diff --git a/.tx/config b/.tx/config new file mode 100644 index 00000000..1d67b233 --- /dev/null +++ b/.tx/config @@ -0,0 +1,12 @@ +[I2P.website] +source_file = ./messages.pot +source_lang = en +trans.de = i2p2www/translations/de/LC_MESSAGES/messages.po +trans.es = i2p2www/translations/es/LC_MESSAGES/messages.po +trans.fr = i2p2www/translations/fr/LC_MESSAGES/messages.po +trans.sv_SE = i2p2www/translations/sv/LC_MESSAGES/messages.po +type = PO + +[main] +host = http://www.transifex.net + diff --git a/compile-messages.sh b/compile-messages.sh new file mode 100755 index 00000000..819e4e81 --- /dev/null +++ b/compile-messages.sh @@ -0,0 +1,4 @@ +#!/bin/sh +. ./translation.vars + +TZ=UTC env/bin/pybabel compile -d $TRANSDIR diff --git a/extract-messages.sh b/extract-messages.sh new file mode 100755 index 00000000..1593068d --- /dev/null +++ b/extract-messages.sh @@ -0,0 +1,8 @@ +#!/bin/sh +. ./translation.vars + +TZ=UTC env/bin/pybabel extract --msgid-bugs-address="http://trac.i2p2.de" \ + --project=$PROJECT \ + --version=$VERSION \ + -F $BABELCFG \ + -o $POTFILE $PROJDIR diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py new file mode 100644 index 00000000..fdf7170a --- /dev/null +++ b/i2p2www/__init__.py @@ -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 diff --git a/i2p2www/babel.cfg b/i2p2www/babel.cfg new file mode 100644 index 00000000..729a9312 --- /dev/null +++ b/i2p2www/babel.cfg @@ -0,0 +1,4 @@ +[python: **.py] +[jinja2: **/pages/**.html] +[jinja2: **/blog/**.rst] +extensions=jinja2.ext.autoescape,jinja2.ext.with_ diff --git a/www.i2p2/pages/status-2004-07-13.html b/i2p2www/blog/2004/07/13/status.html similarity index 95% rename from www.i2p2/pages/status-2004-07-13.html rename to i2p2www/blog/2004/07/13/status.html index 4160ef9e..f4e6e42e 100644 --- a/www.i2p2/pages/status-2004-07-13.html +++ b/i2p2www/blog/2004/07/13/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-07-13{% endblock %} -{% block content %}

I2P Status Notes for 2004-07-13

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -93,4 +90,3 @@ c507IhMQP3WwejdCIyYRx7oX
-{% endblock %} diff --git a/i2p2www/blog/2004/07/13/status.rst b/i2p2www/blog/2004/07/13/status.rst new file mode 100644 index 00000000..cea1b4e6 --- /dev/null +++ b/i2p2www/blog/2004/07/13/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-07-13 +=============================== + +.. raw:: html + :file: blog/2004/07/13/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-07-20.html b/i2p2www/blog/2004/07/20/status.html similarity index 97% rename from www.i2p2/pages/status-2004-07-20.html rename to i2p2www/blog/2004/07/20/status.html index 8124dcfa..2e32c8fb 100644 --- a/www.i2p2/pages/status-2004-07-20.html +++ b/i2p2www/blog/2004/07/20/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-07-20{% endblock %} -{% block content %}

I2P Status Notes for 2004-07-20

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -148,4 +145,3 @@ sxKqvaHlNppJCq/x/BzEWcxd
-{% endblock %} diff --git a/i2p2www/blog/2004/07/20/status.rst b/i2p2www/blog/2004/07/20/status.rst new file mode 100644 index 00000000..482e4a75 --- /dev/null +++ b/i2p2www/blog/2004/07/20/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-07-20 +=============================== + +.. raw:: html + :file: blog/2004/07/20/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-07-27.html b/i2p2www/blog/2004/07/27/status.html similarity index 95% rename from www.i2p2/pages/status-2004-07-27.html rename to i2p2www/blog/2004/07/27/status.html index 7895d539..384c68ce 100644 --- a/www.i2p2/pages/status-2004-07-27.html +++ b/i2p2www/blog/2004/07/27/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-07-27{% endblock %} -{% block content %}

I2P Status Notes for 2004-07-27

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -99,4 +96,3 @@ Q36Vr3muI4ti770dlw0mUDLu
-{% endblock %} diff --git a/i2p2www/blog/2004/07/27/status.rst b/i2p2www/blog/2004/07/27/status.rst new file mode 100644 index 00000000..b9a76d3b --- /dev/null +++ b/i2p2www/blog/2004/07/27/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-07-27 +=============================== + +.. raw:: html + :file: blog/2004/07/27/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-08-03.html b/i2p2www/blog/2004/08/03/status.html similarity index 97% rename from www.i2p2/pages/status-2004-08-03.html rename to i2p2www/blog/2004/08/03/status.html index 1d5ffe17..ce5c2385 100644 --- a/www.i2p2/pages/status-2004-08-03.html +++ b/i2p2www/blog/2004/08/03/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-08-03{% endblock %} -{% block content %}

I2P Status Notes for 2004-08-03

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -143,4 +140,3 @@ iQA/AwUBQQ/U+BpxS9rYd+OGEQI4+ACgglcWt+LSOPGodCCoqSBsVfl0wxYAoNFO
-{% endblock %} diff --git a/i2p2www/blog/2004/08/03/status.rst b/i2p2www/blog/2004/08/03/status.rst new file mode 100644 index 00000000..99bb1cbc --- /dev/null +++ b/i2p2www/blog/2004/08/03/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-08-03 +=============================== + +.. raw:: html + :file: blog/2004/08/03/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-08-10.html b/i2p2www/blog/2004/08/10/status.html similarity index 95% rename from www.i2p2/pages/status-2004-08-10.html rename to i2p2www/blog/2004/08/10/status.html index 5d26763f..d5f5d58f 100644 --- a/www.i2p2/pages/status-2004-08-10.html +++ b/i2p2www/blog/2004/08/10/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-08-10{% endblock %} -{% block content %}

I2P Status Notes for 2004-08-10

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -91,4 +88,3 @@ E+89jypnECNyg/uF1RHuy1Fy
-{% endblock %} diff --git a/i2p2www/blog/2004/08/10/status.rst b/i2p2www/blog/2004/08/10/status.rst new file mode 100644 index 00000000..2b847539 --- /dev/null +++ b/i2p2www/blog/2004/08/10/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-08-10 +=============================== + +.. raw:: html + :file: blog/2004/08/10/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-08-17.html b/i2p2www/blog/2004/08/17/status.html similarity index 93% rename from www.i2p2/pages/status-2004-08-17.html rename to i2p2www/blog/2004/08/17/status.html index fe028ea9..7521aa13 100644 --- a/www.i2p2/pages/status-2004-08-17.html +++ b/i2p2www/blog/2004/08/17/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-08-17{% endblock %} -{% block content %}

I2P Status Notes for 2004-08-17

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -71,4 +68,3 @@ i0kp7DNZkldsLH2uenA0mpeI
-{% endblock %} diff --git a/i2p2www/blog/2004/08/17/status.rst b/i2p2www/blog/2004/08/17/status.rst new file mode 100644 index 00000000..4441d86a --- /dev/null +++ b/i2p2www/blog/2004/08/17/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-08-17 +=============================== + +.. raw:: html + :file: blog/2004/08/17/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-08-24.html b/i2p2www/blog/2004/08/24/status.html similarity index 98% rename from www.i2p2/pages/status-2004-08-24.html rename to i2p2www/blog/2004/08/24/status.html index adc24988..61bc90f5 100644 --- a/www.i2p2/pages/status-2004-08-24.html +++ b/i2p2www/blog/2004/08/24/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-08-24{% endblock %} -{% block content %}

I2P Status Notes for 2004-08-24

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -216,4 +213,3 @@ JDLmPE9nXRLzrRWdTTRJ1JHH
-{% endblock %} diff --git a/i2p2www/blog/2004/08/24/status.rst b/i2p2www/blog/2004/08/24/status.rst new file mode 100644 index 00000000..1824a546 --- /dev/null +++ b/i2p2www/blog/2004/08/24/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-08-24 +=============================== + +.. raw:: html + :file: blog/2004/08/24/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-08-31.html b/i2p2www/blog/2004/08/31/status.html similarity index 97% rename from www.i2p2/pages/status-2004-08-31.html rename to i2p2www/blog/2004/08/31/status.html index b10050b5..8f54b44d 100644 --- a/www.i2p2/pages/status-2004-08-31.html +++ b/i2p2www/blog/2004/08/31/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-08-31{% endblock %} -{% block content %}

I2P Status Notes for 2004-08-31

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -162,4 +159,3 @@ gEg6cYDHMxLuGop/ALQwU+bg
-{% endblock %} diff --git a/i2p2www/blog/2004/08/31/status.rst b/i2p2www/blog/2004/08/31/status.rst new file mode 100644 index 00000000..1c081521 --- /dev/null +++ b/i2p2www/blog/2004/08/31/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-08-31 +=============================== + +.. raw:: html + :file: blog/2004/08/31/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-09-08.html b/i2p2www/blog/2004/09/08/status.html similarity index 97% rename from www.i2p2/pages/status-2004-09-08.html rename to i2p2www/blog/2004/09/08/status.html index e91090cb..22bd828f 100644 --- a/www.i2p2/pages/status-2004-09-08.html +++ b/i2p2www/blog/2004/09/08/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-09-08{% endblock %} -{% block content %}

I2P Status Notes for 2004-09-08

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -130,4 +127,3 @@ qS8j385jn3Xj4wIJCPimEX01
-{% endblock %} diff --git a/i2p2www/blog/2004/09/08/status.rst b/i2p2www/blog/2004/09/08/status.rst new file mode 100644 index 00000000..2c8ca9f5 --- /dev/null +++ b/i2p2www/blog/2004/09/08/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-09-08 +=============================== + +.. raw:: html + :file: blog/2004/09/08/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-09-14.html b/i2p2www/blog/2004/09/14/status.html similarity index 98% rename from www.i2p2/pages/status-2004-09-14.html rename to i2p2www/blog/2004/09/14/status.html index 910ca785..ede0b788 100644 --- a/www.i2p2/pages/status-2004-09-14.html +++ b/i2p2www/blog/2004/09/14/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-09-14{% endblock %} -{% block content %}

I2P Status Notes for 2004-09-14

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -198,4 +195,3 @@ iQA/AwUBQUc1OhpxS9rYd+OGEQLaYQCg0qql8muvuGEh46VICx4t69PuRl8An0Ki
-{% endblock %} diff --git a/i2p2www/blog/2004/09/14/status.rst b/i2p2www/blog/2004/09/14/status.rst new file mode 100644 index 00000000..412bae1a --- /dev/null +++ b/i2p2www/blog/2004/09/14/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-09-14 +=============================== + +.. raw:: html + :file: blog/2004/09/14/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-09-21.html b/i2p2www/blog/2004/09/21/status.html similarity index 91% rename from www.i2p2/pages/status-2004-09-21.html rename to i2p2www/blog/2004/09/21/status.html index 1ecd18ae..03f2df16 100644 --- a/www.i2p2/pages/status-2004-09-21.html +++ b/i2p2www/blog/2004/09/21/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-09-21{% endblock %} -{% block content %}

I2P Status Notes for 2004-09-21

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -56,4 +53,3 @@ iQA/AwUBQVCVAxpxS9rYd+OGEQIdswCg1gpn/wMwppYT4DnNss+ChBi+U7MAnAuW
-{% endblock %} diff --git a/i2p2www/blog/2004/09/21/status.rst b/i2p2www/blog/2004/09/21/status.rst new file mode 100644 index 00000000..90865a05 --- /dev/null +++ b/i2p2www/blog/2004/09/21/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-09-21 +=============================== + +.. raw:: html + :file: blog/2004/09/21/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-09-28.html b/i2p2www/blog/2004/09/28/status.html similarity index 95% rename from www.i2p2/pages/status-2004-09-28.html rename to i2p2www/blog/2004/09/28/status.html index c75309f7..c106cf84 100644 --- a/www.i2p2/pages/status-2004-09-28.html +++ b/i2p2www/blog/2004/09/28/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-09-28{% endblock %} -{% block content %}

I2P Status Notes for 2004-09-28

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -88,4 +85,3 @@ iQA/AwUBQVmbSxpxS9rYd+OGEQLRLQCfXYW9hGbiTALFtsv7L803qAJlFocAoPPO
-{% endblock %} diff --git a/i2p2www/blog/2004/09/28/status.rst b/i2p2www/blog/2004/09/28/status.rst new file mode 100644 index 00000000..c4da5a9b --- /dev/null +++ b/i2p2www/blog/2004/09/28/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-09-28 +=============================== + +.. raw:: html + :file: blog/2004/09/28/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-10-05.html b/i2p2www/blog/2004/10/05/status.html similarity index 97% rename from www.i2p2/pages/status-2004-10-05.html rename to i2p2www/blog/2004/10/05/status.html index 97b0348a..f3d37a44 100644 --- a/www.i2p2/pages/status-2004-10-05.html +++ b/i2p2www/blog/2004/10/05/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-10-05{% endblock %} -{% block content %}

I2P Status Notes for 2004-10-05

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -168,4 +165,3 @@ vkNuIUa6ZwkKMVJWhoZdWto4
-{% endblock %} diff --git a/i2p2www/blog/2004/10/05/status.rst b/i2p2www/blog/2004/10/05/status.rst new file mode 100644 index 00000000..86f3293f --- /dev/null +++ b/i2p2www/blog/2004/10/05/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-10-05 +=============================== + +.. raw:: html + :file: blog/2004/10/05/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-10-12.html b/i2p2www/blog/2004/10/12/status.html similarity index 96% rename from www.i2p2/pages/status-2004-10-12.html rename to i2p2www/blog/2004/10/12/status.html index 019b2af0..f595c4be 100644 --- a/www.i2p2/pages/status-2004-10-12.html +++ b/i2p2www/blog/2004/10/12/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-10-12{% endblock %} -{% block content %}

I2P Status Notes for 2004-10-12

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -112,4 +109,3 @@ uGWqH5WOe6ZCObkRlxVsMj+B
-{% endblock %} diff --git a/i2p2www/blog/2004/10/12/status.rst b/i2p2www/blog/2004/10/12/status.rst new file mode 100644 index 00000000..45570819 --- /dev/null +++ b/i2p2www/blog/2004/10/12/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-10-12 +=============================== + +.. raw:: html + :file: blog/2004/10/12/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-10-19.html b/i2p2www/blog/2004/10/19/status.html similarity index 95% rename from www.i2p2/pages/status-2004-10-19.html rename to i2p2www/blog/2004/10/19/status.html index 40c9f849..538d884b 100644 --- a/www.i2p2/pages/status-2004-10-19.html +++ b/i2p2www/blog/2004/10/19/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-10-19{% endblock %} -{% block content %}

I2P Status Notes for 2004-10-19

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -96,4 +93,3 @@ azbFco6lKpQW9SM631nLXXZB
-{% endblock %} diff --git a/i2p2www/blog/2004/10/19/status.rst b/i2p2www/blog/2004/10/19/status.rst new file mode 100644 index 00000000..6549d74e --- /dev/null +++ b/i2p2www/blog/2004/10/19/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-10-19 +=============================== + +.. raw:: html + :file: blog/2004/10/19/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-10-26.html b/i2p2www/blog/2004/10/26/status.html similarity index 95% rename from www.i2p2/pages/status-2004-10-26.html rename to i2p2www/blog/2004/10/26/status.html index ebfa0fe6..980186a9 100644 --- a/www.i2p2/pages/status-2004-10-26.html +++ b/i2p2www/blog/2004/10/26/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-10-26{% endblock %} -{% block content %}

I2P Status Notes for 2004-10-26

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -92,4 +89,3 @@ zFtdHN6Y54VUcfsFl6+5W/3B
-{% endblock %} diff --git a/i2p2www/blog/2004/10/26/status.rst b/i2p2www/blog/2004/10/26/status.rst new file mode 100644 index 00000000..7f786462 --- /dev/null +++ b/i2p2www/blog/2004/10/26/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-10-26 +=============================== + +.. raw:: html + :file: blog/2004/10/26/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-11-02.html b/i2p2www/blog/2004/11/02/status.html similarity index 95% rename from www.i2p2/pages/status-2004-11-02.html rename to i2p2www/blog/2004/11/02/status.html index f2a4fa03..664d200b 100644 --- a/www.i2p2/pages/status-2004-11-02.html +++ b/i2p2www/blog/2004/11/02/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-11-02{% endblock %} -{% block content %}

I2P Status Notes for 2004-11-02

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -93,4 +90,3 @@ Z1ThyrjEZjAttC/wChPN43aD
-{% endblock %} diff --git a/i2p2www/blog/2004/11/02/status.rst b/i2p2www/blog/2004/11/02/status.rst new file mode 100644 index 00000000..6fced1ca --- /dev/null +++ b/i2p2www/blog/2004/11/02/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-11-02 +=============================== + +.. raw:: html + :file: blog/2004/11/02/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-11-09.html b/i2p2www/blog/2004/11/09/status.html similarity index 90% rename from www.i2p2/pages/status-2004-11-09.html rename to i2p2www/blog/2004/11/09/status.html index c27328d8..972ceecc 100644 --- a/www.i2p2/pages/status-2004-11-09.html +++ b/i2p2www/blog/2004/11/09/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-11-09{% endblock %} -{% block content %}

I2P Status Notes for 2004-11-09

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -60,4 +57,3 @@ iHMiSnKD18OhLH6P91TLfSSv
-{% endblock %} diff --git a/i2p2www/blog/2004/11/09/status.rst b/i2p2www/blog/2004/11/09/status.rst new file mode 100644 index 00000000..63ab7a4a --- /dev/null +++ b/i2p2www/blog/2004/11/09/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-11-09 +=============================== + +.. raw:: html + :file: blog/2004/11/09/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-11-16.html b/i2p2www/blog/2004/11/16/status.html similarity index 94% rename from www.i2p2/pages/status-2004-11-16.html rename to i2p2www/blog/2004/11/16/status.html index a97459b1..fb99f5ec 100644 --- a/www.i2p2/pages/status-2004-11-16.html +++ b/i2p2www/blog/2004/11/16/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-11-16{% endblock %} -{% block content %}

I2P Status Notes for 2004-11-16

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -75,4 +72,3 @@ ZEawa8wEMLl1tz/uk4BTENkb
-{% endblock %} diff --git a/i2p2www/blog/2004/11/16/status.rst b/i2p2www/blog/2004/11/16/status.rst new file mode 100644 index 00000000..f556e157 --- /dev/null +++ b/i2p2www/blog/2004/11/16/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-11-16 +=============================== + +.. raw:: html + :file: blog/2004/11/16/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-11-23.html b/i2p2www/blog/2004/11/23/status.html similarity index 96% rename from www.i2p2/pages/status-2004-11-23.html rename to i2p2www/blog/2004/11/23/status.html index 62aff0a8..8f46c762 100644 --- a/www.i2p2/pages/status-2004-11-23.html +++ b/i2p2www/blog/2004/11/23/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-11-23{% endblock %} -{% block content %}

I2P Status Notes for 2004-11-23

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -117,4 +114,3 @@ pfi+wfwTumipVNuMFPUm39TK
-{% endblock %} diff --git a/i2p2www/blog/2004/11/23/status.rst b/i2p2www/blog/2004/11/23/status.rst new file mode 100644 index 00000000..bb1fd1a5 --- /dev/null +++ b/i2p2www/blog/2004/11/23/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-11-23 +=============================== + +.. raw:: html + :file: blog/2004/11/23/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-11-30.html b/i2p2www/blog/2004/11/30/status.html similarity index 95% rename from www.i2p2/pages/status-2004-11-30.html rename to i2p2www/blog/2004/11/30/status.html index 650151b0..61cf05b9 100644 --- a/www.i2p2/pages/status-2004-11-30.html +++ b/i2p2www/blog/2004/11/30/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-11-30{% endblock %} -{% block content %}

I2P Status Notes for 2004-11-30

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -101,4 +98,3 @@ iD8DBQFBrOBZGnFL2th344YRArtBAJ9YhRvP3MczO96gi4Xwnowie55HlACgzlO3
-{% endblock %} diff --git a/i2p2www/blog/2004/11/30/status.rst b/i2p2www/blog/2004/11/30/status.rst new file mode 100644 index 00000000..be1e6167 --- /dev/null +++ b/i2p2www/blog/2004/11/30/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-11-30 +=============================== + +.. raw:: html + :file: blog/2004/11/30/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-12-07.html b/i2p2www/blog/2004/12/07/status.html similarity index 91% rename from www.i2p2/pages/status-2004-12-07.html rename to i2p2www/blog/2004/12/07/status.html index c164b62c..f34dfe38 100644 --- a/www.i2p2/pages/status-2004-12-07.html +++ b/i2p2www/blog/2004/12/07/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-12-07{% endblock %} -{% block content %}

I2P Status Notes for 2004-12-07

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -59,4 +56,3 @@ i2p mailing list
 i2p-Po2eaMWI3R0@xxxxxxxxxxxxxxxx
 http://i2p.dnsalias.net/mailman/listinfo/i2p
-{% endblock %} diff --git a/i2p2www/blog/2004/12/07/status.rst b/i2p2www/blog/2004/12/07/status.rst new file mode 100644 index 00000000..529db3a9 --- /dev/null +++ b/i2p2www/blog/2004/12/07/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-12-07 +=============================== + +.. raw:: html + :file: blog/2004/12/07/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-12-14.html b/i2p2www/blog/2004/12/14/status.html similarity index 95% rename from www.i2p2/pages/status-2004-12-14.html rename to i2p2www/blog/2004/12/14/status.html index 7420d7ec..1dd3c99b 100644 --- a/www.i2p2/pages/status-2004-12-14.html +++ b/i2p2www/blog/2004/12/14/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-12-14{% endblock %} -{% block content %}

I2P Status Notes for 2004-12-14

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -101,4 +98,3 @@ vL+gi2piiZq3aup7iyN/wRY=
-{% endblock %} diff --git a/i2p2www/blog/2004/12/14/status.rst b/i2p2www/blog/2004/12/14/status.rst new file mode 100644 index 00000000..f8ad8314 --- /dev/null +++ b/i2p2www/blog/2004/12/14/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-12-14 +=============================== + +.. raw:: html + :file: blog/2004/12/14/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-12-21.html b/i2p2www/blog/2004/12/21/status.html similarity index 96% rename from www.i2p2/pages/status-2004-12-21.html rename to i2p2www/blog/2004/12/21/status.html index 02e3d85d..4e8e679a 100644 --- a/www.i2p2/pages/status-2004-12-21.html +++ b/i2p2www/blog/2004/12/21/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-12-21{% endblock %} -{% block content %}

I2P Status Notes for 2004-12-21

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -111,4 +108,3 @@ iD8DBQFByItjGnFL2th344YRAmmOAKD+HxEAK+dqseq8ZCO5pjvW4EKImQCgkfwX
-{% endblock %} diff --git a/i2p2www/blog/2004/12/21/status.rst b/i2p2www/blog/2004/12/21/status.rst new file mode 100644 index 00000000..a9e64336 --- /dev/null +++ b/i2p2www/blog/2004/12/21/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-12-21 +=============================== + +.. raw:: html + :file: blog/2004/12/21/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2004-12-28.html b/i2p2www/blog/2004/12/28/status.html similarity index 91% rename from www.i2p2/pages/status-2004-12-28.html rename to i2p2www/blog/2004/12/28/status.html index 6138e5f0..0d158b8c 100644 --- a/www.i2p2/pages/status-2004-12-28.html +++ b/i2p2www/blog/2004/12/28/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2004-12-28{% endblock %} -{% block content %}

I2P Status Notes for 2004-12-28

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -57,4 +54,3 @@ c9O5fcXfOJ54OuM7vPhHBQU=
-{% endblock %} diff --git a/i2p2www/blog/2004/12/28/status.rst b/i2p2www/blog/2004/12/28/status.rst new file mode 100644 index 00000000..882e0096 --- /dev/null +++ b/i2p2www/blog/2004/12/28/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2004-12-28 +=============================== + +.. raw:: html + :file: blog/2004/12/28/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-01-04.html b/i2p2www/blog/2005/01/04/status.html similarity index 96% rename from www.i2p2/pages/status-2005-01-04.html rename to i2p2www/blog/2005/01/04/status.html index ee953337..ed66a866 100644 --- a/www.i2p2/pages/status-2005-01-04.html +++ b/i2p2www/blog/2005/01/04/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-01-04{% endblock %} -{% block content %}

I2P Status Notes for 2005-01-04

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -115,4 +112,3 @@ ZQXQmqk6EIx184r2Zi7poZg=
-{% endblock %} diff --git a/i2p2www/blog/2005/01/04/status.rst b/i2p2www/blog/2005/01/04/status.rst new file mode 100644 index 00000000..c9c28c9e --- /dev/null +++ b/i2p2www/blog/2005/01/04/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-01-04 +=============================== + +.. raw:: html + :file: blog/2005/01/04/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-01-11.html b/i2p2www/blog/2005/01/11/status.html similarity index 97% rename from www.i2p2/pages/status-2005-01-11.html rename to i2p2www/blog/2005/01/11/status.html index ce7cce0f..86ba3f98 100644 --- a/www.i2p2/pages/status-2005-01-11.html +++ b/i2p2www/blog/2005/01/11/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-01-11{% endblock %} -{% block content %}

I2P Status Notes for 2005-01-11

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -132,4 +129,3 @@ ItUMfG4sTnmRKk5m2u9Yxjg=
-{% endblock %} diff --git a/i2p2www/blog/2005/01/11/status.rst b/i2p2www/blog/2005/01/11/status.rst new file mode 100644 index 00000000..d0bfb66b --- /dev/null +++ b/i2p2www/blog/2005/01/11/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-01-11 +=============================== + +.. raw:: html + :file: blog/2005/01/11/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-01-18.html b/i2p2www/blog/2005/01/18/status.html similarity index 97% rename from www.i2p2/pages/status-2005-01-18.html rename to i2p2www/blog/2005/01/18/status.html index a4d34263..d7ee78b0 100644 --- a/www.i2p2/pages/status-2005-01-18.html +++ b/i2p2www/blog/2005/01/18/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-01-18{% endblock %} -{% block content %}

I2P Status Notes for 2005-01-18

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -138,4 +135,3 @@ LFh9H55UFtsLPRFk7hxdv1c=
-{% endblock %} diff --git a/i2p2www/blog/2005/01/18/status.rst b/i2p2www/blog/2005/01/18/status.rst new file mode 100644 index 00000000..edf655c0 --- /dev/null +++ b/i2p2www/blog/2005/01/18/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-01-18 +=============================== + +.. raw:: html + :file: blog/2005/01/18/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-01-25.html b/i2p2www/blog/2005/01/25/status.html similarity index 94% rename from www.i2p2/pages/status-2005-01-25.html rename to i2p2www/blog/2005/01/25/status.html index 49ad20a7..e3b5c2a5 100644 --- a/www.i2p2/pages/status-2005-01-25.html +++ b/i2p2www/blog/2005/01/25/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-01-25{% endblock %} -{% block content %}

I2P Status Notes for 2005-01-25

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -73,4 +70,3 @@ W/EO4gPSteZWp+rBogWfB3M=
-{% endblock %} diff --git a/i2p2www/blog/2005/01/25/status.rst b/i2p2www/blog/2005/01/25/status.rst new file mode 100644 index 00000000..86d9dfd5 --- /dev/null +++ b/i2p2www/blog/2005/01/25/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-01-25 +=============================== + +.. raw:: html + :file: blog/2005/01/25/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-02-01.html b/i2p2www/blog/2005/02/01/status.html similarity index 94% rename from www.i2p2/pages/status-2005-02-01.html rename to i2p2www/blog/2005/02/01/status.html index 9c8aad44..0aac5a94 100644 --- a/www.i2p2/pages/status-2005-02-01.html +++ b/i2p2www/blog/2005/02/01/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-02-01{% endblock %} -{% block content %}

I2P Status Notes for 2005-02-01

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -74,4 +71,3 @@ kF6G0CoDu08TvpEtuzuzH9o=
-{% endblock %} diff --git a/i2p2www/blog/2005/02/01/status.rst b/i2p2www/blog/2005/02/01/status.rst new file mode 100644 index 00000000..69f73830 --- /dev/null +++ b/i2p2www/blog/2005/02/01/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-02-01 +=============================== + +.. raw:: html + :file: blog/2005/02/01/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-02-08.html b/i2p2www/blog/2005/02/08/status.html similarity index 96% rename from www.i2p2/pages/status-2005-02-08.html rename to i2p2www/blog/2005/02/08/status.html index ba74d327..565c07f2 100644 --- a/www.i2p2/pages/status-2005-02-08.html +++ b/i2p2www/blog/2005/02/08/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-02-08{% endblock %} -{% block content %}

I2P Status Notes for 2005-02-08

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -107,4 +104,3 @@ iD8DBQFCCSaRGnFL2th344YRApVpAKCEypMmgxmJu7ezMwKD5G3ROClh8ACfRqj6
-{% endblock %} diff --git a/i2p2www/blog/2005/02/08/status.rst b/i2p2www/blog/2005/02/08/status.rst new file mode 100644 index 00000000..25ec46e3 --- /dev/null +++ b/i2p2www/blog/2005/02/08/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-02-08 +=============================== + +.. raw:: html + :file: blog/2005/02/08/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-02-15.html b/i2p2www/blog/2005/02/15/status.html similarity index 95% rename from www.i2p2/pages/status-2005-02-15.html rename to i2p2www/blog/2005/02/15/status.html index 236a2755..cf62c7a2 100644 --- a/www.i2p2/pages/status-2005-02-15.html +++ b/i2p2www/blog/2005/02/15/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-02-15{% endblock %} -{% block content %}

I2P Status Notes for 2005-02-15

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -90,4 +87,3 @@ Cbz/JT+3L2OfdhKAy8p/isQ=
-{% endblock %} diff --git a/i2p2www/blog/2005/02/15/status.rst b/i2p2www/blog/2005/02/15/status.rst new file mode 100644 index 00000000..d8c42eae --- /dev/null +++ b/i2p2www/blog/2005/02/15/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-02-15 +=============================== + +.. raw:: html + :file: blog/2005/02/15/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-02-22.html b/i2p2www/blog/2005/02/22/status.html similarity index 94% rename from www.i2p2/pages/status-2005-02-22.html rename to i2p2www/blog/2005/02/22/status.html index 75b0efdf..cb622dbf 100644 --- a/www.i2p2/pages/status-2005-02-22.html +++ b/i2p2www/blog/2005/02/22/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-02-22{% endblock %} -{% block content %}

I2P Status Notes for 2005-02-22

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -81,4 +78,3 @@ nNdoN5D/aKLL0XdusZcigTA=
-{% endblock %} diff --git a/i2p2www/blog/2005/02/22/status.rst b/i2p2www/blog/2005/02/22/status.rst new file mode 100644 index 00000000..f6aa4e5b --- /dev/null +++ b/i2p2www/blog/2005/02/22/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-02-22 +=============================== + +.. raw:: html + :file: blog/2005/02/22/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-03-01.html b/i2p2www/blog/2005/03/01/status.html similarity index 95% rename from www.i2p2/pages/status-2005-03-01.html rename to i2p2www/blog/2005/03/01/status.html index 1c3677c0..563b4631 100644 --- a/www.i2p2/pages/status-2005-03-01.html +++ b/i2p2www/blog/2005/03/01/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-03-01{% endblock %} -{% block content %}

I2P Status Notes for 2005-03-01

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -94,4 +91,3 @@ iD8DBQFCJNebGnFL2th344YRAobNAJ4lfCULXX7WAGZxOlh/NzTuV1eNwgCg1eV/
-{% endblock %} diff --git a/i2p2www/blog/2005/03/01/status.rst b/i2p2www/blog/2005/03/01/status.rst new file mode 100644 index 00000000..4b8e2b86 --- /dev/null +++ b/i2p2www/blog/2005/03/01/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-03-01 +=============================== + +.. raw:: html + :file: blog/2005/03/01/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-03-08.html b/i2p2www/blog/2005/03/08/status.html similarity index 93% rename from www.i2p2/pages/status-2005-03-08.html rename to i2p2www/blog/2005/03/08/status.html index f4d3edc8..f2e6ec8a 100644 --- a/www.i2p2/pages/status-2005-03-08.html +++ b/i2p2www/blog/2005/03/08/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-03-08{% endblock %} -{% block content %}

I2P Status Notes for 2005-03-08

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -70,4 +67,3 @@ EHsY9W9LztKK3FZBHPN2FyE=
-{% endblock %} diff --git a/i2p2www/blog/2005/03/08/status.rst b/i2p2www/blog/2005/03/08/status.rst new file mode 100644 index 00000000..5b0b929e --- /dev/null +++ b/i2p2www/blog/2005/03/08/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-03-08 +=============================== + +.. raw:: html + :file: blog/2005/03/08/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-03-15.html b/i2p2www/blog/2005/03/15/status.html similarity index 94% rename from www.i2p2/pages/status-2005-03-15.html rename to i2p2www/blog/2005/03/15/status.html index 1b596eec..452f2992 100644 --- a/www.i2p2/pages/status-2005-03-15.html +++ b/i2p2www/blog/2005/03/15/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-03-15{% endblock %} -{% block content %}

I2P Status Notes for 2005-03-15

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -71,4 +68,3 @@ mvxKNX+jQ7jnfBFyJponyCc=
-{% endblock %} diff --git a/i2p2www/blog/2005/03/15/status.rst b/i2p2www/blog/2005/03/15/status.rst new file mode 100644 index 00000000..6008ccc0 --- /dev/null +++ b/i2p2www/blog/2005/03/15/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-03-15 +=============================== + +.. raw:: html + :file: blog/2005/03/15/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-03-22.html b/i2p2www/blog/2005/03/22/status.html similarity index 94% rename from www.i2p2/pages/status-2005-03-22.html rename to i2p2www/blog/2005/03/22/status.html index fa5fcb22..23b47431 100644 --- a/www.i2p2/pages/status-2005-03-22.html +++ b/i2p2www/blog/2005/03/22/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-03-22{% endblock %} -{% block content %}

I2P Status Notes for 2005-03-22

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -84,4 +81,3 @@ iD8DBQFCQIW+GnFL2th344YRAj03AKCAwDNl6Dr/4Xi6l9x4kOhw8YIkEwCglfFc
-{% endblock %} diff --git a/i2p2www/blog/2005/03/22/status.rst b/i2p2www/blog/2005/03/22/status.rst new file mode 100644 index 00000000..6a047ae2 --- /dev/null +++ b/i2p2www/blog/2005/03/22/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-03-22 +=============================== + +.. raw:: html + :file: blog/2005/03/22/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-03-29.html b/i2p2www/blog/2005/03/29/status.html similarity index 95% rename from www.i2p2/pages/status-2005-03-29.html rename to i2p2www/blog/2005/03/29/status.html index e64ce8cc..0194b23e 100644 --- a/www.i2p2/pages/status-2005-03-29.html +++ b/i2p2www/blog/2005/03/29/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-03-29{% endblock %} -{% block content %}

I2P Status Notes for 2005-03-29

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -88,4 +85,3 @@ Kk+3I6WgqDjqaNKSc5xnoQA=
-{% endblock %} diff --git a/i2p2www/blog/2005/03/29/status.rst b/i2p2www/blog/2005/03/29/status.rst new file mode 100644 index 00000000..ed09e445 --- /dev/null +++ b/i2p2www/blog/2005/03/29/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-03-29 +=============================== + +.. raw:: html + :file: blog/2005/03/29/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-04-05.html b/i2p2www/blog/2005/04/05/status.html similarity index 92% rename from www.i2p2/pages/status-2005-04-05.html rename to i2p2www/blog/2005/04/05/status.html index 0de00d45..bd84ef2c 100644 --- a/www.i2p2/pages/status-2005-04-05.html +++ b/i2p2www/blog/2005/04/05/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-04-05{% endblock %} -{% block content %}

I2P Status Notes for 2005-04-05

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -57,4 +54,3 @@ Li2s44HU5EehnMoCMxIOZlc=
-{% endblock %} diff --git a/i2p2www/blog/2005/04/05/status.rst b/i2p2www/blog/2005/04/05/status.rst new file mode 100644 index 00000000..0c447146 --- /dev/null +++ b/i2p2www/blog/2005/04/05/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-04-05 +=============================== + +.. raw:: html + :file: blog/2005/04/05/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-04-12.html b/i2p2www/blog/2005/04/12/status.html similarity index 97% rename from www.i2p2/pages/status-2005-04-12.html rename to i2p2www/blog/2005/04/12/status.html index ca916400..ec4b2cd1 100644 --- a/www.i2p2/pages/status-2005-04-12.html +++ b/i2p2www/blog/2005/04/12/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-04-12{% endblock %} -{% block content %}

I2P Status Notes for 2005-04-12

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -127,4 +124,3 @@ ONGe96zS1hmVNeAzqQgjeUo=
-{% endblock %} diff --git a/i2p2www/blog/2005/04/12/status.rst b/i2p2www/blog/2005/04/12/status.rst new file mode 100644 index 00000000..c1383f2c --- /dev/null +++ b/i2p2www/blog/2005/04/12/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-04-12 +=============================== + +.. raw:: html + :file: blog/2005/04/12/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-04-19.html b/i2p2www/blog/2005/04/19/status.html similarity index 94% rename from www.i2p2/pages/status-2005-04-19.html rename to i2p2www/blog/2005/04/19/status.html index ebe33c85..2b67bff5 100644 --- a/www.i2p2/pages/status-2005-04-19.html +++ b/i2p2www/blog/2005/04/19/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-04-19{% endblock %} -{% block content %}

I2P Status Notes for 2005-04-19

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -80,4 +77,3 @@ T3H2xh74GXTtBdOloaAHS9o=
-{% endblock %} diff --git a/i2p2www/blog/2005/04/19/status.rst b/i2p2www/blog/2005/04/19/status.rst new file mode 100644 index 00000000..bc49d34c --- /dev/null +++ b/i2p2www/blog/2005/04/19/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-04-19 +=============================== + +.. raw:: html + :file: blog/2005/04/19/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-04-26.html b/i2p2www/blog/2005/04/26/status.html similarity index 92% rename from www.i2p2/pages/status-2005-04-26.html rename to i2p2www/blog/2005/04/26/status.html index 6ba2b317..0cd1cd91 100644 --- a/www.i2p2/pages/status-2005-04-26.html +++ b/i2p2www/blog/2005/04/26/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-04-26{% endblock %} -{% block content %}

I2P Status Notes for 2005-04-26

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -61,4 +58,3 @@ VBGnM3PHevpd6dpqHoI/tvg=
-{% endblock %} diff --git a/i2p2www/blog/2005/04/26/status.rst b/i2p2www/blog/2005/04/26/status.rst new file mode 100644 index 00000000..6f1c7629 --- /dev/null +++ b/i2p2www/blog/2005/04/26/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-04-26 +=============================== + +.. raw:: html + :file: blog/2005/04/26/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-05-03.html b/i2p2www/blog/2005/05/03/status.html similarity index 96% rename from www.i2p2/pages/status-2005-05-03.html rename to i2p2www/blog/2005/05/03/status.html index 5924348a..6491dae3 100644 --- a/www.i2p2/pages/status-2005-05-03.html +++ b/i2p2www/blog/2005/05/03/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-05-03{% endblock %} -{% block content %}

I2P Status Notes for 2005-05-03

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -107,4 +104,3 @@ vJ2B+nJiHEMLwobhZIRS2hQ=
-{% endblock %} diff --git a/i2p2www/blog/2005/05/03/status.rst b/i2p2www/blog/2005/05/03/status.rst new file mode 100644 index 00000000..defbeef6 --- /dev/null +++ b/i2p2www/blog/2005/05/03/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-05-03 +=============================== + +.. raw:: html + :file: blog/2005/05/03/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-06-21.html b/i2p2www/blog/2005/06/21/status.html similarity index 96% rename from www.i2p2/pages/status-2005-06-21.html rename to i2p2www/blog/2005/06/21/status.html index 90dc7a8a..19a2819c 100644 --- a/www.i2p2/pages/status-2005-06-21.html +++ b/i2p2www/blog/2005/06/21/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-06-21{% endblock %} -{% block content %}

I2P Status Notes for 2005-06-21

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -114,4 +111,3 @@ gaRYTsDAU3zHBCxr4TiSl18=
-{% endblock %} diff --git a/i2p2www/blog/2005/06/21/status.rst b/i2p2www/blog/2005/06/21/status.rst new file mode 100644 index 00000000..b517f85c --- /dev/null +++ b/i2p2www/blog/2005/06/21/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-06-21 +=============================== + +.. raw:: html + :file: blog/2005/06/21/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-06-28.html b/i2p2www/blog/2005/06/28/status.html similarity index 97% rename from www.i2p2/pages/status-2005-06-28.html rename to i2p2www/blog/2005/06/28/status.html index bee9abc6..7c9caa53 100644 --- a/www.i2p2/pages/status-2005-06-28.html +++ b/i2p2www/blog/2005/06/28/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-06-28{% endblock %} -{% block content %}

I2P Status Notes for 2005-06-28

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -129,4 +126,3 @@ mbSQS7iBWcts4GQpGLBmcSg=
-{% endblock %} diff --git a/i2p2www/blog/2005/06/28/status.rst b/i2p2www/blog/2005/06/28/status.rst new file mode 100644 index 00000000..bde58a07 --- /dev/null +++ b/i2p2www/blog/2005/06/28/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-06-28 +=============================== + +.. raw:: html + :file: blog/2005/06/28/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-07-05.html b/i2p2www/blog/2005/07/05/status.html similarity index 96% rename from www.i2p2/pages/status-2005-07-05.html rename to i2p2www/blog/2005/07/05/status.html index 45d1510e..08025bde 100644 --- a/www.i2p2/pages/status-2005-07-05.html +++ b/i2p2www/blog/2005/07/05/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-07-05{% endblock %} -{% block content %}

I2P Status Notes for 2005-07-05

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -107,4 +104,3 @@ p1RmRcbFNI8vA+qVwFGVFT4=
-{% endblock %} diff --git a/i2p2www/blog/2005/07/05/status.rst b/i2p2www/blog/2005/07/05/status.rst new file mode 100644 index 00000000..f603d010 --- /dev/null +++ b/i2p2www/blog/2005/07/05/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-07-05 +=============================== + +.. raw:: html + :file: blog/2005/07/05/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-07-12.html b/i2p2www/blog/2005/07/12/status.html similarity index 96% rename from www.i2p2/pages/status-2005-07-12.html rename to i2p2www/blog/2005/07/12/status.html index 97871c07..b4c8d213 100644 --- a/www.i2p2/pages/status-2005-07-12.html +++ b/i2p2www/blog/2005/07/12/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-07-12{% endblock %} -{% block content %}

I2P Status Notes for 2005-07-12

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -99,4 +96,3 @@ gB0FYFO3bKRemtBoB1JNyLM=
-{% endblock %} diff --git a/i2p2www/blog/2005/07/12/status.rst b/i2p2www/blog/2005/07/12/status.rst new file mode 100644 index 00000000..4cc9344d --- /dev/null +++ b/i2p2www/blog/2005/07/12/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-07-12 +=============================== + +.. raw:: html + :file: blog/2005/07/12/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-07-19.html b/i2p2www/blog/2005/07/19/status.html similarity index 88% rename from www.i2p2/pages/status-2005-07-19.html rename to i2p2www/blog/2005/07/19/status.html index 17af1ac9..61de7c2c 100644 --- a/www.i2p2/pages/status-2005-07-19.html +++ b/i2p2www/blog/2005/07/19/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-07-19{% endblock %} -{% block content %}

I2P Status Notes for 2005-07-19

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -41,4 +38,3 @@ Toa8+cur8F8ErP5Wz57GeCs=
-{% endblock %} diff --git a/i2p2www/blog/2005/07/19/status.rst b/i2p2www/blog/2005/07/19/status.rst new file mode 100644 index 00000000..75d4cd6a --- /dev/null +++ b/i2p2www/blog/2005/07/19/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-07-19 +=============================== + +.. raw:: html + :file: blog/2005/07/19/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-07-26.html b/i2p2www/blog/2005/07/26/status.html similarity index 90% rename from www.i2p2/pages/status-2005-07-26.html rename to i2p2www/blog/2005/07/26/status.html index 61c9daa7..0c60b027 100644 --- a/www.i2p2/pages/status-2005-07-26.html +++ b/i2p2www/blog/2005/07/26/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-07-26{% endblock %} -{% block content %}

I2P Status Notes for 2005-07-26

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -45,4 +42,3 @@ ifBDYsYs61vpTg447SJ02Xk=
-{% endblock %} diff --git a/i2p2www/blog/2005/07/26/status.rst b/i2p2www/blog/2005/07/26/status.rst new file mode 100644 index 00000000..47e52bf9 --- /dev/null +++ b/i2p2www/blog/2005/07/26/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-07-26 +=============================== + +.. raw:: html + :file: blog/2005/07/26/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-08-02.html b/i2p2www/blog/2005/08/02/status.html similarity index 95% rename from www.i2p2/pages/status-2005-08-02.html rename to i2p2www/blog/2005/08/02/status.html index a793e163..95ddb000 100644 --- a/www.i2p2/pages/status-2005-08-02.html +++ b/i2p2www/blog/2005/08/02/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-08-02{% endblock %} -{% block content %}

I2P Status Notes for 2005-08-02

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -92,4 +89,3 @@ jRueb/0QtxGouKlYVM6C1Ms=
-{% endblock %} diff --git a/i2p2www/blog/2005/08/02/status.rst b/i2p2www/blog/2005/08/02/status.rst new file mode 100644 index 00000000..b23b194e --- /dev/null +++ b/i2p2www/blog/2005/08/02/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-08-02 +=============================== + +.. raw:: html + :file: blog/2005/08/02/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-08-09.html b/i2p2www/blog/2005/08/09/status.html similarity index 92% rename from www.i2p2/pages/status-2005-08-09.html rename to i2p2www/blog/2005/08/09/status.html index b0a32e50..e093881b 100644 --- a/www.i2p2/pages/status-2005-08-09.html +++ b/i2p2www/blog/2005/08/09/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-08-09{% endblock %} -{% block content %}

I2P Status Notes for 2005-08-09

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -56,4 +53,3 @@ uYh12HSZl+lrsjar+TS36q0=
-{% endblock %} diff --git a/i2p2www/blog/2005/08/09/status.rst b/i2p2www/blog/2005/08/09/status.rst new file mode 100644 index 00000000..ba447da0 --- /dev/null +++ b/i2p2www/blog/2005/08/09/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-08-09 +=============================== + +.. raw:: html + :file: blog/2005/08/09/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-08-16.html b/i2p2www/blog/2005/08/16/status.html similarity index 95% rename from www.i2p2/pages/status-2005-08-16.html rename to i2p2www/blog/2005/08/16/status.html index 0cf44bae..2739262a 100644 --- a/www.i2p2/pages/status-2005-08-16.html +++ b/i2p2www/blog/2005/08/16/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-08-16{% endblock %} -{% block content %}

I2P Status Notes for 2005-08-16

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -88,4 +85,3 @@ ZA7O66ghsqwxy4dcVh9e4Hg=
-{% endblock %} diff --git a/i2p2www/blog/2005/08/16/status.rst b/i2p2www/blog/2005/08/16/status.rst new file mode 100644 index 00000000..1a4b8049 --- /dev/null +++ b/i2p2www/blog/2005/08/16/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-08-16 +=============================== + +.. raw:: html + :file: blog/2005/08/16/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-08-23.html b/i2p2www/blog/2005/08/23/status.html similarity index 96% rename from www.i2p2/pages/status-2005-08-23.html rename to i2p2www/blog/2005/08/23/status.html index 95e52c19..83c81ade 100644 --- a/www.i2p2/pages/status-2005-08-23.html +++ b/i2p2www/blog/2005/08/23/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-08-23{% endblock %} -{% block content %}

I2P Status Notes for 2005-08-23

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -106,4 +103,3 @@ eZbXWs+EFfg8QQq3YIv08yw=
-{% endblock %} diff --git a/i2p2www/blog/2005/08/23/status.rst b/i2p2www/blog/2005/08/23/status.rst new file mode 100644 index 00000000..0b376899 --- /dev/null +++ b/i2p2www/blog/2005/08/23/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-08-23 +=============================== + +.. raw:: html + :file: blog/2005/08/23/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-08-30.html b/i2p2www/blog/2005/08/30/status.html similarity index 96% rename from www.i2p2/pages/status-2005-08-30.html rename to i2p2www/blog/2005/08/30/status.html index 485d2552..21b2ccc3 100644 --- a/www.i2p2/pages/status-2005-08-30.html +++ b/i2p2www/blog/2005/08/30/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-08-30{% endblock %} -{% block content %}

I2P Status Notes for 2005-08-30

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -104,4 +101,3 @@ omzf6cHV9GW3oBCkAHg7gns=
-{% endblock %} diff --git a/i2p2www/blog/2005/08/30/status.rst b/i2p2www/blog/2005/08/30/status.rst new file mode 100644 index 00000000..d8ae9b82 --- /dev/null +++ b/i2p2www/blog/2005/08/30/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-08-30 +=============================== + +.. raw:: html + :file: blog/2005/08/30/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-09-06.html b/i2p2www/blog/2005/09/06/status.html similarity index 95% rename from www.i2p2/pages/status-2005-09-06.html rename to i2p2www/blog/2005/09/06/status.html index 4d9ac134..d959867d 100644 --- a/www.i2p2/pages/status-2005-09-06.html +++ b/i2p2www/blog/2005/09/06/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-09-06{% endblock %} -{% block content %}

I2P Status Notes for 2005-09-06

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -84,4 +81,3 @@ nGjbU9ArII04Uj3ZJiAsgC0=
-{% endblock %} diff --git a/i2p2www/blog/2005/09/06/status.rst b/i2p2www/blog/2005/09/06/status.rst new file mode 100644 index 00000000..943c4082 --- /dev/null +++ b/i2p2www/blog/2005/09/06/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-09-06 +=============================== + +.. raw:: html + :file: blog/2005/09/06/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-09-13.html b/i2p2www/blog/2005/09/13/status.html similarity index 96% rename from www.i2p2/pages/status-2005-09-13.html rename to i2p2www/blog/2005/09/13/status.html index 548ff175..985988ec 100644 --- a/www.i2p2/pages/status-2005-09-13.html +++ b/i2p2www/blog/2005/09/13/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-09-13{% endblock %} -{% block content %}

I2P Status Notes for 2005-09-13

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -118,4 +115,3 @@ PVtD2O9r3Xk4yT8r3UWD45E=
-{% endblock %} diff --git a/i2p2www/blog/2005/09/13/status.rst b/i2p2www/blog/2005/09/13/status.rst new file mode 100644 index 00000000..5985931a --- /dev/null +++ b/i2p2www/blog/2005/09/13/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-09-13 +=============================== + +.. raw:: html + :file: blog/2005/09/13/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-09-20.html b/i2p2www/blog/2005/09/20/status.html similarity index 96% rename from www.i2p2/pages/status-2005-09-20.html rename to i2p2www/blog/2005/09/20/status.html index b82e9832..265d699f 100644 --- a/www.i2p2/pages/status-2005-09-20.html +++ b/i2p2www/blog/2005/09/20/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-09-20{% endblock %} -{% block content %}

I2P Status Notes for 2005-09-20

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -112,4 +109,3 @@ U48LKyf4X8qHAJN4Z5t8eVg=
-{% endblock %} diff --git a/i2p2www/blog/2005/09/20/status.rst b/i2p2www/blog/2005/09/20/status.rst new file mode 100644 index 00000000..3cb51c6b --- /dev/null +++ b/i2p2www/blog/2005/09/20/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-09-20 +=============================== + +.. raw:: html + :file: blog/2005/09/20/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-10-04.html b/i2p2www/blog/2005/10/04/status.html similarity index 92% rename from www.i2p2/pages/status-2005-10-04.html rename to i2p2www/blog/2005/10/04/status.html index 4ef93875..d3f526ff 100644 --- a/www.i2p2/pages/status-2005-10-04.html +++ b/i2p2www/blog/2005/10/04/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-10-04{% endblock %} -{% block content %}

I2P Status Notes for 2005-10-04

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -60,4 +57,3 @@ iD8DBQFDQtBeWYfZ3rPnHH0RAta/AJ4pXQ8TE1sXwnqtpm/KR8vWv4pKkwCff+fG
-{% endblock %} diff --git a/i2p2www/blog/2005/10/04/status.rst b/i2p2www/blog/2005/10/04/status.rst new file mode 100644 index 00000000..091011ff --- /dev/null +++ b/i2p2www/blog/2005/10/04/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-10-04 +=============================== + +.. raw:: html + :file: blog/2005/10/04/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-10-11.html b/i2p2www/blog/2005/10/11/status.html similarity index 97% rename from www.i2p2/pages/status-2005-10-11.html rename to i2p2www/blog/2005/10/11/status.html index 528cf833..fa732078 100644 --- a/www.i2p2/pages/status-2005-10-11.html +++ b/i2p2www/blog/2005/10/11/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-10-11{% endblock %} -{% block content %}

I2P Status Notes for 2005-10-11

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -133,4 +130,3 @@ pGTlS9rp+6WTthBLEZ07b2s=
-{% endblock %} diff --git a/i2p2www/blog/2005/10/11/status.rst b/i2p2www/blog/2005/10/11/status.rst new file mode 100644 index 00000000..0113db5e --- /dev/null +++ b/i2p2www/blog/2005/10/11/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-10-11 +=============================== + +.. raw:: html + :file: blog/2005/10/11/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-10-18.html b/i2p2www/blog/2005/10/18/status.html similarity index 96% rename from www.i2p2/pages/status-2005-10-18.html rename to i2p2www/blog/2005/10/18/status.html index 08d90ac7..22294782 100644 --- a/www.i2p2/pages/status-2005-10-18.html +++ b/i2p2www/blog/2005/10/18/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-10-18{% endblock %} -{% block content %}

I2P Status Notes for 2005-10-18

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -105,4 +102,3 @@ rYTKbx3oDZr3XWp3E9s0ag==
-{% endblock %} diff --git a/i2p2www/blog/2005/10/18/status.rst b/i2p2www/blog/2005/10/18/status.rst new file mode 100644 index 00000000..aefa6162 --- /dev/null +++ b/i2p2www/blog/2005/10/18/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-10-18 +=============================== + +.. raw:: html + :file: blog/2005/10/18/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-10-25.html b/i2p2www/blog/2005/10/25/status.html similarity index 97% rename from www.i2p2/pages/status-2005-10-25.html rename to i2p2www/blog/2005/10/25/status.html index 339b1909..475ed252 100644 --- a/www.i2p2/pages/status-2005-10-25.html +++ b/i2p2www/blog/2005/10/25/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-10-25{% endblock %} -{% block content %}

I2P Status Notes for 2005-10-25

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -129,4 +126,3 @@ iD8DBQFDXpFZWYfZ3rPnHH0RAqKMAJ0TdFB1/n46y3Qn8jHWVl63kwJe4gCfX9Sp
-{% endblock %} diff --git a/i2p2www/blog/2005/10/25/status.rst b/i2p2www/blog/2005/10/25/status.rst new file mode 100644 index 00000000..b795c606 --- /dev/null +++ b/i2p2www/blog/2005/10/25/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-10-25 +=============================== + +.. raw:: html + :file: blog/2005/10/25/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-11-01.html b/i2p2www/blog/2005/11/01/status.html similarity index 96% rename from www.i2p2/pages/status-2005-11-01.html rename to i2p2www/blog/2005/11/01/status.html index 1f81f548..e330e522 100644 --- a/www.i2p2/pages/status-2005-11-01.html +++ b/i2p2www/blog/2005/11/01/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-11-01{% endblock %} -{% block content %}

I2P Status Notes for 2005-11-01

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -107,4 +104,3 @@ QeaqMIqTB1tvEZI3YEIQX/Y=
-{% endblock %} diff --git a/i2p2www/blog/2005/11/01/status.rst b/i2p2www/blog/2005/11/01/status.rst new file mode 100644 index 00000000..d177929e --- /dev/null +++ b/i2p2www/blog/2005/11/01/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-11-01 +=============================== + +.. raw:: html + :file: blog/2005/11/01/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-11-08.html b/i2p2www/blog/2005/11/08/status.html similarity index 95% rename from www.i2p2/pages/status-2005-11-08.html rename to i2p2www/blog/2005/11/08/status.html index da9362ff..97bf54df 100644 --- a/www.i2p2/pages/status-2005-11-08.html +++ b/i2p2www/blog/2005/11/08/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-11-08{% endblock %} -{% block content %}

I2P Status Notes for 2005-11-08

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -93,4 +90,3 @@ iD8DBQFDcQFOWYfZ3rPnHH0RAu0yAKCLMH0E31zRlByRJMoZ3MSlY0JmqwCdFIgb
-{% endblock %} diff --git a/i2p2www/blog/2005/11/08/status.rst b/i2p2www/blog/2005/11/08/status.rst new file mode 100644 index 00000000..0cf0f670 --- /dev/null +++ b/i2p2www/blog/2005/11/08/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-11-08 +=============================== + +.. raw:: html + :file: blog/2005/11/08/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-11-15.html b/i2p2www/blog/2005/11/15/status.html similarity index 95% rename from www.i2p2/pages/status-2005-11-15.html rename to i2p2www/blog/2005/11/15/status.html index a4f4d572..af6e39c7 100644 --- a/www.i2p2/pages/status-2005-11-15.html +++ b/i2p2www/blog/2005/11/15/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-11-15{% endblock %} -{% block content %}

I2P Status Notes for 2005-11-15

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -98,4 +95,3 @@ wzUvzQmeOtZhXfemCLSsuZE=
-{% endblock %} diff --git a/i2p2www/blog/2005/11/15/status.rst b/i2p2www/blog/2005/11/15/status.rst new file mode 100644 index 00000000..2ba04a91 --- /dev/null +++ b/i2p2www/blog/2005/11/15/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-11-15 +=============================== + +.. raw:: html + :file: blog/2005/11/15/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-11-22.html b/i2p2www/blog/2005/11/22/status.html similarity index 94% rename from www.i2p2/pages/status-2005-11-22.html rename to i2p2www/blog/2005/11/22/status.html index 71a3c45b..43133c27 100644 --- a/www.i2p2/pages/status-2005-11-22.html +++ b/i2p2www/blog/2005/11/22/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-11-22{% endblock %} -{% block content %}

I2P Status Notes for 2005-11-22

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -69,4 +66,3 @@ bx40VHgj3IV/F0ctUhKD540=
-{% endblock %} diff --git a/i2p2www/blog/2005/11/22/status.rst b/i2p2www/blog/2005/11/22/status.rst new file mode 100644 index 00000000..0ed78e40 --- /dev/null +++ b/i2p2www/blog/2005/11/22/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-11-22 +=============================== + +.. raw:: html + :file: blog/2005/11/22/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-11-29.html b/i2p2www/blog/2005/11/29/status.html similarity index 94% rename from www.i2p2/pages/status-2005-11-29.html rename to i2p2www/blog/2005/11/29/status.html index cfa2bdea..04a26495 100644 --- a/www.i2p2/pages/status-2005-11-29.html +++ b/i2p2www/blog/2005/11/29/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-11-29{% endblock %} -{% block content %}

I2P Status Notes for 2005-11-29

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -76,4 +73,3 @@ TGFrhg6eQyzhNa6jNV3s3bA=
-{% endblock %} diff --git a/i2p2www/blog/2005/11/29/status.rst b/i2p2www/blog/2005/11/29/status.rst new file mode 100644 index 00000000..bad917d9 --- /dev/null +++ b/i2p2www/blog/2005/11/29/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-11-29 +=============================== + +.. raw:: html + :file: blog/2005/11/29/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-12-06.html b/i2p2www/blog/2005/12/06/status.html similarity index 96% rename from www.i2p2/pages/status-2005-12-06.html rename to i2p2www/blog/2005/12/06/status.html index 4f381c10..621b9b1b 100644 --- a/www.i2p2/pages/status-2005-12-06.html +++ b/i2p2www/blog/2005/12/06/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-12-06{% endblock %} -{% block content %}

I2P Status Notes for 2005-12-06

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -101,4 +98,3 @@ I52RW2XsrcEziJHHrihfBms=
-{% endblock %} diff --git a/i2p2www/blog/2005/12/06/status.rst b/i2p2www/blog/2005/12/06/status.rst new file mode 100644 index 00000000..2e1852c6 --- /dev/null +++ b/i2p2www/blog/2005/12/06/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-12-06 +=============================== + +.. raw:: html + :file: blog/2005/12/06/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-12-13.html b/i2p2www/blog/2005/12/13/status.html similarity index 94% rename from www.i2p2/pages/status-2005-12-13.html rename to i2p2www/blog/2005/12/13/status.html index 1d87babf..6f4b1b4a 100644 --- a/www.i2p2/pages/status-2005-12-13.html +++ b/i2p2www/blog/2005/12/13/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-12-13{% endblock %} -{% block content %}

I2P Status Notes for 2005-12-13

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -75,4 +72,3 @@ RgvenKVDEEUbUMi8ePPOkuk=
-{% endblock %} diff --git a/i2p2www/blog/2005/12/13/status.rst b/i2p2www/blog/2005/12/13/status.rst new file mode 100644 index 00000000..1e6812ba --- /dev/null +++ b/i2p2www/blog/2005/12/13/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-12-13 +=============================== + +.. raw:: html + :file: blog/2005/12/13/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2005-12-20.html b/i2p2www/blog/2005/12/20/status.html similarity index 95% rename from www.i2p2/pages/status-2005-12-20.html rename to i2p2www/blog/2005/12/20/status.html index 16a90e04..c9e4b06a 100644 --- a/www.i2p2/pages/status-2005-12-20.html +++ b/i2p2www/blog/2005/12/20/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2005-12-20{% endblock %} -{% block content %}

I2P Status Notes for 2005-12-20

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -83,4 +80,3 @@ iD8DBQFDqGKDWYfZ3rPnHH0RAiHcAJ9FuF0+Pnq1DKE+phJ7tWHNHHYJAgCcDZks
-{% endblock %} diff --git a/i2p2www/blog/2005/12/20/status.rst b/i2p2www/blog/2005/12/20/status.rst new file mode 100644 index 00000000..b1664b71 --- /dev/null +++ b/i2p2www/blog/2005/12/20/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2005-12-20 +=============================== + +.. raw:: html + :file: blog/2005/12/20/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-01-03.html b/i2p2www/blog/2006/01/03/status.html similarity index 96% rename from www.i2p2/pages/status-2006-01-03.html rename to i2p2www/blog/2006/01/03/status.html index c714597d..8dc0a9eb 100644 --- a/www.i2p2/pages/status-2006-01-03.html +++ b/i2p2www/blog/2006/01/03/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-01-03{% endblock %} -{% block content %}

I2P Status Notes for 2006-01-03

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -111,4 +108,3 @@ PEKzFOKsWV54No3PoPYsd2c=
-{% endblock %} diff --git a/i2p2www/blog/2006/01/03/status.rst b/i2p2www/blog/2006/01/03/status.rst new file mode 100644 index 00000000..2b01c66c --- /dev/null +++ b/i2p2www/blog/2006/01/03/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-01-03 +=============================== + +.. raw:: html + :file: blog/2006/01/03/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-01-10.html b/i2p2www/blog/2006/01/10/status.html similarity index 97% rename from www.i2p2/pages/status-2006-01-10.html rename to i2p2www/blog/2006/01/10/status.html index 65a2235c..65dd8f13 100644 --- a/www.i2p2/pages/status-2006-01-10.html +++ b/i2p2www/blog/2006/01/10/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-01-10{% endblock %} -{% block content %}

I2P Status Notes for 2006-01-10

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -129,4 +126,3 @@ O4wXeggK4HJFFY3qioGTjlU=
-{% endblock %} diff --git a/i2p2www/blog/2006/01/10/status.rst b/i2p2www/blog/2006/01/10/status.rst new file mode 100644 index 00000000..0dd53b90 --- /dev/null +++ b/i2p2www/blog/2006/01/10/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-01-10 +=============================== + +.. raw:: html + :file: blog/2006/01/10/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-01-17.html b/i2p2www/blog/2006/01/17/status.html similarity index 96% rename from www.i2p2/pages/status-2006-01-17.html rename to i2p2www/blog/2006/01/17/status.html index 81e0b524..6d2a886e 100644 --- a/www.i2p2/pages/status-2006-01-17.html +++ b/i2p2www/blog/2006/01/17/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-01-17{% endblock %} -{% block content %}

I2P Status Notes for 2006-01-17

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -86,4 +83,3 @@ LilfUATcbuSUa0nkgev7ZDc=
-{% endblock %} diff --git a/i2p2www/blog/2006/01/17/status.rst b/i2p2www/blog/2006/01/17/status.rst new file mode 100644 index 00000000..12a3c67c --- /dev/null +++ b/i2p2www/blog/2006/01/17/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-01-17 +=============================== + +.. raw:: html + :file: blog/2006/01/17/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-01-24.html b/i2p2www/blog/2006/01/24/status.html similarity index 92% rename from www.i2p2/pages/status-2006-01-24.html rename to i2p2www/blog/2006/01/24/status.html index 51c3c966..75f08f3c 100644 --- a/www.i2p2/pages/status-2006-01-24.html +++ b/i2p2www/blog/2006/01/24/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-01-24{% endblock %} -{% block content %}

I2P Status Notes for 2006-01-24

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -60,4 +57,3 @@ MYP0IunumxNqgO2jfYaVq+M=
-{% endblock %} diff --git a/i2p2www/blog/2006/01/24/status.rst b/i2p2www/blog/2006/01/24/status.rst new file mode 100644 index 00000000..7282801d --- /dev/null +++ b/i2p2www/blog/2006/01/24/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-01-24 +=============================== + +.. raw:: html + :file: blog/2006/01/24/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-01-31.html b/i2p2www/blog/2006/01/31/status.html similarity index 93% rename from www.i2p2/pages/status-2006-01-31.html rename to i2p2www/blog/2006/01/31/status.html index 4972cae3..8d67e036 100644 --- a/www.i2p2/pages/status-2006-01-31.html +++ b/i2p2www/blog/2006/01/31/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-01-31{% endblock %} -{% block content %}

I2P Status Notes for 2006-01-31

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -64,4 +61,3 @@ trNzQYyZ2jFQ0AKihSFGE+0=
-{% endblock %} diff --git a/i2p2www/blog/2006/01/31/status.rst b/i2p2www/blog/2006/01/31/status.rst new file mode 100644 index 00000000..fbb1a4b1 --- /dev/null +++ b/i2p2www/blog/2006/01/31/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-01-31 +=============================== + +.. raw:: html + :file: blog/2006/01/31/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-02-07.html b/i2p2www/blog/2006/02/07/status.html similarity index 95% rename from www.i2p2/pages/status-2006-02-07.html rename to i2p2www/blog/2006/02/07/status.html index 5fd3a37f..a653a8c8 100644 --- a/www.i2p2/pages/status-2006-02-07.html +++ b/i2p2www/blog/2006/02/07/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-02-07{% endblock %} -{% block content %}

I2P Status Notes for 2006-02-07

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -95,4 +92,3 @@ ykoV6oDPbmUhB2CZ05EWnHs=
-{% endblock %} diff --git a/i2p2www/blog/2006/02/07/status.rst b/i2p2www/blog/2006/02/07/status.rst new file mode 100644 index 00000000..ee7ac772 --- /dev/null +++ b/i2p2www/blog/2006/02/07/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-02-07 +=============================== + +.. raw:: html + :file: blog/2006/02/07/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-02-14.html b/i2p2www/blog/2006/02/14/status.html similarity index 91% rename from www.i2p2/pages/status-2006-02-14.html rename to i2p2www/blog/2006/02/14/status.html index c21c9d33..7145113d 100644 --- a/www.i2p2/pages/status-2006-02-14.html +++ b/i2p2www/blog/2006/02/14/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-02-14{% endblock %} -{% block content %}

I2P Status Notes for 2006-02-14

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -59,4 +56,3 @@ T2YquN2BKbUfLD+ubjeFUic=
-{% endblock %} diff --git a/i2p2www/blog/2006/02/14/status.rst b/i2p2www/blog/2006/02/14/status.rst new file mode 100644 index 00000000..730ee816 --- /dev/null +++ b/i2p2www/blog/2006/02/14/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-02-14 +=============================== + +.. raw:: html + :file: blog/2006/02/14/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-02-21.html b/i2p2www/blog/2006/02/21/status.html similarity index 92% rename from www.i2p2/pages/status-2006-02-21.html rename to i2p2www/blog/2006/02/21/status.html index 8a8cbab1..dbafa845 100644 --- a/www.i2p2/pages/status-2006-02-21.html +++ b/i2p2www/blog/2006/02/21/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-02-21{% endblock %} -{% block content %}

I2P Status Notes for 2006-02-21

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -56,4 +53,3 @@ rB9c/J0H6414HlVQmOPv8Ck=
-{% endblock %} diff --git a/i2p2www/blog/2006/02/21/status.rst b/i2p2www/blog/2006/02/21/status.rst new file mode 100644 index 00000000..fc0ca375 --- /dev/null +++ b/i2p2www/blog/2006/02/21/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-02-21 +=============================== + +.. raw:: html + :file: blog/2006/02/21/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-02-28.html b/i2p2www/blog/2006/02/28/status.html similarity index 95% rename from www.i2p2/pages/status-2006-02-28.html rename to i2p2www/blog/2006/02/28/status.html index 739aafcd..d46e1732 100644 --- a/www.i2p2/pages/status-2006-02-28.html +++ b/i2p2www/blog/2006/02/28/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-02-28{% endblock %} -{% block content %}

I2P Status Notes for 2006-02-28

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -88,4 +85,3 @@ rALo7pJF3TQlZYXxikyKBaI=
-{% endblock %} diff --git a/i2p2www/blog/2006/02/28/status.rst b/i2p2www/blog/2006/02/28/status.rst new file mode 100644 index 00000000..a41d17f1 --- /dev/null +++ b/i2p2www/blog/2006/02/28/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-02-28 +=============================== + +.. raw:: html + :file: blog/2006/02/28/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-03-07.html b/i2p2www/blog/2006/03/07/status.html similarity index 88% rename from www.i2p2/pages/status-2006-03-07.html rename to i2p2www/blog/2006/03/07/status.html index ea9689a8..c3676872 100644 --- a/www.i2p2/pages/status-2006-03-07.html +++ b/i2p2www/blog/2006/03/07/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-03-07{% endblock %} -{% block content %}

I2P Status Notes for 2006-03-07

Hey y'all, a brief weekly update this time
 
 * Index
@@ -38,4 +35,3 @@ meeting to say hey!
-{% endblock %} diff --git a/i2p2www/blog/2006/03/07/status.rst b/i2p2www/blog/2006/03/07/status.rst new file mode 100644 index 00000000..f707cea9 --- /dev/null +++ b/i2p2www/blog/2006/03/07/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-03-07 +=============================== + +.. raw:: html + :file: blog/2006/03/07/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-03-14.html b/i2p2www/blog/2006/03/14/status.html similarity index 89% rename from www.i2p2/pages/status-2006-03-14.html rename to i2p2www/blog/2006/03/14/status.html index b870b369..aa2ecb05 100644 --- a/www.i2p2/pages/status-2006-03-14.html +++ b/i2p2www/blog/2006/03/14/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-03-14{% endblock %} -{% block content %}

I2P Status Notes for 2006-03-14

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -45,4 +42,3 @@ DIheXOEdcTPMGnDH4cbK8E0=
-{% endblock %} diff --git a/i2p2www/blog/2006/03/14/status.rst b/i2p2www/blog/2006/03/14/status.rst new file mode 100644 index 00000000..9c0f038c --- /dev/null +++ b/i2p2www/blog/2006/03/14/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-03-14 +=============================== + +.. raw:: html + :file: blog/2006/03/14/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-03-21.html b/i2p2www/blog/2006/03/21/status.html similarity index 93% rename from www.i2p2/pages/status-2006-03-21.html rename to i2p2www/blog/2006/03/21/status.html index 6504bb50..d51aad97 100644 --- a/www.i2p2/pages/status-2006-03-21.html +++ b/i2p2www/blog/2006/03/21/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-03-21{% endblock %} -{% block content %}

I2P Status Notes for 2006-03-21

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -71,4 +68,3 @@ TTD/4/BorP0cK1ycO/CBhoU=
-{% endblock %} diff --git a/i2p2www/blog/2006/03/21/status.rst b/i2p2www/blog/2006/03/21/status.rst new file mode 100644 index 00000000..d28d48a0 --- /dev/null +++ b/i2p2www/blog/2006/03/21/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-03-21 +=============================== + +.. raw:: html + :file: blog/2006/03/21/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-03-28.html b/i2p2www/blog/2006/03/28/status.html similarity index 90% rename from www.i2p2/pages/status-2006-03-28.html rename to i2p2www/blog/2006/03/28/status.html index 0a36fd71..5b851484 100644 --- a/www.i2p2/pages/status-2006-03-28.html +++ b/i2p2www/blog/2006/03/28/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-03-28{% endblock %} -{% block content %}

I2P Status Notes for 2006-03-28

Hi y'all, tuesday rolls around again
 
 * Index
@@ -49,4 +46,3 @@ meeting!
-{% endblock %} diff --git a/i2p2www/blog/2006/03/28/status.rst b/i2p2www/blog/2006/03/28/status.rst new file mode 100644 index 00000000..f5f0fdbf --- /dev/null +++ b/i2p2www/blog/2006/03/28/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-03-28 +=============================== + +.. raw:: html + :file: blog/2006/03/28/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-04-04.html b/i2p2www/blog/2006/04/04/status.html similarity index 90% rename from www.i2p2/pages/status-2006-04-04.html rename to i2p2www/blog/2006/04/04/status.html index 2cca11cd..bccbeb5f 100644 --- a/www.i2p2/pages/status-2006-04-04.html +++ b/i2p2www/blog/2006/04/04/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-04-04{% endblock %} -{% block content %}

I2P Status Notes for 2006-04-04

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -52,4 +49,3 @@ Gr8i0t2hse2x0/FbsYlNsqw=
-{% endblock %} diff --git a/i2p2www/blog/2006/04/04/status.rst b/i2p2www/blog/2006/04/04/status.rst new file mode 100644 index 00000000..87350d0a --- /dev/null +++ b/i2p2www/blog/2006/04/04/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-04-04 +=============================== + +.. raw:: html + :file: blog/2006/04/04/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-04-18.html b/i2p2www/blog/2006/04/18/status.html similarity index 94% rename from www.i2p2/pages/status-2006-04-18.html rename to i2p2www/blog/2006/04/18/status.html index 62400c30..40ec5b34 100644 --- a/www.i2p2/pages/status-2006-04-18.html +++ b/i2p2www/blog/2006/04/18/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-04-18{% endblock %} -{% block content %}

I2P Status Notes for 2006-04-18

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -78,4 +75,3 @@ nFrLMyhEQRCexJgH5VI2T38=
-{% endblock %} diff --git a/i2p2www/blog/2006/04/18/status.rst b/i2p2www/blog/2006/04/18/status.rst new file mode 100644 index 00000000..ee7f6a75 --- /dev/null +++ b/i2p2www/blog/2006/04/18/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-04-18 +=============================== + +.. raw:: html + :file: blog/2006/04/18/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-04-25.html b/i2p2www/blog/2006/04/25/status.html similarity index 90% rename from www.i2p2/pages/status-2006-04-25.html rename to i2p2www/blog/2006/04/25/status.html index a1285445..ccc507ed 100644 --- a/www.i2p2/pages/status-2006-04-25.html +++ b/i2p2www/blog/2006/04/25/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-04-25{% endblock %} -{% block content %}

I2P Status Notes for 2006-04-25

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -51,4 +48,3 @@ VqtP1RdoT8SGPs/OqC0vdHE=
-{% endblock %} diff --git a/i2p2www/blog/2006/04/25/status.rst b/i2p2www/blog/2006/04/25/status.rst new file mode 100644 index 00000000..badcd780 --- /dev/null +++ b/i2p2www/blog/2006/04/25/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-04-25 +=============================== + +.. raw:: html + :file: blog/2006/04/25/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-05-02.html b/i2p2www/blog/2006/05/02/status.html similarity index 91% rename from www.i2p2/pages/status-2006-05-02.html rename to i2p2www/blog/2006/05/02/status.html index a110172c..a22cecd2 100644 --- a/www.i2p2/pages/status-2006-05-02.html +++ b/i2p2www/blog/2006/05/02/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-05-02{% endblock %} -{% block content %}

I2P Status Notes for 2006-05-02

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -53,4 +50,3 @@ edLqQiDWEyqoe0GsYGIYLCU=
-{% endblock %} diff --git a/i2p2www/blog/2006/05/02/status.rst b/i2p2www/blog/2006/05/02/status.rst new file mode 100644 index 00000000..dc584295 --- /dev/null +++ b/i2p2www/blog/2006/05/02/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-05-02 +=============================== + +.. raw:: html + :file: blog/2006/05/02/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-05-09.html b/i2p2www/blog/2006/05/09/status.html similarity index 94% rename from www.i2p2/pages/status-2006-05-09.html rename to i2p2www/blog/2006/05/09/status.html index de512cab..a075bb0e 100644 --- a/www.i2p2/pages/status-2006-05-09.html +++ b/i2p2www/blog/2006/05/09/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-05-09{% endblock %} -{% block content %}

I2P Status Notes for 2006-05-09

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -69,4 +66,3 @@ VDUPoPbUGi8bVf/h7Ao6jtY=
-{% endblock %} diff --git a/i2p2www/blog/2006/05/09/status.rst b/i2p2www/blog/2006/05/09/status.rst new file mode 100644 index 00000000..95db2ce6 --- /dev/null +++ b/i2p2www/blog/2006/05/09/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-05-09 +=============================== + +.. raw:: html + :file: blog/2006/05/09/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-05-16.html b/i2p2www/blog/2006/05/16/status.html similarity index 82% rename from www.i2p2/pages/status-2006-05-16.html rename to i2p2www/blog/2006/05/16/status.html index f0a32a7d..7b756b51 100644 --- a/www.i2p2/pages/status-2006-05-16.html +++ b/i2p2www/blog/2006/05/16/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-05-16{% endblock %} -{% block content %}

I2P Status Notes for 2006-05-16

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -27,4 +24,3 @@ r1U4JJaXClSyISpVf1uly2c=
-{% endblock %} diff --git a/i2p2www/blog/2006/05/16/status.rst b/i2p2www/blog/2006/05/16/status.rst new file mode 100644 index 00000000..6c0de94e --- /dev/null +++ b/i2p2www/blog/2006/05/16/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-05-16 +=============================== + +.. raw:: html + :file: blog/2006/05/16/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-05-30.html b/i2p2www/blog/2006/05/30/status.html similarity index 89% rename from www.i2p2/pages/status-2006-05-30.html rename to i2p2www/blog/2006/05/30/status.html index e828bc70..c3f8deb4 100644 --- a/www.i2p2/pages/status-2006-05-30.html +++ b/i2p2www/blog/2006/05/30/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-05-30{% endblock %} -{% block content %}

I2P Status Notes for 2006-05-30

Hi y'all, after a brief intermission, its time for our weekly status
 notes again (unsigned for system maintenance reasons)
 
@@ -48,4 +45,3 @@ anything they'd like to discuss, please swing on by #i2p tonight at
-{% endblock %} diff --git a/i2p2www/blog/2006/05/30/status.rst b/i2p2www/blog/2006/05/30/status.rst new file mode 100644 index 00000000..1b6c3461 --- /dev/null +++ b/i2p2www/blog/2006/05/30/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-05-30 +=============================== + +.. raw:: html + :file: blog/2006/05/30/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-06-13.html b/i2p2www/blog/2006/06/13/status.html similarity index 85% rename from www.i2p2/pages/status-2006-06-13.html rename to i2p2www/blog/2006/06/13/status.html index 454c5501..e79001bd 100644 --- a/www.i2p2/pages/status-2006-06-13.html +++ b/i2p2www/blog/2006/06/13/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-06-13{% endblock %} -{% block content %}

I2P Status Notes for 2006-06-13

Hi gang, 'tis tuesday again,
 
 * Index
@@ -36,4 +33,3 @@ for our meeting to say hey!
-{% endblock %} diff --git a/i2p2www/blog/2006/06/13/status.rst b/i2p2www/blog/2006/06/13/status.rst new file mode 100644 index 00000000..5d088f21 --- /dev/null +++ b/i2p2www/blog/2006/06/13/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-06-13 +=============================== + +.. raw:: html + :file: blog/2006/06/13/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-08-01.html b/i2p2www/blog/2006/08/01/status.html similarity index 91% rename from www.i2p2/pages/status-2006-08-01.html rename to i2p2www/blog/2006/08/01/status.html index aa29d512..7e4cf223 100644 --- a/www.i2p2/pages/status-2006-08-01.html +++ b/i2p2www/blog/2006/08/01/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-08-01{% endblock %} -{% block content %}

I2P Status Notes for 2006-08-01

Hi y'all, time for a brief set of notes before tonight's meeting.
 I realize that you may have a variety of questions or issues to
 bring up, so we'll go in a more fluid format than usual.  There
@@ -46,4 +43,3 @@ Thanks for your help moving us forward!
-{% endblock %} diff --git a/i2p2www/blog/2006/08/01/status.rst b/i2p2www/blog/2006/08/01/status.rst new file mode 100644 index 00000000..2f0d4906 --- /dev/null +++ b/i2p2www/blog/2006/08/01/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-08-01 +=============================== + +.. raw:: html + :file: blog/2006/08/01/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-09-12.html b/i2p2www/blog/2006/09/12/status.html similarity index 98% rename from www.i2p2/pages/status-2006-09-12.html rename to i2p2www/blog/2006/09/12/status.html index 97545fa9..a30f8d23 100644 --- a/www.i2p2/pages/status-2006-09-12.html +++ b/i2p2www/blog/2006/09/12/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-09-12{% endblock %} -{% block content %}

I2P Status Notes for 2006-09-12

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -265,4 +262,3 @@ esxfTWz6qhtpyTUqsmoNlB4=
-{% endblock %} diff --git a/i2p2www/blog/2006/09/12/status.rst b/i2p2www/blog/2006/09/12/status.rst new file mode 100644 index 00000000..8cd7f146 --- /dev/null +++ b/i2p2www/blog/2006/09/12/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-09-12 +=============================== + +.. raw:: html + :file: blog/2006/09/12/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-10-03.html b/i2p2www/blog/2006/10/03/status.html similarity index 98% rename from www.i2p2/pages/status-2006-10-03.html rename to i2p2www/blog/2006/10/03/status.html index 80241e13..85e5ca30 100644 --- a/www.i2p2/pages/status-2006-10-03.html +++ b/i2p2www/blog/2006/10/03/status.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-10-03{% endblock %} -{% block content %}

I2P Status Notes for 2006-10-03

-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -260,4 +257,3 @@ H/X9NBh7t6KTc9dibqLdgow=
-{% endblock %} diff --git a/i2p2www/blog/2006/10/03/status.rst b/i2p2www/blog/2006/10/03/status.rst new file mode 100644 index 00000000..7cd965b1 --- /dev/null +++ b/i2p2www/blog/2006/10/03/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2006-10-03 +=============================== + +.. raw:: html + :file: blog/2006/10/03/status.html \ No newline at end of file diff --git a/www.i2p2/pages/status-2006-10-10.html b/i2p2www/blog/2006/10/10/status.html similarity index 94% rename from www.i2p2/pages/status-2006-10-10.html rename to i2p2www/blog/2006/10/10/status.html index 6578b642..a3c787e3 100644 --- a/www.i2p2/pages/status-2006-10-10.html +++ b/i2p2www/blog/2006/10/10/status.html @@ -1,7 +1,5 @@ -{% extends "_layout.html" %} -{% block title %}I2P Status Notes for 2006-10-10{% endblock %} -{% block content %}

I2P Status Notes for 2006-10-10

-
-----BEGIN PGP SIGNED MESSAGE-----
+
+-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Hi y'all, brief status notes this week
@@ -79,7 +77,4 @@ iD8DBQFFK6hgzgi8JTPcjUkRAuG2AJ46vK/13GIEngzQe05KRuEP2ZYvRQCeJB3j
 VmEzybBbtZSpSrFcU4qdvks=
 =QlDy
 -----END PGP SIGNATURE-----
-
-
 

-{% endblock %}
diff --git a/i2p2www/blog/2006/10/10/status.rst b/i2p2www/blog/2006/10/10/status.rst
new file mode 100644
index 00000000..b77847b7
--- /dev/null
+++ b/i2p2www/blog/2006/10/10/status.rst
@@ -0,0 +1,6 @@
+===============================
+I2P STATUS NOTES FOR 2006-10-10
+===============================
+
+.. raw:: html
+   :file: blog/2006/10/10/status.html
diff --git a/i2p2www/blog/2007/10/07/0.6.1.30-Release.rst b/i2p2www/blog/2007/10/07/0.6.1.30-Release.rst
new file mode 100644
index 00000000..a7b4bfcb
--- /dev/null
+++ b/i2p2www/blog/2007/10/07/0.6.1.30-Release.rst
@@ -0,0 +1,6 @@
+================
+0.6.1.30 Release
+================
+
+.. raw:: html
+   :file: blog/2007/10/07/release-0.6.1.30.html
diff --git a/www.i2p2/pages/release-0.6.1.30.html b/i2p2www/blog/2007/10/07/release-0.6.1.30.html
similarity index 87%
rename from www.i2p2/pages/release-0.6.1.30.html
rename to i2p2www/blog/2007/10/07/release-0.6.1.30.html
index e24670db..ecb8583c 100644
--- a/www.i2p2/pages/release-0.6.1.30.html
+++ b/i2p2www/blog/2007/10/07/release-0.6.1.30.html
@@ -1,6 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}0.6.1.30 Release{% endblock %}
-{% block content %}
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -28,4 +25,3 @@ C5c5uUMKct7SwyqWArEyx2I=
 =WZ3+
 -----END PGP SIGNATURE-----
 

-{% endblock %}
diff --git a/www.i2p2/pages/statnotes0108.html b/i2p2www/blog/2008/02/01/status.html
similarity index 89%
rename from www.i2p2/pages/statnotes0108.html
rename to i2p2www/blog/2008/02/01/status.html
index 4c069b79..a7aec701 100644
--- a/www.i2p2/pages/statnotes0108.html
+++ b/i2p2www/blog/2008/02/01/status.html
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}Status update 01 2008{% endblock %}
-{% block content %}
New Information about situation in I2P for start of 2008.

-
 
 
 Welcome!
@@ -35,5 +31,4 @@ replacement of i2p.net.
 Sorry for the inconvenience the last month but we were hit unprepared and spent our rare spare
 time to give you the best experience we could offer.
 
-

-{% endblock %}
+
diff --git a/i2p2www/blog/2008/02/01/status.rst b/i2p2www/blog/2008/02/01/status.rst new file mode 100644 index 00000000..e2b71380 --- /dev/null +++ b/i2p2www/blog/2008/02/01/status.rst @@ -0,0 +1,6 @@ +=============================== +I2P STATUS NOTES FOR 2008-02-01 +=============================== + +.. raw:: html + :file: blog/2008/02/01/status.html \ No newline at end of file diff --git a/i2p2www/blog/2008/02/10/0.6.1.31-Release.rst b/i2p2www/blog/2008/02/10/0.6.1.31-Release.rst new file mode 100644 index 00000000..151f393f --- /dev/null +++ b/i2p2www/blog/2008/02/10/0.6.1.31-Release.rst @@ -0,0 +1,6 @@ +================ +0.6.1.31 Release +================ + +.. raw:: html + :file: blog/2008/02/10/release-0.6.1.31.html diff --git a/www.i2p2/pages/release-0.6.1.31.html b/i2p2www/blog/2008/02/10/release-0.6.1.31.html similarity index 92% rename from www.i2p2/pages/release-0.6.1.31.html rename to i2p2www/blog/2008/02/10/release-0.6.1.31.html index 6de24474..05ec0ccb 100644 --- a/www.i2p2/pages/release-0.6.1.31.html +++ b/i2p2www/blog/2008/02/10/release-0.6.1.31.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.6.1.31 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -43,4 +40,3 @@ DgDzhyGCLCMWps4ibp7w4ZM=
 =T9GN
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2008/03/09/0.6.1.32-Release.rst b/i2p2www/blog/2008/03/09/0.6.1.32-Release.rst new file mode 100644 index 00000000..401980ea --- /dev/null +++ b/i2p2www/blog/2008/03/09/0.6.1.32-Release.rst @@ -0,0 +1,6 @@ +================ +0.6.1.32 Release +================ + +.. raw:: html + :file: blog/2008/03/09/release-0.6.1.32.html diff --git a/www.i2p2/pages/release-0.6.1.32.html b/i2p2www/blog/2008/03/09/release-0.6.1.32.html similarity index 94% rename from www.i2p2/pages/release-0.6.1.32.html rename to i2p2www/blog/2008/03/09/release-0.6.1.32.html index 3cba4088..268f3ef8 100644 --- a/www.i2p2/pages/release-0.6.1.32.html +++ b/i2p2www/blog/2008/03/09/release-0.6.1.32.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.6.1.32 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -55,4 +52,3 @@ E+npcvwX3Y4q5oAD4t9RUBI=
 =EaFf
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2008/04/26/0.6.1.33-Release.rst b/i2p2www/blog/2008/04/26/0.6.1.33-Release.rst new file mode 100644 index 00000000..a7a1dd76 --- /dev/null +++ b/i2p2www/blog/2008/04/26/0.6.1.33-Release.rst @@ -0,0 +1,6 @@ +================ +0.6.1.33 Release +================ + +.. raw:: html + :file: blog/2008/04/26/release-0.6.1.33.html diff --git a/www.i2p2/pages/release-0.6.1.33.html b/i2p2www/blog/2008/04/26/release-0.6.1.33.html similarity index 92% rename from www.i2p2/pages/release-0.6.1.33.html rename to i2p2www/blog/2008/04/26/release-0.6.1.33.html index 8d20ba93..864c6152 100644 --- a/www.i2p2/pages/release-0.6.1.33.html +++ b/i2p2www/blog/2008/04/26/release-0.6.1.33.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.6.1.33 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -41,4 +38,3 @@ iD8DBQFIE5cv+h38a3n8zjMRAiNhAJ4o+6vL/Yd7TlUoU1pevLGXGCsa4gCgiEDK
 =Yac6
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2008/06/07/0.6.2-Release.rst b/i2p2www/blog/2008/06/07/0.6.2-Release.rst new file mode 100644 index 00000000..4eb68369 --- /dev/null +++ b/i2p2www/blog/2008/06/07/0.6.2-Release.rst @@ -0,0 +1,6 @@ +============= +0.6.2 Release +============= + +.. raw:: html + :file: blog/2008/06/07/release-0.6.2.html diff --git a/www.i2p2/pages/release-0.6.2.html b/i2p2www/blog/2008/06/07/release-0.6.2.html similarity index 93% rename from www.i2p2/pages/release-0.6.2.html rename to i2p2www/blog/2008/06/07/release-0.6.2.html index 515d74d1..a45cefbe 100644 --- a/www.i2p2/pages/release-0.6.2.html +++ b/i2p2www/blog/2008/06/07/release-0.6.2.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.6.2 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -47,4 +44,3 @@ AqL1Wz/jN7hRUPXLRhPJTGw=
 =u9me
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2008/08/26/0.6.3-Release.rst b/i2p2www/blog/2008/08/26/0.6.3-Release.rst new file mode 100644 index 00000000..5c6e345a --- /dev/null +++ b/i2p2www/blog/2008/08/26/0.6.3-Release.rst @@ -0,0 +1,6 @@ +============= +0.6.3 Release +============= + +.. raw:: html + :file: blog/2008/08/26/release-0.6.3.html diff --git a/www.i2p2/pages/release-0.6.3.html b/i2p2www/blog/2008/08/26/release-0.6.3.html similarity index 93% rename from www.i2p2/pages/release-0.6.3.html rename to i2p2www/blog/2008/08/26/release-0.6.3.html index 3b5ec584..5ced76f8 100644 --- a/www.i2p2/pages/release-0.6.3.html +++ b/i2p2www/blog/2008/08/26/release-0.6.3.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.6.3 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -45,4 +42,3 @@ iD8DBQFIsTvl+h38a3n8zjMRAi2GAJ9HAwg9JBWIjkHcvR8SHw95FcYnngCfQL+w
 =5P8t
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2008/10/06/0.6.4-Release.rst b/i2p2www/blog/2008/10/06/0.6.4-Release.rst new file mode 100644 index 00000000..a2451931 --- /dev/null +++ b/i2p2www/blog/2008/10/06/0.6.4-Release.rst @@ -0,0 +1,6 @@ +============= +0.6.4 Release +============= + +.. raw:: html + :file: blog/2008/10/06/release-0.6.4.html diff --git a/www.i2p2/pages/release-0.6.4.html b/i2p2www/blog/2008/10/06/release-0.6.4.html similarity index 93% rename from www.i2p2/pages/release-0.6.4.html rename to i2p2www/blog/2008/10/06/release-0.6.4.html index 08b5d07c..456c3b05 100644 --- a/www.i2p2/pages/release-0.6.4.html +++ b/i2p2www/blog/2008/10/06/release-0.6.4.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.6.4 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -46,4 +43,3 @@ ceYAn0BoC7N/Er34EG361tdrG8qT9WpQ
 =hG2h
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2008/12/01/0.6.5-Release.rst b/i2p2www/blog/2008/12/01/0.6.5-Release.rst new file mode 100644 index 00000000..98f996b0 --- /dev/null +++ b/i2p2www/blog/2008/12/01/0.6.5-Release.rst @@ -0,0 +1,6 @@ +============= +0.6.5 Release +============= + +.. raw:: html + :file: blog/2008/12/01/release-0.6.5.html diff --git a/www.i2p2/pages/release-0.6.5.html b/i2p2www/blog/2008/12/01/release-0.6.5.html similarity index 94% rename from www.i2p2/pages/release-0.6.5.html rename to i2p2www/blog/2008/12/01/release-0.6.5.html index da4df26f..d7d51c52 100644 --- a/www.i2p2/pages/release-0.6.5.html +++ b/i2p2www/blog/2008/12/01/release-0.6.5.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.6.5 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -57,4 +54,3 @@ clQAnRbuoYUa8qPiea7fCxOsGKsJMMCL
 =STLb
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2009/01/25/0.7-Release.rst b/i2p2www/blog/2009/01/25/0.7-Release.rst new file mode 100644 index 00000000..441a3c14 --- /dev/null +++ b/i2p2www/blog/2009/01/25/0.7-Release.rst @@ -0,0 +1,6 @@ +============= +0.7 Release +============= + +.. raw:: html + :file: blog/2009/01/25/release-0.7.html diff --git a/www.i2p2/pages/release-0.7.html b/i2p2www/blog/2009/01/25/release-0.7.html similarity index 95% rename from www.i2p2/pages/release-0.7.html rename to i2p2www/blog/2009/01/25/release-0.7.html index a10547f5..24a2b2d6 100644 --- a/www.i2p2/pages/release-0.7.html +++ b/i2p2www/blog/2009/01/25/release-0.7.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -56,4 +53,3 @@ UkgAn1HqnG8FOuN84l3gShE3PVfDAVNS
 =TxoZ
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2009/03/29/0.7.1-Release.rst b/i2p2www/blog/2009/03/29/0.7.1-Release.rst new file mode 100644 index 00000000..e1533108 --- /dev/null +++ b/i2p2www/blog/2009/03/29/0.7.1-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.1 Release +============= + +.. raw:: html + :file: blog/2009/03/29/release-0.7.1.html diff --git a/www.i2p2/pages/release-0.7.1.html b/i2p2www/blog/2009/03/29/release-0.7.1.html similarity index 93% rename from www.i2p2/pages/release-0.7.1.html rename to i2p2www/blog/2009/03/29/release-0.7.1.html index 38a9c176..1e8e9500 100644 --- a/www.i2p2/pages/release-0.7.1.html +++ b/i2p2www/blog/2009/03/29/release-0.7.1.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.1 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -47,4 +44,3 @@ iEYEARECAAYFAknP3UQACgkQ+h38a3n8zjNTwwCcCBDoS6Lqz7rpuNFx4ilSO6fb
 =BBsy
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2009/04/19/0.7.2-Release.rst b/i2p2www/blog/2009/04/19/0.7.2-Release.rst new file mode 100644 index 00000000..c4219fad --- /dev/null +++ b/i2p2www/blog/2009/04/19/0.7.2-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.2 Release +============= + +.. raw:: html + :file: blog/2009/04/19/release-0.7.2.html diff --git a/www.i2p2/pages/release-0.7.2.html b/i2p2www/blog/2009/04/19/release-0.7.2.html similarity index 93% rename from www.i2p2/pages/release-0.7.2.html rename to i2p2www/blog/2009/04/19/release-0.7.2.html index f7269d0f..0382fff9 100644 --- a/www.i2p2/pages/release-0.7.2.html +++ b/i2p2www/blog/2009/04/19/release-0.7.2.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.2 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -47,4 +44,3 @@ HZMAn15tFbcHh2xE+HyZOT1EOctYZHK/
 =RpcD
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2009/05/18/0.7.3-Release.rst b/i2p2www/blog/2009/05/18/0.7.3-Release.rst new file mode 100644 index 00000000..26b6bba8 --- /dev/null +++ b/i2p2www/blog/2009/05/18/0.7.3-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.3 Release +============= + +.. raw:: html + :file: blog/2009/05/18/release-0.7.3.html diff --git a/www.i2p2/pages/release-0.7.3.html b/i2p2www/blog/2009/05/18/release-0.7.3.html similarity index 93% rename from www.i2p2/pages/release-0.7.3.html rename to i2p2www/blog/2009/05/18/release-0.7.3.html index 6a807132..e4b5a732 100644 --- a/www.i2p2/pages/release-0.7.3.html +++ b/i2p2www/blog/2009/05/18/release-0.7.3.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.3 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -44,4 +41,3 @@ Cy0An372IlJMf/E+dHE9ssiH4DoTi57q
 =7SfN
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2009/06/13/0.7.4-Release.rst b/i2p2www/blog/2009/06/13/0.7.4-Release.rst new file mode 100644 index 00000000..c26c6e17 --- /dev/null +++ b/i2p2www/blog/2009/06/13/0.7.4-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.4 Release +============= + +.. raw:: html + :file: blog/2009/06/13/release-0.7.4.html diff --git a/www.i2p2/pages/release-0.7.4.html b/i2p2www/blog/2009/06/13/release-0.7.4.html similarity index 93% rename from www.i2p2/pages/release-0.7.4.html rename to i2p2www/blog/2009/06/13/release-0.7.4.html index 937f5c4a..7adef4b2 100644 --- a/www.i2p2/pages/release-0.7.4.html +++ b/i2p2www/blog/2009/06/13/release-0.7.4.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.4 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -44,4 +41,3 @@ gc8An3/HFievfAvorlpm2GzzZE57KVIy
 =xe6x
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2009/06/29/0.7.5-Release.rst b/i2p2www/blog/2009/06/29/0.7.5-Release.rst new file mode 100644 index 00000000..ee552e52 --- /dev/null +++ b/i2p2www/blog/2009/06/29/0.7.5-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.5 Release +============= + +.. raw:: html + :file: blog/2009/06/29/release-0.7.5.html diff --git a/www.i2p2/pages/release-0.7.5.html b/i2p2www/blog/2009/06/29/release-0.7.5.html similarity index 95% rename from www.i2p2/pages/release-0.7.5.html rename to i2p2www/blog/2009/06/29/release-0.7.5.html index a776f1b6..ceb69ac0 100644 --- a/www.i2p2/pages/release-0.7.5.html +++ b/i2p2www/blog/2009/06/29/release-0.7.5.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.5 Release{% endblock %} -{% block content %} 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -66,4 +63,3 @@ gk8AoIU30WJSxJmFo5FTDYRDc605HBgw
 =5I+4
 -----END PGP SIGNATURE-----
-{% endblock %} diff --git a/i2p2www/blog/2009/07/31/0.7.6-Release.rst b/i2p2www/blog/2009/07/31/0.7.6-Release.rst new file mode 100644 index 00000000..3569473f --- /dev/null +++ b/i2p2www/blog/2009/07/31/0.7.6-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.6 Release +============= + +.. raw:: html + :file: blog/2009/07/31/release-0.7.6.html diff --git a/www.i2p2/pages/release-0.7.6.html b/i2p2www/blog/2009/07/31/release-0.7.6.html similarity index 97% rename from www.i2p2/pages/release-0.7.6.html rename to i2p2www/blog/2009/07/31/release-0.7.6.html index 22407569..88e1e38a 100644 --- a/www.i2p2/pages/release-0.7.6.html +++ b/i2p2www/blog/2009/07/31/release-0.7.6.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.6 Release{% endblock %} -{% block content %}

I2P version 0.7.6 contains additional fixes for network stability issues related to tunnel building and connection limits. @@ -105,4 +102,3 @@ SHA256 Checksums: e799ef916871c12d0c53ade577fe2ab89feb138589b9dd312a38f35f31c45bff i2pupdate_0.7.6.zip e4605534e5accec9956c2204c547486ad5a3cca57597f2a44665c49cdf9dede3 i2pupdate.sud -{% endblock %} diff --git a/i2p2www/blog/2009/10/12/0.7.7-Release.rst b/i2p2www/blog/2009/10/12/0.7.7-Release.rst new file mode 100644 index 00000000..37db0f7d --- /dev/null +++ b/i2p2www/blog/2009/10/12/0.7.7-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.7 Release +============= + +.. raw:: html + :file: blog/2009/10/12/release-0.7.7.html diff --git a/www.i2p2/pages/release-0.7.7.html b/i2p2www/blog/2009/10/12/release-0.7.7.html similarity index 95% rename from www.i2p2/pages/release-0.7.7.html rename to i2p2www/blog/2009/10/12/release-0.7.7.html index ac16aace..924ea060 100644 --- a/www.i2p2/pages/release-0.7.7.html +++ b/i2p2www/blog/2009/10/12/release-0.7.7.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.7 Release{% endblock %} -{% block content %}

I2P version 0.7.7 contains several anonymity improvements. The use of session keys for crypto was completely reworked, @@ -69,4 +66,3 @@ SHA256 Checksums: f57fab38141f652dffcd1073dce16ac5fb151645439fd6038141552333d2d179 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2009/12/08/0.7.8-Release.rst b/i2p2www/blog/2009/12/08/0.7.8-Release.rst new file mode 100644 index 00000000..4930c1a6 --- /dev/null +++ b/i2p2www/blog/2009/12/08/0.7.8-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.8 Release +============= + +.. raw:: html + :file: blog/2009/12/08/release-0.7.8.html diff --git a/www.i2p2/pages/release-0.7.8.html b/i2p2www/blog/2009/12/08/release-0.7.8.html similarity index 97% rename from www.i2p2/pages/release-0.7.8.html rename to i2p2www/blog/2009/12/08/release-0.7.8.html index 764a4957..bf21c3a4 100644 --- a/www.i2p2/pages/release-0.7.8.html +++ b/i2p2www/blog/2009/12/08/release-0.7.8.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.8 Release{% endblock %} -{% block content %}

Release 0.7.8 contains initial support for router console translations, and changes to the floodfill system which lay the foundation for supporting large growth in the network. @@ -73,4 +70,3 @@ e0a3efbcba2e58aed97e7246fe3a604809ebf90ecdc3b274e000401fd743adc0 i2pinstall_0.7 94b805afb93f659e2896ed3b1607133bd5fcc9568198acc6c5970b3d2bb53481 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/01/12/0.7.9-Release.rst b/i2p2www/blog/2010/01/12/0.7.9-Release.rst new file mode 100644 index 00000000..19d8385a --- /dev/null +++ b/i2p2www/blog/2010/01/12/0.7.9-Release.rst @@ -0,0 +1,6 @@ +============= +0.7.9 Release +============= + +.. raw:: html + :file: blog/2010/01/12/release-0.7.9.html diff --git a/www.i2p2/pages/release-0.7.9.html b/i2p2www/blog/2010/01/12/release-0.7.9.html similarity index 96% rename from www.i2p2/pages/release-0.7.9.html rename to i2p2www/blog/2010/01/12/release-0.7.9.html index 7eecab53..49b44167 100644 --- a/www.i2p2/pages/release-0.7.9.html +++ b/i2p2www/blog/2010/01/12/release-0.7.9.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.9 Release{% endblock %} -{% block content %}

0.7.9 fixes several longstanding bugs causing message corruption. We are hopeful that network performance will improve once it is widely deployed. @@ -65,4 +62,3 @@ cd2e113ee205c7d33b18920ca1e853d18fecd0f79e30c74a9c20c79cbb553889 i2pupdate_0.7. eb995184206fcd54880d1c15c792a0a0d47c46fad19a8d409ab9fdca345f58e2 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/01/22/0.7.10-Release.rst b/i2p2www/blog/2010/01/22/0.7.10-Release.rst new file mode 100644 index 00000000..cbf601e6 --- /dev/null +++ b/i2p2www/blog/2010/01/22/0.7.10-Release.rst @@ -0,0 +1,6 @@ +============== +0.7.10 Release +============== + +.. raw:: html + :file: blog/2010/01/22/release-0.7.10.html diff --git a/www.i2p2/pages/release-0.7.10.html b/i2p2www/blog/2010/01/22/release-0.7.10.html similarity index 91% rename from www.i2p2/pages/release-0.7.10.html rename to i2p2www/blog/2010/01/22/release-0.7.10.html index 4fa5a9ae..d9cc2bff 100644 --- a/www.i2p2/pages/release-0.7.10.html +++ b/i2p2www/blog/2010/01/22/release-0.7.10.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.10 Release{% endblock %} -{% block content %}

0.7.10 closes some recently-discovered vulnerabilities related to the way routers communicate with floodfill peers. @@ -28,4 +25,3 @@ c003efa3e66e0a874246376fa7213b4309b8472207c43ec9a307cc0c19a8f114 i2pinstall_0.7 47dce43bb793f11c8206d0f39cbda1b49b28d535b51d878a7f4c61e4f8a74c71 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/02/15/0.7.11-Release.rst b/i2p2www/blog/2010/02/15/0.7.11-Release.rst new file mode 100644 index 00000000..a35787f3 --- /dev/null +++ b/i2p2www/blog/2010/02/15/0.7.11-Release.rst @@ -0,0 +1,6 @@ +============== +0.7.11 Release +============== + +.. raw:: html + :file: blog/2010/02/15/release-0.7.11.html diff --git a/www.i2p2/pages/release-0.7.11.html b/i2p2www/blog/2010/02/15/release-0.7.11.html similarity index 95% rename from www.i2p2/pages/release-0.7.11.html rename to i2p2www/blog/2010/02/15/release-0.7.11.html index f3724905..bceb8249 100644 --- a/www.i2p2/pages/release-0.7.11.html +++ b/i2p2www/blog/2010/02/15/release-0.7.11.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.11 Release{% endblock %} -{% block content %}

The 0.7.11 release fixes several issues, some related to clocks, which prevented new routers from quickly integrating into the network. It also fixes the installer for 64-bit Windows. @@ -62,4 +59,3 @@ cdfe59145158c63af6f19efea6868b3d0f64efe58b5c27123cdaddad22ba5406 i2pupdate_0.7. 0b289bb0368dd82b1975113d1173f7694ab6a3c036fb915cbf1d87ea1667c2cb i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/03/15/0.7.12-Release.rst b/i2p2www/blog/2010/03/15/0.7.12-Release.rst new file mode 100644 index 00000000..f9216e83 --- /dev/null +++ b/i2p2www/blog/2010/03/15/0.7.12-Release.rst @@ -0,0 +1,6 @@ +============== +0.7.12 Release +============== + +.. raw:: html + :file: blog/2010/03/15/release-0.7.12.html diff --git a/www.i2p2/pages/release-0.7.12.html b/i2p2www/blog/2010/03/15/release-0.7.12.html similarity index 97% rename from www.i2p2/pages/release-0.7.12.html rename to i2p2www/blog/2010/03/15/release-0.7.12.html index 7c161bd2..b2f384d4 100644 --- a/www.i2p2/pages/release-0.7.12.html +++ b/i2p2www/blog/2010/03/15/release-0.7.12.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.12 Release{% endblock %} -{% block content %}

The 0.7.12 release contains support for user-generated plugins. These plugins may contain console web applications, themes, translations, or standalone programs. @@ -91,4 +88,3 @@ a9033145b38cba2b35b37180a46101a67507943fc62ee4731bb60bccc80ef170 i2pinstall_0.7 31dd5ee3a47666d600a3a621224f1f73d4af17dce3e3e6ca8519971df3085052 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/04/27/0.7.13-Release.rst b/i2p2www/blog/2010/04/27/0.7.13-Release.rst new file mode 100644 index 00000000..d89edce7 --- /dev/null +++ b/i2p2www/blog/2010/04/27/0.7.13-Release.rst @@ -0,0 +1,6 @@ +============== +0.7.13 Release +============== + +.. raw:: html + :file: blog/2010/04/27/release-0.7.13.html diff --git a/www.i2p2/pages/release-0.7.13.html b/i2p2www/blog/2010/04/27/release-0.7.13.html similarity index 96% rename from www.i2p2/pages/release-0.7.13.html rename to i2p2www/blog/2010/04/27/release-0.7.13.html index 419bccfe..01a0ebca 100644 --- a/www.i2p2/pages/release-0.7.13.html +++ b/i2p2www/blog/2010/04/27/release-0.7.13.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.13 Release{% endblock %} -{% block content %}

The 0.7.13 release contains several changes and bug fixes to improve performance. It also includes improvements for the plugin support that was @@ -80,4 +77,3 @@ b0b4f2dd1efc562fb36326df4b2da140413ad907fc1ac5f636f521e21208fd28 i2psource_0.7. f8bf0b1e2bcc8921fb4f51d3751130dfbd855a2fc8afe0e0f6ea7eac1e95e4b0 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/06/07/0.7.14-Release.rst b/i2p2www/blog/2010/06/07/0.7.14-Release.rst new file mode 100644 index 00000000..010ef7d5 --- /dev/null +++ b/i2p2www/blog/2010/06/07/0.7.14-Release.rst @@ -0,0 +1,6 @@ +============== +0.7.14 Release +============== + +.. raw:: html + :file: blog/2010/06/07/release-0.7.14.html diff --git a/www.i2p2/pages/release-0.7.14.html b/i2p2www/blog/2010/06/07/release-0.7.14.html similarity index 94% rename from www.i2p2/pages/release-0.7.14.html rename to i2p2www/blog/2010/06/07/release-0.7.14.html index 583f9666..17b27680 100644 --- a/www.i2p2/pages/release-0.7.14.html +++ b/i2p2www/blog/2010/06/07/release-0.7.14.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.7.14 Release{% endblock %} -{% block content %}

The 0.7.14 release contains the usual collection of bug fixes and performance tweaks. There are also some i2psnark improvements and more fixes for plugins. @@ -45,4 +42,3 @@ ff16904bc1bbe58b4d256002bffddfa017e4538f133b0752bf73e2c2a403a13e i2pupdate.su2 c55c57420011137865fd9068c2b3644c5749d9f2f57e7b90667bb74c0e81544a i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/07/12/0.8-Release.rst b/i2p2www/blog/2010/07/12/0.8-Release.rst new file mode 100644 index 00000000..24dc0f6b --- /dev/null +++ b/i2p2www/blog/2010/07/12/0.8-Release.rst @@ -0,0 +1,6 @@ +============= +0.8 Release +============= + +.. raw:: html + :file: blog/2010/07/12/release-0.8.html diff --git a/www.i2p2/pages/release-0.8.html b/i2p2www/blog/2010/07/12/release-0.8.html similarity index 97% rename from www.i2p2/pages/release-0.8.html rename to i2p2www/blog/2010/07/12/release-0.8.html index 930f9fe4..10bfebe6 100644 --- a/www.i2p2/pages/release-0.8.html +++ b/i2p2www/blog/2010/07/12/release-0.8.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8 Release{% endblock %} -{% block content %}

In early 2009, shortly after our attendance at 25C3, we released version 0.7 of the I2P Anonymous Network. Over the next 15 releases in 18 months we have worked to improve the usability of the I2P software @@ -85,4 +82,3 @@ b9eff16965fb597b7a69fab72c5e4d21a767ffc1e654b3269d2dd9febdb79291 i2pupdate.su2 79b3ac041ea6afb0c04f705e134da10ec32bd4ffe5a7f378da60faf274ef112c i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/11/15/0.8.1-Release.rst b/i2p2www/blog/2010/11/15/0.8.1-Release.rst new file mode 100644 index 00000000..5024592c --- /dev/null +++ b/i2p2www/blog/2010/11/15/0.8.1-Release.rst @@ -0,0 +1,6 @@ +============= +0.8.1 Release +============= + +.. raw:: html + :file: blog/2010/11/15/release-0.8.1.html diff --git a/www.i2p2/pages/release-0.8.1.html b/i2p2www/blog/2010/11/15/release-0.8.1.html similarity index 95% rename from www.i2p2/pages/release-0.8.1.html rename to i2p2www/blog/2010/11/15/release-0.8.1.html index 4b48e0ac..e9cf9fd8 100644 --- a/www.i2p2/pages/release-0.8.1.html +++ b/i2p2www/blog/2010/11/15/release-0.8.1.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8.1 Release{% endblock %} -{% block content %}

The 0.8.1 release contains the usual collection of bug fixes and performance tweaks. There is also a new i2psnark theme and several translation updates. @@ -72,4 +69,3 @@ SHA256 Checksums: 63cfb32ebf6adbc3c2ee6364b471f9e57ce680c85c6152dca92a411fadd77694 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2010/12/22/0.8.2-Release.rst b/i2p2www/blog/2010/12/22/0.8.2-Release.rst new file mode 100644 index 00000000..9803fb98 --- /dev/null +++ b/i2p2www/blog/2010/12/22/0.8.2-Release.rst @@ -0,0 +1,6 @@ +============= +0.8.2 Release +============= + +.. raw:: html + :file: blog/2010/12/22/release-0.8.2.html diff --git a/www.i2p2/pages/release-0.8.2.html b/i2p2www/blog/2010/12/22/release-0.8.2.html similarity index 96% rename from www.i2p2/pages/release-0.8.2.html rename to i2p2www/blog/2010/12/22/release-0.8.2.html index 4c5c6877..6655ebdb 100644 --- a/www.i2p2/pages/release-0.8.2.html +++ b/i2p2www/blog/2010/12/22/release-0.8.2.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8.2 Release{% endblock %} -{% block content %}

The 0.8.2 release includes extensive bug fixes and theme updates in the router and in i2psnark. There are also optimizations to reduce memory usage in i2psnark. @@ -79,4 +76,3 @@ SHA256 Checksums: 5d094c6f1c98b4d463852c288c8a90041165c3fc002414bd2c425bbe204ae865 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2011/01/24/0.8.3-Release.rst b/i2p2www/blog/2011/01/24/0.8.3-Release.rst new file mode 100644 index 00000000..3278d520 --- /dev/null +++ b/i2p2www/blog/2011/01/24/0.8.3-Release.rst @@ -0,0 +1,6 @@ +============= +0.8.3 Release +============= + +.. raw:: html + :file: blog/2011/01/24/release-0.8.3.html diff --git a/www.i2p2/pages/release-0.8.3.html b/i2p2www/blog/2011/01/24/release-0.8.3.html similarity index 95% rename from www.i2p2/pages/release-0.8.3.html rename to i2p2www/blog/2011/01/24/release-0.8.3.html index 147d73ca..2b1762d8 100644 --- a/www.i2p2/pages/release-0.8.3.html +++ b/i2p2www/blog/2011/01/24/release-0.8.3.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8.3 Release{% endblock %} -{% block content %}

The 0.8.3 release contains several performance improvements, including reduction of threads and memory usage, and faster I2CP (client-router) communication. @@ -66,4 +63,3 @@ SHA256 Checksums: 4a2352be546fd9044068074c5edbd6c9ded373dab0f0f77e9df0db8974cbc2d9 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2011/03/02/0.8.4-Release.rst b/i2p2www/blog/2011/03/02/0.8.4-Release.rst new file mode 100644 index 00000000..7e597c86 --- /dev/null +++ b/i2p2www/blog/2011/03/02/0.8.4-Release.rst @@ -0,0 +1,6 @@ +============= +0.8.4 Release +============= + +.. raw:: html + :file: blog/2011/03/02/release-0.8.4.html diff --git a/www.i2p2/pages/release-0.8.4.html b/i2p2www/blog/2011/03/02/release-0.8.4.html similarity index 94% rename from www.i2p2/pages/release-0.8.4.html rename to i2p2www/blog/2011/03/02/release-0.8.4.html index 13bd3487..a4fadb65 100644 --- a/www.i2p2/pages/release-0.8.4.html +++ b/i2p2www/blog/2011/03/02/release-0.8.4.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8.4 Release{% endblock %} -{% block content %}

The 0.8.4 release contains some performance improvements and important bug fixes. Also, i2psnark now supports magnet links. @@ -55,4 +52,3 @@ SHA256 Checksums: 465060129520ad115a3823e625def94b8ebafdd28c6ab9b27e125afed70cf851 i2pupdate.sud

-{% endblock %} diff --git a/i2p2www/blog/2011/04/18/0.8.5-Release.rst b/i2p2www/blog/2011/04/18/0.8.5-Release.rst new file mode 100644 index 00000000..f70e5314 --- /dev/null +++ b/i2p2www/blog/2011/04/18/0.8.5-Release.rst @@ -0,0 +1,6 @@ +============= +0.8.5 Release +============= + +.. raw:: html + :file: blog/2011/04/18/release-0.8.5.html diff --git a/www.i2p2/pages/release-0.8.5.html b/i2p2www/blog/2011/04/18/release-0.8.5.html similarity index 94% rename from www.i2p2/pages/release-0.8.5.html rename to i2p2www/blog/2011/04/18/release-0.8.5.html index bcb4bd3c..d2092c30 100644 --- a/www.i2p2/pages/release-0.8.5.html +++ b/i2p2www/blog/2011/04/18/release-0.8.5.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8.5 Release{% endblock %} -{% block content %}

The 0.8.5 release contains a few bug fixes and performance improvements, and lots of translation updates. as usual, upgrading is recommended. @@ -51,5 +48,3 @@ SHA256 Checksums: efea978f3e4e955b9afa05847dc4ebb83c8df3651adeb717769e32a908bc5f53 i2pupdate.su2 1b6eca94b7938f5c61c26b4482c89919bdfbc7c41aee7735f8f561c01c3a29d3 i2pupdate.sud - -{% endblock %} diff --git a/i2p2www/blog/2011/05/16/0.8.6-Release.rst b/i2p2www/blog/2011/05/16/0.8.6-Release.rst new file mode 100644 index 00000000..30f3696c --- /dev/null +++ b/i2p2www/blog/2011/05/16/0.8.6-Release.rst @@ -0,0 +1,6 @@ +============= +0.8.6 Release +============= + +.. raw:: html + :file: blog/2011/05/16/release-0.8.6.html diff --git a/www.i2p2/pages/release-0.8.6.html b/i2p2www/blog/2011/05/16/release-0.8.6.html similarity index 93% rename from www.i2p2/pages/release-0.8.6.html rename to i2p2www/blog/2011/05/16/release-0.8.6.html index 2b7f3dd3..63c047b6 100644 --- a/www.i2p2/pages/release-0.8.6.html +++ b/i2p2www/blog/2011/05/16/release-0.8.6.html @@ -1,6 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8.6 Release{% endblock %} -{% block content %}

The 0.8.6 release contains more peer selection defenses to resist powerful attackers, and tweaks to adjust to the recent rapid growth in the network. @@ -43,5 +40,3 @@ SHA256 Checksums: - -{% endblock %} diff --git a/i2p2www/blog/2011/06/06/Ipredator-SoC.rst b/i2p2www/blog/2011/06/06/Ipredator-SoC.rst new file mode 100644 index 00000000..40c96634 --- /dev/null +++ b/i2p2www/blog/2011/06/06/Ipredator-SoC.rst @@ -0,0 +1,27 @@ +======================== +Ipredator Summer of Code +======================== +.. meta:: + :date: 2011-06-06 + :author: hottuna + :excerpt: I have been commissioned to contribute code to I2P during the + summer of 2011, implementing a control protocol and a client for + this protocol (similar to Vidalia for Tor). + +I have been commissioned to contribute code to I2P during the summer of 2011, implementing a control protocol and a client for this protocol (similar to `Vidalia`_ for Tor). +This work was the idea of Jan-Erik Fiske of `ViaEuropa`_ and Peter Sunde of `flattr`_ and `The Pirate Bay`_ fame and its funding will be generously provided by `Relakks`_ and `Ipredator`_. + +.. _`Vidalia`: https://www.torproject.org/projects/vidalia.html +.. _`ViaEuropa`: http://viaeuropa.se +.. _`flattr`: https://flattr.com +.. _`The Pirate Bay`: http://thepiratebay.org/ +.. _`Relakks`: https://www.relakks.com/?cid=gb +.. _`Ipredator`: https://www.ipredator.se/?lang=en + +Current information can be found on `zzz's forum`_ and #i2p-dev on chat.freenode.net + +.. _`zzz's forum`: http://zzz.i2p.to/topics/888 + +Cheers + +// hottuna (or Robert) diff --git a/i2p2www/blog/2011/06/27/0.8.7-Release.rst b/i2p2www/blog/2011/06/27/0.8.7-Release.rst new file mode 100644 index 00000000..2a22c0d6 --- /dev/null +++ b/i2p2www/blog/2011/06/27/0.8.7-Release.rst @@ -0,0 +1,6 @@ +============= +0.8.7 Release +============= + +.. raw:: html + :file: blog/2011/06/27/release-0.8.7.html diff --git a/www.i2p2/pages/release-0.8.7.html b/i2p2www/blog/2011/06/27/release-0.8.7.html similarity index 98% rename from www.i2p2/pages/release-0.8.7.html rename to i2p2www/blog/2011/06/27/release-0.8.7.html index 06c6d68a..9be1ec9f 100644 --- a/www.i2p2/pages/release-0.8.7.html +++ b/i2p2www/blog/2011/06/27/release-0.8.7.html @@ -1,7 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8.7 Release{% endblock %} -{% block content %} -

I2P release 0.8.7 contains several upgrades to long-neglected components, including the Naming Services, graphing, the native CPU ID and BigInteger libraries, crypto implementations, and the wrapper.

@@ -101,5 +97,3 @@ SHA256 Checksums: cad2233ec477fb4455ce90283a5d4a18dda17d312a818d6ae1276358cb2f55a5 i2pupdate.sud - -{% endblock %} diff --git a/i2p2www/blog/2011/08/23/0.8.8-Release.rst b/i2p2www/blog/2011/08/23/0.8.8-Release.rst new file mode 100644 index 00000000..7eb72a6f --- /dev/null +++ b/i2p2www/blog/2011/08/23/0.8.8-Release.rst @@ -0,0 +1,6 @@ +============= +0.8.8 Release +============= + +.. raw:: html + :file: blog/2011/08/23/release-0.8.8.html diff --git a/www.i2p2/pages/release-0.8.8.html b/i2p2www/blog/2011/08/23/release-0.8.8.html similarity index 97% rename from www.i2p2/pages/release-0.8.8.html rename to i2p2www/blog/2011/08/23/release-0.8.8.html index 28e0fb79..39e46c18 100644 --- a/www.i2p2/pages/release-0.8.8.html +++ b/i2p2www/blog/2011/08/23/release-0.8.8.html @@ -1,7 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.8.8 Release{% endblock %} -{% block content %} -

I2P release 0.8.8 enables the new hosts.txt database to speed hostname lookups and store additional information on hostname entries. It also includes improvements to speed a router's integration on startup. @@ -80,5 +76,3 @@ SHA256 Checksums: - -{% endblock %} diff --git a/i2p2www/blog/2011/09/03/Ipredator-SoC-itoopie-released.rst b/i2p2www/blog/2011/09/03/Ipredator-SoC-itoopie-released.rst new file mode 100644 index 00000000..242a34d1 --- /dev/null +++ b/i2p2www/blog/2011/09/03/Ipredator-SoC-itoopie-released.rst @@ -0,0 +1,33 @@ +======================== +Ipredator Summer of Code +======================== +.. meta:: + :date: 2011-09-03 + :author: hottuna + :excerpt: itoopie and I2PControl are launching! + I'm happy to announce that itoopie and I2PControl are available publicly. + +itoopie and I2PControl are launching! + +I'm happy to announce that itoopie and I2PControl are available publicly. + +itoopie is a graphical interface intended as a compliment to the I2P Router Console. +The aim of itoopie is to provide an interface that is simpler and has a lower lurning curve than the I2P Router Console. + +I2PControl is an I2P plugin providing a JSONRPC interface for the I2P router. The interface supports setting basic settings (bandwidth, ports etc.), reading many stats and is provided over an SSL encrypted HTTP connection. + +More information and instructions can be found at `itoopie.net`_, `itoopie.i2p.to`_ (via proxy)and `itoopie.i2p`_ (anonymously). + +.. _`itoopie.net`: http://itoopie.net +.. _`itoopie.i2p.to`: http://itoopie.i2p.to +.. _`itoopie.i2p`: http://itoopie.i2p + +This project has been funded by the VPN services `Relakks`_ & `Ipredator`_ and was initiated by Jan-Erik Fiske and `Peter Sunde`_. + +.. _`Relakks`: http://relakks.com +.. _`Ipredator`: http://ipredator.se +.. _`Peter Sunde`: http://twitter.com/brokep + +Thank you Jan-Erik and Peter, + +// hottuna diff --git a/i2p2www/blog/2011/10/11/0.8.9-Release.rst b/i2p2www/blog/2011/10/11/0.8.9-Release.rst new file mode 100644 index 00000000..1074da6a --- /dev/null +++ b/i2p2www/blog/2011/10/11/0.8.9-Release.rst @@ -0,0 +1,81 @@ +============= +0.8.9 Release +============= +.. meta:: + :date: 2011-10-11 + :category: release + :excerpt: The 0.8.9 release has several performance improvements, and many changes to handle the continued rapid growth of the network. It uses a new iterative method for Kademlia network database lookups that should be more reliable and efficient. There are also several improvements to our SSU (UDP) transport protocol that should help reliability and efficiency. We have made several changes to improve tunnel build success rates. And, of course, there are lots of bug fixes and translation updates. + +The 0.8.9 release has several performance improvements, and many changes to handle the continued rapid growth of the network. It uses a new iterative method for Kademlia network database lookups that should be more reliable and efficient. There are also several improvements to our SSU (UDP) transport protocol that should help reliability and efficiency. We have made several changes to improve tunnel build success rates. And, of course, there are lots of bug fixes and translation updates. + +The network has grown quite rapidly in recent weeks, and that's great news, +but it has caused some instability. We welcome all our new users and we +ask you to be patient as we make improvements to the software. + +Please help grow the network. `Get involved`_, spread the word, and `donate`_! +If you find a bug, please enter a report on `Trac`_. +We are still looking for help on new and existing translations. +Please volunteer on IRC #i2p-dev. + +.. _`Get involved`: {{ site_url('get-involved') }} +.. _`donate`: {{ site_url('get-involved/donate') }} +.. _`Trac`: http://{{ i2pconv('trac.i2p2.i2p') }}/report/1 + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +**{% trans %}Major Changes{% endtrans %}** + +- Iterative netdb lookup, this had to be fixed as the network growth was making the old method less reliable. Also increase lookup timeouts to improve success rates. +- Implement a SSU disconnect message so that the other side of a connection finds out when the peer disconnects. This should considerably speed up subsequent reconnection. +- Major rewrite of the SSU send queue code, for efficiency in high-speed routers +- Major rewrite of the participating tunnels expiration code, for efficiency in high=speed routers +- Increase the maximum SSU MTU so messages take less packets +- New reverse lookup table in the hosts.txt database so that names are displayed again on the neteb leases page. +- Preliminary support for IRC DCC - not enabled by default +- (New installs only) Switch to the Maxmind GeoIP database which is up-to-date and has better coverage of some countries. +- (New installs only) Update to wrapper 3.5.12 to fix file permission problems. + +**{% trans %}Bug Fixes{% endtrans %}** + +- Fix restoration of original tunnel quantity after idle +- Reduce CPU usage when network is disconnected +- Fix i2psnark "eject" button in certain browsers +- Fix changing i2psnark tunnel parameters +- Fix installation issues on some non-English Windows versions +- Catch some uncaught exceptions from GNU NIO +- Fix connectivity issues after long suspend times + +**{% trans %}Other{% endtrans %}** + +- Improvements to the data structure caching, and increase some cache sizes, to increase hit rates. Add a country code string cache. +- Continue work on removing global locks for performance improvements +- Rewrite of the job queue for efficiency +- Switch to https reseed by default for security; update the reseed host lists +- Don't bother to gzip small http responses and images +- Use bigger buffers and gunzipper cache in the http proxy +- Several changes to improve tunnel build success rates +- Increase the number of floodfills again +- Faster router info expiration +- Remove ancient deprecated ministreaming socket manager +- Add option for i2psnark files readable by everyone +- Add option for i2psnark page refresh time +- Add streaming API for getting and setting I2CP port +- More aggressive netdb exploration by hidden routers +- Remove confusing "firewalled and fast" message +- Translation updates for German, Spanish, Portuguese, Russian, and Swedish + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 554d0abe82ca034e1b7479410bab330bba5644ca1ae4117982af670d0f44ee66 i2pinstall_0.8.9.exe + c40d503c0ee2e90c75f3d635649490a8e49b60e1da8100db118e2097a133429e i2psource_0.8.9.tar.bz2 + dba9258b67b3021c40456aae8e6986dc954ec55ab4ea527fd1ef02cfba88d803 i2pupdate_0.8.9.zip + 8f04438cd3d17240bebe8afc172ed54a65c3265db8ea4675a8c508d8ba088326 i2pupdate.su2 + e8754a0490bd3e47bc5017ea66d2bfda6386e9c9c6d50a6d77d2c15c0cab098b i2pupdate.sud diff --git a/i2p2www/blog/2011/10/20/0.8.10-Release.rst b/i2p2www/blog/2011/10/20/0.8.10-Release.rst new file mode 100644 index 00000000..f47bef4c --- /dev/null +++ b/i2p2www/blog/2011/10/20/0.8.10-Release.rst @@ -0,0 +1,44 @@ +============== +0.8.10 Release +============== +.. meta:: + :date: 2011-10-20 + :category: release + :excerpt: Release 0.8.10 includes two changes intended to reduce the number of router-to-router connections, and therefore improve tunnel build success rates and general reliability. Of course, there's also a few bug fixes and translation updates. + +Release 0.8.10 includes two changes intended to reduce the number of router-to-router connections, and therefore improve tunnel build success rates and general reliability. Of course, there's also a few bug fixes and translation updates. + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +**{% trans %}Major Changes{% endtrans %}** + +- Disable tunnel testing as it forces too many router connections +- Select outbound endpoint - inbound gateway paths that are closer, using an XOR metric, to reduce router connections. + +**{% trans %}Bug Fixes{% endtrans %}** + +- Fix exceptions at shutdown +- Fix concurrency errors in SSU +- Fix timeout message on POST + +**{% trans %}Other{% endtrans %}** + +- Increase max tunnels, reduce router info expiration +- Add gunzip support to eepget to reduce reseed bandwidth +- Finnish, Italian, Russian, and Swedish translation updates + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 8494640d29b1b7969118169a7ae1c56bc5a07f354ec883734687bf09eef0e35c i2pinstall_0.8.10.exe + e5832bb49f46b0b6620e8492e6fc6454de4107b84bca5a4b35461c6b7ac0575e i2psource_0.8.10.tar.bz2 + 64bcd1fdd478cfda987c1d4906d94b3f20a0555bd4037aefa7a09af4f39a0e99 i2pupdate_0.8.10.zip + 5620113f4e19768e15af0a9c8bc670ca443e9983a0d4868997800ee215790c51 i2pupdate.su2 + 39bfbfebbf77d660081fe1ce282f642fb15ed9cd170901f54a954bc986eadaf5 i2pupdate.sud diff --git a/i2p2www/blog/2011/11/08/0.8.11-Release.rst b/i2p2www/blog/2011/11/08/0.8.11-Release.rst new file mode 100644 index 00000000..879b3348 --- /dev/null +++ b/i2p2www/blog/2011/11/08/0.8.11-Release.rst @@ -0,0 +1,59 @@ +============== +0.8.11 Release +============== +.. meta:: + :date: 2011-11-08 + :category: release + :excerpt: Release 0.8.11 includes several more changes to reduce the number of router-to-router connections and increase connection and tunnel build capacity. The goal, of course, is to improve tunnel build success rates and general reliability. As always, there's a few bug fixes and translation updates. + +As you all have noticed, the unprecedented network growth starting October 5th +has dramatically increased network congestion, especially on evenings (UTC) +and weekends. The last two releases contained a few changes that we hoped +would relieve the pressure, but unfortunately these measures have been only +modest successes. The primary issue is to limit the number of direct router +to-router connections in the network. This isn't a new problem; we've been +working on it for several years, with good results. However, the recent +growth pushed us over the edge once again. + +Release 0.8.11 includes several more changes to reduce the number of router-to-router connections and increase connection and tunnel build capacity. The goal, of course, is to improve tunnel build success rates and general reliability. As always, there's a few bug fixes and translation updates. + +We welcome all our new users. Please be patient as we work to improve network +performance. Debugging congestion problems in a distributed anonymous network +is a continuing challenge. Please help improve the network +by restarting your router once the upgrade is downloaded. + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +**{% trans %}Major Changes{% endtrans %}** + +- Improve peer profile capacity metric to include factors for connection, reachability, country, and router hash, to reduce connection churn +- Adjust connection limits and timeouts to increase capacity +- Adjust router info and peer profile expirations to reduce memory usage +- Rebuild existing tunnels some of the time to reduce connection churn and improve build success +- Build Executor / Handler thread separation to increase build handling capacity for high-speed routers +- Bloom Filter optimizations to reduce lock contention for high-speed routers +- SSU introducer changes + +**{% trans %}Bug Fixes{% endtrans %}** + +- Fix expiration of peer profiles + +**{% trans %}Other{% endtrans %}** + +- Ukrainian translation updates + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + fa3d566874f196e32e1d5987d3dedb956cfa0b2a93a0735e53d6dd9fa2b1769a i2pinstall_0.8.11.exe + f7113da64bacea9a560e0f3c31c9fb663fc646d16bb621a9b8f1e97477d0a2d1 i2psource_0.8.11.tar.bz2 + 835fe7dadd4b8155a83774ea025dc76332660fed2c20799fa21f54b5627bff3d i2pupdate_0.8.11.zip + d932c54d275eef0a31418970e0ecae8ea46d25e1110db4b9eab4ba685830e445 i2pupdate.su2 + ca3e17c3cd29159e8a2a91ccc51bdfbf794ad9ca481f620b29bdd51251c3ab97 i2pupdate.sud diff --git a/i2p2www/blog/2012/01/06/0.8.12-Release.rst b/i2p2www/blog/2012/01/06/0.8.12-Release.rst new file mode 100644 index 00000000..0488c6fe --- /dev/null +++ b/i2p2www/blog/2012/01/06/0.8.12-Release.rst @@ -0,0 +1,90 @@ +============== +0.8.12 Release +============== +.. meta:: + :date: 2012-01-06 + :category: release + :excerpt: The 0.8.12 release fixes several message corruption bugs, some present since 2005. It also contains a redesign of the router's congestion control, and continued optimization of CPU and memory usage. We are hopeful that these changes will improve network performance. + +The 0.8.12 release fixes several message corruption bugs, some present since 2005. It also contains a redesign of the router's congestion control, and continued optimization of CPU and memory usage. We are hopeful that these changes will improve network performance. +Upgrading is recommended. + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +This release contains several big changes that should help network reliability and performance. + +The first two changes are fixes for major UDP packet transmission bugs, described below. The third change +is fixes to the decompressor. Fixing these should eliminate a big source of message delivery failures. + +Also, the release contains a rewrite of the router's participating traffic congestion control. It should +now more accurately measure current participating bandwidth, handle bursts better, drop messages less, and +drop the right messages if dropping is required. + +Also, the release reduces the amount of processing that routers do for messages they pass down the tunnel. +These messages do not need to be completely parsed and validated since the gateway is simply passing them through. +This will help performance of all routers but the improvement will probably not be noticeable except on high-traffic routers. + +We're optimistic that these changes will help, and of course eliminating sources of message corruption is sure to help. +However the extend of the improvement won't be apparent until the majority of the network upgrades. + +The release also contains some updates to the router console light theme. You may need to do a shift-reload +or control-reload in your browser to force a reload of the CSS. + +**{% trans %}Major changes{% endtrans %}** + +- Instead of fully parsing and validating messages received at the inbound gateway, simply pass them down the tunnel +- Don't verify I2NP checksums in most cases, as message corruption is caught at other layers +- Don't recalculate I2NP checksums on messages passed through unchanged +- Several NTCP pumper optimizations, to hopefully fix NTCP pumper high CPU usage on fast routers +- Rewrite participating tunnel congestion control, to drop less, more accurately measure traffic, and handle bursts better + +**{% trans %}Wrapper Update{% endtrans %}** + +New installs include wrapper version 3.5.13 which fixes a heap corruption with very long log lines. +See http://wrapper.tanukisoftware.com/doc/english/release-notes.html +for additional information. I2P PPA package users should have received this update in the last week of December. +If you do not use our PPA package and would like to update your wrapper manually, follow the instructions at +http://www.i2p2.de/manualwrapper . + +**{% trans %}Bug Fixes{% endtrans %}** + +- Fix major SSU MTU bug introduced in 0.8.9.The router sometimes sent UDP packets that exceeded the maximum + size that routers would accept on the receive side. This resulted in a lot of dropped packets, tunnel build problems, + and connection problems. One thing that contributed to us missing the problem was that 0.8.9 was released in the + middle of the huge network expansion in early October, when network performance was already deteriorating rapidly. +- Fix major SSU fragmentation bug present since 2005. UDP corrupted transmit messages when the message size + was an exact multiple of the fragmentation size. +- Fix major decompression bugs present since 2005 that caused message corruption and data loss at multiple protocol layers. +- Snark doesn't always delete directories +- Fix all character case conversion (Turkish four i problem) +- Whitelist more IRC commands +- Remove expired reseed cert + +**{% trans %}Other{% endtrans %}** + +- Speed up the inefficient GeoIP lookup +- Optimize several heavily-used utility functions +- Don't drop the transport connection when receiving an invalid message, it isn't necessary and could be an attack vector +- Console light theme update +- Move the complex network configuration stuff to a new console page +- Add a link to hide the news in the console +- Allow numerous additional IRC commands through the IRC filter +- Several other cleanups, optimizations, and object caches added +- New Estonian translation (thanks ajutine) +- Spanish, Swedish, Ukrainian translation updates + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 7a05b96c535f565b06aeec3b83fca6245b1159003d4e2da2149374ba0f476847 i2pinstall_0.8.12.exe + 019d6018e7093650cf67fd883b0cf0f12aa2f4f0cddc5ef6a08e6147af07f142 i2psource_0.8.12.tar.bz2 + a9556998b136d47b124749f426d86514e7128094308f03085b889f34bbdf8dc0 i2pupdate_0.8.12.zip + bb7be1dc9bdcc9b2db2587988325b4ea7c81e9eeb542ebcb17e0d6de29fc98d3 i2pupdate.su2 + 491722ef1a641512fc3bbaf825d5d1671b701e32b1298572f2820ab7fbf9851d i2pupdate.sud diff --git a/i2p2www/blog/2012/02/27/0.8.13-Release.rst b/i2p2www/blog/2012/02/27/0.8.13-Release.rst new file mode 100644 index 00000000..5f4c5da0 --- /dev/null +++ b/i2p2www/blog/2012/02/27/0.8.13-Release.rst @@ -0,0 +1,83 @@ +============== +0.8.13 Release +============== +.. meta:: + :date: 2012-02-27 + :category: release + :excerpt: The 0.8.13 release contains several bug fixes and a couple of new features. We are pleased that the last release significantly improved performance, and the network is running well despite continued rapid growth. + +The 0.8.13 release contains several bug fixes and a couple of new features. We are pleased that the last release significantly improved performance, and the network is running well despite continued rapid growth. +Upgrading is recommended. + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +This is likely to be the last release before 0.9, in which we will migrate to Jetty 6, +and introduce a simplified router console home page. Monitor the news section of +your the router console in the coming weeks for more information on the next release. + +Starting with this release, the router will +check for and install plugin updates shortly upon restarting after a router update. +To prevent this, add the advanced configuration +``plugins.autoUpdate=false`` before restarting. +There is also a new update-all button on the client configuration page. + +Routers in certain countries will now automatically enable hidden mode for increased protection. +However, hidden mode may have lower performance or reliability, and is still a work in progress. +To disable hidden mode before restarting, add the advanced configuration +``router.isHidden=false``. +To disable hidden mode later, select *use all auto-detect methods* under *IP Configuration* on the +network configuration page. +For the list of countries see the thread on zzz.i2p. +The only country on the list that has more than one or two I2P users is China. + +**{% trans %}Major Changes{% endtrans %}** + +- Check for and download plugin updates upon restarting after a router update. +- Routers in certain countries will now automatically enable hidden mode for increased protection. +- New Tunnel Wizard for creating tunnels +- A SIGHUP to the wrapper will now initiate a graceful shutdown + +**{% trans %}Bug Fixes{% endtrans %}** + +- Increase read timeout in HTTP Proxy +- Shutdown hooks will now run when router is shutdown externally (i2prouter stop), broken in 0.8.8 +- If an external IP address is specified, bind only to that interface +- Fail tunnels we created when we can't contact the adjacent hop +- Prevent races when saving configuration +- For plugins, check min and max Jetty versions; check all version requirements at startup, not just at install +- Fix plugin startup when console is not on port 7657 +- Only stop plugins if they are running +- Fix NPE when no network interfaces are present +- Fix eepget exit code on failure +- Improve inbound tunnel building when in hidden mode +- Publish our router info sooner after startup to facilitate inbound tunnel building +- Fix Streamr tunnel registration + +**{% trans %}Other{% endtrans %}** + +- Add icons to buttons in SusMail and SusiDNS +- Move wrapper PID, status, and log files from /tmp to ~/.i2p (Debian packages and new installs only) +- i2prouter graceful (Debian packages and new installs only) +- Increase number of floodfills +- Repack jars in installer to save a little space +- New translation infrastructure for i2prouter script (not enabled yet) +- New Czech translation (thanks Waseihou) +- German, Italian, Polish, Spanish, Swedish, Ukrainian translation updates + + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 648a552ee009e9648aba0666c05e2f71e442a714716659a0ca4f60aca87bda50 i2pinstall_0.8.13.exe + bdd510cc47b2cd78aa8d994e27694185c1f2deb48b049d61a93a795932ce5712 i2psource_0.8.13.tar.bz2 + 36683d906ac121fd28ac5600218aec943da154cb0230f274f0e2a7c6cc6fb8a5 i2pupdate_0.8.13.zip + 81fa5256250fde2790153b83d2b01b6bc3b5ee7ea1b4d12232ce46f06ae736ef i2pupdate.su2 + 2eb25974ebfeeeec59d8138e42d5663d97cc24b94f2c6cf77cfe6dc991acf0bb i2pupdate.sud diff --git a/i2p2www/blog/2012/05/02/0.9-Release.rst b/i2p2www/blog/2012/05/02/0.9-Release.rst new file mode 100644 index 00000000..3463eeb0 --- /dev/null +++ b/i2p2www/blog/2012/05/02/0.9-Release.rst @@ -0,0 +1,105 @@ +============= +0.9 Release +============= +.. meta:: + :date: 2012-05-02 + :category: release + :excerpt: The 0.9 release concludes over a year and a half of work on the 0.8.x series, in which we greatly improved the performance and security of the router, and the scalability of the network. + +The 0.9 release concludes over a year and a half of work on the 0.8.x series, in which we greatly improved the performance and security of the router, and the scalability of the network. + +In the 0.9 release we migrate to Jetty 6 for the console and eepsite web server, +and introduce a simplified router console home page. +This release is network-compatible with prior releases, however see below for important +information on compatibility with existing eepsites, plugins, and webapps. +Upgrading is recommended. + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}Update Info{% endtrans %}** + +In-network updates and new installs will include Jetty 6, Tomcat, and JSTL. +PPA (Ubuntu/Debian) updates will have new dependencies for these packages. + +If you have not enabled or modified your eepsite settings, the update should automatically migrate you to Jetty 6. +If you do not use Jetty for your eepsite, the update will not affect it. + +If you have more than one Jetty eepsite or you have changed the local port (7658 by default) or otherwise edited jetty.xml, +you must manually edit the new jetty configuration files after updating, and then restart. + +For those with Jetty-based eepsites, we recommend that you verify that the upgrade +was successful and the eepsites are operational after the router restarts. + +**Plugin information** + +- Plugins not listed below should continue to work under Jetty 6. +- The following plugins require updates for Jetty 6. The router will download and install them a few minutes + after upgrading: i2pcontrol, pebble, zzzot +- The following plugins have been renamed and for Jetty 6. Users must manually remove them and download the new versions + after upgrading: neodatis, seedless +- The following plugin does not work well with Jetty 6, you may wish to remove it and install the unofficial replacement + from plugins.i2p after upgrading: i2pbote + +Other non-standard console and eepsite webapps not packaged by the I2P development team may or may not +require modifications. + +**{% trans %}Major Changes{% endtrans %}** + +- Jetty 6.1.26, Tomcat 6.0.35, JSTL 1.2, supporting Servlet 2.5 and JSP 2.1 standards +- New simplified console home page. + Note that it may be modified or disabled on the new page /confighome . +- The old .exe installer has been split into Windows (.exe) and non-Windows (.jar) installers +- Update to wrapper 3.5.14 (Debian packages and new installs only) + +**{% trans %}Bug Fixes{% endtrans %}** + +- Fix use of unacked ElGamal/AES Session Tags, causing permanently "stuck" connections +- Re-enable verifies of RouterInfo netdb stores +- Fix removal of context properties +- Fix handling of plugin installs requiring router restart +- Fix update key names being forgotten after a save on the config update page +- Fix i2psnark duplicate torrent messages +- Fix occasional NPE in the UDP transport + +**{% trans %}Other{% endtrans %}** + +- More refactoring to get rid of static references which will help testing, shutdown, and embedded applications +- Reseed cleanups and checks +- Streamlining of tunnel endpoint message processing +- i2psnark bug fixes +- i2psnark private tracker support +- i2psnark tracker configuration form +- i2psnark message box cleanup +- i2psnark Javascript refresh +- i2psnark better error reporting +- Remove support for i2psnark "run standalone" +- Remove deprecated i2ptunnel Bean classes from the jar +- Increase max leaseset size from 6 to 16 for future growth +- Plugin tweaks +- Jetty logging moved from wrapper log to I2P log +- New page for viewing individual graphs for easy resizing and viewing of previous intervals +- Remove bandwidth from netdb stats +- Add negative lookup cache to naming service +- Reduce size of netdb structures +- HTTP Proxy refactoring to improve parsing of URLs and support IPv6 addresses, improve handling of malformed URLs, improved address helper handling +- Use per-destination streaming timers +- Better handling of leaseset/routerinfo overwrite attempts +- GeoIP update to April 2012 version (Debian packages and new installs only) +- German, Russian, Spanish, Swedish translation updates +- Non-default theme updates +- General code cleanups + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 006a306a2c5a449cce6a19378da5e74b8aa216ba5a9383a4c2cb66dfead2e736 i2pinstall_0.9_windows.exe + 6175c50a306cbd6ebe6eba40965408bd3f87f3ecd0f6199d7a927099c21d73c0 i2pinstall_0.9.jar + 8a3654a13781a9aacf9db94081e057be73322f88db2931eba4f2cfa467ead429 i2psource_0.9.tar.bz2 + 234d4c0ad1736b389349c702bfcf70511e72770a414b0afe7e9f5e1f5ebca97d i2pupdate_0.9.zip + 78fc1af81b71b5797bf9900b5a98f4513af840b76e801c40b9e4abb5e7e37807 i2pupdate.su2 + 63ec749a1da0c7913c09cc7bcf552497bebb873024ac42030c8a507c92aec9de i2pupdate.sud diff --git a/i2p2www/blog/2012/07/30/0.9.1-Release.rst b/i2p2www/blog/2012/07/30/0.9.1-Release.rst new file mode 100644 index 00000000..55d69742 --- /dev/null +++ b/i2p2www/blog/2012/07/30/0.9.1-Release.rst @@ -0,0 +1,85 @@ +============= +0.9.1 Release +============= +.. meta:: + :date: 2012-07-30 + :category: release + :excerpt: 0.9.1 includes a large number of bug fixes in i2psnark, some streaming lib improvements, home page changes, new themes, and translation updates. + +0.9.1 includes a large number of bug fixes in i2psnark, some streaming lib improvements, home page changes, new themes, and translation updates. +Upgrading is recommended. + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +**I2PSnark** + +- Fix several bugs in downloading torrents with skipped files +- Fix places where rarest-first was not honored +- Fix handling of encoded magnet links +- Additional inbound connection limits +- Immediate closing of connections with handshake errors +- Blocklist peers with multiple handshake errors +- Delay "ballooning" files on disk until required, to speed torrent adds +- Store partial pieces in temp files to greatly reduce memory usage when leeching +- Remove peers restriction when leeching torrents with large pieces +- Improve configuration of open and private trackers +- Prevent configuratino of default trackers as private +- Improved display and control of torrent file downloads +- Reduced number of threads +- Faster startup and shutdown of torrents +- Allow clearing of message box +- New light theme +- Torrent info page updates and cleanups +- Fix problems with restarted torrents +- Delay tunnel close at shutdown to ensure trackers are notified +- Better UI behavior during tunnel startup and shutdown + +**{% trans %}Bug Fixes{% endtrans %}** + +- Prevent shutdown hangs caused by buggy plugins +- Fix for Raspberry Pi crashing +- Fix rare job queue hang +- Fix routing key modifier rarely not updating at midnight +- Fix excessive padding in some AES-encrypted messages +- Fix occasional gunzip failures +- Several fixes to streaming lib to speed recovery after dropped packets and improve retransmit behavior +- Fix bug that reduced reuse of tunnels + +**{% trans %}Other{% endtrans %}** + +- Ports are now passed through the SOCKS and HTTP proxies to support eepsite virtual hosts. See http://{{ i2pconv('zzz.i2p') }}/topics/1182 for setup instructions. +- I2PTunnel configuration changes now take effect immediately. No tunnel restart required. +- Summary bar iframe removed, refresh is now via Javascript only +- Reduce netDB flood redundancy +- Reduce stats publishing frequency +- Minor router console changes +- New Hungarian and Greek translations +- Completed Italian translation +- Updates to Dutch, Finnish, French, German, Spanish, and Swedish translations +- Update geoip to Maxmind 2012-07-04 +- Theme updates +- Theme support for SusiMail and SudiDNS; new dark themes +- I2PTunnel and SusiDNS now iframed with summary bar +- Console home page now shows news summary in summary bar +- Console home page icon updates +- Console summary bar now configurable +- Change the HTTP proxy error code from 404 to 500 +- Cleanups for efficiency in netdb and I2CP +- Increase timeout for internal uses of eepget to improve reliability + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 0727af83988e82f32e0972a9e12c72ac14c3c0da0815c5902193d6b13d356371 i2pinstall_0.9.1_windows.exe + 39c19c0df042ad231a14fdf1c20e4927651a2af0f0cf734b46eba0d2b8419314 i2pinstall_0.9.1.jar + 8603c928a210ced77b6498bf8ee07cb000be9641adc389b34c3c8a10ac4f0677 i2psource_0.9.1.tar.bz2 + 136b74435b93aededef5884d39cfbc513f57184b74c8481580bcd5324aa23b1a i2pupdate_0.9.1.zip + 4f07fee850d56fada06f0aeabb5bb46c6172bad72411e07bf4f6a8e0d76d8acd i2pupdate.su2 + c039b423983789d914a1d02d3703b3c1aa36c87165e132419ff39b5d184ef480 i2pupdate.sud diff --git a/i2p2www/blog/2012/09/21/0.9.2-Release.rst b/i2p2www/blog/2012/09/21/0.9.2-Release.rst new file mode 100644 index 00000000..8dc7cf35 --- /dev/null +++ b/i2p2www/blog/2012/09/21/0.9.2-Release.rst @@ -0,0 +1,61 @@ +============= +{% trans %}0.9.2 Release{% endtrans %} +============= +.. meta:: + :date: 2012-09-21 + :category: release + :excerpt: {% trans %}0.9.2 includes extensive low-level changes to improve the performance and efficiency of the router. We have updated our UPnP library, to hopefully make UPnP work for more people. I2PSnark now has DHT support, but it is not yet enabled by default, as we plan to do more testing during the upcoming 0.9.3 development cycle.{% endtrans %} + +{% trans -%} +0.9.2 includes extensive low-level changes to improve the performance and efficiency of the router. We have updated our UPnP library, to hopefully make UPnP work for more people. I2PSnark now has DHT support, but it is not yet enabled by default, as we plan to do more testing during the upcoming 0.9.3 development cycle. +{%- endtrans %} +{% trans -%} +As usual, there's also lots of bug fixes in this release, so updating is recommended. +{%- endtrans %} + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +**{% trans %}Major Changes{% endtrans %}** + +- {% trans %}SSU: Fix several problems in our UDP transport, to improve efficiency and reliability for connection setup. Also improve defenses against various types of bad input.{% endtrans %} +- {% trans %}UPnP: Updated our library to fix several issues, should work for more routers now{% endtrans %} +- {% trans %}Transport: Improve performance in both our TCP and UDP transports, to benefit high-bandwidth routers{% endtrans %} +- {% trans %}Crypto: The thresholds and number of ElGamal/AES Session Tags delivered are now much more flexible, which should lessen protocol overhead and reduce stalls caused by dropped tags.{% endtrans %} +- {% trans %}I2PSnark: Add DHT support, not yet enabled by default, will do further testing and plan to enable by default in 0.9.3.{% endtrans %} + +**{% trans %}Bug Fixes{% endtrans %}** + +- {% trans %}Fix various issues affecting memory usage and performance on high-bandwidth routers{% endtrans %} +- {% trans %}Fix problems in UDP for routers using a reduced-MTU connection, e.g. a VPN{% endtrans %} +- {% trans %}Fix i2psnark bug that prevented a completion announcement to the tracker{% endtrans %} +- {% trans %}Fix a lock contention problem in i2ptunnel{% endtrans %} +- {% trans %}Fix some OSX installation issues{% endtrans %} +- {% trans %}Remove uses of direct byte buffers that may have been leaking{% endtrans %} + +**{% trans %}Other{% endtrans %}** + +- {% trans %}Reduce overhead in network messages{% endtrans %} +- {% trans %}Add "universal" theme support{% endtrans %} +- {% trans %}Theme updates{% endtrans %} +- {% trans %}Add a jbigi library for Raspberry Pi{% endtrans %} +- {% trans %}New Scala unit test framework{% endtrans %} +- {% trans %}Translation updates for Czech, Dutch, German, and Greek{% endtrans %} +- {% trans %}Update wrapper to 3.5.15 (new installs and PPA only){% endtrans %} +- {% trans %}Update GeoIP data (new installs and PPA only){% endtrans %} + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 4cc506d74bea772d304a8fc1d4adee900e5d7d38cbf896bd8aa9de31002b4f43 i2pinstall_0.9.2_windows.exe + 7eb1b62bdb955691dfd645acc2172fe7947266e35f201273f702272d57b80a70 i2pinstall_0.9.2.jar + ac0262120868a01d11b27ce56a7fea5ea243e261d0d7ff6e6dd59e18987a1be5 i2psource_0.9.2.tar.bz2 + c547b81822ff642e52a9196e847466b5613219fc695bc26485930c7a855e0cee i2pupdate_0.9.2.zip + f8b34fe7764d828fbdbcc13efd4f8f4ae20697f84c1c3772213241fa2ce0786a i2pupdate.su2 + 8ee355a27713f43a2a37dcfb70a4ea1d9f6c1fbad2d33a35083c0a33afaedeec i2pupdate.sud diff --git a/i2p2www/blog/2012/10/27/0.9.3-Release.rst b/i2p2www/blog/2012/10/27/0.9.3-Release.rst new file mode 100644 index 00000000..24eb013d --- /dev/null +++ b/i2p2www/blog/2012/10/27/0.9.3-Release.rst @@ -0,0 +1,65 @@ +============= +{% trans %}0.9.3 Release{% endtrans %} +============= +.. meta:: + :date: 2012-10-27 + :category: release + :excerpt: {% trans %}0.9.3 includes extensive low-level changes to the queueing of messages in the router. We implement the CoDel Active Queue Management (AQM) algorithm. We also unify the queueing and priority mechanisms in the transports to aid diagnosis and reduce network latency. Work continues on fixing UDP transport bugs and making UDP more resistant to attacks. There are more changes to improve the performance of the router and reduce its memory usage. Also, we enable i2psnark's DHT support, introduced last release, by default.{% endtrans %} + +{% trans -%} +0.9.3 includes extensive low-level changes to the queueing of messages in the router. We implement the CoDel Active Queue Management (AQM) algorithm. We also unify the queueing and priority mechanisms in the transports to aid diagnosis and reduce network latency. Work continues on fixing UDP transport bugs and making UDP more resistant to attacks. There are more changes to improve the performance of the router and reduce its memory usage. Also, we enable i2psnark's DHT support, introduced last release, by default. +{%- endtrans %} +{% trans -%} +As usual, there's also lots of bug fixes in this release, so updating is recommended. +{%- endtrans %} + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +**{% trans %}Major Changes{% endtrans %}** + +- {% trans %}Active Queue Management{% endtrans %} +- {% trans %}Priority queues{% endtrans %} +- {% trans %}I2PSnark DHT: Several bug fixes, enable by default.{% endtrans %} + +**{% trans %}Bug Fixes{% endtrans %}** + +- {% trans %}Several SSU fixes including memory leak, and better handling of routers behind firewalls that change UDP ports; additional defenses for malicious packets.{% endtrans %} +- {% trans %}Fix piece selection (rarest-first) bugs in i2psnark{% endtrans %} +- {% trans %}Fix bug causing multiple browsers to open at startup{% endtrans %} + +**{% trans %}Other{% endtrans %}** + +- {% trans %}Improvements in caching{% endtrans %} +- {% trans %}Several synchronization fixes and lock contention reduction{% endtrans %} +- {% trans %}Major reduction in SSU buffers memory use{% endtrans %} +- {% trans %}Fix streaming connection timeout back to 1 minute, was inadvertently changed to 5 minutes; set i2ptunnel server read timeout to 5 minutes, was unlimited{% endtrans %} +- {% trans %}Improved defenses in i2ptunnel for "darkloris"{% endtrans %} +- {% trans %}More validation at torrent creation in i2psnark{% endtrans %} +- {% trans %}Several parameter changes in SSU to improve throughput{% endtrans %} +- {% trans %}New event log for major events including restarts; show multiple restart lines on graphs{% endtrans %} +- {% trans %}Remove duplicate messages from logs{% endtrans %} +- {% trans %}Don't respond to blocked streaming connections with a reset, just drop{% endtrans %} +- {% trans %}Remove all uses of inefficient SimpleTimer{% endtrans %} +- {% trans %}More checks for valid IPs and ports entered in console{% endtrans %} +- {% trans %}Fix bug that wasted a lot of entropy{% endtrans %} +- {% trans %}Translation updates: Italian, Portuguese, Spanish, Swedish{% endtrans %} +- {% trans %}Add non-NIO configuration in jetty.xml, recommended for Java 5{% endtrans %} +- {% trans %}Update GeoIP data (new installs and PPA only){% endtrans %} + + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 762964ab582801be1c9d45843c682f791c284d4fa7b1e1ee733ea4ef033d4907 i2pinstall_0.9.3_windows.exe + 4ebea74b30064c9853c40cf24764d283dc6fff47ed2449b247f3c9991cccb494 i2pinstall_0.9.3.jar + 39a7d6859bf4bd9ac56fd83a5e32d47d1b24ba06f912a027804492ca941936dd i2psource_0.9.3.tar.bz2 + 2381e4a845c6cc0c0d9f27f99571984bcbf448ef041bc1f7a2ba8715228d6377 i2pupdate_0.9.3.zip + d8bb6aef09c967b30c7374fb49da246a7c237c4942fa92999e39c5ce2ca68893 i2pupdate.su2 + 600e806e72441e946027fcac84702f2daabd2783dbc1ee6df3427e6eda7db351 i2pupdate.sud diff --git a/i2p2www/blog/2012/12/17/0.9.4-Release.rst b/i2p2www/blog/2012/12/17/0.9.4-Release.rst new file mode 100644 index 00000000..8ab7476d --- /dev/null +++ b/i2p2www/blog/2012/12/17/0.9.4-Release.rst @@ -0,0 +1,76 @@ +============= +{% trans %}0.9.4 Release{% endtrans %} +============= +.. meta:: + :date: 2012-12-17 + :category: release + :excerpt: {% trans %}0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents.{% endtrans %} + +{% trans -%} +0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents. +{%- endtrans %} + +{% trans -%} +We fixed several bugs in the i2psnark DHT implementation that was introduced +last release. For those of you using console or http proxy passwords, +we converted to the more-secure digest method and improved the security for console forms. +{%- endtrans %} + +{% trans -%} +For those of you already running development builds, your router should automatically +update to 0.9.4-0 using the new in-network torrent facility. +For those running 0.9.3-0, you will update normally using in-network HTTP, and +we will have more information for you when we release 0.9.5. +{%- endtrans %} + +{% trans -%} +Files are available on the `download page`_. +{%- endtrans %} + +.. _{% trans %}`download page`{% endtrans %}: {{ get_url('downloads_list') }} + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +**{% trans %}Major Changes{% endtrans %}** + +- {% trans %}Big rework of the update system; Preliminary support for updates via i2psnark{% endtrans %} +- {% trans %}Add per-destination outbound priorities{% endtrans %} + +**{% trans %}Bug Fixes{% endtrans %}** + +- {% trans %}Fix major bug that reduced SSU connection limits which reduced tunnel build success rates{% endtrans %} +- {% trans %}Fix bug with external I2CP that prevented some external apps from working{% endtrans %} +- {% trans %}Fixed several bugs in i2psnark DHT{% endtrans %} +- {% trans %}Fixed bug in i2psnark PEX that inflated peer counts{% endtrans %} +- {% trans %}Handle dropped I2CP messages better{% endtrans %} +- {% trans %}Reduce overhead of I2CP messages{% endtrans %} +- {% trans %}Enforce max size in transport outbound message queues{% endtrans %} +- {% trans %}Fixes for Windows eepget.bat (new installs and PPA only){% endtrans %} +- {% trans %}Fix a bug that would drop messages of exactly 512 bytes in SSU{% endtrans %} + +**{% trans %}Other{% endtrans %}** + +- {% trans %}More performance improvements, memory reduction, and object churn reduction{% endtrans %} +- {% trans %}Better detection of network disconnections{% endtrans %} +- {% trans %}Further improvements in the SSU transport{% endtrans %} +- {% trans %}Add console password form{% endtrans %} +- {% trans %}Convert http proxy and console from basic to digest authentication for added security{% endtrans %} +- {% trans %}Improved verification of console form submissions, using jsp sessions. Cookies may now be required on forms, except when the console password is enabled{% endtrans %} +- {% trans %}Initial work on new interfaces to manage applications started via clients.config{% endtrans %} +- {% trans %}Increase minimum peer port to 1024{% endtrans %} +- {% trans %}Increase granularity of bandwidth limiter for smoother transmissions{% endtrans %} +- {% trans %}Translation updates: Chinese, French, German, Italian, Polish, Portuguese, Swedish, and Ukrainian{% endtrans %} +- {% trans %}Update GeoIP data (new installs and PPA only){% endtrans %} +- {% trans %}Update wrapper to 3.5.16 (new installs and PPA only){% endtrans %} +- {% trans %}New ARMv6 wrapper for Raspberry Pi{% endtrans %} + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + c76bea15a6b7d98227466cc8025b1eb9069997e40e9d71ff49e55b2c8ac0b995 i2pinstall_0.9.4_windows.exe + 8e670ba26c04176ace9246d91a09951975e2965b89628f620f5a3dff917298e4 i2pinstall_0.9.4.jar + 1b7d9695555ed42142b04ad6bcda083cd1a064f6354b639ad2aef4d9cd474e06 i2psource_0.9.4.tar.bz2 + 0f369d9b85793f157ec67c4d59723a2ad0c1de2a0902d35e11c26a2c74add824 i2pupdate_0.9.4.zip + 6e55d3c44d79b0727f5cd4075df4248e4d78f1736911e3504f6a8af45d973cfc i2pupdate.su2 + 561e521a707fab457c9dfe166d41b446affbff5bc58ddf770d192235f51f4e90 i2pupdate.sud diff --git a/mirror.i2p2/static/style.css b/i2p2www/blog/__init__.py similarity index 100% rename from mirror.i2p2/static/style.css rename to i2p2www/blog/__init__.py diff --git a/i2p2www/blog/helpers.py b/i2p2www/blog/helpers.py new file mode 100644 index 00000000..f5989720 --- /dev/null +++ b/i2p2www/blog/helpers.py @@ -0,0 +1,114 @@ +import codecs +import datetime +from docutils.core import publish_parts +from flask import abort, g, render_template_string, safe_join, url_for +import os +import os.path + +from i2p2www import BLOG_DIR + + +SUPPORTED_METATAGS = { + 'author': u'I2P devs', + 'category': None, + 'date': None, + 'excerpt': u'', + } + +LIST_METATAGS = [ + 'category', + ] + + +##################### +# Blog helper methods + +def get_blog_feed_items(num=0, category=None): + posts = get_blog_posts(num, True, category=category) + items = [] + for post in posts: + meta = post[1] + parts = post[2] + a = {} + a['title'] = meta['title'] + a['content'] = meta['excerpt'] if len(meta['excerpt']) > 0 else parts['fragment'] + a['url'] = url_for('blog_post', lang=g.lang, slug=post[0]) + a['updated'] = datetime.datetime.strptime(meta['date'], '%Y-%m-%d') + items.append(a) + return items + +def get_blog_posts(num=0, return_parts=False, category=None): + """ + Returns the latest #num valid posts sorted by date, or all slugs if num=0. + """ + slugs = get_blog_slugs(num) + posts= [] + for slug in slugs: + parts = render_blog_post(slug) + if parts: + meta = get_metadata_from_meta(parts['meta']) + meta['date'] = meta['date'] if meta['date'] else get_date_from_slug(slug) + meta['title'] = parts['title'] + if not category or (meta['category'] and category in meta['category']): + if return_parts: + posts.append((slug, meta, parts)) + else: + posts.append((slug, meta)) + return posts + +def get_blog_slugs(num=0): + """ + Returns the latest #num valid slugs sorted by date, or all slugs if num=0. + """ + # list of slugs + slugs=[] + # walk over all directories/files + for v in os.walk(BLOG_DIR): + # iterate over all files + slugbase = os.path.relpath(v[0], BLOG_DIR) + for f in v[2]: + # ignore all non-.rst files + if not f.endswith('.rst'): + continue + slugs.append(safe_join(slugbase, f[:-4])) + slugs.sort() + slugs.reverse() + if (num > 0): + return slugs[:num] + return slugs + +def get_date_from_slug(slug): + parts = slug.split('/') + return "%s-%s-%s" % (parts[0], parts[1], parts[2]) + +def render_blog_post(slug): + """ + Render the blog post + TODO: + - caching + - move to own file + """ + # check if that file actually exists + path = safe_join(BLOG_DIR, slug + ".rst") + if not os.path.exists(path): + abort(404) + + # read file + with codecs.open(path, encoding='utf-8') as fd: + content = fd.read() + + # render the post with Jinja2 to handle URLs etc. + rendered_content = render_template_string(content) + + # publish the post with docutils + return publish_parts(source=rendered_content, source_path=BLOG_DIR, writer_name="html") + +def get_metadata_from_meta(meta): + metaLines = meta.split('\n') + ret = {} + for metaTag in SUPPORTED_METATAGS: + metaLine = [s for s in metaLines if 'name="%s"' % metaTag in s] + ret[metaTag] = metaLine[0].split('content="')[1].split('"')[0] if len(metaLine) > 0 else SUPPORTED_METATAGS[metaTag] + if metaTag in LIST_METATAGS and ret[metaTag]: + ret[metaTag] = [s.strip() for s in ret[metaTag].split(',')] + return ret diff --git a/i2p2www/blog/views.py b/i2p2www/blog/views.py new file mode 100644 index 00000000..9a1c8b61 --- /dev/null +++ b/i2p2www/blog/views.py @@ -0,0 +1,54 @@ +from flask import abort, render_template, request +from werkzeug.contrib.atom import AtomFeed + +from i2p2www import BLOG_POSTS_PER_FEED, BLOG_POSTS_PER_PAGE, cache +from i2p2www.blog.helpers import get_blog_posts, get_blog_feed_items, get_date_from_slug, get_metadata_from_meta, render_blog_post +from i2p2www.helpers import Pagination, get_for_page + + +############ +# Blog views + +@cache.memoize(600) +def blog_index(page, category=None): + all_posts = get_blog_posts(category=category) + posts = get_for_page(all_posts, page, BLOG_POSTS_PER_PAGE) + if not posts and page != 1: + abort(404) + pagination = Pagination(page, BLOG_POSTS_PER_PAGE, len(all_posts)) + if category: + return render_template('blog/category.html', pagination=pagination, posts=posts, category=category) + else: + return render_template('blog/index.html', pagination=pagination, posts=posts) + +@cache.memoize(600) +def blog_post(slug): + # try to render that blog post.. throws 404 if it does not exist + parts = render_blog_post(slug) + + if parts: + meta = get_metadata_from_meta(parts['meta']) + meta['date'] = meta['date'] if meta['date'] else get_date_from_slug(slug) + # now just pass to simple template file and we are done + return render_template('blog/post.html', parts=parts, title=parts['title'], body=parts['fragment'], slug=slug, meta=meta) + else: + abort(404) + +def blog_rss(): + # TODO: implement + pass + +@cache.cached(600) +def blog_atom(category=None): + feed_title = 'I2P Blog' + if category: + feed_title = 'I2P Blog Category: %s' % category + feed = AtomFeed(feed_title, feed_url=request.url, url=request.url_root) + items = get_blog_feed_items(BLOG_POSTS_PER_FEED, category=category) + for item in items: + feed.add(item['title'], + item['content'], + content_type='html', + url=item['url'], + updated=item['updated']) + return feed.get_response() diff --git a/i2p2www/downloads.py b/i2p2www/downloads.py new file mode 100644 index 00000000..a8fddd4a --- /dev/null +++ b/i2p2www/downloads.py @@ -0,0 +1,69 @@ +from flask import redirect, render_template +try: + import json +except ImportError: + import simplejson as json +from random import randint + +from i2p2www import CURRENT_I2P_VERSION, MIRRORS_FILE + + +################### +# Download handlers + +# Read in mirrors from file +def read_mirrors(): + file = open(MIRRORS_FILE, 'r') + dat = file.read() + file.close() + lines=dat.split('\n') + ret={} + for line in lines: + try: + obj=json.loads(line) + except ValueError: + continue + if 'protocol' not in obj: + continue + protocol=obj['protocol'] + if protocol not in ret: + ret[protocol]=[] + ret[protocol].append(obj) + return ret + +# List of downloads +def downloads_list(): + # TODO: read mirror list or list of available files + return render_template('downloads/list.html') + +# Specific file downloader +def downloads_select(file): + if (file == 'debian'): + return render_template('downloads/debian.html', file=file) + mirrors=read_mirrors() + data = { + 'version': CURRENT_I2P_VERSION, + 'file': file, + } + obj=[] + for protocol in mirrors.keys(): + a={} + a['name']=protocol + a['mirrors']=mirrors[protocol] + for mirror in a['mirrors']: + mirror['url']=mirror['url'] % data + obj.append(a) + return render_template('downloads/select.html', mirrors=obj, file=file) + +def downloads_redirect(protocol, file, mirror): + mirrors=read_mirrors() + if not protocol in mirrors: + abort(404) + mirrors=mirrors[protocol] + data = { + 'version': CURRENT_I2P_VERSION, + 'file': file, + } + if mirror: + return redirect(mirrors[mirror]['url'] % data) + return redirect(mirrors[randint(0, len(mirrors) - 1)]['url'] % data) diff --git a/i2p2www/helpers.py b/i2p2www/helpers.py new file mode 100644 index 00000000..04bd49ee --- /dev/null +++ b/i2p2www/helpers.py @@ -0,0 +1,57 @@ +from math import ceil +from werkzeug import import_string, cached_property + +######################## +# General helper methods + +def get_for_page(items, page, per_page): + from_item = (page-1)*per_page + to_item = page*per_page + return items[from_item:to_item] + + +######################## +# General helper classes + +class LazyView(object): + def __init__(self, import_name): + self.__module__, self.__name__ = import_name.rsplit('.', 1) + self.import_name = import_name + + @cached_property + def view(self): + return import_string(self.import_name) + + def __call__(self, *args, **kwargs): + return self.view(*args, **kwargs) + +class Pagination(object): + def __init__(self, page, per_page, total_count): + self.page = page + self.per_page = per_page + self.total_count = total_count + + @property + def pages(self): + return int(ceil(self.total_count / float(self.per_page))) + + @property + def has_prev(self): + return self.page > 1 + + @property + def has_next(self): + return self.page < self.pages + + def iter_pages(self, left_edge=2, left_current=2, + right_current=5, right_edge=2): + last = 0 + for num in xrange(1, self.pages + 1): + if num <= left_edge or \ + (num > self.page - left_current - 1 and \ + num < self.page + right_current) or \ + num > self.pages - right_edge: + if last + 1 != num: + yield None + yield num + last = num diff --git a/i2p2www/legacy.py b/i2p2www/legacy.py new file mode 100644 index 00000000..685dc8c5 --- /dev/null +++ b/i2p2www/legacy.py @@ -0,0 +1,135 @@ +from flask import g, redirect, url_for + + +############## +# Legacy paths + +LEGACY_FUNCTIONS_MAP={ + 'announcements': {'function': 'blog_index', 'params': {}}, + 'debian': {'function': 'downloads_select', 'params': {'file': 'debian'}}, + 'download': {'function': 'downloads_list', 'params': {}}, + 'statusnotes': {'function': 'blog_index', 'params': {}}, +} + +LEGACY_PAGES_MAP={ + 'applications': 'volunteer/develop/applications', + 'benchmarks': 'misc/benchmarks', + 'bittorrent': 'docs/applications/bittorrent', + 'blockfile': 'docs/spec/blockfile', + 'bob': 'docs/api/bob', + 'bounties': 'volunteer/bounties', + 'bounty_arabic': 'volunteer/bounties/arabic-trans', + 'bounty_btcclient': 'volunteer/bounties/btc-client', + 'bounty_datastore': 'volunteer/bounties/datastore', + 'bounty_debpack': 'volunteer/bounties/deb-pack', + 'bounty_i2phex': 'volunteer/bounties/i2phex', + 'bounty_ipv6': 'volunteer/bounties/ipv6', + 'bounty_rutrans': 'volunteer/bounties/russian-trans', + 'bounty_silc': 'volunteer/bounties/silc', + 'bounty_syndie2012': 'volunteer/bounties/syndie-2012', + 'bounty_unittests': 'volunteer/bounties/unit-tests', + 'bounty_vuzeplugin': 'volunteer/bounties/vuze-plugin', + 'clt': 'misc/clt', + 'common_structures_spec': 'docs/spec/common-structures', + 'configuration': 'docs/spec/configuration', + 'contact': 'about/contact', + 'cvs': 'misc/cvs', + 'datagrams': 'docs/api/datagrams', + 'dev-guidelines': 'volunteer/guides/dev-guidelines', + 'developerskeys': 'volunteer/develop/developers-keys', + 'donate': 'volunteer/donate', + 'faq': 'support/faq', + 'getinvolved': 'volunteer', + 'glossary': 'support/glossary', + 'halloffame': 'about/hall-of-fame', + 'how': 'docs', + 'how_cryptography': 'docs/how/cryptography', + 'how_elgamalaes': 'docs/how/elgamal-aes', + 'how_garlicrouting': 'docs/how/garlic-routing', + 'how_intro': 'docs/how/intro', + 'how_networkcomparisons': 'about/comparison', + 'how_networkdatabase': 'docs/how/network-database', + 'how_peerselection': 'docs/how/peer-selection', + 'how_threatmodel': 'docs/how/threat-model', + 'how_tunnelrouting': 'docs/how/tunnel-routing', + 'htproxyports': 'support/browser-config', + 'i2cp': 'docs/protocol/i2cp', + 'i2cp_spec': 'docs/spec/i2cp', + 'i2np': 'docs/protocol/i2np', + 'i2np_spec': 'docs/spec/i2np', + 'i2pcontrol': 'docs/api/i2pcontrol', + 'i2ptunnel': 'docs/api/i2ptunnel', + 'i2ptunnel_migration': 'misc/i2ptunnel-migration', + 'i2ptunnel_services': 'misc/i2ptunnel-services', + 'impressum': 'impressum', + 'intro': 'about/intro', + 'invisiblenet': 'misc/invisiblenet', + 'jbigi': 'misc/jbigi', + 'jrandom-awol': 'misc/jrandom-awol', + 'license-agreements': 'volunteer/develop/license-agreements', + 'licenses': 'volunteer/develop/licenses', + 'links': 'links', + 'manualwrapper': 'misc/manual-wrapper', + 'ministreaming': 'docs/api/ministreaming', + 'minwww': 'misc/minwww', + 'monotone': 'volunteer/develop/monotone', + 'myi2p': 'misc/myi2p', + 'naming': 'docs/naming', + 'naming_discussion': 'docs/discussions/naming', + 'netdb_discussion': 'docs/discussions/netdb', + 'newdevelopers': 'volunteer/guides/new-developers', + 'newtranslators': 'volunteer/guides/new-translators', + 'ntcp': 'docs/transport/ntcp', + 'ntcp_discussion': 'docs/discussions/ntcp', + 'othernetworks': 'about/comparison/other-networks', + 'papers': 'research/papers', + 'performance-history': 'support/performance/history', + 'performance': 'support/performance/future', + 'plugin_spec': 'docs/spec/plugin', + 'plugins': 'docs/plugins', + 'ports': 'docs/ports', + 'protocols': 'docs/protocol', + 'ratestats': 'misc/ratestats', + 'release-signing-key': 'volunteer/develop/release-signing-key', + 'roadmap': 'volunteer/roadmap', + 'sam': 'docs/api/sam', + 'samv2': 'docs/api/samv2', + 'samv3': 'docs/api/samv3', + 'signedkeys': 'volunteer/develop/signed-keys', + 'socks': 'docs/api/socks', + 'streaming': 'docs/api/streaming', + 'supported_applications': 'docs/applications/supported', + 'team': 'about/team', + 'techintro': 'docs/how/tech-intro', + 'todo': 'volunteer/todo', + 'transition-guide': 'misc/transition-guide', + 'transition-guide.txt': 'misc/transition-guide.txt', + 'transport': 'docs/transport', + 'tunnel-alt-creation': 'docs/spec/tunnel-creation', + 'tunnel-alt': 'docs/tunnels/implementation', + 'tunnel': 'docs/tunnels/old-implementation', + 'tunnel_discussion': 'docs/discussions/tunnel', + 'tunnel_message_spec': 'docs/spec/tunnel-message', + 'udp': 'docs/transport/ssu', + 'udp_spec': 'docs/spec/ssu', + 'unidirectional-tunnels': 'docs/tunnels/unidirectional', + 'updates': 'docs/spec/updates', + 'upgrade-0.6.1.30': 'misc/upgrade-0.6.1.30', +} + +def legacy_show(f): + lang = 'en' + if hasattr(g, 'lang') and g.lang: + lang = g.lang + if f in LEGACY_FUNCTIONS_MAP: + return redirect(url_for(LEGACY_FUNCTIONS_MAP[f]['function'], lang=lang, **LEGACY_FUNCTIONS_MAP[f]['params'])) + elif f in LEGACY_PAGES_MAP: + return redirect(url_for('site_show', lang=lang, page=LEGACY_PAGES_MAP[f])) + else: + return redirect(url_for('site_show', lang=lang, page=f)) + +def legacy_meeting(id): + return redirect(url_for('meetings_show', id=id, lang='en')) + +def legacy_status(year, month, day): + return redirect(url_for('blog_post', lang='en', slug=('%s/%s/%s/status' % (year, month, day)))) diff --git a/i2p2www/meetings/__init__.py b/i2p2www/meetings/__init__.py new file mode 100644 index 00000000..e69de29b diff --git a/i2p2www/meetings/helpers.py b/i2p2www/meetings/helpers.py new file mode 100644 index 00000000..204aff0a --- /dev/null +++ b/i2p2www/meetings/helpers.py @@ -0,0 +1,77 @@ +import codecs +import datetime +from docutils.core import publish_parts +from flask import abort, g, safe_join, url_for +import os +import os.path + +from i2p2www import MEETINGS_DIR + + +######################## +# Meeting helper methods + +def get_meetings_feed_items(num=0): + meetings = get_meetings(num) + items = [] + for meeting in meetings: + a = {} + a['title'] = meeting['parts']['title'] + a['content'] = meeting['parts']['fragment'] + a['url'] = url_for('meetings_show', lang=g.lang, id=meeting['id']) + a['updated'] = (meeting['date'] if meeting['date'] else datetime.datetime(0)) + items.append(a) + return items + +def get_meetings(num=0): + meetings_ids = get_meetings_ids(num) + meetings = [] + for id in meetings_ids: + parts = render_meeting_rst(id) + if parts: + try: + date = datetime.datetime.strptime(parts['title'], 'I2P dev meeting, %B %d, %Y @ %H:%M %Z') + except ValueError: + try: + date = datetime.datetime.strptime(parts['title'], 'I2P dev meeting, %B %d, %Y') + except ValueError: + date = None + a = {} + a['id'] = id + a['date'] = date + a['parts'] = parts + meetings.append(a) + return meetings + +def get_meetings_ids(num=0): + """ + Returns the latest #num valid meetings, or all meetings if num=0. + """ + # list of meetings + meetings=[] + # walk over all directories/files + for v in os.walk(MEETINGS_DIR): + # iterate over all files + for f in v[2]: + # ignore all non-.rst files + if not f.endswith('.rst'): + continue + meetings.append(int(f[:-4])) + meetings.sort() + meetings.reverse() + if (num > 0): + return meetings[:num] + return meetings + +def render_meeting_rst(id): + # check if that file actually exists + name = str(id) + '.rst' + path = safe_join(MEETINGS_DIR, name) + if not os.path.exists(path): + abort(404) + + # read file + with codecs.open(path, encoding='utf-8') as fd: + content = fd.read() + + return publish_parts(source=content, source_path=MEETINGS_DIR, writer_name="html") diff --git a/i2p2www/meetings/logs/1.log b/i2p2www/meetings/logs/1.log new file mode 100644 index 00000000..fcd913ca --- /dev/null +++ b/i2p2www/meetings/logs/1.log @@ -0,0 +1,695 @@ +--- Log opened Wed May 22 02:01:22 2002 +02:01 <+logger> Logging started +02:01 <@nop> ok +02:01 <@nop> welcome to this humble first meeting +02:01 <@nop> first and foremost +02:02 <@nop> Thank you's to all of you for your efforts +02:02 <@nop> especially as we all know that there is Real life to deal with +02:02 <@nop> and that we've done pretty well so far +02:02 <@nop> meeting: The reason for this meeting(s) will be plural hopefully +02:03 <@nop> we need to gain some order for development and schedules and tasks that are being done for IIP +02:03 <@nop> whether it's contributed tasks, ala #factory, or backend, ala inform, or core ala IIP software +02:03 <@nop> or ircd +02:03 <@nop> :) +02:03 <@mids> . +02:04 <@mids> (to indicate I am here) +02:04 <@nop> I think we all share a common goal in supporting this project, and it has it's rewards just knowing the technology is becoming possible to help a lot of people with free speech, privacy, anonymity and security +02:04 <@nop> this is a great project in the matter, because it challenges all of these topics, and is sparking intereests especially in these times +02:05 <@mids> agenda: +02:05 <@mids> - Welcome (nop) +02:05 <@mids> - Status of developers / projects (nop) +02:05 <@mids> - Website (nym) +02:05 <@mids> - Release Roadmap +02:05 <@mids> - Documentation (cohesion, codeshark, mids) +02:05 <@mids> - Question Round +02:05 <@nop> so welcome all, and again thank you. +02:05 <@Chocolate> (still connected) +02:05 <@nop> next on the agenda: Status of developers +02:05 <@nop> hehe +02:06 <@nop> before we get there +02:06 <@nop> a side not, this meeting is invite only +02:06 <@nop> but will be logged and published to the public for viewing and/or comments +02:06 <@nop> as well as the results +02:06 <@mids> live logging is on http://mids.student.utwente.nl/~mids/iip-dev.txt +02:06 <@mids> (in case you drop out) +02:07 <@nop> ok +02:07 <@nop> Status of developers +02:07 <@mids> who first? :) +02:08 <@nop> UserX and I have been focusing on IIP 1.1 to be released, but we're to the point of no return where we would like to release iip rc2 for running tests by the team and public, but would like more thorough docs, so that's the hold up there +02:08 <@nop> let's talk about docs +02:08 <@nop> status : mids, cs, ? +02:08 <@codeshark> you :) +02:08 <@mids> . +02:08 <@mids> me +02:09 <@mids> I joined IIP when I heared about it on Freenet +02:09 <@mids> after some chatting etc, I made Trent +02:09 <@mids> our big friend :) +02:09 <@nop> yes +02:09 <@mids> also done some ircd patches +02:09 <@mids> helped by Chocolate, thanks! +02:10 <@mids> I promised 0x90 to look into doing client 2 client encryption +02:10 <@mids> I did a lot of talking and research +02:10 <@mids> but nothing is done :( +02:10 <@nop> tis ok +02:10 <@mids> currently I kind of dropped it, because I lacked time and willing +02:10 <@mids> something slightly related: +02:11 <@mids> I coded bankbot +02:11 <@mids> another helpfull application for IIP :) +02:11 < nym> hey +02:11 <@nop> welcome +02:11 < nym> only non op ;) +02:11 <@nop> mids +02:11 <@nop> continue +02:11 -!- mode/#iip-dev [+o nym] by Chocolate +02:11 -!- mode/#iip-dev [+o nym] by mids +02:11 <@nym> sorry, i was under the impression the meeting was tomorrow +02:12 <@mids> last act of me was that I ported the docs to LaTeX, more about that later +02:12 <@mids> . +02:12 <@nop> k +02:12 <@nop> cs +02:12 <@codeshark> ok, like mids i heared about iip on freenet +02:12 <@codeshark> and chatted with nop about it :) +02:13 <@codeshark> then i made our inform relaychecker script, that keeps a list of the running nodes +02:13 <@codeshark> now i'm doing some anonymail stuff... +02:14 <@nop> on a note +02:14 <@nop> cs is responsible for the "dynamic routing system" that being the inform server +02:14 <@nym> freenet is too slow, so i came here +02:15 <@codeshark> anything else? +02:15 <@codeshark> hmm, the docs +02:16 <@codeshark> i created a windows version of our docs (.chm format) +02:16 <@nop> yes +02:16 <@nop> which will need updating once cohesion finishes the docs +02:17 <@codeshark> i also made a test for the docbook format +02:17 <@codeshark> but we'll come back to this later +02:17 <@mids> you bet I will +02:17 <@codeshark> that's it for now +02:18 <@codeshark> chocolate? +02:19 <@Chocolate> I first heard of IIP on freenet from CofE +02:19 <@Chocolate> after seeing a couple of anouncements about it on his freesite +02:19 <@Chocolate> I decided to try it out +02:19 <@Chocolate> since then I have helped with misc things +02:20 <@Chocolate> running a relay (precrypto, the DH didnt work on my 486) +02:20 <@Chocolate> helping to debug the memory leak (by killing the ircd for about 5 hours...) +02:21 <@Chocolate> my first main codeing cotribution to IIP was helping mids with Trent +02:21 <@nop> kewl +02:21 <@nop> don't forget hydrabot +02:21 <@nop> or eyek0n +02:21 <@Chocolate> oh yea right +02:22 <@Chocolate> hydrabot came out of a disire to be able to see waht was happening on #freenet on OPN +02:22 <@Chocolate> unfortunetly the bot died the sad death of flexibilitise +02:23 <@nop> and along came eyek0n +02:23 <@nop> :) +02:23 <@Chocolate> yes, eyek0n is a modified changate that was hacked up to serve the purpos that HydraBot was intended to fill +02:25 <@Chocolate> I also maintain a misc group of xchat and other scripts for IIP, some donated, others my own +02:25 <@Chocolate> my current area of work is on ThreadChat, a realtime BBS/forums type sytem over IRC +02:25 <@Chocolate> . +02:25 <@nop> kewlness +02:26 <@nop> ok +02:26 <@nop> is that all? +02:26 <@mids> ardvark just joined, he isnt a developer, but a zeroday user... he isnt allowed to introduce himself because otherwise this will take too long +02:26 <@mids> maybe a quicky for nym? +02:26 <@nop> ok +02:27 <@nop> nym : developer intro +02:28 <@nop> ok +02:28 <@nop> I'll say it +02:28 <@nop> he seems to be off somewhere +02:28 <@mids> go for it +02:28 <@nop> he comes to us as the web developer of freenetprojects' site +02:29 <@nop> and we're open he can give us a make over to give us a more global appeal of anonymous irc/internet projects +02:29 <@nop> open == hoping +02:29 <@nop> he will be focusing on a lighter design with press releases etc +02:29 <@nop> gives us less of a hobby and more of a serious developer team look to us +02:30 <@nop> even though you can't see us +02:30 <@nop> :) +02:30 <@nop> hehe +02:30 <@mids> :) +02:30 <@nop> ok +02:30 <@nop> agenda list +02:30 <@nop> please +02:30 <@mids> - Website (nym) +02:30 <@mids> - Release Roadmap +02:30 <@mids> - Documentation (cohesion, codeshark, mids) +02:30 <@mids> - Question Round +02:31 <@Chocolate> can't do website now if nym isnt here +02:31 <@nop> ok well let's talk about website when nym seems awake +02:31 <@nop> so Release Roadmap +02:31 <@mids> . +02:31 <@nop> our first focus on this is rc2 +02:31 <@nop> This is for testing the changes and added features and to break in any network changes that may occur before 1.1 +02:32 <@nym> hi +02:32 <@nym> i'm here +02:32 <@nop> ok +02:32 <@nop> website +02:32 <@nop> please +02:32 <@nop> then we'll go back +02:33 <@nop> to roadmap +02:33 <@nym> well the website is coming along, although i thought i had another day to get something to you guys +02:33 <@nop> do you have any screen shots at all +02:33 <@nym> not on hand +02:33 <@nop> hmm mids +02:34 <@mids> http://mids.student.utwente.nl/~mids/draft2.jpg +02:34 <@nop> do you have draft2? +02:34 <@nop> ok +02:34 <@nop> that will give people an idea +02:34 <@nop> this is older +02:34 <@nop> but it's what we have +02:34 <@nym> okay, well what i need to know is what release this is going to correspond with +02:34 <@nop> the current release +02:34 <@nop> and we can modify easily +02:34 <@mids> nop: current as in rc2 ? +02:35 <@nop> current as as soon as we can get something +02:35 <@nym> i thought you had a big release on the horizon +02:35 <@nop> so focus on iip 1.1 rc1 +02:35 <@mids> :) +02:35 <@nop> yes +02:35 <@nop> but +02:35 <@nop> we need something going +02:35 <@nop> other than what we have +02:35 <@nop> something that has a easily modifiable template +02:35 <@mids> we want to have the site betatested too, same with the rcs +02:35 <@nop> so that it can be prepped for released +02:35 <@mids> so we can go 'big' on 1.1 +02:35 <@nop> releases +02:35 <@nop> ok +02:35 <@nop> site betatested +02:35 <@nym> yeah, but what releases do you have coming, and when? +02:36 <@nop> rc 2 +02:36 <@nop> is coming +02:36 <@nop> cohesion is working on docs +02:36 <@nop> cs it's easy for you to do .chm correct? +02:36 <@nym> no idea what those are +02:36 <@codeshark> nop: we'll have to talk about docs later :) +02:36 <@nop> ok +02:36 <@Chocolate> are we on the relese roadmap now or are we still on the website? +02:36 <@nop> website +02:36 <@nop> we went back +02:36 <@nop> because nym is awake ;) +02:36 <@nym> aye +02:37 <@nop> let's focus on getting somethign up +02:37 <@nop> then we can be focused on release +02:37 <@nym> hrm okay +02:37 <@nym> well i'll get something going +02:37 <@nop> we would like to have it modifiable +02:37 <@nop> this is key +02:37 <@nop> so it's template based +02:38 <@mids> nym: can you name the changes between the draft and current? +02:38 <@nym> umm +02:38 <@nop> umm, current I have no clue on +02:38 <@nop> he might +02:38 <@nop> I saw n : and answered +02:38 <@nop> my bad +02:38 * nop will shut up now +02:39 <@nym> okay.. +02:39 <@nym> well lots +02:39 <@nym> font changes +02:39 <@nym> drop shadows +02:39 <@nym> the logo looks different (invisiblenet.net/iip/) +02:40 <@nym> better crunchbox logo +02:40 <@mids> great +02:40 <@nym> we don't have a mac version, so i dropped that +02:41 <@nym> plus i dropped anything to do with invisible im because that's not happening +02:41 <@nop> not as that title +02:41 <@nop> no +02:41 <@nym> that's confusing +02:41 <@nop> IIP is simple and makes sense +02:41 <@mids> question: what about FreeBSD & OpenBSD ? its the same release as linux +02:41 <@nop> let's focus on the now for that +02:42 <@nop> yes +02:42 <@nop> mids it is +02:42 <@mids> freebsd users will be offended if they would have to click on a Tux +02:42 <@nop> hmm +02:42 <@nop> good point +02:42 <@nym> i worry about the neiche market still tho +02:42 <@nop> can we have maybe a tux and a devil fucking ;) +02:42 <@nop> hehe +02:43 <@nym> well we'll offer source +02:43 <@nym> freebsd doesn't need a logo +02:43 * nop says bad jokes too oftne +02:43 <@nop> often +02:43 <@nop> ok +02:43 <@nop> so when can we get a new draft +02:43 <@nop> give us a solid date +02:43 <@nop> GMT +02:43 <@mids> :) +02:44 <@nym> well i can promise progress by next meeting +02:44 <@nym> but i'm in the middle of a big contract atm +02:44 <@nop> how much progress, like something we can put up? +02:44 <@nym> well no +02:44 <@nop> hmm +02:44 <@codeshark> nop: it's better to wait until it's complete anyway +02:45 <@nym> ditto +02:45 <@mids> codeshark: current looks is terrible +02:45 <@nop> understood codeshark : just thinking maybe we can revamp the current look though +02:45 <@mids> I suggest reverting to the old look +02:45 <@nop> it needs a lighter feel +02:45 <@mids> till the site is done +02:46 <@nop> we could do that unless nym can maybe dish out a slightly lighter look for it possibly +02:46 <@nop> with a donation button and just like an intro page +02:46 <@nym> for what? +02:46 <@nop> for the site, instead of the under construction we have now +02:46 <@nop> maybe like something gives more an intro and download software right off the bat +02:47 <@Chocolate> well the old site is linked +02:47 <@nop> then take them to the site behind it +02:47 <@codeshark> nop: just make the old page easier to find +02:47 <@codeshark> put the link up a bit +02:47 <@nop> ok +02:47 <@nym> well edit that as needed +02:47 <@nop> ok +02:47 <@nop> we'll figure something out +02:47 <@mids> k +02:47 <@nym> i'm going to keep working on the big release +02:47 <@nop> can you give us a draft by friday? +02:48 <@nym> most likely +02:48 <@nop> ok +02:48 <@codeshark> but keep the intro page until the new site is complete +02:48 <@mids> screenshot is enough +02:48 <@nop> thnk you +02:48 <@nop> yes +02:48 <@nop> screenshot/draft +02:48 <@nop> same thing to me +02:48 <@nym> i've got everything on my laptop now.. +02:48 <@nym> it shouldn't be a problem +02:48 <@nop> ok +02:49 <@nop> next part +02:49 <@nop> back to roadmap release +02:49 <@mids> what are the current limits for doing RC2 ? +02:49 <@codeshark> what's missing except the docs? +02:49 <@nop> RC2 as stated earlier is designed to get all the bugs out and adjust to changes for 1.1 final release +02:49 <@nop> that's it +02:49 <@nop> docs are needed +02:49 <@nop> and new .chm +02:49 <@nop> and cs +02:49 <@nop> make sure we don't include .ini or listen.ref this time +02:49 <@nop> :) +02:49 <@codeshark> sure :) +02:50 <@codeshark> has been removed +02:50 <@nop> ok +02:50 <@nop> also +02:50 <@nop> cs +02:50 <@nop> in the future +02:50 <@nop> as people move over +02:50 <@nop> to rc2 +02:50 <@nop> we can wait a week +02:50 <@nop> but then after that I need you to add closedelay: infront of the networkprotocol = closedelay:etc +02:50 <@nop> this is a key feature +02:50 <@nop> that has been wanted +02:51 <@codeshark> ok +02:51 <@nop> this tells the network to hold on to the user even if he dies out from 15-45 seconds +02:51 <@mids> (closedelays makes your connection staying up for a little while if your client or node disconnects) +02:51 <@mids> (making it harder to track you to your IP) +02:51 <@nop> yes +02:51 <@codeshark> will it break rc-1 clients completely? +02:51 <@Chocolate> can you reconnect to the held connection? +02:51 <@nop> if we wait a week +02:52 <@nop> most people should have upgraded +02:52 <@codeshark> i'd wait a bit longer than a week +02:52 <@nop> ok +02:52 <@nop> maybe 2 +02:52 <@nop> because the network side will have it +02:52 <@nop> it will still help you +02:52 <@nop> but by the time rc2 is everyone +02:52 <@nop> the entire network will help support your delayed presence +02:53 <@nop> please send a ! now if you guys are willing to pre-test before we officially release rc2 +02:53 <@nop> making sure things go smoothly +02:53 <@mids> ! +02:53 <@codeshark> !I have to do that anyway ;) +02:53 <@nop> hehe +02:53 <@nop> anyone else? +02:54 <@codeshark> tell me if you're ready for rc-2 and i'll prepare the windows installer and *nix tgz +02:54 <@nop> irc is tough for this anyway +02:54 <@codeshark> you have my pager e-mail? +02:54 <@nop> ok, should be ready for friday, but I really want docs updated +02:54 <@nop> no I don't +02:54 <@Chocolate> ! +02:54 <@nop> please send it privately +02:54 <@codeshark> sure +02:55 <@nop> this is a publicly logged channel +02:55 <@nop> you all have mine I assume +02:55 <@Chocolate> the one that's only outgoing? +02:56 <@nop> hehe +02:56 <@nop> ok, to answer cs's question +02:57 <@nop> closedelay - we need to hold off at least 2 weeks +02:57 <@nop> and promote it well enough +02:57 <@nop> so that people do upgrade +02:57 <@nop> the challenge is +02:57 <@nop> making sure relay users can just simply upgrade +02:57 <@nop> without redoing the relay system +02:57 <@nop> that should be trivial +02:57 <@nop> but it's a necessity to make sure it's done right +02:57 <@nop> choc +02:57 <@nop> your question of reconnecting to help connection +02:57 <@nop> can you elaborate +02:57 <@nop> held +02:57 <@nop> not help +02:58 -!- mode/#iip-dev [+o UserX] by mids +02:58 <@nop> welcome userx +02:58 <@UserX> hi +02:58 <@nop> can you redisplay agenda list for userx +02:58 <@nop> please +02:58 <@mids> - Welcome (nop) +02:58 <@mids> - Status of developers / projects (nop) +02:58 <@mids> - Website (nym) +02:58 <@mids> - Release Roadmap +02:58 <@mids> - Documentation (cohesion, codeshark, mids) +02:59 <@mids> - Question Round +02:59 <@nop> we're on release roadmap +02:59 <@Chocolate> the closedelay holds the connection open after the user drops from IP change, or (ip) network failure +02:59 <@nop> yes +02:59 <@Chocolate> can you reconnect to this help connection? +02:59 <@nop> no +02:59 <@nop> it's just for traffic analysis preventative assistance +02:59 <@Chocolate> ok, great +02:59 <@nop> but there is a major other feature that works +02:59 <@Chocolate> I assume it's help for a random time? +02:59 <@mids> s/help/held/ +03:00 <@codeshark> nop: did you include the feature that tries another relay if the first doesn't work? +03:00 <@Chocolate> s/help/held/ +03:00 <@nop> it will retry (default 5 tries) (random time yes) when connecting to network nodes so you won't get disconnected each time a relay doesn't work +03:00 <@codeshark> ok, cool +03:00 <@nop> codeshark see above, yes +03:00 <@mids> wow, cool +03:00 <@nop> this does not help you if a relay fails and you're already conencted to it +03:01 <@nop> that is what closedelay does though +03:01 <@nop> is makes you stall a bit visually +03:01 <@codeshark> btw: we should stop adding features now +03:01 <@nop> it's already stopped +03:01 <@nop> :) +03:01 <@codeshark> :) +03:01 <@nop> cvs rc2 is tagged I believe is it not userx? +03:01 <@UserX> it's not tagged yet +03:01 <@codeshark> nop: not only to rc-2 but also to 1.1 +03:01 <@nop> correct +03:02 <@nop> rc2 is just testing of the already set features +03:02 <@nop> and changes +03:02 <@nop> also cs +03:02 <@nop> make sure we have a decent changelog +03:02 <@nop> I sent you that list +03:02 <@codeshark> hmm +03:02 <@codeshark> email? +03:02 <@nop> the changes and features +03:02 <@nop> yes +03:02 <@nop> I cc'd to you and cohesion +03:02 <@Chocolate> could there be someway to verify that a relay has been added to the check list? +03:02 <@nop> UserX - we're covering roadmap release, is there anything you would like to add +03:02 <@codeshark> k, got it +03:03 <@Chocolate> like I have no idea if my relay isnt on the public list becouse it didnt inform right, or becouse it's to unreliable +03:03 <@nop> choc it's most likely not +03:03 <@nop> but that's ok +03:03 <@nop> we forgive you +03:03 <@nop> :) +03:04 <@codeshark> hmm, i think i should add a page where you can get infos about you relays +03:04 <@mids> Chocolate's question is often asked +03:04 <@codeshark> "you relays" = "your relay" +03:04 <@nop> and you don't think that would compromise anything +03:05 <@Chocolate> make the request come from the IP that the relay in question would have? +03:05 <@codeshark> i won't show too much info +03:05 <@codeshark> and i need to keep the deleted relays too +03:05 <@codeshark> just mark them as deleted +03:05 <@nop> spoofing +03:05 <@nop> UserX - looks like that's a no +03:05 <@nop> hehe +03:06 <@codeshark> nop: tcp/ip conections can't easily be spoofed +03:06 <@nop> easily, but they can be +03:06 <@codeshark> except you are somewhere between the relay and me +03:06 <@mids> it is a php thing isnt it? (not an isproxy one) +03:06 <@codeshark> yes +03:06 <@nop> agenda list please +03:07 <@mids> - Welcome (nop) +03:07 <@mids> - Status of developers / projects (nop) +03:07 <@mids> - Website (nym) +03:07 <@mids> - Release Roadmap +03:07 <@mids> - Documentation (cohesion, codeshark, mids) +03:07 <@mids> - Question Round +03:07 <@codeshark> i'll just show a small status message ("your node is on the public list", "your node has been deleted because it was down to often..." +03:07 <@nop> ok +03:07 <@nop> cs that's fine +03:07 <@nop> any more questions on roadmap release +03:07 <@mids> . +03:07 <@nop> ok next part +03:07 <@nop> documentation +03:07 <@mids> ill do intro +03:07 <@nop> k +03:08 <@mids> cohesion is document manager +03:08 <@mids> but he isnt here +03:08 <@mids> codeshark and me are both working on it +03:08 <@mids> codeshark did .chm (windows help) and Docbook +03:08 <@mids> and will tell about that +03:08 <@mids> I did a LaTeX version, and will explain that +03:08 <@mids> why 2 systems? +03:08 <@mids> docbook was taking long, and I was getting impatient +03:09 <@mids> I knew that a release should be soon, so docs are wanted +03:09 <@mids> I have no hate regarding codeshark or anything :) +03:09 <@codeshark> :) +03:09 <@mids> codeshark, can you tell us about docbook? pro and con and status? +03:09 <@nop> also note +03:09 <@codeshark> ok +03:09 <@nop> cs was in the process of moving +03:10 <@codeshark> pro's: docbook uses xml; it can generate different output formats: pdf, html, and "CHM" +03:10 <@codeshark> cons: it's not that easy to learn. I think i'm the only one who wrote some help pages in it yet :( +03:10 <@mids> hey, I ported trent! +03:11 <@codeshark> completely? +03:11 <@codeshark> cool +03:12 <@codeshark> another thing about the docbook stuff we use: it's taken from the phphelp +03:12 <@codeshark> so we have all the tools/templates for the different output formats +03:12 <@mids> http://cvs.php.net/cvs.php/phpdoc +03:12 <@mids> they made the CHM link with M$ chm cooking facility +03:13 <@codeshark> it has been tested. it works. i converted some chapters of the doc to docbook +03:13 <@codeshark> about CHM: why CHM? +03:14 <@mids> proprietary fileformats are cool? :) +03:14 <@codeshark> nope :) +03:14 <@codeshark> it's the default help format on windows. it supports keyword search, fulltext search and has a nice grouping of the help chapters +03:15 <@codeshark> it allows you to add bitmap to the helps (see iip.chm) +03:15 <@nop> also very handy for IIP help systray option +03:15 <@codeshark> btw: mids, there's also a *nix chm viewer +03:15 <@mids> sure +03:16 <@mids> done? +03:16 <@codeshark> yes +03:16 <@mids> okay, LaTeX is a much older system then docbook +03:17 <@mids> pro: its well known in the academic word, it doesnt use XML, it support different outputs: ps, dvi, pdf, html, txt. and I know it +03:17 <@mids> con: it doesnt use XML, it is not very easy to learn, no native .CHM support +03:17 <@nop> interrupt +03:17 <@nop> real quick +03:17 <@mids> I converted the whole v1.1.2-pre9 doc +03:17 <@mids> ok +03:18 <@nop> for pdf I notice the casper logo +03:18 <@nop> can we change that to nyms logo +03:18 <@nop> for reasons of copyright +03:18 <@mids> sure +03:18 <@nop> and at the bottom +03:18 <@nop> I will send you guys a powered by InvisibleNet +03:18 <@nop> which is us +03:18 <@nop> logo +03:18 <@nop> to put at bottom of page +03:18 <@nop> :) +03:18 <@codeshark> nop: the existing pdf is just a test anyway +03:18 <@nop> yes +03:18 <@nop> I understand +03:18 <@nop> I'm just requesting +03:18 <@codeshark> it doesn't use either docbook nor latex +03:19 <@nop> k +03:19 <@nop> well, anyway +03:19 <@nop> that's a yes I assume +03:19 <@codeshark> yes +03:19 <@nop> kewl +03:20 <@mids> I converted the whole v1.1.2-pre9 doc; its on http://mids.student.utwente.nl/~mids/docdemo/ +03:20 <@mids> take a look +03:20 <@mids> it has the *.tex sourcefiles +03:20 <@mids> the Makefile +03:20 <@mids> and all the outputs... pdf, ps, dvi, txt, html and bightml +03:20 <@nop> mids +03:20 <@nop> you also have a sourceforge account +03:20 <@mids> about chm: why does chm suck? +03:20 <@nop> you have rights to make directories on the website +03:20 <@nop> so that they can be there as well +03:20 <@mids> nop: I know +03:20 <@nop> ok +03:20 <@nop> kewl +03:21 <@mids> chm sucks because it is a proprietary microsoft format +03:21 <@mids> there are no good opensource tools for it +03:21 <@codeshark> nop: these are just experiments right now. that's why they're not on the sf server +03:21 <@mids> the chm viewer for *nix is just a hard to use extractor +03:21 <@mids> nobody uses windows help files anyway +03:21 <@nop> ok +03:21 <@mids> :) +03:21 <@codeshark> hehe ) +03:21 <@codeshark> :) +03:21 <@nop> mids +03:21 <@nop> it's helpful for win32 users +03:22 <@nop> and I say we can use it for help systray option +03:22 <@mids> you can also put the pdf file in the IIP dir or the html ones +03:22 <@nop> yes +03:22 <@mids> and start the browser in the systray option +03:22 <@nop> umm +03:22 <@nop> trust me .chm looks nice in windows +03:22 <@codeshark> sure, but do you have a chapter list in html? +03:22 <@nop> so stick with that for win32 +03:22 <@mids> I am not against CHM for IIP, I am just not going to do it +03:22 <@nop> cs will +03:22 <@nop> no worries +03:22 <@codeshark> aehm +03:23 <@codeshark> there's a small problem +03:23 <@mids> have fun codeshark :P +03:23 <@nop> uhh +03:23 <@codeshark> i don't want to have 2 version of the docs like we have now +03:23 <@nop> sup? +03:23 <@nop> umm +03:23 <@nop> maybe we can make chm a separate doc +03:23 <@nop> :) +03:23 <@codeshark> that's how it is now +03:23 <@codeshark> chm and pdf are seperate +03:23 <@nop> that's all I'm saying +03:23 <@nop> welcome back userx +03:23 <@codeshark> but that's not how it should be +03:23 <@codeshark> right mis? +03:23 <@codeshark> mids? +03:23 <@mids> right +03:24 <@codeshark> what are the possibilities? +03:24 <@nop> chm is a nice plus +03:24 <@codeshark> 1) use docbook,... +03:24 <@nop> one +03:24 <@nop> not everyone has pdf viewers +03:24 <@nop> chm for win32 is built in +03:24 <@codeshark> 2) use latex and try to create the chm's from the htmls +03:24 <@codeshark> 3) manually synchronize chm and html +03:24 <@codeshark> 4) drop chm support +03:25 <@nop> x on 4 +03:25 <@mids> 5) make a light chm with only the menu functions explained +03:25 <@nop> hopefully x 3 +03:25 <@nop> yes +03:25 <@nop> that's what I was thinkign +03:25 <@nop> 5 +03:25 <@mids> (manually) +03:25 <@nop> like a man page +03:25 <@nop> :) +03:25 <@Chocolate> eavryon on win will have a web browser +03:25 <@mids> and link it for more info to the full doc as html, pdf , dvi, ps whatever +03:25 <@nop> sounds good +03:25 <@Chocolate> you should be able to generate an index page from the LaTeX/docbook +03:25 <@codeshark> ok, i'll look at it +03:25 <@nop> ok +03:26 <@nop> is that it for docs? +03:26 <@mids> no +03:26 <@nop> ok +03:26 <@nop> sorry +03:26 <@mids> still pieces of doc should be written on the unix part +03:26 <@nop> continue +03:26 <@nop> also man page +03:26 <@nop> is that completed +03:26 <@mids> its still missing in the current one, cohesions work didnt have it +03:26 <@nop> and symbolicly link iip with isproxy +03:26 <@nop> like man iip +03:26 <@mids> man page is in CVS for weeks +03:26 <@nop> will give man isproxy +03:26 <@mids> nobody commented on it, so I assume it is perfect +03:26 <@nop> ok +03:26 <@nop> nice +03:27 <@nop> UserX +03:27 <@nop> will IIP as is auto-install man pages +03:27 <@codeshark> nop: does it have "make install" yet? +03:27 <@nop> he might be having connectivity issues +03:27 <@nop> yes +03:27 <@mids> hairy topic +03:28 <@nop> the concern is upgrading relay node users +03:28 <@mids> location of manpages is really system dependant +03:28 <@nop> right +03:28 < UserX> make install should install the man page +03:28 <@codeshark> yeah, they have to manually upgrade from rc1 to rc2 +03:28 <@mids> configure in 1.2 will fix that +03:28 <@nop> ok +03:29 -!- mode/#iip-dev [+o UserX] by mids +03:29 <@nop> userx hasn't identified - policy +03:29 <@nop> no ops to unidentified users +03:29 <@nop> ok +03:29 <@nop> spoken late +03:29 <@mids> The nickname userx is registered and identified +03:29 <@nop> :) +03:29 <@nop> I am really lagging +03:29 <@mids> np +03:29 <@nop> I still have it saying that it's not +03:30 <@nop> ok +03:30 <@nop> continue +03:30 <@mids> I am finished with my part of docs +03:30 <@nop> cs +03:30 <@nop> what did you mean they have to manually upgrade +03:30 <@codeshark> hmm +03:30 <@codeshark> docbook vs latex? ;) +03:30 <@mids> latex short term, docbook long term? +03:31 <@codeshark> output of both formats is ok (except missing chm support of latex) +03:31 <@nop> I just want to make sure installer sees already known node.ref and listen.ref in there +03:31 <@nop> as well as isproxy.ini +03:31 <@nop> cohesion needs to get on the unix stuff +03:31 <@codeshark> nop: windows? +03:31 <@mids> mind you that we also have 2 translatins +03:31 <@nop> yes +03:31 <@nop> obviously as long as we don't include our own isproxy.ini, node.ref or listen.ref for unix +03:32 <@nop> we should be fine +03:32 <@nop> we might want to have a blurb in doc about upgrading +03:32 <@nop> to install in same directory +03:32 <@nop> for upgraded node +03:32 <@nop> or import your .ref and .ini files +03:32 <@nop> etc +03:32 <@nop> to be discussed later +03:32 <@mids> . +03:32 <@nop> agenda list please +03:33 <@mids> - Welcome (nop) +03:33 <@mids> - Status of developers / projects (nop) +03:33 <@mids> - Website (nym) +03:33 <@mids> - Release Roadmap +03:33 <@mids> - Documentation (cohesion, codeshark, mids) +03:33 <@mids> - Question Round +03:33 <@nop> ok +03:33 <@nop> question round +03:33 <@nop> any questions +03:33 <@codeshark> nop: i think i'm already handling the upgrading stuff. but i have to check +03:33 <@nop> ok +03:33 <@mids> why is not everybody here? +03:33 <@nop> thnx cs +03:33 <@codeshark> we looked at it on rc1 already +03:33 <@nop> answer : real life +03:33 <@nop> :) +03:33 <@nop> ok +03:33 <@mids> is this time correct or need a better one? +03:34 <@nop> so far it's not conflicting +03:34 <@mids> (it took 1:30 hours now_ +03:34 <@nop> well +03:34 <@nop> this is a first meeting +03:34 <@nop> so I can see why +03:34 <@nop> we'll get better +03:34 <@codeshark> well a bit earlier would be nice +03:34 <@nop> and shorter +03:34 <@nop> :) +03:34 <@codeshark> if possible +03:34 <@nop> the conflict with that +03:34 <@mids> yes, please +03:34 <@nop> hmm +03:34 <@nop> I can't do too much earlier +03:34 <@codeshark> it's 4 am soon :( +03:34 <@mids> 1 hour shorter would be fine +03:34 <@codeshark> yeah, right +03:35 <@nop> hmm +03:35 <@mids> more q's? +03:36 <@codeshark> mids: what is cohesion doing right now? +03:36 <@nop> let's try this for a bit, and see if it's workable +03:36 <@codeshark> on the docs? +03:36 <@nop> dunno +03:36 <@mids> codeshark: dont ask me +03:36 <@nop> he needs to work on contact +03:36 <@mids> btw 1 yodel for everybody attending this meeting +03:36 <@nop> thnx +03:36 <@nop> :) +03:36 <@codeshark> hehe, thanks mids :) +03:37 <@codeshark> btw: right now we have 4 systems to create help files :( +03:37 <@nop> closing +03:38 <@mids> I will leave the log running for a couple of hours +03:38 <@mids> its available on that url +03:38 <@nop> meeting ajouned, thank you for all attending +03:38 <@nop> see you next week +03:38 <@codeshark> same time, same place? +03:38 <@nop> yes +03:39 <@nop> thnx all +03:39 * nop will brb after these messages +03:39 * codeshark will go to sleep soon +03:39 <@mids> night +03:46 <@nop> night +03:47 <+logger> Ended logging +--- Log closed Wed May 22 03:47:55 2002 diff --git a/i2p2www/meetings/logs/1.rst b/i2p2www/meetings/logs/1.rst new file mode 100644 index 00000000..4b2cf2a4 --- /dev/null +++ b/i2p2www/meetings/logs/1.rst @@ -0,0 +1,9 @@ +I2P dev meeting, May 22, 2002 +============================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/10.log b/i2p2www/meetings/logs/10.log new file mode 100644 index 00000000..50b97044 --- /dev/null +++ b/i2p2www/meetings/logs/10.log @@ -0,0 +1,162 @@ +--- Log opened Tue Sep 03 23:55:46 2002 +23:56 <@mids> test +--- Day changed Wed Sep 04 2002 +00:34 < athena> hello :) +00:34 < athena> no specific agenda today? +00:36 -!- mode/#iip-dev [+o nop] by mids +00:36 -!- mode/#iip-dev [+v logger] by mids +00:36 <@mids> not yet atleast +00:55 < athena> OQP... cute :) +00:56 <@mids> what is OQP? +00:56 < athena> occupe', i'm guessing +00:56 <@mids> ic +00:58 < gabierOQP> OQP=occupé in french +00:58 < gabierOQP> busy +00:58 -!- gabierOQP is now known as legabier +00:59 <@mids> compris +01:00 <@mids> Tue Sep 3 23:00:00 UTC 2002 +01:00 <@mids> Welcome to the 10th IIP meeting +01:00 <@mids> Agenda: +01:00 <@mids> 1) Welcome +01:00 <@mids> 2) Website status update +01:00 <@mids> 3) ... +01:00 <@mids> a) Questions +01:00 <@mids> . +01:00 <@mids> lets go to point 1 +01:00 <@mids> welcome all +01:00 < legabier> why freenet is so slow and iip so fast? +01:01 <@mids> legabier: can we keep that till part a ? +01:01 < legabier> ok +01:01 <@mids> part 2 +01:01 <@mids> nop: status update? +01:02 <@mids> hm +01:02 <@mids> the website is in CVS +01:02 <@mids> nop has reviewed the files +01:03 <@mids> but there are some parts without good text +01:03 <@mids> and the support area needs a better layout +01:03 <@mids> appart from that it is done +01:03 <@mids> I wont tell you when the site is up +01:03 <@mids> but you are free to do private bettings on the online time :) +01:04 <@mids> . +01:04 <@mids> nop probably has something to add +01:04 <@mids> lets wait 3 min or something +01:06 < athena> lol +01:06 <@mids> I guess nop is too busy with editing the website to answer +01:06 <@mids> okay well... +01:06 <@mids> before we go to the question round.. any other items we should discuss? +01:08 <@mids> guess not :-) +01:08 <@mids> I like it when everybody agrees :) +01:08 <@mids> . +01:08 <@mids> question from legabier: "why freenet is so slow and iip so fast?" +01:08 <@mids> freenet is a different program, there is no technical relationship between IIP and Freenet +01:08 <@mids> Freenet is completely decentralized.. IIP isn't (yet) +01:08 <@nop> haha +01:09 <@mids> Freenet is intended for file transfer, while IRC over IIP uses short lines +01:09 <@nop> just because freenet is decentralized +01:09 <@nop> is not the reason why IIP is fast +01:09 <@mids> well, enlighten us, o master yoda :) +01:10 <@nop> differences +01:10 <@nop> freenet == high volume, low speed, static (archived) content +01:10 <@nop> iip == low volume, high speed, dynamic content +01:10 <@nop> different concepts all together, centralized or decentralized, IIP will remain fast +01:11 * mids hopes that too +01:11 * nop knows that +01:11 <@mids> ok +01:11 <@mids> does that answer your question legabier ? +01:12 < legabier> yes merci :) +01:13 * mids aims the spotlight in the audience.. searching for the next question and/or comment +01:13 < athena> why are there so few public relays (besides the ones nop runs and mids', i see only 2 or 3 others usually)? do we have no volunteers or does the uptime checker reject a lot of them? +01:13 < Sheige> I got 8 of them.... I guess +01:14 < Sheige> (still a few) +01:14 < athena> how many is that if you don't count mids' and nop's? +01:14 <@mids> 5 +01:14 <@mids> source: http://invisiblenet.net/iip/crypto/node.ref +01:15 < athena> hmmm, ok... guess i need to pull down a new one... still, 20 or so public nodes would be nice :) +01:15 <@mids> I _think_ that the uptime checker is a bit too strict +01:16 <@mids> codeshark had to pause it some time ago when the net was down +01:16 <@mids> otherwise it would kick all relays out +01:17 <@nop> the strict checking is a good thing +01:17 <@nop> you'd have more problems if you had a lot of relays not working +01:17 <@nop> it's better to have lower number with solid relay connection +01:17 <@mids> nop: well.. but the reannounces dont seem to work +01:17 <@nop> than a bunch of crappy ones +01:17 <@nop> yes they do +01:17 <@mids> hm +01:17 <@nop> it just takes time +01:17 <@nop> plus if you're a relay you won't see your route +01:17 <@mids> then why do we only have 7 :) +01:17 <@nop> because the stability of the relays +01:18 <@nop> it may take a few more days for them to show up +01:20 <@nop> talk to codeshark about this +01:20 <@nop> he would have more detail +01:20 <@nop> I will test it with him +01:20 <@mids> ok +01:21 <@mids> I think that I have somehow too many nodes connecting to my relay +01:21 <@mids> but maybe there are a lot more users then we know about :) +01:21 < athena> how many connections do you have? +01:22 <@mids> I dont know if I should tell that +01:22 * mids does some back channel talking +01:22 < athena> could be that you're the best reachable relay +01:22 <@mids> heh, I wouldnt say that with the recent lack of stability +01:22 < athena> i often find that i can't connect through half of the hosts in node.ref +01:23 < athena> and when you start with 7 that's not a whole lot of reliable relays +01:23 <@nop> well, most usually are that are on +01:23 < athena> just relating my experience... +01:24 <@nop> maybe it's recent +01:25 <@mids> it would be interesting to measure uptime... +01:25 <@mids> but... +01:25 < athena> you'd have to measure it from topologically diverse sites +01:27 <@mids> nop: would you be against that? +01:27 <@mids> if this whole thing wasn't about anonymity, I would love to see a lot of statistics :) +01:27 <@nop> umm, if it exposes attacking info, yes +01:28 <@nop> maybe we'll set up a non-anonymous weary system later and take stats +01:28 < athena> i would say any publicly available stats SHOULD be published +01:28 <@nop> especially as it gets bigger +01:28 < athena> rely on the security of IIP, not on keeping info secret +01:28 <@nop> well athena, if anyone was taking stats, they should be published +01:28 <@nop> but no one is so far +01:28 <@nop> anyone who is please publish your findings +01:28 <@nop> ;) +01:29 < athena> maybe i will :p +01:29 <@mids> well.. I'll try to collect stats in a 'fair' way +01:29 <@mids> without abusing my public node-powers +01:29 <@mids> what I can collect that way, everybody can +01:29 < athena> that's exactly what i meant, great +01:30 < ArdVark> why not abuse your public node power and show us what that entails too mids? +01:30 <@mids> now if I disappear from the IIP chat system... it is because someone doesnt like me collecting the stats ;) +01:30 <@mids> ArdVark: maybe that is the next step... +01:30 < athena> ArdVark: lol, excellent point! since anyway can become a public node... +01:31 < athena> s/anyway/anyone/ +01:31 <@mids> athena: install a public relay and you do it :) +01:31 < ArdVark> I wanna see the failures as well as the successes of this beast reported +01:32 <@mids> would be cool to have 100 'agencies' all running a public relay to log connections, but in the meanwhile helping to boost the anonymity +01:33 < ArdVark> on a different topic, not to end the current one, has there ever been any thought to adding wiki to invisiblnet? or too much trouble? +01:33 <@mids> wiki as in wikiwiki? +01:33 < ArdVark> yes +01:33 <@mids> those $#@&%@ infobots are already some wiki +01:33 < athena> mids: how do you know i don't already run a public relay ;) +01:34 < ArdVark> I love those infobots mids ;) +01:34 <@mids> ArdVark: I know you do +01:34 <@mids> ArdVark: if you put a webserver 'behind' IIP.. then you could install a wiki on it +01:35 < ArdVark> ok, that is reasonable I guess +01:35 <@mids> but running a webserver over irc isnt too great +01:35 < ArdVark> no I meant the website +01:35 <@mids> oh +01:35 <@mids> you mean on the normal website +01:35 < ArdVark> yes +01:36 <@mids> guess you could do that +01:36 <@mids> otoh.. you could use a public wiki too.... +01:36 < ArdVark> ok +01:37 <@mids> I think we shouldnt really install the wiki on sourceforge.... not now +01:37 <@mids> since it is some work to install/tweak etc +01:38 <@mids> but someone could run a wiki, and then IIP could point to it +01:38 < ArdVark> fine +01:39 <@mids> ArdVark: but maybe a public wiki for IIP (like freenet has now) is the way to go +01:39 <@mids> . +01:39 < ArdVark> yeah ok +01:41 <@mids> I am going to sleep. feel free to keep chatting here :) +01:41 < athena> night mids +01:49 <@mids> for those who want to play with a wiki: http://mids.student.utwente.nl/~mids/phpwiki/ +01:49 <@mids> I dont care what you do with it :) +02:00 -!- mode/#iip-dev [+o codeshark] by Trent +--- Log closed Wed Sep 04 07:03:17 2002 diff --git a/i2p2www/meetings/logs/10.rst b/i2p2www/meetings/logs/10.rst new file mode 100644 index 00000000..b5d141f6 --- /dev/null +++ b/i2p2www/meetings/logs/10.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 4 2002 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/100.log b/i2p2www/meetings/logs/100.log new file mode 100644 index 00000000..951c09e1 --- /dev/null +++ b/i2p2www/meetings/logs/100.log @@ -0,0 +1,189 @@ +14:02 < jrandom> 0) hi +14:02 < jrandom> 1) 0.3.3 & current updates +14:02 < jrandom> 2) NativeBigInteger +14:03 < jrandom> 3) ??? +14:03 < jrandom> 0) hi +14:03 * jrandom waves +14:03 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-July/000372.html +14:03 < jrandom> (thanks to hypercubus' prodding i got it out before the meeting :) +14:04 < jrandom> ok, jumping on in +14:04 < jrandom> 1) 0.3.3 & current updates +14:06 < jrandom> there's a truckload of info in the email describing whats going on, and there should be a substantial reduction in bandwidth usage coming up +14:07 < jrandom> it won't be backwards compatible because it changes a lot of things, so the next release will be a bumpy upgrade as well, but c'est la vie +14:08 < jrandom> anyone have any questions wrt the 0.3.3 rev or the things posted in the status notes? +14:08 * dm waves +14:08 * jrandom is seeing 23s lag here @ freenode +14:09 * hypercubus sees 0.10 secs lag +14:09 < jrandom> ah back to normal +14:09 < jrandom> ok, if there's nthing, we can just jump in to 2) NativeBigInteger +14:10 < jrandom> Iakin3 has modified some things so it'll be simpler to deploy the crypto code out of the box, which is Good +14:10 < jrandom> every once in a while i look in the netDb and see some people with 2-400ms delays when doing ElGamal encryption, which means some people aren't using jbigi +14:11 < jrandom> (and everyone should use jbigi) +14:12 < deer> how do you know they are not just on slow computers +14:12 < Sonium> why isn't it use automaticaly? +14:12 < hypercubus> because it must be custom compiled for each platform +14:12 < jrandom> we might be able to get that deployed in this next rev, but we'll see +14:12 < deer> If the DLL is not present, the program continue using java-only code (needed for cross-platform support) +14:12 < hypercubus> and currently the platform is not detected +14:12 < jrandom> Nightblade: thats possible, of course +14:13 < jrandom> oOo right, we definitely will keep that functionality +14:13 < deer> Nope, force the existence of the dll an .so files, even if empty or useless +14:13 < jrandom> actually, thats another one of the things we're gaining with some of the current mods i'm working on - we only need to do half as many elGamal encryptions (since the sourceRouteBlock is gone) +14:14 < jrandom> hmm oOo? +14:14 < jrandom> why would we want to do that? +14:15 < deer> Force a check of the _existence_ of the library files. If they are not use, you most likely aren't on a x86 Win/Linux platform and are forced to use the Java code. Anyway you did your best to force the use of native stuff +14:15 < jrandom> oh, right, we have always checked for libjbigi.so / jbigi.dll, the thing Iakin's code adds is the ability to package up a whole bunch of DLL and .so files into a jar and choose the *right* one at runtime +14:16 < hypercubus> +14:16 < jrandom> (falling back on pure java if none match) +14:17 < jrandom> anyway, thats some good stuff that'll hopefully help new users out a bunch +14:17 < jrandom> (and saves me the time of doing some ugly drop down boxes on the admin interface :) +14:18 < jrandom> ok, if there's nothing more on that, i think thats all i've got +14:18 < jrandom> so moving on to 3) ??? +14:18 < jrandom> anyone else have anything they want to bring up? +14:18 < hypercubus> someone should run a spellchecker on the new website ;-) +14:19 < jrandom> you've got cvs access now... :) +14:19 < jrandom> (module: i2pwww) +14:19 < hypercubus> damn +14:19 < deer> The corruption on big transfer, even local one, is under investigation (like grabbing several Mb from your own eepsite) ? +14:20 < hypercubus> i've had many interrupted downloads of big files, but never a corruption +14:20 < jrandom> hmm, most instances of that issue have been resolved, but i've heard reports recently about it. i haven't gone through the app layer and audited things yet again +14:21 < jrandom> i consider interrupted downloads corrupted +14:21 < jrandom> it must work first time, all the way through +14:21 < hypercubus> well you can't help it, because that's what happens on the real WWW too ;-) +14:21 < deer> Not when the grabber is on the same computer then the server ^^ +14:22 < jrandom> oOo: can you reproduce that? +14:22 < jrandom> (or is it intermittent?) +14:22 < deer> jrandom: Did twice, was thinking it was knowed, will try again +14:23 < jrandom> thanks. if you can reproduce it, please let me know the details of the test and i'll dig further into it. +14:23 < jrandom> (i've got to audit the app layer again anyway soo) +14:23 < deer> jrandom: No problem, thanks +14:24 < jrandom> ok, anyone else have anything they want to ask/bring up? +14:25 < cat-a-puss> I'm still interested in talking about how to do myI2P +14:25 < cat-a-puss> I may be able to bring a few people in in a few months +14:25 < jrandom> awesome! +14:26 < hypercubus> a class project? ;-) +14:26 < cat-a-puss> something like that ;-) +14:27 < jrandom> i think once we get 0.4 out there with the new web interface, it should be much easier to put together apps (like myi2p) w/ a web frontend +14:27 < cat-a-puss> so you think that can be done on the purely application layer? +14:27 < jrandom> absolutely +14:28 < jrandom> what else did you have in mind? +14:28 < cat-a-puss> well the network DB could be used to store metadata +14:28 < jrandom> ahh +14:28 < cat-a-puss> would it have access to that? +14:28 < hypercubus> *cough* +14:28 < jrandom> no, nothing has access to the netDb +14:29 < jrandom> we're able to work some magic in the netDb because its quite focused just on serving as our distributed routing table +14:29 < hypercubus> cat-a-puss: what you want is the DHT that Nightblade is working on +14:29 < jrandom> myi2p (et al) could certainly use a DHT on top of i2p though +14:30 < hypercubus> (enclave) +14:30 < jrandom> what sort of metadata were you thinking about? +14:31 < cat-a-puss> well I invesioned doing something like chanels in Frost which runs off of an ssk in freenet +14:31 < cat-a-puss> so you run the ssks on the DHT on top of I2p +14:31 < jrandom> right +14:31 < jrandom> that might be a bit of an overkill for some things though +14:31 < cat-a-puss> but you still need a metakey that lists all the people's ssks that are subscribed to the channel +14:32 < dm> dht over i2p... +14:32 * dm doesn't see that working reliable any time soon. +14:32 < Connelly> a generic DHT library would be nice +14:32 < dm> reliably +14:32 < deer> what's a dht library +14:32 < cat-a-puss> that needs to work diferently ... +14:33 < jrandom> cat-a-puss: i suppose it depends on what sort of activity would go on, but while frost style boards might be good for some things, fmb style boards might be good for others, and blog aggregators might be good for still others +14:34 < Connelly> well a kademlia implementation or somesuch +14:34 < Connelly> I assume enclave would be something like it +14:34 < deer> i think i'm going to do some changes on LibSAM first +14:34 < deer> only two weeks of classes left, for me, counting this week +14:34 < deer> then I will be able to do some stuff I hope +14:35 < jrandom> w00t! :) +14:37 < cat-a-puss> jrandom: basicly the goal is to be all things to all people. If the network does not do everything, people will use something else. (and it needs to be better at it to attract cover traffic) +14:38 < jrandom> i've worked on too many projects that try to do the 'swiss army knife' style - if you build it, they will come +14:38 < hypercubus> the network is a transport layer, not the application layer ;-) +14:38 < jrandom> it very, very, very rarely works out. +14:38 < jrandom> the i2p transport layer should support all possible point to point comm, definitely +14:38 < jrandom> but applications on top of i2p should be user friendly - meaning they address a specific user need and help them with it +14:39 < jrandom> the masses don't want a comm layer, they want a way to talk to people, to read what people say, and to explore +14:39 < Connelly> naw, we should create an XUL, and all new Gecko system +14:39 < Connelly> then build a conglomerate of Mozilla programs on top of that +14:39 < Connelly> then integrate collaborative systems into Mozilla ;) +14:40 < cat-a-puss> great provided the app has enough control over the comm layer to make it do what it wants. +14:40 < dm> Maxthon > Mozilla +14:40 < jrandom> cat-a-puss: absolutely. all apps using SAM, I2CP, or the SDK can do what every other app can do +14:41 < jrandom> (which should be sufficient [the functionality / API is modelled after JMS and MOMs, which has been battle tested for well over a decade in industry]) +14:43 < cat-a-puss> ok, so I've essencialy got: Tcp, datagram, both of those + anonymity if I want it, and a DHT that operates above all that. +14:44 < hypercubus> you have some anonymity, whether you like it or not ;-) +14:44 < cat-a-puss> so the app cannot set the tunnel lenth to 0 even if it wants to? +14:44 < jrandom> right - i2p itself is the TCP/datagram stuff, and the enclave DHT app could be used as a base for the data store +14:44 < jrandom> absolutely +14:45 < jrandom> in fact, with 0 hop tunnels and the defense Connelly outlined last week, it can be pretty anon vs some attackers +14:45 < jrandom> er, i misread what you said. yes the app can set the tunnel length to 0, but in fact, that still provides some degree of anonymity +14:46 < cat-a-puss> ok +14:46 < jrandom> (sufficient for some people, but insufficient vs some statistical attacks) +14:46 < hypercubus> if you wanted no anonymity, you shouldn't be running your traffic over i2p +14:47 < cat-a-puss> and different apps on the same host/port I assume are just handled with seperate keys? +14:47 < jrandom> exactly +14:47 < deer> low anonymity could be popular for running p2p over I2P ? +14:47 < cat-a-puss> then the only question I have left is some sort of an "answering service" +14:47 < jrandom> right DrWoo - filesharing / etc would probably be able to use 0 hop tunnels +14:48 < deer> hey soros! +14:48 < hypercubus> i'm thinking BitTorrent-style apps on i2p would likely need 0-1 hop tunnels +14:48 < Connelly> jrandom: which defense for 0 hop tunnels? +14:48 < deer> hey woo :D +14:48 < deer> soros: you were hiding hehe +14:48 < cat-a-puss> IE: set something up in the i2p database where my traffic goes to someone else while I am offline, and then when I come back up I contact them and they fill me in on what I missed? +14:48 < cat-a-puss> they needn't be able to decrypt it +14:48 < deer> gave up on iip for a few months +14:48 < dm> soros and drwoo reunion... +14:48 < dm> TEAR +14:48 < hypercubus> cat-a-puss: again, app layer stuff +14:49 < jrandom> cat-a-puss: i don't know, that sort of functionality i hadn't really envisioned w/ myi2p, but there are a few ways to do it +14:49 < deer> is this going to freenode automatically ? +14:49 < deer> oops.. this is i2p sorry +14:49 < jrandom> Connelly: using strict ordering for the peers in the tunnel +14:49 < deer> soros: it's a little confusing lol +14:50 < Connelly> ok +14:50 < hypercubus> we need to run a poll on the forum to vote for a new name for myI2P ;-) +14:51 < jrandom> betty +14:51 < hypercubus> MyBetty? +14:51 < dm> MY TOOPIE +14:51 < jrandom> heh +14:51 < deer> how about acropolis....... was that it? +14:51 < hypercubus> Betty Toop? +14:51 < deer> MOAP2P +14:51 < deer> I2P H@ME +14:51 < deer> Mother of all P2P +14:52 < hypercubus> nightblade: yeah, acropolis +14:52 < hypercubus> i like it +14:53 < dm> How about: Pipi in your face +14:53 < hypercubus> dm: you do know this is all going in the meeting log right? ;-) +14:53 < Connelly> man, I got a great idea +14:53 < deer> Center of the Known I2P +14:53 < dm> hypercubus: pipi in your face +14:53 < Connelly> let's integrate a 3D user-programmable RPG into I2P H@ME +14:53 < deer> call it HyperCube. +14:54 < Connelly> and use Mozilla technology to do it :) +14:54 < dm> Maxthon pipi on mozilla +14:54 < Connelly> fine, Maxthon +14:54 < hypercubus> you on a xul kick connelly? ;-) +14:54 < Connelly> yeah! +14:55 < Connelly> but we should create a whole XML-based programming language +14:55 < Connelly> it would be more flexible that way +14:55 < jrandom> and then lets build our own hardware too +14:55 < hypercubus> i2p custom wireless mesh routers +14:55 < jrandom> and put together a distribution company with ships and trains to get 'em out there! :) +14:55 < dm> I know CPUs +14:55 < dm> I build one +14:56 < deer> plus build the chip production facilities ... +14:56 < Connelly> yeah, an anonymous shipping corporation +14:56 < hypercubus> call it WhoEx +14:56 < Connelly> and use reflectors on the moon to beam laser internet traffic to each other! +14:57 < hypercubus> time to boof the meeting i sense +14:57 < jrandom> on that not.. +14:57 < jrandom> er, note +14:57 < jrandom> anything else people want to bring up? if not, we've got the forums and the mailing list +14:57 < jrandom> (and we're here all the time ;) +14:57 * jrandom winds up +14:57 < dm> not me, I have a life. +14:57 < dm> LOSERS +14:57 < dm> NEEEEEEEEEEEEEEEERRRRRRRRRDDDDDDDSSSSS +14:57 * jrandom *baf*s dm on the head +14:58 < jrandom> (closing the meeting) diff --git a/i2p2www/meetings/logs/100.rst b/i2p2www/meetings/logs/100.rst new file mode 100644 index 00000000..a61984da --- /dev/null +++ b/i2p2www/meetings/logs/100.rst @@ -0,0 +1,7 @@ +I2P dev meeting, July 27, 2004 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/101.log b/i2p2www/meetings/logs/101.log new file mode 100644 index 00000000..45a0748f --- /dev/null +++ b/i2p2www/meetings/logs/101.log @@ -0,0 +1,215 @@ +14:05 0) hi +14:05 1) 0.3.4 status +14:05 i guarantee that on PDforge your project will be confirmed virtually immediately ;-) +14:05 2) On deck for 0.3.4.1 +14:05 3) New web console / I2PTunnel controller +14:05 4) 0.4 stuff +14:05 5) Other development activities +14:05 6) ??? +14:05 0) hi +14:05 * jrandomi2p waves +14:05 < mihi> lla ih +14:05 * oOo goof +14:06 hi all +14:06 weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-August/000388.html +14:06 jumping right in to 1) 0.3.4 status +14:07 the net seems generally functional, both for irc and eepsites +14:07 what kind of eepsite reliability / failures are y'all seeing? +14:07 * jrandomi2p can see the irc failures here, as i see when people disconnect / etc +14:08 in general good, got out-of-memory after approx 25MBytes +14:08 but that should be fixed in cvs, as you mentioned +14:08 ah ok thats on a single 25MB download right? +14:09 yes +14:09 right +14:10 large file transfers do still seem to have problems (disconnect over time, not corruption though). i think that may be fixed with the mod mentioned, but i'm not sure +14:11 * jrandomi2p forgot to mention that oOo's roundtrip/connections_reliability.php includes both irc servers here, not just i2p, so doesnt really have the right data atm +14:11 oOo - any thoughts on what it'd take to get the bogobot code to ignore @irc.metropipe.net? +14:12 < duck> kicking hypercubus +14:12 < duck> and me to upgrade +14:12 Very few coding, a peer review by hypercubus and the update of bogobot by duke +14:13 ok cool +14:13 duke? +14:13 duck, sorry :p +14:13 * jrandomi2p thinks that sort of statistical summary would be very helpful +14:13 duke duck +14:14 The stats are made on PHP, could be given to duck, too +14:14 ok, anyone have anything to bring up wrt 0.3.4? +14:14 w3rd +14:15 ok, moving on to 2) 0.3.4.1 +14:15 i dont know what else to mention beyond whats mentioned in the mail +14:16 the StreamSinkServer and StreamSinkClient apps are compact demo apps for ministreaming (for any java devs who want to write streaming over i2p) +14:16 oh, and StreamSinkServer is kind of like aum's dropbox python app (it takes any data anyone sends it and writes it to a file) +14:17 (StreamSinkClient sends a fixed size of random data, so not too useful ;) +14:17 any thoughts / concerns / questions wrt 0.3.4.1? +14:18 * jrandomi2p estimates it'll be out in a day or two +14:19 ok, moving on at a good clip to 3) New web console / I2PTunnel controller +14:20 as mentioned in the mail, we've got the new web console pretty much functional, and a simple web interface to control / edit / create i2ptunnel instances +14:21 < protok0l> where can the protok0l get it +14:22 < protok0l> and what do i do with jetty +14:22 its all in cvs now, but i need to put up some docs on how to set it up +14:22 < protok0l> ok +14:23 * jrandomi2p wrote up and posted a ~5 step process to the channel a few days ago, but we need a simpler proc (or at least a more clear one) +14:23 < protok0l> i heard that CVS sucks +14:23 ok, can tell you once i have the docs :) +14:23 < protok0l> and there was some better CVS thingy +14:23 * oOo logged only the first 2 steps before getting disconnected :p +14:24 < protok0l> same thing with Vi +14:24 < protok0l> lol +14:24 we'll eventually moving to have this new console be the 'standard', but that'll probably wait until we've got everything integrated with hypercubus' new installer +14:26 actually +14:26 for the brave, here's the ugly steps from before: +14:26 20:19 < jrandom> w3rd hyper - could you pull latest from cvs, 'ant dist', grab build/*jar and toss them into your lib dir, mkdir $instDir/webapps/ ; cp build/routerconsole.war $instDir/webapps/ ; edit your router.config to uncomment the clientApp.3.* lines and update your classpath +14:26 20:19 < jrandom> (in the classpath, set it to: lib/i2p.jar:lib/router.jar:lib/mstreaming.jar:lib/heartbeat.jar:lib/i2ptunnel.jar:lib/netmonitor.jar:lib/sam.jar:lib/timestamper.jar:lib/ant.jar:lib/jasper-compiler.jar:lib/jasper-runtime.jar:\ +14:26 20:19 < jrandom> lib/jnet.jar:lib/org.mortbay.jetty.jar:lib/routerconsole.jar:lib/xercesImpl.jar:lib/xml-apis.jar:lib/javax.servlet.jar +14:26 < protok0l> ok screw it +14:27 in addition to that, there's a new i2ptunnel.war - take that and drop it into $instDir/webapps/ and go to http://localhost:7657/i2ptunnel/ +14:27 yeah, as i said, its a pain +14:27 *but* its functional, and I dont really have either the time or the expertise to make it much better +14:27 That's all it needs to be done ? +14:28 yup +14:28 Ok, thanks +14:28 (you'll get something looking like http://dev.i2p.net/~jrandom/config.png when you go to http://localhost:7657/config.jsp +14:29 anyway, thats that +14:29 i'd appreciate if/when people can kick it around, and hopefully come up with ways to improve it :) +14:30 mihi: any thoughts on the whole web interface idea? +14:30 < duck> nice layout +14:31 thought you'd like it duck ;) +14:31 nice +14:31 * mihi likes the layout as well +14:31 web interfaces are always great +14:32 the one i put together for i2ptunnel.war is pretty bland... functional, but bland +14:33 ok, thats that - if/when people wanna chat about it further, we've got irc and the list, etc :) +14:33 jrandomi2p: clientApp.3 is netmonitor for me +14:34 ah ok mule2p - check the router.config from cvs - +14:34 #clientApp.3.main=net.i2p.router.web.RouterConsoleRunner +14:34 #clientApp.3.name=webConsole +14:34 #clientApp.3.args=7657 127.0.0.1 ./webapps/ +14:34 obviously change the 3 to 4 and uncomment :) +14:35 replace 127.0.0.1 if you want to be able to access it remotely +14:35 (and 7657 to use a different port) +14:36 ok, thanks, have looked in the checked out i2p tree for a new router.config, but it may be elsewhere in cvs +14:36 ah sorry, yeah its i2p/installer/java/src/router.config.template +14:37 k +14:37 ok, unless there's anything else, swinging on to 4) 0.4 stuff +14:38 hmm, i dont know if there's anything i can add to whats in that paragraph in the mail +14:38 basically just a bunch of entries on my todo list :) +14:39 anyone have any questions / concerns wrt things posted there? +14:40 How is the installer doing ? ^^ +14:40 hypercubus? que tal? +14:40 patience, danielsan... good things come to those who chafe... uh, wait ;-) +14:40 hehe +14:41 no rush, just wondering how things are goin' +14:41 any problems you're running into, things we can help with, etc? +14:41 who is danielsan? +14:41 no problems, just the tedium of testing atm +14:42 w3rd +14:42 i should have written unit tests first, but oh well ;-) +14:42 hehe +14:43 java's supposed platform independence really breaks down in the area of installation tasks +14:44 * jrandom senses a bulk disconnect +14:45 Uh oh +14:45 hmmm, wonderful... what was the last thing i said? +14:45 java's supposed platform independence really breaks down in the area of installation tasks +14:46 ok, who sabotaged the meeting? ;-) +14:46 * jrandom blames jebus +14:46 maybe it was duke +14:46 you don't want to tell me my router is that important :) +14:46 < jrandom> heh +14:47 [23:46] * jrandomi2p has quit IRC (Client exited) +14:47 hehe... +14:47 if so, sorry. +14:47 anyhow, no worries about the installer's progress, i fully expect it to be ready when 0.4 is +14:47 < jrandom> duck: how many inbound tunnels do you have listening on irc.duck.i2p? +14:47 i'm not running into any head-scratchers +14:47 < jrandom> cool hypercubus +14:47 < hobbs> Reminds me -- is there a commandline-accessible way to spit out a new router.config from router.config.template? +14:47 < jrandom> nope +14:48 < jrandom> not afaik +14:48 < mihi> run the installer and copy it +14:48 < jrandom> other than java -jar install.jar +14:48 < jrandom> heh +14:48 < mihi> into a new dir i mean +14:48 < cervantes> at least not the head scratching you're all thinking of +14:48 < jrandom> ooh neat, my router dumped core +14:48 < duck> jrandom: remind me how I know the hash of irc.duck.i2p +14:48 * hypercubus wonders what cervantes means +14:49 < jrandom> cd lib ; java -cp i2p.jar net.i2p.data.TestData display Destination ../irc.privKey +14:49 < cervantes> hyper: you'd be more familiar with the term strunking :) +14:49 duck: try increasing to 3 or more inbound tunnels... seems to have helped me some +14:50 < duck> *** Building a seperate global context! +14:50 < duck> Log file logger.config does not exist +14:50 < duck> 23:49:47.387 ERROR [main ] net.i2p.util.LogManager : Log file logger.config does not exist +14:50 < duck> 23:49:49.589 CRIT [ 1 shutdown ] net.i2p.util.LogManager : Shutting down logger +14:50 < jrandom> ah hrm +14:50 guess it couldn't handle your log *cough* +14:51 < mihi> copy your logger.config everywhere ;) +14:51 < mihi> at least everywhere where your pwd could be when you run any i2p app +14:51 < duck> no I wont +14:51 < jrandom> ok, echo logger.record.net.i2p.data.TestData=INFO >> logger.config +14:52 < jrandom> actually, thats why i said (cd lib), but i forgot that i changed the default from DEBUG to ERROR in cvs +14:52 < duck> 4 inbounds +14:52 < jrandom> 4 current & ready? +14:52 < jrandom> or 2 not ready (or recently expired) and 2 ready? +14:53 < duck> now it changed to 3 with 1 not ready +14:53 < jrandom> 'k so its probably during tunnel expiration / replacement +14:54 if you update your router.config to specify 3 inbound tunnels that should help with reliability +14:54 (or you can use the new i2ptunnel web interface to do it ;) +14:54 perhaps tunnel expiration for a single client with multiple tunnels should be staggered +14:55 they are, generally - new tunnels are allocated & a new leaseSet created 60s before tunnel expiration +14:55 ah +14:55 however, during tunnel failure it has to create a new leaseSet on demand which doesnt immediately propogate +14:56 (well, it goes out on the netDb, but clients wont get that for up to a few seconds) +14:57 !who +14:57 < alpaca_> Userlist for #i2p: [hobbs] [Iakin3] [duck] [pwk__] [Sonium] [jar] [alpaca_] [interrupt] [protok0l] [mihi] [aum] [Shaun-Away] [cervantes] [jrandom] [deer] [hirvox] [Bladenight] +14:57 Userlist for #i2p: [shendaras] [duck] [josh] [mule2p] [aum] [mrflibble] [hypercubus] [TrueSeeker] [laggybot] [bogobot] [ion_] [mihi] [ion] [mule] [jteitel] [ant] [oOo_] [jrandomi2p] [dm] [ugha2p] [Ch0Hag] [jnk] [oOo] [soros] [bob] [revival] [DrWoo] [thetower] +14:57 there are some further optimizations that can be done to the tunnel pool, but i'm not sure how useful it'd be atm +14:57 ok, jumping back on track - anyone else have anything wrt 4) 0.4. stuff? +14:57 About 'large scale simulations' for 0.4, any way to prepare thus ? Need 'new' specifics applications/tools ? (transition to point 5 ? ;) ) +14:58 actually, for the sim it would be great if someone could help mod the heartbeat (or a sam-powered app) to be kind of a scriptable client / server +14:59 -!- Bladenight is now known as Nightblade +14:59 (e.g. rather than the current "every 30s, send 20KB to peer X", a "for 10 minutes, ask peer X for a 1MB file, and then pause for 60m, then ask peer Y for 1KB files" etc) +15:00 but if someone is interested in helping out with that, please let me know and we can chan +15:00 er, chat +15:00 taking that lead in, lets jump to 5) stuff y'all are doing :) +15:01 not sure how to go about covering this, lets just go down in the (arbitrary) order listed in the mail for updates? +15:01 i dont see sunshine here, and aum probably isn't up yet ;) +15:02 nightblade - how goes the battle? +15:02 < Nightblade> i have some plans for making the libsam interface like bsd sockets +15:02 < Nightblade> but i haven't done any coding on that part yet +15:02 < duck> changed to tunnels.numInbound=3 +15:03 cool duck (hopefully wait until after the meeting to restart your tunnel ;) +15:03 < duck> oh, it doesnt detect the changes? +15:03 word nightblade - is there a problem w/ the way things are now? +15:03 not until you code it to ;-) +15:03 naw duck, the clientApp lines are only read on startup +15:04 (clientApp is really outside the control of the router - thats what the i2ptunnel web app is for) +15:04 < Nightblade> no there is no problem with it the way it is now.... what i would be doing is in addition to the interface that is already there (developers could choose what they want to use) +15:04 wikked +15:05 ok, you're the boss. having variety is good, though variety means more code to maintain / etc, but its a balance +15:06 ok, moving on down the list - mule2p - how goes the outproxy stuff? +15:07 nothing done beyond the patch you have +15:07 ah ok i thought you were working on a further mod +15:07 need to find some spare time for real load balancing +15:07 w3rd +15:08 i'll get that patch applied then +15:08 thanks. and include my outproxy in the client app :) seems to be faster +15:08 heh, well, of course your proxy will be faster for you, its local :) +15:09 And no one else use it ^^ +15:09 no, it isn't +15:09 ooh, its on a different router? cool +15:09 yep, on a root server at an isp +15:10 the i2ptunnel web interface has a field for people to specify the list of outproxies, so it should be easy enough for people to tweak, but we'll get it out in the next rev & release notes +15:10 nice +15:11 ok, nickster seems to be offline atm +15:12 are there any other active client development efforts going on? +15:12 (or are any of the paused ones active, etc?) +15:13 ok, if someone wants to mention anything else on that front, we've got the list and the channel, as always :) +15:13 moving on to 6) ??? +15:13 anyone else have anything they want to bring up? +15:14 < Nightblade> nope +15:15 duck has anything to bring down ;) +15:15 s/any/some/ +15:15 * jrandomi2p pingfloods mihi +15:15 ok, on that note +15:15 * jrandomi2p winds up +15:15 * jrandomi2p *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/101.rst b/i2p2www/meetings/logs/101.rst new file mode 100644 index 00000000..6797b1b8 --- /dev/null +++ b/i2p2www/meetings/logs/101.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 3, 2004 @ 21:00 GMT +=========================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/102.log b/i2p2www/meetings/logs/102.log new file mode 100644 index 00000000..67af773f --- /dev/null +++ b/i2p2www/meetings/logs/102.log @@ -0,0 +1,114 @@ +14:04 < jrandom> 0) hi +14:04 < jrandom> 1) 0.3.4.1 status +14:04 < jrandom> 2) Updated docs +14:04 < jrandom> 3) 0.4 progress +14:04 < jrandom> 4) ??? +14:04 < jrandom> 0) hi +14:04 * jrandom waves +14:04 < jrandom> weekly status notes just posted a few seconds ago @ http://dev.i2p.net/pipermail/i2p/2004-August/000404.html +14:04 < deer> ooh +14:04 * jrandom will give y'all a sec to pull those up ;) +14:05 < jrandom> anyway, while y'all are reading, might as well swing into 1) 0.3.4.1 status +14:05 < jrandom> 0.3.4.1 is out, as you've seen +14:06 < jrandom> its only been a day or two though, but its generally seemed to be going pretty well, at least, up through a few hours ago +14:07 < jrandom> there are a pair of bugs just recently tracked down (and fixed locally, testing ongoing), and those are pretty substantial, so we'll be seeing a new release in a day or two +14:07 < jrandom> has anyone had any problems with the new web console? +14:07 < jrandom> (or, more specifically, has anyone tried it and had problems? :)( +14:07 < deer> Tried it, work well ^^ +14:07 < jrandom> w3rd +14:08 < deer> Even without any Java compiler ^^ +14:08 < jrandom> nice, yeah, it should precompile all the JSPs so people won't need javac +14:08 < jrandom> thats one thing that web app devs will need to do, but its really really easy, especially with ant +14:09 < jrandom> (template code to do it is in i2p/apps/routerconsole/java/build.xml in the 'precompilejsp' target) +14:09 < deer> jrandom, what are your concerns about outproxies? +14:09 < jrandom> i've also added in optional basic HTTP authentication to protect the console, so you'll be able to have it listen on 0.0.0.0 and access it remotely +14:10 < jrandom> oh, my concerns w/ outproxies are threefold - the cost (technical and social) of maangement, the security (outproxies get cleartext), and the anonymity (when you leave a mixnet, you are much more vulnerable to attack) +14:10 < deer> The servlet console misses a few stats from :7655 (memory consumption), and may some other stuff (shitlist), but it's great ^^ +14:11 < deer> Thanks. Just wondering. +14:11 < jrandom> "private" outproxies are different though - e.g. an anonymizer.i2p could work great without requiring trust +14:11 < jrandom> (but still limiting access to pseudonymously known clients, etc) +14:12 < jrandom> ah right oOo, I'm going to add in a new page that mirrors the old one +14:12 < jrandom> or would you suggest a new page for more stats? could you draft up what you'd like it to look like? +14:12 < jrandom> (or even code it? :) +14:12 < deer> Well, it could have been left as an exrcercice for the reader ;) +14:12 < jrandom> lol +14:13 < deer> I was only thinking of memory consumption (on main page) and a Shitlist tab, that's all _I_ miss +14:13 < deer> Might need to add shitlist reason to shitlisting, BTW ;) +14:13 < jrandom> we could probably toss the detailed shitlist into the peer profile page +14:14 < jrandom> we dont actually keep track of that right now, but you're right, we could and it'd be nice +14:14 < deer> IMHO the peer profile page is too big to be really usefull :*) +14:14 < deer> And easy to do, every code to .addshitlist() stuff have good comments just the next line ;) +14:14 < jrandom> any suggestions on improvement? +14:15 < jrandom> heh :) +14:15 < jrandom> (the netDb page imho is pretty nasty) +14:16 < jrandom> hi fvw +14:16 < fvw> heyas jrandom, everyone. +14:16 < jrandom> ok, well, if anyone has any more suggestions for the web side, please let me know +14:16 < jrandom> this new web console is really just a first pass at things, and most of my attention has been paid to the configuration side +14:17 < jrandom> ok, anyone have anything else to bring up wrt 0.3.4.1? +14:17 < jrandom> ok, moving on to 2) Updated docs +14:17 < jrandom> [see email for list of updated pages] +14:18 < jrandom> we've finally gotten all the details out of the paypal/e-gold accts as well (sorry for the delay!) +14:19 < cervantes> w00t +14:19 < jrandom> another aspect of the docs not mentioned is what we should ship with the router - on the new web console, we can easily package up any html / jsp files to serve as context sensitive help +14:19 < cervantes> sheeeit....did I really donate all that +14:20 < jrandom> cervantes definitely gets the cervantes++ this week :) +14:20 < cervantes> must have miscounted my foreign currency ;-) +14:20 < jrandom> lol +14:20 * fvw cheers for cervantes. +14:20 < jrandom> mos def +14:20 < cervantes> btw I've found an old stash of hungarian dollars.... +14:21 < jrandom> lol do you keep these under your mattress or something? +14:21 < cervantes> or forints .. +14:21 < cervantes> I always overestimate my holiday spending ;-) +14:21 < jrandom> heh +14:22 < fvw> hmm, forints. How odd. +14:22 * fvw mumbles "forinti=0..." +14:23 < jrandom> (no wonder hungarian notation doesn't use 'i') +14:23 < jrandom> +14:23 < fvw> hehe. Yes, getting back on track. New docs. very pretty. +14:23 < jrandom> w3rd +14:23 < deer> g`evening +14:24 < jrandom> there is still much to be cleaned up, so hopefully people can take a page or two and give it a once over, sending in your results / updates +14:24 < jrandom> hi kling +14:24 < jrandom> ok, anything else wrt docs? +14:24 < fvw> pweh +14:25 < jrandom> if not, moving on to 3) 0.4 progress +14:25 < fvw> perhaps not totally on topic, but the download page needs some work too. +14:25 < jrandom> ah +14:25 < jrandom> yeah +14:25 < deer> Missings Bounties deatails ? ;) +14:25 < jrandom> that particular page i'm not /too/ worried about, since it'll all be changing with the new installer, so we'll have to rewrite it anyway +14:25 < fvw> I'll kick it a bit and ask the necessary questions on the mailinglist. +14:25 < jrandom> r0x0r fvw +14:25 < fvw> oh, ok. Then I won't,. +14:26 < deer> router still up nothing special to report Uptime 32h +14:26 < jrandom> yeah, we'll still have some of that info, but most will change +14:26 < jrandom> nice kling - are you on 0.3.4.1 or 0.3.4? +14:26 < deer> .1 +14:26 < jrandom> oOo: unfortunately, we lost most of the details pages +14:27 < jrandom> but you're right, we need some filler there +14:27 < deer> Ok, too bad but can live without them ^^ +14:27 < jrandom> or to remove the links +14:27 < jrandom> that also reminds me that aum is now working on a DHT, and it seems Nightblade isn't anymore +14:27 < jrandom> (so the distributed data store 'dev' should be updated) +14:29 < jrandom> ok, anway, the 0.4 stuff is coming along - i smacked around a 100 router sim the other day with a few different bandwidth loads, and it held up pretty well +14:29 < jrandom> also fixed a nasty bug in kaffe's jthread scheduler, but there is still some funkiness on fbsd there (but not on linux) +14:30 < jrandom> i dont know how things are coming with the installer.. +14:30 < jrandom> but i do recall hypercubus working on it today, so i'm sure we'll find out more when more is ready to be found out +14:31 < deer> Hehe +14:31 < jrandom> does anyone have any questions / concerns / suggestions wrt the 0.4 rev? +14:31 < deer> "When ?" J/K ;) +14:32 < jrandom> we really don't have much more to add to the code before its ready for 0.4 +14:32 < jrandom> (but its not like 0.4 is the end game, we've got a truckload more to do after it) +14:32 < deer> To Infinity and Beyond ! +14:32 < jrandom> exactly ;) +14:33 < jrandom> ok, I guess thats all I've got to bring up, so 4) ??? +14:33 < jrandom> anyone have anything they want to discuss? +14:33 < deer> i2pcvs.i2p revival ? +14:34 < jrandom> yeah, i should probably start that up again +14:34 < jrandom> probably will once we bundle the new router console as primary, with the i2ptunnel.cfg +14:35 < deer> Ok, thanks +14:36 < jrandom> ok, if there's nothing else... +14:36 * jrandom winds up +14:36 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/102.rst b/i2p2www/meetings/logs/102.rst new file mode 100644 index 00000000..761e4134 --- /dev/null +++ b/i2p2www/meetings/logs/102.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 10, 2004 @ 21:00 GMT +============================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/103.log b/i2p2www/meetings/logs/103.log new file mode 100644 index 00000000..3a79f77f --- /dev/null +++ b/i2p2www/meetings/logs/103.log @@ -0,0 +1,211 @@ +14:05 < jrandom> 0) hi +14:05 < jrandom> 1) Network status and 0.3.4.3 +14:05 < jrandom> 2) Stasher +14:06 < jrandom> 3) ??? +14:06 < jrandom> 0) hi +14:06 * jrandom waves to all the i[2i]p & freenode gang +14:06 * hypercubus waves +14:06 < jrandom> weekly status notes posted a few seconds ago to http://dev.i2p.net/pipermail/i2p/2004-August/000409.html +14:06 < deer> It's Show Time ! +14:07 < deer> seems i2p irc doesn't love me. or it wants to keep me hot longer by regular interruptions +14:07 < jrandom> heh, yeah, that actually leads us in to 1) Network status and 0.3.4.3 :) +14:07 < jrandom> the network is pretty shitty right now +14:07 < kaji> yep +14:08 < jrandom> the problems are showing up largely from incompatabilities with the different releases that people are running, which has been injecting all sorts of neat ways to break things +14:09 < jrandom> if you check the links in the email, you can see the flooding and netDb DoS that has gone on, but it has largely subsided +14:09 < jrandom> we still do have a half dozen people running old releases (and probably 20-25 people running vanilla 0.3.4.2, with its own problems) +14:10 < jrandom> i appreciate your patience as we move forward on this. i dont want to rush a new release without first being able to effeciently route around bad nodes +14:10 < jrandom> in the past we have been able to route around bad nodes that merely perform poorly, but havent had to deal with nodes who do Bad Things +14:11 < deer> Guinea pigs bows to jrandom ! +14:11 < duck> will the next release be backward compatible? +14:11 < jrandom> perhaps duck. if we can work around those old nodes, there's no reason to make it incompatible +14:12 < duck> cool +14:12 < jrandom> anyway, there's lots of activity going on, even though y'all aren't seeing any new releases yet +14:13 < jrandom> i dont know when 0.3.4.3 will be out. perhaps tomorrow, or perhaps later this week. +14:14 < jrandom> anyone have any questions / comments / concerns they'd like to bring up wrt network status? +14:14 < kaji> will *.3 have hyper's new gui install? +14:14 < jrandom> probably not +14:14 < deer> the network looks good to me in the profiles of my boxes, just that i frequently drop +14:15 < jrandom> yeah, i understand mule. the irc con has been pretty bad for me too, but its been getting better lately +14:15 < deer> but i missed most of your discussion, so i'll shut up for now +14:15 < jrandom> if you want to try pulling from CVS, that should have an improvement, but there are frequent updates so you may want to wait until the release +14:16 < jrandom> ok anything else? if not, moving briskly along to 2) Stasher +14:16 < kaji> woot stasher +14:17 < jrandom> stasher is looking pretty cool. still quite limited functionality, but its making progress +14:17 < jrandom> if aum were awake he could give us an update... +14:17 < jrandom> aum: ping? :) +14:17 < kaji> /kick aum +14:18 < jrandom> (its early for him though, so he is probably still sleeping) +14:18 < duck> how selfish +14:18 < hypercubus> i'm impressed by it so far +14:18 < jrandom> Anyway, installing and running stasher is pretty painless, so if you can help him test it out, that'd be great +14:18 < jrandom> yeah, mos' def' +14:18 < hypercubus> it has allowed me to pull off mass goatse'ing +14:19 < jrandom> and whats an app without a goatse, 'eh? +14:19 < hypercubus> you gotta love an app that lets you upload goatse to someone's drive ;-) +14:19 < aum> pong +14:19 < jrandom> w0ah +14:19 < jrandom> 'mornin aum +14:19 < deer> quick question: do I get stasher via i2p CVS? +14:19 < aum> hi all +14:19 < jrandom> ardvark: in i2p/apps/stasher/ +14:19 < aum> ardvark: hi!!!! :) long time! +14:20 < deer> yes hi aum! good to see you mate! +14:20 < aum> ardvark: prolly easier via tarball - http://stasher.i2p or http://www.freenet.org.nz/python/stasher +14:21 < deer> ok aum, I got the tarball but needs other stuff it says? I'll not hold back the meeting, maybe I can contact you? +14:21 < aum> sure thing +14:22 < hypercubus> so, any update on stasher aum? ;-) +14:23 < aum> small update, i've added a '-l' option which allows local-only get/put +14:23 < aum> also, thinking of implementing a 'put' option which returns immediately +14:24 < aum> last night, was thinking thru issues of implementing freenet keytypes +14:24 < hypercubus> i'd like to request that successful put operations return a status... scp and many other command line net apps do this +14:24 < jrandom> SSK would quite kick ass +14:25 < jrandom> (while CHK is of course what imho is most essential) +14:25 < MikeW> One thing I always found interesting about freenet was: It would tell you why there could be high CPU usage. Sometimes (usually at startup for a minute or two) and randomly, CPU usage spikes to 100%, perhaps a estimation why it thinks java is eating my cpu? +14:25 < deer> Splitfiles ^^ +14:26 < jrandom> MikeW: if i2p is eating your CPU there is most certainly something broken going on +14:26 < aum> i've tentatively implemented splitfiles already, but haven't enabled it - want to test locally first +14:26 < jrandom> MikeW: you can tell exactly whats going on in your router by looking at the 'current job' in the router console, which is (almost always) where the CPU crunch is +14:26 < jrandom> ah cool aum +14:27 < aum> due to a recursive algo, the splitfiles thing should allow unlimited file sizes when it's done +14:27 < deer> Great, splitfiles are mandatory for serious goatse and pr0n stuff... +14:27 < deer> aum: does that include FEC? +14:27 < aum> fec not needed +14:27 < aum> fec is only required on flaky networks +14:27 < deer> Ah, I see. +14:27 < aum> i'm using kademlia, which has far better retrievability guarantee +14:27 < duck> unless nodes go down +14:28 < aum> plus, i can't be fscked doing fec anyway, it's a pain +14:28 < aum> duck: there's redundancy - refer the 'k' value in kademlia +14:28 < jrandom> duck: with a k of 20, even without any republishing it'd be ok ;) +14:28 < duck> heh, okay +14:28 < deer> aum: fec might help in case a number of nodes are removed +14:28 < jrandom> (and with republishing, it'd only hurt if all k died at the same time) +14:28 < aum> naah, i'll just increase k +14:28 < jrandom> k of 20 imho is pretty substantial +14:29 < jrandom> (since that means you have 20 full replicas of the file) +14:29 < hypercubus> users can always use standalone fec tools +14:29 < MikeW> jrandom: Under JobQueue, runners:1, active jobs:0, just finished:1, ready/waiting: 0, timed: 28 +14:29 < aum> that means 20 goatses, guys :P +14:29 < hypercubus> and publish the results +14:29 < duck> what about the britneyspears effect? +14:29 < duck> of very popular keys ending up on 1 node +14:29 < jrandom> (aka insert a 740MB file and you get 14.8GB of data you need to send) +14:30 < aum> duck: popularity is not a concept in kademlia +14:30 < duck> (ofcourse with 32KB keys that might not be terrible) +14:30 < jrandom> ok cool MikeW, but is i2p eating your CPU now? +14:30 < deer> all these kademlia messages I see on i2p are stasher related? +14:30 < MikeW> jrandom: yes +14:30 < aum> duck: and kademlia has no relaying +14:30 < hypercubus> ardvark: the stuff in the router console is the netdb kad implementation +14:31 < aum> the ideas of 'relaying', 'popularity', 'caching' etc are for freenet, which has to expose itself naked to the world, without the cloaking of I2P +14:31 < deer> runnin i2p and tor here and my cpu usage is at 3% now so :/ *shrug* +14:31 < jrandom> MikeW: then your router is unable to maintain connections and is gobbling CPU doing lots of concurrent connection establishment +14:31 < duck> ok, my brain is rotten by freenet +14:31 < duck> please have mercy :) +14:31 < deer> * shendaras comforts. +14:31 < jrandom> MikeW: if you can hang around after the meeting to debug, that'd be great +14:32 < MikeW> will do +14:32 < jrandom> ok cool aum, anything people can do to help? +14:32 < jrandom> or should we just kick the tires and file bugs? +14:33 < duck> I am trying to get used to leo +14:33 < aum> yep, file bugs to the list, if that's ok people +14:33 < duck> already like it more than eclipse +14:33 < hypercubus> what's leo? +14:33 < jrandom> (uh oh, here comes the rant ;) +14:33 < aum> duck: i use nothing but leo these days - except emacs for quick hacks, and zile for even quicker hacks +14:34 < hypercubus> as long as you're not using vi or emacs ;-) +14:34 < aum> http://leo.sf.net - gives you an outline view of your code +14:34 < hypercubus> but i'll have to try this leo myself +14:34 < aum> leo even integrates with emacs if you want +14:34 < hypercubus> it's not an editor? +14:35 < aum> +14:35 < aum> fucking msvc - it allows __int64 for 64-bit ints, but doesn't allow 'LL' or 'ULL' for 64-bit int literals +14:35 < aum> !! +14:35 < aum> +14:35 < hypercubus> ah i see +14:37 < jrandom> ok, if thats that, then we've got nothing left and can move to 3) ??? +14:37 < jrandom> anyone have anything else they want to bring up? +14:37 < hypercubus> yeah i guess i'll say a bit about the new direction of the installer +14:37 < jrandom> ok word +14:38 < hypercubus> from 0.4 onward, command line users will merely grab the i2p tarball and unpack it, then run a script to start the router and pop open the router console in lynx or whatever +14:39 < hypercubus> so not much has changed, except you don't have to go through a silly Q/A session with an installer +14:39 < hypercubus> you do all the configuration in the router console +14:39 < hypercubus> for GUI users, we have something spiffy +14:39 < jrandom> (w00t) +14:40 < hypercubus> which you can preview at http://files.hypercubus.i2p/install.jar +14:40 < jrandom> or from cvs (ant pkg ; java -jar install.jar) right? +14:40 < aum> hypercubus: how are you going with the winstaller? does it autodetect/autodownload/autoinstall java ? +14:41 < hypercubus> menu shortcuts are forthcoming, as well as systray integration and a way to install the router as a daemon +14:41 < aum> daemon? as in windows 'service' ? +14:41 < hypercubus> no, at least not for the forseeable future, they will need to click on a link on the i2p site that takes them to the official java download page +14:42 < hypercubus> the installer requires java, but that's ok since i2p does as well +14:42 < aum> hypercubus: sorry, but that'll lose 80% of users +14:42 < hypercubus> name one java project that doesn't do that +14:42 < jrandom> we'll have it eventually. +14:42 < jrandom> just not now. +14:42 < aum> freenet did it well - their winstaller takes you through the download +14:43 < jrandom> (we have so many other more important fish to fry. we dont *want* thousands upon thousands of users now) +14:43 < hypercubus> that's a consideration for 1.0 +14:43 < hypercubus> i have most of the code to pull it off done already +14:43 < aum> jrandom: i thought you said it would be for 0.4 +14:43 < deer> so you should require that java is built from source :) +14:44 < jrandom> the new installer will be for 0.4 +14:44 < hypercubus> we have scrapped all the code i have written thus far +14:44 < hypercubus> in favor of IzPack +14:44 < hypercubus> http://izpack.sf.net +14:44 < jrandom> we can offer a 15MB download bundling the two as one, but most users who will use i2p prior to 1.0 will know what "java" is +14:45 < hypercubus> this gives me time to perfect a fully public domain java installer framework which i eventually hope to move i2p back to +14:45 < hypercubus> but the priority right now is to get rid of the awful current installer ;-) +14:46 < hypercubus> (no offense to whoever hacked it together) +14:46 < deer> Got a 404.... +14:46 < duck> http://www.izforge.com/izpack/ +14:46 < hypercubus> http://www.izforge.com/izpack/ +14:47 < hypercubus> sorry about that +14:47 < hypercubus> anyhow, i would appreciate feedback on the preview installer i've put up on my eepsite +14:48 < hypercubus> it's been tested on *nix and windows, it should work on os x and solaris too +14:48 < jrandom> r0x0r +14:48 < duck> its sweet +14:48 < jrandom> yeah, it kicks ass +14:49 < hypercubus> i may hack izpack to remove those dorky icons from the buttons +14:49 < deer> hypercubus: will it destroy existing configurations or preserve them? +14:49 < hypercubus> there are no config files contained in the package +14:49 < hypercubus> so it will only overwrite jars and wars +14:49 < jrandom> (at the moment ;) +14:49 < hypercubus> well, we'll take configs into account +14:49 < deer> k, thanks +14:49 < duck> how will one start the whole jetty thang? +14:50 < duck> still a sh/bat ? +14:50 < jrandom> yes +14:50 < jrandom> the router will start w/ a script, and/or a service (calling that script) +14:50 < hypercubus> yes, and i'll throw in an exe for win users +14:50 < jrandom> w00t +14:50 < hypercubus> that will launch from the Start menu +14:50 < hypercubus> the Windows Start menu +14:51 < hypercubus> should have jetty working as a windows service by tomorrow +14:51 * jrandom mumbles *its not jetty, its i2p* +14:51 < hypercubus> ah right ;-) +14:52 < hypercubus> jetty comes with a win32 service wrapper though +14:52 < hypercubus> we can use it to wrap anything +14:52 < jrandom> yeah, there are 3-4 PD/BSD java service wrappers out there +14:52 < hypercubus> yeah, there are probably some for linux too +14:53 < jrandom> well, linux service == init script :) +14:53 < hypercubus> yeah but linux services are handled differently among even the major distros +14:53 < hypercubus> for example, gentoo uses the rc-setup script scheme +14:54 < jrandom> w3rd +14:54 < hypercubus> anyhow, i'll get it working for all the major distros and *bsd's +14:54 < hypercubus> if not more +14:55 < hypercubus> oops, s/rc-setup/rc-update/ +14:55 < hypercubus> ok, that covers everything i guess +14:55 < hypercubus> you guys can wake up now ;-) +14:55 < deer> * shendaras yawns +14:55 < jrandom> cool, thanks hyper, sounds good. +14:56 < jrandom> anyone else have anything they want to bring up? +14:56 < aum> sorry if i missed earlier discussion, but.. +14:56 < aum> what's the weather like vis a vis datagram latency etc? +14:57 < jrandom> i dont know about datagrams - the only apps i use run on top of datagrams via streams +14:57 < jrandom> network status is still pretty bad - see status notes @ http://dev.i2p.net/pipermail/i2p/2004-August/000409.html +14:58 < aum> k +14:58 < jrandom> ok, if there's nothing else... +14:58 * jrandom winds up +14:59 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/103.rst b/i2p2www/meetings/logs/103.rst new file mode 100644 index 00000000..bde03969 --- /dev/null +++ b/i2p2www/meetings/logs/103.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 17, 2004 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/104.log b/i2p2www/meetings/logs/104.log new file mode 100644 index 00000000..9cd04a32 --- /dev/null +++ b/i2p2www/meetings/logs/104.log @@ -0,0 +1,416 @@ +14:01 < jrandom> 0) hi +14:01 < jrandom> 1) 0.3.4.3 status +14:01 < jrandom> 1.1) timestamper +14:02 < jrandom> 1.2) new router console authentication +14:02 < jrandom> 2) 0.4 status +14:02 < jrandom> 2.1) service & systray integration +14:02 < jrandom> 2.2) jbigi & jcpuid +14:02 < jrandom> 2.3) i2paddresshelper +14:02 < jrandom> 3) AMOC vs. restricted routes +14:02 < jrandom> 4) stasher +14:02 < jrandom> 5) pages of note +14:02 < jrandom> 6) ??? +14:02 < jrandom> 0) hi +14:02 * jrandom waves +14:02 < deer> Hi. +14:02 < jrandom> weekly notes posted (waaay early) at http://dev.i2p.net/pipermail/i2p/2004-August/000419.html +14:03 < jrandom> so i expect you've all done your homework and have read them diligently +14:03 < jrandom> (or something) +14:03 < jrandom> ok, 1) 0.3.4.3 status +14:04 < kaji> (late hi) +14:04 < jrandom> there are a few things adjusted since the 0.3.4.3 release came out last friday, but overall the rev seems pretty stable, from what i can tell +14:04 < deer> huh. whats going on? +14:04 < deer> Oh. Nm. sorry, i usually sleep thorugh the meeting though. Hi :) +14:05 < jrandom> what are people's experiences with 0.3.4.3 with regards to eepsites / squid / etc? +14:05 < luckypunk> very quick. +14:05 < jrandom> (i can tell what people are seeing with irc) +14:05 < luckypunk> Under 3 seconds page loading sometimes. +14:06 < deer> Jrandom do kick squid's router too often ;) +14:06 < jrandom> cool lucky +14:06 < deer> working well +14:06 < luckypunk> i can open up 10 pages of things through the squid and I2P keeps up, pretty slowly though, on my 350 mhz. +14:06 < deer> snappiest it's ever been +14:06 < jrandom> yeah, i do oOo, but thats why we have www1.squid.i2p :) +14:06 < jrandom> r0x0r +14:06 < jrandom> i've heard a few reports of excessive CPU usage - is that hitting people often? +14:07 < deer> not i... i suspect it's just the people with 386s *cough*lucky*cough* +14:07 < deer> Some very rare peaks here. Related to another erro, I might trace it back one day :p +14:07 < deer> not here +14:07 < luckypunk> I think, if its affecting all platforms and stuff, i would feel it hard, and no not really. Only when its serving the new config pages or downloading a lot of stuff does I2P pin my processor. +14:08 < jrandom> ok cool. there are a few scenarios where i2p will be a bitch wrt CPU, but hopefully those are few and far between +14:08 < jrandom> actually, that leads us in to 1.1) timestamper :) +14:09 < jrandom> (one of the problems can occur when the timestamper gets goofy / loses track of the correct time) +14:10 < jrandom> the whole timestamping stuff has been revamped and integrated into the router, thanks to Adam Buckley being kickass and releasing his work under the BSD license +14:10 < jrandom> (yay Adam) +14:11 < jrandom> we had previously used the SNTP code as a standalone client app, but we are not doing that anymore - instead we have a tight integration with the router +14:11 < jrandom> (so people may need to update their config files as mentioned in the email) +14:11 < jrandom> SNTP alone is only a part of the solution though +14:12 < jrandom> long term we need some better (read: NTP) synchronization, as SNTP is prone to flux +14:12 < jrandom> (especially in light of high network congestion) +14:12 < jrandom> Adam sent me some code he has for dealing with it, but i dont really have the time to work through that side of things atm +14:13 < deer> Using SNTP only ? +14:13 < jrandom> i dont recall - i think it may be ntp-esque via sntp queries +14:13 < deer> Ok, thanks +14:14 < luckypunk> uh +14:14 < luckypunk> i have a suggestion about that.. +14:14 < jrandom> anyway, if anyone ever feels bored and wants to do some crazy ntp hacking, that'd Rule +14:14 < luckypunk> Maybe it's wrong though. +14:14 < jrandom> mmhmm lucky? +14:14 < luckypunk> use ntpdate -q +14:14 < luckypunk> get the offset. +14:14 < jrandom> ntpdate -q == SNTP +14:14 < luckypunk> or something similar. +14:14 < deer> That is what the current code do, more or less ;) +14:14 * cervantes catches up what he's mised +14:14 < luckypunk> oh. +14:15 < luckypunk> sorry. +14:15 < cervantes> missed +14:15 < deer> But we need variable seconds length & co ;) +14:15 < cervantes> cpu usuage on my system is the lowest it's ever been.... +14:15 < jrandom> nice +14:15 < cervantes> but I've got 700 odd java threads now and rising +14:15 < jrandom> yeah oOo, and the skew detection / candidate selection +14:16 < luckypunk> yes, last time i ran it, about a month ago, it seriously affected my usability of my box, now i don't even notice if I2P is running. +14:16 < jrandom> yeah i've been looking into that cervantes +14:16 < deer> True, even if it's a weak part of the whole stuff ;) +14:16 < luckypunk> i have about 200 threads. +14:16 < luckypunk> 219, to be precise. +14:16 < jrandom> cervantes: i've tracked down the threads to the transport layer (we do some *uuugly* stuff to get timeouts), and we can do some better cleanup later +14:16 -!- TheCrypto__ is now known as thecrypto +14:18 < jrandom> basically some oddities are occurring with the increased # of peers on the network & the churn. all workable, but it can be annoying +14:18 < jrandom> anyway, thats it for 1.1, now 1.2) new router console authentication :) +14:19 < jrandom> (no one probably cares about this, but we have basic http authentication working. see the email for more info) +14:19 < cervantes> cool +14:19 < cervantes> despite that though the memory handling rocks... haven't had an oom in ages +14:19 < jrandom> ah wikked +14:20 < jrandom> actually, that gets us towards 2) 0.4 status +14:22 < luckypunk> Yes. If I2P were a MS product, we'd be ready for 1.0 :) +14:22 < jrandom> arggg, damn net connection dropped +14:22 < jrandom> (screen++) +14:23 < jrandom> ok, anyway, there has been a lot going on, and there are still a few more back end things left to do (some client tunnel pool management, as oOo is seeing, and some peer selection testing, as is in cvs) +14:24 < jrandom> there's also been a lot of progress on the installer / service / systray side of things +14:24 < jrandom> hypercubus: want to give us an update? +14:24 < deer> sure +14:25 < deer> the service wrapper installation is nearing completion, perhaps today or tomorrow... the service wrapper takes care of OOMs by automatically restarting the i2p router +14:25 < jrandom> (yay) +14:25 < deer> so it covers our butts there somewhat +14:26 < deer> systray integration is complete and works great... it's only for Win32 currently, since the systray4j lib seems to have some bugs in its KDE implementation +14:26 < deer> i'll be tracking the KDE progress and hopefully we'll have that in the near future +14:27 < deer> the installer is almost complete as well, all that remains to be added are post-installation tasks +14:27 < deer> i expect that will be done by the weekend +14:27 < deer> (as it depends on the complete integration of the service wrapper) +14:28 < jrandom> r0x0r +14:28 < deer> i'll be making available a pre-0.4 installer package for people to test +14:28 < deer> so i will let you all know when that's ready +14:28 < luckypunk> What about GNOME? +14:28 < cervantes> increment(hypercubus) +14:28 < deer> the systray4j project hasn't taken on gnome yet +14:29 < deer> we'll be adding additional desktop environments as becomes available with systray4j +14:29 < luckypunk> well, no biggie, i'mm gonna switch once/if KDE compiles. +14:30 < deer> the systray icon is only for launching the router console in your browser anyhow +14:30 < deer> so its main use will be by windows users ;-) +14:30 < jrandom> yeah, we expect *nix users to know how to bookmark ;) +14:30 < deer> but we will of course cater to the lazy *nix users when we can ;-) +14:30 < deer> N/C... +14:30 < luckypunk> Oh, I have a link in my firefox link hings like, with slashdot and BSD Google. +14:31 < deer> but the icon does also serve as a convenient status indicator +14:31 < jrandom> agreed +14:31 < deer> i.e. if the icon is gone, your router is gone too ;-) +14:31 < deer> unless of course you chose to hide the icon from your router console +14:32 < deer> which you can do, and it works great +14:32 < deer> ok, i think that's all, unless there are any questions +14:33 < protok0l> whats a good PDA that runs linux well? +14:33 < jrandom> word hyper +14:33 < jrandom> proto: #i2p-chat (or after the meeting) +14:33 < protok0l> oops +14:33 < deer> *snicker* +14:33 < jrandom> ok, movin' on to 2.2) jbigi & jcpuid +14:34 < jrandom> iakin has put together some kickass JNI/asm code to detect the exact CPU architecture used (on x86 boxen), and he has jbigi rigged up for freenet to auto-select the right .so/.dll based on that +14:35 < jrandom> he has also released that work into the public domain, and we've snagged a copy and integrated it back into i2p +14:35 < luckypunk> So we won't have to chose which jbigi to download? Won't that make the install somewhat larger? +14:35 < jrandom> correct +14:35 < jrandom> yeah, it adds a few hundred KB +14:36 < jrandom> but, well, the new install is, um, larger than the old one +14:36 < luckypunk> oh, i thought it would be more than a few hundred kb. +14:36 < luckypunk> Yea, between the new console...I'm guessing 6 - 10 mb? +14:36 < deer> * Myo9 has only got 99 mb left on this drive. +14:36 < deer> ;) +14:36 < jrandom> (especially since i'm being an ass and insisting on .war support rather than direct servlets, requiring xerces, which weighs in at 800KB) +14:36 < jrandom> the new install is looking ~4-6MB +14:37 < jrandom> but the good thing is, only ~1MB of that is i2p specific, so updates will be lightweight ;) +14:38 < deer> I2P hasn't got much publication has it? +14:38 < deer> Compared to freenet and TOR? +14:38 < jrandom> correct, we're staying fairly quiet +14:38 < protok0l> is download size a real consern? most people have broadband +14:38 < protok0l> i'm use it if it were 100megs +14:38 < luckypunk> protok0l, most people don't, actually. Most people that'd use I2P do. though i think I2P still supports dialup (sort of) +14:38 < deer> for i2p users it shouldn't +14:39 < jrandom> in my view, the development effort is best served with gradual adoption after sufficient testing goes on at different crititcal points +14:39 < luckypunk> yes. I2P isn't ready for 500 slashdot users :) +14:39 < jrandom> though our recent growth has been good, helping to poke different parts of the system +14:40 < jrandom> as we launch the 0.4 rev, we will want to move towards the 100-router mark +14:40 < deer> ok, i'll set up another 50 :) +14:40 < jrandom> plus, that'll give more incentive for client app devs to build client apps ;) +14:40 < jrandom> lol mule :) +14:41 < deer> Arr. +14:41 < cervantes> at the rate of adoption we could probably reach 100 in about a month +14:41 < cervantes> without evangelising +14:41 < jrandom> that would be a good rate of growth +14:42 < jrandom> but anyway, back to the agenda :) +14:42 < protok0l> i cant wait to evangelize +14:42 < jrandom> jbigi + jcpuid == integrated (and see the mailing list if you want to run CVS HEAD) :) +14:42 < jrandom> heh we can tell proto ;) +14:42 < deer> lucky: more than half of US internet users have broadband... report was released the other day +14:43 < jrandom> and less than 1/10th of the world is in the us ;) +14:43 < deer> Who mind about the USA ? ^^ +14:43 < jrandom> but moving on to 2.3) i2paddresshelper +14:44 < jrandom> oOo has put together yet another patch, this one letting people hit eepsites with linked pages without editing hosts.txt +14:45 < jrandom> the details are listed in the weekly status notes +14:45 < jrandom> oOo - is there anything you want to add? +14:45 < deer> Hum... Let's the eepsites number grow fast and Cervantes add his promised support :p +14:46 < jrandom> ah, cervantes has already added the "Try it [i2p]" link :) +14:46 < jrandom> (only people on CVS HEAD can use it, until 0.4 is out) +14:46 < cervantes> :o) +14:46 < jrandom> ((works great, btw)) +14:46 < deer> Great ^^ Will play with it as soon as I manage to get my router back online ;) +14:47 < kaji> you could password the client download and roll it gmail style +14:47 < jrandom> hmm? +14:48 < kaji> small base + invitation only +14:48 < kaji> but that would take work +14:48 < jrandom> oh, for 0.4 release? +14:48 < kaji> oh, for the 1.0 +14:48 < jrandom> no, not worth the effort atm. if we get flooded with new users we may want to look at using certificates, etc +14:48 < deer> 1.0 is for mass audience :p +14:49 < jrandom> well, for 1.0 we're going to be up past the 1000 user mark already +14:49 < jrandom> (at least, thats my hope ;) +14:49 * kaji thinks it would be fun to watch i2p go from 50 to 5000 node in 3 hours +14:49 < jrandom> heh +14:49 < deer> And then down to 100 ;) +14:49 < luckypunk> hypercubus, whoo hoo for americans! they're catching up ;) +14:49 < jrandom> heh, thats one way to test churn ;) +14:50 < cervantes> if aum gets stasher working...and hyper increases his goatse library then you'll see it jump 50 to 5000 is less than 3 hours ;-) +14:50 < kaji> and then 50100 as the nsa brings their node onlin +14:50 < jrandom> actually that kind of brings us forward to 3) AMOC vs. restricted routes +14:51 < jrandom> one of the interesting aspects of restricted routes is the ability to mount a 'sybil' attack really, really, really easily. +14:51 < jrandom> while mule was just mentioning a few minutes ago installing 50 new nodes, it'd be possible to bring online a significant number +14:52 < jrandom> one of the ways to address this is through a certificate authority, limiting the introduction of new routerIdentity certificates +14:52 < jrandom> another is through hashcash +14:52 < jrandom> another is through morphmix/tarzan style ip prefix detection +14:53 < jrandom> but, yet another is to say "fuck it" and hope we get sufficient 'good' peers to outnumber the 'bad' ones +14:53 < fvw> I think that's ok for the time being yes. +14:54 < protok0l> heres an idea +14:54 < jrandom> yeah, its the simplest thing to do, and adding artificial barriers to join a p2p network at this stage seems... foolish +14:54 < fvw> I think perhaps a mix of hashcash and ip-based would be nice to have for 1.0, but all in all you can't defend against a powerful enough adversary. +14:54 < protok0l> cut off the inital noderef access +14:54 < protok0l> if someone wants on, we can give them your noderefs +14:54 < protok0l> *uor +14:54 < fvw> and how would that help? +14:55 < jrandom> right fvw, and we might be able to put it off until after 1.0, as well +14:55 < fvw> depends on your definition of 1.0 :) +14:55 < jrandom> proto: i'm not sure that'd help much +14:55 < jrandom> heh fvw, we're not like freenet ;) +14:56 < jrandom> 1.0 == functional, secure, [sufficiently] anonymous, and scalable +14:56 < deer> and well documented ;) +14:56 < jrandom> documentation is a prerequisite to secure :) +14:56 < deer> Are all users added to the noderef at the moment? +14:57 < jrandom> Myo9: yes - http://dev.i2p.net/i2pdb/ is just a link into one of my router's netDb/ dir +14:57 < jrandom> (so it will list everyone my router has a reference for, at any time) +14:58 < jrandom> ((and everyone has a ref for people they talk to, which, at our current scale, is everyone)) +14:58 < jrandom> ok, but back to 3) AMOC vs. restricted routes +14:59 < deer> Ok. +14:59 < jrandom> as mentioned in the email, mule's ideas might be able to get us to drop the 0.4.2 AMOC transport and instead implement basic restricted route support, treating people behind NATs/firewalls as simply being behind a restricted route +15:00 < fvw> it would be kind of cool +15:00 < jrandom> yeah, and save us from writing yet another transport protocol +15:01 < deer> But how would make performing sybil attack that much easier? +15:01 < jrandom> s/writing/designing,implementing,reviewing,debugging,deploying,debugging,debugging,debugging,debugging.../ +15:01 < deer> how would it make* +15:02 < jrandom> ugha2p: there is no way to tell how many *real* routers are behind a restricted route - all we know about them is that they have a unique router identity and are reachable through a certain router +15:02 < deer> Ah. +15:03 < jrandom> that certain router could in fact be one sim instance, running 100 other routers in the same JVM, each pretending to be behind firwalls +15:03 < deer> Right. +15:03 < deer> They could as easily been using 100 ports on the same host... +15:03 < fvw> however assuming you're willing to spend a few 100 euros on your attack, you can get a large number of spread out IPs anyway. +15:03 < jrandom> agreed fvw +15:04 < jrandom> oOo: true, though ports cost memory (and some CPU) +15:04 < deer> I don't think that presumption is going to stop more powerful enemies though. +15:04 < jrandom> (which is why when i do larger sims, i need to switch from the TCP comm system to the VM comm system) +15:04 < jrandom> agreed ugha2p +15:04 < jrandom> it just makes it easier +15:05 < fvw> I think we're going to have to assume that anybody with more than a bored-sunday-afternoon desire to attack the system is going to be able to get at least 10^3 nodes on the network easy. +15:05 < deer> Not *that* much +15:05 < jrandom> right fvw +15:05 < deer> (+ easier) +15:05 < fvw> and at that order of magnitude, nothing apart from central certification is going to stop them. +15:06 < deer> 100 open ports on one single host would be trivial to detect, but 100 restricted routes behind a machine might not be. +15:06 < jrandom> well, thats open to debate fvw, but yeah, sybil is a bitch +15:06 < deer> 100 zombies are tricky to detect ;) +15:06 < fvw> which means we ideally need a 10^4 network. +15:06 < jrandom> definitely oOo +15:06 < fvw> (loose estimates) +15:07 < deer> We'll ideally have a 10^4+ network. +15:07 < jrandom> fvw: i'd go higher than that - imho we need to grow this into the millions +15:07 < deer> Ideally would be more then half available IPs ;) +15:07 < jrandom> heh oOo +15:07 < fvw> It'd be nice if we could yeah. +15:08 < jrandom> (but, of course, to grow it into hte millions we need sufficient reason to do so. i think we will be able to make the case for that eventually though) +15:08 < deer> I'm not sure if Kademlia could be held in one piece for that long. ;) +15:08 < fvw> at which point beating people up would definately become the low-cost attack. Which, unintuitively enough, would be a good thing. +15:08 < jrandom> heh +15:08 < deer> jrandom: millions would need serious useability and benefit +15:09 < jrandom> agreed DrWoo +15:09 < fvw> luckily, a lot of (non-nice) people are working very hard on that now. +15:09 < deer> Pr0n for masses :p +15:10 < deer> which is why imho we need a kickass filesharing app +15:10 < deer> "One human, One goatse", which lead us to stasher :p +15:10 < cervantes> download->install->share musi +15:10 < deer> jrandom: it would have to be order of an anonymous kazza, luckily the motivation is being taken care of by the RIAA & co. +15:10 < fvw> pr0n is already easy to get (see usenet and such). I think big record company assocs and such are going to crack down a lot harder on p2p than pornographers ever could. +15:10 < cervantes> music +15:10 < fvw> but once again we drift offtopic. +15:11 < fvw> "4) stasher"? +15:11 < deer> Yeah ! 4) ! +15:11 < jrandom> agreed - we can all think up some reasons to justify use, but first we need to get it *working* :) +15:11 < cervantes> ah for once a non-tenuous link into the next item +15:11 < jrandom> movin' to 4) stasher +15:12 < jrandom> aum: you awake yet? +15:12 * hypercubus chants auuuuuummmmmmmmm +15:12 < jrandom> well, in case he isn't, i know he's been doing a lot of work on adding CHK and SVK support to stasher +15:13 < jrandom> which is Cool +15:13 < deer> And splitfiles +15:13 < jrandom> yeah, the splitfile support is interesting +15:13 < fvw> in the 'interesting times' sense? +15:14 < jrandom> thats one of the differences between freenet and stasher, in that stasher already has a fixed 31KB max size per key +15:14 < deer> "Useful, great, don't need anything from user application" +15:14 < jrandom> (since afaik stasher uses SAM datagrams) +15:14 < luckypunk> can't you impliment lik..split files? +15:15 < jrandom> ooohhh! i just realized what bug he was running into wrt reliability! +15:15 < jrandom> (fixed the other day in cvs, significantly killing the bug) +15:15 < jrandom> yeah lucky +15:15 < jrandom> but the splitfile implementation is inherently different from how freenet splitfiles work, due to max keysize limitations +15:15 < deer> So Stasher over-I2P just be healthy again ? ^^ +15:16 < jrandom> (if you read freenet devl or tech lately, you'll hear toad and hobx talking it over) +15:16 < deer> *should +15:16 < jrandom> oOo: with HEAD, yeah +15:16 * jrandom hasnt heard any reports of people even trying it since 0.3.4.3 came out (or was it 0.3.4.2) +15:16 < jrandom> but anyway, he is planning on another new test build by end of the week +15:17 < jrandom> anyone have anything to mention / discuss wrt stasher? +15:17 < jrandom> (other than yay! go aum!) +15:18 < deer> Yeah, there is an urge to find non-goatse contents there ;) +15:18 < jrandom> heh +15:18 < deer> ex-Freeneter, start your engines ;) +15:18 < jrandom> yeah splitfile support should definitely help with that, as would ssk & fcp support +15:19 < fvw> I'd like to second the 'go aum!' if I may. +15:19 < deer> yay ! +15:19 < jrandom> motion is seconded, and thirded :) +15:19 < jrandom> ok, swingin' forward to 5) pages of note +15:20 < jrandom> i just wanted to point out three new pages +15:20 < jrandom> DrWoo's safe browsing guide gives a pretty good rundown on the dangers of eepsites & the outproxies +15:20 < jrandom> the problems can be addressed in code, but we just havent had time to do it yet, so its Good to be informed +15:21 < jrandom> lucky has also put together a good doc on the freebsd+java side of things as well +15:21 * jrandom hasnt tried too many jvms on fbsd, just kaffe, so nag him if you have questions :) +15:22 < jrandom> hyper has also put together the doc for upgrading to the 0.4 dev code, which he'll likely be updating once we want more people to test it ;) +15:22 < hypercubus> my post on the forum covers installation of the service wrapper... the howto for the new router console is here --> http://files.hypercubus.i2p/New_I2P_Router_Console_Howto.txt +15:23 < jrandom> wr0d +15:23 < jrandom> oh, there's also a new pretty picture & some new text @ http://www.i2p.net/how_intro (hopefully making things a bit more clear) +15:24 < fvw> ooh, that looks pretty. Who did that? Good work. +15:25 < hypercubus> it was actually copied directly from a crop circle +15:25 * fvw tries not to mention the resemblence between jrandom and Dave but fails miserably. +15:25 < jrandom> heh +15:25 < fvw> ah, that explains jrandom's feelers. +15:25 < jrandom> the pic was beautified by our anonymous designer +15:25 < jrandom> (thankfully so, my ms paint skills suck :) +15:26 < hypercubus> we're still trying to decipher the significane of Charlie's long chin +15:26 < deer> Arr, this sucks. +15:26 < jrandom> how about alice's skewed eyes? ;) +15:26 < hypercubus> heh +15:26 < deer> yeah, it'll be nice when we get irc.duck.i2p upgraded (if it hasnt been already..) +15:27 < fvw> never mind that, she looks like she's doing a double alien-bursting-from-stomach-scene with her cheeks. +15:27 < jrandom> lol +15:27 < jrandom> *thats* why she is talking to dave +15:27 < jrandom> well, anyway, i think this leads us to 6) ??? +15:27 < fvw> haha +15:27 < jrandom> anyone have anything they want to bring up? +15:28 < deer> Can't you build the skeleton of certificates' stuff in I2P and let *others* fill it and have fun ? (Or his this already done ? :p) +15:28 < deer> Or is this absolutely useless ? +15:28 < deer> (for now) +15:28 < jrandom> hmm? +15:28 < jrandom> the hashcash / etc certificate stuff? +15:28 < deer> Ok, nevermind ^^ +15:28 < deer> Yes +15:29 < jrandom> ok yes, we already have the infrastructure for that +15:29 < jrandom> (though things like libSAM will need to be modified to interpret the destination properly, since iirc nightblade assumed 384bytes always ;) +15:30 < jrandom> but the router will handle different types of certificates transparently +15:30 < deer> The code is ready for this ? Just missing some 'content' ? +15:31 < jrandom> yes - the RouterIdentity created currently always attaches a NullCertificate (certificate type == 0) +15:31 < jrandom> if it attaches another type, another type of certificate is attached +15:31 < jrandom> e.g. hashcash cert, CA signed cert, etc +15:31 < jrandom> verification infrastructure is there as well (RouterInfo.verify) +15:32 < deer> Oh, great :) +15:32 < deer> So someone may play with this code and adding hashcash and stuff in advance ? +15:32 < jrandom> if we had a flash flood i could probably lock down the net in a day or two +15:32 < jrandom> right +15:33 < jrandom> (though i think fvw is right in that it wont be pressing for at least a little while) +15:33 < deer> Ok. I don't volunteer ;) But someone might :p +15:33 < Nightblade> on i2p.net, the aug 24 meeting log link is pointed at the aug 17 log +15:33 < jrandom> right, sorry, meeting isn't over yet :) +15:33 < Nightblade> oh haha +15:34 < jrandom> so, anyone have anything else they want to bring up? :) +15:34 < hypercubus> new rule... whoever edits the website: no smokin' the funny stuff while editing! +15:34 < jrandom> uh oh... +15:34 < jrandom> what'd i do? +15:34 < hypercubus> i was referring to broken links ;-) +15:34 < jrandom> oh +15:35 < hypercubus> we need a full time web editor... i nominate lucky +15:35 < jrandom> well, yeah, i updated the link to this weeks weekly status notes before the meeting, in case anyone went to the page ;) +15:35 < jrandom> we certainly do need someone to keep track of the web site and poke people when things are funky +15:36 < luckypunk> me? web enditor? +15:36 < luckypunk> enditor haha +15:36 < luckypunk> i dunno +15:36 < Nightblade> spelchek reqwired +15:36 < luckypunk> i'll probably be pretyt busy once school start.s +15:36 < jrandom> bah, drop out! work on i2p fulltime! +15:36 < luckypunk> if i drop out +15:37 < luckypunk> my parents will make me get a job +15:37 < deer> excuses excuses ;-) +15:37 < luckypunk> and i'm still busy +15:37 < deer> amen +15:37 < deer> * oOo will happily renovate the English used on the website ;) +15:37 < luckypunk> anyway, i don't think i'm gonna be allowed to drop out +15:38 < luckypunk> they're raising the legal dropout age to 18 +15:38 < luckypunk> or high school diploma +15:38 < luckypunk> whatever comes first. (usually the latter) +15:38 < hypercubus> er +15:38 < Nightblade> haha "legal dropout age" - what will they come up with next? +15:38 < luckypunk> it's 16 now. +15:38 < luckypunk> You can't leave school before that, else they'll arrest you. +15:38 < jrandom> actually, thats a good point.. as we move towards 1.0 it'd be good to offer different translations of various pages +15:39 * luckypunk can make a vague translation intro french, if absolutely required. +15:39 < Nightblade> I'll do the Klingon and Ebonics translations +15:39 < deer> Yeah, Klingon translation of the website :p +15:39 < hypercubus> yes, we can offer English, B0rk, and oOo-fried English +15:39 < deer> Damned, same idea >< +15:39 < Nightblade> ooo, a mindreader +15:39 < luckypunk> (with the theory that babelfish aided with a human is better than no translation at all.) +15:39 < jrandom> i think we might be able to scam jar into updating his French translation lucky, but thanks ;) +15:39 < deer> hyper: will gladly for free like in beer :p +15:40 < jrandom> thats actually one of the big things post 0.4 - getting the docs solid +15:40 < luckypunk> hey, my french is completely intelligible to a french speaker +15:40 < luckypunk> Though i probabxly sound equivilent to godmode0 +15:40 < hypercubus> the installer already has native language packs btw +15:40 < jrandom> (perhaps a whitepaper or two on various aspects) +15:40 < jrandom> w3rd hyper +15:40 < deer> * oOo suspect we can master quite some language with the people online here ;) +15:40 < jrandom> (yeah, it'll be tough to translate the paragraph license ;) +15:40 < hypercubus> i could just make it throw up the panel to choose a language +15:40 < jrandom> agreed oOo +15:40 < hypercubus> heheh... libre: +15:40 < jrandom> gratis: +15:41 < luckypunk> gratis and libre +15:41 < luckypunk> damn french and their ability to have two words. +15:41 < jrandom> ok, anything else? +15:41 < hypercubus> we have 10 words for everything +15:41 < luckypunk> though libre also means free beer in quebec french. =( +15:41 < luckypunk> so much for that theory. +15:42 < jrandom> ok... if there's nothing else... +15:42 * jrandom winds up +15:42 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/104.rst b/i2p2www/meetings/logs/104.rst new file mode 100644 index 00000000..e6059205 --- /dev/null +++ b/i2p2www/meetings/logs/104.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 24, 2004 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/105.log b/i2p2www/meetings/logs/105.log new file mode 100644 index 00000000..8bca0dc2 --- /dev/null +++ b/i2p2www/meetings/logs/105.log @@ -0,0 +1,219 @@ +14:04 < jrandom> 0) hi +14:04 < jrandom> 1) 0.3.4.3 +14:04 < jrandom> 2) 0.3.5 and 0.4 +14:04 < jrandom> 3) docs +14:04 < jrandom> 4) stasher update +14:04 < jrandom> 5) ??? +14:04 < jrandom> 0) hi +14:04 * jrandom waves +14:05 < deer> * Pseudonym waves +14:05 * hypercubus flaps +14:05 < deer> * detonate waves +14:05 < jrandom> weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-August/000425.html +14:05 < jrandom> moving on to 1) 0.3.4.3 +14:06 < jrandom> as it says in the notes, and as you all know from firsthand experience, the net isn't too healthy atm +14:06 < jrandom> lots of messages are lost, and people are often seeing warnings about their leases having expired a while back +14:07 < jrandom> this is unfortunate, and largely addressed in CVS, which will be rolled out when we can (see item 2) +14:07 < kaji> (late) hi +14:08 < jrandom> anyway, i think thats all i've got to mention on 0.3.4.3, beyond whats in the email. i appreciate your patience as we move forward through the rough patches +14:08 < jrandom> swinging on up to 2) 0.3.5 and 0.4 (unless someone has anything else they'd like to add..?) +14:09 < deer> So 90% of broken nodes can knock down the network ^^ +14:09 < deer> * Pseudonym eagerly awaits the release of 0.3.5 +14:09 < kaji> who was running the dos? they did a good job +14:10 < jrandom> well, I can reach squid consistently from my other CVS HEAD boxes +14:10 < jrandom> so the network isn't 'knocked out' for people on cvs head :) +14:10 * lucky is having partial success with .3.4.3 still. +14:10 < jrandom> but yeah, the old peer selection algorithm did some Stupid Things +14:10 < deer> I'm on CVS head and lost suid.i2p a lot of time ;) +14:11 < jrandom> hmm +14:11 < jrandom> what are you seeing for a tunnel failure rate? +14:12 < jrandom> (total # events at /routerStats.html#tunnel.failAfterTime compared with total # events at #tunnel.buildFrequency ) +14:13 < deer> lifetime average value: 288 268,91 over 339,00 events +14:13 < jrandom> and tunnel.buildFrequency? +14:14 < deer> But you might have been restarting your router too much while repairing thread leaks ;) +14:14 < jrandom> what is your lifetime # of tunnel.buildFrequency? +14:14 < deer> 24h frequency: avg per period: (2,76, max 2,76, current is 100,00% of max) strict average per period: 5 645,58 events (averaged using the lifetime of 5 729,00 events) +14:14 < deer> 24h ~= router lifetime +14:15 < jrandom> so ~5% tunnel failure +14:15 < jrandom> thats about what i've been seeing on CVS HEAD, as opposed to the 40-60% tunnel failure of 0.3.4.3 +14:16 < deer> Let's swing on up to 2) then ;) +14:16 < jrandom> consider it swung +14:16 < jrandom> ok, as mentioned in the email, the next rev will be 0.3.5, not 0.4 +14:16 < jrandom> it'll have all the goodies y'all have been waiting for, but it won't have the "0.4 stamp of approval" ;) +14:17 < deer> 0.4.rc-1 +14:17 < jrandom> well, i considered going down the rc road, but I dont want to be overconfident +14:17 < kaji> 0.4.rc-0.9 +14:17 < deer> heh +14:18 < kaji> beta +14:18 < jrandom> while 0.3.5 is out, I'm going to see if we can mount the DoS again, as well as a variety of new issues that we should be able to come up with +14:18 < lucky> we have to keep DoSing it till it works while being DoSed +14:18 < jrandom> right +14:19 < kaji> dos it till it cant be dosed no more +14:19 < deer> but no new features between 0.3.5 and 0.4 right? +14:19 < jrandom> perhaps someone can be inspired to help out with implementing some churn and fail cases in the simulator, so we can test this stuff more easily and automatically... ;) +14:20 < jrandom> correct Pseudonym, I do not expect any significant new features to come during 0.3.5 +14:20 < jrandom> at least, from an app user perspective +14:20 < jrandom> perhaps some developer will take this time to improve upon the eepproxy, a transparent webserver, help out aum, etc +14:21 * jrandom pokes at someone hacking on an irc proxy w/ DCC support ;) +14:21 < deer> a public inproxy for i2p/tor is in the make +14:21 < jrandom> ah nice, html specific, or bitpipe? +14:21 < jrandom> er, web specific, that is +14:22 < deer> web specific +14:22 < jrandom> w3rd +14:22 < deer> the idea being that an ISP can put up some gateways to specific sites +14:22 < deer> so the world can access alexandria +14:23 < jrandom> ooh, what would *really* rule is if those gateways could act as vhosts +14:23 < jrandom> (maybe thats what you're talking about anyway) +14:23 < deer> http://anonygateway.com/home.duck.i2p/~alexandria/ +14:23 < jrandom> ah ok +14:23 < jrandom> still cool +14:23 < deer> http://anonygateway.com/6sxoyfb3h2nvok2d.onion/ +14:24 < deer> virtual host is also possible; just for a next iteration +14:24 < jrandom> (though 6sxoyfb3h2nvok2d.onion.anonygateway.com would be cooler ;) +14:24 < jrandom> right right +14:24 < deer> easy to do with a mod_rewrite ofcourse +14:25 < cervantes> or just set up a subdomain :) +14:25 < kaji> hah vhost a bittorent seed +14:25 < deer> I am paying dev out of my pocket; patch will be pub domain +14:25 < jrandom> duck++ +14:26 < deer> also talking with an ISP who might want to offer it as a paid service +14:26 < jrandom> nice +14:26 < deer> ofcourse it is better when anarchistgang.org does so +14:26 < deer> but you know the stability of those types +14:26 < jrandom> *cough* +14:27 < cervantes> their quackers +14:27 < cervantes> *they're +14:27 < deer> hi!!!!!! +14:27 * hypercubus snickers +14:27 < jrandom> hi jon2 +14:27 < deer> I like meeting >:-D +14:28 < jrandom> i think after the net is settled down a bit more (once 0.3.5 is out there), we'll want to reevaluate some app level activities +14:28 < deer> *cough* myi2p? +14:28 < jrandom> heh +14:29 < kaji> what about access behind a firewall? +14:29 < deer> yes, firewall access :) +14:29 < jrandom> we need something rock solid, usable, *and* secure, that provides functionality that people want (and hopefully, that we can use to encourage community) +14:30 < deer> * duck points at 0.4.2 @ http://www.i2p.net/roadmap +14:30 < jrandom> believe me, i want access behind firewalls / uncontrollable NATs / etc just as much as the rest of you. +14:30 < deer> I can do the secure part, I know cryptophagy. +14:30 < jrandom> (someone has to add that as a quote ;) +14:30 * hypercubus wonders what a cryptophage is +14:31 < jrandom> jon2 - we definitely need help on this stuff and would love to snag some of your time! +14:31 * kaji just started back to school, he would like to take i2p with him ;) +14:31 < aum> morning all +14:31 < cervantes> btw I'm wondering if any devs miss their little i2p blogs.... if perhaps they should get devoted forum sections, at least in the short term... +14:31 < cervantes> *if so +14:31 < deer> cryptophagy, science of security. +14:31 < jrandom> 'mornin aum +14:32 < hypercubus> jon2: do you also know cryptography? +14:32 < deer> Good morning aum. +14:32 < jrandom> cervantes: i'm holding off until i can get a blog of my own, which hopefully wont be too far off +14:32 < deer> no :-( +14:33 < cervantes> jrandom: and everyone else? +14:33 < jrandom> nightblade has been using his blog @ cashdollar.org +14:33 < deer> I have a blog on blogs.aspnet.com +14:33 < jrandom> though i suppose it'd be cool to have people posting on the forum +14:34 < cervantes> ah good...well it seems most have found alternatives....but it's a same they've become fragmented +14:34 < jrandom> yeah +14:34 < cervantes> *shame +14:34 < cervantes> darn fingerzzz +14:34 < lucky> well, a phage is part oft he immune system. +14:34 < jrandom> i liked having the devblogs on the site. we'll get something back eventually +14:34 < hypercubus> jon2: funny, blogs.aspnet.com is an unclaimed domain +14:34 < jrandom> ok, anyway, anything else for 2) 0.3.5 and 0.4 ? +14:35 < hypercubus> yeah +14:35 < hypercubus> i've got the firefox problem solved now, in cvs +14:35 < jrandom> w000t +14:36 < deer> I am asp developer. +14:36 < hypercubus> reads the default from the registry +14:36 < cervantes> :) +14:36 < deer> sorry.. I mean blogs.asp.net +14:36 < hypercubus> no you don't +14:36 < deer> weblogs.asp.net +14:36 < jrandom> ah, great hypercubus. so we're almost there for the 0.3.5 release +14:37 < cervantes> shudder....asp +14:37 < hypercubus> yes i can feel it getting close +14:37 < jrandom> ok, moving on to 3) docs +14:37 < jrandom> well, I dont have anything to add beyond my request in the email +14:38 < jrandom> (send in your questions! post 'em to the list, send 'em in email, post 'em on the forum) +14:38 < deer> Yeah, anonymously use the forum and make Cervantes happy ;) +14:39 * cervantes gets all tingly +14:39 * hypercubus adjusts the rabbit ears +14:40 < nicktastic> haha +14:40 < deer> I liked this meeting.. +14:40 < cervantes> you said that... +14:40 < cervantes> I like meeting >:-D +14:40 < hypercubus> great, you get to buy the donuts next time ;-) +14:40 < jrandom> ok, if there's nothing else, 4) stasher update +14:41 < jrandom> aum seems to have awoken early... you still 'round? +14:41 < deer> GREAT MEETING! +14:41 * hypercubus wonders if dm has children +14:41 < jrandom> heh, yeah, he's back ;) +14:41 < cervantes> I'd think it's an impossibility +14:42 < hypercubus> guess aum missed that first cuppa +14:42 < jrandom> ok, maybe he'll swing back to the term +14:42 < jrandom> anyway, his general update was posted in the email +14:42 < jrandom> looks like there's lots of progress going on +14:43 < jrandom> some questions remain, but ever onward +14:43 < deer> But no release date given ;) +14:43 < hypercubus> how many people are testing it atm? +14:43 < jrandom> i dont know if the code he has now w/ the things mentioned is public yet +14:43 < hypercubus> ah +14:44 < deer> BAF BAF BAF BAF BAF +14:44 < kaji> whats new about stasher? +14:44 < jrandom> kaji: see the http://dev.i2p.net/pipermail/i2p/2004-August/000425.html +14:45 < deer> It now use less water to wash the dishes +14:45 < hypercubus> i've been waiting for that feature +14:45 * jrandom too +14:45 < jrandom> ok +14:45 < jrandom> if aum is still afk, swinging on to 5) ??? +14:45 < jrandom> does anyone else have something they want to bring up? +14:45 * cervantes puts on a tin hat +14:46 < lucky> How's jetta for serving web pages coming along? +14:46 < jrandom> i dont know of anyone working on an app to safely allow people to host pages with jetty +14:46 < jrandom> (host pages that can be served as an eepsite, that is) +14:47 < jrandom> jetty does allow people to deploy client applications (though i dont know anyone working on a web based app yet either) +14:47 < hypercubus> i'd like to say something about systray4j vs. SWT +14:47 < jrandom> mmhmm? +14:47 < hypercubus> the cost of ditching systray4j for SWT: we'd be dropping systray4j.jar and systray4j.dll, shedding 147 KB from our distribution size -- and replacing that with swt.jar (885 KB) + native libs (332 KB on Win, 639 KB on *nix), a net difference of 1.2-1.5 MB, but with that we gain systray icons on KDE, Gnome, and OS X as well as Win32, and also launch icons for plain X environments a la NextStep/GNUstep +14:48 < hypercubus> and this will give us the ability to add other GUI components later, independent of the JRE the user has (otherwise, accomodating Kaffe users would limit us to using AWT only) +14:48 < hypercubus> just food for thought... maybe down the road +14:48 < jrandom> worth discussing, down the road, as users demand it +14:49 < jrandom> if the value is there, the value is there +14:49 < deer> Web interface is intend to be the GUI, isn't it ? +14:49 < hypercubus> cervantes had a cool idea to make further use of SWT +14:49 < hypercubus> an I2P dashboard ;-) +14:49 < jrandom> yes oOo +14:49 < hypercubus> oh, and skins! j/k +14:49 < jrandom> i'd really much rather have that sort of functionality built into the router console, if you mean what i think you mean +14:50 < hypercubus> point is... +14:50 < cervantes> it might also encourage application development if i2p comes with a nice set of SWT libraries +14:50 < hypercubus> it seems development on systray4j is winding down or otherwise mired +14:50 < deer> As long as systray and GUI stuff aren't mandatory to have a fully working router... +14:50 < jrandom> right oOo +14:50 < hypercubus> i don't see them fixing the KDE version anytime soon +14:51 < hypercubus> correct, we could just add a hook in the router's systray class +14:51 < hypercubus> and the user could optionally download the systray/SWT stuff +14:51 < jrandom> hypercubus: personally, i'm not entirely 100% sure the user base will even need a systray. i think we need to deploy it and get feedback to know the value +14:51 < jrandom> cervantes: client application developers can absolutely bundle SWT with their app +14:51 < jrandom> (or say "get SWT") +14:51 < hypercubus> i suspect we'll get requests for expanded systray options +14:52 < jrandom> and if a client app dev gets something we want to bundle with the router, we'll deploy swt with the bundle +14:52 < jrandom> (etc) +14:52 < deer> Too late to split the console/status monitor/whatever from the really-routing-stuff ? +14:52 < jrandom> really routing stuff? +14:52 < jrandom> the router console is a fully seperate client application +14:53 < jrandom> (apps/routnerconsole/) +14:53 < deer> The stuff needed to have the bytes anonymously flowing +14:53 < jrandom> i do think down the line we will want to have a minimal-router install as well +14:53 < jrandom> (with nothing in clients.config, etc) +14:53 < jrandom> but we dont have the developer hours to maintain multiple sets of things +14:55 < jrandom> ok, anyone else have anything they want to bring up? +14:57 < jrandom> if not +14:57 * jrandom winds up +14:57 < deer> 0.3.5, when ? ;) +14:57 < jrandom> it'll be out hopefully this week +14:57 < jrandom> (in the next day or two if all goes well) +14:57 < deer> Ok ^^ +14:57 * jrandom stops winding up +14:57 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/105.rst b/i2p2www/meetings/logs/105.rst new file mode 100644 index 00000000..7e3e8fd0 --- /dev/null +++ b/i2p2www/meetings/logs/105.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 31, 2004 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/106.log b/i2p2www/meetings/logs/106.log new file mode 100644 index 00000000..be47c299 --- /dev/null +++ b/i2p2www/meetings/logs/106.log @@ -0,0 +1,470 @@ +14:09 < jrandom> 0) hi +14:09 < jrandom> 1) 0.4 +14:09 < jrandom> 2) Capacity and overload +14:09 * cervantes pulls up a bar stool +14:09 < jrandom> 3) Website updates +14:09 < jrandom> 4) I2PTunnel web interface +14:09 < jrandom> 5) Roadmap and todo +14:09 < jrandom> 6) ??? +14:09 < jrandom> 0) hi +14:09 < nicktastic> ugha, Ah, -x isn't even necessary to see what's being resolved - silly me +14:09 < cervantes> hullo +14:09 * nicktastic resumes lurking +14:10 < jrandom> 'lo all, sorry for the delay in the notes - http://dev.i2p.net/pipermail/i2p/2004-September/000437.html +14:10 * jrandom just had to reply to Derick's E post :) +14:10 < deer> nicktastic: Right. The meeting already started though. :) +14:10 < luckypunk> h wow, i didn't miss it. +14:10 < jrandom> !hi5 +14:10 < jrandom> ok, swinging on in to 1) 0.4 +14:11 < jrandom> we finally got it out the door, and it doesn't seem to have bitten us too bad +14:12 < jrandom> the network is larger than its ever been (I counted 60 TCP connections a few hours back), eepsites are retrievable, and irc is often usable +14:12 < dm> hey!! meeting? +14:12 < jrandom> hypercubus has done some great work with the new install, systray, and service manager, which I know has helped us out a bunch +14:13 < modulus> yay +14:13 < hypercubus> still a ways to go though +14:13 < hypercubus> but i think we're getting somewhere now +14:13 < jrandom> agreed, ever onwards :) +14:14 < jrandom> this release also has the widespread deployment of oOo's ?i2paddresshelper +14:14 < jrandom> we covered that a bit the other week [http://dev.i2p.net/pipermail/i2p/2004-August/000419.html item 2.3], but now its probably a good idea for people to consider using it for their links +14:15 < hypercubus> does it work with name-based vhosts? +14:15 < jrandom> the i2ptunnel httpclient still correctly sends Host: $base64dest +14:17 < jrandom> on that note, there has been some more talk about using the bundled webserver to serve some eepsites, and i think if someone has some time to figure out the configuration necessary, that'd be pretty kickass (saving us from the vhost / apache config problems) +14:18 < jrandom> ok, anyone else have anything to bring up about 0.4? +14:18 < deer> is this web server in cvs? +14:18 < demonic_1> ? +14:18 < hypercubus> the web server is in 0.4 +14:18 < demonic_1> what i miss +14:18 < deer> baffled: It's going to be. +14:18 < hypercubus> hence CVS +14:18 < jrandom> baffled: yeah, its all in cvs (lib/org.mortbay.*) +14:18 < cervantes> btw I experimented with window's url protocol handers... it's very easy to set the registry up so "i2p://base64" will launch in a browser with a http://site.i2p?i2paddresshelper=base64 ... +14:19 < deer> Oh, it already is. +14:19 < dm> this is all very very cool +14:19 < hypercubus> i already wrote registry interfacing code +14:19 < hypercubus> we can use that to set up an .i2p association +14:19 < fvw> cervantes: i2p:// wouldn't be quite right I think. After all, it's http over i2p; just as you could have irc:// over i2p. +14:19 < cervantes> you can also specify security and proxy settings on a per protocol basis +14:19 < jrandom> cervantes: does firefox/etc honor those? +14:19 < cervantes> yup +14:20 -!- shardy_ is now known as shardy +14:20 < jrandom> woah, hi shardy_ +14:20 < shardy> hey jrandom, long time no talk +14:20 < cervantes> although admittedly I need more testing... +14:20 < nicktastic> konqueror should, too +14:20 < cervantes> I was just playing in a spare moment ;-) +14:20 < deer> Opera doesn't. +14:20 < cervantes> although I doubt firefox takes any notice of windows proxy and security settings +14:20 < hypercubus> you can set it in opera's ini file +14:21 < hypercubus> i did that to opera so ed2k:// would work +14:21 < deer> hypercubus: Ah, cool. +14:21 < fvw> only up to a point. You can't turn URL handlers into http:// handlers handled by opera itsself alas. +14:21 < hypercubus> though they don't document it very well +14:21 < deer> really, what benefit does i2p:// give? +14:22 < fvw> hypercube: You're handing it off to a helper app I suppose? I did much the same, but I couldn't find a way to make opera display a "download started" page. +14:22 < hypercubus> yes, it gets handed to eMule +14:22 < dm> yes, who wants to pee in public anyway? +14:22 < hypercubus> we could hand i2p:// to the eeproxy +14:22 < hypercubus> then you web guys can figure out the rest from there ;-) +14:22 < Sciatica> is https not http over, uh, "s"? +14:23 < jrandom> but, as i think duck is getting at, we'll already be tied in to the eepproxy anyway? +14:23 < deer> Sciatica: It's HTTP over SSL, yes. :) +14:23 < jrandom> Sciatica: http over i2p (well, anything over i2p) is secure and authenticated. what happens after it reaches the other side is outside i2p's scope +14:23 < deer> But that's an established convention. +14:24 < Sciatica> yes, I knew that. I'm just saying that the argument against i2p:// isn't as clear as "isn't it juts http _over_ i2p?" +14:24 < dm> htt2p +14:24 < hypercubus> i don't know if i2p:// is necessary, but i do believe it's possbile to get the major browsers at least to work with it +14:24 < deer> jrandom: I think he just referred to the 'https://' prefix. +14:24 < jrandom> ah, sorry. +14:24 < deer> we need an anonymizing filter plus http://127.0.0.1:7657/www.duck.i2p/ anyway +14:25 < deer> with those you dont need to tweak browser settings +14:25 < jrandom> but yeah, I agree with fvw, this sounds like excessive overloading of the url protocol +14:25 < demonic_1> not here >> as a lame use i feel i2p:// links would rule << not here +14:25 < jrandom> right duck +14:25 < jrandom> hehe +14:25 < cervantes> perhaps i2p:// could me made to operate as a protocol arbiter: i2p://irc/base64 +14:26 < fvw> ungh, that's ugly and abusing URLs in the worst possible way. +14:26 < deer> cervantes: How would that work in IRC's case? +14:26 < deer> URIs :) +14:26 < cervantes> that way you can launch different apps based on a single url standard +14:26 < fvw> (not that there's anything wrong with that) +14:26 < jrandom> wouldn't the more appropriate URL mod be irc://i2p/base64/#i2p ? +14:27 < jrandom> but, ok, we're a bit off track.. +14:27 < jrandom> anything else on 0.4? :) +14:28 < fvw> I don't think that URI's allow for specifying transport mechanism seperately from protocol, which is a shame really. +14:28 < dm> you can use the filesystem +14:28 < fvw> Yes, sort of: *applause* +14:28 < dm> c:\i2p\irc #i2p +14:29 < dm> ha! I confused you all +14:29 < deer> * mule_iip agrees with fvw +14:29 < fvw> dm: I'm going to seriously hurt you. Maybe not today, maybe not tomorrow, but soon and for the rest of your life. +14:29 < jrandom> :) thanks, we do our best +14:29 < fvw> +14:29 < jrandom> heh +14:29 < jrandom> ok, jumping on to 2) Capacity and overload +14:30 < deer> Hi everyone +14:30 < jrandom> i'd rather not just copy out what was posted in the notes, so review whats there :) +14:30 < dm> hi +14:30 < hypercubus> welcome to our meeting DrVince ;-) +14:30 < deer> Hi, DrVince. +14:31 < jrandom> one thing I'd like to mention wrt 2) was something a few people have seen - severe skew in participating tunnels +14:31 < jrandom> e.g. someone with DSL had 300+ tunnels the other day +14:31 < dm> me +14:31 < modulus> yeah +14:31 < jrandom> (and when they go down, that breaks a *lot* of tunnels) +14:31 < jrandom> the problem is tunnels are really lightweight - 2-20bps on average +14:31 < cervantes> and my OC3 has practically nada +14:31 < hypercubus> i only have 8 atm +14:32 < dm> i had 270+, and I am on 150kbps +14:32 < jrandom> overall, the network has ~ 20*n tunnels on average at any given time +14:32 < jrandom> (where n = # nodes in the network) +14:32 < jrandom> at an average of 2 hops per node, that means every node participates in an average of 40 tunnels +14:33 < hypercubus> ideally ;-) +14:33 < jrandom> well, thats the thing, balancing like that *isnt* ideal +14:33 < jrandom> since not all nodes are as fast or have as much bandwidth +14:33 < jrandom> on the ohter hand, balancing the tunnels so they all go through 2 or 3 really fast peers also sucks +14:33 < jrandom> since if one of those go down, *boom* +14:34 < hypercubus> right, so why is dm's inferior DSL connection so overloaded, while my much faster DSL connection has been under-utilized? +14:34 < Sciatica> will this problem go away as the # of nodes in the network grows beyond 100, 200, etc.? +14:34 < dm> inferior? :'( +14:34 < jrandom> hypercubus: because i2p is currently nonresponsive to the bandwidth available, unless people turn on bandwidth limiting +14:34 < hypercubus> dm: technically speaking ;-) +14:34 < hypercubus> ok i have bandwidth limiting enabled... dm must not? +14:35 < Sciatica> (at some point won't the number of nodes a server can host be greatly dwarfed compared the the number of total nodes [e.g., tunnels]? +14:35 < ugha_node> Arrr! +14:35 < ugha_node> '(the local message processing time exceeds 1s)' -- I don't think we should program any such constants into the router. I think all such values should be taken from the (I2P network) environment, so it would still work in case the router lands in an unexpected enviromnent. +14:35 < dm> yeah, I don't, also my uplink is decent: 256kbps (downlink 150kbps) +14:35 < Sciatica> bad terminiology -- I type too slow for such issues :-) +14:35 < jrandom> Sciatica: it isn't a problem, is just a reality. if every node maintains 20 tunnels at any given time, with each tunnel an average of 2 hops, no matter how large the network is, it averages out +14:36 < jrandom> ugha_node: agreed - the 1s thing is random #, but how can we derive the "right" value? what amount of delay is "a lot"? +14:37 < jrandom> we do have some code in the RouterThrottleImpl that tracks "how much bandwidth we've agreed to allocate" +14:37 < jrandom> but at the moment, it doesn't throttle based on that +14:37 < dm> hmmmm I don't like these overload discussions... flashbacks of freenet. +14:37 < jrandom> (bandwidth agreed to == # participating tunnels * # messages per tunnel on average * # bytes per message on average) +14:37 < dm> Maybe we should use estimators? +14:38 * jrandom kicks dm +14:38 < hypercubus> dm: are you using bandwidth limiting in your router? +14:38 < dm> hypercubus: no +14:38 < hypercubus> dm: i highly recommend using it ;-) +14:38 < dm> jrandom: three words... NGR +14:38 < fvw> It's really up to the node that requested the tunnel, right? What kind of lag are they willing to put up with? Would it be viable to make it one of the tunnel parameters? +14:39 * fvw wonders if dm is trying to scare us or if it's merely an added benefit. +14:39 < jrandom> hmm, that has potential +14:39 < dm> errr.. won't that just move the arbitrary threshold to the requesting router? ;) +14:39 < dm> I don't want to choose, you choose! +14:40 < jrandom> yes dm, but the requesting router knows what the tunnel will be used for (irc w/ low lag vs bulk w/ high lag and high throughput) +14:40 < fvw> yes, but for some things 10s lag is no problem (think file transfers), whereas other stuff (irc) needs low latency. +14:40 < dm> yeah, so you have the app layer decide the threshold? +14:40 < jrandom> that is, however, dangerous +14:40 < fvw> the only problem is using high-latency links will not increase capacity, so in the end file transfers get all the resources. +14:41 < cat-a-puss> can you really trust any load claims made by the router, otherwise a malicious preson could try to get another nodes traffic to go through all their routers +14:41 < jrandom> cat-a-puss: these are only used to reject requests to participate, not to solicit +14:41 < ugha_node> You can't. +14:41 < cat-a-puss> ok +14:42 < jrandom> a malicious user can of course accept tunnels when they're totally overloaded, but we'll detect that when the tunnel fails +14:42 < jrandom> (and the freeloader can reject the tunnel when they arent loaded, but, c'est la vie) +14:43 < jrandom> the throttle based on local overload is pretty effective though. however, that isn't enough +14:43 < dm> greedy bastard +14:43 < jrandom> i've been trying to find out an ideal way to work out whether to accept it or not, and i think that there is some potential for probabalistically rejecting requests we would otherwise accept, based on how many tunnels we are already in +14:44 < jrandom> the concept there is that the peer wants other people to take on some load +14:44 < cat-a-puss> should we run as many virtual routers as avalable bandwidth? +14:44 < jrandom> (so as to distribute the failure) +14:44 < jrandom> hmm cat-a-puss? +14:44 < jrandom> are you running the sim on the live net? +14:45 < jrandom> in any case, no, a single router should be able to address the local capacity +14:46 < deer> problem is that bandwidth used in a tunnel may change significantly over time, right? +14:46 < cervantes> which is not currently happening...at least not for me +14:46 < cat-a-puss> well if it's all random how can you take advantage of an oc3 any more than some poor guy on a 56k? You ether have to advertise: problematic, or run virtual routers, ether way I think a malicious party could try to encircle a node for some sort of stistical attack +14:46 < jrandom> right mule_i2p. we need to do some more monitoring of the tunnel activity +14:46 < cervantes> 14 participents each have 11.5mbit ... that's a bit of a waste :) +14:47 < jrandom> cat-a-puss: probabalistic != random :) +14:47 < jrandom> heh cervantes +14:48 < jrandom> the basic idea behind probabalistically rejecting would be to spread the load out to other peers. however, if the network really is saturated, the probability won't be a problem as people will just ask again +14:48 < jrandom> the issue is that we currently have an overwhelming *excess* of capacity +14:48 < Sugadude> Poor i2p, having *too* much capacity. Don't worry, I'm on it. ;) +14:49 < fvw> assuming everyone is wellbehaved, you could perhaps not reject from people who come back within a short interval of being probabilisticly rejected? +14:49 < deer> so fill any tunnel with some cover traffic +14:49 < jrandom> heh Sugadude :) +14:49 < cervantes> that's because everyone's requests are being handled by dm's router ;-) +14:49 < jrandom> fvw: we dont know who requests a tunnel +14:49 < fvw> hmm, good point. *screws head back on* +14:50 < jrandom> fvw: probabalistically, subsequent requests would be accepted - we'd want the 'reject' factor to stay low enough +14:50 < deer> which will increase anonymity and make load calculation easier +14:51 < jrandom> true mule_iip, but it'd be nice to actually have the net operate effectively without requiring high load :) +14:51 < jrandom> but that is definitely a worthwhile scenario for the sim +14:51 < deer> effectively make i2p use a constant bitrate with cover traffic. but that was for a future release, i guess :) +14:52 < jrandom> we *could* use ATM-style allocation +14:52 < fvw> Doesn't bandwidth usage vary too much for that to be viable? +14:52 < jrandom> e.g. assume 5 messages per minute per tunnel @ 32KB each, and compare that with the bandwidth limits, and reject accordingly +14:52 < cervantes> hyper has some ascii we can use to pad the messages out +14:52 < hypercubus> hmmmm, i don't like that constant bitrate idea... i2p would be filtered by ISPs very quickly if that were implemented +14:53 < jrandom> heh cervantes +14:53 < deer> yes +14:53 * hypercubus doesn't know what cervantes is talking about +14:53 * hypercubus hides his floppy +14:53 < jrandom> fvw: padding? or allocation? +14:53 < fvw> allocation +14:53 < cervantes> ah ya plausable deniability huh +14:54 < jrandom> hmm fvw. perhaps, but I think we can monitor them statistically and compensate +14:54 < deer> constant bitrate sounds like Waste +14:54 < jrandom> for instance, http://localhost:7657/oldstats.jsp#tunnel.bytesAllocatedAtAccept +14:54 < hypercubus> hence its name ;-) +14:55 < jrandom> that stat monitors how much bandwidth we have agreed to pass on for other people's tunnels +14:55 < jrandom> (using the last 10 minutes as a guideline) +14:56 < jrandom> so my peer with 85 tunnels says it will transfer 3,676,945.65 bytes over the next 10 minutes for all of those tunnels, combined +14:56 < deer> kaji: it is waste, and we probably should use it only for the more severe threat models. but would be nice for low latency like irc. +14:56 < jrandom> thats 72bps each, but I'm not sure how skewed it is (probably *very*) +14:57 < jrandom> however, if all of those tunnels started using lots and lots of bandwidth, the total value would shoot up, and we could throttle it +14:57 * fvw nods. +14:57 * fvw notes this is in fact a wildly interesting problem, theoreticly speaking. +14:57 < fvw> (but maybe that's just me being weird) +14:57 < jrandom> agreed +14:58 < jrandom> (to both ;) +14:58 < jrandom> but yeah, we dont have the Right Answer yet. but its something to be worked on +14:59 < jrandom> ok, unless there's anything else on that, moving on to 3) Website updates +14:59 < fvw> We could ofcourse go totally lossy and just drop datagrams when we're overloaded, and make people run something like tcp over that. +14:59 < jrandom> we tried that, and lots and lots and lots of tunnels failed +15:00 < jrandom> (since if a tunnel drops 1 message, we mark it as failed) +15:00 < fvw> yes, you shouldn't do that if you take that approach. +15:00 < jrandom> ((and when we tried not being such fascists, we didn't notice when a tunnel *really* fails)) +15:00 * fvw nods and strokes his beard. Good point. (mental note to self: grow beard to stroke in situations like this) +15:01 < jrandom> heh +15:01 < jrandom> ok, anyway, as you've all seen, our new installer and new web interface is completely different from the old way of doing things +15:01 * hypercubus gives fvw his beard +15:02 < jrandom> while that is Good, since the old way was Painful, all our old docs are now wildly incorrect +15:02 < fvw> could we stick on 2) a few minutes longer? I still have a few bad ideas I want you to shoot down. +15:02 < jrandom> sure +15:02 < dm> I can't use the internet... +15:02 < dm> Bandwidth in/out +15:02 < dm> 1m: 13.32/11.98KBps +15:02 < dm> 5m: 10.74/9.46KBps +15:02 < jrandom> how many tunnels dm? +15:02 < hypercubus> dm: that's why i suggested you turn on i2p's bandwidth limiting ;-) +15:02 < dm> only 166 +15:02 < jrandom> yeah, throttle it down to 6KBps +15:02 < jrandom> lol +15:03 < dm> (participating) +15:03 < jrandom> (or maybe 8KBps if you're nice) +15:03 < dm> I'll leave it as is, I just need to view this one page +15:03 < jrandom> btw, the 13.32 vs 11.98 lets us know you're downloading approximately 1KBps locally +15:03 < jrandom> (through i2p) +15:03 < fvw> What happens if we just time-out tunnels at a reasonably large idle-time? Say 30 mins or something. The next protocol up would have to do keepalives, but wouldn't that solve the not-detecting-dead-tunnels thing? +15:03 < hypercubus> he's downloading far more than that actually +15:04 < jrandom> ((though that 1KBps might be small enough to be netDb)) +15:04 < dm> hypercubus: our transfer is stalling badly, actually. +15:04 < jrandom> fvw: tunnels expire after 10 minutes +15:04 < deer> hold it, is bandwidth working now? if so what sould i turn it to? +15:04 < dm> dissapointed in the getright/i2p combo +15:04 < jrandom> they're not long lived fvw, unlike TOR +15:04 < fvw> and that had most tunnels failing, even with keepalives? +15:04 < hypercubus> dm: periodically yes... i think the solution would be to limit your upstream to about 8KB/s +15:04 < jrandom> kaji: http://localhost:7657/ +15:05 < hypercubus> since it seems you're saturated +15:05 < jrandom> er, /config.jsp +15:05 < fvw> ok, but you don't want them dissapearing in flurries of packet loss. +15:05 < jrandom> every minute (on average) each peer tests each tunnel to make sure its alive (so that other people can send us data - without tunnels, we're fucked) +15:06 < fvw> Ok. I need to read more of how i2p currently works. On to 3) as far as I'm concerned. +15:06 < deer> right now its set on the default -1 but I dont know what a 1.5/750@1.2ghz connections translates to from maximum tunnel partisipation +15:07 < deer> i seem to be participation in 166 +15:07 < jrandom> kaji: your router will never get so many tunnels that it'll be CPU congested ;) +15:07 < deer> off-topic: don't you need a tunnel to be fucked :) +15:07 < deer> *ing +15:07 < jrandom> heh +15:07 * fvw votes "nay" +15:08 < deer> jrandom, i just finnished reading the letter about tunnels without bandwidth, i just didnt know what to set the limmit to +15:08 < jrandom> ok, i agree, lots more to be done to figure this stuff out +15:08 < jrandom> ok cool kaji, just enable your bandwidth limiter to something like 8KBps +15:08 < jrandom> (or 12 if you're nice :) +15:09 < deer> +15:09 < jrandom> ok, on to 3) website updates +15:09 < deer> inbound and outbound? +15:09 < jrandom> yes kaji +15:09 < jrandom> ok, as I said, we need help with the docs +15:09 < jrandom> (heeeeeeeeelp!) +15:09 < hypercubus> i move we fill the long-vacant team positions of Webmaster and Web Editor +15:10 * jrandom seconds that motion +15:10 < jrandom> (now all we need is someone to volunteer ;) +15:10 < hypercubus> i know cervantes is a busy guy +15:10 < jrandom> its more up to the invidual to volunteer /themselves/ hyper ;) +15:10 < hypercubus> i nominate Curiosity for Webmaster or Web Editor, or both if she's up for it ;-) +15:11 < deer> Uhh. +15:11 < dm> Man, even my CPU is starting to max out because of I2P... +15:11 < dm> You love, you REALLY love me :'( +15:11 < dm> oops, :') +15:12 * cervantes feels someone pushing him into the bull ring +15:12 < jrandom> i think we can use all the help we can get, and if she is up for helping, we'd love it +15:13 < hypercubus> i've seen her web designs and can vouch for her work +15:13 < hypercubus> and she expressed interest, i don't know what she finally decided however +15:13 < jrandom> ok great +15:13 < dm> she? +15:13 < cervantes> I'm sure she can devote far more care and attention to it than I ever could +15:14 < dm> that word must not be used in our world +15:14 < fvw> never mind that, he said 'care and attention'. +15:15 * jrandom groans +15:15 < fvw> present company excluded ofcourse. +15:15 < jrandom> ok, in any case, we'll need some people to help out on the docs - generating new walk throughs, intro docs, etc +15:16 < jrandom> we'll chat with Curiosity about what we can get her to hack on :) +15:16 < hypercubus> i can take on the installation related stuff +15:16 < hypercubus> s/on/of/ +15:16 < hypercubus> i know how everyone loves to read these baroque howto's that i write ;-) +15:16 < jrandom> :) +15:17 < jrandom> an install guide / walkthrough would KickAss +15:17 < fvw> that's not how you spell 'broke'. +15:17 < jrandom> heh +15:17 * hypercubus snickers, then steals fvw's wallet +15:17 < hypercubus> that's how you spell "broke" ;-) +15:17 < deer> hyper what system are you on? i'll take a crack on the winxp version but im not very reliable, i may see something shiny and quit +15:17 < deer> * Curiosity is away for a bit... +15:18 < hypercubus> kaji: ? +15:18 < deer> hyper, i was asking what OS you are using +15:18 < hypercubus> OSes +15:18 < deer> OSESES +15:19 < hypercubus> i have vmware, so i can run all the windowses and freebsd and such +15:19 < hypercubus> also have pearpc, so i can run OS X +15:20 < jrandom> ok, if there's nothing else on the web side +15:20 < jrandom> moving on to * 4) I2PTunnel web interface +15:21 * jrandom declares the i2ptunnel web interface shitty. functional. but shitty. +15:21 < deer> I could dig in for french translation if interest may be +15:21 < jrandom> duck had a few ideas for improving it, but he had to jet, so let me paste a few lines +15:21 < hypercubus> again, we need more web devs ;-) +15:21 < jrandom> oh, translating web pages to french would rule +15:22 < jrandom> s/french/french and other langs/ +15:22 < jrandom> here are some duck-isms: +15:22 < jrandom> reduce data load on general page; use tables/div to order stuff +15:22 < jrandom> provide a edit/detailed page with info most dont care about, tunnels, dest hash, full key +15:22 < jrandom> feedback after clicking buttons, 'item saved' etc. give dest as output when new one created +15:22 < jrandom> (hide under edit/details otherwise) +15:22 < jrandom> tag the top messages as being 'log'; sometimes confusing +15:22 < jrandom> make clear that 'confirm' is only needed for remove, not save +15:22 * jrandom agrees with what he says +15:23 < jrandom> there have been a slew of bugfixes behind the scenes in the /i2ptunnel/ web interface since 0.4 too, so the functional kinks should be cleaned up +15:24 < jrandom> the code implementing those pages are pretty ugly though +15:24 < jrandom> probably the best approach would be to write up the screens in plain html / css / images / etc, then give it to one of the java devs to integrate +15:25 < hypercubus> whatever happened to the days when there was an overabundance of web devs? ;-) +15:25 < jrandom> they're all working at mcdonalds +15:25 < hypercubus> ah right +15:25 < deer> * Curiosity is back :) +15:25 < jrandom> anyway, if anyone is interested in helping out, or has further suggestions, please get in touch +15:25 < jrandom> wb Curiosity +15:26 < deer> should i bring up the idea i told oyu about jrandom? +15:26 < cat-a-puss> I know someone who might be able to help with the web stuff +15:26 < jrandom> ah, the live cd? +15:27 < jrandom> great cat-a-puss, we need all the help we can get +15:27 < deer> teah :) +15:27 < deer> err yeah +15:27 < jrandom> Curiosity: yeah, please bring that up when we get to item 6) ??? +15:28 < deer> okay :) +15:28 < cat-a-puss> ok, I'll get them on the list, and give them jrandom's e-mail (curiosity I don't know your email) +15:28 < jrandom> ok, does anyone have anything else to mention regarding the I2PTunnel web interface? +15:28 < jrandom> r0x0r cat-a-puss +15:29 < deer> also, i don't mind helping wiht the web editing, etc. also :) +15:29 < jrandom> ok, if there's nothing else, 5) Roadmap and todo +15:30 < jrandom> awesome Curiosity, thanks! we can chat a bit after the meeting about taking over the world^W^W^W^Wweb stuff +15:30 < deer> okies :) +15:30 < jrandom> as y'all probably saw, there's a new big scary page on the website (http://www.i2p.net/todo) +15:31 < jrandom> that covers the big scary issues we have ahead of us (and doesnt even touch on all the client apps we need, etc) +15:31 < jrandom> as you can see, we've got a shitload to do, but the good news is, we dont have to have it all done right away. +15:32 < jrandom> in fact, those things are really just the bullet items from the roadmap page (with a heap of text introducing each) +15:33 < jrandom> while i know thats a lot to sort through, what would be great is if people could let me know if they come across something that we will need to deal with that isn't on that page +15:34 < jrandom> that isn't necessary today or this week even, just a general "hey, let us know" +15:35 < jrandom> with mule's suggestion (http://www.i2p.net/todo#nat) i've been doing a lot of soul searching, and the roadmap will likely be moved around a bit +15:35 < jrandom> but we'll see. +15:36 < jrandom> if you have any strong feelings on certain issues ("omg we *cannot* function without X, Y, and Z!"), please let me know or post onto the list +15:36 < jrandom> while i'm no champion of democracy, i am open to reason :) +15:37 < jrandom> ok, thats all i've got to say about that.. anyone have anything to throw out there? +15:37 < deer> benevolent dictatorship :) +15:37 -!- Sonium_ is now known as Sonium +15:37 < jrandom> bah, i'm no dictator - i dont control what other people code :) +15:37 < cervantes> tranquil hegemony +15:37 < cat-a-puss> I've aquired two more developers +15:37 < jrandom> w00t! +15:38 < cat-a-puss> and have grand plans for a distributed search engine +15:38 < jrandom> oh, kickass +15:38 < jrandom> would that be something http://files.i2p/ could tie into? +15:38 < jrandom> or, well, let me just say, oh, kickass :) +15:38 < cat-a-puss> er: I can't get there (hostile enviroment) +15:39 < jrandom> ah 'k +15:39 < cat-a-puss> anyway, some CVS space would be nice, once we get there +15:40 < jrandom> certainly, space on cvs.i2p is available +15:40 < jrandom> either within the i2p/apps/ directory or your own module, if preferred +15:40 < jrandom> (cvs.i2p == cvs.i2p.net) +15:40 < cat-a-puss> I should probably talk to the people working on the dht huh? +15:41 < cat-a-puss> what is the status of that thusfar +15:41 < jrandom> :) +15:41 < jrandom> i haven't heard any status updates from aum in the last few days, but i'm sure he's churning away +15:42 < jrandom> last update was in http://dev.i2p.net/pipermail/i2p/2004-August/000425.html +15:43 < jrandom> ok, i guess that moves us on to * 6) ??? +15:44 < jrandom> Curiosity was bouncing around the idea of a 'live cd' idea with i2p +15:44 < jrandom> which i think is pretty cool, and something we will want +15:44 < deer> kewl :) +15:44 < jrandom> though we aren't really stable enough for that yet, with a release every 2 weeks or so +15:44 < hypercubus> agreed... it could even be integrated into a Knoppix ISO +15:45 < deer> ? +15:45 < hypercubus> Knoppix, a livecd distro of linux +15:45 < hypercubus> very user friendly +15:45 < deer> k +15:45 < jrandom> though once we have the Really Simple Update functionality that is a one click download from http://dev.i2p/i2p/i2pupdate.tar.bz2, it might not be too bad +15:46 < jrandom> Curiosity: do you have anything else you want to discuss about that? +15:46 < fvw> ...and as soon as it becomes widely used, anyone controlling dev.i2p can compromise the network. +15:47 < jrandom> as long as people use that Really Simple Update functionality +15:47 * fvw nods. +15:47 < deer> i just wanted a way for people to run it w/o having to download a bunch of stuff onto their computer +15:47 < jrandom> (and if dev.i2p is compromised, we put up a new hosts.txt entry for dev.i2p) +15:48 < hypercubus> a knoppix i2p livecd would be prime for cybercafe use +15:48 < deer> jarndom: won't a real i2p user grab the source, study the diff against the latest peer reviewed version and build from source :) +15:48 < fvw> yes but people will just hit 'update'; They won't listen to discussions about whether the new version might have vulnerabilities... +15:48 < demonic_1> is there anyway to not need hosts file. u know like a dns server? +15:48 < deer> yeah... riiiight mule_iip. lol +15:49 < fvw> but anyway, I'll be very happy when we get to the stage where this becomes a problem. +15:49 < fvw> demonic_l: It's possible, but there'd still be a central authority. +15:49 < hypercubus> demonic_1: there are currently a couple of proposals for such functionality, but global names have been ruled out +15:49 < jrandom> demonic_1: yes, see the mailing list (recent discussions on http://dev.i2p.net/pipermail/i2p/2004-September/000432.html ) +15:49 < jrandom> (and my take @ http://dev.i2p.net/pipermail/i2p/2004-September/000435.html :) +15:50 < hypercubus> *globally unique names +15:50 < demonic_1> k +15:51 < jrandom> ok, anyone have anything else they want to bring up? +15:52 < deer> I would also like ot suggest putting service only items into a service folder... i was trying to uninstall i2p (one time of many) and was hitting the wrong uninstall thingie +15:52 < hypercubus> Curiosity: that's being done +15:52 < jrandom> w3rd +15:52 < hypercubus> the installer will install shortcuts for i2p to the Start menu in Windows +15:52 < hypercubus> and optionally on your desktop +15:52 < deer> okies :) +15:52 < hypercubus> among them will be "uninstall" +15:53 < deer> i was talking about when i go into program files/i2p +15:53 < hypercubus> you don't need to from there +15:54 < hypercubus> Windows users don't ever go into the program folders ;-) +15:54 < demonic_1> :/ +15:54 < deer> i do! :P +15:54 < jrandom> we could perhaps add a bin/ dir with all the scripts +15:54 < jrandom> er, nm +15:54 < hypercubus> then you would have seen the folder called "Uninstall" ;-) +15:54 * jrandom remembers the paths +15:54 < hypercubus> which is where the uninstaller is located +15:54 < jrandom> we can move the service scripts into lib though +15:54 < hypercubus> i'm not sure we can +15:55 < cervantes> you could go the 'doze method and have the "uninstall" option in the installer ;-) +15:55 < hypercubus> wrapper is very particular about where you put those +15:55 < jrandom> at the very least they can "cd .." first +15:55 < hypercubus> i'll look into changing their location +15:55 < hypercubus> but it might not be doable +15:55 < jrandom> cool, thanks. it'd be nice to remove some of the clutter in the install dir +15:55 < hypercubus> agreed +15:55 < jrandom> (most of which is my fautlt with all those .config files :) +15:56 < hypercubus> we could have a config dir i guess +15:56 < cervantes> ./conf ? +15:56 < jrandom> c'mon, we're geeks. etc/ :) +15:56 < jrandom> that would be Really Easy though +15:56 < jrandom> (just a few -D parameters on the CLI) +15:56 < hypercubus> then we'll have to field questions from Windows users that "etc" isn't obvious enough ;-) +15:56 < jrandom> people shouldnt need to touch their config +15:57 < jrandom> thats what the web is for +15:57 < cervantes> I've always gone for the blatant: ./configuration/ +15:57 < hypercubus> right, but Windows users shouldn't need to launch the uninstaller from their program directory either heheh +15:57 < jrandom> ./thesefilestellstufftodothings/ +15:57 < cervantes> ./scripts/ +15:57 < cervantes> ./asciipr0n +15:57 < jrandom> ok, but yeah, some work we can flesh out +15:57 < deer> lol +15:58 < jrandom> anyone have anything else to bring up for the meeting? +15:58 < jrandom> if not +15:58 * jrandom winds up +15:59 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/106.rst b/i2p2www/meetings/logs/106.rst new file mode 100644 index 00000000..c8428b77 --- /dev/null +++ b/i2p2www/meetings/logs/106.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 7, 2004 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/107.log b/i2p2www/meetings/logs/107.log new file mode 100644 index 00000000..18f3f3e5 --- /dev/null +++ b/i2p2www/meetings/logs/107.log @@ -0,0 +1,494 @@ +14:06 < jrandom> 0) hi +14:06 < jrandom> 1) 0.4.0.1 +14:06 < jrandom> 2) Threat model updates +14:06 < jrandom> 3) Website updates +14:06 < jrandom> 4) Roadmap +14:06 < jrandom> 5) Client apps +14:06 < jrandom> 6) ??? +14:06 < jrandom> 0) hi +14:06 * jrandom waves +14:06 < cervantes> evening +14:06 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-September/000444.html +14:07 < jrandom> (before the meeting this time too ;) +14:07 < deer> woah, 30 people over here +14:07 -!- Irssi: #i2p: Total of 21 nicks [0 ops, 0 halfops, 0 voices, 21 normal] +14:07 < jrandom> ok, anyway, lets jump right in to 1) 0.4.0.1 +14:08 < jrandom> the release is out and things seem to be working more or less +14:09 < jrandom> i see a variety of connection times on irc, though in discussions with people, it seems there are congestion issues when e.g. downloading large files and using irc at the same time +14:09 < jrandom> are many people running into that? +14:10 < jrandom> i guess not +14:11 < cervantes> I've been doing various bandwidth tests recently and haven't encounter problems in that area yet...although I'm not using the bandwidth limiter +14:11 * nicktastic hasn't downloaded much since raiding alexandria weeks ago +14:11 < dm> I remember getting disconnect more often on IRC when I was using eepsites, but that was 2 months ago +14:11 < dm> disconnected +14:11 < dm> not sure if it still happens +14:11 < jrandom> ah, yeah, we need to harass the alexandria folks to give us more books :) +14:12 < Nightblade> thanks for keeping us up to date dm +14:12 < jrandom> i've had good luck w/ irc while downloading some large files from thetower, but, like cervantes, i dont have bandwidth limiting set +14:13 < jrandom> (though that router's bw average was a steady 11KBps at the time, while downloading 8KBps of music) +14:13 * nicktastic finds something to download +14:13 * jrandom watches your irc.duck.i2p connection quickly get dropped ;) +14:13 < jrandom> ok, anyway, does anyone have anything else they want to bring up wrt 0.4.0.1? +14:14 < dm> Nightblade: hehe, no problem :) +14:14 < dm> jrandom: good work, ever onwards +14:14 < fvw> the installer is pretty? (not sure if that's new in .1?) +14:14 < jrandom> gracias dm +14:15 < jrandom> fvw: same as 0.4, but i agree, hyper did some great work there (as did our anonymous designer!) +14:15 < fvw> also, I'm not going to commit myself as to pretty _what_ it is :) +14:15 < jrandom> sonofabi... +14:16 < jrandom> ok, moving on to 2) Threat model updates +14:16 < cervantes> yes well done.. :) writing documentation always sucks +14:17 < jrandom> yeah, it was a painful 2-3 days +14:17 < jrandom> i'm not sure if any of y'all have read http://www.i2p.net/how_threatmodel but if you ever want to know wtf we're talking about when we say "anonymous", thats what we mean +14:18 < jrandom> most of the categories there were just ripped from http://citeseer.ist.psu.edu/454354.html (linked to on the page) +14:18 < jrandom> there's a lot more i'd like to do in the threat model, but i just dont have the time. +14:18 < jrandom> i'd love to see a matrix of those threats vs cost of mounting them vs the type of user who cares about them +14:19 < jrandom> (e.g. joe sixpack does't care about global active adversaries) +14:19 < jrandom> so if anyone is bored... ;) +14:19 < cervantes> something that occurred to me whilst reading your doc... we need a decent glossary... +14:20 < fvw> doesn't he? joe sixpack likes to download mp3s... +14:20 < jrandom> someone just published one iirc... +14:20 < cervantes> really? +14:20 < cervantes> on an eep? +14:20 < jrandom> no, some research paper +14:20 < jrandom> its not on freehaven yet, lemmie dig it up +14:21 < jrandom> bugger, i dont seem to have my copy anymore. +14:21 < jrandom> i'll try to track it down after the meeting +14:22 < cervantes> does it tackle i2p specific concepts to? +14:22 < jrandom> oh, no +14:22 < jrandom> its just a general glossary for anonymous networks, dealing with mixes, cascades, attackers, etc +14:22 < jrandom> no garlic routing or tunnels ;) +14:23 < cervantes> a nice single paragraph summary of all "in" buzzwords so people can quickly see the difference between onion and garlic routing (for example) withou having to read the whole "how" document +14:23 < jrandom> you realize a glossary would be larger than the how_* pages combined, right? +14:23 < jrandom> but yeah, i agree, we should do that +14:23 < cervantes> sure... but.. ;) +14:23 * jrandom volunteers cervantes to work on it ;) +14:23 * dm concurs +14:23 < cervantes> hehe I don't know what half that shit means :) +14:24 < jrandom> write up what you do know and ask me questions +14:24 < cervantes> I'll have a crack at it +14:24 < jrandom> w00t! cervantes++ +14:24 < cervantes> if I put it on the forum then others can contribute... +14:24 < jrandom> good idea +14:24 < deer> * Pseudonym cheers +14:25 < cervantes> _but_ that doc you mentioned would be handy :o) +14:25 < dm> tunnel: artificial underground passage +14:25 < jrandom> agreed, i'll try to find it again +14:25 < cervantes> I'll do a special version for you dm +14:25 < dm> yay! +14:26 < jrandom> ok, anything else on the threat model, or shall we move on to 3) Website updates ? +14:27 < jrandom> ok, as anyone who has been to the site today has seen, Curiosity has come up with some nice usability updates +14:27 < dm> I think cervantes and I are the only ones still awake. +14:27 < korkakak> I think that in threat models +14:28 < korkakak> you should add some mixnetwork attacks +14:28 < jrandom> what sort of mix attacks? +14:28 * dm loads up www.i2p.net +14:28 < korkakak> like collusion attacks +14:28 < jrandom> thats the thing that sucks about the taxonomies i used. they're all pretty much collusion attacks. +14:29 < korkakak> With mix attacks i mean attacks that may happen in a mix network +14:29 < korkakak> ah ok sorry +14:29 < jrandom> (and most can be used for either probabalistic or confirmation attacks, etc) +14:29 < dm> I like the increasing-in-size paragraphs. Helps drag people in. Far too technical for a front page though. +14:29 < korkakak> Another 5 cents from me: Can i2p detect a collusion automatically? +14:30 < jrandom> but if you have some suggestions for things we need to add, please, let me know +14:30 < jrandom> oh, definitely not. we haven't imported morphmix's algorithms +14:30 < korkakak> I c +14:30 < korkakak> ok keep on +14:30 < jrandom> though theirs wouldn't really fly with us though, since we're a free route mixnet +14:31 < korkakak> Well yes and no +14:31 < korkakak> but it is ok. SOrry for the interrutp +14:32 < cat-a-puss> It might also be a good idea to mention up frount some of the obvious attacks that I2p is NOT vunerable to +14:32 < jrandom> hmm? their algorithms are based off detecting the influence of colluding peers in the peer selection - within i2p, the local router explicitly defines the entire peer selection algorithm +14:33 < korkakak> I guess that this is true due to the size of todays network +14:33 < jrandom> ah, thats a good idea cat-a-puss, w/ MITM/etc. would you be interested in posting up some ideas for that? +14:33 < cat-a-puss> sure +14:33 < dm> MITM? +14:33 < dm> Ah, man in the middle. +14:33 < jrandom> muchas gracias cat-a-puss! +14:34 * cervantes jots down MITM for the glossary +14:34 < jrandom> korkakak: hmm. i'm not sure how that aspect is affected by the size of the net, but there may be things we can learn from morphmix's collusion detection, certainly +14:34 < jrandom> (perhaps wrt the netDb responses, for instance) +14:34 < korkakak> wrt = ? +14:35 < dm> hehee +14:35 < jrandom> sorry, with regards to +14:35 < dm> I know that one! +14:36 < jrandom> we would certainly benefit from more discussion on the threat model. perhaps we can start up a thread on the list or in the forum? +14:36 < dm> "The result is that the number of peers relaying each end to end message is the absolute minimum necessary to meet both the sender's and the receiver's threat model." +14:36 < dm> I like this way of looking at it. +14:37 < dm> Although it's not true. +14:37 < jrandom> hmm? +14:37 < jrandom> if both sender and receiver want only plausible deniability, they can talk directly +14:37 < jrandom> (etc) +14:37 < dm> The absolute minimum number of peers required to meet the threat model of A and B is the number of peers required by A or B, whichever has more stringent requirements :) +14:38 < jrandom> not true dm +14:38 < jrandom> if they both require 2 hop tunnels to defend against colluding attackers in their tunnels, they can't both have 1 hop tunnels +14:39 < dm> If A is willing to talk to someone with 10 indirections, and B is willing with 5, the minimum needed is 10, not 15!? +14:39 < jrandom> no, 15. B shouldn't trust A's tunnels. +14:39 < dm> Yeah, he shouldn't. +14:39 < dm> But theoratically.. Anyway, stupid discussion. I like that sentence though. +14:40 < jrandom> its one of the more important design decisions in i2p ;) +14:40 < jrandom> anyway, back to 3) Website updates +14:41 < deer> (fyi - irc dropped while downloading two large files, but latency to the server is as it was before the downloads started, so could've been a fluke (ungraceful shutdown somewhere?)) +14:41 < jrandom> Curiosity and I discussed the length of the new homepage, and while we all agree that its a little long, its better than the old 1 liner +14:41 < cervantes> agreed +14:42 < jrandom> ah ok. perhaps even network congestion while downloading, since the eepproxy and the irc client use the same I2P destination (by default) +14:42 < nicktastic> Aaah.... +14:42 < jrandom> (so both would be trying to use the same pair of inbound tunnels) +14:42 < nicktastic> I was wondering why only one showed up +14:43 < jrandom> yeah, thats the default within I2PTunnel and the ministreaming lib. perhaps if someone cares we can expose a way to configure that ;) +14:43 < nicktastic> sorry to interrupt +14:43 < deer> * Pseudonym cares +14:43 < dm> such polite lads we have in this room +14:43 < interrupt> you are forgiven +14:44 < interrupt> ;) +14:44 * nicktastic rolls eyes +14:44 < jrandom> patches welcome Pseudonym ;) (naw, i'll see if i can find an easy way.. shouldnt be too hard) +14:44 < jrandom> ok, anyway +14:44 < deer> good, 'cause I don't know crap about how to code in java +14:45 < jrandom> there may be further website updates, but if anyone has any suggestions, please post 'em to the forum or the list, or point 'em out to Curiosity on irc and we'll get things rolling +14:45 < jrandom> anyone have anything they want to bring up wrt the website? +14:45 < cervantes> umm bouties perhaps +14:46 < cervantes> although maybe that's best saved for 5 +14:46 < jrandom> prolly so +14:46 < jrandom> ok, moving on to 4) Roadmap +14:46 < jrandom> lots of updates. see the email for info +14:47 < jrandom> (or look at the pretty gantt chart ;) +14:47 < dm> Was that done in MS Project? +14:47 < jrandom> http://ganttproject.sourceforge.net/ +14:47 < cervantes> eerm gantt :) +14:47 < dm> oh.. gantt is a product. My bad. +14:48 < dm> Nice to see there are no dependencies in the roadmap. +14:48 < jrandom> i've posted a few different revs of the roadmap over the last few days, but this one seems to be solid +14:48 < cervantes> it's all dependant on jrandom ;-) +14:48 * jrandom whimpers +14:48 < fvw> 3.0 in febuary? Wow. +14:48 < jrandom> the 2.0 and 3.0 releases are really just 1 (big) feature each +14:48 < dm> Don't forget: exponential versioning +14:49 < jrandom> heh +14:49 < jrandom> yeah, we'll be 1183 by next july +14:50 < dm> Well, it's more interesting than the abritrary +0.1 per build of most projects, so I'm not complaining. +14:50 < jrandom> the 2.0 and 3.0 releases may be delayed to stay in line with other apps though. e.g. 3.0 would work great with an email app +14:51 < jrandom> the release criteria for 1.0 has been the usual - functional, secure, scalable, and anonymous +14:51 < jrandom> thats why i moved the udp transport in, as our current tcp transport would shit bricks if we had a few thousand peers +14:51 < dm> so we should have a 0.9 - The Slashdot +14:51 < dm> if it survives we can check off scalable and move to 1.0 +14:51 < jrandom> heh +14:52 * jrandom would rather grow organically, thankyouverymuch +14:52 < cervantes> we don't to tell _them_ about it +14:52 < cervantes> *don't want +14:52 < korkakak> btw may i say something about the global timing? +14:52 < cervantes> let them all stay on the internet while we move here +14:52 < jrandom> sure korkakak +14:53 < korkakak> As far as i am concerned you cannot simulate a synchronus network over an asynchronous +14:53 < korkakak> it is just bad design and should lead to network splits [i think] in the way it is used +14:54 < korkakak> as a timestamp for UDP packets +14:54 < jrandom> the timing is not synchronized for messaging, merely to help us know the freshness of data +14:54 < korkakak> yes that's the point +14:54 < jrandom> without knowing the freshness of the netDb entries, you're vulnerable to a whole slew of attacks +14:55 < korkakak> Yes +14:55 < korkakak> but imagine a growing network +14:55 < korkakak> a huge network +14:55 < jrandom> like the internet +14:55 < dm> bigger! +14:55 < fvw> two internets tied together with bits of string! +14:55 < jrandom> that has a network time protocol for scaling to such sizes... ;) +14:56 < korkakak> I don't think I understand your point but +14:56 < dm> korkakak: what are you trying to say? +14:57 < korkakak> that net splits may happend due to invalid timestamps +14:58 * dm is not sure how syncing works currently +14:58 < korkakak> the case is called localization effect [english translation from greek] +14:58 < deer> i hear i2p's anonymity has been cracked +14:59 < deer> true ? +14:59 < jrandom> i believe we can address the time sync issue the same way the NTP networks do. there are a massive number of tier 2 and 3 NTP hosts, and while our current SNTP implementation is of course unsuitable for congested environments, there is no reason to believe time synchronization isn't possible +14:59 < jrandom> heh soros +14:59 < jrandom> soros: the thread you're referring to (someone else mentioned it to me) on devl was talking about JAP being compromised, not I2P. +15:00 < dm> so all I2P nodes must stay synced at all times for it to work? +15:00 < korkakak> NTP nets are synhcronus networks over synchronus networks ;-) +15:00 < jrandom> but if someone has a compromise for I2P, I would certainly love to hear about it +15:00 < deer> i have one but i'm keeping it a secret +15:00 < jrandom> at various levels of abstraction korkakak, sure. my ethernet cable is synchronized too +15:01 < deer> :) +15:01 < jrandom> yes dm, synchronized to the network time +15:01 < korkakak> jrandom it is nick or korki :-) +15:01 < jrandom> (the point is that we dont use synchronous messaging) +15:01 < jrandom> :) 'k +15:01 < jrandom> (please dont be offended if i dont tell you my name ;) +15:02 < korkakak> No I am not +15:02 < dm> His name is Abdul +15:02 < jrandom> ok where were we +15:02 < nicktastic> 4) +15:03 < jrandom> ok right, thanks. the roadmap +15:03 < jrandom> anyone have any concerns / ideas / suggestions? +15:03 < dm> so when you say some work is going to be done on the transport, do you mean reworking TCP, or moving to UDP? +15:04 < jrandom> UDP is 0.4.4 +15:05 < dm> I thought I saw something about work on the transport layer +15:05 < dm> in the near future +15:05 < jrandom> yes, 0.4.1 will be a revamp of the TCP transport +15:05 < dm> why revamp TCP in 0.4.1 if going UDP in 0.4.4? +15:05 < dm> We'll need both? +15:05 < cervantes> only to point out that your are still the only resource in the project plan... ...are we suffering from a lack of contributors or just project fragmentation? +15:06 < jrandom> dm: some people cannot use UDP +15:06 < dm> firewalls? +15:06 < jrandom> cervantes: we certainly could parallelize many of those tasks with more contributors +15:07 < jrandom> (but the roadmap does not assume more) +15:07 < cervantes> so hopefully it represents the worse case scenario +15:07 < jrandom> there is however other important work going on not reflected on the roadmap, such as client mods, services on top of i2p, etc +15:08 < cervantes> asside from you being assassinated +15:08 < dm> I wish we could afford toad +15:08 < deer> now that 0.4 is out and pretty much working, should we announce somewhere (not necessarily /.) to try to increase the number of developers/testers/donors? +15:08 < jrandom> more contributors would certainly be welcome +15:08 * korkakak farewells all. REady to go to his bed. It is late at korkakak lands... +15:08 < korkakak> bye gayz +15:08 < cervantes> g'night +15:08 < jrandom> thanks for swinging by nick, ttyl +15:10 < dm> nite +15:10 < jrandom> a /. would probably be premature, but it would be good to bring new folks on board through other means +15:10 < dm> You're very open to Pseudonym's suggestion. I thought you were going to freak out. +15:10 < jrandom> but i think through word of mouth we're growing steadily +15:11 < deer> and if we do want to announce, where should we do it? +15:11 < jrandom> i dont think we should have any announcements yet, not till 1.0 +15:11 < deer> seems like we could use an influx of cash/talent +15:11 < jrandom> but if you hear someone talking about how they wish there were some way to help do stuff anonymously, point 'em at i2p ;) +15:12 < deer> * DrWoo suggests a whisper campaign +15:12 < cervantes> we have a fair amount of unnallocated cash already... +15:12 < jrandom> we're an open team, but you only have one chance to make a first impression. +15:13 < cat-a-puss> I would not recomend going from no publicity to /. there needs to be an intermediate step to make sure we can handel the load +15:13 < deer> then we should allocate it to bounties we think are important +15:13 < dm> We need to hire a full-time dev or find someone REALLY REALLY bored +15:13 < jrandom> agreed. i'd like to see at least 500 routers online prior +15:13 < jrandom> actually, y'all are moving us right along to 5) Client apps :) +15:14 < jrandom> we do have ~300 in the pot at the moment (well, almost, but thats another story) +15:14 < deer> any suggestions on what the intermediate step could be? +15:14 < jrandom> pseudonym: we can't have 1000s of nodes until 0.4.4 +15:15 < jrandom> (and we'd want to stress test the net out first) +15:15 < fvw> Actually, we probably can on most unices. Needs adjusting the rlimits though. +15:15 < jrandom> right right +15:15 < jrandom> it'd be painful, anyway ;) +15:16 < deer> right. so no /. but it seems like there should be somewhere we can get a couple hundred +15:16 < jrandom> we can do larger sims though +15:16 < deer> does anyone know someone at the EFF? maybe they have a mailing list +15:17 < jrandom> yeah, i've spoken with some eff folks about some things +15:17 < fvw> I think any announcement will cause it to filter through to slashdot. I agree with jrandom, a little waiting isn't bad at this time. +15:18 < dm> you have to be aware that if you hit 200-300 nodes, you're most likely to get an automatic /. mention ;) +15:18 < jrandom> (especially since we've been going for ~ 15 months already) +15:18 < dm> critical mass/hype and all that +15:18 < jrandom> well, thats also another thing that leads in to 5) Client apps +15:19 < jrandom> i'm watching some stats and it seems probably 1/4th of the routers out there aren't even really doing any client activity +15:19 < jrandom> which is great and wonderful that people are willing to donate their resources to act as I2P routers, but its too bad that we dont have something to suck them in :) +15:19 < fvw> Yeah, I'd like to do a proper chat app (as in irc, but in a way that makes sense for i2p), but this is very much a long term thing, no time the next few months... +15:20 < jrandom> we have had an influx of kickass eepsites recently though +15:20 < jrandom> ah cool fvw +15:20 < cervantes> many people run more than 1 router though +15:20 < jrandom> a solid IM/group chat for I2P would certainly rule +15:20 < nicktastic> fvw: Instant messenger with multi-user chat, perhaps? +15:20 < deer> dudes, in 0.4.0.1, how do i allow the router to listen on more than just localhost? +15:20 < cat-a-puss> hey, could someone write a gaim plugin? that would be a good way to do it +15:20 < jrandom> right cervantes +15:20 < cervantes> they maybe use 1 for apps...and donate the others +15:21 < jrandom> mrflibble: http://localhost:7657/i2ptunnel/ to configure the http and irc proxies to listen on "any interface" +15:21 < fvw> which reminds me: could we do something multicastish for outbound tunnels? ie have one message delivered to multiple inbouds? +15:21 < nicktastic> cat-a-puss: Certainly possible +15:21 < fvw> yeah, in essence there's not much difference between irc and im, apart from the user interface. +15:22 < jrandom> fvw: yes and no. it wouldn't offer much savings (as messages are end to end encrypted, so you'd have to garlic wrap the message to the outbound tunnel's endpoint and direct the cloves seperately from there) +15:22 < jrandom> imho multicast would want to use an application layer overlay +15:22 < deer> oh, thanks jrandom! +15:22 < fvw> what do you mean by application layer overlay? +15:22 < jrandom> ala shoutcast/etc +15:23 < hypercubus> he means do the multicasting in the applcation layer +15:23 < hypercubus> not in the i2p layer +15:23 < cervantes> 'lo hyper +15:23 < fvw> yes ok. Fair enough. +15:24 < jrandom> ok, I ranted enough in the email about the client apps, so I'm not going to repeat myself here. +15:25 * fvw pouts and puts away the popcorn. +15:25 * jrandom !thwaps the wiseass +15:26 < jrandom> but, basically I think before we go "live", we need something engaging to go live *with* +15:26 < dm> If you build it, they will come... +15:26 < dm> hahaha, or not!!! +15:26 < fvw> yes. Though we could probably pull quite some crowd from freenet just by having dynamic (not to mention _working_) freesites. +15:27 < deer> what about using some of the money in the general fund to create/increase bounties for the engaging stuff +15:27 < nicktastic> ...and dht +15:27 < cervantes> I have no knowledge of freenet... how do freesites differ to eepsites? +15:27 < cervantes> if they are in any way the same +15:27 < deer> eepsites work +15:28 < deer> heh +15:28 < hypercubus> imo you guys are impatient +15:28 < cervantes> apart from that +15:28 < nicktastic> hypercubus: How's that? +15:28 < hypercubus> contribute to the project, or shut up +15:28 < deer> freesites are static. +15:28 < jrandom> bounties/voting some of the general fund to give $$$ to service providers / eepsites that do kickass things does sound like a good idea +15:28 * jrandom is the impatient one hypercubus ;) +15:28 < jrandom> Pseudonym: is that what you mean? +15:28 < cervantes> these applications are certainly not going to materialise overnight +15:29 < jrandom> right, thats why we need to talk about it now +15:29 < jrandom> duck: you 'round? +15:29 < hypercubus> it's these people pushing for public announcements +15:29 < fvw> I doubt you'll get more eepsites with bounties. The people who build them do it because it's fun, I doubt we could pay those who don't find it fun enough. +15:29 < deer> dynamic freesites can be updated, but only once a day... +15:29 < jrandom> probably true fvw +15:29 < deer> I was thinking more of using the general fund to support bounties for apps, not services/eepsites +15:29 < fvw> nobody's pushing for announcements, it was just discussed briefly. +15:30 < hypercubus> the project is evolving and growing naturally, have patience +15:30 < jrandom> ok word Pseudonym. +15:30 * fvw nods at pseudonym. That might be good yes. +15:30 < jrandom> what would y'all suggest? +15:30 < nicktastic> hypercubus: They're just brainstorming ways to grow the network without GROWING the network ;) +15:30 < jrandom> the entire donation pool is available to be applied wherever we see fit +15:30 < fvw> though I think small bug or feature bounties have the greatest chance of actually causing stuff to happen as opposed to being a nice gift for the person who happened to do it anyway. +15:31 < deer> small bounties don't seem to be working. how about we push a bunch of money into the MyI2p pot +15:32 < hypercubus> how about you donate? +15:32 < nicktastic> jrandom: Well, for swarming file transfer and dds to be useful, we need streams faster than 4kbyte/sec, so two bounties are fairly dependent on the streaming library bounty +15:32 < nicktastic> jrandom: But from earlier discussion, that sounds rather trivial +15:32 < cervantes> throwing money at things isn't going to make stuff appear overnight either :) +15:32 < deer> I have donated +15:32 < deer> just announce i2p to slashdot +15:32 < deer> thats all you need +15:33 < hypercubus> that is exactly the opposite of what we need +15:33 < deer> not overnight, but maybe somebody will start working on it +15:33 < jrandom> nicktastic: the streaming lib will be lots of work, but thats the 0.4.3 release :) +15:34 * nicktastic consults roadmap +15:34 < jrandom> but I agree with cervantes, $$ doesn't make code, coders make code. +15:34 < deer> is i2p listed on freshmeat ? +15:34 < jrandom> if only there were some magic way to get in touch with hackers without letting general users know ;) +15:34 < jrandom> not to my knowledge soros +15:34 < fvw> cross-post to other anonymity-related software mailinglists? +15:35 < fvw> actually, I think most of the people where already involved with freenet or gnunet, and have become aware of i2p already. +15:35 < cervantes> hack into their inferior anonymity networks and say "hi come and work for us" +15:35 < jrandom> we do get a good # of hits from gnunet's links page +15:35 < jrandom> heh cervantes +15:35 < deer> there r some ng's i would think +15:36 < cervantes> (work for us or we'll give your ip to big brother) +15:36 < cat-a-puss> you could put refrences to I2p in wikis talking about related things +15:36 < deer> I think one thing we need is some way to get mail in to i2p and anonymously out of it. +15:36 < jrandom> i think someone has already placed i2p at various spots in wikipedia, though i dont know about iA lately +15:36 * fvw doesn't see why you couldn't run smtp over a tunnel. +15:37 < jrandom> agreed baffled, a solid way to do mail *securely* would be great +15:37 < cervantes> is that possible though +15:37 < fvw> we must be careful not to spam though. +15:37 < jrandom> fvw: do you trust your mail client? +15:37 < jrandom> however, a mixminion/mixmaster outbound gateway would *rule* +15:37 < jrandom> (so someone go set up a web interface to one of those. please :) +15:37 < fvw> jrandom: as much as I trust any other client software... Do you trust your IRC client? your web browser? ... +15:38 < cervantes> you'd have to trust the guy who owns the gateway isn't reading your mail +15:38 < jrandom> fvw: no. +15:38 < jrandom> fvw: and thats a problem. +15:38 < jrandom> fvw: a problem we must fix before we can recommend that people use I2P for anything beyond testing. +15:39 < fvw> How do you suggest making mail clients "more anonymous"? +15:39 < jrandom> it'd need to be a local SMTP/POP3 "server" that reads from the client, parses, interprets, and acts accordingly. +15:39 < cervantes> you'd need a bespoke mail application for a start +15:39 < jrandom> (there are a few apps out there that do that already) +15:39 < cervantes> (client) +15:40 * cervantes apologies for saying "bespoke" +15:40 < cervantes> *apologises +15:40 < jrandom> but that gets to one of the points in the weekly status notes - there are just so many important things that need to get done +15:40 < fvw> jrandom: That'd be very easy, at least on unix. Just hack up a sendmail drop in and something that does fetchmail and you're there. Could be done in shell scripts if you wanted to. +15:40 < deer> me hears an echo of his name +15:40 < jrandom> we need to focus if the bounties are going to be sufficient +15:40 < jrandom> oh, heya duck +15:41 < deer> sorry, I was euh.. drinking' +15:41 < jrandom> duck: just wanted to check in to see if there was any update on that web gateway thingy? and/or whether it might be something normal i2p users could use? +15:41 < jrandom> heh, cheers +15:41 < nicktastic> drunken duck +15:41 < cervantes> pond water? +15:41 < jrandom> fvw: get coding :) +15:42 < deer> nope, the dev did freeze up. will have to find someone else +15:42 < jrandom> ok, sorry to hear that +15:42 < deer> We told you not to keep putting them in the closet to protect them. +15:43 < deer> my initial specs: http://duck.i2p/files/anonyproxy.txt +15:44 < deer> Is getting mail in/out of i2p as easy as some type of interface web/tunnel to one of these mixmaster thingies? +15:44 < jrandom> perhaps we can work on a revamp of the spec for that and see if it could serve the needs of normal eepsites (with i2p general funds pitching in) +15:44 < jrandom> oh ok cool duck, i'll check that out +15:44 < jrandom> baffled: out of i2p? yes. in to i2p? probably more work +15:44 < fvw> baffled: Why do you want to add mixmaster? Everything mixmaster offers we already have. +15:45 < jrandom> fvw: mixmaster has a network of outproxies, plus nontrivial delays +15:45 < jrandom> ah ok duck, spec glanced over. we may be able to figure something +15:45 < deer> I don't, jrandom suggested setting up a web interface to it not me. +15:46 < jrandom> (though it seems to have some heavyweight requirements, so maybe not. unsure, we can see) +15:46 < deer> its very easy; expectation was 1.5h study of ingredients and then 3-4h patching +15:46 < fvw> outproxies would be useful yes. As for nontrivial delays, someone who's not already using i2p isn't going to use i2p just for mail when there's mixmaster, whereas someone already using i2p is going to be compromised elsewhere by our lack of delays (if this is possible) anyway +15:46 < jrandom> right right, plus ship perl, privoxy, and apache duck ;) +15:47 < jrandom> perhaps fvw. (though i2p 3.0 blah blah blah) +15:47 < fvw> hehe, I hesitate to say "good point", but I get what you mean. +15:48 < nicktastic> FYI, JES (Java Email Server) provides SMTP and POP3 servers under the GPL +15:49 < jrandom> ok, perhaps there should be some more discussion on the list or on the forum about what one or two client apps we should explore focusing on +15:49 < jrandom> word nicktastic, there's also a kickass one from apache too +15:49 < nicktastic> Nice, know what its called? +15:49 < jrandom> http://james.apache.org/ +15:49 < nicktastic> Thanks +15:50 < jrandom> (nntp too (drooool)) +15:50 < nicktastic> Wow +15:50 * nicktastic gets a stiffy +15:51 * fvw has joined #i2p-porn. Or at least it feels like that. +15:51 < fvw> Ok, next? +15:51 < jrandom> ok, we can continue client app discussions and strategizing on the list and in the forums +15:51 < nicktastic> Yes +15:52 < jrandom> but for now, moving on to 6) ??? +15:52 < nicktastic> Or during non-meeting hours ;P +15:52 < jrandom> anyone have anything else they want to bring up? +15:52 * fvw nods. It is worth some discussion on-list. +15:52 < deer> little explanation to the www-inproxy: the idea was to get some ISP(s) to offer such a gateway as a service +15:52 < fvw> nah, the list is good. Gives everyone a chance to chime in, not just those who happen to be awake. +15:52 < jrandom> word duck, which is quite cool +15:52 < deer> so joe i2p-less-sixpack can access it using his MSIE +15:52 < deer> but the host is anonymous +15:52 < deer> http://it.slashdot.org/article.pl?sid=04/09/14/2226226&threshold=0&tid=172&tid=128&tid=201&tid=218 (ugly new exploit for windows xp) +15:52 < jrandom> i2pless! heretic! burn them! +15:53 < deer> ISP takes part of the risk, hence the whitelist requirement +15:53 < deer> and ofcourse payment for domain etz +15:53 < fvw> hehe. Then suddenly we plaster child porn all over the famous eepsites and watch half the people get arrested and the other half install i2p. +15:53 < jrandom> heh +15:53 < deer> * duck calls the AIVD +15:54 < fvw> duck is dutch? *ponders* +15:55 < deer> I think many clientapps are not really killer +15:55 < jrandom> ok, anyone else have anything they want to bring up? +15:55 < jrandom> agreed duck, but we need *something* +15:55 < deer> some self-made smtp tunnel thing is not going to be a big thing +15:56 < deer> myi2p with IOU accounting +15:56 < deer> fvw: Bedankt foor die bloumen +15:57 < deer> "After complaints to NIC.CX (the regulation authority of .cx domains) by an office worker named Rhonda Clarke of Christmas Island, the site goatse.cx was taken down Friday, January 16, 2004. (Goat.cx and Hick.org/Goat remain active.) A petition has even been launched to bring goatse.cx back. " +15:57 < deer> i've lost faith in humanity +15:57 < deer> small thing about the site: I2P was added to the of each page for google purposes +15:57 < deer> <soros> sorry wrong window +15:57 < jrandom> ah ok duck +15:57 < deer> <duck> but I dont keep up with the latest google-dance, so it might be worthless. +15:57 < jrandom> perhaps if there were a way to explicitly not include it? +15:58 < jrandom> (e.g. so we can say "Welcome to I2P.net" instead of "I2P - Welcome to I2P.net", etc) +15:58 < deer> <duck> that is ofcourse possible +15:58 < deer> * duck looks on the fun-o-meter +15:58 < jrandom> we can always just add title = "I2P - How does it work" to menu.ini +15:58 < deer> <duck> nope, not today +15:58 < deer> <thetower> Oh oh, isn't there some way we can get google to crawl i2p? Like some sort of reverse proxy or something? +15:58 < jrandom> yeah, not worth it +15:58 < jrandom> thetower with duck's thingamabob, probably. +15:59 < deer> <duck> yeah +15:59 < fvw> but as mentioned, you probably don't want to be the one running it. +15:59 < deer> <thetower> Seems like if eepsites were coming up in google searches that would be good advertising right there. +16:00 < deer> <duck> fvw: I have contacted an isp who is interested +16:00 < deer> <duck> but he is not going to build it +16:00 < jrandom> thetower: perhaps if an ht://dig were hooked up to files.i2p, and if files.i2p exposed the database as big file with html links, that could be mirrored..? +16:00 < fvw> duck: really? How large and in which country? +16:00 < cervantes> how about a cache instead of a proxy +16:00 < cervantes> ah +16:00 < deer> <duck> 20cm +16:00 < fvw> If I were an ISP and not afraid of the legal problems, I'd still not be interested until I2P was a lot bigger. +16:01 < jrandom> a cache would be interesting too, a swarm of squids, etc +16:01 < deer> <duck> skynet +16:01 < fvw> that's pretty big. Did you give them a phone book to sit on? +16:01 < nicktastic> hehe +16:01 < deer> <duck> fvw: they'll likely scan the site before adding it +16:01 < deer> <duck> so you'll have to find another place for your nasty stuff +16:01 < fvw> Once or every update? +16:02 < fvw> the latter seems a lot of work for very little content. +16:02 < deer> <duck> every 2nd sunday of a month with an x in it +16:02 < deer> <duck> geeh +16:03 < jrandom> ok, we've gone past the two hour mark, does anyone else have something to bring up, or should we continue further discussions on the list / in the forum / etc? +16:03 < fvw> I just find it highly unlikely that a serious ISP will commit resources to I2P at this point. +16:03 * cervantes covers his head with a saucepan +16:03 < deer> <duck> fvw: your emotions are noted. +16:03 * fvw nods at jrandom. I need a drink. Keep up the good work. +16:03 < deer> <duck> when will we go for the 24h meeting? +16:04 < jrandom> perhaps next week duck +16:04 * jrandom winds up +16:04 < deer> <duck> oh boy! +16:04 < fvw> duck: my emotions? You haven't even begun to see my emotions. Let me get a few drinks though.. *grin* +16:04 * jrandom *baf*s cervantes on the head, closing the meeting diff --git a/i2p2www/meetings/logs/107.rst b/i2p2www/meetings/logs/107.rst new file mode 100644 index 00000000..19168ac0 --- /dev/null +++ b/i2p2www/meetings/logs/107.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 14, 2004 +=================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/108.log b/i2p2www/meetings/logs/108.log new file mode 100644 index 00000000..506eb87a --- /dev/null +++ b/i2p2www/meetings/logs/108.log @@ -0,0 +1,34 @@ +14:06 < jrandom> 0) hi +14:06 < jrandom> 1) Dev status +14:06 < jrandom> 2) New userhosts.txt vs. hosts.txt +14:06 < jrandom> 3) ??? +14:06 < jrandom> 0) hi +14:06 * jrandom waves +14:06 < jrandom> brief weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-September/000449.html +14:06 < jrandom> (and probably brief meeting logs to be posted once this is over ;) +14:07 * jrandom gives y'all a good 30s to read those notes +14:07 < jrandom> anyway, moving on to 1) dev status +14:07 < jrandom> basic overview of whats up is in that email +14:08 < jrandom> one thing you may notice is that i won't be missing random letters in my text anymore, as my laptop has been a bitch lately +14:09 < jrandom> so i'm in the process of moving entirely over to my server (w/ the laptop as backup for windows testing, etc) +14:09 < jrandom> thats all i've got to say on that front +14:10 < jrandom> anyone have anything they want to bring up wrt 0.4.0.1 or the dev activity? +14:11 < deer> <jrandom> no jrandom, we're just lurking +14:11 < jrandom> ok, moving on to 2) new userhosts.txt vs. hosts.txt +14:11 < protok0l> yey! +14:11 < jrandom> minor new feature so people can modify their local naming while still pulling down hosts.txt +14:12 < protok0l> which file has priority if they conflict? user i would assume +14:13 < jrandom> it'll be rolled out in the next release, so basically just put your local changes in userhosts.txt as hosts.txt will be overridden +14:13 < jrandom> userhosts.txt has first preference +14:15 < jrandom> ok, thats all i've got for 2, so moving on quickly to our last point- 3) ??? +14:15 < jrandom> anyone have anything else they want to discuss? +14:16 < deer> <Pseudonym> timetable for 0.4.1? +14:17 < jrandom> should be out this week, but maybe not until the weekend. +14:17 < deer> <Pseudonym> cool +14:17 < jrandom> i finally gave up the battle with my laptop after the spacebar died +14:17 < jrandom> (codingWithoutSpaces==lame;) +14:18 < jrandom> ok, anyone else have anything they want to bring up? i think we're going for a record meeting time here +14:18 < jrandom> (not that thats a problem) +14:19 < jrandom> ok, if not +14:19 * jrandom winds up +14:19 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/108.rst b/i2p2www/meetings/logs/108.rst new file mode 100644 index 00000000..1a234b95 --- /dev/null +++ b/i2p2www/meetings/logs/108.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 21, 2004 +=================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/109.log b/i2p2www/meetings/logs/109.log new file mode 100644 index 00000000..8333232e --- /dev/null +++ b/i2p2www/meetings/logs/109.log @@ -0,0 +1,113 @@ +14:08 < jrandom> 0) hi +14:08 < jrandom> 1) New transport +14:08 < jrandom> 2) 0.4.1 status +14:08 < jrandom> 3) ??? +14:08 < jrandom> 0) hi +14:08 < duck> hi +14:09 < jrandom> heya +14:09 < deer> <ugha2p> Hi. +14:09 < deer> <pseudonym> hi +14:09 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-September/000454.html +14:09 < deer> * ugha2p is looking for the weekly status notes. +14:09 < jrandom> (hey, i'm psychic) +14:10 < jrandom> ok, jumping in to 1) New transport +14:10 < jrandom> the message pretty much covers the main bits +14:11 < jrandom> its all working atm, but obviously wont talk to anyone else until the new release is out +14:12 < jrandom> i've kicked the tires on it a bit, but its pretty hard to simulate all the possible kooky network problems that occur at the transport level +14:12 < deer> <pseudonym> does it include windowsize? +14:12 < deer> <ugha2p> 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). +14:12 < deer> <ugha2p> Sounds like a potential security hole. +14:12 < jrandom> oh, no, this is just the inter-router transport, not the streaming lib, unfortunately +14:12 < deer> <pseudonym> ok +14:12 < jrandom> in a way ugha, yes +14:12 < jrandom> (which is why if people *can* set their IP, they should) +14:13 < jrandom> ugha: however, it only 'believes' someone if they have NO connections that work +14:13 < deer> <ugha2p> Shouldn't the router listen on 0.0.0.0 in any case? +14:13 < jrandom> but someone pretty smart could probabalistically do some evil things +14:14 < jrandom> ugha: it does that (almost always) +14:14 < jrandom> however, we need to know our IP address so we can put it in our RouterInfo +14:14 < jrandom> (since our RouterInfo is verified whenever we contact someone) +14:14 < deer> <ugha2p> Ah, ok. +14:15 < deer> <ugha2p> I'm sure there are ways to make this more secure (rely on more routers for detecting the IP), but I'm not sure if this is feasible. +14:15 < jrandom> yeah ugha, there's trouble down that path, but its a numbers game +14:16 < deer> <ugha2p> Anyhow, that was just a suggestion. We can move on. +14:16 < jrandom> (however, they could just sybil you and mess up whatever #s you're trying) +14:16 < deer> <ugha2p> Right. +14:17 < deer> <ugha2p> What if the router loses all connections (eg, network failure)? +14:17 < deer> <ugha2p> Does it redetect its IP? +14:18 < jrandom> the IP is transmitted as part of the protocol on all connection attempts, the peer just decides to honor it if 1) no ip was explicitly set 2) there are no active TCP connections +14:18 < deer> <ugha2p> (This would be the case with dynamic IPs) +14:18 < jrandom> right, it'll work fine with that +14:18 < deer> <ugha2p> Ah, ok. +14:19 < jrandom> (see ourAddressReceived(String addr) in TCPTransport.java for the details) +14:19 < deer> <pseudonym> what happens when reported IPs don't match? +14:19 < jrandom> pseudonym: if you already have active TCP connections, you ignore what other people tell you +14:20 < jrandom> if you dont have active TCP connections, you tear down the old listener and start up a new one with the new address given +14:20 < jrandom> (updating your routerInfo) +14:22 < deer> <pseudonym> if there are active conns, it seems like a mismatch should be a red flag +14:22 < deer> <pseudonym> (I'm not sure what to do with it) +14:22 < jrandom> if someone gives us the wrong IP address (and we *know* its the wrong IP address, since we already have the right one - that *works*) we ignore it +14:23 < deer> <ugha2p> Too bad we can no longer reduce the router's reliability ranking. +14:23 < jrandom> we can add that to the list of connection errors though +14:24 < jrandom> ugha: but we can shitlist 'em ;) +14:24 < jrandom> (and we do) +14:24 < deer> <pseudonym> how do we know the one we already have is "right"? maybe the existing conns are from black hats +14:24 < deer> <pseudonym> especially if we have few or only recent conns +14:24 < jrandom> pseudonym: the existing connections are "right" in that they can send and receive data +14:24 < deer> <ugha2p> pseudonym: We can be sure when we get new inbound connections, although those can be spoofed as well. +14:25 < jrandom> right, if we're talking about someone concerned with an active IP spoofing attack in addition to sybil... +14:25 < jrandom> well, that person can simply set their IP address ;) +14:25 < deer> <ugha2p> :) +14:26 < deer> <pseudonym> but what's the likelyhood that the operator will even know what's happening +14:26 < deer> <pseudonym> if we get a lot of mismatches there should be some active alert +14:27 < deer> <pseudonym> (this may be something to worry about in a later release, but since it came up...) +14:27 < jrandom> we can add an explicit message to the list of connection errors +14:27 < jrandom> the only real concern here is that we're trying to prevent a restricted route from being formed +14:27 < jrandom> (and the extreme of that being a full network partition) +14:30 < jrandom> thats about all i can see us working to deal with for now, at least until the 2.0 rev when we need to worry beyond the restricted route +14:30 < jrandom> ok, anyone else have anything wrt the new transport? +14:31 < jrandom> if not, moving on to 2) 0.4.1 status +14:31 < jrandom> all the "necessary" stuff is done, but theres still some debugging and minor updates to get in +14:32 < jrandom> current target is a thursday release, but we'll see what gets added or removed from the rev ;) +14:33 < jrandom> one thing that would be cool is if someone could download a jetty install, check out the jetty.xml config file, and could write up some docs on how to run a jetty instance (for an eepsite/etc) with what is shipped with i2p +14:33 < deer> <ugha2p> Does 0.4.1 include other updates than the new TCP transport? +14:33 < jrandom> not really ugha :) +14:34 < deer> <pseudonym> is it backward compatible? +14:34 < jrandom> (see: www.i2p.net/roadmap ) +14:34 < jrandom> no, it is not backwards compatible +14:34 < deer> <ugha2p> :) +14:36 < jrandom> ok, thats all ive got to mention wrt 0.4.1.. anything else on that? +14:36 < jrandom> if not, we're on to ol' faithful: 3) ??? +14:36 < deer> <ugha2p> *silence* +14:37 < jrandom> anyone have anything else (i2p related) they want to bring up? +14:37 < jrandom> we're already twice as long as last week's meeting ;) +14:37 < deer> <ugha2p> Well, I could mention that thanks to cervantes, my Wiki now has an outproxy to the real world, through http://ugha.ath.cx/ +14:38 < deer> * pseudonym is a troublemaker +14:38 < jrandom> ooh right, v.cool +14:38 < jrandom> s/outproxy/inproxy/ :) +14:38 * jrandom sends the troublemaker to the corner +14:38 < deer> <ugha2p> Right, inproxy. :) +14:40 < jrandom> ok, if there's nothing else +14:40 < deer> <pseudonym> I think the new mail service from the postmaster is pretty cool +14:40 < jrandom> oh, definitely agreed +14:40 < deer> <pseudonym> er, postman +14:41 < deer> * ugha2p has yet to sign up. +14:41 < deer> <baffled> has anyone heard anything of stasher recently? +14:41 < jrandom> its nice that it works with both telnet and kmail:) +14:41 < jrandom> naw baffled, havent heard a peep +14:42 < deer> <baffled> I guess aum needs a boot to the head. +14:42 < deer> <ugha2p> I would probably write a page about EepMailAnonymity, but I don't know too much about SMTP/POP3/IMAP/other e-mail-related stuff. +14:42 < jrandom> not the head, the butt ;) +14:43 < jrandom> ugha: www.postman.i2p has a few pages about that +14:43 < deer> <ugha2p> Ah. +14:43 < deer> <baffled> they may be the same. +14:45 < deer> * ugha2p taps his fingers waiting for the baf. +14:45 < jrandom> sorry, nearly passed out here (loong day) +14:46 < jrandom> anything else? if not, we've got the forum and the list +14:46 < duck> thanks to Mi-Go we have an updated i2ptunnel page +14:46 < duck> it is almost perfect +14:46 < jrandom> ooh nice +14:46 < duck> but if someone has some improvements, you know where to find me +14:47 * jrandom traceroutes +14:47 * jrandom winds up +14:47 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/109.rst b/i2p2www/meetings/logs/109.rst new file mode 100644 index 00000000..436b8f35 --- /dev/null +++ b/i2p2www/meetings/logs/109.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 28, 2004 +=================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/11.log b/i2p2www/meetings/logs/11.log new file mode 100644 index 00000000..431a1946 --- /dev/null +++ b/i2p2www/meetings/logs/11.log @@ -0,0 +1,152 @@ +--- Log opened Tue Sep 17 22:59:26 2002 +23:01 -!- mode/#iip-dev [+v logger] by mids +23:54 * Roto waves +23:54 <@mids> ssh, we arent started :) +23:55 < Lorax> Heh, I am already logged. +23:56 * Lorax waves to any SRHers. +23:59 < Lorax> anyway, if IIP could pass psudonymous keys then SSL can be used, as it's the connection that is secure, not the conversation. (Unless you have previously established socially satisfactory identification exchange.) +--- Day changed Wed Sep 18 2002 +00:00 <@mids> hush +00:01 <@mids> we start in 1 hour +00:01 < Lorax> but we are here now. +00:01 <@mids> but the others aint +00:01 <@mids> its not fair to start :) +00:01 -!- mode/#iip-dev [+m] by mids +00:02 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: not started +00:03 <@Chocolate> starting in about 1 hour +00:04 -!- mode/#iip-dev [-m] by Chocolate +00:23 < Lorax> Why are the logs recording to a website already then? hrm? ;) +00:23 <+logger> we are testing the live nsa wiretap +00:24 < Lorax> ah, that is senseable. +00:51 < nop> hi +00:51 < Roto> hulloz +00:53 < thecrypto> hello +00:53 < nop> http://www.techtv.com/screensavers/supergeek/story/0,24330,3347481,00.html +00:53 < nop> friend of mine +00:54 -!- mode/#iip-dev [+o codeshark] by Trent +00:54 < nop> just got back from a deposition +01:00 <@mids> Tue Sep 17 23:00:09 UTC 2002 +01:00 <@mids> Welcome everybody +01:00 <@mids> this is the 11th IIP meeting +01:00 <@mids> maybe more, but then I lost count +01:00 <@mids> :) +01:00 <@mids> Agenda for now: +01:00 <@mids> rc2 status update +01:00 <@mids> website +01:00 <@mids> open mic +01:01 <@mids> . +01:01 < Roto> . +01:01 <@mids> nop is on the phone, but he might drop in +01:01 <@mids> like you all know, rc2 has been 'almost there' for a long time +01:01 <@mids> but it didnt work +01:01 <@mids> now it does better :) +01:01 <@mids> userx fixed some bugs with the end-end crypto +01:02 <@mids> and with the 1.1 protocol +01:02 <@mids> I tested it this weekend, and it works great +01:02 <@mids> you can even do 2048 bit encryption etc +01:02 <@mids> so, one step closer to the release +01:02 <@mids> (heh we did say that often) +01:02 <@mids> . +01:03 < codeshark2> what is needed for the release? except the inform stuff? +01:03 -!- codeshark is now known as nickthief53256 +01:03 -!- codeshark2 is now known as codeshark +01:03 <@mids> only some minor things: fixup of the commandline help +01:03 <@mids> manpage check +01:04 <@mids> cant think about more +01:04 -!- mode/#iip-dev [+o codeshark] by Trent +01:04 <@codeshark> so, the source is ready +01:04 <@mids> I'd say so +01:05 <@codeshark> ok, i think we should create a build for internal testing then +01:05 <@codeshark> . +01:05 <@mids> ack (pending nops status) +01:05 <@codeshark> and set up inform for the new protocol +01:06 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: RC2 +01:06 <@mids> more rc2? +01:06 <@codeshark> another thing we should discuss is: version numbers +01:06 <@codeshark> why call it rc2 ;) +01:06 <@codeshark> . +01:06 <@mids> release candidate +01:07 <@codeshark> yeah sure, but we changed a lot of stuff between rc1 and rc3 +01:07 <@codeshark> rc2 +01:07 <@mids> yes we did +01:07 <@mids> it aint proper naming this way +01:07 <@mids> based on the changes we should be at 1.3 now +01:08 <@codeshark> yes +01:08 <@codeshark> we could call it 1.3 RC-2 (and then make a final 1.3 soon) +01:08 <@mids> nah +01:09 <@mids> I'd say continue with the numbering like we do now +01:09 <@mids> and in the future, release more often +01:10 <@codeshark> ack +01:10 <@mids> . +01:10 <@codeshark> . +01:10 <@mids> next thing: website +01:10 <@mids> nop reviewed most text, some stuff is reworded +01:11 <@mids> ellison (the designer) is now making a layout for the support page +01:11 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: website +01:11 <@mids> should be there in a week +01:12 <@mids> the latest version of the site is on http://mids.student.utwente.nl/~mids/iip/www/ +01:12 <@mids> and in CVS ofcourse +01:12 <@mids> . +01:12 <@mids> site should be up soon too +01:12 <@mids> . +01:13 * mids hands the mic over to codeshark +01:13 <@codeshark> nothing to add ;) +01:13 <@codeshark> . +01:13 <@mids> yes you do +01:13 <@codeshark> i do? +01:13 <@mids> tell em about your work with the public nodes +01:13 <@codeshark> about the website? +01:13 <@codeshark> ok +01:13 <@mids> how you rescued 2000 +01:13 <@codeshark> 23 +01:14 <@codeshark> our inform server does very strict checking on the relay nodes: our list has been reduced to about 6 nodes +01:15 <@codeshark> i disabled one of these checks to allow nodes to be down more often +01:15 <@codeshark> and most important: +01:15 <@codeshark> i rescued all nodes ever added to inform and checked if they're still up +01:16 <@codeshark> now, we have 23 nodes in our list +01:16 <@codeshark> . +01:16 < _42> how are nodes added to inform? +01:16 < nop> awesom +01:16 < nop> when you announce +01:16 < nop> it sends a message to inform +01:17 <@codeshark> just for the statist guys here: i added 1125 hosts from the log +01:17 < nop> you know that's a lot of downloads ;) +01:18 <@codeshark> about 300 of them were valid (dns resolves...) and unique hosts +01:18 <@codeshark> . +01:18 <@mids> currently we have 9 nodes on the list... in about 5 days (after the inform testing) that will be 23 (if they keep up) +01:18 <@mids> . +01:19 <@codeshark> right now 22/23 are up +01:19 <@codeshark> . +01:19 -!- mids changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: hurray for the saviour of the public nodes +01:20 < Roto> . +01:20 <@mids> okay, I am out of agenda items +01:20 < nop> rc2 +01:20 <@mids> maybe nop has something to add +01:20 < nop> rc2 will be released with website release +01:20 < nop> we will be spending this week thoroughly testing it from a developer's standpoint +01:20 <@codeshark> nop: we should create an internal build of rc2 asap +01:21 < nop> agreed +01:21 < _42> What new features will be added to rc2? +01:21 <@codeshark> so we can set up the network and test inform +01:21 < nop> Perfect Forward Security +01:21 < nop> 160 bit encryption end to end +01:21 < nop> 1536 bit network id +01:21 < nop> 2048 bit PFS keys +01:21 <@codeshark> . +01:21 < nop> and all around just general bug fixes +01:21 < nop> I will get a changelog +01:22 < nop> . +01:23 <@mids> I guess its open microphone time +01:24 <@mids> you can reread the chatlogs of this and the previous meetings on http://mids.student.utwente.nl/~mids/iip/ +01:24 <@mids> questions? (I know that Lorax had some... :) +01:25 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: open mic +01:25 <@Chocolate> Lorax timed out +01:25 <@mids> I know :) +01:26 * Roto cheerleads +01:26 <@Chocolate> I'd like to raise the issue of saner version numbers +01:27 <@Chocolate> the feature changes from rc1 to rc2 where realy a minor version increment, not updates to a beta release +01:30 <@mids> the updates got out of hand +01:30 <@mids> for the common good.. but that is no excuse :) +01:37 <+logger> official part is over, if you got more questions; ask here or in #iip +01:37 <+logger> cya next week +--- Log closed Wed Sep 18 01:37:46 2002 diff --git a/i2p2www/meetings/logs/11.rst b/i2p2www/meetings/logs/11.rst new file mode 100644 index 00000000..239ed484 --- /dev/null +++ b/i2p2www/meetings/logs/11.rst @@ -0,0 +1,9 @@ +I2P dev meeting, September 18, 2002 +=================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/110.log b/i2p2www/meetings/logs/110.log new file mode 100644 index 00000000..39e99f72 --- /dev/null +++ b/i2p2www/meetings/logs/110.log @@ -0,0 +1,180 @@ +14:05 < jrandom> 0) hi +14:05 < jrandom> 1) 0.4.1.1 status +14:05 < jrandom> 2) Pretty pictures +14:05 < jrandom> 3) 0.4.1.2 and 0.4.2 +14:05 < jrandom> 4) Bundled eepserver +14:05 < jrandom> 5) ??? +14:05 < jrandom> 0) hi +14:05 * jrandom waves +14:05 < jrandom> weekly status notes are available at http://dev.i2p.net/pipermail/i2p/2004-October/000461.html +14:06 < jrandom> (i cant believe its october) +14:06 < cervantes> it's december +14:06 * jrandom disconnects from cervantes. excess clock skew +14:06 < deer> <baffled> could we have summer back now? +14:07 < cervantes> damn...lost your pr0n feed +14:07 < jrandom> sure. its a few thousand KM south of you baffled +14:07 < jrandom> ok, jumping into 1) 0.4.1.1 status +14:07 < deer> <baffled> will you let me know when I get there? +14:07 < cervantes> heh +14:07 < jrandom> click your heels three times... +14:08 < jrandom> ok, the 0.4.1 and 0.4.1.1 revs are out, and things are pretty much working again +14:08 < deer> <baffled> no, no, I don't want to go home it's cold there. +14:08 < jrandom> ;) +14:08 < jrandom> the autodetection of the external IP address seems to be working for the most part +14:09 < jrandom> (there have been a few quirks though, due to b0rked connections that don't hang up properly) +14:09 < jrandom> have people been using that, or had good/bad experiences with the autodetection? +14:10 < jrandom> guess not +14:10 < jrandom> ok, anyone have any comments/questions/concerns wrt 0.4.1.1? +14:11 < cervantes> no complaints here.... +14:11 < dm> Haven't tried it yet, but it's on my agenda! +14:11 < jrandom> if not, swingin on to 2) pretty pictures +14:11 < jrandom> !thwap dm +14:12 < deer> <Jake> dunno about autodetection, but i tried using the 'guess' button or whatever on my natted windows box and it guessed the ip right...... if thats what wer're talking bout +14:12 < jrandom> ah ok, naw, the 'guess' button just tries to guess your IP by querying www.whatismyip.com +14:13 < jrandom> the autodetection is where you leave the IP address field blank and it figures it out by itself +14:13 < jrandom> most existing I2P users won't need it, since we're all used to either dyndns or static IPs anyway +14:13 < jrandom> it'll probably only matter for new users +14:14 < deer> <demonic_1> yea that worked a little slow for me +14:14 < deer> <demonic_1> but it did work +14:15 < jrandom> ok cool +14:15 < jrandom> anyway, i dont want to rehash what i posed in this weeks email wrt the stats gathered +14:16 < jrandom> instead, does anyone have any questions/comments/concerns about them? +14:17 < jrandom> i was pretty glad to see the 20h summary had only 500-something send failures out of 30,000-ish +14:17 < cervantes> how much load does the stats collecting generate? +14:17 < cervantes> I know the filesizes...but will it impact on performance having it ticking in the background +14:18 < jrandom> should be ~= 0. there's no memory allocation in the stat gathering (as we use preallocated events) and everything is async +14:18 < cervantes> cool +14:18 -!- Sugadude [random@badfish.securityminded.net] has joined #i2p +14:18 -!- cat-a-puss [~tom@152.228.242.159] has joined #i2p +14:19 < jrandom> once 0.4.1.2 is outi'll probably nag some more people to gather various stats at times +14:19 < deer> <mule_iip> you're welcome +14:19 < cervantes> I'm happy to start collecting now... I'm already on 0.4.1.1-6 +14:20 < jrandom> w3wt +14:21 < jrandom> ok, thats all i've got for the stats, unless anyone has anything to add? +14:21 < jrandom> if not, 3) 0.4.1.2 and 0.4.2 +14:21 < deer> <baffled> You have my vote for streaming first. +14:22 < jrandom> cool +14:22 < jrandom> does anyone think we should keep the tunnel mods first? +14:22 < deer> <mule_iip> streaming first +14:23 < cervantes> doing the tunnel stuff now would likely cause more network distruption....it's probably good to have a breather ;-) +14:23 < jrandom> true +14:23 < deer> <mule_iip> all of those here today have been identified by the black hats anyhow :) +14:23 < jrandom> though i was thinking the other day about how we could do the tunnel mods without incompatabilities +14:23 < deer> <baffled> Comeon admit it, you just want to get your audio p0rn faster. +14:23 < duck> (me too on streaming first) +14:23 < jrandom> hehe +14:24 < cervantes> hehe +14:24 < cervantes> baffled: only if you source more of it ;-) +14:24 < dm> I think we should stick to the tunnel stuff first +14:24 < dm> get it out of the way... +14:24 < cat-a-puss> how is the new encryption stuff going to be different? +14:24 * jrandom kicks dm +14:25 < jrandom> cat-a-puss: right now, we have blanket tunnel encryption - messages passed within the same tunnel look the same at each hop +14:25 < deer> <baffled> I think I can get a bit more. +14:25 < cat-a-puss> oh! +14:26 < cervantes> http://www.i2p.net/todo#tunnelId +14:26 < jrandom> it isn't so bad since an alice-->bob message goes through two tunnels with different encryption, but it does b0rk us for colluding attackers +14:27 < jrandom> the per-hop tunnelId stuff is also necessary to keep harvesting from messing with predecessors (/etc) +14:27 < dm> Yeah, we should definitely fix that first. +14:27 < deer> <mule_iip> i vote for dm to do it +14:28 < deer> <fidd> did i miss the meeting? ;) +14:28 < jrandom> i was just about to suggest that mule :) +14:28 < cervantes> I vote for dm not to have anything to do with it +14:28 < jrandom> heh +14:28 < jrandom> nope fidd, we're on item 3 of the agenda +14:29 < jrandom> ok, if there are no objections to dm's suggestion (other than his own), i think we'll go ahead and move the streaming lib updates to 0.4.2 +14:29 < dm> sweet +14:30 < jrandom> ok, moving on to 4) Bundled eepserver +14:30 < jrandom> if you haven't noticed, there's a bundled eepserver. +14:30 < cervantes> "just put the war files in the webapps directory and you're ready to go" +14:30 < jrandom> heh +14:30 < jrandom> for sufficiently well coded .war files :) +14:31 < cervantes> ooh does such a think exist? +14:31 < cervantes> *thing +14:31 < jrandom> but from a practical perspective, "just edit ./eepsite/docroot/index.html" +14:31 < deer> <baffled> One question I have is are you wishing people would use the eepserver or use a standard httpd server? +14:31 < cat-a-puss> do the ones generated by kde work? +14:31 < jrandom> cervantes: phttprelay.war, i2ptunnel.war, routerconsole.war :) +14:31 < dm> ah yes.. war. One of those J2EE things that requires 20 years experience at manually editing xml files. +14:31 < cervantes> touche +14:32 < jrandom> baffled: i really don't care. if people have a webserver installed that can accept requests from kooky Host: lines, great +14:32 < jrandom> the eepserver is just for convenience +14:32 < jrandom> cat-a-puss: hmm, kde .war files? +14:32 < protok0l> monoculture... monoculture... +14:33 < deer> <duck> when playing with wars, I miss the feature to only restart jetty; which is unfortunately needed for a lot of deployment stuff +14:33 < cat-a-puss> yeah, you need kdeaddons installed, just go to a webpage and then click archive and it makes a .war file +14:34 < jrandom> duck: ah, thats true. simply pull out the lines starting the eepserver from clients.config and put them into a shell script +14:34 < jrandom> (with the same classpath as the router) +14:34 < dm> can we integrate i2p into jboss and bundle that before 1.0? +14:34 < jrandom> ooh, cool cat-a-puss +14:35 < cervantes> I take it the missing webdefault.xml has been fixed in cvs? +14:35 < deer> <detonate> actually, jetty.xml has +14:35 < jrandom> find us a compelling .ear dm :) +14:35 < jrandom> cervantes: what detonate said. (i messed up the jetty.xml) +14:36 < cervantes> yup... think I mentioned somewhere about removing the reference in the jetty.xml so it uses it the one inside the jetty archive +14:36 < jrandom> wr0d +14:37 < cervantes> just wanted to check that's been fixed in cvs ;-) +14:37 < jrandom> si sr +14:37 < cervantes> cool +14:37 < jrandom> (though the 0.4.1.2 release update will not overwrite people's eepsite) +14:37 < jrandom> ((0.4.1.2+ clean installs will of course include it though)) +14:38 < cervantes> oh and did we discover the cause of DrWoo's missing eepsite keys? +14:38 < jrandom> actually, on that note, i just want to mention that everyone should upgrade whenever there is a new release, as if you don't, you might not have an upgrade procedure +14:38 < jrandom> no cervantes, nor a reproducable bug :/ +14:39 < cervantes> ah good we can blame user error ;-) +14:39 < deer> <DrWoo> cervantes: almost certainly something klutzy I did +14:39 < cervantes> :o) +14:39 * jrandom blames the gremlins +14:40 < deer> <Jake> http://en.wikipedia.org/wiki/User:Kmweber/List_of_Everyone_Who_Has_Ever_Lived +14:40 < jrandom> ok, moving on to 5) ??? +14:40 < jrandom> heh +14:40 < jrandom> well, yes, that certainly qualifies as "other" +14:40 < jrandom> anyone have anything they want to bring up? +14:41 < dm> I'd like to put forward, at this point, that I am pleased with the new outlook the I2P community is showing towards my suggestions. +14:41 < dm> Kind Regards +14:41 < cat-a-puss> oh oh pick me! I have the base code for a distrubuted search. +14:41 < deer> <demonic_1> yea why do i2p after running 30 + hours go up to 100% cpu +14:41 < dm> dm +14:41 < deer> <Jake> yes, i want to bring up the issue of encryption inheritence based on 4th order gamal fractal equations and how it would apply to i2p +14:41 < deer> <demonic_1> and most of it system? +14:41 < jrandom> ooh kickass cat-a-puss! +14:41 < cat-a-puss> I anounced it here the other day, nobody noticed +14:41 < deer> <baffled> only tangentially jake. +14:42 < cat-a-puss> anyway, could use come cvs space +14:42 < deer> <DrWoo> cat-a-puss: do you have an eepsite for that? +14:42 < jrandom> demonic_1: hmm, there have been some critical bugs in the last release or two. are you on 0.4.1.1? +14:42 < cat-a-puss> and I can start testing in about 2 weeks +14:42 < cat-a-puss> DrWoo: nope +14:42 < deer> <Jake> baffled, HaH ! +14:43 < deer> <demonic_1> 0.4.1.1-3 +14:43 < jrandom> cat-a-puss: r0x0r, not a problem. bounce me an email with the name of the module you'd like it called & your pgp key and we'll get something sorted +14:44 < cat-a-puss> jrandom: alright +14:44 < jrandom> cat-a-puss: what sort of searching does it do? +14:44 < jrandom> demonic_1: did it consume that much CPU prior to 0.4.1? +14:44 < cervantes> (proxies to MSN) +14:44 < deer> <mule_iip> demonic_1: and you get 1 meg of log every minute? sounds familiar. +14:45 < deer> <demonic_1> no +14:45 < jrandom> heh mule, yeah the bug you found was a nasty fast-busy +14:45 < cat-a-puss> jrandom: it's basic keywork search, you need to specify the words to index under, and it will store the URL +14:45 < jrandom> demonic is more likely being hit by one of the NPEs in the tcp.ConnectionBuilder +14:46 < deer> <baffled> Well, it's dindin time so I'll go hunt up some more slut sounds in preparation for the streaming updates and chat with you all anon. +14:46 < cat-a-puss> jrandom: It should eventualy scale well, and all that jazz, but right now, all the servers need to be connected and nobody can join or leave, and there is no way to insert content yet, but all that will get fixed +14:46 < jrandom> ah cool, does it work with a distributed db, or is it more of a search-against-spidered? +14:47 < jrandom> ok cool +14:47 < cervantes> later baffled +14:47 < jrandom> lol, ttyl baffled +14:47 < cervantes> baffled: how do we know they're slut sounds, and not you on the end of your microphone? +14:47 < protok0l> ALL RIGHT! +14:47 < protok0l> i2p works again +14:47 < jrandom> w3wt +14:48 < jrandom> what was wrong? +14:49 < jrandom> ok, anyone else have anything they want to bring up for the meeting? +14:49 < deer> <Jake> can announce i2p to slashdot after the new streaming protocol is implemented ? +14:49 < dm> preferably before +14:49 < dm> but after will do +14:49 < jrandom> !thwap^2 +14:50 < protok0l> POSTMAN! +14:50 < jrandom> ok, if there's nothing else.. +14:50 * jrandom winds up +14:51 < deer> * Jake kisses jrandom +14:51 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/110.rst b/i2p2www/meetings/logs/110.rst new file mode 100644 index 00000000..7145dbb4 --- /dev/null +++ b/i2p2www/meetings/logs/110.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 5, 2004 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/111.log b/i2p2www/meetings/logs/111.log new file mode 100644 index 00000000..04dcb2c9 --- /dev/null +++ b/i2p2www/meetings/logs/111.log @@ -0,0 +1,195 @@ +14:04 < jrandom> 0) hi +14:04 < jrandom> 1) 0.4.1.2 +14:04 < jrandom> 2) 0.4.1.3 +14:05 < jrandom> 3) 0.4.2 +14:05 < jrandom> 4) mail discussions +14:05 < jrandom> 5) ??? +14:05 < jrandom> 0) hi +14:05 * jrandom waves +14:05 < Janonymous> hello +14:05 < jrandom> lots of #s in our agenda this week +14:05 < jrandom> weekly status notes up @ http://i2p.net/pipermail/i2p/2004-October/000466.html +14:05 < jrandom> (posted a min or three ago) +14:05 < deer> * cervantes has brought a pillow +14:06 < jrandom> oh i hope it won't be that boring ;) +14:06 < jrandom> anyway, jumping on in to the good stuff: 1) 0.4.1.2 +14:06 < deer> <cervantes> make me up after the statistal analysis section +14:06 < jrandom> the release is out and everyone should upgrade +14:06 < jrandom> heh +14:06 < deer> <cervantes> eerm wake +14:07 < jrandom> there are some bugs with the watchdog code, which will kill your router poorly (rather than restart it when bad stuff happens) +14:07 < jrandom> but hopefully those situations are few and far between +14:07 < deer> <mule_iip> nope :( +14:08 < jrandom> well, it varies by the user +14:08 < jrandom> i'm trying to find the cause, as its been around forever and its pretty annoying +14:08 < jrandom> (the actual hang, not the watchdog code that detects the hang) +14:09 < jrandom> the current CVS rev (0.4.1.2-1) has the 'meat' of the watchdog disabled - it monitors, but oesn't shut down the router +14:10 < jrandom> but 0.4.1.2 should be fine for everyone (except mule ;) +14:10 < jrandom> oh, as mentioned before, start up some logging and send me some data, per http://dev.i2p.net/pipermail/i2p/2004-October/000465.html +14:11 < jrandom> the more data the better - if you can leave it running overnight, that'd be great (a 20h run on duck's box generated ~60MB of data) +14:11 < jrandom> ok, moving on to 2) 0.4.1.3 +14:12 < jrandom> well, there's not really anything i want to mention beyond wahts in the email +14:12 < jrandom> anyone have anything they want to say re: 0.4.1.3? +14:12 < Janonymous> nah +14:13 < deer> <postman> no +14:13 < Janonymous> backwards compatable? +14:13 < jrandom> certainly +14:13 < jrandom> ok, moving on to * 3) 0.4.2 +14:14 < jrandom> again, another "see the email" :) +14:14 < Janonymous> xpc vs. tcp ?? +14:14 < jrandom> i've never implemented a tcp stack before, so any guidance would be appreciated +14:15 < jrandom> xcp has better handling in networks with high delays +14:15 < jrandom> (for congestion control) +14:15 < Janonymous> does that include fec? +14:15 < jrandom> no +14:16 < Janonymous> k, cause I've been researching that some +14:17 < jrandom> cool +14:17 < jrandom> anything good you've found? +14:17 < deer> <cervantes> most GET requests are sub 32kb...and your average html page should be around that size...so I'd imagine eepsurfing will be much improved... - I wouldn't mind seeing an improvement in per-tunnel throughput though...will the new stack improve upon that? +14:17 < Janonymous> fec is used a lot for high latency/high throughput networks +14:18 < deer> <mule_iip> jrandom: nor have i, but i could tell a folk here to support you +14:18 < Janonymous> jrandom: some.. I'll report back +14:18 < deer> <mule_iip> at least it would be a good learning experience for him and another pair of eyes +14:18 < jrandom> great Janonymous +14:18 < jrandom> oh kickass mule +14:18 < jrandom> cervantes: per-tunnel throughput would improve with >1 message windows +14:19 < jrandom> (i expect we'll be able to even start with >1 as a window size, depending upon what we can gleam from the router) +14:19 < jrandom> ((ecn++)) +14:19 < deer> <cervantes> grand +14:20 < jrandom> ok, anything else on 0.4.2 stuff? +14:20 < Janonymous> fresh stack.. fresh laptop.. *drools* +14:21 < jrandom> heh +14:21 < Janonymous> yea +14:21 < Janonymous> one thing +14:22 < Janonymous> this will implement the new short handshake? +14:22 < jrandom> hmm? +14:22 < jrandom> we have the low-cpu TCP reconnection code in the 0.4.1 transport +14:22 < Janonymous> ah, in the email, you mention the alice-> bob handshake +14:23 < Janonymous> ah +14:23 < Janonymous> still catching up +14:23 < jrandom> oh. yeah, whatever 0.4.2 comes up with, it'll support a packet sequence like the one in the email +14:24 < Janonymous> k +14:24 < jrandom> we'll probably control it largely through socket options (e.g. set the stream to interactive and it sends asap, set the stream to bulk and it only sends when the buffer is full or itsflushed [or it needs to ack]) +14:25 < jrandom> ok, swinging on to 4) mail discussion +14:25 < jrandom> postman - you 'round? +14:26 < deer> <postman> ya +14:26 < jrandom> word, wanna give us a run down / update wrt the mail stuff? +14:27 < deer> <postman> hmm, ok tho i am quite shy talking in front of that many ppl :) +14:27 < jrandom> heh just imagine we're all nak^H^H^Her... nm +14:28 * Janonymous gets popcorn out +14:28 < deer> <postman> since the 20th od september there is a SMTP/POP Service running - accessible with normal smtp/pop3 MUAs +14:29 < deer> <postman> i put quite some efforts in it in a way that i analyzed the potential risks that normal mail clients bear +14:29 < Janonymous> what about inproxies/outproxies? +14:29 < deer> <postman> put it all together on a website +14:29 < deer> <postman> for those who haven't done so: www.postman.i2p +14:29 * Janonymous has not access to the network currently +14:30 < deer> <postman> there's a proposal on the website that tries to comprehend all the common problems dealing with anonymity and reliability of a mailservice when doing a bridging between i2p and internet +14:30 < deer> <postman> out/inproxy does not run yet but is in the planning +14:30 < Janonymous> I think I caught some of the discussion on the maillist or the forum +14:30 < Janonymous> out would be more dangerous than in, right? +14:31 < deer> <postman> first i want a commonly accepted concept +14:31 < deer> <postman> generally YES, but i think we found a way that spam and the likes won't be sent outward +14:31 < jrandom> what'd be neat is if the mx.postman.i2p in/outproxy could dispatch to different (or multiple redundant) pop3 accts +14:31 < deer> <postman> simply by putting a quota on every user trying to send mails out +14:32 < jrandom> (that way it wouldn't be tied to a particular mailhost) +14:32 < deer> <postman> jrandom2p: please explain further +14:33 < Janonymous> could the seperate mailhosts be syncronized too? +14:33 < deer> <postman> jrandom2p: it's a question of account based routing +14:33 < jrandom> right postman +14:33 < jrandom> probably lots of work, i dont know much about the MTAs you're working on +14:33 < deer> <postman> jrandom2p: the out/in proxy could easily handle more than one internal mailsystem - even could arrange a fallback kind of delivery +14:34 < jrandom> 'k, great +14:34 < Janonymous> Q wrt in/out +14:34 < deer> <postman> janonymous: i did not understand your question - please explain +14:34 * jrandom dreams up uucp-style offline fetch from mx.postman :) +14:35 < Janonymous> would mandatory mailbox to mailbox encryption make in/out sending less dangerous? +14:35 < deer> <postman> jrandom: haha, uucp is not needed i think - maybe ETRN is sexier :) +14:35 < deer> <postman> janonymous: right now the system works only internaly - everyone is free to apply PGP or sth similiar +14:36 < jrandom> Janonymous: you should swing by www.postman.i2p - he's put up a chunk of ideas / issues on there +14:36 < Janonymous> mandatory encryption/signatures is also an antispam method I believe +14:36 < deer> <Ragnarok> would it be possible to serve the postman.i2p address book using LDAP? +14:36 < Janonymous> I will once my laptop comes in +14:37 < deer> <postman> rag: there's an addressbook already - it is based on SQL tho - a transfer to LDAP os possible +14:38 < Janonymous> = server hosted address book? +14:38 < deer> * postman invites everybody to contribute own ideas to the ideas/concepts html document +14:38 < Janonymous> will do postman +14:38 < deer> * cervantes spiders the address book and starts writing penis enlargement pharmacutical mails +14:39 < deer> <postman> janonymous: well, ALL mailusers are SQL based - thus the "addressbook" is just a view on that table +14:39 < deer> <postman> cervantes: btw, every user can chose whether he wants to be visible or not +14:39 < Janonymous> ah +14:40 < Janonymous> how about selective groups ;) +14:40 < deer> <cervantes> postman: yup I've signed up already ;-) +14:40 < deer> <postman> cervantes: and since we HAVE a mailidentidy system , you cannot forge your senderaddress - we know it has been YOU :) +14:40 < deer> <postman> janonymous: yeah, it's planned for version 2.0 :) +14:41 < deer> <cervantes> postman: but I'll just spam every ircnym@postman.i2p ;-) +14:41 < deer> <postman> cervantes: this is technically possible, yes :) +14:42 < deer> <postman> cervantes: i hope you're able to deliver those pills too :) +14:42 < Janonymous> sounds like a much needed and long expected development for i2p +14:42 < Janonymous> the new email system +14:42 < deer> <cervantes> postman: and on the sender thing..the "Cervantes' penis enlargement elixir" would indicate the sender too :) +14:42 < deer> <postman> janonyous: i cannot tell about every detail implemented +14:43 < deer> <postman> jan: the website is best suited for this +14:43 < deer> <postman> cervantes: indeed - but this could be forged :) +14:43 < Janonymous> alrighty.. I'll get there asap +14:43 < jrandom> ok, great. so, yeah, y'all should review whats up on www.postman.i2p and send in your ideas/comments +14:43 < deer> * postman nods and sits down again +14:44 < jrandom> (postman++) +14:44 < jrandom> ok that brings us to 5) ??? +14:44 < jrandom> anyone have anything else they want to bring up? +14:44 < jrandom> (i2p related) +14:44 < deer> <postman> :) +14:44 < Janonymous> just a thought +14:45 < Janonymous> possible uses for I2P.. we know its a "distributed anonymous network layer" +14:45 < deer> <Jake> my node is down :( moving equipment to a different part of the house +14:46 < Janonymous> but what can that be used for.. particularly, those "common good" issues +14:46 < Janonymous> Oppressive third world countries, freedom of speech.. etc.. thats one of the primary things that got me so interested in i2p to start with +14:47 < Janonymous> and freenet for that matter +14:47 < deer> <Jake> oppressed 1st world countries like the u.s. +14:47 < Janonymous> so, I thought maybe some extrapolation on those issues, maybe starting on the forum, then some words on the site +14:48 < jrandom> we've got a lot of work to do before we can claim any relevence for people in china +14:48 < Janonymous> heh, yea, wouldn't want to make any false promises, but.. +14:48 * jrandom will not say we're safe when there has been so little peer review (and there are still so many outstanding issues) +14:49 < deer> <fidd> how hard will it be for china to censor i2p? +14:49 < deer> <cervantes> I think applications will begin to surface more readily once the underlying network has stopped "shapeshifting" +14:49 < Janonymous> but those issues to me are one of the main things that makes i2p so exciting +14:49 < jrandom> fidd: censor has many definitions. in the sense "stop specific content from being transferred", pretty much impossible, short of making i2p illegal +14:50 < Janonymous> how about, "detect i2p on networks in china" +14:50 < Janonymous> stego? +14:51 < jrandom> exciting, yes. important? yes. necessary? yes. but since there's so much work to do before we're relevent, its just depressing to talk about it. +14:51 < Janonymous> my bad :) +14:51 < deer> <cervantes> once the base network is solid, then we could probably do with some nice toys to play with - eg filesharing apps, IM systems etc. Hopefully the userbase will swell at that point....before this happens there just won't be enough peers to guarantee anonymity for people who live in oppressive systems +14:52 < jrandom> its always important to keep your eyes on the real goals Janonymous, and i appreciate that +14:52 < Janonymous> yea, numbers of nodes has a lot to do with it +14:52 < modulus> imo until there is stego and things like random noise to defeat traffic analysis people in oppressive countries should stay away for a while. +14:53 < deer> <cervantes> no..they should stay here and help :) +14:53 < modulus> :-) +14:53 * jrandom will not describe in detail why those aspects won't be necessary, as the 3.0 rev will take care of 'em :) +14:53 < modulus> 3.0? sounds long-term ;-) +14:53 < jrandom> i have ~= 0 faith in stego transports for public networks +14:54 < jrandom> it aint tomorrow, thats for sure. +14:54 < Janonymous> word? huh +14:54 < Janonymous> jrandom: whys that (wrt stego)? +14:55 < jrandom> how to defeat stego on public networks with open source software: download the source, review the stego generation code, write detection code, deploy. +14:56 < jrandom> how to defeat stego on public networks with closed source software: kidnap the dev's family, subvert the code. deploy. +14:56 < Janonymous> ah.. yea.. random inputs? eh.. I just read this article talking like it was the future or something +14:56 < jrandom> how to defeat stego on private networks: laugh at the 5 people using it, and arrest 'em all. +14:56 < modulus> well, what about anonymous closed-source software? of course it could be a trojan ;-) +14:57 < deer> <Jake> jrandom: if you're ever kidnapped, you can let us know by telling us "my dog fido is really upset about the food he's eating today" +14:57 < deer> <Jake> that will be the giveaway and we'll know +14:57 < deer> <cervantes> %s!dev's family!jrandom +14:57 < jrandom> heh jake +14:58 < Janonymous> whens the eta for 4.2? +14:58 < jrandom> Janonymous: the #1 feature of anonymity or security software: snake oil. +14:58 < jrandom> 0.4.2? sometime this month +14:58 < jrandom> prolly near the end +14:58 < Janonymous> heheh. +14:58 < jrandom> 0.4.1.3 will prolly be out later this week or the weekend +14:58 < deer> <cervantes> Jake: that would never work, we'll juist think you've poisoned his dog +14:58 < deer> <cervantes> *just +14:58 < Janonymous> I should be back on the net in a week or two +14:59 < jrandom> r0x0r +14:59 < jrandom> ok, anyone else have something to bring up? +14:59 < deer> <Jake> cervantes :) +15:00 < jrandom> if not.. +15:00 * jrandom winds up +15:00 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/111.rst b/i2p2www/meetings/logs/111.rst new file mode 100644 index 00000000..9fe27a4a --- /dev/null +++ b/i2p2www/meetings/logs/111.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 12, 2004 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/112.log b/i2p2www/meetings/logs/112.log new file mode 100644 index 00000000..5ce2381e --- /dev/null +++ b/i2p2www/meetings/logs/112.log @@ -0,0 +1,268 @@ +14:03 < jrandom> 1) 0.4.1.3 +14:03 < jrandom> 2) Tunnel test time, and send processing time +14:03 < jrandom> 3) Streaming lib +14:03 < jrandom> 4) files.i2p +14:03 < jrandom> 5) ??? +14:03 < jrandom> 0) hi +14:03 * jrandom waves +14:04 < modulus> hi hi +14:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-October/000469.html +14:04 < deer_> <fidd> howdy +14:04 < jrandom> i didn't spend much time on the notes, so they're pretty brief +14:05 < jrandom> but, c'est la vie +14:05 < jrandom> moving on to 1) 0.4.1.3 +14:05 < jrandom> the release came out the other day and its been.. well... largely like before +14:05 < jrandom> working good enough for most things, but not as reliable as we'd like +14:06 < jrandom> throughput is still low, but thats a know issue to be dealt with in 0.4.2 +14:06 < jrandom> as mentioned in the email, I dont expect there to be any more 0.4.1.* releases +14:07 < jrandom> I dont have much more to say on that - anyone have any comments / concerns? +14:07 < deer_> <newsbyte> yes: what about the freeze-up? +14:09 < jrandom> I'm not going to discount the possibility that your machine hung due to I2P, but I severely doubt it +14:09 < jrandom> no one else has ever reported that happening on any platform +14:09 < deer_> <newsbyte> well...it must be related to it somehow, if not directly, IMHO +14:09 < deer_> <newsbyte> maybe the java? +14:10 < jrandom> you're on 1.5 on w2k? +14:10 < jrandom> or 1.4.2_05? +14:10 < deer_> <newsbyte> nope, 1.5 +14:10 < jrandom> ok +14:10 < deer_> <newsbyte> I can't exclude it's something else, ofcourse +14:11 < deer_> <newsbyte> could be coincidence it happend two times +14:11 < jrandom> well, we can discuss further how to find out the cause after the meeting if you'd like +14:11 < deer_> <newsbyte> but the last time..I dunno...nothing much else was running, then +14:11 < deer_> <dinoman> 1.5 on w2k works good for me :) +14:11 < deer_> <newsbyte> indeed, though +14:11 < deer_> <newsbyte> isn't there a simple debug log or something? +14:11 < jrandom> if it happens again, please send me wrapper.log and logs/log-router-*.txt +14:11 < deer_> <newsbyte> that might be usefull when it freezes +14:11 < jrandom> there are more logs than dirt ;) +14:12 < jrandom> ok cool dinoman +14:12 < jrandom> perhaps it was some interaction with your software firewall +14:12 < deer_> <newsbyte> maybe +14:12 < jrandom> but, yeah,bounce me logs if it happens again +14:12 < jrandom> (please :) +14:12 < deer_> <newsbyte> well, that it would get blocked, I would understand +14:12 < deer_> <newsbyte> but a total freeze...dunno...was creepy +14:13 < deer_> <newsbyte> on the bright side: I've 27/63 now +14:13 < jrandom> great +14:13 < jrandom> ok, anyone else have any questions/comments/concerns with 0.4.1.3? +14:13 < deer_> <newsbyte> I'll guees I'll ask Whoo to guide my through the eep thingy +14:13 < deer_> <dinoman> just don't use it with Sygate Personal Firewall bad bad +14:13 < deer_> <newsbyte> why? +14:14 < deer_> <dinoman> crash +14:14 < deer_> <newsbyte> yes; you forgot 6) profit!! +14:14 < deer_> <newsbyte> ;-) +14:14 < deer_> <newsbyte> crash? +14:14 < deer_> <newsbyte> ermm +14:14 < jrandom> dinoman: it crashes your OS? the firewall? I2P? +14:14 < deer_> <newsbyte> well, wouldn't that explain it, then? ;-) +14:15 < jrandom> newsbyte: are you running Sygate Personal Firewall? +14:15 < deer_> <newsbyte> indeed +14:15 < deer_> <newsbyte> well, not on my router +14:15 < deer_> <newsbyte> but on the puter, yes +14:15 < deer_> <newsbyte> seems we're on to something +14:16 < deer_> <DrWoo> newsbyte: /join #i2p-chat so jrandom can get through his meeting +14:16 < deer_> <newsbyte> though it doesn't crash/freeze immediately, apperently +14:16 < deer_> <dinoman> os it crashes windows +14:16 < deer_> <newsbyte> ? +14:16 < deer_> <newsbyte> jrand is already here +14:16 < deer_> <dinoman> sorry looked away +14:16 < jrandom> ok, perhaps we can look into what SPF is b0rking on +14:16 < jrandom> if there's nothing else on 0.4.1.3, moving on to 2) Tunnel test time, and send processing time +14:17 < jrandom> there was some discussion yesterday exploring some of the timeouts, and basically things just occationally take too long +14:17 < jrandom> i dont think the spikes you can see in http://dev.i2p.net/~jrandom/processingTime.png are legitimate though +14:18 < jrandom> well, they're real - it really does take that long +14:18 < jrandom> what i mean is, we should be able to get rid of them +14:18 < jrandom> some queueing is going to happen, but if we are more careful with what we accept, we should be able to reduce it +14:19 < jrandom> the delays are also likely due to some occational spikes in job processing time, which we can tune the fsck out of +14:20 < jrandom> in general though, the message queueing seems all right, even if it spikes up some tunnel tests +14:20 < deer_> <newsbyte> darn..I wish freenet and i2p could really merge...seems like progress would be a lot faster, possibly beneficial to both +14:20 < deer_> <Ragnarok> yeah, I don't see why fsck would be useful for jon processing :) +14:20 < deer_> <Ragnarok> s/jon/job/ +14:21 < jrandom> there is much potential for collaboration, but the two projects have very different aims +14:21 < jrandom> !thwap Ragnarok +14:21 < deer_> <newsbyte> ermm +14:21 < jrandom> oh, one thing I mentioned yesterday +14:21 < deer_> <newsbyte> I don't think the projects' goals, however, are all that different... +14:22 < deer_> <DrWoo> jrandom: technical goals +14:22 < jrandom> newsbyte: we can discuss that in 5) ??? or later if you prefer, we're on 2) right now +14:22 < deer_> <DrWoo> oops newsbyte: technical goals +14:22 < deer_> <Ragnarok> hehe +14:22 < deer_> <newsbyte> yes, and 3)profit! according to /. traditions! +14:22 < deer_> <newsbyte> :-) +14:22 < deer_> <Demokritos> I can't believe Tor is not backwards compatible from 0.0.8 to 0.0.8.1 +14:23 < jrandom> with the tunnel testing, there is a floor to the test period - currently set to 5 seconds by default +14:23 < jrandom> the previous release had a hard limit of 30 seconds, but you can configure your own tunnel test time by updating http://localhost:7657/configadvanced.jsp and adding "router.tunnelTestMinimum=10000" (or whatever - that value is in milliseconds) +14:23 < deer_> <newsbyte> those seconds, are they alchimagical? +14:24 < jrandom> the 5s default should be fine though +14:24 < deer_> <Demokritos> I actually upgraded Tor the day before yesterday because it stopped working, and now the network is telling me again, I have a non compatible version... what the.. +14:24 < deer_> <Demokritos> oh... hello everyone :) +14:24 < jrandom> newsbyte: the tunnel test time is MAX(avgTunnelTestTime*2, minTunnelTestTime) +14:25 < jrandom> (we have the minTunnelTestTime because otherwise a series of fast tests could cause a cascading failure) +14:26 < jrandom> more details can be found in http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD +14:26 < deer_> <newsbyte> hmm +14:26 < deer_> <Demokritos> this is really funny... a job agency wants me to use Internet Explorer, otherwise I'm not able to register an application +14:27 < jrandom> *cough* y'all realize these meeting logs go on the web, right? :) +14:27 < deer_> <Demokritos> <-- not too good in english +14:27 < deer_> <newsbyte> they do?! +14:27 < deer_> <newsbyte> Hi mum! +14:27 < deer_> <newsbyte> ;-) +14:27 < deer_> <Demokritos> um, sorry. .I'm disturbing the meeting.. I'm off +14:28 < jrandom> naw, please stay, but discuss i2p stuff ;) +14:28 < deer_> <newsbyte> don't worry; disturbing is an art, just keep an eye on me, and you'll learn +14:28 < deer_> <newsbyte> ;-) +14:28 < jrandom> ok, anything else on 2) Tunnel test time, and send processing time ? +14:28 < deer_> <Ragnarok> focus people +14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has quit [Read error: 60 (Operation timed out)] +14:29 < jrandom> if not, moving on to 3) Streaming lib +14:29 < jrandom> as mentioned in the status notes, lots of progress +14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has joined #i2p +14:29 < deer_> <newsbyte> done by you? +14:29 < jrandom> still not there yet, but I hope to be doing some live tests in the next week +14:30 < jrandom> i've been working on the streaming lib, yeah +14:30 < jrandom> i finally got it ping()ing earlier today ;) +14:30 < deer_> <Ragnarok> nice :) +14:31 < jrandom> ok, i dont really have anything else to add about that +14:31 < jrandom> anyone have any questions / comments / concerns? +14:31 < deer_> <newsbyte> ermm...speed? +14:31 < jrandom> speed is fine +14:31 < deer_> <baffled> what type of speed up/through put do you expect? +14:31 < jrandom> i expect significant throughput improvements +14:32 < deer_> <newsbyte> he expects a fine, he said +14:32 < deer_> <newsbyte> for speeding +14:32 < deer_> <newsbyte> ;-) +14:32 < jrandom> in addition, for small request/response connections, the latency will be dramatically reduced +14:32 < jrandom> (cut in half) +14:32 < deer_> <dinoman> wow +14:32 < deer_> <dinoman> is that using udp? +14:33 < jrandom> the new lib exposes all the neat tunable parameters for normal TCP stacks too, so apps will be able to tweak out their own setup +14:33 < jrandom> no dinoman, this works on top of i2p's I2CP +14:33 < deer_> <dinoman> wow x2 +14:33 < jrandom> (though we'll be writing similar code in a month or so to get the UDP transport..) +14:34 < jrandom> but, well, we'll see. +14:34 < deer_> <newsbyte> because...? +14:34 < jrandom> there's still a lot of work to do +14:34 < jrandom> because what? +14:34 < deer_> <newsbyte> well, can't tcp do it as well? +14:35 < jrandom> oh, why we're going to go UDP? http://www.i2p.net/todo#transport +14:35 < deer_> <newsbyte> I remember the same discussion on freenet too, but they sticked to tcp as yet +14:35 < jrandom> plus TCP is a general purpose streaming transport - we can dramatically simplify it, since we can put up with a certain degree of out of order +14:35 < deer_> <newsbyte> not that all decisions they make are good ;-) +14:36 < jrandom> newsbyte: i've followed those discussions and we're going to go udp +14:36 < jrandom> (that doesnt mean freenet is wrong - they've got different constraints) +14:37 < deer_> <Ragnarok> i2p should not be compared too closely to freenet. They're very different technically. +14:37 < deer_> <newsbyte> (or: they ARE wrong ;-) +14:37 < jrandom> i dont think their use of TCP right now is wrong, just as I dont think I2P's previous use of TCP is wrong. progress requires small steps +14:38 < deer_> <mule_iip> newsbyte makes sure the meetings don't get too short +14:38 < jrandom> heh +14:38 < deer_> <newsbyte> yeah, nothing worse then short meetings +14:38 < deer_> <newsbyte> you can't eat all the popcorn and drink all the beer, then +14:38 < jrandom> ok, anything else on 3) Streaming lib ? +14:39 < jrandom> if not, 4) files.i2p +14:39 < deer_> <Ragnarok> I think we're cool +14:39 < deer_> <newsbyte> well, I know I am +14:39 < deer_> <newsbyte> ;-) +14:39 < deer_> <newsbyte> and funny too +14:39 < deer_> <newsbyte> most of the time +14:39 < deer_> <newsbyte> and also annoying +14:39 < deer_> <newsbyte> ;-) +14:39 < jrandom> well, i just wanted to point out files.i2p - a new search engine on i2p +14:40 < deer_> <newsbyte> ah, I see +14:40 < deer_> <newsbyte> I was hoping it would be about putting eepsites up +14:40 < jrandom> one interesting thing to note is that you can reach eepsites that aren't up anymore with it, since it caches +14:41 < deer_> <baffled> does it cache everything? +14:41 < deer_> <newsbyte> all searchengines thusfar are server-side? +14:41 < deer_> <Ragnarok> interesting. Shouldn't be too hard, these days :). +14:41 < jrandom> baffled: caches text/html from what i can tell +14:42 < deer_> <mule_iip> at least it has limits on file size and types, so won't cache movies +14:42 < deer_> <baffled> Auh, that's what I thought not binary. +14:42 < deer_> <newsbyte> I mean, they are not in js, I suppose? +14:43 < jrandom> it uses nutch if anyone wants to look into it further. or i'm sure we'll get the site author to put up a feedback form or something ;) +14:43 < jrandom> newsbyte: correct, this is just a normal website hosted anonymously +14:43 < jrandom> the site contains a search engine (like google) +14:44 < jrandom> anyway, i just wanted to mention it +14:44 < jrandom> there have also been a lot of blogs popping up lately, which imho is really cool +14:44 < jrandom> my 'eep' bookmark folder almost fills a screen :) +14:44 < deer_> <Ragnarok> hehe, myi2p is happening all by itself :) +14:45 < jrandom> you just have to bring up the sore points, dont ya ragnarok? ;) +14:45 < deer_> <Ragnarok> sorry :) +14:46 < jrandom> ok, anyone have any questions/comments/concerns wrt files.i2p? +14:46 < jrandom> if not, let me move on to 4.1) biff +14:46 * jrandom almost forgot biff +14:46 < jrandom> postman, you arond? +14:47 < deer_> <newsbyte> I think he's biffed up +14:47 < jrandom> well, if not, biff is this new kickass mail notification bot +14:47 < jrandom> if you've got an email acct at mail.i2p, you can tell biff to notify you when you get new mail +14:47 < deer_> <newsbyte> does it has archives? +14:48 < jrandom> newsbyte: biff is just a notification bot, the mail is stored on the mail server (and accessed with your normal mail reader - kmail, etc) +14:48 < jrandom> see http://www.postman.i2p/ +14:49 < jrandom> ok, so, yeah, go to the eepsite or check out #mail.i2p over there +14:49 < deer_> <newsbyte> I will, as soon as I get my eepsite on +14:49 * jrandom doesnt really know much more wrt biff - redirect any questions to postman +14:50 < jrandom> instead, we can move on to 5) ??? +14:50 < deer_> <newsbyte> indeed +14:50 < jrandom> does anyone have anything else they want to bring up? +14:50 < deer_> * mule_iip raising hand to get voice: would like to recall my persistent FCP over I2P problems. but probably that can wait and will automagically be solved by 0.4.2. +14:50 < deer_> <newsbyte> yes, and the freeze +14:50 < jrandom> i hope so mule_iip +14:50 < deer_> <mule_iip> ok, will be your test platform :) +14:50 < jrandom> newsbyte: is there anything we need to discuss about it? could you just email me your logs if it happens again? +14:51 < jrandom> ooh mule, that'd rule +14:51 * jrandom will definitelytake you up on that +14:51 < deer_> <newsbyte> well...can i still send those, if everything is frozen? +14:51 < jrandom> the files are written to disk. +14:51 < jrandom> when you restart, send me the logs +14:51 < deer_> <newsbyte> I mean, in that case, I could send it now, since they should be somewhere +14:51 < jrandom> (please) +14:51 < deer_> <dinoman> i was in the forum and see that the jabber service is gone. was thaat of us to anyone if it was i would like to run one if it would be cool? +14:51 < jrandom> the files rotate though newsbyte +14:52 < jrandom> duck and demonic_1 have had jabber servers at various times, but it seems most of the i2p IM activity has been on irc +14:52 < deer_> <newsbyte> the files rotate? surely it stores quite some data before it starts deleting? +14:53 < jrandom> newsbyte: ok, send me your logs, maybe it has something in it +14:53 < deer_> <newsbyte> good +14:53 < deer_> <newsbyte> ermm +14:54 < deer_> <newsbyte> darn +14:54 < deer_> <newsbyte> a lot of .logs +14:54 < deer_> <dinoman> ok +14:54 < deer_> <newsbyte> a noob is never gonna follow this +14:54 < deer_> <newsbyte> I guess you're right in not making a /. article yet +14:55 < jrandom> we're in no rush +14:55 < deer_> <newsbyte> log-router.txt? +14:55 < jrandom> wrapper.log and logs/log-router-*.txt +14:56 < deer_> <newsbyte> and the mailaddy to use would be...? +14:56 < deer_> <fidd> dinoman, a jabber server would be cool imo +14:56 < jrandom> jrandom@i2p.net +14:56 < deer_> <newsbyte> accessible by i2p, I hope? +14:56 < deer_> <newsbyte> ;-) +14:56 < jrandom> newsbyte: you can put your logs on your eepsite and msg me the url +14:57 < jrandom> or you can send mail to jrandom@mail.i2p +14:57 < deer_> <newsbyte> indeed! +14:57 < deer_> <newsbyte> a good idea! +14:57 < deer_> <newsbyte> there is only one little problem with it: It's not up yet +14:57 < jrandom> ok, anyone else have anything they want to bring up? +14:57 < jrandom> well, we can work on that newsbyte +14:57 < jrandom> (after the meeting) +14:59 < deer_> <newsbyte> thnks, but whoo is already helping +14:59 < jrandom> if there's nothing else... +14:59 < deer_> <newsbyte> we need a detailed howto/wiki/helpsite/something, though +14:59 * jrandom winds up +14:59 < deer_> <Jake_> i'd like to say, for the meeting, if a public release of i2p can be made before the u.s. election on november 2nd, this would go a long way to helping ensure a stable democracy +14:59 < deer_> <newsbyte> what about 6)? +14:59 < jrandom> newsbyte: would you like to work on that? +15:00 < jrandom> newsbyte: i do agree it'd be great to get some more howtos and help info +15:00 < deer_> <Ragnarok> 6) There is no.... number 6 +15:00 < deer_> <newsbyte> well, yeah, sort of, but it's a strange thing, with me +15:00 < deer_> <newsbyte> I'm pro-wiki and public thingy and free for everyone and all that +15:00 < deer_> <newsbyte> but my ego protests and wants minimal control +15:00 < jrandom> great +15:00 < deer_> <newsbyte> go figger +15:00 < jrandom> heh +15:01 < jrandom> well, if you'd like to make your own eepsite into a wiki you control, that'd be great too +15:01 < deer_> <newsbyte> indeed +15:01 < jrandom> though ugha.i2p has a pretty good uptime +15:01 < deer_> <newsbyte> I'll think about it +15:01 < jrandom> cool +15:02 < deer_> <newsbyte> 6 would be the freenet-i2p thingy +15:02 * jrandom winds up +15:02 * jrandom *baf*s the meeting closed +</div> +{% endblock %} diff --git a/i2p2www/meetings/logs/112.rst b/i2p2www/meetings/logs/112.rst new file mode 100644 index 00000000..e67f2f2d --- /dev/null +++ b/i2p2www/meetings/logs/112.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 19, 2004 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/113.log b/i2p2www/meetings/logs/113.log new file mode 100644 index 00000000..28317f3a --- /dev/null +++ b/i2p2www/meetings/logs/113.log @@ -0,0 +1,267 @@ +14:04 < jrandom> 0) hi +14:04 < jrandom> 1) Net status +14:04 < jrandom> 2) Streaming lib +14:04 < jrandom> 3) mail.i2p progress +14:05 < jrandom> 4) ??? +14:05 < jrandom> 0) hi +14:05 * jrandom waves +14:05 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-October/000474.html +14:06 * jrandom will let y'all read ahead (damn you, read ahead!) +14:06 < jrandom> jumping in to 1) net status +14:07 < jrandom> i guess the email covers what i wanted to mention. nice fix wrt resume duck, and thanks for reporting it ardvark and ragnarok! +14:07 < jrandom> does anyone have anything they want to bring up about the network status? +14:08 < modulus> it rules. +14:08 < deer> <postman> hi +14:08 < jrandom> w3wt +14:09 < jrandom> there is something funky w/ lag going on lately though, but it seems to be the same as what we discussed last week +14:09 < jrandom> (especially since i haven't done any work on the core since then) +14:09 < deer> <clayboy> i think everybody agrees that it has been stable and usable. +14:09 < deer> <clayboy> i miss my 10-16 hours connected time on irc though, not important +14:10 < deer> <jrandom2p> i'm on for 20h here +14:10 < deer> <jrandom2p> but yeah, it varies (which hopefully agenda item 2) will help with) +14:10 < deer> <clayboy> i can hardly get > 2h, but i always reconnect in an instant, so it's still usable +14:11 < jrandom> cool +14:11 < jrandom> still not good enough, but sufficient +14:11 < jrandom> (for the time being) +14:11 < deer> <clayboy> agreed +14:12 < jrandom> ok, anyone have anything else, or shall we move on to 2) streaming lib? +14:13 < jrandom> [consider us moved] +14:13 < jrandom> the email gives a rundown of how the progress is coming +14:14 < jrandom> the message sequences are 'correct' in most cases (matching the ones discussed before) +14:14 < jrandom> e.g. short request/response gets the requestee a response in a single round trip +14:15 < jrandom> i'm working on the profile=bulk right now, going through the sliding windows under lag and failure conditions +14:15 < jrandom> still some things to clean up, and nothing ready for use, but its progress +14:16 < deer> <clayboy> so is 0.4.2 with streaming lib en route for october? it seems like an unnecessary rush. +14:16 < jrandom> i dont think we'll have the streaming lib ready for final deployment by next week, no +14:17 < jrandom> so there'll be some schedule slippage, i'm not sure to what extent yet +14:17 < deer> <duck> any test classes we can run for kicks? +14:18 < jrandom> i havent committed the build.xml file yet to keep people from using it ;) but i'll commit what i've got later tonight, and you can try out http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/streaming/java/test/net/i2p/client/streaming/StreamSinkTest.java?rev=1.1&content-type=text/x-cvsweb-markup +14:19 < deer> <duck> h0t +14:19 < jrandom> one thing is that this new streaming lib doesn't use the old mode=guaranteed anymore since it has its own ACK/NACK setup +14:20 < jrandom> that means that after the lib works perfectly, there's still going to be some work to be done in the router itself, as the client sending tasks are designed for 'guaranteed' delivery, bundling a roundtrip message in the garlic to confirm session tag delivery +14:21 < jrandom> we don't actually have to fix that right away though - the bandwidth usage on that DeliveryStatusMessage is... trivial +14:21 < jrandom> but we'll want to sooner rather than later +14:22 < jrandom> ok, thats all i've got to say on that +14:22 < jrandom> anyone have anything to bring up wrt the streaming lib? +14:23 < jrandom> if not, 3) mail.i2p progress +14:23 < jrandom> postman, you 'round? +14:23 < deer> <postman> ya +14:24 < jrandom> any update for us, or shall we wait until there's more news? +14:24 < deer> <postman> ok +14:24 < deer> <postman> shall i? +14:24 < jrandom> the mic is yours +14:24 < deer> * gott awakens. +14:24 < deer> <postman> 1.) the in/out proxy facility is being installed/tested atm +14:25 < deer> <postman> 2.) within the next 10 days we'll have a gateway service from and to the internet for emails +14:25 < modulus> cool! +14:25 < jrandom> cool^2! +14:25 < deer> <clayboy> indeed +14:25 < deer> <postman> 3.) the implementation will follow the ideas/concepts of the ideas.html document on my websote +14:25 < deer> <gott> bravo ! +14:26 < deer> <postman> means: hashcash/recipient based quotas and all the fancy stuff +14:26 < deer> <postman> the service should not be abused by its fellow anonymous users +14:26 < deer> <postman> :) +14:26 < deer> <postman> well there'e another point +14:26 < deer> <postman> the question for webmail interfaces +14:26 < deer> <postman> right now i don't want to host itz on my servers +14:27 < deer> <postman> since i don't know about potential security problems +14:27 < deer> <postman> the system that runs now is verified by me - i know the source and the security risks +14:28 < deer> <postman> adding php and dynamic stuff and a webmail application FOR ALL users makes it much more difficult +14:28 < deer> <postman> the idea ( thanks jr) is: +14:28 < deer> <postman> what if the user got his own webmail interface installed as aonthr optional jetty or whatever instance? +14:29 < modulus> like a pop3 -> webmail thing? +14:29 < jrandom> 'zactly +14:29 < deer> <postman> and this local webmail application uses the postman.i2p tunnels to do smtp and pop3 +14:29 < modulus> sounds good. +14:29 < deer> <postman> but i need help in evaluating +14:30 < deer> <postman> right now i am quite busy with real life stuff and the in/out proxies +14:30 < jrandom> (eww, real life!) +14:30 < deer> <postman> and i got a peanut sized brain - so i am not good in java at all +14:31 < deer> <postman> i need sbdy helping how this can be done as a local/optional service +14:31 < modulus> may there be something that does this already on tcp? if so it could be used. +14:31 < deer> <DrWoo> postman: I doubt it's peanut sized, I think it takes walnut sized just to breath ;) +14:32 < jrandom> after a quick glance through hotscripts, i saw one that did pop3, though i dont know if it did authenticated smtp +14:32 < deer> <postman> modulus: i assume there's something in the wild that can be used / adapted - it would be sexy to let it run in an own jetty instance +14:32 < jrandom> i'm sure there is something out there, we just need an adventurous soul to go find it :) +14:32 < deer> <postman> jrandom2p: this can be hacked quite easily i think +14:33 < jrandom> exactly - in an ideal world, someone can just grab a mywebmail.war and save it to the webapps/ directory and jump into http://localhost:7657/mywebmail/ +14:33 < deer> <postman> well, i leave this issue to you to think about it :) +14:33 < modulus> even if it's a stand-alone app, it should be fine, with i2ptunel +14:33 < jrandom> right modulus +14:33 < deer> <postman> yep :) +14:34 < jrandom> and local >> remote, as the local side can do things like access your GPG keyrings or whatever +14:34 < deer> <postman> i will do anything thats needed to support such a system on the server side +14:34 < modulus> which hopefully would be very little. +14:36 < deer> <postman> of course there will be an official announcement as soon as internet access is available - so stay tuned - maybe there will be some progress on the webmail idea as well +14:36 < deer> <postman> so much for my department +14:36 < deer> * postman sits down again and sips on his coffee +14:36 < modulus> could you do something about filtering anon-revealing data? +14:36 < jrandom> kickass, thanks postman! sounds exciting +14:36 < modulus> some MUAs are very misbehaved in this way. +14:37 < deer> <postman> modules: please look at the webpage - there is a multipage sermon about that +14:37 < jrandom> :) +14:37 < modulus> ok +14:37 < jrandom> http://www.postman.i2p/sec.html to start +14:37 < modulus> i read that, i just thought maybe some fields could be filtered. +14:37 < modulus> maybe i trust postman but not other ppl. +14:38 < deer> <postman> modulus: They ARE filtred +14:38 < modulus> ok, last time i treid it they weren't. +14:38 < modulus> sorry about that. +14:38 < deer> <postman> modulus: sec2.html describes WHAT headerlines are filtered or changed +14:38 < deer> <postman> modulus: what headerlines are you refrring to? +14:38 < modulus> from domain (IP) kind of thing +14:39 < jrandom> it would be good if a local webmail script did the filtering locally +14:39 < jrandom> (in addition to any filtering done @ smtp.postman.i2p) +14:39 < deer> <postman> modulus: lets talk about that in pm, ok? :) +14:40 < deer> <postman> jrandom2p: of course - i am happy about every client doing its homework +14:40 < modulus> sure, sorry. +14:41 < jrandom> ok, do we have anything else for mail.i2p discussions? +14:41 < jrandom> if not, 4) ??? +14:41 < deer> * duck has something for #4 +14:42 < jrandom> sup duck? +14:42 < deer> <duck> the HD of home.duck.i2p blew up +14:42 < jrandom> (d'oh) +14:42 < deer> <duck> luckily the hosting accounts were not really used, except for alexandria +14:42 < deer> <duck> did anybody here leach all the ebooks? :) +14:43 < deer> <duck> if so, I got some missing so msg me please +14:43 < jrandom> actually, i think thetower did +14:43 < deer> <duck> I know that hypercubus also has them +14:43 < deer> <postman> damn +14:43 < jrandom> i saw a mirror on his site a while back +14:43 < deer> <postman> :/ +14:43 < deer> <duck> cool +14:43 < jrandom> i dont know if it has everything though, or how up to date it was +14:43 < deer> <duck> alexandria is now on http://duck.i2p/alexandria/ +14:44 < deer> <duck> and I am going back to being ashamed +14:44 < deer> <duck> . +14:44 < jrandom> no need to be ashamed, you've provided a kickass free service! +14:45 < jrandom> perhaps now is the chance for some geocities.i2p site ;) +14:46 < deer> <duck> oh, I made a yodel webfrontend @ http://duck.i2p/yodel/ +14:46 < jrandom> oh, one thing i didn't have in the agenda is BT related stuff. i know dinoman is doing some hacking on that - perhaps he wants to mention something? +14:46 < jrandom> ah nice +14:48 * jrandom notes that thetower's alexandria mirror link 404s +14:48 < deer> <gott> I have something to suggest. +14:48 < jrandom> sup gott? +14:48 < deer> <gott> I think it would be a nice feature for 0.4.2 to add a link to one of the sitelists on pages such as thetower's, baffled or mine. +14:49 < jrandom> thats a good idea +14:49 < jrandom> perhaps all three +14:49 < deer> <gott> This is to (a) keep a list of active eepsites and (b) form an index for i2p similar to FIND / Dolphin +14:49 < jrandom> yours is nice w/ the links to the eepsites too +14:49 < deer> <gott> the one located at http://gott.i2p/sites.html is being kept up-to-date +14:49 < deer> <gott> and the script is run every day +14:49 < deer> <gott> I can add optional descriptions to the links ( thanx to baffled's script ) +14:50 < deer> <gott> which would make it an index +14:50 < jrandom> perhaps it'd be neat to have a "recently added" or "recently removed" marker too? +14:50 < jrandom> word +14:51 < deer> <gott> quite good. +14:51 < deer> <gott> that's all I had to say for now. +14:51 < deer> <gott> oh, another thing +14:51 < deer> <gott> snipsnap works well under i2p +14:52 < deer> <gott> so we might see kuro5hin-style eepsites being brought up sometime a la SCUM +14:52 < jrandom> kickass +14:52 < deer> <gott> *except more devious a la SCUM +14:52 < jrandom> a howto for setting that up would be great +14:52 < deer> <gott> you put the .war in webapps +14:52 < deer> <gott> it's pretty straightforward ;-) +14:53 < deer> <polecat> snipsnap...SCUM...? +14:53 < jrandom> its really that easy? booyeah! +14:53 < jrandom> polecat - http://snipsnap.org/space/start +14:53 < deer> <gott> I have finished my discourse. +14:53 < deer> * gott retires. +14:53 < jrandom> thanks gott +14:54 < jrandom> nickster was using snipsnap for a while +14:54 < jrandom> ok, anyone have anything else to bring up? +14:55 * jrandom notes that we're near the hour mark even *without* newsbyte ;) +14:55 < deer> <polecat> I like pie! +14:55 < deer> <gott> I have another thing. +14:55 < deer> <duck> oh, orz is awake +14:55 < deer> <gott> I would like to announce that soon after 0.4.2 release I will publish an interview on jrandom on i2p-related things. +14:55 < deer> <polecat> I wasn't aware this a formal meeting. Might mention my ideas about name servers... +14:56 < deer> <duck> I suggest all japanese ppl to check out his eepsite/ircserver +14:56 < deer> <gott> Nothing specific to be said on it until the questions are asked and answered but you have something to look forward to. +14:56 < deer> <gott> it will be on my eeplog and if jrandom thinks good enough, probably featured somewhere on i2p.net +14:57 < deer> * gott retires again. +14:57 < deer> <postman> modulus: +14:57 < jrandom> yeah, orz's site and irc server work great, i just dont know what it says :) +14:58 < modulus> YES? +14:58 < modulus> sorry for caps. +14:58 < deer> <DrWoo> polecat: so about nameserver? +14:58 < deer> * gott unretires +14:58 < deer> <gott> duck: does he speak english ? +14:59 < jrandom> oh polecat, whats up? +14:59 < jrandom> polecat: we have our weekly meting every tuesday at 9p GMT +14:59 < deer> <gott> I assume he does to have set everything up so well. +14:59 < jrandom> (logs posted @ http://www.i2p/meetings once they're done ;) +15:00 < deer> <polecat> Yes. Well I was thinking a name server might be a good idea. But not DNS. c.c I had an idea for a server that did nothing but translate between Protocol Specific Addresses and human readable names. +15:00 < jrandom> so a URI-->URL resolver, kinda? +15:01 < deer> <polecat> That would replace hosts.txt, and eventually replace DNS itself once it supports ipv4 and ipv6. +15:01 < deer> <polecat> name => hash in the case of i2p. Like duck.i2p => gobbledygook +15:02 < jrandom> right right +15:02 < deer> <polecat> Trouble with DNS is it has "requirements" (i.e. hacks) like MX servers, and root hierarchy, and nasty stuff like that. The hackiness of DNS puts even Usenet to shame. +15:03 < deer> <polecat> I was talking about this earlier, and someone mentioned http://distributeddns.sourceforge.net/ +15:03 < deer> <polecat> I haven't had a chance to look at that site though. +15:05 < jrandom> there are lots of things to keep in mind when working through a naming system, and in turn, there are lots of tradeoffs to be made. there have also been lots of discussions of improvements over the years (not just within i2p) to address many of the issues, but a concrete solution would be great +15:05 < deer> <gott> quite good, quite good. +15:07 < jrandom> i've got my own views, but thats where one of i2p's strong points comes out - my own views are irrelevent :) any sort ofnaming srevice can be used by client apps, as all of that functionality is outside of the core scope +15:08 < jrandom> i know nano is working on something too - there's some entries @ nano.i2p, though i dont know how thats progressing +15:08 < deer> <polecat> Agreed; you could write clients to use a ddns server as much as you could write them to parse the local hosts.txt +15:08 < deer> <gott> jrandom: I dread the day when hosts.txt or equivalent naming system begins to show << enlarge.your.penis.i2p >> +15:09 < deer> <polecat> Just might be easier; at the current standing only I2PTunnel has the ability to understand hosts.txt. Plus if we're going to compete with ipv4 and ipv6 we can't compromise limited functionality when they don't. +15:10 < jrandom> a while back mihi factored out the naming hooks in i2ptunnel - anything that implements http://dev.i2p.net/javadoc/net/i2p/client/naming/NamingService.html can be used transparently +15:10 < jrandom> (and that includes I2PTunnel and SAM) +15:10 < deer> <polecat> Really? I'll have to look at that too... +15:11 < jrandom> well, they trade off functionality for security and identity +15:11 < deer> <polecat> And also since i2p has such long hashes, for cryptographic security, having a name server is even more important since most people cannot remember the full i2p hash address. +15:11 < jrandom> e.g. the jackboots can kick down $domainOwner's door +15:11 < jrandom> (and someone can spoof dns without much trouble) +15:12 < jrandom> but having some sort of name --> location resolution functionality is definitely important +15:13 < deer> <polecat> Without a centralized server, you can't have a unique human readable name anyway. Even if they're cryptographically signed, they still can be duplicated on the part that is comprehensible to us. +15:14 < lucky> ugh. +15:14 < lucky> Why don't you have deer block gott out? +15:14 < jrandom> there are many tradeoffs +15:14 < jrandom> i've outlined my preference at http://dev.i2p.net/pipermail/i2p/2004-February/000135.html +15:15 < jrandom> but i'm not goingto write a naming service anytime soon, so whatever an implementer wants to do, they're free to :) +15:15 < lucky> heh. I thought that was in response to the Gott question. +15:15 < jrandom> heh +15:15 < jrandom> naw, gott has been contributing positively as of late +15:16 < jrandom> ok, in any case polecat, you should put up an eepsite with your ideas +15:16 < lucky> god, what is the world coming to? +15:16 < deer> <polecat> I'm thinking of writing a naming service myself. I'd like to know what everyone else prefers, and get as much guidance as possible how to implement it in a way that works really really well. +15:16 < lucky> Oh, how can i contribute? +15:16 < lucky> I know some java know. Like variable assigning. +15:16 < lucky> And what ++j means +15:17 < deer> <polecat> Ugh... an eepsite... +15:17 < deer> <polecat> ++j is the post-increment operator on variable j? +15:18 < jrandom> polecat: you can post to the mailing list or forum, as well. perhaps make a poll in the forum if you want to see what sort of preferences people have? +15:18 < deer> <polecat> Trouble is this computer I'm on gets reset into Windoze frequently, and so unless I put my eepsite on a vfat partition, I can't share its info between operating systems. +15:19 < jrandom> 'k, then its prolly best to have the naming stuff on the forum instead of an eepsite :) +15:20 < deer> <polecat> Where's the forum again...? +15:20 < jrandom> http://forum.i2p/ +15:20 < jrandom> and http://forum.i2p.net/ +15:20 < jrandom> (isnt naming wonderful? :) +15:21 < deer> <gott> I have always contributed positively. +15:21 < deer> <polecat> Yes, except we all still wget the hosts.txt file from a centralized sources. ;3 +15:22 * jrandom uses cp, not wget ;) +15:22 < jrandom> ok, anyone have anything else to bring up? +15:23 * jrandom doesnt mean to shut down the naming discussion, its just that we can discuss that for weeks on end +15:23 < deer> <DrWoo> dinoman is working on a cvs server in i2p? +15:23 < jrandom> well, there already *is* a cvs server in i2p (cvs.i2p) +15:24 < jrandom> but thats right - dinoman was working on a full blown gforge in i2p iirc +15:24 < deer> <DrWoo> jrandom: sorryt,I mean a fully anonymous cvs ;) +15:25 < jrandom> hey, cvs.i2p is fully anonymous cvs :) i2p is completely self hosting, but without all the goodies for adding on lots of other projects +15:25 < jrandom> (and having a gforge on i2p would Kick Ass) +15:26 < deer> <DrWoo> jrandom: doesn't cvs.i2p run on the public server? +15:26 < deer> <polecat> gforge... dunno that... +15:27 < jrandom> DrWoo: maaaybe ;) +15:27 < jrandom> DrWoo: but the key is that developers can be anonymous and develop for i2p through i2p +15:27 < jrandom> if the machine that cvs.i2p is physically located on is under attack, we can just move the destination somewhere else +15:28 < deer> <polecat> Yes, so while the i2p source itself is vulnerable to being confiscated by the Long Arm of the Law, its developers are immune to a certain extent through anonymity. +15:28 < jrandom> let 'em have the source, its free! :) +15:29 < deer> <DrWoo> jrandom: ya, i see what you're saying, but it still is at the risk of something like the indymedia thing +15:30 < jrandom> if the jackboots kicked down the door of the colo where cvs.i2p is, i'd simply install cvs somewhere else, deploy a backup of the cvs there, and run an i2prouter with the cvs.i2p private key +15:30 < jrandom> (and *not* tell peole that cvs.i2p == cvs.i2p.net ;) +15:32 < jrandom> ok, anyone else have soemthing to bring up for the meeting? +15:32 < deer> <polecat> Hee, that's pretty cool. +15:33 < jrandom> if not +15:33 * jrandom winds up +15:34 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/113.rst b/i2p2www/meetings/logs/113.rst new file mode 100644 index 00000000..8db2b270 --- /dev/null +++ b/i2p2www/meetings/logs/113.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 26, 2004 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/114.log b/i2p2www/meetings/logs/114.log new file mode 100644 index 00000000..a54d7eb0 --- /dev/null +++ b/i2p2www/meetings/logs/114.log @@ -0,0 +1,398 @@ +13:37 < jrandom> 0) hi +13:37 < jrandom> 1) Net status +13:37 < jrandom> 2) Core updates +13:37 < jrandom> 3) Streaming lib +13:37 < jrandom> 4) mail.i2p progress +13:38 < jrandom> 5) BT progress +13:38 < jrandom> 6) ??? +13:38 < jrandom> 0) hi +13:38 < jrandom> sorry for the delay, weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2004-November/000477.html +13:38 < dm> meeting in 24 or 84? +13:38 < jrandom> 0 +13:38 < dm> oh.. -36? +13:39 < jrandom> yup, 9p GMT +13:39 < jrandom> but i forgot that, so we're starting... now ;) +13:39 < jrandom> 1) net status +13:39 < dm> good timing +13:39 < jrandom> well, no real change in the net status from my end - does anyone have anything they'd like to bring up about it? +13:41 < jrandom> if not, might as well move on to 2) core updates +13:41 < jrandom> i dont really have anything to add beyond whats in the email, so i'll give people a min to digest +13:42 < deer> <postman> arg +13:42 < jrandom> there've been 8 patches since the release, with another one or two pending. we'll probably just tag those all up into a 0.4.1.4, as the streaming lib itself isn't ready +13:43 < deer> <jrandom> wb, its looking a bit bumpy over here +13:43 < deer> <postman> np, i am back :) +13:43 < protok0l> any word on aum's disappearance? i want stasher! +13:44 * dm likes knowing that stuff is being done under the hood to optimize I2P +13:44 < jrandom> as gott quoted, diy, do or die +13:45 < jrandom> yeah, the memory churn was getting to be a substantial portion of the CPU time +13:45 < jrandom> so it was finally worth the effort to optimize +13:45 < deer> <baffled> Sorry, have to catch a bus I'll read the logs later night. +13:45 < deer> <peer> hi just a bug report +13:45 < jrandom> (as its cut down streaming lib test time by a factor of 5) +13:45 < jrandom> cool baffled, ttyl +13:46 < deer> <peer> when your net connection goes down, i2p dies +13:46 < dm> These are the kind of things that creep up on you, good to get them out of the way while the project is still lean. +13:46 < deer> * postman noticed this too a few days ago +13:46 < deer> <postman> one of my servers lost its link +13:46 < deer> <postman> for a few mins - after that i2p was good for a complete restart +13:46 < jrandom> dies, as in, the JVM stops, or the router stops talking to peers? +13:47 < jrandom> (it obviously stops talking to peers, i mean, after the net is back up, does it recover?) +13:47 < deer> <postman> jrandom: in my case jvm was still running - but no connection lead to success for about 15 minutes +13:47 < deer> <postman> jrandom: after that i restarted +13:47 < jrandom> hmm, ok, cool +13:48 < jrandom> thanks peer, postman. i'll do some debugging down there +13:48 < jrandom> what OSes, btw? +13:48 < deer> <postman> jrandom: np - wanted to write you a mail but forgeot +13:49 < deer> <postman> jrandom: Linux 2.4.recent - glibc2.3.recent jvm 1.4.05 +13:49 * jrandom suspects that this week will be the week of "break shit and make i2p handle it better" +13:49 < jrandom> word +13:50 < deer> <peer> jrandom: in my case the jvm went completely +13:50 < jrandom> did it say OutOfMemory or have any CRIT messages? or did it create a hs_* file inyour i2p install dir? +13:52 < jrandom> perhaps we could dig through the details later, after the meeting +13:52 < jrandom> does anyone have anything else on 2) core updates? +13:52 < jrandom> if not, on to 3) streaming lib +13:53 < dm> yeah +13:53 < dm> this increased latency +13:53 < dm> do you have an estimated % increase per hop? +13:53 < dm> we talking a couple % points or 30-40%? +13:53 < jrandom> none, its just some situations it didn't send through an outbound tunnel +13:54 < dm> so negligeable... 'kay +13:54 < dm> (on average) +13:54 < dm> 3) +13:54 < jrandom> 0% per hop, but its as if the peer you talk to has tunnels 1 hop longer than before (on average) +13:55 < jrandom> not many real visible updates for the streaming lib so far +13:55 < jrandom> things work pretty well, and i've been doing a bunch of benchmarks to track the progress during the recent memory updating +13:55 < dm> oh throughput numbers!!! +13:57 < dm> ping +13:57 < deer> <Natalia> . +13:57 < jrandom> well, it varied on the message size and per-hop latency injected, but preliminary throughput has been 2-5x faster +13:57 < jrandom> it has been CPU bound though +13:57 < dm> hmmm, not bad. +13:58 < dm> cpu at which end? +13:58 < jrandom> the big benefit is in the reduction of data retransmission and the virtual elimination of failure ;) +13:59 < jrandom> dm: these tests were done with the sim, injecting random delays per hop +13:59 < jrandom> (e.g. 400ms each time, or 1000ms, or 2000ms) +13:59 < dm> Is there some kind of priority scheme so that forwarding of messages of tunnels won't be too affected by people trying to download at 30k/s and maxing out their CPU? +13:59 < jrandom> (well, the *big* benefit is the sliding window and reordering, but reduction of retransmit is good) +14:00 < jrandom> not sure i understand +14:00 < dm> Like if I'm downloading porn, will I inject a 3s lag to anyone who's going through me in their tunnels. +14:00 < jrandom> (and the transfer rates were much higher than 30KBps, but again, this was local-only with random injected delays) +14:01 < dm> I'm just wondering what happens in general if someone is maxing out their CPU, as far as their contribution to the network is concerned. +14:01 < dm> I guess it's not specific to abusing the streaming lib. +14:02 < jrandom> you're not going to be maxing your CPU doing streaming, the CPU load was something i run into when using the local sim running a ton of routers on a single box +14:02 < dm> ah alright, I thought the cpu was maxed with one router trying to encrypt all the bits going down the pipe. +14:02 < jrandom> nah, encryption is ReallyReallyFast +14:03 < dm> coo' +14:03 < jrandom> ok, anyone else have any questions wrt the streaming lib progress? +14:03 < jrandom> if not, 4) mail.i2p progress +14:04 < deer> <jrandom> postman, you 'round? +14:04 < deer> <postman> yo :) +14:04 < deer> <postman> ok +14:04 < deer> * postman waves +14:05 < deer> <postman> well, gentlemen. Some of you may have noticed that we have finally implemented in/out services +14:05 < jrandom> [w00t!] +14:05 < deer> <postman> please reas www.postman.i2p/inout.html +14:05 < deer> <postman> please test the system out +14:06 < deer> <postman> baffled will deliver the 2nd official mx +14:06 < jrandom> word +14:06 < deer> <postman> right now i am working on IMAP implementation +14:07 < deer> <postman> this means a switch to maildir format soon +14:07 < jrandom> we'll need to recheck various clients for that though, right? +14:07 < deer> <postman> right now i am evaluating/testing +14:07 < jrandom> cool +14:07 < deer> <Natalia> why IMAP and not pop3 ? +14:07 < deer> <postman> yeah, and the serverside as well +14:08 < deer> <postman> Natalia: we have pop3 already +14:08 < deer> <postman> pop3 can be used of course +14:08 < deer> <postman> IMAP4 will make us more flexible for webmail systems (hopefully) +14:10 < deer> <postman> this is still open issue +14:10 < deer> <Natalia> okay. +14:10 < deer> <Natalia> you sounded like you were going to switch from pop3 to IMAP +14:11 < deer> <postman> no, of course not +14:11 < deer> <postman> jrandom: are there any news concerning locally run webmail? +14:12 < jrandom> not to my knowledge. i havent had time to look into it at all +14:12 < deer> * postman neither +14:12 < jrandom> there were those discussions of atmail, but they're closed source +14:12 < deer> <postman> mmh, yes +14:13 < deer> <postman> but something jspish ? +14:13 < jrandom> 'twould be a really great way for a volunteer to jump in and do some legword :) +14:13 < deer> <Natalia> well, I've added this description to gott.i2p/sites.html +14:13 < deer> * postman is completely unable to do research on that matter +14:13 < deer> <Natalia> for www.postman.i2p +14:13 < deer> <Natalia> postman runs i2p's first mail-service, providing free and anonymous pop3 and SMTP +14:13 < deer> <Natalia> accounts over i2p. Recently implemented is the ability to send and receive e-mails to and +14:13 < deer> <Natalia> from outside of the i2p network, marking the services of www.postman.i2p as a nifty +14:13 < deer> <Natalia> destination for any concerned e-mailer and soon a must-have, as mail.i2p e-mail accounts +14:13 < deer> <Natalia> become the norm for eepsite-authors. +14:14 < deer> <Natalia> sound good ? +14:14 < deer> <postman> thanks Natalia :) +14:14 < deer> <postman> jrandom: i think it's not a urgent issue +14:14 < deer> * Natalia curtsies :) +14:15 < deer> <postman> jrandom: maybe we pick up the webmail issue later again :) +14:15 < jrandom> agreed postman +14:15 < deer> <postman> that's all from my side , thanks :) +14:15 < jrandom> word, thanks postman +14:15 < deer> * postman curtsie too and sits down again +14:15 < jrandom> ok, anything else on that, or shall we move on to 5) BT progress? +14:16 < deer> <jrandom> dinoman: you 'round? +14:16 < dm> Yeah, I'm still waiting for BT to reactivate my ADSL +14:16 < jrandom> !thwap +14:17 < deer> <duck> dino has done some good work +14:17 < deer> <duck> with Ragnarok to fix some ends +14:17 < deer> <duck> so far it looks like the current problems are: +14:17 < deer> <duck> - SAM unreliability +14:17 < deer> <duck> - Python SAM library issues +14:17 < deer> <duck> - Incorrect usage of the Python SAM lib +14:18 < deer> <duck> - Correct handleing of destination instead of host/ip/port +14:18 < deer> <duck> once those are fixed it should work +14:18 < jrandom> cool +14:19 < deer> <duck> I think it is needed to take a little step back though +14:19 < deer> <duck> and agree on how to modify the protocol to properly handle destinations +14:19 < deer> <duck> it will be incompatible anyway, so better break it good +14:19 < jrandom> i concur +14:20 < jrandom> perhaps someone can mock up an overall plan of what needs to be done to various apps/components to get it working +14:20 < deer> <duck> each peer has an unique peer_id of 20 bytes +14:20 < deer> <duck> it is normally derived from the host/ip +14:21 < deer> <duck> I think that using the full destination is a bit much +14:21 < deer> <duck> what globally unique thing should we use? +14:21 < jrandom> SHA1(destination)[0:19] +14:21 < jrandom> perhaps? +14:21 < deer> <Ragnarok> first twenty bytes of the dest? :) +14:22 < deer> <duck> a sha1 hash is 20 bytes +14:22 < jrandom> first 20 bytes of the dest should be pretty random too, enough to deal with random clashes, but not to deal with hostile colisions +14:22 < jrandom> even better +14:22 < deer> <dinoman> if you lose the key how do peers find one another +14:22 < jrandom> a peer *is* a key +14:23 < jrandom> oh +14:23 * jrandom misinterpreted +14:23 < jrandom> the tracker must give peers the full destination, not the SHA1(destination) +14:24 < jrandom> is that the same peer_id in question? +14:24 < deer> <dinoman> i have fixed the php tracker to send the full key as the ip +14:24 < deer> <duck> actually the client generates the peer_id +14:24 < deer> <duck> (what do you mean with 'key'?) +14:25 < deer> <dinoman> destination +14:25 < dm> Sounds like a who's on first skit. +14:25 < dm> Use full sentences people! +14:26 < deer> <dinoman> ok fine :/ the tracker sends the Full destination as the ip +14:27 < jrandom> heh dont mind dm. sounds great +14:27 < deer> <dinoman> peer id is just for the trackers +14:27 < deer> <duck> maybe we could use #i2p-bt +14:28 < jrandom> what i think would be useful though is if you (or someone else) could perhaps draft up a list of modifications that'll need to be made +14:28 < deer> <duck> so no religious wars start each time the name of the snake is dropped +14:29 < deer> <dinoman> works for me +14:29 < deer> <dinoman> i don't war if it works it works +14:29 < jrandom> (e.g. "tracker sends e full destination as the IP", "client interprets the IP as the full destination", "torrent contains the tracker's destination in the field 'trackerDest'", etc) +14:29 < deer> <duck> definitly +14:30 < deer> <dinoman> jrandom you got it +14:31 < deer> <dinoman> this is the sample output of the tracker 8:intervali300e12:min intervali30e5:peersld2:ip50:klkjlkfsdjfkljkfdhjkddfsjkldsfjlkjfdlkjsfdl;kj;sdf7:peer +14:31 < dm> copy/pastes jrandom's sentence into notepad and saves as "draft.txt" +14:31 < cat-a-puss> will bt over i2p be intercompatible with other clients that are not over i2p? +14:31 < jrandom> cool dinoman +14:31 < deer> <dinoman> at ip50 you will see a junk key +14:32 < jrandom> cat-a-puss: yes +14:32 < deer> <dinoman> yes +14:32 < cat-a-puss> then we should talk +14:32 < jrandom> welcome to the weekly meeting! :) +14:32 < deer> <dinoman> it will need to be something like .i2ptorrent to make it live togeter +14:32 < deer> <dinoman> for filenames and links and what not +14:33 < jrandom> are you working on something similar cat-a-puss, or have some ideas for improvements? +14:33 < cat-a-puss> working on something similar +14:33 < cat-a-puss> in java +14:33 < jrandom> cool +14:34 < jrandom> is it necessarily java specific, or can some peers be in other langs? +14:34 < cat-a-puss> good question, I don't know how to work that sort of thing in java, I'll have to look into it +14:35 < deer> <duck> right +14:35 < deer> <duck> lets use ugha.i2p to write up some specs +14:35 < deer> <duck> . +14:35 < jrandom> or perhaps we need a "swarming data transfer" section in the forum so we can all discuss this stuff at our own pace? +14:35 < jrandom> or ugha.i2p, of course +14:36 < jrandom> (while we work through some bugs in the sam impl and libs :) +14:36 < deer> <duck> makes it all a challenge +14:37 < deer> <dinoman> hehe ok +14:38 < deer> <duck> ... +14:38 < deer> <duck> mo bt? +14:38 < deer> * dinoman gets back to work on Savane +14:39 < jrandom> http://ugha.i2p/SwarmingTransfer / http://ugha.ath.cx/SwarmingTransfer +14:39 < jrandom> word +14:39 < jrandom> ok, anything else on 5) BT progress? +14:39 < jrandom> or shall we hit 6) ??? +14:39 < jrandom> and ask dinoman how the Savane progress is coming? :) +14:40 < deer> * jrandom cracks whip +14:40 < deer> <dinoman> mail i am stuck on using the i2p mail system +14:40 < deer> <dinoman> i think i should just take the mail out +14:40 < jrandom> is there any way to tell it to use the SMTP server at a different port? +14:40 < jrandom> or is the problem authenticated SMTP? +14:41 < deer> <dinoman> auth +14:41 < protok0l> Uptime: 5d +14:41 < protok0l> ii own +14:41 < deer> <dinoman> it is not in the class Savane uses +14:42 < deer> <dinoman> i can put it in +14:42 < protok0l> i'm "Ident: pxEI" can someone tell me my rating +14:42 < jrandom> ok, i bet we can just get postman to set you up with a custom SMTP destination that doesnt require authentication +14:42 < dm> I give you a 6/10 +14:42 < dm> You could work on your ass a bit +14:42 < janonymous1> Whats savana +14:43 < jrandom> janonymous1: its like sourceforge +14:43 < deer> <dinoman> because i am looking at the I2P Public Domain Software Homepage in my browser now +14:43 < jrandom> w00t +14:45 < deer> <dinoman> that would be cool be what is being done on the server i don't want someone hacking me and the getting the info about the mail server +14:45 < deer> <dinoman> that is what bugs me +14:45 < jrandom> well, they wouldn't get any info on the mail server, they'd just be able to (at worst) spoof @mail.i2p +14:45 < janonymous1> Cool +14:46 < jrandom> but yeah, it'd be great to have authenticated SMTP support to prevent that +14:46 < jrandom> i dont know how much work that'd be though +14:46 < protok0l> well im glad i left my mailserver idea to postman +14:46 < protok0l> it seem more difficult than i imagined +14:47 < deer> <Ch0Hag> I wouldn't mind helping with that +14:47 < dm> protocol +14:47 < deer> <Ch0Hag> Got to do something. :-) +14:47 < deer> <dinoman> i will do auth :( it will take a little time but i will do it +14:47 < deer> <protokol> yes dm +14:48 < jrandom> see, you've got a volunteer already dinoman! :) +14:48 < deer> <protokol> maybe i could host a nessus server +14:48 < deer> <protokol> and tunnel it through TOR on my side +14:49 < deer> <Ch0Hag> Plus I need a good excuse to work on the rest of my network. +14:49 < deer> <protokol> and i shall dedicate myself to learning python +14:49 < janonymous1> 'the i2p software foundation'. I can see it now +14:49 < deer> <protokol> and how to correctly type +14:49 < dm> I shall dedicate myself to the pursuit of more money for myself and for those directly related to myself, who may be inclined to give me money in the near future. +14:50 < jrandom> ok, anyone else have anything to bring up for 6) ??? +14:50 < dm> 7) $$$ +14:51 < duck> Roger Dingledine (arma @ freenode) published a draft for a chapter of an upcoming O'Reilly book +14:51 < duck> http://freehaven.net/doc/wupss04/usability.pdf +14:51 < jrandom> ah, yeah, its pretty good +14:51 < duck> it is about anonymity and usability +14:51 < dm> chapter on usability? +14:51 < deer> <protokol> i can run the i2p software foundation +14:51 < deer> <protokol> lol +14:51 < duck> some interesting parts about negative imago +14:52 < deer> <protokol> give me the keys the the treasury +14:52 < duck> having good default +14:52 < deer> <protokol> NOW! +14:52 < duck> etc +14:52 < duck> . +14:52 < jrandom> and the importance of usability, even over security at times +14:52 < dm> protok0l: you're the user advocate aren't you? You should read that document. +14:52 < jrandom> 'k, anything else for the meeting? +14:52 < deer> <protokol> wow, im seeing 83 peers +14:52 < duck> now we know why there are so few known hidden sides on tor +14:53 < deer> <protokol> dm: i shall +14:53 < duck> arma is affraid for negative imago +14:53 < duck> . +14:53 < dm> "imago" ? +14:53 < duck> image +14:53 < deer> <duck> (psychoanalysis) an idealized image of someone +14:53 < dm> No mention of I2P in there :( +14:53 < duck> jrandom: aint we? +14:54 < jrandom> hm? +14:54 < dm> he means aren't we. He's dutch. +14:54 < duck> if some specific group now moves to i2p, +14:54 < duck> they could keep away much needed other users +14:55 < jrandom> oh, thats in there? i didnt see that +14:55 < duck> no, I am saying that +14:55 < duck> but it is in there too, more or less +14:55 < duck> ofcourse andy anarchist doesnt give a fuck +14:56 < jrandom> well, i do think there is room for both i2p and tor +14:56 < duck> yes +14:56 < duck> but what about early negative image on I2P +14:56 < deer> <Natalia> this is the reason I am forced to be a somewhat mundane female on this IRC channel +14:56 < protok0l> haha, when i get the word every major anarchist listserv and forum will hear about i2p within a day or 2 +14:56 < jrandom> oh, i dont give a flying fuck about that duck ;) +14:56 < deer> <Natalia> jrandom doesn't approve of got +14:56 < deer> <Natalia> *gott +14:57 < duck> jrandom: yeah, but well +14:57 * duck counts the amount of anarchy friendly regions on the globe +14:57 < deer> <Natalia> so I have to be Natalia, the loved female of the channel +14:57 < deer> <Natalia> ( lame ) +14:57 < duck> somalia? +14:57 < duck> I bet they have flying fucks there +14:57 < protok0l> Chiapas, mexica +14:57 < duck> but not friendly ones +14:57 < protok0l> mexiico +14:58 < deer> <Ragnarok> bah, you want to be feminized +14:58 < jrandom> duck: when it comes time to be more public, i'm certain we can put on a reasonable joe sixpack friendly face +14:58 < duck> k +14:58 < jrandom> will people do "bad" things with i2p? yeah +14:58 < dm> I think we should target joe beergut +14:58 < protok0l> good luck, i know gott is planning something +14:58 < protok0l> gott will destroy us +14:58 < duck> ok +14:58 < duck> . +14:58 < jrandom> the only way any worthwhile anonymity or security system can survive is to be content neutral +14:59 < deer> <Ragnarok> anonymous communication systems can only protect communication. They don't interfere with good old police work if someone actually *does* something. +14:59 < duck> just saying that some links placed on http://127.0.0.1:7657/index.jsp could be bad +14:59 < dm> I2P is about technology. +14:59 < deer> <Natalia> yes +14:59 < jrandom> true enough duck +15:00 < duck> and yes, the sitelist.html will turn into a TFE discussion thing all over +15:00 < jrandom> well, mmhmm +15:00 < deer> <Natalia> content neutrality is something I write about in the latest eeplog entry +15:00 < deer> <Natalia> http://gott.i2p/eeplog.html +15:01 < jrandom> this is, however, the power of interactive eepsites, like wikis +15:01 < jrandom> (e.g. having people register their site with a sitelist.py or whatever) +15:01 < deer> <Natalia> jrandom: do you support not support the idea of eepsite crawlers linking to illegal material, being linked from the frontpage ? +15:01 < deer> <Natalia> +or +15:01 < deer> <Natalia> if you were going to link to the sitelist +15:02 < duck> from a moral point I dont give a flying fuck either +15:02 < deer> <Natalia> jrandom: none of these are registered +15:02 < duck> but from an usability point I might +15:02 < deer> <Natalia> the script checks host.txt +15:02 < deer> <Natalia> *hosts.txt +15:02 < jrandom> from a nontechnical perspective, i support whatever the user community requires +15:02 < deer> <Natalia> so everyone gets added to the list if they have a domain +15:03 < deer> <Natalia> ugh, bras are so uncomfortable. +15:03 < protok0l> yup, creepy +15:03 < deer> <cervantes> have you _seen_ the user community? +15:03 < cat-a-puss> The simplist solution would be to simply link to search pages, Everyone knows how to use them, they provide fast access, and nobody sees for anything they did not ask for. +15:04 < deer> <cervantes> :) +15:04 < protok0l> gott is a serial killer, i know it. he will be the first to offer live murders via webcam on i2p +15:04 < deer> <Natalia> the user community consists of rather strange people. +15:04 < jrandom> good point cat-a-puss, we could just link to files.i2p +15:04 < deer> <Natalia> at the moment, I am forced to be a woman because the lead developer disapproves of the immoral behaviour of my other. +15:04 < duck> cat-a-puss++ +15:04 < deer> <Natalia> we are united through common adventure. +15:06 < BS314159> I'm not convinced this is a good idea, but the I2P license is certainly broad enough for people to spin off their own versions, differing only in the local link pages +15:06 < deer> <Natalia> well. +15:06 < deer> <cervantes> lets hope DrWoo can keep his indices free of corruption +15:06 < jrandom> certainly BS314159 +15:06 < BS314159> not versions. distributions. +15:06 < deer> <Natalia> files.i2p should be one link +15:06 < jrandom> BS314159: people can even edit their own local link page +15:06 < deer> <Natalia> and then there should be a yahoo-style internet directory link +15:06 < protok0l> most people will be wise enuf to use the official version +15:06 < jrandom> (in docs/readme.html) +15:07 < deer> <Natalia> search engines and internet directories serve different roles +15:07 < deer> <Natalia> this is why the directory is there in the first place +15:07 < deer> <Natalia> it has been requested as independent of a search engine +15:07 < BS314159> so if you want e.g. to target an anti-pornography demographic, find an anti-pornography maintainer who maintains a filtered default start page set +15:07 < protok0l> unless they are willing to search for backdoors in third-party versions +15:07 < deer> <Natalia> by people +15:07 < deer> <Natalia> so I think the search-engine is good +15:07 < jrandom> right BS314159 +15:07 < deer> <Natalia> but should not be the limit +15:07 < deer> <Natalia> search engine, internet directory, wiki, help page +15:07 < deer> <Natalia> perhaps. +15:08 < jrandom> we already link to fproxy.i2p, and we know what scary evil content they have on that site ;) +15:08 < BS314159> I'm not sure I'm on topic, but that seems possible. Is there an open-source content filter that any search-engine maintainers would be willing to implement support for? +15:08 < BS314159> I have a feeling I'm not on topic +15:08 < protok0l> is the meeting still on? +15:08 < jrandom> yes protok0l +15:08 < BS314159> sorry. (silences self) +15:08 < deer> <Natalia> jrandom: perhaps you shouldn't link to fproxy.i2p +15:08 < deer> <Natalia> it is almost always down +15:08 < jrandom> BS314159: i think a cntent filter in the search engine is excessive +15:08 < deer> <Natalia> it is down right now, it seems +15:09 < protok0l> it is +15:09 < deer> <Natalia> according to the recent run of the site-checking script +15:09 < jrandom> 'k +15:09 < jrandom> well, this has been a good discussion, lots of good ideas +15:09 < BS314159> not _the_ search engine. _someone_'s search engine +15:10 < deer> * Natalia smiles. +15:10 < deer> <cervantes> BS3: aol.i2p ;-) +15:10 < jrandom> ok, is there anything else for the meeting? +15:10 < deer> <cervantes> whoa...still in the meeting... +15:11 < deer> <cervantes> thought I'd missed that by an hour +15:11 < jrandom> nope, i was late +15:11 < jrandom> ok, if not.. +15:11 * jrandom winds up +15:11 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/114.rst b/i2p2www/meetings/logs/114.rst new file mode 100644 index 00000000..9f10489d --- /dev/null +++ b/i2p2www/meetings/logs/114.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 2, 2004 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/115.log b/i2p2www/meetings/logs/115.log new file mode 100644 index 00000000..bdd3fa46 --- /dev/null +++ b/i2p2www/meetings/logs/115.log @@ -0,0 +1,517 @@ +13:26 < jrandom> 0) hi +13:26 < cervantes> lets see the menu before we order :P +13:26 < jrandom> 1) 0.4.1.4 +13:26 < jrandom> 2) Streaming lib +13:26 < jrandom> 3) BT progress +13:26 < jrandom> 4) addressbook.py +13:26 < jrandom> 5) ??? +13:26 < jrandom> 0) hi +13:27 * jrandom waves +13:27 < Ragnarok> hi +13:27 * cervantes waves +13:27 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000485.html +13:27 < keysersoze> hi +13:27 <+polecat> 5) can be DHTs, like that bamboo thing? +13:27 < jrandom> (yeah, i'm late) +13:27 < jrandom> cool polecat +13:27 * polecat nips at fingers again! +13:27 < jrandom> ok, jumping into 1) 0.4.1.4 +13:28 <+Ch0Hag> 0.4.1.4 seems to die more than it should +13:28 <+Ch0Hag> like - at all +13:28 < jrandom> die? +13:28 <+Ch0Hag> Though there's a chance that's kaffe's fault. +13:28 < jrandom> drop your irc connection, or restart the router? +13:28 < jrandom> ah, you're on kaffe? +13:29 <+Ch0Hag> the router +13:29 <+Ch0Hag> I am. +13:29 <+Ch0Hag> Someone has to be :) +13:29 < jrandom> on kaffe i've had to double the defaul mem usage (give 'er a -mx128m on startup) +13:29 <+polecat> GAH! No wonder! I had hawk on ignore. +13:29 < jrandom> well, we've got at least 3 people on kaffe these days +13:30 < jrandom> other than that, though, how is 0.4.1.4 going for y'all? +13:30 * polecat is on kaffe... doesn't know of a better JVM at the moment. +13:30 < jrandom> early reports were good, but i havent heard much lately +13:30 <+Ch0Hag> I had 64, shall try 128 +13:30 < Ragnarok> seems good +13:30 < keysersoze> jrandom: No major problems here +13:30 <@duck> latest major irc outage was mine +13:30 <+Ch0Hag> And yes, much of it was OOMing +13:31 <@duck> otherwise I think it is a bit unstable (since my bw enabling), but I dont have proof +13:31 < jrandom> the throttling on your machine is a bit of a choke point, as e.g. each message you receive is something like 20+ messages that have to be sent out +13:32 <@duck> ah +13:32 < jrandom> but i agree, irc has been bumpy +13:32 < cervantes> 0.4.1.3 has always been rock solid on my ibm jvm, so I've avoided upgrading at this stage +13:32 < cervantes> (22 days uptime) +13:32 < jrandom> nice cervantes +13:32 < jrandom> duck: [insert comment describing hopes for new streaming lib here] +13:33 < cervantes> baffled's irc server has been a little less bumpy +13:33 < jrandom> word, thats a good metric +13:33 < keysersoze> cervantes: What version does he run? (Do you know?) +13:33 < ant> <dm> will streaming lib have an effect on IRC, or are the messages too small anyway? +13:33 <@duck> I have been a good duck this week, so I'll up the limit a bit +13:33 < jrandom> lemmie check keysersoze +13:33 < jrandom> :) +13:33 <+polecat> I've got 11 hours uptime. ;.; +13:34 < jrandom> keysersoze: 0.4.1.4 +13:34 < keysersoze> jrandom: ;) But one could ask him here when he's around +13:34 < keysersoze> ok +13:34 < jrandom> dm: the new streaming lib will improve resiliance and address failures, but obviously won't improve irc throughput +13:34 < jrandom> (router versions are published in the netDb, and i know which routers are his) +13:34 < ant> <dm> that's good +13:35 < jrandom> ok, do we have anythingelse for 0.4.1.4? +13:35 < jrandom> if not, swinging briefly over to 2) streaming lib progress +13:36 < keysersoze> no +13:36 < jrandom> as mentioned in the notes, more news when its available :) +13:36 <+polecat> What would we be able to do with the streaming lib that we would not be able to do before it exists? +13:36 < Ragnarok> download large files quickly +13:36 < Ragnarok> and DOS the network :) +13:36 < jrandom> polecat: transfer arbitrarily large files, transfer at > 4KBps +13:37 <+Ch0Hag> and/or reliably? +13:37 < jrandom> Ragnarok: *not* dos'ing the network is what i'm working on now ;) +13:37 <+protokol> i've noticed over time that if i lose a connection on eepIRC, the reconnects always fail, but if i stop it for a few minutes it connects just fine +13:37 <+polecat> It would increase the transfer rate? o.O +13:37 < jrandom> polecat: yes. the current streaming lib uses a fixed 1 packet window size - waiting for an ack before sending the next message +13:37 * polecat nods to protokol, seems so. +13:38 < ant> <dm> The streaming lib will allow a new class of TCP-based applications to be usable on I2P. +13:38 < Ragnarok> jrandom: ah, good. I've been a little concerned about that :) +13:38 < ant> <dm> That's the marketing version. +13:38 < jrandom> let me just say that throughput looks promising with the new lib. +13:39 < jrandom> heh dm +13:39 < keysersoze> jrandom: Like the extension to normal TCP, where the sending machine will keep sending even if it hasn't receivved an ACK yet, up to a certain number? +13:39 <+polecat> jrandom: Ah, I see how that could be compromising... +13:39 < jrandom> right keysersoze, up to a (sliding) window size +13:39 < jrandom> (doing all that congestion control / avoidance stuff) [/arm waving] +13:40 <+polecat> I also see how it might have congestion problems. If many packets are sent after a connection is dropped. +13:40 < cervantes> will be interesting to see some benchmarks comparisions for i2p BT over the new streaming lib and the old not-so-streaming lib +13:40 < jrandom> aye cervantes +13:41 < jrandom> polecat: thats the biggest danger, preventing a network flood, which is why we're deploying cautiously +13:41 < ant> <dm> I have a bug to report. Someone remind me when we hit 5. +13:41 < cervantes> jrandom: from an application point of view, how transparent will the switch over be? +13:42 < keysersoze> polecat: Do the current plans implement a "slow-start" idea, where the window will be 1 first, and then cautiously increased to 2, and ONLY if that works well, to 3, etc. Up to a certain maximum? +13:42 <+polecat> Does 0.4.1.4 use the streaming lib, or has it not yet been deployed? +13:42 < jrandom> cervantes when 0.4.2 is out, no code changes. you can even use the streaming lib now if you want, if you specify a magic flag in the environment :) +13:42 < cervantes> polecat: that will be with us on 0.4.2 +13:42 < ant> * dm everyone rushes towards jrandom. +13:42 < jrandom> its with you now - see streaming.jar +13:42 < jrandom> but disabled by default +13:42 < ant> <dm> "flag! flag! flag!" +13:43 < keysersoze> jrandom: Ow come on, spoil us and tell which env var ;) +13:43 < jrandom> however, the streaming lib is *NOT BACKWARDS COMPATIBLE* +13:43 < jrandom> aka you can't use IRC with it +13:43 < cervantes> I have an early .1.3 remember ;-) +13:43 < jrandom> unless duck runs a seperate newStreamingLib destination +13:43 <+polecat> Yeah... probably best to switch in sync then, not individually. +13:43 < jrandom> yup +13:43 <+Ch0Hag> I think this flag is one of those "if you can't find it, you don't need it" ones. +13:43 < ant> <dm> duck: for the love of god, do as you're told!!! +13:43 <+Ch0Hag> Like most of GCCs... +13:43 < jrandom> right Ch0Hag :) +13:44 < jrandom> dm: still some other things to be tested +13:44 < jrandom> e.g. this morning mule was helping out test with FUQID +13:44 < keysersoze> jrandom: Does that influence any of the hosts.txt keys for existing I2P destinations? +13:44 < mule> missed the meeting. end of daylight savings :(. +13:44 < jrandom> (and FUQID does eeevil things :) +13:45 < jrandom> heya mule, me too :) you're just in time +13:45 < ant> <dm> mule: you haven't missed section 5) ????? +13:45 <+Ch0Hag> Oh speaking of fuqid, is there news on stasher? +13:45 < ant> <dm> for all you know, ???? might be: GOTO 1 +13:45 < jrandom> keysersoze: no, the streaming lib isn't involved in that part of things +13:45 <+Ch0Hag> Or is that a big enough topic to wait until 5? +13:45 < jrandom> Ch0Hag: no one has heard anything from aum since september, and no one else is doing anything on stasher. +13:46 < jrandom> (but there is other DHT stuff to discuss in 5)??? i hear) +13:46 <+Ch0Hag> Oh. +13:46 <+Ch0Hag> Bummer. +13:46 <+Ch0Hag> The freenet devs didn't have their competition ... removed did they? +13:46 <+Ch0Hag> :) +13:46 < jrandom> heh +13:47 <+polecat> The first application of assassination politics. x3 +13:47 <+Ch0Hag> Anyway I have nothing else, so I shan't butt in again until 5 +13:47 < jrandom> ok, there's lots going on in the streaming lib, but discussion will have to wait for later +13:47 < jrandom> unless there's somethingelse, we can move to 3) BT progress +13:47 < cervantes> </evasion> +13:48 < ant> <dm> Doesn't everyone wish jrandom adopted the toad deployment process? +13:48 < ant> <dm> Build 3435: streaming lib attempt +13:48 < jrandom> duck: ping? +13:48 < ant> <dm> Build 3436: streaming lib attempt 2 +13:48 <@duck> pong +13:48 < ant> <dm> Build 3436: streaming lib attempt 3 +13:48 < jrandom> be nice +13:48 * duck takes the mike +13:48 < Ragnarok> no, no we don't +13:48 <@duck> dinoman, Ragnarok and me have been working on the BT client. +13:48 <@duck> - BT protocol analysed and changes specified on http://duck.i2p/i2p-bt/txt/i2p-bt_protocol.txt +13:48 <@duck> - dino modified phpbt, info at http://duck.i2p/i2p-bt/txt/tracker.txt +13:48 <@duck> dino got the client to talk with the tracker, R and me have improved it a bit. +13:48 <@duck> the whole tracker <-> client stuff worked +13:48 <@duck> but we got stuck at the python sam library... +13:49 <@duck> Connelly has been helping, but also busy +13:49 <@duck> and aum is missing +13:49 <+polecat> I'm still stunned BT can work at all on i2p... +13:49 <@duck> so I threw out pysam, reimplemented BT's RawServer.py and now it kinda works. +13:49 < jrandom> (w00t!) +13:49 <@duck> hot news: channel #i2p-bt (especially topic with latest release info) +13:49 <@duck> now I am working at adding a lot of logging support, to catch some little flaws +13:50 < Ragnarok> it's much nicer than the original RawServer.py +13:50 < peer> duck: so is it ready for beta testing? +13:50 <@duck> (for example during the EndGame it has to timeout and retry to get the last bits) +13:50 <@duck> peer: yup +13:50 <@duck> a little point of discussion: +13:51 <@duck> so far it is python 2.2 (and up) compatible +13:51 <@duck> (seems to be the same for bittorrent itself) +13:51 <@duck> the logging stuff needs 2.3 though... +13:51 < cervantes> yus indeed +13:51 <@duck> how bad do you think that is? +13:51 < jrandom> my freebsd and linux boxen have 2.3 +13:51 < ant> <dm> bad? +13:52 < jrandom> (though they were installed within the last year) +13:52 < Ragnarok> are there any major distros still shipping 2.2? +13:52 <@duck> debian-stable still seems to ship 2.2, last time I checked +13:52 < jrandom> ah, i'm on debian unstable +13:52 <@duck> but then again that is hardly a surprise +13:52 <+Ch0Hag> Debian ships 2.3, 2.2, 2.1 and possibly 2.0 +13:52 <+Ch0Hag> Together. +13:52 < Ragnarok> except Debian stable, I think... +13:53 <+Ch0Hag> That's what I'm unsure about. +13:53 < jrandom> it'd be nice to have 2.2 support - are there no good logging libs for it? +13:53 < Ragnarok> silly debian +13:53 <@duck> jrandom: you could bundle the 2.3 lib +13:54 < Ragnarok> can logging simply be made optional? +13:54 <@duck> I guess +13:55 < jrandom> well, its really a coder-productivity-tool, so whatever works best for the people coding +13:55 < ant> <dm> we can worry about this when I2P + BT becomes popular. +13:55 < keysersoze> For whom is this logging necessary? Not for the end-user, I guess, so when deploying, it shouldn't matter that logging isn't possible on some platforms, no? +13:55 < ant> <dm> by then maybe 2.3 is standard +13:55 < jrandom> 2.2 support would be nice, but i dont think it'd be that bad if 2.3 were required +13:55 < cervantes> duck: so the tracker's peer announce list can be made to spew out i2p destinations instead of machine ips? +13:56 <@duck> ok, we'll try to abstract the logging lib, with 2.2 use stdout +13:56 <@duck> cervantes: http://duck.i2p/i2p-bt/diffs/phpbt-i2p.diff +13:56 < jrandom> keysersoze: you want logging deployed on the clients machines so that if/when bugs arise, the dev can get detailed logs +13:56 < jrandom> word duck +13:56 < cervantes> ta +13:56 <+Ch0Hag> heh if anyone's still interested, Woody has python 1.5, 2.0 and 2.1 +13:56 <+Ch0Hag> :) +13:57 <@duck> heh +13:57 <@duck> ok, in that case I say require 2.3 +13:57 <@duck> and fuck woody +13:57 < cervantes> think mine is tuck on 1.5 and 2.2 +13:57 < jrandom> yeah, no need to deal with 2.1 +13:57 < cervantes> (upgrade time) +13:57 < jrandom> heh +13:57 <+Ch0Hag> That's the opinion of most Debian users, too +13:58 < Ragnarok> addressbook.py requires 2.3 +13:58 <@duck> there are some interesting sub projects: +13:58 < jrandom> ah ok cool Ragnarok +13:58 <@duck> researching the optimal settings for i2p +13:58 <+polecat> That little thing requires 2.3? +13:58 < keysersoze> jrandom: I agree, but on a small net like now (~100 peers), it's not a problem to have some beta-testers upgrade to 2.2 or 2.3. And once the most blatant bugs are stamped out, the new "real" endd-users shouldn't really need logging. So what I'm saying is: The logging is no problem at this stage, so we agree ;) +13:58 < cervantes> when I was pulling apart BT a year or so back, this machine was pushing 6mb/sec through the tracker at times... +13:58 <+polecat> Weird... 2.2 must be practically crippled then. +13:58 < Ragnarok> 2.3 has better urllib proxy support +13:58 <@duck> porting the standard bt tracker too +13:58 < cervantes> I mean the seed +13:59 < Ragnarok> it could work on 2.2, but it'd be too much effort :) +13:59 <+polecat> Ah that would be important, right. +13:59 < jrandom> duck: researching the optimal settings will be tough until 0.4.2 comes out +13:59 <@duck> right +14:00 < jrandom> porting the tracker would be great though. do you have the tools for creating the .torrent implemented, or did you do that manually? +14:00 <@duck> whut? +14:00 < cervantes> the client has tons of nice tweaks for peer takeup rates, timeouts, min/max peers etc +14:01 < cervantes> jrandom: that shouldn't need any modification I think +14:01 < jrandom> duck: the .torrent references the i2p destination of the tracker, right? +14:01 <@duck> right now we ship: btdownloadheadless.py + btmakemetafile.py + btshowmetainfo.py +14:01 < jrandom> or does it reference the name? +14:01 < cervantes> it's just a url and a bunch of sha1 hashes +14:01 <@duck> though btmakemetafile.py and btshowmetainfo.py are not modified +14:01 < jrandom> "a url" is the tough part :) +14:02 <@duck> so you can use other tools +14:02 <@duck> its http://duck.i2p/phpbt/announce.php now +14:02 < jrandom> ok, cool +14:02 <@duck> guess you can use http://i2p/bigbase64/announce.php +14:02 <+protokol> are their plans for other clients to support eepTorrent? i like azureus +14:02 <@duck> plenty +14:02 < cervantes> jrandom: the early version I looked at did no url validation on the announce string +14:03 < ant> <dm> what does eep stand for again? +14:03 < cervantes> you could put anything in there +14:03 < jrandom> hmm, worth checking to see if that works duck ( in case phpbt does stupid url rewriting, etc) +14:03 < cervantes> dm: look in the forum glossary +14:03 <@duck> maybe its time for an i2p-bt forum? +14:03 < keysersoze> duck: Especially once new users, that don't have a "registration" in hosts.txt, want to host trackers, it _must_ be possible to have a base64 iin theer +14:03 <+Ch0Hag> Eye Eye Pee? +14:03 < jrandom> that'd be cool duck +14:03 <@duck> (forum section on forum.i2p) +14:04 < ant> <dm> cervantes: that was helpful! +14:04 < cervantes> duck: yeah no probs +14:04 <@duck> keysersoze: it will be investigated +14:04 < jrandom> still, as is its pretty bloody cool +14:05 < jrandom> the 4KBps per peer isn't really that much of a problem either +14:05 < ant> <dm> what time is it? "There's a clock just two blocks down the road" +14:05 < cervantes> moving forward oerhaps we should set up a seperate forum space so people can publish files alla suprnova +14:05 <@duck> eeprnova +14:05 < jrandom> cervantes: with reviews, etc :) +14:05 < keysersoze> jrandom: Will the transition to streaminglib require large changes to the current python I2P-BT code? +14:05 <+polecat> I sure never get more than 4KBps even on IPv4 bittorrent streams... +14:05 < peer> would be good if there were a command line argument for setting the i2p server address, so you can run it from other machines on a network +14:05 < jrandom> (but i think that'd be best left outside of the forum.i2p, perhaps) +14:06 < jrandom> keysersoze: 0 changes +14:06 <@duck> mind you that i2p-bt trackers will scale a lot worse +14:06 <@duck> since they have to send bloaty big keys +14:06 < Ragnarok> polecat: you must be natted +14:06 < keysersoze> polecat: ((OT) try the firefox torrent of today ;)) +14:06 < cervantes> jrandom: yup. +14:06 <@duck> where the normal trackers are recently modified to only send 6 bytes / peer +14:06 < jrandom> peer: i2p server address? +14:07 < jrandom> peer: i use the i2p-bt with my SAM bridge locally accessing a remote router +14:07 < jrandom> oh, but it'd be nice if there were flags to set the SAM bridge location & eep proxy location in the CLI, yeah +14:07 < peer> jrandom: yep +14:07 < keysersoze> duck: Can we compress the host-key? (Just asking...) +14:08 < peer> with one cli arg +14:08 < jrandom> (rather than remodifying the code after every release :) +14:08 <@duck> keysersoze: using binary instead of base64 will shrink it a bit +14:08 <@duck> like 15% +14:08 <@duck> no worth it +14:08 < keysersoze> duck: I agree. +14:09 < ant> <dm> cervantes: where is this forum glossary? I don't see anything at http://forum.i2p.net/ +14:09 < Ragnarok> could hostnames be used? +14:09 < jrandom> Ragnarok: hostnames are not globally unique +14:09 <@duck> Ragnarok: dont want to go there +14:09 < cervantes> dm: only shows up for reg'd users +14:10 < ant> <dm> cervantes: oh excellent! I'll look for eep on google then! +14:10 < Ragnarok> fair enough +14:11 < cervantes> dm: it's a phoneme for IIP +14:11 < cervantes> is the word on the street +14:11 < jrandom> ok, y'all are doing tremendous work on the bt side of things, and i look forward to hearing (and using) more :) +14:11 < ant> <dm> cervantes: not an acronym? +14:12 * cervantes has 1/2 of a terabyte of movies and tv shows to share +14:12 < jrandom> do we have anything else wrt i2p-bt to discuss? +14:12 < cervantes> dm: not that I've heard +14:12 <@duck> (dont forget #i2p-bt) +14:12 < jrandom> yeah, #i2p-bt, finally an incentive for people to move from freenode :) +14:12 < ant> <dm> alrighty. Thank you sir. +14:13 <+Ch0Hag> As if this Great network wasn't incentive enough already... +14:13 < jrandom> ok if not, shall we move on to 4) addressbook.py +14:13 < jrandom> Ragnarok: wanna give us the run down? +14:13 < Ragnarok> whee +14:14 < Ragnarok> hm, ok. addressbook.py is a first stab at a subscribable address book system. +14:14 < Ragnarok> It's pretty ugly at the moment, but it works +14:14 < Ragnarok> you can get it at ragnarok.i2p +14:14 < peer> can i just make a suggestion re: naming? i think the best method would be for the links between eepsites to use base64, but let people create their own bookmark names for sites, rather than having any centralised naming system +14:14 < Ragnarok> um... +14:14 < Ragnarok> any questions? +14:15 <+postman> Ragnarok: define ugly :) +14:15 < jrandom> Ragnarok: kickass +14:15 < ant> <dm> jrandom: not a question +14:15 <+polecat> What were we talking about again? @.@ +14:15 < peer> sort of like the bookmarks on the front page of the freenet web interface, but instead with urls +14:15 < cervantes> Ragnarok: is it all command line, or is there a gui? +14:15 < Ragnarok> read it, it's ugly :) +14:15 < jrandom> peer: agreed, though we need author tools +14:15 < cervantes> there weren't any screenies so I lost interest and went away ;-) +14:15 < jrandom> peer: though the ?i2paddresshelper helps +14:15 <+postman> Ragnarok: ok, thanks - i will check it out +14:16 <+polecat> Bah, GUIs are for soccer moms! +14:16 < Ragnarok> it's all command line. It's designed to be run as a daemon. It doesn't run as a daemon on windows yet, but that's my next project. +14:16 < Ragnarok> aside from the cli tool, all interactions are through config files. +14:17 < jrandom> perhaps the next step in the namign field is a web interface for managing the entries and subscriptions? +14:17 < cervantes> are you basically syndicating your hosts file then? +14:17 < Ragnarok> yes +14:17 < cervantes> right...cool +14:17 < Ragnarok> web interface would be great. I'm not writing it, though :) +14:17 < jrandom> with merges and conflict management +14:18 <+polecat> What is the conflict management, besides yelping about it in the log? +14:18 < jrandom> yeah, the engine itself is Good Stuff, maybe we can get someone else to jump on the web side of it :) +14:19 < Ragnarok> none. If you want to resolve a conflict, you do it by hand :). Though, it is a bit easier now. +14:19 < jrandom> polecat: yelp & never overwrite an existing entry afaik +14:19 < jrandom> (er, what he said) +14:19 < cervantes> it would be nice as a sidebar plugin for firefox... +14:19 <+polecat> Yes, that's what I had thought. +14:19 < cervantes> that's something I could work into my i2p toolbar +14:20 < Ragnarok> user changes are never overwritten, so it's reasonably secure against attack +14:20 < jrandom> and you should only subscribe to relatively trustworthy peers +14:20 < Ragnarok> indeed +14:20 < cervantes> maybe a feature to lock entries? +14:20 < cervantes> (ie move them to userhosts) +14:21 < Ragnarok> entries are are never modified +14:21 <+polecat> I like the concept of a myhosts.txt file for entries you want to endorse yourself. +14:21 < cervantes> Ragnarok: ah sorry, so you said +14:22 < Ragnarok> myhosts.txt is a dirty hack to get around a race condition, but for some reason everyone likes it as an interface thing :) +14:22 < jrandom> if people are interested, there are ways to get the i2ptunnel / sam / etc to read from more than just hosts.txt and userhosts.txt +14:22 < jrandom> (but only if there's a good solid reason to do so) +14:22 < cervantes> Ragnarok: you were meant to pretend that was intentional ;-) +14:23 * duck suggest abstracting away from hosts.txt / userhosts.txt +14:23 <+polecat> My perl version of addressbook.pl supports the myhosts.txt thing. +14:23 < Ragnarok> yeah, that will be part of the big rewrite :) +14:23 * polecat notes to duck, you'd have to modify i2ptunnel and sam to do that. +14:23 < Ragnarok> first, I want to get feature parity on windows, though. +14:24 < jrandom> right duck, as it would have been nice for 0.4.2 if we could flag different destinations as "oldLib" and "newLib" (etc) +14:24 <@duck> polecat: you could write the final result to something called 'hosts.txt' +14:24 < cervantes> ideally you want a hierachical mini-database of local addresses you can catagorise +14:24 <@duck> but use some other structure towards the user +14:24 <+polecat> The final result goes to userhosts.txt +14:24 <+polecat> And also a file called "hosts.txt" on the eepsite that is not the system hosts.txt. +14:24 <@duck> which is confusing :) +14:25 < Ragnarok> I like to be as confusing as possible :) +14:25 < MrEcho> hope to have the dns done by the end of the month +14:25 <@duck> ok, then let the name depend on the checksum of the content +14:25 < cervantes> addressbook.txt? :) +14:25 < Ragnarok> the published address book is just called hosts.txt, because that's what it is on dev.i2p +14:25 <+polecat> It's possible to call Ragnarok's hosts.txt file something else. People just have to subscribe to that other filename. +14:26 < Ragnarok> true, it's a configuration option +14:26 <+polecat> i.e. like going http://polecat.i2p/addressbook instead of http://polecat.i2p/hosts.txt +14:26 < MrEcho> fyi, my dns doesnt touch the hosts file .. just like a real dns +14:27 <+polecat> Oh yeah, there's that too. >.< +14:27 <@duck> my dns causes world peace +14:27 < jrandom> MrEcho: it might be worthwhile to explore interoperability +14:27 <+polecat> There's /etc/hosts, jrandom's hosts.txt that i2ptunnel and sam use, and now the hosts.txt published by Ragnarok. +14:28 < Ragnarok> I don't think anything that doesn't resolve names locally will ever perform acceptably over i2p, but you're welcome to prove me wrong :) +14:28 < mule> hostile environment :) +14:28 < MrEcho> i could make it update the hosts text, but i was hoping to add something in other code +14:28 < jrandom> there is some code in cvs (under apps/myi2p) for loading/storing address book entries with the data posted to that feb email, if anyone is interested ;) +14:29 <+polecat> ? +14:29 < MrEcho> already took a look jr +14:30 < jrandom> polecat: http://forum.i2p.net/viewtopic.php?t=141#419 +14:30 <+polecat> You mean under apps/myi2p/java/src/net/i2p/myi2p +14:30 < jrandom> well, yeah, if you want to get specific ;) +14:30 <+polecat> More like hideously redundant. ;3 +14:31 < jrandom> cool MrEcho, though i'm suggesting that sort of file format for other naming systems too, if people are going to consider replacing hosts.txt +14:31 < jrandom> polecat: with good reason (and imho there's no redundancy in that pathname ;) +14:31 < Ragnarok> cool. I'll have a look +14:32 < ant> <dm> at least it doesn't say internet three times in there anymore +14:33 < jrandom> it'd have to be implemented as a net.i2p.client.naming.NamingService as well - something to load from that local db, but that shouldn't be too hard +14:33 <+polecat> Eek! No, no noo MX records... no CNAME... +14:33 < jrandom> having multiple destinations per name is a good idea though +14:33 < ant> <janonymous2> Im partial to an address book/ dns hybrid +14:34 < jrandom> an address book is a domain name system :) +14:34 <+polecat> jrandom: How many times did you have to call it myi2p? And how necessary is it to call it i2p if it's already called myi2p? And is there any question whether or not that mess is a thing of java? +14:34 < jrandom> polecat: not all myi2p code will be in java. +14:34 <@duck> go back to your cave you perl troll :) +14:34 <+polecat> I agree that it's all necessary, not blaming you jrandom, but blaming java and ant. +14:35 < jrandom> polecat: and i2p's codebase is unique under the net.i2p namespace, as we don't control the net.myi2p namespace :) +14:35 * polecat grunts and crouches under the bridge. +14:35 < ant> <dm> polecat: it's called OCD +14:35 < jrandom> heh +14:35 < jrandom> its called software engineering ;) +14:36 <+polecat> Yes, but why put everything in a directory structure parroting the namespace? +14:36 <+polecat> Just specify like... in the file "This file is namespace net.i2p" +14:36 < jrandom> but anyway, anything else on Ragnarok's kickass naming system? :) +14:36 <@duck> it kicks ass +14:36 < Ragnarok> thank you :) +14:36 <+polecat> Asseth Kickius. +14:36 < jrandom> polecat: there are 1340 java files in i2p +14:37 <@duck> I was _shocked_ when I wanted to visit an eepsite and the host was already propagated +14:37 < Ragnarok> hehe +14:37 < jrandom> :) +14:37 <+polecat> Well, not saying it needs to be squashed all in one place. 1340 files seems an awful lot though, isn't there any redundant code in there? o.O +14:38 < Ragnarok> does anyone know a command to kill a windows process by pid? +14:38 <@duck> like TCP stack reimplementations? :) +14:38 <+polecat> Not to mention fully functional web servers. c.c +14:38 < jrandom> heh +14:38 < jrandom> oh, lemmie skip the jetty code.. +14:39 < keysersoze> (91 peers on the net now!) +14:39 < ant> <dm> ragnarok: kill +14:39 < jrandom> ok, 389 in router/ and core/ +14:39 < Ragnarok> what versions does that exist on? +14:39 <+polecat> That's still a lot for a lousy router... but considering the all and everything not too bad. +14:39 < ant> <dm> not sure... Running XP here. +14:39 < cervantes> Ragnarook: only if you have the support cd files installed +14:40 < Ragnarok> ah +14:40 * duck refocuses +14:40 < cervantes> Ragnarok: otherwise download sysinternals pskill +14:40 < jrandom> ok, anything else for 4) addressbook.py, or shall we move on to 5) ??? +14:41 < cervantes> Ragnarok: http://www.sysinternals.com/ntw2k/freeware/pstools.shtml +14:41 < jrandom> ok, 5) it is +14:41 < Ragnarok> neat, thanks :) +14:41 < jrandom> polecat: iirc you wanted to bring up bamboo-dht? +14:41 < MrEcho> ? meeting right now +14:41 <+polecat> :chants: DHT DHT USA USA~/o +14:42 <+polecat> Yes indeed. I'm just looking something up... +14:42 < jrandom> yes MrEcho +14:43 <+Ch0Hag> 5? +14:43 < jrandom> 5) ??? +14:43 < MrEcho> heh +14:43 <+Ch0Hag> ooh yes, I've found an irrelevant semantic bug +14:43 < jrandom> sup Ch0Hag? +14:43 <+polecat> There are 79 java files in bamboo source. There are 253 files total. +14:44 <+polecat> The entire project takes 4.6 megabytes in source and support files, before building. +14:44 < jrandom> yikes +14:44 <+Ch0Hag> in /netdb.jsp, 'our' information is given port first, whereas other peers are given host first +14:44 <+Ch0Hag> On the Addresses line +14:44 < jrandom> have you played around with it polecat? +14:44 < jrandom> Ch0Hag: the ordering is arbitrary +14:45 <+Ch0Hag> And 0.4.1.4 has been up for an hour with 128MB under Kaffe +14:45 <+polecat> I haven't had much of a chance. I played around with circle, and got a nifty graphical representation of a PGP public key, but not bamboo yet. +14:45 < ant> <dm> ah yes, ch0hag's insignificant bug report reminded me! +14:45 < ant> <dm> on the config page it says "you should either use a service like dyndns or leave the hostname blank. If you leave it blank, your router will autodetect the 'correct' IP address by asking a peer" +14:45 <+Ch0Hag> It seems to be host/port on all of them +14:45 < MrEcho> Uptime: 54h Memory: 23,506KB +14:45 <+Ch0Hag> But hey +14:45 <+Ch0Hag> It's not like it really matters. +14:46 < ant> <dm> which is great for me, since I have a dynamic IP address and have been waiting for this feature for some time, but when I blank and hit save, it automatically fills the box again with an (incorrect) IP +14:46 < cervantes> polecat: do you have a url? +14:46 < ant> <dm> Cheers! +14:47 < jrandom> hmm dm, it doesnt honor you setting it to empty? +14:47 < jrandom> thats definitely a substantial bug +14:47 <+polecat> Yes, moment please. +14:47 < Ragnarok> it would be nice if it only recommended filling in the box if you have a real, static hostname. Or if the box wasn't there... +14:47 < jrandom> Ch0Hag: kaffe typically keeps a steady size +14:47 <+polecat> http://bamboo-dht.org/ +14:48 < jrandom> Ragnarok: i'm considering removing that box altogether, leaving it for the hackers to add on /configadvanced.jsp +14:48 < ant> <dm> I only care because the instruction paragraph makes me feel like na idiot when I can't get it to blank ;) +14:48 < cervantes> polecat: ta +14:48 <+Ch0Hag> dm: It's clearly an intelligence test. +14:48 <+Ch0Hag> If you can make it stay blank, you pass. +14:48 <+polecat> I also notice bamboo seems to compile with jikes and the kaffe jar in approximately 30 seconds. +14:48 <+polecat> Uses some weird variables though, JAVAC and JAVAHOME instead of JAVA_HOME +14:49 < Ragnarok> jr: I think that's a great idea. At this point, it's a bit like a newbie trap. +14:50 < cervantes> dm: do you click the save button, or hit enter? +14:50 < ant> <dm> click save +14:50 < ant> <dm> * Updated bandwidth limits +14:50 < ant> <dm> * Configuration saved successfully +14:50 <@duck> polecat: do you plan to take a closer look at it? +14:51 <+polecat> I do indeed. bamboo seems like the best candidate for porting over i2p, and the most "together" DHT project I see out there. +14:52 <+polecat> The important thing is whether it "works" or not of course. +14:52 < jrandom> bah, who needs functionality, its all about buzzword compatability! +14:53 < jrandom> please keep us updated on how it goes +14:53 < jrandom> (as i agree, the project does look promising) +14:53 <@duck> probably most important is what it offers for transport level modifications +14:54 < ant> <janonymous2> Whats the shtick on bamboo? +14:54 < jrandom> aye, whether it requires NIO channels or uses plain sockets +14:54 < cervantes> heh... bamboo news: "5 Aug Bamboo Now 100% Pure Java...uses Berkely DB Java Edition" "4 Nov Bamboo No Longer 100% Pure Java...BDB Java sucked..back to C"" +14:54 < jrandom> (though we /could/ write NIO channels for i2psocket, it'd take some work) +14:54 <+polecat> jrandom: Go back to your cathedral, java gargoyle! X3 +14:54 <+polecat> Indeed. If it requires TCP or UDP, or worse... DNS, then we might be hosed. +14:54 <+polecat> NIO/ +14:54 <+polecat> NIO? +14:55 <+polecat> All I know is ni'o means change the subject in lojban. +14:55 < jrandom> NIO is a New I/O library in java, added in 1.4 +14:55 <+polecat> I see. Even plain sockets though, doesn't SAM have analog objects for sockets, and analog read() and write() functions? +14:55 < jrandom> yes +14:56 < jrandom> if they use plain sockets, its easy as shit +14:56 < jrandom> (...whatever that means) +14:56 < ant> <janonymous2> Whats bamboo? +14:56 < jrandom> bamboo-dht.org +14:57 < cervantes> what were the problems with pysam btw? +14:57 * polecat nods. +14:58 <@duck> cervantes: sending / receiving data +14:58 < cervantes> duck: oh is that all? :) +14:58 < ant> * janonymous2 /me coweres on his inadequate phone +14:58 <@duck> and making / detecting connections +14:58 <+Nightblade> it didn't send? +14:59 < Ragnarok> oy +14:59 <@duck> Nightblade: it probably did something +14:59 <+Nightblade> does it work at all? +15:00 < cervantes> duck: any thoughts on i2p-bt forum section naming? +15:00 < cervantes> d'you want you're own top level, with some subs? +15:01 < Ragnarok> hm, I've got to hit the road. Have a good rest-of-meeting :) +15:01 < jrandom> Nightblade: aum was using it, so i'm sure it worked +15:01 < jrandom> l8r Ragnarok +15:01 < cervantes> you're = your +15:01 < cervantes> cya ragnarok +15:02 < ant> <janonymous2> Status on bt? +15:02 < jrandom> janonymous: see the meeting logs (once they come out) +15:03 < jrandom> speaking of which, is there anything else people would like to bring up in the meeting? +15:03 < ant> <janonymous2> Oh, my bad +15:04 * cervantes hands jr the egold plated baffer +15:04 * jrandom winds up +15:04 < jrandom> ... +15:04 < jrandom> ... +15:04 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/115.rst b/i2p2www/meetings/logs/115.rst new file mode 100644 index 00000000..6aff181f --- /dev/null +++ b/i2p2www/meetings/logs/115.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 9, 2004 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/116.log b/i2p2www/meetings/logs/116.log new file mode 100644 index 00000000..b3056828 --- /dev/null +++ b/i2p2www/meetings/logs/116.log @@ -0,0 +1,177 @@ +13:05 < jrandom> 0) hi +13:05 < jrandom> 1) Congestion +13:05 < jrandom> 2) Streaming +13:05 <+dinoman> pgforge's key has changed :/ sorry +13:05 < jrandom> 3) BT +13:05 < jrandom> 4) ??? +13:05 < jrandom> ah cool, we can do some magic for that +13:05 < jrandom> 0) hi +13:05 * jrandom waves +13:05 < ant> <lucky> hi +13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000489.html +13:05 < wiht> Hello. +13:06 < jrandom> (and we got the notes posted *before* the meeting. w00t) +13:06 < jrandom> might as well jump on in to 1) Congestion +13:07 < jrandom> for people who have been hanging around the channel the last few days, you've heard lots of discussions about wtf has been going on, and both this email and duck's post earlier should cover it generally +13:07 < jrandom> that said, does anyone have any questions / comments / concerns that they'd like to raise/discuss? +13:09 < wiht> What do you mean by "wild peer selection"? +13:10 < jrandom> the way our current tunnel building works unfortunately lets things stabalize around the fast peers +13:10 < jrandom> if those fast peers don't fail occationally, we simply use them, period, rather than explore beyond them in our tunnel building +13:11 < jrandom> that means that when they *do* fail later on, we have pretty much no idea how much capacity the rest of the network has, and as such, choose peers fairly arbitrarily +13:11 <+DrWoo> jrandom: what is in the pipeline to use the capacity better? +13:12 < jrandom> DrWoo: the 0.4.3 release will include a new way of pooling tunnels so that we can have more 'experimental' backup tunnels (allowing us to learn more about the network without sacrificing performance) +13:13 < jrandom> more aggressive load balancing through ATM-style reservations are also in the pipeline, but aren't plotted at a particular release yet (aka we'll do it when we need it) +13:14 < ant> <Connelly> bleh +13:14 < ant> <Connelly> no meeting yet? +13:14 < jrandom> (ATM-style reservations, as in, keep track of how much bandwidth tunnels use, on average, multiply that by the number of tunnels we participate in, and compare that to our bandwidth limits / capacity, using that comparison to accept / reject further tunnel requests) +13:15 < jrandom> Connelly: started 10m ago, status notes posted on the list ;) +13:15 <+DrWoo> jrandom: what impact will that have on performance? +13:15 <+DrWoo> local pc performance +13:15 * wiht wonders how many different protocols are being used on the I2P network besides HTTP, IRC, and BT. +13:16 < jrandom> DrWoo: the 0.4.3 pooling will give us greater resiliance (less failures), and the reservations will allow for more capacity-based load sharing (aka reduce contention) +13:16 < jrandom> neither of those are particularly latency based though +13:17 < jrandom> wiht: those three are the main ones used to my knowledge, though some ugly stuff is done over HTTP +13:17 < jrandom> thats actually an interesting issue, wrt irc and congestion +13:18 < jrandom> what was really killing irc.duck.i2p the other day was the fact that during congestion, duck's irc server still had to pump out 20x the number of messages it received +13:19 < jrandom> add on the automatic message resending every.10.seconds.with.no.backoff, and that grows to 120 messages for every line of text ;) +13:19 < jrandom> basically what i'm saying is, a decentralized chat protocol would be Good ;) +13:19 <+DrWoo> is there such a beast? +13:20 < jrandom> (though the new streaming lib will get rid of that 6x overhead) +13:20 <+dinoman> is there a good one +13:20 < jrandom> i dont know if anyone has evaluated something ala SILC for i2p within the last year +13:20 < susi23> pop3 and smtp are _awfully_ slow on i2p +13:21 < ant> <duck> silc == irc+somecrypto +13:21 < susi23> (as answer on the question, which protocols are used too) +13:21 < jrandom> ah, i thought silc got away from the ircd concept +13:21 < jrandom> oh, shit, right, i forgot about those two :) +13:21 < wiht> susi23: Yes, I forgot that we have mail on I2P now. +13:21 < ant> <duck> not far atleast +13:21 < jrandom> 'k +13:21 < ant> <protok0l> meeting? +13:22 < ant> <lucky> rite now protok0l +13:22 < ant> <protok0l> k +13:22 < jrandom> ok, do we have anything else for 1) congestion? +13:23 < jrandom> if not, moving on to 2) streaming +13:23 < jrandom> [see the email] +13:24 < jrandom> i've kept all the streaming lib updates out of the history.txt, but you can watch whats going on via the cvs list +13:24 < jrandom> (if you're crazy) +13:24 < jrandom> i dont really have anythign else to add though. so, any questions/comments/concerns? +13:25 <+postman> just one +13:25 <+postman> thanks :) +13:25 < ant> <protok0l> what speed increase will there be +13:25 < jrandom> hehe you're supposed to wait until you *get* the software postman ;) +13:25 < jrandom> protokol: some. varies. +13:25 <+postman> jrandom: i would bet on you blindfold +13:26 <+DrWoo> jrandom: I'm going to ask you what you hate, is there an ETA on the new streaming lib, the current situation obviously is a point of vulnerability? +13:27 < jrandom> if tests this week go well, we can pencil in next week +13:27 < jrandom> there'll be services up and running on the new streaming lib before then though, so that we can test it under load conditions +13:28 < wiht> As I recall, you are using a simulated network for the tests. Is that still true? +13:29 < jrandom> for some of them, yeah +13:29 < jrandom> when i dont use the sim, i just run it on the live net +13:30 < jrandom> (because i like to abuse your bandwdith ;) +13:30 < susi23> you're welcome ;) +13:30 <+dinoman> hehe turn it on a see if it blows up? +13:31 -!- x is now known as fidd +13:31 < jrandom> pretty much - i've got some logging code that essentially dumps the streaming packet headers, allowing me to make sure everything is sent properly and various situations are handled as they should be +13:32 < jrandom> the sim'ed tests are more involved though, with perhaps a half dozen unit tests w/ various runtime params +13:33 < wiht> How well do the simulation tests reflect observed network usage? +13:33 < jrandom> pretty well, as the simulation code is the same as the live network code +13:34 < jrandom> i dont have the lag and drop injection perfect in the sim though, but its in the ballpark +13:35 < ant> <cat-a-puss> will the new streaming lib use the same interface? Or will Java apps have to do something new? +13:35 < wiht> Thanks for clarifying that. +13:36 < jrandom> cat-a-puss: same interface. there are a few additional config options that you might want to tack on when building an I2PSocketManager, but thats a good ol' properties map +13:36 < ant> <cat-a-puss> k +13:37 < jrandom> k, anything else, or shall we jump to 3) BT? +13:38 < jrandom> duck: ping +13:38 <@duck> *quack +13:38 <@duck> Last week I reported that we had BitTorrent on I2P working. There has been some +13:38 <@duck> confusion but it is anonymous both for trackers and for clients (seeders and leechers). +13:38 <@duck> Updates since last week: +13:38 <@duck> GUI work (wxPython), included tracker, bugfixes. +13:39 <@duck> full list at http://dev.i2p/cgi-bin/cvsweb.cgi/~checkout~/i2p-bt/CHANGES.txt?rev=HEAD +13:39 <@duck> also the code is at the CVS on cvs.i2p +13:39 <@duck> and got a dedicated eepsite: http://duck.i2p/i2p-bt/ +13:39 <@duck> The included tracker is very spartanic and you still have to provide the +13:39 <@duck> torrents themself somewhere; so DrWoo, thetower and me have been looking at +13:39 <@duck> several alternatives which offer features like suprnova, until I got nuts. +13:39 <@duck> *flierp* +13:40 < jrandom> w00t +13:40 <@duck> Finally bytemonsoon is selected, the original is ugly, but DrWoo has been fixing that, +13:40 <@duck> The idea is to improve it some more and release it as an I2P ready tracker solution, +13:40 <@duck> see: http://brittanyworld.i2p/bittorrent/ +13:40 <@duck> meeting the requirements at: http://duck.i2p/i2p-bt/txt/bytemonsoon.txt +13:40 <@duck> . +13:40 < jrandom> kickass +13:40 <+DrWoo> you can check out a couple of small test files on a the nice tracker duck fixed up +13:41 <+DrWoo> there's nothing big to gum up the net heh +13:41 < jrandom> what, you dont want us to download more episodes of Lost? :) +13:41 <@duck> if thetower's is up.. +13:42 < jrandom> the bytemonsoon port is looking really nice. +13:42 <+DrWoo> I can't get thetower right now here +13:42 <+DrWoo> jrandom: it really seems to provide most anything you'd need +13:42 <+dinoman> what kind of speed r ppl seeing? +13:43 <@duck> ~5kb/s per peer +13:43 <+DrWoo> dino: from this side it looks like 4-10K per peer +13:43 <@duck> (optimistically, ofcourse there are those shitty adsl folks) +13:44 <+dinoman> wow better then i thought +13:44 <@duck> til i2p crashes; see 1) +13:44 < jrandom> heh +13:44 <+DrWoo> dinoman: in other works, it should look pretty impressive with a swarm +13:44 <@duck> there have been various calls for improving the GUI +13:45 <+DrWoo> dinoman: and some 0 hop peers ;) +13:45 <@duck> not many takers on it though +13:45 < jrandom> duck (& gang): what can we do to help? +13:45 <@duck> you: get the new streaming lib ready +13:46 <@duck> gang: look at the todo: http://duck.i2p/i2p-bt/txt/todo.txt +13:46 <@duck> lucky is working on a howto +13:47 <@duck> DrWoo: anything else? +13:47 < jrandom> nice +13:47 <+DrWoo> jrandom: can you talk a bit about where you stand regarding the importance (or not) of file sharing(and other popular services currently run over the internet) and what it's means to to I2P's anonymity prospects. +13:47 < ant> <lucky> i am? +13:48 < ant> <lucky> oh +13:48 < ant> <lucky> i am +13:48 < ant> <lucky> :) +13:48 <+DrWoo> duck: there's always something else heh +13:48 < jrandom> file sharing is critical to I2P's success, as its realistically the largest potential pool of users to blend into our anonymity set +13:49 < ant> <lucky> uh oh. +13:49 < ant> <lucky> So that means i should really, really, work on that howto then. +13:49 < jrandom> without a viable large-file-transfer system, we've got to do some wonders for engaging user apps +13:50 < jrandom> which we are doing - susi's and postman's work is quite promising +13:50 < jrandom> but the market for anonymous email is much less than the market for safe file transfer +13:51 < jrandom> while I2P itself scales to whatever size (if things are as we hope ;), we need a large anonymity set to support anything wortwhile +13:51 < jrandom> </my $0.02> +13:52 <@duck> what do you think about default settings for those filesharing apps? +13:52 < jrandom> that i dont know +13:53 <@duck> or isn't that really relevant yet giving todays possibilities +13:54 <+DrWoo> duck: there may be some 'thinking outside the box' needed to get over some bumps along the way? +13:54 < jrandom> 1 hop tunnels may be relevent for the BT-ers, prior to 0.4.3 +13:57 < jrandom> ok, do we have anything else for 3) BT? +13:57 <@duck> notme +13:57 <+DrWoo> thanks to duck and the dudes +13:58 <+DrWoo> that was pretty awesome work +13:58 < jrandom> aye, y'all are doing a kickass job +13:58 <+dinoman> i did not do it +13:58 < jrandom> (i love watching the --spew 1 on the btdownloadheadless :) +13:58 <@duck> dinoman: you started it +13:58 <+Ragnarok> headless spew... sounds dirty +13:59 <+DrWoo> dino: pushing the effort along is a real contribution +13:59 * Ragnarok will put together a patch for the command line option stuff on the todo list +13:59 < jrandom> w00t +14:00 < ant> <dm> Don't forget anonymous WWW, that's a big one as well. +14:00 < jrandom> dm: yeah, perhaps thousands or tens of thousands, but not the draw of millions +14:01 < jrandom> (for outproxy stuff, imho) +14:01 < jrandom> ok, if there's nothing else, moving on to good ol' fashioned 4) ??? +14:01 < jrandom> anything not yet raised that should be? +14:02 < wiht> postman: What is the status of the mail system? How well is it working, especially with respect to communications outside the I2P network? +14:02 <+DrWoo> dm: it's all part of life's rich pageant :) +14:03 < ant> <dm> a lotta people use da web +14:03 < ant> <dm> (they just installed surfcontrol at my workplace) ;) +14:03 < jrandom> aye, anonymous www hosting will be critical for those who really need i2p, though they probably won't be the anonymity set necessary +14:03 < jrandom> ah, lame +14:04 < jrandom> wiht: if he's not around, i can say that in and outproxy has worked pretty well for me - none lost yet +14:04 < jrandom> (and checking my mail takes a few seconds, but biff tells me when i need to anyway) +14:05 < jrandom> ok, is there anything else? +14:06 < ant> <dm> are you baffing the meeting? +14:07 < jrandom> seems like it +14:07 * jrandom winds up +14:07 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/116.rst b/i2p2www/meetings/logs/116.rst new file mode 100644 index 00000000..aed888fb --- /dev/null +++ b/i2p2www/meetings/logs/116.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 16, 2004 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/117.log b/i2p2www/meetings/logs/117.log new file mode 100644 index 00000000..eae2dd49 --- /dev/null +++ b/i2p2www/meetings/logs/117.log @@ -0,0 +1,64 @@ +13:03 < jrandom> 0) hi +13:03 < jrandom> 1) Net status +13:03 < jrandom> 2) Streaming lib +13:04 < jrandom> 3) 0.4.2 +13:04 < jrandom> 4) Addressbook.py 0.3.1 +13:04 < jrandom> 5) ??? +13:04 < jrandom> 0) hi +13:04 * jrandom waves +13:04 <+postman> hi :) +13:04 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-November/000490.html +13:05 < jrandom> well, might as well jump on in to 1) net status +13:05 < jrandom> i dont have much to add to this that wasn't in the email +13:05 < jrandom> anyone have anything they want to bring up wrt the network status over the last week? +13:06 < jrandom> if not, we can jump on down to 2) streaming lib +13:06 < jrandom> there's lots of info in the mail about this, so i'll let y'all digest a bit +13:07 < jrandom> while the new lib will improve lots of things, the most important (imho) is its resiliance and handling of congestion +13:08 < jrandom> especially the latter, as we've seen how things get funky with the old lib under heavy congestion +13:08 < jrandom> there's also a lot of things left out of the lib though, places for people to experiment and optimize further +13:09 < jrandom> anyone have any questions wrt this, or have we been beating a dead horse by discussing it each week for the last month? ;) +13:10 <+Ragnarok> we'll call that a yes +13:10 < jrandom> heh +13:10 < jrandom> ok, moving on to 3) 0.4.2 +13:10 < jrandom> out real soon, just doing some minor updates to the install process at the moment +13:11 <+postman> yesss +13:11 <+postman> :) +13:11 < jrandom> the updated install proc will be a bit nicer for people, addressing the most common user errors +13:12 < jrandom> (since no one ever reads the text on the router console ;) +13:12 < jrandom> but that should be ready in the next day or two, so with some testing we should have a release out by friday +13:12 < jrandom> (if not sooner) +13:13 < jrandom> as i mentioned in the mail though, its both backwards compatbile and /not/ backwards compatible +13:13 <+Ragnarok> awesome +13:13 < jrandom> does anyone have any strong preferences as to how we should do that tap dance? +13:13 < jrandom> should we just push out 0.4.2 and let people upgrade when they notice they cant reach any eepsites? +13:14 < jrandom> (or will they uninstall it and say "dood i2p sux0rz") +13:14 * jrandom neither +13:15 <+Ragnarok> I'd say mark it as not compatible. It's always better to be explicit. +13:15 < jrandom> well, the docs and announcement will say not compatible, mandatory upgrade in big bold letters +13:16 <+Ragnarok> no reason to send mixed messages, then +13:16 < jrandom> aye +13:16 < jrandom> though we would be able to tunnel route through those old peers +13:16 < jrandom> i dunno, we've got a few days to finalize the decision anyway +13:17 < jrandom> just something to think about, and a WARNING to people that they'll NEED TO UPGRADE TO 0.4.2 +13:17 < jrandom> :) +13:18 < jrandom> ok, anyone have any questions/comments/concerns wrt 0.4.2, or shall we move on to 4) addressbook.py? +13:18 < jrandom> consider us moved +13:18 < jrandom> Ragnarok: wanna give us an update? +13:20 <+Ragnarok> sure. Minor update released yesterday. Fixes some bugs on windows, and doesn't violently die if the proxy isn't there. Only really notable thing is that this will probably be the last release for this version, barring a giant bug. +13:20 < jrandom> ok cool +13:21 < jrandom> avoiding violent death is always a nice feature to have +13:21 < lba> hi folks +13:21 <+Ragnarok> I'm planning on redesigning (just designing, really) it from the ground up based on jrandom's thoughts from the mailing list. Possibly in java too, if I can figure out the xml parsing and http stuff I'll have to do. +13:21 < jrandom> wikked :) +13:21 < jrandom> 'lo lba +13:22 <+Ragnarok> well, that's all. Carry on. +13:22 < jrandom> cool, thanks for the update +13:22 < jrandom> ok if there's nothing else on that, we can move on at a blazing pace to 5) ??? +13:22 < jrandom> anyone else have something they want to bring up? +13:23 <+Ragnarok> anyone else here? +13:23 < jrandom> heh, yeah, we dont have our usual malcontents ;) +13:24 < jrandom> then again, they'll show up to read the logs on the site later [yeah, i mean *YOU*] +13:24 < jrandom> ok, i think thats probably the shortest meeting we've had in over a year +13:25 < jrandom> might as well wraper 'er up +13:25 * jrandom winds up +13:25 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/117.rst b/i2p2www/meetings/logs/117.rst new file mode 100644 index 00000000..df42f007 --- /dev/null +++ b/i2p2www/meetings/logs/117.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 23, 2004 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/118.log b/i2p2www/meetings/logs/118.log new file mode 100644 index 00000000..ec12d381 --- /dev/null +++ b/i2p2www/meetings/logs/118.log @@ -0,0 +1,318 @@ +13:08 < jrandom> 0) hi +13:08 < jrandom> 1) 0.4.2 and 0.4.2.1 +13:08 < jrandom> 2) mail.i2p +13:08 < jrandom> 3) i2p-bt +13:08 < jrandom> 4) eepsites +13:08 < jrandom> 5) ??? +13:09 < jrandom> 0) hi +13:09 < jrandom> sorry to interrupt dm's agenda +13:09 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000492.html +13:09 < jrandom> [hi] +13:10 <+postman> ((hi)) +13:10 <+postman> :) +13:10 < jrandom> so, as y'all read through that overwhelmingly interesting email, we might as well get the meeting underway +13:10 < jrandom> 1) 0.4.2 and 0.4.2.1 +13:11 < jrandom> 0.4.2 is out, as you know, and the results are mixed, but when its not failing bad, it seems to be doing much better ;) +13:12 < jrandom> there will be a release with a whole slew of bugfixes soon - i've been holding off to try to get as many things improved as possible +13:12 < jrandom> as things stand now though, it looks like the 0.4.2.1 release will not yet get the i2p-bt port into tip top shape quite yet +13:12 <+postman> jrandom: what do the bugfixes address - all errors in the new streaminglib or other stuff as well? +13:13 < jrandom> a fast busy loop in the streaming lib that came up from a poorly tested scenario, some SAM issues, IP address detection problems, among other things +13:14 < jrandom> dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/history.txt?rev=HEAD has the full list +13:14 <+postman> k +13:14 <+postman> thx +13:15 < jrandom> oh, one thing to note about 0.4.2.1 is that it, like 0.4.2, will need to modify your wrapper.config again, so please pay attention to the update instructions when they're out :) +13:15 < jrandom> does anyone have any questions/comments/concerns about 0.4.2? +13:15 < jrandom> (/0.4.2.1) +13:16 < clayboy> been working great here, have been tracking cvs too, always smooth +13:16 < jrandom> wikked +13:17 < bla> It's table (0.4.2): up for days already +13:17 < bla> s/table/stable/ +13:17 < jrandom> ah nice, yeah, the bugs havent been hitting everyone +13:17 < jrandom> ok, if there's nothing else on that, lets jump on to 2) mail.i2p +13:18 < jrandom> i hear postman has some things to discuss +13:18 <+postman> hello +13:18 < jrandom> hi postman, you're up :) +13:18 <+postman> weeks ago i conducted a poll regarding IMAP +13:19 <+postman> since a few weeks passed now i decided to close the polls and to count the vote +13:19 <+postman> result is: not needed - won't be done. period +13:19 <+postman> after talking to susi - she was quite fine wioth pop3 on her webmail interface +13:19 < clayboy> reason wins! :) +13:19 < jrandom> w3wt +13:20 <+postman> so let's just stick to the pop3 end bury any silly imap ideas +13:20 <+postman> :) +13:20 * jrandom gets the shovel +13:20 <+postman> 2.) we're close to 100 registered users +13:21 < clayboy> wow +13:21 <+postman> not all of them public of course, but it still sounds like a quite reasonable number regarding the size of the network +13:21 <+Ragnarok> so... how about that LDAP address book? :) +13:21 < jrandom> nice +13:21 <+postman> 3. a feature to upload/share you public pgp key is active since weekend +13:21 <+postman> please use it +13:21 <+postman> www.postman.i2p/user/acc.html +13:22 < clayboy> i'm not taking any credit for that idea :> +13:22 <+postman> the public keys can easily be downloaded with the help of the addressbook +13:22 <+postman> or direct as www.postman.i2p/public/accountname.pub +13:22 < jrandom> ooh cool +13:22 <+postman> the system works quite fine +13:22 <+postman> thanks to duck for pointing at a few bugs +13:23 <+postman> 4.) i think about offering accountbased routing +13:23 <+postman> like ppl say +13:23 < jrandom> account based routing? +13:23 <+postman> all mail for foo@mail.i2p gets transported to the following destination +13:23 <+postman> and user presents a valid destination key for it +13:24 <+postman> postman.i2p will then manually route mail to those accounts to mailsystems +13:24 <+postman> just an idea(tm) +13:24 < jrandom> ah nice +13:24 <+postman> i am looking forward to develop and discuss the whole matter +13:25 <+postman> that's it for now +13:25 <+postman> more follows next week +13:25 <+postman> thanks +13:25 < nmi> postman: sorry, transported to a particular i2p destination you mean? +13:25 * postman hands the mike back to jrandom +13:25 <+postman> nmi: yes +13:25 < ant> <Nightblade> am SMTP i2p destination? +13:25 < ant> <Nightblade> an +13:25 <+postman> nmi: provided the destination accepts smtp and mail for that account +13:25 < jrandom> that sounds very cool, gets rid of the trust aspect of the mail fiiltering +13:26 < nmi> ah, ok. clever. i had thought of doing something similar using mixminion single-use-reply-blocks but your idea is better... +13:26 < jrandom> its probably a lot of work to set up on the client side, but perhaps someone could do some hacking +13:26 <+postman> jrandom: i am working on it +13:26 < jrandom> w00t +13:26 <+postman> jrandom: the user will have the usual webinterface ( acc.html...) +13:27 <+postman> jrandom: and inserts the destinationkey +13:27 < jrandom> well, right, but then there's the MTA configuration +13:27 <+postman> the rest will be done automatigally +13:27 <+postman> yes, on the postman.i2p AND the receiving sinde +13:28 < nmi> jrandom: yeah, it would be cool to have a really stripped down smtp proxy for people not wanting to run a full MTA +13:28 < jrandom> right right +13:28 <+postman> jrandom: i will provide a simple setup config for ppl interested +13:28 <+postman> jrandom: for postfix, exim and sendmail +13:28 <+postman> jrandom: those can be stripped down to BARE necessities +13:28 <@duck> seriously, do you think that there are many users for that? +13:28 < jrandom> postman: this all sounds pretty kickass. i look forward to hearing more when you're ready +13:29 <+postman> jrandom: no idea about windows smtp servers tho +13:29 <+postman> duck: well +13:29 <+postman> duck: 8 weeks ago there was no need for a mailsystem and no users either +13:29 <+postman> duck: it's investment +13:29 <@duck> true +13:29 <+postman> duck: in 6 months we'll be happy to have it +13:29 < jrandom> duck: the potential comes with moving away from a trusted SMTP filter +13:29 <+postman> :) +13:30 < jrandom> er, perhaps i should say, moving /to/ a trusted smtp filter (no offense postman ;) +13:30 <+postman> and there will be a few ones +13:30 <+postman> AND +13:30 <+postman> (now the punchline) +13:30 <+postman> we could easily create maildomains :) +13:30 <+postman> like duck@duck.i2p and other stuff +13:30 <+postman> :) +13:30 <@duck> ah +13:31 <+postman> the only problem would be the official/private mapping +13:31 < jrandom> hosts.txt! +13:31 * jrandom ducks +13:31 <+postman> but this is another thing for the webmanagement console :) +13:31 <+postman> LOL +13:31 <+postman> jrandom: i rely on shaky sql databases :) +13:31 <@duck> ok; I see it fitting in +13:32 <+postman> ok +13:32 <+postman> then i will work it out and present an concept soon +13:32 <+postman> yess, yet more work +13:32 * postman leans back relaxed +13:32 <+postman> :) +13:32 < jrandom> kickass, thanks postman +13:33 < jrandom> ok, unless other people have further mail.i2p related questions, shall we move on to 3) i2p-bt? +13:33 < jrandom> consider us moved +13:34 < jrandom> ok, as the email mentioned, i broke the i2p-bt port +13:34 * jrandom hangs head in shame +13:34 < jrandom> in other news, duck, do you have anything wrt i2p-bt you want to discuss? +13:34 <@duck> as a result of jrandom's work not much has been done :) +13:35 <+Ragnarok> booo, hissss +13:35 <@duck> oh Ragnarok had some patches +13:35 * jrandom2p pelts jrandom with tomatoes +13:35 <@duck> I think, see the history file :) +13:35 < jrandom> oh cool +13:35 <@duck> we got some things in the queue too +13:35 <+Ragnarok> well, I was hissing at jr, but ok :) +13:36 <@duck> but I dont want to change (too) much on the unstable ground +13:36 <@duck> (like breaking bt while i2p is getting fixed) +13:36 < jrandom> aye, good plan +13:36 <@duck> . +13:37 < jrandom> ok cool, anyone else have anything on i2p-bt? +13:37 < jrandom> if not, moving us along to 4) eepsites +13:38 < jrandom> well, i know the issues have been discussed a few times since we first got the eepproxy, but there have been some recent queries warranting their mention again +13:39 < bla> yes... +13:39 < jrandom> what we have now for browsing eepsites and normal websites anonymously just plain isn't safe +13:39 < clayboy> disabling java, javascript, cookies and flash helps, though +13:39 < jrandom> DrWoo has done a great job with his page describing the dangers and how you can protect yourself +13:40 < jrandom> right clayboy, definitely +13:40 < clayboy> url? +13:40 < bla> clayboy: Yes, on the HTML side, but not on the HTTP side +13:40 < jrandom> but if there's one thing i've learned with the router console, its that no one follows more than two steps into the instructions ;) +13:40 < clayboy> bla: good point +13:40 < jrandom> clayboy: http://brittanyworld.i2p/browsing/ +13:41 < bla> I've done some experiments here: http://forum.i2p/viewtopic.php?t=182 +13:41 < bla> Doesn't look good as it is +13:42 <@duck> who has the evil applets? +13:42 < ant> <Nightblade> there was a security exploit found in java +13:43 < ant> <Nightblade> for some older 1.4.x vers +13:43 < ant> <Nightblade> not 1.5 +13:44 < jrandom> nightblade: the 'attack' used in this person's case was really trivial, and, according to the person, worked from 1.1.6-1.5 +13:44 < ant> <Nightblade> hmm +13:44 < jrandom> (download a .exe, run the .exe) +13:45 < jrandom> i was suprised to see some java security permissions fire up on instantiation of new File(filename) but no security permissions fire up on instantiation of new FileOutputStream(filename) +13:45 * jrandom stops handing out hand grenades +13:46 < jrandom> (i havent verified their code, but did see much of it) +13:46 < jrandom> but anyway, eepsites +13:47 < jrandom> well, i dont think it would be prudent to remove the eepproxy altogether +13:47 < jrandom> but i dont really have time right now to implement any of the solutions listed +13:48 < bla> jrandom: Stripping out all Accept* headers would be a good thing, for now +13:48 < jrandom> what do y'all think? any volunteers? shall we wing it until we do get time? +13:48 < ant> <Nightblade> bla: I don't think it is a big deal that people can see some browser headers +13:49 < ant> <Nightblade> millions of people use those browsers +13:49 < bla> And always adding a User-Agent: header, even if the client didn't send one. I makes requests homogeneous +13:50 < bla> Nighblade: Yes, but if your browser says Accept-Language: xx (just made up on the spot), and there happens to be only 1 I2P node in a country that speaks language xx, almonimity is gone, completely +13:50 < bla> The Accept-Language: header is there though, in some browsers. And we can't rely on it always being "en" +13:50 < ant> <Nightblade> ok but what if removing some of those headers violates the HTTP spec? +13:50 < jrandom> adding those two cases are easy enough, and i'll get them into 0.4.2.1, but it really isn't safe to explicitly filter headers like this +13:50 < jrandom> nightblade: we break so many aspects of the HTTP spec it hurts +13:51 < bla> Nightblade: Only one of the threee browsers I listed did send the header, so it shouldn't be much of a problem +13:51 < ant> <Connelly> HTTP was not designed for anonymity +13:51 < jrandom> the eepproxy is duct tape and shoe polish +13:51 < bla> jrandom: Why isn't that filttering safe? +13:52 < bla> jrandom: We could even consider stripping _all_ headeers, except for the Host: header and the GET header +13:52 < jrandom> bla: stripping all headers except the host would be safer, yes +13:52 < bla> jrandom: After all, what do we need more for an anonymous HTTP? +13:52 < jrandom> but thats beyond the amount of time i can put into it +13:52 < jrandom> i can add the Accept and user-agent filters in ~ 30s +13:53 < jrandom> much beyond that and i throw my hands in the air and rewrite the http proxy ;) +13:53 < bla> jrandom: How come stripping all of them is more difficult? +13:53 < jrandom> read the code. +13:54 < jrandom> (patches welcome) +13:54 < jrandom> but what we're looking at here is still just a short term solution +13:54 < bla> jrandom: Point well taken ;) But seriously: I think the Accept* and User-Agent fixes would do really fine for now +13:54 < jrandom> we need someone to work on something that will last us long term +13:55 < ant> * dm just ate 20 slices of cheese... drool. +13:55 < jrandom> bla: i heard that last time someone asked us to filter the User-agent and referrer headers ;) +13:55 < jrandom> (but yeah, i'll get those two into the next rev) +13:56 < ant> <dm> those headers are usefl +13:56 < ant> <dm> useful +13:56 < ant> <dm> For service providers. +13:56 < jrandom> yes, they are +13:57 < jrandom> we've already had some apps break because we filter referrer too +13:57 < bla> dmm: Yes, indeed. However, they also provide a browser or OS fingerprint +13:57 < ant> <dm> I have an idea! +13:57 * jrandom takes cover +13:58 < ant> <dm> Hard code the User-Agent to: Nokia6230/2.0 (03.15) Profile/MIDP-2.0 Configuration/CLDC-1.1 149.254.201.133 +13:58 < ant> <dm> eh? eh? +13:58 < jrandom> we already hard code the user agent header +13:59 < ant> <Nightblade> I2P-enabled cell phones +13:59 * jrandom mounts a DoS on that phone +13:59 < ant> <dm> To what? +13:59 < ant> <dm> My poor phone!!! +13:59 < jrandom> ok, anyone else have any thoughts on the eepproxy/eepsite stuff? +14:00 < bla> MYOB/6.ss (AN/ON) +14:00 < bla> no\ +14:00 <+Ragnarok> we should reinvent html using s-expressions! +14:01 < jrandom> (i really do think using a bbcode style macro language is the way to go, at least for some things ;) +14:01 < jrandom> ((or xml for you geeks)) +14:02 < ant> <dm> Microsoft endorses use of XML +14:02 < ant> <dm> So I'm all for it. +14:02 <+Ragnarok> xml is just excessively wordy s-expressions :) +14:03 < ant> <dm> Is this a good time for me to aplaud jrandom for his work on this project? +14:03 * jrandom volunteers Ragnarok to work on it, after getting the next gen address book ;) +14:03 <@duck> I dont think that 'invent your own markup language' will work for general browsers +14:04 <@duck> maybe for the blog thing inside myi2p +14:04 <+Ragnarok> it's always a good time :) +14:04 < ant> <dm> applaud even +14:04 < jrandom> duck: the proxy will need to filter content anyway, it would be simple enough (heh) to inject the results of macro expansions into the resulting filtered content +14:05 < ant> * dm tips his hat to jr. +14:05 < jrandom> gracias dm et al +14:05 < ant> <Nightblade> something like PDF would be safer than HTML +14:05 < jrandom> lol +14:05 <@duck> .txt files! +14:06 < ant> <Nightblade> i've seem PDF files with clickable links, but the files themselves are huge +14:06 < ant> <Nightblade> seen +14:06 < ant> <dm> Uncompressed Bitmaps? +14:06 < jrandom> yes, lets all write in pdf +14:07 <+Ragnarok> erg, postscript is fugly +14:07 < ant> <cat-a-puss> how is html insecure? +14:07 <@duck> anyway +14:07 < ant> <Nightblade> cat: with javascript, activex, applets,... +14:07 < jrandom> cat-a-puss: all the different ways to encode dangerous data +14:08 < ant> <dm> languages aren't secure or insecure, clients are. +14:08 <+Ragnarok> the realy problem is how to do anon dhtml... +14:08 < jrandom> (and we'll never, /never/ be ahead of the game as long as we explicitly filter) +14:08 < ant> <cat-a-puss> Java/javascript are enclosed in tags. So strip those out, plain html is not harmful right? +14:08 < ant> <dm> We need to use a data format that is parsed by a client made by a company that we trust. +14:08 < jrandom> Ragnarok: macros, and/or reference known safe and locally installed javascript +14:08 < ant> <dm> I trust Microsoft, therefore I suggest Internet Explorer, Microsoft Word, or Notepad +14:09 < ant> <dm> Flight Simulator 2002 is acceptable as well. +14:09 < ant> <cat-a-puss> Freenet already has an "anonymity filter" strips out all Java / Javascript / ActiveX etc. Borrow that and the only thing I can think could get through would be Image exploits... unless there is something I am missing. +14:10 < jrandom> freenet's anon filter is a good start for one or two of the different camps, but would likely require some work to get forms working as we want them +14:10 < ant> <Nightblade> the eepproxy would have to run as a separate process, because of licensing +14:11 < jrandom> that still leaves us a heavily crippled html +14:11 < jrandom> (with no css) +14:11 < ant> <dm> Okay, how about Flash? +14:11 < jrandom> nightblade: we can work around that (same way we work around i2ptunnel being GPL) +14:11 < ant> <dm> Imagine a world wide web with only flash. +14:11 < ant> <dm> What a rich and wonderful world that would be. +14:12 < ant> <Nightblade> well Just create a warning: "Eepsite browsing is hazardous to your anonymity. Please use Gopher." +14:12 < ant> <Nightblade> actually gopher is not a bad idea +14:12 * jrandom ports archie +14:12 <+Ragnarok> gopher! +14:12 < ant> <dm> There was Betty as well, wasn't there... +14:12 <+Ragnarok> I remember gopher :) +14:13 <+Ragnarok> man, those were the good old days. I think I had a screaming 14.4 baud at the time... <sigh> +14:13 < ant> <Nightblade> I only browsed gopher in text mode, and I don't know if it supported graphics +14:13 < jrandom> they didnt have gui browsers last time i used gopher ;) +14:14 < jrandom> anyway, there are lots of options +14:14 < ant> <Nightblade> what was that browser called back then? the one before Netscape... +14:14 < ant> <Nightblade> i forget +14:14 < jrandom> mosaic +14:15 < ant> <Nightblade> yeah +14:15 < ant> <dm> Mosaic 2.0 +14:15 < ant> <Nightblade> "Welcome to I2P, please wait while we install Gopher and Mosaic." +14:15 < jrandom> heh +14:15 < jrandom> yeah, probably no javascript exploits in those +14:16 < jrandom> ok, anyway, thats that, i suppose +14:16 < jrandom> moving on to 5) ??? +14:16 <+Ragnarok> there's still a gopher package in debian +14:16 < jrandom> anyone have anything else (not gopher related)? +14:17 < ant> <dm> What will happen to I2P when you need to start working again? +14:18 < jrandom> i'll be on i2p fulltime through the spring, at least. we can discuss things beyond then as that time approaches +14:19 < ant> <dm> o k +14:19 < jrandom> in any case, if i got hit by a bus tomorrow, everything is in cvs and all code is free +14:19 <+Ragnarok> I assume you're planning to have a 1.0 before then. What do you think the odds are? +14:19 <+Ragnarok> before spring, not your untimely demise... +14:20 < jrandom> certainty. +14:20 < ant> <dm> ahaha.. yes, what are the odds of 1.0 before tomorrow when you get hit by that bus? +14:20 < jrandom> (assuming no buses ;) +14:20 < ant> <dm> I just had a very sad thought. +14:20 < ant> <dm> Depressing really, but... If you were to get hit by a bus, no one here would know of it. +14:20 < ant> <cat-a-puss> On filtering: What if we created a better proxy, such that all the applications on the computer's traffic could go through it, then we would not need to filter Javascript et alt because they can't find out who we are anyway. +14:21 < ant> <dm> You would just die, and we wouldn't know what happened :( +14:21 < ant> <dm> God why did he have to die?!?!? why?!?! +14:22 < ant> <dm> Can you put a clause in your will to email the mailing list if you die? +14:22 < jrandom> cat-a-puss: javascript can send the contennts of your bookmarks, your IP address, and all sorts of things to a remote site +14:22 < jrandom> dm: people who know me irl know i'm involved in i2p. enough of this morbid shit +14:23 < ant> <dm> ah cool. +14:24 < ant> <cat-a-puss> jrandom: yeah, but that sort of thing requres an exploit right, not just say forwarding them to some page that uses a different protocall that is not proxied. We probably be reasonable safe from those with a scanner on incomming content and automatic updates. +14:25 < jrandom> cat-a-puss: erm, perhaps i misunderstood - are you suggesting that it may be safe to have javascript enabled in the browser, as long as the connections that that javascript code makes are proxied also? +14:26 < ant> <cat-a-puss> jrandom: yeah, as long as there is no buffer overflows etc. +14:26 < jrandom> if so, thats still vulnerable to plain old javascript that reads the javascrip environment and sends it "anonymously" to http://cia.i2p/data. +14:27 < jrandom> the data available to javascript includes your IP address, as well as your bookmarks and all sorts of other things +14:27 < jrandom> so even though the connection to cia.i2p was anonymous, the content exposes you +14:31 < jrandom> ok, anyone else have something to bring up for the meeting? +14:31 <@duck> yes: +14:31 <@duck> what does the new 'active peers' counter mean +14:31 < jrandom> ah +14:31 < jrandom> yeah, that changed +14:32 < jrandom> in 0.4.2.1, the new Active: x/y will have x=# of peers you've sent or received a message from successfully in the last minute, y=# peers seen in the last hour or so +14:32 < jrandom> this is part of the code to deal with some peers giving out bad info in the IP autodetection phase +14:33 * duck will try to remember it +14:33 < jrandom> so it'll vary much more than before +14:33 < jrandom> heh so dont worry when the value is lower than you're used to ;) +14:34 < jrandom> ok, if thats it, then y'all should check back onto the mailing list and website over the next day for the 0.4.2.1 release +14:34 < jrandom> it'll be backwards compatible, blah blah blah +14:34 < jrandom> in any case +14:34 * jrandom winds up +14:35 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/118.rst b/i2p2www/meetings/logs/118.rst new file mode 100644 index 00000000..4c2da054 --- /dev/null +++ b/i2p2www/meetings/logs/118.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 30, 2004 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/119.log b/i2p2www/meetings/logs/119.log new file mode 100644 index 00000000..6d5539f0 --- /dev/null +++ b/i2p2www/meetings/logs/119.log @@ -0,0 +1,168 @@ +22:00:00 <@duck> Tue Dec 7 21:00:00 UTC 2004 +22:00:04 <@duck> I2P meeting time +22:00:05 < Frooze> i just made Frooze up for i2p. i don't even know what a 'frooze' is. +22:00:21 <@duck> as announced on http://dev.i2p.net/pipermail/i2p/2004-December/000509.html +22:00:29 <@duck> Agenda: +22:00:29 <@duck> 0) hi +22:00:29 <@duck> 1) 0.4.2.3 +22:00:29 <@duck> 2) i2p-bt +22:00:29 <@duck> 3) #idlerpg +22:00:29 <@duck> 4) ??? +22:00:32 <@duck> . +22:01:09 <@duck> 0) hi +22:01:15 < clayboy> hi +22:01:16 <@duck> jrandom called in sick +22:01:20 <+ugha2p> Hi. +22:01:30 <@duck> plus msged me that he'd probably not make it +22:01:39 <+protokol> http://www.google.com/search?q=frooze +22:01:41 <@duck> so we'll see and just start +22:01:46 < clayboy> hope he gets better quick +22:02:06 <@duck> 1) 0.4.2.3 +22:02:16 <@duck> new release will be out Real Soon +22:02:31 <@duck> so tomorrow or thursday. +22:02:41 <@duck> there has been quite a few bugfixes +22:03:24 <+ugha2p> Do newer CVS revisions also fix the memory/CPU issues? +22:03:29 < clayboy> a few of us have been following the cvs builds, it's working very nicely +22:03:33 <@duck> most streaming lib, sam bridge, etc +22:04:17 <+ugha2p> I've been experiencing some uncommon loads from I2P. +22:04:23 < clayboy> i think those were fixed many revisions ago, ugha2p +22:04:41 <+ugha2p> (Running -7) +22:04:51 < clayboy> oh, hm +22:04:52 <@duck> ugha2p: dont see anything about that in the history +22:05:48 <+protokol> you know what would be nice (if not feasable/worth it) is an RSS feed of the changelog +22:05:48 <@duck> ok +22:05:49 <+ugha2p> That's strange. +22:06:01 <+protokol> ;-) +22:06:17 <@duck> maybe file a bugzilla item +22:06:25 <@duck> or dunno +22:06:34 <+ugha2p> The Java process consumes 100% of CPU for about half of the time. +22:07:18 <+ugha2p> So, you don't know anything about the issue? Do your routers behave OK? +22:07:24 < dinoman> yea it is high for me to -6 +22:08:24 <@duck> top/uptime info is behaving weird for me since my nptl upgrade, so cant say +22:09:03 <+ugha2p> Ok, maybe we should move on? +22:09:07 <@duck> ok +22:09:14 <@duck> 2) i2p-bt +22:09:24 <+ugha2p> And ask jrandom when he is about to release 0.4.2.3 +22:09:40 <+ugha2p> It has worked fine for me with NPTL. +22:09:45 <@duck> ugha2p: he said tomorrow or thursday +22:09:58 <+ugha2p> Right. +22:09:59 <@duck> yesterday I released a new i2p-bt +22:10:23 <@duck> I gained some new understanding of the whole 'buffer' concept +22:10:42 <@duck> plus there were some previous pending patches from Ragnarok +22:11:13 < mule> duck: congratulations, good work! +22:11:15 <@duck> also the slice size is increased, which means that instead of sending 32KB each time, it sends 128KB +22:11:29 <@duck> which should keep the queue filled +22:11:47 <+ugha2p> Yeah, thanks, duck. :) +22:11:56 <@duck> DrWoo and others filed some GUI feature requests +22:12:23 <@duck> but I never use the GUI myself, wouldnt know wxpython and probably dont care too much :) +22:12:31 <+Ragnarok> fitting each slice into a single message didn't work as well as expected? +22:12:57 < clayboy> many seeded torrents on http://brittanyworld.i2p/bittorrent/ if anyone want to try (with i2p 0.4.2.2-7 and i2p-bt 0.1.3) +22:13:10 <@duck> Ragnarok: it is a bit of a guess +22:13:27 <@duck> it gives much higher throughput values on local transfers +22:13:51 <+ugha2p> Maybe we should wait for someone to port a full-featured client instead? +22:14:10 <+Ragnarok> hm, ok +22:14:13 <@duck> we can all wait :) +22:14:37 < clayboy> BitTorrent _is_ "full featured", it's the only client i use for bt (also off i2p) :) +22:15:15 <+ugha2p> clayboy: Not really. :) +22:16:02 <@duck> personally I prefer things with sound defaults +22:16:17 <@duck> take mldonkey, you can change 1 million things and most users have no idea what they do +22:16:50 <@duck> this leads to user-myths, like i2p users hitting 'Reseed' all the time, or reinstalling if it doesnt work +22:17:01 <+ugha2p> If you aren't willing to find out, then you shouldn't be using Linux anyway. :) +22:17:04 <@duck> which kills kittens +22:17:28 < slart> what about bittornado? +22:17:43 <+Ragnarok> I suppose I could be tempted to write a pygtk gui, but I've got a lot of other stuff to do, and I'm not sure what people want +22:17:45 <+protokol> azureus? +22:17:57 <@duck> part of me is ofcourse making up excuses not to do things +22:18:03 <+protokol> azureus supports plugins +22:18:10 <@duck> protokol: well, write a plugin +22:18:32 <+protokol> heh +22:18:40 < slart> bittornado is based off the offical bt isnt it? +22:18:50 <+protokol> easier said than done +22:18:52 <@duck> slart: I have looked at it and wept +22:19:07 <@duck> it has some improvements, which might be useful +22:19:17 <@duck> but on the other hand it made the whole thing way more complex +22:19:22 <@duck> without cleaning up the original code +22:19:36 <+Ragnarok> gah +22:19:56 <@duck> the GUI feature that you can specify a torrent if no arguments are given is taken from it and added to i2p-bt +22:20:11 < clayboy> let's get the basic bittorrent working excellently before worrying about these fluffy gui things :) +22:20:46 <@duck> slart: probably some other things can be used too; someone just has to do it (properly) +22:21:23 <+ugha2p> clayboy: Well, I think it already does work excellently. :) +22:21:53 < slart> the abc client uses tornado (i think) +22:22:15 < clayboy> i feel like we have still to do some really heavy-duty testing to see how much data can really be pushed through i2p-bt +22:22:21 < bushka> yes it does slart. +22:23:49 <@duck> depending on how those work, you might be able to port the i2p-bt changes to them quite easily +22:24:41 <@duck> please give it a try and report back +22:25:47 <@duck> . +22:25:55 <@duck> any other i2p-bt / bittorrent comments? +22:26:08 < slart> python :S +22:26:41 <+ugha2p> . +22:26:51 <@duck> slart: if you dont like python, you can give porting azureus a try +22:27:00 <+ugha2p> slart: What about it? +22:27:06 < slart> how many people could we get seeding somthing like a linux is for speed testing? +22:27:15 < slart> *iso +22:27:34 <@duck> lets try that after the new i2p release +22:27:57 <@duck> (since pulling an i2p router build from cvs is quite a challenge for most) +22:28:17 <+protokol> eh +22:28:54 <@duck> pl +22:28:57 <@duck> err, ok +22:29:10 <@duck> 3) #idlerpg +22:29:22 <@duck> found this funny irc rpg game +22:29:36 <@duck> you dont have to do anything for it, just idle +22:29:56 <+ugha2p> Well, you do have to LOGIN. ;) +22:30:04 <@duck> ah ;) +22:30:18 < mule> cvs update -dP :) +22:30:18 < mule> ant dist updater :) +22:30:20 <+postman> it's the most hilarious thing i've ever seen, but i LIKE it :) +22:30:30 <+protokol> there should be prizes +22:30:45 <@duck> on ircnet it has 779 online players +22:30:46 <+ugha2p> duck: I was thinking, that it could potentially be a reason not to upgrade. +22:30:52 <+protokol> give yodels for winning stuff or reaching levels +22:31:03 <+ugha2p> Although I'm not sure if people on I2P could be that childish. :) +22:31:14 <+protokol> i know duck has like $10000 in yodels +22:31:18 <@duck> protokol: yeah, I have to see how those quests work +22:31:39 <@duck> maybe we can do some fun stuff with it +22:31:42 <@duck> ugha2p: what do you mean? +22:31:49 < ant> * cervantes is not going to do another 40 days without restarting his router +22:32:08 <@duck> ugha2p: oh, not update because of the game :) +22:32:18 <+protokol> Linux: If you can't fix it without restarting, you can't fix it. +22:32:20 <@duck> well, I'll put it on pause while my router restarts +22:32:24 <+ugha2p> :) +22:32:33 <@duck> so if you sync it well, you wont lose +22:32:35 <@duck> hehe +22:32:55 < ant> <cervantes> thats good... since your router restarts all the time :P +22:33:16 <@duck> thats called dedicated testing :) +22:33:20 < ant> <cervantes> I guess that throws roulette into the equation too +22:33:23 <@duck> ok +22:33:38 <@duck> . +22:33:49 <+ugha2p> . +22:34:05 <@duck> 5) ??? +22:34:08 <@duck> s/5/4/ +22:34:12 <@duck> open mike! +22:34:23 <+postman> . +22:34:53 < mule> with a bit of tweaking you can two routers. one for the game only, which you upgrade only every year +22:34:53 <@duck> questions? comments? suggestions? +22:35:38 < ant> <mahes> Hi, i have a general non-dev question +22:36:08 <@duck> shoot +22:36:08 <+ugha2p> Thanks for holding the meeting, duck. +22:36:50 < ant> <mahes> if i set up an eepsite , how can be reached with an address like i.e mahes.i2p +22:36:59 <+protokol> i have a consern +22:37:44 <+protokol> (start the battle) i think .i2p is a shitty TLD for many reasons +22:38:19 <+ugha2p> mahes: What do you mean 'how'? People will configure their browsers to use the eepproxy, and just enter http://mahes.i2p/ onto their address bar. +22:38:19 <+protokol> i think we should use one that is a) one syllable b) can be pronounced like a word c) does not include a number' +22:38:46 <+ugha2p> protokol: Like .eep? +22:39:07 <@duck> mahes:: to get a 'nice name' to point to your eepsite, it has to be present in your hosts.txt file +22:39:37 <+protokol> ugha2p: sure +22:40:01 <+ugha2p> protokol: You can make a proposal on the mailing list. +22:40:03 <@duck> you can post it on the eepsite announcement forum so others can get it too +22:40:09 <+ugha2p> It'll probably be considered once we have MyI2P. +22:40:35 <+protokol> heh, ill try but jr shot it down for some reason already +22:41:06 < ant> <mahes> well. i am just a user... ok, so i just publish mahes.i2p=hhfbwer8328... and it will just spread +22:41:32 <@duck> it doesnt spread automatically, ppl need to get it into their hosts.txt somehow +22:41:39 < ant> <mahes> ok +22:41:52 <@duck> but announce it on the forum and it is more likely to :) +22:42:34 <@duck> . +22:43:18 <@duck> lets give it a *baf* +22:43:20 <+ugha2p> . +22:43:30 * ugha2p is waiting for the baffer. +22:43:38 * duck winds up +22:43:45 * duck *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/119.rst b/i2p2www/meetings/logs/119.rst new file mode 100644 index 00000000..53ef4934 --- /dev/null +++ b/i2p2www/meetings/logs/119.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 7, 2004 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/12.log b/i2p2www/meetings/logs/12.log new file mode 100644 index 00000000..0726cb69 --- /dev/null +++ b/i2p2www/meetings/logs/12.log @@ -0,0 +1,610 @@ +--- Log opened Wed Sep 25 00:57:27 2002 +00:57 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ +00:57 [Users #iip-dev] +00:57 [@mids] [ Dag] [ logger] [ nemesis] [ nop] [ Zwolly] +00:57 -!- Irssi: #iip-dev: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +00:57 -!- Irssi: Join to #iip-dev was synced in 1 secs +00:58 -!- mode/#iip-dev [+v logger] by mids +01:00 <@mids> Tue Sep 24 23:00:38 UTC 2002 +01:00 <@mids> welcome et all +01:00 <@mids> the 12th meeting just started +01:01 <@mids> agenda: +01:01 <@mids> 1) website +01:01 <@mids> 2) nop's messages +01:01 <@mids> 3) question round +01:01 <@mids> website: +01:01 <@mids> new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/ +01:02 <@mids> for those who just joined: +01:02 <@mids> new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/ +01:02 <@mids> geeh +01:02 <@mids> I keep busy +01:02 < nop> ok +01:02 < nop> pause a sec +01:02 <@mids> for those who just joined: +01:02 <@mids> hehe +01:02 < nop> just add it to topic +01:03 < nop> ok +01:03 < nop> go +01:03 < nop> ;( +01:03 -!- mids changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/ +01:03 < nop> ;) +01:03 <@mids> . +01:04 -!- mode/#iip-dev [+o nop] by mids +01:05 <@mids> any questions about this topic? otherwise we'll go to #2 +01:06 <@nop> ok +01:06 <@nop> thanks to ellison +01:07 <@nop> and the distributedcity crew +01:07 <@nop> for helping out +01:07 <@nop> with the website +01:07 <@nop> we owe them a lot now ;) +01:07 <@nop> ok +01:07 <@nop> rc2 is coming out tomorrow +01:07 <@nop> we're just packaging it up +01:07 <@nop> and getting it ready for release +01:07 <@nop> new features +01:07 <@nop> are Forward Security +01:08 <@nop> Close Delay protocol for killed connections +01:08 <@nop> some bug fixes +01:08 <@nop> and upgrade features for future versions +01:08 <@nop> I think that's about it +01:08 <@nop> thank you all you users +01:08 <@nop> that use IIP +01:08 <@nop> without you +01:08 <@nop> the project would be a waste +01:08 <@nop> ;) +01:09 <@nop> so thank all of you for your loyalty and support by using the software +01:09 <@nop> I think that's it for my daily comments ;) +01:09 <@nop> oh +01:09 <@nop> wait +01:09 <@nop> thank you mids +01:09 <@nop> for assisting me with the website setup +01:09 <@nop> and for being patient with me +01:09 <@nop> thank you codeshark +01:09 <@nop> for setting up the software +01:09 <@mids> your welcome :) +01:09 <@nop> and handling inform +01:09 <@nop> thank you userx wherever you ar +01:10 <@nop> are +01:10 <@nop> for your hard work on core development +01:10 <@nop> and putting up with my ranting ;) +01:10 <@nop> thanks to chocolate +01:10 <@nop> for the informity and scripts that are needed +01:10 <@nop> thanks to cohesion even though long gone, for documentation in the past +01:10 <@nop> umm, like to thank the academy ... j/k +01:11 <@nop> everyone who has contributed thank you all +01:11 <@nop> . +01:11 <@mids> 3 hurrays for nop +01:11 <@mids> hurray +01:11 < Zwolly> hurray +01:11 < thecrypto> huzzah +01:11 <@nop> haha +01:11 < athena> that's 2 hurrays and 1 huzzah +01:11 <@nop> oh and DC people have been whispering in my ear to thank the Lord +01:11 <@nop> ;) +01:12 < Neo> lol +01:12 <@nop> well, on a side note, thank life for it is a neat thing ;) <-- no comments +01:12 <@nop> . +01:13 <@nop> any questions +01:13 <@nop> suggestions +01:13 <@nop> review +01:13 <@nop> ideas +01:13 <@nop> etc +01:13 < Neo> congratulations on the new site, looks great. +01:13 <@nop> ? +01:13 <@nop> thnx +01:13 <@mids> what is forward security? +01:13 <@nop> encryption can only be decrypted at time of session +01:13 <@nop> aka, you can't replay the messages +01:13 <@nop> and decrypt them +01:14 <@nop> as that key and signature doesn't exist anymore +01:14 <@nop> and will not be useful +01:14 <@nop> this is designed against log and replay attacks +01:14 <@nop> . +01:14 <@mids> thx +01:14 < athena> will you require public proxies to support these new protocol additions? (methinks all proxies should be forced to upgrade) +01:14 <@nop> athena +01:14 <@nop> it's a mandatory upgrade +01:14 <@nop> all relay holders +01:14 <@nop> will need to upgrade +01:15 <@nop> to rc2 relay +01:15 <@nop> and re-announce +01:15 < athena> ok, thanks +01:16 < sferic> I guess I cam ein late and missed something, but do you mean that we can't log anymore? +01:16 <@nop> no +01:16 <@nop> you can log +01:16 <@nop> what I'm saying +01:16 <@nop> is +01:16 <@nop> if you were a gov't agent +01:16 <@nop> spying on a relay +01:16 <@nop> and you were logging the encrypted traffic +01:16 <@nop> you couldn't then come and seize the ircd end node +01:16 <@nop> and use the network secret key +01:16 <@nop> to replay the traffic +01:16 <@nop> and decrypt it +01:17 < sferic> Ahh, thanks +01:17 <@nop> it eliminates the importance of the network secret key +01:17 <@nop> it's useless +01:17 <@nop> all it does is authenticate +01:17 <@nop> nothing more +01:17 <@nop> doesn't actually encrypt +01:17 <@nop> this covers two things +01:17 <@nop> man in the middle attack protection +01:17 <@nop> and log and relay protection +01:17 <@nop> aka forward security +01:17 <@nop> ;) +01:17 < Zwolly> is it now without central server. +01:18 <@nop> not yet +01:18 <@nop> that's 1.22 +01:18 <@nop> 1.2 +01:18 <@nop> correction +01:18 <@nop> 1.2.0 to be exact +01:18 <@nop> ;) +01:18 <@nop> after 1.1 basically is finished +01:18 <@mids> (I'd say that decentralization is 2.0) +01:19 < Zwolly> how about system resources memory cpu and bandwith +01:19 <@nop> well, 2.0 is a more perfect form of decentralization +01:19 <@nop> 1.2 we will attempt decentralization +01:20 < Tanthrix> how does true p2p work, you can't exactly scan IP blocks until you find someone? isn't some sort of a central server neccessary for initial connection? +01:20 <@nop> bootstrap is needed +01:20 <@nop> but once connected +01:20 <@nop> you have your own peer routes +01:20 <@nop> so we include a small node.ref +01:20 <@nop> which connects you in +01:20 <@nop> then from that point +01:20 < athena> thanthrix: find some friends you trust and trade node.refs :) +01:20 <@nop> you are dynamically updated from the network +01:21 <@nop> yes +01:21 <@nop> that's the idea +01:21 <@nop> in a nice world +01:21 <@nop> ;) +01:21 < Tanthrix> hehehe +01:21 <@mids> what if you dont have friends? +01:21 <@nop> then try to trust the signature on our software ;) +01:21 <@nop> haha +01:21 <@nop> yeah right, digital trust is rarely possible +01:22 < Dag> trust no one +01:22 < Dag> heh +01:22 < athena> awww...i'll be your friends, mids! +01:22 <@mids> hurray +01:22 < athena> huzzah +01:22 < Tanthrix> and grey-eyed athena comes to the rescue.. +01:22 <@nop> hehe +01:22 <@nop> this website kicks ass +01:22 <@nop> far difference then the previous one +01:23 <@mids> kinda :) +01:23 <@nop> umm +01:23 <@nop> yeah +01:23 <@nop> that nice little under construction site sucked ass +01:24 < Tanthrix> heh..the new invisiblenet site looks like a page for some web-based corporation +01:25 <@mids> thanks... I guess :) +01:25 * mids points at ellison ... he is the one to blame; he gets all fame +01:25 < Tanthrix> hehehe +01:25 * ellison hides under some eye candy in the corner +01:26 < Zwolly> what is the gues about how stable it will be +01:26 <@mids> Zwolly: Trent is running on a rc2 relay for 2 days now +01:26 <@mids> without trouble +01:27 < Zwolly> ok. +01:27 <@mids> trent is the irc client/service with the heaviest traffic +01:27 <@mids> so... I think it is okay +01:27 < Zwolly> we will see +01:27 <@nop> the reason +01:27 < Zwolly> is it tomorrow already? hehe +01:28 <@nop> for the middle of the road +01:28 <@nop> corporate looking site +01:28 <@nop> is called steganography +01:28 <@nop> ;) +01:28 <@nop> our evil black hat activities +01:28 <@nop> wouldn't be good +01:28 <@nop> if it's obvious +01:28 <@nop> we're evil +01:28 <@nop> now would it +01:29 <@nop> so we blend in with the other evil +01:29 <@nop> and they won't notice us +01:29 <@nop> ;) +01:29 <@nop> honestly though +01:29 <@nop> it's just for attracting all audiences +01:29 <@mids> in 2 month there will be an invisibleNET sponsored golf tournament +01:29 <@nop> hahaha +01:30 <@nop> oh and the palladium efforts +01:30 <@nop> we bought it out +01:30 <@nop> ;) +01:31 <@nop> if you've noticed +01:31 <@nop> we own www.invisiblenet.net, www.invisiblenet.com, and www.invisiblenet.org +01:31 <@nop> we're evil +01:31 <@nop> ;) +01:31 <@nop> we've monopolized the market +01:31 <@nop> we're bastards +01:31 < Dag> what about getting one of those signs on the highway for cleaning up the roadside? +01:31 <@nop> yeah +01:31 <@nop> that's in the works +01:31 <@nop> as well as OEM'ing with Microsucks, and Intel +01:32 <@nop> haha +01:32 <@mids> euh +01:32 <@mids> you okay nop? :) +01:32 < Zwolly> ok other question what to do if there are warez channels and some big stupid country lets say america for example want this network doun can it run on its own from the european nodes +01:32 <@nop> yeah +01:32 <@nop> yes +01:32 <@nop> it will be possible to do that +01:33 <@nop> plus +01:33 <@nop> I advise for all warez activity +01:33 < Dag> I thought there was no /dcc +01:33 < Dag> in here +01:33 <@nop> to use a !anonymous mode channel +01:33 <@nop> doesn't mean you can't trade ftp sites +01:33 < Dag> well +01:33 <@nop> then for anyone monitoring +01:33 <@nop> who is saying what +01:33 < Dag> google trades warez ftp sites +01:33 <@nop> is a bit more tricky +01:33 <@nop> ;) +01:33 <@nop> exactly +01:33 < Dag> so does the newsgroups +01:33 <@nop> I doubt that we're a threat to that +01:33 < Dag> er do +01:33 <@nop> our main concern is #pedophilia public channels +01:34 < Dag> I did a /list one day +01:34 <@nop> as they would be a concerned threat to the existance of IIP as a whole +01:34 < Dag> and saw that channel in the list +01:34 <@mids> nah +01:34 < Dag> was a month or so ago +01:34 <@mids> I wouldnt be too affraid about that +01:34 <@nop> I like as little trouble as possible while were developing +01:34 <@mids> this is pure text based +01:34 <@nop> true +01:34 < nemesis> k +01:34 < nemesis> brb +01:35 * nemesis decides to go out and tar the way to the loung ()ŻŻŻŻ)ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ)))~~~~ +01:35 < Dag> freenet has been overwhelmed with that crap +01:35 < Dag> at least last time I used frost +01:35 < Dag> it was a VERY high percentage of that crap on there +01:35 < athena> comes with the territory +01:35 < Dag> I think it would be good for people to spam freenet with random non porn images and media files +01:36 <@nop> yeah +01:36 <@nop> it's unfortunate +01:36 < Dag> just to make the percentage of crap go down +01:36 <@mids> I am using freenet for 3 or 4 years now and I have never seen any pedo crap... +01:36 <@nop> I accidentally downloaded trash on my hardrive because of their shit +01:36 <@nop> sickening +01:36 <@nop> I found one +01:36 <@mids> if you dont look for it, I dont think you will run into much +01:36 <@nop> by accident +01:36 <@nop> not true +01:36 <@nop> stuff gets renamed stuf +01:37 < Dag> mids I just had frost list all the files available +01:37 < Dag> as there are not many +01:37 < Dag> maybe a few hundred files max +01:37 < Dag> its not like gnutella +01:37 <@mids> well, if you view each of them.. you will probably run into stuff +01:37 < Dag> I didnt download anything +01:37 <@mids> but I have no reason to view a msc0001a.jpg +01:38 < Dag> I just saw the listings +01:38 < ellison> you guys seen www.bitzi.com? +01:38 < Dag> no +01:38 < Dag> isnt that some spyware +01:38 < ellison> it is a database of tons of files on p2p networks +01:38 < athena> no +01:38 <@nop> mids +01:38 < athena> the fingerprint mp3s +01:38 <@nop> check iip-dev +01:38 < ellison> you can enter a filename and size, and it'll tell you what it is +01:38 <@nop> this can't be true +01:38 <@nop> we have a few debian users +01:38 <@mids> nop: iip-dev email? +01:38 <@nop> yes +01:38 < Dag> ellison who is funding it? +01:39 < ellison> dag: dunno +01:40 < Dag> ellison I would bet its the riaa +01:40 < ellison> "Bitzi is a privately-held metadata publishing company based in San Francisco." +01:40 < Dag> or some such org +01:40 < Dag> ellision who pays the bills +01:40 < Dag> follow the $$$$$ +01:40 < ellison> doubt it, I think you can use their service to differentiate between valid media files and the fake stuff uploaded by RIAA +01:41 < ellison> the founder posted on a RIAA thread and mentioned this use of the system +01:41 < Dag> find out who funds it +01:41 < ellison> i brought up their site because it seems to be a good way of avoiding nasty re-named stuff +01:41 < athena> bitzi is cool... their stuff is opensource +01:41 < Dag> one thing is certain in this day and age +01:41 < ellison> there's no reason you couldn't submit freenet files to the service +01:42 < ellison> dag: there would be concern if there was any evidence that they are funded by the RIAA, but it doesn't look like it to me +01:42 < Dag> ellison a md5->file content database +01:42 < Dag> would maybe work +01:42 < Dag> but can be abused as well +01:42 < Dag> its all about who controlls the data +01:43 * athena controls the data +01:43 < Dag> mallicous people can change the file slightly anyhow +01:43 < ellison> if course there is an issue of trust, but if you don't trust anyone then it'll be difficult to take part in a service-based economy... +01:43 < ellison> then the signature would change +01:44 < Dag> yes +01:44 < Dag> I am addressing your wanting to avoid known bad files +01:44 < ellison> if lots of people use bitzi, then all it takes is one person downloading and reporting a bad file +01:45 < Dag> I could write a gnutella server to on the fly randomly tag on some byte +01:45 < Dag> to a file +01:45 < ellison> and bitzi will be a more and more valuable service as the RIAA begins seeding P2P networks w/ crap... +01:45 < Dag> and change the file sig each time +01:45 < athena> bitzi is being integrated into limewire +01:45 < ellison> people could go to bitzi and find out which files are the good ones, and only download those +01:45 < Dag> I think that the riaa would find the service more usefull than not +01:46 < Dag> they are doing the riaas job for them +01:46 < ellison> it's also about finding the good ones - avoiding the bad ones is just 1/2 of the process +01:46 < Dag> finding keys to stuff they own +01:46 <@mids> hey aum +01:46 < aum> hi mids +01:47 <@nop> aum +01:47 <@nop> it's most likely +01:47 <@nop> the dh key exchange +01:47 <@nop> maybe handshaking with a bad or out of date node, or so +01:47 < aum> the max-out doesn't happen when i run iip as root +01:47 < aum> only when i run as user +01:47 <@nop> interesting +01:47 < athena> huh? +01:47 <@nop> have you checked your file descriptors for users +01:47 <@nop> how many are allowed and such? +01:48 < aum> well, all the files are owned by the same user as is running the daemno +01:48 < aum> it's a severe max-out when i run as user - a 1.5GHz box grinds to a halt - even the mouse can barely move +01:49 < Zwolly> people i need to go now it was fun and will install the new IIP as soon as possible (working at 7.00) +01:49 < aum> compliments on the new website nop +01:49 <@nop> thnx, thank ellison +01:50 <@nop> he did it +01:50 <@nop> ;) +01:50 < aum> it looks so professional that one could expect to go to the download page, and see a link saying 'download 30-day demo' +01:50 < aum> free software websites are rarely designed so professionally +01:50 <@mids> :) +01:50 <@nop> nor are they documented so well either +01:51 <@mids> nor do they have such cool irc channels +01:51 <@nop> we have kind of put the profesionallism back into open source ;) +01:51 <@nop> I spelled that badly +01:51 <@nop> haha +01:51 < aum> the word 'free' needs to appear on the front page IMO +01:51 <@nop> Professionalism +01:51 <@nop> it says open +01:51 <@nop> and available +01:51 <@nop> etc +01:51 < aum> the word 'open' is being used more and more with commercial software +01:51 <@nop> well, if people don't read +01:51 <@nop> they can't be educated +01:52 <@nop> and they shouldn't be running IIP anyway +01:52 < ellison> :-) +01:53 < aum> i saw a freaky film the other night - 'fight club' +01:53 <@nop> finally? +01:53 <@nop> haha +01:53 <@nop> read the book +01:53 <@nop> it's worse +01:53 < aum> wow! +01:53 <@mids> night all +01:53 < aum> good concept - taking down the credit card databases +01:53 < aum> night mids +01:53 < ellison> night mids +01:54 <@nop> night mids +01:54 <@nop> thnx again +01:54 <@nop> for your help +01:54 < nemesis> gn8 mids +01:54 * aum wonders if iip can take advantage of palladium features +01:55 * nop wonders what aum means by that +01:55 < aum> palladium could be a huge boon for p2p +01:55 <@nop> yes +01:55 <@nop> did you get my ip stego app? +01:55 < aum> palladium creates a private task space that not even root can access +01:55 < aum> back in 5... +01:55 <@nop> k +02:02 <@nop> ok +02:02 < aum> back +02:02 <@nop> wb +02:03 < aum> palladium can help piracy +02:03 < Dag> anyone here run vmware? +02:03 <@nop> I'm not convinced that palladium will be secure against the security researchers of the world +02:03 < aum> yes +02:03 <@nop> I do +02:03 <@nop> I run it +02:03 < aum> ditto +02:03 < Dag> how good a sandbox is it? +02:03 <@nop> great +02:03 < aum> brilliant +02:03 <@nop> I use it for my windows stuff +02:03 < Dag> that is my only real interest for it +02:03 <@nop> while running linux as the main one +02:03 <@nop> oh yeah +02:03 < Dag> is a sandbox potentia; +02:04 <@nop> yes +02:04 <@nop> it's great +02:04 <@nop> easy to set up too +02:04 < aum> beautiful thing about vmware is that you can choose to discard all disk changes +02:04 < Dag> well +02:04 < Dag> i imagine it leaks data to the swap +02:04 < aum> so if you install some windows fuckware, it's easy to get rid of it without having to hunt through c:\windows and registry etc +02:04 < Dag> well yes +02:05 < Dag> just delete the install +02:05 < Dag> I keep a good install file +02:05 < Dag> that has nothing on it +02:05 < aum> i like how vers 3 does usb +02:06 < Dag> its an amazing little app +02:06 < Dag> wish it was open sourced +02:06 < Dag> I looked at some open source attemps +02:06 < Dag> at the same thing +02:07 < Dag> and seemed to be stagnating +02:07 < Dag> bochs and the like +02:07 < aum> bochs is a nightmare +02:07 < nemesis> AS/400 are better than vmware ;p +02:08 < Dag> plex86 was another one I think +02:08 < Dag> I have run vmware and ran some tools like filemon and regmon +02:08 < Dag> etc +02:09 < Dag> and they seem to show that its a decent sandbox +02:09 < Dag> its not writting or reading to anything unusual +02:09 < Dag> from waht I saw +02:09 < Dag> winternals software rules +02:09 < Dag> sysinternals/winternals that is +02:10 < Dag> tcpview pro is another of their tools I like +02:10 < Dag> erd commander is another +02:11 < Dag> I am hoping someday soon that linux/bsd can have better ntfs support +02:12 < Dag> read only access (stable) is pretty limiting +02:14 <@nop> I'm so excited +02:14 <@nop> this toorcon speech might get me killed ;) +02:14 < nemesis> hrhr +02:14 < nemesis> nooo nooo +02:15 < nemesis> i linke the read only +02:15 <@nop> sorry +02:15 <@nop> I'm all interrupting +02:15 <@nop> ;) +02:15 < nemesis> because i stored some files in a ntfs5.1 part +02:15 < nemesis> ;) +02:15 < aum> nop - you better have a fast car out the back, and deliver the speech in a ski mask +02:16 <@nop> did you read what I'm talking about +02:16 <@nop> www.toorcon.org +02:16 < aum> actually, a ski mask would be a good gimmick - that, and a throat-mike wired up to a harmoniser box to change your voice +02:16 <@nop> and no I don't care if people know who I am, it's a risk I have to take for starting IIP anyway +02:17 <@nop> haha +02:17 <@nop> I have a friend who's an expert in make-up and disguise +02:17 <@nop> could do that too +02:17 < Dag> nop is it tammy faye"? +02:17 < Dag> katherine harris? +02:17 < aum> room will be fulla spooks +02:18 <@nop> http://www.toorcon.org/speakers/james.html +02:20 <@nop> making gov't irrelevant is the underlying tone +02:21 <@nop> I contradict the keynote speaker +02:21 <@nop> who works for nasa +02:23 < Dag> nasa is evil +02:23 < Dag> richard hoagland says so +02:23 < Dag> they are withholding proof aliens exist +02:24 <@nop> hehe +02:24 < Dag> they bombed the face on mars +02:24 <@nop> aum is quiet +02:24 <@nop> hehe +02:24 < Dag> to cover up that it really looked like a face +02:24 < Dag> even in high res scans +02:25 < Dag> if it were not for nasa, we would each have our own starship cruisers +02:25 < Dag> and vacation planets as we speak +02:25 < Dag> hell they even wont let that backstreet boy +02:25 < Dag> on their stupid space station +02:25 <@nop> haha +02:25 <@nop> nsync but yeah +02:26 < Dag> they dont want him to see who their real masters are +02:26 <@nop> haha +02:26 < Dag> and I dont mean the american taxpayer +02:26 <@nop> yep +02:27 < Dag> the government is not run by the taxpayer +02:27 <@nop> you know what I notice +02:27 <@nop> every corporate position in a company +02:27 < Dag> I think the fairest govt would be one were the number of votes you have is in line with the taxes you pay +02:27 <@nop> is desired by a selfish person +02:27 <@nop> right +02:27 < Dag> maybe 1 vote for each 5k in taxes you pay +02:28 < Dag> the government is run on theft +02:28 < Dag> steal steal steal +02:29 < Dag> rms is a commie too +02:29 < Dag> did you know that +02:29 <@nop> that's why they punish drug dealers +02:29 <@nop> because the gov't is stealing the money they make +02:29 <@nop> you notice +02:29 <@nop> they always wait +02:29 <@nop> till the dealer +02:29 <@nop> is making big money +02:29 <@nop> to get their bust +02:29 <@nop> they don't care about the lowly pot dealer +02:29 <@nop> they always like to let it continue +02:29 <@nop> till they know +02:29 < Dag> the us govt is the biggest drug dealer out there +02:29 <@nop> there is serious money coming in +02:30 <@nop> then bam +02:30 <@nop> robbin' from the dealer +02:30 < Dag> bo gritz says so +02:30 < Dag> harry brown for president +02:30 < Dag> enuf said +02:30 <@nop> hehe +02:30 <@nop> charlie brown for president +02:31 < Dag> what about snoopy +02:31 <@nop> he's cool +02:31 <@nop> he doesn't say much +02:31 <@nop> so yeah +02:31 < Dag> he always seemed level headed +02:31 < Dag> cept he hung out with that bird a little to much +02:31 < Dag> charlie brown was easily duped +02:32 < Dag> how many times he try to kick that damn football? +02:33 * aum is back +02:33 < Dag> how big is a freenet install? +02:33 <@nop> not big, 200 megs +02:33 <@nop> for datastore +02:33 <@nop> ;) +02:33 < aum> default freenet datastore is 1GB these days +02:34 < Dag> yikes +02:34 <@nop> what? +02:34 < aum> on another subject, i uninstalled gentoo last night and went back to debian => bliss +02:34 <@nop> really? +02:34 < aum> the source-based distros are too flaky just now +02:34 < Dag> go back to freebsd +02:35 < Dag> er forward +02:35 < Dag> heh +02:35 < aum> debian 4 me - huge catalog of software, ready to urn +02:35 < aum> s/urn/run/ +02:35 < Dag> well you running it as a server or desktop? +02:35 < aum> debian stuff works wight out of the box - no need to read megs of manuals and grope through scripts +02:36 < Dag> I always compile my servers +02:36 < aum> i've had debian woody on my server for over a year - switched desktop from windows back in feb +02:37 < aum> my desktop went windoes -> mandrake -> debian -> sourcemage -> gentoo -> debian +02:37 < Dag> you ever try knoppix? +02:37 < aum> what's that? +02:37 < aum> a distro? +02:37 < Dag> is a livefilesystem linux distro +02:37 < Dag> based off debian +02:37 < aum> huh? +02:37 < aum> what does 'livefilesystem' mean? +02:37 < Dag> the whole thing runs in ram and cd +02:38 < Dag> boot off the cd +02:38 < Dag> and away you go +02:39 < Dag> its pretty good about hw detection +02:39 < Dag> runs kde and even has openoffice +02:39 < Dag> heh +02:39 < Dag> I dont run any linux servers anymore +02:39 < Dag> but its fun to have around +02:39 < aum> Dag: freeBSD? +02:40 < Dag> free/openbsd +02:40 < Dag> solaris +02:40 < aum> what's the big advantage? +02:40 < Dag> depending on HW +02:40 < Dag> openbsd has a good security audit +02:40 < Dag> of anything they release +02:40 < Dag> no distro of linux even comes close +02:41 < aum> but linux 'ploits get fixed within 24 hours +02:41 <@nop> true +02:41 < Dag> do you check for exploits and patch every day? +02:41 <@nop> I do +02:41 < Dag> well +02:41 < Dag> come now +02:41 < Dag> heh +02:41 <@nop> I'm on bugtraq +02:41 <@nop> and I sometimes post +02:41 <@nop> so I keep my eye out +02:42 < Dag> openbsd has had ONE remote exploit in 6 years +02:42 <@nop> it's my daytime job +02:42 <@nop> openBSD is very conscious +02:42 <@nop> which is good +02:42 <@nop> proves +02:42 <@nop> that all it takes +02:42 <@nop> is more conscious coders +02:42 <@nop> and a conscious framework +02:43 < Dag> if you install redhat without patches +02:43 < Dag> its a guarantee you will be hacked +02:43 < Dag> I use to work in a NOC +02:43 < Dag> it would piss me off when other lazy coworkers would install rh 6.2 etc +02:43 < Dag> for a client +02:44 < Dag> and never put any patches on +02:44 < Dag> one guy worked there 3 years and his idea of rebooting a box was to hit the power switch +02:46 < aum> power switch? did he think it was windows? +02:46 < nemesis> lol +02:46 * aum sometimes sees the linux BSOD screensaver +02:47 < Dag> there was a time like 4 years back that anyone could get a tech job +02:47 < Dag> now people who have a brain and experience +02:47 < Dag> cant find sh*t +02:47 < aum> an open source advocate here in new zealand wrote to the Minister for Information Technology expressing concerns about windows security vulnerabilities - Minister wrote back saying "we don't have a security problem - we use firewalls" +02:48 < Dag> you hear the latest with XP and their help center allowing you to delete files by visiting a url +02:48 < Dag> heh +02:48 < Dag> there is a story at the register uk about it +02:49 < Dag> there is even a link to have the exploit remove the help center from your machine +02:49 < Dag> and in doing so removes the ablity to be exploited +02:50 < Dag> Win-XP Help Center request wipes your HD +02:50 < Dag> http://www.theregister.co.uk/content/4/27074.html +03:03 < nemesis> erm, sorry +03:03 < nemesis> question +03:03 < nemesis> can i ban an port with bind to an nic? +04:14 < nemesis> cu@all für genau 50 mins ins bett legen dann duschen und in arbeit fahren *grummel* +08:05 < nop> sheesh +08:05 < nop> still here +--- Log closed Wed Sep 25 10:20:49 2002 diff --git a/i2p2www/meetings/logs/12.rst b/i2p2www/meetings/logs/12.rst new file mode 100644 index 00000000..76704df5 --- /dev/null +++ b/i2p2www/meetings/logs/12.rst @@ -0,0 +1,9 @@ +I2P dev meeting, September 24, 2002 @ 23:00 UTC +=============================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/120.log b/i2p2www/meetings/logs/120.log new file mode 100644 index 00000000..87ebb10c --- /dev/null +++ b/i2p2www/meetings/logs/120.log @@ -0,0 +1,484 @@ +13:08 < jrandom> 0) hi +13:08 < jrandom> 1) Net status +13:08 < jrandom> 2) mail.i2p +13:08 < jrandom> 3) roadmap +13:08 <+polecat> It's almost as if the nodes are using the time they got 5 min ago, and setting it to the current time instead of the real time. +13:09 < jrandom> 4) i2pcontent +13:09 < jrandom> 5) i2p-bt +13:09 < jrandom> 6) ??? +13:09 < jrandom> 0) hi +13:09 < jrandom> weekly status notes posted a few minutes back to http://dev.i2p.net/pipermail/i2p/2004-December/000522.html +13:09 * Pseudonym waves +13:10 < cervantes> thanks for waiting.... just got back from work ;-) +13:10 < jrandom> polecat: it isnt exactly 5m (but we can discuss further after the meeting or in it) +13:10 * polecat nod +13:10 < jrandom> w3rd, well, i'll give you a moment to jump into the status notes then :) +13:11 < jrandom> in the meantime, 1) Net status +13:11 * postman waves +13:11 < jrandom> the other day, as mentioned on the list, it was pretty turbulent on irc +13:12 < jrandom> we've made some adjustments though and the bugfixes have gone pretty well +13:12 * dm waves +13:12 < jrandom> in addition to the time sync issue mentioned in the mail, there's also a "leases expiring" problem that some have been reporting +13:13 < Pseudonym> are they related? +13:13 <+protokol> (for months) +13:13 < Pseudonym> (the issues, not the people) +13:13 < jrandom> thats due in part to a variety of issues, some of which may be addressed by the patches in CVS, some of which may be time sync related, but most of which are due to issues we're working on for the 0.5 release +13:14 < jrandom> the essence of the problem is that the peer is sometimes unable to build tunnels for the client, which means it won't ask the client for a new lease +13:14 < jrandom> the solution is to make sure we can build new tunnels that meet the client's needs +13:15 < Pseudonym> and if we can't? +13:15 < jrandom> if we can't, the leases will stay expired until we can +13:16 < Pseudonym> so, how is that different? +13:16 < jrandom> it isn't :) +13:16 < jrandom> we need to be able to build tunnels, period. +13:16 < jrandom> to assure that we can, we must both improve our profiling (see: cvs fixes for a long standing profiling bug) and improve our pooling strategy (see: 0.5) +13:17 < jrandom> the only legitimate cause for not being able to build tunnels is if the entire net is completely saturated +13:17 <+polecat> or you're cut off from it +13:17 < jrandom> right +13:17 < bla> jrandom: Can this be because the net has grown to ~110 peers? +13:18 < dm> or its cut off from you +13:18 < jrandom> nah, we've seen this before too bla +13:18 < Pseudonym> are the "cvs fixes for a long standing profiling bug" in 0.4.2.3 or just CVS? +13:18 < jrandom> though in a way, i suppose it is, since we now have a lot more peers that we have no profiling data on +13:18 < jrandom> Pseudonym: CVS +13:19 <+polecat> By profiling you mean ranking peers according to how helpful they are? +13:19 < jrandom> yeah +13:19 * Pseudonym wants 0.4.2.4 ;-) +13:19 <+polecat> Phew. +13:19 <+polecat> Thought it was some weird kinda function tracing like gprof or something. +13:20 * orion wants 2.0 :) +13:20 < jrandom> hehe naw, the profiling bug was in part due to some stupid code that was ignoring daily stats +13:20 * jrandom too +13:20 * polecat wants the larval form of a large dog. +13:20 < jrandom> ok, well, thats about all i've got to bring up for 1) net status - anyone else have anything to add? +13:21 < jrandom> if not, moving on to 2) mail.i2p +13:21 < jrandom> postman: you've got the floor +13:22 <+postman> ok +13:22 <+postman> sorry +13:22 <+postman> :) +13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual +13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual.html +13:23 <+postman> (too much red wine) +13:23 < dm> this is a very unprofessional presentation! +13:23 <+postman> it tries to explain a system how to handle maildomains other than @mail.i2p addresses +13:23 < frosk> :D +13:24 * orion smacks dm in the head with the chalkboard eraser. +13:24 < frosk> does that i can have frosk@frosk.i2p? +13:24 <+postman> frosk: indeed +13:24 < jrandom> v.cool +13:24 <+polecat> The question is, why? :3 +13:24 <+postman> it's quite complex, still i ask for comments and ideas for this one +13:24 < cervantes> s/eraser/ +13:24 < frosk> froody cool +13:25 <+postman> it might not be a needed feature for a few ppl but the future is bright and shiny +13:25 < jrandom> there are lots of reasons why - e.g. giving each user @ forum.i2p a mail address, etc +13:25 < susi23> its a central system bound to postman.i2p +13:25 <+polecat> Yes, that much seems clear. +13:25 < susi23> if that machine fails, we're all upset :) +13:25 <+polecat> jrandom: But if it all has to go through mail.i2p in the first place... +13:25 * postman is VERY aware of this problem +13:26 <+postman> :/ +13:26 < jrandom> polecat: perhaps, but perhaps not +13:26 <+polecat> susi23: exactly! +13:26 <+postman> the recent implementation is indeed quite single point of failure +13:26 <+postman> but this applys to the internet bridge as well +13:27 < jrandom> oh, the second gateway isn't in place yet? +13:27 <+polecat> One solution is to put multiple destinations in the client SMTP/POP3 tunnels, and have all these destinations relay only with each other. +13:27 <+postman> jrandom: no baffled has not setup yet +13:27 < jrandom> ah ok +13:27 <+postman> polecat: and on WHAT pop3 server should YOUR mailbox reside +13:27 < orion> shiny is good, but how tould that virtual address relate to an internet address? I like the fact that orion@mail.i2p and orion@i2pmail.org are both usable. +13:27 < orion> s/usable/identical/ +13:28 <+postman> polecat: who wants to transfer 100MBs of mailbox data every day in 1 year for all 10000 users? +13:28 <+postman> orion: they will be usable +13:28 <+polecat> instead of going mail.i2p -> polecat.i2p -> frosk@baffled.i2p, it could go to either of the 3, and from there straight to baffled. +13:29 <+postman> i ask all ppl interested to contribute some ideas +13:29 <+postman> still the virtual domains is a feature that appears useful and can be implemented regardless of the state of the network +13:29 <+polecat> So if mail.i2p ever dies, the other two will have their server tunnels available as alternatives into the mail relay system. +13:30 <+postman> polecat: still there is the question of your mailbox +13:30 <+postman> polecat: your mailbox data must be moved as well and kept synchronized between ALL possible location +13:30 <+polecat> Ugh... yeah that's true... +13:30 <+postman> polecat: just consider this for 1000 users in the future +13:30 < susi23> everybody could set up a destination on their nodes where mails are delivered to... now we have to problem to connect destinations to mail addresses +13:30 <+postman> it's not THAT easy +13:30 <+polecat> Oh! But this would work though... +13:30 <+postman> indeed +13:31 <+postman> otoh the problem of relaying from and to the internet is still there +13:31 < dm> jrandom: you're enjoying this, aren't you? +13:31 <+polecat> Yes! A user chooses which server to have their POP3 mailbox on, and that is the server they choose as destination for the POP3 tunnel. +13:31 <+postman> polecat: what if THIS server fails? +13:32 <+polecat> So mail.i2p and polecat.i2p never even have to see baffled's POP3 mailbox, since all of baffled's POP3 users download straight from baffled. +13:32 <+postman> a real redundant system will require a mailbox sync +13:32 < susi23> yeah, but with such a system everybody could deliver mails within i2p, even if postman.i2p would not be there +13:32 <+polecat> postman: Then they have to change servers. -.- +13:32 < dm> Students having an intelligent conversation between each other. A professor's dream :) +13:32 <+postman> well, the meeting is hardly the place to DISCUSS all those things +13:33 <+postman> i am just here to trigger the discussion +13:33 <+postman> read the document first please and AFTER THAT i am ready to hear your comments +13:33 <+postman> 2. +13:33 <+polecat> Alright, so mail.i2p is in the works, and attempting to become less centralized and single point failurey. +13:33 <+postman> we officially crossed the 100 users with 110 registered accounts +13:33 <+postman> just FYI +13:33 < jrandom> w00t +13:34 <+postman> thats all for today :) +13:34 <+postman> thanks +13:34 * dm applauds +13:34 < jrandom> kickass, thanks postman. it all looks promising +13:34 <+postman> :) +13:35 < mule2> i'd like to bring up a topic on mail, but after the meeting +13:35 < jrandom> perhaps some mail-decentralization discussions could go on over the list or on the forum? but for now what you've got set up more than meets our needs +13:35 <+postman> there's even a channel for it +13:35 <+postman> :) +13:35 < jrandom> heh good point +13:35 < frosk> which one? +13:36 < jrandom> #mail.i2p +13:36 <+postman> frosk: #mail.i2p +13:36 <+polecat> Oh, one quick note I just surprised myself by getting a little perl caching SMTP server going, so emacs doesn't hang waiting for postman's SMTP server to respond over i2p. +13:36 < frosk> ok +13:36 <+polecat> I might post some code later, if it works like, really well. +13:36 < jrandom> oh, kickass polecat +13:36 < cervantes> postman: you're welcome to have a dedicated section on the forum +13:37 <+postman> cervantes: ohh thanks +13:37 * postman feels honoured :) +13:37 < dm> You deserve it +13:38 * postman hands the mike back to hr +13:38 * postman hands the mike back to jr +13:38 <+postman> damn +13:38 <+postman> :) +13:38 < jrandom> ok, if there's nothing else on 2) mail.i2p, lets jump on over to 3) roadmap +13:38 <+polecat> vroom vroom! +13:38 < jrandom> the old roadmap was looking a little... out of date +13:39 < jrandom> the new one reflects the current view of things +13:39 < jrandom> hopefully the schedule listed has enough padding, though if more people jump on board perhaps we can beat those estimates :) +13:40 < jrandom> once we've hit 0.6, we'll be able to scale to large numbers of nodes, as we wont have the thread-imposed ceiling +13:41 < frosk> what do you think is a realistic node limit for < 0.6? +13:41 < jrandom> prior to 0.6 though, we'll probably need to stay under 200 active nodes, though we can probably stop being so lazy and actively kill some connections +13:41 < jrandom> with some care, i think we'll be able to get up to 3-500 +13:42 < mule2> so no slashdotting please +13:42 < jrandom> we'd have connection churn at that point, but our low-cost tcp transport shouldn't hurt too much +13:42 < Pseudonym> the roadmap for 0.6 doesn't mention that. just udp and content dist +13:42 < Pseudonym> or is it the udp that fixes it? +13:42 * orion votes for no slashdotting ever +13:43 < jrandom> Pseudonym: udp fixes it (http://www.i2p.net/todo#transport ) +13:43 < cervantes> postman: http://forum.i2p/viewforum.php?f=22 +13:44 < Pseudonym> orion: I disagree. to get real anonymity we're going to need LOTS of nodes eventually +13:44 < Pseudonym> at some point we have to tell people about it +13:44 < jrandom> agreed. when we need 'em, we'll definitely want to do all sorts of PR +13:44 < jrandom> the geek crowd will likely be a large part of the userbase +13:44 < Pseudonym> when do we announce to the geek community? not as a finished product but as a beta for tire-kicking +13:44 < Frooze> Ask JRandom +13:45 <+polecat> I think we should be very careful about making this network too popular. +13:45 < jrandom> Pseudonym: when we've done the best tire kicking we can without them +13:45 <+polecat> Because one of these days someone is going to use it to do something horrible and illegal. +13:45 <+polecat> And if we can be tracked down at that point, we will be persecuted right along with the criminal. +13:46 < jrandom> basically, once the network works great consistently and we're not able to do tihngs to b0rk it up, /then/ we'll need to get more users to help break/test it +13:47 < mule2> you have to kick me off before :9 +13:47 < Pseudonym> just don't fall into the same trend as Toad with freenet +13:47 <+polecat> Because we gave them the freedom to post the source code for Windows XPQXR, and Halo 7, so we'd better as all heck have good anonymity protection. +13:47 < orion> speaking of b0rking... was that time-skew bug ever identified? +13:47 < jrandom> Pseudonym: i believe our roadmap is realistic +13:48 < jrandom> polecat: agreed, people shouldn't use i2p for things that are 'dangerous' yet +13:48 < jrandom> orion: no +13:48 < Pseudonym> jr: I'm not complaining about the roadmap. but it doesn't address announcements +13:48 < jrandom> true +13:49 < dm> well, with 2 years of development/testing under its belt, it should be one of the most polished offerings of this type when it launches :) +13:49 < Pseudonym> perhaps add slashdotting to 0.6? :-) +13:49 <+polecat> jrandom: More importantly, people who would use i2p for things that dangerous would do us a lot of good if they didn't know about i2p just yet. +13:49 < jrandom> i was thinking about that the other day. perhaps some announcements for other activities (e.g. I2PContent) would make sense, to draw more people in to work on them +13:49 < dm> as opposed the usual level of maturity when things go big +13:50 < ant> <jnymo> i think jrandom should write the slashdot article.. he's best at describing i2p, i think +13:50 * Pseudonym agrees +13:51 < dm> I'm sure something will go on there before jrandom is comfortable to do it himself ;) +13:51 < Pseudonym> I'm just trying to nudge him a bit +13:51 < jrandom> heh +13:51 < jrandom> well, with 0.6 we'll want to attract a larger user base in any case +13:51 < Pseudonym> I figure if I can't code, I can at least pester the people who can +13:51 * jrandom flings mud +13:52 <+polecat> dm: I'm sure the Second Coming will pass before jrandom is comfortable enough to /. i2p ;3 +13:52 * Pseudonym ducks. quack +13:52 < jrandom> ok, in any case, anyone have anything else to discuss wrt the roadmap? +13:52 < jrandom> or shall we move on to 4) I2PContent ? +13:53 -!- Irssi: #i2p: Total of 36 nicks [1 ops, 0 halfops, 3 voices, 32 normal] +13:53 < jrandom> frosk: ping +13:53 * frosk grabs the wireless mic +13:54 < cervantes> *zzzzzZzzzzttt* +13:54 * orion plugs in his RF jammer. ;) +13:54 <+polecat> I have been trying to get ahold of frosk, without luck as such yet. Frankly I think I might never see em on IRC, and eir email is a sightless void. +13:54 < frosk> well, jrandom put this "distributed content infrastructure" on the new roadmap for 0.6, and after hearing some thoughts about it here, it sounded really interesting, and i figure i should do whatever my skills allow to beat the schedule ;) +13:54 * dm looks at polecat +13:54 <+polecat> *shakes head* Just no luck whatsoever. No where to be FOUND. Maybe frosk is invisible! +13:55 < frosk> "i2pcontent" is so far a document at frosk.i2p +13:55 < Pseudonym> how is I2PContent different from i2p-bt? +13:55 * polecat is on 4.4 atm. +13:55 < frosk> it merges the ideas i've heard with my own, and it has gone through some revisions with helpful comments and suggestsions from jrandom and others, and i think it's starting to look very cool :) +13:55 < ant> * jnymo tries to find a postscript viewer to see these ideas.. :/ +13:56 < dm> what is it, I can't get to frosk.i2p. Executive summary? +13:56 <+polecat> Pseudonym: i2p-bt only applies to 1 file at a time, and is a swarming download. +13:56 < frosk> Pseudonym: i2pcontent is a lot like Usenet +13:56 < frosk> it merges concepts from usenet and freenet. i shall refrain from calling it "frusenet". +13:56 < jrandom> lol +13:56 <+polecat> Did you get my suggestion on i2pcontent? +13:56 < jrandom> frusenet has a ring to it... +13:56 < frosk> i2pcontent lets you post messages to your blog or to public forums, and publish your address book for others to import +13:56 * dm did not refrain from calling it frazaa +13:56 <+polecat> It merges usenet, freenet and livejournal. So.... Fusejournal? +13:56 < jrandom> rofl +13:57 < frosk> hm, yeah, LJ too ;) +13:57 <+polecat> Lj is the closest parallel I've found. +13:57 <+polecat> But here's one thing I didn't read in your i2pcontent document. +13:57 < frosk> anyway, at this point i really want it well designed, so i urge anyone who's interested to read the document and make suggestions +13:57 < orion> LiveFuseNet. +13:58 <+polecat> What about making it so only a few people can /read/ a group? Not so much encrypting it, but preventing its existence from even being known. +13:58 < dm> How about: Contnet? ContNet +13:58 < dm> Content, Contnet... get it? eh??? +13:58 < susi23> jnymo: regarding postscript, I kindly asked frosk to supply us with pdf *blush* +13:58 < frosk> polecat: that may be interesting, yeah. it's hard to fit into the current design, though +13:58 < jrandom> i'm not sure, it sounds pretty doable +13:59 <+polecat> I want HTML or plain text myself. -.- Don't like bitmap ps readers. -.- +13:59 < jrandom> rather than offering a group for syndication, only trusted/known users can get the group +13:59 < jrandom> (off trusted/known syndication nodes) +13:59 < frosk> polecat: http://frosk.i2p/i2pcontent-3.pdf if you can handle pdf's :) +13:59 < jrandom> kind of like usenet's "Distribution:" header +13:59 < susi23> polecat: ps is not bitmap :P +13:59 <+polecat> frosk: It's important though, if you want to have things like private mailboxes, or secret groups, or livejournal's ability to block text to all but certain friends. Also moderated forums will probably be important to have that. +13:59 < frosk> hm, yeah +14:00 < frosk> polecat: blocking to all but friends can be handled with encryption +14:00 <+polecat> frosk: My PDF reader is this: $ pdf2ps file.pdf > file.ps; gs file.ps +14:00 < jrandom> polecat: you had a good suggestion for moderated forums the other day - an unmoderated submission queue, with moderators posting to the "real" group +14:01 <+polecat> frosk: Encryption is good, and hopefully somewhat transparent. Otherwise users will have to type text in an xterm running gpg, copy it and paste it to the journal window. >.< +14:01 <+polecat> jrandom: Yes, but ideally the submission queue should be invisible to all but the moderators. +14:01 < frosk> polecat: oh, transparency is an important keyword in the whole thing :) +14:01 < jrandom> polecat: you'd lose 99% of the target audience if you say "xterm" +14:02 <+polecat> jrandom: Heathens! A grep on them! +14:02 < ant> <jnymo> mmmmm.. what's usenet? +14:02 < ant> <jnymo> I mean i've heard of it.. but +14:02 < susi23> jnymo: news, nntp, google -> groups +14:02 < frosk> http://en.wikipedia.org/Usenet :) +14:03 <+polecat> jnymo: newsgroups, eh? +14:03 < dm> It's good for random porn downloads. +14:03 < frosk> it's basically the world's oldest and most proven p2p net, as jrandom wrote today +14:03 < ant> <jnymo> so you can post files up? or links to files? +14:03 < jrandom> and its bloody resiliant +14:03 < susi23> dm: its 'use'ful for random porn downloads :P +14:03 <+polecat> dm: I suppose, if you can find the porn around all the spam. +14:04 < frosk> it's first and foremost for discussion groups, but it's widely used for files too +14:04 <+polecat> There's another issue actually. Spam and all.. +14:04 * dm used to run a 'porn downloader'. It worked well. +14:04 < ant> <jnymo> so its like the forum format of irc? +14:04 < frosk> i have thought about spam on i2pcontent, and i don't look forward to it ;) +14:04 * susi23 points back to topic *blush* +14:04 <+polecat> We can't have open forums, or at least we can't only have forums with 1 author, and forums without restriction. We need some kind of happy medium where multiple people can post, but not unauthorized people. +14:04 <+dinoman> i have just 1 thing to ask would i have to run this ie is it going to be part of i2p? +14:05 < frosk> polecat: i2pcontent has that (groups of users editing one blog) +14:05 < dm> It's amazing usenet is so big considering how few people actually use it. +14:05 < dm> Average Joe doesn't know what usenet is. +14:05 < jrandom> dinoman: its an application, definitely not required +14:06 <+dinoman> :) +14:06 < ant> <jnymo> yea.. i'm average joe +14:06 < frosk> but hopefully distributed with i2p ;) +14:06 <+polecat> So pretty much you have a list of sha4 in meta.group.*, one list for approved syndicators/readers, one for writers, one for owners, etc... +14:06 < jrandom> (but i can see no reason why not use it, as 1) installing it doesn't add *any* overhead to your machine 2) lots of good features :) +14:07 < jrandom> frosk: definitely +14:07 < dm> Google seems to be giving it some exposure. It should be presented as "the biggest message board in the world", and have a similar UI to the usual forums. +14:07 <+polecat> jrandom: Why would you say *no* overhead? c.c +14:07 <+polecat> Just because you have to select syndicates and blogs to read, before you will download them? +14:07 < jrandom> jnymo: a usenet-like itnerface to the i2p mailing list: http://news.gmane.org/gmane.network.i2p +14:08 < jrandom> polecat: no, 0 overhead if you don't use it +14:08 < frosk> polecat: groups have one owner who can add users. as for "secret" message namespaces, i haven't thought about that till now :) +14:08 < jrandom> (as in, just having it installed doesnt make your machine a public data store, etc) +14:08 -!- ]Replica[ is now known as ]Replica|zZz[ +14:08 < jrandom> and there will probably be i2p announcements done over secure blogs in i2p, worth reading, etc +14:08 <+polecat> frosk: No reason it can't have multiple owners, though only one could go in the sha for the name. :3 Just allow multiple people to modify the meta.* stuff for that group. +14:09 < frosk> so in closing, if you're interested in helping out, read the document at frosk.i2p and let's talk :) anything else on i2pcontent? +14:09 <+dinoman> oh so it is not freenet over i2p! +14:09 < frosk> (i have quite a lag here right now) +14:09 < jrandom> right dinoman, definitely not +14:09 < susi23> data organized in "newsgroups" would be great...simply delete/unsubscribe i2p.childporn.* ... +14:09 <+polecat> dinoman: En. Oh. +14:10 < ant> <jnymo> jrandom: ah.. that's cool +14:10 < jrandom> word frosk. this is definitely some cool shit, and people should throw tons of email at you, and read your blog :) +14:10 < ant> <jnymo> useful ;) +14:10 <+polecat> susi23: Right, and if nobody wants to syndicate it, then nobody has to help move it around. +14:10 < frosk> polecat: yeah, though it adds a bit of complexity, and i'm a simplicity freak ;) +14:10 < jrandom> jnymo: aye. but we can do some really cool shit beyond that, making things look like http://www.livejournal.com/ or blogger or whatever +14:11 < jrandom> yeah, its best not to aim too high at the start (</lesson learned>). go for the simplest thing that could possible work, with hooks for later improvement +14:11 < frosk> the rendering is of course 100% up to the user client (web interface that looks like LJ? ok. slashdot-like? fine! etc :) +14:12 <+polecat> frosk: I just think permissions should be generalized, and not "only one" for owner, "just a few" for writer, "everybody and their mother" for reader, unless the forum itself specifies those permissions. Otherwise you're hardcoding many types of authorization. +14:12 < frosk> jrandom: yes, extensionability is king +14:12 < frosk> which is why a sound design from the start is important +14:13 <+dinoman> so let me see if i get this to me (end user) this is going to work like newsgroups. +14:13 < frosk> polecat: agree +14:13 <+polecat> dinoman: More like Livejournal, but yes. +14:14 <+dinoman> well i could learn to like this idea! +14:14 < frosk> technically it's like newsgroups (on speed), but on the surface it can be like livejournal +14:14 <+polecat> frosk: Also not like LIvejournal, in that it's decentralized Usenet style. So the user has to pick syndicates, instead of the one syndicate LJ. +14:15 < frosk> polecat: yes. the user software does the syndicate picking in most cases though, so most users won't have to know about many technicalities +14:16 <+polecat> Hmm... perhaps. You'd have to have a way for the software to find the syndicates though. Aside from the user copying the hash from IRC into the i2pcontent add syndicate box. +14:17 < jrandom> polecat: syndicate(s) used are included in the meta.* post +14:17 < frosk> polecat: yes, i2pcontent comes with a few "seed syndicates", and the user asks them for more +14:17 < ant> <Asciiwhite> frost, livejournal?, sounds brillient... +14:17 <+polecat> jrandom: You need a syndicate to get a meta.* post. 8) frosk: yeah something like that, cool. +14:17 < frosk> ah yes, frost people will love i2pcontent ;) +14:18 < jrandom> heh true +14:18 < frosk> jrandom: that wasn't my plan, but it sounds very smart, actually :) +14:18 < frosk> the current syndicate database is a sore point in some ways +14:18 < jrandom> i thought i saw it in one of your .ps files, perhaps it was just in a conversation though +14:19 <+polecat> Make it a kademelia DHT! X3 +14:19 * jrandom groans +14:19 < jrandom> but yeah, there are lots of optimizations on the syndicate database that can be done +14:19 < frosk> perhaps you're just thinking smart thoughts and exchange what you read with that ;) +14:19 < jrandom> lol +14:19 < ant> <jnymo> so can you embed html? +14:19 <+polecat> *chants* DHT DHT DHT USA US-- +14:19 < jrandom> jnym: any content +14:20 <+polecat> jnymo: Either that or some sort of bbcode type thing. +14:20 < jrandom> yeah, rendering would be safest with a bbcode-like syntax +14:20 < dm> frosk: would you like a dedicated section on cervantes' forum? +14:20 < frosk> blogs and forums will expect text with some markup like bbcode +14:20 < frosk> dm: i think it's kind of early yet :) +14:21 < dm> frosk: consider it done! +14:21 < cervantes> dm: would you like a private sound proof section on my forum? +14:21 < dm> cervantes: make it so. +14:21 < frosk> while i'm still on, please not that "i2pcontent" is just a dummy name since i didn't want to insult jrandom by calling it MyI2P ;) we need a more catchy name +14:21 < dm> how about... contnet? +14:22 < jrandom> frusejournalrent +14:22 < frosk> i like! +14:22 * dm rubs his hands in excitement +14:22 < jrandom> </fark> +14:22 < dm> </stupid jrandom tag> +14:22 <+polecat> usejournalforrent? +14:22 < ant> <jnymo> fusenet sounded pretty cool +14:22 <+protokol> eepnet +14:22 <+postman> uupnet :) +14:22 < lurk> froops +14:23 <+postman> LOL +14:23 < dm> nnnnnnnnnnnntp +14:23 <+postman> silly persons +14:23 <+polecat> "frosk's catchy name for a content distribution syndicate network." We could say "Fcnfacdsn was inspired by Usenet..." +14:23 < ant> <Asciiwhite> yeah i thought frusenet was good. +14:23 < frosk> :D +14:23 < jrandom> ok, please direct all silly names to frosk@mail.i2p :) +14:23 <+polecat> frootloops! +14:23 < frosk> i tried frusenet on a friend, he said "... or not." +14:23 < jrandom> (along with any comments/concerns/etc) +14:24 < frosk> although fusenet has a cool ring to it :) +14:24 < dm> How about just 'Content' ? +14:24 <+polecat> I like fusenet, it sounds... volatile. +14:24 <+polecat> So yes. Quieting down now. +14:24 < Pseudonym> nn2p +14:24 < dm> Nice and dinstinguished +14:24 < jrandom> ooOOo +14:24 < frosk> anyway, i'm not last on the agenda, we might want to move on ;) +14:24 <+postman> NN2P is COOL +14:24 < ant> <jnymo> if you had html.. you could have what looks like the net... inside froozlednet +14:24 < jrandom> ok, moving on to 5) i2p-bt +14:24 < jrandom> duck: you 'round? +14:24 <@duck> meep +14:24 < frosk> dm: "Content" is probably trademarked by Apple or whatever ;) +14:25 < ant> <Asciiwhite> owww, is this a minutes ? +14:25 <@duck> i2p-bt events this week: +14:25 < dm> speeddating!@ +14:26 <@duck> - rss available on the trackers +14:26 <@duck> - silly attempts to make a metatracker in #eeprnova +14:26 < ant> <jnymo> noice +14:26 < ant> <Asciiwhite> yeah, great idea. +14:26 <+polecat> I still wish we could find a better codebase than that blasted bittorrent python source... +14:26 < ant> <Asciiwhite> What about support for say samplers(i.e video/pics) +14:26 <@duck> - some detailed code review leading to not finding bugs +14:26 <@duck> most of the scary looking errors are pretty harmless +14:27 <@duck> - I forgot +14:27 <@duck> . +14:27 < jrandom> word +14:27 < jrandom> i've been watching the streaming lib activity while swarming, and there have been some improvements in cvs +14:28 <+polecat> A metatracker lets you find trackers for files...? +14:28 < ant> <Asciiwhite> so people can upload a small sample of video quality, or a thumbnail etc. +14:28 < jrandom> (to keep up with the bt setup) +14:28 <+polecat> jrandom: Improvements as of what date, this morning? :3 +14:28 <@duck> polecat: yeah, well this one just announces new files into a channel; but it could be enhanced +14:28 < jrandom> a day or two ago +14:29 <+polecat> Just checking, because last time I got CVS Head, you updated to 0.4.3 a few hours later. +14:29 < ant> <jnymo> yea.. is there some idea for i2ptorrent search some where down the eschelons? +14:29 < jrandom> one of the neat things though is that i believe the main remaining i2p-bt bumps we're seeing are actually just i2p/streaming lib/sam problems +14:30 <+polecat> Someone'd have to write a searching server, maybe by keyword and such. +14:30 <@duck> or an irc bot +14:30 < jrandom> jnymo: http://brittneyworld.i2p/bittorrent/ +14:30 < jrandom> polecat: files.i2p/ +14:30 < ant> <jnymo> hmm +14:30 < ant> <jnymo> mmhmm.. yea. mk +14:30 <+polecat> duck: Well a server to search, whether a bot or a eepsite like files.i2p... +14:31 <@duck> if someone needs rss etc enhancements on the tracker for their bots etc, let me know +14:31 < ant> <jnymo> hmm.. seems brittanyworld.i2p is down at the moment +14:32 < jrandom> since it seems the remaining problems are i2p related, not i2p-bt related, we've marked the swarming file transfer bounty as completed +14:32 < jrandom> (yay!) +14:32 < ant> <jnymo> anyhoo +14:32 < ant> * jnymo tips his hat +14:32 < frosk> congrats to all involved, you rock +14:33 < jrandom> aye, thanks to all the hard work of duck, ragnarok, dinoman, connelly, and drwoo +14:33 <+polecat> ragnaroks! dinoman's da man! Um... +14:33 < ant> <Asciiwhite> nice work duck. +14:33 <+polecat> I still want to get ctorrent ported to i2p. It's a wicked efficient bittorrent thingy, if a little flaky on the UI. +14:34 < dm> good work +14:35 <+polecat> Anyone know where the info about SAM proxies is? +14:36 < jrandom> about half of our general fund went towards that bounty, so our current balance is around $400USD [after some new donations today [yay!]] +14:36 < jrandom> polecat: http://www.i2p.net/sam +14:37 <+polecat> jrandom: Doing a swarming file transfer cost like, money? o.O +14:37 <+polecat> Ohh right the reward. +14:37 < Pseudonym> it'd be kinda cool to have the general fund balance on the website +14:37 < jrandom> right polecat :) +14:37 < jrandom> thats a good idea Pseudonym +14:38 < Pseudonym> doesn't have to be updated daily, just occasionally +14:38 < jrandom> i'll add it on to /bounties (sound good?) +14:38 < Pseudonym> sure +14:38 <+protokol> dont tell me they are keeping the hello chat room +14:38 < cervantes> if he did that we'd all see how much it goes down whenever jrandom goes out for a pie and a pint lunch +14:39 < jrandom> heh cervantes +14:39 < Pseudonym> didn't somebody donate money for jrandom's beer? +14:40 < cervantes> enough for half a pint at todays rates :) +14:40 < jrandom> yeah we've had a few beer donations :) +14:40 < jrandom> (list of donations up @ http://www.i2p.net/halloffame ) +14:40 < Pseudonym> are you spending them? +14:41 < cervantes> nice...someone has money to burn I see ;-) +14:41 < ant> <Asciiwhite> anonymous +14:41 < ant> <Asciiwhite> $5.00 USD +14:41 < ant> <Asciiwhite> buy jrandom a beer fund +14:41 < ant> <Asciiwhite> lol +14:42 < jrandom> it would be nice if we can grow the bounties on the CDN, as thats a truckload of work +14:42 < jrandom> but we'll see how it goes over time +14:42 < jrandom> ok, i think we're pretty off track for 5) i2p-bt +14:42 < jrandom> so i suppose we should move to 6) ??? +14:42 <@duck> nothing to add here. +14:43 < jrandom> is there anything else people would like to bring up? +14:43 <@duck> - why do so many ppl have problems when they specify a hostname? +14:43 < jrandom> not sure +14:43 < jrandom> both of my routers use an explicit hostname +14:43 <@duck> mine too, np +14:44 <@duck> maybe the warning text should be more negative +14:44 < jdot_> do we have a way to change keys on hostnames in hosts.txt? +14:44 < jrandom> sounds good duck +14:44 <+polecat> Regarding addressbook... +14:44 < jrandom> jdot_: no, not really, especially in light of the addressbook +14:44 < jdot_> like, if I lost my previous eepsite key. :( +14:44 < mule2> same here - but i have problems :) +14:44 <+polecat> Addressbook is going to be fused with i2pcontent, right? +14:45 < mule2> but don't think these result from the hostname +14:45 < Pseudonym> do we have a working addressbook? +14:45 <+polecat> You subscribe to an addressbook just like you subscribe to a blog... except it overwrites userhosts.txt and such. +14:45 < jrandom> polecat: distributing addressbooks through i2pcontent makes sense, yeah +14:45 < jrandom> Pseudonym: http://ragnarok.i2p/ +14:45 <+polecat> Pseudonym: http://polecat.i2p/addressbook.pl.zip +14:45 < jrandom> and http://pole...er, what he said +14:45 < Pseudonym> thanks +14:46 < jrandom> i think there's also another one at http://orion.i2p too +14:46 < frosk> polecat: "overwrite" sounds dramatic. it "merges" ;) +14:47 <+polecat> Yeah... I saw orion's too. +14:47 < jdot_> dang +14:47 < jrandom> jdot_: so it looks like you're outa luck :/ +14:47 < jrandom> ok, anyone else have anything for the meeting? +14:48 < dm> merry xmas +14:48 <+polecat> jdot: Thankfully when we've got fusenet working, you can update your i2p key with that eventually. +14:49 < ant> <Asciiwhite> dm, 15th of december here :) +14:49 < jrandom> and a happy Chanukah +14:49 <+polecat> Christ was born in September, what's everyone all celebrating about? +14:49 <+polecat> I'll stick with Yule thanks muchly. +14:49 < jrandom> ok if thats it... +14:49 * jrandom winds up +14:50 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/120.rst b/i2p2www/meetings/logs/120.rst new file mode 100644 index 00000000..1e6b4c91 --- /dev/null +++ b/i2p2www/meetings/logs/120.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 14, 2004 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/121.log b/i2p2www/meetings/logs/121.log new file mode 100644 index 00000000..52e18f21 --- /dev/null +++ b/i2p2www/meetings/logs/121.log @@ -0,0 +1,323 @@ +13:05 <@jrandom> 0) hi +13:05 <@jrandom> 1) 0.4.2.4 & 0.4.2.5 +13:05 <@jrandom> 2) 0.5 strategy +13:05 <@jrandom> 3) naming +13:05 <@jrandom> 4) eepsite roundup +13:05 <@jrandom> 5) ??? +13:06 <@jrandom> 0) hi +13:06 * jrandom waves +13:06 <@jrandom> weekly status notes posted a lil while ago @ http://dev.i2p.net/pipermail/i2p/2004-December/000528.html +13:07 <@jrandom> lets jump on in to 1) 0.4.2.4 & 0.4.2.5 +13:08 <@jrandom> for those of you who have already upgraded to 0.4.2.5 - a good 1/3 of the network so far - thanks! +13:09 <@jrandom> i do try to keep a more calm pacing to the releases, but there were some things in 0.4.2.5 that really needed wider deployment +13:10 < Madman2003> 0.4.2.5 is working well for me when it comes to disconnects, but i don't run i2p 24/7(i had quite a few irc disconnects lately) and it's only been a few hours after the release +13:10 <@jrandom> as mentioned later on in the email, i dont have a planned date for when the next bugfix release will be, but we shall see +13:10 <@jrandom> ah great Madman2003 +13:10 <@jrandom> yeah, its definitely too early to tell about 0.4.2.5 +13:11 < frosk> i used to see periods of high lag on .4, so far none of those with .5, but again, a bit early +13:11 < frosk> (i'm talking about irc lag, of course) +13:11 <@jrandom> the dns bug fixed could manifest itself in large numbers of peers running older releases failing at once, so the sooner people upgrade, the better +13:12 <@duck> is that related with the failures on those manually entering a hostname? +13:12 <@jrandom> yep +13:12 < dm> how useless is the windows system tray I2P icon!?!? +13:12 <@duck> ah, so that is why config.jsp is still friendly +13:13 < Madman2003> anyone have a clue why some still run pre 0.4.2.4 routers?(it's been out a while) +13:13 <@jrandom> dm: its more of a placeholder right now, plus a status icon saying "i2p is running" +13:13 < dm> They have a life? :) +13:13 * jrandom should resent that... +13:14 < redzog> is there a way to do soft-restarts from the command line? +13:14 <@jrandom> redzog: unfortunately not +13:14 < redzog> hmm, pity +13:14 <@jrandom> other than with wget, perhaps +13:14 < redzog> would make it easier to do automatic updates +13:14 <+detonate> i2prouter stop && i2prouter start :) +13:14 <@jrandom> no, nm, wget wouldnt work either +13:14 <@jrandom> (as the form requires interaction) +13:14 < Madman2003> i generally update trough cvs several times in between releases(at best once a day), only takes a few minutes +13:15 < redzog> lwp::simple could manage it +13:15 < redzog> just a POST +13:15 <@jrandom> redzog: support for that would be pretty cool +13:15 < redzog> I'll try to whip something up +13:15 <@jrandom> well, its more than just a post, you need to read the form presented to you then post those fields back +13:16 <+detonate> eventually releases will be further spaced though.. right? +13:16 <@jrandom> (there's a hidden flag to prevent people from doing things like <img src="/configservice.jsp?action=restart"> +13:16 < redzog> heh, right +13:16 <@jrandom> right detonate, t'wasn't planned to be this rapid, once a week at most +13:16 < redzog> does the nonce value change? +13:17 <@jrandom> if it didn't, it wouldnt be a nonce ;) +13:17 < redzog> hmm, seems so +13:17 < redzog> well, between sessions, between pageloads... ;) +13:17 < redzog> pageloads it is +13:17 <@jrandom> right +13:17 <@jrandom> ok, anyone have anything else wrt 0.4.2.4/0.4.2.5? +13:18 <@jrandom> i'm sur there'll be more discussion later after we've burnt in the new release more +13:18 < dm> oh, is this a meeting? +13:18 <+detonate> starting up seems to be a lot less smooth +13:18 <+detonate> than 2.3 +13:18 <@jrandom> oh? in what way detonate - cpu, lag, memory, time? +13:19 <+detonate> the list of peers takes forever to populate +13:19 <+detonate> and i get a huge number of shitlisted peers +13:19 <+detonate> also the i2ptunnel stuff sometimes hangs, but generally seems to take at least 2x as long to actually start up +13:19 <+detonate> once it's started things smooth out +13:19 <+detonate> it's odd +13:19 <@jrandom> hmm, what does it list for the cause on /logs.jsp#connectionlogs ? +13:20 < ant> <BS314159> I just did a graceful restart into 0.4.2.5. It took 120s to have Local Destinations +13:20 < ant> <BS314159> seems good +13:20 <@jrandom> cool BS314159 - thats pretty much the bare minimum, as we don't start i2ptunnel until 2 minutes after startup :) +13:20 <+detonate> there's nothing out of the ordinary +13:20 <+detonate> a shutdown exception +13:21 <+detonate> but i think i caused that +13:21 < mule> i have pulled over 300M through fcp for a movie with the last release. never been that good before. top rates beyond 40k. great work. +13:21 <@jrandom> wow, nice mule! +13:21 < mule> however i still have serious trouble with recovering from an IP change +13:21 <@jrandom> detonate: hmm, ok, i'd love to debug this further after the meeting or another time you have available +13:22 <+detonate> yeah +13:22 <+detonate> ok +13:22 < dm> tunnel lag: 364ms. What the fuck is going on , the tunnel lag is dropping 100-200ms on each release! +13:22 <@jrandom> ah mule, ok +13:22 <@jrandom> i've got an idea for how we could deal with those hung tcp connections - just toss on a 5m keepalive +13:23 <@jrandom> heh dm, dont worry, it'll get back up again ;) +13:23 < frosk> wow, i only have 261ms here :) +13:24 <@jrandom> ok, if there's nothing else, lets jump on to 2) 0.5 strategy +13:24 < dm> That can't be right... +13:25 <+ugha2p> Looks like I'm late for the meeting again. +13:26 <@jrandom> there's still a lot of work to be done with 0.5, but a broad outline of the process was included in that email +13:26 * jrandom sends ugha2p to the principal's office +13:27 <@jrandom> there are still some details left to be worked out on the tunnel pooling and creation, but i think we've got a few different offerings that will meet the needs of various user bases +13:28 <@jrandom> there'll be some good ol' fashioned documentation posted once most of the kinks in the design are hammered out for y'all's review +13:28 <@jrandom> (currently its taking up ~8 pages in the notebook, should compress well though) +13:29 < kaji> has the meeting started yet? +13:29 <@jrandom> but another one of the tasks listed for 0.5 is "deal with the bandwidth needs of the network", and i have no idea how to plan for that, so we'll play that by ear +13:29 <@jrandom> yes kaji, we're on 2) 0.5 strategy +13:30 <@jrandom> well, thats all i have to say about that at the moment, unless anyone has any questions/comments/concerns? +13:31 <+ugha2p> Wow, most of the routers have already upgraded. +13:31 <+detonate> is filtering http traffic to strip out javascript/etc in the roadmap? +13:31 <+detonate> for 0.5 +13:31 <+ugha2p> detonate: No. +13:31 <@jrandom> detonate: 0.6 +13:31 < ant> <cat-a-puss> WRT bandwidth, should we enable probabilistic tunnel length, and/or local biased tunnels, for bittorrent as in general BT users have a weaker threat modle? +13:32 <@jrandom> cat-a-puss: yes, definitely. thats one of the big parts of the 0.5 release +13:32 <+ugha2p> detonate: Unless you implement it first. ;) +13:32 <+detonate> i was thinking about it +13:33 < ant> <cat-a-puss> will html filtering be conducted in a seperate process? +13:33 <@jrandom> i think michelle is looking at that too, so if you two wanted to work together (michelle is learning java) that'd rule +13:33 <+detonate> ok +13:33 <@jrandom> cat-a-puss: i know not. +13:34 <+ugha2p> cat-a-puss: Why should it? +13:35 < ant> <cat-a-puss> (I ask because I was thinking of making a proxy that ran all incomming brouser traffic through clamav) That is GPLed so if we could include that in the filter, it would probably be good. +13:35 <@jrandom> cool cat-a-puss! +13:35 <+ugha2p> Some people already use Privoxy for I2P. +13:36 < bens> in general, I'm anti-including-stuff +13:36 < susi23> I would rather see people configuring their browsers right than promising to protect them from malicious code. +13:36 <@jrandom> susi23: no one configures their browser properly +13:36 <@jrandom> especially not joe sixpack +13:37 < frosk> one can wonder if Joe is even able to set a proxy for his browser +13:37 <@jrandom> my personal view is that something cgi-proxy like would be ideal +13:37 <@jrandom> exactly frosk +13:37 <@jrandom> with a cgi-proxy like interface (filtering according to their preferences, safe by default), even a drooling moron could use it +13:38 < bens> I suppose I2P needs multiple versions for multiple markets even more than MS Office +13:38 <@jrandom> 'tis why we have small components and push this stuff out of the router bens ;) +13:38 < Ragnarok> a proxy auto config file would help +13:39 <@jrandom> Ragnarok: we have one, but there are still dangerous things that can be done with it +13:39 < frosk> maybe a specialized i2p browser even (if someone is drowning in free time ;) +13:39 < susi23> ragnarok: that one? http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/proxyscript/i2pProxy.pac +13:39 <@jrandom> frosk: on the specialized i2p OS and hardware too, i suppose +13:40 < frosk> hehe, perfect +13:40 < Ragnarok> that's not in the install, though +13:40 * jrandom implements those in the specialized i2p universe +13:40 < susi23> . o O ( perhaps we should try to find a dedicated i2p planet too ) +13:40 < susi23> . o O ( damn, too slow ) +13:40 < mule> ok, we'll sell the hardware :) +13:40 < frosk> you know what they say, to create something from scratch, first create the universe +13:41 <@jrandom> w00t, now all we need are some investors.. +13:41 < bens> seriously, a firefox autoconfigurator might be reasonable +13:41 <@jrandom> bens: the .pac susi linked to above should do the trick +13:41 < bens> not just for proxy; also for the security settings, homepage, etc. +13:41 <@jrandom> we can ship that with the install too, but its insufficient for people who need anonymity (and are not ubergeeks already) +13:42 <@jrandom> hmm, perhaps that sort of thing could go into cervantes' i2p xul app +13:43 <@jrandom> but thats getting further off topic from the 2) 0.5 strategy +13:43 <@jrandom> anyone else have anything for that, or shall we move on to 3) naming? +13:44 -!- Irssi: #i2p: Total of 40 nicks [2 ops, 0 halfops, 6 voices, 32 normal] +13:44 <@jrandom> consider us moved +13:44 <@jrandom> ok, aparently i kind of jumped the gun w/ the 2.0.1 ref of addressbook - Ragnarok, want to give us an update? +13:44 <+ugha2p> jrandom: Can we expect the dates on the roadmap to be correct? +13:45 <@jrandom> ugha2p: they currently reflect my best estimate +13:45 <+ugha2p> jrandom: Ok, right. +13:45 < Ragnarok> it's released now +13:45 <@jrandom> w00t +13:45 < Ragnarok> check ragnarok.i2p +13:45 < Ragnarok> I wasn't planning on releasing it yet, but jrandom forced my hand :) +13:46 <@jrandom> hehe +13:46 <+ugha2p> Ragnarok: Btw, you're missing a link from the homepage. :) +13:46 < Ragnarok> it's just a few bug fixes, nothing major, but it should deal better with some corner cases +13:46 <@jrandom> its on the top right ugha2p +13:47 < Ragnarok> ugha2p: it's on the sidebar +13:47 < Ragnarok> I'll add links to the post as well, though :) +13:47 < mule2> "that'll be the day when i die". daily IP change to set the clock after. +13:48 < Ragnarok> anyway, if everyone could try it out, that'd be nice. Bug reports are always appreciated +13:48 <+ugha2p> Ragnarok: Oh, that sidebar is seriously fucked in Opera. +13:48 < mule2> Lease expired 12773d ago +13:49 <+ugha2p> Ragnarok: Well, not really fucked, but just located at the end of the page. +13:49 <@jrandom> cool Ragnarok, thanks +13:49 < Ragnarok> your window's probably not wide enough +13:49 <+ugha2p> Ragnarok: Right, but it should work with any window size. +13:50 <+ugha2p> So you might want to fix it in the future. :) +13:50 < Ragnarok> ugha2p: should is an interesting choice of words :) +13:50 < Frooze> ah, wrong in mozilla 1.7 too. my window is small though. +13:50 <+ugha2p> Why's that? +13:50 < Frooze> thanks ragnarok. cool stuff. +13:51 < Ragnarok> I may fix it in the future, but it's really low on my priorities +13:51 * jrandom prefers addressbook updates to html fixes +13:52 < Ragnarok> anyhoo, any questions? +13:53 < frosk> thanks for addressbook, Ragnarok, sounds very useful +13:54 <+ugha2p> Is the documented way of loading addressbook the only way, or are there any less intrusive ones? +13:54 < kaji> i just installed it, it rocks +13:54 < Ragnarok> you can start it by hand using "java -jar addresbook.jar <path to i2p/addressbook>" +13:54 < Ragnarok> thank you :) +13:55 < kaji> oh, and i dled version 2.0.0 is there an update someware? +13:55 < Ragnarok> ok, I fixed the column, it was just a stupid mix of absolute and realitive sizes +13:56 < Ragnarok> yep, there's 2.0.1 up now on ragnarok.i2p +13:57 <+ugha2p> I'm getting "Failed to load Main-Class manifest attribute from" now, but never mind, I'll do a restart later. +13:57 < Ragnarok> whoops +13:58 < Ragnarok> that's my bad +13:58 < Ragnarok> I'll try to fix that soon +13:58 <+ugha2p> Ah, okay. :) +13:58 < Ragnarok> there will also be an easy to install .war version soon +13:59 < dm> jrandom: you are a machine +14:00 <@jrandom> wikked, thanks Ragnarok +14:00 <@jrandom> susi23: ping? +14:00 < susi23> 1200ms +14:01 <@jrandom> !thwap +14:01 <@jrandom> anyway, wanna give us a rundown on whats up w/ susidns? +14:01 <@jrandom> or should that wait for later? +14:01 < susi23> do we have time for a more general discussion about naming stuff? +14:02 < susi23> what features we want in the future? +14:03 <@jrandom> some of my thoughts are posted up on http://dev.i2p.net/pipermail/i2p/2004-February/000135.html +14:03 <@jrandom> (for what general features) +14:04 <@jrandom> i think the hardest thing will be weaning people off globally unique human readable names, but with some good interfaces it should be doable +14:04 < Ragnarok> implementing the data structures you outlined in xml is one of my next goals +14:04 < susi23> ok, there is a small writing about attributes at http://susi.i2p/removablekeys.html +14:05 < ant> <Jnymo> wow.. pretty crowded in here tonight +14:05 < bens> ragnarok: have you checked out YAML? Might be easier +14:05 <+ugha2p> Jnymo: Yeah, we're trying to hold a meeting here. +14:05 < Ragnarok> YAML's name is far too apt +14:05 <@jrandom> cool susi23, though i think we'll definitely want to migrate away from the plain hosts.txt format +14:05 < ant> <Quadn-werk> addition of a command line graceful restart? +14:06 < ant> <Jnymo> ugha2p: ah +14:06 < susi23> are there any ideas how to keep names unique in the long run? +14:06 <@jrandom> one of the important parts of the data to be managed in the naming service is for an entry to be signed, requiring some hard structure (or careful xml) +14:07 <@jrandom> i dont believe in globally unique human, human readable, and secure names. +14:07 <@jrandom> (i bundle centralized & secure together) +14:07 <@jrandom> susi23: have you seen http://zooko.com/distnames.html ? +14:07 < Ragnarok> I think using an addressbook like system, the names will end up being mostly unique, since it's in the interest of the person claiming a name not to choose one that's already in use +14:08 <@jrandom> Ragnarok: we'll see. perhaps +14:08 < susi23> i'll check this out +14:08 < bens> I suspect trusted authorities will emerge +14:08 < Ragnarok> well, there already is one +14:08 < frosk> hosts.txt? :) +14:09 < Ragnarok> jrandom's, yeah +14:09 <@jrandom> or if not trusted authorities, names that include the path to uniquely identify it +14:09 <@jrandom> (e.g. "the site orion.i2p calls 'frosk.i2p'") +14:10 <@jrandom> Derek Eddington had some posts along those lines in september - http://dev.i2p.net/pipermail/i2p/2004-September/000432.html +14:10 < bens> frosk.orion.i2p +14:10 <@jrandom> smtp.frosk.ns.orion.i2p +14:11 * jrandom starts building uucp bang paths +14:11 < frosk> hah +14:12 < susi23> ok, what now... how about a "naming roadmap"? :) +14:12 < ant> <Jnymo> you guys have swayed me away from an absolute distributed dns for i2p.. somewhat.. but ducks ideas started me thinking that a trust system might work.. like, a lookup could bring back a list of sites/files, and each could be listed with the amount of trust that the network gives it +14:12 < susi23> once we agreed what to do +14:12 <@jrandom> thats a good idea susi23, wanna write one up? +14:13 <@jrandom> trusting other people's trust has potential, but needs to be done very carefully +14:13 < susi23> I could do this, but I still have no idea WHAT we want to do. There are some decisions to make. +14:14 <@jrandom> (aka only according to the terms that you trust the peers along the chain to the trust author) +14:14 < modulus> there is or there should not be a "network trust" of a site, trust has to be user-centric always +14:14 <@jrandom> susi23: roadmap step 1: decide among $featureset +14:14 < susi23> Or at least we have to develop all ideas into a more precise concept. +14:14 < ant> <Jnymo> well, if it was explicitly simple.. like, if files i2p listed how many sites linked to siteinquestion.i2p +14:15 < Ragnarok> ok, the I've updated the addressbook package with an executable jar. +14:15 < ant> <Jnymo> er, files.i2p +14:15 <@jrandom> jnymo: that turns into a centralized authority - files.i2p +14:15 < modulus> not to say that you could poison the pool of links by establishing a shitload of sites. +14:16 < modulus> googlebombing on i2p +14:16 < ant> <Jnymo> true.. but files i2p could be decentralized +14:16 < susi23> ok, how about collection ideas/information/concepts until, lets say january +14:16 < orion> 'lo all. I see naming is on the table.. *again* :) +14:16 < susi23> then comes the decision phase, ok? +14:16 <@jrandom> sounds good - will you be the point of contact to gather that together? +14:16 < Ragnarok> sure +14:16 < modulus> doesn't matter if the trust aggregate is descentralized, trust has to emanate from the user. anything else can be poisoned imo. +14:17 < susi23> can't we take the mailinglist for this? +14:17 < bob> or perhaps ugha's wiki? +14:17 < ant> <Jnymo> agreed.. but what how to do that? put a little trust meter bar at the top of the web browser? +14:18 <@jrandom> the wiki would be good, we can gather links to all the previous discussions there +14:18 < modulus> jnyo: probably the most feasible solution is to bind to the first name encountered or something. +14:18 < dm> let's all give a hand of applause to jrandom for his wonderful project management +14:18 < susi23> fine +14:18 < modulus> but there are more ways than sausages. +14:19 < susi23> url to the wiki? (for the records) +14:19 < ant> * Jnymo claps +14:19 <@jrandom> ugha.i2p +14:19 * dm claps +14:19 < susi23> ok +14:19 < susi23> then I'm done and ping jrandom back ;) +14:20 < ant> <Jnymo> modulus: so, if i refer a link to someone else, i'm refering them to the site i first binded to.. that might work.. +14:20 <+ugha2p> Looks like jrandom has ping timeouted. +14:20 <@jrandom> ok cool, anything else on nami^W nm, no more on naming. on to the wiki +14:20 < modulus> anyway, if you're linking you'll probably want to put an absolute path in the link, not just a name +14:21 <@jrandom> moving forward to 4) eepsite roundup +14:21 < dm> dm.i2p is up and running +14:21 <@jrandom> cool +14:22 <@jrandom> ok, i dont really have much to add beyond whats mentioned in the mail +14:22 < bob> nice to see an influx of sites! all speedy to access as well! +14:22 <@jrandom> aye, agreed bob +14:22 < bob> orion, thanks for your work.. I use your site daily. +14:22 * jrandom too, the 'last updated' is especially helpful +14:23 < bob> dm: :-) +14:24 <@jrandom> ok, if there's nothing more on that, we can jump to 5) ??? +14:24 <@jrandom> is there anything else people want to bring up for the meeting? +14:24 < ant> <Jnymo> hows the net status? +14:24 < ant> <Jnymo> wrt 4.2.5? +14:25 <@jrandom> its looking good, but the release is only a few hours old, so too soon to tell +14:25 < ant> <Jnymo> oh, heh +14:25 < ant> <Jnymo> any fusenet news? +14:26 <@jrandom> (http://piespy.i2p/i2p/i2p-current.png heh) +14:26 < frosk> my work on i2pcontent has been largely put aside for some weeks, but the latest version of the document can be read at http://frosk.i2p/i2pcontent.html . if anyone is interested, do read, and do comment harshly if needs be (om irc when i'm not /away or mail to frosk@mail.i2p) +14:26 < frosk> i2pcontent/fusenet/anything ;) +14:26 < ant> <Jnymo> wordicus +14:28 <@jrandom> ok, if there's nothing else... +14:28 < mule2> tons of applause for all the excellent contributions +14:29 <@jrandom> aye, y'all are doing some kickass shit +14:29 < frosk> you too, jrandom :) +14:29 < orion> word. +14:29 < orion> yes, very much so, you too jrandom. +14:29 < scintilla> hear hear! +14:29 < ant> <Jnymo> yea, i noticed on the site, theres less info on how to help out +14:29 <@jrandom> sometimes kickass, sometimes ass kicked ;) +14:29 < orion> HIP HIP +14:30 < ant> <Jnymo> HORRAY +14:30 * orion smiles +14:30 < Frooze> downloaded eclipse today, to learn java over holiday, because y'all are so impressive. +14:30 <@jrandom> jnymo: many of the small easy-to-accomplish tasks have been done +14:30 <@jrandom> ooh wikked Frooze +14:31 < Frooze> so, trouble on horizon. heh +14:31 <@jrandom> jnymo: i really should collect some more of them though and post 'em +14:31 < ant> <Jnymo> jrandom: You still looking for someone to help out on alexandria.i2p? +14:31 <@jrandom> (take cover arizona!) +14:31 * jrandom is not involved in alexandria, but yes, i believe they are still looking for a librarian +14:31 < ant> <Jnymo> learn to swim, folks ;) +14:31 * orion loves pump up the volume references. Vague though they may be. +14:31 <@duck> yes we do +14:31 <@jrandom> :) +14:31 < Ragnarok> jrandom: where is the war actually supposed to go? +14:31 <@jrandom> (orion++) +14:32 <@jrandom> Ragnarok: i2p/webapps/addressbook.war +14:32 <@jrandom> (then restart the router) +14:32 < ant> <Jnymo> duck, you talkint to me? +14:32 < Ragnarok> cool. I shall commence testing +14:32 <@jrandom> r0x0r +14:32 < ant> <Jnymo> duck: is alexandria on your site? +14:33 <@duck> duck.i2p/alexandria/ +14:33 < ant> <Jnymo> word +14:34 <@jrandom> ok, if thats all, we can slide out of here @ the 90m mark.. +14:34 * jrandom winds up +14:34 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/121.rst b/i2p2www/meetings/logs/121.rst new file mode 100644 index 00000000..46b09da0 --- /dev/null +++ b/i2p2www/meetings/logs/121.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 21, 2004 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/122.log b/i2p2www/meetings/logs/122.log new file mode 100644 index 00000000..02a3e125 --- /dev/null +++ b/i2p2www/meetings/logs/122.log @@ -0,0 +1,195 @@ +13:06 <@jrandom> 0) hi +13:06 <@jrandom> 1) 0.4.2.5 +13:06 <@jrandom> 2) 0.5 +13:06 <@jrandom> 3) ??? +13:06 <@jrandom> 0) hi +13:06 * jrandom waves +13:06 <+postman> *wave* +13:06 < ant> <jnymo> hello +13:06 <@jrandom> brief status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html +13:07 <@jrandom> jumping in to 1) 0.4.2.5 +13:07 <@jrandom> as mentioned, things are pretty much working +13:08 <+postman> yeah, quite impressive +13:08 <+postman> no more lease timouts on my systems at all +13:08 <@jrandom> a lot of people have seen what you've seen jnymo, with 0 participating tunnels, largely in part to the increased efficiency & peer selection (where we now know to leech off postman's machine ;) +13:08 < ant> <jnymo> me too +13:08 <@jrandom> nice +13:08 < ant> <jnymo> and eepsites are snappy +13:09 <+postman> :) +13:09 < ant> <jnymo> thanks postman :) +13:09 <+postman> totsl bw is 29kb / 30.1kb/s +13:09 < frosk> everybody feels less loved, but in reality the love is just being put more efficiently to work +13:10 < ant> <jnymo> wow +13:10 <@jrandom> b1tchin postman +13:10 < mule2> i don't think that is the preferred ideal. we'd better have some traffic through all nodes +13:10 < ant> <jnymo> i could handle that if people just loved me :( +13:10 <+postman> yep +13:10 < mule2> as kind of cover traffic +13:10 <@jrandom> mule2: its a matter of our load being much less than our network capacity +13:11 <@jrandom> i dont think we'll be able to keep the capacity greater than the load for long +13:11 < ant> <jnymo> mule2, postman is also act as i mixer.. so its hard to tell where you packets are going after they go in +13:11 <@jrandom> so i'm not too worried about not pushing any data through slower peers +13:12 < mule2> probably less perfect optimization would be good for anonymity +13:12 <@jrandom> otoh, it also gives incentive for more people to (implement &) use i2pcontent, so they can mirror as well as gain cover traffic ;) +13:12 < jdot__> i it a security issue that one router handles all(ish) tunnels? +13:13 <@jrandom> mule2: lets first get it as good as we can get it, then we can discuss proactively making it worse +13:13 <@jrandom> jdot__: we don't have one router handling all of the traffic, but we are seeing the grouping of routers who are on very fast connections (colo, etc) handling more than dialup/dsl/cable users +13:14 <@jrandom> plus the reduced tunnel failures means we're shifting & exploring less +13:14 < mule2> perhaps some traffic distribution would be possible, as long as we are far from the routers limits +13:14 <@jrandom> right, probabalistic tunnel rejection is in the router and can be enabled based on the router's bandwidth limits +13:15 < ant> <jnymo> yea, but such high throughput on postman's node makes it harder to analyze his node.. so it might be safer to send through him than for all nodes to do one KBs.. +13:15 <@jrandom> (but if postman doesnt set any limits, we can't reject based on a % of that ;) +13:15 < ant> <jnymo> groupings of faster nodes cause something of a mix cascade structure, no? +13:15 <@jrandom> aye, that is one way to look at it +13:15 < lektriK> can I close the Start I2P window? +13:15 * postman is very sorry NOT to restrict his bandwidth +13:16 <@jrandom> lektriK: unfortunately, not really, unless you start i2p as a service (See http://localhost:7657/configservice.jsp) +13:16 <@jrandom> heh postman dont worry, we'll back off your router if/when we reach your router's capacity +13:17 < lektriK> Ok, it sais service started +13:17 < lektriK> can I close it now? +13:17 <@jrandom> lektriK: no/yes - you can shut down your router then start it again via start->run->"net start i2p" +13:18 < mule2> as it is, a few very big routers could handle all the tunnels, removing all cover traffic from all other routers. but lets continue with that after the meeting. +13:18 < mule2> don't want to complain about the network behaving to good :) +13:18 <@jrandom> hehe +13:20 <@jrandom> some further exploration will occur with 0.5, though there are anonymity related issues with spreading too far. there'll be further details to be worked through on that for 0.5 though (and in the doc which might be ready next week as a first draft) +13:21 <@jrandom> anyway, anyone else have something to bring up for 0.4.2.5? +13:21 <@jrandom> or shall we move on briefly to 2) 0.5? +13:21 <+postman> move +13:21 < ant> <jnymo> very stable... move +13:21 <@jrandom> consider us moved +13:22 <@jrandom> 2) 0.5 +13:22 <@jrandom> yeah. still work in progress. more info when its ready. +13:22 < ant> <Quadn-werk> Sir Arthur C. Clarke is alive :P +13:22 < ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 +13:22 < ant> <jnymo> .5 is exciting +13:22 <@jrandom> ok, thats all i have to say on that - anyone have any questions / things to discuss about it? +13:23 <@jrandom> aye, there are definitely some important revamping going on, based on what we've learned over the last 16 months +13:23 <@jrandom> (or shit, 18) +13:23 <+postman> jrandom: so 0.5 will emnploy a new tunnel management system mostly? +13:23 < ant> <Quadn-werk> arg, i hope i didnt interrupt the meeting :/ +13:23 <+postman> wow +13:23 < ant> <Quadn-werk> sorry heh +13:23 < ant> <jnymo> heh. i had a suggestion +13:24 <@jrandom> yeah postman, new management, pooling, and building +13:24 <+postman> quadn: look what you've done - your paste caused a netsplit :) +13:24 <@jrandom> you bastard! +13:24 < ant> <Quadn-werk> ! +13:24 <@jrandom> sup jnymo? +13:24 <+postman> jrandom: will every tunnel be a separate local destination still? +13:25 <@jrandom> huzzawuzzah? +13:25 <@jrandom> there won't be any change to i2ptunnel in 0.5 +13:25 <+postman> jrandom: ok +13:25 <@jrandom> (at least, i dont plan on any) +13:26 < mule> postman mounting an intersection attack? +13:26 < ant> <jnymo> for those who aren't getting /any/ bandwidth usage.. how bout letting routers build tunnels with them in it.. like ABCABCA +13:26 <+postman> mule: no, it was quadn's fault :) +13:26 < ant> <jnymo> and that would be a dummy tunnel +13:27 <@jrandom> jnymo: advertising a router as saying "hey i have excess bandwidth, use me" is a dangerous game +13:27 <+postman> jrandom: what issues will then be addressed by the redesign ( in a nutshell ) +13:27 < ant> <jnymo> not sure i meant that, jrandom +13:27 <@jrandom> but what it looks like now is that we'll have two sets of tunnels - the normal ones, and then exploratory ones, where the later are built from randomly selected non-failing peers +13:28 < ant> <jnymo> jrandom: i meant creating a dummy tunnel, and putting my self in the middle of that tunnel just to simulate some traffic +13:29 <@jrandom> postman: making it much harder to correllate peers in a tunnel, allowing clients to effectively choose their outbound tunnel length, and providing the options necessary for addressing the predecessor attack (with various tradeoffs) +13:29 <@jrandom> (oh, and improving performance by getting rid of a lot of modPow calls) +13:29 <+postman> ok thanks +13:29 < ant> <jnymo> postman: and per hop tunnel ids is a big one +13:30 <+postman> modpow? +13:30 <@jrandom> ah jnymo. yeah, there's a lot of potential for various chaff traffic generation +13:30 < ant> <jnymo> that way, no two non-neighboring nodes can know there on the same tunnel, postman +13:30 <@jrandom> postman: modular exponentiation, heavy cpu usage & memory waste +13:31 < ant> <jnymo> jrandom: k cool +13:31 <+postman> k +13:31 < scintilla> jrandom, wrt to letting clients choose tunnel length: will there be anything in place to keep ppl from cranking it up to 99 (or whatever)? +13:31 < ant> <jnymo> cpu power +13:32 <@jrandom> when necessary we can add hashcash, but excessively long tunnels will just end up failing anyway +13:32 < scintilla> ah good point +13:32 <@jrandom> we could even add in some trickery - requiring that a tunnel have a valid tunnel message pumped through it within 60s of creation for it to be 'valid' +13:33 <@jrandom> (so if the tunnel was 20 hops long, it'd take them too long to build all those hops) +13:33 < scintilla> that's a great idea - that'll keep any such ridiculousness from lingering for very long +13:33 <@jrandom> but thats all vs the hackers. normal users will just use the exposed interface +13:34 < ant> <jnymo> right, which you'll cap off somewhere right? +13:34 < ant> <jnymo> we'll get higher than the maximum 2 as it is now, right? +13:34 <@jrandom> right, like the # hops drop down on /configclients.jsp or /i2ptunnel/edit.jsp +13:35 <@jrandom> oh i thought the max was 3 now? ok, but yeah, higher than 2 will be available +13:35 < ant> <jnymo> 3 tunnels, 2 hops +13:35 <@jrandom> ah 'k +13:35 <@jrandom> yeah, 0.5 will add in some important new tweaks, such as whether to randomize those lengths, as well as how much to randomize, etc +13:36 < frosk> the max is indeed 3 +13:36 < ant> <jnymo> hmm +13:37 <@jrandom> ah its 3 on /configclients 2 on i2ptunnel +13:37 < frosk> is 0.5 still on track for january? +13:37 < ant> <jnymo> ah +13:37 <@jrandom> yeah frosk +13:37 < frosk> goodie +13:37 <@jrandom> i wont dawdle too much longer on the streaming lib, i promise ;) +13:37 < frosk> it just sounds like a lot of work :) +13:38 <@jrandom> its actually not so bad, the hard part is getting the algorithms right +13:38 <@jrandom> (details schmetails ;) +13:39 <+postman> frosk: and it's all on paper already +13:39 <+postman> :) +13:39 < ant> <jnymo> heh +13:39 < frosk> true :) +13:39 <@jrandom> mostly yeah ;) +13:39 <@jrandom> ok, anyone have anything else for 2) 0.5? +13:39 < ant> <jnymo> nada +13:39 < frosk> el zilcho +13:40 <@jrandom> 'k, swingin on to good old fashioned 3) ??? +13:40 <@jrandom> hi +13:40 <@jrandom> anyone have anything else they want to bring up? +13:41 < ant> <jnymo> postman: there arent smtp/pop3 inproxies on i2pmail.org are there? +13:41 < cat-a-puss> I am still seeing weird delays on the client end... +13:41 <+postman> hrm no +13:41 < frosk> this is where i'd hand over the congratulatory bottle of wine for a fine year of development ;) +13:41 <+postman> jnymo: POP3 is only available for i2p users +13:41 <@jrandom> cat-a-puss: ah i missed those messages when you were around earlier +13:41 <+postman> jnymo: there IS a SMTP inproxy as MX for the domain i2pmail.org +13:42 <@jrandom> frosk: cheers +13:42 < ant> <jnymo> right right.. that's coo'.. +13:42 < cat-a-puss> Like I can have two local Destinations and when one trys to connect to another there is a delay and it is not CPU bound +13:42 < mule> cat-a-puss: do you also hand over the bonus cheque ? +13:42 * postman donates a good whiskey +13:42 <@jrandom> cat-a-puss: right, you saw a .5-1.0s delay right? +13:42 < cat-a-puss> mule: what? +13:42 < cat-a-puss> jrandom: yeah +13:43 <@jrandom> cat-a-puss: perfectly normal, part of the deferred syn +13:43 < mule> sorry, the comment was from frosk +13:43 < ant> * jnymo pulles out that crappy box wine +13:43 < mule> frosk: do you also hand over the bonus cheque ? +13:43 <@jrandom> (it waits a bit to send the SYN and the related ACK in case there is more data to bundle) +13:43 < scintilla> oh fyi, i should be receiving the book with the fortuna algorithm spec in it soon... in the meantime i've been experimenting with trying to gather entropy in java without destroying a machine +13:44 <@jrandom> ah kickass +13:44 < ant> <jnymo> mmm, someone was wanting to mount some attacks on i2p +13:44 < ant> <jnymo> who was that? +13:44 <@jrandom> connelly +13:44 < cat-a-puss> Is there a way to prevent that, or do I just have to try to avoid short lived connections where I can? +13:45 < ant> <jnymo> any word on that, jr? +13:45 <@jrandom> cat-a-puss: yeah there are some options you can pass when creating the I2PSocketManager, lemmie pull 'em up +13:46 <@jrandom> jnymo: its a long term intersection attack, so after a while he'll have data to help identify what routers particular eepsites are on. i'm sure he's going to write up some summary data for us once he's got it +13:46 < ant> <jnymo> scintalla: what's the fortuna algorithm? +13:46 < ant> <jnymo> jrandom: aight +13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 +13:48 < scintilla> it's a cryptographically secure pseudo-random number generator... something which is absolutely essential for trustworthy encryption +13:48 < jdot__> anyone volunteer for that attack yet? +13:48 <@jrandom> cat-a-puss: then be sure to flush() after write()ing to the I2PSocket +13:48 <@jrandom> jdot__: yeah, he has 7 volutneered sites +13:48 < cat-a-puss> jrandom: ok +13:49 < ant> <jnymo> wrt the great naming debate.. +13:49 < ant> * jnymo snickers +13:49 <@jrandom> oh and i2p.streaming.initialAckDelay=1000 +13:49 <@jrandom> or even =100 +13:49 * jrandom flings mud at jnymo +13:50 < ant> <jnymo> i actually do work with x500 and my job lets me have free winSevers +13:50 < ant> <jnymo> so, perhaps i'll just set up a central DNS for testing purposes in a month or two +13:51 <@jrandom> heh, having a centralized naming server hosted on a .mil would be bloody hilarious +13:51 < ant> <jnymo> though hacking i2p addresses into winserver may be non-trivial.. dunno +13:51 < ant> <jnymo> heh.. dnsalias is the ticket +13:52 <@jrandom> nano has done some really cool work, integrating dnsjava with i2p +13:52 < ant> <jnymo> ooooh +13:53 <@jrandom> check out nano.i2p for more details +13:53 < ant> <jnymo> and no one was going to tell me.. ah, thanks +13:53 <@jrandom> but, as mentioned last time, people should post up their thoughts and ideas about naming to the wiki +13:54 <@jrandom> ok, anyone else have something to bring up for the meeting? +13:55 < ant> <jnymo> nope +13:57 <@jrandom> ok in that case +13:57 * jrandom winds up +13:57 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/122.rst b/i2p2www/meetings/logs/122.rst new file mode 100644 index 00000000..0a9da382 --- /dev/null +++ b/i2p2www/meetings/logs/122.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 28, 2004 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/123.log b/i2p2www/meetings/logs/123.log new file mode 100644 index 00000000..dba2ec01 --- /dev/null +++ b/i2p2www/meetings/logs/123.log @@ -0,0 +1,154 @@ +13:09 <@jrandom> 0) hi +13:09 <@jrandom> 1) Net status +13:09 <@jrandom> 2) 0.4.2.6 +13:09 < ant> <DrVince> It says that it can't find tools.jar but doesn't stop +13:10 <@jrandom> 3) 0.5 +13:10 <@jrandom> 4) jabber @ chat.i2p +13:10 <@jrandom> 5) ??? +13:10 <@jrandom> 0) hi +13:10 * jrandom waves +13:10 < eco> hi +13:10 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-January/000541.html +13:10 <@jrandom> DrVince: if you can hang around, we can hack through that after the meeting +13:10 < ant> <DrVince> Cool +13:11 <@jrandom> jumping on into 1) Net status +13:11 <@jrandom> (as i'm sure y'all have read the weekly status notes already *cough*) +13:11 <@jrandom> basically, the net seems to be working well +13:11 <@jrandom> we still do have more irc disconnects than usual though, but not a horrid amount +13:12 <@jrandom> hopefully the next release (with the streaming lib improvements) will help out, as will further load balancing off duck's server +13:12 <@jrandom> (since remember, every message we send to any irc channel is sent to the irc server and echoed out again several times) +13:13 <+protokol> yeah +13:13 <@jrandom> a fully distributed chat system would be neat, but i'm not holding my breath. plus, irc works good enough +13:14 <@jrandom> ok, thats all i have wrt 1) net status +13:14 <@jrandom> does anyone have anything to add, comment, etc? +13:14 * eco has been away for a while (what's new) +13:15 < eco> and was happily surprised by the state of things. very good progress +13:15 < Myo9> Wasn't the meeting at 10? +13:15 < eco> both performance and usability wise +13:15 < eco> Myo9 10GMT (general meeting time) +13:16 <@jrandom> 9p GMT +13:16 <@jrandom> the last year has definitely brought a lot of progress +13:17 * eco hands out cookies to all devs and then shuts up +13:17 <@jrandom> *munch* +13:17 <@jrandom> ok, jumping on to 2) 0.4.2.6 +13:18 <@jrandom> new release coming with bugfixes, improvements, and the addressbook bundled in +13:18 <@jrandom> i dont know exactly when it'll be out, maybe end of the week +13:18 <@jrandom> it'll be announced on the list and in the channels, of course +13:19 <@jrandom> thats all i have to say on that - anyone have any questions/comments/concerns wrt 0.4.2.6? +13:19 * eco recalls someone mentioning Debian packages +13:20 <@jrandom> os/distro-specific packaging is probably premature at the moment +13:20 < eco> Burton is willing to give that a try, but that won't be this week i guess +13:20 <@jrandom> ah cool, i hadn't heard that +13:21 < eco> agree, though it would be handy +13:21 <+protokol> hold on, im pretty high +13:21 <+protokol> oops +13:21 <+protokol> that was supposed to be a PM +13:21 <@jrandom> distro-specific packaging will be nice, but we probably need to have the auto-updater in place for that to be viable +13:21 <+protokol> i can look into making an ebuild +13:21 <@jrandom> protokol: if you're nice, i'll cut that out of the logs ;) +13:21 <+protokol> no guarentees +13:21 <+protokol> lol +13:22 <@jrandom> yeah, i wouldn't worry about packages until 0.5, if not 1.0 +13:22 <@jrandom> (i hope to have the auto-updater in 0.5) +13:22 <+protokol> awesomecore +13:23 <@jrandom> actually, if someone wants to work on the updater, that'd be a pretty kick-ass low-hanging-fruit. just write a servlet to download and verify from dev.i2p/i2p/i2pupdate.zip, then call the router's restart method +13:23 < Myo9> Auto-updater, sounds like a threat. +13:23 <+protokol> modulus: welsome +13:23 <+protokol> $200 bounty for it +13:24 <@jrandom> heh true myo9, the update would want to allow both manual controls (one click update) and would want to verify a signature on the update +13:24 < ant> * DrVince had a problem with i2pupdate.zip +13:24 < ant> <cervantes> something that can be enabled or disabled would be nice ;) +13:24 * protokol makes it offical +13:24 < Myo9> So, all of a sudden, the router restarts and one notices Jr. has teamed with the IP ppl and DRM is enabled. +13:24 <@jrandom> protokol: oh cool, send in the $200 and i'll add that to the bounty page +13:24 < Myo9> ;) +13:24 < Myo9> I want auto-update turned off by default. +13:24 <@jrandom> agreed myo9 +13:25 < ant> <cervantes> perhaps the routerconsole can be ammended to notify if a new version is available +13:25 <@jrandom> right cervantes +13:25 < Myo9> Great! +13:25 <@jrandom> it would want to display whether there is a new release, and give the user a one click option to upgrade +13:25 <@jrandom> (it'd be easy enough to add a web page @ www.i2p/ that contains the current version, so the router could check that periodically) +13:26 <@jrandom> ((or on demand)) +13:26 < Hybrid> yes jrandom. that would be cool. also on the button a link to 'whats new' html page +13:26 <@jrandom> Hybrid: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD +13:26 < ant> <cervantes> yeah...I've got a page on the forum that lets my firefox toolbar know of latest "events"/news +13:27 <@jrandom> but yeah, a link there too would be nice +13:27 <@jrandom> ah cool cervantes +13:27 < Hybrid> don't forget to put the version the user is currently running and the new version number available. (I like the way dvd decrypter does this) +13:27 < ant> <cervantes> don't count on me releasing anything yet though.... +13:28 <@jrandom> right right Hybrid, the current version the user is running is visible on the top left corner of the router console, so it shouldnt be a problem +13:28 < ant> <cervantes> wanted to spend the holidays working on it and have so far done absolutely nothing... +13:28 <@jrandom> but this won't be bundled into the 0.4.2.6 release, because i havent written any of this code :) +13:28 <@jrandom> heh cervantes, i hear you. i do look forward to the xul though! +13:29 <@jrandom> ok, anyone have anything else wrt 2) 0.4.2.6, or shall we move on to 3) 0.5? +13:29 < Hybrid> is it a problem for i2p to shutdown, new version install, and restart... would other applications irc need restarting??.. any other complications in a 'click n update' feature +13:30 < Hybrid> (sorry interrupting dev meeting lol) +13:30 <@jrandom> Hybrid: not a problem at all - thats what the "graceful restart" button on http://localhost:7657/configservice.jsp does +13:30 < Hybrid> k +13:31 < ant> <cervantes> jrandom: does the wrapper re-read the wrapper.config on a restart? +13:31 <@jrandom> cervantes: no :( +13:31 <@jrandom> i wish it did +13:31 < ant> <cervantes> guess we need a wrapper service wrapper +13:32 <@jrandom> perhaps someone could get a patch in to the java service wrapper folks +13:32 <@jrandom> heh +13:32 <@jrandom> ok, jumping to 3) 0.5 +13:32 <@jrandom> well, i dont really have much to say about this beyond whats in the email +13:33 <@jrandom> lots of progress, many sheets of paper, and some code. nothing committed or ready for show yet though +13:33 <@jrandom> thats 'bout all i have to say on that front, unless someone has any questions +13:34 <@jrandom> if not, we can mosey on over to 4) jabber @ chat.i2p +13:35 <@jrandom> new jabber server (w00t!). see the email & the forum for details +13:35 <@jrandom> aparently it was dirt easy to set up the server too, so hopefully we can get some docs out there so that other people can run their own +13:35 < frosk> i think it's the third i2p has had. i hope this one sticks around :) +13:36 < jdot> docs are coming. its easy a heck w/ Jive Messenger. Just tunnel the ports properly. +13:36 <@jrandom> personally, i'm fine with irc for one on one and group chat, but having the option for jabber is cool +13:36 <@jrandom> ah word jdot +13:36 <@jrandom> no rush, whenever is great +13:37 <@jrandom> it'd just be great to be able to tell people that if they dont like how things are on one particular irc srever, they can go run their own :) +13:37 < jdot> also will be looking to changate it with the irc channels .. in the future +13:37 <@jrandom> nice +13:38 <@jrandom> ok, thats all i have to say on that. you have anything you want to add jdot? +13:39 <+protokol> how does one get on chat.i2p +13:39 <+protokol> tis not resolve for me +13:39 <@jrandom> http://forum.i2p.net/viewtopic.php?t=229 +13:40 < jdot> nothing to add. +13:40 * eco has peeked at java service wrapper in the mean time +13:40 < eco> re-reading the config file has been implemented for the upcoming 3.20 release +13:40 < eco> see http://sourceforge.net/tracker/index.php?func=detail&aid=981060&group_id=39428&atid=425190 +13:41 <@jrandom> ah wikked +13:41 * eco doesn't know when that's due though +13:41 <@jrandom> perhaps with 0.5 we'll do a big external-app-upgrade, replacing our aging jetty and java service wrapper code +13:42 <@jrandom> oh, before i go on, i suppose we should officially move to 5) ??? +13:42 <@jrandom> protokol: i think i remember you saying you got jetty working with CGI? any docs / info on that? +13:43 <@jrandom> someone else out there was able to get jetty to do symlinks too, though i dont know who +13:43 <@jrandom> (you out there, whoever you are? how'd you do it? :) +13:44 <@jrandom> or, i suppose, anyone else have anything they want to bring up? +13:45 * eco has a public service announcement +13:45 < eco> there's a bounty for succesfully pulling i2p through gcj +13:45 < eco> according to jr this will be dead simple, so go get it! :-) +13:45 <@jrandom> heh, not dead simple, that was just wishful thinking ;) +13:46 <@jrandom> but it might be +13:46 <@jrandom> (so go get it :) +13:46 < cervantes> think I posted links concering jetty symlinks somewhere either in chat or on the forum...can't remember which +13:46 < cervantes> was a while back now +13:46 <+protokol> jrandom: it was for the more recent version, i just crashed my jetty +13:46 < slart> any news on the azureus plugin? +13:46 <+protokol> i think jetty should be borught up-to-date so the docs on their website are useful +13:46 < Hybrid> gcj? +13:46 <+protokol> makes java into a binary +13:46 <@jrandom> ah cool cervantes, i'll dig around for it +13:47 < cervantes> I've looked at jetty with php...but it's a very hit an miss affair... php comes with a servlet .jar executable for use with tomcat..., I've seen reports that it can be made to work with jetty...but I have no idea how +13:47 <@jrandom> protokol: ah +13:47 <+protokol> and it needs cgi and symling support as well +13:47 <@jrandom> slart: the azureus devs are hacking away and making progress, but its not ready yet +13:47 <+protokol> cervantes: DO IT! +13:48 <+protokol> it would be like apache built into i2p +13:48 < frosk> Hybrid: The GNU Compiler for Java, or sumthing +13:48 <@jrandom> cervantes: yeah, .jar support would be neat, but if its flakey, not worth it. having cgi support in jetty would be best, sicne we could then use normal php +13:48 < slaw> excellent +13:48 < frosk> mod_i2p :) +13:49 <@jrandom> heh +13:50 <@jrandom> ok, anyone else have anything they want to bring up for the meeting? +13:51 <@jrandom> if not... +13:51 * jrandom winds up +13:51 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/123.rst b/i2p2www/meetings/logs/123.rst new file mode 100644 index 00000000..08c1f4a1 --- /dev/null +++ b/i2p2www/meetings/logs/123.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 4, 2005 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/124.log b/i2p2www/meetings/logs/124.log new file mode 100644 index 00000000..e54caf72 --- /dev/null +++ b/i2p2www/meetings/logs/124.log @@ -0,0 +1,378 @@ +13:10 < jrandom> 0) hi +13:10 < deer> <Ragnarok> you're fired +13:10 < jrandom> 1) Net status +13:10 < jrandom> 2) 0.5 progress +13:10 < jrandom> 3) 0.6 status +13:10 < deer> <polecat> bye! +13:10 < jrandom> 4) azneti2p +13:10 < jrandom> 5) fbsd +13:10 < jrandom> 6) hosts.txt as WoT +13:11 < jrandom> 7) ??? +13:11 < jrandom> 0) hi +13:11 * jrandom waves +13:11 < fdr> yo +13:11 < deer> <Ragnarok> hola +13:11 < toad_> you just starting? /me will just watch from time to time +13:11 < deer> <detonate> hi +13:11 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000551.html +13:11 < jrandom> cool, all are welcome +13:11 < deer> <polecat> Oh. Not your employment. My bad. =3 +13:11 < jrandom> the logs of the dev meetings are posted up @ the website (after the meeting, of course) +13:11 < fdr> I'm starving, so I'll be in and out.. +13:12 < jrandom> ok, swinging on int to 1) Net status +13:12 < jrandom> things seem to be working fine. duck is back (yay!) +13:12 < jrandom> I dont really have much to add beyond whats in the email - anyone else have anything? +13:13 < deer> <jrandom> nope +13:13 < jrandom> ok, if not, moving on to 2) 0.5 status +13:14 < jrandom> There's been some good progress here, finally got the matrix encryption working, but after chatting with polecat the other day, theres a little tweak we need to add on +13:14 < toad_> talking to yourself? +13:14 < jrandom> heh yeah, until anyone replies ;) +13:14 < jrandom> (you should have seen these meetings before I posted the weekly status notes beforehand) +13:14 < toad_> I meant across networks. I talk to myself all the time, but not usually across networks. ;) +13:15 < deer> <jrandom_> across three networks even [iip here] +13:15 < deer> <Ragnarok> stop that, it's creepy :) +13:15 < deer> * postman waves +13:16 < jrandom> I dont really have anything else to add wrt 0.5, beyond "more info coming soon" +13:16 < deer> <polecat> Re net performance, my i2p router went down 24h ago, but before that I managed 8 days of uptime. +13:16 < jrandom> ah ok cool +13:16 < jrandom> OOMed? were you running bt or just from activity? +13:17 < deer> <polecat> Just a heuristic to brag about. =3 +13:17 < deer> <frosk> i generally get as much uptime from my router as i want, although usually no more than 8-9 due to upgrades :) +13:17 < deer> <frosk> 8-9 days, that is +13:18 * jrandom wishes my kaffe box could do that (oh well) +13:18 < deer> * orion can crash a router at will by running 40+ local destinations via btlaunchmanycurses.py. ;) +13:18 < jrandom> heh yes, that would do it orion +13:18 < deer> <polecat> Oh, the logs say that the JVM appears hung, so I suppose lucky must have used me in a tunnel to download gigabytes of over endowed men. +13:18 < deer> <orion> but, I've had uptime of 15 days before BT storms. +13:18 < jrandom> oh interesting polecat. +13:19 < jrandom> polecat: if you're feeling brave, it might be worth trying the latest java service wrapper +13:19 < jrandom> (if it gets rid of that we should upgrade) +13:19 < deer> * laberhorst had uptime 15days with 0.4.2.5 without bt +13:19 < jrandom> i think cervantes is still the winner w/ 0.4.1.1 @ 41 days +13:20 < deer> <polecat> Anyone want to PM me on how to get the latest java service wrapper? +13:20 < jrandom> but anyway, anyone have any comments on 0.5 stuff? +13:20 < protok0l> is i2p done yet? +13:20 < jrandom> http://wrapper.tanukisoftware.org/doc/english/ +13:20 < deer> <eco> looking forward to the docs +13:20 < jrandom> !thwap protok0l +13:21 < jrandom> ok, moving on to 3) 0.6 status +13:21 < deer> <polecat> I still think that there ought to be a way to checksum without the gateway knowing all the checksums, or how many. +13:21 < deer> <Ragnarok> where are the documents going up? +13:21 < jrandom> polecat: I'd love it, but I doubt it can be done. +13:22 < jrandom> Ragnarok: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD is the current draft +13:22 < jrandom> (not updated wrt the first hop issue) +13:22 < deer> <Ragnarok> thanks +13:22 < deer> <polecat> "They said it couldn't be done.... they called me mad... but they were fools, FOOLS! +13:22 < jrandom> heh +13:22 < jrandom> hey, if you can find a way, I'm all ears +13:23 < jrandom> (and I have a feeling the mixmaster/mixminion folks will be too) +13:23 < deer> <jrandom> zounds, 42 usres here +13:23 < deer> <jrandom> mule: you 'round? +13:24 < deer> <polecat> Heh. Will keep my nose to the ground then, but no promises as I'm just a dumb ferret not geniushes like y'all. +13:24 * jrandom flings a small furry animal at polecat +13:25 -!- dm [mihi@dsl-80-42-80-26.access.uk.tiscali.com] has joined #i2p +13:25 < jrandom> ok, anyway, 0.6 stuff looks interesting, and mule has started on some hacking, but its still early on in the game +13:26 < jrandom> zab has been pretty helpful giving us some guidance from how limewire goes about things, but, well, their congestion control is kind of scary (fixed small windows, full ack) +13:26 < jrandom> (but i'm sure they'll improve in time, of course) +13:26 < jrandom> also was nice of him to give us a view into how they're having the rubber hit the road, what gotchas they've had with various jvms, etc +13:27 < jrandom> (yay zab) +13:27 < jrandom> in any case, if you're interested in helping out with the design and implementation or integration of some other provider for 0.6, get in touch with either mule or myself (or, of course, send patches ;) +13:28 < jrandom> not much else to say on that, unless anyone has anything to bring up? +13:28 < deer> <polecat> Isn't 0.6 supposed to have preliminary fusenet support? +13:28 < deer> <frosk> by april, hopefully :) +13:29 < toad_> fusenet? +13:29 < deer> <frosk> but with all this work on the udp transport, maybe it'll be ready before fusenet will +13:29 < jrandom> yeah, the general aim is just to get the ball rolling +13:29 < deer> <frosk> fusenet is a content-distribution system more or less like usenet on speed +13:29 < toad_> cool +13:30 < deer> <frosk> it will initially support blogs, discussion forums and addressbooks for i2p name-destination mappings +13:30 < jrandom> though of course, if we get the UDP transport implemented next month, we'll probably roll that out with 0.5 +13:31 < deer> <frosk> of course, that would be cool :) +13:31 < jrandom> and if i had a pony, i'd play with him aaaaalll day +13:31 < jrandom> ok, thats prolly 'bout it for 0.6 stuff, moving on to 4) azneti2p +13:31 < deer> <frosk> i'm glad you have no pony, then ;) +13:31 < jrandom> heh +13:32 < jrandom> azneti2p == kickass. +13:32 < jrandom> parg & the rest of the azureus folks have done some great work, and the integration is really nice +13:33 < jrandom> torrents work the same as before, show up with all the pretty graphs, lets you do all the queueing / etc you're used to in azureus, except anonymously +13:33 < deer> <postman> w00t! +13:33 < jrandom> there are still further optimizations and simplifications left to do, but all in all, i'm quite impressed +13:33 < deer> <eco> hurray! enter the masses... +13:33 < deer> <frosk> i understand you still have to do some manual labour in the router console before you can use it? +13:33 * jrandom holds the gates closed for just a litttttle wile longer +13:33 < deer> <eco> is java 1.5 indeed required? +13:34 < deer> <polecat> Yup.. neat stuff except you can't leave it to daemon out. +13:34 < deer> <postman> sounds like the invitated for the i2p network to get his ass kicked badly +13:34 < jrandom> frosk: right - but we're working on patching it up to do the I2PTunnel calls within the plugin itself +13:34 < deer> <frosk> cool +13:34 < jrandom> eco: unsure, I only tried it with 1.5, but I believe them when they say it. +13:34 < deer> <polecat> eco: I should hope not. o.O 1.5 is just Sun trying to strongarm the market. +13:34 < jrandom> worth trying though, i'll do so later +13:35 < deer> * postman does not care, i got gigabit ethernet interfaces and LOTS of traffic included :) +13:35 < deer> <polecat> Oh dear... and azareus requires it. I _really_ have to make my C++ torrent app. +13:35 < jrandom> polecat: azureus does have a headless mode of operation, and a web console +13:36 < deer> * polecat blinks. +13:36 < jrandom> (but its... tough to the uninitiated [like myself]) +13:36 < deer> <polecat> Well okay then... I thought it didn't, like KazAa +13:36 < jrandom> but i only glanced at it (and ran back to the GUI ;) +13:36 < deer> <Ragnarok> is duck going to be bringing i2p-bt up to 3.9/4.0? +13:37 < jrandom> ragnarok: unknown, but duck is currently doing leaps and bounds to keep all the existing stuff compatible with azneti2p +13:37 < jrandom> (they had to do some... odd changes due to technical requirements) +13:37 < deer> <polecat> One of the most powerful aspects of p2p is if the app can run quietly in the background whet you're not using it. +13:38 * jrandom isnt arguing with that point +13:38 < jrandom> ok, i think thats all i have to say wrt azneti2p (other than w00t, again). more info in the email, and there'll be lots of activity in #i2p-bt i'm sure +13:39 < jrandom> anyone else have anything to bring up wrt azneti2p? +13:39 < cervantes> are you ready for it... ;-) +13:40 < jrandom> heh, we're workin' on it +13:40 < deer> <polecat> Might I note that the source of azareus is totally abysmal... +13:40 < deer> <polecat> There are 28 main entry points, and it uses at least a namespace depth of 3. +13:40 < deer> <Ragnarok> does any bt client have nice source? +13:40 < jrandom> there are some oddities, but i suspect you'll find that in anyone else's source (NIH) +13:40 < deer> <polecat> Mine will. +13:40 < jrandom> oh c'mon, net.i2p.router.netdb.kademlia.* :) +13:41 < deer> <Ragnarok> not if it's in C++ it won't :) +13:41 < toad_> lol +13:41 < deer> <polecat> I said at least! +13:42 < jrandom> ok, anyway, moving us along to 5) fbsd +13:42 < deer> <polecat> Ragnarok: You've never seen how I *cough*rape*cough* use C++. n.n +13:42 * duck looks in +13:42 < deer> <polecat> Who cares about FreeBSD? Show of hands? +13:42 < jrandom> lioux has packaged up the 0.4.2.6 release into ports (w00t!) +13:42 < deer> * detonate raises his +13:42 < deer> <polecat> Paws, tentacles, wings, etc? +13:43 * jrandom raises my hand +13:43 * [dave] raises +13:43 < deer> <Ragnarok> duck: 3.9/4.0? :) +13:43 < deer> <polecat> Woah, i2p is integrated into a distribution? +13:43 < duck> Ragnarok: the lack of comments / docs / etc on the latest bram-Bittorrent changes were a bit of a setback +13:43 < fdr> FreeBSD is cool :( +13:43 < deer> <Ragnarok> I'll bet +13:43 < fdr> I may be biased though. +13:44 < jrandom> aye, i was worried at first polecat, but his ports impl looked really really easy (so updates will be really really easy) +13:44 < duck> It would require studying what they did, maybe it would be worth the effort +13:44 < deer> <polecat> As far as I'm concerned, fbsd is a distro with an odd kernel and lots of data hiding. It's all POSIX in the end so... ;) +13:44 < jrandom> polecat: and very, very w0nky JVMs +13:45 < duck> though secretly I have been hoping on azneti2p solving all problems +13:45 < deer> <Ragnarok> duck: it did sound like there were some nice improvements, but you're the one who'd probably be doing the work, so... :) +13:45 < deer> <polecat> Ugh... don't remind me. +13:45 < jrandom> heh, azneti2p will probably fit the needs of many users, but simple CLI tools will still make sense for the ubergeeks out there +13:46 < jrandom> anyway, so it seems he's tested i2p 0.4.2.6 on fbsd5.3 without problems (w00t) +13:46 < deer> <Ragnarok> oy, I don't like azureus, I'd much rather use the normal client +13:46 * jrandom has only done so on 4.8 +13:46 < duck> currently I'd like to do something with kenosis; being a hit-n-run coder +13:47 < deer> <eco> jrandom: what jvm did he use? +13:47 < jrandom> kenos2p +13:47 < jrandom> eco: native compiled sun 1.4 +13:47 < jrandom> (booo hiss) +13:47 < deer> <eco> ah, illegal! +13:47 < deer> <polecat> Ragnarok: If you want to critique my bittorrent client design, my current code plan is here: http://polecat.i2p/bittorrent.plan.txt +13:47 < jrandom> ((but kaffe works)) +13:48 < jrandom> eco: is it illegal? I thought you could agree to the terms and get the source legit on fbsd +13:48 < deer> <eco> sun withdrew the license afaik +13:48 < jrandom> hmm, i think thats just the blackdown license +13:48 < jrandom> (and, tbh, blackdown sucks) +13:49 < jrandom> individuals can still license it under SCSL +13:49 < deer> <polecat> ouch. +13:49 < jrandom> (first born child, etc) +13:49 < jrandom> heh, its interesting to hear such license gripes when so few have copyright gripes ;) +13:50 < jrandom> but this discussion is best for the 7) ?? +13:50 < jrandom> and we're on 5) fbsd +13:50 < deer> <eco> license stuff on http://www.freebsdfoundation.org/press/20041221-newsletter.shtml , but back to the main thread... +13:50 < cervantes> first time we've crept above 5) in a long time +13:51 < jrandom> cervantes: and we had to trim things ;) +13:51 < jrandom> ok, i think thats it for fbsd stuff (beyond yay!) +13:51 < jrandom> so jumping into a messy one... 6) hosts.txt as a WoT +13:51 < deer> <polecat> licensing can get you at the node though, whereas copyright vio can only be tracked to the destination. +13:51 < deer> <polecat> Which "can't" be found. +13:52 < jrandom> right right polecat, but once They have physical control of your box, you're in deep shit anyway +13:53 < jrandom> ok, anyway I'm not sure if there's much I have to add to what was posted in the email wrt hosts.txt +13:53 < jrandom> anyone have any questions/comments/concerns? +13:53 < jrandom> (was I vague enough? :) +13:53 < duck> yes +13:53 < deer> * eco considers handing hosts.txt management over to the UN +13:54 < jrandom> heh yeah, because we know nice centralized beurocratic authorities always Do The Right Thing +13:54 < toad_> lol +13:55 < jrandom> i suppose the real "big win" will be when the addressbook gets both a web interface and more metadata +13:55 < jrandom> (and perhaps the fusenet syndication, etc) +13:55 < deer> <Ragnarok> metadata will be the next thing I work on, using xml name records +13:56 < jrandom> kickass ragnarok! +13:56 < jrandom> whats your take on the WoT side ragnarok - do you see it as an issue with the addressbook, or how you forsee naming? +13:57 < deer> <Ragnarok> Essentially I think the way addressbook works (and how passing around name references on fusenet will work) is the only really sensible way to handle naming on i2p +13:58 < deer> <Ragnarok> so, the WoT is a feature :) +13:58 < jrandom> Wo0T +13:58 < lucky> whoa +13:58 < deer> <eco> but surely you sell premium accounts? +13:58 < lucky> is that a toad i see? +13:58 < lucky> a real toad? +13:58 < lucky> or just a frog. +13:58 < deer> <frosk> the important point imho, is how to handle collisions +13:59 < toad_> a toad +13:59 < deer> <detonate> first come, first serve +13:59 < jrandom> right frosk, it'd be nice to have an interface to manage those, rather than just "read the log" +13:59 < deer> <Ragnarok> frosk: I think that's more an issue of interface than anything else. Collisions will have to be resolved by the user. +13:59 < toad_> call my name if it gets close to my area :) +13:59 < deer> <frosk> Ragnarok: my thinking too +13:59 < deer> <Ragnarok> anything else can be attacked +13:59 < lucky> oh, not the freenet toad. +13:59 < lucky> oh +13:59 < lucky> it is. +13:59 < deer> <eco> so the names are simply like aliases in IM? +14:00 < deer> <frosk> collisions need to be stored so you can switch long after the fact +14:00 < deer> <Ragnarok> and is probably not provably better in the general case +14:00 < lucky> we're paying toad now? +14:00 < jrandom> eco: right - the names are just private local nicknames +14:00 < deer> <susi23> the addressbook should recognize collisions and notify the user so he can decide +14:01 < deer> <Ragnarok> frosk: after the switch to name records, the intent is to never throw them away, but make it easy to change the address they correspond to +14:01 < deer> <susi23> until the user made his decision any changes regarding the collision should somehow get "quarantined" :) +14:01 < deer> <Ragnarok> susi23: that's essentially how it works now +14:01 < deer> <Ragnarok> it just has a lousy interface +14:01 < deer> <frosk> Ragnarok: sounds good :) do you have a web interface in the works? (or is there one already i'm not aware about?) +14:02 < deer> <susi23> fine then +14:02 < deer> <Ragnarok> nope. I don't do web interfaces :) +14:02 < deer> <Ragnarok> susi was working on something, I think, but I'm not sure what's happened with that +14:02 < jrandom> (volunteers? any chance of reviving susidns to manage the names?) +14:03 < deer> <susi23> ok, give me a week, I put it on TODO +14:03 < jrandom> (and after susidns, we need susitorrent and susiirc...) +14:03 < jrandom> wikked! +14:04 < jrandom> ok, anyone have anything else to bring up wrt that whole hosts.txt thing? +14:05 < jrandom> if not, moving on to 7) ??? +14:05 < deer> <Ragnarok> one thing +14:05 < jrandom> you've got the mic +14:05 < deer> <Ragnarok> for the next release, can we agree that hosts.txt should be managed directly by addressbook, so we can stop mangiling userhosts.txt? +14:06 < jrandom> sounds reasonable. i'll stop shipping hosts.txt in the i2pupdate.zip (but will include it in i2pinstall.jar) +14:06 < deer> <Ragnarok> cool. That's all :). +14:07 < jrandom> ok, now back to the opne floor +14:07 < jrandom> anyone else have anything they want to bring up? +14:07 < deer> <postman> yes +14:07 < jrandom> hit it postman +14:07 < deer> * postman raises his hand +14:08 < deer> * postman is desperately looking for a volunteer providing the secondary MX server for i2pmail.org ( this being an inproxy to the internal mailsystem ) +14:09 < deer> <postman> if anyone got a stable, fast (dedicated) machine, i would be very happy to accept help +14:09 < deer> <postman> configuration / howto will be delivered by me +14:09 < deer> <eco> how fast is fast? +14:10 < deer> <postman> eco: static IP wuld be nice - everything else is negotiable +14:10 < jrandom> how much traffic are you seeing through mail.i2p postman? +14:10 < jrandom> (external, that is) +14:10 < deer> <polecat> Stable, fast, dedicated... well 1/3 isn't bad. +14:10 < deer> <postman> the mailtraffic is VERY low +14:10 < deer> <postman> in/out is about 500 mails / month +14:11 < jrandom> ah cool +14:11 < deer> <Frooze> i have slow (500 MHz), stable, dedicated +14:11 < deer> <postman> BUT since the inproxy will have a I2P running +14:11 < jrandom> (that'll probably pick up as more people find out about it though ;) +14:11 < deer> <eco> the machine would be for incoming mail only? +14:11 < deer> <postman> most traffic would be I2p i guess +14:12 < deer> <postman> eco: at least incoming ( it's needed for this ) +14:12 < deer> <postman> if the operator is ok with that i would like to rotate outgoing over both machines +14:12 < deer> <postman> Frooze: it's ok, when it's able to run i2p +14:13 < deer> <postman> just drop me a mail +14:13 * toad_ wonders if his current issues are AOB business or if they are simply between him and jrandom +14:13 < deer> <postman> if anyone is interested +14:14 < deer> * postman hands back the mike +14:14 < deer> <Frooze> will do. +14:14 < deer> <postman> thanks jr :) +14:14 < jrandom> cool, thanks postman +14:14 < jrandom> toad_: i think there's much to be discussed, though largely a question for the freenet folks +14:15 < toad_> jrandom: right +14:15 < toad_> jrandom: talk after meet +14:15 < jrandom> sounds good +14:15 < duck> no public mudfight? :/ +14:15 < jrandom> ok, anyone else have anything to bring up for the meeting? +14:15 < jrandom> heh duck +14:15 < deer> * eco points at http://dodo.freenetproject.org/pipermail/tech/2005-January/001224.html +14:15 < jrandom> (that was on tehc ;) +14:15 < cervantes> postman: my box has too much shit running on it to be any help I'm afraid ;-) +14:15 < deer> <polecat> Ragnarok: If we could sign the addressbook host data, that would allow for automatic updates. Otherwise not much to be done. Even if the user gets a popup, how are they to tell which key is accurate? +14:15 < deer> <Ragnarok> what does accurate mean? +14:16 < jrandom> polecat: signing entries would Kick Fucking Ass. +14:16 < deer> <eco> fyi +14:16 < deer> <eco> no mud involved. +14:16 < deer> <Ragnarok> (and signing is planned for name records) +14:16 < deer> <postman> cervantes: hi, thanks anyway :) +14:16 < cervantes> you are indeed very welcome +14:16 < cervantes> :P +14:17 < jrandom> ok, anything else? +14:17 < deer> <polecat> Ragnarok: accurate means centered around the correct result. +14:17 < cervantes> polecat: I'm waiting for one of my clients to go bust before I sneak into one of their forgotten mailservers to install i2p +14:18 < deer> <Ragnarok> polecat: yes, but what's the correct result? +14:18 < jrandom> lol cervantes +14:18 < cervantes> %s/polecat/postman +14:19 < deer> <polecat> The addressbook file that gets sent between eepsites could do the signing in its format, keeping the other hosts.txt the same. +14:19 * duck wonders if updating dot.png is useful? +14:19 < duck> it got kind of full +14:19 < deer> <eco> give us a 3d applet +14:20 < jrandom> duck: its a bit hard to read yeah ;) +14:20 < jrandom> duck: perhaps only list the blue lines? +14:20 < jrandom> to me, the value comes from seeing how spread out green is +14:20 < jrandom> (or whether there are clusters of dark green, etc) +14:20 < deer> <Ragnarok> polecat: signing will be supported in the xml name record format. +14:21 < deer> <polecat> Ragnarok: The correct result is that the human readable name maps to the destination you expect to see, and only changes when the owner of that destination changes keys. +14:21 < deer> <polecat> Right. So... great. No problem then. +14:21 < deer> <Ragnarok> polecat: that's what we've got now +14:22 < deer> <polecat> If the signature of an update matches the original record's public key then you can update automatically, no problem. +14:24 < jrandom> ok, there's still room left to be hashed out on the Great Naming Debate, of course +14:24 < jrandom> anyone have anything else for the meeting? +14:24 < deer> * eco has a UI poll +14:24 * jrandom has a GUI +14:25 < deer> <Ragnarok> polecat: that will be supported once we've got signing :) +14:25 < deer> <eco> the i2ptunnel option in the web ui results in a popup - am i the only one less enthusiastic about that? +14:25 < jrandom> definitely not the only one eco. +14:25 < jrandom> i wrote the i2ptunnel web interface approximately as poorly as i could +14:25 < jrandom> it really, really sucks +14:25 * cervantes steals jrandom's "patches welcome" line +14:26 < jrandom> (what cervantes said :) +14:26 < jrandom> or even just plain HTML, i can integrate it with the jsp +14:26 < jrandom> (but of course patches to the jsp would be nice) +14:27 < cervantes> jrandom: btw I have a patch for what we discussed yesterday...just going to test it a little more first.... +14:27 < jrandom> ah wikked cervantes, thanks! +14:27 < deer> <eco> why not list that in the main page, like the other pages? +14:27 < deer> <eco> ok, so no big religious or technical reason behind it? +14:28 < deer> * polecat has a FUI +14:28 < jrandom> eco: from a UI perspective, it can be made to look like the other pages, but not technically +14:28 < jrandom> technically, it needs to stay seperate as a client app deployed as a seperate .war file +14:28 < deer> <polecat> Ragnarok: I thought you said that's what we've got now? +14:29 * jrandom appreciates very much mihi's contribution of that code, but I can't let the i2p console depend upon GPL +14:29 < deer> <Ragnarok> er, sorry, I meant everything but the signing, which obviously we don't do right now. +14:29 < jrandom> (but we can make it look like the other pages +14:30 < deer> <eco> ah, license issues. great +14:30 < jrandom> heh isn't it grand eco? +14:30 < deer> <Ragnarok> so currently addresses are never updated automatically, changing the destination an address points to always requires user intervention +14:30 < cervantes> jrandom: iframe :P +14:30 * jrandom wishes people just saw the IP farse for what it was and released into the public domain +14:30 < deer> <eco> but in this case a socket connection for example should be okay GPL-wise i'd guess +14:30 < jrandom> cervantes: not an impossible alternative +14:30 < jrandom> right eco +14:31 < jrandom> we've done our best to tap dance around the integration of the actual meat (using clients.config and i2ptunnel.config), but the web UI suffers a bit from it +14:33 < deer> <susi23> any wishes, feature requests, and comments regarding the addressbook interface please add to http://susi.i2p/susidns.html +14:33 * toad_ respects jrandom's extremist licensing views while disagreeing vehemently with them :) +14:33 < jrandom> oh cool, shall do susi23 +14:34 < jrandom> heh toad_ :) +14:34 < deer> * eco puts it on his when-i'm-64-to-do-list +14:34 < toad_> bbiab +14:34 < jrandom> l8r +14:34 < toad_> when i get back we need to talk about various technical issues with i2p/freenet integration +14:34 < jrandom> ok, anyone else have anything for the meeting? +14:34 * cervantes wheels out the metal gong +14:34 < toad_> will try to get back quickly +14:34 < jrandom> cool toad_, i'll be around +14:34 < jrandom> (it'll give me time to catch up on those threads ;) +14:35 * jrandom winds up +14:35 * jrandom *baf*s the gong, closing the meeting +14:35 < deer> <DrWoo> jrandom: I have one issue if you're still open to 7)??? , I just want to go back to the azureus plug-in for a moment if I may, #1 - this will be *quite* appealing to the peeps, isn't this the perfect time to try to get easy tunnel length controls into the p2p side of I2P via this plug-in, to try to make the best use of bw resources on the net? #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not, +14:35 < dm> i2p/freenet integration!? +14:35 * jrandom de-gongs +14:35 * cervantes puts the gong away +14:35 < jrandom> #1: yes, absolutely - I've sent parg a patch to do that +14:36 < jrandom> #2: [got trimmed @ 'want it or not,'] +14:38 * jrandom watches the irc streaming lib logs - +14:38 < jrandom> 14:37:55.701: SEND bRC43g==QRnB~Q==: #2 DELAY 1000 MS ACK 1 data: 29 sent 2 times +14:38 < jrandom> 14:38:20.072: SEND juVFdg==aAUIVw==: #3465 DELAY 1000 MS ACK 5723 data: 43 sent 2 times +14:40 < deer> * eco grabs a beer +14:40 < deer> <DrWoo> jrandom: #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not, are you prepared for a user influx, and if not when do you think you will be? +14:40 < jrandom> it would not be good to have a large burst of users prior to the UDP transport +14:41 < jrandom> there is still a lot of work to be done on azneti2p, so hopefully that'll buy us some time, but we'll do what we need to do +14:41 < deer> <DrWoo> jrandom: cool to see your all over #1 ;) +14:42 < jrandom> we also will need some docs for #1 too, explaining why 0 hops works for some threat models :) +14:44 < jrandom> ok, we ready for a re-gong? +14:45 * jrandom winds up +14:45 * jrandom *baf*s the meeting closed^2 diff --git a/i2p2www/meetings/logs/124.rst b/i2p2www/meetings/logs/124.rst new file mode 100644 index 00000000..1ed84b7f --- /dev/null +++ b/i2p2www/meetings/logs/124.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 11, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/125.log b/i2p2www/meetings/logs/125.log new file mode 100644 index 00000000..82dd0477 --- /dev/null +++ b/i2p2www/meetings/logs/125.log @@ -0,0 +1,278 @@ +13:04 < jrandom> 0) hi +13:04 < jrandom> 1) Net status +13:04 < jrandom> 2) 0.5 +13:04 < jrandom> 3) i2pmail.v2 +13:04 < jrandom> 4) azneti2p_0.2 +13:04 < jrandom> 5) ??? +13:04 < ant> <duck> (the sound of the crypto talk flying past my ears) +13:04 < jrandom> :) +13:04 * jrandom waves +13:04 < cervantes> 'lo +13:04 < jrandom> you too can listen to the sound of crypto talk flying past your ears! weekly status note posted @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html +13:05 < bla> hi +13:05 < jrandom> jumping on in, since we're cutting into an interesting discussion anyway... 1) net status +13:05 < jrandom> i dont really have anything to add beyond whats in the mail - anyone have anything they want to bring up wrt the net status? +13:06 < bla> Other that we have, for the first time, seen nodes on *all* continents except Antarctica, no. +13:06 < jrandom> w00t! +13:07 < jrandom> ok, moving on to 2) 0.5 stuff +13:07 < mule> hey, my father is just on his way to antarctica, should have given him a node +13:07 < ant> <duck> bloody Antarticans +13:07 < Xan> no antarcticans? :( +13:07 < jrandom> hah nice +13:07 < jrandom> though i dont think there's much of an anonymity set up there +13:07 < Frooze> blame antarctica +13:08 * cervantes sets up an oil rig in antartica so he can finance a node there +13:09 < jrandom> ok ok, there's a lot of 0.5 stuff, so we can take it in pieces +13:09 < jrandom> first up, thanks to the folks who gathered a days worth of stats - lots of interesting data @ http://dev.i2p.net/~jrandom/messageSizes/ +13:09 < postman> it was a pleasure :) +13:10 < cervantes> wrt net status...seen quite a few people having troubles getting I2P up and running lately (on the forums etc) - I don't know if that's just down to increase user volume or perhaps more i2p based apps for things to go wrong with +13:10 <+protokol> jrandom: LIAR! you said the data was interesting! +13:10 * jrandom flings mud at protokol +13:11 < ant> <duck> cervantes: I have also seen reports of ppl able to get it up and running within a couple of minutes +13:11 < ant> <duck> I think that NAT is causing most problems +13:11 < cervantes> duck: true... +13:11 < ant> <dmdm> who is NAT? +13:11 < jrandom> cervantes: there are some ugly issues still, certainly. the NAT issue and osx has been a bit of a pain lately, but Jhor's help with the later should improve the later +13:12 < cervantes> aye +13:12 < cervantes> *cough* so... 0.5 +13:13 < Xan> dmdm: network address translation +13:13 < jrandom> heh, ok. basically the drive with those message size stats is to explore the padding issues +13:14 < jrandom> unfortunately, the strategy i built by cherry picking numbers sucked, giving a 25% overhead just with padding data +13:14 < jrandom> if we go with one of the proposals for the 0.5 encryption (tunnels-alt.html), we won't have that issue +13:15 < jrandom> (since it'll force small fixes sizes with fragmentation) +13:15 < mule> what type of messages do you want to pad, those a router sees or those an external observer sees? +13:15 < jrandom> mule: important question +13:15 < jrandom> if we're just worried about the external observer, we can leave the messages unpadded, doing any chaff generation at the transport layer +13:16 < Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 +13:16 < jrandom> otoh, if we're worried about tunnel participants doing flow analysis, we need to worry about padding down the tunnel +13:16 <@duck> with 5-6 hops, how big is the danger of a router doing traffic analysis? +13:16 < cervantes> Teal`c: meeting atm... can you use #i2p-chat for mp3 announce ;-) +13:17 < Teal`c> sorry +13:17 < cervantes> :) for david hasselhoff? +13:18 < jrandom> depends upon what level of analysis duck. if they've somehow tracked down what tunnel they're in (e.g. they're the inbound tunnel gateway and have harvested the netDb, correlatign that with a destination), thats nontrivial data. otoh its not a direct exposure, but does give some info +13:18 < jrandom> even more than the tunnel padding though is end to end padding, hiding message flow data from gateways and endpoints. +13:19 < jrandom> if we're crazy/stupid, we could go all the way to a pipenet, using constant bitrate everywhere +13:19 <+polecat> I got it! +13:19 < jrandom> (and end up with no users running i2p) +13:19 <+polecat> What we need to do is tunnel i2p over email! +13:19 < cervantes> what's the likelyhood of colluding routers ending up in the same tunnel on a sufficiently large network? +13:19 <+polecat> No ISP would be dumb enough to stop email! +13:20 * jrandom awaits the net.i2p.router.transport.gmail implementation +13:20 < postman> polecat: gee , this is silly +13:20 < postman> :) +13:20 < bla> cervantes: N^(-h) (N is # of fast nodes, h = # hops). It seems +13:20 <+polecat> =3 I know. +13:21 < cervantes> is that a lot? :) +13:21 < jrandom> not the # of fast nodes, as external people won't know your profiles +13:21 <+polecat> Seriously though, in shameless abuse of existing IP services, we could tunnel i2p in any number of ingenious ways. +13:21 < jrandom> c^2/N^h to get two peers into the same tunnel +13:21 < jrandom> agreed polecat. thats one of the reasons why we don't have bidirectional tunnels +13:22 < jrandom> some transports (e.g. email) suck for bidirectional comm +13:22 < bla> jrandom: c = ? +13:22 < jrandom> c==# colluding peers +13:23 <+polecat> Hm, interesting point. +13:23 < ant> <duck> roadmap wise, what is the impact of i2p going a wrong direction and picking a wrong crypto solution? +13:23 <+polecat> Or carrier pigeon protocol, not bidi in the slightest. +13:23 <+polecat> crypto is modular already, isn't it? +13:23 < jrandom> duck: its just one bullet point out of 0.5, and one subsection of the tunnels*.html doc. theres lots more to the tunnel routing than just how we wrap the data +13:24 < bla> jrandom: Then again, this is the prob. for getting them in the tunnel *now*. However, over T tunnel refreshments (every so many minutes), this goes as P = 1 - (1 - c^2/N^h)^T +13:24 < jrandom> otoh, the difference between "fixed 1KB blocks" and "0-40KB blocks" has substantial impact +13:24 <+polecat> I'd hate to see this network go the way of Entropy, stuck in McEliece. +13:24 < jrandom> polecat: read http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD +13:24 < bla> jrandom: And thus tends to zero for large enough time. I.e.: for large enough time, the attackers will be in the same tunnel at last one time +13:25 < jrandom> the plan is standard AES256/CBC +13:25 <+protokol> i hear dns is good for tunneling stuff, most people dont block it +13:25 < jrandom> certainly bla, though its not quite that direct (for exploratory tunnels it is, but not for client tunnels) +13:26 <+polecat> And if somehow even AES gets cracked, some equivalent symmetric cipher. +13:27 < jrandom> bla: i dont think its large enough of a practical worry for most cases in that degree, but when you mount it as part of a predecessor attack, the issue is largely moot +13:28 < jrandom> (because of the way we do the rest of the tunnel routing) +13:28 < bla> jrandom: k +13:28 < jrandom> right polecat +13:29 < jrandom> duck: if we go w/ the second option, changing to another later will likely be easy. +13:29 < jrandom> otoh, the second option will require some hefty performance tuning to Not Suck +13:29 < jrandom> but i'm sure we can pull it off +13:31 < jrandom> anyway, I think the above covers where we are right now wrt 0.5 work +13:31 < jrandom> does anyone have any more questions/comments/concerns? +13:31 < bla> jrandom: One +13:32 < bla> jrandom: I think we should values anon. slightly more than performance atm: so yes, the PRNG options sounds good +13:33 < jrandom> agreed. performance can be tuned later, "adding in" better anonymity however, is much harder +13:33 < jrandom> (but, of course, performance /is/ a security parameter. if it Sucks, no one uses it) +13:33 < bla> Yes. +13:33 < bla> jrandom: +13:33 < bla> sorry +13:33 <@duck> right, /me flips the magical Freenet-performance bit +13:33 < cervantes> perhaps it'll deter all those torrent waving leechers to stay away a while longer ;-) +13:34 < jrandom> heh +13:34 < cervantes> <-- connection reset +13:34 < bla> cervantes: No, I'm not! :) +13:34 < cervantes> :) +13:35 < jrandom> i do think that we can pull off some really cool optimizations, and it seems a lot of our choke is not related to the peer selection, but merely (heh) bugs in the jobqueue +13:36 < jrandom> but, anyway, anything else for 2) 0.5? +13:36 < ant> <BS314159> could you post an explanation for this loop attack? +13:37 < ant> <BS314159> it sounds more dangerous than your treatment implies it is +13:37 < jrandom> loop: build a tunnel containing A-->B-->C-->D-->C, send in 10 messages. +13:37 < jrandom> without the PRNGs, you can add as many messages to that C<-->D loop as you want +13:38 < ant> <BS314159> ok +13:38 < jrandom> effectively DoSing any routers with just a few messages +13:38 < ant> <BS314159> but only A can do this +13:38 < jrandom> with the PRNGs, it limits the number of messages that can go into the loop +13:38 < ant> <BS314159> so there's no danger of an attacker shortening my tunnels by introducing loops +13:38 < jrandom> no, no one can shorten your tunnels +13:39 < jrandom> the only thing this is useful for is a DoS +13:39 < jrandom> (a very cheap DoS) +13:39 < jrandom> (but when you can selectively DoS peers without much cost, you can do naaaasty stuff) +13:40 < ant> <BS314159> comprendo +13:40 <+protokol> and hashcash certs will help this? +13:40 < jrandom> protokol: hashcash addresses the issue of a peer building too many tunnels, and perhaps building too many hops +13:41 < jrandom> protokol: it doesnt help with loops. the two ways i could find that /did/ were the PRNGs (tunnel-alt.html) or verifying at each step (tunnel.html) +13:42 < jrandom> verifying at each step has dangers, so the current leaning is towards the PRNGs +13:42 <+Ragnarok> how effective will the prng method be? +13:42 < Xan> A-->B-->C-->D-->C - shouldnt each hop get a different id or something, so that messages leave the tunnel the second time they reach C rather than looping? +13:43 < jrandom> Xan: they do, but without verifying each step, you can't tell whether its bad or not +13:44 < jrandom> Ragnarok: i think it'll be very effective at minimizing the damage done +13:45 < jrandom> at least, from what I can see so far +13:45 < jrandom> if anyone sees any problems/issues with it, or suggestions for improvement, please get in touch :) +13:46 < Xan> or maybe Im missing the point +13:46 < Xan> bbl +13:46 < jrandom> 'k l8r, i'll update the doc to be more clear +13:47 < jrandom> ok, unless there's something else, shall we move on to 3) i2pmail.v2? +13:47 < jrandom> postman: you 'round? +13:48 < postman> yes +13:49 < postman> :) +13:49 < jrandom> anything to add from your post on the forum? it sounds pretty cool +13:49 < postman> well, a few of you might have read the draft for i2pmail.v2 already +13:50 < bla> wtf is happening? Massive disconnects. I've got trouble reaching sites (say orion, library) here too +13:50 < postman> it aims towards a fully decentralized mail infrastructure in the future +13:50 < postman> but is in need of proxysoftware on the nodes as well as a bunch of dedicated relays +13:51 < postman> all are invited to contribute ideas / concepts / rants +13:51 < postman> development already has started - dont expect anything before late spring :) +13:51 < jrandom> w00t +13:51 < kaji> hmm, the cops just showed up at my door +13:52 < bla> kaji: ? +13:52 < jrandom> quick, blow your hard drive +13:52 < postman> jrandom: well, this is all i have to say for now :) +13:52 < cervantes> hide the blackjack table! +13:52 < jrandom> wikked, thanks postman +13:52 < kaji> they said i dialed 911, but im quite sure neither i nor my brother did +13:53 <+protokol> kaji: they're just checking up on i2p +13:53 < jrandom> ok, unless there's anytihng else on 3) i2pmail, lets move over to 4) azneti2p_0.2 +13:53 <+protokol> <creepy music> +13:53 < jrandom> as mentioned in the email, there's been some important progress lately +13:53 < kaji> then they said cordless phones can freak out when off the hook, but all my cordless phones are on their charger -> #i2p-chat +13:55 < jrandom> the azureus folks have been very responsive in getting an update ready (yay!), but people should also be on the lookout for problems +13:55 < jrandom> (if you don't read the i2p mailing list and use azneti2p, read the i2p mailing list) +13:55 < jrandom> ((or even if yuo dont use azneti2p, read the list, as thats where we announce important things ;) +13:56 < jrandom> duck and orion have also been making lots of updates to accomodate the new bt client and formatting +13:56 < jrandom> (yay!) +13:56 * orion smiles +13:57 < orion> theres still a ways to go, but for now, it works. +13:57 < jrandom> (inasmuch as i2p lets it ;) +13:58 < orion> hehe, yes. ;) +13:58 < jrandom> does anyone else have anything to bring up wrt azneti2p or i2p-bt? +13:58 < jrandom> (or bytemonsoon2p ;) +14:00 < jrandom> ok if not, moving right along to 5) ??? +14:00 < jrandom> open floor - anyone else have anything to bring up? +14:00 < postman> jrandom: why does the addressbook publich userhosts entries ? +14:01 < jrandom> postman: bug. +14:01 < postman> so this was no planned behaviour and will be changed? +14:01 < cervantes> just one thing... +14:01 < jrandom> postman: correct, and will be changed +14:02 < jrandom> (right Ragnarok? :) +14:02 <+Ragnarok> depends on exactly what postman means... +14:03 < jrandom> Ragnarok: new entries added by the local user to their own private hosts shouldn't be propogated to the hosts published +14:03 < jrandom> (e.g. userhosts.txt is private, hosts.txt is synchronized with other people and is public) +14:03 < cervantes> As part of a semi regular slot on the forum, there will be recognition and awards for those that have contributed good things to I2P either recently or over the project's lifetime +14:03 < postman> Ragnarok: after updating to 0.4.2.6 i found entries from my userhosts.txt in the published addressbook in my eepsite folder +14:03 < ant> <BS314159> hmm +14:04 < postman> Ragnarok: those have been manually added keys, which haven't been supposed to be published +14:04 < cervantes> this week we recognise duck for general excellence as a service provider for the community and as an all round great idler: http://forum.i2p/viewtopic.php?t=275 +14:04 < jrandom> w00t! +14:04 < jrandom> (go duck go, go duck go) +14:05 < Teal`c> what about domain name hijacking ? +14:05 * brachtus applauds +14:05 * orion does a duck waddle as a sign of respect. +14:05 < cervantes> one important point for the future...you don't have to be a cryptographic genius to get praise! +14:06 <+Ragnarok> no, that's expected behaviour. I can change it, but first I'll have to finish implementing file locking so you can change hosts.txt directly +14:06 < orion> (but it helps) +14:06 < cervantes> you might just have contributed a cracking eepsite or something... +14:06 < cervantes> or been a helpful bod on the forum etc +14:07 < ant> <BS314159> hmm +14:07 < cervantes> (otherwise, lets face it, jrandom would win every week) +14:07 < jrandom> hey, y'all are paying for my beer fund, this stuff aint free ;) +14:07 < ant> <BS314159> could you just make a new file, "publichosts.txt"? +14:07 < ant> <BS314159> then have addressbook ignore userhosts.txt, but allowed users to subscribe to their own publichosts.txt? +14:08 < jrandom> Teal`c: there is no way to hijack a domain name, no entries are overwritten, and userhosts always overrides hosts +14:09 < jrandom> Ragnarok: perhaps the web interface can address the locking issue, since users won't be adding to the files manually +14:09 <+Ragnarok> once the locking is done, there's no real reason to pull in addresses from userhosts.txt anymore (it's currently the only way to dodge a race), so there's no real point in adding a third file +14:10 <+Ragnarok> jrandom: well, I was planning on using the java file locking api +14:10 < jrandom> if you think its necessary, you're the boss :) +14:10 < ant> <BS314159> it would allow you to kill all the names gotten from other people while keeping the ones you made yourself +14:10 < ant> <BS314159> simply by clearing hosts.txt and changing your subscriptiong +14:11 < ant> <BS314159> but I guess that can wait for name-signing +14:11 < orion> metadata will solve this problem. Is a spec drafted yet? +14:11 < jrandom> using just two files should be fine - one managed by the addressbook, one not +14:12 < jrandom> (you could even have the addressbook ignore userhosts.txt entirely - userhosts.txt overrides hosts.txt anyway) +14:12 <+Ragnarok> jrandom: that would be the plan, once locking is done (which really shouldn't be too much work, I just haven't gotten around to it :) +14:13 <+Ragnarok> and I'm currently working on learning enough xml schema to write one for the namerecords +14:13 < ant> <dr_kavra> is this the channel for kenosis? another channel told me to come here :D +14:13 < jrandom> lol +14:13 < jrandom> nah, sorry, this is i2p +14:14 < jrandom> (unless you're looking for an anonymous comm layer) +14:14 < jrandom> wikked Ragnarok +14:14 < ant> <BS314159> I still the XML is too verbose and non-human-readable for this, compared to YAML, but I'm not the one writing the code +14:14 < jrandom> Ragnarok: the tough part will be doing the crypto w/ XML without reverting to ugly CDATA +14:14 < orion> anybody write a working draft for the metadata spec yet? +14:15 < jrandom> (i personally think xml sucks, but i'm just a naysayer) +14:15 < jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html has a basic setup +14:15 < orion> (name/key metadata) +14:15 < dox> has the addressbook and its features been announced somewhere? I didn't know my hosts.txt is published +14:15 < jrandom> (see NameReference and LocalEntry elements) +14:16 < jrandom> dox: its written to the location specified in addressbook/config.txt +14:16 < jrandom> (by default, ./eepsite/docroot/hosts.txt) +14:17 < orion> is missing a public/private (i.e. distribute, don't) flag. +14:17 < ant> <cervantes> the only good thing about XML (and this is a large + point) is that it's a widely accepted standard +14:17 < jrandom> right orion, lots of good ideas have come up since that post +14:17 <+Ragnarok> xml may suck, but frankly, it better than any of the alternatives for what I'm doing +14:17 < jrandom> cervantes: so is EDI +14:17 < orion> is there a place to condense them? i.e. forum area? +14:18 < orion> or maybe a wiki page? +14:18 < jrandom> orion: susi's or ugha's wiki +14:18 < orion> I'm going to set up wikis for bytemonsoon and orion.i2p to help get some community consensus as to the future development goals of each. +14:18 < BrockSamson> xml + crypto w/o CDATA = mime, no? +14:19 < jrandom> wikked orion +14:19 < jrandom> BrockSamson: smime, with different parsers ;) +14:19 < orion> (also one for name metadata) +14:21 < jrandom> there are lots of ways to do the metadata, the important thing is flexibility and 'correctness' so that it can grow or change over time +14:21 * jrandom is sure Ragnarok et al will come up with some good stuff :) +14:21 < orion> thats why I think a public draft is in order. +14:22 < ant> <cervantes> i2p consortium :P +14:22 < jrandom> well, people have been saying "someone should put up their ideas on the wiki" for the last few meetings, but the wiki pages aren't growing too much ;) which is fine, we take the pace we take +14:23 * orion promises to have three wikis up within a day and email everyone their locations +14:23 < BrockSamson> call me lazy, but compare an ANSI 850 Purchase order EDI to nearly any other XML based purchase order, and i'd rather decode, code, and debug for the XML version. Even if it's 5x the EDI size +14:23 < jrandom> w00t +14:23 < jrandom> heh BrockSamson +14:24 < BrockSamson> Position 10 is ST? oh then position 310 should be name +14:24 < BrockSamson> duh me +14:24 < jrandom> BrockSamson: don't think the xml schemas for POs are much better ;) +14:24 < jrandom> (but yeah, that stuff is just a totally bloody disaster) +14:25 < BrockSamson> they are at 4:30 in the morning +14:25 < BrockSamson> unless... +14:25 < jrandom> heh +14:25 < BrockSamson> it's written by an ex EDI programmer +14:25 < BrockSamson> and the xml looks like this: <p1><po><q>1</q></po></p1> +14:26 < BrockSamson> i bet though, if you add up the horuse OpenSource projects spend talking about to 'XML' or not 'XML' you could code linux 10x over. +14:26 < BrockSamson> every project i've ever been part of has had massive debates on it +14:27 < orion> debates are good for a project, depending on who's debating. ;) +14:27 < jrandom> eh, it does what it does, but its not a panacea. it may work well for the naming stuff +14:28 < BrockSamson> many people are in projects just to debate though. +14:28 < jrandom> not here. i'm here for the free beer +14:28 < ant> <cervantes> that's debatable +14:28 < orion> the implementation details will be clearer when the draft spec is more tangable. +14:28 < orion> hence the need for a wiki/peer review. +14:29 < BrockSamson> I heard this project gave away free Garlic +14:29 < jrandom> lots of it +14:30 < jrandom> ok, anyone else have anything to bring up for the meeting? +14:30 < ant> * cervantes wheels out the ceremonial call with bell +14:30 < ant> <cervantes> call =cow +14:30 * jrandom winds up +14:31 * jrandom *baf*s the cowbell, closing the meeting diff --git a/i2p2www/meetings/logs/125.rst b/i2p2www/meetings/logs/125.rst new file mode 100644 index 00000000..cd4186be --- /dev/null +++ b/i2p2www/meetings/logs/125.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 18, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/126.log b/i2p2www/meetings/logs/126.log new file mode 100644 index 00000000..aed9b818 --- /dev/null +++ b/i2p2www/meetings/logs/126.log @@ -0,0 +1,172 @@ +13:50 < jrandom> 0) hi +13:50 < jrandom> 1) 0.5 status +13:50 < jrandom> 2) sam.net +13:50 < jrandom> 3) gcj progress +13:50 < jrandom> 4) udp +13:50 < jrandom> 5) ??? +13:50 < jrandom> 0) hi +13:50 * jrandom waves belatedly +13:51 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000560.html +13:51 <+postman> hi +13:51 * brachtus waves back +13:52 * cervantes waves a detention slip for tardiness +13:52 < jrandom> yeah yeah, blame the code for sucking me in +13:52 < jrandom> ok, jumping into 1) 0.5 status +13:53 < jrandom> lots of progress since last week - all the messy problems we had with the new crypto are resolved without much trouble +13:54 < jrandom> the latest http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD is very likely to be what we deploy in 0.5 and beyond, unless/until people find any problems with it +13:55 < jrandom> not sure if i have anything else to add beyond whats in the email +13:55 < jrandom> anyone have any questions/concerns? +13:56 < Ragnarok> what's performance going to be like? +13:56 < jrandom2p> (not me) +13:56 < jrandom> Ragnarok: tunnel performance should be much better +13:56 < frosk> any significant overhead compared to what we have today? +13:57 < jrandom> frosk: sometimes +13:57 < jrandom> frosk: when we can coallesce messages in a tunnel, the overhead will be minimal +13:58 < jrandom> however, when we cannot coallesce or when its not effective, there can be nontrivial waste +13:58 < frosk> i see +13:59 < jrandom> otoh, we're trimming some of the absurdities of our current i2np (where we currently prepend a 32 byte SHA256 before each I2NP message, even ones within garlic messages, etc) +13:59 < jrandom> the fragmentation and fixed size will be an issue we need to tune with, but there is lots of room to do so +14:01 < jrandom> ok, anytihng else on 0.5? +14:02 < jrandom> if not, moving on to 2) sam.net +14:02 < jrandom> smeghead has ported the java sam client lib to .net (yay!) +14:02 < jrandom> smeghead: wanna give us the rundown? +14:03 < smeghead> sure +14:03 < smeghead> i'm writing tests for it, should have those in cvs in the next couple of days +14:04 < smeghead> should work with .net/mono/portable.net +14:04 < smeghead> and c# and vb.net +14:05 < frosk> (and all of the other languages that works with .net i suppose) +14:05 < cervantes> (urgh) +14:05 < smeghead> the interface is dirt simple +14:05 < smeghead> just register listener methods with SamReader, or subclass SamBaseEventHandler and override methods as necessary +14:05 < smeghead> yes, i aim to make it fully CLR compatible +14:06 < jrandom> wikked +14:06 < cervantes> cool... smeg.net ;-) +14:06 < frosk> goodie +14:06 < smeghead> really not much else to it +14:06 <+protokol> CLR? +14:06 < smeghead> common language runtime +14:06 < smeghead> the .net equivalent of the JRE +14:07 <+protokol> JRE? +14:07 <+protokol> just kidding +14:07 < jrandom> !thwap protokol +14:07 < Ragnarok> jrandom: how's the sam bridge holding up these days? were all the bt related issues resolved? +14:08 < Tracker> I doubt it, i2p-bt can even drive my amd64 3000 mad, cpu-wise... +14:08 < jrandom> Ragnarok: i havent touched it lately. there's still the outstanding choke issue that polecat came up with, but where the i2p-bt<-->sam bridge is getting off, i'm not sure +14:09 < jrandom> hmm, failed connections will force full ElGamal instead of AES +14:10 < Ragnarok> ok +14:10 < jrandom> we should be able to reduce some of that after 0.5, but only partially +14:12 < Tracker> Ok, the I2P will be good for anonymus trackers but not for anonymus clients. Just try to think what happens on a really popular torrent with some 1000 seeds and leechs. +14:12 < jrandom> ok, the sam.net stuff sounds cool, thanks again smeghead. i'm looking forward to the unit tests and perhaps a demo app :) +14:12 < ant> <Evil-Brotten> hello everbody +14:12 < smeghead> a demo app, yes i'll do that too +14:13 < smeghead> i've ported yours in fact +14:13 < jrandom> Tracker: i2p can handle anonymous clients just fine, we just need to figure out whats wrong with the i2p-bt<-->sam bridge to reduce the full ElG's +14:13 < smeghead> they're just bug-ridden atm +14:13 < ant> <Evil-Brotten> deer? +14:13 < jrandom> hi Evil-Brotten +14:13 < ant> <Evil-Brotten> hello +14:14 < jrandom> weekly dev meeting going on, feel free to stick around. deer is a gateway to i2p/iip +14:14 < ant> <Evil-Brotten> are you an i2p expert? +14:14 < ant> <Evil-Brotten> :P +14:14 < ant> <Evil-Brotten> ow, ok +14:14 < ant> <cervantes> Evil-Brotten: you can talk in #i2p-chat if you like while the meeting is ongoing +14:14 < jrandom> Tracker: we've got a lot to do before handling 1k-wide torrents +14:14 < ant> <Evil-Brotten> i was just trying to install your program, but i am having some problems +14:14 < ant> <Evil-Brotten> cool, i will ask there +14:15 < jrandom> wikked smeghead +14:15 < Tracker> jrandom: I hope so, non-anonymus bt won't survive much longer... +14:15 < frosk> nonsense +14:15 < jrandom> "but exeem is anonymous!@#" </snark> +14:15 < Tracker> jrandom: But that's a different story +14:15 < ant> <MikeW> what? +14:15 < ant> <MikeW> who said exeem is anonymous? +14:16 < jrandom> mikew: just the occational fanboy +14:16 < jrandom> Tracker: after 0.5 we're going to have a lot of work to do getting performance where we need it to be +14:16 * DrWoo notes that 'people' are fucking morons (sometimes) +14:16 < Tracker> jrandom: Yeah, installing spy-/adware isn't really what I would do ;) +14:16 < jrandom> heh +14:17 < smeghead> i happen to like people +14:17 < smeghead> they're good on toast +14:17 < jrandom> *chomp* +14:17 < smeghead> some need a little more butter than others +14:18 < jrandom> ok, i think thats 'bout it for 2) sam.net (unless anyone has something else to add?) +14:18 < jrandom> if not, moving on to 3) gcj progress +14:19 < ant> <dm> sam.net?? +14:19 < ant> <dm> is it working?/ +14:19 < jrandom> i've read in my backlog that smeghead has been making some good headway - wanna give us an update on how its going? +14:19 < smeghead> yes +14:20 < ant> <dm> cooooooool +14:20 < smeghead> i modified a few classes so the router compiles with gcj 3.4.3 +14:20 < smeghead> i will submit the patch after the meeting +14:20 < smeghead> after that i and anyone who would like to help can get to work on making it run +14:21 < jrandom> nice +14:21 * frosk decorates smeghead with the Employee of the Week medal for sam.net _and_ gcj work +14:21 < jrandom> aye, v.cool +14:21 < smeghead> :) +14:22 < Tracker> frosk: better forum user of the week ;) +14:22 < frosk> i haven't read the forum this week, sorry :) +14:22 < cervantes> duck's glory has not yet expired ;-) +14:23 * jrandom is very much looking forward to seeing i2p gcj compatible +14:24 < jrandom> (and there's still that bounty on it, so people should get in touch with smeghead and get involved ;) +14:24 < smeghead> yes it would expand i2p's portability significantly +14:24 < cervantes> maybe we'll be able to squeeze something that resembles performance from the router :P +14:24 < ant> <dm> my 32-week run as hardest I2P worker ends at last... +14:25 < jrandom> i dont expect gcj to actually improve performance or reduce the memory footprint, but it'll work on OSes that sun doesn't release JVMs for and kaffe is b0rked on +14:25 < jrandom> (but if i'm wrong, cool!) +14:25 < frosk> anything that can make i2p run better without proprietary software is Good +14:26 < jrandom> agreed. supporting both kaffe and gcj would be a Good Thing +14:27 < jrandom> ok, anything else on 3) gcj progress, or shall we move on? +14:27 < smeghead> installation would be easier too +14:27 < Teal`c> has gcj worked for anything besides 'hello world' examples ? +14:27 < Ragnarok> someone built eclipse with it +14:27 < smeghead> Teal`c: yes, i've used it for .exe's under mingw before in fact +14:27 < smeghead> yes, eclipse was running under gcj with red hat not to long ago +14:28 < jrandom> having the option of distributing gcj'ed executables, plain .jar installers, and bundled .jar+jvm will definitely be Good +14:29 < jrandom> ok, moving on to 4) udp +14:30 < jrandom> there was a recent post to the forum that i just wanted to draw people's attention to, asking (and answering) why udp is important +14:30 < Tracker> Yuck +14:30 < jrandom> (see http://forum.i2p.net/viewtopic.php?t=280 and comment if you have any suggestions/questions/concenrs) +14:31 < jrandom> yuck Tracker? +14:32 < jrandom> anyway, both mule and detonate are making some headway on the udp side. detonate/mule: y'all have any updates to share? +14:32 < Tracker> UPD is evil here, while it works well within the country borders it really get's ugly when trying to use it on destinations outside our countrys. +14:32 < jrandom> hmm +14:32 < Tracker> Just my experience from 5 years online gaming... +14:33 < jrandom> we'll certainly need to take into account the congestion and mtu issues as they go out on the net +14:33 < Tracker> Somehow the two big backbones here don't like to router UPD very well and if only with very low priority. +14:34 < Tracker> Meaning pings between 5 and 20 seconds. +14:34 < jrandom> i'd be pretty suprised if there was an isp that didn't allow UDP at all (since we all use DNS) +14:34 < Tracker> And high packet loss +14:34 < jrandom> congestion control is certainly important +14:35 < Tracker> Why do you think I'm running my own caching dns with a very big cache for years ;) +14:35 < jrandom> heh +14:35 < jrandom> well, we will have the fallback of tcp for people who cannot use udp for some reason +14:36 < jrandom> but udp will be overwhelmingly preferred +14:36 < Tracker> That's nice. +14:36 < jrandom> (meaning i hope there will only be perhaps 10 people using tcp out of 1m+ nodes ;) +14:37 < jrandom> but, again, that forum link explains why we need to do what we're doing, though if anyone can find a better way, i'm all ears +14:37 < Tracker> I guess I will be one of them. +14:37 < jrandom> perhaps. +14:38 < jrandom> we'll see as 0.6 is deployed whether thats the case, or whether we'll be able to work around the issues your isp has +14:38 < jrandom> ok, anything else on udp? or shall we move on to 5) ??? +14:39 < jrandom> consider us moved +14:39 < jrandom> 5) ?? +14:39 < jrandom> anyone have anything else to bring up? +14:40 < Teal`c> is the pizza here yet ? +14:40 < Jhor> anybody know where i should look to find/debug problems in bittorrent? +14:41 < jrandom> Jhor: in i2p-bt, a good place to start would likely be adding in some logging to tell you what BT messages are sent/received, so we know where its blocking/timing out/etc +14:41 < jrandom> (assuming you mean i2p-bt and not azneti2p?) +14:42 < Jhor> yeah, i2p-bt. what are the different spew levels? +14:42 < jrandom> no idea, all i know is --spew 1 +14:42 < Jhor> Ok, I'll try that +14:43 * Jhor prepares for a crash course in python +14:43 < jrandom> :) +14:44 < jrandom> ok, anybody else have something to discuss? +14:44 * cervantes wheels out the Strand Gong +14:44 < jrandom> we're around the 60m mark, so a pretty good rate +14:44 < Teal`c> when is udp due for general consumption ? +14:44 < jrandom> Teal`c: april +14:44 < jrandom> thats 0.6, we're still working on 0.5 +14:45 < Teal`c> nice work. +14:46 < jrandom> progress, ever onwards +14:46 * jrandom winds up +14:46 * jrandom *baf*s the gong, closing the meeting diff --git a/i2p2www/meetings/logs/126.rst b/i2p2www/meetings/logs/126.rst new file mode 100644 index 00000000..154f8535 --- /dev/null +++ b/i2p2www/meetings/logs/126.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 25, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/127.log b/i2p2www/meetings/logs/127.log new file mode 100644 index 00000000..124613f1 --- /dev/null +++ b/i2p2www/meetings/logs/127.log @@ -0,0 +1,153 @@ +13:06 < jrandom> 0) hi +13:06 < jrandom> 1) 0.5 status +13:06 < jrandom> 2) nntp +13:06 < jrandom> 3) tech proposals +13:06 < jrandom> 4) ??? +13:06 < jrandom> 0) hi +13:06 * jrandom waves +13:06 <+postman> hi jr +13:07 * postman waves +13:07 < jrandom> w3wt there is life out there :) +13:07 < jrandom> weekly status notes posted up @ http://i2p.net/pipermail/i2p/2005-February/000561.html +13:07 < ant> * dm waves +13:08 < jrandom> while y'all read that email, we can jump into 1) 0.5 status +13:08 < MANCOM> hi +13:09 < jrandom> lots of progress over the last week, all the new crypto is in and tested, and now all of the router's tunnel operation is done through the new tunnel pools +13:10 < jrandom> there are still some parts of the router i chopped out while doing the update, such as the tie in to request leases from clients or periodically test the tunnels, but those shouldn't be too difficult +13:11 < jrandom> the code is not compatible with the live net, and is on a separate branch in cvs, so people can still pull cvs HEAD and work with the latest +13:12 <+polecat> Dook I finally looked at that page, and I still don't understand how we can avoid mixmaster style redundancy to protect from tunnel detection attacks. +13:12 <+protokol> yey +13:12 <+polecat> I imagine it works very well though. :) +13:12 <+protokol> are you throwing in any other cool compatibility-breaking stuff? +13:13 <+protokol> the tunnel pool has to do with treads, right? +13:13 < jrandom> polecat: we don't verify at every hop, but we have a fixed message size to prevent useful tagging (and everything is encrypted at each hop) +13:14 < jrandom> protokol: i'm considering http://www.i2p/todo#sessionTag +13:14 <+polecat> So how to prevent multiple hops passing around bogus messages, and causing a DoS? +13:15 < jrandom> but no, the pools aren't the threading issue, the pools just let us safely manage the tunnels so that we don't get those "Lease expired" messages and can configure the length on a per-client basis +13:15 < jrandom> polecat: they'll fail at the endpoint, and the creator will detect the failure and move off it +13:16 <+protokol> jrandom: aside from any difficulty, i think any anon-improving features should go in ASAP +13:16 <+polecat> w00t! Synchronized PRNG! First application I've ever seen of that idea! +13:17 < ant> <dm> what does PRNG stand for? +13:17 < ant> <dm> if I may ask :) +13:18 < jrandom> protokol: agreed, thats what 0.5 is for :) there aren't any other i2p-layer low hanging fruit, but there's always improvements that can be made at the app and lib layers (e.g. i2ptunnel filtering, etc) +13:18 < jrandom> dm: PseudoRandom Number Generator +13:18 < ant> <dm> cool, thanks +13:20 <+protokol> so youre saying that after this, its mostly speed and reliability tweaking? +13:21 <+protokol> and why has IRC been sucking lately +13:21 < jrandom> protokol: prior to 2.0 for the core and router, yes +13:21 <+protokol> i cant seem to connect to ducks server +13:21 <+protokol> yey +13:21 * jrandom doesnt know, we've seen perhaps 5 bulk disconnects in the last day or so, perhaps something on the server side +13:22 < jrandom> there's lots to be tweaked though, especially in the streaming lib after 0.5 is deployed +13:23 <+polecat> That whole UDP thing. +13:24 < jrandom> ah, the streaming lib shouldn't need changes for the 0.6 release, beyond the ones we do for the 0.5 rev +13:25 < jrandom> ok, thats all i have to bring up wrt 0.5 status - anyone have anything else on it? +13:27 < jrandom> if not, moving on to 2) nntp +13:27 < jrandom> nntp.fr.i2p is up, check it out :) +13:28 < jrandom> it doesnt seem like LonelyGuy is around, but he can be reached at http://fr.i2p/. there are also configuration instructions for slrn on my blog, and jdot found that thunderbird can be fairly safe (though i dont know what config jdot used) +13:30 < smeghead> LonelyGuy? :) +13:30 < cervantes> did someone also test Pan? +13:30 < jrandom> hes been on here occationally +13:30 <+polecat> I wouldn't waste too much time on nntp, but as long as it has user managed access control it's fine. +13:30 < jrandom> (lonelyguy, not pan ;) +13:30 < smeghead> i thought his name was LazyGuy +13:31 < jrandom> is it LazyGuy? +13:31 < jrandom> i know we've had both... +13:31 < jrandom> you're right, lazyguy +13:31 * jrandom !stabs self +13:31 < jrandom> cervantes: i think LazyGuy tried it out, i dont know the config or result though +13:32 < cervantes> I thought it was LimeyGuy? +13:33 * jrandom awaits SnarkeyGuy's comments +13:33 < smeghead> he's French +13:35 < jrandom> ok, i dont have anything more to add beyond that, so unless anyone has any questions, moving on to 3) tech proposals +13:35 < cervantes> smeghead: you're thinking of ParesseuxGuy +13:36 < jrandom> orion has put together some good descriptions and ideas for a few of the messier issues up at 1) 0.5 status +13:36 < jrandom> 2) nntp +13:36 < jrandom> 3) tech proposals +13:36 < jrandom> erg +13:36 < jrandom> damn ^C^V +13:36 < jrandom> up at http://ugha.i2p/I2pRfc that is +13:37 < jrandom> so next time you want to discuss how you've got a killer naming idea, go to http://ugha.i2p/I2pRfc/I2pRfc0001ResourceNameMetadata +13:39 < jrandom> i dont really have much more to add beyond that. its a wiki, get wikiing :) +13:39 <+polecat> Yay. +13:39 <+postman> jrandom: ohh, cool i think i need to add a few ... +13:40 < jrandom> cool postman, thought you would :) there's a template up there for new ones +13:41 <+postman> jrandom: gimme a lil time (first things first) but i will contribute :) +13:41 < jrandom> w3rd +13:41 <+polecat> ResourceNameMetadata, forming it is relatively trivial. The trick is figuring out how to /get/ it from other people. +13:42 < jrandom> polecat: as postman said, first things first. +13:42 <+polecat> But if I had a solution, I'd be wikiing now wouldn't I. :) +13:42 < jrandom> heh +13:42 < jrandom> discussion of the tradeoffs of /how/ to distribute prior to deciding /what/ to distribute is premature +13:43 < jrandom> there's room for lots of 'em though, so anyone should feel free to post up ideas that aren't fully worked through yet even (though fully functional ones with implementations would be cool too ;) +13:44 < jrandom> ok, unless there's something else on that, perhaps we can swing on to good ol' 4) ??? +13:44 < jrandom> anyone have anything else to bring up? +13:45 < jrandom> smeghead: is there anything people can do to help out work through the gcj issues, or is it stalled on their prng? +13:46 <+polecat> What to distribute is just a signed dict. Simple as that. +13:46 <+polecat> Yeah probably a good idea. +13:46 <+polecat> I'm STILL working on the skeleton for my i2p bt client, though would very much appreciate advice at any stage. +13:46 < smeghead> i think i've found a solution +13:46 < smeghead> in gnu crypto, there's a fortuna impl. since last summer +13:46 < jrandom> nice polecat +13:46 < jrandom> oh cool smeghead +13:46 <+polecat> smeghead: Hee, the $150 is as good as yours. +13:47 < smeghead> i can whip up a gnu-crypto.jar that contains only the classes needed for Fortuna +13:47 <+polecat> My working notes so far are at http://polecat.i2p/bittorrent.plan.doc +13:47 < smeghead> if we shipped the whole gnu-crypto.jar it's about 500 KB, too big really +13:47 <+polecat> Don't let the .doc scare you, it's in text/plain. +13:48 <+polecat> Fortuna doesn't use SecureRandom to do random things? +13:48 < jrandom> yowza, yeah 500KB is a bit excessive, but glancing at http://www.gnu.org/software/gnu-crypto/, it looks like something we could integrate safely (as we'd only be linking to it, not modifying) +13:48 < smeghead> SecureRandom was never the problem +13:48 < jrandom> polecat: fortuna /feeds/ secureRandom :) +13:49 < smeghead> jrandom: it would be easy to make a custom .jar, probably around 50KB +13:49 < smeghead> (rough estimate mind you) +13:49 < smeghead> i could make an ant build to custom package it on demand even +13:50 < jrandom> smeghead: wanna dig 'er into i2p/apps/fortuna/ ? +13:50 < smeghead> will do +13:50 < jrandom> kickass! +13:51 < smeghead> after that, assuming gcj will finally be spitting out random numbers, there will probably be more testing of various i2p functionality +13:51 <+polecat> What's the license? +13:51 < jrandom> we can then work some voodo in net.i2p.util.RandomSource to either use SecureRandom or fortuna (if its found, etc) +13:51 < smeghead> lgpl +13:51 <+polecat> Cool. +13:51 < smeghead> true, SecureRandom would be unnecessary +13:52 < jrandom> yeah, there's still lots to do to get it gcjing, but its a great start +13:52 < jrandom> in the profiles i've done on the live net, reseeding the PRNG takes a good portion of the cpu load +13:52 < smeghead> if anyone is into writing tests +13:52 < smeghead> but i probably don't have to finish that sentence +13:52 < jrandom> hehe +13:53 < smeghead> i will ask the gnu crypto maintainer about this impl., because i googled for info on it and searched their mailing list archives and there's not a peep on it +13:54 < smeghead> and their cvs commit logs aren't too enlightening either +13:54 < jrandom> 'k good idea +13:54 < smeghead> i hope it works +13:54 < smeghead> it's in kaffe cvs btw +13:54 < smeghead> your version should have it even +13:55 < jrandom> hmm, ah, yeah from the gnu-crypto import +13:55 < smeghead> gnu.security.prng.Fortuna +13:55 < jrandom> the 'kaffe' provider still uses their old sha1prng iirc +13:55 < jrandom> cool +13:56 < MANCOM> what is the status of the .net sam stuff? should one start getting into it or are major changes to be expected? +13:56 < smeghead> MANCOM: it needs testing, i'll be writing some unit tests for it soon +13:56 < smeghead> this gcj thing has kinda put that on hold +13:57 < smeghead> MANCOM: i don't expect there'll be any changes to the API at all, so it should be safe to code against +13:58 < smeghead> changes behind the API are likely, but you as a client don't need to know that :) +13:59 < MANCOM> :) +13:59 < jrandom> there may be some later updates that are relevent if you build apps that do large bulk transfer +14:00 < jrandom> but if you're just transferring a 10s of KB at a time, it should be fine +14:00 < smeghead> ok if the Java client's API changes, then the sam-sharp's will too :) +14:01 < MANCOM> i can't argue against that +14:02 < jrandom> ok, does anyone have anytihng else to bring up for the meeting? +14:02 * cervantes lowers big ben into the channel +14:03 <+DrWoo> note: nice work jrandom +14:03 < smeghead> nice pun cervantes +14:03 * jrandom groans +14:04 < MANCOM> i read that you don't want to advertise i2p too much before v0.5, is that true? +14:04 < jrandom> MANCOM: before 0.6. yes +14:04 < jrandom> MANCOM: 0.5 will improve anonymity and help users control their performance better. 0.6 will let thousands+ concurrent users operate safely +14:04 < MANCOM> ah. 0.6. ok. +14:05 < jrandom> gracias doc, lots of progress :) +14:05 <+polecat> Whee, here's looking forward to 0.6... +14:05 <+DrWoo> :) +14:06 < jrandom> agreed polecat, agreed :) +14:06 * jrandom winds up +14:06 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/127.rst b/i2p2www/meetings/logs/127.rst new file mode 100644 index 00000000..ba50905f --- /dev/null +++ b/i2p2www/meetings/logs/127.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 1, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/128.log b/i2p2www/meetings/logs/128.log new file mode 100644 index 00000000..9493fd50 --- /dev/null +++ b/i2p2www/meetings/logs/128.log @@ -0,0 +1,285 @@ +13:05 < jrandom> 0) hi +13:05 < jrandom> 1) 0.4.2.6-* +13:05 < jrandom> 2) 0.5 +13:05 < jrandom> 3) i2p-bt 0.1.6 +13:05 < jrandom> 4) fortuna +13:05 < jrandom> 5) ??? +13:06 < jrandom> 0) hi +13:06 * jrandom waves +13:06 <@duck> y0 +13:06 < smeghead> hi +13:06 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000564.html +13:07 < cervantes> sorry I'm late...I was busy reading the status notes that were posted at the last minute... +13:07 < jrandom> hey, this week they were /before/ the meeting at least (by 30s or so ;) +13:08 < jrandom> anyway, while you dig through that oh so exciting email, lets jump on into 1) 0.4.2.6-* +13:09 < jrandom> with the latest patches from anon et al, i'm torn between pushing out a new 0.4.2.7 so close to the 0.5 rev. +13:10 < jrandom> for the moment though, if you're feeling brave, feel free to give cvs a whirl - its stable (i'm breaking things off on another branch), and has some good stuff +13:11 < jrandom> the deciding factor for not pushing a rev out was when i did a checklist for 0.5 and found that the only things left were really web interface updates +13:11 <+Ragnarok> about the patches from sugadude, they do represent a policy change, as we discussed filtering out non .i2p addresses before, and you decided against it +13:11 < jrandom> oh, hrm? i disagree with my old self then - eepproxy doesn't accept non-.i2p address in any case, even if they were in hosts.txt +13:12 < jrandom> did i have a convincing argument before? +13:13 <+Ragnarok> ok, then can we revert the patch, and I can implement it the way it originally worked, which is a 0 line change? +13:13 <+Ragnarok> not really, I just didn't care either way :) +13:13 < jrandom> oh, cool you're the boss +13:13 < cervantes> well you convinced me to drop all my work on a multi-tld management system and fire all my employees +13:13 <+Ragnarok> filtering is already happening, so it's just adding a condition to an if statement +13:14 < jrandom> cervantes: there's also this beautiful bridge i've got for sale... +13:14 < cervantes> :) +13:14 < jrandom> ok word Ragnarok, if you want to send me a .java/.tar/.diff/.whatever, that'd be great +13:15 <+Ragnarok> I can do cvs now :) +13:15 < jrandom> :) even better +13:15 * cervantes backs up cvs head +13:15 < jrandom> heh +13:16 <+Ragnarok> *BOOM* +13:16 <+Ragnarok> ... just kidding :) +13:17 < jrandom> ok, other than that, anyone have anything else to bring up wrt 0.4.*? +13:17 < ant> <dm>gt; 0.4.* sucks, give us 0.5 +13:17 < ant> <dm>gt; It's like a gazillion years old!! +13:18 < ant> <fvw>gt; 0.4.* doesn't suck, give us 0.5 anyway. +13:18 < jrandom> 2) 0.5 it is then :) +13:19 < ant> <dm>gt; you guys owe me big time, I brought 0.5 +13:19 < jrandom> we couldn't'a done it without ya dm +13:19 < ant> <dm>gt; amen +13:20 < jrandom> as mentioned in the notes, pretty much all the heavy lifting for 0.5 is done and tested, but there are still the odds and ends left to fix up +13:21 < jrandom> (e.g. the next task on my list is a tunnel config page to manage the pools and settings) +13:22 <@duck> I hope we will have a test-0.5 network before releasing? +13:22 < jrandom> there have been updates to lots of different components though, so 0.5 might be a bit bumpy +13:22 < ant> <dm>gt; jrandom HAS a test network already.. duh +13:23 < jrandom> aye, i've been doing one locally here with a dozen routers, but in the next day or two i'll try to snag some people to help with some wide area tests +13:24 * postman can offer a dedicated machine +13:24 < jrandom> wikked. perhaps we can try something out tomorrow, try to break some things. +13:26 < cervantes> as can I +13:27 < jrandom> word +13:27 < jrandom> thats about all i have to say about the upcoming 0.5 at the moment - the cvs commit logs have been pretty verbose, so if you want the nitty gritty, hit 'em up +13:28 < jrandom> anyone else have any comments/questions/concerns/frisbees wrt 0.5? +13:29 <+postman> no +13:29 * postman is looking forward to get the new V8 running :) +13:30 < jrandom2p> well, 0.5 is more of a new tank - designed to improve security and anonymity, not as a performance tweak ;) +13:30 < jrandom2p> but i agree, its been too long +13:30 <@duck> dont forget to add a 0.5 target to bugzilla +13:30 <@duck> in case there are bugs +13:30 < jrandom2p> (heh, did i even add a 0.4?) +13:31 < jrandom2p> but good call +13:31 <@duck> or would you like bugs elsewhere +13:31 <@duck> err bugreports :) +13:31 <@duck> I know that I have been lazy and abuse irc messages for them +13:31 < jrandom2p> no, bugzilla is great, much better than my notebook +13:32 < jrandom2p> i don't blame you, as bugzilla is a bit of a pain +13:32 < jrandom2p> but as bugs pile up, its for the best +13:32 <@duck> nah +13:33 * jrandom just noticed i'm switching schitzophrenically between screens +13:34 < jrandom> ok, anyway, moving on to 3) i2p-bt 0.1.6 +13:34 < jrandom> duck: you've got the mic +13:34 <@duck> ok +13:34 <@duck> i2p-bt 0.1.5 had some issues, the two biggest ones: +13:35 <@duck> - resource temporarily unavailable +13:35 <@duck> - invalid argument error on windows +13:35 <@duck> both have been fixed +13:35 < jrandom> (yay!) +13:35 <@duck> while I tried to blame the sam protocol, the sam bridge and winsock +13:35 <@duck> the problem turned out to be related to non-blocking socket code +13:36 <@duck> I yet have to see 0.1.6 crash +13:36 <@duck> some other issues are not addressed: +13:36 <@duck> the GUI users have been complaining about the popups +13:36 <@duck> you can comment them out, but I didnt like that +13:37 <@duck> still waiting for someone to implement a better solution +13:37 <@duck> like showing a status line on the transfer window itself +13:37 * smeghead hides +13:37 < smeghead> i looked at that last night actually +13:37 < smeghead> but it's not at the top of my priority list +13:37 <@duck> or maybe one day I will look into how wxPython works and do it myself +13:37 <@duck> but it's not at the top of my priority list +13:38 <@duck> and I dont use the GUI, so I dont really care :P +13:38 <+Ragnarok> there's always the new gui from 3.9 :) +13:38 <@duck> is it any better? +13:38 < smeghead> yes why did you base i2p bt on such a crusty version in the first place? :) +13:38 <@duck> because it was the stable release at that moment +13:39 <@duck> and not as mutilated as clients like bittornado +13:40 <@duck> Ragnarok: ignoring licensing issues, I think that porting our i2p things to 3.9 might be good +13:40 <+Ragnarok> the new gui is pretty awsome, imho, and it's written using pygtk, so I can actually hack on it +13:40 < jrandom> what's 3.9's license? i thought it was mit-esque? +13:40 <+protokol> i would love a more recent jetty version +13:40 < smeghead> protokol: that's coming sooner than you think +13:41 <@duck> "BitTorrent Open Source License" +13:41 < smeghead> flavor of the month license +13:41 <+Ragnarok> I haven't read all of it.. it seems odd +13:41 <+protokol> licencing does not exist on i2p +13:41 <@duck> derived from the Jabber Open Source License 1.0 +13:41 <+protokol> if there is source, its PD +13:41 <@duck> protokol: that is why I said 'ignoring' +13:42 < smeghead> and the jabber license is based on? +13:42 < jrandom> (out of date copyright laws?) +13:42 < smeghead> besides that :) +13:43 < modulus> Sun's wish to fuck about. +13:43 <@duck> http://www.opensource.org/licenses/jabberpl.php +13:43 < smeghead> i move we schedule the licensing issue for the next meeting of the I2P Public Domain Security Council +13:43 < modulus> ah, that one +13:43 < modulus> misheard. +13:45 <@duck> 3.9.0 looks hot +13:45 <@duck> it is still beta though +13:47 <@duck> ok, those willing to help, please let me know +13:47 <@duck> so we can look into using 3.9.x +13:47 <@duck> . +13:47 < jrandom> w3rd +13:47 < smeghead> i'm willing to help out +13:47 < jrandom> i'm willing to help test +13:48 <+Ragnarok> I'm willing, but there are likely to be time constraints, as I am currently having the semester from hell. +13:48 < jrandom> d'oh +13:48 <@duck> drop out +13:48 < jrandom> damn, duck beat me +13:48 < smeghead> yes, everyone does it +13:49 <+Ragnarok> boo +13:49 < ant> <jnymo>gt; just join the military ;) +13:50 < jrandom> yeah, as that'll give you lots of time to code, 'eh? ;) +13:50 <+Ragnarok> I've already given up on being a math major, that's as much as you're getting from me :) +13:50 < jrandom> heh +13:50 < jrandom> ok, anyone else have anything on 3) i2p-bt? +13:51 < ant> <jnymo>gt; just don't sign up for six years +13:51 <@duck> quite a bit of forum posts on it +13:51 <@duck> thanks to those who aid the newbies +13:51 <@duck> s/thanks/my thanks/ +13:51 <@duck> if you have stuff for a FAQ, lemme kno +13:52 < jrandom> (if we still had drupal, we could just add a new node...) +13:53 < jrandom> ok, anyway, moving on to 4) fortuna +13:54 < jrandom> smeghead: wanna give us an update on things? +13:54 < smeghead> yes, i'm working on pants and fortuna in tandem +13:55 < smeghead> since i needed to modify fortuna's build to turn it into a pbuild +13:55 < smeghead> eta on a patch that will let you test fortuna is a day or two, maybe tonight depending on what drugs are involved +13:56 < jrandom> heh +13:56 <@duck> so you'll get your pants down? +13:56 < jrandom> ok, cool, whenever is fine - if we get it in for 0.5 in the next week or so, thats great, if not, thats great too +13:56 < smeghead> well even if i finish it tonight, i would take a conservative stance on deployment +13:57 < jrandom> reasonable enough +13:57 < smeghead> until we get some decent testing in +13:57 < smeghead> since this will be at the heart of most of i2p's crypto +13:57 < jrandom> aye +13:57 < ant> <jnymo>gt; will jbigi stay? +13:57 < smeghead> your new entropy class is cool +13:58 < jrandom> yeah jnymo, this is just a random # generator +13:58 < ant> <jnymo>gt; ah +13:59 < jrandom> we'll still need to do some research into the quality of various entropy sources in the router, but I think we'll be able to feed it some data. +14:00 < smeghead> btw if anyone wants to read what this pants thing is about: http://smeghead.i2p/README_pants +14:00 < jrandom> oh wikked +14:01 < smeghead> pants is almost done too +14:01 < brachtus> i know jbigi is kinda hard to get working with OS X/Darwin... will this have the same build problems? +14:01 < smeghead> what is the issue on osx? +14:01 < modulus> it's just you have to build the lib +14:02 < modulus> not a big deal imo, but somewhat troublesome. +14:02 < jrandom> brachtus: fortuna is in pure java, doesnt use anything native +14:02 < smeghead> i can put jbigi into pants and that should make building a cinch if we ship pants with i2p +14:02 < brachtus> nothign terribly difficult, it's like building a shared lib on linux, but harder than just double-click-install +14:02 < smeghead> you'd need ant of course +14:02 < brachtus> ok jrandom, that's great :) +14:03 < jrandom> smeghead: thats actually a good point - jbigi has a pants dependency upon GMP +14:03 < ant> <jnymo>gt; what is pants? +14:03 < smeghead> no manual mucking would be necessary +14:03 < ant> * jnymo doesn't have a router up +14:03 < smeghead> jnymo: read that link i just posted +14:04 < jrandom> http://bolas.mine.nu:8080/cgi-bin/nph-proxy/000000A/http/smeghead.i2p/README_pants +14:04 < smeghead> pants can build gmp too +14:04 < jrandom> (public inproxy) +14:04 < smeghead> ah nice +14:04 < jrandom> yuck, that totally b0rked the text +14:04 < ant> <jnymo>gt; thanks jr +14:04 < ant> <fvw>gt; aren't you afraid of legal trouble? +14:04 < smeghead> jrandom doesn't run the inproxy +14:04 < jrandom> oh, the inproy is run by someone else, its been posted to the forum +14:05 < jrandom> (see http://bolas.mine.nu:8080/) +14:05 < cervantes> jrandom: it shouldn't be viewed as an html file...check the source +14:05 < ant> <fvw>gt; still, I'm amazed anyone would. But as long as it's being run by someone not vital to the project, fine :) +14:05 < jrandom> hehe +14:05 < jrandom> we're /all/ vital to the project :) +14:06 < smeghead> fvw: i don't see inproxies as legally precarious as outrpoxies +14:06 < smeghead> outproxies even +14:06 < ant> <fvw>gt; Perhaps not, but they can still serve up child porn and such +14:06 < jrandom> only if there were such things on i2p, which, to my knowledge, there isnt +14:06 < legion> outproxies could route through tor, just to be a little safer, since they would just be used for webrowsing I don't see it as a problem. +14:07 < jrandom> (but yeah) +14:07 < modulus> yet +14:07 < ant> <fvw>gt; yeah, but anyone can put it on at any point. +14:07 < ant> <fvw>gt; yeah, I wouldn't run a tor outproxy either. Anyway, sorry for drifting offtopic like that +14:07 < jrandom> legion: yeah, though i tossed up squid.i2p before tor was out +14:07 < ant> <duck_>gt; to get back on topic; looking forward to pants +14:08 < jrandom> aye, pants++ +14:08 < smeghead> i'll let you know before i drop pants on CVS +14:08 < smeghead> it's kinda big +14:08 < ant> <duck_>gt; folks outside of i2p might be interested in it too +14:09 < cervantes> yes let us all know before you drop your pants +14:09 < smeghead> yes, i intend to publicise it outside of i2p also +14:09 < jrandom> agreed, perhaps we should put it in another module (or on the new fast/large server)? +14:09 <+Ragnarok> especially if you're a big pants kind of guy +14:10 < smeghead> yes the pants module really should be kept separate from the pants repo in the source tree, currently i have them located in the same apps/pants root +14:10 < smeghead> :/ +14:10 < smeghead> which i don't have to tell you is total pants +14:11 < smeghead> so what were we talking about originally? +14:11 < jrandom> hmm, we can discuss deployment options offline +14:11 < jrandom> fortuna ;) +14:11 < smeghead> right +14:12 < jrandom> smeghead: have you looked at the AES/SHA256 needs of the impl? +14:12 < jrandom> (as i2p's SHA256 doesn't do partial digests) +14:13 < smeghead> hm +14:13 < jrandom> AES we've got perfectly suitable block impl though +14:13 < smeghead> i guess i'll find out when it blows up +14:13 < jrandom> anyway, we can work those through too +14:13 < jrandom> heh +14:15 < jrandom> ok, anyone have any questions/thoughts/concerns on fortuna? +14:15 < jrandom> if not, hopping on over to 5) ??? +14:15 < jrandom> cervantes: p1ng +14:16 < cervantes> http://forum.i2p/viewtopic.php?t=305 +14:16 < cervantes> we have a new forum member of the week +14:16 < cervantes> I present [drumroll] Sugadude! +14:16 * brachtus applauds Sugadude +14:17 < jrandom> yay +14:17 < cervantes> for generally being a helpful sod to all those i2p n00bs +14:17 <@duck> nice avatar too +14:17 < cervantes> avatar(s) +14:18 < legion> avatars? didn't know that we could have avatars on the i2p forums? +14:18 < smeghead> only users who are really really bad get them +14:18 < cervantes> you can't...unless you're a forum person of the week ;-) +14:18 <@duck> only for the elite +14:18 < legion> oh, i see... +14:19 < ant> <jnymo>gt; i know someone was interested in secure financial systems over i2p +14:19 < legion> makes sense :) +14:19 < ant> <jnymo>gt; don't know if they're here, but... +14:19 <@duck> I am a smelly anarcho capitalist +14:19 <@duck> so try me +14:20 < ant> <jnymo>gt; i was reading more on threashold cryptography and theres talk about using it for that +14:20 < ant> <jnymo>gt; as well as securing other functions +14:21 < ant> <jnymo>gt; everyone familiar with threshold cryptography? +14:21 < legion> IMO that cryptography and network security should be variable, how much should depend on the feature/task. +14:21 < ant> <duck_>gt; jnymo: a bit +14:22 < ant> <jnymo>gt; well, for trustable financial transactions in i2p, we want strong decentralized trust +14:22 < modulus> is that about the shared keys and shit like that? +14:23 < ant> <jnymo>gt; yea, keys are shared in pieces +14:23 < ant> <duck_>gt; but in an anonymous environment, how do you know that the entities doing the sharing arent controlled by the same one? +14:23 < ant> <jnymo>gt; and you need to circumvent more than half of all the servers in the system to obtain the priv key +14:24 < modulus> afaik it's kind of complicated the issue of distributed key generations though. +14:24 < legion> yeah but in a system of millions that would be hard (yeah i2p is small at the moment, but hopefully it will grow much larger soon). +14:25 < ant> <jnymo>gt; atomic communications, or something.. but yea, theres issues with taking on new nodes on the system, which i thing are being worked out +14:25 < ant> <jnymo>gt; think +14:25 < ant> <jnymo>gt; so maybe its not developed enough, but i'd bet some usage of threshold crypto will end up over i2p at some point +14:26 < jrandom> neat +14:26 < legion> dunno, maybe +14:26 < ant> <jnymo>gt; someone has already built a DNSSEC addon with threshold crypto +14:27 < ant> <jnymo>gt; and a wrapper around bind +14:27 < jrandom> thresholds work fine when identity is scarce +14:27 < jrandom> in anonymous networks, however, identity is free +14:27 < legion> I'd figure at the moment the highest priority is to get it more user friendly and debugged. +14:27 < jrandom> (want a new destination? want 100,000?) +14:28 < legion> granted it's cool whenever a new service/feature is developed. +14:28 < jrandom> aye, commerce and finance on top of i2p will be nice +14:28 < ant> <jnymo>gt; yea, and i wouldn't know if atomic commo would work over a 10000 node threshold crypto sys +14:29 < ant> <jnymo>gt; well, that's all i had to say :) +14:30 < jrandom> heh cool, definitely feel free to post up neat stuff to the forum or whatnot whenever +14:30 < jrandom> ok, anyone else have anything for the meeting? +14:32 <+ugha2p> I suck. +14:33 < jrandom> whats up ugha2p? +14:33 < ant> <jnymo>gt; glad you got that off your' chest, ugha ;) +14:33 <+ugha2p> I never remember the meetings. :) +14:33 < jrandom> heh +14:33 < jrandom> well, the logs will be posted soon, 90 minutes of action packed fun +14:34 < jrandom> well, on that note +14:34 * jrandom winds up +14:34 * Curiosity waves to jrandom and stays thank-you! :D +14:34 < ant> * jnymo pitches the meeting ball +14:34 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/128.rst b/i2p2www/meetings/logs/128.rst new file mode 100644 index 00000000..cd28c840 --- /dev/null +++ b/i2p2www/meetings/logs/128.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 8, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/129.log b/i2p2www/meetings/logs/129.log new file mode 100644 index 00000000..e6d5cdfb --- /dev/null +++ b/i2p2www/meetings/logs/129.log @@ -0,0 +1,247 @@ +13:07 < jrandom> 0) hi +13:07 < jrandom> 1) Net status +13:07 < jrandom> 2) 0.5 status +13:07 < jrandom> 3) i2p-bt 0.1.7 +13:07 < jrandom> 4) ??? +13:07 < jrandom> 0) hi +13:07 * jrandom waves +13:07 <+ugha2p> jrandom: Is irc.duck.i2p also available on the testnet and linked to this network? +13:07 <+ugha2p> To this IRC network +13:07 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2005-February/000575.html +13:07 < ant> <Sonium_> Bonjour, sa cette fois de la semaine encore, +13:07 < jrandom> no ugha2p +13:08 < ant> <Sonium_> are you speaking french jrandom ? +13:08 < jrandom> heh, yeah, proof that babelfish has its limits ;) +13:08 < jrandom> lol, yeah, people were saying babelfish was turning out ok french before, but aparently not this time ;) +13:09 <+ugha2p> Hi fellow I2Pers. +13:09 < ant> <fedo2p> hi +13:09 < jrandom> anyway, lets get this underway before we netsplit again +13:09 < jrandom> 1) net status +13:09 < jrandom> see the email for an update +13:10 < jrandom> it seems that while irc has been pretty bumpy, as has some outproxy activity, bt has been doing pretty well +13:11 < jrandom> i don't really have much more to add beyond that though - anyone have any comments/questions/concerns? +13:12 < ant> <Sonium_> will 0.5 be released this friday? +13:12 < jrandom> heh good question, I suppose that can bring us on to 2) 0.5 status +13:12 < jrandom> yes, 0.5 will be released this friday +13:13 < jrandom> the test network is doing pretty well with the latest updates, but there's still some doc and minor cleanups left to do. i'm also going to try to get the latest jetty in there, but we'll see +13:14 < ant> <Sonium_> a question for a native english speaker: what is the semantical difference between "it will be released" and "it is going to be released" ? +13:14 < bla_> Routing seems to be a little bit of a problem sometimes; in, say 5-10% of the cases, I have to reload a page, because the tunnel isn't working well +13:14 < smeghead> i'd like to request that everyone involved in bittorrent activity voluntarily cease until 0.5 is released on friday since the surge in bt traffic is ruining the rest of the network traffic, especially irc +13:15 < jrandom> Sonium: the later is more definitive, but same general idea +13:15 < bla_> smeghead: I'd agree, but 0.5 will not solve the load problem, will it? +13:15 < smeghead> eepsites are affected too, not just irc +13:16 < ant> <Sonium_> ok, than it missunderstood the usage till now +13:16 <+ugha2p> jrandom: Will it be doing a better job with interactive traffic? +13:16 < jrandom> 0.5 will change a lot of dynamics, and should be able to more cleanly handle load balancing, as we can now differentiate between the different causes of tunnel rejection +13:16 < ant> <Sonium_> I better would have listened up at school +13:16 < jrandom> ugha2p: yes, substantially +13:17 <+ugha2p> Ah, cool. +13:17 < jrandom> otoh, there will be an overal increase in bandwidth usage for many situations, though we will improve upon that later as things progress +13:18 < smeghead> and someone please let our new french speaking users know about this and ask them to hold off the bt stuff until friday +13:18 < ant> <BS314159> smeghead: it's three days. I'm sure you can come up with something else to do for three days +13:19 * jrandom could poke open an inproxy to spaetz's 0.5 ircd :) +13:20 < jrandom> perhaps a simpler solution would be to suggest bt users take advantage of the capacity to reduce network load by reducing their tunnel length +13:21 < jrandom> (both on the inbound tunnels, as configured with the bt command line, and on outbound tunnels, as configured on http://localhost:7657/configclients.jsp ) +13:21 < polecat> Yeah, they don't need so much anonymity as obscurity. It's us illegal alien ferrets that need the 2 hop thingy. +13:21 < bla_> jrandom: A possible solution, bt-0.1.8, wiith default tunnels length of 1, was mentioned before here on the channel. Duck, you here? +13:22 < polecat> Does i2p-bt use SAM, or does it use an i2ptunnel session? +13:23 < jrandom> hmm, otoh there are a whole set of new i2cp session options we'll want exposed in the i2p-bt, so i'll need to get in touch with duck about an updated release anyway +13:23 < jrandom> polecat: SAM +13:23 < smeghead> BS314159: i'm a contributor to not only i2p codebase, but also i2p-bt, this bt traffic is preventing me from communicating with the other devs and impeding our efforts to improve everyone's experience, have some consideration please +13:23 < smeghead> BS314159: is it more important for you to torrent than it is for us to develop +13:23 < smeghead> ? +13:23 < smeghead> polecat: sam +13:23 < cervantes> make 0.1.8 shop all it's users to the mpaa and we'll all stick with 0.1.7 +13:23 < smeghead> bla_: there probably won't be a 0.1.8, we've got 0.2.0 in cvs now, a new codebase based on bt 3.9.1 +13:23 < jrandom> heh cervantes +13:23 < jrandom> ooOOo nice +13:24 < jrandom> perhaps thats a good segue from 2) 0.5 status to 3) i2p-bt :) +13:24 < jrandom> smeghead/duck, how goes? +13:25 < ant> <Sonium_> google knows 167 links to www.i2p.org +13:25 < bla_> jrandom: Maybe the upgrade timeline should be reiterated: take yer eepsite offline on Thursday evening (UTC), upgrade on Friday, and fire up the eepsite when a sufficient number of users have upgraded +13:26 < ant> <Sonium_> erm .net +13:26 < smeghead> all the bt mods in 0.1.7 have been integrated into the new 0.2.0 codebase +13:26 < smeghead> but we have to write a completely new sam interface, we can't use the one from 0.1.7 +13:27 < jrandom> ah ok +13:27 < smeghead> if there's anyone with python socket experience that would like to help *cough*connelly +13:28 < polecat> All that's happening in SAM is the addition of stream level choking, right? +13:28 < jrandom> polecat: no protocol changes yet (to my knowledge), just porting +13:28 < smeghead> please get in touch with duck +13:28 < ant> <MANCOM> anything new on azneti2p? +13:28 < smeghead> the 0.2.0 client will handle multiple torrents all in one instance, you won't have to open multiple sessions anymore +13:29 < jrandom> (yay!) +13:29 < polecat> Reeeally? +13:29 < smeghead> and hopefully we can get it all working over a single sam session to further reduce network clutterage +13:29 < bla_> smeghead: Nice! Will you also port the text-onlu bttrackmany? +13:29 < polecat> Can it run in the background? +13:29 < jrandom> MANCOM: I haven't heard any news, and unfortunately haven't had time to audit the updates +13:29 < polecat> How much memory does it sit on? +13:29 < smeghead> bla_: yes i believe so +13:30 < smeghead> polecat: using btdownloadheadless.py it's a background process +13:31 < polecat> A single SAM session is possible: the peerwire and tracker protocol can be divined by both the client and server. +13:31 < polecat> smeghead: Yes, but what if I want to add a torrent to that process? +13:32 < smeghead> polecat: and it shouldn't use significantly more memory than the comparable number of 0.1.7 instances do +13:34 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT. someone could add new and better features, but lets start with a plain port first ;) +13:36 < bla_> (Connection rollercoaster ride, again...) +13:36 < jrandom> (this is why I lightly edit the meeting logs ;) +13:37 < bla_> jrandom: :) +13:37 < jrandom> wb +13:37 < polecat> smeghead: Yes, but what if I want to add a torrent to that process? +13:38 <+ugha2p> jrandom: No, it must be because you're censoring the netsplits. +13:38 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT. someone could add new and better features, but lets start with a plain port first ;) +13:38 < jrandom> hey, if i censor the netsplits, they dont happen! +13:38 * jrandom buries head in sand +13:40 < smeghead> but i will use this opportunity to again ask bt users to hold off until friday please +13:41 < bla_> Right, if there's anyone who speaks French here, you don't have to say anything now, but please add a message to the effect of what smeghead asks to the French sections of forum.i2p ... +13:42 <+polecat> At any rate, I've missed the chance to say but, I was thinking of instead of a bt client in C++, I could just fix the mldonkey bittorrent plugin, and use that. +13:42 < ant> <dm> I speak french. +13:43 < ant> <dm> awww shit, I was supposed to not say anything. +13:43 * jrandom flings mud at dm +13:43 < bla_> dm: Could you add those messages? +13:43 < smeghead> there's nothing wrong with torrenting, but then again such a sudden increase in the number of i2p users wasn't expected and clearly the 0.4.x network can't handle it well +13:43 <+polecat> Unless someone else had an idea for something better I could waste my time on. :/ +13:44 < ant> <dm> don't have i2p on here, I'm afraid. I can translate english->french if u msg me what needs to be said. +13:44 < jrandom> polecat: perhaps help out getting the upcoming i2p-bt to work as you'd like? +13:44 < jrandom> dm: forum.i2p.net/ +13:44 <+polecat> jrandom: I think the main bt isn't very useful myself, and is doomed to be a stopping block for multiple torrent system, unless they switch to a client/server UI. +13:44 <+polecat> Which I might add, mldonkey/mlnet has already done. +13:44 < smeghead> polecat: mldonkey is a horrid, horrid mess, please help on the i2p-bt project or the azureus-i2p project, they could use a hand +13:44 < ant> <BS314159> polecat: I think it's a waste of time to reimplement i2p-bt in a faster language, given the overhead in I2P +13:45 <+polecat> And I was planning to do with this stupid C++ client thingy o' mine. +13:45 < jrandom> polecat: so put on a gui, giving you the benefit of the underlying i2p-bt code +13:45 < ant> <BS314159> but having the use of the MLDonkey interface might be a very good thing +13:46 <+polecat> Azareus doesn't separate UI from file transfer I dun' think. :/ +13:46 < smeghead> polecat: you need to try bt 3.9.1, it's a multitorrent client now +13:48 <+polecat> Does it allow you to quit the UI without quitting swarming your files? +13:48 < jrandom> there are some features that it doesnt do well, that azureus does well, though there are also some environments where azureus isn't the right solution +13:48 < ant> <jnymo> has azureus released a compatable binary for the plugin? +13:48 < jrandom> polecat: no. but adding that is trivial compared to writing a new bt client +13:48 < jrandom> jnymo: yes, they have a beta azneti2p +13:49 < smeghead> polecat: it could easily be modified to do so, very easily in fact +13:49 < jrandom> polecat: just modify the existing bt daemon to allow other processes (aka your new GUI) to tell it to do things +13:49 <+polecat> Well, perhaps... +13:49 <+polecat> You think so? +13:49 <+polecat> Maybe if I wrote a UI that was just an RPC socket protocol, and then... I'd have to write a whole client to grok that protocol... +13:50 < smeghead> polecat: you don't have to write a new ui, mod the existing i2p-bt 0.2.0 ui to do it, it's simple +13:50 <+polecat> Maybe we could separate the UI part of bt and the daemon part, and run those pieces as separate processes without having to rewrite too much code! +13:50 <+polecat> Okay. +13:50 <+polecat> I have one more question though... +13:51 < smeghead> polecat: don't reinvent the wheel because something lacks trivial features +13:51 < smeghead> polecat: you haven't looked at the i2p-bt codebase at all have you? the ui is completely separate +13:51 <+polecat> If bittorrent 3.9.1 is out, why are we using version 0.2.0 in i2p? o.o +13:51 < jrandom> heh +13:51 < jrandom> i2p-bt 0.2.0 == bt 3.9.1 :) +13:51 <+polecat> I looked at the codebase a while ago. It was quite convoluted and obfuscated. +13:51 < jrandom> (i2p-bt 0.1.* == bt 3.4.something i think) +13:51 <+polecat> Oh, you have different versioning. +13:52 <+polecat> Is i2p-bt on CVS? +13:52 < smeghead> polecat: 0.2.0 is a new branch in cvs i created yesterday, it's i2p-bt, the official bt version it's based on is 3.9.1 which will be bittorrent 4.0 when it's out of beta +13:52 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p-bt/ +13:52 < smeghead> i2p-bt 0.1.7 is bt 3.4.2 based +13:52 <+polecat> Thanks. +13:52 <+polecat> Wait. +13:53 < cervantes> at which point we'll call it version 0.3.0 :P +13:53 <+polecat> I meant CVS, not the "ooh lookit the pretty website CVS" +13:53 < jrandom> cvs -d :pserver:anoncvs@cvs.i2p.net/cvsroot co i2p-bt +13:53 <+polecat> CVSROOT= is noticeably absent on those cvs-cgi thingies I've noticed. +13:53 < jrandom> or, if you have the CVS proxy locally, cvs -d :pserver:anoncvs@localhost/cvsroot co i2p-bt +13:54 < smeghead> polecat: convoluted? btdownloadgui.py is all the gui code, how can you get more cleanly separated than that? +13:54 * polecat whews, and doesn't feel a burning desire to bitch about CVS now. +13:54 < ant> <dm> ugh, that was painful, haven't written anything in french for years! http://forum.i2p.net/viewtopic.php?p=1238#1238 +13:55 < jrandom> thanks dm +13:56 < ant> <dm> np +13:57 < smeghead> it probably says something obscene +13:58 < ant> <dm> hehehhe +13:58 <+polecat> Alright, so I have to write btdaemon.py, which is the gui - all gui stuff. And also btdaemongui.py, which is the gui - all daemon stuff. +13:58 < ant> <BS314159> if it's sufficiently obscene, it may serve our purposes just fine +13:58 < ant> <fedo2p> good job dm ;) +13:58 < jrandom> heh +13:58 < jrandom> r0x0r polecat +13:59 <+polecat> Sigh, I hate to emerge wxwindows though, it's a big library I don't normally use. Oh well. +13:59 < smeghead> polecat: 0.2.0 is gtk based, no more wxwidgets +13:59 < jrandom> ok, lots of bt work to do, perhaps we can discuss further on the list/forum/wiki/#i2p-bt as necessary? +13:59 <+polecat> If I'm gonna be hackin', I best get the toolz +14:00 <+polecat> Oh I forgot about that channel. :) +14:00 < smeghead> polecat: get bittorrent 3.9.1 beta and read the docs +14:01 < smeghead> #i2p-bt, right +14:01 < smeghead> there's even people there +14:02 < jrandom> heh ok, lots of exciting bt stuff. anything else for 3) i2p-bt, or shall we move on to 4) ??? +14:03 < jrandom> ok, moving to 4) ??? +14:03 < jrandom> anyone else have anything else to bring up for the meeting? +14:03 < ant> <jnymo> threshold crytography rules +14:04 < cervantes> ??? = http://forum.i2p/viewtopic.php?p=1237 +14:04 < ant> <BS314159> proxies to the web are not cool. What about proxies to new versions of I2P, or other anonymnets? +14:04 < ant> <BS314159> and by not cool I mean not safe to run +14:04 < ant> <jnymo> they aren't run by everyone, BS +14:05 < ant> <BS314159> I know that +14:05 < cervantes> Forum member of the week is <tadaa!> jrandom +14:05 < ant> <BS314159> I'm thinking about upgrades +14:05 < jrandom> lol thanks cervantes +14:06 < ant> <BS314159> Not now, but eventually, would it be possible to have a large number of routers act as inter-version proxies? +14:06 < ant> <BS314159> and would that remove the timing attack without downtime? +14:06 < ant> <jnymo> forced upgrades are necessary +14:07 < ant> <BS314159> I disagree +14:07 < jrandom> BS314159: I2NP over i2ptunnel over I2P would be, painful. though perhaps one of the "outproxies" could point at some inproxy +14:07 < jrandom> BS314159: while forced upgrades aren't generally necessary, they are here. period. we need it, because I didn't forsee all of the changes we need for 0.5 +14:08 < ant> <BS314159> I'm not saying new versions should be backwards-compatible +14:08 < cervantes> jrandom: well lets be honest...you're the one that does 98% of the work ;-) +14:09 < ant> <BS314159> I'm just trying to come up with a way to allow non-nimble I2P users to upgrade without timing attacks or downtime +14:10 < jrandom> BS314159: can't be done for the 0.5 release. later releases we can be careful. but for this one, its a drop dead cutoff. +14:10 < ant> <jnymo> automatic update may be better in the future +14:10 < ant> <BS314159> I'm speaking about the far future. +14:10 < ant> <jnymo> is auto-update too insecure? +14:10 < jrandom> cervantes: nah, only 95% of the infrastructure, but there's a lot more goin' on than just i2p/{core,router}/ :) +14:11 < jrandom> jnymo: 0 click update == insecure. 1 click == safe. +14:11 < cervantes> jrandom: yes it's begun to pickup over the last couple of months thankfully ;-) +14:11 < ant> <jnymo> and a line that says "you need to update.. countdown in * days" +14:12 < jrandom> aye, lots of people [http://www.i2p.net/team] have been doing kickass shit +14:13 < jrandom> BS314159: definitely lots we can do for later updates, perhaps we can discuss concrete impls as they approach :) +14:13 < jrandom> ok, anyone else have anything to bring up for the meeting? +14:13 < ant> <MANCOM> could we have some kind of autospeed feature (like with the azureus plugin that measures ping times) in i2p that adjusts the maximum (upload-)bandwidth? +14:14 < ant> <MANCOM> it would help keep bandwidth up and latency down +14:14 < jrandom> oh, interesting +14:14 * cervantes is working on a 1-2 click update feature for the i2p toolbar +14:14 < cervantes> although I'm having problems with hashing atm....so it's probably a few weeks away. +14:15 < ant> <jnymo> cervantes++ +14:15 < jrandom> MANCOM: if you could doc up how it'd work and look, and post that on the forum, that'd be great. if its simple enough, might even make it into 0.5 +14:15 < cervantes> in which time a dozen people will come up with a glut of better solutions +14:16 < jrandom> heh +14:16 < cneal92_> :D +14:17 < ant> <MANCOM> well, i'll try +14:17 < ant> <cervantes> but it already detects when there's a new release out, and can point you at the relevant download link... +14:17 < ant> <cervantes> which I may roll with initially +14:18 < jrandom> cool cervantes +14:18 < jrandom> thanks MANCOM +14:18 < ant> <jnymo> you could just put the "graceful restart" button to upgrade, after the update is already in the directory +14:19 < ant> <jnymo> or call it "upgrade" +14:19 < ant> <jnymo> and put the restart function in there +14:19 < ant> <jnymo> though i'm probably stating the obvious +14:19 < jrandom> right, we need perhaps a dozen lines of code to fetch http://dev.i2p/i2p/i2pupdate.zip, verify it, then restart +14:20 < jrandom> ok, anyone else have anything to bring up for the meeting? +14:20 < ant> <cervantes> well I can already get the toolbar to download an update into the i2p folder AND trigger a graceful restart...but so far I haven't been able to get it verify the download's integrity +14:21 < jrandom> cervantes: ah, that part should be easy - at a later date, we'll have the update itself be self-verifying +14:21 < jrandom> (aka signed, verified by the router before installation) +14:21 < ant> <cervantes> jrandom: that would be cool. +14:21 < ant> <jnymo> ooh +14:22 < ant> <cervantes> perhaps it will be enough then that I trigger the download and then pop a "do you wish to restart" yes/no requester +14:22 < ant> <cervantes> so someone can verify manually if desired +14:23 < ant> <cervantes> (it already displays what the sha1 _should_ be) +14:23 < jrandom> hehe +14:23 < ant> <jnymo> how bout, "click here to autodownload on availability" +14:25 < cervantes> I'd rather avoid auto downloads +14:25 < ant> <jnymo> hmf.. microsoft does it ;) +14:26 < cervantes> but by all means alert the user that a download exists and offer a "download now" button +14:26 < jrandom> right, 1 click at the least. we can automatically /notify/ on update availability, but autoinstall is not ok +14:26 < jrandom> (er, what cervantes said) +14:27 < ant> <jnymo> now, how do 10000 people update? how bout integrating i2p-bt at one point? +14:27 < jrandom> yes, and flying ponies +14:28 < ant> <jnymo> good enough for me +14:29 < jrandom> ok cool... if there's nothing else... +14:29 <+postman> damn missed the meeting :/ +14:29 * cervantes gets back to coding his vapourware +14:29 < jrandom> heh you're at the buzzer, in case there's something you want to bring up postman :) +14:30 <+postman> no thanks +14:30 <+polecat> Microsoft? =) I have gentoo doing it. +14:30 * jrandom winds up +14:30 <+postman> ooops +14:30 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/129.rst b/i2p2www/meetings/logs/129.rst new file mode 100644 index 00000000..c4ae7038 --- /dev/null +++ b/i2p2www/meetings/logs/129.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 15, 2005 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/130.log b/i2p2www/meetings/logs/130.log new file mode 100644 index 00000000..508c5f84 --- /dev/null +++ b/i2p2www/meetings/logs/130.log @@ -0,0 +1,282 @@ +13:04 < jrandom> 0) hi +13:04 < jrandom> 1) 0.5 +13:04 < jrandom> 2) Next steps +13:04 < jrandom> 3) azneti2p +13:04 < jrandom> 4) ??? +13:04 < jrandom> 0) hi +13:04 * jrandom waves +13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html +13:05 < jrandom> (yeah, only a minute or two before the meeting, so lets test your speed reading) +13:05 <+detonate> i think i'll wait until it's a bit less buggy before i put boondock saints up, in that case +13:06 < jrandom> why... thats... thats... thats a copyright violation! +13:06 <+detonate> weird new additions to the azureus beta +13:06 <+detonate> categories +13:06 <+detonate> haha +13:06 <+detonate> a dht tracker +13:06 <+detonate> sweet +13:07 < jrandom> aye, it looks v.cool, but lets hit items 1 and 2 before 3, 'eh? ;) +13:07 <+detonate> hi +13:07 <+detonate> indeed +13:07 < jrandom> jumpin into 1) 0.5 +13:07 < jrandom> its, like, out, and stuff +13:08 < cervantes> yay! +13:08 < jrandom> there'll be a new rev later this evening with a bunch of updates (current CVS head is 0.5-5, with a -6 in testing on some routers) +13:09 < jrandom> its gone pretty well, but we've hit a few funky bugs along the way. but c'est la vie +13:09 < frosk> i can report that 0.5-5 behaves a _lot_ more friendly than -4 (which often gave me participating tunnel counts in the thousands) +13:09 < bla> jrandom: Will the 0.5.0.1 version correct the problem of nor being able to find destinations? +13:09 < jrandom> ah, well, thats really just a function of other people though, the -0 build actually does build hundreds of tunnels +13:09 < bla> s/nor/not +13:10 < jrandom> bla: yes, thats a bug in the netDb +13:10 < bla> jrandom: Great! +13:10 < jrandom> (in the leaseSet publishing, specifically) +13:11 < jrandom> and yes, the 0.5.0.1 rev will get rid of that occational disapearing proxy bug +13:12 < jrandom> there is still a funky memory leak I haven't tracked down affecting some users +13:12 < bla> Then, in all, it seems that part from these bugs, the 0.5 net is doing very well. Yay! +13:12 < jrandom> to my knowledge, its only really hitting two or three I2PTunnel instances though +13:12 < Meomia> is it a sign of progress when you have gone from 0 to 130 participating tunnels since 0.5 ? +13:13 < jrandom> w3wt +13:13 < jrandom> Meomia: bah, I've had over 5000 tunnels ;) +13:13 < jrandom> but dm actually has helped find a bug in the exploratory pool code, so we will be building tunnels more often on 'random' peers +13:14 < jrandom> (yay) +13:14 < Meomia> ok +13:14 < bla> jrandom: Does that also mean that now, in contrast to 0.4, every peers can at one time become your inbound gateway? +13:14 < jrandom> yes, for exploratory tunnels +13:15 < jrandom> client tunnels will only use peers in the 'fast' tier +13:15 < bla> bla: Ok. The fact that client tunnels use only the fast peers is good: otherwise, we get the anon issue we discussed before +13:16 < jrandom> and performance would suck otherwise ;) +13:17 < jrandom> actually, that brings us in to 2) Next steps +13:18 < jrandom> the big thing left for the 0.5 series is a bunch of strategies for ordering and/or filtering the peers used in tunnels +13:18 < godmode0> jrandom can use nntp w i2p ? +13:18 < jrandom> godmode0: there are two NNTP servers on i2p, yes. see the forum +13:19 < godmode0> jrandom ok i;m testing +13:19 < godmode0> i can build my server too ? +13:20 < jrandom> godmode0: we're in a meeting right now, but yes, you can run a server +13:20 < godmode0> jrandom ok sorry +13:20 < jrandom> np +13:20 < jrandom> the posted strategies are basically aimed at improving anonymity, but there are a few other goals that we can balance in there +13:21 < jrandom> perhaps we can find a way to integrate some of the AS paths into the selection, as bla suggested +13:22 < jrandom> that can both improve (jurisdictional) anonymity, or if we try to stay within an AS (or two), that can improve performance +13:22 < bla> jrandom: This basically is related to a paper by the Tor creators: http://theland.i2p/files/routing-zones.pdf +13:22 < jrandom> aye +13:23 < jrandom> there are a whole slew of different strategies people can use, and trying out new ones should be pretty easy +13:24 < jrandom> we aren't going to spend months implementing everything we can think of, but merely provide the basics for what most people will need. anyone who wants to add new ones are very much encouraged to help plug 'em in +13:25 < jrandom> anyway, once the basics are in place, we'll be moving on to focus on the UDP transport for 0.6 +13:26 < jrandom> thats about all I have for 2) next steps, anyone have any comments/questions/concerns? +13:26 < bla> Who where the ppl that started looking into I2P, again? +13:26 < bla> It seems we haven't heard much from them, lately. +13:27 < bla> s/into I2P/into UDP/ +13:27 < bla> sorry +13:27 < jrandom> ah, mule has been sick, thogh I think detonate is making progress +13:28 < jrandom> detonate: any news? +13:29 < jrandom> or perhaps not ;) +13:30 < jrandom> ok, moving on to 3) azneti2p +13:30 <+detonate> sorry +13:30 <+detonate> i'm making progress +13:30 <+detonate> i still need to finish the re-assembly side of things +13:31 <+detonate> as far as splitting data into packets and sending it across in an orderly fashion, that works +13:31 <+detonate> on to 3) +13:31 < jrandom> wikked +13:31 < godmode0> sorry step 2) i2p has any problem with attacks ? +13:31 < bla> detonate: Cool! Can you keep all of us posted on the forum? +13:32 <+detonate> bla: sure +13:32 < tracker> About azneti2p, look here: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 seems like downloading works, seeding not. +13:32 < jrandom> godmode0: the different ordering strategies should let the user choose the impact of predecessor attacks +13:33 < microsoft> whoever runs i2p.net should add more Enterprise Class Solutions buzzwords to the page. +13:33 <+detonate> someone needs to make sure that new dht tracker isn't misbehaving as well, with respect to the azureus plugin +13:33 < tracker> My local tests seem to prove this, I can download with azureus but not seed. +13:34 < jrandom> hmm ok cool tracker, thanks - i know they updated a few things and pushed out b34 last night, but there may be more left to do, it seems +13:34 < jrandom> detonate: good point +13:35 < tracker> Good point detonate, I have DHT disabled as azureus dies after some hours whit 100% CPU usage when it's active. +13:35 * jrandom would like to reiterate that the azneti2p plugin is still fairly early beta, and azureus' anonymity implications have not fully been audited +13:36 < jrandom> while I'm sure they love having people test it out, those who need anonymity may want to be cautious +13:36 < tracker> On the other hand, i2p-bt works really well. Except that it doesn't close the tunnels, but that's not too bad IMHO. +13:37 < jrandom> oh, thats still happening with you tracker? i havent been able to reproduce that +13:37 < jrandom> you're on the 0.1.7 rev, right? +13:37 < tracker> Yes, I'm. +13:38 < jrandom> ok cool, if it happens all the time for you I'd love to pick your brains after the meeting to help track down the cause +13:39 < tracker> Maybe it's related to running it on XP instead of linux or unix. Closing the tunnel works with azureus, so I gues it is I2P-BT related. +13:39 < jrandom> hmm right, i2p-bt uses SAM, while azureus uses the i2p SDK directly +13:40 < tracker> Btw. I send you a bug-report on the forum. The timestamper is dies on the latest cvs-builds of I2P. +13:40 < jrandom> ah cool, thanks, havent checked my PMs over there today +13:41 < jrandom> on -5 or -4? or earlier? +13:42 < jrandom> ah, -4. ok cool +13:42 < jrandom> thanks, I'll get that fixed for 0.5.0.1 +13:42 < jrandom> ok, anyone have anything else for 3) azneti2p? +13:43 < tracker> It's also happening on -5 +13:43 < jrandom> you have sntp server defined explicitly, right? +13:44 < tracker> Yes. The 2 ones from our country. +13:44 < jrandom> i just checked the source and the exception occurs if the # concurring servers (default = 3) is greater than the # of servers specified (new default has 3) +13:44 < jrandom> ok cool, its a trivial fix to % # servers +13:45 < jrandom> ok, if there's nothing else for azneti2p, moving on to good ol' fashioned 4) ??? +13:46 < jrandom> anyone else have something to bring up for the meeting? +13:46 < tracker> Nice. I've just send you the log errors from the router when closing i2p-bt on the forum. +13:47 < jrandom> 'k cool, thanks +13:47 < cervantes> nothing to mention other than: nice work with the 0.5 rollout, looks like it'll kick ass once the bugs are ironed out +13:48 < tracker> Yep, the latest CVS builds are really performin good over here. +13:48 < jrandom> thanks, with your help as well as the rest of the 0.5-pre testers we were able to clean up a bunch of issues +13:49 < jrandom> the performance has been better than i had expected, though still not as high throughput as before. lots left to optimize though +13:49 < cervantes> strangely the pre version were more stable...for me, but then, I was running them on a different machine ;-) +13:49 < jrandom> (and these damn bugs to get reliability where it should be) +13:50 < jrandom> heh well, yeah, but the -pre network was 5-7 routers, all insanely reliable on really really fast connections +13:50 < cervantes> :) +13:51 < cervantes> sign me up for the 0.6 pre test then :) +13:51 < jrandom> heh +13:51 < tracker> Maybe I should take part in the next pre network then. Providing a very unreliable and slow connection ;). +13:51 < jrandom> the 0.6 migration will probably be even easier, I hope, as we'll just be able to add new router addresses to the routerInfo (UDP addresses) +13:51 < jrandom> heh word +13:51 < cervantes> I can put my 1TB file share online... +13:52 < jrandom> we'll definitely need lots of help with the 0.6 testing, pulling in a whole variety of network setups +13:52 < hobbs> ssh '~C' command is nifty +13:52 < laberhorst> will this e another non comnpatible step? +13:53 < Myo9> Anyone knows what nntp servers are up? +13:53 < jrandom> laberhorst: no, 0.6 will be backwards compatible +13:53 < jrandom> Myo9: dunno, they might be up and just be bitten by the 0.5-0 bugs +13:54 < jrandom> the 0.5.0.1 rev should fix a lot of issues, and once its out, upgrading will be highly recommended +13:54 < laberhorst> so just built a test 0.6 and put it to testers +13:54 < cervantes> we can make BT traffic use only outdated routers...that will encourage people to upgrade ;-) +13:54 < laberhorst> so big upgrade party tomorrow +13:54 < jrandom> there'll be an announcement on the forum and the list when its ready +13:54 < jrandom> right laberhorst +13:54 < jrandom> heh cervantes ;) +13:55 < laberhorst> *being keen on testing for you* +13:55 < jrandom> BT performance has been pretty good on 0.5, I've seen lots of successful large file transfers on the trackers +13:55 < laberhorst> pload rate: 8.85 kB/s +13:55 < jrandom> (and irc hasn't been affected as it was before, beyond the problems we've been having with duck's tunnel) +13:55 < tracker> Depends on what you call large ;) +13:56 < jrandom> tracker: i'm thinking of a particular 874MB file that has a bunch of successful downloads ;) +13:56 < jrandom> but its true, thats small to some +13:56 < laberhorst> just good old porn +13:56 < laberhorst> i assume ;-) +13:57 < laberhorst> lets hope from tomorrow on, my router won't participate in >3000 tunnels +13:57 < tracker> Ok, that's large. +13:57 < laberhorst> or, if so, the network IS large +13:57 < jrandom> heh laberhorst +13:58 < jrandom> ok, anyone have anything else for the meeting? +13:58 < laberhorst> btw, if participate in >3000 a synonym for a good reliable router in i2p with fast connection? +13:58 <+detonate> i'm putting boondock saints up after i grab house tonight :) +13:59 <+detonate> that'll be a good 4.1gb :) +13:59 * laberhorst just wants to thank the developers for fast bug squashing +13:59 <+detonate> there seems to be lots of demand +13:59 < laberhorst> oh, some DVD images are here, to +13:59 < hobbs> detonate: ooh, right. House. :) +13:59 < tracker> cervantes, did you already upgrade to phpBB 2.0.12 +13:59 < laberhorst> but wait till 0.5.0.1 is out +13:59 <+detonate> should give 0.5.0.1 a good shakedown too +14:00 <+detonate> yeah +14:00 <+detonate> i intend to +14:00 < jrandom> only people who already own legal copies of those files should download them, of course. thats just for testing +14:00 < jrandom> *cough* +14:00 < tracker> rofl +14:01 * jrandom notes mpaa.i2p +14:01 <+detonate> heh +14:01 < laberhorst> oh, i can built iso images from debian, fedora, suse, pictures I made,... +14:01 < laberhorst> so a lot of legal material +14:01 < laberhorst> if you just want to test, /dev/random is VERY large +14:01 < Ragnarok> not always +14:02 < laberhorst> btw, for lonely weekends: cat /dev/random | grep linux :-) +14:02 < jrandom> heh +14:02 < frosk> /dev/random runs empty all the time, i prefer /dev/urandom :) +14:02 < frosk> or the new, improved /dev/jrandom +14:02 < jrandom> nah, that dumps core all the time +14:03 < jrandom> and needs its nightly rest +14:03 < Ragnarok> what's the best way to generate entropy for /dev/random? +14:03 < laberhorst> we should really built the "get jrandom a few beers" fund +14:03 < frosk> call it rest or entropy gathering :) +14:03 < hobbs> Ragnarok: Depends on what you really mean. Getting a hardware RNG would be more or less the "best" way :) +14:03 < jrandom> Ragnarok: depends on your OS (and whether you have hardware ;) +14:04 < tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Allways nice ;) +14:04 < jrandom> we'll actually be bundling in a fortuna implementation one of these builds, and will need to dig around for various entropy sources +14:04 < Ragnarok> without hardware :P +14:04 < susi23> . o O ( I thought somebody using i2p knows why he should not use /dev/urandom ) +14:05 < cervantes> tracker: the security exploits covered in 2.0.12 my mod_rocinante inadvertantly fixes, so I haven't bothered to upgrade yet +14:05 < hobbs> susi23: when it's just for mischief, I think it's alright ;) +14:05 < ant> <Nolar> who here does the python BT port? +14:05 < jrandom> Nolar: that'd be duck +14:06 * duck whistles +14:06 < ant> <Nolar> duck: why did you guys change the request block size to 128k ? +14:06 < susi23> . o O ( next one suggests: while true; do echo $RANDOM >> largefile; done ) +14:06 < ant> <Nolar> that's why az cant seed to you +14:06 < tracker> cervantes: Ok +14:06 < ant> <Nolar> we block requests > 64k +14:06 < laberhorst> hell, i need more mp3 +14:06 < frosk> susi23: for grepping for linux on an idle evening, /dev/urandom is just fine :) +14:07 < jrandom> ah, did you always? iirc i2p-bt has used 128k for a while +14:08 < ant> <Nolar> yup, been there since the beginning :) +14:08 < ant> <Nolar> any reason 128 is used? +14:08 < ant> * duck looks through cvs log +14:08 < jrandom> keeps the pipeline filled, i2p has some lag ;) +14:08 < jrandom> with 32KB, thats essentially a fixed window size of 1 +14:09 < jrandom> so each message blocks for an ACK, while 128KB allows 4 messages to fly in the rtt +14:09 <@duck> right, maximum allowed slice size according to the BT specs +14:09 < ant> <Nolar> well, there are two ways do deal with this: 1) we raise the limit to 128k on our side, or 2) you simply pipeline more requests +14:09 < cervantes> i2pbt is a little snappier than it used to be...perhaps you can afford to reduce it... +14:10 <@duck> schni, schna, schnappi +14:10 < ant> <Nolar> so, instread of making a single 128k request, send out two 64k ones for example +14:10 < hobbs> duck: haha... that thing has gotten around the world. +14:10 <@duck> why do you block 128k? +14:11 < cervantes> *shudder* europop +14:11 < laberhorst> duck: pls. be quiet OR i shoot you down! +14:11 < tracker> Sometimes I regret that I learned german some years ago... +14:11 < laberhorst> no europop, really not POP +14:11 * cervantes orders the UK to repel borders before a song like that enters the charts +14:11 < laberhorst> tracker: don't care, its ok +14:12 < ant> <duck> its now (2^17)-13 +14:12 < ant> <Nolar> duck: well, the limit has been there for a while, but one good reason is that 128K blocks take a while to upload.....16KB (our default) allows for finer request control +14:12 < ant> <duck> 13 bytes being the bittorrent command length +14:12 < ant> <duck> would have no problem to (2^16)-13 +14:12 < laberhorst> some music is really ridiculous, but real industrial music, boh, no +14:13 < ant> <duck> or go back to the default? +14:13 < jrandom> reducing it to 64KB seems the simplest (is that a cli param atm?) +14:13 < ant> <duck> --download_slice_size +14:14 < ant> <Nolar> well, my question is, do you have a compelling reason for sticking to 128K blocks, which seems a bit large to me, especially for i2p +14:14 < ant> <Nolar> rather than just pipelining multiplpe smaller requests? +14:14 < ant> <duck> I have no reason. +14:14 < tracker> laberhorst: Sometimes I catch some of the german channels via satellite. Especially viva and that "Theater Kanal" are really gruesome... +14:15 < ant> <Nolar> one problem with large blocks is that once i choke you, i still have to finish sending that 128k chunk +14:15 < jrandom> I don't recall whether the vanilla bt knows how to pipeline, but it should be simple enough (especially since i'm not doing it ;) +14:15 < ant> <Nolar> which can take a while +14:15 < laberhorst> tracker: viva is only interesting while "hard rock" time, all other times "please ignore", and theater, i don't know +14:15 < jrandom> with i2p, 128KB isn't really that large, since there's an inherent lag on the order of seconds +14:15 < ant> <Nolar> which can mess with the chunk/unchoke +14:16 <@duck> jrandom: does it still make sense to subtract the bittorrent 13 byte overhead so it fits in a sam message? +14:16 < jrandom> duck: nah, since the streaming lib already reduces it further into 16KB messages, so just have it be 64KB +14:17 <@duck> ok, 2**16 it is +14:17 < jrandom> (and then the tunnels break those 16KB messages into 996 byte fragments..) +14:17 < ant> <Nolar> the problem with 128k, is that if i'm uploading at say 12 k/s, then it'll take me 10+ seconds to finish that block +14:18 < cervantes> wow that's almost as long as the lag on irc... +14:18 < jrandom> which is 1-10 RTTs (while on the normal net, 10-500) +14:18 <+detonate> i was all set to use 512K blocks +14:18 < ant> <Nolar> you might also experiment with pipelinng 16kb blocks +14:18 < jrandom> heh +14:18 <+detonate> so 64 is preferred? +14:19 < ant> <Nolar> all bt clients afiak use 16KB blocks +14:19 < ant> <duck> fixed in CVS; +14:19 < jrandom> wikked, thanks duck! (and Nolar!) +14:19 < ant> <duck> expect it to appear in the 0.1.8 release together with some sam i2cp tuning +14:19 < tracker> laberhorst: It's complete name is "ZDF Theater" or so. And well they say they send a high level cultural program. I really hope that what they send isn't the best the german culture can offer ;) +14:19 < jrandom> ok, heh, I just remembered we're still in a meeting +14:19 < jrandom> anyone else have anything for the meeting? +14:20 < ant> <Nolar> so if we want a 128k chunk, we just make 8 simult requests +14:20 < susi23> . o O ( and discard the 448 left bytes? ) +14:20 < jrandom> right right +14:20 < laberhorst> tracker: oh, that is small side channel... arte or 3sat is really more interesting +14:20 < laberhorst> and arte is german/french :-) +14:20 < ant> <Nolar> if the uploader can fill such a request, all 128k should be pushed into the i2p pipe stream +14:20 < jrandom> cool +14:21 < cervantes> . o O ( wonders why he can hear everything susi is thinking ) +14:21 < ant> <Nolar> so, it might be worth experimenting with 16KB vs 32KB vs 64KB blocks sizes +14:21 < jrandom> aye +14:21 < jrandom> as long as its pipelined, i2p doesnt care +14:21 < ant> <Nolar> great +14:22 < jrandom> the speed at 16KB without pipelines is pretty bad though, or at least it used to be +14:22 < tracker> laberhorst: Ok, I'll try if I can catch arte in the next days... +14:22 < ant> <duck> I suggest leaving this tweaking for 0.2 +14:22 < ant> <duck> since it will include the bittorrent 3.9.1 improvements +14:22 < jrandom> yeah, DTSTTCPW +14:22 < susi23> . o O ( oh thats easy... people are so predictable... ) +14:23 < ant> <duck> which might completely restructure the network code +14:23 < cervantes> http://www.gavelstore.com +14:24 < jrandom> ok, I think thats it for the moment, people should check the list and the site in a few hours as the 0.5.0.1 rev will be coming out soon +14:24 < ant> <Nolar> ya, i can see how single 16kb requests would be slow +14:24 * jrandom downloads a gavel +14:24 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/130.rst b/i2p2www/meetings/logs/130.rst new file mode 100644 index 00000000..2a5f409c --- /dev/null +++ b/i2p2www/meetings/logs/130.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 22, 2005 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/131.log b/i2p2www/meetings/logs/131.log new file mode 100644 index 00000000..12515675 --- /dev/null +++ b/i2p2www/meetings/logs/131.log @@ -0,0 +1,366 @@ +13:05 <@jrandom> 0) hi +13:05 <@jrandom> 1) 0.5.0.1 +13:05 <@jrandom> 2) roadmap +13:05 <@jrandom> 3) addressbook editor and config +13:05 <@jrandom> 4) i2p-bt +13:05 <@jrandom> 5) ??? +13:05 <@jrandom> 0) hi +13:05 * jrandom waves +13:05 <@duck> hi +13:05 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000616.html +13:05 < null> hi +13:05 <@jrandom> (yeah, i'm late this week, off with my head) +13:06 <@jrandom> while y'all speedreaders dig through that, perhaps we can jump into 1) 0.5.0.1 +13:07 <@jrandom> 0.5.0.1 is out, and gets rid of the most ovious bugs from 0.5, but as we've seen, there's still work to be done +13:07 <@jrandom> (current cvs stands at 0.5.0.1-7, I expect at least -8 or -9 before we hit 0.5.0.2) +13:07 <+ugha2p> Hi. +13:08 <+ugha2p> Does CVS HEAD fix that 100% CPU issue? +13:08 <@jrandom> yes, -7 should get the last remnants of it +13:08 <@duck> Does CVS HEAD fix that OOM issue? +13:08 <+detonate> hi +13:08 <@jrandom> no, the OOM is still being tracked down +13:09 <@jrandom> actually... is there a Connelly in the house? +13:09 < ant> <jrandom> nope +13:09 <@jrandom> bugger +13:09 <+ugha2p> jrandom must be going crazy, he is having a dialogue with himself. +13:09 <@jrandom> ok, well, we can see what will be done to get rid of the OOM. its definitely a show stopper, so there won't be a release until its resolved one way or another +13:10 <+detonate> just in time for the meeting +13:11 <@jrandom> thats about all i have to say for the 0.5.0.1 stuff - anyone else have anything they want to mention/ask/discuss? +13:12 <+ugha2p> jrandom: Err, I haven't actually seen the CPU issue with 0.5.0.1, but it happened twice when I tried 0.5.0.1-5. Am I missing something? +13:12 <+ugha2p> I downgraded back to 0.5.0.1 as a result. +13:13 <+detonate> i had a question, the shutdown seems to take a very long time, and the memory usage spikes by about 40mb during that time +13:13 <+detonate> was wondering if you knew why +13:14 <+detonate> the immediate one, obviously +13:14 <@jrandom> it could happen with 0.5.0.1, you just hadn't run into it. +13:14 <@jrandom> (its not a common occurrence, and it only hits some people in odd situations) +13:14 <@jrandom> detonate: very long, as in, more than the usual 11-12 minutes? +13:14 <+ugha2p> Well, it hit me twice during a 8-hour period. +13:15 <+detonate> once all the participating tunnels are gone +13:15 <+ugha2p> jrandom: Is it supposed to use up all the CPU and lose all the leases until restarted when that bug occurs? +13:16 <@jrandom> ugha2p: thats a typical result from the bug, yes +13:16 <+detonate> hmm +13:17 <@jrandom> (it happens when the # of tunnel build requests consume sufficient CPU to exceed the time to satisfy a request, causing an additional request to be queued up, etc) +13:17 <+ugha2p> Must have been an extreme coincidence that it only happened to me while on 0.5.0.1-5. +13:18 <@jrandom> ugha2p: its happened to some people repeatably on 0.5.0.1-0, but is fixed in -7. you can stick with -0 if you prefer, of course +13:18 < cervantes> it was a wonderous godsend +13:18 <+ugha2p> jrandom: I'll try out -7. +13:18 <@jrandom> cool +13:19 <+ugha2p> Although I'm already feeling guilty for giving a bumpy ride to the wiki users so far. :) +13:20 <+ugha2p> One more thing, have you documented the bulk/interactive tunnel types anywhere? +13:20 <+ugha2p> (Except for the source ;) +13:20 <@jrandom> in the changelog. the only difference is a max window size of 1 message +13:20 <+ugha2p> Oh, okay. +13:21 <@jrandom> ok, anything else on 0.5.0.1, or shall we move on over to 2) roadmap? +13:21 <@duck> move on! +13:21 <@jrandom> consider us moved +13:22 <@jrandom> roadmap updated. 'n stuff. see the page for details +13:22 < cervantes> eeh, duck ankle bites +13:23 <@jrandom> i'm thinking of pushing some of the strategies from 0.5.1 to 0.6.1 (so we get UDP faster), but we'll see +13:23 <@jrandom> anyone have any questions/comments/concerns/frisbees? +13:23 <+detonate> have you heard from mule lately? +13:23 <+detonate> speaking of udp +13:24 <@jrandom> nope, he was fairly ill last i heard from 'im +13:24 <+detonate> :/ +13:24 < jnymo> udp would kick ass +13:25 <@jrandom> s/would/will/ +13:25 <@jrandom> hopefully he's off having fun instead though :) +13:25 <+ugha2p> jrandom: What kind of changes would the bandwidth and performance tuning include? +13:26 < jnymo> so, udp basically means connectionless.. which means.. bigger network, right +13:26 <+detonate> udp introduces all sorts of difficulties along with that +13:26 <@jrandom> ugha2p: batching the tunnel message fragments to fit better into the fixed 1024byte tunnel messages, adding per-pool bw throttles, etc +13:27 <+detonate> but yeah +13:27 <@jrandom> detonate: it won't be so bad, the token bucket scheme we have now can handle async requests without a problem +13:27 <@jrandom> (we just obviously wouldn't use the BandwidthLimitedOutputStream, but would ask the FIFOBandwidthLimiter to allocate K bytes) +13:27 <+ugha2p> Would the first one really make much difference? Per-pool throttling doesn't sound urgent. +13:28 <+detonate> that's good then +13:28 <@jrandom> ugha2p: likely, yes. you can see the exact #s involved by going to /oldstats.jsp#tunnel.smallFragments +13:29 < bla> detonate: How's progress on the reassembly? +13:29 <+detonate> really stalled +13:30 <@jrandom> ugha2p: though its largely dependent upon the type of activity, of course. chatty comm has more to gain, but bulk comm already fills the fragments fully +13:30 <+ugha2p> jrandom: Ok. +13:30 <+ugha2p> Right. +13:31 <+detonate> i stopped working on it completely and started working on the addressbook-editor +13:31 <+detonate> there's probably a really efficient, well-researched way of doing that sort of thing, but i haven't come across it +13:31 < jnymo> will upd mean people behind nats can get through now? +13:31 <@jrandom> some jnymo +13:31 < jnymo> and use i2p? +13:32 <@jrandom> but first we need to get it to work with udp at all, then we start adding the firewall/nat punching, then the PMTU, etc +13:32 < jnymo> that'll be a boon +13:33 <+detonate> of course if anyone has suggestions on what to do, i'd appreciate them +13:33 <+ugha2p> jrandom: How would UDP help people behind NATs? +13:34 < bla> detonate: TCP (on the regular net) does reassembly. Can those concepts be carried over to the I2P UDP reassembly? +13:34 <+detonate> i haven't looked into how tcp does it +13:34 <@jrandom> ugha2p: there's a lot of trickery we can pull off with consistent port #s, etc. lots of code & docs out there +13:35 <@jrandom> bla: we'll certainly be using some level of UDP reassembly along tcp-SACK lines +13:35 <+detonate> but if you're going to handle most of what tcp does, you might as well go the NIO route and actually use it +13:35 <+detonate> saving the hassle +13:35 <@jrandom> no, there's substantial reason for why we do want both some reassembly/retransmission and not tcp +13:36 <+detonate> well, the threads thing +13:36 <@jrandom> the transport layer will not need to be fully reliable or ordered, just semireliable and unordered +13:37 <+ugha2p> Can we also expect a drop in memory usage because of fewer threads? +13:37 <@jrandom> yes +13:37 <+ugha2p> A significant drop +13:38 <+ugha2p> ? +13:38 <@jrandom> substantially. (as well as a drop in memory usage, based off whatever the current OOM is coming from ;) +13:38 <+ugha2p> Right. +13:39 <@jrandom> ok, anything else on 2) roadmap? +13:39 < bla> jrandom: Yeah. +13:40 < bla> jrandom: Will detonate be doing the UDP stuff now? Or else, who will? +13:40 <@jrandom> its a team effort for all who can contribute :) +13:40 <+detonate> heh, i plan on working on udp stuff more, it's less boring than watching tv +13:41 <@jrandom> heh w3wt +13:41 < bla> jrandom: I understand. But for a moment it looked like detonate dropped the project ;) +13:42 <@jrandom> its on the roadmap, it will be done +13:42 <+detonate> sorry for the confusion +13:43 <@jrandom> ok anyone else have anything on 2) roadmap, or shall we mosey on over to 3) addressbook stuff? +13:44 <@jrandom> ok, detonate wanna give us an overview/status report on the editor? +13:45 < bla> detonate: (np) +13:45 <+detonate> ok +13:45 <+detonate> the current state of the editor is here: +13:45 <+detonate> http://detonate.i2p/addressbook-editor/current-state.html +13:45 <+detonate> it still doesn't do any actual editing +13:45 <+detonate> and currently i'm working on the table at the bottom +13:46 <+detonate> i need to read a couple chapters of my jsp book, but after that, you should be able to use it to add/modify entries in the hosts.txt and subscriptions quite easily +13:47 <+detonate> i took a break from it the last 24 hours or so, so that's why there hasn't been much progress +13:47 <+detonate> that's pretty much all +13:47 <@jrandom> w3wt +13:48 < bla> detonate: Looks good +13:49 <@jrandom> yeah, mos' def', I'm looking forward to a way to manage the entries /other/ than just hcaking the hosts file +13:49 <+detonate> thanks +13:49 <+detonate> that's the first time i've used jsp for anything +13:50 <@jrandom> cool +13:51 <@jrandom> oh, i hadn't realized there was the overlap here for subscription management - perhaps smeghead's work can fit in with this as well +13:51 <@jrandom> smeghead: you 'round? you seen this yet? +13:51 < jnymo> detonate: will there be collision detection and what not? +13:51 <@smeghead> actually i only hashed out some skeleton code on the addressbook console, nothing useful +13:51 <+detonate> yeah, i got tired of that, thank duck for suggesting the idea :) +13:51 <@smeghead> i got sidetracked on the TrustedUpdate thingy +13:52 <@jrandom> ah cool :) +13:53 * jrandom likes sidetracking to add new features +13:53 < bla> smeghead: You mean 1-click updates of I2P from _within_ I2P? +13:53 <@smeghead> so luck, not laziness (at least this time :) +13:53 < cervantes2p> bla: 2 click at least ;-) +13:54 <@jrandom> bah, we can get it down to 1 (reject if bad sig/invalid/etc ;) +13:54 <+detonate> yeah, there will be collision detection, that's currently what i'm working on +13:54 <@jrandom> detonate: doesnt the addressbook itself take care of that? +13:54 <@jrandom> detonate: i thought what you're doing just edited the files? +13:55 <@jrandom> (the files will be uniq'ed by the addressbook) +13:55 <+detonate> i mean, showing you the collisions from the logs and handling that +13:55 <@jrandom> ah +13:55 <@jrandom> ok cool +13:55 <+detonate> i assume that's what jnymo is talking about +13:55 < Ragnarok> hm, is there anything I can do to make your life easier? :) +13:55 <+detonate> so you can say "replace entry" with the colliding one of your choice +13:55 <@jrandom> nice! +13:58 <@jrandom> Ragnarok: iirc detonate was able to parse out the logfile pretty easily. do you forsee that format changing? +13:58 < jnymo> detonate: pretty much, yea +13:58 < jnymo> now, is this tied into i2p tightly? How easily can i put a link+key from my browser into my address book? +13:59 <+detonate> yeah, don't change the format, that'll break everything +13:59 < Ragnarok> the format is highly unlikely to change +14:00 < Ragnarok> though more things may get logged in the future +14:00 <@jrandom> jnymo: the eepproxy doesn't have any hooks into detonate's editor atm, but we could add something down the road +14:00 <+detonate> although if you modified the Conflict lines, that would make them easier to parse +14:00 < cervantes2p> possibly something my firefox plugin could do +14:00 <+detonate> right now there are lots of human readable words that get in the way +14:00 < Ragnarok> modify how? +14:00 <@jrandom> (for instance, perhaps i2paddresshelper might redirect to an editor page) +14:00 < cervantes2p> "click here to add this to your addressbook" +14:00 < Ragnarok> ah... I want to be nice to the humans, though +14:00 <+detonate> <date>=<host>=<source>=<new destination> would be superior +14:01 <@jrandom> cervantes2p: that going to work like google's page rewriter? :) +14:01 <+detonate> well, that's what the addressbook-editor is for :) +14:01 <+detonate> it's really not an issue, i've got it covered +14:01 < cervantes2p> jrandom: nah...just have it in the link context menu +14:01 <@jrandom> ooOOoo +14:01 <+detonate> as long as nothing changes radically, things should keep working smoothly +14:02 < cervantes2p> of course I could add a rewriter...but that's just breaks people's page layouts ;-) +14:02 <+detonate> oh, one thing you could do +14:02 <+detonate> because it conflicts with what i do +14:02 <+detonate> make sure all the entries for the hostnames are all-lowercase +14:02 <+detonate> since Legion.i2p is in there +14:02 < cervantes2p> I do want to add a "non i2p link highlighter" +14:02 <+detonate> and i run them all through toLowercase() +14:02 <@jrandom> ah that'd be neat cervantes2p +14:03 <@jrandom> (be sure to only toLowercase the names, base64 is case sensitive ;) +14:03 <+detonate> yeah, only the names +14:04 < jnymo> context menu would be ideal +14:04 <@jrandom> (dont forget the flying ponies!) +14:04 < Ragnarok> I've made address comparisons non-case sensitive in my local branch... I should commit that... +14:04 <+detonate> /make all the hostnames lowercase +14:04 <+detonate> pair[0] = pair[0].toLowerCase(); +14:05 <+detonate> there, in black and white +14:05 <+detonate> it just does the hostnames +14:05 <@jrandom> aye Ragnarok, give us the goods :) +14:05 < jnymo> why do i always feel i'm the one riding the flying ponies :( +14:06 <@jrandom> thats 'cause you're hoggin' 'em jnymo ;) +14:06 < cervantes2p> jnymo: don't discuss your domestic "arrangements" in a meeting +14:07 <@jrandom> ok, lots of cool stuff going on within the addressbook & editor. any eta on when we can beta things detonate? (this week, next week, etc) +14:07 < jnymo> heh +14:07 <+detonate> well, as soon as you can get it to work in jetty, you can put it in beta i think +14:07 * jnymo pulls out his p32-space-modulator +14:07 <@jrandom> it works in jetty +14:07 <+detonate> i have no idea how to get netbeans to precompile them and put them in the war +14:08 <+detonate> as long as people don't change the names of the files in config.txt, it should work hopefully without bugs +14:08 <@jrandom> ok, we can work you through ant to take care of things +14:08 <+detonate> ok +14:08 <+detonate> cool +14:08 < cervantes2p> detonate: do what I did, take jrandom's code....strip out everything you don't need, crowbar in your own code and run the ant build script ;-) +14:08 <@jrandom> heh +14:09 <@smeghead> detonate: i know a thing or two about ant, yell if ya get stuck +14:09 <+detonate> feel free to add it to your release +14:09 <+detonate> if you know how to do that +14:09 < MichElle> s/you don't need// +14:09 < Ragnarok> addressbook has a very simple build script, if you want to take a look at that +14:10 <+detonate> i need the section that precompiles jsps +14:10 <+detonate> that's missing from mine +14:10 <+detonate> although it does compile them, it just doesn't merge them, and the entry to test compile them isn't in build.xml +14:10 <@jrandom> detonate: check out the precompilejsp targets in routerconsole, that'll get you started +14:10 <+detonate> and i need to figure out where to put -source 1.3 etc in +14:10 <@jrandom> (and the <war> task) +14:11 <+detonate> yeah, we can sort things out later this evening +14:11 <@jrandom> aye +14:11 < cervantes> yup that's how I managed it...and I don't know ANY java or jsp ;-) +14:11 <@jrandom> ok, if there's nothing more on 3) addressbook stuff, moving on to 4) bt stuff +14:12 <@jrandom> duck/smeghead: wanna give us an update? +14:12 <@duck> k +14:12 <@duck> last week we spoke with Nolar from Azureus about fixing some compatibility problems +14:12 <@duck> with the release of 0.1.8 as result +14:12 <@duck> this week has been mostly about communication +14:12 <@duck> with fellow developers, with forum admins and with users +14:13 <+detonate> does anyone know if the aznet plugin can host torrents again? +14:13 <@duck> the FAQ has been updated based on input from the forum, thanks for those who contributed +14:13 <@duck> also there has been some miscommunication and confusion +14:13 <@jrandom> detonate: word on the street is yes +14:13 <@duck> like legions spork +14:13 <+detonate> excellent +14:13 <@duck> I believe that changing the name of it will prevent further problems there +14:13 <@duck> . +14:14 <@jrandom> r0xor duck +14:14 * MichElle applauds duck +14:14 < MichElle> duck: you work very hard +14:14 < jnymo> yea, why not i2p-bt_extractor or some shit? +14:15 <@jrandom> any word on the later 0.2 stuff, or is that to be addressed after 0.5.0.2/etc? +14:15 <@smeghead> don't applaud yet, you don't know what we're naming it >;-} +14:15 <@jrandom> heh +14:15 * jnymo claps +14:15 <@duck> tell us! +14:15 <@jrandom> i2p-flying-pony-torrent +14:16 <+detonate> heh, are we hiding it now by changing the name? +14:16 < MichElle> again with the ponies +14:16 <@smeghead> it's top-secret for now, we don't want to get sued +14:16 < jnymo> what a debocle +14:17 * bla makes sign for MPAA: "Sue me, if you can..." +14:17 <@smeghead> duck and i have agreed 0.2 will be the first version with the new name +14:17 <+detonate> i2p-communism +14:17 <@duck> released spring 2006 +14:17 <@jrandom> heh +14:17 <@duck> . +14:18 <@smeghead> based on my current workload and the fact that i'm moving this week, i don't expect to get any hacking done on 0.2 for a few days, i don't know what duck's near-term schedule is like +14:18 <@duck> been doing 8 hours of C++ pointer fixing +14:19 <@duck> so not much here either :) +14:19 <@jrandom> 'k but something we can perhaps look forward to along side 0.6 (or 0.5.1 if we're lucky?) +14:19 <@jrandom> yikes, fun fun fun +14:19 <@duck> before 2.0 atleast +14:19 <@smeghead> i'd estimate a month or so, just a wild guess, what do you think duck +14:19 <@duck> yeah +14:19 <@jrandom> cool +14:19 <@duck> ballpark +14:20 <@smeghead> the thing is we'd like to wait until the release of the official BT 4.0 +14:20 <@jrandom> its ok, we know how schedules go ;) +14:20 <@smeghead> so we can sync 0.2 up-to-date with that +14:20 < MichElle> duck has many things on his plate, indeed +14:20 <@smeghead> 4.0 appears imminent +14:20 <@jrandom> ah, really smeghead? cool +14:20 <@duck> smeghead: that is just the official excuse :) +14:20 < MichElle> but he is a hard worker +14:21 <@duck> I am for 5) ??? +14:21 <@jrandom> almost there... +14:21 <@jrandom> legion: any updates on your bt client? progress, etc? +14:21 <@smeghead> source code? +14:22 <@smeghead> (in a zip, not an .exe) +14:22 < cervantes> so the next wave of releases then +14:22 <@jrandom> hmm, legion seems to be idle, ok perhaps we can get an update later +14:22 < cervantes2p> damn huge lag +14:23 <@jrandom> so, movin' on over to 5) ??? +14:23 < cervantes> *ahem* w00t +14:23 <@jrandom> cervantes2p: nah, you're just slow ;) +14:23 <@jrandom> ok, anyone else have anything to bring up? +14:23 < cervantes2p> I said those things like 5 minutes ago +14:23 <+ugha2p> jrandom: The mailing list footer still uses the i2p.dnsalias.net address. Perhaps you should update it to reflect dev.i2p.net? :) +14:23 * cervantes2p feeds his router's hamster +14:24 <@jrandom> ah, yeah, prolly ugha2p +14:24 * jrandom has some sysadmin work i've been avoiding for a while (like, oh, moving things to the new srever...) +14:24 < MichElle> I have a concern +14:24 < MichElle> regarding transparency +14:24 <@jrandom> sup MichElle? +14:25 < MichElle> for purposes of full transparency, I will declare here that identiguy has suggested jrandom could in fact be employed by the NSA +14:25 <+detonate> oh, i've noticed 190 routers, how close are we to the thread limit right now? +14:25 * jnymo wonders about other help people can do +14:25 < jnymo> (still looking into the php thing, duck ;) +14:25 <@jrandom> heh MichElle +14:25 < MichElle> his 'convenient' ability to work 24/7 on i2p is quite suspicious, indeed +14:25 < MichElle> anyway +14:25 < MichElle> that's all I wanted to say +14:25 < MichElle> keep your eyes on jrandom +14:26 < MichElle> his gentle and warm facade may be just that. +14:26 <+ugha2p> detonate: There are no theoretical thread limits, it will just consume all available resources until it crashes. :) +14:26 < jnymo> facade +14:26 <@jrandom> detonate: some OSes/ulimits may throttle @ 256, but win98 is already past the 100 TCP connections limit anyway +14:26 < cervantes2p> I can give a quick update on the firefox plugin. The I2P Mail notifier is working now, as is the news reader and basic router controls. I'm busy with tediously building configuration screens now ( http://freshcoffee.i2p/fire2pe_i2pmail_prefs.jpg ) +14:27 < jnymo> MichElle, if the source code is sound, then who cares? +14:27 <+detonate> oh, is the firefox plugin released? +14:27 < MichElle> jnymo: it ruins the mood a little +14:27 < cervantes2p> and I want to implement a downloader/install service that ties into smeghead's new updater verifier before I release +14:27 < ddd> hi channel +14:28 <+detonate> ok +14:28 <@jrandom> w0ah! kickass cervantes2p +14:28 <@jrandom> it looks really nice +14:28 <+detonate> hi ddd +14:28 < cervantes2p> but getting close now...probably another couple of weeks... +14:28 < MichElle> sort of like how running windows would still not be cool, even if microsoft open-sourced it +14:28 <+detonate> that plugin looks cool +14:28 < MichElle> back to the meeting, though ... +14:28 <@smeghead> TrustedUpdate may be done this week hopefully, before i move +14:28 <@jrandom> cool +14:29 < ddd> ? +14:29 < ddd> is i2p the only anonymous chat? +14:29 <@jrandom> hi ddd . weekly dev meeting going on +14:30 < cervantes2p> 'lo ddd, we're just finishing a meeting...stick around we'll be done in a couple of minutes +14:30 < ddd> are there other projects like i2p? +14:30 <@smeghead> ddd: type /list then take your pick +14:30 < ddd> ok +14:30 < ddd> no i mean on other networks +14:30 <@jrandom> ok, anyone else have anything to bring up for 5) ??? +14:30 <@smeghead> ddd: ask in #i2p-chat +14:30 < ddd> ok i let you guys finish +14:30 <+detonate> has anyone successfully run i2p in openbsd yet? +14:31 <@jrandom> ddd: http://www.i2p.net/how_networkcomparisons +14:31 < ddd> ok +14:31 <+detonate> i was thinking of starting that fiasco up again +14:31 <@jrandom> detonate: dunno +14:31 < jnymo> oh yea.. who was doing the bsd i2p distro, and which bsd was it? +14:31 <@jrandom> heh cool detonate, let us know how it goes +14:31 <@jrandom> jnymo: lioux packaged 'er up for fbsd +14:32 <@smeghead> i2p would never ship with openbsd :) +14:32 <+detonate> sure +14:32 < jnymo> woord.. wasn't someone going to do a i2p oriented distro? +14:32 <+detonate> yeah, there's a port in freebsd now +14:32 <+detonate> it's scary +14:32 <+detonate> heh, someone wanted to have a knoppix cd that ran i2p +14:32 <@jrandom> jnymo: after i2p is rock solid, it'd be worthwhile to explore packaging on distros/microdistros, yeah +14:32 <+detonate> who knows why +14:33 <@smeghead> jnymo: i remember that, i think it was going to be a knoppix/i2p, can't recall who was talking about it +14:33 <@jrandom> detonate: netcafe +14:33 <+detonate> ah +14:34 <@jrandom> ok, anything else for the meeting? +14:34 < MichElle> what the fuck is an i2p 'oriented' distro +14:34 < MichElle> tor, i2p, and freenet ? +14:34 < MichElle> there is no purpose +14:34 < MichElle> the bandwidth requirements cancel the programmes out +14:34 < MichElle> is jrandom theo de raadt ? +14:34 < cervantes> a slightly camp distribution +14:34 < jnymo> a completely anonymized distro +14:35 < cervantes2p> jrandom: I guess not :) +14:35 < MichElle> jrandom: nothing +14:35 * jrandom winds up +14:35 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/131.rst b/i2p2www/meetings/logs/131.rst new file mode 100644 index 00000000..10362736 --- /dev/null +++ b/i2p2www/meetings/logs/131.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 1, 2005 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/132.log b/i2p2www/meetings/logs/132.log new file mode 100644 index 00000000..ef6bbe62 --- /dev/null +++ b/i2p2www/meetings/logs/132.log @@ -0,0 +1,359 @@ +13:06 <@jrandom> 0) hi +13:06 <@jrandom> 1) 0.5.0.2 +13:06 <@jrandom> 2) mail.i2p updates +13:06 <@jrandom> 3) i2p-bt updates +13:06 < legion> so it's related to the irc servers? +13:06 <@jrandom> 4) ??? +13:06 <@jrandom> 0) hi +13:06 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html +13:07 < fedo> hi +13:07 <+postman> hi +13:07 < frosk> goodday +13:07 <@jrandom> legion: no, related to i2p bugs, being worked on +13:07 < bla> hi +13:07 < legion> ok +13:07 <@jrandom> speaking bugs being worked on, lets jump on in to 1) 0.5.0.2 :) +13:07 < cervantes> 'lo +13:07 < cervantes> -- Disconnected +13:08 <@jrandom> heh +13:08 < ant> <mihi> hi all +13:08 <@jrandom> 0.5.0.2 is out, and while your irc connection may lag at times, it'll recover ;) +13:08 <@jrandom> woah heya mihi +13:09 < cervantes> hey mihi +13:09 <@jrandom> the status notes give a general overview of where things are and the most immediate priorities +13:10 <@jrandom> the scary thing I'm trying to track down can be seen on http://localhost:7657/oldstats.jsp#router.invalidMessageTime +13:10 < bla> As for me, I can say that 0.5.0.2 already improved realiability _vastly_ compared to 0.5.0.1: errors where destinations couldn't be contacted almost don't occur anymore +13:10 <@jrandom> those numbers should be very very small, but they're not, unfortunately +13:10 <@jrandom> wikked bla +13:11 <@jrandom> yeah, the 0.5.0.2 is definitely an improvement, and everyone should upgrade ASAP +13:11 < bla> 375,932.22 in the last 10 minutes here.... +13:11 <@jrandom> well, the particular value isn't really the problem, its their frequency +13:11 <@jrandom> (events per period) +13:12 <@jrandom> those messages can likely be attributed to 0.5 routers, and some of it to 0.5.0.1 routers, which is why I want people to upgrade ASAP +13:12 <@jrandom> it may be the case that its something else though, but I'd like to rule it out +13:12 < bla> jrandom: I get about 200 per hour here +13:13 <@jrandom> bla: i've currently got 93 this hour, but peak count much higher (thousands) +13:13 <@jrandom> anyway, this particular stat is published in the netdb +13:13 < bla> jrandom: How about excluding 0.5-0 from the net in software when releasing 0.5.0.3? +13:14 <@jrandom> so we can all look around and see what values other people have ;) +13:14 <@duck> 309,854.24 peak 5,473,314.59 +13:15 <@duck> pasting the wrong one, huh +13:15 <@jrandom> bla: definitely. I added some code in the 0.5.0.2 rev to do soem forward compatability that 0.5.0.1 and 0.5 don't have +13:16 <@jrandom> duck: hard to have a nonintegral # of events ;) +13:16 < bla> jrandom: Good. At least that allows you to test your invalid-messages-are-due-to-0.5-0 hypothesis in a controlled manner +13:16 <@jrandom> bla: aye, though it'd be great if people updated before then ;) +13:17 <@jrandom> (so for those reading at home: http://www.i2p.net/download is your friend ;) +13:17 < maestro^> jr: those numbers for router.invalidMessageTime deviations in ms? +13:17 <@jrandom> maestro^: yes +13:18 <@jrandom> (aka some really insanely skewed values) +13:18 < legion> Here is a little network report [version|Number of nodes][0.5|6][0.5.0.1|39][0.5.0.2|107] +13:18 <@jrandom> yeah, y'all have been great about updating +13:18 < legion> So there is still a few people running 0.5 and many people running 0.5.0.1 +13:18 < maestro^> so any idea where they might be lagging? +13:18 < bla> jrandom: Freenet has a flag in each release that specifies the minimum node version it will communicate with. Is the new forward-compat. code something like that? +13:19 <@jrandom> maestro^: many, many ideas for why 0.5 and 0.5.0.1 users are lagging. +13:19 <@jrandom> bla: similar +13:19 < maestro^> or is it clock drift on nodes? +13:20 <@jrandom> maestro^: clock skew, some serialization bugs, the 100% cpu bug +13:20 <@jrandom> ok, thats generally my focus atm, trying to get the message reliability back up +13:21 <@jrandom> anyone have any questions/comments/concerns on 0.5.0.2? +13:21 < ant> * mihi has a 0.4.2.5 router here on hd not started since dec 22th... but he thinks he'd better delete it... +13:21 <@jrandom> heh +13:21 <@jrandom> yeah, that wont talk to too many routers ;) +13:21 * postman got a backup copy of his last 0.4 installation :) +13:21 < ant> <mihi> question for me 'd be upgrade or delete. +13:22 <@jrandom> delete +13:22 <@jrandom> (backing up any destination keys) +13:22 <@jrandom> there is no upgrade procedure from pre-0.5 anymore +13:22 < legion> Perhaps releasing another update say 0.5.0.2-1 that only allows connections from 0.5.0.2 or newer, would be good? +13:22 <@jrandom> legion: that would segment the network +13:22 <@jrandom> people should juts upgrade. +13:23 <@jrandom> (and we should work around those that dont) +13:24 < legion> yeah until the people running outdated nodes updated ;) +13:24 <@jrandom> segmenting the network hurts us all, not just them +13:25 < legion> Maybe if there was a update notification in the router console or something that let them know they are running outdated versions? +13:25 <@jrandom> yeah, that'd certainly be pretty cool +13:25 <@jrandom> hopefully that can get tied in with the updater as well +13:26 < legion> yeah, I know, segmentation is bad... +13:26 <@jrandom> smeghead is working on some of the key components of that, though not sure if that includes the notification / download +13:26 <@jrandom> (so if anyone wants to help work on that, get in touch!) +13:27 <@jrandom> ok, movin' on to 2) mail.i2p updates +13:27 <@jrandom> postman: ping +13:27 <+postman> yes +13:27 < bla> jrandom: smeghead was doing some signing-related stuff IIRC (so that when you get an update notice, you at least know it's real, and not a phishing/spyware/crap thing) +13:28 * postman takes over the mike +13:28 < legion> hmm, maybe if there was a autoupdate feature built in, where updates would be downloaded through i2p and the nodes would simply download the update, then do a graceful restart. +13:28 <@jrandom> right bla +13:28 < ant> <Gatak> Oh, btw. Would I2P work behind nat even if you cannot open a port? +13:28 <@jrandom> Gatak: not yet. some people will be able to at 0.6, others at 2.0 +13:29 <@jrandom> legion: patches welcome +13:29 < ant> <Gatak> 2.0 heck, that is far on the future =) +13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) +13:29 <+postman> erm, shall i start now? +13:29 < aum> morning all +13:30 <@jrandom> mic is all yours postman (sorry ;) +13:30 <@jrandom> 'lo aum, made it for the meeting +13:30 <@jrandom> (d'oh! /me shuts up again) +13:30 < cervantes> Gatek: http://www.i2p.net/roadmap +13:30 <+postman> first, i wanted to say, that we reached 300 accounts registered at postman.i2p already +13:30 <@jrandom> w00t +13:30 <+postman> the number of mails from/to internet is growing steadily and once more proves that we need to move further +13:31 < cervantes> *squeeeel* +13:31 <+postman> after talking to jr some weeks ago we agreed upon the the release of v2mail together with I2P 1.0 +13:31 <+postman> recent status is: the java based smtp proxy designed to run on every node is finished +13:31 <@jrandom> nice! +13:32 <+postman> the java based POP3 proxy is at 80% with just the maildir engine missing +13:32 <+postman> there will be a webmanager that needs some heavy tweaking still (15% done) +13:32 <+postman> the inter node communication is at 40% - we tested some datarecord exchanging with HTTP/XML +13:33 <+postman> seems to work quite well and fast even +13:33 <+postman> even if a relay node fails/was powered off for a few days, it'll be synced within a few minutes after going back onlione again +13:33 <@jrandom> wikked +13:33 <+postman> i think we're quite n track +13:34 <+postman> one thing is noteable +13:34 < bla> postman: Nice work man! One question: Many nodes cannot receive or send data on port 25 (not directly, anyway). Will node-owners be able to specify this (or will this be auto-detected)? +13:34 < cervantes> cool +13:34 <+postman> bla: later +13:34 <+postman> in v2mail there will be a locally run webapp +13:34 <+postman> with this you can manager your local proxies AND apply for an "relayaccount" +13:35 <+postman> this relayaccount will then be used to associate your addess/domain to the relays +13:35 <+postman> the relays will sync the information automatically +13:35 <@jrandom> cool +13:35 <+postman> even features like the addressbook / public keys and stuff will work with the LOCAL interface +13:36 <+postman> so the idea is to have one centralized manager where you can do all your mailstuff +13:36 <+postman> relevant data is transferred to ONE of the relays and then being synced between the relays +13:36 <+postman> and this webbased manager will run on your very node +13:37 <+postman> when your node is online, the relays will deliver mails queued for your destination/domain/address +13:37 <+postman> it will be delivered to your local smtp proxy +13:37 <+postman> you can even trigger the whole thing with ETRN :) +13:37 < aum> hi again +13:37 < aum> i'd like to raise a discussion point in this meeting, if it's ok +13:37 <+postman> so much for the future folks :) +13:37 <+postman> . +13:38 <@jrandom> sound bitchin postman +13:38 * postman hands back the mike +13:38 <@jrandom> aum: great, should be some time at 4) +13:38 <+postman> yeah, iam ecstatic :) +13:38 <@jrandom> postman: so for the normal user, the smtp proxy will have the local maildir, and the pop3 proxy will read/etc, right? +13:39 <+postman> yeah, the smtp proxy got a MDA +13:39 <+postman> and will deliver the mail into local maildirs +13:39 <+postman> even several accounts/users can be created locally +13:39 < cervantes> postman: will the relays keep track of your quotas etc and propogate such info between each other? +13:39 <+postman> and mapped to accounts of your domain +13:39 <+postman> cervantes: yes, they will +13:39 < septu_ssh> sorry, can I ask postman about payment/anti-spam mechanisms in the new model? +13:40 <+postman> septu_ssh: have you read any of the documents on the webpage? +13:40 <+postman> cervantes: it's not perfect real time +13:40 <+postman> cervantes: but i am fine with a few minutes update of quota information exchange +13:40 < septu_ssh> postman: in the queue for reading :/ +13:40 < septu_ssh> but if it's doc'd, then it's fine +13:40 < cervantes> postman: yeah I figured +13:41 <+postman> septu_ssh: www.postman.i2p/inout.html +13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html +13:41 <+postman> cervantes: this is no drama really - the quota is a sane limit +13:41 < cervantes> postman: even someone being able to send nrelays * quota recipients is no bad thing +13:41 * septu_ssh is bungle +13:41 <+postman> cervantes: yep +13:42 <+postman> the goal is just to stop anybody from really abusing the service +13:42 <+postman> in the tests i had 3 relays have been really fast +13:42 <@jrandom> postman: i forget, will this have support for the local smtp relay talking directly to someone else's smtp relay, rather than bouncing through your nodes? +13:42 <+postman> cervantes: within 10 secs they have been synced :) +13:43 <@jrandom> (or perhaps thats just for later) +13:43 <+postman> jrandom: the i2p mail relays will be operated by several ppl and are the preferred dests for routing mail +13:43 < cervantes> postman: you could introduce an exponential delay to the send queue +13:43 < cervantes> if it becomes an issue +13:43 <+postman> jrandom: so sending to other destinations could be handy under certain circumstances +13:44 <@jrandom> aye, though dangerous under others +13:44 < cervantes> so the more mail you send the greater the time the mail gets queued for...should give the relays time to catch up +13:44 <+postman> jrandom: but if a node's owner discloses his IMIO destination he could be spammed w/o control :) +13:44 <@jrandom> exactly +13:44 <@jrandom> otoh, same goes if the i2p mail relays are hostile +13:45 <+postman> jrandom: indeed, it's a WOT like construction +13:45 <@jrandom> </tinFoil> +13:45 <+postman> jrandom: i cannot stop a relay operator from distributing a quota of 0 for your address +13:45 <@jrandom> 'k great. yeah, no need to worry about it for now +13:45 <+postman> :) +13:46 <+postman> ok +13:46 <+postman> . +13:46 <@jrandom> ok cool, thanks for the update. some really exciting stuff +13:46 <@jrandom> ok, swinging on to 3) i2p-bt updates +13:46 <@jrandom> duck: ping +13:46 <@duck> hi +13:47 <@duck> Yesterday BitTorren 4.0.0 was released +13:47 < ant> <dm> sounds german +13:47 <@duck> which we more or less waited for before starting on 0.2 +13:47 <@duck> wrote a tasklist / todo: http://pastebin.ca/raw/7037 +13:47 <@duck> (sorry my www is currently down) +13:48 <@jrandom> cool +13:48 < legion> what sort of timetable are we talking about for 0.2? +13:48 <@duck> the goal was 4 weeks +13:49 < legion> cool +13:49 <@duck> as you can see RawServer (the part that communicates with i2p) is the biggest task +13:50 <@duck> . +13:50 <@duck> a quick poll: +13:50 < legion> yeah, I'm well aware of that :) +13:50 <@duck> who is planning to create an i2p-bt fork? +13:50 <@jrandom> cool, is there anything people can do to help? +13:50 <@jrandom> heh +13:51 < ant> <dm> i +13:51 * jrandom grabs a spoon +13:51 < ant> <dm> m wiling to hepl +13:51 < legion> i +13:51 < ant> <dm> m gay +13:51 < legion> I'm working on a fork +13:52 <@duck> good, then I know who not to take serious. +13:52 <@duck> really, I think it is silly; pooling resources might get you much further +13:53 <@jrandom> or perhaps if there are better ways to go, you can convince duck to work that way? +13:53 < named> I'm going to write a fork in qbasic, please take me seriously. +13:53 <@duck> I'll try to have the process more open, so others can see what is planned etc +13:53 < ant> <dm> your openness is not swaying us. FORK! FORK! FORK! FORK! +13:53 <@duck> if you have any other suggestions +13:54 < ant> * dm raises legion onto his shoulders. +13:54 < legion> hmm, that may be true, though with what I'm doing I doubt you want me polluting the main i2p-bt development process ;) +13:54 < ant> <dm> FORK! FORK! FORK! FORK! +13:54 <@jrandom> legion: what are you doing that duck wouldn't want to support? +13:55 <@duck> legion: congrats, if you google for 'i2p bittorrent', then an announcement of "Windows I2P Bittorrent Version 1.0" is #1 +13:55 <@jrandom> jesus +13:56 < bla> jrandom: Yes? +13:56 <+postman> jrandom: yeah, they will rip this network's ass open soon :) +13:56 < bla> ;) +13:56 < named> 1.0? Damn, I'm using 0.1.8! +13:56 < Ragnarok> oy +13:57 < legion> omfg, really?! I cannot believe it... that's insane. +13:57 <@duck> anyway, I dont think that there is much new to say on this +13:57 < legion> my 1.0 release is based on 0.1.8 if you're running 0.1.8 you're fine. +13:58 <@jrandom> (and the 1.0 release is a .exe that no one has reviewed, ymmv) +13:58 < legion> I poorly named and numbered it sorry, again about that. +13:58 < ant> <dm> 1.0 >> 0.1.8 +13:58 < ant> <dm> any day of the week +13:59 <@duck> slightly related: +13:59 <@jrandom> ok, anything else on 3) i2p-bt, or shall we move on to 4) ??? +13:59 <+postman> legion: when there will be sourcecode downloadable? +13:59 < frosk> "I2P-BT 0.1.8 works pretty fine and stable so far. I personally see no reason to update to I2P-BT 1.0" (seen on forum) +13:59 * jrandom sighs +13:59 <@duck> last month bram cohen held a talk about bittorrent on some university +14:00 <@duck> quite interesting: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent +14:00 <@duck> (learned lessons about big p2p programs, plus some bittorrent details explained) +14:00 <@duck> . +14:01 <@jrandom> word +14:01 <@duck> postman: legion has released some sourcecode +14:01 < ant> <dm> is he the inventor of BT? +14:01 <@duck> but according to smeghead it isnt the same as the .exe +14:01 <@jrandom> dm: yes +14:01 < legion> There is a developer source you can download from http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 +14:02 <+postman> k, will have a look +14:02 < ant> <dm> is the exe a direct compile of that source? +14:03 < legion> though really the 1.0 source is really just 0.1.8 with a patch from smeghead, compiled and nicely packaged. +14:04 * cervantes walks over to 4)??? and waits for everyone to catch up +14:04 < ant> <dm> the question remains unanswered +14:04 < ant> <dm> Legion, did you or did you not, order a code red??? +14:04 <@jrandom> *cough* +14:04 < legion> Perhaps we should get back on topic, my bt client discussion moved to #itorrent +14:05 <@jrandom> ok, 4) ??? +14:05 <@jrandom> anything else people want to bring up? +14:05 <@jrandom> aum: you had something? +14:06 < ant> <dm> stasher is back? +14:06 < legion> I'm just seeing some funky behavior with 0.5.0.2 periods of heavy traffic... +14:06 < aum> yes +14:06 < aum> i'd like to raise the question of automated tunnel creation/management +14:07 < ant> <dm> go on +14:07 <+detonate> there's a null pointer exception in the systray thing in windows, i just noticed +14:07 < aum> it's 1337 that the web console now allows for humans to manually create/delete/manage tunnels +14:07 <@jrandom> detonate: could you toss 'er on the bugzilla? +14:07 < aum> but I also strongly believe that there should always be a reliable and convenient way for programs to manage tunels as well +14:08 <@jrandom> aum: no one disagrees. we need it, and we will have it. just not yet. +14:08 < ant> <dm> can't you do that through SAM? +14:08 < aum> i noticed on my recent return to i2p that the pysam library is no longer working +14:08 < septu_ssh> I have a quick question as well after aum +14:08 < aum> which was a disappointment +14:08 <@jrandom> the SAM protocol works, pysam doesnt +14:08 < Ragnarok> did it ever work? +14:09 < aum> correct +14:09 < aum> pysam used to work brilliantly +14:09 < legion> During such periods there are 1000+ tunnels my node is participating in and several seconds of lag and delay. +14:09 <@jrandom> legion: aye, the # of tunnels is because of older builds +14:09 < cervantes> ah mymodesty +14:09 < cervantes> eerm pymodesty +14:09 < aum> i'm presently writing a module 'i2ptunnel.py', which defines classes allowing easy tunnel management +14:10 < legion> so if older builds were not being connected to, the networking would be much smoother? +14:10 <@jrandom> 'k, i don't know if thats the right long term solution, but if it bridges the gap for you now, cool +14:10 <@jrandom> legion: those tunnels aren't the problem +14:11 < aum> well, the class interfaces can remain even though the underlying mechanism changes +14:11 <@jrandom> 'k +14:11 < legion> aren't they? +14:12 < legion> When there a few tunnels, there is very little lag and delay... +14:12 < cervantes> legion: sorry aum is just raising some questions, if you hang fire a minute +14:12 < legion> it just seems odd to me. +14:13 < legion> ok +14:13 <@jrandom> i just worry that we need to take into consideration whats been successful in the past - the web config works and is maintained because everyone uses it. perhaps it'd be best to get whatever app you're working on working with manual tunnel creation *first*, that'd be more efficient? +14:13 <@jrandom> just so that there is always something that is using i2ptunnel.py, to stress it +14:13 < aum> we seem to be deadlocking +14:13 <+detonate> jrandom:sure +14:14 < ant> <dm> let's move on then +14:14 < aum> i don't want to invest time in developing my app till I've got a tunnel mgmt API I can rely on +14:14 < septu_ssh> \o. - point to raise +14:14 < cervantes> realistically I can't imagine the tunnel interface will be revamped in the next couple of months though... +14:14 <@jrandom> but surely you see that we can add one trivially +14:14 < cervantes> so a stopgap solution is viable +14:15 < named_> Couldn't the web config have some kind of api that aum's program manipulates? +14:15 <@jrandom> named_: yes +14:16 <@jrandom> its trivial to add something in to allow safe control via URLs, but only makes sense if there's something that needs it +14:16 <@jrandom> otherwise it'll just rot +14:16 < aum> named_: that would be nice, and could work if there were a hardcoded password in config that client progs need to POST in along with tunnel control fields +14:16 < cervantes> personally I'd like to see the whole tunnel system completely revamped, if you include a tunnel management interface from the start then you won't have to worry about the extra effort needed to maintain a seperate interface +14:17 <@jrandom> aye, the proxies do need a bunch of work, which i've been hiding from as much as possible :) +14:17 < aum> SAM is good for some situations, bad for others +14:17 < cervantes> but that's somewhat down the line... +14:17 < fedo> ( +14:18 <@jrandom> aum: but as a stopgap, couldn't you just use one of the three available methods? +14:18 < cervantes> ie if the webinterface itself uses the api then there's no maintenance overhead +14:18 <@jrandom> right. the web interface uses the TunnelControllerGroup +14:19 < aum> SAM usage gets difficult when one wants to use existing libs that are extensively dependent on standard TCP sockets +14:19 < aum> jrandom: the I2PTunnel CLI doesn't work for opening server tunnels, so i'm presently writing code for using TunnelControllerGroup +14:19 <@jrandom> aum: exising libs need to be carefully audited. for instance, the gzip utility itself exposes sensitive data +14:19 < aum> coding as we speak +14:21 <@jrandom> I'm certain that the CLI works for server tunnels, but using the TunnelControllerGroup is preferred, if you need it that way +14:21 <@jrandom> ok, anyone else have anything to bring up? +14:22 < septu_ssh> My question pertains to a distributed version of the hosts.txt, a DHT table is used currently for routerInfo, could this not be extended to a distributed version of DNS? The DNS DHT could contain mappings from www.bla.i2p to the eepsite SHA, and the entries would be signed by an 'I2P registrar'... comments? rebuttals? +14:22 < mancom> a question concerning the roadmap: is 0.6 still scheduled for april? +14:22 <@jrandom> septu_ssh: non-routing data goes in the netDb over my dead body ;) +14:23 < septu_ssh> jrandom: not the same db +14:23 < septu_ssh> a different distributed db +14:23 < aum> jrandom: did you see my bug report? the CLI 'server' command /does not work/ +14:23 < maestro^> septu_ssh: there isnt any i2p registrar +14:23 <@jrandom> septu_ssh: there are many dangerous aspects of naming, with a few key tradeoffs. have you seen the naming discussion on ugha.i2p? +14:24 <@jrandom> septu_ssh: ah, a DHT on top of I2P could certainly be used to distribute entries, though those names would not be secure, if they were treated as global entries +14:26 <@jrandom> aum: i used it daily up through a few weeks ago, did you see my reply? +14:26 <@jrandom> maestro^: thats the plan +14:26 <@jrandom> er, mancom: +14:26 < cervantes> aum: I have a reply to that i2plist mail from jr, has it not reached you yet, or does the issue remain? +14:26 < septu_ssh> the only reason why I suggest a 'registrar' is because collisions can take place otherwise +14:26 <@jrandom> septu_ssh: embrace collisions :) +14:26 <@jrandom> globally unique, human readable, distributed, and secure naming doesnt exist +14:27 < septu_ssh> it can also happen in host.txt if it is manually edited, but the problem remains the same +14:27 <@jrandom> drop the first parameter, and you're golden +14:27 < aum> jrandom: i did see your reply - and I /do/ have streaming.jar in my cp +14:27 < septu_ssh> postman manages a central node for mail, so there is some element of trust within the network, surely someone would trust a registrar to manage namespace? +14:27 <@jrandom> ok cool, and it still comes back with that stacktrace aum? +14:28 < aum> yes +14:28 <@jrandom> septu_ssh: postman only acts as a central element for postman's outproxies and inproxies +14:28 * Ragnarok really need to get around to writing that addressbook doc... +14:28 < aum> this is when i manually run the cli, do a genkeys, then do a 'server' using the privkeyfile generated by genkeys +14:28 <@jrandom> septu_ssh: no one will trust anyone to manage a namespace. censorship == exert presure on that registrar. +14:28 < maestro^> everyone is really their own registrar +14:29 < maestro^> you trust your friends and they trust you +14:29 < aum> oh shit, i picked up an old classpath +14:29 * aum tests again +14:30 < ant> <dm> ok, I'll be the registrar. +14:31 < ant> <dm> I'll be as unbiased as I can... cool? +14:31 < septu_ssh> hmmm, ok, back to the proverbial drawing board then... +14:31 <@jrandom> septu_ssh: a good place to review is http://zooko.com/distnames.html :) +14:32 <@jrandom> everyone wants it, but what they want just isn't secure. we have a solution that is, but we give up global uniqueness +14:33 < septu_ssh> hmmm, ok +14:33 <@jrandom> ok, anyone else have anything else to bring up for the meeting? +14:33 < cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 +14:33 < aum> jrandom - ok, cli 'server' now works, but i never got a 'job number' for the tunnel +14:34 <@jrandom> hmm right, it runs forever +14:34 < aum> oh, i gotta do 'list' to get the job num +14:36 <@jrandom> ok cool, if there's nothing else... +14:36 * jrandom winds up +14:36 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/132.rst b/i2p2www/meetings/logs/132.rst new file mode 100644 index 00000000..b543bbc7 --- /dev/null +++ b/i2p2www/meetings/logs/132.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 8, 2005 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/133.log b/i2p2www/meetings/logs/133.log new file mode 100644 index 00000000..ced46f5b --- /dev/null +++ b/i2p2www/meetings/logs/133.log @@ -0,0 +1,317 @@ +13:07 < jrandom> 0) hi +13:07 < jrandom> 1) Net status +13:07 < jrandom> 2) Feedspace +13:07 < jrandom> 3) ??? +13:07 < jrandom> 0) hi +13:07 * jrandom waves +13:07 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000649.html +13:08 < Teal> hi +13:08 < jrandom> (yeah, i was late this time, but close!) +13:08 < frosk> hi +13:08 < jrandom> might as well jump on in to 1) net status +13:08 < jrandom> the net, its, like, up, 'n stuff +13:09 < jrandom> overall throughput is still down where it was before, with a substantial number of dropped messages & fragments +13:09 < bla> hi +13:09 < ant> <dm> bad +13:09 < Teal> any clues as to why ? +13:10 < jrandom> Teal: sure, read the status notes? :) +13:10 <+detonate> hi +13:11 < jrandom> there are still ~ 25 people on older builds, and likely, they'll be staying there until we drop them off the net +13:11 < jrandom> in any case, we should be able to work around them, so having them here is actually helpful, i suppose +13:11 < jrandom> (though it'd be nice if they upgraded... ;) +13:11 < cervantes> (hi) +13:11 < frosk> those are probably sheeple who installed i2p because they read about it somewhere and wanted to try "anonymous p2p" +13:12 < ant> <BS314159> yeah, if network quality degradation can happen due to bugs, it's possible due to malice +13:12 < newkid> This is the first meeting I am in, but I read the notes, and the problem seems related to what I explained before the meeting +13:12 < Pseudonym> do we know what specific probblems the old nodes are causing and why? +13:12 < jrandom> bs314159: never attribute to malice what can be attributed to jrandom writing bad code ;) +13:13 < jrandom> Pseudonym: yeah, see the changelog +13:13 < newkid> I run two nodes, milliseconds apart, and they don't regard eacxh other "fast" more of the time +13:13 < jrandom> right newkid +13:13 < jrandom> the speed calculator as deployed is, well, pretty shitty +13:13 < jrandom> it doesnt gather enough data to have any sort of confidence in the values +13:13 < bla> Hmm.. That's bad at best ;) +13:13 < jrandom> its about as meaningless as the "instantaneous rates" you can see on /oldconsole.jsp +13:14 < jrandom> i'm trying out some new calculators, and there is an improvement, but there are problems in the algorithm +13:14 < jrandom> namely, it won't let high capacity peers turn into fast peers without those fast peers dropping from the high capacity group +13:15 < bla> jrandom: Does every node get "fastness" data for the other nodes directly ("P2P"), or via tunnels? +13:15 < jrandom> (aka the first K peers placed in the fast group will stay in the fast group) +13:15 < jrandom> bla: tunnels, we cannot trust direct measurement, as that'd allow trivial anonymity attacks +13:15 < godmode0> "alfYl6RvHzw=" = "21538-900" +13:15 < godmode0> "alV9ye/y/Us=" = "23565-200" +13:15 < godmode0> its is sha1 ? +13:15 < jrandom> (e.g. be really really slow to everyone except Alice) +13:15 <+detonate> they'll stay there for the lifetime of the router? +13:15 < jrandom> godmode0: we're in a meeting right now +13:16 < godmode0> ops sorry +13:16 < jrandom> detonate: until one of them failed or rejected a tunnel (aka their capacity rank drops them from the high capacity group) +13:16 <+detonate> ok +13:17 < bla> bla: Hmm.. This sounds like a problem that ---in order to get _really_ enough_ data--- has to be >>log(N) on the network. +13:17 < jrandom> i've been toying with some ideas to get more data, but haven't updated it yet +13:17 < bla> In terms of load, that is. +13:18 < jrandom> well, one of the critical points certainly is when the network load exceeds the network capacity +13:18 < jrandom> i believe our capacity calculators can handle that though +13:18 < cervantes> jrandom: is -3 actually employing this fast peer selection method? +13:18 <+polecat> Hopefully since data transfer between peers has fairness controls, there won't be any way to increase load too much... +13:19 < bla> jrandom: Well, I mean more specifically: we need to make sure that the "finding out who is fast" algo. stays O(log(N)) +13:19 < jrandom> cervantes: yeah, but as i said, it doesn't allow promoting peers between fast and high capacity +13:19 < jrandom> polecat: fairness controls? +13:19 < cervantes> since I've just realised I've had the proxy enabled, and have been browsing the live web without realising (I did think my connection was a little sluggish) ;-) +13:20 < cervantes> s/live web/outerweb +13:20 < jrandom> bla: i'm not sure we should be dependent upon N. no need to find an optimal 'fastest on the net', merely 'fast enough to handle our data' +13:20 <@smeghead> it would seem i2pProxy.pac is dangerous even for its creator :) +13:20 < jrandom> heh nice cervantes :) +13:20 < jrandom> lol +13:20 < cervantes> so it certainly seems to have improved things on my home node which was really suffering before +13:21 < ant> <BS314159> jrandom: can you randomize it? +13:21 < cervantes> smeghead: hehe hell I don't use that! you think I'm mad! +13:21 < ant> <BS314159> i.e. create a spontaneous transition rate? +13:21 < jrandom> BS314159: we use the tiers, and randomize within the tiers +13:22 < jrandom> BS314159: spontaneous rates are essentially what we have now, which fluctuate widely +13:22 < jrandom> (we == 0.5.0.2-0) +13:22 < ant> <BS314159> I think I don't understand the problem. nm. +13:23 < jrandom> it is tough to do safely and accurately, but i think there's enough data around for us to harvest sufficient info. we shall see +13:23 < bla> jrandom: In any case, finding out a couple of good nodes looks an awful lot like an ant-colony optimization thing +13:24 < bla> jrandom: Because once you've got fast peers, you're likely to use _those_ to find out who else is fast. +13:24 < jrandom> would you propose further active probing along those lines? +13:24 < jrandom> ah, actualy, thats not true +13:25 < jrandom> thats the difference between client tunnels and exploratory tunnels +13:25 < bla> jrandom: And thus, it seems you'd essentially be doing a greedy optimization scheme (much like ant-colony) +13:25 < jrandom> client tunnels are built with fast peers, exploratory tunnels are built with any non-failing peer +13:25 < jrandom> (chosen randomly) +13:26 < bla> jrandom: Hmm.. For anonimity, that's good. However, for quickly finding good tunnel-partners to use, it would be better to use fast peers in the expl. tunnels... The trade-off again +13:26 < jrandom> otoh, there may be something in that vein to help optimize the peer selection +13:26 < jrandom> oh, right, certainly you'd get better performance by using the fast peers, but then you wouldn't be exploring :) +13:27 < jrandom> the exploratory tunnels aren't used for end to end client messages, just for netDb messages, tunnel maintenance messages, and peer test messages +13:27 < bla> jrandom: I see, so effectively, you use random expl. tunnels to prevent falling into local optima? +13:27 < jrandom> so the actual throughput of the exploratory tunnels doesnt matter (as long as the data gets through, eventually) +13:27 < jrandom> aye +13:29 < bla> jrandom: Ok, I see. OTOH: When I use my client tunnels to transfer some data (like downloading from an eepsite), I seems to me (intuitively), that the timing/throughput data on that could also serve as some kind of "passive peers assessment", couldn't it? +13:29 < jrandom> definitely bla, and at the moment, we don't yet harvest that data within the speed selection +13:29 < bla> jrandom: i.e. as an aux. way to get more data on peers +13:30 < jrandom> some of it we can, though some of it will be harder to grab (since the streaming lib is external) +13:30 < jrandom> we should definitely grab what we can though to get more confidence +13:30 < ant> <BS314159> won't that depend on the slowest link in any tunnel? +13:31 < ant> <BS314159> making it very difficult to use for hops>0? +13:31 < jrandom> BS314159: yeah, but it'll average out, as peers are selected randomly within the fast tier +13:31 < jrandom> same goes for any remote measurement +13:34 < jrandom> ok, so thats generally where things stand atm. hopefully we'll have some new calculators & stats up for a -4 or -5 build in the next few days, trying to see how it handles the live net +13:34 < jrandom> anyone have anything else to bring up for 1) Net status? +13:34 < bla> jrandom: It may seem that I'm putting a truckload of emphasis on this, but it seems to me to be a problem that['s very fundamental for a big I2P net to work... +13:35 < jrandom> bla: its certainly important, but remember, we don't need optimal peer selection. merely sufficient +13:35 < ant> <aum> morning folks +13:36 < jrandom> all we care about is finding some peers who can handle a tunnel, and making sure those tunnels can handle our data +13:36 < jrandom> 'mornin aum, in time for the meeting :) +13:36 < bla> jrandom: I see. Thnx for the explaination! +13:36 < jrandom> of course, you're right in that it'd be kickass if we /could/ find the optimal peer selection ;) +13:37 < jrandom> and there is definitely lots of room for some students to work out some ideas and write up some papers +13:37 < frosk> this would be a cool thesis project :) +13:37 <+detonate> how workable do you think it would be to actively tweak the parameters of the peer selection until it hopefully settles on something that works, disregarding the impossibility of debugging such a system? :) +13:38 < jrandom> detonate: manual peer selection is a PITA, since fast peers get congested occationally, asking you to back off, etc. +13:38 <+detonate> ah +13:39 < jrandom> i know we could dig into this forever, which is why i've set a milestone of successfully transferring one specific large file through standard tunnels, without disconnect +13:39 <+detonate> alright +13:40 < Teal> Victory at any cost! +13:40 < jrandom> (otoh, there are some undocumented features of the peer selection system to let people weight individual peers manually, but i'm not recommending 'em ;) +13:40 < jrandom> ok, thats 'bout it for 1), now lets swing on to 2) Feedspace +13:41 * jrandom hands the mic to frosk +13:41 < frosk> oh, ok, hi +13:42 < Myo9> Hi Frosk. +13:42 * jrandom gets out the high intensity spotlight +13:42 < frosk> so, everyone should check out http://feedspace.i2p (keys at orion or jrandom's blog) +13:42 < frosk> my devbuddy (which i will out now as ku) and i have started writing some code and have had many lively discussions +13:42 < frosk> also, http://feedspace.i2p/wiki/CallForComments has a fresh rev of the feedspace document :) +13:43 < frosk> hi Myo9 +13:43 < frosk> oh yeah, feedspace is our new (and final) name for what used to be known as i2pcontent or fusenet :) +13:43 < jrandom> r0x0r +13:43 < frosk> as the status notes notes, we are still very interested in feedback on the general design of everything +13:44 < frosk> nobody should be shy about challenging it :) +13:44 < frosk> and the web site also lists some "job openings", we could use some helping hands on many aspects of the system and project +13:45 < frosk> we're on a pretty tight schedule and none of us are full-time developers on the project unfortunately +13:45 < frosk> so that's pretty much it, i think. questions? :) +13:45 < ant> * aum can't reach orion.i2p or jrandom's blog, so can't reach feedspace.i2p +13:46 < frosk> hm yes, the web site also has a roadmap, but the dates there _will_ change :) +13:46 < legion> feedspace.i2p=KuW5sR2iGCfnnuwdslHbFsNyNCsoZnoIwAmHeypOV-s8OQxokBpdNazksBrhoQum9nv81vprl6k15Mhcd~KWE4OajjmdU7v2fjqps7QK3KmLv4UTrX-ihSIUdhb5B9FLh2XEFEQ4-8guFTVxBRqQQE~c058AL6~uZpuFpLtEOg0HEZ6BydndOhx-FCDm8ip12pPwZ3a5O86l1UoATZBXxoctGafTjnUlx64jyQs6y0WB811l36wVrc~~dqEcanxab0yfg8dJ~1M4EUNrXcHT-PwYYrr3GgpimuF4oUtYjkeDKlq5WjfMAa8bE73HFgquxq99fuW5aI1JbLPxnTLHi00-2On0dSDwJxSP08HOhKFKMNzykI9Asg8CywzNO6kWpbX9yaML36ohCJF0iaLvvDyhS4a2B65crSJRJPVkbxIvsyyUyYMGi31EK593ijOLjOvug +13:46 < legion> there you go aum +13:46 * jrandom just added feedspace to http://dev.i2p.net/i2p/hosts.txt +13:46 < jrandom> (and cvs) +13:46 * frosk goes temporarily blind +13:46 < jrandom> legion: never paste as a single line, its too large to fit +13:47 < ant> <aum> thx +13:47 < frosk> jrandom can probably commit the key into his hosts.txt maybe? :) +13:47 < jrandom> aye, 'tis on there now, forgot to :) +13:48 < frosk> anyway, the plan is to have something simple and functional (and 100% bug-free!) out by I2P 0.6.1, and we'll build more neat stuff in later +13:49 < jrandom> heh wikked +13:49 < frosk> s/out/ready for real-world testing/ +13:49 < frosk> i still can't say if that's realistic or not, but i hope it will be, or we'll continue to cut features ;) +13:49 < ant> <BS314159> since I can't reach feedspace.i2p, I'll ask a basic question +13:50 < ant> <aum> that key is not correct, only 441 chars +13:50 < jrandom> right aum, irc trims it, snag http://dev.i2p.net/i2p/hosts.txt +13:51 <+detonate> frosk: i have a suggestion for the meantime +13:51 <+detonate> get something on the i2p router console that grabs a list of updates from the i2p webserver, so people know when to update their routers, etc :) +13:51 < legion> ah sorry, about that. Anyways I've already commited it to my hosts.txt also. +13:51 < ant> <aum> thx jrandom +13:51 < ant> <BS314159> which of the following systems do you see feedspace supplanting: usenet, gnutella, google, livejournal, www +13:52 < jrandom> , the church +13:52 < jrandom> er.. +13:52 < cervantes> jrandom: ah you caught me mid commit of hosts +13:52 < ant> <BS314159> i.e. is it a message forum, a filesharing system, a content indexing system, a dynamic page system, and/or a static serving system +13:53 < ant> * aum turns off throttling within routerConsole, and sees if that helps +13:54 < frosk> BS314159: we will support blogs, forums, and shared address books (for the first version, other applications are possible) +13:54 < frosk> it doesn't replace web pages per se +13:54 < frosk> but it certainly could be used for "file sharing" +13:54 <+detonate> content syndication then? +13:54 < jrandom> it'd probably supplant static web content though, allowing persistent web publication for people who cannot run eepsites +13:54 < frosk> that's what it's about +13:55 < jrandom> (two word summary: usenet+SSK) +13:55 < frosk> yeah +13:55 < ant> <BS314159> ok +13:55 < Ragnarok> not that persistent +13:56 < jrandom> Ragnarok: depends on syndicator policy, true +13:56 <+detonate> is anything happening with stasher? +13:56 < frosk> it can be as persistant as the most eager syndicator :) +13:56 < jrandom> (see: dejanews ;) +13:56 < ant> <aum> detonate: stasher is on hold, writing a whole new thing called quartermaster +13:57 <+detonate> i see +13:58 < jrandom> frosk: what can we do to help? +13:59 < jrandom> should people register & hack on the wiki, email, post on the forum? +13:59 < jrandom> oh, perhaps we can get cervantes to add a new forum category? +13:59 < frosk> i think actually a forum would be very nice at this point +14:00 < frosk> for more private discussion, you can email us both at ku@mail.i2p and frosk@mail.i2p +14:01 < cervantes> hrrrm ... are you going to put game reviews in it? +14:01 < jrandom> heh +14:01 < jrandom> w3rd +14:01 < cervantes> because if not...then you're welcome to have a new forum section +14:01 < frosk> i was thinking top20 music reviews, cervantes +14:02 < jrandom> (btw, mirror of the call for comments @ http://dev.i2p.net/~jrandom/feedspace.txt) +14:02 < cervantes> :) +14:04 < cervantes> frosk: feedspace or feed space or Feedspace or Feed Space or FeedSpace? +14:04 < frosk> cervantes: Feedspace +14:05 < frosk> looking forward to much discussion over at the forum then :) i don't have anything else for this point, anyone else? +14:05 < jrandom> ok cool, thanks for the update frosk +14:06 <@smeghead> or FEeDspace? +14:06 < ant> <cervantes> frosk: when you have a moment, just pm me a one liner description for the forum section +14:06 < legion> hmm speaking of new forums, lol. I'm putting a new forum site together. Though I have much hacking left to do on the phpbb code, it should be finshed sometime this week. ;) +14:06 < jrandom> cool legion +14:06 < jrandom> that actually brings us into 3) ??? nicely +14:06 < jrandom> anyone have anything else to bring up? +14:06 < jrandom> aum: any updates on Q? +14:07 < frosk> i, uhm, no +14:07 < ant> <aum> Q devlt is moving along nicely, nothing to announce atm +14:07 < jrandom> w3rd +14:07 < ant> * aum is 90% complete with net.i2p.i2ptunnel.I2PTunnelXMLServer +14:07 < ant> <BS314159> I have a simple question about netDb +14:07 < ant> <aum> everything's working now except 'i2p.tunnel.close' +14:07 < legion> my forums will allow for members to have decent sized avatars, discuss shared content, just about whatever. +14:08 < jrandom> wikked +14:08 < ant> <BS314159> it says on the page that entries are stores on the peers closest to SHA256(router identity + YYYYMMdd) +14:08 < jrandom> right BSpi +14:08 <@smeghead> legion: will it be as much a security hazard as your bt client? +14:08 < ant> <BS314159> does this mean there's a burst of traffic every 00:00 GMT? +14:08 < ant> * aum is actually gaining some fluency in java, having attained a 'cognitive critical mass' +14:09 < jrandom> BS: data points expire more frequently than they migrate +14:09 < jrandom> a LeaseSet is only good for 10 minutes, for example +14:09 < bla> jrandom: Is there a command-line call I can make, such that I can speed estimates of each of the peers in the net over the last, say, 60 seconds, or so? +14:09 < legion> lol, forums a security hazard? +14:10 <@smeghead> legion: yes, and if you don't know that much, i'm already convinced that your forums will be a security hazard +14:10 < jrandom> bla: yeah, java -cp lib/i2p.jar:lib/router.jar -Djava.library.path=. net.i2p.router.peermanager.ProfileOrganizer peerProfiles/* +14:10 < jrandom> (i think) +14:10 < legion> oh and the next release of my bt client shouldn't cause such issues... +14:10 < jrandom> you may need to add some log levels to logger.config, lemmie check +14:10 <@smeghead> legion: Cervantes made a ton of modifications to phpBB to lock it down for i2p use +14:10 < ant> <BS314159> It just seems like having it occur all-at-once at a specified time is awkward. If it were happening continuously, that would seem...smoother. It would also give an attacker less time to mount an attack, since bits of the data would be wrong in less than 24 hours +14:11 < jrandom> nah, it dumps to stdout +14:11 < frosk> jrandom: how do you feel about the i2p roadmap currently, if one may ask? do you think it's realistic? +14:11 < legion> Hmm I wonder if I can get a copy of cervantes mods? +14:11 < jrandom> frosk: i update it when i become uncomfortable with it +14:12 < frosk> ok +14:12 <+detonate> you know, there's a windows installer for python 2.4, one for wxpython, and there's the i2p-bt tarball, i don't really see why anyone would get/trust a third-party release +14:12 < legion> Otherwise I'll just have to continue to hack on the phpbb source myself... +14:12 < jrandom> BS: peers would only look in the wrong place for up to 30s, due to clock synchronization +14:12 <@smeghead> legion: have fun +14:12 < legion> well why would anyone get and use kazaa? +14:13 < bla> jrandom: I'm asking, because... +14:13 < legion> Or morpheus? +14:13 < jrandom> (because they dont know better?) +14:13 < legion> Both of those contain adware/etc... +14:13 <+detonate> they are ignorant? +14:14 < legion> yeah and there are millions of ignorant users out there. ;) +14:14 < ant> <BS314159> legion: you sound like you want to bundle spyware with I2P. Truly, a stroke of genius. +14:14 < bla> jrandom: ...I browsed SpeedCalculator.java and CapacityCalculator.java, and I'd like to experiment with the estimators +14:14 < cervantes> legion: stay uptodate with official patches, and put htaccess on the admin areas +14:14 < jrandom> wikked bla +14:14 < legion> What? Heck no... I hate malware... +14:14 < cervantes> most of my mods involve spam prevention +14:14 < ant> <aum> can i raise a more critical issue? +14:14 < legion> That's it? cervantes? +14:15 < jrandom> sup aum? +14:15 <@smeghead> legion: what about your users that also hate malware? why do you do nothing to alleviate any concerns they might have? +14:15 < ant> <dm> BS314159: are you a windows hotfix? +14:15 < ant> <aum> is it just me, or is there still some flakiness going on with in i2p? i'm having heaps of trouble with even main eepsites, irc etc +14:15 < bla> jrandom: In addition, the idea of "passive fingerprinting" is now in my head (a bit ;): If I receive data through a tunnel, this tells me something about the bandwidth/capacity of all the peers in that tunnel:... +14:15 < jrandom> aum: see the weekly status notes +14:16 < cervantes> legion: rename all registration, login , posting and profile editing pages to something non-standard +14:16 < bla> jrandom: It tells me some about the peer closest to me, somewhat less about the peers one step away, and so progressively less. +14:16 < cervantes> will help keep worms at bay +14:16 < jrandom> bla: aye, i read that timing paper, and yesterday's tor attack paper with much interest +14:17 < Myo9> Cervantes, releasing ant of your mods? +14:17 < Myo9> s/ant/any/ +14:17 < jrandom> there is worry along those lines in the capacity calculator with the different tiers of rejection +14:18 < bla> jrandom: In a way, this gives me some degree of "belief" in a peers bandwidth/capacity (that degree of belief depends on the distance to each of the tunnel members, and on the amount of belief I have on the BW/cap. of the nodes closest to me) +14:18 < legion> thanks for the advice cervantes :) +14:18 < bla> jrandom: Now, I happen to know some ppl that know a lot about Bayesian Belief Networks... ;)) +14:18 <@smeghead> again, legion ignores the question +14:18 <+thetower> I think we're all gonna have to call a truce with legion and let him write whatever he wants, its not like anyone is forced to use it. +14:18 < jrandom> hmm, what do you mean by distance bla? +14:18 < ant> <dm> what is legion up to? +14:19 < bla> jrandom: I'll have a chat with them, regarding passive fingerprinting (note: I do not mean "fingerprinting" in the negative sense of the word) +14:19 < jrandom> wikked +14:19 < jrandom> suggestions as to how we can best select 'quality' peers are very much welcome +14:19 < cervantes> Myo9: I certainly could do. +14:19 < legion> Anyways there isn't many i2p windows users just yet and not that many running my i2p-bt binary distribution. Soon my next release will be done and released, it will not have such issues... As there will be a binary and source distribution. +14:19 <@smeghead> why anyone would want to use software from someone who doesn't even take the most basic measures to address users' concerns about security and anonymity is beyond me +14:20 < ant> <aum> frosk: what lang you writing feedspace in? (forgive me if i asked you before) +14:20 < cervantes> it's not a clean "patch" or anything though +14:20 < bla> jrandom: distance... Say I have an inbound tunnel X -> Y -> me, and I know a _lot_ about Y's properties, than stats on what I receive thru that tunnel tells me a good deal about X +14:20 < frosk> aum: java (and i forgive you ;) +14:20 < cervantes> I've just been fixing stuff andproblems as it arises +14:20 < bla> jrandom: OTOH, if I have little data/belief on Y's properties, transfer stats don't tell me much about X yet; I first have more to learn about Y +14:20 < cervantes> as they +14:20 < jrandom> bla: its very hard to tell whether lag or congestion occurs @ X or Y (or earlier hops) +14:20 < cervantes> http://forum.i2p/index.php?c=4 +14:21 < cervantes> new section: Feedspace +14:21 < jrandom> w00t +14:21 < frosk> yay +14:22 < legion> anyways enough discussion about my release, any further discussion about it should be done in the #itorrent channel +14:22 < bla> jrandom: That is true. However, given large amount of data (and hoping that the measurement time is not _much_ larger than the timescale on which node properties change), I'm convinced there _must_ be information in traffic/tunnel stats +14:22 <@smeghead> legion: we can discuss in meeting point # 3) any business that affects i2p +14:23 <@smeghead> legion: and i think your software is of serious concern and warrants a warning to users +14:23 < legion> yeah, ok +14:23 < jrandom> bla: certainly, we just need to rope in the RTT from the OutboundClientMessageOneShotJob +14:23 < jrandom> (and then figure out how best to calculate & decay the data) +14:24 < legion> So smeghead if you were to make such a release, what would you do differently? +14:24 <@smeghead> legion: the way you continually dodge questions and try to defer discussion on the subject is very disconcerting +14:25 <@smeghead> legion: first of all, release the source to your current binary, no matter if it's "just i2p-bt with smeghead's patch", and have a writeup on your site explaining about your fork +14:25 < bla> jrandom: What does the RTT signify there? +14:26 <@smeghead> legion: it would be helpful to do as i2p-bt does also, and make a changelog indicating all the modifications you've made +14:27 < jrandom> bla: end to end client messages are often (by default, always) bundled in garlic wrapping, containing an additional DeliveryStatusMessage that returns to the sender (through tunnels, of course), allowing the use of AES+sessionTags instead of ElGamal +14:28 < bla> jrandom: (yes) +14:28 <+detonate> as i said, you could just provide a link to the download page for the three things you need for i2p-bt to work, it's straight-forward and gets you exactly the same thing, i can't actually see a use for it besides a trojan +14:28 < jrandom> later on we'll update I2CP (and the SDK) to allow the streaming lib to deliver that same data without requiring the DeliveryStatusMessage +14:29 <@smeghead> detonate: i agree, he should have just submitted a patch to the official i2p-bt in the first place, forking was completely unnecessary and fostered immediate suspicioun +14:30 <+detonate> indeed +14:30 <@smeghead> *suspicion +14:31 < jrandom> ok, anyone else have anything to bring up for the meeting? +14:31 < ant> <drakoh> hi people ! wanted to know, is there anything special with the network ? +14:32 <@smeghead> because of the nature of i2p, applications developed for it require a greater measure of openness with end users and cooperation among developers +14:32 < jrandom> drakoh: see the weekly status notes +14:32 < bla> quit +14:32 < ant> <drakoh> no I mean something strange ... +14:32 <@smeghead> i2p users will always be naturally paranoid to some extent, and it's our duty to do what we can to dispel any concerns we possibly can +14:32 < ant> <drakoh> like I lost all my peers +14:33 < jrandom> aye, agreed smeghead. for anonymity or security software, especially software dealing with a trojan-laden field such as filesharing, its critical to be open. +14:33 < jrandom> drakoh: ok, hold on, we can debug that once the meeting is over +14:33 < ant> <drakoh> woops sorry +14:33 < jrandom> ok, speaking of the meeting being over... +14:34 * jrandom winds up +14:34 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/133.rst b/i2p2www/meetings/logs/133.rst new file mode 100644 index 00000000..c6563549 --- /dev/null +++ b/i2p2www/meetings/logs/133.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 15, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/134.log b/i2p2www/meetings/logs/134.log new file mode 100644 index 00000000..37cbc49e --- /dev/null +++ b/i2p2www/meetings/logs/134.log @@ -0,0 +1,171 @@ +13:01 <@jrandom> 0) hi +13:01 <@jrandom> 1) 0.5.0.3 +13:01 <@jrandom> 2) batching +13:01 <@jrandom> 3) updating +13:01 <@jrandom> 4) ??? +13:01 <@jrandom> 0) hi +13:01 * jrandom waves +13:01 <@jrandom> the just-now-posted weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html +13:02 <+detonate> hi +13:02 <+cervantes> 'lo +13:02 <@jrandom> jumpin' right in to 1) 0.5.0.3 +13:02 <@jrandom> the release came out a few days ago, and reports have been positive +13:02 <+cervantes> jrandom: let us know when the blue dancing dwarves climb onto your monitor and we'll stop the meeting early +13:03 <@jrandom> heh cervantes +13:03 <@jrandom> (thank Bob for editable meeting logs ;) +13:04 <@jrandom> i dont really have much to add wrt 0.5.0.3 than whats in that message +13:04 <@jrandom> anyone have any comments/questions/concerns on it? +13:04 < bla> jrandom: Any new measurements on the fast-peers-selection code? +13:05 <@jrandom> ah, i knew there was something else in 0.5.0.3 that i had neglected ;) +13:06 <@jrandom> i dont have any hard metrics yet, but anecdotally the fast peer selection has found the peers that i know explicitly to be 'fast' (e.g. routers on the same box, etc) +13:07 < bla> jrandom: Sometimes, eepsites still require a number of retries to find a good tunnel to use +13:07 <@jrandom> reports have come in for fairly reasonable throughput rates on occation as well (in the 10-20KBps range), but thats still not frequent (we still have the parameters tuned down) +13:08 <+ant> <Connelly> oops there's a meeting +13:09 <@jrandom> hmm, yes, i've found that reliability still isn't where it need to be. retrying more than once really isn't a solution though - if a site doesnt load after 1 retry, give it 5-10m before retrying +13:09 <@jrandom> what i've seen on the net though is some not-infrequent-enough transport layer delay spikes +13:10 <@jrandom> e.g. taking 5-20+ seconds just to flush a 1-2KB message through a socket +13:10 <@jrandom> tie that up with a 5 hop path (2 hop tunnels) and you can run into trouble +13:11 <@jrandom> thats actually part of whats driving the batching code - reducing the # of messages to be sent +13:13 <@jrandom> ok, anyone else have any questions/comments/concerns on 0.5.0.3? +13:13 < bla> jrandom: Looks good. I will ask more about it in the next "section" +13:14 <@jrandom> w3rd, ok, perhaps we can move on there then - 2) batching +13:15 <@jrandom> the email and my blog (jrandom.dev.i2p</spam>) should describe the basics of whats planned +13:15 <@jrandom> and, well, really its some pretty basic stuff +13:15 <@jrandom> the current preprocessor we have was the simplest possible one to implement (class name: TrivialPreprocessor) ;) +13:16 <@jrandom> this new one has some tunable parameters for batching frequency, as well as some outbound tunnel affinity within individual tunnel pools (where we try to select the same outbound tunnel for subsequent requests for up to e.g. 500ms, so that we can optimize the batching) +13:17 <@jrandom> that's about all i have to add on that though - any questions/comments/concerns? +13:18 < bla> Does this require all participating nodes to run the new preprocessor, or can a mix of Trivial/NewOne coexist? +13:18 <+Ragnarok> this will add .5 s to latency, right? +13:19 <@jrandom> bla: nah, this preprocessor is only used on the tunnel gateway, and its up to that gateway to decide how or whether to batch +13:20 <@jrandom> Ragnarok: not usually - message 1 may be delayed for up to .5s, but messages 2-15 get transferred much faster than they would have otherwise. its also a simple threshold - as soon as a full tunnel message worth of data is available, its flushed +13:20 <+Ragnarok> cool +13:20 <+Ragnarok> how much overhead does it save? +13:21 <@jrandom> substantial ;) +13:21 <+Ragnarok> substantial is good, if vague :P +13:21 <@jrandom> look on your http://localhost:7657/oldstats.jsp#tunnel.smallFragments +13:21 <@jrandom> compare that to #tunnel.fullFragments +13:22 < bla> jrandom: Does this concern endpoint->IB-gateway communication only? +13:22 <@jrandom> with batching, the ratio of full to small will go up, and the # of pad bytes in the small will go down +13:23 <@jrandom> bla: hmm, it concerns all tunnel gateways, whether inbound or outbound +13:24 < mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events +13:24 < bla> jrandom: ok +13:24 < mihi> can there be a frational number of fragments? +13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events +13:25 <@jrandom> heh mihi +13:25 <@jrandom> (that small: 746 means that on those 692k messages, 746 out of 996 bytes were wasted pad bytes!) +13:26 <@jrandom> well, not quite wasted - they served their purpose +13:26 <+detonate> needless overhead anyway +13:27 <@jrandom> yep, much of which we should be able to shed with the batching preprocessor +13:28 <@jrandom> unfortunately, that won't be bundled in the next release +13:28 <@jrandom> but it will be bundled in the 0.5.0.6 rev (or perhaps 0.5.1) +13:28 <@jrandom> erm, 0.5.0.5, or 0.5.1 +13:28 * jrandom gets confused with #s +13:29 < bla> jrandom: How come not? +13:29 <+cervantes> hash and pills...damn +13:30 <@jrandom> !thwap cervantes +13:30 <@jrandom> bla: there's a bug in 0.5.0.3 (and before) where the fragmented message handler will cause subsequent fragments within the same tunnel message to be discarded +13:31 <@jrandom> if we deployed the batching preprocessor directly, we'd have a substantial number of lost messages +13:31 <@jrandom> its not a worry, we've got other neat stuff up our sleeves though, so this coming 0.5.0.4 won't be totally boring ;) +13:31 < bla> jrandom: Ah, so that +13:32 < bla> jrandom: Ah, so that is why we have to do that after 0.5.0.4 is mainstream.. I see. Thnx. +13:33 <@jrandom> yeah, it'd be nice if the fragment handler was able to deal with it, and it does, generally, it just releases the byte buffer too soon, zeroing out subsequent fragments (oops) +13:33 <@jrandom> ok, anything else on 2), or shall we move on to 3) updating? +13:35 <@jrandom> ok, as mentioned in the status notes (and discussed for a while in various venues), we're going to add some functionality for simple and safe updating that doesn't require the end user to go to the website, read the mailing list, or read the topic in the channel :) +13:36 <+detonate> cool +13:36 <@jrandom> smeghead has put together some code to help automate and secure the process, working with cervantes to tie in with fire2pe as well as the normal routerconsole +13:37 <@jrandom> the email lists the general description of whats going to be available, and while most of it is functional, there are still a few pieces not yet fully hashed out +13:37 <@jrandom> unlike the batching, this /will/ be available in the next rev, though people won't be able to make much use of it until 0.5.0.5 (when it comes time to update) +13:39 <+Ragnarok> so... what's the cool stuff for 5.0.4, then? +13:42 <@jrandom> with the update code comes the ability to pull announcement data, displaying e.g. a snippet of news on the top of the router console. in addition to that, as part of the update code we've got a new reliable download component which works either directly or through the eepproxy, retrying and continuing along the way. perhaps there'll be some relatd features built off that, but no promises +13:42 <+Ragnarok> neat +13:43 <@jrandom> ok, anyone else have any questions/comments/concerns on 3) updating? +13:45 <@jrandom> if not, moving on to 4) ??? +13:45 <@jrandom> anything else anyone wants to bring up? i'm sure i've missed soem things +13:45 <+detonate> i2p's known to work with the sun jvm in OpenBSD 3.7 :) +13:45 <@jrandom> nice! +13:47 < bla> What is the status on the UDP transport? +13:48 <+detonate> udp is going to be messy, i think it would be better to steal the pipelining code from bt and adapt it ;) +13:48 <@jrandom> *cough* +13:49 <@jrandom> i dont expect there to be much trouble, but there's certainly work to be done +13:49 <@jrandom> how the queueing policy operates, as well as the bw throttling for admission to the queue will be interesting +13:50 < bla> Who was doing that prelim work? +13:50 <@jrandom> bla: detonate and mule +13:50 <+detonate> yeah.. i've been slacking off the last month or so though +13:50 < bla> detonate: I assume you jest, with your BT remark? +13:51 <+detonate> i'm half-serious +13:51 <+detonate> you could at least cut the thread count for the transport in half if you did that +13:51 * jrandom flings a bucket of mud at detonate +13:51 < jdot> woohoo. my router is now running on my dedicated server rather than my POS cable connection. +13:51 <@jrandom> nice1 jdot +13:52 <@jrandom> we'll be able to get by with 3-5 threads in the transport layer for all comm with all peers +13:52 < bla> detonate: But half is not going to cut it, when the net becomes large (> couple hundred nodes) +13:52 < jdot> with 1000GB of b/w at its disposal +13:53 < jdot> unforunately j.i2p and the chat.i2p will be down for a few more hours while i migrate things +13:53 < duck> detonate: addressbook on halt too? +13:53 <+detonate> yeah, it's on halt too +13:54 <+detonate> the only thing that isn't on halt is the monolithic profile storage, i was meaning to get that working later today +13:54 <@jrandom> w3rd +13:54 <+detonate> then i2p won't fragment the drive massively +13:54 < jdot> jrandom: as far as BW limits go, are they averages? +13:54 <+frosk> modern filesystems don't fragment, silly +13:55 <+detonate> ntfs does +13:55 <@jrandom> jdot: the bandwidth limits are strict token buckets +13:55 <@jrandom> jdot: if you set the burst duration out, thats how long of a period it averages out through +13:56 <@jrandom> (well, 2x burst == period) +13:56 <@jrandom> ((ish)) +13:56 < jdot> hmmm... well i have 1000GB and want i2p to be able to take up to 800GB/mo.... +13:56 <+ant> <mihi> detonate: ntfs stores really small files in mft which means nealy no fragmentation +13:57 < jdot> and i dont care what it bursts to +13:57 <+detonate> well, when you run the defragmenter, it spends 10 minutes moving all 6000 profiles around.. so they must fragment +13:58 <@jrandom> jdot: hmm, well, 800GB is probably more than it'll want to push anyway, so you can probably go without limits ;) +13:58 <@jrandom> otoh, if you could describe a policy that you'd like implemented, we might be able to handle it +13:58 < jdot> jrandom: i'll do that for now and see how it works +13:58 < bla> detonate: NTFS, IIRC, is a journalling FS. So even a monolotic file will get fragmented if you write small portions to it +13:58 <+detonate> everything gets written at once +13:59 <+detonate> and read at once +13:59 < bla> detonate: Ok. I see. +13:59 < jdot> jrandom: well, lets wait until we figure out if it'll even be a problem. +13:59 < bla> detonate: Good work in that case! +13:59 <+detonate> i'd be interested in knowing how much usage there really is if you leave it uncapped +14:00 <+detonate> on a good connection +14:00 < jdot> i'm interested too! +14:00 <@jrandom> my colo routers run uncapped, though cpu constrained +14:00 <+Ragnarok> can you use a bitbucket to average over a month? +14:00 < jdot> jrandom: cpu contrianed? what kind of cpu? +14:01 <@jrandom> 4d transfer 3.04GB/2.73GB +14:01 <+detonate> hmm, was expecting less +14:01 <@jrandom> jdot: cpu constrained because i run 3 routers on it, plus a few other jvms, sometimes profiling +14:01 <+detonate> must be those bt people +14:01 <+detonate> once the batching stuff is online, it would be interesting to see how that changes +14:02 <@jrandom> detonate: some of that transfer is also me pushing 50MB files between itself ;) +14:02 <+detonate> heh +14:02 < jdot> ahh. ok. well, we'll see how this system does. its an AMD XP 2400 w/ 512MB and a 10Mbit connection +14:02 <@jrandom> Ragnarok: token buckets dont really work that way +14:02 <@jrandom> jdot: word, yeah, this is a p4 1.6 iirc +14:03 <@jrandom> Ragnarok: in a token bucket, every (e.g.) second you add in some tokens, according to the rate. if the bucket is full (size = burst period), the tokens are discarded +14:04 <@jrandom> whenever you want to transfer data, you need to get a sufficient amount of tokens +14:04 <@jrandom> (1 token = 1 byte) +14:04 <+Ragnarok> I know how they work... what happens if you just make the bucket really big? +14:05 <+detonate> then you never stop sending data +14:05 <+detonate> if it's infinite in size +14:05 <+detonate> err, and it's filled with tokens +14:05 <@jrandom> if its really big, it may go out and burst to unlimited rates after low usage +14:06 <@jrandom> though perhaps thats desired in some cases +14:07 <@jrandom> the thing is, you can't just set the token bucket to 800GB, as that wouldnt constrain the total amount transferred +14:08 <+detonate> you need a field there where you can set the number of tokens per second, then you can just divide the bandwidth usage per month by the number of seconds +14:08 <+detonate> :) +14:10 <@jrandom> thats the same as just setting the rate averaged over the month, which would be unbalanced. but, anyway, lots of scenarios available - if anyone has any that address their needs that can't be met with whats available, please, get in touch +14:10 <+Ragnarok> but if you set the rate to the average you want... I think 308 kB/s here, and then set the bitbucket to something very larger... why doesn't that work? +14:11 <+Ragnarok> s/larger/large/ +14:12 <+detonate> well, you could set it so that it never sends more than 800GB/44000 in a 60 second burst period +14:12 <+detonate> 44000 being roughly the number of minutes in a month +14:13 <@jrandom> the bucket size / burst duration describes how much we'll send without constraint, and most people /do/ want constraints, so the router doesnt gobble 10mbps for 5 minutes while draining the bucket (or whatever) +14:14 <@jrandom> an additional throttle of tokens coming out of the bucket is also possible (and should that throttle have its own token bucket, and that bucket have its own throttle, etc) +14:16 <+Ragnarok> I thought the bucket only got paid into when there was bandwidth not being used +14:16 <@jrandom> tokens are added to the bucket at a constant rate (e.g. 64k tokens per second) +14:17 <@jrandom> anything that wants bandwidth always asks the bucket +14:18 <+Ragnarok> ah.. ok +14:19 <@jrandom> ok cool, anyone else have anything they want to bring up for the meeting? +14:21 <@jrandom> ok if not +14:21 * jrandom winds up +14:21 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/134.rst b/i2p2www/meetings/logs/134.rst new file mode 100644 index 00000000..bd5e5348 --- /dev/null +++ b/i2p2www/meetings/logs/134.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 22, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/135.log b/i2p2www/meetings/logs/135.log new file mode 100644 index 00000000..d269af7a --- /dev/null +++ b/i2p2www/meetings/logs/135.log @@ -0,0 +1,119 @@ +13:13 < jrandom> 0) hi +13:13 < jrandom> 1) 0.5.0.5 +13:13 < jrandom> 2) UDP (SSU) +13:13 < jrandom> 3) Q +13:13 < jrandom> 4) ??? +13:13 < jrandom> 0) hi +13:13 * jrandom waves +13:13 * smeghead particles +13:13 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000661.html +13:14 < jrandom> (an hour early *mumblemumble*) +13:14 < jrandom> anyway, jumping in to 1) 0.5.0.5 +13:15 < jrandom> as mentioned in the status notes, there'll be a new release later this evening +13:15 < jrandom> everyone who is not yet on 0.5.0.4 should upgrade ASAP, as you'll be unable to talk to 0.5.0.5 users +13:15 < jrandom> all 0.5.0.4 users should upgrade as soon as 0.5.0.5 is out, as well +13:16 <@smeghead> will the update work through the new trusted update facility in the router console? +13:17 < jrandom> yes and no +13:17 < jrandom> of course, 0.5.0.4 has a bug in the NewsFetcher, where it doesn't write to a temp file, but instead resumes /over/ the existing file +13:18 < jrandom> so, given the way that the NewsFetcher detects updates, it won't see the later "hey, 0.5.0.5! get it!" info +13:18 < zzz> yes if you want to wait 12 hours? there's no 'update now' button, is there? +13:18 < jrandom> otoh, once 0.5.0.5 is out and the news.xml is updated, 0.5.0.4 users can delete the file and it'll fetch it, detect it, and let you update +13:19 <@smeghead> what's the name of this file? +13:19 <@smeghead> oh ic +13:19 < jrandom> zzz: if news.xml doesn't exist or if it hasn't been modified in 12 hours, a new rev is fetched +13:20 < jrandom> there'll be a new i2pupdate.zip made available, as well as i2pupdate.sud +13:20 < jrandom> (though for later revs, the .zip may not be provided) +13:20 <@smeghead> should news.xml be in the base install dir? +13:20 < jrandom> smeghead: docs/news.xml +13:21 <+Myo9> Would it not good to get updates anonymous by default? +13:21 <+Myo9> s/not/"not be"/ +13:22 < jrandom> Myo9: last week bla offered a counterpoint to that - the fact that you're running i2p is not secret, and using your eepproxy to fetch it could let dev.i2p see what destination is used +13:22 <+frosk> anyone can tell you're running a router anyway +13:22 <+ant> <mae^> lalalala +13:22 < jrandom> just as it isn't a good idea to say on irc "hey, i'm restarting my router now", you dont want to associate your nyms with your router's activity +13:23 <+Myo9> Ok. +13:23 <+ant> * mae^ covers his ears +13:23 < jrandom> but, on the other hand, if dev.i2p were truely an anonymous host (aka we didn't know it was dev.i2p.net), we'd need support for it :) +13:23 <+ant> <mae^> dont talle me your goddamn network passwword +13:24 <+ant> <mae^> damnit +13:25 < jrandom> ok, anyone else have anything for 1) 0.5.0.5? +13:25 <+ant> <mae^> lets all take take a minute to thank jr ight now +13:25 <+ant> <mae^> silently and to yourself... +13:25 <@smeghead> mae^: how about after the meeting +13:25 < jrandom> heh, and to the donations page ;) +13:25 <+ant> <mae^> or to him and private is ifine too +13:26 <+ant> <mae^> or donate! +13:26 < jrandom> ok, moving on to 2) UDP (SSU) +13:26 < jrandom> we've got some thoughts on the new UDP protocol up on the web, and some critical feedback would be great +13:27 <+ant> * cervantes notes the royal "we" +13:27 <@smeghead> what is SSU +13:27 < jrandom> well, i may be the one who types it in, but we've all been discussing the issues ;) +13:28 < jrandom> SSU == Secure Semireliable UDP +13:28 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD +13:28 <+ant> <Eol> ??? got i2p up and running but can't resolve the .i2p sites .... states point browser at 4444 proxy but privoxy + tor already there ... site.i2p:4444 also fails ... ideas (w/o disabling privoxy or tor) +13:28 <@smeghead> Eol: --> #i2p-chat +13:29 < jrandom> Eol: perhaps some people in #i2p-chat can help, we're in the weekly dev meeting right now +13:30 < jrandom> the basic gist of things is that we'll be able to work around most NATs, but unfortunately not all of 'em. stats show that it'll work for a substantial % though (75-95, depending upon who you ask) +13:31 < jrandom> ok, thats that, really - if anyone has any questions/comments/concerns, feel free to bounce me or the list an email anytime +13:31 <+ant> * Eol apologizes +13:31 <@smeghead> the remaining should rebel against their tyrannical system admins +13:31 < jrandom> np eol +13:32 <@smeghead> (or splurge for a real net connection) +13:32 < jrandom> or get a non-symmetric NAT +13:32 <+frosk> (or wait for restricted routes) +13:32 < jrandom> yeah, or wait for 2.0 :) +13:32 <@smeghead> because really, if you're concerned about freedom of information and anonymity, you shouldn't subject yourself to such NAT restrictions beyond your power anyhow +13:32 < jrandom> smeghead: not everyone has a choice in the matter +13:33 < jrandom> for instance, we had a user here the other day from the UAE, where there is ONE isp, with their own NAT +13:33 <@smeghead> very true, but there are also people who expect us to bend over backwards to support them when they should be getting their power back +13:33 <@smeghead> right +13:34 < jrandom> aye, we'll support what we can, and what we can't, well, we can't, yet +13:34 <@smeghead> the more people bend over for their ISPs, the more ISPs will restrict their users, and the harder our task becomes +13:37 < jrandom> ok, anyone else have anything for 2) UDP? if not, moving on to 3) Q +13:37 < jrandom> hmm, looks like aum isn't up yet :) +13:37 < jrandom> but basically, lots of cool stuff up @ http://aum.i2p/q/ +13:38 <@smeghead> i think i speak for aum when i say, "zzzzzzzzzzzzzZZZz" +13:39 < jrandom> ok, i dont know if i have anything to add beyond whats in the email, beyond "neat stuff, talk to aum" :) +13:40 < jrandom> ok, moving on at a rapid rate to 4) ??? +13:40 < jrandom> anyone else have anything they want to bring up? +13:41 < cervantes> whoa a sub half hour? +13:41 < jrandom> first i get the meeting notes out an hour early, and now this! +13:41 <@smeghead> time for a filibuster +13:41 < jrandom> *cough* +13:41 <+postman> :) +13:41 < jrandom> ok, if there's nothing else, i can get back to packaging up 0.5.0.5 and y'all can download when its ready :) +13:41 <+postman> ok, just wanted to announce v2mail.i2p +13:42 * cervantes wheels out a ming dynasty china gong +13:42 < jrandom> ooh word postman +13:42 <+postman> as official portal to the v2mail deleopment +13:42 <+postman> the html layout eats babys +13:42 <+postman> but still i hope you find the docs/whitepapers there interesting +13:43 <+postman> the documentation will be updated over the next week +13:43 <@smeghead> could you say a little about what v2mail is? +13:43 <@smeghead> v2 like version 2, or like the rocket? +13:43 <+postman> smeghead: the new decentralized mailservice for i2p 1.0 +13:43 <+postman> smeghead: v2 refers to the version +13:44 * postman does not plan any mailbombs or rockets :) +13:44 <@smeghead> does it have specific dependencies on 1.0, or is that just a target? +13:45 <+postman> there's still a few months work ahead - updates will be announced there +13:45 <+frosk> nice effort, postman +13:45 <+postman> smeghead: no, there're no dependencies on 1.0 - you'll still continue using susimail or your own mua +13:46 <+postman> frosk: thanks +13:46 <+postman> jrandom: k, /me hands back the microphone +13:47 <+ant> <cervantes> *distant clapping* +13:47 < jrandom> w3rd, it definitely looks cool +13:47 <+postman> cervantes: hey, what about your firefox plugin? +13:47 < jrandom> ok, anyone else have anything to add to the meeting? +13:48 <+ant> <cervantes> postman: eerm still plugin away at it +13:49 <+postman> cervantes: me want play with it :) +13:50 <+ant> <cervantes> just getting through a tedious part of managing user preferences...then all should be ready for a test release +13:50 < jrandom> wikked +13:50 <+postman> c00l :) +13:52 <+ant> <cervantes> on an aside...I seem to have persuaded a few mozilla developers to look into modifying the codebase so I can easily add URI filtering into the plugin (ie I will be able to guarantee no connections to non-i2p addresses are being made) +13:52 < jrandom> oh, nice! +13:52 <+ant> <cervantes> but that won't be in firefox for a couple of releases +13:53 < jrandom> great, please keep us updated +13:53 <+ant> <cervantes> will do +13:54 < jrandom> ok, if there's nothing else... +13:54 * jrandom winds up +13:54 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/135.rst b/i2p2www/meetings/logs/135.rst new file mode 100644 index 00000000..110319c6 --- /dev/null +++ b/i2p2www/meetings/logs/135.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 28, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/136.log b/i2p2www/meetings/logs/136.log new file mode 100644 index 00000000..4c3539dd --- /dev/null +++ b/i2p2www/meetings/logs/136.log @@ -0,0 +1,97 @@ +14:34 <@jrandom> 0) hi +14:34 <@jrandom> 1) 0.5.0.5 +14:34 <@jrandom> 2) Bayesian peer profiling +14:34 <@jrandom> 3) Q +14:34 <@jrandom> 4) ??? +14:35 <@jrandom> 0) hi +14:35 * jrandom waves +14:35 * smeghead outsources his todo list to a parallel universe +14:35 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-April/000675.html +14:36 <@jrandom> might as well jump on in to 1) 0.5.0.5 +14:36 <+ant> * Connelly waves +14:37 <+protokol> high everyone +14:37 <@jrandom> as mentioned in the status notes (and the current history.txt), we've tracked down some very long lasting netDb bugs +14:37 <@jrandom> in the past, we've been able to fudge it, but 0.5.0.5 forced us to start doing things "right", which is why its been biting us now +14:39 <@jrandom> i expect we'll have a new release sometime tomorrow, so keep an eye out for the update link on your router console :) +14:39 <+protokol> yey +14:39 <@jrandom> actually, thats about all i have on that at the moment - anyone else have anything to add wrt 0.5.0.5? +14:40 <+protokol> nope +14:41 <@jrandom> ok, moving on to 2) Bayesian peer profiling +14:41 <@jrandom> ah, damn, bla dropped off the channel a few mins back +14:42 <@jrandom> well, anyway, I just wanted to point people out at bla's work exploring some more robust profiling techniques +14:42 <+protokol> postponing 2? +14:43 <@jrandom> check out the forum post and the link to theland.i2p for more info, and bounce bla your thoughts :) +14:44 <@jrandom> ok, movin' on to 3) Q +14:44 <@jrandom> aum: you up? +14:44 <@jrandom> hmm, doesnt look like it +14:45 <@jrandom> ok, lots of progress on the Q front, more details for getting involved in alpha testing up @ http://aum.i2p/q/ +14:45 <@jrandom> i'm sure we'll hear more on the list when there's an update available +14:46 <+ant> <Connelly> Q works for me for retrieving content +14:46 <@jrandom> yeah, its been working great for me as well, a few bumps here and there, but quite promising +14:47 <+ant> <Connelly> my Q server stored 2 small items, then got stuck at 100% cpu usage until i killed it +14:47 < zzz> for those who haven't seen it check out my q front end http://flock.i2p/cgi-bin/q +14:47 <@jrandom> zzz: that is quite kickass +14:48 * jrandom forgot the url to that when writing up the status notes (d'oh) +14:50 <@jrandom> ok, anything else on 3) Q? or shall we move on to 4) ??? +14:50 * jrandom considers us moved +14:51 <@jrandom> anyone have anything else they'd like to bring up for the meeting? +14:51 <+ant> <Connelly> i've coding an http/html filter for i2p +14:51 <+protokol> yes +14:51 <+protokol> ian clarke is a troll on slashdot +14:51 <+ant> <Connelly> been coding +14:51 <+ant> <Connelly> should be more safe than freenet's html filterer +14:51 <+ant> <Connelly> if i run out of time i'll just incorporate freenet's filterer +14:51 <@jrandom> cool Connelly, how is it coming along? +14:52 <@jrandom> protokol: and you're a troll in #i2p ;) +14:52 <+ant> <Connelly> so in the end we should have an html filterer for i2p +14:52 <+ant> <Connelly> got html filtering done, now working on css, still haven't looked at header filtering +14:53 <+ant> <Connelly> it's very paranoid :) +14:53 <@jrandom> bitchin +14:53 <+protokol> whitelist? +14:53 <@duck> does it let anything trough at all? +14:53 <+ant> <Connelly> yeah +14:53 <+protokol> if so, what is currently disallowed +14:53 <+protokol> (of any importance) +14:55 <+ant> <Connelly> disallowed of significance: frames and iframes, scripting, optgroup +14:55 <+ant> <Connelly> meta +14:55 <+ant> <Connelly> embedded objects +14:56 <@jrandom> neat. i'm looking forward to seeing how things progress - any eta on when we could try rigging it up with the eepproxy? +14:56 <+ant> <Connelly> i'll probably have an alpha in 1-2 weeks +14:57 <+ant> <Connelly> so we can test out how it works +14:57 < jrandom2p> kickass +14:58 <+ant> <Connelly> it allows forms, cookies, content caching but those can be turned off in 'paranoid' mode +14:58 <+protokol> why frames and iframes? can you just not block connections to non-i2p sites from them? +14:59 <+ant> <Connelly> it has a cgiproxy like url navigator bar at the top +14:59 <+ant> <BS314159> I suspect the hard thing would be blocking frames between different eepsites +14:59 <+ant> <Connelly> i don't want that hijacked +14:59 <+protokol> i mean can you just block connections +14:59 <+ant> <Connelly> could make it like freenet's proxy where you just enter a url at the beginning +14:59 <+protokol> yeah, frames can rock +14:59 <+ant> <Connelly> and can't enter urls once you start browsing +14:59 < jrandom2p> frames kill kittens +15:00 <+ant> <BS314159> this has to be the oldest framewar ever. excuse me, flamewar +15:00 < jrandom2p> heh +15:00 <+protokol> i said "can" rock +15:00 <+ant> <BS314159> what we need is our own browser +15:00 <@jrandom> and flying ponies +15:01 <@jrandom> *cough* +15:01 <+ant> <Connelly> i'd prefer an F-16 to a pony +15:01 < Teal`c__> can i have a girl ? +15:01 <+ant> <Connelly> i'll make an option for enabling frames +15:01 <+protokol> Teal`c__: no +15:02 <+ant> <BS314159> Is there a functioning I2P inproxy? bolas.mine.nu appears to be dead. +15:02 <+protokol> from other eepsites, right? +15:02 <@jrandom> BS314159: http://i2p.mine.nu/ +15:02 <+protokol> i2p.mine.nu +15:02 < frosk> i2p.mine.nu +15:02 <+ant> <BS314159> thanks +15:02 <+ant> <BS314159> frames are safe if they're inside one eepsite. frames are safe if all content is static +15:03 <+ant> <BS314159> the only danger is if there's a form in one of the frames, since you might submit information to the wrong party +15:04 <@jrandom> eh, i'm of the opinion the filter should only support what we *need* (and know is safe), and let actual end user demands expand functionality, rather than preemptively assume people will want some things +15:04 <+ant> <BS314159> wise +15:06 <@jrandom> ok, anyone else have anything for the meeting? +15:06 < Teal`c__> sorry didn't know a meeting was on +15:07 <@jrandom> heh no worry, you'll be immortalized in the meeting logs ;) +15:07 <@jrandom> speaking of which +15:07 * jrandom winds up +15:07 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/136.rst b/i2p2www/meetings/logs/136.rst new file mode 100644 index 00000000..9e649b1c --- /dev/null +++ b/i2p2www/meetings/logs/136.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 5, 2005 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/137.log b/i2p2www/meetings/logs/137.log new file mode 100644 index 00000000..6bbfa33f --- /dev/null +++ b/i2p2www/meetings/logs/137.log @@ -0,0 +1,280 @@ +14:05 < jrandom> 0) hi +14:05 < jrandom> 1) Net status +14:05 < jrandom> 2) SSU status +14:05 < jrandom> 3) Bayesian peer profiling +14:05 < jrandom> 4) Q status +14:05 < jrandom> 5) ??? +14:05 < hummingbird> 7) Profit +14:06 < jrandom> damn, i messed up y'all's agenda :) +14:06 < jrandom> hi +14:06 < jrandom> weekly status notes posted /before/ the meeting up @ http://dev.i2p.net/pipermail/i2p/2005-April/000683.html +14:06 < gott> jrandom: try it again +14:06 <+cervantes> never mind, this meeting gott off onto a bad footing anyway +14:06 < jrandom> *cough* +14:06 < jrandom> jumping in to 1) Net status +14:07 < jrandom> the big problem we were seeing with the netDb has been fixed and confirmed dead in the wild +14:07 < jrandom> there are still some other issues, but it seems on the whole to be fairly reasonable +14:08 < frosk> any idea what's causing the weird dnfs sometimes? +14:08 < gott> confirm; I can get my illegal porn at record speeds for i2p now. +14:08 <+cervantes> seems like that might be a hard one to pin down +14:08 < jrandom> sneaking suspicion that its some confusion related to the throttle on the tunnel building +14:09 < jrandom> pulling out those throttles will probably address it, but could be painful for users with slow CPUs +14:09 < jrandom> otoh, perhaps we could make them optional, or someone could write some smarter throttling code +14:10 < frosk> i see +14:10 <+cervantes> the throttle seems much more pro-active than previous versions on my system +14:10 < jrandom> yeah, we delay tunnel building when there are too many outstanding - before we just said "ok, we need to build X tunnels. build 'em" +14:10 <+cervantes> can we not make the threshold tweakable? +14:11 < jrandom> aye, that we can +14:11 < gott> jrandom: optional +14:11 < gott> so users with thin i2p servents can still be productive +14:12 < jrandom> my attention is focused elsewhere at the moment, so if someone wants to dig into that, the key method is TunnelPoolManager.allocateBuilds +14:12 < jrandom> (or if no one jumps at it, i can toss in some tweaks when the next build comes out) +14:13 <+cervantes> ........@ <-- tumbleweed +14:13 < jrandom> :) +14:13 < jrandom> anyone have anything else for 1) net status, or shall we move on to 2) SSU? +14:14 * gott mutters something about too much talk and too little action when it comes to the i2p community +14:14 <+cervantes> perhaps in the future we can introduce performance profiles into the console +14:14 < gott> jrandom does too much on the development side. +14:14 <+cervantes> so people can choose a preset batch of config options for high/med/low spec systems +14:15 < jrandom> ooh good idea cervantes, there's lots of room for variants. while we want to automatically tune ourselves as best we can, it may be easier for humans to do it +14:15 <+cervantes> since there are many that seem to be using low spec machines and modem connections atm +14:15 < gott> cervantes: yeah, excellent idea. +14:15 <+cervantes> I should publish my fire2pe todo list...it has lots of shit like that in it ;-) +14:16 < gott> based on processor and network speed primarily ? +14:16 < jrandom> a site with a pseudonymous todo list would be nice +14:16 < gott> that is a good idea. +14:16 <+cervantes> well the bandwidth limiter should ideally take care of net speed +14:16 < gott> in typical google-fashion, have a bunch of 'thin i2p servents' in your LAN. +14:17 <+cervantes> jrandom: ugha.i2p? +14:17 < jrandom> perhaps +14:19 < jrandom> ok, anything else for 1) net status? +14:19 * jrandom moves us on to 2) SSU +14:19 < jrandom> Lots of progress on the UDP front (SSU == Secure Semireliable UDP) +14:19 < gott> someone should alias 'i2pwiki.i2p' to that +14:20 <+cervantes> I guess that's up to ugha ;-) +14:20 < jrandom> the general overview of whats up is in the email, and a lot more technical details (and a pretty picture ;) is up on my blog +14:21 <+ant> <godmode0> udp is safe ? +14:21 <+ant> <godmode0> how :) +14:21 < jrandom> http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html <-- how +14:22 <+ant> <godmode0> hehe +14:22 <+ant> <godmode0> i2p not found right ip my computer +14:22 < jrandom> sorry, if you don't have i2p installed, change "dev.i2p" to "dev.i2p.net" +14:22 <+ant> <godmode0> have installled +14:23 <+ant> <godmode0> but not work +14:23 < jrandom> ok, perhaps we can debug that after the meeting +14:23 <+ant> <godmode0> oops in meeting again sorry +14:23 < jrandom> hehe np +14:25 < jrandom> anyway, as i said, the general plan of how things are going is in the email +14:25 < jrandom> anyone have any questions/comments/concerns wrt SSU? +14:26 <+Ragnarok> will throughput/latency be much different than the tcp transport? +14:27 < jrandom> my hope is that the cause of the lag spikes will be addressed, but i'm not making any particular predictions. +14:28 < jrandom> if we can keep latency in the same ballpark as it is now and get rid of the spikes, we can jack back up the throughput +14:29 <+Ragnarok> cool +14:29 < gott> will there be documentation on the implementation provided on i2p.net ? +14:30 < jrandom> much of my time when i go offline to move will be writing up docs to be put on the website, yes +14:30 < gott> awesome \m/ +14:30 < jrandom> we do have some pretty good implementation docs at the code level for the core and router, but no great overall router architecture docs yet +14:31 < jrandom> anyway, if there's nothing else on 2) SSU, lets shimmy on over to 3) Bayesian peer profiling +14:32 < jrandom> we got a brief update from bla earlier this evening, as shown in the status notes +14:32 <+bla> I'm still here though... ;) +14:33 < jrandom> bla may atcually still be around to give us any further thoughts or answer questions - +14:33 < jrandom> ah, there you are +14:33 < defnax> jrandom : what do you think about anounce i2p bittorrent Tracker, for security i think is not good or?, +14:34 <+bla> The IRC discussion quoted by jrandom shows the general idea. Summarized: +14:34 < jrandom> defnax: perhaps we can discuss that further in 5) +14:34 < defnax> ok i can wait +14:34 <+bla> The eventual idea is to use both round-trip-time information obtained from explicit tunnels tests, and implicit information from client-tunnel tests, into one node-speed estimation framework +14:35 <+bla> For now, I use information obtained from explicit tunnel tests only, as for those tests, all participating peers are known. +14:36 <+bla> A naive Bayesian classifier framework will be used to estimate a peer's speed, given the tunnels in which it has participated (in any position), and how fast those tunnels were +14:36 <+bla> In order to compare things to a "ground truth", I've obtained "actual" peer speeds as listed in the status notes +14:37 <+bla> Results are very prelim. But http://theland.i2p/estspeed.png shows the correlation between actual speeds, and speeds inferred using the Bayesian framework +14:37 <+bla> Well. Any questions or comments? +14:38 < jrandom> comment: looks promising. +14:38 <+ant> <BS314159> it seems like the total tunnel speed provides a hard lower bound on the speed of every participating peer +14:38 <+detonate> comment: seem to be a few outliers +14:38 <+ant> <BS314159> is that incorporated? +14:39 < jrandom> BS314159: total tunnel speed? oh, do you mean the testing node's net connection? +14:40 <+bla> BS314159: That does provide a lower bound, yes. This is not addressed yet, but will be: The naive Bayesian framework enables weighting different samples (RTT measurements) to different degrees. Very fast RTTs will be weighted by a larger factor in the future +14:40 <+ant> <BS314159> I mean the total bandwidth of a given tunnel +14:40 <+bla> BS: The results show _latency_ measurements, for now +14:40 <+ant> <BS314159> right. +14:41 <+ant> <BS314159> nevermind, then +14:41 < jrandom> ah, right, certainly. throughput measurements will require further modifications to test with different size messages +14:41 < jrandom> otoh, the implicit tunnel tests are driven by larger messages (typically 4KB, since thats the streaming lib fragmentation size) +14:42 <+bla> detonate: Yes, there are outliers. There will always be _some_ (that's inherent to estimation, and modeling in general). However, the separation between really slow and really fast clients (putting a threshold at around 400 ms), is ok-ish +14:42 <+detonate> ok +14:43 <+bla> jrandom: Indeed. Once I get that working (in not a Java buff...), I'll also test using the larger messages +14:43 <+bla> detonate: Now, I'd like to make the separation between fast and really-fast peers in a better way. +14:43 < jrandom> cool, i'll see if i can bounce you a modified TestJob for that +14:44 <+bla> I'll report when I have new results. +14:44 < jrandom> kickass +14:45 < jrandom> ok cool, anyone else have anything for 3) Bayesian peer profiling? +14:46 < jrandom> if not, moving on to 4) Q status +14:46 < jrandom> As mentioned in the email, rumor has it Aum is making progress on a new web interface +14:47 < jrandom> i don't know much about it, or the status details on the rest of the Q updates, but i'm sure we'll hear more soon +14:48 < jrandom> anyone have anything on Q to bring up? or shall we make this a rapid fire agenda item and move on to 5) ??? +14:49 < jrandom> [consider us moved] +14:49 < jrandom> ok, anyone have anything else to bring up for the meeting? +14:50 < jrandom> defnax: announcing an i2p tracker to people in the i2p community would be great. to the outside world it might be a bit rough, since we aren't at 0.6 yet +14:50 < gott> Yes. +14:50 < jrandom> (or 1.0 ;) +14:50 < gott> I have some information to bring up on userland documentation efforts. +14:51 <+mancom> just for the record: on mancom.i2p there is a c# implementation of Q's client api (in its first incarnation) +14:51 < jrandom> oh cool, sup gott +14:51 < jrandom> ah nice1 mancom +14:51 < gott> I have previously written userland documentation for 0.4 i2p. +14:52 < jrandom> which i unforutnately obsoleted by changing a whole bunch of stuff :( +14:52 < gott> But it is entirely out-of-date with current i2p. +14:52 < gott> Accordingly, I am very interested in writing a defacto set of documentation that we can either (a) bundle with i2p or (b) have access via i2p. +14:53 < jrandom> wikked. docs to bundle with i2p (localized to the user's language, etc) would be great +14:53 <+cervantes> cool +14:53 < gott> I don't suggest bundling, but it is still a possible option, as a user can't access eepsites to read the manual if he doesn't know how to use or configure i2p ;-) +14:53 < gott> Okay. +14:53 < gott> But is it overkill ? +14:53 <+ant> <BS314159> what respectable program comes without man pages? +14:53 <+cervantes> and is it worth waiting til 1.0? +14:54 < gott> That is another question. +14:54 < jrandom> since development is fairly fluid, it might be worth focusing on context-specific help, rather than an overall user guide +14:54 < gott> BS314159: these are not manpages, as it will be platform-independent. Probably HTML. +14:54 <+cervantes> how much more structural changes are we due before then +14:54 < jrandom> for instance, it'd be nice to have better docs describing what the different config options *mean*, what their implications are, etc. +14:55 < gott> Okay, so I shall write an english and french localisation of a manual for i2p. +14:55 <+jdot> actually, we could use the inproxy to access the documentation even w/o i2p being installed. +14:55 < gott> Two major questions : +14:55 < jrandom> those could be kept up to date by virtue of being *in* the interface itself +14:55 <+cervantes> yeah context help would rock +14:55 < gott> (1) Bundled or accessible via manual.i2p ? +14:55 < gott> (2) For which version ? +14:55 < gott> yes +14:55 < jrandom> gott: i'm not sure it'd be wise to build a user guide yet +14:55 < gott> that's a great idea +14:56 < gott> do you mean to use the auto-update function to update the usermanual ? +14:56 < gott> jrandom: okay +14:56 < gott> but then how do you suggest context-specific help ? +14:56 < jrandom> oh, we can certainly deploy updates to the docs with the update process +14:56 <+cervantes> if/when it's time to do a manual then perhaps a manual.war can be dropped into a user's webapps folder if they want local access to the docs +14:57 < gott> I am thinking of a user-manual. +14:57 < gott> or a HOWTO. +14:57 < gott> I have no idea what you mean by context-specific help. +14:57 < gott> it's pretty straightforward. +14:57 < jrandom> gott: for instance, a set of human (non-ubergeek) readable info explaining wtf things on /config.jsp mean. that info would go *on* /config.jsp, or on an html page reachable from that config.jsp +14:58 < jrandom> a user-manual or howto would be great, but not until 1.0 +14:59 < jrandom> there's already some work on that front in the forum @ http://forum.i2p.net/viewtopic.php?t=385 +14:59 < gott> jrandom: yes. +14:59 < gott> well. +14:59 < gott> the information on config.jsp is pretty straightfoward already +15:00 < jrandom> otoh, we see questions about what bandwidth limits actually do, how the burst rates work, etc here all the time. it'd be great to have the answers on the page, rather than have people ask +15:00 < gott> heh +15:00 < jrandom> gott: its straightforward to you because you've been using i2p for almost two years +15:00 < gott> nevermind, 'configtunnels.jsp' could use some work. +15:00 < gott> okay. +15:00 <+cervantes> straightforward to the initiated perhaps, a n00b would be lost +15:01 < gott> this is, then, a more up-to-date selection of tasks : +15:01 <+cervantes> not sure the best way to present the help from an interface perspective +15:01 < gott> (1) Context-specific help on the webpages localised to user's language. A configuration variable can be set for the language interface, by default, loaded from $LANG path variable on linux +15:02 < gott> I'm not sure how java figures out the default locale under windows. +15:02 < gott> But this is a good start to localisation and documentation writing. +15:03 < gott> (2) For version 1.0, a HOWTO _accessed_ via i2p +15:03 < gott> I don't suggest bundling the HOWTO, as that is just overkill. Would be nice to keep i2p as small as possible, hmm ? +15:03 < jrandom> dood, its html. its tiny. even if its huge, html compresses *really* well +15:03 < jrandom> having a local manual would be very much preferred +15:03 < jrandom> especially since we can push updates +15:03 * gott shrugs +15:04 < gott> I suppose. +15:04 < gott> I just find it silly. +15:04 < gott> when you can just download it via the web. +15:04 < gott> but on the other hand, if the user can't figure out how to use i2p +15:04 < gott> he can't. +15:04 <+ant> <Synonymous2> Is aum around, i was looking at the specs for QuarterMaster +15:04 <+ant> <Synonymous2> * In order to help client-side searching, all data items are accompanied +15:04 <+ant> <Synonymous2> by a simple metadata schema - so far, just consisting of: +15:04 <+ant> <Synonymous2> - key - text name of key +15:04 <+jdot> put it on www.i2p.net so it is accessible via the intarweb and i2p. +15:04 <+jdot> and always up to date +15:05 < gott> yeah. +15:05 < gott> well, just use the update mechanism. +15:05 < gott> okay. +15:05 < gott> so, finalising : +15:05 < jrandom> sure, we can put it on the website too. we can spam it all over the net if it helps ;) +15:05 <+ant> <Synonymous2> I am wondering if Aum can implement the datastore so the metadata are seperated incase he wants to upgrade the storage system. Remember when Freenet wanted to change the storage system but was stuck +15:05 < gott> 1 : Localised interface and context-specific help. +15:05 < gott> 2 : Localised HOWTO for version 1.0 +15:05 <+ant> <Synonymous2> oopse is this the meeting :) +15:05 < gott> Any additions ? +15:06 < gott> the HOWTO will cover a lot of extra i2p-network features. +15:06 < gott> where to get the latest porn ( j/k ) +15:06 <+ant> <BS314159> manpage! :-) +15:06 < gott> manpages aren't platform-independent +15:06 < jrandom> cool, including things like Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto +15:06 <+cervantes> the installer could be localised too I guess... +15:06 < gott> the i2p network has a hilariously large amount of french users +15:07 <+Ragnarok> you should clearly write the addressbook documentation I've never gotten around to :) +15:07 < gott> I'm sure they would appreciate a localised interface so they don't have to look at the disgusting english language +15:07 <+cervantes> hey it's mostly french already +15:07 < gott> true. +15:07 < gott> good ideas. +15:08 < gott> well, that is all I had to say. +15:08 < jrandom> ok cool, thanks gott, nice initiative +15:08 < gott> for now, I shall start on the context-specific stuff +15:08 < jrandom> Synonymous2: I'm not sure what Aum is doing on that front +15:08 < jrandom> bitchin' +15:08 < gott> and then, when a localisation option is added, the localised languages +15:08 <+bla> gott: Je _deteste_ Anglais! ;) +15:09 < gott> moi aussi +15:09 <+ant> <Synonymous2> Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto, i think the wiki article should be updated for i2p to add this, i'll do that +15:09 <+cervantes> ewll you have william the conquerer to blame for that +15:09 < jrandom> heh +15:09 < gott> a wiki is good, but also non-official. +15:09 < gott> the manual has the element of certification. +15:09 < gott> it is more reassuring. +15:10 <+ant> <Synonymous2> if ppl want to come and look that would be helpful too, the freenet wikipedia article is also good describing the tools for freenet. As well, I see that the Freenet webpage is released under the GNU FDL, if i2p.net could do the same (or public domain) I could copy some stuff to wikipedia :)) if you want to do that +15:10 <+cervantes> we'd still be speaking anglo-saxon otherwise +15:10 < jrandom> everything i do which i 'have rights to' is released implicitly into the public domain +15:11 <+ant> <Synonymous2> i thought it was, if you can put that as a blurb on the webpage that would be great at your convience, the ppl at wikipedia are anal bout copyright :> +15:11 <+ant> <Synonymous2> :))) +15:11 < gott> jrandom: all the localisation I write will be public domain +15:11 < jrandom> otoh, outright copying the text is, er, not too helpful, as your copies will be out of date - just link to it, the web is there for a reason +15:11 < gott> I don't give a damn about any licenses. +15:12 < gott> also, last question : +15:12 <+ant> <Synonymous2> i was going to copy a few things like the chart and some graphics hehe +15:12 < gott> where are the .jsp for the router located ? +15:12 < jrandom> gott: http://dev.i2p/cgi-bin/cvsweb.cgi/apps/routerconsole/jsp/ +15:13 < gott> ah +15:13 < gott> so, locally, they are in a .jar ? +15:13 < jrandom> gott: routerconsole.war +15:13 < jrandom> but you can't really edit them there, as they're precompiled into java +15:13 * gott nods +15:13 < gott> Sure. +15:14 < gott> Though, that's an inconvenience. +15:14 < gott> when localisation comes out, that might be changed ? +15:14 < jrandom> yep. lots of options though. if you work out the html that the jsps should render as, we can wire it in +15:14 <+cervantes> Synonymous: http://www.i2p.net/licenses +15:15 < gott> so you can have language packs +15:15 * gott nods +15:15 < gott> for now, it is just hardcoded +15:15 < jrandom> localization in java works by loading up per-language properties files with resources +15:15 < gott> but later on, it should be less restricted, I suggest +15:15 < jrandom> right right +15:16 < gott> awesome. +15:16 < gott> well, I'll use anonymous CVS then ;-) +15:16 < jrandom> bitchin' +15:16 <+ant> <BS314159> bla: is your raw data available anywhere? +15:16 < jrandom> bla has recently disconnected, but we'll see about getting some data available +15:17 < gott> btw, do we have anyone running i2p on openbsd ? +15:17 <+ant> <BS314159> it's be fun to let people try their own estimators +15:17 <+ant> <BS314159> sister:...23? +15:17 < jrandom> gott: yeah, i think detonate is +15:18 <+ant> <BS314159> ack +15:18 <+ant> <BS314159> cross-post +15:18 <+ant> <BS314159> curses! +15:18 < gott> is it even possible ? what are the java limitations regarding openbsd and i2p ? +15:18 < gott> okay. +15:18 < jrandom> BS314159: yeah, there's some good info about modifying your estimators up in the forum +15:18 <+cervantes> long meeting +15:18 < gott> if I ever have time, I might get it running and setup a port. +15:18 < gott> but that is long off and someone will probably do it before me ;-) +15:18 < jrandom> cervantes: check the logs, we've broken 2h before ;) +15:19 < jrandom> ok, anyone else have anything for the meeting? +15:20 < jrandom> if not +15:20 * jrandom winds up +15:20 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/137.rst b/i2p2www/meetings/logs/137.rst new file mode 100644 index 00000000..34c42580 --- /dev/null +++ b/i2p2www/meetings/logs/137.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 12, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/138.log b/i2p2www/meetings/logs/138.log new file mode 100644 index 00000000..ad0bac53 --- /dev/null +++ b/i2p2www/meetings/logs/138.log @@ -0,0 +1,100 @@ +14:05 <@jrandom> 0) hi +14:05 <@jrandom> 1) Net status +14:05 <@jrandom> 2) SSU status +14:05 <@jrandom> 3) Roadmap update +14:05 <@jrandom> 4) Q status +14:05 <@jrandom> 5) ??? +14:05 <@jrandom> 0) hi +14:05 * jrandom waves +14:05 <@jrandom> weekly status notes (posted a sec ago) up @ http://dev.i2p.net/pipermail/i2p/2005-April/000708.html +14:06 * maestro^ beatboxes +14:06 <+cervantes> evening +14:06 <+protokol> susi23: you there? +14:06 <@jrandom> while y'all read those exciting notes, lets jump on in to 1) net status +14:06 <+protokol> oops, meeting +14:07 <@jrandom> i dont really have much to add beyond what it says though. new release tomorrow, most likely, with the fixes incorporated so far, as well as some neat new contributions +14:08 <@jrandom> anyone have any comments or concerns w/ the net status &&/|| the upcoming 0.5.0.7? +14:10 <@jrandom> if not, moving on to 2) SSU status +14:10 <+maestro^> i've been getting some of these errors: Wanted to build 2 tunnels, but throttled down to 0, due to concurrent requests (cpu overload?) +14:10 <@jrandom> ah, yeah, thats the tunnel throttling issue +14:10 <+protokol> will it support ftp? +14:10 <@jrandom> its a bit... overzealous +14:10 <+protokol> jk jk +14:10 <@jrandom> !thwap protokol +14:10 <+maestro^> heh, ok +14:12 <@jrandom> ok, as for SSU, there's been a bunch of updates in the last week, and still further changes locally not yet committed +14:13 <@jrandom> i havent been making any history.txt entries for the updates though, since its not used by anyone yet, so only people on the i2p-cvs list get to read the exciting details ;) +14:14 <@jrandom> otoh, in the last few days after things have been pretty much working, while streamlining its operation i've found some choke points in the SDK +14:14 <@jrandom> (and in the jobQueue). i've pulled those out now, locally, and testing continues. +14:15 <@jrandom> we may have some alphas for the SSU transport this week, more likely this weekend though +14:15 <@jrandom> not much more i have to say on that - anyone have any questions? +14:16 <+Ragnarok> how much impact did the choke points have? +14:17 <@jrandom> well, it varies - i'm measuring the impact upon the live net now, but on my local ssu network, two minor tweaks gave more than an order of magnitude improvement +14:17 <@jrandom> but i don't expect that to occur on the live net +14:17 <+Ragnarok> yikes +14:18 <+Ragnarok> heh, ok +14:18 <@jrandom> (at least, not until we move to 0.6 ;) +14:20 <@jrandom> ok, following that lead, lets move to 3) Roadmap update +14:21 <@jrandom> as mentioned in the notes, the dates and revs on the roadmap have been moved around. 0.5.1 dropped, with the further tunnel modifications pushed to 0.6.1 +14:21 <+cervantes> 3) Roadmap Skew +14:21 <@jrandom> heh +14:22 <@jrandom> yeah, when you run a fast CPU, it skews the clock more frequently. similary... ;) +14:22 <@jrandom> ^ry^rly +14:23 <+cervantes> ooh is that a hint of an ego? I never would have thought! :) +14:23 <@jrandom> but yeah, unfortunately, a 0.6 rev in april just isnt going to happen +14:23 <@jrandom> hehe +14:23 <@jrandom> cervantes: dont worry, its tempered by the fact that its taken 2 years to get this far ;) +14:25 <@jrandom> we will probably have some -X builds for people to brea^Wtest SSU on the live net while i'm offline, but there won't be a 0.6 rev until i'm back +14:25 <@jrandom> (and, like last year, i have no idea how long it'll take to get hooked up again, but hopefully less than a month) +14:25 <+cervantes> heh, if anyone here is a little deserving of self-appreciation then I guess it would be you ;-) +14:26 <+polecat> Where you going, jrandom ? +14:27 <+cervantes> $somewhere +14:27 <@jrandom> dunno +14:27 <@jrandom> (thankfully, $somewhere is a runtime expression ;) +14:27 <+cervantes> jrandom: do you envisage a months downtime? +14:27 <+maestro^> jr: walk around the neighborhood and setup a wireless relay network from someone else's link ;] +14:27 <@jrandom> depends on the internet situation where i end up cervantes. +14:28 <@jrandom> i'm quite likely to hop online occationally of course, though +14:28 <+protokol> polecat: lol +14:28 <+cervantes> I would have though you would have got the relocation class method pretty slick by now +14:28 < Teal`c> lets move to .6 now and work the bugs out as we go along +14:28 <+cervantes> *thought +14:28 <+cervantes> cool, Teal'c you can do Q&A +14:29 <@jrandom> Teal`c: "work the bugs out" == fix the code == (have a coder who knows the code to fix it) +14:29 < Teal`c> ya, I'd like that. +14:29 < Teal`c> I know some perl +14:29 * cervantes sets bugzilla > tealc@mail.i2p +14:29 <@jrandom> word Teal`c, we can always use some help testing +14:30 <@jrandom> especially in automation of tests +14:31 <@jrandom> ok, anything else on 3) or shall we move to 4) Q status +14:31 <+polecat> I see. Good luck getting stable Internet back. +14:31 <+ant> <jrandom> hrm, aum seems to be sleeping still +14:31 <@jrandom> thanks. i'm sure i'll find a way ;) +14:32 <@jrandom> ok, I don't really have much more to add beyond whats in the status notes +14:32 <@jrandom> aum's code is in cvs now though, so the hardcore can grab it and start hacking +14:32 <+maestro^> shweet +14:33 <@jrandom> yeah, definitely. currently things are all GPL (since one component links against I2PTunnel), but I hear aum is working on some refactoring so it'll end up LGPL +14:34 <@jrandom> (but dont ask me what the implications of licensing is when it comes to xmlrpc ;) +14:34 <@jrandom> ok, anyone have anything on 4) to bring up? +14:36 <@jrandom> ok, if not, moving on to 5) ??? +14:36 <@jrandom> anyone have anything else to bring up for the meeting? +14:36 <+polecat> I would like to say a few words for this occasion. +14:37 <+polecat> Hinkle finkle dinkle doo. +14:37 <@jrandom> mmmhmm. +14:37 <@jrandom> ok, anyone have anything to bring up in a human language? :) +14:38 < defnax> what moving on 5? +14:39 <+maestro^> long live spacerace! long live i2p! +14:39 <@jrandom> hmm defnax? +14:41 < defnax> on 5 o'clock in the morning? +14:41 < defnax> in 5 hours? +14:41 <+cervantes> wrt xmlrpc, copyright is retained on the specification, but no restrictions placed upon implementation +14:42 <@jrandom> defnax: agenda item 5: "???", where we discuss other issues +14:43 <+maestro^> jr: have you committed those optimization changes? +14:43 <@jrandom> cervantes: my jab related to the question of whether using a GPL'ed app's xmlrpc API is viral (but merely a rhetorical question) +14:43 <@jrandom> maestro^: nope +14:43 * jrandom tests before committing +14:43 <+maestro^> excellent! whats your eta on that? +14:44 <@jrandom> later tonight, maybe, else tomorrow for the release +14:45 <@jrandom> ok, if there's nothing else +14:45 * jrandom winds up +14:45 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/138.rst b/i2p2www/meetings/logs/138.rst new file mode 100644 index 00000000..fcbc0e0e --- /dev/null +++ b/i2p2www/meetings/logs/138.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 19, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/139.log b/i2p2www/meetings/logs/139.log new file mode 100644 index 00000000..a5228acb --- /dev/null +++ b/i2p2www/meetings/logs/139.log @@ -0,0 +1,58 @@ +14:10 <@jrandom> 0) hi +14:10 <@jrandom> 1) Net status +14:10 <@jrandom> 2) SSU status +14:10 <@jrandom> 3) Unit test bounty +14:10 <@jrandom> 4) ??? +14:10 <@jrandom> 0) hi +14:10 * jrandom waves +14:10 <@jrandom> (late) weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-April/000723.html +14:10 < bla> hi +14:11 <@jrandom> while y'all read that tome, lets jump on into 1) Net status +14:12 <@jrandom> the previous set of problems we saw with some eepsites going offline in 0.5.0.6 seems to be resolved, though there are a few people who have been running into other problems with their sites +14:13 <@jrandom> i've seen some increased torrent activity at some trackers as well, though it hasn't caused any problems on irc from what i can tell +14:13 < laberhorst> net status: fairly well beside the not reachable prob :-) +14:13 <@jrandom> heh +14:13 <@jrandom> yeah, i'm stil not sure whats going on with your site. we can debug further after the meeting +14:14 <@jrandom> other than that, anyone else have any questions/comments/concerns wrt the net status / 0.5.0.7? +14:16 <@jrandom> ok, if not, moving on to 2) SSU status +14:16 <@jrandom> [insert hand waving here] +14:17 < Lorie> Good morning. +14:17 <@jrandom> i know, i'm dragging my heels a bit by not pushing it out faster, and it does perform really well as is. still, there are some issues i'm not comfortable with yet, so y'all will have to bear with me a bit during this testing +14:18 <@smeghead> i commend you for not foisting crapware on us :) +14:18 <@jrandom> i'm hoping this week we'll have some further live net tests though (fingers crossed) +14:19 <@jrandom> well, i've foisted enough bugs on y'all so far +14:19 < Lorie> you're dragging your heels, are you ? +14:19 * Lorie eyes smeghead +14:19 < bla> jrandom: Just to make things clear: We could even have an intermediate period in which clients can be both UDP and TCP? +14:20 <@jrandom> bla: yes. i've got a test network now with some TCP-only and some both TCP and UDP. its kind of neat running the tunnels through both :) +14:20 <@jrandom> the live net will actually handle that as well, ignoring any UDP addresses (for people who don't yet support it) +14:20 <@smeghead> and that's given us lots of protein, but we don't want to over-indulge +14:21 < bla> jrandom: Nice! That's good for the transition +14:23 <@jrandom> aye, thats the hope. still, there's lots of work to do[/obligatory] +14:23 <@jrandom> while our transport is SSU - "SEMIreliable Secure UDP" - we still need to try to be kind of reliable +14:24 <@jrandom> i've followed a bunch of research out there on the net, watching whats worked best, and while we could just be lazy and fire & forget, there's a lot to be gained by doing some simple tcp-esque reliability, which is what i'm hacking on now +14:25 <@jrandom> otoh, since its just semireliable, if it doesn't get ACKed quickly we can just drop the message, rather than drop the connection +14:26 < Lorie> yes +14:26 < Lorie> do be reliable; time is a luxury one has +14:27 <@jrandom> thats about all i have to bring up for 2) SSU status. anyone have any questions/comments/concerns, or shall we move on to 3) Unit test bounty? +14:28 < jrandom2p> consider us moved +14:29 < jrandom2p> ok, duck posted up a good summary about whats up and the importance of the unit test bounty the other day, and there's a lot of detail referenced from the site. +14:30 < jrandom2p> this is a good chance for someone to dig into i2p a bit and get a little cash back in the process ;) +14:30 < jrandom2p> but anyway, y'all can read all that stuff. does anyone have any questions on it? +14:31 < jrandom2p> ok, if not, moving on to 4) ??? +14:32 <@smeghead> anyone tried that emma code coverage suite? +14:32 < jrandom2p> there's been a lot of various things going on in the last week, though i'm not sure whats ready for discussion yet. anyone have anything they want to bring up? +14:33 < jrandom2p> not i +14:33 <@duck> *hick* +14:34 <@smeghead> either duck is inebriated, or he has spotted a redneck +14:34 <@duck> !former +14:35 < jrandom2p> (to evaluate as a shell command or c/java... ;) +14:36 < jrandom2p> anyone else have anything to bring up for the meeting? +14:36 * jrandom2p likes short meetings, leaves more time for coding +14:36 <@smeghead> and drinking apparently :) +14:36 <@duck> & drinking +14:37 <@smeghead> bah lag +14:37 < jrandom2p> heh +14:38 < jrandom2p> ok, time to get back to dri^Wworking +14:38 * jrandom2p winds up +14:38 * jrandom2p *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/139.rst b/i2p2www/meetings/logs/139.rst new file mode 100644 index 00000000..4b354d95 --- /dev/null +++ b/i2p2www/meetings/logs/139.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 26, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/140.log b/i2p2www/meetings/logs/140.log new file mode 100644 index 00000000..3ab4212a --- /dev/null +++ b/i2p2www/meetings/logs/140.log @@ -0,0 +1,193 @@ +14:08 < jrandom> 0) hi +14:08 < jrandom> 1) Net status +14:08 < jrandom> 2) SSU status +14:08 < jrandom> 3) i2phex +14:08 < jrandom> 4) awol +14:08 < jrandom> 5) ??? +14:08 < jrandom> 0) hi +14:08 * jrandom waves +14:08 < jrandom> weekly status notes posted nearly an hour early @ http://dev.i2p.net/pipermail/i2p/2005-May/000738.html +14:09 * Masterboy waves back:P +14:10 < jrandom> ok, jumping into 1) Net status +14:10 < jrandom> i don't really have too much more to add, though it does appear that we may be up for some turbulance from the azureus influx +14:11 < jrandom> hopefully it'll hold up well enough though, we'll see +14:11 < Masterboy> no big probs for me and i can't remember the little ones. +14:11 < jrandom> heh cool +14:11 < jrandom> anyone else have any questions/comments/concerns wrt the current net status? +14:11 < sirup> is azureus using out proxies? +14:12 < jrandom> heh i hope not +14:12 < jrandom> its probably just people trying it out after seeing the option listed +14:12 <@smeghead> most will bugger off in a week or so +14:13 < Masterboy> :D +14:13 <+DrWoo> smeghead: that's not good +14:13 < sirup> so they wrap two different networks under one hood +14:13 <+cervantes> it's not mentioned in the az release notes +14:13 <+cervantes> although it is listed in the plugins section +14:14 < ant> <cat-a-puss> There is a link that mentions it on the left of their main page +14:14 < jrandom> it'll be great once 0.6 is out and we can handle the increased user load +14:14 <+DrWoo> jrandom: what is the current status of getting out a build to cope with more users? +14:14 < jrandom> yeah, azureus is currently our largest referrer to the website, well more than even the /. references +14:15 < jrandom> DrWoo: no chance. +14:15 < sirup> don't let that stress you and put out 0.6 too early +14:15 * eAi sets unreasonable bandwidth limit to stop people haxoring my download speed +14:15 < ant> <cat-a-puss> how big of a network will .6 support? +14:15 < jrandom> DrWoo: 0.6 is the solution, and that'll be ready when its ready :) +14:15 <+cervantes> there are 445 google hits for "i2p" and "azureus" +14:15 < jrandom> heh eAi +14:16 <+cervantes> I must say I was impressed with the throughput of the test SSU net +14:16 < Masterboy> w00t cervantes:) +14:16 <+DrWoo> jrandom: you know I love ya but your shedule is slipping like a $5 hooker's panties ;) +14:16 < jrandom> cat-a-puss: it removes our current bottleneck to the point that i don't see the next bottleneck clearly. i hope it'll handle into the thousands. +14:16 <+cervantes> managed to max out my DSL connection with a straight http file transfer +14:17 < jrandom> damn straight DrWoo ;) if it could be done faster, that'd be great, but i've got to move next week, so there really isn't any alternative +14:17 < sirup> cervantes: 0 hops both ends ;) +14:18 < jrandom> sirup: sure, but the point is the SSU transport was able to handle it +14:18 <+DrWoo> jrandom: yikes that sux, good luck :) +14:18 < Teal`c__> there is an alternative. I'm calling toad, he'll finish it up while you're in tahiti +14:18 <@smeghead> movin' on up, to the east side, to a deluxe apartment in the skyyyyy +14:18 < shendaras> You have a place in mind, jrandom, or is it up in the air where you end up? +14:19 <+cervantes> *mute* +14:19 < jrandom> heh +14:19 < jrandom> i think i know what country i'll end up in. beyond that, not really +14:19 < jrandom> ok, anyway, back onto the agenda +14:19 < jrandom> anything else on 1) Net status, or shall we move on to 2) SSU status? +14:20 < Masterboy> move +14:20 < jrandom> consider us moved +14:21 < jrandom> ok, as described in the status notes and as cervantes said a minute ago, things are looking promising +14:22 < jrandom> this first round of live net tests caught a few bugs but also helped expose some of the tradeoffs in bandwidth, latency, and tcp-friendliness +14:23 < Masterboy> how can one join a test net?:P +14:23 < jrandom> thats the thing - the ssu testing is done on the live net +14:24 < jrandom> if you look in the netDb, you'll see that some peers have both TCP and SSU addresses, while almost everyone else has just a TCP address. +14:24 < jrandom> peers who know how to talk via SSU try that first, but fall back on TCP if the SSU port isn't reachable. +14:25 < jrandom> still, and i can't emphesize this enough, ssu is not production ready. it will break, and it will cause problems, so people should not use it except as part of explicit tests +14:25 < Masterboy> thanks:) +14:26 < jrandom> for now, everyone should disable ssu, but in the next day or so there'll be more info made available on my blog for the second round of tests +14:27 < jrandom> ok, i think that and the email covered pretty much what i have to bring up wrt ssu. anyone have any questions/comments/concerns? +14:27 < Teal`c__> jrandom: can we use ssu while your gone ? +14:28 < jrandom> probably, but people may want to talk to other users to see if it acts up, and if it does, just disable it +14:29 < shendaras> What's your new SACK technique? =) +14:29 < jrandom> i've still got almost a week of hacking time left, so there's going to be more improvement +14:30 <+bla> jrandom: I was just thinking... When there is a SSU connection between two nodes, do they drop the TCP connection between them (since that's not necessary then)? +14:30 < jrandom> heh shendaras, its just exploiting the small message size and fixed fragmentation to let the receiver transmit explicit ACKs/NACKs for a full message in a bitfield, rather than ACKing or NACKing each fragment separately +14:31 < jrandom> bla: correct, they never establish a TCP connection if SSU is available +14:31 < jrandom> the two transports 'bid' on each message being sent, and the SSU transport is configured to bid 'lower' than the TCP transport +14:31 <+bla> jrandom: That's good, but it means I'll have to update my theland.i2p scripts :(... ;) +14:32 < jrandom> heh well, yeah too bad ;) +14:32 < jrandom> (the new peers.jsp may be what you're after though) +14:33 <+bla> jrandom: I'll have a look. But I don't plan on using SSU until it is ready, though +14:33 <+cervantes> perhaps we should all stay on TCP so bla doesn't have to do any coding +14:34 < jrandom> heh +14:34 < jrandom> cool bla, yeah, no rush +14:34 <+cervantes> ;) +14:34 <+bla> cervantes: ;) +14:35 <+cervantes> will there be any situations where an SSU connection is not appropriate and a TCP one would be preferred? +14:36 * Masterboy pokes jr +14:36 < jrandom> the current default setup prefers an established TCP connection to an unestablished SSU connection +14:36 < jrandom> (you can override that with a config flag, i think its documented in the history.txt) +14:37 <@smeghead> there are some people who've claimed their ISPs block UDP altogether +14:37 < jrandom> but in general, no i can't think of why you'd want to go TCP when SSU is available +14:37 <+cervantes> yup I know about the config option...but I mean are there circumstances where it would be better to use TCP instead of UDP packets +14:37 < jrandom> smeghead: there are some people who've claimed elvis was a martian +14:38 <+cervantes> so it's good just as a fallback +14:38 < jrandom> cervantes: none i can think of, as long as ssu is available by both peers +14:39 < jrandom> perhaps as a fallback, though it does raise issues of restricted routes, as all peers must be able to contact all peers. +14:40 < jrandom> if we allow TCP only nodes, that means everyone must be reachable through TCP and UDP +14:41 < Teal`c__> :~( +14:41 < jrandom> for this summer, we'll probably support both, but i'm inclined to lean towards udp only +14:41 < entroy> Hi, can any one tell me where I can go to ask a q about setting up 12p and Azureus? +14:41 < jrandom> (until 2.0) +14:42 < jrandom> hi entroy, #i2p-chat may be able to help, or forum.i2p.net. we're in our weekly dev meeting at the moment, but can help you out afterwards if you're still having trouble +14:42 <+cervantes> here they come, repel borders :) +14:42 < jrandom> cervantes: anyone who can make it onto irc is one of us :) +14:42 <@smeghead> better call the Minutemen +14:43 < Teal`c__> liverpool or chelsea ?! +14:43 < entroy> ok, thx +14:43 < ant> <cat-a-puss> jrandom: WRT bitfields, if we assume most of the packets are going to be successfully received, then the bitfields would be almost all 1's. Wouldn't it be more efficent to list the number of NACKS and then encode them ECC style. +14:43 <+cervantes> jrandom: are you sure about that...someone mentioned an mschat client earlier +14:43 <+cervantes> ;-) +14:45 < jrandom> cat-a-puss: there are a few options, but when you look at the actual message size, its pretty hard to beat- tunnel messages, which are 4x as common as every other message, will require at *most* two fragments - only two bits +14:45 < Teal`c__> <steve> # Appears as TIKI +14:45 < jrandom> streaming lib messages between the endpoint and gateway is only 4KB - up to 8 bits, or 2 bytes wiwth the bitfields +14:45 < jrandom> that is, assuming the absolute smallest MTU +14:46 < jrandom> with 1492 (or 1472, depending on who is counting), you can handle most anything in a single bitfield byte +14:46 < ant> <cat-a-puss> jrandom: ah, so the bitfields are only for fragments, not for each packet then? +14:47 < jrandom> right, if a message is partially received, you send back the bitfield for the received fragments of that message +14:47 < ant> <cat-a-puss> ok +14:47 < jrandom> message ids are unfortunately completely random and unordered, so we can't use tcp style sequence numbers +14:48 < jrandom> (and, well, we dont want that overhead either) +14:49 < jrandom> ok, if there's nothing else on 2) SSU, lets move on to 3) i2phex +14:49 < jrandom> sirup: you 'round? +14:49 < ant> <cat-a-puss> quickly:why random? +14:50 * sirup is lurking +14:50 < jrandom> cat-a-puss: message ids are exposed to peers - we don't want them to know that one message is related to another message (the one with an earlier sequence #) +14:50 < ant> <cat-a-puss> ok +14:51 < jrandom> heya sirup, i posted up some general info to the list, but if you could give us an update, that'd be great +14:52 < sirup> well. first tests were successfull +14:52 < jrandom> [w3wt] +14:52 < sirup> but it also seems that we need tweaking with the time out settings. connections between peers don't hold up for some reason +14:53 < sirup> so it's not run and gun right now :) +14:53 < sirup> but i also expected that, cause i didn't change anything concerning timeouts and such +14:54 < sirup> generally, i would be happy if some people would be ready to help me test it until a bearable state is reached +14:55 < sirup> several instances on the same machine only get you so far... +14:55 < sirup> oh. and any experience/input is welcome. best done wiht mail to sirup@mail.i2p +14:56 < sirup> a forum would be great too (i can't have any at my destination, 'cause i'm not 24/7) +14:56 < sirup> that's it :) +14:56 < jrandom> wikked +14:56 < jrandom> cervantes: any way we could get an i2phex section added in there? +14:57 <+cervantes> sure could +14:57 * sirup wonders who's downloading that crappy commons licensed music from me :) +14:58 <@smeghead> hey, you can build more crap on top of that crap at least :) +14:58 <+cervantes> sirup: I take it "sirup" is your moniker on the forum +14:58 < sirup> that would be neat +14:58 < sirup> yes +14:59 < ant> <BS314159> status notes? +15:00 < jrandom> ok great. its looking really quite promising, sirup has done some great work, so people should swing over to sirup.i2p and read up on whats goin' on :) +15:00 <@smeghead> mailing list? +15:00 < RevDuck> or www.i2phex.tk +15:01 < sirup> mailing list would also be nice, of course +15:01 < sirup> lol. i2phex.tk is fake. get your dialers there :) +15:01 <+cervantes> I2Phex forum added +15:01 < jrandom> !stab duck +15:02 <+cervantes> sirup is moderator +15:02 < Masterboy> :D +15:02 <+cervantes> sirup: let me know if you want to change the description text +15:02 < jrandom> sirup: if you'd like an i2phex and i2phex-cvs list, lemmie know, they're easy enough to add +15:02 < jrandom> (though at the moment, it may be simpler to just use the i2p list) +15:02 < sirup> cervantes, thanks a bunch +15:03 < sirup> yeah. forum will do atm +15:04 < jrandom> ok cool. anyone have anything else on 3) i2phex? +15:05 < jrandom> if not, moving on briefly to 4) awol +15:05 < jrandom> i know y'all are chomping at the bit, looking for ways to contribute code to i2p, so the status notes have a few suggestions +15:05 <+bla> jrandom: You're finally being canceled by Operations? +15:06 < jrandom> nah, the CIA is just reassigning me^Ula la la +15:06 <@smeghead> no the black budget was increased this quarter +15:07 <+cervantes> *the elephant has flown the nest* repeat *the elephant has flown the nest* over +15:07 < jrandom> i dont really have much more to add to 4) than what was in the mail, though i'm sure y'all have plenty of other neat ideas +15:07 * smeghead supresses elephantitis joke +15:08 < jrandom> so your homework assignment while i'm gone is to pick something neat that you want to build, and build it ;) +15:08 * cervantes staunches smeghead's bleeding temples +15:08 < jrandom> (be it a webpage or a flying pony) +15:09 < jrandom> ok, moving on to 5) ??? +15:09 < jrandom> anyone else have anything they want to bring up for the meeting? +15:09 < shendaras> We'll miss you... +15:09 <@smeghead> yeah who's chairing the meetings while you're gone? +15:09 <+mancom> has aum shown up during the last week? +15:09 <@smeghead> mancom: negative +15:10 < Masterboy> brother duck?:P +15:11 < jrandom> our beloved operations manager will hopefully fill in, or y'all can draw straws for who has to write up status notes at the last minute :) +15:11 < jrandom> mancom: he was by #i2p-chat the other day briefly +15:12 < RevDuck> maybe only hold meetings when there is actually something to report though +15:12 <+cervantes> it's ok I'm writing a jrandom simulation script +15:12 <+cervantes> * w3wt +15:12 < jrandom> nothing wrong with 5 minute meeting ;) +15:13 <+cervantes> * jrandom flings a mud at his flying pony +15:13 * smeghead writes a cervantes simulation script that writes a jrandom simulation script +15:13 * jrandom writes a smeghead simu[CRASH] +15:13 <+cervantes> oop gotta work on that grammar +15:14 <@smeghead> haha +15:14 < jrandom> ok, anyone else have anything to bring up for the meeting? +15:14 * cervantes writes an aum simula......... +15:14 <@smeghead> java.util.RecursiveIdiocyException +15:15 < jrandom> speaking of which.. ;) +15:15 * jrandom winds up +15:15 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/140.rst b/i2p2www/meetings/logs/140.rst new file mode 100644 index 00000000..d72338e1 --- /dev/null +++ b/i2p2www/meetings/logs/140.rst @@ -0,0 +1,7 @@ +I2P dev meeting, May 3, 2005 +============================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/141.log b/i2p2www/meetings/logs/141.log new file mode 100644 index 00000000..fa86a384 --- /dev/null +++ b/i2p2www/meetings/logs/141.log @@ -0,0 +1,129 @@ +13:53 < jrandom2p> ok, as i'm here, is there anyone interested in having a brief meeting wrt the notes (or something else)? +13:54 < jrandom2p> anything in the notes people are concerned with, thoughts not related to 'em that people want to bring up, or other issues relevent and timely? +13:54 <@smeghead> sure +13:54 <+protokol> is icepick here? +13:55 <+protokol> i am wondering if i2p-mnet is testable yet and/or an ETA on it +13:55 < jrandom2p> idle for 9 hours atm.. +13:56 < jrandom2p> from the channel logs, it didnt sound workable, but he did get the basic SAM integration going +13:56 < jrandom2p> i'm sure we'll hear more when there's more to hear +13:56 <+protokol> cooool +13:57 < jrandom2p> smeghead: has -1 fixed your port migration issue? +13:57 <@smeghead> i haven't noticed any funny business +13:58 <@smeghead> in 3 days or so +13:58 <@cervantes> glad to say I haven't had a loss of service for a day or two +13:58 <@smeghead> i think i can call it fixed +13:58 < jrandom2p> wr0d +13:58 < jrandom2p> (^2) +13:59 <@cervantes> and thetower is only reconnecting every 4 minutes now...so the network health in general must be improving +13:59 < jrandom2p> heh +13:59 <+thetower> A fresh install seemed to fix the problem, but it was really quite disturbing and I never could find a good reason for it. +14:00 < jrandom2p> hmm +14:00 < jrandom2p> was it irc only, or were you losing many peers? +14:00 <@cervantes> gremlins +14:01 <+thetower> Is it possible that changing the router.config file without restarting i2p would have caused the crashes? +14:01 < jrandom2p> hmm, no, i change router.config often +14:01 < jrandom2p> or, is there a particular change you're concerned with? +14:02 <@cervantes> I remember copying over my jbigi lib once while the router was still running.... THAT caused problems ;-) +14:02 <+thetower> I set up some script to alter the bandwidth limits based on current network usage and I was wondering if that was causing the problem. +14:02 < jrandom2p> heh yeah cervantes, that'll always kill the router +14:03 < jrandom2p> ah ok, no, that shouldnt be a problem... though... if it altered the limits to be too small for messages to get through... +14:04 <+thetower> Well, it had fairly reasonable lower limits so I guess that wasn't it. +14:04 < jrandom2p> ok cool, just checkin~ :) +14:05 < jrandom2p> i suppose we'll have 0.6.0.1 tomorrow then, as -1 seems to be a pretty good improvement +14:05 < jrandom2p> it'll be backwards compat, etc, yadda yadda. +14:06 < jrandom2p> anything else y'all know that needs to get pushed out there? +14:06 < jrandom2p> whats the status with i2phex? +14:06 <@smeghead> maybe push the cvs hosts.txt to dev.i2p.net... the current one is months old +14:06 < jrandom2p> i did the other night iirc +14:07 <@smeghead> sirup hasn't been around in a couple of weeks +14:07 < jrandom2p> ooh, hmmm.. +14:07 <@smeghead> it's summer though +14:07 <@smeghead> maybe on holiday or something +14:08 <@cervantes> or he's been bum-raped by the riaa +14:08 < jrandom2p> ah yeah, its up there (it was just cached on squid.i2p) +14:08 <@smeghead> riaaped? +14:09 < jrandom2p> ($Id: meeting141.html,v 1.2 2005-08-04 16:21:39 duck Exp $) +14:09 < jrandom2p> *cough* +14:09 <+bar> there are some things that need to be added to bugzilla, like i2p 0.6 and java 1.5 +14:09 <@smeghead> ok +14:09 < jrandom2p> ah right, yeah i still havent gotten my laptop online yet (grr) +14:10 < jrandom2p> ((the weekly status notes needed to be burnt to cd... a 1KB cd...)) +14:10 < jrandom2p> woah heya mihi +14:10 <@duck> hi mihi! +14:10 < mihi> hi all :) +14:10 <@cervantes> could be dm :) +14:10 < jrandom2p> heh +14:10 <@smeghead> indeed +14:10 <@cervantes> 'lo mihi +14:10 < mihi> seemed to require a bit of tweaking in the config file till my router believed that *only* 8887/udp is open... +14:11 * jrandom2p mentioned i2ptunnel in the status notes and mihi appears ;) +14:11 < jrandom2p> ah, hmm, the i2np.udp.fixedPort=true thing? +14:11 < mihi> hmm? was it there? +14:11 * mihi read status notes only quickly +14:11 < mihi> hmm... is that better solution? +14:12 * mihi just reset the port to 8887 and restarted hard until it did not change the port... +14:12 < jrandom2p> whats the tweak you did to your router.config to make it believe only 8886? +14:12 < jrandom2p> er, 8887 +14:12 < jrandom2p> hah +14:12 <@cervantes> can we perhaps rename I2PTunnel as you suggested to something like I2PProxy...? +14:12 < jrandom2p> ok, yeah, use i2np.udp.fixedPort=true +14:12 < jrandom2p> (deployed in 0.6-1 and to be released asap as 0.6.0.1) +14:12 <@cervantes> it can get very confusing talking about "the tunnel config page" +14:13 <+thetower> Oh I have a question, isn't i2p supposed to automatically detect which udp port to use? And if so, is it supposed to be hard coded in the default router.config? +14:13 < mihi> hmmkay... +14:14 < mihi> seems that i2p changed the port once again +14:14 < mihi> expect me to be away soon :) +14:14 < jrandom2p> thetower: yes, it should automatically detect, but there are some funky tap dances that we~re going through at the moment +14:14 <@cervantes> mihi: d'you have the latest cvs? +14:14 < jrandom2p> thats what the whole PeerTest thing is about (making it so that we always automatically configure it properly) +14:14 < mihi> nope. +14:14 <@cervantes> mihi: that would be why then :) +14:15 < mihi> only the version from i2pupdate.zip +14:15 <@cervantes> mihi: 0.6 has RandomPort (tm) functionality +14:15 < jrandom2p> heh +14:16 <@cervantes> :) +14:16 <+ant> * mihi 'd like FixedPorto functionality :) +14:16 <+ant> <mihi> and disconnected... +14:16 <@cervantes> then you'd need 0.6-1 FixedPort Pro +14:16 < jrandom2p> heh +14:16 < jrandom2p> ok, anyone else have something to bring up for the meeting? +14:16 <@cervantes> or wait for 0.6.0.1 +14:17 < jrandom2p> how has the latency/throughput been, barring the intermittent reachability? +14:17 <+ant> <mihi> hmm. here is a cvs checkout from 2004-10-06. should try to update it :) +14:17 < jrandom2p> !thwap mihi +14:18 <@cervantes> I got i2pinstall.jar at 110k/sec from dev.i2p yesterday on a single stream +14:18 < jrandom2p> nice +14:19 <@cervantes> and 320k/sec using multiple +14:19 < jrandom2p> w0ah +14:19 < jrandom2p> 0hop, i assume +14:19 < jrandom2p> (dev.i2p is 0hop) +14:19 <@cervantes> yup +14:19 < jrandom2p> ((in case you couldn't tell ;) +14:19 <@cervantes> ;-) +14:19 <+thetower> download to: GTA San Andreas +14:19 <+thetower> download rate: 28.51 kB/s +14:20 <@cervantes> that was from multiple sources though... +14:20 < jrandom2p> ah cool thetower +14:20 <@cervantes> managed to push squid.i2p up to about 280 +14:21 < lucky> jrandom2p :) +14:21 < lucky> would you push the new hosts.txt to the site +14:21 <@cervantes> lucky: tis done +14:21 < jrandom2p> yeah, once we can consistently pull that sort of rate cervantes, we'll need to add on some configurable delays to let people do 0hops safely +14:22 < jrandom2p> (so it delays AVG(tunnelTestTime/2) but doesnt waste bw or lose messages) +14:22 <@cervantes> to hide the fact that it's a 0 hop tunnel? +14:22 < lucky> i wonder if I2P will ever have speeds decent enough tha ti could let people log into my virtu-vax +14:23 < jrandom2p> yeah. otherwise, if you say "hey i~m getting 300KBps from your site", you can pretty safely guess that its 2 0hop tunnels +14:23 < jrandom2p> (otoh, 1 to 2 to 3 to 4hops don't have such a dramatic cut) +14:23 <@cervantes> so will i2p effectively have a bandwidth cap +14:23 < jrandom2p> ((as once you force true tunnel operation, each intermediate hop isn't much)) +14:24 < jrandom2p> nah cervantes, large windows + delays +14:24 * cervantes cancels his plans for HDTV streaming anonymous pr0n +14:24 < jrandom2p> you can just have more messages in the air to get the same rate +14:25 <@cervantes> ah right +14:25 < jrandom2p> (but it'll take a few more rtts to get to the larger window, of course) +14:25 < jrandom2p> ok, anyone have anything else to bring up? +14:26 < mihi> bring up a *baf*er :) +14:26 <@cervantes> it's gone rusty with missuse +14:27 < jrandom2p> heh i suppose its time ;) +14:27 * jrandom2p winds up +14:27 * jrandom2p *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/141.rst b/i2p2www/meetings/logs/141.rst new file mode 100644 index 00000000..05e2081a --- /dev/null +++ b/i2p2www/meetings/logs/141.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 2, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/142.log b/i2p2www/meetings/logs/142.log new file mode 100644 index 00000000..73fb614a --- /dev/null +++ b/i2p2www/meetings/logs/142.log @@ -0,0 +1,88 @@ +13:11 < jrandom2p> 0) hi +13:11 < jrandom2p> 1) 0.6.0.2 +13:11 < jrandom2p> 2) roadmap update +13:11 < jrandom2p> 3) ??? +13:11 < jrandom2p> 0) hi +13:11 * jrandom2p waves +13:11 <+detonate> hi +13:11 < jrandom2p> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000839.html +13:12 < jrandom2p> ok, jumping in briefly to [1-2] before the freeforall.. +13:12 < jrandom2p> 1) 0.6.0.2 +13:12 < jrandom2p> its out. and stuff +13:12 < jrandom2p> anyone have any questions/comments/concerns w/ 0.6.0.2? +13:13 < jrandom2p> if not, moving on to 2) roadmap update +13:13 < jrandom2p> the, er, roadmap has been updated. and stuff ;) +13:14 < duck> you aussie +13:14 <+bla> jrandom: There still are intermittent problems contacting a destination, even when it's normally up +13:14 * postman can second this +13:14 * detonate can third that +13:14 <+bla> jrandom: E.g., forum.i2p works fine, then after a few minutes it doesn't, and requires a few reloads +13:15 * bla firsted it ;) +13:15 < jrandom2p> hmm, aye, i've heard reports of that. with 0.6.0.2 as well, right? +13:16 <+postman> indeed sir +13:16 <+bla> Yes, 0.6.0.2 +13:16 <+bla> Could be netDb trouble, or poor selection of peers to put in tunnels (or something else) +13:16 < jrandom2p> 'k +13:17 < jrandom2p> the tunnel peer selection has been pretty bad lately, as has netDb store flooding +13:17 < jrandom2p> (see your /oldstats.jsp for tunnel request failure counts) +13:18 <+bla> Now that we use UDP/SSU, peer classification seems to be better than before: a number of peers I _know_ to be fast, usually show up under the "fast" section on the profile pafe +13:19 < jrandom2p> nice +13:19 < jrandom2p> 0.6.0.2 added some tunnel rejection code based on the netDb that it should have been doing before (refusing to join if we can't find the next hop), so the increase in rejections is expected +13:19 <+bla> Though I really should get going at the classification algorithms again... ;) +13:20 < jrandom2p> i've been doing profile/stat analysis, but no solid results yet +13:21 < jrandom> that would be cool bla :) +13:25 < jrandom2p> ok, anything else on 2) roadmpa update? :) +13:26 < jrandom2p> if not, moving on to 3) ??? +13:26 <+detonate> do you think it would be useful to shitlist peers with high failure/duprecv rates compared to the mode? +13:27 < jrandom> hmm, i'm not sure about that - if the failure/dup rates are too high to be useful, we should just transfer slowly and carefully +13:27 < jrandom> as long as messages are getting through, messages are getting through +13:28 < jrandom> there's a reason why we haven't used stats on direct peer communication as part of our profiling - depending upon them would make us vulnerable to some easy and powerful attacks (acting differently to different peers and see who uses you, etc) +13:29 <+detonate> hmm +13:29 <+detonate> ok +13:29 < jrandom> but perhaps we need to drop sessions for peers who are in such congested cons +13:29 <+detonate> good point +13:34 < jrandom> ok, anyone else have something to bring up for 3) ??? +13:34 < luckypunk> o,oh, maybe you should wait ti leveryone is back +13:34 < luckypunk> before asking critical questions :P +13:35 < jrandom2p> bah, they've got the mailing list ;) +13:35 < luckypunk> well +13:35 < luckypunk> i guess this is the right place to whine +13:36 < luckypunk> I2P still uses a bit of CPU +13:36 < luckypunk> but not as much as before +13:36 < luckypunk> true, i haven't run it since the 5.0 days +13:36 < luckypunk> but yeah +13:36 < luckypunk> er +13:36 < luckypunk> 0.5.0 +13:36 < jrandom2p> cool, which of your boxes works with it? +13:36 < luckypunk> er +13:36 < luckypunk> ffs +13:36 < luckypunk> i haven't used it since 0.6.0.0 +13:36 < luckypunk> it works fine with the pentium 2 +13:37 < luckypunk> the default nice value mens it tends to crashif i do anything too CPU intensive for too long as I2P gets CPU starved +13:38 <+detonate> hmm, i guess there could be a space in the router console network config to hardwire the introducers, once there are introducers, if the user prefers +13:39 < jrandom2p> are you on 0.6.0.2 now luckypunk? +13:39 <@smeghead> detonate: that's trusted route stuff... later on in the roadmap :) +13:39 < luckypunk> no +13:39 < luckypunk> i haven't run it since 0.6.0.0 +13:39 <@smeghead> *restricted route +13:40 < luckypunk> but it's CPU use seemed much less. +13:40 <+detonate> heh, it should be there as soon as there's introducers :) +13:40 < jrandom2p> ah yeah detonate, the introducer selection could certainly be configurable, but it'll probably be a hidden advanced config option ;) +13:41 < jrandom2p> luckypunk: 0.6.0.1 cut out a lot of crypto, and 0.6.0.2 should help further. give it a try sometime, it may handle it better +13:41 < luckypunk> ok +13:41 <@smeghead> what if an introducer doesn't want you selecting them all the time? +13:41 < luckypunk> i have the feeling I2P would on a dedicated mid range pentium now. +13:41 < jrandom> smeghead: then they say "fuck off, i'm not going to serve as an introducer for you" +13:42 < jrandom> and peers will have multiple introducers, so it'll be balanced +13:42 < jrandom> (and its only 2 packets to wire up a new peer, not all packets communicated) +13:44 <+detonate> if introducers worked differently you could do a majority vote between them to decide which ones are working, but as it stands that doesn't make sense +13:45 < ant> <jme___> q. where can i find a description of this voting system ? +13:45 < jrandom> majority doesnt make any sense +13:45 * jrandom doesnt trust voting any further than i can throw it +13:45 < jrandom> (especially in light of sybil) +13:45 < jrandom> an introducer is working if a new peer can contact you through it +13:47 <+detonate> what's the status of vanguard, that's sort of related +13:47 <+detonate> while smeghead is around +13:51 < jrandom> ok, if there isn't anything else... +13:51 * jrandom winds up +13:51 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/142.rst b/i2p2www/meetings/logs/142.rst new file mode 100644 index 00000000..6aaa3fde --- /dev/null +++ b/i2p2www/meetings/logs/142.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 9, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/143.log b/i2p2www/meetings/logs/143.log new file mode 100644 index 00000000..6d26ce71 --- /dev/null +++ b/i2p2www/meetings/logs/143.log @@ -0,0 +1,50 @@ +13:09 <@jrandom> 0) hi +13:09 <@jrandom> 1) PeerTest status +13:09 <@jrandom> 2) Irc2P +13:09 <@jrandom> 3) Feedspace +13:09 <@jrandom> 4) meta +13:09 <@jrandom> 5) ??? +13:09 <@jrandom> 0) hi +13:09 * jrandom waves +13:09 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000842.html +13:10 <@jrandom> (which i'm sure you've all read studiously) +13:10 <@postman> hi +13:10 <+cervantes> hmm changate perl scripts...will give them a go... +13:10 <+cervantes> hi +13:10 <@jrandom> 1) peer test status +13:11 <@jrandom> not too much to add on this beyond what i posted in the notes - anyone have any questions/comments/concerns with it? +13:11 <@jrandom> i'm not sure whether to verify the remote reachability of everyone who connects to us, but i'm toying with that idea +13:11 <@jrandom> (we do that now with tcp) +13:13 <@jrandom> well, perhaps we can try it without that on a 0.6.0.3 before moving to 0.6.1. ve zhall zee +13:13 <@jrandom> ok, moving on to 2) irc2p +13:13 <@jrandom> y'all are here, so you know whats up :) +13:13 <@jrandom> nice work postman & smeghead +13:16 <@jrandom> ok, smeghead & postman have been putting out plenty of info on that thaang, so if there's nothing else y'all want to bring up on that, we can swing over to 3) feedspace +13:16 <@jrandom> frosk seems to have stepped out, and i don't really have anything to add beyond whats in the notes (and on his blog) +13:17 <@postman> :) +13:17 * Complication is reading frosk's blog +13:18 <@jrandom> ok, perhaps frosk'll fill us in with a post there when there's more info to share +13:19 <@jrandom> movin' on briefly to 4) meta +13:19 <@jrandom> what are y'all's thoughts on 8p GMT meetings? too early, too late, just right? +13:21 * jrandom holds back the crowds +13:21 <+Complication> I'd like to say something useful, but cannot seem to find my world clock... +13:21 <@jrandom> google://what+time+is+it +13:22 <+Complication> :) +13:22 <@jrandom> ok, movin' on to 5) ??? +13:22 <@jrandom> anyone have anything else they want to bring up? +13:23 <+susi23> well +13:23 <+susi23> not officially ;) +13:24 <+Complication> It's been an unusually stable time. +13:24 <+Complication> Aside from occasional "message invalid" (or was it "packet invalid"), I can't find errors to report. :o +13:24 <@postman> my errors are already reported :) +13:24 <@jrandom> coo', though thats unfortunately a symptom of undetected errors Complication, since there's still some stuff not going as it Should +13:25 <@jrandom> but, progress, ever onwards +13:25 <@jrandom> perhaps we're seeing a lot of restricted routes out there due to the udp situation +13:25 <+susi23> we started a new idlerpg on #idle and you are all invited to join :) +13:25 <@jrandom> (and perhaps there's a bunch of other things...) +13:25 <@jrandom> w00t susi23 +13:26 <+susi23> :P +13:30 <@jrandom> ok, anyone else have something to bring up for the meeting? +13:32 <@jrandom> ok, if there's nothin' else +13:32 * jrandom winds up +13:32 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/143.rst b/i2p2www/meetings/logs/143.rst new file mode 100644 index 00000000..2a6945dd --- /dev/null +++ b/i2p2www/meetings/logs/143.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 16, 2005 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/144.log b/i2p2www/meetings/logs/144.log new file mode 100644 index 00000000..bd1e82a8 --- /dev/null +++ b/i2p2www/meetings/logs/144.log @@ -0,0 +1,143 @@ +12:01 < jrandom> 0) hi +12:01 < jrandom> 1) 0.6.0.3 status +12:01 < jrandom> 2) IRC status +12:01 < jrandom> 3) susibt +12:01 < jrandom> 4) Syndie +12:01 < jrandom> 5) ??? +12:01 < jrandom> 0) hi +12:01 * jrandom waves +12:01 < lucky> hi +12:02 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000857.html +12:02 < lucky> hihihihi +12:02 < jrandom> hi lucky +12:02 < jrandom> ok, jumping into 1) 0.6.0.3 status +12:02 < jrandom> i think the biggest things worth mentioning wrt 0.6.0.3 are in the status notes, but beyond that, anyone have anything to bring up? +12:04 < gott> What's the deal with 'Unknown' ? +12:04 < jrandom> i'm not sure whether the ssu cwin improvements will come in 0.6.0.4 or will wait until 0.6.1 when we have better peer / configuration +12:04 < jrandom> gott: there are two paragraphs in the email related to that - do you have any specific questions beyond those? +12:05 < jrandom> or is there some point i could clarify? +12:05 < gott> No, I just haven't read the bloody email. +12:05 < jrandom> heh +12:05 < jrandom> well, scroll up five lines and read the bloody email ;) +12:06 < jrandom> ok, anyone else have any questions on 0.6.0.3? +12:07 < jrandom> if not, moving on to 2) IRC status +12:07 < modulus> sorry guys, but need to leave. later all. +12:08 < jrandom> beyond whats in the mail, postman/cervantes/arcturus: y'all have anything you want to bring up? +12:08 < jrandom> l8r modulus +12:08 <+arcturus> on 1)? +12:08 <+arcturus> oh sorry +12:08 < gott> Hmm. +12:08 <+arcturus> 2) it is now +12:09 < gott> How much upstream bandwidth does IRC over i2p usually take at the moment ? +12:09 <+arcturus> netsplits are history +12:09 <+arcturus> gott: i coudln't say that without compromising my router's anonymity +12:09 < gott> No, no, no. +12:10 < jrandom> not sure, my router with squid.i2p/dev.i2p/cvs.i2p/www.cvs/syndiemedia.i2p plus my irc and eepproxy uses on average 10-20KBps +12:10 < gott> Does it require a commercial line ? +12:10 < jrandom> nice1 arcturus +12:10 < gott> jrandom: I mean to say, to host. +12:10 < jrandom> gott: to operate a server or a client? +12:10 < jrandom> ah +12:10 <+arcturus> gott: i couldn't say that without compromising my router's anonymity +12:10 < gott> server. +12:10 * jrandom knows not. probably less when you have just one ircd +12:10 < gott> So are you running a modified unrealircd ? +12:11 < jrandom> say, add a factor of 1.3 to the client usage for a single server +12:11 <+arcturus> i'd like to also add that inter-server lag is steady and very very low +12:11 < gott> I assume you are, since there doesn't seem to be a VERSION command +12:11 <+arcturus> i disabled version +12:12 < gott> Are your modifications open-source ? +12:12 <+arcturus> maybe we're running unreal, maybe we aren't :) +12:12 < gott> You should put them up so others can start their own private networks. +12:12 <+arcturus> i can't tell you without compromising security +12:12 < gott> security through obscurity, sweet. +12:12 < jrandom> word arcturus. i'm seeing something like 0-2s lag on average (at the moment, less than irssi's lag detector) +12:12 <+arcturus> no, it's only one layer of security +12:13 <+arcturus> and it only serves as a deterrent, no substitute for technical security measures +12:15 < jrandom> arcturus: how goes with vanguard? +12:15 <+arcturus> i haven't coded on it lately, other projects have been occupying me, but there's a constant, steady pressure i feel to get around to finishing it :) +12:16 < jrandom> heh coo' +12:16 <+arcturus> vanguard will be most effective against bots, the hashcash measure is a separate deal +12:16 <+arcturus> i'm concerned about hashcash now though +12:17 <+arcturus> with the latest attacks against sha-1 +12:17 <+arcturus> it won't be long before there are tools available to the masses +12:17 <+arcturus> unfortunately the standard hashcash implementation is based entirely on sha-1 +12:17 < susi23_> Unable to find a javac compiler; // com.sun.tools.javac.Main is not on the classpath. // Perhaps JAVA_HOME does not point to the JDK +12:18 <@cervantes> ah made it +12:18 < susi23_> any ideas about this? JAVA_HOME points definitely to the right dir, javac is in PATH and callable +12:18 <+arcturus> susi23_: we're in a meeting atm :) +12:18 < jrandom> susi23_: OOM? +12:18 < susi23_> meeting? though its 8pm? +12:18 < jrandom> (precompile your jsps rather than letting jetty/tomcat do it, its faster ;) +12:19 < jrandom> yeah we moved it susi23_ :) +12:19 < susi23_> didn't know, sorry +12:19 < jrandom> hehe np, glad you made it for the meeting, your agenda item is up next ;) +12:20 * susi23_ sits down and listens +12:20 <+arcturus> so while i don't expect immediate problems with hashcash, i think it's feasible sha-1 could be seriously compromised soon +12:21 < jrandom> arcturus: hashcash with md5 would probably be fine +12:21 < jrandom> its just a PoW +12:21 <+arcturus> if anyone knows of any hashcash implementations based on sha256 or higher please met me know +12:21 <+arcturus> well PoW is pointless if there's little P in it :) +12:21 < jrandom> the size of the hash only matters when your hashcash reaches the size of the hash +12:23 < jrandom> (but, yeah, running against a truncated sha256 or 512 or whirlpool or whatever would be neat) +12:23 <+arcturus> i guess we could go ahead with the current implementation, perhaps we can design it so that we can swap it out easily later when we need to +12:24 < jrandom> (DTSTTCPW) +12:25 <+arcturus> because we will eventually need to drop sha-1, i'm sure of it :) and if we can't be reasonably certain a token was generated properly there's no reason to even be using hashcash +12:25 < jrandom> (its only for a PoW to get a nym on irc, not to get access to fort knox ;) +12:26 <@cervantes> there's some talk on the hashcash mailing list about implementing sha256 +12:26 <+arcturus> it's not for a nym, it's for entry to the server +12:26 <+arcturus> cervantes: cool i'll check that +12:27 <+arcturus> jrandom: and it's not just PoW, the hashcash is what gives us a method to uniquely identify clients on the network, akin to being able to identify by IP, so that we can ban with precision +12:28 < jrandom> certainly those are renewed over time though, right? +12:28 < jrandom> e.g. a new PoW cert every 6 months (or 6h, or whatever) +12:28 <+arcturus> if a user doen't have to do any work to get their ID, that nullifies our ability to ban them +12:29 <+arcturus> i don't know of any reason to expire them automatically, only expire them manually if they violate terms of service +12:29 <+arcturus> no need to make people do unnecessary work for new IDs +12:29 < jrandom> eh, its just a passive PoW, they can run one cycle every 6 hours to regenerate a new one +12:29 < jrandom> but perhaps DTSTTCPW +12:30 <+arcturus> any hashcash genereated must be used within 24 hours or it is invalid +12:32 <@cervantes> just to reiterate the new server irc.freshcoffee.i2p needs to be added into your i2ptunnel console +12:32 < jrandom> coo'. ok, anything else for 2) irc2p? +12:33 <@cervantes> (http://forum.i2p/viewtopic.php?t=911 +12:33 <@cervantes> ) +12:33 <@cervantes> <-- done +12:34 <+arcturus> i don't have anything else to bore you all with :) +12:34 < jrandom> hehe +12:34 < jrandom> ok, 3) susibt +12:34 < ardvark> um, when I add the new server to my tunnel, do I have to restart i2p? +12:34 < jrandom> susi23_: p1ng +12:35 <@cervantes> ardvark: just the tunnel +12:35 <@cervantes> (ircproxy tunnel) +12:35 < ardvark> oh ok, I just added and saved, so that is not enuff then +12:36 < jrandom> right, unfortunately you need to stop and start that proxy +12:36 < susi23_> well +12:36 < ardvark> but i'll miss the meeting then ;) +12:37 < susi23_> susibt is a webapp (like susimail) to drop into your routers VM +12:37 < susi23_> it acts as a web frontend for i2p-bt +12:38 < susi23_> so you can manage your seeds, up- and download files etc. +12:38 < jrandom> w00t +12:39 < susi23_> the prob is, you need to start a btdownloadheadless.py for each seed... so you get lot of python processes to your many java threads :) +12:39 <+arcturus> that will be addressed in ducktorrent *cough* +12:39 < jrandom> heh +12:39 * jrandom holds breath +12:40 < susi23_> it even supports restart of seeds after router restart +12:40 <@cervantes> nice +12:40 < jrandom> wikked +12:40 < susi23_> future plans are automatic build of torrents and ui improvement +12:41 < susi23_> if you want to try it out, I recommend a separate jetty instance +12:41 < susi23_> so you don't have to fiddle with your router :) +12:41 < susi23_> download and installation instructions on http://susi.i2p +12:42 < susi23_> thats all *ping back to jr* +12:42 < jrandom> w3wt, gracias susi +12:42 < jrandom> ok, anyone have any questions & comments on that, or shall we jump on over to 4) syndie? +12:44 < jrandom> ok regarding syndi, i've posted a bunch to the list about it over the last day or two, and there'll be lots more activity +12:45 < jrandom> the main demo site for syndie is http://syndiemedia.i2p / http://66.111.51.110:8000/, but of course people are encouraged to download it and install it locally +12:45 < jrandom> i dont have too much to add at the moment on that frnt. unless anyone has any questions? +12:46 < gott> Why is it called syndie ? +12:46 < gott> is it a reference to 'syndicate' ? +12:47 < jrandom> yeah, its a generic syndication frontend (+ security, authentication, and anonymity awareness) +12:48 < jrandom> ok, if there's nothing else on 4), lets jump on over to 5) ??? +12:48 < jrandom> anyone have anythin i2p related to bring up for the meeting? +12:51 < jrandom> ok, if there's nothing else +12:51 * jrandom winds up +12:52 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/144.rst b/i2p2www/meetings/logs/144.rst new file mode 100644 index 00000000..88ff16d8 --- /dev/null +++ b/i2p2www/meetings/logs/144.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 23, 2005 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/145.log b/i2p2www/meetings/logs/145.log new file mode 100644 index 00000000..8d51fadd --- /dev/null +++ b/i2p2www/meetings/logs/145.log @@ -0,0 +1,128 @@ +13:03 <+bla> Is there a meeting today? +13:04 < jrandom> 0) hi +13:04 < jrandom> 1) Net status +13:04 < jrandom> 2) floodfill netDb +13:04 < jrandom> 3) Syndie +13:04 < jrandom> 4) ??? +13:04 < jrandom> 0) hi +13:04 <+bla> ;) +13:04 * jrandom waves +13:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-August/000871.html +13:04 < jrandom> (yeah, i'm a few minutes late ;) +13:05 < jrandom> anyway, jumping into 1) net status +13:06 < jrandom> restricted routes suck, and we finally have some data as to how common they are (boo hiss) +13:06 < jrandom> but stil, the net seems fairly healthy, if you ignore all the worried reports of "omg it says status: Unknown!" ;) +13:07 < gloin> hmm.. where should be the document root for the i2p included webserver? +13:07 < jrandom> $i2pInstallDir/eepsite/docroot/ +13:07 < gloin> i2p/eepsite/docroot ? +13:07 < jrandom> anyone have any questions/comments/concerns regarding the net status outside of whats posted in the status notes? +13:08 < gloin> found it. it seems that the webserver won't deliver index.html automatically. +13:08 <+bla> jrandom: I have been doing some tests to check which nodes are selected in tunnels. +13:09 <+bla> jrandom: Mainly, as I've now implemented node-localization in the RouterInfo struct, I can see graphically (country flags) were tunnel participants are located. +13:09 <+bla> I am in Europe (no secret), and most of my tunnel participants are in Europe +13:09 < jrandom> gloin: it should serve up the index.html (thats what renders "Welcome to your Eepsite") +13:10 < jrandom> ooh nice1 bla! +13:10 < redzara> as some people have reported some low perf with UDP, maybe we could had a little perfmeter like iperf in I2P ? +13:11 < redzara> s/had/add +13:11 < jrandom> bla: so thats not just on the profiles.jsp page, but also on tunnels.jsp? v.cool... screenshots, screenshots! :) +13:11 < gloin> jrandom: now it works. strange. +13:11 <+bla> jrandom: I'll post some screenshots, but I first have to black out my own router-ID in the screenshots ;) +13:11 < jrandom> redzara: hmm, a command line utility to let people check their link quality, or a monitor for SSU performance? +13:11 < jrandom> heh bla +13:12 < jrandom> odd gloin +13:13 < gloin> jrandom: btw, since I updated my pppoe i2p seems to be more stable. +13:13 < jrandom> nice, what was the problem with your net connection? firmware update? +13:14 < gloin> jrandom: I lost all peers. But the internet connection was ok, but every peer failed. +13:16 < jrandom> right, but what did you update about your pppoe settings? +13:17 < gloin> jrandom: I mean the linux ppppoe deamon. +13:18 < jrandom> ah ok +13:18 < jrandom> ok, anyone else have anything for 1) net status, or shall we move on to 2) floodfill netdb? +13:18 <+bla> http://theland.i2p/parttunnels.jpg +13:19 <+bla> http://theland.i2p/servertunnels.jpg +13:21 <+bar> (umm.. inaccessible?) +13:21 < jrandom> yeah, i'm having trouble reaching it too +13:21 < fox> <godmode0> i use pppoe never be at problem i2p +13:22 * jrandom will try later though +13:22 <+bla> jrandom: Well.. There's new network problem just there ;) +13:22 < jrandom> hehe +13:22 < jrandom> bla: are you on -4 or an earlier build? +13:23 <+bla> jrandom: I'm on -4 +13:23 < jrandom> hmm, ok cool +13:23 < jrandom> ok, anyway, we can dig through that later +13:24 < jrandom> (if you could send me the netDb stats from /oldstats.jsp, that'd be great :) +13:25 < jrandom> ok, moving on to 2) floodfill netdb +13:26 < jrandom> there's lots of info posted to my blog on this topic +13:26 < jrandom> we've begun deploying a first pass, though there's still some work to be done +13:26 < jrandom> does anyone have any questions/comments/concerns on the plan? +13:27 <+bla> jrandom: Will the floodfill scale as log(N) (N=number of peers in the net), or linearly? +13:27 < jrandom> linearly with M (M= number of peers participating in the floodfill netdb) +13:28 < jrandom> well, M may be small enough that N is the dominant term +13:29 < jrandom> (in which case it'll be linearly with N) +13:29 < jrandom> which is not great, but until we have > 10K eepsites, it doesnt matter +13:30 < jrandom> once we do, then we can go into more advanced algorithms for sharing the load between the floodfill participants +13:31 < jrandom> (note thats 10k eepsites, not users, since we don't really need to publish client leaseSets in the netdb) +13:32 <+bla> jrandom: Is there a reason why we still do publish the client destinations in the netDb? +13:32 <+bla> jrandom: Or, for that matter, why we still show off who our fast peers are in the netDb? +13:33 <+bla> jrandom: Removing both would slash the netDb data by a big factor +13:33 < jrandom> bla: to the former, no. to the later, for me to debug (though i havent looked at that particular field recently) +13:33 < jrandom> aye, worth trying, perhaps in -5 +13:36 < jrandom> ok coo', well, we'll see and hopefully get -5 out in the next few days +13:37 < jrandom> (maybe tomorrow) +13:37 < jrandom> ok, if there's nothing else on 2) floodfill netdb, lets move on to 3) syndie +13:38 < jrandom> i posted a bunch of info in the mail and on my blog, so rather than rehash them, does anyone have any questions / comments / concerns? +13:40 * jrandom really digs the remote syndication functionality, though its far from what we're hoping for with feedspace integration +13:41 < jrandom> (i havent been bothered to do freenet posting integration, though it would be quite easy to fire up a CLI and post all the entries in) +13:42 < jrandom> ok, if there's nothing else on 3) syndie, lets open 'er up to 4) ??? +13:42 < jrandom> anyone have anything else i2p related to bring up? +13:42 < redzara> sure, where is the doc ;) +13:43 < laberhorst> just that my node under 0.6.x sonsumes up to 100% cpu load, but have to crosscheck it with linux on that line here +13:43 <+nickless_head> I think the i2pProxy.pac script should be in the jetty web folder by default. +13:43 < jrandom> nickless_head: i dont recommend i2pproxy.pac, as its a huge security risk +13:44 < redzara> 2 - could be have the latest build of jetty included in I2P ? +13:44 < jrandom> we've got 5.2.1 in i2p right now +13:44 < jrandom> er, 5.1.2 +13:44 <+nickless_head> jrandom: it's the only thing available for separating between eepsites and websites in one browser without having to switch by hand afaik +13:45 < jrandom> i use switchproxy +13:45 < jrandom> (and i dont switch to non-anonymous browsing) +13:45 < jrandom> ((squid.i2p is fast enough for me)) +13:45 <+nickless_head> Think of the slashdotters! :p +13:46 < jrandom> as i've said before, i have reservations about the viability of eepsites. the security risks are tremendous +13:46 < jrandom> but, for those who don't care about those risks, perhaps an i2pproxy.pac makes sense. +13:47 <+bla> I strongly think that something that isn't secure by _default_, shouldn't be in I2P, as to not give new users a false sense of secutiry +13:48 < jrandom> agreed (though we do push i2pproxy.pac, we just dont tell people about it until we scare 'em enough ;) +13:49 <+nickless_head> I somehow can't believe that within the configuration of Mozilla there isn't a way to make sites only access resources from the same domain .. +13:50 < redzara> sorry but IRC connection lost :( about jetty there is a fix about common logging and maybe this help me running my mvnforum in the same instance of I2P +13:50 < redzara> Jetty-5.1.5rc1 - 23 August 2005 +13:52 < jrandom> ah cool, whats the problem exactly redzara? +13:52 < jrandom> nickless_head: if you find a way, let us know +13:52 < redzara> or maybe i could even only build my own I2P with the latest version of jetty +13:52 < jrandom> redzara: that you certainly can do - just drop in the jetty jar files into your i2p lib directory +13:53 < redzara> jrandom : everythime i try to start mvnforum in I2P, jetty failed to find apache common logging +13:53 <+nickless_head> Oh! I just noticed that the default i2pproxy.pac uses a mode which allows sites to switch proxy'ing to i2p on and off at runtime, which is protected by the TOTALLY SECURE AND UNBREAKABLE </sarcasm> default password "passw0rd". Please, someone who knows about cvs change this. +13:54 < jrandom> redzara: thats in commons-logging.jar and commons-el.jar iirc, which should be in your lib dir and in your wrapper.config's classpath +13:54 < jrandom> nickless_head: yet another reason why i dont recommend anyone use it ;) +13:55 < redzara> yes i know, i'm not so n00b :)) i've to dig into again with this new version of jetty +13:56 < jrandom> cool, keep us updated +13:56 < redzara> np +13:57 < fox> * mihi guesses most i2p users will reveal their "real ip" to a java applet anyway :) +13:57 < fox> <mihi> try http://www.stilllistener.com/checkpoint1/Java/ (and scroll down) +13:58 * jrandom sees lots of blank fields ;) +13:59 <+bla> fox: All one exposes is the relation between an IP and a particular client destination, where the client destination will change at every router restart. +13:59 < jrandom> bla: unless the user is on some site like e.g. http://i_have_illegal_stuff.i2p/ +14:00 < jrandom> (exposing the clients IP "just once" is fatal enough ;) +14:00 <+bla> jrandom: Yes. +14:00 <+bla> But then again, if you're serious about anonymous browsing, you'll use temporary HTTP proxies, and disable all things java, and plugins, and cookies, entirely +14:01 < jrandom> or use syndie :) +14:02 < ZULU> sorry for interruption,is duck.ip down ? +14:02 <+bla> jrandom: Is it time yet for general questions? +14:02 < jrandom> aye, we're on 4) ??? +14:02 < jrandom> ZULU: yeah, duck is offline for the time being +14:03 <+bla> jrandom: I've edited the java-files that help profiles.jsp and tunnels.jsp generate the country-flags +14:04 <+bla> jrandom: However, where do I place images that I can actually LINK to, and that will work, on my local router (_not_ my eepsite)? +14:06 < jrandom> we need a "get.jsp?name" that dumps the contents of ./docs/'name' to the browser +14:06 < jrandom> (aka you need to have it in the .war right now, but with a tiny .jsp file, you could dump 'em in docs) +14:06 <+bla> jrandom: Ah, ok, so it wasn't my fault ;) +14:06 < jrandom> heh nope, blame me :) +14:09 < jrandom> ok, if there's nothing else for the meeting +14:09 * jrandom winds up +14:10 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/145.rst b/i2p2www/meetings/logs/145.rst new file mode 100644 index 00000000..dc31c931 --- /dev/null +++ b/i2p2www/meetings/logs/145.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 30, 2005 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/146.log b/i2p2www/meetings/logs/146.log new file mode 100644 index 00000000..8ddb6bda --- /dev/null +++ b/i2p2www/meetings/logs/146.log @@ -0,0 +1,212 @@ +13:04 < jrandom> 0) hi +13:04 < jrandom> 1) Net status +13:04 < jrandom> 2) Syndie status +13:04 < jrandom> 3) susidns +13:04 < jrandom> 4) ??? +13:04 < jrandom> 0) hi +13:04 * jrandom waves +13:04 <+bar> salaam aleikum +13:04 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2005-September/000888.html +13:04 <+Ragnarok> hi +13:04 * cervantes tips his hat +13:04 <+fox> * adamta waves back across the Irc2p/Freenode bridge +13:05 < jrandom> :) ok, movin' in to 1) net status +13:05 <@cervantes> *** Disconnected +13:05 < jrandom> things seem to be going reasonably well from what i can see +13:05 < jrandom> heh +13:06 * cervantes concurs...only one netsplit in a few days +13:06 < jrandom> i know we do still have some problems when one's net con is heavily congested (causing messages to back up and fail, resulting in more elGamal and higher CPU usage) +13:06 <@cervantes> and my irc connection uptime is as long as my routers' +13:06 <+Ragnarok> same as usual for me. Slow, but usable, with intermittent unreliability +13:07 < jrandom> nice, i have been seeing that too cervantes +13:07 < jrandom> Ragnarok: unreliability with eepsites, irc, i2pbt, i2phex, mail, all of the above? with 0.6.0.5 or earlier? +13:08 <+Ragnarok> mostly in the form of irc disconnects every few hours. +13:08 <+Ragnarok> don't use a whole lot else, so I don't have much more information +13:08 < jrandom> hmm, do you have the bw limiter set? +13:08 <+Ragnarok> yeah +13:08 < jrandom> (as a reminder, -1 now means 16KBps) +13:09 <+Ragnarok> it's set to more than the default +13:09 < jrandom> ok cool, is it hitting that limit at all, and/or is that limit appropriate for your real net capacity? +13:09 <+Ragnarok> the limit is well below my real capacity, since setting it high seems to kill my wireless router +13:10 < jrandom> heh ok +13:10 <+Ragnarok> but my router doesn't seem to hit the limit anyway +13:11 <+Ragnarok> I can try to stress test it a bit, and keep better track +13:11 < jrandom> does the peak bw usage hit it though (per oldstats.jsp)? i2p is pretty bursty, and congestion on a burst might cause an irc discon +13:11 < jrandom> cool, that'd be great. i can only locally test so many situations, so any reports are appreciated +13:11 <+Ragnarok> which number am I looking for. oldstats is pretty dense... +13:12 <+Ragnarok> s/./?/ +13:12 < jrandom> heh, sorry - oldstats.jsp#bw.sendBps the 60s peak (the second number on the line) +13:14 <+Ragnarok> what are the units? The number seems highly improbable +13:14 < jrandom> KBps, sorry +13:14 < jrandom> (its improperly named) +13:15 < Pseudonym> bits or bytes? +13:15 < jrandom> bytes +13:15 <+Ragnarok> unfortuneately, it must be wrong then +13:15 <+Ragnarok> the peak number is a small fraction of the limit, and of the current usage of the router +13:15 < jrandom> hmm, its pretty specific, counting sizeof(messages received) +13:16 < jrandom> (though the bw limiter itself works at a lower level, counting sizeof(packets received or sent) +13:16 <+Ragnarok> how bad is it if I cut & paste the line? :) +13:16 < jrandom> might be safer to msg it to me +13:17 <+Ragnarok> wait, I was looking at the 60 m rate. It still looks low, but at least it's higher than the current usage. +13:17 <+Ragnarok> sorry +13:17 <+Ragnarok> I'll /msg you more info +13:17 <@cervantes> Ragnarok: we'd instantly be able to determin your name, address and credit details from the netDB +13:17 < jrandom> heh +13:18 < jrandom> cervantes: thats why the netDb bw publishes only the *current* rate, not the peak ;) +13:18 < jrandom> (but yeah, giving out one's bw usage can be dangerous to an adversary) +13:19 < jrandom> ok, anyone else have anything to bring up wrt net status? +13:21 < jrandom> if not, moving on to 2) syndie status +13:22 < jrandom> lots of syndie progress, as outlined in the email and on my blog. rather than repeating it here, anyone have anything to bring up on that front? +13:22 <@cervantes> Officiali2pApps++ +13:23 <+fox> <adamta> I'm modifying the JSP files to use more structured/semantic markup so that it can be more flexibly styled with CSS. +13:23 <+fox> <adamta> I don't have anything to show yet, but I'll post on the mailing list when I have something ready. +13:23 <+Ragnarok> maybe a small description on what you think the common use case for syndie is might be nice. I'm still a little unsure as to what it is, aside from a blog CMS +13:23 < jrandom> cool adamta - be sure to work with the latest codebase, as I went through and css'ed everything last night +13:24 < jrandom> (at a rought level, that is) +13:24 <+fox> <adamta> jrandom: Oops... I'd been working on an earlier version. +13:24 <+fox> <adamta> I'll `cvs update` and see what's changed, then. +13:24 * Ragnarok , asking for user docs. Oh the hypocrisy +13:24 < jrandom> good call Ragnarok. the use case is essentially '$myI2P.getUseCases()' +13:25 < jrandom> safe syndication and publication of content, rather than using eepsites +13:25 < jrandom> (as eepsites don't allow safe syndication, require more skill for publication, and require high availability of the operating node) +13:25 <+Ragnarok> how is it syndicated, though? +13:26 < jrandom> a good intro to syndie's aims is in the post http://syndiemedia.i2p/index.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=1124496000001&images=false&expand=true +13:27 < jrandom> syndication, right now, is done through http with explicitly specified syndication peers (either apache archives, other syndie instances, or freesites with syndie archives) +13:27 * cervantes just pulled apart the syndie css... it's sufficiently classes to do a varied amount of styling, but the markup itself isn't good for working in new themes +13:27 <+Ragnarok> oh, nice. I don't think I've seen that +13:27 <@cervantes> *classes=classed +13:27 <@cervantes> adamta: I'd be interested in seeing what you come up with +13:28 < jrandom> cervantes: i'm no css wonk, so anyone inspired to improve upon it, restructure it, or revamp how the whole css/frontend works is very much appreciated :) +13:28 <@cervantes> just get rid of those damn tables :) +13:28 < jrandom> heh +13:30 <+fox> <adamta> cervantes+jrandom: Indeed. There's enough there for basic styling, like changing the colour scheme, but I'm trying to modify it to get rid of the tables and to provide enough semantic markup (nested <div>s for sections, header tags, and so forth, all with classes and IDs when it would be useful) so that a stylesheet can completely change the appearance to the user's liking. +13:30 <@cervantes> cool +13:30 < jrandom> kickass adamta! +13:31 * jrandom will not touch that side of things for a bit (i've got plenty to work on in the router :) +13:31 <@cervantes> on a semi related note the new routerconsole themes have been somewhat delayed by arcturus' *ahem* disappearence +13:31 < jrandom> heh d'oh +13:31 <@cervantes> I'm trying to pick up where he left off with some of the workflow tweaks +13:32 <@cervantes> but I don't have the JSP skills to do anything radical like fix the broken tunnel config screens +13:33 < jrandom> ah cool, any progress is good, and if you need help with anything in particular, i'm 'round +13:33 < jrandom> adamta: one thing to keep in mind is the multiple-style thing (using the author-selected but locally hosted style) ((check my recent blog posts for more info)) +13:33 <@cervantes> having said that the new alternative theme is looking ok +13:33 < jrandom> nice +13:34 <+fox> <adamta> The new color scheme is definitely nicer, if that's what you're referring to (?). +13:35 <@cervantes> adamta: it would be cool if the author's can select a complete style from a set of templates for their particular blog +13:35 < jrandom> cervantes: do you think we should deploy those jsp/css changes arcturus bounced me before, or would you prefer to hold off until you've finished some more pieces of it? +13:36 <@cervantes> jrandom: I'm not sure what he gave you +13:36 <@cervantes> if you can sling them over to me I can compare...I have made additional markup changes since I last discussed things with him +13:37 < jrandom> cervantes: individual blog posts can now have per-blog style applied (causing e.g. class="s_detail_addressLink ss_minimal_detail_addressLink" to be used in the html, assuming the style specified is "minimal") +13:37 < jrandom> cool, i'll bounce 'em your way cervantes +13:37 <@cervantes> ta +13:38 < jrandom> cervantes: a per-blog theme is a bit tougher - the LJ folks had to deal with it too, and came up with the compromise saying the list containing multiple blogs uses the reader's style preferences, while the list containing just one blog's posts uses the author's style preferences +13:38 < jrandom> we could publish a 'DefaultStyle: minimal' in the blog's metadata to allow the later +13:39 <@cervantes> yeah that was what I was imagining +13:39 <+susi23> (readers preferences should always override others) +13:39 <+susi23> (but thats an opinion :) +13:39 < jrandom> right, when the reader has explicit preferences +13:39 <@cervantes> /ignore susi23 +13:39 <@cervantes> sheet it didn't work +13:41 <@cervantes> if we make filter by blog more distinct form of navigation +13:42 <@cervantes> such as a side list +13:42 < jrandom> at the moment, the user's preferences are kind of integrated into the workflow, rather than off in a separate prefs page (e.g. a link to bookmark a blog, or ignore them, or hide/show images). perhaps when we have multiple local styles, it'd be good to have a 'view style' drop down at the top +13:42 <@cervantes> then it will make style changes more pallatable +13:42 < jrandom> hmm yeah ,interblog navigation is going to be interesting +13:43 < jrandom> so you like how it was originally, with that list of blogs on the left hand side, rather than the drop down? +13:43 < jrandom> http://syndiemedia.i2p/viewattachment.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=1124769600000&attachment=0 +13:44 <@cervantes> <bluesky>well that could be a template preference perhaps?</bluesky> +13:44 < jrandom> hmm, i dont know if stylesheets can turn a list into a drop down, can it? +13:44 <@cervantes> navigation type: dropdown|sidelist|hierarchy +13:44 <@cervantes> no +13:45 < jrandom> ok, yeah, that can be done in jsp & user preference though, no problem +13:45 < jrandom> (hierarchy?) +13:45 <+susi23> (sure, you can give the select a rows parameter) +13:45 <@cervantes> but if you abstract the markup into templates then you can have multiple user preference layouts +13:45 < jrandom> ah, true, as a multivalued list +13:45 < jrandom> (rather than an html list of links) +13:46 <@cervantes> (I was blueskying though) +13:46 < jrandom> right right cervantes (though it'd be nice if we can do as much templating as possible through css, since thats easier to deploy themes for) +13:46 < jrandom> ((especially with the new docs/syndie_standard.css)) +13:46 <@cervantes> you might want to save that until version 2 and concentrate on more important aspects +13:47 <+susi23> (you could put all three variants in the html source and the users decides which divs we want to hide) +13:47 <@cervantes> right, if adamta sorts out the markup then you can probably do quite dramatic variations +13:47 < jrandom> aye, but i'm open for ideas for the default. if there's a better way to nav, it'd be better to deploy that +13:47 < jrandom> good call susi23 +13:47 <+susi23> (k, not very elegant way ;) +13:47 <@cervantes> as in http://www.csszengarden.copm +13:48 <@cervantes> * http://www.csszengarden.com +13:48 * jrandom is glad i implemented ArchiveIndex as a separate object from Archive, so all this stuff is essentially just churning through the archive.txt textfile :) +13:49 < jrandom> ok, anyone have any further questions/comments/concerns wrt syndie? +13:50 < jrandom> (one thing to note is that the new petname stuff has a one-click export to the user's userhosts.txt file, dumping any i2p addresses there [but it doesn't import yet]) +13:50 <@cervantes> nice work +13:50 < jrandom> gracias cervantes +13:50 <@cervantes> you going to ever do anything on i2p core again? :) +13:50 < jrandom> heh +13:51 * jrandom has a pair of killer changes to the router coming up, giving us lots of capabilities +13:51 < jrandom> (but more on those when they're tested and ready for deployment) +13:51 <@cervantes> i2pponies.ar +13:51 <@cervantes> i2ponies.war +13:52 <@cervantes> hmm vnc refresh is slow tonight +13:52 <+susi23> (pony wars? poor ponies...) +13:52 < jrandom> heh +13:52 < jrandom> ok, moving on to 3) susidns +13:52 < jrandom> susi23: wanna give us a rundown? +13:52 <+susi23> well +13:53 <+susi23> there is not much to say... susidns is a very simple webapp giving you access to addressbook configuration and subscriptions files +13:53 <+susi23> and to your "addressbooks" namely hosts.txt, userhosts.txt and (if existing) your published addressbook +13:54 <+susi23> I added an introduction page and some explanations how addressbook works +13:54 <+susi23> (ok, how I think addressbok works ;) +13:54 < jrandom> w00t :) +13:54 <+bar> userhosts.txt? +13:54 <+susi23> as there've been user questions about this in the last weeks +13:54 <+Ragnarok> I'll send feedback, once I try it out :) +13:54 <@cervantes> cool, how ready is it? +13:54 <+susi23> sure +13:54 <+susi23> usable +13:55 < ardvark> i use addressbook, but have no userhosts.txt, or is userhosts.txt my personal/private eepsites? +13:55 < jrandom> ardvark: userhosts is for user specified custom overrides (it doesnt exist by default) +13:55 <+susi23> userhosts.txt is a 2nd hosts.txt file which is read by the NamingService +13:55 < ardvark> ok +13:55 <+Ragnarok> userhosts.txt is the one you can edit without fear of dataloss via race conditions :) +13:55 <+susi23> and yes people used this for private keys +13:56 <+susi23> (which is a bit dangerous now when you activate addressbook publication) +13:57 <+susi23> well, no magic here... thats all +13:57 <+Ragnarok> adding a privatehosts.txt or something, which is read by the NamingService but not addressbook would be trivial +13:57 <+susi23> true +13:57 <@cervantes> I would like to see that ;-) +13:58 * cervantes clutches his private keys ;-) +13:58 < jrandom> ooh, susidns intro page is nice :) +13:58 < jrandom> (cervantes/susi/ragnarok/et al: see the syndie pet name web interface too [you need to log in to see it]) +13:58 <+susi23> as addressbooks publication is turned off by default there is no danger for normal people +13:58 < jrandom> right right +13:59 <+Ragnarok> I've asked this before, but is there anything I can do to make life easier for people writing addressbook frontends? +13:59 * cervantes has forgotten his login +13:59 < jrandom> cervantes: you can register again ;) +13:59 <+Ragnarok> so have I, probably +14:00 <@cervantes> wouldn't sushidns be a better name? +14:00 * cervantes ducks +14:00 <+susi23> ragnarok: how about a function to interupt the sleeping thread for immediate (user triggered) subscription update? +14:01 < jrandom> ooh, or a manual "fetch now" capabiliy +14:01 * susi23 slaps cervantes with a large trout. +14:01 <+susi23> yes, calling it dns is ridiculous here...but thats a historic name :) +14:01 <@cervantes> raw trout! +14:01 * cervantes grabs the soya sauce +14:01 <+susi23> (pervert!) +14:02 <+susi23> k, back to topic please ;) +14:02 <+Ragnarok> ok, I'll look into that +14:02 <+susi23> (don't drink at meetings!) +14:02 * jrandom hides my drink +14:03 * susi23 pings jrandom +14:03 < jrandom> ok cool, thanks susi, looks v.nice +14:03 < jrandom> ok, moving on to 4) ??? +14:03 < jrandom> anyone have anything else they want to bring up for the meeting? +14:04 <@cervantes> if anyone has been experiencing any issues with irc2p please let the admins know +14:06 <@cervantes> #irc2p is the support channel +14:06 <@cervantes> or post to the forum +14:06 <@cervantes> jrandom: do you want a syndie forum btw? (or is that redundant) +14:07 <@cervantes> susi23: you're welcome to have one too, for you plethora of i2p apps ;-) +14:07 < jrandom> atm, i think we're ok without one, thanks though +14:07 < jrandom> the susiworld forum +14:09 < jrandom> ok, if there's nothing else +14:09 * jrandom winds up +14:09 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/146.rst b/i2p2www/meetings/logs/146.rst new file mode 100644 index 00000000..e3b20394 --- /dev/null +++ b/i2p2www/meetings/logs/146.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 6, 2005 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/147.log b/i2p2www/meetings/logs/147.log new file mode 100644 index 00000000..60a3f8ea --- /dev/null +++ b/i2p2www/meetings/logs/147.log @@ -0,0 +1,41 @@ +13:01 < jrandom> 0) hi +13:01 < jrandom> 1) Net status +13:01 < jrandom> 2) SSU introductions / NAT hole punching +13:01 < jrandom> 3) Bounties +13:01 < jrandom> 4) Client app directions +13:01 < jrandom> 5) ??? +13:01 < jrandom> 0) hi +13:01 * jrandom waves +13:01 < jrandom> weekly status notes posted up (before the meeting!) at http://dev.i2p.net/pipermail/i2p/2005-September/000892.html +13:01 < jrandom> (drop the .net if you prefer, of course) +13:03 < jrandom> jumping on in to 1) Net status +13:03 < jrandom> there are a few users bouncing a bit on irc, but it seems pretty good for most +13:04 < jrandom> does anyone have any reports regarding other protocols to bring up, or questions/concerns regarding the net status? +13:05 <@cervantes> I've found this version to be the most stable since 0.4.x +13:05 <@cervantes> so top work! ;-) +13:05 < jrandom> w00t +13:05 < jrandom> ok, if there's nothing else on 1) net status, lets move on to 2) SSU introductions +13:06 < jrandom> I don't really have much to add beyond whats in the email - anyone have any questions/comments/concerns? +13:07 < jrandom> if not, i suppose we'll be hearing more when 0.6.0.6 comes out ;) +13:07 < jrandom> ok, moving on to 3) bounties +13:07 * cervantes battens down the hatches +13:08 * cervantes wonders if people have got the hang of the new meeting time yet +13:08 < jrandom> hmm, it doesn't seem like Comwiz is around at the moment. I suppose we can expect more info when its ready +13:08 < jrandom> bah, bloody americans and their slow time zones +13:09 <+Myo9> I though you were one, having your own bunker and all. ;) +13:09 * susi23 listens to the dialog ;) +13:10 < jrandom> ok, if there's nothing else on 3), we can race on through to 4) client apps directions +13:11 < jrandom> lots of typing in the mail, so rather than repeat it here, anyone have any thoughts on it? +13:11 < jrandom> its not just an immediate question, if/when people want to chime in on that stuff, please feel free to post to the forum or list as well +13:12 <@cervantes> there's a new Application Support section in the forum, which is a good place to post about such matters +13:12 < jrandom> ah good call +13:13 < jrandom> also the discussion section for non-support comments, e.g. prioritization stuff +13:13 < jrandom> ok, working us towards the first under-15-minute meeting in a long time... +13:14 < kbi> i guess the meetings go fast when everyone is happy +13:15 < jrandom> could be, and hopefully we'll get some posts on the list and the forum +13:15 < jrandom> ok, moving on to 5) ??? +13:15 < jrandom> anyone have anything else they want to bring up for the meeting? +13:15 <@cervantes> (except their lunch) +13:17 <@cervantes> there goes 15 mins +13:17 * jrandom winds up +13:17 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/147.rst b/i2p2www/meetings/logs/147.rst new file mode 100644 index 00000000..e478bb34 --- /dev/null +++ b/i2p2www/meetings/logs/147.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 13, 2005 +=================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/148.log b/i2p2www/meetings/logs/148.log new file mode 100644 index 00000000..57296ccf --- /dev/null +++ b/i2p2www/meetings/logs/148.log @@ -0,0 +1,97 @@ +16:18 < jrandom> 0) hi +16:18 < jrandom> 1) 0.6.0.6 +16:18 < jrandom> 2) I2Phex 0.1.1.27 +16:18 < jrandom> 3) migration +16:18 < jrandom> 4) ??? +16:18 < jrandom> 0) hi +16:18 * jrandom waves +16:18 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-September/000929.html +16:18 <+postman> hello +16:18 < forest> hi +16:18 < jrandom> lets jump on in to 1) 0.6.0.6 +16:19 < jrandom> the status notes cover pretty much what i've got on my mind for 0.6.0.6. anyone have any questions/concerns/comments to bring up? +16:19 <+postman> jrandom: observation: +16:19 <+postman> jrandom: much higher bandwidth consumption +16:20 <+postman> jrandom: all within the limits and running fine - but my routers really getting warm now +16:20 * nickless_head makes similar observation +16:20 < jrandom> aye, me too, i think its likely due to an increase in bt and i2phex traffic +16:20 <+postman> what increase, with just 80 active torrents on the tracker? :) +16:20 < jrandom> heh +16:21 <+postman> but its good to see, that the network does not crumble +16:21 <+postman> irc is pretty stable altho the router does 50k/s atm +16:21 < jrandom> mos' def'. i'm not even logged into freenode anymore, as irc here is stable enough +16:22 * postman hands the mike back +16:22 < jrandom> cool, thanks. i think there's definitely still room to go for bandwidth efficiency, but it seems reasonable atm +16:22 < jrandom> (hopefully the thing i'm working on will help, but more on that when its ready) +16:22 < fox> <mihi> you should definitely distinguish between OK (Nat) and Err (Nat)... +16:23 < fox> <mihi> or is your hole punching almighty? +16:23 < jrandom> heh +16:23 < jrandom> well, ERR-SymmetricNAT is and will continue to be an ERR +16:23 < fox> <mihi> or is it impossible to check whether it was successful? +16:24 < fox> <mihi> ok +16:24 < jrandom> but ERR-Reject is due to restricted cone, while full cone nats work fine +16:24 < jrandom> (since i2p uses only one source port for everyone, as long as you're on i2p you'll have a hole punched for the full cone) +16:25 < jrandom> still, it is better when people forward their ports so they don't need introducers, as that lets them also become introducers themselves +16:25 < fox> <mihi> as long as there are no nasty iptables rules (like drop UDP to 8887 from IP addresses divisable by 7 :) ) +16:25 < jrandom> heh +16:26 < jrandom> and unfortunately, some people do have b0rked configurations like that (*cough*peerguardian*cough*) +16:26 < jrandom> someone the other day was wondering why i2p didn't work, even though they had their firewall dropping packets from all .edu peers +16:27 <+Ragnarok> .edu? That's pretty random +16:27 < jrandom> yeah, made no sense to me, in so many ways +16:27 < jrandom> but, c'est la vie +16:27 * nickless_head sings: We don't need no education... +16:28 < jrandom> heh +16:28 < jrandom> ok, anyone else have anything on 1) 0.6.0.6? +16:29 < jrandom> if not, moving on to 2) i2phex 0.1.1.27 +16:29 < jrandom> not much to say here beyond whats in the mail either... +16:30 <+postman> jrandom: there was no positive response in the mentioned forums either :( +16:31 <+postman> jrandom: i will forward your statusnotes and links - maybe the readers get the point +16:31 < jrandom> postman: people are of course able to use whatever they want, but I don't recommend the binary release from legion as the source doesn't match the binary, and the launcher is entirely closed source +16:32 < jrandom> now that we've got i2phex on a web accessible location, built from cvs, hopefully that will reduce people's reliance on that +16:33 < jrandom> (perhaps if you want to post the irc log from #i2p-chat an hour or two ago between legion and i, that might help explain the situation to people more completely) +16:34 < jrandom> ok, anyone else have anyhing on 2) i2phex, or shall we move on to 3) migration +16:34 * postman has a look +16:34 < jrandom> there's not much really to add for 3), its more of an fyi +16:34 < jrandom> so, perhaps we can jump quickly to 4) ??? +16:34 < jrandom> anyone have anything else they want to bring up for the meeting? +16:35 <+Complication> Migration? +16:36 < jrandom> if you didn't notice, great :) +16:36 < jrandom> we moved from one colo to another +16:36 < jrandom> (cvs.i2p.net, dev.i2p.net, www.i2p.net, mail.i2p.net) +16:36 <+Complication> Oh, that migration. :) +16:36 * Complication is simply a bit slow today +16:39 <+Complication> By the way, 0.6.0.6 seems very nice... in the regard that my router didn't touch 0 participating tunnels in 54 hours. +16:39 <+Complication> Not even once. +16:39 < jrandom> nice +16:40 < jrandom> ok, if there's nothing else people want to bring up for the meeting... +16:40 * jrandom winds up +16:40 <+postman> jrandom: one thing +16:40 * jrandom stops winding +16:40 <+postman> jrandom: you just incremented the i2phex version - what if sirup plans another release? +16:40 < jrandom> postman: sirup uses the cvs +16:41 <+postman> jrandom: how about giving it a an additional tag +16:41 <+postman> ok, that's fine then +16:41 <+postman> :) +16:41 * postman is back in his cave +16:41 < jrandom> (developing code outside a source control system == crazy) +16:41 * Kefoo remembers how crazy it was developing inside a source control system, too +16:41 <+postman> jrandom: (it did not need to be YOUR's) +16:42 < jrandom> heh true enough Kefoo ;) +16:42 < jrandom> heh well, yeah... his just happens to be though ;) +16:43 * bar just set a new personal record of 156 concurrent udp connections (old record was 152) +16:43 < jrandom> cool, yeah, i saw 173 earlier today +16:44 <+bar> oh :) yeah the indtroducing is doing its thing fo' sure +16:44 < Kefoo> Not to backtrack, but is i2phex supossed to try connecting on startup? I've heard both yes and no. +16:44 <+bar> -d +16:44 < jrandom> wikked bar +16:44 < jrandom> Kefoo: afaik, no. +16:44 < jrandom> but, i'm no phex dev +16:45 < Kefoo> The only way I've found is to copy and paste the host keys into the program and connect to them manually +16:45 < jrandom> thats what i've done Kefoo +16:45 <+postman> wind ye up now, jrandom :) +16:45 < Kefoo> Ok, so I'm not making it harder than it should be +16:45 < Kefoo> I do that sometimes +16:46 < jrandom> Kefoo: if there's something easier, i'd like to hear about it :) +16:46 < jrandom> ok ok postman, you can go get your beer ;) +16:46 * jrandom winds up +16:46 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/148.rst b/i2p2www/meetings/logs/148.rst new file mode 100644 index 00000000..ed9afede --- /dev/null +++ b/i2p2www/meetings/logs/148.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 20, 2005 @ 20:00 UTC +=============================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/149.log b/i2p2www/meetings/logs/149.log new file mode 100644 index 00000000..6cebeb2d --- /dev/null +++ b/i2p2www/meetings/logs/149.log @@ -0,0 +1,252 @@ +16:14 < jrandom> 0) hi +16:14 < jrandom> 1) Net status +16:14 < jrandom> 2) 0.6.1 +16:14 < jrandom> 3) ??? +16:14 < jrandom> 0) hi +16:14 * jrandom waves +16:14 <+Ragnarok> ok, I'll hold my further questions +16:14 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-September/000933.html +16:14 <+Ragnarok> hi :) +16:15 < wiht> Hello. +16:15 < jrandom> we can definitely dig into it further in 3?? if you'd prefer +16:15 <+Ragnarok> cool +16:15 < jrandom> ok, jumping into 1) Net status +16:15 < jrandom> in general, things seem pretty solid +16:16 < A123> Is the http outproxy run by just one router? +16:16 < wiht> I see 307 known nodes on my router console. +16:16 < A123> (I'm still a little hazy on how I2P works) +16:16 < jrandom> there are two outproxies configured by default, and a few others available not configured by default +16:16 < wiht> Has anyone's bandwidth been maxed out by the recent growth of the network? +16:17 < jrandom> well, my bandwidth usage has grown, a steady 30-40KBps on my routers +16:17 < jrandom> (to a steady 30-40, that is) +16:18 < jrandom> (i'm also running a few high traffic services, like squid.i2p ;) +16:19 < A123> Ever look at the logs? +16:19 < jrandom> of squid? no, i have it set to not do any request logging +16:20 <+Ragnarok> remember, he could be lying :) +16:20 <+Ragnarok> thus, it's a stupid question to ask +16:20 < jrandom> (though that could be a lie, and may work for the FBI/etc, so don't abuse it ;) +16:20 < A123> I was just curious as to whether there was anything interesting in there :) +16:21 <+mihi> A123: run your own outproxy :) +16:21 < gloin> A123: setup a tor node. +16:21 < A123> Is it easy to set up? +16:21 < jrandom> not really +16:21 < A123> gloin, tor is explicitly not designed for file sharing, so I have little interest in it. +16:22 < jrandom> (an outproxy, that is. tor is easy to set up) +16:22 < A123> Or at least, they've explicitly stated that they don't want people to use it for file sharing. +16:22 < wiht> jrandom, do you still want to wait for version 1.0 before a full public announcement of the I2P project's maturity? +16:23 <+mihi> A123: it is definitely harder than registering your nick with nickserv *hint* *hint* +16:23 < A123> Oh yeah, I sure don't want A123 to be taken :) +16:23 < wiht> If the network is doing well now, could it stand the addition of more users? +16:23 < jrandom> we'll need to do some outreach before 1.0 so that we can have some testing in larger environments +16:24 <+Ragnarok> maybe a preview release, or some such thing +16:24 < wiht> A beta release? Sounds like a good idea. +16:25 < jrandom> aye, that'll happen along side the website revamp, maybe before 0.6.2 +16:25 < jrandom> (or maybe @ 0.6.2) +16:25 < jrandom> (website revamp being part of that critical path so we dont spend hours upon hours answering the same questions) +16:25 <+Ragnarok> well, with a little more end-user polish than just another beta +16:26 < A123> Is it possible for I2P-aware clients to configure tunnels themselves easily? +16:26 < jrandom> yes +16:26 < A123> I guess they could always do HTTP requests to the console... +16:26 <+Ragnarok> the router console also need a serious revamp. It would be nice for the initial page to be more like an i2p portal, and move all the technical stuff a little farther in +16:26 < jrandom> its one of the properties they send when they connect to i2p +16:26 < jrandom> agreed Ragnarok +16:27 < A123> Hrm. The Azureus I2P plugin could have a bit of additional friendliness, then. +16:27 < A123> Or any friendliness at all. +16:27 < jrandom> agreed A123 ;) +16:27 < jrandom> (though they've done a great job showing the proof of work) +16:28 < jrandom> there have been a lot of great suggestions on the mailing list as of late regarding usability +16:28 < jrandom> many/most of which should be done prior to asking new users to try i2p out +16:28 < A123> From the console: "If you can't poke a hole in your NAT or firewall to allow unsolicited UDP packets to reach the router, as detected with the Status: ERR-Reject..." +16:28 < A123> Where would I see "Status: ERR-Reject"? +16:29 <+Ragnarok> it's nice that we're at the point where we can worry about usability :) +16:29 < jrandom> A123: on the left hand side of your router console, it says Status: OK (or Status: unknown, or something else) +16:29 <+Complication> In the Status field of the router console. +16:29 < jrandom> true 'nuff Ragnarok +16:29 <+Complication> Hopefully you've got an OK or OK (NAT) there. +16:30 < A123> Complication, ah, thanks. Is that the thing that gets updated if you click on "Check network reachability..."? +16:30 < wiht> I hope that you will not have to break compatibility in future releases of I2P. Full network migration to a new version seems to have been painful in the past. +16:30 <+Complication> A123: yes, it should test again when you click +16:30 <+Complication> Doesn't happen instantly, though. +16:30 < jrandom> eh, they're not as painful as they used to be, but yeah, it'd be good if we can avoid it wiht +16:30 < A123> So I have to refresh the page? +16:30 < A123> Well, no, that would do another http post... +16:31 <+Complication> A123: it may take a minute to find a testing-suitable peer +16:31 <+Complication> 'cause you cannot test with those whom you're already speaking to +16:31 <+Complication> It could give false results. +16:32 <+Complication> So, it should show up when you view the router console sometime later. +16:32 <+Complication> Basically, in ideal circumstances, you shouldn not need to fire a peer test manually. +16:33 <+Complication> =shouldn't need +16:33 < jrandom> right, i2p now does a peer test automatically when certain events occur +16:33 < jrandom> (such as when someone tells you that your IP is something other than what you think it is) +16:33 < A123> I found that button completely unintuitive. I had no idea what it was updating and when, it never explicitly told me the results of the test... +16:34 < A123> The page wasn't automatically refreshing (I think), I can't do a reload in the browser... +16:34 < jrandom> reload should be safe +16:34 < A123> Surely that fires another test? +16:34 < jrandom> but yeah, the router console was designed more for technical reasons rather than usability +16:34 < jrandom> A123: it has a nonce to prevent that +16:34 <+Complication> That facet might benefit from a better explanation text in future +16:35 < wiht> Have we skipped 2) and gone to 3) already? +16:35 < jrandom> Complication: we'll probably drop it, since its unnecessary +16:35 < jrandom> no, still on 1 +16:35 < jrandom> actually, anyone have anything else for 1) network status? +16:35 < A123> Ah, indeed, after a few times it complains about the nonce. +16:35 < jrandom> if not, moving on to 2) 0.6.1 +16:35 < A123> "nonce" to non-geeks is just going to seem like a nonsense word. +16:36 < A123> :) +16:36 * Complication looks at graphs +16:36 <+Complication> No complaints about net status from here. +16:36 < jrandom> w3wt +16:37 < A123> Is there any reason that reseeding isn't automatic? +16:37 < jrandom> ok, i don't really have too much to mention regarding 0.6.1 beyond whats in the mail +16:37 < gloin> hmm.. shouldn't be the incoming and outoging traffic more or less symmetric? +16:37 < A123> Mine seems more or less symmetric. +16:37 < jrandom> A123: yes, though we may be able to do it safer +16:37 <+Complication> gloin: not if one's leeching or seeding ;) +16:37 <+Ragnarok> not if you're downloading stuff +16:38 < A123> Total: 3.74/4.09KBps (that's in/out) +16:39 < gloin> Complication: Is this a security problem? Shouldn't the 'foreign' traffic be reduced? +16:39 <+Complication> gloin: depends on what the criteria are +16:40 <+Complication> A person striving for utmost security clearly shouldn't be doing things which permit others to cause observable changes in their BW. +16:40 < jrandom> gloin: as we move to 1.0, we will stop publishing those stats +16:40 < A123> My ISP will still know them... +16:40 < jrandom> but yes, defending against local traffic analysis does require you to participate in other people's tunnels +16:41 <+Complication> (for a strict definition of "their BW", meaning "bandwidth use starting/ending at their node") +16:41 < jrandom> (or do sufficient chaff activity. tarzan for instance has "mimics" for wasting bandwidth^W^Wdefending anonymity) +16:41 < A123> Hrm. +16:41 < A123> I'm on ADSL, with far more download ability than upload. +16:42 <+Complication> Many are. +16:42 < A123> When my download exceeds my upload, doesn't that imply that I'm downloading stuff? +16:43 < wiht> No, you could also be forwarding others' traffic. +16:43 <+Complication> I guess it would imply you are downloading something. +16:43 < A123> Does I2P cache data? +16:43 * wiht would like to be corrected if that's wrong. +16:43 <+Complication> Unless you are seeding as much as you're leeching. +16:43 < jrandom> i2p itself does not cache +16:43 <+Complication> A123: no caching occurs to my knowledge +16:43 < jrandom> though syndie, on the other hand, does. +16:44 < A123> If there's no caching, then my download exceeding my upload must mean that I'm downloading something myself, right? +16:44 < jrandom> if you have large amounts of inbound trafffic but no current outbound traffic, you could just be running a syndie node +16:44 < jrandom> yes A123, given a small enough time frame +16:45 < A123> Since I could only usefully be downloading at the speed of my upload, after network buffers fill. +16:45 < jrandom> for a certain threat model, yes +16:45 < A123> Hrm. +16:45 < jrandom> (local passive attacker with sufficient resources, or a targetted local attacker, etc) +16:46 <+Complication> You could download faster, but it would increase your risk. (For which reason I have allocated up/down similar limits.) +16:46 < A123> Ah, good point, I can just limit my download speed. +16:46 <@LevDavidovitch> btw, you should limit both your dl and ul speed +16:47 <+Complication> But if someone targeted everyone who downloads more than uploads... they'd be targeting everyone and their granny. +16:47 < wiht> We are still having disconnection issues with IRC, it seems. +16:47 < jrandom> wiht: only a few people are +16:47 < wiht> OK. +16:47 <@LevDavidovitch> also reconnection is v FAST these days +16:48 < jrandom> (and nothing as bad as it was) +16:48 < wiht> I agree, reconnections are better. +16:48 < jrandom> aye, its nice to have our irc servers hosted on routers with reasonable bw limits :) +16:49 < jrandom> ((not that before was unreasonable, it was great, we just outgrew it)) +16:49 < A123> Is there any technical reason why DCC isn't supported? It can be implemented similar to the nat module, right? +16:49 < jrandom> ok, anyone have anything for 2) 0.6.1? +16:49 < jrandom> yes A123, there are technical reasons why dcc isnt supported +16:50 <@LevDavidovitch> it'd have to be done client side, i think. +16:50 < jrandom> someone could implement an irc proxy with dcc support, but no one has +16:50 < A123> What are they? Or is that a long discussion? +16:50 < jrandom> dcc support requires knowing and interpretting the irc protocol, and rewriting the irc messages sent as necessary +16:50 <@LevDavidovitch> normal dcc uses arbitrary ports and all +16:50 < jrandom> (in particular, ctcp messages for establishing dcc connections) +16:50 < A123> Oh, that's what I meant to ask... Whether it was technically possible to do it as with a nat module (which does as you say). +16:51 < jrandom> i dont know what a nat module is? +16:51 <@LevDavidovitch> the nat uses some UDP weirdnesses. +16:52 <@LevDavidovitch> the nat traversal thing i think he means +16:52 < jrandom> ah, ok, yeah, its technically possible, but no one has volunteered to work on it (and i'm swamped) +16:52 < A123> No... At least for Linux, there's a masq module for iptables which will rewrite IRC packets with DCC CTCP requests. +16:53 <@LevDavidovitch> ah, i see +16:53 <@LevDavidovitch> maybe some of that code would be usable +16:53 <@LevDavidovitch> depends how intimate it is with the ipfilter thing +16:54 < jrandom> probably simpler to just extend I2PTunnelClient to interpret irc perhaps +16:54 < A123> http://www.koders.com/c/fidA6A89E1080590138EB211E694473DDDD098B6B75.aspx <- Might be interesting, courtesy of Google. +16:54 < jrandom> (in the same way I2PTunnelHTTPClient extends it to interpret HTTP) +16:55 <@LevDavidovitch> not in most countries. +16:55 <@LevDavidovitch> oops +16:56 < jrandom> A123: an os level filter would be a bit tough to deploy, but if someone wants to work on it, that'd be a good place to start +16:57 < jrandom> ok, anything else on 2) 0.6.1, or shall we move on to 3) ??? +16:57 < A123> jrandom, it wouldn't really need to be OS level, would it? It would be coming through the IRC tunnel anyway... +16:58 < jrandom> actually, it wouldn't even work as an iptables filter. it has to be done inside i2ptunnel or some other i2p-aware proxy +16:58 < jrandom> in any case, its a lot of work, and unless someone volunteers to do it, it'll never get done ;) +16:59 < jrandom> (it *woudl* be cool though) +16:59 < A123> Right. +16:59 < A123> I meant "like the iptables filter", not "using the iptables filter" :) +16:59 < A123> -the+a +16:59 < A123> +n +17:00 < A123> Hrm hrm. +17:00 <@LevDavidovitch> go forth I think +17:01 < jrandom> ok, on to 3) ??? +17:01 < jrandom> (though one could probably say we've been on 3) all along ;) +17:01 < jrandom> anyone have anything else they want to bring up for the meeting? +17:01 <+fox> <brutus> on 3) bugzilla would be nice to have in shape before 1.0 +17:01 < wiht> Speaking of the usability suggestions from the mailing list, have you incorporated any of them into I2P? +17:02 < jrandom> brutus: we used to have bugzilla, but no one used it +17:03 < wiht> I should say, are you still concentrating on the core I2P functionality and planning to focus on usability a little later? +17:03 < A123> I don't want to try it here, but I think that sending someone a DCC request at the moment would reveal to them your IP. +17:03 < A123> (Assuming your client knows your IP) +17:03 < jrandom> wiht: the last week i've been doing a lot of improvements to the streaming lib which should substantially improve usability +17:04 < jrandom> A123: the irc servers filter ctcp messages +17:04 < jrandom> (they've been modified) +17:04 < A123> Servers... +17:04 < jrandom> but yes, that does send your ip to the server (which it may discard, or may file into some NSA database) +17:04 < jrandom> so, dont send dcc requests +17:04 < A123> I don't really want the server admins knowing who I am, either :) +17:05 < A123> (In theory. I don't care now or with you guys) +17:05 < A123> It might be worth warning users about that. +17:05 < jrandom> there's a page on the wiki about a whole slew of issues iirc +17:05 < jrandom> (swing by ugha.i2p) +17:06 <+fox> <mihi> btw: are the irc2p servers connected via i2p or directly? +17:06 <+Complication> I'd assume i2p +17:06 <+Complication> Unless someone's gone mad meanwhile, and not notified me. :P +17:06 < wiht> jrandom, that's good, but what about the UI suggestions by Isamoor? +17:07 < jrandom> mihi: i believe they're done over i2p +17:08 < jrandom> wiht: the list of what i've been doing is available on http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD +17:09 < jrandom> there's a lot more to be done, and a lot more will be done, but i have only two hands +17:09 < wiht> Thank you, I will look there. +17:10 < jrandom> actually, i have something to bring up for the meeting... +17:10 < A123> What's the server/channel that fox is changating? Or do I misunderstand fox's purpose? +17:11 < jrandom> as mentioned on hq.postman.i2p, we've had over a full year of anonymous mail service through postman's servers! +17:11 * jrandom cheers +17:11 * wiht does not want to seem ungrateful. +17:12 < A123> jrandom, have the spammers caught on yet? +17:12 < jrandom> A123: fox is a bridge to irc.freenode.net +17:12 < A123> (OK, it's a slow way to go about spamming...) +17:12 < jrandom> A123: doubt it, postman has antispam measures +17:12 < jrandom> inbound spam is a bit of a problem though ;) +17:13 < jrandom> (but my account there has been well filtered) +17:13 < mule> is it really that long. time passes ... +17:13 < A123> jrandom, ah, thanks. +17:13 * Complication looks if someone has finally dropped him a bear via e-mail +17:14 <+fox> <brutus> yeah, postman & cervantes deserve a medal, they're pulling some great weights around here +17:15 <+fox> <brutus> excellent services indeed +17:16 < jrandom> mos' def'. as is mule with his outproxy and fproxy, orion with his site, and the rest of y'all with yer content :) +17:16 < jrandom> ok, anyone have anything else to bring up for the meeting? +17:16 < wiht> Speaking of content... +17:16 < wiht> It seems that we know what sites are up or not, but no easily accessible directory of sites. +17:17 < A123> My clock runs fast. Would it be possible for the "Updating clock offset to -316819ms from -304801ms" messages to be downgraded from "CRIT"? It's a little disconcerting. +17:17 < wiht> I was thinking of creating one where site admins can post what their site is about. +17:17 < jrandom> orion.i2p is pretty easily accessible...? +17:17 < jrandom> A123: hmm, perhaps +17:18 < wiht> It has a short description of sites' purposes? +17:18 <+postman> A123: spam is only a problem for incoming mail ( mail FROM the internet ) +17:18 < jrandom> wiht: yeah, it does, though i dont know where they come from +17:18 <+Complication> wiht: no, orion doesn't seem to have that feature +17:18 < wiht> I will look again. +17:18 < jrandom> iirc jnymo used to maintain them +17:18 <+postman> A123: i2p mail users can rarely spam themselves as well as they cannot spam internet targets +17:19 <+Complication> Sorry, meant to say it doesn't seem user-accessible. +17:19 < wiht> I was thinking of a directory that categorizes sites, something similar to dmoz.org. +17:19 < A123> wiht, as a brand new user, that sounds great. +17:19 <+fox> <Sugadude> wiht: Do we have enough sites to need to classify them? +17:19 < A123> wiht, but check Freenet for an excellent example of how not to do it. +17:20 < jrandom> a reliable categorized site would be neat. or perhaps we can integrate it into syndie to let people tag and categorize their peer references (and share them) +17:20 < jrandom> (syndie already has a set of category tags for each bookmark, laying it out visually dmoz style wouldnt be hard) +17:20 < jrandom> and it'd be local <--- fast +17:20 < A123> Or just get Google interested in i2p... +17:20 < jrandom> heh +17:24 < jrandom> ok, if there's nothing more for the meeting... +17:25 * jrandom winds up +17:25 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/149.rst b/i2p2www/meetings/logs/149.rst new file mode 100644 index 00000000..e055f784 --- /dev/null +++ b/i2p2www/meetings/logs/149.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 27, 2005 +=================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/15.log b/i2p2www/meetings/logs/15.log new file mode 100644 index 00000000..93074d5d --- /dev/null +++ b/i2p2www/meetings/logs/15.log @@ -0,0 +1,517 @@ +--- Log opened Tue Oct 15 23:31:29 2002 +23:31 < logger> test +23:32 < mason> sorry, that test did not work +23:32 < mason> :) +23:32 -!- mode/#iip-dev [+o mids] by Trent +23:32 <@mids> Tue Oct 15 21:32:19 UTC 2002 +23:32 <@mids> meeting starts in 1:30 hours +--- Day changed Wed Oct 16 2002 +00:44 < geully> hi all +00:50 <@mids> Public IIP meeting in 10 minutes here +00:50 < Robert> Hello all. +00:51 <@mids> shhh +00:51 <@mids> not yet +00:51 <@mids> 9 more minutes +00:51 < Grishnav> lol +00:51 < al-jabr> Tue Oct 15 22:51:23 UTC 2002 +00:51 * Robert zips his lip. +00:51 < al-jabr> lalala +00:53 -!- geully is now known as Geully +01:00 <@mids> Tue Oct 15 23:00:02 UTC 2002 +01:00 <@mids> welcome to the n-th public IIP meeting +01:00 <@mids> logfiles are on http://mids.student.utwente.nl/~mids/iip/ +01:00 < nop> hehe +01:00 <@mids> oh, 15th +01:00 < nop> 15th +01:00 < nop> yes +01:00 <@mids> agenda for today: +01:01 <@mids> - new IIP developer +01:01 <@mids> - IIP logo contest +01:01 <@mids> - bug fixes +01:01 <@mids> - question rounds +01:01 <@mids> , +01:01 <@mids> . +01:01 < nop> ok +01:02 < nop> welcome back all +01:02 < nop> to another round of meetings ;) +01:02 < nop> for all that work in a corporate office +01:02 < nop> you have permission to sleep +01:02 < nop> ok +01:02 < nop> new IIP developer +01:02 -!- mode/#iip-dev [+o nop] by mids +01:02 <@nop> and is a talented and quick learning C programmer +01:02 -!- mode/#iip-dev [+o UserX] by mids +01:02 <@nop> and has already added some patches and some grunt work that was needed to the code +01:03 <@mids> hurray! +01:03 <@nop> we are glad to have him +01:03 <@nop> and we feel that he will be an essential part of the team +01:03 * al-jabr claps +01:03 <@nop> ok +01:03 <@nop> next on list +01:03 <@nop> IIP logo contest +01:03 <@nop> any graphix designers etc +01:03 <@mids> graphix? you mean graphics? +01:04 < Grishnav> No, he means graphix :P +01:04 < hobbs> nop: maybe. Me or my mom. She's good, and she got a tablet recently. :) +01:04 <@nop> who would like to come up with a cool slogan and/or logo for invisiblenet, and IIP (yes I mean graphics) for t-shirts can submit their entries to iip@invisiblenet.net +01:04 <@nop> the winner +01:04 <@nop> will win a free t-shirt +01:04 <@nop> black or white +01:04 <@nop> of his choice +01:04 <@nop> or her choice +01:04 <@mids> woohoo! +01:04 <@nop> and 10.00 DRAN +01:04 < hobbs> nice. +01:05 <@nop> this can definitely include slogans as well +01:05 <@nop> so there could be two winners +01:05 <@nop> if one comes up with logo +01:05 -!- mode/#iip-dev [+o Chocolate] by mids +01:05 <@nop> and one comes up with an awesome slogan +01:05 -!- mode/#iip-dev [+o Chocolate] by Trent +01:05 <@nop> but submit to iip@invisiblenet.net +01:05 <@nop> and they will be reviewed +01:05 <@nop> I hope that if you're not a graphics guy, that you can tell a friend +01:05 <@nop> and maybe split the profits +01:05 <@nop> ;) +01:06 <@nop> because we would like to have cool shirts +01:06 <@nop> for the e-store +01:06 <@nop> and in general +01:06 <@nop> as well +01:06 <@nop> for bumper stickers etc +01:06 <@nop> maybe a mascot would be good too +01:06 <@mids> :) +01:06 <@nop> either way +01:06 <@nop> do what you can +01:06 <@nop> submit them +01:06 <@nop> and we'll decide at the end of the month +01:06 < philocs> our only mascot is satan +01:06 <@nop> well +01:06 <@nop> that's taken +01:06 <@nop> BSD +01:06 <@nop> ;) +01:07 < philocs> we could make a scarier satan +01:07 < hobbs> that's a DAEMON! +01:07 <@nop> hehe +01:07 <@Chocolate> black +01:07 <@nop> ok +01:07 <@nop> next +01:07 <@nop> bugfixes +01:07 <@Chocolate> tshirt must be black +01:07 <@nop> ok +01:07 <@nop> yeah +01:07 <@nop> all artist must make inversed drawings +01:07 <@nop> so that it caters to black or white backgrounds +01:07 <@nop> and you can use color :) +01:07 <@nop> oh +01:07 <@nop> and the winner +01:08 < nemesis> http://www.stk.com/products/50_beta/about50.cfm +01:08 <@nop> will of course get full credit by having his logo on the t-shirt +01:08 < nemesis> nice +01:08 * al-jabr fears that this T-shirt may be hopelessly dorky +01:08 <@mids> al-jabr: make a better one +01:08 <@mids> okay... +01:08 <@mids> next poing? +01:09 <@mids> point :) +01:09 <@mids> beeing: bugfixes +01:09 <@mids> UserX fixed even more bugs then reported +01:09 <@mids> there are still a few (possible) bugs out there.. +01:09 <@mids> if you found some that aren't mentioned +01:09 <@mids> please tell us +01:10 < al-jabr> I personally couldn't replicate the terminal bug, unless that was something in CVS +01:10 <@mids> without bugreports we cant fix +01:10 <@nop> neither could i +01:10 <@mids> al-jabr: I have had it in the past; but couldn't repeat +01:10 <@mids> I'll ask Jeekay for more details +01:10 < philocs> where do I find list of outstanding bugs? +01:11 <@nop> well everyone is encouraged to use the sourceforge bug tracker +01:11 <@nop> but most people don't +01:11 <@nop> ;) +01:11 < philocs> bug tracker is good +01:11 <@nop> we should probably link to that on our main site +01:11 <@mids> http://www.sourceforge.net/projects/invisibleip/ +01:11 <@nop> for a bug submital +01:11 < firegod> too bad it doesnt have an IRC frontend (: +01:11 <@mids> most bugs are mailed to the iip-dev mailinglist though +01:11 < philocs> ok I just subscribed yesterday +01:11 <@mids> cool +01:12 < nemesis> cause the logo, whate resolution? and dpi ? +01:13 <@nop> any one knowing graphix have a suggestion for resolution and dpi? +01:13 < firegod> start big +01:13 < firegod> it can be resized +01:13 <@nop> ok +01:13 <@nop> kewl +01:13 < firegod> down if needed +01:13 < nemesis> -e +01:13 < firegod> it is much more difficult going the other way (: +01:13 < nemesis> hehe +01:13 < nemesis> firegod +01:13 < nemesis> something +01:14 < hobbs> nop: would you be interested in having it in a vector graphics format, if that just happens to be how it's done? +01:14 < firegod> always good to have high res masters +01:14 < nemesis> 10 megapixels +01:14 <@nop> svg? +01:14 < nemesis> 72dpi +01:14 < hobbs> (not that I even own a vector program, but somebody might care) +01:14 < nemesis> or 1000 ? +01:14 < nemesis> ;) +01:14 < nemesis> very dificult +01:14 < nemesis> +f +01:15 < firegod> sure, if they are creative.. +01:15 < firegod> but svg isnt widly used just yet +01:15 < al-jabr> Question: I'm patching IIP to use /dev/random. Would you be interested in incorporating this? I'm doing it #ifdef linux for until I or someone configurifies the source. +01:15 < firegod> so standard raster formats would be more usable atm +01:15 < firegod> al-jabr: finish the patch and submit it to the mailing list +01:15 <@nop> al-jar +01:15 < al-jabr> okay +01:15 < hobbs> al-jabr: I'd suggest making it #ifdef SOME_FLAG_THAT_CAN_GO_IN_MAKEFILE +01:15 < al-jabr> yeah +01:16 < al-jabr> will do +01:16 < hobbs> (and have a well-commented DFLAGS line in Makefile) +01:16 <@nop> yarrow is a very good prng +01:16 <@nop> it's known to be secure +01:16 <@nop> and we have done a test with our randomness via chi-square +01:16 < al-jabr> nop: I believe yarrow would be redundard when we have /dev/urandom +01:16 <@nop> and it got 25% which is good +01:16 <@nop> yes, but yarrow is portable +01:16 <@nop> and known to be stronger +01:16 <@mids> al-jabr: the problem is that not all operating systems have a good implementation for /dev/random +01:16 < firegod> not at all +01:17 <@nop> I would rather rely on what a cryptography expert developed +01:17 <@nop> then the /dev/random on the machines +01:17 < hobbs> true. A -DUSE_DEV_RANDOM might end up being useful, or it might just hurt a lot of people who don't know what they're doing. +01:17 <@mids> otoh, giving the more modular future of IIP, maybe several alternatives could be an option +01:17 < hobbs> and not the best odds on the first. :) +01:17 <@nop> yes +01:17 <@nop> and we do plan to add more entropy in the future +01:18 < al-jabr> Well, linux /dev/random and /dev/urandom are some of the most scrutinized crypto out there... I'm mostly thinking of that because it's a very good entropy pool that's out there on very many machines running IIP +01:18 <@nop> to increase this +01:18 < firegod> general question: with iip2 are we going to have more feedback from the proxy? +01:18 < al-jabr> you wouldn't have to go querying the user for entropy. +01:18 <@nop> yes firegod +01:18 <@nop> well you usually don't +01:18 <@nop> but it's definitely added plus +01:18 <@nop> if there isn't enough +01:18 <@nop> it will query +01:19 <@nop> and we will probably look into adding a form of /dev/random entropy very soon +01:19 < hobbs> does linux /dev/random support O_NONBLOCK ? +01:19 <@nop> because we intend on really strengthening the pool +01:19 <@nop> I'm sure it does hobbs +01:19 <@nop> /dev/random let's you select your pool size +01:19 < hobbs> nop: yeah, but there's a softlimit, and a hardlimit in the kernel, and the hardlimit isn't that big. +01:19 <@nop> al-jabr it would be best to hold off +01:19 < al-jabr> nop: personally I'd trust linux more, which uses SHA1 and uses all kinds of hardware sources of entropy, than a newbie who might just go entering 'aaaaaaaaaa...' but anyway it's only an option +01:20 <@nop> al-jabr +01:20 < al-jabr> ok +01:20 <@nop> thats not all the entropy +01:20 <@nop> there is more +01:20 <@nop> there are network timings, and dh calculation timings as well +01:20 < al-jabr> but it only has access to user-mode entropy +01:20 <@nop> and we plan to add more +01:20 < al-jabr> why reinvent the wheel. i recommend using /dev/random and for those who don't have it, EGD. +01:20 <@mids> nop: would it harm to give al-jabr a try, and maybe use it as plugin for entropy? +01:20 < al-jabr> since the GPG and linux people are doing it +01:21 <@mids> nop: alww +01:21 < al-jabr> why don't we concentrate on doing what we do best? +01:21 <@nop> that's fine +01:21 <@mids> nop: always good to have alternatives around +01:21 <@nop> if you want to submit a patch +01:21 <@nop> please do +01:21 <@nop> I'm not against it +01:21 <@nop> and we definitely want to add more entropy +01:21 < philocs> is the darwin /dev/random good? is it the same one in linux or openbsd? +01:21 <@nop> so please submit it to iip-dev when you've added it +01:21 < firegod> thats what mailing lists are for, people can digest it better +01:22 < al-jabr> okay, will do. +01:22 <@nop> thnx +01:22 <@nop> is that all? +01:22 <@nop> no more questions? +01:22 <@mids> hehe +01:22 <@nop> or suggestions +01:22 <@nop> or complaints +01:22 < nemesis> hm.. +01:22 < philocs> I have a dumb newbie question ... +01:22 <@nop> sure +01:22 < firegod> well. release dates? +01:22 < nemesis> cache in the nodes +01:22 <@mids> sjoet +01:22 <@nop> oh oh on +01:22 <@nop> that wasn't on the list +01:22 <@nop> but +01:23 <@nop> we are at this time working on a short term todo list +01:23 <@nop> that will be publicized +01:23 < philocs> if someone hacks a relay to log, does that mean they can see the trafic for private channels that go through it? +01:23 <@nop> no +01:23 <@mids> philocs: all traffic is encrypted node-node and end-end +01:23 < philocs> ok, so you can only get the cleartext at the server, right? +01:23 < firegod> but not contextually withing IRC +01:23 <@nop> right +01:24 < firegod> right +01:24 < firegod> and the client +01:24 <@mids> philocs: correct +01:24 <@nop> yes +01:24 < philocs> good +01:24 < firegod> how far are you from encrypted channels? +01:24 < hobbs> and the client -- well, can only see stuff that's actually sent to it. +01:24 <@mids> firegod: nop is working on a roadmap and syncing it with the developers (if I understood well) +01:24 < nemesis> add an multicast option for filetransfers, when one user, will send the same file to some multiple clients +01:24 < hobbs> which means, if you don't even know that a channel exists, then you can't (intentionally or accidentally) snoop it. +01:24 <@nop> firegod it will be done when we decentralize +01:24 <@nop> which is our next goal +01:25 <@nop> after 1.1 stable +01:25 < nemesis> that the nodes between the nodes cache it +01:25 < firegod> okay. roadmap. +01:25 < hobbs> nemesis: actually.... that's worth thinking about -- talk to chocolate. :) +01:25 < philocs> is there an advantage to having "channel key encryption" before decentralization? +01:25 <@mids> nemesis: well, filetransfer isnt implemented in IIP itself anyway +01:25 < nemesis> lol +01:25 < firegod> hobbs: well, knowing about a channel is easy +01:25 <@mids> nemesis: it CAN do multicast, just send it to a channel :) +01:25 < hobbs> nemesis: it should be possible to add a hack to fileserv to have it use a channel, and then anyone who wants to receive just joins. :) +01:25 < hobbs> firegod: oh, is it? +01:25 < nemesis> what can you do with an anonymous network +01:26 < nemesis> when you can share code? +01:26 < nemesis> whats about some c code? +01:26 < firegod> multicast is a problem due to not spectacular widespread support.. +01:26 <@mids> philocs: yes, I'd think so... less trust needed on the server +01:26 < nemesis> when the complet internet are banned for open source? +01:26 < hobbs> firegod: not multicast IP, just "multicast" :) +01:26 < firegod> hobbs: re fileserv channel: that gives you encrypted channels btw (: +01:26 < nemesis> how you can share this information? +01:26 < hobbs> firegod: oh, how's that? +01:27 < nemesis> <hobbs> nemesis: it should be possible to add a hack to fileserv to have it use a channel, and then anyone who wants to receive just joins. :) +01:27 < firegod> hobbs: sure, if you join IIP at all it is simple to /list the channels +01:27 < nemesis> not a hack +01:27 < philocs> I might start thinking about some 'channel key encryption'. it doesn't seem like it would be terribly complicated thing to me, just keep private keys in some directory maybe +01:27 < nemesis> built in +01:27 < nemesis> and an "server node" option +01:27 < nemesis> to allow that +01:27 < nemesis> or not +01:27 <@mids> philocs: you could implement it client side... +01:27 < hobbs> nemesis: okay, I'm just behind the times. I haven't worked on fileserv for... months +01:27 < nemesis> and an option for the cache size for it +01:27 <@mids> philocs: look at the blowfish.pl scripts for irssi and xchat +01:27 < firegod> philocs: and perl plugins on clients +01:27 <@mids> s/blowfish/blowjob/ +01:28 < philocs> mids: would it make sense to implement it in the client side of isproxy? +01:28 <@mids> nemesis: caching wouldnt make much sense when everything goes still through the central ircd +01:28 < philocs> that way it would work with all clients +01:28 < nemesis> <mids> nemesis: caching wouldnt make much sense when everything goes still through the central ircd +01:28 <@mids> philocs: maybe; but that would require the 'vircd' +01:28 < nemesis> i think there are planned to be an p2p network? +01:28 < nemesis> and then theres no central hub +01:28 <@mids> nemesis: for IIP 2 +01:29 < nemesis> only some nodes +01:29 < nemesis> where cache the datas +01:29 <@mids> nemesis: but that is long term; first IIP 1.2 +01:29 < philocs> nemesis: I think you want freenet maybe +01:29 < nemesis> no +01:29 < philocs> p2p file transfers with caching +01:29 < nemesis> only an option to share some public files +01:29 < nemesis> or larger text +01:29 < philocs> thats what freenet does +01:29 < firegod> any merging of namespace possible between freenet and iip? +01:29 < nemesis> that you don'*t copy it line for line in the channel /query +01:29 < hobbs> what sits on top of the IIPv2 network could be a lot of interesting things -- but that's a while off. :) +01:29 <@mids> nemesis: first we would need decentralized routing... +01:30 < nemesis> k +01:30 < firegod> every isproxy was a freenet node? +01:30 < nemesis> but don't forget it ;) +01:30 < philocs> I don't think it makes sense to cannabalize freenet ... +01:30 <@mids> nemesis: once we have that; ask again :) +01:30 < firegod> philocs: does it do the job? +01:30 < nemesis> lol +01:30 <@mids> philocs: giving recent freenet-shit; I'd say no, indeed it doesn't +01:30 < firegod> philocs: and I like 'incorporate' a bit better +01:30 < hobbs> it should be possible to write a mini-freenet on top of IIP... but it would be better to leave freenet at what it does, and take advantage of the high speed and "pushiness" of IIP to write even better things. +01:30 < nemesis> in how many years? *fg* +01:31 < firegod> alright (: +01:31 < firegod> people do want to exchange chunks of binary data thru their messaging clients, in this case IIP +01:31 < firegod> how will that be addressed? +01:31 < philocs> firegod: well, I think it does the job well, and it will only get better. yes I agree that it would be better to have iip implement the freenet protocol for freenet type things rather than make something incompatible +01:31 < hobbs> for example, IIPv2 should be able to support the niftiest "anonymail" anyone's ever seen (without a bot), unless I'm hallucinating. :) +01:31 < nemesis> hm.. +01:32 < nemesis> hacker ethic +01:32 < nemesis> the slogon +01:32 < nemesis> for.. +01:32 < nemesis> miiiids!! +01:32 <@mids> hobbs: IIPv2 will be so smart that it could do your math homework +01:32 < hobbs> that's good, 'cause I don't do mine often enough. +01:32 < philocs> speaking of which +01:33 <@UserX> firegod: the intention is to do a DCC emulation using Freenet as the transport for files +01:33 < Grishnav> Sorry if this has already been suggested, I've missed much of the conversation being in and out of the room, but how about some sort of API for IIP to create modules? After IIP gets completely distributed (with v2) you could have all sorts of interesting modules pop up... a file transfer mod, perhaps a freenet node mod if you only wanted one service running... +01:33 < firegod> UserX: that'll work (: +01:33 < philocs> UserX: I think that is the best solution +01:33 < hobbs> Grishnav: that's more or less the plan, as I understand it. And if it's not, we'll beat nop with halibut until it is. +01:33 < Grishnav> lol +01:34 < firegod> UserX: but if IIPv2 is decenteralized, would this dcc emulation need freenet? you already can do point multipoint point transfers, you just need a session handshake for that kind of transfer +01:34 < firegod> albiet dcc +01:34 < nemesis> waaaaaaaaaah +01:34 < philocs> plus if every iip user was running some sort of freenet implementation, that would make freenet much better +01:34 < nemesis> ardvark +01:34 < nemesis> grrrrrr +01:34 < nemesis> where is he? +01:34 < nemesis> where can speak german? +01:34 < hobbs> also, it should be (more) convenient to have multiple IIPv2 networks, but I think that's a given. :) +01:34 < nemesis> or known only a little bit german +01:34 < firegod> philocs: thats what I'm saying (: +01:34 < nemesis> and have the english hacker ethic? +01:34 < firegod> whos working on IIPv2? +01:35 < philocs> I need to go study for my german test soon +01:35 < philocs> firegod: are you left handed or in oz or something? +01:35 <@mids> hm, ppl; I got to go; keep chatting here +01:35 <@mids> bbl +01:35 < nemesis> hrhr +01:35 < nemesis> mids!!! +01:35 < firegod> philocs: nope, just a freak +01:35 < nemesis> don't drunk to much ;p +01:35 < nemesis> *fg* +01:36 < firegod> mids is working on IIPv2 I'm sure, anyone else? UserX? +01:36 < nemesis> nop +01:36 <@UserX> firegod: in theory yes. but currently we want to keep IIP low bandwidth. freenet would me suited transfering large volumes of data (and better because it doesn't have a constraint of realtime routing that IIP needs) +01:36 < nemesis> i think +01:36 <@nop> yes +01:36 < nemesis> aaaaaah +01:36 < nemesis> nop +01:36 < philocs> I guess what is really needed is for someone to write a C implementation of freenet ... +01:36 < firegod> UserX: this is true. +01:37 < firegod> UserX: or at least an opt-in on that feature +01:37 <@UserX> firegod: yes i am working v2 +01:37 < hobbs> philocs: I agreed with that pretty heavily a few months ago, but right now I'm happy to let java fred do its thing, and settle down, before anyone clones. +01:37 < hobbs> (now that it _works_, that is) +01:37 < firegod> UserX: how have you solved scaling issues for resource location? ie: how do you find nodes originating #channels? +01:37 < philocs> UserX: yes well thats a good reason to not make it easy for people to do 'dcc' and to encourage them to use freenet +01:38 < firegod> philocs: it should just be opt-in.. people wanting to abuse their bandwidth, can go right ahead.. those on modems dont get killed (: +01:38 < hobbs> UserX: would be nice to keep in mind, though, that freenet is good at pulling things, and iip is good at pushing things. :) +01:38 < philocs> hobbs: well I agree, I think the java version is fine but if we are going to basically package freenet with iip somehow then eventually (and probably when freenet hits 1.0?) we will want a c implementation +01:38 < firegod> philocs: those wanting freenet backed features, change a setting and BLAM it just works +01:38 <@UserX> firegod: haven't worked out highly scalable system yet +01:39 < firegod> hobbs: IIP is a great way of grouping freenet keys (: +01:39 < hobbs> philocs: that's some pretty long thinking. :) +01:39 < firegod> UserX: ah. If you havnt peaked at Circle, I encourage you to (: +01:39 < firegod> I know mids said he'd played with it +01:39 < philocs> hobbs: well freenet is getting more stable all the time +01:40 < youkai> yeah, i would never run freenet as long as its only java +01:40 < firegod> theres a slogan for ya d-: +01:40 < firegod> "getting more stable every day" +01:40 < youkai> too bulky +01:41 < philocs> youkai: its not too bad +01:41 < youkai> plus i think its shitty to have os software that only compiles on a corp owned language +01:41 < Grishnav> I don't like Java anymore than the next guy, but I certainly am a freenet fan. I'll use the java one, but only until I hear about a C implementation. :) +01:42 < youkai> i mean if you guys were using the os non sun java i wouldent mind as much +01:42 < youkai> ah yes +01:42 < youkai> blackdown +01:42 < hobbs> youkai: freenet works fine on a few flavors of non-sun java. +01:42 < hobbs> blackdown has sun behind it. +01:42 < youkai> you just cant win with java then :/ +01:42 < firegod> so? +01:42 < youkai> i dont trust sun any more then i do microsoft +01:43 < firegod> java is not your friend (: +01:43 < Grishnav> Does anyone have a link to the souce download for Blackdown? (Their site is less than helpful) +01:43 < firegod> I encourage those who are disatisfied with java, to try phthon for their scripting needs (it is NOT java) +01:43 < youkai> yeah python is cool +01:44 < youkai> but i dident stop running m$ operating systems just so i could let another corp in the door (sun) +01:44 < hobbs> Grishnav: er. It's in "non-free" for a reason, isn't it? +01:44 < philocs> you are wanting me to write freenet in python? would a python module be distributed with iip? +01:44 < Grishnav> Ahh... I was under the impression is was free. my mistake. +01:45 < youkai> thats the only problem i have with freenet +01:45 < philocs> java is not evil, sun treats java differently than MS treats windows +01:45 < hobbs> Grishnav: no. If you ask sun, it's impossible to create a free java2 implementation, and they've done a good job of making it true. +01:45 < youkai> i mean java is a lot easier to code in because you dont have to worry about memory leaks and stuff as much +01:45 < Grishnav> rofl +01:45 < youkai> the garbage collector lets you be lazy +01:45 < philocs> hobbs: why is it impossible? +01:45 < Grishnav> [16:45] <youkai> i mean java is a lot easier to code in because you dont have to worry about memory leaks and stuff as much -- yeah, it's no wonder that all java apps are so goddamn memory hoggy!! +01:46 < youkai> yeah thats because they need the whole jre loaded in memory with the software +01:46 < hobbs> philocs: because if you write anything that's java2, and claims to be "java", then sun will destroy you. :) +01:46 < philocs> hobbs: yes but you can make java, just don't call it 'java' +01:46 < hobbs> er... without obtaining the appropriate license and signing the appropriate agreements first, that is. :) +01:46 < Grishnav> call it coffee +01:46 < philocs> kaffe +01:46 < Grishnav> hehe +01:46 < Grishnav> yeah +01:47 < Grishnav> I've played with Kaffe +01:47 < hobbs> philocs: true. But nobody's done it. +01:47 < Grishnav> not quite mature enough yet, but getting there +01:47 < philocs> hobbs: uh yes, the FSF has done it +01:47 < hobbs> philocs: oh? +01:47 < philocs> yes +01:47 < youkai> but seriously i think java is right up there with VB +01:47 < philocs> Kaffe +01:47 < hobbs> philocs: Kaffe is not java2. +01:47 < youkai> its for lazy programmers +01:47 < youkai> who dont mind being owned by a corp +01:47 < philocs> hobbs: but there is no reason it could not implement java2 +01:47 < hobbs> philocs: except for the fact that it doesn't. +01:47 < philocs> plus gccj or whatever its called +01:48 < hobbs> er... +01:48 < youkai> the other thing is java2 is huge, and they have a gigantic team of programmers working on it all the time +01:48 < hobbs> yeah. gcj/gij are also nice. +01:48 < firegod> not to interupt, but java wars work out better in apropriatly named channels (: +01:48 < philocs> hobbs: but its not a legal issue, the java spec is an open standard, the java name is not +01:48 < youkai> gcj? +01:48 < philocs> youkai: gcc that compiles java code +01:48 < youkai> huh +01:49 < youkai> to binary or does it still need a jre +01:49 < philocs> binary I believe +01:49 < hobbs> philocs: that's a pretty heavy restriction, though. +01:49 < hobbs> You can't say: this is java, this is compatible with java, or this smells like java. +01:49 < philocs> hobbs: well I don't think so. You can make the claim that 'this software is not java, but you will probably find that it works the same' +01:50 < philocs> which most people would understand +01:50 < hobbs> probably. +01:50 < youkai> anyway, why rewrite java when you could just use c++ +01:50 < youkai> its almost the same language +01:51 < philocs> arg, I would rather use java over c++ +01:51 < philocs> but I'm not getting into that +01:51 < philocs> anyway, I forgot where this horrible diatribe started +01:51 < hobbs> youkai: not really. c++ doesn't force you to use OO crap when it's completely inappropriate, like java does. :) +01:51 < firegod> round and round we go, where we stop nobody knows +01:51 < firegod> philocs: exactly +01:51 < philocs> ok, so in isproxy, is there like a client side and a node side? +01:52 < firegod> philocs: you know how many times I've seen this exact same 'argument' ? (: +01:52 < youkai> hobbs: hah +01:52 < firegod> philocs: there are relays, and proxys and 'servers' +01:52 < firegod> as I see it +01:52 <@UserX> philocs: can you clarify your question? +01:52 < philocs> I mean, would it make sense to put channel key encryption in isproxy, the part that actually talks to the irc client on 6667? +01:52 < hobbs> philocs: sorta. there are nodes, and there are nodes. :) +01:52 < firegod> philocs: dont forget you have multiple clients for each isproxy +01:53 < hobbs> and nodes 1) talk to clients 2) talk to nodes 3) (one of them) talks to the server. +01:53 < philocs> firegod: really? I've never been able to see this behavior, actually maybe its just my configuration +01:53 < firegod> (: +01:54 < philocs> but anyway, does my question make sense? +01:54 < youkai> i just came here to beg you guys not to write the next ver of iip in java :D +01:54 < firegod> which question d-: +01:54 < firegod> youkai: i think thats a given +01:54 <@UserX> philocs: currently IIP 1.x is essentially a tunnel. having the client implement channel encryption would require a lot of work to do. and would become redunant when v2 gets done +01:54 < youkai> also if theres freenet people around, a c++ ver would be nice +01:55 < firegod> UserX: how about isproxy functioning as an http tunnel? +01:55 < firegod> UserX: IIPv2 as well? +01:55 < nemesis> <youkai> i just came here to beg you guys not to write the next ver of iip in java :D +01:55 < nemesis> noooooo +01:56 < philocs> I'm thinking that you could have it so that there ways like a 'keys/' directory and then you could have in that 'channel.key' or something and then just run blowfish or whatever on what goes in and out of that channel, understand? +01:56 < nemesis> native code are the best thing +01:56 < philocs> and fuck c++, I'll take java over c++ anyday +01:56 < philocs> but I also think that c is nice +01:57 <@UserX> firegod: 1.x could be used to tunnel to a single fixed HTTP server +01:57 < firegod> okay, enough language wars please? +01:57 < nemesis> m$ sponsored his .net campain, and will place his IL on the front +01:57 < youkai> k :D +01:57 < firegod> User: hrmm +01:57 < nemesis> you can controll the compiller +01:57 < philocs> youkai keeps brining it up, if he likes c++ so much, he should marry it +01:57 < nemesis> thats the different +01:57 < firegod> oh jebus +01:57 < youkai> heh philocs: if you like java so much you should go work for sun +01:57 < nemesis> can't +01:58 < philocs> UserX: would that make sense or is it better to wait for next version to do that? +02:00 < youkai> UserX: thats a good idea +02:00 <@UserX> philocs: to do that with 1.x network would require giving nodes the intelligence to read and parse recompose IRC client messages/commands +02:01 < philocs> oh I see +02:01 < nemesis> <UserX> philocs: to do that with 1.x network would require giving nodes the intelligence to read and parse recompose IRC client messages/commands +02:01 < nemesis> xml ;) +02:01 <@UserX> it's possible but would take a fair amount of effort which i want to put into v2 +02:01 < nemesis> very flexible +02:01 < philocs> I understand +02:02 < philocs> later +02:11 < logger> logging ended +--- Log closed Wed Oct 16 02:11:14 2002 diff --git a/i2p2www/meetings/logs/15.rst b/i2p2www/meetings/logs/15.rst new file mode 100644 index 00000000..a7b0ba83 --- /dev/null +++ b/i2p2www/meetings/logs/15.rst @@ -0,0 +1,9 @@ +I2P dev meeting, October 16, 2002 +================================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/150.log b/i2p2www/meetings/logs/150.log new file mode 100644 index 00000000..5bb9fc11 --- /dev/null +++ b/i2p2www/meetings/logs/150.log @@ -0,0 +1,142 @@ +16:16 < jrandom> 0) hi +16:16 < jrandom> 1) 0.6.1.1 +16:16 < jrandom> 2) i2phex +16:16 <@protokol> speaking of, whats the news on legion and i2phex +16:16 < jrandom> 3) syndie +16:16 < jrandom> 4) ??? +16:16 < jrandom> 0) hi +16:16 * jrandom waves +16:16 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-October/000939.html +16:17 <+postman> hi +16:17 < jrandom> might as well jump into 1) 0.6.1.1 +16:18 <+postman> ya +16:18 < jrandom> the network has been growing in number and in usage, but things have been doing pretty well +16:18 <+postman> .. apart from the irc servers +16:18 < jrandom> aye, thats an interesting one +16:19 < jrandom> (the irc servers are currently running an older rev, and we're still working on some debugging to understand exactly why things are the way they are) +16:19 <+Ragnarok> what happened? +16:20 < jrandom> hopefully we'll get the irc servers upgraded sooner rather than later, as there has been some good stuff lately +16:20 < cervantes> Ragnarok: server<->server link is shakey under 1.1 +16:20 <+Ragnarok> weird +16:20 < jrandom> 0.6.1.1, that is ;) +16:20 <+Complication> protokol: see forum, he finally opted for a sensible approach +16:20 <+postman> cervantes: don't mention the time travel, idiot +16:20 < cervantes> 0.6.1.x +16:20 <+postman> :) +16:21 < cervantes> oop +16:21 <+postman> jrandom: i hope i'll be able to build a test ircd this week +16:21 <+postman> jrandom: we could link to an instance run by you or cervantes +16:22 < jrandom> aye, that'd be great. we could even split off the different tunnels into different jvms, using different streaming libs and router versions, to isolate the issue further +16:23 < jrandom> it'd be cool if we could do that before 0.6.1.2, but if not, no big deal +16:24 < jrandom> ok, anyone else have anything for 1) 0.6.1.1? +16:24 <+postman> jrandom: apart from that: runs like hell +16:24 < jrandom> would that be a good hell or a bad hell? :) +16:24 <+postman> a hell of a hell :) +16:25 <+Complication> Eh, managed to cause a few more errors (but those were really, really borderline stuff, router restart under a running i2phex.) Will send privately. +16:26 < jrandom> ah cool, thanks Complication +16:26 <+Complication> (e.g. they probably won't hurt anyone in real life) +16:26 < jrandom> heh never underestimate people's ability to break things :) +16:27 < cervantes> or the ingenuity of fools in testing fool proof systems +16:27 <+postman> yea, make something fool proof and you'll be rewarded with a new kind of fool +16:28 < jrandom> hallelujah +16:29 < jrandom> ok, anything else for 1), or shall we move on to 2) i2phex +16:30 < jrandom> there has been a lot of discussion as of late, and legion has agreed to merge back the changes made into sirup's i2phex codebase. +16:30 <+postman> move +16:30 < jrandom> this is quite cool, as it'll be great for us all to benefit from legion's hard work while remaining entirely open and secure +16:31 <+Ragnarok> what did he actually do? +16:33 < jrandom> latest changes include the addition of systray4j, striker's timeout updates, increased tunnel length defaults, some nsis and jni stuff, and a few other changes +16:33 <+Ragnarok> hm, ok +16:33 <+postman> jrandom: so there're a bunch of improvements - those will be kept tho? +16:34 < jrandom> certainly, all good stuff will be integrated into i2phex +16:34 < jrandom> there are a few things i'm not so sure of, but that'll be discussed with legion outside of the meeting ;) +16:35 <+postman> k +16:36 < jrandom> ok, anyone else have anything for 2) i2phex? or shall we move on to 3) syndie? +16:37 * postman prepares his syndie500 franchising goods +16:37 < jrandom> heh +16:37 < jrandom> ok, Ragnarok, wanna give us the rundown on the latest? +16:37 <+Ragnarok> hm, ok +16:38 <+Ragnarok> Syndie will now get new posts from an archive automatically. +16:38 <+Ragnarok> you can set which archives you want to get updates from, and set how often you do it in the syndie config file +16:39 <+Ragnarok> more details about that are in history.txt +16:39 <+Ragnarok> it needs a ui, but otherwise it's essentially done +16:39 <+Ragnarok> 'course, no one seems to be posting anything recently, so maybe it's not that useful :) +16:40 < jrandom> [insert field of dreams quote here] +16:40 < jrandom> thanks Ragnarok, this has been an oft requested feature +16:41 <+Ragnarok> cool +16:41 <+Ragnarok> happy to do it, wasn't really that much work +16:42 <+Ragnarok> mostly just scratching my own itch :) +16:42 < cervantes> oh wasn't it? or forget it then :P +16:42 < cervantes> or=oh +16:42 <+postman> (hush, the genius must not admit that it needs to work hard too) +16:42 <+Ragnarok> hehe +16:43 <+Ragnarok> anyway, if anyone's got bug reports/feature requests/boos/cheers/etc. let me know +16:43 < jrandom> (cheers!) +16:43 <+Ragnarok> next thing I'm thinking of is auto matically importing petnames seen in posts into the routers petname db, but that looks like it could be complicated... +16:44 <+Ragnarok> but, it would essentially allow syndie to replace addressbook +16:44 < jrandom> that would be Very Cool +16:44 <+nickless_head> yeah :) +16:45 <+Ragnarok> I just have to figure out how to get a list of petnames out of the archive +16:45 <+Ragnarok> everything else is trivial +16:45 <+nickless_head> ragnarok: are your changes already in cvs? (too lazy to read the whole discussion) :) +16:45 <+Ragnarok> yeah +16:45 <+nickless_head> :happy: +16:45 * nickless_head considers cvs update +16:45 <+Ragnarok> have been since yesterday +16:45 <+nickless_head> nah, probably better to wait for the next release +16:45 < jrandom> perhaps get the petnames whenever they're rendered, exposed via the HTMLRenderer (in the addressReceived) +16:46 <+Ragnarok> ok, I'll look into that +16:46 < jrandom> cool, thanks Ragnarok +16:47 <+Ragnarok> well, that's it from me, unless there's questions +16:49 < jrandom> wr0d. ok, jumping on to 4) ??? +16:49 < jrandom> anyone have anything else to bring up for the meeting? +16:49 < cervantes> aye +16:49 * nickless_head looks at cervantes interestedly +16:50 <+fox> <mancom> is there anything new on Q or feedspace? +16:50 <+postman> nickless_head: hey, he's mine - don't dare to stare at him like that :) +16:50 <+nickless_head> I'm not staring at him .. I'm looking at him interestedly. +16:51 < cervantes> After some deliberation I've revived the "Forum User of the Month" spot - and this month it deservedly has gone to Complication for outstanding forum contributions +16:51 <+nickless_head> congratulations complication! +16:51 <+postman> kudos :) +16:51 < cervantes> so he gets an avatar (whether he likes it or not) :P +16:51 <+Complication> Heh, I hope my blunders have been less outstanding. :O :D +16:52 <@protokol> oh yeah +16:52 < jrandom> w00t! thanks Complication +16:52 < cervantes> (which is active now) +16:52 <@protokol> hows that Yellow Submarine i2phex test going +16:52 <@protokol> any notable speeds or lack thereof? +16:52 <+Complication> It's going. +16:52 < jrandom> mancom: nothing new regarding Q or feedspace +16:53 <+Complication> No hyperfast speeds, but a guaranteed good-enough speed, I'd say. +16:53 < jrandom> protokol: last i heard was 10-20KBps, but thats just stuff on the forum +16:53 <@protokol> im downloading it right now +16:53 * nickless_head understands what postman implied +16:53 * nickless_head blushes +16:53 <+Complication> (also: I re-read part of the tech intro, and couldn't find flaw with the network comparisons. I think they're good enough.) +16:54 <+postman> nickless_head: LOL (sorry) +16:54 * Complication looks at the avatar and grins :D +16:54 <+nickless_head> postman: *GG* (no problem) +16:54 < cat-a-puss> Has anything been done in an effort to get "Amazon honor system" as an alternate method of collecting donations? +16:54 <+Complication> Spot on. :P +16:55 <@protokol> cat-a-puss: what do you mean? +16:55 < jrandom> not yet cat-a-puss, haven't seen wilde around +16:55 < jrandom> woah, hey phedy +16:55 < phedy> Hi jrandom. +16:55 < cat-a-puss> protokol: it's like pay-pal, except you can use an account you have with amazon.com to make payment +16:56 < jrandom> Complication: thanks re: the comparisons. there are a few cleanups left, but its coming along +16:56 <@protokol> weak +16:56 <+Complication> (not that I know Tor or Freenet in decent degree, although I've used both) +16:57 * cat-a-puss is thinking of creating a bounty for helping finish the distributed search engine. +16:57 < jrandom> (before putting the doc out on the normal website i'll run it by those folks for comment) +16:58 < cervantes> Complication: it's an art installation on a roundabout in London that causes havoc with the traffic ;-) +16:59 < jrandom> cat-a-puss: i've got to work out some other financial stuff soon anyway, so shall let you know asap +16:59 < jrandom> ok, anyone else have anything to bring up for the meeting? +16:59 < cat-a-puss> oh if we want documents translated to some other languages before 1.0, I may know people who could help with Spanish and Chinese. +16:59 < cat-a-puss> ok +16:59 < jrandom> kickass, that'd be great +17:00 <+Complication> cervantes: thanks for telling, I wasn't aware where such an, umm... effect occurred :D +17:00 < jrandom> there's a draft tech intro floating around in cvs, and we'll eventually want whatever our website redesign turns out to contain to be translated +17:03 * nickless_head goes to sleep +17:03 < jrandom> i suppose i should grab the baffer... +17:03 < jrandom> if there's nothing else +17:03 * jrandom winds up +17:03 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/150.rst b/i2p2www/meetings/logs/150.rst new file mode 100644 index 00000000..a511a34a --- /dev/null +++ b/i2p2www/meetings/logs/150.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 4, 2005 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/151.log b/i2p2www/meetings/logs/151.log new file mode 100644 index 00000000..b87b3f87 --- /dev/null +++ b/i2p2www/meetings/logs/151.log @@ -0,0 +1,234 @@ +16:29 < jrandom> 0) hi +16:29 < jrandom> 1) 0.6.1.2 +16:29 < jrandom> 2) I2PTunnelIRCClient +16:29 < jrandom> 3) Syndie +16:29 < jrandom> 4) I2Phex +16:29 < jrandom> 5) Stego and darknets (re: flamewar) +16:29 < jrandom> 5) ??? +16:29 < jrandom> 0) hi +16:29 <@cervantes> (6) +16:29 <+postman> you mean 6)? +16:29 < jrandom> yeah, i can't count ;) +16:30 * postman high-fives cervantes +16:30 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/000990.html +16:30 < wiht> Questions should be item 6. +16:30 < jrandom> since i'm 30 minutes late, y'all have already read through those notes, I'm sure, so lets get this underway ;) +16:31 < jrandom> 1) 0.6.1.2 +16:31 <@cervantes> 6) Discuss jrandom's roommate's poor judgement in timing +16:31 < jrandom> *cough* ;) +16:31 < jrandom> ok, as mentioned in the email, the 0.6.1.2 release seems to be doing pretty well +16:32 < jrandom> we've found the bug that had kept the irc servers back on an older build, and they're now up to date too (w00t!) +16:32 <+postman> :) +16:32 < wiht> Speaking of that, in the netDB on the router console, would it be possible to list the table with routers and their versions at the top of the page? +16:33 < jrandom> the number of routers per version, right? sure, that could be done pretty easy, maybe integrate it into the peers.jsp table (showing per-peer version) and a new table at the bottom? +16:34 < jrandom> its kind of nice seeing 9 versions playing well together, though of course newer ones work best +16:35 < jrandom> ok, anyone else have something to bring up regarding 1) 0.6.1.2? +16:35 <+postman> one of my routers shows 1080 known +16:35 < jrandom> zounds +16:35 <+postman> i think this is a bit off track? +16:35 < jrandom> is that on 0.6.1.2? +16:35 <+postman> yeah, think so +16:36 < jrandom> hmm, yeah, thats a... bit high. i'm seeing about half that many right now +16:36 <+Complication> Sustainably 400-ish here +16:37 <+bar> same here +16:37 < wiht> I see 260 known routers. +16:37 < jrandom> postman: perhaps we can dig into whats going on in that router after the meeting (could you tar.bz2 me netDb/routerInfo-*?) +16:38 <+postman> jrandom: yeah thanks +16:38 < jrandom> gracias +16:38 < jrandom> yeah, not everyone will see every netDb reference, so thats normal for there to be fluctuation +16:40 < jrandom> ok, if there's nothing else on 1) 0.6.1.2, lets swing on over to 2) I2PTunnelIRCClient +16:40 <@cervantes> nice one dust +16:40 < jrandom> as mentioned in the email, we've got a new IRC-protocol-specific filter available in CVS, and it should be rolled out as the default in the next rev +16:41 <+postman> cool +16:41 < jrandom> yeah, this is very cool, people have been asking for something like it for ages +16:41 <+Myo9> Jrandom, you have become more open recently, we have learned about your ex, and now your room mate, etc. Do recall: http://www.navysecurity.navy.mil/st031204.jpg +16:41 < jrandom> *cough* +16:42 < dust> if you wish to see what your client send you can add net.i2p.i2ptunnel.I2PTunnelIRCClient=INFO and then look at the logs to see it all +16:43 < dust> i've tested some clients but there are many.. +16:43 < jrandom> yeah, i've been watching it for a lil bit, but the filtering seems sound +16:44 < jrandom> there are some neat things we may be able to do in the future too - e.g. PING/PONG locally, to cut down on network activity +16:44 <+Complication> dust: thanks for the "info" :) +16:44 <+bar> awsome dust, thanks a lot +16:44 < wiht> Does this mean we don't need to set up an extra IRC tunnel? +16:44 < jrandom> wiht: no, you'll need an irc tunnel, but it can replace the one you use already +16:45 <+Complication> wiht: just worry less about our IRC client giving away our ass +16:45 < jrandom> postman/cervantes: any thoughts on increasing or removing the server ping/pong timeouts? +16:45 < wiht> That explains it, thanks. +16:46 <+postman> mmh, i would not remove them, my client completely freaked when i played around with it +16:46 < jrandom> postman: well, i'm thinking if it responded to them locally, so the client would get a really, really fast PING/PONG +16:46 <@cervantes> postman: the proxy could respond to pings +16:46 < jrandom> (but the ping/pong wouldn't need to go over the network) +16:47 < jrandom> i don't know the impact, but it may be worth looking into. +16:47 <@cervantes> but I'm not sure how the servers would react, you might end up with a bunch of zombie clients +16:47 <+postman> jrandom: well +16:47 < jrandom> well, the streaming lib's keepalive should handle that +16:47 * Complication has occasionally experienced zombification +16:47 < jrandom> Complication: recently? +16:47 <+postman> jrandom: if the proxy pings for the client, the proxy must ping/pong to the client as well +16:48 <+Complication> A week ago, I think. +16:48 < jrandom> postman: a PING from the client to the proxy would have the proxy respond directly to the client with a PONG without sending anything over i2p +16:48 <+Complication> But my "copy" was dropped eventually. +16:48 <@cervantes> jrandom: the connection would be held open...the servers would need to lower their threshold for deciding at what point a client is stale and need ejecting +16:48 < jrandom> Complication: ah, the irc servers weren't up to date back then, shouldn't happen anymore +16:49 <+Complication> Without me using "ghost". Recent uses of the ghost command have been due to operating with many nodes. +16:49 <+postman> jrandom: and the lag measurement? +16:49 < jrandom> cervantes: right. and/or if necessary, the proxy could inject an extra PING message to the server if it /needs/ one. +16:49 <+postman> i find it quite useful to know if i am lagged or not +16:49 < jrandom> postman: i do too, but you can always /msg yourself +16:50 < dust> you could perhaps reduce the number of pings +16:50 < jrandom> it would save a substantial amount of bandwidth, since tunnel messages are 1024byte blocks, sent over 2*k+1 hops +16:50 < jrandom> that too +16:50 < jrandom> i don't know, just an idea. what we have now is kick ass regardless +16:51 <+postman> ok, i would try to patch a testserver +16:51 <@cervantes> perhaps we could look into reducing the number...but I think we should still send some real pings do determine if the clients are still alive +16:51 <+postman> maybe it works +16:51 < jrandom> seems reasonable cervantes. i don't think it'd need any patching on the server, i hope? +16:52 <+postman> jrandom: to deactivate maybe - but lowering the interval is conf parameter +16:53 * postman chews on the ircd documentation ( again ) +16:53 < jrandom> cool, no rush. just something we can look into sometime +16:53 <@cervantes> class servers +16:53 <@cervantes> { +16:53 <@cervantes> pingfreq 120; +16:54 <@cervantes> class clients { pingfreq 90 } +16:54 <@cervantes> that's my current config +16:54 <+postman> cervantes: yes, i know - the question is if it can be deactivated at all +16:54 <@cervantes> I wouldn't deactivate them...just look into reducing them +16:55 <+postman> ok, let's start with that +16:55 <+postman> cervantes: how about 180 secs? +16:56 <@cervantes> in at the deep end with 240 +16:56 <@cervantes> but perhaps we should ge tthe ircproxy side of things ready first +16:57 <@cervantes> *discuss after meeting* +16:57 <+postman> agreed +16:57 < jrandom> w3rd. ok, anything else on 2) I2PTunnelIRCClient, or shall we move on to 3) Syndie? +16:57 <@cervantes> anything to reduce my current 40kb/sec average router traffic ;-) +16:58 < jrandom> heh, for some reason i doubt thats all irc ;) +16:58 < jrandom> ok, movin' on +16:59 * cervantes hides is pony video downloads he's been leeching from jrandom all week +16:59 <@cervantes> is=the +16:59 <+postman> LOL +16:59 < jrandom> as mentioned in the mail, there's some pretty cool stuff going on with syndie +16:59 < jrandom> the cli is trivial, but dust's new Sucker looks really promising +16:59 < jrandom> dust: wanna give us a rundown? +17:00 < dust> oh, +17:01 < dust> well, it uses rome for parsing the feeds and then converts it to sml, like described in jrandoms blog +17:02 < dust> it's not what you'd call robust yet, but it's only two days old :) +17:02 < dust> i've got some dilbert in my syndie.. +17:02 < dust> :) +17:02 < dust> . +17:02 < jrandom> nice +17:03 < jrandom> ok, what are your thoughts on where its going - should we toss it into the syndie source and expose it as a cli, or keep it separate and distribute it independently, or something else? +17:04 * dust don't know, you decide +17:04 < dust> the less separate tools the better +17:04 < jrandom> yeah, probably easier to bundle it all together, that way everyone knows they can use it +17:05 < jrandom> we'd then be able to do things like integrate it into the web interface, and maybe into Ragnarok's scheduler (syndicating with other nodes and pulling from rss/atom/etc) +17:07 < jrandom> ok, anyone have any questions/comments/concerns on 3) Syndie? +17:07 < wiht> If you keep integrating software into I2P, it may become a bloated software package. +17:07 < wiht> Of course, I can turn off Syndie if I am not using it. +17:08 < jrandom> the i2p sdk 13KLOC +17:08 < jrandom> and the i2p router is only 22KLOC +17:08 < jrandom> but yeah, there is an impact on download times of the install +17:09 < jrandom> if someone wanted, they could build a stripped down router with no client apps, using just the router.jar, jbigi.jar, and i2p.jar +17:09 < wiht> Yes, I was referring to the download. +17:09 < jrandom> (but its much more useful when there's a web interface to control it, and i2ptunnel, and the streaming lib, etc ;) +17:11 < jrandom> smeghead was working on a distribution system (like emerge, for java), and there's the jpackage folks too +17:11 < jrandom> if someone wants to look into a seamless and reliable way to manage the apps without bundling, it'd be pretty cool +17:12 < jrandom> ok, if there's nothing else on that, lets jump on over to 4) I2Phex +17:13 < jrandom> I don't really have much to add beyond whats in the status notes +17:13 < jrandom> redzara: you around? +17:13 <+redzara> yes i'm +17:13 <+redzara> I'm already working on the next version, while waiting for the meeting with Gregor. +17:13 < jrandom> ah great +17:13 <+redzara> Work, for the moment, primarily consists in identifying the differences and the needs related to the use of I2P such as for example tcp/udp vs i2p, management of the parameters specific to I2P (and management of the update of these same parameters at the time of the next versions, ...) port of GWebCache to I2P, use RSS or not, use push or not... +17:14 <+redzara> I have much documentation and code to read +17:15 < jrandom> wow, yeah, sounds like a lot. let me know if you've got any questions regarding i2p integration, or if you just want someone to bounce ideas off +17:16 < jrandom> getting the I2Phex part into a plugin for the mainline Phex would be really kickass +17:17 < jrandom> ok, anyone else have anything for 4) I2Phex? +17:18 <+redzara> I would need certainly assistance for the petname part +17:19 <+redzara> and maybe too for fine tunning tunnels's parameters +17:19 < jrandom> cool, the naming is pretty easy - at a basic level, you could even get by without using names at all (this is how I2Phex does it now) +17:20 < jrandom> tunnel config shouldn't be a problem either, though that brings up the idea that maybe Phex would need an "advanced configuration" section for plugins +17:20 < jrandom> (we'd obviously want to have good defaults anyway) +17:21 <+redzara> maybe something like ircclient, an filter to be sure +17:22 <@cervantes> better to get the app in shape imho +17:22 < jrandom> that might work, though dealing with arbitrary byte sequences may be tough +17:23 < jrandom> though, a proxy like ircclient might be able to allow any gnutella client to use it. but it'd be a bunch of work. +17:23 <+redzara> humm, it's just an idea ;) +17:23 * jrandom doesn't know the protocol well enough to say what the best approach is, so suggest going with the simplest thing that could possibly work :) +17:25 < jrandom> ok, if there's isn't anything else, perhaps we can swing through 5) stego and darknets briefly +17:26 < jrandom> i'm not sure if there's anything i have to add beyond whats being said on the list (and major discussion should probably continue there) +17:27 < jrandom> that said, is there anything people want to bring up about the issues raised? +17:27 < wiht> Freenet version 0.5 and 0.7 were mentioned in the discussion. Is there a version 0.6 for Freenet? +17:27 < jrandom> 0.6 is their current "unstable" branch of the network +17:27 < jrandom> afaik +17:27 <+postman> ohh and i thought it has been stolen by alien forces +17:28 < jrandom> while blaming the aliens is usually a safe bet, this is one of the few instances where they're not at fault +17:28 <+postman> :) +17:28 < wiht> Toad was talking about being able to harvest the IP addresses of I2P or FreeNet nodes, right? +17:28 < jrandom> among other things +17:29 < wiht> Just wanted to clarify that, thanks. +17:29 < jrandom> np. ok, anyone else have anything on 5), or shall we move on over to the good ol' fashioned 6) ??? +17:30 <+postman> ok, i got one for 6) +17:30 < jrandom> consider us moved. +17:30 < jrandom> whats up postman? +17:30 <+postman> we all have seen that protocol specific filter capable proxies are good and needed +17:31 <+postman> would it be feasable to invest thinking in a generic proxy +17:31 <+postman> that can be fed with a protocol description +17:31 <+redzara> I would like to have an application like cron using beanshell to run code java code dynamically +17:31 <+postman> along with stuff to watch for/filter/disguise +17:31 <+postman> like a filter/sanitize xml description +17:32 <+postman> so that we dont need new source but just a new filter file/profile +17:32 <+postman> (just a question if its worth to think about it) +17:32 < jrandom> very, very complicated postman. it'd be possible to use a lexer like javacc to build input languages and an app to translate that language into the output format +17:32 <@cervantes> it's catching the stuff that deviates from the protocol that's tricky +17:33 <+postman> it was just an idea to trigger a process of brainstorming +17:33 <+postman> imho something like a generic proxy with modeled filter/parser is very usable +17:33 < wiht> Has anyone been able to connect to eepsites.i2p? I have tried several times over the past week, but was always unsuccessful. +17:33 < jrandom> wiht: i loaded it once, its the same as eepsites.com +17:34 < jrandom> (or is it .net? or .org? i forget) +17:34 * wiht visits eepsites.com +17:34 < jrandom> postman: if someone could come up with something that'd work, that'd kick ass +17:34 <+postman> jrandom: ok, i'll do some thinking together with susi +17:34 < jrandom> w3wt +17:34 <+postman> jrandom: maybe we'll drop it next week +17:35 < wiht> It is eepsites.com, and it is a search engine for eepsites. +17:35 <+postman> but i had a dream that it worked +17:35 <+postman> :] +17:35 < jrandom> :) +17:36 * Complication suspects that descibing all the subtleties which occur in protocols... requires code, and nothing less than code +17:36 <+Complication> (for most protocols, at least) +17:36 <@cervantes> nah just some eeevul regex +17:36 <+postman> Complication: maybe this suspicion is the reason that keeps us from further investigation +17:37 <+postman> Complication: i am not yet sure, but suspicion alone will not put me to rest on that matter +17:37 < jrandom> well, an important point here is something dust demonstrated for us - +17:37 * Complication fears a regex capable of such things +17:37 < jrandom> code isn't necessarily that scary. +17:37 <+postman> see? :) +17:37 <+postman> a good filter modelling language will do the same +17:38 <+postman> :) +17:38 <@cervantes> tcl? :) +17:38 <+Complication> It would have to be good. +17:38 * jrandom sees that you've got your own flying ponies too postman ;) +17:38 * dust also felt bad about duplicating code here and there +17:38 <+postman> jrandom: no cows :) +17:38 < jrandom> working code >>> theoretical improvements in code +17:39 <+postman> mmh +17:40 <+postman> one thing i learned from i2p +17:40 < wiht> >>> means "much, much better?" +17:40 <+postman> do not give up on first looks +17:40 < jrandom> true enough postman +17:40 < jrandom> yes wiht +17:41 < jrandom> it would be really cool +17:41 < jrandom> ok, anyone else have something to bring up for the meeting? +17:41 <+bar> well, how's the IMAP working, postman? (i read about it in the forums but haven't tried it yet myself) +17:41 <+postman> bar: try it yourself - i have no user reports yet +17:41 * cervantes rolls in the pony shaped gong +17:42 <+bar> ok, will do :) +17:42 <+postman> bar: and for me it works FINE :) +17:42 < jrandom> nice +17:42 <+bar> cool +17:42 <+postman> cervantes: you're fixated +17:42 <@cervantes> me?! +17:42 <@cervantes> :) +17:43 < jrandom> ok, before we reach the 90 minute mark +17:43 * jrandom winds up +17:43 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/151.rst b/i2p2www/meetings/logs/151.rst new file mode 100644 index 00000000..340f5c2e --- /dev/null +++ b/i2p2www/meetings/logs/151.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 11, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/152.log b/i2p2www/meetings/logs/152.log new file mode 100644 index 00000000..40ef226b --- /dev/null +++ b/i2p2www/meetings/logs/152.log @@ -0,0 +1,270 @@ +16:10 < jrandom> 0) hi +16:10 < jrandom> 1) 0.6.1.3 +16:10 < jrandom> 2) Freenet, I2P, and darknets (oh my) +16:10 < jrandom> 3) Tunnel bootstrap attacks +16:10 < jrandom> 4) I2Phex +16:10 < jrandom> 5) Syndie/Sucker +16:10 < jrandom> 6) ??? +16:10 < jrandom> 0) hi +16:10 * jrandom waves +16:10 < jrandom> weekly status notes are up at http://dev.i2p.net/pipermail/i2p/2005-October/001017.html +16:10 < dust> yay, works now. thanks Gregor +16:10 < cervantes> hullo +16:11 <+fox> <blx> heloa +16:11 < jrandom> ok, jumping into 1) 0.6.1.3 +16:11 < jrandom> y'all have updated at a pretty good clip, thanks! +16:12 < jrandom> things seem to be in reasonable condition, but I don't have much to add beyond whats in the status notes +16:12 < jrandom> anyone have any questions/comments/concerns re: 0.6.1.3? +16:13 < jrandom> ok if not, lets jump on in to 2) Freenet, I2P, and darknets (oh my) +16:13 < cervantes> 609 known peers! +16:14 < cervantes> (w00t) +16:14 < jrandom> aye, network has been growin' +16:14 <+fox> <blx> oh my! +16:14 * cervantes is holding a sweepstake for how long until the big 1000 +16:14 < jrandom> heh +16:14 < tethra> heheh +16:15 < tethra> are we betting with digital cash? ;) +16:15 < cervantes> but it show how solid i2p core has got lately that the user uptake has been accelerating +16:16 < cervantes> nah...jrandom has already unknowningly donated all his beer money for this year +16:16 < jrandom> hehe +16:16 < jrandom> ok, on 2), i'm not sure if i've got anything else to add to the subject (i think we've flogged that horse). anyone have any questions/comments/concerns on it? +16:18 < cervantes> as you said, if nothing else it has stimulated some interesting semi-related security discussions ie 3) +16:18 < jrandom> if not, we can jump forward at a quick pace to 3) Tunnel bootstrap attacks +16:18 < jrandom> aye, that it has +16:19 < jrandom> the issue Michael brought up quantifies a general view i've had, but its nice to make it explicit +16:20 < jrandom> there's going to be some further discussion on the newer attack later this evening (once i can write up a reply), but the former doesn't seem to be much of a problem +16:21 < jrandom> does it make sense to people, or do people have any questions or concerns about it? +16:22 < cervantes> heh...that either means everyone is cool with it or they can't make head of tail of what the issues are +16:23 < cervantes> I'll put myself in the ignorance is bliss category +16:23 < jrandom> heh its basically an attack where the mean guys just happen to be the outbound endpoint of every tunnel you've ever built +16:23 < jrandom> now, when you're just starting up, "every tunnel you've ever built" is a very small number (eg. 0, 1, 2) +16:24 < jrandom> but after a few seconds, the number grows large enough to turn (c/n)^t into a really really small number +16:25 < tethra> (c/n)^t is... +16:25 < jrandom> (this is one of the reasons why we don't start up the i2cp listener - and hence, i2ptunnel/etc - until a little while after startup) +16:25 < jrandom> c == # of colluding peers (bad guys), n == # of peers in the network, t == # of tunnels you've built. +16:25 < cervantes> right... +16:25 < tethra> ah +16:26 < jrandom> so as t grows, the probability of successful attack gets really small +16:26 < cervantes> so for it to be even viable you'd have to start using your router for sensitive tasks within a couple of minutes of it starting up? +16:26 < jrandom> (or, in any case, smaller than the probability of taking over all hops in a tunnel) +16:26 < tethra> ahh, i see +16:27 < jrandom> cervantes: immediately, before the 3rd tunnel is built +16:27 < jrandom> (assuming you use 3 hop tunnels) +16:27 < cervantes> that's fairly improbable +16:28 < cervantes> just from a use case perspective +16:28 < jrandom> 'zactly. +16:28 < jrandom> and since we build more than 3 tunnels on startup before letting any clients run, its not just a probability issue +16:28 < jrandom> but its good to quanitify the attack anyway +16:29 < cervantes> is it worth letting the router churn for a bit longer to guard against any likelyhood? +16:30 < cervantes> or churn harder... +16:30 < jrandom> perhaps. if we ignore connection establishment time as well as nonrandom peer selection, it has no likelihood +16:31 < tethra> that's cause for a "woot!" i take it? +16:32 < jrandom> aye, though from an engineering perspective, we shouldn't ignore those characteristics ;) +16:32 < jrandom> so, for 0.6.2 we may want to look at it during the revamped tunnel peer selection / ordering implementation, to make sure its behaving Sanely +16:34 < jrandom> ok, if there's nothing else on 3), lets move on to 4) I2Phex +16:34 < jrandom> sirup isn't here, and i haven't seen striker on irc - redzara, you around? +16:36 <+redzara> yes +16:36 <+redzara> First pass is nearly completed : port Sirup's mod to lastest phex cvs. +16:36 < jrandom> nice1! +16:36 <+redzara> next : Second pass : diff from Sirup code to base phex code used in initial release, to be sure i don't forget anything :) +16:37 <+redzara> maybe terminated for this W.E. +16:37 < jrandom> wow that'd be great +16:37 <+redzara> Pass three : refactoring comm layer with GregorK +16:37 <+fox> <GregorK> hope you are aware that in latest Phex CVS the download code is not stable and the download file is not compatible with previous releases +16:38 < jrandom> this is i2p, we're used to instability :) +16:38 <+fox> <GregorK> :) +16:38 <+redzara> For the last pass, as I've currently no contact with GregorK, this sould be pretty hard :( +16:38 < jrandom> GregorK: what would you recommend for inegration? +16:39 <+fox> <GregorK> well you now have contact with me ;) +16:39 < jrandom> ah 'k redzara, the first two are big enough in any case :) +16:39 <+redzara> GregorK : hi man +16:40 <+redzara> GregorK : I've read carefully all codes +16:40 <+fox> <GregorK> I have a idea on how to build a layer... I can try to prepare it as good as i can and then we can see how good it fits and what needs to be changed +16:40 <+fox> <GregorK> all?? wow... +16:40 <+redzara> Gregork : yes, all !! +16:41 < cervantes> he even knows the size of your underwear +16:41 < Rawn> :D +16:41 <+fox> <GregorK> great... next time I'm shopping I just need to ask you... +16:43 <+fox> <GregorK> what would be nice if we could maybe have someone from the i2phex team on the phex team too.. +16:43 < jrandom> redzara: so, do you think we'll have a 0.1.2 I2Phex release with the results of your second pass before we get everything merged into a plugin layer in the mainline Phex? or will that be all in one go? +16:43 <+redzara> Sorry, but I don't understand / speak /read / write english good enough to laugh with what you have writed +16:43 <+fox> <GregorK> this would also help solve bugs that are on both sides +16:44 < jrandom> GregorK: hopefully we'll find a way that the I2P side is just a thin plugin in Phex though, right? +16:44 < jrandom> or do you think the two should stay separate? +16:44 <+redzara> jrandom : I think we could have an Phex 2.6.4 over I2P, for me I2Phex is down +16:45 < jrandom> down? +16:45 <+fox> <GregorK> i'm not sure if we can make it this way right from the start, but I think the major part of it could be separated into a plugin. +16:45 < jrandom> cool, yeah, its a lot of work, I'm sure +16:46 < jrandom> especially when you look at things like java.net.URL (which leaks DNS requests on instantiation, etc) +16:46 <+redzara> jrandom : down, endded +16:46 <+Ragnarok> grr +16:47 < jrandom> ok right redzara, one we can get everything working in Phex 2.6.4 over I2P, I agree, there wouldn't seem to be much of a need for an I2Phex +16:47 <+fox> <GregorK> right... I think Phex uses the apache URI class in some places to work around this.. but only when necessary +16:48 < jrandom> ah right, I remember playing around with that library, looks good +16:49 < jrandom> we'll definitely be helping audit things a bit for anonymity/security before pushing it for end users over i2p +16:49 < jrandom> (not to suggest there are any problems in Phex, just there are problems in every app, and hopefully we can help sort 'em out) +16:50 <+fox> <GregorK> for some things like Socket use and these things I have an idea on how to integrate it smothly... but other places like different features UDP and such... I'm not sure yet how to solve them best +16:50 <+fox> <GregorK> oh i'm sure there are many problems in phex. :) +16:50 < jrandom> ah, yeah sockets will be easy, but we may need to disable other things. what is udp used for - quick queries? +16:51 <+fox> <GregorK> currently only bootstrapping +16:51 <+fox> <GregorK> UDP Host Cache.. a replacement for GWebCache +16:52 < jrandom> ahhh, ok. +16:52 <+redzara> So we don't need it if we have a descent GwebCache ? +16:53 <+fox> <GregorK> yes... but the standard GWebCache have there security problems too... +16:53 <+redzara> GregorK : not inside I2P I think +16:54 < jrandom> oh, that part could be overcome - I2PSocket is authenticated - you know the 'destination' of the peer on the other end, so they couldn't say "I'm, er... whitehouse.gov.. yeah!" +16:54 < jrandom> but you're right, its soemthing that needs to be verified +16:54 <+fox> <GregorK> also firewall to firewall transfers would be a UDP topic we like to implement once we find a volunteer :) +16:54 < jrandom> ah, well, I2P doesn't need firewall to firewall transfers - I2P exposes an entirely open end to end address space :) +16:55 < jrandom> but... ooh, thats something that might be useful +16:55 < jrandom> if Phex users had "0 hop tunnels", they'd get free NAT traversal/firewall to firewall transfers with pretty decent speed +16:55 <+fox> <GregorK> another one would be LAN broadcasts of queries and such... for easier sharing of contents in private networks +16:56 < jrandom> (0 hop tunnels offers a level of plausible deniability without requiring any intermediary peers to carry the trafffic) +16:57 < jrandom> hmm, lan broadcast is good, though i'm not sure if i2p would really need that (since its an anonymity risk to know where the other peer is :), so perhaps that feature could be disabled when using the I2P plugin? +16:58 < cervantes> *disabled by default +16:58 <+fox> <GregorK> well its not available yet.. but in this case user usually know each other anyway to build that private network.. +16:58 < jrandom> oh right cervantes +16:58 < jrandom> right right GregorK +16:59 <+fox> <GregorK> are there any changes regarding the user interface?? +17:00 <+bar> well, we won't need flags :) +17:00 < jrandom> at the least, the ability to have a few configuration options related to I2P would be useful. +17:01 < jrandom> i think sirup was able to switch in some of the display to use I2P 'destinations' instead of showing IP + port numbers, so I think it was fine +17:01 <+redzara> And what about bitzyNot for the moment, but flags and countries are unused +17:01 < jrandom> bitzy? +17:01 <+redzara> sorry, wrong coupy/paste :( +17:02 <+fox> <GregorK> can you provide a list of configuration options and optional features you need? +17:03 < jrandom> I'm sure we can get those to you. a host+port that I2P is running on and a few drop downs regarding performance/anonymity tweaks should do it +17:03 < jrandom> we'll get you the details though +17:02 <cervantes> [x] Super transfer speed mode +17:02 <+fox> < GregorK> well bitzi is used to identify files.. is that an anonymity problem? +17:03 < vulpine> <redzara> GregorK : I'm preparing it, but basicly, thre is no changes +17:03 <+fox> < GregorK> :) ask your provider cervantes... +17:03 <redzara> GregorK : maybe, I'm working on it +17:04 <cervantes> GregorK: heh UK resident....no chance ;-) +17:04 <+fox> < GregorK> if you transfer files between 2 Phex instances on the same PC.. transfers are lightning fast ;) +17:05 <cervantes> cool...I have lots of cool movies I can share with myself :) +17:05 <cervantes> * strike that from the meeting notes * +17:06 <bar> jrandom touched the subject before, but, here's that crazy idea again: +17:06 <+bar> how 'bout integrating i2p into Phex, so that ordinary users have 0-hop tunnels? +17:07 <+fox> <GregorK> I think display of flags and IP+port comes from the HostAddress object.. which would be hidden from the new layer.. so you can display something else +17:07 <+bar> (for plausible deniability and udp firewall hole punching) +17:08 <+fox> <GregorK> not sure if I really understand what that means ;) +17:08 <+bar> probably me neither ;) +17:09 < jrandom> GregorK: essentially, it means that Phex users would talk to each other directly, but would get plausible deniability, as they could be talking indirectly +17:09 <+bar> jrandom, i'm sure you're catching my drift here, could you elaborate? +17:09 < jrandom> they'd also get I2P's NAT traversal thrown in for free, as well as data security and protection from sniffing by ISPs/etc +17:09 <+redzara> GregorK : so you have to strip all code related to host+port + IsLocalIP + Is PrivateIP + ... +17:10 < jrandom> on the other hand, (a BIG other hand), it wouldn't be able to talk to gnutella clients that don't run on top of I2P +17:10 < jrandom> (though eventually, they all will ;) +17:10 <+fox> <GregorK> Well I think the first step is - and that step is already big enough - to bring i2p and phex closer together. +17:10 < jrandom> agreed +17:10 <+bar> (damn, didn't think of that) +17:11 <+bar> yeah, def. +17:11 < jrandom> this is flying pony stuff. lets get the practical things first +17:11 <+fox> <GregorK> and after we see how good that worked we can decide how we go further.. +17:11 < jrandom> exactly +17:12 <+fox> <GregorK> redzara: I like to have two implementations of HostAddress one for i2p and on like the current. +17:14 <+redzara> Gregork : no pb, I've commented all code in my mod you could easyly build two implementations. Just let me finish the initial work please +17:14 <+fox> <GregorK> sure.. no problem.. +17:14 < jrandom> :) ok, so redzara, you think we may be able to get an alpha test of the new Phex-2.4.2 based version sometime next week? +17:15 < jrandom> (for the phase 2 part. your phase 3 will take more work integrating with the mainline) +17:15 <+redzara> jrandom : next sems to be ok for me +17:16 < jrandom> ok great +17:16 <+redzara> s/next/next week/ +17:16 < jrandom> ok, this is pretty exciting stuff, it'll be wonderful to get it going smoothly +17:17 < jrandom> does anyone have anything else to bring up for 4) I2Phex, or shall we move on briefly to 5) Syndie/Sucker? +17:17 < cervantes> I2P will surely benefit from such killer apps +17:18 <+fox> <GregorK> btw there is a Phex CVS mailing list for all CVS changes in Phex... if that is of any help +17:18 < jnymo> *ehem*.. hell yes +17:18 < jrandom> ok great, thanks GregorK +17:18 < jrandom> definitely cervantes +17:19 < jrandom> ok, on 5), I don't really have anything to add beyond whats there +17:19 < jrandom> dust: are you around? +17:19 <+redzara> GregorK : Thanks but handlingone version is far enough for me :) +17:19 < jrandom> hehe redzara +17:19 < dust> I haven't had much spare time lately, but if I do I'm thinking I'll try to get a handle on this addresses.jsp thing, add 'RSS' in the protocol dropdown in there and then build a path through Updater, Sucker to BlogManager. +17:20 < dust> unless anyone have a better idea +17:20 < jrandom> kickass +17:20 < jrandom> that sounds perfect. +17:21 < jrandom> though, hmm, maybe it'd need an additional field (the "what blog to post it in" and "what tag prefix")... +17:21 < jrandom> maybe a separate form/table would make sense, though maybe not +17:22 < dust> oh, I thought addresses.jsp was for one blog only (since you have to login to get there?) +17:22 < jrandom> ah, true, good point +17:23 < jrandom> the updater part is kind of fuzzy, but you're right +17:23 < dust> (we'll figure it out when we get there) +17:23 < jrandom> aye +17:24 * jnymo thinks www.i2p.net could start up a 'merchandise cafe' type thing +17:24 < jnymo> with eyetoopie shirts that say "I am Jrandom" on them ;) +17:24 * mrflibble is still catching up on the "flamewar", which seems to be spiraling into a proper flamewar :) +17:24 < jrandom> heh jnymo +17:25 < jrandom> yeah, there's a lot of content in that thread +17:25 < jrandom> ok, maybe this gets us to 6) ??? +17:25 < jrandom> anyone have anything else to bring up for the meeting? +17:25 <+bar> aye, just a quick note on the symmetric nat issue (been doin a lil snoopin'): +17:25 <+nickless_head> jrandom: I know the truth! +17:25 <+fox> <blx> kaffe? +17:25 < mrflibble> oops, sorry jr +17:26 < jnymo> but seriously.. every open source project of any size has their own merchandise section +17:26 <+nickless_head> jrandom: I have definite proof you hacked the last.fm homepage! +17:26 <+nickless_head> (the what you get when you sign up section listed 'a pony') +17:26 < jrandom> jnymo: i think you're right, we will want to explore that avenue, might be a good method of fundraising too +17:27 < jnymo> jrandom: exactly +17:27 * mrflibble would buy the tshirt +17:27 <+bar> right, regarding symmetric nats, +17:27 <+bar> for what it's worth, i think that unlike for the already supported nats, there's no magic trick. the only way to do it properly, is to study and examine each and every symmetric nat's behaviour and use introducers for probing. +17:28 < jrandom> blx: the latest kaffe CVS is completely b0rked. the crypto packages aren't in the source, the prng fails to initialize, and the url handlers can't deal with file:// :( +17:28 < jnymo> You probably wouldn't want to wear it in public until i2p has a few thousand users though ;) +17:28 <+bar> (i believe this is how e.g. Hamachi and Skype do udp hole punching from behind symmetric nats) +17:28 <+nickless_head> jnymo: cups would rule :) +17:28 <+bar> based on what i have read on the 'net so far, symmetric nat prediction algos pretty much suck. +17:28 < jrandom> hmm bar +17:28 < mrflibble> hehe, i wouldn't put my nick on it. oh, and i'm still allive/unarrested even though i've got an IIP ttshirt +17:28 < jrandom> yeah, thats what i read too +17:29 <+bar> i will try gathering some more good, relevant reading material on this. +17:29 <+redzara> Small question : what was the common average percentage of bytes retransmitted in 0.6.1.3 ? +17:29 < jrandom> thanks bar +17:29 <+fox> <jme___> bar, the prediction they got are consistent ? +17:29 <+fox> <jme___> bar, let me rephrase :) +17:29 <+fox> <blx> jrandom, i'm sad to hear +17:30 < jrandom> redzara: I unfortunately forgot to put that into the netDb. I do see 2.6 and 3.8 right now though +17:30 < jrandom> blx: me too :( +17:30 <+fox> <jme___> bar, when you analyze the nat box behaviour and find a formula to predict it. does this always work for this nat box ? or later once it worked, once it fails ? +17:30 < jrandom> blx: i know they're doing some merging with classpath now though, so hopefully once thats sorted +17:30 <+fox> <blx> probably means i wont be joining the party +17:30 < jrandom> blx: are you kaffe-specific, or OSS/DFSG-specific? +17:31 <+fox> <blx> free software +17:31 <+fox> <blx> dfsg you could say +17:31 < jnymo> encase an i2p user wants to use a hosted server for i2p, what would be a liberal, cheap hosted services company to go with? +17:31 <+bar> jme___: hamachi is reportedly able to mediate 97% of all connection attempts. i guess there are some nats out there that show an almost random behaviour when it comes to assigning ports +17:32 < jrandom> ok, I'm sure we'll get something going blx. kaffe used to work, and we don't depend upon anything sun specific +17:32 < jrandom> jnymo: i use sagonet.net, but they've cranked up their prices from 65/mo to 99/mo (but on a fast link w/ 1250GB/mo) +17:32 < jrandom> i know there are some cheap ones in germany too +17:33 <+fox> <jme___> bar, 97% would be terrific +17:33 < jrandom> redzara: what are you seeing for retransmission rate? +17:33 <+bar> jme___: yeah, so i guess most symmetric nats are predictable +17:33 <+fox> <blx> jrandom, i sure hope so. i'm really interested in this shit :) +17:33 <+fox> <jme___> bar, what would you do ? relay, udp hole punching, cnx reversal.. is there others thech ? +17:33 < jnymo> is 99 expensive, on average? +17:34 <+redzara> jrandom between 3;8 and 4.2 +17:34 < jrandom> jme___: we're udp, no need for connection reversal :) +17:35 <+bar> jme___: i'm no expert, perhaps i'll have some more info for next week's meeting (but it sure smells like profiling + udp hole punching ;) +17:35 < jrandom> jnymo: for 1250GB, not really. i've seen 60-120USD/mo for 50-100GB/mo +17:35 < jrandom> bar: perhaps UPnP would be a better way to go? +17:35 <+fox> <jme___> jrandom, even with udp it is usefull :) +17:35 <+redzara> jrandom : but only some node done major impact, maybe some olders +17:35 <+fox> <jme___> vulpine: ok +17:35 < jrandom> though that only helps the people who could control their NAT +17:36 <+fox> <jme___> upnp must be supported but it isnt exclusive to other means +17:36 < jrandom> well, we're doing everything we do now without any UPnP +17:36 <+fox> <jme___> because upnp isnt supported by all nat, far from it +17:36 < jrandom> right, e.g. an ISP's nat +17:36 <+bar> jrandom: if there are no security issues with upnp, i guess it can't hurt. though, hamachi doesn't use upnp +17:36 <+fox> <jme___> here by 'must' = to provide the max connectivity +17:37 <+fox> <jme___> ok going back to my c++ :) +17:38 < jrandom> right jme___, though if we can do symmetric hole punching in addition to cone/restrited hole punching, we're in great shape +17:38 < jrandom> l8s jme___ +17:38 < jrandom> yeah, it'd be ideal if we didn't need it +17:39 < jrandom> ok, anyone have anything else to bring up for the meeting? +17:41 < jrandom> if not... +17:41 * jrandom winds up +17:41 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/152.rst b/i2p2www/meetings/logs/152.rst new file mode 100644 index 00000000..91d030e0 --- /dev/null +++ b/i2p2www/meetings/logs/152.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 18, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/153.log b/i2p2www/meetings/logs/153.log new file mode 100644 index 00000000..81f82f37 --- /dev/null +++ b/i2p2www/meetings/logs/153.log @@ -0,0 +1,440 @@ +16:24 < jrandom> 0) hi +16:24 < jrandom> 1) Net status +16:24 < jrandom> 2) Fortuna integration +16:24 < jrandom> 3) GCJ status +16:24 < jrandom> 4) i2psnark returns +16:24 < jrandom> 5) More on bootstrapping +16:24 < jrandom> 6) Virus investigations +16:24 < jrandom> 7) ??? +16:24 < jrandom> 0) hi +16:24 * jrandom waves +16:24 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/001079.html +16:25 * susi23 waves back +16:26 < jrandom> lets jump on in to 1) net status +16:26 < jrandom> as I mentioned, things look pretty reasonable so far. +16:26 <+fox> <Romster> ah meeting sweet +16:27 < jrandom> there is some good stuff coming down the line too, so we'll have a new release later this week +16:27 < jrandom> anyone have anything they want to bring up regarding 1) net status? +16:27 <@cervantes> omg 7 issues +16:27 <+legion> yup looking good :-) +16:27 < jrandom> busy week cervantes :) +16:28 <@cervantes> can only be good +16:28 <+Complication> Works relatively well, dev.i2p even - I can even pull CVS checkouts without EOF messages. +16:28 < jrandom> nice :) +16:28 <+Complication> Might have been release-related overloads, those last ones. +16:28 <+Complication> But I can't tell. +16:28 < jrandom> dev.i2p is on the latest build code too (-7), so it'll be hopefully performing substantially better than before +16:29 < jrandom> s/dev.i2p/cvs.i2p (etc)/ +16:29 <+legion> forums.i2p also seems to be much better than before :) +16:29 <@cervantes> *ahem* +16:29 <+fox> <Romster> is i2p safe to let others join etc? +16:29 <+Ragnarok> ok, now I've got to try this miraculous "cvs checkout that works the first time" +16:30 <+fox> <Romster> since there is no known limits now +16:30 <@cervantes> that's because everyone's hammering i2p-list instead of posting to the forum +16:30 <+legion> hmm you sure cervantes? +16:30 < jrandom> Romster: well, we've been growing at a pretty good pace lately, but we should hold off on public beta until 0.6.2 +16:30 < jrandom> heh cervantes ;) +16:30 < jrandom> hush Ragnarok, you'll jinx it! +16:31 <+Ragnarok> wow... it's true. I'm speechless +16:31 <+fox> <Romster> k jrandom +16:31 < jrandom> (man my eyes are watering from the curry my roomates are cooking downstairs) +16:31 < jrandom> nice1 Ragnarok +16:32 <+fox> <Romster> lol now that's a strong curry +16:32 < jrandom> ok, if there's nothing else on 1), we can jump quickly through 2) Fortuna integration +16:32 < jrandom> (true that Romster) +16:32 <+fox> <shardy> yay for fortuna integration! +16:32 <+fox> <Romster> moving onto 2) :P +16:32 <+fox> <Romster> what is fortuna? +16:32 < jrandom> heh thought you'd like that shardy :) +16:32 <+fox> <Romster> i've been a bit behind the last month +16:32 <+Complication> PRNG algo, if I remember. +16:33 <+Complication> Supposedly a good one, or so they write. :P +16:34 * Complication knows nothing about its inner workings, though +16:34 < jrandom> shardy: I'd love if you could give it a look sometime +16:34 <+fox> <shardy> of course +16:34 <+fox> <shardy> you're using the gnu implementation? +16:34 < jrandom> Romster/Complication: there are some links in the email +16:34 < jrandom> yeah shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java +16:35 < jrandom> (integrated with http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java ) +16:36 < jrandom> we vary from the straight gnu-crypto implementation though, since we've already got AES256 and SHA256 code (Cryptix's and Bouncycastle's, respectively) +16:36 < jrandom> ok, anyway, this looks cool, as we've been hacking through getting that support in there for probably a year now +16:37 < jrandom> (fortuna integration was one of the main projects driving smeghead to build 'pants' ;) +16:37 < jrandom> if anyone has any questions/comments/concerns about it, please bounce 'em to the list +16:37 < jrandom> (or email, or forum, of course) +16:38 <+fox> <Romster> yeah where is smeghead hes not been around for awhile now +16:38 < jrandom> smeghead is [redacted] doing [redacted] +16:39 < jrandom> ok, moving on to 3) GCJ status +16:39 < jrandom> i2p works on GCJ! [w00t!] +16:39 <+susi23> nice job +16:39 <+legion> sweet +16:39 < jrandom> at least, it does on GCJ 4.0.2 on linux 2.6.12. I haven't tried any other platforms +16:40 < jrandom> yeah, the GCJ and GNU Classpath folks have worked wonders +16:40 < jrandom> it was really easy to get it building, the old static reference classes I remember weren't necessary +16:41 <+Complication> Which sounds quite positive, given Sun Java's less-than complete openness (with regard to distribution, if I remember correct). +16:41 < jrandom> there's a makefile shipped with I2P now, though for simplicity, I think we'll probably stick with distributing pure java, at least primarily +16:41 <+susi23> (next we try to run it on J2ME ;) +16:42 <+fox> <Romster> GCJ to take over Suns JVM> +16:42 < cat-a-puss> how is preformance with GCJ? +16:42 < jrandom> aye, though sun is entirely open, and we /could/ distribute their JVM along side I2P, but their license prohibits distributing their JVM as a general purpose tool +16:42 < jrandom> cat-a-puss: comparable +16:42 < jrandom> most of the heavy work in i2p is already done by assembler code ;) +16:43 <+fox> <Romster> how would i2p go with C#/mono again with that jave to C# adition (forgot it's name) +16:43 <+fox> <Romster> i remember jrandom and i both tryed it out ages ago +16:43 < jrandom> no idea. but if it works with gcj, it might work with ikvm - the mono jvm thing +16:44 <+Ragnarok> IKVM +16:44 <+Ragnarok> nm +16:44 <+fox> <Romster> ah tahts the one ikvm +16:44 <+fox> <Romster> much difereances with GCJ and IKVM and Sun's? +16:45 < jrandom> i've never used ikvm +16:45 <+fox> <Romster> i'm sure you have once with mono or was that eclipse? +16:45 <+fox> * Romster shrugs +16:45 < jrandom> and i2p as shipped doesn't currently support the router console, though it does support the router operation, i2ptunnel, and sam +16:46 <+Ragnarok> what's blocking the router console? +16:47 <+susi23> xerces, when I remember correctly +16:47 < jrandom> xerces stuff. the xercesImpl shipped with i2p has sun.* dependencies, and when I naively tried to drop in the latest xerces, getting that and jdom and rome and the rest of jetty GCJed was b0rking +16:47 < jrandom> there are some additional requirements of the latest xerces, it seems +16:48 < jrandom> (for jar files we don't currently ship). however, I'm sure we can track it down +16:49 <+fox> <Romster> jrandom is good at tracking down problems :) +16:49 < jrandom> even better at making problems +16:49 <+fox> * Romster featches a coffee +16:49 < jrandom> ok, anything else on 3) GCJ status? +16:49 < jrandom> or shall we move on to 4) i2psnark +16:50 < jrandom> consider us moved +16:50 < jrandom> ok, i2psnark is back (yay) +16:51 < jrandom> not much I have to add to whats in the mail... you have anything Ragnarok? +16:51 <+Ragnarok> nope +16:51 <+susi23> regarding web frontend +16:51 <+Ragnarok> more testing would be nice though, so everyone should try it :) +16:52 <+susi23> supporting it with susibt shouldn't be a problem +16:52 < jrandom> ooh give us the scoop susi23 :) +16:52 < jrandom> nice +16:52 <+fox> <jme___> naive question, why spending time supporting old bt client while other (azureus) support full blown client ? +16:52 < jrandom> jme___: azureus *is* kickass +16:52 <+susi23> major release of susibt is scheduled for november :) +16:53 < jrandom> heh cool susi23 +16:53 <+Complication> To me, Azureus seemed terribly complex. +16:53 <+Ragnarok> azureus blows monkey chunks +16:53 <+susi23> for me, I always need a headless solution +16:53 <+Ragnarok> not to put too fine a point on it +16:53 <+fox> <jme___> ok :) +16:53 < jrandom> jme___: azureus is a bit heavyweight though, but is a great general purpose bt solution +16:53 <+Complication> (I personally could see the day I'd misconfigure something in it, and dent my anonymity.) +16:54 <+fox> <jme___> it make sense, just wanted to know +16:54 <+fox> <Romster> to me azerious never workd well i've moved to bitlord which does work +16:54 < jrandom> i do still plan on helping further improve the azneti2p plugin with the azureus folks, but i2psnark took literally less than 2 hours before I was swarming data +16:54 <+legion> Yeah azureus is just too big and complicated for i2p +16:54 <+Complication> If the goal is bundling a bt client along with i2p, a lightweight client sounds best. +16:54 <+fox> <Romster> KISS principal +16:54 <+Ragnarok> I like the official client best, but i2psnark has the major advantage of being simple enough for me to hack on +16:55 <+legion> thing is i2p doesn't need a heavyweight bittorrent client +16:55 < jrandom> yeah, its really clean code (with oddball gnu formatting ;) +16:55 <+Ragnarok> damn gnu +16:55 <+Ragnarok> worst brace style ever +16:55 < jrandom> heh +16:55 <+fox> <Romster> heh code reformatter :) +16:55 <+Ragnarok> jrandom won't let me :) +16:55 <+Ragnarok> well, for good reason +16:55 <+fox> <jme___> independance and simplicity are criteria i definitly agree with +16:56 <+fox> <Romster> will there be options to enable the bt-torrent program on each i2p node? +16:56 < jrandom> aye, it'd be nice if we can backport multitorrent, piece selection, and web capacity to mjw's mainline snark +16:56 <+Ragnarok> the simpler it is, the more likely it will be maintained +16:56 < jrandom> exaaactly Ragnarok +16:57 <+legion> yeah backporting those would be killer +16:57 <+fox> <Romster> as a OT point here take a look at emules KAD network i think it's rather neat. +16:57 < jrandom> Romster: its now shipped with the build by default, but once we get it into susibt, it'll be on the top nav with the rest of the clients +16:58 <+Ragnarok> we need to be able to ship a .torrent maker as well, though. And a tracker would be nice. +16:58 < jrandom> yeah, actually, snark has both of those, I just disabled them because i didn't want to maintain 'em :) +16:58 <+legion> hmm good point ragnarok +16:58 < jrandom> but getting them back in wouldn't be much trouble +16:59 <+Ragnarok> well, the torrent maker at least shouldn't be that bad +16:59 < jrandom> there's a Tracker.java too, and handling in the PeerAcceptor, but I threw out what wasn't necessary, so one would probably want to look back at http://klomp.org/snark/ for those +17:00 < jrandom> (and review http://dev.i2p/~jrandom/snark_diff.txt for changes) +17:00 <+fox> <Romster> since snarik is back it'll get worked on right :) +17:00 <+legion> actually when it comes to a tracker, it'd be better to come up with a distributed solution +17:00 <+fox> <Romster> snark* +17:00 < jrandom> porting code is easier than building a new distributed tracker legion ;) +17:00 <+fox> <Romster> legion, your your talking +17:00 <+legion> true, that +17:01 < jrandom> but I wouldn't be opposed to integrating a nice clean maintained anonymity-friendly distributed tracker solution :) +17:01 <+fox> <Romster> could be tacked onto the eepsites? +17:01 * jrandom spots a flying pony go past the window +17:01 <+Ragnarok> the official bt client has a kademlia based distributed tracker, but obviously that's only good as a design reference +17:01 <+legion> a place to start ;) +17:02 <+fox> <Romster> actually kademlia = emules KAD netowrk? hmm, if that's the case KAD would be ideal for a tracker but bootstraping is an issue +17:03 <+Ragnarok> they're based on the same algorithm, but they're not in any way compatable +17:03 <+Ragnarok> compatible, even +17:04 <+Ragnarok> doing something like emule's KAD for i2phex would be sort of interesting... +17:04 <+Ragnarok> anyway, flying ponies +17:04 < jrandom> :) +17:04 < jrandom> (agreed on both counts) +17:04 < jrandom> ok, anything else on 4) i2psnark? +17:05 <+Ragnarok> as long as we have something to make .torrent files, the existing trackers are fine +17:05 < jrandom> thats a good point - there's some commented out code in Snark's main I believe +17:05 <+legion> no I think the existing trackers are not fine :( +17:05 < jrandom> whats wrong with them legion? +17:05 < cat-a-puss> don't just hand uesrs a torrent file ether +17:05 <+legion> often have trouble accessing them +17:06 < jrandom> hmm cat-a-puss? oh, you mean, we need to get a web interface to transparently swarm? +17:06 <+legion> sites get flooded with traffic +17:06 < jrandom> ah, thats i2p's issue, hopefully 0.6.1.4 will improve that +17:06 < jrandom> postman was telling me how he was getting tons of hits @ tracker.postman.i2p +17:06 < jrandom> i forget the #s offhand +17:06 < cat-a-puss> If we are handling both the swarming code and the code to get the torrent in the first place, might as well make it transparent for the user +17:07 < jrandom> orion.i2p/bt/ isn't really used though +17:07 < jrandom> (and tracker-fr seems lively) +17:07 <+susi23> with susibt I hope to include trackers rss feed, so you don't need to go on the trackers webpage anymore but get the torrents downloaded automatically :) +17:07 < cat-a-puss> also prevents confusing an i2p torrent with a non-anonymous one +17:07 <+fox> <jme___> http tracker for bt doesnt scale due to poorely designed protocol +17:07 <+fox> <Romster> router watchdog router hung hard restart wtf +17:07 <+legion> right, which is my point some trackers are flooded while others are idle +17:07 < jrandom> cat-a-puss: ah, yeah I'd love to integrate hooks from syndie into susibt :) +17:07 <+fox> <jme___> it can be easily fixed but break the compatibility with official bt protocol +17:08 <+fox> <jme___> it is the road followed by the dht tracker stuff +17:08 < jrandom> (and the other way around, so people can easily syndicate .torrent files, etc) +17:08 <+Complication> Romster: I get those, but the machine I get them on is borderline (300 MHz) +17:08 <+fox> <Romster> the distributed tracker is the solution to hammered trackers +17:08 < jrandom> legion: that can easily be remedied by people using different trackers :) +17:08 <+fox> <Romster> azerius DHT +17:08 < jrandom> code is expensive, using different URLs is cheap +17:08 <+legion> yeah, but they don't seem to be doing that do they? +17:09 < jrandom> but, yes, a distributed tracker would be great. not on my roadmap though, but if someone gets it going, that would Rule. +17:09 <+Complication> In due time... surely someone can go distributed too. +17:09 <+legion> Instead of of posting torrents to tracker sites, they could post a bith and whatever details to their eepsite. +17:10 < jrandom> bith == hash? +17:10 <+legion> yeah, stands for bittorrent hash, not my term +17:10 <+Complication> In the beginning, though... a simple and solid client, in Java, bundled with the router... can solve many problems. (Perhaps even pull signed updates without overloading dev.i2p.) +17:11 <+legion> yeah, that would be great +17:11 < jrandom> aye Complication +17:11 <+fox> <Romster> yeah torrent updates +17:11 <+fox> <Romster> ok next item ont he list :) +17:12 < jrandom> ok, 5) more on bootstrapping +17:12 <+legion> yeah lets move on +17:12 < jrandom> lots of interesting stuff on the list as of late, and no way am i going to summarize it all here :) +17:12 <+fox> <Romster> bootstraping the i2p router database? +17:12 < jrandom> anyone have any questions/comments/concerns they want to discuss about the thread? +17:12 < jrandom> Romster: see the list and/or email +17:12 <+fox> * Romster needs to read that list +17:13 < jrandom> aye, there's good stuff on there :) +17:13 <+fox> <Romster> i've been rather busy laterly +17:13 <+Complication> 26 messages to read through, can't comment yet +17:13 < jrandom> still no end result, but we're looking towards a new way of building tunnels for 0.6.2 +17:14 <+fox> <Romster> a new way, is there a flay in the current method? +17:14 <+fox> <Romster> flaw* +17:14 < jrandom> Michael's analysis shows the attack is not really a problem now, as there are easier attacks on the alternatives +17:14 < jrandom> read the list ;) +17:14 <+fox> <Romster> arg later +17:14 <+fox> <Romster> this is now :) +17:15 <+fox> <Romster> i'm noramlly asleep at this time. +17:15 <+fox> <Romster> so i rearly get to be at a meeting +17:16 < cat-a-puss> can you post your ideas for a new way / existing / rejected ways in an email to the list so we can compare +17:16 <+fox> <Romster> so its todo with attack methods and tunnel creation i assume, without reading the list yet +17:16 < cat-a-puss> (that's for Jrandom) +17:16 < jrandom> cat-a-puss: i'm not sure if we've really hashed out an end result yet +17:16 <+fox> <Romster> be an idea cat-a-puss +17:17 <+Complication> Romster: yes, it was more-or-less about giving the endpoint of an exploratory tunnel less influence as a possible attacker +17:17 < jrandom> but http://dev.i2p.net/pipermail/i2p/2005-October/001073.html is the latest for what I see coming out of your suggestion +17:17 < jrandom> well, not influence - i2p is a free route mixnet - but less information +17:18 <+Complication> Yes, that would likely be a more correct term +17:18 < jrandom> (the above linked url is full of arm waving, no solid crypto figured out yet) +17:18 <+fox> <Romster> lesss = better for more robustness agenst attacks, i get what your geting at +17:18 < jrandom> ((but i think its all doable with existing techniques) +17:19 < jrandom> Romster: here's a plot of Michael's attack against the existing algorithm, with the X axist saying what % of the network is compromised - http://dev.i2p.net/~jrandom/fraction-of-attackers.png +17:20 < jrandom> (plain telescopic building would be off the chart before hitting x=200) +17:20 < jrandom> ((so what we have now is literally orders of magnitude better)) +17:20 < jrandom> but we can improve upon that further +17:21 < jrandom> though there's also the garlic routing alternative too +17:21 < jrandom> anyway, yeah, more things to be hashed out, keep an eye on the list :) +17:21 <+fox> <Romster> ok i'll have a good read of that list later +17:22 <+fox> <Romster> and see if i can think of anything too add +17:22 < jrandom> cool +17:22 < cat-a-puss> would the "new" telescopic method be fast enough to do on demand construction? +17:22 < jrandom> I'm not sure we want that +17:22 < jrandom> its the O(1) vs O(N) issue +17:23 < jrandom> the new technique would allow tunnel creation without using the exploratory tunnels, leavng the exploratory tunnels for netDb operation +17:23 < jrandom> (and for exploratory tunnel creation :) +17:24 <+fox> <Romster> hrmm would it be worthwhile screwing with the hackers by givving them heaps of false positives thereby masking the real source +17:24 <+legion> sounds good :) +17:24 <+legion> I'd think some screwing like that would be good +17:24 < cat-a-puss> jrandom: right, I was asking if doing do would speed things up enough, so that sometimes that last hops don't know they are the last hop, as disguesed on list. +17:25 <+fox> <Romster> exploratory tunnels to collect netDB router refereances? +17:25 < jrandom> romster: we are the hackers ;) but yeah, if the false positives overwhelmed the true positives, it'd require substantially large number of attacks to get statistically significant data +17:26 < jrandom> hmm right cat-a-puss, but I'm not sure how that'd speed things up though, it'd move us from an O(1) to O(N) tunnel topology +17:26 < jrandom> or what do you mean by speed things up? +17:26 <+fox> <Romster> and if it got to the point of being detected it could then drop off and go silent forawhile? +17:26 < jrandom> using the new technique would reduce the failed tunnel creations, certainly +17:26 <+fox> <Romster> or mistearly change it's key and continue or something heh +17:26 < jrandom> romster: it'd probably be worth digging through the mails to review the attack ;) +17:27 <+fox> <Romster> yeah after sleep +17:27 <+Complication> Romster: afaik, it's a passive attack mostly, so the target can't detect it occurring +17:27 <+fox> <Romster> and fixing a friends pc i got sitting here +17:27 <+fox> <Romster> ah ic complication. +17:27 < cat-a-puss> jrandom: I'm not talking about the O(n) thing. I mean just waiting to construct a client tunnel until we need one for some apps, rather than just having them sit there all the time. +17:28 <+Complication> (but I might be wrong, and those last 26 messages might have active components) +17:28 <+fox> <Romster> would a long term passive attack evently find the target? +17:28 <+fox> <Romster> i'll comment after i've read the list +17:28 < jrandom> ah cat-a-puss, we'll certainly improve the tunnel pooling for 0.6.2. we currently only build the tunnel when we need it (giving ourselves a little time in case the creation fails) +17:28 <+Complication> Romster: well, persisting the attack beyond tunnel lifetime would require resources and patience +17:28 <+fox> <Romster> and understand it better +17:29 <+Complication> But time plays a part in every probability of success. You try long, you get more chances. +17:29 <+fox> <Romster> ah that's the idea tunnel life tiem be too short to actually have a worthwhile attack work. +17:29 < jrandom> each pool has a defined number of backup tunnels, and we by default build replacements between 60-120 seconds before an old one expires +17:29 <+fox> <Romster> time* +17:30 < jrandom> right Complication - each sample occurs only 'm' times every (c/n) tunnels +17:30 <+fox> <Romster> there is no interaction between each tunnel to gather stastics? +17:30 <+fox> <Romster> as one is about to die and another is being built +17:31 < jrandom> romster: the new tunnels do not talk to each other, no, but thats not the attack Michael has been describing +17:31 < jrandom> there are countless attacks out there, most of which we have dealt with, but whenever someone comes up with one that may have a bearing on I2P's operation, we want to analyze it further +17:31 <+fox> <Romster> must read the list, ok i'll leave it at that for now, anyone else got anything to say? +17:32 < jrandom> ok, if there's nothing else, lets move on to 6) virus investigations +17:32 <+fox> <Romster> actually one stastic i can see could be gathered is no 0 hop would mean that the next hop is not the end point so it could be ruled otu but with millions of nodes that analying technique would be useless +17:33 < jrandom> I don't have anything to add beyond whats been discussed on the forum +17:33 < jrandom> right Romster, there are predecessor attacks on tunnel length, which is one of the main things we're addressing in 0.6.2 +17:33 <+fox> <Romster> virus, what virus, if it's linux it'll be nonexistant, but windows hmmm +17:34 <+Complication> Well, although I couldn't build a matching binary (hell knows hy) the final difference was small enough... to hopefully be useful to anyone interested in reading assembly code. +17:34 < jrandom> Romster: please, the weekly status notes should explain these agenda items, and the meeting is to discuss things /beyond/ whats in the notes ;) +17:35 <+Complication> I sure couldn't find anything obvious in there, but nor could I explain away all the difference. +17:35 <@cervantes> rtfml and rtff +17:35 <+fox> <Romster> yeah i haven't been upto speed for quite awhile, sorry about taht jrandom +17:35 <@cervantes> ;-) +17:35 < jrandom> aye, the fact that both a known safe bat file and the old one triggered the same detection code is substantial +17:35 <+Complication> Yes, that sort of eases doubts. +17:36 <+Complication> I guess the QBFC might have undocumented differences within the same version number (different builds?) +17:37 * jrandom has no idea, but its possibly just some OS interaction, or whatever. I don't know, you've put up enough analysis for people to make their own informed decision +17:37 <+Complication> I think it's better that way. +17:37 <+Complication> Disassembly is really notably outside my usual playground. +17:37 < jrandom> legion: is there anything you want to mention about this, or should people just go through the forum if they want more info? +17:38 <@cervantes> can I just re-iterate what others have said on the forum, and thank Complication for the time and maticulous attempts he's put in to checking this issue out +17:38 < jrandom> aye, its much appreciated +17:38 <+legion> I've nothing to add, I feel that I've said way too much about it already +17:39 < jrandom> 'k understood. ok, anyone else have anything to bring up on this, or shall we move on to 7) ??? +17:39 < jrandom> [consider us moved] +17:40 <+fox> * Romster seconds that :) +17:40 <+legion> ok for 7)??? how about we take a moment to discuss i2phex +17:40 < jrandom> cool, good idea +17:40 <+fox> <Romster> since i'm using it right now even :) +17:40 <@cervantes> no no group hug first +17:40 < jrandom> redzara mentioned he was going to be at the meeting, but progress on the merge is going slow +17:41 <+legion> susi23 inquired about a headless version +17:41 < jrandom> ah cool, i saw your post on that +17:41 <+fox> <Romster> might i add the favourites list needs to be wider to cope with the longer i2p keys +17:42 <+susi23> (that's no must, I was just curious about it) +17:42 < jrandom> well, no one can remember base64 keys, so I'm not sure if you're missing much Romster ;) +17:42 < jrandom> (and the first few bytes should be enough to uniquely identify them) +17:42 <+fox> <Romster> starting i2phex with a server is the major problem i see so far +17:42 <+legion> Actually I'd like to see only like the first 12 characters of keys to displayed in the client +17:42 <+fox> <Romster> heh guess +17:42 * Complication is regrettably majorly busy, and can't do no xml-rpc +17:43 < jrandom> seems reasonable legion +17:43 <+fox> <Romster> what about display as many characters to make the key unique +17:43 < jnymo_> I'm having good results with i2phex +17:44 < jrandom> cool jnymo_, i've been hearing good things too +17:44 <+fox> <Romster> so if 2 keys start with abc it'll be abcx +17:44 < jnymo_> 12 identical characters isn't likely, romster +17:44 <+fox> <Romster> true +17:44 <+Complication> Besides, simpler = quicker +17:44 <+fox> <Romster> but wouldnt need 12 if the keys are that far randomised +17:45 <+Complication> (not that there is much speed to gain from displaying things) +17:45 <+legion> Well maybe there could be a new host properties window, stating the full key and certain information like how much it is sharing and whatever +17:45 <+susi23> (netdb works great with 4 chars only for router ids) +17:45 <+fox> <Romster> or the database and using the keyname=base64 and only displaying the keyname +17:45 < jrandom> hmm, i thought there was already a peer info display legion? +17:46 < jrandom> legion: some things like that would be good to add to the mainline phex, most likely? +17:46 <+legion> hmm could be right... +17:46 < jrandom> (that way Gregor can maintain it ;) +17:46 <+Complication> Well, there's a "Browse host" function, but that may not be the exact same thing. (If it works.) +17:46 < jrandom> Complication: it does +17:46 < jrandom> (work, that is) +17:47 <+Complication> Seems to basically drop the host destkey into the search box +17:47 <+Complication> ...and runs a search. +17:48 < jnymo_> this may be an i2phex mainline issue, but I didn't see an ETA on i2phex downloads +17:48 <+Complication> Hmm... or actually, doesn't run a search. +17:48 <+Complication> Mine seems to wait until I manually start it. +17:48 <+fox> <Romster> whats the nearby i2phex running tickbox for? +17:49 <+legion> I see where there is plenty of room for improvement. ;) +17:49 < jrandom> yep :) +17:50 < jrandom> lots to be done, and the forum is a good place to post up ideas/suggestions/questions(/patches :) +17:50 <+fox> <Romster> despite it's ovous name +17:50 < jrandom> ok, anyone have anything else for the meeting? +17:50 <+fox> <Romster> hmm good point +17:50 <+fox> <Romster> can't think of anything else +17:51 <+fox> <Romster> but anyone working on a distributed data store? +17:51 * cervantes checks his watch +17:51 <+fox> <Romster> like activtely +17:51 < jrandom> Romster: beyond syndie, no +17:51 < jrandom> (not to my knowledge, at least) +17:52 <+legion> well I was wondering about integrating a http download manager into i2p, would make downloading larger content from eepsites easier. +17:52 <+fox> <Romster> q and iphex and one or 2 others but i've not seen anything mentained for awhile now +17:52 <@cervantes> what's the status of feedspace...I haven't heard aught of it in a while +17:52 < jrandom> legion: that would be cool - there's a post about that on the forum too i think +17:53 <+fox> <Romster> ah feedspace another one +17:53 < jnymo_> if this was mentioned in the meeting already, nm.. but, is there news on i2p freenet colab? +17:53 < jrandom> cervantes: last i heard frosk was kind of busy, but if frosk is around, maybe he can tell us more :) +17:53 <+legion> Personally I'd like to see a i2p entropy colab. +17:54 <+fox> <Romster> i have ideas for a datastore, but it be a expansion to existing methods that are in use currently +17:54 <+legion> Given that q, feedspace and such don't seem to be going anywhere fast right now +17:54 < jrandom> jnymo_: I've bounced the freenet folks some code to run on our SSU transport,toad has been joining in on some of the discussions, but freenet won't be in a position for us to run it as a data store on top of i2p for a while (after their 0.7 release comes out, most likely) +17:54 <+fox> <Romster> i want to start a project but not go over what others have done already +17:54 <+legion> wonder if it'd be possible to port entropy to run over i2p... +17:54 < jrandom> legion: entropy would be good, but integration is kind of hard. of course, people could run things like fproxy.i2p for entropy +17:55 * jrandom doesnt know entropy's transport code at all +17:55 <+fox> <Romster> i've put my irc client on hold, there is alot of them in progress already all i2p needs now is a datastore and it'll beat freenet with ease :) +17:55 < jrandom> (but perhaps that'd be a good way to get someone to hack on the GCJ SDK :) +17:56 < jrandom> Romster: helping out on other efforts is a lot more rewarding that starting brand new projects, as you get a lot more done with less effort :) +17:56 < jnymo_> ah.. congrats on the gcj port +17:56 <+fox> <Romster> entropy's is in c or C++ iirc +17:57 < jrandom> right Romster, which is why they'd be able to use I2P's SDK and streaming lib, built with GCJ into native libraries +17:57 <+fox> <Romster> jrandom true, but who :) +17:57 < jrandom> not I +17:57 <+legion> oh and on another issue, just like to mention that today I released a new version of my readme.html update for the i2p router console. +17:57 < jrandom> (the only way to get something you care about done is for *you* to do it :) +17:57 < jrandom> cool +17:57 * dust would like to see some kind of 'squid' syndication for offloading eepsites +17:58 < jrandom> dust: yeah totally, if we can get sucker into that position, that'd be ideal +17:58 < jrandom> e.g. I'd love to get the latest info from orion in syndie, local +17:58 <+fox> <Romster> build a proxy for squid to use :) +17:59 <+legion> I'd been putting it of in the hope that certain improvements to the python eepsitechecker would have been made by now. +17:59 < dust> ah, syndie +17:59 < jrandom> (thats actually what syndie is for - syndication to cut down on load) +17:59 < dust> _the_ answer +17:59 < jrandom> there's a python eepsite checker? +17:59 <+fox> <Romster> first i've heard about it +17:59 <+legion> yeah, it's what I use ;) +18:00 < jrandom> cool legion +18:00 <+legion> really? It's been around for awhile +18:00 <+fox> <Romster> nice i'd like to check that out :) +18:00 <@cervantes> think someone ported baffled's script... can't remember who/when +18:00 <+fox> <Romster> i'm learning python +18:00 < jrandom> ah ok cervantes +18:00 <+fox> <Romster> the hard way by examples and the manual :) +18:00 < jrandom> yeah, i'm lazy, i just use polecat.i2p/i2psurvey/ and orion.i2p/ :) +18:01 < jrandom> (no need for me to spider) +18:01 <+legion> if someone would care to work with me on it, I'd really like to get the code fixed and working with either python 2.3 or 2.4 +18:01 <+fox> <Romster> i have 2.4 installed here +18:01 <+Ragnarok> I may have a look at it. Got link? +18:01 <+fox> <Romster> actually think it's 2.4.1 +18:02 <+legion> right now it has no py2exe compatibility and half of it works with each version, which means anyone running it needs to have both installed. +18:02 * jnymo_ would love to see an orion.i2p/I2PDirectory hybrid.. info, catagories, stats.. butter +18:02 <+legion> I'll archive it after the meeting and post a link to the forums +18:03 <+Ragnarok> ok +18:03 < jrandom> legion: hmm, do you see lots of people needing to run that though? I mean, only a few people need to spider +18:03 <+fox> <Romster> both eck, might be a bit much for me to translate to the newer dunno untill i look at the code +18:03 < jrandom> (not that there's anything wrong with making it easy for those few people, that is :) +18:04 <+fox> <Romster> cold be disected and used todo other things too? +18:04 <+legion> Well thing is I can see where there could be some uses for everyone that runs i2p. +18:04 <+fox> <Romster> could* +18:04 < jrandom> hmm, I'm not so sure, could you explain how? +18:04 < jrandom> I mean, I don't want everyone to essentially DDoS every eepsite +18:05 <+legion> One of which would be a dynamic bookmarks page, that is auto generated every 12-24 hours or so. +18:05 < jrandom> ah, that is trivial in syndie (actually one of the main features - 'new blogs') +18:05 < jrandom> ((but of course, syndie doesn't have a great ui for that yet)) +18:06 <+fox> <Romster> actually would only need a few to spider and throw it into a torrent/dht like database and sync that between nodes +18:06 < jrandom> right Romster (though that torrent/dht-like database to sync, or "syndi"cate, could be syndie ;) +18:06 <+fox> <Romster> could even be a hidden way to learn more i2p nodes and services +18:07 <+fox> <Romster> yeah or syndie +18:07 < jrandom> ok, anyone else have anything for the meeting? the curry is getting cold ;) +18:08 <+fox> <Romster> if syndie is going tobe that great one could store static pages to cashe and the same with images +18:08 <+fox> <reliver> bon appetit, jrandom :-) +18:08 < jrandom> exactly romster, you can do that now +18:09 < jrandom> ok, if there's nothing else... +18:09 * jrandom winds up +18:09 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/153.rst b/i2p2www/meetings/logs/153.rst new file mode 100644 index 00000000..9777c067 --- /dev/null +++ b/i2p2www/meetings/logs/153.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 25, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/154.log b/i2p2www/meetings/logs/154.log new file mode 100644 index 00000000..ebeef12c --- /dev/null +++ b/i2p2www/meetings/logs/154.log @@ -0,0 +1,176 @@ +15:04 < jrandom> 0) hi +15:04 < jrandom> 1) 0.6.1.4 and net status +15:04 < jrandom> 2) boostraps, predecessors, global passive adversaries, and CBR +15:05 < jrandom> 3) i2phex 0.1.1.34 +15:05 < jrandom> 4) voi2p app +15:05 < jrandom> 5) syndie and sucker +15:05 < jrandom> 6) ??? +15:05 < jrandom> 0) hi +15:05 * jrandom waves +15:05 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-November/001186.html +15:05 < jrandom> (lets see if this cat will let me use both hands to type...) +15:06 < jrandom> ooh, looks like we're a few minutes early (damn clock skew), but maybe this'll make up for being a few minutes late before ;) +15:07 < jrandom> anyway, jumping into 1) 0.6.1.4 and net status +15:08 < jrandom> I don't have much to add beyond whats in the status notes +15:08 * cervantes is waiting till the correct time to say hi +15:08 < jrandom> heh +15:09 < jrandom> you've got 19 seconds, acording to timeanddate.com :) +15:09 <@cervantes> hi +15:09 < jrandom> ;) ok, anyway, anyone have any comments/concerns on 0.6.1.4? from what i can see, its gone prety well +15:10 <+Complication> Counted 747.6 routers today :P +15:10 < jrandom> yeah, we've had a higher churn than usual lately +15:10 < jrandom> still getting a bunch of referrers in from that digg / gotroot article +15:10 <+Complication> And one trick to "knowing" more peers is simply restarting less often :) +15:10 < jrandom> heh true enough +15:10 <@cervantes> *cough*sourceforge*cough* +15:11 <+polecat> I've had some trouble with number of participating tunnels dropping abruptly now and again. Might be that darn NAT thing. +15:11 * jrandom cringes. have you had many referrers from sf cervantes? +15:11 <+Complication> cervantes: you mean *that* SourceForge page? :eek: +15:11 * cervantes doesn't log referrers +15:11 < jrandom> hmm polecat, could be a problem with your nat, but dropping the # of participating tunnels isn't really a bad thing - it /should/ do that +15:11 < jrandom> ah ok cervantes +15:12 <+polecat> Really? I thought lots of participating tunnels was good. +15:12 <+Complication> polecat: mine used to drop them rapidly when it exceeded practically usable bandwidth +15:12 <@cervantes> I make a point of only logging the minimum required to debug forum issues ;-) +15:12 <@cervantes> since folk seem touchy on the subject +15:12 <@cervantes> I've noticed... +15:13 < jrandom> polecat: sure, but the # should drop if your machine gets loaded or otherwise acts funky +15:13 < jrandom> reasonable enough cervantes +15:13 * jrandom logs everyone's mother's maiden name, to remind people not to trust anyone ;) +15:14 < jrandom> (or do I? you'll never know ;) +15:15 < jrandom> polecat: is your nat just randomly restarting, or losing its ip address, or something else? +15:15 <@cervantes> yeah I might change my mind on that issue....it's way too much fun seeing where everyone follows links from :P +15:16 < jrandom> its how i found the got-root and digg articles :) +15:16 < dust> i've noticed better network throughput lately, or it it just me imagining things again? +15:17 < jrandom> it should be better, especially for short lived connections (e.g. http responses) +15:18 < jrandom> otoh, its not as much of an improvement as i had hoped, so there's still work to be done on that front +15:18 < dust> e.g. i2phex pretty much takes any limit i give it if i give it enough parallel transfers +15:18 < jrandom> nice +15:20 < dust> per-tunnel seems limited <~10k/s +15:20 < dust> or per-transfer +15:20 <+polecat> Okay, my machine does get loaded now and again. +15:21 <@cervantes> have any of the folk on bandwidth restricted connections noticed improvement? +15:22 < jrandom> hmm right, 10KBps per stream seems ballpark to what i'm seeing as well +15:22 < jrandom> cervantes: i think we scared 'em all away (but if anyone with a modem or Really Shitty Connection wants to give it a try and report back, it'd be appreciated :) +15:23 < jrandom> ok, if there's nothing else on 1), lets move on to 2) boostraps, predecessors, global passive adversaries, and CBR +15:23 < jrandom> there's been lots of discussion on this fron over the mailing list (october had more posts than any other month since i2p started!) +15:24 < defnax> did anywere looked eepsites.i2p? +15:24 < jrandom> beyond whats in the status notes, i'm not sure what i have to add at the moment. anyone have any questions/comments/concerns? +15:24 <@cervantes> I think you've successfully generated full tunnel CBR by maintaining a constant level of i2plist mails +15:24 < jrandom> heh cervantes +15:24 < jrandom> defnax: yeah, it looks neat, a nice database growing there +15:25 < jrandom> same with tino.i2p +15:25 < defnax> but i dont like it +15:25 <+polecat> Hey, I'm on a bandwidth restricted connection! i2p gets 10K/s up and 32K/s down. :) +15:26 < defnax> www.eepsites.com then can all normal users on internet search for i2p sites +15:26 < defnax> and mpaa or riaa can browse what sites avaible and +15:26 < jrandom> so? +15:26 < jrandom> mpaa/riaa/etc can just run i2p if they want to see whats on i2p +15:26 < jrandom> w3wt polecat +15:27 < jrandom> (jesus, some sick search queries @ eepsites.com...) +15:27 < defnax> thats not good for anonnymity +15:27 < defnax> then all users now where can find torrents on I2P eepsites +15:27 < jrandom> defnax: same with tino.i2p +15:27 <@cervantes> I like the faux google ads on eepsites.i2p.... but anyway, digression +15:27 < jrandom> defnax: thats not good for /secrecy/. thats different from anonymity. +15:27 < jrandom> people hosting public eepsites should expect that anyone can view their eepsites +15:28 < jrandom> if they want to restrict who can access it, they should do so +15:28 < jrandom> yeah definitely cervantes :) +15:28 <+polecat> Anyone who wants a private eepsite, just don't give it a name in hosts.txt. Problem solved! +15:28 < defnax> but normal internet users must dont know which eepsites is avaible! +15:28 < jrandom> polecat: thats not entirely sufficient +15:29 <+polecat> Really? +15:29 < jrandom> i'm sorry, perhaps I misunderstand defnax. why shouldn't people know what eepsites are available? +15:29 < defnax> i know it then not listend in a search enigine when dont make eespite public +15:29 <+polecat> I thought it was a brute force sweep through the base64 keyspace to find eepsites... +15:29 < jrandom> polecat: right, someone can harvest the netDb +15:29 < defnax> i think this person dont need I2P +15:29 < jrandom> well, harvesting for leaseSets is substantially more work than harvesting for routers... +15:30 < jrandom> defnax: I'm sorry, I don't understand +15:30 < jrandom> eepsites.com is a public interface to a search engine across public eepsites. nothing private is being revealed +15:30 <@cervantes> lol @ last 5 searches +15:30 <+Complication> Yep, the "last searches" box suggests someone (ironically someone who is probably non-anonymous) is a tiny bit sick. +15:30 <+Complication> Ah, whatever. +15:30 < defnax> i mean he dont need I2P ! he tells on public IP on which eespites are torrents or other things avaible! +15:31 < defnax> on I2P is ok , but not on normal internet +15:31 < jrandom> defnax: sure, that person running eepsites.com does not themselves require i2p. you can find out their home address, phone number, etc. +15:31 < jrandom> but, on the other hand, same goes for forum.i2p. +15:31 < jrandom> (and to some extent, www.i2p, though that doesn't give you /my/ info ;) +15:32 < jrandom> some sites are public. thats fine. thats neat. +15:32 <+fox> <jme___> defnax, what attacks is possible thanks to this site, which isnt without this site ? +15:32 <@cervantes> Complication: snigger +15:32 < jrandom> they're offering a potentially useful service to people who may want to try out i2p before installing +15:33 < defnax> ok any news from I2Psnark? +15:33 <+Complication> cervantes: yeah, nothing like good old irony :) +15:33 < defnax> i will become before 0.6.2 a webinterface/gui? +15:33 <@cervantes> defnax: there's been an i2p inproxy for several months +15:33 < jrandom> defnax: nope, but I suppose we should jump forward in the agenda before we hit 6) ??? +15:33 < jrandom> ok, is there anything else on 2) boostraps, predecessors, global passive adversaries, and CBR? +15:34 < jrandom> or shall we move on to 3) I2Phex 0.1.1.34 +15:34 < jrandom> [consider us moved] +15:35 < jrandom> ok, those not yet on 0.1.1.34 should upgrade, as there's some important stuff in the release. Those already on 0.1.1.34 who want to help test out some not-yet-released improvements, there's further work in CVS, so if you try that out and run into troubles, please post on the forum +15:36 < jrandom> in other news, I've heard some good progress on the gwebcache front as well, but no word on its integration with i2phex yet +15:36 < jrandom> redzara: any word on the merge? +15:37 <+Complication> The post .34 cvs improvements seem to make the GUI *much* more responsive. +15:38 < jrandom> cool, yeah, I couldn't handle the <= ..34 responsiveness, but i'm not sure if the fixes are entirely regression-free, since i don't really understand all the code. but it /seems/ ok :) +15:42 <+redzara> jrandom : sorry, but we have just change hour time in France to Winter Time and work is near finished for I2phex, I've just to track 2 or 3 bugs +15:43 < jrandom> ah cool! +15:43 < jrandom> no rush, just wondering +15:44 <+redzara> and maybe I've to get lastest I??phex code to see if GregorK's mod apply to lastest phex code ?!? +15:45 < jrandom> yeah, disabling the remote request functionality will be required, but it was a trivial two line fix (comment out MAGMA and URI requests). +15:45 < jrandom> same for the latest synchronization issue (remove unnecessary locks on network operations) +15:46 <+fox> <jme___> I??phex <- interesting how typo can reveal location too :) +15:46 < jrandom> not as much as "in France" does ;) +15:46 <+redzara> this is already done in my code +15:46 <@cervantes> hehe +15:46 < jrandom> (but thats another bug thats not yet fixed... the irc charset stuff) +15:46 < jrandom> ok cool redzara +15:47 <+redzara> jme___ : I don't search to hide my location, you konw :-) +15:47 <+redzara> so nothing more to say about i2phex for me +15:47 <+fox> <jme___> redzara, ok :) +15:48 < jrandom> ok great, thanks for the update +15:48 < jrandom> anyone else have anything on i2phex, or shall we move on to 4) voi2p app? +15:49 <+redzara> consider we are moving :) +15:49 < jrandom> for 4), I'm not sure if I've got anything to add beyond whats in the mail, and it seems aum has disconnected, so we'll probably have to wait for an update at a later time +15:49 < jrandom> (unless someone else has something to discuss for 4)?) +15:50 < jrandom> if not, consider us moved to 5) syndie and sucker +15:50 < jrandom> dust: wanna give us the word? +15:51 <@cervantes> so is syndie good at sucking now? +15:51 < jrandom> yes *cough* +15:51 < dust> heh +15:52 < dust> well, the note says pretty much it +15:52 < dust> there are still stuff to do +15:53 < dust> word on the testing and reporting of bugs +15:54 < jrandom> ok great, do you know offhand what the story with rome-0.8 is? worth waiting for a pending release, or should we grab a cvs build and upgrade it later? +15:55 <+fox> <brutus> oi, how about the auto ping-pongin' ircProxy, any progrssthat? +15:55 < jrandom> no progress i know of +15:55 <+fox> <brutus> (ups, sry) +15:55 <+polecat> voi2p, make a mp3 of your voice and i2p bittorrent it. +15:56 < dust> no, dunno the eta on next rome +15:56 < dust> i couldn't get to the cvs +15:57 < dust> (i don't remember why) +15:57 < jrandom> ah 'k, well, we don't need it yet, it'd just be neat. a later date then +15:58 < jrandom> ok, anyone have anyhing else on 5)? or shall we move on to 6) ??? +15:59 < jrandom> [consider us moved] +15:59 <@cervantes> brutus: I don't beleive anything has been done concerning that +16:00 < dust> should it be done? +16:01 <+fox> <brutus> oki, yeah, i guess it's pretty low priority as well +16:01 <+polecat> I still want to know how we could make i2p, and anonymity techniques in general, more accessible in poor or dangerous places. +16:01 < jrandom> polecat: by getting someone with a dialup connection to help test ;) +16:01 <@cervantes> free rifle with every installation? +16:02 < jrandom> polecat: we're definitely working on that, but we have so, so much more to do first. +16:02 < jrandom> dust: the irc thing? might be worthwhile, but sucker improvements are probably more important +16:02 < jrandom> (imho) +16:03 <@cervantes> (somewhat biases opinion ;-) +16:03 <@cervantes> *biased +16:03 < jrandom> true that, but i think my bias is Right :) +16:04 * cervantes notes the capital lettering ;-) +16:05 * Complication looks at the phone socket, and wonders if anything good can come of such <things> :D +16:05 <+Complication> Then again, if DSL travels over it, it cannot be inherently evil. :D +16:05 <+polecat> No... not Things! +16:05 <@cervantes> Complication: you can also use it to call people.... +16:06 < jrandom> ok, anyone have anything else for 6) ??? +16:07 * cervantes wasn't sure we had anything for ??? in the first place +16:07 < jrandom> in that case... +16:07 * jrandom winds up +16:08 * jrandom *bafs* the meeting closed diff --git a/i2p2www/meetings/logs/154.rst b/i2p2www/meetings/logs/154.rst new file mode 100644 index 00000000..a2cca3d8 --- /dev/null +++ b/i2p2www/meetings/logs/154.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 1, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/155.log b/i2p2www/meetings/logs/155.log new file mode 100644 index 00000000..16227451 --- /dev/null +++ b/i2p2www/meetings/logs/155.log @@ -0,0 +1,60 @@ +15:21 < jrandom> 0) hi +15:21 < jrandom> 1) Net status / short term roadmap +15:21 < jrandom> 2) I2Phex +15:21 < jrandom> 3) I2P-Rufus +15:21 < jrandom> 4) I2PSnarkGUI +15:21 < jrandom> 5) Syndie +15:22 < jrandom> 6) ??? +15:22 < jrandom> 0) hi +15:22 * jrandom waves +15:22 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2005-November/001206.html +15:22 * bar mumbles greetings from behind his/her false(?) beard +15:23 < jrandom> ok, jumping into 1) Net status / short term roadmap +15:23 < jrandom> Not much to say beyond whats in the mail - hopefully a new release later this week, or this weekend +15:24 < jrandom> there are some new optimizations in cvs which should help improve reliability, and its worked pretty well in the tests i've done, but it probably won't have much of an impact until it gets widespread deployment +15:25 < jrandom> I also haven't picked an arbitrary throughput level I want to reach before continuing on to 0.6.2, though my gut instinct tells me that optimizations should continue until I can justify the choke points by per-router hop delays +15:26 < jrandom> right now, however, that isn't our choke point, so there's still work to be done. +15:26 < jrandom> I don't have much more to add on that front - anyone have any questions/comments/concerns? +15:28 < jrandom> ok, if not, moving on to 2) I2Phex +15:28 < jrandom> I don't have much more to add here beyond whats been said in the email. There have been a bunch of discussions on the forum too, though, so swing by there for more news and ranting +15:31 < jrandom> ok, if not, jumping on over to 3) I2P-Rufus +15:31 < jrandom> this bullet point was really just me repeating a rumor, but we'll see how things go +15:32 < jrandom> Rawn / defnax: do you have anything to add? +15:35 < tealc_> whats i2p-rufus ? +15:35 < jrandom> a port of the rufus bittorrent client for I2P (http://rufus.sourceforge.net/) +15:36 < jrandom> ok, if there's nothing else, we can jump to another quick rumor reportage - 4) I2PSnarkGUI +15:37 < jrandom> I don't have much to add to this beyond saying "hey, cool" :) +15:38 <+bar> yeah, looks nice +15:38 <@frosk> snark is Y.A. BT client? +15:38 < jrandom> yeah, but snark is a bittorrent client bundled with I2P :) +15:38 <@frosk> oh yeah, right :) +15:38 < jrandom> (currently a command line tool, but multitorrent and web interface is on the way, though not imminent) +15:39 <+fox> <ZipTie> who was doing the work for the rarest-first fetching strategy for snark? did that ever get done? +15:39 < jrandom> yeah, Ragnarok implemented that +15:39 < jrandom> its in the current I2PSnark +15:39 <+fox> <ZipTie> cool +15:40 < jrandom> aye, quite +15:41 <+fox> <ZipTie> is i2p-bt going to be decomissioned then in favor of either rufus or snark? +15:41 < jrandom> thats for users to decide +15:42 <+fox> <ZipTie> or maintainability :) +15:42 < jrandom> personally, I think if snark gets a web interface, integrated with the router console, multitorrent capabilities, and offers equivilant performance as the others, it'll be in good shape +15:43 < jrandom> but really, what you mention is the key - who does the maintenance and development is the driving force +15:43 * jrandom does not maintain python apps +15:44 < jrandom> ok, if there's nothing else on 4, lets move on to 5) Syndie +15:45 < jrandom> I've been doing some usability research into how best to proceed, and I think we've got a pretty viable UI on the way, but if you've got an opinion, post it up on syndie or the forum and we can hopefully take it into consideration +15:46 < tealc_> ahh, i thought i2phex was java.. the stuff on the forums offers .exe installers and .exe's in zips +15:47 < jrandom> i2phex is java +15:47 < jrandom> and the .exe works with any platform that java works on +15:47 < jrandom> java -jar i2phex.exe +15:47 < jrandom> (yes, really) +15:49 < jrandom> (cough) +15:49 < jrandom> dust: anything to add re: syndie stuff? +15:50 < dust> nope +15:50 < jrandom> ok cool. unless anyone else has anything on it, lets jump to ol' faithful: 6) ??? +15:50 < jrandom> anyone have anything else they want to bring up for the meeting? +15:53 <+fox> <reliver> is the paella ready ? ;-) +15:53 * jrandom grabs a spork +15:54 < jrandom> (on that note...) +15:54 <+fox> <reliver> and the cat still smells like cats ;?) +15:54 * jrandom windos up +15:54 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/155.rst b/i2p2www/meetings/logs/155.rst new file mode 100644 index 00000000..779bda4c --- /dev/null +++ b/i2p2www/meetings/logs/155.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 8, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/156.log b/i2p2www/meetings/logs/156.log new file mode 100644 index 00000000..4bb8fa3d --- /dev/null +++ b/i2p2www/meetings/logs/156.log @@ -0,0 +1,345 @@ +15:15 < jrandom> 0) hi +15:15 < jrandom> 1) Net status / 0.6.1.5 +15:15 < jrandom> 2) Syndie updates +15:15 < jrandom> 3) I2Phex +15:15 < jrandom> 4) I2P-Rufus +15:15 < jrandom> 5) Issue tracker +15:15 < jrandom> 6) Dynamic Keys +15:15 < jrandom> 7) ??? +15:15 < jrandom> 0) hi +15:15 * jrandom waves +15:16 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-November/001210.html +15:17 <+bar> yalla! *fires some rounds into the air* +15:17 * jrandom ducks and covers, diving into 1) Net status / 0.6.1.5 +15:18 < jrandom> as mentioned in the mail, there's been a lot of progress, and there should be a new release later tonight +15:18 * jrandom would have released it earlier, but I slept late and didn't want everyone upgrading /during/ the meeting :) +15:20 < jrandom> anyone have any questions/comments/concerns re: 1) net status / 0.6.1.5? +15:20 <+fox> <ailouros> is "please keep up the good work" an acceptable comment? +15:20 < jrandom> :) thanks +15:22 < jrandom> I've been pretty happy with the stability as of late. hopefully the next release will improve throughput beyond 4-8KBps/stream. I've done plenty of local testing, but we need to see it out in the wild +15:22 < tethra> i second ailouros's comment, and furthermore, propose a toast: +15:22 < jrandom> we've also had some more positive reports from users on dialup connections +15:22 < tethra> to jrandom, and i2p! woot! +15:22 < tethra> <3 +15:23 < jrandom> w3wt. ok, if there's nothing else, lets jump on over to 2) Syndie updates +15:24 < jrandom> lots of progress on this front, but perhaps it'll be best to discuss it after the release when people can try it for themselves +15:25 < jrandom> hopefully the info up @ http://syndiemedia.i2p.net/about.html (the first link) can explain why you should bother trying it out :) +15:25 <+fox> <ailouros> oh come on, first you don't release it, then you say "try it first"... this is just teasing! :D +15:25 < jrandom> :) +15:26 < jrandom> ok ok, so lets just jump ahead to 3) I2Phex then, so y'all can post up your thoughts about syndie to syndie itself after you upgrade ;) +15:27 < jrandom> there's going to be an announcement for I2Phex 0.1.1.36 later tonight +15:28 < jrandom> the only change is the fix for the annoying "Please insert a disk" popup +15:28 < tethra> that means i can take the disk out the drive without it screaming at me, then? ;) +15:28 < jrandom> heh yes +15:28 < tethra> :D +15:30 < jrandom> ok, if there's nothing more on 3) I2Phex, lets jump on over to 4) I2P-Rufus +15:30 < tethra> what are the plans for i2phex, while we're on the subject? +15:30 < jrandom> ah +15:30 < jrandom> there's a set of feature requests posted to the forum +15:31 < jrandom> I haven't heard anything from redzara about the code merge with Phex, but Gregor is still working on abstracting the networking stuff so we can more easily keep in sync +15:32 < jrandom> generally, the app seems functional, though gwebcache support would be Really Good, so that I2Phex could work out of the box without needing to fetch any files or keys +15:32 < jrandom> I don't know anyone working on getting gwebcache support (back) into I2Phex, but if someone knows java, that'd be Really Useful +15:33 < tethra> cool. +15:33 <+fox> <reliver> _007pig perhaps ? +15:33 <+fox> <ailouros> sorry if I ask, but wasn't gnutella network the one that flooded itself to death some time ago? +15:33 < tethra> the new guys do tend to be a bit confused about it at first +15:33 <+fox> <reliver> you did not take him up on his offer for help, yesterday, jrandom +15:33 < jrandom> _007pig was looking into translation work, but anyone would be great. Phex itself has gwebcache support, but sirup disabled it +15:34 < jrandom> ailouros: gnutella is still around, but yeah, its not ideal. +15:34 < tethra> is anyone looking into perhaps changing the protocol i2phex uses to something else? +15:35 < jrandom> I'm hesitant to demand people work on specific projects, so I instead suggest a few different areas that someone could explore +15:35 < jrandom> tethra: no one that I know of +15:35 <+fox> <ailouros> well, I think I'd rather see Localhost (azureus modification) on i2p then +15:36 < tethra> surely bittorrent is more awkward than gnutella? +15:36 < tethra> in terms of seeding and such +15:36 < jrandom> ailouros: whatever people implement and maintain is good :) +15:36 <+fox> <ailouros> I don't know, I didn't use gnutella since... 6 years I think +15:37 < anti> surely it is more efficient and better test of true scalability? +15:37 <+fox> <ailouros> jrandom yeah that's a good metric :D +15:37 < jrandom> i2phex works pretty well, I've transferred lots of data through it, and found some neat content +15:37 <@cervantes> (pony pr0n) +15:37 <+fox> <ailouros> lol +15:37 < tethra> hahah +15:37 < jrandom> there may be better ways to do things, but something that works is better than something that doesn't exist +15:37 < tethra> cervantes++ +15:37 < tethra> ;) +15:38 < tethra> truer words have never been spoken. +15:39 < anti> good point +15:39 <@cervantes> uhoh... jr has taken offense and gone early to dinner +15:39 <@cervantes> (sorry) +15:39 < anti> no, he's probably searching for that (mythical) pony pr0n. ;) +15:40 < jrandom> *cough* ;) +15:40 < tethra> lol +15:40 < tethra> heheh ;) +15:40 < jrandom> ok, if there's nothing else on 3), lets move on to 4) I2P-Rufus +15:40 <+fox> <reliver> i want flying pony pr0n :-) +15:40 < jrandom> Rawn / defnax: anything to add to what was posted on the forum? +15:41 <@cervantes> looks like some good progress is being made +15:41 < jrandom> aye +15:45 < jrandom> ok, if there's nothing on that, lets jump on to 5) issue tracker +15:45 < jrandom> the forum is a bit heavyweight for managing bugs and feature requests, and bugzilla is a bit of a beast... +15:46 <@frosk> isn't there a bugzilla already somewhere? +15:46 < jrandom> i've posted up some general requirements, and cervantes has come up with one workable solution +15:46 < jrandom> nah, the bugzilla was on the old host (@johnscompanies) before we migrated to sago +15:46 <+fox> <ailouros> hot about NNTP? better than forums, usually threaded... +15:46 <+fox> <reliver> strange that bugzilla is so lacking, considering the huge open source community using it ... +15:46 <+fox> <ailouros> how* +15:46 <@frosk> ah ok +15:47 < jrandom> nntp has potential, but there are some benefits over that by using syndie (simple filtering by tag): http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004& +15:48 < jrandom> but nntp does have the benefits of having decades of battle testing +15:48 <+fox> <ailouros> NNTP reader filter by keyword (the [] tags)? :D +15:49 <@modulus> perhaps not so much testing of late? +15:49 <+fox> <reliver> including spamming and flaming ... +15:49 < jrandom> we'd want something web accessible though, since most people don't use nntp readers +15:49 <+fox> <ailouros> I say Thunderbird is good in that sense, and you can share the enigmail between i2mail and i2nntp +15:49 <@modulus> maybe a web accessible nntp reader? +15:49 <+fox> <reliver> gateways are common +15:49 < jrandom> hmm modulus? +15:50 <@modulus> well, usenet is not so much used anymore i think +15:50 < jrandom> right, so we'd have to have an nntp server and a gateway with filtering support +15:50 <@frosk> i like cervantes' idea though +15:50 <+fox> <ailouros> (and I also say the reason people don't use NNTP readers is because forums are so much prettier and so much heavier) +15:50 <@modulus> hmm, gateway with filtering support? what are you guys talking about, maybe it helps knowing. :-) +15:51 <@modulus> imo forums suck, i hate fucking forums, they're unusable ;-( +15:51 <+fox> <ailouros> LOL I guess he wants the access from the InterNEt +15:51 <+fox> * ailouros agrees with modulus +15:51 <@frosk> modulus: so very true +15:51 < jrandom> heh modulus ;) we're discussing http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003& +15:51 <+fox> <ailouros> aieee the megabyte long URI +15:52 <@modulus> what I love about syndie URLs is how memorable and simple they are to type +15:52 < jrandom> I do still like http://syndiemedia.i2p.net:8000/threads.jsp?post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004& +15:52 < jrandom> heh +15:52 < jrandom> well, go to http://syndiemedia.i2p.net/threads.jsp then and click on the "Issue tracking software" link :) +15:53 <@frosk> bug reporting right from your router console +15:53 <@modulus> hmm, bug tracking. +15:53 < jrandom> using syndie would give us 1) integration with every I2P user's environment 2) trivial filtering 3) threading 4) spam handling (via ignore/favorites) 5) syndie a workout :) +15:54 <+fox> <reliver> sounds great :-) +15:54 <+fox> <ailouros> it is +15:54 < jrandom> aye that is a really good feature frosk... we could even have specialized html forms to post to /syndie/post.jsp +15:54 <+fox> <ailouros> and by the way, wasn't there talk about basing syndie on NNTP? :D :D :D +15:54 <@modulus> hmm, how about the Debian bug tools? they're nice i think, the mailbug +15:54 < anti-> can't argue with what already works! +15:55 <@cervantes> I think you should do it purely from a techdemo perspective +15:55 < jrandom> ailouros: using NNTP to distribute syndie posts, yeah. right now we just use ad-hoc syndication, but further enhancements would be great +15:56 <@cervantes> no better way to demonstrate syndie than with some real world use cases +15:56 < jrandom> true enough +15:56 < jrandom> ok, perhaps we can plan on getting that out in the 0.6.1.6 release +15:56 <+fox> <reliver> what i don't like about forum is they are low entry cost +15:57 <+fox> <reliver> so lots of distractions filling them. +15:57 <@modulus> i don't know, this syndie thing ... i much do not like yet, but maybe i'll get used to it. +15:57 <+fox> <reliver> and you can only work with them online +15:57 < jrandom> modulus: have you read the post linked to from http://syndiemedia.i2p.net/about.html ? +15:57 <@modulus> reliver: high-entry is bad for bug reports though, people are making you a big favour by bothering to report in a sense. +15:57 <+fox> <ailouros> they are not low entry cost: bandwidth comes to mind. They are high noise levels, so you can use [font=54]HELLO WORLD![/font] and annoy a huge number of people in no time +15:57 < jrandom> agreed modulus +15:58 <+fox> <ailouros> oh yeah and you have to be online indeed +15:58 < jrandom> heh ailouros, thats something we need to deal with in Syndie anyway :) +15:58 <@modulus> hmm, probably not, jr, let me check +15:58 <+fox> <ailouros> well, with syndie you can blacklist the users and you're pretty much set +15:58 < jrandom> well, with syndie you can create your bug reports offline, then syndicate them up to a remote archive later when you are :) +15:58 < jrandom> exactly ailouros, with one click in the new release too +15:59 <+fox> <ailouros> with forums either you hope for an admin to come and kill'em, or you keep them +15:59 < anti-> it's more uucp than nntp :) +15:59 <@modulus> hmm, which post in particular linked from there? +15:59 < jrandom> lol *exactly* anti +15:59 < jrandom> modulus: the first link "in syndie itself" +15:59 * cervantes likes the killing option +16:00 <@modulus> bah, uucp == nntp for all practical purposes :-) +16:00 < jrandom> anti-: thats actually the point - as people build newer and better transport mechanisms (uucp, nntp, usenetdht, etc), the content can flow seamlessly +16:00 <+fox> <ailouros> this all reminds me of plan9 +16:01 <+fox> <reliver> i2p may be special, but usually bug reporting systems used as firewalls against users ... +16:01 < jrandom> used as firewalls against users? +16:01 <+fox> <reliver> i2p may be special, but usually bug reporting systems are used as firewalls against users ... +16:01 <+fox> <reliver> yes. +16:01 < jrandom> I want it to be really, really easy for people to report bugs +16:01 <+fox> <reliver> mozilla, thunderbird, ubuntu are just examples +16:02 <+fox> <reliver> ok, great :-) +16:02 < jrandom> mozilla/etc have that integrated "feedback agent" for submitting bug reports automatically +16:02 <+fox> <reliver> they don't read those bug reports +16:02 < jrandom> heh +16:02 <@modulus> hmm, that intro is ok, only problem is i just don't like the interface at all, i prefer doing mailish things through the folder metaphor rather than the web-with-sithloads-of-links-on-it method +16:02 <@modulus> but that's just me +16:02 < jrandom> modulus: perhaps the rss export would best serve your needs then? +16:02 <+fox> <ailouros> I agree with modulus (anyone guessed? :D ) +16:02 <@cervantes> having to use pastebin to show console errors is a bit of a put-off for some folks +16:03 < jrandom> or we can get susimail integration, as cervantes suggested, to send out reports +16:03 < jrandom> (or to post to syndie) +16:03 <@modulus> it is possible, jrandom, i'll look into it. maybe i need an RSS-to-NNTP or RSS-to-POP?/IMAP converter, i'll think on it. +16:05 <@cervantes> modulus: I'll be curious to find out what you think of the new i2ptunnel interface come the next i2p release +16:05 <@cervantes> whether it's better or worse for you in terms of usability +16:05 <@cervantes> (but I guess you just normally edit the config files?) +16:07 < jrandom> ooh yeah shit, I forgot so much stuff in the status notes... +16:08 <+fox> <ailouros> then let's hurry ahead and skip to the next point in line... that was point number C, right? +16:08 * jrandom thinks it really kicks ass, but we'll get some more feedback as people try it out +16:08 <@modulus> cervantes: is that curious as in "you're going to kill yourself with a small knife in your arse as a better alternative to using it" or on the contrary? :-) +16:08 < jrandom> yeah, jumping to 6), anyone have any thoughts on the Dynamic Keys proposal? +16:09 <@modulus> cervantes: usually use the interface actually, though now i know the config files are editable ... :-) +16:09 <+fox> <ailouros> yeah, I'm pretty certain it will cause the skyrocket in the number of supposed known routers +16:09 <@cervantes> *damn* :) +16:10 <@modulus> this dynamic key is the idea that routers get a new key upon new IP, right? +16:10 <@cervantes> modulus: well, just if it's even worth bothering with WAI bullshit +16:10 < jrandom> heh thats true ailouros +16:10 <@cervantes> anyway...I digress +16:10 < jrandom> right modulus +16:11 <@modulus> well, perhaps it isn't bad that the known peers are actually guesswork, more so than now. +16:11 <+Complication> Well, the only thing I can figure out about Dynamic Keys.. seems that one shouldn't change keys needlessly (or it screws reliability performance tracking). +16:11 <+Complication> But when IP changes (rare enough?) it might not hurt. +16:11 < jrandom> right Complication. it isn't something we'd want by default. most people will *not* want it +16:12 < anti-> i'm not sure of the positive impact of the proposals. +16:12 < jrandom> it won't offer much of an improvement for anonymity either, and no improvement at all against a powerful adversary, but it might help against weak adversaries +16:12 <+fox> <ailouros> wouldn't it also give away which nodes are fixed ip and which aren't? +16:13 * cervantes has had the same key for nearly 2 years :) +16:13 <+polecat> Well at least I can get here. +16:13 < jrandom> ailouros: it would not be used by most people. only a very, very small minority would want to use it +16:13 <+fox> <ailouros> so basically more churn for a bit of protection against weak adversaries? +16:13 < jrandom> right ailouros +16:13 <+fox> <ailouros> oh ok +16:14 <+fox> <ailouros> is there a way to measure the performance hit of that feature once in the wild? +16:14 <@modulus> it would, i think, help against a node-dest intersection attack? +16:14 <+polecat> I still wonder why I keep switching between OK and OK(NAT), puzzling... +16:14 < jrandom> modulus: only for a weak adversary +16:14 <+fox> <ailouros> polecat don't worry, I keep switching between 15h uptime and 0h uptime :| +16:14 < jrandom> ailouros: not sure, though stats.i2p suggests that we can handle the churn +16:15 < jrandom> polecat: hmm, means there's likely some filtering going on +16:15 <@modulus> imo the node-dest intersection attack is the most serious likely feasible attack atm? besides the fact we are too few, i mean. +16:15 <@modulus> so, i think anything which helps on that line is probably a good idea +16:16 <+polecat> I can send UDP packets right over my router at that port, no problem from remote shells. No clue, perhaps i2p detects the NAT, and mistakenly thinks it isn't forwarded. +16:16 <+fox> <ailouros> I agree with the "good idea" as long as the churn doesn't cause a severe performance hit +16:16 < anti-> when the network is bigger, there will be plenty of churn anyway... +16:17 < anti-> *points out the obvious DoS attack involving constantly changing keys every few minutes +16:17 < anti-> what impact would that have? +16:17 <+fox> <ailouros> dos against who? :D +16:18 < jrandom> eh, new peers go in the "not failing" tier by default, and only go up to the "high capacity" or "fast" tiers after they are around for a while +16:18 < jrandom> so it won't DoS peer selection +16:18 < anti-> with a relatively strong opponent... would create an awful lot of apparently dead nodes/netdb churn? +16:18 <+Complication> anti: nobody would consider that node reliable any more +16:18 <+polecat> anti-: We have a shitlist for a reason. +16:19 < anti-> *satisfied +16:19 < jrandom> well, the netDb entries are dropped if the peer is unreachable +16:20 < anti-> then the same performance issues that were just raised about dynamic keys would apply? if the performance wouldn't be too impacted by such an attack, the performance wouldn't be affected noticeably by dynamic keys either... would it? +16:20 <+polecat> incremental trust really does help with handling late onset betrayers, I was thinking. +16:20 <+fox> <ailouros> what's a "late onset betrayer"? +16:20 <+polecat> Trust people more and more as they continue to benefit you, but never so much that they can take away more than they've given... +16:20 < anti-> join for ages, then turn judas. +16:21 < jrandom> right, peers get dropped out of the 'fast' tier quickly if they act poorly +16:21 <+Complication> I'd think it would be someone behaving like "wait until 300 participating tunnels, crash" +16:21 <+polecat> Oh, I make up phrases all the time. Yeah, Judas type betrayal, where you genuinely help someone, then betray them with the idea of cashing in at the last minute. +16:21 < anti-> oh no, the tunnels broken *rebuild* +16:21 < jrandom> the peers promoted to the 'fast' tier during that time they're dropped should then suffice +16:21 <+fox> * ailouros has fun with these incorrect bible refernces :D +16:22 < jmg> speaking of high capacity, wow im getting between 400k and 600K constantly for the router today. (but maybe all those zero hops settings im using are helping) +16:22 < jrandom> 600KBps?! +16:22 <+polecat> Hopefully during the time it takes to get to 300 participating tunnels, you'll be required to help transfer enough data it wouldn't matter if you crashed. +16:22 < jmg> yes +16:22 <+fox> <ailouros> O_O what are you connected to? +16:22 <+Complication> Such bandwidth is news to me :) +16:22 < jrandom> damn, thats fast enough to start running into our bloom filters +16:22 < anti-> ailouros: rude question to anony researchers ;) +16:23 <+polecat> It's gotta be 600KBpm or ph. +16:23 <+fox> <ailouros> sorry anti- :D but he was the first to speak +16:23 <+polecat> puh! +16:23 < jrandom> I'd love to get some stats from the oldstats.jsp page off you. but glad to hear its handling things :) +16:23 < anti-> one day i will try from i2... +16:23 < jrandom> hehe +16:24 <+fox> <ailouros> sounds cool, I2P on I2 +16:24 < jmg> jrandom: im keeping graphs, ill monitor more closely, but yes i can confirm 600kB/s sustained for 2 minutes, about 5 minutes ago +16:24 <+polecat> Has anyone tried to traverse a d-link router's firewall? I'm having no luck there whatsoever and my friend keeps forgetting to forward the port. +16:24 < jrandom> nice jmg +16:24 < anti-> polecat: do we do udp holepunching yet? i lost track +16:25 < jrandom> anti-: yes, we do, for all but symmetric NATs +16:25 < jrandom> polecat: if your friend has their model #, there are a few sites online listing what type of NAT it is +16:26 < anti-> regarding late onset betrayal... might be an issue with a powerful adversary? +16:26 < jmg> jrandom: of course bittorrent has been known to rape this connection at 4MB/s sustained, but Iv eased up on that a little lately +16:26 < anti-> 24000 nodes, so you get one crashing every 10 seconds or so? +16:26 <+polecat> symmetric NAT, as opposed to full cone? +16:26 < jrandom> nice jmg +16:26 < jrandom> hmm anti-? +16:26 < jrandom> polecat: or restricted cone +16:27 <+polecat> Wow, it can even do restricted cone that's impressive.. +16:27 < anti-> i don't think late onset betrayal would have any significant effect at all unless applied on an incredibly massive scale, at which other attacks would have more of an impact? +16:28 < jrandom> yeah I'm not too worried about it anti-... it'd cost too much, and we can route around failures anyway, so the damage would be minimal +16:28 <+Complication> Late betrayal kind of requires contributing a lot (as to get other machines relying on your machine). +16:28 <+fox> <ailouros> incredibly massive scale = you are all the netries on almost everyone else's router? +16:28 < anti-> that is exactly what anti-p2ps do now, but we do have anti-anti-p2ps now... +16:29 <+fox> <ailouros> no wait anti-p2p send trash instead of good data +16:29 <+fox> <ailouros> that's not the same +16:29 < anti-> that's just a faster way of getting shitlisted, so you would never be listed well. +16:29 < anti-> that wouldn't work against i2p at all, i think. +16:29 <@cervantes> jmg: I've had 4-5mb/s off torrents before, but never anything like 600k over I2P...have you got beefy hardware too? +16:29 <+polecat> I was more thinking independant of i2p persay. My government does a lot of late onset betrayal, though they try to keep it classified. +16:29 < anti-> but we would probably bleed them dry of bandwidth first! +16:29 < jrandom> anti-: if they're reliable for days on end, they can only attack once for less than 10 minutes +16:30 < jrandom> exactly anti- :) +16:30 <+polecat> Or in the context of online banking. +16:30 < jmg> does anyone have easy instructions on setting up the Native BigInteger library for amd64? if not ill just figure it out +16:30 < jrandom> heh polecat +16:30 < jrandom> jmg: its built into jbigi.jar, but it should build on amd64 now +16:30 < jrandom> though, I suppose this means we're now on 6.1) ??? +16:31 < jrandom> anyone have anything else to bring up? :) +16:31 < anti-> you'd need 20000 machines or something, with a rolling crash schedule, and i think the results would be disappointing; you would end up contributing far more to the network than you took away! +16:31 < jrandom> that is the hope anti- +16:31 <+fox> <ailouros> well, worst case scenario is that people must reseed +16:31 < jmg> oh thanks +16:31 <+polecat> 64 bit processor, 4mbit upload bandwidth, sounds like somebody's a lucky bastard. +16:32 < anti-> or running a normal machine at a uni... +16:32 <+fox> * ailouros looks at his uni's hardware list and frowns +16:32 < anti-> a uni that doesn't buy dell ;) +16:33 <+fox> <ailouros> I think we have a couple of dells... from 5 years ago IIRC +16:33 <+fox> <Sonium> i think this is bad: +16:33 <+fox> <Sonium> jvm 1 | java.lang.OutOfMemoryError +16:33 <+fox> <Sonium> jvm 1 | java.lang.OutOfMemoryError +16:33 <+fox> <Sonium> jvm 1 | java.lang.OutOfMemoryError +16:33 <@cervantes> polecat: 4 megabyte ;-) +16:33 < jrandom> Sonium: yeah, once it gets one OOM, it'll die fast +16:34 <+fox> <Sonium> and this too: +16:34 <+fox> <Sonium> jvm 1 | 21:21:44.484 CRIT [ Establisher] sport.udp.EstablishmentManager: Err +16:34 <+fox> <Sonium> or in the establisher +16:34 < jrandom> (subsequent OOMs are safe to ignore) +16:34 < jrandom> once it gets a single OOM, you can ignore all subsequent errors +16:34 <+fox> <ailouros> yeah but you shouldn't have the first OOM :D +16:34 < jmg> polecat: the latency out here on the russian space station in phenominal though.. +16:34 < jrandom> true ailouros +16:35 <+fox> <ailouros> oh, by the way... my router gets watchdogged quite often +16:35 < jrandom> hrm, high cpu usage? +16:35 <+fox> <ailouros> I guess it's just my unlucky installation? +16:35 <+fox> <ailouros> not that I know of, the machine is rather unloaded +16:36 <+fox> <ailouros> but I guess this is what I should expect from a buggy JVM on a somewhat bugged linux emulation layer +16:36 < jrandom> what jvm are you using, and what os? +16:36 <+fox> <Sonium> me? +16:36 <+fox> <ailouros> Sun's Java(tm) 2 Standard Edition, JRE 5.0 Update 5 on NetBSD/i386 2.0.2 +16:37 < jrandom> ahhh yeah, I have done no testing on nbsd. fbsd is fine, but I don't have any experience w/ nbsd +16:38 < jrandom> might be worth trying out gcj, perhaps we can dig into that after the meeting +16:38 <+fox> <ailouros> it works rather well, but the real fun with this is that sometimes (depending on which bit he flipped when getting off the bed -- err restarting) the netbsd files get created with 540 permission :D +16:38 <+fox> <Sonium> something really sucks here +16:38 <+fox> <Sonium> jvm 1 | # Internal Error (53414645504F494E540E4350500175), pid=3500, tid=345 +16:38 <+fox> <Sonium> 6 +16:39 <+fox> <ailouros> sorry the netDb files are created 540 +16:39 <+fox> <Sonium> I think I will reinstall this later +16:39 < jrandom> Sonium: what OS are you on? the jvm seems to be acting up +16:39 <+fox> <Sonium> winxp +16:39 < jrandom> yeah, if you're on 1.5.0_5, might be worth trying 1.4.2_09 +16:39 < anti-> i don't think that's i2p's problem... +16:40 < jrandom> (1.4.2 has been more stable for me, requiring less resources) +16:40 < jrandom> and i2p doesn't use any 1.5-isms, nor do we need the 1.5 GUI improvements +16:40 <+fox> <Sonium> the curious thing is, that is never occured before +16:40 <+polecat> Can't use azureus if you don't have 1.5 though, meh. +16:40 <+fox> <ailouros> and of course I *DO* use azureus :| +16:41 <+fox> <ailouros> but it isn't a real problem... not much, I think... +16:41 <+fox> <ailouros> unless those messages about bob being fourth are relevant +16:41 < jrandom> nah, those are safe to ignore +16:41 < anti-> (am i the only one irked by utorrent and bitcomet not being open?) +16:42 <+polecat> :o Damn you bob! +16:42 < jrandom> ok, anyone have anything else for the meeting? +16:42 < anti-> muffins? +16:42 * cervantes can recommend ibm java 1.4.2 if you're after better resource handling +16:42 <+polecat> anti-: Try mlnet. caml -> weirdest language in the world, but it works well. +16:42 <+fox> <ailouros> caml is cool +16:42 <+fox> <ailouros> (if you can read it :D ) +16:42 <@frosk> hey, don't diss caml +16:43 < anti-> prolog deserves a mention there, as does brainf**k et al +16:43 <+polecat> caml has horrible docs. It took me half an hour to figure out that ! usually (sometimes) is a dereference operator. +16:43 <@frosk> i'm paid to write ocaml :) +16:43 <+polecat> jrandom: Didn't know I crashed a meeting, sorry. +16:44 < jrandom> np, we're making up for our short meetings ;) +16:44 * jrandom winds up +16:44 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/156.rst b/i2p2www/meetings/logs/156.rst new file mode 100644 index 00000000..284efcf3 --- /dev/null +++ b/i2p2www/meetings/logs/156.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 15, 2005 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/157.log b/i2p2www/meetings/logs/157.log new file mode 100644 index 00000000..d38c1a2c --- /dev/null +++ b/i2p2www/meetings/logs/157.log @@ -0,0 +1,138 @@ +16:18 < jrandom> 0) hi +16:18 < jrandom> 1) Net status +16:18 < jrandom> 2) Fox hunt +16:18 < jrandom> 3) ??? +16:18 < jrandom> 0) hi +16:18 * jrandom waves belatedly from a house with its power restored +16:18 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001227.html +16:19 < jrandom> 1) Net status +16:20 < jrandom> not much to add beyond whats in the mail.. anyone have anything they want to bring up re: net status? +16:21 < jrandom> if not, movin' on to 2) Fox hunt +16:21 < zzz> great idea +16:22 < jrandom> here, too, I don't have much to add beyond whats in the mail and Raccoon23's proposals.. +16:22 <+fox> <ailouros> I have something against the name "Fox hunt". I'd rather call it "Man hunt". Foxes did nothing wrong. +16:22 < Raccoon23> hah +16:22 < jrandom> aye, I concur zzz, it'll be quite helpful to give people a real incentive without the serious dangers of actual use +16:23 < nickless_head> call it "<politically correct animal> hunt +16:23 < Raccoon23> "Fox hunt" is the typical name for a ham radio contest where you try to find a rogue transmitter +16:24 <+fox> <ailouros> I don't care for radio trasmitters called Fox, we're talking i2p here, no anonymous foxes allowed +16:24 <+fox> <ailouros> :D +16:24 * cervantes wonders if ailouros is aware of the name of changate +16:24 < nickless_head> maybe "Dissident hunt" +16:25 <@cervantes> <fox> <ailouros> :D +16:25 <+fox> <ailouros> (err what's changate?) +16:25 < jrandom> heh +16:25 <@cervantes> ailouros: it's the bots that relay chat between different networks +16:26 <+fox> <ailouros> you mean vulpine here? +16:26 <@cervantes> chat over on i2p gets relayed to you as vulpine +16:26 <@cervantes> and you chat is relayed to us via fox +16:26 <@cervantes> ;-) +16:26 <@cervantes> *your +16:26 <+fox> <ailouros> so the hunt is for the poor slave-working bot? :D +16:27 < Raccoon23> so yeah, I think there should be a bounty/info page set up. I think we should shoot for raising $1k +16:27 <+fox> <ailouros> yeah sorry I don't usually go i2pchat :) +16:27 <+fox> <ailouros> now, that's a bounty! +16:28 < jrandom> Raccoon23: I agree, but it may be a bit premature to do so now. +16:28 < jrandom> (we can always allocate funds out of the general fund to the bounty to kick start it when necessary) +16:28 <+fox> <ailouros> start the hunt right now but without a bounty? +16:28 <+fox> <ailouros> I mean, the sooner it starts, the more eyes get open +16:28 < jrandom> for the fox hunt to make sense (aka help I2P), we need to do so carefully. +16:28 < jrandom> no ailouros, I disagree. +16:29 < jrandom> running the contest before I2P is ready would be very bad. +16:29 < Raccoon23> yah +16:29 < jrandom> both because it would waste people's time evaluating something that isn't done, and because it wouldn't tell anything useful +16:30 <+fox> <ailouros> ....point taken +16:30 < Raccoon23> and it would be bad press if vulns were "found" that were scheduled to be fixed in coming versions +16:30 < jrandom> aye +16:33 < jrandom> ok, anything else on 2), or shall we move on over to 3) ??? +16:34 < zzz> on the other part of the jrandom/raccoon23 thread, was it a conclusion to move to 2-hop-minimum? any other conclusions? +16:35 < jrandom> hmm, its all a question of who one's adversary is, but it wouldn't really hurt to default to 2 +0-1 and would afford protection against a class of attacker +16:35 < jrandom> other conclusions may be "hey, get rolling on 0.6.2" :) +16:35 <+fox> <ailouros> how do I set the configuration so that the tunnels always have a set value (like 0+1 variance)? I keep getting default values every restart +16:36 < jrandom> ailouros: you should be able to save the settings on /i2ptunnel/ +16:36 < jrandom> or are you changing them on /configtunnels.jsp ? +16:37 < Raccoon23> I think 1 hop tunnels allow a pretty weak attacker to do a lot in 0.6.1 at least. I would argue that 0.6.1.6 should not have 1 hop tunnels by default +16:37 <+fox> <ailouros> configtunnels it is +16:37 < jrandom> aye, agreed Raccoon23 +16:37 < jrandom> ailouros: use /i2ptunnel/ and save your settings +16:37 <+fox> <ailouros> didn't notice the new interface :D +16:38 <@cervantes> ailouros: just added in 0.6.1.5 +16:38 < jrandom> yeah cervantes did some great work there ailouros +16:38 <+fox> <ailouros> well, kudos for that +16:39 <@cervantes> while we're on that subject, if folk are having troubles saving settins on the new interface, they might want to use a non-IE browser for now until the next release +16:39 <@cervantes> *grumble* microsoft *grumble* +16:40 <+fox> <ailouros> on a different topic, would anyone be interested if I set up a nethack server on i2p? :D +16:41 <@frosk> ailouros: been thinking about it (playing nethack irl), but the lag would be horrible i'm afraid (and lag sucks really hard when playing nethack) +16:42 <+fox> <ailouros> guess so +16:42 <+fox> <ailouros> okay, idea scrapped +16:43 * frosk just had his first ascension a few months back, woot +16:44 < jrandom> ok, anyone have anything else for the meeting? +16:45 <+fox> <ailouros> yes, some indicator for syndie wen the thread has a new message +16:46 < nickless_head> jrandom: and it would be cool if new messages (the titles) could be printed in bold/italics the first time they're displayed +16:47 < nickless_head> jrandom: is there a _really simple_ way to get to the messages in the syndie database, over http? +16:47 < jrandom> ah yeah ailouros/nickless_head, I'm thinking of color coding/flagging the first column by date (e.g. things posted today get a bright flag, yesterday a less bright, etc). +16:47 < nickless_head> jrandom: preferredly in something nice and importable like xml +16:48 < jrandom> nickless_head: wget -R http://localhost:7657/syndie/archive/ +16:48 < nickless_head> if there is, I could write a syndie to nntp exporter +16:48 < jrandom> oh, if you want to export to nntp, use rss to nntp +16:48 < nickless_head> jrandom: ok I'll try that :) +16:48 < nickless_head> jrandom: that already exists? ... damn. ;) +16:49 < jrandom> i'm also thinking about adding per-user message histories to let you mark messages as read/unread, but that probably won't be in 0.6.1.6 (unless someone else implements it :) +16:49 < jrandom> or perhaps a new filter on the thread tree - only show messages posted since [today |v] +16:49 < jrandom> (or yesterday, or 2 days ago) +16:50 < jrandom> nickless_head: http://www.methodize.org/nntprss/ +16:50 < nickless_head> jrandom: thanks +16:54 < jrandom> np +16:54 < Raccoon23> jrandom: so it'd be a while before I'd be able to implement it (I wanna get restricted routes done first), but what do you think about optional 1024bit garlic routing for outbound server tunnels? +16:54 < jrandom> tremendous overhead - O(data) is >>> O(tunnels). if we're running into trouble now with O(tunnels), there's no way we can hope for O(data) +16:55 < Raccoon23> are we still having cpu issues? my router has been pretty low, but I don't exactly have a T1 over here.. +16:56 < jrandom> not everyone has p4s ;) +16:56 < jrandom> i hear reports of 8-15% usage on slow machines, but that spikes bad under congestion +16:56 < jrandom> (to 100+%) +16:56 <+Complication> About CPU consumption: curiously enough, Java on Mandriva 10.1 consumes a lot less than Java on Mandriva 2006. +16:56 < Raccoon23> yah, but those who don't probably don't have T1 +16:56 < Raccoon23> either :) +16:57 <+Complication> Both tweaked, 2006 has jbigi compiled locally. +16:57 < jrandom> weird Complication +16:57 < jrandom> same revs of i2p? +16:57 <+Complication> On 2006 (Celeron 2.4) java can hit 20%. +16:58 <+Complication> On 10.1 it wouldn't go higher than 5%. +16:58 <+Complication> (Usually) +16:58 <+Complication> (usually==not on startup) +16:58 <+Complication> Same revisions. +16:58 <+Complication> Almost the same Java too (_04 versus _05) +16:59 <+Complication> Reminds me to tweak daemons a bit more. Perhaps some of them is obstructing java. +16:59 <+Complication> In some wacky way I cannot figure out. +17:00 <+Complication> But yes, the Cel 300 is feeling notably better. Could have been the adaptive MTU +17:01 < jrandom> ah cool, yeah, we've got some neat stuff on the way :) +17:03 <+Complication> I wonder if there'd be a way to get past the libc-related jbigi problems on certain Linux distros? +17:03 < jrandom> yeah, definitely, just need to rebuild all the jbigis +17:03 < jrandom> (its not libc, its libg++) +17:05 * Raccoon23 decides he doesn't give up his dreams of garlic routing, but will wait for performance to stabilize.. perhaps 2.0 +17:05 <+Complication> Oh, you think a proper rebuild will help it? +17:05 < jrandom> Complication: yeah, the jcpuid link errors are unnecessary, as jcpuid is really just an ASM call (and shouldn't have been implemented in c++ anyway ;) +17:06 < jrandom> Raccoon23: cool :) its something we can do eventually over the live net too, just using a different I2NP message type, advertising the right capability, and filtering on that +17:06 < jrandom> (eventually) +17:07 < Raccoon23> like a caps=S for speedy CPU? ;) +17:08 < jrandom> and caps=I for insane ;) +17:08 < jrandom> ok, anyone else have something for the meeting? +17:08 < Raccoon23> haha +17:09 < Raccoon23> what do you think about the stopgap of sharing keys across multiple tunnels? too little payoff for the work? +17:09 < jrandom> why would that be better than just having multiple tunnels and sending the message through one of the multiple tunnels? +17:10 < jrandom> (and, erm, wouldn't it be worse, from a security perspective, and anonymity perspective) +17:10 < Raccoon23> well the idea is that nodes could not tell which traffic was part of one tunnel, so that if you were running i2phex and and eepsite, and choose the same hosts for your tunnels, the traffic from the two would be blended as far as the hops could see +17:11 < Raccoon23> which should make timing attacks harder +17:11 < jrandom> ah, yikes, yeah. that adds Really Bad linkability +17:11 < jrandom> its why we moved to per-client tunnel pools in 0.4 +17:11 < Raccoon23> explain? +17:11 < jrandom> i2ptunnel does let people share pools, if they want, by sharing the same destination +17:12 < jrandom> if messages for 2 clients go down a tunnel, you know both of those clients are controlled by the same person +17:12 < jrandom> s/clients/destinations/ +17:13 < Raccoon23> well if keys were shared, the early hops could be blended, but the leasesets seperate.. +17:13 < Raccoon23> the early hops being the dangerous ones for timing attacks anyways +17:13 < jrandom> it'd still allow a vector for linking the two unlinkable destinations +17:14 < jrandom> one could do some munging to hopefully obfusticate the linkability, but they'd be inherently linked. which isn't necessary, and is bad. +17:18 < Raccoon23> back to dreaming of caps=SI I guess :) +17:19 < jrandom> ah well. ok, anyone have anything else? +17:20 * jrandom winds up +17:20 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/157.rst b/i2p2www/meetings/logs/157.rst new file mode 100644 index 00000000..3d36fbe2 --- /dev/null +++ b/i2p2www/meetings/logs/157.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 22, 2005 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/158.log b/i2p2www/meetings/logs/158.log new file mode 100644 index 00000000..d3d35fc8 --- /dev/null +++ b/i2p2www/meetings/logs/158.log @@ -0,0 +1,222 @@ +15:25 < jrandom> 0) hi +15:25 < jrandom> 1) Net status and 0.6.1.6 +15:25 < jrandom> 2) Syndie +15:25 < jrandom> 3) I2P Rufus 0.0.4 +15:25 < jrandom> 4) ??? +15:25 < jrandom> 0) hi +15:25 * jrandom waves +15:25 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html +15:26 * bar hands jrandom a baf +15:26 < c3rvantes> not yet! +15:26 * jrandom winds up +15:26 < jrandom> er... +15:26 < jrandom> lets hit the first few agenda items first :) 1) Net status and 0.6.1.6 +15:27 < jrandom> lots of things have been updated in the last few releases, but the network still seems reasonably stable. +15:28 < jrandom> we've had some serious spikes in router participation on a few routers, though thats pretty harmless +15:28 <+legion> cool, I agree net status is getting better. Also yeah why not drop tcp for 0.6.1.7 +15:28 < jrandom> (er, spikes in tunnel participation, that is) +15:29 <@cervantes> you're not kidding +15:29 < jrandom> not sure legion. there may be some users out there limited to tcp only, but i seem to recall that there was only one or maybe two of those +15:29 <+legion> well I've noticed with 0.6.1.5 the router would sometimes restart on its own. +15:29 <+Complication> Mine's been swinging withint reasonable limits, 100 to 250 participating tunnels +15:29 < jrandom> I can't think of any great reason to keep it, and I can think of a few to drop it +15:30 < jrandom> cool Complication +15:30 < jrandom> (those numbers are fairly average, according to stats.i2p/, but remember, numbers like that can damage anonymity, so shouldn't really be given out, especially not in logged meetings ;) +15:30 <+Complication> My old Celeron is still auto-restarting every 10 hours or so +15:30 <+Complication> Otherwise it's better connected than ever before +15:30 < Pseudonym> what are the reasons to drop it? +15:31 <+Complication> TCP is expensive +15:31 <@cervantes> my router is shagged out +15:31 <+Complication> In terms of threads per connections +15:31 <@cervantes> Complication: multiply that by 10 and you get my router's current range ;-) +15:31 <+legion> Mines been swinging within 200-400 participating tunnels, so it seems better than ever. +15:32 <+Complication> cervantes: ouchie ouchie +15:32 <+Complication> I've seen a freak accident which caused 2000 participating tunnels, but that was in Summer +15:32 < jrandom> Pseudonym: performance (cpu/memory, better scheduling due to our semireliable requirements), maintainability, more effective shitlisting +15:32 <+Complication> A single spike which never repeated again +15:32 <+legion> yeah, with some past versions there were such spikes +15:32 < jrandom> Complication: we've had > 2000 tunnel spikes with this last rev +15:33 < jrandom> but hopefully 0.6.1.7 will take care of that +15:33 <+legion> Well those are some good reasons to drop tcp :) +15:33 < jrandom> but, again, the spikes in tunnel participation is fine, as most of them aren't used +15:34 <@cervantes> Pseudonym: there only seems to be one or two routers still using tcp on the network +15:34 < jrandom> it may also be a good idea to drop tcp in this rev too, since it doesn't have other major changes. that way we can see how it affects things pretty clearly +15:34 < jrandom> (and can reenable it if necessary) +15:35 < Pseudonym> if there are only two routers using it, I can't imagine it would have much effect either way +15:35 < Pseudonym> (except for there being two less routers on the network) +15:35 <@cervantes> 2 disgruntled customers +15:35 < jrandom> well, the transport does show up in some odd situations, which is one of the reasons i want to disable it :) +15:35 <+Complication> I hope they won't take it very personally +15:36 <+Complication> It's really nasty of certain ISP's to filter UDP. +15:36 <+Complication> Nasty, and completely senseless. +15:36 < jrandom> (e.g. when a router is hosed, people mark their SSU transport as failing, and as such, they fall back on the tcp transport) +15:36 * Pseudonym loves his ISP. no restrictions +15:37 <+Complication> So without TCP, one would see how UDP handles it alone? +15:37 <+Complication> "with no auxiliary wheels" :P +15:37 <+legion> huh so how do we get around such nasty filtering without tcp? +15:38 < jrandom> exactly Complication :) +15:38 < jrandom> legion: we don't +15:38 < jrandom> (restricted routes) +15:38 <+Complication> Well, aren't there a number of useful apps besides file-sharing programs, which also use UDP packets sized above DNS packets? +15:39 <+legion> :( doesn't sound good +15:39 <+Complication> Sized similarly to the smallest packet size I2P uses? +15:39 < jrandom> eh legion, its not a problem +15:39 < jrandom> Complication: streaming protocols +15:39 <+Complication> One cannot block UDP directly, ever, without crippling DNS. +15:39 <+Complication> One can limit the packet size. +15:40 <+legion> ok, it did sound like it could be +15:40 <+Complication> VoIP? +15:40 < jrandom> it'd be a problem if it were widespread - if the internet community in general banned udp +15:40 <+Complication> Hmm, does VoIP use big or small packets? +15:40 < jrandom> but if its just a few isps, we can treat them like restricted routes +15:40 <+Complication> Or did you mean more like... video spreaming? +15:40 <+legion> I'd think it'd use a mix of both +15:41 < jrandom> both Complication, RTSP runs over UDP, and real runs over RTSP iirc +15:41 <+Complication> s/p/s +15:42 <+legion> So on to the next item? +15:42 <+Complication> cat /etc/services | grep -c udp +15:42 <+Complication> 227 +15:43 < jrandom> I'm still not sure if we'll drop tcp in 0.6.1.7, but probably. +15:43 < jrandom> aye, anyone have anything else on 1)? if not, lets jump on to 2) Syndie +15:43 <+Complication> Meaning, there are at least 227 apps (some possibly obsolete or LAN apps) which use UDP +15:44 < jrandom> bah, this is the intarweb. all you need is proxied HTTP access +15:44 < jrandom> I don't have much to add to 2) beyond whats in the mail (and whats on Syndie) +15:44 <+legion> I'm convinced, yeah drop it. :) +15:44 < jrandom> anyone have anything re: syndie they want to bring up? +15:45 <+legion> I've nothing to say about 2) either. +15:45 * Complication is reading "how Syndie works" +15:46 <+Complication> One little UI effect, keeps surprising me. :D +15:46 <+Complication> When I expand a thread of messages, it always gets me by surprise that the active message moves to become the topmost in the list. :P +15:47 <+Complication> But you can proabably safely ignore that. I'm just very picky, and a creature of habit. :P +15:47 <@cervantes> the threading model is something that's being discussed at length +15:47 <@cervantes> ;-) +15:47 <+Complication> I'll get used to it. :) +15:48 <+Complication> cervantes: in Syndie? I gotta find that thread. :) +15:48 <@cervantes> I don't like that either - but it could well change +15:48 < jrandom> yeah, thats kind of kooky I suppose +15:48 <+legion> yeah +15:48 <@cervantes> "subject: syndie threading" +15:49 <+Complication> Besides, if the expanded message were the bottom-most, it *would* have to move anyway. +15:49 <+Complication> 'Cause otherwise it'd be stuck there. +15:50 < jrandom> well, the nav at the bottom shows 10 *threads* at a time, not 10 messages. so it could expand the bottom thread +15:50 * cervantes is testing some different threading UI style implementations atm +15:51 < jrandom> wikked +15:51 < jrandom> yeah, ideally we'll be able to switch them around in css, or if not, on the server side +15:52 <@cervantes> or rather "threading navigation styles" +15:53 <@cervantes> hmm my tests use pure html nested unnordered lists by default +15:53 <@cervantes> you can layer on as much css and javascript as your need or want +15:53 < jrandom> any eta on when we can see some mockups? +15:53 <@cervantes> (however it's only a proof of concept, not an actual ui implementation) +15:54 <@cervantes> I do most of my coding during I2P meetings ;-) +15:54 < jrandom> heh +15:54 <@cervantes> perhaps the first mockup will be ready this evening +15:54 * jrandom schedules daily meetings +15:54 < jrandom> wikked +15:54 <@cervantes> curses :) +15:55 < jrandom> ok, anyone have anything else for 2) syndie? +15:55 < jrandom> if not, lets move on to 3) I2P Rufus 0.0.4 +15:56 < jrandom> I don't have much to add beyond whats in the mail - Rawn/defnax, y'all around? +15:56 <+legion> so how good is 0.0.4? What problems remain if any? +15:57 * jrandom hasn't a clue +15:58 <+legion> Maybe one of its users can answer. Does it seem good and stable? +15:58 < jrandom> ok, seems Rawn and defnax are away atm. if anyone has any questions/comments/concerns regarding I2P Rufus, swing on by the forum and post 'em away +15:58 <+legion> darn, guess we'll have to. +15:59 <+legion> on to 4)? +15:59 < jrandom> aye, so it seems. ok, 4) ??? +15:59 <+Complication> I haven't tried I2P Rufus, unfortunately. +16:00 < jrandom> anyone have anything else they want to bring up? +16:00 < jrandom> (c'mon, we've got to drag this out so cervantes can do some more work!) +16:00 <+legion> yeah, what sort of interesting stuff is coming down the pipe? +16:00 <+bar> is there anywhere i could read more about "restricted routes"? +16:00 <+bar> (i *have* searched) +16:01 <+legion> Maybe we could even discuss i2phex? +16:01 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD +16:01 * cervantes poises his mouse over the close button +16:01 < jrandom> er, #future.restricted +16:02 < jrandom> plus the how_* pages & todo +16:02 < jrandom> (on the web) +16:02 <+Complication> Heh, I2P seems to have skipped a build :D +16:02 <+Complication> :D +16:02 <+bar> thanks +16:02 <+Complication> - public final static long BUILD = 1; +16:02 <+Complication> + public final static long BUILD = 3; +16:03 < jrandom> legion: some hacking on the netDb, performance mods, restricted routes, streaming improvements, eepproxy improvements, tunnel improvements, etc. lots of stuff, but nothing ready yet +16:03 <+legion> huh, odd +16:03 < jrandom> anything to bring up re: i2phex legion? +16:03 < jrandom> Complication: yeah, intended. I forgot to increase it for BUILD = 2 +16:03 <+Complication> (not that it matters for anything, just wondering if I've seen this rare occasion before :) +16:04 <+legion> sweet, sounds great, thanks! +16:04 < jrandom> oh, that reminds me... it'd be cool if someone wanted to dig into looking at revamping our webpage +16:05 * jrandom doesnt want to think about it, but its got to be done sooner or later +16:05 <+legion> yeah, there is +16:05 <+legion> would it be worthwhile to update i2phex at this point to the latest phex cvs code? +16:06 <+Complication> Not sure, I haven't heard from Redzara recently +16:06 < jrandom> last I recall, redzara was waiting on gregorz's updates to phex +16:06 < jrandom> (so we could have a fairly clean update/extension) +16:08 <+legion> huh, then why have i2phex? +16:08 <+Complication> Just in case? +16:08 < jrandom> hmm? +16:08 < jrandom> i2phex is an extension to phex +16:08 <+legion> Seems like they wanted there to just be phex with a i2p extension +16:09 < jrandom> extension, as in, modification to a very small number of bits +16:09 < jrandom> er, s/bits/components/. so we can easily update the code whenever the phex devs fix things +16:10 <+legion> if so then it shouldn't take much work for me to update it to the latest cvs code, though I know it will. +16:10 < jrandom> last I heard in the forum was that the plan is to have I2Phex and Phex be separate applications, but they'd share a majority of code +16:10 < jrandom> aye legion, that'd be great, but last I heard, Gregor hadn't finished the modifications to Phex yet +16:11 < jrandom> (which is what redzara was waiting on) +16:11 <+legion> ah I see +16:11 < jrandom> so, the alternative is to either help Gregor out or continue modifying the existing I2Phex codebase +16:12 <+legion> well then if I don't wait and just update i2phex with new code, there would be no need for redzara continue +16:12 < jrandom> well, not really. +16:12 < jrandom> updating I2Phex to the current Phex code would be great, yes +16:13 < jrandom> but as soon as the Phex developers update their Phex code, we're out of sync again +16:13 <+legion> ok, I'll probably get to it sometime tonight or within a couple days. +16:13 < jrandom> wikked +16:13 <+legion> That is fine. +16:14 <+legion> Really I'm not looking to have i2phex remain in sync with phex code, it's just that it sounds like the cvs contains fixes which i2phex could certainly use. +16:15 <+legion> Also I'm really looking to drop out any phex code and features which i2phex doesn't need. +16:15 < jrandom> cool +16:16 <+legion> As to any new features and fixing anything that is still not working like the upload queues... Well I've already looked into getting the webcaches working, but have much more to do. +16:17 < jrandom> word. yeah, phex used to have working gwebcache support, but sirup disabled it, as it wasn't necessary at first +16:17 <+legion> I do plan on adding jeti to i2phex eventually. +16:17 < jrandom> neat +16:18 * jrandom has never used jeti, and I hope it stays an optional component, but supporting more things is cool +16:18 <+legion> Yeah it can be optionally, users will be able to download a jeti2phex ;) +16:19 < jrandom> word +16:19 <+legion> There still is much we can do with i2phex, though it is working great as it is. +16:20 <+legion> So far keeping a client connected, up and running for 24/7 is possible and easy. +16:21 < jrandom> yeah, I've had some good success with it... "backing up my licensed recordings" +16:21 <+legion> heh :) +16:22 < jrandom> ok, anyone else have anything for the meeting? +16:23 * cervantes wheels in the chinese gong +16:23 <+legion> Seems like I'm forgetting something... hmm +16:24 <+legion> Oh yeah, any ideas on how we can reduce the amount of memory i2p and i2phex consumes? +16:25 <+Complication> Well, the TCP transport takes a bit +16:25 < jrandom> one could run both in the same jvm +16:25 <+Complication> If that is going, it will free a bit +16:26 <@cervantes> take some ramsticks out of your machine +16:26 < cat-a-puss> anyone with any experence with javolution know if it would help? http://javolution.org/ +16:26 < jrandom> (clients.config in the i2p install dir defines the main class and arguments to launch clients) +16:26 <+legion> So if we ran both in the same jvm and when tcp goes, could we bring it down to under 50mb? +16:27 < jrandom> no idea legion. depends on what you mean by 50MB as well. RSS/VSS/etc +16:27 < jrandom> I really wouldn't recommend running both in one JVM though, unless you keep both running all the time, since shutting down one would kill the other +16:27 <@cervantes> legion: limiting bandwith and capping participants might also help +16:27 < jrandom> aye, what cervantes said +16:28 < cat-a-puss> it would seem to me that if we know exactly how many of some type of object we are eventually likely to use, it would help prevent overzellous jvm allocation +16:28 <+Complication> Right, it makes those different allocations, which I've never really managed to make sense of +16:28 < jrandom> aye, we do some of that cat-a-puss (see net.i2p.util.ByteCache) +16:29 <+Complication> (but as said, Java is a very new thing to me) +16:29 < jrandom> I've glanced at javolution before, but it seems to have made a lot of progress. i'll give 'er another look +16:30 < cat-a-puss> jrandom:I know some people at my work use it and are happy with it, though they don't care about memory allocation +16:31 < jrandom> well, it really wouldn't save any memory, but would help cut down on GC churn +16:31 <+legion> Well I personally don't care much about memory allocation, however many people do. +16:31 < jrandom> ooh, and its BSD licensed too +16:31 < cat-a-puss> right +16:31 < jrandom> legion: memory allocation means performance +16:32 <+legion> er, oh, memory consumption then +16:33 <+legion> Many people are so very happy with utorrent because of it's very small memory footprint. +16:33 < jrandom> ah, oh, yeah. we can tweak it down the line, but since i2p runs within the default jvm sizes, i'm not too worried (as we've got lots of room for tweaking) +16:34 < jrandom> ok, anyone have anything else for the meeting? +16:35 <+legion> nah I'm good... +16:37 * jrandom winds up +16:37 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/158.rst b/i2p2www/meetings/logs/158.rst new file mode 100644 index 00000000..a1bbbeae --- /dev/null +++ b/i2p2www/meetings/logs/158.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 29, 2005 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/159.log b/i2p2www/meetings/logs/159.log new file mode 100644 index 00000000..054c98d5 --- /dev/null +++ b/i2p2www/meetings/logs/159.log @@ -0,0 +1,260 @@ +15:26 < jrandom> 0) hi +15:26 < jrandom> 1) 0.6.1.7 and net status +15:26 < jrandom> 2) Experimental tunnel failures +15:26 < jrandom> 3) SSU and NATs +15:26 < jrandom> 4) Syndie +15:26 < jrandom> 5) ??? +15:26 < jrandom> 0) hi +15:26 * jrandom waves +15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001237.html +15:26 * ailouros read the notes +15:27 * jrandom is late, so I'll give y'all a moment to read up :) +15:29 < jrandom> ok, might as well jump on in to 1) 0.6.1.7 and net status +15:29 <@cervantes> *cough* +15:29 < jrandom> I don't have much more to add beyond whats in the mail on this point. anyone have any further comments/questions/ideas? +15:30 < Pseudonym> seems like doing performance optimization before changing the the tunnel creation algo might be backwards +15:30 < gott> I am getting a lot of "No HTTP method found in the request. +15:30 < gott> Software caused connection abort: socket write error +15:30 < gott> " +15:30 <@modulus> tunnel lag is much lower, i don't know if you made any changes or my ISP is better all of a suden. +15:30 < gott> from the I2PTunnel Webmanager +15:31 < jrandom> gott: those suggest bad http requests, or things that the eepproxy ouldn't understand +15:31 < jrandom> modulus: cool, we've been doing lots to try and improve things +15:31 < jrandom> Pseudonym: well, so far tunnel creation hasn't been our choke point - our choke point was much higher level stuff +15:32 < jrandom> otoh, the improvements of the last few revs have exposed some issues down there +15:32 < Pseudonym> oh, so the optimization has been related to other parts of the code? +15:32 < Pseudonym> cool +15:33 < jrandom> aye, at the SSU level, as well as the tunnel operation level. tunnel creation is not a performance sensitive operation [except when it is ;] +15:34 < jrandom> I'm doing some live net load testing though, gathering some non-anonymous load stats of different peers to try to narrow things down further +15:34 < ailouros> I wonder why sometimes I see more tunnels than those configured for a destination (eg. eeProxy, inbound 7 tunnels 4 outbound) +15:34 < jrandom> so, over the next few days when you see the router 7xgV transferring lots of data, well, dont mind it ;) +15:35 < jrandom> ailouros: when tunnel creation takes a while, it builds extras, just in case. +15:35 < jrandom> zzz outlines a few of the odd issues on that front too, and there's a patch being worked on to improve things a bit +15:35 < ailouros> I see.. but then why they all expire at the same time? +15:35 <@cervantes> jrandom: out of curiosity, when did you begin those tests? +15:35 < jrandom> cervantes: a few days ago +15:36 <@cervantes> ah cool, it's _not_ that then ;-) +15:36 < jrandom> dunno ailouros, depends on a few conditions. but there are some... *cough* oddities in the tunnel creation code, which I've been holding off messing with since its getting rewritten for 0.6.2 +15:38 < ailouros> I see. I thought it was a policy matter... I'd rather see the tunnels die at different times unless there's a good reason not to +15:38 < ailouros> as in, tunnel creations are skewed +15:39 < jrandom> aye, there will be better randomization for 0.6.2, and zzz's patch adds some randomization for the current rev too +15:40 <+Complication> I wonder why an otherwise sane instance of i2phex... would decide to rehash files every other time I start it? +15:40 < jrandom> not a clue +15:40 <+Complication> Damaged configuration sounds the likely cause so far, but I've not deleted my config yet. +15:40 < jrandom> perhaps skewed timestamps? +15:42 <+Complication> Nah, they seem correct too +15:42 * jrandom knows not. never looked at that part of phex's cod +15:42 < jrandom> er, code +15:42 <+Complication> I'll see if deleting old config files does it any good +15:42 < jrandom> cool +15:43 < jrandom> ok, anything else on 1) Net status / 0.6.1.7? +15:43 < jrandom> if not, moving on to 2) Experimental tunnel failures +15:44 < jrandom> we've touched on this a bit already, and there's more in the notes and on zzz.i2p +15:44 < jrandom> zzz: do you have anything you want to add/bring up? +15:46 < jrandom> if not, lets move on to 3) SSU and NATs +15:46 < jrandom> bar: anything you want to add? +15:46 <+bar> nope, i have nothing else to add but what's in the mail +15:47 < jrandom> cool, yeah I've still got to reply to some of the details - i think our retransmission will already take care of some of the issues you bring up +15:48 < jrandom> the trick is going to be detecting which situation is in play, so we can automate the right procedure (or inform the user that they're screwed) +15:48 <+bar> all in due time, no hurry +15:49 <+bar> aye, i suggested a manual user setting to circumvent that problem for the time being, perhaps it's not possible, but we can discuss it later +15:50 < jrandom> yeah, manual overrides will help, but my experience with earlier i2p revs was that everyone (*everyone*) fucked it up ;) so automation is preferred +15:50 < jrandom> (everyone meaning myself included ;) +15:52 <+bar> agree +15:52 < ailouros> lol if I did too then there were something wrong with the docs, as I followed them bit by bit :D +15:53 <+bar> meanwhile, i will spend some time studying the peer testing +15:53 < jrandom> cool, thanks bar! +15:54 <+bar> (perhaps i could generate some useless spam regarding that as well :) +15:54 < jrandom> :) +15:55 < jrandom> ok, if there's nothing else on 3), lets move on to 4) Syndie +15:56 < jrandom> there has been a lot of progress on this front lately, with pretty substantial UI revamps since 0.6.1.7 came out +15:57 < jrandom> there's also a new standalone install/build, though since all of us have i2p installed, we don't need a separate one +15:57 < ailouros> I find that 6.1.7's layout is harder to use than 6.1.6's +15:58 < jrandom> hmm, are you running syndie in single user mode? and/or are you using the latest CVS build or the official 0.6.1.7 build? +15:58 < ailouros> official 0.6.1.7, single user +15:58 < jrandom> are you one of the proponents of the blog-like interface, as opposed to the threaded nav? +15:58 < ailouros> I am not, though I don't really know which is the blog-like +15:58 < ailouros> personally I'd rather have a threaded nav +15:59 < ailouros> (and some color-coding of new messages as well in thread view) +15:59 <+Complication> Relatively late CVS, single user +15:59 <+Complication> I've found a minor oddity (which I think, could be non-intended) +15:59 < jrandom> ah, there has been a lot of progress on that front in CVS ailouros +15:59 < ailouros> great :) +16:00 < jrandom> we've got a new threaded display too, using cervantes' suggested full traversal of just one branch, as opposed to all branches +16:00 <@cervantes> are those changes pushed to syndiemedia.i2p.net? +16:00 <+bla> Would it be a good idea to show some default examples for the location in http://localhost:7657/syndie/syndicate.jsp ? +16:00 < jrandom> syndiemedia.i2p.net is CVS head, yeah +16:00 <+Complication> When you've opened up a thread, and are currently reading its posts... and then choose to apply a filter to which no posts match (e.g. open thread "Syndie threading", apply filter "i2p.i2phex")... +16:00 < jrandom> aye, perhaps bla. new installs will have the three defaults in there, but examples would be good +16:01 <@cervantes> (the actual thread's tree needs to fully open too though) +16:01 <+Complication> ...it appears to leave the current posts displayed, as if they were matching or something... +16:01 <+Complication> Despite me definitely clicking the "Go" button. +16:01 <@cervantes> Complication: yeah I found that confusing too +16:02 < jrandom> hmm Complication, the general idea was to let you browse around while still looking at a post, but perhaps it'd be best to drop the posts being displayed +16:02 < jrandom> cervantes: ah, yeah expanding it to the leaf would be good, and should be trivial to do +16:02 <+Complication> Just noticed, and since it stuck out, thought I'd tell +16:02 <@cervantes> (or make it more obvious that there aren't any matches) +16:03 < jrandom> well, the thread nav says *no matches* :) +16:03 < ailouros> perhaps he's looking for a lighter +16:03 < jrandom> !thwap +16:03 <@cervantes> (or make it even more obvious that there aren't any matches) +16:03 < jrandom> <blink>No matches</blink> +16:03 <+Complication> Oops :) +16:04 < tethra> seems your !thwap got spaetz__ instead, jr! +16:04 <+Complication> Right, sometimes the thread navigator *does* feel a long distance away :) +16:04 < jrandom> yeah, we're experimenting with some css to float that down the side, as an option +16:05 <@cervantes> with skinning support you could have the thread top buttom left right etc +16:05 <@cervantes> ah as jr said +16:05 <+Complication> The "Threads" link takes one there fairly quick, though +16:05 <+Complication> ...if it's within the viewport currently. +16:06 <+Complication> And those who are used to keyboard-navigating can naturally press "End" +16:06 < jrandom> of course, this stuff is really simple to modify (as you can see from the rapid changes in CVS :), so if anyone has any suggestions (or mockups - html / png / etc), please, post 'em up whenever +16:07 < jrandom> I expect we'll have a main blog overview page in the next few days in cvs +16:08 < jrandom> ok, there's lots of other stuff going on w/ syndie, so swing on by http://localhost:7657/syndie/ for more info :) +16:08 < jrandom> anyone have anything else to bring up on that, or shall we move on to 5) ??? +16:09 < zzz> hi just walked in. on 2), I'm looking for testers for my patch. +16:10 < zzz> My results are improvements in job lag and reliability, and reduction in router hangs. So hoping others will try. +16:10 < ailouros> that sounds good enough. what do I have to do? +16:11 < jrandom> heya zzz, ok cool, i'll be bashing it around a bit here too. its got lots of different components to it, so might be worth splitting up into pieces, but it does look good and is on track for 0.6.1.8 +16:11 < ailouros> (average uptime is about 10h here :( +16:11 < zzz> If you have source code and ant just apply the patch - or I can put up an i2pupdate.zip if you want +16:12 < zzz> jrandom I'll work on splitting it up +16:12 < ailouros> I'll go for the update, thanks +16:13 < zzz> ailouros will put it on zzz.i2p within an hour - thanks +16:13 < jrandom> zzz: I wouldn't worry about it unless you've got spare time... I can read through the diff :) +16:13 < ailouros> thank you +16:14 < zzz> jrandom OK. There's some miscellaneous stuff that can easily be ripped out by either you or me. +16:16 < ailouros> I guess we're at 5) ??? now? +16:16 < zzz> jrandom other topic was Router OOMs with i2phex and possible SAM issues +16:16 < jrandom> aye ailouros +16:16 < jrandom> ah yeah zzz, it'd be great to track down whats up with SAM +16:17 < ailouros> j346, did you have the chance to check out my app? +16:17 < jrandom> what would Rule is if someone could jump on and take over maintenance of the SAM bridge, as I havent done any substantial work on it, and human hasn't been around for a while. +16:19 < jrandom> not yet ailouros, unfortunately. was a bit unsure about how it worked, so I've got to read through the source first +16:20 < ailouros> feel free to ask +16:20 < ailouros> (and good luck on the journey through the source, it's a good definition for the word "mess") +16:20 < jrandom> hehe +16:21 < zzz> correction my experience has been OOMs when using i2p-bt, not i2phex. Happens after about 24 hours when running one i2p-bt and in a few hours when running two i2p-bt +16:22 <+Complication> Mine happened after some late-night stress-testing. +16:22 <+Complication> (during which, let it be noted, I saw 5-minute averages of 50 KB/s) +16:22 < bar_> could you please remind me what your app is/does, ailouros? my memory is good but short... +16:22 <+Complication> Incoming, that is. +16:22 <+Complication> Outgoing was limited to 35 KB/s +16:22 <@cervantes> Complication: I've never heard it called late-night stress testing before... +16:22 < jrandom> nice Complication +16:23 <+Complication> cervantes: well, one *could* call it semi-daily megaleeching then :P +16:23 < ailouros> bar_: it's a working proof-of-concept for a distributed filesharing app which shares common blocks among differnt files (as suggested by polecat) +16:23 < bar_> ah, right, thanks ailouros +16:24 < tethra> cervantes: heheheh ;) +16:24 < ailouros> you're welcome (if anyone wants to get the source, it's in c/c++) +16:25 <+polecat> ailouros: Be careful, the chance of two binary blocks being the same is sufficiently rare, I'm mostly talking about pure theory that would be unuseful in practice. +16:25 < ailouros> polecat, I agree. My best guess is that it comes useful when you get different versions of the same files +16:25 < ailouros> like, a movie which has a corrupted block +16:25 <+polecat> You could transfer blocks of zeroes at lightning speeds! ("The next block is zeroes" "oh I have that already" "the next block is zeroes" "oh I have that already") +16:26 < ailouros> or an archive of other zip files +16:26 < jrandom> or e.g. modified ID3 tags, etc +16:26 < ailouros> exactly +16:26 <+polecat> True. But an easy way to "fix" a movie with a corrupted block is to tell bittorrent to download on top of it. Most clients will preserve the blocks whose hashes are the same, and overwrite the ones that are different. +16:26 < jrandom> archives of files probably won't work though, since they'd have to break on file boundaries +16:27 < ailouros> j636, that's why I want to implement LBFS's idea of splitting on data marks and not fixed block sizes +16:27 <@cervantes> the DC community used that method, by sharing file distributions in rarsets +16:27 <+polecat> What might be useful is to make a general binary error correction algorithm, then implement it on a huge scale. All blocks could be "corrected" into each other, and you'd only have to transmit the correction data, which might be smaller than transmitting the block itself. +16:29 <@cervantes> and then searches are basedon tiger hashes of those rar parts +16:29 <+Complication> Nice thought... sounds difficult though :) +16:29 <+polecat> But just a hash-for-hash equivalent... you'd never find two blocks alike! +16:29 < ailouros> cervantes, what's a "rarset"? :D (except a "RAR file", that is) +16:29 <+polecat> Unless both sides already had the file, one of them corrupted. +16:29 < ailouros> polecat, uh? +16:29 <@cervantes> ailouros: a split rar archive, with parity files if necessary +16:30 < ailouros> cervantes: I don't understand the advantage of doing that +16:31 <@cervantes> it's main benefit was to add pseudo-multi-source downloading to DC +16:32 < ailouros> well, that's part of the block sharing mechanism between files, isn't it? +16:34 < ailouros> polecat: about the bittorrent overwriting of damaged files, what it doesn't buy you is when you're trying to get multiple versions at once +16:35 <@cervantes> your client only matches/downloads valid parts, if you have parity files you can also recover damaged parts +16:35 < ailouros> with my system there are no damaged parts (files are assembled only when the composing blocks are downloaded and re-checked) +16:36 <@cervantes> stuff bittorrent does by default, except that you can't search specifically for individual parts +16:36 <+polecat> Multiple versions aren't likely to have a single bit in common though... which is why they're so stupid. Some jerk decides to re-encode the movie in postage stamp format, and gives it the same name. +16:37 <+polecat> Or another jerk takes random data and names it by the file you want to download. +16:37 < ailouros> lol that's correct +16:37 <@cervantes> exactly and rarset releases are immune to that... +16:37 < ailouros> but keep in mind that files from other networks (emule, kazaa, whatever) often come corrupted +16:38 <+polecat> rarset releases aren't immune... +16:38 <+polecat> You still have to figure out which rarset is the right one. +16:38 < ailouros> cervantes, how are rarsets immune to an idiot publishing random junk? +16:38 <@cervantes> (provided you have a reliable source) +16:39 <@cervantes> because a release group publishes hashes/distribution information +16:39 < ailouros> hahaha that's easy :D +16:39 <@cervantes> and stuff is marked as nuked if it's poor quality, folk remove it from shares +16:40 < ailouros> cervantes, that much my toy already does +16:40 <@cervantes> cool +16:40 < ailouros> you get the file descriptor from a trusted source, you multiget the file pronto +16:41 <@cervantes> sounds good ;-) +16:41 < ailouros> you don't get to sarch for files, but you can browse through each user's shared dire, so you can use a web crawler and cache the results +16:42 < ailouros> though I might add a search function sometime in the future if deemed necessary +16:44 < ailouros> I believe my toy, proprely developed into an app, can offer the caching and resiliancy the freenet people try to offer +16:44 < ailouros> as in static content distribution and caching +16:45 < ailouros> you read my blog, you cache it and offer it to other people when they want. you don't do anything more than leave the content there +16:45 < ailouros> don't like the content? delete it and we're all set +16:45 < jrandom> hmm, so do you see it as a backing store that could be used for syndie? +16:46 < ailouros> it CAN be used as a backing store +16:46 < ailouros> as it is now, you might even use it in place of jetty, in i2p default installations +16:46 < jrandom> e.g. attachments / links to [clunk hash="$foo"]my file[/clunk] +16:46 < ailouros> (well with a couple of minor changes :D ) +16:46 < jrandom> heh +16:47 < jrandom> ok, yeah, I definitely don't understand how clunk works... wanna post about it in syndie, or put up an eepsite? :) +16:47 < ailouros> file hashes are downloaded on file request, and these hashes are automagically downloaded into the full file +16:48 < jrandom> right, but "down"loaded is a question of from where to where, etc. an overal network architecture description would be helpful +16:48 < ailouros> I'll write a decent doc first, then publish it somewhere +16:48 < jrandom> r0x0r, thanks +16:48 < ailouros> downloaded from wherever you got the hash from +16:48 < ailouros> plus everyone else sharing these blocks +16:49 < ailouros> think go!zilla and download accellerator :) +16:49 < jrandom> I think you misunderstand how much I am confused +16:49 < ailouros> but transparent and within i2p +16:49 < ailouros> lol guess so :D +16:50 < jrandom> a very, very basic explanation of e.g. "you run a clunk client, download from a clunk server, get info about clunk peers", etc +16:50 < jrandom> do I use a web browser to query a clunk client? or server? or peer? +16:51 < jrandom> (thats how lost I am) +16:51 < ailouros> redo from 0 :) +16:51 < ailouros> you use your web browser +16:51 < ailouros> you connect to your client +16:51 < ailouros> you browse others' dir with your browser +16:51 < ailouros> you select which files to download with your browser +16:51 < ailouros> your client does the dirty work +16:52 < ailouros> you get the downloaded file back +16:52 < ailouros> is this better? :) +16:52 < jrandom> ok great, thanks - so the "browse other's dir" is done by your client querying their client and responding back with an HTML representation of it +16:52 < ailouros> exactly +16:52 < jrandom> (or pulled from some server/superpeer/etc) +16:53 < jrandom> coo' +16:53 < ailouros> all the dirty work (finding duplicates, multidownloads and so on) is done by your (local) client transparently +16:54 < ailouros> what you see is, basically, a directory tree and some fiels you can download +16:54 < jrandom> cool +16:55 < ailouros> to publish your data you give away your public (p2p) address +16:55 < ailouros> and to share files you copy them (or symlink them) to the pub/ directory (or some subdir). It's that easy +16:57 * jrandom will dig through the source further, and look forward to more info :) +16:57 < jrandom> ok, anyone else have anything for the meeting? +16:57 < bar_> umm.. what's the difference between publishing and sharing, if i may ask? does publishing push the data to some datastore? +16:58 < ailouros> bar_: sharing is giving the blocks to download. publishing is letting the world know what you share +16:58 < ailouros> publishing is a subset of sharing +16:58 < bar_> aha, gotcha, thanks +16:58 < ailouros> for example, if you have half of a file, you share it but don't publish it +16:59 < jrandom> how would people know they ould get those blocks from you then? +16:59 < ailouros> and you have full control over which files you publish (unlike emule where every downloaded file is published) +16:59 < ailouros> because each client periodically sends information to the network about which blocks he has to offer +17:00 < jrandom> coo' +17:00 < ailouros> sends to the network as in server (as is now) or DHT (future) +17:00 < jrandom> so its mnet-esque, with a block tracker +17:00 < ailouros> err mnet-esque? +17:01 < jrandom> similar to how mnet (mnetproject.org) works +17:01 * ailouros is reading mnetproject.org +17:02 < ailouros> well, you have just your personal spaces, no shared spaces +17:02 < ailouros> and you don't PUSH blocks around +17:02 < jrandom> yeah, its not exactly the same as mnet, but it similar structurally +17:03 < jrandom> its like mnet where everyone is too broke to have anyone host their data ;) +17:03 < ailouros> yep +17:03 < ailouros> :D +17:03 < jrandom> ok, anyone else have anything else to bring up? +17:04 < jrandom> if not... +17:04 * jrandom winds up +17:04 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/159.rst b/i2p2www/meetings/logs/159.rst new file mode 100644 index 00000000..87edaf81 --- /dev/null +++ b/i2p2www/meetings/logs/159.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 6, 2005 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/160.log b/i2p2www/meetings/logs/160.log new file mode 100644 index 00000000..f4b2618a --- /dev/null +++ b/i2p2www/meetings/logs/160.log @@ -0,0 +1,49 @@ +15:15 < jrandom> 0) hi +15:15 < jrandom> 1) Net status and load testing +15:15 < jrandom> 2) I2PSnark +15:15 < jrandom> 3) Syndie +15:15 < jrandom> 4) ??? +15:15 < jrandom> 0) hi +15:15 * jrandom waves +15:15 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-December/001239.html +15:15 < jrandom> (*before* the meeting this week - who woulda thunk it?) +15:16 < jrandom> not that it matters, since y'all wait until the meeting starts to read it anyway ;) +15:16 < jrandom> so, movin' on in to 1) Net status and load testing +15:16 <@cervantes> hey! +15:17 < jrandom> thanks for doing your part cervantes ;) +15:17 <@cervantes> read what? +15:17 -!- DreamTheaterFan [anonymous@irc2p] has quit [Connection reset by peer] +15:17 < jrandom> I don't have much to add beyond whats in the mail, anyone have any questions or comments on 1)? +15:19 < spaetz> is load testing performed on *the* i2p net or do you have a private net for this? +15:19 < jrandom> I'm doing it on the live net +15:19 < spaetz> just curious +15:19 < spaetz> k +15:20 < jrandom> its being done carefully though, backing off hard from peers under load, and it of course honors tunnel rejections +15:20 <@cervantes> recent irc2p instability was unrelated to the tests +15:21 <@cervantes> (in case you were wondering) +15:21 < jrandom> hows the new setup handling things cervantes? +15:21 <@cervantes> been rock solid so far +15:22 < jrandom> cool +15:22 <@cervantes> just took some tedium to track down the source of the gremlins +15:24 < jrandom> ok, anyone else have any questions/omments, or shall we jump on over to 2) I2PSnark? +15:25 < jrandom> consider us jumped +15:26 < jrandom> ok, basically I2PSnark should work again... there were a few attributes not yet in the BT spec but used by azureus and rufus, causing incompatibility, but we're now compatible with the situations I was able to see +15:26 < jrandom> i2psnark now works with all of the torrents i've tested, but if anyone runs into trouble, let me know +15:27 < jrandom> part of the drive for me to fix that up was in relation to some SAM bugs, since I2PSnark doesn't use SAM +15:28 < jrandom> not much more to add on that front... unless anyone has any questions, lets move on over to 3) Syndie +15:29 -!- Xunk [Xunk@irc2p] has quit [Connection reset by peer] +15:30 < jrandom> ok, I don't have much to add beyond the email on that front either +15:31 -!- Xunk [Xunk@irc2p] has joined #i2p +15:31 < jrandom> if there aren't any questions re: Syndie, lets continue on and open the floor with 4) ??? +15:31 -!- DreamTheaterFan [anonymous@irc2p] has joined #i2p +15:32 * jrandom remembers that clunk wasn't in the agenda, among other things. anyone have anything they want to bring up? +15:32 <@cervantes> man speeding though +15:32 <@cervantes> *through +15:33 -!- bar [bar@irc2p] has quit [Connection reset by peer] +15:33 < jrandom> aye, no need to talk just to see words on the meeting logs :) +15:33 -!- bar [bar@irc2p] has joined #i2p +15:33 -!- mode/#i2p [+v bar] by chanserv +15:33 -!- mule [mule@irc2p] has joined #i2p +15:35 < jrandom> ok, if there's nothing else... +15:35 * jrandom winds up +15:35 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/160.rst b/i2p2www/meetings/logs/160.rst new file mode 100644 index 00000000..15d22637 --- /dev/null +++ b/i2p2www/meetings/logs/160.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 13, 2005 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/161.log b/i2p2www/meetings/logs/161.log new file mode 100644 index 00000000..76379d8e --- /dev/null +++ b/i2p2www/meetings/logs/161.log @@ -0,0 +1,116 @@ +15:20 < jrandom> 0) hi +15:20 < jrandom> 1) Net status +15:20 < jrandom> 2) I2PSnark updates +15:20 < jrandom> 3) Syndie blog UI +15:20 < jrandom> 4) ??? +15:20 < jrandom> 0) hi +15:20 * jrandom waves +15:20 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001240.html +15:22 < jrandom> ok, jumping on in to 1) Net status +15:22 < jrandom> I don't have much to add beyond whats in the status notes. +15:22 <+Complication> If it weren't for the occasional OOM's, I'd dare call it good +15:22 < jrandom> the load testing is looking quite promising, suggesting that we have a lot of room to improve performance +15:23 <+Complication> And I guess the OOM +15:23 < jrandom> heh, i2psnark related OOMs? or from before that? +15:23 <+Complication> 's contribute to flakyness, when either i2p-bt, i2psnark, or i2p-rufus instances do... things. +15:24 < zzz> my theory is that increased torrent traffic is somewhat hurting IRC reliability +15:24 <+Complication> (perhaps I shouldn't be calling the SAM oddity an OOM, since I've not looked at it closely, but it's one of the factors definitely) +15:24 < jrandom> hmm, I'm not sure, as the irc status was similar to before the latest snark updates +15:25 <+Complication> Bandwidth has been solid, part. tunnels solid too... just crashing now and then +15:26 < zzz> In any case I'm optimistic the tunnel build fixes coming in 0.6.1.8 will improve people's IRC experience +15:26 <+Complication> For known reasons, which hopefully go away when their time comes :) +15:26 < jrandom> aye, I think so too zzz, so we'll probably have a release in the next day or so +15:26 <+legion> Well irc might just be too sensitive, maybe just using something like jabber would be better? +15:26 < zzz> especially for people on slower machines and/or connections +15:27 < jrandom> jabber would not change things +15:27 <+Complication> Especially with tunnel redundancy at 2 +15:28 <+bar> i'd say irc is an excellent crap-o-meter for determining the network weather +15:28 <+legion> Yeah, the wind just blows a little and irc craps out +15:28 <+bar> exactly :) +15:28 <+Complication> I notice that after the shitlisting fix, "Recent" tends to always exceed "Known" +15:29 <+Complication> Would this be because "Known" doesn't include shitlisted peers, while "Recent" does? +15:29 < jrandom> aye, irc is a good view on things, as its shown substantial variation on different users (e.g. dreamtheaterfan always has trouble, etc) +15:30 < jrandom> hmm, that makes sense Complication +15:30 <+Complication> (I'm not sure if it does, just guessing) +15:30 < jrandom> (as shitlisted peers are dropped from the netDb, but their profiles are not removed) +15:32 <+Complication> Then the indicators seem OK (just wanted to ask in case they wouldn't) +15:33 < jrandom> ok, anything else on 1) Net status? +15:33 < jrandom> if not, lets move on over to 2) I2PSnark updates +15:33 < tealc_> what sort of updates are available? +15:34 < jrandom> see http://dev.i2p.net/pipermail/i2p/2005-December/001240.html for a brief listing ;) +15:34 < jrandom> basically I2PSnark can now handle multiple torrents at once over a single I2P destination, has a web interface, and is built into the router console +15:35 < tealc_> i'm running of the latest cvs builds and i2psnark is causing a lot of memory heap errors or whatever +15:35 <+Complication> ...and it also handles Azureus-created torrents with odd meta-tags. +15:35 <+Complication> Which it previously got stuck on. +15:35 < jrandom> ah, yeah, there are still some things I'm debugging in there tealc_ +15:35 < jrandom> (as mentioned in the weekly status notes ;) +15:35 < jrandom> ah right Complication +15:36 < jrandom> oh, also, the Azureus folks have fixed a bug in their tracker that would keep I2PSnark from using it +15:36 < jrandom> (so people running azureus trackers prior to B16 should upgrade at their earliest convenience) +15:37 <+bar> i'd like to have the possibility to easily disable the i2psnark autostart (for low bw scenarios, etc.) +15:38 < jrandom> that should be easy enough to add in +15:38 <+bar> sounds great +15:39 < jrandom> ok, anything else on 2) I2PSnark updates? +15:40 < jrandom> if not, lets move on to 3) Syndie blog UI +15:40 < zzz> two thumbs up on the new i2psnark - good job +15:41 < jrandom> gracias, mjw did the hard work, making snark so easy to extend +15:41 < jrandom> ok, as mentioned in the status notes, syndie now has a new blog UI +15:42 < jrandom> I think it'll offer a balance between whitelists and blacklists, dealing with the different spam issues available to people +15:43 < jrandom> we'll have that rolled out in the next release, so y'all can dig in to it in a day or two +15:43 <+legion> Is spam really going to become much of a problem anytime soon? +15:44 <+Complication> legion: as someone was kindly willing to demonstrate, it could be +15:44 < jrandom> nah, blacklists take care of authors who flood, and whitelists take care of spammers who create lots of authors +15:44 < dust> (anonymity brings out the worst in a some people) +15:44 < jrandom> (so spamming is not a problem) +15:45 <+Complication> (Although I think the fellow was regenerating keys to avoid perma-blacklisting, which *is* somewhat of a slow-down.) +15:45 <+Complication> Although not a big slow-down, and thus I whole-heartedly agree that whitelists are good too. :) +15:46 <+bar> perhaps some hashcash solution could be feasible down the road, if necessary +15:46 < jrandom> if necessary, but I don't see why it would be +15:46 <+bar> agree, right now, i don't either +15:46 <+Complication> bar: like "don't show unless they've bothered to crunch some numbers"? +15:47 <+bar> yes, something along that line +15:47 <+Complication> Sounds possible, even if probably needless. +15:47 <+bar> probably so. +15:47 < jrandom> if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog +15:47 <+Complication> Or more like, hopefully needless. +15:48 <+Complication> Might be good to consider if Syndie can accommodate such functionality, should need ever arise. +15:49 < jrandom> aye, it can, with headers in the blog post or in the blog's own metainfo +15:49 < jrandom> er, metadata (damn you bt!) +15:51 < jrandom> ok, if there's nothing else on 3) Syndie, lets jump on to 4) ??? +15:51 < jrandom> anyone have anything else they want to bring up for the meeting? +15:51 <+legion> yes a couple things +15:52 <+legion> first clunk +15:52 < jrandom> cool, yeah clunk sounds interesting +15:52 <+legion> As I mentioned earlier today in i2p-chat, I've been working on getting it to compile with cygwin and or mingw. +15:53 <+legion> So far just the client is broken, the rest including the server compiles and seems to work +15:53 < jrandom> neat +15:54 < tealc_> i2p could prove to be a real hairball for George Bush's limitless surveillance program. I'll see you guys in the death camps, bring the cards ya +15:54 <+legion> Been trying to not only track down why the client is broken, but also resolve it. At the moment I'm stuck. +15:56 <+legion> The other thing I was meaning to discuss, was could a default tunnel to my jabber server be included in the next update? Just to make things easier for anyone that wants to try out jabber. +15:57 < tethra> 20:34:37 <jrandom> if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog <--- perhaps something to the effect of polecat's way of combining trust could play a role in this? (ie to both block spammers -and- promote popular authors.) +15:57 < tethra> </$0.02> +15:58 <+polecat> That would be a primitive example of my trust network idea, with a heuristic of 100% trust transfer, yes. +15:58 < jrandom> legion: hmm, adding a disabled config is easy enough for new users, but the hesitancy I have is regarding protocol filtering (and what clients leak what info). what is your experience with different clients? +15:59 < jrandom> aye, there is a lot of room for integration of trust metrics into syndie +16:01 <+legion> Well far as I know jeti doesn't leak, other than its filetransfer, which is disabled in my server settings anyways. Possibly the next jeti version will have it corrected. Other than that I don't know about the other clients. +16:02 <+legion> I do know for sure the groupchat is solid, regardless of clients, it is just contact outside of the groupchat which some clients might leak, though I'm not sure. +16:03 < jrandom> hmm, leaking isn't really a boolean, its a matter of /what information/ the clients leak, not whether they leak any information +16:04 <+legion> Right, I was of course referring to any critical information like ip addresses, though good clients should if they do leak that information only report it as 127.0.0.1 or localhost +16:06 <+legion> So I would recommend only using known clients which don't leak, such as jeti. +16:07 < zzz> could you add a verified-doesn't-leak column to your client chart? +16:07 < jrandom> it'd be useful if you could doc up what jeti does and does not leak (along the lines of what postman put together for the smtp and pop proxy) +16:08 <+legion> According to jeti's developer it does not leak anything that would comprimise ones anonymity. That much is certain without a doubt. I've also looked through its source and have not found anything which would make me think otherwise. +16:09 < jrandom> that the developer said it may be certain, but what the developer understands about anonymity is another question ;) +16:09 <+legion> Yeah zzz I could add another such column +16:09 < jrandom> I don't doubt the possibility that jeti behaves properly, but we need to know what that means +16:10 < zzz> seems like non-leakage can only be verified by protocol tracing +16:10 < zzz> not by looking at source or asking developer +16:12 < jrandom> ok, does anyone have anything else for the meeting? +16:12 <+bar> just a reminder not to forget amd64 jbigi +16:13 <+bar> (but i bet it's on your todo list) +16:13 < jrandom> aye :) +16:13 < jrandom> (win amd64, that is, linux amd64 is already working) +16:13 < jrandom> but, if there's nothing else... +16:14 * jrandom winds up +16:14 <+bar> yes, win amd64. +16:14 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/161.rst b/i2p2www/meetings/logs/161.rst new file mode 100644 index 00000000..f05320a4 --- /dev/null +++ b/i2p2www/meetings/logs/161.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 20, 2005 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/162.log b/i2p2www/meetings/logs/162.log new file mode 100644 index 00000000..0b008445 --- /dev/null +++ b/i2p2www/meetings/logs/162.log @@ -0,0 +1,87 @@ +15:22 < jrandom> 0) hi +15:22 < jrandom> 1) Net status and 0.6.1.8 +15:22 < jrandom> 2) Load testing results and peer profiling +15:22 <@cervantes> jrandom: arguably the slowest most horrific punishment since they banned stoning +15:22 < jrandom> 3) 2005 review / 2006 preview / ??? +15:22 < jrandom> 0) hi +15:22 < gott> falafel +15:22 < gott> n : small croquette of mashed chick peas or fava beans seasoned +15:22 < gott> with sesame seeds +15:22 <@cervantes> hullo +15:22 * jrandom waves after recovering from the falafel pelting +15:22 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001246.html +15:23 < jrandom> as I'm 10m late, I'm sure y'all have already read those notes and have comments ready +15:23 < jrandom> *cough* +15:23 < jrandom> ok, lets jump on in to 1) net status and 0.6.1.8 +15:24 <@cervantes> ie. it works well, except protocol is slowing it down +15:24 < jrandom> I don't have much to add beyond whats in the mail - we had 0.6.1.8 cooking for a while before the release, and its gone pretty well from what I can tell +15:25 < jrandom> heh yeah, I'm not sure if infoshop has posted anything since the last rss import +15:25 < JosephLeBlanc> Hmm, well I have just a couple of comments. +15:25 <+Complication> With regard to status, though I've mentioned before... after build -7 got into CVS, my Celeron 300 seems to behave like an actual computer. It like, transfers data with a resemblance of stability. +15:26 <+Complication> Lets me extensively browse eepsites, and only rarely kicks me from IRC. +15:26 < jrandom> word Complication +15:26 < jrandom> whats up JosephLeBlanc +15:26 <@cervantes> /kick complication +15:26 <@cervantes> doh +15:26 < JosephLeBlanc> I am running the latest CVS and, afaics, most things are in order. +15:27 < JosephLeBlanc> However, I was wondering if that jbigi athlon problem was fixed which I talked to you about some time ago. +15:28 < jrandom> jbigi for amd64 on window isn't yet in jbigi.jar, though I hope to get it into 0.6.1.9 +15:29 <+Complication> I *think* (but can't confirm) that it's focusing more tightly on peers it has seen success with... and this approach *may* keeps those paths from collapsing more effectively (it's behind a somewhat too agressive NAT). +15:29 < JosephLeBlanc> Well, the logs are returning: 'NOTICE: Resource name [jbigi] was not found' +15:30 < jrandom> JosephLeBlanc: there is a line after that regarding jbigi - what does it say? +15:31 < JosephLeBlanc> It reads, "INFO: Optimized native BigInteger library 'libjbigi-linux-athlon.so' loaded from resource +15:31 < jrandom> ok great +15:32 < JosephLeBlanc> Just wanted to give you a heads up about that NOTICE line. +15:32 < jrandom> that means it first tries to pull the resource "jbigi", but it doesn't exist (which is normal - the jbigi resource is for very rare situations) +15:32 < jrandom> it then tries to pull the OS/architecture specific resource "libjbigi-linux-athlon.so" and succeeds +15:33 < JosephLeBlanc> Ah, okay. Then, it seems that whatever bug I was experiencing earlier has been fixed in -7 +15:33 < jrandom> w3wt +15:33 < JosephLeBlanc> Thanks a billion, bud. +15:34 < jrandom> np +15:34 < jrandom> Complication: aye, I think you're right, and some of the strategies for 0.6.2 will build on that concept further +15:35 < jrandom> ok, anyone else have something for 1) net status / 0.6.1.8? +15:37 < jrandom> if not, lets move on to 2) Load testing results and peer profiling +15:39 < jrandom> ok, lots of stuff in the email, does anyone have any questions on it? +15:40 <+bar> how big was the resonable improvement? +15:41 <+Complication> Late remark about 0.6.1.8 (just tested with my laptop) - jbigi was loaded correctly there too. +15:42 <+Complication> Previously, this machine (Mandriva 2005) was failing to load the correct one. +15:42 <+Complication> Due to the jcpuid problem. +15:42 < jrandom> I'd rather not quote a number in the meeting, as it'll affect people's expectations. measureable improvement, but nowhere near wire speed. +15:43 < jrandom> (and the load test is a bit contrived) +15:43 <+bar> alrighty np :) +15:44 < jrandom> cool complication. Yeah, I finally bundled up scintilla's C jcpuid port :) +15:45 < jrandom> ok, I don't have much to add on 2) beyond whats in the mail. More info on the resulting speed profiling will come out once its shipped in 0.6.1.9. +15:47 < jrandom> if there's nothing else on that, jumping on to 3) 2005 review / 2006 preview / ??? +15:49 <+bar> i agree with what's in the mail, 2005 was a fantastic year and i can't see 2006 becoming any worse, i2p wise +15:49 < jrandom> we've come a long way in the last year, and y'all have done lots of great work pushing us forward. this coming year looks to be the big one for us, moving out of the geeky backrooms and into the venues where it matters. +15:50 * tethra came in towards the wrong end of 2005, but it was still pretty damn cool. *thumbs up* +15:51 <+Complication> Hoping for the best. +15:51 < jrandom> I don't have much more to add, so if there's other stuff that people want to bring up for the meeting, the floor is open +15:52 <+Complication> Speaking of which, if someone wanted to translate some docs into Spanish (see Discussion forum), whom would it be best for them to coordinate with? +15:52 <+Complication> e.g. which parts are liable to change heavily, or such matters +15:53 <+Complication> Also, in which format would it be best to have various docs? +15:54 < jrandom> the tech intro doc @ dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD is fairly stable +15:54 <+Complication> Included with the router... on the website... both? +15:54 < jrandom> (there will be updates on 0.6.2 though) +15:54 < jrandom> well, I'm hugely in favor of inline documentation +15:54 < jrandom> but that should probably wait until the new router console is in place +15:55 < jrandom> website intro docs would be good as well, but that should probably wait until the new website is in place +15:55 <+Complication> Aha... so it would be best to not touch that yet... +15:56 <+Complication> ...instead preferring docs like the above. +15:58 < jrandom> probably. ok, is there anything else people want to bring up for the meeting? +15:59 < jrandom> if not... +15:59 < tethra> did we discuss the eepget UI idea yet? +15:59 < gott> If the meeting is still on, please fix the trouble with accents in IRCclient +15:59 < tethra> ie, before i got here +15:59 < jrandom> nope, wanna implement it tethra? :) +15:59 < jrandom> gott: patches welcome +16:00 < gott> If not, please fix the trouble with accents in IRCclient. +16:00 < gott> jrandom: By the time, I fix it, it will be fixed by somebody else ;-) +16:01 < tethra> jrandom: i'm not entirely sure how to go about it, as i'm not much a coder. if you feel like pointing me at any tutorials in writing .war type apps and i'll be glad to have a shot, though. +16:01 < gott> I reserve the right to be defeatist in deed and action. +16:01 < tethra> haha +16:01 <+Complication> :) +16:02 < jrandom> tethra: the oreily servlets books are pretty good +16:02 < jrandom> ok, if there's nothing else... +16:02 * jrandom winds up +16:02 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/162.rst b/i2p2www/meetings/logs/162.rst new file mode 100644 index 00000000..b4ec2c35 --- /dev/null +++ b/i2p2www/meetings/logs/162.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 4, 2006 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/163.log b/i2p2www/meetings/logs/163.log new file mode 100644 index 00000000..c3c1ed4d --- /dev/null +++ b/i2p2www/meetings/logs/163.log @@ -0,0 +1,170 @@ +15:26 < jrandom> 0) hi +15:26 < jrandom> 1) Net status +15:26 < jrandom> 2) Throughput profiling +15:26 < jrandom> 3) Syndie blogs +15:26 < jrandom> 4) HTTP persistent connections +15:26 < jrandom> 5) I2Phex gwebcache +15:26 < jrandom> 6) ??? +15:26 * jrandom waves +15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001247.html +15:27 < jrandom> (yeah, I know... we need a 7) One more thing...) +15:28 < jrandom> jumping on in to 1) Net status +15:28 < jrandom> In general, seems the same ol' same ol', beyond whats in the mail. +15:28 < jrandom> Anyone have anything they want to bring up about 1)? +15:30 < jrandom> ok, if not, moving on over to 2) Throughput profiling +15:31 < tethra> it sounds cool, but may i ask what the objective is? +15:31 < jrandom> find fast peers +15:31 < tethra> (forgive my lack of wit and tact) +15:31 < tethra> ah, cool. +15:32 < jrandom> basically, our old speed profiling wasn't that great (see last week's status notes for a summary), and this seems to be pretty good at finding peers that I know are fast +15:32 < jrandom> (I know they're fast because I've cheated and measured them with non-anonymous techniques) +15:33 < tethra> shocking! ;) +15:33 < jrandom> ((yes, someone could have been crazy and mounted attacks to confuse my measurements, but, well, I doubt it ;) +15:33 < tethra> haha +15:33 < tethra> sweet, so that should make client tunnels more likely to find a 'good' peer and presumably put the 'fast' peers under less pressure, then? +15:35 < tethra> s/'good'/fast/ +15:35 < jrandom> yes to the former, but not really to the later - it won't reduce the pressure on them, but it will let people make more effective use of them +15:35 <@cervantes> I guess the folks with fast peers will have to hope the peer throttling is good enough to take the extra participation +15:36 < jrandom> e.g. rather than having $slow-->$fast-->$fast, it'll have $fast-->$fast-->$fast +15:36 < tethra> ah, i see +15:36 < jrandom> aye cervantes, I've been paying attention to the capacity profile as well, and its been doing the trick +15:36 <@cervantes> grand +15:37 < jrandom> the interplay between capacity and speed is important - peers are not considered fast if they are not high capacity, even if their speed is ranked higher than everyone else +15:37 <@cervantes> be interesting to see how it effects througput +15:37 < jrandom> (which is why 'fast' is just shorthand for 'fast and high capacity') +15:37 <@cervantes> +h +15:37 < jrandom> aye cervantes +15:39 < jrandom> ok, if there's nothing else on 2, lets jump on over to 3) Syndie blogs +15:40 < jrandom> I don't have much more to add beyond whats in the mail there +15:41 <@cervantes> it's looking swell +15:41 < tethra> i very much like where the blogs are going, personally. it seems to all be gravy, one might say. +15:41 < tethra> :D +15:41 <+Complication> Bit late, sorry. +15:42 < jrandom> cool, its similar to how it was originally, but I think the blog view has some promise +15:42 < jrandom> wb Complication, no worry, we've got logs :) +15:43 <+Complication> Reading scrollback right now :) +15:43 < jrandom> I do think there's a place for both views, I suppose it just depends on the user +15:43 < jrandom> (and the content, and the author) +15:45 < jrandom> one thing though is that the html aint that grand. cervantes has been helping me revamp my very basic education to a more modern view, but there are lots of issues left +15:46 < jrandom> there will be continuing improvements to syndie's web interface, and if some html volunteer wanted to help out with formatting, design, css, cross browser issues, etc, it would be much appreciated +15:47 <@cervantes> other than having 2 opening <style> tags the code looks pretty clean ;-) +15:47 < jrandom> heh oops +15:48 <@cervantes> I think the emphasis will be on getting the styling clean and readable and perhaps designing some template alternatives +15:48 < jrandom> hmm +15:49 < jrandom> thats one thing I was thinking about for the blog view - it'd be easy to let people customize certain attributes (colors, fonts, sizes), but I'm not sure how much more +15:50 < jrandom> otoh, the blog view, like the thread view, is all just a template over the syndie archive +15:50 <@cervantes> well you certainly don't want to allow deployable templates +15:50 < jrandom> so the question is, a template for whom? +15:50 < jrandom> (what level of experience would those using the template require) +15:51 <@cervantes> I was thinking just a popup config option someone can choose for their blog +15:51 < jrandom> hmm? +15:51 <@cervantes> I want "Pony Look" +15:51 < jrandom> ah, ok +15:51 <@cervantes> so we ship syndie with a variety of skins +15:52 < jrandom> yeah, preset colors/font/etc +15:52 < jrandom> (and icons, etc) +15:52 < jrandom> thats one thing that hasn't really been implemented through the blog view yet +15:54 < jrandom> good idea on the simple theme chooser though, rather than some complex set of options +15:54 <@cervantes> an alternative would be someone can offer their own template presets as a download on their site - which could be saved into a theme folder +15:55 <@cervantes> it's up to the individual if they want to trust the blog author's custom skin +15:55 < jrandom> ... trust? +15:55 < jrandom> nothing in syndie will let you do unsafe html or css +15:55 < tethra> what of unsafe javascript/etc +15:55 < jrandom> the skins would be text files/config files/images, rather than jsp +15:55 < tethra> ? +15:56 < tethra> (page forwards to non-anonymous addresses with js, for instance?) +15:56 <@cervantes> it depends if a theme might also contain structural html changes +15:56 <@cervantes> right ok +15:56 <@cervantes> well that would keep it nice an clean and simple +15:57 < jrandom> tethra: I'm... incredibly hesitant about javascript. seen that new blog post today from default? +15:57 < jrandom> "I'm just curious: does it use AJAX? The page doesn't seem to update as a whole..." +15:57 < tethra> nein, i did not. +15:57 < tethra> i'd find a way to just shag any js that is used, personally. +15:58 < jrandom> since syndie is *local*, its insanely fast, and we don't need do worry about the same latency issues +15:58 < tethra> as i don't trust it as far as i can throw it. +15:58 < tethra> hmm :/ +15:58 < jrandom> cervantes: aye, very simple - we could even do things like let people viewing a blog theme they like say "steal this theme" +15:59 <@cervantes> in theory you could provide a library of "safe" functions fo blog user - but by the time you remove everything that is unsafe from the average browser's implementation you're left with the "alert();" function +16:00 < jrandom> heh +16:00 < jrandom> (and you've got all those accessibility issues of javascript) +16:00 <+Complication> cervantes: mind you, alert() in an infinite loop can be bad :P +16:00 * jrandom is quite proud of syndie's lynx-friendliness +16:00 < tethra> lynx <3 +16:02 < jrandom> ok, if there's nothing else on 3), lets jump on over to 4) HTTP persistent connections +16:02 < jrandom> I don't have anything to add beyond whats in the mail... zzz, you here? +16:02 <@cervantes> there are other ways of implementing a *spit* AJAX ui, like a mozilla extension +16:03 < jrandom> fire2pe++ :) +16:03 < jrandom> zzz doesn't seem to be around, so we'll probably have to wait for later for more info on 4) +16:03 <@cervantes> fire2pe is just a helper - syndilla is what you mean ;-) +16:03 < jrandom> lol +16:04 < jrandom> (and, the usb keychain version, syndog ;) +16:04 < jrandom> ok, moving on to 5) I2Phex gwebcache +16:05 < jrandom> Complication: p1ng +16:05 <+Complication> Well, since it would make integrating with the net easier... +16:06 <+Complication> ...I've recently worked on reviving the gwebcache code already in I2Phex +16:06 <+Complication> It's already doing some very limited things (like crash neatly) at this stage :) +16:06 <+Complication> Also pesters awup's webcache server with moderate success +16:07 < jrandom> lol nice +16:07 <+Complication> I have hope though, that eventually I'll get it reworked +16:07 <+Complication> (lots of it is currently meant to deal with IP addresses) +16:09 < jrandom> cool, good luck, and lemmie know if there's anything I can do to help +16:09 <+Complication> Will do :) +16:10 < jrandom> ok, anything else on 5) I2Phex gwebcache, or shall we mosey on over to 6) ??? +16:11 < jrandom> consider us moseyed +16:11 < jrandom> anyone have anything else for the meeting? +16:11 <@cervantes> another cup of tea would be nice +16:12 < tethra> heheh +16:12 < Pseudonym> how's the roadmap? +16:12 < jrandom> no changes +16:12 < Pseudonym> what's left for 0.6.2? +16:13 < jrandom> all of the 0.6.2-related stuff +16:13 * jrandom ducks +16:14 < Pseudonym> :-P +16:14 <@cervantes> some bling bling +16:14 < Pseudonym> do we have a tentative date/timeline? +16:14 < jrandom> specifically, the new tunnel creation crypto and algorithms, the new peer selection strategies +16:14 < tethra> heheh +16:14 < jrandom> no dates and timelines (at least, not announced in meetings ;) +16:15 < Pseudonym> is there more to peer selection strategies than the throughput stuff you've been working on? +16:16 < jrandom> yes, these peer profiling changes are performance issues, not the anonymity related peer selection and ordering strategies +16:16 <+Complication> jrandom: do I remember correct... if I guess the tunnel creation crypto related to things discussed on the mailing list, during the talk about predecessor (and other) attacks? +16:17 < jrandom> yeah Complication +16:17 <+Complication> s/related/relates +16:19 <+Complication> You're going to try making that fancy lil' datastructure work? +16:19 < jrandom> aye +16:20 < jrandom> (hence, 0.6.2 is not on the 2 week horizon ;) +16:20 <+Complication> Neat. Sounds interesting, I should probably read up about it +16:21 <+Complication> I hope it goes smoothly +16:21 < jrandom> it was only arm-waved around on the list, no spec digitized yet +16:21 < tethra> which neat datastructure is this, sorry? +16:21 <+Complication> Oh, and figured why the link (from the "moo" message) wouldn't work. :D It's freedomarchives.i2p (in the plural, with an "s" at end) +16:21 < jrandom> it'll be backwards incompatible, so smooth won't be its catchphrase, but hopefully won't hurt too much :) +16:21 < jrandom> ah bugger +16:22 < jrandom> tethra: a datastructure that doesn't exist yet for creating tunnels +16:22 < tethra> cool +16:22 < jrandom> (see the predecessor threads from november or so) +16:23 < tethra> what advantages/disadvantages will it have over the current one? (if there is a current one :o) +16:23 < jrandom> (see the predecessor threads from november or so) ;) +16:23 < tethra> ah, ok +16:23 <+Complication> IIRC, to make tunnel creation less transparent to observers +16:23 < tethra> "" +16:23 < tethra> ;) +16:23 < jrandom> but, its not a proposal, there is nothing on the table for 0.6.2 until all of the things prior to 0.6.2 are sorted. +16:23 < jrandom> once the things that should be working are working in the manner that we need them to work, then we move on. +16:24 < Pseudonym> other than fast peer selection, what's not working? +16:25 < jrandom> fast peer selection is a part of "good performance" +16:25 < jrandom> we /do/ have good performance, for an anonymous network, but not good enough to compete with non-anonymous networks +16:25 < jrandom> to compete, we've got to get better performance *and* provide functionality they can't get elsewhere +16:26 < jrandom> (anonymity does not sell) +16:26 < Pseudonym> is there more to it than fast peer selection? +16:27 < jrandom> through the last month or two, benchmarking different aspects of i2p, slow peer selection seems to be the smallest bottleneck. what the next bottleneck will be is unknown. +16:27 < jrandom> (there have also been countless improvements at different points to improve performance) +16:27 < jrandom> (see http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD ) +16:28 < Pseudonym> so... release of new peer selection this week? ;-) +16:28 < teal`c_> i2p feels good +16:29 < jrandom> Pseudonym: aye, new peer profile algorithm is in cvs and will be deployed this week with 0.6.1.9 +16:30 < jrandom> ok, anyone have anything else for the meeting? +16:30 < Pseudonym> cool +16:31 < jrandom> if not... +16:31 * jrandom winds up +16:32 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/163.rst b/i2p2www/meetings/logs/163.rst new file mode 100644 index 00000000..2cc58e02 --- /dev/null +++ b/i2p2www/meetings/logs/163.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 10, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/164.log b/i2p2www/meetings/logs/164.log new file mode 100644 index 00000000..5be0b576 --- /dev/null +++ b/i2p2www/meetings/logs/164.log @@ -0,0 +1,261 @@ +15:40 < jrandom> 0) hi +15:40 < jrandom> 1) Net status and 0.6.1.9 +15:40 < jrandom> 2) Tunnel creation crypto +15:40 < jrandom> 3) Syndie blogs +15:40 < jrandom> 4) ??? +15:40 < jrandom> 0) hi +15:40 * jrandom waves +15:40 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html +15:41 <@cervantes> pfff, good job i2p is more reliable than NASA +15:41 < jrandom> heh +15:41 < tethra> haha +15:41 < jrandom> (though I am 20 minutes late... ;) +15:41 < jrandom> anyway, lets jump on in to 1) Net status and 0.6.1.9 +15:42 < wmpq> NSA or NASA, not that diffrent are they? +15:42 <@cervantes> I said I2P not jrandom ;-) +15:42 < jrandom> good point cervantes ;) +15:42 < tethra> don't be silly, jrandom IS i2p! ;D +15:42 <@cervantes> oh I thought it was a way of thinking +15:42 < wmpq> [redact] +15:43 < jrandom> heh well, anyway, 0.6.1.9 is out and about, with 70% of the net upgraded (thanks y'all) +15:43 < Pseudonym> mmmm, tasty new release +15:44 <+zzz> client tunnel build success remains < 30% +15:44 < jrandom> I haven't heard many reports of substantially increased end to end throughput, though some routers are more than saturating T1 lines +15:44 <+zzz> down from ~40% +15:44 <+Complication> Bandwidth seems normal, a bit higher than on the last CVS before release. Peer counts look a big higher. +15:45 < jrandom> hmm, yeah, I'm not really worried about that zzz, since its all getting completely reworked for 0.6.2 +15:45 <+zzz> avg BW up from ~12K to ~20K +15:45 < jrandom> 0.6.1.9 shouldn't pick peers more liable to agree (meaning, high capacity), but should instead focus on those who have higher throughput +15:46 <+Complication> Retransmission percentage (noted 7% on the night of release) has come down to 6 point something +15:46 < jrandom> aye, with routers pushing 1-300KBps, there's going to be a skew +15:46 < jrandom> hmm, thats a pretty crazy rate Complication, i've only seen 2-3% +15:46 < jrandom> (but I don't doubt what you see) +15:47 <+Complication> I'm maxing out my outbound, pretty much +15:47 <+Complication> (and I mean maxing out the line capacity) +15:47 < jrandom> ah, that'd do the trick +15:47 <+zzz> still getting NULLs before gets which results in 405 bad method, rate may be declining, hard to say for sure +15:48 < jrandom> yeah zzz, there are some things that need to be worked through in the streaming lib, but I probably won't get to that until after the 0.6.2 tunnel revamps +15:48 < jrandom> (but if someone wants to dig in further before that, that would rule, of course) +15:49 < jrandom> Complication: if you reduce your bw limiter to something like 70% of your line capacity, does the failure rate go back to a reasonable value? +15:49 <+zzz> I still think it was something that went in the code just before new years, so better to look at before those recent changes are forgotten :) +15:50 <+zzz> First seen Dec. 29 +15:50 < jrandom> yeah zzz, it certainly was. likely related to how we now honor timeouts. +15:51 <+Complication> jrandom: I'm actually trying that currently :) +15:51 <+Complication> Adjusted a few seconds before you asked, but won't know very soon, I guess +15:51 < jrandom> but there is substantial work that needs to be done in there to clean it up, and its more important to get the new tunnel creation code implemented (which will substantially improve tunnel build success rates, as well as add a whole set of anonymity improvements) +15:51 < jrandom> cool Complication, yeah, give it 3-6 hours +15:51 < jrandom> (to clear out the old values / connections) +15:52 <+zzz> ~ 1% - 3% of GETs are corrupted atm +15:54 < jrandom> so do you suggest reverting the streaming lib changes (so that i2psnark will OOM all of its users in 12-48 hours) and put off further streaming lib rework until after the 0.6.2 tunnel work, or push out the 0.6.2 tunnel work for a week or two while revamping the streaming lib? +15:55 <+zzz> certainly don't revert +15:56 <+zzz> your call +15:56 <+Complication> It's a fairly sly bug, I can only say +15:58 < jrandom> there are other bugs in the streaming lib, so if I'm going to roll up my sleeves, I'd want to tackle them all together (since none of the remaining bugs are apparent). +15:59 < jrandom> on the other hand, we'll have substantial bandwidth usage reduction, increased build success percentage, better anonymity, and an improved ability to monitor load balancing on the live net by going with the tunnel work first +15:59 < Pseudonym> if it's only a 1-3% failure rate on surfing, I'd say it can wait, but that's just my opinion. +16:00 < jrandom> I'm leaning towards doing the tunnel work first, since after deploying it, we can passively monitor the network while actively revamping the streaming lib +16:01 < jrandom> (I'd also like to build a GUI for editing/posting to Syndie, but that can wait until after both of those things are sorted ;) +16:01 <+Complication> That's what the rate is like, here too +16:02 <+Complication> (on my eepsite) +16:04 < jrandom> Ok, I think it'd be great if y'all can keep an eye on things to see if those rates changes, but in the meantime, I'll continue on with the tunnel revamp, after which will come the streaming lib revamp (both of which will be in place before 0.6.2) +16:05 < jrandom> (or, if somene wants to dig into the streaming lib [or see if there's some odd interaction with i2ptunnel], lemmie know!) +16:06 <+Complication> jrandom: out of curiosity, could one exclude i2ptunnel with a test app? +16:07 <+Complication> e.g. if something like jnymo's sample app would *also* receive nulls, that would clear i2ptunnel from the list of suspected causes? +16:07 < jrandom> one could wire up a thin (in-VM) I2PSocket implementation to do that, certainly +16:07 <+Complication> Since, IIRC, that sample used the streaming lib directly... +16:08 <+Complication> (or pretty directly) +16:08 < jrandom> aye, of course if something using the streaming lib can duplicate it, it would exonerate i2ptunnel +16:10 <+Complication> Hmm, unless someone else gets first (I'll try finishing with the webcache thingy first) I might try emulating HTTP with something like that... +16:10 < jrandom> wikked, thanks Complication +16:10 < jrandom> ok, anything else on 1) Net status and 0.6.1.9? +16:11 < jrandom> if not, lets mosey on over to 2) Tunnel creation crypto +16:11 <+Complication> Nah, it may lead to nothing useful, or I may stumble on halfway... but it's a possibility which intrigues me +16:11 < jrandom> aye, definitely worth exploring Complication +16:12 < jrandom> (and explorations do not have to have positive results to be worthwhile :) +16:12 * cervantes spots a "moo" exception in the source changes leading up to new year....perhaps that's the issue? :) +16:13 < jrandom> ok, there's a new tunnel creation crypto spec referenced in the email, based on the discussion toad, Michael, and myself had on the mailing list last october +16:14 < jrandom> give 'er a look and lemmie know your thoughts - it won't be deployed on the live net for a while, as there are other things that need to be implemented first, but its coming +16:14 <+Complication> Is "moo" a reserved word for Java? ;P +16:14 <+zzz> on 2) I'll help review references in status mail +16:14 <+Complication> On the tunnel crypto subject, do you mind checking if the following rephrase is decent - I'd just like to ensure I've understood it right... +16:14 < jrandom> thanks zzz +16:15 <+Complication> "Each hop encrypts all records with their reply key, which they decrypted from their record, using their ElGamal private key, and by encrypting in such fashion, reverses one layer of decryption (or should I say, encryption) done by the tunnel owner, rendering the next participants' record readable with the next participant's ElGamal private key?" +16:15 < jrandom> Complication: yes +16:15 <+Complication> Or is my rephrase plain wrong? +16:16 <+fox> <jme___> and way to complicated, if i may +16:16 < jrandom> its correct I believe, but yeah, too many clauses :) +16:16 <+Complication> I didn't think of a better way to visualize it. 'Twas hard enough that way. :P +16:16 < jrandom> (or jme___ are you saying the algorithm is too complicated?) +16:17 <+fox> <jme___> nope i tried rapidely to read the doc and give up as too many things require prior knowledge +16:17 <+fox> <jme___> on the other hand i didnt try much :) other things to do +16:17 < jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD +16:18 <+fox> <jme___> is this peer review a formality, or you are really worried/unsure of it ? +16:19 <+Complication> Well, it's always good to know what an underlying mechanism is doing... +16:19 < jrandom> I'm confident that it does what I intend for it to do, but I am sincerely interested if someone can see a problem +16:19 <+fox> <jme___> if the second i could spend the time, but my knowledge is old and not on top of my head +16:20 <+fox> <jme___> if not i trust :) +16:20 < jrandom> the notes section has some questions - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes +16:22 < jrandom> there's no rush, it'll probably be a week or two before this new crypto is actually used in the router +16:22 <@cervantes> jrandom: on those, would there be much of a performance hit on injecting a random delay between hops? +16:22 <@cervantes> as that seems the most sensible option to prevent timing attacks +16:23 < jrandom> its tunnel creation, so a delay wouldn't hurt, though could cause premature lease set expiration under catastrophic failures +16:25 < jrandom> well, I'm not sure how effective those delays would be. they may help substantially, but they may not. live tunnels, however, can simply use blending to detect colluding peers on that tunnel anyway though, so I'm not sure it matters +16:25 <+fox> <jme___> ok rereading it +16:27 < jrandom> thanks. ok, no rush, but if/when anyone has any thoughts, bounce 'em my way (or to the list, or to your blog, etc) +16:27 < jrandom> ok, anything else on 2, or shall we move on to 3) Syndie blogs? +16:29 < jrandom> (consider us moved) +16:29 < jrandom> ok, new neat bloggy stuff in syndie, dig in ;) +16:29 <@cervantes> v.cool +16:30 < jrandom> the groups on the left can contain links to arbitrary urls, as well as links to blogs, posts within blogs, or attachments to posts within blogs +16:30 < jrandom> there are a whole slew of enhancements possible, too, such as adding per-blog or per-tag styling for posts, icons, etc. if someone wants to dig into that, it'd rule (and have a highly visible impact :) +16:31 <@cervantes> btw external links defined in comments should also have a title attribute set to the target url (as you have done on the left panel) +16:31 <@cervantes> comments/posts +16:32 < jrandom> ah, good idea +16:33 < jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer method renderLinks(...) :) +16:34 <@cervantes> *scribble* +16:35 < jrandom> what else do the syndie blogs need for them to offer a functional alternative to informational eepsites? obviously, syndie is static content, so you can't do some things, but you can publish content and let people comment +16:36 < jrandom> are there particular customizations you want to be able to do? if so, lemmie know +16:37 < DoubtfulSalmon> jrandom: updating existing content via script? +16:37 <@cervantes> archive by date +16:37 < jrandom> DoubtfulSalmon: via script? +16:37 < jrandom> cervantes: ah, like a little calendar widget, rather than the "5 older entries" links? +16:38 <@cervantes> yup +16:38 < DoubtfulSalmon> jrandom: say I want this file/text to replace that file/text. How do I do that? +16:38 < jrandom> ok cool, yeah, that should be really easy (if someone whips up the html :) +16:38 <@cervantes> or more simply "view last month's posts" +16:39 <@cervantes> jrandom: you just need a 7x6 table with some numbers in it ;-) +16:40 < jrandom> DoubtfulSalmon: changing content that has been published is an interesting direction. across the board, it wouldn't always work, since it'd have to operate like usenet control messages (cancelling an old post, etc) +16:40 < jrandom> DoubtfulSalmon: on the other hand, you can simply post a new file/entry and change the links on the left hand side to point to the new file/entry +16:40 < jrandom> (that way, the old content is still there, but people are directed to the new content) +16:41 < DoubtfulSalmon> jrandom: yeah, it would be ok if the old content was still there, as long as everyone's links pointed to the new content, without them having to change their content. +16:41 < jrandom> building a full blown wiki out of it, essentially posting diffs with syndie rendering them result, is possible, but may be overkill +16:41 < jrandom> hmm, ok I see what you're saying +16:42 < jrandom> so, you want the ability to have redirectable links, rather than the existing links to exact versions of content +16:43 < jrandom> perhaps that could be done by linking to a blog's bookmark, and the exact version is found by loading that blog's current bookmarks and seeing where it points +16:44 < jrandom> otoh, the new version could be marked as a reply to the old post, so when people follow a link, they can follow it to the reply which replaces the content +16:44 < jrandom> (though thats probably not as seamless) +16:44 < DoubtfulSalmon> yeah: say I want to have a link to say: a current radar image, or somthing like that that will be upadated every 10 min. It's ok if the contet doesn't fly all over the net, but if someone else links to my page, the user should see the current image. +16:45 < jrandom> well, that depends on what they want to do - do they want to link to the image as it was when they referred to it, or do they want to link to the service that renders the image when the reader views it +16:45 <+Complication> cervantes: oddity of the day :D Last post in: http://forum.i2p/viewtopic.php?t=1199&start=15 +16:46 <+Complication> Felt like it might be another of our robotic overlords :P +16:46 < jrandom> but its a good idea to support both concepts, and I don't think it'd be much trouble +16:46 <@cervantes> thnx +16:46 < jrandom> though it'd need a small extension to sml (e.g. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.png"]) +16:47 * cervantes will upgrade forum defenses if we start to get a lot of them +16:47 <@cervantes> (already know how to stop that one) +16:47 < DoubtfulSalmon> jrandom: they should be able to link to both a static version of it, provided the syndicator has not deleted the content, as well as a generic url that points to whatever is the latest version +16:47 < jrandom> (which would look at ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c='s current meta post for bookmarks, pulling the exact uri from the one named "radar.png") +16:48 < DoubtfulSalmon> jrandom: could that be done now with something like: "View most recent one post in tag <weird string>" +16:48 < jrandom> ah, good point - yes, it could +16:49 < jrandom> that could even be restricted to "View most recent post by $author with tag $tag" +16:49 < jrandom> (so other people couldn't spoof it) +16:49 < DoubtfulSalmon> so maybe just put some sort of UI so the user does not have to see weird tags and what not +16:50 < jrandom> there's an example of how that looks up there, though I don't have the uri offhand... but yeah, is a link around the linked text +16:50 < DoubtfulSalmon> I assume all of that information can come in URL form. +16:51 < jrandom> but this is definitely complicated to write the source SML, which is why a GUI to create SML would be useful +16:51 < jrandom> they're attributes on the SML tags, not URLs +16:52 <@cervantes> and SML gui will be tricky without javascript +16:52 < DoubtfulSalmon> but you can bookmark a search result right? +16:52 < jrandom> what is a search result? +16:52 < jrandom> and what do you mean by bookmark? +16:52 <@cervantes> (or a browser extension ;-) +16:52 < jrandom> oh, browser side bookmarks, yes +16:52 <+Complication> A filter result? +16:53 < jrandom> but those bookmarks are not generally shareable +16:53 < DoubtfulSalmon> er: a "get most resent 1 post by X with tag Y" +16:53 < jrandom> (actually, most are, but its not universal, since they're URLs not URIs)) +16:53 < DoubtfulSalmon> yeah, it would be good if other bolgs could link to those too +16:54 < jrandom> DoubtfulSalmon: they can, with sml +16:54 < jrandom> [blog tag="Y" bloghash="X"] +16:54 < DoubtfulSalmon> oh goodie +16:55 < jrandom> cervantes: javascript, or xul, or java, or some other OS-specific client app +16:57 <@cervantes> ah cool, so you don't mind a scripting or plugin dependancy +16:57 < jrandom> (when our website gets revamped for 0.6.2, syndie will definitely get a website explaining wtf this whole syndie thing is, and how it can do everything short of wash the dishes ;) +16:57 <@cervantes> (as long as it degrades gracefully) +16:57 < jrandom> cervantes: syndie should be function with lynx, but there's lots of room for rich clients +16:58 < jrandom> (s/function/functional/) +16:58 <@cervantes> right..so lynx uses would get an SML reference chart, but nothing more +16:58 < jrandom> aye, as we have now +16:58 < jrandom> though perhaps a simplified sml, dunno. +17:01 <+Complication> jrandom: do you think it might be even remotely plausible... that the null bug might be related to gzip encoding? +17:01 <+Complication> I was thinking of how to disable gzipping for my eepsite tunnel... +17:01 <+Complication> Or would that be entirely implausible? +17:01 <@cervantes> there was some http compressor stuff added just before new year in i2ptunnel +17:03 < jrandom> aye, it could - yo ucan disable it on the client side with i2ptunnel.gzip=false (on /configadvanced.jsp). atm I don't think you can disable it in i2ptunnelhttpserver though +17:03 <+zzz> it's on the request side where there isn't any compression +17:03 <+zzz> server won't compess if client set to false +17:03 <+Complication> zzz: oh, right, I forgot that +17:04 < jrandom> (but without too much trouble you could add it to I2PTunnelHTTPServer [line 310, etc) +17:04 * Complication is a fool, and apologizes for that +17:04 <@cervantes> (or you could use a normal tunnel) +17:04 <+Complication> Aha, thanks... +17:05 < jrandom> hmm, though by the time the i2ptunnelhttpserver receives the GET, the null is already there +17:05 <+zzz> yup I did get orion moved back to HTTP tunnel which greatly helps load times for his pages since now compressed again +17:05 <+Complication> I somehow entirely forgot that gzipping starts when the client and server have *agreed* to do it +17:05 < jrandom> so it may be on the client side, but definitely not the server side +17:05 < jrandom> yeah zzz, its pretty insanely fast now :) +17:05 <+zzz> its on the _request_ side not the _response_ side - could be on either client or server side +17:06 < jrandom> true +17:09 < jrandom> ok, anyone else have anything on 3) Syndie blogs? +17:09 < jrandom> if not, lets jump on to 4) ??? +17:09 < jrandom> anyone have anything else to bring up for the meeting? +17:10 < cat-a-puss> Complication: Java's gzip stream + I2P tunnels. Does NOT work and it's sun's bug +17:10 < jrandom> hmm cat-a-puss? really? +17:10 <+zzz> HTTP persistent connections update: client side mostly done, server side making good progress, lots of bulletproofing and testing to do, est. completion 2-4 wks +17:10 < jrandom> nice1 zzz! +17:11 < cat-a-puss> jrandom: yeah I talked to you about that a long time ago, I could probably find the long explination as to why, but it's probably best to just document that somewhere as there is no reason to do it. +17:12 < jrandom> hmm I'm out of context, what exactly does not work? what is sun's bug? +17:14 < dust> i get weird logs like this: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html> +17:14 < jrandom> hmm, interesting +17:15 < jrandom> what tracker? +17:15 < cat-a-puss> jrandom: As I recall sun uses headerless zips and some magic number to tell that it's a zip stream. But the number just so happens to be negitive, so if you endup creating a zip stream within a zip stream for some reason, it reads the data out of the stream as a sequence of unsigned bytes and so the magic number gets converted to some other positive number. (I am probably missing some detail but that is the gist of it) +17:16 < dust> for example the OSDevWithCVS_3E.pdf.torrent +17:17 < dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ... +17:17 < jrandom> hmm, I don't know anything about that, and I'm not sure how it'd affect gzip stream over i2ptunnel (if it /did/, they'd all fail, because we gzip evertthing) +17:19 < jrandom> ok cool dust, so postman's tracker. hmm, are you on 0.6.1.9 dust? +17:20 < cat-a-puss> jrandom: yeah it's been almost a year now sense I had that problem so I don't remember too well, and I don't know if it is fixed in 1.5 but I did have a reall devil of a time trying to figure out why every normal type of stream would work, but as soon as I wrapped them in a compressed stream they would all fail. +17:20 < dust> yes +17:20 < jrandom> cat-a-puss: we've changed things dramatically for compression over i2p in the last year ;) +17:21 < jrandom> (and I don't personally use 1.5) +17:21 < jrandom> but we do our own zip encoding explicitly, rather than use their packaged stream (but for anonymity / efficiency reasons, not compatability) +17:22 <@cervantes> zzz: where exactly in the request does the null happen? right after GET? +17:22 <+Complication> Before, if I remember +17:23 <+fox> <lordalbert> hi +17:23 <+Complication> Sidenote: Celeron 300 shows twice lower retran. percentage than Sempron +17:23 < jrandom> 'lo lordalbert +17:23 < jrandom> cool Complication, 2-3% is reasonable (though I'd prefer lower, of course) +17:23 <@cervantes> would be interesting to fire off a load of HEAD requests or something... +17:24 < jrandom> yeah, a set of local tests would be great, though iirc Complication tried that a while back with no errors +17:24 <+fox> <lordalbert> can anyone make a anonymous tracker? I try it but i dont' understand how use the tunnel +17:24 <+Complication> cervantes: I once tried provoking it, with a recursive wget between my 2 nodes +17:24 <+Complication> Grew tired before it happened +17:25 <@cervantes> heh +17:26 <+fox> <lordalbert> 'lo b0unc3 ;) +17:26 <+fox> <b0unc3> lordalbert, :D +17:26 <+Complication> lordalbert: which part would you need advise about? +17:27 <+Complication> About setting up trackers, I unfortunately don't know. +17:27 <+Complication> About I2PTunnel, I could try explaining... +17:27 <+fox> <lordalbert> I have installed BTtracker, and it work perfectly +17:28 <+Complication> It should also be noted that, for the tracker to *remain* anonymous, it should likely run a pretty careful config +17:28 <+fox> <lordalbert> now, i'd like anonimise it +17:28 <+fox> <lordalbert> so +17:28 < jrandom> I'm sure we can help work through it after the meeting. you shouldn't use generic trackers, you need one built for anonymity +17:28 <+fox> <lordalbert> i have just made a i2ptunnel +17:29 < jrandom> (e.g. the bytemonsoon modification that you can find on any of the i2p trackers, or in the cvs) +17:29 <+fox> <lordalbert> now, i'd like to know how use this tunnel. I have made a tunnel yet +17:29 < jrandom> ok, anyone have anything else for the meeting? +17:30 < jrandom> lordalbert: http://localhost:7657/i2ptunnel/ should let you create an 'http server tunnel' pointing at your webserver/tracker, but your tracker will not work unless it has been modified for anonymous use +17:30 <+fox> <lordalbert> jrandom, what tracker i must use? +17:31 <+Complication> postman uses a modified version of ByteMonsoon, I think +17:32 < jrandom> i2p-bytemonsoon has been modified for anonymous use - there's a zip up @ http://i2p-bt.postman.i2p/, and there's the cvs in http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ but I really don't know much about it +17:32 <+fox> <lordalbert> isn't bytemonsoon obsolete? +17:32 < jrandom> if it works, its not obsolete. it works +17:33 <+fox> <lordalbert> ok XD +17:33 < jrandom> there are many trackers out there, and if some developer wants to modify it to work safely and anonymously, that'd be great +17:33 <+Complication> May well be oldish... but definitely works with destkeys instead of IP's... +17:33 <+Complication> Can't tell about security and leakproofness +17:34 < jrandom> (it was modified by duck et al for anonymity and security) +17:34 <+Complication> But it's been up for a while, and seems to manage... +17:35 < jrandom> ok, if there's nothing else for the meeting... +17:36 * jrandom winds up +17:36 * jrandom *baf*S the meeting closed diff --git a/i2p2www/meetings/logs/164.rst b/i2p2www/meetings/logs/164.rst new file mode 100644 index 00000000..ee16891f --- /dev/null +++ b/i2p2www/meetings/logs/164.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 17, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/165.log b/i2p2www/meetings/logs/165.log new file mode 100644 index 00000000..475579df --- /dev/null +++ b/i2p2www/meetings/logs/165.log @@ -0,0 +1,108 @@ +15:25 < jrandom> 0) hi +15:25 < jrandom> 1) Net status +15:25 < jrandom> 2) New build process +15:26 < jrandom> 3) ??? +15:26 < jrandom> 0) hi +15:26 * jrandom waves +15:26 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2006-January/001254.html +15:26 -!- Teal`c [tealc@irc2p] has joined #i2p +15:26 -!- gloin [gloin@irc2p] has quit [Connection reset by peer] +15:26 < bar> hi +15:26 < jrandom> lets jump on in to 1) Net status +15:26 -!- gloin [gloin@irc2p] has joined #i2p +15:27 < jrandom> I don't have much more to add beyond whats in the mail... anyone have any questions/comments/concerns? +15:27 <+Complication> Moving to CVS build -6 has been... challenging +15:28 < jrandom> aye, understandable +15:28 <+Complication> Net is probably doing fine. It's just my node whcih isn't. +15:28 <+Complication> =which +15:28 < bar> it's a rough road, but it's the right road. i'm 100% supportive of this move +15:29 < jrandom> tunnel building on 2+ hop tunnels is a pain, with nasty failure rates as has been reported +15:29 < jrandom> much of this is likely to be addressed with 0.6.2's new creation crypto, but I'm not convinced that all of it will be. +15:30 < jrandom> I do wonder whether we'll be able to get it reliable enough prior to that though. But we'll try +15:31 <+Complication> If there's any stats I can provide (though you probably have more than enough of them at your own disposal) just ask +15:31 < jrandom> so, 1 hop tunnels are fairly reliable on the latest builds, but those who need 2+ hop tunnels should expect... bumps +15:31 < jrandom> thanks Complication +15:32 <+Complication> Most of my apps are 2+0..1 +15:32 <+Complication> And the router itself too, if I remember correct +15:33 < jrandom> well, I could suggest staying at the release, but the release will be building short tunnels anyway if and when it encounters catastrophic failures +15:34 < jrandom> (s/short/1hop/) +15:34 <+Complication> Right, I could probably adjust it to 2+0 +15:34 <+Complication> And have less spectacular effects +15:35 < jrandom> aye, though that'll still, in effect, turn to 2+/-1, but it'll try its best to stay at 2hops +15:36 <+Complication> With build -6 too? +15:36 -!- gloin [gloin@irc2p] has quit [Connection reset by peer] +15:36 < jrandom> no, the current release will fail hard rather than go to fallback tunnels +15:37 <+Complication> Or is there probability involved, which never quite goes zero? +15:37 < jrandom> the trouble there is that if it goes for 10 minutes without building the tunnels, it'll restart the router (due to the watchdog) +15:37 <+Complication> Saw it once :) +15:37 < jrandom> no, -5 or newer will use exactly the hop lengths allowed by the client (2+/-0 means only 2 hop tunnels. never anything else) +15:39 < jrandom> ok, anyone have anything else for 1) Net status? +15:39 < jrandom> or, I suppose we're already discussing 2) New build process ;) +15:40 < jrandom> does anyone have anything else to discuss on 2) New build process? +15:40 <+Complication> Not much here, anymore :D +15:41 < jrandom> hehe ok, if not, lets shimmy on over to 3) ??? +15:41 < jrandom> anyone have anything else they want to discuss? +15:42 < bar> may i ask, how many backwards incompatible changes are lined up now, and if some (all?) can be put into one release? +15:42 < bar> i mean, is there more than one backwards incompatible release planned, until 0.6.2? +15:42 < jrandom> bar: the hope is to do them all at once +15:42 < jrandom> (though there may be further ones down the line) +15:43 -!- Complication [Complicati@irc2p] has quit [Connection reset by peer] +15:43 -!- Complication2 [Complicati@irc2p] has joined #i2p +15:43 < bar> hmac bug, new crypto and restricted routes at once? +15:43 < bar> that's a tall order :) +15:43 < jrandom> restricted routes? +15:43 < jrandom> the hmac bug "fix" is changing one value ;) +15:44 < bar> ah :) +15:44 -!- Complication2 is now known as Complication +15:44 < bar> umm.. perhaps restricted routes was 2.0.. +15:44 < jrandom> yeah, but restricted routes will be doable without losing backwards compatability +15:45 < jrandom> (in fact, it can be done with 0.6.2, if done carefully, to a degree) +15:45 < bar> ok, great +15:45 < jrandom> I'm also thinking of when to drop tcp... maybe in the next release +15:46 < jrandom> or maybe after, so we don't have /too much/ at once +15:49 < jrandom> ok, anyone have anything else for the meeting? +15:51 < jrandom> if not +15:51 * jrandom winds +15:51 < stealth> I have some question: I noticed that all eepsites are mapped to the external internet e.g. http://tracker.postman.i2p.tin0.de/. Is that wanted ? +15:51 < jrandom> [saved] +15:51 < jrandom> sure, I think thats cool +15:51 < jrandom> anyone who publishes information should expect that their information is public +15:52 -!- gloin [gloin@irc2p] has joined #i2p +15:52 < jrandom> I think tino has a way for people to topopt out as well +15:52 < tethra> that was short +15:53 < stealth> They are also indexed by google... +15:53 < jrandom> isnt that a good thing stealth? +15:53 < Complication> Did it not involve some convention similar to "robots.txt" +15:54 < jrandom> aye Complication +15:54 < Complication> (might be best to ask tin0) +15:54 <@postman> damn, i am too late +15:54 <@postman> (again) +15:54 < jrandom> nah, hasn't ended yet postman :) +15:54 < Complication> He wrote about it in the forum, at some point +15:54 < Complication> Might be findable there +15:54 <@postman> ahh cool ( hello then) :) +15:55 < jrandom> yeah, its opt-out-able, but I don't understand the concept of opt-out for the i2p content (are people pushing some idea of 'copyright' - "don't copy my stuff or make it visible other places"?) +15:55 < jrandom> but, whatever, tino is being nicer than I would be regarding inproxies ;) +15:56 -!- Rawn [Rawn@irc2p] has quit [Connection reset by peer] +15:56 -!- gloin [gloin@irc2p] has quit [Connection reset by peer] +15:57 -!- Karellen [Karellen@irc2p] has quit [Connection reset by peer] +15:57 < Complication> Yes indeed, the assumption shouldn't follow that other providers of in-proxies will be equally nice +15:58 -!- Karellen [Karellen@irc2p] has joined #i2p +15:58 -!- Rawn [Rawn@irc2p] has joined #i2p +15:58 -!- mode/#i2p [+v Rawn] by chanserv +15:59 < Complication> Information intended to be secret... is best simply not published +15:59 < tethra> indeed :/ +15:59 < stealth> Yes but it might turn too much publicity to i2p before evrything is really totally save. The problem seems to me that I2p has at the moment not enough nodes for a very good anonymity... +16:00 -!- Complication [Complicati@irc2p] has quit [Connection reset by peer] +16:00 < jrandom> our anonymity isn't dependent upon the size, and i2p has been googled plenty +16:01 < jrandom> (or, the base level of anonymity isn't dependent upon the size) +16:01 < jrandom> but, of course, no one who needs hard anonymity should use i2p now. +16:01 -!- digger3 [digger3@irc2p] has quit [Connection reset by peer] +16:01 -!- digger3 [digger3@irc2p] has joined #i2p +16:02 < bar> i wouldn't worry, 99% would just ignore the seemingly dead link that turns up on google... the other 1% is likely somewhat geeky and would want to know more +16:03 -!- gloin [gloin@irc2p] has joined #i2p +16:03 < bar> (well.. dead, that depends on tino's inproxy being up or not, of course) +16:05 < jrandom> ok, anyone have anything else for the meeting? +16:06 < jrandom> if not +16:06 * jrandom winds up +16:07 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/165.rst b/i2p2www/meetings/logs/165.rst new file mode 100644 index 00000000..04d3583a --- /dev/null +++ b/i2p2www/meetings/logs/165.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 24, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/166.log b/i2p2www/meetings/logs/166.log new file mode 100644 index 00000000..9f65de40 --- /dev/null +++ b/i2p2www/meetings/logs/166.log @@ -0,0 +1,136 @@ +15:19 < jrandom> 0) hi +15:19 < jrandom> 1) Net status +15:19 < jrandom> 2) 0.6.1.10 status +15:19 < jrandom> 3) ??? +15:19 * jrandom waves +15:19 < jrandom> status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001257.html +15:20 < jrandom> ok, jumping on in to 1) Net status +15:21 < jrandom> as mentioned in the mail, those on 0.6.1.9-0 (the full release) should have the same-ol'-same-ol' +15:21 < jrandom> though users on newer builds (those since 0.6.1.9-5 or newer) may have trouble +15:21 < jrandom> ("trouble" is perhaps an understatement...) +15:21 <+Complication> CVS -8 was a bit flaky, so running -2 instad (works nice enough) +15:22 < gloin> :-) +15:22 <+Complication> =instead +15:22 < Pseudonym> things seem unstable lately (I'm on 0.6.1.9-0) +15:22 < jrandom> cool, I was considering reverting the process changes but including dust's ircclient update and the i2ptunnel httpserver patch on head, but 0.6.1.10 probably isn't that far away +15:23 < jrandom> hmm Pseudonym, accessing eepsites, irc, or other services, or hosting them? +15:23 <+Complication> Unstable with -0? How does the problem exibit itself? +15:23 < Pseudonym> I notice IRC primarily (playing idlerpg) +15:24 < jrandom> ("playing" ;) +15:24 < Pseudonym> also, somtimes the router goes wonky and has to be restarted (no active peers) +15:24 < Pseudonym> heh +15:24 < jrandom> hmm, internet connectivity issues? +15:24 <@frosk> -0 is stable here, of course except for the twice-daily "router hung!" restarts +15:24 < jrandom> hrm frosk, real "router hung", or "router hung" due to leaseSet expiration? +15:25 < Pseudonym> internet connectivity is fine. when I restart the i2p router it comes right back +15:25 <+Complication> My Cel300 also hangs after a while, but the periods have been increasing, and I'm not up-to-date on its reason +15:25 <@frosk> jrandom: lease expiration, i'm pretty sure +15:25 < jrandom> hmm 'k +15:26 < jrandom> pretty much all of that has been rewritten for the new creation and management code, so we'll see how it goes in 0.6.1.10 +15:27 <@frosk> cool +15:27 <@frosk> i'll be glad to help test it +15:28 < Pseudonym> I don't need you to troubleshoot the problem right now. I just wanted to add a datapoint about stability +15:28 < jrandom> wikked, once its stable locally I'll certainly need to recruit some help :) +15:28 < jrandom> cool, thanks Pseudonym +15:28 < jrandom> ok, anyone else have something for 1) Net status? +15:30 < jrandom> if not, lets jump on in to 2) 0.6.1.10 status +15:30 < jrandom> as mentioned in the mail, rather than pile tweak upon tweak on the live net, we're going to go straight to the source +15:31 < jrandom> it won't be backwards compatible, so it will have a... bump, and while we'll roll up a few other backwards incompatible changes with it, there is the possibility for another one afterwards +15:32 < jrandom> more specifically, one idea I'm toying with is migrating to 1024bit ElGamal for the tunnel creation code, rather than 2048bit +15:32 < jrandom> but that may not be necessary. it depends on how hard it hits us on the live net +15:34 < jrandom> if it does, it would just mean a network upgrade, but all destinations/etc would stay the same. +15:34 < jrandom> but, anyway, thats something to explore after 0.6.1.10 comes out +15:34 <+Complication> A loosely related question: is the key length in any way related to the tunnel-creation datastructure length? +15:34 < jrandom> yes +15:35 < jrandom> directly related: key length * 2 * max # hops == data structure size +15:36 < jrandom> (so, 256*2*8 = 4KB, which also happens to be the size of full streaming lib messages) +15:37 < jrandom> ((ElGamal has a 2x expansion factor)) +15:38 <+Complication> Aha, thanks. :) +15:38 < jrandom> ah, one other thing re: the new spec. during implementation I found one other data point I need (a 4 byte "reply message ID") which I've added to the spec locally, using some of the reserved bits +15:40 < jrandom> I'm hoping to get everything working in the next few days though, so perhaps there'll be some early (non-anonymous) testing by the weekend +15:40 < jrandom> but, of course, more info on that as it comes +15:41 < jrandom> ok, anyone have any questions/comments/concerns on the 0.6.1.10 stuff? +15:41 < bar> another loosely related question: during the rol out of .10, how about keeping i2p.net on .9 for a couple of days for all the auto updating folks? +15:41 < bar> rollout* +15:41 < jrandom> aye, definnitely +15:42 < jrandom> I'll probably have two or three routers on that box during the migration +15:42 < jrandom> and there will be loud warnings at least 5 days in advance of the release +15:42 < bar> smooth +15:42 <+Complication> This way it would be smoother indeed. +15:43 <+Complication> Forum seems a good channel. News box on the Router Console too... +15:43 * jrandom remembers the days when every release was backwards incompatible... we got a lot of practice then ;) +15:43 < jrandom> aye, forum, news box, list, website +15:43 <+Complication> So those who attend their machines would know. +15:43 < tethra> heheh +15:44 < jrandom> and those on 0.6.0.1 still, well, they're fscked anyway ;) +15:44 <@frosk> off with their heads +15:44 <+Sugadude> Totally un-related: Can we have more backwards incompatible changes more often to force these old routers out? +15:44 <+Complication> I think they just forgot I2P running :) +15:44 < jrandom> heh Sugadude +15:45 < jrandom> well, if they're compatible, we can make use of their resources, but if there's some reason why we can't, we should mark them as incompatible +15:47 < jrandom> ok, if there's nothing else on that, lets jump on over to our catch-all: 3) ??? +15:47 < jrandom> anyone have anything else they want to bring up for the meeting? +15:48 < tethra> it says somewhere on the router console that users behind symmetric NATs aren't currently supported, is that going to change at some point soon? +15:48 < tethra> or am i showing immense ignorance of something +15:49 <+Complication> Regarding webcache code... it seems I'm pretty much ready. +15:49 < jrandom> there are a few techniques to help users behind symetric nats, which bar has outlined on the list and the forum, though I don't know of any immediate progress on it +15:49 < jrandom> oh, nice1 Complication, lemmie know when to push the release :) +15:50 <+Complication> Got the watchdog aborting downloads reasonably, doing some testing and clean-up (it currently logs way more than decent).. +15:50 <+Complication> I have one webcache server up, awup has another... for some realistic testing, we may want to turn limiting on... +15:51 <+Complication> ...if I manage to encounter legion, I'll ask if he might be interested in running one too. +15:52 < jrandom> cool, even a single webcache would be a great start +15:52 <+Complication> And if anyone else wants to run the script (available from awup.i2p, Python script using SAM)... their references can be added, though currently adding refs to more "seed webcaches" does require a recompile of sources. +15:53 <+Complication> (not in a file but the header of GWebCacheContainer.java) +15:53 * gloin don't know what this webcache stuff is. +15:53 < jrandom> gloin: it lets you connect to i2phex without having to download an i2phex.hosts file the first time +15:54 <+Complication> gloin: for easier integration of I2PHex +15:55 * cervantes arrives late +15:55 <+Complication> And for later reconnecters (e.g. people who've run out of live peer refs) it can offer fresh refs +15:55 < gloin> ok. +15:57 <+Complication> Oh, offline again +15:58 < stealth> what about an automatic startup of i2phex after i2p has started ? +15:58 <+Complication> Seems like overkill +15:58 <+Complication> At current phase, at least +15:58 < jrandom> stealth: you can have the i2p router launch any java application you want by adding entries into your client.config file +15:59 <+Complication> Besides, I think I2Phex can be started before I2P runs +15:59 <@frosk> at any phase +15:59 <+Complication> Theoretically, it should keep trying to connect until I2P gets up +15:59 <+Complication> (haven't tested, though) +15:59 < jrandom> though remember, if you tell it to launch i2phex, when i2phex closes, chances are the i2phex client will kill the JVM (restarting your router) +16:00 <+Complication> Besides, one could script it fairly easily too... +16:00 <+Complication> e.g. "cd /home/i2p; sh i2prouter start; cd /home/i2phex; sleep 100; sh run.sh;" +16:00 <+Complication> (or however it was) +16:01 <+Complication> Sorry, /home/user/i2p more likely :) +16:01 < cervantes> don't forget to start /usr/games/tetris before the sleep 100 +16:02 < jrandom> damn straight +16:02 < jrandom> ok, anyone have anything else for the meeting? +16:03 < stealth> well I thought about it just start the exe. the i2psnark solution with always on is better because people forget to share their files if they are not downloading... +16:04 < jrandom> aye, though I've yet to hear of a gnutella client that is thin enough (that could be integrated) +16:05 < cervantes> isn't the work being done on the current Phex to abstract the UI? perhaps the client eventually become skinny +16:05 <+Complication> I haven't read that part of Phex CVS +16:06 < jrandom> if phex could be run as a .war, that would indeed rule +16:06 < cervantes> isn't the=isn't there +16:06 < cervantes> I'm probably mistaken +16:06 <+Complication> Sirup certainly was working on an XML-RPC interface, but I'm not sure if Gregor & co are too +16:07 <+Complication> So I'm not sure if sirup ported it in, or started writing it from scratch +16:09 < jrandom> iirc he was just importing apache's xmlrpc lib and exposing some of i2phex's internals, but there hasn't been any work on that in probably 6-8 months, and it was never functional afaik +16:10 < fox_> <tethra> mutella is a web based gnutella client that is fairly lightweight, iirc. not sure if it will be any help, but heh, might be worth someone (more talented) checking it out. +16:10 < fox_> <tethra> might not be what is being looked for, though. +16:12 < jrandom> porting a new one is a chunk of work, especially a C/C++ one, unfortunately +16:12 <+Complication> I'm personally unlikely to tinker with XML-RPC. Attempting to catch various bugs... is in my near-term plans, though. +16:13 * Complication wants the rehash effect gone for good, since it's such a waste of time +16:13 < jrandom> ooh, perhaps thats triggered by timezone shift? +16:14 < jrandom> when the I2P SDK connects to the router, it gets the current I2P (NTP) time from it, and forces the SDK's JVM into UTC +16:14 <+Complication> Sounds unlikely... but at this stage, I can't exclude much +16:15 < jrandom> (and if the rehash depended upon ordering and file timestamps, perhaps the shift of a few hours would change that) +16:15 < jrandom> yeah, you've dug into a lot of it, just mentioning a possibility +16:15 * jrandom doesn't know anything about it beyond your bug reports :) +16:16 <+Complication> It occurs occasionally, and *seems* related to something happening when the "sharedlibrary" config file is being loaded/rewritten +16:16 <+Complication> Hmm, interesting possibility... +16:16 <+Complication> I've not dug enough to exclude that +16:18 < jrandom> ok, anyone else have something for the meeting? +16:19 < jrandom> if not... +16:19 * jrandom winds up +16:19 * bar wishes jrandom good luck with .10 and hands him a shiny baf +16:19 < jrandom> gracias :) +16:19 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/166.rst b/i2p2www/meetings/logs/166.rst new file mode 100644 index 00000000..21d8f8d0 --- /dev/null +++ b/i2p2www/meetings/logs/166.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 31, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/167.log b/i2p2www/meetings/logs/167.log new file mode 100644 index 00000000..dfa60695 --- /dev/null +++ b/i2p2www/meetings/logs/167.log @@ -0,0 +1,145 @@ +15:36 < jrandom> 0) hi +15:36 < jrandom> 1) Net status +15:36 < jrandom> 2) _PRE net progress +15:36 < jrandom> 3) I2Phex 0.1.1.37 +15:36 < jrandom> 4) ??? +15:36 < jrandom> 0) hi +15:37 * jrandom waves +15:37 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html +15:37 < bar> hello +15:38 < jrandom> while y'all dig through that oh-so-exciting material, lets jump on in to 1) Net status +15:38 < jrandom> there hasn't been much changed on the live net in the last week, from an i2p perspective, so I don't really have much to add here +15:39 < jrandom> anyone have anything they want to bring up regarding the current net status? +15:39 < KBlup> I have seen terrible spikes of failing clients when running i2p for long... dunno if thats fits to 1) +15:39 < jrandom> KBlup: does that correlate to high cpu load or bandwidth consumption? +15:40 < KBlup> resuluts in msg-delay > 10000ms :-/ +15:40 < jrandom> ah, very likely one of the causes of the _PRE net being developed :) +15:40 < KBlup> I think it then tries to establish new tunnels and fails constantly, which results in 300+ jobs some times... +15:41 < KBlup> my maschine is quite strong but overloaded with that... +15:41 < jrandom> aye, thats all been reworked along the way for 0.6.1.10, hang tight until thats ready +15:43 < jrandom> ok, anything else on 1), or shall we mosey on over to 2) _PRE net progress +15:43 <+Complication> 0.6.1.10 seems to contain substantial changed indeed +15:45 < jrandom> yeah, there's a lot of meat under here. The current state is that the new creation code is in place and seems to be working properly, but now I'm using this opportunity to debug some of the underlying issues further +15:46 <+Complication> You mentioned having to cough up a lot of CPU time in advance +15:47 <+Complication> Would this cost now be associated with building any sort of a tunnel? +15:48 <+Complication> (meaning, before the construction, during a short while, you'd have to perform a batch of heavy crypto) +15:48 < jrandom> yes, all tunnel build requests will need to do k heavy crypto operations (where k = number of hops in the tunnel being built) +15:49 <+Complication> Whad I wanted to ask... is the interval just tighter than before, or the amount bigger too? +15:50 < jrandom> the amount is both bigger, smaller, and tighter. tighter, in that they're all done upfront. bigger, in that we can't short circuit and not do the encryption for a hop if an earlier hop rejects it, and smaller in that earlier hops fail a lot less +15:51 < jrandom> in addition, however, unlike earlier releases, we're no longer using ElGamal/AES+SessionTag for the tunnel requests - we use (fairly) straight ElGamal +15:52 <+Complication> ...and it couldn't be pre-calculated, unless one knew the final set that's going to succeed? +15:52 < jrandom> that means that while we used to be able to cheat without an asymmetric operation, we don't try to cheat anymore (as the cheating itself exposed a class of attacks) +15:53 <+Complication> (set of peers) +15:53 < jrandom> hmm, it could certainly be precalculated, assuming you know who the peers in the tunnel that are going to be asked +15:54 < jrandom> the new tunnel creation process is done on a separate thread, so it doesn't bog down the main job queue under load, and so that it can throttle itself better +15:54 <+Complication> Could one also assume that, barring change in available knowledge, one knows a few whom one is going to ask from, if attempts fail? +15:54 < jrandom> hmm, not entirely sure I follow +15:55 <+Complication> Or is knowing them already useless, since the struct must be redone from scratch? +15:56 <+Complication> (meaning: the ElGamals redone from scratch, at least) +15:56 < jrandom> ah, the structure is http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord +15:56 < jrandom> so, yes, if the next hop changes, the ElGamal must be redone +15:56 < jrandom> (if you precompute) +15:56 <+Complication> Right, I wasn't sure enough about that instantly +15:57 <+Complication> Now I realize it, though +15:57 < jrandom> otoh, we're really trying to get our build success rate up, and the new build process should be able to adapt to minimize unnecessary creations +15:58 <+Complication> How does it seem doing in reality? +15:58 < jrandom> (oh, that structure has been slightly modified on the _PRE branch: http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord ) +15:59 <+Complication> I noticed the detail about ElGamal encrypts taking a leap towards quickness... +15:59 < jrandom> well, the build success rate is much much higher than it is on the live net, but that may just be due to the small _PRE net size +16:00 < jrandom> yeah, creating a 2 hop structure, for instance, takes an average of 44ms over 1120 runs, as compared to the live net's ElGamal encryption time of 542ms (over 1344 runs) +16:02 < jrandom> (on the same box) +16:02 <+Complication> Would this 542 include retries on failure too, or just the pure building? +16:02 <+Complication> If it's pure building, I need to find my lower jaw... it's on the floor somewhere. :P +16:02 < KBlup> about that change of the exponent : at what scale does that affect anonymity? +16:02 < jrandom> no, thats the pure elGamal stat, since the live net doesn't build the new _PRE net structure +16:04 < jrandom> KBlup: anonymity? none. security? according to what I've read, 228 bits is more than enough to match 2048bit ElGamal +16:04 * Complication doesn't know much about ElGamal's x and y +16:04 <+Complication> Not enough to comment meaninfully +16:06 <+Complication> If serious researchers consider the shorter x hard enough, and those crypto wonks didn't run away screaming... +16:06 <@cervantes> well not only that, but the implications of dropping to 1024/160 +16:07 < KBlup> i guess i have to read the paper later ;) +16:07 <+Complication> cervantes: yes, it's better than that, for sure +16:08 <+Complication> Besides, what is the foremost attack this cipher must repel, and how long is the attack viable? +16:09 <+Complication> Could it be something which benefits you only if you break it quick, or also benefits if you break it eventually? +16:11 <+Complication> If I understand right, the immediate secret it guards is the next tunnel participant, right? +16:11 <+Complication> (or more precisely, the next-to-next one) +16:11 <@modulus> meeting ongoing? +16:11 <+Complication> (which only the next one may know) +16:11 <@cervantes> modulus: ayre +16:11 <@cervantes> -r +16:11 < jrandom> for a practical (yet insanely powerful) adversary, breaking it during the tunnel lifetime would be necessary. breaking it after that tunnel lifetime would only help if you logged all network traffic and broke all tunnels (that is, after breaking the ephemeral transport layer crypto and working on the tunnel layer crypto) +16:11 < jrandom> so, we're talking on the order of minutes here, not decades +16:12 < jrandom> (so 1024bit is probably even overkill) +16:12 <@cervantes> is there a way to measure the risk in a meaningful way? +16:13 <+Complication> Besides, for a tunnel with more hops, the adversary would have to break several, right? +16:13 <+Complication> (though the builder would have to build several too) +16:13 <@cervantes> if we need no more than 1024 bits, then is it really necessary to use more? +16:14 <@cervantes> we can always use a stronger algo in 3 years time when we've got vastly more powerful quantum computers +16:14 <@modulus> jrandom: if the adversary would know that at time hh:mm something important is going to be tunneled is it likely they could break it somehow by logging? +16:14 < jrandom> Complication: right, they'd have to break several (and the DH keys protecting the transport layer) +16:14 <@modulus> afaik 1024bit is break()able with a lot of power +16:15 < jrandom> a lot of power and a decade +16:15 < jrandom> (or three) +16:15 <@cervantes> jrandom: is it difficult to try the weaker cipher? +16:15 <@modulus> i was under the impression that 1024bit composits were factorizable these days in a few months. +16:15 <@cervantes> could we roll out to the pre net +16:15 <@cervantes> and see whether it actually offers much benefit +16:16 <@cervantes> modulus: yes but they'd need to break several +16:16 <@modulus> if this is based on discrete log domain and all that stuff then i don't know anything +16:16 <@modulus> cervantes: aha +16:16 < jrandom> cervantes: it requires changes to a lot of structures, since we currently use 512byte slots. though, perhaps we could just fill the first 256 bytes with 0x00 for testing +16:17 < jrandom> modulus: ElGamal is based on discrete log +16:17 <@cervantes> jrandom: worthy of testing? +16:17 <@modulus> right right, i was imagining RSA +16:17 <@cervantes> or better to focus on other things and return to it if necessary +16:18 < jrandom> definitely worth testing, though for the moment I'm hacking away at some transport layer evaluations +16:18 <+Complication> I guess it depends on how their calculation can be handled in real life. +16:18 < jrandom> (and the 44ms encryption time is good enough for the moment, though a 4ms encryption time would be even better :) +16:19 <+Complication> If it holds together with current computers, it will improve with newer machines. +16:19 <@modulus> especially if there comes crypto hw, as it is starting to come in some +16:19 < jrandom> but, of course, changing this parameter will not be done lightly or immediately. but if someone has a good reason to avoid it, please get in touch +16:21 < jrandom> modulus: I've heard of dedicated AES and RSA chips, but nothing on DH/ElGamal. otoh, when one looks to the NSA/etc as an adversary, where they can build their own, its possible +16:22 <@cervantes> they have crypto machines built on ring sprinkled donut technology +16:23 * Complication is willing to upgrade the Celeron 300 to Athlon 600, if it holds the tide of ring-sprinkled donuts :D +16:23 < tethra> heheh +16:24 < jrandom> mmMMmm donuts +16:25 < jrandom> ok, anyone have anything else on 2) _PRE net progress? +16:25 < jrandom> if not, lets jump on over to 3) I2Phex 0.1.1.37 +16:26 < jrandom> Complication: wanna give us the skinny? +16:26 <+Complication> Well, it seems to work. :) +16:26 <+Complication> There is hope of getting more webcaches for extra redundancy soon. +16:27 < jrandom> word +16:27 < jrandom> hmm, do you think we need more webcaches? don't we just need one to be up? not that more hurts, of course +16:27 <+Complication> (if legion manages to solve the mysteries which haunted his initial try) +16:27 <+Complication> There's also a mystery bug in there, but it doesn't byte hard, and I'm trying to find it. +16:28 <+Complication> One up is enough +16:28 <+Complication> More just increases the chances that one is up +16:28 < jrandom> cool +16:28 <+Complication> Because at current stage, it will never drop webcaches as bad. Too few of them altogether. +16:29 <+Complication> (that routine will activate if there exist more than 10) +16:29 <+Complication> (if I remember correctly) +16:29 <+Complication> As for the bug: after a long time operating, the webcache subsystem sometimes stalls +16:30 <+Complication> Likely because a httpclient's GET request can't be aborted successfully +16:31 <@modulus> so it needs to die from time to time? +16:31 <+Complication> It's safe, and never seems to bite freshly joined machines +16:31 < jrandom> hmm, what does that mean, functionally? after a while, it will stop registering with the webcache, so new people won't be given references to them? +16:31 <+Complication> If it bites a machine already well integrated, that machine can get enough peers from the peers it's already connected to +16:31 <+Complication> So currently the impact seems close to 0 +16:31 <@modulus> cool +16:32 <+Complication> It's curious, just +16:32 <@modulus> no rule about when it will fail or anything? +16:32 <+Complication> modulus: generally not before 20 hours +16:33 <+Complication> And since I have no way of forcing it to occur, debugging is a bit slow +16:33 <@modulus> :_) +16:34 <+Complication> Either way, should I find it, I'll fix it, and should I not find it, I'll find other stuff to tinker with :) +16:34 < jrandom> :) +16:34 < jrandom> sounds like its just a symptom of some bugs we've seen in the streaming lib / eepproxy, so fixing those should fix this +16:35 <+Complication> Could be +16:38 < jrandom> ok great, nice work Complication +16:38 < jrandom> anyone have anything else on 3) I2Phex 0.1.1.37, or shall we jump on over to the catch-all, 4) ??? +16:41 < jrandom> (consider us jumped) +16:41 < jrandom> ok, anyone have anything else for the meeting? +16:42 < tmp> Or forever hold your breath? +16:43 < jrandom> and ever and ever +16:43 * jrandom winds up +16:43 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/167.rst b/i2p2www/meetings/logs/167.rst new file mode 100644 index 00000000..ebf4ca9c --- /dev/null +++ b/i2p2www/meetings/logs/167.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 7, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/168.log b/i2p2www/meetings/logs/168.log new file mode 100644 index 00000000..7c1234f9 --- /dev/null +++ b/i2p2www/meetings/logs/168.log @@ -0,0 +1,68 @@ +15:39 < jrandom> 0) hi +15:39 < jrandom> 1) Net status +15:39 < jrandom> 2) 0.6.1.10 +15:39 < jrandom> 3) Syndie activity +15:39 < jrandom> 4) ??? +15:39 < jrandom> 0) hi +15:39 * jrandom waves +15:39 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001260.html +15:39 < jrandom> (I'm a lil late with that, so I'll give y'all a minute to skim through those brief notes) +15:40 <+Complication> hello +15:40 <@cervantes> 'lo +15:41 < jrandom> well, its brief enough, so lets just jump on in to 1) Net status +15:41 < jrandom> I don't have anything to add to this one, anyone have something on it to discuss? +15:41 <@cervantes> <jrandom> (damn flakey net connection) +15:41 <+Complication> A bit congested occasionally, but graphs suggest it's nothing new +15:42 < jrandom> heh cervantes, well, thats due to one of my roommates using limewire, not i2p ;) +15:43 <@cervantes> we've had various server problems too with irc and postman's tracker over the past couple of weeks - postman has done a lot of migrations, so things should be more stable for folk +15:43 <+Complication> It must be hard letting them do that, but I guess... such is life :O +15:43 <+Complication> do that=use limewire +15:44 <+Complication> This morning, tracker.postman.i2p was refusing connections, though +15:44 < jrandom> Complication: disk was full, fixed now +15:44 < jrandom> (new machines have their new quirks) +15:46 < jrandom> ok, anyone have anything else on 1) Net status? +15:46 < jrandom> otherwise, lets shimmy on over to 2) 0.6.1.10 +15:47 < jrandom> As mentioned, we're going to have a new backwards incompatible release in a few days +15:48 < jrandom> while it alone won't revolutionize our performance, it will improve a few key metrics to get us on our way +15:48 < jrandom> there are also a whole bunch of bug fixes in there too +15:49 <@cervantes> will zzz's server tunnel improvements make the fold? +15:49 < jrandom> oh, and there's that whole improved anonymity thing... ya know, sine qua non +15:50 < jrandom> cervantes: probably not, haven't heard much since that post to zzz.i2p last week. i did do some minor bugfixes in cvs though (to should support lighttpd, etc), but we won't have zzz's persistent connections +15:50 < jrandom> (yet) +15:51 <@frosk> what DH key size/etc did you land on? +15:51 <@cervantes> yeah, I saw those newline issues a few weeks ago, but I held off changing them because of zzz's impending improvements +15:51 < jrandom> ah, for the moment we'll be sticking with 2048bit crypto with small exponents +15:52 <@frosk> so some lower cpu consumption can be expected? +15:52 < jrandom> aye +15:53 <@frosk> excellente +15:53 < jrandom> switching to 1024bit would cut another order of magnitude to the CPU load, but would require some reworking of the tunnel creation structures (1024bit asym isn't large enough to convey the data we need to convey). +15:54 < jrandom> we may explore that in the future though, but this next release should substantially cut down cpu overhead +15:54 < jrandom> I've also disabled the TCP transport, because I'm a mean and vicious person +15:55 <@frosk> do you expect any more incompatible upgrades before 1.0? +15:55 < jrandom> hope not +15:55 * cervantes must be a danish cartoonist +15:55 <@frosk> i don't think we'll miss tcp :) +15:55 <@cervantes> I mean jrandom must be +15:55 <@cervantes> ;-) +15:55 * jrandom watches the embassy burn +15:56 < jrandom> ok, anyone have anything else on 2) 0.6.1.10? +15:56 < void> why wouldn't it support lighttpd earlier? +15:56 < jrandom> (ah, as an aside, there have also been some interesting improvements to the streaming lib for 0.6.1.10, such as tcp-style fast retransmit, etc, so we'll see how that helps) +15:57 <@cervantes> void: malformed headers +15:57 < jrandom> void: bug where we weren't standards compliant +15:57 < void> ah, are these inconsistent newline bugs also fixed? +15:58 < void> and what about the null character one? are you waiting for zzz's persistent connection patch? +15:58 < jrandom> the newline bug is the malformed header, and is fixed +15:58 < jrandom> no news on the null character one +15:59 < void> ok +16:00 < jrandom> ok, if there's nothing else on 2, lets swing on by 3) Syndie activity briefly +16:00 < jrandom> well, I don't really have much to add... +16:01 < jrandom> (I /did/ say briefly) +16:01 < jrandom> so lets jump on to 4) ??? +16:01 < jrandom> anyone have anything else they want to bring up for the meeting? +16:01 <+fox> <duck> too busy reading Syndie to comment +16:01 < jrandom> ;) +16:02 * Complication is too busy issuing meaningless signatures to comment :D +16:05 < jrandom> ok cool. just another reminder for people to stay away from CVS for the next day or two until the release, as CVS HEAD is going to get the _PRE branch's changes, and the _PRE branch is going to be retired +16:05 * jrandom winds up +16:05 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/168.rst b/i2p2www/meetings/logs/168.rst new file mode 100644 index 00000000..24ec57ff --- /dev/null +++ b/i2p2www/meetings/logs/168.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 14, 2006 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/170.log b/i2p2www/meetings/logs/170.log new file mode 100644 index 00000000..987d34a9 --- /dev/null +++ b/i2p2www/meetings/logs/170.log @@ -0,0 +1,116 @@ +15:11 < jrandom> 0) hi +15:11 < jrandom> 1) Net status and 0.6.1.12 +15:11 < jrandom> 2) Road to 0.6.2 +15:12 < jrandom> 3) Miniprojects +15:12 < jrandom> 4) ??? +15:12 < jrandom> 0) hi +15:12 * Complication quickly reads notes +15:12 * jrandom waves +15:12 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001266.html +15:12 < jrandom> (and here I was posting the notes more than 15 minutes before the meeting! ;) +15:13 < jrandom> ok while y'all read those oh-so-exciting bits, lets jump on in to 1) Net status and 0.6.1.12 +15:14 < jrandom> as mentioned, the primary goals of the 0.6.1.10-0.6.1.12 releases seem to have been met, addressing the tunnel creation crypto change and improving creation reliability substantially +15:16 < jrandom> the bumps we saw at 0.6.1.10 are gone, and irc stability seems quite good again +15:16 < jrandom> anyone have anything else to bring up for 1) Net status and 0.6.1.12, or shall we mosey on over to 2) Road to 0.6.2? +15:17 <+Complication> Net status over here: no more going back under 20 KB/s :) +15:18 < jrandom> cool, yeah 0.6.1.12 fixed a pretty large bug in 0.6.1.11 where it wouldn't exploit the bandwidth available. it should now make better use of available resources +15:20 < jrandom> ok, lets jump on to 2) +15:20 < jrandom> as mentioned, there are a few things that need to get sorted before the last functional change is put in place for 0.6.2, but we're making progress on that front +15:20 < nymisis> net status is fine :) +15:22 < jrandom> word. there'll be more info available on the specifics of the new peer ordering strategies before they come out, but the gist of them should be clear from their brief mention in the notes +15:23 < jrandom> anyone have any questions/comments/concerns regarding 2) road to 0.6.2? +15:23 < postman> jrandom: any testnets this time? +15:24 < postman> (need any routers, particpants to test stuff) +15:24 < postman> ? +15:24 <+Complication> The essence of the matter seemed quite straightforward - to limit opportunity for an adversary to harvest diverse statistical data +15:25 <+Complication> Sounds like a fairly desirable feature +15:25 < jrandom> postman: the new stuff should work transparently on the live net using local-only info, so shouldn't need a separate net to test +15:25 < jrandom> aye, exactly Complication +15:26 < postman> ok +15:26 < postman> jrandom: are you bold enough to disclose an ETA for 0.6.2 ? :) +15:27 < blubb> 1 april +15:27 < jrandom> well, seeing as today is the end of feb, i'd guess march or april +15:27 < postman> hehe +15:27 < jrandom> blubb: we've already got an mi6 backdoor scheduled for then ;) +15:29 <@cervantes> more like an mi6 catflap +15:29 <@cervantes> (budget cuts) +15:29 < postman> in an elephant house +15:30 < nymisis> That's SIS, not MI6, if you're going to be accurate. :) +15:30 < jrandom> well, lets just call them Them ;) +15:31 < jrandom> ok, anything else for 2)? +15:31 < jrandom> if not, lets shimmy on over to 3) miniprojects +15:31 <@cervantes> sorry "the firm" +15:34 < jrandom> ok, I just wanted to point out a few neat things that would be 1) simple to do and 2) really useful +15:34 <+Complication> On the miniprojects side, I'm not sure if my Syndie reply made it or not, but I'm wondering if I could snatch one. +15:34 <+Complication> Not sure which one yet. Currently practising a little more Java (doing a micro-project :D) just to have added certainty that when I try, I'll be able to handle one +15:35 < DeltaQ> hmm if i upp the bw on the console is the chanes immediate or reboot needed? +15:35 <+Complication> When I get ready with the "micro-project" (assuming of course the table hasn't been cleared yet), I'll try picking one +15:35 < jrandom> w3wt, great Complication +15:36 < jrandom> DeltaQ: immediately +15:36 <@cervantes> isn't 1) syndie scheduler a tie in with 4) Download Manager / eepget scheduler +15:36 <+Complication> DeltaQ: takes effect almost instantly (within the periods that bandwidth gets averaged over) +15:37 <@cervantes> seems to me that a more generally functional up and download manager would service both needs +15:37 < jrandom> cervantes: hmm, not necessarily. 1) is pretty focused, and also includes pushes, while 4) is prety generic +15:37 <+Complication> cervantes: sounds like it could +15:37 < jrandom> but yeah, the engine behind both is EepGet +15:37 < jrandom> (eepget does syndie's http transfers, programatically) +15:38 < DeltaQ> avg doesnt seem yto go above 13kb/s +15:38 < DeltaQ> i set 64kb/s with 192 burst down +15:38 < DeltaQ> 32/64 up +15:38 <@cervantes> so a generic pushing and pulling eepget with a scheduling and management api... +15:39 <@cervantes> still, in probably ceases to become a mini-project at that point +15:39 <+Complication> DeltaQ: the average also depends on how much load your client tunnels (and other peers' participating tunnels) generate +15:39 <+Complication> sorry, s/average/actual bandwidth +15:39 < jrandom> cervantes: yeah, there's substantial logic involved in the syndie stuff though. +15:40 < DeltaQ> heh it finally went up +15:40 < DeltaQ> 1s: 30.82/29.33KBps +15:40 < DeltaQ> guess i needed up upp the ul bw +15:40 < jrandom> DeltaQ: the average will also be affected by how other people view you, which depends upon your actions, not any advertized rate, so it'll take a bit +15:40 <+Complication> DeltaQ: for pass-though traffic (participating tunnels), what comes in must also get out +15:41 <+Complication> DeltaQ: so very different ul/dl rates would choke participating traffic to the lower of the two +15:42 <+Complication> DeltaQ: also, participating traffic depends on how other nodes "perceive" your node's routing capacity +15:42 < DeltaQ> oki +15:43 <+Complication> If they think it can route well, they'll ask more often +15:43 < jrandom> ok, if there's nothing else on 3) miniprojects, lets jump on over to 4) ??? +15:43 < jrandom> anyone have anything else to bring up for the meeting? +15:43 < DeltaQ> well i am behind a router but i did map port 8887 to this pc +15:43 <+Complication> If it's new, or has only recently increased in capacity, they're a bit shy +15:44 < DeltaQ> oh sorry i didnt mean to intervere a meeting ^^ +15:44 <+Complication> Someone asked the other day, about possible attacks based on clock skew. I think I saw your answer about the tunneling part (creation message holds only tunnel validity period, not time from its creator's perspective)... +15:44 <@cervantes> (thanks for the mention in the status notes) ;-)_ +15:46 <+Complication> So I thought, actually, about asking... which points if any at all, in I2P messaging, could contain time from a sender's perspective? +15:47 <+Complication> I've not managed to dig myself up-to-date on this, so I'm a bit clueless about it +15:47 < jrandom> Complication: nothing explicitly says "I think it is now $time", but with sufficient traffic and timing analysis, one could likely narrow it down substantially +15:48 < jrandom> we do quantize the times at a large period, though not as large as our max clock skew, so there is room there +15:49 <+Complication> Do you think there would ultimately be any benefit to receive from a more "streamlined" NTP client? +15:49 <+Complication> One which would / could easier keep skews smaller? +15:50 < jrandom> well, since the sntp client was introduced into i2p, its been getting better and better so that now we don't see the variation we used to +15:51 < jrandom> perhaps we could reduce the minimum-skew limit from 10s to perhaps 2 or 3s, or maybe less +15:51 < jrandom> alternately, we could allow it to look at the ssu clock skews as well to avoid unecessary skews +15:52 <+Complication> Or alternatively, could it be possible to limit further any opportunity to guess at another peer's possible clock value? +15:53 * Complication doesn't know which way would be more practical, just suggesting random possibilities :D +15:53 < jrandom> no, we know the clock skew of directly connected peers +15:55 < Magii> is there anyway to tell if the update was done successfully? +15:55 <+Complication> Aha, so session protocol really depends on that info.. +15:55 < tethra> look at your version number +15:55 <+Complication> Magii: it should file a CRIT like "update verified, restarting to install" in logs +15:55 < tethra> :/ +15:55 <+Complication> Then, it should count down minutes to a graceful restart +15:56 <+Complication> And finally restart +15:57 <+Complication> Oh, sidenote: does the internal NTP client know of a concept like "clock drift rate"? +15:58 < jrandom> yeah, the version number on the top left corner of http://localhost:7657/index.jsp should be a giveaway :) +15:58 < jrandom> Complication: no, it doesn't guarantee sequential clock ticks +15:59 < jrandom> s/sequential/ordered/ +15:59 <+Complication> Nor develop knowledge like "our system clock is 0.00345 times faster than needed"? +16:00 < jrandom> ah, no, though adding that to net.i2p.util.Clock wouldn't be that hard (wanna miniproject? :) +16:00 <+Complication> I was thinking of something along those lines +16:01 <+Complication> I guess I'm now thinking a bit more about it :) +16:01 <+Complication> Other miniprojects first, though :) +16:02 < jrandom> ok, anyone have anything else for the meeting? +16:03 < nymisis> Muffins? +16:04 < jrandom> no, pancakes +16:04 < jrandom> (mmMMmm pancakes) +16:04 < jrandom> speaking of which +16:04 * jrandom winds up +16:04 < nymisis> Oh, darn, good point. +16:04 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/170.rst b/i2p2www/meetings/logs/170.rst new file mode 100644 index 00000000..1db07f86 --- /dev/null +++ b/i2p2www/meetings/logs/170.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 28, 2006 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/171.log b/i2p2www/meetings/logs/171.log new file mode 100644 index 00000000..745bea50 --- /dev/null +++ b/i2p2www/meetings/logs/171.log @@ -0,0 +1,72 @@ +15:08 < jrandom> 0) hi +15:08 < jrandom> 1) Net status +15:08 < jrandom> 2) ??? +15:08 < jrandom> 0) hi +15:08 * jrandom waves +15:08 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001267.html +15:09 * jrandom gives y'all hours to read through that huge tome of notes +15:10 * Complication pretends not having noticed yet ;) +15:11 <+Complication> Hi :) +15:11 <+susi23> hi :) +15:12 < jrandom> well, might as well dig on in to 1) net status +15:12 < jrandom> The mail gives my general view of whats going on. how does that line up with what y'all are seeing? +15:13 <+Complication> Throttling fixes seem to have increased reliability, but really suppressed bandwidth +15:13 <+Complication> Just a second, digging for the graph +15:14 <+Complication> http://complication.i2p/files/bw-week.png +15:14 <+Complication> High stretches are on non-latest, low stretches on latest +15:15 <+Complication> Same limiter settings, possibly more lax on stricter (latest) versions +15:16 <+Complication> But it's not much of a problem, since it does transfer +15:16 < jrandom> cool, reduced bandwidth usage is appropriate as you approach your actual bandwidth limit +15:17 <+Complication> Most of time, it seems to bounce back before the "sustained bandwidth" limit +15:17 <+Complication> Never touches the burst limit +15:18 <+Complication> (which, in itself, is sensible - it's the bouncing back before the sustained limit which concerns me) +15:19 < bar> i'm seeing pretty much what Complication is seeing. my total bw consumption is just 50% of my max settings. it used to be ~80% pre 0.6.1.11 +15:19 < jrandom> is 200kbps your limiter rate, w/ 300kbps burst? +15:20 < jrandom> (just wondering how much time it used to spend in the burst) +15:20 < jrandom> reduced bandwidth usage though is one of the aims of the recent changes +15:21 <+Complication> ~225 sustained, ~325 burst +15:21 <+Complication> Hey, I could have... +15:22 <+Complication> Have I *interpreted* it wrong? +15:23 <+Complication> Forget it, I'm a fool... did the math wrong, it's not nearly as bad :O +15:23 < jrandom> insufficient data :) it might be indicitive of a problem, but what you've described so far suggests things are behaving as desired +15:23 <+Complication> It's a bit on the conservative side, but not nearly as bad as I thought +15:24 <+Complication> According the Router Console (which measures in the same unit as the limiter) outbound total average is 2/3 of the sustained limit, and 1/2 of the burst limit +15:25 <+Complication> But inbound total average, I have to say, is only slightly above 1/3 sustained limit, and 1/4 burst limit +15:26 <+Complication> for example, assuming a sustained limit of 30, and a burst limit of 40, outbound would be 20 and inbound just above 10 (mostly due to lack of load) +15:26 < jrandom> cool +15:26 <+Complication> But the graph I misinterpreted, due to Kb/KB issues :O +15:27 * Complication wipes the graph from history +15:28 < jrandom> good eye though, definitely lemmie know when things sound funky +15:28 < jrandom> ok, anything else on 1) Net status? +15:28 < jrandom> if not, lets shimmy on over to 2) ??? +15:28 < jrandom> anyone have anything else to discuss? +15:30 <+Complication> Well, there's been some jbigi testing, and apparently, someone got results which suggested the 64-bit version for Linux being slowish +15:31 <+Complication> They had it slower than pure Java, not sure if a measurement glitch or not :O +15:32 <+Complication> I couldn't repeat it +15:32 < jrandom> yeah, i wasn't sure exactly what .so they were using for the platform +15:32 <+Complication> Over here, it was about twice faster than pure Java +15:32 <+dust> my experiments with html as an additional message format in syndie is starting to work. my local 'sucker' can now retrieve web pages (with images) and store them as syndie posts +15:33 < jrandom> ah wikked dust +15:33 <+dust> no css tho +15:33 <+Complication> But people on 32-bit spoke of it being *way* faster then pure Java (like 10x or similar) +15:35 < bar> hmm.. Complication, could it be that the current amd64 .so is for 32-bit systems only, and he tested it on a 64-bit OS? +15:36 <+Complication> bar: could be, since I tested it too on a 64-bit OS :O +15:36 < jrandom> iirc the amd64 was built to work on pure64 debian +15:37 <+Complication> Either way, some people suggested that importing a fresher gmp might help +15:37 < bar> just a stab in the dark, i'm no wiz at these things +15:37 < jrandom> eh, we use 4.1.4 +15:37 <+Complication> Especially after they've done their soon-to-come version jump +15:38 <+Complication> Since I'm no gmp specialist, I couldn't tell much about it +15:38 < jrandom> (and the upcoming optimizations in gmp aren't likely to have substantial improvement) +15:38 <+Complication> Aside from "perhaps indeed" +15:38 < jrandom> improvements come from per-arch builds +15:40 <+Complication> In my test, provoked by their test, however the 64-bit athlon lib on a 64-bit Sempron, on a 64-bit Mandriva, however... does seem only marginally quicker than pure Java +15:40 <+Complication> (oh, and a 64-bit VM) +15:41 <+Complication> (marginally being twice) +15:41 < jrandom> hmm 'k +15:42 <+Complication> I'll try testing on more platform combinations, and tell if I find anything which seems worth relaying +15:43 < jrandom> cool, thanks +15:43 < jrandom> ok, anyone have anything else for the meeting? +15:46 < jrandom> if not... +15:46 * jrandom winds up +15:47 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/171.rst b/i2p2www/meetings/logs/171.rst new file mode 100644 index 00000000..d905516a --- /dev/null +++ b/i2p2www/meetings/logs/171.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 7, 2006 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/172.log b/i2p2www/meetings/logs/172.log new file mode 100644 index 00000000..3ea5462a --- /dev/null +++ b/i2p2www/meetings/logs/172.log @@ -0,0 +1,59 @@ +15:09 <@jrandom> 0) hi +15:09 <@jrandom> 1) Net status +15:09 <@jrandom> 2) ??? +15:09 <@jrandom> 0) hi +15:09 * jrandom waves +15:09 <@jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001270.html +15:10 <@jrandom> while y'all read that massive missive, lets jump into 1) Net status +15:10 <@jrandom> the net seems to still work (woot) +15:12 < bar> got me a new udp connection high score yesterday, 244 +15:12 <@jrandom> I don't have much more to add on that front - anyone have any comments/questions/concerns? +15:12 <@jrandom> ah nice +15:12 <@jrandom> yeah, I'm hitting peak values too, currently 338 SSU connections +15:14 * jrandom has also done some substantial i2psnark transfers, though not always at great rates +15:15 <@jrandom> I've seen some interesting cyclical variations on stats.i2p regarding tunnel selection though, but that'll be seeing some changes as .0.6.1.13 rolls out +15:17 <@jrandom> I've also been doing some low(er) bandwidth testing and optimization, and thats really whats currently holding up ...13. I think we'll have some good stuff down the pipe, but we'll see how it goes +15:18 <@jrandom> ok, if there's nothing else on 1) Net status, lets move on over to the floor - 2) ??? +15:18 <@jrandom> anyone have anything they want to bring up? +15:18 <+Complication> I have only record uptimes to report, and to add that build -6 is very conservative on accepting participating tunnels +15:19 <+Complication> (but I mentioned that already earlier) +15:19 <@jrandom> nice - its doing well with the lower peer counts still, too, right? +15:19 <+Complication> Peer counts have recently risen a bit, actually +15:20 <@jrandom> ah 'k +15:20 <+Complication> They are now more like 50...100 +15:20 <+Complication> (generally more towards 50 than 100) +15:20 <@jrandom> oh, so still fairly low compared to before +15:20 <+Complication> The around-30 values seem to have been as low as it gets +15:21 <+Complication> But generally, it's doing fine +15:21 <@jrandom> great +15:26 * jrandom would like to take this moment for a brief shout-out to some recent contributors supporting I2P - special thanks go out to bar, $anon, postman, and the rest of the folks up at http://www.i2p.net/halloffame! +15:27 <@jrandom> contributions of code and content of course are critical, but financial support helps keep me out of the normal workforce and crunching on I2P fulltime, plus our varied infrastructure costs +15:28 < bar> me blushes, but thanks :) +15:28 <@cervantes> w00t +15:29 <+Complication> nice :) +15:31 < ripple> jrandom: pastebin.i2p...mission accomplished.... +15:32 <@jrandom> ripple: thanks - it looks like it behaves as desired - on OOM, it dies a fast and horrible death, which the service wrapper detects and restarts the router +15:32 <@jrandom> ok, anyone have anything else for the meeting? +15:34 < tmp> Yes, let's pray for the recovery of Betty. +15:34 * tethra prays +15:34 <@jrandom> your prayers have been answered - she's back :) +15:34 < tmp> Faith based I2P. +15:35 < tmp> Ok. ;) +15:35 < tethra> awesome +15:35 < tethra> XD +15:35 < fc> tmp: is that a transport protocol or what? +15:35 < tethra> anonymous prayer? +15:35 <@jrandom> betty == my laptop +15:35 < tethra> not even god knows who you are! +15:36 <@frosk> how about the new machine that bar so awesomely donated? +15:36 <+susi23> jr: you did not name it susi??? shame on you ;) +15:37 <@jrandom> the new machine is currently being assembled, an x86_64 (x2) box for windows, gentoo, and perhaps fbsd +15:37 <@frosk> cool +15:37 <@jrandom> (once its ready, expect some photos on my blog ;) +15:38 < fc> bsd! bsd! bsd! ;) +15:38 <@jrandom> susi23: the new one will need a new name... ;) +15:38 <@cervantes> susan! +15:39 <@jrandom> ;) +15:39 <@jrandom> ok, if there's nothing else for the meeting... +15:39 * jrandom winds up +15:39 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/172.rst b/i2p2www/meetings/logs/172.rst new file mode 100644 index 00000000..bb04995d --- /dev/null +++ b/i2p2www/meetings/logs/172.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 14, 2006 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/173.log b/i2p2www/meetings/logs/173.log new file mode 100644 index 00000000..c53a07b7 --- /dev/null +++ b/i2p2www/meetings/logs/173.log @@ -0,0 +1,116 @@ +15:09 <@jrandom> 0) hi +15:09 <@jrandom> 1) Net status +15:09 <@jrandom> 2) jrobin +15:09 <@jrandom> 3) biff and toopie +15:09 <@jrandom> 4) new key +15:09 <@jrandom> 5) ??? +15:09 <@jrandom> 0) hi +15:09 * jrandom waves +15:09 <@jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001271.html +15:11 <@jrandom> lets jump briefly on in to 1) Net status +15:12 <@jrandom> we've been a while since a release, but things still seem fairly stable. there are some improvements coming down the pipe though, and I hope to get us a new 0.6.1.13 this week +15:13 <@jrandom> anyone have any questions/comments/concerns regarding the status of the network? +15:13 <+Complication> About the periodism I noticed yesterday on a freshly started node: it desynchronized itself in a few hours +15:14 <@jrandom> ah cool +15:14 <+Complication> Meaning, the highs and lows became a lot more random +15:14 <@jrandom> I think it still may be worthwhile to jumpstart that at the beginning though +15:14 <@jrandom> (for those playing at home, we're talking about the implications of the 10m rebuild period) +15:15 <+Complication> Probably helps prevent tunnel failures +15:15 <+Complication> I'm still observing a healthy amount of those, but haven't counted +15:15 <+tethra> (thanks for the translation :) +15:15 <+Complication> Aside from that, working decently here +15:16 <+Complication> I think I get "as there are no inbound/outbound tunnels available" about once per 2 hours +15:17 <@jrandom> hmm, on an i2phex / i2psnark / eepproxy / ircproxy / eepsite destination? +15:17 <@jrandom> (its possible for clients to overload their own tunnels, which is why I ask which) +15:18 <+Complication> Checking if there's a trend +15:19 <+Complication> Bit of shared clients and Pycache, more of I2Phex +15:20 <@jrandom> hmm ok cool, thanks +15:20 <+Complication> Significantly more of I2Phex +15:20 <+Complication> Might have to limit its bandwidth +15:21 <+Complication> (was at default 16K) +15:23 <@jrandom> ok cool, anyone have anything else for 1) Net status? +15:25 <@jrandom> if not, lets shimmy on over to 2) JRobin +15:26 <@jrandom> jrobin is neat. I like it. it was dirt easy to integrate, fairly small (177KB), fast, has a low memory overhead, and provides visualizations that are easy to understand +15:27 <+Complication> Quite agreed :) +15:29 <+Complication> Convenient graphs, with high enough resolution, help find oddities and help ask about them :) +15:29 <@jrandom> if there are any rrdtool gurus out there, if you want to give the latest cvs a glance and see what we're doing and/or see if there are easier ways to accomplish these tasks, I'd love some advice +15:30 <@jrandom> (rrdtool <-->jrobin info @ http://www.jrobin.org/api/jrobinandrrdtoolcompared.html) +15:31 <@jrandom> (and, if someone wants, they could write a fairly small app to read netDb/routerInfo-*.dat, feed them into jrobin databases, and essentially run your own stats.i2p) +15:32 <@jrandom> the in-console jrobin integration is different from the stats.i2p functionality though, as it summarizes *your* router, not all routers. both are useful +15:34 <@jrandom> ok, if there's nothing else on 2) JRobin, lets swing on over to 3) biff and toopie +15:34 <@jrandom> postman: wanna give us the rundown? +15:34 < postman> aah yes +15:35 < postman> years ago the mailservice had an irc bot called biff could notify you about new mails +15:35 <+Complication> Postman's AI foundry ;P +15:35 < postman> with the migration to a new platform biff became unusauble and i had no time to revamp it +15:35 < postman> now it's back online again +15:35 <@jrandom> (yay!) +15:36 < postman> if you wish to monitor your mailbox over irc just /msg biff .help for a list of commands +15:36 < postman> usage is straightforward +15:36 < postman> question/errors/rants/flames -> postman@mail.i2p +15:36 < postman> 2. +15:37 < postman> in order to cope with the (hopefully) increasing stream of newbies jr, cervantes and me thougt of a Q&A bot that can be asked for helkp on the usual daily topics and problems +15:38 < postman> first draft is named toopie and will soon reside on #i2p (i2p-chat maybe too) +15:38 < postman> it will hold a list of topics, and Q&A sorted by topics and indexed by keywords +15:38 < postman> toopie can speak to the channel as well as privmsg with a user +15:38 <+Complication> Sounds neat, though I've never seen one before :) +15:39 < postman> we hope to fill its brain asap +15:39 < postman> Complication: you can play with it in #irc2p (in private if you wish :)) +15:39 <@jrandom> and one of the good parts about it is that we can fill it up with messages on irc :) +15:39 < postman> yes +15:40 < postman> admins can add some lines straight from irc and make it a new q&a +15:40 * tethra suggests an entry purely for the sake of TheJudge/closedshop to the effect of "No, predecessor attacks don't work." +15:40 <+tethra> ;) +15:40 < postman> hee +15:41 < postman> there is still room for the way of structuring the informationm +15:41 <@jrandom> (but they do. though they're not a particular program you "run" to attack someone) +15:41 < postman> more to come soon +15:41 * postman hand back the mike +15:41 <@jrandom> word, thanks postman +15:42 < ashter> postman; will toopie speak in other langages too ? +15:42 < postman> ashter: not (yet) +15:42 <+fox> <mihi> igpay atinlay? *g* +15:42 < ashter> ok +15:42 < postman> ashter: the infrastructure is there ( /me planned this ) +15:42 <@jrandom> word +15:42 < postman> ashter: it will be a version 2 feature +15:42 < ashter> great, really nice thank you +15:44 < postman> (thejudge makes alone 50% of alle irc disconnects today) +15:45 < postman> jrandom: ok next topic +15:46 <@jrandom> ok cool, anyone have anything else on 3) biff and toopie? +15:46 <@jrandom> if not, lets swing on by to 4) new key +15:47 <@jrandom> well, there's not really anything to add to what I posted. new key, yadda yadda +15:47 <@jrandom> ok, lets jump on over to 5) ??? +15:47 <+tethra> erm +15:47 <@jrandom> anyone have anything else to bring up? +15:48 <+tethra> how does biff know you are you? :/ +15:48 <+fox> <mihi> tethra: you have to register +15:48 <+fox> <mihi> just read what is referenced in the weekly notes :) +15:48 < postman> tethra: 1.) you know your mailboxes credentials, 2. you register with an identified nick@biff +15:48 <+fox> <mihi> yes :) +15:48 <+fox> <mihi> what is the point to have expiring keys when you could have expiring subkeys instead? +15:48 <+tethra> postman: ah, ok. thanks. +15:49 <@jrandom> mihi: to compartmentalize compromise. +15:50 <+fox> <mihi> you can delete expired secret subkeys from your keyring if you wish +15:51 <+fox> <mihi> but I guess it is much nicer to have ppl lsign your key every year :) +15:51 <+fox> <mihi> nicer in some sadistic point of view :-> +15:51 < postman> jrandom: now, riddle mihi this :) +15:52 <@jrandom> (assuming only the subkey could be compromised) +15:54 <@jrandom> in any case, anyone have anything else to bring up for the meeting? +15:54 <+fox> <mihi> assume someone compromised your key yesterday. now he can have played a mitm and replaced the new key. +15:54 <+fox> <mihi> i.e. compromise one key -> compromise all future keys, isn't it +15:55 <+Complication> Unless the owner uses a revocation certificate +15:55 <+Complication> invalidate compromised key -> invalidate future ones +15:55 <@jrandom> mihi: and I could revoke the compromised key and tell you not to trust new keys +15:55 <@jrandom> you now have the choice whether to trust the key change or not +15:56 <+fox> <mihi> whom to believe then? :) +15:56 <@jrandom> good question. if you hear a signed revocation in the next day or two, you should discard the new key +15:57 <+fox> <mihi> and if it was a subkey, you'd revoked the amin key and the subkey is automatically discarded :) +15:57 <+fox> <mihi> s/amin/main/ +15:58 <+fox> <mihi> agree to disagree? +15:58 <@jrandom> aye, that we can agree to ;) +15:58 <@jrandom> ok, if there's nothing else for the meeting... +15:58 <+fox> * mihi hands jrandom the *baf*er (after years, just like in good old times...) +16:00 <@jrandom> hehe +16:00 * jrandom winds up +16:00 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/173.rst b/i2p2www/meetings/logs/173.rst new file mode 100644 index 00000000..f4fd4128 --- /dev/null +++ b/i2p2www/meetings/logs/173.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 21, 2006 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/174.log b/i2p2www/meetings/logs/174.log new file mode 100644 index 00000000..1288a74c --- /dev/null +++ b/i2p2www/meetings/logs/174.log @@ -0,0 +1,72 @@ +15:08 < jrandom> 0) hi +15:08 < jrandom> 1) Net status and 0.6.1.13 +15:08 < jrandom> 2) Use case survey +15:09 < jrandom> 3) ??? +15:09 < jrandom> 0) hi +15:09 * jrandom waves +15:09 < Complication> Finally loaded, reading :) +15:10 < jrandom> weekly status notes posted up at dev.i2p.net/pipermail/i2p/2006-March/001274.html +15:10 <@cervantes> *** connection reset +15:10 < jrandom> heh +15:11 < jrandom> ok, while y'all dig into that, lets jump on in to 1) Net status +15:12 < jrandom> about 2/3rds of the net has upgraded to 0.6.1.13 (thanks!), and results have been mixed +15:12 < jrandom> anyone out there on low bandwidth links have any experiences they want to share? better / worse / no difference? +15:13 < jrandom> or, any results from folks on dsl-class links? +15:13 * jrandom has heard (and felt) some results on faster links (largely negative, unfortunately) +15:14 <+Complication> Well, I wanted to say that net status is a bit flaky. :) But the net said it first. :D +15:15 <+Complication> On the scale of recent disconnects, this was a very rapid recovery, though. +15:16 <+Complication> Haven't had any more massive message jams, but it still loses a lease now and then +15:17 <+Complication> Also, I think the last router run ended when a lease couldn't be renewed, so it concluded "Router hung!" +15:18 < jrandom> ah col +15:18 <+Complication> Had been ticking for 15 hours or so +15:18 < jrandom> perhaps we should adjust the watchdog to stop restarting the router under those situations +15:19 <+Complication> Retransmission is also the same as before (uncomfortably high, but apparently possible to live with - which in itself is good news) +15:19 < jrandom> the restart used to be necessary, but recurrant tunnel failure should be recoverable +15:19 < jrandom> hmm, <10%, <20%, >20%? +15:20 <+Complication> > 20% +15:20 <+Complication> I don't know many protocols which work tolerably when every third message goes missing +15:21 <+Complication> This one works :) But it used to be around 7% +15:21 < jrandom> well, thats averaged across all of the peers, so its probably quite low for most peers, but quite high for highly congested peers +15:21 < jrandom> (as shown on peers.jsp) +15:22 <+Complication> True, and I haven't taken a look at that side of the distribution yet +15:23 <+Complication> Might need to check, if for nothing else, then to verify how it's distributed +15:24 < jrandom> cool, thanks Complication +15:24 < jrandom> ok, anyone have anything else on 1) Net status? +15:25 < bar> Complication: may i ask what burst limit you are using? mine are set to 60% of my theoretical upload max, and i currently have a retransmission ratio of 11% +15:26 <+Complication> bar: it's around 80% of line speed +15:26 < bar> ok +15:26 <+Complication> On the same level as it was, when retransmission was around 7% +15:26 <+Complication> Had it higher meanwhile, but brought back down +15:28 < bar> i'll try to use 80% for a day or so to see if anything happens +15:28 <+Complication> And sustained transfer limit is around 65% +15:28 <+Complication> Actual transfer, if the total indicator is correct, averages near 60% of line speed +15:29 <+Complication> (peaks are higher) +15:30 < ashter_> for my part lot of 'no lease' thing for local destination (as i said today) +15:30 < ashter_> and a node a bit more congested +15:30 <+fox> <nextgens> hi +15:30 < jrandom> heya nextgens +15:30 < jrandom> ashter_: hmm, are you on dialup, dsl/cable, or faster? or, better said (more anonymously), are you congested? +15:31 <+fox> <nextgens> cool, jrandom is around :) you might help me :) +15:31 < jrandom> (as in, network congestion, not the numbers i2p displays) +15:31 < ashter_> dsl/cable +15:32 < jrandom> ok thanks +15:33 < jrandom> ok, if there's nothing else on 1) Net status, lets jump on over to 2) Use case survey +15:34 < jrandom> I don't expect anwers immediately, but if y'all could put some thought into the questions from the mail and post up replies (either to the forum, syndie, the list, etc), it'd be much appreciated +15:37 <@cervantes> *cough* +15:38 <+tethra> oh dear :/ +15:39 < jrandom> (|grep -v -- -\!- ;) +15:39 < jrandom> ok, as I said though, bounce word through whatever fashion you care to use at your convenience. gracias +15:39 < jrandom> movin' on to 3) ??? +15:39 < jrandom> anyone have anything they want to bring up for the meeting? +15:40 <@cervantes> http://forum.i2p.net/viewtopic.php?p=7442 <-- sticky thread for use case discussion +15:40 < jrandom> ah cool, thanks cerv +15:42 < ashter> (erf that happened once again, and when this occurs participating tunnels grows insanly :( ) +15:43 < jrandom> hmm, to the thousands, or hundreds? +15:43 < jrandom> (there are a few fixes for bursts of new tunnels pending, should be out later this week) +15:43 < ashter> thousands +15:44 < ashter> (ok thank you) +15:44 < jrandom> ok cool. you may want to conider lowering your bandwidth limit or share percentage in the meantime +15:44 < jrandom> ok, anyone have anything else for the meeting? +15:45 < jrandom> if not... +15:45 * jrandom winds up +15:46 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/174.rst b/i2p2www/meetings/logs/174.rst new file mode 100644 index 00000000..a267bd3f --- /dev/null +++ b/i2p2www/meetings/logs/174.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 28, 2006 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/175.log b/i2p2www/meetings/logs/175.log new file mode 100644 index 00000000..ea4a582e --- /dev/null +++ b/i2p2www/meetings/logs/175.log @@ -0,0 +1,126 @@ +16:21 < jrandom> 0) hi +16:21 < jrandom> 1) Net status and 0.6.1.14 +16:21 < jrandom> 2) Syndie plotting +16:21 < jrandom> 3) Local jbigi optimizations +16:21 < jrandom> 4) ??? +16:21 < jrandom> 0) hi +16:21 * jrandom waves +16:21 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-April/001275.html +16:21 * Complication reads +16:22 < jrandom> while y'all read that (briefly put together) post, lets jump on in to 1) Net status +16:23 <@cervantes> (forum back) +16:23 < jrandom> there are a few problems out there affecting use on 0.6.1.13, and most of tem have been tracked down and solved +16:24 < Complication> Over here, with the "fourth" CVS build, I noticed a change in my graphs +16:24 < jrandom> here are still a few kinks getting tested and revamped though, but a release should be out in the next few days +16:24 < Complication> In general, things moved towards more stability and less jumpyness +16:24 < jrandom> oh bugger, I forgot to increment it to -4 didn't I? +16:24 < jrandom> (ok, -5 will be out later this evening) +16:24 < jrandom> cool Complication +16:25 < Complication> But my perceptions could be influenced by jbigi too, as I didn't take steps to exclude that +16:25 < Complication> Now, after a while, retransmission has edged down to 15% too +16:28 < jrandom> hmm, i'm also seeing my average ssu rto approach the 3s ceiling as well +16:28 < jrandom> (though very low retransmission still, under 5%) +16:29 * Complication takes a second look at it +16:29 < Complication> Let's say the raw average is a little over 1500 +16:29 < Complication> (over here) +16:30 <+fox> <BrianR___> jrandom: Is there a de-facto "MTU" for i2p packets? +16:30 < jrandom> ah ok, perhapsas that inches up, the retransmission rate will go down +16:30 < Complication> I noticed mine start out with smaller MTUs, now it's upped some to 1350 +16:30 < jrandom> BrianR___: yes, either 1350 or 608 (as shown on http://localhost:7657/peers.js) +16:31 < jrandom> if the failure rate is too high at the larger MTU, it falls back to the smaller MTU (and if its too low at the smaller MTU, it jumps up to the higher MTU) +16:31 <+fox> <BrianR___> jrandom: Now is that for the inside payload or the visible IP packets? +16:31 <+fox> <BrianR___> Ie, if I were to send a block of data over an I2P stream, what would be the ideal size for the chunks to minimize overhead? +16:31 < jrandom> that is for the UDP payload +16:32 < jrandom> streams are two layers up +16:32 < jrandom> (there's fragmentation for tunnels, and then fragmentation at the stream/i2cp level) +16:32 <+fox> <BrianR___> Yes... Is there an ideal size to minimize fragmentation? +16:32 < jrandom> the ideal block size of an app using the streaming lib is "large", so that the streaming lib can use the appropriate size. +16:33 < jrandom> (aka ignore the man behind the curtain) +16:33 <+fox> <BrianR___> Aah.. Maybe I should think about pipelining or something then.. +16:34 <+fox> <BrianR___> I'm planning an app with lots of request/response traffic... +16:34 < jrandom> i'd recommend batching then to cut down on the chattyness +16:34 < Complication> Perhaps keeping traffic focused would help to some extent +16:37 < jrandom> ok, anyhing else on 1) Net status, or shall e shimmy on over to 2) Syndie plotting +16:38 * jrandom shimmies +16:39 < jrandom> this is largely a placeholder and cfp - there's going to be some substantial revamp to syndie, both in operaion and the ui, so if you've got some key features or use cases you think need to be addressed, get in touch +16:40 < jrandom> (more info will be of course forthcoming as things get fleshed out further) +16:42 < jrandom> thats all i've got to say on that for the moment, so, moving on over to 3) jbigi optimizations +16:42 <@frosk> and i had assumed "plotting" referred to some jrobin stuff in syndie :) +16:43 < jrandom> hehe +16:43 < jrandom> it'd be interesting to plot posts/day, posts/author, new authors/day, etc ;) +16:44 < Complication> Oh, on bit about Syndie (sorry, only now remembered) +16:44 < Complication> =one bit +16:44 <@frosk> which do you want, 0 or 1? :) +16:44 < Complication> Do you think it could be practical, or easy/difficult to separate favourite authors and blacklisted (spam)authors into two different lists? +16:45 < Complication> On addresses.jsp +16:45 < jrandom> oh, yeah without much trouble +16:46 < jrandom> thats a good idea for therevamp too, but perhaps we can get that into the 0.6.1.14 build +16:47 < Complication> Nah, it's not byting me, I just remembered something I noticed back then +16:47 < Complication> Anyway, jbigi gets faster on Linux/AMD64 when you compile locally and use GMP 4.2 +16:48 < jrandom> cool +16:48 < jrandom> did you compare that w/ -O3 -m64 on GMP 4.1.2? +16:48 < Complication> And I'm a damn fool for going after way wrong compile flags :O +16:48 <@cervantes> the relevant link was http://forum.i2p/viewtopic.php?t=1523&start=30 btw +16:48 < jrandom> ah thanks cervantes +16:48 < Complication> jrandom: I haven't compared yet, but will +16:49 < Complication> During next scheduled reboot +16:50 < jrandom> the jbigi build process is essentially "build GMP, then build jbigi.o, and link the two together", so any sort of optimizations people want to make on GMP can be made as the first step +16:50 <@cervantes> I've not seen much difference between -O3 and -O2 in any previous tests I've done, whether that's different under x86_64 ... *shrug* +16:50 < jrandom> aye, might be compiler rev dependent as well +16:50 < jrandom> (especially with all these 3.3/3.4/4.0/4.1 issues) +16:51 <@cervantes> just to re-iterate what I mentioned in that thread... we probably won't see windows64 optimised jbigi anytime soon +16:51 <+fox> <BrianR___> Does the i2p stream lib do payload compression? +16:52 < Complication> BrianR: yes +16:52 <@cervantes> unless someone has M$ VC 2005 w/64-bit SDK and fancies some heavy toil to get it to compile gmp +16:52 < Complication> At least to my knowledge +16:53 <@cervantes> (there was a project to port gmp into a vc project somewhere though) +16:53 < jrandom> cervantes: well, we've got one that /works/ for amd64/win, but it doesn't use the most out of the hardware ;) +16:53 < jrandom> (when my new box gets here though i may be able to tweak that, as its an amd64) +16:53 <+fox> <BrianR___> trying to figure if I should use a binary protocol to save bits or if zlib or something is going to smoosh up ascii protocol nice and small.. +16:54 <@cervantes> coolio - unfortunately Mingw64 or cygwin64 doesn't seem to be on the near horizon... +16:54 < jrandom> BrianR___: premature optimization being the root of all evil, and all that jazz... +16:55 < Complication> at least partly human readable protocols are generally easier to debug, but I guess it depends what one's doing +16:56 < Complication> ('cause some things like encryption don't like being human-readable, no matter what :) ) +16:57 < Complication> But if I2P does the encryption, and also compresses, good chances are that many things which occur on top of it, can be done with human-readable protos +16:58 < jrandom> aye +16:58 < jrandom> ok, anything else on 3) jbigi stuff? +16:58 < jrandom> if not, lets move to 4) ??? +16:59 < jrandom> anyone have anything else for the meeting? +17:01 <+tethra> i recall hearing something about anonymous collaboration tools recently +17:01 <+tethra> care to elaborate on what kind, and whether they'll be syndie-esque or not? +17:02 <@cervantes> irc and syndie is an anonymous collaboration tool :) +17:02 < jrandom> hmm, not sure of what you refer to - or maybe you mean the actual planned syndie revamps? :) +17:02 <+tethra> true. +17:02 * tethra isn't sure either, which is why he asked +17:02 <+tethra> there was talk of it on the forums - reasons for anonymity and stuff +17:03 <+tethra> i'll find the thread so i can get the quote +17:03 < jrandom> ah right +17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 +17:03 < jrandom> the use case thread +17:03 <+tethra> - anonymously hosted & publicly reachable forums/boards/wikis +17:03 <+tethra> yeah +17:04 <+tethra> is there going to be an i2wiki type project that is based around something like syndie or is it up to users? +17:04 < jrandom> there have been some good ideas in there, and some good feedback +17:05 < jrandom> the ability to edit syndie posts is an oft-requested feature, and with that, you could pull off a wiki w/ a rich editor +17:05 < jrandom> but, of course, nothing will exist in a vaccum - if someone believes that is necessary, someone should say "hey, a wiki is essential, and here's why" +17:06 < jrandom> there are an infinite number of apps that /can/ be built, but as we're aiming for strong anonymity and strong security, care must be taken in what is built +17:07 <+tethra> right +17:07 <+tethra> that said, some of the more difficult things to keep anonymous and secure might be better off being done by someone who is good at keeping things anonymous and secure, right? +17:08 < jrandom> likely so, though there is no cabal - anyone can learn +17:08 <+tethra> (key things, basically. not that i'm naming any, but hey.) +17:08 <+tethra> true +17:09 <+tethra> but learning at the cost of your own and other people's anonymity isn't the greatest way of doing it +17:10 < jrandom> everyone has to start somewhere, of course +17:10 <+tethra> (perhaps if someone made a sandbox type thing that allowed people to run $software and have people attack it and stuff that'd be good for someone who is new/inexperienced?) +17:10 <+tethra> yeah +17:14 < jrandom> ok, anyone else have anything for the meeting? +17:15 < jrandom> if not +17:15 * jrandom winds up +17:15 <@cervantes> *ahem* +17:15 * jrandom pauses +17:16 < jrandom> whats shakin' cerv? +17:16 < Complication> Neat, I found a baf ;P +17:17 < jrandom> baf-blocked ;) +17:17 <@cervantes> hups srry, continue baffing +17:17 * jrandom resumes winding +17:18 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/175.rst b/i2p2www/meetings/logs/175.rst new file mode 100644 index 00000000..7f72e5ad --- /dev/null +++ b/i2p2www/meetings/logs/175.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 4, 2006 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/176.log b/i2p2www/meetings/logs/176.log new file mode 100644 index 00000000..9e0f3142 --- /dev/null +++ b/i2p2www/meetings/logs/176.log @@ -0,0 +1,174 @@ +16:09 < jrandom> 0) hi +16:09 < jrandom> 1) Net status and 0.6.1.16 +16:09 < jrandom> 2) Tunnel creation and congestion +16:10 < jrandom> 3) Feedspace +16:10 < jrandom> 4) ??? +16:10 < jrandom> 0) hi +16:10 * jrandom waves +16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-April/001281.html +16:10 * frosk too +16:10 < jrandom> (almost two hours *before* the meeting, too :) +16:11 < jrandom> ok, since i'm sure y'all've already poured over the notes, lets jump into 1) Net status +16:12 <+Complication> Hi :) +16:12 * Complication quickly grabs the notes +16:12 < jrandom> the 0.6.1.16 release fixed a very long standing but in our prng, which had caused a substantial number of arbitrary tunnel rejections +16:13 < jrandom> (the root cause was injected last october, but is fixed now) +16:13 <+Complication> Status over here: works tolerably with 1 + 0..1 hop tunnels, won't behave with 2 + 0..1 or 2 +/- 0..1 +16:14 < jrandom> aye, thats understandable too, especially under slower links +16:14 < jrandom> (unfortunately, "slower" isn't all that slow, either) +16:15 < jrandom> there is still much work to do, and 0.6.1.16 isn't where we need to be, but its progress +16:17 <+Complication> Something I've been thinking of, with regard to what you called "congestion collapse" +16:18 <+Complication> One way to limit its impact might be to actually *require* a router to accept a certain quota of participation requests +16:19 <+Complication> (something specified by the user either directly or indirectly?) +16:19 < jrandom> specified by which user? +16:19 <+Complication> (e.g. some part of share percentage or an additional parameter) +16:19 < jrandom> the local user, or by us as remote users? +16:19 <+Complication> Specified by everyone for themselves +16:19 <@frosk> should we move over to 2) then? :) +16:20 < jrandom> aye, might as well consider us on 2) :) +16:20 <+Complication> So that I could, for example, tell my router "even if you're congested, keep routing a minimum of 4 KB/s" +16:21 < jrandom> Complication: thats not really possible - if a router is too congested, other people will (hopefully ;) stop asking them to participate in tunnels. +16:21 <+Complication> (this would, of course, mean that some local destination could be offline a while longer) +16:21 < jrandom> and if they aren't asked, they /cant/ push other people's data +16:22 <+Complication> Ah, perhaps I should have phrased it significantly clearer +16:24 <+Complication> I imagined it could, under a certain quota of participating traffic, throttle its own tunnel creation messages instead of participating tunnels +16:24 <+Complication> e.g. "I'll never throttle my participating tunnels to less than 4 KB/s. If that would be needed, I'll instead throttle my own traffic." +16:26 < jrandom> hmm, there are anonymity risks in that (though still along the same lines of selective DoS, which we don't defend against anyway) +16:27 < jrandom> but throttling our own local tunnel builds in face of congestion is something i've got in testing now - adding support tooptionally ignore the 4KBps floor should be simple enough +16:28 < spinky> Currently, you get no cover traffic at all when transferring lots of data. +16:29 < spinky> Having a floor for participation bw sounds good. +16:30 < jrandom> well, we do have a floor (both as the share percentage and an internal 4KBps reserved after all bw is assigned) +16:30 <+Complication> Bah, disconnects... I hope much wasn't lost of what I said, but any replies I'll have to read from the log :) +16:32 <@frosk> is there anything significant about 4KBps? +16:33 < jrandom> a few things - 4KB ~= sizeof(tunnel create message), and heuristically, i've never heard of a router running uccessfully on less +16:33 < spinky> Maybe it's the bugs that keep the share percentage from working then? +16:34 < jrandom> what makes you say the share percentage doesn't work? +16:34 <@frosk> i see +16:34 <+Complication> frosk: nah, it's just a number in the current code, and I referred to it while trying to explain what I imagined too +16:35 <+Complication> (not because of meaningful reasons, just because what I imagined was, in a certain sense, its equal opposite) +16:35 < spinky> It's set to 80% and participation goes to 0 when locally generating data. Perhaps I'm misunderstanding things. +16:36 < jrandom> ah, yes, thats not what the share percentage does +16:36 <+Complication> spinky: it's a maximum limit of what may be shared, subject to bandwidth actually available for sharing +16:37 <+Complication> If local traffic takes up 70%, you've only got 10% left for sharing +16:37 <+Complication> If local traffic is heavy, you'll have 0% left, and the top limit of 80% will never be touched +16:37 < spinky> Ok. I see it says 'up to'... +16:38 <+Complication> And also, there's the 4 KB/s reserve +16:38 < jrandom> ah, its share percentage of what you have available +16:38 < spinky> Maybe another setting for the floor participation bw, under which the router will accept more tunnels? +16:38 < jrandom> if you are using 95% of your bw, it will share up to 80% of the remaining 5% +16:39 <+Complication> Oh, then I've partly misunderstood it too +16:40 < fox> <zorglu1> how i2p measure the amount of bw used by other local applications ? +16:40 < spinky> (Just saying, if you consider cover traffic a good thing maybe having it configurable even under heavy local bw usage is a good thing) +16:40 <+Complication> I thought it was applied against the sustained limit +16:40 < jrandom> zorglu1: it measures i2p's bw usage, and knows i2p's bw limits +16:41 < jrandom> oh, hmm, looking back at the code, int availBps = (int)(((maxKBps*1024)*share) - used); +16:41 < jrandom> so you're right Complication +16:42 < jrandom> spinky: cover traffic is only so useful on a low latency mixnet +16:42 < jrandom> it does add some incentive for higher bw routers, but those w/out bw to spare have little recourse +16:49 < jrandom> anyway, the tunnel congestion issue has been around for a while, but only recently exacerbated by the insane tunnel rejection rates +16:49 < jrandom> hopefully the next rev will clear it up for us +16:49 < jrandom> ok, anyone have anything else on 2) tunnel creation and congestion? +16:50 <@frosk> sounds like it would take some changes to the tunnel-building scheme +16:50 <+Complication> I hope it will help improve things :) +16:51 <+Complication> Oh, by the way... +16:52 < jrandom> well, we've got some cheap fixes, such as reducing the max concurrency, throttling our build attempts when congested, reducing the drop frequency (as opposed to explicit rejection), and adjusting the profiling to incentivize explicit rejections as opposed to drops +16:52 <+Complication> ...did you perchance find anything which could explain the big disparity between raw bandwidth indicators and tunnel payload indicators? +16:52 <+Complication> (e.g. total banwidth 1 GB, tunnel payload summed up 300 MB) +16:52 < jrandom> but its true, those only affect the magnitude +16:52 <+Complication> (since I haven't been around IRC lately, I'm not sure if you've been looking at that one recently) +16:54 < jrandom> havent dug into that much, but remember, tunnel build requests for outbound tunnels aren't tunnel messages (and there are lots of them if only .1% are successful. and at 4KB each...) +16:54 * Complication isn't certain if it's the indicators, or a real effect +16:55 <+Complication> Oh... outbound build requests... indeed +16:55 < jrandom> the upcoming -1 build adds a slew of stats for monitoring per-message-type packet monitoring +16:55 <+Complication> That could be precisely it +16:55 < jrandom> (also included in those outbound build requests are build participationg requests - forwarding a reply) +16:56 < jrandom> ((so its not just local stuff)) +17:00 <+Complication> > Thanks, that explains it a whole lot :) +17:00 <+Complication> > It ain't voodoo then, but quite real traffic, which I just forgot, since it wasn't specifically counted in the places I checked +17:00 <+Complication> It would indeed have to occur, and would indeed cost a lot of bytes +17:00 <+Complication> Especially with low success rates +17:01 < jrandom> aye, though i shouldn't cost as much as it does, since we should have higher success rates than we do :) +17:01 < jrandom> ok, anything else on 2)? +17:02 < jrandom> if not, lets swing on over to 3) Feedspace +17:02 < jrandom> frosk: wanna give us an update? +17:03 < jrandom> (or tell us to fsck off and read the eepsite? ;) +17:04 <@frosk> well, for those who haven't paid attention to frosk.i2p or feedspace.i2p, feedspace is now basically working (for my own defintion of "basically) +17:04 < jrandom> (w00t) +17:05 <@frosk> there's been some nice additions lately, like infrastructural support for transports other than i2p (tor and non-anonymous tcp/ip comes to mind) +17:06 <@frosk> so in time, we plan to allow syndie (in an upcoming and probably very nice rewrite) to use feedspace as one of its syndication methods +17:06 <@frosk> for now, there aren't any client apps to actually *use* feedspace for anything :) i've been testing with an extremely crude servlet app +17:07 < jrandom> (crude + functional)++ +17:07 <@frosk> so there is of course a job opening for a client hacker ;) +17:08 <@frosk> there are still some necessary stuff that feedspace needs before any public testing, but it shouldn't be long now :) +17:08 < jrandom> nice1 +17:08 < jrandom> anything we can do to help? +17:08 <@frosk> also i've been working a bit on documentation, which has been lacking +17:09 < spinky> Do you see feedspace being usable for large files? +17:10 <@frosk> 1) client apps using the (still undocumented) xmlrpc api, 2) http://feedspace.i2p/wiki/Tasks, 3) participate in testing when that time comes +17:10 <@frosk> large files support is not a priority for now, but perhaps later +17:10 <@frosk> focus for "1.0" is smaller messages such as blog and discussion entries, and events of any sort +17:11 < jrandom> though feeding .torrent files into an rss/feedspace-enabled bt client wouldn't be a problem +17:11 <@frosk> large files may or may not work :) +17:11 <@frosk> that would be a superneat thing +17:12 < jrandom> feed2snark ;) +17:12 <@frosk> i hope we'll see all sorts of such "adapter" apps :) +17:12 <+Complication> Well, I'm sure people will find ways to move large files using bit... umm, side channels :) +17:15 <@frosk> i feel a bit guilty about the feedspace code using all sorts of java1.5 features. it would probably be hard to compile/use on free java right now, but it will catch up i'm sure :) +17:15 < jrandom> yikes +17:16 < jrandom> well, there are rumors of gcj adopting ecj for 1.5-isms +17:16 < spinky> Complication: Ponies with saddle bags full of hdds? +17:16 <@frosk> yep +17:17 <+Complication> spinky: drones, in my preferred case :P +17:17 * jrandom is still barely moving up to 1.4-isms +17:17 <+Complication> But I guess ponies work too :P +17:17 < jrandom> though 1.6 sure is nice ;) +17:17 <@frosk> to stay gcj-compatible? +17:18 <@frosk> well 1.6 doesn't have a lot of "isms" for most things anyway i think :) +17:18 <+Complication> (or flying hedgehogs airdropping memory cards) +17:18 < jrandom> gcj/classpath/etc, but also for performance (i've found 1.5 a bit heftier than 1.4) +17:19 < jrandom> true, 1.6's improvements are largely vm/bytecode specific +17:19 <@frosk> hm ok +17:20 * jrandom isn't trying to pursuade you not to use 1.5isms. i'm sure you've got your reasons, and e.g. azureus already requires 1.5 +17:21 <@frosk> well there's no going back :) hopefully it won't be too bumpy +17:24 < jrandom> aye, i'm ure it'll work out fine :) +17:25 < jrandom> ok cool, anyone have anything else on 3) feedspace? +17:25 * frosk hugs his generics and java.util.concurrent ;) +17:25 < jrandom> heheh +17:27 < jrandom> ok, if there's nothing else on 3, lets move on over to 4) ??? +17:27 < jrandom> anyone have anything else for the meeting? +17:27 <+Complication> A little question which I should have asked under 2) +17:28 <+Complication> Do you know, how do idle participating tunnels typically form? +17:28 <+Complication> Are they mostly a sign of failed tunnel builds, where only the creator really knows it failed? +17:28 <+Complication> Or do they have additional reasons? +17:28 <+Complication> (besides, of course, the obvious - namely an app sitting idle) +17:29 < jrandom> an idle app wouldn't have idle tunnels (they'd be tested) +17:29 < jrandom> idle tunnels are failed for some reason or another +17:29 < jrandom> (either failed to be creted fully, or failed during operation) +17:30 <+Complication> Right, so all tunnels are tested anyway, and tunnel testing should cause traffic... indeed +17:30 <+Complication> That actually brings me to the second part of my question: would it offer any benefit to notice that a tunnel is idle, and scrap it early? +17:31 <+Complication> Are there any precious resources to be saved there? +17:32 < jrandom> none - a tunnel that isn't pushing data isn't using up resources +17:32 < jrandom> (ok, its using up some ram, perhaps 32 bytes) +17:32 <+Complication> Or perhaps, could it help a router to keep a better picture of its load and similar parameters... +17:33 < jrandom> predictions on bw usage bsed on the tunnel history is certainly an open question +17:33 <+Complication> Or would it just be pointless work, and it's best to wait until it expires naturally? +17:33 <+Complication> (like it does now) +17:34 < jrandom> we used to do some predictions, but it didn't give us clear benefits, so we're using a simpler algorithm now +17:34 <+Complication> Aha, so no gain... +17:34 <+Complication> Thanks, that was basically all I wanted to ask about it :) +17:34 < jrandom> np, understandable concern +17:34 < jrandom> ok, anyone have anything else for the meeting? +17:35 <+Complication> Yeah, if one did predictions, the percentage of idling tunnels might tilt estimates +17:35 <+Complication> (if it varied significantly) +17:36 < jrandom> aye, we'd want to keep idle % as part of the estimate +17:36 < jrandom> (we used to - see the RouterThrottleImpl.allowTunnel method) +17:37 <+Complication> Oh, didn't know that :) +17:37 < jrandom> and note the new comment: +17:38 < jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly +17:38 < jrandom> // grounded conclusions about future use (or even the bursty use). Instead, +17:38 < jrandom> // simply say "do we have the bw to handle a new request"? +17:39 * Complication is still browsing towards the file, but thanks :) +17:39 < jrandom> w3rd +17:40 < jrandom> ok, if there's nothing else for the meeting... +17:40 * jrandom winds up +17:41 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/176.rst b/i2p2www/meetings/logs/176.rst new file mode 100644 index 00000000..a619a0aa --- /dev/null +++ b/i2p2www/meetings/logs/176.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 18, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/177.log b/i2p2www/meetings/logs/177.log new file mode 100644 index 00000000..213ec9ed --- /dev/null +++ b/i2p2www/meetings/logs/177.log @@ -0,0 +1,148 @@ +16:12 < jrandom> 0) hi +16:12 < jrandom> 1) Net status and 0.6.1.17 +16:12 < jrandom> 2) I2Phex +16:13 < jrandom> 3) ??? +16:13 < jrandom> 0) hi +16:13 * jrandom waves +16:13 <@cervantes> 'lo +16:13 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html +16:14 < jrandom> while y'all skim that, lets jump into 1) Net status +16:14 < jrandom> so, as most of y'all have seen, we've got a new release out, and so far, the results have been pretty positive +16:15 <@cervantes> (yay!) +16:15 < jrandom> still not where we need to be, but it pretty much sorts out the main issues we were seeing +16:15 < jrandom> aye, 'tis nice to have halfway decent tunnel build rates again, at 2+ hop tunnels :) +16:16 * jrandom has 50%+ success rates on another router w/ 1hop tunnels +16:17 < jrandom> I think the last few changes in 0.6.1.17 should help avoid this sort of congestion collapse in the future as well +16:17 < jrandom> the user-visible result though is that we'll occationally see lease expirations, but rather than compounding itself, it'll back off +16:17 * cervantes sparks up azureus +16:18 <+Complication> This morning, I recorded client tunnel (length 2 +/- 1) success rates near 35% +16:18 <+Complication> Currently it's lower, since I tried making some modifications, and the latest of them wasn't so great :D +16:18 <@cervantes> jrandom: well done tracking that down - we were beginning to look like freenet for a bit :) +16:19 < jrandom> *cough* ;) +16:20 <+fox> <inkeystring> jrandom: would you mind briefly describing the backoff mechanism? i'm working on something like that for freenet 0.7 at the moment +16:21 < jrandom> inkeystring: we've had a transport layer backoff mechanism in place to cut down transmissions to a peer when the transport layer is overloaded, but that wasn't sufficient +16:21 <@cervantes> *cough* did I say freenet, I meant tor +16:21 <+fox> <inkeystring> :-) +16:22 < jrandom> inkeystring: the new change was to propogate that up to a higher level so that we stopped trying to build tunnels when our comm layer was saturated +16:22 < jrandom> (rather than sending more tunnel build attempts) +16:22 <+fox> <inkeystring> thanks - does the transport layer only back off when packets are lost, or is there some way for the receiver to control the flow? +16:23 * jrandom seems to recall discussing the impact of congestion *vs* routing w/ toad a few times (on irc and my old flog), though i don't recall any net-positive solution :/ +16:23 < jrandom> the receiver can NACK, and we've got hooks for ECN, but they haven't been necessary +16:23 <+fox> <inkeystring> yeah the debate has resurfaced on freenet-dev :-) still no silver bullet +16:24 <+fox> <inkeystring> cool, thanks for the information +16:24 <+Complication> They're using UDP too these days, aren't they? +16:24 < jrandom> currently, the highly congested peers have trouble not with per-peer throttling, but with the breadth of the peer comm +16:24 <+Complication> (as the transport protocol) +16:24 <+fox> <inkeystring> breadth = number of peers? +16:24 < jrandom> yes +16:25 < jrandom> with the increased tunnel success rates, peers no longer need to talk to hundreds of peers just to get a tunnel built +16:25 < jrandom> so they can get by with just 20-30 peers +16:25 < jrandom> (directly connected peers, that is) +16:26 <+fox> <inkeystring> i guess that's good news for nat hole punching, keepalives etc? +16:26 < jrandom> otoh, w/ 2-300 active SSU connections, a 6KBps link is going to have trouble +16:26 < jrandom> aye +16:26 <+fox> <inkeystring> Complication: yes +16:27 <+fox> <inkeystring> (in the 0.7 alpha) +16:27 <+Complication> Aha, then they're likely facing some similar stuff +16:27 <+Complication> I hope someone finds the magic bullet :D +16:27 < jrandom> in a different way though. the transport layer is a relatively easy issue +16:27 <+fox> <inkeystring> i think they might have reused some of the SSU code... or at least they talked about it +16:27 < jrandom> (aka well studied for 30+ years) +16:28 < jrandom> but i2p (and freenet) load balancing works at a higher level than point to point links, and has different requirements +16:28 <+fox> <inkeystring> yeah it's the interaction with routing that's tricky +16:29 < jrandom> aye, though i2p's got it easy (we don't need to find specific peers with the data in question, just anyone with capacity to participate in our tunnels) +16:30 <+fox> <inkeystring> so there's no efficiency loss if you avoid an overloaded peer... +16:30 <+fox> <inkeystring> whereas in freenet, routing around an overloaded peer could increase the path length +16:30 <+fox> <inkeystring> anyway sorry this is OT +16:31 < jrandom> np, though explaining why the changes in 0.6.1.17 affect our congestion collapse was relevent :) +16:31 < jrandom> ok, anyone else have anything for 1) Net status? +16:32 <+Complication> Well, as actually mentioned before, while running pure .17, I observed a noticable periodism in bandwidth and active peers +16:32 <+Complication> And a few other people seem to experience it too, though I've got no clue about how common it is +16:33 <+Complication> I've been wondering about its primary causes, mostly from the perspective of tunnel throttling, but no solution yet +16:33 <+Complication> I managed to get my own graphs to look flatter, but only at the cost of some overall deterioration +16:33 <+Complication> Tried modifications like: +16:34 <+Complication> > _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); +16:34 <+Complication> (this was to avoid it totally refraining from build attempts for its own tunnels) +16:35 < jrandom> ah right +16:35 <+Complication> (oh, and naturally the loglevel is wacky, since I changed those for testing) +16:35 < jrandom> we've got some code in there that tries to skew the periodicity a bit, but it isn't working quite right (obviously) +16:36 * perv just shot his system :( +16:36 <+Complication> But I tried some things like that, and tried reducing the growth factor for tunnel counts +16:36 < perv> is there an undelete for reiser4? +16:36 < jrandom> basically, if we just act as if tunnels expire (randomly) earlier than they actually do, it should help +16:36 <+Complication> Currently reading the big "countHowManyToBuild" function in TunnelPool.java :D +16:36 <+Complication> But I've not read it through yet +16:37 < jrandom> (though it'd obviously increase the tunnel build frequency, which prior to 0.6.1.17, wouldn't have been reasonable) +16:37 <+Complication> perv: there is something +16:37 < jrandom> hmm, putting a randomization in there would be tough Complication, as we call that function quite frequently +16:38 * perv considers salvaging and switching to gentoo +16:38 < jrandom> what i'd recommend would be to look at randomizing the expiration time of successfully built tunnels +16:38 <+Complication> perv: you're better off with reiser than ext3, certainly +16:38 <+Complication> perv: but I don't know it by heart +16:38 <+Complication> jrandom: true, sometimes it could overbuild this way +16:38 < jrandom> (so that the existing countHowManyToBuild thinks it needs them before it actually does) +16:38 <+Complication> (and sometimes it inevitably overbuilds, when tunnels break and it gets hasty) +16:40 <+Complication> Hmm, a possibility I've not considered... +16:41 <+Complication> Either way, playing with it too, but no useful observations yet +16:42 < jrandom> cool, i've got some tweaks i've been playing with on that, perhaps we can get those together for the next build to see how it works on the reasonably-viable net ;) +16:43 < spinky> Is there a stat where you can see the amount of overhead the i2p network adds to the application data? +16:43 < jrandom> "overhead" is such a loaded term... ;) +16:43 < jrandom> we call it the cost of anonymity ;) +16:43 < spinky> hehe +16:45 < jrandom> (aka not really. application layer payload on a perfect net w/ 0 congestion & 1+1hops gets something like 70-80% efficiency for the endpoints) +16:45 < jrandom> ((last i measured)) +16:45 < jrandom> but thats really lab conditions +16:45 < jrandom> live net is much more complicated +16:47 < spinky> Right, I meant just the amount of extra data used for setting up tunnels, keys, padding etc +16:47 < spinky> ...compared to the application data transferred +16:47 < jrandom> depends on the message framing, congestion, tunnel build success rates, etc +16:48 < jrandom> a 2 hop tunnel can be built by the network bearing 20KB +16:48 <+Complication> I've wanted to test that sometimes, primarily with the goal of estimating the "wastefulness" of mass transfer applications like BitTorrent and I2Phex +16:48 <+Complication> But I never got around to doing a clean measurement between my two nodes +16:48 <+Complication> Some day, I'll get back to that, though +16:49 < jrandom> Complication: its pretty tough with chatty apps, much simpler to measure wget :) +16:49 <+Complication> How very true +16:50 <+Complication> In what I managed to try, no resemblance of precision was involved +16:54 < jrandom> ok, if there's nothing else on 1), lets slide on over to 2) I2Phex +16:55 < jrandom> Complication: whatcha upta? :) +16:55 <+Complication> Well, yesterday's commit was a fix to certain problems which some people experienced with my silly first-run detector +16:56 <+Complication> The first-run detector is now less silly, and bar reported that it seemed to start behaving normally +16:56 <+Complication> However, since I2Phex seems runnable already in current network conditions, +16:56 <+Complication> I'll try finding the rehash bug too. +16:57 <+Complication> If I only can +16:57 < jrandom> cool, i know that one has been haunting you for months now +16:57 <+Complication> What is interesting that mainline Phex may also have it, and locating + reading their observations is something I'll try doing too +16:58 < jrandom> but nice to hear the startup fix is in there +16:58 < jrandom> ah word +16:58 <+Complication> =is that +16:58 <+Complication> I can't confirm currently if mainline Phex has it or not, though - never seen it personally there +16:59 < jrandom> (intermittent bugs)-- +16:59 <+Complication> It's difficult to cause in controlled fashion, and thus difficult to find +17:00 <+Complication> And on my side, that's about all currently +17:00 <+Complication> Later on, I was wondering if it would be worthwhile to limit the number of parallel peer contacting attempts I2Phex fires at a time +17:01 < jrandom> aye, likely +17:01 <+Complication> Since they'd create a whole bunch of NetDB lookups in a short time, and that could be potentially not-so-nice from an I2P router's perspective +17:02 < jrandom> and new destination contacts require elG instead of aes +17:02 <+Complication> But I've not read or written any actual code towards that goal yet +17:04 < jrandom> k np. perhaps the mythical i2phex/phex merge'll bundle a solution :) +17:04 <+Complication> And on my part, that's about all the news from the I2Phex front... +17:04 < jrandom> cool, thanks for the update and the effort looking into things! +17:05 < jrandom> ok, lets jump on over to 3) ??? +17:05 < jrandom> anyone have anything else to bring up for the meeting? +17:05 < lsmith> hello! i just want to commend the devs on the fantastic improvements with the latest release, my total bw reads 0.9/1.4 KBps and i remain connected to irc... it's...insanely cool :) +17:05 <+Complication> :D +17:06 < jrandom> thanks for your patience along the way - supporting low bw users is critical +17:06 <@cervantes> lsmith: that's really good to +17:06 <@cervantes> * Connection Reset +17:06 < jrandom> heh +17:07 < lsmith> :) +17:09 < jrandom> oh, one other thing of note is that zzz is back, and with 'im comes stats.i2p :) +17:09 < jrandom> [wewt] +17:11 <+Complication> A quite useful source of comparison data :) +17:11 < jrandom> mos' def' +17:11 < jrandom> ok, anyone have anything else for the meeting? +17:13 < jrandom> if not... +17:13 < jdot> i have a post-baf question or two +17:13 < jrandom> heh ok, then lets get the baffer rollin' :) +17:13 * jrandom winds up... +17:13 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/177.rst b/i2p2www/meetings/logs/177.rst new file mode 100644 index 00000000..c34cad09 --- /dev/null +++ b/i2p2www/meetings/logs/177.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 25, 2005 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/178.log b/i2p2www/meetings/logs/178.log new file mode 100644 index 00000000..1c87757f --- /dev/null +++ b/i2p2www/meetings/logs/178.log @@ -0,0 +1,35 @@ +16:09 < jrandom> 0) hi +16:09 < jrandom> 1) Net status +16:09 < jrandom> 2) Syndie status +16:09 < jrandom> 3) ??? +16:09 < jrandom> 0) hi +16:09 * jrandom waves +16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001285.html +16:11 < jrandom> ok, while y'all read through that exciting mail, lets jump on in to 1) Net status +16:13 < jrandom> so far, it seems the whole congestion collapse issue is fixed, yand tunnel creation rates are doing pretty well. still, there are issues left to be sorted out +16:14 < jrandom> the previously discussed cyclic behavior (often running on 10-12 minute intervals) is still in place,causing rejections inversely. there's a new fix to the code as of -1 that should get rid of that though +16:15 < jrandom> (namely, randomize the tunnel expirations /correctly/, unlike the broken randomization before) +16:16 < jrandom> that, plus the improved ssu and tunnel test scheduling should help, but to what dgree, i'm not entirely sure yet +16:17 < jrandom> ok, thats about all i have on that at the moment. anyone have any questions/comments/concerns on 1) Net status? +16:18 < green> humm, max bw limits are never reached and this is really far from previous +16:18 < green> like in 1é-7 +16:18 < green> s/1é-7/.12-7 +16:18 < jrandom> how is your bw share percentage set? thats now a very powerful control +16:19 < green> 80% +16:19 < green> but only about 40% of total bw is used +16:20 < green> this is just a "do nothing router" :P +16:20 < jrandom> hmm, how often does your bw spike up to 80%, and do you often reject tunnel requests (http://localhost:7657/oldstats.jsp#tunnel.reject.30 and tunnel.reject.*) +16:21 < jrandom> the periodicity seen in tunnel requests often causes people to detect overload when it isn't really there +16:21 < jrandom> (because routers have excess capacity at other times, just not when they're being spiked) +16:22 < green> tunnel.reject.30 is very flat like 1,00 over 14 025,00 events +16:22 < jrandom> oh, sorry, its the event count theselves for that stat thats key - you've rejected more than 14,000 tunnel requests due to bandwidth overload +16:23 < jrandom> (the "value" for that stat is how many tunnels were rejected at the event, and thats always 1, since an event is caused by a message) +16:27 < jrandom> ok, if there's nothing else on 1) Net status, lets slide on over to 2) Syndie status +16:27 < jrandom> I don't have much more to add to whats in the email regarding syndie, just wanted to give an update +16:28 < jrandom> ok, as such, unless there's something someone wants to bring up wrt syndie, lets jump on to ol' faithful, 3) ??? +16:28 < jrandom> anyone have anything else they want to bring up for the meeting? +16:31 * tethra would like to say "thanks" (again) for .17, as it has been muchos improvement +16:33 < jrandom> glad to help, and there's more stuff on the way +16:33 < jrandom> ok, but if there's nothing else for toay's meeting... +16:33 * jrandom winds up +16:33 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/178.rst b/i2p2www/meetings/logs/178.rst new file mode 100644 index 00000000..c0a4662b --- /dev/null +++ b/i2p2www/meetings/logs/178.rst @@ -0,0 +1,7 @@ +I2P dev meeting, May 2, 2006 +============================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/179.log b/i2p2www/meetings/logs/179.log new file mode 100644 index 00000000..0806fb2f --- /dev/null +++ b/i2p2www/meetings/logs/179.log @@ -0,0 +1,61 @@ +16:31 < jrandom> 0) hi +16:31 < jrandom> 1) Net status and 0.6.1.18 +16:31 < jrandom> 2) baz +16:31 < jrandom> 3) ??? +16:31 < jrandom> 0) hi +16:31 * jrandom waves +16:32 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001288.html +16:32 < jrandom> while y'all read through that, lets jump on in to 1) Net status and 0.6.1.18 +16:33 < jrandom> the past week has been pretty bumpy on irc & the net in general +16:33 <+Complication> Watching the graphs, but haven't noticed a perceivable change yet +16:33 <+Complication> Only the beginning too, of course +16:34 < jrandom> aye, its only been a few hours, with under 20% of the net upgraded +16:35 < jrandom> there are still a few big guns left to deploy on the net, but I'd like things to stabilize first before pushing out major changes +16:35 <+Complication> Indeed, it helps to see (as much as seeing is possible) what changes what, and in which direction +16:36 <+Complication> If one deploys everything at once, figuring out what worked may be very tough +16:38 < tmp> *sigh* +16:38 * tmp dreams of IRC stability. +16:39 < jrandom> aye, on all fronts ;) +16:39 <+fox> <roderick_spod1> Roderick dreams of big tits. +16:39 < jrandom> (this is why we can filter the meeting logs... ;) +16:40 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.18? +16:41 < jrandom> if not, lets hop on over to 2) +16:42 < jrandom> not much more to add here, just giving a status update on some w32/w64 support +16:43 < jrandom> as mentioned in the mail, gcj doesn't really seem viable on mingw atm, though we might be able to pull some tricks +16:44 < jrandom> there is an older 3.4.4/3.4.5 gcj that works on mingw, but the classpath suport in there is pretty old. +16:45 < jrandom> (and even after stripping a bunch out of hsqldb, there are still some dependencies that 3.4.5 doesn't meet. but maybe we can hack those out too... if necessary) +16:47 < jrandom> ok, if there's nothing else, lets move on over to 3) ??? +16:47 < jrandom> anyone have anything else to bring up for the meeting? +16:48 < cervantes> just to say "nice one bar" for his cool donation +16:48 <+Complication> Well, there was a question in the forum about uptimes presented in NetDB... +16:48 * Complication seconds that +16:49 <+Complication> 'bout the uptimes, if you recall, I fuzzified them slightly in March... +16:49 < cervantes> must have missed that amongst the odci.gov rants +16:50 < tmp> What on earth are you doing on that side roderick_spod? +16:50 < jrandom> aye Complication +16:50 <+Complication> Well, since the question was raised, I wondered if they could be fuzzified further, or would it hurt ability to debug? +16:52 < jrandom> i'm not sure of the point - with careful analysis, all of the stat data can reveal a bunch of information +16:52 < arse> do you guys think the network periodicity is gonna subside +16:52 < jrandom> when its time, we will just turn off the stat publhshing whatsoever +16:52 <+Complication> We haven't recently had any router-restarting ones, but that's only recently... +16:52 < jrandom> arse: yes +16:52 <+Complication> (and partly because the watchdog lacks teeth) +16:54 <+Complication> True, it's pretty inevitable that during this phase, some info must be out there +16:55 < jrandom> also, the assumption they've made isn't correct, publishedTimeAgo is how long ago the router /received/ the netDb entry, not when it was signed +16:55 < jrandom> erm, wait, no, thats not true +16:56 < jrandom> never mind me. yeah, it just adds a small variation +16:56 <+Complication> Heh, I'm trying to post a reply, but get "no post mode specified" currently +16:57 <+Complication> Yeah, there's delay involved, and besides, how often was this info published? Not very frequently, IIRC? +16:57 <+Complication> Basically, if I offered to somewhat decrease the precision there, would you mind? +16:58 < jrandom> a new signed entry is published eery 5-15 minutes, but that is only published to the netDb, not all peers +16:58 < jrandom> peers only get the updated one when they either search for it or they reconnect +16:59 < jrandom> but yeah, adding more variation is fine. it'd affect stat.i2p's uptime plots, but as long as it keeps things reasonable, thats cool +17:01 <+Complication> I'll try to keep it reasonable, then :) +17:01 < jrandom> heh cool, thanks Complication +17:04 < jrandom> *cough* (and consistent ;) ok, anyone have anything else for the meeting? +17:04 <+Complication> sidenote: neat, the "post mode" bug yielded to persistence, and I could post a reply too :) +17:05 < jrandom> w3rd Complication +<i>offtopic messages snipped</i> +17:08 < jrandom> ok, if there's nothing else... +17:08 * jrandom winds up +17:09 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/179.rst b/i2p2www/meetings/logs/179.rst new file mode 100644 index 00000000..ef3bc533 --- /dev/null +++ b/i2p2www/meetings/logs/179.rst @@ -0,0 +1,7 @@ +I2P dev meeting, May 9, 2006 +============================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/18.log b/i2p2www/meetings/logs/18.log new file mode 100644 index 00000000..1a8dbf3e --- /dev/null +++ b/i2p2www/meetings/logs/18.log @@ -0,0 +1,170 @@ +--- Log opened Tue Nov 05 23:14:03 2002 +23:14 < logger> test +23:55 < nop> hineo +23:55 < Neo> hinop +23:57 < nop> hi hezekiah +--- Day changed Wed Nov 06 2002 +00:00 < Neo> 23:00:00.00 UTC +00:00 < nop> ok +00:00 < nop> welcome +00:00 < nop> I kind of want to wait, looks like a relay died +00:00 < nop> just another minute +00:00 < nop> so that people can re-assimilate ;) +00:01 < hezekiah> Yeah. I got bumped out about 30 seconds ago. +00:01 < nop> right +00:01 < nop> ok +00:01 < nop> ok +00:01 < nop> welcome to the n-th iip-dev meeting +00:02 < hezekiah> 18th! +00:02 < nop> I think it's like the 18th +00:02 < nop> yes +00:02 < nop> thnx +00:02 < nop> on the agenda +00:02 < nop> 1) welcome <-- we're doing this now +00:02 < nop> 2) agenda list <-- we're doing this now +00:02 < nop> 3) ;) +00:03 < nop> 4) IIP logo +00:03 < nop> 5) Dev report +00:03 < nop> 6) RC3 (coming soon, we promise) +00:03 < nop> 7) questions +00:03 < nop> . +00:03 < nop> ok we did the welcome and the agenda +00:03 < nop> let's do the ;) +00:03 < nop> ;) +00:04 < nop> Ok IIP logo +00:04 < nop> and slogan +00:04 < co> Where can we see the logos that have been submitted? +00:04 < nop> none have really been submitted +00:04 < nop> except one +00:04 < nop> and I submitted a slogan for InvisibleNet +00:04 < nop> I'll tell you mine +00:05 < nop> front part of shirt "You can't attack what you can't see..." +00:05 < nop> then back would say +00:05 < nop> InvisibleNet +00:05 < nop> then there's this other one, I'll mail to iip-dev +00:05 < nop> but no one else seems to care +00:05 < nop> so... :( +00:06 < nop> then again +00:06 < nop> no one seems to want to buy shirts for IIP anyway +00:06 < nop> so... what can ya do +00:06 < nop> yes we're working on getting black shirts +00:06 < nop> next on the agenda +00:06 < nop> Dev report +00:07 < nop> same ol' same ol' dev is working on the core control +00:08 < nop> userx will give a brief summary +00:08 < hezekiah> *applause* +00:09 < UserX> core control will provide a system for being able to support multiple cores in iip. each core is esssentially network protocol +00:10 < UserX> . +00:10 < nop> ok +00:10 < nop> thank you UserX +00:10 < nop> man of many words +00:10 < nop> ;) +00:10 < nop> or woman +00:10 < nop> never know +00:10 < nop> anyway +00:10 < nop> RC3 +00:11 < nop> it's on it's way out the door, I believe there is an openbsd compatibility that was reported and from what I know, it's been patched and cvs'd +00:11 < nop> (for some reason, I haven't got a listserv about it) +00:11 < nop> but we're hoping that this weekend would be a good time to do an RC3 upgrade +00:11 < nop> and it's not going to conflict with rc2 in any way +00:12 < nop> just mostly bug fixes +00:12 < nop> Questions +00:12 < nop> anyone? +00:12 < codeshark> so everything is in cvs now? +00:12 < dj28> yea +00:12 < dj28> i have a stupid one +00:12 < dj28> when will the IIP core server migrate away from the irc protocol? +00:12 < nop> codeshark - I believe so, please check with UserX to make sure he's comfortable with it +00:13 < nop> this is what the core control dev work puts us in a position to do +00:13 < dj28> and when will it become completely distributed? +00:13 < dj28> oh ok +00:13 < nop> so then we'll be able to build upon that +00:13 < UserX> codeshark: it will be once my server is talking to the internet again +00:13 < nop> and we hope to have 1.2 a fully distributed version +00:13 < dj28> ok. cool +00:13 < nop> at least at communication level +00:13 < nop> the routing might still be run through inform +00:14 < nop> but the communication should be decentralized +00:14 < nop> similar to how freenet 0.3 was +00:14 < dj28> yea +00:14 < nop> any other questions? +00:15 < co> So a core is a package of encryption algorithms that allow network communication? +00:15 < co> Explain that concept again, please. +00:15 < Mak> wow ...i jumped here ...sorry ... +00:16 < nop> well +00:16 < nop> a core is a network protocol +00:16 < nop> this puts us in a modular position +00:16 < nop> to possibly support many routing architectures +00:16 < Neo> oooh nice... +00:17 < nop> this could position us to support many protocols +00:18 < nop> the core control is similar to an API for cores +00:19 < nop> any more questions? +00:19 < co> Thank you. +00:19 < nop> np +00:21 < nop> oh +00:21 < nop> one more thing +00:22 < nop> Many thanks to Phiberoptika for her fine translation of the El Pais newspaper article done on IIP +00:22 < nop> it appears in spanish and with english translation (done by Phiberoptika) on the iip site www.invisiblenet.net/iip +00:22 < nop> it's a good article +00:22 < hezekiah> Cool! I'll have to check that out! Thanks, Phiberoptika! :) +00:22 < al-jabr> I have a question... +00:22 < nop> yes sir +00:22 < al-jabr> Two questions +00:22 < nop> sure +00:22 < al-jabr> I had one problem +00:23 < al-jabr> running IIP in linux, don't know if it's actually an IIP problem +00:23 < al-jabr> after I killed isproxy +00:23 < al-jabr> and tried to run again, it couldn't bind to the port +00:23 < al-jabr> had this problem a couple times, had to change the port number +00:23 < al-jabr> but when i logged of and on again (a few days later) the port was available +00:24 < al-jabr> so I'm not sure that's directly an issue with isproxy +00:24 < hezekiah> Is this reproducable, or just a random happening? +00:24 < nop> right, if you wait like 1 minute with RC2 you can rebind +00:24 < UserX> was something connected to it when you killed it? +00:24 < al-jabr> i'll try to reproduce it +00:24 < al-jabr> but +00:24 < al-jabr> no, nothing was connected to 6667 +00:25 < nop> oh that port +00:25 < nop> hmm +00:25 < al-jabr> and it happened like three or four times and i had to keep changing ports +00:25 < al-jabr> yeah +00:25 < al-jabr> not the other one +00:25 < Phiberoptika> re:article: ;)!!!, no problem chicos.. +00:25 < al-jabr> i haven't reproduced it since then, but i haven't been trying +00:25 < nop> hehe +00:25 < al-jabr> since i rarely go restarted isproxy +00:26 < al-jabr> i should probably try to. also, i was experiencing a lot of problems with the network for the last few days +00:26 < Povert> I have a question.... +00:26 < al-jabr> and i don't know if it's something local +00:26 < UserX> odd. the only reason i know for that to happen is that if the connection is closed properly it will be left hanging and you have to wait for the OS to time it out +00:26 < Povert> is de openbsd thing realy solved? +00:26 < al-jabr> or if it's not really any worse than it's usually been +00:27 < al-jabr> because, before the last couple days, i got kicked off, maybe a couple times a day at MOST, then all of the sudden i was getting kicked off every few minutes, and sometimes not getting on at all, and sometimes lagging +00:27 < UserX> al-jabr: did you try using netstat to see if there were any lingering connections to port 6667 +00:27 < al-jabr> and changing node.refs didn't seem to help +00:27 < al-jabr> no, i should have investigated that +00:27 < al-jabr> silly me +00:27 < al-jabr> i'll try it a bit more and i'll do that +00:28 < al-jabr> i didn't think that there could be connections on the other end after the server is killed +00:28 < nop> would netstat give a TIME_WAIT? +00:29 < hezekiah> Also, sometimes a process of isproxy hangs (but that only has happened to me when I'm debugging buggy code.) You should be able to check to see if there are still a hanging process of isproxy by doing: ps -e | grep isproxy +00:29 < al-jabr> i did that +00:29 < al-jabr> no isproxies were running +00:29 < hezekiah> Good. :) +00:30 < al-jabr> no, bad. +00:30 < al-jabr> but anyway, i'll investigate that some more, probably not a big issue +00:32 < Povert> nop +00:32 < Povert> is openbsd kompilation ready solved? +00:32 < Neo> diff -r1.2 sock.h +00:32 < Neo> 45c45 +00:32 < Neo> < #elif defined(__FreeBSD__) || defined(__MACH__) +00:32 < Neo> --- +00:32 < Neo> > #elif defined(__FreeBSD__) || defined(__MACH__) || defined(__OpenBSD__) +00:33 < Povert> in codetree I meen +00:34 < nop> it's about to be committed +00:34 < Povert> ok +00:34 < Povert> dank +00:34 < nop> yep +00:37 < nop> any more questions? +00:42 < nop> thanks for attending +00:42 < nop> . diff --git a/i2p2www/meetings/logs/18.rst b/i2p2www/meetings/logs/18.rst new file mode 100644 index 00000000..aac36288 --- /dev/null +++ b/i2p2www/meetings/logs/18.rst @@ -0,0 +1,9 @@ +I2P dev meeting, November 5, 2002 @ 23:00 UTC +============================================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/180.log b/i2p2www/meetings/logs/180.log new file mode 100644 index 00000000..916303e3 --- /dev/null +++ b/i2p2www/meetings/logs/180.log @@ -0,0 +1,77 @@ +< cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html +< cervantes> 0) hi +< cervantes> 1) jrandom's not here +< cervantes> 2) ??? +< cervantes> 0) hi +< cervantes> hi +< cervantes> moving on to 1) +< cervantes> jrandom isn't here today, but he'll give us a status update tomorrow +< cervantes> 2) ??? +< cervantes> does anyone have anything else to add to the meeting? +< bar> i have a question +< cervantes> in that case... +* cervantes winds up +* cervantes stops winding +< Complication> Aha, a question... +< bar> the PRNG fix in cvs, will that improve the general performace or is it related to something else? +< cervantes> it's uncertain what consequences it might have in general +< Complication> I'm personally not aware of its total impact, but it does involve at least two behaviours I'm aware of: +< cervantes> but it specifically fixes a symptom with i2ptunnel +* cervantes lets complication decomplicate +< Complication> tunnel length randomization and IRC server choice (more generically, random selection from a list of I2PTunnel destinations) +< Complication> Tunnel length randomization probably has a significant effect on overall network health, since it allows clients who are permitted to compromise on tunnel length to actually do that +< Complication> So they won't be holding breath and building 2-hop tunnels, but also try some 1-hop tunnels +< Complication> (which on hard times, are much easier to get) +< cervantes> also irc connectivity might improve once it's rolled out. Basically freshcoffee was never getting any client connections because it was second in the list - so with the next release the load should be evenly distributed between both servers +< bar> so the bug made people always go for the longer tunnel lengths if available? +< Complication> If I understood right, every randomization with smallish integers (e.g. pick 0 or 1) was affected +< Complication> I *think* randomizations with bigger integers (e.g. pick an integer between 0 and 100) were less affected +< Complication> if you're interested, you should probably ask jranom for details when he's back +< Complication> I may get the details wrong. +< bar> i see, thanks. good catch +< Complication> well, cervantes came here and started complaining about not getting any overload ;P +< cervantes> that was my understanding of it too +< cervantes> see...you don't get anything in life if you don't grumble :) +< cervantes> do any folk have other questions or topics for the meeting? +< fox> < duck> yes +< Pi> a question about general net health : i see more and more clients get left behind i2p-version wise (2 still using 0.6.1.11 and so on). won't these clients make monitoring effects of changes to the core more and more harder? (as "fewer" seem to want to update) +< fox> * duck repeats above +* w423412323 suggests a topic change along that line. ;) +< fox> < duck> I was wondering, I have seen some funky tuning commits on the cvs mailinglist. are those more experiments? are they based on observations? are they premature? +< Complication> Pi: as long as they aren't present in big numbers, they shouldn't make a big difference +< Pi> 70 of 300 clients using non-0.6.1.18-version according to my netdb now +< Complication> It's a game of numbers and capacity - if either most routers, or additionally the highest-capacity routers are reasonably updated, some people forgetting that they installed I2P shouldn't matter :) +< cervantes> Pi: if the older routers misbehave then the network _should_ adapt and reduce traffice being router via them +< cervantes> *being routed +< cervantes> Complication: did you see duck's question? +< Pi> and a question about a stat on the i2p-console which appeared some time ago : what does handle backlog mean? +< Complication> duck: would you mean the tunnel throttle adjustments? They're tuning in the sense that they won't bring much inherently new, but they should be fairly well-tested now (e.g. they probably won't byte) +< Complication> But they might byte a little, if you run an exotic setup which is completely outside the parameters I could think of +< fox> < duck> Complication: I was wondering if '2' instead of '3' thingies really mattered that much +< fox> < duck> but it seemed that the random problem might have been a big baddy +< fox> < duck> (though the relative impact of that towards network unhealth depends on when it was introduced) +< cervantes> Pi: handle backlog is the number of pending inbound tunnel join requests (quoted from the changelog) +< Complication> If you mean the random nextInteger() problem, and effect on tunnel length randomization, I feel it would have significant effect +< Complication> The cost difference of building a 1-hop and 2-hop tunnel is pretty significant +< Pi> thx, cervantes :) +< fox> < duck> when was it introduced? +< Complication> duck: I think it was introduced with some switchovers to the Fortuna generator, or some modification therein +< fox> < duck> ok; thanks a lot for your input +< Complication> Let me check the cvsweb for more detail... +< cervantes> Pi: I believe there's code in place now that drops inbound tunnel requests if the queue fills up (to help reduce cpu load) +< Complication> Pi: yes, that should be the visible indicator of another parameter used for deciding "do we have enough capacity to participate in another tunnel?" +< cervantes> duck: I certainly experience a large change in router behaviour since the fix was introduced. - not all good I have to say :) +< Complication> big handle backlog == congestion, no point in trying to join other people's tunnels +< cervantes> had a load average of 14 and 12000 participating tunnels the other day +< Complication> Handle backlog seems important particularly on high-capacity routers (referring to what cervantes saw) +< Complication> Low capacity routers generally throttle their tunnel acceptance for bandwidth reasons +< Complication> (or tunnel test time reasons, to be correct) +< Complication> (or at least, to try that) +< cervantes> wow we've managed half an hour.... +< Complication> Indeed :D +< cervantes> anyone want to bring anything else to the table? +< cervantes> in that case... +* cervantes winds up +* cervantes *baffs* the meeting closed +< fox> < duck> thx for taking care of the meeting +< cervantes> heh I was expecting to baf it closed before anything said anything....but bar ruined that plan :) diff --git a/i2p2www/meetings/logs/180.rst b/i2p2www/meetings/logs/180.rst new file mode 100644 index 00000000..ea8efae0 --- /dev/null +++ b/i2p2www/meetings/logs/180.rst @@ -0,0 +1,7 @@ +I2P dev meeting, May 16, 2006 +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/181.log b/i2p2www/meetings/logs/181.log new file mode 100644 index 00000000..14d99618 --- /dev/null +++ b/i2p2www/meetings/logs/181.log @@ -0,0 +1,52 @@ +16:00 < jrandom> 0) hi +16:00 < jrandom> 1) Net status +16:00 < jrandom> 2) Peer filtering +16:00 < jrandom> 3) Syndie status +16:00 < jrandom> 4) ??? +16:00 < jrandom> 0) hi +16:00 * jrandom waves +16:01 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html +16:01 < jrandom> (up an hour early, even [or a few weeks late, if you want to pick on me ;]) +16:02 < jrandom> ok, lets jump on in to 1) Net status +16:02 < jrandom> things arent in the shape they should be in. they're better than they were during the congestion collapse, but it should be better than it is now +16:03 < jrandom> i don't have much more to add on that though, unless anyone has any questions/concerns on 1)? +16:03 <@frosk> i get days of irc connection with .19, so no complaints here +16:04 < jrandom> nice +16:04 < jrandom> yeah, its good for some, just not good enough or consistent enough. stats in the db aren't looking that great either +16:06 < jrandom> ok, anyone have anything else on 1) Net status, or shall we move on over to 2)Peer filtering? +16:07 < jrandom> [insert moving sounds here] +16:09 < jrandom> as mentioned in the mail, the gist of things is to give our peer selection a bit of a boost. at first, it'll be a bit dangerous, allowing some active partitioning attacks, but if it works as I hope, we can avoid those +16:10 < jrandom> (but avoiding it requires essentially killing all router identities, which would essentially serve as a network reset, so i'd like to avoid that unless its worthwhile) +16:11 < bar> reset them once or repeatedly? +16:11 < bar> s/reset/killing +16:11 < jrandom> at least once, but also on all subsequent drastic config changes +16:12 < jrandom> (aka putting some criteria into the router identity's certificate, which in turn means changing the ident hash, so they can't pretend to push one setting to some people and others to others) +16:13 < bar> gotcha +16:14 < jrandom> ok, i dont think i have anything else on that topic atm, unless anyone has any questions/comments/concerns? +16:15 < jrandom> (hopefully there'll be a build out in the next day or two, release after it stabilizes) +16:17 < jrandom> ok, hitting 3) briefly.. +16:18 < jrandom> syndie is coming along, and although the amd64/amd32/x86/swt/gcj battle hasn't always been pretty, we'll have a build ready in june +16:19 < jrandom> (but still don't talk to me about mingw/gcj ;) +16:19 < jrandom> i don't have much more to add on there at the moment though, unless anyone has any questions/concerns re: the syndie revamp? +16:21 <@cervantes> how's mingw/gcj support coming along? +16:21 <@cervantes> *duck* +16:22 <@cervantes> do we get some screenies before the june release? :) +16:23 < jrandom> i'm sure i'll try to rope some eager volunteers into pre-release testing ;) +16:23 < tethrar> count me in ;) +16:23 < jrandom> w3wt +16:24 < jrandom> ok, lets swing over to the bullet point i know y'all have been waiting for: 4) ??? +16:24 < jrandom> wazaaaap? +16:24 < green> Is there any plan to have to have a "real" working I2P router with Via C7 ? jbigi give only 30% better than full java +16:25 < jrandom> is 30% still too cpu intensive? what makes it not "real"? +16:25 < jrandom> but no, i do not have the math or c7 asm skill to make a better libGMP for C7. +16:25 < green> sure too cpu intensive with 100% cpu load :P +16:26 < jrandom> 100% cpu load suggests that the problem isn't jbigi, but the fact that jbigi needs to be used too much +16:26 < jrandom> and for that, yes, there is lots we've got on the way. +16:26 < jrandom> (e.g. reducing the connection reestablishments, improving tunnel build success rates, etc) +16:27 < jrandom> ((and not getting as many tunnel requests if the router is not capable of handling them)) +16:29 < green> humm, this is with a dedicated box with 100Mb/s so It should be capable +16:30 < jrandom> no, bandwidth is not the only resource constrained here, cpu obviously is ;) +16:33 < jrandom> ok, anyone have anything else for the meeting? +16:36 < jrandom> *cough* +16:37 * jrandom winds up +16:37 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/181.rst b/i2p2www/meetings/logs/181.rst new file mode 100644 index 00000000..ec2294db --- /dev/null +++ b/i2p2www/meetings/logs/181.rst @@ -0,0 +1,7 @@ +I2P dev meeting, May 30, 2006 +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/182.log b/i2p2www/meetings/logs/182.log new file mode 100644 index 00000000..2accbbab --- /dev/null +++ b/i2p2www/meetings/logs/182.log @@ -0,0 +1,57 @@ +16:05 < jrandom> 0) hi +16:05 < jrandom> 1) Net status +16:05 < jrandom> 2) 0.6.1.21 +16:05 < jrandom> 3) ??? +16:05 < jrandom> 0) hi +16:05 * jrandom waves +16:05 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-June/001293.html +16:06 < jrandom> while y'all dig through that, lets jump on over to 1) Net status +16:07 < jrandom> the network's behavior isn't that great at the moment - it works pretty well for some people, but for others, it doesn't work at all +16:07 < modulus> .20 works pretty well for me, where .19 didn't work at all, but i guess that's just anecdote. +16:08 < jrandom> you say anecdote, i say data point :) +16:08 < jrandom> there'll be a new release tomorrow though which should improve things a bit +16:09 < jrandom> oh, i suppose thats 2)... anyone have anything else on 1) net status they'd like to discuss first? +16:10 < jrandom> if not, lets jump to 2) 0.6.1.21 +16:11 < jrandom> 0.6.1.20-7 is cvs head, and will become 0.6.1.21 sometime tomorrow +16:12 < jrandom> it should improve the ability for fast peers to handle more tunnels, which in turn should improve everyone's success rates +16:13 * jrandom currently gets ~30-60% success rates (excluding expirations) - hopefully the expirations will be cut further +16:14 < jrandom> ok, I don't have much more to add on that front- the changes are listed in the history.txt, so keep an eye out tomorrow for the release +16:14 < jrandom> (also, remember that it may take up to 12 hours to push the release out, so its probably best to either build -7 or wait until the actual announcement on the mailing list/website) +16:15 < jrandom> ok, lets shimmy on over to 3) ??? +16:15 < jrandom> anyone have anything else they want to bring up? +16:15 < user-land> are there recommendations for routers that can take the load from i2p ? +16:15 < NickyB> yes +16:15 < NickyB> about the ircproxy +16:15 < user-land> and what holds up i2p 1.0 ? :-) +16:16 < jrandom> user-land: to the first question, no (other than "patience") +16:16 < jrandom> to the second question, see the first question +16:16 < NickyB> first, sorry for my poor english. My ircProxy is set to be reachable on my lan, like all others proxy (eeproxy too) but my 6668 is reachable on the Net.... +16:17 < jrandom> NickyB: when you say on your lan, what is the *interface* it is bound to (on http://localhost:7657/i2ptunnel/index.jsp) +16:18 < jrandom> NickyB: if the interface is "0.0.0.0", yes, it will accept connections from anywhere. if its "127.0.0.1" it will only accept connections from the localhost. if its "10.0.0.123" or "192.168.1.42", then it will accept connections from your LAN +16:19 < NickyB> err, for my console, i did a change in client.config +16:19 < NickyB> clientApp.0.args=7657 192.168.0.1 ./webapps/ +16:19 < NickyB> 192.168.0.1 is the adresse gived to all my proxy +16:19 < NickyB> Reachable by: +16:20 < NickyB> LAN Hosts +16:20 < NickyB> 192.168.0.1 +16:20 < NickyB> and my 4444 is not reachable on the net, but my 6668 yes +16:20 < jrandom> NickyB: you need to stop and start that particular i2ptunnel proxy for the changes to take effect +16:21 < jrandom> though, perhaps we can continue debugging after the meeting (as this is all logged ;) +16:21 < NickyB> will try, thank you +16:21 < jrandom> np, thanks for your patience +16:21 < jrandom> ok, anyone have anything else for the meeting? +16:21 < fedo> why the .21 will not be a *mandatory* release ? i ask that because we have a lot of .12 .13 etc. routeurs. This may not help for the network health ... +16:23 < jrandom> the old routers don't hurt much, and there arent too many of them (something like 2-300 stay within 1 release of current) +16:23 < user-land> my hardware router crashed under i2p load. that is why i asked for hardware recommendations. +16:24 < jrandom> ah, sorry, misundertood your question user-land. i've been able to get by with cheap linksys and belkins, though i dont know what switches they have at the current colo +16:24 < user-land> thanks. +16:25 < jrandom> fedo: the real key of ...21 is that 1) fast routers upgrade (and they're the most likely to anyway) and 2) that users be on ...19 or higher +16:26 < fedo> ok Jr +16:26 < jrandom> ok, anyone have anything else for the meeting? +16:28 < user-land> thanks for your efforts :-) +16:28 * ashter2 seconds user-land +16:28 < user-land> and http://www.savetheinternet.com/ +16:29 < jrandom> (bah, never trust politics to defend us. use technology) +16:29 < jrandom> ok, if there's nothin' else... +16:30 * jrandom winds up +16:30 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/182.rst b/i2p2www/meetings/logs/182.rst new file mode 100644 index 00000000..978eefb4 --- /dev/null +++ b/i2p2www/meetings/logs/182.rst @@ -0,0 +1,7 @@ +I2P dev meeting, June 13, 2006 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/183.log b/i2p2www/meetings/logs/183.log new file mode 100644 index 00000000..8efac097 --- /dev/null +++ b/i2p2www/meetings/logs/183.log @@ -0,0 +1,185 @@ +16:02 < jrandom> ok, might as well get this rolling +16:03 < jrandom> hi, pre-meeting notes posted up at http://dev.i2p.net/pipermail/i2p/2006-August/001304.html +16:03 < jrandom> rather than have me essentially reread that message to y'all here, lets just skip to our standard ??? section - +16:04 < jrandom> anyone have anything they want to bring up and discuss? +16:04 <@cervantes> eerm +16:04 * cervantes scurries to read the post +16:05 <+Complication> With regard to network status, all fine over here... +16:05 <+Complication> But one question (actually relaying from forum) about the NTCP transport, +16:06 <+Complication> namely, does it sound likely that activating it could cause someone CPU load issues (they were on XP)? +16:06 <@cervantes> I have to say I've actually been seeing lower CPU usage since switching over :) +16:07 < jrandom> well, you can't *deactivate* it (unless you've been reading the source code and know the magic incantation ;) +16:07 <+Complication> The person who spoke of this problem (can't easily repeat it, and no big CPU use here) mentioned that their experience of high CPU usage seemed to correlate with NTCP +16:07 < jrandom> so, i assume they mean not accepting inbound ntcp connections +16:07 <+polecat> NTCP causes my router to instantly clock the CPU, and I repeated it twice before manually having to alter the config file to get a working router again. +16:07 < jrandom> (while still using outbound ntcp connections) +16:07 <+Complication> (over here it's only a tiny bit up from usual levels, and that's likely because of pumping *way* more data) +16:08 <+Complication> ( http://forum.i2p/viewtopic.php?t=1815 ) +16:08 < jrandom> when you establish an ntcp connection, you do a heavyweight crypto calculation (or three) +16:08 < jrandom> if you are accepting inbound ntcp connections, you may get lots of inbound attempts at once, since there are hundreds of i2p routers out there +16:09 < jrandom> polecat: that wasn't ntcp's fault, it was the fault of a bad ntp server in the ntp pool +16:09 <+polecat> Yes. So I can't handle that myself, apparantly. +16:09 < jrandom> (thanks to cervantes for tracking down that ntp server and getting the pool folks to !thwap 'em :) +16:10 < jrandom> ((and Complication for making it so we avoid those crazy bastards in the future :)) +16:10 <@cervantes> heh I think their server watchdogs only work on weekdays ;-) +16:10 <+Complication> Well, the current avoidance is pretty limited +16:10 <@cervantes> http://www.pool.ntp.org/scores/216.52.237.153 +16:11 <+Complication> I hope to get something more paranoid coded eventually +16:11 <+polecat> Oh, so enabling NTCP won't clock the CPU anymore? +16:11 < jrandom> (it never did polecat, 'twas a coincidence ;) +16:12 <+Complication> "clock" in which particular sense? +16:12 < jrandom> (see cervantes' link) +16:12 * polecat clocks Complication upside the head. +16:12 <@cervantes> whatcha smoking polecat +16:12 <+Complication> :P +16:12 <+polecat> Er, I mean, stole all clock cycles. :) +16:13 <+Complication> If it jumped 30 seconds forward or backward, it could have lost many, many sessions, and resorted to all kinds of heavy, heavy crypto +16:13 <+Complication> That could steal plenty of CPU cycles, I think +16:13 <+Complication> Indeed, perhaps the person in the forum actually saw the same, and mis-correlated it? Have to ask... +16:13 < jrandom> ah.. well, bursts of valid inbound ntcp connections will cause bursts of cpu, while outbound-only ntcp will only try to talk to so many new ntcp peers at a time +16:14 < jrandom> there is nothing wrong with not enabling inbound ntcp. +16:15 <@cervantes> Complication: the server was corrected mid-monday, so it might be worth seeing if they've had issues since then +16:15 < jrandom> ok, anyone else have something they want to discuss? +16:16 <+Complication> cervantes: indeed, could be worth a try +16:16 <@cervantes> I've had reports of some folk still losing leases periodically... is that a known problem? +16:16 <+void> how much does the ntcp implementation differ from ssu? +16:17 <+polecat> How do we tell if we lose leases? +16:18 < jrandom> void: there's a slightly higher per-message andwidth overhead in ntcp (though perhaps offset by the OS's likely-more-efficient reliable transmission implementation) +16:18 <+Complication> polecat: tunnels.jsp will show no tunnels for a particular tunnel pool (e.g. "shared clients") +16:18 < jrandom> cervantes: aye, our tunnel build success rates still aren't where they need to be +16:18 <+void> polecat: the router console says so +16:18 <+Complication> And like void says, the left sidebar of the console will tell so +16:19 <+polecat> I get those "No leases" messages a lot... that's what you mean, right? +16:19 <@cervantes> yup +16:20 <+polecat> That's usually what kills my IRC connection. Thought it was normal! +16:21 * jrandom cringes +16:24 <+tethra> lol ;) +16:25 < jrandom> ok, anyone have anything else for the meeting? +16:25 <@cervantes> jrandom: have you made any progress on syndie lately or have you had your hands full with ntcp/bug fixing/ISP hunting/bicycling ? +16:27 <+tethra> any news on feedspace, or should i just go to their eepsite? +16:28 < jrandom> when the live net hit the shitter i pushed syndie to the side. but with the net moving back on track again, syndie has been reclaiming my time, and I hope to have a small cli system out shortly (with focused guis coming after that, based on user feedback) +16:28 < jrandom> (the implemented swt gui is in pretty good shape, but its probably best to start off with the cli to adjust expectations) +16:29 * jrandom hasn't heard any news on feedspace +16:29 <@cervantes> cool +16:29 < jrandom> frosk: any word? :) +16:29 <+polecat> I'm glad you're working on syndie again. The new one does sound pretty promising. Any thoughts on ACL for stuff such as deleting blogs from a node, or doing administrative account-independant tasks? +16:30 <@cervantes> <jrandom> DELETE FROM messages WHERE postedOn < NOW()-14*24*60*60; +16:31 < jrandom> local archives will likely remain essentially trusted (since if you can access the local archive db, you can change the file however you want) +16:32 < jrandom> however, for shared blogs, yeah there's a whole set of crypto structures in place for authenticating and / or authorizing posts and changes +16:33 < jrandom> (but there'll be a way for people to view 'unauthorized' posts as well, but they'll be very much off to the side) +16:33 <+polecat> I'm sure once someone floods syndicates with thousands of giant blog posts, the technique to physically delete posts will be perfected. +16:34 <+tethra> heheh +16:35 < jrandom> physical deletion is trivial, its the question of what posts to accept in the first place ;) +16:36 < jrandom> (i have no interest in making syndie into a movie distriution platform, etc) +16:36 <+polecat> One cannot be sure of what one is accepting, until a sample has been accepted. I envision something like allowing only a whitelist of blogs, and allowing new IDs on a trial basis before adding them, insta-deleting on spam betrayal. +16:36 < jrandom> aye +16:37 <+polecat> I'm more interested in its application for colluding streams of conversation together: we could make a BBS that had no central server, just a tag in common! +16:37 < jrandom> (manually allowing new ids, manually kickbanning ids that flood, etc) +16:37 < jrandom> there's even inherent support for that in the crypto polecat :) +16:37 <+polecat> Possibly a moderator signing approved messages for the BBS, and people collecting those approval lists from the moderator's blog. +16:38 <+polecat> Ooh excellent. +16:38 <@frosk> jrandom: been working on gui stuff lately, but it's been hard to combine with starting a new job :( +16:39 * cervantes contacts Human Resources to get frosk fired +16:40 < jrandom> ah cool, hopefully once syndie is out there pushing kludged http syndication we'll tempt you on it again ;) +16:40 <@frosk> at least my boss follows i2p development now :) +16:40 * jrandom waves to frosk's boss +16:40 <@frosk> oh yes, i'm still determined (damn it!) :) +16:40 < jrandom> (gives frosk more time off, we need 'im!) +16:41 <@cervantes> hopefully he won't read about how you've been posting classified company information onto your syndie blog +16:41 < bar> gui is good, we like gui. you're forgiven. +16:41 <+Complication> Hehe :) +16:41 <@frosk> it's weird to walk into his office and catch him reading syndie :) +16:41 < jrandom> hah awesome +16:42 <+polecat> Congratulations frosk, even if you get fired in shame and infamy, at least you showed one more person how cool syndie can be. +16:43 <@frosk> hehe yeah +16:43 <+tethra> haha +16:44 <@frosk> the gui (in swt) is/will be a testbed for all things feedspace, to kickstart it +16:44 < jrandom> r0x0r +16:45 <+void> jrandom: perhaps you should cross-post everything that goes onto the mailing lists to syndie as well? +16:45 < jrandom> we should totally merge it in with the syndie swt gui (basic paradigm is a browser, though not displaying html pages in the tabs) +16:46 <+polecat> That'd be nice. I can't seem to get the mailing list anymore. +16:46 < jrandom> void: it'd be pretty easy for someone to write up a small shell script to pipe procmail into the syndie CLI +16:46 <@cervantes> are these fancy swt gui's tied into the applications? or are they tops for cli executables or use tcp etc etc +16:46 <@frosk> that makes sense +16:46 < jrandom> (iirc there's a post in my blog a while back explaining how to use the syndie cli to insert posts) +16:47 <+polecat> Currently one can make RSS feeds to feed into syndie, though it's kind of cludgy still. +16:47 < jrandom> cervantes: jdbc in event handlers, inline with jni and msvc callouts, of course ;) +16:47 * jrandom ducks +16:48 <+polecat> Microsoft Visual Classes? +16:49 <@cervantes> jrandom: so anything that can talk SQL can administer syndie then +16:49 < jrandom> (from syndie's perspective, all of the functionality is basically implemented in lots of tiny cli apps which just update the jdbc database, and there's an swt ui to browse around the db) +16:51 <+polecat> And since the database has two interfaces, JDBC, and SQL, a client communicating in either protocol can screw with syndie. +16:51 < jrandom> cervantes: well, yes and no - there's a good portion of the database thats encrypted, so not all fields are readable +16:51 <+void> will the current web interface still be there? +16:51 < jrandom> (jdbc == sql) +16:51 < jrandom> void: no +16:51 <+polecat> I thought you said that JDBC wasn't a stupid human readable protocol? +16:51 <+Complication> jdbc == java database interface, perhaps a bit similar to odbc +16:51 < jrandom> ((jdbc ~= sql)) +16:51 <+Complication> Something you talk SQL over +16:52 <+void> jrandom: what will happen to syndie.i2p/syndiemedia.i2p.net? +16:52 <+polecat> Oh. Well I never liked SQL anyway, for the record. +16:52 <@cervantes> jrandom: so it's best to create a top for syndieTools (tm) than to try and leech the data yourself +16:53 < jrandom> void: time will tell. likely they'll 1) serve as syndie's website/eepsite, 2) serve as a public archive of posts to syndicate with, and eventually, when a web interface is written, 3) serve up a web interface +16:53 <+polecat> Why not submit bytecode as database queries, instead of archaic COBOL statements? +16:53 < jrandom> aye cervantes +16:53 < jrandom> !lart polecat +16:54 <+void> hehehe +16:54 <+polecat> Ah, my secret weakness. +16:54 <@cervantes> * you have 6 larts left in your inventory, there is a door to the north and an unconsious polecat on the floor +16:54 < jrandom> cervantes: thats actually cli app #3 (extracting individual posts, which comes after app #2, listing individual posts (after #1, creating individual posts, and after #0, managing nyms))) +16:54 < jrandom> lol +16:54 <+tethra> haha +16:55 <+Complication> feature proposal: instead of bytecode, why not submit live $agency agents as database queries? ;P +16:56 <+Complication> Would be far easier to validate for safety :P +16:56 <@cervantes> jrandom: gotcha +16:56 <+tethra> do they act like carrier pigeons under the right climate, Complication? +16:56 <+Complication> tethra: only if you manage to push them through the TCP stack intact :P +16:56 <+polecat> Yes, database queries over CPP! +16:57 <+Complication> I imagine that getting wrinkled in TCP might corrupt them +16:58 <+Complication> (sorry, should really keep jokes to #i2p-chat, but sometimes can't help) +16:58 * cervantes senses a baff is soon approaching +16:58 <+Complication> database queries as shellcode? +16:59 < jrandom> ok, anyone have anything else for the meeting? +16:59 <+polecat> http://www.blug.linux.no/rfc1149/ <- we could tunnel i2p over this, really. +16:59 * Complication would rather stick with SQL +17:00 <+void> jrandom: do other langauges than java have libraries for hsqldb databases? +17:01 <+Complication> Oo would seem likely to, since they seem to use it +17:01 <+void> looks like a "no" to me +17:01 <+void> oh, hmm +17:01 <@cervantes> openoffice uses it so I would guess so +17:01 <+Complication> But I'm not sure what OpenOffice is written in +17:01 < jrandom> not that i know of. but someone could run syndie against another jdbc database (mysql, oracle, etc) +17:01 < jrandom> oo uses java +17:02 <+void> what exactly does openoffice use this database for? +17:02 <+Complication> But seems to only partially use it +17:02 < jrandom> void: for pdf generation and for their access-like database app +17:02 < jrandom> (among other things) +17:02 <+Complication> Given that it recommends an external JRE +17:02 <+void> okay +17:03 <+void> it's a pain in the ass to write portable sql though +17:03 <+Complication> if one doesn't do triggers or stored procedures, shouldn't be a big pain, though +17:04 < jrandom> eh, its not that bad, and easy to externalize +17:04 <+void> especially when aiming oracle ;) +17:05 < jrandom> actually, hsqldb supports pl/sql ;) +17:06 < bar> are there any other plans for this database, such as for stats, peer profiles, netdb..? +17:06 < jrandom> no, this is syndie only +17:06 < bar> ok +17:07 < jrandom> (though when we ship the hsqldb code, we can use it in i2p 'for free') +17:07 <@cervantes> since syndie is not an I2P application, just an application that can run over I2P correct? +17:07 < jrandom> aye cervantes, there is no dependency upon i2p +17:07 <+Complication> Good to keep Syndie portable, since it might have other transports besides I2P +17:07 < bar> right +17:08 <+Complication> However, I take it wouldn't be difficult to run many hsqldb instances on the same machine +17:08 <+Complication> So if other apps would need it, it seems they could just use it +17:08 < jrandom> trivial, and 0-cost if you just use the in-jvm dataase +17:08 <+Complication> (use their own instance, preferably) +17:10 <+void> there's no jdbc driver for sqlite? +17:11 < jrandom> dunno, never used it +17:11 <+void> ah, looks like there is *something* +17:13 < jrandom> ok, anything else for the meeting? +17:13 < jrandom> if not... +17:13 * jrandom dinws up +17:13 * jrandom steps back +17:13 * jrandom winds up +17:13 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/183.rst b/i2p2www/meetings/logs/183.rst new file mode 100644 index 00000000..c2623935 --- /dev/null +++ b/i2p2www/meetings/logs/183.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 1, 2006 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/184.log b/i2p2www/meetings/logs/184.log new file mode 100644 index 00000000..454eb601 --- /dev/null +++ b/i2p2www/meetings/logs/184.log @@ -0,0 +1,262 @@ +16:06 < jrandom> 0) hi +16:06 < jrandom> 1) 0.6.1.25 and net status +16:06 < jrandom> 2) I2PSnark +16:06 < jrandom> 3) Syndie (what/why/when) +16:06 < jrandom> 4) Syndie crypto questions +16:06 < jrandom> 5) ??? +16:06 < jrandom> 0) hi +16:06 * jrandom waves +16:06 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-September/001307.html +16:07 < jrandom> since those notes came up hours and hours ago, y'all should have already read them and have notes ready, right? ;) +16:07 < jrandom> jumping forward to 1) 0.6.1.25 and net status +16:08 < vulpine> <Complication> Regarding 0.6.1.25 seems to have worked fine over here, only one previously unseen error +16:08 < jrandom> cool, whats the prob? +16:08 < vulpine> * Complication searches logs +16:09 < jrandom> the net size seems larger than before, though still same orer of magnitude +16:09 < vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840" +16:10 < vulpine> <Complication> Started with "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)" +16:10 < jrandom> ah ok cool, that one has been around for a long time, safe to ignore +16:11 < vulpine> <Complication> Single occurrence +16:11 < vulpine> <frosk> i've gotten several of that last one +16:11 < vulpine> * jrandom pokes fox +16:12 < vulpine> <Complication> Oh, and one more: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ" +16:12 < vulpine> <Complication> (seems non-significant too, maybe simple congestion) +16:12 < jrandom> aye, likely +16:13 < jrandom> irc is, obviously, a bit rough at the moment still +16:13 < jrandom> (but, for once, its not i2p's fault :) +16:14 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.25? +16:15 < kostya213> just want to add that .25 fixed all my problems i've been having the past few months +16:15 < jrandom> wikked! +16:16 < vulpine> <green> please, change status calcul when only using NTCP +16:16 < jrandom> 'k, but its not recommended to disable udp (i believe i've explicitly said that i won't tell people how to disable udp too) +16:17 < jrandom> but the status should be updated to take into consideration that udp is not the only transport +16:17 < jrandom> i'll get that fixed in the next rev, thanks +16:17 < vulpine> <green> jrandom : sure you don't tell, but i'm able to read code ;) +16:18 < jrandom> right, though when i don't recommend something, and tell people not even to try, don't be suprised if a display message comes up confusing ;) +16:19 < vulpine> <green> sure, i could also juste display "OK" in console :) +16:19 < jrandom> true 'nuff +16:21 < jrandom> ok, lets jump on over to 2) I2PSnark +16:21 < jrandom> zzz doesn't seem to be over there atm +16:22 < jrandom> there are some changes zzz is working on to improve the scheduling in i2psnark +16:23 < jrandom> (its a bit.. simplistic atm iirc, though i'm not entirely certain of the mods zzz is hacking on) +16:23 < jrandom> ((but i look forward to the progress!)) +16:25 < jrandom> ok, if there's nothing else on 2) I2PSnark, lets move forward to 3.*) Syndie stuff +16:26 < jrandom> lets jump in to 3.1) what is syndie first, since there's so much to cover +16:27 < jrandom> i got a few questions before the meeting regarding the encryption for posts +16:27 < jrandom> basically, posts are *symmetrically* encrypted - anyone with the symmetric key can read the post, as they're authorized +16:28 < jrandom> channel replies are asymmetrically encrypted to the public key associated with the channel/forum +16:28 < jrandom> some posts can use passphrase based encryption to generate the symmetric key for reading +16:29 < jrandom> and some posts can include the symmetric key in the post's readable headers (so that anyone can read it) +16:29 < modulus> what's the point of that last one? +16:29 < jrandom> and some forums themselves can include the symmetric key in the forum metadata, so that anyone can read the post but only if they have the channel metadata +16:29 < jrandom> modulus: so that everything is always encrypted, even publicly readable stuff +16:29 < jrandom> (so that trivial wiretapping is useless) +16:30 < modulus> right, i see. +16:31 < jrandom> ok, i think that covers the encryption questions that were asked before the meeting +16:31 < jrandom> does anyone have any questions on 3.1) what is syndie? +16:31 < jrandom> (I mean, more will be clarified as it is pushed out there, of course) +16:32 < vulpine> <void> hmm +16:33 < jrandom> que tal void? +16:33 < vulpine> <void> <void> i guess that the message (.zip) archive can also include other messages, possibly from other people, such as the messages being quoted? +16:34 < jrandom> well, yes, you can include .snd files as attachments, but there is an explicit namespace, so you can do standard References: style links to previous messages +16:34 < jrandom> (aka you don't have to do frost-style "threading") +16:35 < vulpine> <void> ok, right +16:37 < vulpine> <Complication> About Syndie, I wondered how people would go about solving the problem of granting people access to some multiple-poster forum (like accounts on an ordinary message board) but not granting this irrevocably, and avoiding undesired mess when need to revoke access (for whatever reasons) occurs +16:38 < vulpine> <Complication> One solution, of course, seemed for the author to specify a recommendation of whose replies clients should display +16:38 < jrandom> Complication: create a new pub/private keypair, give the private key to (temporarily) authorized people, and include the public key as the list of "keys allowed to post" +16:38 < vulpine> <Complication> ..and for clients, unless they desire to research history, to follow this recommendation (or more specifically its latest version) +16:38 < jrandom> (and when they are no longer authorized, remove that key from the list of "keys allowed to post") +16:39 < kostya213> jrandom: you might want to use a different extension than .snd since it's a widely used extension for audio applications, mime will confuse it +16:39 < jrandom> ah, right - all forums have an "owner" (a signing private key) who can manage the list of who is allowed to post, etc +16:39 < vulpine> <Complication> "keys allowed to post" would be metadata attached to the author's latest post, or some other message, right? +16:39 < jrandom> good point kostya213, though we may be stuck with .dat then ;) +16:40 < jrandom> Complication: ah sorry, no, its like the current/old syndie- separate signed metadata posts for the forum/channel itself +16:40 < vulpine> * Complication believes that someone has even claimed .dat for something :) +16:40 < jrandom> yes, the application called "octet-stream" ;) +16:40 < vulpine> <void> it doesn't look like .syn is used for anything noteworthy +16:41 < vulpine> <Complication> Aha, special metadata posts... right, that could do it +16:41 < jrandom> oh neat, we get to syn! +16:41 < jrandom> (good eye void, thanks kostya213) +16:41 < vulpine> <void> hmm, " +16:41 < vulpine> <void> hmm, "Word Synonym File", Company: Microsoft +16:42 < jrandom> well, i'm sure we'll work 'er out +16:42 < kostya213> yes it's used by word +16:42 < vulpine> <void> but we might as well ignore that :) +16:42 < kostya213> don't lose hope, i think it's possible to find something that won't cause problems with widely used mimetypes +16:43 < jrandom> ok, anything else on 3.1) What is syndie? +16:43 < vulpine> <void> err, then again, why would we stick with three-letter extensions? it's a relic from the DOS ages +16:43 < kostya213> one thing that must be asked, why limit to a three-letter extension? nobody uses DOS anymore +16:44 < jrandom> heh +16:44 < kostya213> jinx on void +16:44 < kostya213> .syndie seems good to me +16:44 < vulpine> <void> .synd wouldn't conflict with any +16:44 < kostya213> good as well +16:45 < vulpine> <void> damn lag :( +16:48 < jrandom> ok, lets jump on over to 3.2) Why does Syndie matter? +16:48 < vulpine> <void> jrandom: wait +16:48 < cervantes> (because you say it does) +16:48 * jrandom waits +16:48 < jrandom> !thwap cervantes ;) +16:48 < vulpine> <void> the status notes post mentions that an avatar can be attached to a post, otherwise a default will be used +16:49 < vulpine> <void> but what if a person wants to have several predefined avatars instead of a single "default" one? +16:49 < jrandom> aye, the author can include a default avatar in their own channel's metadata +16:49 < vulpine> <void> attaching the other one every time isn't going to be efficient +16:49 < jrandom> good question void - lets jump to that script code in the notes +16:50 < jrandom> listauthkeys --authorizedOnly true +16:50 < jrandom> authenticate 0 +16:50 < vulpine> <void> (?) +16:50 < jrandom> listauthkeys will display all of the identities you can sign the message saying that you are, while "authenticate 0" picks an identity to sign with +16:51 < jrandom> so, that identity has its own channel, and that channel has its own metadata, which may include an avatar +16:51 < vulpine> <void> hmm, a separate identity means a separate keypair? +16:51 < jrandom> yes +16:51 < vulpine> <void> what if a person wants to have several avatars on a single identity? +16:52 < jrandom> they have a default avatar on their channel metadata, and they can override it on a per-message basis +16:52 < kostya213> dubious value +16:52 < vulpine> <void> several "default" avatars he can choose from +16:52 < vulpine> <void> or am i splitting hair here? :) +16:53 < jrandom> ah, i understand what you're saying. nah, not supported at first +16:53 < jrandom> maybe later +16:53 < vulpine> <void> true kostya213, never mind then +16:53 < vulpine> <void> :) +16:53 < jrandom> (but the avatars will be very limited in size, so shouldn't be much trouble to include) +16:53 < vulpine> * Complication thinks the adding of per-message ones could be coded to be easy enough +16:53 < vulpine> <void> so, 3.1) What is syndie? +16:53 < vulpine> <Complication> (eventually) +16:54 < vulpine> * cervantes glues the irc servers together +16:54 < vulpine> <void> Complication: jrandom just said he is going to do that already :) +16:54 < jrandom> (per message ones will be in the baseline complication, its the idea of having many 'defaults' to choose from, picking it by saying "use avatar 1" in a message rather than including the avatar itself) +16:54 < vulpine> <Complication> latency, latency... +16:54 < jrandom> ok, anything else for 3.1? +16:54 < jrandom> if not, lets jump to 3.2 +16:55 < vulpine> <void> i think that's all +16:55 < jrandom> wr0d. +16:56 < jrandom> other than cervantes' snark, anyone have any questions/comments/concernts re "why"? +16:56 < jrandom> (er, "concerns") +16:58 < vulpine> <Complication> cervantes: did you clean the surface with alcohol before applying glue on the ircd? ;) +16:58 < kostya213> imo syndie doesn't need justification, its value should be self-evident to anyone who's already interested in anonymizing networks +16:58 < kostya213> and aware of the dangers of centralization of information +16:59 < vulpine> <Complication> (repost, please ignore if reached server) +16:59 < vulpine> * Complication thinks that Syndie matters because Joe Sixpack running phpBB would suffer pwnage too quickly, and Joe Sixpack running $random_blogging_tool would suffer it too +16:59 < vulpine> <Complication> (even if probability might vary) +16:59 < vulpine> <void> indeed +16:59 < jrandom> aye, plus anyone facing actual hostile adversaries (not even necessarily state level) +17:00 < jrandom> ok, cool, just wanted to run things by y'all +17:00 < jrandom> anything else on 3.2, or shall we move over to 3.3) when can we use syndie? +17:01 < vulpine> <void> well, essentially it's a forum/blogging/e-mail/communication tool based on cryptographic primitives and independent from a transport layer +17:01 < vulpine> <Complication> ...and in the far-out scenario that Joe Sixpack's adversary would mount intersection attacks, anyone running an eepsite of any kind would suffer pwnage eventually (except in an enormous network) +17:01 < kostya213> it might be a harder sell to those who don't see immediate value in privacy/anonymity +17:01 < jrandom> kostya213: aye, though we may be able to pull some tricks, like being able to safely browse offline +17:02 < vulpine> <Complication> They might appreciate security regardless +17:02 < jrandom> (e.g. an offline rss reader that also pulls in the full set of pages referenced, not just the rss summary) +17:02 < vulpine> <void> so yeah, i can't see why it needs justification :) +17:02 < vulpine> <void> kostya213: they needn't be anonymous to use syndie +17:02 < cervantes> when can we use syndie or when will syndie be useable? +17:02 < jrandom> word void :) +17:03 < cervantes> for the text interface I imagine there needs to be a fairly hefty amount of usage documentation +17:03 < jrandom> cervantes: right now, syndie is functional (you can create posts, manage channels, read posts, reply to posts, etc) +17:03 < kostya213> jrandom: how does syndie handle redundancy? how resilient is it against content disappearing? +17:03 < cervantes> (before it's useable) +17:03 < jrandom> cervantes: there's inline menus with each command doc'ed (at least minimaly) +17:04 < cervantes> cool, any plans on some use case examples? +17:04 < jrandom> kostya213: syndie works at the content layer - redundancy is handled by something else. if you post to usenet, its replicated across usenet (for instance) +17:04 < cervantes> I think the trick will be learning how they all script together +17:04 < vulpine> <void> kostya213: that's out of the scope of syndie, it's dependant on the transport mechanism +17:04 < vulpine> <void> unfortunately +17:04 < jrandom> good idea cervantes +17:05 < jrandom> the first syndie release will include an http replication system like the old/existing syndie +17:05 < jrandom> cervantes: perhaps some of the beta users can put together their favorite scripts for us to distribute :) +17:05 < modulus> mmm, is this a console app? +17:05 < jrandom> modulus: yes, the first text based app +17:06 < modulus> excellent! +17:06 < cervantes> jrandom: provided the beta users can work out how to use it ;-) +17:06 < jrandom> hehe +17:06 * jrandom considered curses/etc, as well as cli-only, but an interactive scriptable text interface is probably the simplest and most useful +17:07 < jrandom> (sans gui, that is) +17:07 < cervantes> modulus: see, jrandom listened to your relentless feedback :) +17:07 < vulpine> <Complication> If people want, they can probably build more interactive textual interfaces on top of it +17:07 < jrandom> aye, certainly +17:08 < jrandom> (the code is built to support easy integration with an irc client, like pircbot) +17:08 < modulus> cervantes: hehe +17:09 < modulus> i guess you could put a gui on top of it too for that matter, if it works roughly as i imagine +17:09 < modulus> although that'd be lots more work. +17:09 * kostya213 waits for the emacs plugin +17:09 < modulus> hahaha +17:09 < jrandom> heh +17:09 < modulus> actually an emacs mode isn't such a bad idea, maybe would attract more crazies to it. +17:10 < cervantes> press ctrl-alt-shift-break-uparrow-num7-b to choose your identity +17:10 * jrandom will leave that to elipsers to hack through ;) +17:10 < kostya213> no offense, but i'm not sure this project needs to attract more crazies +17:10 < vulpine> <Complication> would those sort of crazies code, too? +17:11 < jrandom> hopefuly complication +17:11 < jrandom> ok, hopefully 3.3) explains a it of whats coming down the line +17:11 < jrandom> as for *when*, well, we'll see, but i'm hoping "soon" ;) +17:12 < jrandom> ok, anyone have anything else for 3.3)? +17:12 < vulpine> * Complication would welcome a few hordes of those crazies then :D +17:12 < cervantes> well there's coding and then there's writing obfuscated perl interpreted tcl +17:12 < kostya213> a plugin for FUSE might be useful too +17:13 < jrandom> aye +17:13 < jrandom> ok, lets jump on over to 4) crypto for syndie +17:13 < jrandom> anyone have any comments on those issues? +17:14 < vulpine> <Complication> I wish I had, but I'm not competent to estimate the strength of those ciphers/hashes/key lengths +17:15 < vulpine> <void> how long are elgamal/rsa signatures? 4kbit for a 2kbit key? +17:15 < vulpine> * Complication leaves that talk entirely for others +17:15 < jrandom> dunno offhand +17:15 < vulpine> <void> vs dsa? +17:16 < jrandom> (though ecc looks nice'n'tiny) +17:16 < modulus> ElGamal signatures are hard and long. as gnupg's team found out. +17:16 < jrandom> aye, though some of those tricks were related to key reuse +17:16 < vulpine> <void> ah, ok +17:16 < vulpine> <void> yeah, it does +17:16 < tethra> modulus: if they're hard and long, there's a fetish site for it +17:17 < jrandom> ok, that point was really just a heads up and call for comments whenever y'all have thoughts +17:17 < cervantes> could it not be possible to implement some kind of pluggable ciphers - when a better method of creating keys is standardised we can add that to syndie and new posts will begin using them, but can still use obsolete methods for older posts +17:17 < tethra> (sorry) +17:17 < jrandom> cervantes: it includes a DSA: prefix, so an Elg: prefix would work +17:17 < modulus> are you using 1024-limited dsa or not? +17:18 < modulus> also what has? sha1 or higher order revs? +17:18 < cervantes> so really you are just concerned with getting syndie off to a good start +17:18 < jrandom> dsa is only 1024bit (there are dsa2 proposals for longer, but they aren't standardized yet) +17:18 < jrandom> and yes, dsa requires sha1 +17:18 < modulus> hmm, my understanding is that they were quite strong pre-standards. +17:18 < kostya213> cervantes has a good point, having syndie content in fixed ciphers offers poor forward-secrecy, you never know when an algo will go titsup +17:18 < modulus> but i don't follow the process closely enough so you are probably right +17:19 < jrandom> kostya213: but choice is bad for crypto, so we should have fixed values when we can +17:19 < jrandom> (bad because of anonymity) +17:19 < vulpine> <void> do you know why aren't more people/protocols using ecc, anyway? are they afraid of the lack of research, or just worried about compatibility? +17:19 < modulus> patents. +17:20 < jrandom> patents and fud, yet some concerns in implementation +17:20 < vulpine> <void> ah, right modulus +17:20 < modulus> btw, is there are a good reason to go dsa vs rsa-sha512 for instance? +17:20 < tethra> patents and fud and the state (oh my) +17:20 < modulus> not trying to be annoying, just considering that gpg for instance has gone this way, among others. +17:20 < jrandom> haven't reviewed that option in years modulus +17:21 < modulus> obviously dsa is a standard, which speaks for it, but the keys are small and the hashes are weak. not that i think it's likely to end up being the weakest link ;-) +17:23 < cervantes> I wouldn't propose "choice" - but new versions of syndie would package increasingly secure (mandatory) ciphers +17:23 < vulpine> <Complication> Leaving some leeway in the structures for future change, seems reasonable regardless of which current crypto proves best, I'd think +17:23 < jrandom> aye, though that implies the fallback to weaker/older versions to interoperate +17:23 < jrandom> but, ok, we'll work through it +17:24 < jrandom> ok, lets jump on over to 5) ??? +17:24 < jrandom> anyone have anything else to bring up for the meeting? +17:25 < cervantes> no being able to read the latest posts from your favourite source is a good incentive to make sure everyone stays upgraded +17:25 < jrandom> to a degree +17:26 < cervantes> no=not +17:26 < jrandom> (aye, its an incentive, but people are lazy/not interested in "upgrading software", etc) +17:27 < jrandom> s/people/some people/ +17:27 < cervantes> I guess that's their issue though +17:27 < jrandom> true that +17:27 < kostya213> the i2p implementation at least can have painless upgrading +17:28 < jrandom> certainly +17:28 < cervantes> as for ??? - apologies for the irc connectivity - the ISP should be restoring one if it's major network carriers "as soon as possible" +17:29 < jrandom> w3wt +17:29 < vulpine> <Complication> To the ??? topic, I could perhaps add that the second (more extensive) part of NTP modifications is close to working, and I hope to have it committed for testing soonish +17:29 * cervantes pinches salt +17:29 < kostya213> what's the near-term plans for router development? is the roadmap accurate? +17:29 < jrandom> wikked complication +17:29 < vulpine> <Complication> It's goal is to second-guess NTP servers basing on peer clock skews +17:29 < jrandom> kostya213: stabilization until syndie is out +17:30 < jrandom> (from my perspective) +17:30 < vulpine> <Complication> (and avoid taking potentially connectivity-damaging action) +17:31 < cervantes> grand +17:32 < jrandom> ok, anything else for the meeting? +17:34 * jrandom winds up +17:34 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/184.rst b/i2p2www/meetings/logs/184.rst new file mode 100644 index 00000000..aa5829e4 --- /dev/null +++ b/i2p2www/meetings/logs/184.rst @@ -0,0 +1,7 @@ +I2P dev meeting, September 12, 2006 +=================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/185.log b/i2p2www/meetings/logs/185.log new file mode 100644 index 00000000..eb79fabe --- /dev/null +++ b/i2p2www/meetings/logs/185.log @@ -0,0 +1,79 @@ +16:01 < jrandom> 0) hi +16:01 < jrandom> 1) Net status +16:01 < jrandom> 2) Syndie dev status +16:01 < jrandom> 3) ??? +16:01 < jrandom> 0) hi +16:01 * jrandom waves +16:01 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001314.html +16:02 <+fox> * dm waves +16:02 < jrandom> w3wt, ok, while y'all read that oh-so-fun missive, lets jump on to 1) net status +16:03 < jrandom> the net seems to be maintaining the steady state right now, though with a slight growth trend +16:04 < jrandom> there are some discussions on the big cpu-related issue on the forum, though no big win yet, afaics +16:04 < jrandom> anyone have anything to bring up re: 1) net status? +16:05 < jrandom> (the last full week w/ 0.6.1.26 seems to have gone well [yay]) +16:06 <+fox> <dm> well, I better say something +16:06 <+fox> <dm> is there a consistent metric that is being used to monitor net status +16:06 <+fox> <dm> or is it just ad-hoc experiences? +16:07 <+fox> <dm> like is there an application out there that tries to connect to random places every day while measuring response times and failures. +16:07 < jrandom> i'm going largely by irc behavior, as well as the stats and activity on the routers i run (stats.i2p is down for a week or two, but it usually is a solid enchmark to run against) +16:08 <+fox> <dm> cool, I'll check that site out. +16:08 < jrandom> there are several people running stat monitoring apps - orion.i2p, tino.i2p, eepsites.i2p, as well as stats.i2p +16:09 <+fox> <dm> thank you! +16:09 < jrandom> np :) +16:09 < jrandom> ok, if there's nothing else on 1), lets jump on over to 2) syndie dev status +16:10 < jrandom> lots going on, as mentioned in the status notes (and you can finally see a non-hideous-looking website at syndie.i2p.net :) +16:11 <+fox> <dm> down at the moment? +16:11 <+fox> <dm> scratch that +16:11 <+fox> * dm shuts up +16:11 < jrandom> :) +16:12 < marlowe> jrandom, the diagram on the front page is very helpful +16:12 < marlowe> i know understand the concept behind syndie +16:12 <+fox> <dm> it's pretty as well +16:13 <+fox> <dm> but how do you access syndie without download/installing it? I remember you could do this before? +16:13 < jrandom> great, glad its clear marlowe - it can be a confusing concept in just text :) +16:13 < jrandom> dm: the old syndie (syndiemedia.i2p.net/) was web based, but this new one is, well, brand new, completely redesigned +16:14 <+fox> <dm> it's not web-based? +16:14 < jrandom> (and thanks to cervantes for turning my ugly ms-paint-style image into the slick pic you see there :) +16:14 < jrandom> no, its not web based - current release is actually text only, but work continues on a gui +16:14 < jrandom> http://syndie.i2p.net/roadmap.html +16:14 <+fox> <dm> text-only! wow. ok. downloading. +16:14 < jrandom> w3wt +16:15 < jrandom> one important thing you need to know to effectively use it is the location of a syndie archive that you can push posts to and pull posts from +16:15 <+fox> <dm> wow.. this is hardcore stuff. (Next Command:) hehhehe +16:15 < jrandom> there's currently one at http://syndie.i2p.net/archive - you can sync up with that via "menu syndicate" "getindex --archive http://syndie.i2p.net/archive" and "fetch" :) +16:16 < jrandom> its a fairly simple system, though with very specific design features +16:16 < jrandom> (and incredibly robust - it can run on anything :) +16:17 <+fox> <dm> there's something cool about really complex apps running with a text frontend +16:17 <+fox> <dm> anyway... +16:17 <+fox> * dm shuts up again +16:19 * jrandom hopes to bring us up to 1.0 sometime this month, so beta testing would be great +16:20 < jrandom> (kick the tires, tell me whats broken, etc) +16:20 < jrandom> 1.0 won't include the gui, of course, thats 2.0 +16:20 <+fox> <dm> of course +16:21 < jrandom> ok, anyone have any comments/questions/suggestions/toenails on 2) Syndie dev status? +16:22 < jrandom> oh, one thing i wanted to bring up - as i posted in my syndie blog, we need a logo! so, see urn:syndie:channel:d7:channel44:bF2lursCrXhSECJAEILhtXYqQ6o-TwjlEUNJLA5Nu8o=9:messageIdi1160962964161ee :) +16:23 <+fox> <dm> there's a good place to get free or semi-free very high quality logos +16:24 < jrandom> flickr? :) +16:24 <+fox> <dm> http://www.worth1000.com/ <--- photoshop geeks around try to outdo each other for a little fame and/or money +16:24 < jrandom> ah cool +16:25 <+fox> <dm> example of a previous 'contest' http://www.worth1000.com/cache/contest/contestcache.asp?contest_id=12170&start=1&end=10&display=photoshop +16:25 <+fox> * dm shuts up again +16:26 < jrandom> wikked, thanks dm +16:27 < jrandom> ok, if there's nothing on 2, lets jump to 3) ??? +16:28 < jrandom> anyone have anything else for the meeting? +16:28 < bar> perhaps we should save that for the 1.99b version and have a little contest/bounty thing going to plug syndie 2.0? +16:28 < jrandom> ah, thats a good idea, since 1.* is going to be text anyway +16:30 < bar> think about it, i'm sure we can dig up some funding +16:30 <+fox> <dm> how's funding going anyway? +16:31 <+fox> <dm> are you still doing this full-time jr? +16:31 < jrandom> aye, still getting by, thanks to some insanely generous contributors (thanks!) +16:31 < jrandom> http://www.i2p.net/halloffame +16:32 <+fox> <dm> ah yes.. the shoestring budget. I remember now +16:32 < jrandom> hehe +16:34 < jrandom> ok, anyone have anything else to bring up? +16:34 <+fox> <dm> just dropped you a c-bill. Make sure it's only used for alcohol or other frivolous uses. +16:34 <+fox> <dm> oh and keep my real name secret! +16:34 < jrandom> w00t! thanks dm +16:36 < jrandom> ok, if there's nothing else... +16:36 * jrandom winds up +16:36 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/185.rst b/i2p2www/meetings/logs/185.rst new file mode 100644 index 00000000..064df69d --- /dev/null +++ b/i2p2www/meetings/logs/185.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 17, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/186.log b/i2p2www/meetings/logs/186.log new file mode 100644 index 00000000..25059457 --- /dev/null +++ b/i2p2www/meetings/logs/186.log @@ -0,0 +1,97 @@ +16:03 < jrandom> 0) hi +16:03 < jrandom> 1) Net status +16:03 < jrandom> 2) Syndie dev status +16:03 < jrandom> 3) ??? +16:03 < jrandom> 0) hi +16:03 * jrandom waves +16:03 * Complication stumbles to somewhere within reach of keyboard (week's beginning was hell, but it's over now) +16:04 < jrandom> (hooray to hellish beginnings!) +16:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001315.html +16:04 <+Complication> Hello +16:05 < jrandom> while y'all read the (short) notes, lets jump to 1) Net status +16:05 * jrandom has been connected to freshcoffee for 3 days now w/out discon, and it looks like both of the irc servers have a good number of users on them +16:06 < jrandom> stats.i2p is back too, and the tunnel success rate has been doing some odd jumps, but generally in good shape too +16:06 < jrandom> (though still in the 20-30 range) +16:06 < jrandom> ((which is much better than 5-10, but much worse than 60-80)) +16:07 < jrandom> ok, anyone have anything to bring up for 1) net status? +16:08 <+Complication> Similar here, but no extra-persistent connections +16:08 <+tethra> other than applause, nothing from me! +16:08 <+Complication> I just wanted to drop a little line related to NTP issues +16:09 <+Complication> Basically, on Sunday, Oct 29, some times zones will jump off dailight saving time +16:09 < jrandom> (its going to suck) +16:10 <+Complication> I personally hope it doesn't cause anyone any problems, but I'm not well versed enough in NTP to be sure +16:10 <+Complication> So, just in case the recent NTP server sanity check (added with version .26) should inconvenience someone that night... +16:11 <+Complication> ...I thought it'd be better if I mentioned the configuration key using which it can be disabled (if need should exist) +16:11 <+Complication> (so folks who read status notes would know) +16:12 <+Complication> Disabling it can be done by entering the line "router.clockOffsetSanityCheck=false" into http://localhost:7657/configadvanced.jsp +16:12 <+Complication> But as mentioned, I do hope nobody needs that +16:13 <+Complication> It will be interesting to watch and see how the network behaves that night, though, as different time zones start switching +16:13 <+Complication> I'll certainly observe, in hope that if any anomaly is seen, perhaps it can be fixed by Spring :D +16:14 < jrandom> the minute-of will probably be pretty jumpy, but should heal shortly +16:14 <+Complication> ...and that's all I had. :) +16:14 < jrandom> but, hopefully it'll work out, and if not, as you say, there's spring :) +16:14 < bar> and should things indeed b0rk, there were two possible suggestions for future improvement that surfaced in the chat the other day: +16:15 < bar> "prevent skewed routers from forming subnets by handing over control to NTP if peers < some number" +16:15 < bar> ...and "do not delete floodfill peer router infos from netdb if there are too few of them" +16:15 < jrandom> aye +16:16 <+Complication> Indeed, adjusting the required number of data points (available peer clock skews) which are required to deem peer skew measurements reliable +16:16 <+Complication> (oops, some redundancy in my last sentence) +16:17 <+Complication> ...and yes, the floodfill check. I take that no similar check exists currently? +16:18 < jrandom> right +16:18 <+Complication> Seems like some people, sometimes, either with luck or magic, may be managing to lose track of floodfill peers +16:19 < jrandom> that should certainly be remedied +16:19 < jrandom> (it hit some folks the other day, when one of 'em was null routed) +16:20 < jrandom> (if #floodfill == 0, perhaps randomly treat a few as floodfill) +16:20 <+Complication> If that's doable, possible also +16:21 <+Complication> Though, perhaps doing that in addition to keeping at least 2 (or something like that) floodfill peers would be a doubly safe bet +16:22 < jrandom> aye +16:25 < jrandom> ok, anyone have anything else for 1) net status? or shall we move on over to 2) syndie dev status? +16:25 < badger> re irc stability: seeing much much much fewer reconnects at the server end. +16:25 < badger> you could almost call it a service :) +16:26 < jrandom> :) +16:28 < jrandom> ok, jumping on to 2) syndie dev status +16:28 < jrandom> lots of progress here, as mentioned in the status notes +16:28 < jrandom> there's also been a bunch of discussion on it here over the last few days +16:28 < jrandom> anyone have anything they want to bring up on that front? +16:30 <@cervantes> install something other than mspaint +16:30 < jrandom> heh +16:30 < jrandom> well, there's value in using *ugly* things to sketch - limits expectations +16:31 <+fox> <HotTuna> the links in the forumpost seem to be down ... some are anyway.. +16:31 <@cervantes> I think that's mentioned in the posts +16:31 <+fox> <HotTuna> oh. . sorry +16:31 < jrandom> hottuna: they're mirrored @ dev.i2p.net/~jrandom/mockup/ +16:31 <@cervantes> some should be mirrored further down +16:32 <+Complication> One question: so, do you think it's easier to (safely) implement limited HTML from ground up, without picking apart some web browser? +16:33 * jrandom just uploaded two more pics: dev.i2p.net/~jrandom/mockup/forum.png and blog.png (showing the discussion of the last few days regarding different ways to view a forum) +16:33 <@cervantes> most definitely easier to do that safely +16:33 <+Complication> (just being curious as to what's going in on the GUI side, having been somewhat unaware of it) +16:33 < jrandom> Complication: i've got nearly everything done for general formatting purposes already +16:33 <@cervantes> especially given the limited subset of html that syndie will support +16:34 <+Complication> Aha +16:34 < jrandom> (fonts, alignment, sizes, colors, images, links, lists (including nested), headers, paragraphs, html entities) +16:35 < jrandom> now, going in and doing divs for placement or tables requires substantially more work, but i'm not tackling that now +16:35 <+Complication> Sounds nice enough +16:36 <@cervantes> and of course the <blink> tag +16:36 * jrandom pelts cervantes with † +16:37 <@cervantes> ouch, skewered by an entity +16:37 < jrandom> we'll see though. as it gets deployed and used, perhaps it'll be necessary to switch to a full blown html rendering engine +16:38 * jrandom wants the codebase to be as small as possible though, so there is less to debug and review for security and anonymity issues +16:39 <+Complication> Indeed, there are doubtless benefits to handling text/plain +16:40 <+Complication> (which hopefully only supports natural-language attacks ;P ) +16:41 <+Complication> What are your opinions about the possibility of hashcash antispam measures? Too early to tell? Do you think they'd be easy to tack on later? +16:42 <@cervantes> well I guess using bbcode or wiki syntax would reduce the risk of markup injection in a full html engine +16:42 <@cervantes> *rendering engine +16:43 < jrandom> quite easy to tack on Complication - just a new public header (hashcalc'ed against the canonical syndie uri, verified on import, created on signing) +16:44 * Complication thought about some a few days back, but only lightly +16:44 < jrandom> the hashcash can be done at several levels too - per new channel (meta.syndie), per updated channel, or per post (perhaps even graduated against sizeof(post) or #msgs/day) +16:44 <+Complication> If one wanted to implement hashcash as proof of work, I wonder what the poster of the message would be best required to caclulate collisions against? +16:45 <+Complication> Aha, the uri... might be indeed +16:45 <+Complication> Oh, indeed +16:45 <+Complication> That's some things I didn't think about +16:48 < jrandom> cervantes: true enough +16:48 < jrandom> ok, anyone have anything else for 2) syndie dev status? +16:51 < jrandom> ok, if not, lets jump to 3) ??? +16:51 < jrandom> anyone have anything else they want to bring up? +16:54 < jrandom> ok, if not... +16:54 * jrandom winds up +16:54 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/186.rst b/i2p2www/meetings/logs/186.rst new file mode 100644 index 00000000..37c670f1 --- /dev/null +++ b/i2p2www/meetings/logs/186.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 24, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/187.log b/i2p2www/meetings/logs/187.log new file mode 100644 index 00000000..73baa63c --- /dev/null +++ b/i2p2www/meetings/logs/187.log @@ -0,0 +1,70 @@ +15:33 < jrandom> 0) hi +15:33 < jrandom> 1) Net status +15:33 < jrandom> 2) Syndie dev status +15:33 < jrandom> 3) ??? +15:33 < jrandom> 0) hi +15:33 * jrandom waves +15:33 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2006-October/001316.html +15:33 * tethra waves back! +15:34 < jrandom> lets jump on in to 1) net status +15:34 < jrandom> no news on this front afaik... things seem stable +15:34 < jrandom> anyone have anything they want to bring up on it? +15:35 <+tethra> nothing here +15:36 < jrandom> ok lets jump on to 2) Syndie dev status then +15:37 < jrandom> as mentioned in the notes, i've been exploring some wysiwyg editor components, but it seems a big pain in the ass (no suprise), and no great solution exists afaik +15:38 < jrandom> so, right now my thoughts are to go with a basic editor with helpers like you see on forums like forum.i2p.net. not wysiwyg, but helpful +15:39 <+tethra> makes sense. might wysiwyg be a progression later on, then? +15:39 < jrandom> of course, if someone tracks down a good small oss wysiwyg editor, i'd love to hear about it (though i've reviewed a dozen options) +15:39 < jrandom> aye, thats a great way for later enhancement +15:40 <+tethra> less of a jump between geek and non geek that way :) +15:40 <+tethra> (have you looked at Nvu?) +15:41 < jrandom> aye, huge, but promising +15:41 <+tethra> which others had you looked at? +15:42 <+tethra> out of interest +15:42 < jrandom> everything i could google into. no list at hand +15:42 <+tethra> ah, right +15:44 < koff> Would it be useful to have a split view with the html at the bottom and a realtime updating rendering of the page at the top? +15:45 <+tethra> or maybe left/right (being able to choose would be lovely +15:45 <+tethra> ) +15:45 < jrandom> aye, thats a good idea (not entirely realtime, but semi-realtime) +15:46 <+tethra> yeah, refresh button etc +15:46 < jrandom> perhaps on 5s idle or a button press +15:46 < jrandom> right +15:48 < koff> You could maybe even have two cursors, so you almost feel like you're navigating both at the same time? +15:48 <+tethra> that'd be a bit confusing :/ +15:48 < koff> maybe :) +15:50 < jrandom> ok, anyone have anything else on 2) syndie dev status? +15:51 < jrandom> if not, lets move on to 3) ??? +15:51 < jrandom> anyone have anything else they want to bring up for the meeting? +15:54 <+fedo> yeah Jr , can hope to have a "joe 6 pack"'s guide to use syndie 1.0 ? ie : what we can do with that text mode console ... +15:55 <+fedo> i'll love to help to test syndie but i'm still unable to understand how to use syndie ! :) +15:55 < jrandom> fedo: does http://syndie.i2p.net/manual.html and http://syndie.i2p.net/features.html and http://syndie.i2p.net/usecases.html help? +15:55 < jrandom> is it a question of "what can you do with syndie", or "how can you do $x"? +15:55 <+fedo> hm not really Jr :-/ +15:56 <+fedo> really, i try to do it ... +15:56 <+fedo> how i can use syndie ... +15:57 <+fedo> the text mode console is not a problem +15:57 < jrandom> how you can use syndie /to do what/? or is that the question itself - why would you install and use syndie? +15:57 <+fedo> but what to do when i've installed Syndie is one :-s +15:57 < jrandom> ah +15:58 < jrandom> ok, think of syndie like a customized web browser - you install it so that you can participate in forums. once you install it, you need to tell it what forums you want to participate in +15:59 < jrandom> the current 0.919b install will out of the box tie in to the syndie archive at http://syndie.i2p.net/archive/ - you can just install it, log in, and sync up +16:00 < jrandom> and once you've synced up, you can read posts to the various forums, post up replies, or post up to your own forum +16:01 <+fedo> Jr : i'm thinking that you could made a breif note to explain how to use Syndie : ie how to sync, how to fecth a post ... +16:02 <+tethra> (or even, an example repository (syndie.i2p.net ?) to sync to) +16:02 <+tethra> oh, didn't read above :/ +16:02 <+tethra> nvm +16:03 < jrandom> fedo: good idea, i'll write one up +16:03 * fedo waves +16:05 < jrandom> ok cool, anyone have anything else for the meeting? +16:05 <+fedo> we know that you to enable the use of syndie on freenet : tell us how to do it ... (you know that i'm unable to find by reading the syndie's code :-/ ) +16:05 <+fedo> ((help me :)) +16:06 < jrandom> http://syndie.i2p.net/manual.html#syndicate_freenetpost +16:06 < jrandom> and http://syndie.i2p.net/manual.html#syndicate_getindex +16:07 <+fedo> many 'neurones' to burn but i'll try :) +16:07 < burl> fedo: Complication has written a brief and pretty handy startup guide on the forum here: http://forum.i2p/viewtopic.php?p=8860#8860 +16:08 < jrandom> ah right, thats a good one burl +16:08 <+fedo> thanks burl : i'll have a look to that note ;) +16:12 < jrandom> word, ok, if there's nothing else for the meeting... +16:12 * jrandom winds up +16:12 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/187.rst b/i2p2www/meetings/logs/187.rst new file mode 100644 index 00000000..f5641b52 --- /dev/null +++ b/i2p2www/meetings/logs/187.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 31, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/188.log b/i2p2www/meetings/logs/188.log new file mode 100644 index 00000000..e9af7e15 --- /dev/null +++ b/i2p2www/meetings/logs/188.log @@ -0,0 +1,87 @@ +15:09 < jrandom> 0) hi +15:09 < jrandom> 1) Net status +15:09 < jrandom> 2) Syndie dev status +15:09 < jrandom> 3) I2Phex mods +15:09 < jrandom> 4) ??? +15:09 < jrandom> 0) hi +15:09 * jrandom waves +15:10 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2006-November/001317.html +15:10 * spaetz waves back +15:10 < mrflibble> cool, i was the only one in #i2p-dev a minute ago :) +15:10 < jrandom> hehe +15:10 < jrandom> yeah, the i2p-dev chan migration didn't last too long ;) +15:10 < jrandom> ok, lets jump into 1) Net status +15:11 < spaetz> ad 1) net seems stable +15:11 < spaetz> however, as you noted, reseeding is needed every 7 days or so +15:11 < jrandom> aye, 'tis unfortunate, and fixable +15:12 < jrandom> though the kludge fix is kind of ugly, and the long term fix is pretty involved +15:12 < spaetz> yep, that would be nice. My firewall is too tight for reseeding +15:12 < jrandom> damn, doesn't allow outbound http to dev.i2p.net? +15:12 < spaetz> I need to poke additional holes in it :-) +15:13 < spaetz> jrandom: outbound yes, but all the reply data gets stopped by default :-) +15:13 < spaetz> but that OT. go on. +15:14 < jrandom> lol ok, interesting +15:14 < jrandom> its something that needs to get addressed, though its not on my do-immediately pile +15:15 < jrandom> i dont really have much more to add to 1).. anyone have anything else they want to bring up re: net status? +15:15 < spaetz> I get disconnected on IRC every 1-2 hours +15:15 < spaetz> but I would call that stable :-) +15:16 < spaetz> ok, on to 2) +15:16 < jrandom> heh cool, 2) it is +15:17 < jrandom> lots of progress on this front +15:17 < spaetz> Is the new Syndie going to be integrated into i2p when it goes gold? +15:18 < jrandom> hmm, if you mean bundled with, i'm not sure. if you mean capable of seamlessly using, yes, definitely +15:19 < spaetz> I actually meant bundled. I2p seems to come "with batteries included" +15:19 < jrandom> the reason i'm not sure is that syndie will weigh a good deal (swt native libs, translations, spellcheck dictionaries, etc) +15:19 < jrandom> we will have an option to bundle them, certainly +15:20 < jrandom> and maybe that'll be the most common download +15:20 < spaetz> ok, I'm for an optional install then. alright. +15:21 < jrandom> bundling the text UI is certainly doable without a doubt, thats quite lightweight +15:22 < spaetz> that might be good enough to tease people +15:22 < spaetz> SOme might want to run the gui on a different machine than their i2p peer anyway +15:22 < spaetz> (I will) +15:23 < jrandom> word +15:23 < jrandom> ok, some teaser images for the gui dev status: +15:23 < jrandom> html rendering: http://dev.i2p.net/~jrandom/mockup/render_snap.png +15:23 < jrandom> forum tree: http://dev.i2p.net/~jrandom/mockup/syndie_refchooser.png +15:23 < jrandom> message tree / filter: http://dev.i2p.net/~jrandom/mockup/syndie_msgchooser.png +15:24 < jrandom> (the html rendering has been seen before, and the reference chooser may have been, and the message chooser was just implemented last night ;) +15:25 < jrandom> there'll be lots of little add-ons, but i'm focusing on first getting gui message generation in place +15:25 < jrandom> (which requires being able to browse forums and messages anyway, to pick links) +15:26 < spaetz> cool +15:26 < spaetz> although the beauty of syndie was its seamless integration through the web interface +15:26 < spaetz> but I bet that would be possible to implement +15:27 < jrandom> well, a web interface would technically be possible, but it would have all the security issues of the browser plus all the problems for interactive content that javascript/etc can cause +15:28 < spaetz> mmh, I see the hell you'd get into. I remember the corresponding freenet discussions a few years back +15:28 < jrandom> technically, we can pull in the mozilla engine to do html rendering with the SWT Browser widget, but doing so just isn't safe +15:29 < jrandom> aye, exactly +15:29 < jrandom> (and what, 5-8 years on, they still just found another security hole in their filter the other week) +15:30 < jrandom> ((my point is not that their filter isn't great, its that doing the filter is insanely dangerous)) +15:30 < spaetz> ok, if there's a document "syndie for dummies" I'd give it a shot. (the text UI). IS the manual the right document for this? +15:30 < spaetz> It seemed a bit specific already +15:31 < jrandom> ah - check out Complication2's post: http://forum.i2p.net/viewtopic.php?t=1935 +15:31 < spaetz> ok, thanks. +15:31 < jrandom> that's getting wrapped up into a page for the syndie site, but isn't up yet +15:32 < spaetz> ok, that's great. all I needed +15:34 < jrandom> cool. ok, thats about it for gui stuff atm +15:34 < jrandom> there's a little teaser for the p2p folks in the status notes regarding a swarming syndication system +15:35 < jrandom> thats an area quite ripe for playing around in, for those who'd like to do some network hacking +15:36 < jrandom> but, thats just a side note +15:36 < jrandom> ok, if there's nothing else on 2) syndie dev status, lets jump over to 3) i2phex mods +15:36 < jrandom> Complication2: wanna give us the rundown? +15:38 < jrandom> or, if you're not here, those of y'all interested can check the status notes for my synopsis +15:39 < spaetz> mmh, gone fishin' +15:39 < jrandom> ok, lets jump on over to 4) ??? +15:39 < jrandom> anyone have anything else to bring up for the meeting? +15:39 * mrflibble sticks his hand up +15:40 < spaetz> nahh, looking forward to see (the new) Syndie getting more useful +15:40 < mrflibble> on http://dev.i2p.net/pipermail/i2p/2006-November/001317.html, what does "hi y'all, good luck with the subpoena power" mean exactly? +15:40 < spaetz> will the first codename be "will the real Syndie please stand up?" :-) +15:41 < jrandom> mrflibble: http://www.electoral-vote.com:2006/ +15:41 < jrandom> hehe spaetz +15:41 < mrflibble> oh! +15:41 * bar impregnates a ballot +15:43 < jrandom> (not that the democrats would be any better for the world, but the ability to subpoena the us president via congressional investigations would likely throw a few wrenches into the war machine for a bit) +15:44 < jrandom> ok, anyone have anything else for the meeting? +15:45 < jrandom> if not... +15:46 * jrandom winds up +15:46 * jrandom *baf*S the meeting closed diff --git a/i2p2www/meetings/logs/188.rst b/i2p2www/meetings/logs/188.rst new file mode 100644 index 00000000..ee036f62 --- /dev/null +++ b/i2p2www/meetings/logs/188.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 7, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/189.log b/i2p2www/meetings/logs/189.log new file mode 100644 index 00000000..90eaaf0d --- /dev/null +++ b/i2p2www/meetings/logs/189.log @@ -0,0 +1,90 @@ +15:07 < jrandom> 0) hi +15:07 < jrandom> 1) Net status +15:07 < jrandom> 2) Syndie dev status +15:07 < jrandom> 3) I2Phex mods +15:07 < jrandom> 4) ??? +15:07 < jrandom> 0) hi +15:07 * jrandom waves +15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001318.html +15:07 < jrandom> (i'm late, so i'll let y'all catch up on those) +15:09 < jrandom> ok, lets jump on in to 1) net status +15:10 < jrandom> [eom] :) +15:10 * jrandom has had a good irc connection now (4+ days), so things are in pretty good shape. +15:11 < jrandom> we've also got those new peer capacity graphs on stats.i2p, detailing some interesting ratios +15:13 < jrandom> ok, anyone have anything else for 1) net status? +15:14 < striker> just that it looks nice. +15:14 < jrandom> w00t :) +15:15 < jrandom> ok, lets hop on over to 2) syndie dev status then +15:15 < green> I dunno U can have 4+ days conection on IRC,, I'm disconnected somewhat every 24h even with a router not so overloaded +15:15 < jrandom> green: unfortunately, its pretty arbitrary. +15:16 < jrandom> (or, more precicely, the cause is dependent upon many factors without a good control over them) +15:17 < green> any chance to really know why ? +15:17 < green> I've plenty of tunnels even where IRC goes down +15:18 < green> s/when +15:18 < jrandom> yes, there's lots we can do, but i'm focusing my time on getting syndie out first +15:18 < green> I know, so I've just to way more ;) +15:19 < green> s/wait +15:20 < green> gr f..ing keyboard +15:20 < green> ok, no more on 1 let's got to 2 +15:20 < jrandom> w3rd +15:21 < jrandom> ok, not much more to add beyond whats in the notes (well, that can reasonably be brought up) +15:21 < jrandom> the webcaching discussion thread is http://forum.i2p.net/viewtopic.php?t=1958 +15:22 < green> is there any plan on phpbb to syndie converter ? +15:22 < jrandom> and the latest mockup image referred to is http://dev.i2p.net/~jrandom/mockup/forum.png +15:23 < jrandom> green: hmm, i thought we discussed that in one of the meetings, but looking back at the logs, it occurred outside of a meeting +15:24 < jrandom> short answer: doable, and maybe it'll get done, but its not on the immediate roadmap +15:24 < jrandom> at least, not bidirectional phpbb<-->syndie operation +15:24 < jrandom> phpbb-->syndie is easy (just suck in the posts, or use server side generation) +15:25 < jrandom> syndie-->phpbb is easy too +15:25 < jrandom> i'm not sure if the phpbb model of operation is what people will end up using syndie for though +15:25 < jrandom> but we'll see +15:28 < green> even just an phpbb -> syndie would be enough +15:30 < jrandom> cool, that'll be trivial (pulling phpbb's rendered html into a page & posting it). a bit more complex would be pulling from phpb's database itself, though that'd give more control (but then only the phpbb admin could do it - the former method can be done by anyone) +15:31 < badger> phpbb's admin is fairly flat.... not a challenge to get a hook of +15:32 < badger> and there are various rss plugins available for it +15:33 < jrandom> ah cool. actually, if someone wanted to start looking into that, it'd rule - just generate an HTML page (and if you need to reference other resources, do so with the syndie URIs [syndie.i2p.net/spec.html#uri] +15:34 < jrandom> (and if you need images/etc, just reference them as img src="attachment1" etc) +15:34 < jrandom> (and then we can shove 'em into a syndie post with no problem) +15:35 < jrandom> currently the message editor has "add text page" and "add html page" features... eventually we can toss in an "add page from the web..." that prompts you for a URL to fetch +15:37 < badger> http://forum.i2p/rss_news.php +15:38 < badger> translating that to syndie markup would probably be straightforward +15:39 < jrandom> aye (though remember, syndie markup /is html/. the uris are just... long and hard to read :) +15:41 < jrandom> ok, anyone have anything else on 2) syndie dev? +15:42 < jrandom> if not, lets jump to 3) i2phex mods +15:43 < jrandom> strike1 / Complication: wanna give us an update? +15:43 < strike1> I did a quick sanity check in regards to solving the connect to self problem +15:43 < strike1> http://forum.i2p.net/viewtopic.php?t=1965 +15:44 < strike1> It seems to be working okay, but is merely preventing the local dest from being added to i2phex.hosts +15:44 < strike1> I am also looking into the hashing problems, and the downloading issues +15:45 < jrandom> kickass! +15:45 < strike1> The new mods in cvs seem to make for a slightly better i2phex so far too, I must say. +15:48 < strike1> Hopefully between Complication, I, and anyone else who wants to help we can solve them all soon. :) +15:49 < jrandom> wikked, thanks strike1 (& complication et al!) +15:50 < jrandom> ok, anyone have anything else for 3) i2phex mods? +15:51 < jrandom> if not, lets jump to 4) ??? +15:51 < jrandom> anyone have anything else they'd like to bring up for the meeting? +15:54 < green> any chance to have a dijjer port on I2P ? +15:55 < green> wow, don't worry, just a simple question ;) +15:55 < jrandom> probably not (dijjer port being a large number of public squid outproxies that cache) +15:56 < jrandom> but the ability to have content hosted when you're not online will be there with syndie +15:56 < jrandom> (and syndie can run over i2p) +15:56 < green> sure but how syndie can handle large content ? +15:57 < jrandom> technically, yes, but practically, no +15:58 < green> so using cache is not a so bad idea ? +15:58 < jrandom> otoh, we can have syndie distributed .torrent files for torrents that are encrypted with session keys that only those authorized on syndie know +15:59 < jrandom> there's a use case for caching large files, though i'm not sure if the freenet/dijjer caching method is the best route +15:59 < jrandom> (no pun intended) +15:59 < green> humm .torrent files so we have to rely on a cetral server / tracker +15:59 < green> s/central +16:00 < jrandom> (for instance, see http://freehaven.net/anonbib/#redblue ) +16:01 < jrandom> green: torrents can be distributed, and you can put the same data on lots of swarms +16:01 < jrandom> but functionally, we know that torrents work for transfering truckloads of data +16:03 < green> There isn't so much goo tracker on I2P, so currently we rely on a central server even if it's doable to distribute torrent over a lot of tracker +16:05 < jrandom> hmm, the trackers we have are good, there just isn't that much content :) +16:06 < strike1> I agree though looking at postman's tracker I was impressed with what I found there as opposed to last year. +16:07 < jrandom> aye, quite +16:07 < strike1> Lots of nice stuff :) +16:09 < jrandom> ok, anything else for the meeting? +16:10 < green> (baf) :) +16:10 * jrandom winds up +16:10 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/189.rst b/i2p2www/meetings/logs/189.rst new file mode 100644 index 00000000..b0c1c4aa --- /dev/null +++ b/i2p2www/meetings/logs/189.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 14, 2006 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/190.log b/i2p2www/meetings/logs/190.log new file mode 100644 index 00000000..f53b108f --- /dev/null +++ b/i2p2www/meetings/logs/190.log @@ -0,0 +1,114 @@ +15:02 < jrandom> 0) hi +15:02 < jrandom> 1) Net status +15:02 < jrandom> 2) Syndie dev status +15:02 < jrandom> 3) ??? +15:02 < jrandom> 0) hi +15:02 * jrandom waves +15:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001319.html +15:03 < jrandom> since that one is pretty short, lets jump on in to 1) net status +15:04 < jrandom> things are looking pretty good atm, network seems pretty steady +15:04 <+zzz> I invented a "peer capacity index" +15:04 <+zzz> on the dashboard... +15:04 <+zzz> so far not sure it is helpful though +15:04 < jrandom> ah yeah, sorry, metioned that one last week - looks quite useful, thanks! +15:05 < jrandom> interesting to see the disparity out there so clarly +15:05 <+zzz> the idea is the ratio of high-cap routers to low-cap routers, which is obviously important to tunnel build % +15:06 <+zzz> I'm removing routers from stats that I don't get a netdb update for in 1.5 hours but that seems too quick, I think it is skewing the stats +15:07 < jrandom> ah, ok, that would explain it. are you still harvesting? +15:07 < jrandom> (or wget'ing from dev.i2p.net?) +15:08 <+zzz> yes +15:08 < jrandom> cool +15:08 <+zzz> netDb.harvestDirectly=false +15:08 <+zzz> netDb.shouldHarvest=true, right? +15:09 < jrandom> so the stats we've had before were largely based on routers that were so bad the user shut them down & disapeared then? +15:09 < jrandom> right +15:10 <+zzz> it's always been 1.5 hours, but plotting the M/N/O routers, they seem to come and go when intuitively they should stay pretty constant +15:10 < jrandom> ah ok +15:10 <+zzz> you can see spikes/dips in all the data that last 1.5 hours :) +15:11 < spaetz> net seems pretty stable. Yep +15:12 <+zzz> thats all I have for that topic +15:12 < spaetz> I'd like to know if jrandom completely focuses on syndie nowadays or if he still looks at i2p dev. +15:12 < spaetz> or if this is just a bit on hte backburner temporarily +15:13 * jrandom completely focuses on syndie nowadays, but will work on i2p both when there are problems and once syndie is established +15:13 * spaetz thanks for the information +15:14 * spaetz is fine with this +15:15 < jrandom> w3wt. yeah, steadystate means syndie dev can continue, but if there are problems, of course i reprioritize +15:15 < jrandom> ok, anyone have anything else on 1) net status? +15:15 < Walter> I have a random question. +15:15 < jrandom> hit me Walter +15:17 < Walter> Assume you have 100Mb/s BW, what kind of server would you need to saturate it as an I2P node? +15:17 < jrandom> doesnt matter +15:17 < jrandom> i2p does not and will not saturate 100Mbps +15:18 < Walter> Assume one wanted to make use of available BW. +15:18 < jrandom> you would not. +15:19 < spaetz> I've got 150kbs up and down and it uses like 25% of a vserver (Dell shared with a dozen others) +15:19 < jrandom> that exceeds the capacity of the entire network +15:19 < spaetz> 25%CPU that is +15:19 * spaetz admits that's not really a precise answer and shuts up +15:20 < jrandom> the routers themselves have a mem v. throughput tradeoff, making it less likely that a router can even push > 3-350KBps +15:20 < jrandom> (of course, that tradeoff can be tweake to allow higher rates, but thats not an issue) +15:21 < jrandom> using bandwidth is *BAD* unless that bandwidth is being used only when necessary +15:22 <+zzz> the network is averaging about 1.5 MBps (=12 Mbps) total traffic over the last 3 months +15:23 < Walter> I see. +15:24 <+fox> <LeerokKitchen> Field trip! +15:26 < jrandom> ok, if there's nothing else for 1) net status, lets jump on over to 2) syndie dev status +15:26 < jrandom> progress here continues, and i've been doing testing both on windows and linux +15:28 < jrandom> current battle is on the forum management interface, though since the text interface is already embedded, all functionality is already in place +15:29 < jrandom> not much more news to discuss on that front though +15:30 < jrandom> anyone have any questions/comments/concerns on 2) syndie dev status? +15:33 < jrandom> ok, lets jump on to 3) ??? +15:33 < jrandom> y'all have anything else for the meeting? +15:34 <+fox> <blx> when will gpl java be usable with i2p= +15:34 <+fox> <blx> ? +15:35 < Complication3> I guess it depends on when gpl java will be usable on various distros +15:35 < Complication3> Or available for download from Sun +15:36 < Complication3> But it feels like a moot point, since it's the same Java which is usable already now +15:36 < Complication3> GPL would only let it be packaged more conveniently, and improved upon +15:37 < jrandom> (and i2p already works with gcj/kaffe, though not all of the client apps) +15:37 * Complication3 quickly reads backlog +15:37 < jrandom> ((and syndie works with gcj/kaffe completely)) +15:38 <+fox> <blx> Compilation, thats what they want you to think ;) +15:38 <+fox> <blx> but ok, i got my question answered. +15:38 <+fox> <blx> Complication even. misread +15:39 < Complication3> blx: well, the sources are available already now, it's just that few read and compile them +15:39 < jrandom> (and you can even modify and use those modifications, you just can't distribute your mods) +15:40 < koff> when will i2p have the logging functionality suggested by the proposed laws i heard about? +15:41 < jrandom> never +15:41 <+zzz> hahahaha +15:41 * Complication3 suspects never :) +15:41 <+fox> <blx> what laws? +15:41 * jrandom assumes you refer to .de/.eu data retention issues +15:41 < Complication3> Someone in the forum talked of a (proposed) law in Germany +15:42 < jrandom> (and then the .us ones in a few years) +15:42 < Complication3> They could have spelled it out better though +15:42 < jrandom> aye, 'tis just proposed, but not a big suprise +15:43 < Complication3> I personally think: it's not like data retention laws aren't being broken left and right already +15:43 < Complication3> Breaking a dozen more of them? I personally wouldn't care much... +15:44 < Complication3> In short, I want to see how they're going to enforce it +15:44 < tea> like they did with napster : arrest everyone +15:45 < Complication3> If they manage to make a good try, something will need to be found to thwart that ("not in my country" peering principle for countries where insanity prevails) +15:45 <+fox> <LeerokLacerta> That reminds me of a song. +15:45 <+fox> <LeerokLacerta> http://2ch.ru/mu/src/1163070550597.mp3 +15:46 < tea> turning all data traffic over to anonymous networks might help ... +15:47 < Complication3> Just ignoring them en masse has worked for plain ordinary pirates... +15:47 < Complication3> You can arrest one person ignoring you. Can't do that with several hundred thousand. +15:47 < tea> that's no argument for a german :) +15:47 <+fox> <modulus> you can +15:47 <+fox> <modulus> hitler did +15:48 < Complication3> That's only because nobody bothered removing him +15:48 < jrandom> *cough* +15:48 < Complication3> Had they taken up arms, it wouldn't have worked +15:48 < Complication3> (sorry, far off topic, yes) +15:48 < tea> still, one does feel important in being paranoid +15:48 <+fox> <modulus> that said i think i2p could comply with data retention laws without damaging anonimity, but there's no reason to do that. +15:48 < jrandom> ok, well, i think we've addressed the i2p-related issue there ;) +15:48 < tea> sry +15:49 < jrandom> aye modulus +15:49 < jrandom> (we already assume individual users are logging everything anyway, as are the isps) +15:49 <+fox> <modulus> right, so a DR-enabled i2p wouldn't be the end of the world +15:51 < Complication3> Someone would have to bother forking that, though... :P +15:52 * jrandom keeps my mouth shut ;) +15:52 < jrandom> ok, anyone have anything else for the meeting? +15:53 < jrandom> if not +15:53 * jrandom winds up +15:53 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/190.rst b/i2p2www/meetings/logs/190.rst new file mode 100644 index 00000000..f26b114d --- /dev/null +++ b/i2p2www/meetings/logs/190.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 21, 2006 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/191.log b/i2p2www/meetings/logs/191.log new file mode 100644 index 00000000..9e4024df --- /dev/null +++ b/i2p2www/meetings/logs/191.log @@ -0,0 +1,52 @@ +15:14 < jrandom> 0) hi +15:14 < jrandom> 1) Net status +15:14 < jrandom> 2) Syndie dev status +15:14 < jrandom> 3) ??? +15:14 < jrandom> 0) hi +15:14 * jrandom waves +15:14 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001320.html +15:14 < jrandom> (sorry for the delay, small kitchen emergency) +15:14 < gott> Hello, jrandom. +15:15 < jrandom> heya gott +15:15 < jrandom> ok, lets jump in to 1) net status +15:15 * jrandom has nothing more to add for 1) net status, beyond mentioning that i've been connected to irc for 13 days now w/out discon) +15:16 < gott> I have been able to download my favourite modernist movie Metroland from the Frenchmen in #fr via i2psnark +15:16 < gott> Going at download rate of 4400 kb/s; upload around the same. +15:16 < gott> 6 peers. +15:16 < gott> Very good for the propagation of European modernist fiction. +15:16 < jrandom> !thwap +15:17 < jrandom> (or, if you are actually getting 4Mbps, both sides are using 0hop tunnels) +15:17 < gott> bytes a second. +15:18 < jrandom> anyone have anything else to bring up for 1) net status? +15:20 < jrandom> ok, lets jump on over to 2) syndie dev status +15:20 < gott> Is it possible to make i2p better somehow in this regard? +15:20 < jrandom> gott: oh, you mean 4400 Bps, not kbps? +15:20 < jrandom> then i take back the 0hop tunnel thing +15:21 < jrandom> 4KBps is typical atm, and can be improved with better peer selection and congestion management +15:22 < jrandom> ok, for syndie dev status, lots of progress going on, as mentioned in the notes +15:23 < jrandom> there's still a bunch of gaps to fill, but they're largely just filling gaps, not writing new components +15:24 < jrandom> ok, anyone have anything else on 2) syndie dev status? +15:25 < jrandom> ok, lets jump on over to 3) ??? then +15:26 < jrandom> anyone have anything else to bring up in this short meeting? +15:26 < JosephLeBlanc> Do you need any money? +15:26 < JosephLeBlanc> oh for fuck sake +15:26 < JosephLeBlanc> well, do you need any money? +15:27 < JosephLeBlanc> Do you want a computer? +15:27 < JosephLeBlanc> Do you want beer? +15:27 < JosephLeBlanc> What? +15:27 < jrandom> atm, finances are in pretty good shape, though contributions are always appreciated, of course +15:27 < JosephLeBlanc> Out with it +15:27 < JosephLeBlanc> Alright, then +15:27 <+zzz> post a bounty for emule client :) +15:28 < jrandom> (but if you've got money burning a hole in your poket, it'd be great to snag a mac mini for osx gui testing ;) +15:28 < jrandom> lol zzz +15:28 < JosephLeBlanc> Not everyone is a lesbian snob who has a 40 thousand dollar student loan that needs paying off +15:28 <+zzz> keep up the good work jr +15:28 < jrandom> just in case that wasn't closedshop: i appreciate the interest and support, but i won't have any time to work on a file sharing app in the future +15:29 < JosephLeBlanc> Can you implement modulus' lovesoc +15:29 < JosephLeBlanc> ? +15:29 < jrandom> thanks zzz, you as well (your services and code definitely help tons!) +15:29 <+zzz> get the baf lol +15:30 * jrandom runs to the corner +15:30 * jrandom winds up +15:30 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/191.rst b/i2p2www/meetings/logs/191.rst new file mode 100644 index 00000000..81f643f7 --- /dev/null +++ b/i2p2www/meetings/logs/191.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 28, 2006 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/192.log b/i2p2www/meetings/logs/192.log new file mode 100644 index 00000000..b30fb4c3 --- /dev/null +++ b/i2p2www/meetings/logs/192.log @@ -0,0 +1,52 @@ +15:00 < jrandom> 0) hi +15:00 < jrandom> 1) Net status +15:00 < jrandom> 2) Syndie dev status +15:00 < jrandom> 3) iToopie +15:00 < jrandom> 4) ??? +15:00 < jrandom> 0) hi +15:00 * jrandom waves +15:00 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-December/001321.html +15:01 < jrandom> (almost two hours before the meeting, too! :) +15:01 < jrandom> ok, lets jump on in to 1) net status +15:01 < jrandom> things are going pretty well, no big change on this front +15:02 * jrandom has been connected to irc here for 20 days now, too (a record, i believe) +15:03 < jrandom> not much more to add on this front though atm +15:03 < jrandom> so, if there's nothing else on it, lets jump forward to 2) syndie dev status +15:04 < jrandom> progress continues here, with more bits and bobs becoming workable +15:04 < jrandom> its still quite rough though... "utilitarian", but graphically utilitarian ;) +15:05 < jrandom> the alpha isn't imminent though, but i hope to have it ready soon +15:07 < jrandom> in any case, more info as it comes about :) +15:08 < jrandom> ok, lets jump briefly on over to 3) iToopie +15:08 < jrandom> as mentioned in the notes, Thanks y'all! :) +15:08 < jrandom> ok, continuing on in rapid fire to 4) ??? +15:08 < jrandom> anyone have anything they'd like to bring up for the meeting? +15:10 < jrandom> (its probably been a year or two since our last 10 minute meeting, but perhaps that's for the best) +15:10 <+fox> <Ch0Hag> Hey wow. Totally by accident I am actually present for an I2P meeting. +15:11 <+fox> <Ch0Hag> Hi mum! +15:11 <+fox> <Ch0Hag> This is going in the logs right? :) +15:11 < jrandom> heh yeah ch0 ;) +15:12 <+fox> <Ch0Hag> Because of course my mum reads I2P meeting logs... +15:12 < burl> i was going to ask about the licensing but i just read the answer on www.i2p (why not gpl?) +15:13 < jrandom> gpl kills babies +15:13 * jrandom ducks +15:13 < burl> i have to print them out for my mum. she's not very good with computers +15:13 < jrandom> heheh +15:14 < burl> i've been reading all about the free software movement recently. ethically it seems bang on +15:14 < burl> closed source is evil :) +15:14 < jrandom> good, evil, they're all the same. what matters here is that closed source is /insecure/ ;) +15:15 < jrandom> (syndie license summary @ http://syndie.i2p.net/faq.html#license less religious license info for i2p @ http://www.i2p.net/licenses ) +15:15 < burl> yeah, that did cross my mind too. if some evil company stole syndie and made a "better" closed version, who'd trust it? +15:16 < jrandom> you can't steal whats free +15:16 < burl> yeah, but i mean made changes to the source and didn't let you see them +15:17 < jrandom> changes to /your copy/ of the source. my copy of the source is still exactly as it was before, and still exactly as free ;) +15:17 < jrandom> but, yeah, i understand. disagree, but understand +15:18 < jrandom> all things considered, open source>>closed source, and while gpl has some nasty limits, its sufficient for many things, and open enough for security +15:18 < burl> because no-one would trust the closed version so it could never take over in popularity +15:20 < jrandom> aye +15:21 < jrandom> licence rants are always good ways to fill up 10m of meeting logs ;) +15:21 < jrandom> ok, anyone have anything else for the meeting? +15:23 <+fox> <Ch0Hag> Well if you need more meeting time - why Java? +15:23 <+fox> <Ch0Hag> I mean ewww! +15:23 < jrandom> !thwap +15:24 * jrandom winds up +15:24 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/192.rst b/i2p2www/meetings/logs/192.rst new file mode 100644 index 00000000..cf201e0e --- /dev/null +++ b/i2p2www/meetings/logs/192.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 5, 2006 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/193.log b/i2p2www/meetings/logs/193.log new file mode 100644 index 00000000..82cfb2cf --- /dev/null +++ b/i2p2www/meetings/logs/193.log @@ -0,0 +1,21 @@ +15:03 < jrandom> 0) hi +15:03 < jrandom> 1) Net status +15:03 < jrandom> 2) Syndie dev status +15:04 < jrandom> 3) ??? +15:04 < jrandom> 0) hi +15:04 * jrandom waves +15:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-December/001322.html +15:04 < jrandom> lets jump on in to 1) net status +15:05 < jrandom> no real changes here, though its good to note that stability seems quite sufficient on irc, even with long tunnels +15:05 < jrandom> though, of course, thats not necessarily the case for eveyone, and can vary substantially +15:05 < jrandom> but, 'tis nice to see anyway +15:05 < jrandom> ok, anyone have anything to bring up for 1) net status? +15:07 < jrandom> if not, lets swing over to 2) syndie dev status +15:07 < jrandom> lots going on here, though summarized in the mailing list post +15:08 < jrandom> the new http server isn't in use on the syndie.i2p.net/archive/ archive yet, so you cant push up new messages atm, though you can pull (or, of course, run your own 'httpserv' and let people post) +15:11 < jrandom> ok, anyone have anything to discuss for 2) syndie dev status? +15:11 < jrandom> if not, lets shimmy over to 3) ??? +15:12 < jrandom> anyone have anything else to bring up for the meeting? +15:16 < jrandom> if not +15:16 * jrandom winds up +15:16 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/193.rst b/i2p2www/meetings/logs/193.rst new file mode 100644 index 00000000..b3d8ee16 --- /dev/null +++ b/i2p2www/meetings/logs/193.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 12, 2006 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/194.log b/i2p2www/meetings/logs/194.log new file mode 100644 index 00000000..7dfbebb0 --- /dev/null +++ b/i2p2www/meetings/logs/194.log @@ -0,0 +1,154 @@ +15:02 < jrandom> 0) hi +15:02 < jrandom> 1) Net status +15:02 < jrandom> 2) Syndie 1.000a +15:02 < jrandom> 3) ??? +15:02 < jrandom> 0) hi +15:02 * jrandom waves +15:02 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2006-December/001324.html +15:03 < jrandom> lets jump on in to 1) net status +15:03 < Complication2> Oh, I entirely forgot it's a Tuesday +15:03 < jrandom> things are going pretty well, as mentioned, though my router finally had a restart after a 45 day uptime +15:04 < jrandom> (but frankly, i'd be quite happy if we could consistently get 1+ month uptimes :) +15:04 < Complication2> Net status is a bit flakier than before for me, but that's because one of my I2P routers is having a recurring (once about 10 days) problem +15:04 < Complication2> Other router is capable of pulling one-month uptimes, but it's not a very high-traffic router +15:05 < Complication2> Rather modest, in fact +15:05 < jrandom> stats.i2p has been showing a slightly reduced build success rate in the past week, but that may just be seasonal +15:07 <+fox> <hottuna> Ive been getting some weird wrapper log messages +15:07 <+fox> <hottuna> INFO | jvm 1 | 2006/12/26 01:00:00 | 2006-dec-26 00:00:00 org.mortbay.util.RolloverFileOutputStream removeOldFiles +15:07 <+fox> <hottuna> INFO | jvm 1 | 2006/12/26 01:00:00 | INFO: Log age 2006_09_26.request.log +15:07 <+fox> <hottuna> INFO | jvm 1 | 2006/12/26 01:00:00 | 2006-dec-26 00:00:00 org.mortbay.util.RolloverFileOutputStream removeOldFiles +15:07 < jrandom> irc is still doing pretty well though, even with 3 hop tunnels +15:07 < jrandom> oh interesting hottuna, sounds like some verbose commons-logging stuff +15:08 < jrandom> (jetty uses their own logger, not ours) +15:08 <+fox> <hottuna> nothing to worry about then .. +15:08 <+fox> <hottuna> but still ahven been running my router due to BW starvation +15:09 < jrandom> starvation being "not enough bw for i2p", or "i2p using too much bw"? +15:11 <+fox> <hottuna> Well, both but since Im running i2p to donate bw the first alternative fits me best +15:11 < jrandom> ah heh, ok +15:11 <+fox> <hottuna> I just started syndie for the first time and Im feling a bit overwhelmed, dont really know where to begin +15:11 <+fox> <hottuna> nice touch with adding the standard archive though +15:13 < jrandom> thanks :) there's lots that we need to do to reduce the overwhelmed sensation, though lets do that in our jump to 2) Syndie 1.000a :) +15:13 < jrandom> 1.000a is out, download and enjoy! +15:14 < jrandom> out of box experience should basically be: install, start, "add the standard archive", tell Syndie to sync with the standard archive "now" (then hit save), and it'll start pulling messages +15:15 < jrandom> it'll add a line to that table below the save button, one per message and one per forum - right clicking on messages & forums brings them up, or you can browse via the Forum->Read all menu +15:15 < bar> congratulations on the syndie alpha release, you've been working long and hard on this. respect. +15:16 < Complication2> Same here. Impressive database and quite promising interface. :) +15:16 <+fox> <hottuna> Im using syndie right now and reading the epic syndie and i2p direction post +15:16 < gloin> btw, build.xml contains a hardcoded value: build.xml: <property name="swt.win32" value="../swt-I20061214-1445-win32-win32-x86/swt.jar" /> +15:16 < jrandom> thanks, there's lots to do to get syndie where it needs to be, but its a start +15:17 <+fox> <hottuna> there is much work to be done on the usability front but still you have come a long way +15:17 < jrandom> gloin: aye, 3 of 'em (swt.win32, swt.osx, and swt.linux32) - they're only used for "ant dist" +15:18 < Complication2> does "ant" default to "ant clean jar", by the way? +15:18 * Complication2 checks +15:18 < jrandom> hottuna: thats where you (and y'all :) come in - my head is deep in the innards of syndie, so its often hard for me to get the right perspective for making syndie more usable +15:19 < jrandom> i need your opinions, feedback, and suggestions to improve things +15:19 < Complication2> Aha, dependency check and jar +15:19 < Complication2> (without the cleanup part) +15:19 < jrandom> right Complication2, no 'clean' by default +15:21 < gloin> does "ant dist" build versions for linux, win32 and so on? +15:21 < jrandom> gloin: yeah, building installers, .exe files, etc +15:22 < jrandom> if you just want to build and run syndie for your own use, "ant jar" and copy the lib/syndie.jar to your syndie install, or "ant run" to launch it in place +15:23 < Complication2> darn, I overlooked the "run" target then +15:23 < jrandom> (specifying the necessary -Dswt.dir=/blah flags, or placing them in the (new) file nbproject/private/private.properties as swt.dir=/blah/) +15:23 < Complication2> Cooked up a run.sh :D +15:24 < Complication2> two-liner, though, so nothing time-consuming +15:24 < jrandom> that works too :) +15:24 < Complication2> Yep, "ant run" worked nicely +15:24 < gloin> ant run seem to work, the install linux32.exe complains about missing swt. +15:24 < Complication2> Just tested +15:26 < jrandom> hmm gloin, and swt.jar exists in the installed syndie lib dir? +15:27 < gloin> yes. +15:28 < jrandom> and you're running "java -jar /some/path/to/that/syndie/bin/syndie.exe"? or do you mean the linux installer? +15:29 < gloin> the installer was fine. it created the syndie-1.000a directory. +15:31 < gloin> Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3235 in java.library.path +15:33 < Complication2> One little question (I'm testing out the Linux binary) +15:33 < jrandom> hmm, did it create the libswt-pi-gtk-3235.so in /tmp/ gloin? +15:33 < Complication2> Where to obtain the public key "393F2DF9"? +15:33 < jrandom> thats a good question... +15:34 < gloin> who? when? +15:34 < gloin> at the moment, theres no libswt-pi-gtk-3235.so in /tmp/ +15:35 < jrandom> gloin: the new swt (3.3M4) shipped with syndie extracts the native libs to /tmp/ when it can't find them +15:36 < jrandom> gloin: can you run (cd ~/syndie-1.000a/ ; java -cp lib/syndie.jar:lib/swt.jar:lib/hsqldb.jar syndie.gui.SWTUI ) and see if that finds them? +15:36 < jrandom> Complication2: it'll be up on the various keyservers and the website after the meeting +15:37 < Complication2> Thanks :) +15:37 < jrandom> (its on my keyrings which aren't accessible from my windows box) +15:37 < Complication2> Meanwhile, I found out using more conventional means that my download of the binary *did* abort early +15:37 * Complication2 fetches the end again +15:38 < gloin> no. Maybe I rebuild the the installer +15:39 < jrandom> gloin: could you check the swt.jar to make sure it contains the libswt-pi-gtk-3235.so (jar tvf lib/swt.jar)? +15:40 < jrandom> in any case, we'll keep on debugging as things come up +15:41 < gloin> it's not in it. +15:41 < jrandom> thats about it for syndie 1.000a - there will of course be updates over time, and they'll be announced in meetings or mails +15:42 < jrandom> (there are much smaller downloads for upgrading syndie than the full 4-5+MB ones - see syndie.i2p.net/download.html) +15:42 <+fox> <hottuna> whats is the i2p syndie archives url on the i2p network ? +15:43 < jrandom> gloin: could you priv msg me the jar tvf output? +15:43 < jrandom> hottuna: http://archive.syndie.i2p/ +15:43 <+fox> <hottuna> thank you +15:45 < jrandom> (note that archive.syndie.i2p / syndie.i2p.net:8080 are just instances of syndie with the built-in HTTP server running) +15:45 <+fox> <hottuna> oh :) wicked :) +15:45 <+fox> <hottuna> oh btw the syndie clock doesnt match the clock on my system +15:46 < jrandom> so, anyone can run their own syndie archive and let people sync off 'em - just give them a link to your archive (which you can do via irc/html/etc, or in syndie itself with an 'archive link'/reference) +15:46 < jrandom> syndie clock? +15:46 <+fox> <hottuna> or the time stamps on messages in syndie +15:47 <+fox> <hottuna> wait a second. . now they seem to be right.. +15:47 <+fox> <hottuna> a restart later +15:52 < gloin> how do I build a headless archive server? I assume that the import.cgi is not 'supported' anymore? +15:53 < jrandom> right, import.cgi is incompatible with the latest - you can run a headless server with a normal syndie install by running syndie "--cli", causing it to run the text engine. +15:55 < jrandom> the integrated http server can be run from the text engine via the 'httpserv' command (http://syndie.i2p.net/manual.html#general_httpserv ) +15:55 < gloin> thanks a lot. +15:56 < jrandom> if you're going to be firing up your archive again, i should be thanking you :) +15:57 < gloin> puh.. even with a gui, it looks complicated :) +15:58 < jrandom> aye, y'all've got your work cut out for you - help make it usable and useful :) +15:59 < jrandom> we'll have lots more to cover as people start kicking the tires and issues start coming up, but for the time being, feel free to dig in, post away, and see whats going on +15:59 < jrandom> shimmying on over to 3) ???, anyone have anything else to bring up for the meeting? +16:00 < Complication2> Tested the Linux binary installer, runs nicely +16:00 < Complication2> It's only curious that when it tried creating a shortcut in the KDE menu, the shortcut ended up in the group "Development" +16:00 < Complication2> Along with NetBeans and stuff +16:01 < Complication2> I might be mistaken, but I think I recall it writing that it was going to try creating a group called Syndie... +16:01 < jrandom> ah, yeah. izpack and the java packagers/installers are still working through the kde integration +16:02 < Complication2> Anyway, small detail +16:02 < Complication2> But wanted to mention just in case +16:02 < jrandom> it /should/ create a Syndie group, but as you can see, the kde menu doesn't have per-app folders (it has categories of apps, and then per-app folders) +16:02 < jrandom> hopefully to be fixed when izpack fixes it (its on their radar) +16:03 < Complication2> Right +16:03 < Complication2> Either way, the shortcut appeared, and the uninstaller shortcut appeared too +16:03 < jrandom> wewt +16:03 < Complication2> And the uninstalled worked nicely too (used it too since I typically compile from sources) +16:03 < Complication2> =uninstaller +16:04 < bar> i have two questions, slightly related to each other +16:04 < bar> 1. any plans yet on when to nuke the old syndie? +16:04 < bar> 2. could we have an i2p gateway, syndie.i2p, to syndie.i2p.net, or would that perhaps collide with the old syndie infrastructure? +16:05 < Complication2> On 2, I think it currently would collide +16:06 < jrandom> hmm, i actually haven't thought about that much. i'm tempted to say "nuke it, move everyone to the new syndie now now now" :) +16:07 < Complication2> ...going to "http://archive.syndie.i2p" through "localhost:4444" +16:07 < bar> the reason i'm asking is, it's sometimes a bit of a pain having to use squid.i2p to access the syndie web pages +16:07 < jrandom> ah, understood. ok, i can redirect syndie.i2p to point to syndie.i2p.net, and old-syndie users can still use syndiemedia.i2p +16:09 < bar> loverly :) +16:09 < Complication2> oh, you meant the web pages +16:10 < Complication2> I thought you meant the archive :) +16:10 < bar> correct Complication2, sorry for not being clear on that +16:10 < gloin> the own forum is the own identity? +16:11 < Complication2> There's definitely a default identity / pseudonym created in a new Syndie instance +16:11 < Complication2> I'm not sure if it auto-creates a forum +16:11 < jrandom> gloin: every identity has a forum (and every forum is owned by an identity) +16:12 < jrandom> a forum, in syndie, is just a public key +16:12 < jrandom> (as is an author) +16:12 < Complication2> I've forgotten how I went about doing it, and it was in October with the text interface anyway, I think :) +16:12 < jrandom> ((in the database and code, they're both called 'channels', but the ui talks about forums and authors/nyms)) +16:13 < bar> on the topic of closing down the old syndie, may i suggest something along the lines of "keeping it online for another month but closing the archive for new posts, along with leaving an informative note" +16:14 < gloin> the gui let me create forums only. Does that means, when I a want that you can post in my forum I authorize the jrandom forum and not the jrandom person? +16:15 < Complication2> Or perhaps even leaving it open for a short while after posting the note, so if someone desperately needs it at this stage (gasp!) they can exchange some data for a short while still +16:15 < jrandom> gloin: forums and identities are the same thing - when you create a new forum, you craete a new ientity (and to authorize jrandom the person to post in your forum, authorize jrandom's forum) +16:15 < jrandom> seems reasonable Complication2 & bar +16:17 < jrandom> gloin: this stuff is definitely not-obvious, and we need to do a lot of work on making it easier +16:21 < Complication2> Oops, I've not noticed multiple suggestions for I2Phex tuning by striker on the old Syndie +16:21 * Complication2 makes local copies +16:23 < jrandom> :) the old syndie will still remain accessible at syndiemedia.i2p/ and syndie.i2p.net:8000/ +16:23 < jrandom> ok, anyone have anything else for the meeting? +16:25 < gloin> In the forum configuration I can set the privay level (all/auth/passphrase). But with each post I can set it, too. Which counts? +16:27 < jrandom> both count, though for the time being, i'd recommend keeping the forum privacy as 'public' (since i havent written up the gui for passphrase protected forums yet, only passphrase protected messages) +16:27 < jrandom> the forum privacy covers the forum's metadata (links to other sites, bundled keys, etc), while individual messages have their own policy +16:33 < jrandom> (syndie.i2p --> syndie.i2p.net as of now, syndiemedia.i2p still points to syndie.i2p.net:8000/) +16:33 < jrandom> ok, if there isn't anything else for the meeting +16:33 * jrandom winds up +16:33 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/194.rst b/i2p2www/meetings/logs/194.rst new file mode 100644 index 00000000..55c8dea7 --- /dev/null +++ b/i2p2www/meetings/logs/194.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 26, 2006 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/195.log b/i2p2www/meetings/logs/195.log new file mode 100644 index 00000000..af9678f4 --- /dev/null +++ b/i2p2www/meetings/logs/195.log @@ -0,0 +1,72 @@ +15:02 < jrandom> 0) hi +15:02 < jrandom> 1) Net status and plans +15:02 < jrandom> 2) Syndie 1.001a +15:02 < jrandom> 3) ??? +15:02 < jrandom> 0) hi +15:02 * jrandom waves +15:02 < jrandom> weekly status notes posted up on http://dev.i2p.net/pipermail/i2p/2007-January/001325.html +15:03 * mrflibble waves to jrandom +15:03 * jrandom expects most are still nursing their hangovers, so we'll do this quietly +15:04 < jrandom> lets jump on in to 1) Net status and plans +15:05 < jrandom> as mentioned in the notes, there's been a lot covered, but we've got our work cut out for us this year +15:05 < jrandom> we'll want to discuss the various tradeoffs though and make sure the most appropriate ones are taken to support the specific functionality we're driving towards +15:06 < jrandom> but, we'll see how it goes as things progress +15:06 < jrandom> for the time being though, the net seems fairly steady-state, which is Good +15:07 < jrandom> anyone have anything they'd like to bring up re: net status and plans? +15:09 < jrandom> if not, lets hop on over to 2) Syndie 1.001a +15:09 < z^z> anything I can work on on the net - netdb or tunnels? +15:09 * jrandom hops back +15:10 < z^z> I know we have questions on netdb propagation and on cpu usage but I would need a good pointer to get started +15:11 < z^z> think about it anyway +15:11 < jrandom> z^z: netDb search when the # of known/reachable floodfill peers reaches 0 needs to, most likely, do a random iterated walk across known peers +15:12 < z^z> ok thx will poke around and ask questions later +15:12 < jrandom> perhaps a new flag on the netDb lookup message asking for "give me some floodfill peers" +15:12 < jrandom> kickass z^z! that'd likely have a substantial impact for new users - let me know if you run into any trouble +15:13 < z^z> ha that will take me into new territory sounds like fun for the new year +15:13 < jrandom> :) +15:14 < bar> "do not delete floodfill peer router infos from netdb if there are too few of them" <-- does anyone remember if this one got into cvs or not? +15:15 < jrandom> nope +15:15 < jrandom> or, not that i recall... +15:16 < bar> okie +15:17 < jrandom> (a great spot for that would be KademliaFloodfillNetworkFacade::dropAfterLookupFailed) +15:18 < jrandom> er, KademliaNetworkDatabaseFacade, that is (floodfill extends it) +15:20 < jrandom> (there's also a few bits in the DatabaseLookupMessage that could be used to flag 'send me floodfill peers' - the 'tunnelSpecified' is a boolean, but transferred in a full byte) +15:21 < jrandom> ok, anything else on 1) Net status and plans? +15:23 * jrandom resumes the hopping to 2) Syndie 1.001a +15:24 < jrandom> she's coming soon, maybe in a day or two. lots of bugfixes and cleanup (thanks to everyone helping!), with more details in the announcement when its released +15:25 < jrandom> thats about it to mention on that, though (but if you're using the new syndie, you can follow up on the latest discussions there ;) +15:27 < jrandom> anyone have anything to bring up on syndie 1.001a, or shall we skip on over to 3) ??? +15:27 < jrandom> anyone have anything else they'd like to discuss in the meeting? +15:28 <+fox> <covracer> are you still not in favor of an ebuild? +15:29 < jrandom> for syndie, or i2p? +15:29 <+fox> <covracer> i2p +15:29 < jrandom> correct, i am still not in favor of an ebuild +15:29 < jrandom> (thank you for the offer/suggestion though!) +15:30 < jrandom> i2p's problems are not related to the size of the network, so increasing the size will not address them +15:30 < jrandom> instead, it will just force more people to deal with the problems and the upgrade path to address them +15:30 <+fox> <covracer> yeah +15:31 <+fox> <covracer> alex has done some good work though on an ebuild +15:31 <+fox> <covracer> it's in the java-experimental-migration overlay iirc +15:31 <+fox> * godmode0 is back (gone 01:57:51) +15:32 <+fox> <covracer> well at any rate it depends on lots improvements in gentoo's handling of java and jetty +15:32 <+fox> <covracer> and won't get into the main tree any time soon +15:33 < jrandom> cool (that alex's work is going well), and hopefully we'll get i2p to the point where pushing it to main will be a great thing :) +15:34 <+fox> <covracer> would a ebuild for syndie be welcomed or should it also be postponed? +15:34 * jrandom wonders how much shakeup there is going to be in java handling once the sun jvm & libs go gpl +15:35 < jrandom> syndie will hopefully be ready for full production use in a matter of months, with beta in maybe a month, so looking at an ebuild there would be great +15:36 < jrandom> when syndie goes production i'd like to make it as easy as possible for people to use - apt-get, emerge, rpm, etc +15:36 <+fox> <covracer> okay, I'll see if I can hack an ebuild together this week of vacation--I've got nothing better to do +15:36 < jrandom> kickass, thanks covracer! +15:37 <+fox> <covracer> easy installation is very important for wide adoption +15:37 < jrandom> (and let me know if you run into any bits that could be simplified 'upstream' - i'd like to make packaging as transparent as possible) +15:37 < jrandom> aye, definitely +15:38 <+fox> <covracer> alright, although I'm only vaguely aware of the best practices of ebuild writing, not being a dev myself or really all that active on the coding front +15:40 < jrandom> cool, you likely know more about ebuild writing than I though :) good luck, and thanks +15:40 < jrandom> ok, anyone have anything else they'd like to bring up for the meeting? +15:40 < bar> well, i think an official post in cervantes' syndie forum and the old syndie wouldn't hurt, if/when you're looking for more testers for the new syndie +15:40 < bar> except for the last meeting log, i don't think there has been much mentioning of the alpha release, many i2p users simply haven't heard the news, methinks +15:41 < jrandom> good idea - i'll spam 'em when 1.001a is out +15:42 < bar> alritey :) +15:47 < jrandom> ok, if there isn't anything else for the meeting... +15:47 * jrandom winds up +15:47 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/195.rst b/i2p2www/meetings/logs/195.rst new file mode 100644 index 00000000..0220ef80 --- /dev/null +++ b/i2p2www/meetings/logs/195.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 2, 2007 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/196.log b/i2p2www/meetings/logs/196.log new file mode 100644 index 00000000..23ea4f66 --- /dev/null +++ b/i2p2www/meetings/logs/196.log @@ -0,0 +1,111 @@ +15:07 < jrandom> 0) hi +15:07 < jrandom> 1) Net status +15:07 < jrandom> 2) I2Phex 0.1.1.38 +15:07 < jrandom> 3) Syndie progress +15:07 < jrandom> 4) Syndie bug harvesting contest +15:07 < jrandom> 5) ??? +15:07 < jrandom> 0) hi +15:07 * jrandom waves +15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-January/001328.html +15:09 < jrandom> while y'all continue drooling over the macworld stuff, lets jump on in to 1) net status +15:09 < jrandom> i don't have anything to mention here this week, but felt bad not including the net status in the report, so here it is +15:09 < jrandom> anyone have anything to add regarding the network status? +15:09 <+zzz> I'm testing a couple of i2psnark tweaks, nothing major +15:10 < jrandom> ah cool, regarding the recent bug reports, or other goodies we can look forward to? +15:11 <+zzz> other - mostly better handling of torrents with > 4 peers +15:11 < jrandom> wikked +15:11 <+zzz> also catching a couple of common OOM spots rather than dumping the whole JVM +15:12 < tea> sounds great, atm i2p-bt seems the best choice for "high"-speed torrents +15:12 <+zzz> i.e where it grabs a whole 256KB - 1MB chunk to store a piece +15:13 <+zzz> everybody pick a torrent and pile onto it to help me test :) +15:14 < jrandom> kickass, let us know when we should try things out zzz +15:14 < tea> shall someone redo 'casino royale' ? :) +15:14 * jrandom mentions that this meeting is logged and posted on the web ;) +15:15 <+void> oh, the meeting +15:15 < tea> no volunteers, then +15:16 < jrandom> ok cool, anyone have anything else for 1) Net status? +15:17 < bar> while we're mentioning i2psnark... +15:18 < bar> ...would it be possible to start, stop and restart i2psnark from the console? +15:18 < bar> (rather than restarting the whole router to kill the tunnels) +15:19 <+zzz> don't know - jrandom you have any thoughts? +15:20 < jrandom> bar: when you say stop and start, what does that entail beyond stopping and starting the inividual torrents? +15:21 < bar> killing the i2psnark tunnels that are draining my resources when not torrenting +15:22 < bar> (the tunnels don't die when you remove the .torrents, iirc) +15:22 < jrandom> ah, stopping the actual i2p destination for it. doable without much trouble, the web interface has access to the SnarkManager +15:23 < jrandom> (an interim workaround could be to set the tunnel lengths to 0 until you need to use them again) +15:23 < jrandom> but you're right, that would be useful +15:23 <+void> you could change the tunnels to have 0 depth, although that would be error prone +15:23 <+zzz> good idea to provide a stop tunnel button on the web page, agreed +15:23 * jrandom !hi5s void +15:24 <+void> ack, i'm lagging *that* much? +15:24 < jrandom> I2PSnarkUtil already has a static .disconnect() too +15:25 < jrandom> (so calling that from the I2PSnarkServlet should be trivial) +15:25 < jrandom> zzz: you wanna hit that, or you want me to toss that in there? +15:27 <+zzz> I don't see a question there so take it +15:27 < jrandom> ok cool, shall do +15:27 < jrandom> ok, anyone have anything else on 1) Net status? +15:29 < jrandom> if not, lets hop over to 2) I2Phex 0.1.1.38 +15:29 < jrandom> Complication: wanna pelt us with the low down? +15:31 < jrandom> afaik, there's a good summary of changes in the CVS and announcement (http://forum.i2p.net/viewtopic.php?t=2005) +15:33 < tea> is there a possibility of permantly changing the tunnel lengths ? +15:34 < jrandom> sure, i recall there's a place where you can set them in the i2phex config file by specifying the custom i2p options (though i don't recall the i2phex config file option to use at the moment) +15:35 < bar> tea: yes, in i2phex.cfg (i2pInboundLength, i2pInboundLengthVariance, i2pOutboundLength, i2pOutboundLengthVariance) +15:36 < tea> i was thinking of the option tab i2p-rufus has +15:37 < tea> could something like that be added ? +15:38 < jrandom> i think complication said that'd be a good idea, so its probably pretty doable +15:38 * jrandom hasn't done any gui hacking in i2phex (though I'm sure if you sent in a patch, I'd make sure it went in :) +15:38 < jrandom> oh, nm, seems complication said 'e's working on it +15:39 < jrandom> http://forum.i2p.net/viewtopic.php?t=2005#9149 +15:39 < tea> as an amateur rufus user i was pleased to see the pop up question 'allow zero hop connections ?', and be able to click no ... +15:42 < jrandom> aye. ok, anyone have anything else on 2) I2Phex 0.1.1.38? +15:42 < bar> well, while we're at it, i think congratulations to the original Phex team on their 3.0 release are in order, it came out just the other day :) +15:43 * bar waves +15:43 < jrandom> aye, congrats ArneBab et al! +15:45 < tea> maybe they'll wave back one day ... +15:46 < jrandom> ArneBab and GregorK have had some good feedback on i2phex over the years +15:46 <+void> the day that i2phex reaches version 3.0? +15:46 < jrandom> here's hopin :) +15:47 < bar> we'll be long gone by then, but yeah :) +15:48 < jrandom> ok, lets jump on over to 3) Syndie progress +15:48 < jrandom> lots of progress in the last week, including 1.001a hitting the street +15:50 < jrandom> though most of the discussion on that front is going on within syndie itself +15:50 < jrandom> so, if you're not on it yet, get on it and find out more :) +15:51 < jrandom> anyone have anything they'd like to discuss regarding syndie? +15:53 <+void> well, i just ran sync and it imported one unread message with a bunch of read ones +15:53 <+void> but i guess we'll debug that after the meeting? +15:54 < jrandom> hmm, aye, quite strange (i imported a few new messages recently, and they showed up as unread). but yeah definitely need to dig some more into that +15:54 < jrandom> ok, lets hop on over to 4) Syndie bug harvesting contest +15:55 <+void> can you register anonymous egold accounts? +15:55 < jrandom> aye, no ID necessary +15:56 <+void> ah, cool +15:56 < jrandom> though, of course, they can freeze fraudulent accounts, and they do track all the transfers, and share the transfer data with Them +15:56 < jrandom> but it is more than sufficient to defend against most adversaries +15:57 <+void> yeah, naturally +15:58 * jrandom has found the bug reports and feature requests invaluable, and while I realize the $50USD doesn't come close to compensate the actual time involved, its hopefully a small token of thanks +15:58 < jrandom> I'm hoping we'll continue this contest every month +15:58 <+void> hehe +15:59 <+void> heheat least it's fun time +15:59 <+void> arg +16:00 < jrandom> does anyone have any questions regarding the contest, or suggestions, or frisbees? +16:01 <+tethra> contest? +16:01 <+tethra> (i am late) +16:01 * tethra reads up +16:01 <+tethra> cool :o +16:02 < jrandom> so get yer bug reports flowin' :) +16:03 < jrandom> ok, lets swing on over to 5) ??? +16:03 <+void> they already are :) +16:03 <+tethra> yessir! ;) +16:03 < jrandom> aye, thanks! (yes, I'm counting everything from jan1 to jan31 :) +16:03 < jrandom> ok, anyone have anything else to bring up for the meeting? +16:04 <+fox> <nony> does it run on java6? +16:04 < tea> sure +16:04 <+tethra> come to that, does it compile with gcj? +16:04 < jrandom> nony: i run it on java6 here, yes +16:04 < jrandom> tethra: aye, and runs ;) +16:04 <+tethra> excellent +16:04 <+tethra> ;) +16:04 <+fox> <nony> sweet +16:07 < jrandom> ok, anyone have anything else for the meeting? +16:09 < jrandom> if not... +16:09 * jrandom winds up +16:09 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/196.rst b/i2p2www/meetings/logs/196.rst new file mode 100644 index 00000000..963ef346 --- /dev/null +++ b/i2p2www/meetings/logs/196.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 9, 2007 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/197.log b/i2p2www/meetings/logs/197.log new file mode 100644 index 00000000..983286d0 --- /dev/null +++ b/i2p2www/meetings/logs/197.log @@ -0,0 +1,33 @@ +15:03 < jrandom> 0) hi +15:03 < jrandom> 1) Net status +15:03 < jrandom> 2) I2PSnark updates +15:03 < jrandom> 3) Syndie progress +15:03 < jrandom> 4) ??? +15:03 < jrandom> 0) hi +15:03 * jrandom waves +15:03 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2007-January/001329.html +15:05 < jrandom> as y'all dig through that, lets jump on in to 1) Net status +15:05 < jrandom> not much change at the moment on this front +15:06 < jrandom> interesting to note the updated domains chart on http://stats.i2p/cgi-bin/serv_domain.cgi listing a good spread of hosts even after pruning 2000 old entries +15:07 < jrandom> zzz: what period is that chart based off? +15:07 <+zzz> 1 month +15:07 < jrandom> wow cool +15:09 < jrandom> of course, the NICs aren't always up to date, but it gives a good view of things from a high level. nice work zzz, thanks +15:10 < jrandom> ok, anyone have anything else to bring up for 1) net status? +15:12 < jrandom> if not, lets hop on over to 2) i2psnark updates +15:12 < jrandom> zzz, wanna give us the low down? +15:13 <+zzz> we have improvements in fairness when > 4 leechers, a fix for the longstanding restart-torrent bug, don't start a tunnel if autostart unchecked, and adding some more links on the webpage. +15:13 <+zzz> added a stop-all button which usually doesn't work if there is traffic, it seems +15:13 <+zzz> looking for testers and reports as usual, thanks +15:14 < jrandom> kickass, thanks zzz +15:14 < jrandom> when you feel its right, we can package 'er up and ship a new 0.6.1.27 w/ that bundled +15:15 <+zzz> ok maybe a week or 2 +15:16 < jrandom> sounds good +15:17 < jrandom> ok lets jump on over to 3) Syndie progress +15:17 < jrandom> logs going on in this front as mentioned, and we'll hopefully be pushing out a new rev in the next day or two +15:19 < jrandom> there'll be an announcement when thats out, in syndie, on the web pages, on the forum, and in the list +15:19 < jrandom> ok, swinging over to 4) ??? +15:20 < jrandom> anyone have anything else they want to bring up for the meeting? +15:23 < jrandom> if not... +15:23 * jrandom winds up +15:23 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/197.rst b/i2p2www/meetings/logs/197.rst new file mode 100644 index 00000000..017985b5 --- /dev/null +++ b/i2p2www/meetings/logs/197.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 16, 2007 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/198.log b/i2p2www/meetings/logs/198.log new file mode 100644 index 00000000..eecbb9f4 --- /dev/null +++ b/i2p2www/meetings/logs/198.log @@ -0,0 +1,57 @@ +15:06 < jrandom> 0) hi<p> +15:06 < jrandom> 1) Net status<p> +15:06 < jrandom> 2) Syndie status<p> +15:06 <+zzz> )))<p> +15:06 < jrandom> 3) I2PSnark status<p> +15:06 < jrandom> 4) ???<p> +15:06 < jrandom> 0) hi<p> +15:07 * jrandom waves<p> +15:07 <+fox> <mk> I just made the post, so feel free to respond<p> +15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-January/001331.html<p> +15:07 < jrandom> w3wt, shall do mk, thanks<p> +15:07 < jrandom> (now lets get into our archived weekly development meeting :)<p> +15:08 < jrandom> short set of status notes this week, but lets jump through 'em<p> +15:08 < jrandom> 1) Net status<p> +15:08 < jrandom> no real changes here, though we've had a substantial decline in build success rates as charted on stats.i2p<p> +15:08 < jrandom> though not the catastrophic failures we saw last summer<p> +15:09 <+zzz> yes, contrary to your rather sunny assessment in the notes, we hit a 3-month low in tunnel build success late last week. There has been only a modest recovery in last few days<p> +15:09 < Complication2> On the net status side, I've seen some increased routing pressure, which has caused about 10% of bandwidth increase, but not much more<p> +15:11 < jrandom> aye, thats the odd part zzz - the failure rate has substantially incrased, but irc hasn't been substantially affected<p> +15:11 < Complication2> It "feels" like a bit of significant routing capacity either recently left the network, or experienced downtime<p> +15:11 < jrandom> Complication2: hmm, there were a few nodes with hardware and network trouble, which would correlate with that<p> +15:12 <+zzz> from over $here irc was quite affected<p> +15:12 < Complication2> but I found that my stat recorder has been recording 0B files since October... so I honestly don't know<p> +15:12 < Complication2> had a typo in my script :O<p> +15:12 < jrandom> d'oh<p> +15:13 < jrandom> zzz: hopefully that has passed though, right?<p> +15:13 <+zzz> I'd say things are improving although during evenings GMT things are worse than in mornings<p> +15:15 < jrandom> hmm interesting<p> +15:15 < Complication2> if most users are still from Europe, during evenings GMT, their count could be rising...<p> +15:15 <+zzz> just remember weather is always sunny inside a colo :)<p> +15:16 < Complication2> (but I haven't checked theland.i2p lately)<p> +15:16 < jrandom> hehe<p> +15:16 < jrandom> (we have had an increase in the last few days, with known: hitting 555 earlier this afternoon, and now sitting at 570)<p> +15:17 < jrandom> ((active: 266/367))<p> +15:17 < jrandom> at least, according to my router<p> +15:18 < jrandom> ok, anyone have anything else for 1) Net status?<p> +15:20 < jrandom> if not, lets hop on over to 2) Syndie status<p> +15:20 < jrandom> some hefty stuff going on here, with a new release coming in the next day or two<p> +15:21 < jrandom> i'm doing my best to clear as many of the bugs filed as possible, and there are two major functional improvements in the upcoming release - better handling for banning, and support for a whole slew of privacy, authentication, and authorization policies for various forums<p> +15:23 < jrandom> when the new release is out though, there'll be more to discuss on that front (though most of that discussion is going on within syndie, naturaly :)<p> +15:23 < jrandom> as for the contest - there's still one more day left to file your bugs! the winners and supporters will be announced in next week's meeting<p> +15:24 < jrandom> ok, anyone have any questions/comments/concerns re: syndie status?<p> +15:25 < jrandom> if not, lets jump on to 3) I2PSnark status<p> +15:25 < jrandom> zzz, wanna give us an update on things?<p> +15:25 <+zzz> yes<p> +15:26 <+zzz> at the mtg 2 wks ago I was at a good stopping point, but then I found and fixed some real memory-eaters and made some other tweaks...<p> +15:26 <+zzz> I'm now at a good stopping point again so folks please test CVS and report results here or in syndie - thanks<p> +15:27 <+zzz> on the startup thrashing...<p> +15:27 <+zzz> there were some good suggestions in syndie...<p> +15:28 <+zzz> my first idea didn't really work, but I cleaned up a lock so that the web page doesn't hang at startup anymore, so it _looks_ faster<p> +15:28 <+zzz> may stab at the other suggestions later. <eot><p> +15:29 < jrandom> heh cool, thanks zzz!<p> +15:30 < jrandom> ok, lets jump to our good ol' catch-all: 4) ???<p> +15:30 < jrandom> anyone have anything else tobring up for the meeting?<p> +15:33 < jrandom> ok, if not...<p> +15:33 * jrandom winds up<p> +15:34 * jrandom *baf*s the meeting closed<p> diff --git a/i2p2www/meetings/logs/198.rst b/i2p2www/meetings/logs/198.rst new file mode 100644 index 00000000..75ee23a8 --- /dev/null +++ b/i2p2www/meetings/logs/198.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 30, 2007 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/199.log b/i2p2www/meetings/logs/199.log new file mode 100644 index 00000000..ba4bd456 --- /dev/null +++ b/i2p2www/meetings/logs/199.log @@ -0,0 +1,235 @@ +15:02 < jrandom> 0) hi +15:02 < jrandom> 1) Net status +15:02 < jrandom> 2) Syndie dev status +15:02 < jrandom> 3) January bug harvesting contest winners! +15:02 < jrandom> 4) ??? +15:02 < jrandom> 0) hi +15:02 * jrandom waves +15:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001333.html +15:03 < jrandom> hopping on to 1) Net status +15:03 < jrandom> I don't really have much to add here (as you can probably tell ;) +15:03 < jrandom> anyone have anything to bring up regarding the network status? +15:04 <+void> used to be better, somehow... +15:04 <+void> but not bad +15:05 < jrandom> its odd, the last wek or so our build rates have been going back up, per stats.i2p +15:05 < tethrage> is there a long term pattern? +15:06 < tethrage> (in build rate change) +15:07 < jrandom> afaics the patterns have been associated with the capacity of high powered routers, but thats only given a very limited view of the network (since i only know whats publicly available, pretty much) +15:07 < tethrage> i see +15:08 < tethrage> is there any information that could be provided to help? +15:08 < tethrage> from just normal routers that is +15:08 < jrandom> not really, from my point of view +15:09 < tethrage> i see +15:09 < jrandom> (basically we just need to implement some code changes before moving forward) +15:10 < tethrage> i see +15:11 < jrandom> ok, anyone have anything else for 1) Net status? +15:12 < jrandom> if not, lets skip on over to 2) Syndie dev status +15:14 < jrandom> lots going on here, as you can read +15:14 <+fox> <mk> minor: perhaps changed 'signed by' to 'authorization'? I'm a little edgy on the blurry lines between forums, identities, signatures, and so on +15:14 <+fox> <mk> -d +15:15 < jrandom> ah, thats a good idea +15:16 <+void> mk: a forum is an identity :) +15:16 <+void> and vice versa +15:17 < jrandom> aye, though we don't want to confuse people too much by making this odd duality visible +15:17 <+fox> <mk> I'm aware, but it's still blurry. I grasp it just fine now, but I worry that new users might be confused by the lack of differentiation +15:18 <+void> ah +15:18 < jrandom> right - people think of forums differently than they think of identities, so need to make sure we behave as expected +15:18 <+fox> <mk> something else that might be worth implementing in the forum or identity management is explicit 'post to this forum only under author x authorization y', which would eliminate mixups. you wouldn't even need a dropdown on the new post messages +15:19 <+fox> <mk> (a dropdown for keys) +15:20 <+void> i'd prefer a global identity dropdown that was visible at all times +15:20 <+fox> <mk> like, who you're posting under? +15:20 < jrandom> hmm +15:21 <+fox> <mk> perhaps, but there really isn't much of a difference, I think, between having it on top always and having it appear on posts only +15:22 < jrandom> ok, before we dig too deep into this, there is a side channel not currently addressed in syndie that can link multiple identities +15:22 <+void> though your identity is not used anywhere else other than posting +15:22 <+fox> <mk> what do you mean? +15:23 <+void> pushing new posts? +15:23 < jrandom> if you need to have completely unlinkable identities, you need to run separate syndie instances - you can sync them off each other, and only use one to pull/push to the other archives, but the local archive contains information that only some of the identities have access to +15:23 <+fox> <mk> (I agree that we should probably save big discussions for the dev forum, but it is nice to have a bunch of people talking about it at once) +15:24 <+void> true +15:24 < jrandom> however, all of the identities on the local archive can acces that information, and if they act on it (post with those keys, etc), they'd leak the linkabiity +15:25 < jrandom> perhaps we can find a way to accomplish all of that transparently through the gui though +15:26 < jrandom> (running with multiple archives locally without having to fire up syndie twice) +15:26 <+fox> <mk> there are many other issues - like marking certain archives exclusive against each other - that could help with anonymity. we should try to define all these scenarios and figure out a way to deal with them in a very usable way +15:27 < tethrage> syndie doesn't aim for anonymity, just security +15:27 < tethrage> it is the transport layer it runs on that should deal with that, surely? :/ +15:27 < jrandom> syndie aims for anonymity +15:27 < tethrage> (correct me if i'm wrong) +15:28 < jrandom> the transport layer only deals with a small portion of the anonymity - we need to deal with the rest +15:28 < jrandom> s/small// +15:28 < tethrage> does it? :/ +15:28 <+fox> <mk> yes, that's right. syndie deals especially with information leaks +15:29 < jadeSerpent> ip address anonymity vs. identity anonymity +15:29 < tethrage> i see. i thought you said a while ago syndie was meant as a secure app that employed crypto but wasn't strictly anonymous? +15:29 < tethrage> (not in the same way as i2p etc, anyway) +15:29 <+fox> <mk> information security is handled by the redundancy of archives +15:29 < jrandom> mk: i'm not sure what you mean by marking the archives, but i'd love a post on the syndie dev forum discussing it :) +15:29 < jrandom> tethra: syndie can be used for things that don't require anonymity +15:30 < jrandom> but syndie must be usable for things that do +15:30 < jrandom> (otherwise, there is no point to implement it as part of the i2p project) +15:31 < tethrage> yeah +15:31 <+void> jrandom: well, to be fair, there still would be a point if syndie provided anonymity by utilizing i2p +15:31 <+void> but never mind +15:31 <+void> c +15:31 < tethrage> what, other than security against information leaks and dodgy code, does syndie do to keep people anonymous? :/ +15:32 < tethrage> surely unless specified you access the archives directly etc? +15:32 <+fox> <mk> tethrage, information leaks of all sorts. If you'd like we can go into more detail in a bit +15:33 < jrandom> tethra: for instance, someone accessing an eepsite with javascript enabled +15:33 < jadeSerpent> tethrage: there's no guarantee that the posts you push to an archive originated with you, someone might have pushed them to your archive +15:34 < tethrage> jrandom: yeah, the js can give things away and such. but surely that's more a matter of security than anonymity if you're not using an anonymous network of some variety? +15:34 < tethrage> then again, i suppose i'm just arguing semantics, so i'll stop +15:34 < tethrage> :/ +15:34 < jadeSerpent> i would argue running your own publically accessible archive increases your anonymity in that respect +15:34 <+fox> <mk> jrandom, I'll make that post. Also, I've been playing around with a design for a browser (I don't like opening new tabs for new sections), so I'll try to make a prototype for it, and perhaps post some scribbles to dev +15:34 < jrandom> "security against information leaks" is the core of anonymity - controlling who knows facts about your identity +15:35 < jrandom> ah kickass mk, thanks! +15:35 < jrandom> jadeSerpent: certainly +15:35 < tethrage> i see +15:35 < tethrage> point taken +15:36 < jrandom> mk: if there are better ways to present the syndie ui, i'm 100% for it (only a very small portion of code is bound to these tab-based components) +15:36 < jrandom> and we are alpha after all +15:38 <+void> jrandom: i don't suppose it's hard to turn the tabbed interface into a windowed interface? +15:38 <+fox> <mk> yep. and if some people prefer the tabbed-for-all approach, then there's no problem with using that +15:38 <+fox> <mk> (alongside of the browser tab) +15:39 < jadeSerpent> please no mdi, i suggest something halfway between tabbed and mdi, eclipse's perspectives +15:39 <+void> mdi is bad, i agree +15:40 < jadeSerpent> netbeans has something like that too, forget what it's called +15:40 < jadeSerpent> views or workbenches or something, been a while +15:41 < jrandom> .png sketches appreciated :) +15:41 * jrandom went with the tab-for-all style because everyone loves firefox (/etc) +15:42 < jadeSerpent> when i finish the icons i might hack on some of that +15:42 <+fox> <mk> the 2 week release cycle is a good thing. I like seeing those goals explicit, but I'd also like to see some 'softer' goals listed - dev and later on user documentation, diagrams, and so on +15:42 < jrandom> wikked +15:42 < jadeSerpent> tabs are fine for now imo, they're usable +15:42 < jrandom> mk: http://syndie.i2p.net/roadmap.html ? +15:42 < jrandom> (though there are no dates on the roadmap) +15:43 <+fox> <hottuna> nice :=) ... just posted about it to pending tasks :P +15:44 <+fox> <mk> yeah, though I'm referring to smaller goals. "document the general interactions between classes in syndie.gui", or "write up a doc regarding banning" etc. +15:44 < jrandom> ah, good point +15:45 < jrandom> i've been meaning to collate all the small/mid/high level todo items again +15:45 * jrandom adds that to the todo list +15:47 < jrandom> ok, anything have anything else to bring up for 2) Syndie dev status? +15:48 < jrandom> (of course, we've always got the dev forums in syndie, but irc is useful for quick back & forth) +15:49 < jrandom> if not, lets jump on over to to 3) January bug harvesting contest winners! +15:50 < jrandom> congrats Darn, voyde, mk, and Anonymous, and thanks to everyone who helped out +15:51 * jrandom realizes the contest was originally for the top 3, but the count was so close +15:51 < jrandom> there's a new contest on for this month too, same rules as before +15:51 < jadeSerpent> how do you know "Anonymous" was only one person? ;) +15:51 <+fox> <mk> 225 (by my count) bugs in total - impressive +15:51 <+void> :) +15:52 <+fox> <mk> jade, the key, I would think :) +15:52 < jrandom> jadeSerpent: urn:syndie:meta:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=e :) +15:53 < jrandom> it could be five people sharing that key though +15:53 < jrandom> but then they've got to share the $50USD ;) +15:53 < jrandom> (first one with the private key who signs a message to me specifying what egold acct to send it to wins ;) +15:53 < jadeSerpent> unless one kills the others +15:54 < jadeSerpent> but that kind of thing would only happen in romania +15:54 < tethrage> and russia +15:54 < jrandom> (and britain, and australia, and...) +15:55 <+fox> <mk> 50usd is a lotta money... +15:55 < jadeSerpent> in russia they'd all be killed, and the landlord would take the money and pass it on to the mob as protection fee +15:55 < tethrage> not in gbp ;p +15:55 <+fox> <mk> I know *I'd* kill for it +15:55 < tethrage> i suppose asking where you're from wouldn't get an answer, mk? +15:55 < tethrage> :/ +15:56 <+fox> <dw_g> ok, I'll take it ;) +15:56 <+fox> <mk> russia originally :D now canada +15:56 < jadeSerpent> 225 bugs is impressive, how many of those have been closed? +15:56 < tethrage> ice. +15:56 < tethrage> +n +15:57 < jrandom> jadeSerpent: i'd thumb it at maybe 75-80% addressed +15:57 < jadeSerpent> nice +15:58 < jrandom> (with maybe another 5-10% invalid/wontfix) +15:58 < jrandom> but actually, thats one of the higher level todo items - get a real management ui on the bugtracking +15:58 * jadeSerpent recommends trac +15:58 < jrandom> (it took me a while to walk through all the posts and count them all up manually) +15:58 <+fox> <mk> external to syndie? +15:59 < jrandom> hmm, with a syndie-->track exporting system? +15:59 < jrandom> s/ck// +15:59 <+fox> <mk> a nice project would be to hook syndie up to a bug tracker +15:59 < jadeSerpent> yeah +15:59 * jrandom bets a few SQL queries & inserts would do the trick +16:00 < jrandom> it would be quite worthwhile though, at least from a readonly-trac perspective +16:00 <+void> but syncing updates made to trac back into syndie is bound to be tricky, i think +16:00 < jrandom> full cycle integration isvery hard +16:00 < jrandom> right +16:00 <+fox> <mk> at some point it might be worth considering a 'revision'-type system +16:00 < jrandom> but being able to query & drill down in trac, and generate reports, etc +16:01 <+fox> <mk> where posts supercede older ones +16:01 < jrandom> ah, yeah there are hooks for that, but the Overwrite* headers aren't currently honored +16:02 < jrandom> wouldnt be too tough though, just a UI toggle to navigate to previous revs of the same post, plus a few lines of code to verify the post is authorized to override the old post +16:03 < jadeSerpent> i understand the desire to use syndie itself for bug reporting, but its design doesn't involve issue tracking, and it will always be sub-optimal for that task, imo you should use a real issue tracker +16:04 <+fox> <mk> seeing the number of bugs filed, I agree with jadeSerpent +16:05 < jrandom> though on the flip sie, how many bugs were discovered by those using syndie to file the bugs? +16:05 * jrandom is not entirely oposed to a trac or other bug tracking system +16:05 < jadeSerpent> those kinds of bugs are going to be discovered anyhow +16:05 <+void> well, severities, components, versions and closing/opening/reopening bugs can be done with syndie tags +16:05 < jrandom> right +16:06 <+void> (and most of those already are) +16:06 < jadeSerpent> like the other day when it froze up on someone who was posting a bug report, it would have frozen on them if they were posting about any subject, didn't matter that it was a bug report +16:06 < jrandom> it we can feed a real issue tracker via pseudonymously (and authentic) messages, that would be great +16:06 * jrandom has received a few private bug reports as well, which include sensitive information, - these are protected by syndie's encryption +16:07 <+fox> <mk> well, why not keep both? +16:08 < jadeSerpent> i agree that there is however no issue tracker designed with anonymity or more-than-trivial confidentiality in mind +16:09 <+fox> <mk> it would be nice to have syndie have that sort of bug tracker, but anonymity isn't too great a problem when filing most bug reports +16:10 < jadeSerpent> maybe trac could be modded to utilize syndie's features there +16:10 <+fox> <mk> jade, it'd be hard. browsers don't implement signing +16:12 < jrandom> hmm. what we have is originally based off: http://syndiemedia.i2p.net:8000/blog.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003 +16:12 < jrandom> plus http://dev.i2p.net/~jrandom/bugsp1.txt and http://dev.i2p.net/~jrandom/bugsp2.txt +16:13 < jrandom> i agree that we need something better than what we have to track these issues, and i'm open to whatever best moves us forward +16:13 < jrandom> but i'd like to keep whatever it is minimal if possible, because we're building syndie, not a bug tracker :) +16:14 < jadeSerpent> yeah well you seem to be managing it for now without one ;) +16:14 < jrandom> but i'm sure some will fallbetween the cracks, and others will have a harder time finding whats known/etc, and contributing fixes +16:15 <+fox> <mk> we probably don't even need to implement it through syndie. it's useful there to some extent, but 200+ bugs really is a lot. we should decide on a tracker and make it available through the www and through i2p +16:16 <+fox> <mk> provide a link to it atop the syndie file a bug screen, and that way we have both options. a bug tracker implementation in syndie isn't something to be using resources on now +16:17 * jrandom does love having bug tracking integrated (so people don't need to create bug tracking accounts, use fake email addresses, etc), but i'm open to proposals for what solution we should use +16:17 <+fox> <mk> I think we should keep that, but also have that bug tracker +16:18 < jadeSerpent> read-only access for the short term would be nice +16:18 < jadeSerpent> i prefer a more bug-oriented search interface +16:18 < jrandom> wouldn't be so bad, could perhaps write a one-way syndie-->issue tracker export without much trouble too, of r those who can't dont want to use the web based one +16:19 < jrandom> s/of r/for/ +16:19 <+fox> <mk> integrated bug submission is a great thing to have, but we shouldn't use the syndie archive to track 200+ bugs +16:20 < jrandom> though its great for testing our search capabilities :) [yeah, ok, i'm convinced] +16:20 < jrandom> so, one vote for trac. any other votes? please post to the syndie dev forum, with rationale, of course +16:21 < jadeSerpent> two votes for trac, unless you've already counted mine ;) +16:21 < jrandom> aye, thats what i was counting ;) +16:21 <+fox> <mk> what are the options? I know nothing about trackers +16:21 < jadeSerpent> i was hoping that was your own vote, but ok +16:22 < jadeSerpent> i've worked with trac, great third party support +16:22 < jadeSerpent> bugzilla i would say blah to +16:22 < jrandom> though, as an aside, if someone is quite familiar with an issue tracker, that'd be helpful for whipping out a syndie-->issue tracker export +16:22 < jrandom> yeah, bugzilla is a beast +16:22 < jadeSerpent> jira is also good, like trac +16:23 <+void> trac is probably familiar to lots of people, too +16:23 < jrandom> aye, and good folks too (they gave i2p a license, though we havent used it yet) +16:23 < jadeSerpent> you have a jira license? +16:23 < jrandom> aye, jira and fisheye +16:24 < jadeSerpent> cool, might as well give it a shot +16:24 < jadeSerpent> btw eclipse's mylar plugin integrates fully into bugzilla, trac, and jira +16:24 < jadeSerpent> high praises for its interface +16:25 < jrandom> damn this netbeans/eclipse battle +16:25 < bar> (bugs are reported automatically when created? ;) +16:25 < tethrage> (haha) +16:26 <+fox> <mk> hah, nice +16:26 < jadeSerpent> jrandom: netbeans support is on the mylar roadmap iirc +16:26 < jrandom> cool +16:26 <+fox> <modulus> that's what comes to those who fanatically support sun :-) +16:27 * jrandom pelts modulus with javabeans +16:27 < jadeSerpent> even though mylar is offically under the aegis of eclipse foundation +16:27 <+fox> * mk can't find a live site for trac +16:27 <+fox> <modulus> http://trac.wordpress.org/ +16:27 < jrandom> mk: http://feedspace.i2p/ atm +16:28 <+void> http://trac.edgewall.com/ +16:29 * jrandom doesn't want to spend a lot of time evaluating lots of different systems, so if someoe wants to champion a specific system, please do so in the syndie dev forum +16:29 < jadeSerpent> http://overlays.gentoo.org/proj/alt/wiki +16:29 <+void> (^ official meta-trac) +16:29 <+fox> <mk> yeah, it's all the same to me +16:30 * jrandom will assume thats it for * 3) January bug harvesting contest winners! and move us on to 4) ??? +16:30 < jrandom> anyone have anything else for the meeting? +16:30 <+fox> <mk> 'best' is overrated. whoever has the most experience with these things should probably flip a coin +16:32 * jrandom isn't really looking for a project planning / release planning system, or a source code browser (a free wiki doesnt hurt, but we've got ugha.i2p too) +16:32 < jrandom> tracking issues is the only feature i care about for that +16:37 < jrandom> ok, if there isn't anything else for the meeting... +16:37 * jrandom winds up +16:37 * void hands jrandom the baffer +16:37 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/199.rst b/i2p2www/meetings/logs/199.rst new file mode 100644 index 00000000..6a74f000 --- /dev/null +++ b/i2p2www/meetings/logs/199.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 6, 2007 +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/2.log b/i2p2www/meetings/logs/2.log new file mode 100644 index 00000000..2634cc76 --- /dev/null +++ b/i2p2www/meetings/logs/2.log @@ -0,0 +1,1125 @@ +--- Log opened Tue May 28 22:39:11 2002 +22:39 <+logger> logging started +22:40 -!- mids changed the topic of #iip-dev to: IIP Development Channel (moderated) | Weekly development meetings happen here at 0000 UTC wed. (tue if you are in a minus tz) | (during meetings) live logfile http://mids.student.utwente.nl/~mids/meeting2/livelog.txt +22:52 -!- mode/#iip-dev [-v logger] by mids +23:42 -!- mids changed the topic of #iip-dev to: IIP Development Channel (moderated) | Weekly development meetings happen here at 0000 UTC wed. (tue if you are in a minus tz) | http://mids.student.utwente.nl/~mids/iip/ +--- Day changed Wed May 29 2002 +00:16 [Users #iip-dev] +00:16 [@mids] [ athena] [ logger] [ MiB] [ SubLiminaL] +00:16 -!- Irssi: #iip-dev: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal] +00:26 -!- mode/#iip-dev [+o UserX] by mids +00:29 -!- mode/#iip-dev [+o codeshark] by mids +00:32 <@codeshark> mids: i have an additional topic for today +00:32 <@codeshark> we need more relays +00:33 <@mids> where do you want it? +00:34 <@codeshark> stability of networks +00:34 <@mids> done +00:56 <@UserX> mids: i'm going to have to leave about 30 minutes after the meeting starts +00:56 <@mids> ok, if you have agenda items, please msg them to me, and they will be discussed +00:56 <@mids> same if you want to shuffle the order +00:57 <@mids> though I tried to move the most important ones to the top +00:58 <@codeshark> add to agenda items: change meeting time +00:59 <@mids> to when? +00:59 <@codeshark> needs to be discussed +01:00 <@mids> ok +01:00 <@codeshark> for me it's a bit too late +01:00 <@codeshark> 2 AM ... +01:22 -!- mode/#iip-dev [+o nop] by mids +01:51 -!- mode/#iip-dev [-m] by mids +01:51 * mids unmoderates till it start +01:51 <@codeshark> my notebook has power for 38 minutes +01:52 * codeshark wonders if that's enough +01:52 <@mids> brb +01:53 <@mids> re +01:54 < MiB> Side question: I noticed mids' page is .nl... how many of you are Dutch? I'm a Belgian myself. +01:54 <@mids> we have atleast 10 dutch(wo)men here +01:54 < MiB> Wow, leuk om weten :) +01:55 -!- mode/#iip-dev [+o nop] by mids +01:55 < athena> codeshark: where are you at 2am that doesn't have a power outlet?? :) +01:57 <@codeshark> i have, but i'm too lazy +01:59 -!- mids changed the topic of #iip-dev to: Meeting info, agenda, livelog including live logs in case you are late): +01:59 -!- mids changed the topic of #iip-dev to: Meeting info, agenda, livelog (in case you are late): http://mids.student.utwente.nl/~mids/iip/ +02:00 <@nop> ok +02:00 <@nop> welcome +02:00 <@nop> to our 2nd meeting +02:00 -!- mode/#iip-dev [+m] by mids +02:00 <@nop> at IIP +02:00 <@mids> This is the first public IIP meeting, we plan to have such a meeting each week at the same time and place. +02:00 <@mids> Previous meeting ( http://mids.student.utwente.nl/~mids/iip/meeting1/ ) was non public, this one is. +02:00 <@mids> We will moderate the meetings to prevent chaos. After the subject is stated, the channel will be unmoderated +02:00 <@mids> so you can talk. If this becomes too chaotic, it will be kept moderated and then if you have a question or +02:00 <@mids> want to contribute something, message someone with ops (@) or voice (+) +02:00 <@mids> Meeting info, agenda, livelog (in case you are late): http://mids.student.utwente.nl/~mids/iip/ +02:00 <@mids> . +02:00 <@nop> ok +02:01 <@nop> let's get started, I've been so busy today +02:01 <@nop> multitasking +02:01 <@nop> so you'll have to excuse if I'm in and out +02:01 <@mids> np +02:01 <@nop> agenda list +02:01 <@mids> Topics: +02:01 <@mids> 1) Welcome +02:01 <@mids> 2) Stability network +02:01 <@mids> 3) Project management +02:01 <@mids> 4) Instant Anonymous Messenger +02:01 <@mids> 5) Website +02:01 <@mids> 6) Documentation +02:01 <@nop> ok +02:01 <@mids> 7) Other +02:01 <@nop> stability network +02:01 <@mids> 8) Questions? +02:01 <@mids> 9) Next meeting +02:01 <@mids> . +02:02 -!- mode/#iip-dev [-m] by mids +02:02 <@nop> as you may have noticed +02:02 <@mids> maybe initial questions? +02:02 <@nop> sure +02:02 <@mids> anybody.... +02:02 < Neo> hi. +02:02 < Neo> do you know the causes of the network problems? +02:02 <@mids> Neo: that will be answered in a minute +02:02 <@nop> ok +02:02 <@mids> first we look if there are initial questions +02:02 <@nop> any initial questions +02:02 <@mids> guess not, nop go on (+m) +02:03 <@nop> ok +02:03 <@nop> network stability +02:03 <@nop> the reasons of this are many +02:03 <@nop> for one +02:03 <@nop> this network has been sitting in a laptop on a desk at my work for a long time +02:03 <@nop> problem with this is +02:03 <@nop> someone moved the laptop +02:03 <@nop> not thinking it needed to be on +02:03 <@nop> so... that was one problem +02:04 <@nop> second +02:04 <@nop> I decided to move it +02:04 <@nop> to a beefier box +02:04 <@nop> especially because of all the Diffie-Hellman calculations +02:05 <@mids> can you explain the case with the DH? +02:05 <@nop> it is now gone from a 300 mhz +02:05 <@nop> actually +02:05 <@nop> 366 mhz +02:05 <@nop> to a 933 mhz +02:05 <@nop> from 128 megs of ram to 512 +02:05 <@nop> big difference +02:05 <@nop> :) +02:05 <@nop> Pent II - Pent III +02:05 <@nop> ok +02:05 <@nop> from that point +02:05 <@nop> we found a memfree assertion error - actually athena also discovered it running rc2 +02:06 <@nop> and this problem needed to be addressed +02:06 <@nop> which was +02:06 <@nop> and just recently +02:06 <@nop> upon fixing that problem +02:06 <@nop> it has been since stable +02:06 <@nop> now +02:06 <@nop> we would really love to move away from centralization and that's our main goal +02:06 <@nop> but it's a one step at a time type of deal, and this is a developer's network +02:06 <@nop> so sometimes reliability is not it's best +02:07 <@nop> but I am trying to keep everyone happy at this level +02:07 <@nop> any questions +02:07 <@nop> regarding this matter +02:07 <@mids> can you explain the case with the DH? +02:07 <@nop> Case with DH +02:07 <@nop> Diffie-Hellman key exchange calculations take a lot of processes +02:07 <@nop> so when it goes down for a sec +02:07 <@nop> and everyone tries to connect +02:07 <@nop> it spikes the cpu at 99% +02:08 <@nop> because lots of calculations are taking place +02:08 <@nop> our goal +02:08 -!- mode/#iip-dev [-s] by mids +02:08 <@nop> to fix this +02:08 <@nop> we have done a few things +02:08 <@nop> we put a poll/delay to handle calculations better +02:08 <@nop> and 2 +02:08 <@nop> we are planning on implemented a better Multi-precision library in the future +02:09 <@nop> any more questions regarding this matter +02:09 <@mids> I have one thing to ad: +02:09 <@nop> ok +02:09 <@nop> please +02:09 <@mids> network graph: http://mids.student.utwente.nl/~mids/iipstats/network.html +02:09 <@mids> as you see (especially at weekly) +02:09 <@mids> after a long network downtime +02:09 <@mids> we loose a big time of users +02:09 <@mids> and it takes a long time to gain them back +02:09 <@mids> this is bad for our reputation +02:09 <@nop> and for anonymity +02:09 <@mids> maybe we should communicate better with the users +02:09 <@nop> more users the better +02:10 <@nop> agreed +02:10 <@mids> when you know that the net will go down: do a global announcement +02:10 <@nop> ok +02:10 <@nop> sometimes +02:10 <@nop> I don't know +02:10 <@mids> if you observe that it is down: update status on site +02:10 <@mids> . +02:10 <@nop> ok +02:10 <@nop> any questions or comments on this topic +02:10 < athena> if i can make a suggestion: a brief update in the ircd motd would be great also +02:10 * Neo things update status on site is really good idea +02:11 <@nop> ok athena : you are noted, and I will make my efforts in doing so +02:11 < athena> thanks' +02:11 < Neo> (sometimes I don't know if it is the network or just me) +02:11 <@nop> Neo and mids I agree on update status +02:11 <@nop> great idea +02:11 <@mids> codeshark had something on the node status +02:11 <@nop> k +02:11 <@codeshark> just thought it could be integrated in the nodechecker +02:12 <@nop> please elaborate +02:12 <@codeshark> if i see that all hosts are down (=network down), i could update the status page +02:12 <@nop> cool +02:12 <@nop> sounds great +02:13 <@nop> this also could go well with nym's who's online, instead of that, just have a network status page +02:13 <@mids> please use . when done +02:13 <@codeshark> . +02:13 <@nop> . +02:13 < Neo> . +02:13 <@mids> how many public relays do we have? +02:13 <@mids> . +02:13 <@codeshark> right now we 15 in the nodechecker list +02:13 <@codeshark> 13 are online +02:14 <@codeshark> . +02:14 <@nop> agenda +02:14 <@mids> do we need more? +02:14 <@mids> . +02:14 <@nop> we always need more +02:14 <@nop> that's a given +02:14 <@nop> :) +02:14 <@nop> . +02:14 <@codeshark> not for stability +02:14 <@codeshark> but for anonymity +02:14 <@codeshark> . +02:14 <@nop> yes +02:14 <@nop> . +02:14 <@mids> other questions/ +02:14 <@mids> . +02:14 <@nop> this . thing is funny +02:14 <@nop> . +02:14 * mids does no . after a question anymore +02:15 <@mids> okay, next +02:15 <@mids> 3) Project management +02:15 <@nop> mids - you might want to open up on that +02:15 <@mids> maybe we should try to be more professional +02:15 <@mids> while keeping it fun +02:15 <@nop> well +02:15 <@nop> maybe more organized +02:15 <@mids> publish our milestones +02:15 <@nop> professionaly is up for debate +02:16 <@mids> delegate tasks +02:16 <@nop> the challenge with professional is we can't be committed every single day to this, because of real life +02:16 <@nop> but yes +02:16 <@nop> we should definitely delegate tasks +02:16 <@nop> which +02:16 <@nop> I think we do +02:16 <@nop> but not everyone has remained in contact about their task +02:16 <@mids> maybe make delegation more open +02:16 <@mids> so everybody knows who to inform about what +02:16 <@nop> ok +02:16 <@nop> yes +02:16 * Neo has a suggestion re: project management helper that we are using in DC. +02:16 <@mids> I remember several cases of double work +02:16 <@mids> . +02:16 <@mids> yes Neo ? +02:17 < Neo> Mr Project. +02:17 <@nop> an agent? +02:17 < Neo> Here is our release schedule: http://citystateinc.com/dc/dc_project_5-28-2002.gif +02:17 < Neo> Its a task sheduler thing, take a look at the gif it explains it pretty much. +02:17 < Neo> Its just a helper tool. +02:18 <@nop> sounds good +02:18 <@nop> also +02:18 <@nop> we need a whiteboard type communication device +02:18 <@nop> something that can allow developer's to communicate visually +02:18 <@nop> especially as we dive deeper into complications of anonymous network +02:18 <@nop> s +02:18 <@codeshark> mids and I tried some whiteboard stuff +02:18 <@nop> networks +02:18 <@codeshark> but it doesn't seem to be very useful +02:18 <@codeshark> at least the tools we tried +02:18 <@codeshark> . +02:18 <@nop> hmm +02:18 <@mids> those we tried were too slow and limited +02:18 <@mids> . +02:19 <@nop> hmm +02:19 <@nop> what did you try +02:19 <@mids> some freshmeat ones +02:19 <@nop> k +02:19 <@mids> does anybody have good experience with public whiteboards? +02:19 <@nop> guess not +02:19 <@mids> hm, nope +02:19 <@mids> :) +02:19 <@nop> well +02:19 <@nop> maybe we should delegate a task +02:19 <@mids> put it on the todo +02:20 <@nop> todo/task delegateion +02:20 <@nop> who wants to assist in finding a whiteboard that would suit developer's needs +02:20 <@nop> it can always be more than one person as well +02:20 <@mids> well, if I find one, I wont keep it a secrey +02:20 <@nop> k +02:20 <@nop> well it's on the todo +02:20 <@mids> but it has to be multiplatform +02:20 <@nop> yes +02:21 <@mids> ok +02:21 < Neo> nop, what do you see people finding the whiteboard useful for? (curious of your ideas) +02:21 <@nop> well, I am visual with networks +02:22 <@nop> and I know there have been a few times +02:22 <@nop> that visual drawings make sense +02:22 <@nop> rather than chatting on irc +02:22 < Neo> k, thanks :) +02:22 <@nop> that can be limiting and hard to get your algorithm/network design across +02:22 <@mids> especially the explination of the relays +02:22 < Neo> some screen grabs could come in handy for docs also. +02:22 <@nop> yes +02:23 <@nop> so far +02:23 <@nop> I've come to the point of drawing it out and faxing it last time +02:23 <@nop> :) +02:23 <@mids> lol +02:23 <@nop> ok - anyway +02:23 <@codeshark> nop: email :) +02:23 <@nop> noted that whiteboard would be a plus +02:23 <@nop> yeah yeah +02:23 <@mids> other point: +02:23 <@nop> email smemail +02:23 <@nop> you guys think we're like geeks or somethin +02:24 <@mids> banks suggested to follow the thought of the Cathedral Bazaar thing by Eric Raymond: release often +02:24 <@nop> I'm still learning email ;) +02:24 <@mids> I think that is under project management too +02:24 <@nop> umm, link +02:24 <@codeshark> (... release early) +02:24 <@mids> http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ +02:25 <@codeshark> i think that's what we doing. or do you want to release more often? +02:25 <@codeshark> . +02:25 <@mids> Banks? +02:25 < Banks> I'm not sure yet +02:26 * mids guesses he is just anxious to see RC2 +02:26 < Banks> it helps people to see that the path to RC2 is advancing swiftly :) +02:26 <@nop> RC2 is done - it's docs that are being the hold up +02:26 <@mids> docs are point 6 +02:26 <@nop> k +02:27 < Banks> Docs on RC2? +02:27 <@mids> Banks: yes +02:27 <@nop> well, docs for 1.1 official release +02:27 <@nop> but yes +02:27 <@nop> if we don't get progress done +02:27 <@nop> on docs +02:27 <@nop> then we'll be lagged period +02:27 <@nop> for release of 1.1 Release +02:27 < Banks> I've just done a ton on the docs but not for RC2. Haven't sent it yet. Don't know cvs +02:28 <@nop> hehe +02:28 <@nop> ok +02:28 <@codeshark> banks: what did you do? +02:28 < Aster> hola +02:28 <@mids> hi Aster please check the notices +02:28 < Aster> which notices? +02:28 < Aster> im soo lost +02:28 < Aster> whats going onn? aaahhhh +02:28 <@mids> [notice(Aster)] welcome, the channel is moderated if you have something to say, message me or somebody else with ops or voice +02:28 <@mids> [notice(Aster)] Information, agenda and logs: http://mids.student.utwente.nl/~mids/iip/ +02:29 < Banks> codeshark: A handful of things. Related quotes at the beginning of each chapter, a small FAQ ... +02:29 < Banks> How to contribute +02:29 < Banks> Why Anonymity? +02:29 < ptsc> suggestion if i may be so bold: default option, which can be disabled, of 'crippling' urls to be non-clickable, in the proxy. +02:29 <@codeshark> ok. we have to talk about that in point 6 +02:29 <@mids> great +02:29 < Banks> How to configure a WinXP firewall to allow IIP +02:30 <@mids> ptsc: what do you mean? +02:30 < ptsc> perhaps by chaning http to some other string such as wysiwyg or url or something unlikely to be anonymity compromising, like the anonymity tripwire in freenet +02:30 <@mids> you mean, that if I say http://www.google.com/ that it will be censored? +02:31 < ptsc> since the easiest means of compromising anonymity is to post a honeypot url to a crowded channel +02:31 < SkyRat> no just not clickable +02:31 <@mids> anybody want to respond on that one? +02:31 < ptsc> this should be something that can be disabled. +02:31 < Banks> That would have to be done at the IRC client level wouldn't it? +02:31 < athena> or server +02:32 <@mids> it can be done on the server level +02:32 <@mids> but I think there is some responcibility for the user +02:32 < ptsc> contaminating server traffic might be bad +02:32 <@mids> should we also change telephone numbers? +02:32 < Banks> Lot of overhead though isn't it? +02:32 * Neo thinks manipulating content should not be done with the system. that is a pure client issue +02:32 < athena> think this problem can't be solved +02:33 < Banks> It's a good point though +02:33 <@mids> maybe a specialmodified security client +02:33 <@mids> see point 5! +02:33 <@mids> err 4 +02:33 * Banks is trying not to jump to the docs part, "I mentioned it in the docs" +02:33 <@mids> hehe +02:33 * Neo thinks mids is correct, it has a place in a custom client maybe, or in "security" patches to existing clients +02:33 < athena> there should be discussion of this in the manual... i.e. "ways of losing your anonymity" +02:34 <@mids> I suggest going on , and see what point 4 brings us after MiBs comment +02:34 < MiB> :) +02:34 < MiB> You spoke about better communication with users a bit earlier, how do you feel about a public mailing list and/or BBS where developers and testers can conversate with each other? +02:34 <@mids> afaik we have 1 mailinglist +02:34 * athena points out #iip +02:34 <@mids> iip-dev mainly for development +02:35 < Banks> Maybe an IRC chan where people who can't connect to IIP can go? +02:35 <@mids> although also other topics +02:35 <@codeshark> we have the bug-list on sourceforge too +02:35 < ptsc> i actually have written a sort of 'guide for the clueless' +02:35 < ptsc> including some of these +02:36 < Banks> I saw that at deja, ptsc. Nice. +02:36 < ptsc> http://groups.google.com/groups?selm=ss9rdugclv39cemnk4ue9t8jv6n8se8a3h%404ax.com&output=gplain +02:36 < ptsc> it is written to a specialized audience concerning an iip channel that is as yet relatively uninhabited +02:36 < ptsc> thx +02:36 < Banks> It's a good idea for a chan +02:37 < ptsc> i think it captures the "fool's mate" ways of trashing your own anonymity, but i do believe more sophisticated attacks could be made especially by an opponent who both has surveillance capability and is running a node. +02:37 <@mids> cool for an howto I would say! +02:38 <@mids> noe?j +02:38 <@mids> err +02:38 < Neo> Re: BBS - Distribued City is a ssl/web based community system located at xs4all. We welcome IIP forums in our forum section. +02:38 <@mids> neo? +02:38 < Banks> I tried to put some of it into the docs. +02:38 < ptsc> i think it's beyond a mid-level opponent such as an unaided church of scientology but assisted by hackers and/or a corrupt node, and a manipulated federal agency (FBI), i think you could possibly bust it open +02:39 < ptsc> it doesn't have the latency of the remailer network (and in fact couldn't, and still be reasonably 'instant') +02:39 < Neo> The DC system also has GPG Web private messaging. Mids and I and others have kept in contact when IIP was down, and also relevant discussion of issues related to IIP. +02:39 < Neo> We are in beta now, but opening to public soon. +02:39 < Neo> . +02:39 <@mids> So we can use DC for the non-irc part of IIP +02:39 <@mids> forums, announcements +02:39 < Neo> You bet. +02:39 < Banks> A corrupt node would have to unscramble the end-to-end encryption too, wouldn't it? +02:39 < Neo> We trashed our chat system, and are using IIP, so you guys jump right in. +02:40 <@mids> Banks: err, thats offtopic atm +02:40 < Banks> mids: You're right +02:40 <@mids> I suggest discussing the IIP internals later +02:40 < ptsc> i guess by 'corrupt' i meant the person rather than the node +02:40 <@mids> lets hurry and move on before chocolate joins +02:40 <@mids> any objections? +02:40 < ptsc> and by that, i mean just that the person is going to run netstat periodically and log who is connecting to them, +02:41 < ptsc> while also being logged in a channel as a nick, watching who shows up, and weeding people out by a process of elimination +02:41 < Neo> We can give IIP their own custom forums. - Newbies - Tech - Dev... let us know. +02:41 -!- mode/#iip-dev [+o Chocolate] by mids +02:41 < ptsc> they could also get network internals of other nodes they connect to, and then obtain subpoenas/'carnivore' capability on those nodes +02:41 <@mids> ptsc: its offtopic +02:41 <@mids> please discuss it later +02:41 <@mids> (getting chaotic) +02:41 < ptsc> apologies +02:41 <@mids> np +02:42 <@mids> 4) Instant Anonymous Messenger (wilde wont be here) +02:42 <@mids> wilde was too sleepy +02:42 <@mids> so u +02:42 <@nop> ok +02:42 <@mids> so I 'll just paste what he said: +02:42 <@nop> please do +02:42 <@mids> Status and features: +02:42 <@mids> wilde started to work on an IM, easy to use program to connect to IIP. +02:42 <@mids> He got the IRC connection working. The plugin system works too. +02:42 <@mids> Apart from IRC and IM support there will also be features for digital +02:42 <@mids> currencies. He is looking into cryptography now. +02:42 <@mids> For further information email wilde@invisiblenet.net or visit #iam-dev +02:42 <@mids> . +02:42 <@nop> ok +02:42 <@nop> also +02:42 <@nop> if freenet ever gets stable +02:42 <@nop> it would be nice to add a dcc transport +02:42 <@nop> that utilizes freenet +02:42 <@nop> as a plugin +02:43 <@mids> yup +02:43 <@nop> ok +02:43 <@nop> sounds good +02:43 <@nop> any questions +02:43 <@mids> and maybe, like ptsc suggested +02:43 < Banks> True, but won't RC2 have DCC? +02:43 <@mids> filter the IRC, to disable urls +02:43 <@nop> IIP rc2 will not have dcc +02:43 <@nop> it compromises anonymity +02:43 <@nop> file sharing will have to be later within IIP +02:44 <@nop> but it's in planning +02:44 < Banks> ok, I thought there might be a way to do it without compromise +02:44 <@nop> not till we decentralize +02:44 <@nop> then there will be +02:44 <@nop> utilizing broker agents +02:44 <@nop> etc +02:44 <@nop> we have a fileserv plugin for xchat +02:44 <@nop> that does base64 +02:44 <@nop> anyway +02:44 <@nop> that's the plan +02:44 <@nop> ok +02:44 <@nop> next topic +02:45 <@mids> maybe questions +02:45 <@mids> but we dont know all answers +02:45 <@mids> cause wilde aint here +02:45 <@mids> :) +02:45 <@mids> so just ask, he can read them in the logs +02:45 < Neo> wilde coding in perl? +02:45 <@nop> java +02:45 <@mids> java +02:45 <@nop> I believe +02:46 <@mids> he bases it on a full IM client that a friend of him wrote +02:46 < Neo> ah +02:46 <@mids> okay, lets hurry to topic 5 +02:46 <@mids> we have 9 in total +02:47 <@nop> topic number 5 is ... +02:47 <@nop> drum roll please +02:47 <@mids> write your burning quesitons down +02:47 <@mids> 5) Website +02:47 <@nop> ahh +02:47 <@nop> yes +02:47 <@nop> the lag +02:47 <@mids> I want to give the word to nym +02:47 <@nop> yeah +02:47 <@nop> umm +02:47 <@mids> nym? +02:47 <@mids> okay +02:47 <@nop> ok +02:47 <@nop> site looks ok +02:47 <@mids> he was here last week +02:47 <@nop> the fear I have +02:47 <@mids> and appologied for the delay +02:47 <@nop> is that it will take him forever to update any changes +02:47 <@mids> he has made a new updayed design: +02:47 <@mids> http://buttsnot.com/invisible2.html +02:48 <@nop> or press releases +02:48 <@mids> the first one was http://mids.student.utwente.nl/~mids/iip/meeting1/draft2.jpg +02:48 <@nop> so dunno +02:48 <@mids> any comments on the looks? +02:48 <@nop> and we need a plan b +02:48 <@nop> just in case he never shows a stable site +02:48 < tikk> nice job.. and i'm a designer +02:48 < tikk> there's a few table errors +02:48 < Neo> ellison is available for plan b +02:48 < Aster> its ok, could use some more work +02:49 < tikk> cosmetic stuff +02:49 <@nop> neo are you sure +02:49 <@nop> that would be great +02:49 <@nop> also Neo +02:49 <@nop> thnx for the IIP stuff you wrote +02:49 <@mids> I think it is not good enough for > 15 hours work +02:49 <@nop> it's impressive +02:49 < Neo> yes, he already offered +02:49 <@nop> great +02:49 < Neo> what IIP stuff? +02:49 <@nop> dc +02:49 <@nop> on dc beta +02:50 < Neo> OH. ellison did that :) +02:50 <@nop> also +02:50 <@nop> well thank him +02:50 <@nop> also +02:50 <@nop> does ellison do logo design? +02:50 < Neo> will do, he will read this log +02:50 <@mids> FYI, ellison is the gfx guy of Distributed City +02:50 < Neo> you bet. +02:50 <@nop> kewl +02:50 < Neo> and alta/lese/liquid privacy +02:50 <@nop> is he fast working +02:50 <@nop> like we would be able to see something soon +02:50 <@nop> type of deal +02:50 <@nop> because I"m bout ready to put my foot down +02:50 <@nop> and go with plan b +02:51 < Neo> he will be on later, we can have a quick meeting then, I can't speak for him +02:51 <@mids> update on nym +02:51 <@nop> ok +02:51 <@mids> he got $100 from us to do a design +02:51 <@mids> payed out of the donations depot +02:51 < Neo> now but I know that he was very interested in doing something for IIP if the opportunity arose. +02:51 <@mids> all the donators agreed +02:51 <@mids> but, what we have now is not usable +02:51 <@mids> it is going too slow +02:51 <@nop> and we know 100$ ain't much +02:52 <@nop> but I don't feel that we even have that worth +02:52 <@mids> but well, we dont have more +02:52 <@mids> I am sure that nym means it all right +02:52 <@nop> we gave it to him like more than a month ago +02:52 <@mids> but lacks the time +02:52 <@nop> yes +02:52 <@nop> I understand +02:52 <@nop> but we have to be practical +02:52 < Aster> once he gets the design done, someone else (ide be willing to) get the rest together +02:52 <@mids> we want a website asap +02:52 <@mids> Aster: thanks +02:52 <@nop> and good logo's +02:52 <@nop> yes thanks +02:53 <@mids> so what are the options: +02:53 <@mids> - use what we have and craft it into a site +02:53 <@mids> - put another gfx guy/girl on it +02:53 <@mids> - keep the old site +02:53 <@nop> old site has to go +02:53 <@nop> I like it +02:53 <@nop> but it's too villany +02:53 <@mids> - wait for nym to finish it +02:54 <@nop> and casper == copyright infringement +02:54 < Banks> I think the old site is pretty good. Logo and Times New Roman aside. +02:54 <@nop> hehe +02:54 <@nop> you know +02:54 <@nop> you'd be surprised +02:54 <@nop> but that was done in 10 minutes +02:54 < Banks> shame that Gamespy had to steal our logo before we had a chance to create it :) +02:54 <@nop> haha +02:55 <@nop> ok +02:55 <@nop> so on topic of website +02:55 <@nop> reverting back to old one is last option at most +02:55 <@nop> I'm really wanting to go for a brighter look +02:55 <@nop> something more professional +02:55 <@nop> because +02:55 <@nop> if we get attention by press +02:55 <@nop> the darkness will give way to the "media hacker" term +02:56 < Banks> true. I think we should think about who the target market is and cater it to that. +02:56 <@nop> and IIP will not go down like that +02:56 <@nop> Banks: agreed +02:56 <@nop> the target market is how you market it though +02:56 <@nop> the way I see this +02:56 < Neo> ellison can *REALLY* help you with this. +02:56 <@nop> yes +02:56 <@nop> I see +02:56 <@mids> I have seen ellisons work +02:56 <@nop> I have as well, it's very good +02:56 <@mids> and if he wants, lets give him a try +02:56 <@nop> PR and website == one idea +02:57 < Banks> True, but there's already an audience for it. Slashdot-types. +02:57 < Aster> market to both groups: hackers and corp looking...have 2 sites +02:57 < Aroonkoa> And kuro5hin. :) +02:57 <@mids> about the $100, I see it as lost +02:57 <@nop> yes +02:57 <@mids> and we dont do such things again in the future +02:57 <@Chocolate> 2 sites is way to much overhead +02:57 <@mids> lets name it a learning phase +02:57 <@nop> yes +02:57 < Aster> chocolate: in what way? +02:57 <@nop> we want the invisibleNet front page +02:57 < Banks> The program itself is always significantly more important than the website. +02:57 <@nop> then the Invisible Irc Project page +02:58 < Banks> A good program markets itself. +02:58 <@nop> InvisibleNet is the Dev team +02:58 <@nop> all of us +02:58 <@nop> everyone using IIP +02:58 <@nop> is part of an invisibleNet +02:58 <@nop> :) +02:58 <@nop> a society so secret we don't even know ourselves +02:58 <@nop> ;) +02:58 <@nop> but seriously +02:58 <@nop> and then we need the main IIP page +02:58 <@mids> tikk offers his help too +02:58 <@mids> maybe we can make a little web-board +02:58 <@nop> tikk, much appreciated +02:58 <@mids> for input etc +02:59 < Neo> Banks: yes, but part of the marketing needs to cater to PR for political reasons ciphers only go so far +02:59 <@mids> who wants to participate in the webboard? (just an idea) +02:59 * mids +02:59 <@nop> Neo : please elaborate on that comment +02:59 < Banks> Neo: I agree +02:59 * nop doesn't quite understand yet +03:00 <@nop> also - mids : anytime Website is topic have website/PR as one topic +03:00 <@nop> because it is one in the same +03:00 <@mids> nop: yup +03:00 <@nop> ok +03:00 <@nop> well, if ellison is willing +03:00 <@nop> and tikk you are willing to offer advice +03:00 <@nop> let's do this +03:01 < Neo> re: PR. Like your comment above about the "media hacker" term. The dark "villianry" (sp?) +03:01 <@nop> and anyone else willing to get the website to the optimal point then hop on and let's go for it +03:01 <@nop> Neo: point seen - understood +03:01 < Neo> image is not good for PR - Political PR and marketing for new users PR. +03:01 < Neo> That is why people interested in saving money from people who try and take it away from +03:01 < Aster> nop: you mean as in webmaster, or just finishing the job of the site (hop on comment) +03:02 < tikk> i'm willing to help advise, sure.. i'm not sure if i'm +v here +03:02 < Neo> them and use crypto, it is better for them to use crypto for freedom of speech uses. not to capitalize on +03:02 <@mids> tikk: we hear you +03:02 <@nop> aster that's debatable, lately, I've been the semi-webmaster +03:02 <@mids> tikk: the chan isnt +m +03:02 <@nop> aster +03:02 < Aster> yup? +03:02 <@nop> if you want to it's an open position once we get it up +03:02 < Neo> how they are protecting assets. (nuff said, this is for another room/thread) +03:02 < Aster> sure +03:03 <@nop> I have a feeling this is going to be bigger than I can handle +03:03 <@mids> ok +03:03 <@nop> Neo : good point ;) +03:03 * mids asks contact info from parties involved +03:03 <@mids> and I'll notice you +03:03 <@nop> and pubkeys +03:03 <@nop> also +03:03 <@nop> on a side note +03:03 <@nop> everyone registered with trent +03:03 <@nop> has anonymail access +03:03 <@nop> user@iipmail.net +03:04 <@nop> pgp compatible +03:04 <@nop> somewhat +03:04 <@nop> :) +03:04 <@nop> it's like memoserv here +03:04 <@nop> and is very useful +03:04 <@nop> continue +03:04 <@nop> off topic +03:04 <@mids> ok +03:04 <@nop> but needed to say +03:04 <@mids> (just ask in #iip for more info) +03:04 <@nop> yep +03:05 <@mids> I'll contact the parties who offered their interest in the web/pr +03:05 <@mids> lets move on +03:05 <@mids> ) Documentation (codeshark, cohesion or mids) +03:05 <@mids> cohesion isnt here +03:05 <@Chocolate> can I stick something in real fast? +03:05 <@nop> sure +03:05 <@mids> ok +03:05 <@Chocolate> going back to the whiteboard +03:05 * mids scrolls up +03:05 < Banks> That's what I'm always saying to my wife. +03:05 <@Chocolate> I found one called "CSV" (if I remeber rigth) +03:06 <@Chocolate> I'll find the url and send it to #iip +03:06 <@Chocolate> . +03:06 <@mids> nice +03:06 <@mids> 6) Documentation +03:06 <@mids> last week we had a lenghty talk +03:06 <@mids> 3 ppl involved with documentation +03:06 <@mids> all pretty busy +03:07 <@mids> docu is really needed before release +03:07 <@mids> there are 2 systems: +03:07 <@mids> LaTeX or Docbook +03:07 <@mids> we agreed on using LaTeX now +03:07 <@mids> and moving to docbook in a later state +03:08 <@mids> current latex is available on http://mids.student.utwente.nl/~mids/docdemo/ +03:08 < Banks> I was using HTML to PDF with HTMLDOC. +03:08 <@mids> but it needs review +03:08 <@mids> and also misses some items +03:08 <@mids> (unix install) +03:08 <@mids> probably anonymail can be added too it too as appendix +03:08 <@mids> now, we heared that a few people have made additions to the manual +03:09 <@mids> problem is that we dont know what version +03:09 <@mids> so lets coordinate that +03:09 <@mids> and put everything together +03:09 <@mids> . +03:09 <@mids> anybody something to add? +03:10 <@mids> hm +03:10 <@mids> we have 3 translations +03:10 < Banks> Is codeshark still here? +03:10 <@mids> spanish, french and dutch +03:10 <@mids> so it becomes a bit heavy +03:10 <@mids> we need documentation management. +03:11 <@mids> any news about cohesion's status? +03:11 <@mids> nop? +03:11 <@nop> here +03:11 <@nop> sorry +03:11 <@nop> umm +03:11 <@nop> he's around +03:11 <@nop> on earlier today +03:11 <@mids> but he is documentation manager not? +03:11 <@nop> umm +03:12 <@nop> yes +03:12 <@nop> hold +03:12 <@nop> just a sec +03:12 <@nop> someone at work talking in my ear +03:12 <@mids> :) +03:12 <@mids> --- advertizement --- +03:12 < Banks> Codeshark: Are you still here? Check your pm +03:13 <@mids> Banks: if you talk to him, tell him to respond here too :) +03:13 < Banks> codeshark has been idle 27mins 38secs +03:13 < Banks> :) +03:13 <@mids> darn, out of battery power +03:13 <@Chocolate> lol +03:14 <@nop> back +03:14 <@nop> ok +03:14 <@mids> ellison: we are now at the part 6) Documentation +03:14 <@nop> cohesion is document manager +03:14 <@mids> ok +03:14 <@nop> and main technical writer +03:14 <@mids> but he seems to be busy +03:14 <@nop> but people have real life +03:14 < ellison> thanks, catching up in the logs +03:14 <@nop> and I think that is what is going on +03:14 <@nop> so... +03:14 <@mids> true +03:14 <@nop> we should have a assistant doc manager +03:14 <@mids> suggestion: put as much as possible in CVS, so more can work on it +03:14 <@nop> so that this can continue +03:15 <@nop> mids = you seem like you have a lot on plate +03:15 <@nop> do you +03:15 <@nop> or does it seem that way +03:15 <@nop> with IIP that is +03:15 < Banks> I can help but I'm not familiar with CVS +03:15 <@nop> hold +03:15 <@mids> nop: yup +03:15 <@nop> banks +03:15 <@mids> need to delegate +03:15 <@nop> I'll get you doc on cvs +03:15 <@nop> well chocolate - how are you lately ol' buddy ol pal +03:16 <@nop> ok +03:16 <@mids> I can do the assistent doc management +03:16 < Banks> Does anyone want a copy of a PDF I churned out? Codeshark is busy right now. +03:16 <@mids> but I am not going to write +03:16 <@mids> I can put input into LaTex +03:16 <@mids> and keep it central +03:17 <@mids> it wont be much time for me +03:17 <@mids> Banks: url +03:17 <@nop> sure Banks +03:17 < Banks> Where do you want me to email it? +03:17 <@nop> mids = if you waill approve and put in cvs as a contrib +03:17 <@nop> waill =will +03:17 <@nop> aster +03:17 <@mids> nop: what? my latex of Banks pdf? +03:17 <@nop> I believe so +03:18 <@nop> also +03:18 < Aster> nop: hum? +03:18 <@nop> ellison wrote a good end users doc on dc beta +03:18 <@nop> much appreciated +03:18 <@nop> and could be very usable in future +03:18 <@nop> for general IIP +03:18 <@nop> on website +03:18 <@nop> here +03:18 <@nop> a getting started +03:18 <@nop> type thing +03:18 < Banks> mids: Do you want me to email it to mids@invisiblenet.net? +03:18 <@mids> Banks: please +03:19 < Banks> ok +03:19 <@nop> aster - mind if I delegate you a webmaster once site goes up +03:19 < Aster> nop: dont mind at all :) +03:19 < Banks> mids: Sent. +03:19 < ellison> nop: i can clean it up and re-purpose it for the site +03:19 <@nop> great +03:20 <@nop> ellison - at a later point in time +03:20 <@nop> we would like to discuss web dev with you +03:20 < ellison> ok +03:20 < Banks> mids: Tell me what you think. +03:20 <@mids> Banks: will do once I got it +03:21 <@nop> docs - anymore comments on docs +03:21 <@nop> or questions +03:21 < Banks> mids: Ok, I can send the HTML with BMPs later too. +03:21 < Banks> I've got a question. +03:21 <@mids> Banks: I'll contact you and put it central +03:21 <@nop> yes sir +03:21 < Banks> The whitepaper says "here is a "steady" streaming protocol, for those who can afford the bandwidth, for constant traffic, (which protects you from traffic analysis of any form, but will cause a 500 millisecond lag)." +03:22 < Banks> And then "[name of this parameter?]" +03:22 < Banks> What is the name of the parameter? :) +03:22 <@mids> euh +03:22 <@mids> too detailed +03:22 <@mids> this is a public meeting :) +03:22 <@Chocolate> isnt that offtopic? +03:22 < Banks> My bad. +03:22 <@mids> I got the contact info from those with documentation +03:23 <@mids> I will gather it +03:23 <@mids> and put it central +03:23 <@mids> then find editors to edit +03:23 <@mids> dont fear LaTeX or CVS +03:23 <@mids> you'll live +03:23 <@mids> :) +03:23 <@mids> . +03:23 < Banks> Reading up on LaTeX was a nightmare :) +03:23 <@Chocolate> ok so is Documentation finished? +03:24 <@mids> Chocolate: lol +03:24 <@mids> Chocolate: well, the subject here is +03:24 <@mids> I think. +03:24 * Chocolate kicks mids +03:24 <@Chocolate> thats what I ment +03:24 <@mids> oh :) +03:24 <@mids> before we go to a free-for-all question round +03:24 <@Chocolate> I ment "is agenda item 6 finished" +03:25 <@mids> lets do 1 more public thing +03:25 <@mids> about the meeting time +03:25 <@mids> Quick jump to topic 9 Next meeting: +03:25 -!- Chocolate changed the topic of #iip-dev to: Meeting info, agenda, livelog (in case you are late): http://mids.student.utwente.nl/~mids/iip/ | current topic: meeting time +03:25 <@mids> statement: current time too late for Europeans, better time? +03:25 <@mids> codeshark and me would prefer 2 hours earlier +03:26 <@mids> (its 3:30 am here now) +03:26 < Aster> ouch +03:26 <@mids> Kronos-X: we are now almost finished +03:27 <@mids> Kronos-X: trying to settle a better meeting time +03:27 < Kronos-X> I'm unpredictable, so I'm flexible by default. +03:27 < Kronos-X> :) +03:27 < MiB> 3:38 over here, 3 to 4 hours earlier would be much more humane for me :) +03:27 <@mids> nop: what about 2 hours earlier? choc? banks? neo? +03:28 <@Chocolate> IIRC 0000 is the earlyst nop can make it +03:28 < Neo> anytime is cool with me, its the others to ask. :) +03:28 <@Chocolate> 2200 tuesday should be ok for me +03:29 < Banks> Fine by me +03:29 <@Chocolate> it's important that nop and/or userx can make the meetings though +03:29 < Aster> uh, whats thaht eastern? +03:29 <@Chocolate> no, UTC +03:29 < Aster> what would be eastern then? ( i dont know how this time stuff works :) +03:29 <@mids> http://www.timeanddate.com/worldclock/ +03:29 <@Chocolate> EDT is -5 +03:29 < Aster> k +03:29 < ellison> oooh, an ISO compliant meeting! +03:29 < Kronos-X> Heh +03:30 <@mids> nop seems to be busy +03:30 <@mids> he has a veto on the time imho +03:30 <@Chocolate> same +03:30 <@mids> those who showed up didnt complain +03:30 <@mids> so proposal is 2 hours earlier +03:30 <@mids> end of meeting time? +03:30 <@mids> . +03:31 <@mids> topic 7/8 Free 4 all Question round!!! +03:31 <@mids> sorry for cutting you all off earlier +03:31 <@mids> take revenge now +03:31 <@Chocolate> lol +03:31 <@nop> sorry +03:31 <@nop> back +03:31 <@mids> nop: 2 hours earlier meeting okay? +03:31 <@nop> ooh +03:31 <@nop> well, I'm in prime of working time +03:31 <@mids> be honest +03:32 <@nop> hmm +03:32 <@nop> can we shoot for an hour earlier +03:33 <@nop> I can get in trouble for chatting at work at that time in the day +03:33 <@mids> yup +03:33 <@mids> then we will try that +03:34 <@nop> ok +03:34 <@mids> okay... questions! +03:34 -!- mids changed the topic of #iip-dev to: Meeting info, agenda, livelog (in case you are late): http://mids.student.utwente.nl/~mids/iip/ | current topic: Questions +03:34 < Kronos-X> mids: Where are the .debs? +03:34 < Kronos-X> ;) +03:34 <@nop> teach us old wise one +03:34 <@nop> and we will make .debs +03:34 <@nop> :) +03:34 <@mids> Kronos-X: you would make them! +03:34 < Kronos-X> Heh. +03:35 < Kronos-X> Sorry, I'm just here to bump the noise-to-signal ratio., +03:35 < Kronos-X> Let me pass the mic on to someone with a real question. +03:35 <@nop> hehe +03:35 <@mids> ptsc: any Q about the protocol? +03:35 < Banks> ptsc has been idle 53mins 56secs :) +03:36 <@mids> okay, banks' PDF is online on http://mids.student.utwente.nl/~mids/iip/meeting2/ +03:36 <@nop> did we discuss roadmaps +03:36 <@nop> etdd +03:36 <@mids> it looks cool already +03:36 <@nop> etc +03:37 <@mids> nop: only that rc2 depends heavily on docs +03:38 <@nop> ok +03:39 <@nop> this pdf kicks ass +03:39 <@nop> just need the invisible irc logo in there +03:40 <@nop> and you're done eh:) +03:40 <@mids> I love the quotes and the screenshots +03:40 < Banks> Casper? +03:40 <@mids> even a FAQ! +03:40 <@mids> Banks: why didn't you tell us before? +03:40 < Banks> I spoke to codeshark but he didn't really say anything. +03:42 <@nop> no +03:42 <@nop> take the one off the site +03:42 <@nop> for now +03:42 < Banks> ok +03:43 <@mids> I am going to sleep +03:43 <@mids> logger will keep running for a while +03:43 <@mids> thanks everybody for listening +03:43 < Neo> l8r mids +03:43 <@mids> night +03:44 <@Chocolate> night +03:44 < Banks> night mids +03:44 < Kronos-X> Night, mids. +03:44 < Aster> nite +03:45 < ellison> l8r mids +03:46 < Banks> Is there a logo in the works? +03:48 <@nop> umm yeah +03:48 <@nop> also +03:48 <@nop> we want to have +03:48 <@nop> pwered by InvisibleNet +03:48 <@nop> and IIP now logo's +03:49 < Banks> That's a good idea. +03:49 <@nop> banks +03:49 < Banks> It's hard to think of a logo that conveys IRC invisibility :) +03:49 <@nop> excellent pdf +03:49 < Aster> how long till these logos exist +03:49 <@nop> we will definitely use it for distro with IIP +03:49 < Banks> Cheers +03:49 <@nop> well +03:49 <@nop> I have some drafts of powered by invisiblenet +03:49 <@nop> but you know +03:49 <@nop> the goal of IRC is one thing +03:49 <@nop> but in the future +03:49 <@nop> Invisible Internet +03:49 <@nop> so... +03:50 < Banks> True +03:50 <@nop> IRC Is main project +03:50 <@nop> but it's so modular +03:50 <@nop> that rumors might start +03:50 < Banks> Logos with heads or faces seem to do pretty well. Redhat, Napster, etc. +03:50 < Banks> Rumors? +03:51 < Aster> banks: but do we want to copy the other guys, or come up with something unique, while still remeberable +03:51 <@nop> it's a joke, basically it will be so modular anything can be put in as a protocol to anonymize +03:51 < Banks> nop: I see :) +03:52 < Banks> Aster: A head or face can still be unique. I think they're better than geometric patterns, etc. +03:52 < Aster> yeah +03:53 <@Chocolate> anyone with a camelion as a maskot? +03:54 <@nop> geiko +03:54 <@nop> insurance +03:54 <@nop> :) +03:54 <@Chocolate> damn +03:54 <@Chocolate> the fuckers +03:54 <@Chocolate> they're a terible companie +03:55 < Banks> GameSpy has taken the Invisible Man thing +03:55 <@nop> yes +03:55 <@nop> they don't even do good at getting cheap insurance +03:55 <@Chocolate> maby a klingon bird of prey? +03:55 < Banks> :) +03:55 <@Chocolate> cloaked you know ;) +03:56 < Banks> Maybe footprints that disappear across the text. +03:57 <@nop> hehe +03:57 <@nop> ok, meeting is officially over +03:57 <@nop> just to let you know +03:58 <@nop> it's free for all +03:58 <@nop> anyone have a good slogan for IIP +03:58 <@mids> IIP - it keeps you awake +03:58 <@nop> hehe +03:58 < Neo> IIP - "Fuck the State" +03:59 <@nop> umm +03:59 < Neo> oh... sorry... +03:59 <@nop> no +03:59 < Neo> :) lol +03:59 < Banks> I love that one Neo :) +03:59 < Banks> IIP - "Stuttering Urinators." +03:59 <@nop> hah +03:59 <@nop> haha +04:00 <@Chocolate> IIP - where animals talk +04:00 < Banks> Heh heh +04:01 < Banks> Maybe a Dog logo, you know, on the internet no one knows that you're a dog. +04:01 < Banks> An invisible dog! :) +04:01 < ellison> "and doubly-so with IIP" +04:02 < Banks> IIP - "Where AOLers can be free from prejudice" +04:03 <@nop> haha +04:05 <@Chocolate> IIP - Talk to yourself without people laughing at you +04:05 < Banks> Heh heh +04:10 -!- CwZ|away is now known as Somedude +04:11 <@Chocolate> hey Somedude +04:11 < Somedude> hey Chocolate +04:11 < Somedude> how goes? +04:11 <@Chocolate> I'm ok, you? +04:11 < Somedude> fine fine +04:12 < Banks> Heh heh +04:13 * Banks pm's Somedude, "We all hate Chocolate". +04:13 < Somedude> yea I do too +04:13 <@nop> hey guyes +04:14 <@nop> email me sites you like +04:14 <@nop> for examples of styles for IIP +04:14 < Banks> Hmmm. +04:14 <@nop> 0x90@invisiblenet.net +04:17 < Mole> Ok, heres the deal: I am a p2p researcher and has al ot of nice algorithms that I have invented and tested for distributed systems. +04:17 < Mole> I am currently looking for some project with which I should share my knowledge. +04:18 < Banks> You've come to the right place :) +04:18 < Banks> nop is your man. +04:18 < Mole> I just found iip some minutes ago. +04:18 < Mole> I guy in #freenet on openprojects.net recommend you. +04:18 < Mole> Well, heres what i got so far: +04:19 <@nop> k +04:19 < Mole> * All my algorithms are completely distributed and is not dependant on any central server. +04:20 < Mole> * An algorithm to keep together a network with anything from 2 to 20000000000 nodes. :)) +04:20 < Mole> * That network never gets netsplits and cant be crashed as far as I know. +04:20 <@nop> mole +04:20 <@nop> please email iip@invisiblenet.net +04:20 <@nop> with it +04:20 <@nop> along with your pubkey +04:21 < Mole> * Algorithm to announce subnets/services on the main network. (Aad subnets on the subnets.) +04:21 <@nop> can it remain anonymous +04:21 <@nop> and help not give too much info +04:21 < Mole> * Algorithms to collect statistics like number of nodes, average and median values et.c. +04:22 < Mole> * Algorithms to keep secret hwhat different nodes does on the network and what services they are suppliyng. +04:22 <@nop> why Mole for a nick +04:22 < Mole> And I am curently I am working to solve the distributed secure efficient database. :) +04:22 <@nop> kewl +04:22 < Mole> Well, Mole has been my Internet nick since 1991. +04:23 < Mole> I myself is not a very secret person. :) +04:23 < ellison> Mole: you familiar with quorum based distributed data systems? +04:23 < Mole> But I like to supply secresy to people. :) +04:23 <@nop> had a feeling those algo's are secret +04:23 <@nop> :) +04:23 < Mole> nope, not quorum. +04:23 <@nop> quorum or quantum +04:23 < ellison> lotsa cool work being done there +04:24 < ellison> quorum +04:24 < Mole> Kind of been into my research and simulations to much so I am currently taking a long break to check what other projects there are out there. +04:24 < ellison> it's basically a distributed databases structure where many entities can have read/write access, but the system is protected from attempts at corruption by any of those entities +04:24 < ellison> really useful for certain types of data structures/purposes +04:25 < ellison> http://citeseer.nj.nec.com/malkhi97byzantine.html +04:25 <@Chocolate> Mole: I recomened you here :) +04:25 <@Chocolate> got a spybot going in #freenet here +04:26 < Mole> Ok, Ill check quorum out to. +04:26 < Mole> Well, now I have lots of questions about IIP to see what good my algorithms and knowledge might do for you. :) +04:27 < Mole> First of all, is there any documentation of how IIP works anywhere? +04:28 <@nop> yes +04:28 <@nop> banks +04:28 <@nop> where's that link +04:28 < Banks> Wait one +04:28 < Banks> http://mids.student.utwente.nl/~mids/iip/meeting2/iipdoc.pdf +04:29 < Banks> Mole: You'll probably want to read mainly chapter 1 and chapter 9. +04:29 < Mole> Ok, downloading it. +04:32 <@nop> I have to run +04:32 <@nop> see ya guys later +04:33 < Banks> Seeya nop +04:33 < Mole> Hey you gues are really friendly. Lots of chats in all windows and private cahts too. +04:33 < Banks> :) +04:36 < Mole> I'll read all the stuff you all recommended and talk to you some other day when I know more. :) +04:37 < Banks> That'd be great :) +06:07 < Mole> Ahh, I just browsed through iipdoc.pdf and now I think I understand how IIP works. +06:08 < Mole> If I got it right there are allmost normal IRC-servers in the "backbone" ? +06:12 < Mole> And you are planning on making verions 2.0 fully decentralised. +06:12 < Mole> Have any design work or algorithm research been done on the decentrailsed structure for verison 2.0 ? +06:20 <@Chocolate> some +06:20 <@Chocolate> still r&d +06:21 < Mole> Ok, I think I can be of use to you then. :) +06:36 < Aster> k +06:37 < Mole> Ok, well here are my thoughts on anonymous DCC chat and file send: +06:38 < Mole> Add a socks-proxy to the "IIP-client". +06:38 < Mole> Tell the users to configure their IRC client to run through the IIP-socks-proxy. +06:39 < Mole> That means all the DCC connections will go to the IIP-socks-proxy. +06:40 < Mole> The when the IRC-client (like mIRC) wants to connect to mole.anon.iip the proxy sends that connection through some of the other +06:40 < Mole> nodes in the network until it finally reaches the node you want to DCC. +06:41 < Mole> Thus you got an anonoymous DCC! +06:41 < Mole> Waht do you think? +06:41 < Aster> dcc involves files right (im not a big irc kid) +06:42 < Mole> Yep. +06:43 < Mole> So it will create much network load for the nodes that the connection "bounces" through. +06:43 < Aster> yeah...the only problem i see is that now, when you start sending your file, its gotta go through all the other servers, causing lots of traffic +06:43 < Aster> yeah +06:44 < Mole> But since allmost all nodes should be assisting the distributed net that network load could be spread pretty equally. +06:44 < Mole> But it will of course be slower "downloads" than over unsafe DCC. +06:45 < Mole> Ahh, network split? +06:46 < Aster> sorry, i missed your last few messages +06:46 < Mole> Repating: But since allmost all nodes should be assisting the distributed net that network load could be spread pretty equally. +06:46 < Mole> Repeating: But it will of course be slower "downloads" than over unsafe DCC. +06:46 < Aster> yeah +06:47 < Mole> So it has to be discussed if it should be implented. +06:47 < Aster> not really though about the spread out network load...each node still has to relay, lets say, 10mB no matter how many other nodes are there +06:47 < Mole> But atleast it is very simple to implement if you decide to use it. +06:47 < Aster> yeah +06:48 < Mole> Not with my algorithms. :) Then each node only has to relay about 500 byte / second. +06:48 < Mole> Excpet for the DCC data ofcourse.... +06:49 < Mole> Lets go to my next simple algorithm: +06:49 < Mole> To create network efficient channel communications you do like this: +06:50 < Mole> Provided that each user has his own local IIP-node: +06:51 < Mole> That is, all the data we are creating while chatting only travles among the nodes taking part in the chat. +06:51 < Mole> Thus not loading the rest of the network. +06:51 < Mole> We have to ad one thing though for anonymity: +06:51 < Mole> The nodes actually taking part in the mini network for the channel +06:52 < Mole> is only front ends for the real chatters. +06:52 < Mole> That is each node connects to a front end (perhaps in two or more levels) and it is the front end that joins the channel-network. +06:53 < Mole> That save a lot of communication bandwidth! +06:53 < Mole> and also makes the network much more robust. +06:53 < Aster> hum +06:54 < Aster> interesting +06:55 < Aster> brb....i need to lay down for a bit..back hurting +06:55 < Mole> chatter node <-> intermediate <-> frontend <- channelnet - +06:55 < Mole> > frontend <-> intermediate <-> chatter node +06:56 < Mole> Any other of you guys have any comments? +07:18 -!- Zwollywood is now known as Zwolly +07:21 < Mole> Hi Zwolly +07:22 < Zwolly> hello +07:22 < Zwolly> one moment +07:23 < Mole> Are you working with IIP-development? +07:24 < Zwolly> no i am just an user +07:24 < Zwolly> i think i am to late for the meetibg +07:25 < Mole> Ahh, me to. +07:25 < Mole> Yep, the meeting was hours ago. +07:25 < Mole> I am thinking on joining the development team. +07:25 < Zwolly> http://mids.student.utwente.nl/~mids/iip there is some info there +07:25 < Zwolly> great +07:25 < Zwolly> if you got the skills and they can use some one +07:26 < Mole> Yep, I got the skills. Researched decentralised p2p systmes since 1997... +07:27 < Mole> Thanks for the reminder of the URL. +07:28 < Mole> I checked it again and there were more stuff there then I noticed when I took a first look some hours ago. +07:28 < Zwolly> only thing i know of making programs is how to make them crash hehe +07:28 < Mole> Well, sounds like you could bee a good beta-tester then? +07:29 < Zwolly> yeh maybe +07:29 < Zwolly> i am busy on an dutch translation of the manual so maybe i can help a little with that +07:29 < Mole> I find it funny that they have a command to add your website to your ncik. +07:30 < Mole> Just read about the extra commands IIP has. +07:30 < Zwolly> yeh that is a nice option +07:32 < Mole> Oops, I looked in the "livelog.txt" on the site IIP site. +07:34 < Mole> Whoops, got disconnected. +07:35 < Zwolly> yeh i see +07:35 < Zwolly> also an point on agenda +07:35 < Zwolly> more stable connections +07:36 < Mole> hehe, yep. +07:37 < Mole> It is possble to build networks that use multiple tcp-connections to make things very robust. +07:38 < Zwolly> yeh i am reading about that but need to see it first before i believe it +07:38 < nop> dang +07:38 < nop> meeting still going? +07:38 < Zwolly> now reading log file +07:38 < Zwolly> no +07:39 < Zwolly> just some people talking and reading what they have missed +07:39 * mids kicks everybody out +07:40 <@mids> MEETING IS OVER +--- Log closed Wed May 29 07:40:24 2002 diff --git a/i2p2www/meetings/logs/2.rst b/i2p2www/meetings/logs/2.rst new file mode 100644 index 00000000..bbe06ec6 --- /dev/null +++ b/i2p2www/meetings/logs/2.rst @@ -0,0 +1,9 @@ +I2P dev meeting, May 29, 2002 @ 00:00 UTC +========================================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/20.log b/i2p2www/meetings/logs/20.log new file mode 100644 index 00000000..4e1499fc --- /dev/null +++ b/i2p2www/meetings/logs/20.log @@ -0,0 +1,404 @@ +--- Log opened Tue Nov 19 23:51:34 2002 +23:52 < logger> test +23:52 -!- mode/#iip-dev [+o mids] by Trent +23:52 -!- mode/#iip-dev [+v logger] by mids +23:53 -!- mode/#iip-dev [+oo nop UserX] by mids +23:57 <@mids> public IIP meeting in channel #iip-dev starting in 2.5 minutes +23:57 < nemesis> lol +23:57 < zic> anybody from Ukrain? message me! hehehe +23:58 -!- mode/#iip-dev [+o hezekiah] by mids +23:58 <@hezekiah> Hello again, mids! +23:58 < Robert> Hey Nemesis, have you seen http://www.bash.org/?top +23:58 * athena sees hezekiah in a whole new light :p +23:58 < nemesis> bash? +23:58 <@mids> Robert: they are down +23:58 <@mids> what! +23:58 <@mids> they are back! +--- Day changed Wed Nov 20 2002 +00:00 <@mids> Tue Nov 19 23:00:00 UTC 2002 +00:00 <@nop> welcome +00:00 <@nop> welcome +00:00 <@nop> to the 20th? +00:00 <@nop> IIP meeting +00:00 <@hezekiah> 20th! +00:00 <@mids> yes +00:00 <@nop> yes on the agenda today... +00:01 <@nop> mids... +00:01 <@mids> 1) welcome +00:02 <@mids> 2) getting rc3 out +00:02 <@mids> 3) sneak preview on rc3 +00:02 <@mids> 4) snacks and drinks +00:02 <@mids> 5) questions +00:02 <@mids> . +00:02 <@nop> thnx +00:02 <@nop> ok +00:02 <@nop> so we are having rc3 officially released thursday +00:02 <@nop> please mark that in your calendars +00:02 <@mids> we hope :) +00:02 <@mids> (unless sourceforge is down again) +00:03 <@nop> right, did they fix the ro on nfs? +00:03 <@mids> yes +00:03 <@nop> was it their mistake? +00:03 < tarpY> i am here for the food +00:03 <@mids> it was announced on their status page btw +00:03 <@nop> ok +00:03 <@mids> maintenance +00:03 <@nop> gotcha +00:03 <@nop> probably doing backups +00:03 < tarpY> i wanted to order pizza off of the freenet and i found out they wont +00:03 <@nop> :) +00:03 < tarpY> where can i get food here +00:03 <@mids> tarpY: #muchnies-to-take-away +00:04 <@nop> ok +00:04 <@mids> what will be new in rc3: +00:04 <@nop> so Thursday we will get that out +00:04 <@nop> oh +00:04 <@nop> Mids, I believe you have the changelog handy +00:04 <@nop> if not +00:04 <@mids> me too +00:04 <@nop> I'll display +00:04 <@nop> ok +00:04 < sinster> will rc3 have a decent install script for *nix? +00:04 <@mids> - Display of version number for windows (menu option) and unix (command line). +00:04 <@mids> - Random number generation fix. +00:04 <@mids> - IIP network connections are no longer paused while in the setup screen. +00:04 <@mids> - Now exits if it can't bind to a socket at startup. +00:04 <@mids> Windows now displays a message box informing that it can't bind to port. +00:04 <@mids> - Several bugfixes and one memory leak fixed. +00:04 <@mids> . +00:04 <@mids> sinster: no, that is what hezekiah is working on +00:05 <@mids> that will be 1.2 +00:05 <@hezekiah> Not quite ... +00:05 <@nop> ok +00:05 < zic> are there plans for translating the (nice) faq @ help.invisiblenet.net ? +00:05 <@nop> anyone who wants to translate +00:05 <@nop> please do +00:05 < sinster> mids/hezekiah: will it add iip to /etc/rc.d/ so that it starts automatically? just a suggestion +00:05 <@nop> we would very much appreciate it +00:05 <@nop> and have it on the site +00:05 < zic> will rc3 demand any mod in the FAQ? +00:06 <@mids> sinster: I got a script here... but that needs more testing +00:06 <@mids> sinster: maybe we'll add that with 1.1 final +00:06 <@hezekiah> sinster: that would not be distribution compatible, since different distros put startup stuff in different places. +00:06 <@mids> zic: no +00:06 < sinster> mids: yeah, make sure you test it on the major linux flavors, redhat, debian etc +00:06 <@nop> well, can we wait on quesitons +00:06 <@nop> please +00:06 < zic> my isproxy is scripted in /etc/init.d (debian), works perfectly +00:06 <@mids> oops +00:06 <@nop> till the questions and answers +00:06 < zic> sorry! +00:06 < zic> sorry! +00:06 <@hezekiah> Sorry. +00:06 <@nop> it gets confusing +00:06 <@nop> ;) +00:06 <@nop> sorry +00:06 < sinster> nop: ok +00:06 < tarpY> no translating everyone should speak english. +00:07 < sinster> nop: my bad +00:07 <@nop> no prob +00:07 <@mids> any questions on the changelog? +00:07 <@mids> no? +00:07 <@mids> nop: sneak preview? +00:07 <@nop> hold my relay just bit the dust +00:08 <@nop> wait till everyone comes back +00:08 <@mids> auch +00:08 <@nop> delay can be annoying in a meeting +00:08 <@nop> ;) +00:08 <@nop> everyone still here? +00:08 <@mids> seems like it +00:09 <@hezekiah> I didn't see anyone leave. +00:09 <@nop> ok +00:09 < zic> i am (does i matter? hehe) +00:09 <@nop> well there is a delay feature we have +00:09 <@nop> ;) +00:09 <@nop> ok +00:09 < al-jabr> I didn't either. +00:09 <@nop> guess my relay got kicked off the list for unreliability +00:09 <@nop> haha +00:09 <@mids> hehe +00:09 * Robert joins #muchnies-to-take-away while he waits... +00:09 <@mids> there we go +00:09 <@nop> yep +00:10 <@nop> there's another +00:10 <@nop> ;) +00:10 < al-jabr> there goes five. +00:10 <@hezekiah> We really need to do something about that. :( +00:10 < nemesis> erm +00:10 < nemesis> mids +00:10 <@nop> hezekiah: spread spectrum routing +00:11 < tc> is this glitches in the relay system? +00:11 <@nop> ;) +00:11 <@nop> my windows relay box crashed +00:11 <@nop> typical +00:11 < nemesis> for win2k / xp, thers in the future a build without gui +00:11 <@hezekiah> lol +00:11 < nemesis> or only gui to setup +00:11 < nemesis> and the rest as an daemon? +00:11 <@nop> it would be nice to have it as a service +00:11 <@nop> ;) +00:12 < nemesis> yes +00:12 < nemesis> ;) +00:12 <@nop> there is a program out there called service installer +00:13 <@nop> ok +00:13 <@nop> well +00:13 < nemesis> iip.exe --install +00:13 <@nop> no more delays +00:13 < nemesis> like apache for win +00:13 <@mids> is everybody already back? +00:14 <@nop> ok +00:15 <@nop> welcome baci +00:15 <@nop> back +00:15 < nemesis> matrix's neo? ;) +00:15 <@nop> ok +00:15 <@nop> I think they are back +00:16 <@mids> yes +00:16 <@nop> ok +00:16 <@nop> sneak preview +00:16 <@mids> I made a FLT-iip.1.1-rc3-pre1-mids-sneak-preview-screaner.tgz +00:16 <@mids> everybody with unix can test it +00:16 <@mids> no windows version yet +00:16 <@nop> I can make one right now +00:16 <@nop> if you want +00:16 < zic> lol +00:16 <@mids> http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz +00:16 < nemesis> thats ok +00:16 < nemesis> i wait +00:16 < zic> OGG or LAME audio? +00:17 <@mids> I am especially looking forward to reports on obscure unix versions +00:17 <@mids> like netbsd etc +00:17 < nemesis> i think, its not so important when a unix machine crash with 30 days uptime +00:17 <@mids> and macosx +00:17 < nemesis> as an windows machine with 3 days uptime ;) +00:17 < tc> mids: is this change just in the isproxy or in any other relay stuff also? +00:17 <@nop> no +00:17 <@nop> you keep your settings +00:17 <@nop> did we test that it can install over the previous one +00:17 <@nop> hmm +00:18 <@nop> make a note +00:18 < zic> nemesis: but it would be cool if it never crashed. but let's kill the talking here. we are in a formal meeting +00:18 < nemesis> hehe +00:18 <@nop> ok +00:18 <@nop> if anyone wants to test if the upgrade process is trivial +00:18 < nemesis> don't test it on meeting days ;) +00:18 <@nop> then please go ahead +00:18 <@nop> and email or notify one of the devs of the results +00:18 <@mids> please test it next to your current relay +00:18 <@mids> and yes, please give feedback +00:19 <@mids> on what went wrong +00:19 <@mids> etc +00:19 <@nop> wb tarpY +00:19 <@nop> let's put that screener in the topic +00:19 < goc> is it possible to run isproxy-rc2 and isproxy-almost-rc3 simultaneously? +00:19 <@nop> yes +00:20 <@nop> different port settings +00:20 <@nop> and it's not hard at all +00:20 < goc> where's the conf file stored? +00:20 <@nop> but rc3 should be able to go over rc2 +00:20 <@nop> you might have to do a -f /dir +00:20 <@nop> or you may have it go over the rc2 install +00:21 < tarpY> are you going to eventually remove the proxy and integrate it into a client? +00:21 <@nop> probably not +00:21 <@nop> the idea is transparent applications +00:21 <@nop> it's a transport medium +00:21 <@nop> and we'll remove the server +00:21 <@nop> and integrate it into the proxy yes +00:22 <@nop> mids, can we have your link on the topic +00:22 <@nop> for the preview +00:22 -!- mids changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback +00:23 <@nop> ok +00:23 < zic> compiling +00:23 <@nop> so that's the rc3 unix preview +00:23 <@nop> next on agenda +00:23 <@nop> I think it's food and drinks +00:23 <@mids> snacks and drinks +00:23 < zic> i want pizza +00:24 * mids gives a Quattro-Strationi to zic +00:24 < zic> it's stinking :-/ +00:24 < zic> what did you put on that? +00:24 <@mids> ok +00:24 <@mids> questions? +00:24 < zic> i have +00:24 < tc> zic: dead fish +00:24 < zic> tc ehhe +00:25 < tc> does this just change the proxy? +00:25 < zic> i propose a translation project... +00:25 <@nop> also +00:25 <@nop> we need a doc writer +00:25 <@nop> for technical documentation +00:25 <@nop> updates +00:25 <@mids> volunteers? +00:26 < zic> i would be, but my english is bad hehe +00:26 < zic> i prefer translating things +00:26 <@nop> translation: any volunteer +00:26 * zic ! +00:26 <@nop> what languages? +00:26 * zic -=> portuguese only +00:27 <@nop> ok +00:27 <@nop> any other volunteers for specific languages +00:27 < Fairwitness> English :) +00:27 < nemesis> english and german ;) +00:28 <@nop> English, is done, unfortunately it's the primary language +00:28 <@nop> FW are you planning to assist with tech docs then +00:28 <@nop> ? +00:28 < Fairwitness> sure, if you want help. I like to write... +00:28 < zic> i would like to help with something else, but i dont know what i need, and i am a mediocre coder +00:28 < zic> s/i/you +00:29 < Fairwitness> ...and I can't code for shit... +00:29 <@nop> zic translation is great +00:29 < zic> i can make debian packages +00:29 <@nop> that's definitely a plus +00:29 < zic> but this is not good for RC +00:29 <@nop> correct +00:29 < zic> but i can test it +00:29 <@nop> but debian wants to include IIP as a package when stable +00:30 < zic> is there anybody doing this? +00:30 <@mids> I got to sleep now +00:30 <@mids> ... +00:30 <@mids> bye all +00:30 <@nop> ok +00:30 <@hezekiah> Bye! +00:30 < Fairwitness> bye mids +00:30 < zic> bye mids +00:30 <@nop> ok so FW +00:30 <@nop> can you assist with docs +00:30 < tc> bye +00:30 < Neo> nightz +00:30 < Fairwitness> sure, what do you need done? +00:30 <@nop> I have to upgrade the docs on encryption +00:30 <@nop> and we're going to need docs for 1.2 +00:31 <@nop> soon +00:31 <@nop> and full regular docs for 1.1 stable that have been reviewed +00:31 <@nop> and are considered good for general audience +00:31 < Fairwitness> define "general". +00:31 < nemesis> ;) +00:32 <@nop> well, when stable is released +00:32 <@nop> we'd like a good docs to accompany +00:32 < nemesis> that i understand this ;) +00:32 < Fairwitness> general public or general crypto techno fetish geek +00:32 < Fairwitness> :) +00:32 <@nop> a little in between +00:32 < nemesis> hrhr +00:32 < nemesis> make some nice pictures +00:32 <@nop> enough to be in the middle and answers questions for all users +00:32 < nemesis> and say this is the securest irc network +00:32 < nemesis> like m$ +00:32 < nemesis> this winxp is the stablest windows +00:33 < nemesis> ;) +00:33 < zic> "anoymousest" +00:33 <@nop> haha +00:33 < Fairwitness> Well if you give me the docs you have I can go through them and review and edit them for a general release. +00:33 < zic> what about wiki documentation? +00:33 <@nop> do you know how to make .chm file in windows +00:34 < Fairwitness> In my RL I have got quite good an writing software docs that are understandable by "generl" folks as well as non english speakers. +00:34 < nemesis> xml to chm? +00:34 < nemesis> ;) +00:34 < nemesis> or latex to chm +00:34 <@nop> .chm is like the help doc in win32 +00:35 <@nop> we can discuss that later +00:35 <@nop> ok +00:35 <@nop> http://www.invisiblenet.net/iip/docsMain.php +00:35 < nemesis> i know.. k later.. +00:36 <@nop> ok +00:36 <@nop> any other questions? +00:36 < zic> what is the future of mankind? +00:37 < Fairwitness> are there any caffinated beverages here? +00:37 < Fairwitness> if not, why not! +00:37 <@nop> haha +00:37 < tc> zic: wonderous .. if we can survive assholes +00:37 < Fairwitness> I demand intra venus V as my price for editing docs !! +00:37 < Fairwitness> :) +00:38 < Fairwitness> Hi Neo +00:38 <@nop> ok +00:38 <@nop> meeting officially ended +00:38 < Fairwitness> but, my V!! +00:38 < zic> hahaha +00:39 * Fairwitness slumps in the chair. +00:40 -!- mode/#iip-dev [+o Chocolate] by Trent +00:40 -!- mode/#iip-dev [+n] by Chocolate +00:40 <@Chocolate> damn I alwasy miss them :( +00:40 < nemesis> hrhr +00:40 < nemesis> Chocolate: ;) +00:44 < zic> nictuku:/home/yves/freenet# [2002/11/19-23:41:02]:Socket(5), Error (98):Failed to bind listening socket. +00:44 < zic> [2002/11/19-23:41:02]:sockListen: bind failed: host(127.0.0.1), port(6667)Failed to bind listening socket. +00:45 < zic> it should say it exited +00:45 <@hezekiah> If you do a "ps -e | grep isproxy" you shouldn't see it on the list. +00:45 < zic> i know +00:45 <@hezekiah> However, that is a good idea. +00:45 < zic> but it should printf that +00:47 < sanity> are you talking about how to kill isproxy? +00:47 <@hezekiah> No. What isproxy should do when it doesn't load. +00:52 < zic> is iip already meant to be popular? +00:52 < nemesis> i don't know +00:52 < nemesis> it's like +00:53 < nemesis> cryptomail +00:53 < zic> i bet it isnt in freshmeat and tucows, for example.. is it? it could +00:53 < nemesis> when there are no way to share files with more than under 1kbyte/sec then i don't have a good look at the future +00:54 < zic> but iip is not about sharing files.. +00:55 < nemesis> thats true +00:55 < nemesis> but what can i do with an chating plattform +00:55 < nemesis> when i can't send the other people the newest own mp3 mix? +00:56 < zic> chat! +00:56 < nemesis> theres to many options what you can do with files +00:56 < nemesis> when it's only a chatlog +00:56 < zic> i bet in OPN ppl dont care about sending things +00:56 <@Chocolate> zic: iip is on freshmeat I beleave +00:56 < nemesis> what you will send the other one +00:56 < nemesis> or a new perlscript for xchat +00:56 < nemesis> and so on +00:57 < nemesis> desktop pics +00:57 <@Chocolate> nemesis: use fileserv.pl, it's under the GPL so you can make any modifications you want +00:57 < zic> i think he knows that chocolate +00:57 < nemesis> erm +00:57 <@Chocolate> zic: well I forgot to include the licence header in the file so :) +00:57 < nemesis> test it on windows with xchat and active perl please +00:58 < nemesis> and say me how i can use it +00:58 < nemesis> or make a faq +00:58 < zic> Chocolate: oh yes, you made it. thank you, btw +00:58 < nemesis> ;) +00:59 < zic> Chocolate: is it possible to make a perl-version compatible MIRC script ? +00:59 < nemesis> ;) +01:00 < nemesis> where need a shareware? +01:00 < nemesis> xchat under win is more stable and open than mirc +01:00 < nemesis> i only miss the drag and drop option bye filesend +01:00 < zic> but mirc is far more popular +01:00 < nemesis> and? +01:01 < zic> and many IIP users use mirc +01:01 < nemesis> i had mirc 6.00 for 1 to 2 month +01:01 < nemesis> it crashes always after some hours +01:01 < zic> i used mirc all my life +01:01 < zic> i like mirc a lot +01:01 < nemesis> and it takes 3 month or so for the next version +01:01 < nemesis> then +01:01 < nemesis> the multiserv +01:01 < nemesis> in the performlist +01:01 < nemesis> it deleted and reorganized the list +01:02 < nemesis> in xchat i can use the (very slow) transparent windowbackground +01:02 < nemesis> have good ssl support for other irc networks that support this +01:02 < zic> nemesis: ok, but ppl use it, so fileserver.pl must have a compatible clone for mirc... +01:03 < nemesis> for every server a own perform list and so on +01:03 < nemesis> mirc +01:03 < nemesis> thats an programing language the mirc script? +01:04 < zic> hmm it's mirc's own scripting language +01:04 < zic> which is btw very known, my first interpreted language was mirc's +01:05 < nemesis> lol +01:05 < nemesis> *sorry* +01:05 < nemesis> make a good if then constallation +01:05 < nemesis> i stopped it +01:06 < nemesis> cause i can't finde the way to make it possible in mirc +01:06 < zic> why not? +01:07 < zic> well, nevermind +01:07 < nemesis> it's to hard to explain it in english sorry guy +01:08 < zic> ok, dont worry, sorry for pushing +01:08 < zic> what i meant is just that fileserver.pl needs compatibility.. hehe +01:08 < nemesis> kk +01:09 < nemesis> find a way in your mirc scripting language ;) +01:09 < zic> :-/ +01:09 < zic> i dont even use windows anymore +01:09 < nemesis> i only liked the easy way to make windows with mirc +01:29 < sanity> . +01:29 < zic> ' +01:31 < zic> going to opn, see you +02:44 < dd0c> is this rc3 preview useable? +02:44 < dd0c> heh dumb question +--- Log closed Wed Nov 20 10:43:44 2002 diff --git a/i2p2www/meetings/logs/20.rst b/i2p2www/meetings/logs/20.rst new file mode 100644 index 00000000..ace22050 --- /dev/null +++ b/i2p2www/meetings/logs/20.rst @@ -0,0 +1,9 @@ +I2P dev meeting, November 19, 2002 @ 23:00 UTC +============================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/200.log b/i2p2www/meetings/logs/200.log new file mode 100644 index 00000000..d93e59e7 --- /dev/null +++ b/i2p2www/meetings/logs/200.log @@ -0,0 +1,73 @@ +15:04 < jrandom> 0) hi +15:04 < jrandom> 1) Net status and 0.6.1.27 +15:04 < jrandom> 2) Syndie dev status +15:04 < jrandom> 3) trac.i2p.net +15:04 < jrandom> 4) ??? +15:04 < jrandom> 0) hi +15:04 * jrandom waves +15:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001334.html +15:05 < jrandom> lets jump on in to 1) Net status and 0.6.1.27 +15:06 < jrandom> zzz: wanna give us the rundown of the main bugfixes/improvements we'll find in i2psnark? +15:07 <+zzz> um, it's all over the map, see history.txt :) +15:07 < green> We can't say anything about that since you don't have work on it for a long time, humm ! +15:08 < green> So there isn't new to discuss +15:08 < jrandom> heh ok zzz, fair 'nuff :) +15:08 <+zzz> should be more robust for torrents with large number of seeders, some UI improvements, some bug fixes, support for multi-file torrent creation, etc etc +15:08 <+zzz> BTW w00t mtg 200 +15:09 < jrandom> zounds +15:09 < jrandom> ok word +15:09 < jrandom> my plans right now are just to add in the simple whispering for the floodfill peers (so people don't lose track of them as easily) +15:09 < jrandom> are there any other low hanging fruit i should address before tagging & pushing? +15:10 <+zzz> that sounds smarter than waiting for me to do it +15:10 < jrandom> oh, i should disable the old syndie too +15:11 < jrandom> (or at least its fetching) +15:11 < jrandom> i've heard some suggestions to disable theepsite tunnel by default as well - any thoughts? yea nea? +15:11 * bar beats his not-yet-quite-dead "not have eepsite server tunnels autostart by default" horse +15:12 <+zzz> I checked in a note on localhost/syndie/ warning people it's obsolete if you want to let it go one more release, up to you +15:13 < jrandom> it might be worth keeping the content around for a while but killing the syndication +15:13 < jrandom> ok, if anyone comes up with omething else, lemmie know +15:14 <+zzz> if you do check to see if the note I added needs updating +15:14 < jadeSerpent> i agree it shouldn't start serving pages out of box, no other app does that, potential security risk +15:14 < green> Disabling default eepsite is a good idea as most people using I2P don't use it and others use user defined tunnels, you have just to look at orion stat with only ~30 sites online +15:14 < jrandom> aye +15:14 <+zzz> and ditto if you disable eepsite tunnel the instructions & default eepsite homepage need to be updated +15:15 < jrandom> it won't disable already configured tunnels, it'll just affect new users +15:15 < jrandom> true zzz +15:15 <+zzz> prob. a good idea +15:17 < green> but this is just a minor tweak not a improvemnt +15:17 < jrandom> ok, anyone have anything else for 1) net status and 0.6.1.27? +15:17 <+zzz> resources/eepsite_index.html "your eepsite is up and running but..." +15:17 < jrandom> aye +15:19 < green> jr : Courage, let us flee! +15:19 < jrandom> ok jumping to 2) Syndie dev status +15:20 < jrandom> lots going on here, of course +15:20 < jrandom> beyond whats mentioned in the notes, once we get i2p 0.6.1.27 out i'm going to clear a bunch of the open bugs for next week's 1.004a release +15:21 <+fox> * thecrypto waves as he returns after a very very long hiatus from this project +15:21 < jrandom> anyone want to bring up anything for 2) Syndie dev status? +15:21 < jrandom> woah! +15:21 < jrandom> wb thecrypto +15:22 <+fox> <thecrypto> Thank you +15:22 < jrandom> still hacking on an i2p 0.1 sdk? :) +15:22 <+zzz> back for the 200th anniversary? +15:23 <+fox> <thecrypto> I guess so :) But I'm hoping to get back up to speed on this stuff as I've been looking around at what else is out there and it all sucks :) +15:24 < jrandom> heh cool +15:24 <+fox> * thecrypto takes a seat off to the side to let the rest of the meeting proceed +15:25 < jrandom> ok, if there's nothing else for 2) Syndie dev status, lets jump to 3) trac.i2p.net +15:25 < jrandom> by popular (and reasonable) demand, we've migrated from the in-syndie bugtracker to a real bugtracker +15:26 < jrandom> please use it if you can to file bug reports (though bug reports filed with syndie will be automatically imported into it after a delay) +15:26 * jadeSerpent claps +15:27 <+fox> <thecrypto> Trac works very well, use it at my day job. Have you integrated CVS into it? +15:27 < jrandom> monotone (our dvcs), yes +15:27 < jrandom> https://trac.i2p.net/browser +15:28 <+fox> <thecrypto> Neat, migrated to DVCS :) Good time for me to rejoin :) +15:28 < jrandom> mos' def' +15:29 < jrandom> at the moment, the wiki is basically disabled, but might get some use at times for working through some issues +15:29 < jrandom> i'm not sure if/when it'll get used though, but we'll see +15:30 < jrandom> ok, anyone have anything else for 3) trac.i2p.net ? +15:31 < jrandom> if not, lets jump to good ol' fashioned 4) ??? +15:31 < jrandom> anyone have something else to bring up for the meeting? +15:33 <+fox> <thecrypto> Glad to be bck +15:33 < jadeSerpent> does it always get really laggy around meeting time? +15:35 < jrandom> jadeSerpent: more than usual, yeah, though not that bad (i'm @ 1.46s lag) +15:35 * jrandom winds up +15:35 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/200.rst b/i2p2www/meetings/logs/200.rst new file mode 100644 index 00000000..399ccd9d --- /dev/null +++ b/i2p2www/meetings/logs/200.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 13, 2007 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/201.log b/i2p2www/meetings/logs/201.log new file mode 100644 index 00000000..9779d857 --- /dev/null +++ b/i2p2www/meetings/logs/201.log @@ -0,0 +1,34 @@ +14:59 < jrandom> 0) hi +14:59 < jrandom> 1) Net status +14:59 < jrandom> 2) Syndie dev status +15:00 <+void> jrandom: fyi, bookmark management is not working as of 8e18877de3908c52daae6d8a85fc8c671cdfb5d5 +15:00 < jrandom> 3) ??? +15:00 < jrandom> 0) hi +15:00 * jrandom waves +15:00 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001336.html +15:01 < jrandom> void: drag and drop onto the bookmarks currently doesn't refresh the display (the bookmarks are added but not shown) - working on that in the other dwindow atm :) +15:01 <+void> ah :) +15:01 < jrandom> if thats not what you're referring to, please file a bug report +15:01 <+void> (well, i already filed a bug report for that +15:01 <+void> ) +15:02 < jrandom> w3wt +15:02 < jrandom> ok, lets jump into 1) Net status +15:02 < jrandom> i don't really have much to add beyond whats in the status notes +15:04 < jrandom> anyone have anything they'd like to add re: 1) Net status? +15:06 < jrandom> if not, lets shimmy on over to 2) Syndie dev status +15:06 < bar> jrandom: yeap, Traditional Chinese language support fixed the "china.i2p" issue and Simplified Chinese fixed your "peace" post +15:06 < jrandom> ah great bar +15:06 < bar> (oops, sry!) +15:08 < jrandom> in theory we could bundle actual fonts and distribute them with syndie (which might make sense in some situations, like the preinstalled CDs/images that anonymous recently discussed) +15:10 < jrandom> (specifically, in the bug report @ urn:syndie:channel:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=9:messageIdi1171666081846ee ) +15:10 < jrandom> anyway, regarding syndie dev status, lots going on there +15:10 < jrandom> i expect we'll have a new release out later this week with the latest goodies +15:12 < jrandom> as always, keep those bug reports and feature requests flowin, and we'll get 'em addressed as soon as possible +15:12 < jrandom> anyone have anything to add re: 2) Syndie dev status? +15:15 < jrandom> ok if not, lets slide to 3) ??? +15:15 < jrandom> anyone have anything else to bring up for the meeting? +15:16 <+Complication> not anything I'd recall in a hurry :) +15:18 <+Complication> (not yet, at least) +15:18 < jrandom> heh in that case... +15:18 * jrandom winds up +15:18 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/201.rst b/i2p2www/meetings/logs/201.rst new file mode 100644 index 00000000..c8f4e4d1 --- /dev/null +++ b/i2p2www/meetings/logs/201.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 20, 2007 +================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/202.log b/i2p2www/meetings/logs/202.log new file mode 100644 index 00000000..05517f10 --- /dev/null +++ b/i2p2www/meetings/logs/202.log @@ -0,0 +1,81 @@ +16:01 < jrandom> 0) hi +16:01 < jrandom> 1) Net status and 0.6.1.28 +16:01 < jrandom> 2) Syndie dev status and 1.005a +16:02 < jrandom> 3) Syndie GUI directions +16:02 < jrandom> 4) Feb bug harvesting contest results +16:02 < jrandom> 5) ??? +16:02 < jrandom> 0) hi +16:02 * jrandom waves +16:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001338.html +16:02 < jrandom> y'all've had a few hours to read those (and of course to read the related syndie posts ;) so lets just jump in to 1) net status and 0.6.1.28 +16:04 < jrandom> there's been a bunch going on in this front lately - zzz wanna gives us a rundown of whats coming in 0.6.1.28? +16:05 <+zzz> ok +16:06 <+zzz> lots of improvements in tunnel building and upstream performance, mainly benefitting those who have a lot of outbound traffic or are upstream-bandwidth-constrained... +16:06 <+zzz> like i2psnark users... +16:06 <+zzz> I'm getting good results in testing so looking forward to getting it out there to all... +16:07 < jrandom> [w3wt] +16:07 <+zzz> I have one tweak to make a parameter configurable, as requested by Amiga4000, should get that in soon. +16:08 <+zzz> And thx for the $$ offer, however please keep it in the bank. +16:08 <+zzz> EOT :) +16:08 < jrandom> r0x0r - added to halloffame.html :) +16:09 <+zzz> haha I'm famous now +16:10 < jrandom> the changes look pretty promising, and they do seem that they'll have their largest impact once its widely deployed +16:11 < jrandom> just bounce me a msg when you want me to pull the trigger and i'll get it packaged and pushed w/in a day or so +16:11 < jrandom> ok, anyone have anything they'd like to bring up re: net status? +16:13 < jrandom> if not, lets hop on over to 2) syndie dev status +16:14 < jrandom> lots going on here (as you can see if you're using syndie or following https://trac.i2p.net/timeline ) +16:14 < jrandom> i expect we'll have a new 1.005a release in the next day or two (obviously not including the things we're discussing in (3) below) +16:15 < TrevorReznik> jrandom: do you have time for a short query? +16:17 < jrandom> if its for the meeting, certainly (if its on 2), now is good, if it doesnt fit the agenda, we've got 5) ??? for everything else :) +16:17 < jrandom> (if its not something for the meeting, hit me as a priv msg) +16:17 < TrevorReznik> ok ;) ill wait +16:18 < jrandom> ok, anyone have anything for 2) syndie dev status? +16:20 < jrandom> if not, lets switch to 3) Syndie GUI directions +16:20 < jrandom> as mentioned in the mail, lots going on in this direction - mk has put together some really interesting ideas and we'll likely see it in syndie sooner rather than later +16:20 <+zzz> call me a traditionalist, but I think the current multipane thunderbird-like i/f is pretty good +16:24 < jrandom> hmm, with the multipane view, would that fit more with mk's mods than our current multitab interface though? +16:24 < jrandom> do you use the preview tab on the thread view now, for instance? +16:26 <+zzz> right now there's no choice but to go to the preview tab to see attachments, which I don't like - would rather just see the whole thing in the lower pane +16:26 <+zzz> sorry not conversant in the details of mk's mods so can't answer your other question +16:27 < jrandom> ah, so it would work better w/ mk's view (once we get it using the MessageView instead of MessagePreview down there) +16:27 < jrandom> oh, there's a screencap of mk's proposal up at http://dev.i2p.net/~jrandom/mk_max.png +16:27 < jrandom> mk: perhaps we could find a way to make the tree above vs. left configurable? +16:29 <+zzz> thunderbird used to give you a choice of 2 or 3 layouts for the 3 panes, but can't find it in the options atm +16:30 < jrandom> i remember reviewing their diagram for that, yeah +16:31 < jrandom> perhaps if we can find a way to get mk's "explorer" parentable cleanly in an arbitrary SWT Composite we could use it both via the current tabbed GUI as a tab and in the fullscreen mode as a screen +16:33 <+zzz> I like the tabs for the less-common stuff like options, syndication configuration, etc; I think that tabs combined with the multipane for the common stuff is good. imho anyway. +16:34 < jrandom> do you run syndie fullscreen or only in part of the screen +16:35 <+zzz> usually full +16:35 < jrandom> hmm cool +16:36 <+zzz> but because I'm using a 1024x768 laptop these days... on my 1600x1200 desktop I wouldn't take up the whole screen +16:37 < jrandom> ok, for all y-all watching in the background, please post up your thoughts and ideas whenever its convient for you +16:37 < jrandom> heh aye, makes sense +16:38 * jrandom is on an 800x600 net cafe box atm +16:38 <@detonate> hmm, i'm having trouble getting i2p working again +16:39 <@detonate> it's doing something, using lots of cpu, but the web console doesn't seem to ever start +16:39 <@detonate> i guess i could try running it in windows +16:39 < jrandom> anything in the logs? +16:39 <@detonate> not really, it just says that i need to reseed +16:39 <@detonate> are the logs quieter than before? +16:39 <+zzz> wrapper.log NPE's? +16:41 < jrandom> ok, if there isn't anything else for 3, lets jump on to 4) Feb bug harvesting contest results +16:42 < jrandom> congrats & thanks to void, Darn, and Anonymous! +16:42 < jrandom> (and to everyone else who has helped out, of course) +16:42 < jrandom> bug reports help us track down these issues and make sure they get taken care of, so please keep 'em coming +16:43 < jrandom> ok, if there isn't anything on 4), lets jump to 5) ??? +16:43 < jrandom> anyone have anything they want to bring up for the meeting? +16:45 < bar> there was someone asking in the forums why the graphs displaying bw seem a bit off +16:45 < bar> thought you might have an idea or two +16:46 < bar> (basically, they peak at 1.5 x max bw setting) +16:47 < jrandom> aye, wasn't sure *which* bw graphs they were referring to (each of the graphs accurrately render the stat which they represent, from what i've seen) +16:47 <@detonate> nm, it's working again :) +16:48 <+zzz> it's the first 3 graphs on graphs.jsp, which seem much higher than the bw displayed on the left side of the router console, and for me are much higher than my configured upstream limit +16:49 * jrandom loads +16:51 < jrandom> hmm, and that includes the upstream avg w/ burst in mind? +16:52 <+zzz> yes +16:52 < jrandom> hmm, ill look into it +16:53 <+zzz> I'll investigate further, guess it doesn't ring a bell for you +16:53 < jrandom> ok, anyone have anything else for the meeting? +16:57 < jrandom> if not... +16:57 * jrandom winds up +16:58 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/202.rst b/i2p2www/meetings/logs/202.rst new file mode 100644 index 00000000..361de44a --- /dev/null +++ b/i2p2www/meetings/logs/202.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 13, 2007 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/203.log b/i2p2www/meetings/logs/203.log new file mode 100644 index 00000000..39ead4a4 --- /dev/null +++ b/i2p2www/meetings/logs/203.log @@ -0,0 +1,105 @@ +16:05 < jrandom> 0) hi +16:05 < jrandom> 1) Net status and 0.6.1.28 +16:05 < jrandom> 2) Syndie dev status +16:05 < jrandom> 3) ??? +16:05 < jrandom> 0) hi +16:05 * jrandom waves +16:05 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001341.html +16:05 * jrandom only recently posted that, so i'll give y'all a minute to read that exiting note ;) +16:08 < jrandom> ok, lets jump on into 1) net status and 0.6.1.28 +16:09 < jrandom> things are looking pretty good so far with about half of the net upgraded +16:09 < jrandom> an interesting data point is that the net has grown a bit too, added perhaps another 40-50 active ntcp connections to my router and i see around 700 known router idents +16:10 < jrandom> we'll see how that progresses over the next week or so though +16:11 < jrandom> ok, anyone have anything to bring up re: net status or 0.6.1.28? +16:13 < jrandom> ok, if not, lets swing on over to 2) syndie dev status +16:13 < jrandom> lots going on in that front, as mentioned in the notes +16:13 < Amiga4000> hi +16:13 < jrandom> heya Amiga4000 +16:13 < Amiga4000> which point now? +16:13 < jrandom> we just hopped over to 2, but if you have something to bring up for 1, hit me ;? +16:14 < Amiga4000> yeah, posted in syndie right now, I assume my pool isn't working as aspected +16:14 < jrandom> pool? +16:14 < Amiga4000> 2 pout tunnels 2 hops, one 70sec and 1300kb, one 250sec and 1000 kb +16:15 < Amiga4000> ( I refer to the msg in zzz forum on syndie about I2Psnark and pooling inside router) +16:15 < jrandom> i assume those times are expiration times, right, and data is total transferred so far +16:15 < Amiga4000> damned, right +16:15 < jrandom> ok, i replied to that post in syndie - what you see is good +16:15 < Amiga4000> *fine* +16:16 < Amiga4000> sry, wqas to fast in read and not understanding +16:16 < jrandom> if all tunnels expired at the same time, there'd be a rush and a good chance of total failures +16:16 < Amiga4000> correct, any chance to see the lifteime of a tunnel? +16:16 < jrandom> 1300KB and 1000KB is pretty good balancing too +16:16 < jrandom> lifetime is always 10 minutes +16:17 < Amiga4000> ok, I track some more data :_) +16:18 < jrandom> w3wt, thanks for asking about it though, its a good question +16:18 < Amiga4000> ok, and net status: 0.1.28 is fine, although upload of i2psnakr data is slow +16:19 < jrandom> hmm, you were describing 10-15KBps though, right? +16:19 < Amiga4000> right, it was 30-40 before the last 2 or 3 changes by zzz +16:20 < jrandom> hmm, lets see how it progresses as the new-release churn reduces +16:20 < Amiga4000> yes, lets wait 1-2 weeks more :-) +16:20 < jrandom> though in my view, 10-15KBps is good enough +16:21 < Amiga4000> :-) +16:21 < jrandom> (i was actually using the 10-20 range as my target for reasonable usage, rather than 1-5KBps) +16:21 < jrandom> of course, more is better, but a solid 10-15 is great news +16:21 < Amiga4000> I just know it has done the 2-4x of that +16:21 < _bob> Hmm, i2p is using 120% CPU. ;) +16:22 < Amiga4000> and I still can grab data from "internet" via the outproxy< in 20-40 kb rate +16:22 < jadeSerpent> _bob: hope your heatsink/fan is working +16:22 < jrandom> you're referring to kilobytes per second, right Amiga4000? +16:22 < Amiga4000> right +16:23 < jrandom> cool +16:23 < Amiga4000> and even syndie.i2p is in the 40 range +16:23 < jrandom> bob: or you've got a dual or quad proc pc ;) +16:24 < _bob> Didn't know top reported values over 100%. +16:24 < jrandom> i2p is just magic +16:24 < jadeSerpent> i guess it's over the top +16:25 < _bob> Wish I did. Can only route around 150KB/s in each direction as it is now. +16:25 * jadeSerpent dodges rotten fruit +16:27 < jadeSerpent> i have a core 2 duo and i sometimes see various processes using >100% +16:29 < jrandom> ok, anyone have anything else for 1? +16:30 < jrandom> if not, really moving on to 2 ;) +16:30 < jrandom> not much more to add to that here beyond whats in the mail and the forum +16:30 < jrandom> anyone have anything they want to bring up re: 2) syndie dev status? +16:30 < jadeSerpent> i can't wait to try the new editor widget +16:30 < jadeSerpent> the current one is driving me nuts +16:30 < jrandom> heh +16:31 < jadeSerpent> how were you able to pull in native editors on the various platforms? +16:31 < Eric> Just a quick question...why does Susimail take so long to check mail or load? Other .i2p pages load quickly. +16:32 < jadeSerpent> Eric: pop3 is a very verbose protocol, moreseo than http (more packets exchanged per operation) +16:32 < Eric> Ah, alright. +16:33 < jrandom> jadeSerpent: import org.eclipse.swt.widget.Text instead of ...swt.custom.StyledText ;) +16:33 < _bob> Eric = Protocol? +16:33 < jrandom> Eric: aye, the app runs locally but talks a full pop3 subset to the pop3 server +16:34 < jadeSerpent> jrandom: ah so swt does interface to com frameworks +16:34 < Eric> Why not use webmail over HTTP as opposed to a local client fetching and sending via POP/SMTP? +16:34 < jadeSerpent> nm i'll just read the code +16:35 < jrandom> jadeSerpent: well, its a native /text/ widget, not the com html editor widget +16:35 < jadeSerpent> Eric: ask postman that question, and preferably in #i2p-chat ;) +16:35 < Eric> Okay. +16:35 < jadeSerpent> jrandom: oh +16:35 * jadeSerpent was thinking gedit/console/riched32 +16:36 < jadeSerpent> s/console/kate/ +16:36 < jrandom> jadeSerpent: the com html editor widget is easy enough to integrate too, but itd require a lot of issues +16:36 < jadeSerpent> yeah best do your own parsing for security +16:36 < jrandom> (eg auditing it for security, especially when quoting content) +16:39 < jrandom> ok, if there's nothing else on 2), lets jump to 3) ??? +16:39 < jrandom> anyone have anything they want to bring up for the meeting? +16:40 < jadeSerpent> how's the situation with registerfly +16:40 < jadeSerpent> is i2p.net saved? ;) +16:41 < jrandom> eh not yet sorted, hope to get it dealt with soon +16:41 < jrandom> but y'all have 66.111.51.110 memorized anyway, right? ;) +16:41 < _bob> i2p.net will soon serve you ads and ads. ;) +16:42 < jadeSerpent> yes, it's the same number i use for the combination on my briefcase +16:42 < jadeSerpent> _bob: that's one of my fears :( +16:43 < jadeSerpent> or redirect to SiteFinder +16:43 < jadeSerpent> what a mess registerfly created heh +16:43 < jrandom> it'll get sorted in the next day or two +16:44 < Eric> Heh, now I remember where I've seen that IP. It's the outproxy IP address. +16:44 < snoopy> jr: check this page, re i2p.net: http://www.dyndns.com/news/releases/registerfly_safe_harbor.html +16:44 < jrandom> aye eric :) +16:46 < jrandom> snoopy: most of the registrars out there are offering discounts to scoop up ex-registerfly users (though luckily we're technically an enom registrant) +16:46 * jrandom just needs to get onto a secure term (tried to earlier today, but the place was closed) +16:47 < jrandom> ok, anyone have anything else to bring up for the meeting? +16:49 < jrandom> if not... +16:49 * jrandom winds up +16:50 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/203.rst b/i2p2www/meetings/logs/203.rst new file mode 100644 index 00000000..02d56eb6 --- /dev/null +++ b/i2p2www/meetings/logs/203.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 20, 2007 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/204.log b/i2p2www/meetings/logs/204.log new file mode 100644 index 00000000..e0ea9a8c --- /dev/null +++ b/i2p2www/meetings/logs/204.log @@ -0,0 +1,75 @@ +16:02 < jrandom> 0) hi +16:02 < jrandom> 1) Net status +16:02 < jrandom> 2) zzz's NTCP/SSU proposals +16:03 < jrandom> 3) Syndie dev status +16:03 < jrandom> 4) DNS/registrar status +16:03 < jrandom> 5) ??? +16:03 < jrandom> 0) hi +16:03 * jrandom waves +16:03 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001342.html +16:04 < jrandom> jumping into 1) net status +16:04 < jrandom> things seem pretty good, and as mentioned there's more research to do regarding the latest changes +16:05 <+Complication> I wanted to complain a bit about IRC connectivity (everything else seems decent enough), but this last day, I've only had about 6 disconnects, which ain't so bad +16:05 < cervantes> /mute Complication +16:05 < jrandom> heh +16:05 <+Complication> :D +16:06 <+Complication> Tunnel build success is very nice, though +16:06 * Complication checks again, just in case +16:06 < jrandom> yeah i've seen some discon churn (though tbh, i read my backlog with a grep -v -\!- so never see the discons ;) +16:06 < cervantes> there have been various ISP cockups recently on the irc front - postman is looking into alternative hosting arrangements +16:06 < jrandom> tunnel build rates on the stats have made an upturn, though seem generally in line with the cycles up on stats.i2p +16:06 < cervantes> hopefully we can get some better network redundancy +16:06 < jrandom> ah ok cervantes +16:07 * jrandom would offer to help w/ dev.i2p.net, but i dont remember the last time the load was under 4 on it +16:08 < jrandom> ok, anyone have anything else to bring up re: net status? +16:10 < jrandom> if not, hopping over to 2) zzz's NTCP/SSU proposals +16:10 < jrandom> zzz doesn't seem to be around atm, and i left my syndie posts responding to the thread at home (d'oh) +16:11 < jrandom> in any case, post up your thoughts in zzz's blog (or read there for more info) +16:11 < jrandom> anyone have anything to discuss regarding that here now though? +16:12 <+Complication> Well, I personally wrote a reply there, expressing concern about too great reliance on UDP (since for me personally, UDP had rather high retransmission rates) +16:12 < jrandom> aye +16:12 <+Complication> I thougt, however, about one approach... +16:12 <+Complication> Currently the bids are fully deterministic (as opposed to probabilistic with a random component) right? +16:13 < jrandom> aye, fully deterministic +16:13 <+Complication> I was wondering if there would be any benefit (in the sense of avoiding extremes) in making them have a probability component +16:14 <+Complication> As in "60% chance of getting NTCP, 40% chance of getting SSU" +16:14 <+Complication> (assuming no prior data - if prior failure / success data would be present, that would probably need to skew the probability in favour of the better-performing transport for that link) +16:15 < jrandom> well, it depends on what one is hoping to achieve - from my understanding of zzz's proposal, the aim is to use ssu whenever possible +16:15 <+Complication> (assuming of course that both transports are usable for a given link - sometimes they certainly aren't) +16:15 < jrandom> randomizing it would't help with that, though would offer more room to get data on both transports in the wild +16:16 <+Complication> Just a thought on one possible way of trying to strike a balance between them ('cause if one always bids higher, routers likely won't "experiment" much) +16:19 < jrandom> 'tis a method we could use to gather more data, worth keeping in mind +16:19 < jrandom> ok, as mentioned, post on up to that thread for more stuff :) +16:20 < jrandom> jumping on over to 3) Syndie dev status +16:20 < jrandom> i dont have much to add beyond whats in the mail +16:20 < jrandom> anyone have any questions/comments/concerns? +16:21 <+Complication> Not yet. :) +16:22 < jrandom> hehe +16:22 * Complication entertains a hope of helping out more, either on the I2P or Syndie front, but I really need to get that webcache thingy out of the door first +16:22 < jrandom> w3rd, looking forward to both :) +16:24 < jrandom> ok lets skip past 4 and jump to 5) ??? +16:25 < jrandom> anyone have anything else they want to bring up for the meeting? +16:26 < TrevorReznik> is there any interest in a hashcash generator for i2p? +16:26 < TrevorReznik> as in through the browserinterface. +16:26 < TrevorReznik> i thought about that as kind of way to eliminate possible DoS scenarios inside i2p. +16:27 < jrandom> hmm, in javascript or c/java? +16:27 < jrandom> i think there are a few hashcash generators out there +16:27 < TrevorReznik> in java. +16:28 <+Complication> well, some research into hashcash schemes is likely to be needed at some point +16:28 < TrevorReznik> www.hashcash.org has some i think. +16:28 < TrevorReznik> they are an initiative to establish it for email clients as antispam thing. +16:28 <+Complication> perhaps not research in a proper sense, but in an implementation and best practise sese +16:28 <+Complication> =sense +16:28 < TrevorReznik> they have a collection of implementations in a multitude of languages. +16:28 < TrevorReznik> there are 2 java classes and at least one applet there, though i dont know the exact license parameters as of now. +16:30 <+Complication> places which could use it: 1) nym registration in Syndie 2) name registration in I2P +16:30 <+Complication> 3) email, obviously +16:30 * TrevorReznik agrees. +16:30 <+Complication> 4) in less optimistic scenarios, ordinary messages in Syndie +16:31 <+Complication> on the I2P network level itself... +16:31 <+Complication> hmm +16:31 < jrandom> its possible to embed them into tunnel creation mesages, but we're already hosed on that cpu front as it is ;) +16:39 < jrandom> ok, anyone have anything else for the meeting? +16:41 < jrandom> if not +16:41 * jrandom winds up +16:41 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/204.rst b/i2p2www/meetings/logs/204.rst new file mode 100644 index 00000000..9d33e80f --- /dev/null +++ b/i2p2www/meetings/logs/204.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 27, 2007 +=============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/205.log b/i2p2www/meetings/logs/205.log new file mode 100644 index 00000000..0cf0603a --- /dev/null +++ b/i2p2www/meetings/logs/205.log @@ -0,0 +1,82 @@ +16:01 < jrandom> 0) hi +16:01 < jrandom> 1) net status +16:01 < jrandom> 2) syndie dev status +16:01 < jrandom> 3) ??? +16:01 < jrandom> 0) hi +16:01 * jrandom waves +16:01 < jrandom> weekly status notes are not up yet, but there wasn't much in 'em so we can cover it inline here +16:01 < jrandom> jumping into 1) net status +16:01 < jrandom> things seem to be doing pretty well, no major problems atm. there were some troubles on the irc servers earlier, but the hardware issues have been resolved (thanks cervantes and postman!) +16:01 < jrandom> there's been some more discussion on zzz's blog regarding the ssu/ntcp ideas - check that out for more info +16:01 < jrandom> i don't have much to add on that... anyone have anything to bring up on 1) net status? +16:04 < jrandom> if not, lets move on to 2) syndie dev status +16:04 < jrandom> some good progress on the desktop gui lately, with a few components propagated back into the tabbed gui as well +16:04 < jrandom> we've still got some work to do, but i use the desktop gui for most everything atm. +16:04 < jrandom> mk has brought up some more ideas and concerns regarding the desktop gui as well, and as always, read the Syndie dev forum to follow the planning and implementation +16:04 <+Complication> indeed, I can also confirm higher IRC sessions persistence +16:04 < jrandom> w3wt +16:06 <+Complication> Seems like testing it again might be scheduled then (during my last test, I found it a bit... intimidating) +16:07 < jrandom> ah yeah, i added labels to most of the buttons now ;) +16:07 < jrandom> though if you're on windows it still does the vertical button labels wrong (need to write a custom layout for that) +16:07 <+Complication> (especially the lack of labels on the many components) +16:08 < jrandom> but its still not ready for alpha... i can use it because i know what everything does/is suposed to do +16:08 <+Complication> over here it's Linux, but good to know, I guess +16:08 < jrandom> but hopefully in the next week or so +16:09 <+Complication> on the Syndie side, I've been wondering about one issue: could the new syncing code is being overzealous, like attempting too many transfers concurrently? +16:09 <+Complication> s/is being/be +16:09 < jrandom> it'll try 5 concurrent fetches per archive +16:10 < jrandom> (and one async import thread) +16:10 <+Complication> Over here, its failure rate against most archives has seen a dramatic rise from earlier times +16:10 < jrandom> hmm +16:10 <+Complication> It could be that more people are syncing too, but I'd still hope it possible to hit a spare moment when the archive ain't busy +16:10 <+Complication> "hitting a spare moment" and getting a quality sync done, seems to generally not happen, though +16:10 < jrandom> so various fetches fail saying "connection reset" or other tcp-like error message? +16:11 <+Complication> "socket closed" and whatnot +16:11 < jrandom> ah ok +16:11 <+Complication> I haven't really counted them +16:11 <+Complication> This is of course entirely via I2P +16:11 < jrandom> the servers arent currently that hefty (i think they have very limited handling capacity), and that should get imporved +16:12 < jrandom> also, as you and $nymFormerlyKnownAsAnonymous said, we should retry those kinds of failures +16:12 <+Complication> right, that might help too +16:12 < tapeworm> What are the servers based on? +16:12 < jrandom> but we definitely need that to be rock solid and transparent, of course +16:13 < jrandom> tapeworm: homebrew +16:13 <+Complication> though when I mesured "eepget" performance a while back, comparatively to Syndie, eepget got great performance and reliability +16:13 < jrandom> (about a dozen lines of code) +16:13 <+Complication> it pulled 2 x 9 MB from dev.i2p.net while archive.syndie.i2p kept failing on tiny little messages +16:13 < jrandom> oh, thats not really a fair test though +16:14 <+Complication> different boxes? +16:14 < jrandom> and syndie actually /uses/ eepget to fetch +16:14 < jrandom> fetching from apache is pretty different from fetching lots of small files from a homebrew webserver ;) +16:14 <+Complication> hmm... I should probably log overzealously while syncing then +16:15 <+Complication> indeed, and the difference between servers too +16:17 <+Complication> heh, it seems I managed to initiate a sync in the desktop UI +16:17 <+Complication> a task which proved too hard last time :) +16:17 < jrandom> w3wt :) +16:18 < jrandom> ok, anyone have anything else for 2? if not, lets jump on over to 3) ??? +16:18 <+Complication> I do have the habits of a heavy taskbar user, though, so it will likely take some getting used to +16:18 <+Complication> (I usually have the taskbar on auto-hide) +16:19 < jrandom> well, there's a compile time option to put the desktop gui in a shell rather than fullscreen - we can make that a command line switch instead +16:19 <+Complication> is the desktop gui, in principle, capable of having a "minimize" button? +16:19 < jrandom> its trouble to make it a runtime change though, as swt doesn't allow gui component reparenting (reliably), and you cant change a shell's trim +16:20 < jrandom> oh, yes, definitely possible - good idea +16:20 <+Complication> which would send it to background without affecting the order in which other windows below it are arranged? +16:20 < jrandom> we can toss that into the control menu (top left) or the task menu (top right) +16:20 <+Complication> Because using alt+tab tends to change that +16:21 <+Complication> (something... like the "show desktop" button I typically like to have on the taskbar near the KDE / Start button) +16:21 <+Complication> (another location may prove better, but something of this effect) +16:22 < jrandom> yeah, we can hide it the same wayt the tabbed gui's minimize works (or we can iconize it like the normal windowing minimize button) +16:22 <+Complication> Even if admittedly, minimize and show desktop are different things - now that I consider more, minimize seems a bit more logical. +16:24 <+Complication> As for syncing errors, I currently have 1 instance of HTTP 504, and 4 instances of "socket closed" +16:24 <+Complication> 2 successes +16:24 * TrevorReznik encounters like 70% socket closed +16:24 < jrandom> zounds +16:24 < jrandom> ok, ill look into that and get an update in there asap +16:27 < jrandom> ok, in 3) ??? - anyone have anything else for the meeting? +16:27 <+Complication> I wish I had, but not yet - webcache app still incomplete, since real life ran me over a little +16:28 < jrandom> damn that reality! +16:28 * Complication will try to get the 15 annoying things sorted out of the way +16:32 < jrandom> wr0d +16:32 < jrandom> ok, if there isn't anything else for the meeting... +16:32 * jrandom winds up +16:33 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/205.rst b/i2p2www/meetings/logs/205.rst new file mode 100644 index 00000000..aa3e4bac --- /dev/null +++ b/i2p2www/meetings/logs/205.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 3, 2007 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/206.log b/i2p2www/meetings/logs/206.log new file mode 100644 index 00000000..ecd81433 --- /dev/null +++ b/i2p2www/meetings/logs/206.log @@ -0,0 +1,39 @@ +16:01 < jrandom> 0) hi +16:01 < jrandom> 1) Net status +16:01 < jrandom> 2) Syndie dev status +16:01 < jrandom> 3) ??? +16:01 < jrandom> 0) hi +16:01 * jrandom waves +16:01 < jrandom> the brief weekly status notes are posted up at http://dev.i2p.net/pipermail/i2p/2007-April/001343.html +16:01 * mrflibble waves back +16:03 < jrandom> as those notes are short enough, lets jump on in to 1) Net status +16:03 < jrandom> things seem to be going along fairly well lately +16:03 < jrandom> atm there aren't any major changes underway for the net (that i know of), so that will likely remain the case +16:03 < jadeSerpent> irc seems to have calmed down finally too +16:03 < jrandom> cool +16:05 < jrandom> i don't have much to add re: 1) net status, so unless anyone has anything for it, lets jump on over to 2) Syndie dev status +16:07 < jrandom> the next rev is taking longer than expected, but i'm hoping to get a new release out in the next 2-3 days +16:07 < jrandom> it won't be the desktop gui, but will include a number of improvements +16:08 < Complication> anything which helps syndication reliability would be wonderful +16:08 < Complication> it's been comparatively poor lately +16:08 < jrandom> aye, that trouble should be easy enough to sort out (to an extent) +16:09 < jadeSerpent> you know what's causing the failed fetches via i2p? +16:09 < jrandom> aye, low timeouts +16:10 < jrandom> (and low handler threads on the servers) +16:13 < jrandom> ok, if there isn't anything else on 2) Syndie dev status, lets jump over to 3) ??? +16:13 < jrandom> anyone have anything else to bring up for the meeting? +16:14 * mrflibble waves +16:14 < mrflibble> sorry, going back to point 1 again +16:15 < mrflibble> <jadeSerpent> irc seems to have calmed down finally too - is this for any particular reason do you think? +16:16 < jrandom> there were some network and hardware trouble on the irc servers, and most people have upgraded to the latest release now (giving us the benefit of zzz's improvements) +16:17 < jrandom> the #s for tunnel creation success rates look much better +16:17 < mrflibble> oh ok, was the servers themselves +16:17 < mrflibble> what were zzz's imporvements? +16:19 < Complication> message priorities, to allow tunnel build messages to take priority over tunnel traffic +16:19 < Complication> and streaming lib adjustments, and the usual array of I2PSnark fixes +16:19 < mrflibble> ah, thanks +16:19 < jrandom> (what Complication said :) +16:22 < jrandom> ok, anyone have anything else for the meeting? +16:26 < jrandom> if not +16:26 * jrandom winds up +16:26 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/206.rst b/i2p2www/meetings/logs/206.rst new file mode 100644 index 00000000..6220c96b --- /dev/null +++ b/i2p2www/meetings/logs/206.rst @@ -0,0 +1,7 @@ +I2P dev meeting, April 10, 2007 +=============================== + +Quick recap +----------- + +TODO diff --git a/www.i2p2/pages/meeting207.html b/i2p2www/meetings/logs/207.log similarity index 99% rename from www.i2p2/pages/meeting207.html rename to i2p2www/meetings/logs/207.log index 66fb4015..2150edca 100644 --- a/www.i2p2/pages/meeting207.html +++ b/i2p2www/meetings/logs/207.log @@ -1,9 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 207{% endblock %} -{% block content %}<h3>I2P dev meeting, February 10, 2009</h3> -<div class="irclog"> -<pre> -{% filter escape %} 2009 Feb 10 20:58:32 <unixfr3ak> dev meeting eh? 2009 Feb 10 20:59:27 -*- dream turns on devo 2009 Feb 10 21:00:25 <welt> dream: ah.. glad you're here too :) @@ -386,8 +380,3 @@ 2009 Feb 10 22:20:51 <zzz> I have CONNECT implemented, that's what I was talking about above 2009 Feb 10 22:23:20 <dream> Neat I can't think of any reason why not to do that, and it'd be lots more convenient since SOCKS is so goddamn popular many apps come with it. 2009 Feb 10 22:23:30 <-- gloin (gloin@irc2p) hat das IRC verlassen (Connection reset by peer) -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/207.rst b/i2p2www/meetings/logs/207.rst new file mode 100644 index 00000000..2d18312f --- /dev/null +++ b/i2p2www/meetings/logs/207.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 10, 2009 @ 21:00 UTC +============================================== + +Quick recap +----------- + +TODO diff --git a/www.i2p2/pages/meeting208.html b/i2p2www/meetings/logs/208.log similarity index 83% rename from www.i2p2/pages/meeting208.html rename to i2p2www/meetings/logs/208.log index 18448cd8..0d0f5157 100644 --- a/www.i2p2/pages/meeting208.html +++ b/i2p2www/meetings/logs/208.log @@ -1,69 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 208{% endblock %} -{% block content %}<h3>I2P dev meeting, September 8, 2010</h3> -<div> -<h4>Quick recap</h4> -<ul> - <li><b>Present:</b> duck, eche|on, Mathiasdm, Moru (later on), superuser, whitenoise, zzz</li> - <li> - <b>Website content progress:</b> - <p> - The website overhaul has taken 7 weeks so far. Progress is not fast enough. We need more people to join in! - </p> - </li> - <li> - <b>Website backend progress:</b> - <p> - No report yet, welterde could not attend the meeting. - </p> - </li> - <li> - <b>Location for development discussion:</b> - <p> - Most people agree that IRC is not an ideal location to post long-winded development discussions, it's too volatile, not backed up and not everyone can read it. <b>All developers are advised to post their discussions (or a writeup) to another medium, like zzz.i2p, mailing lists or forum.i2p</b>. - Opinions on the alternatives are a bit more divided. zzz.i2p is currently the location for most discussions, but a number of people also like the idea of a mailing list. No decision has been made on which alternative would be best suited. - </p> - </li> - <li> - <b>Task appointing and disagreements:</b> - <p> - Currently, people appoint themselves to a task by editing the team.html page (this requires monotone access, so there is at least a level of trust implied before being allowed to appoint yourself). - However, what happens if people disagree? - </p> - <p> - The discussion pointed out that when disagreeing, a discussion should be held (for example on zzz.i2p). If that doesn't resolve the issue, a vote is a possibility, or the Project Manager (zzz) or repository maintainers (welterde, eche|on) can make a decision. - </p> - </li> - <li> - <b>Status updates:</b> - <p> - Status updates will be started next weekend. They will mostly consist of a 'what work did you do last week?' and 'what work will you do next week?'. - </p> - </li> - <li> - <b>Development conferences:</b> - <p> - Nothing big was mentioned. - </p> - </li> - <li> - <b>Promoting the usage of the bittorrent protocol inside I2P: pros and cons:</b> - <p> - Filesharing in general and bittorrent more specifically can be either good or bad for I2P. - On one hand, they could give I2P a bad reputation. On the other hand, they could boost I2P popularity. - What to do? - </p> - <p> - Filesharing on I2P will not be promoted specifically. Instead, general usability should be looked at and improved. - If people decide to use filesharing on I2P (or any other service, like e-mail or browsing), it should become easier as a result of improving the usability. - </p> - </li> -</ul> -</div> -<div class="irclog"> -<h4>Full IRC Log</h4> -<pre> -{% filter escape %} 22:02 <@Mathiasdm> okay 22:02 <@Mathiasdm> meeting time 22:03 <@Mathiasdm> 0) Hello @@ -327,8 +261,3 @@ 23:24 < eche|on> COOKIES! 23:25 <@Mathiasdm> don't eat all of them 23:25 * Mathiasdm pokes eche|on -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/208.rst b/i2p2www/meetings/logs/208.rst new file mode 100644 index 00000000..20c9182a --- /dev/null +++ b/i2p2www/meetings/logs/208.rst @@ -0,0 +1,36 @@ +I2P dev meeting, September 8, 2010 @ 22:00 UTC +============================================== + +Quick recap +----------- + +*Present:* + duck, eche|on, Mathiasdm, Moru (later on), superuser, whitenoise, zzz + +*Website content progress:* + The website overhaul has taken 7 weeks so far. Progress is not fast enough. We need more people to join in! + +*Website backend progress:* + No report yet, welterde could not attend the meeting. + +*Location for development discussion:* + Most people agree that IRC is not an ideal location to post long-winded development discussions, it's too volatile, not backed up and not everyone can read it. **All developers are advised to post their discussions (or a writeup) to another medium, like zzz.i2p, mailing lists or forum.i2p**. + Opinions on the alternatives are a bit more divided. zzz.i2p is currently the location for most discussions, but a number of people also like the idea of a mailing list. No decision has been made on which alternative would be best suited. + +*Task appointing and disagreements:* + Currently, people appoint themselves to a task by editing the team.html page (this requires monotone access, so there is at least a level of trust implied before being allowed to appoint yourself). + However, what happens if people disagree? + The discussion pointed out that when disagreeing, a discussion should be held (for example on zzz.i2p). If that doesn't resolve the issue, a vote is a possibility, or the Project Manager (zzz) or repository maintainers (welterde, eche|on) can make a decision. + +*Status updates:* + Status updates will be started next weekend. They will mostly consist of a 'what work did you do last week?' and 'what work will you do next week?'. + +*Development conferences:* + Nothing big was mentioned. + +*Promoting the usage of the bittorrent protocol inside I2P: pros and cons:* + Filesharing in general and bittorrent more specifically can be either good or bad for I2P. + On one hand, they could give I2P a bad reputation. On the other hand, they could boost I2P popularity. + What to do? + Filesharing on I2P will not be promoted specifically. Instead, general usability should be looked at and improved. + If people decide to use filesharing on I2P (or any other service, like e-mail or browsing), it should become easier as a result of improving the usability. diff --git a/www.i2p2/pages/meeting209.html b/i2p2www/meetings/logs/209.log similarity index 96% rename from www.i2p2/pages/meeting209.html rename to i2p2www/meetings/logs/209.log index 9e67e056..8a6cfaec 100644 --- a/www.i2p2/pages/meeting209.html +++ b/i2p2www/meetings/logs/209.log @@ -1,60 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 209{% endblock %} -{% block content %}<h3>I2P dev meeting, November 20, 2012</h3> -<div> -<h4>Quick recap</h4> -<ul> - <li><b>Present:</b> - asdfsdafsdafsd, - darrob, - dg, - k0e, - KillYourTV, - LaughingBuddah, - nom, - psi, - st4d, - thursday, - user, - weltende, - zzz - </li> - <li> - <b>Network Health - IRC</b> - <ul><li>Russian User Support: Russians are the top country using I2P at - this time, followed by USA and Germany. We know of one - dedicated Russian user that is providing help in our IRC channel #ru - (also see next point). If we add to this area, that would be - great. Since most of the network is russian it makes sense to - make sure they get quality help so they are running their - router optimally.</li> - <li> - Complementing the above issue would be to have our irc - operators <a href="http://www.unrealircd.com/files/docs/unreal32docs.html#denychannelblock">redirect</a> - either #ru -> #i2p-ru or vice versa, there seems to be - conflicting advice given to russian users asking for directions - in this area. - <code> - <br /> - KillYourTV user 'slow' fits there<br /> - KillYourTV (and he's nearly always in #ru) <br/> - dg btw, #ru has users, #i2p-ru does not<br /> - </code> - </li> -</ul> - - <li> - <b>Next Meeting</b> - <p> - The next meeting is scheduled for Tuesday, November 27 @ 19:30 UTC (7:30PM) - </p> - </li> -</ul> -</div> -<div class="irclog"> -<h4>Full IRC Log</h4> -<pre> -{% filter escape %} 20:03:41 <Laughing1uddah> Meeting time? 20:03:48 <dg> It is! 20:04:01 <k0e> checkout http://www.youtube.com/watch?v=hgJ7yck1qwY @@ -585,8 +528,3 @@ 22:10:39 <dg> Great. 22:14:59 <LaughingBuddah> Cya all 22:15:02 <LaughingBuddah> dg: good meeting -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/209.rst b/i2p2www/meetings/logs/209.rst new file mode 100644 index 00000000..1977ac30 --- /dev/null +++ b/i2p2www/meetings/logs/209.rst @@ -0,0 +1,43 @@ +I2P dev meeting, November 20, 2012 @ 20:00 UTC +============================================== + +Quick recap +----------- + +* **Present:** + asdfsdafsdafsd, + darrob, + dg, + k0e, + KillYourTV, + LaughingBuddah, + nom, + psi, + st4d, + thursday, + user, + weltende, + zzz + +* **Network Health - IRC** + * Russian User Support: Russians are the top country using I2P at + this time, followed by USA and Germany. We know of one dedicated + Russian user that is providing help in our IRC channel #ru + (also see next point). If we add to this area, that would be + great. Since most of the network is russian it makes sense to + make sure they get quality help so they are running their + router optimally. + + * Complementing the above issue would be to have our irc operators + redirect_ either #ru -> #i2p-ru or vice versa, there seems to be + conflicting advice given to russian users asking for directions + in this area:: + + KillYourTV user 'slow' fits there + KillYourTV (and he's nearly always in #ru) + dg btw, #ru has users, #i2p-ru does not + +.. _redirect: http://www.unrealircd.com/files/docs/unreal32docs.html#denychannelblock + +* **Next Meeting** + The next meeting is scheduled for Tuesday, November 27 @ 19:30 UTC (7:30PM) diff --git a/i2p2www/meetings/logs/21.log b/i2p2www/meetings/logs/21.log new file mode 100644 index 00000000..1940021a --- /dev/null +++ b/i2p2www/meetings/logs/21.log @@ -0,0 +1,682 @@ +--- Log opened Tue Nov 26 22:43:56 2002 +22:44 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback +22:44 [Users #iip-dev] +22:44 [ CwZ|away] [ Disposable] [ icepick] [ logger] [ pox] [ UserX] +22:44 -!- Irssi: #iip-dev: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal] +22:44 -!- Irssi: Join to #iip-dev was synced in 2 secs +22:44 < logger> test +23:35 < nop> IIP dev meeting in 25 minutes, Special appearance by Capn' crunch aka John Draper +23:36 < Disposable> cool +23:36 < Disposable> the famous capncrunch +23:36 < Disposable> :P +23:36 < nop> yes +23:37 < nop> friend of mine +23:37 < nop> ;) +23:37 < Disposable> yeah? +23:37 < nop> he's working on porting iip to mac os 9 +23:37 < Disposable> cool +23:37 < ptsc> unfortunately i'm off to do laundry but will lurk +23:37 < nop> ok +23:37 < ptsc> nop, why not an os x.2 clean version? +23:37 * Disposable is listening to The Beets - Killer Tofu +23:37 < nop> what? +23:37 < nop> ptsc, we have os x versions +23:37 < Disposable> hmmm +23:37 < nop> we need os 9 +23:38 < nop> because there are still a lot of people on it +23:38 < ptsc> ah, okay. i was considering getting a mac that could run os x +23:38 < nop> yes +23:38 < nop> but only 20% of mac users have switched to X +23:38 < ptsc> in my case, i'd be switching to mac specifically *because* of x +23:39 < Disposable> lol +23:39 < Disposable> yeah +23:39 < Disposable> it looks so sweet +23:39 < Disposable> :) +23:39 < Disposable> i wunna try it +23:39 < Rain> "unix for users done right" some feel +23:39 < ptsc> i saw it at a friend's house who has been a mac freak for ages +23:39 < ptsc> and it just looks awesome +23:39 < ptsc> plus they brought back the NeXT-style file browser +23:39 < ptsc> which has always ruled +23:40 < ptsc> ok bbl +23:40 < Rain> "the first lickable interface", according to mr jobs. +23:41 < Disposable> :/ +23:48 < Disposable> wb +--- Day changed Wed Nov 27 2002 +00:00 < nemesis> blubb +00:00 < nemesis> 23 UTC +00:00 < nop> ok +00:00 < nop> welcome to the 21st iip meeting +00:01 < nop> on the agenda +00:01 < nop> 1) welcome +00:01 < nop> 2) why rc3 isn't released yet +00:01 < nop> 3) when will it be released +00:01 < nop> 4) OS 9 port by Cap'n Crunch +00:01 < nop> 5) Questions and comments +00:02 < nop> ok +00:02 < nop> welcome +00:02 < nop> :) +00:02 < nop> codeshark is out of the country on business, and will be back later this week +00:02 < nop> he's our release coordinator +00:02 < nop> and if he's not back shortly, mids and I will arrange the release candidate +00:02 < nop> and do it that way by friday +00:02 < Aprogas> one should only accept the function of release coordinator, if one knows to have time for that function +00:02 < nop> when will it be released, friday at latest +00:03 < nop> comments are saved for last +00:03 < nop> thnx though aprogas +00:03 < Aprogas> ok +00:03 < nop> ok, os 9 port, Cap'n Crunch has been working (along with his friend) on porting IIP to mac os 9 users +00:04 < nop> hopefully, he will be on here shortly to give us some detail +00:04 < nop> if not I'll send out an email +00:04 < nop> to iip-dev with the latest from him +00:04 < nop> oh speak of the devil +00:04 < crunchman> Ok, I'm on +00:04 < nop> Hi crunch +00:04 < Aprogas> nop: that must be bpb in disguise +00:04 < nop> can you give us a quick detail of what's going on with os 9 +00:04 < crunchman> Of course I didn't get the chance to read over the source so I can bring up my issues. +00:05 < nop> k +00:05 < crunchman> yes - I can. +00:05 < nop> the floor is yours, take it away +00:05 < crunchman> basically - the way IIP was written, it's a CAAN OF WORMS if I have to use the structures you are already using. +00:06 < crunchman> There is NO discrete seperation between the GUI and the guts. +00:06 < crunchman> Let me explain. +00:06 < crunchman> It is VERY baised towards WinBlows. +00:06 < crunchman> As you know, the Mac uses resources for the GUI components. +00:07 < crunchman> I need to examine the code now, and would like to take a few mins to go over my notes, so I can be more specific. +00:07 < nop> ok +00:07 < nop> either way, we can cover that later, but Crunch is working on the os 9, and we will aid him with what we can so that it may be not so tedious a task +00:08 < nop> reasons for the port, is only 20% of mac users have made the switch to os x +00:08 < nop> they still rely on os 9 +00:08 < nop> so a lot of mac os users donated money towards this goal +00:08 < nop> and any other donations are welcome to assist crunch for his time on this project +00:09 < nop> questions and comments from iip users etc +00:09 < nop> ? +00:09 * Disposable is listening to Creedence Clearwater Revival - Fortunate Son +00:09 < Aprogas> comment: one should only accept the function of release coordinator, if one knows to have time for that function +00:09 < Rain> question: what will be new in rc3 +00:09 < Rain> ? +00:09 < nop> mainly bug fixes, hold, I'll get the changelog +00:09 < Aprogas> /exec -o cat ChangeLog | head -200 +00:10 < bpb> question: since when does IIP get donations? +00:10 < crunchman> bob cant get on +00:10 < nop> + iip1.1-rc3: +00:10 < nop> + - Display of version number for windows (menu option) and unix (command line). +00:10 < nop> + - Random number generation fix. +00:10 < nop> + - IIP network connections are no longer paused while in the setup screen. +00:10 < nop> + - Now exits if it can't bind to a socket at startup. +00:10 < nop> + Windows now displays a message box informing that it can't bind to port. +00:10 < nop> + - Several bugfixes and one memory leak fixed. +00:10 < crunchman> i +00:10 < nop> + +00:10 < crunchman> im on phone - helping him +00:10 < crunchman> hold on +00:10 < nop> k +00:10 < nop> that is the changelog +00:11 < Aprogas> comment: women are always late +00:11 < crunchman> hold on - still on phone w/ bob +00:11 < Rain> ok, thanks. +00:11 < nop> haha +00:11 < nop> ok meeting is officially over +00:11 < bpb> if he can't get iip to work, he could connect to my node +00:11 < Aprogas> huh ? +00:12 < nop> I will resume talks with crunch in here +00:12 < athena> okay, so i can slap aprogas now? +00:12 < Aprogas> but maybe i still had questions or commens +00:12 < bpb> :) +00:12 < nop> aprogas +00:12 < nop> do you have any more questions +00:12 < Aprogas> am i being ignored? +00:12 < nop> or comments +00:12 < nop> that pertains to IIP +00:12 < Rain> is the "sneak release" the same as the final one, and will i dare running it on a public proxy at this stage? +00:12 < crunchman> meeting is over? - but we havent even gotten on yet! +00:12 < Aprogas> where is mids? +00:12 < bpb> crunchman: that's nop for you... +00:12 < nop> crunch we can still talk in here +00:12 < Aprogas> no mids no meeting +00:12 < crunchman> Bob is trying to get on - and yet the meeting is now over? +00:12 < nop> rain sneak is the same yes +00:12 < nemesis> hm... nop, i use blackbox under windows xp, why theres no cmd line version of IIP out? +00:13 < nemesis> that i can use as an service.. +00:13 < crunchman> bpb - I have no clue what you mean by "crunchman: that's nop for you" +00:13 < Aprogas> bpb means nothing with it +00:13 < Aprogas> he loves to confuse people +00:13 < nop> well, nemesis iip -d might be able to do that for you +00:13 < crunchman> still trying to get bob logged in. +00:13 < bpb> crunchman: he's cutting off the meeting after it hasn't begun +00:14 < nop> the "official" meeting is over +00:14 < Disposable> hehe +00:14 < nop> other than comments +00:14 < crunchman> sorry I couldn't get on sooner. +00:14 < Rain> ok, so i might as well de-install the rc2 proxy i recently installed today, and replace it with rc3, no risk? +00:14 < Aprogas> nop: will there be an rc4 or even rc5, and when are they expected, and when is iip 1.1 expected? +00:14 < nop> rc3 should be final before 1.1 +00:15 < nop> unless +00:15 < Aprogas> of course the release candidate comes before the release +00:15 < crunchman> Could someone call bob on phone and help him +00:15 < nop> unless major bugs were found +00:15 < nemesis> hm.... +00:15 < Aprogas> nop: why do i get the idea you forget what a rc is all the time ? +00:15 < nemesis> nop, must i shutdown my current iip for -d? +00:16 < Aprogas> nop: so when are 1.1 and 1.1-rc3 expected? +00:16 * bpb remembers when decentralized 2.0 was expected ;) +00:16 < nemesis> crunchman: help with what? +00:17 < crunchman> bob cant get on this IRC server. +00:17 < crunchman> I tried to help him - I gave up. +00:17 * Aprogas remembers saying that iip 1.1 would be released the day after freenet 0.5 +00:17 < crunchman> I asked Lance to help him get on. +00:17 < Aprogas> crunchman: what kind of error does he get ? +00:17 < crunchman> When he's on... he can give you guys an update in HIS progress. +00:18 * Disposable is listening to Creedence Clearwater Revival - Susie Q +00:18 < crunchman> I don't know - I didnt get chance to ask him - sorry. +00:18 < nemesis> waaaaaaaaaaaaaaaaaaaaaaah *crying* +00:18 < nemesis> mids +00:18 < nemesis> i have 5 iip process running... +00:18 < crunchman> I REALLY would like to go off and re-examine the IIP work I did - so I can answer intellegent questions on the issues I want to bring up. +00:18 < nemesis> fuck it *grrr* +00:18 < crunchman> but I want BOB up here first. +00:19 < crunchman> because he also has to explain HIS part in the project +00:19 < Aprogas> it would be useful if we would know what kind of problem he has with connecting to here +00:19 < crunchman> I think he will address the group on his "socket" problems. +00:19 < Aprogas> is he using his own isproxy or yours? +00:19 < crunchman> Nop is talking to him on the phone right now - i hope.; +00:20 < crunchman> Bob has a Mac... I think he's using ircle +00:20 < crunchman> this is what I'm using right now. +00:20 < nop> I am +00:20 < nop> athena +00:20 * Kyfhon remembers trying that vile thing in an emulator +00:20 < Disposable> question: primary mac developeman will before os 9 ? +00:20 < nop> he's using athena +00:20 < crunchman> ok, i'll be right back. +00:20 < nemesis> re.... +00:20 < nemesis> are no pid implented in iip yet? +00:21 < nemesis> or cmd line output... +00:21 < nop> crunch, his inet connection is acting up +00:21 < nemesis> i always started a new instance with iip -d or -h or -? and ? +00:23 < Aprogas> maybe he could come tomorrow, or at next week's meeting then +00:24 < bpb> well, captn crunch made a atleast celebrity appearance today. +00:24 < bpb> err +00:24 < Aprogas> never heard of him, im from the pentium generation +00:25 < bpb> minus the atleast +00:25 < bpb> Aprogas: you never heard of captain crunch? +00:25 < Aprogas> no +00:25 < bpb> he is THE LEGEND +00:25 < Aprogas> nop: IIP should become a tiny bit more formal +00:25 < xenode> im from the pentium generation and i still've heard of him +00:25 < nop> formal? +00:25 < Aprogas> of course its an opensores project, so it will always be informal +00:25 < bpb> Aprogas: you mean without your rudeness? +00:26 < Aprogas> but right now it seems like a chaotic bunch of people doing some things in a basement and something coming out of nowhere once in a while +00:26 < bpb> Captain Crunch is the man who started telephone fraud :) +00:26 < Aprogas> it seems completely unorganised to me +00:26 < Aprogas> bpb: as i said, im from the pentium generator +00:26 < xenode> Aprogas: thats no excuse +00:26 < bpb> well, maybe not started it, but he did it using a captain crunch whistle +00:26 < nemesis> hm.... +00:27 < Aprogas> its not meant as an excuse, its a reason +00:27 < rda> i am here +00:27 < xenode> its not a reason either +00:27 < Kyfhon> Aprogas: What do you expect? Snappy logos and a pr gremlin? +00:27 < nemesis> irc are at the most time idle +00:27 < Aprogas> kyfhon: no, but that is all i see now +00:27 < bpb> ...and used it to call the pope long distance for free +00:27 < nemesis> whats about VoIP (IIP) ;) +00:27 < Aprogas> i'd like releases, and code, and bugfixes and stuff +00:27 < nemesis> 8kbit datastream +00:27 < bpb> the legendary phone call +00:27 < Aprogas> and less t-shirts, mugs, and interviews +00:27 * Kyfhon didn't know there were tshirts. Hmm +00:27 < crunchman> Ok, back on again. +00:28 < crunchman> ok +00:28 < bpb> Aprogas: I can't believe you hadn't heard of Captn Crunch +00:28 < nemesis> lol +00:28 < hezekiah> crunchman: Good! :) +00:28 < bpb> geez Aprogas, you're a disgrace +00:29 < Aprogas> bpb: i know +00:29 < bpb> next thing I know you'll be saying you don't know who Steve Wozniac is +00:29 < Aprogas> nop: i also feel like my suggestions are being ignored +00:29 < Aprogas> dont know him either +00:29 < nop> well, you expect quite a bit +00:29 < Aprogas> im a hermit, i dont know many people +00:29 < Aprogas> maybe +00:29 < xenode> he must be fooling with us.. i mean.. jeez +00:29 < Aprogas> or maybe IIP isnt what i thought it was +00:29 < bpb> Aprogas: what about Steve Jobs? +00:29 < bpb> Aprogas: Bill Gates? +00:30 < Aprogas> bpb: sounds familiar, isnt he the Apple CEO +00:30 < bpb> Aprogas: 0x90 +00:30 < bpb> yep +00:30 < Aprogas> and the second one the Microsoft Fuehrer +00:30 < Aprogas> i know 0x90 +00:30 < Aprogas> but he isnt legendary +00:30 < bpb> true +00:30 < Aprogas> nop: what is IIP actually? +00:30 < bpb> but I wanted to make sure you knew who he was :) +00:31 < Aprogas> i know his address, get a copy of his phone bill, listen to his phonecalls sometimes, and have camera's behind his mirrors +00:31 < Aprogas> so i know him +00:31 < bpb> but captain crunch is one of the few true legends we have in the world of geekdom +00:31 < xenode> heh +00:31 < Aprogas> im not a geek, im a hermit +00:31 < bpb> Aprogas: that's too bad +00:31 < Aprogas> but i need IRC for some dynamics +00:31 < Aprogas> my shack is only statis +00:32 < Aprogas> and statis does not bring much inspiration +00:32 < bpb> nop: you know the world of geekdom well, correct? :) +00:32 < nop> yes +00:32 < nop> aprogas IIP is what it is +00:32 < Aprogas> nop: which is ? +00:32 < Aprogas> im not sure if i know what IIP is actually +00:32 < Aprogas> or what it is meant to be +00:32 < Aprogas> can you tell me ? +00:33 < nop> it would take too long +00:33 < nop> read the site +00:33 < Aprogas> bla +00:33 < nop> rda join #dev +00:33 < bpb> haha +00:33 < Aprogas> i read it +00:33 < Aprogas> #dev, #iip-dev, #iip, #anonymous +00:33 < Aprogas> *g* +00:33 < Aprogas> you want to DoS my client by letting me join more channels than it can handle? +00:33 < bpb> they're all conspiring against us in #dev +00:34 < nop> well aprogas it doesn't matter to you +00:34 < nop> you're not a developer +00:34 < Aprogas> ok +00:34 < Aprogas> indeed i am not +00:34 < nop> so your expectations must remain as a critic +00:34 < nop> critics don't get what they want +00:34 < nop> developers do +00:34 < Aprogas> im not a critic +00:34 < bpb> hahaha +00:34 < Aprogas> im a disappointed enthusiast +00:35 < nop> yes +00:35 < bpb> nop: you never answered my question from the meeting btw... +00:35 < nop> and I appreciate your dissapointment +00:35 < nop> which one bpb +00:35 < bpb> nop: since when does IIP get donations? +00:35 < Aprogas> someone who thought it would be possible to resist opression without needing dark basements and information exchanges in the park +00:35 < nop> well they have bpb +00:36 < bpb> nop: since when, how much, etc.? :) +00:36 < bpb> nop: the critics must know ;) +00:36 < Aprogas> nop: i think you still did not tell me when iip 1.1 will be done +00:37 < nop> I can't give that answer until rc3 is released +00:37 < Aprogas> can you give a rough estimate ? +00:37 < Aprogas> or at least tell me when you expect rc3 +00:38 < nop> rc3 by friday +00:38 < nop> at worse case +00:38 < Aprogas> so by friday you can give a rough estimate about when iip 1.1 will be done ? +00:38 < nop> yes +00:38 < Aprogas> ok, ill stay until friday then +00:39 < nop> fine with me +00:39 < nop> what do you expect from IIP aprogas +00:39 < nop> and why +00:39 < Aprogas> i dont know what to expect from IIP +00:39 < Aprogas> but i can try to analyse what i expect from it +00:40 < Aprogas> i think i expect IIP to be a certain `medium' which i can use to say anything i would like without having feelings of fear along with saying those things +00:40 < Aprogas> but i think i also expect IIP to have a somewhat professional, or at least organised, character +00:41 < Aprogas> probably because i would have more trust in the application if that would be the case +00:41 < nop> I can't demand professionals unless I can pay them +00:41 < Aprogas> you can act like a professional +00:41 < nop> since people like you choose not to donate substantial amounts of money, and only your criticism it will be hard +00:41 < Aprogas> i dont enjoy criticism +00:42 < Aprogas> and i would love the develop if i didnt think the development team was an unorganised bunch of people +00:42 < nop> it's not unorganized +00:42 < nop> it's quite organized +00:42 < Aprogas> it seems to be +00:42 < nop> it's just not the way you want it +00:42 * Debolaz whispers to the developers next to him: "Don't take it personally.. someday, you'll be a real live boy" +00:42 < Aprogas> maybe +00:43 < nop> aprogas, if you want to be the leader +00:43 < nop> than that is up to you +00:43 < Aprogas> i dont want to be the leader at all +00:43 < nemesis> hrhr +00:43 < Aprogas> i want to be unknown, because being unknown is safer +00:43 < nop> correct +00:43 < Kyfhon> Dear gods. Aprogas get your head out of your ass. These people are doing this on their own time and letting everyone use it, and you're demanding behavior modification +00:44 < Aprogas> i am just giving these people some advice +00:44 < nemesis> achja, fehlt nur noch ardvark ;) +00:44 < Aprogas> if you make a tool, but if you seem like an unorganised bunch, that will probably repell serious users +00:44 < nop> well, we have serious software that works +00:44 < Aprogas> sure, you'll attract some geeks who can say `look mommy, im now anonymous' +00:44 < nop> and a serious website +00:44 < nop> and we have decent organization +00:44 < Kyfhon> Well your advice was given quite awhile ago. You keep giving the advice repeatedly and thus it looks like demands from my end +00:44 < Aprogas> then why do you hide that ? +00:44 < nop> I think that we have gone farther than a lot of open source projects +00:44 < Aprogas> if you have serious softwar that works, why dont you release it ? +00:45 < nop> you're using it right now +00:45 < Aprogas> it doesnt seem to work well +00:45 < nop> and if you want rc3 +00:45 < nop> it's in cvs +00:45 < nop> ready for you +00:45 < nop> and when rc3 is ready for the General audience +00:45 < nop> it will be released +00:45 < Aprogas> my isproxy often complains it cannot reach certain things, and sometimes just vanishes without a trace +00:45 < nemesis> hm.... irgendwie hat er ja recht... +00:45 < nop> probably because someone hated your noc +00:45 < bpb> nop: well, what's the goal of IIP anyway? And how close is it to reaching that goal? +00:45 < Aprogas> no +00:45 < nemesis> lol +00:45 < Aprogas> it did that before that +00:46 < Aprogas> bpb: the goal of IIP is to be what it is +00:46 < nop> bpb, the goal is obvious +00:46 < nop> if you haven't read the site +00:46 < nop> then I can't help you +00:46 < nop> I'm not going to be long winded +00:46 < nemesis> hm... +00:46 < nop> I am programmed to have a array of 200 characters max per line +00:46 < nop> and I prefer it to be shorter +00:46 < nop> obviously +00:46 < bpb> nop: I've read the sites ever since casper the friendly ghost... +00:46 < nemesis> 200? +00:47 < nop> then you're asking a rhetorical question +00:47 < Aprogas> nop: is the central IIP server reliable ? +00:47 < nop> it hasn't gone down for a very long time +00:47 < nop> it's hosted in a secured facility +00:47 < nemesis> 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 +00:47 < bpb> nop: no, I don't believe I am... maybe I should rephrase... +00:47 < nemesis> thats 200 ^^ +00:47 < Aprogas> even before our NOC was destroyed, i got disconnected from IIP at least once a day i think +00:47 < Aprogas> so i wouldnt really call that `software that works' +00:47 < nop> well, you're talking on it now +00:47 < nop> so +00:48 < Aprogas> sure +00:48 < Aprogas> but i want it to be reliable +00:48 < Aprogas> you never know when you are going to need it +00:48 < bpb> nop: why did you start IIP exactly? +00:48 < Aprogas> bpb: to mock his wife +00:48 < nop> because it was cool +00:48 < nop> and i wanted to be cool +00:48 < nop> don't you know +00:48 < nop> I'm in california +00:48 < nop> it's all about cool +00:48 < nemesis> ;) +00:49 < nemesis> and whate are you think about your project at this time? ;) +00:49 < bpb> ... +00:49 < bpb> heh +00:49 < nop> next I'll get breast implants +00:49 < nop> I think it's cool +00:49 < nop> ;) +00:49 < nemesis> hehe ;) +00:49 < bpb> nop: hey, if you're a city employee in SF, free sex change ;) +00:49 < nop> look aprogas, you've made your comments +00:49 < Aprogas> maybe +00:50 < nop> and they are heard +00:50 < nop> and we do our best +00:50 < bpb> nop: butt sex is also cool in california ;) +00:50 < Aprogas> they havent been really said +00:50 < nemesis> why you wan't to limit the max characters to max 200 each per line? +00:50 < Aprogas> its hard to express what exactly i mean +00:50 < Aprogas> its just that everytime i try to do something with anonimity and stuff, it fails +00:50 < Aprogas> its a big disappointment +00:51 < nemesis> thats true.. +00:51 < Aprogas> every few months i cvs checkout freenet again, see if it works already +00:51 < Aprogas> then it seems to work, and at the moment i am to share my excitement with others, it breaks into a horrible pit of frustration and agony +00:51 < Aprogas> im afraid IIP is going to be affected by the same curse +00:52 < nop> well aprogas, more comments say IIP works better than freenet +00:52 < nop> but it's a work in progress +00:52 < bpb> If you want to be cool, you just need to let everybody know you're friends with captn crunch... oh wait, you've done that too ;) +00:52 < Aprogas> thats why i still use IIP right now and ditched freenet +00:52 < Kyfhon> Heh ever since freenet 0.5 it takes like 5 minutes to retr something. +00:52 < Aprogas> kyfhon: thats not that bad +00:52 < Aprogas> i can wait 5 minutes +00:52 < Kyfhon> ...With a50% failure rate +00:53 < nemesis> hrhr +00:53 < Aprogas> mm.. maybe i should try freenet again +00:53 < bpb> yeah +00:53 < bpb> 0.4 during a certain era was great +00:53 < Aprogas> is that with the 5xx or 6xx build? +00:53 < Aprogas> most of the time 0.4 was broken +00:53 < Aprogas> and trying to insert something in freenet 0.3 traumatised me +00:53 < bpb> Aprogas: 0.5 is 5xx and 6xx +00:54 < Kyfhon> 0.5.0.6 tarball +00:54 < Aprogas> bpb: thats why im asking where kyfhon gets those decent results +00:54 < Aprogas> but i shouldnt be naive +00:54 < Aprogas> i know its going to faiil +00:54 < Aprogas> because i use kaffe +00:54 < Aprogas> so ill try again later +00:54 < bpb> haha +00:55 < bpb> kaffe works fine with freenet +00:55 < bpb> evil GPL ware +00:55 < Aprogas> nop: i think the problem with the IIP developers team is that they are a bunch of geeks who are coding a program for a bunch of other geeks +00:55 < bpb> anyway... shouldn't we be talking in #anonymous +00:55 < Aprogas> but it would be nice if IIP would also target different users +00:56 < bpb> Aprogas: umm, what do you think the first computers were, and look at them now ;) +00:56 < Aprogas> users who dont just want to explore the technology of being anonymous, but users who actually need being anonymous +00:56 < Aprogas> the first computers were used in the textile industry i think +00:59 < Rain> they were not really computers, though. more like automats. they could not actually process information, only act on a given program. progammed looms. +01:00 < Aprogas> are there any users on here who arent here just for the kick of being `anonymous' ? +01:00 * Debolaz isn't being anonymous here. +01:00 < Aprogas> debolaz: why are you here ? +01:00 < nemesis> me? +01:01 < Rain> i like the people, and i want to see how it turns out. +01:01 < Aprogas> bla +01:02 < Aprogas> you would whine too if you were in my position +01:02 < Aprogas> you fucking rats +01:02 < Kyfhon> Wah =[ +01:02 < nemesis> hrhr +01:02 < mateofree> what was that?!? +01:02 < nemesis> "<Aprogas> you would whine too if you were in my position" +01:02 < nemesis> what he mean with this? +01:03 < Kyfhon> He prolly needs anonymity. Or something. +01:03 < mateofree> I might have an idea for logo +01:03 < mateofree> mind if I throw it out here? +01:04 < Rain> go ahead man.. +01:04 < mateofree> ok +01:05 < mateofree> well I thought maybe a head either in profile or from front.. +01:05 < mateofree> with one side dissolving into ones and zeros +01:06 < Rain> might look nice, but what is the "iip specific" thing of it? +01:06 < mateofree> hehe don´t know +01:06 < mateofree> hello fw +01:06 < mateofree> the eye is closed btw +01:07 < Fairwitness> the eye? +01:07 < mateofree> so there is some allusion to "invisible" "not seen" +01:07 < mateofree> hehe +01:07 < Rain> hmm, that might work. +01:07 < Kyfhon> Submarine dissolving into (1|0)'s +01:07 < Fairwitness> your talking about a logo? +01:07 < Rain> pehaps a question mark somewhere.. +01:07 < mateofree> don´t go anywhere, I will upload it +01:07 < mateofree> I have a scetch +01:08 < mateofree> have to log first +01:08 < mateofree> brb +01:08 < Gilles2Rais> hey about dcc on iip irc, perhaps freenet could be used +01:09 < Kyfhon> It would take years to send a file :> +01:09 < Gilles2Rais> hum not really !! +01:09 < Kyfhon> Well, not _that_ long +01:09 < Gilles2Rais> a irc command could be used for trading the key +01:09 < Kyfhon> Might as well just give out refs +01:10 < Gilles2Rais> simulating a dcc +01:10 < Rain> does anyone know if there is any project +01:10 < Rain> to make a native freenet node implementation? +01:10 < Kyfhon> That would be nice +01:11 < Rain> the last one died, but now that 0.5 is actually released +01:11 < Kyfhon> Isn't there a java compiler that outputs native bins? +01:11 < Rain> yeah, but i belive i read that there was some misc trouble with it +01:11 < Rain> ie, the process is not perfect +01:11 < Kyfhon> Hm +01:15 * Kyfhon has to scram +01:17 < mateofree> check here: http://briefcase.yahoo.com/mateo_freeman +01:18 < mateofree> in IIP sketch folder +01:20 < Fairwitness> What's this image proposed for Mateo? +01:20 < mateofree> IIP logo +01:20 < mateofree> just an idea I got +01:20 < mateofree> just now +01:21 < Fairwitness> can you explain the image? +01:21 < mateofree> well, it is a head either in profile or from front, with closed eye +01:21 < mateofree> and one side dissolves into ones and zeros +01:22 < Fairwitness> ahhh.. I could see that it was disolving but not what into +01:22 < mateofree> oh, well I did it fast so... +01:22 < mateofree> just to get the idea out, hehe +01:23 < mateofree> don´t know if it is proper though +01:23 < mateofree> might be too ambigous +01:24 < mateofree> might work though as a t shirt logo though +01:24 < mateofree> a little one on chest or somethign +01:24 < Fairwitness> might be a bit detailed for a tshiort +01:24 < Fairwitness> I think it is a great idea and woudl love to see you develop it. +01:24 < mateofree> well, I was thinking of simplyfying it +01:25 < mateofree> with more clean lines +01:25 < Fairwitness> Kool. +01:25 < mateofree> I kind of like the profle one +01:25 < mateofree> profile +01:25 < Fairwitness> that's much better for screen printing... +01:26 < mateofree> yes +01:26 < mateofree> maybe something with lines, as in that picture is better than ones and zeros +01:26 < mateofree> might be too small to see +01:26 < mateofree> ones and zeros that is +01:27 < Fairwitness> I lik ethe fading to 1's and 0's idea... +01:28 < mateofree> yes.. but would maybe be to small for something like t shirt? +01:28 < mateofree> the "point" is though the shut eye +01:28 < mateofree> that is what ties to invisible +01:30 < Rain> i actually like the sound of that. simple enought. together with the "iip" text, it will be pretty obvious, even to a non techie. they might not now what a "proxy" is, but "invisible" and "net" should be prettey obvious. +01:31 < Rain> heh, a "closed eye" is kinda the opposite of the "lidless eye" from LOTR... +01:31 < mateofree> hehe +01:32 < mateofree> hmm, maybe an open eye over a pyramid might be better..... ;) +01:33 < Rain> hmm, that seems kinda familiar.... +01:33 < Gilles2Rais> hu my job is graphism and 3d so if u need ... +01:33 < mateofree> cool +01:33 < Rain> (note to self: learn to spell) +01:33 < Gilles2Rais> u could find my gallery at : +01:33 < Gilles2Rais> (just wait :) +01:33 < mateofree> what programs du you use? +01:33 < mateofree> for 3d +01:34 < Rain> can you accentuate the closed eye, make the face look "calm"? +01:34 < Gilles2Rais> http://www.renderosity.com/gallery.ez?ByArtist=Y&Artist=delly +01:34 < Gilles2Rais> im using rhino for modelling +01:34 < Rain> in the the current scetch he looks to be somewhat in pain ;) +01:34 < mateofree> wow cool +01:34 < Gilles2Rais> render with pov bmrt or lightwave +01:34 < mateofree> I owbn rhino too +01:34 < Gilles2Rais> or flamingo +01:34 < Gilles2Rais> rhino is soooooo cool +01:34 < Gilles2Rais> the best for me +01:35 < mateofree> yeah +01:35 < Gilles2Rais> and im using only one +01:35 < Gilles2Rais> rhino +01:35 < mateofree> I used to do 3d some years ago +01:35 < Gilles2Rais> have u and url where I could see the actual logo +01:35 < mateofree> also used truespace +01:35 < Gilles2Rais> yes ive tried it +01:35 < Gilles2Rais> ive luv the cinema 4d rendering too +01:36 < Gilles2Rais> actually for fast done animation I prefer moray 303 +01:36 < Gilles2Rais> and lightwave for not fast done :) +01:36 < mateofree> oh btw did you see my post on dc? +01:36 < mateofree> about 3d plugin to 3dmax +01:37 < mateofree> http://www.eyematic.com/products_facestation.html +01:37 < mateofree> now that is cool +01:37 < Gilles2Rais> have u try brazil ? +01:37 < mateofree> nope, what is that? +01:37 < Gilles2Rais> woo I luv it too but all tried beta was so bugged +01:37 < Gilles2Rais> the better render engine +01:38 < Gilles2Rais> (for me :) +01:38 < mateofree> cool +01:38 < mateofree> hehe +01:38 < Gilles2Rais> splutterfish.com +01:38 < Gilles2Rais> I guess +01:38 < Gilles2Rais> Video In. Facial Animation Out. It's That Simple. +01:38 < Gilles2Rais> its ur artcile +01:38 < mateofree> snow desert was very cool +01:38 < Gilles2Rais> article +01:38 < mateofree> what program did you use for it? +01:38 < mateofree> cool +01:39 < Gilles2Rais> dont know this +01:39 < Gilles2Rais> http://www.neilblevins.com/artgallery/gallery_brazil.htm +01:40 < Gilles2Rais> see and cry :) +01:40 < Gilles2Rais> http://splutterfish.com/sf/Images/img_c02_glassc.jpg +01:40 < mateofree> your gallery was very cool +01:40 < Gilles2Rais> thx +01:40 < Gilles2Rais> but it seems lots pictures are 404 :( +01:41 < Gilles2Rais> I luv this http://splutterfish.com/sf/Images/img_c06_delphipaw_marbles_on_rails_DOF3-3.jpg +01:41 < mateofree> wow! +01:41 < mateofree> that was very cool +01:42 < mateofree> brb +01:43 < mateofree> back +01:44 < mateofree> what I really like about rhino and truespace is price +01:44 < mateofree> very good price/value +01:44 < Gilles2Rais> yep true +01:44 < Gilles2Rais> so much features +01:45 < mateofree> yeah +01:45 < Gilles2Rais> have u try flamingo too ? +01:45 < mateofree> truespace is amazing +01:45 < mateofree> nope +01:45 < Gilles2Rais> its great and too easy to use materials +01:45 < mateofree> only have rhino 1. something and truespace 4. something +01:45 < Gilles2Rais> but slow +01:45 < mateofree> haven´t used them in years +01:45 < Gilles2Rais> truespace have nice render and seems fast +01:46 < Fairwitness> Sorry to split in the middle of a conv Mateo but I had to get the phone.. +01:46 < Gilles2Rais> rhino 3 beta is available +01:46 < mateofree> I like that truespace is a complete package +01:46 < Fairwitness> I agree with the previous commment that the face looks quite unhappy. +01:46 < mateofree> hehe np fw +01:46 < mateofree> ofcourse it is unhappy, having to hide away from the statists, hehe +01:46 < Gilles2Rais> have u and url I could see the actuall iip logo +01:46 < Fairwitness> Do either of you have PalmS? +01:47 < Fairwitness> PDA's that is? +01:47 < mateofree> nope +01:47 < mateofree> gilles du you mean: http://www.invisiblenet.net/iip/ +01:47 < mateofree> or my example? +01:48 < Fairwitness> bummer :) +01:48 < Fairwitness> I have a palm addiction... I found an excellent drawing program for Plam OS +01:48 < Fairwitness> I LOVE your gallery Gilles2Rais!! +01:48 < mateofree> cool +01:48 < mateofree> the palms are really cool +01:49 < Fairwitness> I use it a lot as it is great t be able to have coloured drawing tools wherever I go +01:49 < Fairwitness> and it can print the images at ANY size with no loss of quality as it is vector based +01:49 < mateofree> yeah I bet +01:50 < mateofree> I have a wacom drawing tablet, very cool +01:50 < Gilles2Rais> I need it +01:50 < Gilles2Rais> but my mouse is terrible :) +01:50 < mateofree> I guess palm is kind of like it +01:50 < mateofree> hehe +01:50 < Fairwitness> I nearly bought one of them... +01:50 < mateofree> yeah drawing witgh mouse is ipossible for me +01:50 < Fairwitness> but I bought a film scanner instead +01:51 < Fairwitness> I don't do a lot of drawing.. mostly photos. +01:51 < Fairwitness> and retouching is ok with a mouse... but a tblet woud be better +01:51 < mateofree> yeah +01:51 < mateofree> it is pretty amazing really +01:52 < mateofree> you think it might be weird but it is very intuitive +01:52 < Fairwitness> I will console myself with the fact that I LOVE my film scanner :0 +01:52 < Fairwitness> though now i have got a digital camera... +01:53 < mateofree> hehe what model is it? +01:53 < mateofree> oh yeah an ixus right? +01:53 < mateofree> those are cool +01:53 < Fairwitness> I know this probably sounds silly but I didn;t get a tablet because i just have no more desk space +01:53 < Fairwitness> yeah +01:53 < Fairwitness> it is ok for stuff to go on the web +01:53 < mateofree> lol +01:53 < Fairwitness> but big prints are a bit suboptimal +01:54 < mateofree> yeah +01:54 < Fairwitness> nothing like film for resolution.. +01:54 < Fairwitness> but I am OVER the chemicals. +01:54 < mateofree> well..... +01:54 < Fairwitness> I will soon be putting up the kipbetbot page whic has some nice shots on it... +01:54 < mateofree> price is a bit to high right now but there are very good alternatives +01:55 < mateofree> for digital cams +01:55 < Fairwitness> true, but I am waiting... I think there will be a big jump in quality soon. +01:55 < mateofree> for about 2000 dollars you can get a digital cam as good as 35mm film +01:55 < mateofree> yeah +01:55 < Fairwitness> and I want one of the decents lens makers to come up with an really goood digital camera... +01:56 < Fairwitness> ...but lenses...? +01:56 < mateofree> oh the proffesional ones are compatible with standard lenses +01:56 < Fairwitness> resolution on the screen is nice... but oyu need the lenses ot get good images to utilise the high res +01:56 < Fairwitness> still too expensive though.. +01:57 < mateofree> yeah +01:57 < mateofree> but if trends are going as lately it will be cheap soon +01:57 < Fairwitness> anyway I am supposed ot be working... gotta go... +01:57 < mateofree> ok bye +01:58 < Fairwitness> I hope so.. I'm counting on prices falling ... +01:58 < Fairwitness> see you later +01:58 < mateofree> http://www.luminous-landscape.com/reviews/cameras/d60/d60.shtml +01:58 < mateofree> save that for later +01:58 < mateofree> good review of canon d60 +02:30 < Gilles2Rais> cya all +07:14 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback +07:14 [Users #iip-dev] +07:14 [ CwZ|away] [ epoch ] [ jeremiah] [ nemesis] [ ptm ] [ UserX] +07:14 [ Debolaz2] [ icepick-work_] [ logger ] [ pox ] [ ptsc] +07:14 -!- Irssi: #iip-dev: Total of 11 nicks [0 ops, 0 halfops, 0 voices, 11 normal] +07:14 -!- Irssi: Join to #iip-dev was synced in 2 secs +08:45 * nemesis is away: sleeps +--- Log closed Wed Nov 27 10:49:36 2002 diff --git a/i2p2www/meetings/logs/21.rst b/i2p2www/meetings/logs/21.rst new file mode 100644 index 00000000..ca4dddd1 --- /dev/null +++ b/i2p2www/meetings/logs/21.rst @@ -0,0 +1,9 @@ +I2P dev meeting, November 26, 2002 @ 23:00 UTC +============================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/www.i2p2/pages/meeting210.html b/i2p2www/meetings/logs/210.log similarity index 98% rename from www.i2p2/pages/meeting210.html rename to i2p2www/meetings/logs/210.log index e4650547..1e1ad9a4 100644 --- a/www.i2p2/pages/meeting210.html +++ b/i2p2www/meetings/logs/210.log @@ -1,35 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 210{% endblock %} -{% block content %}<h3>I2P dev meeting, November 27, 2012</h3> -<div> -<h4>Quick recap</h4> -<ul> - <li><b>Present:</b> - - christop1, - darrob, - dg, - hottuna, - KillYourTV, - LaughingBuddha, - RN, - Schnaubelt, - str4d, - topiltzin, - weltende - </li> - <li> - <b>Next Meeting</b> - <p> - The next meeting is scheduled for Tuesday, December 4 @ 20:00 UTC (8:00PM) - </p> - </li> -</ul> -</div> -<div class="irclog"> -<h4>Full IRC Log</h4> -<pre> -{% filter escape %} 19:33:46 <dg> Alrighty. 19:33:49 <dg> So, today's agenda is: 19:33:52 <dg> 0) Hi @@ -459,8 +427,3 @@ 21:48:53 * dg notes 21:49:00 <str4d> Yep. So not finished yet =P 21:49:30 <dg> *baf*s -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/210.rst b/i2p2www/meetings/logs/210.rst new file mode 100644 index 00000000..a27f8b26 --- /dev/null +++ b/i2p2www/meetings/logs/210.rst @@ -0,0 +1,21 @@ +I2P dev meeting, November 27, 2012 @ 19:30 UTC +=============================================== + +Quick recap +----------- + +* **Present:** + christop1, + darrob, + dg, + hottuna, + KillYourTV, + LaughingBuddha, + RN, + Schnaubelt, + str4d, + topiltzin, + weltende + +* **Next Meeting** + The next meeting is scheduled for Tuesday, December 4 @ 20:00 UTC (8:00PM) diff --git a/www.i2p2/pages/meeting211.html b/i2p2www/meetings/logs/211.log similarity index 96% rename from www.i2p2/pages/meeting211.html rename to i2p2www/meetings/logs/211.log index 62d4f38e..0845fd1e 100644 --- a/www.i2p2/pages/meeting211.html +++ b/i2p2www/meetings/logs/211.log @@ -1,33 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 211{% endblock %} -{% block content %}<h3>I2P dev meeting, December 4, 2012 @ 20:00 UTC</h3> -<div> -<h4>Quick recap</h4> -<ul> - <li><b>Present:</b> - - dg, - hottuna, - KillYourTV, - lillith, - Meeh, - psi, - str4d, - weltende, - zzz - </li> - <li> - <b>Next Meeting</b> - <p> - The next meeting is scheduled for Tuesday, December 11 @ 20:00 UTC (8:00PM) - </p> - </li> -</ul> -</div> -<div class="irclog"> -<h4>Full IRC Log</h4> -<pre> -{% filter escape %} 20:18:53 * KillYourTV has noticed that we're 17 minutes into the meeting...and we're off to a quiet start... 20:19:31 <lillith> i was wondering that, did i also get the wrong time or something? 20:20:23 * dg is waiting for self to be free @@ -261,8 +231,3 @@ 22:28:10 * psi lag 22:28:55 <lillith> Meeh, to be decided, maybe before since this one wasn't a great success 22:29:25 <Meeh> true true, next week then -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/211.rst b/i2p2www/meetings/logs/211.rst new file mode 100644 index 00000000..c0746a65 --- /dev/null +++ b/i2p2www/meetings/logs/211.rst @@ -0,0 +1,19 @@ +I2P dev meeting, December 4, 2012 @ 20:00 UTC +============================================== + +Quick recap +----------- + +* **Present:** + dg, + hottuna, + KillYourTV, + lillith, + Meeh, + psi, + str4d, + weltende, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, December 11 @ 20:00 UTC (8:00PM) diff --git a/www.i2p2/pages/meeting212.html b/i2p2www/meetings/logs/212.log similarity index 89% rename from www.i2p2/pages/meeting212.html rename to i2p2www/meetings/logs/212.log index e82fa34a..23a705cc 100644 --- a/www.i2p2/pages/meeting212.html +++ b/i2p2www/meetings/logs/212.log @@ -1,31 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 212{% endblock %} -{% block content %}<h3>I2P dev meeting, December 11, 2012 @ 20:00 UTC</h3> -<div> -<h4>Quick recap</h4> -<ul> - <li><b>Present:</b> - - lillith, - Meeh, - postman, - psi, - str4d, - topiltzin, - zzz - </li> - <li> - <b>Next Meeting</b> - <p> - The next meeting is scheduled for Tuesday, December 18 @ 20:00 UTC (8:00PM) - </p> - </li> -</ul> -</div> -<div class="irclog"> -<h4>Full IRC Log</h4> -<pre> -{% filter escape %} 20:20:09 <str4d> <str4d> Not sure where dg is, so I propose that we get the meeting started anyway, continuing on with the agenda from last week (or restarting it if necessary). 20:20:09 <str4d> (http://zzz.i2p/posts/5779) 20:20:18 <iRelay> Title: zzz.i2p: IRC Meetings (at zzz.i2p) @@ -99,8 +71,3 @@ 22:07: <lillith> i'l leave this to dg , presumably it will be 8.00 UTC next tuesday (18th) 22:08: <lillith> topiltzin, i'l take a look 22:09: <lillith> I'd say this meeting is now officially over then :) -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/212.rst b/i2p2www/meetings/logs/212.rst new file mode 100644 index 00000000..8502917d --- /dev/null +++ b/i2p2www/meetings/logs/212.rst @@ -0,0 +1,17 @@ +I2P dev meeting, December 11, 2012 @ 20:00 UTC +=============================================== + +Quick recap +----------- + +* **Present:** + lillith, + Meeh, + postman, + psi, + str4d, + topiltzin, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, December 18 @ 20:00 UTC (8:00PM) diff --git a/www.i2p2/pages/meeting213.html b/i2p2www/meetings/logs/213.log similarity index 98% rename from www.i2p2/pages/meeting213.html rename to i2p2www/meetings/logs/213.log index cf045678..f468ac1c 100644 --- a/www.i2p2/pages/meeting213.html +++ b/i2p2www/meetings/logs/213.log @@ -1,32 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 213{% endblock %} -{% block content %}<h3>I2P dev meeting, December 18, 2012 @ 20:00 UTC</h3> -<div> -<h4>Quick recap</h4> -<ul> - <li><b>Present:</b> - - Astral_12, - eche|on, - KillYourTV, - LaughingBuddha, - RN, - str4d, - topiltzin, - zzz - </li> - <li> - <b>Next Meeting</b> - <p> - The next meeting is scheduled for Tuesday, January 8 @ 20:00 UTC (8:00PM) - </p> - </li> -</ul> -</div> -<div class="irclog"> -<h4>Full IRC Log</h4> -<pre> -{% filter escape %} 20:08:58 <RN> meeting start while I was disconnected? 20:09:17 <eche|on> which meeting? 20:09:38 * KillYourTV points to the topic @@ -409,8 +380,3 @@ 00:08:13 <topiltzin> and thanks to KillYourTV and sighup-bot__ for the logs :) 00:13:54 <zzz> pfft. didnt know we were still in the meeting :) 00:26:40 <topiltzin> just zoned back in :) back seat was so cozy I spaced out a little -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/213.rst b/i2p2www/meetings/logs/213.rst new file mode 100644 index 00000000..2ff888ca --- /dev/null +++ b/i2p2www/meetings/logs/213.rst @@ -0,0 +1,18 @@ +I2P dev meeting, December 18, 2012 @ 20:00 UTC +=============================================== + +Quick recap +----------- + +* **Present:** + Astral_12, + eche|on, + KillYourTV, + LaughingBuddha, + RN, + str4d, + topiltzin, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, January 8 @ 20:00 UTC (8:00PM) diff --git a/www.i2p2/pages/meeting214.html b/i2p2www/meetings/logs/214.log similarity index 98% rename from www.i2p2/pages/meeting214.html rename to i2p2www/meetings/logs/214.log index c40b986c..51f17d9d 100644 --- a/www.i2p2/pages/meeting214.html +++ b/i2p2www/meetings/logs/214.log @@ -1,34 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 214{% endblock %} -{% block content %}<h3>I2P dev meeting, January 8, 2013 @ 21:00 UTC</h3> -<div> -<h4>Quick recap</h4> -<ul> - <li><b>Present:</b> - - christoph, - dg, - h2ik, - KillYourTV, - orion, - primal, - RN, - str4d, - welterde, - zzz - </li> - <li> - <b>Next Meeting</b> - <p> - The next meeting is scheduled for Tuesday, January 15 @ 20:00 UTC (8:00PM) - </p> - </li> -</ul> -</div> -<div class="irclog"> -<h4>Full IRC Log</h4> -<pre> -{% filter escape %} 21:02:22 <str4d> Alright, I'm going to go ahead and start the meeting. 21:02:29 <str4d> 0) Say hi 21:02:29 <str4d> 1) Feeds progress @@ -559,8 +528,3 @@ 00:51:07 <str4d> \o/ 00:51:14 <orion> \o\ \o/ /o/ 00:51:29 <str4d> *wub wub* -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/214.rst b/i2p2www/meetings/logs/214.rst new file mode 100644 index 00000000..dc5b0281 --- /dev/null +++ b/i2p2www/meetings/logs/214.rst @@ -0,0 +1,20 @@ +I2P dev meeting, January 8, 2013 @ 21:00 UTC +============================================ + +Quick recap +----------- + +* **Present:** + christoph, + dg, + h2ik, + KillYourTV, + orion, + primal, + RN, + str4d, + welterde, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, January 15 @ 20:00 UTC (8:00PM) diff --git a/www.i2p2/pages/meeting215.html b/i2p2www/meetings/logs/215.log similarity index 96% rename from www.i2p2/pages/meeting215.html rename to i2p2www/meetings/logs/215.log index 864ad986..cb22ffd9 100644 --- a/www.i2p2/pages/meeting215.html +++ b/i2p2www/meetings/logs/215.log @@ -1,34 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 215{% endblock %} -{% block content %}<h3>I2P dev meeting, January 15, 2013 @ 20:00 UTC</h3> -<div> -<h4>Quick recap</h4> -<ul> - <li><b>Present:</b> - - darrob, - dg, - eche|on, - hottuna, - KillYourTV, - LaughingBuddha, - orion, - sponge, - welterde, - zzz - </li> - <li> - <b>Next Meeting</b> - <p> - The next meeting is scheduled for Tuesday, January 22 @ 20:00 UTC (8:00PM) - </p> - </li> -</ul> -</div> -<div class="irclog"> -<h4>Full IRC Log</h4> -<pre> -{% filter escape %} 20:02:07 <hottuna> dg, is there a meeting today 20:02:26 <LaughingBuddha> oh yeah, it's tuesday 20:02:56 <hottuna> str4d, Meeh: is the meeting now? @@ -284,8 +253,3 @@ 21:23:52 <hottuna> See you next week, same time. 21:23:52 <hottuna> baf's 21:24:12 <dg> huzzah -{% endfilter %} -{# TODO: pygments #} -</pre> -</div> -{% endblock %} diff --git a/i2p2www/meetings/logs/215.rst b/i2p2www/meetings/logs/215.rst new file mode 100644 index 00000000..c07733b9 --- /dev/null +++ b/i2p2www/meetings/logs/215.rst @@ -0,0 +1,20 @@ +I2P dev meeting, January 15, 2013 @ 20:00 UTC +============================================= + +Quick recap +----------- + +* **Present:** + darrob, + dg, + eche|on, + hottuna, + KillYourTV, + LaughingBuddha, + orion, + sponge, + welterde, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, January 22 @ 20:00 UTC (8:00PM) diff --git a/i2p2www/meetings/logs/216.log b/i2p2www/meetings/logs/216.log new file mode 100644 index 00000000..7b810118 --- /dev/null +++ b/i2p2www/meetings/logs/216.log @@ -0,0 +1,378 @@ +20:07:05 <hottuna_> Alright, meeting-time? +20:07:27 <str4d> o/ +20:08:28 <RN-> tjink so +20:08:41 <hottuna_> eche|on, zzz, dg: ping +20:09:46 <hottuna_> let's wait until 20:15 and see if dg shows up. +20:10:21 <RN-> did everyone read zzz homework assignment? +20:10:36 <hottuna_> yepyep +20:11:28 <RN-> was over my head +20:11:31 <str4d> Okay, looks like the three meeting topics are ugha.i2p, the website revamp and the crypto. Anything else we want to cover? +20:11:50 <hottuna_> I think that is more than enough +20:11:58 <str4d> Alright: +20:12:01 <RN-> read it tho +20:12:04 <str4d> (0) Say Hi. +20:12:11 <str4d> (1) Ugha.i2p +20:12:18 <str4d> (2) Website revamp +20:12:29 <str4d> (3) Crypto discussion +20:12:32 <str4d> (0) Say Hi. +20:12:35 <str4d> Hi! +20:13:00 <RN-> hi +20:13:07 <hottuna_> hello everybody! +20:14:44 <RN-> we waiting 4 zzz and ech? +20:15:21 <hottuna_> I think we can manage until the crypto part +20:15:27 <str4d> eche|on was around an hour ago; zzz tends to speak when he needs to. +20:15:27 <RN-> guess they r at end... +20:15:49 <hottuna_> weltende, welterde, eche|on: ping, re new website +20:15:52 <hottuna_> altight +20:15:58 <RN-> anyone got the baffer? +20:15:58 <str4d> And everyone else can turn up when they do ^_^ +20:16:05 <str4d> (1) Ugha.i2p +20:16:05 <hottuna_> So.. ugha? +20:16:08 <str4d> o/ +20:16:39 <zzz> here, standing by until 3), if it's reasonbly fast +20:16:52 <hottuna_> Alright, I posted a content-request page last week +20:16:52 <hottuna_> syndie/imule content was requested +20:16:59 <hottuna_> and has as far as I can see been submitted +20:17:18 * str4d can +20:17:29 <str4d> 't actually load ugha right now =P +20:17:41 <str4d> Do we know who runs ugha? +20:18:04 <hottuna_> I don't +20:18:23 <hottuna_> do we have any further ideas about what to change/add to ugha? +20:18:31 <str4d> Because it would be useful to get some proper spam protection if possible. +20:18:38 <eche|on> we do partly know/guess who runs it. but it will not be disclosured here +20:18:47 <eche|on> and owner did not respond yet +20:18:54 <dg> Okay, hey +20:18:57 <str4d> eche|on: fair enough. +20:18:57 <eche|on> ugha.i2p was cleaned from spam +20:19:09 <str4d> eche|on: how much work was that? +20:19:12 <eche|on> and I added a site about iMule and syndie, KillYourTV added a bit more +20:19:30 <eche|on> spam? a lot, it was >200 or even >400 spam messages to be removed +20:19:38 <eche|on> they appeared in 2 years time +20:20:09 <str4d> And just manually removed? +20:20:24 <hottuna_> did it appear over the inproxy? +20:20:35 <dg> I was wondering this +20:20:50 <dg> sorry for being late although I managed to get here :) +20:20:53 <eche|on> yea, str4d, click each spam site, click delete site, click yes, I want to remove, click next spam site +20:21:08 <eche|on> and IMHO it is on INproxy. +20:21:27 <eche|on> yeah, it is +20:21:58 <eche|on> http://ugha.i2p.to/RecentChanges +20:22:01 <hottuna_> alright, maybe it shouldnt be accessible over the inproxy? +20:22:15 <RN-> so... set read omly for inproxy? +20:22:15 <eche|on> maybe someone want to count the "delete" pictures ;-) +20:23:34 <hottuna_> is it possible to notify the admin via the the wiki? +20:23:45 <eche|on> guess not +20:23:48 <hottuna_> a read-only via inproxy rule would probably be good +20:23:51 <hottuna_> ok +20:24:06 <hottuna_> eche|on, but you know who? you could do it? +20:24:28 <eche|on> I cannot do anything on it, I am just a user like anyone else +20:24:43 <dg> The person obviously is not active. +20:24:46 <dg> So.. maybe still no. +20:24:51 <eche|on> all I can do is asking tino (i2p.to owner) to block it. +20:25:18 <hottuna_> is blocking it entirely an acceptable solution? +20:26:01 <eche|on> yes +20:26:05 <dg> not long term +20:26:30 <RN-> I agree with dg +20:26:44 <eche|on> it is a wiki. It needs active administration to remove unwatned content +20:26:44 <hottuna_> i think blocking it is acceptable.. since it only is of use to people who are already using i2p +20:26:57 <eche|on> but as we also have active spammers inside of I2P.... +20:26:57 <zzz> tino's not going to take action unless the owner requests it +20:27:04 <zzz> at least, he shouldnt. +20:27:41 <hottuna_> eche|on, could you contact the owner? +20:27:52 <eche|on> currently I visit ugha.i2p daily and remove the spam +20:28:15 <eche|on> hottuna_: I did contact via IRC and email already. now it is time for person to react. +20:28:38 <zzz> if it continues to be an embarassment we can take it out of the router console, whether we have a replacement or not +20:28:41 <eche|on> you know, we´ve seen same problem with forum.i2p already. thats the problem inside of I2P +20:28:48 <hottuna_> regarding blocking from i2p.to? +20:29:02 <eche|on> regarding active admin jobs on it +20:29:25 <hottuna_> ok +20:29:58 <hottuna_> anyway, if you manage to get some response, ask about blocking +20:31:01 <RN-> tino is not only inproxy anymore +20:31:43 <dg> Yeah. +20:32:01 <str4d> Aside from the spam issue, is there any content that ugha should have/needs updated> +20:32:29 <dg> Yes. +20:32:29 <eche|on> I had a look at the russian wiki. Thats a nice nice nice one +20:32:44 <str4d> From /Requests - "More advanced i2p config options and explanations." - hottuna_ you already added some of these, right? +20:32:44 <eche|on> it is really filled with good content and structured. but in russian. +20:32:44 <str4d> eche|on: link? +20:32:53 <hottuna_> what's the url for the russian wiki? +20:33:12 <hottuna_> str4d, yes. And I found a similar list on echelon.i2p +20:33:24 <eche|on> if I find it again... +20:34:10 <eche|on> imho rus.i2p +20:34:56 <eche|on> but more explanation about advanced config is nice +20:34:59 <str4d> Ooh, that *is* a nice wiki. +20:36:25 <eche|on> to sad I am a bit out of time, but if I get the chance, I do a few bits +20:36:32 <RN-> looks like it's using the same nice clean interface as cake why TV on his Cindy page +20:36:42 <dg> is it in english? +20:36:45 <RN-> I'll have to leave in about 10 minutes or less catch up with the rest of the meeting on my scroll back... +20:38:21 <str4d> Are there any other major points about ugha.i2p that need raising? +20:38:36 <hottuna_> no. +20:38:47 <hottuna_> I updated the request site +20:39:50 <str4d> The /I2pRfc page could do with updates, if it is/was ever planned to be authoritative (though the website is probably the better place for specs). +20:40:26 <dg> ugha.i2p has a lot of content which could be added or update +20:40:33 <dg> it seems to have more information about i2p's past and old tech documents than anywhere else +20:41:19 <str4d> Summary so far: spam is (currently) under control but needs active policing; there are numerous old pages that would be good to get updated (a good task for people who like writing). +20:41:34 <hottuna_> agreed. +20:41:41 <str4d> And if possible, the wiki should block edits from the inproxy. +20:41:56 <str4d> Anything else to add before we move on? +20:41:59 <dg> Is that all for the wiki then? +20:42:02 <dg> I don't think so +20:42:52 <str4d> dg: you want to do the honors? ^_^ +20:43:11 <dg> Alright :3 +20:43:15 <dg> thx +20:43:38 * str4d gets to talk lots in the next topic anyway =D +20:43:53 <dg> Okay, so the website revamp - I feel that the new design headed by str4d (he's doing the backend mostly but some CSS changes) brings a fresh look to i2p and can help refresh people's perspective and first impressions of it +20:44:00 <dg> The current one is rather stale, etc, etc.. +20:44:11 <dg> I think that we should look into what needs completing in order to push it live +20:44:34 <str4d> What *must* be completed before pushing live: +20:44:37 <dg> Minor issues can be worked on when it's out there so the blockers we need to consider here? +20:44:48 <str4d> - translation tagging +20:45:01 <str4d> (well, not *must* but most at the very least) +20:45:17 <str4d> - checking that all site-internal links are updated and valid +20:45:36 <str4d> That's basically it. +20:45:56 <hottuna_> how is translation tagging done? +20:46:07 <str4d> I've already started on that, and have covered most of the site pages (if you leave out the docs, which are large on their own) +20:46:22 <dg> Latter isn't too hard. There's tools for it IIRC but I can go around clicking (take one for the team ;) if push comes to shove. +20:46:33 <dg> Explain translation tagging? +20:46:40 <str4d> hottuna_: Jinja2 template tags +20:46:40 <str4d> And gettext PO files +20:47:05 <str4d> <h2>{% trans %}A Gentle Introduction to How I2P Works{% endtrans %}</h2> +20:47:08 <str4d> <p>{% trans -%} +20:47:08 <str4d> I2P is a project to build, deploy, and maintain a network supporting secure and anonymous +20:47:08 <str4d> communication. People using I2P are in control of the tradeoffs between anonymity, reliability, +20:47:11 <str4d> bandwidth usage, and latency. There is no central point in the network on which pressure can be +20:47:11 <str4d> exerted to compromise the integrity, security, or anonymity of the system. The network supports +20:47:11 <str4d> dynamic reconfiguration in response to various attacks, and has been designed to make use of +20:47:11 <str4d> additional resources as they become available. Of course, all aspects of the network are open and +20:47:11 <str4d> freely available. +20:47:15 <str4d> {%- endtrans %}</p> +20:48:17 <str4d> The tagged blocks get extracted into a messages.pot which can then be translated like the routerconsole is. +20:48:36 <str4d> That's another task that I think *must* be done before launch: +20:48:57 <str4d> - Migrate old translated pages (e.g. /how_intro_fr) to PO files +20:49:53 <hottuna_> ok +20:49:56 <hottuna_> whats the mtn repo name? +20:50:04 <hottuna_> alright +20:50:08 <str4d> That one I can't do much about =P I've migrated one page as a test, but I can't verify the accuracy of the old translations (especially as there was nothing to keep things in sync between the static pages) +20:50:12 <str4d> i2p.www.revamp +20:51:02 * str4d starts up the test site again +20:52:33 <str4d> Okay, http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/en/ is back up. +20:52:44 <iRelay> Title: I2P Anonymous Network (at vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p) +20:52:59 <str4d> Something else I've done is added mobile support to the website - you can see it by narrowing your browser window below 768px +20:53:34 <dg> What are we doing about blog/ +20:53:34 <dg> ? +20:53:45 <str4d> dg: what do you mean? +20:53:52 <str4d> (In what regard?) +20:54:04 <dg> Who will be blogging and how will we set it up? When will we blog also? :) +20:54:43 <str4d> At present the blog just contains the (old) release posts and the (much older) status posts. +20:54:54 <str4d> At the very least there will be the release posts as normal. +20:55:50 <str4d> That's a later issue though - we need to actually get the site finished first! +20:56:09 <hottuna_> agreed +20:56:20 <str4d> Ticket #807 does have a few things in it which would be good to get done, but are not blockers +20:56:32 <iRelay> http://trac.i2p2.i2p/ticket/807 - (accepted enhancement) - Revamp of website +20:56:44 <str4d> They are somewhat spread out through the ticket, but some are: +20:57:02 <str4d> - fill out /about/glossary +20:57:21 <str4d> - improve blog/meetings layout and styling +20:58:17 <str4d> - fix or replace the theme +20:58:36 <hottuna_> re translation tagging: is """{{ _('Friends of I2P') }}""" tagable in a straight forward manner +20:59:03 <str4d> hottuna_: That already is tagged. +20:59:26 <hottuna_> just curious about syntax +20:59:29 <str4d> (That's the more compact notation) +20:59:39 <hottuna_> aah +20:59:42 <str4d> {{ }} inserts the result of the contained Python method +20:59:53 <str4d> _() is the gettext call in Python +21:00:00 <str4d> (well, the one that is imported into Jinja2 +21:00:03 <str4d> ) +21:00:19 <hottuna_> thanks +21:00:34 <str4d> {% trans %}{% endtrans %} is a more verbose tag, but it's the Jinja2 tag and supports any content between the tags. +21:00:49 <str4d> (whereas the _() one can't contain e.g. ' +21:00:52 <hottuna_> what is left to tag? +21:01:13 <str4d> hottuna_: check the mtn log for details of what has been tagged, but IIRC: +21:01:44 <str4d> - get-involved/guides (I've tagged ides and dev-guidelines there) +21:01:55 <str4d> - misc/* +21:01:58 <str4d> - docs/* +21:02:09 <str4d> And then any blog posts that we want translated. +21:03:06 <str4d> (I've already migrated and tagged the 0.9.4 and 0.9.3 posts, and future posts can be tagged as well; earlier ones can be tagged as/when people can be bothered) +21:04:17 <str4d> Okay, we do need to get a move on in the meeting. +21:05:18 <str4d> Summary: site revamp is almost ready, help is appreciated getting the rest of the site tagged for translation and url-checked (can be done simultaneously) (thanks hottuna_ for offering to help (I assume that's what you are doing?)) +21:05:45 <str4d> And other text/layout changes are appreciated but not blocking. +21:06:31 <str4d> Oh: and if anyone wants to get started on translating the pages (using the old translated pages as reference or for copy-paste), *please do so*. +21:06:34 <str4d> Anything else? +21:06:49 <hottuna_> ill have a look at tagging +21:07:48 <str4d> hottuna_: thanks. Leave get-involved/guides to me, as I've already started in there. +21:08:43 <str4d> dg: are you keeping an eye on the meeting (timeliness)? +21:09:02 <dg> oh, sorry +21:09:14 <dg> So we're done with website/ +21:09:41 <dg> Crypto time :-D +21:10:16 <dg> Let me dig up the relevant topics +21:10:16 <dg> One moment +21:11:28 <dg> http://zzz.i2p/topics/1328 + http://zzz.i2p/topics/715 +21:11:38 <iRelay> Title: zzz.i2p: Meeting [22nd January] (at zzz.i2p) +21:12:10 <dg> TL;DR: We need to be discussing which components of the i2p router need to be changed in order of priority (or as zzz put it, "to talk generally about which uses are more vulnerable than others" +21:12:10 <dg> ) +21:12:17 <dg> (for the DSA change) +21:12:45 <dg> It's an apt time to discuss any other crypto changes that could be thrown in but right now, we should stick to what zzz suggested as it's a masssive rabbithole +21:12:52 <hottuna_> like noted in the tor cipher migration document we should strive to do changes where they are the most important and not necessarily the easiest +21:13:26 <dg> (https://gitweb.torproject.org/torspec.git/blob_plain/34ecac0fbac7f476bfcbf813767721fada62c17e:/proposals/ideas/xxx-crypto-migration.txt) +21:15:55 <hottuna_> in my mind the most important areas are those using potentially weak ciphers for longterm keys +21:16:39 <dg> hottuna_: I'm no crypto expert (and as such I'll stay out unless I know something) but aren't the longterm keys also the keys which could cause a flag day? +21:17:12 <hottuna_> changing most ciphers would cause a flag day +21:17:31 <dg> I was thinking all destinations being fucked +21:17:38 <dg> so yeah +21:17:41 <hottuna_> well basically +21:18:03 <hottuna_> i dont see a way around destinations being wrecked +21:19:03 <hottuna_> Im don't have a list of places where long-term keys are used +21:19:22 <hottuna_> but such a list and the corresponding cipher used should be created +21:21:04 <str4d> Agreed. We should also rank their perceived vulnerability. +21:21:11 <str4d> (This would make a good wiki page on Trac) +21:21:19 <hottuna_> yes. +21:22:02 <hottuna_> we should also create a list of ciphers that have been proven as safe (by the test of time) and are otherwise viable for us +21:22:17 <str4d> Section 2 of the Tor page basically applies to us as well. +21:22:20 <hottuna_> that list should include asymetric +21:22:55 <zzz> sounds good +21:23:11 <hottuna_> asymmetric* encryption, symmetric encryption, signatures and hmac ciphers that we trust +21:23:49 <zzz> how_cryptography page is a good reference +21:24:32 <hottuna_> str4d, did you start a wiki page or should I? +21:24:40 * str4d is doing so now +21:25:00 <str4d> /Crypto/CurrentSpecs sound alright? +21:25:09 <str4d> (For the summary table) +21:25:09 <hottuna_> sure +21:25:16 <zzz> DSA is a nice place to start analysis because it's easy to understand, and it's on the surface the weakest +21:26:15 <hottuna_> yes +21:27:01 <hottuna_> as for what is used where and what time periods which keys are used for I dont know much +21:28:56 <zzz> the OP on http://zzz.i2p/topics/715 has a list +21:29:03 <zzz> ~8 places we use DSA +21:29:05 <iRelay> Title: zzz.i2p: DSA 1024/160 Replacement (at zzz.i2p) +21:29:40 <hottuna_> the one with the longest validity is routerinfo? +21:30:23 <str4d> || '''Aspect/Location''' || '''Cipher used''' || '''Cipher details''' || ''' Perceived vulnerability''' || '''Comments''' +21:30:30 <str4d> Anything else that needs to go into the table? +21:30:30 <zzz> maybe dest. which isn't listed. +21:31:12 <zzz> theres both a dest key and a leaseset key I think the dest signs the leaseset and the leaseset key is unused +21:31:38 <hottuna_> str4d, validity period +21:32:24 <zzz> wouldnt be the end of the world to have a RI flag day but throwing out all 2500 in hosts.txt is another story +21:32:38 <str4d> Hmm... maybe the Perceived vulnerability / validity should be in a separate table then. +21:33:07 <zzz> datagrams is a problem, dests is a problem +21:33:22 <hottuna_> throwing out hosts is a huge issue. but it is also the most vulnerable key in my mind +21:34:37 <zzz> for each case we have to go farther though. not just how easy to break but what's the threat model / consequence. +21:35:08 <hottuna_> yes. maybe link to a separate page for each case? +21:35:26 <str4d> http://trac.i2p2.i2p/wiki/Crypto/CurrentSpecs now exists and has some basic content +21:35:33 <iRelay> Title: Crypto/CurrentSpecs – I2P (at trac.i2p2.i2p) +21:36:09 <zzz> and put that in perspective gven the size of the net, etc. e.g., we currently have a guy that claims he can shutdown an eepsite for 23 1/2 hours a day. +21:37:13 <hottuna_> christoph1, ? +21:37:25 <dg> Yikes. +21:37:28 <str4d> Mmm. +21:37:35 <dg> How does that work? +21:37:58 <hottuna_> eclipse attack on our floodfills +21:38:01 <christoph1> use enough precomputed routerinfos, put 10 bad nodes near the target hash block lookup +21:38:20 <lillith> why is it not 24 hours? +21:38:35 <christoph1> because midnight is a bit tricky +21:38:46 <christoph1> you can use another 10 to put in place for tomorrow +21:39:05 <christoph1> but there's still a period around the keyspace rotation where things are unstable +21:39:22 <lillith> so the router gets half an hour where the floodfills are uncertain? +21:39:33 <christoph1> (client can hit one of the good nodes by chance because it doesn't know all attackers jet +21:39:52 <str4d> The keys for the next day can be known in advance, so positioning malicious nodes could be planned in advance, no? +21:39:59 <christoph1> jep +21:40:22 <christoph1> still it seems around rotation it is somewhat unstable +21:40:49 <str4d> Anyway, this is somewhat off-track for this topic (sorry christoph1) +21:41:05 <christoph1> ack +21:43:08 <str4d> Okay, does anyone want to work on getting http://trac.i2p2.i2p/wiki/Crypto/CurrentSpecs filled out? +21:43:14 <iRelay> Title: Crypto/CurrentSpecs – I2P (at trac.i2p2.i2p) +21:43:26 <zzz> dg, please keep us on track, not drag us off it :) +21:43:42 <hottuna_> str4d, yeah. I just managed to log in :P +21:44:01 <str4d> Maybe we should quickly clarify what exactly we want on that page (my column headings are rather generic) +21:44:36 <dg> zzz: sory ;) +21:44:59 <str4d> First table: a summary of the crypto used in the router. Name, validity period, vulnerability... key length? Prime strength? +21:44:59 <zzz> m yfault too +21:45:48 <str4d> Second table: a list of every point in the router where crypto is used. Location and cipher name (of course). Usage details? What is important to know here? +21:46:27 <str4d> We can probably elaborate on separate pages for the second table if necessary (link the location name to a subpage) +21:47:41 <hottuna_> str4d, added subpage +21:48:06 <str4d> IMHO this should be a page that someone can glance at and understand the current state-of-play (whereas the site docs are the full specs) +21:48:32 <str4d> hottuna_: ah, I get what you mean by validity period now. +21:48:39 <hottuna_> :) +21:50:20 <str4d> hottuna_: there's already an entry for destinations - LeaseSet signing +21:50:29 <hottuna_> oh +21:50:29 <hottuna_> sorry +21:50:36 <str4d> (For the DSA part at least - I think you're thinking there of the encryption) +21:51:56 <str4d> Also, I'd call it "Security timescale" rather than "Validity period" +21:52:38 <hottuna_> yep +21:52:38 <zzz> FYI for everybody else - every RI and Dest has two keys, one for encryption and one for signing +21:53:11 <hottuna_> ok +21:53:11 <hottuna_> why? +21:53:32 <zzz> ElG was deemed far too slow for signing +21:54:44 <str4d> This might be a silly question, but how are the two keys "linked" verifiably? +21:55:23 <zzz> for both RI and Dest, the Hash covers both keys + the (usually null) Certificate +21:55:23 <hottuna_> a public key is derived from the private key +21:55:51 <zzz> change any of the 3 and you change the hash. +21:56:13 <str4d> Ah, k (you mean the Destination hash?) +21:56:23 <str4d> (i.e. the B64) +21:56:26 <zzz> yes +21:56:53 <str4d> Okay... the problem with upgrading the Destination crypto makes much more sense now... +21:56:59 <zzz> and for Dests, change any of the 3 and you need a new hosts.txt entry +21:58:34 <zzz> and (hint) non-null certs may be the path to upgrades w/ (partial) compatibility, i.e. not breaking gravity. That's what's covered further down in topic 715 +21:59:39 <str4d> Yeah - that enables both to work alongside each other. +22:00:09 <str4d> But it still means that the end-to-end crypto for the old Destinations is untouched. +22:00:52 <str4d> The point where the Dest crypto key is most important is the leg between the OPEP and IBGW, right? +22:01:26 <zzz> not sure +22:01:53 <zzz> other complication is there used to be two layers of end-to-end crypto, one in the router and one in the client, and some keys are now unused +22:02:32 <zzz> ditto w/ signing keys... one was for LS revocation and is unused +22:02:46 <zzz> so that's another opportunity, maybe +22:03:29 <str4d> http://www.i2p2.i2p/how_intro seems to indicate that the ElGamal/AES+SessionTags is used for end-to-end router encryption. +22:04:37 <zzz> crypto is much harder to discuss than signing. theres the ElG wrapping the AES and the Tags, together with the DH exchange. +22:05:35 <str4d> Yes. But as far as e.g. LeaseSets go, we probably need to discuss both in tandem, no? +22:05:46 <zzz> I'd suggest not even trying to get into the crypto side today. +22:05:53 <str4d> Not today, no. +22:06:00 <zzz> maybe, maybe not +22:06:03 <str4d> So, back on topic *derp* +22:06:30 <zzz> you change one key, you change the hash. But as the Tor doc says, don't try to change everything just because you're changing one thing +22:06:33 <str4d> What is the issue with Datagram signing? +22:07:12 <zzz> it's using our signing algorithm, i.e. DSA. Which we use to sign everything. (including suds) +22:07:54 <zzz> which also isn't on the list on topic 715, and might be the longest-lived key of all +22:09:04 <str4d> Right, but the specific problem I'm guessing with Datagrams is ensuring that routers can still talk to each other +22:09:04 <str4d> ? +22:10:00 <zzz> right. change signing and you break all RI and LS lookup, and all signed end-to-end communication +22:10:51 <zzz> because almost everything is signed +22:11:41 <str4d> So really the only way to move forward with upgrading the signing algorithm is to ensure that every place it is used can handle multiple signing algorithms? +22:12:27 <str4d> The problem then becomes knowing what versions are supported by a router (and the partitioning problems from the Tor doc are relevant here). +22:12:30 <zzz> but then every dest would need two sets of tunnels, one for old and one for new, afaik +22:12:49 <zzz> there's two kinds of compatibility to consider. +22:13:19 <str4d> That's a good point >_< +22:13:42 <zzz> 1) "network" compatibility, i.e. can the RIs and LSs be stored and retrieved, can msgs get thru tunnels, even if the ffs or participants are down-rev; +22:14:21 <zzz> 2) end-to-end compatibility, can A talk to B. For that, seems like both A and B need to support the same things +22:15:43 <str4d> 2) is "easy" to handle for direct router-to-router communication, as the router versions are public knowledge. What about end-to-end communication? +22:17:24 <zzz> the other thing is an RI has a whole Properties in it, we can put whatever flags we want in there +22:17:27 <str4d> Where would a router need to look to determine if another router (such as an eepsite server) supports the new signatures? +22:17:30 <zzz> nothing like that for LS +22:18:01 <zzz> certs is the magic +22:18:48 <zzz> in a cert we can spec both crypto and signing algo, and store the extra bytes if it doesnt fit in the first 384 +22:18:59 <zzz> again, that's the topic 715 stuff +22:19:53 <zzz> the cert has to start at byte 385 to not break 1) +22:20:54 <zzz> is that about enough for today? got out of this what you wanted? +22:21:09 <hottuna_> i think this is a beginning +22:21:34 <hottuna_> more specific issues and solutions cna be discussed and the wiki page used as an aid +22:23:50 <str4d> zzz: it's a good start - thank you =) +22:24:24 <zzz> lots of work ahead... +22:24:39 <str4d> Yes, but we have to start somewhere ^_^ +22:24:54 <hottuna_> str4d, pushed tags for monotone.html +22:25:05 <zzz> I had one more topic for the mtg but only if welt welterde weltende is around +22:25:26 <str4d> hottuna_: the one under get-involved/guides? I'll drop the ones I'd started putting in then ^_^ +22:25:37 <hottuna_> yes +22:26:00 <hottuna_> alright, are we done then? +22:26:11 <dg> I'd say so? +22:26:15 <str4d> I'd like to add a random point: +22:26:18 * dg had nothing to chime in with +22:26:21 <dg> not a crypto god +22:27:08 <str4d> I'd like to congratulate sponge on his efforts with Android - stock I2P now successfully runs on Android devices. +22:27:46 <str4d> And initial reports seem to indicate better performance and lower battery usage than I2P-Android +22:27:53 <hottuna_> that's quite the feat +22:28:04 <hottuna_> well done sponge +22:28:16 <hottuna_> i've gotta go now +22:28:23 <hottuna_> dg, will you strat the thread for next week? +22:28:27 <dg> spogne has done extremely well +22:28:56 <dg> Will do. Topics? Seems crypto needs to be a recurring topic for the next few weeks. :) +22:29:03 <dg> I should be here on time next week also +22:29:47 <str4d> If we can get the revamp tagged by then, we could potentially go live with the new site (though I would prefer to get actual translations in first) +22:30:18 <str4d> (Also depends on welterde being around) +22:30:25 <hottuna_> str4d, i think actual translations will take a very long time +22:30:52 <hottuna_> alright, nn ppl +22:30:59 <str4d> hottuna_: complete translations, yes. But there are already-translated pages (see www.i2p2/pages/translations) which would be quick to migrate. +22:31:07 <str4d> (For people who understand the language) +22:31:14 <str4d> o/ hottuna_ +22:31:45 * str4d *baf*s the meeting closed. diff --git a/i2p2www/meetings/logs/216.rst b/i2p2www/meetings/logs/216.rst new file mode 100644 index 00000000..943980a0 --- /dev/null +++ b/i2p2www/meetings/logs/216.rst @@ -0,0 +1,18 @@ +I2P dev meeting, January 22, 2013 @ 20:00 UTC +============================================= + +Quick recap +----------- + +* **Present:** + christoph1, + dg, + eche|on, + hottuna, + lillith, + RN, + str4d, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, January 29 @ 20:00 UTC (8:00PM) diff --git a/i2p2www/meetings/logs/217.log b/i2p2www/meetings/logs/217.log new file mode 100644 index 00000000..c9580f04 --- /dev/null +++ b/i2p2www/meetings/logs/217.log @@ -0,0 +1,96 @@ +20:08:14 <dg> so hi all +20:08:33 <dg> we didn't really talk much about the agenda but we have some big stuff to discuss anyhow so no big deal +20:08:55 <dg> first topic is the new website design and the blockers for getting it live +20:08:58 <dg> so i'll hand over to str4d +20:09:09 * dg passes metaphorical spotlight to str4d +20:09:20 <str4d> Hi! +20:09:27 <str4d> </ocd> +20:10:07 <str4d> Right, well I haven't had as much time over the last week to work on it, but the site *can* go live if desired. +20:10:26 <str4d> The blockers (that I see) are tagging the documentation for translations. +20:10:37 <str4d> Oh, and fixing URLs - that actually is a blocker. +20:10:48 <str4d> (I've been doing them at the same time). +20:11:45 <str4d> I've done the rest of the site - we just need to go through every page of the documentation and repeat what I've been doing: add translation tags to each paragraph/heading/list item/whatever, and check/correct the site-internal URLs. +20:12:29 <str4d> The other bit that I consider a blocker is getting the old translations migrated to the new format, i.e. going through the old faq_lang.html etc. pages and copying their text into the .po files as appropriate. +20:12:55 <dg> Translation tagging IMHO isn't a true blocker but something we need to finish soon, I don't know how you guys feel about going live without translations fully done +20:13:14 <str4d> (I've done 1.2 pages for de and 1 page for es as an example, but it really needs to be someone who understands the language, so that the copy-paste can be verified) +20:14:00 <str4d> (since there is no guarantee that the two individual pages have the same content) +20:15:52 <str4d> Design-wise, I'm starting to be more inclined to just leave the modified duck's theme there; it's had praise from quite a few people, including a designer. I'm personally still not happy with it (e.g. I find it a bit hard to read the long text passages in the documentation), but I wouldn't call it a blocker. +20:16:09 <dg> I like it more or less +20:16:40 <str4d> Oh - one bad thing currently is that the mobile CSS I added seems to not work on mobiles *derp* +20:16:52 <str4d> (Though it works quite nicely on a narrowed desktop browser) +20:19:26 <str4d> That's really about it for the site, as far as I can think of - it's functioning nicely, and most of the groundwork is in place. +20:19:41 <dg> I'll go check out for any broken links later +20:19:52 <dg> I found some previously +20:20:17 <str4d> dg: my test site is running the latest version, so you can check there. +20:20:32 <str4d> The only broken links should be in /lang/doc/* +20:20:35 <dg> let me dig up the ticket +20:20:38 <str4d> Every other page should be fine. +20:20:45 <str4d> It's ticket #807 +20:20:52 <dg> saved me some time :) +20:20:59 <iRelay> http://trac.i2p2.i2p/ticket/807 - (accepted enhancement) - Revamp of website +20:20:59 <dg> want to revisit this next week then? +20:23:38 <dg> Found one. +20:23:46 <dg> http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/en/docs/how/networkcomparisons from http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/en/docs/how/garlic-routing +20:23:49 <str4d> Oh, and /lang/misc/* hasn't been looked at either. +20:23:56 <iRelay> Title: Garlic Routing - I2P (at vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p) +20:24:06 <dg> Should be /en/comparison +20:24:12 <dg> sorry for pasting whole thing, won't do it again +20:24:15 <dg> eyerape +20:24:22 <str4d> dg: yep, that is a side-effect of my hypenating all the double-worded pages. +20:24:30 <str4d> Oh, that too. +20:25:09 <dg> /en/docs/how/garlic-routing has /en/docs/how/elgamalaes, should be /en/docs/how/elgamal-aes +20:25:16 <dg> i'll put them all into the ticket later +20:25:23 <dg> <+dg> want to revisit this next week then? +20:26:01 <str4d> I'm happy to. Anyone else want to comment? ^_^ +20:27:18 <Meeh> http://meeh.i2p/viewmtn/viewmtn.py/ +20:27:49 <dg> internal server error on http://meeh.i2p/viewmtn/viewmtn.py/branch/changes/i2p.i2p +20:28:45 <Meeh> yepp +20:28:48 <Meeh> working on it +20:28:55 <dg> I'll take it as a no, anyway +20:28:58 <dg> so onto .. crypto? +20:29:18 <str4d> One last question then: given the apparent level of apathy from people in here regarding copying over the old translations, would it be a better idea to just abandon them and upload the blank .po to Transifex? +20:29:44 <dg> Isn't Transifex reasonably active? +20:29:51 <str4d> The .po file will end up on Transifex anyway; I had just planned on it containing the old translations as a bit of a head start. +20:30:05 <dg> I'd say yes +20:30:48 <str4d> Any other votes? +20:32:38 <str4d> If we go with that, then I'll try and tag as many more pages as I have time for, and then I'll create .po files for the current website languages. Then someone with Transifex access can create an i2p.www subprojcet and upload them (KillYourTV?) +20:32:50 * psi reads scrollback +20:33:34 <psi> votes on a hackfest? +20:35:05 * psi reads more scrollback +20:39:01 <str4d> ... +20:39:04 * str4d doesn't like assuming, but assumes that no one has objections to that line of action. +20:39:04 <dg> too quiet >.> +20:39:04 <str4d> In that case, the old translations will be discarded from i2p.www.revamp (or maybe just left in the branch for now - if a translator really wants to they can find them for reference). +20:39:04 <psi> no formed opinion +20:39:14 <SkinSystem> hi, i heard k0e touches himself whilst watching granny pr0n +20:39:21 <dg> uh? +20:39:32 <psi> >.> #i2p-chat +20:40:45 <str4d> Right, that's it from me on the website. +20:49:59 <dg> well.. +20:50:11 <dg> IDK if wait(str4d) +20:51:33 <dg> AFK, back soon +21:03:55 <hottuna> zzz, did you see the update of http://trac.i2p2.de/wiki/Crypto/CurrentSpecs ? +21:03:58 <iRelay> Title: Crypto/CurrentSpecs – I2P (at trac.i2p2.de) +21:07:36 <zzz> yeah you guys are doing a great job +21:08:13 <hottuna> do you think we are using asymmetric ciphers where they aren't needed? +21:08:23 <hottuna> and could be replaced by symmetric alternatives? +21:08:38 <zzz> I doubt we're using anything where it isn't needed +21:09:04 <hottuna> good +21:09:15 <zzz> the web page crypto section needs the symm/asymm crypto added ofc, right now it's only sigs +21:09:46 <hottuna> yeah. But one issue at a time +21:09:53 <hottuna> I think the signs are the most vulnerable anyway +21:10:07 <zzz> right. just as a one-liner placeholder is all I meant +21:20:19 <hottuna> zzz, sud signing should be fairly do-able as far as implementation and not having a flag day goes? +21:20:41 <hottuna> do-able as in possibly to change cipher for. +21:23:58 <dg> back +21:26:53 <zzz> i guess. we did su2 w/o incident, so why not su3, su4, ... +21:28:38 <hottuna> but before we should decide what cipher is the most viable +21:36:25 <dg> okay +21:36:33 <dg> since str4d_afk is gone.. uh +21:36:51 <dg> zzz, hottuna, do you want to discuss anything further or should we close the meeting? It seems like nobody else is around +21:40:29 <dg> a'ight +21:40:35 * dg bafs the meeting closed +21:41:11 <hottuna> thanks dg :) +21:41:55 <dg> str4d went MIA +21:45:03 <dg> anyway, np +23:00:32 <str4d> Sorry, connection went down and then I was AFK diff --git a/i2p2www/meetings/logs/217.rst b/i2p2www/meetings/logs/217.rst new file mode 100644 index 00000000..e7df7b55 --- /dev/null +++ b/i2p2www/meetings/logs/217.rst @@ -0,0 +1,14 @@ +I2P dev meeting, January 29, 2013 @ 20:00 UTC +============================================= + +Quick recap +----------- + +* **Present:** + dg, + hottuna, + str4d, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, February 5 @ 20:00 UTC (8:00PM) diff --git a/i2p2www/meetings/logs/218.log b/i2p2www/meetings/logs/218.log new file mode 100644 index 00000000..afc139f9 --- /dev/null +++ b/i2p2www/meetings/logs/218.log @@ -0,0 +1,398 @@ +19:59:45 <dg> str4d: thoughts wrt IPv6 in mtg? +20:01:00 <str4d> Bring it up if you want. I know there are real issues that are holding that back, but it could be a good idea to verify what they currently are. +20:01:03 <str4d> I'll also be bringing up the website revamp. +20:01:14 <dg> Sweet. +20:01:22 <str4d> (So poke that in somewhere ^_^) +20:01:33 <dg> Will do :) +20:01:36 <dg> We'll put crypto last, if at all +20:01:44 <dg> I don't want to kill the movement but I don't know where we are going wit hit +20:01:55 <dg> I don't know enough about it to try .. push for it +20:05:01 <str4d> Yeah, last is a good idea, as long as the earlier sections of the meeting stay on track. +20:05:28 <str4d> And we already are in a much better place - the crypto review page has some interesting data (provided by "guest" so I have no idea who ^_^) +20:05:41 <dg> I was thinkign about that +20:14:16 <str4d> dg: ain't it meeting time now? +20:14:48 <dg> oh yeah +20:14:55 <dg> okay then +20:14:58 <darrob> i was going to ask that. i'm confused to see you *plan* a meeting at 08:05. +20:15:36 <dg> the agenda today is: +20:15:36 <dg> (0) - Hi! +20:15:36 <dg> (1) - Primary domain +20:15:36 <dg> (2) - IPv6 progress, blockers +20:15:39 <dg> (3) - Site revamp +20:15:42 <dg> (4) - Crypto +20:15:57 <dg> didn't realize the time +20:16:20 * str4d sends a CTCP TIME message to dg +20:16:34 * str4d watches it bounce off the I2P IRC tunnel. +20:16:41 <hottuna> Hello everybody! +20:16:48 <str4d> Hi! +20:16:55 <dg> We'll start off then? +20:17:25 <dg> So, (1) - primary domain +20:17:28 <dg> (also, hi) +20:17:46 <dg> The current primary domain (used in most places) is i2p2.de +20:17:49 <dg> There's a few problems with it +20:17:53 <str4d> www.i2p2.de +20:18:00 <str4d> (not i2p2.de) +20:18:00 <dg> (1) - It's not attractive or memorable. +20:18:11 <dg> (2) - SEO issues due to the country based TLD +20:18:29 <dg> (3) - Conflicts with other domains (we use geti2p.net on stickers, for example) +20:19:03 <eche|on> I do use www.i2p2.de on I2P stickers +20:19:06 <hottuna> (3) was my fault, it's just a more memorable domain +20:19:13 <dg> I'm proposing we use geti2p.net for all matters from now on but keep the old sites up with a redirect or some SEO magic to tell sites that we've moved without a full redirect +20:19:16 <str4d> (2) isn't a direct problem for Google at least. +20:19:54 <dg> i2p2.net is the better out of the pick though, there's ones like i2p-projekt.de that IMHO are too obscure for project usage +20:20:01 <dg> geti2p.net is kind of motivational too +20:20:16 <str4d> Their support page on geolocation says that geotargeting doesn't specifically affect page rank unless the search is limited by country. +20:20:40 <str4d> But then they also say that they use the geotargeting along with a heap of other things they look at to decide on regionalization. +20:20:43 <hottuna> I prefer geti2p.net, but I think we would need to have an official vote to change it +20:20:49 <KillYourTV> iRelay: web title i2p2.net +20:20:52 <dg> I concur, hottuna +20:20:55 <iRelay> Home - Contractor Safety Program Manuals - Downloadable and Turn-Key Custom-Written +20:21:23 <dg> i2p.net would be ideal, simple & the original domain but we can't have that for years. No promise we'll get it when it expires, either. +20:21:34 * KillYourTV was curious what was there, typo or not +20:22:01 <str4d> What about i2p.com and i2p.org? +20:22:16 <str4d> (Or one of the other generic TLDs? +20:22:16 <str4d> ) +20:22:35 <str4d> Were they long-time registered? +20:23:10 <dg> Believe so. AFAIK, we were lucky to get .net when the project started but I'm not sure. +20:23:10 <eche|on> 1. i2p.net is registered til 2016 and will be grabbed by some machines after wards +20:23:21 <eche|on> 2. do NOT change the domain again. Thats a pain in the ass. really. +20:23:39 <eche|on> user credability is not to be raised with a domain change +20:23:42 <dg> It's not going to be an emergency change this time. +20:23:50 <dg> We already have 5 or so domains floating about +20:23:57 <eche|on> it was a looong 3 year phase to get www.i2p2.de into the game after i2p.net was dead +20:24:08 <str4d> eche|on: that's because you didn't have access to i2p.net +20:24:15 <dg> totally different circumstances +20:24:27 <dg> (and a totally different process) +20:24:30 <str4d> With access to both the old and new domains, either leave the content at the old one, or (better) do a 301 redirect. +20:24:45 <dg> it's not like we're recovering from such a major blow this time, just changing the default domain we refer to +20:25:50 <zzz> Back in the day, com/net/org were the best. But not true now, plus the whole issue of the U.S. can and does shut those down as they please. You really want to go back to a .net? +20:26:24 <dg> It's not like the U.S. can't get .de. If keeping things safe was as simple as being foreign, we wouldn't need I2P. +20:26:49 <hottuna> i2p.{aero|af|ag|ai|am|asia|bz|cat|cm|coop|cx|gg|gr|gs|gy.|hk|hn|ht|im|io|je|ki|la|lc|li|lt|lv|me|mg|mn|ms|mx|name|nf|nu|pt|re|tel|tv} are available +20:27:07 <dg> the "2" makes it unclean which bugs me +20:27:26 <dg> hottuna: i2p.io sounds groovy +20:27:41 <eche|on> I want i2p.xxx +20:27:44 <hottuna> the 2 is nonsensical for any newbie +20:28:11 <str4d> i2p.coop +20:28:14 <dg> I believe in the CCC talk, the guy speaking actually called i2p "i2p2" +20:28:17 <str4d> i2p.coup? ^_^ +20:28:18 <christoph3> the list gets probably a lot shorter by removing inacceptably expensive domains ;-) +20:28:24 <zzz> dg you're greatly underestimating the difference in US-shutdown-ability of .de vs .net +20:28:24 <dg> "to i2p or not to i2p" (or something) +20:28:55 <str4d> zzz: i2p.net is out of the question anyway =) +20:29:09 <dg> zzz: really? I'm not so sure. If the US wanted it down, they could surely exercise their US-shutdown-abilities. +20:29:09 <hottuna> zzz, agreed. Also a valid point. +20:29:24 <dg> str4d: but geti2p.net is the alternative I proposed at least, so I guess he is referring to that +20:29:27 <hottuna> until now only us domestic domains have been taken down +20:29:57 <eche|on> even .at domains were not taken down though being spam and virus spreading domains +20:30:17 <christoph3> zzz is probably not talking about worst-case where the US really really really wants to shut it down +20:30:28 <christoph3> but just would like to +20:30:31 <str4d> Since this was started off by geotargeting issues: what are the actual generic TLDs? +20:30:31 <dg> Pretty sure if the US started shouting it was terrorist related, it could be taken down too +20:31:12 <hottuna> how are .org domains controlled? +20:31:12 <str4d> Ooh, just found a list. +20:31:12 <eche|on> str4d: a lot of them,also including some local russian, asian, chinese... one +20:31:19 <str4d> https://support.google.com/webmasters/bin/answer.py?hl=en&answer=1347922 +20:31:34 <str4d> Google treats all of those ^ as gTLDs. +20:31:38 <eche|on> http://de.wikipedia.org/wiki/Top-Level-Domain +20:31:41 <iRelay> Title: Top-Level-Domain – Wikipedia (at de.wikipedia.org) +20:31:49 <christoph3> .org was verizon just like .com and .net wasn't it? +20:31:52 <eche|on> i2p.int would be nice. +20:31:59 <eche|on> and it would be possible. +20:32:18 <eche|on> or a .nato? +20:33:05 <hottuna> int sounds nice, but is controlled by IANA which is us government +20:33:27 <str4d> hottuna: aren't all TLDs eventually controlled by IANA? +20:33:46 <str4d> (excluding the new raft of TLDs that companies are allowed to buy now) +20:34:04 <dg> new proposal: we buy .i2p +20:34:11 <hottuna> more or less directly? .int being directly? +20:34:11 <hottuna> :P +20:34:14 <hottuna> i2p.i2p? +20:34:21 <dg> project.i2p +20:34:36 <dg> download.i2p +20:34:39 <darrob> hottuna: obviously the main page would have to be www.i2p2.i2p. :) +20:34:54 <hottuna> :P +20:35:12 <str4d> But I just went to all this effort of double-tagging the entire website revamp >_< +20:35:59 <hottuna> str4d, I did some translations. About 70k words left though. +20:37:10 <str4d> There were about 70k words to start with =P +20:37:13 <darrob> how immediate is this US shutdown threat though? instead of worrying about it we could just wait and see. worst case: we'd have to go piratebay-crazy with proxies and media attention and all. +20:37:36 <eche|on> so far it is a no brainer, as tor is still alive. +20:37:47 <dg> oh. yeah. Tor, of course. +20:38:19 <darrob> dg: go on? +20:38:38 <hottuna> realistically we will still have the mirrors, so a specific tld being lost isnt much of an issue +20:38:53 <dg> darrob: about Tor?? +20:38:56 <dg> darrob: as for the discussion, I think we're still talking +20:39:03 <dg> So, do we want to put this down to a vote? +20:39:18 <dg> If so, what would be the options? +20:39:18 <dg> (and when?) +20:39:22 <hottuna> i would like geti2p.net to be an option +20:39:28 <dg> We could do it now if you guys wanted, I don't know if we have enough people +20:39:35 <KillYourTV> +1 for new TLD. Often they're a steal at $185,000 for registration then $6,250 each quarter. Surely we have enough funds available for that. +20:39:35 <hottuna> next meeting? +20:39:50 <dg> Hell yeah! +20:39:53 <dg> hottuna: sure +20:39:53 <hottuna> and announce it on the forums +20:39:53 <darrob> dg: sorry, never mind. your tor comment was not clear to me but it's irrelevant now. +20:40:04 <eche|on> KillYourTV: ^^ oerfect solution, but hosting is another topic. +20:40:35 <hottuna> would anyone like to propose a change to a domain other than geti2p.net? +20:40:38 <darrob> KillYourTV: we'd just need to sell our bitcoins at the right time. +20:41:00 <dg> hottuna: I have none but then again, I don't know the other ones we have. +20:41:55 <str4d> i2p.io sounded quite good, but .io is still country-specific +20:42:42 <dg> ideal world: we would have i2p.org +20:43:34 <hottuna> ok, then we have 2 alternatives. i2p.io and geti2p.net +20:43:45 <str4d> i2p.int? +20:43:48 <str4d> i2p.info? +20:43:56 <str4d> i2p.jobs =P +20:43:59 <dg> is i2p.info available? +20:44:18 <dg> i2p.transformers? +20:44:30 <eche|on> i2p.onion +20:44:45 <hottuna> i2p.info is taken +20:45:00 <str4d> i2p.co - that's a country one that is treated (by Google at least) as generic. +20:45:23 <hottuna> i2p.co is taken +20:45:30 <str4d> i2p.me? +20:45:37 <dg> i2p.me is cool. +20:45:58 <str4d> (another gccTLD) +20:46:09 <darrob> and cool is gimmicky if i may say so. i'd rather see i2p2.org or something. +20:46:09 <hottuna> suggestions: i2p.io i2p.int i2p.me geti2p.net +20:46:28 <dg> I want to drop the "2". +20:46:31 <str4d> darrob: I'd rather see i2p.something +20:46:53 <str4d> Why wasn't i2p.de chosen originally? Taken? +20:47:01 <str4d> s/originally/at the time/ +20:47:04 <iRelay> str4d meant: Why wasn't i2p.de chosen at the time? Taken? +20:47:12 <hottuna> i2p2.org taken +20:47:16 <hottuna> i2p.de taken +20:47:31 <str4d> Mmm. +20:47:50 <KillYourTV> i2p.ispent185000dollarsandalligotwasthisstupidtld +20:48:00 <str4d> I agree that we don't want something gimmicky. +20:48:07 <str4d> It needs to make sense. +20:48:22 <dg> cool == workable in this context +20:48:24 <dg> (too) +20:49:13 <hottuna> i2p.int is available btw +20:50:52 <hottuna> dg, will you add i2p.io i2p.int i2p.me geti2p.net to the alternatives of the vote? +20:51:18 <dg> hottuna: Yup. Making a note of it now. +20:51:27 <hottuna> danke +20:54:10 <str4d> Anything else here, or next topic dg? +20:54:40 <dg> was writing up the topic +20:54:40 <dg> yeah, next +20:54:43 <dg> Alright, IPv6! +20:54:53 <dg> From what I understand, welt* was working on this and then.. ??? happened +20:55:04 <dg> I don't know the blanks, maybe someone can fill them in +20:55:21 <dg> There's a bounty right now for IPv6 support in I2P +20:55:42 <dg> It's 100 EUR +20:55:45 <hottuna> http://zzz.i2p/topics/109 +20:55:48 <dg> http://www.i2p2.i2p/bounty_ipv6 +20:55:55 <iRelay> Title: zzz.i2p: IPV6 TODO (at zzz.i2p) +20:55:56 <iRelay> Title: Bounty I2P IPv6 native - I2P (at www.i2p2.i2p) +20:56:04 <dg> I think after/alongside the crypto doup, this is important +20:56:43 <dg> I could do with zzz or welt* +20:56:57 <dg> It'd be fantastic if welt* took it up again +20:59:01 <dg> Meeh is seemingly OK with helping +20:59:12 <dg> If zzz is going to, he needs SSH +20:59:42 <Meeh> I can provide zzz with SSH +20:59:45 <Meeh> to a dev server +21:00:09 <Meeh> we should also start using mailing lists now that it's up :) +21:00:20 * dg nods +21:00:44 <dg> I'm not aware of mailing list etiquette but I can start posting there +21:00:51 * dg crickets +21:01:54 <str4d> Meeh: is it I2P-internal as well, or should we use @i2pmail.org? +21:02:17 <dg> i2p-internal I assumed but.. +21:02:20 <Meeh> @i2pmail.org for now... haven't figured out howto bring it inside i2p yet +21:03:16 <str4d> Meeh: you'd need some sort of rewriting. Maybe talk to postman? +21:03:36 <Meeh> yepp, I will +21:04:34 <dg> Should we move on or wait? +21:04:49 <str4d> Back to IPv6, zzz provided a nice summary in the dev forum post +21:05:20 <str4d> It sounds like the next step is to compare and contrast the three possible options. +21:05:43 <str4d> Do we want to do that here/now? In the dev thread? On a Trac wiki page like the crypto one? +21:06:17 <dg> Trac, I say +21:06:52 <Meeh> dg, str4d : +21:06:52 <Meeh> 22:05:27 <postman> if the mailinglist server resides in the internet +21:06:52 <Meeh> 22:05:40 <postman> all people use their @i2pmail.org adress for signup +21:06:52 <Meeh> 22:06:14 <postman> teh mails will be automatically rewritten when transferred to / from internet +21:06:52 <Meeh> and i2p +21:07:34 <Meeh> 22:07:02 <postman> ( i think it would be best to have a ml server public) +21:07:56 <Meeh> 22:07:16 <postman> so people without mail.i2p adresses can subscribe +21:08:12 <Meeh> so I suggest current setup, since many that's not on i2p can join the list +21:08:37 <str4d> Meeh: alright. +21:08:54 <dg> <+dg> Should we move on or wait? +21:08:54 <str4d> Oh, and also, if the domain name changes, what happens to the list email? +21:09:04 <dg> CNAME the MX? +21:09:14 <str4d> Ah, true. +21:09:25 <str4d> dg: move on, I think. I don't think we are going to have in-depth IPv6 discussions today,. +21:09:40 <dg> Yeah.. seems that way. I'm dubious about crypto too? :| +21:09:51 <dg> Okay, website revamp! +21:10:07 <dg> str4d has been chugging away at tagging and eliminatin the blockers +21:10:14 <dg> I think we're getting closer to being able to put it live +21:10:17 * dg hands mic to str4d +21:10:50 <str4d> Okay, the site is edging closer and closer to being ready. +21:11:02 <str4d> I've nearly tagged the entirety of docs/ +21:11:36 <str4d> I'm just working on docs/spec/* now, and then docs/discussion/* (though I'm not sure if that one is needed?) +21:12:03 <str4d> docs/spec/ is somewhat hard to fully tag though, as there is a lot of <pre>-formatted stuff which translating will just break. +21:12:36 <str4d> URL-wise, aside from docs/spec/* and docs/discussion/* the entire site should have working URLs. +21:12:51 <str4d> If someone wants to test that (manually or automated) that would be good. +21:13:37 <str4d> Structurally, I don't think there is much more needed for the site - can anyone think of anything? +21:14:55 <hottuna> No +21:15:06 <hottuna> and if flaws are found they can be fixed +21:15:24 <dg> I don't think there's any.. let alone critical +21:15:31 <str4d> Design-wise, I'm still not entirely happy, but that's not critical. +21:15:53 <str4d> The mobile CSS I added *does* have flaws, but it is far easier to use/read than the desktop CSS. +21:16:27 <str4d> So I think the only thing left is to wait for the translations to start coming in. +21:17:10 <str4d> (I'd like to at least have some of the main pages translated before launch, so that Google doesn't think I'm lying to it in the sitemap.xml) +21:19:52 <str4d> And here's an idea: If/when we decide on a new domain, we launch the new site there, so we can test it live, and then inform Google/users via 301 redirect that the new site is the new domain? +21:21:03 <hottuna> the translation is a very big job +21:21:03 <hottuna> one that will take a lot of time +21:21:03 <hottuna> why not update sitemap.xml when translations are available? +21:22:56 <str4d> hottuna: the sitemap is somewhat recursively generated. +21:22:59 <hottuna> Would that be better? +21:23:02 <hottuna> ok +21:23:28 <str4d> It's to do with the whole reflang thing that Google requires. +21:23:51 <str4d> Every page in the sitemap has to list as a lang link every other language page, including itself. +21:24:06 <str4d> And that has to be repeated for each lang variant of a page. +21:24:25 <str4d> I've already split it up into a /sitemapindex.xml and /lang/sitemap.xml pages. +21:24:41 <dg> Would Google really care? +21:24:41 <hottuna> but we're always going to lack translations for some languages? +21:24:45 <str4d> But we also have a Language dropdown, which Google is going to find. +21:25:23 <str4d> hottuna: the list of Languages on the revamp is taken from the current site - there are partial translations for all of them. +21:25:26 <str4d> dg: no idea really. +21:25:59 <dg> It could take a long time to get us translations +21:26:06 <str4d> The sitemap language thing is there so that Google doesn't use the pages themselves to determine language (as in that case, every language variant would be called "English" currently) +21:26:33 <str4d> Hmm... I'll go check whether Google defers to the sitemap entirely, or if it still uses its own observations. +21:26:39 <str4d> I could just be needlessly worrying. +21:26:47 <hottuna> dg: I think it will, historically that has been the case for most languages. +21:27:02 <hottuna> maybe str4d, but ultimately this is your call +21:27:06 <str4d> And if having "lang-specific" pages which aren't translated isn't going to affect our pagerank, then it's not a blocker. +21:29:44 <dg> Hm, ok +21:31:22 * dg waits +21:32:56 <str4d> Okay, just did some reading, and it looks like Google defers to the sitemap +21:33:25 <str4d> Since one usage is translating only the template of the page, and leaving the content in a single language (like forum posts). +21:33:44 <str4d> So, translations are not a blocker, and can be updated as we go. +21:33:51 <str4d> In which case, the site could go live, now. +21:33:51 <dg> Any other bugs? +21:33:58 <dg> Oh. Sweet. +21:34:01 <str4d> (Well, now + time it takes to check all remaining URLs) +21:34:04 <dg> Anyone got any views on putting it live? +21:37:48 <hottuna> alright. if now is an option, i would vote for now +21:37:59 <dg> me too +21:38:34 <str4d> Putting it live requires some help from whoever is running the server (welterde IIRC) +21:38:45 <str4d> And the mirrors. +21:39:20 <hottuna> alright, at next sighting of the welterde/weltende, let's ask? +21:39:34 <str4d> Propagating back to i2p.www is simple. But the server ops need to run the setup script and then configure their WSGI setup to use the virtualenv. +21:40:15 * str4d will prop i2p.www onto the revamp now so that merges etc. can be handled now. +21:42:53 <dg> Huzzah +21:43:12 <hottuna> Yep +21:46:43 <str4d> Okay, so that's the revamp done. dg? +21:46:50 <dg> str4d: Yup. +21:47:21 <dg> I was avoiding moving on +21:47:22 <dg> due to the IPv6 discussion (or lack of..) +21:47:25 <dg> Wanna call it a night? +21:47:25 <dg> I think it's the best choice +21:47:33 <hottuna> Sure +21:47:59 <str4d> Yeah, 1.75 hours can be enough for today +21:48:10 <dg> Heh. +21:48:10 <dg> Alright, +21:48:13 * dg bamfs the meeting closed +21:49:21 <dg> http://zzz.i2p/topics/1343 +21:49:28 <iRelay> Title: zzz.i2p: Meeting [6th February] (at zzz.i2p) +21:50:31 <hottuna> the next meeting is the 12/2 not 6/2 +21:50:42 <hottuna> wut +21:50:42 <hottuna> ok +21:50:49 <hottuna> or am I confused +21:51:47 <dg> my mistake +21:52:10 <dg> ;_; +21:55:01 <iRelay> <str4d@freenode> ping weltende +23:39:54 <zzz> um, was it just me, or did the meeting totally skip the final decision that changing our URL was definitely a good idea? +23:40:30 <zzz> I saw some pros and cons on changing and then 'lets post a vote for which new one to pick' +23:40:50 <iRelay> <jenkins@kytv> Project Syndie HSQLDB2 build #9:SUCCESS in 15 sec: http://eotfca7qexthbireor6ae7g4hbj5hwuhe4gkzxdx3l3g2t5gzn7q.b32.i2p/job/Syndie%20HSQLDB2/9/ +23:41:54 <zzz> nor did I see anybody volunteer to do all the work req'd to implement such a change +23:45:25 <zzz> or is the (unstated) plan to vote on the best name first, and only then decide whether to do it and how? +23:45:29 <zzz> ^^ dg +23:45:55 <dg> Correct, sorry if it wasn't clear +23:46:03 <dg> I'll outline more next time +23:46:49 <zzz> might be me, I was just skimming. +23:46:55 <zzz> so was there a decision made or not? +23:47:37 <dg> We're having a vote next week +23:48:03 <zzz> a vote on what? whether to change, or what to change it to? +23:48:33 <dg> What to change it to +23:48:56 <zzz> so was there a decision made or not on whether to change it at all? +23:48:59 <dg> We could certainly have people abstain though +23:49:06 <dg> which would be a "no change" +23:49:42 <dg> We were in agreement that a change would be nice but unable to agree on what *to* +23:49:52 <zzz> is the decision to change at all a) already made or b) deferred until after the vote? +23:50:14 <dg> b) +23:50:54 <zzz> that wasnt clear to me either from the mtg or from http://zzz.i2p/topics/1343 +23:51:01 <iRelay> Title: zzz.i2p: Meeting [12th February] (at zzz.i2p) +23:51:18 <str4d> zzz: What I gathered is that, of the people present at the meeting, the majority were for a change. +23:51:25 <zzz> and to me, imho "would be nice" is far far short of "it's definitely a good idea AND we have volunteers to do the work" +23:51:28 <str4d> But, not all relevant people were at the meeting. +23:51:38 <dg> (e.g. you) +23:52:04 <dg> welt wasn't there either, I may be forgetting someone but was anyone else missing? +23:52:37 <zzz> sure, I was in and out, my bad. But my review of the logs is the pros were saying 'would be nice' and the cons had significant objections. +23:53:04 <str4d> zzz: I don't recall significant objections. Care to elaborate? +23:53:07 <zzz> but dg says it hasn't been decided yet, +23:53:25 <str4d> The only major one was eche's about linkage loss, but that is easily solved with a 301 redirect +23:53:28 <dg> The big one was from ech, saying it would cause big issues +23:53:31 <dg> and that was't true +23:53:45 <dg> s/was't true/debunked +23:53:52 <str4d> (So can't really be fairly compared to the i2p.net -> i2p2.de migration, which *was* an issue) +23:53:58 <zzz> <eche|on> 2. do NOT change the domain again. Thats a pain in the ass. really. +23:53:58 <zzz> <eche|on> user credability is not to be raised with a domain change +23:54:09 <zzz> there's the US-controlled issue I raised +23:54:19 <zzz> there's the amount of work required, which nobody raised +23:54:30 <str4d> "pain-in-the-ass" was referring to above. +23:54:46 <dg> There's links on the main site (how much of that can be done with regex?), some in the source code (same again?) +23:54:46 <dg> What else? +23:54:53 <zzz> there's the SEO issue, which you apparently think is managable, but I'm not so sure +23:55:16 <str4d> User credability - that is rather wishy-washy and IMHO changing from i2p2.* to i2p.* is going to make it easier for users. +23:55:16 <zzz> there's links in our docs and code +23:55:35 <str4d> Links on the site are all relative, so no issues there. +23:55:35 <dg> s/http://www.i2p2.de/http://geti2p.net/ +23:55:38 <iRelay> Title: Not found - I2P (at www.i2p2.de) +23:55:38 <dg> s/http://www.i2p2.de/http://geti2p.net/g +23:55:41 <iRelay> Title: Not found - I2P (at www.i2p2.de) +23:55:50 <str4d> Docs and code and SEO - again, a 301 redirect solves all that. +23:56:05 <dg> 301 is perm redirect, yeah? +23:56:08 <str4d> (The docs and code of course should be updated, but the links would not break) +23:56:11 <str4d> Yes. +23:56:21 <dg> If so, I'd assume that's what it was created for - that kind of thing anyway. +23:56:21 <str4d> It's what the revamp has for all the old page locaions +23:56:24 <zzz> if it's not decided yet, (and dg says it isn't) then we can talk about it next week. my reading from the logs and zzz post was that it was decided, but apparently not +23:56:42 <str4d> e.g. /debian.html --[301]--> /en/download/debian +23:56:57 <str4d> zzz: yep, not decided yet, this was just getting the ball rolling. +23:57:04 <zzz> ok +23:57:19 <zzz> also a lot of this requires welt's tme which is in short supply +23:57:24 <str4d> Nothing is going to happen without informed consensus. +23:57:44 <zzz> ok great. guess I misread the logs +23:57:55 <str4d> Yeah, which is why I'd like to sort out the revamp and push it live at the same time. +23:58:29 <str4d> Or rather, I'll keep on working on site stuff and whenever welt turns up we can push it live. +23:59:15 <dg> I'll edit the post to make it clear +23:59:18 <zzz> maybe. trying to change 6 things at once increases the risk too. I'd recommend incrementalism +00:00:16 <zzz> also beware of becoming overly google-focused as there are other search engines too, who may behave differently +00:00:31 <zzz> or at least more slowly +00:00:34 <str4d> zzz: mmm, which is why I suggested putting the revamp on the "new" url to test it. +00:00:42 <str4d> And then apply the 301. +00:00:53 <str4d> (Assuming the url is changed) +00:01:30 <str4d> Yeah, I'll do some checking up of other search engines, but Google seems to use reasonably standard technology (e.g. the sitemap stuff) +00:02:05 * str4d is currently checking and fixing old/broken URLs. +00:03:24 <dg> Edited my post. http://zzz.i2p/topics/1343 +00:03:31 <iRelay> Title: zzz.i2p: Meeting [12th February] (at zzz.i2p) +00:05:36 * dg waits for ech to come back +00:05:43 <dg> That'll be tomorrow, right? +00:08:17 <zzz> re: incrementalism, e.g. you may wish to consider using 302s for a few days on the live site until you're sure it's all good before switching to 301s, as you really don't want to mess up 301s +00:08:28 <str4d> Mmm, yep. +00:08:40 <str4d> Do you mean for the legacy pages as well? +00:09:16 <zzz> maybe. something to think about +00:09:43 <str4d> I'm pretty sure all the old pages are good (I manually checked most of them) +00:09:53 <dg> As for domains, https://twitter.com/i2p/status/298485275053666304 - I can't be the only one who thinks that's messy +00:10:00 <str4d> But probably worth checking again at some stage. +00:10:28 <dg> str4d: No reply from zab. +00:12:36 <iRelay> <jenkins@kytv> Starting build #43 for job Cobertura Coverage Reports +00:13:41 <zzz> not saying it's a bad idea to switch (and if we do, geti2p.net is the only choice). Just that we do it purposefully if we do. You made a proposal and held discussion but never called for a decision, or even identified how or when a decision would be made. +00:14:59 <dg> <+hottuna> I prefer geti2p.net, but I think we would need to have an official vote to change it +00:15:02 <dg> <+dg> I concur, hottuna +00:15:13 <dg> only geti2p.net? +00:15:20 <dg> So fuck the vote and just have a y/n? +00:15:27 <dg> that's fine but tell me now :p +00:16:10 <zzz> so the vote to change it and the vote on what to change it to got conflated +00:17:01 <zzz> "only choice" just imho +00:17:12 <dg> Everyone attending was up for changing it (ech was the only one who disagreed and he.. went quiet.. I don't know what that means, no?) so I skipped that step +00:20:04 <zzz> well, run the meeting how you want, but not sure you want to discount people who only object once, especially if you don't have an obvious call for the end of discussion and a decision +00:20:13 <dg> no, i see your opint +00:20:16 <dg> point* +00:20:26 <dg> i do need to outline things more diff --git a/i2p2www/meetings/logs/218.rst b/i2p2www/meetings/logs/218.rst new file mode 100644 index 00000000..13eba9f8 --- /dev/null +++ b/i2p2www/meetings/logs/218.rst @@ -0,0 +1,19 @@ +I2P dev meeting, February 5, 2013 @ 20:00 UTC +============================================= + +Quick recap +----------- + +* **Present:** + christoph3, + darrob, + dg, + eche|on, + hottuna, + KillYourTV, + Meeh, + str4d, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, February 12 @ 20:00 UTC (8:00PM) diff --git a/i2p2www/meetings/logs/219.log b/i2p2www/meetings/logs/219.log new file mode 100644 index 00000000..5441ac5b --- /dev/null +++ b/i2p2www/meetings/logs/219.log @@ -0,0 +1,523 @@ +20:00:38 <hottuna> dg, meetingtime? +20:03:06 <dg> uh.. through tor? +20:03:06 <dg> was just pulling the mtg topic ;) +20:03:06 <dg> ok, hi! +20:03:06 <dg> Today's agenda: +20:03:09 <dg> (0) - hi +20:03:15 <dg> (1) - Domain vote +20:03:18 <dg> (2) - Website transition +20:03:25 <dg> (3) - IPv6 .. I hope +20:03:28 <dg> (4) - Crypto .. I hope +20:03:43 <dg> str4d KillYourTV eche|on zzz +20:03:54 <str4d> Hi! +20:03:57 <dg> sponge meeh +20:03:57 <hottuna> Hi! +20:04:04 <dg> Hi! :-) +20:04:07 <exoshell> dg: Looks like I need to edit my .pac file and update the regex. The connect was going through 127.0.0.1:4444 Thanks! :) +20:04:25 <dg> exoshell: No problem. Better to be that problem than being censored for real, right? +20:04:34 <dg> Ok, how many people do we need to vote? +20:04:45 <exoshell> no kidding. +20:04:48 <str4d> weltende +20:04:52 <str4d> (ping) +20:05:06 <hottuna> Mathiasdm postman badger +20:05:19 <hottuna> domain vote is coming up +20:05:22 <dg> \o/ +20:05:41 <dg> h2ik bpb psi +20:05:49 <dg> .. wakey wakey? +20:06:23 <dg> Everyone's sleepy +20:06:36 <dg> We could do with more than three people >.> +20:06:51 <hottuna> 3 ppl isnt enought. +20:06:58 <str4d> Nope +20:07:16 <hottuna> Could we start a zzz.i2p thread for it and have #i2p-dev topic point ppl to it. +20:07:20 <str4d> And there are two votes needed - what we would change it to, and if we are going to change it at all. +20:07:31 <hottuna> and just have people vote for one of the alternatives +20:07:38 <str4d> (Can and should be independent) +20:07:41 <dg> RN, Shinobiwan +20:07:49 <hottuna> agreed +20:08:00 <dg> might be an idea +20:08:07 <dg> I was going for $OPTIONS/"I don't want a change" +20:08:28 <hottuna> dg, makes sense to me +20:08:45 <dg> I mean.. we did post this a week ago +20:08:45 <zzz> dont even bother if weltende isnt here +20:08:48 <str4d> With two votes, even those who don't want a change can contribute an idea as to what they would change to if they had to. +20:09:22 <dg> They could anyway? We've had the topic up for a week and there's been no new suggestions. +20:09:22 <hottuna> str4d, so $OPTIONS/"I don't want a change" is not good enough? +20:09:37 <dg> "You can abstain (to say I don't want us to change) but it's preferable if you'd bring it up first so we could discuss why.. but not necessary." +20:09:40 <Shinobiwan> o/ +20:10:26 <iRelay> <weltende@freenode> zzz: well.. I don't *really* care +20:10:51 <str4d> hottuna: that doesn't give the right statistics. +20:10:51 <dg> Does that mean you'll go with the majority or.. what? +20:10:55 <dg> Not caring isn't a great stance. +20:11:02 <hottuna> weltende, as long as you know that there is a vote +20:11:21 <zzz> ok, but presumably work would fall on you if we switch, so you kinda have to agree to a switch +20:11:21 <dg> We've said there's a vote, people are able to vote for - with a choice or against +20:12:11 <str4d> weltende, how much work do you see for yourself in the event of a switch? +20:12:22 <hottuna> alright, are we enough ppl around for the vote "Do you want to change the domain?" ? +20:12:29 <dg> I'm trying to think of things you can't do with a quick sed. +20:13:03 <dg> hottuna: hottuna, str4d, zzz, Shinobiwan, welt, dg +20:13:03 <dg> that's 6 +20:13:03 <dg> is that enough? +20:13:10 <dg> I'm not sure. +20:13:10 <hottuna> yes? +20:13:22 * asdfsdafsdafsd runs in the room +20:13:29 <asdfsdafsdafsd> I'm here.... 7 +20:13:29 <dg> :o +20:13:32 <dg> make that 7 +20:13:47 <zzz> dns updates, ssl certs, transfers (if somebody else has the new domain now) .. .among others +20:13:47 <hottuna> so let's do the vote? +20:13:54 <dg> it's not lik we have ssl certs anyway +20:13:57 <dg> let's do it +20:13:57 <inscrutus> i'm just a civvie, is my opinion worth anything ? +20:14:04 <dg> yes +20:14:11 <hottuna> inscrutus, yes :) +20:14:14 <zzz> dg, yes we do have certs +20:14:21 <dg> zzz: none valid afaik +20:14:28 <hottuna> zzz, the cacert cert? +20:14:28 <dg> hottuna: say "I"? deal? +20:14:30 <inscrutus> cool :) +20:15:00 <hottuna> \me says votes "I" +20:15:03 <asdfsdafsdafsd> so, what are the alternate domain choices? +20:15:06 <zzz> dg the choice of CA is a different issue. don't confuse things by saying we dont have certs. +20:15:17 <hottuna> "I" +20:15:17 <Shinobiwan> i2p2.de ? +20:15:17 <dg> zzz: meh. same diff for the most part. for another time, anyway. +20:15:24 <dg> Those in favor of a domain change (doesn't matter what to), say I! +20:15:35 <hottuna> asdfsdafsdafsd, that is the next vote, first we decide if we want to change +20:15:42 <zzz> no, its not the same at all. It's work to be done, don't discount it. +20:15:42 * dg votes "I" +20:15:44 <iRelay> <weltende@freenode> str4d: not sure.. but not gonna do anything before 1.3 +20:15:52 * hottuna votes "I" +20:15:59 <zzz> do you guys mean "aye" ? +20:16:06 <zzz> ffs +20:16:07 <dg> ... +20:16:07 <dg> yes +20:16:10 <hottuna> yes :P +20:16:13 <hottuna> damnit +20:16:13 <dg> LOL +20:16:16 * inscrutus says aye (FWIW) +20:16:16 <asdfsdafsdafsd> hottune, ah ok +20:16:19 <dg> .. aye +20:16:26 <asdfsdafsdafsd> edit.... tuna lol +20:17:20 <hottuna> 3 for - 0 against, this far. +20:17:46 <Shinobiwan> i2p2.de ? ?_? +20:17:49 <zzz> do we have volunteers to do all the other work required? docs, website, router console, etc? +20:17:52 <Shinobiwan> if so, aye +20:18:03 <dg> Shinobiwan: Moving from i2p2.de -> anything +20:18:19 <dg> (we'll have another vote to determine what "anything" is) +20:18:26 <Shinobiwan> yea then... definitely. +20:18:29 <hottuna> zzz, ill take responsibility if works needs to be done (that is server specific) +20:18:35 * asdfsdafsdafsd confers with his greater and lesser demons.... +20:18:46 <dg> Website doesn't need anything doing. +20:18:46 <asdfsdafsdafsd> aye +20:19:01 <str4d> zzz: the work will get done, but the 301 server redirect will solve that. +20:19:01 <hottuna> 5 for - 0 against +20:19:04 <dg> well, a redirect. +20:19:07 <dg> 4 for - 0 against. +20:19:09 <iRelay> <user@kytv> abstention here +20:19:09 <dg> oops +20:19:12 <str4d> Website, has nothing (aside from tweaking the mirror links in the footer) +20:19:31 <str4d> Ah, and aye +20:19:34 <dg> so.. no? +20:19:37 <hottuna> ok +20:19:43 <str4d> dg: abstention. Difference. +20:19:47 <eche|on> count me as a no, it is absolutly unneeded and unneeded work and confuses the users +20:20:00 <asdfsdafsdafsd> I guess this means I'll have to edit my posters.... +20:20:00 <dg> str4d: No, I said something in the topic due to the previous model we were going for. +20:20:02 <iRelay> <user@kytv> my English is bad. I mean I am indifferent +20:20:12 <dg> str4d: "You can abstain (to say I don't want us to change) but it's preferable if you'd bring it up first so we could discuss why.. but not necessary." +20:20:12 <eche|on> but as I do not have to do anything, who cares +20:20:15 <dg> ah ok +20:20:18 <dg> 6 for - 1 against +20:20:21 <lillith> FWIW, my vote is no change. i like i2p2.de with the other urls pointing at it +20:20:34 <str4d> lillith: other urls? +20:20:34 <dg> 2 against. +20:21:01 <lillith> geti2p.net etc +20:21:04 <str4d> You mean the mirrors? They aren't pointing at it (that would be a 301 redirect) - at present they are full mirrors. +20:21:19 <dg> geti2p.net is a mirror iirc. +20:21:22 <lillith> ahh okay :D +20:21:26 <dg> so.. yes or no? +20:21:45 <zzz> I'll give a contingent aye, dependent on the result of the 2nd vote. If I don't like the new one I will switch to nay. +20:21:52 <lillith> no - keep i2p2 as primary url +20:21:59 <hottuna> sponge, Mathiasdm, Meeh, RN: Domain votes? +20:22:06 <dg> 7 for - 2 against. +20:22:25 <str4d> (That's why I wanted to do the second vote first =P) +20:22:33 <dg> .. oh. +20:22:38 <dg> That makes snese. +20:22:45 <asdfsdafsdafsd> can zzz setup a poll on the dev forum? +20:22:56 <dg> don't know if polls are possible +20:22:59 <zzz> no, because if the 1st vote loses you dont need a 2nd. +20:23:13 <inscrutus> lillith: that hints at another question: keep i2p2 as a secondary domain? +20:23:20 <str4d> inscrutus: of course. +20:23:20 <inscrutus> i2p2.de* +20:23:26 <dg> That's a yes. +20:23:33 <dg> We're keeping it for SEO purposes and to stop evil. +20:23:37 <str4d> If a change goes ahead, www.i2p2.de will be 301-ed to the new one +20:24:10 <str4d> I.e. it wouldn't be a full mirror, it would redirect to the new URL (which ensures that the old SEO/linkage/etc. gets transferred to the new URL) +20:24:28 <inscrutus> Right, that makes sense +20:24:37 <eche|on> ..at some point I cannot read/hear/... this buzzwor SEO anymore,... +20:24:47 <asdfsdafsdafsd> I guess a forum vote is maybe a bad idea, because you could get people voting multiple times too +20:24:54 <zzz> my vote and any change is also contingent on weltende agreeing to do the work +20:24:54 <dg> SEO is real, lol. +20:26:05 <str4d> zzz: my sugggestion (if a domain change is agreed on) is that the site revamp be put up at the new URL, and then once tested the old one is put on redirect. So weltende would be killing two birds with a slightly larger stone. +20:26:43 <hottuna> Is the first vote over and done? +20:26:49 <iRelay> <user@kytv> don't kill innocent birds!! +20:26:49 <dg> Believe so. +20:26:59 <h2ik> hi back dg +20:26:59 <dg> So.. 7 for - 2 against. +20:27:02 <dg> oh! +20:27:02 <dg> hi! +20:27:02 <h2ik> sorry, working :-) +20:27:06 <dg> np :-) +20:27:10 <dg> got enough time to say yay or nay? +20:27:13 <asdfsdafsdafsd> I don't think anyone else is coming... +20:27:36 <asdfsdafsdafsd> we could wait until 8:30 UTC though +20:27:51 <dg> I'll wait for h2ik's answer +20:28:18 * h2ik is reading up on the domain vote +20:28:38 <dg> the vote right now is actually "Do you think we should change?" - not what to +20:29:01 <dg> if the result is yes, I will post a forum topic for voting. +20:29:04 <dg> if no..: pass +20:29:16 <h2ik> We've had the .de for a long time and I'm not opposed to it. So pass. +20:29:31 <h2ik> sorry, obstain +20:29:31 <dg> 7 for - 3 against. +20:29:34 <dg> oh +20:29:34 <h2ik> I'm ok either way +20:29:41 <dg> so not against, not for +20:29:44 <dg> ok +20:29:44 * unresolved waves +20:29:47 <h2ik> 7 - 1 - 3 +20:29:50 <dg> 7 for - 2 against. +20:30:15 <dg> 7 - 2 - 3 +20:30:15 * h2ik eagerly awaits the ipv6 topic :-) +20:30:19 <dg> Okay, that's done then! :D +20:30:37 <dg> str4d: Your time to shine. +20:30:47 <dg> topic = transition to new website design +20:30:50 <str4d> We can always update this vote if more people come in, but there's enough for the second vote. +20:31:08 <str4d> dg: are we not having the second vote right now? Or are we doing that in a thread? +20:31:22 <dg> str4d: I was thinking of a thread.. we can do it now if you want? +20:31:25 <dg> We have enough to do it. +20:31:35 <dg> It's not worth waiting another week IMO but I didn't want to upset anyone +20:31:54 <hottuna> Let's do it now? +20:31:57 <zzz> cant do polls on zzz.i2p. use forum.i2p if you want a poll +20:31:57 <dg> hell, let's do it +20:32:07 <asdfsdafsdafsd> we need a catchy domain name... +20:32:10 <hottuna> enumerate the options and we'll all pick one +20:32:17 <dg> The new domain candidates are: +20:32:17 <dg> - i2p.io +20:32:17 <dg> - i2p.int +20:32:17 <dg> - i2p.me +20:32:17 <dg> - geti2p.net +20:32:38 <h2ik> geti2p.net would follow suit with other FOSS projects +20:32:38 <Meeh> i2p.int was kind of fancy +20:32:41 <Meeh> or io +20:32:43 <hottuna> ** other (specify) ** +20:32:51 <dg> (and make sure it's available) +20:33:05 * hottuna votes for geti2p.net (since we already have it and it's pretty good) +20:33:17 * dg votes for geti2p.net. ditto on the reasons. +20:33:23 <zzz> who owns those 4 now? +20:33:29 <asdfsdafsdafsd> i2p4.me? lol +20:33:36 <dg> N/A, N/A, N/A, hottuna. AFAIK. +20:34:00 <hottuna> i dont own geti2p.net +20:34:04 <dg> oh? +20:34:15 <hottuna> weltende/welterde owns geti2p.net +20:34:18 <dg> ah ok +20:35:03 <zzz> um, if we don't know who owns a proposed domain, then there's no f-ing use talking about it. Unless it's available. +20:35:10 <lillith> would it be counterproductive to go for i2p-projekt.de? +20:35:10 <lillith> that's my vote if it's an option +20:35:21 <hottuna> zzz, the above ones are available +20:35:36 <hottuna> lillith, you can vote for whatever you like :) +20:35:44 <zzz> ok. +20:35:47 <asdfsdafsdafsd> i2phides.me +20:35:58 <zzz> yet another reason why we need welt's agreement. +20:36:09 <lillith> hottuna: good. just checking the point isn't to move away from a .de domain :) +20:36:17 <dg> it was for some of us ;) +20:36:24 <dg> well.. actually.. overall, it was. +20:36:31 <dg> but you can vote for whatever +20:36:36 <Shinobiwan> geti2p.net is good, i2p.me is good too IMO +20:36:39 <Shinobiwan> if need to get new one, i2p.me +20:36:46 <str4d> dg: not overall +20:36:57 <dg> it does not have to be new +20:37:03 * zzz again raises the significant issue of moving to a US-controlled TLD +20:37:12 <iRelay> <user@kytv> and there was silence ..... +20:37:13 <iRelay> <user@kytv> I don't like the .me and .io - they're very unknown here +20:37:15 <iRelay> <user@kytv> maybe cheaper, I dunno, but people here would be like "WTF is that?" +20:37:15 <dg> I don't think it's the time to. +20:37:35 <hottuna> when you've decided what ytou'd like to vote for, please denote it with a /me or something easily distinguishable +20:37:35 <dg> The vote was in +, not - +20:37:49 <asdfsdafsdafsd> I don't like the '.io' +20:37:52 <Shinobiwan> yea the country bit is important :/ +20:38:11 <dg> I felt that if the $GOV wanted rid of us, they could anyway. Tor Project does fine. +20:38:17 <zzz> agreed. you arent picking 2 letters, you're picking a legal domain +20:38:19 <iRelay> <user@kytv> oh, it was the relay lagging. +20:38:19 * Mad reads silently, thinking this is quiet an important descision. +20:38:22 <dg> We have bigger problems than our domain if they want us shut down so badly. +20:38:31 <iRelay> <user@kytv> IMHO short is better than i2p-project.whatever +20:38:43 <unresolved> i2.p +20:38:46 <unresolved> :P +20:39:25 <zzz> dg, the fact that $X hasn't yet been shut down is not much of an argument. The issue is who a particular government _has_ shutdown and why, and the legal process required. +20:42:48 <asdfsdafsdafsd> that's pretty good unresolved -> i2.p +20:44:24 <inscrutus> Are we worried about the .net having censorship issues? +20:44:27 <dg> zzz: It is? I don't think the US government would come after us, but if they were to, they'd likely go after TPO at the same time, or not long after. TPO didn't see it as much of an issue and I don't either. +20:44:27 <dg> I'm not, some are. +20:44:30 <lillith> semi related to zzz's point, is there an i2p .onion? will there ever be? +20:44:33 <zzz> to handwave and say all TLDs are equivalent is naive +20:44:33 <unresolved> ty :P +20:44:33 <dg> lillith: I can get on that but AFAIK, right now, no. +20:44:33 <str4d> lillith: that IS a valid point; but that would be work for weltende +20:44:33 <str4d> (There isn't one now) +20:44:33 <lillith> also a freesite - if censorship is/may be an issue there are other ways of getting round it than just changing the url +20:44:33 <inscrutus> Well there _are_ backup domains in case geti2p.net gets shut down +20:44:33 * inscrutus votes geti2p.net +20:44:33 <inscrutus> And getting shut down would be good media coverage :D +20:44:35 <asdfsdafsdafsd> hehe +20:44:35 <zzz> again, the fact that t.p.o or anybody else hasn't yet had a problem, or your theory that they wouldn't shutdown us unless thy also shutdown $X and they'd never do that, is irrelevant +20:44:35 <lillith> also re: people talking about tor, tor dosent allow file sharing, so they have more protection in US +20:44:35 <lillith> i2p does allow filesharing so is more likely to be a target +20:44:35 <zzz> it's the established procedures and due process or lack thereof. +20:46:13 <dg> inscrutus: mm, yeah. I doubt we'd be censored without some noise. +20:46:19 <str4d> lillith: it's not that they forbid filesharing for legal reasons, it's that they encourage people to not fileshare for technical reasons. +20:46:19 <dg> In any case, you can still use Tor for filesharing. +20:46:19 <dg> You just shouldn't. +20:46:22 <dg> So.. +20:46:22 <dg> Back on topic? +20:46:22 <lillith> str4d: whatever the reason, it will almost certainly be a plus when it comes to not being shut down +20:46:33 <lillith> sorry, dg. yes +20:46:50 <dg> Right now, I believe it's geti2p.net - 2 +20:46:53 * lillith wishes to officially register a vote for i2p-projekt.de +20:46:56 <dg> Shinobiwan: You never decided ;) +20:46:56 <dg> ok +20:46:59 <zzz> presumably i2p2.de etc remains a mirror for many years +20:47:02 <dg> yes +20:47:05 <Shinobiwan> I pinged out, must have missed something +20:47:19 <dg> Shinobiwan: ah. Doesn't have to be a new domain. Your vote? +20:47:57 <Shinobiwan> geti2p.net +20:48:15 <dg> that's 4 so far.. +20:48:15 <Shinobiwan> if welterde say OK, or w/e needs to happen for that. +20:48:27 <zzz> .io, .me, and .int are worse than what we have now and not worthy. i2p-projekt.net is better but hyphens are terrible for many reasons, an the english spelling is problematic. that leaves only geti2p.net imho +20:48:41 <inscrutus> dg: am I counted among those 4? I think I'm lagging +20:49:13 <asdfsdafsdafsd> I agree with zzz.... out of the 4 geti2p.net is the best +20:49:32 <Shinobiwan> yeah, haha, exactly. +20:49:55 <str4d> Of the available choices, my vote is for geti2p.net (and for http://geti2p.net/ rather than http://www.geti2p.net/ as it currently is) +20:50:06 <iRelay> Title: I2P Anonymous Network - I2P (at geti2p.net) +20:50:34 <dg> geti2p.net - 7 - hottuna, dg, inscrutus, zzz, asdfsdafsdafsd, Shinobiwan, str4d +20:50:34 <dg> i2p-projekt.de - 1 - lillith +20:51:34 <unresolved> ill go for geti2p.net +20:51:53 <Meeh> geti2p.net + meeh +20:52:55 <Meeh> In case you didn't get it , I vote for geti2p.net too +20:53:09 <dg> aye +20:53:12 <dg> geti2p.net - 9 - hottuna, dg, inscrutus, zzz, asdfsdafsdafsd, Shinobiwan, str4d, unresolved, meeh +20:53:15 <dg> i2p-projekt.de - 1 - lillith +20:53:18 <dg> Are we done? +20:53:21 <zzz> ech has a couple others too. i2pprojekt.net maybe? too bad those didnt get added to the list last week. +20:53:25 <orion> Vote? +20:53:28 <orion> What are we voting on? +20:53:32 <dg> zzz: if anybody cared to, they could have suggested it +20:53:39 <dg> orion: new project domain (official, main one used) +20:53:46 <zzz> in fact, step one, a couple of weeks ago, should have been to list all the domains we already have. +20:53:49 <orion> What are the choices? +20:54:00 <dg> orion: +20:54:00 <dg> - i2p.io +20:54:00 <dg> - i2p.int +20:54:00 <dg> - i2p.me +20:54:00 <dg> - geti2p.net +20:54:10 <iRelay> <user@kytv> re i2pprojekt.net - I have the same issue as zzz: the k instead of c +20:54:10 <dg> (or one you know of that is available!) +20:54:25 <str4d> - i2pproject.net +20:54:32 <str4d> - i2p-projekt.de +20:54:57 <str4d> (We have those two alongside geti2p.net and i2p2.de) +20:55:00 <lillith> i just think it should be a little different than the typical get[name].[com|net|org] +20:55:08 <suhr> i2p-project.org is avalible? +20:55:15 <dg> "-"s suck. +20:56:12 <iRelay> <user@kytv> I think geti2p.net and i2pproject.net are best, despite the double p +20:56:37 <iRelay> <user@kytv> but I'd go with the geti2p.net one +20:57:18 <str4d> AFK 5 mins +20:58:25 <Mathiasdm> 21:22 < hottuna> sponge, Mathiasdm, Meeh, RN: Domain votes? +20:58:28 <Mathiasdm> hm? +20:58:35 <orion> What about i2p.sg, i2p.vc, or i2p.mn? +20:58:56 <Mathiasdm> I won't vote, I haven't been active enough to contribute anything useful +20:59:07 <Meeh> ok, is there some simple webutility where we just can create a fast vote thing, and vote and be finished with it? :P +20:59:10 <hottuna> We're voting to change our official domain away from i2p2.de +20:59:17 <hottuna> every opinion is valuable Mathiasdm +20:59:24 <Mathiasdm> thanks for asking :) +20:59:42 <Mathiasdm> yes, but I'm someone with an uninformed opinion :) so I'll pass this one +20:59:45 <dg> I'm keeping note. +20:59:48 <Mathiasdm> I need to go afk again, I'm afraid +20:59:51 * Mathiasdm waves +20:59:55 <hottuna> bye +21:00:10 <dg> bye +21:00:21 <dg> be nice if we could see you again soon, Mathiasdm! +21:00:21 <Meeh> bye +21:00:24 <orion> What's the legal status on these TLDs? +21:00:57 <dg> AFK for 10 minutes or so. As str4d is gone and he's leading the next topic, feel free to talk about domains or whatever. +21:01:03 <dg> geti2p.net is winning, will likely be our decision. +21:01:28 <iRelay> <user@kytv> bye Mathiasdm! +21:03:28 <orion> Can we have the website be geti2p.net and have personal emails be directed to blah@i2p.io? +21:03:35 <orion> Like, press@i2p.io +21:04:11 <hottuna> i dont think we've ever hade personal email +21:04:22 <hottuna> not that it is a bad idea, it would be nice +21:04:29 <lillith> orion: why? +21:04:51 <hottuna> having them separated makes little sense in my mind +21:05:07 <iRelay> <user@kytv> I don't even know what .io stands for. input output? +21:05:11 <Meeh> personal email for active developers/contributors could be usefull +21:05:22 <Meeh> exceptly when it comes to PR etc +21:05:33 <lillith> i agree but surely meeh@geti2p.net +21:05:36 <Meeh> postman's service is nice... but great with imap and stuff +21:05:55 <lillith> a site with different email screams out scam to me +21:06:06 <suhr> i2p.io is nice, but we've got i2pmail.org... +21:06:23 <inscrutus> kytv: yeah input/output +21:06:30 <asdfsdafsdafsd> haha my thoughts too user.... +21:06:41 <lillith> suhr: it's not official. i agree there should be official emails for devs etc though +21:06:59 <unresolved> i2pmail ? :/ +21:07:06 <unresolved> is that really a good idea +21:07:13 <suhr> It should be avalibe in i2p. +21:07:23 <lillith> unresolved: it already exists +21:07:30 <Meeh> yea, but sure we can have two mail domains inside i2p +21:07:34 <unresolved> :/ +21:07:37 <suhr> (www.i2p2.i2p is a terrible address, anyway) +21:07:40 <inscrutus> isn't i2pmail.org already the postman mail gateway? +21:08:03 <str4d> Back +21:08:16 <iRelay> <user@kytv> inscrutus, it is +21:08:24 <hottuna> Do we have any other voters? +21:08:39 <asdfsdafsdafsd> so jrandom took i2p.i2p too when he went awol? +21:09:04 <lillith> str4d: the meeting was handed over to you :) +21:09:30 <str4d> K. I have to depart in the next ten mins anyway, so I'll be brief: +21:10:10 <str4d> The website is ready for transition (or at least, as ready as I can see) +21:10:30 <str4d> Translations are underway. +21:10:41 <lillith> str4d: how is the mobile site? +21:10:45 <str4d> The structure, urls etc. is set. +21:10:54 <str4d> lillith: I *haven't* worked on that, no. +21:11:05 <str4d> It's better than the current site, but the menu CSS still needs work. +21:11:44 <str4d> As does the desktop CSS +21:12:02 <str4d> So designers are more than welcome to get stuck in. +21:12:09 <str4d> But we decided previously that the theme is not a blocker. +21:12:46 <str4d> Currently, the redirects from the old URLs to the new ones (e.g. /how_threatmodel.html -> /en/docs/how/threat-model) are done with 302 redirects. +21:13:20 <hottuna> Ok +21:13:20 <str4d> I'm going to leave them like that until the site is live, so the URL redirects can be properly tested +21:13:27 <str4d> (But switching to a 301 is a simple addition of a parameter) +21:13:31 <hottuna> Have you heard anytinhg from echelon or weltende about deploying the site? +21:13:49 <str4d> weltende has said no website work before March +21:14:15 <str4d> (He said 2 weeks last week, but earlier in the meeting he said 1/3 which I assume means March) +21:15:33 <str4d> So there is still time for design work, more translations, and any other suggestions +21:15:36 <hottuna> ok +21:15:54 <Meeh> maybe a bit late, but I got a topic for the meeting.. we now got mailing list... should we start using them? +21:16:05 <Meeh> I've done setup the server at lists.i2p2.de +21:16:15 <hottuna> dg, are you back? +21:16:42 <hottuna> we've had no new +21:16:49 <hottuna> votes +21:16:56 <hottuna> wait, thats not true +21:16:59 <hottuna> geti2p.net - 9 - hottuna, dg, inscrutus, zzz, asdfsdafsdafsd, Shinobiwan, str4d, unresolved, meeh, user +21:17:09 <zzz> I dont know what 1/3 meant. But w/o him agreeing and doing the work for the site, or a new domain, or anything else we have nothing. +21:17:28 <hottuna> i2p-projekt.de - 1 - lillith +21:18:03 <Meeh> another question, who got access to geti2p.net, and what if that person goes awol? +21:18:09 <inscrutus> zzz: is it possible for others to pitch in to lessen the load on weltende? +21:18:27 <Meeh> witch load? +21:18:46 <zzz> dont know +21:18:56 <hottuna> Meeh, welterde/weltende +21:18:59 <lillith> Meeh: are we leaving the mailing list topic to the end? +21:19:06 <dg> I'm back. +21:19:14 <hottuna> how does shared dns-ownership work? +21:19:25 <hottuna> maybe shared access to a registrar account? +21:19:35 <iRelay> <user@kytv> Meeh: is this lists.i2p2.de reachable from withing i2p? +21:19:55 <dg> Not yet. +21:20:09 <iRelay> <weltende@freenode> can give you access to the relevant VM +21:20:38 <Meeh> lillith: we can leave it to the end yes. +21:20:52 <dg> So, website +21:21:03 <dg> Are we waiting on welt to be able to help us deploy? +21:21:20 <hottuna> I think we are +21:21:39 <Meeh> weltende, I can ssh into it and portforward the console and fix it if you want? +21:21:58 * dg nods +21:22:13 <hottuna> but we've reached a decision? +21:22:28 <dg> yes, geti2p.net +21:22:35 <dg> that is the majority +21:23:46 <iRelay> <weltende@freenode> Meeh: hmm? fix what? +21:24:25 <str4d> Last point about the website revamp - http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ has the latest, suggestions welcome. +21:24:36 <iRelay> Title: I2P Anonymous Network (at vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p) +21:24:36 <Meeh> tunnel, lists.i2p2.i2p or whatever +21:24:36 <Meeh> since it's not inside i2p yet +21:26:12 <inscrutus> str4d: very nice +21:26:33 <iRelay> <user@kytv> looks pretty good, str4d +21:27:02 <str4d> Thanks =) +21:27:20 <str4d> Post any suggestions in ticket #807 +21:27:24 * str4d is off now o/ +21:27:26 <iRelay> <weltende@freenode> Meeh: ah.. good point +21:27:26 <dg> o/ +21:27:29 <dg> So, IPv6? +21:27:32 <iRelay> http://trac.i2p2.i2p/ticket/807 - (accepted enhancement) - Revamp of website +21:27:35 <SkinSyste> thats awesome, should make the i22p.de homepage +21:28:06 <asdfsdafsdafsd> I like the color scheme str4d... +21:28:35 <asdfsdafsdafsd> are we doing away with the light or dark color scheme? +21:28:53 <inscrutus> dg: Is there an IPv6 + i2p summary I could read up on? +21:29:15 <dg> inscrutus: Yeah, hang on. +21:29:22 <Meeh> there is a IPv6 topic or two on zzz.i2p +21:29:37 <dg> http://zzz.i2p/topics/109 http://zzz.i2p/topics/594 +21:29:37 <hottuna> inscrutus, http://zzz.i2p/topics/109 +21:29:52 <iRelay> Title: zzz.i2p: I2P vs. IPv6: A bad joke (at zzz.i2p) +21:29:56 <iRelay> Title: zzz.i2p: IPV6 TODO (at zzz.i2p) +21:31:30 <suhr> How to get to "How does I2P work" page on that site? +21:31:33 <suhr> Menu isn't clickable. +21:32:15 <suhr> Ah, that's "Documentation index" +21:33:19 <suhr> It's a bit unintuitive. +21:34:01 <dg> Hm. That's for str4d for a ticket. +21:34:04 <dg> *or +21:34:16 <dg> IPv6.. +21:34:34 <dg> welt was the last (only?) dev to work on IPv6 + I2P +21:34:46 <dg> I don't know if anyone is willing to take it up aside from zzz (and he needs a box, ssh thru i2p in that case) +21:34:53 <dg> hottuna? Meeh? +21:34:55 <Meeh> yea, is someone interesting in a ipv6 hackfest? +21:35:13 <Meeh> I provide server +21:35:13 <hottuna> A hackfest seems like a nice idea +21:35:20 <Meeh> and help testing on other locations as well +21:35:46 <zzz> no, this is not time for a hackfest. We need an analysisfest and a decisionfest. +21:36:05 <Meeh> ok, well, do you want to lead that zzz? +21:36:27 <Meeh> and do you want a ssh account to a ipv6 server you can play with? +21:38:18 <zzz> yes to both. however probably not before April. +21:39:14 <Meeh> ok, why not before April? +21:39:21 <Meeh> and +21:39:40 <Meeh> how do we analyse what's needed to be analyzed? +21:39:55 <Meeh> IMO we should get i2p on ipv6 asap +21:40:21 <zzz> I'm probably about to lose a whole bunch of time but I have nothing more to say about it yet. +21:40:32 <Meeh> ah ok +21:40:44 <dg> hopefully won't be the case but :( +21:41:09 <zzz> for analysis, read and understand every work in thread 109 and then keep going and come up with a recommendation and reasoning +21:42:42 <zzz> s/work/word/ +21:42:45 <iRelay> zzz meant: for analysis, read and understand every word in thread 109 and then keep going and come up with a recommendation and reasoning +21:42:56 <Meeh> I support your option #3, from my limited experience with ipv6 +21:43:10 <Meeh> and I've read the thread +21:43:25 <zzz> it's mostly about how what change fits best into our code, not about ipv6 itself. +21:44:16 <zzz> it could also be about how to do NTCP/SSU with pigeons. +21:45:37 <suhr> Is there a big difference between ipv4 and ipv6 in java? +21:48:13 * suhr don't know I2P code. +21:52:54 <christoph4> I doubt the problem is the direct networking code +21:52:54 <zzz> no +21:53:28 <zzz> it's really a datastructure issue. +21:54:32 <christoph4> + there might be some fun with privacy extension and multiple valid addresses adround where you want to switch from time to time. And how you do a "one node per /16" on IPv6 address space +21:54:43 <zzz> do you want to organize by hi-level protocol NTCP/SSU, or low-level IPv4/v6, or both or neither +21:56:12 <zzz> right. the various places where we assume v4 all have to be fixed too, but that's just grunt work +21:57:07 <inscrutus> grunt work would be good for new devs to help get familiar with the code +21:57:10 <zzz> dg are we done I hope? +21:57:21 <dg> yeah +21:57:28 <dg> we've got nobody else +21:57:31 <dg> so.. yeah. +21:57:38 <hottuna> alright! +21:57:38 * zzz hands dg the *baffer +21:57:53 <dg> I'll cut down on what we have per-meeting next time, or maybe more poking? ;-) +21:57:56 * dg takes +21:57:56 <lillith> dg: so are crypto and mailing list rolling over to next week? +21:57:59 * dg *baf*s the meeting closed +21:58:02 <dg> lillith: Yup. +21:58:17 <hottuna> alright, you've managed to get us all to decide on a new domain +21:58:20 <hottuna> not bad at all :) +21:58:40 <dg> :) +21:58:51 <lillith> hottuna: it was a fairly unanimous decision ;) +21:59:08 <hottuna> getting us to make is the hard part +21:59:23 <inscrutus> dg: i think it's reasonable to not wait as long for stragglers +21:59:51 <lillith> inscrutus: or start earlier for stragglers +22:00:06 <lillith> ie start poking from half 7 ish +22:00:29 <inscrutus> lillith: that too +22:00:33 <dg> Perhaps trivial, non dev topics should be erlier +22:00:44 <dg> (Mailing list for example) +22:01:26 <inscrutus> dg: a good idea so to not scare off the non-devs :) +22:01:29 <dg> I need to know good times for zzz .. and whoever the other crypto/ipv6 guys are. Most of us can't contribute to discussion at all. +22:04:44 <zzz> dg, I don't know when the good times are either. str4d and tuna seemed to be making a little progress. +22:07:47 <zzz> dg I'm guessing 6-12 months will be required to come up with a solid plan. +22:08:13 <dg> zzz: That's resonable. Better late than never, and I'd rather us be planning than nothing at all. +22:09:25 <zzz> it's been on the list for years already. pushing more might help or might not. diff --git a/i2p2www/meetings/logs/219.rst b/i2p2www/meetings/logs/219.rst new file mode 100644 index 00000000..102acdd3 --- /dev/null +++ b/i2p2www/meetings/logs/219.rst @@ -0,0 +1,28 @@ +I2P dev meeting, February 12, 2013 @ 20:00 UTC +============================================== + +Quick recap +----------- + +* **Present:** + asdfsdafsdafsd, + christoph3, + dg, + eche|on, + h2ik, + hottuna, + inscrutus, + lillith, + Mathiasdm, + Meeh, + orion, + Shinobiwan, + str4d, + suhr, + unresolved, + user, + weltende, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, February 19 @ 20:00 UTC (8:00PM) diff --git a/i2p2www/meetings/logs/22.log b/i2p2www/meetings/logs/22.log new file mode 100644 index 00000000..a98a5bac --- /dev/null +++ b/i2p2www/meetings/logs/22.log @@ -0,0 +1,144 @@ +--- Log opened Tue Dec 03 23:52:14 2002 +23:52 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback +23:52 [Users #iip-dev] +23:52 [ codeshark2] [ Disposable] [ logger] [ nemesis] [ nop] [ root_] +23:52 [ Debolaz ] [ icepick ] [ mids ] [ Neo ] [ pox] [ UserX] +23:52 -!- Irssi: #iip-dev: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal] +23:52 -!- Irssi: Join to #iip-dev was synced in 3 secs +--- Day changed Wed Dec 04 2002 +00:01 < mids> Tue Dec 3 23:01:00 UTC 2002 +00:01 < mids> Welcome everybody +00:02 < mids> today we are going to talk about nice websites +00:02 < mids> atleast, until nop comes back in 8 minutes +00:02 < mids> now here comes my nice website: +00:02 < hezekiah> lol +00:02 < mids> http://www.longbets.org/ +00:02 < mids> "The purpose of the Long Bet Foundation is to improve long-term thinking" +00:03 < mids> consult the website for more information +00:03 < mids> . +00:03 < hezekiah> mids ... you need to take a course at an MC camp about "filling dead air." +00:03 < hezekiah> How's RC3? Do you know? +00:03 < mids> 1) you take a bottle of air +00:03 < mids> 2) you fill it with water +00:03 < mids> 3) the dead air is filled. +00:03 < mids> . +00:03 < hezekiah> Any feedback on the "pre" RC3? +00:04 < mids> someone asked how the upgrade could be done +00:04 < mids> otherwise no comments that I can remember +00:05 < mids> codeshark made some commits for the windows version of rc3 to CVS +00:05 < mids> like said last weeks: rc3 is near +00:05 < mids> only we lack developertime to release it :) +00:06 < hezekiah> The configure script should now support Linux, FreeBSD, and Mac OS X. If you want to try it, check out the "development" branch of CVS and give it a whirl! +00:06 < mids> I tried it +00:06 < mids> but I got all kind of errors +00:06 < hezekiah> When did you try it? +00:06 < mids> 3 days ago +00:06 < hezekiah> Hmmm ... what operating system? +00:06 < mids> linux +00:07 < hezekiah> Odd. Send me the errors. +00:07 < hezekiah> I'll look into it. +00:08 < mids> ./configure works fine... but takes quite long actually +00:08 < mids> compared with other opensource projects +00:08 < hezekiah> Hmm ... it should take only a minute or so. +00:08 < mids> yeah +00:08 < mids> but longer as other projects with the same size +00:09 < hezekiah> Do they have to do crypto? +00:09 < hezekiah> That can make a big difference. (A fair section of the time is spent finding OpenSSL, and finding integer types and making macros for them.) +00:09 < mids> hm nope +00:09 < mids> it compiles now +00:09 < hezekiah> Good! :) +00:09 < mids> but it refuses to bind to port 6667 +00:10 < mids> is the configuration file format changed? +00:10 < hezekiah> It should. +00:10 < mids> oh wait +00:10 < hezekiah> You already have isproxy running on port 6667 since your talking to me. (Unless you customized the isproxy you ran before.) +00:10 < mids> it is this NASTY timeout +00:10 < mids> that should really be fixed... +00:11 < mids> it works +00:11 < hezekiah> The timeout that occures when a copy of isproxy bombs out with the port still bound? +00:11 < mids> hip hip +00:11 < hezekiah> hurra! +00:11 < mids> yeah that timeout +00:11 < hezekiah> Ugh. You're right. +00:11 < mids> . +00:11 < mids> Other question that I got through some user: +00:12 < hezekiah> Well, that's the current state in developerland from my view folks! More at 11:00! +00:12 < hezekiah> What? +00:12 < mids> why does the entropy generation feed directly from the keypresses? +00:12 < mids> and not from /dev/random like GnuPG etc do? +00:12 < hezekiah> I don't know. UserX? +00:12 < mids> /dev/random uses mouse, network and other randomness too +00:13 < hezekiah> (Well, /dev/random doesn't use network if you say not to in the kernel; ... which I do.) +00:13 < mids> depens on the os I think +00:14 < mids> . +00:14 < UserX> reason for that is not all /dev/randoms produce secure random data +00:15 < hezekiah> Ah ... +00:15 < mids> UserX: then how does GnuPG handle it? I am sure they do it right :) +00:15 < hezekiah> Maybe we should make it check to see if the system does ... and use it if so. +00:16 < UserX> mids: i'm not sure. i'll look into that +00:16 < hezekiah> If it's in their configure script, then I might be able to find it. +00:16 < mids> great +00:16 < mids> I _really_ need to sleep now +00:17 < hezekiah> Bye, mids! : +00:17 < hezekiah> :) +00:17 < mids> night +00:17 < hezekiah> 'night. +00:17 < mids> (logfiles on http://mids.student.utwente.nl/~mids/iip/) +00:18 < hezekiah> (Meanwhile, our reports are still investigating the mysterious dissapearence of "nop"! We'll give you the breaking news "as it happens (r)!") +00:18 < hezekiah> [If no one has noticed yet, I'll be the first to admit: I don't do well at filling dead air.] +00:19 < hezekiah> I would like to officially thank the person who submitted a logo to the iip-dev mailing list. +00:19 < hezekiah> It's the best one I've seen yet. (Note: It's also the only one I've seen yet ...) +00:20 < hezekiah> Well, while we wait for nop ... +00:20 < hezekiah> ... Does anyone have question!? +00:21 < hezekiah> Anyone? +00:21 < hezekiah> Anyone at all? +00:21 < pox> bpb was writing a license. did it materialize? +00:22 < hezekiah> I wasn't aware of any license in the works. Currently, I beleive is IIP licensed under the GPL. +00:23 < hezekiah> Yup. IIP is licensed under the GPL +00:23 < nop> hi +00:23 < nop> ok +00:23 < nop> sorry +00:23 < hezekiah> The man is HERE! +00:24 < nop> alright +00:24 < nop> rc3 should be coming out today +00:24 < nop> it's getting tested as we speak +00:24 < hezekiah> Yay! +00:25 < nop> other than that +00:25 < nop> I don't think there's much to say this week +00:25 < nop> rather slow week +00:25 < nop> busy for most people +00:25 < nop> side note +00:25 < nop> life is good +00:25 < nop> :) +00:25 < nop> any questions +00:25 < nop> comments +00:26 < nop> . +00:26 < hezekiah> When can we expect IIP 1.1 final to be out? +00:27 < nop> hezekiah you tell me ;) +00:27 < nop> j/k +00:27 < nop> probably a few weeks after rc3 is released today +00:27 < hezekiah> I'm working on 1.2 development! +00:27 < nop> haha +00:27 < hezekiah> OK. :) +00:27 < nop> I know +00:27 < nop> I'm kidding +00:27 < hezekiah> You would! +00:27 < hezekiah> lo +00:27 < nop> pending bugs etc +00:27 < hezekiah> lol +00:30 < hezekiah> Does any else have a question? +00:30 < nemesis> hm... +00:31 < nemesis> plan codeshark a tut for fileserv? +00:40 < hezekiah> Well ... I'm off. Have fun everyone. ;-) +03:09 < nemesis> http://forum.pcwelt.de/fastCGI/pcwforum/topic_show.fpl?tid=82168&pg=5 loooooooooooooooooooooooooooooooooooooooooooooooooooooool +03:10 < nemesis> ups, sorry, an url ;) +03:10 < nemesis> *gg* +04:07 < nemesis> cu@all +04:11 * Disposable is listening to System of a Down - Spiders +13:17 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback +13:17 [Users #iip-dev] +13:17 [ Debolaz ] [ icepick] [ pox ] [ UserX] +13:17 [ Disposable] [ logger ] [ root__] +13:17 -!- Irssi: #iip-dev: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal] +13:17 -!- Irssi: Join to #iip-dev was synced in 8 secs +--- Log closed Wed Dec 04 19:49:58 2002 diff --git a/i2p2www/meetings/logs/22.rst b/i2p2www/meetings/logs/22.rst new file mode 100644 index 00000000..d7937069 --- /dev/null +++ b/i2p2www/meetings/logs/22.rst @@ -0,0 +1,9 @@ +I2P dev meeting, December 3, 2002 @ 23:01 UTC +============================================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/220.log b/i2p2www/meetings/logs/220.log new file mode 100644 index 00000000..4a641cba --- /dev/null +++ b/i2p2www/meetings/logs/220.log @@ -0,0 +1,134 @@ +20:25:01 <KillYourTV> Perhaps I'm in the minority but I think that if there are going to be meetings they *really* should start on time. +20:25:24 <inscrutus> Indeed +20:26:31 <KillYourTV> Not starting until 30-60 minutes after it _should have started_ looks bad, especially to outsiders that may be watching from the relayed networks. +20:27:21 <inscrutus> I don't remember who chaired last time. Are we waiting for him? +20:28:11 <lillith> ^this +20:28:28 <lillith> inscrutus: dg is often late +20:32:22 <hottuna> KillYourTV, yeah. I agree +20:33:01 <lillith> we could just start without dg, if anyone wants to just go for it +20:36:27 <inscrutus> I believe ipv6 was one topic left over from last meeting... +20:50:56 <dg> It was. +20:51:07 <dg> Most of it can't be done without zzz though, or str4d +20:52:25 * dg apologizes for being late - been out of it +20:52:40 <dg> Topics were/are: +20:52:43 <dg> * Syndie documentation (lillith) +20:52:43 <dg> * Mailing list (meeh) +20:52:43 <dg> * Feeds (str4d) +20:52:43 <dg> * Thoughts (anyone) +20:52:54 <dg> Meeh, lillith? +20:53:03 <dg> if you guys aren't here.. shit. +21:18:01 <Meeh> dg: I'm here now, sorry +21:18:20 <dg> np, is lillith? +21:18:23 <dg> I'm sorry, not you ;) +21:18:27 <Meeh> dunno +21:18:49 <inscrutus> lillith was, about 45m ago +21:18:49 <lillith> i am +21:19:08 <inscrutus> I stand corrected +21:20:10 <dg> \o +21:20:22 <dg> Hi all, sorry for delay +21:20:42 <dg> lillith is going to be speaking about Syndie doumentation +21:21:35 <lillith> is this my cue or are we having a full schedule first? +21:21:49 <dg> I've given the full one ;) +21:21:52 <dg> maybe it was lost +21:21:59 <dg> <+dg> Topics were/are: +21:21:59 <dg> <+dg> * Syndie documentation (lillith) +21:21:59 <dg> <+dg> * Mailing list (meeh) +21:21:59 <dg> <+dg> * Feeds (str4d) +21:21:59 <dg> <+dg> * Thoughts (anyone) +21:21:59 <dg> <+dg> Meeh, lillith? +21:22:02 <dg> <+dg> if you guys aren't here.. shit. +21:22:21 <lillith> ahh okay :) +21:22:24 <inscrutus> I saw it via kytv relay only.... +21:23:10 <lillith> right well since zzz and others have put so much work into syndie, i feel it is a shame that it is still so unused +21:24:01 <lillith> and since the gui is.. challenging for a begginer, i thought it may be a good idea to write/update the docs +21:24:47 <lillith> so now myself, KillYourTV, and aargh are working on a wiki +21:25:17 <lillith> hosted at *i don't have the b32 handy* +21:25:19 <dg> Wiki for exclusively Sundie? +21:25:23 <dg> s/Sundie/Syndie +21:25:54 <lillith> since it is a wiki i/we would appreciate if everyone could have a look and fix it if needed +21:26:01 <lillith> yes +21:26:16 <Meeh> I'm trying to make a map over the syndie archives at http://wiki.meeh.i2p/doku.php?id=syndie:known_archives +21:26:24 <iRelay> Title: syndie:known_archives [wiki.meeh.i2p] (at wiki.meeh.i2p) +21:26:43 <lillith> so, please do have a play on syndie and report back on f you feel the beginners guide is suitable for a short intro +21:26:50 <dg> A column for default or not may be useful +21:27:25 <dg> alright :) +21:27:44 <lillith> the current documentation is ufinished, so anthing we do is an improvement +21:28:27 <lillith> also KillYourTV: i assume the plan is to export the wiki into the official website at some point, is that correct and if so who do i need to speak to? +21:30:10 <lillith> Meeh: a column for filtering/blocking policy might be useful too +21:30:25 <Meeh> ok, but I don't know what to fill in there +21:31:03 <dg> ask around I suppose +21:31:26 <Meeh> gonna do it +21:31:53 <dg> thanks for giving Syndie some love lillith +21:32:01 <lillith> i'l tell you mine later, not here now :) +21:32:31 <inscrutus> lillith: is this the wiki b32? http://fomjl7cori4juycw55kdlczpgzzhme6nox6zykokuiov6t5lxhvq.b32.i2p/user_guide/ +21:32:34 <iRelay> Title: Syndie Handbook (at fomjl7cori4juycw55kdlczpgzzhme6nox6zykokuiov6t5lxhvq.b32.i2p) +21:33:02 <lillith> dg: it's actually pretty good, even if it is buggy. +21:33:23 <lillith> inscrutus: it is :) thanks +21:33:54 <KillYourTV> lillith: yes, once finished all documentation will ultimately end up on the 'official' syndie site (for now http://www.syndie.i2p/wiki/ will redirect to the wiki page) +21:33:57 <iRelay> Title: Syndie Documentation Project (at www.syndie.i2p) +21:35:14 <inscrutus> Ok, what's next, dg? +21:35:17 <lillith> so unless anyone else has anything to say on this, i can *baf* this topic :) +21:35:20 <dg> Meeh +21:35:31 <dg> (with mailing list) +21:35:43 <dg> lillith: thx :) - I'm enjoying reading the introduction +21:36:02 <dg> Meeh: Want to take the floor? +21:36:41 <Meeh> IIRC I'm waiting for weltende because I needed access to the router console for creating tunnels for making mailing list available inside i2p +21:37:42 <Meeh> and, we need to start to use it +21:38:36 <inscrutus> Is it a -dev mailinglist? Or just general i2p? +21:38:39 <dg> zzz and user said they were going to hold off until an inner-i2p presence appeared +21:38:42 <Meeh> both +21:38:56 <inscrutus> ok +21:39:04 <Meeh> ok +21:39:25 <Meeh> weltende: any chance for creating tunnels for the mailing list? +21:39:25 <Meeh> soon +21:41:01 <lillith> Meeh: what is the intention for the mailing list? as in compared to zzz.i2p or irc or syndie +21:41:37 <str4d2> apologies for absence - internet fail +21:42:00 <dg> str4d :) +21:42:11 <Meeh> personaly, I'm unsure.. But it seemed liked we came to the conclution that we should start with the mailing list stuff again, as other open source projects do... +21:42:33 <Meeh> don't remember which meeting it was +21:43:08 <inscrutus> Maybe it would be a good idea to mirror the mailing list to Syndie or vice versa. To avoid fragmentation +21:43:23 <str4d2> I'm unavailable in about 15 mins, btw +21:44:10 <Meeh> I like your idea inscrutus +21:44:41 <str4d2> (and can't make this meeting time in future) +21:45:11 <str4d2> that's a nice ideqla +21:45:14 <str4d2> idea* +21:45:53 <dg> It was suggested in the past, I believe it was going to be a part of Syndie anyhow. +21:46:04 <dg> Meeh: Anything more? +21:46:15 * lillith- really needs to remember to plug my laptop in.... reading scrollback on sighup... +21:47:11 <Meeh> no not really, I need to talk with weltende first +21:47:22 <lillith-> inscrutus: that was my next suggestion :) +21:47:41 <dg> Alright. +21:47:44 <inscrutus> :) +21:47:51 <lillith-> i think we could be 'dog-fooding' a little more +21:48:18 <dg> lillith-: ? +21:48:40 <lillith-> about the mailing list/syndie mirrorring +21:48:55 <dg> I'm not familiar with that expression +21:49:47 <lillith-> ahh the dog food principle of open source projects is, basically, use your own software +21:49:50 <inscrutus> it means to use your own product(s). It comes from a dogfood maker whose ceo i believe ate his company's own dogfood to prove it's good +21:50:01 <dg> oh.. to eat our own dog food +21:50:04 <dg> I agree +21:50:15 <lillith-> if we expect others to use it, we should too +21:50:35 <str4d2> Mmm +21:51:01 <str4d2> My problem with Syndie is that I have NFI how to use it +21:51:12 <dg> I need to check it out again +21:51:12 <dg> Anyhow.. +21:51:12 <dg> str4d2: You ok to do feeds now? After $next_thing, perhaps a new meeting time should be discussed. Not everyone is here though.. +21:51:15 <str4d2> The interface is not very intuitive. +21:51:18 <lillith-> str4d2: have you looked at the docs? +21:51:57 <str4d2> Somewhat, but we shouldnt expect users to all do that +21:52:00 <lillith-> dg: surely that is the reason we need a new time... +21:52:30 <dg> kind of. zzz and others are missing due to IRL issues too though - which makes it harder to agree on a new time which works for everyone. +21:53:01 <str4d2> and I'm busynow, sorry +21:53:01 <lillith-> dg: we could have a new temporary time and revisit it in a few weeks. +21:53:38 <lillith-> tues 8.00 isn't great for dg, str4d2, or me +21:55:51 <dg> it doesn't :-/ +22:03:14 <lillith-> has everyone gone to sleep or is that the end of the meeting? +22:03:29 <dg> Apparently sleep.. +22:03:36 <dg> We'll open a thread on zzz.i2p about it? +22:03:39 * lillith- picks up the baffer menacingly +22:03:42 <inscrutus> I'm here, just don't have anything to add to meeting times +22:03:49 <dg> It's just us three. +22:05:25 * dg *bafs the meeting closed +22:05:28 <lillith-> okay well if no-one has anything to add then i'l do the honours +22:05:51 * lillith- *bafs* the meeting +22:06:10 <lillith-> damn you got there first ;) diff --git a/i2p2www/meetings/logs/220.rst b/i2p2www/meetings/logs/220.rst new file mode 100644 index 00000000..2fe501e6 --- /dev/null +++ b/i2p2www/meetings/logs/220.rst @@ -0,0 +1,17 @@ +I2P dev meeting, February 19, 2013 @ 20:00 UTC +============================================== + +Quick recap +----------- + +* **Present:** + dg, + hottuna, + inscrutus, + KillYourTV, + lillith, + Meeh, + str4d + +* **Next Meeting** + The next meeting is on hold until a more suitable time can be chosen. diff --git a/i2p2www/meetings/logs/23.log b/i2p2www/meetings/logs/23.log new file mode 100644 index 00000000..f73b58cd --- /dev/null +++ b/i2p2www/meetings/logs/23.log @@ -0,0 +1,331 @@ +--- Log opened Tue Dec 10 23:32:22 2002 +23:32 -!- Topic for #iip-dev: http://www.patrick.fm/boobies/boobies.php?text=IIP <-- mmm, boobies, aka our new mascot! +23:32 [Users #iip-dev] +23:32 [@codeshark] [ icepick] [ Neo] [ pox ] [ UserX ] +23:32 [ Debolaz ] [ logger ] [ nop] [ sferic] [ xcasex] +23:32 -!- Irssi: #iip-dev: Total of 10 nicks [1 ops, 0 halfops, 0 voices, 9 normal] +23:32 -!- Irssi: Join to #iip-dev was synced in 2 secs +23:34 -!- mode/#iip-dev [+o mids] by Trent +23:34 -!- mode/#iip-dev [+v logger] by mids +23:53 < |EN3RGY|> wee +23:55 < mrflibble> lol, like the pic, is it ne1 we know? +23:55 * jeremiah_ wonders if this is working... using the metropipe JS interface... +23:55 < hobbs> jeremiah_ : you're sending, at least. :) +23:56 < jeremiah_> hobbs: looks like it works, meeting about to start? I'm at the public library +23:56 < hobbs> jeremiah_ : just a few minutes, yeah. +23:56 < Zwolly> i want to order an IIP mascot where can i buy them??? +23:57 < nop> hehe +23:57 < jeremiah_> hey nop +23:57 < nop> hi +23:57 < nop> I like the metropipe thing +23:57 < nop> rather neat +23:57 < jeremiah_> yeah it's cool +23:57 < hobbs> yeah, and amazing that it works. >:) +23:58 < nop> works real well +--- Day changed Wed Dec 11 2002 +00:00 <@mids> Tue Dec 10 23:00:04 UTC 2002 +00:00 <@mids> Welcome to the 23th IIP meeting +00:00 < dangermouse> 22:48 by my clock :p +00:00 < xcasex> thankyou +00:00 <@mids> Agenda: +00:00 <@mids> 1) Welcome +00:00 <@mids> 2) RC3 finally +00:00 <@mids> 3) Security Advisory +00:00 <@mids> 4) Network inconsistancies +00:00 <@mids> 5) Questions? +00:00 <@mids> . +00:00 <@mids> Logs are available on +00:00 <@mids> http://mids.student.utwente.nl/~mids/iip/ +00:01 <@mids> If you got questions related to the current agenda item, please ask +00:01 <@mids> otherwise safe them for the question round +00:01 <@mids> . +00:01 < nop> I'm gonna wait for a sec +00:01 <@mids> yeah, till they come back +00:02 < nop> k +00:02 <@mids> did you all see nop's IIP mascot submission? +00:02 <@mids> http://www.patrick.fm/boobies/boobies.php?text=IIP +00:02 < hobbs> nop : btw, whatever happened to those beeps in the MOTD? I actually liked them. +00:02 < jeremiah_> is it profane? I can't really look at profane stuff +00:02 < {Due}> hi all +00:02 < nop> oh, I think I fixed the problems +00:02 < hobbs> jeremiah_ : not suitable for a library. +00:02 -!- mids changed the topic of #iip-dev to: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +00:03 < nop> oh, got rid of our mascot +00:03 < nop> :( +00:03 < {Due}> here ppl only write in english? +00:03 -!- mids changed the topic of #iip-dev to: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ - IIP Mascot: http://www.patrick.fm/boobies/boobies.php?text=IIP +00:03 <@mids> {Due}: yeah +00:04 < |EN3RGY|> la mayoria si, {Due} +00:04 < {Due}> i really dont understand what is the meaning of this +00:04 < {Due}> :\ +00:04 <@mids> ok, me hands the microphone to nop +00:04 < nop> alright +00:04 < nop> Welcome +00:04 < nop> to the nth +00:04 < nop> hezekiah: you should know +00:04 < hezekiah> 23rd +00:04 < nop> meeting +00:04 < nop> of IIP +00:04 < nop> clockwork +00:05 < nop> mids, agenda please +00:05 <@mids> 1) Welcome +00:05 <@mids> 2) RC3 finally +00:05 <@mids> 3) Security Advisory +00:05 <@mids> 4) Network inconsistancies +00:05 <@mids> 5) Questions? +00:05 < |EN3RGY|> {Due} entiendes algo ? +00:05 < nop> ok +00:05 < {Due}> si |EN3RGY| +00:05 < nop> please try and save comments for the questions part +00:05 -!- mode/#iip-dev [+oo nop hezekiah] by mids +00:05 < {Due}> ahora hay "chala", wait +00:05 < |EN3RGY|> XD +00:05 <@nop> so we can get throught his +00:05 < |EN3RGY|> ok +00:05 < {Due}> ;) +00:05 <@nop> 2) RC3 finally!!! +00:05 <@nop> yeah +00:05 <@hezekiah> Yeah! +00:05 < |EN3RGY|> q paranoia ! +00:06 <@nop> RC3 is here and arrived in 50% less time than RC2 +00:06 < {Due}> |EN3RGY| /say yeah! +00:06 < {Due}> ke todo hay ke decirtelo :\ +00:06 <@mids> ok, be quiet people, I can barely hear nop +00:06 <@nop> hmm +00:06 < |EN3RGY|> yeah! +00:06 < |EN3RGY|> XDDD +00:06 <@nop> cayete +00:06 <@nop> or how ever you say it +00:06 <@nop> silencio +00:06 < |EN3RGY|> solo me entero +00:06 < |EN3RGY|> de algo sobre el RC3 +00:06 < jeremiah_> nosotros hablamos espanol tambien +00:06 < {Due}> |EN3RGY| silencio ;) +00:06 <@nop> they are translating ;) +00:06 <@nop> haha +00:06 < |EN3RGY|> ok +00:07 <@nop> ok +00:07 <@nop> anyway +00:07 < |EN3RGY|> ok jeremiah_ +00:07 <@nop> RC3 is here, and it includes what was requested as well as bugfixes +00:07 <@nop> version is definitely there this time :) +00:07 <@nop> so we're all happy +00:07 < {Due}> nop, before of that, waht is RC3 ? +00:07 <@nop> oh +00:07 <@nop> Release Candidate 3 of 1.1 +00:07 < {Due}> ajam +00:08 <@nop> the neat thing about it, is the next version will be ... +00:08 <@nop> 1.1 STABLE!!! +00:08 <@nop> 1.1.0 STABLE +00:08 <@nop> so we have room for error ;) +00:08 < Rav-> haha +00:08 <@nop> we'll take the freent approach +00:08 < {Due}> nop i know about this soft just 5 minuts ago, plz tell me what this does +00:08 <@nop> build 500392938103967 +00:08 <@nop> Due - http://help.invisiblenet.net +00:08 <@mids> {Due}: we will help you later +00:08 < {Due}> oka +00:09 <@nop> ok +00:09 <@nop> 3) Security Advisory +00:09 <@nop> accidentally came upon some weaknesses in Adelphia's PowerLink Network that is crucial to privacy +00:09 <@nop> so I felt the need to send them an advisory +00:09 <@nop> and post it to iip-dev list +00:09 < Debrys> Due: http://www.invisiblenet.net/iip/aboutMain.php take a look at this page....... and also the interview and docs....... most of the things you're asking yourself get answered there :) they're really no nonsense page..... pure info and straight to the point +00:10 <@nop> anyway +00:10 <@nop> if any users use adelphia +00:10 * {Due} reading ;) +00:10 <@nop> that is the reason I posted it +00:10 <@nop> for the benefit of our users +00:10 <@nop> as they host 5.5 million customers +00:10 <@nop> so we might have a few +00:11 <@nop> hopefully they will adhere to the advisory and fix it +00:11 <@nop> if not +00:11 <@nop> it will be publicized 30 days from the date +00:11 <@nop> which will apply a bit of pressure to fix the problem +00:11 <@nop> moving on +00:11 <@nop> Connection issue +00:11 <@nop> with the upgrade +00:11 <@nop> a lot of people probably have been shutting off their previous rc2 relay +00:11 <@nop> and turning on rc3 +00:12 <@nop> this probably will happen over a span of a couple weeks +00:12 <@nop> most people aren't consistant with keeping track of upgrade day +00:12 <@nop> also +00:12 <@nop> there were a few times this past week that the colocation facility of the ircd server had some network maintenance +00:12 <@nop> this caused a few hiccups +00:12 <@nop> and it may have beend difficult to get on +00:12 <@nop> this is over +00:13 <@nop> and it should be pretty clean (other than relays dropping from time to time) +00:13 < jeremiah_> will a relay notify the admin when it should be updated? +00:13 <@nop> as in the IIP software notify? +00:13 <@mids> currently, no +00:13 <@nop> the relay admin? +00:13 <@nop> that should be optional +00:13 <@nop> for debatable anonymity reasons +00:13 < jeremiah_> yeah, but it isn't an option right now, correct? +00:13 <@codeshark> nop: maybe a simple version check would help +00:13 <@nop> correct it is not +00:14 <@nop> definitely an option that could appear in 1.1 +00:14 <@nop> stable +00:14 <@nop> but I can't promise that +00:14 <@nop> as we want to keep changes to a minimum +00:14 < jeremiah_> ok +00:14 <@mids> I suggest we dont put it in +00:14 <@mids> only fix bugs +00:14 <@nop> as well do I for this version +00:14 <@codeshark> yes, no new features +00:15 <@hezekiah> I agree. +00:15 <@nop> ok +00:15 <@mids> are there any bug reports yet? +00:15 <@nop> I know that codeshark had one +00:15 <@codeshark> yeah, couldn't send mail, damn invisiblenet ;) +00:16 <@nop> haha +00:16 <@nop> send it when you can +00:16 <@nop> there's a couple of firewall questions +00:16 <@codeshark> iip.log, isproxy.ini, mynode.ref, seed.rnd are stored in current directory instead of ~iip/.iip dir +00:16 <@nop> I think we might have to be more clear that 6667 isn't the only connection that should be open +00:17 <@nop> can you officially send it as an email +00:17 <@nop> it helps for tracking +00:17 <@codeshark> doesn't work ;) +00:17 <@nop> mail shoudl work +00:17 <@mids> nop: do you mean firewall rules for outgoing connections? +00:18 <@nop> yes +00:18 <@mids> ok +00:18 <@nop> I don't think all users realize how it works +00:18 <@mids> yeah we can add that to the firewall chapter of the FAQ +00:18 <@nop> ok +00:18 <@mids> or create that one if it doesnt exist +00:18 <@nop> anyway, cs can you submit it to our sourceforge bug report page +00:18 < {Due}> ok, one second +00:19 < {Due}> may i ask something? +00:19 <@nop> hold +00:19 <@nop> what's next on agenda +00:19 <@mids> question round! +00:19 <@nop> ok +00:19 <@nop> due +00:19 < {Due}> ;) +00:19 <@nop> you can ask +00:19 < {Due}> oka +00:19 <@codeshark> nop: ok +00:20 < {Due}> 1) mids says tha this servers is anonymoues +00:20 < {Due}> anonymous +00:20 < {Due}> <mids> we dont know where the server is +00:20 < {Due}> newsserver1.ussc.com +00:20 <@nop> that's a relay +00:20 <@nop> 1 of many +00:20 <@nop> your peers protect you +00:20 * Neo stands in question queue +00:21 < {Due}> but what is the meaning of all that? +00:21 < {Due}> i mean, all the ircu servers +00:21 <@mids> I'll try to help {Due} in private +00:21 < {Due}> has vhost +00:21 < {Due}> oka mind +00:21 <@nop> neo yes +00:21 <@mids> pop queue, neo +00:21 < Neo> Ok. +00:22 < Neo> nop: can you please give us: +00:22 < Neo> diff 'invisible internet' 'tarzan' +00:22 < Neo> thoughts please. +00:22 <@nop> I need to finish my read on tarzan before I can answer that +00:22 <@nop> but they are similar +00:22 <@nop> but I find some problems with tarzan +00:22 * jeremiah_ would like a url that describes tarzan +00:23 <@nop> neo do you have the url handy +00:23 < Neo> http://www.pdos.lcs.mit.edu/tarzan/index.html +00:23 < jeremiah_> thank you +00:23 <@nop> I'll tell you what neo +00:23 <@nop> when I finish my read +00:23 <@nop> I will send you an email +00:23 <@nop> on my thoughts +00:24 <@hezekiah> What if you just submit the email to iip-dev? +00:24 <@nop> ok +00:24 < Rav-> can i make a suggestion +00:24 < Rav-> for the node.ref etc files +00:24 <@nop> there are aspects that can be fully utilized from tarzan +00:24 < Neo> nop: thanks +00:24 < Rav-> store them in user home directories +00:24 <@hezekiah> That would be nice. +00:25 < Rav-> so its easier to secure a proxy +00:25 < Rav-> and have it update noninteractively +00:27 < Debrys> ahem:....... it would be nice if i could use IIP withouth installation and copied file....... i.e. copy the files on a disk......... go to someone with a pc and irc-client........ run IIP from disk withouth any files copied to the hard-disk....... so i would be thankfull if this user-home-dirs thingie would be an option +00:29 <@mids> currently it _should_ look in several places +00:29 <@mids> current directory, homedir +00:29 <@mids> and system wide directory +00:29 <@mids> I dont remember in what order that happens +00:29 < jeremiah_> it would also good to be able to run the system from memory w/o config files so someoen could use it and then delete it easily (not sure how possible this is right now) +00:29 < Debrys> okay, thanks for the info mids +00:30 <@nop> knoppix +00:30 <@nop> www.knoppix.net +00:30 <@mids> Debrys: but codeshark just reported a bug on that, so it might not work :) +00:30 <@codeshark> Debrys: yes, there's a problem with this feature +00:30 <@codeshark> some files are stored in local directory +00:30 < xcasex> jeremiah_: just mount a portion of ram to the filesystem D: +00:30 < xcasex> :D +00:30 < Debrys> well, i'm okay if i know it will work in the future :) +00:31 < Debrys> its just a possibility i would miss if it would be discarded in future development +00:31 < Rav-> from memory only the node.ref file needs to be local.. is that right? +00:32 <@nop> 7and listen.ref +00:32 <@nop> and +00:32 < Debrys> cs: local dir is okay....... because the local dir would be the diskette? +00:32 <@nop> and isproxy.ini +00:32 < Rav-> yeah thats right +00:32 < Rav-> 3 files +00:32 <@nop> although +00:32 < Debrys> the only problem would be if its run from a cd........ but thats okay to me +00:32 <@mids> you can specify the file location if you run isproxy +00:32 <@mids> try: isproxy -h +00:32 <@mids> if will give an overview of options +00:33 < Debrys> °nods° +00:33 < Rav-> atm i have those 3 files rw for users since iip starts as a user daemon not a system daemon +00:34 <@nop> ok +00:34 <@nop> I'll bb in a bit +00:35 <@mids> other questions? +00:35 < Debrys> not for now or 1.1 +00:35 < Rav-> mmm... update notification? +00:35 < Rav-> wouldnt be anonymous i guess +00:36 <@mids> Rav-: the server could send a control message +00:36 < Rav-> okay +00:36 <@mids> atually it already sends the version I think +00:36 <@mids> but then again +00:36 <@mids> if I run a public relay +00:37 <@mids> what should the relay do if it sees that it is too old? +00:37 < Rav-> you could include it in node.ref +00:37 < Rav-> dunno +00:37 < jeremiah_> it could be given the option of emailing the admin +00:37 < jeremiah_> or anonymail +00:37 <@mids> yeah maybe +00:37 < Debrys> what if clients get to know about a new version from other clients..... not the server? this could also work in a decentralized network........ since if update notification is server dependant it wouldn't work when IIP goes decentralized? +00:38 < Rav-> yeah thats why i was thinking node.ref +00:38 <@mids> I dont think it is possible to do it in a decentralized environment +00:38 <@mids> unless you sign those messages by the IIP development team +00:38 <@mids> since otherwise it would be too easy to send fake messages +00:38 < hezekiah> Right +00:39 < Debrys> thats true +00:39 < Rav-> hmm +00:39 <@mids> actually +00:39 <@mids> once it is fully distributed +00:39 <@mids> it could well be that there are multiple version +00:39 < Debrys> but would it be THAT evil if a fake "new version" message is received? except of being annoying? +00:39 <@mids> +s +00:39 <@mids> and clones etc +00:40 <@mids> Debrys: it would be easy to do, and make it not useful anymore +00:40 < Rav-> that should be a good case for update notification +00:40 < Debrys> okay +00:40 <@mids> what would be better is the admins subscribing to the IIP development mailinglist +00:40 < Rav-> dont know how you would dist the message +00:40 <@mids> :) +00:40 <@mids> maybe we should make other mailinglists in the future +00:40 <@mids> like iip-announce +00:41 < xcasex> dont forget the-iip-133+3 +00:41 * jeremiah_ has to go +00:41 < jeremiah_> bye +00:41 < jeremiah_> will login later +00:41 < Rav-> when you say distributed, do you mean as part of a decentralised iip network or do you mean you are releasing the server daemon for use on other networks +00:41 < hezekiah> bye +00:44 <@mids> Rav-: decentralized +00:46 < hezekiah> Well, I'm off. Bye everyone. +00:47 <@mids> ok +00:47 <@mids> hereby I declare the meeting beeing over +00:47 <@mids> see you next week, same time, same place +00:48 <@mids> feel free to hang around a bit +00:48 <@mids> and if there are more questions / comments, ask em in #iip or #anonymous +--- Log closed Wed Dec 11 00:48:34 2002 diff --git a/i2p2www/meetings/logs/23.rst b/i2p2www/meetings/logs/23.rst new file mode 100644 index 00000000..2865ec65 --- /dev/null +++ b/i2p2www/meetings/logs/23.rst @@ -0,0 +1,9 @@ +I2P dev meeting, December 10, 2002 @ 23:00 UTC +============================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/25.log b/i2p2www/meetings/logs/25.log new file mode 100644 index 00000000..02ca2388 --- /dev/null +++ b/i2p2www/meetings/logs/25.log @@ -0,0 +1,141 @@ +--- Topic for #iip-dev is IIP Meeting - logfiles: +http://mids.student.utwente.nl/~mids/iip/ +<nemesis> nop, no meeting today? +<nop> yes +<nop> sorry +<nop> ok +<nop> welcome +<nemesis> hi nop ;) +<nop> hi +<nop> agenda +<nop> 1) welcome +<nemesis> whats going on? everybody sleeps? +<nop> 2) Happy New Year +<nop> 3) Happy Holidays +<chscrtr> hi, happy new year +<nop> 4) IIP +<nemesis> hehe, happy new year too +<mrflibble> happy new year! :) +<nop> 5) IIP logo contest +<nop> 6) CryptoCon +<nop> 4) IIP +<nop> ok IIP +<nop> it's kind of stagnant because of the holidays +<nop> but I believe we're picking it back up +<nop> any bug reports please send to iip@invisiblenet.net +<nop> ok +<nop> 5) IIP logo contest +<nop> we'll being putting up something on our site about the rules etc +<nop> and display the drawings we have so far +<nop> please help out if you can +<nop> get a free t-shirt and your logo on it +<nop> 6) CryptoCon +<mrflibble> cool +<nop> we're trying to get a program committee and some organizational +planning for Jan 2004 to have cryptocon happen +<nop> join #cryptocon for any assistance etc +<nop> anyway, that's about it +<nop> questions? +<nop> questions? +<nop> ;) +<mrflibble> nope +<nop> ok +<nop> meeting ajourned +<Neo> nope +<Neo> thanks. :) +<mrflibble> np +<mrflibble> oo, 1 thing +<mrflibble> about cryptocon +<mrflibble> is there a particular reason for organising your/your own? +<mrflibble> there are general crypto confs out there that cyou could submit +stuff 2 +<nop> well +<nop> we want to attract businesses to meet cipherpunks +<nop> and push cryptography more than it is +<nop> this will be different +<mids> fsck +<mrflibble> gotcha +<nop> missed it +<nop> ;) +<mids> sorry folks :) +<mrflibble> it will just be a lot of work 4 u all +<mids> is there still a point in bringing the logger here? +<mrflibble> lol +<nemesis> hehe +<nop> well mrflibble I don't think it will be +--- Log opened Wed Jan 08 00:14:47 2003 +00:14 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +00:14 [Users #iip-dev] +00:14 [ chscrtr] [ logger] [ mrflibble] [ Neo] [ Nostradumbass] [ w ] +00:14 [ co ] [ mids ] [ nemesis ] [ nop] [ UserX ] [ wilde] +00:14 -!- Irssi: #iip-dev: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal] +00:15 < nop> we have a year to plan +00:15 < mrflibble> true +00:15 -!- Irssi: Join to #iip-dev was synced in 43 secs +00:16 < nop> plus we need to raise money +00:16 < nop> and this might help +00:16 < nop> since no one likes to donate +00:16 < nop> ;) +00:16 < chscrtr> error - less than a year +00:16 < nemesis> hm... nop, you are using knoppix right now, or? +00:17 < mrflibble> ic +00:17 < nop> suse right now +00:17 < mrflibble> u might need to advertise a lot to get the sponsers +00:17 < mrflibble> which will cost +00:18 < nemesis> are you think that iip is important/stable enough to show it the world? +00:18 < chscrtr> not that much, PR can be cheap +00:18 < nop> nemesis I don't think I'm showing it to the world +00:19 < mrflibble> hmm, i hope so +00:19 < nop> It's a conference, separate concept +00:19 < mids> ok, lizzy__ raised the point that the idleing time might give away too much information +00:19 < nemesis> hehe +00:19 < nop> yes it does +00:19 < mids> so (s)he suggested to disable it server side +00:19 < nop> we can take that out +00:19 < nop> I've been wanting to do that +00:19 < nop> ok +00:19 < nemesis> cause, it would be nice when future releases are packed for trustix ;) +00:19 < nop> will work on it +00:19 < mids> also that registering your nickname pinpoints you and makes you more traceble +00:19 < mids> so there should be a warning against that +00:19 < mids> . +00:20 < mids> I suggest that we metion the possible risks and issues more clear in the documentation +00:20 < mids> mention +00:20 < mrflibble> why is registering mae u more traceable? +00:20 < mrflibble> make +00:20 < mids> mrflibble: because once you identify, then you are guaranteed the same person as before +00:21 < mids> while if you just use the same nick, you might not be the same person +00:21 < mids> registering and identifying makes you pseudonymous +00:21 < mids> instead of anonymous +00:21 < mrflibble> oh +00:21 < mrflibble> but that's good tho +00:21 < mrflibble> trust is important +00:24 < mids> yes, but you build a public record of information +00:24 < mids> each time that you connect and say something, you add more info +00:24 < mids> there are tools which can identify the identity of people based on language patterns. +00:25 < mids> the ones that I tried are not that good, but it is often quite easy to spot errors and make conclusions. +00:25 < mids> I believe that it wouldn't harm to add a chapter about the risks even in an 'anonymous' environment to our manual +00:25 < mids> and I invite lizzy__ to start with that chapter. +00:25 < mids> . +00:25 < Nostradumbass> That's why passing your text through multiple language translators can be useful +00:27 * mids passes the microphone back to the audience +00:28 < mids> oh, excuse for joining that late, if someone can send me the logs of the first 15 minutes then I would much appreciate it. +00:28 < mids> . +00:29 < mrflibble> ooh +00:29 < mrflibble> gotcha +00:29 < mrflibble> mids, make that about 5 minutes :) +00:29 < mids> heh. +00:30 < mids> did nop already say something about 1.1-final? +00:30 < mids> like when we claim that it will be released ;) +00:31 < mrflibble> nope +00:31 < mrflibble> ill send u a capture +00:31 < mids> gracias +00:31 < mrflibble> shit, i cant +00:31 * mrflibble slaps mrflibble around a bit with a large trout +00:31 < mrflibble> ill cut and paste +00:32 < mrflibble> hope i dont flood myself off +00:32 < mids> in private please +00:32 < mids> okay, now this unofficial meeting is officially closed +00:32 < mids> :) +00:32 < nemesis> looool +--- Log closed Wed Jan 08 00:33:43 2003 diff --git a/i2p2www/meetings/logs/25.rst b/i2p2www/meetings/logs/25.rst new file mode 100644 index 00000000..a03f29c5 --- /dev/null +++ b/i2p2www/meetings/logs/25.rst @@ -0,0 +1,9 @@ +I2P dev meeting, January 7, 2003 +================================ + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/26.log b/i2p2www/meetings/logs/26.log new file mode 100644 index 00000000..9c051e54 --- /dev/null +++ b/i2p2www/meetings/logs/26.log @@ -0,0 +1,260 @@ +--- Log opened Tue Jan 14 22:44:57 2003 +22:45 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +22:45 [Users #iip-dev] +22:45 [ logger] [ pox] +22:45 -!- Irssi: #iip-dev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal] +22:45 -!- Irssi: Join to #iip-dev was synced in 3 secs +23:48 -!- StoVoKor|away is now known as StoVoKor +23:58 < mids> Tue Jan 14 22:58:16 UTC 2003 +23:59 < mids> 1 minute +--- Day changed Wed Jan 15 2003 +00:00 < mids> Tue Jan 14 23:00:00 UTC 2003 +00:00 < mids> Welcome to the 26th IIP meeting +00:00 < mids> I didn't get any agenda items from anybody, so I'll just propose my own: +00:00 < mids> - Release of 1.1-final +00:00 < mids> do you guys have anything else to add? +00:00 < hezekiah> (I propose an agenda item: What's the current major feature being worked on in IIP 1.2 dev?) +00:01 < mids> great +00:01 < FillaMent> I have a couple suggestions for additions to anonymail +00:01 < mids> ok +00:01 < mids> Agenda: +00:02 < mids> - What's the current major feature being worked on in IIP 1.2 dev +00:02 < mids> - Anonymail suggestions +00:02 < mids> - Release of 1.1-final +00:02 < mids> . +00:02 * mids hands the microphone to hezekiah +00:02 < FillaMent> Also like to note a project that I'm working on that uses IIP +00:02 < hezekiah> I have no clue. It was actually a question. :) Nop? +00:02 * hezekiah hands the microphone to nop. +00:02 < nop> hi +00:02 < nop> ok +00:02 < nop> welcome +00:03 < nop> ok on the agenda +00:03 < nop> mids take it away +00:04 < mids> no, you tell what the status of 1.2 is +00:04 < nop> ok +00:04 < nop> well +00:04 < nop> lots of grindy stuff +00:04 < nop> mainly taking care of the grunt stuff +00:04 < hezekiah> (Ahmen!) +00:04 < nop> getting the core ready for hardcore decentralization and crypto, we're in the midst of deciding crypto libraries, we think cryptlib and GnuMP +00:05 < nop> and are looking at a few possibilities for routing, either the listener route concept, or possibly chord type routing +00:05 < nop> and that's mainly it for right now +00:05 < nop> for 1.2 +00:05 < mids> cool +00:05 < nop> 1.1 status, is if no one has any bugs in a weeks time +00:06 < nop> then we will probably move to defcon 1.1 +00:06 < nop> ;) +00:06 < nop> meaning 1.1 Release +00:06 < mids> stick to the agenda nop +00:06 < mids> anonymail features are first +00:06 < nop> I didn't see an agenda +00:06 < mids> :p +00:06 < hezekiah> Mids, behave! :) +00:06 < hezekiah> ;-) +00:06 < nop> ok +00:06 < nop> I guess anonymail suggestions +00:06 < mids> - Anonymail suggestions +00:06 < nop> take it away whoever that was +00:06 < mids> FillaMent? +00:06 < FillaMent> Okay, I just have two quick ones... +00:07 < FillaMent> 1) Some sort of escape character to do \n's. +00:07 < hezekiah> Yeah! +00:07 < FillaMent> Discuss or move on to #2? +00:07 < hezekiah> Perhaps, "\n" for a newline, and "\\n" for a literal, "\n". +00:08 < mids> what character do you suggest? +00:08 < mids> ok +00:08 < hezekiah> (Like how you would do in C with printf.) +00:08 < FillaMent> C, Perl, Java.... +00:08 < hezekiah> C++ ... :) +00:08 < FillaMent> Nah, make it vbCRLF +00:08 < mids> and \\\\n for literal \\n :) +00:08 < hezekiah> Yup1 +00:08 < mids> vbCRLF? +00:09 < FillaMent> visualbasicCarriageReturnLineFeed +00:09 < mids> are you serious? +00:09 < hezekiah> (I hope not.) +00:09 < FillaMent> I used to hack vbScript (no, I'm not serious. \n is what everyone will be familiar with) +00:09 < hezekiah> So, what was suggestion number 2? +00:10 < thecrypto> damn wireless network +00:10 < FillaMent> 2) Stripping non-plain text MIME garbage from mails that come from the internet and replacing it with something to the effect of <One part MIME binary/word-doc stripped> +00:11 < FillaMent> Forgive me if I'm incorrectly implying MIME +00:11 < mids> I dont really agree +00:11 < mids> you should be able to receive RFC2015 compatible PGP signatures +00:11 < mids> and stuff +00:11 < hezekiah> Yeah. +00:12 < hezekiah> But changing Quoted-Printable to plain ASCII might not be a bad idea if it isn't already implemented. +00:12 < FillaMent> And that's a specific mime type? +00:12 < FillaMent> PGP sig I mean. +00:12 < mids> it is +00:12 < hezekiah> There are OpenPGP sigs that have a mime type. +00:12 < mids> I can understand that it will be a lot of work to do MIME right +00:13 < mids> since there are a lot of MIME types +00:13 < mids> and browsers who violate it +00:14 < hezekiah> "2) Stripping non-plain text MIME ..." (Wouldn't they be in base64 if they aren't plain ASCII anyway? And if not, then couldn't they just be converted?) +00:14 < mids> maybe we should just forward the suggestions to codeshark +00:15 < mids> since he knows how the app looks +00:15 < hezekiah> Or even, if it has to be stripped, you could offer an option to retrieve it (in base64 or 7-bit.) That way you can save it via copy-paste, and decode/read it on your hard drive. +00:15 < mids> (he made it) +00:15 < mids> and what he can implement +00:15 < hezekiah> Good idea! +00:15 < FillaMent> The other day I got a mail that was written with MS Outaluck/W3rd and it came in as multipart MIME. The first part was a plain txt version of the message, the second was an RTF will all the formatting Markup +00:15 < nop> this is something +00:15 < nop> that needs to be sent to anonymail +00:15 < nop> oops +00:15 < nop> codeshark +00:15 < mids> yeah +00:15 * FillaMent digresses. +00:15 < mids> lets just pass it on +00:15 < mids> and see what his imput is +00:16 < mids> - Release of IIP 1.1-final +00:16 < mids> my comments: got to check the sourceforge bugtracker +00:16 < mids> but I dont think that there are any code bugs open +00:17 < hezekiah> Not the last time I saw ... (checking now.) +00:17 < mids> http://sourceforge.net/tracker/index.php?func=detail&aid=651711&group_id=50945&atid=461514 +00:17 < mids> (files stored in wrong dir) +00:17 < mids> http://sourceforge.net/tracker/index.php?func=detail&aid=655568&group_id=50945&atid=461514 +00:17 < mids> (-h doesnt work) +00:17 < mids> that option DOES work for me +00:17 < mids> please check it +00:18 < mids> and if it works for everybody, we got to mark that report as invalid +00:18 < mids> http://sourceforge.net/tracker/index.php?func=detail&aid=654147&group_id=50945&atid=461514 +00:18 < mids> (FreeBSD socket call) +00:18 < mids> I dont have FreeBSD, someone with FreeBSD should check +00:19 < mids> . +00:19 < mids> Also we should really really supply some script that people can put in their /etc/init.d/ +00:20 < mids> ping? +00:20 < hezekiah> It looks like the guy who did the FreeBSD bug ... +00:21 < hezekiah> ... already found and pointed out the problem. +00:21 < hezekiah> http://sourceforge.net/tracker/download.php?group_id=50945&atid=461514&file_id=37660&aid=654147 +00:22 < hezekiah> That's the link to the patch file. AF_INET apparently needs to be PF_INET on FreeBSD. +00:22 < hezekiah> The patch was simple: +00:23 < hezekiah> 484,489c484 +00:23 < hezekiah> < // If statement added by wiht, since FreeBSD uses PF_INET. +00:23 < hezekiah> < #ifdef __FreeBSD__ +00:23 < hezekiah> < sh->Socket = socket(PF_INET, SOCK_STREAM, 0); +00:23 < hezekiah> < #else +00:23 < hezekiah> < sh->Socket = socket(AF_INET, SOCK_STREAM, 0); +00:23 < hezekiah> < #endif +00:23 < hezekiah> --- +00:23 < hezekiah> > sh->Socket = socket(AF_INET, SOCK_STREAM, 0);//PF_INET); +00:23 < mids> I see, but then I dont know why the original ifdef was there at first? +00:23 < hezekiah> What do you think, nop? +00:23 < hezekiah> The top section should be the new code. The bottom section should be the old. +00:23 < nop> that should work +00:24 < hezekiah> Yeah. The bottom is the old. +00:24 < nop> you should commit looks fine +00:24 < hezekiah> Do you want me to write it up, commit, and label the bug as fixed, nop? +00:24 < nop> but why is it different +00:24 < hezekiah> Apparently, FreeBSD requires PF_INET instead of AF_INET as the first arguement for socket. +00:25 < hezekiah> I don't know why. +00:25 < hezekiah> But, the writter said this fixed the problem. Commit? +00:25 < nop> yes +00:25 < hezekiah> OK. +00:25 < mids> ok +00:26 < mids> who can look into the filepath problem? +00:27 < FillaMent> I don't get that problem. If I try and start IIP as a different user or not in ~iip it says it can't write the log +00:28 < mids> ok, we got to check the reported bugs and report on that on the mailinglist +00:28 < mids> lets try to do that this week +00:28 < mids> . +00:28 < mids> The biggest problem is the scalability of IIP +00:28 < mids> RC2 was kinda stable +00:28 < mids> RC3 isnt +00:29 < mids> why? +00:29 < mids> Imho it is because the node.ref is so big +00:29 < mids> so a lot of potential bad node +00:29 < mids> nodes +00:29 < mids> it is really, anonymity vs stability +00:29 < mids> . +00:29 < hezekiah> I noticed that. But some of them are just slow, not necisarily bad. +00:29 < mids> the problem is the lot of people Pinging Out +00:30 < mids> the solution that I suggest is releasing RC3 with a minimal node.ref +00:30 < mids> only 4 nodes or something +00:30 < mids> . +00:31 < nop> I agree +00:31 < FillaMent> Pardon my lack of design knowledge... IIRC uses relays like freenet and IRC, right? +00:32 < FillaMent> node == relay +00:32 < mids> they are more static +00:32 < mids> once you connect +00:32 < nop> well +00:32 < nop> at least in 1.1 +00:32 < mids> you stay connected through them for the same session +00:32 < nop> they won't be forever +00:32 < FillaMent> But, it's still one node passes to other nodes +00:32 < nop> yes +00:33 < mids> if you keep a big list of nodes, then the path is very long +00:33 < mids> hence a lot of potential problems +00:33 < FillaMent> Why not just make it so that it goes through the node.ref and picks a few at random, and keeps doing that. The user could maybe set the number. This would maybe distribute the load a little more? +00:34 < mids> the current protocol doesnt support selecting the amount of hops +00:34 < nop> and we're not changing it in this version +00:34 < nop> ;) +00:34 < FillaMent> Okay, then it's outside my technical knowledge... what about the starting point? +00:34 < FillaMent> or is the TTL the number or nodes in node.ref +00:35 < FillaMent> s/or/of/ +00:35 < mids> each node connects to a node in its node.ref at random +00:35 < mids> until it 'accidently' hits the server +00:35 < mids> so if you have a lot of nodes +00:35 < FillaMent> got it. +00:35 < mids> it will have huge paths +00:36 < mids> that is why I would suggest a manually crafter first layer of public nodes +00:36 < FillaMent> Could another solution be to make 'the' server 'a' server? +00:36 < mids> so you decrease the amount of hops +00:36 < LeeroklaLacerta> Is there any sort of reliability-index-type thing? +00:36 < mids> you only have 1 end-node +00:36 < mids> there isnt, since you dont know what nodes a node connects through +00:37 < mids> if your connection goes down, you dont know what node caused it +00:37 < mids> it can be anyone on your path +00:37 < LeeroklaLacerta> K. +00:37 < mids> and you dont know your path +00:37 < FillaMent> Is there anyway for the end user it increase the reliability of IIP? +00:37 < mids> yes, manually edit your node.ref +00:38 < mids> and put only some stable nodes on it +00:38 < mids> and dont let it update the node.ref automatically +00:38 < FillaMent> mids: I mean setting up a relay or something. +00:38 < mids> ofcourse you dont know what are stable nodes, unless you have some inside knowledge about the IIP topography +00:39 < mids> Trent for example directly connects to a node which connects to the IIP server node +00:39 < mids> otherwise it would go down all the time +00:39 < mids> resulting in a really bad network +00:41 < FillaMent> To save me some time, where does iip store the nodes.ref on a linux box? +00:41 < mids> ~/.iip/ +00:41 < mids> or the local directory +00:42 < mids> ok, I want to quit this item +00:42 < mids> homework for next week: +00:42 < mids> think about the issues +00:42 < mids> and propose suggestions to the mailinglist +00:42 < FillaMent> Give me 10 min and I'll have a kludge for the massive node list problem +00:42 < mids> or to a developper (if you arent subscribed) +00:43 < mids> . +00:43 < mids> questions? +00:51 < hezekiah> You almost have your "kludge" (I don't know what that word means) for the node list problem yet, FillaMent? +00:52 < FillaMent> kludge is coding duct tape, and yes. +00:52 < hezekiah> Ah. +00:53 < thecrypto> the full definition is http://www.tuxedo.org/~esr/jargon/html/entry/kluge.html +00:54 < mids> hezekiah: thanks for putting your hands on those 2 bugtracker items +00:55 < hezekiah> No problem. I still don't know how to assign a bug to myself. Otherwise, I would have "officially" picked up the PF_INET one. +00:55 < hezekiah> I couldn't find the button/link/whatever that lets you assign a bug to yourself. +00:57 < mids> only project admins seem to be able to assign bugs for our project +00:57 < hezekiah> Ah +00:57 < hezekiah> That would explain it! :) +00:59 < hezekiah> OK. Well, I'm going to leave now. Bye everyone! :) +00:59 < LeeroklaLacerta> Good bye. +01:04 < mids> ok +01:04 < mids> I am gone too +01:04 < mids> bye +01:08 < LeeroklaLacerta> Everyone's leavin'? +01:08 < LeeroklaLacerta> Is the meeting over? +01:09 < FillaMent> I'm still here. Perhaps my time estimate was a bit off. I love/hate perl. +01:10 < LeeroklaLacerta> What's perl got to do with it? +01:10 < FillaMent> My node.ref kluge +01:10 < LeeroklaLacerta> Ah. +01:11 < FillaMent> I should just describe it to someone competant and let them do it in like 5min +01:11 < LeeroklaLacerta> I'm just here for the heck of it. +01:16 < LeeroklaLacerta> I'm going back to #anonymous. +01:17 < FillaMent> Ha ha! +01:39 < FillaMent> Anyone care to enlighten me as to why in perl, when I push an item into an array, /every/ item ends up being that item? +02:59 < sdgg> hi +03:05 < FillaMent> Know how long an md5 signature is supposed to be? +03:10 < sdgg> 128 bits I believe +03:14 < sdgg> Does anyone know of a good tutorial on c/c++ for *nix programming? +03:14 < sdgg> Or somewhere I can look? +05:10 * FillaMent is away: Destinking myself diff --git a/i2p2www/meetings/logs/26.rst b/i2p2www/meetings/logs/26.rst new file mode 100644 index 00000000..7201e581 --- /dev/null +++ b/i2p2www/meetings/logs/26.rst @@ -0,0 +1,9 @@ +I2P dev meeting, January 15, 2003 @ 23:00 UTC +============================================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/28.log b/i2p2www/meetings/logs/28.log new file mode 100644 index 00000000..72c1cc2b --- /dev/null +++ b/i2p2www/meetings/logs/28.log @@ -0,0 +1,140 @@ +--- Log opened Tue Jan 28 22:35:17 2003 +22:35 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +22:35 [Users #iip-dev] +22:35 [ co] [ logger] [ pox] [ ptm] [ UserX] +22:35 -!- Irssi: #iip-dev: Total of 5 nicks [0 ops, 0 halfops, 0 voices, 5 normal] +22:35 -!- Irssi: Join to #iip-dev was synced in 2 secs +22:41 -!- mode/#iip-dev [+o mids] by Trent +22:41 -!- mode/#iip-dev [+v logger] by mids +22:41 -!- mode/#iip-dev [+o UserX] by mids +23:56 -!- mode/#iip-dev [+o nop] by mids +--- Day changed Wed Jan 29 2003 +00:00 <@mids> Tue Jan 28 23:00:00 UTC 2003 +00:00 <@nop> hi +00:00 < Debrys> greetings +00:00 < case> hallo +00:00 <@nop> hi +00:00 < Bouris> Hi. +00:00 < MrEcho> hey case +00:00 <@nop> meeting started +00:00 < case> sup echo +00:01 <@mids> nop: agenda please +00:01 <@nop> ok +00:01 <@nop> I thought you had it +00:01 <@nop> ;) +00:01 <@nop> 1) welcome +00:01 <@mids> 1) Welcome +00:01 <@mids> 2) Normal stuff +00:01 <@mids> 3) Questions +00:01 <@mids> . +00:01 <@nop> sure that works +00:01 <@nop> welcome to the nth IIP-dev meeting +00:01 <@nop> 2) Normal stuff, i.e. IIP update +00:01 <@nop> ok +00:02 <@nop> we're working on getting rc3 changed to 1.1 final +00:02 <@nop> I think all that's left is some path fix bugs +00:02 <@mids> hezekiah made the patch for -h, nop is reviewing it +00:02 <@nop> yes +00:02 <@nop> actually he can commit, I'll let him know, forgot to email him +00:02 <@mids> ok +00:02 <@nop> also +00:02 <@mids> then we just got to check how the other reported bug is +00:03 <@nop> Hezekiah has successfully compiled a version of IIP with the GNU Multi Precision library +00:03 <@nop> and it was a success +00:03 < MrEcho> cool +00:03 <@nop> the crypto speed was improved +00:03 <@nop> so that will be something we do for 1.2 +00:03 <@nop> 1.2 is focusing on standards as well, standardized crypto engine and big number routines +00:03 <@nop> etc +00:03 <@mids> there is our hero! +00:04 -!- mode/#iip-dev [+o hezekiah] by mids +00:04 <@hezekiah> Who? +00:04 <@nop> you +00:04 <@mids> you! +00:04 <@hezekiah> Sorry I'm late. :) +00:04 <@hezekiah> (And thanks for the compliment.) +00:06 <@hezekiah> Did I miss the meeting? ... or is it still going? +00:06 <@mids> nop was just telling about the update works +00:06 <@mids> and that you can commit the -h patch +00:06 <@hezekiah> OK. +00:06 <@mids> then we got to see how severe the problems with the file paths are +00:06 <@hezekiah> I just got through reading the logs. +00:06 <@mids> test in multiple locations etc +00:06 < MrEcho> anything new for windows users? +00:06 <@mids> platofrms I mean +00:08 <@hezekiah> Well, the -h bugfix might affect the windows users. I'm not sure if it was a problem over there. +00:09 <@hezekiah> As for the GnuMP implementation of BigNum, that should be part of the 1.2 release for windows (though it might take some work to get it to run on windows.) +00:09 < Debrys> may i ask what this BigNum-stuff is all about? +00:10 < case> what version of libgmp was it dones with? +00:10 < case> er +00:10 < case> dones/done +00:10 <@hezekiah> Well, since mids and nop seem to have dissapeared for the moment, I'll explain it while we wait for them to get back. +00:10 <@hezekiah> OK. +00:10 <@mids> I am listening +00:10 <@mids> please entertain +00:10 <@hezekiah> First I'll answer case's question because it is simple. I used version 4.1 of GnuMP. +00:10 <@hezekiah> (Gentoo doesn't have 4.1.2 yet.) +00:11 <@hezekiah> Next is Debrys question: +00:11 <@hezekiah> BigNum structure with a is a bunch of functions used in the isproxy source code. +00:11 <@hezekiah> It is basically just a way to make integers that are REALLY REALLY big. +00:11 <@hezekiah> Obviously modern CPU's don't offer really really big integer types, so C doesn't have them. +00:12 <@hezekiah> ... and crypto needs to use really big numbers. +00:12 <@hezekiah> Thus, an implementation of a "BigNum" is needed. +00:12 < Debrys> i think i got it :) thank you +00:12 <@hezekiah> Currently, we have 2 implentations of BigNum: one in SSL and one in GnuMP. +00:12 <@hezekiah> You're welcome. :) +00:12 <@hezekiah> Back to you, mids. :) +00:12 <@mids> ok +00:12 * hezekiah hands the microphone back. +00:13 <@mids> I am done on point 2 +00:13 <@mids> lets go to the question round +00:13 <@mids> questions? +00:13 <@hezekiah> (oh, the irony.) ;-) +00:13 <@hezekiah> Yeah. Are we almost to 1.1 release yet? +00:14 <@hezekiah> What still needs to be done? (Besides get codeshark to make a tarball.) +00:14 <@mids> testing if files are stored in the right directories +00:14 <@mids> in every case +00:15 <@mids> hezekiah: please tell me if you did commit the -h thing, then I'll put the bug item closed +00:15 <@nop> oh hezekiah you can commit +00:15 <@nop> the -h thing +00:15 <@nop> ;) +00:15 <@hezekiah> I haven't commited the -h thing yet. +00:15 <@hezekiah> I don't know what branch to commit to. :) +00:15 <@nop> he does now ;) +00:16 <@hezekiah> Give me a minute and I +00:16 <@hezekiah> I'll update the bugfix. +00:16 < Debrys> hmm, what will be new or changed in 1.1? not too much into detail - just in general +00:16 <@hezekiah> 1. Bugfixes! :) +00:17 <@mids> 2. more bugfixe +00:17 < Debrys> lol +00:17 <@nop> debrys no major changes +00:17 < Debrys> anything which makes the connections more stable? +00:17 <@nop> just bug fixes +00:18 <@mids> Debrys: we will try that with a more minimum node.ref in the initial distribution +00:18 < Debrys> i did a.......... rather unelegant hack to the node.ref.......... +00:19 < Debrys> only the invisiblenet relays.......... no update of node.ref +00:19 < Debrys> i havent ping-timeout'ed for days........ +00:19 < Debrys> before of that i god disconnected in 30min intervals on average +00:20 < Debrys> but its not a very good solution :) +00:21 < Debrys> also.......... on the floppy-disk thing........ +00:21 < Debrys> i asked someone if he would do a hack for me on the boxedIRC-Source...... +00:22 < Debrys> if he accepts, this means i would have an 120kb IRC-Client which doesn't need any installation and saves all its settings in a ini-file on the disk +00:23 <@mids> nice +00:23 <@mids> keep us informed please +00:23 < Debrys> if this works, there will not only be IIP and a IRC-Client on the disk, but also an email-client...... and i'm trying to get a PGP-App on it too........... maybe also a messenger client :) +00:23 < Debrys> I'll do :) +00:23 < lonelynerd> sound nice. +00:23 < lonelynerd> [ sounds even. ] +00:24 <@mids> ok +00:24 <@mids> more things? +00:24 < Debrys> nope +00:25 * mids searches for his meeting-hammer +00:25 <@hezekiah> Almost got the patch up, mids. +00:25 <@mids> hurray +00:25 <@mids> *baff* +00:25 <@mids> meeting closed +00:25 <@hezekiah> lol. +00:25 < Debrys> :) +00:26 < Bouris> Hooray! +00:27 <+logger> cya next week +--- Log closed Wed Jan 29 00:27:06 2003 diff --git a/i2p2www/meetings/logs/28.rst b/i2p2www/meetings/logs/28.rst new file mode 100644 index 00000000..ea5bbbcc --- /dev/null +++ b/i2p2www/meetings/logs/28.rst @@ -0,0 +1,9 @@ +I2P dev meeting, January 28, 2003 @ 23:00 UTC +============================================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/29.log b/i2p2www/meetings/logs/29.log new file mode 100644 index 00000000..af0ad648 --- /dev/null +++ b/i2p2www/meetings/logs/29.log @@ -0,0 +1,196 @@ +--- Log opened Tue Feb 04 23:38:39 2003 +23:38 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +23:38 [Users #iip-dev] +23:38 [ co ] [ mids ] [ Neo] [ ptm ] +23:38 [ logger] [ MrEcho] [ pox] [ UserX] +23:38 -!- Irssi: #iip-dev: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal] +23:38 -!- Irssi: Join to #iip-dev was synced in 12 secs +23:51 < mids> nop wont be on +23:51 -!- mode/#iip-dev [+o mids] by Trent +23:51 -!- mode/#iip-dev [+o UserX] by mids +23:59 -!- mode/#iip-dev [+o hezekiah] by mids +23:59 -!- mode/#iip-dev [+o hezekiah] by Trent +23:59 <@hezekiah> Oops! +23:59 <@hezekiah> I was just about to try that, mids! :) +23:59 <@hezekiah> I think I figured it out! +23:59 <@mids> you did +23:59 * hezekiah feals very happy with himself for learning more about IRC. :) +--- Day changed Wed Feb 05 2003 +00:00 < MrEcho> lol +00:00 <@mids> Tue Feb 4 23:00:10 UTC 2003 +00:00 <@mids> Welcome to the 29th iip meeting +00:00 <@mids> nop emailed me that he wont be there +00:00 <@mids> so you got to do it without him +00:00 <@mids> I dont have a specific agenda +00:00 <@mids> except for this +00:01 <@mids> 1) welcome :) +00:01 <@mids> 2) highlights of the week +00:01 <@mids> 3) questions +00:01 <@mids> . +00:01 <@mids> any highlights to report? +00:02 <@hezekiah> Uh, not on my side. I'm still waiting for UserX or nop to look at the GnuMP BigNum impl. to see if it's OK. +00:02 <@mids> userx added some code to the isproxy so that an empty node.ref file wont do harm if you upload +00:02 <@hezekiah> The configure options for it got uploaded though. +00:02 <@hezekiah> Is IIP 1.1 out yet? +00:03 <@mids> havent seen it +00:03 <@hezekiah> I guess not. +00:03 <@mids> only thing is that we need to look at the location where the files are saved +00:04 <@hezekiah> Hmmm ... +00:04 <@mids> and if that gives bugs on different operating systems +00:04 <@hezekiah> What exactly is the problem? +00:05 * mids loads the sourceforge bugtracker +00:05 <@mids> http://sourceforge.net/tracker/index.php?func=detail&aid=651711&group_id=50945&atid=461514 +00:05 * hezekiah is doing the same. +00:05 <@hezekiah> Thanks. :) +00:06 <@hezekiah> I remeber looking at that briefly once. +00:07 <@hezekiah> The tricky part is what you are supposed to do in Windows. +00:07 <@hezekiah> The *nix/*BSD part shouldn't be that difficult. (I hope.) +00:07 <@mids> in windows it does just look at the current working directory +00:08 <@hezekiah> I'll leave the Windows part to UserX. :) +00:08 <@mids> the windows behavious shouldnt change imho +00:09 <@hezekiah> Whatever. I run linux, and avoid Windows whenever I can. ;-) +00:09 <@mids> same +00:09 <@mids> but what behaviour do we want for unix? +00:09 <@hezekiah> The behavior is defined in the code using #ifdef's based on platform. +00:09 <@mids> you need to have access to the root/iip account to be able to access ~iip/.iip +00:10 <@mids> so it should also look in other dirs +00:10 <@mids> like ~/.iip +00:10 <@mids> or the current dir +00:10 <@hezekiah> Well, if isproxy is installed the default thing for a program to do would be look in /home/<user's homedir name>/.iip +00:10 <@hezekiah> So in my case: /home/hezekiah/.iip +00:10 <@hezekiah> node.ref would be /home/hezekiah/.iip/node.ref +00:11 <@hezekiah> Then each user can have their own settings, etc. +00:11 < MrEcho> you can kind of do the same thing in NT +00:11 < MrEcho> my doc's folder is protected +00:11 <@hezekiah> But under Win9[58] there really aren +00:11 < MrEcho> ya +00:11 <@hezekiah> aren't user specific home dirs. +00:12 < MrEcho> anyone using 9x needs help anyways .... +00:12 * hezekiah laughs +00:12 <@hezekiah> Well, I'll email nop and ask him how he wants it done for *nix. Then, I'll see what I can do. +00:12 <@mids> mail the list please +00:13 <@mids> the we can all discuss +00:13 < MrEcho> for the 9x ppl just put the files in ./.iip/ +00:13 <@hezekiah> OK. +00:13 <@hezekiah> Or when IIP is installed it could be installed in Program Files/IIP. +00:14 < MrEcho> for 9x ppl +00:14 <@hezekiah> node.ref, isproxy.ini, seed.rnd, etc. could be placed there. +00:14 <@mids> if you start IIP with a windows start thingie, then you can set the workingdirectory +00:15 <@hezekiah> Well, anyway, I don't intend to touch the Windows implementation with a ten-foot poll. UserX can figure this one out. ;-) +00:15 < MrEcho> :P +00:15 <@mids> ok +00:15 < FillaMent> You could look into a nasty WSH script. Then you can store in info in the registry +00:15 <@hezekiah> (My compiler might not even _compile_ IIP under Windows!) +00:15 <@mids> :) +00:15 < MrEcho> fuck the registry +00:15 <@hezekiah> FillaMent: if we used the registry in a program that needs to work under *nix, it would be an #ifdef NIGHTMARE!! +00:16 < FillaMent> Not what I"m saying +00:16 <@hezekiah> (But I will admit I tought of it to for a few seconds ... only a few, mind you.) +00:16 <@hezekiah> Oh? +00:16 <@hezekiah> Explain? :) +00:17 < FillaMent> Have the location of the data file stored in the registry, then launch IIP with a WSH script that pulls the path out of the registry and pass it to the program as a cmnd line option +00:17 < MrEcho> http://bofh.st/bofh/images/traffic.gif +00:18 <@hezekiah> That might be doable. +00:19 <@mids> I only had someone asking for windows NOT to change the current system there +00:19 <@mids> maybe it would be nice to let it work without registry +00:19 < FillaMent> A while back I wrote a script that would replace the name of the last logged in user with an arbitrary string. NT Ninja Vanish =) Had to do it because Generals and Colonels would freak because there was another login nam +00:19 <@mids> from a security / anonymity pov +00:20 <@hezekiah> I have to admit that I hate the Windoze registry with a pasion, just my personal opinion, though. :) +00:20 < MrEcho> same here hezekiah +00:20 < MrEcho> but ive learned to work with it +00:20 <@hezekiah> So have I, ... but I still hate it. :) +00:20 <@mids> so +00:20 <@mids> lets investigate this week how the system currently works +00:21 <@mids> and discuss on the list about how it should +00:21 <@hezekiah> Right. +00:21 <@mids> after that, make it work like it should :) +00:21 <@hezekiah> I'll post an email to start up the conversation. +00:21 <@mids> yay +00:21 <@mids> so +00:21 <@mids> next item? +00:22 <@hezekiah> 3.) questions +00:22 < MrEcho> where the hell is 1.1 +00:22 <@mids> *nod* +00:22 < MrEcho> hehe +00:22 <@hezekiah> I don't know. +00:22 <@hezekiah> But I think the reason it's not out is because of the aforementioned bug. +00:22 <@hezekiah> (The one we are going to talk about on the mailing list.) +00:23 < MrEcho> i just hope it connects faster and more stable connections +00:24 <@hezekiah> (I have to admit I haven't had a problem with unstable connections, and I usually connect to the 1st or 2nd node I try.) +00:24 <@mids> but that is just because you have a clean node.ref, I assume? +00:24 <@hezekiah> No. +00:24 <@hezekiah> I have a normal node.ref +00:24 <@mids> oh +00:25 <@mids> but you never stay online for 24 h +00:25 <@hezekiah> It's the one the server gives me each time I conect. +00:25 < FillaMent> I can stay connected for a couple days, usually. +00:25 <@hezekiah> No. I have a life. ;-) +00:25 <@mids> one can stay online without irc-ing ofcourse +00:25 <@mids> *geeh* +00:25 <@hezekiah> And my family's phone line is the same on the internet connection is on. :) +00:25 < jrandom> eww +00:26 <@mids> then get offline now! +00:26 <@mids> :) +00:26 <@hezekiah> Other questions? +00:26 <@mids> I dont have those +00:28 < FillaMent> HaZaa... +00:28 <@hezekiah> HaZaa? +00:28 <@mids> gesundheit +00:28 <@hezekiah> *lol* +00:28 <@hezekiah> Was that a question, FillaMent? +00:28 < FillaMent> My FServe +00:29 <@hezekiah> OK. I'm lost. :) +00:29 <@mids> tell us about it hezekiah +00:29 <@mids> s/hezekiah/FillaMent/ +00:30 < FillaMent> I was just wondering if there'd be any expected problems using IIP as a comm backbone for a lot of file browsing. +00:30 < FillaMent> And eventually a text-based protocol like HTTP +00:30 <@mids> you will be bound to the slowness of IIP +00:30 <@mids> the 50B/s limit +00:31 <@hezekiah> IIP might not always be slow, mids. ;-) +00:31 <@hezekiah> We shall optimize and improve. :) +00:31 <@mids> hurray +00:31 < FillaMent> That's not a big deal since we're not doing actual file transfer of IIP. Just comm. I'm concerned with whether or not it would be a strain. +00:32 < lonelynerd> 50B/s might be ok for telnet +00:32 <@hezekiah> (Mids? You want to answer all this? I'm reeaaallllyyy lost.) +00:32 <@mids> ok +00:32 <@mids> FillaMent is working on something caled HaZaa +00:32 <@mids> it is some fserve on IIP +00:33 <@mids> which uses Freenet for the actual file sharing +00:33 <@mids> right? +00:33 < FillaMent> Yeah... IIP for the browsing. +00:33 <@mids> so you have some telnet/ftp like interface locally +00:33 < FillaMent> firing it up now. +00:34 < FillaMent> haz: /msg hazaaclone shell +00:36 < FillaMent> haz: /msg hazaaclone cd /stuff/mp3s +00:38 <@hezekiah> Not bad!! +00:38 <@hezekiah> Uh ... how do you leave the shell? +00:38 < FillaMent> It just times out. +00:38 <@hezekiah> Oh ... +00:39 < FillaMent> Think traffic like that would be a problem... I expect /lots/ of people will run them. Especially since DALnet just put a ban on FServes +00:40 < HazaaClone> I might clog your chat network =) +00:40 <@hezekiah> Hmmm ... +00:40 <@hezekiah> That would be a problem. :) +00:41 < FillaMent> Dunno how much traffic it would be or what effect it will have on IIP. +00:41 <@mids> during the slashdot attack we did do pretty well +00:41 < FillaMent> Sounds solid then. +00:41 <@mids> the total amount of people wasnt too high +00:41 <@mids> but it was constant joining and parting +00:42 < FillaMent> I /think/ I got the flooding issue fixed. +00:43 <@hezekiah> Well, if you threw in an "exit/quit" command, maybe the connections would be lower. Just a suggestion. :) +00:44 <@hezekiah> Well, I had better go. See you all around. :) +00:44 < FillaMent> THe eventual version will use IIP to pass search queries and query results. +00:45 <@hezekiah> mids: I'm looking into the code on the file placement bug. I should have an email up on the mailing list shortly. :) +00:45 <@hezekiah> Bye, all! :) +00:45 <@mids> bye +00:46 < MrEcho> hey mids .. have you checked out iip-im latly +00:46 <@mids> nope +00:46 <@mids> but I didnt get many CVS updates +00:46 < MrEcho> got a bunch of stuff done +00:46 <@mids> lets end the official part of the meeting +00:46 < MrEcho> im working on xml themes right now +00:46 <@mids> and move over to friendly chit chat +00:46 < MrEcho> ... +00:47 < FillaMent> ooooo! That just gave me an idea. +00:48 < FillaMent> Oooo.... this is going to ROCK! +00:48 <@mids> ? +--- Log closed Wed Feb 05 00:48:36 2003 diff --git a/i2p2www/meetings/logs/29.rst b/i2p2www/meetings/logs/29.rst new file mode 100644 index 00000000..d54a0110 --- /dev/null +++ b/i2p2www/meetings/logs/29.rst @@ -0,0 +1,9 @@ +I2P dev meeting, February 4, 2003 @ 23:00 UTC +============================================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/3.log b/i2p2www/meetings/logs/3.log new file mode 100644 index 00000000..9787cd4f --- /dev/null +++ b/i2p2www/meetings/logs/3.log @@ -0,0 +1,609 @@ +--- Log opened Wed Jun 05 00:38:00 2002 +00:38 <+logger> logging started +00:38 <@codeshark> already? +00:38 <+logger> yes, warming up +00:49 * Annemiek is nu afwezig [Slapen/sleeping] [p-uit l-uit] +00:49 -!- Annemiek is now known as keimennA +00:59 <@nop> time +00:59 <@nop> what time is it +00:59 <@codeshark> 22:59 UTC +01:00 < ellison> drumroll..... +01:00 <@codeshark> 23:00 UTC +01:00 < Zwollywood> 1:00 +01:00 <@mids> Tue Jun 4 23:00:50 UTC 2002 +01:01 <@mids> lets start +01:01 <@nop> ok +01:01 <@nop> Welcome all +01:01 <@nop> to the 3rd meeting +01:01 <@nop> of IIP +01:02 <@nop> Today is probably a shorter meeting +01:02 <@nop> but that's not exactly a bad thing +01:02 <@nop> so anyway +01:02 <@mids> on request of some europeans the meeting is held 1 hour earlier, nop is busy working, so he might be away +01:02 <@nop> let's get started shall we +01:02 <@mids> Previous meeting has logs on http://mids.student.utwente.nl/~mids/iip/meeting2/ +01:03 <@mids> if it will get crowded, this channel will be moderated, in that case direct your question to those with ops +01:03 <@nop> ok +01:03 <@nop> agenda +01:03 <@mids> 1) Welcome +01:03 <@mids> 2) Documentation status +01:03 <@mids> 3) RC2 compatibility +01:03 <@mids> 4) IPv6 support for IIP 1.2 +01:03 <@mids> A) Questions? +01:03 <@mids> B) Next meeting +01:03 <@nop> welcome +01:03 <@nop> on to 2 +01:04 <@mids> Thanks to Banks a lot of holes in the docs are filled +01:04 <@mids> he added screenshots for windows +01:04 <@mids> and found nice quotes that are used in each chapter +01:04 < Banks> np +01:04 <@codeshark> yeah, doc looks cool +01:04 <@mids> cohesion reviewed his work on chapter 1 and 2 +01:04 <@mids> it is in CVS now +01:05 <@mids> demo: http://mids.student.utwente.nl/~mids/iip/htmldoc/en/index.html +01:05 <@mids> nop still has to review everything, so it is in no way final +01:05 <@mids> . +01:05 <@mids> pardon the logo, that ASCII art is a placeholder :) +01:05 <@mids> . +01:06 <@mids> Sina: now everybody is looking at the nice docs: demo: http://mids.student.utwente.nl/~mids/iip/htmldoc/en/index.html +01:07 < Neo> nice job banks. stuff looks great. +01:07 < Banks> cheers :) +01:07 <@nop> one comment +01:08 <@nop> looks great +01:08 <@nop> but +01:08 <@nop> oh +01:08 <@nop> never mind +01:08 <@nop> ok +01:08 < Banks> If we can get an advance release on RC2 we can package the latest docs with it +01:08 <@mids> hehe +01:08 <@nop> it's all good +01:08 <@nop> we will, we'll get to rc2 next +01:08 <@mids> any other comments on the docs? +01:08 < Banks> You sure there isn't a but? :) +01:08 < cohesion> anyone here have debian? +01:09 * mids +01:09 <@mids> there is no /etc/boot.local +01:09 <@mids> everything is script based +01:09 < cohesion> sys V +01:09 < cohesion> you mean? +01:09 <@mids> so you need to create a startup script and put it in /etc/rcS.d/ +01:09 < cohesion> ya +01:09 < cohesion> hum +01:09 < cohesion> *shrugs* +01:10 <@nop> oh guys +01:10 <@nop> we need to include the random data for windows snapshot +01:10 <@nop> might throw them off +01:10 <@nop> but we generate a seed there as well +01:10 <@mids> is that GUI based? +01:10 <@nop> yes +01:10 <@nop> mouse and keyboard strokes +01:10 <@nop> both or either +01:11 <@mids> so it is already in cvs? +01:11 <@nop> yes sir +01:11 <@mids> ok +01:11 <@nop> but you have to do a clean install on that +01:11 <@mids> Banks: can you snap that? +01:11 <@nop> cohesion +01:11 <@nop> chapter 4 +01:11 <@nop> installation on Unix systems +01:11 <@nop> is that completed the isproxy -C +01:12 < Banks> mids: I'll try +01:12 <@nop> because it starts up at beginning if you are not upgrading +01:12 <@mids> Banks: you require a windows compilation then, maybe ask codeshark +01:12 <@mids> AndreGoldman: we are at 2) Documentation status +01:12 <@nop> I can compile it for you +01:12 < Banks> nop: Cheers +01:13 <@nop> and send it your ways +01:13 <@mids> AndreGoldman: everybody is looking at the documentation demo: http://mids.student.utwente.nl/~mids/iip/htmldoc/en/ +01:13 < AndreGoldman> Thank, I'll jut follo along. +01:13 <@nop> I'll send it in a bit +01:13 <@mids> more comments on docs? +01:13 <@nop> cohesion +01:13 <@nop> need to finish isproxy configuration for unix +01:13 <@nop> on chapt 4 +01:14 <@nop> I'll look over it later for other stuff +01:14 <@nop> but that's a biggy +01:14 < cohesion> hum +01:14 < Zwolly> just let me know where to find original and i will make an dutch translation +01:14 <@nop> ahh yes +01:14 <@nop> translations +01:14 <@mids> Zwolly: will do once reviewed by nop +01:14 <@nop> we need to include those +01:14 <@nop> in source +01:14 <@nop> this will help people tremendously +01:15 <@mids> any germans here? +01:15 <@nop> Skyrat is +01:15 <@nop> but he's not on right now +01:15 <@mids> or other languages except for english, dutch and french +01:15 <@nop> also +01:15 < Phiberoptika> do you need spanish? +01:15 <@nop> cohesion include the network diagram +01:15 <@mids> UnDeRToW told me that he didn't have time for up to date spanish +01:15 <@nop> I think we have spanish +01:15 <@nop> oh +01:15 <@nop> ok +01:15 <@nop> then yes +01:15 <@nop> spanish is good +01:15 < cohesion> what diagram? +01:15 <@nop> the one I sent a while back +01:16 <@nop> ascii art of the network architecture +01:16 < cohesion> ok +01:16 < cohesion> i'll find it +01:16 <@nop> k +01:16 <@mids> Phiberoptika: cool, we'll find you when needed :) +01:16 <@nop> because what's demonstrated is part of the communication protocol +01:16 <@nop> not the netwrk arch +01:16 <@nop> and we'll label that communication protocol as such +01:16 < Phiberoptika> ok : ) +01:16 <@nop> and then include net arch +01:16 <@nop> anyway +01:17 <@nop> I've spoken my mind, the rest of that can be worried about offline +01:17 <@mids> . +01:17 <@nop> oh +01:17 <@nop> and pertaining to rc2 with docs +01:17 <@nop> I will rewrite the encryption when done, but we'll know why in next part +01:18 <@mids> next item? +01:18 <@nop> yes +01:18 <@mids> 3) RC2 compatibility +01:18 <@nop> ok +01:18 <@nop> decided yesterday +01:18 <@nop> we have some more work on rc2 +01:18 <@nop> so please +01:19 <@nop> use 1.1 rc1 until otherwise notified +01:19 <@nop> because they won't work together +01:19 <@mids> wasn't there a function freeze? +01:19 <@nop> and the entire infrastructure has to be upgraded +01:19 <@nop> but it must be when release of rc2 is out +01:19 <@nop> or at least 1 week for pre-testing +01:19 <@nop> reason: +01:19 <@codeshark> nop: we need a parallel rc-2 network +01:19 <@nop> we will have one cs +01:19 <@codeshark> ok +01:19 <@nop> but inform will look the same +01:19 <@nop> and you'll have to restart inform +01:20 <@nop> because we're not changing the communication to inform +01:20 <@nop> so when we parallel +01:20 <@nop> we'll slowly delete out as wel upgrade +01:20 <@codeshark> you mean: flush the relays +01:20 <@nop> we upgrade +01:20 <@nop> yes +01:20 <@nop> except for a couple +01:20 <@nop> which we can discuss later +01:20 <@codeshark> sure +01:20 <@nop> ok +01:20 <@mids> what is changed? +01:20 <@nop> reason: +01:20 <@nop> mandatory security upgrade +01:21 <@nop> IIP 1.1 as is, is very secure under normal circumstances +01:21 <@nop> hackers, etc +01:21 <@nop> but +01:21 <@nop> against a gov't attack, and ultimate paranoia +01:21 <@nop> there can be a few certain types of physical attacks that can be used to obtain the secret server key through coersion +01:21 <@nop> because of this risk +01:21 <@nop> well +01:22 <@nop> let me explain it in more detail +01:22 <@nop> for instance +01:22 <@nop> we're all enjoying ourselves on IIP +01:22 <@nop> right? +01:22 <@nop> right +01:22 <@mids> k: we are now on 3) RC2 compatibility +01:22 <@mids> right +01:22 < Neo> I am. +01:22 <@nop> someone does something stupid and happens to live in a corrupt gov't space +01:22 <@mids> (if the network is up) +01:22 <@nop> this gov't is now wiretapping and monitoring their internet connection +01:22 < k> listening. +01:23 <@nop> and starts putting up spy nodes around this user +01:23 <@nop> then +01:23 <@nop> they log this stuff for the amount of time they feel needed to get this guy +01:23 <@nop> and suddenly they seek me out +01:23 <@nop> and say we're raidnng the server +01:23 <@nop> you have no choice but to give us the key +01:23 <@nop> legally I'm obligated to do so +01:23 <@nop> which is another issue of whether I do or not +01:23 <@nop> say worst situation +01:24 <@nop> they shoot me in the head +01:24 <@nop> and take the key +01:24 <@nop> ok +01:24 <@nop> now with proper analysis +01:24 <@nop> they will be able to decrypt the messages involved +01:24 * Neo thinks we would all miss you. +01:24 < AndreGoldman> it is called 'rubber hose cryptography' +01:24 <@nop> well +01:24 <@nop> still +01:25 < Aroonkoa> Can the key be kept completely in memory? +01:25 <@nop> this is involving IIP as a protocol and rubber hose doesn't work on 2.4 kernels +01:25 <@nop> we have provided a solution +01:25 <@nop> and are currently in the process of implementing it +01:25 < Banks> can you tell us what it is? +01:25 <@nop> this solution is to have a double encrypted protocol for end to end +01:25 <@nop> of course, we're open source +01:25 <@nop> ;) +01:25 <@nop> what happens +01:26 <@nop> user A connects through ---> to end node, connects to networkid, authenticates, and then will be doing a separate random key exchange that will disappear after communication is finished +01:26 <@nop> this key will not be used again +01:26 <@nop> and is after networkid authentication +01:26 <@nop> plus enhanced with the Rolling Key Algorithm we use +01:26 <@nop> and the way we Xor every 8 bytes of data +01:27 <@codeshark> well, you could still do a mitm +01:27 <@nop> no +01:27 <@codeshark> why not? +01:27 <@nop> because +01:27 <@codeshark> if you have the network key +01:27 <@nop> it's done after the networkid +01:27 <@nop> this is a situation against the log and raid server attack +01:27 <@nop> not a live attack +01:27 <@codeshark> ok +01:27 <@mids> will this cause more load on the serverside IIP relay? +01:27 <@nop> most likely not after they are connected +01:27 <@nop> you might note a spike on exchange +01:27 <@nop> but that happens anyway +01:27 <@nop> and a little more time connecting +01:27 <@nop> also +01:28 < Banks> the one-time key will be securely wiped after use? +01:28 <@nop> networkid will be changed for safety reasons +01:28 <@nop> and become 2048 bit +01:28 <@nop> and made optionally in the software to support a 4096 bit networkid key +01:28 <@mids> how well does it scale? +01:28 <@nop> yes Banks it will +01:28 <@mids> we had big trouble on the old server, when everybody connected at once +01:28 < Neo> (log and raid server attack == log all cipher traffic, then raid for the key, then replay the traffic and decrypt the data) +01:28 <@nop> correct +01:28 <@mids> thanks nop +01:29 <@mids> s/nop/Neo/ +01:29 <@nop> the already used ciphers assist quite well for most attacks, the windows are small because of RKA and fake traffic forcing the rolling of keys +01:29 <@nop> but if a user is being monitored +01:29 <@nop> they are at risk until we decentralize completely +01:29 <@nop> so for this reason +01:30 <@nop> we are implementing rc2 as a mandatory security upgrade +01:30 < Banks> cool +01:30 <@nop> and will not be compatible with the previous version +01:30 <@nop> and +01:30 <@nop> one more comment on security +01:30 <@nop> we need to make an ettiquette doc on how to think securely and anonymously +01:30 <@nop> especially in public channels +01:30 <@nop> as well +01:30 <@mids> offtopic :) +01:30 <@nop> as just putting iip links to lots of websites +01:31 <@nop> it's part of the security of IIP +01:31 <@nop> which I believe is rc2 +01:31 <@nop> ;) +01:31 < Banks> heh +01:31 <@nop> just linking IIP could lead to bad compromised software +01:31 <@nop> even with md5's +01:31 <@nop> we need to make sure that the servers that mirror it +01:31 <@nop> are secure +01:31 <@nop> etc +01:31 <@nop> anyway +01:32 <@nop> off topic +01:32 <@nop> so we'll discuss that next meeting +01:32 <@nop> anywa +01:32 <@nop> scalability +01:32 <@nop> IIP doesn't scale at all really because of it's centralized (temporary) design +01:32 <@nop> but DH key exchange will not affect the scaling +01:32 <@nop> we are planning for the future +01:32 <@nop> and bigger prime numbers are essential as we go against faster and faster computers out there +01:33 <@mids> well I remember terrible loads when everybody connects at once, right? +01:33 <@nop> not anymore +01:33 <@nop> this was fixed recently +01:33 <@nop> on the back end +01:33 <@nop> I get a spike of 32% now with that issue +01:33 <@nop> not 99% +01:33 <@mids> nice +01:33 <@mids> why put this mandatory thing in RC2 (which was feature frozen imho) and not in 1.2 ? +01:34 <@nop> because it will be waiting too long +01:34 <@nop> no offense to the US gov't +01:34 <@nop> but they have been issuing laws faster than we code +01:34 <@nop> particularly to wiretapping +01:34 <@nop> deniability is a key issue here +01:34 < Banks> indeed +01:34 <@mids> k +01:34 <@nop> especially for the server +01:34 <@mids> good point then +01:35 <@mids> do we need version numbering in the node.ref? (like freenet has) +01:35 <@nop> hence the need to fix some issues and advance in our need for privacy and security +01:35 <@nop> it's an ongoing battle +01:35 <@nop> but it's worth it +01:35 <@nop> well +01:35 <@nop> versioning might be an optional feature +01:35 <@nop> sounds like it will turn out important soon +01:36 <@nop> so it's in consideration +01:36 <@nop> will let you know next week +01:36 <@nop> ok +01:36 <@nop> I'm done +01:36 <@mids> k +01:36 <@nop> . +01:36 <@nop> any questions +01:36 <@mids> . +01:36 < Neo> Yeah. +01:37 < Neo> The fake traffic option. +01:37 < Neo> Wouldn't it be a good idea to have this turned on by default? +01:37 <@nop> it is +01:37 < Neo> good. +01:37 < Neo> thanks. +01:37 <@nop> it's been on since encryption came out to IIP +01:37 <@mids> fake traffic, what is the length again? +01:37 <@nop> it varies +01:38 <@nop> it's max is 50 bytes +01:38 <@mids> between fixed values isnt it? +01:38 <@nop> about the size of simulated chat messages +01:38 <@mids> cant you let it vary based on normal chat? +01:38 <@nop> it is as close as we can get at this time +01:38 <@nop> AI comes later +01:38 <@nop> ;) +01:38 <@mids> heh +01:39 < Banks> what do you mean mids? +01:39 <@nop> we plan to do that with iip 2 +01:39 <@nop> that will have more available techniques +01:39 <@mids> Banks: well, maybe 50 maximum is too short +01:39 <@mids> Banks: topic are much longer for example +01:39 < Banks> I see. Is it random text? +01:39 <@mids> Banks: and that might give away something +01:39 <@nop> yes +01:39 <@nop> I believe the values can be altered fairly easy +01:39 <@nop> ;) +01:40 < Banks> :) +01:40 <@mids> k +01:40 <@nop> any more questions +01:40 <@mids> feature request for 1.2: +01:40 <@nop> oh +01:40 <@nop> feature requests need to be posted on sourceforge +01:40 <@mids> keep record of average and SD of the lenght of lines +01:40 <@mids> yes, I know +01:41 <@nop> SD? +01:41 <@mids> standard diviation +01:41 <@nop> why? +01:41 <@mids> to be able to fake messages within the used scale +01:41 < Banks> mids: you mean per user or for all users? +01:42 <@mids> Banks: all users is safest +01:42 <@mids> hm, but harder +01:42 <@nop> well +01:42 <@mids> hm +01:42 <@nop> a nice goal +01:42 <@nop> would be this +01:42 <@nop> iip node takes data traffic +01:42 <@nop> analyzes it +01:42 <@nop> and scrambles it +01:42 <@nop> and uses it for it's seed of random spurting data +01:43 <@nop> that would give a bit of form of ai +01:43 <@mids> k +01:43 < Banks> might be better to get the random data from somewhere else. I mean, that's the data we're trying to keep secret :) +01:43 <@nop> what I mean +01:43 <@nop> not direct data +01:43 <@nop> but size of data info +01:44 <@nop> and +01:44 <@nop> spurt ratio of normal data +01:44 <@nop> so that it mimics +01:44 <@nop> actual data +01:44 < Banks> I see +01:44 <@nop> is randomized using yarrow +01:44 < Banks> Do you guys get notified of bugs added at sourceforge? +01:44 <@nop> I check daily +01:45 <@mids> and subscribers are emailed +01:45 < Banks> ok, just wanted to point out that node/relay settings bug if you hadn't seen it +01:45 <@nop> which one +01:45 < Banks> cool +01:45 <@mids> the one that you didnt see :) +01:45 < Banks> [ 563246 ] node/relay type settings cancellation +01:46 <@nop> ahh +01:46 <@nop> yes +01:47 <@mids> Banks: thanks for pointing out +01:47 <@mids> who does the windows code? +01:47 <@nop> that's not really a bug +01:47 < Banks> yeah, but it's not really a feature either :) +01:47 <@nop> right +01:47 <@nop> it warns you about your settings +01:48 <@nop> but +01:48 <@nop> we'll look into it +01:48 <@nop> thnx +01:48 < k> what's the time? +01:48 < Banks> np +01:48 <@mids> Tue Jun 4 23:48:37 UTC 2002 +01:48 <@mids> more item 2 questions? +01:48 <@nop> next on agenda +01:49 < k> what's that in central america? +01:49 <@mids> 4) IPv6 Support for IIP 1.2 +01:49 <@mids> http://www.timeanddate.com/worldclock +01:49 < k> thnx +01:50 <@mids> IPv6 is something that is going to be used more wide spread +01:50 <@mids> making IIP IPv6 compatible seems usefull +01:51 <@mids> does anybody have experience with making daemons IPv6 compatible? +01:51 <@nop> well +01:51 <@nop> I think it's fairly simple to make it ipv6 compatible +01:51 <@nop> it's really size and input, if your machine is compatible +01:51 <@nop> then it will just do it correctly +01:52 <@codeshark> node.ref parser? +01:53 <@mids> how does it know if it should use the IPv6 or IPv4 address when doing a DNS query? +01:54 <@codeshark> dns returns it +01:54 <@codeshark> either an A record +01:54 <@codeshark> or AAA +01:54 <@mids> dns returs both +01:54 <@mids> (if both exist) +01:54 <@codeshark> hmm, if it has both +01:54 <@mids> s/AAA/AAAA/ +01:54 <@UserX> ipv6 nodes would probably be indicated by adding a "transport" field to noderef with a value "tcp6" or similar +01:54 <@codeshark> right :) +01:55 < Aroonkoa> Nodes could be both ipv4 and ipv6, correct? +01:55 <@UserX> . +01:55 <@UserX> yes +01:56 <@mids> would be nice, that way you can make them gateways +01:56 <@codeshark> if nodes can be on ipv6, i need to connect to the ipv6 network with the nodechecker +01:56 <@codeshark> . +01:56 <@nop> right +01:57 <@nop> remember this is iip 1.2 +01:57 <@nop> so hopefully we'll be prepared for then +01:57 <@nop> . +01:57 <@mids> k +01:58 < k> me? +01:58 < k> j/k +01:58 <@mids> more IPv6? +01:58 <@nop> mids +01:58 <@nop> it won't be too hard +01:58 <@nop> I think that's it for ipv6 +01:59 <@mids> UserX's idea is great, that should solve all problems +01:59 <@mids> . +01:59 <@nop> yes +01:59 <@nop> . +01:59 <@nop> he always has great ideas +01:59 <@nop> . +01:59 <@mids> A) Questions +01:59 <@mids> ------------- +01:59 <@mids> Ask a question +01:59 <@nop> How does everyone like IIP so far +01:59 <@nop> ? +01:59 <@nop> ;) +02:00 < Banks> It's elite +02:00 < Zwolly> great and impressed +02:00 <@mids> I like it pure +02:00 <@nop> hehe +02:00 < Neo> Schweeet. +02:00 < Aroonkoa> Love it. +02:00 <@nop> awesome +02:00 < Zwolly> just looking fot this my whole internet irc life +02:00 < Zwolly> for +02:00 < Neo> We love it for what it is, and even more so for what it plans to be. +02:01 <@nop> neato +02:01 < Phiberoptika> bravo!: )))) +02:01 < Banks> It's not just a pipe dream. It's here, now. With promise for the future. +02:01 * Banks reaches for tissues. +02:01 <@nop> umm +02:01 <@nop> that was the idea +02:02 * Banks offers the box around. +02:02 <@nop> haha +02:02 <@nop> oh +02:02 <@nop> banks +02:02 <@nop> great job on iip logo design +02:02 <@nop> one comment +02:02 <@mids> what logo? +02:02 < Banks> shoot +02:02 <@nop> use it for docs if we can +02:02 <@nop> t-shirts +02:02 <@nop> and bumper stickers +02:02 <@nop> but website probably will be more light +02:03 <@nop> it's very cynical ;) +02:03 <@nop> and as a group +02:03 <@nop> we like it +02:03 <@mids> ah, banks did the logo, forgot +02:03 < Zwolly> t-shirts... there goes your anonimous life +02:03 < Neo> bumper stickers... lol +02:03 <@nop> just saying +02:03 <@mids> did everybody see it? I will put it on my site +02:03 < Banks> :) +02:03 <@nop> defintely on the docs though +02:03 <@nop> THat is the epitome of the docs +02:03 <@nop> and the software +02:04 <@mids> http://mids.student.utwente.nl/~mids/iip/meeting3/IIPlogo_bigger.png +02:04 <@mids> somebody who isnt here at the moment had a comment on the logo +02:05 <@mids> (s)he didn't quite like how the P worked out +02:05 < Banks> We can change IIP to stand for Invisible Internet Project if you like, which represents your long-term goals as I understand it. +02:05 <@mids> (but liked the whole concept) +02:05 < Banks> if we can think of a way to improve the P, we should. +02:06 <@mids> maybe a normal P? +02:06 <@nop> maybe make both +02:06 <@nop> irc and internet +02:06 <@nop> internet is a ways off +02:06 < k> just don't p on the floor, k? +02:06 <@nop> we have a joker in here +02:06 <@nop> hehe +02:06 <@nop> ;) +02:06 < Banks> :) +02:06 <@mids> well, there is an idea +02:07 <@mids> if you put the P a bit higher, it looks maybe better +02:07 <@mids> though I like the concept! +02:07 < Banks> mids: you can make those changes and send them around for comment if you want, or I can do it. +02:07 <@mids> I am not a gfx guy +02:08 < Banks> neither am I really :) +02:08 <@mids> :) +02:08 < Banks> I'll do a normal P and move it up and send it around +02:08 < k> what's the time in costa rica?? +02:11 <@mids> okay, I have a little idea +02:11 <@mids> everybody may promote his channel here now, with a oneliner +02:11 <@mids> include channelname + description +02:12 <@mids> #anonymous - general network channel, meet celibrities & crackheads +02:12 < Zwolly> channel Annemiek just for the fun and in dutch (or english) +02:12 * keimennA is afwezig [Slapen/sleeping] [1h22m52s] +02:13 < k> glad I got to know that.. +02:13 < Banks> #scientology is a classic example of the kind of channels which IIP is ideally suited to +02:13 < Banks> (it's not mine though :) ) +02:13 < k> lol +02:14 < Neo> #distributedcity - Sovereign Individuals +02:14 <@mids> #test - for all your testing +02:15 <@nop> #vegetarian for vegetarian (joke) +02:15 < Banks> #hacktivismo isn't up today +02:15 < Banks> Heh +02:16 <@mids> okay, any questions? (IIP related) +02:18 < Banks> Any way to improve fserve speed in the short-term? We could get a bigger user-base then. +02:18 <@nop> umm +02:18 <@nop> not without having flooding problems +02:18 <@codeshark> filesharing in iip is not a very good idea +02:19 <@codeshark> it's very inefficient +02:19 <@nop> wait till decentralized +02:19 <@codeshark> because of base64 encoding and additional irc headers +02:19 <@codeshark> ... +02:19 <@nop> then we'll make sure it's possible +02:19 < Banks> I think it's a priority for a lot of people though. I was just wondering if there was any way to improve it somewhat before decentralization. Ok. +02:20 <@nop> freenet gets it's act together +02:20 <@nop> and you can write an irc plugin +02:20 <@nop> :) +02:20 <@codeshark> yeah, integration with freenet or somthing like it would be great +02:20 <@mids> help freenet testing by running a watchme node +02:20 <@codeshark> watchme node? +02:20 <@mids> if they get that thing working again, freenet will be very usefull +02:21 <@mids> http://freenetproject.org/cgi-bin/twiki/view/Main/SpyWare +02:21 <@codeshark> statistics node? +02:21 < Banks> true +02:21 <@mids> it is a 'spyware' node, intended for debugging +02:24 < k> woo +02:25 <@mids> yes k? do you have a question? +02:25 <@mids> (no sorry, dont know the costa rica timezone) +02:26 < k> sorry - just celebrating out loud. +02:27 <@mids> question: how does the 'new' time suit you? +02:27 < k> huh? +02:28 <@codeshark> it's a bit better, but we need to make the meetings shorter +02:28 <@codeshark> . +02:28 < Banks> I won't be able to make it to the next meeting. I have unavoidable business all day. +02:28 <@nop> ok +02:28 <@nop> it's all good +02:28 <@mids> codeshark: any idea how to make it shorter? +02:29 <@codeshark> make it more efficient +02:29 <@codeshark> someone has to lead each topic +02:30 <@codeshark> . +02:30 <@mids> k +02:30 <@mids> I am going to sleep +02:30 <@mids> thanks all +02:30 <@codeshark> me too +02:31 <@mids> nop: can you moderate the channel again when the discussion is over? +02:31 <@nop> sure +02:31 <@mids> logger will be kept running for a while +02:31 <@codeshark> nop: anything left for discussion> +02:31 <@codeshark> ? +02:32 <@nop> not really +02:32 <@nop> no +02:32 <@nop> everyone go home +02:32 <@nop> haha +02:32 < Zwolly> thanx dad +02:32 <@nop> your welcome son +02:32 < Zwolly> hehe +02:33 -!- mode/#iip-dev [+m] by nop +02:33 <@nop> everybody out +02:33 <@nop> I need my time alone +02:33 <@nop> leave me be +02:33 * codeshark kicks out everyone +02:34 -!- Phiberoptika was kicked from #iip-dev by nop [nop] +02:34 -!- Neo was kicked from #iip-dev by nop [nop] +02:34 -!- keimennA was kicked from #iip-dev by nop [nop] +02:34 -!- keimennA was kicked from #iip-dev by nop [nop] +02:34 -!- mode/#iip-dev [+i] by codeshark +02:34 -!- keimennA was kicked from #iip-dev by nop [nop] +02:34 -!- k was kicked from #iip-dev by nop [nop] +02:34 -!- jakob[oFF] was kicked from #iip-dev by nop [nop] +02:34 -!- AndreGoldman was kicked from #iip-dev by codeshark [codeshark] +02:34 -!- Banks was kicked from #iip-dev by codeshark [codeshark] +02:34 -!- ion was kicked from #iip-dev by nop [nop] +02:35 -!- ellison was kicked from #iip-dev by nop [nop] +02:35 -!- Aroonkoa was kicked from #iip-dev by codeshark [codeshark] +02:35 -!- cohesion was kicked from #iip-dev by nop [nop] +02:35 <@codeshark> hehe +02:35 <+logger> abusive +02:35 <+logger> logging ended +--- Log closed Wed Jun 05 02:35:32 2002 diff --git a/i2p2www/meetings/logs/3.rst b/i2p2www/meetings/logs/3.rst new file mode 100644 index 00000000..8e8c4b93 --- /dev/null +++ b/i2p2www/meetings/logs/3.rst @@ -0,0 +1,9 @@ +I2P dev meeting, June 4, 2002 @ 23:00 UTC +========================================= + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/30.log b/i2p2www/meetings/logs/30.log new file mode 100644 index 00000000..d8ec71d6 --- /dev/null +++ b/i2p2www/meetings/logs/30.log @@ -0,0 +1,448 @@ +--- Log opened Tue Feb 11 23:36:59 2003 +23:37 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +23:37 [Users #iip-dev] +23:37 [ ArdVark ] [ logger ] [ mids] [ ptm ] [ UserX] +23:37 [ jeremiah] [ lonelynerd] [ pox ] [ thecrypto] +23:37 -!- Irssi: #iip-dev: Total of 9 nicks [0 ops, 0 halfops, 0 voices, 9 normal] +23:37 -!- Irssi: Join to #iip-dev was synced in 2 secs +23:57 < nop> hi hezekiah +23:58 < hezekiah> Hi. :) +23:58 -!- mode/#iip-dev [+o mids] by Trent +23:58 -!- mode/#iip-dev [+o nop] by Trent +23:58 <@mids> gimme an h. e. z. e. k. i. a. h +23:58 <@mids> hezekiah! +23:58 < hezekiah> lol +23:58 < lonelynerd> :D +23:58 < hezekiah> (Hmmm ....) +23:59 * hezekiah gets an idea wondering if I can do something in IRC. +23:59 <@nop> uh oh +23:59 -!- mode/#iip-dev [+o hezekiah] by Trent +23:59 -!- mode/#iip-dev [+o UserX] by hezekiah +23:59 < _42> what? +23:59 <@hezekiah> It works! +23:59 <@mids> kick me out? +23:59 <@hezekiah> Cool! +23:59 <@hezekiah> No. +23:59 -!- mode/#iip-dev [-o UserX] by mids +23:59 <@hezekiah> See if I could op UserX +23:59 <@nop> it worked yes +23:59 <@hezekiah> Oops. +23:59 <@mids> userx didnt identify +23:59 < _42> op everyone :) +23:59 <@hezekiah> Oh. +23:59 <@hezekiah> Sorry. +23:59 <@mids> he might be evil +23:59 <@mids> :) +23:59 <@hezekiah> My mistake. :( +23:59 <@mids> *grin& +23:59 <@hezekiah> I was just wondering if I could do it. (Good at C. Newborn at IRC.) +--- Day changed Wed Feb 12 2003 +00:00 <@nop> anonymity and authentication take practice hezekiah +00:00 <@mids> Tue Feb 11 23:00:05 UTC 2003 +00:00 < _42> Yeah, but we all know that nop is sa fe. +00:00 <@nop> you will learn grasshoper +00:00 <@nop> ok +00:00 <@nop> welcome +00:00 <@mids> Welcome to the 30th meeting +00:00 <@nop> _42 let's take this outside +00:00 <@nop> ;) +00:00 < thecrypto> yah! +00:00 < thecrypto> 30! +00:00 <@nop> sweet +00:00 <@nop> ok +00:01 <@nop> anyway +00:01 <@nop> welcome, do we have anything specific on the agenda +00:01 <@hezekiah> IIP 1.1 yet? +00:01 <@mids> nope! +00:01 < hobbs> 30 is the product of the first three primes. :) +00:02 <@nop> hehe +00:02 < thecrypto> yah! +00:02 < thecrypto> primes! +00:02 <@nop> simmer down everyone +00:02 <@mids> showstoppers for IIP 1.1: +00:02 <@mids> - file paths +00:02 < _42> what about them? +00:03 <@nop> 42 we have questions later +00:03 <@nop> after all this +00:03 <@nop> continue mids please +00:03 <@mids> 42 asked what is one with the file paths I guess +00:03 <@mids> I dont have other showstoppers +00:04 <@nop> oh +00:04 <@nop> well than do a . +00:04 <@nop> so we know +00:04 <@nop> sorry 42 +00:04 < _42> it's ok +00:04 <@nop> ok umm, I believe UserX is working on the file path issue +00:04 <@nop> I don't think he's at his keyboard at this moment +00:04 <@mids> he didnt yet +00:04 <@mids> I checked today +00:04 <@nop> but I'll see if I can get that done stat +00:05 <@hezekiah> I also proposed a solution. +00:05 <@nop> oh ok +00:05 <@hezekiah> I'm willing to code it if someone tells me what to do. +00:05 <@mids> read http://sourceforge.net/tracker/index.php?func=detail&aid=651711&group_id=50945&atid=461514 +00:05 <@mids> and fix it :) +00:05 <@nop> ok, mids I think you know the details of what we wanted done, but did we decide on the proper paths? +00:05 <@hezekiah> If that +00:06 <@hezekiah> mids: ... that's the bugtracker ID, then I've already read it. :) +00:06 <@mids> yeah +00:06 <@mids> first ~/.iip/ +00:06 <@mids> if not, current dir +00:06 <@hezekiah> Were we going to make an "install-local"? +00:07 <@mids> yes +00:07 <@hezekiah> BTW, accourding to my testing, the code already does that. +00:07 <@mids> I already made that I think... +00:07 <@hezekiah> It just requires that ~/.iip exists. +00:07 <@mids> hezekiah: it never ever puts iip.log in there +00:07 <@hezekiah> Ah. +00:07 <@hezekiah> That can be corrected. :) +00:07 <@mids> and maybe also not mynode.ref +00:07 <@hezekiah> Any other files that need to be there? +00:07 <@hezekiah> (I think it does put node.ref there.) +00:08 <@mids> userx' problem was that the logger code is very low level +00:08 <@hezekiah> How's that affect the file paths? +00:08 <@mids> and it doesnt have the extended features like '@' extends to path +00:09 <@hezekiah> (I wish people would tell me they want these things.) I can probably write that up for him. +00:09 <@hezekiah> In the development tree that is. I'm not sure what the logging code in head looks like. +00:10 <@hezekiah> I should be able to write that up for him in head as well. +00:10 <@hezekiah> I'll have to ask him exactly what he wants. :) +00:11 <@mids> do that +00:11 <@hezekiah> OK. :) +00:11 <@hezekiah> So exactly what files _aren't_ getting placed in ~/.iip? +00:12 <@hezekiah> You mentioned iip.log. +00:12 <@mids> according to codeshark: iip.log, isproxy.ini, mynode.ref, seed.rnd +00:12 <@hezekiah> Hmmm. +00:12 <@hezekiah> I can't remember which CVS tree I tested, but isproxy.ini, node.ref, and seed.rnd were are placed in ~/.iip. +00:13 <@hezekiah> The key was that ~/.iip needs to exist _and_ isproxy.ini needs to be in ~/.iip or not exist. +00:13 <@hezekiah> When those conditions are met, the 3 files I listed are placed in ~/.iip. +00:13 <@mids> if not, current directory +00:14 <@hezekiah> Right. +00:14 <@hezekiah> isproxy.ini listen.ref node.ref seed.rnd +00:14 <@hezekiah> Those are the files that the development branch places in ~/.iip. +00:14 <@mids> what about mynode.ref ? +00:15 <@hezekiah> mids, I've never met a file called mynode.ref. +00:15 <@hezekiah> What is it? +00:15 <@mids> it is created if you make a public/private relay +00:15 <@mids> contains the info that is also sent to inform +00:15 <@nop> yes +00:16 <@nop> it's designed for if you want to do neighbor noding +00:16 <@hezekiah> It is only mentioned in active sourcecode at: iip/iip-ui.c:650 +00:16 <@nop> they specifically piggy back off you +00:16 <@nop> so they can bootstrap +00:16 <@nop> into the network +00:18 <@mids> ok +00:18 <@mids> keep in mind that the filepath can be changed +00:18 <@mids> it has to work if the filepath is changed too +00:18 <@hezekiah> (I'm looking into where mynode.ref gets placed.) +00:18 <@mids> or if the location for the individual files are specified too +00:18 <@hezekiah> mids: right now the filepath is hardcoded into the code. +00:19 <@mids> -f lets you change the path +00:19 <@hezekiah> If features are added in the future to do those things, then the code can be adapted to work with them. +00:19 <@mids> see my manpage :) +00:19 <@hezekiah> Hmmm ... odd. +00:20 <@hezekiah> Oh, duh! Right, the part that's hardcoded is used as a default parameter. +00:21 <@mids> thats fine +00:21 <@hezekiah> Anyway, I'll talk to UserX and see what he has done/wants done. :) +00:21 <@nop> coo +00:21 <@mids> huya +00:21 <@hezekiah> huya? +00:21 <@mids> lets try to get this done BEFORE the next meeting +00:22 <@hezekiah> If I can catch UserX before the next meeting (which I should), and I can get rid of this cold (which I should), and I don't make any more braindead mistakes (which I hope I won't), then hopefully, it will be. +00:22 <@hezekiah> (Note I garuntee nothing: Coding is far to volatile [no pun intended] to do that.) +00:23 <@mids> would be awesome +00:23 <@mids> okay +00:23 <@mids> other release issues? +00:23 <@mids> did everybody look at the new manpage? +00:23 <@mids> can the old one be removed? +00:23 <@hezekiah> Yeah. +00:23 <@hezekiah> Do you want it removed? +00:24 <@mids> I'll do that right away +00:24 <@mids> I wont put the .1 manpage in CVS +00:24 <@mids> if we release, it has to be created +00:25 <@mids> I'll send my Makefile with install-local to the mailinglist +00:25 <@hezekiah> Should the makefiles create the manpage? +00:25 <@mids> not right now +00:26 <@mids> end-users dont need to have perl +00:26 <@hezekiah> OK. Should they be installed by the Makefile? +00:26 <@mids> (which ships perldoc) +00:26 <@mids> future versions can have a make distribute or something +00:27 <@hezekiah> I'm asking these questions because right now the automake Makefiles for the development tree install the isproxy.1 manpage. +00:27 <@mids> making a directive that makes an isproxy.1 out of isproxy.pod should be simple +00:28 < lonelynerd> [ +00:28 <@hezekiah> Right. But that makes the end user require perl. :) +00:28 < lonelynerd> whoops +00:28 <@mids> pod2man -s 1 -c isproxy -r $VERSION ./$NAME/doc/isproxy.pod >./$NAME/doc/isproxy.1 +00:28 <@hezekiah> Remember, you said you don't want them to need perl. +00:28 <@mids> then put that in the make distribute code +00:28 <@mids> I am more talking about requirements for 1.1 +00:28 <@mids> 1.2 is different +00:29 <@mids> k +00:30 <@mids> TODO: mids mail install-local makefile +00:30 <@mids> hezekiah contact userx +00:30 <@hezekiah> Right. +00:30 <@mids> nop: look at podfile +00:30 <@mids> okay, for install-local +00:30 <@mids> where should the binary and manpage be installed? +00:30 <@mids> ~/bin and ~/man or something? +00:31 <@mids> or not install manpage.. +00:31 <@hezekiah> What did UserX say in our email conversation? +00:31 <@nop> ok +00:31 <@hezekiah> Oops. +00:32 <@hezekiah> nop? +00:32 <@nop> yes +00:32 <@nop> which email conversation +00:32 <@hezekiah> You were saying something. :) +00:32 <@nop> no +00:33 <@nop> just saying I'd look at podfile +00:33 <@hezekiah> Oh, mids, UserX, and I were going back and forth about what to do with the file path problem. +00:33 <@hezekiah> Part of that involved making an install-local makefile target. +00:33 <@hezekiah> I think I sent CC's of all my messages to you. +00:33 <@mids> did get some +00:33 <@hezekiah> Except for one that your email box wouldn't accept because it was full. +00:33 <@hezekiah> (I anonymailed you the summary of that one.) +00:34 <@hezekiah> I quote from UserX: "A possible solution to this is to add a "install-local" target to the Makefile. This would put the executable in ~/bin/ and other files in ~/.iip/." +00:35 <@mids> mail sent +00:37 <@hezekiah> So for now, install-local only copies node.ref and isproxy. +00:37 <@hezekiah> I still see a small problem. +00:37 <@hezekiah> When the user just runs "make install". +00:38 <@hezekiah> ... then ~/.iip doesn't get created. +00:38 <@hezekiah> Thus, isproxy will still leave its files in the current directory. +00:38 <@mids> can you check userid with make? +00:38 <@hezekiah> Huh? +00:38 <@mids> so if you arent root, make install will give an error +00:39 <@hezekiah> You can run a command like whoami. +00:39 <@mids> would that be an option? +00:39 <@hezekiah> id -u +00:39 <@hezekiah> That should spit out the numeric ID of the user. +00:40 <@mids> "Error: make install requires you to be root, use make install-local instead" +00:40 <@hezekiah> Well, they should get that anyway if they are trying to copy files to /usr/local/bin +00:41 <@hezekiah> It still doesn't fix the problem: isproxy will not place files in ~/.iip unless it exists, and "make install" doesn't create it. +00:41 < nemesis> can i speak? +00:41 <@hezekiah> (I don't see why not. Nop or mids can he speak? +00:41 <@hezekiah> ) +00:41 < nemesis> ;) +00:41 <@mids> please speak +00:42 < nemesis> anyone know the linux distri SoL (server optimized linux) ? there are a root /server for all servers, unreal are added too +00:42 <@mids> (hezekiah: make install makes /home/iip/.iip/ and installs there) +00:42 < nemesis> it would be nice when iip goes someday in that distri +00:43 < _42> What about configure --prefix=~ ? +00:43 < nemesis> any suggestions? +00:43 <@mids> _42: 1.1 doesnt have configure yet, 1.2 does +00:43 < _42> oh. +00:43 <@hezekiah> _42: the main branch of CVS doesn't have a configure script. +00:43 <@mids> _42: good point though +00:43 <@hezekiah> _42: but I already suggested that for 1.2. :) +00:44 <@mids> nemesis: once 1.1 is out, we'll ask distributetions to make packages +00:44 <@mids> which leads us to the following, we need an init.d script +00:44 <@mids> we should really supply that +00:44 < nemesis> SoL usese XML for that +00:44 < nemesis> very nice configs... +00:44 < _42> mids: they're distro-defined. I might be able to write a gentoo one. +00:45 <@hezekiah> And Gentoo uses a different format than most. +00:45 <@mids> iip.1.1.showstoppers.add(init.d-script) +00:45 <@mids> maybe we can supply a general one? +00:45 <@hezekiah> I wouldn't bet on it working. +00:45 <@mids> ah +00:45 <@mids> so, we dont have to? +00:45 <@hezekiah> I'd save leave it to the distros, or make distro-specific ones. +00:45 < _42> mids: gentoo uses a dependency system with its init.d scripts. It's simple, but incompatible. +00:45 <@mids> k +00:45 <@mids> then lets leave it +00:46 <@mids> I still have some contact info of a debian packages +00:46 <@hezekiah> _Especially_ when not all distros even USE init.d! (Gentoo uses a totally different format.) +00:46 <@hezekiah> OK. :) +00:46 <@mids> he offered to package iip in the past +00:46 <@hezekiah> Cool! :) So where were we? +00:46 <@mids> show stoppers +00:46 <@mids> any more? +00:46 <@hezekiah> Oh, yeah. +00:46 <@hezekiah> I don't know of any +00:46 < nemesis> when will 1.1 be released? ;) +00:46 <@mids> nemesis: once all the show stoppers are tackled +00:47 <@hezekiah> When we fix all the showstoppers! ;-) +00:47 <@mids> what about the windows helpfile thing +00:47 <@mids> how does that work atm? +00:47 < nemesis> *g* k thx +00:47 <@mids> what does it say +00:47 < _42> mids: If I knew the proper start/stop commands I could write a gentoo runscript. +00:47 <@hezekiah> I have no clue. I don't use Windoze unless I need to. +00:47 <@mids> I believe that codeshark made a 'no help right now, see http://help.invisiblenet.net/' or something +00:47 <@hezekiah> (If it comes to that, I could write one, _42. I use Gentoo.) +00:47 <@mids> thx +00:48 < _42> hezekiah: how about one of us does the ebuild, and the other the init.d? :) +00:48 <@hezekiah> Fine. I don't really care. :) +00:48 < _42> yes, but who does what? +00:48 <@mids> ok +00:48 <@mids> any windows user? +00:48 <@hezekiah> You can do both if mids lets you. :) +00:49 <@mids> it wont be bundled in the 1.1 release itself +00:49 * hezekiah listens to the thunderous silence resounding through the room. +00:49 <@mids> oh yeah +00:49 <@hezekiah> What? +00:49 <@mids> nop had to read through the docs +00:49 <@mids> some crypto things changed +00:50 < _42> what, the ebuild? of course not. That's distributed from Gentoo HQ. in a mysteriopus complex in (DELETED FOR DISTRO SECURITY REASONS) via rsync +00:50 <@hezekiah> So what's the list of stuff we need to do until 1.1 look like now? +00:50 <@hezekiah> _42: I know. But you can write one and submit it to the bugzilla list. +00:50 <@mids> - filepath +00:50 <@mids> - install-local +00:50 <@mids> - readme, install, authors update +00:51 <@mids> - windows documentation check +00:51 <@mids> . +00:51 <@hezekiah> - and nop needed to look at those docs you mentioned? +00:51 <@nop> ok +00:51 <@hezekiah> Or was that the windoze doc check? +00:52 <@mids> well +00:52 <@mids> the docs on http:L +00:52 <@hezekiah> Ah! :) +00:52 <@mids> http://help.invisiblenet.net/ can be changed also after release +00:52 <@hezekiah> So my work is talking to UserX about the filepath stuff and seeing how I can help all this. +00:52 <@mids> yes +00:52 <@mids> and pushing us to do our stuff +00:52 <@hezekiah> lol. +00:53 <@hezekiah> I wouldn't do good at that. You're better at pushing. ;-) +00:53 <@mids> I k +00:53 <@mids> I'll request daily updates +00:53 <@mids> at 8.00 am +00:53 <@mids> :) +00:53 <@hezekiah> Do I change the development automake Makefile templates to mimic your install-local, or does it need to be reviewed first? +00:54 <@mids> it is a request for comments +00:54 <@hezekiah> Ah. +00:54 <@mids> lets first put it in 1.1, if everybody agrees +00:54 <@mids> cvs dev can be done later +00:54 <@hezekiah> I have a comment: let's make a PREFIX var. +00:54 <@hezekiah> Right now /usr/local is hardcoded into several variables. +00:55 <@mids> in Makefile? +00:55 <@hezekiah> This is a pain for anyone that needs to install on a system that doesn't use /usr/local. +00:55 <@hezekiah> Yeah. +00:55 <@mids> ok +00:55 <@hezekiah> i.e. INSTALLEXEPATH would look like this +00:55 <@hezekiah> > PREFIX=/usr/local +00:55 < _42> what's the syntax for checking out the 1.1 branch? +00:55 < _42> from cvs +00:55 <@mids> 1.1 is HEAD +00:55 <@hezekiah> > INSTALLEXEPATH=$(INSTALLEXEPATH)/bin +00:55 <@hezekiah> . +00:55 < _42> ok +00:56 <@hezekiah> 1.2 is development. :) +00:56 <@hezekiah> ;-) +00:56 < _42> oh, how zen +00:56 < _42> You must be one with the development... +00:56 <@hezekiah> Anyway, a PREFIX var would let someone go "make PREFIX=/usr install" instead of setting 3-4 other variables. +00:57 <@hezekiah> _42: yeah. :) +00:57 <@hezekiah> _42: but I do bugfix stuff for 1.1 too ... it's just that most my code goes in development. +00:57 <@mids> how do you let make PREFIX= override the PREFIX in the Makefile? +00:57 <@hezekiah> "make PREFIX=/usr install" +00:57 < _42> 'k. But if dev is in CVS, wouldn't a co without a -r get it as well? +00:57 <@mids> I mean, in the makefile itself +00:58 <@hezekiah> It would override whatever PREFIX was set to in the makefile. +00:58 <@mids> automagically? +00:58 <@hezekiah> If PREFIX=/usr/local in the makefile "make PREFIX=/usr install" makes PREFIX=/usr instead. +00:58 <@mids> great +00:58 <@hezekiah> That's one way how Gentoo ebuild get around anoying makefiles. :) +00:58 <@mids> ok +00:59 <@mids> nother thing +00:59 <@hezekiah> Cool. +00:59 <@mids> in iip/doc/help/imaghes +00:59 <@mids> iomages +00:59 <@mids> images even :) +00:59 <@mids> there are some bmp files +00:59 <@mids> I believe that they can be removed +00:59 <@mids> iip.pdf in doc/help too +00:59 <@hezekiah> You sure the files in doc/help don't use them? +00:59 <@mids> no idea +00:59 <@mids> I am not a windows guy +00:59 <@hezekiah> (Ouch.) +01:00 <@mids> should ask codeshark +01:00 <@mids> he made em +01:00 <@hezekiah> Neither here, but I try to be careful. +01:00 <@hezekiah> I'll leave the removing of files from the HEAD branch to you. :) +01:00 <@hezekiah> (... and keep my neck safely on my shoulders.) ;-) +01:00 <@mids> ok, I removed isproxy.1 from both branches +01:00 <@hezekiah> Ah. +01:00 <@mids> super todo: mail todo list to mailinglist +01:00 <@mids> :) +01:00 <@hezekiah> lol +01:01 <@hezekiah> First we should update it. +01:01 <@hezekiah> There are a bunch of things I've done that never got checked off. +01:01 <@hezekiah> Also, the development branch makefiles depended on isproxy.1. +01:01 <@mids> oh +01:01 <@mids> I already removed isproxy.1 from dev +01:02 < _42> The Makefile should support copying files to one dir but configuring the executable for another +01:02 <@hezekiah> So what do I do _exactly_ with isproxy.pod? +01:02 <@mids> here it comes: +01:02 < hobbs> mmm. pod. +01:02 <@hezekiah> Well, we can put it back if we need to, but I think there are better things to do. :) +01:02 <@mids> hezekiah: pod2man -s 1 -c isproxy -r $VERSION ./$NAME/doc/isproxy.pod >./$NAME/doc/isproxy.1 +01:02 <@hezekiah> _42: it does. The executable and makefiles go in different places. They were both targets for "make install" though. +01:03 <@mids> I hope that the makefile knows the version somehow +01:03 <@hezekiah> I can handle that. +01:03 <@hezekiah> But this makes the user require perl. +01:03 <@nop> sorry guys I'm in and out +01:03 <@nop> at work so +01:03 <@hezekiah> (We were over this before.) +01:03 < _42> No, I mean copy the files to one directory specified by overriding a makefile var and configure them for another +01:03 <@hezekiah> No problem. :) +01:03 <@mids> you can replace "./$NAME/doc/isproxy.pod >./$NAME/doc/isproxy.1" with "$? > $@" +01:03 < _42> k +01:04 <@hezekiah> OK. +01:04 <@hezekiah> But this still leaves the user of the development branch dependant on perl. +01:04 <@hezekiah> Is that OK? +01:04 <@mids> depend on pod2man +01:04 <@hezekiah> OK. +01:04 <@hezekiah> So I make the configure script look for it. +01:04 <@mids> yes +01:05 <@mids> _42: doesnt gentoo patch makefiles etc? +01:05 <@mids> (like freenet does) +01:05 <@hezekiah> nop: any objections to me having the configure script look for pod2man and having the makefile (in the development tree) build the manpage? +01:05 <@hezekiah> mids: Gentoo uses patches, sed, or just sets makefile VAR's. +01:06 <@hezekiah> mids: whichever least drastic measure is required. :) +01:06 * mids guesses that nop doesnt object +01:06 < _42> mids: it can, but it's easier to add a PREFIX=${D}/ +01:06 <@mids> _42: yop +01:06 < _42> freenet patches akefiles? +01:06 <@mids> freebsd +01:06 < _42> ah +01:07 <@mids> or maybe it doesnt +01:07 <@mids> anyway +01:08 <@mids> - filepath (A hezekiah, userx) +01:08 <@mids> - Makefile install-local,PREFIX +01:08 <@mids> - README, INSTALL, AUTHORS (mids) +01:08 <@mids> - windows documentation (codeshark) +01:08 <@mids> - docs (nop) +01:08 <@mids> any additions? +01:09 <@mids> otherwise I'll mail that +01:09 <@hezekiah> Not that I can think of. :) +01:10 <@mids> who will do the makefile? +01:10 <@mids> me? +01:10 <@hezekiah> You do the HEAD one. +01:10 <@mids> I am talking about HEAD +01:11 <@hezekiah> I usually take care of the makefiles/configure script in development. :) +01:11 <@hezekiah> You do it. :) +01:12 < lonelynerd> what about debian packages? ;) +01:12 <@mids> lonelynerd: that can be done after the code is frozen / release is made +01:12 < lonelynerd> sure +01:13 <@mids> TODO mailed +01:13 <@mids> ok +01:13 <@mids> question round? +01:14 <@mids> question round. +01:14 < hezekiah> Sorry about that. +01:14 < hezekiah> I got disconnected. +01:14 <@mids> you did? :) +01:14 < hezekiah> Yeah. :) +01:16 <@mids> okay, meeting participants without questions are not allowed to ask any for a week if they could ask them now :) +01:16 < hezekiah> lol. +01:16 < hezekiah> mids: do people actually come up to you with questions during the week? +01:17 <@mids> shiploads +01:17 < hezekiah> Wow! +01:17 < lonelynerd> ;) +01:17 <@mids> mostly in #iip and #help +01:17 < hezekiah> Oh. "Mommy, Mommy! What's an isproxy!?" +01:17 < hezekiah> ;-) +01:17 <@mids> RTFM +01:18 < hezekiah> lol +01:18 <@mids> ok +01:18 <@mids> end? +01:18 * hezekiah hands mids his gaffle to "baf" +01:18 <@mids> baf it will be +--- Log closed Wed Feb 12 01:19:02 2003 diff --git a/i2p2www/meetings/logs/30.rst b/i2p2www/meetings/logs/30.rst new file mode 100644 index 00000000..9aca2754 --- /dev/null +++ b/i2p2www/meetings/logs/30.rst @@ -0,0 +1,9 @@ +I2P dev meeting, February 11, 2003 @ 23:00 UTC +============================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/31.log b/i2p2www/meetings/logs/31.log new file mode 100644 index 00000000..05ee9521 --- /dev/null +++ b/i2p2www/meetings/logs/31.log @@ -0,0 +1,437 @@ +--- Log opened Tue Feb 18 23:54:43 2003 +23:54 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +23:54 [Users #iip-dev] +23:54 [ aum ] [ bpb ] [ jeremiah ] [ logger] +23:54 [ Barney] [ codeshark] [ LeerokOnKnoppix] [ mids ] +23:54 -!- Irssi: #iip-dev: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal] +23:54 -!- Irssi: Join to #iip-dev was synced in 2 secs +23:55 * bpb points at the logging bot then jumps up and down like a japanese animated school girl +23:55 -!- mode/#iip-dev [+o mids] by Trent +23:55 -!- mode/#iip-dev [+v logger] by mids +23:57 -!- LeerokOnKnoppix is now known as Trent +23:57 -!- Trent is now known as nickthief76011 +23:57 <@mids> :p +23:57 -!- nickthief76011 is now known as LeerokOnKnoppix +23:57 < lonelynerd> wwwhat? +23:58 <@mids> Trent protects the nick +23:58 < lonelynerd> oh, nothing +23:58 < LeerokOnKnoppix> How does it do that? +23:58 -!- LeerokOnKnoppix is now known as _Trent +23:58 < _Trent> I am Trent, hear me roar! +23:58 < hezekiah> LOL +23:58 < _Trent> Get out, all unverified users! +23:59 -!- mode/#iip-dev [+o hezekiah] by Trent +23:59 < _Trent> What about me? +23:59 <@mids> hey hezekiah :) +23:59 -!- _Trent is now known as LeerokOnKnoppix +23:59 <@hezekiah> Hi, mids. :) +23:59 <@hezekiah> I think I'm getting the hang of some of this IRC thing! :) +23:59 <@mids> kool +--- Day changed Wed Feb 19 2003 +00:00 <@hezekiah> So have any bugs defied the great IIP dev team and risen their ugly heads since your last mail to the iip-dev mailinglist? +00:01 < LeerokOnKnoppix> It disconnects every now and then. +00:01 <@hezekiah> I don't seem to experiance that bug. :( +00:01 < lonelynerd> LeerokOnKnoppix, it's probably your connection. i haven't had any problems +00:01 < LeerokOnKnoppix> Hmm. +00:01 <@hezekiah> mids: Where are nop and UserX? +00:01 <@mids> Tue Feb 18 23:01:51 UTC 2003 +00:01 <@mids> user was here but he pinged out +00:01 < LeerokOnKnoppix> _Trent kicked them out. +00:02 <@mids> userx +00:02 <@mids> just icq-ed nop +00:02 < LeerokOnKnoppix> Is he coming? +00:02 <@mids> dunno +00:02 < bpb> lonelynerd: it's always happened though... and it's not just him +00:03 < lonelynerd> bpb, still, it's not a problem with iip but unreliable connections +00:04 <@mids> nop is comming +00:04 < nop> hi +00:04 < lonelynerd> hi +00:04 < nop> ok +00:04 < nop> welcome +00:04 < LeerokOnKnoppix> Hello nop. +00:04 <@hezekiah> Hi, nop! :) +00:04 < nop> Leerok likes Knoppix? +00:04 < LeerokOnKnoppix> So far. +00:04 < nop> kewl +00:04 < nop> ok +00:04 < bpb> lonelynerd: it's a problem with the actual network then +00:04 < LeerokOnKnoppix> But I want to install it to the hard drive. +00:04 < LeerokOnKnoppix> But it didn't work when I tried it. +00:04 < nop> well, welcome to the 31st meeting +00:04 < nop> of IIP-dev +00:04 < LeerokOnKnoppix> Cool. +00:04 < lonelynerd> bpb, well, it could handle unrealiable links, but it doesn't at the moment +00:04 < LeerokOnKnoppix> I'm just hanging around to let knowledge osmose into my head. +00:05 < nop> ok +00:05 < nop> shh +00:05 < nop> meeting started +00:05 < nop> on the agenda +00:05 -!- mode/#iip-dev [+o nop] by mids +00:05 <@nop> IIP 1.1 and pleasantries with that +00:05 <@nop> hezekiah: +00:06 <@hezekiah> Yeah? +00:06 <@nop> hezekiah: all entropy stuff have we resolved? For instance the hhhhhh issue +00:06 <@hezekiah> I just told you about the hhhhhhhh isue. +00:06 <@hezekiah> We haven't done anything about it yet. +00:06 <@nop> ok +00:06 <@hezekiah> The seed.rnd issue is resolved by porting the --randomdialog option from development .. +00:06 <@nop> ok +00:07 <@nop> and can you explain what they do +00:07 <@nop> just for the record +00:07 <@hezekiah> ... and having IIP abort when seed.rnd doesn't exist. +00:07 <@hezekiah> Explain what --randomdialog and --ignoreemptyrandom do? +00:07 <@nop> yes +00:07 <@hezekiah> OK. :) +00:07 <@nop> for official purposes +00:07 <@nop> aka the meeting +00:07 <@hezekiah> Right. :) +00:08 <@hezekiah> When isproxy is run with --randomdialog, the user is asked for entropy (even is seed.rnd already exists). +00:09 <@hezekiah> When isproxy is run with --ignoreemptyrandom, and there isn't enough entropy (a condition that would cause isproxy to _normally_ abort), the program just keeps going. This is a security risk, so a suitablely scary warning label is added in the help description. +00:09 <@hezekiah> (Speaking of all these options, unless mids as already added them, they aren't in the isproxy.pod file yet.) +00:09 <@hezekiah> . +00:09 <@mids> I didnt +00:09 <@hezekiah> We should do that before release. :) +00:10 < lonelynerd> (shouldn't it be --random-dialog and --ignore-empty-random ? ;P) +00:10 <@hezekiah> lonelynerd: I code what UserX orders. :) +00:10 < lonelynerd> ok +00:10 <@hezekiah> nop: So, the seed.rnd problem is solved, but the hhhhhhhh problem isn't. +00:10 <@nop> right +00:11 <@nop> hmm, well, we could have a counter that won't allow the same keystroke more than three times in a row +00:11 <@hezekiah> (I don't even know if hhhhhhhh is a problem. I just mentioned it to you and UserX. You tell me!) :) +00:11 <@nop> real simple +00:11 <@nop> it's a slight problem +00:11 <@hezekiah> PGP some how knows how much entropy text is worth. +00:11 <@nop> well, we calculate the keyboard timings as well +00:12 <@nop> we could just force a wait till something beyond 3 same char in a row are pressed +00:12 <@hezekiah> Does GPG evaluate the entropy of a string of text? If they do, we could look at their code. :) +00:12 <@nop> I am not sure +00:12 <@nop> I advise looking at it +00:12 < lonelynerd> hezekiah, i think it just uses /dev/random, or? +00:12 <@nop> lonelynerd no +00:12 <@nop> it doesn't +00:13 < lonelynerd> ah +00:13 <@nop> we're talking about creation of entropy +00:13 <@nop> aside /dev/random +00:13 <@nop> like an Initialization +00:13 <@hezekiah> GPG does make the user pound on the keyboard. :) +00:13 <@mids> well no +00:13 <@mids> it reads from the entropy pool +00:13 <@mids> and suggests that you move the mouse + press keys +00:14 <@mids> but entropy pool can be filled with interrupts etc too +00:14 <@nop> yes +00:14 < lonelynerd> yep +00:14 <@hezekiah> Ah. I just remembered when GPG made me pound on the keyboard once. ;) +00:14 < lonelynerd> it was pgp perhaps? +00:14 <@hezekiah> Nope. It was GPG running under Mandrake Linux. +00:14 < Barney> yep +00:15 <@hezekiah> (It was a few years ago, before AES was released I remember.) Anyway, back on topic. :) +00:15 <@nop> I think we should look at the code +00:15 <@hezekiah> OK. :) +00:15 < lonelynerd> :) +00:15 <@nop> if it's not clear, I suggest limiting the characters in a row +00:15 <@nop> and waiting +00:15 <@nop> for new characters to be pressed +00:15 <@hezekiah> Are there any methods outline (maybe in whitepapers from acedemia) on evalutating the entropy worth of a string of text? +00:16 <@nop> yes there are, I will dig them up in a bit +00:16 <@hezekiah> Cool! :) +00:16 < lonelynerd> "ent - A pseudorandom number sequence test program" +00:16 <@nop> yes, chi squaring +00:16 <@hezekiah> We could just implement one of those. (Believe it or not, it might be faster than digging through GPG code!) :) +00:16 <@nop> http://www.gnu.org/software/gnu-crypto/api/gnu/crypto/tool/Ent.html +00:17 <@nop> that's java +00:17 <@nop> but still +00:17 <@hezekiah> I can read Java. :) +00:17 <@hezekiah> I can translate too. :) +00:17 < lonelynerd> ent is in C, too +00:17 <@nop> yep +00:17 <@hezekiah> lonelynerd: Where can I find the C version? +00:18 < lonelynerd> apt-get inst.. whoops, ;P http://www.fourmilab.ch/random +00:18 < lonelynerd> Upstream Author(s): John Walker +00:21 <@nop> ok +00:21 <@nop> anyway +00:21 <@nop> I'm sure that needs to be taken care of b4 1.1 +00:21 <@nop> this will give mids time to update isproxy.pod +00:21 <@hezekiah> lol +00:21 <@mids> pff +00:22 <@mids> say nop, did you work on the docs? :) +00:22 <@nop> ;) +00:22 <@nop> I am working on them +00:22 <@nop> and I have an editor too ;) +00:22 <@mids> well +00:22 <@mids> dont edit the html +00:22 <@nop> I know +00:22 <@nop> I'm just writing it in notepad +00:22 <@nop> ;) +00:22 <@mids> just send me the text changes, yeah thats fine +00:22 <@hezekiah> Yay! Real HTML coder! Uses a plain text editor! ;-) +00:23 <@nop> haha +00:23 <@nop> I ain't coding it +00:23 <@nop> just typing the doc +00:23 <@nop> ;) +00:23 <@mids> so +00:24 <@mids> will any more features slip in for 1.1? +00:24 * mids hopes not +00:24 <@mids> I tried to contact codeshark +00:24 <@nop> no +00:24 <@mids> but didnt get a reply yet +00:24 <@nop> it's not a feature +00:24 <@nop> it's a bug fix +00:24 <@nop> ;) +00:25 <@nop> anyway +00:25 <@nop> moving forward +00:25 <@mids> ok, I got other things to do +00:25 <@mids> if you need me shout loud +00:25 < lonelynerd> (gpg seems to use get_entropy_count(fd) to check how many bytes /dev/random has to offer) +00:26 <@nop> right +00:26 <@nop> aka checking the entropy pool size +00:26 < lonelynerd> which is some ioctl +00:26 < lonelynerd> dunno how that would work under windows +00:26 <@hezekiah> lonelynerd: It probably _doesn't_ work under windows. This a GNU project, remember? :) +00:27 < lonelynerd> great :) +00:27 <@hezekiah> What we really want (at least I think we do) is something that can evaluate how much entropy is in a buffer of text. +00:27 < lonelynerd> but gpg supports also other means to get entropy +00:27 <@nop> yes +00:27 <@hezekiah> That way we can have the user keep pounding until we get that much _REAL_ entropy. :) +00:27 < lonelynerd> hezekiah, ok +00:27 <@nop> yes +00:27 <@nop> we should have 1 bits per 3 characters +00:28 <@nop> technically that's considered secure entropy +00:28 < lonelynerd> ok, but under linux it could just read /dev/random +00:28 < lonelynerd> let the windows users type ;) +00:28 <@hezekiah> Well, isn't "randomentropyneeded" the number of bytes of entropy still needed? +00:28 <@nop> yes +00:29 < LeerokOnKnoppix> MD5sum of the registry. +00:29 <@hezekiah> lonelynerd: UserX, nop, and I have talked about ways to get IIP to use /dev/urandom under controlled circumstances. +00:29 < lonelynerd> hezekiah, hmm +00:29 < lonelynerd> hezekiah, urandom is just like random, but it doesn't block when there isn't enough entropy? +00:31 <@hezekiah> I think so. Is that right, nop? +00:31 <@nop> yes, with urandom you can assign the amount of entropy in advanced +00:31 < lonelynerd> so urandom might or might not be secure +00:32 <@nop> urandom just uses random +00:32 < lonelynerd> yep +00:33 <@hezekiah> lonelynerd: That's the issue. :) We considering compiling a list of OS's (and their versions) with secure instances of /dev/urandom, and having IIP use it when it's secure; when it's not secure, IIP would stick with the current methods. It's a thought. :) +00:33 <@nop> right, but not for 1.1 +00:33 <@nop> ;) +00:33 <@hezekiah> Of course! +00:33 < lonelynerd> hezekiah, wouldn't that be "secure versions of random" and not urandom? +00:33 <@hezekiah> This is all 1.2 stuff I'm talking about. (I am usually always talking 1.2 unless otherwise stated!) +00:33 < lonelynerd> ok +00:33 < lonelynerd> sounds great +00:34 <@nop> lonelynerd nothing wrong with urandom if random is considered secure +00:34 < lonelynerd> well if you check that there is enough entropy +00:36 <@hezekiah> So, nop? How exactly do we handle this hhhhhhhh problem? +00:36 <@nop> well +00:36 <@nop> for 1.1.0 I would limit the amount of repeated characters +00:36 <@nop> in a row that is +00:36 <@nop> and then leave it for in depth discussion in 1.2 +00:37 <@hezekiah> OK. But what happens when someone does pattern like "hHhHhHhHhHhHhH"? +00:37 < lonelynerd> :) +00:37 <@nop> we need to create a counter that spaces it out +00:37 <@hezekiah> (Let's assume the user is an idiot. The software is only as secure as the user!) :) +00:37 <@nop> so so many bytes can not contain this letter +00:37 <@nop> since last used +00:37 < jeremiah> hello +00:37 <@nop> hi +00:37 <@hezekiah> jeremiah: hi. :) +00:37 < jeremiah> hey hezekiah +00:38 <@nop> for instance [h][H][xonH[xonH[ etc +00:38 <@hezekiah> So, 'h' can't be repeated more than _m_ times in _x_ bytes? +00:38 <@nop> yes +00:38 < jeremiah> are we talking about buffer overflows? +00:38 <@nop> it will be considered rejected entropy +00:38 <@hezekiah> jeremiah: Nope! We're talking about entropy! :) +00:38 <@nop> but still log the keyboard timings +00:38 <@nop> just ignore it as a string +00:39 < jeremiah> random number generators are supposed to make sure there isn't a correlation with the numbers anyways +00:39 < jeremiah> you can do that with chi-square +00:39 < jeremiah> right? +00:40 <@nop> well yarrow helps mix +00:41 <@hezekiah> You said we "log the keyboard timings". What's that mean? +00:42 < jeremiah> hezekiah: times between when you hit keys +00:42 < lonelynerd> that's difficult if input is buffered +00:42 <@nop> just do the character thing, it will be fine +00:42 <@nop> yarrow does the rest +00:42 <@hezekiah> nop: Are we getting the entropy from the keys being hit or the timing between when the keys get hit? +00:42 <@nop> both +00:42 <@hezekiah> Oh. OK. :) +00:42 <@hezekiah> I'll just write up some code that prohibits 'char' repeating more than 'm' times in 'x' bytes. :) +00:43 <@nop> yes +00:43 <@nop> thnx +00:43 <@hezekiah> Then for development, we brainstorm. ;-) +00:43 <@nop> yes +00:44 < LeerokOnKnoppix> How 'bout you get entropy from all possible inputs like the microphone, internet, processor speed, temperature, memory usage and speed, and other things? +00:44 < lonelynerd> LeerokOnKnoppix, calm down :P +00:44 <@hezekiah> I refuse to collect entropy from my internet connection; if someone can sniff it, then the quality of my entropy is lowwered. +00:45 <@nop> haha +00:45 < lonelynerd> yeah, and the kernel already does a nice job in gathering entropy. applications shouldn't do it +00:46 <@hezekiah> lonelynerd: That works fine as long as IIP is run on an OS with good kernel random number support. There are OS's that exist that _don't_ have good support! +00:46 < PsionX> like windows +00:46 <@hezekiah> lol +00:46 < lonelynerd> hezekiah, yep +00:46 -!- PsionX is now known as WindowsHater +00:46 < WindowsHater> lol +00:46 < lonelynerd> hezekiah, just use some #ifdef there +00:47 -!- WindowsHater is now known as PsionX +00:47 <@nop> this was discussed earlier +00:47 <@nop> and we will look at it on 1.2 +00:47 <@nop> moving on +00:47 < lonelynerd> ok ok +00:47 <@nop> we'll end up repeating ourselves +00:47 <@nop> a dozen times +00:47 <@nop> before this meeting is over +00:47 <@hezekiah> Yeah. :) +00:47 <@hezekiah> Next item! :) +00:49 <@hezekiah> Uh, nop? Do we have a next item? +00:49 <@hezekiah> Perhaps: "What's on the list until we can release IIP 1.1" +00:50 <@hezekiah> Currently, I have: +00:50 <@hezekiah> 1.) mids adds docs for --randomdialog and --ignoreemptyrandom to isproxy.pod +00:50 <@hezekiah> 2.) nop finishes working on his HTML docs +00:50 <@nop> yeah +00:50 <@hezekiah> 3.) We correct the 'hhhhhhhh' entropy problem by prohibiting a certain number of repeated characters. +00:51 <@hezekiah> Anything else? +00:51 <@nop> right +00:51 <@nop> nope +00:51 <@nop> not that i know of +00:51 <@hezekiah> Well, hopefully all that will be done by next week! :) +00:51 <@hezekiah> (Or earlier!) +00:51 <@nop> yes +00:54 <@hezekiah> So what's next on the agenda? +00:55 <@nop> umm +00:55 <@nop> questions, +00:55 <@hezekiah> lol! +00:55 < LeerokOnKnoppix> Not much, it appears. +00:55 < LeerokOnKnoppix> Will there be socks? +00:55 * PsionX looks at his feet +00:55 < LeerokOnKnoppix> No, I mean the proxy thing. +00:55 <@nop> not in 1.1.0 +00:56 < LeerokOnKnoppix> Hmm. +00:57 < LeerokOnKnoppix> Will there be IP spoofing? +00:57 < lonelynerd> w-what? +00:57 <@nop> umm, not in this lifetime +00:57 < LeerokOnKnoppix> Never mind. +00:57 < LeerokOnKnoppix> I'm just thinking up random questions. +00:58 < lonelynerd> :) +00:58 < LeerokOnKnoppix> Will there be any sort of file-transer? +00:58 < LeerokOnKnoppix> *transfer +00:58 <@nop> not in 1.1 +00:58 < LeerokOnKnoppix> Will there be buddy icons? +00:58 <@hezekiah> LOL +00:59 < PsionX> will someone please shut him up? +00:59 < lonelynerd> LeerokOnKnoppix, you can already transfer files over iip but it's a bit slow +00:59 < LeerokOnKnoppix> I know. +01:01 < LeerokOnKnoppix> Will there be Reversi? +01:01 < PsionX> this guy wants everything and a bag of chips too +01:02 < LeerokOnKnoppix> Indeed. +01:02 <@nop> the best question +01:02 <@nop> will the human race be freed +01:02 <@nop> from oppression +01:02 < LeerokOnKnoppix> With IIP? Certainly! +01:02 <@hezekiah> lol! +01:02 < PsionX> i got a question +01:02 < PsionX> ... can i kick hezy in the butt for no good reson? +01:02 <@nop> sure +01:02 < PsionX> lol +01:03 <@hezekiah> nop: So my work for now is to write up the repeating-character-entropy fix. +01:03 <@nop> yes +01:03 <@nop> oh and change the world in one sitting +01:04 <@hezekiah> lol +01:04 * aum pulls his face out of the other windows +01:04 < LeerokOnKnoppix> Peace in Iraq. +01:04 < aum> hi all +01:04 < LeerokOnKnoppix> Hello. +01:04 <@hezekiah> Oh, boy! I spent TOO LONG going over THAT one! +01:04 <@nop> hi aum +01:04 < PsionX> ... +01:04 < PsionX> ... i got spikeys +01:05 <@hezekiah> Question! +01:05 < PsionX> Answer +01:06 <@hezekiah> After IIP 1.1 is released, are we going to sit down and draw up a nice linear list of what needs to be done to decentralize the ircd server? (For example: does the "core" code need to be completed first?) +01:09 <@nop> yes we will do that +01:09 <@mids> s/1.1/1.1.0/ +01:09 <@hezekiah> lol. OK, mids. :) +01:10 <@hezekiah> mids: Though it should probably be s/1\.1/1.1.0/ just for clarity's sake. ;-) +01:10 <@mids> oops, sorry +01:10 <@hezekiah> lol. :) +01:11 <@hezekiah> Also: +01:11 <@mids> maybe before decentralizing there should be another step +01:11 <@hezekiah> I've seen that there is the capability to make varios crypto cores. +01:11 <@mids> keeping a central irc, but letting the proxy be IRC aware +01:11 <@mids> so it can already handle private conversations +01:11 <@mids> etc +01:14 <@hezekiah> mids: i.e. it interprets /msg and does direct user-to-user encryption? +01:14 <@mids> yes +01:14 <@hezekiah> Well, I don't know how abstract things have to say, but I think it's a good idea until we can get the server decentralized! :) +01:16 <@hezekiah> About the crypto cores: if IIP has several crypto cores (SOCKS, SSL, and custom for example), then what happens when you have a connection between a user and several relays that has different encryption between each link? +01:16 <@mids> you can do what GPG does +01:16 <@mids> require a minimum +01:16 <@mids> and if both parties have better, use that +01:16 <@mids> also look hope SILC does it +01:17 <@mids> bye hezekiah +01:17 < PsionX> LOL dial up +01:17 < PsionX> lol on hezy +01:17 <@mids> ;) +01:17 <@mids> wb +01:17 < hezekiah> Let's say that SOCKS is weaker than SSL (I have no idea if it is.) +01:18 < namless> what about own privat/publick keys that the user can add to (client or to IIP proxy) so he can crypt what he talks to chertain chanels or private querys? (meaning users who downt have the right key on these special chanels or private queries down understant other users and IIP proxy filters this crypted text away) +01:18 < hezekiah> (Sorry about being nocked off the internet folks; my brother probably tried to get on.) +01:18 < namless> down -> dont (dam bad english and typos :( +01:19 <@mids> namless: like the existing blowfish etc encryption for irc clients, but then server side +01:19 <@mids> (psybnc has it too) +01:19 < namless> jep +01:20 < namless> the system vould be build into the IIP proxy so it could be transparent to the client... +01:20 <@mids> another thing that I'd like to see is support for multiple layers on the same 'mixnet' +01:20 < namless> vould-> could +01:20 <@mids> so you can do multiple protocols with the same relays +01:22 < hezekiah> (OK. This is getting annoying.) +01:22 <@mids> probably it is bedtime for you :) +01:23 < hezekiah> Nah. That's not for hours. +01:23 <@mids> so no divine intervention? +01:23 < hezekiah> lol +01:23 < hezekiah> So, mids. From what the logs said (Thank God for logs), you mentioned that we could do as GPG does: require a minimum and use better if we have it. +01:24 <@mids> yeah +01:24 <@mids> probably different systems can be compatible too +01:24 <@mids> like homebrew DH and SSL one +01:24 <@mids> with SSL just beeing faster +01:24 < hezekiah> But all the advantage of one connection type being securer than the other are lost when someone along the long uses something less secure. +01:24 -!- LeerokOnKnoppix is now known as LeerokShovelSno +01:26 < hezekiah> Oops. s/along the long/along the line/ +01:26 < hezekiah> Well, we can worry about that another day. +01:26 <@mids> k +01:26 <@mids> btw, any idea how to do something like <br> in POD format? +01:26 < hezekiah> nop: Sometime we should also work on implementing RKA. :) +01:27 < hezekiah> mids: You know more about POD than I do because I know nothing about POD! :) +01:29 <@nop> well we have RKA working but not as good as we'd like +01:29 <@nop> the GMP stuff will change that +01:29 < hezekiah> mids: "E<escape>" -- a character escape +01:29 < hezekiah> nop: We do? When did that happen? +01:29 <@nop> it's been in +01:30 <@nop> every 52 blocks it changes keys +01:30 < hezekiah> Ah +01:30 < hezekiah> Do you think we might make the key changing a little more random? +01:30 < namless> "everyting should be random"... +01:31 < hezekiah> Like having a random number checked every 10 blocks and a 1 out of 3 chance of the key changing? +01:31 < hezekiah> ... or having an SHA sum of the last 3 plaintext messages checked and a 1 out of 3 chance of the key changing based on that? +01:35 < lonelynerd> hmm +01:35 <@mids> ok, info about --randomdialog and --ignoreemptyrandom added to POD +01:35 < namless> by the way how "similar" is the traffic IIP is making? is there any plans to make this traffic to look as much random it can be? if the "transfer macanism" makes a static mark in the traffic then it can be detected as IIP traffic and can be started to be monitored and well there only the sky is the limit... +01:35 < hezekiah> And committed to HEAD and development? +01:36 <@mids> oops +01:36 * mids does to dev too +01:37 < hezekiah> nop? Are you there? +01:37 <@nop> sorry +01:37 <@nop> what +01:37 <@nop> dude, my brain is gone +01:37 <@nop> can we discuss all this later +01:37 < hezekiah> OK. :) +01:37 < hezekiah> Sorry. :) +01:38 <@mids> ok, lets close +01:38 < hezekiah> (If it makes you feel any better, my brain is going to be gone too after a Physics review and some calcus!) :) +01:38 <@mids> commited to development too +01:38 * hezekiah hands mids the "baff"er +01:38 < hezekiah> OK. Good! :0 +01:38 <@mids> *baff* +01:38 < hezekiah> s/0$/)/ +01:38 < hezekiah> Bye all! :) +01:38 <@mids> cya next week +01:40 < lonelynerd> bye +--- Log closed Wed Feb 19 01:40:48 2003 diff --git a/i2p2www/meetings/logs/31.rst b/i2p2www/meetings/logs/31.rst new file mode 100644 index 00000000..7e3cbcba --- /dev/null +++ b/i2p2www/meetings/logs/31.rst @@ -0,0 +1,9 @@ +I2P dev meeting, February 18, 2003 @ 23:01 UTC +============================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/32.log b/i2p2www/meetings/logs/32.log new file mode 100644 index 00000000..4621af6f --- /dev/null +++ b/i2p2www/meetings/logs/32.log @@ -0,0 +1,298 @@ +--- Log opened Tue Mar 04 23:47:24 2003 +23:47 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +23:47 [Users #iip-dev] +23:47 [ eep] [ jeremiah] [ logger] [ mids] [ nop] [ UserX_] +23:47 -!- Irssi: #iip-dev: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal] +23:47 -!- Irssi: Join to #iip-dev was synced in 2 secs +23:48 < LeerokLacerta> Making history. +23:48 < mrflibble> helooo +23:48 < LeerokLacerta> Hello. +23:52 < nop> hi +23:52 < jeremiah> hi +23:53 < nop> hi +23:53 -!- mode/#iip-dev [+o mids] by Trent +23:53 < LeerokLacerta> Konnichiwa. +23:54 < bpb> konnichiwa +23:58 < nop> hi +23:58 <@mids> Hi hezekiah! +23:58 < hezekiah> Hi. :) +23:58 <@mids> *hedgehog sound* +23:58 < hezekiah> lol +23:58 < hezekiah> *orgle* +23:58 < LeerokLacerta> Hedgehog? +23:58 < hezekiah> (orgle: That's one of the sounds a llama makes.) +23:58 <@mids> LeerokLacerta: relatively large rodents with sharp erectile bristles mingled with the fur +23:59 < hezekiah> Mids got turned into a hedgehog by the entropy bug. +23:59 < hezekiah> I got turned into a llama. +23:59 <@mids> no +23:59 < LeerokLacerta> I know what it is, but why're you making hedgehog noises? +23:59 <@mids> because I reported the logging bug that didnt exist +23:59 < hezekiah> Ah. +23:59 < hezekiah> Well, you had mentioned you were going to turn into a hedgehog when refering to the previous entropy bug. +--- Day changed Wed Mar 05 2003 +00:00 <@mids> that was back then +00:00 <@mids> Tue Mar 4 23:00:03 UTC 2003 +00:00 <@mids> meeting NOW in here +00:00 <@mids> Welcome everybody +00:00 <@mids> this is the 32th IIP meeting +00:00 * LeerokLacerta feels welcomed. +00:00 <@mids> previous one was canceled, because nobody was there +00:00 <@mids> logs are available on http://mids.student.utwente.nl/~mids/iip/ +00:01 <@mids> We got a little agenda: +00:01 <@mids> 1) Welcome +00:01 <@mids> 2) IIP 1.1.0 Release status update +00:01 <@mids> 3) Trent accesslevel for 'voice' +00:01 <@mids> 4) Question round +00:01 <@mids> if you have any questions on the current topic, please ask +00:01 <@mids> otherwise save them for the question round. +00:01 <@mids> . +00:02 * mids moves the agenda pointer to #2 "IIP 1.1.0 Release status update" +00:02 <@mids> well hezekiah, what happened? :) +00:02 < hezekiah> Oh. OK. :) +00:02 < hezekiah> Well, the first entropy bug got fixed. +00:02 < hezekiah> After much banging of heads and exchanging of emails ... +00:03 < hezekiah> ... UserX, nop, and myself managed to work out a fix for it. +00:03 < hezekiah> Now, mids is noticing a NEW problem with the entropy gathering (namely seed.rnd isn't getting saved.) +00:03 < hezekiah> Anyway, I've hunted in the code and posted my discoveries to the iip-dev mailing list. +00:04 <@mids> this thing is another release delayer +00:04 <@mids> hopefully the last one +00:04 < hezekiah> I am now waiting on UserX or nop to tell me what all this means and if I'm missing something (because I think I am. None of it makes any sense.) +00:04 < hezekiah> Hopefully. *orgle* +00:04 <@mids> . +00:04 < hezekiah> . +00:04 <@mids> Any IIP 1.1.0 specific questions? +00:05 < LeerokLacerta> No socks? +00:05 <@mids> no socks +00:05 < hezekiah> No SOCKS. +00:05 < LeerokLacerta> K. +00:05 <@mids> ok +00:05 <@mids> lets move on to #3 "Trent accesslevel for 'voice'" +00:06 <@mids> this is related with the hidden agenda point #2.9 "The #freenet-opn channel" +00:06 <@mids> the official Freenet project channel is on irc.freenode.net +00:06 <@mids> but that is not anonymous +00:06 <@mids> we have a mirror with that channel here +00:06 <@mids> in #freenet-opn +00:07 <@mids> the bot 'eyeKon' tells you everything that happens on the other side +00:07 <@mids> normally this is a one way mirror, but you can say something back with the "!say :text" command +00:07 <@mids> to use this you got to have operator or voice status +00:07 <@mids> if you want to say something, ask an operator to give you voice +00:07 <@mids> , +00:08 < dm> How about if you are identified by Trent you get voice automatically and your name gets prefixed to your messages. If people on the other side have a problem they can send a command to the bot to "ban" a certain anonyname. In which case EyeKon on this side removes voice permanently from that name. +00:08 < LeerokLacerta> Permanently? +00:08 < LeerokLacerta> How 'bout timed ban? +00:08 <@mids> it will get pretty complicated +00:09 <@mids> they have to know how to bot works +00:09 <@mids> while it is intended more as a one-way transparant thing +00:09 -!- hezekiah is now known as nickthief88099 +00:09 <@mids> I have contacted the channelowners of #freenet +00:09 <@mids> and they didnt have a problem with it +00:09 < dm> sure, until mids or someone restores it. Must make sure not to spam/bother people on the other side. +00:09 <@mids> that is why not everybody will get voice +00:09 <@mids> it is VERY easy to create lot of accounts here +00:10 <@mids> so it will be impossible to ban them all +00:10 < dm> ok, so selective voice, through trent? +00:10 <@mids> what I DO want to do is selective voice through Trent +00:10 < jake> this sure is an interesting conversation but I need to eat buh bye +00:10 <@mids> which is agenda item #3 +00:10 <@mids> bye jake, thanks for joining +00:10 <@mids> be sure to read the logfile afterwards +00:10 < jake> thank you +00:10 < jake> k +00:10 <@mids> Right now the channel access system has 3 levels: +00:11 <@mids> level 1: operator +00:11 * mids checks the site how he called it +00:12 <@mids> Level 1: Normal operator, can give him/herself ops +00:12 <@mids> Level 2: Super operator, can add other users to the channel (with lower level) +00:12 <@mids> Level 3: Founder, most powerfull, required to drop a channel for example +00:12 <@mids> I want to add a voice level +00:12 <@mids> so people can get voice on the channel if they are on the access list +00:12 <@mids> but the problem is... what number should the voice level be? +00:12 < hezekiah> lol +00:13 < hezekiah> Tell me you didn't use magic numbers, mids. +00:13 < hezekiah> Please. +00:13 <@mids> I am thinking about changing level 1 into 10 +00:13 <@mids> and 2 into 20 +00:13 <@mids> and 3 into 30 +00:13 <@mids> and adding level 5 as voice +00:13 < hezekiah> Sounds good. It leaves room for further improvements. +00:13 <@mids> exactly +00:14 <@mids> note that I dont plan to make Trent a big & bloaty service +00:14 <@mids> comments? objections? +00:14 <@mids> . +00:14 < hezekiah> Umm .. so what's the problem? +00:15 <@mids> there is no problem +00:15 < dm> voice = voice on all channels? +00:15 < hezekiah> OK. +00:15 < hezekiah> It sorta looked like that. :) +00:15 <@mids> dm: no, it is channel specific +00:15 <@mids> hezekiah: I am always dramatic +00:15 < dm> ok +00:15 <@mids> dm: try this: +00:15 <@mids> /squery trent chanlist #iip-dev +00:15 <@mids> you'll get a list of the users on the access list +00:15 <@mids> with the level +00:15 < dm> ah, nice +00:16 <@mids> ok +00:17 <@mids> then it is now time for the last item #4: "Question Round" +00:17 < dm> is there a roadmap documented anywhere, for IIP? +00:18 <@mids> only internally I think +00:18 <@mids> I dont have it... +00:18 <@mids> hezekiah? +00:18 < hezekiah> And why does "/squery Trent :chanlist #anonymous" return a blank list. +00:18 < hezekiah> Oh. +00:18 < hezekiah> Well we have a small todo list of stuff we need to do in the development tree. +00:18 <@mids> hezekiah: too late (because nobody is on the access list for #anonymous, it is oper-less) +00:18 < hezekiah> I'm not aware of any roadmap though. +00:19 <@mids> maybe it would be good to make one +00:19 < dm> ok, you're not even thinking about decentralizing any time soon, correct? +00:19 < hezekiah> Well, that would be nop's department. +00:19 < hezekiah> (Actually, I've already asked for something like that.) +00:20 < hezekiah> (He said we were going to sit down and map out [or whatever he said] IIP 1.2 after 1.1 is released.) +00:20 < hezekiah> . +00:21 <@mids> well +00:21 < dm> 1.1 is there a changelog somewhere? +00:21 <@mids> nop is very busy +00:21 <@mids> maybe someone else should do it +00:21 <@mids> dm: yes, hang on +00:21 < hezekiah> mids: No one else has the authority to do it. +00:21 <@mids> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/invisibleip/iip/CHANGELOG +00:21 < hezekiah> We are talking about setting the future course of development for IIP. +00:21 < dm> thanks, bookmarked +00:22 <@mids> hezekiah: understood +00:25 * mids just heared that they got plenty of things to do for 1.2 +00:25 < hezekiah> As for nop not having time, ... +00:25 < hezekiah> We still have plenty of known coding to do on 1.2. +00:26 < hezekiah> 1.2 will not die for lack of vision. And even if we finish the stuff currently on the list, a short discussion will come up with more. +00:26 < hezekiah> Eventually nop will have time to sit down with us and describe a plan for development of 1.2. +00:26 < dm> any general notes on what 1.2 is striving for? +00:26 < hezekiah> The big one: decentralize the ircd server! +00:26 < dm> ah, ok, you don't know. +00:27 < dm> ah, that's in 1.2? sweet. +00:27 <@mids> is it already? +00:27 <@mids> omg +00:27 < hezekiah> Is the decentralization ready? No! +00:27 < dm> planned for I mean :p +00:27 * mids objects! +00:27 <@mids> when do you want to release 1.2? +00:27 <@mids> 2010? +00:27 * LeerokLacerta is an object. +00:27 < hezekiah> lol +00:28 < hezekiah> Let's just say sometime after 1.1 is released. :) +00:28 < hezekiah> Right now 1.1 is the priority. +00:28 < hezekiah> (At least that's the feeling I've gotten.) +00:28 < dm> so you is it going to be distributed ircd servers or completely decentralized? +00:28 < hezekiah> dm: I don't know the details. +00:28 < dm> ok +00:28 < hezekiah> I'm not really very good at P2P stuff. :) +00:28 < hezekiah> I just code +00:28 <@mids> let me paste an email from 2002-03-19 +00:28 <@mids> From: 0x90 (0x90@invisiblenet.net) +00:28 <@mids> Date: Tue Mar 19 2002 - 00:22:26 CET +00:28 <@mids> Subject: [iip-dev] 1.1.0 almost complete +00:28 <@mids> Ok, we're nearing the completion of 1.1.0. As soon as the TODO/Fixes and cui +00:28 <@mids> for linux are complete, we should run a beta test of the network for this +00:28 <@mids> week, this is done by the developers/testers. Stay posted. +00:29 <@mids> --0x90-- +00:29 <@mids> . +00:29 < hezekiah> Ouch. +00:29 < hezekiah> That hurt, mids. ;-) +00:29 <@mids> yes it did +00:29 < hezekiah> What date was the last release of IIP made? +00:30 <@mids> RC3 was 2002-12-04 +00:30 <@mids> but ofcourse the whole 'RC' stuff was wrong +00:31 <@mids> ofcourse it is just a name +00:31 <@mids> RC2 could have been 1.1.0 +00:31 <@mids> then RC3 1.1.1 +00:31 <@mids> and what we will have now 1.1.2 +00:32 < nop> well +00:32 < nop> in the crypto community +00:32 < nop> we should continue with RC4, 5 and 6, and see if they crack it +00:32 < nop> ;) +00:32 < nop> bad joke +00:33 < Nostradumbass> Excuse me for butting in... +00:33 < jake> butts! +00:33 < Nostradumbass> but it seems that iip developers have forgotten the prime mazimum of open source, "Release early, release often". +00:34 < LeerokLacerta> IIP is open source? +00:34 < nop> sure +00:34 < nop> right +00:34 < nop> but +00:34 < hezekiah> LeerokLacerta: yes +00:34 < LeerokLacerta> I'm dumb. +00:34 < nop> we also value security +00:34 < Nostradumbass> i haven't been around on iip too long but i can't recall ever hearing about it being /.'d +00:35 < nop> and we like to bend the rules +00:35 < nop> it's been slashdotted +00:35 < Nostradumbass> apologies +00:35 <@mids> RC2 was /.-ed +00:35 < Nostradumbass> k +00:35 <@mids> and it gave us... hezekiah ! +00:35 < nop> yes +00:35 < nop> ;) +00:35 < Nostradumbass> still that's quite a while back. +00:35 < hezekiah> mids: actually no. +00:36 < hezekiah> mids: I was watching this project for more than a year before the /.ing. +00:36 < jake> um guys? about the web based IIP are there any plans for improvement? like a nicer interface? +00:36 < nop> that's a distributedcity question +00:36 < nop> they make the interface +00:36 < jake> oooo k +00:37 < nop> it was something that they did, not really direct involvement with us +00:37 <@mids> doing releases gives publication +00:37 <@mids> you can do announcements, press releases +00:37 <@mids> we have multiple places that really like to hear about updates +00:38 <@mids> it increases the interest and amount of users in the project +00:38 <@mids> and also potential contributors / developers +00:38 <@mids> IF you have some super-duper mixnet +00:38 <@mids> you do need lots of users +00:38 <@mids> because with 2 users it isnt anonymous +00:39 <@mids> there have been more stable periods in the development code +00:39 <@mids> at which point we could have made a release +00:39 <@mids> IMHO +00:39 <@mids> problem is maybe the dependencies... +00:40 <@mids> PGP signing the release, compiling for windows, etc +00:40 <@mids> anyway, I have said it before ;) +00:42 < hezekiah> Well, between my being sporadically bumped from the network, I've tried to say something that didn't get said. ;-) +00:42 < hezekiah> <hezekiah> nop: mids has raised some good points. +00:42 < hezekiah> <hezekiah> nop: After we get 1.1 out the door (which should be _really_ soon), are we going to come up with a nice coherent plan for 1.2 so that we can get it out in a reasonable amount of time? +00:42 < hezekiah> <hezekiah> I think with good planning, and goals to get certain parts done by certain times, we could still write great code, but get it done in a reasonable timeframe. :) +00:42 < hezekiah> There! :) +00:42 <@mids> thanks +00:43 < Nostradumbass> in addition to the proposed feature list, perhaps a list of prohibited features (to limit feature creep) might be a good idea. +00:43 < dm> 1.2! 1.2! 1.2! 1.2! +00:44 <@mids> good suggestion Nostradumbass +00:44 < hezekiah> Well, I wasn't really refering to a feature list. I was refering to what we are going to code, in what order, and by what suggested time. +00:45 < hezekiah> nop? What do you think? +00:46 < nop> good idea +00:46 < nop> organization is always good +00:46 < nop> but not always perfect +00:46 < hezekiah> Perhaps after we release 1.1, all the developers could sit down and we could make up a list of stuff we plan on doing in the next 1-2 months, then a list of stuff planned for the next 5 months, then with a full list of what will make IIP 1.2 to be version 1.2. :) +00:46 < hezekiah> I know. It will be _very_ flexable. +00:47 < hezekiah> (For starters I wouldn't say feature A is one at date 1 and feature B is done at date 2. I'd say feature A is hopefully done in X weeks, and feature B is hopefully done Y weeks after feature A.) +00:47 < hezekiah> I think that something as a general guide to what we're doing is a good idea. +00:48 < hezekiah> Not a stiff-as-iron list. :) +00:48 <@mids> yeah, get it +00:48 < hezekiah> OK ... +00:48 < hezekiah> Anything to add mids? +00:49 <@mids> nope +00:49 < hezekiah> OK. ;) +00:49 < hezekiah> So for now ... +00:49 < hezekiah> I am waiting for nop or UserX to enlighten me concerning the stuff I dug up on mids' new entropy bug. +00:49 <@mids> I hope that I wont find other issues +00:49 < hezekiah> (It just doesn't seem like randomWriteSeed() is never called.) +00:49 < hezekiah> Let's hope. :) +00:50 < nop> double negative +00:50 < nop> hmm +00:50 < nop> ;) +00:50 <@mids> . +00:50 <@mids> I am done :) +00:50 < hezekiah> You're right! :) +00:50 < hezekiah> It seems like randomWriteSeed() should be called. +00:50 < hezekiah> But it doesn't look like it is. +00:51 <@mids> not in randomSlowPoolReseed? +00:52 < hezekiah> Well, lets hope we have this bug fixed by next week. +00:52 <@mids> you better do that! +00:52 * mids tries to put up an angry face +00:53 <@mids> ok, been a pleasure again. till next meeting, mailinglist, chat or otherwise! +00:53 <@mids> *boink* +00:53 < hezekiah> randomSlowPoolReseed() calls randomWriteSeed(), but (as I said in my email to iip-dev), randomSlowPoolReseed() is never called by anyone! +00:53 < hezekiah> lol +-- Log closed Wed Mar 05 23:42:43 2003 diff --git a/i2p2www/meetings/logs/32.rst b/i2p2www/meetings/logs/32.rst new file mode 100644 index 00000000..b38404a7 --- /dev/null +++ b/i2p2www/meetings/logs/32.rst @@ -0,0 +1,9 @@ +I2P dev meeting, March 4, 2003 @ 23:00 UTC +========================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/33.log b/i2p2www/meetings/logs/33.log new file mode 100644 index 00000000..b9c7e1ac --- /dev/null +++ b/i2p2www/meetings/logs/33.log @@ -0,0 +1,417 @@ +--- Log opened Wed Mar 12 00:01:53 2003 +00:01 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +00:01 [Users #iip-dev] +00:01 [@mids ] [ jeremiah] [ mihi] [ pox ] +00:01 [ hezekiah] [ logger ] [ nop ] [ UserX] +00:01 -!- Irssi: #iip-dev: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal] +00:02 -!- Irssi: Join to #iip-dev was synced in 7 secs +00:02 <@mids> Welcome to the 33th meeting +00:02 < hezekiah> Hi +00:03 <@mids> IIP 1.1.0 is released yesterday +00:03 < toni> is it okay, to simply idle here and eve's drop? +00:03 <@mids> toni: yes +00:03 <@mids> Agenda for this meeting: +00:03 <@mids> 1) IIP 1.1.0 +00:03 <@mids> 2) Future of IIP +00:03 <@mids> 3) Questions +00:04 <@mids> if you have questions about the current subject, please ask +00:04 <@mids> otherwise save it for round 3 +00:04 <@mids> . +00:04 < nop> hi +00:04 <@mids> logs are available on http://mids.student.utwente.nl/~mids/iip/ +00:04 < hezekiah> hi! :) +00:04 < luckypunk> Hi. +00:04 <@mids> . +00:04 < jrand0m> ev'nin +00:05 <@mids> 1) IIP 1.1.0 (stable) Released!!! +00:05 < hezekiah> YAY! +00:05 <@mids> Finally +00:05 < luckypunk> :) +00:05 <@mids> almost a year after nop's post that it would be out soon :) +00:05 < FillaMent> w3rd i$ b0nd +00:05 <@mids> In this version the installation for Unix is enhanced, entropy generation is improved and a few bugs are fixed. +00:05 <@mids> We call it a stable release +00:05 < hezekiah> mids: Is that list of changes as compared to 1.1.0 RC3 or compared to 1.0.0? +00:05 <@mids> and it looks stable so far +00:06 <@mids> hezekiah: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/invisibleip/iip/CHANGELOG +00:06 <@mids> thats all I know +00:06 < hezekiah> OK. :) +00:06 < hezekiah> (It sorta sounds like it is a comparison to 1.1.0 RC3 or RC2.) +00:07 <@mids> hezekiah: it does, because nobody wrote what was updated before +00:07 < dm> Should I download the Service Pack 2 for IIP if I'm using a cracked version of IIP? +00:07 < hezekiah> mids: Ah ... Therein lies the tale! ;-) +00:07 < dm> sorry, carry on. +00:07 < hezekiah> dm: I'm not aware of any service packs. +00:07 <@mids> the release is announced on our website, freshmeat, infoanarchy and frost +00:08 <@mids> I did email a few other sites that had it listed +00:08 <@mids> if you guys/girls know other places to tell... +00:08 <@mids> please do so +00:08 < jrand0m> nsa? +00:08 < toni> i know, but im a total stranger to iip *g* +00:08 < FillaMent> kuro5hin? +00:08 < hezekiah> mids: Did you email that program archive that hosts it that was recently mentioned on iip-dev? +00:08 < toni> heise.de german security/internet related site +00:08 < FillaMent> jinx.biz +00:09 <@mids> hezekiah: I did mail vipul's munitions +00:09 < hezekiah> mids: OK! :) +00:09 <@mids> kuro5hin requires a decent article +00:09 <@mids> and they are very picky +00:09 <@mids> but if you want to write something... +00:09 <@mids> please do so +00:09 < hezekiah> slashdot again? +00:09 <@mids> toni: could you inform them? +00:09 < hezekiah> They don't require anything super decent, and they mentioned us before. ;-) +00:10 < toni> they also require articles, and i dont know how picky they are +00:10 < toni> if somebody writes an article, i could translate it to german and email them +00:10 <@mids> you could use the press release on http://www.infoanarchy.org/story/2003/3/10/23466/2065 +00:11 <@mids> and link the CHANGELOG to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/invisibleip/iip/CHANGELOG +00:11 <@mids> be sure to include a general description of IIP +00:11 <@mids> I think we should try to do /. +00:12 <@mids> we survived it before +00:12 < hezekiah> mids: Note: You mention to view the changelog in the infoanarchy article, but you don't appear to provide people with a link to it! +00:12 < toni> since im not really familiar with iip, i guess i can't give a decent description, but if you /. it, i could give heise a hint, they often take news from there and translate them +00:12 <@mids> hezekiah: yes, I forgot. +00:12 <@mids> I'll mail their editor +00:15 < hezekiah> OK ... anything else on agenda item 1 (IIP 1.1 release) ? +00:17 <@mids> did you all already submit a newsstory to /.? +00:17 < hezekiah> No. +00:18 < hezekiah> I haven't been with the project quite long enough to have a firm grasp of what has happened since 1.0. +00:18 < hezekiah> Who wrote the last /. post? +00:18 <@mids> we dont know +00:18 < hezekiah> LOL! +00:18 < jrand0m> hahah +00:18 < dm> I think it might have been no_nick +00:18 < mihi> is iip too anonymous? ;-) +00:19 <@mids> yes :) +00:19 < hezekiah> Well, I'll go hunt up the previous post, and see if I can come up with something. :) +00:19 <@mids> ok... +00:19 <@mids> previous one was a copy of the kuro5hin article +00:19 <@mids> which was about nop's interview +00:19 <@mids> ok +00:19 <@mids> Item 2?? +00:19 < hezekiah> Yay! :) +00:20 <@mids> 2) Future of IIP +00:20 <@mids> we want: +00:20 <@mids> DECENTRALIZATION +00:20 <@mids> but who is going to do it +00:20 <@mids> and how +00:21 < dm> and is it possible. +00:21 < jrand0m> and what will be lost. +00:21 < hezekiah> If I may interupt: I just want to make sure nop and UserX and present and accounted for. This conversation will be pretty futile without them. :) +00:21 < jrand0m> (aka centralized authentication - trent) +00:21 < hezekiah> nop? +00:21 < hezekiah> UserX? +00:21 <@mids> hezekiah? +00:21 < hezekiah> Are you present? +00:21 < hezekiah> mids: Here! +00:21 < nop> I'm somewhat present +00:22 < hezekiah> OK. :) +00:22 < nop> userx and I have had discussions +00:22 < nop> on how we would like to do it +00:23 < hezekiah> Did those get discussions written up in papers and stuck in the research directory of the IIP website? +00:23 < nop> ues +00:23 < nop> most are there +00:23 < nop> userx has more +00:23 < nop> that I would like pu t there +00:23 < nop> http://www.invisiblenet.net/research/IIP-WP-Notes.txt +00:23 < hezekiah> OK. Could you please give the filenames of the most relavent ones so I can give them a look? :) +00:23 < nop> that one contains quite a bit +00:24 < nop> there is also some other's contributed +00:24 < nop> IIP_netproto.html +00:24 < nop> and architecture.pdf +00:24 < hezekiah> OK. :) +00:24 < nop> +00:25 < nop> http://www.invisiblenet.net/research/IIP-Identity.txt +00:25 < nop> as well +00:25 < nop> http://www.invisiblenet.net/research/IIP-Messages.txt +00:27 < hezekiah> OK. Are any of them completely (or primarily) devoted to just the decentralization aspect? +00:27 < nop> yes +00:27 < nop> all of them +00:27 < hezekiah> OK. :) +00:27 < hezekiah> Thanks for all the links! I'm checking them out now. :) +00:31 <@mids> ok +00:31 <@mids> other IIP Future events? +00:31 < dm> is FillaMent here? +00:31 < hezekiah> Well, in the near future, IIP-dev still doesn't have the "entropy problem" fixed. +00:31 < dm> he had the idea of making trent allow PGP key exchanges +00:31 < dm> which makes sense. +00:31 * FillaMent is present +00:32 <@mids> yes FillaMent and me did talk about that +00:32 * mids hands the microphone to FillaMent +00:32 * FillaMent taps it a couple times, "this thing on?" (sorry) +00:33 * hezekiah turns up the volume +00:33 < lonelynerd> :) +00:33 < FillaMent> Here's the deal: I think it'd be handy to have a PGP key storage and exchange mechanism on IIP. I have a few proposals as to how such a thing should work. +00:34 < dm> Should be fairly easy? Just add a field for PGP to trent, and add GET/STORE commands? +00:34 < FillaMent> 1) Capability is built into trent. This presents a problem with most IRC clients sending strings that long +00:35 < dm> ah, ok. +00:35 < FillaMent> 2) Make trent able to pull a CHK from freenet and store the contents of that file as the Key +00:35 < FillaMent> 3) Build a separate bot to preform 1 or 2 +00:35 < nop> hmm +00:35 <@mids> good points +00:35 < nop> the only issue +00:35 < nop> I have +00:35 < nop> with this concept +00:35 < nop> is how do we trust trent or any bot for that matter to handle pub keys +00:35 < nop> without verification +00:36 <@mids> well +00:36 < FillaMent> Well, it could check and make sure the nick was reg'd and ident'd +00:36 <@mids> it could be just as a keyserver +00:36 < nop> the idea I'm thinking +00:36 < nop> is it can do a verify to all major key servers +00:36 < nop> as well +00:36 < nop> so that it gets congruent info +00:36 < FillaMent> nop: read my flog entry about psuedoidentity? +00:36 < nop> link +00:37 < FillaMent> SSK@WxBcPJd1ppZSZ~C8IJI-DHx94oIPAgM/fillament// +00:37 <@mids> keyservers dont verify anything +00:37 <@mids> they just store stuff +00:37 <@mids> what you can do now with Trent +00:37 < FillaMent> here's the short of it... what if your identity only exists in anonymous space? What can you verify? +00:37 <@mids> /squery trent nickinfo mids +00:38 <@mids> see the comment line +00:38 <@mids> it can contain anything +00:38 <@mids> also urls etc +00:38 < FillaMent> but short +00:38 <@mids> so you could link to your PGP key +00:39 < FillaMent> I'm just thinking of something to remove all the middle steps. +00:39 < hezekiah> Looking at mids' ID comment, I see it lists a key fingerprint +00:39 < hezekiah> It also lists the key ID. Why can't someone just get the key from a keyserver, and check the fingerprint. +00:39 < FillaMent> hezekiah: What key server? +00:39 < FillaMent> one on the internet? +00:39 < nop> that's what I'm saying +00:40 < mihi> how get a key up to a key server? anonymously? +00:40 < lonelynerd> we just need a bot to fetch those +00:40 < FillaMent> if your identity only exists in anonymous space, like mine... I don't want to leave a trail on the internet +00:40 < hezekiah> Ah ... +00:40 < hezekiah> OK. I get it. :) +00:40 <@mids> so a keyserver bot for IIP would be it +00:40 <@mids> combined with freenet +00:40 < FillaMent> that'd be sweet... just feed trent the fingerprint and it'll try to fetch the key... +00:41 <@mids> currently freenet is too heavy to run on the Trent server +00:41 < lonelynerd> mids, well, you could ascii armor the public keys +00:41 < FillaMent> mids: Such a thing need not be built into trent, as my point 3 +00:41 < nop> well +00:41 < nop> you could use a gateway mids +00:41 < nop> like groovy +00:41 <@mids> too unreliable +00:42 < someone> why do you need freenet, again? +00:42 < FillaMent> mids: If you wanted to make trent capable, just have it access one of the public freenet servers +00:42 <@mids> why not let a user upload the key to freenet and give the url to the bot? +00:42 <@mids> someone: for file storage +00:42 < FillaMent> mids: Because it a few days it's gone if no one accesses it. +00:42 < lonelynerd> mids, wouldn't it be more efficient to have a one huge digest of public keys used by people? +00:43 < hezekiah> lonelynerd, mids: You could just add a the capability to assign PGP key ID's to a nick just like you can assign a comment. +00:43 < FillaMent> I think the best solution is to have it not integrated into IIP. Someone writes it as a piece of software (hell, I could do it but am busy) then distribute the software. Anyone who wants to run an IIP keyserver, can. +00:44 < lonelynerd> hezekiah, true, but you still need to fetch the pgp key +00:44 < nop> ok here's the funny thing +00:44 < lonelynerd> FillaMent, sounds reasonable +00:44 < nop> things we can see +00:44 < nop> we trust +00:44 < nop> like the internet +00:44 < nop> yet it's insecure +00:44 < someone> why not just have a bot upload nad download keys from internet key servers and store a fingerprint with trent +00:44 < nop> yet we have a cryptographic network +00:44 < nop> and we don't trust a soul to run a pgp keyserver +00:44 < lonelynerd> someone, that's what i suggested +00:44 < hezekiah> nop: lol! :) +00:45 < lonelynerd> nop :) +00:45 <@mids> nop +00:45 <@mids> you dont get it +00:45 < nop> I do get it +00:45 <@mids> you DONT need trust for a keyserver +00:45 < nop> I'm joking +00:45 < FillaMent> nop: Sure you do... one just has to put their pseudoidentity on line. +00:45 < FillaMent> on the line +00:45 < FillaMent> mids: Sure you do +00:45 <@mids> it is just for storage +00:45 < nop> I know mids +00:45 < nop> I was just being funny +00:45 < nop> ;) +00:45 <@mids> users should ALWAYS verify fingerprint +00:45 < someone> lonelynerd: so we don't need freenet, right? +00:45 <@mids> and check web of trust +00:45 < FillaMent> mids: I could just stick my key there and say it's nop's. +00:46 <@mids> nop: good if you are funny :) but others might not understand it +00:46 < lonelynerd> FillaMent, actually, what you wrote about pseudoidentity got me thinking. i'm wasting time and resources by having two identities on iip, one for people who know me irl and then this. +00:46 <@mids> FillaMent: thats why you can stick the fingerprint on Trent +00:46 < lonelynerd> someone, exactly, freenet is cool, but not needed this time +00:46 <@mids> (you'll have to trust trent though +00:46 < FillaMent> mids: Yes... and /how/ many people know about key fingerprints? +00:47 < lonelynerd> someone, but somebody could still post compressed digests contain many keys +00:47 <@mids> if they dont know, they shouldnt use PGP +00:47 < FillaMent> mids: yeah.. let's alienate the userbase +00:47 < lonelynerd> true +00:47 < lonelynerd> :) +00:47 <@mids> no seriously +00:47 < FillaMent> I've already had this discussion 20x with zab +00:47 < hezekiah> FillaMent: if they don't know enough about key fingerprints, then they probably don't know enough about crypto for me to trust that they haven't given away their key! +00:47 <@mids> using PGP without checking fingerprints gives a false sense of security +00:48 < FillaMent> hezekiah: And how do you sort those people out? +00:49 < lonelynerd> FillaMent, that's tricky. far too many users use pgp insecurely +00:49 < hezekiah> FillaMent: Tis the billion dollar question! That is very hard. :) +00:49 < FillaMent> If you tell people that they're too stupid to use crypto, they won't want to. They'll say, 'fuck it... I don't have time to care about privacy'... they may be sheep, but there are more of them voting than us. We have to make it easy for the sheep. +00:50 <@mids> you can try to educate them +00:50 < FillaMent> You have to get them in the classroom, and IIP/Fnet is the best classroom I know of +00:50 < hezekiah> Correct, mids. Security is only as strong as the intelligence of the person behind it. +00:50 <@mids> I totally agree FillaMent +00:51 < FillaMent> such a key storage bot would have a motd explaining that they should be checking fingerprints +00:51 <@mids> I just think that you should seperate keyserver from trust +00:51 < hezekiah> So what are we going to do with this bot and IIP? What do we want it to do, and how? +00:51 < FillaMent> I think it should be a 3rd party thing +00:52 < hezekiah> Like anonymail? +00:52 < FillaMent> no... like something that anyone can run +00:52 <@mids> anybody can run anonymail +00:52 <@mids> IF you would have the source +00:52 <@mids> :) +00:52 < FillaMent> mids: You know what I mean though +00:53 <@mids> yes +00:53 <@mids> sorry +00:53 < hezekiah> So is this something, the IIP developers need to write, or can someone who knows nothing about IIP but basic IRC can write? +00:53 * FillaMent already has a framework going +00:53 < hezekiah> OK! :) +00:54 < FillaMent> well... I'd have to hack it to change it's direction +00:54 < FillaMent> GAH!!!!!! More projects!!!! Nooooooo! +00:54 < jrand0m> give in FillaMent, just give in +00:54 < FillaMent> jrand0m: I know... I know. +00:54 < hezekiah> Basically what I'm asking is, is this something that needs to get built into IIP, or can it be independant? +00:55 < FillaMent> independent +00:55 < hezekiah> If it's independant, then I'd say, "GO FOR IT!" :) +00:55 <@mids> hezekiah: IndependEnt +00:55 * mids ducks +00:55 < hezekiah> mids: really? +00:55 <@mids> yes +00:55 * FillaMent thinks he's missing a joke. +00:56 < hezekiah> My spell checker says independant is OK. +00:56 <@mids> hezekiah: made a typo +00:56 < FillaMent> oh... yeah... +00:56 < FillaMent> dent +00:56 < FillaMent> independEnce +00:56 < hezekiah> Hmmm ... it says independent is OK too, odd. +00:56 <@mids> hezekiah: grep "^independ.nt$" /usr/share/dict/words +00:56 < FillaMent> probably a new english/old english thing +00:56 <@mids> anyway +00:56 < hezekiah> Anyway ... :) +00:57 <@mids> say we have this keybot +00:57 < hezekiah> And it will be independent of IIP. :) +00:57 <@mids> how will it get the key from a user? +00:57 < FillaMent> /msg +00:57 <@mids> the full key? +00:57 < FillaMent> no +00:57 < FillaMent> freenet +00:57 <@mids> ah +00:58 <@mids> so you msg the freenet url +00:58 <@mids> and it tries to download in the background +00:58 < lonelynerd> what's the problem? you can easily paste full key to iip. +00:58 < FillaMent> /msg Keybot STORE CHK@lakdjfa;lsdfjasd;lkfj +00:58 <@mids> lonelynerd: my key is 8 KB big +00:58 < FillaMent> lonelynerd: Not will all clients +00:58 < mihi> FillaMent: you can if you do it in blocks of 10 lines. +00:59 <@mids> the keyboard _could_ look if you are identified with trent +00:59 <@mids> keybot +00:59 <@mids> :) +00:59 < FillaMent> mids: It would have to +00:59 <@mids> and just add that as an additional flag +01:00 < FillaMent> /msg keybot MSGSTORE ad;flkjsflkjsdf;lasdrkfj +01:00 < FillaMent> /msg keybot MSGSTORE ad;flkjsflkjsdf;lasdrkfj +01:00 < FillaMent> /msg keybot MSGSTORE ad;flkjsflkjsdf;lasdrkfj +01:00 <@mids> well +01:00 < FillaMent> such a thing would best be scripted +01:00 <@mids> yes +01:00 <@mids> exactly +01:00 < jrand0m> is a centralized identity manager like trent really desireable? +01:00 < FillaMent> so either chopped and sent via msg or via freenet +01:00 <@mids> jrand0m: with a centralized ircd, yes +01:00 <@mids> maybe we should form a keybot commitee +01:01 <@mids> and let them discuss the details +01:01 < jrand0m> ah, right. yeah, I was assuming a decentralized net. +01:01 * mids opens #keybot +01:01 < FillaMent> mids: I don't see a need +01:01 <@mids> well +01:01 <@mids> we got more on the agenda +01:01 < lonelynerd> mids, uhm. +01:01 <@mids> and we are already busy for 1 hour +01:01 < FillaMent> 20 people start keybots... 1 will eventually prove the most reliable and become the defacto standard +01:02 <@mids> I mean more.. any other Future IIP things? +01:02 < hezekiah> nop? +01:02 < hezekiah> What are the major features/changes you plan for 1.2? +01:02 < nop> what +01:02 < nop> decentralization +01:02 < nop> and channel encryption +01:02 < nop> as well as client to client encryption +01:02 < nop> channel trust +01:02 < nop> using RSA keyring +01:02 < Debolaz> I have a question. What is the thing needed most from IIP now, that an ISP would be able to provide? +01:03 <@mids> money! +01:03 <@mids> millions +01:03 <@mids> so we can hire thousands of developers +01:03 < Debolaz> I was thinking more in terms of services. +01:04 < jrand0m> OC12? +01:04 <@mids> hosting is fine at sf so far +01:04 <@mids> maybe a stable node somewhere +01:05 <@mids> ... +01:05 < Debolaz> Well, I was thinking of a node sort of thing. And perhaps a file mirror. +01:05 <@mids> project release files are already mirrored on 8 servers so far +01:06 <@mids> plus on vipul's munitions +01:07 * mids slowly pushes the topic to item 3, questions +01:07 < hezekiah> Ack! +01:07 <@mids> 3) Questions? +01:08 < jrand0m> eta for decentralization (1 mo, 3 mo, 6 mo)? +01:08 < jrand0m> aka, without dependence on a central server +01:08 <@mids> no comment! +01:08 < hezekiah> mids: LOL! +01:08 < hezekiah> I really have no idea. UserX would probably have the best bet +01:09 < hezekiah> nop, UserX: are we done decentralizing "core" in isproxy yet? +01:09 < nop> um no +01:11 < hezekiah> I'm assuming that "core" comes before ircd decent., right? +01:12 < nop> first +01:12 < nop> we have to make a virc +01:12 < nop> which is a virtual irc transport +01:12 < nop> so that the irc clients can still talk to the core +01:12 < nop> without ircd +01:13 <@mids> roadmap anybody? +01:13 < hezekiah> lol. I'm clueless. :) +01:16 <@mids> *silence* +01:16 <@mids> I heared that some wanted next meeting to be earlier +01:16 < nop> yes +01:16 * FillaMent rubs his legs together furiously but fails to produce the proper chirp. +01:16 < nop> UserX can't make it at the time we have now +01:16 < nop> because of work +01:16 < hezekiah> Ah. +01:16 < nop> if we had it a couple hours earlier +01:16 <@mids> what time would be better? +01:16 < nop> this would be easier +01:16 <@mids> 21:00 UTC? +01:16 < hezekiah> If UserX would talk more we could really get some stuff done! :) +01:16 < nop> that should work +01:17 < hezekiah> Let's see ... +01:17 < hezekiah> It's normally 23:00 UTC, right? +01:17 <@mids> yes +01:17 < hezekiah> Yeah. +01:17 < hezekiah> That should work for me. :) +01:17 <@mids> 21:00 UTC it is +01:18 <@mids> ok +01:18 <@mids> I am out +01:18 <@mids> thanks for listening to me :) +01:18 * mids bows +01:18 <@mids> oh +01:18 <@mids> before I forget +01:18 <@mids> UserX, nop, hezekiah, thanks for your work on IIP so far! +01:18 < hezekiah> mids: I enjoy listening to you. +01:19 < hezekiah> mids: A pleasure! :) +01:19 < hezekiah> All you guys make it worthwhile! :) +01:19 < jrand0m> yeah, thanks for the updates. I appreciate using y'alls software +01:19 < hezekiah> (Note: I am a Yankee. No offense is meant if there are girls in the channel.) +01:19 * FillaMent curses them for this network that consumes his free time. +01:19 < hezekiah> FillaMent: lol! :) +01:19 < jrand0m> heh +01:20 * hezekiah picks up the "baf"er +01:20 < hezekiah> *BAF!* +01:20 < hezekiah> Meeting adjurned! :) +01:22 < mihi> adjourned, you mean? +01:23 < hezekiah> Over. +01:23 < hezekiah> Done. +01:23 < hezekiah> End. +01:23 < hezekiah> Dead. +01:23 < hezekiah> The meeting is dead. Long live the next meeting. +01:23 < mihi> ;-) logger is still living diff --git a/i2p2www/meetings/logs/33.rst b/i2p2www/meetings/logs/33.rst new file mode 100644 index 00000000..f1b6c7fb --- /dev/null +++ b/i2p2www/meetings/logs/33.rst @@ -0,0 +1,9 @@ +I2P dev meeting, March 12, 2003 +=============================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/34.log b/i2p2www/meetings/logs/34.log new file mode 100644 index 00000000..505df318 --- /dev/null +++ b/i2p2www/meetings/logs/34.log @@ -0,0 +1,127 @@ +--- Log opened Tue Mar 18 20:14:29 2003 +20:15 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +20:15 [Users #iip-dev] +20:15 [ jeremiah] [ logger] [ mids] [ UserX] +20:15 -!- Irssi: #iip-dev: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal] +20:15 -!- Irssi: Join to #iip-dev was synced in 5 secs +20:17 -!- mode/#iip-dev [+o mids] by Trent +22:00 < nop> hi +22:00 <@mids> Tue Mar 18 21:00:10 UTC 2003 +22:00 < hezekiah> Hi. :) +22:00 <@mids> HEllo +22:00 <@mids> so +22:01 <@mids> whats on the agenda? +22:01 < hezekiah> I have no clue. +22:01 < armpit> howdy +22:01 < hezekiah> Hi +22:01 <@mids> ok +22:01 < armpit> mind if i lurk around? :) +22:01 <@mids> then lets just keep a question round +22:01 <@mids> btw, Freenet 0.5.1 is out +22:01 < hezekiah> Cool. :) +22:02 < hezekiah> Maybe one of these days I'll try using it. :) +22:02 <@mids> so, any IIP questions? +22:02 < Hitman> quick run down of current status would be nice nop +22:02 < Hitman> so we can get up to speed on what's happening with it all +22:03 <@mids> good point +22:03 < nop> hold +22:03 * hezekiah turns on beautiful classical music those tech-support hotlines play while we wait for them ... +22:04 * Hitman shudders as teh memories flood back +22:05 * mids runs out of breath +22:06 * mids dies +22:06 < hezekiah> Well, meanwhile I think it should be noted that some people don't appear to have remembered the meeting starts 2 hours earlier now. +22:06 <@mids> or they just dont care :) +22:07 < nop> ok +22:07 < nop> back +22:07 < hezekiah> Yay! :) +22:07 < nop> 1.1.0 is out, 1.2 meeting needs to be set +22:07 < nop> so that hez, Userx and I can discuss furthur major development +22:08 <@mids> maybe the development cycle should be more open? +22:08 <@mids> so others can hear what the plans are too? +22:08 < nop> we will log and place in research directory +22:08 < nop> on invisiblenet +22:08 <@mids> ok +22:08 < Aprogas> that would counter allegations that IIP is vapourware +22:09 < hezekiah> mids: I think openess is great, but it can get pretty annoying when you are trying to discuss coding and the listeners are continueally getting off the subject into theory. :( +22:09 < nop> that's why we log +22:09 < nop> ;) +22:09 < hezekiah> I think the logging is a good idra. +22:09 < nop> and publish +22:09 <@mids> hezekiah: channels can be moderated +22:09 < hezekiah> Maybe we could post the log to the iip-dev mailing list too? That would give people a good idea of what's going on behind the scenes. +22:09 < Hitman> open discussion of ideas and brainstorming would rock, but end product changes will have to be discussed seperately by the actual coding team otherwise thing's won't get implemented correctly +22:09 <@mids> k +22:09 < hezekiah> They could pipe up with all kinds of suggestions then. :) +22:10 < hezekiah> UserX? Are you currently present? +22:10 < UserX> i'm present +22:10 < hezekiah> OK. :) +22:10 < hezekiah> (To both UserX and nop): Do either of you have any times for that meeting that would be good for you? +22:11 < hezekiah> I mentioned the times that won't work for me, in my email. I hope it's a small enough subset not to be a problem. :) +22:12 <@mids> anyway, you can settle that in private +22:12 < Hitman> in my personal opinion I think that decentralisation of the network is the number one priority. To make IIP completely p2p would take away any ability whatsoever the goverment and other nasty forces have to shut it down. While a central server exists tehy can still end it....ie napster +22:12 < hezekiah> OK. +22:12 <@mids> we can read the logs afterwards. +22:13 < hezekiah> Hitman: decentralization is the main theme of 1.2 +22:13 < Hitman> sweet +22:14 < hezekiah> So where were we? +22:15 < hezekiah> Oh, yeah. Nop was listing the current status of 1.2. +22:15 < nop> yeah +22:15 < hezekiah> Did you have anything else to add, nop? +22:15 < nop> so 1.2 we need a dev meeting to start +22:15 < nop> and from that point is our start +22:16 < Aprogas> did you create a branch in CVS so bugs in 1.1 can be fixed without requiring users to update to a alpha or beta state 1.2 ? +22:17 < UserX> The development is already in a seperate branch from 1.1 +22:18 < hezekiah> And the 1.1 release was tagged v1-1-0. +22:18 < Aprogas> so there is a tag on the release, but not a branch tag ? +22:18 < Aprogas> i assume the development is on the `MAIN' branch ? +22:19 < hezekiah> Uh, I currently don't know what CVS commands I should be running to tell the difference. :) +22:19 < UserX> 1.1 is on the MAIN branch +22:19 < Aprogas> something like cvsweb gives more overview of such things than cvs commands anyway; branchs in cvs are quite confusing +22:20 < Aprogas> anyway, having a release on the main branch and the development in a seperate branch is quite an uncommon setup; and that might have reasons +22:20 < Aprogas> maybe it is worth investigating if it would not be more useful to do it the other way around ? +22:25 < hezekiah> Well, I don't know much about CVS so my input wouldn't be much worth here. :) +22:26 < Aprogas> CVS is a scary beast +22:27 < hezekiah> Yeah. I wonder if it ate the other people in the room. It seems deathly quiet in here. +22:27 < Aprogas> i ended up re-importing sources numerous times because i messed up after trying to put my branches right +22:27 < hezekiah> ;-) +22:28 < Aprogas> so be careful with it +22:28 < hezekiah> *lol* +22:29 < hezekiah> Mids? Do we have another item on the agenda? It seems like we're done with this one (or else someone got eaten by the CVS beast.) +22:31 < Aprogas> well.. i didnt really see anyone reacting to my `suggestions' +22:31 < Aprogas> im wondering why the IIP development team uses this different way of using branches +22:31 < hezekiah> I have no clue. +22:31 < Aprogas> i guess 99% of the CVS-using project develop on the MAIN branch and keep releases on seperate branches +22:32 < hezekiah> I do know that it works fine. +22:32 < Aprogas> that will become obvious when you get 1.2 +22:32 < Aprogas> what will happen with 1.1 which s currently on the main branch ? +22:32 < hezekiah> So I say that "If it isn't broken, then don't fix it." +22:32 < hezekiah> It's sources are tagged. +22:33 < Aprogas> a bug in it might be found +22:33 < Aprogas> and you might want to create 1.1.1 +22:33 < hezekiah> I guess that if we need to do a bug fix, then someone checks out v1-1-0, fixes the bug, and commits under the tag v1-1-1. +22:33 <@mids> hezekiah: no, none +22:33 < Aprogas> hezekiah: that is possible too +22:33 < hezekiah> mids: As I said, I don't know much about CVS. :) +22:33 < Aprogas> but using release branches is more common +22:33 < UserX> the developement will probably be merged back on to the main branch. and if we need to do bug fixes/upgrades to 1.1 we just create a branch from it +22:33 < Aprogas> userx: ok +22:33 < hezekiah> Oh, well. I'll leave the CVS playing to the developers that understand it. :) +22:34 < Aprogas> noone understands CVS +22:34 < hezekiah> lol +22:34 < Aprogas> thats the problem +22:34 < Aprogas> its a beast that cannot really be tamed +22:34 < hezekiah> So, mids. What's next on the agenda? Question round? +22:34 <@mids> ok, I am out. cya +22:35 -!- mode/#iip-dev [+o hezekiah] by Trent +22:35 <@hezekiah> OK. The question round has officially begun, I guess. :) +22:35 < Aprogas> oh +22:35 <@hezekiah> Questions? +22:35 <@hezekiah> (Not that I can promise an answer, but you can ask.) +22:37 <@hezekiah> Going once ... +22:37 <@hezekiah> Going twice .. +22:37 <@hezekiah> Gone! +22:38 <@hezekiah> Sold to the eternal silence of the ever questioning public (until the next iip-dev meeting that is.) ;-) +22:38 <@hezekiah> Well, it was nice talking to you all (and nice to be able to have UserX around and talking in an iip-dev meeting. I'm glad the time change has improved things for him.) +22:38 <@hezekiah> Bye, all! :) +22:38 < nop> bye +--- Log closed Tue Mar 18 22:43:48 2003 diff --git a/i2p2www/meetings/logs/34.rst b/i2p2www/meetings/logs/34.rst new file mode 100644 index 00000000..2876ec25 --- /dev/null +++ b/i2p2www/meetings/logs/34.rst @@ -0,0 +1,9 @@ +I2P dev meeting, March 18, 2003 @ 21:00 UTC +=========================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/35.log b/i2p2www/meetings/logs/35.log new file mode 100644 index 00000000..163aaee1 --- /dev/null +++ b/i2p2www/meetings/logs/35.log @@ -0,0 +1,199 @@ +--- Log opened Tue Mar 25 22:07:19 2003 +22:07 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ +22:07 [Users #iip-dev] +22:07 [@hezekiah] [ Aprogas] [ logger] [ mids] [ poX] [ UserX] +22:07 -!- Irssi: #iip-dev: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] +22:07 -!- Irssi: Join to #iip-dev was synced in 3 secs +22:07 < UserX> yes +22:07 <@hezekiah> OK. :) +22:07 < mids> log is up http://mids.student.utwente.nl/~mids/iip/meeting35/livelog.txt +22:07 < Aprogas> /exec -o tail -f http://mids.student.utwente.nl/~mids/iip/meeting35/livelog.txt +22:08 < Aprogas> loops are fun +22:08 < mids> unless anybody has any agenda; +22:08 < mids> I'd like to hear what the official proposals are for the decentralized routing protocol +22:09 < Aprogas> then at least have 1. decentral routing protocl 2. question as agenda +22:09 < mids> 1) welcome +22:09 < mids> 2) decentralized protocol +22:09 < mids> 3) WVTTK +22:09 < mids> 4) questions +22:09 < Aprogas> thats dutch +22:10 < mids> whats the english word for it? +22:10 < Aprogas> 3) WCTTA +22:10 < Aprogas> maybe +22:10 < Aprogas> but latin would be more elite +22:10 < Aprogas> where is the director to tell me to shut up and get back to the point ? +22:10 <@hezekiah> Aprogas: be quite and get back to the point. ;-) +22:10 < mids> quod etcetera mensa venit +22:11 < Aprogas> hezekiah: thanks +22:11 < mids> -1- +22:11 < mids> Welcome everybody! +22:11 <@hezekiah> Hiya! :) +22:11 < mids> as you see, the regular meetings are earlier as the other 33 ones from now on +22:11 < mihi> hi mids +22:11 < mids> . +22:11 < mids> -2- +22:11 < Aprogas> to better fit the mainly US/EU users of IIP ? +22:12 < nop> yo +22:12 < Aprogas> hello nop +22:12 -!- mode/#iip-dev [+o nop] by Trent +22:12 <@nop> got the page +22:12 <@hezekiah> Hiya, nop! :) +22:12 < mids> Aprogas: it would fit better for UserX / nop +22:12 <@nop> is userx alive? +22:12 < Aprogas> dont forget to change your nick to noP +22:12 -!- nop is now known as noP +22:12 < mids> 2) I'd like to hear what the official proposals are for the decentralized routing protocol +22:12 <@noP> thnx aprogas +22:12 <@noP> we have no official proposal till Friday 21:00 +22:12 < UserX> noP: i'm here +22:13 <@noP> that is to be discussed +22:13 <@noP> there are semi-official proposals in www.invisiblenet.net/research +22:13 < Aprogas> can i join that discussion to give totally useless suggestions ? +22:13 <@noP> which are many different proposals +22:13 <@hezekiah> Uh, oh. Looks like I have a lot of reading to do before Friday. ;-) +22:13 <@noP> we will log it +22:13 <@noP> and you can suggest +22:13 <@noP> during iip-dev meeting +22:14 <@noP> yeah hezekiah we added more stuff ;) +22:14 -!- mids changed the topic of #iip-dev to: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ - http://www.invisiblenet.net/research/ +22:14 < mids> ok +22:14 < mids> . +22:14 < mids> quod etcetera mensa venit? +22:14 <@noP> brb +22:14 <@hezekiah> mids: What language is that? +22:15 < mids> latin +22:15 <@hezekiah> Ah. +22:15 < Aprogas> mensam sounds more correct +22:15 < mids> it should mean something like: what else comes to the table +22:15 < Aprogas> and `etcetera' isnt +22:15 < mids> et cetera +22:15 < Aprogas> but that still doesnt make sense +22:16 < mihi> quod ceterum ad mensam venit? +22:16 < Aprogas> maybe +22:16 < Aprogas> when will the IIP sourcecode be translated to latin using latin.h ? +22:16 < mihi> igpay atinlay? ;-) +22:16 < Aprogas> in other words, when will IIP development freeze to transfer those manhours to my latin.h project and complete it, only to then implement it in IIP ? +22:17 <@hezekiah> Never. +22:17 < mids> quod autem ad mensam venit +22:17 < mids> powered by http://www.latijnnederlands.nl/ +22:17 < mids> . +22:17 < Aprogas> thats W Echter TTK +22:17 < mids> any IIP questions? +22:17 < mids> Aprogas: 2. verder, voorts, en dan (ter voortzetting of uitwerking v. iets voorafgaands). +22:17 < mihi> "*but* what comes to the table"? +22:17 < Aprogas> `what' does +22:18 < mids> mihi: questions, proposals, comments +22:18 < mihi> mids, you missed the "" +22:18 < Aprogas> anything that was talked about during the meeting but didnt fit in the point that was currently active +22:18 <@hezekiah> Is this item 3 on the agenda? +22:18 < Aprogas> hezekiah: i think we are at questions yet +22:18 < mids> hezekiah: yes +22:18 < Aprogas> the meeting seems chaotic and without any real content, except that the decision on the routing protocol will be made later +22:19 <@hezekiah> ... because I have no idea what "WVTTK" means and this conversation is definately obscure enough to be a possible candidate. ;-) +22:19 < mids> ok, /me formalizes +22:19 <@hezekiah> Right +22:19 < Aprogas> its probably because i am here +22:19 < mids> and because I had a lot of beer +22:19 < Aprogas> WVTTK in reality is anything that does not make sense +22:19 * mids moves on to point 4 +22:20 < mids> any IIP related questions? +22:20 < Aprogas> how does the IIP team expect the userbase to grow, and when will massive PR start to stimulate more growth ? +22:20 < Aprogas> also, what kind of people does the IIP team expect to attract in the beginning, and with the PR campaign +22:21 < mids> past experience has tought that it is very easy to get on slashdot +22:21 < mids> which results in a quick increase of users +22:21 < mids> but you need Cool Features +22:21 < mids> to excuse an announcement +22:21 < Aprogas> well, most slashdot users dont stay long i think +22:21 < Aprogas> a few of them stay, but most just want to `check it out' +22:21 <@hezekiah> Right. +22:21 <@hezekiah> So once we decentralize we will have something to brag about on /. +22:22 < mids> then we can address some online magazines +22:22 < mids> like theregister +22:22 < mids> and/or wired +22:22 < Aprogas> you need cool features to excuse an announcement, and you need a cool application to keep them +22:22 <@hezekiah> Right. +22:22 < Aprogas> but slashdot is a pretty `limited' target group +22:22 < Aprogas> it only attracts a certain type of people +22:22 < mids> it is a part +22:22 < Aprogas> perhaps some more diversity would be good +22:22 < mids> you could also address some target audiences +22:22 <@hezekiah> I personally don't really care about attracting people. I just want a good program. +22:23 < mids> like writing to the dutch organisation Martijn :) +22:24 < mids> maybe some press release to AA groups, amnesty, EFF, scientology/cult critics +22:24 < mids> hezekiah: even with a good program you require a certain userbase to be able to offer decent traffic +22:25 < mids> you cant have only 2 users on your ultra-anonymous network +22:25 <@hezekiah> The way I look at it, if it's easy enough to find on freashmeat/sourceforge and it offers what people want (good anonymized chat), then people will use it. +22:26 <@hezekiah> Yes. That is a very primitive outlook on userbase growth. +22:26 < Aprogas> the average internet user does not search at sourceforge +22:26 < Aprogas> its hard to search for something if you dont know that it exists +22:26 < mids> hezekiah: freshmeat / sourceforge is only for the geeks +22:26 < mids> they think that anonymity is 'cool' +22:26 < mids> but dont really need it that much +22:26 <@hezekiah> Or they have people they don't want to be looking over their shoulder. :) +22:26 < mids> cause they have nothing to hide :) +22:27 <@hezekiah> But their paranoia helps them set up secure nodes. +22:27 <@hezekiah> I'm not sure I would want my message traffic running through Great Aunt Edna's Windows Me machine. +22:27 < mids> what is the target audience in your oppinion? +22:27 < mids> 16-23 year old linux kiddies? +22:27 <@hezekiah> Well, I really don't care who uses it. +22:28 < mids> or joe sixpack +22:28 <@hezekiah> I would just want the people who make the nodes to make them securely. +22:28 < Aprogas> maybe some lawyers to defend us +22:28 <@hezekiah> Beyond that, I just want to make the program better by good coding. +22:28 < Aprogas> if IIP is a proper program, it would take into account that not all nodes can be secure +22:28 <@hezekiah> Nop does some userbase kind of stuff. He seems to understand it pretty well. +22:29 < mids> what do you mean? +22:29 < Aprogas> hezekiah is the true programmer, he is afraid of users +22:29 <@hezekiah> Aprogas: IIP will do its best to be idiot proof, but the security of a system always comes down to the people who run it. +22:29 <@hezekiah> Aprogas: I'm not affraid of users. I just don't really care too much _who_ they are. +22:29 < mids> http://www.joelonsoftware.com/articles/StrategyLetterV.html +22:30 <@hezekiah> mids: He does corporate stuff. Buisness kind of things. I still don't know how he got funding to hire Cap'n Crunch. +22:30 < mids> no comment +22:30 <@hezekiah> lol +22:33 < mids> I got nothing to say anymore +22:33 < mids> other questions? +22:33 < Aprogas> how many developers does IIP have right now, and how many hours per week do those developers spend (estimated) +22:33 <@hezekiah> Uh .. +22:34 <@hezekiah> That's a trick question actually. :) +22:34 < Aprogas> is it ? +22:34 <@hezekiah> Which _kind_ of developers are you looking for? +22:34 < Aprogas> i am not looking for developers +22:34 < Aprogas> i just want to know how the IIP development is doing +22:34 <@hezekiah> So you want to know about the developers who right isproxy? +22:35 < Aprogas> IIP is more than just isproxy i guess +22:35 <@hezekiah> Yeah. +22:35 < Aprogas> i just want to know how many people are currently spending time on IIP +22:35 <@hezekiah> That's why it's a trick question. :) +22:35 <@hezekiah> Then I have no idea! :) Not all of them are probably public! +22:35 < mids> how much time do you spend on IIP then? +22:35 < Aprogas> never mind, ill just go watch the sf's actitivity meter i guess +22:36 < Aprogas> if it has such information +22:36 <@hezekiah> I can tell you that right now (to the best of my knowledge) there are really only two people actively writting code for the isproxy source. +22:36 <@hezekiah> UserX and myself. +22:36 < mids> *nod* +22:36 < Aprogas> im not only talking about writing code +22:36 <@hezekiah> Nop is doing stuff in the background when he can that deals with neat protocols and theory. +22:36 < Aprogas> also about plannig stuff, for example that routing protocol +22:36 < Aprogas> just the project as a whole +22:36 <@hezekiah> OK ... this is an opensource project. The "developers" are anyone who pitches in an idea. +22:37 <@hezekiah> lol +22:37 < Aprogas> actually i want to know how many manhours are spent (wasted?) on IIP, so i can calculate how much money that represents +22:37 <@hezekiah> A lot trickier to answer than you thought, eh? +22:37 <@hezekiah> Well, I pretty much only know about work on isproxy. +22:37 < Aprogas> ok +22:37 <@hezekiah> That fluxuates based on how busy UserX and myself are. +22:37 <@noP> aprogas you're being nit picky +22:38 < Aprogas> its just that i want to know that if i were to donate money to this project, that i donate the right amount, not too much, not too little +22:38 <@noP> if you're not on the dev team +22:38 <@noP> then just don't waste your time +22:38 <@hezekiah> For example, right now I am very busy in real life, so I haven't been able to touch the isproxy code for over a week! (Ack!) +22:38 < Aprogas> so i want to know how much this project would `cost' in manhours +22:39 <@hezekiah> On an average week where I can write code, I might get in 4-5 hours. That's a wild stab in the dark! UserX seems to code in spurts (no offense) having periouds where he doesn't have much time and then one week where there is a flurry of commits. (He might be coding the whole time and just committing when he has completed code. I really don't know.) +22:39 <@hezekiah> Anyway, it's way to volatile for me to really get a handle on it. +22:40 < Aprogas> ok +22:41 < Aprogas> i have no more questions +22:43 * mids ends the suffering +22:43 * hezekiah hands mids the *baf*er +22:44 -!- mode/#iip-dev [+o mids] by Trent +22:44 -!- logger was kicked from #iip-dev by mids [*baf*] +--- Log closed Tue Mar 25 22:45:02 2003 diff --git a/i2p2www/meetings/logs/35.rst b/i2p2www/meetings/logs/35.rst new file mode 100644 index 00000000..f2a56c8a --- /dev/null +++ b/i2p2www/meetings/logs/35.rst @@ -0,0 +1,9 @@ +I2P dev meeting, March 25, 2003 @ 21:00 UTC +=========================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/4.log b/i2p2www/meetings/logs/4.log new file mode 100644 index 00000000..5ccd4201 --- /dev/null +++ b/i2p2www/meetings/logs/4.log @@ -0,0 +1,419 @@ +--- Log opened Tue Jun 11 22:52:16 2002 +22:55 < logger> logging started +22:55 <@mids> already? +22:55 < logger> yes :) +22:55 -!- mode/#iip-dev [+v logger] by mids +23:23 < I> 23:23 @933.23 +23:23 < I> heh, evil time +--- Day changed Wed Jun 12 2002 +00:09 -!- mode/#iip-dev [+oo UserX nop] by mids +00:39 -!- mode/#iip-dev [+o codeshark] by nop +00:39 <@mids> hey codeshark +00:39 <@codeshark> hey +00:41 < UnDeRToW> hi, good night everybody +00:41 <@nop> night +00:49 <+BluePaperBoy> hi +00:49 <+BluePaperBoy> did I miss the meeting yet? +00:50 <@mids> Tue Jun 11 22:50:18 UTC 2002 +00:50 <@mids> almost +00:50 <+BluePaperBoy> just in time :) +00:55 <+BluePaperBoy> 4 minutes 20 seconds ;) +00:56 <@nop> ok +00:57 <+BluePaperBoy> sorry, just getting antsy :) +00:58 <@nop> hehe +00:59 <@mids> lets get started +00:59 <@mids> first of all I want to congratulate UnDeRToW, he passed his exams +01:00 <+BluePaperBoy> 0 +01:00 < UnDeRToW> :) +01:00 <+BluePaperBoy> :) +01:00 <@nop> awesome +01:00 <+BluePaperBoy> it has begun :P +01:00 <@mids> all the important docs are on http://mids.student.utwente.nl/~mids/iip/ +01:00 <+BluePaperBoy> err, my count down ended :P +01:00 <@mids> this is the 4th meeting +01:00 <@mids> it is public, and unmoderated as long as it isnt chaotic +01:01 <@mids> if it become moderated, message an operator or somebody with voice, the line that you want to say +01:01 <@mids> welcome :) +01:01 <@nop> welcome all +01:01 <@mids> a logfile is recorded +01:01 <@mids> and available for everybody +01:01 <@mids> including for those who are too late +01:01 <@mids> . +01:02 <@mids> got something to add nop ? +01:02 <@nop> thnx you for all coming +01:03 <@nop> and contributing to IIP as a user/tester, developer, or otherwise +01:03 <@codeshark> i'm here +01:03 <@nop> let's see what's on the agenda for today +01:03 <@mids> 1) Welcome +01:03 <@mids> 2) Network / Channel policies +01:03 <@mids> 3) Website +01:03 <@mids> 4) Documentation status +01:03 <@mids> A) Questions? +01:03 <@mids> B) Next meeting +01:03 <@mids> attition: something about iip 1.1 +01:03 <@mids> (forgot to add that) +01:03 <@mids> . +01:04 <@nop> ok +01:04 <@nop> 2 network / channel policies +01:04 <@nop> mids if you would please +01:04 <@mids> sure +01:04 <@mids> we had something happening in #anonymous +01:04 <@mids> I kind of missed it +01:05 <@mids> but thanks to my big brother logging, I got to see it later +01:05 <@mids> there was a little incident that showed us the need for some policies +01:05 <@mids> since this network is going to become more serious +01:05 <@mids> with more people attending +01:05 <@nop> may I add something +01:05 <@mids> the risk of possible conflicts is always there +01:05 <@nop> ? +01:05 <@mids> sure +01:06 <@nop> The definitive goal of IIP +01:06 <@nop> is to allow freedom of speech +01:06 <@nop> and to fight censorship and oppression +01:06 <@nop> now we all share this common goal +01:06 <@nop> assuming +01:06 <@nop> so there are moderators +01:06 <@nop> for channels +01:07 <@nop> which gives us a sense of power, but really, is very minimal control, banning anonymity is not exactly easy +01:07 <@nop> but the purpose is to make sure everyone is not inhibited by their speech +01:07 <@nop> and can say what they would like to say +01:07 <@mids> as you maybe all know +01:07 <@nop> so keeping this in mind +01:08 <@nop> continue +01:08 <@mids> 'we' dont often know what is going on on the network +01:08 <@mids> exept for the public channels +01:08 <@mids> inclusing #anonymous, but also #iip and #help +01:08 <@mids> maybe I forgot more official channels, if so +01:08 <@mids> inform me +01:08 <@mids> because those channels kindof determine the public look of IIP, we need to get some rules done +01:09 <@mids> why? +01:09 <@mids> 2 reasons +01:09 <@mids> tell the users what the operators can do +01:09 <@mids> and visa versa +01:09 <@mids> normally, on IIP, every channel +01:09 <@mids> should be seen as a sovereign country +01:09 <@mids> since there is almost none network wide power +01:09 <@mids> every channel got to have its own rules +01:10 <@mids> which can differ from channel to channel +01:10 <@mids> if you have a channel names #sailing +01:10 <@mids> we cant do nothing there +01:10 <@mids> even if we hate the boat that you like to sail with :) +01:10 <@mids> anyway +01:10 <@mids> I want to propose some rules +01:11 <@mids> 3 categories +01:11 <@mids> 1) network wide +01:11 <@mids> 2) #anonymous +01:11 <@mids> 3) other official channels +01:11 <@mids> for all other channels, we have no power as IIP team +01:11 <@mids> except for the network rules +01:11 <@mids> any questions so far? +01:12 <@mids> nope? +01:12 <@mids> great +01:12 <@mids> I have thought of these 3 rules for the whole network: +01:12 < ellison> seems to me that #iip should be protected as well +01:12 <@mids> - no flooding +01:12 <@mids> - no spamming +01:13 < ellison> oh, 3) other protected channels +01:13 <@mids> - no acts that endanger the existance of IIP +01:13 <@mids> . +01:13 <@mids> ellison: yes? +01:13 < ellison> nevermind, 'scuse me +01:13 <@mids> np +01:13 <+BluePaperBoy> acts that endanger the existance of IIP? please clarify +01:14 <@mids> sure +01:14 <@mids> that is a pretty broad subject +01:14 <@mids> but whatever happens here.. we shouldnt risk the continuity of IIP +01:14 <@mids> some posibilities: +01:14 <@mids> ddos attacks +01:14 <@mids> child porn +01:15 <@mids> terrorist cells etc +01:15 <@mids> if we know about those things +01:15 <@mids> we have to forbid them +01:15 <@mids> because countries will attack us if we support such things +01:15 < UnDeRToW> but how we control that? +01:15 <@mids> good question +01:16 < UnDeRToW> we cant spy other users +01:16 <@mids> sure +01:16 <+BluePaperBoy> we shouldn't atleast +01:16 < ellison> ddos is a separate matter from the rest +01:16 <@mids> but if such happens, without us knowing? +01:16 <@mids> ellison: yes, correct.. ddos is more flooding +01:16 < ellison> for child porn, terrorist cells, money laundering and other statust bugaboos, we should insist on proof from the entity complaining or threatening to shut down IIP +01:18 <@mids> so if an entity comes with evidence about activity x +01:18 <@nop> evidence that they have to prove that it is the specific user +01:18 < ellison> yup +01:19 <@mids> then we can nuke his trent accounts, jupe his nick etc +01:19 < ellison> if the entity complaining has no power to harm IIP, we ignore them +01:19 <@mids> but such claims should always be verified +01:19 <+BluePaperBoy> if IIP is truly anonymous, how could that be proven and what steps could be taken to stop the person is question +01:19 <@mids> ellison: exactly +01:20 < ellison> if they can harm IIP, we insist on proof +01:20 <@mids> BluePaperBoy: we can deal with nyms, not with real persons +01:20 <+BluePaperBoy> mids: but then they can merely change their IIP identity and continue +01:20 < ellison> if they meet the proof requirements, we delete their Trent accounts as you said, and then send a report to the entity which complained +01:21 < ellison> BPB: yeah, that's the beauty of a pseudoanonymous system... +01:21 <@mids> for the sake of the common IIP wealth, such complaints should be globally announced I think +01:22 <@nop> agreed +01:22 < ellison> BPB: say some soldiers in afghanistan discovered a computer with IIP logs which proved that terrorists were using IIP to communicate ebtween their cells +01:22 <@mids> nop: what is the official email address for such things? +01:22 <+BluePaperBoy> put on the website? +01:22 < ellison> that would consistute proof, I think +01:22 <@nop> iip@invisiblenet.net +01:23 <+BluePaperBoy> ellison: be we would no not who it was or how to stop them +01:23 < ellison> we'd have their nym names +01:23 < ellison> and we could just delete their records from Trent (assuming they used Trent) +01:23 <@mids> okay, governments and other entities should email their proof of misusage (pgp signed & encrypted ofcourse) to iip@invisiblenet.net +01:23 < ellison> heh +01:24 <@nop> we still have very little power +01:24 <@nop> to stop them +01:24 <@nop> and the most we can do +01:24 <@nop> is prohibit them from using trent +01:24 <@nop> etc +01:24 <@nop> at least under that nym +01:24 <@mids> ofcourse we will do that +01:24 <@mids> whatever is in our power +01:24 < ellison> (this inability to exert controlling censorship is part of the good design of IIP, IMHO) +01:25 <@nop> it only gets better with age +01:25 <@UserX> what do we do if entities try and demand logging? +01:25 <@mids> UserX: they may join channels +01:25 < ellison> remove IIP servers from their jurisdiction +01:25 <@mids> and log all traffic +01:25 <+BluePaperBoy> so IIP'll do like most governments and "officially condemn" +01:26 <@nop> try being key operative word +01:26 <@nop> the most logging that is taking place +01:26 <@nop> is the irc clients +01:27 <@nop> but the big concern is coercing or forcing a user to log +01:27 <@mids> everybody should understand that he/she acts here as a nym +01:28 <@mids> and every relationshop between his/her real identify and the nym is a possible danger on his anon/pseudo nymity +01:29 <+BluePaperBoy> What about bad mouthing IIP and convincing people to leave/stop supporting...would that be considered "acts that endanger the existance of IIP" (just to clarify) +01:29 <@nop> no +01:29 <+BluePaperBoy> thank you +01:29 <@nop> but +01:29 <@nop> it's not nice +01:29 <@nop> ;) +01:30 <+BluePaperBoy> I was just wondering how liberally mids' statement would be taken :) +01:30 <@mids> ok +01:30 <@mids> now we have another thing +01:30 <@mids> maybe it is channel, maybe network wide +01:30 <@mids> 'dont reveal the identify of others without permission' +01:31 <+BluePaperBoy> I don't think that should be regulated +01:31 <@nop> it's more of a request +01:31 <@nop> not a regulation +01:31 <@mids> maybe on a personal / per channel base? +01:32 <@mids> ok, got network covered... lets move to #anonymous +01:32 <@mids> what is the main purpose of this channel +01:32 <@mids> and what is its name :) +01:32 <@mids> personally I think that it is about freedom of speech +01:32 <+BluePaperBoy> bash liberals? +01:32 <@mids> & that is what IIP is about +01:33 <@mids> so, I don't think that any additional rules are needed except for the network ones +01:33 < Robert> . +01:33 <@mids> with the suggestion to move offtopic stuff to the appropriate channels +01:34 <@mids> freenet stuff may be discussed there +01:34 <@mids> but should be not taken too seriouyd +01:34 <@mids> serioud +01:34 <@mids> err +01:34 <@mids> whatever :) +01:35 <@mids> if someone is doing / saying things that you dont like +01:35 <@mids> consider using /ignore +01:35 <@mids> (see your IRC client manual for more information) +01:35 <@mids> other additions to #anonymous? +01:35 < Neo> /ignore #anonymous works pretty good for me :) +01:36 <@mids> Neo: I think you mean /part #anonymous :) +01:36 < Neo> :) +01:36 <@mids> now the other official channels... +01:36 <@mids> which do we have? +01:36 <@mids> I think : #iip +01:36 <@mids> #iip-dev and #help +01:37 <+BluePaperBoy> what about #freenet? +01:37 <@mids> hm, since there is no real relationship between freenet and IIP, I think that that isnt an official matter +01:38 < ellison> #terrorist-plots +01:38 < ellison> ;-) +01:38 <@mids> #freenet channel policies should be discussed with the #freenet founder and operators +01:38 <@mids> -Trent(anon.iip)- The channel #terrorist-plots is NOT registered +01:38 <@mids> ok +01:38 <@mids> #iip is the main serious IIP channel +01:38 <@mids> (imho) +01:39 <@mids> so, stuff there should be related to IIP +01:39 <@mids> and should be correct.. don't give incorrect info there +01:39 <@mids> maybe same for #help +01:39 <@mids> anyway +01:39 <@mids> I got the hint that we are getting bored +01:39 <@mids> :) +01:40 <@mids> , +01:40 <@nop> ok +01:40 <@nop> basically +01:40 <@nop> no inhibiting people's speech +01:40 <@nop> only time to regulate +01:40 <@nop> is if others are inhibiting free speech +01:40 <@nop> aka spamming +01:40 <@nop> or flooding +01:41 <@nop> and do not abuse operator powers to inhibit speech +01:41 <@nop> got it +01:41 <@nop> good +01:41 <@nop> move on +01:41 <@mids> yup +01:41 <@mids> official thingL +01:41 <@mids> reinstate cohesion +01:41 <@nop> we will once we talk to him and review the rules +01:41 <@nop> he should be re-instated +01:41 <@mids> done +01:42 <@mids> with level 2 +01:42 <@mids> over & out :) +01:42 <@mids> 3) Website +01:43 <@mids> -------- +01:43 <@mids> how is the design going? +01:43 <+BluePaperBoy> ? +01:43 * mids looks at the agenda +01:43 <@mids> ellison: got something to say? :) +01:44 < ellison> ah +01:44 < ellison> working on it right now +01:44 < ellison> looks cool, trust me. +01:44 < ellison> ;-) +01:44 <+BluePaperBoy> which "sample" is his +01:44 <+BluePaperBoy> ? +01:44 < ellison> I might have something to show by the end of the meeting - if not then, later tonight +01:45 <@mids> another design (from tikk) is on http://www.nokhockey.com/scott/IIP/home2.htm +01:45 <@mids> hm, nop, can you say something about "wear IIP? +01:47 <@nop> oh +01:48 <@nop> hold please +01:48 <@nop> on phone +01:48 <@mids> ah +01:48 <@mids> "if you cant wait till the IIP site is done and already want to show your passion with IIP : http://www.cafepress.com/invisiblenet +01:48 <@mids> nop got some nice stuff there +01:48 * mids bought some IIP tshirts :) +01:49 <@nop> all funding goes to fund the project +01:49 <@mids> but most goes to the cafepress guys :( +01:49 <@mids> I want to have a black tshirt with a white IIP logo +01:50 <@mids> if you know a way to get it... tell us :) +01:50 < ellison> i want a black t-shirt with a black logo... +01:51 <@mids> ellison: noted.. we will have them too :) +01:51 < ellison> :-) +01:51 <@mids> other comments? +01:51 <+BluePaperBoy> I want something blue :) +01:51 <@mids> BluePaperBoy: cool +01:51 <@mids> I think that the logo's that Banks made are available +01:51 <+BluePaperBoy> ...can't find anything though ;( +02:07 -!- Topic for #iip-dev: Info, agenda, log : http://mids.student.utwente.nl/~mids/iip/ | Tuesday 23:00 UTC - http://e-store.invisiblenet.net +02:07 [Users #iip-dev] +02:07 [@codeshark ] [ ellison] [ logger] [ Robert ] [ UserX] +02:07 [@nop ] [ epoch ] [ mids ] [ Rooster77] +02:07 [+BluePaperBoy] [ I ] [ Neo ] [ UnDeRToW ] +02:07 -!- Irssi: #iip-dev: Total of 13 nicks [2 ops, 0 halfops, 1 voices, 10 normal] +02:07 -!- Irssi: Join to #iip-dev was synced in 1 secs +02:07 < Neo> <UserX> A new protocol has now been implemented for IIP 1.1 details of it are at: http://mids.student.utwente.nl/~mids/iip/meeting4/iip11proto.txt +02:07 < Neo> <UserX> this adds error detection and fixes problems introduced by the server having a static key +02:07 < Neo> (4 the logger) +02:08 < logger> gracia +02:10 <@nop> ok +02:10 <@nop> next +02:10 < logger> 3,4] +02:11 -!- mode/#iip-dev [+o mids] by Trent +02:13 < UnDeRToW> ... +02:14 <@mids> hmpf +02:14 <@mids> sorry ppl +02:14 <@mids> blaim the civ :) +02:14 <@mids> did you all see the new network diagrams? +02:14 <@nop> yes +02:14 <@nop> links etc +02:15 <@mids> question: +02:15 <@mids> bigendian == network order? +02:15 <@nop> big endian == byte order +02:15 <@mids> byte order != network order? +02:16 <@nop> ok +02:16 <@nop> any questions +02:16 <@nop> before we close the meeting +02:16 < UserX> as i understand bigendian byte order is the network byte order +02:16 <@mids> thanks UserX +02:17 -!- mode/#iip-dev [+o UserX] by mids +02:17 < UnDeRToW> can we translate the isproxy too? +02:18 <@mids> can you explain? windows, unix, docs? +02:19 < UnDeRToW> the program to join here +02:20 <@mids> how do such programs work? do they detect the language automatically? +02:20 <@nop> locale I guess +02:21 < UnDeRToW> or have different versions +02:21 < UnDeRToW> spannish, french ..... +02:22 <@UserX> there are some hooks for adding translations (gettext style) to isproxy but no support for doing actual translations yet +02:22 <@mids> I think that is a good thing.. certainly not for 1.1.. but to keep in mind, maybe 1.2 ? +02:22 < UnDeRToW> great +02:23 < UnDeRToW> and also a we have to start a FAQ +02:23 <@mids> but, I think the work involved shouldnt underestimated... chinese characters sound complex to me +02:24 <@mids> UserX: any idea how the windows i18n is? +02:24 <@codeshark> you can use resource files on windows +02:24 <@nop> chinese require double byte +02:24 <@nop> unicode +02:24 <@codeshark> yes +02:24 <@UserX> mids: do you mean how hard it would be to do translation? +02:24 <@mids> Rooster77 knows something about htat +02:25 <@mids> UserX: no, more the unicode / utf8 support +02:26 < Rooster77> Rooster77 is not fluent yet, but is working on it.. +02:27 <+BluePaperBoy> just give it to a chinese programmer ;) +02:27 < Rooster77> good idea...! +02:27 <@UserX> not that familar with it but as i understand you can select codepages for interpreting 8 bit characters +02:28 <@mids> okay... more questions? +02:30 < UnDeRToW> i need the new docs to update the translation +02:30 <@mids> okay, while they are still under review, you can get them from the CVS +02:30 < UnDeRToW> ok +02:30 <@mids> do you know how to use CVS? +02:30 <+BluePaperBoy> mids: are we stuck with that crappy iip logo? What ever happend to the copyrighted casper pics? +02:30 < UnDeRToW> yes +02:30 <@mids> UnDeRToW: contrib/htmldoc/ +02:31 <@nop> which logo +02:31 <@mids> UnDeRToW: thats where everything is +02:31 <+BluePaperBoy> the two trenchcoat guys then the p +02:31 < UnDeRToW> ok +02:31 <+BluePaperBoy> ...on the clothing ;) +02:31 <@mids> I like the new design +02:32 < UnDeRToW> and the FAQ +02:32 < UnDeRToW> we have to do one +02:32 <@mids> UnDeRToW: banks started some faq items in the manual too +02:32 < UnDeRToW> i see almost always the same quesitons +02:32 < UnDeRToW> ok +02:32 < UnDeRToW> i will take a look +02:33 < UnDeRToW> last thing +02:33 <@nop> k +02:33 <@nop> I think we're done +02:33 < UnDeRToW> i think +02:34 < UnDeRToW> would be usefull to being able to change your trent password +02:35 <@mids> ok +02:35 < UnDeRToW> if you want to change you pass you have to drop the nick +02:35 <@mids> would it be needed to enter it twice? +02:35 < UnDeRToW> but if you drop you loose the channels +02:35 <+BluePaperBoy> mids: that would be nice +02:36 <@mids> I'll think about it :) +02:37 <@mids> (no reason not to do it, just someone has to code it) +02:37 <@nop> should be like 5 lines of code +02:37 <@mids> well, 6 +02:37 <@mids> :) +02:38 <+BluePaperBoy> so it'll be done within a year I guess :) +02:38 <@mids> very likely +02:39 <@nop> ok +02:39 <@mids> remember me everydat +02:39 <@mids> day +02:39 <@nop> one thing +02:39 <@nop> http://e-store.invisiblenet.net +02:39 <@nop> support the project +02:39 <@nop> will work on getting black on white +02:39 <@nop> ellison +02:39 <@nop> anything on website yet +02:39 < ellison> hey, +02:39 < ellison> about 1 hour away from something I'd be comfortable showing +02:40 <@nop> ok +02:40 <@nop> is it like just started +02:40 <@nop> or is it fully functional +02:40 <@nop> the one you're showing +02:40 <@nop> ? +02:40 < ellison> this is a photoshop draft +02:40 <+BluePaperBoy> are you hardcoding or cheating? +02:40 < ellison> ? +02:41 < ellison> it's quite a few steps away from a finished site, but I can break out the HTML for templates in a day or so once the design is finalized +02:42 <@nop> ok +02:42 <@nop> kewl +02:45 <@mids> okay folks, I am going to sleep.. thanks for the patience :) +02:46 < UnDeRToW> me too +02:46 < UnDeRToW> i have to wake up in 4 hours +02:46 < UnDeRToW> :( +02:46 < UnDeRToW> bye +02:46 <+BluePaperBoy> bye +03:08 < logger> logging ended +--- Log closed Wed Jun 12 03:08:35 2002 diff --git a/i2p2www/meetings/logs/4.rst b/i2p2www/meetings/logs/4.rst new file mode 100644 index 00000000..81739ee1 --- /dev/null +++ b/i2p2www/meetings/logs/4.rst @@ -0,0 +1,9 @@ +I2P dev meeting, June 11, 2002 @ 23:00 UTC +========================================== + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/47.log b/i2p2www/meetings/logs/47.log new file mode 100644 index 00000000..faababaa --- /dev/null +++ b/i2p2www/meetings/logs/47.log @@ -0,0 +1,907 @@ +--> You are now talking on #iip-dev +--- Topic for #iip-dev is IIP Meeting - logfiles: + http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/ +<al-jebr> it's 21:13 +<-- wilde has quit (Ping timeout) +--- Trent@anon.iip gives channel operator status to UserX +<nop> ok +<qriff> !time +<Ambience> al-jebr: 00:21 here +<nop> I believe everyone has settled +<hezekiah> Let's go. :) +<jrand0m> 11:06 here +<nop> let's start +<nop> anyone get my agenda +<nop> so they can play it back +<nop> I forgot the order +<-- leenookx has quit (Ping timeout) +<Ambience> my clock is 15 minutes ahead :) +--> hifi (~MetroPipe@anon.iip) has joined #iip-dev +<hezekiah> <nop> on the agenda +<hezekiah> <nop> 1) Welcome +<hezekiah> <nop> 2)Our Goodbyes +<hezekiah> <nop> 3)IIP development now +<hezekiah> <nop> 4) IIP development restructuring proposal +<qriff> actually its xx:13 everywhere... +<hezekiah> <nop> 5) Recruiting for services to aid with IIP +<hezekiah> <-- Delly has quit (Ping timeout) +<hezekiah> <nop> 6) comments suggestions and people who want to help +<mids> 23:05:28 <@nop> 1) Welcome +<mids> 23:05:38 <@nop> 2)Our Goodbyes +<mids> 23:05:43 <@nop> 3)IIP development now +<mids> 23:05:56 <@nop> 4) IIP development restructuring proposal +<mids> 23:06:16 <@nop> 5) Recruiting for services to aid with IIP +<mids> 23:06:53 <@nop> 6) comments suggestions and people who want to help +<nop> wow, flood in here ;) +<nop> pl +<LeerokLacerta> Out goodbyes? +<hezekiah> lol +<hifi> TROLLS !!! +<nop> Ok, welcome all +<nop> let's settle down now :) +<hifi> . +<Ambience> settled +--> wilde (~anon@anon.iip) has joined #iip-dev +<hifi> settled +<al-jebr> anyone logging? +--> thecrypto (~thecrypto@anon.iip) has joined #iip-dev +<hezekiah> I am (sort of). +<luckypunk> mids should be. +* jrand0m logs at all times +<al-jebr> let's go! +<nop> ok +<hezekiah> nop: Agenda item number 2? +<nop> Our goodbyes +<LeerokLacerta> Bye! +<thecrypto> where is the livelog? +<nop> Ok, mids has come to a point where he is moving to other projects +--> Phiberoptika (~none@anon.iip) has joined #iip-dev +<mids> After having worked for IIP for more than I year now, I have decided to + resign as IIP developer. +<LeerokLacerta> Awww. +<mids> It has been fun and an educative experience +<mids> but it is time to move on, refresh the spirit and shuffle the cards. +<Rain> Will you still be online/around? +<mids> I'll keep running Trent as long as needed and possible. +<mids> Yes, I do plan to stay around as user +--> ntk (~blob@anon.iip) has joined #iip-dev +* nop is in the corner sobbing +<nop> oh, ah hem +<jrand0m> many thanks mids, iip w/out trent would be a pita +<LeerokLacerta> It's so sad. +<nop> yes +<nop> thank you mids for all your workup +<nop> work +<mids> Although I'll be off on vacation soon :) +<mids> . +--- mids removes channel operator status from mids +<luckypunk> :D +<luckypunk> Seem's like you've done a great job. :) +<Rain> ..how symbolic.. +<nop> we love you mids!!! +<nop> you hear that +<nop> that was my window opening +<thecrypto> we all do! +<nop> fan base out there +--> w (~w@anon.iip) has joined #iip-dev +--- nop is now known as we +<luckypunk> lol, yep. +<luckypunk> :D +* we love you mids +<Rain> Go mids go! +<jrand0m> rofl +--> leenookx (~leenookx@anon.iip) has joined #iip-dev +--- LeerokLacerta has changed the topic to: IIP Meeting - logfiles: + http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/ + | We love you mids! +<Rain> weeeeee are the chaaaampins, my frieeeennnndd... +<Neo> yes mids, thanks for all your input, collaboration and hard work in code + and doing general developer things for IIP. +--- we is now known as nop +* mids bows +* Ehud stands up and gives a standing ovation to the commitment, perseverence, + effort, and good hard code that mids has given the project. +<hifi> yeah mids take your toys and go to tigertown lol +<nop> and don't forget the PR and web management +<nop> he's been a vital aspect to IIP +<nop> getting it this far would have been hard without his work +--> ChZEROHag (hag@anon.iip) has joined #iip-dev +<hifi> hifi bitches with mids over trolling issue +<-- hezekiah has quit (Ping timeout) +<mids> heh hifi +--> hezekiah (~hezekiah@anon.iip) has joined #iip-dev +--- Trent@anon.iip gives channel operator status to hezekiah +<hezekiah> Back. :) +<luckypunk> Yay. +<hezekiah> (And in case anyone doubted, Hezekiah == Ehud.) +<hifi> i never used frucking trent and don't know what mids did . i only troll . +<nop> obviously your hezekiah@anon.iip gave it away +<-- Ehud has quit (Ping timeout) +<hezekiah> Ugh +<hezekiah> Item number 3? +<hezekiah> (If we're all done sobbing yet ...) +<hifi> and i never was pingouted in my life . I am the most disciplined user of + IIP . +<mids> 3)IIP development now +<luckypunk> heh +<luckypunk> Ok everyone! Shhh. Back on track! +<hifi> BUT I CRY that MIDS GO !!! +<hifi> ok +<hifi> . +<luckypunk> IIP development. Whats the current status of that code snapshot + release? +<luckypunk> That was supposed to happen today? +<hezekiah> Well, unless UserX has an objection to the tarball I made, + it's done. +<luckypunk> Ok. Post it on the wiki? +<hezekiah> UserX? Were there any problems with the tarball? +<UserX> no problems with the tarball +<luckypunk> Yes, but are there any windows compilations? +<hezekiah> OK1 +<hezekiah> http://invisiblenet.net/hezekiah +<hezekiah> Get your tarballs there! +<UserX> there hasn't been a windows compilation on the windows version yet +<luckypunk> hm +<LeerokLacerta> "tarballs" sound like some sort of food... +* luckypunk will try and make one. +--- hezekiah has changed the topic to: IIP Meeting - logfiles: + http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/ +- tarballs of the 'unstable' development release are at + http://invisiblenet.net/hezekiah | We love you mids! +<luckypunk> They are. For GCC. +<luckypunk> lol +<Rain> Sticky food. +<hezekiah> There is one 'documented bug'. +<nop> I can compile a win32 version if you'd like +<Rain> So, could you give a quick describtion of what is new in this release? +<hezekiah> If you run isproxy, and it fails to bind the port, then it will + /not/ abort. It will just sit there wasting memory. +<hezekiah> Rain: That's too much for me to handle (not to mention I don't + even _know_ all the differences). +<Ambience> this one I assume: iip-1.2-dev1.tar.bz2 01-Jul-2003 01:45 + 292k tar archive ? +<hezekiah> UserX could give a much better description +<hezekiah> UserX? +<nop> hezekiah/UserX can we get a changelog of the differences by chance +<nop> that may be a day before that gets done +<hezekiah> Ambience: Yup! Or the Gziped one. There the same tarball. +<nop> because there are a log of changes +<Rain> Oh, and has the expired IIP signing-key been replaced? +<Ambience> hezekiah: ok +<hezekiah> nop: I joined IIP after the development branch was already in + progress. +--> Ehud (~hezekiah@anon.iip) has joined #iip-dev +<hezekiah> Rain: No. I had to use my GPG key. +<nop> no one has tested the compile of this dev branch in win32 have they? +<luckypunk> Hey, is this src is CVS? +<hezekiah> Rain: I couldn't contact anyone who had the IIP release key. +<hezekiah> luckypunk: Yes. +* luckypunk has, but his system didn't work for it. +<Rain> hezekiah: Ok, roger. +<UserX> changes: multi-threading, bignum support via openSSL or GMP, numerous + inmprovements to the memory management system +<hezekiah> luckypunk: Right now that tarball is a copy of what you get when + you check out the hezekiah-dev branch from CVS and run 'make dist-bzip2'. +<luckypunk> Gah! I hate windows. +<Rain> UserX: niceties ;) +<hezekiah> And of course there are other internal changes that only the + developers see. :) +<qriff> just as a question for the qurious... what defines the holder for "Trent"... +<hezekiah> One simple thing is that now that BigNum is implemented using + either GMP or SSL, login is a LOT faster. +<Rain> May i mention a IIP quirk i noticed earlier today? +* luckypunk guesses its a yes. +<hifi> at wiki search button is absent . only window to type in but nowhere to + click lol . +<luckypunk> hit enter. +<qriff> and what about channel/nick expiration... +--- Ehud is now known as logger +<qriff> registration that is... +<Rain> Ok, it seems to me like you cannot start isproxy from a /path/to/isproxy + command, but intead have to do a cd /path/to and then do a ./isproxy +<hezekiah> Rain: Let me guess ... you get a configuration screen or a request + for entropy, right? +* jrand0m has a feeling this will be a very.long.meeting +<Rain> Is that intentional, or just some quirk of my local system? +<Rain> hezekiah: yes. +<hezekiah> Rain: You need to make a .iip subdirectory in your home directory. +<Rain> It claims that the conf-file is not found. +<Rain> with my .conf file? +<hezekiah> Rain: If no such directory exists, isproxy will always look for + the config files in the current directory +--> AmishOne (amishone@anon.iip) has joined #iip-dev +<Rain> Ahh. Of course. +<hezekiah> OK ... +<hezekiah> nop? Was there anything else for item 3? +<nop> have we tested it for win32 +<nop> compile wise +<hezekiah> I haven't. +<nop> UserX: ? +<UserX> no +<nop> I will test it this week then +<hezekiah> luckypunk, tried doing hezekiah-dev recently and complained for + compile errors. +<nop> that's key to maintain portability +<hezekiah> I suspect there might be problems. +* luckypunk tried, it balked. +<hezekiah> Yup. There are problems. +<Ambience> I'll have to leave for the more dominant one is ordering me to + and I have no choice here. So I'll be off to bed, but will be logging #iip-dev + for future reference. +<Ambience> see ya guys! +<lonelynerd> later +<qriff> bye +<hezekiah> Bye, Ambience. :) +<luckypunk> i'll be back. +<Ambience> <--gone (log on) +<nop> ok +<nop> this topic is done +<nop> next on agenda +<nop> what's 4? +<hezekiah> 4) IIP development restructuring proposal +<nop> ok +<nop> we had a meeting about a discussion and proposal brought to us by jrand0m + for the future development +<nop> and as well +<nop> I have had a lot of privmessages directed at me +<nop> for requests to focus on an arbitrary framework, instead of IRC specific +<nop> aka a framework that supports IRC + a whole lot more +<nop> so the want is obviously there +<nop> and the developers definitely want to go there as well +<hezekiah> Amen! +<nop> the question of how to go about doing it +<nop> and how to make the most productive use of our developers +<nop> is up in the air +<ChZEROHag> XML +<mids> is his framework site available to everybody? +<nop> this isn't specifically about language +<ChZEROHag> create a communications protocol +<nop> ok, please let me finish +<ChZEROHag> I've started on that somewhere... +<nop> then we can comment +<ChZEROHag> My apologies +<ChZEROHag> I'm a bit in and out at the moment +<nop> ok, +<nop> no prob +<nop> We are at a stage where there is discussion of an arbitrary communications + protocol +<nop> specifically for anonymous and secure communication +<nop> at this point jrand0m, any chance we can post the logs of #iip-future + meeting +<jrand0m> sure +<jrand0m> perhaps those zips I sent you so people don't have to struggle + through freenet for the other pages too +<nop> ok +<nop> hold +<nop> please +<jrand0m> (btw, the logs were unedited, so expect the usual occational banter) +<hezekiah> lol. Yup! You'll get to see exactly how much I DON'T know about + p2p networks! lol +<jrand0m> heh +<hezekiah> (And they'll probably have my conspiracy theories about nop + too! So be sure to read the logs! ;-) ) +<-- logger has quit (Ping timeout) +<hezekiah> Ugh +<nop> ok +<Neo> the logs will be a lot to read. can someone summarizze for the meeting + what was covered and some key points of all this? +<nop> http://office.invisiblenet.net/iip_future.zip +<nop> and +<hezekiah> At this point, the 'stable' release is being more unstable than + the 'unstable' one!! Urg. +<nop> http://office.invisiblenet.net/meetingPrepnotes.zip +<nop> http://office.invisiblenet.net/jrand0mnetwork_protocol.txt +<jrand0m> meetingPrepnotes.zip is a small doc that summarizes the meeting, + and the meeting was basically "ok, any thoughts?". +<-- Delly has quit (EOF From client) +<jrand0m> essentially, the proposal is to get going on a generic secure + anonymous message based system, and run iip on top of that +<mids> is there a zip with anonCommFramework too? +<nop> I didn't see that +<nop> jrand0m can you zip and send I'll post to site +<jrand0m> sure, h/o +<-- Phiberoptika has quit (* ciaito mua mua *) +<Neo> what is anonCommFramework? +<jrand0m> uber-quick summary of the meeting in iip_future.zip is "ok, + here's the proposal, any comments?" and comments were basically "ok, can IIP work + as planned on this? +<jrand0m> if you're on freenet, anonCommFramework is at + SSK@MQNd5lT-X5wHA4vONvtVadi6q1IPAgM/anonCommFramework/2// +* jrand0m is sending nop a zip of that momentarily +<Rain> Did you discuss support for PGP-based nyms? +<nop> ah hem, this is early discussions +<-- ChZEROHag has quit (Ping timeout) +<jrand0m> no, endpoints in the framework are not nym based, they're idents +<Rain> Right. So nyms an higher level. +<Rain> are +<jrand0m> (and for lots of reasons, they shouldn't be long term idents + like nyms) +<jrand0m> yes +<Rain> I was just thinking of something like trent with PGP signarute auth. +<mids> trent is central +<mids> central=bad +--> logger (~hezekiah@anon.iip) has joined #iip-dev +<jrand0m> briefly, anonCommFramework is a meta-network. a generic set + of protocols & structures that an anonymous communication network could use to + interoperate to provide militant grade anonymity +<wilde> what's the one sentence explanation of your ideas on network topology? +--> ChZEROHag (~hag@anon.iip) has joined #iip-dev +<ChZEROHag> that was fun +--> Delly (dedede@anon.iip) has joined #iip-dev +<Rain> mids: Yea. I meant similar services. +<lonelynerd> what about having to pay with hashcash to send data? couldn't + that help against flooding? +<jrand0m> wilde> heterogeneous. no one answer solves all problems. + interoperate, balancing latency, bandwidth, anonymity, and reliability to provide + the user's needs +<Delly> still in 4) ? +<hezekiah> Delly: Yup +<Delly> thx +<ChZEROHag> I think when the ircd is removed from the equation, we'll have + far better options than (hash|think|real)cash +<nop> jrand0m: any luck sending +<nop> ;) +<jrand0m> uploading to hush now. +<jrand0m> ChZEROHag> anonCommFramework has built in support for providing + network use authorization credentials +<Rain> There has been a lot of talk of IIP-Freenet interoparability. Will that + fit into the framework, or are we talking application-level again? +<ChZEROHag> come again? +<jrand0m> app level +<jrand0m> what we're discussing is splitting iip into two parts - the irc + part, and the message based secure anonymous network +<wilde> one solution could be: +<Rain> jrand0m: k. +<wilde> Application <-> SOCKS5 Proxy Interface <-> Onion Wrapper <-> Onion Router + 1 <-> ... <-> Onion Router N <-> Exit Relay <-> Public Server +<jrand0m> building a DHT on top of the message layer should be fairly easy +<hezekiah> DHT? +<jrand0m> distributed hash table +<jrand0m> (ala freenet) +<nop> ok, jrand0m let me clarify +<ChZEROHag> wilde: I think the plan is to design it such that the 'public + server' could be removed from the equation at some point +<nop> are we talking about splitting irc, or merging to focus on anonymity + framework +<jrand0m> well, given unlimited # of developers, splitting and doing both + (well, 3 things ;) in parallel. +<nop> what I mean is that the irc part is application layer +<jrand0m> given reality, there's prolly only enough dev time to get the + comm system running first, then iip on top +<jrand0m> right exactly +<nop> and since we have a somewhat viable network working with IIP +<jrand0m> irc is just another app running on it +<nop> then the idea should be +<nop> is to have developers start focusing on framework aspects +<wilde> ChZEROHag: ok, what I suggested is an anonymizing layer for regular + internet traffic, not a seperate network +<hezekiah> (This could get fun.) +<nop> wilde there are weaknesses to that +<nop> just to let you know +<nop> aka the clear text on the outer ends +<-- AmishOne has quit (EOF From client) +<wilde> nop: yes, so all connections should be encrypted to the ends +<nop> we have an effort as well to have anonymous web browsing possible with + this network +<jrand0m> yes. it must be able to operate without ever leaving the mixnet +<nop> but it is not as real time direct as your proposal wilde +<nop> it uses some time delay tactics +<nop> with caching etc +<nop> timing attacks are a serious threat to anonymity +<hifi> I WANT ANONYMISER BASED on IIP !! I DON"t TRUST OTHER ANONYSERS THEY ARE + FBI TRAPs !! +<mids> http://mids.student.utwente.nl/~mids/anonCommFramework/ +<nop> hifi, this isn't changing IIP, this is moving us forward +<nop> thanks mids +<jrand0m> heh word mids, my moz is hanging +<nop> ok +<wilde> although independant mixnets are cool, the real killer apps will probably + be general ip traffic anonymizers +<nop> wilde, they are myths +<wilde> killer apps? +<nop> no +<-- thetower has quit (EOF From client) +<jrand0m> wilde> that could be a service built on top of the comm layer +<nop> general ip traffic anonymizers +<wilde> or ip traffic anonymizers? +<nop> so far they don't exist +<nop> they exist in papers only +--> thetower (none@anon.iip) has joined #iip-dev +<jrand0m> if you build an anonymizing service on top of the comm layer, + however, your outbound routers will get shut down quickly +<thetower> Haha, I just noticed I wasn't port forwarding. +<thetower> Oop, sorry, wrong chan +<wilde> nop: what about the ZKS system? +<nop> is it still around? +<nop> and working +<wilde> nope, bad business +<wilde> few people paid +<wilde> but the framework seemed to work, but all nodes were ZKS:s paid relays +<nop> wilde but they were internal and it wasn't complete +<nop> it still had certain vulnerabilities +<nop> it was a start +<nop> I met Ian Goldberg at CodeCon 2k2, and he himself admitted it was incomplete + to what he desired +<wilde> yes, everything has vulnerabilities, we just raise the cost of tracing + dramatically +<jrand0m> right, after the mixnet is up and running, i'd like to see wilde + offer generic outbound proxy services. that'd be cool +<jrand0m> (sincerely) +<nop> jrand0m: but again the ultimate would be using that magic mirror concept + for optimum protection +<ChZEROHag> Probably the hardest option, but wouldn't freenet be a good + framework to build from? +<nop> wilde, maybe you and I can discuss this in another forum at some point +<jrand0m> but in any case, the network must be built first +<ChZEROHag> Or is that not what we're discussing? +<jrand0m> ChZEROHag> no. +<jrand0m> freenet doesn't provide hard anonymity +<ChZEROHag> aah +<ChZEROHag> I should try paying attention +<nop> ok, moving forward +<nop> UserX you still here +<wilde> nop: yes, if you have decided on topology there is no need to discuss + this in public +<UserX> I'm still here +<nop> well it's application layer, so that comes after net design etc +<nop> ok +<nop> where did we leave off at #iip-future meeting +<-- hezekiah has quit (Ping timeout) +<nop> let's start there +--- logger is now known as Ehud +* nop is catching up on the meeting logs +<jrand0m> [04:31] <jrand0m> I think we're back to your question. can / + should the irc functionality move forward as its going or move towards this mixnet. + there are significant benefits to move towards the mixnet, but some aspects of + the irc side seem to require some redesign to operate on it. +<jrand0m> [04:31] <jrand0m> the right way for the irc development to go is + not for me to say +<Ehud> Basically, UserX had some thinking to do about wether IIP could run + satisfactorily on the mixnet. +<mids> nite all +<-- mids (mids@anon.iip) has left #iip-dev (mids) +<ChZEROHag> Would it not be an idea to create a replacement irc in parallel + with a mixnet? +<ChZEROHag> After all it's going to be damn hard to use a normal ircd +<jrand0m> ChZEROHag> given infinite # devs, yes +<nop> ok ChZEROHag silence please :) +<ChZEROHag> Assume infinite devs +<ChZEROHag> Oh is this not a question bit? +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<nop> not yet +<UserX> Unfortuantlely I haven't had time to seriously sit down and think about + how your proposal would fit in with IIP +<ChZEROHag> oh +<ChZEROHag> oops +<nop> just want to get into the discussion +<nop> well +<jrand0m> UserX> think of the mixnet as a socket +<nop> let me suggest something +<nop> do we agree that our goal is not just IRC ? +<lonelynerd> well +<Delly> it's a great idea sure +<hezekiah> nop: Beyond all doubts, I agree that the goal is an anonymous + network. +<lonelynerd> doing something traffic-intensive would have the potential to + ruin the whole project +<hezekiah> nop: IRC is just a starting point. +<nop> ok, well what we should look at is this +<jrand0m> NOT doing something traffic intensive has the potential to get + us to overlook problems :) +<nop> instead of saying IIP doesn't fit +<nop> or it does fit +<nop> let's look at what modifications need to be made for irc to fit with this + mixnet, whether it's a mod to the mixnet itself +<lonelynerd> jrand0m: hmm +<nop> for instance +<nop> UserX has a vision of using channels as endpoints +<nop> Jrand0m calls them idents +<nop> are they having subtle differences +<nop> or are they largely different +<jrand0m> there's substance to those differences. +<nop> can we review that +<nop> on both sides +<nop> from jrand0m and UserX +<-- hezekiah has quit (EOF From client) +<nop> actually +<nop> read the log +<nop> nevermind +<jrand0m> ;) +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<jrand0m> the hesitancy I have w/ sending messages to a channel ident and + having that channel redistribute it to members is that the channel gets plaintext +<nop> how does it get plaintext? +<jrand0m> instead, I'd suggest having a channel contain just the channel info + (modes, users, topic, etc) +<jrand0m> the channel is just an application running on one (well, 3+) + routers listening to one (well, 3+) identities. when you /msg a channel, you + send a message to that identity (application). it then resends it out to the N + users in the channel, encrypted to each +<nop> well +<nop> I had a proposal for that +<nop> that would have the channel not contain plaintext +<nop> directly +<jrand0m> at least, without adding a channel key (which would be managed + by the channel application itself, which defeats the point) +<nop> well +<nop> we were having channel keys +<nop> for private channels +<nop> and pub channels are public anyway +<jrand0m> right. there may be ways around it. y'all know more about irc + than I do. there are other ways that don't require going this route though +<nop> see the neat thing with message channels is this +<nop> you scale slightly better than trying to find all idents to send to directly +<-- luckypunk has quit (Ping timeout) +--> dd0c (dd0c@anon.iip) has joined #iip-dev +<jrand0m> I'm not sure you scale better, but you do redistribute the load +<jrand0m> (we can find idents via O(log(n))) +--> sahara (~sahara@anon.iip) has joined #iip-dev +<jrand0m> but thats neither here nor there, this is application layer + design ;) +<nop> right +<jrand0m> all we need to do, imho, is find some workable ways that *could* + operate on the comm layer and then leave it to the wayside until we get there +<UserX> jrand0m: messages sent to channels are encrypted with a channel key that + is different to the channel's identity. a channel server can't decrypt a message + unless it has come across the key by othermeans +<sahara> did I miss the meeting? +<jrand0m> you've got some ways that could work, it sounds like, right? +<jrand0m> UserX> how does a user joining a channel get the key? +<hezekiah> sahara: Nope. You're right in the middle of it! :) +<nop> it's a key exchange +<jrand0m> with whom nop? +<jrand0m> brand new user joining #anonymous, and the app containing the + list of users on #anonymous doesn't have the key (As userx said) +<jrand0m> (all I'm saying is there's a way to get all the functionality + and still avoid having a channel key) +<UserX> jrand0m: with public channels it is derived from the channel name. with + private channels the user either creates one or a someone gives them the keys to + the channel +<jrand0m> 'k, cool +<jrand0m> so apps managing public channels can read the plaintext (by + deriving from the channel name) +<jrand0m> (which is prolly fine) +<nop> right +<wilde> jrand0m: if the apps encrypt the plaintext to each recepient, will it + scale well? +<jrand0m> yes wilde, perhaps better (depending on the algorithm used to + nominate channel managers) +<jrand0m> (though it will potentially have a nonserialized delivery) +<jrand0m> ((though i think thats the case with normal irc anyway)) +<-- thecrypto has quit (Ping timeout) +<jrand0m> but, getting back on to the question - +<jrand0m> nop, what do we hope to have decided by the end of the discussion + of #4? +<-- Neo has quit (Ping timeout) +--> d (~sahara@anon.iip) has joined #iip-dev +<nop> well +<-- sahara has quit (EOF From client) +<hifi> simple site , problem is i am tech blond but want good things lol +<nop> I was hoping that we could re-organize, but this is gonna be a discussion + for later +<hifi> sorry OOPS +<nop> UserX +<-- d has quit (Client exiting) +<nop> how long will you need to think about certain aspects, and maybe doc them + up as a concern list +<UserX> hard to say. maybe a week +<nop> what I'm thinking jrand0m is that a lot of this needs sorting out, rather + than just plowing into it, or we'll end up at the beginning with nothing to show +<nop> so let's push a week into this +<nop> and see what concerns are coming into play +<nop> because again +<nop> we want an adaptable mixnet +<nop> any application should be able to survive +<jrand0m> absolutely +<jrand0m> thats the point of the anon comm framework +<-- wilde has quit () +<nop> ok, so let's put this off a week, and focus on some realistic proposals + that can fit all of our needs +<jrand0m> you say "send message M to location L" and it magically, securely, + anonymously gets delivered +<nop> but magic is one thing +<nop> science is another +<nop> of course you know that :) +<jrand0m> the magic is from the app level's perspective ;) +<nop> yes +<nop> understood +<jrand0m> the science is in that 15 page anonCommFramework/2// ;) +<nop> ok +<hezekiah> lol +<nop> UserX, if you can get that in a week that would be helpful +<nop> ? +<jrand0m> I'll aim at revamping the docs & getting comm layer network design + ready for then so we can hit the ground running +<nop> well +<nop> we haven't agreed on certain aspects +<nop> I think that still should be hashed out +<jrand0m> what, in the network layer, haven't we agreed on? +<nop> personally I agree that maybe you post your anonCommFramework on iip-dev +<nop> and have it reviewed and commented +* jrand0m isn't on iip-dev +<Rain> So, meeting again next tuesday, same bat-time, same bat-channel? +<nop> what haven't we agreed on is whether it can support all applications +<hezekiah> jrand0m: Just post to iip-dev@invisiblenet.net . +<hezekiah> Rain: We are on item #4. There are still other items to go. :) +<jrand0m> its ~800k. if someone could post the URL to mids' mirror that'd + be cool +<Delly> argh +<Delly> re +<Delly> about services, i think if IIP become more easier and friendly, we will see + more users and more nodes. it's why i'm making script for mIRC user, one is a Trent + script, allowing to use Trent and Anonymail with the mouse, the other is a script + allowing to transfer file over iip, staying anonymous (using uuencoding). The + "protocol" used is easy and could be done for lot's irc clients with scripting + support. And so everybody could transfer little files, even between di +<jrand0m> nop> I'm 100% certain it can support all applications. +<Rain> hezekiah: Right. My missunderstanding. +<jrand0m> this layer has been used for over a decade in hundreds of industries +<Delly> was my thought of the day +<nop> well then where do we not agree +<nop> if Irc is an issue, then how is it adaptable? +<jrand0m> it isn't an issue +<jrand0m> y'all just don't understand the layer's abstraction ;) +<lonelynerd> Delly: i have a perl script that allows one to use ssh/telnet/etc + over irc +<jrand0m> (really, think of it as a socket) +<Delly> lonelynerd, the goal was just to enhance mirc +<Delly> for iip network +<lonelynerd> Delly: yeah, but if you use base64, i think it's compatible with + this one +<Delly> could be possible tu use it +<jrand0m> ok, we ready for #5 yet? +<hezekiah> nop? +<-- hezekiah has quit (Client exiting) +<Delly> oups i thought it was 5) ! +<ChZEROHag> There's a 5? +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<-- hezekiah has quit (Client exiting) +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<nop> sorry +<nop> delly +<nop> you guys +<nop> this is off topic +<nop> please reserve your conversation outside this channel +--> hezekiah_ (~hezekiah@anon.iip) has joined #iip-dev +<-- hezekiah has quit (EOF From client) +<nop> well +<nop> jrand0m +--- hezekiah_ is now known as hezekiah +<nop> before I agree to go to 5 +<nop> the problem I'm seeing is +<nop> UserX has a voice +<nop> as well +--- Trent@anon.iip gives channel operator status to hezekiah +<jrand0m> of course +<nop> and if he sees logistical problems +<nop> I believe they should be heard +<nop> so you can't just say, hey it's gonna work +<nop> it has to be "solidly" agreed on both ends +<nop> aka he needs convincing +<jrand0m> right, but I'm not going to sit on my thumbs waiting for him + to doc them up. if he does come up with some problems in a week, fantastic, + and we'll revise accordingly +<nop> or he needs to convine you +<nop> but the idea is this +<nop> what I'm trying to propose with this +<nop> is to reorganize our dev team to get on your bandwagon +<nop> with that +<nop> it would put our energy in working on the network design +<nop> that's the idea +<nop> thus helping all of us get somewhere specific +<nop> I'm not trying to slow down +<jrand0m> right, i don't expect to have a V1.0 final protocol spec next week. + last night I downloaded about 50 new articles off citeseer to do some more research +<nop> ok +<nop> so can we post your proposal to iip-dev +<nop> and get some review +<jrand0m> coo' +<nop> also I advise on your own to propose it on cryptography@metzdowd.com +<nop> which will get some serious review +<jrand0m> sounds good +<nop> ok +<nop> UserX, you there +<UserX> i'm here +<nop> ok, so jrand0m will work on protocol spec, and can I assume you'll come + up with a concerns list or some additives to the protocol? +<UserX> yes +<nop> ok, let's resume this in a week +<nop> what was 5? +<nop> sorry If I'm being a pain +<nop> just want to organize it +<nop> to make sure we're all on same page +<jrand0m> recruiting for services...? +<hezekiah> 5) Recruiting for services to aid with IIP +<nop> ok +<nop> yes +<nop> since mids departure +<nop> and cohesions return +<nop> we are possibly looking for others to contribute to IIP in some aspect +<nop> this does not mean you have to be a hardcore core developer +<nop> but additives like maybe a web maintainer would be good, +<nop> some PR would be good +<hezekiah> luckypunk volunteered to manage the website. +<hezekiah> <luckypunk> I wanna help/take over the IIP website. +<hezekiah> <luckypunk> :D +<nop> and if more people would like to hop on with the upcoming project that + jrand0m is proposing +<jrand0m> wikked +<nop> even if you just want to review the protocol +<nop> that is more than enough help +<nop> the reality is this +<nop> we have a lot of developers with real time jobs +<nop> and it is consuming them at the moment +<nop> and any additional help is wanted +<nop> since this is a huge endeavor +<nop> to take IIP to where it needs to be +<nop> aka InvisibleNet at some point +<nop> real life jobs ;) +<nop> anyway +<nop> the idea is +<nop> it would be cool if people would love to add to this project in some ways +<nop> using their skills, and I know their are some programmers out there +<nop> and a few that have some spare tiem +<nop> time +<nop> luckypunk's reliability will have to be reviewed, no offense, I've had + him offer before with help maintaining a freesite, and no luck there +<hezekiah> nop: I can understand that one. ;-) +<hezekiah> nop: He just asked me to forward the offer along because he + wouldn't be here. +<nop> ok +<hezekiah> nop: I did. My part's done. :) +<nop> well, either way, anyone who wants to join in +<nop> contact one of us +<nop> either at iip@invisiblenet.net +<hezekiah> One of whom? +<nop> or just by nick, +<nop> hezekiah, userx, nop, +<jrand0m> I hear anyone who volutneers to help iip gets free hookers and blow +<hezekiah> What are 'hookers and blow'? +<hezekiah> ... or do I not want to know? +<jrand0m> heh +<nop> hezekiah: don't ask +<hezekiah> OK. +<hezekiah> I don't want to know. :) +<nop> hezekiah: enjoy your sheltered life ;) +<nop> while you can +<nop> cuz college is gonna be fun :) +<hezekiah> I'm enjoying it! I'm enjoying it! +* jrand0m enjoys the hookers and blow ;) +<nop> jrand0m: quick question +* w hugs luckypunk and nop +<jrand0m> si sr? +<nop> jrand0m: are you considering yourself a dev of IIP at some time soon? +<nop> since you are offering a merge ;) +<hifi> + http://www.guerrillanews.com/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=gnn&Number=182767&page=0&view=collapsed&sb=5&o=0&part= +<hifi> sorry , opps again +<jrand0m> nop> a dev of invisiblenet, but I can't contribute to iip +<nop> understood +<nop> IIP == invisiblenet future projects +<hezekiah> jrand0m: Good working! +<hezekiah> jrand0m: Wording. +<nop> devs wanted for either +<nop> to make that clear +<nop> specifically cuz jrand0m could use a good team set +<Addic> I could take a look of the Windows code... +<jrand0m> si sr. once we get rolling into software design, there's going + to be more truckloads of work than one can imagine +<jrand0m> word Addic +<nop> awesome +<nop> ok +<nop> I will send this request on iip-dev line as well +<nop> anyone interested please don't hesitate to contact +<nop> was there a 6? +<nop> I believe so +<jrand0m> 6) comments suggestions and people who want to help +<jrand0m> suggestion: < 1.8 hours next time :) +<jrand0m> (not that any of the topics could have been condensed any more + than they were) +<nop> no comments? +* nop thinks everyone's asleep +<nop> hehe +<nop> we bored them +<jrand0m> w3wt +<Addic> heh, who has been working on the Windows' code this far? +<nop> ok +<hifi> zzzzzz... +<nop> UserX has made it so far portable +<Rain> What kind of talents are we looking for? +<Addic> ok +<nop> ok, let me re-iterate +<nop> Coders, Graphics dudes, Web devs, PR people, Web maintainers +<Rain> Ok, missed that. Sry. +<nop> and if you can write biz plans, that helps me too :) +<nop> you didn't miss +<nop> I didn't go in enough detail +<jrand0m> heh +<-- Ehud has quit (EOF From client) +<hifi> I am Born PR people +<Rain> Step one: Collect Underpants. +<Addic> translating to other languages at wiki? +<nop> yes +<nop> that would be great +<nop> translations +<Addic> ok, i could do that too +<nop> documentation +<nop> etc +<-- hezekiah has quit (Ping timeout) +<nop> even organization +<nop> anyone who wants to be actively involved in helping InvisibelNet/IIP +<hifi> I invite ppl to use IIP alll the time +<nop> thnx hifi +--> hezekiah (hezekiah@anon.iip) has joined #iip-dev +<Rain> What kind of org skills? +<nop> well, maybe help run the meetings, or maybe forcing us dev guys to get + more docs on the protocol +<nop> etc +<nop> possibly organize interviews and some type of press releases +<nop> some ideas for the future of promoting the use of IIP +<nop> etc +<nop> ok, please contact one of us if you want to help out +<Rain> Ok, org question, that I have mentioned before: IIP Signing key? (nag, nag) +--> Ehud (~hezekiah@anon.iip) has joined #iip-dev +<hifi> IIP notification service :) for ppl to knoe I /him is online LOL +<qriff> just as a question for the qurious... what defines the holder for "Trent"... +<qriff> and what about channel/nick expiration... +<qriff> registration that is... +<-- ChZEROHag has quit (Ping timeout) +<jrand0m> trent is a service, not a nick, so trent must have access to the + ircd (i think) +<nop> these questions are mids questions for trent, he's an abstract piece +<nop> yes jrand0m +<jrand0m> iip notification would be cool. how does anonymail do it? +<jrand0m> can clients send a /notify nick to the server and get a msg when + the nick joins? +<hifi> IIP SMS notification LOL +<nop> actually +<nop> we did have IIP SMS as the first version of anonymail +<nop> but it tended to flood +<hifi> oh +<nop> so now we do it as anonymail database delivery +<hifi> IIP invitation msg as signature to ordinary e-mails ... +<hifi> Kinda " Do yo Yahoo ? Get MSN free " stuff +<jrand0m> ooOOoo textAds +<jrand0m> but does iip need more users? +<hifi> oh +<jrand0m> or is getting more users just a "oh cool, lets service more people"? +<hifi> no +<hifi> dunno +<hifi> i just brainstorm +<-- Mira has quit (Ping timeout) +<hezekiah> More people ... more ideas ... more volunteers +<hifi> IIP as world standart will be cool +<hezekiah> More people ... more problems ... more strain on the network ... +<hezekiah> ... more floods of #anonymous ... +<hezekiah> It's a two sided question. +<hifi> more channels lol +--> Mira (~Mira@anon.iip) has joined #iip-dev +<hifi> IIP Eugenics Program LOL Less Population Less Problems +--> ChZEROHag (~hag@anon.iip) has joined #iip-dev +<Addic> hmm... going back to the notification question... is it so the /notify + nick does not work here? Or am I not understanding the question... +<lonelynerd> Addic: sure it works +<Addic> well what's the problem then? +<hifi> ? +<-- Delly has quit (EOF From client) +<lonelynerd> wasn't much following the conversation, but they talked about + having a /notify that wouldn't require the client to poll +<Addic> ok +<-- ChZEROHag has quit (Ping timeout) +<-- w has quit (Ping timeout) +<-- Rain has quit (I Quit) +--> w (~w@anon.iip) has joined #iip-dev +<hezekiah> Hmmm ... +<hezekiah> I think it's about time we adjurne this meeting. +<hezekiah> What do you say, nop? +* jrand0m thinks he fell asleep too +<nop> yeah +<nop> ok +<nop> later +<-- jrand0m (jrandom@anon.iip) has left #iip-dev (jrand0m) +<hezekiah> Meeting adjurned! :) +<hezekiah> *BAF*! +<-- Addic (anon@anon.iip) has left #iip-dev (Addic) +<-- LeerokLacerta (~leerok@anon.iip) has left #iip-dev (Client Exiting) +<-- hezekiah has quit (Client exiting) +<-- Ehud has quit (Client exiting) diff --git a/i2p2www/meetings/logs/47.rst b/i2p2www/meetings/logs/47.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/47.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/49.log b/i2p2www/meetings/logs/49.log new file mode 100644 index 00000000..29be7821 --- /dev/null +++ b/i2p2www/meetings/logs/49.log @@ -0,0 +1,741 @@ +--- Log opened Tue Jul 15 17:46:47 2003 +17:46 < gott> yo. +17:46 <@nop> just a heads up on my silence +17:46 <@hezekiah> Tue Jul 15 21:46:49 UTC 2003 +17:47 <@hezekiah> OK. The iip-dev meeting has started. +17:47 <@hezekiah> Is it the 48th or 49th? +17:47 < jrand0m> nop> this is why its critical that we get the router + architecture pounded out asap. I understand that different people have + different rates of speed, and we must segment so different components can + proceed accordingly +17:47 < mihi> 49th +17:47 <@hezekiah> OK! Welcome to the 49th iip-dev meeting! +17:47 < jrand0m> I have three more days at my job, after which 90+ hours / + week will be dedicated to getting this going +17:48 < jrand0m> I know and don't expect everyone to be able to do that, + which is why we need to segment +17:48 < jrand0m> hi hezekiah :) +17:48 <@hezekiah> lol +17:48 <@nop> to rebutt on that +17:48 <@hezekiah> I'll wait a minute. Then we can do the agenda. :) +17:48 <@nop> the security of the router architecture is dependant that you + do not rush as well +17:49 <@nop> if we do +17:49 <@nop> we overlook +17:49 <@nop> which could leave us cleaning up a big mess later +17:49 -!- Rain [Rain@anon.iip] has quit [I Quit] +17:49 < jrand0m> nop> disagree. we can still build app layer and APIs + without implementing the router (or even knowing how the network will operate) +17:49 <@nop> I agree with that +17:50 <@nop> I'm specifically talking about the underlying network +17:50 < jrand0m> if we can agree to the API I sent out, then thats the + segmentation we need +17:50 < jrand0m> right, router impl and network design still isn't done +17:50 <@nop> ok +17:50 <@nop> oh, I can definitely agree with your api so far +17:51 <@hezekiah> jrand0m: One problem. +17:51 < jrand0m> shoot hezekiah +17:51 <@hezekiah> It will look different if you implement it in C. +17:51 < jrand0m> not too different +17:51 < gott> oh dear +17:51 < jrand0m> less capital letters, and replace the objects with structs +17:51 < gott> what languages are people considering implementing it in? +17:51 < jrand0m> (for the api) +17:51 <@hezekiah> Uh, jrand0m? There is no 'byte[]' in C. +17:51 < jrand0m> gott> read the mail archives for some example answers to that +17:52 <@hezekiah> You will be using void*'s with an integer to specifiy the + length most likely. +17:52 < jrand0m> hezekiah> then unsigned int[] +17:52 < gott> jrand0m: for once, a religious war that I'm not a part of +17:52 <@hezekiah> If I remember correctly (help me out here nop), you can't + just return an unsigned int[] from a function. +17:53 <@hezekiah> gott: It's not a religious war. I'm just saying that the + API as a concept might be fine, but in C it would look seriously different. +17:53 < gott> hezekiah: as opposed to what? pseudocode? +17:53 < jrand0m> right, syntactic changes. but yes, if there are real + differences, we need to get them worked out ASAP. (like, today) Perhaps + now would be a good tiem to look at the email I sent entitled "high level + router architecture and API" and review? +17:54 <@hezekiah> nop? UserX? Are you game for that? +17:54 < jrand0m> not too different, but different none the less, yes. + which is why I said Java API on todays email :) +17:54 -!- WinBear [WinBear@anon.iip] has joined #iip-dev +17:55 <@nop> wait +17:55 <@nop> reading above +17:55 -!- mihi_2 [~none@anon.iip] has joined #iip-dev +17:55 -!- mihi is now known as nickthief60234 +17:55 -!- mihi_2 is now known as mihi +17:55 < jrand0m> wb mihi +17:55 < gott> btw, is this being live logged? +17:55 -!- nickthief60234 [~none@anon.iip] has quit [EOF From client] +17:55 <@hezekiah> gott: Yes. +17:55 < mihi> redundancy rules ;) +17:55 < gott> I'll just read it later on then. +17:55 -!- gott [~gott@anon.iip] has left #iip-dev [gott] +17:56 <@nop> ok +17:56 <@nop> yes +17:56 < WinBear> jrand0m: hi +17:56 <@nop> definitely differences +17:56 <@nop> what we need +17:56 < jrand0m> heya WinBear +17:56 <@nop> is a team of certain developers to write the main api level + controls for these languages +17:56 <@nop> we know that jrand0m can handle java +17:56 <@nop> and probably could team up with thecrypto as well +17:56 <@nop> and hezekiah and the gang can do C +17:56 <@nop> and jeremiah if he's willing +17:56 <@nop> can do python +17:56 <@hezekiah> I can do C++ too! ;-) +17:56 <@nop> ok +17:56 <@nop> C++ as well +17:57 <@hezekiah> lol +17:57 <@nop> C++ will probably work +17:57 <@nop> with C +17:57 <@nop> if you don't template the crap out of it +17:57 < jrand0m> heh +17:57 <@hezekiah> lol +17:57 <@hezekiah> Actually, while MSVC can link C and C++ object files, + gcc doesn't seem to like that. +17:57 <@nop> aka, stick to structs that are compatible with C, or is that + not viable +17:57 < jrand0m> first question, prior to that, is what applications will use + these APIs? I know of apps that will want to use java, will iproxy be in C? +17:58 <@hezekiah> nop: I don't think C and C++ are object compatible. +17:58 <@nop> ok +17:58 <@hezekiah> nop: C++ won't get along with C much better than Java. +17:58 <@nop> well maybe USerX could do C +17:58 <@nop> and you could pull C++ +17:58 <@hezekiah> We don +17:58 <@nop> ? +17:58 <@hezekiah> don't even need to _do_ C++ if you don't want to. It's + just that I prefer it. +17:59 <@nop> well, the thing is +17:59 <@nop> there are a lot of C++ developers +17:59 <@nop> especially in the microsoft world +17:59 <@hezekiah> Even in the Linux world. (see: KDE and Qt.) +17:59 < jrand0m> C and C++ are binary compatible if you just make .so or .a +17:59 < jrand0m> (btw) +18:00 <@nop> can C be a good placement for C++, aka C++ developers would be + able to handle a c api easier than a C++ api with a c developer? +18:00 <@hezekiah> jrand0m: Yeah. You can probably have libraries ... but if + you can +18:00 <@hezekiah> jrand0m: can't even use classes, it sorta defeats the + purpose. +18:00 <@nop> right +18:00 <@nop> let's stick with C +18:01 <@nop> because C++ coders can still call a C library rather easily +18:01 <@hezekiah> If one module needs to call anothers functions, then they + had best both be the same language. +18:01 <@hezekiah> nop: C++ coders will know C well enough ... though it + might take some work if they never /learned/ C. +18:02 <@hezekiah> However, C coders wouldn't know C++ since C is just a + subset of C++. +18:02 -!- logger_ [~logger@anon.iip] has joined #iip-dev +18:02 -!- Topic for #iip-dev: logfiles will be online after the meeting: + http://wiki.invisiblenet.net/?Meetings +18:02 [Users #iip-dev] +18:02 [@hezekiah] [+Ehud ] [ leenookx] [ moltar] [ tek ] +18:02 [@nop ] [ jeremiah] [ logger_ ] [ Neo ] [ WinBear] +18:02 [@UserX ] [ jrand0m ] [ mihi ] [ ptsc ] +18:02 -!- Irssi: #iip-dev: Total of 14 nicks [3 ops, 0 halfops, 1 voices, +10 normal] +18:02 < jrand0m> right +18:02 -!- Irssi: Join to #iip-dev was synced in 9 secs +18:02 < jrand0m> (with JMS :) +18:02 <@nop> yep +18:03 -!- You're now known as logger +18:03 < jrand0m> ok, can we review the overall architecture to see whether + the APIs are even relevent first? +18:03 <@nop> fine 18:04 < jrand0m> :) +18:04 < jrand0m> ok, see the email I sent w/ the routerArchitecture.png. + any thoughts on that seperation? +18:04 -!- tek [~tek@anon.iip] has quit [] +18:05 < WinBear> jrand0m: is that on the wiki? +18:05 < jrand0m> WinBear> no, on the mailing list, though the archives + are down. lemmie add it to the wikki +18:06 <@hezekiah> Correct me if I'm wrong ... +18:07 <@hezekiah> ... but it looks like we're going to have 3 seperate API's + that are as similar as possible. +18:07 <@hezekiah> Right? +18:07 < jrand0m> yes hezekiah +18:07 <@hezekiah> So since each API is in a different language, are they + going all each have seperate implementations? +18:07 < jrand0m> yes +18:07 <@hezekiah> Or is there a way for Java or Python to access a C library? +18:08 < jrand0m> yes, but we don't want to go that route +18:08 < mihi> for java: JNI +18:08 <@hezekiah> So this talk about Java, C, C++, Python, etc. working + together is mute since they never will? +18:08 < jrand0m> how do I attach an image to the wiki? +18:08 <@hezekiah> Each API has its own backend written in that language. +18:08 < jrand0m> no hezekiah, look at the diagram +18:09 <@hezekiah> Oh, duh! +18:09 <@hezekiah> The API's don't link to a backend. +18:10 <@hezekiah> They talk via sockets. +18:10 < jrand0m> si sr +18:10 <@hezekiah> This is still a little confusing though. +18:10 <@hezekiah> Give me a sec here. :) +18:11 <@hezekiah> OK. What is the thing labeled 'transport'? +18:11 < jrand0m> for example, bidirectional HTTP transport, SMTP transport, + plain socket transport, polling HTTP socket, etc +18:11 < jrand0m> the thing that moves bytes between routers +18:12 <@hezekiah> OK. +18:12 <@hezekiah> So the diagram I'm looking at shows one person's computer. +18:12 <@hezekiah> He has a router that talks to other people's computers + via the transports. +18:12 < jrand0m> correct +18:12 <@hezekiah> Person 1 (Alice) has 2 applications running. +18:12 <@hezekiah> One is in C, the other in Java. +18:13 <@hezekiah> Both are linked to a library (that's the API). +18:13 < jrand0m> both are "linked" to seperate libraries (the APIs) +18:13 <@nop> simple concept +18:13 <@nop> yes +18:13 <@hezekiah> Those libraries, take input from the program encrypt it, + and send it via sockets (unix or TCP) to the router ... which is another + program Alice is running. +18:13 < jrand0m> correct +18:14 <@hezekiah> OK. So it's kinda like isproxy being split in two. +18:14 < jrand0m> bingo :) +18:14 <@hezekiah> One part is low end and written in C, and the other is + high end and written in whatever. +18:14 < jrand0m> exactly +18:14 <@hezekiah> OK. I get it. :) +18:14 < jrand0m> w00t +18:14 <@hezekiah> So no language needs to play nice with any other language. +18:14 < jrand0m> WinBear> sorry, I can't toss it on the wiki as it only + takes text :/ +18:15 <@hezekiah> Since they all comunicate with the router via sockets, + you could write an API in PASCAL for all the design cares. +18:15 <@nop> yes +18:15 <@nop> arbitrary +18:15 < jrand0m> right +18:15 <@nop> it handles arbitrary sockets +18:15 < jrand0m> though some things need to be standardized (like the data + structures for Destination, Lease, etc) +18:15 < WinBear> jrand0m: i get a vague idea based on what hezekiah is saying +18:15 < jrand0m> word +18:16 <@hezekiah> jrand0m: Right. The structure and order of the bytes that + go across that socket is set in a design somewhre +18:16 <@hezekiah> somewhere. +18:17 <@hezekiah> But you can still implement how those bytes are send and + received any joly way you please. +18:17 <@nop> WinBear: it's the same exact way that the irc client works + with isproxy +18:17 < jrand0m> exactly +18:17 <@hezekiah> Good. +18:17 <@hezekiah> I understand now. :) +18:17 -!- moltar [~me@anon.iip] has left #iip-dev [moltar] +18:17 <@nop> well +18:17 <@nop> not exactly +18:17 <@hezekiah> Uh oh. +18:17 <@nop> but imagine how that works +18:17 <@nop> and you can understand arbitrary sockets +18:17 <@nop> isproxy just routes +18:17 <@nop> and delivers +18:18 <@nop> now jrand0m +18:18 <@nop> quick question +18:18 < jrand0m> si sr? +18:18 <@nop> is this api designed for only new applications that are designed + to work on this network +18:18 -!- mode/#iip-dev [+v logger] by hezekiah +18:18 < WinBear> nop: with the highlevel replacing the irc client? +18:18 < jrand0m> nop> yes. though a SOCKS5 proxy could use this API as well +18:18 <@nop> or can it be able to have a middle man that can allow already + standard clients +18:18 <@nop> for instance +18:19 <@nop> so all we would have to do is write the middleman -> api +18:19 < jrand0m> (but note that there's no 'lookup' service available - + no DNS for this network) +18:19 < jrand0m> correct +18:19 <@nop> so that we can support say Mozilla etc +18:19 <@nop> so they can just code plugins +18:19 < jrand0m> nop> yes +18:19 <@nop> ok +18:19 <@nop> or transports :) +18:20 < jrand0m> (e.g. the SOCKS5 has the HTTP outproxies hardcoded to + destination1, destination2, and destination3) +18:20 <@nop> ok +18:20 < WinBear> i think i get it +18:21 < jrand0m> w00t +18:21 < jrand0m> ok, one of the things I had to think about in this design + was keeping the private keys in the app's memory space - the router never + gets a hold of destination private keys. +18:21 <@hezekiah> So the application can send raw data over the I2P network + by sending it to the API, and it doesn't need to worry about the rest. +18:22 <@hezekiah> Right? +18:22 < jrand0m> that means the APIs need to implement the end to end part + of the crypto +18:22 < jrand0m> exactly hezekiah +18:22 <@hezekiah> OK. +18:22 <@nop> yes +18:22 <@nop> that's the idea +18:22 <@nop> it does it for you +18:22 <@nop> you just call the hook +18:23 <@hezekiah> One quick question: +18:23 <@hezekiah> This 'router' obviously needs to speak a certain protocol + over it's transports. +18:23 < jrand0m> correct +18:23 <@hezekiah> So it is possible to provide multiple implementations of + the router ... +18:23 < jrand0m> yes +18:24 <@hezekiah> ... as long as they both speak the same protocol. +18:24 < jrand0m> (which is why the spec has placeholders for bitbuckets) +18:24 < jrand0m> right +18:24 <@hezekiah> So you have a router in Java, and one in C, and one + in PASCAL. +18:24 * jrand0m cringes +18:24 < jrand0m> but yeah +18:24 <@hezekiah> And they all can talk together since they're talking over + TCP/IP using the same protocol. +18:24 * WinBear jumps +18:24 <@hezekiah> jrand0m: And yes. I don't remember my PASCAL days overly + fondly either. +18:25 < jrand0m> well, Pascal can talk to the C one through the TCP transport, + and the C one can talk to the Java one over the HTTP transport, for example +18:25 <@hezekiah> Right. +18:25 < jrand0m> (transports talk to other like transports, routers manage + the messages delivered between them but don't deal with how they're delivered) +18:26 <@hezekiah> The point I was looking to make was that the protocol is the + same, so it doesn't matter what language someone's router is implemented in. +18:26 < jrand0m> right +18:26 <@hezekiah> Cool. +18:26 < jrand0m> now you understand why I said "who cares" to all the C vs + Java vs etc debates? :) +18:26 <@hezekiah> Yup. +18:26 <@hezekiah> lol +18:27 <@hezekiah> I've got to hand it to you jrand0m. This will make it very + kind for develoeprs to write programs for this network. +18:27 < jrand0m> heh, well, the API ain't quite original. this is how + Message Oriented Middleware (MOM) works +18:27 <@hezekiah> And you could even make routers that specialize in certain + platform specific features (like 64-bit CPU's). +18:28 < jrand0m> absolutely +18:28 <@hezekiah> jrand0m: Humble too! ;-) +18:28 <@hezekiah> Well, it looks good to me. +18:28 < jrand0m> ok, UserX, nop, does this seperation make sense? +18:28 <@nop> of course +18:28 <@nop> is userx still here +18:29 <@hezekiah> He's been idle for 1:26. +18:29 < jrand0m> 'k. so then we have two tasks: design the network, and + design how the API works. +18:29 <@nop> right +18:29 <@hezekiah> Quick simple question: The API's do end to end crypto. Do + the routers to node to node crypto ? +18:29 <@nop> yes +18:30 < jrand0m> yes +18:30 < jrand0m> (transport level) +18:30 <@hezekiah> Good. :) +18:30 <@nop> hezekiah: it's very similar to what we have so far +18:30 <@nop> in that aspect +18:31 < jrand0m> ok.. er, shit, thecrypto aint around for comments on the + performance model. +18:31 < Neo> and for the paranoid, the apps can do the pgp encryption before + it hits the API ;) +18:31 < jrand0m> absolutely neo +18:31 < jrand0m> I was even tempted to leave the end to end crypto out of + the API and leave it up to the apps... +18:31 <@hezekiah> jrand0m: That would be cruel. +18:31 < jrand0m> heheh +18:32 <@hezekiah> BTW, the API's and the router communicate via sockets. +18:32 <@hezekiah> On UNIX will they be using UNIX sockets or local TCP/IP + sockets? +18:32 < jrand0m> prolly just local tcp/ip for simplicity +18:32 <@nop> hold +18:32 <@hezekiah> (I suppose you could make a router that accepts both.) +18:33 * hezekiah is really liking this interchangable parts setup +18:33 <@nop> if you hold on a sec +18:34 <@hezekiah> Holding ... :) +18:34 <@nop> I'll call thecrypto at his house +18:34 <@nop> see if he can get on +18:34 < jrand0m> hehe word +18:34 <@hezekiah> lol +18:34 * hezekiah dons a thick Itallian accent +18:34 <@hezekiah> Nop ha' got ... CONNECTIONS! +18:34 < jeremiah> lo +18:34 <@nop> hey jeremiah +18:35 < jrand0m> heya jeremiah +18:35 <@nop> would you be willing at the api level to assist with a python api +18:35 < jeremiah> sure +18:35 * jeremiah reads backlog +18:35 < jrand0m> heh word +18:35 * nop is calling +18:36 <@nop> he's not home +18:36 <@nop> he'll be back in an hour +18:36 < jrand0m> 'k, has anyone else read the .xls and/or have comments on + the model? +18:37 <@hezekiah> I read the .xls ... but I don't know much about p2p so + most of it was over my head. +18:37 <@hezekiah> UserX is good at that stuff. +18:37 <@nop> I have to read it still +18:37 < jrand0m> (btw, morphmix had some insane numbers... they were saying + they could expect random hosts on the net to have average 20-150ms ping times, + rather than the 3-500 I was expecting) +18:37 < jrand0m> coo' +18:37 <@nop> it's staroffice or openoffice? +18:37 < jrand0m> openoffice, but I exported it to .xls +18:37 <@nop> which is excell? +18:37 < jrand0m> correct +18:38 <@hezekiah> BTW, concerning the API ... +18:38 < jrand0m> si sr? +18:38 <@hezekiah> ... in C the boolean would be int. +18:38 <@nop> which email +18:38 <@nop> hezekiah: yes +18:38 <@hezekiah> The classes would be sent as structure pointers. +18:38 <@nop> unless you typedef boolean +18:39 <@hezekiah> And the functions that use byte[] would use a void* with + an additional parameter that specefies the length of the buffer. +18:39 <@nop> hezekiah: you're being picky :) +18:39 < jrand0m> nop> I cant access the archives so I'm not sure what the + subject line was, but it was last week... +18:39 <@nop> save it for a later time +18:39 <@hezekiah> nop: Picky? +18:39 < jrand0m> heh, yeah, y'all working on the C api can work that detail out +18:39 * jeremiah is done reading backlog +18:39 <@nop> what's the file called +18:39 <@hezekiah> nop: I'm just trying to find all the stuff that is different, + so we can hammer it out like jrand0m asked. +18:40 <@hezekiah> I'm trying to be helpful. :) +18:40 <@nop> hezekiah: yes, probably off meeting time +18:40 < jrand0m> nop> simple_latency.xls +18:40 <@hezekiah> boolean sendMessage(Destination dest, byte[] payload); +18:40 <@hezekiah> would be +18:40 <@hezekiah> int sendMessage(Destination dest, void* payload, int length); +18:40 <@hezekiah> . +18:40 <@hezekiah> byte[] recieveMessage(int msgId); +18:40 <@hezekiah> that could either be: +18:41 <@hezekiah> void* recieveMessage(int msgId, int* length); +18:41 <@hezekiah> or +18:41 <@nop> jrand0m: got it +18:41 <@hezekiah> void recieveMessage(int msgId, void* buf, int* length); +18:41 <@hezekiah> or +18:41 < jrand0m> hezekia: why not typedef struct { int length; void* data; + } Payload; +18:41 <@hezekiah> DataBlock* recieveMessage(int msgId)l +18:41 <@hezekiah> DataBlock* recieveMessage(int msgId); +18:41 < jeremiah> where's this xls? +18:41 <@nop> oh iip-dev +18:41 <@hezekiah> jrand0m: The struct you just mentioned is basically what + DataBlock is. +18:42 < jrand0m> word hezekiah +18:42 <@nop> subject more models +18:42 <@hezekiah> Chances are the C version would have DataBlocks. +18:43 <@hezekiah> Beyond that the only other thing to note is that each + 'interface' would just be a set of functions. +18:43 <@hezekiah> nop: Did I find all the differences that would exist in + a C API? +18:43 < jrand0m> right. perhaps #include "i2psession.h" or something +18:43 < jeremiah> is there a mockup python api? +18:44 < jrand0m> no jeremiah, I don't really know python :/ +18:44 <@nop> I would have to re-review the java api, but I would say that + you're right on target +18:44 < jrand0m> but it would probably be similar to the java, as python is OO +18:44 < jeremiah> cool, i can derive one from the C one +18:44 * nop is not a java head +18:44 < jrand0m> cool jeremiah +18:44 < jeremiah> is the c api in the thing you sent out a few days ago? +18:44 <@hezekiah> Yeah. Python should be able to handle the Java api. +18:44 < jrand0m> jeremiah> that was the Java one +18:45 < jrand0m> oh, the Java one was today +18:45 < jrand0m> the older one was language independent +18:45 <@hezekiah> Hmm +18:45 <@nop> UserX says he should be able to assist with C api +18:45 < jrand0m> word +18:45 <@nop> he's busy at work at the moment +18:46 < jrand0m> coo' +18:46 <@hezekiah> One last note: With the C api, each function would probably + take a structure* to the structure that it is an 'interface' of in Java. +18:46 <@nop> hezekiah: loos good +18:46 <@nop> looks good +18:46 <@hezekiah> I2PSession createSession(String keyFileToLoadFrom, + Properties options); +18:46 <@hezekiah> would be: +18:46 <@nop> java and their non-native data types +18:46 <@hezekiah> I2PSession* createSession(I2PClient* client, char* + keyFileToLoadFrom, Properties* options); +18:46 <@nop> ;) +18:46 < jrand0m> hehe +18:46 < jrand0m> right hezekiah +18:47 < jeremiah> are we addressing unicode? +18:47 <@hezekiah> Anyway, if you can live with those differences, the C and + Java API's should be identical beyond that. +18:47 <@hezekiah> nop? Unicode? :) +18:47 < jrand0m> UTF8 if not UTF16 +18:48 <@hezekiah> Perhaps Unicode should be dealt with on the application + level. +18:48 < jrand0m> right, charset is all the content of the message +18:48 <@hezekiah> Oh. +18:48 < jeremiah> ok +18:48 <@hezekiah> Java String's are done in Unicode, aren't they jrand0m? +18:48 < jrand0m> the bitbuckets'll all be bit defined +18:48 < jrand0m> yes hezekiah +18:48 < jrand0m> (unless you explicitly instruct them to change charsets) +18:49 <@hezekiah> So the string sent to the Java API would be different than + the one sent to the C API unless the C API implements strings using Unicode. +18:49 < jrand0m> not relevent +18:49 <@hezekiah> OK. +18:49 < jrand0m> (app->API != API->router. we only define API->router) +18:49 <@hezekiah> What I'm saying is this, jrand0m: +18:50 <@hezekiah> If I set my password with the Java API, it goes to the + router out someplace else. +18:50 < jrand0m> password? you mean you create a Destination? +18:50 <@hezekiah> Then it find another router, which sends it to another API + (?) which is implemented in C. +18:50 <@hezekiah> void setPassphrase(String old, String new); +18:50 <@hezekiah> That function. +18:51 < jrand0m> hezekiah> thats the administrative password to access the + administrative methods of the router +18:51 <@hezekiah> Ah +18:51 <@hezekiah> Do any functions in the API which use Java String's end + up with that String being sent to another API? +18:51 < jrand0m> 99.9% of apps will only use I2PSession, not I2PAdminSession +18:51 <@nop> also, anything carried with the router gets converted for + network travel correct? +18:51 <@hezekiah> If so, we should probably use Unicode. +18:51 <@nop> unicode wouldn't be releavant +18:52 < jrand0m> hezekiah> no. all inter-router info will be defined by + bit buckets +18:52 <@hezekiah> OK. +18:52 < jrand0m> correct nop, at the transport level +18:52 <@hezekiah> (I'm assuming a bit bucket is just a binary buffer, right?) +18:53 < jrand0m> a bit bucket is a statement that the first bit means X, + the second bit means Y, bits 3-42 mean Z, etc +18:53 < jrand0m> (e.g. we may want to use X.509 for the certificates bitbucket) + +18:53 <@hezekiah> I've never dealt with that before. +18:54 <@hezekiah> I'll worry about it when I get there. :) +18:54 < jrand0m> heh word +18:55 < jrand0m> ok, the four things I wanted us to hit today: *router + architecture, *performance model, *attack analysis, *psyc. We've done + the first, thecrypto is offline so perhaps we delay this (unless you have + thoughts on the model nop?) +18:57 <@hezekiah> Um ... jrand0m. I have yet another question. +18:57 < jeremiah> jrand0m: where's the latest version of the network spec? is + it what you sent out on the 13th? +18:57 < jrand0m> si sr? +18:57 <@hezekiah> Well the router architecture has the API's handle keys + /sent to them by the Application/. +18:57 < jrand0m> jeremiah> yes +18:57 <@nop> I don't at this time +18:58 <@hezekiah> Now ... the only way I see that the API gets the key is + from createSession. +18:58 < jrand0m> hezekiah> the router gets public keys and signatures, + not private keys +18:58 < jrand0m> right +18:58 <@hezekiah> But that requires a file. +18:58 < jrand0m> the keys are stored in a file or in the API's memory +18:58 < jrand0m> yes +18:58 <@hezekiah> Now if the application generates a key, why can't it just + send it to the API via a buffer? +18:59 <@hezekiah> Must it really store it in a file, and then provide the + file name? +18:59 < jrand0m> no, it can be in memory if you'd like +18:59 <@hezekiah> There is not function to all that in the API though. +18:59 <@hezekiah> It's just a thought. +19:00 <@hezekiah> If the key is supposed to be generated only once and used + many, many times (like GPG keys), then a file makes sense. +19:00 -!- mihi [none@anon.iip] has quit [bye all, it's getting late...] +19:00 <@hezekiah> But if it will be generated more often, then perhaps some + way to directly send it to the API via a structure or buffer of some sort + might be nice +19:00 <@hezekiah> . +19:01 < jrand0m> yes, its generated once and only once (unless you're wearing + a tinfoil hat) +19:02 < jrand0m> though the createDestination(keyFileToSaveTo) lets you + create that key +19:02 <@hezekiah> OK. +19:02 <@hezekiah> So there's really no need for transfer directly from the + App to the API. A file will suffice. +19:03 <@hezekiah> So where were we before I so rudely interupted? :) +19:06 < jeremiah> so right now we're just working on the router API, not + the client one, right? +19:06 < jrand0m> well, we're skipping on performance analysis for now + (hopefully we can get some chatter re: it on the mailing list before next + week?). and probably the same wrt attack analysis (unless anyone read the + new spec and has comments) +19:07 <@hezekiah> So we're since we're skipping that, what are we supposed + to be talking about now? +19:07 <@hezekiah> Psyc? +19:07 < jrand0m> unless anyone else has other comments to bring up...? +19:08 <@hezekiah> Well, for once, my comment hole (also notoriously known + as my mouth) is empty. +19:08 < jrand0m> hehe +19:09 < jrand0m> ok, anyone have any thoughts on how the IRC side of things + will work, and whether psyc may be relevent or useful? +19:09 < jeremiah> sidenote (that pissed me off): wired's "Wired, Tired, + Expired" list had Waste as 'wired' +19:09 < jrand0m> heh +19:09 < jrand0m> do you realize how much we're going to blow everyone away? +19:09 < jeremiah> yep +19:09 <@hezekiah> jrand0m: That assumes we get this to work. +19:10 < jrand0m> I guarantee it will work. +19:10 <@hezekiah> There are a lot of other failed efforts out there. +19:10 < jrand0m> I quit my job to work on this. +19:10 <@hezekiah> Then we're going to blow everyone away. :) +19:10 <@hezekiah> Yeah. How is bread getting on the table when you do that? +19:10 <@hezekiah> GPL code doesn't pay well. ;-) +19:10 < jrand0m> heh +19:11 <@hezekiah> As for psyc ... let me put it this way: +19:11 <@hezekiah> The first time I heard of it was when you emailed us + about it. +19:11 < jrand0m> shit, I wasn't the one who found it :) +19:11 <@hezekiah> However, IRC is probably one of the most (if not /the/ + most) prolific chat protocols around. +19:11 <@hezekiah> People will want IRC apps LONG before they even /know/ + what psyc is. +19:11 <@hezekiah> jrand0m: Oops. Sorry. I forgot that detail. :) +19:12 < jrand0m> not according to psyc. their history goes back to 86 I think +19:12 <@hezekiah> The point is that the supperiority of the protocol, isn't + really as relevant as to who uses it. +19:12 <@hezekiah> Their _history_ may go back that far. +19:12 <@hezekiah> But how many people _use_ Psyc? +19:12 < jeremiah> yeah if they've been around since a year after I was born + (ahem) and they aren't that big yet +19:12 <@hezekiah> My point is that even if it's a better protocol, most + people _use_ IRC. +19:13 <@hezekiah> We can make the best I2P network on the planet ... +19:13 -!- Ehud [logger@anon.iip] has quit [Ping timeout] +19:14 < jeremiah> can someone explain briefly why we care? I thought IRC + would only be one possible application but that the network is flexible to + support psyc as well if it wanted to +19:14 <@hezekiah> Right. +19:14 <@hezekiah> Psyc can be made ... +19:14 <@hezekiah> ... but I'm saying we should do IRC first because more + people use it. + +19:14 <@hezekiah> jrand0m, we can make a great I2P network, but people won't + use it unless it has something they want. +19:14 < jrand0m> jeremiah> the reason psyc is interesting is that we may + want to implement IRC in the same vein that psyc works +19:15 <@hezekiah> Hence we should provide them with a 'killer-app'. +19:15 < jeremiah> ok +19:15 < jrand0m> right, IIP is invisible IRC project, and will allow people + to run IRC +19:16 < jrand0m> with no central server (or any server at all, actually), + theres a lot of thinking to be done to figure out how IRC will work. + psyc has a possible answer to that +19:16 < jrand0m> though there are others +19:17 <@hezekiah> As I said, psyc might do better, but people want to use IRC, + not psyc. +19:17 < jrand0m> and they will +19:17 < jrand0m> they'll use irc +19:17 <@hezekiah> It's all about marketing, baby! ;-) +19:17 < jeremiah> I'll try to read the spec and some stuff on psyc tonight +19:17 < jrand0m> word +19:17 <@hezekiah> lol +19:17 < jeremiah> planning to meet at 5:00 UTC tommorow? +19:17 <@hezekiah> No? +19:18 < jeremiah> or whenever +19:18 < jrand0m> I'm on iip 24x7 :) +19:18 < jeremiah> yeah but i eat +19:18 <@hezekiah> jrand0m: I noticed. +19:18 < jrand0m> 05:00 utc or 17:00 utc? +19:18 <@hezekiah> jeremiah: LOL! +19:18 <@hezekiah> Well the iip-dev meeting officially starts at 21:00 UTC. +19:18 -!- Ehud [~logger@anon.iip] has joined #iip-dev +19:19 < jeremiah> ok, i just said 05:00 UTC because I was talking out of my ass +19:19 < jeremiah> where's mids? +19:19 <@hezekiah> mids, left the project for a while. +19:19 <@hezekiah> Weren't you there a few meetings back? +19:19 < jeremiah> ok +19:19 < jeremiah> guess not +19:19 <@hezekiah> We had a goodbye party of sorts as part of the agenda. +19:19 < jeremiah> oh +19:20 <@hezekiah> OK ... +19:20 <@hezekiah> Is there anything still on the agenda? +19:20 * jrand0m doesn't have any left on mine +19:20 < jeremiah> about psyc: +19:20 < jeremiah> if this is a psyc feature, I know you mentioned it a + while ago +19:20 * hezekiah never had an agenda in the first placve +19:21 <@hezekiah> pace +19:21 <@hezekiah> place +19:21 < jeremiah> I don't think having each user send a message to every + other use in the room is s smart idea +19:21 <@hezekiah> There! +19:21 < jrand0m> jeremiah> so you'd have redundant nominated pseudoservers + redistribute the messages? +19:21 < jrand0m> (pseudoservers = peers in the channel who have the list + of users) +19:21 < jeremiah> I don't think 'broadcasting' is that smart either, but it + + seems like it'll require a _lot_ of bandwith for a given user who may be on + a modem, and with the lag from sending say... 20 messages separately would + screw up conversation +19:21 < jeremiah> I don't know the best solution, maybe that would be one +19:22 < jeremiah> I think direct messaging would be good if you wanted it, + but there are cases where it's probalby not that important +19:22 <@hezekiah> The message would need to be signed by the authors private + key to garuntee authenticity. +19:22 <@hezekiah> Though this issue won't matter for a long time still, + I think jeremiah has a point +19:22 < jrand0m> hezekiah> that requires users wanting provable comm :) +19:23 < jrand0m> definitely. +19:23 <@hezekiah> If I had to send a message to 100 users in a channel ... +19:23 < jeremiah> although my average message is only a few hundred bytes, + so sending it to hundreds of users might not be so hard +19:23 <@hezekiah> ... well, my conversation would be /very/ slow. +19:23 < jeremiah> especially if you didn't wait for a response +19:23 <@hezekiah> 20K to send one message. +19:23 <@hezekiah> I don't think so. :) +19:23 < jrand0m> well, if there are 100 users in a channel, *someone* has + to send out 100 messages +19:23 < jeremiah> it's 20k? +19:23 < jeremiah> oh, right +19:23 <@hezekiah> 200 users +19:24 < jeremiah> hmm +19:24 < jeremiah> wouldn't the routers be good at that? +19:24 < jeremiah> we can somewhat safely assume they have decent bandwith, + right? +19:24 <@hezekiah> I thought each person had a 'router implementation' +19:24 < jrand0m> not really. if there are relays, the nomination mechanism + needs to take that into consideration +19:24 < jrand0m> yes hezekiah +19:24 < jeremiah> i haven't read the spec +19:25 < jrand0m> a router is your local router +19:25 <@hezekiah> Ugh! +19:25 <@hezekiah> I'm still mixing your nicks up! +19:25 <@hezekiah> lol +19:25 < jrand0m> hehe +19:25 <@hezekiah> Um ... where'd nop go? +19:25 <@hezekiah> Oh. +19:26 <@hezekiah> He's still here. +19:26 <@hezekiah> I thought he was gone for a moment, +19:26 < jrand0m> but jeremiah is right, psyc has some ideas we may want to + consider, though we may want to reject them +19:26 <@hezekiah> Let's just get the network running first. +19:26 * jrand0m drinks to that +19:26 <@hezekiah> If you strech your vision to the finish line, you'll trip + over the rock 3 inches in front of you. +19:27 * jeremiah feels inspired +19:27 <@hezekiah> lol +19:27 < jrand0m> I think what would be really great if we could aim to review + the network spec by next week, sending out emails to iip-dev whenever anyone + has thoughts or comments. am I out of my mind? +19:27 <@hezekiah> nop? Do you have anything else to add to the agenda, + or do we adjurn? +19:27 <@hezekiah> jrand0m: Well, I don't know if I could read all that by + next week, but I can try. :) +19:27 < jrand0m> heh +19:28 < jrand0m> its a grueling 15 pages ;) +19:28 <@hezekiah> 15 pages? +19:28 <@hezekiah> It looked more like 120! +19:29 < jrand0m> heh, well, depends on your resolution I suppose ;) +19:29 < jeremiah> he has a lot of anchors in there, makes it look like + it's huge +19:29 < jrand0m> hehe +19:29 <@hezekiah> The left side has a LOT more than 15 links, budy! +19:29 <@hezekiah> 'Fess up! +19:29 <@hezekiah> It's more than 15. :) +19:29 <@hezekiah> Oh! +19:29 <@hezekiah> Those aren't pages! They're just anchors! +19:29 <@hezekiah> I'm saved! +19:30 * hezekiah feels like a seaman just rescued from drowning +19:30 < jeremiah> class turn to volume 4 chapter 2 Message Byte Structure +19:30 < jrand0m> lol +19:30 <@hezekiah> lol +19:30 <@nop> adjourn +19:30 <@hezekiah> *baf*! +19:30 <@hezekiah> Next week, 21:00 UTC, same place. +19:30 <@hezekiah> See y'all there. :) +19:30 < jeremiah> seeya +--- Log closed Tue Jul 15 19:30:51 2003 diff --git a/i2p2www/meetings/logs/49.rst b/i2p2www/meetings/logs/49.rst new file mode 100644 index 00000000..3147e3b3 --- /dev/null +++ b/i2p2www/meetings/logs/49.rst @@ -0,0 +1,7 @@ +I2P dev meeting, July 15, 2003 @ 21:46 UTC +========================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/50.log b/i2p2www/meetings/logs/50.log new file mode 100644 index 00000000..2d07e192 --- /dev/null +++ b/i2p2www/meetings/logs/50.log @@ -0,0 +1,594 @@ +--- Log opened Tue Jul 22 15:56:06 2003 +15:56 <@hezekiah> jrand0m: Righto! +15:56 -!- mode/#iip-dev [+o jrand0m] by hezekiah +15:56 <@cohesion> log enabled +15:56 <@jrand0m> w00t +15:56 <@nop> we need to add cohesion and remove mids on dev list +15:56 <@hezekiah> Excelent. :) +15:56 <@hezekiah> What dev list? +15:56 <@cohesion> nop: i tried CVS and it wouldn't accept my user/pass +15:56 <@nop> ok, I'll add you +15:56 <@nop> hold +15:56 <@nop> what is your sf id +15:56 <@cohesion> cohesion +15:56 <@nop> pmsg me if you need +15:56 <@nop> ok +15:57 <@cohesion> i think +15:57 -!- thecrypto [thecrypto@anon.iip] has joined #iip-dev +15:57 <@hezekiah> BTW, everyone I will be leaving around 22:15. +15:57 <@hezekiah> UTC +15:57 <@cohesion> yea +15:57 <@cohesion> hezekiah: okay +15:58 <@nop> cohesion: you're in +15:58 <@nop> we need to update website +15:58 <@cohesion> nop: okay +15:58 <@cohesion> nop: i'll try it now +15:58 <@nop> and we need to start modelling the IIP with an I2P +15:58 < thecrypto> hey +15:58 < thecrypto> i made it +15:58 <@nop> ok +15:58 <@nop> werd +15:58 <@nop> ;) +16:00 <@hezekiah> jrand0m? I just looked at your revision to the +development schedual. +16:00 <@jrand0m> si sr? +16:00 <@hezekiah> The graph with the bars and lines gets chopped off at +the right hand side; I can't see the rest of it. +16:01 <@jrand0m> yeah, ganttproject isn't quite perfect, but its better +than doing it by hand. +16:01 <@jrand0m> the things at the far right are the last tasks - +nothing is after them +16:01 <@hezekiah> But I can +16:01 <@jrand0m> the tasks there are listed, in order, on the +index-tasks.html +16:01 <@hezekiah> can't even see what the tasks are. +16:02 <@hezekiah> OK. :) I'll just have to settle for text. +16:02 <@hezekiah> nop: Are we going to start soon? I'm going to have to +leave at 22:15 UTC, but I'd like to catch as much of the meeting as +possible. +16:02 <@jrand0m> let me see if I can make a big task to fix that... +16:02 <@hezekiah> jrand0m: Thanks. :) +16:03 <@nop> yes +16:03 <@nop> alright +16:03 <@nop> agenda +16:03 <@nop> 1) +16:03 <@nop> welcome +16:03 <@nop> 2) +16:03 <@nop> Website future +16:03 <@nop> 3) +16:03 <@nop> bug fixes with 1.1 +16:03 <@nop> 4) +16:03 <@nop> I2P +16:03 <@nop> 5) +16:03 <@nop> Suggestions and comments +16:03 <@nop> welcome all +16:04 <@nop> moving to 2 +16:04 <@nop> website +16:04 <@nop> cohesion, are your maintanance website skills up to par? +16:04 <@cohesion> aye +16:04 <@cohesion> XHTML and CSS are my specialties +16:04 <@nop> ok, we are assuming you can do website stuff, changes etc +16:04 <@nop> ok +16:04 <@cohesion> yep +16:05 <@cohesion> granted that i can get CVS to cooperate :) +16:05 <@nop> easy +16:05 <@nop> export CVS_RSH=ssh +16:05 <@nop> and don't use pserver +16:05 <@nop> use d:ext +16:05 <@cohesion> i'm using gruntspud to CVS interfacing +16:05 <@nop> ok +16:05 <@cohesion> it's part of my text editor +16:05 <@cohesion> it should work +16:05 <@cohesion> we can talk about that later though +16:05 <@cohesion> i'm trying it now +16:05 -!- thecrypto [thecrypto@anon.iip] has quit [Ping timeout] +16:05 <@nop> if you have issues let me know right away if you can, so I +can assist this because I have a bunch of tasks +16:06 <@nop> also +16:06 <@nop> we need to look at making an I2P section +16:06 <@nop> since it's going to be the next big project +16:06 <@nop> I'll talk to ellison to see if he's contribute a bit of his +web design skills to add to that for a template +16:06 <@hezekiah> Should I2P be a section of invisiblenet.net or +invisiblenet.net/iip? (I vote for the former.) +16:06 <@nop> and we can get that hashed out +16:06 <@cohesion> ok +16:06 <@nop> former as well +16:06 <@jrand0m> former +16:06 <@nop> it would be under projects +16:07 -!- thecrypto [~thecrypto@anon.iip] has joined #iip-dev +16:07 <@nop> iip is one project +16:07 <@nop> i2p is another +16:07 <@hezekiah> So, invisiblenet.net/i2p +16:07 <@nop> yes +16:07 <@hezekiah> Right. That's the way I see it too. :) +16:07 <@nop> anyone here good at making a logo? +16:07 <@nop> volunteers are welcome +16:07 <@nop> just submit to iip-dev list +16:07 <@nop> ok moving on +16:07 <@nop> bug fixes in 1.1 +16:07 <@jrand0m> h/o +16:07 * hezekiah would like to point out that his skills at the GIMP are +to be avoided like WMD. +16:08 <@jrand0m> would it be possible to keep the i2p stuff off the web +until we're ready for beta? +16:08 <@cohesion> i suggest we use the wiki for collaborating on the i2p +documents +16:08 <@nop> yes +16:08 <@cohesion> i can set up a restricted area +16:08 <@nop> that's possible +16:08 <@hezekiah> jrand0m: Are you thinking of a big smash announcement +on /. or something once we have it in good order? +16:08 <@nop> cohesion: I concur +16:08 <@jrand0m> yes hezekiah +16:08 <@jrand0m> word cohesion +16:09 <@nop> ok +16:09 <@nop> let's look at 1.1 for a sec +16:09 <@nop> hezekiah you made a discovery, that has not to do with +focus? +16:09 <@nop> or what? +16:10 <@hezekiah> The code is fine. +16:10 <@hezekiah> The problem is communication, not code. +16:10 <@hezekiah> The user has to move the mouse aroung _inside_ the +dialog box. +16:10 < mihi> the dialog lacks a progress bar to give feedback if the +user does it correctly +16:10 <@nop> yes that's true +16:10 <@hezekiah> He can move the mouse around _outside_ the dialog box +until he's blue in the face, but it won't gather entropy. (Which is what +these users are doing.) +16:10 <@nop> it does lack a dialog box +16:11 <@hezekiah> A progress bar would be a plus. +16:11 <@hezekiah> And should be somewhat easy to implement ... if I +could understand the tangle that UI code in IIP is. +16:11 <@cohesion> or even some feedback +16:11 <@hezekiah> Anyway, I posted my suggestions to the mailing list. +16:12 <@nop> it's in win32 api +16:12 <@nop> ;) +16:12 <@hezekiah> Either capture the mouse (I couldn't get M$ to +cooperate to do that), or make the dialog box message explain to the +user he needs to move the mouse around _inside_ the dialog box. +16:12 <@hezekiah> nop: I know. +16:12 <@nop> fine hezekiah be that way :) +16:12 <@hezekiah> What? +16:12 <@hezekiah> What did I do? +16:12 * hezekiah is confused +16:12 < thecrypto> how about just maximize the dialog box? +16:12 <@nop> hezekiah: I'm just messin' with ya +16:13 <@hezekiah> nop: OK. :) +16:13 <@hezekiah> Where's UserX? He knows more about the IIP UI code +than I do. +16:14 <@hezekiah> thecrypto: As for maximizing, well, the user might not +like a rabid dialog box consuming his entire screen. +16:14 <@hezekiah> Mouse capture is ideal, but as I said, I couldn't get +M$ to do it. +16:14 <@jrand0m> many other apps don't capture the mouse +16:14 <@jrand0m> a status bar plus explaination seems typical +16:15 <@hezekiah> Anyway, that's the 'bug'. +16:15 <@hezekiah> How do you want it fixed nop? +16:15 <@nop> well +16:15 <@nop> I would think if possible we could have a meter that shows +the entropy gathering for sure +16:16 <@hezekiah> OK. +16:16 <@nop> and definitely fixes the language. Have you exhausted the +research on capturing the mouse movements? +16:16 <@hezekiah> To the point of my patience. +16:16 <@hezekiah> Seriously, what I did _should_ work. +16:16 <@nop> I assume that's a lot? +16:16 <@hezekiah> Well, I didn't get much sleep last night. +16:17 <@nop> hmm +16:17 <@nop> let's try to get a meter bar and the language fixed +16:17 <@nop> that will give us an idea +16:17 <@hezekiah> Because it isn't working, I'm assuming the M$ docs are +lieing to me (very possible) or something 'unknown' is happening in the +IIP UI code. +16:17 <@nop> right +16:17 <@hezekiah> Righto. :) +16:17 * hezekiah now gets down on his knees and prays that UserX wrote +UI code for a progress bar. +16:19 <@nop> haha +16:19 <@nop> if not go to planet-source-code.com +16:19 <@nop> there's a lot of samples there +16:19 <@hezekiah> The win32 API I can manage (though I detest it.) +16:19 <@nop> I hate it as well +16:19 <@hezekiah> But UserX/whoever-originally-wrote-this made a wrapper +around it. +16:19 <@hezekiah> It's the wrapper I'm worried about. +16:19 * nop is coding in it right now for work +16:19 <@hezekiah> I'm looking into it now. +16:20 <@hezekiah> Let's move on to the next agenda item. +16:20 -!- jeremiah-gym is now known as jeremiah +16:20 <@nop> ok +16:20 <@nop> next item is i2p +16:20 < jeremiah> hi +16:20 <@nop> hi +16:20 <@nop> jrand0m you start +16:20 <@hezekiah> jeremiah: Just in time! +16:20 < jeremiah> hezekiah: nop and I are oddly time synced, as you'll +learn +16:20 <@jrand0m> 'k, has everyone had a chance to check out the roadmap? +16:21 <@hezekiah> Yeah. +16:21 <@jrand0m> its obviously draft, and things after the 1.0 milestone +are largely up in the air, but its something to start from +16:21 <@jrand0m> I've updated it beyond whats on the list to include +hezekiah jumping on the C api (w00t!) +16:22 -!- jeet [~miteymous@anon.iip] has joined #iip-dev +16:22 <@jrand0m> basically, after this coming friday, we'll have the API +protocol spec'ed out, which will mean we can parallelize a lot +16:22 < jeet> hello ;) +16:22 <@jrand0m> 'lo jeet +16:23 < jeet> hey if i make a server is it possible to change anon.iip +to whatever i want +16:23 <@jrand0m> rough gut question: how insane does the r2 roadmap +sound? are schedules insane, are there things missing, are things in the +wrong order or dependencies not represented? +16:23 <@nop> yes +16:23 < jeet> kewl +16:24 <@hezekiah> jrand0m: I would concur the entire thing is insane. +However, I think (until I get to college) it should be doable. +16:24 <@jrand0m> heh +16:24 < jeet> this is a very cool thing you guys have done ;X +16:24 <@hezekiah> Though I'm not sure nop and UserX can design that IRC +protocol even in 21 days. +16:24 <@hezekiah> nop: ;-) +16:24 <@nop> no +16:24 <@jrand0m> ok, you're off to uni in late august? mid august? when +should we pencil you in for less activity? +16:24 <@hezekiah> Around August 20th I'm of. +16:24 <@hezekiah> off. +16:25 <@jrand0m> 'k +16:25 <@hezekiah> Until then I'm a rabid nermal! :) +16:25 < jeremiah> I'm off about the same time +16:25 < jeremiah> (to univ) +16:26 <@nop> ok +16:26 <@jrand0m> so we'll have to get more resources on the 'implement +IRC' task or just drop the task from the 1.0 release +16:26 <@hezekiah> I wouldn +16:26 <@hezekiah> wouldn't make the 1.0 release dependant on IRC. +16:26 <@nop> I believe that we will need to delay the task +16:26 < jeet> [17:23] -anon.iip- CTCP (except ACTION) and DCC are +disabled <- how can i stop this from poppiing up every 3 minutes? +16:26 <@hezekiah> Do the IRC, but let i2p 1.0 come out when it's ready. +16:27 < thecrypto> wow, i'm half way through college as two others just +start :) +16:27 <@jrand0m> lol +16:28 <@jrand0m> I concur hezekiah +16:28 <@hezekiah> Cool. I still think i2p will be it's own killer app. +:) +16:28 <@jrand0m> so that basically means all I2P 1.0 requires after +august is a month of debugging and documentation to go from alpha to +beta to 1.0 +16:29 <@jrand0m> hezekiah> definitely. we need to get a demo app out on +it first - does the instant messenger app + file transfer sound good to +people for that? +16:29 -!- jeet [~miteymous@anon.iip] has quit [ircN 7.27 + 7.0 for mIRC +(2002/01/10 00.00)] +16:29 <@hezekiah> Well, you said it best: 'demo'. From my view, it +doesn't need to be special. It just needs to prove the network is worth +developing on. +16:30 <@hezekiah> So the IM client would be a good demo, in my opinion. +16:30 < Zwolly> file transfer is one thing i really would like to see so +gimme a demo +16:30 <@hezekiah> Zwolly: lol +16:30 <@nop> yes +16:30 < Zwolly> and see me as an "normal" user +16:31 <@hezekiah> Zwolly: You can be our guniea pig! ;-) +16:31 * hezekiah starts mixing poisinous code in his lab. ;-) +16:31 < Zwolly> hmmm yummie +16:32 <@jrand0m> ok, one last thing on i2p +16:32 <@nop> sure +16:33 <@jrand0m> nop> any chance we can get a non sourceforge trusted +cvs server? +16:34 <@jrand0m> sourceforge has more problems than these college +student's exams +16:34 <@nop> yes +16:34 <@nop> I will arrange that and have it up by next week +16:34 <@jrand0m> awesome. thanks +16:34 <@nop> also +16:34 <@nop> I may be able to get a compile farm +16:34 <@nop> that is not sf +16:34 <@nop> with vpn access to it +16:35 <@hezekiah> Compile farm!? +16:35 <@jrand0m> compile farm? bah, we can just run ant :) +16:35 <@hezekiah> jrand0m: All code is not Java. +16:35 <@hezekiah> I personally love compile farms. +16:35 <@hezekiah> :) +16:35 <@jrand0m> ant == make. it can run gcc / etc +16:35 <@nop> hezekiah: send me a list of viable platforms we'll need to +test on +16:35 <@jrand0m> 'k, if we really need the cpu power of a compile farm, +thats great +16:36 < wilde> what license are you planning to use? +16:36 <@nop> GPL +16:36 <@jrand0m> GPL cool with everyone for this? +16:36 < wilde> k nice +16:36 <@hezekiah> I'm very pro GPL. +16:36 <@hezekiah> But one warning +16:36 <@hezekiah> For the API's we will probably need LGPL. Otherwise +all programs made for this network MUST be GPL +16:36 <@jrand0m> we may want to go LGPL down the line +16:37 <@jrand0m> yeah +16:37 <@jrand0m> we MUST not require all apps using I2P to be GPL'ed +16:37 <@hezekiah> So the router should be GPL, but the API's will +probably need to be LGPL at some time. +16:37 <@hezekiah> jrand0m: Then we'll need an LGPL API. +16:37 <@hezekiah> The only problem that poses is getting a good crypto +kit for C that is compatible with LGPL. +16:38 <@hezekiah> I don't think Cryptlib's Sleepycat license is. +16:38 <@hezekiah> I could email the author and ask for an exception or +something if I need to when the time comes. +16:38 <@jrand0m> hezekiah> not need, want. the API comm layer will be an +open spec, so anyone can write their own and not link to any of our +libraries +16:38 <@hezekiah> Right. +16:38 <@nop> right +16:38 <@hezekiah> So for now we can even make GPL API's if we need to. +16:39 <@hezekiah> OK, one question for jrand0m: +16:39 < jeremiah> but we should try to have non-viral ones asap +16:39 <@hezekiah> I agree. +16:39 < wilde> http://www.virtualunlimited.com/products/beecrypt/ +16:40 < wilde> Bee Crypt is LGPL, i've used once +16:40 <@hezekiah> wilde: Beecrypt is far beneath what is required +unfortunately. +16:40 <@nop> yes +16:40 <@nop> I don't think we should use a crypto lib like Beecrypt +16:40 <@jrand0m> word wilde +16:40 <@cohesion> hezekiah: there's tons of crypto code in +GnuPrivacyGuard that's all GPL'd +16:40 <@cohesion> you might check and see where it came from +16:40 <@hezekiah> cohesion: The problem is we'll need an LGPL C API that +uses Crypto. +16:41 <@hezekiah> I'll work it out when I get to it. +16:41 <@hezekiah> For now, I have two questions for jrand0m: (It's gone +up one!) :) +16:41 <@jrand0m> we have lots of options. we'll figure it out +16:41 <@jrand0m> heh fire away +16:42 <@hezekiah> 1.) When the client API spec is done on the 25th will +it detail the byte-by-byte structure of the messages sent over the +network, and will it detail the specifics on how the crypto is +implemented? +16:42 -!- ion [ion@anon.iip] has joined #iip-dev +16:42 <@jrand0m> yes +16:42 <@hezekiah> 2.) Will be we using Twofish? ;-) +16:43 <@jrand0m> no, prolly aes, unless someone has a really good reason +16:43 <@hezekiah> jrand0m: Was that yes to both questions, or just +question 1? +16:43 -!- nemesis [nemesis@anon.iip] has joined #iip-dev +16:43 <@hezekiah> OK. +16:43 <@jrand0m> hezekiah> yes to both +16:43 <@nop> well +16:43 < nemesis> uuuh, since when there are here ops? :) +16:43 <@hezekiah> I really like twofish, but unfortunately AES is easier +to find a good lib for. +16:44 <@nop> hold +16:44 <@hezekiah> nemesis: The English structure of that sentence was +too garbled for me to decipher? Whould you like to restate your +question? +16:44 <@jrand0m> whats special about twofish? why not go with the +advanced encryption Standard? +16:44 <@hezekiah> nop: Holding ... :) +16:44 * jrand0m holds +16:44 <@nop> I prefer that we have a suite of encryption options +16:44 <@nop> not just aes +16:44 <@nop> there are opinions about AES that some people do not feel +comfortable using +16:44 <@nop> and would rather go with Twofish etc +16:44 <@nop> so maybe we can have it be a selection +16:44 < wilde> do both :) +16:44 <@nop> yes +16:44 <@nop> wilde: exactly +16:45 <@jrand0m> nop> suites would mean not everyone can send messages +to everyone +16:45 < jeremiah> but then wouldn't each router have to support both? +that seems painful +16:45 <@jrand0m> doing both is definitely the case for transport layer, +where things can be negotiated +16:45 <@nop> not really +16:45 <@nop> I would not agree with AES then +16:45 <@nop> as if you are paranoid +16:45 <@hezekiah> Right. But let's try to too enclude things that are +weakening like 3DES. +16:45 <@hezekiah> A chain is only as strong as its weakest link. +16:45 <@nop> then you'll realize why +16:45 <@nop> with the US gov't approvals +16:46 <@jrand0m> I don't support AES because it has govt approval, I +support AES because it has cryptographers, scientists, and +mathematicians approvals. +16:46 <@jrand0m> if there is a better one, we can go with that. +16:46 <@jrand0m> but I don't want to go with something because its +different +16:46 <@nop> but the approval of twofish is strong as well amongst +cryptographers +16:46 <@hezekiah> Well, the last three AES candidates were Rijndael, +Twofish, and Serpent. +16:46 <@nop> exactly +16:47 <@hezekiah> Rijndael was the fastest. +16:47 <@hezekiah> Personally, I have more faith in Twofish than +Rijndael. +16:47 <@jrand0m> nop I think I heard you say there were problems with +serpent? +16:47 < wilde> use multiple layers of encryption if you have CPU for it +16:48 <@jrand0m> wilde> there will be, but thats on a different aspect +of things. +16:48 <@nop> all I'm saying is that we could have both supported +16:48 <@nop> doesn't hurt +16:48 <@jrand0m> actually it does hurt +16:48 <@jrand0m> segmentation attack +16:48 < wilde> ok twofish wrapped in AES could be overkill +16:48 <@nop> haha +16:48 <@nop> not twofish wrapped in AES +16:49 < jeremiah> should we standardize each transport as having one +specific set of characteristics (network setup, encryption)? +16:49 <@nop> alright for the sake of argument +16:49 <@nop> let's do rijndael for this part +16:49 < jeremiah> and then we could have one TCP transport supporting +AES, one with Twofish, but not one that has to juggle both? +16:49 <@jrand0m> jeremiah> yes, particular transports will have +particular characteristics, but we're covering the end to end message +crypto done in the api atm +16:49 <@nop> let's do end to end AES +16:49 < jeremiah> jrand0m: ah +16:49 <@nop> then node to node twofish option +16:50 <@nop> and if you can, do AES-counter mode +16:50 <@jrand0m> 'k, sounds good. we can always change later on before +release (during peer review, etc) +16:50 < wilde> but all crypto algorithms have failed in the past, using +double encryption would at least buy time in case of a crypto +breakthrough +16:50 < jeremiah> not really +16:50 <@jrand0m> wilde> the truly paranoid can encrypt with their own +system prior to sending messages over the I2P network +16:50 <@hezekiah> wilde: If one algorithm is found to be weak, we'll +replace it. +16:51 <@jrand0m> I2P will just transparently encrypt +16:51 < wilde> jrand0m: yes, you're right, there should be a limit to +paranoia +16:52 <@nop> yes +16:52 <@nop> we could go on all day +16:52 <@nop> arguing about it +16:52 <@nop> AES end to end +16:52 <@jrand0m> ok, I don't have anything else on I2P stuff +16:52 <@nop> Twofish and others node to node +16:52 <@jrand0m> coo' +16:53 <@jrand0m> any other I2P stuff, or are we on the next agenda item? +16:54 <@hezekiah> I'm done. :) +16:54 < wilde> what about A2A, anonymous 2 anonymous? +16:54 <@hezekiah> I +16:55 <@hezekiah> I've never heard of that. What are you talking about, +wilde? +16:55 <@jrand0m> I2P is anonymous to anonymous communication +16:55 <@jrand0m> I2P = "Invisible Internet Project" +16:55 < nemesis> jrand0m: can you send the roadmap as an attechment, and +not as inline? +16:55 <@jrand0m> (dont make us say I^2P) +16:55 <@nop> hushmail has an encrypted messenger +16:55 <@nop> neat +16:56 <@jrand0m> nemesis> hmm, I tried to - hushmail said it was +attached :/ +16:56 <@hezekiah> nemesis: I got it as attached. +16:56 <@jrand0m> nemesis> you can d/l from +http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/290 +16:56 < nemesis> i'm sorry, i can't copy&paste it +16:56 <@hezekiah> nemesis: Perhaps your mail reader is the problem? (He +sent it as a zip file.) +16:56 < nemesis> its inline +16:56 < nemesis> theres a zip file... +16:56 -!- UserX [~User@anon.iip] has joined #iip-dev +16:57 <@jrand0m> 'lo userx +16:57 < nemesis> -Hush_boundarfy-31fda3d62329b +16:57 <@nop> did anyone log this +16:57 < nemesis> Content-Transfer-Encoding: base64 +16:57 <@hezekiah> cohesion was supposed to. +16:57 <@jrand0m> I log all IRC +16:57 <@cohesion> i have it all +16:57 < thecrypto> yes +16:57 <@jrand0m> word +16:58 < Zwolly> my ISP also logs all the IRC chatting so what is new +16:58 <@jrand0m> lol Zwolly +16:58 < Zwolly> hehe +16:59 <@hezekiah> Zwolly: Your ISP won't have logs of this. :) +16:59 < Zwolly> i hope not if so you guys do a louzy job +16:59 <@hezekiah> lol +17:00 <@hezekiah> So, I'm assuming we move on to the next agenda item +now since we've stopped talking about i2p for a while. +17:00 <@nop> yes +17:00 <@nop> comments +17:00 <@nop> suggestions +17:01 <@jrand0m> we, should, like, do some drugs, man +17:01 <@hezekiah> jrand0m: Sorry. I refuse to ruin a good mind with such +substances. +17:01 < wilde> question: isn't the release plan a bit optimistic= +17:01 < wilde> ? +17:02 <@hezekiah> wilde: lol. Well, my term would be 'insane'. But I +think it might be feasible. +17:02 <@jrand0m> wilde> good question. it should be plausible, and if +any devs on there want to adjust tasks they are working on, we will. +17:03 < thecrypto> we can do it! +17:04 <@jrand0m> go TEAM! +17:04 < wilde> aim high that's good, but it should be realistic +17:04 < wilde> do you guys have time enough for the actual programming? +17:04 * jrand0m quit his job to work on this, and a few people have +summer break coming up +17:05 < wilde> i mean september-october that's like 60-90 days +17:05 < wilde> ok that's sounds good +17:05 <@jrand0m> but don't believe us. we'll release when its ready. +17:05 <@hezekiah> jrand0m: BTW, since you quit your job, how are you +going to eat while you code this? +17:05 < jeremiah> wilde: we're going to be implementing lots of it in +high-level languages and then re-coding in C later +17:05 <@jrand0m> hezekiah> I eat code +17:05 <@hezekiah> I was afraid you'd say something like that. +17:06 <@jrand0m> ;) +17:06 <@hezekiah> I just hope you've got a good nest egg to live on. +17:06 < jeremiah> jrand0m: my code eats random numbers +17:06 < jeremiah> that might make a bad loop +17:06 <@hezekiah> ROTFL! +17:07 < wilde> drinking java, eating python, roasted ant, could go +17:07 <@jrand0m> but bugs have lots of protien +17:07 * jrand0m !thwaps self +17:07 <@jrand0m> ok, do we have other questions / comments / +suggestions? +17:07 <@hezekiah> Well, I've got to go now. +17:07 <@hezekiah> Bye everyone. :) +17:07 <@jrand0m> or are we actually finishing up in under an hour? +17:07 -!- hezekiah [hezekiah@anon.iip] has quit [Client exiting] +17:07 <@jrand0m> lol wilde +17:08 <@jrand0m> nop> got anything or we done? +17:10 -!- UserX [~User@anon.iip] has quit [Ping timeout] +17:10 -!- wilde [anon@anon.iip] has quit [] +17:10 <@cohesion> ok, i'm ending the meeting +17:11 < nemesis> STOP! +17:11 <@cohesion> nop: i'll get with you about CVS tomarrow +17:11 * jrand0m stops +17:11 < nemesis> ganttproject-1.9.7.jar +17:11 <@cohesion> GO! +17:11 < nemesis> how it works? +17:11 <@nop> ok +17:11 <@nop> also +17:11 <@nop> aes +17:11 <@jrand0m> nemesis> just double click on it with java 1.4.2 +installed +17:11 <@nop> we should use 256 bit as a norm +17:11 < nemesis> i have java 1.4.2... +17:11 <@jrand0m> nemesis> I'll email out the xml with the project info +17:12 <@jrand0m> word nop, definitely +17:13 < nemesis> Could not find the main class. Program will exit! +17:13 < nemesis> hm.. i think my java are broken.... Title of the +Window: Java Virtual Machine Launcher... +17:14 <@jrand0m> weird nemesis, works for me... make sure its loading it +with the 1.4.2 jvm and not the windows jvm +17:14 <@jrand0m> ah, try running from the cmd.exe command line +17:14 < nemesis> eh? +17:14 < nemesis> k +17:14 < nemesis> then i write a .bat for it, like for columba :) +17:14 <@cohesion> ok, i'm closing the logs +17:14 <@jrand0m> (and type java -version first to make sure it uses the +right one) +17:14 <@jrand0m> heh word +17:14 <@cohesion> everyone say "cheese" +17:14 <@jrand0m> queso +17:14 < thecrypto> cheese +17:15 < Zwolly> chesse +17:15 < Zwolly> cheese +17:15 < nemesis> E:\Sytemprogramme\server\Projektverwaltung>java +ganttproject-1.9.7.jar +17:15 < nemesis> Exception in thread "main" +java.lang.NoClassDefFoundError: ganttproject-1/9/7/ja +17:15 < nemesis> r +17:16 <@jrand0m> java -jar ganttproject-1.9.7.jar +17:16 < nemesis> java version "1.4.2-beta" +17:16 < nemesis> Java(TM) 2 Runtime Environment, Standard Edition (build +1.4.2-beta-b19) +17:16 < nemesis> Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed +mode) +17:16 < nemesis> hm... why with -jar? +17:16 < nemesis> now it works... +17:17 -!- ion [ion@anon.iip] has quit [Ping timeout] +17:17 < nemesis> thx jrand0m +17:17 <@jrand0m> without -jar asks it to load the class +ganttproject-1/9/7/jar +17:17 <@jrand0m> np +17:17 < jeremiah> is cvs working? +17:17 < jeremiah> i checked out earlier today, but it's weird now +17:17 <@jrand0m> sourceforge is being a pain atm +--- Log closed Tue Jul 22 17:18:14 2003 diff --git a/i2p2www/meetings/logs/50.rst b/i2p2www/meetings/logs/50.rst new file mode 100644 index 00000000..acc21b45 --- /dev/null +++ b/i2p2www/meetings/logs/50.rst @@ -0,0 +1,7 @@ +I2P dev meeting, July 22, 2003 +============================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/51.log b/i2p2www/meetings/logs/51.log new file mode 100644 index 00000000..4307e81b --- /dev/null +++ b/i2p2www/meetings/logs/51.log @@ -0,0 +1,881 @@ +--- Log opened Tue Jul 29 16:54:31 2003 +17:11 <@hezekiah> Tue Jul 29 21:11:18 UTC 2003 +17:11 <@hezekiah> The 51th (I think) iip-dev meeting. +17:11 <@hezekiah> Agenda: +17:11 <@hezekiah> 1.) Welcome +17:11 <@hezekiah> 2.) jrand0m's stuff +17:11 <@hezekiah> 3.) Any of the other developer's stuff +17:11 <@hezekiah> 4.) Anything nop adds when/if he gets here +17:12 <@hezekiah> 5.) Questions and Comments from the ever eager unwashed + masses. ;-) +17:12 <@hezekiah> OK! +17:12 <@hezekiah> Welcome everyone to the 51th (I think) iip-dev meeting +17:12 <@hezekiah> Item number 2! +17:12 <@hezekiah> jrand0m's stuff +17:12 -!- thetower [none@anon.iip] has joined #iip-dev +17:12 * hezekiah hands the mike to jrand0m +17:12 <@jrand0m> sub-agenda: +17:12 <@jrand0m> 2.1) I2CP spec & dev status +17:12 < co> Where are the logs for meeting 50? +17:12 <@jrand0m> 2.2) SDK plans +17:12 <@jrand0m> 2.3) crypto +17:12 <@jrand0m> 2.4) roadmap / network proto status +17:13 <@hezekiah> co: cohesion is working on getting them up +17:13 <@jrand0m> (btw, its "mic", for microphone) +17:13 <@hezekiah> jrand0m: Sorry. :) +17:13 <@hezekiah> jrand0m: (And this mistake from a sound tech guy!) +17:13 -!- luckypunk [~yetalohe@anon.iip] has joined #iip-dev +17:13 -!- odargur [odargur@anon.iip] has joined #iip-dev +17:13 <@jrand0m> 2.1) I2CP: the spec is committed to CVS with a slight mod + to one of the messages (MessageStatusMessage) +17:14 <@jrand0m> Comments are always welcome on I2CP, but the sooner the + better. +17:14 <@hezekiah> jrand0m: Where's the spec in CVS? ... and is it on the SF + CVS too? +17:14 <@jrand0m> The reason for sooner the better is that we'll have a + working Java client implementation by friday. +17:14 -!- some_random_guy [~dan@anon.iip] has joined #iip-dev +17:14 * thecrypto crosses fingers on that one +17:14 <@jrand0m> Plus a local only router by the end of the weekend, I'm hoping +17:15 <@jrand0m> no hez, only on the cathedral +17:15 <@jrand0m> good point thecrypto. +17:15 <@jrand0m> Caveat: +17:15 <@hezekiah> Ugh. I still can't get CVS to work with cathedral. +17:15 <@jrand0m> some crypto isn't 100%, but its all stub'ed to let us plug + in more complete or other implementations later +17:15 <@jrand0m> hezekiah> we'll get you up after the meeting. +17:15 <@hezekiah> jrand0m: Thanks. :) +17:16 <@jrand0m> the spec is in the + i2p/doc/specs/data_structure_spec/datastructures.html +17:16 <@jrand0m> thecrypto> do you have anything to add re: java impl? +17:16 -!- ArdVark [simple1@anon.iip] has joined #iip-dev +17:16 <@jeremiah> the local-only router you mentioned was the python one, + right? or is there a java one too? +17:17 <@jrand0m> that all depends :) +17:17 <@jrand0m> jeremiah/hezekiah> how goes the python client and local-only + router? +17:17 <@thecrypto> not really, except for the crypto issue i think we'll + talk about in a bit +17:17 <@jrand0m> word thecrypto. +17:17 <@hezekiah> jrand0m: It's coming. I finally got the TCP transport + stuff working yesterday. +17:17 <@jeremiah> it seems ok, i think most of it will be dependent on + hezekiah's dev speed more than mine +17:17 <@hezekiah> jrand0m: Jeremiah has some nice stuff going with the + message strcutures. +17:18 <@hezekiah> hezekiah: I'm hoping that we can make the deadline. +17:18 <@jrand0m> cool. +17:18 <@jeremiah> also... friday is my birthday, so I plan on not being + around the computer then +17:18 <@hezekiah> jeremiah: Understandable. :) +17:18 <@hezekiah> jeremiah: And happy birthday in advance. :) +17:18 <@jeremiah> thanks +17:18 <@jrand0m> jumping slightly to agenda 2.4> when would we expect to be + able to have the python local only router? realistically? +17:19 <@jrand0m> word, if you code on friday I'll kick your ass +17:19 <@jrand0m> virtually, at least +17:19 <@hezekiah> jrand0m: I thought that's what I'm coding. The Python + local only router. +17:19 <@jrand0m> si, that you are +17:19 <@hezekiah> Well the deadline is August 1st. +17:19 <@jeremiah> right now we're working on message to-from binary format + stuff +17:19 <@hezekiah> That's not that hard. +17:19 <@jeremiah> right +17:19 <@hezekiah> I'm hoping to have that done in a day or two. +17:20 <@jrand0m> thats friday :) +17:20 <@jrand0m> awesome +17:20 <@hezekiah> I hope it will be done by August 1st. Realistically it + might be a few days late, but I hope not. +17:20 <@jrand0m> 'k, I'll hold off on touching any java local only stuff + then and work on the network spec after the java client api is set. +17:20 <@hezekiah> Yes. Specs are good. +17:21 <@hezekiah> They make my job a LOT easier! :) +17:21 <@jrand0m> word. +17:21 <@jrand0m> I'll write up a quick 2 paragraph run through of the java + I2CP test harness too +17:21 <@jrand0m> I'll get that out tonight +17:22 <@hezekiah> jrand0m: I love how you get these specs written so fast. +17:22 <@hezekiah> This is fun. :) +17:22 <@jrand0m> Ok, hez/jeremiah/thecrypto> anything else on I2CP? +17:22 <@jrand0m> lol +17:22 -!- dm [~hifi@anon.iip] has joined #iip-dev +17:22 <@hezekiah> Um ... +17:22 <@hezekiah> I want the crypto spec! +17:22 < dm> welcome +17:22 * hezekiah pouts like a baby +17:22 <@hezekiah> ;-) +17:23 <@hezekiah> Seriously, ... I can't think of anything. +17:23 <@jrand0m> thats agenda item 2.3 +17:23 <@thecrypto> still waiting for 2.3 to come up +17:23 <@hezekiah> If I do, I'll just come online and pester you with questions, + jrand0m. :) +17:23 <@jrand0m> word. +17:23 <@jrand0m> ok. 2.2) SDK plans +17:23 <@hezekiah> What agenda point did we just finish? +17:23 <@hezekiah> 2.4? +17:23 <@hezekiah> And have we finished 2.1 yet? +17:23 <@jrand0m> 2.1 +17:24 <@jrand0m> now 2.2> the SDK +17:24 <@hezekiah> OK. +17:24 < dm> agenda has decimal point in it now? I see progress already. +17:24 <@hezekiah> I'm found now (as opposed to lost). +17:24 <@thecrypto> we might have 2 decimal points :) +17:25 <@jeremiah> what makes up the SDK apart from the various APIs? +17:25 <@jrand0m> the SDK is: the client API (as many as we have available), the + local only router, a trivial sample app, and some docs on how to use the APIs. +17:25 <@hezekiah> jrand0m: Would I be correct in assuming that you're writing + the docs? :) +17:26 <@jrand0m> I'd like to have the SDK released asap, so that 3rd (or + even 2nd or 1st) party developers can write and test applications that will + run over I2P, so once the network is operational, we'll hit the ground running. +17:26 <@jrand0m> hezekiah> I'd actually prefer not to. +17:26 <@jrand0m> hezekiah> and I say that not because I don't want to document, + but because I'm too close to it. +17:26 <@hezekiah> jrand0m: OK. +17:26 <@jrand0m> we should have somone who *doesn't* actually implement the + code write that doc, so it can be understandable to people who didn't write + the I2CP spec +17:26 <@hezekiah> jrand0m: We'll cross that bridge when we get there. +17:26 <@jrand0m> but if need be, I'll jump on it. +17:26 <@jrand0m> word. +17:27 < dm> what incentive do people have to write apps without an operational + network, and how would they even test their app. +17:27 <@hezekiah> jrand0m: Or why don't someone who designed the protocol + write it, and then have someone who never worked with it go over it until + it makes sense? +17:27 <@jrand0m> Ok, there has been some discussion of a simple 'talk' + style app. +17:27 <@jrand0m> dm> people will be able to test with the SDK. +17:27 <@thecrypto> actully, i was wondering what would be the use of that + if it's local only +17:28 <@jeremiah> dm: the idea is to implement a simple network that isn't + fully functional but can pass messages +17:28 <@thecrypto> you'd only be able to talk to yourself +17:28 <@jeremiah> it's not actually local-only, but it only includes + client-router, not router-router code +17:28 <@jrand0m> thecrypto> you can talk to other Destinations. I2P is + location independent - local is the same as remote. +17:29 <@thecrypto> okay +17:29 < dm> nice and all, I just don't see anyone (besides you 3-4) writing + anything if you can only test locally. But anyway, doesn't matter. +17:29 <@jrand0m> so a talk app can open up two instances of the application + and talk to oneself, etc +17:30 <@thecrypto> but when we add the remote stuff, the app should just work +17:30 <@jrand0m> dm> right, this is just a prereq for having other people + write apps. +17:30 <@jrand0m> exactly. +17:30 <@jrand0m> the app will work with absolutely NO changes +17:30 < co> dm: This is a test application. Once the router-router code is + written, you will be able to talk to others. +17:30 <@jeremiah> having local-only just lets us develop in parallel +17:30 < dm> yes, but if the app assumes 10 ms latency, and it ends being 12 + seconds, it won't work too well :) +17:31 <@jrand0m> agreed dm +17:31 < dm> any estimates on latency btw? :) +17:31 <@jrand0m> if we have 12 second latency, we have work to do. +17:31 <@jrand0m> we won't have that though. +17:31 <@jrand0m> estimates are .6-2.7sec +17:31 <@jrand0m> for a 5,000,000 router network. +17:31 <@hezekiah> BTW, that reminds me. We need to talk about ElGamal. +17:31 <@thecrypto> the longest time is setup +17:31 <@jrand0m> (see iip-dev archives for the rudimentary models) +17:31 < dm> lower or higher for smaller networks? +17:32 <@jrand0m> hezekiah> 2.3: crypto. +17:32 <@thecrypto> after that the time the drops dramatically +17:32 <@jrand0m> dm> lower. +17:32 <@thecrypto> hezekiah: you prolly have the same question as i +17:32 <@jrand0m> thecrypto> exactly, setup time is offline for message + delivery though [aka set up tunnels prior to sending messages] +17:32 < dm> ok, just checking you ;) +17:32 <@jrand0m> heh +17:33 <@jrand0m> ok. last part of the SDK - the app +17:33 <@jrand0m> co/thecrypto: thoughts on a java talk impl? workable? + time? plans? interest? +17:34 <@thecrypto> once the API is up, we can prolly have a talk done in + about a week or so, 2 tops, co agrre? +17:34 <@jeremiah> chat could be built in as a jabber router, right? +17:34 < co> That should be fairly easy to do. +17:34 < co> thecrypto: I agree. +17:34 <@jrand0m> jeremiah> I don't know jabber, but if jabber can run over + the api, cool +17:35 <@jrand0m> word co & thecrypto +17:35 <@jrand0m> jeremiah> note that this is just a trivial app to do proof + of concept with, not a Kickass Anonymous IM System :) +17:35 <@jeremiah> not yet ;) +17:35 <@thecrypto> we can add that functionallity later +17:35 <@jeremiah> k +17:36 <@jrand0m> heh +17:36 <@thecrypto> let's start small +17:36 * jrand0m puts in the schedule "add feature: be kickass" +17:36 < some_random_guy> heh +17:36 < some_random_guy> nice feature :) +17:36 -!- dm2 [~hifi@anon.iip] has joined #iip-dev +17:37 <@jeremiah> jrand0m: I think I missed this in 2.1, but any thoughts + on kademlia as a DHT? it requires less upkeep than Chord +17:37 -!- nop [nop@anon.iip] has joined #iip-dev +17:37 < nop> sorry +17:37 <@jrand0m> plus one of these days we need to get someone on the IIP + redesign to run over this. +17:37 -!- dm [~hifi@anon.iip] has quit [Ping timeout] +17:37 < nop> what? +17:37 < nop> who +17:37 < nop> where +17:37 < nop> when +17:37 < nop> ? +17:37 -!- dm2 is now known as dm +17:37 <@jrand0m> hey, speakin of the devil +17:37 < WinBear> why? +17:37 < WinBear> nm +17:37 < nop> I'm an angel actually +17:37 <@hezekiah> lol +17:38 <@thecrypto> someone hand nop a log +17:38 < WinBear> azrel +17:38 <@jrand0m> jeremiah> kademila is a good DHT, and we will definitely + review that plus the chord/tapestry crew, along with sloppy dhts in the + network spec. +17:38 <@jeremiah> jrand0m: cool +17:38 <@hezekiah> thecrypto: I'm working on it. :) +17:38 < nop> I was hearing of one that kicks but +17:38 < nop> called chord/middle +17:38 -!- hif [~hifi@anon.iip] has joined #iip-dev +17:39 < nop> but you know who is good to talk to his brandon wiley +17:39 * jrand0m !thwaps nop +17:39 < nop> I knew that would hurt +17:39 <@hezekiah> lol +17:39 <@hezekiah> Who's Brandon Wiley? +17:39 < nop> someone I'm sure jrand0m has been in numerous discussions with +17:39 < nop> :) +17:39 < nop> someone email me a log +17:39 < dm> Brandon is jrandom's real name, busted! +17:39 <@hezekiah> I'm working on it. +17:40 <@hezekiah> Hold you horses, nop. :) +17:40 < nop> haha +17:40 < dm> Brandon Wiley is the first Freenet programmer, having +17:40 < dm> co-founded the development effort with the system's inventor, + Ian Clarke +17:40 < nop> is userx here or there +17:40 < WinBear> you can talk to my brandon wiley +17:40 <@hezekiah> OK. It's on the way ... if my mail client will cooperate + and send a 15K attachement. +17:41 <@thecrypto> we've talked alot :) +17:41 <@hezekiah> nop: UserX is niether hither or thither. +17:41 <@hezekiah> OK! +17:41 <@hezekiah> The log is sent nop! Go read. :) +17:41 <@thecrypto> and now we wait +17:41 <@jrand0m> ok, anyone have any SDK thoughts while we give nop a min + to catch up? ;) +17:41 <@hezekiah> jrand0m: Now that I've gotten that log business done + ... what's kademlia? +17:42 <@jrand0m> Yet Another Academic DHT :) +17:42 <@hezekiah> And where I can get a link to kademlia's webpage? +17:42 -!- Erazerhead [JohnDoe@anon.iip] has joined #iip-dev +17:42 <@jeremiah> http://kademlia.scs.cs.nyu.edu/ +17:42 <@hezekiah> Thanks. :) +17:42 <@thecrypto> YAADHT? +17:42 <@hezekiah> lol +17:42 <@hezekiah> Names these days ... I tell ya'! +17:43 <@jrand0m> and if there's ever any CS stuff mentioned that you don't + understand, go to citeseer.nj.nec.com/cs +17:43 < WinBear> klamidia? +17:43 <@hezekiah> OK. +17:43 < nop> jrand0m: I was just about to say citeseer +17:43 < dm> what's the ETA on the SDK? +17:44 * jrand0m avoids injecting the clap into I2P +17:44 * jrand0m hopes the SDK will be out next week. perhaps next friday? +17:44 * thecrypto crosses another pair of fingers +17:45 <@jrand0m> ok. moving on to 2.3) Crypto. +17:45 * hezekiah imagines thecrypto with about 13 sets of fingers crossed + ... and then realized that he must have run out by now. +17:45 <@hezekiah> Yay! +17:45 * jrand0m pokes nop to make sure he's here +17:45 <@hezekiah> Crypto! +17:45 <@hezekiah> I have something to start us off with. :) +17:46 <@thecrypto> i have something too +17:46 <@thecrypto> Dibs! :) +17:46 * jrand0m doesn.t so you two fight it out +17:46 <@hezekiah> thecrypto can go first. :) +17:46 <@jrand0m> thecrypto> speak +17:46 <@jrand0m> :) +17:46 <@thecrypto> Ok, on Elgamal +17:47 <@thecrypto> We have to figure out whether or not we have common p + and alpha +17:47 -!- some_random_guy [~dan@anon.iip] has quit [BitchX: the original + point-and-click interface.] +17:47 <@thecrypto> the problem with a common p and alpha is that we'd have + to find someway to change everyone's keys at the same time +17:48 <@jrand0m> aka: really bad. +17:48 < co> thecrypto: Sorry, what are p and alpha? +17:48 <@thecrypto> the advantage is that we can pick specially optimized + ones and the amount of data transmitted for a public key is very small +17:48 * jrand0m sees no good reason to use common p and alpha, beyond saving + a few bits +17:48 <@thecrypto> co: for all intensive purposes, special big numbers +17:49 <@jrand0m> thecrypto> we can still optimize for commonly encrypted to + destination's p and alpha +17:49 <@thecrypto> or should i go into an explaination of how elgamal workds +17:49 <@thecrypto> jrand0m: yes +17:49 < co> thecrypto: OK. +17:49 <@thecrypto> we can also have everyone have a different p and alpha +17:50 <@jeremiah> for those who are interested: + http://www.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem +17:50 <@thecrypto> this means that the amount of data transmitted is much + larger and we have to figure out how to pack it in +17:50 <@jrand0m> word, thanks jeremiah +17:50 <@jrand0m> much larger? +17:50 <@jrand0m> I thought with varying p and alpha we can use smaller p + and alpha? +17:51 <@thecrypto> instead of 160 bit numbers we are now talking 2 1024 bit + and 1 160 +17:51 <@thecrypto> or overall 2308 +17:51 <@hezekiah> 288 bytes +17:51 <@hezekiah> Big deal. +17:52 <@jrand0m> ok, thats not too bad. we've planned on 256bytes +17:52 <@hezekiah> These keys aren't transfered all that often, are they? +17:52 <@jrand0m> another 32 doesn't hurt +17:52 <@jrand0m> hezekiah> they're inserted into the DHT +17:52 <@hezekiah> Ah! +17:52 <@hezekiah> That's why we wanted it small. +17:53 <@thecrypto> also, another problem about elgamal we might also have + to worry about +17:53 <@jrand0m> well, it doesn't really hurt if the RouterInfo structure + is about 10K or so +17:53 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev +17:53 <@jrand0m> 'k, s'up thecrypto? +17:53 <@thecrypto> message expansion is 2, the size of an encryption or a + signature is twice the size of the message +17:54 <@jrand0m> ElG encryption is only of the AES key +17:54 <@jrand0m> ElG signature is only of the SHA256 hashes +17:55 <@thecrypto> okay, it's just something to bring up as well +17:55 <@hezekiah> jrand0m: Which makes me _really_ puzzled. +17:55 <@thecrypto> now back to the original issue, do we want to have a + shared p and alpha or do we want everyone to have different p and alphas? +17:55 <@jrand0m> hezekiah> hmm? you read the data structure spec for + #Payload ? +17:55 <@jrand0m> any thoughts/questions on that hezekiah? +17:55 * dm now understands how DHTs work. +17:55 <@jrand0m> nop> thoughts? +17:55 <@jrand0m> awesome dm +17:55 <@hezekiah> If a signature is twice the size of the data signed, + then why does the IC2P spec say a signature is 128 bytes? +17:56 < nop> no +17:56 < nop> shared p +17:56 <@hezekiah> Shouldn't it bee 512? +17:56 <@thecrypto> the hash of the bytes +17:56 < nop> and alphas +17:56 < dm> seems like a lot of work is required when joining a DHT, but I + guess it works. +17:56 < nop> shared base, shared p +17:56 <@jrand0m> hezekiah> bits / bytes. +17:56 < nop> this will eliminate a lot of risk +17:56 <@thecrypto> then how big do we want it? +17:56 <@hezekiah> Hmm +17:56 <@jrand0m> nop> in 3 years, will we want to have everyone change their + p and alpha at the same time? +17:56 < nop> and hold our protocol to standards +17:57 <@thecrypto> since it does open up that p and alpha huge attacks +17:57 < nop> jrand0m: there is such a thing called cooked primes, at this + time, and this is the time I'm looking at +17:57 <@thecrypto> which if completed bring the entire network down +17:57 < nop> I believe we can modify with the times +17:57 < nop> but a static oakley approved prime is advised +17:57 < nop> as they have been reviewed thoroughly as secure +17:58 < nop> and that is a better basis than any of our assumptions about + primes being generated (probable at that) +17:58 <@thecrypto> if it's not prime, encryption or signatures won't work + so we just throw it our +17:59 <@jrand0m> agreed, they have better primes. so when one of those + primes are factored, everyone using them is exposed, correct? +17:59 < dm> hmmm, I gotta go. This is logged right? +17:59 < nop> jrand0m: yes +17:59 <@thecrypto> yup +17:59 < nop> jrand0m: when that happens we'll all know +17:59 < nop> I don't want to risk prime generation +17:59 -!- dm [~hifi@anon.iip] has quit [it better be] +17:59 <@thecrypto> how will we know? +17:59 < nop> plus it adds to our calculation time +17:59 -!- hif [~hifi@anon.iip] has quit [] +17:59 < nop> thecrypto: if you use a standard defined Oakley prime set, + you will know when it's been cracked +18:00 <@thecrypto> how? +18:00 < nop> as it will be very public news +18:00 <@jrand0m> nop> we'll know unless the NSA cracks it. +18:00 < co> nop: How many of those primes are there? If not many, using them + is a risk. +18:00 <@thecrypto> yeah, passive evesdropping is still a threat +18:00 <@thecrypto> and i can make a program to generate ps and alphas and + test them in about an hour +18:00 <@jrand0m> nop> it would be very public news unless it was a threat + to national security. +18:00 < co> Wait... no, that's a stupid question. Never mind. +18:01 < nop> this is true, but I believe from numerous contacts in the + cryptography community that if it's solved it will be solved before the NSA + does it +18:01 < nop> our prime generation will not secure that either way +18:01 < nop> if they solve those primes +18:01 < nop> you may as well figure out a new algo to use +18:01 <@jrand0m> 'k. +18:02 < nop> please use static, it will relieve problems with cryptanalysis, + and reduce the risks of mistake in our crypto +18:02 <@jrand0m> I was on the fence, and I'm fine with going with shared + known good primes. +18:02 <@thecrypto> okay, then let's pick a prime then +18:02 <@jrand0m> nop> we've still got you penciled in the ganttchart for + crypto spec +18:02 <@thecrypto> and do they have generators for these primes? +18:02 < nop> yes +18:02 < nop> yes I do +18:03 < nop> 2 +18:03 < nop> that is a primitive root of the primes I will have +18:03 < nop> what size primes do you guys want? +18:03 <@thecrypto> i'm thinking somewhere between 2048-4096 +18:03 <@hezekiah> We're using a 2048 key, right? +18:03 < nop> yes, so use a 4096 or higher prime +18:04 <@thecrypto> because the sharedness means we're out in the open +18:04 <@thecrypto> and if this takes off, it would be a very valuble prime + to break +18:04 * cohesion missed the meeting +18:04 < co> You are using this prime within ElGamal, though, right? +18:04 <@hezekiah> So the keys will be 4096 bits? +18:04 <@cohesion> did someone log? +18:04 < nop> co yes +18:04 < nop> no hezekiah +18:04 < nop> the keys will be 2048 +18:04 <@cohesion> ok +18:04 < nop> the prime will be higher than 4096 +18:04 * cohesion goes back to his work +18:04 <@hezekiah> OK. Please forgive my horribe understanding here. :) +18:04 < nop> brb +18:05 <@thecrypto> p and alpha can be fixed, alpha will be 2 and p will be + the prime we pick +18:05 < nop> ok, let me email the prime candidates +18:05 < nop> give me a couple of hours I have some work to do +18:05 * jeremiah wanders to dinner, will read logs later +18:05 <@thecrypto> the serect key is a, a number between 0 and p - 2 +18:05 <@thecrypto> the public key is 2^a mod p +18:06 < nop> can we move to next topic and come back so I can be here for + that, I'll be right back, at work and have to do a task real quick +18:06 <@hezekiah> OK, so you call my 'x' as 'a' +18:06 <@hezekiah> ... and my 'g' as 'alpha'. +18:06 < nop> please move the algo talk explanations to a private message +18:06 <@hezekiah> thecrypto: Right? +18:06 <@thecrypto> yes +18:06 <@jrand0m> ok. so thecrypto, nop, and hezekiah will work out the + details of the algo later. +18:06 < nop> ok +18:06 < nop> for sure +18:06 <@hezekiah> OK ... so thecrypto, are you done with your question? +18:06 <@thecrypto> so let's move on +18:06 < nop> I'll email our primes +18:06 <@thecrypto> ye +18:06 <@thecrypto> s +18:06 <@hezekiah> OK. My turn! :) +18:07 <@hezekiah> Why on earth are we using ElGamal for signing? +18:07 <@jrand0m> ok. 2.4) roadmap / network proto status +18:07 <@jrand0m> not yet hez :) +18:07 <@jrand0m> oh hez +18:07 <@hezekiah> When do I get to ask it? +18:07 -!- dm [~hifi@anon.iip] has joined #iip-dev +18:07 <@jrand0m> what would you recommend, when we have ElG public keys? +18:07 <@thecrypto> when nop gets back +18:07 <@jrand0m> no, you're right, I'm wrong. now is the right time. +18:07 < co> Next topic, please. +18:07 <@hezekiah> jrand0m: Well, the problem is this: +18:07 <@hezekiah> speed +18:08 <@hezekiah> I was playing around with the crypto stuff today, and got + a nasty shock. +18:08 <@hezekiah> ElGamal was _astronomically_ slower at verifying a signature + than DSA or RSA. +18:08 <@jrand0m> hezekiah> is that a library implementation problem or + the algorithm? +18:08 <@hezekiah> I don't know. +18:09 <@hezekiah> But I checked Applied Crypto and saw that at least _part_ + of the problem is with ElGamal. +18:09 <@hezekiah> AC has tables of the amount of time it takes for signing + and verification for DSA, RSA, and ElGamal. +18:09 <@jrand0m> so are you suggesting we go to RSA for encryption, decryption, + and signing? +18:09 <@hezekiah> I +18:09 <@hezekiah> I'm not really suggesting much that's definate. +18:09 <@jrand0m> ...though we *could* add a second signing public key to + the RouterInfo structure +18:10 <@hezekiah> I'm just saying, that AC lists ElGamal verification at +9.30 seconds. +18:10 <@hezekiah> RSA is 0.08 seconds +18:10 <@thecrypto> for 1024 bits +18:10 <@jrand0m> damn. +18:10 <@hezekiah> DSA is 1.27 seconds +18:10 <@hezekiah> Now you see my problem. +18:10 <@hezekiah> ElGamal is dirt slow ... +18:10 <@jrand0m> we need sub <100ms verification. +18:10 <@jrand0m> if not sub <10ms +18:10 <@hezekiah> ... and my CPU is 333MHz. +18:11 <@hezekiah> BTW, these calculations were done on a SPARC II +18:11 <@hezekiah> I've got an AMD K6-2 333MHz. +18:11 <@jrand0m> a sparc 2 is a 40Mhz machine. +18:11 <@hezekiah> Verifying an ElGamal sig with my Python module (which uses + a C backend but smells a little fishy). +18:11 < luckypunk> god +18:11 < luckypunk> well +18:11 <@hezekiah> jrand0m: OK. I have no clue about SPARC's. +18:11 <@hezekiah> Anyway, it took about 20 seconds. +18:12 <@hezekiah> If not a little more. +18:12 < luckypunk> anyone with a 1 ghz -2 ghz proc doesn't need to worry. +18:12 < co> hezekiah: On modern computers, then, the verification should be + acceptably fast. +18:12 <@hezekiah> DSA and RSA were nearly instantainious. +18:12 <@jrand0m> hezekiah> I do. sparc 2 was fast in '92 +18:12 <@hezekiah> Anyway, that's why I bring all this up. +18:12 <@hezekiah> We could add a DSA key, but that would meen 2 keys +18:12 <@thecrypto> we should still wonder about people who don't have the + uber fast machines +18:12 <@hezekiah> Or we could go with RSA. +18:12 <@jrand0m> my memory of our rationale for ElG as opposed to RSA was + the preference was not very strong. +18:13 <@hezekiah> Or we can live with the long verification time and use ElG. +18:13 <@jrand0m> thecrypto> absolutely. +18:13 <@thecrypto> nop was the one to say, let's use elgamal +18:13 <@hezekiah> thecrypto: Precisely. Mom and Pop will eventually be + transparently using I2P. +18:13 <@jrand0m> we're going to want bootable distros for 386s, as well as + in-applet implementations. +18:13 <@hezekiah> Mom and Pop won't have state of the art hardware. +18:13 < luckypunk> oh god +18:14 < luckypunk> everyone who would want this has at least a p100 or so. +18:14 < co> Let's not compromise security by choosing a weaker algorithm + that is faster. +18:14 <@hezekiah> co: I'm not suggesting we do. +18:14 <@thecrypto> elgamal and DSA are equivilent +18:14 <@jrand0m> ok. so we're going to revisit the RSA/ElG choice. the code + changes shouldn't be a problem. +18:14 < luckypunk> they can suffer. +18:14 <@hezekiah> co: RSA and DSA are just as reputable as ElGamal. +18:14 < luckypunk> lol +18:14 < luckypunk> if you're concerned about anonyminity +18:14 <@hezekiah> thecrypto: And nothing could be farther from the truth. +18:14 < luckypunk> you won't care about speed too much. +18:14 <@thecrypto> hezekiah: they are both implementations of the same + general algorithim +18:14 < dm> the obvious step here is for someone to figure out for certain + what the CPU usages for the two are :) +18:14 <@jrand0m> luckypunk> you listen to the complaints wrt freenet much? +18:15 <@hezekiah> thecrypto: DSA can't encrypt. It's only a sig algo, and + it's a lot faster than ElG. +18:15 <@thecrypto> hezekiah: it just happens that the signing and verification + equations for DSA are faster +18:15 <@jrand0m> dm> if Applied Crypto benchmarked RSA verification at +1/100th ElG, thats enough for me. +18:15 <@thecrypto> we can use ElG for encryption/decryption and DSA for + signing/verification +18:15 <@jrand0m> the options are go to RSA or add a DSA key (~256bytes more) + to the RouterInfo structure +18:15 <@hezekiah> Right. But now the DHT has 2 public keys in it. +18:16 <@jrand0m> so? +18:16 < co> Let's have one public key. That will be less confusing. +18:16 <@hezekiah> co: It would only be 'confusing' for developers ... and + we need to know what we're doing. :) +18:16 <@thecrypto> i think it's time to wait for nop on this one too +18:16 <@hezekiah> Right. +18:16 <@jrand0m> but if its 100times a slow... +18:16 <@jrand0m> anyway, we'll continue the crypto design discussion offline. +18:17 <@hezekiah> jrand0m: Email the mailing list, will ya'? +18:17 < luckypunk> jrand0m: god, i don't mind, if you cant wait 40 sseconds + for your page to load, fuck off. +18:17 <@thecrypto> or after the main part of the meeting +18:17 <@jrand0m> shit, I email the list daily :) +18:17 <@jrand0m> heh lucky +18:17 -!- hif [~hifi@anon.iip] has joined #iip-dev +18:17 <@jrand0m> right. +18:17 <@jrand0m> ok> 2.4) roadmap / network proto status +18:17 -!- hif is now known as dm2 +18:18 <@jrand0m> I have done very little wrt the network proto beyond + responding to co's messages, as I've been working on the java and I2CP. +18:18 <@jrand0m> roadmap still seems on target. +18:18 <@jrand0m> any changes to the roadmap? +18:19 <@jrand0m> ok. if there are, whenever there are, just mail the list. +18:19 <@hezekiah> Right. +18:19 -!- dm [~hifi@anon.iip] has quit [Ping timeout] +18:19 <@jrand0m> the roadmap.xml is now in the i2p cvs module + i2p/doc/projectPlan +18:19 -!- dm2 is now known as dm +18:20 <@hezekiah> jrand0m: Let me guess ... that's on cathedral too? +18:20 < nop> back +18:20 < nop> sorry bout that +18:20 <@jrand0m> ok, thats it for that (though we can come back to network + protocol questions in the questions section). +18:20 <@jrand0m> I have no more subitems +18:20 <@jrand0m> hezekiah> I don't use sf +18:20 <@thecrypto> well, now that nop is back we can go back to the speed + issue quickly +18:20 <@hezekiah> Right. +18:21 < nop> which speed issue +18:21 <@thecrypto> Elgamal is slow to verify +18:21 < nop> that's true +18:21 < nop> but so is rsa +18:21 <@jrand0m> nop> Applied Crypto benchmarked RSA verification at 1/100th + ElG for signing. +18:21 < nop> hmm +18:22 <@hezekiah> RSA and DSA are instantanious for me. +18:22 <@hezekiah> ElG takes 20 seconds. +18:22 < nop> DSA is el gamal +18:22 <@jrand0m> So we can either jump to RSA or add a DSA key to the + RouterInfo structure +18:22 < nop> DSA +18:22 < nop> I have anything with R's in it +18:22 < nop> ;) +18:22 * jrand0m doesn't remember a really strong reason for ElG as opposed + to RSA +18:22 * jrand0m resents that +18:22 <@hezekiah> nop: Will you enlighten us? Why don't we use RSA? +18:23 <@hezekiah> In all the gory detials. :) +18:23 < nop> for the reasons of this, and it's debatable, but +18:23 < dm> someone msg me the URL to the iip-dev again when you get a chance. +18:23 < nop> factoring primes is how to solve RSA +18:23 < dm> iip-dev list that is. +18:23 < luckypunk> RSA has been cracked. +18:23 < luckypunk> practically. +18:23 < nop> yes, 512 bit RSA has been cracked +18:23 < luckypunk> or was it DES? +18:23 < luckypunk> bah. +18:23 <@hezekiah> DES has been cracked. +18:23 < nop> it was DES I think you're talking about +18:23 < co> luckypunk: Keys of certain size have been cracked. +18:23 <@hezekiah> RSA is not quite there yet. +18:24 < nop> anyway +18:24 < luckypunk> but it might. +18:24 < nop> back to my point +18:24 <@hezekiah> But the question is: is a 2048 or 4096 RSA key secure today? +18:24 <@thecrypto> hold one second +18:24 < nop> 512 bit RSA keys have been cracked with office computers +18:24 <@jrand0m> we're looking at 2048bit RSA or ElG +18:24 < nop> hezekiah: it would be, but here's the fun part +18:24 < nop> if you can factor primes +18:24 < nop> you can crack RSA +18:24 < nop> if you can compute discrete logarithms you can solve RSA and + EL gamal +18:24 < nop> we're closer to factoring +18:24 < nop> than we are with computing discrete logs +18:24 < nop> at this time +18:24 < luckypunk> isn't discrete logs a bit harder? +18:25 <@hezekiah> If you can factor primes _quickly_ you can crack RSA. +18:25 <@hezekiah> luckypunk: That's what nop's saying. +18:25 < luckypunk> quantum computers. +18:25 < luckypunk> are damned near to functional. +18:25 <@hezekiah> lol +18:25 < nop> and the ratio of bit sizes for pub keys for discrete logs is + stronger than RSA's keys +18:25 < nop> for instance 768 bit key is not advised by diffie-hellman + variants, but it has not been provably cracked +18:25 <@hezekiah> So, the end of it is that we add a DSA key. +18:25 <@thecrypto> nop, don't do a bill gates, it's factor large n where n = pq +18:25 < nop> as 512 bit RSA keys have +18:25 <@thecrypto> since factoring prime numbers is easy +18:25 < nop> thnx +18:25 < nop> sorry +18:25 <@jrand0m> hezekiah> thats what its looking like. +18:26 < nop> I was trying to let everyone understand +18:26 < nop> sorry +18:26 <@thecrypto> just a bit of a clarification +18:26 <@jrand0m> word nop, thats cool, gracias +18:26 <@hezekiah> OK. +18:26 < nop> so DSA +18:26 < nop> then +18:26 <@hezekiah> So we're adding a DSA key? +18:26 < nop> which is a diffie-hellman variant as well +18:26 <@jrand0m> ok, given that, we'll continue crypto details offline. +18:26 < nop> I'm in favor of logs over factors +18:27 < nop> ;) +18:27 <@hezekiah> BTW, what do we still need to continue? +18:27 < co> dm: That URL is + http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel +18:27 <@thecrypto> hezekiah: picking the magic prime +18:27 <@hezekiah> Oh, right! +18:27 < dm> thanks co, I found jrand0m's specs. Now all I need is a printer + with lots of toner. +18:27 < nop> I'll send that out +18:27 <@jrand0m> hezekiah> update the data structure spec, add info wrt the + DSA, specify key size for dsa, etc. +18:27 < nop> let's do that offline +18:27 <@jrand0m> lol dm. +18:28 <@hezekiah> OK, so do you have anything left, jrand0m? +18:28 <@jrand0m> ok, I'm done with my stuff. hezekiah> you had # 3? +18:28 <@hezekiah> Yeah. +18:28 < dm> hmmm. pictures are not showing up. +18:28 <@hezekiah> 3.) Whatever nop wants to add to the agenda. + +18:28 < dm> jrand0m: is there a place to get the 'I2P Network Spec Draft +2003.07.23' with pictures included? +18:29 < co> dm: Yes, I have had that problem, too. +18:29 <@jrand0m> dm/co> get the first rev of the network spec (two weeks + prior in the zip), which includes the png. +18:30 <@jrand0m> (its in cvs too, but thats not anon/public yet) +18:30 < arj> when will it be? :) +18:30 <@hezekiah> Wow! +18:30 <@hezekiah> CVS is fast now! +18:31 <@jrand0m> arj> we're doing our best to avoid hype, so once its ready + we're going to put things public, but keep it largely quiet until. +18:31 < nop> hezekiah: what the cathedral one? +18:31 <@jrand0m> arj> however, everything we're doing is GPL, at least so far. +18:31 <@hezekiah> nop: Yeah +18:31 <@hezekiah> ! +18:31 < dm> two weeks prior in which zip? +18:31 <@jrand0m> oh word, you got it working hezekiah? +18:31 < arj> jrand0m: just wanted to read the latest specs +18:31 <@jrand0m> dm> network_spec_*.zip iirc +18:31 <@hezekiah> jrand0m: Yup! :) +18:31 < dm> same here, with pictures! +18:31 <@thecrypto> iip-dev has most of it +18:32 <@jrand0m> arj> + http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/292 has + all but one tiny change. +18:32 <@jrand0m> (well, except for the Client Access Layer, which is in a + different spec now) +18:33 < arj> ok thanx +18:33 <@jrand0m> the client access layer spec is + http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/298 +18:33 < dm> ok, and the link to the zip with the pictures? +18:33 <@jrand0m> ok. nop you have anything, or we "5) opening up to + questions/thoughts from the masses"? +18:34 -!- mihi [none@anon.iip] has quit [Ping timeout] +18:34 * jeremiah is back and has read the backlog +18:34 <@jrand0m> dm> h/o, pulling it up +18:34 <@jrand0m> + http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/269 +18:35 < dm> ty +18:35 <@jrand0m> ok, any questions / thoughts? +18:35 -!- arj [anders@anon.iip] has quit [EOF From client] +18:35 < co> yes. +18:35 <@jrand0m> np +18:35 < co> Are we on item 5 now? +18:35 * jrand0m knew you'd have some co :) +18:35 < co> Currently, communication between client and router (outgoing) + is not encrypted. +18:35 <@jrand0m> yes, since nop is slow :) +18:35 <@jrand0m> (damn people with jobs and stuff) +18:36 <@hezekiah> lol +18:36 < co> Suppose I have a trusted friend and want to use his router for + outgoing messages. +18:36 <@hezekiah> jrand0m: Well, you know. Not everyone can aford not having + a life. +18:36 <@jrand0m> co> largely correct. message payloads are encrypted, + but the rest of I2CP isn't +18:36 < co> Wouldn't that put me at risk of having my messages captured. +18:37 <@hezekiah> Yeah. They would be transfered in the clear over the wire. +18:37 <@hezekiah> Unless you ssh tunnel to his router or something. +18:37 <@jrand0m> if you have a trusted friend and connect to their router, + they can know that you sent or recieved a message, but they can't know what + you sent. +18:37 <@jeremiah> wouldn't the messages still go under public key encryption? +18:37 <@hezekiah> Oops. +18:37 <@hezekiah> My bad. +18:37 < dm> I'm gonna use I2P as a way to learn new stuff to prevent 9to5 + (windows admin, VB tools) job from turning me into a zombie. +18:37 <@jrand0m> I'm fine with adding SSL listener support, as opposed to + just TCP listener. +18:37 <@hezekiah> I forgot that clients to end to end encryption. +18:37 < co> Your assumption is that I run a local trusted router, but as + stated above, I might not want to do that so that messages would not be + connected to me. +18:37 <@jrand0m> yes jeremiah, but thats only for the payload +18:37 <@jrand0m> heh word dm +18:37 -!- mihi [none@anon.iip] has joined #iip-dev +18:38 <@jrand0m> hmm. +18:38 <@hezekiah> jrand0m: Why not add support later on for client-to-router + comm to be encrypted? +18:38 <@jrand0m> you really always should have a local trusted router. + you can have it connect to another known non-local trusted router too. +18:39 < co> True, but I would like to second hezekiah's suggestion. +18:39 <@jrand0m> hezekiah> I'm fine with adding it later (where later: + t=0...releaseDate ;) +18:40 <@jrand0m> I have absolutely no qualms with even adding support for + DH+AES for I2CP +18:40 < nop> good +18:40 <@jrand0m> actually, those features can be added on per-router basis + as well +18:41 < nop> jrand0m: also I believe the polymorphic key rotation will be + needed as well as chaffe traffic +18:41 < nop> I'm sure we're looking at that at a later meeting +18:41 < nop> just my side comment +18:41 < nop> using key sets +18:41 <@jrand0m> yes, when we touch the router-router comm. +18:41 <@jrand0m> (1-2 weeks off) +18:41 < co> nop: Currently, I don't see chaffe traffic in the spec, but it + would be good to add. +18:42 <@jrand0m> there is chaffe, in the sense that routers and tunnel + participants test themselves and their peers. +18:42 -!- arj [~anders@anon.iip] has joined #iip-dev +18:42 <@jrand0m> plus DHT requests are chaffe wrt payload messages +18:42 < nop> jrand0m: well I'll dive into some research on evading some + traffic analysis and giving away any known plaintext +18:42 <@jrand0m> *and* individual transports will have hteir own chaffe styles + (e.g. http transport will query google for "cute puppy dogs" periodically, + or whatever) +18:43 < nop> well, that chaffe is nice, but I also mean encrypted chaffe +18:43 < nop> this helps rotate the session keys +18:43 < nop> and keep your node busy even when inactive +18:43 < dm> maybe change that to hard child porn for more realistic chaffe +18:43 <@jrand0m> word. +18:43 < dm> just kidding! +18:43 <@hezekiah> dm: Good. Otherwise I'd have to !thwack you. +18:43 <@hezekiah> :) +18:44 <@jrand0m> DHT (link encrypted) and test messages (free route mix, + ala onion/garlic) won't have known plaintext problems +18:44 < nop> since newer nodes will have less traffic when starting out +18:44 <@jrand0m> plus we'll have support for constant bitrate transports +18:44 < nop> garlic rocks +18:44 < nop> :) +18:44 < nop> jrand0m: DC net style :) +18:44 * jrand0m is making some pasta w/ lots of garlic after this meeting + is over +18:45 < nop> jrand0m: I meant garlic routing +18:45 <@hezekiah> lol! +18:45 <@jrand0m> i know ;) +18:45 < nop> jrand0m: anyway, constant bitrate could be forced with the + block encryption since AES generates 128 bit blocks +18:45 < nop> ;) +18:45 < nop> so we could just pad all data to be 16 bytes per message +18:45 <@jrand0m> co> did my answers to your email make sense? +18:47 <@jrand0m> *ping* +18:47 <@hezekiah> *pong* +18:47 <@thecrypto> *pong +18:47 <@thecrypto> * +18:47 <@jrand0m> any other questions from anyone, or has my iproxy + disconnected? +18:47 <@jrand0m> heh word +18:47 <@hezekiah> thecrypto: Fragmented packet! +18:47 <@hezekiah> lol +18:48 <@thecrypto> lost that tail end there +18:48 <@thecrypto> smaller MTU here :) +18:48 <@hezekiah> jrand0m: Well, I have no questions. +18:48 < co> jrand0m: Yes, the answers made sense. +18:48 < co> I have no more questions. +18:48 < dm> I shall create questions when I read the specs tomorrow. +18:49 <@jrand0m> well, I hope you have more later :) +18:49 <@jrand0m> awesome dm +18:49 < dm> awesome initially maybe. +18:49 < dm> well, i'm off. good luck people! +18:49 -!- dm [~hifi@anon.iip] has quit [] +18:50 <@jrand0m> we *do* still have the big 2 week peer review period in + the schedule, but review before then is appreciated (even though all the + details haven't yet been put in) +18:51 <@jrand0m> ok. any other questions, or are we going to wrap up #52 + as a 102 minute meeting? +18:52 <@thecrypto> #51 +18:52 <@hezekiah> Uh, I read 1:57 minutes. +18:52 <@hezekiah> Duh. +18:52 <@hezekiah> I'm stupid +18:52 <@hezekiah> Never mind me. +18:52 <@hezekiah> I have no questions ... +18:52 <@hezekiah> Questions! +18:52 * jrand0m could never add... +18:52 <@hezekiah> Speak now or hold you peace until next Tuesday! +18:52 <@hezekiah> Going once! +18:53 <@hezekiah> ... Going twice! +18:53 <@thecrypto> Sold to the guy in a button down shirt +18:53 <@hezekiah> Gone! +18:53 * jrand0m goes to the kitchen to make some long overdue dinner +18:53 <@jrand0m> gracias srs y srtas +18:53 <@hezekiah> Goodbye everyone! +18:53 <@jeremiah> I should checkout the source before I wander off +18:53 <@hezekiah> See you next Tuesday! +--- Log closed Tue Jul 29 18:53:55 2003 diff --git a/i2p2www/meetings/logs/51.rst b/i2p2www/meetings/logs/51.rst new file mode 100644 index 00000000..73834174 --- /dev/null +++ b/i2p2www/meetings/logs/51.rst @@ -0,0 +1,7 @@ +I2P dev meeting, July 29, 2003 @ 21:11 UTC +========================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/52.log b/i2p2www/meetings/logs/52.log new file mode 100644 index 00000000..fbe15fd8 --- /dev/null +++ b/i2p2www/meetings/logs/52.log @@ -0,0 +1,376 @@ +<nop> ok, meeting started +<nop> what's on the agenda +--> logger (logger@anon.iip) has joined #iip-dev +--> Anon02 (~anon@anon.iip) has joined #iip-dev +<hezekiah> Tue Aug 5 21:03:10 UTC 2003 +<hezekiah> Welcome to the Nth iip-dev meeting. +<hezekiah> What's on the agenda? +<thecrypto> Tue Aug 5 21:02:44 UTC 2003 +<thecrypto> synced to a NTP stratum 2 :) +<hezekiah> Tue Aug 5 21:03:13 UTC 2003 +--> ptm (~ptm@anon.iip) has joined #iip-dev +<hezekiah> Just synced to NIST. :) +<mihi> this sync does not help w/ iip delays ;) +<jrand0m> nop: things I want to see covered: java dev status, java crypto + status, python dev status, sdk status, naming service +<hezekiah> (We're going into the naming service _already_?) +<jrand0m> not design you wanker, thats co's schpeel. just talk about stuff + if there's stuff to talk about. +<hezekiah> Ah +* jrand0m puts LART away +<jrand0m> anything else on the agenda? +<jrand0m> or shall we dig in? +<hezekiah> Well, I can't think of anything else to add. +<hezekiah> Ah! +<hezekiah> Oh! +<jrand0m> ok. java dev status: +<hezekiah> Good. +<-- mrflibble has quit (Ping timeout) +<nop> ok +<nop> agenda +<nop> 1) Welcome +<jrand0m> as of today, there is a java client API with a stub java router + that can talk to each other. in addition, there is an application called ATalk + allowing anonymous IM + file transfer. +<nop> 2) IIP 1.1 blackouts +<nop> 3) I2P +<nop> 4) The End with comments and stuff +* jrand0m goes back to corner +<nop> sorry + joeyo jrand0m Aug 05 17:08:24 * hezekiah gives jrand0m a dunce hat to wear in + the corner. ;-) +<nop> sorry about that +<nop> didn't see you started there +<nop> maybe I should go in corner +<hezekiah> lol +<jrand0m> no worry. item 1) +* hezekiah hands nop a dunce hat too. :) +<nop> ok welcome everybuddy +<nop> blah blah +<nop> 2) IIP 1.1 blackouts +--> mrflibble (mrflibble@anon.iip) has joined #iip-dev +<hezekiah> 52nd iip-dev meeting and all that good rot! +<nop> the server recently had some issues with the hard drive sectors and has + been replaced +<nop> I plan to be moving the darn server into a more stable environment with + redundancy +<nop> and possibly lend out control of multiple ircd servers +<nop> dunno +<nop> that's something to be discussed +<-- Anon02 has quit (EOF From client) +<nop> hopefully our servers should stay up now since the harddrive was replaced +<nop> sorry about the inconvenience folks +<nop> 3) I2P - Jrand0m take it away +<nop> come out of the corner jrand0m +* hezekiah goes over to the corner, pulls jrand0m off his chair, drags him + to the podium, takes away his dunce hat, and hands him the mic. +* nop goes into that corner to fill his place +<hezekiah> lol! +<jrand0m> sorry, back +* nop grabs dunce hat from hezekiah +* nop puts it on his head +* nop applauds for jrand0m +* jrand0m just watches the show +<jrand0m> er... um ok +<hezekiah> jrand0m: i2p, java status, etc. Talk man! +<jrand0m> so, as of today, there is a java client API with a stub java + router that can talk to each other. in addition, there is an application called + ATalk allowing anonymous IM + file transfer. +<hezekiah> File transfer already!? +<jrand0m> si sr +<hezekiah> Wow. +<hezekiah> I'm sure behind the times. +<jrand0m> but not the most graceful +<hezekiah> lol +<jrand0m> it takes a file and tosses it in a message +<hezekiah> Ouch. +<nop> how long did 1.8 mb local transfer take? +<jrand0m> I've tested with a 4K file and a 1.8Mb file +<jrand0m> a few seconds +<nop> nice +<nop> :) +<hezekiah> Does the java stuff do real encryption yet, or does it still + fake that? +<nop> fake +<nop> even I know that +<nop> :) +<jrand0m> I warmed it up by talking to myself first [e.g. one window to + another, saying hi] so it didn't deal with the overhead of the first elg +<jrand0m> right, its faked largely +<thecrypto> most of the encryption is fake +<thecrypto> that's being worked on though +<hezekiah> Of course. :) +<jrand0m> definitely. +<jrand0m> on that front, wanna give us an update thecrypto? +<thecrypto> well, right now i'm done with ElGamal and SHA256 +<thecrypto> right now I'm working on generating primes for DSA +<thecrypto> I'll send out 5 and then we can just pick one +<hezekiah> nop: Didn't you have prime(s) coming for use with DSA? +<thecrypto> We also have some benchmarks on ElGamal and SHA256 +<thecrypto> And they are all fast +<jrand0m> latest benchmarks w/ elg: +<jrand0m> Key Generation Time Average: 4437 total: 443759 min: + 872 max: 21110 Keygen/second: 0 +<jrand0m> Encryption Time Average : 356 total: 35657 min: + 431 max: 611 Encryption Bps: 179 +<jrand0m> Decryption Time Average : 983 total: 98347 min: + 881 max: 2143 Decryption Bps: 65 + +<hezekiah> min and max: are they in seconds? +<jrand0m> note that the Bps isn't really useful, as we only encrypt/decrypt + 64 bytes +<thecrypto> ms +<jrand0m> no, sorry, those are all milliseconds +<hezekiah> Cool. :) +<hezekiah> And this is done in java? +<thecrypto> yes +<thecrypto> pure java +<hezekiah> OK. I am officiall impressed. :) +<jrand0m> 100%. P4 1.8 +<thecrypto> they are about the same on my 800 Mhz +<hezekiah> How can I do the same tests? +<jrand0m> sha256 benchmark: +<jrand0m> Short Message Time Average : 0 total: 0 min: 0 max: + 0 Bps: NaN +<jrand0m> Medium Message Time Average : 1 total: 130 min: 0 max: + 10 Bps: 7876923 +<jrand0m> Long Message Time Average : 146 total: 14641 min: + 130 max: 270 Bps: 83037 +<thecrypto> run the ElGamalBench program +<hezekiah> OK. +<hezekiah> I'll go find it. +<jrand0m> (short size: ~10 bytes, medium ~10KB, long ~ 1MB) +<jrand0m> java -cp i2p.jar ElGamalBench +<jrand0m> (after running "ant all") +<hezekiah> jrand0m: Thanks. :) +<jrand0m> np +<thecrypto> The NaN thing means it's so fast that we end up dividing by 0 + it's so fast :) +<hezekiah> What's the sha bench? +<jrand0m> java -cp i2p.jar SHA256Bench +--> Neo (anon@anon.iip) has joined #iip-dev +<hezekiah> OK. +<jrand0m> we'll probably want to move those to be main() methods of the + associated engines, but they're good where they are atm +<hezekiah> Let's see how fast all this is on an AMD K6-2 333MHz (which is + a chip not well know for its integer math.) +<jrand0m> heh +<jrand0m> ok so we have DSA and AES left, right? +<jrand0m> this is all wikked thecrypto. nice work. +<thecrypto> yup +<jrand0m> can I nag you for an ETA on the other two? ;) +<hezekiah> If this is anywhere near as fast on my box as it is on yours, + you have to show me how you do that. ;-) +<thecrypto> DSA should be done almost as soon as i have primes ready +<nop> hezekiah have you tried the sslcrypto for python +<thecrypto> copying some code around from the prime generator and things like + that and it's done +<nop> the one off that link +<hezekiah> nop: sslcrypto won't do us any good. +<hezekiah> nop: It doesn't implment ElGamal _or_ AES _or_ sha256. +<thecrypto> AES is mostly done except that there is some error somewhere that + i'm still trying to pick out and destroy, once i have that, it'll be done +<jrand0m> thecrypto> so by friday, DSA keygen, sign, verify, and AES encrypt, + decrypt for arbitrary size inputs? +<nop> the one on McNab's site does not? +<thecrypto> yeah +<nop> darn +<thecrypto> should be friday +<thecrypto> most likey thursday +<jrand0m> thecrypto> does that include the UnsignedBigInteger stuff? +<thecrypto> i'll be missing next weeks meeting because of summer camp, and + i'll be back after that +<thecrypto> jrand0m: prolly not +<jrand0m> ok. +<jrand0m> so for the time being, interoperability between java and python + is b0rked. +<jrand0m> for crypto, that is. +--- Notify: jeremiah is online (anon.iip). +--> jeremiah (~chatzilla@anon.iip) has joined #iip-dev +<jrand0m> (aka for signatures, keys, encryption, and decryption) + +<nop> hmm maybe we should focus more on C/C++ +<thecrypto> well, once we get it working completely we can then make sure + both java and python can speak to each other +<jrand0m> while you're out I'll look into the unsigned stuff. +<jeremiah> can someone email me a backlog? jeremiah@kingprimate.com +<hezekiah> jeremiah: Give me a minute. :) +<jrand0m> nop> do we have devs for C/C++? +<nop> I have one guy yes +<nop> and Hezekiah we know could do it +<jrand0m> or perhaps we can get a python dev status update from hezekiah + + jeremiah to see when we'll have more people for the c/c++ dev +<jrand0m> right, of course. but hez+jeremiah are working on python atm + (right?) +<hezekiah> Yeah. +<-- mrflibble has quit (Ping timeout) +<hezekiah> I'm sort of giving poor jeremiah lots of trouble. +<nop> I was just saying if python won't be fast speeds +<hezekiah> Python is mainly for me to understand this network. +<nop> ahh +<hezekiah> Once, I get it to basically follow the complete spec, I intend + to hand it off to jeremiah to do with as he sees fit. +<hezekiah> It's not meant to be a killer implementation of the spec. +<hezekiah> (If I wanted that, I'd use C++.) +<jeremiah> well there aren't any really processor intensive parts of the app, + iirc, aside from crypto, and ideally that will be handled in C anyways, right? +<jrand0m> sure jeremiah. all depends on the app +--> mrflibble (mrflibble@anon.iip) has joined #iip-dev +<hezekiah> jeremiah: In theory. +<jrand0m> so where are we on the python side? client api, local only + router, etc? +<jeremiah> the python implementation will also let us know what optimizations + we could make from the start... I'd like to keep it up to date or, possibly, + ahead of the C implementation as I can +<hezekiah> jrand0m: OK. Here's what I've got. +<hezekiah> In _theory_ the router should be able to handle all non-admin + messages from a client. +<hezekiah> However, I don't have client yet, so I haven't been able to debug + it (i.e. there are still bugs.) +<hezekiah> I'm working on the client right now. +<jrand0m> 'k. if you can disable signature verification, we should be able + to run the java client against it now +<hezekiah> I'm hoping to have that done except for admin messages in a day + or two. +<jrand0m> we can test that out after the meeting +<hezekiah> jrand0m: OK. +<jeremiah> I've been dealing with real-world stuff mostly since the last + meeting, I can work on the client API, just been trying to sync my thinking + with hezekiah's +<jrand0m> cool +<hezekiah> jeremiah: You know what, just wait. +<hezekiah> jeremiah: I'm probably throwing in too much new stuff for you to + deal with right now. +<jeremiah> hezekiah: right, what I was going to say is that you should + probably just go ahead and implement the base stuff +<hezekiah> jeremiah: In a little while, it will be stabalized and you can + start refining it. (There are lots of TODO comments that need help.) +<jeremiah> and then I can extend it later once I get the picture +<hezekiah> Exactly. +<hezekiah> You get to maintain all this code. :) +<jrand0m> cool. so eta 1-2 weeks for a working python router + client api? +<hezekiah> I'm going on vacation next week so probably. +<hezekiah> Are we going to have more details on router to router soon? +<jrand0m> no. +<jrand0m> well, yes. +<jrand0m> but no. +<hezekiah> lol +<jeremiah> hezekiah: how long is the vacation? +<hezekiah> 1 week. +<jeremiah> ok +<jrand0m> (aka as soon as the SDK goes out, 100% of my time goes into I2NP) +<hezekiah> I'm hoping to have all non-admin functionality written before I + go on vacation +<hezekiah> . +<jrand0m> but then soon after you get back you're off to college, right? +<hezekiah> I2NP? +<hezekiah> Right. +<jrand0m> network proto +<hezekiah> I have about 1 week after vacation. +<hezekiah> Then I'm gone. +<hezekiah> And my free time drops like a stone. +<jrand0m> so that 1 week should only be debugging +<jeremiah> I can work on the code while hez is gone though +<jrand0m> word +<jrand0m> whats your summer look like jeremiah? +<hezekiah> jeremiah: Perhaps you can get those admin functions working? + +<thecrypto> i'll still have a month after i come back from my vaction to work + on things +<jrand0m> having a life, or being like the rest of us l00sers? :) +<jeremiah> maybe +<hezekiah> 100sers? +<hezekiah> What's a 100ser? +<jeremiah> i leave for college on the 22nd, other than that I can dev +<mihi> hezekiah: a loser +<jeremiah> and the last week before I leave all my friends will be gone... so + I can go into hyperdev mode +<hezekiah> mihi: Ah! +<jrand0m> hehe +<hezekiah> OK. So where were we on the agenda? +<hezekiah> i.e. What's next? +<jrand0m> sdk status +<jrand0m> sdk == one client impl, a local only router impl, an app, and docs. +<jrand0m> I'd like to have that out by next tuesday. +<hezekiah> jeremiah: That backlog is on the way. Sorry I forgot you there. :) +<jeremiah> thanks +<jrand0m> ok, co isn't around, so the naming service stuff is prolly a bit + off base +<jrand0m> we can discuss the naming service after he puts out specs or + he's around +<jrand0m> ok, thats it for I2P stuff +<jrand0m> anyone else have I2P stuff, or we on to: <nop> 4) The End with + comments and stuff +<hezekiah> I can't think of anything. +<jrand0m> I assume everyone's seen + http://www.cnn.com/2003/TECH/internet/08/05/anarchist.prison.ap/index.html ? +<thecrypto> not here +<jrand0m> (nop posted it here earlier) +<hezekiah> The thing about the guy who got arrested for linking to a bomb + building site? +<jrand0m> yes +<jrand0m> relevence to the need to get I2P up ASAP should be aparent ;) +<hezekiah> OK! jeremiah, those logs are now sent. +<jeremiah> thanks +<jrand0m> anyone have any questions / comments / thoughts / frisbees, + or are we having a record breaking short meeting? +* thecrypto tosses a frisbee +<-- logger has quit (Ping timeout) +<jrand0m> damn y'all are quiet today ;) +<mihi> question: +<mihi> where can non devs get yout java code? +<jrand0m> si sr? +<thecrypto> not yet +<mihi> 404 +<jrand0m> that'll be made available once we're release ready. aka the + source will go out with the SDK +<jrand0m> heh +<jrand0m> yeah, we don't use SF +<hezekiah> nop: Is it possible that we can get anonymous cvs working some tiem? +<hezekiah> time? +<-- mrflibble has quit (Ping timeout) +<nop> well, I would open up a non-standard port +<jrand0m> hezekiah> we'll have that once the code has the GPL license on there +<nop> but I am working on viewcvs +<jrand0m> aka not now since the gpl doc hasn't been added to the code yet +<hezekiah> jrand0m: It's in all the python code directories and all python + source files speceify licensing under GPL-2. +<jrand0m> hezekiah> is that on the cathedral? +<hezekiah> Yes. +<jrand0m> ah word. i2p/core/code/python ? or a different module? +* jrand0m hasn't seen it in there +<hezekiah> Each python code directory has a COPYING file in it with the + GPL-2 and each source file has the license set a GPL-2 +<hezekiah> It's i2p/router/python and i2p/api/python +<jrand0m> 'k +<jrand0m> so, yeah, by next tuesday we'll have the SDK + public source access. +<hezekiah> Cool. +<hezekiah> Or as you like to say, wikked. ;-) +<jrand0m> heh +<jrand0m> nada mas? +<hezekiah> nada mas? What's that mean!? +<jeremiah> nothing more +* jrand0m suggests you learn a lil espanol en universidad +--> mrflibble (mrflibble@anon.iip) has joined #iip-dev +<hezekiah> Questions anyone? +<hezekiah> Going once! +<-- ptm (~ptm@anon.iip) has left #iip-dev (ptm) +<hezekiah> Going twice! +<-- mrflibble has quit (mr. flibble says "game over boys") +<hezekiah> Speak now .. or wait until you feel like speaking later! +<thecrypto> okay, i'm going to be optimizing the elgamal even more, so expect + even faster elgamal benches in the future +<jrand0m> please focus on DSA and AES before tuning... puhleeeease :) +<thecrypto> i will +<hezekiah> The reason he's doing that is 'cause I'm causing trouble for + people again. ;-) +<thecrypto> i'm making DSA primes +--> mrflibble (mrflibble@anon.iip) has joined #iip-dev +<thecrypto> well, at least making the program to make DSA primes right now +<hezekiah> ElGamal in Java doesn't like an AMD K-6 II 333MHz. +<hezekiah> OK. +<hezekiah> Question round is over! +<jrand0m> ok hez, we're done. you wanna powow on getting the java client + and the python router work? +<hezekiah> See you all next week citizens! +* hezekiah smashes down the *baf*er diff --git a/i2p2www/meetings/logs/52.rst b/i2p2www/meetings/logs/52.rst new file mode 100644 index 00000000..73a0ef26 --- /dev/null +++ b/i2p2www/meetings/logs/52.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 5, 2003 @ 21:02 UTC +=========================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/53.log b/i2p2www/meetings/logs/53.log new file mode 100644 index 00000000..21ca3b19 --- /dev/null +++ b/i2p2www/meetings/logs/53.log @@ -0,0 +1,108 @@ +[21:09] <jrand0m> ok. 21:00 UTC esta ahora +[21:09] <jrand0m> welcome to the um meeting +[21:09] <jrand0m> we have a lot of people out today (nop, hezekiah, thecrypto, and userx), so we'll keep it brief +[21:10] <jrand0m> agenda: 1) hi 2) sdk 3) status 4) questions +[21:10] <jrand0m> 1) hi +[21:10] <jrand0m> hello. +[21:10] <jrand0m> 2) sdk +[21:11] <jrand0m> the I2P SDK 0.1 is ready for quiet release. +[21:11] <mihi> quiet release? +[21:11] <jrand0m> basically we're not publicizing it except for people in the know, and those trusted by people in the know +[21:12] <jrand0m> it is however fully ready to do application design, development, and testing with +[21:12] <jrand0m> If you're on #iip-dev, you're in the know +[21:13] <jrand0m> so anyone who wants to check it out can either pull it from CVS or retrieve source, docs, and build from CHK@GZ-A-C~SH03AwBuKf~AE3E347IcKAwI,4K38eh3m06zAygRzUnw4tQ/i2p_sdk.zip +[21:13] * UserX has joined #iip-dev +[21:13] <jrand0m> hey, its UserX +[21:14] <jrand0m> The 0.1 of the SDK contains the working java client API, as well as both a python and java router implementation and a simple command line chat application +[21:15] <jrand0m> The point of having the SDK is so that people can get a head start on development so their applications will be up and running once the network goes operational and public in september. +[21:16] <mihi> september that never ended? ;) +[21:16] <jrand0m> (rather than having the network up and running with no applications) +[21:16] <jrand0m> heh +[21:16] <jrand0m> no, we're actually beating the schedule I posted to iip-dev a few weeks back in the ganttproject document +[21:16] <jrand0m> not by much (5 days), but beating it none the less. +[21:17] <jrand0m> I'm quite confident that we'll be 1.0alpha in september. +[21:17] <jrand0m> Also, for status, I suspect that there will be a new I2NP (network proto) draft out by the end of the week. +[21:18] <jrand0m> Then, hopefully next week we can have some internal review and revisions, after which we can go into peer review. +[21:18] * shardy_ is now known as shardy +[21:18] <jrand0m> 'lo shardy +[21:18] <shardy> hiya. +[21:18] <shardy> how goes? +[21:19] <jrand0m> wikked. +[21:19] <jrand0m> I hear rumors we might be able to get some of your time for some .net client lib stuff? +[21:19] * jrand0m may be misinformed +[21:20] * ion has quit IRC (Ping timeout) +[21:21] <shardy> .net? nope, that's not me... +[21:21] <jrand0m> ah 'k, my bad +[21:21] <jrand0m> soy muy tonto +[21:21] <jrand0m> well, hi anyway :) +[21:21] <jrand0m> I also got some feedback from co wrt the naming service application +[21:22] * ion has joined #iip-dev +[21:22] <jrand0m> "On August 8th the first version of the specification for the naming service was posted. It was discovered that the specification has flaws, and I am revising it. It should be done within a week or so. After that, I will be start implementing the system. In the end, there will be four components of this software: +[21:22] <jrand0m> 1. Client program to interact with naming service. +[21:22] <jrand0m> 2. Program for the naming service itself. +[21:22] <jrand0m> 3. Administrative utilities for the naming service. +[21:22] <jrand0m> 4. A Certificate Authority (CA) component." +[21:23] <jrand0m> That's co's status report +[21:23] <jrand0m> I think that may be it for status, unless someone has something to add. +[21:24] <shardy> neat. +[21:24] <jrand0m> definitely neat +[21:24] <shardy> as soon as I get time I'm going to start looking over the specs and get familiar with the way you guys do things. +[21:25] <jrand0m> cool. the I2CP spec in the SDK is pretty much operational, but the I2P network spec posted yesterday is a few weeks behind the times. +[21:25] <jrand0m> I'll be posting a new version probably on friday. +[21:25] <jrand0m> (and as this project only began in earnest maybe a month ago, we're open for variations in how we work) +[21:26] <jrand0m> oh wait, now I remember, you're the ecc guy :) +[21:26] <shardy> yep, that's me. although I haven't really done much with ecc in a while... I'm now the prng guy. +[21:27] <jrand0m> oh nice. we're currently using generic prngs, and will want a better way to deal with random data +[21:27] <jrand0m> ok +[21:27] <shardy> generic ones? nop mentioned using yarrow, which seems pretty good. +[21:28] <shardy> I'm doing implementation work on a new prng now. trying to reduce the theory and practice gap somewhat. :) +[21:28] <jrand0m> right. we have a GPL'ed version of yarrow we can pull from freenet into the java implementations, but for the time being we're using java's built in one (java.security.SecureRandom) +[21:28] <jrand0m> heh +[21:29] <mihi> be careful w/ yarrow from freenet, it does heisenbugs ;) +[21:29] <jrand0m> lol +[21:29] <jrand0m> well, thats fixed now that its synchronized +[21:29] * jrand0m opens the floor to any questions +[21:30] * mihi gets DNF for the key mentioned above :( +[21:30] <jrand0m> shite. I inserted it a dozen times at htl 25 +[21:30] <jrand0m> I'll reinsert it yet again +[21:32] <jrand0m> anyone have any questions, other than "why won't freenet find the SDK's key?" +[21:33] * mihi did not ask that ;) and does not have any other questions until he looks @ it ;) +[21:33] <jrand0m> heh +[21:33] <mihi> who puts the log onto the wiki this time? /me has it completely this time. +[21:33] <jrand0m> awesome, go for it +[21:34] <jrand0m> I believe we're out of questions for the meeting, though please everyone feel free to post up further thoughts ot the mailing list. +[21:34] * jrand0m really likes active discussion on iip-dev, even if its everyone saying how my docs suck +[21:34] <mihi> your java sux, jrandom ;) (HHOK) +[21:35] <jrand0m> thats more like it +[21:35] <jrand0m> I'm reinserting the .zip from freenet's CLI, so it'll probably have a different CHK +[21:36] <jrand0m> I'll msg people with it after I reinsert it a few times +[21:36] <jrand0m> mihi wants it. anyone else I should msg? +[21:36] <jrand0m> (or anyone can ask at another time, as well) +[21:36] <mihi> you could mail it to me... +[21:36] <jrand0m> 1.1Mb +[21:37] <mihi> if it is not *too* large. +[21:37] <mihi> erm, okay then not. +[21:37] * mihi is not kind on fetching splitfiles anyway +[21:37] <mihi> s/kind/keen/ +[21:37] <jrand0m> heh, are you going to suggest I insert it without FEC? +[21:38] <mihi> i guess it won't have any chance in current freenet. +[21:38] <jrand0m> ok, I'll see about getting it web accessible with a private URL +[21:39] * jrand0m feels kind of weird with this quiet release thing, but I think its for the best +[21:40] <mihi> just put it on some webspace and put some gpg conventional encryption around it - and tell the passphrase here. +[21:40] <mihi> or use the key mentioned above as passphrase +[21:40] <mihi> btw - shall i strip that one from the log? +[21:41] <jrand0m> no need to. I'm paranoid enough to believe if its said here, its available to those who want to see it ;) +[21:41] <jrand0m> I'll have nop toss it up on some webspace when he gets back later this evening and anonymail people with the appropriate info (url & password / technology / etc) +[21:43] <mihi> thx. "this evening" regarding which time zone? (me will go to bea in about 1 hour) +[21:43] <mihi> s/bea/bed +[21:46] <jrand0m> heh, evening for nop, which is california +[21:46] <jrand0m> ok, I've got to jet. +[21:46] * jrand0m !thwaps meeting to an end +[21:46] <jrand0m> gracias srs y srtas +[21:46] * mihi hands jrandom the *baf*er +[21:47] * jrand0m *baf*s mihi on the head +[21:47] * shardy has quit IRC (EOF From client) +[21:48] <ion> 2 blocks downloading above url +[21:48] <jrand0m> nice +[21:48] * shardy has joined #iip-dev +[21:48] * mihi drops dead. diff --git a/i2p2www/meetings/logs/53.rst b/i2p2www/meetings/logs/53.rst new file mode 100644 index 00000000..8bd95381 --- /dev/null +++ b/i2p2www/meetings/logs/53.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE @ 21:00 UTC +================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/54.log b/i2p2www/meetings/logs/54.log new file mode 100644 index 00000000..2756d75b --- /dev/null +++ b/i2p2www/meetings/logs/54.log @@ -0,0 +1,436 @@ +--- Log opened Tue Aug 19 16:56:12 2003 +17:00 -!- logger [logger@anon.iip] has joined #iip-dev +17:00 -!- Topic for #iip-dev: Weekly IIP development meetings, and other + conversations among developers are held here. +17:00 [Users #iip-dev] +17:00 [ cohesion] [ leenookx ] [ mihi] [ shardy_ ] [ UserXClone] +17:00 [ Ehud ] [ logger ] [ nop ] [ thecrypto] [ velour ] +17:00 [ hezekiah] [ lonelynerd] [ Rain] [ UserX ] [ WinBear ] +17:00 -!- Irssi: #iip-dev: Total of 15 nicks [0 ops, 0 halfops, 0 voices, +15 normal] +17:00 -!- Irssi: Join to #iip-dev was synced in 7 secs +17:00 < hezekiah> Alright! :) +17:00 < hezekiah> Both loggers are in place. :) +17:01 < thecrypto> yah! +17:03 < hezekiah> Hmmm ... +17:03 < hezekiah> This meeting was supposed to start 3 minutes ago. +17:03 < hezekiah> I wonder what's up. +17:04 < thecrypto> well, whose idle +17:04 < hezekiah> jrand0m's not even online. +17:04 < hezekiah> nop's been idle 15 minutes. +17:05 < nop> hi +17:05 < nop> sorry +17:05 < nop> I'm super busy at work +17:05 < mihi> [22:36] * jrand0m is off to dinner but i'll be back within + the half hour for the meeting +17:05 -!- jrand0m [~jrandom@anon.iip] has joined #iip-dev +17:05 < hezekiah> Hi, jrand0m. +17:05 < nop> hi +17:05 < nop> ok, here's the thing +17:05 < nop> I can't be seen on IIP at work right now +17:05 < nop> so I'll check in with yall later +17:05 < nop> got slack about it yesterday +17:05 < nop> so +17:05 < hezekiah> Bye, nop. +17:05 < thecrypto> bye +17:06 < nop> I'll hang in the channel +17:06 < nop> just won't be obvious :) +17:06 < hezekiah> jrand0m? Since you do the most talking these days, is + there anything you want on the agenda for this meeting? +17:07 < jrand0m> back +17:08 < jrand0m> ok, the pesto pasta was good. +17:08 < jrand0m> lemmie pull up the agenda-ish stuff +17:09 -!- Lookaround [~chatzilla@anon.iip] has joined #iip-dev +17:09 < jrand0m> x.1) i2cp sdk mods x.2) i2np review x.3) polling http + transport x.4) dev status x.5) todo x.6) plan for next two weeks +17:09 < jrand0m> (place x at whatever # in the agenda it fits) +17:10 < thecrypto> you are the agencda +17:10 < hezekiah> jrand0m: I don't have anything to say, and nop can +17:10 < hezekiah> can't talk. +17:10 < jrand0m> lol +17:10 < hezekiah> UserX most likely won't be adding anything (he usually + doesn't), so as far as I'm concerned it's all yours. :0 +17:10 < hezekiah> :) +17:10 < jrand0m> 'k. we logging? +17:10 < jrand0m> heh +17:10 < hezekiah> I'm logging everything. +17:10 < jrand0m> cool. ok. 0.1) welcome. +17:10 < jrand0m> hi. +17:11 < jrand0m> 0.2) mailing list +17:11 < jrand0m> the list is down atm, back asap. you'll know when it is :) +17:11 < jrand0m> for the meantime, wiki or use iip to convo. +17:11 < jrand0m> 1.1) i2cp sdk mods +17:12 < jrand0m> the SDK has been updated with some bugfixes, plus some new + things in the spec have been introduced. +17:12 < jrand0m> I posted to the list yesterday with the info. +17:13 < jrand0m> hezekiah/thecrypto/jeremiah> any questions on what I posted, + or thoughts on a plan to implement the changes? (or other alternatives I + haven't considered?) +17:13 < hezekiah> I've been running around like the chicken with my head + cut off getting ready for college. +17:13 < jrand0m> word, understood. +17:13 < hezekiah> I had a cursory look at what you wrote, but haven't actually + looked at the changes to the spec. +17:13 < jrand0m> we barely have any more of your time left, do we... +17:13 < hezekiah> Not until I get to college. +17:14 < hezekiah> Once I do, then I will probably be unheard from for at + least a week while I adjust. +17:14 < jrand0m> and once you get there you'll have a lot of settling in to do + (iirc from when i went to school ;) +17:14 < jrand0m> heh word. +17:14 < hezekiah> Then by then, I should be a bit more efficient and have + more time so I can code. +17:14 < jrand0m> cool +17:14 < thecrypto> i'm just doing crypto, so the data structures are my real + worry, once i have the CTS mode done, i'll go work on that prolly +17:14 < hezekiah> Anyway, that's my guess. +17:14 < jrand0m> awesome thecrypto +17:15 < jrand0m> ok, the good thing is the SDK works perfectly fine (with + the bugs mihi found being fixed [yay mihi!]) without the update to the spec. +17:15 -!- arsenic [~none@anon.iip] has joined #iip-dev +17:16 < jrand0m> ok, on to 1.2) i2np review +17:16 < jrand0m> anyone read the doc? +17:16 < jrand0m> ;) +17:16 < hezekiah> Not I, yet. +17:16 < hezekiah> As I said, I'm currently a chicken with its head cut off. +17:17 < hezekiah> BTW jrand0m, it appears you like sending PDF's. +17:17 < jrand0m> can everyone read openoffice .swx? +17:17 < hezekiah> I can. +17:17 < jrand0m> [if so, I'll send swx] +17:17 -!- abesimpson [~k@anon.iip] has joined #iip-dev +17:17 < thecrypto> i can +17:17 < hezekiah> I can't search for text in a PDF with KGhostView. +17:17 < hezekiah> So that really hurts. +17:17 < jrand0m> that sucks hezekiah +17:17 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev +17:17 < hezekiah> The linux version of Adobe Acrobat isn't very friendly eiter. +17:18 < jrand0m> ok, openoffice format it is instead of pdf. +17:18 < hezekiah> Cool. +17:18 < jrand0m> um, ok. i2np has a few minor changes to the LeaseSet + structure (reflecting the i2cp change posted earlier), but other than that, + largely in place. +17:19 < hezekiah> jrand0m: Are all these docs in cathedral's CVS? +17:19 < nop> oh +17:19 < nop> can I interject +17:19 < hezekiah> i.e. copies of the PDF files you've been sending to the + list, etc. +17:19 < hezekiah> nop: Go ahead. +17:19 < nop> this is offtopic but important +17:19 -!- ChZEROHag [hag@anon.iip] has joined #iip-dev +17:19 < nop> IIP-dev and the mail are kind of screwy right now +17:19 < hezekiah> I noticed. +17:19 < nop> so bear with us for a bit +17:20 < nop> we're trying to get it up and going +17:20 < nop> but it has spam assassin built in +17:20 < nop> which is the good news +17:20 < nop> :) +17:20 < nop> and a lot of other features +17:20 < jrand0m> any eta nop for the list? +17:20 * ChZEROHag pokes his nose in +17:20 < jrand0m> (i know you're busy, not nagging, just wondering) +17:20 < nop> hopefully by tomorrow +17:20 < jrand0m> cool +17:20 < nop> the mail admin is working on it +17:21 * hezekiah notes that jrand0m _really_ likes the iip-dev list. ;-) +17:21 < nop> haha +17:21 < hezekiah> Go delta407! +17:21 < nop> anyway +17:21 < jrand0m> its best to document decisions publicly hezekiah ;) +17:21 < nop> back to our regularly scheduled meeting +17:21 < jrand0m> heh +17:21 -!- nop is now known as nop_afk +17:21 < hezekiah> jrand0m: So where were we? +17:21 < jrand0m> ok, to your equestion hezekiah> some are, but the latest + aren't. I'll switch to placing in the openoffice format. +17:21 < jrand0m> rather than the pdfs +17:22 < hezekiah> OK. +17:22 < hezekiah> It'd be really cool if all the docs were in CVS. +17:22 < jrand0m> definitely, and they will be +17:22 < hezekiah> Then I can just update, and I know I have the latest edition. +17:22 < jrand0m> (there are the three drafts that aren't so far) +17:22 < hezekiah> (BTW, a little off topic, but is anonymous access to + cathedral up yet?) +17:23 < jrand0m> not yet. +17:23 < jrand0m> ok, by friday, I hope to have another draft of I2NP in + full form [aka no more ... for the kademlia explanation sections, and sample + implementation details] +17:24 < jrand0m> there are no significant changes. just more filling + clarifying things. +17:24 < hezekiah> Sweet. +17:24 < hezekiah> Will there be byte layout for data structures avalible in it? +17:24 < jrand0m> 1.3) I2P Polling HTTP Transport spec. +17:24 < jrand0m> no, byte layouts go in the data structures spec, which + should be converted to the standard format instead of html +17:25 < jrand0m> (though I2NP already has all the necessary byte layouts) +17:25 < jrand0m> ((if you read it *cough* ;) +17:25 < hezekiah> Good. +17:25 < hezekiah> lol +17:25 < hezekiah> Sorry about that. +17:25 < hezekiah> As I said, I've been really busy. +17:25 < jrand0m> heh no worry, you're heading off to college shortly, you're + supposed to be partying :) +17:25 < hezekiah> Partying? +17:25 < jrand0m> ok, 1.3) I2NP Polling HTTP Transport spec +17:25 < hezekiah> Hmmm ... I guess I'm just odd. +17:25 < jrand0m> heh +17:26 < jrand0m> ok, I tried sending this out earlier, but I'll commit + it shortly. its a quick and dirty transport protocol fitting in with I2NP + to allow routers to send data back and forth without direct connections + (e.g. firewalls, proxies, etc) +17:27 < jrand0m> I'm *hoping* someone can see how this works and build + similar transports (e.g. bidirectional TCP, UDP, direct HTTP, etc) +17:27 -!- mihi [none@anon.iip] has quit [Ping timeout] +17:27 < hezekiah> Hmmm, well I don +17:27 < jrand0m> before putting I2NP out for review, we need to include + sample transports so people can see the full picture +17:27 < hezekiah> don't think _I'll_ be building any transports soon. ;-) +17:27 -!- WinBear_ [~WinBear@anon.iip] has joined #iip-dev +17:27 < hezekiah> TCP is working for Java and Python. +17:27 < hezekiah> (At least client-to-router is.) +17:27 < jrand0m> no worry, I'm just putting it out there as a todo for people + who want to contribute +17:28 < hezekiah> Right. +17:28 < jrand0m> right, client-router has different requirements than the + router-router. +17:28 < jrand0m> ok, anyway, 1.4) dev status +17:28 < jrand0m> how we doing with CBC thecrypto? +17:28 < thecrypto> CBC is committed +17:28 < jrand0m> w00000t +17:28 < thecrypto> CTS is almost done +17:28 < hezekiah> thecrypto: What's CTS? +17:29 < thecrypto> i just have to figure out how to implement i nicely +17:29 < jrand0m> cts being cyphertext stealing :) +17:29 < hezekiah> Ah! +17:29 < thecrypto> CipherText Stealing +17:29 -!- WinBear [WinBear@anon.iip] has quit [EOF From client] +17:29 < jrand0m> did you pull nop's reference on that? +17:29 < hezekiah> OK. We're using CBC with CTS instead of padding. +17:29 < hezekiah> Hmm. +17:29 < thecrypto> basically, it makes the message exaclty right length +17:29 < jrand0m> is that workable for the python side hezekiah? +17:29 < hezekiah> I might need to slap the Python crypto lib I'm using upside + the head to make it us CTS properly. +17:30 < hezekiah> I've always prefered CTS over padding, but I don't know + what PyCrypt does. +17:30 < jrand0m> what can python do out of the box to allow exact message + size recovery? +17:30 < thecrypto> all you need to do is change how you process the last + two blocks +17:30 < hezekiah> I have a feeling that library is going to get some serious + rewritting. +17:30 < hezekiah> jrand0m: The CBC stuff in python is transparent. You just + send the buffer to the AES objects encrypt function. +17:31 < hezekiah> It spits out cipher text. + +17:31 < hezekiah> End of story. +17:31 < jrand0m> does D(E(data,key),key) == data, byte for byte, exact + same size? +17:31 < hezekiah> So if it has the wacky idea of using padding instead of CTS, + then I might need to get in its guts and fix it. +17:31 < jrand0m> (regardless of input size?) +17:31 -!- mihi [~none@anon.iip] has joined #iip-dev +17:31 < hezekiah> jrand0m: Yes. It should. +17:31 < jrand0m> hezekiah> if you could look into exactly what algorithm it + uses to do the padding, that'd be great +17:32 < hezekiah> Right. +17:32 * jrand0m is hesitant at requiring a mod to a python crypto lib if + the lib already uses a standard and useful mechanism +17:32 < hezekiah> One way or another, CBC with CTS sounds good. +17:32 < hezekiah> jrand0m: This python crypto lib stinks. +17:32 < jrand0m> heh 'k +17:33 < thecrypto> i just have to calculate how to mess with the two blocks +17:33 < hezekiah> jrand0m: ElGamal will need to be completely rewritten in + C just to make it fast enough to use. +17:33 < jrand0m> hezekiah> whats the benchmark for python elg of 256bytes? + its only done once per dest-dest comm... +17:34 < jrand0m> (if you know offhand, that is) +17:34 < hezekiah> I'd have to test it. +17:34 < hezekiah> Encryption is only a second or two I think +17:34 < jrand0m> < 5 sec, < 2 sec, > 10 sec, > 30 sec? +17:34 < thecrypto> i'll prolly do some work with it +17:34 < hezekiah> Decrypton might be some place between 5 or 10 seconds. +17:34 < jrand0m> cool. +17:35 < jrand0m> hezekiah> have you spoken with jeremiah or do you have any + news about the status of the python client api? +17:35 < hezekiah> thecrypto: All you should need to do is write a C module + that works with Python. +17:35 < hezekiah> I have no clue what he's been up to. +17:35 < hezekiah> I haven't spoken to him since I got back. +17:35 < jrand0m> 'k +17:35 < jrand0m> any other dev status thoughts? +17:36 < hezekiah> Um, not really from me. +17:36 < hezekiah> I've already explained my current free time status. +17:36 < jrand0m> word. understood +17:36 < hezekiah> My only plans are to get the C API up and the python router + back up to spec. +17:37 < jrand0m> 'k +17:37 < hezekiah> Oh my goodness! +17:37 < jrand0m> 1.4) todo +17:37 < jrand0m> si sr? +17:37 < hezekiah> The Python crypto lib doesn't implement CTS or padding! +17:37 < hezekiah> I'll have to do that manually. +17:37 < jrand0m> hmm? it requires data to be mod 16 bytes? +17:37 < hezekiah> Yup. +17:38 < jrand0m> heh +17:38 < jrand0m> oh well. +17:38 < hezekiah> Currently the Python router uses padding. +17:38 < jrand0m> ok. here are some oustanding items that need to get done. +17:38 < hezekiah> I remember that now. +17:38 < hezekiah> Well, let +17:38 < hezekiah> let's be frank about one thing. +17:38 < hezekiah> The Python router is never really meant to be used. +17:39 < hezekiah> It's primarily meant for me to be very familiar with the + spec and it also accomplishes something else: +17:39 < hezekiah> It forces the Java router to comply _exactly_ with the spec. +17:39 < jrand0m> both very important goals. +17:39 < hezekiah> Sometimes the Java router doesn't quite comply, and then + the Python router screams bloody murder. +17:39 < hezekiah> So it doesn't really need to be fast or stable. +17:39 < jrand0m> plus I'm not sure it won't ever be used in the sdk +17:39 < jrand0m> right. exactly. +17:39 < jrand0m> the python client api is a different thing though +17:39 < hezekiah> The Python client API on the other hand needs to be decent. +17:40 < jrand0m> exactly. +17:40 < hezekiah> But that's jeremiah's problem. :) +17:40 < hezekiah> I've left that to him. +17:40 < jrand0m> the SDK local only routers are client dev use only +17:40 < jrand0m> lol +17:40 < jrand0m> ok, as I was saying... ;) +17:40 < hezekiah> ;-) +17:41 < jrand0m> - we need someone to start working on a small web page + for i2p that will be used for putting out the various I2P related specs for + peer review. +17:41 < jrand0m> I'd like this to be ready before 9/1. +17:41 < hezekiah> OK. I am stating right now that you don't want me to do that. +17:41 < hezekiah> I'm not a good webpage designer. :) +17:41 < jrand0m> nor I, if anyone here has seen my flog ;) +17:41 < jrand0m> cohesion? ;) +17:41 < hezekiah> lol +17:42 < hezekiah> Poor cohesion, always stuck with the dirty work. :-) +17:42 * cohesion reads the back log +17:42 < hezekiah> ;) +17:42 < jrand0m> heh +17:42 < cohesion> jrand0m: I will do it +17:42 < cohesion> me@jasonclinton.com +17:42 < cohesion> send me the specs +17:42 < jrand0m> 'k, gracias. +17:42 < jrand0m> the specs aren't all done yet. +17:43 < jrand0m> but the contents that will need to be there are: +17:43 < cohesion> well, what you have an what you would like to have put up +17:43 < jrand0m> -I2CP spec, I2NP spec, Polling HTTP Transport spec, TCP + Transport spec, Security analysis, Performance analysis, Data structure spec, + and a readme/intro +17:44 < jrand0m> (those 7 documents will be in pdf and/or text format) +17:44 < cohesion> k +17:44 < jrand0m> barring the readme/intro +17:45 < jrand0m> I'm hoping that all of those docs will be ready by next week + (8/26). will that give you enough time to get together a small page for a +9/1 release? +17:46 < jrand0m> ok. another thing that will need to come down the pipe is + an I2P network simulator. +17:46 < jrand0m> do we have anyone looking for a CS project? ;) +17:46 < hezekiah> lol +17:46 < cohesion> jrand0m: yea, that's doable +17:47 < hezekiah> I'm not for another few years. ;-) +17:47 < jrand0m> cool cohesion +17:47 < thecrypto> not for a year +17:47 * cohesion goes back to work +17:47 < jrand0m> tnx cohesion +17:48 < jrand0m> ok, 1.6) next two weeks. on my plate is getting these specs, + docs, and analysis up. I'll post & commit as soon as I can. +17:48 < jrand0m> PLEASE READ THE SPECS AND COMMENT +17:48 < jrand0m> :) +17:48 < hezekiah> jrand0m: Right. Once I get time, I will start reading. :) +17:48 < jrand0m> I'd prefer people to post comments to the list, but if + people want to be anon, send me comments privately and I'll post replies to + the list anonymously. +17:49 < hezekiah> (What do you think the eta for OpenOffice files for the + docs being on CVS is?) +17:49 < jrand0m> I can commit the latest revs within 10 minutes of this + meeting being over. +17:49 < hezekiah> Awesome. :) +17:50 < jrand0m> ok, thats it for 1.*. +17:50 < jrand0m> 2.x) comments/questions/concerns/rants? +17:50 < jrand0m> how's the sdk mod working out mihi? +17:51 < jrand0m> or anyone else? :) +17:51 < hezekiah> jrand0m: What is this sdk mod you're talking about? +17:52 < jrand0m> hezekiah> two bugfixes to the sdk, commited (& posted) + the other day +17:52 < hezekiah> Ah +17:52 < hezekiah> Neato. +17:52 < jrand0m> (rotate the message IDs, synchronize writes) +17:52 < hezekiah> Just the java side, or the python side too? +17:52 < jrand0m> yo no hablo python. +17:53 < hezekiah> lol +17:53 < jrand0m> not sure if the bugs exist there. do you rotate message + ids every 255 messages, and synchronize your writes? +17:54 < hezekiah> I think the Python router does both +17:54 < jrand0m> cool. +17:54 < jrand0m> we'll let you know if it doesn't ;) +17:54 < hezekiah> What exactly do you mean by "synchronize your writes"? +17:55 < jrand0m> aka make sure multiple messages aren't written to a client + at the same time if there are multiple clients trying to send messages to + it at the same time. +17:55 < hezekiah> All the data sent over the TCP connection gets sent in + the order it originated. +17:56 < hezekiah> So you won't be 1/2 of message A and then 1/3 of message B. +17:56 < jrand0m> 'k +17:56 < hezekiah> You'll get message A and then message B. +17:56 < hezekiah> OK ... if no one else is going to talk, I suggest we + adjurne the meeting. +17:56 < mihi> my simple TCP/IP over I2p seems to work... +17:56 < jrand0m> niiiiice!! +17:56 * mihi was idling a bit sorry +17:57 < hezekiah> Anyone else have anything to say? +17:57 < jrand0m> mihi> so we'll be able to run pserver over that? +17:57 < mihi> as long as you do not try to create lotas connections at once. +17:57 < mihi> jrand0m: i guess so - i could ge tgoogle through it +17:57 < jrand0m> niiiice +17:57 < jrand0m> mihi++ +17:57 < mihi> jrand0m-ava +17:57 < jrand0m> so you have an outproxy and an inproxy? +17:58 < mihi> exactly. +17:58 < jrand0m> cool +17:58 < mihi> the destination needs keys, the source generates them on demand +17:58 * hezekiah hands jrand0m the *baf*er. Smash the thing when you're + done, man. +17:58 < jrand0m> right. hopefully co's naming service could help with that + once its ready. +17:59 < jrand0m> ok cool. mihi, let me or anyone else know if there's + anything we can do to help :) +17:59 < mihi> fix that thing with the 128 msgids or build a better GUARANTEED + support +17:59 * jrand0m *baf*s nop_afk over the head for having a real job +18:00 < mihi> jrand0m: baf abuse costs 20 yodels +18:00 < jrand0m> lol +18:00 < jrand0m> better guaranteed support? +18:00 < jrand0m> (aka better performance than the one described? we'll fix + that in impl) +18:00 < mihi> did you test my test case with start_thread=end_thread=300? +18:01 < mihi> it generates lots of messages in one direction, and that causes + all msgids to be eaten... +18:01 < jrand0m> hmm, no, hadn't seen that message +18:01 < hezekiah> jrand0m: Would it be reasonable to make msgid 2 bytes? +18:01 * jrand0m tried the 200 / 201, but thats fixed with the latest +18:01 -!- cohesion [cohesion@anon.iip] has quit [off to the lug meeting] +18:01 < mihi> which latest? +18:01 < hezekiah> Then they would have 65535 msgids (if you don't could + msgid 0) +18:01 < hezekiah> . +18:02 < jrand0m> 2 byte message ids wouldn't hurt. I'm comfortable with + that change. +18:02 < jrand0m> mihi> the one I mailed you +18:02 < mihi> if you have a more latest than the one you sent me, send it + (or give me cvs access) +18:03 < mihi> hmm, that one fails for me with 200/201 (as well as with 300) +18:03 < jrand0m> hmm. I'll do some more testing and debugging and mail you + what I come up with. +18:03 < mihi> thx. +18:04 < jrand0m> ok. +18:04 * jrand0m declares the meeting +18:04 < jrand0m> *baf*'ed +18:04 * hezekiah hangs the *baf*er reverantly on its special rack. +18:05 * hezekiah then spins around walks out the door, slamming it behind + him. The baffer falls off the rack. +18:05 < hezekiah> ;-) +--- Log closed Tue Aug 19 18:05:36 2003 diff --git a/i2p2www/meetings/logs/54.rst b/i2p2www/meetings/logs/54.rst new file mode 100644 index 00000000..01a5b1e9 --- /dev/null +++ b/i2p2www/meetings/logs/54.rst @@ -0,0 +1,7 @@ +I2P dev meeting, August 19, 2003 +================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/55.log b/i2p2www/meetings/logs/55.log new file mode 100644 index 00000000..0cc0b5a2 --- /dev/null +++ b/i2p2www/meetings/logs/55.log @@ -0,0 +1,209 @@ +[23:00] <jrand0m> ok, topics> x.0: welcome x.1: spec questions x.2: elg issues x.3: sdk status x.4: release plan x.5: apps +[23:00] <jrand0m> is x == 0 or 1 or 2? +[23:00] <jeremiah> 22/7 +[23:01] <thecrypto> i think it's 0 +[23:01] * jrand0m always logs, so wtf, why not. +[23:01] <jrand0m> 0.0: welcome. +[23:01] <jrand0m> hi. +[23:01] <jrand0m> 0.1: spec questions +[23:01] <jrand0m> anyone read the specs? :) +[23:02] * mihi did. at least tried to +[23:02] <jrand0m> w0ah word +[23:02] <jeremiah> nope +[23:02] <jeremiah> what are the new ones? +[23:02] <thecrypto> occasionally +[23:02] <jrand0m> mihi> tried to, hard to read, bad language, incomprehensible organization, or just boring as fuck? +[23:03] <mihi> i'm just not familiar enough with crypto. the first part was very interesting. +[23:03] <jrand0m> jeremiah> specs are in cvs, and I post to iip-dev when they come out. current ones are: i2cp, i2np, i2p data structures, polling http transport proto +[23:03] <mihi> but when it got into detaily, you could have described how to brew an irish stew and i would not hav noticed ;) +[23:04] <jeremiah> sweet +[23:04] <jrand0m> lol mihi +[23:05] <mihi> although the format had its problems as well -don't have open office here, just ol' staroffice 5.2 +[23:05] <jrand0m> does star office 5.2 not read it? would you prefer .pdf or kludged html? +[23:05] <jrand0m> (or .txt? though txt wouldn't have pics or real formatting) +[23:05] <mihi> i'd prefer "old" .sdw format. +[23:05] <jeremiah> pdf if at all possible +[23:05] <mihi> or pdf +[23:06] <jrand0m> pdf is a one click solution. +[23:06] * jrand0m edits in open office, reads in pdf +[23:06] <jeremiah> or appleworks +[23:06] <jeremiah> ;) +[23:06] <mihi> sxw is supported only in staroffice 6.0 and above +[23:06] <jrand0m> ah ok mihi +[23:06] * jrand0m put out .sxw because last time people complained and wanted .sxw. when we publish we'll put out .sxw, .sdw, and .pdf +[23:07] <jrand0m> (or maybe .doc if i'm feeling dirty) +[23:07] <mihi> i would not mind .sdw.zip or .sdw.gz or .sdw.bzw either... +[23:07] <mihi> s/bzw/bz2/ +[23:07] <jrand0m> heh, zipped up, for sure. +[23:08] <jrand0m> the data structures spec may require a mod, and the network proto requires some fixed urls before release. +[23:08] <jrand0m> anyone have any questions on any of the four specs? +[23:09] <thecrypto> not at the momemet +[23:10] <jrand0m> ok. 0.2: elg issues +[23:10] <jrand0m> we're having some probs w/ elgamal encryption as specified on p13 of the data structures spec. +[23:11] <jrand0m> it may be key related, algorithm related, or implementation related. probably not implementation related, as this has been tested against two implementations. +[23:11] <jrand0m> if its algorithm related, we're going to want to update the spec prior to spec release to reflect whatever we need to change to make it work. +[23:12] <jrand0m> if its implementation or key generation related, we can publish the spec and fix the sdk when resolved. +[23:13] <jrand0m> thecrypto> any thoughts on whats up, or we waiting for nop to reply to the list (or here, if he's around and available to talk) +[23:14] <thecrypto> i'm trying to figure it out at the moment +[23:15] *** Signoff: mihi (Ping timeout) +[23:15] *** mihi_ (~none@anon.iip) has joined channel #iip-dev +[23:15] <jrand0m> 'k +[23:15] *** mihi_ is now known as mihi +[23:15] <thecrypto> i have to run some math and through some other implementation and figure it out +[23:15] <thecrypto> i never had a problem with elgamal +[23:15] <thecrypto> last time i tested +[23:16] *** Signoff: mihi ((null)) +[23:17] <thecrypto> with that benchmark +[23:17] <jrand0m> right, but the benchmark only tried one key +[23:17] <thecrypto> ahh +[23:17] <jrand0m> i can quite repeatedly get the error without any mods to the elg impl +[23:17] <thecrypto> didn't we have a wrong key message that came up? +[23:18] <jrand0m> yes, those still come up +[23:18] *** mihi_ (~none@anon.iip) has joined channel #iip-dev +[23:18] <jrand0m> periodically (usually 2-4 times per keygen) +[23:18] *** mihi (~none@anon.iip) has joined channel #iip-dev +[23:18] *** mihi is now known as mihi_backup +[23:18] *** mihi_ is now known as mihi +[23:18] <thecrypto> and we still get bad keys? +[23:19] <jrand0m> or something. +[23:19] <jrand0m> all that wrong size tests is "if ( (k0.length == PublicKey.KEYSIZE_BYTES) && (k1.length == PrivateKey.KEYSIZE_BYTES) ) {" +[23:19] <jrand0m> no value evaluation, etc. +[23:20] <thecrypto> one second +[23:23] <thecrypto> can you check if x the private key is < p +[23:23] <jrand0m> if (m.compareTo(CryptoConstants.elgp) >= 0) +[23:23] <jrand0m> already done. +[23:23] <jrand0m> (throw new IllegalArgumentException("ARGH. Data cannot be larger than the ElGamal prime. FIXME");) that exception is never thrown. +[23:23] <jrand0m> er x? hmm. +[23:24] <jrand0m> 'k. perhaps we may want to steal bouncycastle's or another impl's elg key gen algo +[23:25] <jrand0m> ok. 0.3> sdk issues +[23:26] <jrand0m> elg is pending, but other than that the sdk is very close to 0.8 (aka release matching specs) +[23:26] <jrand0m> (only the elg issue plus the LeaseSet modification is left) +[23:26] <jrand0m> I'd like to have the SDK 0.8 ready to go with the spec release, but I don't think we should commit to that. +[23:27] <jrand0m> or even whether we need to include SDK 0.1 with the spec release. +[23:27] <thecrypto> gah! annoying +[23:28] <thecrypto> miracl which nop pointed me too does the exact same thing we do +[23:28] <thecrypto> and they have no checks +[23:28] <jrand0m> unsigned though. +[23:28] <jrand0m> (since miracl is in c) +[23:28] * jrand0m assumes +[23:28] <thecrypto> yes +[23:29] <thecrypto> but still, i make sure we never have a signed biginteger +[23:30] <jrand0m> biginteger.toByteArray() returns a signed byte array +[23:30] <thecrypto> sorry, continue +[23:30] <jrand0m> 'k +[23:30] <jrand0m> any movement on the python front jeremiah? +[23:31] <jeremiah> hey +[23:31] <jeremiah> sorry I was reading the backlog +[23:31] <jrand0m> heh hi +[23:31] <jeremiah> nope, I'm still getting used to classes +[23:31] <jrand0m> coo' +[23:31] <jrand0m> no prob +[23:31] <jeremiah> I think I'm gonna sleep for a bit actually +[23:31] <jrand0m> 'k +[23:32] <jrand0m> 0.4: release plan +[23:32] <jrand0m> we need the sdk issues resolved in the next day or so, one way or another. +[23:32] <jrand0m> we need to get working on wiki-fiying the security model +[23:32] <jrand0m> (wiki, where art thou) +[23:33] <jrand0m> we need to get the performance model up (not a prob, ill have it in a day or so) +[23:33] <jrand0m> we need to update the specs to include any elg mods, plus real URLs to other specs. +[23:33] <nop> miracl +[23:33] <nop> has a port +[23:33] <nop> to java +[23:33] <jrand0m> perhaps we need to host the specs && / || sdk outside the US for export regulations [not that i care] +[23:34] <jrand0m> right, but miracl's java port doesnt have elg encryption last i checked. +[23:34] <jrand0m> i'll check again. +[23:34] <nop> jrand0m, we don't care, but we'll worry about that later +[23:34] <nop> jrand0m if it has bigdig() and modexp() +[23:34] <nop> you're fine +[23:34] *** yodel (~yodel@anon.iip) has joined channel #iip-dev +[23:34] <thecrypto> one second +[23:34] <thecrypto> i think i found our problem +[23:35] <jrand0m> word, whats up thecrypto? +[23:35] <nop> can you check jrand0m +[23:35] <thecrypto> our k isn't being checked for relitive prime +[23:36] <jrand0m> will that cause the problems described thecrypto? i thought that would just render the encryption insecure (a problem, nonetheless) +[23:36] <thecrypto> but that would mean only some messages with the key would fail +[23:36] <thecrypto> it's something in keygen +[23:36] <jrand0m> nop> we'll find something to solve it. but i outlined some specific questions in my email that are implementation independent +[23:36] <jrand0m> ok thecrypto, we'll work through that after the meeting +[23:37] <nop> the double ciphertext question? +[23:37] <thecrypto> okay +[23:37] <jrand0m> nop> thats one of the questions +[23:37] * nop goes to read +[23:39] <jrand0m> nop> any ideas on when the wiki will be up? if its just dns, whats the IP so I can mod my hosts file so I can start editing? +[23:40] <thecrypto> quick q jrand0m: where does it fail, the benchmark runs perfectly and it makes a new keypair every time? +[23:41] <nop> let me get it up, hold +[23:41] <mihi> wiki.invisiblenet.net == jasonclinton.com [64.91.236.103] +[23:41] <jrand0m> gracias mihi +[23:42] <jrand0m> thecrypto> it makes a new keypair each time. it fails on a two line test case that I built when debugging the ElGamalAESEngine +[23:42] <thecrypto> can i see this ElGamalAESEngine? +[23:42] <thecrypto> just commit it to CVS and i'll see what the problem is +[23:43] <nop> ok wiki is cname'd +[23:43] <nop> should propagate in a bit +[23:43] * jrand0m doesnt commit things that don't work, but I'll email you +[23:43] <jrand0m> thanks nop +[23:43] <nop> it's up +[23:43] <nop> ;) +[23:43] <nop> (Link: http://wiki.invisiblenet.net)http://wiki.invisiblenet.net +[23:43] <jrand0m> not on my box it aint +[23:43] <jrand0m> ;) +[23:44] <nop> what are we wiki'ing +[23:44] <nop> ? +[23:44] <jrand0m> the security doc, plus a place to distro the specs. +[23:44] <jrand0m> perhaps even the i2p website prior to 1.0 release, but at least the security doc. +[23:45] *** Signoff: sirk ((null)) +[23:45] *** Signoff: shardy_ (Ping timeout) +[23:46] <jrand0m> ok. given the above 5 points on the release plan, I'd like to have the specs out friday, saturday, or sunday, at the latest. +[23:46] *** shardy_ (~shardy@anon.iip) has joined channel #iip-dev +[23:46] <nop> I have a grphx guy working on the website +[23:47] <nop> for i2p +[23:47] <jrand0m> any problems with that for a deadline? [friday deadline, fallback only if Bad Things Happen] +[23:47] <nop> sure +[23:47] <thecrypto> jrand0m: sent? +[23:47] <jrand0m> 'k, so just the security docs and the i2p spec distro location +[23:47] <jrand0m> no thecrypto, there are half a dozen files. i'll send after the meeting. +[23:47] <thecrypto> okay +[23:48] <thecrypto> i'd like them sooner because we're moving tables around today so i need to move computers soon +[23:48] <nop> jrand0m, I'll need to look at your email and I'll respond shortly +[23:48] <nop> multi-tasking +[23:49] <jrand0m> 'k. +[23:49] <jrand0m> 0.5> apps +[23:49] <jrand0m> the name service is awol, as co aint around ;) [but i think he just went off to school too, so thats to be expected for the short term] +[23:49] <jrand0m> mihi has an awesome awesome i2ptunnel app +[23:50] *** Signoff: WinBear_ (EOF From client) +[23:50] <mihi> strip one or two `awesome's ;) +[23:50] <jrand0m> heh +[23:51] <jrand0m> well, its very impressive. there's still stuff to add, but as is its a working port forwarder with reasonable performance. a really good proof of concept +[23:51] <mihi> it relies on too many things i cannot see from the spec (e.g. that GUARANTEED packets are delivered in order) +[23:52] <jrand0m> guaranteed packets are not delivered in order, but the java impl blocks on send of guaranteed, so if you use the java impl w/ guaranteed and don't have multiple sending threads, its guaranteed in order. +[23:52] <jrand0m> ideally, it'd be cool if it FEC'ed or had built in ordering & reconstruction or something +[23:52] <jrand0m> (so that it didn't block on send and didn't require GUARANTEED) +[23:53] <mihi> that's a bot too many ifs i think... +[23:53] <mihi> s/bot/bit/ +[23:55] <mihi> but perhaps i'll have some time to add reordering/resending to it... +[23:55] <jrand0m> well, thats how the java client impl is implemented ;) guaranteed is not recommended for low latency synchronous use, as it requires an ack (which in turn is a full message delivery, though without the client side end to end crypto, just i2np crypto) +[23:55] <jrand0m> word +[23:56] <jrand0m> any other apps on the horizon? should we have a page on the wiki w/ apps & app ideas for devs to get involved with? +[23:57] * jrand0m thinks we probably aren't too far off until yodel's xml rpc can operate via the i2p sdk (either through mihis tunnel or natively) +[23:57] <nop> hmm +[23:57] <thecrypto> test +[23:57] <jrand0m> tset +[23:57] <thecrypto> still connected? +[23:57] <jrand0m> si sr +[23:58] <thecrypto> we're unplugging phonelines right now +[23:58] <nop> IIP, it defies phone lines +[23:58] <jrand0m> heh +[23:58] <nop> :) +[23:58] <thecrypto> i can get back on the IM front and file transfer +[23:58] <jrand0m> wikked +[00:00] <jrand0m> ok. thats all i have for agenda items. +[00:00] <jrand0m> any comments/questions/concerns/frisbees? +[00:00] * thecrypto throws a frisbee +[00:00] * jrand0m gets a frisbee in the face +[00:01] <thecrypto> i just want to get this crypto stuff done so i can go back and optimize elg +[00:01] <thecrypto> and do the same for python hopefully +[00:01] <jrand0m> word. I'll get you the code in the next 5 +[00:02] <thecrypto> that would be good +[00:03] * jrand0m readies the *baf*er +[00:03] * jrand0m winds up +[00:03] * jrand0m *baf*s the meeting to a close. diff --git a/i2p2www/meetings/logs/55.rst b/i2p2www/meetings/logs/55.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/55.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/56.log b/i2p2www/meetings/logs/56.log new file mode 100644 index 00000000..bbbab398 --- /dev/null +++ b/i2p2www/meetings/logs/56.log @@ -0,0 +1,210 @@ +[22:53] <jrand0m> ok, wtf, why not. agenda: +[22:53] <jrand0m> 0) welcome +[22:53] <jrand0m> 1) spec & sdk release +[22:53] <jrand0m> 2) spec & sdk questions +[22:53] <jrand0m> 3) dev status 3.1) co's NS 3.2) SDK 1.0 criteria 3.3) network simulator 3.4) other apps [IM, tunnel, etc] 3.5) more transports 3.6) java router implementation +[22:53] <jrand0m> 4) meeting time change? +[22:53] <jrand0m> 5) cvs administravia +[22:54] <jrand0m> 6) shardy's stuff +[22:54] <jrand0m> 7) peanut gallery +[22:54] <jrand0m> thazzit. +[22:54] <jrand0m> 0) welcome +[22:54] <w0rmus> hihi +[22:54] <thecrypto> so welcome everyone to meeting number 55 +[22:54] <thecrypto> 56 +[22:55] <thecrypto> 56 is correct +[22:55] *** Signoff: mihi (EOF From client) +[22:55] <jrand0m> hi. welcome to meeting 56 +[22:55] <jrand0m> yea +[22:55] <jrand0m> 1) spec & sdk release +[22:55] <w0rmus> haha +[22:55] *** mihi (~none@anon.iip) has joined channel #iip-dev +[22:55] <jrand0m> the specs are out and the sdk 0.2 is out as well. +[22:56] <jrand0m> currently, they're only available on freenet [http://localhost:8888/CHK@p1VU1U67UgXYJ7v7cS4Xqn~p4ssLAwI,RvdwV4jZyZYcJgYabpVPOQ/I2P_SDK.zip] +[22:56] <jrand0m> but nop told me he'd have them on the normal web today, as well as an email to a few of the traditional lists to round up some reviewers +[22:57] <jrand0m> 2) any new questions on the specs or the sdk? +[22:58] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev +[22:58] *** terrific (terrific@anon.iip) has joined channel #iip-dev +[22:58] <jrand0m> well, first question in there is, how goes the progress /reading/ the specs? :) +[22:58] <w0rmus> needa do that :) +[22:58] <thecrypto> slowlyu +[22:58] <w0rmus> therefore I have no questions +[22:58] <jrand0m> heh word +[22:59] <w0rmus> I'll start now then +[22:59] <jrand0m> suggested order of reading the PDFs is> I2POverview.pdf, then I2NP, then datastructures, then I2CP, then polling HTTP transport +[22:59] <w0rmus> ok I'll do it in that order then +[23:00] <jrand0m> ok. on to # 3 then, unless there are any q's on the specs +[23:00] <jrand0m> 3.1) co's naming service proposal +[23:00] <jrand0m> he posted rev 1.1 of his spec up to the mailing list this morning and it seems to deal with a lot of the issues brought up before +[23:01] <jrand0m> does anyone have any comments/questions on the spec that they want to say here? or should we just do that part on the list, since co isn't here atm? +[23:01] <mihi> how can one get the address of a name server? ;) +[23:02] <jrand0m> OOB, but good point. he should toss in a "bootstrapping" section +[23:03] <thecrypto> OOB? +[23:03] <jrand0m> out of band. e.g. from a web site or built into the software +[23:03] <thecrypto> ahh +[23:03] *** naphtala (asdf@anon.iip) has joined channel #iip-dev +[23:04] <jrand0m> (co may actually have different ideas, I'm just assuming thats what he meant. definitely something to mention on the list) +[23:04] <mihi> is there any general way to make a text representation of Destinations (e.g. ascii armor)? +[23:05] <jrand0m> no, we haven't needed to spec that yet, though offhand I'd probably suggest alt-base64 the Destination object per that rfc that was just released +[23:06] <jrand0m> perhaps that should be added to the I2P data structures spec. good idea. +[23:06] <jrand0m> does anyone have any qualms with base64? +[23:07] <jrand0m> ok. at least for now that'll get added in. +[23:08] <jrand0m> 3.2) SDK 1.0 criteria +[23:08] <jrand0m> SDK 0.2 does full end to end crypto for java, but there's still a lot to be done before the SDK is 1.0 ready. +[23:09] <jrand0m> the criteria I have jotted down for the sdk 1.0: all APIs and local only routers up to spec [there are two small mods left]. full Java, C, and Python client API implementations. +[23:09] <jrand0m> optionally, we may want to include a streaming API as well +[23:10] <jrand0m> does anyone else have any 1.0 criteria they'd like to see in the SDK? +[23:11] *** jnk (jnk@anon.iip) has joined channel #iip-dev +[23:11] <jrand0m> ok. post to the list if you think of anything +[23:11] <jrand0m> 3.3) network simulator +[23:12] <jrand0m> sometime when someone has spare time, there should be efforts made on simulating the i2p net per i2np. the performance models used so far are limited in that they do not take into consideration resource contention among different users +[23:13] <jrand0m> there are good tools out there, and i've got some sketches down already of how to run this, but I'm just mentioning this now in case anyone is looking for a project ;) +[23:14] * jrand0m utterly fails to keep a straight face wrt the likelyhood of someone jumping up and writing a simulator +[23:14] <jrand0m> ok. 3.4) other apps +[23:14] <w0rmus> haha +[23:14] *** Signoff: mihi_backup (Ping timeout) +[23:14] * thecrypto jumps up...and writes something else +[23:14] <jrand0m> heh +[23:15] <jrand0m> mihi> any mods/updates/plans for the i2ptunnel? +[23:17] <mihi> nope. +[23:17] <jrand0m> cool, just checkin' in :) +[23:17] <mihi> if someone writes a TCP layer for I2P, i might use it, but I wont write it. +[23:18] <jrand0m> ah word. yeah, thats the streaming api thing. no worry, using GUARANTEED works and is a perfect use for local only routers +[23:18] *** Trifixion (~lame-o@anon.iip) has joined channel #iip-dev +[23:19] <jrand0m> and in a production environ waiting for an ACK before sending the next message is only a ~.4s delay +[23:19] <jrand0m> <insert caveat on latency models here> +[23:19] <jrand0m> ok. next "other apps" +[23:20] <jrand0m> thecrypto> IM? +[23:20] <thecrypto> well, i'm working on a UI prototype right now +[23:20] <thecrypto> as soon as we have some way of communicating with other people, i can just put in the networking stuff +[23:20] <jrand0m> we /have/ some way of communicating with other people +[23:21] <jrand0m> (not that I'm against doing it in pieces anyway) +[23:21] <thecrypto> i'm going to start with just UI +[23:21] <jrand0m> wikked. +[23:21] <w0rmus> I do wish to help thecrypto with the IM but I've some reading to do +[23:21] <thecrypto> once all the UI is done, whoever is working on this will just have to plug in the networking stuff and we'll be done' +[23:22] <jrand0m> nice +[23:22] <thecrypto> and i thought we only had local only unless you want to tunnel? +[23:22] <jrand0m> will the UI have an address book feature for storing destinations of friends? +[23:22] <thecrypto> buddy list +[23:23] <thecrypto> we'll have to poll the name server somehow to check when people are online +[23:23] <jrand0m> right, local only, but you can still run multiple instances and talk to itself through the SDK. same way normal network dev goes against localhost +[23:23] <jrand0m> hmm, the IM app will depend on the name server? +[23:23] <jrand0m> or will the IM have a central "presence" server? +[23:23] <thecrypto> it'll need someway to keep track of everyone +[23:23] <thecrypto> i'm trying to avoid central anything +[23:24] <thecrypto> but some sort of distributed presense would have to be thought up and it looks like the NS will do that +[23:24] <jrand0m> I don't think the NS has presence. it only says what the Destinations are +[23:24] <jrand0m> (for each service for each nym) +[23:25] <thecrypto> but doesn't it have an online offline state? +[23:25] <jrand0m> no, the NS is just like DNS. it doesn't tell you if the host is reachable. +[23:25] <thecrypto> at least i thought it do +[23:25] *** mihi_backup (~none@anon.iip) has joined channel #iip-dev +[23:25] <thecrypto> so you have to try it to find out +[23:26] <thecrypto> then i'll have to come up with my own spec to work out that part +[23:26] <jrand0m> coo'. perhaps start without one, and maybe add a rudimentary periodic ping, and then a fully distributed whatever ;) +[23:27] <thecrypto> well step 1 is UI +[23:27] <jrand0m> anyway, you know best, whatever works for ya. if there's anything anyone can do to help, just say the word +[23:27] <jrand0m> right +[23:27] <jrand0m> ok. I don't have any other apps to discuss in the "other apps" section. anyone else have app related ideas / discussion? +[23:28] <thecrypto> well what apps do we have planned already other than IM and NS and Tunnel? +[23:29] <w0rmus> will file transfer be implemented along with IM or separately? +[23:29] <w0rmus> separately I imagine +[23:29] <thecrypto> you will be allowed to file transfer IM, but other people can come up with file transfer only protocols like FTP +[23:29] <w0rmus> ok so what you're working on will have file transfer as well +[23:29] <jrand0m> thecrypto> I'd like to see an http proxy (perhaps ripping the code from JAP), as well as a plugin for a web server to allow I2P web publishing and browsing +[23:30] <thecrypto> IE replace freenet :) +[23:30] <jrand0m> a multiplexing "outdial" tcp tunnel would be cool too +[23:30] <jrand0m> naw, freenet is a CDN, this would require having a server to store space on +[23:31] <thecrypto> okay +[23:31] <jrand0m> (the outdial would probably require SOCKS integration though) +[23:32] <jrand0m> that it for the top of my head though. with mihi's tunnel we can already ssh and cvs over i2p +[23:32] <jrand0m> ok. 3.5) more transports +[23:33] <jrand0m> we need more transports (TCP, UDP, Email). realistically, this will probably be spec'ed and implemented in line with the router reference implementation. +[23:33] <jrand0m> but if someone wants to look at the polling HTTP transport and define some other transport, that'd be fantastic +[23:33] <thecrypto> transports kinda like the jabber transports +[23:33] <thecrypto> translating one to another? +[23:34] <jrand0m> hmm? transports are the actual means of sending bytes from one router to another. +[23:34] <thecrypto> ahh okay +[23:34] *** jnk has left #iip-dev +[23:34] <thecrypto> so instead of just one method of getting the bits from one router to another there are many? +[23:34] <jrand0m> exactly. +[23:34] <jrand0m> I2NP does /not/ specify a particular transport +[23:35] <thecrypto> so if one is firewalled/blocked/slow/... you use another +[23:35] <jrand0m> exactly +[23:35] <thecrypto> sweee +[23:35] <w0rmus> yah that sweet :) +[23:35] <jrand0m> ok, 3.6) java router reference implementation +[23:36] <jrand0m> I'll probably have an architecture doc and some rapid prototypes ready this week. nothing whatsoever will work, but it'll show how things will fit together. +[23:36] <jrand0m> then individual subsystems can be stub'ed and implemented in turn (or in parallel). +[23:37] *** Signoff: mihi (EOF From client) +[23:37] <jrand0m> so probably by end of week or perhaps next weeks meeting I'll be making a call out for java devs to jump in and get coding :) +[23:37] <thecrypto> can do +[23:38] <jrand0m> w3wt +[23:38] <w0rmus> hopefully can do :) +[23:38] <jrand0m> word +[23:38] <jrand0m> ok. any other dev status questions / thoughts / comments? +[23:39] <w0rmus> thecrypto: is anyone else working on the IM with you as of now? +[23:39] <thecrypto> co should be +[23:39] <w0rmus> is co cohesion? +[23:39] <thecrypto> but right now i'm just getting the UI started +[23:39] * jrand0m thinks co will havea /LOT/ of work with the naming service +[23:39] <thecrypto> no co == whit +[23:39] <jrand0m> no, co is wiht, cohesion is a different person :) +[23:39] <w0rmus> ok thanks +[23:40] *** mihi (~none@anon.iip) has joined channel #iip-dev +[23:40] <thecrypto> if it was cohesion then we would use tab compleletion +[23:40] <jrand0m> heh +[23:40] <w0rmus> some people are too lazy for even that +[23:41] <jrand0m> ok. agenda item 4) meeting time change +[23:41] <jrand0m> is anyone here further east than GMT+2? +[23:41] <jrand0m> you don't need to answer that... +[23:41] <jrand0m> er, is anyone here already pushed to their limit of lateness with 9PM GMT meeting time? +[23:41] * mihi_backup is gmt+2 +[23:42] <jrand0m> ah cool. would later work for you mihi, or is 9p best? +[23:42] * jrand0m doesn't go to bed until after the sun rises in gmt+2 +[23:42] <mihi_backup> not much later. 8p or 7p would be better +[23:42] <jrand0m> ah 'k +[23:42] <mihi_backup> but if i can't come; i'll read the log. +[23:43] *** Signoff: cohesion (class) +[23:43] <jrand0m> well, we have no hard reason to make it later and its good to have you here ;) +[23:43] <thecrypto> i say it's perfect where it is +[23:44] <jrand0m> cool. I just wanted to bring it up to possibly help out the left coast 'mericans who have jobs :) +[23:44] <jrand0m> but 9P GMT it is and 9P GMT it stays +[23:44] <jrand0m> ok. item 5) cvs administravia +[23:45] <jrand0m> well, none of the python people are here, and thecrypto and I have already spoken re: cvs module conventions :) +[23:45] <jrand0m> we still are working on getting anon cvs +[23:45] <jrand0m> or at the very least nightly snapshots of the cvs on the web. +[23:45] <jrand0m> that'll be announced once its ready. +[23:46] <thecrypto> most of the reason for limiting access to to make sure not too many people start getting at it +[23:46] <thecrypto> before it's ready +[23:46] <jrand0m> right, but the SDK has the full source of everything in the tree atm anyway ;) +[23:47] <jrand0m> but thats a good point. perhaps we can change perms on the dirs for the router ref impl as it progresses until its ready +[23:47] <jrand0m> dunno though. we'll cross that bridge when it comes +[23:47] *** Trifixion has left #iip-dev +[23:48] <jrand0m> item 6) shardy's stuff +[23:48] * jrand0m waves to shardy +[23:48] <shardy> hiya +[23:48] <shardy> um, I don't really have much of anything to say +[23:48] <shardy> just thought I'd say hi and all +[23:48] <shardy> seeing as how I've got myself involved in the project latey :) +[23:48] <shardy> lately. +[23:48] <w0rmus> hihi +[23:49] <shardy> I don't have a ton of time until thesis/toorcon are both done, but I'll help out with what I can do until then +[23:49] <shardy> like if you need random code debugged, or crypto implemented, or optimized +[23:49] <shardy> the next thing I'm probably going to look at is optimizing the hell out of the crypto engine... I have a lot of experience doing that kind of stuff +[23:49] <jrand0m> cool. we'll probably want to pick your brain as the crypto gets implemented for the routers and we pull in yarrow or another prng +[23:49] <jrand0m> nice +[23:50] <shardy> I'll be hanging around, so grab me for whatever if you need anything. +[23:50] <thecrypto> yah +[23:50] <jrand0m> wikked. +[23:50] <jrand0m> ok. 7) peanut gallery +[23:50] <jrand0m> any i2p thoughts / comments / questions / concerns? +[23:52] <jrand0m> ok then :) +[23:52] *** naphtala has left #iip-dev +[23:52] <w0rmus> i2p is neat +[23:52] <jrand0m> heh +[23:52] <w0rmus> ;0 +[23:52] * jrand0m pulls the *baf* off the wall... +[23:53] <jrand0m> ... the wind-up +[23:53] <jrand0m> and the *baf* diff --git a/i2p2www/meetings/logs/56.rst b/i2p2www/meetings/logs/56.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/56.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/57.log b/i2p2www/meetings/logs/57.log new file mode 100644 index 00000000..fee52875 --- /dev/null +++ b/i2p2www/meetings/logs/57.log @@ -0,0 +1,165 @@ +[22:57] <jrand0m> ok, buenos noches srs y srtas +[22:57] <jrand0m> agenda: +[22:57] <jrand0m> 0) welcome +[22:57] <jrand0m> 1) cvs +[22:57] <jrand0m> 4) naming service +[22:58] <co> You forgot 5) questions. +[22:58] <jrand0m> 3) dev status +[22:58] <jrand0m> 2) spec questions? +[22:58] <jrand0m> 5) other questions? +[22:58] <jrand0m> oh, shit, I forgot to reorder those. ok. they're numbered incorrectly :) 0 == 0, 1 == 1, 4 ==2, 3 == 3, 2 == 4, 5 == 5 +[22:59] <jrand0m> lets see if I can keep that straight as we go... +[22:59] <jrand0m> ok, 0) welcome +[22:59] <shardy> yay for permutation groups! +[22:59] <jrand0m> welcome to meeting 57 +[22:59] <jrand0m> yeah, they're all just symbols anyway +[22:59] <w0rmus> sweet whatup ;0 +[23:00] <w0rmus> I'll help comprise peanut gallery +[23:00] <jrand0m> 1) cvs is still down, after 10+ days. we're finding a new host. +[23:00] <jrand0m> sf.net sucks, and I have no reason to believe gnu's nongnu is better. +[23:00] <co> jrand0m: Why not make that host have the alias "cvs.invisiblenet.net"? +[23:00] <jrand0m> nop is leading the charge on finding the new host. +[23:01] <jrand0m> sure co, once we get the server +[23:01] <shardy> what do you need for a host? +[23:01] <jrand0m> shardy> reliable net connection, ssh/cvs access. and some disk space +[23:01] <shardy> do you have something lined up? +[23:01] <shardy> because if not. I may be able to assist. +[23:02] <jrand0m> awesome! I don't know what nop has lined up, but I'll have him check in with you (unless he's here now?) +[23:02] * w0rmus taps nop +[23:03] <shardy> I've got 1.1 business sdsl. I'd need to find a machine. but as long as you're not using uber amounts of bandwidth I could probably host the server. +[23:03] <shardy> how much disk space would you need? +[23:03] <jrand0m> the repository currently comprises ~ 6Mb. so probably 50M would handle growth for a good while +[23:04] <shardy> oh. pfft. that's nothing. +[23:04] <shardy> and the machine wouldn't need to be super fast? +[23:04] <shardy> you wouldn't be doing big compile jobs on it? +[23:04] <jrand0m> naw, a 286 would probably do it. +[23:04] <jrand0m> no, strictly cvs checking / checkout +[23:04] <jrand0m> (well, and diff, and log, etc ;) +[23:05] <jrand0m> "we're java, we don't need compile farms" </fark> +[23:05] *** Signoff: cohesion (class) +[23:05] <w0rmus> do people concerned with anonymity access CVS using something like JAP? I've never used CVS +[23:05] <jrand0m> w0rmus> I use cvs through a private series of ssh proxies +[23:05] <co> jrand0m: Keep in mind that a C or C++ implementation may be likely in the future. +[23:06] <mihi> jap does not allow cvs access AFAIK :( +[23:06] <w0rmus> ssh tunnelling +[23:06] <shardy> let me see what I can do. someone said they were going to give me another drive... if I can get a disk I have a machine I can toss up. +[23:06] <jrand0m> oh, of course co. I just don't expect we can require a cvs repository to necessarily be a compile farm as well. +[23:07] <jrand0m> awesome shardy. there's anything we can do, just say the word. +[23:07] <co> jrand0m: You are right. They should be separate. +[23:07] <shardy> will do. let me scrounge for a drive, I should be able to get one, and if I do I'd be happy to host the cvs for everyone. +[23:07] <jrand0m> shardy++ +[23:07] <w0rmus> yay ;0 +[23:07] <jrand0m> ok, 4) naming service +[23:08] <jrand0m> co, how goes? +[23:08] <co> I am still writing, but would like to say a few words about it. +[23:08] <co> First, to address a question from thecrypto during the last meeting, the NS does not provide notification of someone's being online. +[23:09] <co> It merely says that a person can be contacted via certain methods, such as AIM. +[23:09] <co> Second, the client side. +[23:09] <co> There will be an API which programs can use to make queries to naming servers. +[23:10] <co> The underlying mechanism will read a configuration file of which servers to query, will use the I2P network to obtain the results, and will pass the results back to the caller. +[23:11] <co> The underlying mechanism will also read the destination mechanism for the local router to contact from a file. +[23:11] <jrand0m> the destination mechanism? +[23:11] <co> I'm sorry, the destination address. +[23:11] <jrand0m> ah 'k +[23:12] <co> That is all at this time. +[23:12] <jrand0m> cool +[23:12] <w0rmus> I agree +[23:12] <w0rmus> ;) +[23:12] <jrand0m> any ballpark ideas on timelines for various milestones? +[23:13] <jrand0m> obviously nothing anyone could hold you to, of course, just wondering +[23:13] <co> Let's say end of the week for finishing the specification and publishing it and the API. +[23:14] * mariesofie arrives late +[23:14] <jrand0m> ah nice co +[23:14] <co> Then, I will start implementing it. I am not certain how long that will take, though. +[23:14] <jrand0m> understandable +[23:15] <jrand0m> anyone else have any naming service questions/thoughts? +[23:15] <jrand0m> ok, 3) dev status +[23:16] <jrand0m> dev goes well. +[23:16] <jrand0m> the java side is up to spec and implements all I2CP and I2NP messages and structures +[23:17] <jrand0m> the java architecture itself is functional and I'm going to continue stubbing out the various subsystems +[23:17] <co> Have you tested it? +[23:17] <jrand0m> the messages & structures? yes via the TestData harness in net.invisiblenet.i2p.data.test +[23:17] <co> I mean connecting two different computers with I2P. +[23:18] <jrand0m> oh, no, thats requires the full implementation of the communication subsystem +[23:18] <co> I see. +[23:18] <jrand0m> first I'm building the various subsystems to operate in test mode, then implementing the various subsystems so they can operate in isolation +[23:19] <jrand0m> we're probably 2 weeks off from a client sending a message to a client on a different router +[23:19] * mariesofie cheers +[23:20] <jrand0m> there's still a lot of work to be done after that before the alpha, but thats progress +[23:21] <jrand0m> the datastrucutres and i2np specs need about a dozen small modifications that I've been accumulating during the implementation to address things overlooked. e.g. "datastructures p11, TunnelSigningPublic/PrivateKey should contain SIGNING Public/Private keys" and "i2np p15, TunnelCreateStatus - add hash of the replying RouterIdentity" +[23:21] <shardy> man. i really need to read up on the specs. +[23:22] <jrand0m> well, they'll soon be hosted on your machine so it'll be easy :) +[23:22] <w0rmus> haha +[23:22] <w0rmus> I have not finished specs either +[23:23] <mariesofie> i printed the specs, read them so many times it got worn out and i had to print out another copy +[23:23] <jrand0m> from discussions I've had with various people, I've found the specs aren't that great at conveying how the thing actually works. they cover the fuzzy stuff and the nitty gritty, but not why the nitty gritty meets the why +[23:23] <w0rmus> heh +[23:23] <jrand0m> rofl mariesofie +[23:23] <jrand0m> ok, thats it for 3) dev status +[23:24] <jrand0m> now for 2) spec questions +[23:24] <w0rmus> I suppose I'll read them instead of stupid calculus +[23:24] <co> I am thinking a little bit into the future. +[23:24] <co> The python and C or C++ implementations will need to have message data readable by the Java implementation. +[23:24] *** Signoff: mihi (EOF From client) +[23:25] <jrand0m> correct co +[23:25] <co> How will you accomplish that? +[23:25] <jrand0m> the datastructures spec specifically defines the byte layouts +[23:25] <jrand0m> and everything is big endian and all numbers are unsigned +[23:25] <mariesofie> what level of technical knowledge are you targetting the specs for? anyone with decent comp. knowledge? college level CS engineer students? +[23:25] <co> Oh, all right. +[23:25] *** mihi_ (~none@anon.iip) has joined channel #iip-dev +[23:26] <mariesofie> i.e. who is the target audience? +[23:26] *** mihi_ is now known as mihi +[23:26] <jrand0m> mariesofie> well, those specs were really targeted haphazardly. i2p_philosophy was the "ok, wtf is this all about", but the rest of the specs were targeted towards people interested in actually implementing the system +[23:26] <jrand0m> we really really need some docs that go in the middle +[23:27] <mariesofie> i see +[23:27] <mariesofie> I found the API docs are very easy to understand and useful, but ironically I still get mixed up when reading the I2NP specs trying to understand the core architecture +[23:28] <mariesofie> maybe thats reflective on me more than the documentation :) +[23:28] <jrand0m> heh geek :) +[23:29] <jrand0m> ok, any other questions on the specs? lets move on to 5) other questions +[23:29] <jrand0m> anyone have any other questions? this is our last bullet point on the meeting agenda +[23:30] <w0rmus> I wonder where thecrypto is with achat +[23:30] <jrand0m> ah, thecrypto is offline for the next three weeks or so +[23:30] <mihi> what happens with peer review? +[23:30] <w0rmus> or atalk +[23:30] <w0rmus> wow +[23:30] <mihi> is anyone reviewing it? +[23:30] <mariesofie> i thought thecrypto has 2hrs per day +[23:31] <w0rmus> and I can't even see the codes he has :( +[23:31] <jrand0m> mihi> reviews have been sent to various people for review and as feedback comes it will be addressed. +[23:31] <jrand0m> w0rmus> do you have any questions on ATalk? +[23:32] <shardy> I will be reviewing it as soon as I have time :) +[23:32] <mihi> i meant, did any feedback come till nowß +[23:32] <w0rmus> I suppose not +[23:32] <mihi> s/nowß/now?/ +[23:32] <jrand0m> mihi> largely in the form of discussions and clarifications +[23:32] <jrand0m> awesome shardy :) +[23:33] <Brownspider> hapy birthday google +[23:33] <jrand0m> mariesofie> right, but thats not even enough time for him to d/l the java lang docs to continue dev :/ +[23:33] <w0rmus> ahaha wtf +[23:35] <jrand0m> ok, any other questions / thoughts? +[23:35] <w0rmus> I guess I should mention that I've never coded outside of school +[23:35] <w0rmus> but I gotta start somewhere anyways +[23:35] <jrand0m> now's a good time to start :) +[23:35] <jrand0m> word +[23:35] <w0rmus> ;0 +[23:35] <mariesofie> i have questions on the api, but not yet, in a day or two when i can try it out some more +[23:35] <w0rmus> I've taken 2 years of java or so +[23:36] <jrand0m> ok cool mariesofie, just bounce a msg to the list or bounce me a message here whenever +[23:37] <co> mariesofie: Have you read the discussion on the iip-dev mailing list? +[23:37] <w0rmus> where is it archived? +[23:37] <jrand0m> http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel +[23:37] <jrand0m> (fairly low traffic atm) +[23:38] <Brownspider> jrand0m wants you code something that can not logicly exist, to tear the world usunder, to end the reign of god. +[23:38] <shardy> my services are still offered if you need any crypto cores or such written or debugged. +[23:39] *** M123456789 (~no@anon.iip) has joined channel #iip-dev +[23:39] <co> Brownspider: huh? +[23:39] <Brownspider> co, it was on his freesite, nevermind +[23:40] <jrand0m> great shardy, I have a feeling we're going to need some once the routers get up and running, and especially when we get the C/Python APIs back up to spec +[23:40] <mariesofie> co> i've only read back to about issue #52 or so +[23:42] <jrand0m> ok. any last words (as I eye the *baf*er...) +[23:43] *** mihi_backup_ (~none@anon.iip) has joined channel #iip-dev +[23:43] *** Signoff: mihi_backup (EOF From client) +[23:43] *** mihi_backup_ is now known as mihi_backup +[23:43] <jrand0m> ok great. next week, same bat time, same bat place. +[23:44] * jrand0m *baf*s the meeting to an end diff --git a/i2p2www/meetings/logs/57.rst b/i2p2www/meetings/logs/57.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/57.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/58.log b/i2p2www/meetings/logs/58.log new file mode 100644 index 00000000..835480fc --- /dev/null +++ b/i2p2www/meetings/logs/58.log @@ -0,0 +1,309 @@ +[22:53] <jrand0m> 0) welcome +[22:54] <jrand0m> 1) apps: +[22:54] <jrand0m> 1.1) IM +[22:54] <jrand0m> 1.2) NS +[22:54] <jrand0m> 2) dev status: +[22:54] <jrand0m> 2.1) subsystems +[22:54] <jrand0m> 2.2) encryption key persistence +[22:54] <jrand0m> 2.3) todo +[22:54] <jrand0m> 3) spec stuff +[22:54] <jrand0m> 3.1) mods +[22:54] <jrand0m> 4) administravia: +[22:54] <jrand0m> 4.1) anon cvs +[22:54] <jrand0m> 5) ? +[22:55] <jrand0m> ok, 0) welcome +[22:55] <jrand0m> welcome to meeting 58 +[22:55] <thecrypto> that all +[22:55] <jrand0m> si sr, unless anyone else has things to add? +[22:55] * nop notices jrand0m is object oriented with his numbering :) +[22:56] <nop> 3.1.2.2.4.5.8() ;) +[22:56] <jrand0m> hey, they could be structs ;) +[22:56] <nop> haha +[22:56] <nop> that is definitely true +[22:56] <jrand0m> ok, 1.1) IM. thecrypto? +[22:56] <nop> although +[22:56] <nop> 2 has inheritance +[22:57] <nop> ;) +[22:57] <jrand0m> heh +[22:57] <nop> nevermind me +[22:57] <nop> ok +[22:57] <nop> sorry +[22:57] <nop> continue +[22:57] *** mihi_ (~none@anon.iip) has joined channel #iip-dev +[22:57] <thecrypto> okay, right now i'm uploading some basic specs for IM +[22:58] <thecrypto> (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw for oowriter +[22:58] <thecrypto> and i'm working on uploading the pdf +[22:58] <nop> if you want I can put on i2p site +[22:59] <thecrypto> give me a second +[22:59] <thecrypto> sure +[22:59] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev +[22:59] <jrand0m> do you want to put that into i2p/apps/IM/doc/ ? +[22:59] *** mihi_ is now known as mihi_backup +[23:00] <nop> I can +[23:00] <nop> yes +[23:00] <jrand0m> I meant in cvs :) +[23:00] <thecrypto> i can do that too +[23:00] <jrand0m> (but on the web is good too) +[23:00] <nop> oh +[23:00] <nop> haha +[23:00] <thecrypto> (Link: http://www.thecrypto.org/i2pim.pdf)http://www.thecrypto.org/i2pim.pdf +[23:01] <MrEcho> "the file is damaged and could not be repaired" AR error +[23:01] <thecrypto> try again +[23:01] * jrand0m loaded it fine +[23:01] <co> MrEcho: The PDF file? +[23:01] <jrand0m> (the sxw) +[23:01] <thecrypto> only partially uploaded at that time +[23:01] <MrEcho> now it works +[23:01] <MrEcho> hehe +[23:02] <thecrypto> basicall i just put in the presence stuff, online offline messages, and a message message +[23:02] <thecrypto> i shameless ripped some sections from the I2NP documenty +[23:02] <thecrypto> :) +[23:02] <jrand0m> heh I thought some of it looked familiar :) +[23:02] <thecrypto> i'm also working on uploading the UI i +[23:02] <thecrypto> i've been working on +[23:03] <thecrypto> jrand0m: do i need to create the dirs apps/IM/doc +[23:03] <jrand0m> yes, and cvs add them individually +[23:03] <thecrypto> -kb? +[23:03] <jrand0m> yes +[23:03] <co> thecrypto: I believe apps/ is there now. +[23:04] <jrand0m> whats a presence? +[23:05] <thecrypto> let me run update +[23:05] <thecrypto> but it's getting in there +[23:05] *** Signoff: shardy (Ping timeout) +[23:05] <thecrypto> i'm just saying rip apart the specs +[23:05] <thecrypto> and the UI will be in there soon as well +[23:05] <thecrypto> and if you have anything that needs to be clarified then anonymail, e-mail, anything me and i'll fix it +[23:05] <mrflibble> did i miss the meeting? +[23:05] *** shardy (~shardy@anon.iip) has joined channel #iip-dev +[23:05] <co> thecrypto: You might want to announce it on the e-mail list, as well, with a link to the documents. +[23:05] <thecrypto> i thought i put that in there? +[23:05] <jrand0m> nope still on the first item point mrflibble +[23:05] <co> mrflibble: Meeting is in progress. +[23:05] <mrflibble> oh sorry, just couldnt see "logger" +[23:06] <jrand0m> thecrypto> you state that its a destination, but is that the destination at which to send messages? how do offline messages work? +[23:06] <mihi> no mids here, so no logger ;) +[23:06] <mrflibble> k +[23:06] * mrflibble goes back to lurking +[23:06] <jrand0m> oh wait, these are just presence notifications, sorry +[23:06] <mihi> how can one subscribe to a presence? +[23:06] <thecrypto> jrand0m: no offline messages +[23:07] <thecrypto> basically +[23:07] <thecrypto> the presence just wraps a destination and a name together +[23:07] <thecrypto> to make things easy +[23:08] <thecrypto> so if we want to move onto NS we can do that, and we can come back to this later? +[23:09] <jrand0m> 'k cool +[23:09] <thecrypto> and you can still message me questions +[23:09] <jrand0m> actually, one quick question +[23:09] <thecrypto> shoot +[23:09] <jrand0m> so the IM is strictly text only? +[23:10] <thecrypto> with this basic one yes, but i will be adding file support in +[23:10] <jrand0m> coo' +[23:10] <thecrypto> i just want the beginnings of the system taken care of and build on it +[23:10] <jrand0m> (iterative and incremental)++ +[23:11] <jrand0m> ok great. I'll go through this further and other people should too... for now, moving on to 1.2) NS. co? +[23:11] <co> Version 1.1 (final) of the naming service specification was released earlier today. +[23:12] <jrand0m> (and there was much rejoicing) +[23:12] <co> Basically, I finished the sections on the data structures and network messages that the program needs. +[23:12] <co> I will be releasing the client API on Thursday. +[23:12] <co> And will begin implementing the NS application. +[23:12] <jrand0m> great +[23:13] <co> One idea that has changed is what the CA does when entities register with it. +[23:13] <thecrypto> co: how will you be implementing it? +[23:13] <thecrypto> co: the name server or the client? +[23:14] <co> thecrypto: Well, first I will implement the data structures necessary. +[23:14] <co> Then, the client, then the server and CA components. +[23:14] <thecrypto> okay +[23:15] <co> As I was saying, I now would like the CA to issue a certificate to newly registered entities. +[23:15] <co> They will present this certificate to naming servers when modifying their records. +[23:15] <co> I have not specified what the certificate contains in this version; that will go into the next version of the specification. +[23:16] <co> Does this strike anyone as a bad idea? +[23:16] <jrand0m> hmm. wouldn't it be simpler / safer to just have the client use a public key / private key? +[23:16] <jrand0m> aka during register, provide a public key for updates and sign the registration, and whenever you want to update again, sign an update +[23:16] <jrand0m> (so that hte CA never gets the private key) +[23:17] <thecrypto> Sidenote: all the I2PIM stuff is now committed to the cvs respository +[23:17] <jrand0m> great +[23:17] <co> It may be simpler to do just that. I will re-think this issue. Thank you for the comment. +[23:17] <co> That is all I have to discuss for the naming service at this time, if you have no other questions. +[23:18] <jrand0m> its lookin good, I haven't gone through the 1.1 yet but I'll email if I come across something +[23:19] <co> OK. Next topic? +[23:19] <jrand0m> ok, 2.1) dev status for subsystems. +[23:19] *** w0rmus (o0o@anon.iip) has joined channel #iip-dev +[23:20] <jrand0m> transport subsystem is good 'nuff to move forward. peer management subsystem is stubbed with stupid algorithms but functional. network db, tunnel management, and stats management subsystems are still pending. client subsystem will be trivial (just reusing the SDK local only router) +[23:21] <co> What do you mean by stupid algorithms? +[23:21] <w0rmus> not fast? +[23:21] <jrand0m> eh, the peer management subsystem isn't keeping track of peer performance, its just returning random peers. +[23:22] <jrand0m> the algorithm will be updated and tuned as things progress to more adequately provide peer selection +[23:22] <jrand0m> current task on my plate is building and handling garlic messages, which is a PITA. +[23:23] <jrand0m> but workable, just annoying +[23:23] <jrand0m> that actually leads into 2.2) encryption key persistence. +[23:24] <jrand0m> garlic messages use ElG+AES encryption to wrap the layers of the cloves +[23:24] <jrand0m> and private keys are used in other places (transport, client management) +[23:25] *** Signoff: thecrypto (Ping timeout) +[23:25] <jrand0m> keeping private and session keys always in memory and never on disk is ideal, but sucks for times when the router goes down (either intentionally or by fault) +[23:26] <jrand0m> does anyone have any thoughts for whether we should 1) never write the keys to disk and risk excessive unnecessary message loss (since they won't be decryptable) 2) encrypt them before writing to disk or 3) just write them to disk plain? +[23:26] <co> Option 2. +[23:27] <nop> jrand0m option 2, or do what we said before +[23:27] <nop> we must trust localhost +[23:27] *** Signoff: cohesion (class) +[23:27] <nop> we assume localhost is not compromised +[23:27] <jrand0m> the kooky thing about option 2 is that it either the user will have to enter a pass phrase to start the router, or the session key will be knowable +[23:27] <jrand0m> good point nop. +[23:28] <nop> again we are a transport, we can't worry about that as much, that can be modified on client end, or we could give them options +[23:28] <nop> depending on paranoia level +[23:28] <nop> security vs convenience measure +[23:29] <co> Then I propose having 3 by default, and giving the user the option to use 2. +[23:29] <nop> exactly +[23:29] <jrand0m> right. ok, the good thing is that people can (and should!) take the router code and modify it for that tradeoff - a "tinfoil I2P router" and a "jane sixpack I2P router" +[23:29] <jrand0m> ok, cool, I'll just go with the simple 3) for now then +[23:30] <jrand0m> ok 2.3) todo +[23:30] * co would like to revisit the NS topic at the end of the meeting. +[23:30] * nop needs to finish reading the NS email +[23:30] <jrand0m> 'k, you're item #5 now +[23:30] <co> I can wait until the end. +[23:31] <jrand0m> mihi put together some tests to point out some bugs in the SDK impl. some fixed already, some not. fixing them is on the todo :) +[23:32] <jrand0m> also, there have been about a dozen changes to various specs. once I get time I'll update the docs and push 'em out, though I may just put up an errata page on the wiki in the meantime +[23:33] <nop> word +[23:34] <jrand0m> other todo's... um, I fixed the "Wrong Size generating key" thing this morning plus a few random bugs +[23:34] <jrand0m> ok, thats it for dev status. 3) spec stuff +[23:35] <jrand0m> 3.1) see todo re: mods. there have been mostly typographical changes, I came across a slightly larger one today when implementing the garlics. still no prob, just requires moving around some data structures and doing some fancy footwork with the encryption. I'll get that in the errata. +[23:35] <jrand0m> 3.2) [I know, this one wasn't on the agenda, but here it is anyway] spec questions +[23:35] <shardy> (brb, I'm still lurking if you need me) +[23:35] <jrand0m> anyone have any questions on any of the specs? +[23:35] <jrand0m> cool shardy +[23:36] <co> jrand0m: Please tell us again which spec is in which document. +[23:37] <jrand0m> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs has 'em mapped out +[23:37] <co> I will look at it. +[23:38] <jrand0m> (looking at that it reminds me I need to document the secure reliable UDP transport. yet another todo...) +[23:39] <jrand0m> there have been some questions from various people wrt what specs to look at - basically, unless you want to know how the routers work (or you want to help implement them), you won't need to read the I2NP spec. I2CP and the I2CP section of the data structures is good enough +[23:40] <nop> jrand0m +[23:40] <jrand0m> si sr? +[23:41] <nop> do you mean actual UDP as in UDP packets +[23:41] <nop> or UDP as in a general UDP protocol +[23:41] <jrand0m> yes, UDP as in UDP packets +[23:41] <nop> for I2P +[23:41] *** thecrypt1 (~thecrypto@anon.iip) has joined channel #iip-dev +[23:41] *** thecrypt1 is now known as thecrypto +[23:41] <jrand0m> i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp for the implementation +[23:42] <thecrypto> back +[23:42] <jrand0m> wb +[23:42] <thecrypto> anyone want to send me what happened while i was gone? +[23:43] <jrand0m> the UDP impl is a pretty simple one - it does a DH exchange and messages are split into 1K packets and AES256 encrypted with the generated key +[23:43] <jrand0m> rekeying is supported though not automatic atm +[23:43] <jrand0m> ACKs are sent back in bundles (aka "I received all packets for message 42 up through packet 18 but not 3 or 7") +[23:44] <jrand0m> (and the practical reason why I went with the UDP impl before the TCP impl is UDP gives 'free' asynchronous IO with nearly 0 overhead) +[23:45] <nop> of course +[23:45] <jrand0m> there are two things left to do in that udp impl - station to station it for MITMs and add a packet for "oh shit, I forgot the session key" +[23:45] <nop> good +[23:46] <jrand0m> after the UDP transport the next one I want to implement is the polling HTTP - so we will have support for both the common user (UDP) and the firewalled / nat'ed / proxied user (polling http) +[23:47] <jrand0m> ok, so, yeah, that needs to get doc'ed up into a spec :) +[23:48] * jrand0m !thwaps self for coding before specing +[23:48] <thecrypto> coding before specing helps me +[23:48] <jrand0m> yeah, it works best iteratively +[23:48] <jrand0m> (as we're finding problems with the specs by implementing them, etc) +[23:49] <jrand0m> ok, thats 3) specs. 4) administravia +[23:49] <jrand0m> 4.1) anon cvs. thecrypto? :) +[23:49] <thecrypto> just in the nick of time +[23:49] <thecrypto> well, i'm looking into it, i think 2401 is currently blocked +[23:49] <jrand0m> can you cvs -d :pserver: locally? +[23:49] <thecrypto> and there might be some inetd stuff to do as well thanks jrandom +[23:50] <jrand0m> ah coo' +[23:50] <thecrypto> let me test that i forgot you cood do that :) +[23:51] <thecrypto> would it just be cvs -d :pserver: ? +[23:51] <jrand0m> cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p +[23:52] <jrand0m> also, it'd be great if we could get a bugzilla on there too +[23:52] <thecrypto> acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused +[23:52] <jrand0m> 'k, after adding the inetd.conf line and kill -HUP identd? +[23:52] <thecrypto> let me try that inet line and i'll get back to you +[23:52] <jrand0m> er, inetd :) +[23:52] <jrand0m> 'k cool +[23:53] <thecrypto> does the pserver go on the same line? +[23:53] <jrand0m> yes, thats all on one line +[23:55] <jrand0m> ok, thats it for administravia, at least that I can think of +[23:55] <jrand0m> 5a) co, you're up +[23:56] <co> When two people want to register the same entity name, the second is refused. +[23:56] <co> But if we use a signature-based approach, +[23:56] <co> the person who was refused could send a message to the naming server +[23:56] <co> anyway, telling it to modify the record. +[23:56] <co> There are two possibilities: +[23:57] <co> 1) CA sends the naming server a copy of the public key for the entity that was approved. +[23:57] <co> 2) CA sends the person who is registering a name a certificate, signed by its private key. The naming server will have the CA's public key to verify it. +[23:58] <co> If a malicious user tells the naming server to modify a certain record, the lack of a certificate would prevent the modification. +[23:58] <co> That is what I was thinking. +[23:59] <jrand0m> but in that case the CA knows the key - asym crypto would mean the CA only ever knows the public key, plus the CA would never want to or need to give that public key out to anyone - its just for the authentic updater to sign against when requesting an update +[00:00] <jrand0m> what you're describing sounds more like symmetric crypto - just using a passphrase, eseentially +[00:00] <thecrypto> cvs is screwing with me! +[00:00] <jrand0m> (where the certificate is the shared secret between CAs and the authentic owner of the nym) +[00:00] *** mrsc (~efgsdf@anon.iip) has joined channel #iip-dev +[00:01] <jrand0m> whats up thecrypto? +[00:01] <thecrypto> i added the user anonymous with blank password added them to readers and into the cvsgroup and i get cvs login: authorization failed: server localhost rejected access to /home/cvsgroup/cvsroot for user anonymous +[00:01] <co> jrand0m: Good point. Let's say that this part of the specification is not finalized, and I will think about it some more. +[00:01] <jrand0m> coo' +[00:01] *** LeerokLacerta (~leerok@anon.iip) has joined channel #iip-dev +[00:02] <LeerokLacerta> Konnichiwa. +[00:02] <jrand0m> hmm thecrypto, I don't think you want an anonymous OS user +[00:02] <jrand0m> heya LeerokLacerta +[00:02] <LeerokLacerta> Hello, jrand0m. +[00:02] <thecrypto> well i stuck on a password and it works now +[00:03] <co> jrand0m: And if you have any more suggestions after reading the spec, send them to me. +[00:03] <jrand0m> shall do co +[00:03] <jrand0m> cool thecrypto.. is /bin/false their shell? +[00:03] <thecrypto> now i just have to find that section in the cvs manual about how to make a user +-> *thecrypto* whats the pw? +[00:04] <thecrypto> now it is +[00:05] <jrand0m> ok, we can work through this after the meeting. +[00:05] <jrand0m> ok, last point on the agenda: 5b) ? +[00:05] <jrand0m> any questions / thoughts / concerns? +[00:05] <thecrypto> just check out the IM app +[00:06] <thecrypto> right now all it does is make a tree but it shows you what it's starting to look like +[00:06] <LeerokLacerta> No SOCKS? +[00:06] <thecrypto> ohh yeah that's what i forgot +[00:06] <jrand0m> ah cool thecrypto +[00:06] <jrand0m> SOCKS? as in, the proxy protocol? +[00:06] <thecrypto> anyone here good at making icons? +[00:06] <LeerokLacerta> Yup. +[00:06] <LeerokLacerta> The answer for all the times I've asked as been "No". +[00:07] <jrand0m> ah. yes, we're definitely going to want a socks proxy, but no one is working on it atm. +[00:07] <LeerokLacerta> Hmm. +[00:07] <jrand0m> thats going to be one of the apps we'll want by 1.0 public, so that people can browse i2p based sites, as well as so that people can browse the normal web anonymously +[00:07] <mihi> there are enough socks proxies available for free, i'd say ;) +[00:08] <jrand0m> exactly, we just need to integrate 'em +[00:08] <mihi> but i don't know any in java. +[00:08] <jrand0m> the JAP client app might work well, I don't know if its GPL though +[00:08] <mihi> the jap client does not contain a proxy. +[00:08] <thecrypto> well I need some icons for the I2PIM project +[00:09] <thecrypto> Something to represent online offline and a group of people +[00:09] <mihi> the only proxy is a http/ftp proxy and that is in the last mix. +[00:10] <mihi> like with iip - isproxy does not know any IRC protocol. +[00:10] <jrand0m> well, thats the outbounds side - for i2p based web sites, we'll need something to accept proxy requests from local browsers, do the lookup of the dest, and send the messages to the appropriate dest +[00:10] <thecrypto> anyone interested? +[00:11] <co> thecrypto: Could you take the icons from the GPL'd gaim project? +[00:11] * jrand0m makes horrificly boring graphics in ms paint +[00:11] <co> Since it's under GPL, and so is this, unless I am mistaken. +[00:11] <thecrypto> yeah, i could +[00:11] <jrand0m> if I2PIM uses the sdk's client libs, I2PIM is definitely GPL :) +[00:12] <thecrypto> ahh the wonderful GPL +[00:12] <jrand0m> LeerokLacerta> any particular reason you ask, or just wanting to prod us to do it? ;) +[00:13] <thecrypto> the problem with the gaim ones is they are from the IM apps they are using +[00:14] <thecrypto> so if someone could make the I2PIM icon that would just be great +[00:15] * jrand0m thinks we'll have lots of scribbled paint-based images for the time being... +[00:16] <jrand0m> ok, anyone have any other thoughts / questions / commnets? +[00:16] <nop> I have commnets +[00:16] <jrand0m> (other than "wtf is a commnet") +[00:16] <jrand0m> is that contagious? +[00:16] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev +[00:16] <mrflibble> lol +[00:17] <jrand0m> 'k, well, if not, that about wraps up the meetin', no more agenda items left +[00:17] <nixonite> did i miss the meeting? +[00:17] <jrand0m> yup, 9p GMT +[00:17] <jrand0m> well, technically you made it for the end :) +[00:17] <nixonite> oh +[00:18] <co> nop: Let's hear them. +[00:18] <thecrypto> so what are the comments +[00:18] * jrand0m thought nop was just making fun of my typo, but if he has comments, let 'er rip bro +[00:20] <thecrypto> anon cvs is still not liking me, more work tommorow +[00:20] <jrand0m> gimmie root and I'll get 'er up +[00:21] <thecrypto> talk to nop about that one +[00:21] <jrand0m> heh 'k +[00:22] <jrand0m> ok, as nop seems to have been dragged back into work... +[00:22] <jrand0m> nop, and anyone else, really> if you have any comments /questions / concerns, either let us know or post on the mailing list (or even into the wiki) +[00:23] * jrand0m loads up and *baf*s the meeting to an end. diff --git a/i2p2www/meetings/logs/58.rst b/i2p2www/meetings/logs/58.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/58.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/59.log b/i2p2www/meetings/logs/59.log new file mode 100644 index 00000000..d6acbf3f --- /dev/null +++ b/i2p2www/meetings/logs/59.log @@ -0,0 +1,730 @@ +[22:56] <jrand0m> ok ok +[22:56] <jrand0m> agenda +[22:56] <jrand0m> 0.0) welcome +[22:56] <jrand0m> 1.0) dev status +[22:56] <jrand0m> 1.1) router +[22:56] *** Myself248 (~ident@anon.iip) has joined channel #iip-dev +[22:56] <jrand0m> 1.2) DH precalc +[22:56] <jrand0m> 2.0) microroadmap +[22:56] <jrand0m> 3.0) apps / usage +[22:56] <jrand0m> 4.0) ns +[22:56] <jrand0m> 5.0) IM +[22:56] <jrand0m> 6.0) administravia (cvs, bugzilla, cvs list, cvs web) +[22:56] <jrand0m> 7.0) questions +[22:57] <jrand0m> (yes, 7 points today. w00t) +[22:57] <jrand0m> 0.0) welcome +[22:57] <jrand0m> hi. +[22:57] <dm> hey +[22:57] <jrand0m> 17 users today. neat +[22:57] *** Ryan_Singer (chatzilla@anon.iip) has joined channel #iip-dev +[22:57] <jrand0m> and counting +[22:57] <jrand0m> ok +[22:57] <thecrypto> 1~hi +[22:57] <jrand0m> 1.1) dev status for router +[22:58] <jrand0m> the java reference impl router is doing very well +[22:58] *** ChZEROHag (hag@anon.iip) has joined channel #iip-dev +[22:58] <jrand0m> we can now run applications on different routers and send messages ot each other +[22:59] <ChZEROHag> Sorry to interrupt, but hopefully it'll just be once +[22:59] <jrand0m> taking an iterative and incremental approach, the current state is secure, not anonymous, not scalable, and harvestable +[22:59] <ChZEROHag> Is anyone else working on a C api? +[22:59] <jrand0m> 'lo ChZEROHag, whats shakin? +[22:59] <ChZEROHag> Because I am, but very slowly +[22:59] *** dcat (dirtycat@anon.iip) has joined channel #iip-dev +[22:59] <jrand0m> oh cool +[22:59] <jrand0m> shardy will be working on one after toorcon is finished +[22:59] <jrand0m> perhaps you two could work together on that? +[23:00] <co> jrand0m: Can you input a destination to send messages to by hand? +[23:00] <co> Better said, is there an ASCII representation of a destination? +[23:00] <jrand0m> yes co, to both +[23:00] <co> Excellent. +[23:00] <jrand0m> destinations, and all I2P structures, are loadable and serializable in (an alternate alphabet) base 64 +[23:01] <thecrypto> so it won't be easy to remember, but it will be ascii? +[23:01] <jrand0m> (e.g. in the netDb for one of my routers, I have leaseSet-enD4jtE-orMwFD0QGog9GAyC5MvLvnPzhVD8cDYvSI8.dat which contains the lease set for destination enD4jtE-orMwFD0QGog9GAyC5MvLvnPzhVD8cDYvSI8) +[23:02] <jrand0m> [though that is H(destination).toBase64() +[23:03] <jrand0m> ChZEROHag> if there's anything we can do to help you with that, just say the word +[23:03] <jrand0m> ok thats 1.1. 1.2) DH precalc +[23:03] <ChZEROHag> You could do it for me? :-) +[23:04] <jrand0m> last night I wrote up a precalc optimization for DH exchanges to save ~1s off 1.5s session negotiations. I'd love if someone who knows crypto could make sure I'm not nuts ;) +[23:04] <jrand0m> lol ChZEROHag +[23:04] <ChZEROHag> aah I know what I needed +[23:04] <ChZEROHag> A netdb implementation +[23:04] <thecrypto> is it in cvs? +[23:04] <thecrypto> the dh +[23:04] <jrand0m> yes thecrypto +[23:05] <jrand0m> C:\dev\i2p\code\core\java\src\net\invisiblenet\i2p\crypto\DHSessionKeyBuilder.java +[23:05] <ChZEROHag> Well I'm going to be up for a good 3/4 hours yet, maybe it'll give me something to do +[23:05] <jrand0m> er, s/C:\\dev/g; s/\\/\//g +[23:05] *** wax_off (~nomail@anon.iip) has joined channel #iip-dev +[23:06] <jrand0m> word. what do you need a netdb impl for? +[23:06] <ChZEROHag> I don't remember +[23:06] <jrand0m> we currently have a non-scalable netdb in cvs +[23:06] <jrand0m> heh +[23:06] <ChZEROHag> Haven't touched it in at least a week +[23:06] <jrand0m> you're working on a C I2CP api, right? not I2NP? +[23:07] <ChZEROHag> I was just going to do everything +[23:07] *** wax_off has left #iip-dev +[23:07] <jrand0m> I2NP is really, really, really significantly more work than I2CP +[23:07] <ChZEROHag> Once I actually get properly started, it'll just roll out +[23:07] <jrand0m> but if you impl an I2NP in C that'd rule +[23:07] <dm> is there a I2NP in anything right now? +[23:07] <jrand0m> (I2CP:I2NP::FCP:FNP) +[23:07] <jrand0m> yes dm +[23:08] * ChZEROHag deminimizes emacs +[23:08] <jrand0m> the java impl i'm working on has I2NP functioning +[23:08] <dm> alrighty... +[23:08] <ChZEROHag> jrand0m: url? I could do with a reference, even if it's in a horrible language. +[23:08] <jrand0m> heh +[23:08] <jrand0m> erm, actually thats 6.0 administravia: aka where the fuck is our anon cvs access ;) +[23:09] <thecrypto> i'm getting the DH stuff +[23:09] <jrand0m> coo' +[23:09] <ChZEROHag> Oh right +[23:09] <Ryan_Singer> jrand0m, back to schedule, the microroadmap? +[23:09] * thecrypto hides his face +[23:09] <ChZEROHag> well I'll wait :) +[23:09] <jrand0m> heh 'k +[23:09] <jrand0m> microroadmap +[23:09] <jrand0m> I have 0.1 through 0.5 mapped out +[23:09] <dm> followed freenet's roadmap then? +[23:10] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev +[23:10] <jrand0m> 0.1) functional, secure, not anonymous, not scalable, harvestable +[23:10] <dm> development slows down and freezes during 0.5... +[23:10] <jrand0m> we are now at 0.1. +[23:10] <jrand0m> heh I noticed that dm, flinks hosed off at 0.5.2 as well ;) +[23:10] <co> What are you calling the whole package? +[23:10] <jrand0m> (strange coincidence) +[23:10] <co> i.e. version 0.1 of? +[23:10] <jrand0m> the whole package? i2p router reference implementation +[23:10] <ChZEROHag> co: Wonga +[23:10] * beefbroth joins the meeting +[23:11] <jrand0m> buenos noches beefbroth +[23:11] <co> All right. That explains it. +[23:11] <ChZEROHag> Actually maybe I will call it that. Certainly sounds more interesting than 'i2pd' +[23:11] <jrand0m> 0.1 has bugs. thats a given. and it has no optimizations of note (though the DH precalc helps). +[23:11] <jrand0m> heh +[23:11] <Ryan_Singer> jrand0m, what's 0.2) then? +[23:11] <jrand0m> invisible internet police department +[23:11] <jrand0m> ok, 0.2 +[23:12] <jrand0m> 0.2 is functional, secure, anonymous, not scalable, harvestable +[23:12] <jrand0m> 0.2 adds support for non-zero-length tunnels +[23:12] <jrand0m> I actually implemented most of that last night, but not thoroughly tested +[23:12] <jrand0m> I think 0.2 will be ready by end of week +[23:12] <Ryan_Singer> how far away are we from that from a dev perspective? +[23:13] <Ryan_Singer> great +[23:13] <jrand0m> 0.3) is functional, secure, anonymous, scalable, harvestable +[23:13] * thecrypto gets bochs so he can simulate a network to help with this +[23:13] <jrand0m> 0.3 adds a kademliaDatabaseManager +[23:13] <jrand0m> right now we use a BroadcastDatabaseManager +[23:13] <jrand0m> (aka gnunet ;) +[23:14] <jrand0m> trivial to implement and functional for small networks, but we need the kademlia to scale +[23:14] <jrand0m> 0.4) is functional, secure, anonymous, scalable, non-harvestable +[23:14] <jrand0m> that adds trusted links +[23:14] <Ryan_Singer> jrand0m, and how much of a dev challenge is it to implement kademlia? +[23:14] <jrand0m> I have two ideas for trusted links.. one is more easily implementable and usable +[23:15] <jrand0m> kademlia will probably take a full week +[23:15] <jrand0m> (to get right) +[23:15] <jrand0m> note that all of this has lots of room for refactoring and tuning. I'm aiming functional first, then we tune. +[23:16] <co> Are you certain you will be able to develop and test that quickly? +[23:16] <jrand0m> I am certain of nothing +[23:16] <jrand0m> thats just my estimate +[23:16] <Ryan_Singer> co, hegets functional, we test +[23:16] <ChZEROHag> Are you sure? +[23:16] <ChZEROHag> (sorry) +[23:16] <co> Ryan_Singer: I see. +[23:17] * jrand0m <3 people who test :) +[23:17] <Myself248> When you say "we" test. Is there any place for non-coders to help with the testing? +[23:17] <jrand0m> Myself248> probably not until 0.4 +[23:17] <dm> lets just hope it never gets to the point where it's functional, but nobody knows what the fuck is going on inside the network to make it work well (i.e. freenet) +[23:18] <jrand0m> once 0.4 is ready, thats pre-alpha. once its 0.4 I'll tune and refactor and fill in the blanks to get ready for 0.5 (alpha) +[23:18] <Myself248> Document, document, document. +[23:18] <dm> is there any though being put into active monitoring of network internals, or is it straightforward? +[23:18] <jrand0m> yes dm, absolutely +[23:18] <jrand0m> one of the key pieces of i2np is the inclusion of stats in the routerInfo strutures published +[23:18] <mihi> jrand0m: do a s/0./0.0./ ;) +[23:18] <jrand0m> the initial revs will publish real stats so we can tune +[23:19] <jrand0m> later revs will either not publish any stats or publish fake ones +[23:19] * jrand0m does not do 0.0 +[23:19] <shardy> ok, I'm here +[23:19] <jrand0m> wb shardy +[23:19] <shardy> sorry for being late, forgot about this window being open, heh +[23:19] <dm> cool. +[23:19] <Ryan_Singer> is there a higher level document describing the archetecture for the network under .4? +[23:19] <jrand0m> off with your head +[23:20] <jrand0m> Ryan_Singer> hmm, I had some overview docs a few months back that mids and nop mirrored, and there's the i2p overview doc +[23:20] <jrand0m> 0.4 is full i2np as described in the spec, just not optimally implemented +[23:20] <shardy> oh and jrand0m, I'll check out the DH optimization for you +[23:20] <jrand0m> word, gracias +[23:20] <Ryan_Singer> can I get those docs? +[23:21] <jrand0m> the overview is at (Link: http://www.invisiblenet.net/i2p/i2p_philosophy.pdf)http://www.invisiblenet.net/i2p/i2p_philosophy.pdf +[23:21] <beefbroth> they're on the wiki I think? +[23:21] <jrand0m> hte old overview docs... hmm +[23:21] <jrand0m> (i2p specs are at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs) +[23:21] <co> They are on (Link: www.invisiblenet.net/i2p/.)www.invisiblenet.net/i2p/. +[23:21] <jrand0m> right beefbroth +[23:22] <jrand0m> though there are old docs in html format w/ ugly ms paint pictures from before showing how tunnels work... +[23:22] <beefbroth> I should know, I've read them enough +[23:22] <jrand0m> hehe +[23:22] <co> Unless those are older versions or mirrors. +[23:22] <jrand0m> those files on the wiki are 0.9 (0.9.1 is out for I2NP and datastructures, but they only include minor changes) +[23:23] <thecrypto> jrand0m: the precalc looks good +[23:23] <jrand0m> cool +[23:24] *** pitu (~pitu@anon.iip) has joined channel #iip-dev +[23:24] * jrand0m runs the router w/ java -Dcrypto.dh.precalc.min=3 -Dcrypto.dh.precalc.max=10 -Dcrypto.dh.precalc.delay=5000 -jar C:\dev\i2p\code\router\java\src\router.jar +[23:25] <jrand0m> ok, thats the microroadmap +[23:25] <jrand0m> as you can see, I'm accepting that alpha won't be ready for end of month. 0.4 will probably be first week of october +[23:26] <dm> that's okay, even that would be the fastest ever implementation of a network of this type ;) +[23:26] <Ryan_Singer> lol +[23:26] <beefbroth> when reading jrand0m's time estimates here, please remember that he has been drinking whiskey for the last 4 hours :-P +[23:26] <jrand0m> heh +[23:26] <Ryan_Singer> ok...apps/usage? +[23:26] <jrand0m> good whiskey at that ;) +[23:26] <jrand0m> ok, apps/usage +[23:27] <dm> 0.7 in 4 seconds....3...2...1..!! +[23:27] <jrand0m> I'm aiming for low hanging fruit here - these are things that we can do with 0 or minimal new code. +[23:27] <ChZEROHag> How are you supposed to code properly if you're stone sober? +[23:27] <jrand0m> all of these make significant use of mihi's kickass i2ptunnel +[23:27] <co> ChZEROHag: Easily. +[23:27] *** mihi has changed the topic on channel #iip-dev to <dm> 0.7 in 4 seconds....3...2...1..!! +[23:28] <jrand0m> using the i2ptunnel, we can do the following without writing any new code: +[23:28] <jrand0m> public ww proxy (using i2ptunnel + squid) +[23:28] * dm tips his hat to mihi. +[23:28] <jrand0m> JAP (using i2ptunnel + JAP) +[23:28] <mihi> you cannot kick asses though i2p (not through a tunnel either...) +[23:28] <jrand0m> browse www anon (i2ptunnel + web browser) +[23:28] <jrand0m> run an i2p web server (i2ptunnel + httpd) +[23:29] <co> Very nice. Bravo, mihi. +[23:29] <jrand0m> cvs outproxy (i2ptunnel) [e.g. cvs outproxy to sourceforge for anon freenet dev] +[23:29] <jrand0m> cvs client, cvs server +[23:29] <jrand0m> IM app, pop3 server, imap server, opennap +[23:29] <jrand0m> those are all really low hanging fruit +[23:29] <dm> okay, now all we need is i2p :) +[23:30] <jrand0m> right ;) +[23:30] <Myself248> wouldn't i2p webserver kinda supplant freenet? :) +[23:30] * jrand0m thinks that qualifies as a faq I should answer +[23:30] <Ryan_Singer> jrand0m, but they are also very valuable +[23:30] <ChZEROHag> From that list, I'd consider cvs more important/useful +[23:30] <ChZEROHag> Partly because I wish to remain anonymous, but also because if anonymous www is provided you'll get lusers +[23:30] <jrand0m> i2p + web doesn't supplant freenet - freenet adds significant value on top of an anon comm framework - content distribution +[23:31] <ChZEROHag> And at the moment the idea of anonymous email is scary :) +[23:31] * dm writes down: "no lusers" +[23:31] <jrand0m> cvs definitely is in the top 3 +[23:31] <beefbroth> i think if i2p webserving works well, you have to consider merging the DHT/storage parts of freenet on top of i2p and then you have the best of both worlds. +[23:31] <Ryan_Singer> ChZEROHag, if it's scalable thats a goodthing +[23:31] <ChZEROHag> dm: lusers are only a problem during the early stages, but they tend not to use cvs +[23:31] <Myself248> okay, add lots of hashcash to any anon email thing. +[23:31] <ChZEROHag> Or, for that matter, even know what (or that) it is +[23:31] <co> I think one of the tests that needs to be done is a test attack on the network. +[23:31] <jrand0m> yes beefbroth, once i2p does what we aim at, freenet will most likely adjust to make use of it +[23:32] <co> Sorry if that is offtopic. +[23:32] <mihi> Myself248: just add a redirector to an anon remailer. +[23:32] <jrand0m> no, thats definitely on topic co - attacking this network is key +[23:32] <ChZEROHag> Myself248: hashcash is primarily to stop flooding while we're forced to use the ancient protocol that is 'irc' +[23:32] <ChZEROHag> Not to stop what could be termed 'abuse' +[23:32] <jrand0m> right mihi. though perhaps mixminion run over i2p would be useful +[23:33] <jrand0m> right, hashcash is even built into i2p itself to keep messages from being delivered a single hop unless they "pay up" +[23:33] <Ryan_Singer> jrand0m, we could run imap over this easily? +[23:33] <jrand0m> absolutely +[23:33] <Ryan_Singer> impressive +[23:33] <jrand0m> imapd with an i2ptunnel pointing at it, with i2ptunnel on the client pointing at that tunnel's destination +[23:34] <Myself248> and freenet search engines :) +[23:34] <mihi> ftp or several non-jabber instant messengers will make problems... +[23:34] <jrand0m> right, things that require two connections are more complex +[23:34] <ChZEROHag> jrand0m: hashcash in i2p? +[23:34] <ChZEROHag> I shall bug you about that when this is over. +[23:34] <shardy> hashcash in i2p? nice. +[23:34] <dm> we're getting ahead of ourselves! oh alright, who cares.. QUAKE + IIP!!!!!! +[23:34] <dm> sorry, I2p :) +[23:34] <jrand0m> lol dm +[23:35] <Myself248> Those of us with little CPUs get nervous when someone says hashcash, but as an anti-spamming measure I understand it. +[23:35] <co> dm: That is *reallY* getting ahead of ourselves. +[23:35] * mihi is jabber:schierlm@a-message.de ;) +[23:35] <jrand0m> yes ChZEROHag - Destination == public signing key (DSA) + public encryption key (ElGamal) + certificate (either null or hashcash(keys)) +[23:35] <beefbroth> is the i2p tunnel static or dynamic on the client end? +[23:35] <mihi> beefbroth: atm it is all static. but you could use a socks proxy as dest. ;) +[23:35] <jrand0m> Myself248> I'm getting a bitching sun ultra1 in the mail in a few weeks. if a 160Mhz box can do it, everyone can +[23:35] <shardy> well. hashcash shouldn't be something that is terrible even to small cpus. only if you want to do something eleventy billion times, should you notice it. +[23:36] <co> beefbroth: It can be dynamic. +[23:36] <Ryan_Singer> the potential applications of the "low-hanging fruit" here are very impressive +[23:36] <jrand0m> right mihi +[23:36] <jrand0m> "eleventy". heh +[23:36] <ChZEROHag> the low hanging fruit is essentially 'normal' internet apps, but anonymously +[23:36] <ChZEROHag> right? +[23:36] <jrand0m> right +[23:36] <Ryan_Singer> yes +[23:36] <dm> (quake) +[23:37] <jrand0m> 0.1 runs them securely, 0.2 runs them anonymously, 0.3 runs them scalably, 0.4 runs them non-harvestably +[23:37] <jrand0m> (we're @ 0.1 now) +[23:37] <shardy> what do you mean by non-harvestably? +[23:37] <co> Sorry, what is harvestable again? +[23:37] <ChZEROHag> dm: Unfortunately we've ben held back enough that realtime is after more than 30 years still not 'normal' +[23:37] <Myself248> Phew. I was hoping someone would ask that. ;) +[23:37] <Ryan_Singer> loggable +[23:37] <jrand0m> harvesting means an active attacker can run a router, find out about lots of other routers ("harvest" them), and send the goons to kick in their doors +[23:38] <Myself248> oh, like you can do with gnutella. :) +[23:38] <Ryan_Singer> secret-servicy like goons +[23:38] <jrand0m> right +[23:39] <shardy> ah, gotcha. +[23:39] <jrand0m> ok, but yeah, thats the microroadmap. +[23:40] <jrand0m> now, am I being stupid calling these 0.x instead of 0.0.x? should 1.0 be "perfect" or should 1.0 be functional and safe? +[23:40] <Ryan_Singer> jrand0m, and we will see .4 when? +[23:40] <jrand0m> 0.4 is probably 2 weeks out +[23:40] * jrand0m is taking a week off (ish) in mid october as I have people coming to visit +[23:40] *** Signoff: dm (EOF From client) +[23:40] <mihi> 1.0 should be stable. +[23:40] <co> Let 1.0 be functional and safe. +[23:40] <thecrypto> dittos co +[23:41] <Ryan_Singer> 1.0 should be functional, stable and safe +[23:41] <ChZEROHag> jrand0m: My philosophy, regarding version numbers, is if in doubt, copy Linux +[23:41] <Myself248> 5.0 can be "perfect". Free software people are overly afraid of version number bloat. +[23:41] <jrand0m> word +[23:41] <mrflibble> jrand0m, v1 of things are never perfect :) +[23:41] *** dm (~gj@anon.iip) has joined channel #iip-dev +[23:41] <mrflibble> people dont expect them to be perfect either +[23:41] <dm> did I miss 1.0? +[23:41] <ChZEROHag> mrflibble: People don't expect any software to be perfect. People use windows. +[23:41] <Ryan_Singer> this software will beGPL orLGPL? +[23:41] <jrand0m> cool, I've already gotten flack for 1.0 being not-perfect yet +[23:41] <ChZEROHag> That doesn't mean it shouldn't be. +[23:41] <mrflibble> good point ChZEROHag +[23:42] <dm> ah shit, I did didn't i.. +[23:42] <mihi> dm: stop kidding +[23:42] <mrflibble> yup, u did +[23:42] <jrand0m> the router is GPL. the java client library is currently GPL, but I'm open. thecrypto and I are full owners of all but one section (the Cryptix AES impl, which is MIT) +[23:42] <dm> alright alright I'm sorry :( +[23:42] <jrand0m> actually, I take that back +[23:42] <jrand0m> I used the Base64.java from freenet too +[23:43] <beefbroth> are we still on agenda item 0.3 Apps ? +[23:43] <jrand0m> so base64 is GPL :) +[23:43] <thecrypto> and the IM client will be GPL +[23:43] <jrand0m> oh yeah, we're on 0.3 aren't we +[23:43] <thecrypto> as soon as i get around to putting comments in the code +[23:43] *** UserX_ (~User@anon.iip) has joined channel #iip-dev +[23:43] <jrand0m> heh thecrypto +[23:43] <ChZEROHag> GPL sounds good to me +[23:43] <jrand0m> w0ah, 23 users +[23:43] <Myself248> we're on agenda item 6.02E23, random crap. :) +[23:43] <Ryan_Singer> jrand0m, if you get time, I want to talk to you about liscencing and potential consulting gigs +[23:43] <jrand0m> cool Ryan_Singer +[23:43] <ChZEROHag> Though as someone (Fillament?) pointed out - if someone breaks the license how is an anonymous person going to do anything about it? +[23:43] <mihi> jrand0m: 22 ;) +[23:43] <jrand0m> ChZEROHag> read my license on flinks ;) +[23:43] <Myself248> we need an anonymous court system. +[23:44] * mihi is here twice +[23:44] <jrand0m> Myself248> its called yodel ;) +[23:44] <Myself248> "The court now hears docket number 34534, J. Doe v. J. Doe" +[23:44] <Ryan_Singer> ChZEROHag, the reason I ask is for corporations to make use of this software for security against industrialespionage +[23:44] <co> Naming server will be licensed under GPL as well. +[23:44] <CCD> lol +[23:44] <Myself248> "Baliff, aren't those the same parties as the last 34533 cases we've heard?" +[23:44] <shardy> well +[23:45] <shardy> there's always the idea that if you want people to *really* use your protocol, and you're not worried about money, just make it completely open. not even restricted by gpl. +[23:45] <co> shardy: You mean public domain? +[23:45] <beefbroth> i think that was co's lead in to 0.4 agenda item :-P +[23:45] <jrand0m> shardy> the specs are public and open. I have not asserted copyright on the specs. +[23:45] <Ryan_Singer> shardy, no, we would like work on the protocol to stay available +[23:45] <shardy> public domain, bsd license, "do whatever you want just give us credit please" license, etc +[23:45] <jrand0m> the code is GPL for the router. one client api implementation in java is GPL +[23:46] <Ryan_Singer> check out the liberty protocol.... (Link: http://projectliberty.org)http://projectliberty.org +[23:46] <shardy> jrand0m: ok cool. gotcha. +[23:46] * jrand0m has thought about "no government use" licenses ;) +[23:46] <jrand0m> ok, the reason I tossed 3.0) apps into the list of issues is this +[23:46] <jrand0m> we need help. +[23:46] <Ryan_Singer> help with what? +[23:46] <jrand0m> i2ptunnel is good code. i2p's router will be good code. +[23:47] <jrand0m> what we need is for people to start figuring out the nuts and bolts of release engineering +[23:47] <dm> why do you need apps if you can just use i2ptunner? +[23:47] <ChZEROHag> jrand0m: come again? +[23:47] <jrand0m> aka, how to actually package something up that joe sixpack can download and browse the web +[23:47] <ChZEROHag> dm: Why do you need apps if you can just use telnet? +[23:47] <dm> what? +[23:47] * dm scratches his head. +[23:47] <CCD> err, there is something besides telnet? +[23:48] * jrand0m thinks thats ChZEROHag's point dm ;) +[23:48] *** Myself248 is now known as myself248 +[23:48] *** Signoff: thecrypto (Ping timeout) +[23:48] <ChZEROHag> dm: To use i2ptunnel would be like having a working car and then dragging it around on a handcart +[23:48] <jrand0m> ok, thats just that. I just wanted to mention in case people had spare time :) +[23:48] <jrand0m> ok, 4.0) +[23:48] <jrand0m> naming service +[23:48] <dm> I can see he's trying to make a point. +[23:48] <jrand0m> hi co, hows it going? :) +[23:48] <co> The naming server must be GPL, since at least the Java implementation uses code from the client library to contact routers. +[23:49] <dm> but we just spent 20 minutes going: I2Ptunnel + web server!, I2Ptunnel + quake! ;) +[23:49] <ChZEROHag> Or, in computing terms, like doing all your internet stuff with telnet instead if directly on the ip stack +[23:49] <co> I did not do much last week. I released the client API, which also needs work. +[23:49] <ChZEROHag> i2ptunnel is an interrim solution +[23:49] <co> I will have time this week, though, to begin implementing the naming server. +[23:49] <jrand0m> cool +[23:49] <jrand0m> where is the client api again? +[23:50] <mihi> on the mailing list ;) +[23:50] <co> One of its assumptions is that destinations can be encoded in base64, which is why I asked the question about that earlier. +[23:50] <jrand0m> ChZEROHag> in some ways its interim +[23:50] * jrand0m !thwaps self +[23:50] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev +[23:50] <dm> so is TCP! +[23:50] *** yodel (yodel@anon.iip) has joined channel #iip-dev +[23:50] <jrand0m> 'lo yodel +[23:50] <beefbroth> what are the naming conventions going to look like? is it something that joe average will be able to relate to (i.e. (Link: www.somthing.com)www.somthing.com or (Link: www.something.i2p)www.something.i2p for http/web stuff)? +[23:50] <co> I will put the naming service specification and client API into CVS. +[23:50] <jrand0m> wb thecrypto +[23:50] <ChZEROHag> These have probably been covered before, but how will the ns provide unique names fairly? +[23:50] * mihi wants to have *.mihi.iip ;) +[23:50] <jrand0m> beefbroth> with the naming service or without? +[23:50] <jrand0m> heh mihi +[23:50] <ChZEROHag> avoiding the squatting, etc. that has plagued DNS +[23:50] <thecrypto> can someone send me what happened? +[23:51] <beefbroth> jrand0m: with. i think without would be a long string of numbers. +[23:51] <co> ChZEROHag: You will register with a group of naming servers, then will use the name of that group to identify yourself. +[23:51] <co> As in IM.beefbroth.mygroup if you provide IM service. +[23:51] <mihi> oops, s/iip/i2p +[23:51] *** godmode0_ (~mode@anon.iip) has joined channel #iip-dev +[23:51] *** Signoff: godmode0 (EOF From client) +[23:51] <jrand0m> ChZEROHag> co's naming service has trusted groups, where each group manages a group name (tld). you select chose which groups run each tld +[23:51] <co> Yes, it will be possible for someone to register the username beefbroth with group2. +[23:51] <thecrypto> in the 4 minutes i was gone +[23:52] <ChZEROHag> co: So the only issue is the .mygroup uniqueness? +[23:52] <ChZEROHag> And who gets the group 'com'? :-) +[23:52] <jrand0m> and that is selected by the client +[23:52] <mihi> ChZEROHag: i2p is not COMmerical +[23:52] <jrand0m> (e.g. you tell your ns client lib "group '.com' is group 0123ff33aefcbb34fe +[23:52] <beefbroth> I hate to suggest it, but I almost think the groups should default to 3 letters to preserve the illusion that it is similar to the regular web +[23:52] <co> ChZEROHag: I am not sure who gets the "com" group. +[23:52] <co> Good question. +[23:53] <shardy> beefbroth: except the "regular web" is no longer only 3 letter lds +[23:53] <mihi> beefbroth: or add a .i2p to all addresses. +[23:53] <ChZEROHag> beefbroth: That illusion is only present in america +[23:53] <shardy> tlds. +[23:53] <jrand0m> to start with, we may just want to initially have one group of naming servers, ".i2p" +[23:53] <co> beefbroth: The naming server software permits you to have up to 32 letters. +[23:53] <ChZEROHag> Elsewhere we use the 2-letter country codes given us +[23:53] <shardy> .us is also in use in america. +[23:53] <co> Actually, I wanted the first group to be "test". +[23:53] <shardy> as are things like .info and .name +[23:53] <jrand0m> heh 'k +[23:54] <ChZEROHag> shardy: yeah, by about 5 people. +[23:54] <ChZEROHag> But this is perhaps a rant for another time :) +[23:54] <jrand0m> actually... +[23:54] <shardy> there's even a .museum +[23:54] <Ryan_Singer> jrand0m, using .12p sounds good +[23:54] <jrand0m> I ran into a distributed DNS based of JXTA the other day +[23:54] <co> ChZEROHag: But the point is that if you do not like the people running the "com" group, you can establish the "com2" group and run its servers (and register with it). +[23:55] <ChZEROHag> YEs that bit makes perfect sense +[23:55] <mihi> ChZEROHag: (Link: http://www.nic.us/press/audio/dotus-mayEM.wav)http://www.nic.us/press/audio/dotus-mayEM.wav ;) +[23:55] <jrand0m> co> can't you just say "well, they 'think' they're .com, but I say .com is run by group2"? +[23:55] <ChZEROHag> What I'm getting at, I suppose, is does it rely on first-come-first-served? +[23:55] <co> You may configure your client to do anything. +[23:56] <Ryan_Singer> how does the JXTA name system work? +[23:56] <jrand0m> co> (Link: http://wiki.java.net/bin/view/Jxta/DisDNS)http://wiki.java.net/bin/view/Jxta/DisDNS is a distributed DNS wiki, though its very rough and doesn't address any real hard issues +[23:56] <co> ChZEROHag: In registering your username with a group, yes. +[23:56] <co> jrand0m: I will look at that after the meeting. +[23:56] <jrand0m> jxta runs naming servers off rendevous points +[23:56] <ChZEROHag> mihi: wassat? +[23:56] <beefbroth> so it is possible someone tries to attack the NS system by mimicing the already existing i2p group of naming servers +[23:57] *** Signoff: jeremiah (Ping timeout) +[23:57] <co> beefbroth: I think not. +[23:57] <mihi> ChZEROHag: listen to it. why xxx million americans prefer .us over .com +[23:57] <mihi> 68 million +[23:57] <co> As I envision it, people setting up groups will announce those groups. +[23:57] <jrand0m> mimicing? they can't mimic as the servers in the group are authenticated by public key systems +[23:58] <jrand0m> however, if groups allow non-trusted members to join the group, they can be taken over trivially. +[23:58] <shardy> but how is the key exchange done? +[23:58] <co> The later people will face the problem that the group is already established, and the client software configuration files contain the former group's destinations. +[23:58] <ChZEROHag> mihi: Well I've always said it makes sense to prefer it, patriotism and whatnot, I've just never really seen it. +[23:58] <beefbroth> what happens if two groups of naming servers both claim to resolve the .i2p group? +[23:58] <co> Good question, though, and I will think over it again, carefully. +[23:58] <ChZEROHag> Anyway, I shall have a listen +[23:58] <jrand0m> shardy> no key exchange - key publishing +[23:58] <beefbroth> i see, good point +[23:58] <ChZEROHag> co: Yeah that's another thing I was trying to get at +[23:58] <shardy> but keys can still be intercepted if they're published online +[23:58] <jrand0m> beefbroth> no one claims anything. your client says "i2p == [dest1, dest2, dest]" +[23:59] <shardy> what we need is a trust-based dns system :) +[23:59] <shardy> so you can submit a query for the name and get back a list of responses... and then go with the trusted one +[23:59] <co> Thank you for bringing this up. +[23:59] <jrand0m> shardy> ah, I think I understand the confusion. I think the naming service will want to come with a set of destinations out of band (aka packaged with install) +[23:59] <ChZEROHag> Yeah we have one - everyone trusts IANA (or whatever they call themselves) or else. +[23:59] * shardy ducks +[23:59] <ChZEROHag> :-D +[23:59] <mrflibble> they're trying that with dnssec, but of course that's not anonymous +[00:00] <jrand0m> what this naming service does is get away from root servers +[00:00] <beefbroth> you could always have an i2p homepage that listed active naming groups and authorites? +[00:00] <shardy> jrand0m: ok. just pointing out that it can still be intercepted no matter what you do, unless there's a physically secure channel to initially transmit those keys over... +[00:00] <co> shardy: I think I covered key exchange in the spec. If not, tell me. +[00:00] <shardy> but packaging it oob makes it better +[00:00] <shardy> co: I'll check it out. +[00:00] <jrand0m> shardy> oh, right. yes, people need to be able to trust the code they download +[00:00] <co> beefbroth: Certainly. +[00:01] <ChZEROHag> aah that reminds me +[00:01] <jrand0m> beefbroth> yes, thats most certainly one of the first apps that will be implemented - an i2p webserver w/ bbs & wiki that people can access through i2p +[00:01] <ChZEROHag> I should create a gpg key for my iipmail +[00:01] *** yodel has left #iip-dev +[00:01] * ChZEROHag does so while unexciting stuff happens +[00:01] <jrand0m> heh ok +[00:01] <co> Please understand that the naming server specification is still open to suggestions for improvement. +[00:02] <shardy> I think I'm going to bring all the specs with me on the flight to toorcon... that'll give me a time to read them +[00:02] <co> I do not claim it is perfect or finalized at this time. +[00:02] <jrand0m> heh I hope its a long flight +[00:02] <shardy> and it's more productive than playing fft advance the entire time, heh +[00:02] * jrand0m has found that criticism will more freely come once there is code implementing specs +[00:02] *** godmode0_ is now known as godmode0 +[00:02] <co> And I have to write the code. +[00:02] <co> I think we can move on to the next topic now. +[00:02] <jrand0m> 'k +[00:02] <jrand0m> 5.0) IM +[00:03] <jrand0m> hi thecrypto +[00:03] <mihi> names should not be able to clash with base64 representations. +[00:03] <thecrypto> hi +[00:03] <thecrypto> okay +[00:03] <mihi> and the namin server should transparently return bas64 addressas as is. +[00:03] <co> mihi: Very well, I will try to avoid that problem. +[00:03] <thecrypto> first since my e-mail isn't working again (damn spammers) +[00:03] <jrand0m> (all classes that extend DataStructure have String .toBase64() and .fromBase64(InputStream) ) +[00:03] <thecrypto> i'll answer whit's questions about me system here +[00:04] * jrand0m loads up co's email +[00:04] <mihi> jrandom? why Inputstream and not Reader? +[00:04] <thecrypto> network is the first thing that came to mind, you are making connections over the i2p network, it's very p2p so i called it a networkr +[00:04] <jrand0m> if you want a Reader, just run an InputStreamReader, you brat +[00:04] <mihi> base64 is characters, not bytes in my opinion. +[00:04] <ChZEROHag> jrand0m: IM == Instant Messaging? +[00:04] <jrand0m> yes ChZEROHag +[00:04] <thecrypto> if people have a problem with that, give me a suggestion for what to call it about +[00:05] <ChZEROHag> jabber? +[00:05] <thecrypto> IM == my own distributed IM network +[00:05] <shardy> you should call it "bob" +[00:05] <jrand0m> i2p im is a network in the same way aim is a network, or kazaa is a network, all running over tcp/ip or udp/ip +[00:05] <co> How about IM application? +[00:05] <ChZEROHag> (anonabber) +[00:05] <co> jrand0m: I see. +[00:05] <thecrypto> jabber requires a centerized server +[00:05] <jrand0m> terminology doesn't matter to me. I like shardy's idea +[00:05] <ChZEROHag> thecrypto: Nothing *requires* a centralised server +[00:05] <thecrypto> and i cannot spell today so bear with me +[00:06] <ChZEROHag> That's just the way things are written +[00:06] <jrand0m> (though I prefer Betty) +[00:06] <thecrypto> so you want me to call it I2PIM bob? +[00:06] <thecrypto> :) +[00:06] <jrand0m> how about wilma? +[00:06] <jrand0m> fred is taken thoug +[00:06] <co> How about distributed IM? +[00:06] <jrand0m> DIM, heh +[00:06] <co> But then, distributed IM *application*? +[00:06] <dm> AIM, anonymous Instant messaging! +[00:06] <thecrypto> bad acronym :) +[00:07] <dm> then we can take over AOL. +[00:07] <thecrypto> ohh i can just wait for AOL to get wind of that +[00:07] <ChZEROHag> dm: That would realy piss certain wankers off. I like it. +[00:07] <jrand0m> heh do it +[00:07] <Ryan_Singer> thecrypto, will webe able to implement IM in a decentralised way, or will it have to be centrallized? +[00:07] <co> dm: Good idea. I would back that acronym. +[00:07] <jrand0m> the way I've read thecrypto's docs, the IM is fully decentralized +[00:07] <thecrypto> i am implementing a distributed IM, it's in the CVS +[00:07] <beefbroth> I would vote against anything that is going to confuse people +[00:08] <Ryan_Singer> AOL TimeWarner changed it's name to Time Warner +[00:08] <ChZEROHag> beefbroth: I would too, but the vote to piss AOL off outweighs that. +[00:08] <beefbroth> You want the system to be familiar enough that people won't be afraid to install it, but different enough to differentiate +[00:08] <jrand0m> actually, thats a good point +[00:08] <thecrypto> I2PIM is the name of the application +[00:08] <jrand0m> being transparently anonymous isn't useful if people don't understand what anonymous is. +[00:09] <ChZEROHag> Oh wait, I have something like this down on paper +[00:09] <beefbroth> I like the crypto's idea +[00:09] <thecrypto> what "network" I2PIM runs on is what I'm looking for +[00:09] <jrand0m> teaching people how to protect themselves is a really important thing +[00:09] <thecrypto> i was thinking Presence System? +[00:09] <Ryan_Singer> hypethe security aspect of anon +[00:09] <dm> I2M (instant 2 messaging) +[00:09] <ChZEROHag> Although I only called it XIrc +[00:10] <jrand0m> you're the man thecrypto, whatever works for ya ;) +[00:10] <dm> and in the I2M logo, the 2 will be really small :) +[00:10] <thecrypto> well I2P expands to Invisible ... jrand0m ? +[00:10] <ChZEROHag> The main thing I liked about it was that everyone was called a Borg and they chatted in Collectives +[00:10] <jrand0m> i2p = i^2p (invisible internet project) +[00:10] <co> I thought the P stands for protocol. +[00:10] <jrand0m> that too +[00:10] <jrand0m> well, actually, no +[00:11] <thecrypto> so it's Invisible Internet Project Instant Messaging +[00:11] <jrand0m> i2np is the protocol +[00:11] <jrand0m> i2p is the project +[00:11] <beefbroth> I thought it stood for "poop" +[00:11] <jrand0m> i2cp is the client proto +[00:11] <co> thecrypto: You are right, the name does not matter too much. +[00:11] <dm> i2m = i^2m = instant invisible messaging +[00:11] <thecrypto> so next topic then +[00:11] <Ryan_Singer> ok....so, we're drifting off agenda...are we done with IM? +[00:11] <shardy> if "bob" isn't good enough, we can call it "jimbob" +[00:11] <jrand0m> 0k, 6.0) administravia +[00:11] <thecrypto> no, still more here +[00:12] <thecrypto> sorry +[00:12] <co> It's administrivia. +[00:12] <thecrypto> no it's IM +[00:12] <jrand0m> nop> give me root. I need to get anon cvs, bugzilla, and cvsweb installed. +[00:12] <thecrypto> i wasn't finished +[00:12] <thecrypto> :) +[00:12] <thecrypto> rewind! +[00:12] * jrand0m backs up +[00:12] <jrand0m> 5.1) thecrypto v2 +[00:12] <Ryan_Singer> what else is there in IM, thecrypto? +[00:13] <mihi> thecrypto: just talk on; /me idi it the same way as i missed the naming services +[00:13] <thecrypto> okay, the thing about presences communicating is different +[00:13] <thecrypto> not everyone knows everyone else +[00:13] <thecrypto> there is practically no way to "stalk" someone +[00:13] <thecrypto> you have to ask to be shown +[00:14] <mihi> in anonymous networks, usually no one knows anyone else ;) +[00:14] <jrand0m> (as long as people's Destination is random) +[00:14] *** Signoff: pitu (Lost terminal) +[00:14] <dm> what do you mean? +[00:14] <thecrypto> Alice wants to talk to Bob +[00:14] <jrand0m> mihi> though the naming service allows search by service +[00:14] <jrand0m> (service being IM, www, etc) +[00:14] <thecrypto> Alice finds Bobs IM destination some how, prolly by the naming service +[00:15] <thecrypto> So Alice sends a message to Bobs IM destination +[00:15] <dm> yes? +[00:15] <thecrypto> he gets a little message saying "Alice tried to contact you" if he wants to talk to her, he can, or he can ignore it +[00:16] <thecrypto> but there is no central presence server, Alice can also just see her message disappear and not get a response +[00:16] <dm> ok, like MSN then? +[00:16] <jrand0m> (though Alice can know that Bob ignored her) +[00:16] <thecrypto> and Alice can't just put Bob on her buddy list and wait for him +[00:16] <Ryan_Singer> thecrypto, ok...how is this different then properly configured Y!, MSN or AIM..apart from the nocentral server bit +[00:16] <thecrypto> because Bob has to send a message to Alice to see her sign on +[00:16] <Ryan_Singer> oh +[00:16] <dm> ok, it doesn't change anything as far as the user is concerned, but I see what you mean. +[00:17] <jrand0m> thecrypto> not quite true +[00:17] <Ryan_Singer> got it..no buddylist functionality... +[00:17] <jrand0m> oh, well, hmm, technically... +[00:17] <thecrypto> Ryan_Singer: no there is still a buddy list +[00:17] <dm> how does alice send bob a message if she can't see him? +[00:17] <dm> you just have to try random contacts in case they are there? +[00:17] <jrand0m> bob has to send a message to alice's router, which can happen without alice knowing it +[00:17] <thecrypto> Alice can just randomly try +[00:18] <dm> that's not very convenient? you go online and have to send everyone a message saying (you there?, you there?) +[00:18] <beefbroth> thecrypto: can't a user "notify" all their buddies when they sign on by sending them a message? or is that what you were just saying +[00:18] * co notes that there can be two Bobs registered with two different naming server groups. +[00:18] <thecrypto> beefbroth: that was just want i'm saying +[00:18] <dm> ok, so similar to current scheme but you are invisible by default. +[00:18] <dm> gotcha. +[00:19] <thecrypto> dm: no it's the other way around, when you sign on, you send a message to everyone saying "I'm on, I'm on" if you recieve a message saying "I'm on" you return it +[00:19] <thecrypto> if you want to +[00:19] <co> So the user controls who can see him/her/it. +[00:19] <thecrypto> so Alice can put you on her buddy list and you'll get a message when she signs on saying "Alice has put you on her buddy list, would you like to notify her of your presece" +[00:20] <Ryan_Singer> when you get off do you first send a msg that says "I'm getting off"? +[00:20] <dm> ok, that's just a way to get around having a server, but the question is will the apps be setup by default to send a "I'm on" when someone logs on. +[00:20] <Ryan_Singer> hopefully +[00:20] <jrand0m> Ryan_Singer> or just have a periodic "I'm still on" ping +[00:20] <jrand0m> (and missing ping == off) +[00:21] <Ryan_Singer> keep-alive type deal? +[00:21] <beefbroth> It might need to "ping" the other IM user every so often to make sure there wasn't an unintentional disconnect +[00:21] <thecrypto> if Bob has Alice on his buddy list and Bob recives and Online message from Alice the return message is automatic +[00:21] <beefbroth> heh +[00:21] <thecrypto> If Bob doesn't have Alice on his buddy list and bob recives an online message from alice, the user is propmted +[00:21] <dm> ok, so the IM experience is the same as it is now. Just wanted to confirm that. +[00:22] <thecrypto> just you now have a confirm on buddy adds +[00:22] <thecrypto> which i think only ICQ has +[00:22] <jrand0m> will the IM app be a stand alone or will I be able to use trillian? +[00:22] <dm> yeah, that's how MSN works. +[00:22] <jrand0m> [etc] +[00:22] <ChZEROHag> thecrypto: ICQ only pretends to require confirmation +[00:22] <beefbroth> dm: wrong. you won't have to deal with MSN, Y! and AIM changing their protocols and locking people out every few months :) +[00:23] <thecrypto> jrand0m: i'll make a spec, trillian can either give me a plugin interface or they can write thier own +[00:23] <thecrypto> i will be writing a plugin for gaim at leasty +[00:23] <thecrypto> along with a standalong client +[00:23] <jrand0m> cool +[00:23] <thecrypto> which is built to be used with the network +[00:23] <jrand0m> does gaim support file xfer or will that be the benefit of the i2pim client? +[00:23] <beefbroth> thecrypto: you might want to give a shout to the kopete developers just to let them know +[00:23] * jrand0m shows his cluelessnesss +[00:24] <thecrypto> i'll try to make the gaim plugin work as well as the standalong, but i don't know +[00:24] <co> thecrypto: Let's have the standalone application first. +[00:24] <thecrypto> gaim file transfer i think only works on AIM +[00:24] <thecrypto> so it might take some wrangling to get it into a plugin +[00:24] <Ryan_Singer> ok..I think we all understand this now...any more IM issues? +[00:25] <thecrypto> and co's final thing +[00:25] <beefbroth> gaim suffers problems with it's IM xfers for people using NAT +[00:25] <thecrypto> more than one person can have the same name +[00:25] <thecrypto> they will have unique destinations +[00:25] *** Signoff: mihi (Ping timeout) +[00:25] <co> All right. +[00:25] * mihi_backup is still here... +[00:25] <thecrypto> but someone can't masquerde +[00:26] <jrand0m> heh nice1 mihi_backup +[00:26] <co> If you use the naming server, it will be "Bob from group1" and "Bob from group2". +[00:26] <co> With unique destinations. +[00:26] <jrand0m> right thecrypto. names are arbitrary. kind of like dns ;) +[00:26] *** mihi (~none@anon.iip) has joined channel #iip-dev +[00:26] <thecrypto> also the IM client itself can optionally check "Hey, this IM you got was from someone called Bob, the destination of the Bob in your list is different, accept message?" +[00:27] <dm> mihi: your backup talked while you were gone. +[00:27] <thecrypto> if they person is trying to masquerde Bob, you'll know, otherwise, you can alias them out +[00:27] <mihi> i know... +[00:27] <jrand0m> "someone called bob"? says who? they call themself bob? or some group calls them bob? or you call their dest bob? +[00:27] <thecrypto> there is a feild in the presence called name +[00:27] <thecrypto> i'm looking at that +[00:28] * jrand0m likes the way ICQ works with that problem - everyone is a number and you just alias numbers locally to names +[00:28] <co> As an aside, should I make the NS entity names case insensitive? +[00:28] <jrand0m> probably co +[00:28] <mihi> base64 things must be case sensitive still ;) +[00:28] * jrand0m doesn't want people spoofing Jrand0m +[00:28] <co> mihi: Entity names, not destinations. +[00:28] <jrand0m> right right mihi +[00:29] <jrand0m> (well, people can spoof jrand0m all they want. I just want jrandom back) +[00:29] <co> Go on, thecrypto. +[00:29] *** Signoff: UserX_ (Ping timeout) +[00:29] <thecrypto> that's all i have +[00:29] <thecrypto> finally :) +[00:29] <mihi> co: you should be able to place a destination wherever you can place an entity name. +[00:29] <mihi> like it is with dns names and IPs +[00:29] <co> mihi: Good point. I will add that to the specification. +[00:29] <thecrypto> jrand0m: actully it's kinda like ICQ except you tell people what you'd like your alias to be +[00:30] <thecrypto> which i think they do now +[00:30] <co> The idea, though, is that it will be much shorter to type names than destinations. +[00:30] <jrand0m> mihi> the naming service only turns names to destinations - if you ask the naming service for the destination of a destination, it should return really really quickly +[00:30] <Ryan_Singer> ok guys...I have a meeting... jrand0m, anonymail me +[00:30] <jrand0m> 'k adios +[00:30] <mihi> jrand0m: yes, and it should return that dest itself, and not "not found" +[00:31] <jrand0m> right +[00:31] *** Signoff: Ryan_Singer ((null)) +[00:31] <jrand0m> ok. we're at 7.0) +[00:31] <jrand0m> questions +[00:31] <jrand0m> hi +[00:31] <co> What about 6.0) Administrivia? +[00:32] <co> Or were you done with that? +[00:32] <jrand0m> 6.0 administravia was just me nagging nop to give me root to get y'all: anon cvs access, bugzilla, and a cvsweb interface :) +[00:32] <beefbroth> are there going to be owners to work on packaging the alpha, beta and releases for Win/Mac/SuSE/RehHat/Debian to speed up adoption? +[00:33] <jrand0m> you volunteering? +[00:33] <jrand0m> (aka yeah, that'd be great) +[00:33] <beefbroth> If I learn how to make a package for my distribution :) +[00:33] <jrand0m> what distro do you use? +[00:34] <co> As I recall, the IIP developers wanted to reimplement IIP over I2P. If I2P delivers on its promises of anonymity, will it not be simpler to just have IRC over I2P? +[00:34] <beefbroth> But my point is, alot of people rely on those. It would make it easier for people to adopt. Freenet suffers from a lack of active maintainers. +[00:34] <dm> jr makes for a good manager :) +[00:34] <jrand0m> yes co, simpler, but not as scalable +[00:34] *** UserX_ (~User@anon.iip) has joined channel #iip-dev +[00:34] <thecrypto> yes, but some people don't want IRC +[00:35] <jrand0m> beefbroth> you're absolutely right, there's a lot of work to do, and I need to sleep at least 4 hours a night +[00:35] <co> thecrypto: Good point, though I2P will anonymize people's IP addresses. +[00:35] <beefbroth> jrand0m: i can help package when things are ready. I think that's a great way some non-developers with a bit of technical expertise can contribute. +[00:35] <jrand0m> awesome beefbroth +[00:35] <thecrypto> if we have IM and IRC, more adoption +[00:36] <mihi> co: the problem is that with irc there is something to shut down (servers). +[00:36] *** jeremiah (~jeremiah@anon.iip) has joined channel #iip-dev +[00:36] <jrand0m> thecrypto> instant adoption: opennap +[00:36] <beefbroth> it's easier to learn to make packages than to learn i2p datastructures. it's an easy way for a few people to get involved +[00:36] <dm> IRC is quite tough though isn't it? +[00:36] <dm> distributed IRC that is... +[00:36] <co> mihi: Of course. I forgot that. Thank you for reminding me. Objection withdrawn. +[00:37] <jrand0m> dm> irc can have multiple irc servers (ala efnet, etc) that talk to each other through i2p +[00:37] <shardy> do you mean an "irc lookalike" chat protocol? +[00:37] <shardy> or adapting irc? +[00:37] <jrand0m> with people talking to each other by tunneling to one of the irc servers via i2p +[00:37] <dm> irc with servers behind i2p is fine, I'm saying without servers. Doesn't matter I guess. +[00:38] <jrand0m> dm> right, it can be done much better without servers, and some thought has been put into it, but nothing really solid (to my knowledge) +[00:39] <dm> anyway, it's off-topic. +[00:39] <dm> carry on! +[00:39] <jrand0m> any other questions? +[00:39] <jrand0m> anyone read the specs yet? ;) +[00:39] <jrand0m> (other than beefbroth, who has them memorized) +[00:39] * dm looks at the ceiling. +[00:40] <jrand0m> ok, 100 minute meeting it is then +[00:40] <thecrypto> i'm reading the, when i need something :) +[00:40] <ChZEROHag> specs! +[00:40] <ChZEROHag> That's what I forgot! +[00:40] <jrand0m> heh +[00:41] *** dm has changed the topic on channel #iip-dev to topic1 +[00:41] * jrand0m loads up and... +[00:41] * jrand0m *baf*s the meeting to an end diff --git a/i2p2www/meetings/logs/59.rst b/i2p2www/meetings/logs/59.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/59.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/60.log b/i2p2www/meetings/logs/60.log new file mode 100644 index 00000000..a83edfe4 --- /dev/null +++ b/i2p2www/meetings/logs/60.log @@ -0,0 +1,274 @@ +[22:53] <jrand0m> 0.x) welcome +[22:53] <jrand0m> 1.x) todo before i2p 0.2: +[22:53] <jrand0m> 1.1) bw limiting +[22:54] <jrand0m> 1.2) AES the tcp transport +[22:54] <jrand0m> 1.3) package up [distro, building, seeding, running] +[22:54] <jrand0m> 1.4) ElG session ack discussion +[22:54] * hezekiah is away: Is off eating to keep up is strength for his upcoming tests +[22:54] <jrand0m> 2.x) apps +[22:54] <jrand0m> 2.1) ns +[22:54] <jrand0m> 2.2) i2pim +[22:54] <jrand0m> 2.3) i2ptunnel +[22:54] <jrand0m> 3.x) ??? +[22:54] <jrand0m> 0.x) welcome +[22:54] <jrand0m> welcome to meeting 60 +[22:54] <dm> thanks +[22:55] <mihi> oh. 60. whe have something to celebrate ;) +[22:55] * jrand0m hands out some beers +[22:55] *** wiht (anon@anon.iip) has joined channel #iip-dev +[22:55] * mihi does not like alcohol +[22:55] <thecrypto> hi +[22:55] * jrand0m takes back the german beer +[22:55] <thecrypto> i'm not awake +[22:55] <mihi> but not asleep either ;) +[22:55] <jrand0m> heh interesting +[22:56] <jrand0m> ok, 1.{x,1}) todo before 0.2 +[22:56] <thecrypto> i just remembered the meeting it today +[22:56] <thecrypto> i was just discussing wireless cards +[22:56] <jrand0m> the router is in pretty good shape, and I think 0.2 will be ready for internal dist and testing +[22:57] *** Signoff: mihi (EOF From client) +[22:57] <jrand0m> there are three things that need to get implemented first though. bandwidth limiting, AES on the TCP, and ElG session ack +[22:57] <jrand0m> the bandwidth limiting will be classless for the moment - just one big honking input limit and output limit. +[22:58] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev +[22:58] <jrand0m> the code is committed to tie it in, but the limit is set at infinity atm +[22:58] <jrand0m> for point 1.2, the TCP transport has key exchange and authentication, but needs encryption +[22:59] <jrand0m> nop/semi-awake-thecrypto> thoughts on AES for streaming? +[22:59] <thecrypto> carefully +[22:59] <jrand0m> !thwap +[22:59] <thecrypto> sorry +[23:00] * CounterRev eats popcorn in the grand stands +[23:00] <jrand0m> CBC using first 16 bytes of H(sessionKey) work, or should we do something else? +[23:00] <dm> I can't remember where that originated, exclamation mark before an action. +[23:00] <thecrypto> i realized when the agenda started being pasted today was tuesday +[23:00] <jrand0m> dm> some eggdrops use them as command identifiers +[23:01] <thecrypto> why not use more bits from the DH for that? +[23:01] <jrand0m> hmm? +[23:01] <thecrypto> i don't see any problem for that +[23:01] <thecrypto> for the IV +[23:01] <jrand0m> more bits of what? X, Y, x, y? +[23:02] *** mihi (mihi@anon.iip) has joined channel #iip-dev +[23:02] <thecrypto> K +[23:02] <dm> !thwap thecrypto +[23:02] <thecrypto> what? +[23:02] <dm> he said X,Y,x or y +[23:02] <jrand0m> AES 256 only has a 16 byte K +[23:02] <jrand0m> er, IV +[23:03] <jrand0m> the session key is 32 bytes +[23:03] <thecrypto> but you generate many more +[23:03] <jrand0m> (originally I was stupid and made the IV the first 16 bytes of the key ;) +[23:03] <thecrypto> so use 48 bytes from the DH +[23:04] <dm> we all make mistakes. +[23:04] <jrand0m> hmm ok, pulling more bytes off the modPow will work. cool. but why 48? +[23:04] <jrand0m> (why not just another 16?) +[23:05] <thecrypto> i meant 32+16 +[23:05] <jrand0m> ah 'k +[23:06] <jrand0m> ok cool, CBC with that. if you or nop or someone else has time (userx?), we can get rekeying / rotating keys in there. but for the moment I'll get it CBC'ed w/ that IV +[23:06] <jrand0m> (rekey would be just drop the connection and re-DH) +[23:06] <jrand0m> ok, 1.3) packaging up for 0.2 +[23:07] <jrand0m> that just means a make / ant script, install / build doc, plus a method for distributing seed routerInfo references +[23:07] <jrand0m> (plus, most likely, a set of a few routers for people to connect to) +[23:08] <jrand0m> I hope to have 0.2 out and ready for people to d/l and install by this time next week, if not sooner +[23:09] <jrand0m> the one last point holding up 0.2 is the ElG session ack +[23:09] <dm> can we use 0.2 to talk to each other? +[23:09] <jrand0m> yes dm +[23:09] <dm> ok, that's useful. +[23:10] <mihi> dm: is talking with you really useful? *veg* +[23:10] <dm> (Killer App: Cyber Sex) +[23:10] <jrand0m> 0.2 is definitely not even alpha, so it won't be for the faint of heart +[23:10] <jrand0m> heh +[23:10] <jrand0m> (but we need to get some testing and experience on some platforms and usage patterns other than my xp box here) +[23:11] <dm> I'll take care of the marketing for I2P, I have a knack for it. +[23:11] <jrand0m> lol +[23:11] <dm> 0.2 code name: CyberSex, features, anonymous CyberSex through text. +[23:11] <jrand0m> ok, the ElG session ack stuff. +[23:11] <wiht> I can test on FreeBSD and Gentoo Linux. +[23:11] <jrand0m> awesome wiht! +[23:11] * popopopo can test Debian +[23:11] <jrand0m> nice +[23:12] <thecrypto> i can test on mandrake +[23:12] * dm can test windows XP +[23:12] <jrand0m> damn we're going to have pretty good coverage :) +[23:12] * dm stands out from the crowd. +[23:12] <popopopo> I can test win2k as well I think, although that should be about the same as XP I think +[23:12] <jrand0m> hopefully +[23:12] <dm> stick to unix popopopo +[23:13] * thecrypto plays the trump: I can test win 98 :) +[23:13] <jrand0m> uuuugh +[23:13] * dm welcomes his little brother to the crowd. +[23:13] <popopopo> I have an old DOS disk around here. Will java run on that? :) +[23:13] <wiht> popopopo: Probably not. +[23:13] <jrand0m> actually, probably. +[23:14] <jrand0m> since gcc supports java +[23:14] <jrand0m> and djgpp runs on dos +[23:14] <popopopo> I2P on DOS, now that would be an accomplishment +[23:14] <mihi_backup> popopopo: there is a commercial java version for DOS ;) +[23:14] * jrand0m is currently hacking around with gjc to see if we can compile to native +[23:14] <dm> Getting PPP working on DOS would be accomplishment enough. +[23:14] <mihi> dm: use arachne. +[23:15] <popopopo> gcj +[23:15] <mihi> should work via parallel modem. +[23:15] <nop> oh shit +[23:15] <nop> it's tuesday +[23:15] <nop> haha +[23:15] <jrand0m> ah right popopopo... I always type it wrong +[23:15] <mihi> oops, serial modem ;) +[23:15] <jrand0m> wb nop ;) +[23:15] <thecrypto> nop: you and me both +[23:15] <nop> haha +[23:16] <nop> sorry +[23:16] <nop> my brain is fried this week +[23:16] <nop> re-cooping +[23:16] <nop> from this weekend +[23:16] <thecrypto> nop: you and me both +[23:16] <jrand0m> ok, the ElG ack stuff. +[23:16] <jrand0m> (take 4) +[23:16] * CounterRev could test xp as well "its running.. its running... its stopped" +[23:17] <jrand0m> right now the ElG+AES works by using session tags - 32 byte tags prepended to AES streams to identify what session key to decrypt with +[23:17] <mihi> and "it's bluescreened, it's autorebooting" +[23:17] <jrand0m> (these tags are distributed in the streams, and the session keys are distributed in the ElG) +[23:18] <jrand0m> the problem comes up if we lose the first ElG+AES, we've lost the session key as well as the initial set of session tags +[23:18] <thecrypto> brb, playing magic +[23:18] <jrand0m> so we need to make sure messages use ElG instead of AES with a session tag unless we know for sure the session key has been received +[23:19] <jrand0m> there are lots of optimizations and tradeoffs here - one could always ElG and just forget about acks +[23:19] <jrand0m> (trading cpu for bandwidth) +[23:19] <jrand0m> or one could always require an ack for the first block, and then AES +[23:20] <jrand0m> but that breaks if the recipient crashes and loses the session key +[23:20] * nop is backlogging +[23:20] <jrand0m> there are a few different patterns that can be used to implement these sessions +[23:21] <jrand0m> what I'm probably going to go with is requiring an ack for the ElG message, using AES from then on, but every {$timeperiod, numMessages, bytes} send another ElG +[23:22] <dm> like P frames in MPEG! +[23:22] <jrand0m> 'k, I dont know the MPEG standard really +[23:22] <dm> sorry, I frames. +[23:23] <jrand0m> the thing is, these ElG messages are expensive. ~0.5-1.0 seconds +[23:23] <jrand0m> (cpu time) +[23:23] <jrand0m> though, hmm, we could precalculate them +[23:23] <jrand0m> (if we don't rotate session keys) +[23:23] <mihi> which cpu? ;) +[23:23] <dm> sender or reciever cpu time? +[23:24] <jrand0m> exactly mihi - mine. p4 1.7g. so we need some perf tuning on the algorithm +[23:24] <jrand0m> both dm +[23:24] <jrand0m> (.5 encrypt, .5 decrypt) +[23:24] <jrand0m> (hand wavey approx) +[23:24] * mihi has celeron 700 +[23:24] * dm has PIII 850 +[23:24] <jrand0m> cool. I'm also getting a sun ultra1 (150Mhz) in a few weeks +[23:25] <dm> Why you getting a SUN? +[23:25] <jrand0m> I'm leaving the option open for reevaluating our ElG keysize if we need to +[23:26] <jrand0m> dm> its free (you can buy a u1 for ~50-100 USD). I also have a few sparc for various purposes +[23:26] <dm> sweet. +[23:27] <jrand0m> ok, unless anyone has any comments on the ElG stuff, on to agenda item 2.x... +[23:27] <jrand0m> ok, 2.x) apps +[23:27] <jrand0m> 2.1) ns +[23:27] <jrand0m> wiht, how goes? +[23:28] *** Signoff: mihi_backup (Ping timeout) +[23:30] <wiht> I have not done any coding on the naming server this past week. +[23:30] <wiht> I should say "of" the naming server. +[23:31] <jrand0m> 'k, understandable.. what do you think your schedule looks like for the next few weeks for implementation? no committment or anything, just wondering +[23:31] <wiht> But I will be working on it this week, and should have something more to report during the next meeting. +[23:31] <jrand0m> cool, great +[23:31] <CounterRev> what is i2p like sans ns? +[23:32] <jrand0m> icq, I suppose +[23:32] <wiht> I should be less busy during the next few weeks, and will have time for this. I cannot say when the naming server will be completed at this time. +[23:32] <jrand0m> you need the secret number for contacting someone, but once you have it, you're ok +[23:33] <mihi> CounterRev: lots of very long destination keys... +[23:33] <jrand0m> CounterRev> I suspect someone will install a squid and an i2ptunnel on their router, allowing people to point at the destination and browse the web anonymously +[23:33] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev +[23:33] <jrand0m> ok, 2.2) i2pim... +[23:33] <jrand0m> thecrypto> you still playing magic? +[23:34] <dm> i2pim, is that the name of the IM app? +[23:34] <jrand0m> yup +[23:34] <wiht> dm: Yes. +[23:34] <dm> crap! i2m, Invisible Instant messaging. +[23:34] <dm> i^2m, just like i^2p! +[23:34] <jrand0m> sounds like there's a market +[23:35] <mihi> dm: we had that discussion last meeting... +[23:35] <dm> fine fine... I'll have to live with it. +[23:36] <jrand0m> ok, thecrypto is probably still off. he'll post to the list if there's any news on the i2pim +[23:36] <jrand0m> (i hope) +[23:36] <jrand0m> ok, 2.3) i2ptunnel +[23:36] * jrand0m waves to mihi +[23:37] <wiht> jrand0m: I see that we have three applications being developed at this time. Have others been proposed? +[23:37] <mihi> oops... +[23:37] <mihi> but i have nothing to tell anyway ;) +[23:37] <mihi> i2p is in cvs; look @ it ;) +[23:37] <dm> mihi speaks in code. +[23:38] <jrand0m> heh word. any updates since you added that config> command? +[23:38] <dm> or rather, his code speaks for itself. +[23:38] <mihi> i2ptunnel is in cvs i mean... +[23:38] * nop proposes ex-lax for i2p +[23:38] <mihi> jrand0m: nope. +[23:38] <jrand0m> coo' +[23:38] <jrand0m> would that be like a LaTeX clone nop? +[23:39] <jrand0m> wiht> some various discussions, but those three have been the main ones discussed +[23:39] <jrand0m> (the i2ptunnel enables a shitload of normal apps to operate over it) +[23:40] <dm> has it been tested with anything? +[23:40] <mihi> i2ptunnel has been tested extensively with the local router. +[23:40] <dm> (not locally) +[23:40] <jrand0m> I've done some web browsing with it, as well as ssh +[23:40] <jrand0m> (browsing a single site, that is) +[23:41] * wiht wonders if that website can still track people through cookies. +[23:41] <dm> great. +[23:41] <jrand0m> sure wiht, cookies are still sent +[23:43] <jrand0m> ok, thats it for apps atm, and on to 3.x) ??? +[23:43] <jrand0m> any questions, thoughts, concerns, toenail clippers, hedgehogs? +[23:43] <mihi> a pony? ;) +[23:43] <jrand0m> yeah, I want a pony! +[23:43] * dm raises his glass. +[23:43] <mihi> nop will give you onw... +[23:43] <dm> TO 0.2!!! +[23:44] <jrand0m> oh yeah, mihi pointed out that in 17 minutes we miss the deadline I set in my flog a month ago +[23:44] <jrand0m> to 1.0! +[23:45] <mihi> 7 minutes ;) +[23:45] <dm> so 2 weeks from now, we'll have 20 people on the network who'll be able to send texts to each other? +[23:45] <jrand0m> I said we'd have an alpha out by end of september. well, it looks like we'll be a little late on that, but I think we're still making a good pace +[23:45] <jrand0m> yes dm (and files, etc) +[23:45] <nop> sickening +[23:45] <jrand0m> there will still be room for performance improvements, of course. there hasn't been much tuning at all +[23:45] <nop> sorry, I already spent my budget the next month +[23:45] <dm> Alrighty, well if that happens, I will applaud. +[23:45] <nop> pony has to wait +[23:46] <jrand0m> damnit! +[23:46] <nop> bought a grand piano instead +[23:46] <nop> ;) +[23:46] <jrand0m> heh nice +[23:47] <mihi> jrand0m: here are some virtual ponies for you: (Link: http://tinyurl.com/p8kx)http://tinyurl.com/p8kx +[23:47] <dm> estimated latency? +[23:47] <dm> with network < 30 nodes? +[23:48] <jrand0m> dm> depends on the sender and receiver's tunnel length +[23:48] <dm> order of magnitude. +[23:48] <jrand0m> (e.g. if they have 0 length tunnels, it'll be approx 400ms) +[23:49] <dm> 0 length tunnels, don't know how I2P works, but 0 length doesn't sound good ;) +[23:49] <mihi> or (Link: http://tinyurl.com/p8l7)http://tinyurl.com/p8l7 +[23:49] <jrand0m> if they have 2 hop tunnels, the latency should be ~ 1s +[23:49] <dm> alrighty. +[23:49] <dm> throughput? +[23:50] <dm> harder to estimate? +[23:50] <jrand0m> depends on bandwidth +[23:51] <dm> Say X is the non I2P bandwidth between 2 nodes, through all the hops I2P uses. +[23:51] <dm> what is the equation for Y(X) where Y is the throughput of I2P from one node to the other. +[23:51] <jrand0m> I2P doesn't add a significant overhead to the size of the data +[23:52] <dm> alrighty. +[23:52] <dm> wait and see I guess. +[23:53] <jrand0m> once she's up and running, we'll definitely get some modeling going on +[23:53] <dm> aye.. +[23:54] * dm raises his glass. +[23:54] <dm> To women! +[23:54] <mihi> dm: you forgot to lower it first ;) +[23:55] <dm> You germans... +[23:55] <dm> You wacky germans. +[23:55] <jrand0m> ok, I think thazzabout it +[23:55] <dm> It's no suprise an american is leading us into the 21st century of anonymous networking. +[23:55] * mihi /igs dm +[23:55] <jrand0m> american? +[23:56] <mihi> jrand0m is spanish i guess. +[23:56] <dm> I was referring to you! +[23:56] <mihi> or italian or sth in CET timezone. +[23:56] <dm> jrand0m, the quiet american. +[23:56] <wiht> dm: jrand0m seems to be a European. +[23:56] <dm> !thwap mihi +[23:57] <dm> !thwap wiht +[23:57] <dm> jrand0m: your team members don't know you well. +[23:58] * jrand0m thinks dm has been drinkin a lil too much, but its time for me to do the same. +[23:58] * jrand0m raises the *baf*... +[23:58] <dm> nice try jr! +[23:58] * jrand0m *baf*s the meeting away diff --git a/i2p2www/meetings/logs/60.rst b/i2p2www/meetings/logs/60.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/60.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/61.log b/i2p2www/meetings/logs/61.log new file mode 100644 index 00000000..59ff0e46 --- /dev/null +++ b/i2p2www/meetings/logs/61.log @@ -0,0 +1,77 @@ +[23:04] <jrand0m> 0.0) welcome +[23:04] <jrand0m> 1.0) dev status +[23:04] <jrand0m> 2.0) new server +[23:04] <jrand0m> 3.0) questions? +[23:04] <jrand0m> 0.0) welcome to the 61st iip meeting +[23:04] <jrand0m> hi. +[23:04] <mihi> hi all +[23:04] <dm> hi you two ;) +[23:04] <jrand0m> ok, 1.0) dev status +[23:05] <jrand0m> we're pretty much ready for 0.2 - which is where people would be able to run i2p. +[23:06] <dm> great! +[23:06] <dm> ETA? +[23:06] <jrand0m> it won't scale, and it is currently implemented with the insanely secure style of the ElG+AES (rather than the optimized w/ session tags) +[23:06] <jrand0m> eta: a few days (related point: agenda item 2.0) +[23:07] <jrand0m> but it will be functional. I'm able to send messages of 10 bytes as well as 100K in ~10s +[23:07] <jrand0m> (both on the same CPU, so its cpu contention) +[23:07] <jrand0m> still some tunnel failback I'm working through, then its time to build the ant scripts, etc +[23:07] <jrand0m> actually +[23:08] <jrand0m> a few seconds ago I built everything using Kaffe 1.1.1 on freebsd with not even a warning. +[23:08] * jrand0m <3 not having to make changes to code +[23:08] <mihi> but it wasn't working either, was it? ;) +[23:08] <jrand0m> heh +[23:09] <jrand0m> no, it works +[23:09] <jrand0m> the prob I'm working through is a failover (aka if one is shut down and starts back up, comm recovers cleanly) +[23:10] <mihi> have you tried to send a complete ASCII table (bytes 0x00 to 0xFF)? And does it appear as it should on the other end? +[23:10] <jrand0m> not yet, havent tried i2ptunnel yet either. but shall tonight +[23:10] <mihi> try i2ptunnel with a binary connection (like ssh), no text based one. +[23:11] <jrand0m> 'k +[23:11] <mihi> what if a node shuts down and does not come up again? +[23:11] <jrand0m> then communication with it will fail ;) +[23:12] <jrand0m> (guaranteed delivery now fails correctly and the SDK has been patched to act on that) +[23:13] <jrand0m> ok, thats it for status atm. I've been pulled in other directions for the last two days, but that should be quieting down shortly. +[23:13] <jrand0m> 2.0) new server +[23:13] <jrand0m> we have a new server on a triple homed T3. +[23:14] <jrand0m> its going to host webcvs, a default i2p router, a webserver with seed router references, and a few default services (e.g. an i2p tunnel pointing at a squid instance, an i2ptunnel pointing at cvs, an i2ptunnel pointing at a webserver) +[23:15] *** Signoff: mihi (EOF From client) +[23:15] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev +[23:15] <jrand0m> i'll also be tossing on a public isproxy later +[23:15] <dm> damn, how much is that costing you? +[23:15] <jrand0m> 65/mo +[23:15] <jrand0m> 40Gb transfer, 2Gb data +[23:15] <dm> bandwidth limit? +[23:15] <dm> cool. +[23:16] *** mihi_ is now known as mihi +[23:16] <jrand0m> perhaps that server will become our cvs, but no need to switch right now. +[23:16] <jrand0m> ok, 3.0) questions +[23:17] <jrand0m> [yes, this has been the fastest meeting I've ever seen ;)] +[23:17] <mihi_backup> do you know anything about naming service progress? +[23:17] <jrand0m> I hear wiht has committed a few files, but I haven't checked them out yet +[23:17] <dm> I'd like to offer my (mental) support to all the developers. Stay humble yet determined. +[23:18] <mihi_backup> they are only dummies afaik. +[23:18] <jrand0m> clueless wankers, for sure. +[23:18] <mihi_backup> interfaces to implement against. +[23:18] <dm> dummies? +[23:18] <jrand0m> lol +[23:19] <dm> ah +[23:19] * jrand0m extends MyParents +[23:19] <mihi_backup> java does not allow multiple inheritance ;) +[23:19] <dm> no bastards... +[23:20] * jrand0m implements MyDad, MyMom // just seems wrong +[23:20] <mihi_backup> although you do not extend either your mother nor your father (see the liskov (sp?) substitution principle) +[23:20] * dm implements jrandom'sMom +[23:20] <dm> ;) +[23:20] <jrand0m> oh, good point mihi +[23:20] * dm now implements mihi'smother +[23:20] <jrand0m> heh +[23:21] *** Signoff: mihi (Ping timeout) +[23:21] <mihi_backup> you just need a constructor public Human(Human father, Human mother) throws SameSexException +[23:22] <dm> nice one +[23:22] <jrand0m> I think modern science requires a few more constructors +[23:22] <dm> although it's not public +[23:22] <dm> it's pubic +[23:22] *** mihi (mihi@anon.iip) has joined channel #iip-dev +[23:22] <dm> I crack myself up. +[23:23] <jrand0m> ok, on that note +[23:23] <jrand0m> I think we've just gotten away with a 23 minute meeting :) +[23:23] * jrand0m slips the *baf*er out of my back pocket and *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/61.rst b/i2p2www/meetings/logs/61.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/61.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/62.log b/i2p2www/meetings/logs/62.log new file mode 100644 index 00000000..a44b1fc2 --- /dev/null +++ b/i2p2www/meetings/logs/62.log @@ -0,0 +1,284 @@ +[23:01] <jrand0m> agenda +[23:01] <jrand0m> 0) welcome +[23:01] <jrand0m> 1) 0.2 status +[23:01] <jrand0m> 2) www proxy +[23:01] * dm ponders. +[23:02] <dm> oh, meeting? +[23:02] <jrand0m> 3) phttprelay +[23:02] <jrand0m> 4) i2ptunnel +[23:02] <jrand0m> 5) installation +[23:02] <dm> sorry. +[23:02] <jrand0m> 6) iip feature request +[23:02] <jrand0m> 7) ??? +[23:02] <jrand0m> 0) welcome +[23:02] <jrand0m> hi. +[23:02] <jrand0m> meeting 62? is it? +[23:02] <Dellammo> hi +[23:02] <jrand0m> (no worry dm, we can forgive you) +[23:02] <mihi> hi jrand0m +[23:02] <dm> hi mihi +[23:02] * mihi thinks so +[23:03] <jrand0m> 1) 0.2 status +[23:03] * jrand0m has had a severe case of feature-creep-itis as of late, so the 0.2 release still has about 30 minutes left of code left to do. +[23:04] <jrand0m> but then we'll be able to run and communicate reliably regardless of NAT, firewall, or HTTP proxy. +[23:04] * dm has just created I2PSecureRemoteShell 1.0 +[23:04] <dm> cool jr! +[23:05] <jrand0m> everything is functional, the only thing left to do is to expire unused database entries after N minutes (probably 5 for a default) +[23:05] <jrand0m> the comm across NAT/firewall/HTTP proxy is the PHTTP transport. its slow, but reliable. +[23:05] <dm> how does it work? what ports does it use? +[23:06] <jrand0m> it sends the message to a reachable PHTTP relay, which stores the message, and then the receiver polls for messages ever N seconds +[23:06] <jrand0m> there is a LOT that can be tuned and improved on that side of things, which is agenda point 3 :) +[23:06] <dm> P stands for? +[23:06] <jrand0m> Polling HTTP +[23:06] <dm> ok thanks. +[23:07] <jrand0m> I'm going to update the "kludges" page on the wiki after the meeting too, to note the things that are funky +[23:07] <jrand0m> (such as not yet handling a lease change during communication) +[23:08] <jrand0m> the other point to discuss is agenda item 5 - installation. aka how we should handle installation of the router/sdk/tunnel/etc +[23:08] <jrand0m> ok, thats it for 0.2 status +[23:08] <jrand0m> 2) www proxy. +[23:09] <jrand0m> moi had a really cool idea for browsing in-i2p www sites. +[23:09] <jrand0m> wanna explain whats up moi? +[23:09] * jrand0m puts the spotlight on ya +*** moi is ~someone@anon.iip (someone) +*** on channels: #freenet #anonymous #iip #iip-dev +*** on irc via server anon.iip (Official IIP ) +*** moi has been idle 9 minutes, signed on at Thu Jan 01 01:00:00 1970 +[23:10] <moi> well +[23:10] <moi> i am just modifying an HTTP proxy and using mihi's tunnel +[23:10] <moi> so that you can go to (Link: http://i2p/BASE64KEYHERE)http://i2p/BASE64KEYHERE +[23:10] <moi> eventually the naming server would be there-- +[23:11] <dm> sweet +[23:11] *** Signoff: mihi (Ping timeout) +[23:11] <moi> you have to paste in the first long key, but after that you should technically be able to follow links I think +[23:11] <Dellammo> so an internal web page or a page outside of i2p? +[23:11] <dm> i2p resolves to localhost? +[23:11] <moi> so someone could put up an i2p Google, and go from there.... mabye +[23:12] <mihi-backup> !thwap dm. +[23:12] <mihi-backup> a proxy... +[23:12] <jrand0m> for security, the proxy should 404 all hosts other than (Link: http://i2p/)http://i2p/ +[23:12] <dm> oops! +[23:12] <moi> good point +[23:12] <dm> missed that part +[23:12] <mihi-backup> although a simple servlet would be nice too +[23:12] <jrand0m> hmm? +[23:13] *** mihi (~mihi@anon.iip) has joined channel #iip-dev +[23:13] <jrand0m> hmm, there may be a problem. +[23:13] <jrand0m> this would use HTTP 1.0 or 1.1? +[23:14] <mihi> if the server requests a Host: header? +[23:14] <jrand0m> [aka, would it have a Host: header?] +[23:14] <jrand0m> exactly +[23:14] * mihi wishes for something +[23:14] <moi> I wonder if we can have the proxy blank that out +[23:14] <jrand0m> if the server's outbound tunnel is always on the same host, thats fine +[23:14] <jrand0m> you can set the proxy Host: to 127.0.0.1 +[23:15] *** dm_backup (~as@anon.iip) has joined channel #iip-dev +[23:15] <jrand0m> but then you must run the tunnel on the same host as the server. not a bad problem, as its not for general normal-web browsing +[23:15] <jrand0m> right? +[23:15] *** Signoff: dm (Ping timeout) +[23:16] * moi hadn't thought that deeply into it yet +[23:16] <mihi> if you run the server on your own box you can also alias i2p to localhost or sth like that. +[23:16] <dm_backup> so do people have to run web servers now? +[23:16] <jrand0m> dm_backup> this is only for people who want to. +[23:16] *** dm_backup is now known as dm +[23:16] <Dellammo> like me +[23:16] <dm> yeah, I mean for this (Link: http://i2p)http://i2p thingie +[23:17] <mihi> if you want to provide content, yes. +[23:17] <mihi> but you have to run one to provide content in good ol' www as well. +[23:18] <Dellammo> why? +[23:18] <dm> Hmmm, maybe I should build a P2P app for I2P. +[23:18] <jrand0m> a filesharing app over i2p would rule. +[23:18] <dm> yes sorry, filesharing. +[23:19] <moi> I think it would be possible for someone to run an OpenNap server in conjunction with i2ptunnel +[23:19] <jrand0m> yes. +[23:19] <jrand0m> (though a native i2p p2p would have better performance) +[23:19] <mihi> but the downloads will be hard. +[23:20] <mihi> no way to get to the correct host as all are localhost ;) +[23:20] <dm> Let's wait till we see PING running over i2ptunnel first. +[23:20] * Dellammo is confused are we talking about a proxy thats not i2ptunnel that lets you access webservers that are internal to the i2p network by typing '(Link: http://i2p/')http://i2p/' ? +[23:20] <jrand0m> perhaps just a simple FTP client designed to run over i2p? +[23:20] <dm> (not ping literally) +[23:20] <mihi> jrand0m: ftp needs 2 ports... +[23:20] <jrand0m> designed to run over i2p. +[23:21] <jrand0m> a general file transfer app, not the FTP protocol, specifically +[23:21] <mihi> then it's not ftp. +[23:21] <mihi> ATalk ;) +[23:21] <jrand0m> (taking advantage of larger message sizes) +[23:21] <dm> battle of the wise men! +[23:21] <jrand0m> heh +[23:21] <moi> Dellammo: right now you have to create an i2ptunnel for each website/Destination you want to browse. We are thinking of using a proxy server that would dynamically build an i2ptunnel for each site. +[23:22] <jrand0m> (kind of) +[23:22] <jrand0m> you won't want to use an i2ptunnel, specifically. +[23:22] <jrand0m> you'll want to use the i2ptunnel protocol, and send messages directly, not via TCP/IP sockets. +[23:23] <jrand0m> mihi> any idea what kind of time it would take to factor the protocol functionality out of i2ptunnel so other apps could send data to an i2p tunnel? +*** mihi is mihi@anon.iip (mihi) +*** on channels: #iip-dev #iip #headlines #german #freenet-opn #freenet #fredisdead #frazaa @#fiw #anonymous +*** on irc via server anon.iip (Official IIP ) +*** mihi has been idle 3 minutes, signed on at Thu Jan 01 01:00:00 1970 +*** mihi-backup is ~mihi@anon.iip (mihi) +*** on channels: #iip-dev +*** on irc via server anon.iip (Official IIP ) +*** mihi-backup has been idle 12 minutes, signed on at Thu Jan 01 01:00:00 1970 +[23:25] <mihi> is there any large protocol functionality? I2PTunnelRunner can be used as is. +[23:25] <mihi> You just have to adjust the client class for your needs. +[23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket +[23:26] <jrand0m> this is a plain java app that wants to generate a message ("HTTP GET /\n\n") and send it to an outbound I2PTunnel +[23:27] <jrand0m> we don't want to redirect the client contacting the proxy to a new port to connect to the newly instantiated I2PTunnel (as there'd be no way to switch back for links off that site) +[23:28] <jrand0m> but perhaps switching I2PTunnelRunner to use an InputStream (all it uses is socket.getInputStream) would be easy... +[23:28] <jrand0m> but then we still need the listen side +[23:28] *** Signoff: mihi (Ping timeout) +[23:28] <jrand0m> d'oh +[23:28] * jrand0m hopes the backup isn't about to ping out... +[23:28] <dm> backup's gonna die as well ,watch it! +[23:29] <mihi-backup> ;) +[23:29] <jrand0m> w00t +[23:29] <mihi-backup> [23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket +[23:29] <mihi-backup> [23:25] <mihi> oops, right. and you want to do it completely without sockets? +[23:29] <mihi-backup> [23:26] <mihi> then there is not much code left from i2ptunnel. most is for handling the sockets. +[23:29] <mihi-backup> [23:26] <mihi> best stick to the protocol and implement it yourself (build the messages w/ the static method in i2ptunnel.java) +[23:29] <mihi-backup> [23:28] <mihi> http would not need that many threads. Just run a reader over the incoming message until a double return and then send your thing out. +[23:30] <jrand0m> ah 'k. thanks +[23:30] <jrand0m> moi> tu sabes? +[23:30] <mihi-backup> re switching I2PTunnel for an input stream. what for? you won't get anythin on it any more after you parsed the request. +[23:31] * moi thinks +[23:31] <dm> toi thinks +[23:31] <mihi-backup> just forget the tunnelrunner. ;) +[23:31] <jrand0m> right, I was just thinking to keep the I2PTunnel and the http proxy to use the same code - I2PTunnel would use socket.getInputStream(), the http proxy would use new ByteArrayInputStream("GET / \n\n".getBytes()) +[23:31] *** mihi (mihi@anon.iip) has joined channel #iip-dev +[23:32] * moi will need to go over this later in detail +[23:32] <mihi-backup> but that will cause the runner to send a "Connection closed" when the string is sent. +[23:32] <mihi-backup> as the stream ends. +[23:32] <jrand0m> right, which is normal HTTP +[23:33] <mihi-backup> just forget the runner, i said ;) +[23:33] <jrand0m> 'k +[23:33] <mihi-backup> jrand0m: nope. the connection is closed when the answer is here, not when the question is out. +[23:33] <jrand0m> oh yeah +[23:33] <jrand0m> ;) +[23:36] <jrand0m> cool moi, we can work through this stuff later on. +[23:36] <jrand0m> ok, thats agenda item 2). now for 3) +[23:36] <moi> ok +[23:37] <jrand0m> 3) phttprelay +[23:37] <jrand0m> phttp relay is a set of servlets wrapped in a .war file +[23:38] <jrand0m> it works out of the box on windows / sun JVM, but I had to hack jetty to run w/ kaffe +[23:38] <mihi> make .peace not .war +[23:39] * jrand0m groans +[23:39] <dm> you can run .war files without a J2ee server? +[23:39] <dm> good to know. +[23:39] <jrand0m> .war files run in any servlet container - tomcat, apache w/ mod_jk, jetty, etc +[23:40] <jrand0m> we're going to want some people to run these on machines w/ publicly reachable IP addresses, but they're only necessary for people who don't have publicly reachable addresses (like me) +[23:41] <mihi> which ports do you need to redirect if you want to go through a nat without that? +[23:41] <jrand0m> its implementation is very rudimentary as well - it needs some limits as to how many routers it relays for, how many messages it queues up, how long before it times out, etc +[23:41] <jrand0m> just the I2NP TCP port +[23:41] <jrand0m> (or the I2NP UDP port) +[23:41] * mihi does not know if his nat allows udp forwarding +[23:42] * jrand0m doesn't know if mihi's nat does either +[23:43] <jrand0m> right now, for example, my laptop is reachable via PHTTP only, and my server's router is reachable via PHTTP, TCP, and UDP. if my laptop establishes a connection to the server's router via TCP, it can send messages via TCP. but if my laptop doesn't first do that, the server must send messages via PHTTP +[23:44] <jrand0m> the code is in i2p/code/apps/phttprelay/ for anyone with servlets experience who wants to hack on a small app +[23:45] <jrand0m> (it should also work transparently with https as well as plain http) +[23:45] <jrand0m> I'll doc up the PHTTP protocol Real Soon Now. :) +[23:45] *** Signoff: mihi (Ping timeout) +[23:45] <jrand0m> ok, thats it for item 3) phttprelay +[23:45] <jrand0m> 4) i2ptunnel +[23:46] <jrand0m> we've already discussed a bunch of stuff. unless mihi (or anyone else) has anything else on it, we can move to 5) +[23:46] *** wilde (~anon@anon.iip) has joined channel #iip-dev +[23:46] <jrand0m> hola wilde +[23:47] <jrand0m> ok. that said, item 5 :) +[23:47] <jrand0m> 5) installation +[23:48] <jrand0m> to get 0.2 out the door, and beyond, I'm thinking of some ant scripts. +[23:48] <jrand0m> or should we use another open source installation system? +[23:48] <jrand0m> anyone have any experiences / thoughts on this? +[23:49] <Dellammo> hmm +[23:50] <jrand0m> ant has the benefit of being unified with the build system, platform independent, and has headless operation. +[23:50] <wilde> hey +[23:50] <jrand0m> but it requires ant (which requires java). and it doesn't have a GUI +[23:51] <Dellammo> i can think of many install programs for windows... i dont know how many are gpl though +[23:51] <jrand0m> yeah, I have a licensed InstallAnywhere Enterprise installation, but its bad for open source +[23:51] <jrand0m> NSIS is open source, but has its nuances. +[23:51] <dm> stupid question: is ant included in java? +[23:52] <jrand0m> nope. +[23:52] <jrand0m> oh, though we COULD distribute a GCJ'ed ant +[23:52] <dm> alright, must have come with eclipse then. +[23:52] <jrand0m> (compiled to native code) +[23:52] <jrand0m> definitely dm. +[23:52] <jrand0m> apache makes ant (ant.apache.org) and its apache licensed. +[23:52] <jrand0m> oh, yuck. +[23:52] * jrand0m just read the sentence I typed) +[23:53] <jrand0m> gpl is not apl friendly, according to the FSF +[23:53] <jrand0m> we probably can't distribute ant. +[23:53] <dm> can't we just a script? what needs to be done for it to be installed? +[23:53] <jrand0m> but we can use it. +[23:53] <jrand0m> not much at all. a script is fine. +[23:53] <jrand0m> but do we want a .bat and a .sh, etc. +[23:54] *** shardy (~shardy@anon.iip) has joined channel #iip-dev +[23:54] <dm> what does an installation entail, a couple of questions? +[23:54] <jrand0m> writing a java installer to do the install platform independent is overkill, so we should ideally use an existing install framework +[23:54] <jrand0m> yeah, a few questions +[23:54] <jrand0m> the installation targets I forsee: +[23:54] <Dellammo> do we get a flashy new logo? whos working on that? +[23:54] <jrand0m> install-router +[23:55] <jrand0m> install-www-tunnel, install-www-proxy, install-sdk, install-cvs-tunnel, update-seednodes +[23:55] <moi> why not use InstallAnywhere? if the code is open that is what matters +[23:55] * jrand0m thinks YOU are Dellammo :) +[23:55] <jrand0m> InstallAnywhere isn't open source. +[23:55] * Dellammo gets to work +[23:56] <dm> script would probably be enough at this point, but I guess might as well think ahead. +[23:56] <jrand0m> (its about 4k euro / seat) +[23:56] <jrand0m> right. so for tomorrow, I'll probably just write ant scripts, but we need to look into a system +[23:56] *** Signoff: wilde (Ping timeout) +[23:56] <jrand0m> so if anyone can help out with that, it'd be appreciated :) +[23:57] <dm> ah okay, I was thinking shell scripts. +[23:57] <moi> Some of the package managers could do that on the Linux installs +[23:57] *** wilde (~anon@anon.iip) has joined channel #iip-dev +[23:57] <jrand0m> managing different installers for different platforms is a PITA +[23:59] <dm> java installer? Why is it a PITA? +[23:59] <jrand0m> a java installer would be great +[23:59] <mihi-backup> pain in the a**e +[23:59] <mihi-backup> oops, sorry... +[23:59] <dm> system.out.println("Please enter where you would like to install I2P") ;) +[23:59] <mihi-backup> s/tln/t; s/P"/P: "/ +[23:59] <mihi-backup> s/sys/Sys/ +[00:00] <jrand0m> writing a custom installer in java is possible, but its preferred to use an existing framework. but if you're volunteering to write a custom installer, I'm behind ya! +[00:00] <dm> mihi's having an epileptic seizure. +[00:00] * mihi-backup slaps dm around a bit with a large trout +[00:00] <dm> Tell you what... +[00:01] <dm> If you have time at any point to write out the exact steps needed in an install, I'll write a java installer. +[00:01] <mihi-backup> dm: read the ant script ;) +[00:01] <jrand0m> word dm. once I get the ant thing working I'll doc 'er up for you +[00:01] <dm> fair enough, we'll see if I can figure out the ant script once it's out. +[00:02] *** Signoff: wilde (Ping timeout) +[00:02] <Dellammo> jrand0m, i2p I2P i^2p or I^2P ? +[00:02] * jrand0m has some scribbles with a capital I, 2 and a capital P all superimposed on each other... +[00:03] <Dellammo> hmm +[00:03] *** wilde (~anon@anon.iip) has joined channel #iip-dev +[00:03] *** mihi (~mihi@anon.iip) has joined channel #iip-dev +[00:03] <jrand0m> ok, thats 5) installation +[00:03] <jrand0m> 6) iip feature request +[00:04] <jrand0m> someone came on here with a request for auto-nicktheifing +[00:04] <jrand0m> basically, if someone has registered a nick, no one can stay as that nick unless they're identified +[00:04] <jrand0m> nop or anyone who has done iip dev - thoughts? +[00:04] * jrand0m thinks it'd be a great feature to have +[00:05] * Dellammo draws an illuminati eye with a no 'as in no smoking sign' over it +[00:05] <jrand0m> heh +[00:05] <dm> Maybe I'll make an I2P logo as well... for the gui part of my installer ;) +[00:05] *** Signoff: wilde ((null)) +[00:05] <Dellammo> lets all make them, so we dont get stuck with a sucky logo +[00:05] <mihi> jrand0m: ask mids - he maintains trent. +[00:06] <mihi> the trent source is in cvs btw +[00:06] <Dellammo> the logo is the most important part of any activity +[00:06] <jrand0m> definitely Dellammo. +[00:06] * dm dusts off Corel Draw... +[00:06] <dm> man I love Corel Draw. +[00:07] <jrand0m> ok, thats it for 6) +[00:07] <jrand0m> 7) ??? +[00:07] <jrand0m> any questions / thoughts / frisbees/ toenails? +[00:07] <dm> Thought: hope it works. +[00:08] <jrand0m> heh +[00:08] * jrand0m too. +[00:09] <mihi> jrand0m: keep the good work! +[00:09] <dm> yes, keep it up. +[00:09] <jrand0m> good work? you obviously haven't seen the code ;) +[00:09] <dm> Love your code, except for the bliding underscores. +[00:09] <dm> blinding...bleeding..etc.. +[00:09] <jrand0m> heh, instance variables have _, so we don't ever need to do this.var = var; +[00:10] <jrand0m> ok... 68 minutes... if I can drag this out for one more minute... +[00:10] <jrand0m> w00t +[00:10] * jrand0m *baf*s the meeting closed. diff --git a/i2p2www/meetings/logs/62.rst b/i2p2www/meetings/logs/62.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/62.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/63.log b/i2p2www/meetings/logs/63.log new file mode 100644 index 00000000..e48fc588 --- /dev/null +++ b/i2p2www/meetings/logs/63.log @@ -0,0 +1,177 @@ +[22:59] <dm> so when IS this meeting? +[23:00] <jrand0m> now. +[23:00] <jrand0m> 0) welcome [63] +[23:00] <jrand0m> 1) roadmap: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap +[23:00] <jrand0m> 2) 0.2 todo: +[23:00] <jrand0m> - long lasting comm testing +[23:00] <jrand0m> - lease rebuilding bugs +[23:00] <jrand0m> 3) prng (yay) +[23:00] <jrand0m> 4) apps / questions / etc +[23:00] <jrand0m> 0) hi +[23:00] <jrand0m> sorry for being stupid and forgetting about daylight savings time +[23:00] <jrand0m> welcome to meeting #63 +[23:01] *** darl_mcbride has left #iip-dev +[23:01] <jrand0m> 1) roadmap +[23:01] <jrand0m> the roadmap is at the above url and will be updated whenever necessary. +[23:02] <jrand0m> yes, the dates are further out than they've been in the past, and thats largely a reflection of 1) me not wanting to release shitty software 2) me overlooking details in previous estimates +[23:02] <jrand0m> but, of course, as it says on the roadmap, "If you get involved and help out with some of the coding, things will go faster" :) +[23:03] <jrand0m> 0.2 itself will allow actual useful functionality +[23:03] *** Signoff: thecrypto (Ping timeout) +[23:03] <dm> that's good news. +[23:03] <jrand0m> ok, item 2) 0.2 todo +[23:04] <jrand0m> i've been doing qa on the 0.2 release for the last week or so and have been tracking down some bugs that have been hard to spot +[23:04] <jrand0m> but i think I found their source a few minutes ago, and I'm running a test against it right now in the background. +[23:05] <jrand0m> (the problem has been that after a few hours of use, communication with a router or a destination fails) +[23:05] <dm> what kind of testing rig are you using? Is it all local at this point? +[23:05] <jrand0m> three routers local, three routers remote +[23:05] <sisr> Does 0.2 include the feature that when a router is not able to be contacted after a certain number of times it stops trying? +[23:05] <jrand0m> yes +[23:06] <jrand0m> every router publishes its contact info every N (currently 2) minutes to everyone it knows. if a router doesn't get new contact info every 2.5*N minutes, it drops its reference. +[23:06] <jrand0m> however, if it /wants/ to find a new router (aka it gets a reference to it via a Lease), it can do a search at any time and find it +[23:07] <jrand0m> however, running three routers plus two active destinations locally is, well, a CPU beast. +[23:08] <jrand0m> I've added a nasty feature which I feel dirty about, but it lets you add an environmental variable to basically turn off ElG and AES encryption. thats only useful for communication with other nodes with the encryption turned off (as otherwise you wouldn't be able to talk) +[23:09] <jrand0m> ok, thats it for 0.2 todo +[23:09] <dm> for your testing purposes? +[23:09] <jrand0m> yeah basically +[23:09] <jrand0m> (and/or for anyone else who is doing their own testing to add new features / etc ;) +[23:10] <jrand0m> in theory however, two destinations (like atalk) could set the -Di2p.encryption=off flag and still work (though there wouldn't be any end to end encryption) +[23:10] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev +[23:10] <jrand0m> but i think thats a Bad Idea. +[23:11] <jrand0m> this feature will most certainly get pulled once the AES+SessionTag stuff gets worked out +[23:11] <jrand0m> ok, 3) prng +[23:11] <sisr> Are there any suggested minimum CPU and RAM requirements? +[23:12] <sisr> sorry +[23:12] <jrand0m> hmm, RAM is minimal (sun's JVM takes 7-10Mb, kaffe 16-22Mb) +[23:13] <jrand0m> CPU is definitely the limiting factor at the moment,but I don't have a wide array of boxes to test on ;) +[23:14] <jrand0m> let me just say that running three routers and two i2ptunnels pointing offsite to a squid on the same box pretty much hoses my P4 1.7Ghz box +[23:14] <thecrypto> i might be a little more active if you want me to say somethingh +[23:14] <dm> alright, say something. +[23:15] <jrand0m> hiya thecrypto :) +[23:15] <sisr> Why would anyone run more than one router on the same computer? +[23:15] <jrand0m> sisr> only a developer would. +[23:16] <sisr> Ok, so the CPU should not be too bad and we can run some tests over the weeks +[23:16] <jrand0m> word +[23:17] <jrand0m> ok, the prng stuff turned out to be a bug in kaffe, which is now fixed. +[23:17] <jrand0m> with that, we don't have any hard need to get a yarrow impl, as they use sha1prng +[23:18] <jrand0m> (but it'd be nice, whenever we get it) +[23:18] <jrand0m> ok, 4) apps / questions / etc +[23:18] <jrand0m> I don't have anything else, so... hi :) +[23:19] <jrand0m> any questions / thoughts / comments on anything else? +[23:19] <sisr> How is the naming server? I have not seen co for a long time +[23:19] *** co (anon@anon.iip) has joined channel #iip-dev +[23:19] <jrand0m> speaking of the devil +[23:19] <jrand0m> hi co +[23:19] <sisr> haha +[23:19] <co> Hello. +[23:20] <jrand0m> we're at that point where there's not really anything left on the agenda 'cept for questions +[23:20] <jrand0m> [23:19] <sisr> How is the naming server? I have not seen co for a long time +[23:20] <jrand0m> [23:19] *** co (anon@anon.iip) has joined channel #iip-dev +[23:20] <jrand0m> and that happened :) +[23:20] *** Signoff: godmode0 (EOF From client) +[23:21] <co> There has been no progress on it. I wrote just a small part of the client, and none of the server. +[23:22] <jrand0m> coo' +[23:22] * dm points the shame-stick at co. +[23:22] <sisr> I believe the HTTP i2p tunnel is working good now +[23:22] <sisr> i have adapt mihis excellent httpclient so that you type it into your proxy setting +[23:23] <jrand0m> aweseme! +[23:23] <sisr> it also does some simple filter of non i2p site +[23:23] <sisr> i think jrand0m has commit this already, yes? +[23:23] <jrand0m> do we know what browsers it works with? I know moz... +[23:23] <jrand0m> yeah, I think I committed that stuff.. lemmie check +[23:23] * co is appropriately ashamed. +[23:23] <sisr> It working with Mozilla and the Konqueror +[23:24] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev +[23:24] <jrand0m> dont worry co, I'm already 2 months behind schedule +[23:24] <sisr> I will try to get the mihi I2P tunnel to work with E-mail server this week +[23:24] <sisr> Also many wiki pages have updated +[23:24] <jrand0m> oh yeah! thanks for that +[23:25] * jrand0m actually added a caveat to one of the FAQs this afternoon :) +[23:25] * dm decides to concentrate his awesome analytical brainpower towards determining where sisr is from. +[23:25] <dm> "Also many wiki pages have updated" +[23:25] <sisr> Ok go ahead +[23:25] <dm> mmmm.....MMmmmm.....mmmmmm... +[23:26] <dm> ah, another clue? +[23:26] <sisr> But I can not tell you if you are correct +[23:26] <dm> "..... has commit this already, yes?" +[23:26] <co> jrand0m: If this has not been asked already, do you want to release the I2P framework and applications as a package at the same time? +[23:27] <jrand0m> I've found that what I want and what happens isn't always the same thing +[23:27] <co> I mean release them together. +[23:27] <sisr> I have a question after co +[23:27] <jrand0m> the current plan is up at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap +[23:28] <jrand0m> i2p itself will be the router and the sdk, but with it will be bundled any applications that are ready, whenever they're ready. +[23:28] <jrand0m> (the installer right now bundles the router, sdk, phttprelay, atalk, and i2ptunnel) +[23:29] *** Signoff: dm (Ping timeout) +[23:29] <jrand0m> 'sup sisr? +[23:29] <co> That page is quite helpful. Thank you. +[23:30] <sisr> The I2P is very big and it can be used to browse the WWW, to browse I2P Tunnel connect programs and web pages and If someone write a direct I2P webserver and client, can go without the tunnel +[23:30] <jrand0m> absolutely. +[23:30] <sisr> My question is how is the I2P developer target towards? Make everything working with I2P Tunnels so that users can have the programs They are already familiar with like IE or +[23:31] <sisr> Is it better to try and make I2P web server program, I2P web browser everything special for the I2P ? +[23:31] *** dm (~as@anon.iip) has joined channel #iip-dev +[23:32] <jrand0m> personally, I'd love if the former could happen. however, there will be performance gains by designing apps native to i2p +[23:32] <mihi> unix principle: one job, one tool. so don't write new browsers. +[23:32] <jrand0m> right +[23:32] <sisr> How much is the overhead of the I2P Tunnel? So we should focus on use the I2p Tunnel to get existing program to work +[23:32] <dm> one job, one tool? silly principle. +[23:33] <sisr> I believe we will need tutorial for people to set up Squid and E-mail proxy to the regular WWW. This is valuable and more than one or two is needed so this means Easy instructions for others to set up their own +[23:33] <jrand0m> sisr> the only significant overhead of i2ptunnel is its reliance on i2p's guaranteed delivery mode, which requires waiting for an ack message after each message sent (a full round trip through the pair of tunnels, using all appropriate encryption) +[23:34] <sisr> Haha, ok sisr has a very old computer +[23:34] <sisr> It seem real slow to me because of this +[23:34] <dm> what was latency like on the first few real tests? Just out of curiosity. +[23:35] <jrand0m> I can pull news.google.com with all images in ~ 30-60 seconds +[23:35] <dm> k +[23:36] <sisr> How difficult will it be to set up a Freenet like content distribution system on top of I2P? Is that major effort or minor effort? +[23:36] <co> And how much time does it take without the tunnel? +[23:36] <jrand0m> sisr> if I worked on it fulltime, I'd suspect ~ 1 month to get a DHT on top of i2p +[23:37] <jrand0m> co> ~ 10-15 seconds +[23:38] <co> So i2ptunnel is 3 times as slow. +[23:39] <jrand0m> well, i2ptunnel + the routers. but that is not a linear time - sending 10 bytes over i2p takes about as long as sending 100k +[23:39] *** Signoff: thecrypto (Ping timeout) +[23:39] <co> For you, at least. +[23:39] <jrand0m> the overhead is in the message wrapping +[23:39] <sisr> If the I2P tunnel is to be the core of most application for I2P then we should concentrate on the User interface and make easy to click option to set up tunnel +[23:40] <sisr> Like checkbox to set up I2P Tunnel web server with port, and Checkbox for E-mail server, so it real simple +[23:40] <jrand0m> sisr> I personally really really like its interface atm :) +[23:40] <jrand0m> oh, definnitely. actually +[23:40] * sisr has never seen the interface but imagines it like the textbox +[23:40] <sisr> Maybe someone can screencap the I2P tunnel for tutorial +[23:41] <jrand0m> what I was planning on is having the installer create a set of .bat and .sh scripts to do so automatically (e.g. java .... I2PTunnel -e 'config basdfawer' -e 'server ...' ) +[23:42] <sisr> What should we be working on for I2P now +[23:42] <jrand0m> thats a big question. short answer is "whatever you can" +[23:43] <jrand0m> if someone were to go ahead and update the installer to build those .sh and .bat scripts, that would rule +[23:43] <jrand0m> if anyone has time to work on some of the things on the i2proadmap, that would also rule :) +[23:44] <jrand0m> I think there's going to be a large demand for doc and qa once 0.2 is out (aka Real Soon Now) +[23:44] <sisr> How will the Installer be? Install shield or Java? +[23:44] <jrand0m> the current installer is a single "install.jar" which prompts the user through a few questions +[23:45] <jrand0m> its a really crappy installer +[23:45] <jrand0m> but its as platform independent as it gets +[23:48] <jrand0m> ok cool, the routers are still working, I think this bugfix may have done it. +[23:48] <jrand0m> oh yeah. +[23:48] <jrand0m> the mailing list will be back sometime +[23:48] <jrand0m> if it isn't back by the time 0.2 is ready, I'll create a new mailing list +[23:49] <co> I have one other question. +[23:49] <jrand0m> fire away +[23:50] <co> Is there a list available of I2P nodes running right now? +[23:50] <jrand0m> nope. +[23:50] <jrand0m> no public i2p nodes are open +[23:50] <co> I see. +[23:50] <jrand0m> however, one of them will make its list of peers available via http once 0.2 is released +[23:50] <jrand0m> (and the URL to that list will be in the installer) +[23:50] <jrand0m> s/will be/is/ +[23:52] <mihi> it's in my bookmarks as well... +[23:52] <jrand0m> heh bastard +[23:52] <mihi> btw: size=777 is 111 bytes too large ;) +[23:53] <jrand0m> rofl +[23:53] <jrand0m> I totally didn't notice that. +[23:53] <jrand0m> they used to be 384 +[23:53] <jrand0m> but then I added some router sw version info to the routerInfo +[23:53] <sisr> I think nop can use the I2P tunnel to set up a test IRC server with the 0.2 router? +[23:54] <jrand0m> that'd be really cool +[23:54] <sisr> I wonder how the latency comparing to this IIP if nop does that +[23:54] <jrand0m> though we wouldn't be able to dcc +[23:54] <jrand0m> i2p would be a lot higher latency +[23:54] <jrand0m> (as each send would be a few seconds, since we don't have AES+SessionTag yet) +[23:57] <jrand0m> ok, if anyone has anything to say before the list is back, either talk here or toss stuff up on the wiki +[23:57] <dm> k, night +[23:57] *** dm has left #iip-dev +[23:57] * jrand0m *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/63.rst b/i2p2www/meetings/logs/63.rst new file mode 100644 index 00000000..1fa758d9 --- /dev/null +++ b/i2p2www/meetings/logs/63.rst @@ -0,0 +1,7 @@ +I2P dev meeting, October 28, 2003 @ 21:02 UTC +============================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/64.log b/i2p2www/meetings/logs/64.log new file mode 100644 index 00000000..fa0f8f87 --- /dev/null +++ b/i2p2www/meetings/logs/64.log @@ -0,0 +1,189 @@ +[22:02] <jrand0m> agenda +[22:02] <jrand0m> 0) welcome +[22:02] <jrand0m> 1) i2p router +[22:02] <jrand0m> 1.1) status +[22:02] <jrand0m> 1.2) roadmap changes +[22:02] <jrand0m> 1.3) open subprojects +[22:02] <jrand0m> 2) native modPow +[22:03] <jrand0m> 2) gui installer +[22:03] <jrand0m> 3) IM +[22:03] <jrand0m> 4) naming service +[22:03] <MrEcho> i saw that .c code +[22:03] <jrand0m> 5) licensing +[22:03] <jrand0m> 6) other? +[22:03] <jrand0m> 0) welcome +[22:03] <jrand0m> hi. +[22:03] <nop> hi +[22:03] <jrand0m> meeting 2^6 +[22:04] <jrand0m> got any agenda items to add to there nop? +[22:04] <jrand0m> ok, 1.1) router status +[22:04] <jrand0m> we're 0.2.0.3 and last I heard, its functional +[22:04] <MrEcho> > 0.2.0.3 +[22:04] <MrEcho> right? +[22:05] <MrEcho> im running it .. seems fine +[22:05] <nop> no +[22:05] <jrand0m> there have been minor commits after the 0.2.0.3 release, nothing release worthy +[22:05] <nop> I am jus trying to catch up +[22:05] <jrand0m> coo' +[22:06] <jrand0m> given the experiences and feedback of 0.2.0.x, the roadmap has been updated to get things less resource intensive to run +[22:06] <jrand0m> (aka so people can run webservers / etc and it won't eat up their CPU) +[22:06] <jrand0m> specifically (moving to agenda 1.2): http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap +[22:06] <MrEcho> what ive noticed is that most routers use: TransportStyle: PHTTP +[22:07] <MrEcho> does it auto go to phttp or does it even try tcp first +[22:07] <jrand0m> hmm, most routers should support PHTTP, and if they can accept incomming connections, should support TCP as well +[22:07] <jrand0m> if at all possible it uses TCP +[22:07] <jrand0m> PHTTP is weighted about 1000 times more expensive than TCP +[22:08] <jrand0m> (see GetBidsJob, which asks each transport how much it thinks it'd cost to send a message to a peer) +[22:08] <jrand0m> (and see TCPTransport.getBid and PHTTPTransport.getBid for the values used) +[22:08] <MrEcho> ok +[22:08] <jrand0m> are you using PHTTP often to send and receive messages? +[22:09] <jrand0m> (that might be a sign that your TCP listener isn't reachable) +[22:09] <MrEcho> i didnt put in the urls on my side +[22:09] <jrand0m> ah 'k. +[22:09] <MrEcho> ohh it is +[22:10] <jrand0m> ok, yeah, my routers have open TCP connections to you +[22:10] <dm> how hospitable of them. +[22:10] * jrand0m is glad y'all made me implement routerConsole.html so we don't have to dig through the logs for this crap +[22:11] <MrEcho> is there a timeout thing if it doesnt connect to the tcp it goes phttp? and whatz the timing on it +[22:11] <jrand0m> but anyway, the big change to the roadmap is that 0.2.1 will implement the AES+SessionTag stuff +[22:11] <MrEcho> or could we have that in a setting? +[22:11] <jrand0m> if it gets a TCP connection refused / host not found /etc, it fails that attempt immediately, and tries the next available bid +[22:12] <MrEcho> so no retrys +[22:12] <jrand0m> phttp has a 30 sec timeout iirc +[22:12] <jrand0m> no need to retry. you either have an open TCP connection and can send the data or you don't :) +[22:12] <MrEcho> lol ok +[22:13] <MrEcho> will it try tcp everytime after that or skip that and just go phttp for the next connection? +[22:13] <jrand0m> it'll try tcp each time at the moment. +[22:13] <jrand0m> the transports don't keep histories yet +[22:13] <MrEcho> ok cool +[22:14] <jrand0m> (but if a peer fails 4 times they get shitlisted for 8 minutes) +[22:14] <MrEcho> well once the otherside gets the phttp msg it should connect to the router that sent the msg via tcp right? +[22:14] <jrand0m> correct. once any tcp connection is established, it can use it. +[22:14] <jrand0m> (but if both peers only have phttp, they'll obviously only use phttp) +[22:15] <MrEcho> that would mean that it couldnt est. a tcp connection to anything +[22:15] <MrEcho> .. but ya +[22:16] <MrEcho> i wish there was a way around that +[22:16] <jrand0m> no, one of my routers doesn't have a TCP address - only PHTTP. but I establish TCP connections with peers who have TCP addresses. +[22:16] <jrand0m> (and then they can send back messages along that TCP connection instead of sending me slower PHTTP messages) +[22:17] <jrand0m> or is that not what you mean? +[22:17] <MrEcho> ya i got mixed up +[22:17] <jrand0m> word, np +[22:18] <jrand0m> so, see the updated roadmap for updated schedule information ((Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap) +[22:18] <jrand0m> ok, 1.3) open subprojects +[22:19] <jrand0m> I finally put a bunch of my palmpilot's todo list into the wiki at (Link: http://wiki.invisiblenet.net/iip-wiki?OpenSubprojects)http://wiki.invisiblenet.net/iip-wiki?OpenSubprojects +[22:19] <jrand0m> so if you're bored and looking for code projects... :) +[22:19] <MrEcho> gezz +[22:20] <MrEcho> already got 2 +[22:20] <dish> You have a palmpilot this is elite +[22:20] <MrEcho> mine died +[22:20] <jrand0m> mihi> there's a line item in there wrt the I2PTunnel describing a thought I had a lil while ago +[22:20] <MrEcho> dont know whatz up wit hit +[22:21] <jrand0m> yeah, I used to have palms but just recently had this one donated to the cause ;) +[22:21] <dish> Could there be an agenda item at the meeting to discuss when the last time userX typed something was +[22:21] <MrEcho> damm thing doesnt even turn on anymore +[22:21] <MrEcho> lol +[22:22] <jrand0m> I don't think UserX has said anything in 4 or 5 months ;) +[22:22] <MrEcho> is that a bot or something? +[22:22] <dish> What did they say 5 months ago? +[22:22] <MrEcho> i bet its a bitchx running on some box he use to have access to .. and forgot about it +[22:22] <jrand0m> that they'd get back with comments about the anonCommFramework (i2p's old name) next week ;) +[22:23] <dish> haha +[22:23] <jrand0m> but I suppose he's busy. so is life +[22:23] <jrand0m> ok, 2) native modPow +[22:23] <MrEcho> i saw that c code +[22:24] <jrand0m> i put together a stub .c and java class to show how something like GMP or another MPI library could be integrated, but it obviously doesn't work +[22:25] <jrand0m> what would be good would be if we had a small package of C classes and that trivial associated Java wrapper class that we could build for windows, osx, *bsd, linux, and package up under GPL + +(insert major iip breakage here) + +[22:38] <MrEcho> last thing i saw was: [13:25] <jrand0m> ok, 2) native modPow +[22:38] <jrand0m> hi MrEcho +[22:38] <jrand0m> yeah, looks like a main proxy crashed +[22:39] <jrand0m> I'm giving it another 2 mins before restarting +[22:39] <MrEcho> k +[22:39] <MrEcho> for $25 1 time i can get full on java on thenidus.net ... one of my sites +[22:40] <jrand0m> $25? they charge you to install software? +[22:40] <MrEcho> no idea really .. its a package +[22:40] <MrEcho> talking to my friend right now +[22:40] <jrand0m> I'm not sure the code is quite stable enough to go out and rent a bunch of colo spots to put up routers though. yet :) +[22:41] <dm> package of what? +[22:41] <MrEcho> java - jsp +[22:41] <jrand0m> ok, resending what I sent before: +[22:41] <jrand0m> i put together a stub .c and java class to show how something like GMP or another MPI library could be integrated, but it obviously doesn't work +[22:41] <jrand0m> what would be good would be if we had a small package of C classes and that trivial associated Java wrapper class that we could build for windows, osx, *bsd, linux, and package up under GPL (or less restrictive license) +[22:41] <jrand0m> however with the new roadmap placing AES+SessionTag as my current action item, this isn't quite as critical as it was. +[22:42] <jrand0m> if anyone wants to run with this though, that'd be great (and I'm sure another project we're all familiar with would be interested in such a packaging) +[22:43] <dm> frazaa? +[22:43] <jrand0m> heh, in a way ;) +[22:44] <jrand0m> ok, 3) gui installer +[22:44] <jrand0m> MrEcho> hi +[22:44] <MrEcho> :) +[22:44] <MrEcho> hehe +[22:44] <MrEcho> its comming alog +[22:44] <jrand0m> cool +[22:44] <MrEcho> nothing fancy +[22:45] <MrEcho> ive got some really cool ideas to make it really fancy .. but thatz a way off +[22:45] <jrand0m> I was wondering if the installer should add 1) an option to auto-get the seeds from http://.../i2pdb/ 2) auto-get the http://.../i2p/squid.dest and create a runSquid.bat/runSquid.sh too? +[22:45] <jrand0m> word +[22:46] <jrand0m> yeah, we want the installer to be as simple as possible - what fancy stuff were you thinking of? +[22:46] <MrEcho> question is .. when you do java -jar installer it goes to the non gui by default because of the way u have things +[22:46] <MrEcho> how are we going to make it to were you dbl click the jar file and it loads the gui +[22:47] <jrand0m> install.jar <-- nongui, installgui.jar <-- gui +[22:47] <jrand0m> seperate code, seperate packages +[22:47] <MrEcho> fancy as in things you might not notice .. but its goingto be nice and clean +[22:47] <jrand0m> cool +[22:47] <MrEcho> aww ok +[22:48] <jrand0m> (or install <-- gui installcli <-- cli. we'll see how things progress) +[22:49] <jrand0m> anything else on the gui, or do we jump off to item 4)? +[22:49] <jrand0m> (any time frame you're thinking? no pressure, just wondering) +[22:51] <MrEcho> no idea right now +[22:51] <jrand0m> coo' +[22:51] <jrand0m> ok, 4) IM +[22:51] <jrand0m> thecrypto aint here, so..... +[22:51] <jrand0m> 5) naming service +[22:51] <jrand0m> wiht isn't here either... +[22:51] <jrand0m> ping +[22:52] <dish> you're off on the number agenda count +[22:52] <dish> 3) IM +[22:52] <jrand0m> yeah, I used to have 2 agenda item 2's +[22:52] <dish> 4) Naming +[22:52] <dish> ;) +[22:52] <jrand0m> (native modPow and gui installer) +[22:52] <jrand0m> see, we're dynamic and stuff +[22:59] <jrand0m> ok, for the logs I suppose I'll continue +[22:59] <jrand0m> 6) licensing +[23:00] <jrand0m> I'm thinking about going less restrictive than GPL. we are using some MIT code, plus one other file is GPL (but thats just the base64 encoding and can be replaced trivially). other than that, all of the code is either copyright by either myself or thecrypto. +[23:00] * dish look at mihi i2p tunnel part of code +[23:01] <jrand0m> oh right, mihi has released that as gpl but he may want to release it as something else if he wants, as well +[23:01] <jrand0m> (but i2ptunnel is essentially a third party app and can license how it wants) +[23:02] <jrand0m> (though since the i2p sdk is gpl, he's been forced to be gpl) +[23:02] <MrEcho> damm about time +[23:02] <jrand0m> I don't know. licensing is not my forte, but I'm inclined at least to move to lgpl +[23:02] * dish release the 10-20 line of change to I2P HTTP Client mihi code as whatever mihi license is +[23:03] <jrand0m> hehe :) +[23:06] <jrand0m> anyway, 7) other? +[23:07] <jrand0m> anyone have any questions / concerns / ideas wrt i2p? +[23:07] <dish> Let me ask +[23:07] <dish> Does the I2P have any group name feature? +[23:07] <jrand0m> group name feature? +[23:07] <dm> team discovery channel! +[23:07] <MrEcho> lol +[23:08] <dish> So that if you want to have private or seperate network, but some router get intermixed somehow without group name the two network would merge +[23:08] <MrEcho> hes thinking of waste +[23:08] <jrand0m> ah +[23:08] <dish> I don't know why you would want that, but I am just ask in case +[23:08] <jrand0m> yes, early on in the network design I was playing with that +[23:09] <jrand0m> its more advanced than we need for now (or for the relatively near future [6-12 months]) but may be integrated later +[23:09] <dish> Or is that a bad idea because it is better to keep it one large network +[23:09] <dm> i2pisdead +[23:09] <jrand0m> heh dm +[23:10] <nop> shad up +[23:10] <jrand0m> no dish, its a good idea +[23:10] <dm> nop: tough guy? +[23:10] <jrand0m> its essentially what release 0.2.3 is -- restricted routes +[23:10] <jrand0m> (aka you've got a small private (trusted) set of peers and you don't want everyone to know who they are, but you still want to be able to communicate with them) +[23:15] <jrand0m> ok, anything else? +[23:15] <nop> nah, I'm just being funny +[23:18] <dm> funny guy? +[23:20] <jrand0m> ok, well, /interesting/ meeting, with a few iip crashes in the middle ;) +[23:21] * jrand0m *baf*s the meeting to a close diff --git a/i2p2www/meetings/logs/64.rst b/i2p2www/meetings/logs/64.rst new file mode 100644 index 00000000..13bee125 --- /dev/null +++ b/i2p2www/meetings/logs/64.rst @@ -0,0 +1,9 @@ +I2P dev meeting, November 11, 2003 @ 21:02 UTC +============================================== + +Quick recap +----------- + +TODO + +(meeting log edited to cover up the fact that iip crashed midway through the meeting and there were lots of ping timeouts, so don't try to read this as a plain narrative) diff --git a/i2p2www/meetings/logs/65.log b/i2p2www/meetings/logs/65.log new file mode 100644 index 00000000..78f9dcd3 --- /dev/null +++ b/i2p2www/meetings/logs/65.log @@ -0,0 +1,617 @@ +[22:02] <jrand0m> agenda: +[22:02] <jrand0m> 0) welcome +[22:02] <jrand0m> 1) i2p dev status +[22:02] <jrand0m> - 0.2.1.1 is out (peer and tunnel updating and testing, tuning enhancements, tunnel throttling, a DoS defense) +[22:02] <jrand0m> - don't use bw limiting (still some debugging) +[22:02] <jrand0m> - keep your clocks generally correct (30 minute fudge factor) [used for lease expirations and garlics] +[22:02] <jrand0m> 2) kademlia, 0.3, and idn +[22:02] <jrand0m> 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? +[22:02] <jrand0m> 4) app status [ppp2p, i2ptunnel, im, ns, squid] +[22:02] <duck> 5) why does jrand0m drink cheap local beer? +[22:02] <jrand0m> 5) comments / questions / etc +[22:02] <jrand0m> heh +[22:02] <jrand0m> so yeah, basically that fits under 5 :) +[22:02] <mihi_> double 5 ;) +[22:03] <mihi_> oops... +[22:03] <jrand0m> 0) welcome +[22:03] * mihi_ did not look 2 the left column +[22:03] <jrand0m> hi. 65th meeting I suppose. +[22:03] <jrand0m> hehe +[22:03] <jrand0m> 1) that code stuff +[22:04] <jrand0m> 0.2.1.1 came out last night +[22:04] <jrand0m> lots of goodness in there. +[22:04] * mihi tests it atm. +[22:04] <jrand0m> tunnels are tested and fail fast, penalizing all participants so they won't likely get into the rebuild +[22:05] <jrand0m> messages in i2ptunnel are also throttled to max 64k size (larger messages caused badness) +[22:05] <jrand0m> there are some bugs being worked out with the bw limiting code, so make sure your bw limits in router.config are negative values +[22:06] <jrand0m> (i2p doesn't have enough traffic on it to cause real load atm anyway) +[22:06] <jrand0m> (but bw limiting will be unit tested and fixed for 0.2.1.2) +[22:07] <jrand0m> also, please try to keep your clocks close to correct. it sucks that we have to need that, but right now we do. +[22:07] <jrand0m> we may be able to work out a way to not require semi-sync'ed clocks, but its delicate. +[22:07] <jrand0m> 2) fun stuff +[22:08] <jrand0m> a lot of the bugs being worked out in the last few releases are related to the crappy kludge of a BroadcastNetworkDB. +[22:08] <jrand0m> since its planned for replacement in 0.3, might as well at least mention what its being replaced with +[22:09] <jrand0m> kademlia is a structured distributed hash table (DHT) that lets us insert and fetch in under O(log(N)) time, guaranteed +[22:09] <jrand0m> [with one small caveat thats still being worked out] +[22:10] <jrand0m> that kademlia code needs to get written for 0.3 so we can do insert and fetch of RouterInfo and LeaseSet structures. +[22:10] <jrand0m> however, things would be simpler if it were implemented seperately - and hence testable seperately. +[22:10] <jrand0m> (unit testing == good) +[22:11] <jrand0m> so, whats a simple way to unit test a dht? to write a simple file store/lookup service on it. +[22:11] <dm> insert fetch? are we talking about content? +[22:11] <jrand0m> enter idn: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN +[22:11] <Ophite1> dm: No, only routerinfo and leaseset structures. +[22:12] <jrand0m> dm> i2p's networkDatabase currently contains only two specialized structures, as ophite said +[22:12] <dm> okay, thanks. +[22:12] <Ophite1> may or may not be useful to use it for bootstrapping other protocols too, but it's not anonymous itself. (?) +[22:12] *** grimps (~grimp@anon.iip) has joined channel #iip-dev +[22:12] <tusko> one question: which protocol is used now for networkDatabase? +[22:13] <jrand0m> sorry, phone. +[22:13] *** Signoff: godmode0 (Ping timeout) +[22:13] <jrand0m> correct, kademlia is not anonymous, but not non-anonymous either +[22:13] <Ophite1> modified kademlia will scale. random will not. +[22:13] <jrand0m> tusko> currently we do a flooded broadcast +[22:13] <duck> what about kademlia getting splitted? +[22:13] <dm> no cell phones allowed into meeting. +[22:13] <duck> <insert zooko comments> +[22:13] <Ophite1> flooded broadcast aka gnutella method definitely won't ;) +[22:13] <jrand0m> Ophite1> right, kademlia doesn't use random ones :) +[22:13] <duck> Ophite1: works better as freenet routing :) +[22:14] <jrand0m> duck> exactly (<jrand0m> [with one small caveat thats still being worked out] ) +[22:14] <Ophite1> duck: i rest my case... ;) +[22:14] *** Signoff: mihi (Ping timeout) +[22:14] <tusko> is kademlia some sort of hypercube? +[22:14] <Ophite1> no, a circle. +[22:14] *** Signoff: mihi_ (Ping timeout) +[22:14] <jrand0m> and/or a xor tree :) +[22:15] <Ophite1> splits/joins... reshuffle tree? can we take a peek at emule's overnetalike for this? :) +[22:15] <jrand0m> its a fairly easy protocol, but we can definnitely look around. +[22:16] <jrand0m> icepick has implemented kademlia in python too, for ent (as kashmir) +[22:16] *** mihi (~mihi@anon.iip) has joined channel #iip-dev +[22:16] <Ophite1> consider also malicious nodes deliberately fragmenting the tree. +[22:16] <jrand0m> absolutely. but its fairly attack resistant +[22:16] <Ophite1> 256 bit keyspace is more resistant to that though. +[22:17] <Ophite1> plus would have to make a lot of routeridentity structures = hard. +[22:17] <tusko> i found interesting the papers of gravepine: (Link: http://grapevine.sourceforge.net/)http://grapevine.sourceforge.net/ +[22:17] <jrand0m> this is also why I want to implement it first as an application, rather than rip out the core of i2p - so we can work out all the messy details first +[22:17] <Ophite1> so I'm pleased with sec 3 of 0.9 draft. +[22:17] *** Signoff: nickthief54450 (Excess Flood) +[22:18] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev +[22:18] <tusko> look to (Link: http://grapevine.sourceforge.net/tech-overview.php)http://grapevine.sourceforge.net/tech-overview.php +[22:18] <Ophite1> though I might point out that if message 0, DatabasePing, is inplemented, you might want to include a hashcash in it. +[22:18] <jrand0m> interesting tusko, I think their economic model might require some revision, as with their sybyl defenses +[22:19] <Ophite1> (you may already; haven't ready that part) +[22:19] <jrand0m> absolutely Ophite1. I was actually thinking about putting hashcash certs into all of the messages (DatabaseLookup included) +[22:20] <Ophite1> good idea. though, be careful of performance and tuning vs. dos defense there, and you might want to run hashcash calc in a separate, lower-priority thread? +[22:21] <jrand0m> well, hashcash verification should be near instantaneous +[22:21] <jrand0m> and hashcash generation shouldn't be able to be precompiled +[22:21] <jrand0m> er, precomputed +[22:21] <dm> Ophite1 must be an avatar created by jrand0m so that he can finally talk about I2P with someone who understands wtf he's saying. +[22:22] <jrand0m> lol +[22:22] * dm is not fooled. +[22:22] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev +[22:22] <Ophite1> one way of preventing that is to use derivatives of session keys as part of the hashcash.. +[22:22] <jrand0m> right. and/or put in a nonce and the date +[22:22] <Ophite1> date leads to those troublesome timing problems though. that could be a real issue. +[22:22] <Ophite1> unless you feel like rewriting ntp as well ;-) +[22:22] *** Signoff: mihi (Ping timeout) +[22:23] <jrand0m> heh +[22:23] <jrand0m> well, we've already run into that a little bit +[22:23] <jrand0m> (hence the 30 minute fudge factor) +[22:23] <jrand0m> a session hash may be workable though. good idea. +[22:24] <Ophite1> and no, i'm not jrand0m's clone ;) +[22:24] <jrand0m> ok, so for idn, I'm probably only going to implement the stuff on that I2PIDN wiki page +[22:25] *** Signoff: dm (Ping timeout) +[22:25] <jrand0m> what would probably rule would be if someone would take that and run with it - make a real user interface, better get/store apps, fec/ecc/etc. +[22:25] <jrand0m> also, I had some ideas about a search network built in parallel as well +[22:26] <jrand0m> but, well, its probably more useful to i2p that I focus my time on the router +[22:26] <Ophite1> it runs on top of i2p? +[22:26] <jrand0m> (making it functional, scalable, and secure) +[22:26] <jrand0m> yes +[22:26] <jrand0m> i2p lets idn be anonymous +[22:27] <Ophite1> what were your search network ideas? +[22:27] <jrand0m> note: its not written yet, but its looking like its #2 on my task list +[22:27] <Ophite1> can another dht be built through tunnels? +[22:27] *** mihi (~mihi@anon.iip) has joined channel #iip-dev +[22:27] <jrand0m> basically a distributed replicated db, with hashcash inserts and syncs, where people store idn keys along side metadata / etc +[22:27] *** dm (~as@anon.iip) has joined channel #iip-dev +[22:28] <jrand0m> hmm, yes, certainly. but i2p isn't inherently tunnel based - its message based (i2p is IP, i2ptunnel is TCP) +[22:28] <Ophite1> if ~all node participate = very useful for "discovering" other protocols. +[22:28] <jrand0m> definitely +[22:28] <Ophite1> so, should be standard. +[22:28] <Ophite1> dhcp/zeroconf for the i2p? :) +[22:28] <jrand0m> idn would be a very good app to bundle with i2p to let people have an 'out of box experience' +[22:29] <Ophite1> If it's meant to be a fully featured communication/file transfer/storage application, I'd like to propose the name "Darknet". +[22:29] <jrand0m> :) +[22:29] <Ophite1> You, of course, probably already know where that comes from. :) +[22:30] <dm> Where does it come from? +[22:30] <Ophite1> MS Research's paper: The Darknet and the Future of Content Distribution. +[22:30] *** Signoff: godmode0 (Ping timeout) +[22:30] <TC> link? +[22:30] *** tonious (~Flag@anon.iip) has joined channel #iip-dev +[22:30] <jrand0m> well, tim may says he invented the term ~11 years ago ;) +[22:30] <tusko> where is the I2PIDN wiki page? +[22:30] <dm> (Link: http://crypto.stanford.edu/DRM2002/darknet5.doc)http://crypto.stanford.edu/DRM2002/darknet5.doc +[22:30] <jrand0m> tusko> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN +[22:30] <Ophite1> also implies that the network works "in the dark" - noone knows who anyone is ;) +[22:30] <jrand0m> exactly. +[22:31] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev +[22:31] <jrand0m> well, i2p itself is a darknet in that sense, but its generic messaging - it is the IP layer for such a darknet. +[22:31] <jrand0m> i2ptunnel is the TCP layer, and idn is NFS :) +[22:31] <Ophite1> i2p is the protocol that allows such a network to be created from something broadly like overnet. +[22:31] <Ophite1> speaking of which... is there a way to specify priority in messages? +[22:32] *** mihi is now known as nickthief76430 +[22:32] *** mihi_ is now known as mihi +[22:32] <jrand0m> funny that you mention that :) +[22:32] *** nickthief76430 is now known as mihi_backup +[22:32] <mihi> oops... +[22:32] <jrand0m> I was just reading some of the upcoming HotNets2 papers ((Link: http://nms.lcs.mit.edu/HotNets-II/program.html)http://nms.lcs.mit.edu/HotNets-II/program.html) and got inspired for some QoS over i2p mechanisms +[22:33] <Ophite1> would a bulk/low-latency bit compromise anonymity slightly (intersection attack?) by allowing traffic linkage? well, even if it were sometimes flips? +[22:33] <Ophite1> ah, well that might work better of course =) +[22:33] <Ophite1> Don't worry about local plausible denability. +[22:33] <jrand0m> right, i2p assumes the local machine is trusted +[22:33] *** Signoff: dm (Ping timeout) +[22:33] <Ophite1> That is a problem to be solved by Rubberhose/Marutukku and Thermite, not I2P. +[22:34] <jrand0m> exactly. (otherwise, the software is compromised and it doesn't matter what we do) +[22:34] * TC hopes his local machine is trusted +[22:34] <jrand0m> heh +[22:34] <Ophite1> TC: easy way to find out; make death threats against bush and see if SS agents turn up at your door ;-) +[22:34] <jrand0m> lol +[22:34] <TC> done and done +[22:34] *** Signoff: tonious (Ping timeout) +[22:34] <jrand0m> hah! +[22:35] * jrand0m watches my squid proxy get taken down by the fbi +[22:35] <TC> its a trap! +[22:35] <jrand0m> get an axe! +[22:35] <jrand0m> :) +[22:35] <TC> anybody play uplink? +[22:35] <Ophite1> completed it. cracked it. released it. +[22:35] <Ophite1> trained it too ;) +[22:36] * jrand0m takes that as a "yes" +[22:36] *** dm (~as@anon.iip) has joined channel #iip-dev +[22:37] <Ophite1> there may be some dos possibilities in caching, in memory stuff... +[22:37] <jrand0m> ok, so thats what I'm thinking with idn/kademlia. get idn implemented and working over the 0.2. code, smash it in a bit, then implement 0.3 with that kademlia implementation +[22:37] <jrand0m> oh certainly. the todo list has 'sync pending and large messages to disk' :) +[22:37] <dm> shouldn't IDN be implemented after I2P is tested and mature? +[22:38] <jrand0m> thats one of the problems we ran into testing a large file of TC's eepsite +[22:38] <Ophite1> dm: not given as it's a testbed for the fancy db. +[22:38] <jrand0m> dm> I was thinking that too, but I need to implement the kademlia code to get 0.3 ready. basically the kademlia code IS 0.3 +[22:38] <Ophite1> I do like the hybrid dht nature such a network would provide though. +[22:39] <dm> aha... +[22:39] <jrand0m> but if no one wants to toss a normal UI onto it until i2p 1.0, that might be a good idea as well +[22:39] <Ophite1> dht node discovery + ngr-like routing = scalability capable of handling critical mass +[22:39] <dm> what happened to that original milestone list. secure-->anonymous-->not harvestable, etc... +[22:39] <Ophite1> jrand0m: I will refrain from advertising it to pirates until it's ready. that enough? +[22:39] <jrand0m> well, minus the ngr-like routing :) we tunnel :) +[22:39] <TC> as long as we keep the cli +[22:39] <dm> ah scalable was one of the items in that chain. +[22:39] <jrand0m> dm> 0.3 is necessary for scalable. which is before not harvestable +[22:39] <jrand0m> thanks Ophite1 :) +[22:40] <jrand0m> definitely TC. I'll need the cli to test it +[22:40] <Ophite1> scalability of the actual anonymous stuff is directly related to choices made in the routing for the tunnels, and that's a router implementation thing? +[22:40] <jrand0m> (and, c'mon, we'll probably do software distribution / releases with idn) +[22:40] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev +[22:40] <dm> alrighty... sounds okay then. +[22:40] <jrand0m> absolutely ophite. +[22:40] <Ophite1> suggestion: maximum message size? +[22:40] <jrand0m> thats the Hard problem +[22:41] <jrand0m> max message size is currently insanely large (4g) but I'm thinking of trimming it to 64k or 128k +[22:41] <jrand0m> but I don't want to resort to that yet +[22:41] * Ophite1 goes digging in notes +[22:41] <Ophite1> BitTorrent/Scone scalability notes indicate 512K. +[22:42] <jrand0m> heh ok cool. (any refs I can dig into?) +[22:42] <Ophite1> but, think of it like tcp window size. +[22:42] <jrand0m> right +[22:42] <Ophite1> not for scone, sorry - friend's research project. +[22:42] <jrand0m> coo', no worry +[22:42] *** Signoff: mihi_backup (Ping timeout) +[22:42] <Ophite1> fwiw, your kademlia is about as good as his though :) +[22:42] <jrand0m> hehe +[22:42] <jrand0m> (well, I haven't implemented it yet ;) +[22:42] <Ophite1> uh, hers I mean :/ +[22:42] <jrand0m> oh wikked +[22:43] <dm> boner.. +[22:43] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev +[22:43] <jrand0m> heh +[22:43] <jrand0m> so, thats 2) kademlia, 0.3, and idn +[22:43] <Ophite1> she named her toys after puddings. custard, crumble (Waste-like), strudel.. her bittorrent-a-like was the fastest pudding in the world - 'scone ;) +[22:43] <jrand0m> haha +[22:45] <Ophite1> she's a math. +[22:45] <jrand0m> even better +[22:45] <jrand0m> there's a lot of stats gathering / analysis that will be coming up for advanced peer selection +[22:45] <Ophite1> but I'll see if I can bounce stuff past her. scalability from i2np 0.9 was from her - she likes it. +[22:45] <jrand0m> (unfortunately we can't cheat like mnet, mixminion, and tor) +[22:46] <jrand0m> great to hear +[22:46] <Ophite1> one comment - dsa? +[22:46] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev +[22:46] <Ophite1> dsa 1024 bit, as in SHA-1? +[22:46] <jrand0m> yea +[22:47] <Ophite1> 'spose it is tried and tested. +[22:47] <Ophite1> also small. +[22:47] <jrand0m> right. but I'm not 100% tied to our particular crypto impls +[22:47] <Ophite1> anyway. to roadmap. +[22:47] <TC> haha, lets name a windows version 'Microsoft Darknet (r)' +[22:47] <jrand0m> heh tc +[22:48] <jrand0m> ok, 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? +[22:48] <jrand0m> because of all the bugs I've been running into wrt the broadcast db, I want to escalate the 0.3 (kademlia db) release +[22:48] <TC> its nice not being limmited by trademarks like a normal open source project +[22:49] *** tonious (~Flag@anon.iip) has joined channel #iip-dev +[22:49] <jrand0m> 0.2.3 is restricted routes / trusted peers, and probably not a hard feature requirement that anyone here has. it can be shuffled out to 0.4 without problem, I think +[22:50] <jrand0m> 0.2.2 is tunnel mods, but I think a lot of the pressure to get that implemented will be eased with the 0.2.1.1 release (which tests and rebuilds tunnels as necessary, rather than waiting 10 minutes) +[22:50] <Ophite1> trusted peers is an area that needs some revision imho. +[22:50] <jrand0m> agreed. +[22:50] *** dm_backup (~as@anon.iip) has joined channel #iip-dev +[22:50] <Ophite1> only area that doesn't give me warm fuzzies. +[22:50] <Ophite1> though that may just be the word "trusted". :) +[22:50] <jrand0m> basically my current thoughts are to publish tunnels to routers +[22:50] <jrand0m> heh +[22:51] <jrand0m> (if we publish tunnels to routers, we can get away with untrusted gateways, which drops the 'trusted' from trusted peers) +[22:51] *** Signoff: dm (Ping timeout) +[22:51] *** dm_backup is now known as dm +[22:51] <Ophite1> need to analyse anonymity implications of that. +[22:51] <jrand0m> but trusted peers is inherently necessary in a militant grade anon system, where /all/ nodes you can contact are considered attackers. +[22:52] <Ophite1> don't think that is truly possible... +[22:52] <jrand0m> certainly. yet another reason it should get 0.4 +[22:52] <jrand0m> Ophite1> trusted nodes with timed / triggered self destruct. +[22:52] <jrand0m> set up a patsy, route through it, kill it +[22:52] <jrand0m> exactly, if patsies delete their logs after N hours / N bytes / N messages +[22:52] <Ophite1> I mean if you want me to release a worm that sets up a couple of million... +[22:53] <Ophite1> logs? what logs? +[22:53] <jrand0m> :) +[22:53] <jrand0m> ok, format the disks ;) +[22:53] * Ophite1 wrote kernel-level stealth trojan +[22:53] <jrand0m> nice +[22:53] * dm wrote kernel level outlook calendar plugin. +[22:53] <Ophite1> ...when I was 19 :) +[22:53] <Ophite1> still works. :) +[22:54] <Ophite1> not going to include it in this though, don't worry, or, uh, check my code, which would probably be a Good Thing To Do anyway ;) +[22:54] <dm> when I was 12. +[22:54] <jrand0m> I don't think i2p will want /that/ large distribution until after 1.0 is stable and heavily peer reviewed +[22:54] <jrand0m> heh Ophite1 +[22:54] <jrand0m> heh dm +[22:54] <Ophite1> frankly, think that is a fluff feature. +[22:54] <jrand0m> perhaps. +[22:55] <jrand0m> restricted routes is a necessity though +[22:55] <jrand0m> its basic functionality for people behind firewalls +[22:55] <jrand0m> (very restrictive firewalls) +[22:55] <Ophite1> hello, transports. +[22:55] <Ophite1> we'll get to that. +[22:55] <Ophite1> or is now the appropriate time to discuss them? +[22:55] <jrand0m> sure, lets dig in :) +[22:56] <jrand0m> we've already run into a problem with an unreachable peer that could be solved with restricted routes +[22:56] *** tusko has left #iip-dev +[22:56] <jrand0m> even though it was due to misconfiguration, it could be more common +[22:57] <Ophite1> Also: given two cooperating peers behind inbound-filtering firewalls that drop bad packets, and one cooperating peer which is not behind a firewall and can send packets with forged IP source addresses to both of the other peers... +[22:57] <Ophite1> You can establish a TCP connection between the two firewalled peers that both firewalls think is outbound. +[22:57] <jrand0m> definitely +[22:57] <dm> forged IP addresses?!? +[22:58] <Ophite1> believe me, firewalls are a VERY common problem. +[22:58] <Ophite1> sometimes they are user-controlled but the user is a doofus. that can be handled with the installer handling the firewall :) +[22:58] <dm> I2P is gonna use IP spoofing? :) +[22:58] <jrand0m> definitely. if i2p can't operate behind firewalls / NATs / proxies, there's no reason to continue. +[22:59] <Ophite1> sometimes they are actively hostile, corporate or educational gateways seeking to deliberately mess up everything. It's got to traverse those, and traverse them cleanly. +[22:59] <jrand0m> dm> transport options +[22:59] <jrand0m> absolutely Ophite1 +[22:59] <Ophite1> dm: I have a working implementation - in the Direct Connect protocol. +[22:59] <jrand0m> i2p wants to be the battleground for that code. +[22:59] <Ophite1> dm: If *that* can handle it, i2p can. +[22:59] *** Signoff: tonious (Ping timeout) +[23:00] <Ophite1> I suggest leaving it turned off by default though. Only a very few want it turned on, and it would be nice if they can advertise which they are so requests can be routed to them. +[23:00] <dm> you can't spoof IPs without native code can you? +[23:00] <Ophite1> the advantage is that they don't have to route *through*, just help the setup. +[23:00] <Ophite1> = massive speed boost. +[23:01] <jrand0m> definitely Ophite1, thats what the RouterInfo.routerAddress[] structure is for +[23:01] <Ophite1> dm: yeah, like this isn't going to be rewritten? +[23:01] *** tonious (~Flag@anon.iip) has joined channel #iip-dev +[23:01] <dm> okay, just checking... +[23:01] <jrand0m> right dm, I have no qualms whatsoever with including native code in i2p +[23:01] <Ophite1> I would like to state that I don't think java is a permanent solution. +[23:01] <Ophite1> And that I regard java router as testbed/prototype. +[23:01] <jrand0m> thats fine. if it gets us to 1.0, works out the protocol, etc, good enough. +[23:02] <Ophite1> ...and hope it doesn't get stuck there as freenet has ;) +[23:02] <dm> IPAddress.Spoof(192.168.32.1); +[23:02] *** alient (alient@anon.iip) has joined channel #iip-dev +[23:02] <jrand0m> lol dm +[23:02] <dm> import IPSpoofing; +[23:02] <Ophite1> mmm... raw sockets in java ;) +[23:02] <jrand0m> fcntl / ioctl in java... mmMMmm +[23:02] <mihi> hmm, raw sockets require root on unix, don't they? +[23:02] <dm> women with large breasts lickig my penis.. mmMMmmm +[23:02] <jrand0m> so we include a rootkit +[23:03] <jrand0m> ;) +[23:03] <Ophite1> jrand0m: got it covered =) +[23:03] <jrand0m> heh +[23:03] <Ophite1> besides as I said; only a few need it. +[23:03] <jrand0m> right +[23:04] <jrand0m> and only for legitimate reasons, of course. +[23:04] <Ophite1> on my dc hub, only one (bot) had the capability, and the hub told it when passives wanted to connect to passives. +[23:04] <Ophite1> caused a bit of amazement that did. +[23:04] <jrand0m> hehe +[23:04] <Ophite1> also got the bot's host shut down, hence my suggestion to perhaps turn it off by default :) +[23:04] <jrand0m> thats definitely a good feature to have avail +[23:04] <jrand0m> lol +[23:05] *** Signoff: nickthief54450 (Excess Flood) +[23:05] <jrand0m> ok, so with restricted routes pushed to 0.4, we have a month or so to continue the debate as to whether the functionality is necessary +[23:06] <jrand0m> any other thoughts / things that should be in the roadmap that aren't, things that are in the wrong place, etc? +[23:06] <Ophite1> I say push it to 0.4 definitely. It will cause firewall issues at the moment but we are still in testing... +[23:06] <Ophite1> ...someone that can't open a firewall port probably shouldn't be trying it yet. +[23:06] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev +[23:06] <jrand0m> right. and even with firewalls, PHTTP lets them through. +[23:07] <Ophite1> though need to test phttp against hostile proxies. +[23:07] * jrand0m is behind a firewall I don't control and I participate fully in i2p +[23:07] <dm> hax0r +[23:07] <jrand0m> well, yes, hostile proxies can fake confirm, but its all signed, so the message can't go to the wrong place / etc +[23:08] <jrand0m> but the phttp relay and transport does have a lot of features needed +[23:08] <Ophite1> in particular, to examine the future possibilities application level routers might have at detecting/fucking up the protocol. +[23:08] <jrand0m> hm? +[23:08] <Ophite1> have some experience with firewall tunnelling though. +[23:08] <Ophite1> might want to include a GET fallback. +[23:09] <jrand0m> hmm. GET goes into logs. but perhaps as a fallback +[23:09] <jrand0m> (POST can be to /index.html) +[23:09] <Ophite1> jrand0m: but it's all signed/encrypted if noderefs are cool...? +[23:10] <Ophite1> unless the proxy becomes an active attacker too, that's going to be quite hard for it. +[23:10] <jrand0m> all messages are encrypted to the destination router, and the designation as to what phttp relay to go through is signed in the routerInfo +[23:10] <jrand0m> right. phttp proxy as is certainly isn't strong enough to go against an active attacker +[23:11] *** Signoff: grimps (Leaving) +[23:12] <jrand0m> I think it'd be great if people posted some alternate transport ideas to the wiki :) +[23:12] <jrand0m> ok, 4) app status [ppp2p, i2ptunnel, im, ns, squid] +[23:12] <jrand0m> damn, tusko left +[23:12] <jrand0m> tusko wrote a python script (ppp2p) to let people run ppp over i2p via i2ptunnel +[23:13] <Ophite1> Told you someone would do that :) +[23:13] <dm> ppp over i2p? +[23:13] <jrand0m> I haven't looked at it, but last I heard he was running a vpn over i2p with 5s ping times +[23:13] <jrand0m> heh yeah +[23:13] <Ophite1> dm: of course. +[23:13] <dm> when could you use that? +[23:13] <dm> could/would +[23:13] <jrand0m> dm> anonymous outproxy +[23:13] <Ophite1> dm: anonymous ANYTHING. +[23:13] <jrand0m> to, say, run a kazaa node anonymously, or whatever +[23:13] * Ophite1 points out that anyone running an outbound i2p->ppp link is insane and will probably be blacklisted/hunted down +[23:13] <dm> ah, I understand. +[23:13] <jrand0m> definitely Ophite1 +[23:14] <jrand0m> so right now, its only for trusted peers. +[23:14] <Ophite1> see also: the dresden JAP cascade... :) +[23:14] <jrand0m> which, well, doesnt really make sense for anonymity... +[23:14] <jrand0m> heh +[23:14] <Ophite1> also most of the stuff going out of their node will be unencrypted... +[23:14] * jrand0m thinks about ike over ppp over i2p +[23:15] * jrand0m watches my head explode +[23:15] *** fiaga (~po@anon.iip) has joined channel #iip-dev +[23:15] <Ophite1> jrand0m: why not i2p over ppp over i2p? +[23:15] <jrand0m> definitely doable. aint recursion fun? +[23:15] <soros> i2p over i2p :-o +[23:15] <jrand0m> or i2p over ppp over i2p over i2p over freenet over kazaa +[23:15] <Ophite1> now that's just silly. Freenet wouldn't possibly work ;) +[23:16] <godmode0> over slow connect :) +[23:16] <jrand0m> heh it'd have latency issues, certainly :) +[23:16] <mihi> ... over an icmp tunnel over ... +[23:16] <Ophite1> ooh yes, loki :) +[23:16] <Ophite1> 0ldsk00l :) +[23:17] <Ophite1> I2P addresses, being the public keys, are ... rather long. +[23:17] <jrand0m> yes. +[23:17] <jrand0m> actually, since we're on agenda item 4: ns +[23:17] <Ophite1> As in an I2P www url being actually too long to paste into any sane place (>512 chars?!!) +[23:17] <mihi> co promised to write a naming service... +[23:17] <jrand0m> yeah. +[23:17] <jrand0m> I think with idn implemented, it would be very easy for someone to adapt the kademlia code into a distributed dns +[23:17] <mihi> Ophite1: post them to the eepsite forum. +[23:18] <Ophite1> trouble with namespace as I can figure it out is that there has to be either some degree of central control OR you have to allow collisions. +[23:18] *** Signoff: fiaga (Ping timeout) +[23:18] <jrand0m> (just toss on a CA or WoT CAs, and voila. (Link: www.mihi.i2p)www.mihi.i2p) +[23:18] <jrand0m> not necessarily. +[23:18] <Ophite1> please enlighten me with your better ideas then. +[23:18] <jrand0m> Ophite1> check out co/wiht's specs on the iip-dev list. +[23:19] <Ophite1> best I could come up with is root key creates signed namespaces. dnssec stylee. +[23:19] <jrand0m> he doesn't go the full route with a dht, but he manages groups +[23:19] <jrand0m> just like how we do now - we /all/ can choose who our root dns servers are. +[23:19] <jrand0m> in the same vein, we /all/ should be able to choose who our CA (or CA WoT) is +[23:20] <jrand0m> so I guess technically there /could/ be collisions, but only once there are multiple CA groups that don't interact +[23:20] * Ophite1 notes that is unlikely +[23:20] <jrand0m> agreed +[23:20] <Ophite1> you either trust the root CA or you don't. +[23:20] <jrand0m> and if you don't trust the root, you create your own +[23:21] <jrand0m> (or find another) +[23:21] <Ophite1> and if you don't trust the root CA it's for a reason, a reason that will rapidly get around. +[23:21] <jrand0m> exactly +[23:21] <jrand0m> especially when there's anonymous publishing :) +[23:21] <Ophite1> being as CA's only real purpose is to insure anti-collision - like Trent... +[23:21] <jrand0m> right +[23:22] <Ophite1> about the only thing that would cause lack of trust in CA is (1) key leakage or (2) refusal to register something that isn't already registered. +[23:22] * jrand0m notes verisign's "trustworthiness" +[23:23] * Ophite1 notes that Verisign purports to verify the identity of the certificate holder - one of the properties that an I2P namespace is in fact guaranteed NOT to do +[23:23] <jrand0m> self signed certs+++ +[23:24] <Ophite1> also I'd point out that distributed systems - like Darknet, as I will call it from here on in until it sticks :) - built on top of i2p probably wouldn't use the namespace. +[23:24] <Ophite1> It's for servers, really. +[23:24] <jrand0m> heh +[23:24] <jrand0m> right +[23:24] <Ophite1> Servers don't scale. That problem will be in i2p as much as in IP. +[23:24] <Ophite1> so, I think that the usage in practice will actually be surprisingly limited. +[23:24] <jrand0m> the idn ("darknet") would keep references to destinations - the full 387 bits of their keys, not some pretty name +[23:24] <jrand0m> agreed. +[23:25] <jrand0m> except / until someone writes a distributed outproxy system +[23:25] <jrand0m> aka o-r / freedom over i2p +[23:25] <TC> how many diffrent keys can we have? +[23:25] * jrand0m looks forward to that day +[23:25] <jrand0m> tc> 2^2048 +[23:25] <Ophite1> jrand0m: at which point the root key signs them a namespace: .proxy.i2p +[23:26] <dm> This must be the most hypothetical/megalomaniac open source development meeting ever :) +[23:26] <jrand0m> aint subspaces grand :) +[23:26] <jrand0m> lol dm +[23:26] <jrand0m> hey, we're alowed to aim high, aint we? +[23:26] <dm> I'm sure most devl meetings are like: "So, do we put 3 bits for the mpeg-5 header or 4?" +[23:26] <Ophite1> jrand0m: oddly as it may seem, not every number works for elgamal ;-) +[23:26] <TC> dm, youve seen debian meetings right? +[23:26] <jrand0m> awww c'mon, 000000000000000000000000000 is a secure key +[23:26] * Ophite1 hands out Chocolate Digestives +[23:26] <dm> TC: no, what are the like? +[23:26] <Ophite1> jrand0m: ooh, identity. +[23:26] <TC> dm, i dont know, i was asking +[23:27] <jrand0m> ok. thecrypto isn't here either... anyone have im thoughts? +[23:27] <Ophite1> damn, I was about to ask about that. +[23:27] <Ophite1> quite an important app. +[23:27] <dm> Anyway, this type of meeting is more lurker-friendly, so I'm all for it. +[23:27] * dm is entertained. +[23:27] <jrand0m> heh +[23:27] <TC> where is co? +[23:27] <Ophite1> as many people will expect i2p to be iip's successor. +[23:28] <jrand0m> iip over i2p is fairly easy, if we don't want dcc +[23:28] <Ophite1> (I guess it could be, if we just run an iip irc server over i2p...) +[23:28] <jrand0m> iip over i2p with dcc requires a new app +[23:28] <jrand0m> exactly Ophite1 +[23:28] <jrand0m> 0 coding +[23:28] <TC> cant we just run irc over i2p? +[23:28] <Ophite1> I don't like that idea 'cause ... well, it doesn't give us anything we don't already have :) +[23:28] <jrand0m> but last I heard, thecrypto was doing some work on an IM app +[23:28] <jrand0m> certainly tc +[23:29] <jrand0m> right Ophite1, and it doesn't scale +[23:29] <jrand0m> (all the traffic gets funneled to the ircd) +[23:29] <Ophite1> Also the IRCd can spy on traffic. +[23:29] <TC> ah, goodpoint +[23:29] <jrand0m> (this would be when UserX should show up and discuss his ideas for iip2.0) +[23:29] <jrand0m> right Ophite1 +[23:29] <jrand0m> all the problems of the current iip +[23:29] <Ophite1> jrand0m: And absolutely nothing different. +[23:29] <jrand0m> more lag. +[23:30] <Ophite1> except it's in java. lovely. :) +[23:30] <jrand0m> heh +[23:30] <Ophite1> Now, shitloads of people have cut their undergraduate teeth trying and failing to build distributed chat applications. +[23:30] <jrand0m> ok, so someone should either help thecrypto out or push him along some more :) +[23:30] * Ophite1 points out IRC3 +[23:30] <jrand0m> yeah, its a perfect school project +[23:30] <Ophite1> ..and SILC... +[23:30] <Ophite1> ...and... +[23:31] <Ophite1> well about a gazillion others. +[23:31] <jrand0m> 'zactly +[23:31] <Ophite1> Literally all of these, I might add, are pre-DHT as far as I can tell. +[23:31] <jrand0m> yup +[23:31] <Ophite1> That's disappointing 'cause that's a freakishly useful structure. +[23:31] <jrand0m> a DHT for lookup / P3P, and then direct con for IM +[23:31] <jrand0m> group chat is harder though, but not too hard +[23:31] <Ophite1> well, direct in the i2p sense :) +[23:31] <jrand0m> heh right +[23:32] <Ophite1> what about darkmail/i2pmail? +[23:32] <soros> group sex too +[23:32] <dm> soros: agreed. +[23:32] <jrand0m> group sex isn't that hard soros ;) +[23:32] <jrand0m> lol +[23:32] <jrand0m> email over i2p is easy. someone just needs to run a pop server +[23:32] <jrand0m> or webmail +[23:32] <jrand0m> hahah +[23:33] <Ophite1> jrand0m: sure, as long as literally everyone is okay with bloody pgp :) +[23:33] * Ophite1 gets CKT nightmares again +[23:33] <jrand0m> oh, true. that'd expose the contents to hte server ;) +[23:33] <Ophite1> Also... spam. +[23:33] <jrand0m> yup +[23:33] <Ophite1> We have this thing called hashcash. +[23:33] <Ophite1> They sort of fit together, no? +[23:34] <jrand0m> ok, so yeah, someone should get working on an i2p specific email app :) +[23:34] <Ophite1> obviously that would work best as part of the im. +[23:34] <Ophite1> What, after all, is the distinction between irc and email? +[23:34] <jrand0m> true, like an IM VMB +[23:34] <Ophite1> Whether or not you can page up and see what you missed after you rejoin... +[23:34] <jrand0m> placed into the dht +[23:34] <jrand0m> good point +[23:35] * jrand0m wishes we had a team of a dozen coders +[23:35] <Ophite1> note, however, that mail requires storage, as it is offline communication. irc requires no storage, as it is online communication. +[23:35] <dm> also email has a lot more penis enlargement adverts. +[23:35] <Ophite1> jrand0m: ask around for funding. +[23:35] <Ophite1> dm: see above re: hashcash. +[23:35] <jrand0m> right, the P3P could contain pending messages +[23:36] <Ophite1> dm: A primitive that was not available to the bloke who hacked up email in a night. +[23:36] <Ophite1> (At least we won't have to use ! paths to specify the tunnel manually. heh. heh. heh.) +[23:36] * dm is gonna miss clear-text dead simple protocols. +[23:36] <jrand0m> jrandom%ophite!dm!mihi +[23:37] <Ophite1> no, this is i2p. Insert ~520 garbage characters between the bangs then you're closer ;) +[23:37] <jrand0m> haha +[23:37] <Ophite1> several of these things *are* sort of related. +[23:37] <jrand0m> true, 387 bytes base64 encoded... +[23:38] <Ophite1> or to put it another way, ELONGURL :) +[23:38] <jrand0m> heh +[23:38] <Ophite1> [does IE chop at 512?] +[23:38] <jrand0m> naw, works fine +[23:38] <Ophite1> you admit to using IE? +[23:38] <Ophite1> To browse anonymously?! +[23:38] <jrand0m> ;) +[23:38] * Ophite1 pulls out six of Liu De Yiu's best and waits =) +[23:38] * jrand0m uses ie for eppsites, moz for squiding +[23:39] <duck> what item are we now? +[23:39] <duck> 4? +[23:39] <jrand0m> yeah, ok ok +[23:39] <Ophite1> still 4 I think. +[23:39] <jrand0m> i2ptunnel. still kicks ass. +[23:39] <jrand0m> any thoughts? any comments mihi? +[23:40] <jrand0m> one thing I want to note wrt the squid outproxy is that I've updated the header filtering to ALLOW COOKIES and replace the user agent with something silly +[23:40] * mihi just waits for naming service... +[23:40] <jrand0m> mihi (or someone else)> it'd be really easy to bootstrap such a naming service with an /etc/hosts style i2p ns +[23:41] <mihi> btw: are there any other public dests except your squid and tc's eepsite? +[23:41] <jrand0m> i2pcvs.dest +[23:41] <jrand0m> (points at the i2p cvs pserver) +[23:41] <jrand0m> (but isn't always up) +[23:41] *** yodel (yodel@anon.iip) has joined channel #iip-dev +[23:41] <jrand0m> hola yodel +[23:41] <yodel> hela +[23:42] <jrand0m> ok, I think thats it for 4) apps +[23:42] <jrand0m> 5) comments / questions / etc +[23:42] <mihi> gui installer? +[23:42] <TC> hi yodel +[23:43] <yodel> I have to start experimenting putting the xml-rpc over i2p +[23:43] <yodel> should work with httptunnel +[23:43] <jrand0m> good question mihi. last I heard MrEcho had some of it working +[23:43] <jrand0m> awesome yodel +[23:43] <jrand0m> definitely. +[23:43] <jrand0m> how large are the streams? +[23:43] <jrand0m> (aka how chatty is the protocol?) +[23:44] * Ophite1 plans to try BitTorrent over I2P as a stress test +[23:44] <yodel> xml over http +[23:44] <yodel> the ssl layer wont be needed with i2p +[23:44] <Ophite1> so, uh, very chatty? :) +[23:44] <jrand0m> ah cool, large POST or large replies? +[23:44] <jrand0m> (or just small and small?) +[23:45] <jrand0m> damn you Ophite1 :) +[23:45] <yodel> equal sizes +[23:45] <yodel> does httptunnel support gzipped http? +[23:45] <jrand0m> but doesn't bt use IP addresses? +[23:45] <jrand0m> hmm, httptunnel doesn't have any inherent compression, its just a bitstream +[23:45] <TC> hmm, package i2p+ppp\vpn+gui as a security solution for wireless windows shares +[23:45] <yodel> so should work... +[23:45] <godmode0> jrand0m> you test i2p in nntp news server ? +[23:45] <jrand0m> yup yodel +[23:45] <yodel> 500-1000 byte send, same for reply +[23:46] <jrand0m> hmm I haven't tested that yet godmode0 +[23:46] <yodel> much less when zipped +[23:46] <jrand0m> oh cool yodel, that'll work without any problem +[23:46] <yodel> what is the latency for a single msg/package/whatever? +[23:46] <jrand0m> 2-5s, sometimes up to 10s +[23:46] <jrand0m> (currently) +[23:46] <Ophite1> not bad for a pre-dht :) +[23:46] <yodel> so 20s roundtime? +[23:47] <jrand0m> I usually pull up a web page in 5-10s +[23:47] <yodel> ah +[23:47] <yodel> goo +[23:47] <yodel> +d +[23:48] <jrand0m> damn, we're coming up to the 2 hour mark. anyone have any other questions / thoughts? +[23:48] <Ophite1> Pie is good. +[23:48] <duck> jrand0m: why do you drink cheap local beer? +[23:48] <Ophite1> Orgy and pie is better. +[23:48] <jrand0m> rofl duck +[23:49] <Ophite1> duck: It's better than Tesco Value Lager? +[23:49] * Ophite1 spits from reflex +[23:49] <jrand0m> heh +[23:49] * duck is concerned about jrand0m's health +[23:49] <jrand0m> you're concerned about my cheap beer habits but not my good whiskey habits? +[23:50] * Ophite1 reminds about the single malt on Cary Sherman's head +[23:50] <duck> do you eat well? +[23:50] <godmode0> corona +[23:50] <duck> do you do your daily exercises? +[23:50] <jrand0m> well, i'm one of those veggies +[23:50] <Ophite1> Isn't that a personal question, duck? +[23:50] <jrand0m> does typing count? +[23:50] <duck> you did drink that much already? +[23:50] <duck> that you became a veggie +[23:50] <jrand0m> heh +[23:50] <Ophite1> cheap beer will do that. +[23:51] <duck> Ophite1: jrand0m's health should concern us all, since it is essential for I2P +[23:51] *** Signoff: mihi_backup (mihi hands jrand0m the *BAF*er) +[23:51] <jrand0m> heh ok ok mihi +[23:51] * jrand0m winds up +[23:51] * jrand0m *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/65.rst b/i2p2www/meetings/logs/65.rst new file mode 100644 index 00000000..94be875f --- /dev/null +++ b/i2p2www/meetings/logs/65.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 18, 2003 @ 21:02 UTC +============================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/66.log b/i2p2www/meetings/logs/66.log new file mode 100644 index 00000000..7defbf8f --- /dev/null +++ b/i2p2www/meetings/logs/66.log @@ -0,0 +1,471 @@ +[22:04] <jrand0m> agenda: +[22:04] <jrand0m> 0) welcome +[22:04] <jrand0m> 1) status +[22:04] <jrand0m> 2) transport futures +[22:05] <jrand0m> 3) peer stats for selection +[22:05] <jrand0m> 4) apps +[22:05] <jrand0m> 5) ...? +[22:05] <jrand0m> 0) +[22:05] <jrand0m> hi. +[22:05] <jrand0m> 66 is it? +[22:05] <duck> 7) what brand of whiskey does jrand0m drink? +[22:06] <jrand0m> bushmills, glenlivit +[22:06] <jrand0m> (for whiskey and whisky, respectively) +[22:06] <TC> yey, i made the meating +[22:06] <jrand0m> woot +[22:06] <jrand0m> ok, 1) status +[22:06] <jrand0m> the kademlia stuff is coming along very well. +[22:07] <jrand0m> I've build a little simulator that runs a network of five nodes and puts them through the basic tests +[22:07] <jrand0m> also the idn stuff is implemented with some tests as well +[22:08] <jrand0m> the last two days or so have been focused on making sure the kademlia code works for both idn and for the i2p netdb, which has caused a bunch of changes +[22:09] <jrand0m> actually, the big change is that I'm forcing myself to be practical and make the kademlia code work first with the netDb and /then/ think about the idn stuff. +[22:10] <jrand0m> idn right now is kind of functional, except for inter-node comm (which will be replaced with comm over i2p, of course ;) +[22:10] <TC> idn is the stuff for the distributed storage? +[22:10] <jrand0m> roadmap has been updated as well - http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap +[22:10] <jrand0m> yes +[22:10] <jrand0m> idn = Invisible Distribution Network +[22:10] <jrand0m> (free open source anonymous akamai, basically) +[22:11] <TC> is there a non anonymous public akamai implemintation i could play with? +[22:11] *** leenookx (~leenookx@anon.iip) has joined channel #iip-dev +[22:12] <jrand0m> mnet is probably up that alley +[22:12] *** Signoff: nickthief60934 (Excess Flood) +[22:12] <jrand0m> before I jump back into the router completely, I'm planning on leaving the idn code in a state that /hopefully/ someone would be able to jump in and make that into a usable app. +[22:13] *** dm (~sd@anon.iip) has joined channel #iip-dev +[22:14] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev +[22:14] <jrand0m> if you see the roadmap, kademlia has been pushed into the 0.2.2 release. in addition, there are also two big outstanding things that I hope to have in there, fixing a pair of bugs that do annoying things +[22:14] <TC> would it be posible do image grabs do idn from an i2ptunnel eepsite? +[22:15] <jrand0m> hmm? +[22:15] <jrand0m> oh, like <img src="idn:blah">? +[22:15] <TC> i was just thinking of bandwidth saving, yes +[22:15] <Ophite1> protocol would be the obvious way to go, yes. +[22:16] <jrand0m> hmm Ophite1? +[22:17] <jrand0m> (sorry, I'm sick again so might not be quite on top of my game today) +[22:17] <dm> how many LOC have you written jr? +[22:17] <TC> Ophite1, could i2p tunnel be modified to redirect? +[22:18] <TC> or could the browser do it on its own somehow? +[22:18] <jrand0m> dm> "find . -exec grep \\\; {} \; | wc -l" currently puts the sdk ~8kloc, the router ~11kloc +[22:18] <dm> okay thanks. +[22:19] <jrand0m> idn would want to support receiving requests from browsers. +[22:19] <Ophite1> would mean integrating idn into i2ptunnel. very ugly. +[22:19] <jrand0m> currently idn has a so-god-damn-easy api. +[22:19] <jrand0m> the api is the file system. +[22:19] <jrand0m> aka: +[22:19] <jrand0m> command=get +[22:19] <jrand0m> key=zGb1tPM6ARNRTWZLCWK4XXco2Ngk8ccx-ciDUCom~9U +[22:19] <jrand0m> saveAs=testGetOutput.txt +[22:20] <jrand0m> place that in a file in a directory, and voila. +[22:20] <jrand0m> (that was the easiest possible for me to implement and test with. certainly better ones can be found and made) +[22:21] <jrand0m> ok, so, yeah. thats the status. I'm hoping for a 0.2.2 release by this time next week, at least. +[22:22] <jrand0m> that'll include the first integration of the kademlia stuff, tunnel fixes, and i2cp updates. +[22:23] <jrand0m> ok, 2) transport futures +[22:23] <jrand0m> I don't like our tcp transport. and our udp transport is disabled. and our phttp transport is tweaky. +[22:23] * jrand0m would like to see the tcp transport replaced with tls / ssl / some-other-standard +[22:24] <Ophite1> link-level encryption is a requirement? +[22:24] <jrand0m> absolutely. +[22:25] <Ophite1> tls is _hell_ though. ask openssl. +[22:25] <tonious> ssh? +[22:25] <Ophite1> that, too. +[22:25] <jrand0m> yeah, I followed the nasty discussions on the cryptography list last month, with interest. +[22:25] <jrand0m> ssh is definitely a possibility. +[22:26] <jrand0m> safe, too, since we already essentially have the certificates (in the RouterInfo.publicKey) +[22:26] <Ophite1> but we're in java. we'd have to code it ourselves? :/ +[22:26] <jrand0m> naw, there are ssl, tls, and ssh java libs +[22:26] *** Signoff: nickthief60934 (Ping timeout) +[22:26] <tonious> There's already at least one java ssh client. Dunno about servers. +[22:26] <Ophite1> re: security of such libs, given numerous high profile holes in openssl, openssh, et al? +[22:27] <jrand0m> Ophite1> most likely better than custom built code. +[22:27] <jrand0m> not that I have any reason to think there are exploits in the tcp transport as written. +[22:27] <jrand0m> but it has not been reviewed. +[22:28] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev +[22:28] <jrand0m> in any case, updating the transports isn't really on deck until january (after the 0.3 release goes out) +[22:28] <jrand0m> but if anyone wants to look into it and do some research, that'd be great +[22:29] <TC> how many devs do we have activly coding? +[22:29] <dm> 1! :) +[22:29] <jrand0m> you can see who commits via (Link: http://i2p.dnsalias.net/pipermail/i2p-cvs/2003-November/thread.html)http://i2p.dnsalias.net/pipermail/i2p-cvs/2003-November/thread.html +[22:29] <tonious> But he's got the strength of ten men.... +[22:30] <jrand0m> mihi has been cleaning up some of my messes, thankfully :) +[22:30] <dm> haha, it's all jrandom :) +[22:30] <dm> nice way of saying "just me" +[22:31] <dm> I noticed that about mihi, when he got involved in frazaa, he just showed up one day and started cleaning up my (horrid) java. It was quite entertaining. +[22:31] <jrand0m> heh +[22:31] <Ophite1> people like that are very, very useful :) +[22:32] <jrand0m> quite +[22:32] <dm> "who's writing all these catch statements who do nothing ;)" -mihi +[22:32] <jrand0m> d'oooh +[22:33] <Ophite1> it's cause of reminders like that the code won't get as bad as freenet (we hope?) :) +[22:33] <jrand0m> if in 5 years any of the current i2p code is still in use, I'll be shocked. +[22:34] <jrand0m> (it had better be ported into finely tuned ASM code by then!) +[22:34] * Ophite1 makes his "java implementation is just a prototype" speech +[22:34] <dm> well, if you're still working on it 4 years from now, I'll guarantee that It'll be in use 5 years from now :) +[22:34] <TC> heh, comment it out and leave it in place +[22:35] <dm> is there a link to see the source on the web? not just the changes. +[22:35] <jrand0m> yes dm, http://i2p.dnsalias.net/ +[22:35] <dm> nm, found it. +[22:35] <jrand0m> :) +[22:35] <jrand0m> ok, 4) peer stats for selection +[22:36] <jrand0m> calling this a nebulus topic is one hell of an understatement. +[22:36] <jrand0m> doctoral theses could be written (and some have been) on how to choose what peers to use in an untrusted environment. +[22:36] <dm> public interface Job +[22:36] <dm> oops, meeting. Sorry didn't realize. +[22:37] <jrand0m> the good part is that half of our peer selection is already taken care of - the selection of peers to find other peers. +[22:37] <jrand0m> (thats the kademlia stuff) +[22:38] <jrand0m> the part thats left is the selection of peers to participate in tunnels, to route garlics, and to bounce replies through +[22:38] *** Signoff: dm (EOF From client) +[22:38] *** Signoff: TC (EOF From client) +[22:38] *** Signoff: leenookx (EOF From client) +[22:38] <jrand0m> what I'm thinking for 0.3 is just going to be a simple history of each peer, tested periodically +[22:39] *** TC (~TC@anon.iip) has joined channel #iip-dev +[22:39] *** leenookx (~leenookx@anon.iip) has joined channel #iip-dev +[22:39] <jrand0m> stats revolving around latency and uptime +[22:39] *** Signoff: soros (Client exiting) +[22:39] <Ophite1> suggest you be wary of including accurate information about bandwidth usage and latency in that stats. +[22:40] <Ophite1> as per my drunken questions. +[22:40] <Ophite1> perhaps a more indirect route, but it's an area that needs very careful, well considered attention. +[22:40] <jrand0m> hmm, with the intent of keeping the accurate info unknown, or to defeat predictabilities? +[22:40] <jrand0m> right +[22:41] <jrand0m> this discussion is for a release that won't go out until at least jan 1 +[22:42] * jrand0m understands and agrees that we want to avoid the predictabilities +[22:42] <jrand0m> but I think we want to gather and use as accurate info as we can, /then/ adjust for entropy +[22:42] <Ophite1> mere entropy alone may not be enough. +[22:43] <Ophite1> but, I need more research on this :/ +[22:43] <jrand0m> true - randomly deciding to garlic route a message rather than tunnel route it, or to use a sequence of tunnels instead of one directly, etc +[22:44] <jrand0m> no rush, just wanted to plant the subject in the minds of those out there :) +[22:44] <jrand0m> ok, 4) apps +[22:45] <Ophite1> been troubling me for a week or more; though, I'm happy to announce I've run into a brick wall so far :) +[22:45] <jrand0m> w00t :) +[22:45] <Ophite1> inclusion of accurate or accurate+some%entropy statistics may make some attacks work though. +[22:46] <TC> oh, before apps i have a question +[22:46] <jrand0m> well, its always easy enough to simply discard accurate info as necessary +[22:46] *** Signoff: nickthief60934 (Excess Flood) +[22:46] <jrand0m> sure tc, whats up? +[22:46] <jrand0m> (stats will also (hopefully) make it easier to debug the network's operation while in development) +[22:46] <TC> when are manditory minium hop counts (or something like it) going to start?> +[22:47] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev +[22:47] <jrand0m> right now the default minimum tunnel length is one non-local hop +[22:47] *** dm (~sd@anon.iip) has joined channel #iip-dev +[22:47] * TC didnt know that +[22:48] <Ophite1> which is okay as long as the non-local hop doesn't KNOW it's the only non-local hop. +[22:48] <jrand0m> that will be up'ed to 2-4 once things are more reliable +[22:48] <jrand0m> right Ophite1 +[22:48] <Ophite1> still one better than a gnunet shortcut, so it's cool :) +[22:48] <TC> oh, and how do speed improvements look? +[22:48] * jrand0m is basing that 2-4 # on o-r comments +[22:49] <Ophite1> temporary stats for network testing are okay by me, and very useful, but please bear in mind they may be a dangerous feature for production anonymity. +[22:49] <jrand0m> hmm, speed improvements will come through more reliable and faster peer selections, which is the 0.3 release +[22:49] <dm> jeez, I forgot how jr's code looks like it was written by a robot. +[22:49] <dm> Hmmm, that would explain a lot. +[22:50] <Ophite1> and through more scalable routing, which is next weeks' :) +[22:50] <jrand0m> heh sorry dm, I'll try to be more inconsistent ;) +[22:50] <Ophite1> (did I just mean discovery?) +[22:50] <jrand0m> right, its discovery, not routing, really. +[22:51] <jrand0m> i2p is scale free for normal comm. +[22:51] <jrand0m> (and o(log(n)) for discovery) +[22:51] <TC> i think your average ai who lives on the net would be pro i2p, what do you think dm? +[22:52] <dm> I think the average method size in this code is the smallest I've ever seen is what I think. +[22:53] <Ophite1> dm: clean. very good for a proto :) +[22:53] <dm> Do you comment as you go or do you go back and put those descriptions? +[22:53] <jrand0m> I comment when I get confused +[22:54] <jrand0m> (I really can't wait until collections are typesafe) +[22:54] <jrand0m> but, yeah, 4) apps :) +[22:54] <jrand0m> (unless anyone else has router / network questions?) +[22:55] <TC> pnope +[22:55] <jrand0m> ok, wiht isn't here, anyone else have any naming service thoughts / comments (mrecho?) +[22:55] <TC> a distributed naming server? +[22:56] <dm> is wiht ever here? +[22:56] <tonious> It could probably just sit on top of IDN. +[22:56] <jrand0m> yeah, I'd really love to see the naming service be a dht (perhaps reusing the idn / kademlia code) containing CA signed entries +[22:56] <TC> did co die? +[22:56] <jrand0m> exactly tonious +[22:57] <jrand0m> perhaps you're right, it could be an app that /uses/ idn, not just uses the code. hmmm... +[22:57] <jrand0m> that'd be Good. +[22:57] <tonious> Mebbe have a key fingerprint associated in case of collisions. +[22:57] <jrand0m> naw, co/wiht is around every few days +[22:57] <tonious> Wouldn't even necessarily need a centralized CA? +[22:57] <jrand0m> we'd need a CA if nyms are unique. +[22:58] <Ophite1> The CA signing chain should elminiate collisions. +[22:58] <jrand0m> (and we need nyms to be unique to do naming, really) +[22:58] <Ophite1> of course this makes CA key very important. +[22:58] <TC> how about dys dns? can i make my host file redirect to a eepsite? +[22:59] <tonious> TC: Not really. The OS doesn't even see i2p. +[22:59] <jrand0m> though we could have $nym.$ca be the thing looked up for +[22:59] <Ophite1> perhaps so important we want to distribute trust by it signing some second level .*.i2p domains, and have virtually all stuff under that, *.*.i2p - i.e., jrand0m.nym.i2p +[22:59] <jrand0m> right, though with tusko's ppp2p we can get i2p to IP mappings +[23:00] <tonious> I dunno. The idea of a CA in an essentially distributed system disagrees with me. +[23:00] <tonious> Not bein' a developer though I'm not gonna make a fuss :) +[23:01] <TC> dns really isnt that importent +[23:01] <jrand0m> tonious> we can do a web of trust, essentially. with, say, 8 seperate known CAs, everyone's local name server knows about those 8, and each of them manages a subdomain (e.g. tc.ca1 or Nightblade.ca2, or we add a .i2p at the end) +[23:01] <Ophite1> if you can think of a better way? +[23:02] <Nostradumbass> i have another question - its sort of spans the network-application area. +[23:02] <jrand0m> (thats really the degenerate case of a WoT) +[23:02] <Ophite1> what I said, sort of - get a root key to sign domains... +[23:02] <jrand0m> agreed tc +[23:02] <jrand0m> fire away Nostradumbass +[23:02] <Ophite1> someone gets com.i2p or nym.i2p... +[23:02] <Nostradumbass> has any thought been goven to guaranteed latency? +[23:02] <Ophite1> allow them to sign jrand0m.nym.i2p, or whatever. +[23:02] <Nostradumbass> i'm thinking of VoIP. +[23:03] <jrand0m> Ophite1> we wouldn't even need a .i2p key with that +[23:03] <tonious> Ophite1: What if the com ca gets taken out by an RIAA hitsquad or something? +[23:03] <jrand0m> Nostradumbass> you mean VoI2P? :) +[23:03] <Ophite1> then once you're done, destroy the master CA. +[23:03] <Nostradumbass> yes +[23:03] <Ophite1> tonious: then there's still the others. +[23:04] <Ophite1> or some system that requires conspiring groups to get the nym signing key? +[23:04] <jrand0m> Nostradumbass> we have already had people run shoutcast streams over i2p with some buffering at 96khz and no buffering problems at less speed. but there's latency. +[23:04] <Nostradumbass> with the upcoming release of cryptophone's (Link: http://www.cryptophone.de/)http://www.cryptophone.de/ source it could make an interesting app for i2p. +[23:04] <Ophite1> and a really freakin' big hashcash? +[23:04] <jrand0m> definitely Nostradumbass +[23:04] <tonious> Ophite1: Mebbe a majority signing protocol? +[23:04] *** Signoff: dm (Ping timeout) +[23:04] <jrand0m> tonious> majority is dangerous with sybil +[23:05] <Ophite1> tonious: otoh, it HAS to be non-repudiatory, and has to be able to guarantee non-collision. +[23:05] <Ophite1> and majority couldn't do that. +[23:05] <Ophite1> a majority of well known users maybe. +[23:05] <Ophite1> if it's a consolation, the internet has problems with this too (think Verisign). +[23:05] <jrand0m> right, WoT :) +[23:06] <Ophite1> but then WoT means that different people might have different ideas of who to trust, which violates non-collision maybe? +[23:06] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev +[23:06] <jrand0m> Nostradumbass> now if we could get some coders to work on a high performance RTSP over i2p tunnel... ;) +[23:06] <Ophite1> it's important, given the length of an "I2P address", but also hard. +[23:06] *** Drak0h (~Dr4k0h@anon.iip) has joined channel #iip-dev +[23:07] <Ophite1> Nostradumbass: not guaranteed. +[23:07] <TC> so how do we secure alias identification (important for commerce and seting up multiple eepsites)? +[23:07] <Nostradumbass> over-provisioning of bandwidth is often the only simple way to try and guarantee latency. is there going to ba any way for a node to determine the available bandwidht at another node, so as to ease routing for VoIP apps? +[23:07] <jrand0m> yes Nostradumbass, QoS can be done transparently within i2p, but unfortunately thats (I hate saying this) > 1.0 +[23:07] <tonious> Say we take root CAs out of it. You generate your key and sign your aliases. +[23:08] *** Signoff: thecrypto (EOF From client) +[23:08] <Ophite1> Nostradumbass: also, troublesome re some potential attacks? +[23:08] <tonious> You also specify who's keys you trust, ala PGP. I think redundancy is more important than collision. +[23:08] <Ophite1> tonious: so which jrand0m.nym.i2p did you want again? +[23:08] * jrand0m attacks the ns dht to get my nym back +[23:08] <Ophite1> if everyone doesn't trust the same, we might not be referring to the same thing when we use the same name. +[23:09] <Ophite1> and it would probably allow freenet-KSK-style collision wars. +[23:09] <jrand0m> right. either the naming service has CA signed nyms, or it just distributes H(destination) --> destination mappings +[23:09] <tonious> Just pop up a menu or something. Or if you're designing an application that talks to a specific server, give it the public key of the signing agent? +[23:10] <jrand0m> (and H(destination) == 42 chars as opposed to ~500 chars for a destination) +[23:10] <Ophite1> tonious: if you're going to give it public keys, you might as well just sling around I2P addresses. +[23:10] <Ophite1> now that's an interesting ideal +[23:10] <Ophite1> assuming sha-256 can't be reversed that yields 256-bit I2P addresses that could be "looked up" to reveal the structure. +[23:10] *** dm (~sd@anon.iip) has joined channel #iip-dev +[23:11] <Ophite1> I smell kademlia again. +[23:11] <jrand0m> :) +[23:11] <Ophite1> It can also be simply checked. +[23:11] <jrand0m> and there's existing code to reuse. +[23:11] <Ophite1> somehow, that makes sense. why weren't we doing this already? :) +[23:11] <jrand0m> because we want nyms +[23:12] <Ophite1> nyms for hosts? +[23:12] <jrand0m> but, I suppose, 42 chars is a good enough starting point +[23:12] <Ophite1> need a root CA for that :/ +[23:12] <jrand0m> right +[23:12] <Ophite1> in the case where you don't want to trust a root ca? +[23:12] <Ophite1> 42 chars is short enough to paste. +[23:12] <jrand0m> you don't need a root CA, you can have a forest instead of a tree +[23:12] <Ophite1> 520 chars isn't :) +[23:12] <jrand0m> heh +[23:13] <Ophite1> but if you have a forest, how does anyone know which tree you're talking about? +[23:13] <Ophite1> you could slap a key in there, but then, ooh, we've got huge strings of random garbage again. +[23:13] <jrand0m> common suffix. $nym.$ca +[23:13] <Ophite1> well, I'd like $nym.$ca.i2p :) +[23:13] <Ophite1> avoid confusion :) +[23:13] <jrand0m> right. I mean, there are possible attacks. I dunno. I'm with TC though +[23:13] <jrand0m> good 'nuff for me +[23:14] <jrand0m> ok, /other/ apps :) +[23:14] <Ophite1> how do you know which ca is which? +[23:14] <Ophite1> you have a list? what signs the list? +[23:14] <jrand0m> i2pns.config +[23:14] *** Signoff: Drak0h (Ping timeout) +[23:14] <Ophite1> how're you going to get that? +[23:14] <TC> if i could make my own dns list, hostfile style i would be happy +[23:14] <jrand0m> on install +[23:15] <Ophite1> how are you going to verify those are the "right" keys? +[23:15] <Ophite1> ca substitution? +[23:15] <jrand0m> right tc, we can even do that without any distributed naming service +[23:15] <TC> because i say they are Ophite1 +[23:15] <jrand0m> Ophite1> you aren't, any more than you're verifying that the source code is running the "real" i2p +[23:15] <TC> and if you trust me, you can download them off my eepsite +[23:16] <Ophite1> I suppose at the end of the day you can only reduce that to trust in one key being right, so :) +[23:16] <Ophite1> works for me, yeah. +[23:16] <Ophite1> as long as I get o1.i2p ;) +[23:16] <jrand0m> heh +[23:17] <tonious> Hmm. Revised threshold scheme: Each CA works the entire namespace, but a majority of CAs must agree before handing out subspace? +[23:17] <jrand0m> ok, last I heard tusko had found a way to get the ppp2p to run off windows machines as well as *nix +[23:17] <TC> it would make the i2p\internet doman system much more community based if we all passed around a huge hostfile\cheat sheet +[23:17] <Ophite1> tonious: back to majority again... +[23:17] <jrand0m> scary for attacks tonious +[23:17] <jrand0m> thats true TC +[23:17] <jrand0m> (and the value of such a community should not be underestimated) +[23:18] <Ophite1> tc: arpanet stylee? +[23:18] <tonious> Sigh. :) +[23:18] <Ophite1> I guess seeds have gotta come from somewhere, so yeah ;) +[23:18] <TC> to get a domain name, you would say this is me, and if people agreed they would change the file, and if they where trusted, others would download updates +[23:19] <jrand0m> sounds like that'd be a heavily retrieved key from idn :) +[23:19] <Ophite1> smells vaguely ca-like too :) +[23:19] <TC> you could even have a fight, with more then one file +[23:19] <Ophite1> the fidonet nodelist! +[23:19] <tonious> And in case of a netsplit there'd be multiple patchfiles. +[23:19] <Ophite1> ...doesn't scale. +[23:19] <jrand0m> with under a few hundred domains, its maintainable manually +[23:20] <TC> after a few hundred you go trusted +[23:20] <jrand0m> right Ophite1. this would just be until we argue out the Right Way. +[23:20] <tonious> It might be enough to jumpstart a WoT. +[23:20] <jrand0m> (or we convince people that CAs aren't that bad ;) +[23:20] <jrand0m> true tonious +[23:20] <Ophite1> if you're trusting someone to agree that someone is someone else, that's a CA, not just a nodelist :) +[23:21] <tonious> Heh. Sorry for bein' the skeptic. +[23:21] <TC> jrand0m, in the end i dont whant to be dependent on CA's +[23:21] <Ophite1> just allow people to give space below theirs... +[23:21] <Ophite1> castyle -- and those on the nodelist to be the cas. +[23:21] <Ophite1> course then it's all "which ca is jrand0m on?" +[23:21] <jrand0m> CA's aren't necessarily choke points. if they're unsatisfactory, we replace them. +[23:22] <tonious> Ophite1: I like that. +[23:22] <Ophite1> point. CA being crapped out would be Big Enough News for someone to simply replace them. +[23:22] <Ophite1> tonious: so is it slashdot.org or slashdot.com? goatse.cx? :) +[23:22] <dm> what does CA stand for? :) +[23:22] <Ophite1> certification authority. +[23:23] <dm> k, thanks. +[23:23] <tonious> Heh. That's where your own WoT comes in, Ophite1. +[23:23] <Ophite1> tonious: yes, but I still have to see goatse once before I realise it's the wrong bloody one. :) +[23:23] <tonious> 'I trust Ophite1 not to show that horrible asshole, and he signed slashdot.org' +[23:23] <jrand0m> lol +[23:24] <Ophite1> so essentially you're trusting a limited subset of people, not to be horrible assholes. +[23:24] * jrand0m reserves the right to be an asshole at times +[23:24] <Ophite1> and to hand out domains to the rest. +[23:24] <Ophite1> at least one of which ought, really, to be a trent-style first-comes-first-served bot. +[23:24] <Ophite1> (with.. yes... hashcash.) +[23:24] <tonious> Yeah. And there may be namespace collisions by people who are outside my WoT... +[23:25] <jrand0m> yup, and another should be something like thetower's tfee/subpage redirects +[23:25] <Ophite1> tonious: something that you can actually USE might be appreciated. it's just a naming system. :) +[23:25] <tonious> Heh. +[23:25] <Ophite1> the good thing about multiple cas is that they can do their own thing re: that kind of thing - different policies. +[23:26] *** Signoff: nickthief60934 (Ping timeout) +[23:26] <jrand0m> ok, other apps... +[23:26] <jrand0m> IM? +[23:26] <Ophite1> finally :) +[23:26] <Ophite1> signed nyms! :) +[23:26] <tonious> Sorry Ophite1 :) +[23:26] <jrand0m> !thwap Ophite1 +[23:27] <Ophite1> what, what are you all looking at? :) +[23:27] <Ophite1> yes, WoT would be appropriate for _that_ :) +[23:27] <dm> I think I remember who was doing IM... thecrypto? +[23:27] <Ophite1> in fact... elgamal 2048-bit... dsa 1024-bit... sha-256... sounds kind of familiar. openpgp? +[23:27] <jrand0m> yodel was in here the other day, mentioned that they had tried out running yodel's xml-rpc interface over with their own local router, and it worked. so, yay +[23:27] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev +[23:28] <tonious> I've managed to get SOAP going on mine, too. +[23:28] <jrand0m> yup dm +[23:28] <tonious> No useful apps, beyond 'Yep, it works' so far. +[23:28] <jrand0m> hehe +[23:29] *** Signoff: nickthief60934 (Excess Flood) +[23:29] <Nostradumbass> tonious: so SOAP over i2p = Black SOAP? +[23:29] * jrand0m really wants to get idn up and running so we can use i2p as an IP layer, not a TCP layer +[23:29] <jrand0m> lol Nostradumbass +[23:29] <Ophite1> nicename :) +[23:29] <tonious> Nostradumbass: Yep, you got it. +[23:30] <tonious> Now I can set up my own I2P casino. w00t! +[23:30] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev +[23:30] <jrand0m> w33wt +[23:30] <jrand0m> ok, I think thats 'bout it for the apps +[23:30] <jrand0m> 5) ...? +[23:31] <jrand0m> hi +[23:31] <Ophite1> tonious: cool. we could use a few of those. donate a percentage to the i2p project? :) +[23:31] <TC> merchandising +[23:31] <tonious> Has anybody thought of a C implementation of I2P? +[23:31] <jrand0m> yeah, rent out colo boxes and run routers :) +[23:32] <jrand0m> tonious> lets wait until we get the router protocol implemented and thoroughly reviewed before porting ;) +[23:32] <tonious> Or anonymous colo: Behind an I2P router and no internet routing :) +[23:32] <Ophite1> merchandising = logo. +[23:32] <TC> stickers, t-shirts, hats, we need the logo +[23:32] <Ophite1> tonious: after it's working and anonymous and stuff? of course. +[23:32] <tonious> Yeah, but I'm still running my P2 and I'm a poor guy. +[23:32] <tonious> :( +[23:32] <Ophite1> i2p needs a good logo. +[23:32] <Nostradumbass> yes +[23:32] <Ophite1> I mean, the internet doesn't have a logo, but that's just bad marketing. :) +[23:32] <dm> I like the one on the WIKI. +[23:32] <TC> also, each made-for-i2p program needs its own tweeked version, or take off of the logo +[23:32] <jrand0m> how about a transparent logo... it'd, be, like, everywhere, dood +[23:33] <Ophite1> an invisible logo. heh. +[23:33] <tonious> A 1 pixel by 1 pixel blank gif? +[23:33] <jrand0m> definnitely +[23:33] <Ophite1> tonious: we'd be sued for copyright infringment? :) +[23:33] <tonious> Ha! +[23:33] <Ophite1> ("Hey, that's OUR blank gif!") +[23:33] <jrand0m> lol +[23:33] <Ophite1> Hey, if John Cage can do it... +[23:33] <tonious> So we leave our names in the comments field :) +[23:33] <Nostradumbass> Ophite1: how about a stream roller paving over the Internet? +[23:33] <jrand0m> heh we're just rendering his audio +[23:34] <Ophite1> that one on the bottom looks the best imho. +[23:34] <tonious> I like the one on the top. It's simple. Like me. +[23:34] <Ophite1> with the arc design. +[23:35] <Ophite1> something that is small, very simple, and above all would work well as an icon, or in the system tray :) +[23:35] <Ophite1> and yes, which can be customised and used as a basis for logos of apps. +[23:35] <jrand0m> right +[23:35] <dm> How about a black circle with white fill. +[23:35] <Ophite1> that arc would be a good start (colour changes?) +[23:35] <dm> or a triangle, maybe a square! +[23:35] <dm> a parallelogram! +[23:37] <tonious> Heh. Open up a cafepress store... +[23:37] <Ophite1> god no, not cafepress. +[23:37] <dm> a white cloud! +[23:37] <Ophite1> we demand class. ... thinkgeek. ;-) +[23:37] <dm> little fluffy cloud. +[23:38] <TC> it would look toomuch like a cumpuddle in minature +[23:38] * jrand0m associates clouds with the sky, thankyouverymuch +[23:38] <tonious> Ophite1: First we've gotta convince 'em that we're whitehat. +[23:39] <TC> no, lets be black hat +[23:39] <jrand0m> tonious> can militant anarchists be whitehats too? +[23:39] * TC doesnt like ppl in hats +[23:39] <tonious> Dunno. +[23:39] * tonious wears a grey fedora FWIW. +[23:39] <Nostradumbass> how about a white and a black hat? +[23:39] <TC> and modulus would say somthing about class distinction or something +[23:40] <dm> a small picture of uncle sam's face? +[23:40] <TC> checkered hat? +[23:40] <jrand0m> heh tc +[23:40] <Nostradumbass> or white and a black wizzard hats +[23:40] <Ophite1> I am NOT a white hat. How dare you insinuate that. I want an apology. +[23:41] <TC> or a black dunce hat +[23:41] <jrand0m> well, anyway... +[23:42] <tonious> "i2p inside"? +[23:42] <jrand0m> heh +[23:42] <dm> I, too, pee... +[23:42] <jrand0m> dm> on a calvin sticker! +[23:42] <Ophite1> "i2p ... somewhere" +[23:42] <TC> so, logo ppl, come on! so can nop set us up a i2p cafepress site? +[23:43] * jrand0m repeats the mantra No PR until its ready. +[23:43] <Nostradumbass> dm: yeah, make it a "Concentration" style chrade logo-gram. +[23:43] <Nostradumbass> <eye> 2 and a pee-ing penis. +[23:44] <dm> Let's set a date. +[23:44] <jrand0m> heh, yeah, and you'll have your mother click on that icon? +[23:44] <dm> March 1st. +[23:44] <Nostradumbass> grab it, in fact :) +[23:44] <tonious> My mother disapproves of encryption :) +[23:44] *** UserX (~User@anon.iip) has joined channel #iip-dev +[23:44] <dm> Slashdot article! No matter how far (or not) jrand0m has gotten! +[23:44] <dm> Let's pile on the pressure. +[23:44] <Ophite1> nooooooo. +[23:44] <Ophite1> not yet! +[23:45] <jrand0m> damn dm, if you pulled that date out of thin air, you're good. in my palm I have 1.0 slotted as ~ march 1 +[23:45] * dm slaps Ophite1 +[23:45] <dm> i said march 1st. +[23:45] <Ophite1> the appropriate time to promote is when we have a cool shiny thing to wave at them. +[23:45] <Nostradumbass> please, no slashdot till the network is ready for the onslaught. +[23:45] <jrand0m> right +[23:45] <dm> I'm good, what can I say. +[23:45] <Ophite1> I call launch date April 4th. +[23:45] <Ophite1> 04/04/04 ;) +[23:45] <jrand0m> no PR until AFTER 1.0 comes out. +[23:45] <Nostradumbass> Mojo was almost destroyed by /. +[23:46] <dm> no, none of this rational thinking. March 1st, end of story. +[23:46] <jrand0m> ooOOo Ophite1 +[23:46] * jrand0m senses that I'm going to have to submit to /. to get them to NOT post dm^H^Han anonymous person's article +[23:46] <Ophite1> no, don't do that. malda doesn't give a shit, and he'll post THAT :) +[23:46] <jrand0m> heh +[23:47] <dm> Yes, you will be ridiculed by my post: "Em, like, there's this like anonymous cool program that's better than kazaa, I2P it's awesome, it's fast, DSA124. yeah" +[23:47] <jrand0m> anyway, as things progress, http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap will be updated +[23:48] <dm> time to pack. +[23:49] <jrand0m> (and some day I'm going to take a week off and go snowboarding) +[23:49] *** soros (~soros@anon.iip) has joined channel #iip-dev +[23:49] <jrand0m> yeah, we're about the 2hour mark. +[23:49] <jrand0m> time to... +[23:49] * jrand0m *baf*'s the meeting closed. diff --git a/i2p2www/meetings/logs/66.rst b/i2p2www/meetings/logs/66.rst new file mode 100644 index 00000000..a6f07c8d --- /dev/null +++ b/i2p2www/meetings/logs/66.rst @@ -0,0 +1,7 @@ +I2P dev meeting, November 26, 2003 @ 22:00 CET +============================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/68.log b/i2p2www/meetings/logs/68.log new file mode 100644 index 00000000..4f9acffa --- /dev/null +++ b/i2p2www/meetings/logs/68.log @@ -0,0 +1,274 @@ +[22:02] <jrand0m> 0) welcome to $num +[22:02] <jrand0m> 1) iip status +[22:02] <jrand0m> 2) kademlia stuff + idn +[22:02] <jrand0m> 3) peer profiling stuff +[22:02] <jrand0m> 4) i2p services +[22:02] <jrand0m> 5) stuff +[22:02] <jrand0m> 0) welcome +[22:02] <jrand0m> hi +[22:03] <jrand0m> this is meeting 67 or 68... +[22:03] <jrand0m> 1) iip status +[22:03] <jrand0m> I dunno. anyone know what the situation has been as of late? +[22:04] <jrand0m> the iip devs aren't here, so... dunno. +[22:04] <jrand0m> [ping] +[22:04] <jrand0m> (last week I typed for probably 10 minutes before my client pinged me out...) +[22:05] <jrand0m> (i'm not going to type anything else until I get a p0ng, damnit ;) +[22:05] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev +[22:05] <jrand0m> 'lo Nostradumbass +[22:06] <Nostradumbass> hi :) +[22:06] <jrand0m> ok cool, so I haven't pinged out, people are just lurking. cool :) +[22:06] * jrand0m hops on to the next agenda item +[22:06] <Nostradumbass> how's i2p coming? +[22:06] <Nostradumbass> sorry? +[22:06] <jrand0m> good lead in ;) +[22:07] <jrand0m> agenda item 3) i2p 0.2.3 status :) +[22:07] *** nerox (~nerox@anon.iip) has joined channel #iip-dev +[22:07] <jrand0m> there's been a lot of progress, even though I'm offline. commited a truckload of code a few hours ago +[22:07] <jrand0m> that includes an implementation of the kademlia netDb +[22:08] <jrand0m> so I'm pretty confident we'll hit the release for 0.2.3 next week (which is basically kademlia netDb + a shell script) +[22:08] <jrand0m> there have been a few more variations on the kademlia proto though to make things more relevent for i2p +[22:09] <jrand0m> we will always have a very, very, /very/ sparse kademlia tree. +[22:09] <jrand0m> 2^256 possible slots, and 1-10 values per peer in the network. +[22:09] <jrand0m> so, thinking insanely overzealous, we still wont be using jack shit, and everything will be in the furthest out kbucket +[22:10] <jrand0m> so some parts of kademlia are going to be quietly ignored ;) but the basic gist stays the same, including the search algo & distance metric +[22:10] <jrand0m> idn, however, is dead in the water. +[22:11] <jrand0m> the idea that i2p's netDb code could run off the same code as a publishing DHT was a silly little idea +[22:11] <jrand0m> and has been promptly abandonded. +[22:11] <jrand0m> idn is still generally a good idea, but I'm not going to spend my i2p dev time working on it +[22:12] *** tusko (~tusko@anon.iip) has joined channel #iip-dev +[22:12] <jrand0m> but part of the 0.2.3 changes include a dramatic revamp of how we choose peers and organize router stats +[22:12] <jrand0m> heya tusko +[22:12] <jrand0m> that brings us to agenda item 3) peer profiling +[22:12] <jrand0m> I've been pretty silly...and finally did some of the math +[22:13] <jrand0m> the stats being gathered now are immense. +[22:13] <jrand0m> about 6000 data points /per peer/ +[22:13] <duck> what is peer profiling? +[22:13] <jrand0m> peer profiling is where the router keeps track of the performance of each peer so that it can decide who to use in the future +[22:13] <duck> ah +[22:13] <jrand0m> (aka fast routers, reliable routers, etc) +[22:13] <duck> the process that eats up my memory :) +[22:14] <jrand0m> heh actually that part isn't toooo bad +[22:14] <jrand0m> though 6000 data points won't scale. +[22:14] <jrand0m> 1000 routers @ 6000 data points each @ 4 bytes / data point = 24Mb +[22:15] <jrand0m> though keeping detailed stats on a few hundred peers is probably fine, even as the net grows beyond that +[22:15] <jrand0m> we /don't/ need to keep stats on everyone. just routers we want to 'use' for our tunnels, garlic routing, and source routing. +[22:16] <jrand0m> we could probably get away in the long term with just keeping track of a hundred or so peers. +[22:16] <jrand0m> but, for now, I'm going to say fuckit. +[22:16] <jrand0m> keep stats on all peers +[22:16] <duck> ping +[22:16] <jrand0m> p0ng +[22:17] <duck> will it try to learn about all peers? +[22:17] <jrand0m> right now, yes +[22:17] <duck> oh wait, your last lines covered that +[22:17] <jrand0m> we also have some code for coallescing and running calculations on the peer profiles +[22:18] <jrand0m> so one of those calculators will determine what peers to drop +[22:18] <jrand0m> an example of the data set being collected: (Link: http://i2p.dnsalias.net/~jrandom/profile.txt)http://i2p.dnsalias.net/~jrandom/profile.txt +[22:19] <jrand0m> (you'll notice lots of 0s :) +[22:19] <jrand0m> I've written up a rough manifesto for peer selection and profiling, but need to get that onto the wiki +[22:20] <jrand0m> but thats all 0.3 stuff, really. 0.2.3 just uses a little of it +[22:21] <jrand0m> ok, thats it for the peer profiling. lots more later, just giving a lil view into whats up +[22:21] <jrand0m> (of course, as always, anyone who wants to get down and dirty and figure out what other stats / calculations / attacks / etc should be used would be *very* much appreciated) +[22:22] <jrand0m> ok, 4) i2p services +[22:23] <jrand0m> tc's site is awesome & really reliable! I finally got to nightblade's page as well, and its a cool blog ('plog' ;).. I just wish I could leave comments :) +[22:23] <jrand0m> there's also duck's jabber server, which works fairly easily with the instructions posted to tc's board +[22:24] <jrand0m> things sometimes act up a bit, but thats related to some bugs in the router <= 0.2.2, and have been fixed (and will roll out in 0.2.3) +[22:24] <jrand0m> the squid proxy is generally offline, since I'm offline too much to babysit my kaffe routers :/ +[22:25] <jrand0m> so for the moment, the eepsites and the jabber chat is probably the most reliable things on i2p, all running on top of i2ptunnel +[22:25] <jrand0m> what services would be cool to show up next? +[22:25] <duck> I did try to run an ircd over i2ptunnel +[22:25] <duck> but before it got the full MOTD after logging in, I got ping timeouted already +[22:26] <jrand0m> d'oh +[22:26] <duck> and that was on the same router +[22:26] <duck> so in the wild performance will be even worse +[22:26] <jrand0m> on the local router it pinged out?! +[22:26] <jrand0m> local router should never ping anything out +[22:26] <jrand0m> oh, except for that race bug +[22:26] <jrand0m> (which is probably what it was, since it was local and the race is faster there) +[22:26] <duck> irc client pinged out for not responding in time +[22:27] <duck> I'll retry with 0.2.3 +[22:27] <jrand0m> word +[22:27] <duck> though jabber is nice for now +[22:27] <jrand0m> totally +[22:27] <jrand0m> and long term, irc is not the way to go +[22:27] <duck> tc, jrandom and me are there to chat with! +[22:27] <jrand0m> hehe :) +[22:28] <jrand0m> we need an IM and group chat solution that doesn't give cleartext to anyone unauthorized, and doesn't require centralized choke points +[22:28] <jrand0m> (aka iip 2.0) +[22:28] <jrand0m> now would be a nice time for userx to come back into the fold ;) +[22:29] * jrand0m stops holding breath +[22:29] <jrand0m> an nntp server would /also/ really really rule. +[22:29] <duck> I'll try that tomorrow +[22:29] <jrand0m> r0x0r +[22:30] <duck> jabber is really nice to run other things over +[22:30] <duck> check out the jabber rpc specs +[22:30] <duck> (Link: http://www.pipetree.com/jabber/jrpc/)http://www.pipetree.com/jabber/jrpc/ +[22:30] <duck> other services? +[22:30] <jrand0m> thats interesting - doing jabber as a naming service, essentially +[22:31] <duck> you mean: +[22:31] <jrand0m> there will always be more services to add - with mail (usenet), chat (jabber) and publishing/browsing (eepsites), there's good coverage +[22:31] <duck> name server has a jabber client through which you can register names (provided token) +[22:31] <duck> also use it to query? +[22:31] <jrand0m> naw +[22:32] <jrand0m> jabber's registry being the naming service +[22:32] <duck> ok +[22:32] <jrand0m> its centralized but it works +[22:32] <jrand0m> just like hosts.txt :) +[22:33] <duck> are there mail solutions that are better suited for there environments than smtp and pop/imap ? +[22:33] <jrand0m> thats a really good question +[22:33] <duck> cause I dont think that it will just work when you hook up mail servers +[22:34] <jrand0m> yeah, it'd probably need either a gateway (ala freemail) or the naming service doing some interesting tap dancing +[22:34] <jrand0m> or it reverts back to centralized single POP3/IMAP server with everyone on the same server +[22:35] <duck> I spoke with aum (author of freemail) yesterday +[22:35] <duck> he was talking about reimplementing fred in python +[22:35] <jrand0m> lol nice +[22:35] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev +[22:35] <duck> so I did suggest him to work on the python routers for i2p instead +[22:35] <jrand0m> ooh that would TOTALLY rule! +[22:35] <duck> then he got totally upset about the pdf documents +[22:36] <jrand0m> hey, if he wants the openOffice originals, or even a txt export I'll export +[22:36] <duck> and I lost my patience and told him that you would also have the m$word docs if he did ask nicely +[22:36] <duck> well, you were a fuckhead for not doing a html export or something +[22:36] <jrand0m> naw, I tried that ;) +[22:36] <duck> I lost my patience and told him to talk to you +[22:36] <jrand0m> the openOffice html export SUCKS +[22:37] <duck> hm +[22:37] <mrflibble> true jr +[22:37] <jrand0m> when the specs turn 1.0 (aka when the router turns 1.0 and they're updated to match the code), they'll be on the wiki. +[22:37] <duck> wiki has most info though +[22:37] <jrand0m> exactly +[22:37] <mrflibble> i tried using that for that kevin mitnick book. it was worse than ms office +[22:37] <duck> oh well +[22:37] <jrand0m> zactly. +[22:37] <duck> he might appear here once +[22:37] <jrand0m> that'd be awesome +[22:38] <duck> but maybe it is better with his attitude to join the freenet gang +[22:38] <duck> ... +[22:38] <jrand0m> well, effort on freenet is always a good thing +[22:38] * duck goes back to beeing friendly +[22:38] <jrand0m> :) +[22:38] <duck> aums work rocks +[22:38] <duck> hopefully he'll rock on i2p +[22:39] <jrand0m> yeah whenever someone talked about searching on freenet, I always just said "well just do a McNabb" +[22:39] <jrand0m> we need the help, certainly +[22:39] <duck> which brings me to the following question: +[22:39] <duck> are the changes to I2P that you do specced? +[22:39] <duck> or is the java source the documentation for the latest info +[22:40] <jrand0m> there are notes taken in my palmpilot, filesystem, and notebook, but unfortunately I haven't updated the openoffice docs in a while +[22:40] <jrand0m> feb is doc-month for jrandom. +[22:40] <jrand0m> (and qa, and bugfixing) +[22:41] <jrand0m> ((and benders ;)) +[22:41] <jrand0m> the specs are still pretty much correct, there are just more details. +[22:41] <duck> awesome +[22:41] <jrand0m> but the datastructures have had more changes +[22:42] <jrand0m> ok, anything else for services? +[22:43] <jrand0m> ok, 5) stuff +[22:43] <jrand0m> hi +[22:43] <duck> hi! +[22:43] <jrand0m> how's tricks? +[22:43] <jrand0m> [any questions / thoughts / issues / etc go here] +[22:43] <duck> the base64 tricks should be added to the i2ptricks pages +[22:44] <jrand0m> ooh good point +[22:44] <duck> might be some other tricks too that I dont know yet +[22:44] <duck> will grep the sources for 'main' +[22:44] <jrand0m> I feel guilty for not having the installer let someoene automatically fetch hosts.txt and reseed +[22:44] <jrand0m> lol +[22:44] <jrand0m> there are lots and lots of main() methods, but they're mostly test functions +[22:45] <jrand0m> oh! +[22:45] <jrand0m> one thing. DONT run the current code from cvs and expect it to work with normal routers. +[22:45] *** joda (--@anon.iip) has joined channel #iip-dev +[22:45] <joda> hi +[22:45] <jrand0m> the db messages changed :) +[22:45] <jrand0m> hi joda +[22:45] <joda> sorry, if I interrupt something +[22:45] <duck> I got a bit upset that I couldnt get cvs to work +[22:45] <duck> but then I did remember that this isnt freenet +[22:45] <joda> I was just wondering what happend to "anonymail" ? +[22:46] <duck> so you dont need latest cvs to be able to use it +[22:46] <jrand0m> joda> the user who runs it doesn't seem to be online at the moment. should be back soon +[22:46] <jrand0m> hehe duck - did it fail for you today after I committed, or do you mean from before today? +[22:46] <duck> last week somewhere +[22:46] <joda> jrand> thx :) +[22:46] <joda> cu :) +[22:46] <jrand0m> ah 'k duck +[22:46] <jrand0m> l8r joda +[22:47] <jrand0m> yeah, I only endorse running the released code +[22:47] <duck> will 0.2.3 put the version files in a directory? :) +[22:47] <jrand0m> 0.2.3 gets rid of the version files :) +[22:47] <jrand0m> (lots and lots and lots of changes) +[22:47] <jrand0m> but that means 0.2.3 (and beyond) will require g enerally correct clocks +[22:48] <jrand0m> (current Router.CLOCK_FUDGE_FACTOR = 30 minutes) +[22:48] <duck> what will the fudge facter be for 0.2.3? +[22:48] <jrand0m> probably the same +[22:49] *** joda has left #iip-dev +[22:49] <duck> oh, current = your code +[22:49] <jrand0m> that time will be used to expire db entries +[22:49] <duck> k +[22:49] <jrand0m> ah, right, yeah :) +[22:49] <jrand0m> (in 0.2.2 that clock_fudge_factor is spread out throughout half a dozen files) +[22:49] <duck> maybe the installer could be a bit more userfriendly +[22:49] <duck> as in less questions +[22:49] *** Signoff: nickthief66282 (Excess Flood) +[22:50] <duck> default phttp urls included, no bandwidth limiting etc +[22:50] <jrand0m> I guess we could autoguess random ports too +[22:50] <jrand0m> you're right +[22:50] <jrand0m> want commit privs? :) +[22:50] *** Signoff: nerox (EOF From client) +[22:50] <jrand0m> (if not I can update it for 0.2.3) +[22:51] <duck> an argument against it can be that users will take settings too easily for granted +[22:51] <duck> and everybody uses the same phttp relay +[22:51] *** nickthief24373 (~chatzilla@anon.iip) has joined channel #iip-dev +[22:51] <jrand0m> true. though 0.3.1 plans include an update to the phttp relay code to let relays talk to each other, and redirect users to a less loaded relay +[22:52] <jrand0m> i'm generally happy with the install process atm though - i built a new 0.2.2 install and was browsing tc's page in under a minute +[22:52] <jrand0m> (though thats because i know what all the text says and didn't read it...) +[22:52] <duck> I dont like the long keys +[22:53] <duck> especially not if you have to copy&paste them +[22:53] <duck> better use them as file +[22:53] <jrand0m> hmm? +[22:53] <duck> but distributing the binary files are a pain +[22:53] <duck> so you have to do the base64 trick.. +[22:53] <duck> could the i2ptunnel read base64 destination keys too? +[22:53] <duck> from a file that is +[22:53] <jrand0m> I was just typing that ;) +[22:53] <jrand0m> yeah, that wouldnt be much work +[22:54] <jrand0m> perhaps even 1 line +[22:54] <duck> also, what about armouring? +[22:54] <duck> with a header&footer +[22:54] <duck> like pgp etc +[22:55] <jrand0m> true, it would be useful to have that sort of validation +[22:55] <duck> ofcourse that is a gadget +[22:55] <duck> but it could be helpful for those who want to use the tunnel +[22:55] <jrand0m> though the Destination structure itself is pretty picky +[22:55] <jrand0m> but you're right, a raw base64 isn't the most intuitive or safe thing to pass around +[22:56] <jrand0m> we need a bugzilla +[22:56] <jrand0m> so things like this can get posted as todo +[22:56] <jrand0m> i'd move off my palm's todo list for that +[22:56] <duck> bugzilla has nazi registration requirements +[22:56] <duck> with emails etc.. +[22:56] <jrand0m> true +[22:57] <duck> but better as nothing +[22:57] <duck> other bugtrackers all have their shortcomings +[22:57] <jrand0m> yeah, every company i've worked at has pretty much ended building their own +[22:58] <jrand0m> we'll see. we need a bugtracker by the time we start doing full on qa (once 0.3 comes out) +[22:58] <jrand0m> so we've got a few weeks ;) +[22:58] <jrand0m> but if someone did some research and found a really nice one, that'd be great +[22:59] <jrand0m> [not you specifically duck, anyone who's reading these meeting logs at home ;)] +[22:59] <duck> so far phpBugTrackers has been okay for me +[22:59] <jrand0m> hmm haven't used that +[22:59] <duck> yes, I am not talking to jrandom either +[22:59] <jrand0m> lol +[22:59] <duck> but to the group of I2P code developers :) +[22:59] * jrand0m is actually 12 people acting under a single nym +[23:00] <jrand0m> ok, 1 hour, on the dot +[23:00] <jrand0m> anyone else have anything before I get the *baf*er out? +[23:01] * duck demands 1 more minute +[23:01] <duck> since we did start on 21:02 +[23:01] <jrand0m> yeah yeah +[23:01] <jrand0m> la la la +[23:01] <jrand0m> what should i have for dinner? +[23:01] <jrand0m> there's a nice falafel place next door... +[23:01] <jrand0m> had gnocci for lunch too +[23:01] <jrand0m> hmm... +[23:01] <jrand0m> maybe a liquid dinner +[23:02] <duck> soup? +[23:02] <jrand0m> ooOooo whiskey soup! +[23:02] * jrand0m *baf*'s the meeting closed on that note diff --git a/i2p2www/meetings/logs/68.rst b/i2p2www/meetings/logs/68.rst new file mode 100644 index 00000000..28f66d35 --- /dev/null +++ b/i2p2www/meetings/logs/68.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 9, 2003 @ 22:00 CET +============================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/69.log b/i2p2www/meetings/logs/69.log new file mode 100644 index 00000000..d837d72d --- /dev/null +++ b/i2p2www/meetings/logs/69.log @@ -0,0 +1,244 @@ +[22:04] <jrand0m> 0) hi +[22:04] <jrand0m> 1) iip +[22:04] <jrand0m> 2) 0.2.3 & 0.2.3.1 +[22:04] <jrand0m> 3) hi +[22:04] <jrand0m> 0) hi +[22:04] <jrand0m> welcome to the ... something'th meeting +[22:05] <jrand0m> (68? 69?) +[22:05] <MrEcho> damm its 1pm here +[22:05] <jrand0m> GMT-8? +[22:05] <duck> 69 +[22:05] <jrand0m> h0t. +[22:06] <jrand0m> ok, 1) iip +[22:06] *** Signoff: tusko (EOF From client) +[22:06] * MrEcho compiles a kernel for the meeting +[22:06] <jrand0m> iip is acting crazy. all i know is nop is "moving servers", whatever that means. i don't know when it'll be done, etc. +[22:06] <jrand0m> anyone have any more info they want to share with the class? +[22:06] *** mids (mids@anon.iip) has joined channel #iip-dev +[22:06] <MrEcho> no info from nop +[22:07] <mids> this morning I was told that I could start Trent again +[22:07] <mids> (I did do so already last night) +[22:07] <jrand0m> wikked +[22:07] <jrand0m> gracias +[22:07] <mids> so that indicates that nop believes that IIP is more stable again +[22:07] <mids> if that is worth anything... +[22:07] <mids> *cough* +[22:07] <jrand0m> ok cool +[22:08] <jrand0m> [woot roommate just handed me a glass of wine for the meeting] +[22:08] <MrEcho> lol +[22:08] <jrand0m> ok, since nop is online and won't come to hte meeting, we'll have to save the lynch mob for later +[22:09] <jrand0m> 2) 0.2.3 & 0.2.3.1 +[22:09] <mids> what specific question do you want to ask him? +[22:09] <protocol> when is the meeting +[22:09] <jrand0m> specific question> when will he make an official announcement describing the past problems and how the future ones will be addressed? +[22:09] <jrand0m> the meeting is now +[22:10] <jrand0m> (aka, at what point should we explore non-iip means of communication) +[22:10] <mids> if I get an answer I'll let you know. +[22:10] <jrand0m> thanks +[22:11] <jrand0m> ok, i2p stuff. 0.2.3 came out yesterday, and while most of hte kademlia code is working fine, there are some 0.2.2 bugs showing up as well as some other bugs being explored. +[22:11] <jrand0m> i've committed a change to use tunneled messages for dbStore instead of garlics, which should reduce the load tc (et al) have been seeing on servers +[22:12] <jrand0m> there is also a new persistent sessionKeyManager that will make it so restarts won't totally b0rk a router for 15 minutes +[22:12] <MrEcho> what about client connect times to routers? +[22:12] <duck> so far it feels as good/bad as 0.2.2; unless my router/tunnels go down again this night, in which case it is worse as 0.2.2 +[22:13] <jrand0m> MrEcho> that seems to be in the interaction of two bugs from 0.2.2 thats acting up more than before. those two are my top priority. +[22:13] <MrEcho> ok cool +[22:13] <jrand0m> duck> my feeling is that its worse than 0.2.2, from an end user perspective. i'm working on fixing that without sacrificing anonymity or security. +[22:13] <MrEcho> its hard to work on the dns with that damm bug .. i have to restrt the dns server alot +[22:14] <jrand0m> MrEcho> with local only routers i have not been able to reproduce the bugs - does it work for you w/ local only? +[22:15] <MrEcho> no +[22:15] <jrand0m> could you send me debug logs for that? +[22:15] <MrEcho> already deleted +[22:16] <jrand0m> ok, if you try again and it doesn't work, if you could send me debug logs from both the router and client I'd appreciate it. +[22:16] <MrEcho> its doing the samething as before .. client gets msg that its sent .. but never makes it to the client +[22:16] <MrEcho> to the other client +[22:17] <MrEcho> ya .. ill see what i can do +[22:17] <jrand0m> ok, sounds like the i2psessionImpl2 bug. i haven't been able to reproduce that locally, but once its fixed for remote hopefully it will work for your situation +[22:17] <jrand0m> gracias +[22:17] <jrand0m> in any case, thanks for y'all's patience with the update. we're making progress, even if it doesn't feel like it on the surface +[22:18] <protocol> shine on you crazy diamond +[22:18] <duck> in the future, say once i2p is actually used, how will the development / release process change to prevent broken releases from mess up the net? +[22:19] <jrand0m> once 1.0 is out, i'll do dev & roll out to an insane group of volunteers to play with for a week, then if things wokr great, it'll get rolled out to general release. +[22:20] * FireRabbit will be an insane vollunteer +[22:20] <jrand0m> right now i've got to battle with kaffe & jetty for updates on i2p.dnsalias.net +[22:20] <duck> what species? +[22:20] * MrEcho already is +[22:20] *** tusko (~tusko@anon.iip) has joined channel #iip-dev +[22:20] <jrand0m> y'all already are insane (and very helpful) volunteers :) +[22:20] <FireRabbit> thank you! +[22:20] <FireRabbit> :) +[22:21] *** TC (~TC@anon.iip) has joined channel #iip-dev +[22:21] <jrand0m> hey if it aint tc +[22:21] * MrEcho wips TC .. your late +[22:21] <TC> hey +[22:21] <TC> we back up and running? +[22:21] <MrEcho> ya i can type todya... +[22:22] <jrand0m> iip seems up... +[22:22] <TC> yay +[22:22] <jrand0m> in any case, i'm hoping to have 0.2.3.1 out in the next few days, once the two critical bugs get fixed (the cpu overload tc has seen has already been updated) +[22:23] *** wiht (anon@anon.iip) has joined channel #iip-dev +[22:23] <TC> what was the cause? +[22:23] <FireRabbit> i seem to have noticed increased disk activtiy since updating to 0.2.3 but i havent spent any time to see if thats actually i2p or just the comp being stupid +[22:23] *** Signoff: wiht ((null)) +[22:23] <TC> FireRabbit, how much memmory do you have? +[22:24] <FireRabbit> that computer has 128 i believe +[22:24] <FireRabbit> you think it could be the paging file? +[22:24] <jrand0m> the cause was that 0.2.3 sends all dbStore messages via garlic routed messages instead of directly, which uses either ElGamal or AES+SessionTag (depending on whether tags are known). the persistentSessionKeyMAnager will make tags last longer, and 0.2.3.1 will send dbStore messages through tunnels instead +[22:24] <TC> because i have 512 and i2p gave me an 'out of memmory' error last night +[22:24] <jrand0m> really? shite +[22:24] <FireRabbit> oh, intresting +[22:25] <MrEcho> wow +[22:25] <jrand0m> yeah, thats #3 on the list of bugs left to crack (though thats not a 0.2.3.1 showstopper) +[22:25] <jrand0m> OOMs don't use all 512 +[22:25] <TC> but it seems to be running fine now +[22:25] <jrand0m> they only use what java's given (e.g. 64M) +[22:26] <TC> yes +[22:26] <duck> Memory: In use: 8187KB +[22:26] <jrand0m> word +[22:26] <duck> that is not much! +[22:26] <duck> yet +[22:26] <MrEcho> Memory: In use: 8908KB Free: 4088KB +[22:27] <jrand0m> right, there is something growing in there, i hope to have it tracked down by 0.3 +[22:27] <jrand0m> cool, free means it used to use 12.9M, now it only uses 8.9 +[22:27] <TC> its running at 30megs of memory at the moment but last night it jumped up to (what windows told me) '70' about then is where it crashed +[22:27] <jrand0m> yeah, kaffe does that for me tc +[22:28] <jrand0m> ok, in any case, people should subscribe to the i2p mailing list +[22:28] * FireRabbit is thinking when he gets home today hes going to rewrite the meshwork lib since it has some problems +[22:28] <FireRabbit> sigh +[22:28] <jrand0m> ((Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/) +[22:28] <jrand0m> d'oh FireRabbit +[22:28] <FireRabbit> this thing is never going to gte done +[22:28] <TC> yah, and memory is no biggy for the most part +[22:28] <jrand0m> heh, no project goes as easily as one hopes +[22:28] <FireRabbit> nope +[22:28] <protocol> jrand0m: the maillist triggers Yahoo! spam protection +[22:28] <protocol> just a heads up +[22:28] <jrand0m> really protocol? +[22:29] <protocol> yeah +[22:29] <jrand0m> perhaps thats what triggered the spam guard when i cc'ed iip-dev +[22:29] * jrand0m will write my isp +[22:29] <jrand0m> (or perhaps its the .dnsalias.net thing) +[22:30] <protocol> i didn't get any mailings so far, and i emptied my bulk mail b4 i could check +[22:30] <duck> or the jrandom nicknam +[22:30] <jrand0m> lol duck +[22:30] <FireRabbit> :) +[22:30] <jrand0m> that'd be awesome if my nick was filtered :) +[22:30] <FireRabbit> hehe +[22:30] *** wiht (anon@anon.iip) has joined channel #iip-dev +[22:30] <jrand0m> wb wiht +[22:30] <jrand0m> speaking of which, I suppose I should inject 3.1) apps :) +[22:31] <jrand0m> hey MrEcho, how goes the battle? +[22:31] <wiht> jrand0m: Hello. +[22:31] <MrEcho> the day somone writes a autodetect program for the linux compile config +[22:31] <MrEcho> well its on its way +[22:31] <duck> knoppix uses some autodetect thing, isnt it? +[22:31] <jrand0m> ./configure ; make ; make check ; make install ; reboot +[22:31] <duck> </offtopic> +[22:31] <MrEcho> ive pritty much maped out how i want to do everything +[22:31] <jrand0m> word +[22:32] <jrand0m> do you have a clear view on how i2ptunnel could be updated to make use of what you're doing MrEcho? +[22:32] <FireRabbit> i think knoppix uses hotplug +[22:32] <MrEcho> 0.1 wont be/might be locked down .. dont know yet +[22:32] <jrand0m> coo' +[22:33] <TC> oh jrand0m, i have a question about the cvs +[22:33] <jrand0m> que tal? +[22:33] <MrEcho> for dns querys im going to have a server port on the Client and RS side for Names querys +[22:33] <FireRabbit> ok jrand0m so enlighten me on this, if you have two arrays, one thats storing data just recieved and one thats acting as a buffer what would you name them +[22:33] <MrEcho> and im going to build a lib for any app to use +[22:33] <jrand0m> FireRabbit> src, dest +[22:34] <FireRabbit> humm +[22:34] <TC> i thought it would be a good idea if i updated the host file directly to the i2p based cvs so it could be included with future versions +[22:34] <jrand0m> definitely tc +[22:34] <FireRabbit> this is a pretty big class, i think id want to go a little more specific than that +[22:34] * jrand0m should get you a cvs account +[22:34] <TC> im just wondering how to connect to it +[22:34] <duck> TC: you want (Link: http://www.tortoisecvs.org/)http://www.tortoisecvs.org/ +[22:34] <duck> easiest CVS client for windows that I know +[22:35] * MrEcho uses the dos ver :) +[22:35] <mihi> duck: for windows != win9x ;) +[22:35] * FireRabbit uses the cvs command line port +[22:35] <duck> mihi: I did test it with win9x +[22:35] <jrand0m> tc> have you used cvs before? or are you concerned w/ anonymity? (you should be able to cvs through i2p at the moment) +[22:35] * mihi uses either WinCVS or the cygwin cvs +[22:35] * jrand0m uses cvs.exe +[22:35] <TC> ok, so i use that client and set up the proxy? +[22:35] <TC> no, ive never used cvs before +[22:35] <jrand0m> ok, i'll walk you through the setup after the meeting +[22:36] <TC> sure, thanks +[22:36] <duck> about cvs-ing through the tunnel: +[22:36] <duck> wouldnt the double messages be a big problem? +[22:36] *** Signoff: wiht (Ping timeout) +[22:37] <duck> especially for commits +[22:37] <jrand0m> yes duck, but I haven't run into that problem (cvs messages are typically small) +[22:37] <jrand0m> >64k messages (e.g. the specs .pdf or .sxw) should for now be done through the normal internet +[22:38] <duck> jabber msges get also duplicated quite often +[22:38] <jrand0m> you're right though, in that its not a rock solid solution for cvs yet +[22:38] <duck> even though they are XML, they are not that big +[22:40] <jrand0m> right, lost acks are one of the bitches of the current lost i2psessionimpl2 bugs :/ +[22:40] <duck> k +[22:41] <duck> (that was a partly lost ack) +[22:41] <jrand0m> (with the network this size, there should be no resends ever, unless that the peer is offline) +[22:42] <jrand0m> hmm ok, any other i2p stuff? +[22:42] <mihi> jrand0m: how about adding some kinda sequence number into the i2p packets? +[22:43] <jrand0m> i2ptunnel packets? +[22:43] <mihi> this would help with the doubling things. +[22:43] <mihi> no, i2pnp packets +[22:43] <mihi> okay, one could do it on i2ptunnel level as well. +[22:43] <TC> so jrand0m did you get your conncetion back or are you still at a cafe? +[22:43] <mihi> just if you get twice the same number, disregard the second one. +[22:44] <jrand0m> those already handle dup ids for most things, though you're right in that there's going to be an update on 0.3 for the remaining messages +[22:44] <jrand0m> right, currently we keep a history of the last 1000 msgIds to drop dups +[22:44] <mihi> okay, if anyone volunteers to write a good tcp impl for i2p, that would be better ;) +[22:44] <jrand0m> yes! :) +[22:44] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev +[22:45] * jrand0m thinks there's going to be a bounty for some [yet to be determined killer app/feature] once 1.0 gets near +[22:45] <duck> win a 1 hour private chat session with UserX! +[22:45] <jrand0m> lol +[22:45] <MrEcho> lol +[22:46] <jrand0m> ok, any other i2p things, or iip things, or anything else for this, the 69th iip-dev meeting? +[22:46] <jrand0m> (other than userx pinup girl comments) +[22:47] <duck> any other apps that duck inc. should run? +[22:47] <jrand0m> bluebeep! +[22:47] <TC> 1. jrand0m did you fix your connection issues? 2. what do you think of my new eepsite? +[22:47] <TC> bluebeep? +[22:47] <jrand0m> oh sorry tc. yes, i finally have net access :) haven't seen your new eepsite beyond the board (which kicks ass), but i'll check later :) +[22:48] <duck> TC: I like the new design +[22:48] <TC> hmm, i should change the board as well to cut down on the load time +[22:48] <duck> only think you should try to disable the email function in the phpboard, now you get an error each time +[22:48] <TC> thanks duck +[22:48] <jrand0m> dropping images would be a plus +[22:49] <TC> good idea +[22:49] <jrand0m> (bluebeep is an old wardialer) +[22:49] <MrEcho> ya +[22:49] <jrand0m> (and all around fun toy) +[22:49] <duck> please keep in mind that the average age is 16 here +[22:50] * MrEcho is 24 +[22:50] * duck ducks +[22:50] * jrand0m doubts there are too many 3 year olds to balance out the geriatrics among us ;) +[22:50] *** wiht (anon@anon.iip) has joined channel #iip-dev +[22:50] <MrEcho> lol +[22:50] * TC built a blackbox once +[22:50] <jrand0m> w3wt +[22:50] <lonelynerd> is the meeting already over? +[22:50] <duck> last Q: +[22:50] *** protocol is now known as proto_afk +[22:51] <duck> how can we read the kademlia stats? +[22:51] * jrand0m hasn't !baf'ed yet lonelynerd, so ask away :) +[22:51] * MrEcho kills pcmcia support in the kernel +[22:51] <duck> just so that we understand what routerConsole.html dumps +[22:51] <MrEcho> im getting pissed +[22:51] <jrand0m> ok, the JobQueue stats I assume you mean? +[22:52] * duck guesses that it is all obvious probably +[22:52] <jrand0m> basically when I look at JobQueue stats, I check to see that the avg execution time for the Build garlic message, buld tunnel, and handle * message jobs are small +[22:52] <jrand0m> (those are the jobs that usually take the longest, and when the pending side of things gets large, everything suffers) +[22:53] <lonelynerd> (actually, i better read the logs first) +[22:53] <duck> gotcha +[22:53] <jrand0m> the .1-.6s avg pending time i've been seeing is shit poor and one of the big things i'm going to aim for once its time to tune 'em +[22:54] <jrand0m> the netDb contents liveliness and reliability are largely random numbers, as long as they're > 100. last sent successfully means when was the last time it was sent to 2 or more peers +[22:54] <jrand0m> (we resend randomly if it isn't local) +[22:54] <jrand0m> (no more than once every 5 minutes though) +[22:55] <jrand0m> is there a stat that would be helpful for people, or some other visualization that might help? (if its nontrivial i might not throw it in, but if its easy, i probably would) +[22:56] <duck> thanks +[22:57] <jrand0m> any other comments / questions / concerns / frisbees? +[22:59] <jrand0m> in that case +[22:59] * jrand0m winds up +[22:59] * jrand0m *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/69.rst b/i2p2www/meetings/logs/69.rst new file mode 100644 index 00000000..0e97a191 --- /dev/null +++ b/i2p2www/meetings/logs/69.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 16, 2003 @ 22:00 CET +============================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/7.log b/i2p2www/meetings/logs/7.log new file mode 100644 index 00000000..17768cf4 --- /dev/null +++ b/i2p2www/meetings/logs/7.log @@ -0,0 +1,449 @@ +--- Log opened Wed Jul 03 00:33:19 2002 +00:33 <+logger> logging started +00:47 -!- mode/#iip-dev [+o nop] by mids +00:54 < UnDeRToW> hi +00:54 <@mids> hi +01:01 <@nop> ok +01:01 <@nop> hi +01:01 <@nop> welcome +01:01 <@nop> to the 5th meeting I believe +01:01 <@mids> 7th +01:02 <@nop> really +01:02 <@nop> ok +01:02 <@mids> http://mids.student.utwente.nl/~mids/iip/ +01:02 <@nop> wilde you have anonymail +01:02 <@nop> ok +01:03 <@nop> iip 1.1 rc2 will be released pending a few doc changes and me submitting a couple of technical docs for merging with docs +01:03 <@nop> umm, cs and I will work on transforming inform to work with latest version +01:04 <@nop> and we have had a few people try out some security checks on IIP +01:04 <@nop> unfortunately with no success +01:04 <@nop> but +01:04 <@nop> that's the spirit +01:04 <@nop> ;) +01:04 <@nop> anyway +01:05 <@nop> this is not much of a meeting today, but if anyone has anything to add please feel free at the questions part +01:05 <@nop> so... mids, do you have anything +01:05 <@mids> yes +01:05 <@mids> I would like to have a public discussion about the pro's and con's of bots in the public channels +01:06 <@mids> with ArdVark and some others I have had an argument about that +01:06 <@mids> everybody has its personal ideas +01:06 <@mids> and they aren't all compatible +01:06 <@mids> but since we are not here to censor everything +01:06 <@mids> lets discuss +01:06 <@mids> allow me to state the current issue +01:07 <@mids> unless someone already wants to add something +01:07 <@mids> 3 2 1 0 +01:07 <@mids> ok +01:07 <@mids> in #anonymous (and #iip and #help) we have had a few infobots +01:07 <@mids> Herod, camabot and now visix +01:08 <@mids> personally I dont see any good in those things.. since they seem to be only 'abused' for channel flooding +01:08 <@mids> but I understand that my vision on that is biased +01:08 <@mids> based on years of IRC trauma's :) +01:09 < Kyl3> yes but there are some bots that are useful +01:09 <@mids> Where are those bots good for? +01:09 <@mids> . +01:09 < ArdVark> what is defined as channel flooding? +01:09 < UnDeRToW> for what? +01:10 < Kyl3> there are some bots that are used for channel protection +01:11 <@mids> like? +01:11 <@mids> ArdVark: good one... anybody? +01:11 < Kyl3> like my eggdrop on DALnet +01:11 < UnDeRToW> but here is not necesary channel protection +01:11 <@mids> I would say: filling the communication channel with data +01:11 < Kyl3> all custom flood protection +01:11 < UnDeRToW> at least now +01:12 <@mids> Kyl3: true, but with Trent, I don't think that is a real issue here +01:12 < ArdVark> excuse me but please define filling the communication channel with data +01:12 <@mids> re flooding: but I agree that it is very personal what is seen as flood +01:12 <@mids> Kyl3: what is flood in your wording? +01:12 <@mids> communcation channel is irc channel / query window / message window +01:13 <@mids> data = ascii characters on itc +01:13 < Kyl3> so Trent has channel protections built into it? +01:13 <@mids> and filling is putting too much into it +01:13 <@mids> Kyl3: no, not like you mean... +01:13 < ArdVark> no I have seen users place huge paragraphs of words in a channel without any negative response; perhaps a friend of an OP +01:14 < UnDeRToW> I think the best way to control that is some @ on public channels that only go up when a problem appear +01:14 <@mids> ArdVark: big pastes (what is big) is flood to imho +01:14 <@mids> and jesus stating all the bible chapters is too... imho again +01:15 < ArdVark> however mids you have offered no negative responses to some individuals; friends of your perhaps? +01:15 < ArdVark> who paste large paragraphs +01:15 <@mids> maybe friends +01:15 <@mids> maybe I was away +01:15 <@nop> tell you what +01:15 <@nop> the best way +01:15 <@nop> to determine this +01:15 <@nop> is to let ircd determine it +01:15 <@nop> ircd has a flood limit +01:15 <@nop> and if they exceed that +01:15 <@nop> it will kick them +01:16 <@nop> other than that, if you're not intentionally doing it +01:16 <@nop> then what's the problem +01:16 <@mids> still, you can flood very easilly +01:16 <@nop> yes +01:16 <@nop> but intentional is obvious +01:16 <@nop> so if it's intentional +01:16 <@nop> we handle it +01:16 <@nop> if it's not +01:16 <@nop> then go on about our business +01:16 < ArdVark> no too easy to decide someone is intentionally flooding nop +01:16 <@nop> no need for unnecessary drama +01:16 <@nop> but +01:16 <@nop> it's easy to ask people to talk to the bot in a private channel +01:17 <@nop> and if they are belligerent +01:17 <@nop> then most likely you have probable cause of their intentions +01:17 < ArdVark> I disagree +01:17 <@nop> ok +01:17 <@nop> ardvark +01:17 <@nop> please define then +01:17 <@nop> because if we can set boundaries +01:18 <@nop> this argument will be quickly over +01:18 < ArdVark> I have no problem with your ircd flood control notion; I have a big problem with an OP doing the "protecting" +01:19 < ArdVark> OP's may have friends that they permit to "flood"; while others are dealt with differently +01:19 <@nop> yes +01:19 <@mids> I think that your problem is having OPs... +01:19 <@nop> the biased issue +01:19 < CyberLOK1> sorry just saw msg I have been at work +01:19 < CyberLOK1> did I miss meeting? +01:19 < ArdVark> yes my ultimate concern is OP's because of the potential to limit speech mids +01:19 <@mids> CyberLOK1: talking about flooding right now +01:19 <@mids> CyberLOK1: logs: http://mids.student.utwente.nl/~mids/iip/ +01:19 < CyberLOK1> mids thanks +01:20 <@mids> ArdVark: I totally agree on the theoretical side of that +01:20 <@nop> well what about an agent +01:20 < ArdVark> I will continually express my dissent about that issue +01:20 <@mids> but on the practical side... without ops, how to deal with problem users that deny others to speak? (by flooding) +01:22 < ArdVark> OP's are a threat to free speech, end of statement; deciding on flooding by OP's is not objective +01:22 <@mids> then please tell me how you see #anonymous without OPs.. using current available technology +01:23 <@mids> everything is fine... +01:23 <@nop> agent to set a standard +01:23 <@mids> then 10 trouble guys enter +01:23 <@nop> for flooding +01:23 <@mids> and start spamming crap +01:23 <@mids> what is your solution ArdVark ? +01:24 < ArdVark> spam is an emotionally laden term used to point out speech other's, perhaps most others do not like; free speech is not just about speech I like +01:24 <@mids> so these 10 guys paste #####'s with the maximum rate that the ircd allows +01:25 <@mids> resulting in nobdy beeing able to see any text +01:25 < UnDeRToW> but an oper can go up when a problem occur +01:25 < UnDeRToW> and the rest of the time down +01:25 < ArdVark> and the point is that these guys are going to remain forever? +01:25 <@mids> UnDeRToW: that is how it is now +01:26 < UnDeRToW> i know +01:26 < UnDeRToW> and if someone do a bad thing +01:26 < UnDeRToW> or an oper do bad thing +01:26 <@mids> ArdVark: why not.. they have a botnet with 100 t3 connections +01:26 < UnDeRToW> talk and he/she know his error +01:26 < UnDeRToW> and if persist +01:26 < UnDeRToW> no more @ +01:27 < ArdVark> well I sense a real threat to free speech concern surrounding this issue +01:27 < UnDeRToW> but at least now any problem related with that, isnt it? +01:28 <@mids> okay, I have a proposal +01:28 <@mids> maybe we should try a period without any operators in #anonymous +01:29 <@mids> few weeks +01:29 <@mids> and see how it goes +01:29 <@mids> fix topic to something static +01:29 <@mids> channel mode +tn +01:29 <@mids> and everybody removed from the trent access list +01:29 <@nop> you know +01:29 <@nop> this is really not fair +01:29 <@nop> people are missing the point +01:30 <@nop> IRC has a ruleset, and channel control and all this other shit +01:30 <@nop> I understand the nature of freedom of speech +01:30 <@nop> but we also have to have some sort of defense +01:30 <@nop> flooding can cause problems on networks +01:30 <@nop> etc +01:30 < wilde> but what's the problem really? anyone is free to open a new channel and get ops? So why is ops a bad thing in #anonymous? Open a new channel and speak freely +01:30 <@nop> you can't say that's speech, really, it's 1's and 0's being abused +01:30 < ArdVark> I disagree nop +01:30 <@nop> the founders of specific channels, they have a choice to control the channel +01:31 <@nop> if they want the #freespeech channel +01:31 <@nop> then so be it +01:31 <@nop> because then +01:31 <@nop> you can flood it +01:31 <@nop> all you want +01:31 <@nop> and call it #freespeech +01:31 <@nop> the technology provides the freedom +01:31 <@nop> but the channel holders might not +01:31 <@nop> and this is the design +01:31 <@nop> you have choices +01:31 < ArdVark> I must express my complete dissent officially +01:31 <@nop> and all the choices range +01:31 <@nop> and that's the freedom of choice +01:32 <@nop> is that if you say I disagree, I can't say, no you must agree +01:32 <@nop> but in a founder's channel +01:32 <@nop> I can say +01:32 <@nop> we take this as flooding +01:32 <@nop> we're not an op on every channel +01:32 <@nop> and if there is concern +01:32 <@nop> then there is concern +01:32 <@nop> but #anonymous is public +01:32 <@nop> which requires some governing of very basic rules +01:32 <@nop> because everyone must have a chance to speak +01:32 <@nop> but flooding, interpreted or not +01:33 <@nop> is not going to be tolerated +01:33 < ArdVark> well again I dissent +01:33 <@nop> that just wouldn't make sense +01:33 <@nop> it's like saying +01:33 <@nop> I have the freedom to kill 10 people +01:33 < UnDeRToW> but nop, and all people without op and if someone start flooding just go up and fix the prob +01:33 < UnDeRToW> and then go down +01:33 <@nop> yes +01:33 <@nop> that's fair +01:33 <@nop> but +01:33 <@nop> the interpretation +01:33 <@nop> is the challenge +01:33 <@mids> UnDeRToW: thats what we all minus ardvark are saying... +01:33 < ArdVark> because I was accused of causing flooding when someone else pasted large paragraphs into channel previously was not admonished +01:34 < CyberLOK1> are we tring to justify flooding? +01:34 <@nop> I agree with Ardvark's view in the sense that he may be executing his free speach +01:34 <@nop> speech +01:34 <@nop> but the interpretation seems to be biased +01:34 <@nop> and to solve that +01:34 <@nop> we need to have a standard +01:34 < UnDeRToW> mids i know +01:34 <@nop> but we can't just allow flooding +01:34 < ArdVark> OP's are inconsistent in their approach; let friends do stuff and others not +01:35 < CyberLOK1> how about a control on the number of people and a throttle of max sends per second +01:35 < CyberLOK1> this way it would be impossible to flood people for to long and it would really do nothing +01:35 <@nop> hmm +01:36 <@nop> it's not really an issue that much +01:36 <@nop> and we might be a little sensitve +01:36 < CyberLOK1> ArdVark remove the human part then +01:36 <@nop> because we're used to public irc +01:36 <@nop> and the biased ness is an issue +01:37 <@nop> I say +01:37 <@nop> that unless it's seriously obvious script kiddie flooding +01:37 <@nop> then we just leave it be +01:37 <@nop> and at the most +01:37 <@nop> we can ask questions or ask politely if they will talk to the bot in a private channel +01:37 < ArdVark> problem with flooding is what if no one is talking in channel? suddenly I just type a lot; since no one else is talking I am not infringing on anyone else's speech +01:37 <@nop> no you're not +01:37 <@nop> and you should be allowed +01:37 < ArdVark> well that was the issue the other day +01:38 <@mids> aprogas asked you to stop +01:38 <@mids> but you didnt see it +01:38 <@mids> because of the bot output I think... +01:38 <@nop> well +01:38 <@nop> I think if aprogas asks to stop +01:38 <@nop> he should do it privately +01:38 <@nop> then he should see it +01:38 <@nop> unless he's running certain irc clients +01:38 <@mids> depends +01:38 <@nop> but that's another issue +01:38 <@mids> lot of people dont check private messages +01:38 < ArdVark> he cann do it privately, but I sense I need not stop because of his/her request +01:39 < ArdVark> if no one else is talking +01:39 <@mids> he was talking +01:39 < CyberLOK1> mids ignorance is not an excuss +01:39 < CyberLOK1> sorry spelling +01:39 <@mids> now you dont want to stop +01:39 <@mids> how much talking is needed for you to stop? +01:39 < ArdVark> once again we have Aprogas a friend of an OP being supported by that OP +01:39 < ArdVark> therein lies the problem +01:40 <@mids> I understand your point +01:40 < ArdVark> a threat to me who is no friend to the OP's and my speech +01:40 <@mids> but I dont see a solution, except that you create your own channel with your rules +01:41 < ArdVark> well why tell me to create one, why not tell your frend instead? +01:41 <@mids> we created #anonymous +01:41 < CyberLOK1> um how about 1 bot in each created channel that is oped.. then when a script kiddie flood is detected it protects the channel +01:41 < ArdVark> see how it goes back to problem with OP's and their friends +01:41 < CyberLOK1> then there is no more issue... no one is opped only 1 person and its not even a person so no one can claim biad +01:41 < CyberLOK1> bias +01:42 <@nop> but the programmer writes the biasedness +01:42 < ArdVark> right +01:42 < CyberLOK1> nop basic rules +01:42 < CyberLOK1> if channel == lines per sec +01:42 < CyberLOK1> if this many people are comming and going +01:42 <@nop> hmm, mids can trent do this +01:42 < CyberLOK1> then +01:42 < CyberLOK1> lock channel kick out people flooding above this much +01:42 < CyberLOK1> timeout at predefined +01:43 <@mids> nop: technically yes, but I dont want trent to snoop on all channels +01:43 <@nop> good point +01:43 <@nop> what about just for #anonymous +01:43 < CyberLOK1> well it would eliminate this "bias" +01:43 <@nop> which is "THE" pub channel +01:43 < CyberLOK1> I mean +01:43 < CyberLOK1> lets face a fact here +01:44 < CyberLOK1> you take risk running to the street shouting your words +01:44 < CyberLOK1> here you risk maybe we all are out to get you and record what you say +01:45 < CyberLOK1> risk is all of life and if they can not deal with "snooping" (which its not but hey) then tell um to get out thier banners and head to the street +01:45 <@nop> no +01:45 <@nop> no snooping +01:45 <@nop> we don't want snooping +01:45 <@nop> the argument is not of this +01:45 < CyberLOK1> nop anyone and anything can snoop +01:45 <@nop> it's that #anonymous is a pub channel +01:46 <@nop> what I'm saying is +01:46 <@nop> we're not going to abuse the power of trent +01:46 <@nop> and become the gov't +01:46 < CyberLOK1> ahhh +01:46 < CyberLOK1> kk well +01:46 <@nop> that's hardly called for +01:46 < CyberLOK1> we can form "public" channel groups +01:46 < CyberLOK1> this consists of channels formed by people +01:46 < CyberLOK1> who dont want ops anymore but want thier channel protected +01:47 < CyberLOK1> and there for it would be a self election +01:47 < CyberLOK1> an "option" +01:47 < CyberLOK1> this way no one choice is taken away +01:47 < CyberLOK1> and you could use trent to protect the anonymous channel as an example +01:47 <@nop> just trent for #anonymous because #anonymous is founded as the Public channel on IIP +01:47 < CyberLOK1> others can leave it to op wars and other such nonsense +01:47 <@nop> the rest is not trent's duty +01:48 <@nop> look +01:48 < CyberLOK1> nop I was thinking +01:48 < CyberLOK1> I want to form a channel +01:48 < CyberLOK1> but I myself dont want to deal with ops and yada +01:48 < CyberLOK1> I want just like you guys freedom of speech +01:48 <@nop> ardvark I understand your concern, it makes complete sense, but without a solution or idea from you, I need to know what can be done +01:48 < CyberLOK1> unless I would be allowed to run a bot in my channel +01:48 <@nop> do you have a proposal +01:48 <@nop> and/or can you offer one by the next meeting +01:49 < ArdVark> well if you are using trent to "control" #anonymous, can you please always place in the topic or have an intro for each user? +01:49 < ArdVark> to let them know of this +01:49 <@nop> I don't think we will do this +01:49 <@nop> but if we could have a proposal from you +01:49 <@nop> by next meeting +01:49 <@nop> on what ideas you think would be acceptable +01:50 <@nop> then that can be accepted and we can work it out so that it make everyone happy +01:50 <@nop> we are just trying to protect the network as well +01:50 <@nop> and that's the stance I'm coming from +01:50 <@nop> so that everyone can use it efficiently +01:50 < CyberLOK1> foofd time +01:50 <@nop> and I want to respect the freedom of speech as well +01:50 < ArdVark> nop I believe that must be worked out over time, I cannot promise in some business-like fashion a solution for next time +01:50 < CyberLOK1> here here nop +01:50 <@mids> okay, thanks for dropping by CyberLOK1 +01:50 <@nop> ok +01:51 <@nop> that's fair +01:51 < CyberLOK1> np mids +01:51 <@nop> but let's just work it out +01:51 <@nop> then +01:51 <@nop> the hard fact is +01:51 <@nop> we're humans +01:51 <@nop> and a community +01:51 <@nop> so it' s a challenge to not want to control +01:52 <@nop> but I need a pseudo-utopia idea, but someone has to defend the utopia as well +01:52 < ArdVark> no too many people are used to irc OP's where if you dissent with them you are kicked +01:52 <@nop> ok +01:52 < ArdVark> so if I dissent with an OP kicking someone +01:52 <@nop> I understand the complain +01:52 <@nop> complaint +01:52 <@nop> and I believe that this can be a problem +01:52 <@nop> and that no one is perfect +01:52 <@nop> so what we can do is set up a standard +01:52 <@nop> I think that mids idea +01:52 <@nop> of no ops +01:52 <@nop> in #anonymous +01:52 <@nop> for a while +01:52 <@nop> might be a workable solution +01:52 < ArdVark> actually nop most people will not complain, they will just leave and not return +01:53 <@nop> ok +01:53 <@nop> well +01:53 <@nop> no ops for 2 weeks +01:53 <@nop> in #anonymous +01:53 <@mids> I still propose no ops for 2 weeks +01:53 <@nop> and the only, and strictly only time +01:53 <@nop> is if there is without a doubt a malicious attack on #anonymous +01:53 <@nop> by a script kiddie +01:53 <@mids> no +01:53 <@mids> no ops is no ops +01:53 <@nop> ok +01:53 <@mids> then you have to do it right +01:53 <@nop> fair enough +01:54 <@nop> no ops +01:54 <@nop> two weeks +01:54 <@nop> in #anonymous +01:54 <@nop> agreed? +01:54 < UnDeRToW> not agree with no ops +01:54 <@nop> all say I +01:54 <@nop> we can vote can't we +01:54 < UnDeRToW> one op only for big problems +01:54 <@nop> that can't be done +01:54 <@nop> it would still have biased +01:54 <@nop> it's just 2 weeks +01:54 <@nop> worse case scenario we deal with it +01:54 <@nop> and measure it out +01:55 <@nop> and say +01:55 <@nop> is it worth it +01:55 <@nop> in 2 weeks +01:55 <@nop> ardvark +01:55 <@mids> it would be an experiment, maybe with very interesting results +01:55 <@nop> will that satisfy you for this temporarily till we can look at better options +01:55 < ArdVark> OK +01:55 <@nop> ok +01:55 <@nop> done +01:55 < ArdVark> thanks +01:55 <@mids> great +01:56 <@mids> now what topic do we use? +01:56 <@nop> the one that's up there +01:56 <@nop> ;) +01:56 <@mids> ok, do you remove everyone from the access list? +01:58 <@nop> can you please mids +01:58 <@nop> for two weeks +02:00 < ArdVark> however I really do not think we have resolved the issue of what is flooding; and the implications therein +02:00 < ArdVark> if you want to talk about what the network can handle +02:00 < ArdVark> cause I understand programs have limitations +02:01 <@mids> (#anonymous accesslist is clear) +02:01 < ArdVark> but have you ever been in #anonymous when the conversation is fast a furious +02:01 < ArdVark> some people words pass by without being readable for me +02:01 <@mids> yes, then I think that the normal typing exceeds the ircd floodrate :) +02:02 < ArdVark> how is that different from so called spam or flooding? +02:02 < AgentDelta> a hypothetical question, i hope i'm not out of line... if there was some kind of strong authentication system to authenticate to a known anonymous user with a micropayment account attached so users pay for breaking specified behavior, would that address flooding concerns? how difficult would it be to integrate such an api into the system? +02:02 <@mids> AgentDelta: like hashcash for instance? +02:02 <@mids> AgentDelta: not.. spam is also personal judged +02:03 < wilde> Freedom of speech isn't equal to forcing people to listen, #anonymous is general place for chat, but if you want more freedom you should start your channel and discuss what you want and with as many sentences as you like per second +02:03 <@mids> s/agentdelta/ardvark/ +02:03 < ArdVark> I agree mids, spam is personal +02:04 <@mids> AgentDelta: and so it flood... even the flood that the ircd denies... some human picked the values for it +02:04 < Neo> wilde: yeah, then you OP your own rules in your own channel. +02:04 < ArdVark> look, I have no problem with people having their own channels with their own rules; so be it +02:04 < ArdVark> #anonymous was started as I remember for anonymous free speech +02:05 < AgentDelta> if the channels aren't owned, i guess you have the tragedy of the commons +02:05 < ArdVark> commons is not a tragedy +02:06 < AgentDelta> no, commons isn't a tragedy, but it doesn't have a specific owner who looks out for it +02:06 < AgentDelta> and litter and other artifacts of this absence of an owner is called the tragedy +02:07 < Neo> the commons can become a tragedy, and that is why we are talking about how to deal with people who flood the system and could turn #anonymous into nothing but a flood zone. +02:07 < AgentDelta> ok +02:07 < ArdVark> you mean like someone to be "accountable" AgentDelta? Using the economic view of life +02:08 < AgentDelta> no, "accountable" implies accountability to some outside power. if i own this piece of land, i'm going to keep it in good shape for my own selfish reasons +02:08 < Neo> AgentDelta: no, accountable could mean accountable to internal users of the system. +02:09 < Neo> We were thinking about forum mentors for DC forums. +02:09 < Neo> They are not all powerfull channel dictators, +02:09 < Neo> but if they censor people, they will be held accountable to the users of the system. +02:09 < AgentDelta> explain +02:09 < Neo> So if mids is the op of #anonymous and he abuses op power, then he can get removed of his status, +02:10 < Neo> and he also suffers reputation damage. +02:10 < Neo> So someone that is impartial controls true FLOODING and real abuse of the system by users. +02:10 < AgentDelta> ok, so you have some stated standard of under what strict circumstances someone could be silenced, and if someone uses op powers demonstrably outside of the listed guidelines, he loses op status? +02:10 < wilde> Actually I think this discussion is really not a big thing, everyone is free to start their own moderated/unmoderated channels, if this is a battle of the #anonymous channel I think most users agree that this general chat channel is best without flooding or promotion of child porn for example, so some minimal control is needed +02:11 < ArdVark> I disagree wilde +02:12 <@mids> AgentDelta: yes, but now the channel founders are free to choose their standards +02:12 < AgentDelta> absent some mechanism to establish order, the most powerful takes control over any place, physical or virtual, and i submit in an irc channel, flooders and spammers are the most powerful. +02:13 < AgentDelta> the sheer volume of noise can overwhelm any logical argument +02:13 < AgentDelta> hehe +02:13 <@mids> AgentDelta: but what is noise? :) +02:13 < ArdVark> noise has it's value too +02:13 < AgentDelta> that's true, +02:14 < AgentDelta> you could have a channel with so much noise in it that you can insert stenographic data that is'nt obvious +02:14 < wilde> ArdVark: You say you disagree, but on what? +02:15 < ArdVark> wilde I will just stand on that statement for now, sorry +02:15 < AgentDelta> an anonymous channel with a constant stream of noise seems to serve an entirely different purpose from an anonymous channel with expectation of real-time communication to/from other minds +02:15 < Neo> The issue right now is not about noise. +02:15 < AgentDelta> maybe it needs a separate channel for anonymous communication for a general purpose, and anonymous communication for conversation +02:15 < Neo> It is about abuse of the #anonymous channel from users flooding the system. +02:15 < wilde> ArdVark: you're arguments are brilliant +02:16 < wilde> s/you're/your +02:16 <@mids> Neo: and (potential) abuse of operator power +02:16 <@mids> anyway, I am going to sleep.. thanks for dropping by. The channel logs are and will be available on http://mids.student.utwente.nl/~mids/iip/ +02:20 < ArdVark> is the meeting over? guess so +02:21 < Neo> yeah, got quiet in here. +02:21 < ArdVark> nice discussion all, see you in #anonymous +02:22 < UnDeRToW> time to sleep +02:22 < UnDeRToW> bye everybody +02:22 < Neo> l8r +02:22 < UnDeRToW> nop +02:22 < UnDeRToW> i will start with the translation of new docs soon +02:22 < UnDeRToW> see you +02:22 < UnDeRToW> bye +10:12 -!- UserX_ is now known as UserX +--- Log closed Wed Jul 03 10:29:14 2002 diff --git a/i2p2www/meetings/logs/7.rst b/i2p2www/meetings/logs/7.rst new file mode 100644 index 00000000..dc72e56e --- /dev/null +++ b/i2p2www/meetings/logs/7.rst @@ -0,0 +1,9 @@ +I2P dev meeting, July 3 2002 +============================ + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/70.log b/i2p2www/meetings/logs/70.log new file mode 100644 index 00000000..e602bfd4 --- /dev/null +++ b/i2p2www/meetings/logs/70.log @@ -0,0 +1,158 @@ +[22:01] <jrand0m> 0) hi +[22:01] <jrand0m> 1) administravia +[22:01] <jrand0m> 2) dev status +[22:02] <jrand0m> 3) services on i2p +[22:02] <jrand0m> 4) app status [ns, im, i2ptunnel, ...] +[22:02] <jrand0m> 5) ??? +[22:02] <thecrypto> wow, i picked a good time +[22:02] <jrand0m> 0) hi +[22:02] <jrand0m> yes you did thecrypto :) +[22:02] <jrand0m> hi +[22:02] <jrand0m> welcome to meeting 70 +[22:02] <TC> woot +[22:03] <jrand0m> 1) administravia +[22:03] <thecrypto> w00t! +[22:03] <jrand0m> mailing list, get on it for announcements / discussion / etc: (Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/ +[22:04] <jrand0m> bugzilla: tell me where shit is broken (and perhaps look for ways you can help! :) (Link: http://i2p.dnsalias.net/bugzilla/index.cgi)http://i2p.dnsalias.net/bugzilla/index.cgi +[22:04] <jrand0m> i think thats it for administravia +[22:05] <jrand0m> (note that i'm just talking i2p stuff here, i don't see any iip things on the agenda) +[22:05] <jrand0m> 2) dev status +[22:05] <jrand0m> 0.2.3 as originally released had a chunk of bugs, so there have been perhaps a dozen subsequent builds, but none quite stable enough to be called 0.2.3.1 yet +[22:06] <jrand0m> i'm rebuilding the tunnel management subsystem now, since that is the source of the bugs and 0.3 (scheduled for jan 1) needs the new pooling tunnel manager anyway. +[22:07] <jrand0m> making good progress on that, I'm hoping it'll be ready for use in the next day or two (i'm testing it now) +[22:07] <jrand0m> a description of whats up with that is on (Link: http://wiki.invisiblenet.net/iip-wiki?TunnelManagement)http://wiki.invisiblenet.net/iip-wiki?TunnelManagement +[22:08] <jrand0m> duck among others have been incredibly helpful in submitting bugs, logs, and helping track down a ton of problems and memory / cpu issues. +[22:08] <jrand0m> y'all rule, I really appreciate the help +[22:09] * thecrypto pulls out the "APPLAUSE" sign +[22:09] <jrand0m> ;) +[22:09] <jrand0m> the # of routers have also been increasing... on avg we're at around 9-12 +[22:09] <jrand0m> (up from 3-5 a week ago, and 6-8 in 0.2.2 times) +[22:10] <jrand0m> the next release will improve the reliability dramatically +[22:10] <jrand0m> (aka it won't get out the door until it does) +[22:10] <jrand0m> ok, 3) services on i2p +[22:11] <jrand0m> fillament started hosting his flog on i2p :) +[22:12] <FillaMent> and I've got another trick up my sleeve =) +[22:12] <jrand0m> ooOOoo :) +[22:12] <luckypunk> tw +[22:12] <luckypunk> hm +[22:12] <luckypunk> hello. +[22:12] <luckypunk> Does it work yet? +[22:12] <jrand0m> duck started a new irc server on i2p with dcc disabled (for security reasons) plus some ident-ish features +[22:13] <luckypunk> lol +[22:13] <jrand0m> luckypunk> people with 350Mhz machines will need to wait until 0.3 is out before being able to use it effectively ;) +[22:13] <luckypunk> yes, but is i2p reliable enough for that? +[22:13] <jrand0m> (but subscribe to the i2p mailing list so you can get announcements) +[22:13] <luckypunk> i overclocked to 377 +[22:13] <luckypunk> does that help? +[22:13] <luckypunk> lol +[22:13] <jrand0m> i was chatting on that irc server the other day, until my irc client b0rked +[22:14] <jrand0m> but yes, things are a bit unreliable at the moment while the tunnel management subsystem is rebuilt +[22:14] <luckypunk> well, im happy my computer didn't molassify overnight again. +[22:15] <jrand0m> any other new services i've missed? +[22:15] <luckypunk> well, when .3 comes out...t here'll be a yahooish service. +[22:15] <luckypunk> ;) +[22:15] <jrand0m> cool +[22:15] <TC> i should run somthing else +[22:16] <TC> whats a service we need that doesnt require messing with apache? +[22:16] <jrand0m> your bbs is kick ass tc, i just can't wait until i2p is reliable enough for me to get to it consistently +[22:16] <jrand0m> you could run a telnet based games server (e.g. adventure, etc) +[22:16] <luckypunk> lol +[22:16] <TC> hah +[22:16] <FillaMent> MUSH +[22:17] <luckypunk> i'll do that... it's low demand. +[22:17] <luckypunk> and i already had about 300k of tinymush code. +[22:17] <jrand0m> yeah, the whole mush/mud/moo/ style thaang +[22:17] <luckypunk> heh +[22:17] <TC> what about ultima online? +[22:18] <thecrypto> ooh that's be fun +[22:18] <luckypunk> "Slay FreeNet Databugs!" +[22:18] <luckypunk> TC: =| +[22:18] <thecrypto> we need to get a telnet client then +[22:18] <luckypunk> maybe if we all obtained 6 ghz computers with oc-128 lines. :D +[22:18] <jrand0m> thecrypto> /bin/telnet + i2ptunnel +[22:18] <thecrypto> ...yeah +[22:18] <thecrypto> i'm sloew +[22:19] <thecrypto> :) +[22:19] <jrand0m> any other low hanging fruit for services? a mail server (pop3/imap without internet mail) would rule +[22:19] <jrand0m> (and if it could /receive/ internet email that'd rule too) +[22:21] <jrand0m> ok, 4) app status +[22:21] <jrand0m> naming service +[22:21] <jrand0m> wiht / co was here earlier, but not now +[22:21] <jrand0m> MrEcho> how goes? +*** MrEcho is echo@anon.iip (Digital_Light) +*** on channels: #iip-dev #anonymous +*** on irc via server anon.iip (Official IIP ) +*** MrEcho has been idle 3 minutes, signed on at Thu Jan 01 01:00:00 1970 +[22:23] <jrand0m> ok, perhaps we'll get back to that +[22:23] <jrand0m> hosts.txt has been growing as destinations have come online +[22:23] <jrand0m> there's a bot on the jabber server that will let you register / fetch entries +[22:24] <jrand0m> (plus the hosts.txt distributed with new installs is managed in cvs and mirrored at (Link: http://i2p.dnsalias.net/i2p/hosts.txt)http://i2p.dnsalias.net/i2p/hosts.txt) +[22:24] <jrand0m> next up, IM +[22:24] <jrand0m> hi thecrypto :) +[22:24] <jrand0m> welcome back +[22:25] <thecrypto> hi +[22:25] <thecrypto> i2pim is being started from scratch +[22:25] <thecrypto> i need to figure out how this network works but tearing apart ATalk and slowly putting it back together +[22:25] <thecrypto> so it's slowly coming along +[22:25] <jrand0m> word +[22:25] <thecrypto> i don't know if i can get group chat working +[22:25] <thecrypto> but it's an idea +[22:26] <jrand0m> you had mentioned the idea of 'tossing around the baton' style of group chat - not centralized, but still workable... I think that might be a way to go +[22:26] <thecrypto> it might involve some difficult baton passing to get it, but if anyone has an idea for how to do group chat under my model, e-mail the list i just signed onto +[22:26] <jrand0m> hehe +[22:26] <jrand0m> cool +[22:27] <jrand0m> yeah, starting off with one on one (perhaps with send/receive file) would probably be prudent +[22:27] <thecrypto> yeah, the only problem would be syncronizing the baton will be difficult +[22:27] <thecrypto> because you don't want 2 people grabbing the baton at the same time, or have the person who has the baton to drop of then et +[22:27] <thecrypto> nety +[22:27] <TC> token-ring-chat? +[22:27] <jrand0m> yup, voting systems are a pain. +[22:28] <jrand0m> right, good ol' 2phaseCommit +[22:28] <thecrypto> TC: no, basically the IM network has no central presence server +[22:28] <thecrypto> so what i'm thinking about doing is have a virtual server baton +[22:29] <duck> ok, using a bootdisk from now on... +[22:29] <jrand0m> the other option is to do group chat fully distributed: "group" just being "send these messages to peer X, Y, Z" +[22:29] <jrand0m> d'oh duck +[22:29] <thecrypto> yeah, but that's network by broadcast +[22:29] <jrand0m> not really +[22:29] <thecrypto> which is usually the stupidest idea +[22:29] <jrand0m> the messages have to get sent to peer X, Y, Z from someone sometime +[22:30] <jrand0m> its actually 1 less message than the (temporary) server based model +[22:30] <thecrypto> yes, but then each person has to keep track of the group +[22:30] <jrand0m> (and the UI can make the group 'pretty') +[22:30] <thecrypto> and now there has to be messages passed around about what the group is current +[22:30] <jrand0m> right, perhaps a control message stating "I think group A is X, Y, Z" +[22:31] <jrand0m> instead of the voting protocol +[22:31] <jrand0m> right, I'm not sure what way is best +[22:31] <jrand0m> just saying there's an option +[22:31] <jrand0m> no lo se +[22:31] <thecrypto> yeah +[22:32] <jrand0m> anyway, if you want a 'product' on bugzilla for i2pim, lemmie know, as well as if theres anything i can do to help +[22:32] <thecrypto> well, i need code for there to be bugs in first +[22:32] <jrand0m> ;) +[22:33] <thecrypto> so wait a bit and i'll have something to put on bugzilla +[22:34] <jrand0m> cool, whenever, its trivial to add +[22:35] <jrand0m> ok, i2ptunnel +[22:35] <jrand0m> i've tossed in two bug-ish things into bugzilla: (Link: http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=1)http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=1 and (Link: http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=2)http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=2 +[22:36] <jrand0m> plus there's a thing wrt some browsers b0rking on missing trailing / +[22:37] <jrand0m> getting sequence numbers into i2ptunnel would be really good, as large transfers sometimes are getting corrupted (missing message thats dropped, but sequence numbers would notice that immediately and fail fast) +[22:37] <jrand0m> other than that, the things are minor, i2ptunnel is behaving a lot better than the router :) +[22:38] <jrand0m> ok, any other apps? +[22:39] <jrand0m> there was some discussion about NAT/SOCKS the last few days on the channel +[22:39] <jrand0m> a socks enabled proxy that would let people ftp, bittorrent, etc would be really great +[22:39] <jrand0m> plus there's the discussion aum started on the i2p list wrt file sharing / cdn +[22:40] <jrand0m> (i swear i didn't tell him to make that post ;) +[22:41] <jrand0m> i probably won't be doing anything on the app side beyond help out integrating with i2p, as there's a truckload of stuff to do in the router, so if you're interested in seeing them show up, get hackin' +[22:44] <jrand0m> ok, thats it for apps +[22:44] <jrand0m> 5) ??? +[22:44] <jrand0m> hi +[22:44] <jrand0m> any comments / questions / concerns / etc? +[22:45] <ardvark> I think everyone fell asleep ;) +[22:46] <jrand0m> someone posted a question to the wiki's FAQ and it got answered after about a day, so if anyone has concerns, either post them there, to the i2p@i2p.dnsalias.net mailing list, ask it in this channel, or spraypaint it on the wall +[22:46] <duck> oh, meeting +[22:46] <jrand0m> yeah, exciting, aint it ;) +[22:46] * jrand0m slings mud at duck +[22:46] * mihi did not follow, sorry. he will stand in the corner for the next 5 minutes... +[22:46] <jrand0m> hehe +[22:47] <jrand0m> ok, thats about it. +[22:48] * jrand0m *baf*s the meeting to a close diff --git a/i2p2www/meetings/logs/70.rst b/i2p2www/meetings/logs/70.rst new file mode 100644 index 00000000..a8e55dc8 --- /dev/null +++ b/i2p2www/meetings/logs/70.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 23, 2003 @ 22:00 CET +============================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/71.log b/i2p2www/meetings/logs/71.log new file mode 100644 index 00000000..a90913b2 --- /dev/null +++ b/i2p2www/meetings/logs/71.log @@ -0,0 +1,330 @@ +<jrandom> 0) hi +<jrandom> 1) router status +<jrandom> 2) i2ptunnel +<jrandom> 3) im +<jrandom> 4) 0.3 plans +<jrandom> 5) time synchronization +<jrandom> 6) ??? +<jrandom> hello mihi, polo +<polo> hello ! +<mihi> hi jrandom +<jrandom> 0) hi +<jrandom> :) +<rsk> hi +<i2p> <duck> hi +<jrandom> 1) router status +<jrandom> 0.2.3.3 is out, and it seems to be working +<jrandom> still lots to do, of course +<jrandom> but this should be the last 0.2 release +<jrandom> 0.3 is going to add the peer profiling to allow routers to avoid bad routers +<jrandom> (and 0.3.1 is a revamp of the transports) +<jrandom> hola Ophite1 +<Ophite1> Heya. +<rsk> so more overhead for 0.3? +<jrandom> yes and no +<jrandom> it will have peer testing, but its going to be more focused +<rsk> will we see a speed up with path selection? +<jrandom> yes +<jrandom> there are those 'liveliness' calculators, and there will be new latency and throughput calculators added +<jrandom> plus people will be able to tweak their own preferences for particular peers +<jrandom> e.g. if you know you want to prefer peer X over peer Y, you will be able to give them a weighting bonus of + some random points +<mihi> will there be a clean shutdown? *g* +<jrandom> thats actually a good question mihi +<jrandom> i2p is getting to the point where it needs an admin interface. +<jrandom> the longest Job thats holding up its operation is the GenerateStatusConsoleJob +<jrandom> which can now take up to 4-6 seconds +<jrandom> (holding everything else up) +<jrandom> that needs to go async and on demand. +<jrandom> but i dont want to write a web listener / etc. +<jrandom> perhaps the reverse - a servlet that starts the router and communicates with it +<mihi> you don't need a full web server. just when you see GET, return your data. +<jrandom> right +<jrandom> you're right, that stuff should be in 0.3 as well. +<mihi> and when you see something else (like SHUTDOWN), do as you please. of course only from localhost ;) +<jrandom> aww c'mon +<mihi> then someone can make a nice admin program +<jrandom> right +<mihi> you had some triggers by files, didn't you? are they documented somewhere? +>>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom +<jrandom> those were in IDN, not the router itself +<jrandom> but that might be a good way to go +<jrandom> its a trivially easy system +<jrandom> good idea, lets go that way +<jrandom> (and i can just reuse that code :) +<i2p> <duck> this magical filestuff starts to look like plan9 +<jrandom> lol +<mihi> but file triggers require polling +<jrandom> right mihi, reading a directory every 30s aint that bad +<mihi> but a ServerSocket#accept is cheaper. +<mihi> as it won't eat any time. (provided a good OS) +<mihi> okay, file triggers are better than nothing, sure. +<jrandom> server socket would allow remote admin +<jrandom> (when appropriate) +<jrandom> dunno. +<jrandom> something to be worked out. +<jrandom> (or if someone wants to jump on it and code... :) +<mihi> and server socket could deliver the routerConsole as well. +<jrandom> right +<jrandom> ok, 2) i2ptunnel +<jrandom> :) +<jrandom> i2ptunnel still rules, and its looking like we want to add a socket based API to control it +<i2p> <anon> aum's ic2cp2pc plans are off for now? +<jrandom> yes, ci2cp is dead in the water, replaced with the socket based API to control I2PTunnel +<jrandom> I think I may be able to throw on that API in the next few days, so he can get churning on the impl +<mihi> just use a socket, make in.readLine() and feed that line to runCommand() ;) +<rsk> what does the api give i2p? +<jrandom> pretty much mihi (except it formats the results and send them back in a standard way) +<mihi> with an appropriate "logger" to send the commands back. +<mihi> s/commands/results/ +<jrandom> rsk> it lets application developers build client and server sockets over i2p without dealing with I2CP's + encryption needs +<jrandom> right right +<jrandom> i2ptunnel /does/ have an overhead for situations where there are lots of i2ptunnels +<jrandom> regardless of the JVM +<jrandom> i2ptunnel clients create a new destination per client contacted, and the router will perform much worse as + the number of local destinations grows. +<rsk> ah +<jrandom> this is due to the anonymity needs of the network tied to how our encryption works +<jrandom> for applications who just want to open a tunnel or two to a peer, this new api will RULE +<jrandom> but for applications that need to talk to lots of other peers, I2CP is the way to go. +<jrandom> (since that is a single destination, multiplexed by i2cp) +<jrandom> I suppose its the old TCP vs UDP balance, in a way +<jrandom> mihi> do you have any thoughts, or some ideas for the future of i2ptunnel? +<rsk> hows the work on the ip over i2p, or the vpn stuff going? +<mihi> jrandom: someone write a good streaming api, and then lets i2ptunnel use it. +<mihi> same for naming server. +<mihi> perhaps add some sequence numbers if no one does the things above. +<mihi> which will mean an incompatible change. +<jrandom> incompatible changes aren't bad, we're early in dev +<jrandom> (if we could increase the size of of the IDs too to two or four bytes per side as well?) +<mihi> the streaming api will be an incompatible change nevertheless. and if i2p worked, we don't need sequence + numbers. +<jrandom> rsk> on hold, until someone has time to run with it? +≡ rsk/#i2p thinks incompatible chages are the best kind +<jrandom> right mihi +<mihi> ID should be 3 byte atm, so why *increase* to 2 bytes? +<jrandom> mihi> actually, I'd like to slowly deprecate mode=GUARANTEED and implement that in the streaming api +≡ mihi/#i2p too +<jrandom> leaving i2p = IP, not TCP or UDP +<jrandom> damnit I wish I had another 14 hours in the day. +<mihi> only 14? ;) +<jrandom> ;) +<jrandom> aren't the 3 byte ids derived by both sides of the con? or maybe i'm just confused +<mihi> each side has an ID of 3 bytes, hovever, only one must be sent at a time. +<jrandom> perhaps I'll implement the streaming API, rip out GUARANTEED, and add that socket controller next. +<jrandom> ah ok +<mihi> see /apps/i2p/i2ptunnel/java/src/protocol.txt +<jrandom> right right +<mihi> btw, who misplaced that file *there*? +≡ jrandom blames eco ;) +<jrandom> wait, naw, you put 'em there +<jrandom> didnt you? +<jrandom> oh wait, no I imported them +≡ jrandom blames self for being stupid. +<jrandom> (la la la) +<jrandom> damn. ok, yeah, working on the streaming API and the socket controller will allow me to mull over the peer + testing / profiling / selection manifesto +<jrandom> I'll post that in a few days for comment +<jrandom> (and it'll get my head out of the router. variety++) +<jrandom> mihi> anything else on i2ptunnel? +<mihi> not that i know +<jrandom> coo' +<jrandom> (thanks again for taking the time to chime in on this stuff, I know you're busy with fiw and the rest) +<jrandom> ok, thecrypto isn't here, but he's making progress on the IM app. +<jrandom> (thats agenda item 3) +<jrandom> 4) 0.3 plans +<jrandom> 0.3.0 ~= peer profiling stuff, and now it'll also include the streaming api and that socket controller for + i2ptunnel +<jrandom> but, if you couldn't guess, its not going to be released on jan 1 +<jrandom> jan 15 is an outside possibility. we'll see how things go. +<jrandom> 0.3.1 isn't a full month of work, so it may not need to get bumped. +<jrandom> other than that, the roadmap is still pretty much on track and representative of where we're moving +<jrandom> 5) time synchronization +<jrandom> a new faq is posted at http://wiki.invisiblenet.net/iip-wiki?I2PTiming +<jrandom> mihi, you had a suggestion about the fourth option there (building our own in-i2p timing)? +<jrandom> hi brawl +<mihi> yep. +∙φ∙ brawl is now known as eco_ +<eco_> hi guys +<jrandom> oh heya eco +<mihi> you should connect 3 random nodes and remember the diff between the avg time and local time. +<jrandom> we just discussed the streaming API / tunnel api +<mihi> and then hack up your own getTimeMillis that corrects that. +<Ophite1> mihi: No, you shouldn't. +<jrandom> mihi> so if an attacker creates 1000 nodes with the wrong time, everyone gets screwed +<jrandom> (since avg would skew randomly in between) +<mihi> if an attacker creates 1000 nodes, everyone gets screwed anyway...? +<rsk> wouldnt that be self corecting? +<Ophite1> mihi: OK, 3. +<jrandom> no, we should be able to handle that mihi. +<mihi> okay, then only use avg, if standard deviation is lower than 1sec or so. +<rsk> if everyone has the same time your ok, even if that time is wrong, right? +<jrandom> rsk> if all 1000 nodes were in sync, but what if they're all random +<mihi> only use times that are close enough together. if not, take 3 new nodes. +<jrandom> mihi> right, we could implement NTP (which basically does what you say, using a series of candidate averages + to iteratively close in on the correct time +<mihi> but we need not care of everything (like ping latencies), as ntp does. +<Ophite1> if we did not, mihi, time would slowly creep backwards. +≡ mihi/#i2p thinks that is better than let users set their time individually. +<jrandom> so anyone who randomly picks 3 of those skewed nodes gets sent onto their own private network? +<jrandom> what about that third option - +<jrandom> i2p has a component that checks with a real NTP server via NTP or SNTP +<mihi> if you have only skewed notes in your netDB, you are on that private net as well... +<jrandom> rather than reimplementing the wheel +<Ophite1> while I partially like that one... +<Ophite1> NTP isn't signed, it's subject to an MITM attack. +<Ophite1> or dns cache poisoning for, say, time.nist.gov +<jrandom> right Ophite1, though with 200,000+ SNTP or NTP hosts, thats a large set to attack. +<jrandom> we would definitely not sync of time.nist.gov. +<Ophite1> connections from i2p to the NSA's time server might raise a few eyebrows, ne? :) +<jrandom> and if an attacker goes after time.nist.gov, everyone everywhere is affected +<jrandom> heh +<mihi> then we combine both. ask a "real" ntp server and your neighbor. if both say the same, it's okay. +<jrandom> so even /more/ code ;) +<jrandom> but yeah, thats reasonable. +<Ophite1> That's interesting. And if they don't? +<Ophite1> pick another ntp server? +<jrandom> refuse the peer. +<mihi> try other ntp server and another peer. +<mihi> until you have a match. then refuse all prev peers. +≡ mihi/#i2p types slower than jrandom :( +<Ophite1> match within a certain threshold, say 1sec? +<jrandom> 1s would be good. +<jrandom> accepting peers up to 30s or so (to deal with lag) +<Ophite1> is 1 sec okay on HEAVILY LADEN connections? +<jrandom> 1s for syncing, 30s for comm. +<Ophite1> I've seen latency on DSL get to 5 seconds when doing evil things to it. +<jrandom> with tcp or udp? +<Ophite1> but then, in that case, that host might not be the one you want to sync time to anyway ;) +<jrandom> right +<Ophite1> udp. +<jrandom> hmm 'k +<Ophite1> you'd have thought it'd get dropped :) +<i2p> <duck> I think that the problem is more letting the user know that there is a problem +<jrandom> duck> that is true. +<i2p> <duck> only after walking through big logs they see that their clock is off (if they find it) +<Ophite1> Maybe. Sort of. +<i2p> <duck> or that the port is already bound +<jrandom> an admin interface would be nice. +<i2p> <duck> the world is better with everybody using NTP connected to their local stantrum (sp) 2 server +CTCP Cloaking is now [On] +<jrandom> perhaps we'll have a 0.4 release with a bunch of cleanups and end user things, prior to going 1.0? +<jrandom> right (stratum) +<i2p> <duck> only windows clients are not likely to have that +<i2p> <duck> but they are also not likely to be stable +<jrandom> windows has NTP +<i2p> <duck> so who cares +<Ophite1> duck: Windows XP and Windows Server 2003 include NTP. +<jrandom> a shitload easier than with unix too +<Ophite1> sync'ed by default to time.windows.com iirc. +<jrandom> with drop down options for others +<Ophite1> It's an essential part of Windows Product Activation. +<Ophite1> can't expire if you don't know the time :) +<jrandom> heh +<mihi> no option at my university... all clocks are 1 hour to 5 hours off. but i might not be allowed to run i2p there + anyway... +<Ophite1> mihi: i2p should try especially hard to work in such a situation... +<jrandom> mihi> awesome! you can help test out the hidden operation :) +<jrandom> as an aside, I'm going to be doing some traveling this summer +<jrandom> i'll likely be offline, without my laptop. +<i2p> <duck> sidethought: ntp.duck.i2p :) +<Ophite1> Look at it like this: Brianna Kazaa downloads cool new anonymous filesharing client which her best friend + told her was really cool and lets you chat to people secretly and stuff. Do we want to tell her that she + needs to set her clock within 30 seconds (how will she get some?)? Or do we want it to just work? +<jrandom> but I'm going to make sure I can still be on I2P with just public terminals. +CTCP Cloaking is now [Off] +<jrandom> no brainer Ophite1. just work (with docs for geeks) +<jrandom> duck> bootstrap ;) +<jrandom> and i2p will /not/ require root. +<Ophite1> That's my point. +<Ophite1> jrandom: would you run a router on a box you didn't have root to? +<jrandom> so yeah, a mix between option 3 and 4 +<Ophite1> option 3.5 sounds cool to me ;) +<jrandom> Ophite1> i'd run a hundred of them :) +<mihi> option 3.1415926... +<jrandom> (and move on to the next lab, run a hundred more) +<Ophite1> Ooh. Pie. Tasty.;) +<Ophite1> jrandom: I said you didn't have root on. Amateur. :) +<jrandom> lol +<jrandom> so thats basically where we're looking. +<jrandom> until the time stuff is implemented, everyone should use option 1 or 2. +<jrandom> for option 2, if someone could write up some docs, I'd appreciate it +<Ophite1> that's acceptable for now as we are Not Yet Ready for Brianna Kazaa et al ;) +<mihi> jftr: i won't test "hidden operation". my univ account has already been disabled once and i don't want it + another time blocked... +<Ophite1> mihi: You are the best test we could possibly have. +<jrandom> Ophite1 > not for test. +<jrandom> 'k mihi, we'll find a way, and once its ready you'll be able to use it. +<Ophite1> OK, maybe not test. Some unis get shirty enough to chuck you out rather than just block you. +<Ophite1> I know someone at the most anti-filesharing pro-RIAA university in the USA. He runs a 2gbit dumpsite. +<jrandom> lol nice +<Ophite1> I appreciate that very, very few people are this ballsy. +<jrandom> ok, thats it for time synchronization. +<jrandom> eco_> hi. any bt stuff you want to talk about? {or save till next week} +<Ophite1> but bear in mind the majority of the internet is in future probably going to become university/corporate. + i2p might be banned. i2p might WELL be considered abuse by major ISPs. i2p will have to work anyway. +<Ophite1> I have a few interesting ideas along that angle I will present at a future date. +<jrandom> word +<Ophite1> (transport) +<rsk> i2p is considered abuse by major ISPs, read your contract +<Ophite1> rsk: running a distributed proxy cache? +<rsk> running any 'server' +<Ophite1> rsk: Not unless it relays to SMTP or WWW. +<jrandom> running services of any time +<jrandom> right +<Ophite1> rsk: Hehe, I have a solution to that ;) +<eco_> jrandom: can give a brief update +<jrandom> floor is yours :) +<eco_> i'm porting the java-based bittorrent client snark (www.klomp.org/snark) to get aquainted with i2p +<eco_> first port runs on top of i2ptunnel, directly calling the java classes +<eco_> current state: does work with 2 peers, things get messed up with > 2, tunnels aren't cleaned up, so restarting + is painful +<eco_> eta: this weekend +≡ eco_/#i2p realises that this might be considered > 2003 +<jrandom> w00t! +≡ jrandom hacks time.nist.gov +<eco_> a "real" port would probably cut the overhead of the tunnels, but that's a next step +<jrandom> cool +≡ eco_/#i2p gives floor back to mc jrandom +<jrandom> 'k, I think that was it +<jrandom> 6) ??? +<jrandom> anyone have anything else? +≡ eco_/#i2p would like to express his thanks for the job well done by jrandom cs up to now +<eco_> and that sleep has some use for home sapiens, though jrandom seems to prove this false +<jrandom> ;) +<jrandom> what are y'all's thoughts on meeting here as opposed to iip, until i2p is reliable enough? +<jrandom> personally, I'm tired of meetings being cut to shreds every week. +<i2p> <anon> lilo sucks! +<eco_> we might be shutting people out by going here +<jrandom> we are, I know. +<jrandom> if we can get an iip<-->here bridge +<i2p> <duck> IIP is shutting ppl out each day +<jrandom> that'd be good. +<jrandom> right. +<jrandom> iip is, unfortunately, unusable for a reliable development community. +<i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html +<i2p> <duck> that is the code where eyeKon etc is based on +<jrandom> and while I like to go off coding on my own, y'all come up with really good ideas and do good stuff that is + essential +≡ rsk/#i2p is writing a windows update script +<i2p> <duck> theoretically it could connect to 3 servers and mirror each of them +<jrandom> word duck, perhaps I'll try to get one running on i2p.dnsalias.net +<jrandom> ping flood from hell ;) +<eco_> irc at duck.i2p was pretty good today, beat iip +<jrandom> agreed +<jrandom> dropped me a few times though. +<jrandom> perhaps it'll be more reliable next week +<eco_> it's in your hands :-) +<jrandom> reliability probably won't improve until 0.3, which is ~2 weeks out +<jrandom> (1 week to do the tunnel/streaming stuff, 1 week for peer profiling / testing) +<jrandom> then there'll be whatever bugs that introduces :) +<jrandom> though I should say I was really excited to stream audio from aum last night +<jrandom> and ardvark was able to stream for 42 minutes without buffering! +<jrandom> so perhaps we can be reliable enough +<jrandom> (my local router is phttp only, which is probably a slight cause) +<jrandom> ok, anyone have anything else? +<i2p> <duck> cant thing of anything +≡ eco_/#i2p can't either +≡ jrandom winds up... +≡ jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/71.rst b/i2p2www/meetings/logs/71.rst new file mode 100644 index 00000000..2082e470 --- /dev/null +++ b/i2p2www/meetings/logs/71.rst @@ -0,0 +1,7 @@ +I2P dev meeting, December 30, 2003 @ 22:00 CET +============================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/72.log b/i2p2www/meetings/logs/72.log new file mode 100644 index 00000000..40292672 --- /dev/null +++ b/i2p2www/meetings/logs/72.log @@ -0,0 +1,653 @@ +[22:02] <jrand0m> agenda: +[22:02] <jrand0m> 0) hi +[22:02] <jrand0m> 1) http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html +[22:02] <jrand0m> 2) [discussion] +[22:02] <wiht> Can I add installer to agenda? +[22:02] <jrand0m> 0) hi +[22:02] <jrand0m> oh yes, certainly! +[22:02] <jrand0m> we're trying something new this week +[22:03] <wiht> You can put it at the end of the agenda. +[22:03] <jrand0m> rather than the old talktalktalkreplytalktalktalk, the http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html post describes most of the things I had planned on saying +[22:03] * mihi_ has joined #i2p +[22:04] <jrand0m> instead, we're trying this week to make the meeting more discussion oriented - things people want to talk about from that post, any follow up posts, and/or anything else people want to discuss +[22:04] <jrand0m> such as a new installer +[22:05] <jrand0m> so, that said, people should start by checking out that email/post and we'll go from there :) +[22:05] * mihi_away is now known as mihi +[22:05] * kaji reads the post +[22:05] * mihi_ is now known as mihi_backup +[22:06] <jrand0m> 27 users with only one dup! w0w +[22:07] * dm is now known as dup +[22:07] <jrand0m> ok, when people have read that, perhaps we can start by going over the index and seeing if there's anything someone wants to add / comment on / discuss? +[22:07] <mihi> jrand0m: where do you know from that there are no more dupes? +[22:07] <jrand0m> heh thanks dm +[22:07] <jrand0m> mihi> I installed keyloggers on everyone's computers (bwhahahaha) +[22:07] <wiht> I would like to add installer as topic 10, and possibly naming service as topic 11. +[22:07] * mihi sent the followup to the wrong address :(, resending... +[22:08] <jrand0m> good call wiht +[22:09] <MrEcho> mrecho's new dns is in the works +[22:09] <jrand0m> cool mihi, yeah I was wondering ;) +[22:09] <kaji> how is dns coming along? - ah +[22:09] <jrand0m> MrEcho> your post, right? +[22:09] <MrEcho> working on the post +[22:10] <jrand0m> ok, in the meantime, anyone have anything on 1) streaming? or should we jump to 2) I2PTunnel, TunnelManager, and i2pmgr? +[22:10] <lucky> good lord... i could spend the rest of my life attempting to figure out these dependecnies. +[22:10] <wiht> So let's say DNS/NS as topic 11. +[22:10] <jrand0m> sounds good wiht +[22:10] * duck walks in +[22:11] <jrand0m> ev'nin duck +[22:11] <mihi> ad 1, i committed code for i2ptunnel using the streaming api +[22:11] <jrand0m> ah right, awesome mihi :) +[22:11] <lucky> hi duck +[22:11] * twosandals has quit IRC (Leaving) +[22:11] <kaji> jrand0m can several sevices use the same key if they are on diffrent ports? +[22:11] <jrand0m> no kaji +[22:11] <mihi> btw: why do your ant files always delete the jar before rebuilding it? +[22:11] <jrand0m> mihi> paranoia +[22:12] <mihi> stealing me time with debugging, i'd say ;) +[22:12] <jrand0m> kaji> in i2p, a key /is/ a port, essentially +[22:12] <jrand0m> heh +[22:12] <kaji> ah +[22:13] <jrand0m> mihi> if you want to update that, as long as it'll build the jar if the class files change thats fine +[22:13] <mihi> if the file is newer than all files in it, and could skip it otherwise. +[22:13] <jrand0m> right +[22:13] <mihi> and for paranoia it is better to add a <depends> task +[22:13] <jrand0m> agreed +[22:13] <FillaMent> yo yo +[22:13] <jrand0m> 'lo FillaMent +[22:14] <jrand0m> ok, 2) i2ptunnel / tunnelmanager / i2pmgr +[22:14] * TC has joined #i2p +[22:15] <human> i did a little hacking to make the TunnelManager return the job ids when "openclient" or "openserver" commands are called +[22:16] <jrand0m> kickass :) +[22:16] <human> this way, apps using the TunnelManager know which job to close later, without parsing the "list" output +[22:16] <jrand0m> yeah, I've not been too comfortable with using tunnelmanager's list and close, since multiple clients can b0rk each other that way +[22:17] <jrand0m> we'll get that patch in there right after the meeting. gracias human :) +[22:17] <human> it involved making I2PTunnel.runCommand return some stuff (currently a Property) +[22:17] <human> s/Property/Properties/ +[22:17] <jrand0m> oh right, there's some things to modify in that before getting it into the code +[22:18] <human> but mihi would prefer to add some asynchronous callbacks to the Logging clas, as far as i understand... +[22:19] <jrand0m> right - so that things can get information from the tasks immediately, without waiting for it to finish +[22:20] * mihi has quit IRC (EOF From client) +[22:20] <human> jrand0m: the idea is: let's I2PTunnel.runCommand() return immediately, and eventually use callbacks to get more info, right? +[22:21] <jrand0m> right +[22:21] <jrand0m> so the tasks fire callbacks whenever there is data to distribute +[22:21] * mihi has joined #i2p +[22:21] <human> well, IMHO there is another question: «how many java apps (will) use I2PTunnel.runCommand() asynchronously?» *All* the apps currently using I2PTunnel (even via the TunnelManager) are perfectly fine with synchronous (even if long) .runCommand() calls, and making all the stuff asynchronous would only make things more complicated (IMHO) +[22:22] * mihi uses it via the gui +[22:22] <human> (well, "all" means the TunnelManager and apps parsing the Tunnel manager output) +[22:22] <jrand0m> right, the gui will hang while the command is executed +[22:22] <mihi> and entering the next 3 tunnel open commands is blocked while the first is running +[22:23] <human> mihi: ok, i didn't know about your app... then we need some solution :-) +[22:24] <human> mihi: asynchronous .runCommand() behaviour would require to revise the TunnelManager +[22:24] <mihi> human: when (iyo) should runCommand terminate? when the tunnel is built, when the connection got through? +[22:25] <mihi> "destination unreachable" will be known *after* the first connection attempt was made. +[22:25] <jrand0m> the command pattern would have the execute() return only after it was complete. +[22:26] <mihi> what does *complete* mean? +[22:26] <jrand0m> (so if we're following the command pattern, runCommand would block until everything required to do that command was complete) +[22:26] <human> mihi: eheh, that's the question :-) +[22:26] <jrand0m> complete for "server 1234 privkeys" would be when the server can accept connections on port 1234 +[22:26] <human> mihi: well, for TunnelServer's IMHO it should return after tunnel creation +[22:27] <jrand0m> complete for "client 234 peer" would be complete when a connection to port 234 would successfully reach peer +[22:27] <jrand0m> at least, thats my take +[22:27] <mihi> how can you determint the latter? +[22:27] <jrand0m> I really don't feel strongly either way +[22:27] <jrand0m> perhaps a ping? +[22:27] * Sciatica has joined #i2p +[22:28] <mihi> and if the peer goes down just after the ping? +[22:28] <mihi> imo it is impossible to do network apps without callbacks +[22:28] <jrand0m> right +[22:28] <mihi> or lotsa threads, and i prefer callback on threads synchronized to death +[22:29] <jrand0m> perhaps it should only return after its able to /attempt/ to connect? +[22:29] <jrand0m> or maybe the command pattern isn't the desired pattern +[22:29] <mihi> that's what it's doing now. and what result should it return then? +[22:30] <mihi> the point is that you want to have a result (different from an int for the connection id) +[22:30] <jrand0m> right, for the client command, one wants the job (so it can be closed later), but for the genkey command, one wants the public key and private key +[22:30] * mihi cannot think of any other info that is known at that point. +[22:30] <jrand0m> agreed, me neither. +[22:31] <dup> 0! +[22:31] <mihi> and genkey should wait? okay, if you think so. +[22:31] <human> mihi: well, something like a status ("ok" or "error") and error messages... +[22:31] <mihi> human: error messages will be "too late" imo +[22:31] <mihi> but do what you want... +[22:32] <mihi> as long as you make it work with the streaming api afterwards as well... +[22:32] <jrand0m> the pain points human is addressing are the kludges in the TunnelManager that parses the logging messages. but I agree, as long as we can expose that information via the logging interface, thats fine +[22:32] <dup> mihi is wise. +[22:32] <human> human: some can be communicated immediately (e. g. when the tunnel port is still in use) +[22:32] <mihi> human is talking to himself ;) +[22:32] <human> oops! :-) +[22:35] <human> maybe we should see what kind of applications are being built upon I2PTunnel +[22:35] <human> the asynchronous interface is the Right Thing(TM), but it's more complicated to use +[22:35] <jrand0m> I think it would be best if we could keep the same functionality for the current software - including the gui. +[22:35] <FillaMent> maybe I'm jumping in ignorantly, but perhaps a method like one might find many that deal with HTTP: getHeader(String headerName) +[22:35] <FillaMent> smake me as needed +[22:35] <FillaMent> smack +[22:36] * jrand0m smake's FillaMent +[22:36] <human> and the TunnelManager doesn't need it (since it will *never* be able to properly support asynchronous events, due to its nature) +[22:36] * kaji has a completely off-topic idea +[22:36] * FillaMent resigns himself to advocacy =) +[22:37] <human> but if mihi application needs to monitor the tunnels state, then the asynchronous interface is a Must(TM) +[22:37] <jrand0m> human> java -jar lib/I2PTunnel.jar\n. We need to support async. +[22:37] <kaji> i2p as a java applet so you can run it from strange computers quickly by going to a website +[22:37] * Sciatica has quit IRC (EOF From client) +[22:37] <human> jrand0m: yes, then we must rework the TunnelManager :-) +[22:37] <jrand0m> kaji> i2p 3.0 :) +[22:38] <jrand0m> agreed human, the tunnelmanager implementation was a quick and dirty impl +[22:38] <jrand0m> do you think you could look into how that'd need to proceed? +[22:38] * human can volunteer to adapti the TunnelManager to the asynchronous interface, when ready +[22:38] <jrand0m> w00t :) +[22:40] <jrand0m> ok, are we ready for agenda item 3) I2COCP +[22:40] <human> otherwise, it would be possible to create sync and async methods for I2PTunnel +[22:40] <jrand0m> true +[22:40] <jrand0m> but duplication might be overkill when a little refactoring would serve the purpose +[22:41] * baffled has quit IRC (Leaving) +[22:41] <duck> personal concern about the tunnels: apps not closing them, so your whole tunnelmanager becomes flooded +[22:41] <human> jrand0m: yes, we should choose the easiest solution between reworking the TunnelManager or adding new APIs to I2PTunnel :-) +[22:42] <jrand0m> thats a good point duck. currently there are no timeouts / expirations, and it assumes the apps using the tunnelManager are well behaving (and that the tunnelManager has no bugs [hah!]) +[22:43] <mihi> apropos new apis: should the Streaming api classes "replace" the old ones or should it be possible to use both (w/ different commands?) +[22:43] <jrand0m> mihi> I think the streaming ones will want to replace, since once the streaming api is solid mode=GUARANTEED will go away +[22:43] <jrand0m> (and hence the old ones wont work) +[22:44] * MrEcho 's email sent +[22:46] <jrand0m> anything else for the tunnel discussion? (this obviously isn't the end of tunnel discussions overall ;) +[22:47] * dup is now known as dm +[22:47] <jrand0m> ok, I2COCP +[22:47] <jrand0m> this was just something human suggested the other day and it seems to fill a gap thats not currently met. but I think we want to hold off on implementing until we have something that wants to use it :) +[22:48] <wiht> That is a somewhat long name, even abbreviated. +[22:48] * jrand0m now calls I2COCP "Wilma" +[22:48] <human> jrand0m: well, i was going to write the same words :-) +[22:48] <jrand0m> heh cool +[22:49] <jrand0m> ok, jumping on to 4) roadmap +[22:49] <human> jrand0m: IMHO, in general, there should be a way for non-java apps to have a somewhat full access to the I2P network +[22:49] <jrand0m> agreed +[22:49] <jrand0m> the intent is that they'd use I2CP +[22:50] <jrand0m> (as all java apps, i2ptunnel and the streaming library included, use that) +[22:50] <human> jrand0m: yes +[22:50] <MrEcho> I2PDNS "Janessa" +[22:50] <jrand0m> but you're right, they'd want streaming too, so either tunnelmanager->i2ptunnel or i2cocp->streaming lib +[22:50] * jrand0m has never met a Janessa +[22:51] * Sciatica has joined #i2p +[22:51] <jrand0m> ok, so, yeah, the roadmap has been updated. no real big changes beyond pushing back 0.3 and 0.3.1 by 2 weeks, adding 2.0 info, and some more 1.0 criteria +[22:51] <human> jrand0m: yeah, there should be "TCP" and "UDP"-like protocols for I2P, with complete protocol event reporting, accessible from non-java apps +[22:52] <MrEcho> human, sounds good +[22:52] <jrand0m> I want there to be every possible interface, but I don't want to overcommit with too many interfaces to be supported +[22:52] * human wanted I2COCP (or whatever) for his I2P twisted transport (see http://www.twistedmatrix.com/), but for now he will happily kludge around the TunnelManager :-) +[22:53] * w0rmus has quit IRC (Lost terminal) +[22:53] <jrand0m> word. that'd be best for now +[22:54] <jrand0m> ok, any comments on the roadmap? +[22:55] <jrand0m> [nothing to see here, la la] +[22:55] <jrand0m> ok, 5) i2pIM +[22:55] <jrand0m> thecrypto isn't here, so we can just wait for a post to i2p@ with updates :) +[22:55] <wiht> We have Jabber now, if I am not mistaken. Do we still need i2pIM? +[22:55] <jrand0m> yes +[22:55] <jrand0m> jabber has a server that gets cleartext. +[22:56] <wiht> Oh. Very well, then; I was not aware of this. +[22:56] <jrand0m> thats two strikes (a server, and cleartext) +[22:56] <jrand0m> its a good solution for some things though, certainly +[22:56] <jrand0m> actually, once thing I was thinking about this morning was if we could get i2pIM and i2psnark merged together, that would be Good. +[22:57] <jrand0m> (but once thing at a time) +[22:57] <jrand0m> actually, speaking of the devil, 6) i2psnark :) +[22:57] <human> jrand0m: i sometimes used jabber with gnupg... +[22:57] <jrand0m> for >2 person chats? +[22:58] <jrand0m> for one on one, I totally agree there are existing solutions +[23:01] <jrand0m> ok, on to a fun one, 7) introducing I.Toopie :) +[23:01] <human> how would you implement encrypted >2 people chats? a shared private key? +[23:01] <jrand0m> yes human +[23:01] <jrand0m> or through n! shared keys in the group +[23:02] <human> well, maybe it could be done above the existing jabber protocol... +[23:02] <mihi> human: a shared symmetric key sent to all participants +[23:02] <jrand0m> the hard part is dealing with joins & leaves - key rotation /etc +[23:03] * Sciatica has quit IRC (Ping timeout) +[23:03] <jrand0m> its in no way a trivial issue. its really really really hard. +[23:03] * mihi acks +[23:03] * human agrees +[23:04] <jrand0m> (which is why having an app designed for it rather than trying to kludge it on top of another protocol may be worthwhile) +[23:04] <jrand0m> but thecrypto can best describe his plans +[23:04] <jrand0m> (though its my understanding he's still open to ideas for how to deal with groups) +[23:05] * Sciatica has joined #i2p +[23:06] <jrand0m> ok, moving on :) [further discussion on i2p@, etc] +[23:06] <wiht> What is I.Toopee, though? +[23:06] <lucky> the mascot... +[23:06] <jrand0m> I.Toopie is a guy holding a yellow mask in front of his face +[23:06] * lucky shudders. +[23:07] <lucky> uh huh. +[23:07] <lucky> can i see it? +[23:07] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?I2PLogo +[23:07] * mihi_backup has quit IRC (EOF From client) +[23:07] <lucky> i have added java to my compile queue... +[23:07] <lucky> but.. lol +[23:07] <lucky> i already have 7 things running +[23:07] <lucky> it'll be a while. +[23:08] <lucky> aw, cute :P +[23:08] <MrEcho> lol +[23:08] <jrand0m> there have been lots of cool logos (I can't believe we've had the logo contest going on for 3 months!), and it looks like we've got some strong potential with I.Toopie. in its simplicity, its conception, and its versatility. +[23:08] <jrand0m> and, yeah, its cute ;) +[23:08] <mihi> are some imgs broken or is my browser buggy? +[23:08] <jrand0m> yeah, some are broken +[23:09] <jrand0m> (they were put on temporary hosting sites 3 months ago) +[23:09] <MrEcho> I.Toopie's stick is now all yellow ... +[23:09] <MrEcho> changed lastnight +[23:09] <jrand0m> it is? +[23:09] <jrand0m> people should UPDATE THE WIKI then +[23:09] <jrand0m> ;) +[23:09] <MrEcho> hehe +[23:09] <MrEcho> i dont have the pic anymore .. sorry +[23:10] <wiht> I see the pictures with Opera, but not with Mozilla somewhy. +[23:10] <jrand0m> you can see http://img.villagephotos.com/p/2003-10/437060/badass.jpg ? +[23:10] <jrand0m> (thats one of the images on that page) +[23:11] <duck> Access Denied (User Account Disabled) +[23:11] <jrand0m> yeah, same here. +[23:11] <MrEcho> i can see it +[23:11] <jrand0m> but yes, DrWoo has done some kickass stuff with I.Toopie +[23:11] <MrEcho> moz 1.5 +[23:11] * soros has quit IRC (EOF From client) +[23:11] * mihi_away has joined #i2p +[23:11] * lucky has quit IRC (EOF From client) +[23:12] <jrand0m> same here MrEcho. strange. +[23:12] <wiht> MrEcho: I am using Mozilla 1.4. +[23:12] <jrand0m> (same as in I'm on moz 1.5 and I'm getting access denied) +[23:13] * jrand0m looks forward to a tray icon w/ i.toopie :) +[23:13] <jrand0m> ok, moving on to 8) chess server +[23:14] * Sciatica has quit IRC (Ping timeout) +[23:14] * ion has quit IRC (Ping timeout) +[23:14] <jrand0m> the latest hosts.txt (http://i2p.dnsalias.net/i2p/hosts.txt) contains the reference for chess.fillament.i2p +[23:14] <jrand0m> you can use any old FICS client or just telnet to that and play away :) +[23:14] <jrand0m> (yay) +[23:15] <kaji> is there a goog fics client for windows? +[23:15] <jrand0m> dunno, I ended up using telnet +[23:15] <wiht> Does eboard work? +[23:15] <jrand0m> (which had some fairly tough rampup to learn the commands) +[23:15] * ion has joined #i2p +[23:16] <jrand0m> dunno +[23:16] * BpX has joined #i2p +[23:16] <wiht> I will try it later. +[23:16] <jrand0m> cool, if you could post up what you find, that'd be great +[23:17] <jrand0m> ok, 9) DHT +[23:17] * wilde has quit IRC (Ping timeout) +[23:17] <jrand0m> we still don't have a dht, but perhaps this is a lead for something we can start to port +[23:18] <jrand0m> (it uses UDP so getting it to use I2CP wouldn't be hard) +[23:18] <MrEcho> dht??? +[23:18] <MrEcho> im blanking on that one +[23:18] <jrand0m> MrEcho> see [10] in the email ;) +[23:18] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?DHT +[23:18] <Nightblade> entropy is a good enough temporary solution +[23:18] <jrand0m> agreed +[23:19] <jrand0m> though I think we need to look at a long term solution as well +[23:19] * soros has joined #i2p +[23:19] * lucky has joined #i2p +[23:20] * human is worried about gcj/kaffe compatibility with DHTs like Bamboo (http://bamboo-dht.org/) +[23:20] <jrand0m> yeah, bamboo is 1.4 +[23:20] <MrEcho> afk +[23:20] <jrand0m> thats the glory of i2cp though - the router & tunnels can be gcj'ed, while things that access them can be whatever +[23:21] <jrand0m> it /is/ purely for an app though - not as part of the core +[23:21] <jrand0m> I'm just trying to think of things that would help the end users who end up downloading i2p do something useful right off the bat +[23:22] <jrand0m> (being able to post uncensorable content anonymously would be a good useful thing) +[23:22] <jrand0m> s/uncensorable/very censorship resistant/ +[23:23] <human> jrand0m: ah, ok - i thought that bamboo was going to replace Kademlia for the NetworkDB :-) +[23:23] <Nightblade> the squid proxy is something they can do... for users for example in china that would be a very nice thing to have +[23:23] <jrand0m> Nightblade> right, but the squid isn't scalable +[23:24] <Nightblade> yeah i think it would be interesting to have a kind of distributed JAP +[23:24] <jrand0m> agreed +[23:24] <jrand0m> so that's also another thing that would be great if people could check into :) +[23:24] <mihi> Nightblade: the prob is abuse handling - i won't open my box for any outgoing http +[23:24] <jrand0m> I'm sure some people will though +[23:25] <Nightblade> with an additional part where an individual node could choose what sites they want to proxy for people... a client could send a requst for "whitehouse.com" and then one of the nodes that will do the proxying and will permit that url can answer +[23:25] <Nightblade> yeah i think it would have to have some kind of access controls +[23:25] <Nightblade> blacklist or whitelist +[23:25] <jrand0m> right +[23:25] <Nightblade> of domain names +[23:26] <jrand0m> its the "exit policy" system. though this is a whole project in and of itself +[23:27] <MrEcho> it could ride on the DNS system... i guess +[23:27] <jrand0m> certainly +[23:27] <wiht> mihi: What if you limit the bandwidth used? Or is it the websites accessed that could get you in trouble? +[23:27] <MrEcho> at a very later date lol +[23:27] <jrand0m> wiht> many providers explicitly disallow running servers of any kind +[23:28] <MrEcho> verizon fucks with port 21 for sure... +[23:28] <wiht> jrand0m: Oh. Yes, that is a problem. +[23:28] <Nightblade> there would have to be some way for clients to request the sites they want downloaded for them.. Broadcast requests are not a very good solution, especially on i2p +[23:29] <mihi> wiht: the problem is the websites that can be accessed. compare the lawsuit of JAP some time ago. /me lives in the same country +[23:29] <jrand0m> agreed. though broadcast isn't possible without brute forcing a ~2^2300 keyspace ;) +[23:30] <jrand0m> right mihi, people in oppresive regimes would not be able to safely run outproxies +[23:30] <wiht> mihi: What was the lawsuit? I do not remember. +[23:30] * dm has quit IRC (Ping timeout) +[23:30] <Nightblade> i mean, even if you had a list of destinations that provide web proxying, you would not want to have to broadcast to them all +[23:30] <jrand0m> right Nightblade +[23:30] <Nightblade> request broadcast i mean +[23:31] <mihi> the prob was that someone had accessed a child porn site and it went over a JAP proxy and they could not tell where the request came from. this was interpreted as thowing stones into police's work +[23:31] <jrand0m> people may want to check out crowds or rewebber to see other projects that worked on this same task +[23:31] <wiht> mihi: Ah. Thank you for the explanation. I see understand you are concerned now. +[23:31] * mihi_away has quit IRC (Ping timeout) +[23:31] <mihi> and made that change to the jap software that makes it possible to catch people. which was removed later +[23:32] <wiht> Er, I understand why you are concerned. +[23:32] <mihi> at the end it came out that the JAP would not have to disclose the data, but i don't want to know what the lawyers cost... +[23:32] <Nightblade> yeah but didn't the police seize the information anyway? +[23:32] <jrand0m> yes +[23:33] <mihi> they did... +[23:33] <jrand0m> but anyway, yes, both a scalable DHT and a scalable web proxy would be Really Good Things to have by 1.0 +[23:34] <mihi> and they cannot give it backk, can they? +[23:34] * BpX has quit IRC (Ping timeout) +[23:36] * Sciatica has joined #i2p +[23:36] <jrand0m> ok, anything else for point 9? or are we on to 10/11) NS/DNS? +[23:36] <wiht> I would like to make a brief comment about the installer after topic 10. +[23:37] <jrand0m> 'k perhaps lets hit that now, since NS/DNS might not be uber-brief? ;) +[23:37] <wiht> All right. The router has a start script and a stop script. +[23:37] <jrand0m> right +[23:37] <wiht> I would like all of the services to be done that way--to have both a start and a stop script. +[23:37] <jrand0m> most of them do +[23:37] <jrand0m> don't they? +[23:38] <jrand0m> oh, not stop scripts +[23:38] <wiht> No, just the router. +[23:38] <wiht> That way, desired services could be started on computer bootup, just like the router. I made a post to that effect to the mailing list. +[23:38] <jrand0m> aum is working on the i2pmgr, which is going to be both a console based and gui based control center for the services and the router itself +[23:38] <wiht> Let's say I want to start the eep and nntp on bootup. Currently, I can't do that. +[23:39] <jrand0m> right, you'd need to nohup startEepProxy.sh & +[23:39] <wiht> All right. By the way, where are these scripts in CVS? +[23:39] <MrEcho> k im back +[23:39] * mihi_away has joined #i2p +[23:39] <jrand0m> wiht> the scripts are in the Install.java (aka hacked) +[23:39] <wiht> jrand0m: Thanks./ +[23:40] <jrand0m> but good point, we want it to be as simple as possible to start on boot, as well as start on demand +[23:41] <jrand0m> ok, on to 10/11) ns/dns +[23:41] <MrEcho> well check my email +[23:41] <MrEcho> theres a few things i forgot about putting in there +[23:41] <jrand0m> unfortunately your email didn't really go through to the web interface well :/ +[23:41] <MrEcho> like "temp" names +[23:41] <MrEcho> ?? +[23:42] * Sciatica has quit IRC (Ping timeout) +[23:42] * ion has quit IRC (Ping timeout) +[23:42] <jrand0m> MrEcho> http://i2p.dnsalias.net/pipermail/i2p/2004-January/000072.html +[23:42] <MrEcho> because of the gif or something +[23:42] <MrEcho> shit .. i singed it +[23:43] <MrEcho> sorry +[23:43] <jrand0m> the mailing list is really intended to be text only. pgp sigs are fine (others have posted signed things) +[23:43] <kaji> whats a good free small antivirus? +[23:43] * ion has joined #i2p +[23:43] <jrand0m> kaji> linux +[23:43] * Sciatica has joined #i2p +[23:43] <wiht> LOL. +[23:43] <kaji> that runs with my hardware +[23:43] <wiht> kaji: Try AVG Antivirus for Windows. +[23:44] * MrEcho_ has joined #i2p +[23:44] * MrEcho has quit IRC (EOF From client) +[23:44] <MrEcho_> fuckign iip +[23:44] <jrand0m> MrEcho / (and anyone else interested in the NS/DNS issue)> have you read http://zooko.com/distnames.html ? +[23:44] <MrEcho_> j, should i resend the email? +[23:44] <jrand0m> it went through to the list fine, it just didn't get web archived correctly +[23:44] <MrEcho_> ya +[23:45] <wiht> jrand0m: I did not read it yet. +[23:45] <MrEcho_> ill take a look at it later +[23:45] * mrflibble has joined #i2p +[23:45] <jrand0m> for those who aren't on the list, I've saved MrEcho_'s email at http://i2p.dnsalias.net/~jrandom/mrecho_dns.txt +[23:46] <MrEcho_> thanks J +[23:46] <kaji> its gay, it wants an email adress +[23:46] <jrand0m> my concern is with the security and scalability of the naming service. once we find a solution that meets those needs, fantastic, but until we do, we should be careful of interim solutions. +[23:47] <jrand0m> kaji> email lists usually want an email address, yeah ;) +[23:47] <kaji> i mean AVG Antivirus +[23:47] <jrand0m> oh ;) +[23:48] <wiht> MrEcho has several good ideas that I did not have in my specification, such as a ban list for bad clients. +[23:49] <MrEcho_> not really a ban list +[23:49] <jrand0m> once there are 1000 clients, does that mean that it would take 125 lookups to find a value? +[23:49] <MrEcho_> no +[23:49] <wiht> Not a list, but banning bad clients is something I did not have. +[23:50] <MrEcho_> 2-4 clients for checking +[23:50] <jrand0m> so every client will have 250 entries? +[23:50] * mihi_away is now known as mihi_backup +[23:50] <MrEcho_> no +[23:50] <wiht> With what I have, it would be one lookup, possibly forwarded a couple of times to reach an authoritative server. +[23:50] <MrEcho_> clients will only have what they need +[23:51] <MrEcho_> it will keep querying other Clients untill they get data that matches for the check +[23:51] <jrand0m> so with 4 peers, it'd do a random search and on average it'd take 125 lookups +[23:51] <jrand0m> (1000/4/2) +[23:51] <jrand0m> or are the peers a DHT? +[23:52] <jrand0m> (with some maintenance protocol?) +[23:52] <jrand0m> or a search tree? +[23:52] <MrEcho_> in a way yes +[23:52] <MrEcho_> ill have a cut off on client searches, it will just query the MS +[23:53] <jrand0m> secure distributed naming is a fairly well studied problem - what would make your proposal easier to analyze the security and scalability would be if you could draw comparisons and validate variations on other approaches, perhaps? +[23:54] <MrEcho_> if it doesnt find / or get enough data from Clients within a set range it will then just query the MS. +[23:54] <jrand0m> as is, there isn't enough detail for me to have confidence in the scalability or security of the architecture. not to say it couldn't work out well, I just can't see that it would yet. +[23:54] <MrEcho_> cany u stop typing for a sec +[23:54] * jrand0m stops typing. +[23:55] <MrEcho_> its going to work .. it will have scalability, it will have security +[23:56] <MrEcho_> the more users the better it will get +[23:56] <jrand0m> so "trust me", 'eh? +[23:56] <MrEcho_> do you trust the Internet DNS system? +[23:56] <jrand0m> for some tasks. +[23:57] <jrand0m> for many, no. +[23:57] <jrand0m> (its quite easy for govts / etc to get records changed - court cases order registrars to update all the time) +[23:58] <MrEcho_> only other way of doing it is having big ass lists of Names and lots of crypto on every client +[23:58] <MrEcho_> and being dynamic .. forget about it +[23:59] * mrflibble has quit IRC (EOF From client) +[23:59] <jrand0m> I suggest reviewing zooko's paper before proceeding further, and answering his final point 5 ("why I'm wrong") +Session Time: Wed Jan 07 00:00:00 2004 +[00:01] <jrand0m> ok, thats probably about it for point 10/11 (lots of future discussion still left on that, of course) +[00:02] <jrand0m> anyone have any other thoughts, etc? +[00:02] <wiht> Yes. +[00:03] <jrand0m> care to share with the class? :) +[00:03] <wiht> I will be rewriting the specification I wrote. I would like to use a local SQL server to store data, not files. +[00:03] <jrand0m> ah cool +[00:03] <jrand0m> (same concerns go for the spec you wrote too - if you could answer zooko's last question, that'd be key :) +[00:03] * mrflibble has joined #i2p +[00:03] <wiht> Let MySQL or a similar server manage data storage, and let Java query that server. +[00:04] <duck> huh ? zooko specs? +[00:04] <wiht> I think that will be easier to implement. +[00:04] <jrand0m> duck> naw, I'm just pointing people at his old article "Names: Decentralized, Secure, Human-Meaningful: Choose Two" +[00:04] <duck> ah that +[00:04] <Nightblade> wiht: what specification is that (i missed a lot of the meeting)? +[00:04] * MrEcho has joined #i2p +[00:04] <jrand0m> (a lot easier than rehashing why supernode/centralized servers are scary security issues ;) +[00:05] * MrEcho_ has quit IRC (EOF From client) +[00:05] * mihi 'd have something for the log as well ;) +[00:05] <mihi> something longer ;) +[00:05] <mihi> *** I2Ping results: +[00:05] <mihi> + + + eco.i2p +[00:05] <mihi> + - - jabber.duck.i2p +[00:05] <mihi> - + + i2pcvs.i2p +[00:05] <mihi> - + + duck.i2p +[00:05] <mihi> - + - jap.eco.i2p +[00:05] <jrand0m> Nightblade> it was posted to iip-dev back in... august? +[00:05] <mihi> - + + irc.duck.i2p +[00:05] <mihi> - + + human.i2p +[00:06] <mihi> - - + nntp.duck.i2p +[00:06] <mihi> - - - tc.i2p +[00:06] <mihi> - - - dyad.i2p +[00:06] <mihi> - - - bozo.i2p +[00:06] <mihi> - - - ogg.aum.i2p +[00:06] <mihi> - - - fcp.entropy.i2p +[00:06] <mihi> - - - http.entropy.i2p +[00:06] <Nightblade> jrandom: oh, before my time.. :) +[00:06] <mihi> - - - www.mail.i2p +[00:06] <mihi> - - - mp3.aum.i2p +[00:06] <mihi> - - - smtp.mail.i2p +[00:06] <wiht> Nightblade: I posted it on September 15th. +[00:06] <mihi> - - - pop.mail.i2p +[00:06] <mihi> - - - mp3.tc.i2p +[00:06] <mihi> - - - lp.i2p +[00:06] <mihi> - - - kaji.i2p +[00:06] <mihi> - - - nm.i2p +[00:06] <mihi> - - - squid.i2p +[00:06] <mihi> - - - chess.fillament.i2p +[00:06] <mihi> - - - mesh.firerabbit.i2p +[00:06] <mihi> - - - nightblade.i2p +[00:06] <mihi> - - - aum.i2p +[00:06] <MrEcho> gezz is anyone up and running? +[00:06] <mihi> - - - fillament.i2p +[00:06] <mihi> *** Finished. +[00:06] <mihi> why are so many hosts down...? +[00:06] * jrand0m isn't running my servers atm +[00:07] <FillaMent> I can connect to myself on both eep and chess +[00:07] * mrflibble has quit IRC (Ping timeout) +[00:07] <jrand0m> oh wait, i2pcvs is up, neat +[00:07] <Nightblade> mihi: mine isn't up because the i2ptunnel crashes for me after a few hours +[00:07] <mihi> so my router is broken (or it's usual I2P problems...) +[00:08] <jrand0m> really Nightblade? please report i2ptunnel crashes (bugzilla would be nice) +[00:08] <Nightblade> it is in the bugzilla +[00:08] <lucky> hi +[00:08] <Nightblade> hold.. +[00:08] <FillaMent> Nightblade: what JVM? +[00:08] <Nightblade> #39 +[00:08] <wiht> My router has been running for more than 12 hours now, although it had a problem in registering itself. +[00:09] <Nightblade> java version "1.4.2-p5" +[00:09] <Nightblade> on freebsd... it could be a jvm problem, i don't know. java support isn't too good on freebsd +[00:09] <jrand0m> you're right Nightblade, my bad +[00:09] <jrand0m> thats the fairly infrequent i2cp bug +[00:09] <jrand0m> is that consistent for you? +[00:09] <Nightblade> the router is very stable for me, just the i2ptunnel server tunnel gives me problems +[00:09] <Nightblade> yeas it happened several times +[00:10] <Nightblade> i haven't tried it recently though +[00:10] * jrand0m just pulled fillament's eepsite +[00:10] <jrand0m> (first try, just noticed the window was complete) +[00:10] <FillaMent> Yeah,, I just jabbered with duck, wiht's trying to hit chess +[00:10] <jrand0m> ah cool +[00:10] <jrand0m> but yes, there are still reliability issues to be dealt with in the network. +[00:10] * FillaMent nudges people with the included winking, "He'll probably be wanting to play." +[00:10] * human 's eepsite is still up - it means that 'killall java' really helped... :-) +[00:10] <wiht> I just successfully connected to chess server. +[00:10] <duck> yeah? +[00:11] <jrand0m> lol FillaMent +[00:11] * mrflibble has joined #i2p +[00:12] <Nightblade> is it safe to run the cvs version of i2p +[00:12] <jrand0m> /me succesfully fetches human's 1984-2004: twenty years of GNU! :-) +[00:12] <jrand0m> yes Nightblade +[00:12] <FillaMent> could not get eco... +[00:12] <Nightblade> ok maybe i'll give that a try +[00:12] <duck> with freenet you should always run the latest cvs version! +[00:13] <duck> only then it is bugfree +[00:13] <duck> s/freenet/i2p/ +[00:13] * jrand0m pulled eco.i2p +[00:13] <FillaMent> just got duck +[00:13] <jrand0m> "Jan 4: First field test of I2PSnark. Pretty catastrophic: no transfer at all. Guess my single router test environment wasn't very representative :-) Back to the drawing board... " +[00:13] <jrand0m> d'oh +[00:13] <duck> well, it worked actually +[00:13] <duck> ardvark could snark something from me +[00:14] <jrand0m> bt precreates the files - were the files actually valid? +[00:14] <duck> but ze did find out the next day +[00:14] <duck> because it was obscured in the logs +[00:14] <jrand0m> what, you mean the logs i2p generates are fairly insane? nawwwwww +[00:14] <duck> no +[00:14] <duck> the i2psnark output +[00:14] <jrand0m> ah +[00:15] <duck> additionally, I suspect that snark does too much churning (sp?) +[00:15] <duck> the normal bittorrent client seems to be more easy +[00:15] <duck> also the high delays on i2p might cause premature blocks +[00:16] * mrflibble has quit IRC (Ping timeout) +[00:16] <duck> last thing is that we had to restart i2ptunnel a few times :/ +[00:16] <jrand0m> agreed +[00:16] <human> final question about I2PTunnel / I2PTunnelManager (yes, i know, i'm boring): what about my patch to make "openclient" and "openserver" return a meaningful jobId? +[00:16] <jrand0m> so, yeah, lots of work to do +[00:16] <human> 1. let's accept it to make the TunnelManager work until the new asynchronous architecture will be roxoring +[00:17] <human> 2. your patch plain sucks, fuck off, and fuck the TunnelManager +[00:17] <human> 3. ... +[00:17] * MrEcho_ has joined #i2p +[00:17] * mihi is for 3 ;) +[00:17] * MrEcho has quit IRC (EOF From client) +[00:17] <jrand0m> 4. lets see how we can update the tunnel manager to go async? shouldn't be too hard +[00:17] <jrand0m> the patch is good, but mihi has a point +[00:18] <human> jrand0m: yes, i agree +[00:18] <jrand0m> we still have 1+ weeks until 0.3, so we've got time until the next full release +[00:18] <human> jrand0m: but my doubt is: how long will it take to have the async interface to be implemented in the TunnelManager? +[00:18] <jrand0m> tunnelmanager itself was 2 hours, I could add async tonight +[00:19] <jrand0m> (all that needs to happen is an update to the BufferedLogging to accept .set calls) +[00:19] <human> jrand0m: (with "to have" i also mean "to have it implemented even in I2PTunnel) +[00:19] <jrand0m> (or .nofity/etc) +[00:19] <jrand0m> right +[00:19] * mrflibble has joined #i2p +[00:20] <jrand0m> if you'd prefer, I could start with your patch (which adds the job id) and merge it with the updates for async +[00:21] <human> jrand0m: i could add the async interface to TunnelManager myself, but the interface still doesn't exist :-) +[00:22] <jrand0m> right, just add public void notifyEvent(String eventName, Object value); to Logging.java +[00:22] <human> jrand0m: i'd suggest "let's merge the dirty hack to make the job ids in the 0.3 release somewhat work, and then work on the async interface" +[00:23] <jrand0m> 0.3 is still a ways off +[00:23] <mihi> 0.3 should have the streaming api anyway, shouldn't it? +[00:23] <human> jrand0m: i'm talking about the worst case +[00:23] <wiht> jrand0m: Maybe there should be another version before 3.0 to settle these issues? +[00:23] <jrand0m> yes mihi +[00:23] <mihi> human: the worst case is "cvs rollback && patch -p0 your.patch" +[00:24] <jrand0m> ok, how about this. I'll get the async implemented and committed tonight, if you could look at it tomorrow human and see what needs to be done to get your update in there? +[00:26] <FillaMent> jrand0m: do you have a job? +[00:27] <jrand0m> i2p +[00:27] <duck> get 1.0 done! +[00:27] <FillaMent> I mean a source of income +[00:27] <jrand0m> :) +[00:27] <FillaMent> that you have to work for +[00:27] <jrand0m> income is overrated. +[00:27] * jrand0m fired my boss +[00:27] <Nightblade> "will code for food" - that's my motto +[00:27] <Nightblade> lol +[00:27] <human> mihi: well, but i and aum (who is working on a python app for the TunnelManager) would like to have jobIds ASAP... +[00:28] <human> jrand0m: ok, i'll work on your changes later/tomorrow +[00:28] <FillaMent> Job/Money, sleep/hygiene, food, side projects, social life: Choose any 3 +[00:29] * jrand0m only choses one. +[00:29] <jrand0m> word human +[00:30] <FillaMent> Anyone have any other ideas for "just tunnel to" services that would be nice to have on the network? +[00:30] * jrand0m still wants a telnet based Adventure :) +[00:30] <jrand0m> or a waffle bbs +[00:30] * duck is now known as enduser +[00:30] * jrand0m kicks enduser +[00:31] <jrand0m> (damn, no ops) +[00:31] <FillaMent> For OS/2 there was a comm driver that could map a comm port to a TCP port =) +[00:31] <enduser> what difference will I see as enduser when I2PTunnel uses the SteamingAPI? +[00:31] * enduser is now known as duck +[00:31] <jrand0m> none +[00:31] <human> lol +[00:31] <FillaMent> FillaMent: friend of mine ran a BBS that way for a while +[00:31] <jrand0m> performance, and perhaps anonymity +[00:31] * human would like a I2P tunnel to a rootshell +[00:32] <human> any volunteer? :-) +[00:32] <duck> rootshell on a UML +[00:32] <jrand0m> chroot'ed rootshells would be good +[00:32] <jrand0m> or UML'ed :) +[00:32] <FillaMent> human: had I a spare boxen, I'd do it +[00:32] <jrand0m> hehe FillaMent +[00:32] <duck> vnc connection to my vmware win98? +[00:32] <FillaMent> seriously though guys... +[00:32] <wiht> E-mail server would be a good one as well. Or do we have that already? +[00:32] <FillaMent> wiht: think TC has pop and SMTP +[00:33] <jrand0m> thats aum, but they're offline, as his box is offline +[00:33] * human could offer telnet accounts on his GNU/Hurd system... +[00:33] <jrand0m> ooOOoo +[00:33] <FillaMent> well, I'm not too keen on setting up open SMTP access yet +[00:33] <jrand0m> understandable +[00:34] <FillaMent> maybe when the network is more stable and I've got money to up my bandwidth +[00:34] <wiht> How about a PGP keyserver? +[00:34] <mihi> FillaMent: you could set up a tunnel pointing to a cleartext remailer +[00:34] <FillaMent> wiht: now THAT's a great idea =) +[00:35] <FillaMent> mihi heh... I could just point the tunnel to my ISP SMTP box =) +[00:35] <mihi> FillaMent: this would make *you* be resposible for abuse... +[00:35] <mihi> s/be// +[00:35] <duck> http://www.mit.edu/people/marc/pks/pks.html +[00:36] <duck> seriously, should duck enterprises consider running a pgp keyserver? +[00:37] <FillaMent> duck: I was poking into that myself... you want to handle it? +[00:37] <duck> we have been one of the most stable service providers according to mihi's independent ping logs +[00:37] <jrand0m> hehe +[00:37] <wiht> duck: Yes, please consider it. +[00:37] <jrand0m> btw duck, how do you do that? do you restart periodically or just run on a reliable OS and JVM? +[00:38] <FillaMent> question: does the JVM cache DNS resolves? +[00:38] <duck> restarting is for kernel updates +[00:38] <jrand0m> yes, but you can do some nasty trickery to avoid it FillaMent +[00:38] * wiht notes that the meeting has gone on for 2h40m now. +[00:38] <jrand0m> oh yeah, +[00:39] * mrflibble sticks his hand up +[00:39] <jrand0m> um, this meeting's log is going to be huge. and here I was thinking posthing things up front would /shorten/ the meeting +[00:39] <jrand0m> sup mrflibble? +[00:39] <FillaMent> jrand0m: okay... because I am without downage but my IP changes periodically... my dyndns update script runs every hour so max 60+~10min of my named addy not pointing to my IP... +[00:39] <FillaMent> how would that affect my router's presence on the network? +[00:40] <mrflibble> my box could be availalbe for some kind of demony thing +[00:40] <jrand0m> cool FillaMent, shouldn't be much of a problem, as long as you point to your dyndns +[00:40] <wiht> mrflibble: demony? +[00:40] <mrflibble> i guess it depends how much bandwidth the thing would use +[00:40] <mrflibble> daemony +[00:40] <jrand0m> w3rd mrflibble - has the router been working reliably for you, or are you just being a good sameritan? :) +[00:41] <mrflibble> not really, but that's because my local bw is saturated atm +[00:41] <mrflibble> im not running it on my colo yet +[00:41] <mrflibble> want to play around with it locally first +[00:41] <jrand0m> ah cool. yeah, i2p isn't really ready for wide deployment, still for testing mainly +[00:42] <FillaMent> Heh.. I'll point a tunnel to my CUPS server and you can have anonymous printing =) +[00:42] <jrand0m> rofl +[00:42] <mrflibble> if there's something that u want me to run that would use <40gb bw a month, lmk +[00:42] <FillaMent> just include a banner page so I know where to mail the hardcopy =) +[00:42] <mrflibble> hehe +[00:43] <jrand0m> wikked mrflibble, I'm sure we'll take you up on that :) +[00:43] <mihi> banner | lpr ? ;) +[00:43] <FillaMent> mihi you cah set up CUPS with a banner page +[00:43] <mrflibble> oky doky! +[00:43] <mihi> banner will most likely create lots of pages ;) +[00:43] <jrand0m> ok, before we get to the mixminion->printer->post office gateway discussion, lets close this meeting ;) +[00:44] * jrand0m readies the *baf*'er +[00:44] * jrand0m *baf*'s the meeting closed. diff --git a/i2p2www/meetings/logs/72.rst b/i2p2www/meetings/logs/72.rst new file mode 100644 index 00000000..4e36c897 --- /dev/null +++ b/i2p2www/meetings/logs/72.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 6, 2004 @ 22:00 CET +============================================ + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/73.log b/i2p2www/meetings/logs/73.log new file mode 100644 index 00000000..0780e290 --- /dev/null +++ b/i2p2www/meetings/logs/73.log @@ -0,0 +1,137 @@ +[22:01] <jrand0m> 0) hi +[22:01] <jrand0m> 1) 0.2.3.4 +[22:01] <jrand0m> 2) 0.3 +[22:01] <jrand0m> 3) streaming library, I2COCP, CI2CP +[22:01] <jrand0m> 4) apps +[22:01] <jrand0m> 5) ??? +[22:01] <jrand0m> 0) hi +[22:01] <jrand0m> hi everyone +[22:01] <jrand0m> y'all seen http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html? +[22:01] <jrand0m> if not, now's your chance :) +[22:02] <jrand0m> iip has been acting up a bit, so if someone could say something every once in a while, that'd be swell +[22:02] <MrEcho> . +[22:02] <jrand0m> w3rd +[22:02] <jrand0m> ok, moving on, 1) 0.2.3.4 +[22:03] <jrand0m> there'll be a new release in the next day or so with the current state of the code, which includes a lot of bugfixes and more features +[22:03] <jrand0m> e.g. tunnelmanager isn't in 0.2.3.3 yet +[22:03] <MrEcho> col +[22:03] <jrand0m> it'll be backwards incompatible, because i'm mean +[22:04] <jrand0m> jumping onto 2) 0.3 +[22:04] <MrEcho> :P +[22:04] <jrand0m> that'll be out fairly soon, but obviously not on thursday +[22:04] <jrand0m> it won't be out until 0.2.3.4 is performing reliably so that everyone can reach all sites they should be able to +[22:05] <MrEcho> cool +[22:05] <jrand0m> well, moving right along to 3) streaming lib / etc +[22:05] <jrand0m> well, thats all spelled out in the email :) +[22:05] * eco has joined #i2p +[22:05] * mihi_away is now known as mihi +[22:05] <jrand0m> if anyone wants to get involved in it, please let me know +[22:06] * ion has joined #i2p +[22:06] <jrand0m> 'lo eco, mihi, ion +[22:06] <jrand0m> ok, moving on to 4) apps +[22:06] <jrand0m> anyone working on an app that will run over i2p that has anything to add? +[22:07] * wiht has joined #i2p +[22:07] <MrEcho> re ask the quest j +[22:07] <jrand0m> well, we're at the last agenda item, so might as well :) +[22:08] <MrEcho> wiht .. get my email? +[22:08] <jrand0m> anyone have anything to bring up outside the http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html post? +[22:08] <wiht> Yes, let me read it. +[22:08] <jrand0m> MrEcho> have you read zooko's naming page yet? +[22:08] * jar has joined #i2p +[22:08] <MrEcho> no .. lost the link +[22:09] <jrand0m> (from the logs last week, http://zooko.com/distnames.html) +[22:10] <jrand0m> anyone have anything to add, or are we at a record breaking 10 minute meeting? +[22:10] <MrEcho> still working on my dns idea +[22:10] <jrand0m> coo' +[22:10] <wiht> MrEcho: Yes, I would like to work together on naming service. +[22:10] <MrEcho> sweet +[22:11] <wiht> But I will not have time until next Wednesday. +[22:11] <MrEcho> ok +[22:11] <MrEcho> will give me some time to finish up on a few things +[22:11] <mrflibble> how long till the meet? +[22:11] <jrand0m> -11 minutes +[22:11] <mrflibble> oops +[22:11] * mrflibble is v late +[22:11] <mrflibble> :) +[22:12] <jrand0m> (we've gone through the 5 agenda items very very quicky :) +[22:12] * mrflibble goes back to lurking and the backscroll +[22:12] <jrand0m> heh +[22:12] <wiht> jrand0m: Have you measured how much CPU is used per tunnel by the server? +[22:14] <wiht> Let me restate that: if you have five connections to other routers, and they are using 20% of CPU, how much will be used after 6th connection? Have you measured this? +[22:15] <jrand0m> they shouldn't consume 20% of the cpu, or even 1% +[22:15] <jrand0m> (for client tunnels - server tunnels may consume more) +[22:15] <wiht> Server tunnels. +[22:16] * eco has quit IRC (Ping timeout) +[22:16] <wiht> But that will probably be dependent on your CPU speed, so that was a badly stated question. +[22:16] <jrand0m> server tunnels before the streaming lib will require cpu load whenever a new peer connects +[22:18] <wiht> All right. +[22:19] <duck> are we at #5 already? +[22:19] * ion has quit IRC (Ping timeout) +[22:19] <jrand0m> yup +[22:20] * duck mentions the hosting options that home.duck.i2p provides +[22:20] <jrand0m> ooOOoo +[22:20] <duck> it hasnt been tested by anybody besides me though +[22:20] <duck> waiting for betatester Ardvark to show up +[22:20] <jrand0m> so the hosting lets someone run apache / etc? +[22:21] <jrand0m> (or do they have to run the i2p router? +[22:21] <duck> neither +[22:21] <duck> they can put their html files on /home/username/public_html/ +[22:21] <duck> and it will show up on http://home.duck.i2p/~username/ +[22:21] <jrand0m> ah nice +[22:21] <jrand0m> php support? cgi / .pl / etc? or just html? +[22:22] <jrand0m> (thats kick fucking ass, in any case) +[22:22] <duck> php and html +[22:22] <jrand0m> wwwwwwwwwicked +[22:22] <mihi> duck: won't that compromize your anonymity? +[22:22] <duck> how? +[22:22] <mihi> phpshell? +[22:22] <mihi> or is the full apache in a vmware/UML box? +[22:22] <duck> system, exec, etc are disabled +[22:23] <duck> plus the host cant connect to the outsite +[22:23] * wilde has joined #i2p +[22:23] <duck> (it is inside an UML box) +[22:23] <duck> (pl and other cgis are too difficult to debug without shell access, plus they often break) +[22:23] * mihi_backup has joined #i2p +[22:23] <jrand0m> jsp access? :) +[22:23] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:23] <duck> ofcourse not +[22:24] <mihi> and why not ssh access as well, when it's an UML box? +[22:24] <duck> because the average IIP user will start running forkbombs +[22:24] <jrand0m> with ssh access, they could traceroute i2p.dnsalias.net +[22:24] <mihi> man ulimit +[22:24] <jrand0m> ah true +[22:24] <mihi> man limiting cpu time on uml boxes. +[22:25] <mihi> (okay, it will crash apache, shit...) +[22:25] <duck> man run your own host :) +[22:25] <jrand0m> hehe +[22:25] <lucky> hi +[22:25] <duck> I'll add it on the todo +[22:25] <jrand0m> a reliable hosting service provider will RULE +[22:25] <kaji> now all we need is a wiki +[22:25] * wiht has left #i2p (wiht) +[22:26] * lucky has a reliable net connection... +[22:26] <duck> you already have a wiki +[22:26] <jrand0m> kaji> duck.i2p has one +[22:26] <duck> wiki.invisiblenet.net +[22:26] <jrand0m> that too +[22:26] <kaji> oh sweet then +[22:26] <jrand0m> (yeah, the main i2p wiki is http://wiki.invisiblenet.net/iip-wiki?I2P ) +[22:26] * dm has quit IRC (Ping timeout) +[22:28] * mihi is now known as mihi_away +[22:28] * mihi_backup has quit IRC (Ping timeout) +[22:29] <jrand0m> 'k, anything else before we close out the meeting? +[22:29] <kaji> doh, i missed the meeting? +[22:29] <jrand0m> we're not quite done yet, but about it +[22:29] <lucky> meeting? +[22:29] <lucky> Oh, thats so not fair +[22:29] <lucky> i just got home. +[22:29] <wilde> are there logs anywhere? +[22:29] <wilde> meeting log +[22:30] * lucky has a log... +[22:30] <kaji> can some one write a howto for using wget over i2p in windows? +[22:30] <jrand0m> meeting logs at http://wiki.invisiblenet.net/iip-wiki?Meetings +[22:30] <jrand0m> kaji you'll probably need to add the http_proxy to the environment +[22:32] <jrand0m> ok, lets wrap this one up, and I'll post up the logs momentarily. anyone who has anything else can post to the mailing list or just chat on here :) +[22:32] <kaji> also im now sharing /books/ and /audio/ at kaji.i2p and i think i will make a short howto about the bugs in apache alias for windows +[22:32] <jrand0m> word kaji! +[22:32] * jrand0m *baf*s the meeting closed on that note diff --git a/i2p2www/meetings/logs/73.rst b/i2p2www/meetings/logs/73.rst new file mode 100644 index 00000000..ca8deaad --- /dev/null +++ b/i2p2www/meetings/logs/73.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 13, 2004 @ 22:00 CET +============================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/74.log b/i2p2www/meetings/logs/74.log new file mode 100644 index 00000000..5ddaf6ba --- /dev/null +++ b/i2p2www/meetings/logs/74.log @@ -0,0 +1,184 @@ +[22:07] <jrand0m> agenda: +[22:07] <jrand0m> 0) hi (read http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html) +[22:07] <jrand0m> 1) router dev status +[22:07] <jrand0m> 2) twisted-i2p +[22:07] <jrand0m> 3) unit tests +[22:07] <jrand0m> 4) network testing / monitoring +[22:07] <jrand0m> 5) ??? +[22:07] <jrand0m> 0) hi +[22:07] <jrand0m> hi +[22:07] * jrand0m waves +[22:07] <dm> ohhhh meeting! +[22:07] * dm waves back. +[22:07] <jrand0m> 9p gmt every tuesday :) +[22:08] <jrand0m> people should read that url (http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html) since there's stuff in it that I need feedback on during agenda item 4 +[22:08] <jrand0m> 1) router dev status +[22:09] <jrand0m> making progress, code currently in cvs is looking good. i've had a script testing a series of routers for the last day or so and none of them have popped out a single ERROR message +[22:09] <duck> reading... +[22:10] <jrand0m> but of course thats just baseline testing (keeping the routers building tunnels correctly, tunneling data through one to another via i2ptunnel, etc) +[22:11] * jnk has joined #i2p +[22:11] <jrand0m> theres certainly other things that need to be fixed up in the wild, which is why there's going to be a 0.2.3.5 release in the next day or so to confirm functionality or to find new bugs +[22:11] <jrand0m> ok, moving on +[22:12] <jrand0m> 2) twisted+i2p +[22:12] <duck> I do have errors +[22:12] <duck> but probably due to others +[22:12] <jrand0m> dropped messages and unknown tunnels, right? +[22:12] <duck> checking +[22:13] <jrand0m> (those are the errors I see with one of my 'live' routers but not on the test network) +[22:13] <duck> 22:13:15.371 ERROR [ Sender 1148] er.transport.phttp.PHTTPSender: Error sending the message +[22:13] <jrand0m> ah ok, yeah, i've been smacking around the phttp relay too +[22:13] <duck> 21:01:01.509 ERROR [JobQueue28 ] eDatabaseSearchReplyMessageJob: Invalid router info returned from [Rout +[22:14] <jrand0m> hmm that one is funky - could you bounce me the stacktrace? +[22:14] <duck> I'll put it up. +[22:14] <duck> . +[22:14] <jrand0m> gracias +[22:15] <jrand0m> actually, thats going to be a general rule with the future releases - WARN or INFO or DEBUG messages are fine, and ERROR or CRIT messages are things I'd like to hear about +[22:16] <jrand0m> ok, back to 2) +[22:16] <jrand0m> human has put together a way to use i2p via python and the twisted framework (yay!) +[22:17] <jrand0m> see his email for more info (http://i2p.dnsalias.net/pipermail/i2p/2004-January/000100.html) +[22:17] <jrand0m> anything to add human? (if you're here) +[22:17] <duck> it is _so_ cool +[22:17] <jrand0m> yeah, the sample code for the echo server and client look kick-ass +[22:18] <jrand0m> ok, moving on to 3) unit tests +[22:19] <jrand0m> yeah, there are some unit tests for most of the data structures, but they aren't "one click testable" so I don't run them on every build. +[22:20] <jrand0m> current thoughts are to migrate them to jUnit, as well as to merge as many of the other unit tests currently implemented in the main(..) method of various components (specifically the crypto ones) +[22:21] <duck> probably it is difficult to test more complex things +[22:21] <jrand0m> thats going to come up to be on the critical path sooner rather than later, depending on where the debugging leads us +[22:21] <jrand0m> right, the unit tests as is just test the basics +[22:21] <duck> like routing, tcp stuff etc +[22:21] <jrand0m> right +[22:21] * dm sees a debate on value of unit testing coming. +[22:21] <jrand0m> but things like the AESInputStream can be tested in collaboration with AESOutputStream +[22:22] <duck> unit test = kickass +[22:22] <jrand0m> (and for those watching their logs closely, there's been some funky "pushed back" behavior during decrypt streaming) +[22:22] <jrand0m> definitely. +[22:23] <jrand0m> unit tests are just for the, er, units. not for the larger components (which is what agenda item 4 is about ;) +[22:24] <jrand0m> but in any case, if someone is interested in helping out convert the existing data structure unit tests to the jUnit framework, lemmie know - it'd be much appreciated (and would give you a good foundation of the i2p codebase) +[22:24] * mihi_away is now known as mihi +[22:25] <dm> If it's not done by the weekend I can take a look. I know nothing about unit testing so I could learn through it. +[22:25] <jrand0m> wikked! +[22:25] <dm> No promises though. +[22:25] <jrand0m> right right +[22:25] <jrand0m> ok, moving on to 4) network testing / monitoring +[22:26] <jrand0m> has everyone read http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html? I don't want to just copy and paste that +[22:26] * Frontier has joined #i2p +[22:27] * jrand0m gives people time to digest +[22:27] * dm says... +[22:28] <Frontier> digest wat? +[22:28] <dm> C) but not with automatic sending. +[22:28] <dm> i.e. you type emaillogstojrandom.sh (.bat) +[22:28] <dm> email or post, or whatever. +[22:29] <dm> and when it does that it clears you log, or moves it somewhere, so you don't submit the same data twice. +[22:29] <jrand0m> so basically B +[22:29] <jrand0m> (or A) +[22:29] <dm> Yeah, user-friendly B) :) +[22:29] <jrand0m> thats one of the tricks wrt the data... that log grows to tens of megs per night +[22:29] <jrand0m> right +[22:30] <dm> sorry, didn't see history=false for C. +[22:30] <jrand0m> Frontier) we're discussing section 4 of http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html? +[22:30] <mihi> jrand0m: man bzip2 +[22:30] <dm> So history=false with a script to post on command. +[22:30] <dm> sorry, history=true :) +[22:30] <dm> god, I've made a mess of it. +[22:31] <jrand0m> right mihi, but bzip2 isn't on windows (unless we require it and install it). or do you mean bzip2 has a flag to submit a file to a url? +[22:32] <dm> I wouldn't worry about the size, 10s of megs for the small group of people you have here is fine. +[22:32] <Ophite1> I vote C. +[22:32] <dm> As long as it gets archived when you run the script to submit. +[22:32] <Ophite1> This is a debug client. +[22:32] <Ophite1> A in a production client of course :) +[22:32] <mihi> jrand0m: then use GZipOutputStream +[22:32] <jrand0m> right right Ophite1 ;) +[22:33] <jrand0m> mihi> people might like to read these files ;) +[22:33] <duck> yeah, opt-in for debugging participation, but once you join, make it as easy as possible for the user (so C) +[22:33] <mihi> man zcat ;) +[22:33] <Ophite1> jrandom: gzcat | less ;-) +[22:33] <mihi> Ophite1: zless ;) +[22:33] <jrand0m> C:\Documents and Settings\dev>man +[22:33] <jrand0m> 'man' is not recognized as an internal or external command, +[22:33] <jrand0m> operable program or batch file. +[22:33] <jrand0m> ;) +[22:34] <mihi> cd \cygwin <Ctrl+T> call cygwin.bat +[22:34] * dm twiddles his thumbs. +[22:34] <Ophite1> double-click -> winrar -> view +[22:34] <jrand0m> ok, so we have one B, two C, whats your take mihi? +[22:34] <jrand0m> (and anyone else?) +[22:34] <dm> twiddle thumbs, pick nose, click click. +[22:34] <mihi> double-click - 7zop - view. I'd say C. +[22:35] <mihi> s/7zop/7zip/ +[22:35] <jrand0m> 3 c one b. i kind of prefer c too, and of course if someone /doesnt/ want to submit this data, they can always say so and it won't do shit +[22:36] <jrand0m> i'll see if i can implement both c and b +[22:36] <dm> Looks like C it is. +[22:36] <dm> Don't waste your time, the B person is on dialup and would offer very little data anyway ;) +[22:36] <jrand0m> hehe +[22:36] <jrand0m> well, c is probably going to be implemented on top of b, so it won't take any more work +[22:37] <jar> for me : just like Ophite1 said ! A for prod client, C for debug ... +[22:37] <jrand0m> word jar +[22:37] <jar> just like Ophite1 said ! A for prod client, C for debug ... +[22:37] <Ophite1> obviously not anything other than A for prod client... +[22:37] <jar> just like Ophite1 said ! A for prod client, C for debug ... +[22:37] <Ophite1> that's a no-brainer :) +[22:37] <jar> sorry ... :( +[22:37] <jrand0m> s'all good jar, we won't kickban you (... this time ;) +[22:38] <jrand0m> ok, so i'll get cracking on that, and pretty much once thats tested we'll have a new 0.2.3.5 release (sometime tomorrow) +[22:39] <jrand0m> ok, moving on to 5) ??? +[22:39] <jrand0m> anyone have anything else? questions, thoughts, concerns? +[22:39] * duck offers free hosting +[22:39] * dm accepts free hosting +[22:39] <jrand0m> oh word. yeah, people should host sites on host.duck.i2p, its nice having reachable pages +[22:39] <jrand0m> (of course people should also feel free to host for themselves too ;) +[22:40] <duck> sure, just for those who can't stay online 24/7 +[22:40] <jrand0m> right +[22:40] <mihi> what happened (will happen?) to the streaming api? +[22:40] <jrand0m> mihi> its in the task list, but getting the network functioning reliably is higher priority at the moment :/ +[22:41] <mihi> but it is not dropped completely? (that's what i wanna know...) +[22:41] <jrand0m> i'll get back to the streaming api for the 0.3.1 release (perhaps sooner, but not sure) +[22:41] <jrand0m> its definitely NOT dropped completely. +[22:41] <jrand0m> it will be done. +[22:41] <dm> What's this streaming API? A different way of exposing the network to clients? +[22:42] <jrand0m> dm> http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary +[22:43] <jrand0m> I made what is arguably a mistake of including mode=guaranteed in the router from the beginning instead of putting it in a seperate lib (and now i'm trying to move it out of the router :) +[22:43] <jrand0m> (the insanely awesome benefit of that mistake was mihi coming along and writing i2ptunnel :) +[22:44] * wn-user has joined #i2p +[22:44] <jrand0m> anyone else have anything? +[22:44] * dm gets it. +[22:45] <jrand0m> w3rd +[22:45] <dm> Hmmm, too early to end meeting, ain't it? +[22:45] <duck> what about the hosts.txt +[22:45] <duck> it is growing and growing +[22:45] <jrand0m> well, 45 mins. two weeks ago we had 20 mins +[22:45] <jrand0m> ah, true that +[22:45] <duck> but 75% is offline +[22:45] <duck> and it looks like 50% is permanently offline +[22:45] <jrand0m> prolly +[22:46] <jrand0m> I dunno +[22:46] <duck> just keep it growing, to raise the incentive for a DNS solution :) +[22:46] <jrand0m> heh exactly +[22:46] <Ophite1> I'm all for a little delay, I'm having a lot of fun with all kinds of Windows problems... +[22:46] <dm> Ophite1: windows is the devil! +[22:46] <Ophite1> You never really understand just how awful Windows is, until you write software for it. +[22:47] <jrand0m> reason #941 to use java +[22:47] <dm> Unless you're using .NET. +[22:47] <dm> also known as java++ +[22:47] <Ophite1> dm/jrand0m: it's still running *on* Windows, and there are still some things you just keep running into. +[22:47] <duck> jrand0m: those last patches, would they solve disconnects? or more connection problems +[22:47] <Ophite1> Path lengths for example. Bloody unicode. +[22:48] <mihi> Or not to use \n in file names ;) +[22:48] <mihi> which will crash cvs anyway (on *nix, BTDT) +[22:48] <jrand0m> duck> no patches today are critical +[22:48] <duck> from yesterday I mean +[22:49] <dm> What happens if you use \n in a filenamE? :) +[22:49] <mihi> dm: try it ;) on *nix, nothing happens, as long as you don't try to run cvs update afterwards. +[22:49] <jrand0m> oh, yesterday there were Good patches that would solve some (most? all?) i2ptunnel Peer unreachable messages. not i2cp disconnects though +[22:50] <dm> I think it would throw an exception. +[22:50] <jrand0m> (which is one of the reasons 0.2.3.5 is coming out) +[22:51] <mihi> dm: it works w/ local repository, but not w/ pserver or ssh. +[22:51] <mihi> something like 'protocol error'. +[22:51] <mihi> (the protocol terminates file names by \n ;) ) +[22:51] <Ophite1> sort of like what happens with direct connect if you have filenames with $ and | in them. I hate DC. +[22:51] <duck> . +[22:52] <Ophite1> No matter what I code, ever, it could never be that bad :) +[22:52] <jrand0m> naw, you c devs just treat \0 as special instead of $ ;) +[22:52] <jrand0m> ok, anything else on i2p or we good to go? +[22:53] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:54] <jrand0m> 'k thazzit +[22:54] * jrand0m *baf*s the meeting to a close diff --git a/i2p2www/meetings/logs/74.rst b/i2p2www/meetings/logs/74.rst new file mode 100644 index 00000000..0977e894 --- /dev/null +++ b/i2p2www/meetings/logs/74.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 20, 2004 @ 22:00 CET +============================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/75.log b/i2p2www/meetings/logs/75.log new file mode 100644 index 00000000..ee9bca18 --- /dev/null +++ b/i2p2www/meetings/logs/75.log @@ -0,0 +1,98 @@ +[22:03] <jrand0m> 0) hi +[22:03] <jrand0m> 1) router dev status (0.2.4) +[22:03] <jrand0m> 2) RTCP +[22:03] <jrand0m> 3) i2p.net +[22:03] <jrand0m> 4) ??? +[22:03] <jrand0m> 0) hi +[22:03] * jrand0m waves +[22:03] <jrand0m> this is meeting $num +[22:03] <duck> . +[22:03] * mihi_backup has joined #i2p +[22:03] <jrand0m> logs will go up onto the wiki once we're through +[22:03] * Robert has quit IRC (Ping timeout) +[22:04] * baffled has quit IRC (Ping timeout) +[22:04] <jrand0m> ok, moving on (hopefully battling ping timeouts)... 1) router dev status +[22:04] * baffled has joined #i2p +[22:05] <jrand0m> some more bugfixes this week, and a large part of the delay and associated message loss has been narrowed down the PHTTP transport +[22:06] <jrand0m> to avoid repeating myself from the email [http://i2p.dnsalias.net/pipermail/i2p/2004-January/000113.html], so, does anyone have any questions / comments on the dev status? +[22:06] <duck> yes +[22:06] <jrand0m> sup? +[22:06] <duck> seems that still after a while the whole tunnel thing locks up +[22:07] <duck> then madman2003 and human have to shout at me +[22:07] <duck> and restart everything +[22:08] <jrand0m> hmm, yeah, I think thats due in large part to the fucked up nature of the 0.2.3.5 PHTTP code. There are some routers out there that are only reachable via PHTTP, and if they are still running plain 0.2.3.5, they won't be able to talk to each other (but will be able to talk to you) +[22:08] * jar has joined #i2p +[22:08] <madman2003> i'd like to say one thing(a bit offtopic): a 404 page in 0.3 would be nice, because a lot of browsers get confused if they don't get an expected response +[22:08] <jrand0m> that means that whenever you build a tunnel through them, your tunnel is unreachable +[22:09] * DrWoo has quit IRC (Ping timeout) +[22:09] <jrand0m> duck> thats one of the reasons on the 'pro' camp for releasing a 0.2.3.6 asap, with 0.2.4 coming out with RTCP in few days +[22:09] * DrWoo has joined #i2p +[22:09] <duck> ok, so that is phttp part? +[22:09] <jrand0m> (the 'con' camp being led by "upgrading sucks") +[22:10] <jrand0m> hmm? the phttp code has been patched in cvs +[22:10] <duck> what con camp? +[22:10] <jrand0m> madman2003> I think baffled might be looking at that :) +[22:10] <madman2003> upgrading is easy :) +[22:10] <kaji> upgrading rox +[22:10] <madman2003> with i2pmgr it's even easier +[22:11] <madman2003> just a touch of a button :) +[22:11] * Robert has joined #i2p +[22:11] <baffled2> I'm looking at it madman might be a while! +[22:11] <jrand0m> well, the con side is that if there's a release (in, say, a few hours), people will have to do another upgrade in, say, 2-3 days +[22:11] <jrand0m> if thats fine, i can wrap up a 0.2.3.6 quite easily +[22:11] <duck> updating makes me happy +[22:12] <kaji> what does .6 fix? +[22:12] <baffled2> I'd say go for it most of us don't have any problem with upgrading regularly. +[22:12] <madman2003> i'd upgrade every 24 hours if that does it +[22:12] <jrand0m> 0.2.3.6 fixes PHTTP to be, er, functional +[22:12] <jrand0m> ok cool +[22:13] <jrand0m> i'll get a 0.2.3.6 wrapped up after the meeting then (perhaps 1-2 hours to clean up) and post on the list when its ready +[22:13] <jrand0m> (as well as here) +[22:13] * Masterboy has quit IRC (Ping timeout) +[22:14] <jrand0m> ok, anything else for the dev status, or shall we jump to 2) RTCP +[22:15] * jrand0m jmp 2 +[22:15] <madman2003> you can always get back to it +[22:15] <jrand0m> right right +[22:15] <jrand0m> ok, rtcp is coming along, and I'm hoping to have the client side libs working after a few more hours of coding +[22:16] <jrand0m> Kirk brought up a good point on the list for chaining - in theory, all of these relays could have an inter-relay connection to build a virtual relay network +[22:16] <jrand0m> but, well, that essentially grows into IRC, or another full on anon network +[22:17] <madman2003> you mean totally eliminating PHTTP? +[22:17] <jrand0m> while thats possible (and quite interesting), I think for now we'll just have the stand alone RTCP relay (and/or integrated relay in the router) +[22:18] <jrand0m> madman2003> no, PHTTP will stay (if only for time sync and people behind HTTP only firewalls), but RTCP provides a faster, low latency alternative +[22:18] <madman2003> (i'd intergrate in the router, because that would spread the load of the relaying) +[22:18] <jrand0m> agreed +[22:19] <jrand0m> basically the topology I forsee with the RTCP is everyone who can have a reachable address will run their own RTCP relay (with their own targetId on that), plus anyone who doesn't have a reachable address can just pick any of those that do and create a target on them +[22:20] <jrand0m> these relays essentially become switchboards for peer comm, but in a fully distributed fashion (since none of them depend in any way on any of the other ones) +[22:20] <madman2003> or use multiple relays if the there are more relays then people who need relays +[22:20] <baffled2> How would folks find the various rtcp relays? +[22:20] <madman2003> phttp :) +[22:20] <jrand0m> right, thats a good point - routers can create targets on multiple relays +[22:20] <jrand0m> baffled> rtcp relays will be listed in a router's RouterInfo (published in the networkDb) +[22:21] <jrand0m> basically a router will see "oh, router XYZ has an rtcp address at 127.0.0.1:8999 targetId 3123" and then connect to 127.0.0.1:8999 and request its own target +[22:23] <madman2003> something i just thought off: auto restart of tunnels every 12 or 24 hours +[22:23] <madman2003> and an auto restart of router + the rest every few days +[22:24] * jrand0m is working on making it so that wouldn't be necessary +[22:24] <jrand0m> one of my routers on a linux box has been up without interruption for several days +[22:24] <mihi> madman2003: you can add your own threads to the jvm to quit it after 12 hours +[22:24] <jrand0m> (and it only went offline when I upgraded it) +[22:24] * madman2003 has to go +[22:25] <jrand0m> l8r madman2003 +[22:25] <madman2003> have a nice meeting +[22:25] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:25] <jrand0m> ok, anything else on rtcp? +[22:26] <duck> no, sounds good +[22:26] <jrand0m> ok, moving on to a brief one +[22:26] <jrand0m> 3) i2p.net. +[22:26] <jrand0m> nuff said +[22:26] <jrand0m> 4) ??? +[22:26] <jrand0m> anyone have anything else? +[22:28] <duck> . +[22:28] * jrand0m senses a record breaking 26 minute meeting +[22:29] <Reskill> lol +[22:29] * Reskill ambles in +[22:29] <jrand0m> 'mornin Reskill +[22:29] <jrand0m> ok, I'm going to get working on pushing out a 0.2.3.6, then crunch away on the rtcp code for a 0.2.4 +[22:30] <jrand0m> if there is nothing further... +[22:30] <Reskill> Oo... +[22:30] <baffled2> Okay, I'll see you all when I get home. +[22:30] * jrand0m *baf*'s the meeting closed diff --git a/i2p2www/meetings/logs/75.rst b/i2p2www/meetings/logs/75.rst new file mode 100644 index 00000000..f69c78f5 --- /dev/null +++ b/i2p2www/meetings/logs/75.rst @@ -0,0 +1,7 @@ +I2P dev meeting, January 27, 2004 @ 22:00 CET +============================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/76.log b/i2p2www/meetings/logs/76.log new file mode 100644 index 00000000..e6cf5970 --- /dev/null +++ b/i2p2www/meetings/logs/76.log @@ -0,0 +1,514 @@ +[22:01] <jrand0m> 0) hi +[22:01] <jrand0m> 1) testnet +[22:01] <jrand0m> 2) updated roadmap +[22:01] <jrand0m> 3) updated application list +[22:01] <jrand0m> 4) volunteers needed +[22:01] <jrand0m> 5) ??? +[22:01] <jrand0m> 0) hi +[22:01] * jrand0m waves +[22:01] * mihi waves back +[22:02] * jrand0m has to warn that i've been up for too long, so may be a little out of it +[22:02] <jrand0m> but anyway, as we proceed, everyone should read (or have read) http://i2p.dnsalias.net/pipermail/i2p/2004-February/000132.html +[22:02] <jrand0m> lets jump right into 1) testnet +[22:03] <mihi> you should change the subject for each mail... they all get sorted into one thread here +[22:03] <jrand0m> hah nice +[22:03] * jrand0m tried for consistency (for ease of filtering) +[22:03] <jrand0m> would you like me to add the date to it? +[22:03] <madman2003> how is the testent really doing?(pessimistic opnion please) +[22:03] <jrand0m> madman2003> poorly, but better than before +[22:04] <mihi> jrand0m: date (or meeting number) would be great +[22:04] <jrand0m> 'k mihi, consider it done +[22:04] <jrand0m> (anyone other than me want to give some feedback to madman2003's question?) +[22:04] <duck> madman2004: baffled and me have been connected for 4h now +[22:04] <baffled> Really that long? +[22:04] <duck> before test3 the maximum time was 10 min +[22:05] <jrand0m> w00t +[22:05] <duck> baffled: since 18:15:07 CET +[22:05] <jrand0m> yeah i had a 90m session the other day too +[22:05] <duck> but maybe we are directly hopped +[22:05] <madman2003> and you're sure the link is intact? +[22:05] <jrand0m> duck> all tunnels are 2 hop (unless your router is failing, in which case your tunnels will break at least once) +[22:06] <jrand0m> madman2003> when the tunnels fail, they fail hard +[22:06] <madman2003> how's general latency on the testnet? +[22:06] * Ophite1 has joined #i2p +[22:06] * jrand0m usually gets 2-10s latency through the squid +[22:06] * lucky has joined #i2p +[22:06] <jrand0m> 5-20s latency through irc +[22:07] <madman2003> is the 30 secs delay on local sites fixed yet? +[22:07] <jrand0m> duck> can you /ping duck on your ircd? how long does it take to reply with a CTCP refused error? +[22:07] <jrand0m> (or baffled>) +[22:08] <jrand0m> madman2003> there have been significant bugfixes that would account for 30s+ delays locally +[22:08] <jrand0m> (jobs got locked up causing insane delays) +[22:08] <duck> response to admin request to baffleds ircd is ~8s +[22:08] <jrand0m> duck> to local? +[22:09] <duck> fido ping/pong is 3 seconds, which is local +[22:09] <jrand0m> coo' +[22:09] <duck> for local eepsites it also seems to be ~3s +[22:09] <jrand0m> (still much higher than i'd like, but <<30s) +[22:09] <duck> initial request longer, might be ~30s +[22:10] <jrand0m> interesting +[22:10] <duck> , +[22:10] <jrand0m> ok, so there's definitely still work to be done on the testnet, but there's been progress +[22:10] <madman2003> is the testnet going to run until poor performance becomes perfect, what is the exact requirement of succes? +[22:11] <madman2003> (i know about 3 days of working good) +[22:11] <jrand0m> success == 3 consecutive days of things that should succeed succeeding. +[22:11] <jrand0m> human has volunteered to help out and implement something along the lines of what I posted in the email +[22:11] * mihi floods the testnet with pings ;) +[22:11] * leenookx has quit IRC (Ping timeout) +[22:11] <jrand0m> basically a way we can just leave a pair of bots connected to the two ircds and measure our progress and failures +[22:12] <jrand0m> (yay human!) +[22:12] <mihi> hmm, if there is no netsplit, i2p is working, but you cannot make the other way conclusion... +[22:13] <jrand0m> the i2p roadmap [http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap] has the 0.2.4 release (~= testnet completion) in a week and a half +[22:13] <madman2003> why don't you focus on making local delay <1s? +[22:13] <jrand0m> that i will. +[22:13] <madman2003> good chance that will solve some other problems too +[22:13] <jrand0m> the cause of >1s delay is likely the load +[22:14] <jrand0m> for routers with no peers, local only requests are near instantaneous +[22:14] <jrand0m> (but as the testnet is actually showing some load, we're stressing different things) +[22:15] <duck> baffled and me also had a little chat about making statsbots, but if human wants to do it; cool for me +[22:15] <madman2003> maybe delays have to do with requests being send to other routers +[22:15] <madman2003> before it see that it's local +[22:15] <jrand0m> oh word duck +[22:15] <jrand0m> naw, doesn't work that way madman2003 +[22:16] <jrand0m> (it gets pumped to the client manager first, which checks if its local, and only if it isn't does it get placed in the router's net pool) +[22:16] * madman2003 wonders where all that load is coming from +[22:16] <jrand0m> france. +[22:16] <jrand0m> er, germany. +[22:16] <jrand0m> (since *someone* is pinging everyone ;) +[22:17] <duck> kuala lumpur +[22:17] * duck hopes nobody gets that joke +[22:17] * jrand0m is pleased to meet duck's hopes +[22:17] <mihi> all that pings made my local box thrashing as well... (with no router!) +[22:18] <jrand0m> mihi> the i2cp lib does the crypto ;) +[22:18] * wiht has joined #i2p +[22:18] <madman2003> doesn't i2p protect from ping floods? +[22:19] <jrand0m> madman2003> the load isn't that significant, its just the code currently has very course grain synchronization (and during the testnet thats being adjusted to more fine grained sync) +[22:19] <madman2003> grain sync? +[22:19] <mihi> jrand0m: congrats: seems that ping -ns does not only produce - - - now +[22:20] <jrand0m> lol mihi :) +[22:20] <mihi> why lol? ping -ns never worked for me. (only the synchronized one) +[22:20] <duck> synchronized one never worked for me... +[22:20] <jrand0m> oh really? word, -ns has been working well for me +[22:21] <jrand0m> madman2003> its a tradeoff of memory and CPU vs concurrency +[22:22] <jrand0m> (course grained synchronization minimizes CPU and memory usage, while fine grained synchronization uses more CPU and memory in exchange for higher concurrency) +[22:22] * TrueSeeker has quit IRC (Leaving) +[22:22] * mihi will post ping stats in #flood in a few secs +[22:22] * ion has quit IRC (Ping timeout) +[22:23] <lucky> bah. +[22:23] <jrand0m> but yeah, the plan is to have the testnet wrap up once it passes the 3 day test. my current estimate is the 14th, but we'll see. +[22:23] <lucky> miserably day. +[22:23] <lucky> stupid capitalist pigs +[22:23] <lucky> taking all my money.. +[22:24] <baffled> looks like there a are new goodies in cvs, how long before test4? +[22:24] <jrand0m> not today, hopefully tomorrow +[22:24] * jrand0m is going to bed after the meeting :) +[22:25] <baffled> cool. +[22:26] <madman2003> bye everyone +[22:26] <jrand0m> later madman2003 +[22:26] <madman2003> don't forget the other points of the meeting :) +[22:26] <jrand0m> ok, so thats testnet. anything else on that, or shall we move to 2) updated roadmap? +[22:26] <jrand0m> hehe +[22:26] <baffled> Are there other stressers we need on the test net? +[22:26] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:26] <duck> what date is it? +[22:27] <jrand0m> Feb 3 +[22:27] <baffled> 3rd here. +[22:27] <mihi> 2004-02-03 +[22:27] * leenookx has joined #i2p +[22:27] <duck> ah, thanks +[22:27] <jrand0m> baffled> actually, has anyone tried out i2psnark on testnet? +[22:27] <wiht> baffled: What do you mean by stressers? +[22:28] <mihi> wiht: i guess people stressing the testnet +[22:28] <baffled> Well, the other day you asked aum and I to siess and desist on nntp I was kinda thinking about setting up a 128kbps ogg stream. +[22:28] * mihi 'd like a public echo service set up by anyone - would allow good latency checks +[22:28] <baffled> so those two items I guess. +[22:28] <jrand0m> we've had a good crew hitting the squid +[22:28] <jrand0m> oh, nntp would rule, as would an ogg stream! +[22:29] * jrand0m doesn't recall asking y'all to stop (except maybe temporarily during an update?) +[22:29] <jrand0m> agreed mihi +[22:29] * jrand0m checks what port 'echo' is +[22:29] <jrand0m> 7 +[22:29] <mihi> afaik 9 +[22:29] <mihi> oops ;) +[22:29] <baffled> You may been frazelled about something else at the time. +[22:30] <wiht> Port 7. +[22:30] <duck> 4 +[22:30] * ion has joined #i2p +[22:30] <jrand0m> prolly baffled ;) +[22:30] <duck> echo 4/ddp # AppleTalk Echo Protocol +[22:30] <jrand0m> echo 7/tcp +[22:30] <jrand0m> echo 7/udp +[22:30] <jrand0m> echo 4/ddp # AppleTalk Echo Protocol +[22:30] <wiht> Port 7 for TCP and UDP. +[22:30] <mihi> duck: we want [0-9]*/tcp +[22:30] * duck ducks +[22:31] * Synonymous has joined #i2p +[22:31] <jrand0m> so, anyone want to wrap up human's test app (the echo server and client)? +[22:32] <jrand0m> (though running twisted does seem a bit much for that ;) +[22:32] <duck> the non-twisted one would work +[22:33] <duck> . +[22:33] * jrand0m didn't realize his i2p code could work w/out twisted +[22:33] <jrand0m> but anyway, anyone wnat to volunteer to run point on getting an echo service up? +[22:33] * duck sits on his hands +[22:33] <wiht> Reachable through I2P, or reachable through regular Internet? +[22:34] <jrand0m> through i2p +[22:34] <baffled> I can look into it with some specific specs. +[22:34] <mihi> duck: do ducks have hands? i thougt wings ;) +[22:34] <jrand0m> spec: receive a line of text and echo it back :) +[22:34] <baffled> oh, okay no prob. +[22:34] <lucky> bah... i have to start filing taxes next year! +[22:34] <mihi> jrand0m: s/line/byte chunk/ +[22:34] <lucky> Stupid, damn government... +[22:35] <jrand0m> mihi> line is so much easier to parse ;) +[22:35] <duck> lucky: hush +[22:35] <jrand0m> baffled++ +[22:35] <jrand0m> ok, moving on to 2) updated roadmap +[22:35] * jrand0m directs people's attention to http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap +[22:36] <mihi> jrand0m: why? while (len=in.read(b) != -1) {o.write(b,0,len);} +[22:36] <jrand0m> (which, of course, y'all have already read) +[22:36] * MrEcho has joined #i2p +[22:36] <jrand0m> mihi> single byte messages vs nagle, etc +[22:37] <jrand0m> but anyway, whatever baffled implements to do echoing to support testing is Good +[22:37] <jrand0m> (or you and he can work out what works best for you) +[22:37] * wiht has quit IRC (Ping timeout) +[22:37] <baffled> If you have requirements write them down and let me know later mihi and I'll try. +[22:38] * ion has quit IRC (Ping timeout) +[22:38] <mihi_backup> baffled: not really. if needed adding a newline after a timestamp is no problem at all. +[22:38] * jar_ has quit IRC (Ping timeout) +[22:38] <duck> (netsplit after 4:20) +[22:38] <jrand0m> heh +[22:39] <jrand0m> not good :/ +[22:39] <jrand0m> well, iterative and incremental. +[22:39] <mihi> 22:38:09.430 ERROR [WrC1->Pz83 ] .i2p.i2ptunnel.I2PTunnelRunner: Error sending +[22:39] <mihi> message to peer. Killing tunnel runner +[22:39] <jrand0m> are all 9/10 routers up atm? +[22:39] <jrand0m> (or did one go down?) +[22:40] <jrand0m> i only see 8 +[22:40] <jrand0m> 22:41:02.758 ERROR [TCP Read [9]] er.transport.tcp.TCPConnection: Error reading from stream to [RouterIdentity: +[22:40] <jrand0m> Hash: 4Sb3aJoFusrhpHgYA2xCZCkn0P5jBo822qu9C0wsE1w= +[22:40] * duck did just update +[22:40] <duck> where goes the i2cp admin stuff fit in the roadmap? +[22:41] <duck> afaik that isnt implemented, but 0.2.5 talks about finalizing the spec +[22:41] <jrand0m> current plan is to make I2CP the plain client protocol, leaving admin functionality seperate +[22:41] <jrand0m> (e.g. through the :7655 admin web port) +[22:41] <duck> ok +[22:42] <jrand0m> (and rip out all that other crap) +[22:42] * jar_ has joined #i2p +[22:42] * ion has joined #i2p +[22:42] <jrand0m> ((shrinkingCodebase)++) +[22:43] <jrand0m> does anyone have any thoughts on the two Big Issues? +[22:43] <jrand0m> = aborting the current PHTTP transport (until 2.0) +[22:43] <jrand0m> = keeping support for a restricted route topology at 2.0 +[22:43] <baffled> Well gang, gotta boogie so I'll have to read the logs later. +[22:43] <jrand0m> cool, glad you could make it, l8r +[22:43] * baffled has quit IRC (Leaving) +[22:44] <duck> secure i2cp would lower the direct need for restricted route topology a bit +[22:44] <duck> so thats fine +[22:45] <jrand0m> agreed, though the 'secured' in this sense won't be ideal (all i2cp payloads will of course be encrypted, but sniffers can detect that $client is sending a $n byte message to $destination) +[22:46] <jrand0m> the only difference from the current i2cp is a little update to the authentication protocol / structure +[22:46] <jrand0m> ((well, the $client can't detect $n, since messages are padded randomly. nm) +[22:46] <jrand0m> er, $sniffer, not $client +[22:47] * wiht has joined #i2p +[22:47] <jrand0m> (of course that doesn't defeat a global passive adversary) +[22:48] <jrand0m> anyone have any other concerns / suggestions / ideas / comments? +[22:48] <jrand0m> (on the roadmap) +[22:49] <duck> no +[22:49] <jrand0m> nor do i +[22:49] * jrand0m hops on to 3) updated application list +[22:49] <jrand0m> [insert "mihi rules" rant here] +[22:50] <duck> help jrand0m to say no! +[22:50] <jrand0m> mihi> any thoughts on the muffin thing? http://wiki.invisiblenet.net/iip-wiki?I2PApplications +[22:50] <jrand0m> heh +[22:51] <mihi> jrand0m: you know what i think about that... +[22:51] <jrand0m> (i'm not specifically asking you to integrate it, i'm just seeing what your thoughts are as to whether it would be good) +[22:52] <mihi> httpclient has to get out of i2ptunnel, since i2ptunnel is for stream forwarding and httpclient does content forwarding +[22:52] <mihi> hacking that into i2ptunnel would be just more hackish. +[22:52] <jrand0m> word, so the app down below [Scalable web proxies] +[22:52] <jrand0m> that makes sense +[22:53] <jrand0m> (apps that do One Thing and One Thing Well)++ +[22:53] <mihi> jrand0m: you misunderstood me... +[22:53] <jrand0m> whaddimiss? +[22:54] <mihi> i don't have anything against an app that reads a http request, parses it, sends it over i2p, reads the answer, parses it, sends it back (maybe with filtering) - just not do it as httptunnel does. +[22:54] <mihi> httptunnel forwards everything except the first few lines. +[22:54] <jrand0m> ah you're right +[22:55] * jrand0m doesn't quite have head screwed on correctly +[22:55] <mihi> it would be hard to build effective filtering into it (if it should filter html and not text or sth like that) +[22:55] <jrand0m> right - perhaps just have MUFFIN as a standalone +[22:55] <jrand0m> (filtering whatever comes out of the httpclient) +[22:55] <mihi> so i'd say, an extra app for that. but that would require streaming lib... (or sth like that) +[22:56] * duck likes how you can do proxies xmlrpc/soap with httpclient though +[22:56] <wiht> jrand0m: I did not see an entry for "muffin" on the list of applications. +[22:56] <jrand0m> wiht> http://muffin.doit.org/ +[22:56] <mihi> muffin is a http content filter +[22:57] <mihi> if we have a content filter, we could drop that shitty "proxy" thingy. +[22:57] <jrand0m> duck> hopefully the muffin filter would be set to pass through xmlrpc/soap, only filtering things like VBScript / etc +[22:57] <wiht> I see. +[22:57] <jrand0m> hm, mihi? +[22:57] <duck> ah wait, xmlrpc/soap would be content type xml +[22:57] <jrand0m> mihi> wouldn't it still need to do the name translation, at the least? +[22:58] <mihi> sure, but not as a proxy. http://localhost:12345/duck.i2p/ would work much better. +[22:58] <Synonymous> muffin is gpl, u have to be careful in a public domain project to use gpl code, its still copyrighted ;) +[22:58] <mihi> since you can link to that from the regular web +[22:58] <jrand0m> hrm mihi. +[22:58] <mihi> Synonymous: i2ptunnel is gpl anyway +[22:58] <jrand0m> Synonymous> I2PTunnel is GPL +[22:58] <Synonymous> ya +[22:59] * jrand0m is well aware of the fact that some people consider copyrights valid, and tries to accomodate them. +[22:59] <Synonymous> make sure to put that up where it is visible (if you use muffin) it already says that iptunnel is gpl +[22:59] <jrand0m> of course, if we use muffin it'd get attributed and marked as gpl. +[22:59] <Synonymous> ya thats what i said, becareful about it +[23:00] <jrand0m> (we're not going to get into the copyright discussion here) +[23:00] <jrand0m> ok, any other thoughts on the apps listed? +[23:00] <Synonymous> then don't, and my comment was not intended to start one +[23:00] * duck laughts at http://muffin.doit.org/demo/evil/ +[23:01] <jrand0m> what do y'all think will be necessary app functionality for 1.0? +[23:01] <jrand0m> heh duck +[23:01] <jrand0m> (or are we already there, and 1.0 app functionality == things proxied through i2ptunnel :) +[23:02] <Synonymous> ppl would want functional chat, and maybe a freenet like ap for 1.0 if thats what you are asking, maybe a set of tools so ppl can easily set up their own services on it +[23:02] <mihi> an IM and a naming service are still missing +[23:02] <jrand0m> mihi> irc over i2p? +[23:02] <wiht> Yes, naming service should be in place by 1.0 version of I2P. +[23:03] <duck> eep +[23:03] <mihi> jrand0m: irc over i2p would be okay as well, but a naming service ;) +[23:03] <jrand0m> wiht> do you have any thoughts on whether a naming service will be implemented and ready to go live by April? +[23:03] * jrand0m really doesn't think a naming service is necessary. useful, yes +[23:04] <jrand0m> (all we *need* is a way to easily update a hosts.txt file) +[23:04] <kaji> or a distributed vpn layer +[23:04] <jrand0m> heh +[23:04] <mihi> jrand0m: for me even that (if automated) is a naming service +[23:04] <wiht> jrand0m: Probably by the middle of April. +[23:05] <jrand0m> kaji> a distributed vpn layer is a solid month of 1-2 devs ;) +[23:05] <wiht> I want to make it scalable for accomodating many more entries than we have in hosts.txt now. +[23:05] <jrand0m> 1.0-->3.0 wont have millions of entries +[23:05] <wiht> MrEcho: Do you have any thoughts on this? +[23:05] <jrand0m> thousands, yeah +[23:06] <jrand0m> Synonymous> freenet like app would be cool, but then we need to recruit someone to implement :) +[23:07] <jrand0m> Synonymous> tools to set up services - definitely. hopefully i2pmanager or i2pmole will do +[23:07] <Synonymous> that might be hard, esp since freenet doesnt work hehe +[23:07] <wiht> Speaking of which, what is the progress of I2PManager? +[23:07] <jrand0m> aparently its coming along, the console / cli mode is making progress (aum now uses it to manage his services via init scripts) +[23:08] <jrand0m> i've used the gui, and aum's logged a few bugs on the tunnelmanager that are still outstanding +[23:08] <jrand0m> (due to large #s of tunnels being created, not due to a small #) +[23:08] <wiht> I think I2PManager should be an application for 1.0. +[23:09] <jrand0m> i hope so too +[23:09] <jrand0m> (especially since that would mean we can throw out the kludged installer, since i2pmanager has that built in) +[23:09] <jrand0m> so, people with python experience should get in touch with aum to see how they can help :) +[23:09] <human> re +[23:09] <jrand0m> wb human +[23:10] * human read about the muffin proxy +[23:10] <human> i know about another privacy-oriented personal proxy called privoxy +[23:11] <jrand0m> yeah, privoxy was another one i had been looking at. good potential as well +[23:11] <jrand0m> (reason i leaned towards muffin was the ease of integration, since its java) +[23:12] * jrand0m won't be the one who implements / integrates it, so my view is only a suggestion +[23:12] <@Nightblade> i think a group chat (or irc) would be a good program because if you can get chat to work reliably then you know i2p's latency and stability are good +[23:13] <jrand0m> agreed +[23:13] <Synonymous> how would trent work on such a system though, is it possible to do it with a system of public and private keys (like frost) +[23:13] <Synonymous> the channel would be the 'board' ? +[23:13] <jrand0m> Synonymous> duck has actually done some neat stuff +[23:13] <Synonymous> kool +[23:14] <duck> which is: users login with a secret password to the ircd, the ircd publishes the sha1 of the password +[23:14] <jrand0m> Synonymous> in his modified ircd, you can provide a password that has its hash shown in the ident +[23:14] <Synonymous> it would also be like waste i guess, even though I didnt usei t +[23:14] <jrand0m> duck> though if anyone else creates their own ircd, they can spoof that :/ +[23:14] <duck> so others can check the sha1 against a local list, without requiring a centralized database +[23:15] <duck> sure +[23:15] <jrand0m> but people could just remember what ircd someone usually connects from, i suppose +[23:15] <jrand0m> would it be possible to have a nickserv? +[23:15] * jrand0m doesn't know much about how irc nets work +[23:16] <duck> yes, but I didnt want that +[23:16] <duck> because Trent was made as a temporary hack +[23:16] <jrand0m> right, it'd be Good if we could do without +[23:16] <jrand0m> hehe +[23:16] <jrand0m> until iip 2.0, right? ;) +[23:16] <duck> now it is the longest running joke in the world +[23:17] <duck> . +[23:18] <jrand0m> ok, so if we go 1.0 with: irc, eepsites (and a way to set up your own), squid, and cvs, thats reasonable? +[23:18] <@Nightblade> yeah +[23:18] <jrand0m> (obviously it'd be fantastic if we could include i2psnark, naming, I2PIM, and the other apps) +[23:19] <duck> with irc you mean native i2pirc? +[23:19] <duck> or if not, why not nntp etc too +[23:19] <jrand0m> oh, right +[23:19] <jrand0m> of course +[23:20] * jrand0m !thwaps self. +[23:20] <duck> not too much ofcourse +[23:20] * duck thinks that the pgp keyserver is silly +[23:20] <jrand0m> i just meant that its easy to overwhelm people with options +[23:20] <duck> ah, sure +[23:20] <duck> as in officially bundeled stuff +[23:20] <jrand0m> "why should I use I2P" "well you can [.............]" +[23:20] <jrand0m> right +[23:20] * duck agrees +[23:21] <jrand0m> with i2ptunnel, we can support all that we've seen (and more :) +[23:21] <jrand0m> ok, in that case, I don't think we need to worry too much about the i2papps +[23:21] <mihi> btw: we should deprecate the -nogui option of I2PTunnel... +[23:22] <jrand0m> to default to -nogui? +[23:22] <jrand0m> (or you trying to get us all to use awt? ;) +[23:22] <mihi> no. not to use -nogui at all. -cli and -nocli are more "transparent" +[23:22] <Synonymous> you should also package all these options in 1 distro if you can +[23:22] <jrand0m> ah ok mihi +[23:22] <Synonymous> unlike freenet, which mentions no otehr utilities and its up to you to go find them out +[23:22] <jrand0m> Synonymous> definitely +[23:22] <jrand0m> Synonymous> have you used i2pmgr yet? +[23:23] <mihi> -nogui acts differently whether you use -e "run configfile" or use "configfile" +[23:23] <Synonymous> no, i couldnt get it working :) +[23:23] <jrand0m> (its still pre-alpha, but functional) +[23:23] <jrand0m> ah ok +[23:23] <Synonymous> from before but it didnt try the gui +[23:23] <Synonymous> i might try now that it has one +[23:23] <Synonymous> :) +[23:23] <jrand0m> word, its been makin progress +[23:23] * duck suppresses a yawn +[23:24] <jrand0m> yeah yeah yeah duck, ok ;) +[23:24] <jrand0m> i think thats it for apps - unless someone else has something? +[23:24] <jrand0m> moving on to 4) Volunteers needed +[23:25] <jrand0m> we're making good progress, and the pace is fine and imho sustainable +[23:25] <jrand0m> but we've all been talking about some really neat things that we'd like added on +[23:25] <jrand0m> if there were another N hours in the day, yadda yadda yadda +[23:26] <duck> what do you mean with 'development bandwidth'? +[23:26] <jrand0m> more hours of developer activity +[23:26] <duck> aye +[23:27] <jrand0m> (e.g. 2 developers == 16/20 hours/day) +[23:27] <jrand0m> my gut feeling is of the 'if you build it, they will come' variety +[23:28] <jrand0m> (but i've also worked at companies that thought they had a kickass product, made it more kickass, released it, and didn't see much market activity) +[23:28] * duck doesnt think that hiring cheap indians will work +[23:28] <jrand0m> heh +[23:29] <duck> product marketing != developer marketing +[23:29] <jrand0m> right, i agree +[23:29] <jrand0m> i just meant as an analogy +[23:30] <jrand0m> we'll see how things progress. i just wanted to throw that stuff out there +[23:30] <@Nightblade> it is a complex program which makes it harder to find people who can figure it out +[23:31] <jrand0m> agreed Nightblade +[23:31] * greasyaxelsex__ has joined #I2P +[23:31] <jrand0m> Nightblade> thats what 1.0 release criteria #3 on the roadmap is for: " Javadoc and code walkthrough / guidebook updated" +[23:32] * dm has joined #i2p +[23:32] * wiht has quit IRC (EOF From client) +[23:32] <jrand0m> we currently have a generally up to date wiki providing an overview of the java impl +[23:32] <mihi> hi dm +[23:32] <jrand0m> but i will definintely need help with the documentation +[23:32] <dm> hello mihi. +[23:33] <jrand0m> (since what makes sense to me != what makes sense to people learning the code) +[23:33] * dm accuses jrand0m of using terms he's invented when explaining things. +[23:34] <jrand0m> occationally ;) +[23:34] <Synonymous> i will help wtih the webpage if u want +[23:34] <jrand0m> (though the only thing i knowingly have coined wrt i2p is 'militant grade anonymity' ;) +[23:34] <Synonymous> i already have a template +[23:34] <dm> How far are we from a bugless 0.2.x? I get my broadband in less than a week's time. +[23:34] * wiht has joined #i2p +[23:34] <Synonymous> the website needs major owkr +[23:34] <Synonymous> im working on my own anonymous p2p website, but you can borrow mine :) +[23:35] <jrand0m> hehe +[23:35] <Synonymous> its modeled after freenet's +[23:35] <Synonymous> but better +[23:35] <Synonymous> :P +[23:35] <jrand0m> actually, yeah, perhaps we can start a thread on the i2p list describing goals of the website and seeing how it fits together? +[23:35] <dm> Synonymous: are you building a p2p app, or just the website? +[23:35] <Synonymous> just the website +[23:35] <jrand0m> (and if that traffic grows, we'll move to something like i2p-www@) +[23:36] <duck> ROFL at anonymous p2p website boilerplates +[23:36] <jrand0m> dm> roadmap updated at http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap with 0.2.4 slated for February 14 +[23:36] <Synonymous> explaing anonymous p2p, the different topologies of networks, the philosophy of it, cypherpunkdom, digital imprimature, links to projects, a mailing list for ppl to discuss it +[23:36] <mihi> dm> bugless sw does not exist +[23:36] <jrand0m> duck> gotta keep the anonymity set large ;) +[23:36] <Synonymous> also links to the other website that does that +[23:37] <dm> mihi: does too! +[23:37] <jrand0m> mihi> i worked on one project a few years ago that actually shipped with 0 bugs. no p1 or even p5s +[23:37] <dm> func addints(int a, int b) { return a + b; } +[23:37] <mihi> jrand0m: they just did not find them... +[23:37] <mihi> dm: which language? +[23:37] <jrand0m> mihi> then its not a bug ;) +[23:37] * greasyaxelsex__ has left #I2P (greasyaxelsex__) +[23:37] <dm> pseudo-language +[23:38] <mihi> and how does this pseudo-language react on an overflow? +[23:38] <wiht> dm: In a project with thousands of lines of code, having no bugs is much less likely. +[23:38] <duck> . +[23:38] <Synonymous> so April is the deadline for something for public release? Why not try to recruit some devls, or would it take to long for you to explain to them how it works etc. +[23:39] <dm> input is never over max_value /2 +[23:39] <jrand0m> (we're currently ~20KLOC, using the "grep \; | wc -l" algorithm) +[23:39] <jrand0m> Synonymous> I don't think we want to just go around posting on lists "hey, we're doing a kickass thing, come code on it" (thats essentially a 1.0 announcement) +[23:40] <dm> that's a lotta lines. +[23:40] <dm> Java bloat! +[23:40] <jrand0m> but if there are people who are interested in helping out, i'll most definitely go out of my way to find out how i can get them involved +[23:40] * jrand0m kicks dm +[23:40] <jrand0m> java bloat is when the jvm uses ram. you're suggesting OO bloat +[23:40] <dm> What a project leader jrand0m is. +[23:40] <Synonymous> well, how will u know if ppl are interested if there is no knowledge of it, thats a contradiction +[23:41] <Synonymous> and by 'recruit' i mean email them, not pubically anounce on say, zeropaid, about i2p +[23:41] <Synonymous> like someone did ;) +[23:41] <jrand0m> Synonymous> what are your thoughts on the explanation of that issue from the email? +[23:41] <dm> Right OO bloat. +[23:41] <jrand0m> yeah, I was pissed when someone told me about that zp article +[23:41] <Synonymous> ya your the one that did the interview +[23:41] <jrand0m> (you can read the august iip-dev messages) +[23:41] <Synonymous> they just quoted you? +[23:41] <jrand0m> "interview"? more like some random person on iip asking me questions +[23:42] <dm> mihi: are you working on the streaming lib? +[23:42] <Synonymous> ah :) +[23:42] <mihi> dm:no +[23:42] <mihi> Standard@laptop /cygdrive/c/eigenes/notback/cvsprojects/i2p/i2p/code +[23:42] <mihi> $ grep \; `find . -name "*.java"` | wc -l +[23:42] <mihi> 30593 +[23:42] <jrand0m> ah. +[23:42] <Synonymous> well, make get a list of project leaders for anonymous p2p and say "here is a project you might be interested in looking at, if you have any ideas on code or projects that might help it please let me know" +[23:42] <mihi> 30kLOC ;) +[23:42] <jrand0m> grep -v \^import +[23:43] <jrand0m> Synonymous> stealing project leads == bad form ;) +[23:43] <jrand0m> (there are many good projects, and while I obviously think i2p is important, others are too) +[23:44] <Synonymous> not stealing, and i dont think the 'leader' can be stolen, he would just desolve the project +[23:44] * jrand0m cant believe we're at 30kloc +[23:44] <jrand0m> heh +[23:46] <jrand0m> ok, moving on to 5) ??? +[23:46] <duck> 2 eepsite proposals, for those who dont know what to do: 1) meshmx FE tunnel (with stunnel) 2) pastebin.de site +[23:46] <jrand0m> anyone have anything else to discuss / bring up? +[23:46] <jrand0m> oh word duck +[23:46] <jrand0m> whats pastebin.de? +[23:46] <jrand0m> (similar?) +[23:47] <duck> site where you can paste code/logs/stuff publically +[23:47] <duck> for irc debugging +[23:47] <duck> http://pastebin.de/ +[23:47] <jrand0m> interesting +[23:47] * @Nightblade just prefers flooding channels with code +[23:48] <jrand0m> wow that is one hell of an innovative idea +[23:48] <jrand0m> insanely simple. +[23:48] <jrand0m> focused. +[23:48] <jrand0m> practical. +[23:48] <dm> Only python though? +[23:48] <jrand0m> oh reall? +[23:48] <jrand0m> :/ +[23:48] <duck> I think this one has python highlighting +[23:48] * jrand0m takes back 'practical' ;) +[23:48] <duck> but I have also seen php ones etc +[23:48] <duck> and you might have a general approach +[23:48] <dm> I think I've seen one which accepts any language. +[23:49] <dm> Good idea, mind you. +[23:49] <duck> anyway, just something simple +[23:49] <duck> you dont need highlighting at all +[23:49] <duck> online linenrs would be useful +[23:49] * dm looks at python code. +[23:49] <dm> What's so special about this again? +[23:50] <jrand0m> its got a y +[23:50] * Nightblade sets mode: +o jrand0m +[23:50] <@jrand0m> w00t +[23:50] * Trent@anon.iip sets mode: +o mihi +[23:50] <duck> there is nothing special about it, +[23:51] <dm> A lot of people really like it, I think. +[23:51] <duck> oh, you mean about python +[23:51] <dm> yes, sorry. +[23:52] * duck moves that to 6) offtopic +[23:52] <duck> :) +[23:52] <@jrand0m> heh +[23:52] <@jrand0m> [beuler, beuler] +[23:52] <dm> Sorry, didn't realize you guys were having a meeting. +[23:52] <@jrand0m> every tuesday 9p gmt :) +[23:53] <duck> ok, php stuff: http://pastebin.com/pastebin.php?showsource=php +[23:53] <@jrand0m> anyone have anything else they want to bring up wrt i2p, etc? +[23:54] <@mihi> i2p rocks! +[23:54] <@jrand0m> (if only it were more reliable..) +[23:55] <@mihi> it is more reliable than freenet for me ;) +[23:55] <@jrand0m> heh :) +[23:55] <@jrand0m> if i just hadn't fucked with your i2ptunnel to set the retry count to 0 we'd be fine ;) +[23:56] <@jrand0m> (corrupt a lil data here and there, but that never hurt no one...er......) +[23:56] <@jrand0m> ok +[23:56] <dm> don't baf +[23:56] * @jrand0m isn't going to try to drag it out 4 more minutes to reach 2 hours +[23:57] <dm> do not baf +[23:57] * @jrand0m denies dm and *baf*'s the meeting closed diff --git a/i2p2www/meetings/logs/76.rst b/i2p2www/meetings/logs/76.rst new file mode 100644 index 00000000..7ea7c2bc --- /dev/null +++ b/i2p2www/meetings/logs/76.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 3, 2004 @ 22:00 CET +============================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/77.log b/i2p2www/meetings/logs/77.log new file mode 100644 index 00000000..c4cbf715 --- /dev/null +++ b/i2p2www/meetings/logs/77.log @@ -0,0 +1,496 @@ +[22:00] <jrand0m> <incoming> +[22:00] <jrand0m> 0) hi +[22:00] <jrand0m> 1) testnet status +[22:00] <jrand0m> 2) naming in i2p +[22:00] <jrand0m> 3) minwww and i2cp +[22:00] <jrand0m> 4) i2p.net website +[22:00] <jrand0m> 5) ??? +[22:00] <dm> I was thinking the other day, that we could make a .NET interface to I2P. Anyway.. +[22:00] <FireRabbit> well there will be one +[22:00] <madman-away> hello +[22:00] <jrand0m> -1) .net interface would be cool +[22:00] <jrand0m> 0) hi +[22:00] * madman-away is now known as madman2003 +[22:00] <jrand0m> hey y'all +[22:00] <wilde> hi +[22:00] <FireRabbit> <-- will write a .net interface +[22:00] <FireRabbit> anyway hi +[22:00] <jrand0m> r0x0r. +[22:00] <dm> awesome +[22:01] <jrand0m> welcome to the 70somethingth meeting +[22:01] <FireRabbit> <-- needs that URL with the client protocol +[22:01] * ion has joined #i2p +[22:01] <jrand0m> i2p.net/ has links to the wiki, you'll probably want to use the tunnelManager +[22:01] <FireRabbit> ok +[22:01] <jrand0m> (people should review http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html for this weeks status update) +[22:01] <FireRabbit> and that works good in the latest release? +[22:02] <jrand0m> yup, aum uses it (and i just fixed a bug he was running into a few hours ago) +[22:02] <jrand0m> (specs @ http://wiki.invisiblenet.net/iip-wiki?I2PTunnelManager) +[22:02] <jrand0m> ok, movin' on +[22:02] <jrand0m> 1) testnet status +[22:02] <FireRabbit> okc ool yes, +[22:03] <jrand0m> i hate sounding like a broken record here, but... testnet is making progress. +[22:04] <jrand0m> we're still not there, but we have multihour sessions without hiccup on the latest build +[22:04] <jrand0m> some setups aren't giving that level of reliability, but some are. so, we're working on making them all up to speed +[22:04] <FireRabbit> excellent +[22:04] <baffled> We're at least populating the net with animals +[22:05] <jrand0m> hehe +[22:05] <jrand0m> dog, cat, mouse, duck... +[22:05] * wiht has joined #i2p +[22:05] <FireRabbit> rabbit! +[22:05] <baffled> maybe I should become a bafflo +[22:05] <human> human! +[22:05] <jrand0m> !! +[22:05] <jrand0m> #animalfarm +[22:06] <dm> dm +[22:06] <jrand0m> but, yeah, thats basically what i've got to say about the testnet status (beyond whats in that status email) +[22:06] <wilde> people will read the logs offline so stay on topic please +[22:06] <jrand0m> heh sorry dad ;) +[22:07] <jrand0m> i think we're still on track for the roadmap +[22:07] <wiht> How many more testnet releases do you plan to distribute? +[22:07] <jrand0m> (plus i've been getting some future things done while running tests, such as the >2 hop tunnels) +[22:07] <jrand0m> wiht> as many as it takes +[22:08] <jrand0m> we're quite close to being done with this round of the testnet though, in my opinion +[22:08] <dm> isn't >2 hop tunnels just a setting? +[22:08] <jrand0m> yes +[22:08] <jrand0m> but in the past it wasn't well tested +[22:08] <dm> cool +[22:09] <jrand0m> while the testnet has been going on, i've had my own seperate testnet on my laptop doing other things +[22:09] * human is open to suggestions to make the ircmonitor more useful +[22:09] <jrand0m> <dreaming>an http listener to render .png on demand?</dreaming> +[22:09] <jrand0m> (or just a /msg cat renderPNG) +[22:10] <human> jrand0m: ok, it should be feasible +[22:10] <baffled> I'd still like to see text summaries. +[22:10] <jrand0m> human++ +[22:10] <baffled> on the ircmonitor. +[22:10] <jrand0m> yes, (text summaries)++ too +[22:10] <human> jrand0m: i was still thinking to make it use gnuplot to generate graphs (instead of gnu plotutils) +[22:11] <jrand0m> potato, potato +[22:11] <jrand0m> (ah, the glory of accents on irc) +[22:11] <FireRabbit> lol +[22:11] <human> jrand0m, baffled: could you give me an example of a text summary? +[22:11] <baffled> If you leave it with me a bit. +[22:11] * dm read that as "potato, potato" +[22:12] <jrand0m> period: 4 hours avg latency: 5.3s missed messages: 95 missed message frequency: 1 every 49 seconds +[22:12] <jrand0m> (perhaps max & min latency) +[22:12] <human> jrand0m: oh, ok +[22:12] <jrand0m> if thats possible / not too much trouble +[22:13] <jrand0m> (at least thats what i think of when i hear text summary) +[22:13] <wilde> max latency, min latency +[22:13] <mihi> human: look @ the summary i give for the ping tester +[22:13] <mihi> hmm, anyone running an echo server this week? +[22:13] <jrand0m> not to my knowledge +[22:14] <human> jrand0m: it should be feasible - i'll basically make the ircmonitor log more raw data, and then i'll create some utility scripts to generate graphs and/or text summaries +[22:14] <jrand0m> kickass +[22:14] <baffled> Sorry mihi, I've been meaning to set yours up but keep forgetting. +[22:14] <jrand0m> i think this will be a good part of the overall functional testing that will grow with us +[22:15] <jrand0m> ok, do we have anything else for the testnet discussion? +[22:16] * jrand0m moves on to 2) naming in i2p +[22:16] <wilde> what's the biggest issue with testnet right now? +[22:16] <jrand0m> biggest issue in testnet is two fold - +[22:16] <jrand0m> 1) finding and fixing the cause of router disconnect +[22:17] <jrand0m> 2) determining the cause of the frequent inter-ircd disconnects +[22:17] <mihi> 1b) coping w/ the fact that routers may disconnect sometimes +[22:17] <jrand0m> right +[22:17] <jrand0m> well, thats not really part of this testnet. +[22:17] <jrand0m> 0.3.x is a series of updates to deal with unreliable routers +[22:18] <jrand0m> thats really why i've been limiting the # of routers that run on the testnet - I know it acts poorly when routers aren't up most of the time +[22:18] <wiht> So you are assuming reliable routers for now, right? +[22:18] <jrand0m> in the 0.2.3.6 testnet, yes +[22:18] <jrand0m> (it recovers from failure, but not quickly enough) +[22:19] <jrand0m> (more graceful recovery will be with multiple leases per destination, increased peer profiling, replay prevention, and retries on alternate lease targets) +[22:20] <jrand0m> ok, moving towards 2) naming in i2p +[22:21] <jrand0m> wiht brings up the core of the issue - global names are really useful, and people like them +[22:21] <jrand0m> (people who arent familiar with this discussion should review http://i2p.dnsalias.net/pipermail/i2p/2004-February/000135.html and the subsequent replies) +[22:22] <wiht> People are used to them, perhaps more than to local names (such as your ICQ analogy). +[22:22] <jrand0m> i'm not sure. +[22:22] <jrand0m> lets say for instance that my name is John. +[22:22] <jrand0m> John isn't global. +[22:22] <jrand0m> not even John Q. Random is global. +[22:22] <jrand0m> nor is John Q. Random born in 1942 in Argentina. +[22:23] <human> well, it has been said that the naming system could have more than one flavor +[22:23] <jrand0m> thats true +[22:23] <human> people could choose a trusted "registration authority" to pick unique names from +[22:23] <jrand0m> absolutely. +[22:24] <jrand0m> though there is the danger there +[22:24] <wiht> The scheme I originally proposed allows for multiple certification authorities, as I recall. +[22:24] <human> jrand0m: of course, it's the tradeoff between comfort and security +[22:24] <FireRabbit> i think someone should write up a quick "centrlized" dns system for the time being then worry about security +[22:24] <human> jrand0m: :-) +[22:24] <FireRabbit> just to make testing easyer +[22:25] <jrand0m> multiple CAs works more easily without the global naming +[22:25] <wiht> jrand0m: Going back to your example, if you are the first to register jrandom.i2p, another John Random would have to register as jrandom2.i2p, for example. +[22:25] <baffled> There isn't really any problem until a conflict occures right? +[22:25] <jrand0m> FireRabbit> I have a strong feeling that what we start with will stay in place for 12+ months. +[22:25] <jrand0m> correct baffled, in any of the plans +[22:25] <wiht> baffled: That is the problem, yes. +[22:25] <jrand0m> wiht> not if there are multiple CAs +[22:25] <FireRabbit> suppose +[22:25] <wilde> eepsites will be a mess if there is local naming, links will not work +[22:25] <baffled> so you only need an authority in the case of conflict resolution. +[22:26] <jrand0m> yes they will wilde +[22:26] <jrand0m> names to be shared and used by others should be fully qualified - self certified - names +[22:26] <wiht> jrand0m: Could you give an example of a self-certified name? +[22:27] <jrand0m> from my email - http://i2pref/[base64 of the NameReference] +[22:27] <wilde> so when I link to your site, and there are three jrandoms out there...which one will be used? +[22:28] * human thinks that a decentralized NS without global naming is Good(TM), because it makes people understand the risks of delegating hostname verification and certification +[22:28] <jrand0m> you link with the fully qualified name - which includes the actual Destination *in it*. +[22:28] <jrand0m> (the NameReference structure from my email) +[22:28] <wilde> so it's like base64 linking +[22:28] <jrand0m> right human - it gets rid of that attack point +[22:28] <wiht> So people will have to type many characters again? That seems self-defeating. +[22:28] * madman2003 has quit IRC (EOF From client) +[22:29] <jrand0m> no one types base64 names +[22:29] <jrand0m> (well, maybe mihi does) +[22:29] <jrand0m> <a href="http://i2pref/[base64 of the NameReference]">jrandom's page</a> +[22:29] <wiht> Oh. That makes sense. +[22:30] * mihi does not *type* anything he can copy&paste +[22:30] <jrand0m> :) +[22:30] <wilde> ok but basically it's long URLS +[22:30] <jrand0m> within eepsites, yes +[22:30] * dm has quit IRC (Ping timeout) +[22:30] <wilde> k that was the question +[22:30] <jrand0m> there are several other scenarios worth looking at though +[22:31] <jrand0m> such as when people want to browse or search for new sites +[22:31] <jrand0m> those are situations where having servers that contain a lot of name references is useful +[22:31] <baffled> Could I propose the idea of a history server rather than an authority. +[22:31] <jrand0m> history server? +[22:32] <jrand0m> ah, so whoever was first "gets it"? +[22:32] <baffled> If someone adopts a new domain which is used the history server sends a note to that person outlining the original holder and how to contact them. +[22:32] <human> maybe an archive to see how a domain name changed during time? +[22:32] <baffled> The conflict can then be resolved by the two parties providing they are both available. +[22:33] <wiht> baffled: What if the new domain's operator is sleazy and continues to hold that already-taken domain name? +[22:33] <baffled> If one party is not available the the conflict goes o the available party in some amount of time. +[22:33] <human> of course it implies to give some trust to the server operator +[22:33] <wilde> that's just authority but in another way +[22:33] <jrand0m> right +[22:34] <baffled> Any arbitrator is either going to act as an authority. +[22:34] <human> well, using non-global names will make people understand that everything built on top of them will ease their life, but possibly make it less secure +[22:34] <jrand0m> right, right +[22:34] <baffled> I don't expect it will become a major problem. +[22:34] <jrand0m> (but why do we need an arbitrator? can't there be two johns in the world?) +[22:35] <jrand0m> if i2p is used for commerce or other such activities, I expect the names to be heavily attacked +[22:35] <baffled> If I want jrandom.i2p and jr won't give it up I can always chose jrandom.i3p or put out a contract. +[22:35] <wilde> I vote for the cryptic nameref solution´ +[22:35] <wiht> Again, that would be fine, as long as _new_ users would understand the implications and which John they want to contact. +[22:35] <jrand0m> (since someone would be able to hijack and get money, etc) +[22:36] <jrand0m> right - its likely we're always going to bundle some name references with the software +[22:36] <jrand0m> (ala the current hosts.txt) +[22:36] <wiht> One idea we should keep, though, is MrEcho's idea of attaching a timed lease to a reference. That way, domain names can expire. +[22:37] <jrand0m> why would domain names want to expire again? +[22:37] <baffled> They're tired of life? +[22:37] <jrand0m> oh, to replace the Destination included? +[22:37] <jrand0m> heh +[22:38] <wiht> Some because the operators want their domain names for just a day or a month. Others, if domain ownership is transferred to a different destination. +[22:38] <jrand0m> hmm, but without uniqueness, there really isnt such a thing as ownership +[22:38] <jrand0m> its not scarce +[22:38] <jrand0m> and if someone wants to change the dest they listen at, they sign a note with their dest saying "hey, I'm moving over here" +[22:39] <wilde> so the nameref is protected by one key, the destination is another +[22:39] <jrand0m> the nameref is signed by the destination's signing key +[22:40] <wilde> you may want another key just for namerefs if possible +[22:40] <jrand0m> hm, i understand and agree, but that'd mean Destination gets yet another 1024bit segment +[22:40] <wilde> so even if a machine gets compromised you can keep the nameref key on a paper +[22:41] * wiht has quit IRC (Ping timeout) +[22:41] <jrand0m> (and Destination is used all over the place) +[22:41] <jrand0m> hmm not sure I follow the compromised part? +[22:42] <wilde> the destination privkey is on the machine all the time +[22:42] <jrand0m> ah right right +[22:42] <wilde> the nameref private key doesn't to be, they can be kept on paper in the wallet +[22:43] <jrand0m> thats a good point. perhaps the comment block could be used for that (containing a PGP signature surrounding the Destination's hash)? +[22:43] <wilde> but that maybe overkill +[22:43] <wilde> i just don't like keeping the most valuable keys on the machine if isn't necessary +[22:44] <jrand0m> right - we need the Destination signing key and the destination decryption key, but nothing else, functionally. +[22:44] <jrand0m> hmm +[22:45] <jrand0m> perhaps the name reference could have a 1024bit public key on it as well +[22:45] <jrand0m> and we'd use that to verify via DSA +[22:45] <jrand0m> rather than the destination's public key +[22:45] <jrand0m> yeah, that'd fly +[22:45] <jrand0m> additional 32bytes, but only for nameReference, not for Destination +[22:46] * jrand0m doesnt know why I thought that'd imply it goes in the Destination +[22:46] <wilde> lots of keys :) but extra security and flexibility +[22:46] <jrand0m> right +[22:46] <jrand0m> (though, c'mon, we know everyone is going to keep their key in the same dir) +[22:46] <jrand0m> ((but maybe commerce shops wont)) +[22:47] <wilde> you can hand over a "domain" but not the destination, or change to someone elses destination +[22:47] <jrand0m> well, ok. i wish MrEcho and wiht were here +[22:47] <jrand0m> right +[22:48] <jrand0m> well, this is all fine and good, and I think it'll fly +[22:48] <jrand0m> but it needs to get coded :) +[22:49] <jrand0m> so, well, perhaps we'll have additional discussions about it later, but until that time, hosts.txt it is +[22:49] <wilde> hire some indians +[22:50] * jrand0m /dcc gets a grant to hire a team of 80 to work on i2p +[22:51] <wilde> :) +[22:51] <jrand0m> ok, do we have anything else for naming, or for the time being are we covered? +[22:51] <baffled> Skip on brother. +[22:52] * wiht has joined #i2p +[22:52] * jrand0m does a hop, skip, and a jump to 3) minwww and i2cp +[22:52] <jrand0m> d'oh, wb wiht +[22:52] <baffled> 1, 2, 5 uh 3 sitr. +[22:52] <wiht> I had trouble getting back on IIP network. I will read logs later. +[22:53] <jrand0m> cool wiht, and we can continue later on the list, etc +[22:54] <jrand0m> ok the other day I finally wrote up why I think i2cp is worth looking into using directly, and sketched up a minimal web system for use in i2p (and for proxying outside web pages through i2p) +[22:54] <jrand0m> (reference the wiki at http://wiki.invisiblenet.net/iip-wiki?MinWWW ) +[22:56] <jrand0m> for HTTP, the cost of establishing and tearing down TCP/IP connections is small, but over I2P, the difference is between 10 destination to destination messages vs 2 +[22:56] * sheer has joined #i2p +[22:56] <duck> did the meeting already start? +[22:57] <jrand0m> yeah, 56 mins ago +[22:57] * jrand0m sends duck to the corner +[22:57] <duck> so I am right on time +[22:57] * wilde has quit IRC (Ping timeout) +[22:57] <jrand0m> heh +[22:57] <baffled> No doubt about it, he's gotta get a new clock. +[22:58] <jrand0m> one part of minwww that I wasn't sure about was whether minwww proxies should automatically also be external gateways as well? +[22:58] * wiht has quit IRC (Ping timeout) +[22:59] <jrand0m> that'd increase the number of outproxies available, decreasing the load +[22:59] <jrand0m> plus with a round robin algorithm tied to the 64/128KB limit, there isn't much likelihood people would use it for large file sharing +[22:59] * wiht has joined #i2p +[23:00] <jrand0m> or should we just have something like a small set list of outproxies (thats periodically updated)? +[23:01] <jrand0m> (or is the idea not worth looking too much into?) +[23:01] * wilde has joined #i2p +[23:02] <jrand0m> (or i've timed out and no one can read anything i've said) +[23:02] <wilde> jrand0m: can see +[23:02] <jrand0m> 'k coo' +[23:02] <baffled> I'll need to understand it better but for now I have another appointment in ten minutes so I'll bbl. +[23:02] <jrand0m> word, l8r +[23:03] <jrand0m> yeah, there's still the absolutely key functionality of i2ptunnel to handle 8bit clean streams +[23:03] <jrand0m> thats necessary for e.g. irc over i2p and such +[23:03] <mihi> jrand0m: don't forget ss[lh] +[23:04] <jrand0m> but for message oriented protocols, such as http, smtp, bittorrent, etc, i2cp may be more appropriate +[23:04] <jrand0m> right, absolutely +[23:04] <jrand0m> (well, more like 'telnet', since ssh over i2p is a bit of an overkill) +[23:04] <wilde> ssh -X +[23:05] <jrand0m> true +[23:05] <jrand0m> (plus certs, etc) +[23:05] <wilde> there is never too much crypto +[23:05] <jrand0m> but if we're pulling web pages through squid in 5-10s, using i2cp would drop that to .5-2s +[23:06] <jrand0m> (without any subsequent tuning of the network, and would reduce overal network load) +[23:06] <wilde> how many man hours does it take to make i2cp? +[23:07] <jrand0m> imho, i2cp has a fairly simple API, bundled into the java i2p SDK +[23:07] <jrand0m> mihi can more fairly say how much effort it is to use / learn it +[23:08] * wiht has quit IRC (Ping timeout) +[23:08] <mihi> it's a bit confusing sometimes (when you have to put a value to the constructor and when to a method after calling default constructor, but w/ i2ptunnel and atalk as examples it should be not too hard. +[23:09] * ion has quit IRC (Ping timeout) +[23:09] <jrand0m> we can obviously improve upon the sdk, i just based it off the JMS api +[23:10] <jrand0m> (and i'd be more than willing to help out anyone who wanted to hack around with it to get familiar) +[23:11] <jrand0m> ok, do we have anything else on the minwww/i2cp? +[23:11] <jrand0m> if not, moving on to 4) i2p.net website +[23:11] <jrand0m> (and there was much rejoicing) +[23:11] <jrand0m> ok +[23:12] <duck> about search functionality +[23:12] <duck> wikipedia uses google for search functionality +[23:12] <jrand0m> thats true. and we're already the #1 result for i2p :) +[23:13] <duck> so a nifty thing might not be needed for searching. +[23:13] <mihi> duck: atm yes ;) +[23:13] <duck> I mean for internal searching +[23:13] <mihi> #1 is www.crestron.com/company_info/i2p/ +[23:13] <jrand0m> ah yeah, i forgot to bribe the pigeons this week +[23:14] <duck> LeaseSet site:wiki.invisiblenet.net +[23:14] <jrand0m> nice +[23:14] <jrand0m> yeah, absolutely. +[23:14] <wilde> drupal has internal search, and you can filter on content types +[23:15] <wilde> it's also VERY google friendly with the clean urls, no index.php?Zillions of arguments +[23:15] <wilde> everything looks like directories +[23:16] * ion has joined #i2p +[23:16] <wilde> ok I've played around with different CMS:s so far and Drupal is my current favourite +[23:16] <duck> I prefer Ian's home-baked solution +[23:16] <duck> :) +[23:16] <jrand0m> what does it use for a backend? mysql/bdb/txt/? +[23:16] <wilde> it's used by http://kerneltrap.org/ http://www.debianplanet.org/ http://www.linuxgazette.com/ +[23:16] <wilde> for example +[23:17] <wilde> it can take heavy loads +[23:17] <wilde> their designs sucks though +[23:17] <wilde> but a nice CSS stylesheet fixes that +[23:17] <wilde> here some other somewhat better looking ones: +[23:17] <duck> The Drupal core platform, additional plug-in modules, and many theme templates are freely available for download under the GNU GPL. Drupal, written in PHP and using either MySQL, PostgreSQL or mSQL as the database backend, can run on many platforms, including Apache or Microsoft IIS web servers. +[23:17] <wilde> http://www.sudden-thoughts.com/ +[23:17] <jrand0m> thats an important point - we need to make sure the underlying software can support the design (and the design can be workable on the underlying software) +[23:18] <wilde> http://www.codemonkeyx.net/ +[23:18] <wilde> http://www.disguast.org/index.php +[23:18] <wilde> http://trip.ee/ +[23:18] <wilde> http://www.blainepeterson.com/image +[23:18] <wilde> . +[23:19] * jrand0m gets the feeling wilde is a raving drupal fan :) +[23:19] <wilde> I'm starting to become that yes, as I like the information management ideas behind it +[23:19] <wilde> everything is a node +[23:20] <wilde> great taxonomy system +[23:20] <wilde> you can create vocabularies for Geographic location, content type, language, etc +[23:20] <wilde> and create custom urls that filters on content those +[23:21] <jrand0m> could it essentially include two blog sections on the homepage? e.g. one small blog area containing titles of the most recent dev blogs, and the main large seperate blog area containing the most recent i2p announcements? +[23:21] <wilde> and it's updated often and the changes are good +[23:21] <duck> in other words we are stupid that we dont have drupal already +[23:21] <wilde> we have duck +[23:21] <wilde> drupal.i2p.net +[23:21] <jrand0m> :) +[23:21] <wilde> you're so in the 90:s duck +[23:22] <duck> that is good +[23:22] <wilde> the design sucks of course +[23:22] <duck> cause that design is so in the 80:s +[23:22] <jrand0m> lol +[23:22] * wilde mud wrestles with duck +[23:22] <jrand0m> right, there are 3 different things that need to get worked out - the tech, the IA, and the graphic design +[23:23] <wilde> you could try the user interface +[23:23] <wilde> login: test pw: test +[23:23] <duck> warning: Bad arguments to implode() in /var/www/html/i2p/modules/project/issue.inc on line 360. +[23:23] <duck> user error: You have an error in your SQL syntax near ') AND (p.state = 1 OR p.state = 2) ' at line 1 +[23:23] <duck> query: SELECT COUNT(*) FROM project_issues p LEFT JOIN node n USING (nid) WHERE n.status = 1 AND () AND (p.state = 1 OR p.state = 2) in /var/www/html/i2p/includes/database.mysql.inc on line 90. +[23:23] <jrand0m> search still doesn't work wilde, right? +[23:24] <duck> user error: You have an error in your SQL syntax near ') AND (p.state = 1 OR p.state = 2) ORDER BY n.changed DESC LIMIT 0, 20' at line 1 +[23:24] <jrand0m> oh nice1 duck +[23:24] <duck> query: SELECT n.nid FROM project_issues p LEFT JOIN node n USING (nid) WHERE n.status = 1 AND () AND (p.state = 1 OR p.state = 2) ORDER BY n.changed DESC LIMIT 0, 20 in /var/www/htm +[23:24] <duck> sucky +[23:24] <jrand0m> AND () AND +[23:24] <wilde> whoops, i had some problems with search i must admint +[23:25] <duck> . +[23:25] <wilde> there is some full text indexing cron script not yet configured +[23:25] <wilde> 2 minutes and duck crashed my life work +[23:25] <jrand0m> (!hi5 duck) +[23:26] <jrand0m> but i do think its worth looking at +[23:26] <wilde> what did you do duck? +[23:26] <jrand0m> i don't know if we're at the point where we want to commit to some CMS yet +[23:26] <wilde> no +[23:26] <jrand0m> (s/some/some specific/) +[23:27] <duck> jrand0m did already make an overview of the requires features didnt he +[23:27] <jrand0m> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html +[23:27] <duck> so now all parties should come with proposals and the price +[23:28] <duck> ofcourse the winning solution will be paid in i2p stocks +[23:28] <jrand0m> which, let me tell you, is quite valuable +[23:28] <jrand0m> *cough* +[23:29] <jrand0m> you'll get your own @i2p.net email +[23:29] <jrand0m> and chicks will love you +[23:29] <jrand0m> (or guys, whatever) +[23:30] <wilde> we had some CMS options +[23:30] <wilde> we should go for some CMS +[23:30] <wilde> and wiki isn't really a long term solution +[23:30] <jrand0m> yeah some listed in point 4 @ http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html +[23:30] <jrand0m> agreed, for the website itself +[23:31] <jrand0m> a wiki based section of the site might be good though, perhaps for the user guide / hackers guides +[23:31] <jrand0m> (but not for everything) +[23:32] <wilde> what about the hosting? +[23:32] <jrand0m> there's always the 53 entries at http://dmoz.org/Computers/Software/Internet/Site_Management/Content_Management/Open_Source/ +[23:32] <wilde> it should survive a slashdot +[23:32] <jrand0m> hosting? +[23:32] <jrand0m> ah, right. +[23:33] <jrand0m> thats actually a really huge draw of plain HTML in and of itself +[23:33] <jrand0m> (dirt easy to mirror) +[23:33] <wilde> and on +[23:33] <wilde> http://www.oscom.org/ +[23:33] <jrand0m> i2p.net is at a colo that is used by several large sites +[23:34] <jrand0m> ah right +[23:34] * jrand0m would love if people would keep at it and find the Right solution +[23:35] <wilde> http://www.opencms.org/ is interesting +[23:35] <wilde> but's maybe too corporate +[23:35] <wilde> with workflows, projects, etc +[23:35] <wilde> I really liked, used it for one project +[23:36] <jrand0m> interesting +[23:36] <wilde> but its java ;) +[23:36] <jrand0m> hmm, and xml +[23:36] <wilde> jsp templates etc +[23:36] <wilde> tomcat +[23:36] <jrand0m> (or jetty) +[23:36] <jrand0m> ((or resin)) +[23:37] <duck> (((lisp))) +[23:37] <wilde> I would never use if for this project, it's really too heavy +[23:37] <jrand0m> wilde> would you be willing to look over the main CMSes and map out pros and cons? +[23:38] <wilde> i have :), and chose Drupal ;) +[23:38] * jrand0m should have known +[23:38] <wilde> I've tried about ten of the major ones +[23:38] <wilde> for some earlier projects +[23:38] <wilde> different CMS works for different projects +[23:39] <duck> so say drupal is used +[23:39] <wilde> Zope and friends are nice too +[23:39] <duck> is the structure clear? +[23:39] <duck> is the next step doing the gui? +[23:40] <wilde> it's really just a CSS template that's needed for the gui, some changes to the xtemplate to prettify things +[23:41] <wilde> www.csszengarden.com could be an inspiration +[23:41] <jrand0m> wilde> could it essentially include two blog sections on the homepage? e.g. one small blog area containing titles of the most recent dev blogs, and the main large seperate blog area containing the most recent i2p announcements? +[23:41] <jrand0m> basically I want to avoid dev blog entries pushing news & announcements off the main stage +[23:42] <wilde> jrand0m: don't know, gonna check, blogs doesn't have to go front page, i configured it that way +[23:42] <jrand0m> ah cool +[23:42] <wilde> we can change to just stories go front page +[23:42] <wilde> everything that is a node could be frontpage, polls, stories, book pages, articles etc, +[23:43] <jrand0m> would it be possible to have stories at the top, with latest N blog entries below? +[23:43] * jrand0m stops micromanaging +[23:43] <wilde> blogs are linked to the bottom left right now, +[23:44] * godmode0 has joined #i2p +[23:44] <wilde> there are nice galleries as plugin, good for screenshots +[23:44] <jrand0m> word +[23:44] <wilde> the filestore plugin would be nice too +[23:45] <wilde> and more cvs, developer plugins too +[23:45] <wilde> and mailinglist +[23:45] <jrand0m> I'm no CMS expert, and it sounds like you've done your homework and are enthusiastic about it +[23:45] <jrand0m> w0ah nice +[23:45] <wilde> jrand0m: i need people pulling the brake for me sometimes :) +[23:46] <wilde> but the design really must be fixed, who are the design gurus here? +[23:46] * wilde can't stand poor design, wikis and current drupal kills him +[23:46] * jrand0m points at DrWoo and frontier +[23:46] <wilde> anyone here now? +[23:47] <duck> no, I left +[23:47] * jrand0m stares at the lurkers +[23:47] <wilde> so what should the site communicate? +[23:47] <duck> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html +[23:47] <wilde> this is a bit broader, we have marketing and donations to think of +[23:48] <jrand0m> (what duck said) +[23:48] <wilde> yeah i've read that, but we are more people here :) +[23:48] <jrand0m> :) +[23:48] <duck> but the puny humans dont matter! +[23:48] * wilde attaches to the borg collective +[23:49] <jrand0m> obviously one of the things I'd like the web site to communicate is "hey, this is a kickass project, you devs should join us and work for the revolution" +[23:49] <duck> ok; I am falling asleep +[23:49] <duck> enjoy +[23:49] <jrand0m> heh cool duck, g'night +[23:49] <duck> wilde: cool work on the CMS stuff +[23:49] * wilde remembers the thing about 80:s design, 5 months of work! +[23:50] <jrand0m> well, good thing we have 2 months then ;) +[23:50] <wilde> night duck +[23:50] <duck> oh yes, the design should BEG for peer reviews and useful comment +[23:50] * ion has quit IRC (Ping timeout) +[23:50] <jrand0m> agreed +[23:50] <wilde> about the toopie +[23:51] <jrand0m> i like 'im, he's humorous, simple, and topical +[23:51] <wilde> doesn't toopie look a bit ... hmm... stupid +[23:51] <jrand0m> (and he can serve as an icon with nearly any purpose) +[23:51] * ion has joined #i2p +[23:51] <wilde> he squints +[23:52] <jrand0m> heh i think we can wrestle up a top-left-logo-quality toopie +[23:52] <jrand0m> there've been a lot of revs going around for different purposes +[23:53] <wilde> i like him, but he must meet a personality consultant +[23:53] * jrand0m suggests bouncing some ideas off DrWoo, both for the design and toopie stuff +[23:54] <wilde> agreed +[23:54] <wilde> ok maybe we should leave it there +[23:54] <jrand0m> there's no rush, lots to digest and churn through +[23:54] <wilde> but please it you find this new kickass CMS, scream out +[23:54] <duck> can we have this as background: http://www.artchive.com/artchive/B/bruegel/death.jpg +[23:55] <jrand0m> but I agree with duck, nice work setting up a drupal to work off +[23:55] <jrand0m> that is so going straight to my desktop +[23:55] <jrand0m> wow I wonder what text over that would look like +[23:55] <wilde> cool picture +[23:55] <jrand0m> actually, on that note, 5) ??? +[23:56] <jrand0m> anyone have anything else to add? +[23:56] * jrand0m prods the peanut gallery +[23:56] <wilde> it's been very quiet in here today +[23:56] <wilde> everyone comes here to listen to messiah Jrandom +[23:57] <duck> 2h is a bit longish +[23:57] <mihi> *ggg* +[23:57] * jrand0m is just here for the beer +[23:57] <duck> maybe you could try 2 weekly meetings of 30 min each +[23:57] <wilde> nah +[23:57] <duck> and then the layoffs at friday afternoon +[23:57] <wilde> that's too often +[23:58] <jrand0m> i do think 2h meetings are very excessive +[23:58] <jrand0m> (unless they're specifically topical. e.g. a meeting discussing the web page design, or some router functionality, etc) +[23:58] <jrand0m> (hey look, we're meta) +[23:59] <jrand0m> perhaps I should shut up more and limit it to 1h? +[23:59] <jrand0m> or perhaps the bulk of the 'meeting' should go to the mailing list, with #i2p for discussion? +[23:59] * godmode0 has quit IRC (Ping timeout) +[23:59] <wilde> the mailinglist could be used more for discussions +Session Time: Wed Feb 11 00:00:00 2004 +[00:00] <duck> I think that the heavy email pre-logs are already good +[00:01] <jrand0m> so maybe the weekly meetings turn more into "ok guys, whats up? anyone have anything to discuss?" +[00:01] <jrand0m> (but open ended meetings like that are a danger in and of themselves) +[00:01] * godmode0 has joined #i2p +[00:02] <jrand0m> ok, maybe we can move this meta to the list or to later +[00:02] <jrand0m> we've already broken the 2h mark +[00:02] <jrand0m> so... +[00:02] * jrand0m winds up... +[00:02] <fidd> :) +[00:02] * jrand0m *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/77.rst b/i2p2www/meetings/logs/77.rst new file mode 100644 index 00000000..22dbea0f --- /dev/null +++ b/i2p2www/meetings/logs/77.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 10, 2004 @ 22:00 CET +============================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/78.log b/i2p2www/meetings/logs/78.log new file mode 100644 index 00000000..feed6844 --- /dev/null +++ b/i2p2www/meetings/logs/78.log @@ -0,0 +1,286 @@ +Considering we did not have a very official meeting do to Jrand0m not +feeling very well, here are my logs of the meeting from slightly +before it started to sometime after it ended. I have edited out the +kick offs and start screens from iip restarting at least twice during +that period. If someone else has better logs feel free to replace +these. (baffled) + +<human> baffled: we're experimenting a psychic communication towards jrand0m, to ask him to be here for the meeting +<human> baffled: just focus your mind on him, and help us +> Don't we have to hold hands or something like that? +<human> baffled: if it helps you focusing your mind... well, yes +> Cool, gimme your hand I'm commensing to focus! +<UL > +<li> human gives his hand to baffled +</UL> +human has changed the topic on channel #i2p to I2P meeting: hold the hand of your neighbour, focus your mind on jrand0m, and ask him to come here +thecrypto (~thecrypto@anon.iip) has joined channel #i2p +<UL > +<li> baffled whipes the sacred potato-chip oil off his fingers and takes humans hand. +</UL> +<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> human: doesn't he make up a pre meeting agenda, you can grab that and direct the meeting +<human> DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>: er... why me? +Rain (Rain@anon.iip) has joined channel #i2p +<human> DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>: (i didn't see any meeting agenda, though) +<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> human: why not, you're sober +<wilde> let's make an agenda ourselves +<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> yeah you guys know the general issues +<wilde> there are many topics to discuss +<UL > +<li> human will direct the meeting in exchange of the sacrifice of the first daughter of every participant +</UL> +<wilde> funding, strategy, marketing, website, recruiting more developers and powerusers, etc +<human> wilde: i agree, we could informally talk about the recent history of I2P +<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> wilde: open a text window and quickly make a numbered agenda +<UL > +<li> human agrees with wilde +</UL> +> As the first item don't we need to add massive responsibilites to jrandom in absentia? +Signoff: wilde (Ping timeout) +Signoff: ion (Ping timeout) +<UL > +<li> human agrees with baffled, too +</UL> +wilde (~anon@anon.iip) has joined channel #i2p +<wilde> back +> you're the first to say anything your in charge. +<wilde> who? me? +jar (jar@anon.iip) has joined channel #i2p +> quit looking surprised. +<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> you guys are funny :) +> hey jar. +<jar> 'lo baffled :) +<jar> 'lo i2p ! +ion (ion@anon.iip) has joined channel #i2p +<UL > +<li> human started logging the meeting (or whatever it will be) +</UL> +> We elected wild to run the meeting because he was the first to say anything after meeting time. +<wilde> ok +jrand0m (jrand0m@anon.iip) has joined channel #i2p +<wilde> 1. Hello +<wilde> 2. Status I2P +<wilde> 3. How to help I2P Project +<wilde> 4. Recruiting more developers +<wilde> 5. Raising money (donations, selling t-shirts) +<wilde> 6. General discussion +<human> jrand0m: has appeared!!! +<wilde> hey jrand0m! +> I'll take a t-shirt. +<human> our experiment succeeded!!! +<jrand0m> shit thought I missed it :) +<UL > +<li> jrand0m leaves the floor to wilde ;) +</UL> +> You better look back through the log jrandom. +<wilde> ok boss you could modify the agenda as you like +<jrand0m> <a href="http://i2p.dnsalias.net/pipermail/i2p/2004-February/000144.html">http://i2p.dnsalias.net/pipermail/i2p/2004-February/000144.html</a> +<UL > +<li> jrand0m just posted +</UL> +> Are the t-shirts good? +<jrand0m> they had better be +<UL > +<li> jrand0m apologizes for being late, been avoiding looking at the monitor today (killer headache) +</UL> +> No apology necessary or expected. +<wilde> np, we prepared an emergency plan +<wilde> everyone taking a job at McDonalds<a href="iip-wiki?action=edit&id=McDonalds" class=wikipageedit>?</a> and hiring indian programmers for the money +Signoff: ion (Ping timeout) +<jrand0m> hah nice +<jrand0m> perhaps we can jump into that agenda, or are we on 1, 2, 3, 6? +<wilde> 0. +<wilde> 1. Hello +<wilde> Hello I2P +<fidd> hi +<jrand0m> hi +<jar> hi +<kaji> ah, i made it +<wilde> last hellos? going once, going twice... +<kaji> hi +> Which agenda the one you posted or the oone wild posted? +<jrand0m> perhaps I can help out with agenda 2) status +<wilde> 2. Status I2P +<jrand0m> the router, as is, is nonfunctional +<wilde> so how are we post-testnet? +> can we cote on that? +<jrand0m> post testnet, yes, but I introduced two bugs in the process +> vote. +<jrand0m> vote on whether its nonfunctional? +> Right. +<UL > +<li> jrand0m wonders if we vote hard enough it'll be functional again +</UL> +<kaji> its dead for me +> oh, nevermind. +> well, we held hands and you appeared. +<jrand0m> hey, worth a shot ;) +<UL > +<li> jrand0m starts a bug-excorcism seance +</UL> +> does that make them bogobugs? +<UL > +<li> DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a> sprinkles dried blood on the floor +<li> jrand0m senses that this chant will cause the bugs to dissapear in the next day or two, with an email going out to i2p@ once its ready +</UL> +> oh wooooow! +<kaji> i switched to j2sdk1.4.2_03 to get ant to work on XP, i wonder how much of and effect it has on the router not working +<wilde> so there's a short i2p vacation +<jrand0m> none, I use that build on xp +<jrand0m> the bug is programmer error, probably a trivial one too +<jrand0m> (but quite fatal) +<jrand0m> right wilde +<jrand0m> but after that, I've been making a bunch of progress on the docs for 0.2.5 and 0.3 +<jrand0m> so I don't think they'll be a full two weeks out +<jrand0m> but we'll cross that bridge when we come to it. +<wilde> nice, any application improvments anyone? +<jrand0m> one idea - on the testnet, we focused a lot on irc and echo, more than eepsites +<UL > +<li> wilde notes in the black book who hasn't done todays homework, a cool I2P application +</UL> +> Do you think they suffered for that? I certainly do. +<jrand0m> having lots of clients (aka destinations) on a single router increases the load, and we may want to think about trimming down our test scope, perhaps +<jrand0m> there's also a discussion wrt perhaps revisiting the keysize of the crypto to reduce the load (for another day after we have more metrics, etc) +Signoff: Robert (Ping timeout) +> What do you consider a lot of clients on one router? +<jrand0m> I dont know, I would like once 0.2.4.x is out and usable that we can use both IRC and eepsites +<jrand0m> that depends on the computer +<wilde> so what's best for now? eepsites or irc? +<UL > +<li> jrand0m wants both, and we will have both functional in the mid and long run +</UL> +<jrand0m> anyway, we can see as 0.2.4.x comes out. perhaps both will be fine again. +<wilde> yeah but what's most useful for debugging? continous connections or sporadic ones? +<jrand0m> both ;) +<wilde> lighweight irc, or eep graphics? +<jrand0m> i2p needs to support long term streaming connections and short term bursty ones +<kaji> what about heavy long downloads? +<jrand0m> right, long term streaming connections +<jrand0m> (though I do think filesharing over i2p would best be served with i2psnark via messages, ala udp) +<wilde> the question really is: you suggested narrowing the test scope, was that to IRC or EEP? +<wilde> (or something else) +<jrand0m> two or three clients will be fine, I just know that running 4+ services may be a bit of an overload for the time being (depending on people's computer) +lucky (~lucky@anon.iip) has joined channel #i2p +<wilde> ok, that's probably wise +<jrand0m> anyone have any dev status for client apps? +<wilde> so the focus should be on services that can us some statistics, like the irc scripts +<jrand0m> that is definitely key. +Newsbyte (~fredisdea@anon.iip) has joined channel #i2p +<jrand0m> woah +<jrand0m> hi Newsbyte +<Newsbyte> ah, jran +<UL > +<li> wilde looks at the clock and at Newsbyte, late arrival, that will cost you an apple +</UL> +<Newsbyte> huh? +<Newsbyte> I never come here +<jrand0m> also, the echo server and client app is great at gathering stats, and doesn't have any irc-specific dependencies. +<wilde> nothing +<Newsbyte> besides, what's an I2P meeting without nop? ;-) +<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> wilde: heh somehow I dont think hes here for the meeting :) +<human> would an eepsite monitoring tool be useful? +<Newsbyte> no nop, no meeting +<UL > +<li> Newsbyte can summarise +</UL> +<wilde> jrand0m: is there something else you'd like to have statistics in the network? +<jrand0m> human> certainly - perhaps some way to do periodic pings of eepsites, maybe keeping track of changes even? +<human> jrand0m: keeping track of what changes? +<jrand0m> I think with the irc scripts giving us long term disconnect / reliability stats, plus the echo app giving us latency, the only thing left is really throughput +<jrand0m> content on the page changing +<Newsbyte> yes, and use more then one server +<wilde> a kb/s meter, I2P Pirate Radio someone? +<jrand0m> hmm? right, when the net is up we usually have between 4-10 servers +<human> jrand0m: it's doable but... how would you use the content change information? +<kaji> i ran a shoutcast stream for a while +<jrand0m> human> that particular aspect wouldn't help me, but would let users use the test (which would tell them whats changed, as well as get them to run the test more [generate more traffic]) +<jrand0m> nice kaji +<jrand0m> yeah, aum's streams were up periodically as well +<human> jrand0m: oh, ok, now i understand +<mihi> jrand0m: a chargen service? ;) +<madman2003> bye everyone, good luck with i2p +<wilde> so throuhput is one stat that would be interesting/useful +<jrand0m> later madman2003 +<wilde> cya madman2003 +Signoff: madman2003 (..12(. www...nnscript...de .12.::. .N.o.N.ame.S.cript 3...8 .12.::. www...XLhost...de. .12.).) +> Well, I have another meeting at five as usual so I'll bbl. Remember to put me down for a t-shirt. +<jrand0m> yes mihi, that'd work (but streaming .ogg sounds cooler) +baffled (~kirk@anon.iip) has joined channel #i2p +mrflibble (mrflibble@anon.iip) has joined channel #i2p +-Trent@anon.iip- The nickname baffled is not registered +Ocelot (~Ocelot@anon.iip) has joined channel #i2p +Rain (~Rain@anon.iip) has joined channel #i2p +nickthief61599 (~chatzilla@anon.iip) has joined channel #i2p +lucky (~lucky@anon.iip) has joined channel #i2p +backup (~ypo@anon.iip) has joined channel #i2p +Sonax (~Sonax@anon.iip) has joined channel #i2p +jar (jar@anon.iip) has joined channel #i2p +wilde (~anon@anon.iip) has joined channel #i2p +Signoff: backup (Ping timeout) +<wilde> hey +<wilde> is the network unstable? +<wilde> I just couldn't get back on +Signoff: thecrypto (Leaving) +<lucky> yea +<lucky> its a bit... ugh. +<lucky> recently. +<wilde> what happened to the meeting? +<lucky> probably got decimated +<wilde> ok lucky what was the last thing you saw from the meeting? (msg me) +<lucky> <wilde> cya madman2003 +<lucky> <-- madman2003 has quit (( www.nnscript.de :: NoNameScript<a href="iip-wiki?action=edit&id=NoNameScript" class=wikipageedit>?</a> 3.8 :: www.XLhost.de )) +<lucky> <jrand0m> yes mihi, that'd work (but streaming .ogg sounds cooler) +Galaxy (yogi@anon.iip) has joined channel #i2p +<wilde> ok that's where it ended for me too +<fidd> me2 +Signoff: Sonax (EOF From client) +Sonax (~Sonax@anon.iip) has joined channel #i2p +<kaji> the meeting got nuked +kaji has changed the topic on channel #i2p to nuked +<kaji> ping? +<jar> pong! +<kaji> ok +<kaji> ithough it crashed again +<jar> yep :( +Signoff: wilde () +<kaji> so... meeting? +<jar> ending brutaly ... +<jar> more signs of jrandom, it seems it's all for the moment +<jar> next move on 0.2.4.2 in few days .... +<jar> (one or two as said jr) +mihi_backup (~mihi@anon.iip) has joined channel #i2p +jar is now known as jar_ +sheer (sheer@anon.iip) has joined channel #i2p +<kaji> wilde said something about funding, but last time i asked jran he said i2p wasnt in a position to need money atm +Signoff: Ranma () +Robert (~chatzilla@anon.iip) has joined channel #i2p +Sonax is now known as JaSiger<a href="iip-wiki?action=edit&id=JaSiger" class=wikipageedit>?</a> +JaSiger<a href="iip-wiki?action=edit&id=JaSiger" class=wikipageedit>?</a> is now known as Sonax +Signoff: Rain (I Quit) +zathras (~zathras@anon.iip) has joined channel #i2p +Ranma (ranma@anon.iip) has joined channel #i2p +mihi (mihi@anon.iip) has joined channel #i2p +<mihi> hmm, what happened to the meeting? +<UL > +<li> mihi has an idea +</UL> +<mihi> ;) +Mode change "+o mihi" on channel #i2p by Trent@anon.iip +Mode change "-o duck" on channel #i2p by mihi +<mihi> no one knowing anything about the meeting? +<UL > +<li> mihi notices that no one fears ops any longer ;) +</UL> +Signoff: zathras (Ping timeout) +mihi_backup has been kicked off channel #i2p by mihi (mihi) +zathras (~zathras@anon.iip) has joined channel #i2p +Signoff: Sonax (Client exiting) +<lucky> mihi, we lall got kicked for the meoeting +hacktic4ever (~hacktic4e@anon.iip) has joined channel #i2p +Signoff: hacktic4ever () +<mihi> ok, nite +<duck> hello +Signoff: sheer (EOF From client) +Signoff: mihi (let's have more luck next week...) +<duck> did I miss anything? +Signoff: jnk (Ping timeout) diff --git a/i2p2www/meetings/logs/78.rst b/i2p2www/meetings/logs/78.rst new file mode 100644 index 00000000..57d77c61 --- /dev/null +++ b/i2p2www/meetings/logs/78.rst @@ -0,0 +1,7 @@ +I2P dev meeting, DATE +============================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/79.log b/i2p2www/meetings/logs/79.log new file mode 100644 index 00000000..c63dca94 --- /dev/null +++ b/i2p2www/meetings/logs/79.log @@ -0,0 +1,181 @@ +[22:00] <jrand0m> 0) hi +[22:00] <jrand0m> 1) 0.2.4.2/0.2.5 +[22:00] <jrand0m> 2) docs +[22:00] <jrand0m> 3) ??? +[22:00] <jrand0m> 0) hi +[22:00] <human> hi +[22:00] * jrand0m waves to the newly-restarted iip-ircd :) +[22:01] <jrand0m> (and, uh, to you :) +[22:01] <jrand0m> weekly status notes (that we're running off) located at http://i2p.dnsalias.net/pipermail/i2p/2004-February/000148.html +[22:01] <jrand0m> (and posted to the mailing list, obviously) +[22:01] <jrand0m> 1) 0.2.4.2/0.2.5 +[22:02] <jrand0m> Dev has been making some good headway on the 0.2.5 release, which will allow and exploit both 2+ hop tunnels and clients with multiple inbound tunnels +[22:03] <jrand0m> the key functionality that will provide will be increased reliability and functional anonymity +[22:04] <jrand0m> the 1-hop tunnels we have now exposes you to statistical attack by an active opponent, but with 0.2.5 you'll be able to determine the length of your own hops (and increasing the default to 2) making the statistical attack much more complex +[22:06] <jrand0m> i also found a pair of bugs in the client send process and the network db which could account for some of the latest instability +[22:06] <jrand0m> (bugfixes underway) +[22:07] <jrand0m> as an aside, I think the roadmap [http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap] is still an accurate reflection of the dev schedule +[22:07] * mihi has joined #i2p +[22:07] <jrand0m> heya mihi +[22:07] * protocol has quit IRC (Ping timeout) +[22:07] <jrand0m> ok, thats it for the router dev status, moving on to 2) docs +[22:07] * human would like to say that he finds I2P unusable since 0.2.4 (it seems to behave *far* worse than the 0.2.3 age, at least on my PC) +[22:07] <jrand0m> hm +[22:08] <human> maybe we could talk about it after the meeting... +[22:08] <jrand0m> in reliability terms, latency, CPU, bandwidth? +[22:08] * protocol has joined #i2p +[22:08] <mihi> hi jrand0m, hi all +[22:08] <human> jrand0m: i can't reach any eepsite or I2P service (with few temporary exceptions) +[22:08] * mihi seconds human +[22:09] <jrand0m> most eepsites are down - duck, baffled, madman2003 are the most consistently up lately +[22:09] <human> jrand0m: i can't reach them, nor irc.*.i2p +[22:09] <jrand0m> squid I use constantly for all my web browsing - are you unable to use that? +[22:09] <human> jrand0m: nope +[22:09] <jrand0m> hm +[22:10] <madman-away> well an uptime of about 8 hours daily for my i2p site +[22:10] <human> jrand0m: we could talk about it after the meeting, i don't want to monopolize the discussion :-) +[22:10] * madman-away is now known as madman2003 +[22:10] <mihi> it might be my provider's problem as well, http://babelfish.altavista.com/babelfish/urltrurl?tt=url&url=http%3A%2F%2Fwww.expressnet.de%2Fnews%2Fnews.php&lp=de_en :( +[22:10] <Janonymous> me too +[22:10] <human> jrand0m: just to point out that some problems seems to exist (that weren't shown before) +[22:10] <Janonymous> mine should be up now +[22:11] <madman2003> what destination? +[22:11] <jrand0m> well, 'k, if things are going backwards in reliability we need to address that before moving on to 0.2.5 +[22:11] * mihi hates babelfish's english :( +[22:11] <jrand0m> heh +[22:12] <jrand0m> (well, it got the Thank you for your understanding. sentence correct at least...) +[22:12] <human> jrand0m: it should be investigated... i thought about an ISP issue, too, but the problem seems to be constant since 0.2.4 (and doesn't seem to happen with other network services) +[22:12] <jrand0m> 0.2.4.0 was shit, as was 0.2.4.1 +[22:12] * wilde has joined #i2p +[22:13] <human> jrand0m: i know, and it worries me... +[22:13] <wilde> hey i2p +[22:13] <jrand0m> heya wilde +[22:13] <madman2003> one thing i noticed is that tunnels tend to get unstable more often +[22:13] <human> jrand0m: i didn't change too much with 0.2.4.2 (at least for me) +[22:13] <human> jrand0m: s/ i / it / +[22:14] <jrand0m> madman2003> thats easily due to routers going on and offline (which will be a big problem until 0.3) +[22:14] <jrand0m> hmm ok +[22:14] <wilde> jrand0m: does that mean we should avoid running transients for now? +[22:15] * mihi has quit IRC (Ping timeout) +[22:15] <jrand0m> hm, I think there are going to be significant fixes in 0.2.5, but we can hold off on moving from 0.2.5 to 0.3 until after the reliability issues are cleared. +[22:16] <jrand0m> wilde> i don't like the term transients, it makes me think of another project that treats unreliable routers differently than reliable ones. we treat all routers equally (and need to, for anonymity) +[22:16] <jrand0m> but as long as routers generally stay up or generally down, they're fine +[22:17] <jrand0m> (just not up 10 minutes, down 10 minutes, up 30, down 30, etc) +[22:17] <madman2003> i do have one request: an option for the router(and tunnels) to be reastablished +[22:17] <baffled> i2p is an equal router opertunity organization? +[22:17] <jrand0m> heh baffled +[22:18] <jrand0m> madman2003> router to be reestablished? your router is shutting down still? +[22:18] <madman2003> i mean reconnecting everything +[22:18] <madman2003> sort of a warm restart of the router +[22:18] <madman2003> without pissing of the other routers +[22:18] <madman2003> (i have to restart router and tunnels a lot) +[22:18] <jrand0m> you can safely restart your client apps (e.g. i2ptunnel eepproxy, etc) without touching the rotuer +[22:19] <jrand0m> you should /never/ need to restart your router. +[22:19] <jrand0m> (almost all config settings are updated dynamically) +[22:19] * Trix has joined #i2p +[22:19] <jrand0m> hi Trix +[22:19] <Trix> hi +[22:19] <madman2003> usually restarting the tunnels does the trick +[22:21] <jrand0m> there's only one situation where that's technically necessary (old lease expirations in a client's leaseSet, which occurred on startup randomly), and thats been fixed in CVS, so you shouldn't need to do that. +[22:22] <jrand0m> (in fact, restarting tunnels can cause temporary problems, depending on the type of tunnel) +[22:22] <madman2003> sometimes i just don't know if i'm causing problems or if someone else is +[22:22] <jrand0m> if your router console doesn't have any of the red warnings, its the network (or someone else) +[22:22] * jnk has joined #i2p +[22:23] <jrand0m> patience fixes more of the current i2p bugs than restarts do ;) +[22:24] <jrand0m> but we'll have another series of bugfix releases after 0.2.5 +[22:24] <jrand0m> (like testnet, except without the restrictions on the userbase) +[22:25] <jrand0m> (and, as always, whenever things break, logs are appreciated :) +[22:25] <jrand0m> anyway, moving on to 2) docs +[22:26] <jrand0m> as posted in http://i2p.net/pipermail/i2p/2004-February/000147.html there've been some new overview docs +[22:27] <jrand0m> I'd appreciate some critiques to improve them, as they referred to pages are essentially going to turn into the main starting point for learning about I2P +[22:28] <madman2003> i read them and i hope you were right about the possibilty to safely reduce the amount of crypto +[22:29] <wilde> layers of crypto or # of bits? +[22:29] <jrand0m> I'm not convinced that the crypto is the bottleneck, but its a possibility +[22:30] <jrand0m> we couldnt safely reduce the layers, but we could use different levels of crypto at different layers, rather than reusing the same code for everything +[22:30] <madman2003> the problem is finding your way +[22:30] <jrand0m> hmm? +[22:31] <madman2003> a static path is usually well found +[22:31] <madman2003> a more dynamic one is more difficult to establish +[22:32] <madman2003> (i'm talking about the inability to properly handle routers going offline) +[22:32] <jrand0m> ah, thought you were talking about crypto +[22:32] <jrand0m> its going to be fairly easy to handle unreliable routers, its just the 0.3 code +[22:33] * jrand0m has ~30 pages of notes on different techniques, its all workable, just lots to do +[22:33] * protocol has quit IRC +[22:34] <madman2003> maybe an idea to have backup routes ready +[22:34] <madman2003> tunnel redundancy +[22:34] <jrand0m> right, thats 0.2.5 - multiple leases +[22:35] <jrand0m> (lease == declaration that a destination can be reached through a specific tunnel) +[22:35] <madman2003> i'll be awaiting that :) +[22:36] <jrand0m> w3rd +[22:37] <jrand0m> well, if anyone has any suggestions for improving the docs, feel free to hit the wiki, post to the list, or send me an email +[22:38] <jrand0m> ok, moving on at a rapid pace to 3) ??? +[22:38] <jrand0m> anything people want to bring up and discuss? +[22:39] <DrWoo> potatoes are fucking cheap yet potatoe chips are expensive, what's up with that? +[22:39] <DrWoo> :) +[22:39] <jrand0m> its a conspiracy! +[22:40] * DrWoo thinks jrand0m has the answer for most anything :) +[22:40] <jrand0m> of course, you can blame anything on conspiracies. +[22:40] <jrand0m> ok +[22:40] <wilde> Stego ? +[22:40] * human accepts suggestions about how to expose I2CP-like message-oriented functionality to non-java apps +[22:41] <wilde> how I2P will implement Stego so an ordinary portscan will reveal nothing +[22:41] <wilde> not even random bytes +[22:41] * human may (does?) sound repetitive... he's thinking about VPNs over I2P with http://openvpn.sf.net/ +[22:41] <jrand0m> well, for one, PHTTP. +[22:42] <jrand0m> openvpn does look very interesting - I hadn't realized tun/tap had windows ports +[22:42] <jrand0m> a simple message oriented socket bridge for I2CP should be very easy +[22:43] <wilde> Isn't freenet calling it Silent Bob, when the node shuts up it you don't give the secret knock (know the router ID) +[22:43] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) +[22:43] <baffled> okay as usual I have another appointment in 15m so I'll catch up later. +[22:43] <jrand0m> right, if we wanted to integrate with a webserver/etc to silent bob, we could +[22:43] <jrand0m> cool, later baffled +[22:44] <jrand0m> (but silent bob doesnt prevent portscan detection, it just makes it look like another service) +[22:44] <wilde> I rather not have random people or ISP:s portscan me and find ports open +[22:44] <wilde> ok +[22:44] <human> jrand0m: ok, i'll work on it when I2P will work again on my PC :-) +[22:44] <jrand0m> UDP would work as well +[22:44] <jrand0m> :) human +[22:45] * kaji has joined #i2p +[22:46] <jrand0m> I hadn't realized reliability had gone down that bad, we'll go through sufficient iterations after 0.2.5 to get it back for you human +[22:46] <wilde> is there a way of hiding an open port from java program, without messing with the OS or firewall +[22:46] <human> w00t! +[22:47] <jrand0m> you mean to have a listening TCP socket that can't be portscanned? no, not directly from Java. +[22:47] <wilde> ok +[22:48] <jrand0m> (i dont even know how to do that in other langs) +[22:48] <jrand0m> udp would probably be the best way to go for that +[22:48] * human invites people to try to telnet human.i2p (tunneled TCP echo server) and type something in +[22:48] <wilde> that would be a little C program filtering and forwarding to another port maybe +[22:49] * kaji_ has joined #i2p +[22:49] <jrand0m> if it accepts TCP connections, its already too late, if I understand your concern correctly. +[22:49] <Janonymous> how do you telnet? +[22:49] <kaji_> finaly +[22:50] <kaji_> that took forever, iip usability sucks dick atm +[22:50] * kaji has quit IRC (Ping timeout) +[22:51] <duck> if you are concerned about open ports, you could use rTCP / PHTTP / whatever couldnt you? +[22:51] <Janonymous> damn... hey, jr, are those new docs accessable from the main i2p page? +[22:51] <human> Janonymous: java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 12221 human.i2p" +[22:51] <jrand0m> no Janonymous, just from the links on that email +[22:51] <human> Janonymous: then telnet localhost 12221 +[22:51] <jrand0m> duck> right +[22:52] <Janonymous> k +[22:52] <duck> (ofcourse whatever can be a silentbob/stealth/stego transport) +[22:52] <jrand0m> human> Message send failed after 61226ms with 391 bytes +[22:53] <human> jrand0m: and it means that...? +[22:53] <jrand0m> that means I cant reach your echo +[22:53] <duck> -nogui is depricated :) +[22:53] <jrand0m> can you reach duck.i2p? +[22:54] <wilde> scary, i googled for rtcp: http://dret.net/glossary/rtcp +[22:54] <jrand0m> right, rtcp is taken :/ +[22:54] <human> jrand0m: i'm trying, but i can't reach duck.i2p since a looong time ago... +[22:54] <jrand0m> wilde> http://wiki.invisiblenet.net/iip-wiki?RelayingTCP +[22:54] <wilde> "Wilde's WWW Online Glossary" +[22:55] <jrand0m> hehe oh yeah :) +[22:55] <jrand0m> human> thats a definite Bad Thing, as its up almost always - could you bounce me your log-*.txt? +[22:56] <human> Started on: Tue Feb 24 10:21:22 GMT 2004 +[22:56] <human> Version: Router: 0.2.4.2 / SDK: 0.2.4.2 +[22:56] <human> Bandwidth used: 56096295 bytes sent, 34308394 bytes received (avg 1.44KBps sent 0.88KBps received) +[22:56] <human> jrand0m: ok, logs coming on meshmx +[22:56] <jrand0m> gracias +[22:56] <jrand0m> ok, anyone have anything else to bring up? +[22:58] * jrand0m winds up +[22:58] * jrand0m *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/79.rst b/i2p2www/meetings/logs/79.rst new file mode 100644 index 00000000..bf8d0ece --- /dev/null +++ b/i2p2www/meetings/logs/79.rst @@ -0,0 +1,7 @@ +I2P dev meeting, February 24, 2004 @ 22:00 CET +============================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/8.log b/i2p2www/meetings/logs/8.log new file mode 100644 index 00000000..e73f9c5c --- /dev/null +++ b/i2p2www/meetings/logs/8.log @@ -0,0 +1,140 @@ +--- Log opened Tue Aug 13 23:58:45 2002 +23:58 [Users #iip-dev] +23:58 [@logger] +23:58 -!- Irssi: #iip-dev: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal] +23:58 -!- Irssi: Join to #iip-dev was synced in 1 secs +23:58 -!- mode/#iip-dev [-o logger] by Trent +23:58 -!- mode/#iip-dev [+nt] by Trent +23:58 -!- Trent changed the topic of #iip-dev to: Info, agenda, log : http://mids.student.utwente.nl/~mids/iip/ | Tuesday 23:00 UTC - http://e-store.invisiblenet.net | topic: no meeting in progress +--- Day changed Wed Aug 14 2002 +00:00 -!- mode/#iip-dev [+o mids] by Trent +00:05 -!- mode/#iip-dev [+v logger] by mids +00:31 -!- mode/#iip-dev [+o mids] by Trent +00:52 <@mids> Info, agenda, log : http://mids.student.utwente.nl/~mids/iip/ | Tuesday 23:00 UTC - http://e-store.invisiblenet.net | topic: Welcome +01:00 <@mids> Tue Aug 13 23:00:00 UTC 2002 +01:00 <@mids> Meeting nr 8! +01:00 <@mids> everybody ready? +01:00 < Neo> yes +01:00 < nop> welcome +01:00 <@mids> thanks +01:01 <@mids> as a sidenote, I feel that my connection is unreliable.. I can die every second +01:01 <@mids> logs are available on http://mids.student.utwente.nl/~mids/iip/ +01:01 <@mids> Agenda for today: +01:01 <@mids> 1) Welcome +01:01 <@mids> 2) RC2 +01:01 <@mids> 3) Mac OS 9 +01:01 <@mids> 4) Website preview +01:01 <@mids> A) Questions? +01:01 <@mids> if you have anything to ask or add.. do so +01:02 <@mids> otherwise I suggest we go to item nr2 +01:02 <@mids> . +01:02 <@mids> great +01:02 <@mids> 2) RC2 +01:03 <@mids> it should be out months ago :) +01:03 <@mids> but it isnt due to various reasons +01:03 <@mids> the biggest one is the summer/vacation period +01:03 <@mids> as far as I know we are waiting on the relay checker that has to be modified for RC2 +01:04 <@mids> last month UserX has squished some more bugs +01:04 <@mids> but nothing serious +01:04 <@mids> once codeshark is back in business.. there is hope +01:05 <@mids> waiting for nop to add optional info +01:05 <@mids> so just have patience +01:05 <@mids> we are doing our best.. working with the resources available +01:05 <@mids> . +01:06 <@mids> according to nop there is an issue with the PRNG +01:06 < nop> for the inner key +01:06 <@mids> Pseudo Random Number Generator +01:06 < nop> technology +01:06 < nop> for rc2 +01:06 < nop> it has an initialization problem +01:06 < nop> that is being worked on +01:07 < nop> but it is slow +01:07 < nop> and userx is moving at this time, so it makes it double slow +01:07 < nop> . +01:07 <@mids> . +01:07 <@mids> so keep up the hope and lets move to the next item +01:07 <@mids> which is... 3) Mac OS 9 +01:07 < nop> ok +01:07 < nop> crunch has given me info on that +01:08 < nop> someone just donated another 300 dollars +01:08 < nop> to the project +01:08 < nop> which is awesome +01:08 < nop> crunch and bob are working on the gui and bob is fixing up the socket stuff +01:08 < nop> it's more of a time issue as they are working on another project +01:08 <@mids> how much $ are collected for the port now? +01:08 < nop> but +01:09 < nop> physically 1100 +01:09 < nop> is all the money that has been collected +01:09 < nop> we would like to get up to 3500 total +01:09 < nop> if possible +01:09 < nop> so anyone wanting to even donate a dollar +01:09 < nop> would help +01:09 <@mids> so... if you want to have the mac os 9 port for IIP done... contact nop +01:09 < nop> to pay for the development time of Cap'n Crunch and his partner bob +01:09 < Robert> Excellent news. Let Neo or I know if you want another request to be put in on the DC front page. +01:09 < nop> plse +01:10 < nop> another request would be great Robert +01:10 <@mids> I suggest we start doing p +01:10 < nop> we've delivered 700 to Crunch +01:10 <@mids> ublic announces every hour on IIP +01:10 < nop> and 300 will be delivered next week +01:10 <@mids> just like OPN used to do :) +01:10 * Neo thinks we should put in a 30 minute NAG screen on the os9 app until we get over $3500 :) +01:10 < nop> haha +01:10 < nop> I believe it's a bad idea +01:10 < nop> let's just request +01:11 < nop> not nag +01:11 <@mids> kay :/ +01:11 <@mids> . +01:11 * Neo thinks maybe a "I use os9 and have not donated" message broadcast from os9 users also. :) +01:12 < Neo> just kidding +01:12 < nop> hehe +01:12 < ellison> there are a few Mac software companies that put funny requests in pop-ups when you first load the program +01:12 <@mids> maybe an article on macworld? +01:12 < ellison> I've found that approach to the the most effective with me personally +01:13 <@mids> . +01:14 <@mids> lets move on.. cause we have some exciting news! +01:14 < nop> . +01:14 <@mids> which is... +01:14 <@mids> the +01:14 <@mids> Website! +01:14 <@mids> 4) Website preview +01:14 <@mids> specially for you a sneak preview +01:14 <@mids> http://www.citystateinc.com/ellison/invisiblenet/index.html +01:15 <@mids> dont forget to click through to the "Invisible IRC Project" in the upper right corner +01:15 <@mids> ellison just released this preview, he is working on the templates now +01:15 <@mids> after that, copy has to be made to fill the blanks +01:16 <@mids> I think we can have the website live pretty soon +01:16 <@mids> . +01:16 < ellison> we're almost there +01:17 <@mids> comments? +01:17 * mids thinks that everybody is still gasping at the site +01:17 < ellison> i think everyone has passed out from joy and hasn't made it back up on their chairs yet +01:17 < nop> haha +01:18 <@mids> next topic? or are we going too fast? +01:19 <@mids> topic nr 5.. requested by Neo +01:19 <@mids> the ! channels with channel mode +a +01:20 <@mids> on this irc server there can +01:20 <@mids> err +01:20 <@mids> you can create special ! channels +01:20 <@mids> to create them, type /join !!channelname +01:20 <@mids> then you get a channel like: !A4CEQchannelname +01:21 <@mids> this strange prefix is there to prevent channel collisions after netsplits, some obscure test by the ircnet programmers +01:21 <@mids> but, these channels have something special +01:21 <@mids> you can set the +a mode +01:21 <@mids> with /mode !A4CEQchannelname +a +01:21 <@mids> then the channel becomes truely anonymous +01:22 <@mids> everybody his/her nick becomes 'anonymous' +01:22 <@mids> so you dont know who is talking +01:22 <@mids> try it out.. join !anonymous for a demo +01:23 <@mids> so remember.. to create ! channels: /join !!channel +01:24 <@mids> to join an existing channel: /join !channel +01:24 <@mids> then set +a mode (if you are operator) /mode !prefixchannelname +a +01:24 <@mids> this mode cant be unset +01:24 <@mids> . +01:25 <@mids> that was my topic list for today +01:25 <@mids> any questions? +01:26 <@mids> nope? +01:26 < Robert> No sir. +01:27 <@mids> then I'll end my monologue :) +--- Log closed Wed Aug 14 01:28:33 2002 diff --git a/i2p2www/meetings/logs/8.rst b/i2p2www/meetings/logs/8.rst new file mode 100644 index 00000000..ae521ebf --- /dev/null +++ b/i2p2www/meetings/logs/8.rst @@ -0,0 +1,9 @@ +I2P dev meeting, August 13, 2002 @ 23:00 UTC +============================================ + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/80.log b/i2p2www/meetings/logs/80.log new file mode 100644 index 00000000..9c6e7fc2 --- /dev/null +++ b/i2p2www/meetings/logs/80.log @@ -0,0 +1,352 @@ +13:07 < jrandom> 0) hi +13:07 < jrandom> 1) Dev status +13:07 < jrandom> 2) Cascades +13:07 < duck> I'll stop +13:07 < jrandom> 3) Roadmap +13:07 < jrandom> 4) Website +13:07 < jrandom> 5) ??? +13:07 < jrandom> 0) hi +13:07 * jrandom waves to the first over-i2p i2p dev meeting :) +13:07 < ughabugha> nick is Janonymous. +13:08 < ughabugha> Ok. +13:08 < duck> hi +13:08 < jrandom> weekly status notes are posted to the mailing list (online at http://i2p.net/pipermail/i2p/2004-March/000155.html) +13:08 < ughabugha> hi. +13:08 < jrandom> as usual, we'll be following that as a guide +13:08 < nick> hello +13:09 < jrandom> jumping into 1) Dev status +13:09 * jrandom repeats mantra of "Progress is being made" +13:10 < jrandom> 0.2.5 has some Good Stuff, and we're finding long hidden bugs +13:10 < jrandom> latest one is db related, but thats not fixed up yet, so no need to track CVS HEAD +13:11 < jrandom> echo tests show pretty good results, but there's still issues to be worked out wrt irc and snark +13:12 < jrandom> how has eepsite retrieval been for people? +13:12 < jrandom> (and/or squid?) +13:12 < nick> here and there +13:12 < duck> generally okay with janonymous or ugha +13:13 < duck> sometimes janonymous goes down etc +13:13 < ughabugha> Yeah. +13:13 < duck> <mihi_backup> jrandom: you *really* know how to make me angry... +13:13 < jrandom> d'oh +13:13 < nick> I've been putting new content +13:13 < jrandom> whats up mihi? +13:13 < jrandom> nice nick +13:14 < jrandom> er janonymous +13:15 < nick> eh? +13:15 < nick> :) +13:15 < ughabugha> IIP <ughabugha> I started a two-way relay now. +13:15 < jrandom> ah cool +13:15 -!- nick [~Janonym@localhost] has quit [Client closed connection] +13:15 < jrandom> whats up mihi? +13:15 < ughabugha> IIP <ughabugha> Automatic. +13:16 < ughabugha> IIP <ughabugha> :) +13:16 < ughabugha> :) +13:16 < ughabugha> IIP <ughabugha> Oops, a bug. +13:16 < ughabugha> Oops, a bug. +13:16 < jrandom> heh is he still there or is there anything else wrt dev status? +13:17 < duck> lets go on +13:17 < jrandom> 'k +13:17 < jrandom> jumping to 2) Cascades +13:17 < ughabugha> IIP <ughabugha> * mihi_backup is now known as mihi_away +13:17 < ughabugha> * mihi_backup is now known as mihi_away +13:17 < ughabugha> IIP <ughabugha> Argh, relaying for my own text doesn't work. +13:17 < ughabugha> Argh, relaying for my own text doesn't work. +13:17 < jrandom> ;) +13:18 < ughabugha> IIP <ughabugha> No, wait. +13:18 < ughabugha> No, wait. +13:18 < madman> then don't speak :) +13:18 < jrandom> mix cascades are one of the two big styles of low latency mix nets, and while we don't use them in i2p, if some people think they're useful, they can tweak their router to get the same effect +13:19 < ughabugha> IIP <ughabugha> Test +13:19 < ughabugha> Test +13:19 < ughabugha> IIP <jrandom> mix cascades are one of the two big styles of low latency mix nets, and while we don't use them in i2p, if some people think they're useful, they can tweak their router to get the same effect +13:19 * jrandom senses an incoming recursive echo... +13:19 < ughabugha> IIP <ughabugha> Damn! +13:19 < ughabugha> Damn! +13:20 < jrandom> anyway, I think its always good to ask fundamental design questions, to poke at i2p and see why we do things the way we do +13:21 < jrandom> i've got the feeling we'll be hearing more about cascade-like systems in the future, so hopefully the description in the email will help explain i2p's relation to cascades +13:21 < ughabugha> Ok, it should work _now_. +13:21 < ughabugha> IIP <ughabugha> Say something. +13:21 < ughabugha> IIP <Janonymous> I move to not go after a mix net implementation within the current roadmap, and leave that for later +13:21 < ughabugha> Yeah, it works now. +13:21 -!- wilde [~anon@localhost] has joined #i2p +13:22 < jrandom> janymous> well, i2p /is/ a mixnet, just not a mix cascade +13:22 < madman> i'm going offline +13:22 < jrandom> 'k, ttyl madman +13:22 < jrandom> heya wilde +13:22 < madman> so bye +13:22 < ughabugha> IIP <wilde> finally +13:22 < ughabugha> IIP <wilde> hello meeting +13:22 < jrandom> but I concur, I don't think mix cascade functionality needs to be on the roadmap +13:23 < ughabugha> IIP <madman2003> bye everyone +13:24 < jrandom> ok, anything else on cascades, or should we move to 3) Roadmap? +13:26 < ughabugha> Hi, wilde@IIP +13:26 < ughabugha> Bye, madman@IIP +13:26 -!- madman [~a@localhost] has quit [( www.nnscript.de :: NoNameScript 3.8 :: www.XLhost.de )] +13:26 < ughabugha> IIP <Janonymous> Just seems like it could be implemented later, like a DHT might be. High Wilde +13:26 < ughabugha> IIP <Janonymous> bye Madman +--- Log closed Tue Mar 02 13:27:07 2004 +--- Log opened Tue Mar 02 13:27:52 2004 +13:27 -!- jrandom [~jrandom@localhost] has joined #i2p +13:27 -!- Irssi: #i2p: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal] +13:27 -!- wilde [~anon@localhost] has joined #i2p +13:27 < jrandom> back +13:28 < ughabugha> Uhoh, jrandom quitted. +13:28 < ughabugha> IIP <Janonymous> bah +13:28 < jrandom> ok last I saw was 13:26:08 < ughabugha> IIP <Janonymous> bye Madman +13:28 -!- Irssi: Join to #i2p was synced in 36 secs +13:28 < jrandom> (irssi missed a ping so it dropped it) +13:29 < ughabugha> You missed IIP <Janonymous> Roadmap +13:29 < ughabugha> IIP <Janonymous> ah.. We all agreed to go onto the roadmap ;) +13:29 < jrandom> w3rd +13:29 < jrandom> ok, the roadmap change is likely why mihi hates me now +13:30 < ughabugha> Uh, then you missed alot more than that. +13:30 < ughabugha> Just a second. +13:30 < ughabugha> [23:23 39] <ughabugha> IIP <wilde> oh we have to camps now, the iip gang and the I2P hood +13:30 < ughabugha> [23:23 47] <ughabugha> IIP <wilde> two +13:30 < ughabugha> [23:23 50] <ughabugha> Hehe. +13:30 < ughabugha> [23:23 54] <ughabugha> IIP <Janonymous> :) got a relay going +13:30 < ughabugha> [23:24 22] <ughabugha> This is a temporary script I hacked together quickly. For future meetings we should think of something better. +13:30 < ughabugha> [23:24 44] <ughabugha> IIP <Janonymous> It works +13:30 < ughabugha> [23:25 18] <ughabugha> Ok, concentrate on I2P now, not the relay. +13:30 < ughabugha> [23:25 39] <ughabugha> IIP <Janonymous> So, mix cascades could feasably implemented quite well over i2p +13:30 < ughabugha> Sorry for the flood. +13:30 < duck> this is chaos +13:31 < ughabugha> IIP <Janonymous> but i think we can emphasize /over/ +13:31 < ughabugha> Ok, 3) Roadmap +13:31 < ughabugha> duck: Pretty much. +13:31 < jrandom> this aint nothing compared to meeting 67 ;) +13:31 < jrandom> ok, on to 3 +13:31 < jrandom> anyone have any thoughts wrt the roadmap? +13:32 < jrandom> the changes / views / concerns? +13:32 < ughabugha> IIP <Janonymous> Multi-tunneling +13:32 < jrandom> janonymous> we've already got that +13:32 < jrandom> (as of 0.2.5) +13:32 < jrandom> if I understand you correctly +13:33 < ughabugha> IIP <Janonymous> but, as in, sending one file over two tunnels to accelerate transmission? +13:33 < ughabugha> IIP <Janonymous> at the same time +13:34 < jrandom> i2p doesn't deal with files, but yes, each individual i2p message can now go down multiple tunnels +13:34 < ughabugha> IIP <Janonymous> I think that would be a great addition for the 2.0 area +13:34 < jrandom> e.g. first 32kb sent down tunnel X, next 32kb sent down tunnel Y +13:35 < ughabugha> IIP <Janonymous> right.. thats what I'm getting at.. that seems very necessary to me +13:35 < jrandom> but i2psnark with i2cp support would be able to maximize things +13:35 < jrandom> janonymous> we do that now +13:36 < ughabugha> IIP <Janonymous> oh. I2PSnark will utilize multiple tunnels for point to point communication? +13:36 < jrandom> all messages can go down multiple tunnels. +13:36 < duck> theoretically +13:37 < jrandom> not just theoretically - if a message takes > 15s, its sent down the other available lease +13:37 < jrandom> and if it takes > 30s, the leaseSet is dropped and refetched, with subsequent messages going down found leases +13:37 < jrandom> BUT +13:38 < jrandom> i2ptunnel (any anything else that uses i2p's mode=guaranteed) waits until each message is delivered before sending the next one +13:38 < jrandom> native i2cp apps don't need to do that +13:38 < jrandom> (nor will any apps that use the socket library, once the socket library is both implemented and supports SACK) +13:38 < ughabugha> IIP <Janonymous> ok.. I just think that will be a great method for these tunnels in the future.. for speed and anomymity +13:38 < ughabugha> IIP <Janonymous> and keeping strain off individual tunnels +13:39 < jrandom> agreed +13:39 < jrandom> ok, anything else on the roadmap? +13:40 < jrandom> (anyone going to bitch me out for dropping the socket lib? mihi? :) +13:41 < ughabugha> IIP <Janonymous> I used an analogy earlier today to describe multi-tunneling to someone.. and I said it was like adding lanes to a road +13:42 < jrandom> pretty much +13:42 < jrandom> (though one's on-ramp is always the same number of lanes ;) +13:42 < duck> if mihi is angry he can do the socket api cant he? +13:43 < jrandom> sure, and/or anyone else. the socket lib is Good +13:43 < jrandom> (but hard, and imho not functionally essential to the operation / security of the network) +13:44 < jrandom> i just wish i had the time to do it and keep moving on the core i2p code +13:44 < jrandom> but, c'est la vie +13:45 < ughabugha> IIP <Janonymous> looks like mihis not here +13:45 < ughabugha> Ok, i'm back now. +13:45 < jrandom> coo' +13:45 < jrandom> ok, moving on to 4) website +13:46 < ughabugha> IIP <Janonymous> big on ramp == cable / small on ramp == dialup ?? +13:46 < ughabugha> Hmm +13:46 < ughabugha> What was the socket library going to do? +13:46 -!- nick [~Janonym@localhost] has joined #i2p +13:46 < jrandom> right nanonymous +13:46 < jrandom> er, janonymous +13:46 < jrandom> (no matter what, i2p cant make your local net connection faster) +13:46 < jrandom> ughabugha: http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary +13:47 < ughabugha> I mean a socket library for Java? Don't you already have one? +13:47 < jrandom> the socket lib factors out the TCP-esque code out of i2p, letting i2p specialize in IP-like messages +13:47 < nick> yup +13:47 -!- nick [~Janonym@localhost] has quit [Client closed connection] +13:48 < jrandom> ah, right, yes, but this would let applications stream data over i2p much more efficiently (if/when the socket library supports selective ACK, rather than requiring an ACK after each message like it does now) +13:49 < jrandom> i'm not comfortable with implementing SACK within the router, since it can safely go outside of it (into the socket lib) +13:49 < ughabugha> But why drop it? Does it really take that much work? +13:49 < jrandom> yes, to get right +13:49 < jrandom> there's some code thats part way implemented, but i dont have time to maintain and test it +13:49 < ughabugha> Ok. You're the man. +13:50 < jrandom> well, $devWhoImplements it is the man ;) +13:50 < jrandom> anyway, moving on to 4) website +13:50 < ughabugha> :) +13:51 < ughabugha> Any volunteers? +13:51 < ughabugha> IIP <Janonymous> research on implementations of anonymous p2p +13:51 * jrandom echoes ughabugha's question :) +13:51 < jrandom> hmm janonymous? +13:51 < ughabugha> Janonymous: This will be covered under 5) ??? +13:51 < jrandom> :) +13:52 < ughabugha> IIP <Janonymous> wll its content that goes on the site +13:52 < jrandom> ah, yeah, I agree +13:52 < jrandom> (see item 7 on http://i2p.net/pipermail/i2p/2004-February/000133.html) +13:53 < jrandom> and item 8 +13:53 < jrandom> or is that not what you mean? +13:53 < jrandom> I'll probably post up the truckload of papers i dug through last summer when researching and designing i2p +13:53 < jrandom> (or at least pointers to their citeseer entries) +13:54 < ughabugha> IIP <Janonymous> Ok. Were we going to discuss the next CMS for I2P? +13:54 < ughabugha> jrandom allready chose the CMS. +13:55 < jrandom> yes/no - rather than researching the pros and cons of CMSes for another month or two, we'll just go with drupal for now +13:55 < ughabugha> IIP <ughabugha> /topic #i2p +13:55 < ughabugha> IIP <Janonymous> Ok.. well, as far as what to put there.. We need a presentation +13:55 < jrandom> if we need to migrate to another one, wilde assures me its simple enough to export content +13:55 < jrandom> a presentation? +13:56 < ughabugha> IIP <Janonymous> with lots of illustrations and a step by step introduction to I2P +13:56 < jrandom> we do need the graphic design implemented +13:56 < jrandom> ah right +13:56 < jrandom> a user's intro +13:56 < jrandom> the wiki intro is generally a technie intro +13:56 < ughabugha> IIP <Janonymous> Almost like a multimedia presentation +13:56 < ughabugha> IIP <jrand0m> w0ah +13:56 < ughabugha> IIP <Janonymous> right +13:57 < ughabugha> IIP <ughabugha> Yay! +13:57 < jrandom> ok, i think we can get that together, but we'll probably want to wait on producing that content until we have both a Real installer, and a GUI control system +13:57 < ughabugha> IIP <Janonymous> In it, there should be more pictures, than words. :) +13:57 < jrandom> right +13:58 < ughabugha> IIP <Janonymous> righto +13:58 < jrandom> but we don't have a real installer yet, and (as much as i2pmgr and i2pmole are great) i think there's still work to be done on a control panel +13:58 < ughabugha> This is not the top priority right now. +13:58 < ughabugha> IIP <Janonymous> certainly not. but for those of us not programming... +13:59 < jrandom> right. so we need volunteers to work on 1) designing what content needs to be on the i2p website 2) designing the graphics / css / layout for the i2p website 3) people to work on creating content for the i2p website +14:00 < ughabugha> IIP <Janonymous> I've got a month to spare. Think it would be time well spent. +14:00 < jrandom> w00t :) +14:00 * jrandom marks Janonymous down as a volunteer... for content design & content creation? +14:00 < wilde> back +14:00 < ughabugha> Well, I could do HTML, CSS and the technical stuff, but I'm not much of a writer, nor a designer. +14:01 < jrandom> r0x0r +14:01 < ughabugha> IIP <Janonymous> right.. I'm not so good at the designing part yet +14:01 < ughabugha> IIP <Janonymous> I could try to write, but not without some good critique.. I've never writen editorial type things +14:01 < ughabugha> I can also use Photoshop and other tools as long as I'm given specific instructions on what to do. ;) +14:01 < wilde> I'll take care of drupal and features +14:02 < ughabugha> IIP <Janonymous> I've got some good ideas for you ughabugha +14:02 < jrandom> right, by content design i don't mean layout, but more "ok, we need a user intro page, a tech intro page, a faq" etc +14:02 < ughabugha> Heh, ok. :) +14:02 < jrandom> r0x0r0r +14:02 * jrandom marks down wilde and ughabugha as volunteers :) +14:02 < ughabugha> Looking forward to them. +14:02 < ughabugha> IIP <Janonymous> there's a shaby picture I made that can be found linked to the new I2POverview doc on I2p +14:03 < jrandom> word, yeah janonymous, that pic is pretty good, some minor tech issues with it, but quite useful +14:03 < ughabugha> IIP <Janonymous> It would look alot nicer in photoshop I'm sure +14:04 < ughabugha> Heh. +14:04 < ughabugha> Janonymous: Let's discuss that privately tomorrow. +14:04 < ughabugha> IIP <Janonymous> eh, actually I may have accidentally deleted it :/ +14:04 < jrandom> ok, anything else for the website, or can we move on to 5) ??? +14:04 < ughabugha> IIP <Janonymous> ok +14:07 < wilde> ok one thing: +14:07 < ughabugha> Anything else on website? +14:07 < wilde> what is the first feeling you should get on the site? +14:07 < wilde> keywords please +14:07 < jrandom> wilde> see http://i2p.net/pipermail/i2p/2004-February/000133.html (the "rom a branding perspective" paragraph :) +14:08 < jrandom> i do like the anonymous bit by bit thing +14:08 < ughabugha> I suppose not. Should we go on to 5) ??? ? +14:08 < ughabugha> IIP <Janonymous> should we make a more detailed user roadmap? +14:08 < ughabugha> IIP <Janonymous> one describing the long term goals in more detail +14:08 < ughabugha> wilde: Only positive emotions. +14:09 < jrandom> janonymous> agreed, the current roadmap is really just tech notes for tech tasks ;) +14:09 < jrandom> ok, 5) ?? +14:09 < jrandom> anything y'all want to bring up? +14:10 < wilde> itoopie isn't really in line with simple and secure +14:10 < wilde> it's more of a cartoon feeling +14:10 < wilde> that's why i asked +14:10 < ughabugha> IIP <Janonymous> yea, might want to build some more anticipation +14:10 < ughabugha> IIP <Janonymous> for the users to get involved +14:10 -!- kaji [~booky5@localhost] has joined #i2p +--- Log closed Tue Mar 02 14:11:08 2004 +--- Log opened Tue Mar 02 14:12:12 2004 +14:12 -!- jrandom_ [~jrandom@localhost] has joined #i2p +14:12 -!- Irssi: #i2p: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal] +14:12 < jrandom_> back +14:12 < ughabugha> IIP <Janonymous> like, it should work for them without them even knowing its there +14:12 < jrandom_> wilde> I'm open to suggestions +14:12 < ughabugha> * jrandom_ (~jrandom@localhost) has joined #i2p +14:12 < jrandom_> <Janonymous> yea, might want to build some more anticipation +14:12 < jrandom_> hmm? +14:14 < ughabugha> You missed these: +14:14 < ughabugha> [00:11 43] <ughabugha> IIP <Janonymous> I'd just like to reemphasize.. I just think all multi-tunneling methods should be transparent and available to all client apps +14:14 < ughabugha> [00:12 07] <ughabugha> IIP <Janonymous> like, it should work for them without them even knowing its there +14:14 < jrandom_> janonymous> already implemented. +14:14 < jrandom_> i2p already transparently balances end to end communication over multiple tunnels +14:15 * jrandom_ kicks jrandom +14:15 -!- jrandom [~jrandom@localhost] has quit [Ping timeout] +14:15 -!- Irssi: Join to #i2p was synced in 231 secs +14:15 < wilde> participation? +14:15 < ughabugha> IIP <Janonymous> even if we profile the fastest most stable tunnels.. we can still use the other slow tunnels for extra throughput if we need it +14:15 < kaji> is iip up? +14:15 -!- kaji [~booky5@localhost] has quit [Client closed connection] +14:15 < ughabugha> IIP <Janonymous> And we may want to distribute the load anyway.. and that should all be transparent to the client apps +14:15 -!- You're now known as jrandom +14:16 -!- protocol [~iip@localhost] has joined #i2p +14:16 < ughabugha> IIP <Janonymous> ok +14:16 < ughabugha> IIP <Janonymous> cool +14:16 < jrandom> :) +14:17 < ughabugha> jrandom: Don't use ACTION, it's not relayed ;) +14:17 < jrandom> hah ok sorry +14:17 * jrandom says something they cant see +14:17 < jrandom> ;) +14:17 < jrandom> ok, anyone else have anything else? +14:18 < jrandom> i think after the current netDb bugs are fixed we may want to try the i2psnark tests again +14:20 -!- kaji [~booky5@localhost] has joined #i2p +14:20 -!- wilde [~anon@localhost] has quit [Ping timeout] +14:20 < ughabugha> But does the 15-second wait really distribute the load? +14:20 < ughabugha> That's not how I see it. +14:20 * protocol says iip is for lusers +14:20 < ughabugha> The way I see it, it should be 100% simultaneous, the node should put packets through the tunnel as fast as the destination can handle them. +14:20 < ughabugha> Through all the tunnels, I mean. +14:20 -!- nick [~Janonym@localhost] has joined #i2p +14:20 -!- kaji [~booky5@localhost] has quit [Client closed connection] +14:21 < jrandom> ughabugha: each message is ideally only sent over one tunnel, but each individual message is balanced over all of them +14:21 < ughabugha> IIP <Janonymous> me and duck ran a test over I2PSnark +14:21 < ughabugha> IIP <Janonymous> earlier today. +14:21 < jrandom> ughabugha: if we sent it over all tunnels always, that'd be a significant amount of wasted traffic +14:21 -!- nick [~Janonym@localhost] has quit [Client closed connection] +14:21 < ughabugha> IIP <Janonymous> Is everyone happy with the "I2P" name? +14:21 -!- kaji [~booky5@localhost] has joined #i2p +14:21 -!- wilde [~anon@localhost] has joined #i2p +14:22 < jrandom> janonymous> i2p is the name. +14:22 < jrandom> you can call it betty, but i2p is the name ;) +14:22 < ughabugha> kaji: Why are you blinking like this? +14:22 < jrandom> ughabugha: kaji likes messing with us +14:22 < ughabugha> jrandom: Yeah, I understand that. I guess it works just as I imagine it. +14:23 < kaji> i dont know +14:23 < kaji> is iip up? +14:23 < ughabugha> IIP <Janonymous> cool +14:23 < ughabugha> IIP <Janonymous> is for me +14:23 < ughabugha> It is for some people, and it's not for others. +14:23 < ughabugha> So I'm running a relay. +14:24 < jrandom> ughabugha++ +14:24 < ughabugha> To connect the networks. +14:24 < kaji> cool +14:24 < jrandom> the details of the parallel/serial sending is in net.invisiblenet.i2p.router.message.OutboundClientMessageJob +14:24 < ughabugha> :) +14:24 < jrandom> (for anyone who wants to know more details of how it works) +14:25 < jrandom> ok, anything else people want to bring up? +14:25 < kaji> so how is i2p dev? :) (Mirc sez 'lag=30 seconds') +14:25 < jrandom> kaji> we're making progress ;) +14:26 < jrandom> irssi here has bounced between 80s and 1s lag +14:26 < jrandom> (two disconnects in the last 90 minutes) +14:26 < ughabugha> IIP <Janonymous> is there any more ideas on content for the new site? +14:27 < ughabugha> IIP <kaji> sweet +14:27 < jrandom> beyond http://i2p.net/pipermail/i2p/2004-February/000133.html I think we'll want to go with one of drupal's forum modules +14:27 < ughabugha> No disconnects for me for 80 minutes. +14:27 < jrandom> nice ughabugha +14:27 < kaji> hmm now the lag is down to a few seconds +14:27 < jrandom> yeah, it varies kaji +14:28 < ughabugha> IIP <Janonymous> oh, me and ugha talked on my chat room over eep today :) +14:28 < jrandom> nice1! +14:28 < ughabugha> Janonymous: I wouldn't call that talking. ;) +14:28 < ughabugha> It was more like shouting over a distance of a few kilometers. +14:28 < jrandom> wait, y'all did voice? +14:29 < ughabugha> IIP <Janonymous> :) it was one message +14:29 < ughabugha> :) +14:29 < ughabugha> Well, I caused all the lag. +14:30 < ughabugha> Anyway, if somebody has a proposition for discussion, do it now, because I have to go. +14:30 < jrandom> word, 90m is a good meeting length to end at too... +14:30 < jrandom> anything else can be taken up on the mailing list +14:30 < jrandom> (and/or iip/i2p later) +14:31 * jrandom winds up the *baf*er... +14:31 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/80.rst b/i2p2www/meetings/logs/80.rst new file mode 100644 index 00000000..3e4d12dd --- /dev/null +++ b/i2p2www/meetings/logs/80.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 2, 2004 @ 13:00 PST +========================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/81.log b/i2p2www/meetings/logs/81.log new file mode 100644 index 00000000..d7d47e34 --- /dev/null +++ b/i2p2www/meetings/logs/81.log @@ -0,0 +1,399 @@ +13:12 < jrandom> agenda: +13:12 < jrandom> 0) hi +13:12 < jrandom> 1) administravia +13:13 < jrandom> 2) 0.3 status +13:13 < jrandom> 3) peer profiling / selection +13:13 < jrandom> 4) web architecture +13:13 < jrandom> 5) ??? +13:13 < jrandom> 0) hi +13:13 * jrandom waves to the gang +13:14 < deer> * jrandom_ waves from i2p +13:14 < deer> * wilde hi5s +13:15 < deer> <ughabugha> Hi! +13:15 < deer> * duck is reading +13:15 < deer> <human> yo! +13:16 < jrandom> w0rd, sorry for the delay getting those status notes up at (http://i2p.net/pipermail/i2p/2004-March/000165.html) +13:18 < jrandom> 1) administravia +13:19 < jrandom> for simplicity, and to avoid the trouble we had last week w/ the various networks being bitchy, some magic has been worked out and this meeting is being run off three irc networks +13:19 < deer> <duck> (amazing!) +13:19 < jrandom> iip's #i2p, the duck/baffled i2p irc network's #i2p, and freenode's #i2p +13:19 < jrandom> :) +13:19 < deer> <baffled> who's paranoid? +13:20 < deer> <ughabugha> Ok, done reading the status notes. +13:20 < deer> <ughabugha> jrandom: What about it? +13:20 < deer> <ughabugha> Or them? +13:21 < jrandom> just mentioning it, so people who have trouble with one can use another +13:21 < deer> <mihi> fine. done with status notes as well +13:21 < jrandom> also, the drupal box should be back online this weekend (crossing fingers) +13:22 < deer> <ughabugha> Oh, ok. Is there anything to discuss on 1)? +13:22 < deer> <ughabugha> Or are we waiting for people to finish reading? +13:22 < deer> <ughabugha> jrandom: Good. :) +13:22 < jrandom> nope, unless anyone has any administravia they'd like to bring up? +13:23 < deer> * mihi wants to set a flag at point 3 +13:23 < jrandom> flag set ;) +13:23 < deer> * duck at point 2 +13:23 < deer> <duck> err, what index do we use? +13:24 * jrandom supposes we can move on to agenda item 2) 0.3 status +13:25 < jrandom> i ended up typing a lot more than usual for the 0.3 status notes, so rather than repeat them here, does anyone have any questions / concerns they'd like to bring up? +13:25 < deer> <ughabugha> Go on. +13:26 < deer> <duck> why do the ElGamal/AES+SessionTag decryptions fail too often? +13:26 < jrandom> duck> due to overload and lag. if a garlic routed message is delayed beyond that sessionTag's lifetime, the decryption will fail +13:27 < deer> <duck> k +13:27 < jrandom> in addition, if the garlic routed message is decrypted fine, but the content was delayed so much that the cloves expire, its a wasted decryption, as well +13:28 < deer> <duck> somehow that sentence made me believe that there was a cause besided the overload/lag +13:28 < deer> <tro|l> ce zi e azi? +13:28 < jrandom> well, there have been some troubles with source routed reply blocks failing decryption, though since they're going away in 0.3.1, its not really worth debugging them too much +13:29 < deer> <kaji> wow it works! +13:29 < jrandom> (and a failed ElG is probably the most CPU intensive thing i2p does) +13:30 < deer> <jrandom_> heh welcome to i2p #i2p :) +13:30 < deer> * kaji praises 0.2.5.1 +13:30 < deer> <jrandom_> 0.2.5.1? sheeit, get thee 0.2.5.4 :) +13:30 < jrandom> ok, anything else for 0.3 status? +13:31 < deer> <kaji> .. +13:31 < deer> <duck> . +13:31 < deer> <kaji> ping? +13:31 < jrandom> p0ng +13:31 < mihi> pung +13:31 < deer> <mihi_backup> pung2 +13:32 < deer> <Pellinore> prawn +13:32 < jrandom> ok, moving on to 3) peer profiling / selection +13:32 * mihi moves the flag to the other number 3 ;) +13:32 < jrandom> (man, its kind of funny that there isn't any vegetarian seafood substitutes...) +13:32 < deer> * kaji praises 0.2.5.4.1 +13:32 < deer> <duck> the whole peer profiling thing looks at magic, how do you plan to debug that? +13:32 < deer> <Pellinore> There is vegetarian crabmeat. +13:32 < jrandom> ah, true pellinore. +13:32 < deer> <wilde> jrandom: and veg sushi +13:33 < jrandom> duck> what part of it looks like magic? +13:33 < deer> <duck> the whole classification etc +13:33 < deer> <Pellinore> And I could have sworn that I had seen some chik-type fish fillet substitute, but I could be wrong. +13:33 < deer> <duck> I mean, how do you know that you are doing optimal things? +13:33 < jrandom> the peer organizer (which moves profiles into the different groups) is a very simple and seperable component +13:33 < jrandom> oh, thats a good point. +13:34 < jrandom> i was doing some benchmarking the other day, running the organizer with 10,000 profiles, and it was organizing them all un ~50ms +13:34 < jrandom> (organizing == runningthe calculators and moving them between groups) +13:34 < jrandom> profiles also consume only ~3-4KB for a full profile, and a minimal profile takes ~200 bytes +13:35 < deer> <duck> yeah, but how do you know that you are right with '0.597s reply' for group 1 +13:35 < deer> <duck> and that it shouldnt be 0.603s +13:35 < jrandom> (so we'll keep a full profile of the best 1000 peers, and minimal of the next 10,000) +13:35 < jrandom> ah, ok, good question. +13:36 < jrandom> thats the Rate component +13:36 < jrandom> there will obviously be some flutter, and we won't be very exact. the goal ois to get ballpark and organize them accordingly +13:37 < deer> <duck> I did see it using averages +13:37 < jrandom> e.g. find the routers on T3s with quad procs, and keep them seperate from routers on 386s with 2400 bps modems +13:37 < deer> <duck> so if you throw in 100 shitty nodes, you heavily influence the average +13:37 < jrandom> agreed - there are two different aspects of that that we can tune +13:38 < jrandom> first, we can make the threshold use the top 10% to determine the "fast" vs "not fast" +13:38 < jrandom> (or top 90%, whichever) +13:38 < jrandom> second, we can adjust the Rate component to keep various statistics - rather than a simple average, it can ignore skew, find stddev, etc +13:39 < jrandom> the rate component currently is quite remedial, and I'd love if someone good with stats could take a look at it and fix it up +13:39 < jrandom> (one of the key goals of it however is to keep it scale free - so if we get 100,000 events, it doesnt have to keep all those data points in memory, etc) +13:40 < deer> <duck> ok, so what prevents another NGRouting disaster from happening? +13:40 < jrandom> but you're absolutely right - the calculators and the peer selection algorithms are going to be a major focus of future network improvements +13:40 < jrandom> ngrouting tried to do two different things - find particular data, and find available peers. +13:40 < jrandom> we only need to find available peers +13:41 < deer> <duck> good +13:41 < jrandom> (and place our tunnels there) +13:41 < deer> * duck removes breakpoint +13:41 < jrandom> :) +13:41 < mihi> but we have to find tunnels as well. +13:41 < jrandom> right mihi - the netDb is an important point +13:42 < deer> <Pellinore> I'm good with the math of statistics, but terrible with the tech aspects of translating the data into computer-useful data. +13:42 < deer> <Pellinore> But I would happily partner up with someone and contribute if I can. +13:42 < jrandom> awesome pellinore! +13:43 < jrandom> the main rate class is up at http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/core/java/src/net/invisiblenet/i2p/stat/Rate.java?rev=1.3&content-type=text/x-cvsweb-markup and we can talk later to discuss it :) +13:43 < deer> <Pellinore> k +13:43 < jrandom> (i know, i don't expect you to read the code, just mentioning it) +13:44 < deer> <Pellinore> I'll read it, but it will be about like my dog reading Kierkegaard. +13:44 < jrandom> hehe +13:45 < deer> <Pellinore> But I am learning. +13:45 < deer> <Pellinore> Anyway, please proceed -- I don't mean to bog things down. +13:45 < jrandom> (volunteering to help isn't bogging things down ;) +13:46 < jrandom> one point i forgot to mention about the peer profiling / selection code is that the 'integration' rank is only used in the network database for 'exploration', not for search/store +13:46 < jrandom> we still do (fairly) traditional kademlia search/store with all non-failing peers +13:46 < jrandom> also, within each peer group, we always choose *randomly* +13:46 < jrandom> (aka we don't always choose the fastest of the fast group, etc) +13:47 < jrandom> thats for both security and load balancing reasons +13:48 < jrandom> (security, so that an attacker can't just create a really fast router and watch everyone make use of them - they have to create a large number of really fast routers, skew the entire distribution in their favor, etc) +13:49 < jrandom> ok, do we have anything else for 3) peer profiling / selection? +13:49 < deer> <duck> . +13:50 < deer> <ughabugha> Doesn't look like it. +13:50 < jrandom> ok, moving on to 4) web architecture +13:52 < jrandom> mihi's new streaming lib gives us a lot of flexibility, plus he's mentioned a few times the desire to factor out the httpclient code into something more robust. in addition, human has started updating things to allow transparent squid(or tor-www) proxying and eepsite proxying within the same client +13:52 < jrandom> given all of these different factors, and the likelyhood that web like functionality will be important for i2p's user base, i think we should take a step back and try to envision how it should all fit together +13:53 * mihi has some code flying around on my hd for that httptunnel code. but it's far from being finished +13:53 < mihi> for me httptunnel == httpclient + some filters +13:53 < mihi> of course using my naming and streaming api. +13:54 < mihi> the code atm only allows different "anonymity profiles". +13:54 < jrandom> any thoughts on human's style of failing over to outproxies like squid/etc? +13:54 < mihi> i.e. send all requests over one destination, mux them up to 10, mux them up to one dest per hostname, etc. +13:54 < jrandom> ah, interesting +13:55 < mihi> but these dests are not used yet ;) +13:55 < jrandom> w3rd. yeah, there *is* the big caveat that having lots of destinations on one router does increase CPU load nontrivially +13:55 < jrandom> (since any garlic fail will need to fail once per dest before failing completely) +13:56 < jrandom> there is some magic left that can be used to minimize that though, i think +13:56 < deer> <ughabugha> Are you sure the transparent squid proxying is a good idea in the performance point of view? I mean, people might get too lazy and not take their eepproxy off after browsing I2P sites or using I2P squid, therefore wasting I2P bandwidth for things that don't require anonymity. +13:56 < jrandom> ughabugha> all things require anonymity :) +13:57 < jrandom> (and if they can't tell the difference, well, sheeit...) +13:57 < mihi> my intention for httptunnel is that http links will be rewritten (similarly to fproxy) so that you don't need a proxy but only a servlet. +13:57 < deer> <ughabugha> jrandom: Heh. That way, I2P was born dead. There isn't going to be enough available bandwidth on the network, that all the endnodes would likely consume. +13:58 < mihi> on that info page one might add a feature to browse the site throufh e.g. squid. +13:58 < jrandom> not quite sure i follow. i do understand and agree with the DNS issues involved (though i think we can get around them a few ways) +13:58 < jrandom> ah, ok mihi +13:58 < deer> <aum> morning all +13:58 < jrandom> mihi> so like a much much more advanced "Unable to reach peer" page? +13:59 < mihi> more like a "anonymity warning" page like in freenet ;) +13:59 < jrandom> ughabugha> if we cant handle web browsing, how are we going to handle BT/filesharing? +13:59 < jrandom> hmm mihi, but do we want that, for people who want to browse the web anonymously? or would httpclient not be the app they'd use? +14:00 < jrandom> 'mornin aum, just in time for the dev meeting :) +14:00 < mihi> jrandom: if someone just wants to browse the web anonymously, he +14:00 < deer> <ughabugha> jrandom: Hmm... Good point. Are we going to at all? ;) +14:00 < deer> <aum> jrandom: you're not on iip, you're not on irc.duck.i2p ?!? +14:00 < jrandom> ughabugha> we must. +14:01 < mihi> might configure httptunnel to so so (httptunnel will still work as a proxy, so it's quite trivial to add that) +14:01 < mihi> and most likely someone browsing the web "anonymously" will like some content filters, i guess ;) +14:01 < jrandom> mihi> i think human already did :) +14:01 < jrandom> agreed mihih +14:01 < jrandom> /hih/hi/ +14:02 < mihi> when i say httptunnel, i don't mean httpclient ;) +14:02 < jrandom> ah ok +14:02 < deer> <jrandom_> i'm here aum ;) +14:02 < mihi> but we *really* should move i2ptunnel to use the streaming api ASAP, which will reduce the number of files we must maintain +14:03 < jrandom> agreed +14:03 < mihi> human only patched the old version, i patched the new version myself +14:03 < jrandom> we ran into some bugs this afternoon, not sure if human bounced you logs yet +14:03 < deer> <wilde> another thing for the list: outproxy was taken, but more like i2p2i +14:04 < mihi> i did not get logs yet from anyone... +14:04 < jrandom> mihi> we'll get on to the streaming code asap, we can talk about it after the meeting if you've got a moment, or over email? +14:04 < deer> * aum spent part of yesterday looking at p2p apps with a view to running them on i2p +14:04 < jrandom> wilde> hmm? +14:04 < jrandom> wikked aum, anything promising? +14:04 < deer> * aum is presently inclined to favour 'push'-type filesharing, eg konspire2b +14:05 < jrandom> i2psnark could be modified to use the new i2ptunnel streaming api fairly easily too +14:05 < deer> <human> mihi: sending the logs (mihi@i2p.net, right?) +14:06 < mihi> dunno if mihi made a redirect for me +14:06 < deer> <mihi> s/mihi/jrandom +14:06 < jrandom> hmm aum, do you think that freenet/insert model really would work most effectively? +14:06 < deer> <wilde> jrandom: i was thinking of using a i2p webserver -> proxy -> internet, so people can browse a i2p site, but maybe an ordinary tunnel can manage the traffic +14:06 < jrandom> mihi> want me to set that to for ward to you? +14:06 < mihi> jrandom: nothing against it ;) +14:07 < deer> <ughabugha> aum: 'Push'-type? What's that? +14:07 < deer> <aum> what i like about konspire2b is it takes away the expectation for instant/prompt delivery, and reduces bandwidth requirement, by only broadcasting content announcements, then letting people 'subscribe' to 'content feeds' +14:07 < jrandom> mihi> done. +14:08 < deer> <aum> so instead of requesting a file, sitting and twiddling your thumbs, getting pissed off waiting for it to come in, you just 'subscribe' to the source's 'channel', then get on with other stuff +14:08 < deer> <aum> konspire2b.sf.net +14:08 < jrandom> aum> but isn't that incredibly innefficient, since you've got to manage an overlay network (broadcast) for list of things available, then you've got to relay them? +14:09 < jrandom> wouldn't a direct swarming system be much more useful / efficient? +14:09 < deer> <ughabugha> Heh. That sounds promising for I2P. +14:09 < deer> <aum> jrandom: any examples of direct swarming? +14:09 < jrandom> wilde> oh, so like the cgiproxy on duck and janonymous's site? +14:09 < jrandom> aum> bittorrent +14:10 < deer> <ughabugha> aum: Did you mean http://konspire.sourceforge.net/? +14:10 < jrandom> where you get the torrent somewhere, and get content blocks directly from peers who have it +14:10 < deer> <aum> ughabugha: guess so :) +14:10 < mihi> argl... $me->brother removed the port forward for i2p... +14:10 < jrandom> d'oh +14:10 < deer> <aum> jrandom: is anyone currently trying bt/i2p? +14:11 < deer> <baffled> aum, have you had a close look at mnet? +14:11 < jrandom> aum> eco made some headway with i2psnark +14:11 < deer> <aum> i've had a look, but not a close look +14:11 < jrandom> (though he's mia at the moment) +14:12 < jrandom> hmm, mnet with eepsite metatrackers and human's i2p/twisted transport might work +14:12 < deer> <duck> heavy testing by janonymous and me seem to show that the current i2psnark problems are 50% caused by i2p and 50% by snark +14:12 < jrandom> duck> how recently were those tests? +14:12 < deer> <duck> last week +14:12 < jrandom> though i've got no qualms with potentially exploring other bt implementations +14:12 < jrandom> ah ok +14:13 < deer> <duck> about mnet, I _think_ that you'd first to fix mnet itself before you could make that working +14:13 < deer> <duck> so you might as wel fix freenet and use that +14:13 < jrandom> heh +14:13 < deer> <aum> fix freenet, ok! right after we bring in world peace ;p +14:13 < deer> <duck> but ask in #mnet @ freenode +14:13 < deer> <Pellinore> mnet=? +14:13 < deer> <Pellinore> Mute? +14:14 < jrandom> in that sense, perhaps an azureus mod for i2p might work? +14:14 < deer> <wilde> no, a market based p2p approach +14:14 < jrandom> pellinore - mnet.sf.net, a distributed data store without anonymity +14:14 < deer> <baffled> Actually, I'm using mnet quite reliably on about five machines. +14:14 < jrandom> right, the mojonation followon +14:14 < deer> <baffled> I can't use freenet reliably on one machine. +14:14 < deer> <duck> baffled: 0.6 or 0.7? +14:14 < deer> <duck> (0.7 is with twisted iirc) +14:16 < deer> <Pellinore> jrandom -- thanks. +14:16 < deer> <Pellinore> You can't use Freenet reliably on any machine. +14:17 < deer> <baffled> 0.6.[23]. +14:17 < deer> <Pellinore> That is, among other reasons, why we are here. :) +14:17 < deer> <aum> i find that entropy works well... eventually! +14:17 < jrandom> i don't know, i still think freenet might be a good base to work from for the i2p DHT (when we can cut out most of the code and keep the data store / SSK/CHK stuff) +14:18 < jrandom> for file sharing, we should learn from the filesharing crowd what works best +14:18 < deer> <aum> but since my linuxworld article on entropy, there's gazillions of entropy nodes now, and the net has taken on some freenet performance characteristics +14:18 < deer> <Pellinore> I like the basic layout and features of Freenet, it's just that the fucker doesn't work, especially if one is using a dialup connection. +14:18 < jrandom> e.g. DC clones, BT, [or what else do those crazy filesharing people use?] +14:19 < jrandom> heh aum, damn you ;) +14:19 < deer> <duck> plus there are the things that Newsbyte did identify about entropy... +14:19 < deer> <aum> it's weaker anonymity, for example? +14:19 < deer> <baffled> Right but there are instability issues with 0.7. +14:19 < deer> <baffled> I think this connection has gotten flakey again. +14:19 < jrandom> and security issues. i think we can unfortunately pass on using entropy +14:21 < jrandom> but, erm, we're on discussion point 4, *web* architecture so for the moment lets jump back to that ;) +14:21 < deer> <aum> another mad-assed file-sharing idea - what about using nntp, with n people running linked nntpds, and just use one of those libs that breaks down files into b64 chunks and posts them, and libs to retrieve them? +14:22 < jrandom> NNTP would be really interesting - its reliable as fuck and time tested +14:22 < deer> <duck> linking the servers? +14:22 * jrandom would love to have an innd running with i2p ;) +14:23 < deer> <aum> and since i2p does the anonymity, there's no need for nntp to have it +14:23 < jrandom> right, the innd feed line could point at a local i2ptunnel proxy +14:23 < deer> <aum> and people with different servers can config the servers to cache their own choice of groups +14:23 < mihi> depending on how often they peer it would be possible to censor articles by creating message id collisions +14:23 < deer> <duck> (ever tried configuring innd?) +14:24 < jrandom> many times duck, but a loooong time ago +14:24 < deer> <aum> is innd hard to setup? +14:24 < deer> <duck> oh well, you are god +14:24 < jrandom> mihi> agreed - thats not a censorship proof distribution medium +14:24 < jrandom> aum> its a bitch +14:25 < jrandom> just like squid - its good at what it does, but we likely need something dirt simple (one click, hopefully) to bundle +14:25 * jrandom drags us back on topic +14:26 < deer> <aum> and yet another p2p/filesharing approach - i seem to recall seeing a p2p app that works via http, chaining http servers +14:26 * mihi guesses most users don't know how to set up a proxy in their brwoser... +14:26 < deer> <aum> sorry, what's the topic? +14:26 < jrandom> agenda item 4) web architecture ;) +14:26 < aum> as in, web servers within i2p? +14:26 < mihi> aum: yep +14:26 < jrandom> thats a good point mihi - a web system will want the basics (.bat, .sh scripts) for startup/shutdown +14:27 < jrandom> hmm, doesn't mozilla include a javascript url you can do to set the proxy? +14:27 < jrandom> e.g. could we have a config page on httptunnel to click "on"/"off"? +14:28 < jrandom> i realize we're not going to come to any decisions today about how the web functionality should work, but we should get some directions down +14:28 < aum> what's the problem with the current eepproxy setup? +14:29 < jrandom> e.g. filtering, inbound proxies (eeproxies), outbound servers (normal i2ptunnel server), outbound proxies (outproxies ala squid or tor-www) +14:29 < mihi> aum: it requires quite some skill both to provide and to request eepsites +14:29 < jrandom> also, the existing outproxy system sucks. +14:29 < jrandom> its wholely unscalable +14:29 < jrandom> we need something to allow/force distributing the outbound web request load across multiple outproxies +14:30 < mihi> how can users get these outproxies. config file (like in hosts.txt?) +14:30 < jrandom> and one reason why normal people would want to run outproxies is for plausible deniability - even if THEY are requesting "bad stuff", they can say "i2p did it" +14:31 < jrandom> thats one option mihhi +14:31 < mihi> jrandom: hehe +14:31 < jrandom> s/hh/h/ +14:31 < aum> but doesn't eepproxy make 'direct' http connection to the requested server, ie as 'direct' as i2p connections are? +14:31 < deer> <wilde> . /castvote DHT ala Freenet +14:31 < mihi> aum: the problem are "normal" web urls. +14:31 < jrandom> ./castvote 3 developers x 1 month x 12h / day +14:32 < deer> * human added httptunnel support to the TunnelManager, btw +14:32 < deer> <human> s/httptunnel/httpclient/ +14:32 < deer> <aum> what's that? +14:32 < deer> <aum> oh, http client support? +14:32 < deer> <human> aum: yes +14:32 < jrandom> right, we need to find a way to let people browse slashdot.org via i2p +14:32 < deer> <aum> so tunnelmgr now talks http? +14:32 < jrandom> nice1 human! +14:32 < jrandom> aum> remember the squid proxy? +14:33 < deer> <aum> yep +14:33 < deer> <wilde> jrandom: so 4 man-months roughly for a DHT? +14:33 < deer> <human> aum: yup: openhttpclient <port> [<outbound WWW proxy>] +14:33 < jrandom> wilde> i think thats reasonable, yes. +14:34 < deer> <aum> human: have you written it up anywhere? +14:35 < jrandom> aum> all it does is say "if !eepsite { send through $outboundWWWproxy } else {send to eepsite}" +14:35 < deer> <human> aum: i was going to commit, then i got stuck with a StreamingI2PTunnelServer bug... +14:36 < jrandom> a good short term solution would be a "outproxies.txt", ala hosts.txt +14:36 < deer> <aum> human: and what exactly does 'openhttpclient <port> [<outbound WWW proxy>]' do? +14:36 < jrandom> though we should start thinking about medium and long term solutions +14:37 < deer> <human> human: will open a proxy listening for connections, that will redirect to WWW-proxy all the stuff that goes to URLS not ending with .i2p +14:38 < deer> <Pellinore> Now that's interesting. +14:38 < deer> <aum> human: ahh, nice, so you split off a thread within tunnelmgr? +14:38 < deer> <human> human: i.e. you can use it to browse both eepsite and the normal web +14:38 < deer> <human> human: yes +14:38 < deer> <human> s/human/aum/ :-) +14:39 < deer> <aum> slightly outside the 'brief' of tunnelmgr, but hey, there's no other place more appropriate in the i2p code - good job d00d +14:39 < deer> <aum> human: so you talk python *and* java? is that damaging your brain? +14:39 < deer> <human> aum: i did it to avoid launching yet another JVM for the EepProxy +14:40 < jrandom> (well, the code is implement in i2ptunnel's httpclient, human just recently exposed it through tunnelmanager as well) +14:40 < deer> <aum> yes, always good to keep the jvm instances down to a minimum +14:40 < jrandom> ((and imho httpclient is exactly where it should go ;) +14:40 < jrandom> (((until mihi's NextGen httpclient [httptunnel] is out))) +14:41 < deer> <aum> is httpclient in cvs, such that it'll build for me as part of i2p update/build? +14:41 < jrandom> yes, eepProxy uses httpclient +14:42 < deer> <aum> *man this is so schizophrenic - i've got 3 xchat sessions open (irc.duck.i2p,iip,freenode)) +14:42 < jrandom> :) +14:42 < deer> <aum> wicked latency on irc.duck.i2p +14:42 < jrandom> ok, so no closure on the web architecture today, obviously, but worthwhile discussion +14:43 < jrandom> yeah aum, 15s or so for me +14:43 < jrandom> anything else on the web architecture for now, or should we move on to the 5) ??? open discussion section? +14:43 < deer> * human is thinking about an I2PSocksTunnel +14:44 < jrandom> yikes, now that'd be cool +14:44 < deer> <human> (well, maybe it belongs to 5) +14:44 < deer> <aum> socks? is there a way to 'shim' non-socks-enabled clients through to a socks interface? +14:44 < deer> <human> aum: apt-get install tsocks :-) +14:45 < aum> web discussion - one last thing - what about possibly forking /patching an existing web client +14:45 < mihi> aum: sockscap for windwos +14:45 < jrandom> aum> scary. very powerful, but scary. +14:45 < jrandom> [i'd hate to have to maintain that] +14:45 < aum> even for now, a brain-dead browser like dillo +14:46 < jrandom> [[though it could be made 'uber secure', etc. but still, very, very scary]] +14:46 < aum> or better, the browser control in wxwindows, it's multiplatform +14:46 * jrandom reminices about the orignial flinks, when it had a built in freesite browser +14:47 < aum> but then again, n00bs will whinge if they can't surf their usual m$-specific-javascript-infested sites +14:47 < jrandom> right aum, and so will hackers if it doesnt support the latest standards compliant code +14:47 < aum> hey, we should ask Microsoft for the source to IE6, then patch it ;p +14:47 < jrandom> building a browser == good way to waste thousands of man-hours +14:47 < jrandom> heh +14:47 < deer> * human is quite happy using privoxy +14:48 < aum> maybe they might toos in ie6 source as part of the European punitive settlement +14:48 < deer> <human> (http://www.privoxy.org/) +14:48 < aum> s/toos/toss/ +14:48 < jrandom> human> how would that fly for both sides of the proxy? +14:48 < jrandom> e.g. we'll want the content filtered locally, not at the outbound endpoint +14:49 < deer> <human> jrandom: users could be encouraged to install it +14:49 < jrandom> (but the outbound endpoint will want to filter some content to avoid abuse, etc) +14:49 < deer> <human> jrandom: or it may be part of the default I2P installation +14:49 < aum> what if a DWP (distrib web proxy) was using a DHT for its cache? +14:49 < jrandom> encourage == only geeks. bundle :) +14:49 < jrandom> that'd be Good aum +14:49 < deer> <human> jrandom: eheheh, agreed :-) +14:49 < deer> <human> jrandom: privoxy also runs on windogs, btw +14:50 < jrandom> word. yeah, we need some sort of content filtering - privoxy, muffin, whatever. +14:50 < deer> <wilde> long meeting... +14:50 * jrandom takes the hint.. +14:51 < deer> <Pellinore> wilde: Much to be said. +14:51 < jrandom> anyone else have anything they want to bring up? we always have the mailing list for further things +14:51 < deer> <Pellinore> And much to be done of course. +14:51 < deer> <Pellinore> I have a couple of small questions. +14:51 < aum> could we fork privoxy and 1) make it work over i2p, 2) make it use DHT for caching? +14:51 < deer> <Pellinore> But they are as easily taken up privately. +14:51 < jrandom> pellinore> whats up? +14:51 < deer> <Pellinore> Nada, sorry I said anything. +14:51 < jrandom> aum> most likely we wouldnt need to fork +14:52 < deer> <Pellinore> I'll talk to you about it privately, or duck, at another time. +14:52 < deer> <Pellinore> Not really dev-specific stuff. +14:52 < deer> <duck> 10+16+7=33 manhours wasted on this one-hour overtime :) +14:52 < jrandom> but building a DHT is a lot of effort. wholely incredibly worthwhile +14:52 -!- Irssi: #i2p: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal] +14:52 * aum goes again to visit infoanarchy.org wiki pages on DHTs +14:52 < jrandom> there are 16 people on iip? +14:53 < deer> <human> aum: no need to fork, just: web browser <-> privoxy <-> httpclient <-> i2p <-> outbound proxy <-> www.pr0n.com +14:53 < deer> <wilde> a generic DHT that would work outside I2P too, and that allows other binding than http +14:53 < jrandom> aum> check out the link duck added to the i2p wiki, listing various ones +14:54 < deer> <human> aum: you can configure privoxy to make it connect to another HTTP/socks proxy (that's how my I2P-to-tor privoxy works) +14:54 < deer> <duck> (http://www.bamboo-dht.org/) +14:54 < aum> not sure i like the idea of a dht working outside i2p - the best dht is one without anonymity (and the anonymity overhead) that can work most optimally within i2p +14:54 < jrandom> hrm duck, what happened to that list of 'em? +14:54 < deer> <duck> aum: easier to test +14:55 < deer> <duck> jrandom: some commie did remove it I guess +14:55 < jrandom> heh +14:56 < jrandom> google++ : http://www.etse.urv.es/~cpairot/dhts.html +14:56 < jrandom> (not the same page, but interesting) +14:56 < jrandom> oh, here's the page - http://himalia.it.jyu.fi/ffdoc/storm/pegboard/available_overlays--hemppah/peg.gen.html +14:57 < jrandom> but yes, a DHT that doesnt try to implement anonymity, plus a DHT that supports both CHK-style and SSK style content would be best +14:58 < jrandom> (SSK style not being strictly necessary, but damn it would be really useful) +14:58 < jrandom> but, anyway +14:58 < jrandom> anyone got anything else they want to bring up? +14:59 < deer> <duck> tomorrow is St. Patrick's Day +14:59 < deer> <wilde> topic 5) ? +14:59 < deer> <duck> so all drink irish beer +14:59 < jrandom> good point +14:59 < deer> <Pellinore> TOmorrow is both the anniversary of my current relationship, and of my second marriage. +14:59 * jrandom takes note to avoid irish pubs tomorrow +15:00 < jrandom> oh, congrats pellinore :) +15:00 < jrandom> wilde> we're on 5) ??? +15:01 < jrandom> (and about to be on 6) [baf]) +15:01 * jrandom will be coming to iip momentarily [if i can] +15:01 * jrandom winds up +15:01 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/81.rst b/i2p2www/meetings/logs/81.rst new file mode 100644 index 00000000..b1dcd2c5 --- /dev/null +++ b/i2p2www/meetings/logs/81.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 16, 2004 @ 13:00 PST +=========================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/82.log b/i2p2www/meetings/logs/82.log new file mode 100644 index 00000000..8e863108 --- /dev/null +++ b/i2p2www/meetings/logs/82.log @@ -0,0 +1,464 @@ +[22:01:22] <jrand0m> agenda: +[22:01:22] <jrand0m> 0) Hi +[22:01:22] <jrand0m> 1) Network status +[22:01:28] <jrand0m> 2) 0.3.1 plan +[22:01:28] <jrand0m> 3) Web architecture +[22:01:28] <jrand0m> 4) Administravia +[22:01:34] <jrand0m> 5) ??? +[22:01:38] <jrand0m> 0) hi +[22:01:39] <no_dammagE> of yourse +[22:01:43] <ughabugha> Oh, cool, the meeting. :) +[22:01:51] <jrand0m> hi, welcome to the weekly dev meeting, number $something +[22:01:56] <ughabugha> Hi. +[22:02:02] <jrand0m> weekly status notes up at http://i2p.net/pipermail/i2p/2004-March/000180.html +[22:02:09] * mihi has joined #i2p +[22:02:13] <fidd> howdy +[22:02:32] <jrand0m> we'll see if we can avoid a 2 hour session today ;) +[22:02:39] <jrand0m> ok, jumping to 1) network status +[22:02:43] <Masterboy> :P +[22:02:56] <jrand0m> we got 0.3.0 out on sunday, and its generally functional +[22:03:12] <Masterboy> yes it is:) +[22:03:23] <ox> * jrandom waves from i2p#i2p to prove it ;) +[22:03:43] <jrand0m> there are still some bugs to fix, and a new set of things to be addressed, but ever onwards we go +[22:04:21] * ion has joined #i2p +[22:04:22] * ughabugha is reading the status notes. +[22:04:27] * mrflibble has quit IRC (r eboot time) +[22:04:35] <jrand0m> in the email i mention a new network monitoring tool duck put together - http://duck.i2p/dot/dot.png (or a snapshot at http://i2p.net/~jrandom/profiles.png) +[22:05:05] <jrand0m> it basically gives us a view into how the network is doing - how many people are out there, and how well they're finding out about reliable and fast resources +[22:05:22] <jrand0m> (basically it visualizes the result of the 0.3 peer profiling and selection process) +[22:05:50] <ox> <duck> nice! +[22:06:22] <jrand0m> yeah, its nice to see the visual feedback on the algorithms, rather than manually going through the networkDb +[22:06:37] <ox> <Masterboy> there's a need of cpu usage decreasing.. +[22:06:38] <fidd> :) +[22:06:48] * jrand0m gives the eepSiteAppOfTheWeek award to duck for dot.png +[22:06:54] <ughabugha> Yeah, I wonder what would we be doing without duck? +[22:07:08] <ox> <duck> maybe we can make an audio version too +[22:07:17] <fidd> haha +[22:07:20] <jrand0m> :) +[22:07:22] <human> heheh +[22:07:34] <fidd> or a smell-one +[22:07:47] <ughabugha> Yeah, and stream it over jnon's icecast every hour. +[22:07:51] <no_dammagE> how do I understand the speed column in #transport? +[22:08:00] <no_dammagE> I mean peer profiles +[22:08:25] <jrand0m> no_dammagE> good question. if you read the bottom text below, it explains that the numbers have no correlation with anything - they're strictly relative values. +[22:08:50] <no_dammagE> ok :) +[22:09:15] <jrand0m> if you want the *real* answer, see http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/router/java/src/net/invisiblenet/i2p/router/peermanager/SpeedCalculator.java?rev=1.3&content-type=text/x-cvsweb-markup +[22:10:07] <jrand0m> the network has also grown to a steady 18-22 routers, which is a good size for the moment +[22:10:31] <jrand0m> we'll want to grow a bit more once some of the existing bugs are dealt with, and the 0.3.1 phttp code is in place +[22:10:36] <KyroxX> re +[22:10:45] <jrand0m> wb KyroxX +[22:11:03] <jrand0m> ok, that leads us into 2) 0.3.1 plan +[22:11:16] <no_dammagE> mine will go off in 30 minutes and will go on in ~ 20 hours (or ill make it on the autostart so that it will be started with the PC) +[22:11:29] <jrand0m> cool no_dammagE, thats fine +[22:11:33] * fR has quit IRC (Ping timeout) +[22:12:01] <jrand0m> rather than get the phttp code, the bandwidth limiter, and the new collusion deterrent all in one 0.3.1 release, i'm pushing the collusion deterrent into 0.3.2 +[22:12:19] <jrand0m> roadmap hasn't yet been updated, but things are pretty much the same +[22:12:45] * fR has joined #i2p +[22:13:17] <ughabugha> Are you going to release 0.3.0.1? +[22:13:18] <jrand0m> there's going to be some complex stuff in the phttp revamp, dealing with throttling the connections, but we'll see how it goes +[22:13:36] * KyroxX has quit IRC (Verlassend) +[22:13:47] <jrand0m> perhaps, though currently the roadmap lists 0.3.1 as next week +[22:13:54] <jrand0m> sunday, even. +[22:14:01] <ox> <baffled> I knew you was in collusion with somebody. +[22:14:02] <jrand0m> so i'm not sure +[22:14:03] * Rom|Away|3h has quit IRC (Ping timeout) +[22:14:04] <Masterboy> how can i limit the cpu usageof my router? why not make : "low" - "normal" - "high" - so you could choose? +[22:14:10] <jrand0m> heh baff +[22:14:11] <no_dammagE> why is that critical?: +[22:14:11] <no_dammagE> 21:55:36.249 CRIT [I2CP Reader ] et.invisiblenet.i2p.util.Clock: Updating clock +[22:14:12] <no_dammagE> offset to 105791ms from 0ms +[22:14:16] * Romster has joined #i2p +[22:14:24] * jar has quit IRC (Ping timeout) +[22:14:38] <jrand0m> Masterboy> the code to work along those lines is planned for the 1.0rc1 release +[22:14:43] <jrand0m> (router throttling) +[22:14:48] * KyroxX has joined #i2p +[22:14:50] <jrand0m> we've got some basics, but its not ready yet. +[22:15:08] <KyroxX> re +[22:15:13] <jrand0m> no_dammagE> because it should only occur at most once - if you see it happening a lot, its an issue +[22:15:14] <Masterboy> oki +[22:15:21] <jrand0m> (a critical issue) +[22:15:48] <jrand0m> any other questions / concerns on the 0.3.1 release? +[22:15:55] <mihi> then it should be debug the first time and then crit... +[22:16:06] <jrand0m> you're right +[22:16:09] <KyroxX> whats the topic? +[22:16:17] <ughabugha> jrand0m: Err.. How can this occur on I2P? Closing Link: [unknown@192.168.0.2] (Ping timeout) +[22:16:31] <jrand0m> KyroxX> the weekly dev meeting, item 2) 2) 0.3.1 plan +[22:16:35] <ughabugha> Ah, never mind. +[22:16:40] <jrand0m> ughabugha> ircd patch +[22:16:49] <KyroxX> ah +[22:17:02] <ox> <duck> my ircd is running on nsa.localdomain +[22:17:06] <jrand0m> hmm +[22:17:08] <ox> <duck> which has 192.168.0.2 as IP +[22:17:12] <jrand0m> ah +[22:17:30] * Romster has quit IRC (Ping timeout) +[22:17:32] <jrand0m> ok, moving on to 3) Web architecture +[22:17:49] * ion has quit IRC (Ping timeout) +[22:17:58] <jrand0m> i know we discussed this last week a bit, and there's been some discussion on the mailing list about it too +[22:18:02] <mihi> how can i make an account on drupal.i2p.net? +[22:18:15] * mihi is too stupid for that... +[22:18:16] <jrand0m> wilde> can you add one for mihi? +[22:18:31] <jrand0m> (there's no way to register normally) +[22:18:35] <mihi> jrand0m: you could simply say no, then i know i can stop trying ;) +[22:18:42] <jrand0m> if wilde isn't around, i'll add one for you momentarily :) +[22:18:51] * Romster has joined #i2p +[22:19:04] * Romster is now known as Rom|Away|3h +[22:19:18] <fidd> i'd like one too if its ok :) +[22:21:05] <ox> <jmand> /ping jmand +[22:21:12] <jrand0m> ok, back to the web arch stuff +[22:22:06] <jrand0m> there are several different aspects of "how we use the web" in i2p, and we can either treat them all as OneBigWebThingy, or we can talk about specializing the components, making things that do their OneThingWell +[22:22:34] * ion has joined #i2p +[22:22:44] <jrand0m> mihi brought up some good points that I hadn't been looking at, some valuable features that we'll certainly want +[22:23:03] <ughabugha> jrand0m: Are you talking about the separation of Squid and I2P web? +[22:23:11] <ughabugha> Or something deeper? +[22:23:24] <duck> the 'HTTPTunnel vs. {privoxy,muffin} + HTTPClient' thread +[22:23:30] <duck> (http://i2p.dnsalias.net/pipermail/i2p/2004-March/) +[22:23:48] <jrand0m> the seperation of squid and eepsites, as well as the seperation of browser proxies vs. (essentially) cgis +[22:23:49] <ughabugha> Right. +[22:24:00] <jrand0m> and, of course, the filters +[22:24:48] <jrand0m> since we all work in the open source world here, there's no real need to have OneBigThing that deals with all of the different use cases - we can build one to address a need, then reuse its code for another to address another need +[22:24:56] * jar has joined #i2p +[22:25:04] <duck> I tend to agree with human's latest post +[22:25:13] <jrand0m> plus, with mihi's new streaming I2PTunnel api, its fairly easy to build off +[22:26:42] <jrand0m> as do i, though i don't have the time to work on httptunnel, so its really up to mihi as to what use case he's most interested in addressing first +[22:26:48] * lucky has joined #i2p +[22:27:45] * jar has quit IRC (EOF From client) +[22:27:52] <jrand0m> mihi> any thoughts? +[22:28:26] <jrand0m> ok or anyone else? :) +[22:28:47] <duck> http://i2p.i2p/ looks ugly to me +[22:28:55] <duck> but even that could be survived +[22:28:59] <jrand0m> i2p.i2p? +[22:29:05] <human> ? +[22:29:27] * ion has quit IRC (Ping timeout) +[22:29:28] <jrand0m> i could add in a dns entry for eep.i2p.net pointing to 127.0.0.1 for machines that do bad dns things +[22:30:01] * fR has quit IRC (EOF From client) +[22:30:20] * human didn't get the latest proposal :-) +[22:30:27] <duck> I think I did see i2p.i2p mentioned somewhere as replacement for the current http://i2p/keybla +[22:30:35] <jrand0m> yours was the latest human +[22:30:54] <jrand0m> oh, right, yeah on irc last night i think jnano was discussing it +[22:30:55] <human> jrand0m: i mean: "i could add in a dns entry for eep.i2p.net pointing to 127.0.0.1 for machines that do bad dns things" +[22:31:03] <mihi> duck: you have good eyes. i did this to prevent netbios lookups in Opera. +[22:31:21] <duck> ah yeah "code/apps/i2ptunnel/java/src/net/invisiblenet/i2p/httptunnel/handler/RootHandler.java" +[22:31:21] <jrand0m> ah sorry human, i meant that with regards to what mihi just said :) +[22:31:23] * lucky has quit IRC (Ping timeout) +[22:31:49] <duck> it is a shame that some browsers need such workarounds +[22:31:55] <human> wew +[22:32:15] <jrand0m> human mentioned something about socks4 not requiring that? +[22:32:15] * KyroxX is now known as wbk +[22:32:23] <duck> socks4a +[22:32:29] <jrand0m> ah ok +[22:32:39] <duck> (socks4 does DNS) +[22:32:49] <jrand0m> do all browsers support socks4a? +[22:32:59] <human> jrand0m: socks4 is Evil(TM), but socks4a and socks5 delegate name resolution to the server +[22:33:00] <duck> s/socks4 does DNS/with socks4 the client does DNS/ +[22:33:06] <mihi> some browsers don't even support socks proxies... +[22:33:08] <human> jrand0m: yes, AFAIK +[22:33:27] <jrand0m> right, plus the kiosk issue mihi, certainly +[22:33:52] <duck> it could be an alternative +[22:34:04] <duck> httpclient + socksclient + etc +[22:34:29] <human> jrand0m, mihi: programs that don's support socks could be tsocks'ed +[22:34:53] <jrand0m> human> unless its a kiosk, where people can't run apps +[22:35:00] <jrand0m> (or change settings, etc) +[22:35:19] <human> jrand0m: yes, of course socks tunnels aren't suited for these tasks +[22:35:31] <duck> (human: though then they'd still call gethostbyname) +[22:35:39] <jrand0m> would they duck? +[22:35:55] <human> duck: no, tsocks even inhibits them and forwards them to the proxy server +[22:36:16] <human> duck: (dunno what happens in the windows world, though) +[22:36:30] <jrand0m> they BSOD +[22:36:32] <jrand0m> er.. +[22:36:57] <duck> (not according to /usr/share/doc/tor-0.0.2_pre27/CLIENTS.gz) +[22:36:57] <human> heheheh +[22:37:07] <jrand0m> heh duck +[22:37:18] <human> socks tunnels, however, will not replace www proxies :-) +[22:37:24] <duck> (( </tortechnotalk> )) +[22:38:25] <jrand0m> mihi> whats your take on the highest priority use case for httptunnel? if there's something we can help with? +[22:38:31] <mihi> http://home.arcor.de/mschierlm/test/nosocks.png (which browser is that?) +[22:38:31] <human> it's just an add-on to do some neat stuff with tunnelling, chaining etc. +[22:38:31] <wbk> I2P is the ircd of iip right? +[22:38:31] <duck> anyway, all solutions need a clientside filter +[22:38:47] <human> duck: yes, according to man 8 tsocks :-) +[22:39:14] <jrand0m> dunno mihi, opera? +[22:39:19] * fR has joined #i2p +[22:39:19] <duck> wbk: no private msg +[22:39:19] <jrand0m> wbk> no +[22:39:30] <mihi_backup> jrand0m: make it work perfectly with post requests && make it do everything httpclient does +[22:39:45] <jrand0m> word +[22:40:08] <ughabugha> mihi: That's Opera. +[22:40:14] <human> mihi: dunno, but as i wrote above: socks tunnels, however, will not replace www proxies :-) +[22:40:18] <ughabugha> If you ment that as a question. :) +[22:41:13] <jrand0m> ok, cool, anyone have anything else to bring up for web stuff, or are we ready for 4) Administravia? +[22:42:23] <jrand0m> ok, just some notes - +[22:42:24] * Rom|Away|3h is now known as Rom|Away|4h +[22:42:51] <jrand0m> the drupal site is back online, so anyone who wants to help out with that, or see the latest progress, please hit drupal.i2p.net :) +[22:44:02] <jrand0m> on it, you'll find the other two administravia points - the team roster [http://drupal.i2p.net/team] and the draft of a new license policy [http://drupal.i2p.net/node/view/85] +[22:44:26] <duck> I was looking at the license policy... +[22:44:35] <duck> AFAIK Cryptix == BSD +[22:44:43] <jrand0m> right +[22:44:52] <duck> (but with Cryptix team as copyrightor instead of regents of massachusets or something) +[22:44:52] <jrand0m> but, strictly, its the Cryptix license ;) +[22:45:05] <duck> what is MIT? +[22:45:13] <jrand0m> mit is == bsd 2 clause +[22:45:16] <jrand0m> == x +[22:45:19] <duck> what code is MIT I mean +[22:45:25] <jrand0m> nothing +[22:45:29] <human> == x < 4.4.0 +[22:45:36] <jrand0m> i just list it as "if you want to use MIT, great" +[22:45:42] <jrand0m> right human :/ +[22:45:49] <duck> the amount of licenses is already quite a few +[22:45:56] <duck> I was wondering if that could be restricted +[22:46:07] <duck> for example changing the GPL code into BSD or even pubdomain +[22:46:31] <duck> was wondering what the author(s) of that part(s) did think about that +[22:46:32] <ox> <no_dammagE> so, chatroom, ill go sleep now. Good code @ Devteam, good time of day to all others. Till tomorrow. +[22:46:40] <duck> bye no_dammagE +[22:46:41] <jrand0m> i would love if the i2ptunnel streaming lib / naming lib or even the full i2ptunnel were licensed under a bsd-like license +[22:46:51] <jrand0m> later no_dammagE +[22:46:55] <no_dammagE> cu +[22:46:58] * no_dammagE has quit IRC +[22:47:19] * jar_backup has joined #i2p +[22:47:50] <jrand0m> but, of course, GPL is fine, t'is mihi's right :) +[22:48:06] <mihi> for streaming/naming lib that would be okay for me (or BSD or LGPL). but I'd like to keep GPL for the core I2PTunnel +[22:48:07] <ughabugha> Well, whatever the license is, it should be GPL-compatible. +[22:48:36] <ughabugha> (Ie, it shouldn't be more restrictive than GPL) +[22:48:42] <human> i'm a GNU GPL advocate, but i think that the best license to disseminate new protocols and formats is something BSD-style (e.g. see how the OGG Vorbis guys relicensed everything from LGPL do MIT-X11) +[22:49:05] <jrand0m> mihi> the streaming and naming lib are funcional without dependency upon i2ptunnel itself, right? +[22:49:14] <ughabugha> Yeah, reference implementation shouldn't be GPL. +[22:49:25] <mihi> they should be. if not, it's a bug. +[22:49:30] <jrand0m> BSD 2 clause on those would be fantastic +[22:49:40] <human> yup! +[22:49:45] <mihi> you can have naming lib public domain if you include it into core ;) +[22:50:02] * ion has joined #i2p +[22:50:03] <jrand0m> absolutely, I'd love to include them in the core sdk +[22:50:42] <mihi> them? ;) (including streaming lib into core would be a bad idea imho, since it is too less open for other impls) +[22:51:09] <jrand0m> well, the sdk impl itself makes some nontrivial design assumptions - its just a ref impl +[22:51:22] <jrand0m> i'd love if people could take i2p.jar and write a streaming app +[22:51:28] <human> mihi: regarding I2PTunnels & GPL: i'd suggest to add an explicit GNU GPL exception that allows people to link your app with proprietary JVMs (see my comment on http://drupal.i2p.net/node/view/85) +[22:51:28] * Masterboy has quit IRC (Ping timeout) +[22:51:59] <duck> human: that brings up the "have to hire a lawyer before I can use it"-problem +[22:52:01] <jrand0m> (perhaps we can split the current i2ptunnel into i2ptunnel and i2pstreaming, if you'd prefer?) +[22:52:32] <mihi> jrand0m: that would be okay for me. just change the ant task to build 2 jars ;) +[22:52:35] <human> duck: i suggest to add the exception just to avoid it +[22:52:39] <jrand0m> duck> if mihi is willing to BSD the streaming and naming libs, i don't think that'd be too much trouble +[22:53:30] <mihi> and better make i2pministreaming instead of i2pstreaming +[22:53:41] <duck> mihistreaming :) +[22:53:48] <mihi> (note the n in mi4ni) +[22:54:02] <mihi> duck: that was exactly what i thought ;) +[22:54:03] <jrand0m> word mihi, so perhaps we can revise the table on http://drupal.i2p.net/node/view/85 to list the I2PTunnel core as GPL (perhaps with the exception human mentions?), plus a seperate I2PMiniStreaming line as BSD? +[22:54:04] <jrand0m> hehe +[22:54:10] <jrand0m> i2pmihistreaming is good too :) +[22:55:25] <duck> ok +[22:55:40] <duck> next week I'll try to convince you all to move totally to publicdomain +[22:55:45] <duck> but this is enough for now :) +[22:55:48] <jrand0m> :) +[22:55:50] <human> hehe +[22:56:06] <jrand0m> mihi*=5 +[22:56:14] <mihi> jrandom**=5; +[22:56:21] <duck> wbk did just offer to help with the webdesign +[22:56:36] <jrand0m> oh awesome duck +[22:56:45] <jrand0m> well, briefly before we jump to 5) +[22:56:58] <jrand0m> do any devs have any qualms with the /policy/ in http://drupal.i2p.net/node/view/85? +[22:57:05] <duck> so I did do a bureaucratic team-table lookup and delegate him to wilde +[22:57:25] <human> before jumping... what about the GPL + exception suggestion? +[22:57:29] <jrand0m> aka "implicitly under $primaryLicense" or "explicitly under $alternate"? +[22:57:47] <jrand0m> duck++ :) +[22:58:02] <mihi> human: I'm adding it atm +[22:58:07] * human agrees with jrand0m's policy +[22:58:25] <duck> what about copyright owner +[22:58:28] <human> mihi: ok, thanks +[22:58:30] * duck did see human adding some new files as GPL +[22:58:36] <duck> and putting mihi's name on that +[22:58:45] <ughabugha> Err... I don't think drupal likes passwords which are 32 characters long. +[22:58:51] <human> duck: i just cut'n'pasted existing files +[22:59:18] <duck> ok, but what if we have 50 ppl working on it and each putting their own name on the copyrights +[22:59:20] <jrand0m> for people that add public domain code, there's no copyright, but for people who use copyright, people should copyright it themselves +[22:59:22] <human> duck: (well, even if i'm forgetting to put copyrights into files...) +[22:59:25] <duck> then you cant switch license at a later point +[22:59:29] <jrand0m> thats fine duck, in my opinion +[22:59:53] <jrand0m> e.g. thecrypto should be the copyright owner of his encryption and SHA routines +[23:00:03] <human> (i was still observing jrand0m's policy to stick with module licenses, btw) +[23:00:05] <jrand0m> though since he's released it under BSD 2 clause, we will use it +[23:00:38] <jrand0m> oh, maybe i'm missing the point - you want to make sure everyone puts their own name on it? +[23:00:44] <duck> no +[23:00:49] * jrand0m assigns copyright to richard nixon +[23:00:56] <human> heheh +[23:01:34] <human> btw: in my country, "public domain" is just another kind of copyright +[23:01:46] <jrand0m> hmm. i2p doesn't have any legal entity to receive copyright (and *never* will) +[23:02:02] <human> i.e. you (the author) distribute your works without any restrictions +[23:02:18] <jrand0m> right, a lot of countries have fucked up IP laws +[23:02:59] <human> jrand0m: just to say that maybe it's better to put something like "i've created this file, and you can use it without any restriction" in each file +[23:03:13] <jrand0m> that i think is a good idea +[23:03:47] <human> jrand0m: (it's still happening, of course, but i think it should be a requirement :-) +[23:03:55] <jrand0m> thats why i included the "jrandom wrote this in $year and releases it into the public domain" ;) +[23:04:08] <human> jrand0m: yeah :-) +[23:04:27] <jrand0m> so i'm missing ducks point +[23:04:37] <fidd> and that thing abouth eating children +[23:04:37] <duck> I lost it too +[23:04:43] <jrand0m> :) +[23:04:44] <human> heheh +[23:04:47] <duck> lets forget it +[23:04:58] * lucky has joined #i2p +[23:05:13] <jrand0m> ok, so I'll add to the commit priv section the suggestion that people make note of their authorship of what they write +[23:05:22] <jrand0m> (even if they dont copyright it?) +[23:05:24] <lucky> hi +[23:05:25] <lucky> :D +[23:05:39] <jrand0m> s/suggestion/<i>suggestion</i>/ +[23:05:42] <jrand0m> hi lucky +[23:05:50] <jrand0m> [damn i borked my regexp] +[23:05:57] <duck> want me to PGP sign a statement? +[23:06:09] <jrand0m> i'm going to, yes +[23:06:30] <jrand0m> once the policy is ready and revised, i'll be contacting all prior committers for PGP/GPG auth +[23:06:33] <human> jrand0m: yes (in my country it's impossible to refuse copyright, it's seen as an inalienable author's right) +[23:06:52] <duck> yes, your country is fucked +[23:06:53] <duck> NEXT +[23:06:56] <duck> (oops) +[23:06:58] <jrand0m> :) +[23:07:19] <fidd> human, what country? +[23:07:39] <human> jrand0m: so, "this file is not copyrighted" just doesn't make sense - you should *always* explicitly say that you're the author, and that you put no restrictions on your work +[23:07:47] <human> fidd: somewhere near Europe :-) +[23:07:54] <fidd> heh, ok +[23:07:59] <lucky> human: you can later say you don't want the copyright +[23:08:03] <lucky> and put it in the public domain. +[23:08:19] <jrand0m> human> with the "implicit release under $primaryLicense", that should address the issue though, right? +[23:08:24] <duck> human means that that doesnt mean anything in $fuckedcountry +[23:08:42] <jrand0m> human> since that implicitly means commit == release as $primaryLicense +[23:08:50] <human> duck: yup, exactly +[23:09:07] <jrand0m> (so no comment == implicit license by $author, per `cvs log`) +[23:09:28] <jrand0m> (ah, legalese in code ;) +[23:09:36] <human> jrand0m: well, i'm not a lawyer... but i think it should work +[23:09:43] * kaji has joined #i2p +[23:09:48] <ox> * wilde agrees with the last proposal +[23:09:57] <jrand0m> w3rd. +[23:10:05] <jrand0m> ok, i'll see if i can get the eff to review +[23:10:19] <jrand0m> moving on to 5) ??? +[23:10:21] <human> jrand0m: maybe it's better to have some sort of agreement when ppl are given CVS access +[23:10:46] <ox> <wilde> when will we see, net.i2p.legal.LicenseManager? +[23:10:47] <jrand0m> agreed human> explicit agreement with $policy will be a prerequisit for getting commit privs +[23:10:50] <jrand0m> heh +[23:10:52] <human> jrand0m: (for example, GPG signing the your policy, and hosting it on the I2P site?) +[23:11:00] <human> heheh +[23:11:04] <jrand0m> reasonable enough human. +[23:11:13] <mihi> jrand0m prefers PGP8 ;) +[23:11:23] <jrand0m> damn straight. pgpdisk++ +[23:12:06] * wilde has joined #i2p +[23:12:14] <duck> hi wilde +[23:12:36] <jrand0m> ok, does anyone have anything they want to bring up for 5) ??? +[23:13:27] <wilde> just an invitation one more time for people to visit drupal and comment, modify, etc +[23:13:37] <jrand0m> word, yes, thats a good point +[23:13:41] <duck> http://drupal.i2p.net/ +[23:13:41] <wilde> so we can have good docs for 1.0 +[23:13:41] <mihi> human, jrand0m: is the license in CVS okay now? ;) +[23:13:55] <jrand0m> on http://drupal.i2p.net/team there are a lot of [vacant] roles. volunteer! +[23:14:02] <fidd> i cant get drupal thru squuid :/ +[23:14:17] * mihi volunteers for QS guy cuz of echo server ;) +[23:14:29] <mihi> s/QS/QA/ +[23:14:33] <jrand0m> woot! +[23:15:01] <wilde> unit tests for echo server +[23:15:12] <mihi> wilde rofl no +[23:15:17] <human> mihi: maybe you should s/XXXX/mihi/ in the GPL exception :-) +[23:15:20] <ughabugha> jrand0m: Heh, what do you mean by stress testing? :) +[23:15:34] <mihi> echo server is system test for i2p ;) +[23:15:38] <mihi> human: oops ;) +[23:15:56] * Rom|Away|4h has quit IRC (Ping timeout) +[23:16:08] <jrand0m> ughabugha> it means you smash (aka use) the router and have patience with me to debug it, submitting reports and logs +[23:16:35] <ox> <wilde> thus stress testing poor jrandom... +[23:16:40] <ughabugha> jrand0m: Oh, okay. :) +[23:16:44] <duck> wow, mihi is fast +[23:16:47] <ughabugha> Hehe. +[23:17:30] * Romster has joined #i2p +[23:17:40] <mihi> duck: editor still open and the CVS comment was fast to type as well ;) +[23:17:40] <jrand0m> mihi> licenses look great - just to be explicit, you're idented here, and you intend to release under the bsd 2 clause [per http://opensource.org/licenses/bsd-license.php], correct? +[23:17:41] * Romster is now known as Rom|Away|4h +[23:18:02] <jrand0m> (or you can just add that copyright text into the source) +[23:19:24] <mihi> hmm, what does idented mean? (yes to your second subclause) +[23:19:42] <jrand0m> means you've proven to trent that you're mihi :) +[23:19:50] <duck> authenticated +[23:19:54] <mihi> ok, identified ;) +[23:20:01] <jrand0m> w3rd +[23:20:06] <human> let's try identicated +[23:20:14] <mihi> it looked to me like "indented" and i thought that my white space was incorrect ;) +[23:20:20] <jrand0m> hehe +[23:20:43] <ox> * wilde thinks launches word for find yet another synonym +[23:21:07] <human> authentified? +[23:21:22] <duck> anyway... +[23:21:28] <jrand0m> ok, r0x0r, anyone have anything else to bring up? +[23:21:44] <ox> <wilde> yeah +[23:21:50] <ox> <wilde> eep naming +[23:22:00] <jrand0m> heh you don't like my pronounciation? +[23:22:12] * kaji has quit IRC (Ping timeout) +[23:22:14] <ox> <wilde> of i2p -> eep +[23:22:14] * Rom|Away|4h has quit IRC (Ping timeout) +[23:22:21] <jrand0m> oh +[23:22:30] <jrand0m> you want to rename the whole project "eep" ? +[23:22:39] <human> lol +[23:22:48] <ox> * wilde mutters +[23:22:48] <mihi> envisible enternet project ;) +[23:23:08] <lucky> envisible +[23:23:09] <jrand0m> extrordinarily excellent people +[23:23:15] <lucky> connotates something for me. +[23:23:46] <mihi> even easier publishing ;) +[23:23:51] <jrand0m> ooOOoo +[23:23:51] <lucky> As in its going to be visable, therefore possible. envision maybe? +[23:23:53] <ughabugha> Come on, stop picking on wilde. :) +[23:23:54] <ox> <wilde> seriously, do you like the name then it's fun? +[23:24:06] <ox> <wilde> fine i mean, getting tired +[23:24:44] <ox> <wilde> new users will not have it easy +[23:25:03] <jrand0m> oh, i'm not a marketeer. we went under "eep" because its all i could think of +[23:25:23] <human> i think it should be forbidden to explain that eep ~= i2p, or users will *really* screw up +[23:25:25] * ion has quit IRC (Ping timeout) +[23:25:26] <jrand0m> what should we call websites that people both host and access through i2p? +[23:25:38] <jrand0m> hehe +[23:25:42] <duck> i2psites? +[23:25:44] <ox> <wilde> i2p site? +[23:25:57] * human likes eepsites without explanations :-) +[23:26:09] * kaji has joined #i2p +[23:26:25] * jrand0m asks the http://drupal.i2p.net/team user advocate for their opinion +[23:26:35] <duck> we got one? +[23:26:38] <jrand0m> no +[23:26:43] <jrand0m> ;) +[23:26:52] <duck> heh +[23:26:55] <human> anyway... you can change all the naming, as long as the "Shitlist" keeps its current name +[23:26:56] <ox> * wilde rushes to the browser +[23:27:01] <jrand0m> heh +[23:27:06] <mihi> lol human +[23:27:07] <jrand0m> oh, shitlist is going to stay, for sure ;) +[23:27:21] <ox> <wilde> i take the role, it should be i2p sites, i resign +[23:27:21] <duck> I bet that shitlist is a proper english word +[23:27:24] <jrand0m> i mean, "blacklist" just isn't as fun +[23:27:26] <jrand0m> hah wilde +[23:27:29] <human> jrand0m: cool! +[23:27:56] <ughabugha> But why not stick to the current names? +[23:28:05] * human was worried that the shitlist was going to be the first victim when I2P goes corporate +[23:28:06] <jrand0m> ok, i don't really care either way, i2psite is fine, eepsite is fine +[23:28:09] <ughabugha> I mean we have enough time to consider it on the mailing list until 1.0. +[23:28:09] <mihi> jrand0m: and the elephants on the moon have to stay too ;) +[23:28:22] <kaji> so is kaji.i2p up for anyone. i kinda just started it up without testing anything and left it running +[23:28:31] <jrand0m> human> i think we don't have to worry about that one ;) +[23:28:35] <ughabugha> kaji: It worked for me. +[23:28:48] <jrand0m> we have to keep moving the easter eggs mihi :) +[23:28:48] <ox> <wilde> i don't really care, eepsite is just as boring as i2psite +[23:29:05] <jrand0m> we can consider them synonyms +[23:29:23] <ox> <wilde> that the worst decision ;) +[23:29:44] <duck> wbk: ok, I have to leave for a bit. The meeting is almost over so people can help you in #i2p +[23:29:44] * jrand0m supposes that now that i've taken on the title of PM i've got to make a decision +[23:29:48] * ion has joined #i2p +[23:29:55] * jrand0m kicks self +[23:30:09] <human> heheh +[23:30:12] * mihi guesses jrand0m needs some support for that +[23:30:19] * Trent@anon.iip sets mode: +o mihi +[23:30:27] * mihi sets mode: +o jrand0m +[23:30:30] <@jrand0m> ooOOoo +[23:30:32] * mihi sets mode: -o mihi +[23:30:49] <ox> <wilde> ok no more questions from me +[23:30:55] * human sacrifices his pet to the PM +[23:31:38] * mihi still waits for jrand0m kicking himself... +[23:31:44] <@jrand0m> i think there's benefit to discussion, as well as some quirkiness. i also lean in human's direction - there's no need to confuse people by explaining "eep != i2p" +[23:31:59] * @jrand0m Offically Decides "eepsite" +[23:32:23] * You were kicked by jrand0m (bastard!) +Session Close: Tue Mar 23 23:32:23 2004 +Session Start: Tue Mar 23 23:32:30 2004 +[23:32:32] <human> lol +[23:32:37] <duck> lets quickly baff the meeting closed +[23:32:40] <duck> oh, too late +[23:32:42] <jrand0m> heh +[23:32:48] <human> heheh +[23:32:56] <jrand0m> ok anything else? we're at the 92 minute mark +[23:33:05] * jrand0m winds up... +[23:33:20] * jrand0m *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/82.rst b/i2p2www/meetings/logs/82.rst new file mode 100644 index 00000000..474e9db4 --- /dev/null +++ b/i2p2www/meetings/logs/82.rst @@ -0,0 +1,7 @@ +I2P dev meeting, March 23, 2004 @ 13:00 PST +=========================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/9.log b/i2p2www/meetings/logs/9.log new file mode 100644 index 00000000..16dc75c3 --- /dev/null +++ b/i2p2www/meetings/logs/9.log @@ -0,0 +1,89 @@ +--- Log opened Wed Aug 21 00:58:22 2002 +00:58 <@mids> test +01:00 <@mids> Hi folk(s) +01:00 <@mids> nop & userx wont be here, and I dont have much to say +01:00 <@mids> so lets just have an informal chit chat +01:00 <@mids> with lots of questions and user feedback (yeah) +01:01 -!- mids changed the topic of #iip-dev to: No formal meeting, but be welcome and chat. logs: http://mids.student.utwente.nl/~mids/iip/ +01:02 <@mids> on the freenet-devl mailinglist there has been a discussion about leaving OPN (irc.openprojects.net) and some suggested that IIP could be an alternative +01:03 <@mids> Ian Clarke countered that IIP isn't subjected to any peer review by experts +01:03 <@mids> and that it might be dangerous to think that this network is anonymous +01:04 <@mids> he has a good point there, currently we are beeing reviewed by some guys, only info that I have is this url: +01:04 <@mids> http://www.cypherpunks.to/ip/ +01:04 <@mids> . +01:05 <@mids> I hope that everybody realizes that IIP isn't bugfree, and that the anonimity factor can be quite relative +01:06 <@mids> but this shouldn't stop us from using it, catching bugs and making improvements +01:06 <@mids> . +01:06 < thecrypto> true anomimity is possible, it's just really hard +01:07 < hobbs> no, actually, I'm pretty sure it's the other way around. true anonymity is impossible, but you can make it "really hard" for whoever wants to find out. +01:08 < hobbs> off to eat. be back asap. :) +01:08 <@mids> appart from the cryptography algorithms, IIP does depend on the amount of public relays to 'hide' the users. with only a few it can be relativly easy for big organisations with lots of power to systimatically track every user down +01:08 <@mids> thanks for dropping by hobbs +01:08 < thecrypto> chaum proved it in his paper on dining cryptographer's, however setting up a DC-net for this would be a huge feat +01:09 <@mids> but what if all philosophers but 1 are working together? +01:10 < thecrypto> yes, that is a weakness there +01:10 <@mids> so, we need more public relays and more peer reviews :) +01:11 <@mids> if you happen to be a security / cryptography expert, dont hesitate to examine IIP +01:11 <@mids> . +01:12 <@mids> I have taken a look at SILC (http://www.silcnet.org) +01:12 <@mids> it is a chat client and server system with embedded cryptography +01:12 <@mids> you can put keys on channels and private conversations +01:13 < thecrypto> i'm not an expert, just a student who reads alot about this topic :) +01:13 <@mids> it cant be compared with IIP, since it doesn't offer (an attempt) to anonymity +01:13 <@mids> but it is quite interesting, maybe you (readers of the logfile) should take a look at it +01:14 <@mids> I have been trying to run it over IIP, so you will get both channel crypto and anonymity +01:14 <@mids> but I had little problems setting up the network for IIP version 1.1 +01:14 <@mids> once nop / userx respond with some hints how to do it, I'll put a test server behind IIP... as a proof of concept +01:15 <@mids> . +01:15 * mids throws the mike in the audience +01:18 < thecrypto> doesn't IIP already have end-to-end encryption? +01:18 <@mids> server-end +01:18 <@mids> the server is a patched ircd, and gets all the text plaintext from the server-side IIP node +01:18 <@mids> so an Evil Serveradmin could log all the private and channel conversations +01:19 <@mids> (after patching the source ofcourse) +01:20 <@mids> but he (or she) wont get are the IP addresses of users +01:20 <@mids> . +01:20 < thecrypto> ahh, the evil admin problem. why can't we put in encryption to the server? +01:21 <@mids> because then you either have to put irc protocol level code in the local IIP nodes or use special irc clients +01:21 <@mids> the aim for IIP has been (so far) to work with normal irc clients, and I expect that it will be that way in the (near) future +01:22 <@mids> an aim is making a VIRCD (virtual irc daemon) in each IIP client relay which handles the channel / user crypto +01:22 < thecrypto> so it's on the TODO list but not there yet +01:22 <@mids> exactly +01:23 <@mids> ellison informed me that he has a demo of the new IIP and InvisibleNet website available +01:24 <@mids> it will cooked into HTML in a couple of minutes +01:24 < agril> Why doesn't /lusers work anymore? +01:25 <@mids> all /stats commands (I don't know if /lusers uses that, or if it is a native ircd command) have been disabled in the ircd +01:25 <@mids> so we dont know how many clients or hidden channels there are +01:26 <@mids> that is probably better... for evildoers it would be harder to measure the outcome of their flood/ddos attempts +01:27 <@mids> but I have to admit that I miss the nice network graphs that could be created using those stats :( +01:30 <@mids> (ellison is uploading the site right now) +01:31 <@mids> http://www.citystateinc.com/ellison/invisiblenet/ +01:31 <@mids> hurray! +01:31 < thecrypto> is there an offical TODO list anywhere? +01:32 <@mids> I know that some subprojects have TODO lists... but the main project, I dont know +01:32 <@mids> but I am sure that userx/nop have their own list +01:33 <@mids> http://help.invisiblenet.net/ chapter 1 - future plans +01:33 <@mids> that contains a few far away aims +01:33 <@mids> Neo: http://www.citystateinc.com/ellison/invisiblenet/ +01:33 < Neo> tanks +01:35 <@mids> any comments about the website? +01:36 < Neo> Oh, nope. +01:36 < Neo> Its looking great. +01:36 < Neo> iip section is just so much better than what was before. +01:37 <@mids> I totally agree +01:37 < Neo> Download, Screenshots, Documentation, Development, Contact. Good flow. +01:39 <@mids> it looks very consistent and easily adaptable +01:39 < thecrypto> good site +01:39 <@mids> any important section missing? (in the menu) +01:42 <@mids> I think we have it all covered +01:43 < pox> looks good +01:43 <@mids> under Contact there will also be a list of all the PGP keys of developers and contributors +01:45 <@mids> last point about the site: ellison will be done soon, then he'll ship it to me and nop and we will fill in the pieces +01:45 <@mids> I guess that I will make some includes using php so that information can be updated easily +01:46 * mids thinks we will have this cool website Real Soon!!! +01:46 <@mids> . +01:47 < thecrypto> a good website is the sign of a good project :) +01:47 < Neo> Great stuff. +01:48 <@mids> That was iip-dev radio with your host mids, feel free to hang around with your questions & comments +01:49 < hobbs> wow. that's pretty. +--- Log closed Wed Aug 21 01:55:36 2002 diff --git a/i2p2www/meetings/logs/9.rst b/i2p2www/meetings/logs/9.rst new file mode 100644 index 00000000..e18d0cc2 --- /dev/null +++ b/i2p2www/meetings/logs/9.rst @@ -0,0 +1,9 @@ +I2P dev meeting, August 21, 2002 +================================ + +(Courtesy of the wayback machine http://www.archive.org/) + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/90.log b/i2p2www/meetings/logs/90.log new file mode 100644 index 00000000..f7cb2e36 --- /dev/null +++ b/i2p2www/meetings/logs/90.log @@ -0,0 +1,197 @@ +14:07 < jrandom> 0) hi +14:07 < jrandom> 1) testnet status +14:07 < jrandom> 2) SAM +14:07 < jrandom> 3) roadmap updates +14:07 < jrandom> 4) MyI2P +14:07 < jrandom> 5) ??? +14:07 < jrandom> 0) hi +14:07 * jrandom waves +14:08 < Nightblade> hi +14:08 * jteitel waves back +14:08 < jar> hi +14:08 < duck> lo +14:08 < Masterboy> :P +14:08 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-May/000239.html +14:09 < jrandom> sorry if I'm a bit out of it today, sleep schedule is more out of wack than usual +14:09 < jrandom> anyway, moving on to 1) testnet status +14:10 < duck> the diversification would automatically happen with a bigger network wouldnt it? +14:10 < jrandom> yes, and/or less skewed peer selection thresholds +14:11 < jrandom> for instance, if the speed threshold were the median as opposed to the average, we'd get half as many fast peers as reliable peers +14:11 < jrandom> as opposed to the situation we have today where the speeds are heavily skewed +14:12 < Masterboy> well the network healed that's not so bad +14:12 < jrandom> yeah, it took longer than it should though, and exposed ways that it can be improved +14:13 < jteitel> did the network heal? I still cannot connect to i2p irc reliably +14:13 < jrandom> the peer profiles didn't decay fast enough, or promote new candidates efficiently +14:14 < jrandom> it did fire off a chain of secondary events as well - overloading routers that weren't capable of holding the load (due to insufficient profiling), causing some overloaded routers to run out of memory and shut down +14:15 < human> ayeee ayeee ayeee! +14:15 < jrandom> its been a progression jteitel - some of the issues we've been seeing are related to the netDb failures +14:15 < jrandom> heya human +14:15 < jteitel> Oh, OK +14:16 < _cervantes_> could not an troubled router offload tunnels to another peer? +14:16 < ugha_node> Wow, Lifetime rate: 8.87KBps sent 8.35KBps received. +14:16 < Nightblade> jteitel: I connected just now after several tries...still waiting for my /join to go through +14:16 * BrianR looks around. +14:16 < jrandom> no - a router can simply drop a tunnel though (if it shouldn't have accepted it in the first place) +14:16 < ugha_node> (And I restarted my router half an hour ago) +14:16 < BrianR> damn it. I'm late. +14:17 < BrianR> jrandom: (Thanks for arranging myi2p towards the end of the agenda) +14:17 < jrandom> ugha> yeah, y'all had to pick up the slack for those three fast ones +14:17 < jrandom> hehe :) +14:18 < duck> a nice attack it was +14:18 < ugha_node> jrandom: Obciously. +14:18 < _cervantes_> so would it not be better to be more ruthless and reject tunnels at lower threshold +14:19 < jrandom> yes cervantes - the routers right now never reject a tunnel unless they cant reach the next hop +14:19 < jrandom> we'll want to include some sort of throttling in there, perhaps based on the size of the jobQueue / avg lag, etc +14:20 < jrandom> in addition, we'll want to make sure we dont try to build too many tunnels at once, as happened when a large portion of them failed +14:20 < _cervantes_> or simply allow the user to set a threshold based on the hardware/bandwith he/she knows he has availabled +14:20 < jrandom> (due to the fast+reliable peers going offline) +14:20 < _cervantes_> at least at this stage +14:20 < jrandom> oh thats a good point - allowing people to explicitly set a max # participating tunnels. +14:21 < jrandom> we'll get that into the next rev. good call. +14:21 < ugha_node> This sounds just like fuzzy logic. +14:21 < jrandom> we've got to deal with overload, and simply queueing up messages in memory certainly doesnt work +14:21 < duck> (hi fvw) +14:21 < _cervantes_> it would be good to have some kind of coalleted stats on tunnel performance... the kind of load the might inflict on a benchmark processor(s) +14:22 < _cervantes_> btw I took my server offline....it was getting a shed load of tunnels and I haven't yet compiled jbigi ;-) +14:22 < jrandom> see http://localhost:7655/routerStats.html#Tunnels +14:23 < jrandom> ah! yeah, jbigi is something we want to encourage everyone to use +14:23 < BrianR> Any thoughts on doing bandwidth budgeting for tunnels? +14:24 < jrandom> currently slated for 3.0 (with overall bandwidth limiting for the router as a whole @ 0.4.1) +14:24 < jrandom> but having per-tunnel bandwidth limits earlier wouldnt hurt +14:25 < fvw> Is it wise to spend effort on this so early when it's much easier and more precisely done in the kernel of the OSes most of the current users/testers are running? +14:25 < _cervantes_> something I would like to see is per-tunnel depth settings (perhaps this is already possible) +14:25 < _cervantes_> for instance I already know I can trust my server....so I don't want to have to go through _x_ hops to get to it +14:25 < jrandom> fvw> thats a good point, especially since we currently don't devour too much bandwidth +14:26 < jrandom> hmm cervantes - yes, each client can specify the length of their tunnels, but i'm not sure thats exactly what you want +14:26 < _cervantes_> nope +14:26 < jrandom> cervantes - i think what you're looking for is a QoS where you can shorten the conn for one particular peer +14:26 < _cervantes_> for instance... +14:26 < _cervantes_> yep +14:27 < jrandom> (which was slated for i2p 4.0, but thats more than a year away == infinity) +14:27 < _cervantes_> in this case also select the depth per i2p host +14:27 < BrianR> fvw: Yes, but an i2p needs to know roughly how much bandwidth potential tunnel members have available in order to make wise tunnelbuilding decisions... +14:27 < _cervantes_> ah ok +14:27 < _cervantes_> :) +14:27 < jrandom> but its a good idea, and technically feasible, but patches accepted :) +14:28 < _cervantes_> the patch is already in the mail....along with that cheque for 5000 bars of e-gold +14:28 < _cervantes_> ;-) +14:28 < jrandom> BrianR: perhaps it can go halfway - keep track of how many tunnels it is participating in, as well as how much bandwidth those tunnels are using, and use that as part of the decision as to whether to accept or reject a tunnel create request? +14:28 < jrandom> heh +14:30 < jrandom> ok, anyone have anything else for the testnet status? +14:30 < Masterboy> what about my paradox? +14:30 < Masterboy> :) +14:30 < jrandom> my plan is to get a 0.3.1.3 with the updates out by thursday or friday +14:31 < jrandom> Masterboy: i havent had time to go through your logs, but we'll have it resolved +14:31 < _cervantes_> friday 2005? +14:31 < _cervantes_> cool +14:31 < Masterboy> k +14:31 < jrandom> ok, moving on to 2) SAM +14:31 < Masterboy> now we know who is running the out of date router.. +14:32 * jrandom hands the mic to our intrepid SAM.pm dev +14:33 < jrandom> (thats you BrianR :) +14:33 < BrianR> Hold a second.. :) +14:33 * duck cheers +14:33 < jrandom> in the meantime, dm or firerabbit around? +14:33 -!- Irssi: #i2p: Total of 26 nicks [0 ops, 0 halfops, 0 voices, 26 normal] +14:33 * jrandom checks the /names, nope. oh well +14:33 < jrandom> (no .net/C# sam lib updates then) +14:34 < duck> is the .py stuff still current? +14:34 < duck> or depricated by SAM improvements +14:34 < jrandom> not sure +14:34 < BrianR> Ok. I'm back. +14:34 < Nightblade> My C library appears to be working... I have not written an application to use it yet though +14:34 < jrandom> awesome nightblade! +14:35 < Nightblade> Has anyone here done GTK+/C programming under Windows? +14:35 < human> duck: the client lib needs a small change for versioning support +14:35 < _cervantes_> "hello world"? +14:35 < human> duck: the rest should work without problems +14:35 * jrandom suggests a datagram like tftp as the ideal sam test :) +14:35 < Nightblade> well, anything really... does GTK work well under windows.....? +14:35 < jrandom> (or even SAM streaming instead of datagram or raw) +14:36 < jrandom> cool BrianR - how goes the .pm and the samcat? +14:36 < BrianR> Net::SAM is in the CVS in mostly non-working form. +14:36 < BrianR> I hope to have all of the bugs ironed and datagram and raw working before week end. +14:37 < BrianR> A bit more work will be required to put a nice OO finish on streams. +14:37 < Nightblade> oh yeah, i didn't bother with datagram or raw... just stream +14:37 < Nightblade> but that is all i would use anyway +14:37 < fvw> human: Have you considered wxWindows? It's quite useful for that kind of stuff (don't think there's a windows GTK target though) +14:37 < jrandom> awesome BrianR +14:38 < BrianR> Wife is bugging me to join her for dinner. I may or may not be back in time for myi2p discussion. I've posted the threat model and stuff dumb fileserver stuff on node 208 +14:38 < human> fvw: the GTK windows client does exist (The GIMP runs on windows, too) +14:38 < jrandom> cool nightblade, its best to implement whats needed first +14:38 < human> fvw: s/client/port/ +14:38 < jrandom> heh 'k BrianR, thanks +14:38 < fvw> human: I mean gtk windows target for wxWindows (which I was suggesting you use) +14:38 * fvw waves to BrianR. Bon Appetite. +14:38 < human> fvw: ah... well, i don't know about vxWidgets (vxWindows' new name :-) +14:39 < human> fvw: but it was Nightblade speaking about GTK+, not me :-) +14:40 < fvw> Oops, my eyes are crooked, ignore me. +14:40 < Nightblade> I'm not as familiar with C++ as I am C +14:40 < Nightblade> afaik GTK is the only cross-platform C GUI library +14:40 < Nightblade> not that i am particularly fond of GTK +14:40 < fvw> doesn't really matter, wxWindows is easily approachable from C. +14:40 < Nightblade> hmm +14:40 < Nightblade> well maybe i'll take a look at it too +14:40 < Nightblade> i know C++ but I haven't written any major programs in it +14:41 * fvw isn't a C++ coder either, but I set up a fairly large transaction viewer for a transport company in it a while back without troubles. +14:42 < Nightblade> i am sure wxwindows has a more mature windows port +14:42 < Nightblade> than gtk +14:42 < fvw> quite probably yeah. +14:43 < Nightblade> (ok continue meeting) heh +14:43 < jrandom> :) +14:43 < jrandom> ok, jumping to 3) roadmap updates +14:44 * jrandom has been negligent updating http://www.i2p.net/roadmap over the last month +14:44 < jrandom> but now its back up to current +14:44 < jrandom> unfortunately we're obviously not getting 0.4 in next week +14:44 < duck> (are 1.1, 2.0, 3.0 also up2date?) +14:45 < jrandom> yessir +14:45 * Masterboy read it liked it - no rush we are not on fire.. +14:46 < duck> someone should update wikipedia/infoanarchy too :) +14:46 < jrandom> oh, i should probably remove the "SAM bridge and client libraries implemented and tested" from 0.4 +14:46 < jrandom> heh yeah, thats why i !thwapped iA a while back when they just copied the wiki page +14:46 < jrandom> (they should just point to the /roadmap, not duplicate the content) +14:47 < Masterboy> SAM is finished? +14:47 < jrandom> its functional yes, though work on additional client libraries are ongoing +14:47 < jrandom> s/are/is/ +14:48 < jrandom> ok, unless there are any more roadmap questions/concerns, moving on to 4) MyI2P +14:50 < jrandom> while i've stopped working on myi2p myself, we've opened up the effort to a bounty - http://www.i2p.net/node/view/216 +14:50 < jrandom> part of that means we need to get the requirements right, and there has been some debate about what those should be +14:51 < Masterboy> tried to get in it my friend he said too mutch work too little money;P well he is a capitalist;) +14:51 < Masterboy> well i offered to code it.. +14:52 < jrandom> coding on it is always wanted :) +14:53 < jrandom> the current outstanding architectural question though is how to deal with people who cannot run their i2p router / myi2p node all the time +14:53 < Nightblade> just have to have some trusted i2p isp +14:53 < jrandom> the two proposals are either to use hosted service providers, or to split off the system to use a distributed backing store +14:54 < _cervantes_> the later being the long term ideal solution +14:54 < _cervantes_> *latter +14:54 < duck> (and being another bounty) +14:55 < _cervantes_> or a webcache proxy service... +14:55 < jrandom> right - if we went the hosted service provider (or locally run node), when a DHT/etc were available we could push more and more of the content into the DHT +14:55 < jrandom> _cervantes_: thats essentially the distributed backing store - untrusted data caches +14:57 < deer> * Masterboy wonders where is bogobot +14:57 < jrandom> the hard part is to get the access control functionality needed - with untrusted data caches / distributed backing store, ACLs are essentially encryption +14:57 < jrandom> but a "side channel" to this discussion comes from the three points raised by an anonymous person @ http://www.i2p.net/node/view/215#comment-105 +14:57 < _cervantes_> and signed content +14:58 < jrandom> right, both ways will need to have signed content +15:00 < _cervantes_> this is where hypercubus' model has merit...but it's by no means "quick" solution +15:00 < jrandom> from the discussions on irc last night, we focused on the "livejournal threat model" - what attacks LJ users care about, and what they dont +15:01 < wilde> first things first, getting a basic MyI2P in first place +15:02 < jrandom> right, and to get the basic myi2p implemented, we've got to know the deployment architecture +15:03 < jrandom> with the lj threat model for users who cannot run their own nodes, i dont think we need to go the untrusted data cache route +15:03 < jrandom> and why would someone use myi2p if they merely need lj's threat model? because its anonymous +15:04 < jrandom> we could go on for some idealized system, but there is the law of diminishing returns +15:04 -!- Irssi: #i2p: Total of 24 nicks [0 ops, 0 halfops, 0 voices, 24 normal] +15:05 < jrandom> which is why i'm leaning towards keeping the bounty along the current lines - we can add on alternatives later, after the basic system is out +15:05 -!- duck_ is now known as duck +15:06 < jrandom> anyway, i think thats all i've got for 4) MyI2P, unless someone has anything else they'd like to bring up +15:06 < jrandom> if not, moving on to 5) ??? +15:07 < _cervantes_> hmm you need a large gavel :) +15:07 < jrandom> i forgot to mention morph.i2p's new eepsite in the meeting notes, and nickster.i2p now has a public fproxy available! +15:08 < jrandom> (and sungo.i2p has his webcam up and running :) +15:08 < _cervantes_> heh... +15:08 < _cervantes_> i2pr0n +15:08 < jrandom> anyone else have anything they want to bring up? +15:10 < jrandom> if not, that'll put us at the 70 minute mark +15:10 < deer> <Masterboy> no +15:10 * jrandom winds up +15:10 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/90.rst b/i2p2www/meetings/logs/90.rst new file mode 100644 index 00000000..f5caf6b7 --- /dev/null +++ b/i2p2www/meetings/logs/90.rst @@ -0,0 +1,7 @@ +I2P dev meeting, May 18, 2004 @ 14:00 PDT +========================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/92.log b/i2p2www/meetings/logs/92.log new file mode 100644 index 00000000..a7831ff0 --- /dev/null +++ b/i2p2www/meetings/logs/92.log @@ -0,0 +1,336 @@ +[22:59] <duck> Tue Jun 1 21:00:00 UTC 2004 +[23:00] <duck> hi folks! +[23:00] <mihi> hi duck +[23:00] <duck> http://dev.i2p.net/pipermail/i2p/2004-June/000250.html +[23:00] <duck> my proposal: +[23:00] * Masterboy has joined #i2p + +[23:00] <duck> 1) code progress +[23:00] <duck> 2) featured content +[23:00] <duck> 3) testnet status +[23:00] <duck> 4) bounties +[23:00] <duck> 5) ??? +[23:00] <Masterboy> hi:) +[23:00] <duck> . +[23:01] <duck> since jrandom is off we'll have to do it ourself +[23:01] <duck> (I know that he is logging and verifying our independency) +[23:01] <Masterboy> no problem:P +[23:02] <duck> unless there are problems with the agenda I propose that we stick to it +[23:02] <duck> though there aint much that I can do if you dont :) +[23:02] <duck> . +[23:02] <mihi> ;) +[23:02] <duck> 1) code progress +[23:02] <duck> not much code submitted to cvs +[23:02] <duck> I did win the trophy this week: http://duck.i2p/duck_trophy.jpg +[23:03] * hypercubus has no cvs account yet +[23:03] <Masterboy> and who did submit something? +[23:03] <duck> anybody doing any secret coding? +[23:03] * Nightblade has joined #I2P + +[23:03] <hypercubus> BrianR was working on some stuff +[23:04] <hypercubus> i've got maybe 20% of the 0.4 installer hacked out +[23:04] <duck> hypercubus: if you have stuff then provide diffs and $dev will commit for you +[23:04] <duck> ofcourse the strict license agreements apply +[23:05] <duck> hypercubus: cool, any issues / things worth mentioning? +[23:06] <hypercubus> not yet, but i'll probably need a couple of BSD people to test the preinstaller shell scripts +[23:06] * duck turns some stones +[23:06] <Nightblade> is it text-only +[23:07] <mihi> duck: which one is you on duck_trophy.jpg? +[23:07] <mihi> ;) +[23:07] <Nightblade> luckypunk has freebsd, also my isp has freebsd but their config is kind of screwed up +[23:07] <Nightblade> my web host isp that is, not comcast +[23:08] <duck> mihi: left one with the glasses. wilde is the right guy handing me the trophy +[23:08] * wilde waves +[23:08] <hypercubus> you have a choice... if you have java installed, you can skip the preinstaller altogether... + if you don't have java installed you can run the linux binary or win32 binary preinstaller (console mode), or a + generic *nix script preinstaller (console mode) +[23:08] <hypercubus> the main installer gives you the choice of using console mode or spiffy GUI mode +[23:08] <Masterboy> i will install freebsd soon so in the future i will give a try to the installer too +[23:09] <hypercubus> ok good... didn't know if anyone else besides jrandom was using it +[23:09] <Nightblade> freebsd java is invoked as "javavm" rather than "java" +[23:09] <hypercubus> as built from sun sources? +[23:09] <mihi> freebsd supports symlinks ;) +[23:10] <hypercubus> anyhow the binary preinstaller is 100% complete +[23:10] <hypercubus> compiles with gcj to native +[23:11] <hypercubus> it just asks you for the install dir, and it grabs a JRE for you +[23:11] <duck> w00t +[23:11] <Nightblade> cool +[23:11] <hypercubus> jrandom's packaging a custom JRE for i2p + +[23:12] <deer> <j> . +[23:12] <Nightblade> if you install java from the freebsd ports collection you use some wrapper script called + javavm +[23:12] <deer> <r> . +[23:12] <hypercubus> anyhow this puppy will be almost completely automated +[23:12] <deer> <r> . +[23:12] <deer> <r> . +[23:12] <deer> <r> . +[23:12] <deer> <duck> r: cut it +[23:12] <deer> <r> . +[23:12] <deer> <m> . +[23:13] <deer> <m> stoopid irc server, does not support pipelining :( +[23:13] <duck> hypercubus: got any ETA for us? +[23:14] <deer> <m> oops, the problem is "Nick change too fast" :( +[23:14] <hypercubus> i still expect to be finished in under a month, before 0.4 is ripe for release +[23:14] <hypercubus> though at present i'm compiling a new OS for my dev system, so it'll be a couple of days + before i get back to the installer ;-) +[23:14] <hypercubus> no worries though +[23:15] <duck> ok. so more news next week :) +[23:15] <duck> any other coding done? +[23:15] <hypercubus> hopefully... unless the power company screws me again +[23:16] * duck moves to #2 +[23:16] <duck> * 2) featured content +[23:16] <duck> lots of streaming audio (ogg/vorbis) done this week +[23:16] <duck> baffled is running his egoplay stream and I am running a stream too +[23:16] <Masterboy> and it works quite good +[23:17] <duck> on our site you can get info how to use it +[23:17] <hypercubus> got any rough stats for us? +[23:17] <duck> if you use a player not listed there and figure out how to use it, please send them to me and I'll + add +[23:17] <Masterboy> duck where is the link to baffleds stream on your site? +[23:17] <Masterboy> :P +[23:17] <duck> hypercubus: 4kB/s goes pretty well +[23:18] <duck> and with ogg it aint tooooo bad +[23:18] <hypercubus> but that still seems to be the avg. speed? +[23:18] <duck> my observation is that is the max +[23:18] <duck> but it is all config tweaking +[23:19] <hypercubus> any idea why that seems to be the max? +[23:19] <hypercubus> and i'm not just talking streaming here +[23:19] <hypercubus> but downloads too +[23:20] <Nightblade> i was downloading some big files yesterday (a couple megabytes) off of duck's hosting + service and i was getting about 4kb-5kb as well +[23:20] <duck> I think that it is the rtt +[23:20] <Nightblade> those Chips movies +[23:20] <hypercubus> 4-5 seems an improvement over the ~3 that i've gotten consistently since i started using i2p + +[23:20] <Masterboy> 4-5kb is not bad.. +[23:20] <duck> with a windowsize of 1 you dont get much faster.. +[23:20] <duck> windowsize >1 bounty: http://www.i2p.net/node/view/224 +[23:21] <duck> mihi: maybe you can comment? +[23:21] <hypercubus> but it is a remarkably consistent 3 kbps +[23:21] <mihi> on what? windowsize>1 with ministreaming: you are a wizard if you manage that ;) +[23:21] <hypercubus> no hiccups on the bandwidth meter... a fairly smooth line +[23:21] <duck> mihi: on why it is so stable at 4kb/s +[23:21] <mihi> no idea. i don't hear any sound :( +[23:22] <duck> mihi: for all i2ptunnel transfers +[23:22] <Masterboy> mihi you need to config the ogg streaming plugin.. +[23:22] <mihi> Masterboy:? +[23:23] <mihi> no, there is no limit inside i2ptunnel regarding speed. it must be in the router... +[23:23] <duck> my thinking: max packet size: 32kB, 5 second rtt: 32kB/5s =~ 6.5kb/s +[23:24] <hypercubus> sounds plausible +[23:25] <duck> ok.. +[23:25] <duck> other content: +[23:25] * hirvox has joined #i2p + +[23:25] <duck> there is a new eepsite from Naughtious +[23:25] <duck> anonynanny.i2p +[23:25] <duck> key is commited to cvs and he did put it on ugha's wiki +[23:25] * mihi is hearing "sitting in the ..." - duck++ +[23:25] <Nightblade> see if you can open two or three streams at a 4kb speed then you will be able to tell if it + is in the router or the streaming lib +[23:26] <duck> Naughtious: you there? tell something about your plan :) +[23:26] <Masterboy> i have read that he provides hosting +[23:26] <duck> Nightblade: I did try 3 parallel downloads from baffled and I got 3-4kB each +[23:26] <Nightblade> i c +[23:27] <mihi> Nightblade: how can you tell that then? +[23:27] * mihi likes listening in "stop&go" mode ;) +[23:27] <Nightblade> well if there is some kind of limitation in the router that only lets it handle 4kb at once +[23:27] <Nightblade> or if it is something else +[23:28] <hypercubus> can someone explain this anonynanny site? i don't have a running i2p router atm +[23:28] <mihi> hypercubus: just a wiki or some sort of it +[23:28] <duck> plone CMS setup, open account creation +[23:28] <duck> allows file upload and website stuff +[23:28] <duck> through web interface +[23:28] <Nightblade> another thing to do would be to test the throughput of the "repliable datagram" which afaik + is the same as the streams but without acks +[23:28] <duck> likely a lot like drupal +[23:28] <hypercubus> yeah i've run plone before +[23:29] <duck> Nightblade: I have been thinking about using airhook to manage those +[23:29] <duck> but so far only some basic thought +[23:29] <hypercubus> anything goes for the wiki content, or does it center on something in particular? +[23:29] <Nightblade> i think airhook is GPLed +[23:29] <duck> the protocol +[23:29] <duck> not the code +[23:29] <Nightblade> ah :) +[23:30] <duck> hypercubus: he wants quality content, and lets you provide that :) +[23:30] <Masterboy> upload the best pr0n of yourself you have got hyper;P +[23:30] <duck> ok +[23:30] * Masterboy will try to do that too +[23:30] <hypercubus> yeah, anyone running an open wiki is just asking for quality content ;-) +[23:31] <duck> ok +[23:31] * duck moves to #3 +[23:31] <duck> * 3) testnet status +[23:31] <Nightblade> Airhook gracefully handles intermittent, unreliable, or delayed networks <-- hehe not an + optimistic description of I2P! +[23:31] <duck> how has it been going? +[23:32] <duck> lets put the datagram over i2p discussion to the end +[23:32] <tessier> I love to run around to open wiki's and link to this: http://www.fissure.org/humour/pics/squirre + l.jpg +[23:32] <tessier> airhook rocks +[23:32] <tessier> I've been looking at it for building a p2p network also. +[23:32] <Nightblade> it seems to be reliable to me (#3) +[23:32] <Nightblade> best i've seen so far +[23:33] <duck> yeah +[23:33] <mihi> works well - at least for stop&go audio streaming +[23:33] <duck> I see quite impressive uptimes on irc +[23:33] <hypercubus> agreed... seeing lots more blue guys in my router console +[23:33] <Nightblade> mihi: are you listening to techno ? :) +[23:33] <duck> but hard to tell since bogobot doesnt seem to handle connections that go over 00:00 +[23:33] <tessier> audio streaming works great for me but loading websites often takes a number of tries +[23:33] <Masterboy> i have an opinion that i2p runs very good after 6 hours of use in the 6th hour i used the irc + for 7 hours and so my router was running for 13hours +[23:33] <duck> (*hint*) +[23:34] <hypercubus> duck: er... heheh +[23:34] <hypercubus> i could fix that i guess +[23:34] <hypercubus> do you have the logging set for daily? +[23:34] <duck> hypercubus++ +[23:34] <hypercubus> log rotation that is +[23:34] <duck> oh yes +[23:34] <duck> duck-- +[23:34] <hypercubus> that's why +[23:34] <Nightblade> I was at work all day and turned on my computer and started i2p and was on duck's irc server + in just a few minutes +[23:35] <duck> I have been seeing some weird DNFs +[23:35] <duck> even when connecting to my own eepsites +[23:35] <duck> (http://dev.i2p.net/bugzilla/show_bug.cgi?id=74) +[23:35] <duck> I think that is what causes most problems now +[23:35] <hypercubus> bogoparser will only analyze uptimes that occur wholly within a single logfile... so if the + logfile encompasses only 24 hours, nobody will show up as connected longer than 24 hours +[23:35] <duck> Masterboy and ughabugha did also have it I think... +[23:36] <Masterboy> yup +[23:36] <duck> (fix it and you will win next weeks trophy for sure!) +[23:37] <deer> <mihi> bogobot is excited? ;) +[23:37] <Masterboy> i tried my web site and sometimes when i hit refresh it takes the other route? and i have to + wait for it to load but i never wait;P i hit it again and it shows instantly +[23:37] <deer> <mihi> oops, sry. forgot that this is gated... +[23:38] <duck> Masterboy: do the timeouts take 61 seconds? +[23:39] <duck> mihi: bogobot set to weekly rotations now +[23:39] * mihi has quit IRC ("bye, and have a nice meeting") +[23:40] <Masterboy> sorry i didn't check it on my web site when i can't reatch it instantly i just hit refresh + and it loads instantly.. +[23:40] <duck> hm +[23:40] <duck> well, it needs to be fixed +[23:41] <duck> .... #4 +[23:41] <Masterboy> i think the route is given not the same eatch time +[23:41] <duck> * 4) bounties +[23:41] <duck> Masterboy: local connections should be cutted short +[23:42] <duck> wilde had some bounty thoughts... you there? +[23:42] <Masterboy> maybe it is a peer selection bug +[23:42] <wilde> I'm not sure that was for the agenda really +[23:42] <duck> oh +[23:42] <wilde> ok but the thoughts were something like: +[23:42] <Masterboy> i think then we go public the bounty system will work better +[23:43] <Nightblade> masterboy: yes there are two tunnels for each connection, or that is how i understand it + from reading the router.config +[23:43] <wilde> we could use this month to do some small advertising of i2p and increase the bounty pool a bit +[23:43] <Masterboy> i can see that the Mute project is going good - they got 600$ and they didn't code a lot yet;P +[23:44] <wilde> target against freedom communities, crypto people, etc +[23:44] <Nightblade> I don't think jrandom wants advertising +[23:44] <wilde> not public slashdot attention, no +[23:44] <hypercubus> that's what i've observed as well +[23:44] <Masterboy> i want to push it again - when we go public the system will work a lot better;P +[23:45] <wilde> Masterboy: bounties could speed up myi2p development for example +[23:45] <Masterboy> and as jr said no public till 1.0 and only some attention after 0.4 +[23:45] <Masterboy> *wrote +[23:45] <wilde> when we have like $500+ for a bounty people could actually survive for some weeks +[23:46] <hypercubus> the tricky part is, even if we target a small dev community, like *cough* Mute devs, those + guys might spread the word about i2p further than we'd like +[23:46] <Nightblade> someone could make a career out of fixing i2p bugs +[23:46] <hypercubus> and too soon +[23:46] <wilde> i2p links are already in many public places +[23:46] <Masterboy> you google and you can find i2p + +[23:47] <hypercubus> obscure public places ;-) (i saw the i2p link on a freesite... i'm lucky the damn freesite + even loaded!) +[23:47] <wilde> http://en.wikipedia.org/wiki/I2p +[23:47] <Masterboy> but i agree that no advertising till 0.4 is done +[23:47] <Masterboy> wha??????? +[23:47] <wilde> http://www.ovmj.org/GNUnet/links.php3?xlang=English +[23:48] <Masterboy> protol0l does a great job;P +[23:48] <Masterboy> ;)))))) +[23:48] <hypercubus> nice typo ;-) +[23:48] <wilde> ok anyway, I agree we should still keep I2P private (jr read this log ;) +[23:49] <Masterboy> who did that? +[23:49] <Masterboy> i think the Freenet crew discussion gave more attention.. +[23:50] <Masterboy> and jr discussing with toad give a lot info to the big public.. +[23:50] <Masterboy> so as in ughas wiki - we can all blame jr for that;P +[23:50] <wilde> ok anyway, we'll see if we can bring in some $ without bringing in /. +[23:50] <Masterboy> agreed +[23:50] <hypercubus> the freenet dev list is hardly what i call the "big public" ;-) +[23:50] <wilde> . +[23:51] <hypercubus> wilde: you'll have a lot of $ sooner than you think ;-) +[23:51] <wilde> oh come on, even my mum subscribe to freenet-devl +[23:51] <duck> my mum reads through gmame +[23:51] <deer> <clayboy> freenet-devl is being taught in schools here +[23:52] <wilde> . +[23:52] <Masterboy> so we will see more bounties after we go 0.4 stable.. +[23:53] <Masterboy> that is after 2 months;P +[23:53] <wilde> where did that duck go? +[23:53] <duck> thanks wilde +[23:53] <hypercubus> though as the only bounty claimant thus far, i have to say that the bounty money had no + bearing on my decision to take up the challenge +[23:54] <wilde> hehe, it would if it been 100x +[23:54] <duck> wyou are too good for the world +[23:54] <Nightblade> haha +[23:54] * duck moves to #5 +[23:54] <hypercubus> wilde, $100 doesn't mean shit to me ;-) +[23:54] <duck> 100 * 10 = 1000 +[23:55] * duck pops("5 airhook") +[23:55] <duck> tessier: got any real-world experience with it +[23:55] <duck> (http://www.airhook.org/) +[23:55] * Masterboy will try dis out:P +[23:56] <duck> java implementation (dunno if it even works) http://cvs.ofb.net/airhook-j/ +[23:56] <duck> python implementation (a mess, did work in the past) http://cvs.sourceforge.net/viewcvs.py/khashmir + /khashmir/airhook.py +[23:58] * duck opens the rant-valve +[23:58] <Nightblade> j one is also gpl +[23:58] <duck> port it to pubdomain +[23:58] <hypercubus> amen +[23:58] <Nightblade> the entire protocol doc is only about 3 pages - it can't be that hard +[23:59] <Masterboy> nothing is hard +[23:59] <Masterboy> it's just not easy +[23:59] <duck> I dont think that it is fully specced though +[23:59] * hypercubus takes away masterboy's fortune cookies +[23:59] <duck> you might need to dive into the C code for a reference implementation +[00:00] <Nightblade> I would do it myself but I am busy with other i2p stuff right now +[00:00] <Nightblade> (and also my full-time job) +[00:00] <hypercubus> duck: maybe a bounty for it? +[00:00] <Nightblade> there already is +[00:00] <Masterboy> ? +[00:00] <Masterboy> ahh Pseudonyms +[00:00] <duck> it could be used at 2 levels +[00:00] <duck> 1) as a transport besides TCP +[00:01] <duck> 2) as a protocol to handle datagrams inside i2cp/sam +[00:01] <hypercubus> that's worth serious consideration then +[00:01] <hypercubus> </obvious> + +[00:02] <Nightblade> duck: i noticed that the repliable datagram in SAM has a maximum size of 31kb, whereas the + stream has a maximum size of 32kb - making me think that the sender's destination is sent with each packet in + repliable datagram mode, and only at the beginning for a stream mode - +[00:02] <Masterboy> well airhook cvs is not very updated.. +[00:03] <Nightblade> making me think that it would be inefficient to make a protocol on top of the repliable + datagrams through sam +[00:03] <duck> airhooks message size is 256 bytes, i2cp's is 32kb, so you need to atleast change a bit +[00:04] <Nightblade> actually if you wanted to do the protocol in SAM you could just use the anoymous datagram + and have the first packet contain the sender's destination.... blah blah blah - i have lots of ideas but not + enough time to code them +[00:06] <duck> then again you have to problems to verify signatures +[00:06] <duck> so someone could send fake packages to you +[00:06] <Masterboy> topic:::: SAM +[00:06] <Masterboy> ;P +[00:07] <Nightblade> true +[00:08] <Nightblade> but if you sent back to that destination and there was no acknowledgement you'd know it was + a faker +[00:08] <Nightblade> there woudl have to be a handshake +[00:08] <duck> but you'll need aapplication level handshakes for that +[00:08] <Nightblade> no not really +[00:09] <Nightblade> just put it in a library for accessing SAM +[00:09] <Nightblade> that is a bad way of doing though +[00:09] <Nightblade> doing it though +[00:09] <duck> you could also use seperated tunnels +[00:09] <Nightblade> it shuold be in the streaming lib +[00:11] <duck> yup. makes sense +[00:12] <duck> ok +[00:12] <duck> I am feeling *baff*-y +[00:13] <Nightblade> ja +[00:13] * duck *baffs* diff --git a/i2p2www/meetings/logs/92.rst b/i2p2www/meetings/logs/92.rst new file mode 100644 index 00000000..75d1b227 --- /dev/null +++ b/i2p2www/meetings/logs/92.rst @@ -0,0 +1,7 @@ +I2P dev meeting, June 1, 2004 @ 21:00 UTC +========================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/93.log b/i2p2www/meetings/logs/93.log new file mode 100644 index 00000000..772771dc --- /dev/null +++ b/i2p2www/meetings/logs/93.log @@ -0,0 +1,275 @@ +21:02:08 <duck> Tue Jun 8 21:02:08 UTC 2004 +21:02:21 <duck> meeting time +21:02:33 <duck> writeup is at http://dev.i2p.net/pipermail/i2p/2004-June/000268.html +21:02:39 <duck> but I did make a mistake in the numbering +21:02:45 <duck> so the first item 5 will be skipped +21:02:53 <hypercubus> yay! +21:03:03 * duck puts some ice in his beer +21:03:14 * mihi 'd rename first #5 to #4 ;) +21:03:27 <hypercubus> nah, let's just have two item 4's next week ;-) +21:03:37 * duck renames 'hypercubus' to 'mihi' +21:03:48 <hypercubus> yay! +21:03:49 <duck> ok +21:03:53 <duck> * 1) libsam +21:04:02 <duck> is there a Nightblade in the channel? +21:04:39 <duck> (idle : 0 days 0 hours 0 mins 58 secs) +21:05:03 <hypercubus> ;-) +21:05:53 * duck reclaims the microphone +21:06:15 <duck> Nightblade wrote a SAM lib for C / C++ +21:06:23 <duck> it compiles for me.. but that is all I can say :) +21:06:37 <mihi> no test cases? ;) +21:07:06 <duck> if there are any rFfreebsd users Nightblade might be interested in you +21:07:08 <ugha_node> The strstr calls really annoyed me in the code. ;) +21:07:27 <ugha_node> duck: What's a rFfreebsd? +21:07:42 <duck> how I did type freebsd +21:08:00 <mihi> rm -rF freebsd? +21:08:29 <ugha_node> Too bad -F doesn't work with rm. +21:08:30 <duck> ugha_node: its bsd licensed; so fix it +21:08:41 <fvw> sounds sane to me :). Alas I uninstalled my last freebsd box a while back. I + have accounts on other peoples' boxes though, and am willing to run testcases. +21:08:43 <ugha_node> duck: I might. :) +21:08:50 <duck> (damn BSD hippies) +21:09:09 <duck> oh, nice and short frank +21:09:17 <duck> mo libsam comments? +21:09:49 <duck> fvw: I guess Nightblade will contact you if he has a need +21:09:50 * fvw grumbles at perfectly sane unix behaviour for killing his irc client. +21:10:02 <duck> but since his email was a week old be might have found something +21:10:17 <mihi> fvw: ? +21:10:24 <fvw> yeah, if someone wanted to take me up on my offer I sort of missed that. Feel + free to send email or something. +21:10:42 * duck hops to #2 +21:10:46 <hypercubus> uhm, to where? ;-) +21:10:54 <duck> 2) browse i2p and normal web with one browser +21:10:57 <fvw> fresh install, haven't yet told my zsh not to hup stuff in the bacgrkground. + </offtopic> + +21:11:09 <fvw> hypercubus: I'm on the public mailinglist user list I think. fvw.i2p@var.cx +21:12:11 <duck> there was some stuff about adding all TLDs to your brower proxy ignore list +21:12:23 <fvw> does that require discussion? I think it was pretty much handled on the + mailinglist. +21:12:24 <duck> I think it is a dirty hack +21:12:36 <fvw> yes, that was mentioned. Welcome back. +21:12:47 <duck> fvw: I didnt read the thread :) +21:13:12 <duck> okay, if you dont want to discuss it, move to #3 +21:13:19 <duck> * 3) chat channel +21:13:23 <hypercubus> cervantes' script works perfectly on Konqueror 3.2.2, Firefox 0.8, and + Opera 7.51, all for Gentoo w/KDE 3.2.2 +21:13:39 * mihi places a flag on #4 +21:13:55 <duck> #i2p-chat is an alternative channel here for offtopic chat and light support +21:14:08 <duck> I dont know who did regg it +21:14:12 <hypercubus> i did +21:14:17 <duck> so better be careful :) +21:14:22 <fvw> ehm, there is no #4, just two #5's :) +21:14:33 <hypercubus> i'll be lucky if i can remember the password when i need it ;-) +21:14:33 <mihi> [22:27] -ChanServ- Channel: #i2p-chat +21:14:33 <mihi> [22:27] -ChanServ- Contact: hypercubus <<ONLINE >> + +21:14:33 <mihi> [22:27] -ChanServ- Alternate: cervantes <<ONLINE >> +21:14:37 <mihi> [22:27] -ChanServ- Registered: 4 days (0h 2m 41s) ago +21:15:12 <hypercubus> i gave a few trusted peeps op powers for whenver i'm not around and + there's trouble +21:15:24 <duck> sounds good +21:15:39 <duck> it might be a bit overkill +21:15:51 <hypercubus> you never know on IRC ;-) +21:15:55 <duck> but after this protogirl did join here I thought it would be good to clean up + this chan +21:16:03 <hypercubus> heh +21:16:27 <hypercubus> we'll need it for sure sometime in the next few months anyhow +21:16:34 <duck> jups +21:16:48 <duck> and then the freenode ppl will kick us out +21:16:55 <hypercubus> ;-) +21:17:13 <duck> they dont like anything that isnt written in their kampf +21:17:16 <duck> err +21:17:44 * duck moves to $nextitem and triggers mihi's breakpoint +21:17:47 <hypercubus> i figured tying the new channel in with support would legitimize it for + freenode +21:18:47 <duck> hypercubus: you might be surprised +21:19:04 <hypercubus> *cough* i admittedly didn't read all the policies... +21:19:24 <duck> it is russian roullete +21:19:39 <hypercubus> hmm, didn't think it would be quite that dire +21:19:52 * duck is being negative +21:19:54 <hypercubus> well i'll look into what we can do +21:20:09 <fvw> sorry, I must have missed something. Why would freenode kick us off? +21:20:21 * duck looks at the timeout counter for mihi's breakpoint +21:20:32 <duck> fvw: they focus on development channels +21:20:35 <mihi> ? +21:20:53 <mihi> duck: the breakpoint triggers on /^4).*/ +21:21:01 <duck> mihi: but there is no #4 +21:21:06 <fvw> so? i2p is soo alpha that right now even support is development. +21:21:11 <fvw> (and no, you may not quote me on that) +21:21:36 <duck> fvw: you might not be familiar with the types of discussion that did happen + on IIP +21:21:38 <hypercubus> yeah but we have *2* channels for it +21:21:45 <duck> and which will likely happen in #i2p channels +21:22:04 <duck> I am pretty sure that freenode does not appreciate it. +21:22:10 <Nightblade> i'm here now +21:22:49 <hypercubus> we'll donate a margarita machine to them or something +21:22:49 <mihi> duck: what do you refer to? the floods? or #cl? or what? +21:23:08 <fvw> discussions on IIP or discussions on #iip? I've never seen anything apart from + devel and support on #iip. And discussions on IIP would move to I2P, not + #i2p@freenode. +21:23:09 <duck> all kinds of non political correct talk +21:23:36 <fvw> there's margarita machines? Ooh, me want. +21:23:54 <duck> oh well +21:24:38 <hypercubus> shall we revisit 2)? +21:24:58 <duck> hypercubus: what do you have to add about the browser proxy? +21:25:18 <hypercubus> oops, number 1... since nightblade just graced us with his presence ;-) +21:25:33 <duck> Nightblade: we took the freedom to 'discuss' libsam +21:25:42 <Nightblade> Ok, i'll say a few lines +21:25:48 <hypercubus> but yeah i had something that wasn't brought up on the list about the + browser thing too now that i think about it +21:25:56 <duck> Nightblade: fvw told us that he might be able to help with some freebsd + testing +21:26:20 <fvw> I don't have a freebsd machine anymore but I have accounts on freebsd + machines, give me test cases and I'd be happy to run them. +21:27:02 <Nightblade> I have started working on a C++ dht, which uses Libsam (C). At this + point I have not gotten especially far although I've been working a lot + on it. right now nodes in the dht can "ping" each other through a sam + data message +21:27:09 <Nightblade> in the process i found a couple minor bugs in libsam +21:27:18 <Nightblade> which i will post a new version of sometime in the future +21:27:51 <ugha_node> Nightblade: Could you please remove those 'strstr' calls from libsam? :) +21:27:52 <Nightblade> the test case is: try to compile it and report the errors to me +21:28:01 <Nightblade> what is wrong with strstr +21:28:21 <ugha_node> It's not meant to be used instead of strcmp. +21:28:38 <Nightblade> oh yeah, also I am going to port libsam to windows, but that is not in + any near future +21:29:07 <Nightblade> is there anything wrong with the way i am using it, besides aesthetics? +21:29:15 <Nightblade> you can send me changes or tell me what you'd rather do +21:29:19 <Nightblade> that just seemed the easiest way +21:29:21 <ugha_node> Nightblade: I didn't notice any. +21:29:32 <fvw> strcmp is more efficient than strstr ofcourse. +21:29:36 <ugha_node> But I just skimmed through it. +21:30:20 <ugha_node> fvw: You can occasionally exploit stuff which uses strstr instead of + strcmp, but that's not the case. +21:31:22 <Nightblade> yeah now i see some places where i can change it +21:31:28 <fvw> that too, but I'm assuming you'd have noted that. Well, actually, you'd have + to use strncmp to prevent those exploits. But that's besides the point. +21:31:31 <Nightblade> i don't remember why i did it that way +21:31:57 <ugha_node> fvw: I agree. +21:32:27 <Nightblade> oh now i remember why +21:32:40 <Nightblade> it is a lazy way of not having to figure the length for strncmp +21:32:49 <duck> heh +21:32:52 <ugha_node> Nightblade: Heheh. +21:33:01 <fvw> use min(strlen(foo), sizeof(*foo)) +21:33:04 <hypercubus> shall the spanking commence? +21:33:15 <fvw> I thought the oral sex came first? *ducks* +21:33:32 <fvw> right, next point I think. Hypercube had a comment about proxying? +21:33:38 <hypercubus> heh +21:33:54 <duck> bring it on! +21:34:03 <Nightblade> i will make the changes for the next version - change some of them at + least +21:34:25 <hypercubus> ok, well this had been discussed briefly in channel a few weeks back, + but i think it bears revisiting +21:34:48 <deer> * Sugadude volunteers to perform the oral sex. +21:34:59 <hypercubus> rather than adding TLD's to your browser's block list, or using the + proxy script, there's a third way +21:35:29 <hypercubus> which shouldn't have the same drawbacks as the other two approaches + anonymity-wise +21:36:17 <fvw> which I'll tell you for the cheap cheap price of $29.99? Spill it already! +21:36:27 <hypercubus> and that would be to have the eeproxy re-write incoming html pages to + embed the page in a frameset... +21:36:58 <hypercubus> the main frame would contain the requested HTTP content, the other + frame would serve as a control bar +21:37:13 <hypercubus> and would allow you to turn on/off proxying at will +21:37:40 <hypercubus> and will also alert you, perhaps via colored borders or some other kind + of alert, that you're browsing non-anonymously +21:37:54 <fvw> how are you going to prevent an i2p site (with javascript etc) from turning + off anonimity? +21:37:59 * duck tries to apply jrandom-skill-level-of tolerance +21:37:59 <hypercubus> or that a link in an eepsite page leads to the RealWeb(tm) +21:38:04 <duck> cool! make it! +21:38:16 <fvw> you'll still have to do something fproxy-like, or make something + non-browser-controlled for switching. +21:38:29 <ugha_node> fvw: Right. +21:39:10 <hypercubus> that's why i'm throwing this out here again, perhaps someone might have + some ideas about how to secure this +21:39:31 <hypercubus> but imo this is something that will be sorely needed for most i2p end + usrers +21:39:33 <hypercubus> *users +21:40:04 <hypercubus> because the TLD/proxy script/dedicated browser approaches are too much + to ask of your general net user +21:40:29 <fvw> In the long run, I think an fproxy workalike is the best idea. But that's + definately not a priority imho, and I don't actually think browsing sites will + be the i2p killer app. +21:40:42 <Sonium> What is the netDb anyway? +21:40:59 <duck> Sonium: database of known routers +21:41:10 <hypercubus> fproxy is too cumbersome for most users +21:41:32 <Sonium> doesn't such a database compromise annonymity? +21:41:39 <hypercubus> imo it's part of the reason freenet never caught on in the non-dev + community +21:41:41 <fvw> hypercube: not necessarily. proxy autoconfiguragion ("pac") can make it as + simple as filling in a single value in your browser config. I think we + shouldn't underestimate the fact that in the foreseeable future, all the i2p + users will be at least slightly clueful computer-wise. (all evidence on + freenet-support notwithstanding) +21:42:00 <ugha_node> Sonium: No, 'bad guys' could collect that information manually anyway. +21:42:21 <Sonium> but if NetDb is down i2p is down, right? +21:42:29 <fvw> hypercubus: Not really, I think the fact that it hasn't worked at all since + early 0.5 is more to blame for that. </offtopic time="once again"> + +21:42:44 <fvw> Sonium: you can have more than one netdb (anyone can run one) +21:42:58 <hypercubus> we already have pac, and even though it works spectacularly from a tech + standpoint, realistically it's not going to protect the anonymity of + the avg. jog +21:43:03 <hypercubus> *avg. joe +21:43:22 <ugha_node> fvw: Err.. Every router has its own netDb. +21:43:42 <duck> ok. I am about to pass out. be sure to *baff* the meeting closed after you + are done +21:43:52 <ugha_node> I2P has no central dependencies anymore. +21:44:07 <hypercubus> ok, well i just wanted to get this idea formally in the logs ;-) +21:44:30 <fvw> ugha_node: ok, a published netdb then. I don't actually run a node (yet), I'm + not entirely up with the terminology. +21:44:34 <ugha_node> Hmm. Didn't mihi want to say something? +21:45:05 * fvw feeds duck coffee-flavoured chocolate to keep him up and running a little bit + longer. +21:45:07 <mihi> no :) +21:45:21 <mihi> is duck a network device? ;) +21:45:25 <ugha_node> mihi: Btw, are you going to take the window size increase bounty? +21:45:28 * fvw feeds duck alcohol-flavoured chocolate to shut him down indefinately. +21:45:30 <hypercubus> in swedish +21:45:52 <mihi> ugha_node: what bounty? +21:46:00 <hypercubus> okay, then on to 5), rant-a-rama? ;-) +21:46:13 <ugha_node> mihi: http://www.i2p.net/node/view/224 +21:46:27 * duck eats some of fvw's chocolate +21:47:16 <mihi> ugha_node: definitely no; sorry +21:47:36 <ugha_node> mihi: Uh, okay. :( +21:48:33 * mihi tried to hack up the "old" streaming api some time ago, but that one was too + buggy... +21:48:53 <mihi> but it would imho be easier to fix that one instead of fixing mine... +21:49:21 <ugha_node> Heh. +21:49:42 <hypercubus> so modest +21:49:46 <mihi> since it already has some (broken) "reordering" support in it +21:50:49 <Sonium> is there a way to ask deer how many people are on the i2p-#i2p channel? +21:51:01 <duck> no +21:51:08 <hypercubus> nope, but i can add that to bogobot +21:51:08 <Sonium> :/ +21:51:11 <Nightblade> !list +21:51:13 <deer> <duck> 10 ppl +21:51:13 <hypercubus> after i finish the installer ;-) +21:51:24 <Sonium> !list +21:51:32 <Sonium> o_O +21:51:35 <mihi> Sonium ;) +21:51:38 <ugha_node> This is not an fserv channel! +21:51:39 <Sonium> that was a trick! +21:51:40 <ugha_node> :) +21:51:41 <hypercubus> should be !who +21:51:44 <deer> <duck> ant duck identiguy Pseudonym ugha2p bogobot hirvox jrandom Sugadude + unknown +21:51:48 <cervantes> oop missed the meeting +21:51:57 <ugha_node> !list +21:52:01 <Nightblade> !who +21:52:11 <deer> <duck> !who-your-mom +21:52:17 <mihi> !who !has !the !list ? +21:52:21 <fvw> !yesletsallspamthechannelwithinoperativecommands +21:52:33 <Nightblade> !ban fvw!*@* +21:52:42 <mihi> !ban *!*@* +21:52:50 <hypercubus> i sense a gavel coming down +21:52:51 <duck> sounds like a good time to close it down +21:52:55 <Sonium> btw, you should also implement an !8 command like chanserv has +21:52:59 <fvw> right, now we have that settled, let's clo.. yes. that. +21:53:00 * hypercubus is psychic +21:53:05 <duck> *BAFF* +21:53:11 <Nightblade> !baff +21:53:12 <hypercubus> my hair, my hair +21:53:24 * fvw points at hypercube and laughs. Your hair! Your hair! diff --git a/i2p2www/meetings/logs/93.rst b/i2p2www/meetings/logs/93.rst new file mode 100644 index 00000000..c6202a63 --- /dev/null +++ b/i2p2www/meetings/logs/93.rst @@ -0,0 +1,7 @@ +I2P dev meeting, June 8, 2004 @ 21:02 UTC +========================================= + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/95.log b/i2p2www/meetings/logs/95.log new file mode 100644 index 00000000..5ac5f4d2 --- /dev/null +++ b/i2p2www/meetings/logs/95.log @@ -0,0 +1,282 @@ +14:00 < jrandom> 0) hi +14:00 < jrandom> 1) status update +14:00 < jrandom> 2) cvs HEAD +14:00 < jrandom> 3) 0.4 +14:00 < jrandom> 4) 1.0 +14:00 < jrandom> 5) other activities +14:00 < jrandom> 6) ??? +14:00 < jrandom> 0) hi +14:00 < dm> 7) Profit!! +14:00 < mihi> hi +14:00 < cervantes> hello +14:00 < dm> hi +14:00 < fvw> hi dr nick +14:01 < jrandom> for all those playing at home, we've got the status notes up @ http://dev.i2p.net/pipermail/i2p/2004-June/000286.html +14:01 < jrandom> as we've done in the past, that contains the actual content - we get all meta here and discuss stuff +14:01 * dm is playing at home. WINK WINK WINK. +14:01 < jrandom> BrianR: this is where the LART comes in handy +14:02 < jrandom> anyway, jumping into 1) status update +14:02 < thecrypto> let's see if i can connect to an eepsite +14:03 < jrandom> the other day we had a larger than usual # of routers jumping off the network, which i'm hoping is because a lot of the services on the network were b0rked due to my stupid bugs +14:03 * mihi fires up his router +14:03 < thecrypto> yah! +14:03 < jrandom> if people are taking down their router for another reason (bugs, cpu/memory usage, etc) i'd really love to hear about it +14:04 < dm> ok +14:05 < BrianR> I must say, i2p is currently more well behaved than freenet on my machine... Both in bandwidth hogging and cpu/ram hogging. +14:05 < jrandom> there's a really bad bug in cvs at the moment, but fixed locally - i'll have that committed later tonight (not sure if i'll do so before or after getting my new machine together) +14:05 < jrandom> ah wikked +14:06 < jrandom> well, to be fair, i2p does a lot less than freenet - once we have thousands of routers we'll see how it goes +14:06 < dm> Why don't operating system's have per-application bandwidth limiting built-in? Is it a hard task? +14:06 < BrianR> I'd like to do some stress testing with i2p's built in bandwidth limiting stuff though. How far along is that? +14:06 < dm> All these projects wasting time implementing their own bandwidth limiting, seems silly. +14:06 < fvw> dm: Linux does it, as does freebsd no doubt. +14:07 < dm> Do they? +14:07 < cervantes> netlimiter on windoze does it +14:07 < BrianR> dm: It's not a hard task. There's lots of system level bandwidth limiting stuff available, for 'doze, linux, *bsd... +14:07 < dm> Makes sense to put it in the OS if you ask me. +14:07 < fvw> dm iptables marking + tc under linux; Using it right now, works like a charm. +14:07 < jrandom> BrianR: its in pretty good shape - it'll be in the next 0.3.1.5 release (which i'm hoping to have out this week) +14:07 < dm> But anyway... +14:07 < BrianR> thing is, it often makes more sense to do limiting at the application level so you can make intelligent decisions about where to spend bandwidth first +14:08 < jrandom> exactly +14:08 < dm> That's a different problem. +14:08 < jrandom> with bandwidth limiting within i2p, we know when we're saturating our limit and can refuse to participate in tunnels (etc) +14:08 < BrianR> At the application level you have no idea which one of your TCP connections is going to lose a packet when you're above the system imposed TX limit. +14:08 < fvw> actually, best would be to have the OS give proper feedback; But that's not relevant for i2p right now. +14:09 < jrandom> true fvw, once we integrate i2p with tun/tap ;) +14:09 < BrianR> fvw: You do get some feedback in terms of backpressure.. But it's hard to tell if backpressure is due to the remote side's link being slow or the local side.. +14:09 < dm> Put a bounty on patching windows to have per-application bandwidth limiting. Thanks. +14:09 < jrandom> heh +14:09 < fvw> "my stuff isn't arriving" and "this connection is being throttled now" are two entirely different things. +14:09 < fvw> they sometimes overlap ofcourse. +14:10 < dm> (extra $20 for having a small graph with bandwidth usage of each window in the window title bar... Next to the minimize buttons, etc) +14:11 < jrandom> ok does anyone else have any network status related things to bring up? +14:12 < BrianR> Oh.. That IRC connection monitoring thing.. +14:12 < duckie> I appologize for updating to cvs +14:12 < jrandom> hehe +14:12 < BrianR> Is there a MRTG graph of that or logs or something somewhere? +14:12 < jrandom> bogobot right? duck.i2p/bogo/ iirc? +14:13 < duckie> something like that +14:13 < jrandom> (its linked to off duck.i2p, my routers are down atm so i cant check) +14:13 < duckie> linked to on http://duck.i2p/ uder the stats section +14:13 < duckie> http://duck.i2p/bogobotlogs/ +14:14 < BrianR> it might be useful to extend that thing to act as a general reachability survey tool.. +14:15 < dm> You guys type reaaaaaaaaaaaaaaaally slowly. +14:15 < deer> <cervantes> hypercubus has some enhancements on the backburner, but he's pretty busy with installer stuff atm +14:16 < jrandom> BrianR: bogobot is just for passive irc tracking, but someone could modify i2ptunnel's ping command to support periodic checking? +14:16 < jrandom> or someone could whip up a perl/SAM script ;) +14:16 < BrianR> maybe some sort of script that produces a MRTG graph of endpoint reachability.... +14:16 < BrianR> jrandom: speaking of perl/sam, bring that up again when we get to the appropriate number in the agenda +14:16 < duckie> doesnt the heartbeat thing do that? +14:17 < BrianR> If it does, I couldn't make it work :( +14:17 < jrandom> kind of - heartbeat tests heartbeat servers, not generic apps +14:18 < BrianR> Yes... Like I want to see if I can successfully do a "GET /" on duck.i2p, and how long it took. +14:18 < jrandom> but yes, once the net is in good shape, lots of people can run a heartbeat server and people can ping each other to measure network performance +14:18 < Nightblade> pingflood too +14:18 < dm> Is there a limit on GET strings? +14:18 < dm> like if you have a really long URL, because of cgi parameters? +14:19 < cervantes> 2047 characters iirc +14:19 < jrandom> that wouldnt be too hard to put together +14:19 < BrianR> dm: Depends on the web server... I think the RFC also specifies a minimum which must be suported. +14:19 < jrandom> (er, an http tester) +14:19 < dm> cervantes: thanks +14:19 < dm> (just realized it might affect something I've been working on) +14:20 < cervantes> you run into 2 problems, webserver support and client support +14:20 < BrianR> have we stumbled off topic? +14:20 < cervantes> both IE and Mozilla are 2047 +14:20 < cervantes> eer yep :) +14:21 < dm> I got my answer, we can move on :) +14:21 < jrandom> ok, i think that covers 1), now briefly to 2) cvs HEAD +14:21 < jrandom> there's a nasty bug in there currently, and i apologize for not fixing it sooner +14:22 < jrandom> in general, if you try out cvs HEAD and it doesnt work well, just roll back (download jars / pull from the tag) +14:22 < jrandom> anyway, 'nuff 'bout that +14:23 < jrandom> jumping forward to 3) 0.4 +14:23 < jrandom> the email has my viewpoint / rational for the release - anyone have any concerns / questions / ideas / suggestions? +14:24 < Nightblade> looks good to me +14:24 < duckie> how does it change the time estimates? +14:24 * fvw nods. Sane and everything. +14:25 < jrandom> it actually moves 0.4 closer, as we're pushing the scary parts of 0.3.3 into 0.4.1 and 0.4.2 +14:25 < jrandom> i dont think it'll change the 1.0 dates, just moving things around before it +14:26 < jrandom> the sim has shown our main problem with tunnel diversification can be easily remedied by active peer testing +14:26 < jrandom> we had some of this in the pre 0.2.3 revs, but stopped that since it seemed to add too much overhead +14:27 < jrandom> (when in fact lots of shit was just plain broken, causing the overhead) +14:27 < deer> <cervantes> what does active peer testing involve? +14:29 < jrandom> it just means we'll build some secondary tunnels through peers we wouldnt normally use - specifically, i'm going to have it pull random peers from the 'reliable' set who arent in the 'fast+reliable' set +14:29 < jrandom> (and if that intersection is too small, extend it to the 'not failing' set) +14:29 < jrandom> i dont know how many tunnels or peers to test yet, we'll probably keep that as a tunable parameter +14:30 < jrandom> the issue manifests itself in the peer profiles - you'll see lots of values for your favorite peers, but lots of 0s or other low numbers for other peers +14:30 < jrandom> (which may be due to them being shitty, or more likely due to them not being tested) +14:31 < jrandom> ok, anything else on 0.4? or should we move on to 4) 1.0? +14:32 < duckie> yes +14:33 < jrandom> 4) 1.0 +14:33 < jrandom> i dont see 1.0 as a big scary asymptotically approached release. its just a release where things work and people can use it +14:34 < jrandom> that said, anyone have any concerns / ideas / suggestions/ questions wrt whats in the mail? +14:35 < dm> The rate at which the versioning is increasing would indeed indicate that it is an asymptotically approached 1.0 +14:36 < dm> We're gonna need some big jumps! +14:36 < jrandom> 0.4--> 1.0 +14:36 < dm> Sweeeeeeeet.... +14:36 < jrandom> and we're only a few weeks from 0.4 +14:37 < jrandom> but, of course, we could use some help to get things moving faster :) +14:37 < dm> Are we happy with stability then? +14:37 < jrandom> no, stability right now sucks +14:37 < cervantes> myi2p could be a fairly hefty bit of development to get implemented properly, since it ideally relies on other projects coming to fruition +14:37 < dm> Okay, haven't been following closely. +14:38 < cervantes> such as DHT and datagrams etc +14:38 < jrandom> agreed cervantes, but if we just have it with the address book and distributed blogging, that'll be good enough for me. +14:38 < cervantes> right +14:38 < jrandom> nightblade is working on a dht that we can plug in whenever its ready, or we could add hooks for referencing freenet:CHK@ or SSK@ +14:39 < cervantes> private messaging is just a small hop from the syndicated address book too +14:39 < jrandom> right, its all doable +14:40 < cervantes> live streaming cam girl desktop might take longer... +14:40 -!- Irssi: #i2p: Total of 21 nicks [0 ops, 0 halfops, 0 voices, 21 normal] +14:40 < jrandom> heh +14:40 < jrandom> actually, as I mentioned to Sonium before the meeting, one of the things people can help out with is the documentation front - +14:41 < jrandom> defining what docs we will need, starting to do some outlines of how those docs will fit together, and perhaps even tossing open an editor and writing 'em +14:42 < cervantes> ah I meant to enquire earlier about enhancing the console GUI too +14:42 < jrandom> docs are an essential part of the releases, both for tech docs (since without good tech docs, no devs will get involved) and for user docs (since without good user docs, users will leave) +14:42 < jrandom> that we'll want for the 0.4 release, and will be jsp/servlet driven +14:43 < jrandom> i havent done any mockups or workflows for that even, so if someone wants to jump on that, we could use the help +14:43 < Nightblade> console GUI? what is that - SVGALIB? :) +14:43 < jrandom> heh +14:43 < mihi> Nightblade: TWIN / curses +14:43 < cervantes> is the data set the same or are there new and improved stats for 0.4 +14:44 < dm> I want a console gui in WIN32/MFC +14:44 < Nightblade> the http console on 7655 right +14:44 < cervantes> ie the duration that elephants stay on the moon, and whether they return freuqently +14:44 < cervantes> yup +14:44 < jrandom> all of the things on the console now reflect data that can be made available to a 0.4 console, but we should totally throw out its existing design +14:45 < jrandom> (e.g. no one cares what the base64 of a routerIdentity's public key is) +14:45 < cervantes> although I suggest that info should still be available +14:46 < jrandom> yeah, i think we may keep the existing console as an option - no need to throw it away +14:46 < jrandom> (but it'd be something like http://localhost:7655/uglyConsole/) +14:46 < cervantes> ./forlynxusers/ +14:47 < jrandom> the new admin console should work for lynx users too +14:47 < dm> Does anyone really use lynx? +14:47 < cervantes> eeew cross browser compatibility +14:47 < jrandom> i do +14:47 < jrandom> (at times) +14:47 < dm> but.... why? +14:47 < fvw> for things like brief config edits, definately. +14:47 < cervantes> dm: if you're stuck at a command prompt you don't have much choice +14:47 < fvw> it's quick and you don't need X +14:48 < Nightblade> i use it for web browsing on headless servers +14:48 < deer> <Pseudonym> I use links browser +14:48 < jrandom> well, yeah, links is preferable to lynx +14:48 < mihi> anyone using w3m? +14:48 < dm> I use INTERNET EXPLORER FROM MICROSOFT +14:48 < dm> It's quite cool. +14:48 < jrandom> good point - anything else wrt i2p 1.0? +14:49 < dm> Won the browser war of 1992-1998 +14:49 < jrandom> or moving on to 5) other activites? +14:49 < dm> 3 medals of honor. +14:49 < Nightblade> yes +14:49 < Nightblade> I am hoping to release a new version of libsam tomorrow but my home computer is broke so I don't know +14:49 < Nightblade> I am going to also upload Nickster's threading library +14:49 < jrandom> awesome!/doh! +14:50 < jrandom> nice! +14:50 < Nightblade> which he said was public domain - i am just going to upload it exactly as he sent it - i haven't had time to do much with it +14:50 < jrandom> once 0.3.1.5 is out, i'll start running the cvs server on i2p as well +14:50 < jrandom> cool +14:51 < jrandom> (so nickster will be able to make edits/updates to his code in cvs without exposing his ip) +14:51 < jrandom> whats new in the next rev of libsam? +14:51 < Nightblade> some fixes to datagram send/receive which were broken +14:51 < Nightblade> and some other stuff i don't remember +14:51 < Nightblade> it iwll be in the changelog +14:51 < jrandom> cool, sounds good +14:52 < jrandom> btw, if you want a mailing list for libsam (-announce,-dev,-users,etc) lemmie know +14:52 < jrandom> (but posting on i2p@i2p is fine too) +14:52 < Nightblade> overkill +14:52 < jrandom> hehe +14:53 < jrandom> yeah prolly +14:53 < cervantes> he can have a section in i2pforum +14:53 * cervantes moves smoothly onto his agenda +14:53 < Nightblade> maybe once I get that DHT working - but that is a long way off, and today and yesterday I hvane't had time to do much with it +14:53 < Nightblade> cervantes: there is already an application development forum or somethihng like that iirc +14:53 < Nightblade> also Connelly needs an account on i2p.net if someone has gotten him one yet +14:53 < cervantes> specifically in relation to i2p? +14:54 < Nightblade> http://www.i2p.net/forum/3 +14:54 < jrandom> oh, i havent added an account for connelly, i'll chat with 'im next time i see him +14:54 < fvw> dang, got to run. See you all next week, keep up the good work. +14:54 < jrandom> ugh, yeah, i dont know about the www.i2p.net/forum/s +14:54 < cervantes> ah...drupal... +14:55 < jrandom> cool fvw, glad you could make it +14:56 < cervantes> the i2pforum is pretty much set up +14:56 < cervantes> it basically just needs content/users to fill it :) +14:56 < jrandom> i'm not sure about the drupal forums, or whether they really fit with what i see the website being. i kind of like the idea of a seperate site thats dedicated to being a user/dev forum +14:57 < jrandom> cool cervantes - is that as an eepsite, website, or both? +14:57 < cervantes> I've picked arbitrary forum topics/sections so if people have any ideas or want to write stuff for FAQs etc them that would be appreciated +14:57 < cervantes> it's both +14:58 < cervantes> currently I have the i2p tunnel offline while my router is so unstable +14:58 < jrandom> cant say i blame you :) +14:58 < Nightblade> what is the url +14:58 < cervantes> but people can start playing on outweb +14:59 < cervantes> currenlty you'll have to add an entry to /etc/hosts c:/windows/system32/drivers/etc/hosts +14:59 < cervantes> 212.113.22.104 i2pforum.cervantes.not2p +14:59 < jrandom> heh +15:00 < cervantes> I'll configure it with a proper hostname soon +15:00 < cervantes> or if someone wants to add a subdomain pointer to the php.net domain record...that would be better +15:00 < jrandom> lemmie know if you want something under the i2p.net domain or if you're going with another domain thats cool +15:00 < cervantes> blah +15:00 < cervantes> i2p.net +15:00 < cervantes> <-- php on the brain +15:01 < jrandom> do you want that to be e.g. forum.i2p.net? +15:01 < cervantes> that would be cool ;-) +15:01 < jrandom> w3rd, i'll update the records tonight +15:01 < cervantes> I've tweaked standard phpbb2 code so it doesn't require a valid email to become a member +15:01 < dm> "The site you requested is no longer hosted here" +15:02 < cervantes> if you forget your pass then you have to contact an admin +15:02 < cervantes> dm: did you enter that into your hosts file or are you just browsing to the IP +15:03 < dm> Invalid URI in request GET i2pforum.cervantes. +15:03 < dm> not2p/<P> + +15:03 < dm> I don't use browsers, I'm using telnet. +15:04 < jrandom> i did it through telnet just now. works fine. +15:04 < dm> hmm forgot the HTTP 1.1 I think. +15:04 < jrandom> GET / HTTP/1.1\nHost: i2pforum.cervantes.not2p\n\n +15:04 < jrandom> anyway +15:04 < jrandom> BrianR: ping +15:05 < dm> That worked. Your telnetting skills are sharp, young one. +15:07 -!- Irssi: #i2p: Total of 19 nicks [0 ops, 0 halfops, 0 voices, 19 normal] +15:07 < jrandom> ok, anyone else working on i2p related projects they want to discuss? +15:07 < jrandom> if not, 6) ??? +15:07 < dm> cum! +15:07 * wern put a hand in the air +15:07 < jrandom> hi^2, que tal? +15:08 * jrandom calls on wilde +15:08 -!- wern is now known as wilde +15:08 < wilde> I just want to thank our new sponsors, cervantes and hypercubus +15:08 < wilde> :) +15:09 < wilde> we got two generous donations to the general fund +15:09 < cervantes> wilde: did they convert ok? +15:09 < dm> how much? +15:09 < wilde> cervantes: will exchange them tomorrow +15:09 < cervantes> ah +15:09 < wilde> (hopefully) +15:10 < cervantes> so there still might be a runner-up prize ;-) +15:10 < jrandom> awesome, thanks cervantes & hypercubus :) +15:10 < cervantes> heh...well save praise until the money is in the bank I think ;-) +15:11 < dm> twas a good meeting. I'm off to bed. +15:11 < dm> Nite! +15:11 < jrandom> 'night dm +15:11 < wilde> yeah, I'll do the full praising next time +15:11 < jrandom> ok, anything else to add wilde, or someone else? +15:11 < wilde> yeah +15:12 < wilde> I'll take the i2p.net site down tomorrow for a while (intentionally this time ;) +15:12 < wilde> to switch servers +15:12 < jrandom> heh ok cool +15:12 < wilde> hold on to your posts, they may disappear +15:12 < jrandom> will we have the same IP, or should I update the records? +15:12 < dm> can you make it seamless? +15:12 < wilde> if you post tomorrow that is +15:13 < wilde> dm: no way ;) +15:13 < wilde> not me +15:13 < dm> okay. +15:13 < wilde> jrandom: same IP +15:13 < jrandom> ok cool +15:13 < jrandom> wilde++ +15:13 < wilde> over and out +15:14 < jrandom> ok, anyone else have something they'd like to discuss? +15:14 * cervantes puts on his metal "ming the merciless" skullcap +15:14 < jrandom> in that case +15:15 * jrandom winds up +15:15 * jrandom *baf*s cervantes on the head, closing the meeting diff --git a/i2p2www/meetings/logs/95.rst b/i2p2www/meetings/logs/95.rst new file mode 100644 index 00000000..36c58d84 --- /dev/null +++ b/i2p2www/meetings/logs/95.rst @@ -0,0 +1,7 @@ +I2P dev meeting +=============== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/logs/99.log b/i2p2www/meetings/logs/99.log new file mode 100644 index 00000000..b2ed0241 --- /dev/null +++ b/i2p2www/meetings/logs/99.log @@ -0,0 +1,197 @@ +14:05 < jrandom> 0) hi +14:05 < jrandom> 1) 0.3.2.3, 0.3.3, and the roadmap +14:05 < jrandom> 2) s/reliability/capacity/g +14:05 < jrandom> 3) website updates +14:05 < jrandom> 4) attacks and defenses +14:05 < jrandom> 5) ??? +14:05 < jrandom> 0) hi +14:05 * jrandom waves +14:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html +14:06 < jrandom> swingin right into 1) 0.3.2.3, 0.3.3, and the roadmap +14:07 < jrandom> (while y'all read ahead, i assume ;) +14:07 < jrandom> the 0.3.2.3 release is out there and seems to be doing well +14:07 < jrandom> what are the main pain points people are seeing? +14:08 < deer> <Nightblade> no trouble at all +14:08 < deer> <duck> 4d uptime with no problems +14:08 < jrandom> hmm, word +14:08 < deer> <duck> for some irc doesnt seem too stable +14:08 < deer> <duck> like kaji getting kicked ever minute +14:08 < deer> <duck> but thats nothing new +14:09 < jrandom> yeah that happens to him on the freenode network too, so i'm not sure what to blame there +14:09 < deer> <duck> yeah +14:09 < deer> <duck> connelly had some bad downloads afaik +14:10 < deer> <duck> but you dont hear me complainin' +14:10 < jrandom> ah really? hmm, i think we found some of those were related to his lib, but i've experienced the occational failure on larger file transfers +14:10 < jrandom> especially while leeching books from alexandria +14:10 < jrandom> (well, not especially, but thats the only site i leech from) +14:11 < deer> <duck> :) +14:11 < jrandom> ok, well, my plan is that once the 0.3.3 release is out, my time will be focused on getting us to 0.4, along side any bugfixes people bring up +14:12 < jrandom> the 0.4 work that is left is largely simple web stuff (new router console w/ servlets, jetty integration, servlet to control the router, and a servlet to config the i2ptunnel instances) +14:13 < jrandom> perhaps some jsp/servlet folks can help out with some of that to get their feet wet with the code, though i've done plenty of that stuff before so impl won't be too tough +14:13 < jrandom> afaik hypercubus' installer is pretty much good to go +14:13 < jrandom> (though i threw some new work on him today ;) +14:13 < deer> <duck> featurecreep++ +14:14 < jrandom> keeps people on their toes :) +14:14 < jrandom> (but c'mon, everyone hates downloading all the jars seperately for upgrades) +14:14 < deer> <duck> yes, that is my biggest problem with upgrading +14:14 < deer> <duck> (though I use cvs) +14:14 < deer> <duck> but it would be if I didn't +14:15 < jrandom> heh +14:15 < mihi> jrandom: just tar all of them -> 1 download ;) +14:15 < jrandom> that'd be simple enough, and leave updgrade.sh/upgrade.bat == jar xf upgrade.jar +14:16 < jrandom> (after a wget-esque call) +14:16 < jrandom> well, i think hypercubus has the code to do all that stuff under control, so we can leave it up to him to do the Right Thing +14:17 < jrandom> anyway, yeah, as y'all may have noticed, our schedule isn't quite what it was before +14:17 < jrandom> the roadmap has been updated and eeeellloooonnnggaattteedd +14:18 < mihi> jjrraannddoomm:: cchheecckk yyoouurr dduupplleexx sswwiittcchh +14:18 < deer> <Nightblade> hah +14:18 < jrandom> heh +14:18 * mihi made a mistake... who spots it first? +14:19 < jrandom> (\n\n) +14:19 < jrandom> but anyway +14:19 < mihi> okay, another one ;) +14:19 < duck> (no double spaces) +14:19 < mihi> duck++ +14:20 < jrandom> i do think the roadmap is pretty realistic at least through the 1.0 release now, though depending upon the user adoption and feedback we may reorder or drop one of 0.4.2 or 0.4.3 +14:20 < jrandom> (and, of course, as always the roadmap is subject to change if more people get involved :) +14:21 < modulus> maybe one day I will, after I learn java, but i2p doesn't sound like a project for a novice. +14:21 < deer> <Sandworm> yeah, it'll take longer :) +14:21 < deer> * duck expects some more slips along the road +14:21 < modulus> :-) +14:22 < deer> * duck can barely call it slips, look at the impressive table on http://www.i2p.net/redesign/announcements +14:22 < jrandom> slips may happen of course, but i think the milestones left are all pretty doable +14:22 < jrandom> yeah, thanks for showing that i have no life duck ;) +14:22 < deer> <duck> this is your life +14:22 < modulus> so, when's 1.0 out? :-) +14:22 < deer> <duck> be proud of it +14:23 < jrandom> modulus: while some parts of i2p are a bitch, there are a lot of pieces that can be tackled by a new developer pretty easily +14:23 < modulus> probably rather boring parts though, no? +14:24 < jrandom> naw, not at all. for example, whipping up a neat anonymous file transfer or chat app, a mini webserver, a mud, a chess app, whatever +14:24 < duck> (website updates) +14:24 < modulus> hmm, sounds cool. +14:24 < jrandom> (aka simple client apps that can be anonymous) +14:24 < jrandom> and of course web updates ;) +14:25 < modulus> what's this web updates deal? +14:25 < jrandom> our website needs work (see http://dev.i2p.net/pipermail/i2p/2004-July/000358.html or wait a few minutes for agenda item 3) +14:25 < cat-a-puss> Where does myi2p fit into all that? +14:25 < modulus> ah ah +14:26 < jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :) +14:26 < modulus> methinks myi2p isn't a priority right now... +14:26 < jrandom> (i just wrote a brief page about it a few hours back) +14:27 < jrandom> as an aside, website updates are all posted to the i2pwww mailing list (http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html) +14:28 < modulus> hmm, i could write a global naming ap :-) +14:28 < jrandom> but i do still see the myi2p implementation (at least the base address book and blogging) being implemented for the 1.0 release +14:28 < jrandom> (per the roadmap, slated for november) +14:28 < jrandom> yes, you certainly could +14:28 < modulus> something simpler than DNS, with authentication and delegation of TLD's +14:28 < jrandom> it wouldnt be a bad thing to have either - a simple app that you could query a central name server would be nice +14:29 < modulus> yep +14:29 < jrandom> so, get coding :) +14:29 < modulus> I'll start tomorrow. beat me up if i'm on other things ;-) +14:29 < jrandom> hehe cool, shall do +14:29 < jrandom> ok, moving on to 2) s/reliability/capacity/g +14:29 < duck> small questio on the site: +14:29 < duck> oh wait +14:29 < duck> thats 3 +14:29 < duck> sorry +14:29 < jrandom> sure, sup? +14:30 < jrandom> ah, 'k +14:30 < jrandom> there is going to be a fairly fundamental change to the peer profiling and selection code in the 0.3.3 release, as described in the email and http://www.i2p.net/redesign/how_peerselection +14:31 < jrandom> i've got it running on a pair of routers atm and it seems fairly well behaved (Speed: 25.18 (5 fast peers) Capacity: 17.50 (8 high capacity peers) Integration: 37.00 (2 well integrated peers)) +14:31 < jrandom> and no more negative values :) +14:31 < modulus> :) +14:32 < jrandom> i'm going to kick the tires a bit more, perhaps for another day or two, and then push 'er out as 0.3.3 +14:32 < cat-a-puss> d +14:32 < cat-a-puss> <modulus> +14:32 < cat-a-puss> oops +14:33 < duck> suggesting against updating cvs? +14:33 < cat-a-puss> to do dns look at a cache of http://www.levien.com/thesis/compact.pdf +14:33 < jrandom> nope, cvs is fairly stable atm +14:33 < jrandom> (but as always, be prepared to fall back if some nastiness hits) +14:35 < jrandom> looks cool cat-a-puss, thanks +14:35 < cat-a-puss> (I have a copy of the origional if anyone wants it) +14:36 < jrandom> the google cache kind of garbles the images a bit, so if you have the raw pdf that'd be great +14:36 < jrandom> anyway, we're sliding a bit off topic for the moment (but we can get back to this) +14:37 < jrandom> that's about it for the reliability/capacity switch, so moving on to 3) website updates +14:37 < jrandom> duck: you had something you wanted to bring up? +14:38 < jrandom> while duck prepares his notes, perhaps anyone has any ideas/suggestions/concerns wrt the items posted in the email? +14:39 < deer> <Nightblade> the website looks good +14:39 < jrandom> yeah, i like the new nav and the site layout is quite clean +14:40 < deer> <Nightblade> easier to find stuff +14:40 < cervantes> _much_ easier to find stuff +14:40 < duck> first of all I want to thank our user advocate protocol for becoming useful :) +14:40 < jrandom> heh +14:40 < duck> he had some good suggestions and he did just start +14:40 < cervantes> hip hip horray! +14:40 < jrandom> (hear hear!) +14:41 < duck> next I think that there is barely a reason not to put the redesign up for real +14:42 < jrandom> agreed - perhaps we can just mark the news/development/documentation as non page nav elements, drop the jvm and config tweaks for the moment, and get some basic content for the I2PTunnel page, i think we can deploy it +14:42 < jrandom> i just want it to go live with all links working (and all pages that arent working) +14:43 < jrandom> there will of course be further updates after it goes life ;) +14:43 < jrandom> er, live +14:44 < jrandom> as an aside, wilde has hooked up our 34sp account too, so we'll be able to migrate the site over there when necessary +14:44 < cervantes> coolio +14:44 < jrandom> thoughts duck? can the menu.php thingy handle non-page nav entries? +14:44 * cervantes checks his inbox for referal points +14:45 < jrandom> (or would it be too much effort to mod that in?) +14:45 < jrandom> hehe cervantes, that should be on the way +14:45 < cervantes> ;-) +14:45 < cervantes> ah the old "cheque's in the post" gambit +14:47 < duck> sorry; doing some other work in the meanwhile. +14:47 < duck> ok; yes possible to make it nav section title only +14:47 < jrandom> np, we can move on and come back to it later if you'd prefer +14:47 < jrandom> ok cool +14:47 < jrandom> (duck++) +14:48 < jrandom> ok, any other website related stuff? +14:48 < duck> with your suggestion it sounds ready for up. +14:48 < jrandom> if not, we can move on to 4) attacks and defenses +14:48 < duck> . +14:48 < jrandom> word +14:49 < jrandom> ok, i'm assuming y'all read the mailing list and have seen connelly's posts and the various replies +14:50 < cervantes> he's been busy :) +14:50 < cervantes> (almost as much as proto) +14:50 < Connelly> imo, the network looks sound to all except traffic analysis (sites with lots of traffic), and government connection-severing attacks, and for attackers taking over a large majority of the net +14:50 < jrandom> while i think we're in pretty good shape, i'm certain that there must be something (or things) we've missed, so please don't assume i2p does or will do what it says - challenge the assumptions and say why it sucks +14:50 < Connelly> the encryption pretty much screws over any non-aggressive attacks +14:51 < jrandom> that is the hope +14:51 < jrandom> plus with i2p 2.0 and 3.0 capabilities, defenses for attacks by govt scale adversaries will be possible +14:51 < Connelly> course in practice there will be security holes to patch +14:52 * jrandom still needs to write up some docs as to how the 3.0 delays will prevent segmentation attacks +14:52 < jrandom> certainly connelly +14:54 < jrandom> ok, if there's nothing more along those lines, i think thats all i've got +14:54 < jrandom> so 5) ??? +14:55 < jrandom> oh, as an aside, i plotted the bandwidth usage vs. # tunnels participated in graph for one of the simulations over a 4 day period +14:55 < jrandom> thats posted up @ http://dev.i2p.net/~jrandom/4daybandwidth.png +14:56 < jrandom> the sim had 32KB messages sent back and forth every 30s, with two routers choked at 6KBps, and things behaved exactly as they 'should' +14:56 < duck> (nolink property implemented for the site) +14:56 < jrandom> (e.g. load distributed over the fast reliable peers, slow peers avoided, etc) +14:56 < jrandom> w00t +14:56 < Connelly> a log plot of bandwidth/user vs network size would be nice +14:57 < Connelly> so you can say 'yeah, it really scales' +14:58 < jrandom> that wouldnt even need a log plot - the scalability of client comm is strictly O(1) [requiring 2k*msgSize, where k = # hops in the tunnel] +14:58 < jrandom> but yeah, I agree, we need some docs describing how i2p scales +14:58 < Connelly> well for kademlia ... is that in your sim? +14:58 < jrandom> yeah, the sim is actually the full blown router code, all run in a single JVM +14:58 < jrandom> i'm running it even with the full TCP connections instead of the VM comm system too +14:59 < jrandom> the kademlia code is used for the first time Alice wants to contact Bob - as long as they continue talking, their communication is O(1) as they bundle their LeaseSet along with the payload +14:59 < jrandom> (so there are no needs for subsequent netDb lookups) +15:00 < cervantes> vl07 and onb0 are the choked routers? +15:00 < jrandom> but yeah, we need a simulation to demonstrate how the netDb itself scales +15:01 < jrandom> cevantes: 0jvf and onb0 +15:01 < cervantes> what accounts for vl07's dive after a days uptime? +15:02 < cervantes> seems to cross over with 00u0 +15:02 < jrandom> all of the non-choked routers are essentially equal - they're all on the same CPU, all have the same (0ms) lag, so the allocation of one as 'fast' vs 'reliable' is just arbitrary +15:04 < Connelly> do your designations of 'fast and reliable', 'slow' etc recover from large values? +15:04 < jrandom> why did it reduce its ranking/usage after a day? i'm not sure, perhaps a transient cpu or io overhead while it was being tested caused its speed to reduce a bit +15:04 < jrandom> yes, the rankings use the median now, not the mean, plus there is a fiarly fast decay on the data +15:05 < jrandom> s/fiarly/fairly/ +15:05 < Connelly> so if i make you think my reliability is 1000000000, you can recover when i start dropping messages +15:06 < jrandom> certainly - if you 'fail' i immediately stop asking you to do things and decrease your ranking +15:06 < jrandom> the new "capacity" calculation in turn is quite sensitive to those types of changes +15:06 < jrandom> (speed is kind of hard to fake too, as all speed ranks are actual measured values) +15:07 < jrandom> ((as was the reliability, and as is the capacity calc)) +15:09 < jrandom> ok, anyone else have anything they want to bring up? +15:10 < deer> * jrandomi2p suggests the *baf*er +15:11 * jrandom concurs +15:11 * jrandom winds up +15:11 * jrandom *baf*s the meeting closed diff --git a/i2p2www/meetings/logs/99.rst b/i2p2www/meetings/logs/99.rst new file mode 100644 index 00000000..91aa3b67 --- /dev/null +++ b/i2p2www/meetings/logs/99.rst @@ -0,0 +1,7 @@ +I2P dev meeting, July 20, 2004 @ 21:00 GMT +========================================== + +Quick recap +----------- + +TODO diff --git a/i2p2www/meetings/views.py b/i2p2www/meetings/views.py new file mode 100644 index 00000000..1f3581c0 --- /dev/null +++ b/i2p2www/meetings/views.py @@ -0,0 +1,87 @@ +import codecs +from flask import abort, render_template, request, safe_join, send_from_directory +import os.path +from werkzeug.contrib.atom import AtomFeed + +from i2p2www import MEETINGS_DIR, MEETINGS_PER_PAGE, cache +from i2p2www.helpers import Pagination, get_for_page +from i2p2www.meetings.helpers import get_meetings, get_meetings_feed_items + + +################## +# Meeting handlers + +# Meeting index +@cache.memoize(600) +def meetings_index(page): + all_meetings = get_meetings() + meetings = get_for_page(all_meetings, page, MEETINGS_PER_PAGE) + if not meetings and page != 1: + abort(404) + pagination = Pagination(page, MEETINGS_PER_PAGE, len(all_meetings)) + return render_template('meetings/index.html', pagination=pagination, meetings=meetings) + +# Renderer for specific meetings +@cache.memoize(600) +def meetings_show(id, log=False, rst=False): + """ + Render the meeting X. + Either display the raw IRC .log or render as html and include .rst as header if it exists + """ + # generate file name for the raw meeting file(and header) + lname = str(id) + '.log' + hname = str(id) + '.rst' + lfile = safe_join(MEETINGS_DIR, lname) + hfile = safe_join(MEETINGS_DIR, hname) + + # check if meeting file exists and throw error if it does not.. + if not os.path.exists(lfile): + abort(404) + + # if the user just wanted the .log + if log: + # hmm... maybe replace with something non-render_template like? + # return render_template('meetings/show_raw.html', log=log) + return send_from_directory(MEETINGS_DIR, lname, mimetype='text/plain') + + log='' + header=None + + # try to load header if that makes sense + if os.path.exists(hfile): + # if the user just wanted the .rst... + if rst: + return send_from_directory(MEETINGS_DIR, hname, mimetype='text/plain') + + # open the file as utf-8 file + with codecs.open(hfile, encoding='utf-8') as fd: + header = fd.read() + elif rst: + abort(404) + + # load log + with codecs.open(lfile, encoding='utf-8') as fd: + log = fd.read() + + return render_template('meetings/show.html', log=log, header=header, id=id) + +# Just return the raw .log for the meeting +def meetings_show_log(id): + return meetings_show(id, log=True) + +# Just return the raw .rst for the meeting +def meetings_show_rst(id): + return meetings_show(id, rst=True) + +@cache.cached(600) +def meetings_atom(): + feed = AtomFeed('I2P Meetings', feed_url=request.url, url=request.url_root) + items = get_meetings_feed_items(10) + for item in items: + feed.add(item['title'], + item['content'], + title_type='html', + content_type='html', + url=item['url'], + updated=item['updated']) + return feed.get_response() diff --git a/i2p2www/pages/blog/category.html b/i2p2www/pages/blog/category.html new file mode 100644 index 00000000..9cd89583 --- /dev/null +++ b/i2p2www/pages/blog/category.html @@ -0,0 +1,5 @@ +{% extends "blog/index.html" %} +{% block title %}{{ _('Blog Category') }}: {{ category }}{% endblock %} +{% block headextra %} + <link href="{{ get_url('blog_atom', category=category) }}" type="application/atom+xml" rel="alternate" title="{% trans %}I2P Blog ATOM Feed for Category: {{ category }}{% endtrans %}" /> +{%- endblock %} diff --git a/i2p2www/pages/blog/index.html b/i2p2www/pages/blog/index.html new file mode 100644 index 00000000..c417a067 --- /dev/null +++ b/i2p2www/pages/blog/index.html @@ -0,0 +1,29 @@ +{% extends "global/layout.html" %} +{% block title %}{{ _('Blog Index') }}{% endblock %} +{% block headextra %} + <link href="{{ get_url('blog_atom') }}" type="application/atom+xml" rel="alternate" title="{{ _('I2P Blog ATOM Feed') }}" /> +{%- endblock %} +{% block content %} +<ul id="posts"> +{% for (slug, post) in posts %} + <li> + <article> + <header> + <a href="{{ get_url('blog_post', slug=slug) }}">{{ post.title }}</a> + </header> + {%- if post.excerpt %} + <p>{{ post.excerpt }}</p> + {%- endif %} + <footer> + <ul> + <li>{{ post.date }}</li> + <li>{{ post.author }}</li> + </ul> + </footer> + </article> + </li> +{% endfor %} +</ul> +{%- from "global/macros" import render_pagination with context -%} +{{ render_pagination(pagination) | safe }} +{% endblock %} diff --git a/i2p2www/pages/blog/latest.html b/i2p2www/pages/blog/latest.html new file mode 100644 index 00000000..dbdca457 --- /dev/null +++ b/i2p2www/pages/blog/latest.html @@ -0,0 +1,6 @@ + <ul> + {% for slug, post in blog_posts -%} + <li>{{ post.date }} - <a href="{{ get_url('blog_post', slug=slug) }}">{{ post.title }}</a></li> + {%- endfor %} + <li><a href="{{ get_url('blog_index') }}"><em>{{ _('More blog posts…') }}</em></a></li> + </ul> diff --git a/i2p2www/pages/blog/post.html b/i2p2www/pages/blog/post.html new file mode 100644 index 00000000..07b7de72 --- /dev/null +++ b/i2p2www/pages/blog/post.html @@ -0,0 +1,13 @@ +{% extends "global/layout.html" %} +{%- from "global/macros" import render_categories with context -%} +{% block title %}{{ title }} - {{ _('Blog') }}{% endblock %} +{% block content %} +<ul id="post-info"> + <li class="date">{{ meta.date }}</li> + <li class="author">{{ meta.author }}</li> + <li class="category">{{ render_categories(meta.category)|safe }}</li> +</ul> +{% autoescape false %} +{{ body }} +{% endautoescape %} +{% endblock %} diff --git a/i2p2www/pages/downloads/debian.html b/i2p2www/pages/downloads/debian.html new file mode 100644 index 00000000..17a6e9b9 --- /dev/null +++ b/i2p2www/pages/downloads/debian.html @@ -0,0 +1,204 @@ +{% extends "global/layout.html" %} +{% block title %}Debian/Ubuntu{% endblock %} +{% block content %} +<h1>{{ _('Debian I2P Packages') }}</h1> + +{% trans -%} +The packages hosted on <a href="https://launchpad.net/%7Ei2p-maintainers/+archive/i2p">the I2P Launchpad site</a> +have been tested and <em>should </em>work on x86/x86_64 platforms running: +{%- endtrans %} +<ul> + <li>{% trans %}<a href="#ubuntu">Ubuntu</a> (Hardy <em>8.04</em> and newer){% endtrans %}</li> + <li><a href="#ubuntu">Mint</a> <em>11</em></li> + <li>{% trans %}<a href="#debian">Debian Linux</a> (Lenny and newer) & <a href="#nonlinux">kFreeBSD</a> (Wheezy){% endtrans %}</li> + <li><a href="#debian">Knoppix</a></li> + <li><a href="#debian">Simply MEPIS</a> <em>8.5.03-rel1</em></li> + <li><a href="#ubuntu">Trisque</a>l <em>4.5.1</em></li> + <li><a href="#debian">gNewSense</a> <em>2.3</em></li> + <li><a href="#nonlinux">Nexenta</a> <em>3.0.1</em></li> +</ul> + +{% trans trac=i2pconv('trac.i2p2.i2p') -%} +The I2P packages <em>may</em> work on systems not listed above. Please report any issues +with these packages on <a href="http://{{ trac }}">Trac</a> at +<a href="http://{{ trac }}">http://{{ trac }}</a>. +{%- endtrans %} +<ul> + <li>{% trans %}Option 1: <a href="#ubuntu">Recent versions</a> of Ubuntu and its derivatives (<em>Try this if you're not using Debian)</em>{% endtrans %}</li> + <li>{% trans %}Option 2: <a href="#debian">Debian</a> (including systems based on Debian and older versions of Ubuntu){% endtrans %}</li> + <li>{% trans %}Option 3: <a href="#nonlinux">Non-Linux</a> (and possibly Non-x86 architectures){% endtrans %}</li> +</ul> + +<h2 id="ubuntu">{{ _('Instructions for Ubuntu Lucid Lynx (and newer) and derivatives like Linux Mint & Trisquel') }}</h2> +<h5>{{ _('Adding the PPA via the command line and installing I2P') }}</h5> +<ol> + <li> + {% trans %}Open a terminal and enter:{% endtrans %}<br /> + <code>    sudo apt-add-repository ppa:i2p-maintainers/i2p</code><br /> +{% trans -%} +This command will add the PPA to /etc/apt/sources.list.d and fetch the +gpg key that the repository has been signed with. The GPG key ensures +that the packages have not been tampered with since being built. +{%- endtrans %} + </li> + <li> + {% trans %}Notify your package manager of the new PPA by entering:{% endtrans %}<br /> + <code>    sudo apt-get update</code><br /> +{% trans -%} +This command will retrieve the latest list of software from each +repository that is enabled on your system, including the I2P PPA that +was added with the earlier command. +{%- endtrans %} + </li> + <li>{% trans %}You are now ready to install I2P!{% endtrans %}<br /> + <code>    sudo apt-get install i2p</code></li> +</ol> + +<h5>{{ _('Adding the PPA Using Synaptic') }}</h5> +<ol> + <li> + {% trans -%} + Open Synaptic (System -> Administration -> Synaptic Package Manager). + {%- endtrans %} + </li> + <li> + {% trans -%} + Once Synaptic opens, select <em>Repositories</em> from the <em>Settings</em> menu. + {%- endtrans %} + </li> + <li> + {% trans -%} + Click the <em>Other Sources</em> tab and click <em>Add</em>. Paste <code>ppa:i2p-maintainers/i2p</code> into the APT-line field and click <em>Add Source</em>. Click the <em>Close</em> button then <em>Reload</em>. + {%- endtrans %} + </li> + <li> + {% trans -%} + In the Quick Filter box, type in <code>i2p</code> and press enter. When <code>i2p</code> is returned in the results list, right click <code>i2p</code> and select <em>Mark for Installation</em>. After doing so you may see a <em>Mark additional required changes?</em> popup. If so, click <em>Mark</em> then <em>Apply</em>. + {%- endtrans %} + </li> +</ol> + +{% trans -%} +After the installation process completes you can move on to the next +part of <a href="#Post-install_work">starting I2P</a> and configuring it for your system. +{%- endtrans %} + +<h2 id="debian">{{ _('Instructions for Debian Lenny and newer') }}</h2> + +{% trans -%} +The steps below should be performed with root access (i.e., switching +user to root with "su" or by prefixing each command with "sudo"). +{%- endtrans %} +<ol> + <li> + {% trans %}Add the GPG key that signs the repository with the following command:{% endtrans %}<br /> + <code>    apt-key adv --keyserver keyserver.ubuntu.com --recv-keys <a href="http://keyserver.ubuntu.com:11371/pks/lookup?search=0x474BC46576FAE76E97C1A1A1AB9660B9EB2CC88B&op=index">EB2CC88B</a></code><br /> +{% trans %}You'll have output like the following if the command was successful:{% endtrans %}<br /> +    <img src="{{ url_for('static', filename='images/add-key-terminal.png') }}" alt="" /> + </li> + <li> + {% trans %}For Debian Oldstable (Lenny) and Stable (Squeeze): Add the following entries to <code>/etc/apt/sources.list.d/i2p.list</code>{% endtrans %}<br /> + <code>    deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu natty main <br /> +    deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu natty main </code><br /> +<br /> +{% trans %}For Debian Testing (Wheezy) or Unstable (Sid), use the following:{% endtrans %}<br /> + <code>    deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main <br /> +    deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main </code><br /> + </li> + <li> + {% trans %}Notify your package manager of the new PPA by entering{% endtrans %}<br /> + <code>    apt-get update</code><br /> +{% trans -%} +This command will retrieve the latest list of software from every +repository enabled on your system, including the I2P PPA added in step +1. +{%- endtrans %} + </li> + <li> + {% trans %}You are now ready to install I2P!{% endtrans %}<br /> + <code>    apt-get install i2p</code></li> +</ol> + +{% trans -%} +After the installation process completes you can move on to the next part of <a href="#Post-install_work">starting I2P</a> and configuring it for your system. +{%- endtrans %} + +<h2 id="nonlinux">{{ _('Instructions for Non-Linux / Non-x86') }}</h2> + +{% trans -%} +The steps below should be performed with root access (i.e., switching +user to root with "<code>su</code>" or by prefixing each command with "<code>sudo</code>"). +{%- endtrans %}<br /> +<ol> + <li> + {% trans -%} + Download the <a href="http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu/pool/main/i/i2p/">i2p-router</a> package from the <a href="http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu/pool/main/i/i2p/">PPA</a>. + {%- endtrans %} + </li> + <li> + {% trans -%} + Make sure that you have Java installed. Running <em><code>apt-get install default-jre</code></em> should be sufficient.{% endtrans %}<br /> +{% trans %}You are now ready to install I2P!{% endtrans %}<br /> + <code>    dpkg -i i2p-router_*.deb</code> + </li> + <li> + {% trans jbigi=site_url('misc/jbigi') -%} + It is recommended to compile <a href="{{ jbigi }}">jbigi</a> for your system to achieve better performance. Instructions are available <a href="{{ jbigi }}">here</a>. + {%- endtrans %} +</li> +</ol> + +{% trans -%} +After the installation process completes you can move on to the next part of <a href="#Post-install_work">starting I2P</a> and configuring it for your system. +{%- endtrans %} + +<h2 id="Post-install_work">{{ _('Post-install work') }}</h2> + + +{% trans -%} +Using these I2P packages the I2P router can be started in the following +three ways: +{%- endtrans %} +<ul> + <li> + {% trans -%} + "on demand" using the i2prouter script. Simply run "<code>i2prouter +start</code>" from a command prompt. (Note: Do <strong><u>not</u></strong> use +sudo or run it as root!) + {%- endtrans %} + </li> + <li> + {% trans -%} + "on demand" without the <a href="http://wrapper.tanukisoftware.com/">java service wrapper</a> +(needed on non-Linux/non-x86 systems) by running "<code>i2prouter-nowrapper</code>". +(Note: Do <strong><u>not</u></strong> +use sudo or run it as root!) + {%- endtrans %} + </li> + <li> + {% trans -%} + as a service that automatically runs when your system boots, even +before logging in. The service can be enabled with "<code>dpkg-reconfigure +i2p</code>" as root or using sudo. This is the recommended means of operation. + {%- endtrans %} + </li> +</ul> + +<p>{% trans -%} +When installing for the first time, please remember to <b>adjust your NAT/firewall</b> +if you can. The ports to forward can be found on the <a href="http://127.0.0.1:7657/confignet"> +network configuration page</a> in the router console. If guidance with respect to forwarding ports is needed, +you may find <a href="http://portforward.com">portforward.com</a> to be helpful. +{%- endtrans %}</p> + +<p>{% trans -%} +Please review and <b>adjust the bandwidth settings</b> on the +<a href="http://127.0.0.1:7657/config.jsp">configuration page</a>, +as the default settings of 96 KB/s down / 40 KB/s up are fairly conservative. +{%- endtrans %}</p> + +<p>{% trans browserconfig=site_url('about/browser-config') -%} +If you want to reach eepsites via your browser, have a look on the <a href="{{ browserconfig }}">browser proxy setup</a> page for an easy howto. +{%- endtrans %}</p> + +{% endblock %} diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html new file mode 100644 index 00000000..e1495622 --- /dev/null +++ b/i2p2www/pages/downloads/list.html @@ -0,0 +1,301 @@ +{% extends "global/layout.html" %} +{% block title %}{{ _('Download') }}{% endblock %} +{% block content %} +<h1>{{ _('Download I2P') }}</h1> + +<h3>{{ _('Dependency') }}</h3> +<p>{% trans java='https://www.java.com/en/download/index.jsp', +openjdk='http://openjdk.java.net/install/', +icedtea='http://icedtea.classpath.org/wiki/Main_Page' %} +Java Runtime 1.5 or higher. +(<a href="{{ java }}">Oracle/Sun Java Version 6</a>, +<a href="{{ openjdk }}">OpenJDK 6</a>, or +<a href="{{ icedtea }}">IcedTea6</a> + recommended) +<br /> +<a href="http://java.com/en/download/installed.jsp?detect=jre&try=1">Determine your installed Java version here</a> +or type <tt>java -version</tt> at your command prompt. +{% endtrans %}</p> + +<h3>{{ _('Clean installs') }}</h3> +<div class="downloadlist"> + +<div class="package"> + <h1>Windows</h1> + <div class="file"> + <a href="{{ get_url('downloads_select', file=ver('i2pinstall_%s_windows.exe')) }}">i2pinstall_{{ ver() }}_windows.exe</a> + <div class="sig"> + (SHA256 +d904878f1feb758afb75cae31af52e3504b43b5ff531c060d902145a19eec56e + <a href="{{ get_url('downloads_select', file=ver('i2pinstall_%s_windows.exe.sig')) }}">sig</a>) + </div> + </div> + <div class="details"> + {% trans -%} + Download that file and run it. + {%- endtrans %} + </div> +</div> + +<div class="package"> + <h1>Mac OS X</h1> + <div class="file"> + <a href="{{ get_url('downloads_select', file=ver('i2pinstall_%s.jar')) }}">i2pinstall_{{ ver() }}.jar</a> + <div class="sig"> + (SHA256 +af251596e034b751dc17b73bd35254b94f92d4a3121a6e96479c45c4d846ab30 + <a href="{{ get_url('downloads_select', file=ver('i2pinstall_%s.jar.sig')) }}">sig</a>) + </div> + </div> + <div class="details"> + {% trans i2pversion=ver() -%} + Download that file and double-click it (if that works) or + type <code>java -jar i2pinstall_{{ i2pversion }}.jar</code> in a terminal to run the + installer. + You may be able to right-click and select + "Open with Java". + {%- endtrans %} + + <h2>{% trans %}Command line (headless) install:{% endtrans %}</h2> + {% trans i2pversion=ver() -%} + Download the {{ i2pversion }} OSX graphical installer file above and + run <code>java -jar i2pinstall_{{ i2pversion }}.jar -console</code> from the command line. + {%- endtrans %} + </div> +</div> + +<div class="package"> + <h1>GNU/Linux / BSD / Solaris</h1> + <div class="file"> + <a href="{{ get_url('downloads_select', file=ver('i2pinstall_%s.jar')) }}">i2pinstall_{{ ver() }}.jar</a> + <div class="sig"> + (SHA256 +af251596e034b751dc17b73bd35254b94f92d4a3121a6e96479c45c4d846ab30 + <a href="{{ get_url('downloads_select', file=ver('i2pinstall_%s.jar.sig')) }}">sig</a>) + </div> + </div> + <div class="details"> + {% trans i2pversion=ver() -%} + Download that file and double-click it (if that works) or + type <code>java -jar i2pinstall_{{ i2pversion }}.jar</code> in a terminal to run the + installer. + On some platforms you may be able to right-click and select + "Open with Java". + {%- endtrans %} + + <h2>{% trans %}Command line (headless) install:{% endtrans %}</h2> + {% trans i2pversion=ver() -%} + Download the graphical installer file above and + run <code>java -jar i2pinstall_{{ i2pversion }}.jar -console</code> from the command line. + {%- endtrans %} + </div> +</div> + +<div class="package"> + <h1>Debian / Ubuntu</h1> + <div class="details"> + <a href="{{ get_url('downloads_select', file='debian') }}">{% trans %}Packages for Debian & Ubuntu are available.{% endtrans %}</a> + </div> +</div> + +<div class="package"> + <h1>Android</h1> + <div class="file"> + <a href="http://{{ i2pconv('stats.i2p') }}/i2p.apk">i2p-android-0.9.1-0_b1-API8.apk</a> + <div class="sig"> + (SHA256 +66ed388e8038529dd3a18dcf2f18bd627a75156c98d094e92499fdb124bf4948 + ) + </div> + </div> + <div class="details"> + {% trans spongeurl='http://'+i2pconv('sponge.i2p') -%} + The Android version of I2P is being actively developed. + The latest dev build is version 0.9.3-5_b2-API8, and is available from + <a href="{{ spongeurl }}">sponge's eepsite</a> - + scan or click the QR code. + {%- endtrans %} + <div class="warning"> + {% trans -%} + The release and dev versions of the I2P APK are not compatible, as they + are signed by zzz and sponge respectively. Uninstall one before installing + the other. + {%- endtrans %} + </div> + </div> +</div> + +<div class="package"> + <h1>{{ _('Source package') }}</h1> + <div class="file"> + <a href="{{ get_url('downloads_select', file=ver('i2psource_%s.tar.bz2')) }}">i2psource_{{ ver() }}.tar.bz2</a> + <div class="sig"> + (SHA256 +441eac3cb7f25c03e7711c7d516626dc86ba6ad373145ab802d150848262c7c2 + <a href="{{ get_url('downloads_select', file=ver('i2psource_%s.tar.bz2.sig')) }}">sig</a>) + </div> + </div> + <div class="details"> + {% trans monotoneurl=site_url('get-involved/guides/new-developers'), i2pversion=ver() -%} + Alternately, you can fetch the source from <a href="{{ monotoneurl }}#getting-the-i2p-code">monotone</a>. + <br /> + Run <code>(tar xjvf i2psource_{{ i2pversion }}.tar.bz2 ; cd i2p-{{ i2pversion }} ; ant pkg)</code> then either + run the GUI installer or headless install as above. + {%- endtrans %} + </div> +</div> + +</div> + +{% trans signingkey=site_url('get-involved/develop/release-signing-key') -%} +The files are signed by zzz, +<a href="{{ signingkey }}">whose key is here</a>. +{%- endtrans %} + +<p>{% trans -%} +I2P can also be downloaded from our project pages on <a href="https://launchpad.net/i2p/trunk">Launchpad</a> and <a href="http://code.google.com/p/i2p/">Google Code</a>. +{%- endtrans %}</p> + +<h3>{{ _('Post-install work') }}</h3> + +<p>{% trans -%} +After running the installer on windows, simply click on the "Start I2P" button +which will bring up the <a href="http://localhost:7657/index.jsp">router console</a>, +which has further instructions. +{%- endtrans %}</p> + +<p>{% trans -%} +On Unix-like systems, I2P can be started as a service +using the "i2prouter" script, located in the directory you selected for I2P. +Changing to that directory in a console and issuing "sh i2prouter status" +should tell you the router's status. The arguments "start", "stop" and "restart" +control the service. The <a href="http://localhost:7657/index.jsp">router console</a> +can be accessed at its usual location. +For users on OpenSolaris and other systems for which the wrapper (i2psvc) is not supported, +start the router with "sh runplain.sh" instead. +{%- endtrans %}</p> + +<p>{% trans faq=site_url('faq') -%} +When installing for the first time, please remember to <b>adjust your NAT/firewall</b> +if you can, bearing in mind the Internet-facing ports I2P uses, +<a href="{{ faq }}#ports">described here</a> among other ports. +If you have successfully opened your port to inbound TCP, also enable inbound TCP on the +<a href="http://localhost:7657/confignet.jsp">configuration page</a>. +{%- endtrans %}</p> + +<p>{% trans -%} +Also, please review and <b>adjust the bandwidth settings</b> on the +<a href="http://localhost:7657/config.jsp">configuration page</a>, +as the default settings of 96 KBps down / 40 KBps up are fairly slow. +{%- endtrans %}</p> + +<p>{% trans browserconfig=site_url('about/browser-config') -%} +If you want to reach eepsites via your browser, have a look on the <a href="{{ browserconfig }}">browser proxy setup</a> page for an easy howto. +{%- endtrans %}</p> + +<h3>{{ _('Updates from earlier releases:') }}</h3> + +<p>{% trans -%} +Both automatic and manual upgrades are available for the release. +{%- endtrans %}</p> + +<div class="package"> + <h1>{{ _('Automatic updates') }}</h1> + <div class="details"> +<p>{% trans -%} +If you are running 0.7.5 or later, your router should detect the +new release. To upgrade simply click the 'Download Update' button on your router console +when it appears. +{%- endtrans %}</p> + <div class="warning"> +<p>{% trans -%} +Due to a bug in release 0.7.6, those whose first I2P installation was that version +and have not upgraded manually +may get a "downloaded version is not greater than current version" error, +and should use the manual update method below. +{%- endtrans %}</p> + </div> + <div class="warning"> +<p>{% trans blogpost=get_url('blog_post', slug='2009/06/29/0.7.5-Release') -%} +If you are running 0.7.4 or earlier, please see +<a href="{{ blogpost }}">the 0.7.5 release notes</a> +for important information about how to configure your router to automatically +receive the release. +{%- endtrans %}</p> + </div> + <div class="warning"> +<p>{% trans instructions=site_url('misc/upgrade-0.6.1.30') -%} +If you are running 0.6.1.30 or earlier, please see +<a href="{{ instructions }}">instructions</a> +for important information about how to configure your router to automatically +receive the release. +{%- endtrans %}</p> + +<ol> +<li> + {% trans instructions=site_url('misc/upgrade-0.6.1.30') -%} + If you have reconfigured your router following the <a href="{{ instructions }}">instructions</a>, you should see a link on your + <a href="http://localhost:7657/index.jsp">router console</a> allowing + you to download and install the new release by just clicking on that + link. + {%- endtrans %} +</li> +<li> + {% trans -%} + Alternately, you can use the manual method specified below. + {%- endtrans %} +</li> +</ol> + </div> + </div> +</div> + +<div class="package"> + <h1>{{ _('Manual updates') }}</h1> + <div class="file"> + <a href="{{ get_url('downloads_select', file=ver('i2pupdate_%s.zip')) }}">i2pupdate_{{ ver() }}.zip</a> + <div class="sig"> + (SHA256 +d20c3f3845c1f4a4cf734dc69cae7de72ff0874cea1382d03d8ac953c50fb139 + <a href="{{ get_url('downloads_select', file=ver('i2pupdate_%s.zip.sig')) }}">sig</a>) + </div> + </div> + <div class="details"> +<ol> +<li> + {% trans -%} + Download that file to your I2P + installation directory and <b>rename as i2pupdate.zip</b>. + (alternately, you can get the source as above and run "ant updater", then copy the + resulting i2pupdate.zip to your I2P installation directory). You do + NOT need to unzip that file. + {%- endtrans %} +</li> +<li> + {% trans -%} + Click <a href="http://localhost:7657/configservice.jsp">"Restart"</a> + {%- endtrans %} +</li> +<li> + {% trans -%} + Grab a cup of coffee and come back in 11 minutes + {%- endtrans %} +</li> +</ol> + </div> +</div> + +{% trans signingkey=site_url('get-involved/develop/release-signing-key') -%} +The file is signed by zzz, +<a href="{{ signingkey }}">whose key is here</a>. +{%- endtrans %} + +<h3>{{ _('Previous Releases') }}</h3> + +{% trans echelon=i2pconv('echelon.i2p') -%} +Previous releases are available on <a href="http://code.google.com/p/i2p/downloads/list?can=1">Google Code</a> +and <a href="https://launchpad.net/i2p/trunk">Launchpad</a> +and within the I2P network on <a href="http://{{ echelon }}/">{{ echelon }}</a>. +{%- endtrans %} + +{% endblock %} diff --git a/i2p2www/pages/downloads/mirrors b/i2p2www/pages/downloads/mirrors new file mode 100644 index 00000000..4913ac68 --- /dev/null +++ b/i2p2www/pages/downloads/mirrors @@ -0,0 +1,5 @@ +{"url": "http://i2p.googlecode.com/files/%(file)s", "org": "Google Code", "org_url": "http://code.google.com", "protocol": "http", "country": "us"} +{"url": "https://i2p.googlecode.com/files/%(file)s", "org": "Google Code", "org_url": "https://code.google.com", "protocol": "https", "country": "us"} +{"url": "https://launchpad.net/i2p/trunk/%(version)s/+download/%(file)s", "org": "Launchpad", "org_url": "https://launchpad.net", "protocol": "https", "country": "us"} +{"url": "http://golden.mtveurope.org/~yang/i2p_mirror/%(file)s", "org": "VServer.si", "org_url": "http://www.vserver.si", "protocol": "http", "country": "lu"} +{"url": "http://a.mirror.geti2p.net/releases/current/%(file)s", "org": "welterde", "protocol": "http", "country": "de"} diff --git a/i2p2www/pages/downloads/select.html b/i2p2www/pages/downloads/select.html new file mode 100644 index 00000000..4d7a60f8 --- /dev/null +++ b/i2p2www/pages/downloads/select.html @@ -0,0 +1,17 @@ +{% extends "global/layout.html" %} +{% block title %}{{ _('Mirror selection') }}{% endblock %} +{% block content %} +<h1>{{ _('Mirror selection') }}</h1> +<h2>{{ _('File:') }} /{{ file }}</h2> +{% for protocol in mirrors -%} +<div class="protocol"> + <h3>{{ protocol.name | upper }}</h3> + <ul> + <li><a href="{{ url_for('downloads_redirect', protocol=protocol.name, file=file) }}">{{ _('Any mirror') }}</a></li> + {% for mirror in protocol.mirrors -%} + <li><img src="{{ url_for('static', filename='images/flags/'+mirror.country+'.png') }}" /> {% if mirror.org_url %}<a href="{{ mirror.org_url }}">{% endif %}{{ mirror.org }}{% if mirror.org_url %}</a>{% endif %} <a href="{{ url_for('downloads_redirect', protocol=protocol.name, file=file, mirror=loop.index-1) }}">[{{ _('Download') }}]</a></li> + {%- endfor %} + </ul> +</div> +{%- endfor %} +{% endblock %} diff --git a/i2p2www/pages/global/bounty.html b/i2p2www/pages/global/bounty.html new file mode 100644 index 00000000..8befd0be --- /dev/null +++ b/i2p2www/pages/global/bounty.html @@ -0,0 +1,38 @@ +{% extends "global/layout.html" %} +{% block content %} +<!-- {% block donatename %}{% endblock %} --> +<div id="bounty"> + +<div class="details"> +{% block bountydetails %}{% endblock %} +</div> + +<div class="judge"> +{% block bountyjudge %}{% endblock %} +</div> + +{% block bountynotesouter %} +<div class="notes"> +Note: +<ul> +{% block bountynotes %} +<li>{% trans -%} +To claim the bounty the author must not be paid by other organizations +or teams for this work (e.g. GSoC students are not valid). +{%- endtrans %}</li> +{% endblock %} +</ul> +</div> +{% endblock %} + +<div class="donate"> +<p><i>{% trans donate=site_url('get-involved/donate'), donatename=self.donatename() -%} +Bounty amounts may be increased by further donations. Do +you think these are important? <a href="{{ donate }}">Add in your donation</a>, +marking the amount for the {{ donatename }} bounty! +{%- endtrans %}</i></p> +</div> + +</div> +{% endblock %} + diff --git a/i2p2www/pages/global/error_404.html b/i2p2www/pages/global/error_404.html new file mode 100644 index 00000000..5111f007 --- /dev/null +++ b/i2p2www/pages/global/error_404.html @@ -0,0 +1,13 @@ +{% extends "global/layout.html" %} +{% block title -%} +{% trans -%} +Not found +{%- endtrans %} +{%- endblock %} + +{% block content %} +{% trans -%} +Yep... the resource, you were searching for, is named differently, doesn't exist or was removed. +{%- endtrans %} + +{% endblock %} diff --git a/i2p2www/pages/global/error_500.html b/i2p2www/pages/global/error_500.html new file mode 100644 index 00000000..e96680d0 --- /dev/null +++ b/i2p2www/pages/global/error_500.html @@ -0,0 +1,21 @@ +<!DOCTYPE html> +<html lang="en"> + <head> + <meta charset="UTF-8"> + <title>{% trans %}Server error{% endtrans %} - I2P + + + + + +

+

I2P

+
{% trans %}500 Server error{% endtrans %}
+
+
+
+ {% trans %}Umm... the server encountered some sort of error.{% endtrans %} +
+
+ + diff --git a/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html new file mode 100644 index 00000000..f6f49979 --- /dev/null +++ b/i2p2www/pages/global/footer.html @@ -0,0 +1,32 @@ +
+

{{ _('Mirrors') }}

+ +
+
+

{{ _('Secure') }}

+ +
+
+

{{ _('Misc.') }}

+ +
+
+

{{ _('T-Shirts!') }}

+ +
+
+ {{ _('Donate') }} +
diff --git a/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html new file mode 100644 index 00000000..314f7be4 --- /dev/null +++ b/i2p2www/pages/global/lang.html @@ -0,0 +1,7 @@ + diff --git a/i2p2www/pages/global/lang.html.full b/i2p2www/pages/global/lang.html.full new file mode 100644 index 00000000..ccff347c --- /dev/null +++ b/i2p2www/pages/global/lang.html.full @@ -0,0 +1,14 @@ + diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html new file mode 100644 index 00000000..c63e3f75 --- /dev/null +++ b/i2p2www/pages/global/layout.html @@ -0,0 +1,78 @@ +{%- from "global/macros" import change_lang with context -%} + + + + + {% block title_outer %}{% block title %}{% endblock %} - I2P{% endblock %} + {%- if self.metadesc() %} + + {%- endif %} + + + {% if g.exttheme %}{% else -%} + + + + + + {%- endif %} + + + {%- block headextra %}{% endblock %} + + +
{{ _('Skip navigation') }}
+
+
+ +
+

{{ self.title() }}

+
+ {% include "global/lang.html" %} +
+
+
+ + +
+
+
+ {% block content_outer %} +
+ {% if self.lastupdated() or self.accuratefor() -%} +
+ + {% if self.lastupdated() and self.accuratefor() -%} + {% trans lastupdated=self.lastupdated(), accuratefor=self.accuratefor() -%} + This page was last updated in {{ lastupdated}} and is accurate for router version {{ accuratefor }}. + {%- endtrans %} + {%- else %}{% if self.lastupdated() -%} + {% trans lastupdated=self.lastupdated() -%} + This page was last updated in {{ lastupdated}}. + {%- endtrans %} + {%- else %}{% if self.accuratefor() -%} + {% trans accuratefor=self.accuratefor() -%} + This page is accurate for router version {{ accuratefor }}. + {%- endtrans %} + {%- endif %}{% endif %}{% endif %} +
+ {%- endif %} + {% block content %}{% endblock %} +
+ {% endblock %} +
+ +
+ + diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros new file mode 100644 index 00000000..49642f19 --- /dev/null +++ b/i2p2www/pages/global/macros @@ -0,0 +1,44 @@ +{%- macro change_lang(lang) -%} +{%- if request.endpoint == 'site_show' -%}{{ url_for('site_show', lang=lang, page=page) }} +{%- elif request.endpoint == 'blog_index' -%} + {%- if category -%}{{ url_for('blog_index', lang=lang, category=category) }} + {%- else -%}{{ url_for('blog_index', lang=lang) }} + {%- endif -%} +{%- elif request.endpoint == 'blog_post' -%}{{ url_for('blog_post', lang=lang, slug=slug) }} +{%- elif request.endpoint == 'meetings_show' -%}{{ url_for('meetings_show', lang=lang, id=id) }} +{%- elif request.endpoint == 'downloads_select' -%}{{ url_for('downloads_select', lang=lang, file=file) }} +{%- elif request.endpoint -%}{{ url_for(request.endpoint, lang=lang) }} +{%- else -%}{{ url_for('site_show', lang=lang) }} +{%- endif -%} +{%- endmacro -%} + +{%- macro render_pagination(pagination) %} + +{%- endmacro -%} + +{%- macro render_categories(categories) -%} +{%- if categories and categories|length %} +{%- for category in categories %}{{ category }}{% if not loop.last %}, {% endif %}{% endfor %} +{%- else %}{{ _('None') }} +{%- endif %} +{%- endmacro %} diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html new file mode 100644 index 00000000..286e00e8 --- /dev/null +++ b/i2p2www/pages/global/nav.html @@ -0,0 +1,143 @@ +
+ +
diff --git a/i2p2www/pages/global/sitemap.xml b/i2p2www/pages/global/sitemap.xml new file mode 100644 index 00000000..020461fb --- /dev/null +++ b/i2p2www/pages/global/sitemap.xml @@ -0,0 +1,16 @@ + + +{%- for url in urls %} + + {{ url_root }}{{ g.lang }}{{ url.path }} + {%- for altlang in langs %} + + {%- endfor %} + +{%- endfor %} + diff --git a/i2p2www/pages/global/sitemap_index.xml b/i2p2www/pages/global/sitemap_index.xml new file mode 100644 index 00000000..2bf57284 --- /dev/null +++ b/i2p2www/pages/global/sitemap_index.xml @@ -0,0 +1,8 @@ + + +{%- for lang in langs %} + + {{ url_root }}{{ lang }}/sitemap.xml + +{%- endfor %} + diff --git a/www.i2p2/pages/_monotonerc.html b/i2p2www/pages/include/monotonerc.html similarity index 99% rename from www.i2p2/pages/_monotonerc.html rename to i2p2www/pages/include/monotonerc.html index cf04e43d..6e7cd75b 100644 --- a/www.i2p2/pages/_monotonerc.html +++ b/i2p2www/pages/include/monotonerc.html @@ -1,4 +1,3 @@ - 
 -- This implements a list of trusted signers.
diff --git a/i2p2www/pages/meetings/index.html b/i2p2www/pages/meetings/index.html
new file mode 100644
index 00000000..4390cf58
--- /dev/null
+++ b/i2p2www/pages/meetings/index.html
@@ -0,0 +1,28 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Meetings') }}{% endblock %}
+{% block headextra %}
+    
+{%- endblock %}
+{% block content %}
+
{{ _('Logs of past I2P meetings') }}

+
+
{% trans -%}
+Meetings are currently on hold until a more suitable time can be chosen.
+{%- endtrans %}

+
+
{% trans blogindex=get_url('blog_index') -%}
+If you have something to discuss, please find the developers on IRC in #i2p-dev.
+Status updates from developers are also available.
+{%- endtrans %}

+
+

+
+
+{%- from "global/macros" import render_pagination with context -%}
+{{ render_pagination(pagination) | safe }}
+{% endblock %}
diff --git a/i2p2www/pages/meetings/show.html b/i2p2www/pages/meetings/show.html
new file mode 100644
index 00000000..c65da553
--- /dev/null
+++ b/i2p2www/pages/meetings/show.html
@@ -0,0 +1,16 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}I2P Development Meeting {{ id }}{% endtrans %}{% endblock %}
+{% block content %}
+{% autoescape false %}
+{% if header %}
+{{ header | restructuredtext }}
+{% endif %}
+{% endautoescape %}
+

+
{{ _('Full IRC Log') }}

+
+{{ log|escape }}
+{# TODO: pygments #}
+

+

+{% endblock %}
diff --git a/www.i2p2/pages/htproxyports.html b/i2p2www/pages/site/about/browser-config.html
similarity index 52%
rename from www.i2p2/pages/htproxyports.html
rename to i2p2www/pages/site/about/browser-config.html
index 436fd481..e3b56988 100644
--- a/www.i2p2/pages/htproxyports.html
+++ b/i2p2www/pages/site/about/browser-config.html
@@ -1,93 +1,106 @@
-{% extends "_layout.html" %}
-{% block title %}Web Browser Configuration{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Web Browser Configuration') }}{% endblock %}
 {% block content %}
 
-
Your web browser will need to be configured in order to browse eepsites and to
+
{% trans -%}
+Your web browser will need to be configured in order to browse eepsites and to
 utilize the outproxies available within I2P. Below are walkthroughs for some of
 the most popular browsers.
-

+{%- endtrans %}

 
-
How to configure your browser

+
{{ _('How to configure your browser') }}

 
 
 
 
 
-
Internet Explorer 8 or Chrome

-

+
{{ _('Internet Explorer 8 or Chrome') }}

+
{% trans -%}
 In the tools menu select the "Internet Options" line to open the settings. In the
 settings window choose the connections tab and click on LAN settings for the
-proxy port configuration.

-IEOptions
-

+proxy port configuration.
+{%- endtrans %}

+{{ _('IE Internet Options') }}
+
{% trans -%}
 Now set the checkmark at "use a proxy server for your LAN" and at the "Bypass
 proxy server for local addresses". With a click on Advanced-button you open the
 window to open the ports. Enter the values like on the picture, IP 127.0.0.1
 and port 4444 for HTTP, port 4445 for HTTPS. With clicks on OK you save the
-settings and your browser is set to use the I2P proxy.

-IEPPorts
+settings and your browser is set to use the I2P proxy.
+{%- endtrans %}

+{{ _('IE Proxy Settings') }}
 
 
 
Firefox

-

+
{% trans -%}
 From the Tools menu, select Options to bring up the Firefox settings panel.
 Click the icon labelled Advanced, then click on the Network
 tab. In the Connections section, click on the Settings button. You'll
-see a Window like the following:

-
-

+see a Window like the following:
+{%- endtrans %}

+{{ _('Firefox Network Options') }}
+
{% trans -%}
 In the Connection Settings window, click the circle next to Manual
     proxy configuration, then enter 127.0.0.1, port 4444 in the HTTP Proxy
 field.  Enter 127.0.0.1, port 4445 in the SSL Proxy field.
-Be sure to enter localhost and 127.0.0.1 into the "No Proxy for" box.

-
-

+Be sure to enter localhost and 127.0.0.1 into the "No Proxy for" box.
+{%- endtrans %}

+{{ _('Firefox Proxy Settings') }}
 
 
 
Konqueror

-

+
{% trans -%}
 From the Settings menu, select Configure Konqueror. In the
 Web Browsing group on the left side, select Proxy Services.
 In this new window, select the option "Manually specify the proxy settings" and
-click the Setup box.

-
-

+click the Setup box.
+{%- endtrans %}

+{{ _('Konqueror Proxy Options') }}
+
{% trans -%}
 Enter 127.0.0.1 and port 4444 into the HTTP box. Enter 127.0.0.1 and port 4445 into
 HTTPS box. Click the New button in the Exceptions section. Enter
 localhost and click OK. Click the New button once more and enter
-127.0.0.1 and OK. Hit OK once more to close the configuration window.

-
-

+127.0.0.1 and OK. Hit OK once more to close the configuration window.
+{%- endtrans %}

+{{ _('Konqueror Proxy Ports') }}
 
 
-
Outproxy Terms Of Service

-

+
{{ _('Outproxy Terms Of Service') }}

+
{% trans -%}
 Remember: I2P was not designed for creating proxies to the outer Internet.
 Instead, it is meant to be used as an internal network.
-

-

+{%- endtrans %}

+
{% trans -%}
 The I2P project itself does not run any proxies to the Internet. Any such proxy
-    services are run by by private volunteers and could be shut down or
-    unreachable at anytime.

-

+services are run by by private volunteers and could be shut down or
+unreachable at anytime.
+{%- endtrans %}

+
{% trans -%}
 By default, I2P comes with two outproxies configured: false.i2p
 (an HTTP-only proxy) and outproxyng.h2ik.i2p (an HTTPS proxy
-routed through Tor.

-
Both of these outproxies are configured with connection limits. This means
+routed through Tor.
+{%- endtrans %}

+
{% trans -%}
+Both of these outproxies are configured with connection limits. This means
 that only set amount of accesses are allowed per client. Once the limit is
 reached, the client is blocked out for a timeframe of 1min/1h/1 day. Be
-respectful and do not overload these services with too many requests!

-
Filtering is active on these outproxies (for example, mibbit and torrent
+respectful and do not overload these services with too many requests!
+{%- endtrans %}

+
{% trans tpb=i2pconv('tpb.i2p') -%}
+Filtering is active on these outproxies (for example, mibbit and torrent
 tracker access is blocked). Note that even though the pirate bay is blocked
-they host an official eepsite at tpb.i2p. Eepsites
+they host an official eepsite at {{ tpb }}. Eepsites
 that are accessible via .i2p addresses are also not allowed via the outproxies.
-As a convenience, False.i2p blocks ad servers.

-
Tor is good application to use as an
-outproxy to the Internet.

+As a convenience, False.i2p blocks ad servers.
+{%- endtrans %}

+
{% trans -%}
+Tor is good application to use as an
+outproxy to the Internet.
+{%- endtrans %}

 
 {% endblock %}
diff --git a/www.i2p2/pages/glossary.html b/i2p2www/pages/site/about/glossary.html
similarity index 93%
rename from www.i2p2/pages/glossary.html
rename to i2p2www/pages/site/about/glossary.html
index 10796a54..73f4a77d 100644
--- a/www.i2p2/pages/glossary.html
+++ b/i2p2www/pages/site/about/glossary.html
@@ -1,7 +1,9 @@
-{% extends "_layout.html" %}
-{% block title %}Glossary{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Glossary') }}{% endblock %}
 {% block content %}
+{% trans -%}
 This page lists often-used terminology when discussing I2P and cryptography.
+{%- endtrans %}
 
diff --git a/www.i2p2/pages/halloffame.html b/i2p2www/pages/site/about/hall-of-fame.html
similarity index 60%
rename from www.i2p2/pages/halloffame.html
rename to i2p2www/pages/site/about/hall-of-fame.html
index 286915d9..e1e91bf9 100644
--- a/www.i2p2/pages/halloffame.html
+++ b/i2p2www/pages/site/about/hall-of-fame.html
@@ -1,21 +1,30 @@
-{% extends "_layout.html" %}
-{% block title %}halloffame{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Hall Of Fame') }}{% endblock %}
 {% block content %}
 
-
I2P's Hall of Fame
   
-Current balance: as of 2013-03-01

-General fund: 5940,28 € and 1222,87398130 BTC

-Datastorage bounty: 145.0 € and 2 BTC

-native IPv6 I2P : 100.0 € and 50 BTC

-I2PHex bounty: 100.0 €

-I2P in debian mirrors: 123.0 €

-Bitcoin client for I2P: 30.0 € and 118.34 BTC

-Unit Tests for I2P router: 2305 €

-Bounty Robert: 0

-Bounty Syndie: 50 BTC

+
{% trans %}I2P's Hall of Fame{% endtrans %}

+{% trans date='2013-03-01' -%}
+Current balance: as of {{ date }}
+{%- endtrans %}

+{{ _('General fund') }}:
+{% trans euroval='5940,28', btcval='1222,87398130' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}

+{{ _('Datastorage bounty') }}:
+{% trans euroval='145.0', btcval='2' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}

+{{ _('Native IPv6 I2P') }}:
+{% trans euroval='100.0', btcval='50' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}

+{{ _('I2PHex bounty') }}:
+{% trans euroval='100.0' %}{{ euroval }} €{% endtrans %}

+{{ _('I2P in debian mirrors') }}:
+{% trans euroval='123.0' %}{{ euroval }} €{% endtrans %}

+{{ _('Bitcoin client for I2P') }}:
+{% trans euroval='30.0', btcval='118.34' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}

+{{ _('Unit Tests for I2P router') }}:
+{% trans euroval='2305' %}{{ euroval }} €{% endtrans %}

+{{ _('Bounty Robert') }}: 0

+{{ _('Bounty Syndie') }}: 50 BTC


-Current monthly running costs:

+{{ _('Current monthly running costs:') }}

     

         I2P
 
 
 

@@ -26,19 +35,19 @@
         

     

         Welterde40 €/mo since January, 2008 - i2p-projekt.de and domains
     

 

-
Big thanks go to the following people who have donated to I2P!

-

-If you have made a donation, please send an email to echelon
+
{% trans %}Big thanks go to the following people who have donated to I2P!{% endtrans %}

+
{% trans echelon='echelon@'+i2pconv('mail.i2p') -%}
+If you have made a donation, please send an email to echelon
 with your name or nick (and optionally homepage) so we can list you here.
-

+{%- endtrans %}

 
-Current monthly subscriptions:

+{{ _('Current monthly subscriptions:') }}

 
-  
+  
01/2012-01/2013anonymous30 €General fund
01/2012-01/2013anonymous30 €{{ _('General fund') }}

 

 

 
-2013 donations and costs:

+{{ _('2013 donations and costs:') }}

 
@@ -82,225 +91,225 @@ with your name or nick (and optionally homepage) so we can list you here.
 

  
datewhoincomeoutgoingaccount

  
Jan, 2013anonymous10 €General fund
 
 

 

-2012 donations and costs:

+{{ _('2012 donations and costs:') }}

 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
- 
- 
- 
+ 
+ 
+ 
- 
- 
- 
+ 
+ 
+ 
  
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
  
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
+ 
+ 
  
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
  
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
  
- 
- 
- 
- 
+ 
+ 
+ 
+ 
  
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
  
- 
- 
- 
- 
+ 
+ 
+ 
+ 
  
- 
- 
- 
+ 
+ 
+ 
  
- 
- 
- 
- 
+ 
+ 
+ 
+ 
  
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
  
- 
+ 
  
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
+ 
+ 
+ 
  
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
+ 
+ 

  
datewhoincomeoutgoingaccount
Jan, 2012www.i2p2.de server rent-100 €General fund
Jan, 2012www.i2p-projekt.de/echelon.i2p server rent-200 €General fund
Jan, 2012I2P services sponge-100 €General fund
Jan, 2012anonymous500 €General fund
Jan, 2012www.i2p2.de server rent-100 €{{ _('General fund') }}
Jan, 2012www.i2p-projekt.de/echelon.i2p server rent-200 €{{ _('General fund') }}
Jan, 2012I2P services sponge-100 €{{ _('General fund') }}
Jan, 2012anonymous500 €{{ _('General fund') }}

  
Jan, 2012anonymous1500 €Bounty Unit Tests
Jan, 2012anonymous30 €General fund
Jan, 2012anonymous10 €General fund
Jan, 2012anonymous0.01 BTCGeneral fund
Jan, 2012anonymous30 €{{ _('General fund') }}
Jan, 2012anonymous10 €{{ _('General fund') }}
Jan, 2012anonymous0.01 BTC{{ _('General fund') }}

  
Jan, 2012anonymous100 BTCBounty I2P bitcoin client

  
Jan, 2012anonymous20 €Bounty .deb package
Jan, 2012anonymous25 €General fund
Jan, 2012alu-anon20 €General fund
Jan, 2012maxkoda1.00 BTCGeneral fund
Jan, 2012anonymous25 €{{ _('General fund') }}
Jan, 2012alu-anon20 €{{ _('General fund') }}
Jan, 2012maxkoda1.00 BTC{{ _('General fund') }}

  
Jan, 2012maxkoda2.00 BTCBounty I2P BTC client
Feb, 2012DJ Eugene10 €General fund
Feb, 2012ZZZ new dev workstation522,02 €General fund
Feb, 2012anonymous15 €General fund
Feb, 2012anonymous91 €General fund
Feb, 2012Sponge dev machine52,3 €General fund
Feb, 2012anonymous30 €General fund
Feb, 2012anonymous22 €General fund
Feb, 2012domain cost11,9 €General fund
Feb, 2012domain cost11,9 €General fund
Feb, 2012anonymous1.4328 BTCGeneral fund
Feb, 2012anonymous1000.00 BTCGeneral fund
Feb, 2012anonymous2.20 BTCGeneral fund
Feb, 2012maxkoda1.00 BTCGeneral fund
Feb, 2012DJ Eugene10 €{{ _('General fund') }}
Feb, 2012ZZZ new dev workstation522,02 €{{ _('General fund') }}
Feb, 2012anonymous15 €{{ _('General fund') }}
Feb, 2012anonymous91 €{{ _('General fund') }}
Feb, 2012Sponge dev machine52,3 €{{ _('General fund') }}
Feb, 2012anonymous30 €{{ _('General fund') }}
Feb, 2012anonymous22 €{{ _('General fund') }}
Feb, 2012domain cost11,9 €{{ _('General fund') }}
Feb, 2012domain cost11,9 €{{ _('General fund') }}
Feb, 2012anonymous1.4328 BTC{{ _('General fund') }}
Feb, 2012anonymous1000.00 BTC{{ _('General fund') }}
Feb, 2012anonymous2.20 BTC{{ _('General fund') }}
Feb, 2012maxkoda1.00 BTC{{ _('General fund') }}

  
Feb, 2012maxkoda2.00 BTCBounty I2P BTC client
Mar, 2012Lautrec10 €General fund
Mar, 2012anonymous30 €General fund
Mar, 2012PayPal fees recalculated188,13 €General fund
Mar, 2012anonymous0.25 BTCGeneral fund
Mar, 2012anonymous2.00 BTCGeneral fund
Mar, 2012anonymous0.0000491 BTCGeneral fund
Mar, 2012Lautrec10 €{{ _('General fund') }}
Mar, 2012anonymous30 €{{ _('General fund') }}
Mar, 2012PayPal fees recalculated188,13 €{{ _('General fund') }}
Mar, 2012anonymous0.25 BTC{{ _('General fund') }}
Mar, 2012anonymous2.00 BTC{{ _('General fund') }}
Mar, 2012anonymous0.0000491 BTC{{ _('General fund') }}

  
Mar, 2012anonymous1500 €Bounty Unit Tests
Mar, 2012domain cost11,9 €General fund
Mar, 2012maxkoda1.01 BTCGeneral fund
Mar, 2012domain cost11,9 €{{ _('General fund') }}
Mar, 2012maxkoda1.01 BTC{{ _('General fund') }}

  
Mar, 2012maxkoda2.10 BTCBounty I2P BTC client
Apr, 2012anonymous100 €General fund
Apr, 2012anonymous30 €General fund
Apr, 2012anonymous0,50 €General fund
Apr, 2012anonymous0.10 BTCGeneral fund
Apr, 2012anonymous0.723 BTCGeneral fund
Apr, 2012anonymous100 €{{ _('General fund') }}
Apr, 2012anonymous30 €{{ _('General fund') }}
Apr, 2012anonymous0,50 €{{ _('General fund') }}
Apr, 2012anonymous0.10 BTC{{ _('General fund') }}
Apr, 2012anonymous0.723 BTC{{ _('General fund') }}
May, 2012anonymous0.01 BTCGeneral fund
May, 2012anonymous2.00 BTCGeneral fund
May, 2012anonymous1.50 BTCGeneral fund
May, 2012anonymous150 €General fund
May, 2012anonymous5 €General fund
May, 2012PayPal fees april11,94 €General fund
May, 2012anonymous0.01 BTC{{ _('General fund') }}
May, 2012anonymous2.00 BTC{{ _('General fund') }}
May, 2012anonymous1.50 BTC{{ _('General fund') }}
May, 2012anonymous150 €{{ _('General fund') }}
May, 2012anonymous5 €{{ _('General fund') }}
May, 2012PayPal fees april11,94 €{{ _('General fund') }}
May, 2012anonymous10 €General fund
May, 2012anonymous30 €General fund
May, 2012anonymous0.25 BTCGeneral fund
May, 2012anonymous0,69307046 BTCGeneral fund
May, 2012anonymous10 €{{ _('General fund') }}
May, 2012anonymous30 €{{ _('General fund') }}
May, 2012anonymous0.25 BTC{{ _('General fund') }}
May, 2012anonymous0,69307046 BTC{{ _('General fund') }}
Jun, 2012sell 100 BTC513.38 €100 BTCGeneral fund
Jun, 2012anonymous10 €General fund
Jun, 2012anonymous30 €General fund
Jun, 2012anonymous10 BTCGeneral fund
Jun, 2012MaxKoda1 BTCGeneral fund
Jun, 2012sell 100 BTC513.38 €100 BTC{{ _('General fund') }}
Jun, 2012anonymous10 €{{ _('General fund') }}
Jun, 2012anonymous30 €{{ _('General fund') }}
Jun, 2012anonymous10 BTC{{ _('General fund') }}
Jun, 2012MaxKoda1 BTC{{ _('General fund') }}

  
Jun, 2012maxkoda1 BTCBounty I2P BTC client
Jul, 2012anonymous10 €General fund
Jul, 2012anonymous30 €General fund
Jul, 2012anonymous1 BTCGeneral fund
Jul, 2012anonymous4 BTCGeneral fund
Jul, 2012anonymous10 €{{ _('General fund') }}
Jul, 2012anonymous30 €{{ _('General fund') }}
Jul, 2012anonymous1 BTC{{ _('General fund') }}
Jul, 2012anonymous4 BTC{{ _('General fund') }}
Aug, 2012anonymous10 €General fund
Aug, 2012anonymous30 €General fund
Aug, 2012anonymous96.04 €General fund
Aug, 2012anonymous10 €{{ _('General fund') }}
Aug, 2012anonymous30 €{{ _('General fund') }}
Aug, 2012anonymous96.04 €{{ _('General fund') }}
Sep, 2012anonymous30 €General fund
Sep, 2012anonymous30 €General fund
Sep, 2012Evgeny Ilin5 €General fund
Sep, 2012anonymous0.0001 BTCGeneral fund
Sep, 2012anonymous30 €{{ _('General fund') }}
Sep, 2012anonymous30 €{{ _('General fund') }}
Sep, 2012Evgeny Ilin5 €{{ _('General fund') }}
Sep, 2012anonymous0.0001 BTC{{ _('General fund') }}
Oct, 2012dJavid84fr30 €General fund
Oct, 2012anonymous1.11 €General fund
Oct, 2012anonymous20 €General fund
Oct, 2012anonymous30 €General fund
Oct, 2012anonymous1 €General fund
Oct, 2012dJavid84fr30 €{{ _('General fund') }}
Oct, 2012anonymous1.11 €{{ _('General fund') }}
Oct, 2012anonymous20 €{{ _('General fund') }}
Oct, 2012anonymous30 €{{ _('General fund') }}
Oct, 2012anonymous1 €{{ _('General fund') }}

  
Oct, 2012anonymous20 €Bounty Deb package

  
Oct, 2012anonymous5 €Bounty Robert

  
Oct, 2012anonymous20 €Bounty Robert

  
Oct, 2012anonymous10 BTCBounty Robert
Oct, 2012anonymous1 €General fund
Oct, 2012anonymous1 €{{ _('General fund') }}

  
Oct, 2012anonymous20 €Bounty Robert
Nov, 2012anonymous20 €General fund
Nov, 2012anonymous30 €General fund
Nov, 2012anonymous0.000666 BTCGeneral fund
Nov, 2012anonymous0.05025998 BTCGeneral fund
Nov, 2012anonymous1 BTCGeneral fund
Nov, 2012anonymous20 €{{ _('General fund') }}
Nov, 2012anonymous30 €{{ _('General fund') }}
Nov, 2012anonymous0.000666 BTC{{ _('General fund') }}
Nov, 2012anonymous0.05025998 BTC{{ _('General fund') }}
Nov, 2012anonymous1 BTC{{ _('General fund') }}

  
Nov, 2012maxkoda1 BTCBounty native I2P BTC client
Nov, 2012anonymous0.00064184 BTCGeneral fund
Mov, 2012anonymous0.01697271 BTCGeneral fund
Nov, 2012anonymous0.0005 BTCGeneral fund
Nov, 2012anonymous0.00064184 BTC{{ _('General fund') }}
Mov, 2012anonymous0.01697271 BTC{{ _('General fund') }}
Nov, 2012anonymous0.0005 BTC{{ _('General fund') }}

  
Nov, 2012anonymous16 €Robert Bounty

  
Nov, 2012anonymous40 €Robert Bounty

  
Nov, 2012I2P101 € & 10BTCRobert Bounty payout
Dec, 2012anonymous10 €General fund
Dec, 2012anonymous3 €General fund
Dec, 2012anonymous20 €General fund
Dec, 2012anonymous30 €General fund
Dec, 2012anonymous10 €General fund
Dec, 2012anonymous0.7 €General fund
Dec, 2012anonymous0.5 BTCGeneral fund
Dec, 2012anonymous0.0010 BTCGeneral fund
Dec, 2012anonymous0.5 BTCGeneral fund
Dec, 2012I2P100 BTCGeneral fund
Dec, 2012anonymous10 €{{ _('General fund') }}
Dec, 2012anonymous3 €{{ _('General fund') }}
Dec, 2012anonymous20 €{{ _('General fund') }}
Dec, 2012anonymous30 €{{ _('General fund') }}
Dec, 2012anonymous10 €{{ _('General fund') }}
Dec, 2012anonymous0.7 €{{ _('General fund') }}
Dec, 2012anonymous0.5 BTC{{ _('General fund') }}
Dec, 2012anonymous0.0010 BTC{{ _('General fund') }}
Dec, 2012anonymous0.5 BTC{{ _('General fund') }}
Dec, 2012I2P100 BTC{{ _('General fund') }}

  
Dec, 2012I2P100 BTCSyndie Bounty
Dec, 2012anonymous0.01234567 BTCGeneral fund
Dec, 2012anonymous0.01234567 BTCGeneral fund
Dec, 2012anonymous0.01234567 BTC{{ _('General fund') }}
Dec, 2012anonymous0.01234567 BTC{{ _('General fund') }}

  
  
 
 
 

 

 
-2011 donations and costs:

+{{ _('2011 donations and costs:') }}

 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
-   
- 
- 
- 
- 
- 
- 
+   
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
- 
+ 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
+ 
+ 
+ 
- 
- 
+ 
+ 
- 
- 
+ 
+ 
- 
- 
+ 
+ 
@@ -311,111 +320,111 @@ with your name or nick (and optionally homepage) so we can list you here.
 

  
datewhoincomeoutgoingaccount
Jan, 2011www.i2p2.de server rent-100 €General fund
Jan, 2011www.i2p-projekt.de/echelon.i2p server rent-200 €General fund
Jan, 2011PayPal fees 2010-40 €General fund
Jan, 2011refund of netstorage bounty,duck,smeghead700 €General fund
Jan, 2011woodchips50 BTCGeneral fund
Jan, 2011anonymous13 €General fund
Jan, 2011anonymous20 €General fund
Jan, 2011anonymous400 BTCGeneral fund
Jan, 2011Amiga40001000 BTCGeneral fund
Jan, 2011anonymous30 BTCGeneral fund
Jan, 2011Mozartito8 €General fund
Jan, 2011anonymous20 €General fund
Jan, 2011Flattr69,15 €General fund
Feb, 2011bv-falcon15 €General fund
Feb, 2011anonymous6,66 €General fund
Feb, 2011anonymous100 €General fund
Feb, 2011anonymous20 €General fund
Feb, 2011anonymous25 €General fund
Feb, 20113 domains 2011-36 €General fund
Feb, 2011anonymous33.41 BTCGeneral fund
Mar, 2011anonymous30 €General fund
Jan, 2011www.i2p2.de server rent-100 €{{ _('General fund') }}
Jan, 2011www.i2p-projekt.de/echelon.i2p server rent-200 €{{ _('General fund') }}
Jan, 2011PayPal fees 2010-40 €{{ _('General fund') }}
Jan, 2011refund of netstorage bounty,duck,smeghead700 €{{ _('General fund') }}
Jan, 2011woodchips50 BTC{{ _('General fund') }}
Jan, 2011anonymous13 €{{ _('General fund') }}
Jan, 2011anonymous20 €{{ _('General fund') }}
Jan, 2011anonymous400 BTC{{ _('General fund') }}
Jan, 2011Amiga40001000 BTC{{ _('General fund') }}
Jan, 2011anonymous30 BTC{{ _('General fund') }}
Jan, 2011Mozartito8 €{{ _('General fund') }}
Jan, 2011anonymous20 €{{ _('General fund') }}
Jan, 2011Flattr69,15 €{{ _('General fund') }}
Feb, 2011bv-falcon15 €{{ _('General fund') }}
Feb, 2011anonymous6,66 €{{ _('General fund') }}
Feb, 2011anonymous100 €{{ _('General fund') }}
Feb, 2011anonymous20 €{{ _('General fund') }}
Feb, 2011anonymous25 €{{ _('General fund') }}
Feb, 20113 domains 2011-36 €{{ _('General fund') }}
Feb, 2011anonymous33.41 BTC{{ _('General fund') }}
Mar, 2011anonymous30 €{{ _('General fund') }}

  
Mar, 2011h2ik23 €I2P deb in debian mirrors
 
  
Mar, 2011h2ik50 €IPv6 Bounty

  
Mar, 2011hamada-80 BTCArabic routerconsole
Mar, 2011anonymous63.01 BTCGeneral fund
Apr, 2011I2P745.84 €-1000 BTCGeneral fund
Apr, 2011anonymous30 €General fund
Apr, 2011anonymous10 €General fund
Apr, 2011magma100 €General fund
Apr, 2011I2P services sponge-100 €General fund
Apr, 2011anonymous20 €General fund
Mar, 2011anonymous63.01 BTC{{ _('General fund') }}
Apr, 2011I2P745.84 €-1000 BTC{{ _('General fund') }}
Apr, 2011anonymous30 €{{ _('General fund') }}
Apr, 2011anonymous10 €{{ _('General fund') }}
Apr, 2011magma100 €{{ _('General fund') }}
Apr, 2011I2P services sponge-100 €{{ _('General fund') }}
Apr, 2011anonymous20 €{{ _('General fund') }}

  
Apr, 2011anonymous50 €I2P debian package bounty
Apr, 2011anonymous10 €General fund
Apr, 2011anonymous10 €General fund
Apr, 2011anonymous0.06 BTCGeneral fund
May, 2011anonymous30 €General fund
May, 2011anonymous5 €General fund
May, 2011anonymous20 €General fund
May, 2011anonymous10 €General fund
May, 2011Max Koda10 BTCGeneral fund
May, 2011anonymous1.180001 BTCGeneral fund
Apr, 2011anonymous10 €{{ _('General fund') }}
Apr, 2011anonymous10 €{{ _('General fund') }}
Apr, 2011anonymous0.06 BTC{{ _('General fund') }}
May, 2011anonymous30 €{{ _('General fund') }}
May, 2011anonymous5 €{{ _('General fund') }}
May, 2011anonymous20 €{{ _('General fund') }}
May, 2011anonymous10 €{{ _('General fund') }}
May, 2011Max Koda10 BTC{{ _('General fund') }}
May, 2011anonymous1.180001 BTC{{ _('General fund') }}

  
May, 2011ZZZ250.06 €trimslice dev device for ZZZ

  
Jun, 2011An anonymous secret society society@mail.i2p200 €SILC bounty
Jun, 2011Flattr104 €General fund
Jun, 2011anonymous30 €General fund
Jun, 2011anonymous3 €General fund
Jun, 2011anonymous-13.6 BTCGeneral fund
Jun, 2011anonymous22.5 BTCGeneral fund
Jun, 2011Flattr104 €{{ _('General fund') }}
Jun, 2011anonymous30 €{{ _('General fund') }}
Jun, 2011anonymous3 €{{ _('General fund') }}
Jun, 2011anonymous-13.6 BTC{{ _('General fund') }}
Jun, 2011anonymous22.5 BTC{{ _('General fund') }}

  
Jul, 2011hamada-20 BTCarabic bounty
Jul, 2011anonymous0.2 BTCGeneral fund
Jul, 2011anonymous0.2 BTC{{ _('General fund') }}

  
Jul, 2011psychonaut30 €Bitcoin client bounty
Jul, 2011anonymous30 €General fund
Jul, 2011anonymous5 GBPGeneral fund
Jul, 2011anonymous10 €General fund
Jul, 2011anonymous10 €General fund
Aug, 2011anonymous30 €General fund
Aug, 2011An anonymous secret society society@mail.i2p20 €General fund
Aug, 2011anonymous15 €General fund
Jul, 2011anonymous30 €{{ _('General fund') }}
Jul, 2011anonymous5 GBP{{ _('General fund') }}
Jul, 2011anonymous10 €{{ _('General fund') }}
Jul, 2011anonymous10 €{{ _('General fund') }}
Aug, 2011anonymous30 €{{ _('General fund') }}
Aug, 2011An anonymous secret society society@mail.i2p20 €{{ _('General fund') }}
Aug, 2011anonymous15 €{{ _('General fund') }}

  
Aug, 2011ZZZ$150 UStravel expenses for ZZZ
Sep, 2011anonymous30 €General fund
Sep, 2011anonymous5 €General fund
Sep, 2011maxkoda.i2p1.303 BTCGeneral fund
Sep, 2011anonymous1.2 BTCGeneral fund
Oct, 2011anonymous12.1347 BTCGeneral fund
Oct, 2011anonymous30 €General fund
Oct, 2011anonymous20 €General fund
Oct, 2011anonymous5 €General fund
Oct, 2011anonymous10 €General fund
Oct, 2011anonymous5 €General fund
Oct, 2011uglic30 €General fund
Oct, 2011anonymous10 €General fund
Oct, 2011vention73 €General fund
Oct, 2011anonymous20 €General fund
Sep, 2011anonymous30 €{{ _('General fund') }}
Sep, 2011anonymous5 €{{ _('General fund') }}
Sep, 2011maxkoda.i2p1.303 BTC{{ _('General fund') }}
Sep, 2011anonymous1.2 BTC{{ _('General fund') }}
Oct, 2011anonymous12.1347 BTC{{ _('General fund') }}
Oct, 2011anonymous30 €{{ _('General fund') }}
Oct, 2011anonymous20 €{{ _('General fund') }}
Oct, 2011anonymous5 €{{ _('General fund') }}
Oct, 2011anonymous10 €{{ _('General fund') }}
Oct, 2011anonymous5 €{{ _('General fund') }}
Oct, 2011uglic30 €{{ _('General fund') }}
Oct, 2011anonymous10 €{{ _('General fund') }}
Oct, 2011vention73 €{{ _('General fund') }}
Oct, 2011anonymous20 €{{ _('General fund') }}

  
Oct, 20114get163 €RU translation delayed payment
Nov, 2011anonymous30 €General fund
Nov, 2011anonymous10 €General fund
Nov, 2011Daniel Liabeuf20 €General fund
Nov, 2011anonymous30 €{{ _('General fund') }}
Nov, 2011anonymous10 €{{ _('General fund') }}
Nov, 2011Daniel Liabeuf20 €{{ _('General fund') }}

  
Nov, 2011anonymous15 €Bounty eepsites in datastorage

  
Nov, 2011maxkoda5.23 BTCbounty BTC client in I2P
Nov, 2011anonymous0.512 BTCGeneral fund
Dec, 2011anonymous30 €General fund
Nov, 2011anonymous0.512 BTC{{ _('General fund') }}
Dec, 2011anonymous30 €{{ _('General fund') }}

  
  
Dec, 2011silc bounty100 €ReturningNovice
Dec, 2011silc bounty100 €General fund
Dec, 2011ReturningNovice50 €General fund
Dec, 2011silc bounty100 €{{ _('General fund') }}
Dec, 2011ReturningNovice50 €{{ _('General fund') }}

  
Dec, 2011ReturningNovice50 €Sponge
Dec, 2011anonymous5 €General fund
Dec, 2011anonymous5 €General fund
Dec, 2011anonymous5 €{{ _('General fund') }}
Dec, 2011anonymous5 €{{ _('General fund') }}

  
Dec, 2011maxkoda5.01 BTCbounty BTC client in I2P

  
Dec, 2011anonymous0.4825475 BTCSponge

  
Dec, 2011anonymous5,54436182 BTCgeneral fund
 
 

 

-Previous to 2011 donations:

+{{ _('Previous to 2011 donations:') }}

 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
  
- 
- 
- 
+ 
+ 
+ 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
- 
+ 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
+ 
+ 
+ 
- 
+ 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
+ 
+ 
+ 
diff --git a/www.i2p2/pages/intro.html b/i2p2www/pages/site/about/intro.html
similarity index 61%
rename from www.i2p2/pages/intro.html
rename to i2p2www/pages/site/about/intro.html
index 3af01ef8..4516f101 100644
--- a/www.i2p2/pages/intro.html
+++ b/i2p2www/pages/site/about/intro.html
@@ -1,8 +1,9 @@
-{% extends "_layout.html" %}
-{% block title %}Intro{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Intro') }}{% endblock %}
 {% block content %}
-
The Invisible Internet Project (I2P)
      
-
I2P is an anonymous network, exposing a simple layer that applications can 
+
{{ _('The Invisible Internet Project') }} (I2P)
      
+
{% trans -%}
+I2P is an anonymous network, exposing a simple layer that applications can 
 use to anonymously and securely send messages to each other. The network itself is 
 strictly message based (a la 
 IP), but there is a 
@@ -10,12 +11,14 @@ library available to allow reliable streaming communication on top of it (a la
 TCP).  
 All communication is end to end encrypted (in total there are four layers of 
 encryption used when sending a message), and even the end points ("destinations") 
-are cryptographic identifiers (essentially a pair of public keys).

+are cryptographic identifiers (essentially a pair of public keys).
+{%- endtrans %}

 
-
How does it work?

+
{{ _('How does it work?') }}

 
-
To anonymize the messages sent, each client application has their I2P "router"
-build a few inbound and outbound "tunnels" - a 
+
{% trans tunnelrouting=site_url('docs/how/tunnel-routing') -%}
+To anonymize the messages sent, each client application has their I2P "router"
+build a few inbound and outbound "tunnels" - a 
 sequence of peers that pass messages in one direction (to and from the client, 
 respectively).  In turn, when a client wants to send a message to another client, 
 the client passes that message out one of their outbound tunnels targeting one of the 
@@ -24,30 +27,38 @@ participant in the network chooses the length of these tunnels, and in doing so,
 makes a tradeoff between anonymity, latency, and throughput according to their 
 own needs.  The result is that the number of peers relaying each end to end 
 message is the absolute minimum necessary to meet both the sender's and the 
-receiver's threat model.

+receiver's threat model.
+{%- endtrans %}

 
-
The first time a client wants to contact another client, they make a query 
-against the fully distributed "network 
+
{% trans netdb=site_url('docs/how/network-database') -%}
+The first time a client wants to contact another client, they make a query 
+against the fully distributed "network 
 database" - a custom structured 
 distributed hash table (DHT) based off the 
  Kademlia algorithm. This is done 
 to find the other client's inbound tunnels efficiently, but subsequent messages 
 between them usually includes that data so no further network database lookups 
-are required.

-  
-
More details about how I2P works are available.

+are required.
+{%- endtrans %}

 
-
What can you do with it?

+
{% trans docs=site_url('docs') -%}
+More details about how I2P works are available.
+{%- endtrans %}

 
-
Within the I2P network, applications are not restricted in how they can 
+
{{ _('What can you do with it?') }}

+
+
{% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
+Within the I2P network, applications are not restricted in how they can 
 communicate - those that typically use UDP can make use of the base I2P 
 functionality, and those that typically use TCP can use the TCP-like streaming
 library.  We have a generic TCP/I2P bridge application 
-("I2PTunnel") that enables people to forward TCP streams
+("I2PTunnel") that enables people to forward TCP streams
 into the I2P network as well as to receive streams out of the network and 
-forward them towards a specific TCP/IP address.

+forward them towards a specific TCP/IP address.
+{%- endtrans %}

 
-
I2PTunnel is currently used to let people run their own anonymous website 
+
{% trans -%}
+I2PTunnel is currently used to let people run their own anonymous website 
 ("eepsite") by running a normal webserver and pointing an I2PTunnel 'server' 
 at it, which people can access anonymously over I2P with a normal web browser 
 by running an I2PTunnel HTTP proxy ("eepproxy").  In addition, we use the same 
@@ -55,13 +66,15 @@ technique to run an anonymous IRC network (where the IRC server is hosted
 anonymously, and standard IRC clients use an I2PTunnel to contact it).  There 
 are other application development efforts going on as well, such as one to 
 build an optimized swarming file transfer application (a la 
-BitTorrent), a 
-distributed data store (a la Freenet / 
+BitTorrent), a 
+distributed data store (a la Freenet / 
 MNet), and a blogging system (a fully 
 distributed LiveJournal), but those are 
-not ready for use yet.

+not ready for use yet.
+{%- endtrans %}

 
-
I2P is not inherently an "outproxy" network - the client you send a message 
+
{% trans -%}
+I2P is not inherently an "outproxy" network - the client you send a message 
 to is the cryptographic identifier, not some IP address, so the message must 
 be addressed to someone running I2P.  However, it is possible for that client
 to be an outproxy, allowing you to anonymously make use of their Internet 
@@ -71,16 +84,21 @@ that runs a squid HTTP proxy, allowing
 simple anonymous browsing of the normal web.  Simple outproxies like that are 
 not viable in the long run for several reasons (including the cost of running 
 one as well as the anonymity and security issues they introduce), but in 
-certain circumstances the technique could be appropriate.

+certain circumstances the technique could be appropriate.
+{%- endtrans %}

 
-
The I2P development team is an open group, welcome to all 
-who are interested in getting involved, and all of 
-the code is open source.  The core I2P SDK and the 
+
{% trans team=site_url('about/team'), volunteer=site_url('get-involved'),
+licenses=site_url('get-involved/develop/licenses'), sam=site_url('docs/api/sam'),
+roadmap=site_url('get-involved/roadmap') -%}
+The I2P development team is an open group, welcome to all 
+who are interested in getting involved, and all of 
+the code is open source.  The core I2P SDK and the 
 current router implementation is done in Java (currently working with both 
 sun and kaffe, gcj support planned for later), and there is a 
-simple socket based API for accessing the network from 
+simple socket based API for accessing the network from 
 other languages (with a C library available, and both Python and Perl in 
 development).  The network is actively being developed and has not yet reached 
-the 1.0 release, but the current roadmap describes 
-our schedule.

-{% endblock %}
\ No newline at end of file
+the 1.0 release, but the current roadmap describes 
+our schedule.
+{%- endtrans %}

+{% endblock %}
diff --git a/i2p2www/pages/site/about/media.html b/i2p2www/pages/site/about/media.html
new file mode 100644
index 00000000..641326da
--- /dev/null
+++ b/i2p2www/pages/site/about/media.html
@@ -0,0 +1,221 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Presentations on I2P') }}{% endblock %}
+{% block content %}
+
{{ _('Presentations on I2P') }}

+
{% trans papers=site_url('research/papers') -%}
+Following are links to presentations, videos, and tutorials about I2P. Links to research papers on I2P are available here.
+{%- endtrans %}

+
{% trans email='press ~~~at~~~ i2p2.de' -%}
+To request an addition to this page, please send to {{ email }}.
+{%- endtrans %}

+
{% trans %}
+Newest links are at the bottom of each section.
+{%- endtrans %}

+

+
+
{{ _('Presentations') }}

+
    
+
+
  • {% trans mp3='http://invisibleip.sourceforge.net/iip/resources/codecon_0x90.mp3',
+transcript='http://invisibleip.sourceforge.net/iip/resources/iip_transcript.txt' -%}
+IIP Presentation at CodeCon
+MP3 audio
+transcript
+Lance James (0x90), February 2002.
+{%- endtrans %}
    • 
+
+
  • {% trans mp3='http://invisibleip.sourceforge.net/iip/resources/toorconspeech.mp3',
+slides='http://invisibleip.sourceforge.net/iip/resources/toorconspeech/' -%}
+IIP Presentation at ToorCon
+MP3 audio
+slides
+Lance James (0x90), September 2002.
+{%- endtrans %}
    • 
+
+
  • {% trans video='http://www.youtube.com/watch?v=TsfdzfGZyu0',
+pdf='http://events.ccc.de/congress/2007/Fahrplan/attachments/1017_24c3-i2p.pdf' -%}
+To Be or I2P
+(Youtube Video)
+An introduction into anonymous communication with I2P.
+To Be or I2P (PDF presentation),
+Jens Kubieziel, 24C3 Berlin, December 28, 2007.
+{%- endtrans %}
    • 
+
+
  • {% trans video='http://marge.informatik.tu-chemnitz.de/archiv/CLT2009/V4-Sa1200-Security-Lars_Schimmer.mp4' -%}
+Video of I2P talk at Chemnitz Linux Tag,
+Lars Schimmer,
+March 14-15, 2009
+{%- endtrans %}
    • 
+
+
  • {% trans mp3='http://c2047862.cdn.cloudfiles.rackspacecloud.com/tnhc21.mp3' -%}
+HOPE New York July 17, 2010 - Brief overview of I2P by zzz, at the end of Adrian Hong's talk
+"Hackers for Human Rights".
+MP3 audio
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.irongeek.com/i.php?page=videos/shmoocon-firetalks-2011' -%}
+Into the I2P Darknet: Welcome to Cipherspace
+Adrian Crenshaw. Schmoocon Firetalk, January 2011
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.youtube.com/watch?v=TexNr_5J5AU' -%}
+Using techhnology to advance liberty
+(Youtube Video)
+Eric Johnson.
+Agora I/O Unconference, March 27, 2011.
+I2P covered from 10:00 to 20:00 in the video.
+{%- endtrans %}
    • 
+
+
  • {% trans pdf='http://patras.fosscomm.gr/talks/BSoD_Pub.pdf' -%}
+The Bright side of darknets, FOSSCOMM Patras May 2011
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.youtube.com/watch?v=bI_1qlcwfE0' -%}
+Common Darknet Weaknesses
+(Youtube Video)
+Adrian Crenshaw, AIDE, July 11-15, 2011.
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.irongeek.com/i.php?page=security/i2p-tor-workshop-notes' -%}
+I2P / Tor Workshop Notes
+Adrian Crenshaw. DEF CON 19, Las Vegas, August 6, 2011.
+{%- endtrans %}
    • 
+
+
  • {% trans live='http://www.youtube.com/watch?v=xxKXkbohRZM',
+studio='http://www.youtube.com/watch?v=xFxJ6Dc5ass',
+slides='http://www.irongeek.com/downloads/Adrian-Crenshaw-darknet-weaknesses.pptx' -%}
+Cipherspaces/Darknets: An Overview Of Attack Strategies -
+DEF CON Live version (Youtube Video),
+"Studio" version (Youtube Video),
+Slides (ppt)
+Adrian Crenshaw. DEF CON 19, Las Vegas, August 7, 2011.
+{%- endtrans %}
    • 
+
+
  • {% trans -%}
+Modern cipherspace ecosystems, 0x375 0x06 4/11/2011
+{%- endtrans %}
    • 
+
+

+
+
{{ _('Tutorials') }}

+
    
+
+
  • {% trans link='http://www.youtube.com/watch?v=5J3nh1DoRMw' -%}
+I2P Windows Tutorial
+(Youtube Video)
+This guide will show you how to install I2P in Windows XP.
+By Telecomix
+{%- endtrans %}
    • 
+
+
  • 
+
  • {% trans link='http://www.youtube.com/watch?v=QeRN2G9VW5E' -%}
+I2P Debian Tutorial
+(Youtube Video)
+This will guide you through how to install I2P on a Debian Linux System.
+By Telecomix
+{%- endtrans %}
    • 
+
+
  • 
+
  • {% trans link='http://www.youtube.com/watch?v=2ylW85vc7SA' -%}
+How to set up anonymous site in I2P
+(Youtube Video)
+How to set up an anonymous web site in I2P.
+By Telecomix
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.youtube.com/watch?v=d8mvGZqVgE4' -%}
+I2P Tutorial Mac OS X
+(Youtube Video)
+A tutorial on how to run i2p on Mac OS X and how to connect to irc.telecomix.i2p.
+By Telecomix
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.youtube.com/watch?v=5jv7tVVJdTQ' -%}
+Felix Atari explains the basic principles of I2P
+(Youtube Video)
+Agent Felix Atari of the Telecomix Crypto Munitions Bureau.
+By Telecomix
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.youtube.com/watch?v=WyN_QK-_3GA' -%}
+How to get onto I2P, the anonymous P2P Darknet (Windows Install)
+(Youtube Video)
+This tutorial shows how to install and configure software needed to access I2P.
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.youtube.com/watch?v=q4owyd_CaGc' -%}
+How to connect to I2P
+(Youtube Video)
+How to install I2P on Ubuntu.
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.irongeek.com/i.php?page=videos/i2p-darknet-software-in-linux' -%}
+Installing the I2P darknet software in Linux
+(Video)
+Adrian Crenshaw.
+January 2011
+{%- endtrans %}
    • 
+
+
  • {% trans link='http://www.youtube.com/watch?v=NV90TRs_pGE' -%}
+Short garlic routing animation
+(Youtube Video)
+Adrian Crenshaw.
+{% endtrans %}
    • 
+
+

+
+
{{ _('Articles and Interviews') }}

+

+{% endblock %}
diff --git a/www.i2p2/pages/performance.html b/i2p2www/pages/site/about/performance/future.html
similarity index 58%
rename from www.i2p2/pages/performance.html
rename to i2p2www/pages/site/about/performance/future.html
index c104206e..41be263c 100644
--- a/www.i2p2/pages/performance.html
+++ b/i2p2www/pages/site/about/performance/future.html
@@ -1,42 +1,47 @@
-{% extends "_layout.html" %}
-{% block title %}Performance{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Future Performance Improvements') }}{% endblock %}
 {% block content %}
-Updated August 2010, current as of router version 0.8
+{% block lastupdated %}{{ _('August 2010') }}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
 
-
Probably one of the most frequent things people ask is "how fast is I2P?",
-and no one seems to like the answer - "it depends".  After trying out I2P, the
-next thing they ask is "will it get faster?", and the answer to that is a most
-emphatic yes.

-
There are a few major techniques that can be done to improve the perceived
+
{% trans -%}
+There are a few major techniques that can be done to improve the perceived
 performance of I2P - some of the following are CPU related, others bandwidth
 related, and others still are protocol related.  However, all of those
 dimensions affect the latency, throughput, and perceived performance of the
 network, as they reduce contention for scarce resources.  This list is of course
-not comprehensive, but it does cover the major ones that are seen.

-
For past performance improvements see the 
+not comprehensive, but it does cover the major ones that are seen.
+{%- endtrans %}

+
{% trans history=site_url('about/performance/history') -%}
+For past performance improvements see the 
 Performance History.
+{%- endtrans %}

 
-
Better peer profiling and selection

-
Probably one of the most important parts of getting faster performance will
+
{{ _('Better peer profiling and selection') }}

+
{% trans sybilpdf='http://www.cs.rice.edu/Conferences/IPTPS02/101.pdf'-%}
+Probably one of the most important parts of getting faster performance will
 be improving how routers choose the peers that they build their tunnels through
 - making sure they don't use peers with slow links or ones with fast links that
 are overloaded, etc.  In addition, we've got to make sure we don't expose
-ourselves to a
-Sybil attack
-from a powerful adversary with lots of fast machines. 

+ourselves to a Sybil attack
+from a powerful adversary with lots of fast machines.
+{%- endtrans %}

 
-
Network database tuning

-
We're going to want to be more efficient with the network database's healing
+
{{ _('Network database tuning') }}

+
{% trans -%}
+We're going to want to be more efficient with the network database's healing
 and maintenance algorithms - rather than constantly explore the keyspace for new
 peers - causing a significant number of network messages and router load - we
 can slow down or even stop exploring until we detect that there's something new
 worth finding (e.g. decay the exploration rate based upon the last time someone
 gave us a reference to someone we had never heard of).  We can also do some
 tuning on what we actually send - how many peers we bounce back (or even if we
-bounce back a reply), as well as how many concurrent searches we perform.

+bounce back a reply), as well as how many concurrent searches we perform.
+{%- endtrans %}

 
-
Session Tag Tuning and Improvements

-
The way the ElGamal/AES+SessionTag algorithm
+
{{ _('Session Tag Tuning and Improvements') }}

+
{% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
+The way the ElGamal/AES+SessionTag algorithm
 works is by managing a set of random one-time-use 32 byte arrays, and expiring
 them if they aren't used quickly enough.  If we expire them too soon, we're
 forced to fall back on a full (expensive) ElGamal encryption, but if we don't
@@ -45,15 +50,17 @@ run out of memory (and if the recipient somehow gets corrupted and loses some
 tags, even more encryption failures may occur prior to detection).  With some
 more active detection and feedback driven algorithms, we can safely and more
 efficiently tune the lifetime of the tags, replacing the ElGamal encryption with
-a trivial AES operation.

-

+a trivial AES operation.
+{%- endtrans %}

+
{% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
 Additional ideas for improving Session Tag delivery are described on the
-ElGamal/AES+SessionTag page.
-

+ElGamal/AES+SessionTag page.
+{%- endtrans %}

 
 
-
Migrate sessionTag to synchronized PRNG

-
Right now, our ElGamal/AES+SessionTag 
+
{{ _('Migrate sessionTag to synchronized PRNG') }}

+
{% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
+Right now, our ElGamal/AES+SessionTag 
 algorithm works by tagging each encrypted message with a unique random 
 32 byte nonce (a "session tag"), identifying that message as being encrypted 
 with the associated AES session's key. This prevents peers from distinguishing 
@@ -62,8 +69,10 @@ new random tag. To accomplish this, every few messages bundle a whole
 new set of session tags within the encrypted message itself, transparently 
 delivering a way to identify future messages. We then have to keep track 
 of what messages are successfully delivered so that we know what tags 
-we may use.

-
This works fine and is fairly robust, however it is inefficient in terms 
+we may use.
+{%- endtrans %}

+
{% trans -%}
+This works fine and is fairly robust, however it is inefficient in terms 
 of bandwidth usage, as it requires the delivery of these tags ahead of 
 time (and not all tags may be necessary, or some may be wasted, due to 
 their expiration). On average though, predelivering the session tag costs 
@@ -72,53 +81,77 @@ size can be avoided by replacing the delivery of the tags with a synchronized
 PRNG - when a new session is established (through an ElGamal encrypted 
 block), both sides seed a PRNG for use and generate the session tags on 
 demand (with the recipient precalculating the next few possible values 
-to handle out of order delivery).

+to handle out of order delivery).
+{%- endtrans %}

 
-
Longer lasting tunnels

-
The current default tunnel duration of 10 minutes is fairly arbitrary, though
+
{{ _('Longer lasting tunnels') }}

+
{% trans -%}
+The current default tunnel duration of 10 minutes is fairly arbitrary, though
 it "feels okay".  Once we've got tunnel healing code and more effective failure
 detection, we'll be able to more safely vary those durations, reducing the
-network and CPU load (due to expensive tunnel creation messages).

+network and CPU load (due to expensive tunnel creation messages).
+{%- endtrans %}

 
-

+
{% trans -%}
 This appears to be an easy fix for high load on the big-bandwidth routers, but
 we should not resort to it until we've tuned the tunnel building algorithms further.
 However, the 10 minute tunnel lifetime is hardcoded in quite a few places,
 so substantial effort would be required to change the duration.
 Also, it would be difficult to maintain backward compatibility with such a change.
-

+{%- endtrans %}

+
{% trans -%}
 Currently, since the network average tunnel build success rate is fairly high,
 there are no current plans to extend tunnel lifetime.
-

+{%- endtrans %}

 
 
-
Adjust the timeouts

-
Yet another of the fairly arbitrary but "okay feeling" things we've got are the
+
{{ _('Adjust the timeouts') }}

+
{% trans -%}
+Yet another of the fairly arbitrary but "okay feeling" things we've got are the
 current timeouts for various activities.  Why do we have a 60 second "peer
 unreachable" timeout?  Why do we try sending through a different tunnel that a
 LeaseSet advertises after 10 seconds?  Why are the network database queries
 bounded by 60 or 20 second limits?  Why are destinations configured to ask for a
 new set of tunnels every 10 minutes?  Why do we allow 60 seconds for a peer to
 reply to our request that they join a tunnel?  Why do we consider a tunnel that
-doesn't pass our test within 60 seconds "dead"?

-
Each of those imponderables can be addressed with more adaptive code, as well
+doesn't pass our test within 60 seconds "dead"?
+{%- endtrans %}

+
{% trans -%}
+Each of those imponderables can be addressed with more adaptive code, as well
 as tunable parameters to allow for more appropriate tradeoffs between
-bandwidth, latency, and CPU usage.

+bandwidth, latency, and CPU usage.
+{%- endtrans %}

 
-
Full streaming protocol improvements

+
{{ _('Full streaming protocol improvements') }}

-

+
{% trans streaming=site_url('docs/api/streaming') -%}
 Additional ideas for improving the streaming library are described on the
-streaming library page.
-

+streaming library page.
+{%- endtrans %}

 {% endblock %}
diff --git a/www.i2p2/pages/performance-history.html b/i2p2www/pages/site/about/performance/history.html
similarity index 62%
rename from www.i2p2/pages/performance-history.html
rename to i2p2www/pages/site/about/performance/history.html
index a65fe726..59f92ba9 100644
--- a/www.i2p2/pages/performance-history.html
+++ b/i2p2www/pages/site/about/performance/history.html
@@ -1,30 +1,43 @@
-{% extends "_layout.html" %}
-{% block title %}Performance History{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Performance History') }}{% endblock %}
 {% block content %}
-
Notable performance improvements have been made using the techniques below.
-There is more to do, see the Performance page
-for current issues and thoughts.

+
{% trans performance=site_url('about/performance') -%}
+Notable performance improvements have been made using the techniques below.
+There is more to do, see the Performance page
+for current issues and thoughts.
+{%- endtrans %}

 
-
Native math [implemented]

-
When I last profiled the I2P code, the vast majority of time was spent within
+
{{ _('Native math') }}

+[{{ _('implemented') }}]
+
{% trans modpow='http://docs.oracle.com/javase/1.4.2/docs/api/java/math/BigInteger.html#modPow(java.math.BigInteger,%20java.math.BigInteger)',
+gmp='http://gmplib.org/',
+jbigi=site_url('misc/jbigi') -%}
+When I last profiled the I2P code, the vast majority of time was spent within
 one function: java.math.BigInteger's
-modPow.
+modPow.
 Rather than try to tune this method, we'll call out to
-GNU MP - an insanely fast math library
+GNU MP - an insanely fast math library
 (with tuned assembler for many architectures). (Editor: see
-NativeBigInteger for faster public key cryptography)

-
ugha and duck are working on the C/JNI glue code, and the existing java code
+NativeBigInteger for faster public key cryptography)
+{%- endtrans %}

+
{% trans %}
+ugha and duck are working on the C/JNI glue code, and the existing java code
 is already deployed with hooks for that whenever its ready.  Preliminary results
 look fantastic - running the router with the native GMP modPow is providing over
 a 800% speedup in encryption performance, and the load was cut in half.  This
 was just on one user's machine, and things are nowhere near ready for packaging
-and deployment, yet.

+and deployment, yet.
+{%- endtrans %}

 
-
Garlic wrapping a "reply" LeaseSet [implemented but needs tuning]

-
This algorithm tweak will only be relevant for applications that want their
+
{% trans %}Garlic wrapping a "reply" LeaseSet{% endtrans %}

+[{{ _('implemented but needs tuning') }}]
+
{% trans -%}
+This algorithm tweak will only be relevant for applications that want their
 peers to reply to them (though that includes everything that uses I2PTunnel or
-mihi's ministreaming lib):

-
Previously, when Alice sent Bob a message, when Bob replied he had to do a
+mihi's ministreaming lib):
+{%- endtrans %}

+
{% trans -%}
+Previously, when Alice sent Bob a message, when Bob replied he had to do a
 lookup in the network database - sending out a few requests to get Alice's
 current LeaseSet.  If he already has Alice's current LeaseSet, he can instead
 just send his reply immediately - this is (part of) why it typically takes a
@@ -36,20 +49,24 @@ stored - completely removing any need for a network database lookup on replies.
 This trades off a large portion of the sender's bandwidth for that faster reply.
 If we didn't do this very often,
 overall network bandwidth usage would decrease, since the recipient doesn't
-have to do the network database lookup.

-

+have to do the network database lookup.
+{%- endtrans %}

+
{% trans -%}
 For unpublished LeaseSets such as "shared clients", this is the only way to
 get the LeaseSet to Bob. Unfortunately this bundling every time adds
 almost 100% overhead to a high-bandwidth connection, and much more to
 a connection with smaller messages.
-

+{%- endtrans %}

+
{% trans -%}
 Changes scheduled for release 0.6.2 will bundle the LeaseSet only when
 necessary, at the beginning of a connection or when the LeaseSet changes.
 This will substantially reduce the total overhead of I2P messaging.
-

+{%- endtrans %}

 
-
More efficient TCP rejection [implemented]

-
At the moment, all TCP connections do all of their peer validation after
+
{{ _('More efficient TCP rejection') }}

+[{{ _('implemented') }}]
+
{% trans -%}
+At the moment, all TCP connections do all of their peer validation after
 going through the full (expensive) Diffie-Hellman handshaking to negotiate a
 private session key.  This means that if someone's clock is really wrong, or
 their NAT/firewall/etc is improperly configured (or they're just running an
@@ -58,37 +75,49 @@ constantly, thanks to the shitlist) cause a futile expensive cryptographic
 operation on all the peers they know about.  While we will want to keep some
 verification/validation within the encryption boundary, we'll want to update the
 protocol to do some of it first, so that we can reject them cleanly
-without wasting much CPU or other resources.

+without wasting much CPU or other resources.
+{%- endtrans %}

 
-
Adjust the tunnel testing [implemented]

-
Rather than going with the fairly random scheme we have now, we should use a
+
{{ _('Adjust the tunnel testing') }}

+[{{ _('implemented') }}]
+
{% trans -%}
+Rather than going with the fairly random scheme we have now, we should use a
 more context aware algorithm for testing tunnels.  e.g. if we already know its
 passing valid data correctly, there's no need to test it, while if we haven't
 seen any data through it recently, perhaps its worthwhile to throw some data its
 way.  This will reduce the tunnel contention due to excess messages, as well as
-improve the speed at which we detect - and address - failing tunnels.

+improve the speed at which we detect - and address - failing tunnels.
+{%- endtrans %}

 
-
Persistent Tunnel / Lease Selection

-
Outbound tunnel selection implemented in 0.6.1.30, inbound lease selection 
-implemented in release 0.6.2.

-
Selecting tunnels and leases at random for every message creates a large 
+
{{ _('Persistent Tunnel / Lease Selection') }}

+
{% trans -%}
+Outbound tunnel selection implemented in 0.6.1.30, inbound lease selection 
+implemented in release 0.6.2.
+{%- endtrans %}

+
{% trans -%}
+Selecting tunnels and leases at random for every message creates a large 
 incidence of out-of-order delivery, which prevents the streaming lib from 
 increasing its window size as much as it could. By persisting with the 
 same selections for a given connection, the transfer rate is much faster. 
-

+{%- endtrans %}

 
-
Compress some data structures [implemented]

-
The I2NP messages and the data they contain is already defined in a fairly
+
{{ _('Compress some data structures') }}

+[{{ _('implemented') }}]
+
{% trans -%}
+The I2NP messages and the data they contain is already defined in a fairly
 compact structure, though one attribute of the RouterInfo structure is not -
 "options" is a plain ASCII name = value mapping.  Right now, we're filling it
 with those published statistics - around 3300 bytes per peer.  Trivial to
 implement GZip compression would nearly cut that to 1/3 its size, and when you
 consider how often RouterInfo structures are passed across the network, that's
 significant savings - every time a router asks another router for a networkDb
-entry that the peer doesn't have, it sends back 3-10 RouterInfo of them.

+entry that the peer doesn't have, it sends back 3-10 RouterInfo of them.
+{%- endtrans %}

 
-
Update the ministreaming protocol
 [replaced by full streaming protocol]
-
Currently mihi's ministreaming library has a fairly simple stream negotiation
+
{{ _('Update the ministreaming protocol') }}

+[{{ _('replaced by full streaming protocol') }}]
+
{% trans -%}
+Currently mihi's ministreaming library has a fairly simple stream negotiation
 protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then
 Alice and Bob send each other some data, until one of them sends the other a
 CLOSE message.  For long lasting connections (to an IRC server, for instance),
@@ -97,22 +126,27 @@ that overhead is negligible, but for simple one-off request/response situations
 necessary.  If, however, Alice piggybacked her first payload in with the SYN
 message, and Bob piggybacked his first reply with the ACK - and perhaps also
 included the CLOSE flag - transient streams such as HTTP requests could be
-reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.

+reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.
+{%- endtrans %}

 
-
Implement full streaming protocol
 [implemented]
-
The ministreaming protocol takes advantage of a poor design decision in the
+
{{ _('Implement full streaming protocol') }}

+[{{ _('implemented') }}]
+
{% trans -%}
+The ministreaming protocol takes advantage of a poor design decision in the
 I2P client protocol (I2CP) - the exposure of "mode=GUARANTEED", allowing what
 would otherwise be an unreliable, best-effort, message based protocol to be used
 for reliable, blocking operation (under the covers, its still all unreliable and
 message based, with the router providing delivery guarantees by garlic wrapping
 an "ACK" message in with the payload, so once the data gets to the target, the
-ACK message is forwarded back to us [through tunnels, of course]).

-
As I've
-said, having
+ACK message is forwarded back to us [through tunnels, of course]).
+{%- endtrans %}

+
{% trans link='http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%}
+As I've said, having
 I2PTunnel (and the ministreaming lib) go this route was the best thing that
 could be done, but more efficient mechanisms are available.  When we rip out the
 "mode=GUARANTEED" functionality, we're essentially leaving ourselves with an
 I2CP that looks like an anonymous IP layer, and as such, we'll be able to
 implement the streaming library to take advantage of the design experiences of
-the TCP layer - selective ACKs, congestion detection, nagle, etc.

+the TCP layer - selective ACKs, congestion detection, nagle, etc.
+{%- endtrans %}

 {% endblock %}
diff --git a/i2p2www/pages/site/about/performance/index.html b/i2p2www/pages/site/about/performance/index.html
new file mode 100644
index 00000000..d484bea9
--- /dev/null
+++ b/i2p2www/pages/site/about/performance/index.html
@@ -0,0 +1,111 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Performance') }}{% endblock %}
+{% block content %}
+
+
{% trans %}How does I2P work, why is it slow, and why does it not use my full bandwidth?{% endtrans %}

+
+
{% trans -%}
+Probably one of the most frequent things people ask is "how fast is I2P?",
+and no one seems to like the answer - "it depends".  After trying out I2P, the
+next thing they ask is "will it get faster?", and the answer to that is a most
+emphatic yes.
+{%- endtrans %}

+
+
{% trans -%}
+I2P is a full dynamic network. Each client is known to other nodes and tests local known nodes for reachability and capacity.
+Only reachable and capable nodes are saved to a local NetDB (This is generally only a portion of the network, around 500-1000).
+When I2P builds tunnels, it selects the best resource from this pool. For example, a small subset of 20-50 nodes are only available to build tunnels with.
+Because testing happens every minute, the pool of used nodes changes every minute.
+Each I2P node knows a different part of the net, meaning that each router has a different set of I2P nodes to be used for tunnels.
+Even if two routers have the same subset of known nodes, the tests for reachability and capacity will likely show different results, as the other routers could be under load just as one router tests, but be free if the second router tests.
+{%- endtrans %}

+
+
{% trans -%}
+The above describes why each I2P node has different nodes to build tunnels.
+Because every I2P node has a different latency and bandwith, tunnels (which are built via those nodes) have different latency and bandwidth values.
+And because every I2P node has different tunnels built, no two I2P nodes have the same tunnel sets.
+{%- endtrans %}

+
+
{% trans -%}
+A server/client is known as a "destination" and each destination has at least one inbound and one outbound tunnel. The default is 3 hops per tunnel.
+This adds up to 12 hops (aka 12 different I2P nodes) for a full roundtrip client-server-client.
+{%- endtrans %}

+
+
{% trans -%}
+Each data package is sent through 6 other I2P nodes until it reaches the server:
+{%- endtrans %}

+
+client - hop1 - hop2 - hop3 - hopa1 - hopa2 - hopa3 - server
+

+
{% trans -%}
+and on way back 6 different I2P nodes:
+{%- endtrans %}

+
+server - hopb1 - hopb2 - hopb3 - hopc1 - hopc2 - hopc3 - client
+

+
+
{% trans -%}
+As most traffic on I2P (www, torrent,...) needs ack packages until new data is sent, it needs to wait until a ack package returns from the server.
+In the end: send data, wait for ack, send more data, wait for ack,..
+As the RTT (RoundTripTime) adds up from the latency of each individual I2P node and each connection on this roundtrip, it takes usually 1-3 seconds until a ack package comes back to the client.
+With some internals of TCP and I2P transport, a data package has a limited size and cannot be as large as we want it to be.
+Together these conditions set a limit of max bandwidth per tunnel of 20-50 kbyte/sec.
+But if ONLY ONE hop in the tunnel has only 5 kb/sec bandwidth to spend, the whole tunnel is limited to 5 kb/sec, independent of the 
+latency and other limitations.
+{%- endtrans %}

+
+
{% trans -%}
+Due to encryption used and other setups in I2P (howto built up tunnels, latency, ...) it is quite expensive in CPU time to build a tunnel. This is 
+why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels to transport data. With a max of 50 kb/sec per tunnel, a destination could 
+use roughly 300 kb/sec traffic combined ( in reality it could be more if shorter tunnels are used with low or no anonymity available).
+Used tunnels are discarded every 10 minutes and new ones are built up.
+This change of tunnels (and sometimes clients that shutdown hard due to usage of "shut down at once" or situations where there is power loss) does 
+sometimes break tunnels and connections, as seen on the IRC2P Network in loss of connection (ping timeout) or on when using eepget.
+{%- endtrans %}

+
+
{% trans -%}
+With a limited set of destinations and a limited set of tunnels per destination, one I2P node only uses a limited set of tunnels across other I2P nodes.
+For example, if an I2P node is "hop1" in the small example above, we only see 1 participating tunnel originating from the client.
+If we sum up the whole I2P network, only a rather limited number of participating tunnels could be built with a limited amount of bandwidth all together.
+If one distributes these limited numbers across the number of I2P nodes, there is only a fraction of available bandwidth/capacity available for use.
+{%- endtrans %}

+
+
{% trans -%}
+To remain anonymous one router should not be used by the whole network for building tunnels.
+If one router does act as a tunnel router for ALL I2P nodes, it becomes a very real central point of failure as well as a central point to grab IPs and data from the clients. This is not good.
+I2P attempts to spread the load across a lot of I2P nodes because of this reason.
+{%- endtrans %}

+
+
{% trans -%}
+Another point is the full mesh network. Each connection hop-hop utilizes one TCP or UDP connection on the I2P nodes. With 1000 connections, one sees 
+1000 TCP connections. That is quite a lot and some home and small office routers (DSL, cable,..) only allow a small number of connections (or just go mad if you use more than X connections).
+I2P tries to limit these connections to be under 1500 per UDP and per TCP type.
+This limits the amount of traffic routed across your I2P node as well.
+{%- endtrans %}

+
+
{% trans -%}
+In summary, I2P is very complex and there is no easy way to pinpoint why your node is not used.
+If your node is reachable and has a bandwidth setting of >128 kbyte/sec shared and is reachable 24/7, it should be used after some time for participating traffic.
+If it is down in between, the testing of your I2P node done by other nodes will tell them: you are not reachable. This blocks your node for at least 
+24h on other nodes. So, the other nodes which tested you as down will not use your node for 24h for building tunnels. This is why your traffic will 
+be lower after a restart/shutdown for a minimum of 24h.
+{%- endtrans %}

+
+
{% trans -%}
+Also: other I2P nodes needs to know your I2P router to test it for reachability and capacity. It takes time for other nodes to get known to your node. 
+It will be faster if you use I2P and build more tunnels, e.g. use a torrent or www for some time.
+{%- endtrans %}

+
+
{{ _('Performance Improvements') }}

+
+
{% trans future=site_url('about/performance/future') -%}
+For possible future performance improvements see
+Future Performance Improvements.
+{%- endtrans %}

+
+
{% trans history=site_url('about/performance/history') -%}
+For past performance improvements see the 
+Performance History.
+{%- endtrans %}

+
+{% endblock %}
diff --git a/i2p2www/pages/site/about/team.html b/i2p2www/pages/site/about/team.html
new file mode 100644
index 00000000..68974c6e
--- /dev/null
+++ b/i2p2www/pages/site/about/team.html
@@ -0,0 +1,352 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Team') }}{% endblock %}
+{% block content %}
+
{{ _('I2P Project Members') }}

+
{% trans volunteer=site_url('get-involved') -%}
+We are a small group of people spread around several continents, working to
+advance different aspects of the project and discussing the design of the
+network.
+Get involved!
+{%- endtrans %}

+
+
Dec, 2010anonymous20 €General fund
Dec, 2010anonymous30 €General fund
Dec, 2010anonymous$20 USDGeneral fund
Dec, 2010anonymous$10 USDGeneral fund
Dec, 2010anonymous20 €General fund
Dec, 2010anonymous1.50 €General fund
Dec, 2010anonymous10 €General fund
Nov, 2010anonymous20 €General fund
Oct, 2010anonymous20 €General fund
Oct, 2010anonymous15 €General fund
Oct, 2010ru bounty payback$230 USDGeneral fund
Oct, 2010R.Schwabe10 €General fund
Oct, 2010Flattr29,40 €General fund
Sep, 2010anonymous10 €General fund
Sep, 2010anonymous11 €General fund
Sep, 2010anonymous10 €General fund
Sep, 2010anonymous20 €General fund
Sep, 2010R.Schwabe10 €General fund
Sep, 2010anonymous15 €General fund
Aug, 2010anonymous20 €General fund
Aug, 2010anonymous10 €General fund
Jul, 2010anonymous6,50 PLNGeneral fund
Jul, 2010anonymous10 €General fund
Jul, 2010anonymous5 €General fund
Jul, 2010anonymous20 €General fund
Jul, 2010anonymous30 €General fund
Jun, 2010anonymous5 €General fund
Jun, 2010anonymous20 €General fund
Jun, 2010anonymous8 €General fund
Jun, 2010anonymous10 €General fund
May, 2010anonymous$ 20 CADGeneral fund
May, 2010anonymous10 €General fund
May, 2010anonymous7 €General fund
Apr, 2010anonymous£ 60 SCOGeneral fund
Apr, 2010anonymous10 €General fund
Dec, 2010anonymous20 €{{ _('General fund') }}
Dec, 2010anonymous30 €{{ _('General fund') }}
Dec, 2010anonymous$20 USD{{ _('General fund') }}
Dec, 2010anonymous$10 USD{{ _('General fund') }}
Dec, 2010anonymous20 €{{ _('General fund') }}
Dec, 2010anonymous1.50 €{{ _('General fund') }}
Dec, 2010anonymous10 €{{ _('General fund') }}
Nov, 2010anonymous20 €{{ _('General fund') }}
Oct, 2010anonymous20 €{{ _('General fund') }}
Oct, 2010anonymous15 €{{ _('General fund') }}
Oct, 2010ru bounty payback$230 USD{{ _('General fund') }}
Oct, 2010R.Schwabe10 €{{ _('General fund') }}
Oct, 2010Flattr29,40 €{{ _('General fund') }}
Sep, 2010anonymous10 €{{ _('General fund') }}
Sep, 2010anonymous11 €{{ _('General fund') }}
Sep, 2010anonymous10 €{{ _('General fund') }}
Sep, 2010anonymous20 €{{ _('General fund') }}
Sep, 2010R.Schwabe10 €{{ _('General fund') }}
Sep, 2010anonymous15 €{{ _('General fund') }}
Aug, 2010anonymous20 €{{ _('General fund') }}
Aug, 2010anonymous10 €{{ _('General fund') }}
Jul, 2010anonymous6,50 PLN{{ _('General fund') }}
Jul, 2010anonymous10 €{{ _('General fund') }}
Jul, 2010anonymous5 €{{ _('General fund') }}
Jul, 2010anonymous20 €{{ _('General fund') }}
Jul, 2010anonymous30 €{{ _('General fund') }}
Jun, 2010anonymous5 €{{ _('General fund') }}
Jun, 2010anonymous20 €{{ _('General fund') }}
Jun, 2010anonymous8 €{{ _('General fund') }}
Jun, 2010anonymous10 €{{ _('General fund') }}
May, 2010anonymous$ 20 CAD{{ _('General fund') }}
May, 2010anonymous10 €{{ _('General fund') }}
May, 2010anonymous7 €{{ _('General fund') }}
Apr, 2010anonymous£ 60 SCO{{ _('General fund') }}
Apr, 2010anonymous10 €{{ _('General fund') }}

  
Apr, 2010anonymous200 €Datastorage bounty
Apr, 2010anonymous10 €General fund
Apr, 2010Mozartito5 €General fund
Mar, 2010anonymous140 €General fund
Mar, 2010anonymous10 €Abo General fund
Mar, 2010anonymous10 €Abo General fund
Feb, 2010anonymous10 €Abo General fund
Feb, 2010anonymous5 €General fund
Feb, 2010anonymous10 €General fund
Apr, 2010anonymous10 €{{ _('General fund') }}
Apr, 2010Mozartito5 €{{ _('General fund') }}
Mar, 2010anonymous140 €{{ _('General fund') }}
Mar, 2010anonymous10 €Abo {{ _('General fund') }}
Mar, 2010anonymous10 €Abo {{ _('General fund') }}
Feb, 2010anonymous10 €Abo {{ _('General fund') }}
Feb, 2010anonymous5 €{{ _('General fund') }}
Feb, 2010anonymous10 €{{ _('General fund') }}
Jan, 2010anonymous500 €General fund
Jan, 2010bernerbaer50 €General fund
Jan, 2010anonymous15 €General fund
Jan, 2010anonymous500 €{{ _('General fund') }}
Jan, 2010bernerbaer50 €{{ _('General fund') }}
Jan, 2010anonymous15 €{{ _('General fund') }}

  
Apr, 2009-Jan, 2010neutron20 €/monthoutproxy fund
Jan, 2010anonymous$20 USDGeneral fund
Jan, 2010anonymous6.80 €General fund
Jan, 2010anonymous10 €General fund
Dec, 2009anonymous5 €General fund
Dec, 2009anonymous35 €General fund
Jan, 2010anonymous$20 USD{{ _('General fund') }}
Jan, 2010anonymous6.80 €{{ _('General fund') }}
Jan, 2010anonymous10 €{{ _('General fund') }}
Dec, 2009anonymous5 €{{ _('General fund') }}
Dec, 2009anonymous35 €{{ _('General fund') }}

  
Nov, 2009russian donor230 $Russian translation bounty
Nov, 2009anonymous10 €General fund
Nov, 2009anonymous10 €{{ _('General fund') }}

  
Oct, 2009echelon10 €i2phex bounty

  
Oct, 2009arne bab10 €i2phex bounty
Oct, 2009anonymous10 €General fund
Aug, 2009anonymous400 €General fund
Aug, 2009anonymous10 €General fund
Aug, 2009anonymous100 €General fund
Jul, 2009G.Klaus15 €General fund
Jul, 2009R.Schwabe$20 USDGeneral fund
Jun, 2009anonymous10 €General fund
Jun, 2009Cendre20 €General fund
Jun, 2009M.Hilbig10 €General fund
Jun, 2009anonymous20 €General fund
May, 2009EoL10 €General fund
Apr, 2009anonymous10 €General fund
Apr, 2009anonymous60 €General fund
Apr, 2009Gilgongo15 €General fund
Oct, 2009anonymous10 €{{ _('General fund') }}
Aug, 2009anonymous400 €{{ _('General fund') }}
Aug, 2009anonymous10 €{{ _('General fund') }}
Aug, 2009anonymous100 €{{ _('General fund') }}
Jul, 2009G.Klaus15 €{{ _('General fund') }}
Jul, 2009R.Schwabe$20 USD{{ _('General fund') }}
Jun, 2009anonymous10 €{{ _('General fund') }}
Jun, 2009Cendre20 €{{ _('General fund') }}
Jun, 2009M.Hilbig10 €{{ _('General fund') }}
Jun, 2009anonymous20 €{{ _('General fund') }}
May, 2009EoL10 €{{ _('General fund') }}
Apr, 2009anonymous10 €{{ _('General fund') }}
Apr, 2009anonymous60 €{{ _('General fund') }}
Apr, 2009Gilgongo15 €{{ _('General fund') }}

  
Apr, 2009Amiga400050 €I2P vuze plugin bounty
Mar, 2009[anonymous]50 €General fund
Feb, 2009[anonymous]30 €General fund
Feb, 2009DVT20 €General fund
Mar, 2009[anonymous]50 €{{ _('General fund') }}
Feb, 2009[anonymous]30 €{{ _('General fund') }}
Feb, 2009DVT20 €{{ _('General fund') }}

  
Oct, 2008eche|on500.0 €Datastorage bounty
Mar, 2007zzz$200 USDGeneral fund
Mar, 2007zzz$200 USD{{ _('General fund') }}

  
Nov, 2006-Dec, 2007[anonymous]$10 USD/monthgeneral fund

  
Dec, 2006barNew mac testing machine
Dec, 2006[anonymous]$200 USDGeneral fund
Oct, 2006[anonymous]$150 USDGeneral fund
Oct, 2006[anonymous]$100 USDGeneral fund
Oct, 2005-Oct, 2006Eol$10 USD/monthGeneral fund
Oct, 2006Peter$750 USDGeneral fund
Jun, 2006[anonymous]$450 USDGeneral fund
Jun, 2006[anonymous]$10 USDGeneral fund
Jun, 2006[anonymous]$10 USDGeneral fund
May, 2006athena$135 USDGeneral fund
Apr, 2006postman$300 USDGeneral fund
Apr, 2006[anonymous]$300 USDGeneral fund
Apr, 2006[anonymous]$500 USDGeneral fund
Apr, 2006[anonymous]$100 USDGeneral fund
Apr, 2006[anonymous]$10 USDGeneral fund
Apr, 2006[anonymous]$50 USDGeneral fund
Apr, 2006[anonymous]$15 USDGeneral fund
Apr, 2006[anonymous]$12 USDGeneral fund
Mar, 2006[anonymous]$30 USDGeneral fund
Mar, 2006[anonymous]$800 USDGeneral fund
Dec, 2006[anonymous]$200 USD{{ _('General fund') }}
Oct, 2006[anonymous]$150 USD{{ _('General fund') }}
Oct, 2006[anonymous]$100 USD{{ _('General fund') }}
Oct, 2005-Oct, 2006Eol$10 USD/month{{ _('General fund') }}
Oct, 2006Peter$750 USD{{ _('General fund') }}
Jun, 2006[anonymous]$450 USD{{ _('General fund') }}
Jun, 2006[anonymous]$10 USD{{ _('General fund') }}
Jun, 2006[anonymous]$10 USD{{ _('General fund') }}
May, 2006athena$135 USD{{ _('General fund') }}
Apr, 2006postman$300 USD{{ _('General fund') }}
Apr, 2006[anonymous]$300 USD{{ _('General fund') }}
Apr, 2006[anonymous]$500 USD{{ _('General fund') }}
Apr, 2006[anonymous]$100 USD{{ _('General fund') }}
Apr, 2006[anonymous]$10 USD{{ _('General fund') }}
Apr, 2006[anonymous]$50 USD{{ _('General fund') }}
Apr, 2006[anonymous]$15 USD{{ _('General fund') }}
Apr, 2006[anonymous]$12 USD{{ _('General fund') }}
Mar, 2006[anonymous]$30 USD{{ _('General fund') }}
Mar, 2006[anonymous]$800 USD{{ _('General fund') }}

  
Mar, 2006barNew development machine
Mar, 2006postman$300 USDGeneral fund
Mar, 2006[anonymous]$5 USDGeneral fund
Feb, 2006[anonymous]$50 USDGeneral fund
Mar, 2006postman$300 USD{{ _('General fund') }}
Mar, 2006[anonymous]$5 USD{{ _('General fund') }}
Feb, 2006[anonymous]$50 USD{{ _('General fund') }}

  
Jan, 2006[anonymous]$500 USDUnit test bounty

  
Jan, 2006[anonymous]$25 USDI2P general fund

  
Jan, 2006[anonymous]$10 USDI2P general fund

 

+
+	
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+    
+	
+	
+
+
+	
+	
+	
+
+
+        
+        
+        
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+	
+	
+	
+
+
+
+	
+	
+	
+	
+
+
+        
+	
+	
+
+
+        
+	
+	
+
+
+        
+	
+	
+
+
+        
+	
+	
+
+
+        
+	
+	
+
+
+        
+	
+	
+
+
+        
+	
+	
+
+
+        
+	
+	
+
+
+        
+	
+        
+
+
+        
+	
+        
+
+
+        
+	
+        
+
+
+        
+	
+        
+
+
+        
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+    
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+
+	
+	
+
+
+
+	
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+        
+        
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+	
+
+
+	
+
+
{{ _('Admin') }}{{ _('Project Manager') }}zzz{{ _('point of contact of last resort') }}
{{ _('Treasurer') }}eche|on{{ _('manage donations / accounts / bounties') }}
{{ _('PR manager') }}orion{{ _('press contact, manages public relations and affairs') }}
{% trans forum=i2pconv('forum.i2p') %}Forum admin{% endtrans %}cervantes{{ _('manage the public user forum') }}
{{ _('Mirrors admin') }}welterde{{ _('manage the project mirrors') }}
{% trans monotone=site_url('get-involved/guides/monotone') %}Monotone guru{% endtrans %}welterde, eche|on{{ _('manage the public monotone repositories') }}
{{ _('Packager; Linux') }}KillYourTV{{ _('Linux (Debian/Ubuntu) distribution packager') }}
{{ _('Packager; Windows') }}KillYourTV{{ _('Windows installer packager') }}
{{ _('Release Manager') }}zzz{{ _('Builds and signs the releases') }}
{{ _('Update admin') }}KillYourTV{{ _('Monitors and recruits in-network update hosts') }}
{{ _('Reseed admin') }}Meeh{{ _('Monitors, advises and recruits reseed hosts') }}
{{ _('Security expert') }}[{{ _('vacant') }}]{{ _('threat model / crypto expert') }}
{{ _('User Advocate') }}[{{ _('vacant') }}]{{ _('gather, prioritize, advocate for user needs') }}
{{ _('Web Designer') }}[{{ _('vacant') }}]{{ _('manage the public project website content design') }}
{% trans website=i2pconv('www.i2p2.i2p') %}Webserver admin{% endtrans %}welterde{{ _('manage the public project webservers') }}
{% trans website=i2pconv('www.i2p2.i2p') %}Website admin{% endtrans %}[{{ _('vacant') }}]{{ _('manage the public project website content') }}
{{ _('News Admin') }}eche|on{{ _('manage router console news feed') }}
{{ _('Director of passion') }}[{{ _('vacant') }}]{{ _('community motivator') }}
{{ _('Dev') }}{{ _('Core Lead') }}zzz{{ _('lead dev for the SDK and router') }}
{% trans postman=i2pconv('hq.postman.i2p') %}I2P mail lead{% endtrans %}postman{{ _('organize and develop the i2p mail system') }}
{% trans i2host=i2pconv('i2host.i2p') %}I2Host lead{% endtrans %}sponge{{ _('I2Host addressbook application') }}
{% trans bob=i2pconv('bob.i2p') %}BOB lead{% endtrans %}sponge{{ _('Basic Open Bridge') }}
{% trans bote=i2pconv('i2pbote.i2p') %}I2P-Bote lead{% endtrans %}HungryHobo{{ _('I2PBote plugin') }}
{% trans bob=i2pconv('bob.i2p') %}Robert lead{% endtrans %}sponge{{ _('Robert BitTorrent client') }}
{% trans forum=i2pconv('forum.i2p') %}I2Phex lead{% endtrans %}[{{ _('vacant') }}]{{ _('I2Phex Gnutella client') }}
{% trans forum=i2pconv('forum.i2p') %}I2PSnark lead{% endtrans %}zzz{{ _('Maintains the integrated Bittorrent client') }}
{% trans forum=i2pconv('forum.i2p') %}iMule lead{% endtrans %}[{{ _('vacant') }}]{{ _('eMule client over I2P') }}
{% trans forum=i2pconv('forum.i2p') %}Syndie lead{% endtrans %}[{{ _('vacant') }}]{{ _('Syndie development') }}
{{ _('Susimail lead') }}[{{ _('vacant') }}]{{ _('Susimail development') }}
{{ _('Console') }}[{{ _('vacant') }}]{{ _('Router console HTML/CSS design') }}
{{ _('SAM') }}[{{ _('vacant') }}]{{ _('SAM maintainer') }}
{{ _('Console Translations') }}walking{{ _('Chinese') }}
monkeybrains{{ _('Dutch') }}
magma{{ _('French') }}
eche|on, mixxy{{ _('German') }}
rus, 4get, slow{{ _('Russian') }}
user{{ _('Spanish') }}
thelastcode, hamada{{ _('Arabic') }}
[{{ _('vacant') }}]{{ _('Other languages') }}
{{ _('Contributors') }}cervantes{{ _('fire2pe dev, console enhancements') }}
Mathiasdm{{ _('desktopgui, dijjer port') }}
KillYourTV{{ _('Debian/Ubuntu Packager and PPA maintainer') }}
[{{ _('vacant') }}]{{ _('Help needed on many fronts!') }}
{{ _('Past contributors') }}mihi{{ _('I2PTunnel development, ministreaming library') }}
jrandom{{ _('Project lead, Syndie lead') }}
Complication{{ _('Project lead, Syndie lead, I2Phex, support guru') }}
mkvore{{ _('iMule lead') }}
redzara{{ _('I2Phex work') }}
striker{{ _('I2Phex work') }}
legion{{ _('I2Phex work') }}
Connely{{ _('Python SAM library, attack simulations') }}
mastiejaner{{ _('i2pmail development') }}
dust{{ _('Syndie help') }}
susi23{{ _('i2p mail,susimail and susidns apps') }}
sirup{{ _('I2Phex (port of Phex to I2P)') }}
Ragnarok{{ _('addressbook,i2p-bt,syndie client') }}
duck{{ _('organize and develop the i2p-bt BitTorrent port') }}
Ragnarok{{ _('addressbook, i2p-bt, syndie client development') }}
thecrypto{{ _('encryption and signature routines, I2PIM') }}
aum{{ _('SAM jython code, work on stasher (DHT) and v2v (VoI2P)') }}
hypercubus{{ _('installer, systray, bogobot') }}
ugha{{ _('jbigi development, wiki migration, doc cleanup') }}
oOo{{ _('java debugging and client development on I2PTunnel and the router console') }}
BrianR{{ _('SAM perl module') }}
eco{{ _('i2psnark work') }}
shendaras{{ _('java cleanup') }}
JAnonymous{{ _('docs. wiki migration') }}
jar{{ _('translations into French') }}
scintilla{{ _('C port of jcpuid') }}
smeghead{{ _('C# SAM library, pants, fortuna integration') }}
Nightblade{{ _('libSAM') }}
dinoman{{ _('i2p-bt tracker development') }}
DrWoo{{ _('i2p-bt tracker development') }}
dr|z3d{{ _('Console and website themes') }}
{% trans %}… and many others{% endtrans %}

+{% endblock %}
diff --git a/i2p2www/pages/site/comparison/freenet.html b/i2p2www/pages/site/comparison/freenet.html
new file mode 100644
index 00000000..cc4c1dbe
--- /dev/null
+++ b/i2p2www/pages/site/comparison/freenet.html
@@ -0,0 +1,40 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('I2P Compared to Freenet') }}{% endblock %}
+{% block content %}
+
+
Freenet

+[Freenet]
+
+
{% trans -%}
+Freenet is a fully distributed, peer to peer anonymous publishing network, offering 
+secure ways to store data, as well as some approaches attempting to address the loads
+of a flash flood.  While Freenet is designed as a distributed data store, people have
+built applications on top of it to do more generic anonymous communication, such as 
+static websites and message boards.
+{%- endtrans %}

+
+
{% trans tahoe='https://tahoe-lafs.org/trac/tahoe-lafs' -%}
+Compared to I2P, Freenet offers some substantial benefits - it is a distributed data
+store, while I2P is not, allowing people to retrieve the content published by others 
+even when the publisher is no longer online.  In addition, it should be able to 
+distribute popular data fairly efficiently.  I2P itself does not and will not provide 
+this functionality.  On the other hand, there is overlap for users who simply want to 
+communicate with each other anonymously through websites, message boards, file sharing
+programs, etc.  There have also been some attempts to develop a distributed data 
+store to run on top of I2P,
+(most recently a port of Tahoe-LAFS)
+but nothing is yet ready for general use.
+{%- endtrans %}

+
+
{% trans -%}
+However, even ignoring any implementations issues, there are some concerns 
+about Freenet's algorithms from both a scalability and anonymity perspective, owing 
+largely to Freenet's heuristic driven routing.  The interactions of various techniques 
+certainly may successfully deter various attacks, and perhaps some aspects of the 
+routing algorithms will provide the hoped for scalability.  Unfortunately, not much
+analysis of the algorithms involved has resulted in positive results, but there is still
+hope.  At the very least, Freenet does provide substantial anonymity against an attacker
+who does not have the resources necessary to analyze it further.
+{%- endtrans %}

+
+{% endblock %}
diff --git a/i2p2www/pages/site/comparison/gnunet.html.new b/i2p2www/pages/site/comparison/gnunet.html.new
new file mode 100644
index 00000000..7aa177a4
--- /dev/null
+++ b/i2p2www/pages/site/comparison/gnunet.html.new
@@ -0,0 +1,37 @@
+{% extends "global/layout.html" %}
+{% block title %}I2P Compared to GNUnet{% endblock %}
+{% block content %}
+
+
GNUnet

+[GNUnet] 
+
+

+TODO: Overview of GNUnet.
+

+
+

+TODO: Comparison to I2P.
+

+
+
Comparison of GNUnet and I2P Terminology

+
+

+TODO: Comparison of terminology
+

+
+
+  
+  
+
GNUnetI2P
PseudonymDestination(?)

+
+
Benefits of GNUnet over I2P

+
+
+
Benefits of I2P over GNUnet

+
+
+{% endblock %}
diff --git a/i2p2www/pages/site/comparison/index.html b/i2p2www/pages/site/comparison/index.html
new file mode 100644
index 00000000..f87651a5
--- /dev/null
+++ b/i2p2www/pages/site/comparison/index.html
@@ -0,0 +1,37 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Comparing I2P to other projects') }}{% endblock %}
+{% block content %}
+
{% trans -%}
+There are a great many other applications and projects working on anonymous 
+communication and I2P has been inspired by much of their efforts.  This is not 
+a comprehensive list of anonymity resources - both freehaven's 
+Anonymity Bibliography
+and GNUnet's related projects
+serve that purpose well.  That said, a few systems stand out for further
+comparison. The following have individual comparison pages:
+{%- endtrans %}

+
+
+
+
{% trans othernetworks=site_url('comparison/other-networks') -%}
+The following are discussed on the other networks page:
+{%- endtrans %}

+
+
+
+
{% trans trac=i2pconv('trac.i2p2.i2p') -%}
+The content of this page is subject to update, discussion and dispute, and we welcome comments and additions.
+You may contribute an analysis by entering a new ticket on Trac.
+{%- endtrans %}

+
+{% endblock %}
diff --git a/www.i2p2/pages/othernetworks.html b/i2p2www/pages/site/comparison/other-networks.html
similarity index 73%
rename from www.i2p2/pages/othernetworks.html
rename to i2p2www/pages/site/comparison/other-networks.html
index 4c52e554..61373ac3 100644
--- a/www.i2p2/pages/othernetworks.html
+++ b/i2p2www/pages/site/comparison/other-networks.html
@@ -1,38 +1,42 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Compared to Other Anonymous Networks{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('I2P Compared to Other Anonymous Networks') }}{% endblock %}
 {% block content %}
 
-
The following networks are discussed on this page.
-

+
{% trans -%}
+The following networks are discussed on this page.
+{%- endtrans %}

 
 
-
Most of the following sections are fairly old, and may not be accurate.
-For discussions of Tor and Freenet, see the
-main network comparisons page.
+
{% trans comparison=site_url('comparison'), trac=i2pconv('trac.i2p2.i2p') -%}
+Most of the following sections are fairly old, and may not be accurate.
+For an overview of available comparisons, see the
+main network comparisons page.
 You may contribute an analysis by entering a
-new ticket on trac.i2p2.de.
-

+new ticket on {{ trac }}.
+{%- endtrans %}

 
 
-
Morphmix and Tarzan

-[Morphmix] 
-   [Tarzan]
+
Morphmix / Tarzan

+[Morphmix] 
+   [Tarzan]
 
-
Morphmix and Tarzan are both fully distributed, peer to peer networks of 
+
{% trans threatmodel=site_url('docs/how/threat-model') -%}
+Morphmix and Tarzan are both fully distributed, peer to peer networks of 
 anonymizing proxies, allowing people to tunnel out through the low latency 
 mix network.  Morphmix includes some very interesting collusion detection 
 algorithms and Sybil defenses, while Tarzan makes use of the scarcity of IP
 addresses to accomplish the same.  The two primary differences between 
-these systems and I2P are related to I2P's threat model 
+these systems and I2P are related to I2P's threat model 
 and their out-proxy design (as opposed to providing both sender and receiver 
 anonymity).  There is source code available to both systems, but we are not aware 
-of their use outside of academic environments.

+of their use outside of academic environments.
+{%- endtrans %}

 
 
+
+
{{ _('Comparison of Tor and I2P Terminology') }}

+
{% trans -%}
+While Tor and I2P are similar in many ways, much of the terminology is different.
+{%- endtrans %}

+
+
TorI2P
+
{{ _('Cell') }}{{ _('Message') }}
+
{{ _('Client') }}{{ _('Router or Client') }}
+
{{ _('Circuit') }}{{ _('Tunnel') }}
+
{{ _('Directory') }}{{ _('NetDb') }}
+
{{ _('Directory Server') }}{{ _('Floodfill Router') }}
+
{{ _('Entry Guards') }}{{ _('Fast Peers') }}
+
{{ _('Entry Node') }}{{ _('Inproxy') }}
+
{{ _('Exit Node') }}{{ _('Outproxy') }}
+
{{ _('Hidden Service') }}{{ _('Eepsite or Destination') }}
+
{{ _('Hidden Service Descriptor') }}{{ _('LeaseSet') }}
+
{{ _('Introduction point') }}{{ _('Inbound Gateway') }}
+
{{ _('Node') }}{{ _('Router') }}
+
{{ _('Onion Proxy') }}{{ _('I2PTunnel Client (more or less)') }}
+
{{ _('Relay') }}{{ _('Router') }}
+
{{ _('Rendezvous Point') }}{{ _('somewhat like Inbound Gateway + Outbound Endpoint') }}
+
{{ _('Router Descriptor') }}{{ _('RouterInfo') }}
+
{{ _('Server') }}{{ _('Router') }}
+

+
+
{{ _('Benefits of Tor over I2P') }}

+
+
+
{{ _('Benefits of I2P over Tor') }}

+
+
+
{{ _('Other potential benefits of I2P but not yet implemented') }}

+
{% trans %}...and may never be implemented, so don't count on them!{% endtrans %}

+
+
+{% endblock %}
diff --git a/www.i2p2/pages/contact.html b/i2p2www/pages/site/contact.html
similarity index 58%
rename from www.i2p2/pages/contact.html
rename to i2p2www/pages/site/contact.html
index ab97787d..e8c5502f 100644
--- a/www.i2p2/pages/contact.html
+++ b/i2p2www/pages/site/contact.html
@@ -1,65 +1,65 @@
-{% extends "_layout.html" %}
-{% block title %}Contact{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Contact') }}{% endblock %}
 {% block content %}
 
IRC

-

+
{% trans -%}
   Our primary IRC network is the Irc2P network within I2P; a default tunnel to this network is set up with new router installs.
-  We are also present on multiple standard networks like OFTC,
+  We are also present on multiple standard networks like OFTC,
   EIN and Freenode.
   All I2P-related channels on all these network are linked to the main channels on Irc2P via relay bots.
-

+{%- endtrans %}

 
 {% filter escape %}
-Channel list:
+{{ _('Channel list:') }}
 
-#i2p       General i2p discussion
-#i2p-chat  Offtopic
-#i2p-dev   Development talk
-#i2p-help  Help channel
+#i2p       {{ _('General i2p discussion') }}
+#i2p-chat  {{ _('Offtopic') }}
+#i2p-dev   {{ _('Development talk') }}
+#i2p-help  {{ _('Help channel') }}
 {% endfilter %}
 

 
-
Forums

-

-  Most of the discussion about I2P's development happens on the I2P developer forum. This is usually the best place to start with inquiries, if the dev IRC channel is inactive.
-

+
{{ _('Forums') }}

+
{% trans zzz=i2pconv('zzz.i2p') -%}
+  Most of the discussion about I2P's development happens on the I2P developer forum. This is usually the best place to start with inquiries, if the dev IRC channel is inactive.
+{%- endtrans %}

 
-
Mailing lists

-

+
{{ _('Mailing lists') }}

+
{% trans -%}
   I2P does have a mailing list, but it is rarely used as the current small team of developers prefer to communicate via IRC or the developer forum. This may change in future.
-

+{%- endtrans %}

 
 
-
Subscribing

-

+
{{ _('Subscribing') }}

+
{% trans -%}
   To subscribe to a mailing list, go to the list information page (linked below) and fill out the form. I2P-internal email addresses (foobar@mail.i2p) can be used.
-

+{%- endtrans %}

 
-
Unsubscribing

-

+
{{ _('Unsubscribing') }}

+
{% trans -%}
   To unsubscribe from a mailing list or edit your subscription options, go to the list information page (linked below) and enter your subscription email address.
-

+{%- endtrans %}

 
-
Lists

+
{{ _('Lists') }}

 
 
 
 
NNTP

-

+
{% trans -%}
   You don't like mailing lists? Then this is for you. All mailing lists are available via NNTP as well.
-

+{%- endtrans %}

 
 {% filter escape %}
-Group-List-mapping:
+{{ _('Group-List-mapping:') }}
 
 i2p.general          i2p-general
 
-Servers:
+{{ _('Servers:') }}
 
 news.welterde.de     news.welterde.i2p
 {% endfilter %}
diff --git a/www.i2p2/pages/bob.html b/i2p2www/pages/site/docs/api/bob.html
similarity index 78%
rename from www.i2p2/pages/bob.html
rename to i2p2www/pages/site/docs/api/bob.html
index 6563aee9..f0cbf0bd 100644
--- a/www.i2p2/pages/bob.html
+++ b/i2p2www/pages/site/docs/api/bob.html
@@ -1,48 +1,77 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}BOB{% endblock %}
+{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
 {% block content %}
-
-Technical differences from SAM (for the better?)
+
{% trans %}BOB - Basic Open Bridge{% endtrans %}

 
+
{% trans %}Technical differences from SAM (for the better?){% endtrans %}

 
+
{% trans -%}
 BOB has separate command and data channels. 
 One, an application command channel socket to router to configure.
 Two, the application data sockets to/from router that carry only data.
 The command channel is only needed for making or setting the initial
 destination key, and to set the destination key to port bindings. 
 All connections run in parallel.
+{%- endtrans %}

 
-SAM One connection that does everything, and you need to parse every packet.
+
{% trans -%}
+SAM has one connection that does everything, and you need to parse every packet.
+{%- endtrans %}

 
+
{% trans -%}
 BOB does not hold keypair values, nor does the router.
 Your application holds the keypair values. 
 This is to reduce any extra complexity in the router code, it also adds to
 your privacy.
+{%- endtrans %}

 
+
{% trans -%}
 SAM router stores every keypair you ever make.
+{%- endtrans %}

 
+
{% trans -%}
 Those are the important differences.
+{%- endtrans %}

 
-KEYS = keypair public+private, these are BASE64
-KEY = public key, also BASE64
+
{% trans -%}
+KEYS = keypair public+private, these are BASE64
+{%- endtrans %}

+
{% trans -%}
+KEY = public key, also BASE64
+{%- endtrans %}

+
{% trans -%}
+ERROR as is implied returns the message "ERROR "+DESCRIPTION+"\n", where the DESCRIPTION is what went wrong.
+{%- endtrans %}

+
{% trans -%}
+OK returns "OK", and if data is to be returned, it is on the same line. OK means the command is finished.
+{%- endtrans %}

+
{% trans -%}
+DATA lines contain information that you requested. There may be multiple DATA lines per request.
+{%- endtrans %}

 
-ERROR as is implied returns the message "ERROR "+DESCRIPTION+"\n", where the DESCRIPTION is what went wrong.
-OK returns "OK", and if data is to be returned, it is on the same line. OK means the command is finished.
-DATA lines contain information that you requested. There may be multiple DATA lines per request.
-
-NOTE: The help command is the ONLY command that has an exception to
+
{% trans -%}
+NOTE: The help command is the ONLY command that has an exception to
 the rules... it can actually return nothing! This is intentional, since
 help is a HUMAN and not an APPLICATION command.
+{%- endtrans %}

 
-PLEASE NOTE:
+
{% trans -%}
+PLEASE NOTE:
 For CURRENT details on the commands PLEASE use the built-in help command. 
 Just telnet to localhost 2827 and type help and you can get full documentation on each command. 
+{%- endtrans %}

 
+
{% trans -%}
 Commands never get obsoleted or changed, however new commands do get added from time to time.
+{%- endtrans %}

 
-Here are the commands we have as of this writing (Aug 2010).
+
{% trans -%}
+Here are the commands we have as of this writing:
+{%- endtrans %}

 
-COMMAND     OPERAND                             RETURNS
+
+{{ _('COMMAND') }}     {{ _('OPERAND') }}                             {{ _('RETURNS') }}
 help        (optional command to get help on)   NOTHING or OK and description of the command
 clear                                           ERROR or OK
 getdest                                         ERROR or OK and KEY
@@ -67,12 +96,16 @@ stop                                            ERROR or OK
 verify      KEY                                 ERROR or OK
 visit                                           OK, and dumps BOB's threads to the wrapper.log
 zap                                             nothing, quits BOB
+

 
+
{% trans -%}
 Once set up, all TCP sockets can and will block as needed, and there is no need for any 
 additional messages to/from the command channel. This allows the router to pace the
 stream without exploding with OOM like SAM does as it chokes on attempting to shove 
 many streams in or out one socket -- that can't scale when you have alot of connections!
+{%- endtrans %}

 
+
{% trans -%}
 What is also nice about this particular interface is that writing anything to interface 
 to it, is much much easier than SAM. There is no other processing to do after the set up.
 It's configuration is so simple, that very simple tools, such as nc (netcat) can be used 
@@ -82,39 +115,53 @@ to stop that application. Instead, you can literally "unplug" the destination, a
 "plug it in" again. As long as the same IP/port addresses and destination keys are used 
 when bringing the bridge up, the normal TCP application won't care, and won't notice.
 It will simply be fooled -- the destinations are not reachable, and that nothing is coming in.
+{%- endtrans %}

 
+
{% trans -%}
 For the following example, we'll setup a very simple local loopback connection, 
 with two destinations. Destination "mouth" will be the CHARGEN service from 
 the INET superserver daemon. Destination "ear" will be a local port that you
 can telnet into, and watch the pretty ASCII test puke forth.
+{%- endtrans %}

 
-EXAMPLE SESSION DIALOGUE -- simple telnet 127.0.0.1 2827 works
-A = Application
-C = BOB's Command response.
+
+{% trans %}EXAMPLE SESSION DIALOGUE -- simple telnet 127.0.0.1 2827 works{% endtrans %}
+A = {{ _('Application') }}
+C = {% trans %}BOB's Command response.{% endtrans %}
 
-FROM 	TO	DIALOGUE
+{{ _('FROM') }} 	{{ _('TO') }}	{{ _('DIALOGUE') }}
 A	C	setnick mouth
 C	A	OK Nickname set to mouth
 A	C	newkeys
 C	A	OK ZMPz1zinTdy3~zGD~f3g9aikZTipujEvvXOEyYfq4Su-mNKerqG710hFbkR6P-xkouVyNQsqWLI8c6ngnkSwGdUfM7hGccqBYDjIubTrlr~0g2-l0vM7Y8nSqtFrSdMw~pyufXZ0Ys3NqUSb8NuZXpiH2lCCkFG21QPRVfKBGwvvyDVU~hPVfBHuR8vkd5x0teMXGGmiTzdB96DuNRWayM0y8vkP-1KJiPFxKjOXULjuXhLmINIOYn39bQprq~dAtNALoBgd-waZedYgFLvwHDCc9Gui8Cpp41EihlYGNW0cu0vhNFUN79N4DEpO7AtJyrSu5ZjFTAGjLw~lOvhyO2NwQ4RiC4UCKSuM70Fz0BFKTJquIjUNkQ8pBPBYvJRRlRG9HjAcSqAMckC3pvKKlcTJJBAE8GqexV7rdCCIsnasJXle-6DoWrDkY1s1KNbEVH6i1iUEtmFr2IHTpPeFCyWfZ581CAFNRbbUs-MmnZu1tXAYF7I2-oXTH2hXoxCGAAAA
+

 
+
{% trans -%}
 MAKE NOTE OF THE ABOVE DESTINATION KEY, YOURS WILL BE DIFFERENT!
+{%- endtrans %}

 
-FROM    TO    DIALOGUE
+
+{{ _('FROM') }}    {{ _('TO') }}    {{ _('DIALOGUE') }}
 A       C     outhost 127.0.0.1
 C       A     OK outhost set
 A       C     outport 19
 C       A     OK outbound port set
 A       C     start
 C       A     OK tunnel starting
+

 
+
{% trans -%}
 At this point, there was no error, a destination with a nickname of "mouth" 
 is set up. When you contact the destination provided, you actually connect 
-to the CHARGEN service on 19/TCP. 
+to the CHARGEN service on 19/TCP.
+{%- endtrans %}

 
+
{% trans -%}
 Now for the other half, so that we can actually contact this destination.
+{%- endtrans %}

 
-FROM    TO      DIALOGUE
+
+{{ _('FROM') }}    {{ _('TO') }}      {{ _('DIALOGUE') }}
 A       C       setnick ear
 C       A       OK Nickname set to ear
 A       C       newkeys
@@ -127,14 +174,20 @@ A       C       start
 C       A       OK tunnel starting
 A       C       quit
 C       A       OK Bye!
+

 
+
{% trans -%}
 Now all we need to do is telnet into 127.0.0.1, port 37337,
 send the destination key or host address from addressbook we want to contact.
 In this case, we want to contact "mouth", all we do is paste in the
 key and it goes.
+{%- endtrans %}

 
-NOTE: The "quit" command in the command channel does NOT disconnect the tunnels like SAM.
+
{% trans -%}
+NOTE: The "quit" command in the command channel does NOT disconnect the tunnels like SAM.
+{%- endtrans %}

 
+
 # telnet 127.0.0.1 37337
 Trying 127.0.0.1...
 Connected to 127.0.0.1.
@@ -146,20 +199,32 @@ ZMPz1zinTdy3~zGD~f3g9aikZTipujEvvXOEyYfq4Su-mNKerqG710hFbkR6P-xkouVyNQsqWLI8c6ng
 #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij
 $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk
 ...
-After a few virtual miles of this spew, press Control-]
+

+
{% trans -%}
+After a few virtual miles of this spew, press Control-]
+{%- endtrans %}

+
 ...
 cdefghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJK
 defghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKL
 efghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=
 telnet> c
 Connection closed.
+

 
+
{% trans -%}
 Here is what happened...
+{%- endtrans %}

+
 telnet -> ear -> i2p -> mouth -> chargen -.
 telnet <- ear <- i2p <- mouth <-----------'
+

 
+
{% trans -%}
 You can connect to EEPSITES too!
+{%- endtrans %}

 
+
 # telnet 127.0.0.1 37337
 Trying 127.0.0.1...
 Connected to 127.0.0.1.
@@ -186,36 +251,52 @@ Accept-Ranges: bytes
 </html>
 Connection closed by foreign host.
 #
+

 
+
{% trans -%}
 Pretty cool isn't it? Try some other well known EEPSITES if you like, nonexistent ones, 
 etc, to get a feel for what kind of output to expect in different situations. 
 For the most part, it is suggested that you ignore any of the error messages. 
 They would be meaningless to the application, and are only presented for human debugging.
+{%- endtrans %}

 
+
{% trans -%}
 Let's put down our destinations now that we are all done with them.
+{%- endtrans %}

 
+
{% trans -%}
 First, lets see what destination nicknames we have.
+{%- endtrans %}

 
-FROM 	TO	DIALOGUE
+
+{{ _('FROM') }} 	{{ _('TO') }}	{{ _('DIALOGUE') }}
 A	C	list
 C	A	DATA NICKNAME: mouth STARTING: false RUNNING: true STOPPING: false KEYS: true QUIET: false INPORT: not_set INHOST: localhost OUTPORT: 19 OUTHOST: 127.0.0.1
 C	A	DATA NICKNAME: ear STARTING: false RUNNING: true STOPPING: false KEYS: true QUIET: false INPORT: 37337 INHOST: 127.0.0.1 OUTPORT: not_set OUTHOST: localhost
 C	A	OK Listing done
+

 
+
{% trans -%}
 Alright, there they are. First, let's remove "mouth".
+{%- endtrans %}

 
-FROM 	TO	DIALOGUE
+
+{{ _('FROM') }} 	{{ _('TO') }}	{{ _('DIALOGUE') }}
 A	C	getnick mouth
 C	A	OK Nickname set to mouth
 A	C	stop
 C	A	OK tunnel stopping
 A	C	clear
 C	A	OK cleared
+

 
+
{% trans -%}
 Now to remove "ear", note that this is what happens when you type too fast,
 and shows you what typical ERROR messages looks like.
+{%- endtrans %}

 
-FROM 	TO	DIALOGUE
+
+{{ _('FROM') }} 	{{ _('TO') }}	{{ _('DIALOGUE') }}
 A	C	getnick ear
 C	A	OK Nickname set to ear
 A	C	stop
@@ -226,20 +307,31 @@ A	C	clear
 C	A	OK cleared
 A	C	quit
 C	A	OK Bye!
+

 
+
{% trans -%}
 I won't bother to show an example of the receiver end of a bridge
 because it is very simple. There are two possible settings for it, and
 it is toggled with the "quiet" command.
+{%- endtrans %}

+
+
{% trans -%}
 The default is NOT quiet, and the first data to come into your
 listening socket is the destination that is making the contact. It is a
 single line consisting of the BASE64 address followed by a newline.
 Everything after that is for the application to actually consume.
+{%- endtrans %}

+
+
{% trans -%}
 In quiet mode, think of it as a regular Internet connection. No
 extra data comes in at all. It's just as if you are plain connected to
 the regular Internet. This mode allows a form of transparency much like
 is available on the router console tunnel settings pages, so that you
 can use BOB to point a destination at a web server, for example, and
 you would not have to modify the web server at all.
+{%- endtrans %}

+
+
{% trans -%}
 The advantage with using BOB for this is as discussed
 previously. You could schedule random uptimes for the application,
 redirect to a different machine, etc. One use of this may be something
@@ -251,5 +343,5 @@ have to bother shutting it down and restarting it. You could redirect
 and point to a different machine on your LAN while you do updates, or
 point to a set of backup machines depending on what is running, etc,
 etc. Only your imagination limits what you could do with BOB.
-
+{%- endtrans %}

 {% endblock %}
diff --git a/i2p2www/pages/site/docs/api/datagrams.html b/i2p2www/pages/site/docs/api/datagrams.html
new file mode 100644
index 00000000..176bd237
--- /dev/null
+++ b/i2p2www/pages/site/docs/api/datagrams.html
@@ -0,0 +1,114 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Datagrams{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
+{% block content %}
+
{% trans %}Datagram Overview{% endtrans %}

+
{% trans i2cp=site_url('docs/protocol/i2cp') -%}
+Datagrams build upon the base I2CP to provide authenticated
+and repliable messages in a standard format.  This lets applications reliably read
+the "from" address out of a datagram and know that the address really sent the
+message.  This is necessary for some applications since the base I2P message is
+completely raw - it has no "from" address (unlike IP packets).  In addition, the
+message and sender are authenticated by signing the payload.
+{%- endtrans %}

+
+
{% trans streaming=site_url('docs/api/streaming'),
+transports=site_url('docs/transport') -%}
+Datagrams, like streaming library packets,
+are an application-level construct.
+These protocols are independent of the low-level transports;
+the protocols are converted to I2NP messages by the router, and
+either protocol may be carried by either transport.
+{%- endtrans %}

+
+
{% trans %}Application Guide{% endtrans %}

+
{% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/datagram/package-summary.html',
+sam= site_url('docs/api/sam'),
+socks=site_url('docs/api/socks') -%}
+Applications written in Java may use the 
+datagram API,
+while applications in other languages 
+can use SAM's datagram support.
+There is also limited support in i2ptunnel in the SOCKS proxy,
+the 'streamr' tunnel types, and udpTunnel classes.
+{%- endtrans %}

+
+
{% trans %}Datagram Length{% endtrans %}

+
{% trans -%}
+The application designer should carefully consider the tradeoff of repliable vs. non-repliable
+datagrams. Also, the datagram size will affect reliability, due to tunnel fragmentation into 1KB
+tunnel messages. The more message fragments, the more likely that one of them will be dropped
+by an intermediate hop. Messages larger than a few KB are not recommended.
+{%- endtrans %}

+
+
{% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
+Also note that the various overheads added by lower layers, in particular asymmetric
+ElGamal/AES, place a large burden on intermittent messages
+such as used by a Kademlia-over-UDP application. The implementations are currently tuned
+for frequent traffic using the streaming library. There are a high number
+of session tags delivered, and a short session tag lifetime, for example.
+There are currently no configuration parameters available within I2CP to tune
+the ElGamal Session Tag parameters.
+{%- endtrans %}

+
+
{% trans %}I2CP Protocol Number and Ports{% endtrans %}

+
{% trans -%}
+The standard I2CP protocol number for datagrams is 17. Applications may or may not choose to set the
+protocol in the I2CP header. It is not set by default.
+It must be set to demultiplex datagram and streaming traffic received on the same Destination.
+{%- endtrans %}

+
+
{% trans i2cp=site_url('docs/protocol/i2cp') -%}
+As datagrams are not connection-oriented, the application may require
+port numbers to correlate datagrams with particular peers or communications sessions,
+as is traditional with UDP over IP.
+Applications may add 'from' and 'to' ports to the I2CP (gzip) header as described in
+the I2CP page.
+{%- endtrans %}

+
+
{% trans -%}
+There is no method within the datagram API to specify whether it is non-repliable (raw)
+or repliable. The application should be designed to expect the appropriate type.
+The I2CP protocol number or port could also be used by the application to
+indicate datagram type.
+{%- endtrans %}

+
+
{% trans i2psession='http://docs.i2p-projekt.de/javadoc/net/i2p/client/I2PSession.html',
+i2psessionmuxed='http://docs.i2p-projekt.de/javadoc/net/i2p/client/I2PSessionMuxedImpl.html' -%}
+The protocols and ports may be set in I2CP's
+I2PSession API,
+as implemented in
+I2PSessionMuxedImpl.
+{%- endtrans %}

+
+
{% trans %}Data Integrity{% endtrans %}

+
{% trans i2cp=site_url('docs/protocol/i2cp') -%}
+Data integrity is assured by the gzip CRC-32 checksum implemented in
+the I2CP layer.
+There is no checksum field in the datagram protocol.
+{%- endtrans %}

+
+
{% trans %}Packet Encapsulation{% endtrans %}

+
{% trans garlicrouting=site_url('docs/how/garlic-routing'),
+i2cp=site_url('docs/protocol/i2cp'),
+i2np=site_url('docs/protocol/i2np'),
+tunnelmessage=site_url('docs/spec/tunnel-message') -%}
+Each datagram is sent through I2P as a single message (or as an individual clove in a
+Garlic Message).
+Message encapsulation is implemented in the underlying
+I2CP,
+I2NP, and
+tunnel message layers.
+There is no packet delimiter mechanism or length field in the datagram protocol.
+{%- endtrans %}

+
+
{% trans %}Specification{% endtrans %}

+
+
{% trans -%}
+See the Datagrams Specification page.
+{%- endtrans %}

+
+
+
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/api/i2pcontrol.html b/i2p2www/pages/site/docs/api/i2pcontrol.html
new file mode 100644
index 00000000..d3f50466
--- /dev/null
+++ b/i2p2www/pages/site/docs/api/i2pcontrol.html
@@ -0,0 +1,205 @@
+{% extends "global/layout.html" %}
+{% block title %}I2PControl API{% endblock %}
+{% block content %}
+
{% trans %}I2PControl - Remote Control Service{% endtrans %}

+
{% trans itoopie='http://itoopie.net/' -%}
+I2P enables a JSONRPC2 interface via the plugin I2PControl.
+The aim of the interface is to provide simple way to interface with a running I2P node. A client, itoopie, has been developed in parallel.
+The JSONRPC2 implementation for the client as well as the plugin is provided by the java libraries JSON-RPC 2.0.  
+A list of implementations of JSON-RPC for various languages can be found at the JSON-RPC wiki.
+{%- endtrans %}

+
+
{% trans %}I2PControl is by default listening on localhost:7650{% endtrans %}

+
+
{% trans %}API, version 1.{% endtrans %}

+
{% trans -%}
+Parameters are only provided in a named way (maps).
+{%- endtrans %}

+
+
{% trans %}JSON-RPC 2 format{% endtrans %}

+
+{{ _('Request:') }}
+{"id":"id", "method":"Method-name","params":{"Param-key-1":"param-value-1", "Param-key-2":"param-value-2", "Token":"**actual token**"}, "jsonrpc":"2.0"}
+{{ _('Response:') }}
+{"id":"id","result":{"Result-key-1":"result-value-1","Result-key-2":"result-value-2"},"jsonrpc":"2.0"}
+

+
    method-name – {{ _('Description') }}
+	
      {{ _('Request:') }}
+		
    • Param-key-1 – {{ _('Description') }}
      • 
+		
    • Param-key-2 – {{ _('Description') }}
      • 
+		
    • Token – {% trans %}Token used for authenticating every request (excluding the 'Authenticate' RPC method){% endtrans %}
      • 
+	
    
+	
      {{ _('Response:') }}
+		
    • Result-key-1 – {{ _('Description') }}
      • 
+		
    • Result-key-2 – {{ _('Description') }}
      • 
+	
    
+

+
+
{% trans %}Implemented methods{% endtrans %}

+
    Authenticate – {% trans %}Creates and returns an authentication token used for further communication.{% endtrans %}
+	
      {{ _('Request:') }}
+		
    • API – [long] {% trans %}The version of the I2PControl API used by the client.{% endtrans %}
      • 
+		
    • Password – [String] {% trans %}The password used for authenticating against the remote server.{% endtrans %}
      • 
+	
    
+	
      {{ _('Response:') }}
+		
    • API – [long] {% trans %}The primary I2PControl API version implemented by the server.{% endtrans %}
      • 
+		
    • Token – [String] {% trans %}The token used for further communication.{% endtrans %}
      • 
+	
    
+

+
    Echo – {% trans %}Echoes the value of the echo key, used for debugging and testing.{% endtrans %}
+	
      {{ _('Request:') }}
+		
    • Echo – [String] {% trans %}Value will be returned in response.{% endtrans %}
      • 
+		
    • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
      • 
+	
    
+	
      {{ _('Response:') }}
+		
    • Result – [String] {% trans %}Value of the key 'echo' in the request.{% endtrans %}
      • 
+	
    
+

+
    GetRate – {% trans %}Fetches rateStat from router statManager. Creates stat if not already created.{% endtrans %}
+	
      {{ _('Request:') }}
+		
    • Stat – [String] {% trans ratestats=site_url('misc/ratestats') %}Determines which rateStat to fetch, see ratestats.{% endtrans %}
      • 
+		
    • Period – [long] {% trans %}Determines which period a stat is fetched for. Measured in ms.{% endtrans %}
      • 
+		
    • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
      • 
+	
    
+	
      {{ _('Response:') }}
+		
    • Result – [double] {% trans %}Returns the average value for the reuested rateStat and period.{% endtrans %}
      • 
+	
    
+

+
    I2PControl – {% trans %}Manages I2PControl. Ports, passwords and the like.{% endtrans %}
+	
      {{ _('Request:') }}
+		
    • *i2pcontrol.address – [String] {% trans %}Sets a new listen address for I2PControl (only 127.0.0.1 and 0.0.0.0 are implemented in I2PControl currently).{% endtrans %}
      • 
+		
    • *i2pcontrol.password – [String] {% trans %}Sets a new password for I2PControl, all Authentication tokens will be revoked.{% endtrans %}
      • 
+		
    • *i2pcontrol.port – [String] {% trans %}Switches which port I2PControl will listen for connections on.{% endtrans %}
      • 
+		
    • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
      • 
+	
    
+	
      {{ _('Response:') }}
+		
    • **i2pcontrol.address – [null] {% trans %}Returned if address was changed{% endtrans %}
      • 
+		
    • **i2pcontrol.password – [null] {% trans %}Returned if setting was changed{% endtrans %}
      • 
+		
    • **i2pcontrol.port – [null] {% trans %}Returned if setting was changed{% endtrans %}
      • 
+		
    • SettingsSaved – [Boolean] {% trans %}Returns true if any changes were made.{% endtrans %}
      • 
+		
    • RestartNeeded – [Boolean] {% trans %}Returns true if any changes requiring a restart to take effect were made.{% endtrans %}
      • 
+	
    
+

+
    RouterInfo – {% trans %}Fetches basic information about the I2P router. Uptime, version etc.{% endtrans %}
+	
      {{ _('Request:') }}
+		
    • *i2p.router.status – [n/a]
      • 
+		
    • *i2p.router.uptime – [n/a]
      • 
+		
    • *i2p.router.version	– [n/a]
      • 
+		
    • *i2p.router.net.bw.inbound.1s – [n/a] 
      • 
+		
    • *i2p.router.net.bw.inbound.15s – [n/a] 
      • 
+		
    • *i2p.router.net.bw.outbound.1s – [n/a] 
      • 
+		
    • *i2p.router.net.bw.outbound.15s – [n/a] 
      • 
+		
    • *i2p.router.net.status – [n/a]
      • 
+		
    • *i2p.router.net.tunnels.participating – [n/a] 
      • 
+		
    • *i2p.router.netdb.activepeers – [n/a] 
      • 
+		
    • *i2p.router.netdb.fastpeers – [n/a] 
      • 
+		
    • *i2p.router.netdb.highcapacitypeers – [n/a] 
      • 
+		
    • *i2p.router.netdb.isreseeding – [n/a] 
      • 
+		
    • *i2p.router.netdb.knownpeers – [n/a] 
      • 
+		
    • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
      • 
+	
    
+	
      {{ _('Response:') }}
+		
    • **i2p.router.status – [String] {% trans %}What the status of the router is.{% endtrans %}
      • 
+		
    • **i2p.router.uptime – [long] {% trans %}What the uptime of the router is in ms.{% endtrans %}
      • 
+		
    • **i2p.router.version – [String] {% trans %}What version of I2P the router is running.{% endtrans %}
      • 
+		
    • **i2p.router.net.bw.inbound.1s – [double] {% trans %}The 1 second average inbound bandwidth in Bps.{% endtrans %}
      • 
+		
    • **i2p.router.net.bw.inbound.15s – [double] {% trans %}The 15 second average inbound bandwidth in Bps.{% endtrans %}
      • 
+		
    • **i2p.router.net.bw.outbound.1s – [double] {% trans %}The 1 second average outbound bandwidth in Bps.{% endtrans %}
      • 
+		
    • **i2p.router.net.bw.outbound.15s – [double] {% trans %}The 15 second average outbound bandwidth in Bps.{% endtrans %}
      • 
+		
    • **i2p.router.net.status – [long] {% trans %}What the current network status is. According to the below enum:{% endtrans %}
+			
        
+				
      • 0 – OK
        • 
+				
      • 1 – TESTING
        • 
+				
      • 2 – FIREWALLED
        • 
+				
      • 3 – HIDDEN
        • 
+				
      • 4 – WARN_FIREWALLED_AND_FAST
        • 
+				
      • 5 – WARN_FIREWALLED_AND_FLOODFILL
        • 
+				
      • 6 – WARN_FIREWALLED_WITH_INBOUND_TCP
        • 
+				
      • 7 – WARN_FIREWALLED_WITH_UDP_DISABLED
        • 
+				
      • 8 – ERROR_I2CP
        • 
+				
      • 9 – ERROR_CLOCK_SKEW
        • 
+				
      • 10 – ERROR_PRIVATE_TCP_ADDRESS
        • 
+				
      • 11 – ERROR_SYMMETRIC_NAT
        • 
+				
      • 12 – ERROR_UDP_PORT_IN_USE
        • 
+				
      • 13 – ERROR_NO_ACTIVE_PEERS_CHECK_CONNECTION_AND_FIREWALL
        • 
+				
      • 14 – ERROR_UDP_DISABLED_AND_TCP_UNSET
        • 
+			
      
+		
      • 
+		
    • **i2p.router.net.tunnels.participating – [long] {% trans %}How many tunnels on the I2P net are we participating in.{% endtrans %}
      • 
+		
    • **i2p.router.netdb.activepeers – [long] {% trans %}How many peers have we communicated with recently.{% endtrans %}
      • 
+		
    • **i2p.router.netdb.fastpeers &ndasg; [long] {% trans %}How many peers are considered 'fast'.{% endtrans %}
      • 
+		
    • **i2p.router.netdb.highcapacitypeers – [long] {% trans %}How many peers are considered 'high capacity'.{% endtrans %}
      • 
+		
    • **i2p.router.netdb.isreseeding – [boolean] {% trans %}Is the router reseeding hosts to its NetDB?{% endtrans %}
      • 
+		
    • **i2p.router.netdb.knownpeers – [long] {% trans %}How many peers are known to us (listed in our NetDB).{% endtrans %}
      • 
+	
    
+

+
    RouterManager – {% trans %}Manages I2P router restart/shutdown.{% endtrans %}
+	
      {{ _('Request:') }}
+		
    • *Reseed – [n/a] {% trans %}Initiates a router reseed, fetching peers into our NetDB from a remote host.{% endtrans %}
      • 
+		
    • *Restart – [n/a] {% trans %}Restarts the router.{% endtrans %}
      • 
+		
    • *RestartGraceful – [n/a] {% trans %}Restarts the router gracefully (waits for participating tunnels to expire).{% endtrans %}
      • 
+		
    • *Shutdown – [n/a] {% trans %}Shuts down the router.{% endtrans %}
      • 
+		
    • *ShutdownGraceful – [n/a] {% trans %}Shuts down the router gracefully (waits for participating tunnels to expire).{% endtrans %}
      • 
+		
    • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
      • 
+	
    
+	
      {{ _('Response:') }}
+		
    • **Reseed – [null] {% trans %}If requested, verifies that a reseed has been initiated.{% endtrans %}
      • 
+		
    • **Restart – [null] {% trans %}If requested, verifies that a restart has been initiated.{% endtrans %}
      • 
+		
    • **RestartGraceful – [null] {% trans %}If requested, verifies that a graceful restart has been initiated.{% endtrans %}
      • 
+		
    • **Shutdown – [null] {% trans %}If requested, verifies that a shutdown has been initiated{% endtrans %}
      • 
+		
    • **ShutdownGraceful – [null] {% trans %}If requested, verifies that a graceful shutdown has been initiated{% endtrans %}
      • 
+	
    
+

+
    NetworkSetting – {% trans %}Fetches or sets various network related settings. Ports, addresses etc.{% endtrans %}
+	
      {{ _('Request:') }}
+		
    • *i2p.router.net.ntcp.port – [String] {% trans %}What port is used for the TCP transport. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.ntcp.hostname – [String] {% trans %}What hostname is used for the TCP transport. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.ntcp.autoip – [String] {% trans %}Use automatically detected ip for TCP transport. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.ssu.port – [String] {% trans %}What port is used for the UDP transport. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.ssu.hostname – [String] {% trans %}What hostname is used for the UDP transport. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.ssu.autoip – [String] {% trans %}Which methods should be used for detecting the ip address of the UDP transport. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.ssu.detectedip – [null] {% trans %}What ip has been detected by the UDP transport.{% endtrans %}
      • 
+		
    • *i2p.router.net.upnp – [String] {% trans %}Is UPnP enabled. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.bw.share – [String] {% trans %}How many percent of bandwidth is usable for participating tunnels. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.bw.in – [String] {% trans %}How many KB/s of inbound bandwidth is allowed. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.bw.out – [String] {% trans %}How many KB/s of outbound bandwidth is allowed. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • *i2p.router.net.laptopmode – [String] {% trans %}Is laptop mode enabled (change router identity and UDP port when IP changes ). If null is submitted, current setting will be returned.{% endtrans %}
      • 
+		
    • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method. If null is submitted, current setting will be returned.{% endtrans %}
      • 
+	
    
+	
      {{ _('Response:') }}
+		
    • **i2p.router.net.ntcp.port – [String] {% trans %}If requested, returns the port used for the TCP transport.{% endtrans %}
      • 
+		
    • **i2p.router.net.ntcp.hostname – [String] {% trans %}If requested, returns the hostname used for the TCP transport.{% endtrans %}
      • 
+		
    • **i2p.router.net.ntcp.autoip – [String] {% trans %}If requested, returns the method used for automatically detecting ip for the TCP transport.{% endtrans %}
      • 
+		
    • **i2p.router.net.ssu.port – [String] {% trans %}If requested, returns the port used for the UDP transport.{% endtrans %}
      • 
+		
    • **i2p.router.net.ssu.hostname – [String] {% trans %}If requested, returns the hostname used for the UDP transport.{% endtrans %}
      • 
+		
    • **i2p.router.net.ssu.autoip – [String] {% trans %}If requested, returns methods used for detecting the ip address of the UDP transport.{% endtrans %}
      • 
+		
    • **i2p.router.net.ssu.detectedip – [String] {% trans %}If requested, returns what ip has been detected by the UDP transport.{% endtrans %}
      • 
+		
    • **i2p.router.net.upnp – [String] {% trans %}If requested, returns the UPNP setting.{% endtrans %}
      • 
+		
    • **i2p.router.net.bw.share – [String] {% trans %}If requested, returns how many percent of bandwidth is usable for participating tunnels.{% endtrans %}
      • 
+		
    • **i2p.router.net.bw.in – [String] {% trans %}If requested, returns how many KB/s of inbound bandwidth is allowed.{% endtrans %}
      • 
+		
    • **i2p.router.net.bw.out – [String] {% trans %}If requested, returns how many KB/s of outbound bandwidth is allowed.{% endtrans %}
      • 
+		
    • **i2p.router.net.laptopmode – [String] {% trans %}If requested, returns the laptop mode.{% endtrans %}
      • 
+		
    • SettingsSaved – [boolean] {% trans %}Have the provided settings been saved.{% endtrans %}
      • 
+		
    • RestartNeeded – [boolean] {% trans %}Is a restart needed for the new settings to be used.{% endtrans %}
      • 
+	
    
+

+
* {% trans %}denotes an optional value.{% endtrans %}

+
** {% trans %}denotes a possibly occuring return value{% endtrans %}

+
+
{% trans %}Error codes{% endtrans %}

+
    {% trans %}Standard JSON-RPC2 error codes.{% endtrans %}
+	
  • -32700 – {% trans %}JSON parse error.{% endtrans %}
    • 
+	
  • -32600 – {% trans %}Invalid request.{% endtrans %}
    • 
+	
  • -32601 – {% trans %}Method not found.{% endtrans %}
    • 
+	
  • -32603 – {% trans %}Internal error.{% endtrans %}
    • 
+

+
    {% trans %}I2PControl specific error codes.{% endtrans %}
+	
  • -32001 – {% trans %}Invalid password provided.{% endtrans %}
    • 
+	
  • -32002 – {% trans %}No authentication token presented.{% endtrans %}
    • 
+	
  • -32003 – {% trans %}Authentication token doesn't exist.{% endtrans %}
    • 
+	
  • -32004 – {% trans %}The provided authentication token was expired and will be removed.{% endtrans %}
    • 
+	
  • -32005 – {% trans %}The version of the I2PControl API used wasn't specified, but is required to be specified.{% endtrans %}
    • 
+	
  • -32006 – {% trans %}The version of the I2PControl API specified is not supported by I2PControl.{% endtrans %}
    • 
+

+
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/api/i2ptunnel.html b/i2p2www/pages/site/docs/api/i2ptunnel.html
new file mode 100644
index 00000000..608ab170
--- /dev/null
+++ b/i2p2www/pages/site/docs/api/i2ptunnel.html
@@ -0,0 +1,166 @@
+{% extends "global/layout.html" %}
+{% block title %}i2ptunnel{% endblock %}
+{% block content %}
+
+
+
I2PTunnel

+
{% trans %}Overview{% endtrans %}

+
{% trans naming=site_url('docs/naming') -%}
+I2PTunnel is a tool for interfacing with and providing services on I2P.
+Destination of an I2PTunnel can be defined using a hostname,
+Base32, or a full 516-byte destination key.
+An established I2PTunnel will be available on your client machine as localhost:port.
+If you wish to provide a service on I2P network, you simply create I2PTunnel to the
+appropriate ip_address:port. A corresponding 516-byte destination key will be generated
+for the service and it will become avaliable throughout I2P.
+A web interface for I2PTunnel management is avaliable on
+localhost:7657/i2ptunnel/.
+{%- endtrans %}

+
+
{% trans %}Default Services{% endtrans %}

+
{% trans %}Server tunnels{% endtrans %}

+
    
+
  • {% trans -%}
+I2P Webserver - A tunnel pointed to a Jetty webserver run
+on localhost:7658 for convenient and quick hosting on I2P.
+
    The document root is:{% endtrans %}
+
    Unix - %APPDATA%\I2P\eepsite\docroot
+
    Windows - C:\Users\**username**\AppData\Roaming\I2P\eepsite\docroot
+
    • 
+

+
{% trans %}Client tunnels{% endtrans %}

+
    
+
  • I2P HTTP Proxy - localhost:4444 - {% trans -%}
+A HTTP proxy used for browsing I2P and the regular internet anonymously through I2P. 
+Browsing internet through I2P uses a random proxy specified by the "Outproxies:" option.
+{%- endtrans %}
    • 
+
  • Irc2P - localhost:6668 - {% trans %}An IRC tunnel to the default anonymous IRC network, Irc2P.{% endtrans %}
    • 
+
  • mtn.i2p2.i2p - localhost:8998 - {% trans -%}
+The anonymous monotone
+sourcecode repository for I2P
+{%- endtrans %}
    • 
+
  • smtp.postman.i2p - localhost:7659 - {% trans postman=i2pconv('hq.postman.i2p') -%}
+A SMTP service provided by postman at {{ postman }}
+{%- endtrans %}
    • 
+
  • pop3.postman.i2p - localhost:7660 - {% trans postman=i2pconv('hq.postman.i2p') -%}
+The accompanying POP sevice of postman at {{ postman }}
+{%- endtrans %}
    • 
+

+
+
{% trans %}Client Modes{% endtrans %}

+
{% trans %}Standard{% endtrans %}

+
{% trans -%}
+Opens a local TCP port that connects to a service (like HTTP, FTP or SMTP) on a destination inside of I2P.
+The tunnel is directed to a random host from the comma seperated (", ") list of destinations.
+{%- endtrans %}

+
+
HTTP

+
{% trans -%}
+A HTTP-client tunnel. The tunnel connects to the destination specified by the URL
+in a HTTP request. Supports proxying onto internet if an outproxy is provided. Strips HTTP connections of the following headers:
+{%- endtrans %}

+
    
+
  • {% trans -%}
+Accept, Accept-Charset, Accept-Encoding, Accept-Language
+ and Accept-Ranges as they vary greatly between browsers and can be used as an identifier.
+{%- endtrans %}
    • 
+
  • Referer:
    • 
+
  • Via:
    • 
+
  • From:
    • 
+

+
{% trans -%}
+HTTP client/server tunnels are via I2Ptunnel force-enabling compression via the following http headers:
+{%- endtrans %}

+
    
+
  • Accept-Encoding: 
    • 
+
  • X-Accept-Encoding:  x-i2p-gzip;q=1.0, identity;q=0.5, deflate;q=0, gzip;q=0, *;q=0
    • 
+

+
{% trans -%}
+Depending on if the tunnel is using an outproxy or not it will append the following User-Agent: 
+{%- endtrans %}

+
    
+
  • {% trans %}Outproxy:{% endtrans %} User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
    • 
+
  • {% trans %}Internal I2P use:{% endtrans %} User-Agent: MYOB/6.66 (AN/ON)
    • 
+

+

+
+
IRC

+
{% trans -%}
+Creates a connection to a random IRC server specified by the comma seprated (", ") 
+list of destinations. Only a whitelisted subset of IRC commands are allowed due to anonymity concerns.
+{%- endtrans %}
+
{% trans %}Whitelist:{% endtrans %}

+
    
+
  • MODE
    • 
+
  • JOIN
    • 
+
  • NICK
    • 
+
  • QUIT
    • 
+
  • PART
    • 
+
  • WALLOPS
    • 
+
  • ERROR
    • 
+
  • KICK
    • 
+
  • H
    • 
+
  • TOPIC
    • 
+

+
+
SOCKS 4/4a/5

+
{% trans -%}
+Enables using the I2P router as a SOCKS proxy.
+{%- endtrans %}

+
+
SOCKS IRC

+
{% trans -%}
+Enables using the I2P router as a SOCKS proxy with the command whitelist specified by
+IRC client mode.
+{%- endtrans %}

+
+
CONNECT

+
{% trans -%}
+Creates a HTTP tunnel and uses the HTTP request method "CONNECT" 
+to build a TCP tunnel that usually is used for SSL and HTTPS.
+{%- endtrans %}

+
+
Streamr

+
{% trans -%}
+Creates a UDP-server attached to a Streamr client I2PTunnel. The streamr client tunnel will 
+subscribe to a streamr server tunnel.
+{%- endtrans %}

+
+
+
+

+
{% trans %}Server Modes{% endtrans %}

+
{% trans %}Standard{% endtrans %}

+
{% trans -%}
+Creates a destination to a local ip:port with an open TCP port.
+{%- endtrans %}

+
+
HTTP

+
{% trans -%}
+Creates a destination to a local HTTP server ip:port. Supports gzip for requests with 
+Accept-encoding: x-i2p-gzip, replies with Content-encoding: x-i2p-gzip in such a request.
+{%- endtrans %}

+
+
HTTP Bidirectional

+
{% trans -%}
+Functions as both a I2PTunnel HTTP Server, and a I2PTunnel HTTP client with no outproxying
+capabilities. An example application would be a web application that does client-type
+requests, or loopback-testing an eepsite as a diagnostic tool.
+{%- endtrans %}

+
+
IRC

+
{% trans -%}
+Creates a destination that filters the reqistration sequence of a client and passes 
+the clients destination key as a hostname to the IRC-server.
+{%- endtrans %}

+
+
Streamr

+
{% trans -%}
+A UDP-client that connects to a media server is created. The UDP-Client is coupled with a Streamr server I2PTunnel.
+{%- endtrans %}

+{% endblock %}
diff --git a/www.i2p2/pages/ministreaming.html b/i2p2www/pages/site/docs/api/ministreaming.html
similarity index 54%
rename from www.i2p2/pages/ministreaming.html
rename to i2p2www/pages/site/docs/api/ministreaming.html
index ac950db5..82b91d80 100644
--- a/www.i2p2/pages/ministreaming.html
+++ b/i2p2www/pages/site/docs/api/ministreaming.html
@@ -1,47 +1,56 @@
-{% extends "_layout.html" %}
-{% block title %}Ministreaming Library{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Ministreaming Library{% endtrans %}{% endblock %}
 {% block content %}
 
-
Note

+
{% trans %}Note{% endtrans %}

+
+
{% trans streaming=site_url('docs/api/streaming'), api='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/package-summary.html' -%}
 The ministreaming library has been enhanced and extended by the
-"full" streaming library.
+"full" streaming library.
 Ministreaming is deprecated and is incompatible with today's applications.
 The following documentation is old.
 Also note that streaming extends ministreaming in the same Java package (net.i2p.client.streaming),
-so the current
-API documentation
-contains both.
+so the current API documentation contains both.
 Obsolete ministreaming classes and methods are clearly marked as deprecated in the Javadocs.
+{%- endtrans %}

 
-
Ministreaming Library

+
{% trans %}Ministreaming Library{% endtrans %}

 
-
The ministreaming library is a layer on top of the core 
-I2CP that allows reliable, in order, and authenticated streams
+
{% trans i2cp=site_url('docs/protocol/i2cp') %}
+The ministreaming library is a layer on top of the core 
+I2CP that allows reliable, in order, and authenticated streams
 of messages to operate across an unreliable, unordered, and unauthenticated 
 message layer.  Just like the TCP to IP relationship, this streaming 
 functionality has a whole series of tradeoffs and optimizations available, but
 rather than embed that functionality into the base I2P code, it has been factored
 off into its own library both to keep the TCP-esque complexities separate and to
-allow alternative optimized implementations.

+allow alternative optimized implementations.
+{%- endtrans %}

 
-
The ministreaming library was written by mihi as a part of his 
-I2PTunnel application and then factored out and released
+
{% trans i2ptunnel=site_url('docs/api/i2ptunnel'), minwww=site_url('misc/minwww') -%}
+The ministreaming library was written by mihi as a part of his 
+I2PTunnel application and then factored out and released
 under the BSD license.  It is called the "mini"streaming library because it makes
 some simplifications in the implementation, while a more robust streaming library
 could be further optimized for operation over I2P.  The two main issues with 
 the ministreaming library are its use of the traditional TCP two phase 
 establishment protocol and the current fixed window size of 1.  The establishment
 issue is minor for long lived streams, but for short ones, such as quick HTTP
-requests, the impact can be significant.  As for the window
+requests, the impact can be significant.  As for the window
 size, the ministreaming library doesn't maintain any ID or ordering within the 
 messages sent (or include any application level ACK or SACK), so it must wait 
-on average twice the time it takes to send a message before sending another.

+on average twice the time it takes to send a message before sending another.
+{%- endtrans %}

 
-
Even with those issues, the ministreaming library performs quite well in many
-situations, and its API
+
{% trans api='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/package-summary.html',
+samv3=site_url('docs/api/samv3') -%}
+Even with those issues, the ministreaming library performs quite well in many
+situations, and its API
 is both quite simple and capable of remaining unchanged as different streaming
 implementations are introduced.  The library is deployed in its own 
 ministreaming.jar.
 Developers in Java who would like to use it can
 access the API directly, while developers in other languages can use it through
-SAM's streaming support.
{% endblock %}
+SAM's streaming support.
+{%- endtrans %}

+{% endblock %}
diff --git a/www.i2p2/pages/sam.html b/i2p2www/pages/site/docs/api/sam.html
similarity index 92%
rename from www.i2p2/pages/sam.html
rename to i2p2www/pages/site/docs/api/sam.html
index f24d8af8..3297fe63 100644
--- a/www.i2p2/pages/sam.html
+++ b/i2p2www/pages/site/docs/api/sam.html
@@ -1,16 +1,18 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}SAM V1 Specification{% endblock %}
+{% block lastupdated %}August 2010{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
 {% block content %}
-Updated August 2010 for release 0.8
 
Specified below is version 1 of a simple client protocol for interacting with
 I2P.
 Newer alternatives:
-SAM V2,
-SAM V3,
-BOB.
+SAM V2,
+SAM V3,
+BOB.
 

 
-
----------------------------------------------------------------------
+
+----------------------------------------------------------------------
 Simple Anonymous Messaging (SAM version 1.0) Specification
 ----------------------------------------------------------------------
 Client application talks to SAM bridge, which deals with
@@ -32,9 +34,9 @@ the key=value pairs can change (e.g. "ONE TWO A=B C=D" or
 addition, the protocol is case-sensitive.
 
 Communication can take three distinct forms:
-* Virtual streams
-* Repliable datagrams (messages with a FROM field)
-* Anonymous datagrams (raw anonymous messages)
+* Virtual streams
+* Repliable datagrams (messages with a FROM field)
+* Anonymous datagrams (raw anonymous messages)
 
 ----------------------------------------------------------------------
 SAM connection handshake
@@ -332,8 +334,8 @@ Tunnel, I2CP, and Streaming Options
 These options may be passed in as name=value pairs at the end of a
 SAM SESSION CREATE line.
 
-All sessions may include I2CP options such as tunnel lengths.
-STREAM sessions may include Streaming lib options.
+All sessions may include I2CP options such as tunnel lengths.
+STREAM sessions may include Streaming lib options.
 See those references for option names and defaults.
 
 
@@ -349,7 +351,7 @@ Client library implementations:
 ---------------------------------------------------------------------- 
 
 Client libraries are available for C, C++, C#, Perl, and Python.
-These are in the apps/sam/ directory in the I2P Source Package.
+These are in the apps/sam/ directory in the I2P Source Package.
 
 
 ----------------------------------------------------------------------
diff --git a/www.i2p2/pages/samv2.html b/i2p2www/pages/site/docs/api/samv2.html
similarity index 93%
rename from www.i2p2/pages/samv2.html
rename to i2p2www/pages/site/docs/api/samv2.html
index 333da68c..b4707c90 100644
--- a/www.i2p2/pages/samv2.html
+++ b/i2p2www/pages/site/docs/api/samv2.html
@@ -1,16 +1,17 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}SAM V2 Specification{% endblock %}
+{% block lastupdated %}August 2010{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
 {% block content %}
-Updated August 2010 for release 0.8
 
Specified below is a simple client protocol for interacting with I2P.
 

 

 SAM V2 was introduced in I2P release 0.6.1.31.
 Significant differences from SAM V1 are marked with "***".
 Alternatives:
-SAM V1,
-SAM V3,
-BOB.
+SAM V1,
+SAM V3,
+BOB.
 

 
 

@@ -20,7 +21,7 @@ on the same I2P destination in parallel, i.e. the client does not
 have to wait for data being successfully sent on one socket before sending
 data on another socket. All data transits through the same
 client<-->SAM socket.
-For multiple sockets, see SAM V3.
+For multiple sockets, see SAM V3.
 

 
 
@@ -46,9 +47,9 @@ the key=value pairs can change (e.g. "ONE TWO A=B C=D" or
 addition, the protocol is case-sensitive.
 
 Communication can take three distinct forms:
-* Virtual streams
-* Repliable datagrams (messages with a FROM field)
-* Anonymous datagrams (raw anonymous messages)
+* Virtual streams
+* Repliable datagrams (messages with a FROM field)
+* Anonymous datagrams (raw anonymous messages)
 
 ----------------------------------------------------------------------
 SAM connection handshake
@@ -400,8 +401,8 @@ Tunnel, I2CP, and Streaming Options
 These options may be passed in as name=value pairs at the end of a
 SAM SESSION CREATE line.
 
-All sessions may include I2CP options such as tunnel lengths.
-STREAM sessions may include Streaming lib options.
+All sessions may include I2CP options such as tunnel lengths.
+STREAM sessions may include Streaming lib options.
 See those references for option names and defaults.
 
 
@@ -416,7 +417,7 @@ Base 64 encoding must use the I2P standard Base 64 alphabet "A-Z, a-z, 0-9, -, ~
 Client library implementations:
 ---------------------------------------------------------------------- 
 Client libraries are available for C, C++, C#, Perl, and Python.
-These are in the apps/sam/ directory in the I2P Source Package.
+These are in the apps/sam/ directory in the I2P Source Package.
 Some may be older and have not been updated for SAMv2 support.
 
 
diff --git a/www.i2p2/pages/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
similarity index 94%
rename from www.i2p2/pages/samv3.html
rename to i2p2www/pages/site/docs/api/samv3.html
index 3e32ec37..5c46f858 100644
--- a/www.i2p2/pages/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -1,15 +1,16 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}SAM V3{% endblock %}
+{% block lastupdated %}August 2010{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
 {% block content %}
-Updated August 2010 for release 0.8
 
Specified below is a simple client protocol for interacting with I2P.
 

 
SAM version 3
 was introduced in I2P release 0.7.3.
 Alternatives:
-SAM V1,
-SAM V2,
-BOB.
+SAM V1,
+SAM V2,
+BOB.
 

 
 

@@ -22,7 +23,7 @@ client<-->SAM socket, which was quite complicated to manage for the client
 

 SAM v3 manages sockets in a different way: each I2P socket
 matches a unique client<-->SAM socket, which is much more simple to handle.
-This is similar to BOB.
+This is similar to BOB.
 

 SAM v3 also offers a UDP port for sending datagrams through I2P, and
 can forward back I2P datagrams to the client's datagram server.
@@ -55,9 +56,9 @@ messages sent by the client to the SAM bridge, and by "<- " for
 messages sent by the SAM bridge to the client.
 
 I2P communications can take three distinct forms:
-* Virtual streams
-* Repliable datagrams (messages with a FROM field)
-* Anonymous datagrams (raw anonymous messages)
+* Virtual streams
+* Repliable datagrams (messages with a FROM field)
+* Anonymous datagrams (raw anonymous messages)
 
 I2P communications are supported by I2P sessions, and each I2P
 session is bound to an address (called destination). An I2P session
@@ -484,8 +485,8 @@ Tunnel, I2CP, and Streaming Options
 These options may be passed in as name=value pairs at the end of a
 SAM SESSION CREATE line.
 
-All sessions may include I2CP options such as tunnel lengths.
-STREAM sessions may include Streaming lib options.
+All sessions may include I2CP options such as tunnel lengths.
+STREAM sessions may include Streaming lib options.
 See those references for option names and defaults.
 
 
@@ -500,7 +501,7 @@ Base 64 encoding must use the I2P standard Base 64 alphabet "A-Z, a-z, 0-9, -, ~
 Client library implementations:
 ---------------------------------------------------------------------- 
 Client libraries are available for C, C++, C#, Perl, and Python.
-These are in the apps/sam/ directory in the I2P Source Package.
+These are in the apps/sam/ directory in the I2P Source Package.
 Some may be older and have not been updated for SAMv3 support.
 
 
diff --git a/i2p2www/pages/site/docs/api/socks.html b/i2p2www/pages/site/docs/api/socks.html
new file mode 100644
index 00000000..b31a1552
--- /dev/null
+++ b/i2p2www/pages/site/docs/api/socks.html
@@ -0,0 +1,75 @@
+{% extends "global/layout.html" %}
+{% block title %}SOCKS{% endblock %}
+{% block content %}
+
{% trans %}SOCKS and SOCKS proxies{% endtrans %}

+
{% trans %}
+The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are supported.
+Enable SOCKS by creating a SOCKS client tunnel in i2ptunnel.
+Both shared-clients and non-shared are supported.
+There is no SOCKS outproxy so it is of limited use.
+{%- endtrans %}

+
+
{% trans faq=site_url('faq') %}
+As it says on the FAQ:
+{%- endtrans %}

+
{% trans -%}
+Many applications leak sensitive
+information that could identify you on the Internet. I2P only filters
+connection data, but if the program you intend to run sends this
+information as content, I2P has no way to protect your anonymity.  For
+example, some mail applications will send the IP address of the machine
+they are running on to a mail server. There is no way for I2P to filter
+this, thus using I2P to 'socksify' existing applications is possible, but
+extremely dangerous.
+{%- endtrans %}

+
{% trans -%}
+And quoting from a 2005 email:
+{%- endtrans %}

+
{% trans -%}
+... there is a reason why human and
+others have both built and abandoned the SOCKS proxies.  Forwarding
+arbitrary traffic is just plain unsafe, and it behooves us as
+developers of anonymity and security software to have the safety of
+our end users foremost in our minds.
+{%- endtrans %}

+
+
{% trans -%}
+Hoping that we can simply strap an arbitrary client on top of I2P
+without auditing both its behavior and its exposed protocols for
+security and anonymity is naive.  Pretty much *every* application
+and protocol violates anonymity, unless it was designed for it
+specifically, and even then, most of those do too.  That's the
+reality.  End users are better served with systems designed for
+anonymity and security.  Modifying existing systems to work in
+anonymous environments is no small feat, orders of magnitude more
+work that simply using the existing I2P APIs.
+{%- endtrans %}

+
+
{% trans -%}
+The SOCKS proxy
+supports standard addressbook names, but not Base64 destinations.
+Base32 hashes should work as of release 0.7.
+It supports outgoing connections only, i.e. an I2PTunnel Client.
+UDP support is stubbed out but not working yet.
+Outproxy selection by port number is stubbed out.
+{%- endtrans %}

+
+
{% trans %}See Also{% endtrans %}

+
+
+
{% trans %}If You Do Get Something Working{% endtrans %}

+
{% trans -%}
+Please let us know. And please provide substantial warnings about the
+risks of socks proxies.
+{%- endtrans %}
+
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/api/streaming.html b/i2p2www/pages/site/docs/api/streaming.html
new file mode 100644
index 00000000..a7c60e2a
--- /dev/null
+++ b/i2p2www/pages/site/docs/api/streaming.html
@@ -0,0 +1,463 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Streaming Library{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}November 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.3{% endblock %}
+{% block content %}
+
{% trans %}Overview{% endtrans %}

+
+
{% trans datagrams=site_url('docs/spec/datagrams') -%}
+The streaming library is technically part of the "application" layer,
+as it is not a core router function.
+In practice, however, it provides a vital function for almost all
+existing I2P applications, by providing a TCP-like
+streams over I2P, and allowing existing apps to be easily ported to I2P.
+The other end-to-end transport library for client communication is the
+datagram library.
+{%- endtrans %}

+
+
{% trans i2cp=site_url('docs/protocol/i2cp') -%}
+The streaming library is a layer on top of the core 
+I2CP API that allows reliable, in-order, and authenticated streams
+of messages to operate across an unreliable, unordered, and unauthenticated 
+message layer.  Just like the TCP to IP relationship, this streaming 
+functionality has a whole series of tradeoffs and optimizations available, but
+rather than embed that functionality into the base I2P code, it has been factored
+off into its own library both to keep the TCP-esque complexities separate and to
+allow alternative optimized implementations.
+{%- endtrans %}

+
+
{% trans -%}
+In consideration of the relatively high cost of messages, 
+the streaming library's protocol for scheduling and delivering those messages has been optimized to
+allow individual messages passed to contain as much information as is available.
+For instance, a small HTTP transaction proxied through the streaming library can
+be completed in a single round trip - the first messages bundle a SYN, FIN, and
+the small HTTP request payload, and the reply bundles the SYN,
+FIN, ACK, and the HTTP response payload.  While an additional
+ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has been
+received, the local HTTP proxy can often deliver the full response to the browser 
+immediately.
+{%- endtrans %}

+
+
{% trans -%}
+The streaming library bears much resemblance to an 
+abstraction of TCP, with its sliding windows, congestion control algorithms
+(both slow start and congestion avoidance), and general packet behavior (ACK,
+SYN, FIN, RST, rto calculation, etc).  
+{%- endtrans %}

+
+
{% trans -%}
+The streaming library is
+a robust library
+which is optimized for operation over I2P.
+It has a one-phase setup, and
+it contains a full windowing implementation.
+{%- endtrans %}

+
+
+
{% trans %}API{% endtrans %}

+
+
{% trans i2cp=site_url('docs/protocol/i2cp') -%}
+The streaming library API provides a standard socket paradigm to Java applications.
+The lower-level I2CP API is completely hidden, except that
+applications may pass I2CP parameters through the
+streaming library, to be interpreted by I2CP.
+{%- endtrans %}

+
+
{% trans i2cp=site_url('docs/protocol/i2cp'),
+i2psktmf='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocketManagerFactory.html',
+i2psktm='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocketManager.html',
+i2psess='http://docs.i2p-projekt.de/javadoc/net/i2p/client/I2PSession.html',
+i2pskt='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocket.html',
+i2psskt='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PServerSocket.html' -%}
+The standard interface to the streaming lib is for the application to use the
+I2PSocketManagerFactory to create an
+I2PSocketManager. The application then asks the
+socket manager for an I2PSession, which will cause
+a connection to the router via I2CP. The application
+can then setup connections with an I2PSocket or
+receive connections with an I2PServerSocket.
+{%- endtrans %}

+
+
{% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/package-summary.html' -%}
+Here are the full streaming library Javadocs.
+{%- endtrans %}

+
+
{% trans -%}
+For a good example of usage, see the i2psnark code.
+{%- endtrans %}

+
+
+
{% trans %}Options and Defaults{% endtrans %}

+
{% trans i2psktmf='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocketManagerFactory.html' -%}
+The options and current default values are listed below.
+Options are case-sensitive and may be set for the whole router, for a particular client, or for an individual socket on a
+per-connection basis.
+Many values are tuned for HTTP performance over typical I2P conditions. Other applications such
+as peer-to-peer services are strongly encouraged to
+modify as necessary, by setting the options and passing them via the call to
+I2PSocketManagerFactory.createManager(_i2cpHost, _i2cpPort, opts).
+Time values are in ms.
+{%- endtrans %}

+
+
{% trans samv3=site_url('docs/api/samv3'), bob=site_url('docs/api/bob'), i2ptunnel=site_url('docs/api/i2ptunnel') -%}
+Note that higher-layer APIs, such as SAM,
+BOB, and I2PTunnel,
+may override these defaults with their own defaults.
+Also note that many options only apply to servers listening for incoming connections.
+{%- endtrans %}

+
+
{% trans -%}
+As of release 0.9.1, most, but not all, options may be changed on an active socket manager or session.
+See the javadocs for details.
+{%- endtrans %}

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
{{ _('Option') }}{{ _('Default') }}{{ _('Notes') }}
i2cp.accessListnull{% trans -%}
+Comma- or space-separated list of Base64 peer Hashes used for either access list or blacklist.
+{%- endtrans %} {% trans release='0.7.13' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2cp.enableAccessListfalse{% trans -%}
+Use the access list as a whitelist for incoming connections.
+{%- endtrans %} {% trans release='0.7.13' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2cp.enableBlackListfalse{% trans -%}
+Use the access list as a blacklist for incoming connections.
+{%- endtrans %} {% trans release='0.7.13' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.answerPingstrue{% trans -%}
+Whether to respond to incoming pings
+{%- endtrans %}
i2p.streaming.blacklistnull{% trans -%}
+Comma- or space-separated list of Base64 peer Hashes to be
+blacklisted for incoming connections to ALL destinations in the context.
+This option must be set in the context properties, NOT in the createManager() options argument.
+Note that setting this in the router context will not affect clients outside the
+router in a separate JVM and context.
+{%- endtrans %} {% trans release='0.9.3' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.bufferSize64K{% trans -%}
+How much transmit data (in bytes) will be accepted that hasn't been written out yet.
+{%- endtrans %}
i2p.streaming.congestionAvoidanceGrowthRateFactor1{% trans -%}
+When we're in congestion avoidance, we grow the window size at the rate
+of 1/(windowSize*factor).  In standard TCP, window sizes are in bytes,
+while in I2P, window sizes are in messages.
+A higher number means slower growth.
+{%- endtrans %}
i2p.streaming.connectDelay-1{% trans -%}
+How long to wait after instantiating a new con 
+before actually attempting to connect.  If this is
+<= 0, connect immediately with no initial data.  If greater than 0, wait
+until the output stream is flushed, the buffer fills, 
+or that many milliseconds pass, and include any initial data with the SYN.
+{%- endtrans %}
i2p.streaming.connectTimeout5*60*1000{% trans -%}
+How long to block on connect, in milliseconds. Negative means indefinitely. Default is 5 minutes.
+{%- endtrans %}
i2p.streaming.disableRejectLoggingfalse{% trans -%}
+Whether to disable warnings in the logs when an incoming connection is rejected due to connection limits.
+{%- endtrans %} {% trans release='0.9.4' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.enforceProtocolfalse{% trans -%}
+Whether to listen only for the streaming protocol.
+Setting to true will prohibit communication with Destinations earlier than release 0.7.1
+(released March 2009). Set to true if running multiple protocols on this Destination.
+{%- endtrans %} {% trans release='0.9.1' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.inactivityAction2 (send) {% trans -%}
+(0=noop, 1=disconnect)
+What to do on an inactivity timeout - do nothing, disconnect, or send a duplicate ack.
+{%- endtrans %}
i2p.streaming.inactivityTimeout90*1000
i2p.streaming.initialAckDelay2000
i2p.streaming.initialResendDelay1000{% trans -%}
+The initial value of the resend delay field in the packet header, times 1000.
+Not fully implemented; see below.
+{%- endtrans %}
i2p.streaming.initialRTT8000 ({% trans %}if no sharing data available{% endtrans %})
i2p.streaming.initialWindowSize6({% trans %}if no sharing data available{% endtrans %}) {% trans -%}
+In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages.
+{%- endtrans %}
i2p.streaming.maxConcurrentStreams-1 {% trans -%}
+(0 or negative value means unlimited)
+This is a total limit for incoming and outgoing combined.
+{%- endtrans %}
i2p.streaming.maxConnsPerMinute0 {% trans -%}
+Incoming connection limit (per peer; 0 means disabled)
+{%- endtrans %} {% trans release='0.7.14' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.maxConnsPerHour0 {% trans -%}
+(per peer; 0 means disabled)
+{%- endtrans %} {% trans release='0.7.14' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.maxConnsPerDay0 {% trans -%}
+(per peer; 0 means disabled)
+{%- endtrans %} {% trans release='0.7.14' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.maxMessageSize1730{% trans -%}
+The MTU in bytes.
+{%- endtrans %}
i2p.streaming.maxResends8{% trans -%}
+Maximum number of retransmissions before failure.
+{%- endtrans %}
i2p.streaming.maxTotalConnsPerMinute0 {% trans -%}
+Incoming connection limit (all peers; 0 means disabled)
+{%- endtrans %} {% trans release='0.7.14' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.maxTotalConnsPerHour0 {% trans -%}
+(all peers; 0 means disabled)
+Use with caution as exceeding this will disable a server for a long time.
+{%- endtrans %} {% trans release='0.7.14' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.maxTotalConnsPerDay0 {% trans -%}
+(all peers; 0 means disabled)
+Use with caution as exceeding this will disable a server for a long time.
+{%- endtrans %} {% trans release='0.7.14' -%}
+As of release {{ release }}.
+{%- endtrans %}
i2p.streaming.maxWindowSize128
i2p.streaming.profile1 (bulk){% trans -%}
+(2=interactive not supported)
+This doesn't currently do anything, but setting it to a value other than 1 will cause an error.
+{%- endtrans %}
i2p.streaming.readTimeout-1{% trans -%}
+How long to block on read, in milliseconds. Negative means indefinitely.
+{%- endtrans %}
i2p.streaming.slowStartGrowthRateFactor1{% trans -%}
+When we're in slow start, we grow the window size at the rate
+of 1/(factor).  In standard TCP, window sizes are in bytes,
+while in I2P, window sizes are in messages.
+A higher number means slower growth.
+{%- endtrans %}
i2p.streaming.writeTimeout-1{% trans -%}
+How long to block on write/flush, in milliseconds. Negative means indefinitely.
+{%- endtrans %}

+
+
+
+
+
{% trans %}Protocol Specification{% endtrans %}

+
+
{% trans -%}
+See the Streaming Library Specification page.
+{%- endtrans %}

+
+
{% trans %}Implementation Details{% endtrans %}

+
+
{% trans %}Setup{% endtrans %}

+
{% trans -%}
+The initiator sends a packet with the SYNCHRONIZE flag set. This packet may contain the initial data as well.
+The peer replies with a packet with the SYNCHRONIZE flag set. This packet may contain the initial response data as well.
+{%- endtrans %}

+
+
{% trans -%}
+The initiator may send additional data packets, up to the initial window size, before receiving the SYNCHRONIZE response.
+These packets will also have the send Stream ID field set to 0.
+Recipients must buffer packets received on unknown streams for a short period of time, as they may
+arrive out of order, in advance of the SYNCHRONIZE packet.
+{%- endtrans %}

+
+
{% trans %}MTU Selection and Negotiation{% endtrans %}

+
{% trans -%}
+The maximum message size (also called the MTU / MRU) is negotiated to the lower value supported by
+the two peers. As tunnel messages are padded to 1KB, a poor MTU selection will lead to
+a large amount of overhead.
+The MTU is specified by the option i2p.streaming.maxMessageSize.
+The current default MTU of 1730 was chosen to fit precisely into two 1K I2NP tunnel messages,
+including overhead for the typical case.
+{%- endtrans %}

+
+
{% trans -%}
+The first message in a connection includes a 387 byte (typical) Destination added by the streaming layer,
+and usually a 898 byte (typical) LeaseSet, and Session keys, bundled in the Garlic message by the router.
+(The LeaseSet and Session Keys will not be bundled if an ElGamal Session was previously established).
+Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not always attainable.
+However, the selection of the MTU, together with careful implementation of fragmentation
+and batching strategies in the tunnel gateway processor, are important factors in network bandwidth,
+latency, reliability, and efficiency, especially for long-lived connections.
+{%- endtrans %}

+
+
{% trans %}Data Integrity{% endtrans %}

+
{% trans i2cp=site_url('docs/protocol/i2cp') -%}
+Data integrity is assured by the gzip CRC-32 checksum implemented in
+the I2CP layer.
+There is no checksum field in the streaming protocol.
+{%- endtrans %}

+
+
+
{% trans %}Packet Encapsulation{% endtrans %}

+
{% trans garlicrouting=site_url('docs/how/garlic-routing'), i2cp=site_url('docs/protocol/i2cp'),
+i2np=site_url('docs/protocol/i2np'), tunnelmessage=site_url('docs/spec/tunnel-message') -%}
+Each packet is sent through I2P as a single message (or as an individual clove in a
+Garlic Message). Message encapsulation is implemented
+in the underlying I2CP, I2NP, and
+tunnel message layers. There is no packet delimiter
+mechanism or payload length field in the streaming protocol.
+{%- endtrans %}

+
+
+
{% trans %}Windowing{% endtrans %}

+
{% trans -%}
+The streaming lib uses standard slow-start (exponential window growth) and congestion avoidance (linear window growth)
+phases, with exponential backoff.
+Windowing and acknowledgments use packet count, not byte count.
+{%- endtrans %}

+
+
+
{% trans %}Close{% endtrans %}

+
{% trans -%}
+Any packet, including one with the SYNCHRONIZE flag set, may have the CLOSE flag sent as well.
+The connection is not closed until the peer responds with the CLOSE flag.
+CLOSE packets may contain data as well.
+{%- endtrans %}

+
+
+
{% trans %}Control Block Sharing{% endtrans %}

+
{% trans -%}
+The streaming lib supports "TCP" Control Block sharing.
+This shares two important streaming lib parameters
+(window size and round trip time)
+across connections to the same remote peer.
+This is used for "temporal" sharing at connection open/close time,
+not "ensemble" sharing during a connection (See
+RFC 2140).
+There is a separate share per ConnectionManager (i.e. per local Destination)
+so that there is no information leakage to other Destinations on the
+same router.
+The share data for a given peer expires after a few minutes.
+{%- endtrans %}

+
+
{% trans %}Other Parameters{% endtrans %}

+
{% trans -%}
+The following parameters are hardcoded, but may be of interest for analysis:
+{%- endtrans %}

+
    
+
  • MIN_RESEND_DELAY = 2*1000 (minimum RTO)
+
  • MAX_RESEND_DELAY = 45*1000 (maximum RTO)
+
  • MIN_WINDOW_SIZE = 1
+
  • TREND_COUNT = 3
+
  • RTT_DAMPENING = 0.875
+
  • MIN_MESSAGE_SIZE = 512 (minimum MTU)
+
  • INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
+
  • INITIAL_TIMEOUT = 1.5 * initialRTT
+
  • PASSIVE_FLUSH_DELAY = 250
+
  • Maximum RTT estimate: 60*1000
+

+

+
+
{% trans %}History{% endtrans %}

+
{% trans -%}
+The streaming library has grown organically for I2P - first mihi implemented the
+"mini streaming library" as part of I2PTunnel, which was limited to a window
+size of 1 message (requiring an ACK before sending the next one), and then it was
+refactored out into a generic streaming interface (mirroring TCP sockets) and the
+full streaming implementation was deployed with a sliding window protocol and 
+optimizations to take into account the high bandwidth x delay product.  Individual
+streams may adjust the maximum packet size and other options. The default
+message size is selected to fit precisely in two 1K I2NP tunnel messages,
+and is a reasonable tradeoff between the bandwidth costs of 
+retransmitting lost messages, and the latency and overhead of multiple messages.
+{%- endtrans %}

+
+
+
{% trans %}Future Work{% endtrans %}

+
{% trans -%}
+The behavior of the streaming library has a profound impact on
+application-level performance, and as such, is an important
+area for further analysis.
+{%- endtrans %}

+
    
+
  • {% trans -%}
+Additional tuning of the streaming lib parameters may be necessary.
+{%- endtrans %}
    • 
+
  • {% trans ntcpdisc=site_url('docs/discussions/ntcp') -%}
+Another area for research is the interaction of the streaming lib with the
+NTCP and SSU transport layers.
+See the NTCP discussion page for details.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+The interaction of the routing algorithms with the streaming lib strongly affects performance.
+In particular, random distribution of messages to multiple tunnels in a pool
+leads to a high degree of out-of-order delivery which results in smaller window
+sizes than would otherwise be the case. The router currently routes 
+messages for a single from/to destination pair through a consistent set 
+of tunnels, until tunnel expiration or delivery failure. The router's 
+failure and tunnel selection algorithms should be reviewed for possible 
+improvements.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+The data in the first SYN packet may exceed the receiver's MTU.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+The DELAY_REQUESTED field could be used more.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+Duplicate initial SYNCHRONIZE packets on short-lived streams may not be recognized and removed.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+Don't send the MTU in a retransmission.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+Data is sent along unless the outbound window is full.
+(i.e. no-Nagle or TCP_NODELAY)
+Probably should have a configuration option for this.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+zzz has added debug code to the streaming library to log packets in a wireshark-compatible
+(pcap) format; Use this to further analyze performance.
+The format may require enhancement to map more streaming lib parameters to TCP fields.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+There are proposals to replace the streaming lib with standard TCP
+(or perhaps a null layer together with raw sockets).
+This would unfortunately be incompatible with the streaming lib
+but it would be good to compare the performance of the two.
+{%- endtrans %}
    • 
+

+
+{% endblock %}
diff --git a/www.i2p2/pages/bittorrent.html b/i2p2www/pages/site/docs/applications/bittorrent.html
similarity index 71%
rename from www.i2p2/pages/bittorrent.html
rename to i2p2www/pages/site/docs/applications/bittorrent.html
index 3643257d..79320856 100644
--- a/www.i2p2/pages/bittorrent.html
+++ b/i2p2www/pages/site/docs/applications/bittorrent.html
@@ -1,183 +1,203 @@
-{% extends "_layout.html" %}
-{% block title %}Bittorrent over I2P{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Bittorrent over I2P{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}September 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.2{% endblock %}
 {% block content %}
-Updated September 2012, current as of router version 0.9.2
 
-
-
There are several bittorrent clients and trackers on I2P.
+
{% trans -%}
+There are several bittorrent clients and trackers on I2P.
 As I2P addressing uses a Destination instead of an IP and port, minor
 changes are required to tracker and client software for operation on I2P.
 These changes are specified below.
 Note carefully the guidelines for compatibility with older I2P clients and trackers.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 This page specifies protocol details common to all clients and trackers.
 Specific clients and trackers may implement other unique features or protocols.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 We welcome additional ports of client and tracker software to I2P.
-

+{%- endtrans %}

 
 
 
-
Announces

-

+
{% trans %}Announces{% endtrans %}

+
{% trans -%}
 Clients generally include a fake port=6881 parameter in the announce, for compatibility with older trackers.
 Trackers may ignore the port parameter, and should not require it.
-

-

+{%- endtrans %}

+
+
{% trans commonstructures=site_url('docs/spec/common-structures') -%}
 The ip parameter is the base 64 of the client's
-Destination,
+Destination,
 using the I2P Base 64 alphabet [A-Z][a-z][0-9]-~.
-Destinations
+Destinations
 are 387+ bytes, so the Base 64 is 516+ bytes.
 Clients generally append ".i2p" to the Base 64 Destination for compatibility with older trackers.
 Trackers should not require an appended ".i2p".
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Other parameters are the same as in standard bittorrent.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 While all current Destinations for clients are exactly 387 bytes, a tracker should not
 presume that will always be so. A reasonable maximum to assume, for now, is 475 bytes.
 As the tracker must decode the Base64 to deliver compact responses (see below),
 the tracker should probably decode and reject bad Base64 when announced.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 The default response type is non-compact. Clients may request a compact response with
 the parameter compact=1. A tracker may, but is not required to, return
 a compact response when requested.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Developers of new I2P clients
 are strongly encouraged to implemenent announces over their own tunnel rather than
 the HTTP client proxy at port 4444. Doing so is both more efficient and it allows
 destination enforcement by the tracker (see below).
-

-

+{%- endtrans %}

+
+
{% trans -%}
 There are no known I2P clients or trackers that currently support UDP announce/responses.
-

+{%- endtrans %}

 
 
-
Non-Compact Tracker Responses

-

+
{% trans %}Non-Compact Tracker Responses{% endtrans %}

+
{% trans -%}
 The non-compact response is just as in standard bittorrent, with an I2P "ip".
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Trackers generally include a fake port key, or use the port from the announce, for compatibility with older clients.
 Clients must ignore the port parameter, and should not require it.
-

-

+{%- endtrans %}

+
+
{% trans commonstructures=site_url('docs/spec/common-structures') -%}
 The value of the ip key is the base 64 of the client's
-Destination, as described above.
+Destination, as described above.
 Trackers generally append ".i2p" to the Base 64 Destination if it wasn't in the announce ip, for compatibility with older clients.
 Clients should not require an appended ".i2p" in the responses.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Other response keys and values are the same as in standard bittorrent.
-

+{%- endtrans %}

 
 
 
-
Compact Tracker Responses

-

+
{% trans %}Compact Tracker Responses{% endtrans %}

+
{% trans commonstructures=site_url('docs/spec/common-structures') -%}
 In the compact response, the value of the "peers" dictionary key is a single byte string,
 whose length is a multiple of 32 bytes.
 This string contains the concatenated
-32-byte SHA-256 Hashes
+32-byte SHA-256 Hashes
 of the binary
-Destinations
+Destinations
 of the peers.
 This hash must be computed by the tracker, unless destination enforcement
 (see below) is used, in which case the hash delivered in the X-I2P-DestHash
 or X-I2P-DestB32 HTTP headers may be converted to binary and stored.
 The peers key may be absent, or the peers value may be zero-length.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 While compact response support is optional for both clients and trackers, it is highly
 recommended as it reduces the nominal response size by over 90%.
-

+{%- endtrans %}

 
 
 
-
Destination Enforcement

-

+
{% trans %}Destination Enforcement{% endtrans %}

+
{% trans commonstructures=site_url('docs/spec/common-structures') -%}
 Some, but not all, I2P bittorrent clients announce over their own tunnels.
 Trackers may choose to prevent spoofing by requiring this, and verifying the
 client's
-Destination
+Destination
 using HTTP headers added by the I2PTunnel HTTP Server tunnel.
 The headers are X-I2P-DestHash, X-I2P-DestB64, and X-I2P-DestB32, which are
 different formats for the same information.
 These headers cannot be spoofed by the client.
 A tracker enforcing destinations need not require the ip announce parameter at all.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 As several clients use the HTTP proxy instead of their own tunnel for announces,
 destination enforcement will prevent usage by those clients unless or until
 those clients are converted to announcing over their own tunnel.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Unfortunately, as the network grows, so will the amount of maliciousness,
 so we expect that all trackers will eventually enforce destinations.
 Both tracker and client developers should anticipate it.
-

+{%- endtrans %}

 
 
 
-
Announce Host Names

-

+
{% trans %}Announce Host Names{% endtrans %}

+
{% trans naming=site_url('docs/naming') -%}
 Announce URL host names in torrent files generally follow the
-I2P naming standards.
+I2P naming standards.
 In addition to host names from address books and ".b32.i2p" Base 32 hostnames,
 the full Base 64 Destination (with [or without?] ".i2p" appended) should be supported.
 Non-open trackers should recognize their own host name in any of these formats.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 To preserve anonymity,
 clients should generally ignore non-I2P announce URLs in torrent files.
-

+{%- endtrans %}

 
 
 
-
Client Connections

-

+
{% trans %}Client Connections{% endtrans %}

+
{% trans -%}
 Client-to-client connections use the standard protocol over TCP.
 There are no known I2P clients that currently support uTP communication.
-

-

-I2P uses 387+ byte
-Destinations for addresses, as explained above.
-

-

+{%- endtrans %}

+
+
{% trans commonstructures=site_url('docs/spec/common-structures') -%}
+I2P uses 387+ byte Destinations
+for addresses, as explained above.
+{%- endtrans %}

+
+
{% trans -%}
 If the client has only the hash of the destination (such as from a compact response or PEX), it must perform a lookup
 by encoding it with Base 32, appending ".b32.i2p", and querying the Naming Service,
 which will return the full Destination if available.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 If the client has a peer's full Destination it received in a non-compact response, it should use it
 directly in the connection setup.
 Do not convert a Destination back to a Base 32 hash for lookup, this is quite inefficient.
-

+{%- endtrans %}

 
 
-
Cross-Network Prevention

-

+
{% trans %}Cross-Network Prevention{% endtrans %}

+
{% trans -%}
 To preserve anonymity,
 I2P bittorrent clients generally do not support non-I2P announces or peer connections.
 I2P HTTP outproxies often block announces.
 There are no known SOCKS outproxies supporting bittorrent traffic.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 To prevent usage by non-I2P clients via an HTTP inproxy, I2P trackers often
 block accesses or announces that contain an X-Forwarded-For HTTP header.
 Trackers should reject standard network announces with IPv4 or IPv6 IPs, and not deliver them in responses.
-

+{%- endtrans %}

 
 
 
 
PEX

-

+
{% trans commonstructures=site_url('docs/spec/common-structures') -%}
 I2P PEX is based on ut_pex.
 As there does not appear to be a formal specification of ut_pex available,
 it may be necessary to review the libtorrent source for assistance.
@@ -186,37 +206,40 @@ It is an extension message, identified as "i2p_pex" in
 It contains a bencoded dictionary with up to 3 keys, "added", "added.f", and "dropped".
 The added and dropped values are each a single byte string, whose length is a multiple of 32 bytes.
 These byte strings are the concatenated SHA-256 Hashes of the binary
-Destinations
+Destinations
 of the peers.
 This is the same format as the peers dictionary value in the i2p compact response format specified above.
 The added.f value, if present, is the same as in ut_pex.
-

+{%- endtrans %}

 
 
 
 
DHT

-

+
{% trans -%}
 DHT support is included in the i2psnark client as of version 0.9.2.
 Preliminary differences from
 BEP 5
 are described below, and are subject to change.
 Contact the I2P developers if you wish to develop a client supporting DHT.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Unlike standard DHT, I2P DHT does not use a bit in the options handshake, or the PORT message.
 It is advertised with an extension message, identified as "i2p_dht" in
 the extension handshake.
 It contains a bencoded dictionary with two keys, "port" and "rport", both integers.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 The UDP (datagram) port listed in the compact node info is used
 to receive repliable (signed) datagrams.
 This is used for queries, except for announces.
 We call this the "query port".
 This is the "port" value from the extension message.
 Queries use I2CP protocol number 17.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 In addition to that UDP port, we use a second datagram
 port equal to the query port + 1. This is used to receive
 unsigned (raw) datagrams for replies, errors, and announces.
@@ -226,25 +249,29 @@ We call this the "response port".
 This is the "rport" value from the extension message.
 It must be 1 + the query port.
 Responses and announces use I2CP protocol number 18.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Compact peer info is 32 bytes (32 byte SHA256 Hash)
 instead of 4 byte IP + 2 byte port. There is no peer port.
 In a response, the "values" key is a list of strings, each containing a single compact peer info.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Compact node info is 54 bytes (20 byte SHA1 Hash + 32 byte SHA256 Hash + 2 byte port)
 instead of 20 byte SHA1 Hash + 4 byte IP + 2 byte port.
 In a response, the "nodes" key is a
 single byte string with concatenated compact node info.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 Secure node ID requirement: To make various DHT attacks more difficult,
 the first 4 bytes of the Node ID must match the first 4 bytes of the destination Hash,
 and the next two bytes of the Node ID must match the next two bytes of the
 destination hash exclusive-ORed with the port.
-

-

+{%- endtrans %}

+
+
{% trans -%}
 In a torrent file,
 the trackerless torrent dictionary "nodes" key is TBD.
 It could be a list of
@@ -252,24 +279,24 @@ It could be a list of
 containing a host string and a port integer.
 Alternatives: A single byte string with concatenated hashes,
 or a list of strings alone.
-

+{%- endtrans %}

 
 
-
Additional Information

+
{% trans %}Additional Information{% endtrans %}

 
 
 
diff --git a/i2p2www/pages/site/docs/applications/supported.html b/i2p2www/pages/site/docs/applications/supported.html
new file mode 100644
index 00000000..f454e644
--- /dev/null
+++ b/i2p2www/pages/site/docs/applications/supported.html
@@ -0,0 +1,703 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Supported Applications{% endtrans %}{% endblock %}
+{% block content %}
+
+
{% trans %}Supported Applications{% endtrans %}

+
+
+
+
{% trans trac=i2pconv('trac.i2p2.i2p') -%}
+This is intended to be a comprehensive listing of applications used with
+I2P. If you know of something that's missing please submit a ticket on
+Trac, and be sure to select the
+“www” component in the submission form.
+{%- endtrans %}

+
+
{% trans %}
+Supported applications are tagged with one or more of the following:
+{%- endtrans %}

+
+

+  
{{ _('bundled') }}

+
+  

+    
{% trans -%}
+Bundled application — I2P ships with a few officially
+supported applications that let new users take immediate advantage of
+some of I2P's more useful capabilities.
+{%- endtrans %}

+  

+
+  
{{ _('plugin') }}

+
+  

+    
{% trans plugins=i2pconv('plugins.i2p') -%}
+Third-party plugin — I2P's plugin system provides convenient
+deployment of I2P-enabled applications and allows tighter integration
+with the router. Plugins are [reviewed by the community](http://{{ plugins }}) to identify security and
+anonymity issues.
+{%- endtrans %}

+  

+

+
+

+  
{{ _('standalone') }}, {{ _('standalone/mod') }}

+
+  

+    
{% trans -%}
+Third-party standalone application — Many standard network
+applications only require careful setup and configuration to communicate
+anonymously over I2P. These are tagged with standalone. Some
+applications, tagged with standalone/mod, require patching to
+function properly over I2P or to prevent inadvertent disclosure of
+identifying information such as the user's hostname or external IP
+address.
+{%- endtrans %}

+  

+
+  
{{ _('service') }}

+
+  

+    
{% trans -%}
+Third-party essential network service — Services which on
+the I2P network are analogous to those provided on the public Internet
+by hosting providers, ISPs, and Google: eepsite indexes and jump
+services, search engines, email, DNS-style name services, hosting,
+proxies, etc. These services focus on boosting the usefulness of the
+network as a whole, and making network content more discoverable.
+{%- endtrans %}

+  

+
+  
{{ _('unmaintained') }}

+
+  

+    
{% trans -%}
+Unmaintained — This is used to tag plugins, applications,
+and services which appear to be unmaintained and may be removed from
+this listing in the future.
+{%- endtrans %}

+  

+

+
+
{% trans threatmodel=site_url('docs/how/threat-model') -%}
+Warning: Using an application, plugin, or service with I2P
+doesn't automatically protect your anonymity. I2P is merely a set of tools
+which can help you mitigate certain identified
+threats to anonymity. We do not and cannot make any guarantees about the
+safety of the applications, plugins, and services listed below. Most
+applications and plugins must be properly configured, and some will need to
+be patched — and even then your anonymity might not be assured. Similarly,
+services could put your anonymity at risk, either by design or through
+carelessness on their part or your own.
+{%- endtrans %}

+
+
{% trans -%}
+If you have doubts about the suitability of an application,
+plugin, or service for use with I2P, you are urged to inquire about privacy
+issues with its maintainers, to search its mailing lists and bug tracker if
+one exists, and consult trusted, knowledgeable members of the I2P
+community.
+{%- endtrans %}

+
+
{% trans -%}
+Take responsibility for your own anonymity and safety — always
+seek expert advice, educate yourself, practice good judgment, be mindful of
+disclosing personally identifying information, and don't take
+shortcuts.
+{%- endtrans %}

+
+
{% trans %}Blogging, Forums, and Wikis{% endtrans %}

+
+
    
+    
+
+  
  • 
+    
    El Dorado —
+    {% trans %}Lightweight forum software.{% endtrans %}
+    [{{ _('standalone/mod') }}]
    
+  
    • 
+
+  
  • 
+    
    Pebble —
+    {% trans %}Another lightweight blogging platform.{% endtrans %}
+    [{{ _('plugin') }}, {{ _('standalone/mod') }}]
    
+  
    • 
+
+  
  • 
+    
    phpBB —
+    {% trans %}Most popular open source forum software.{% endtrans %}
+    [{{ _('standalone/mod') }}]
    
+  
    • 
+
+  
  • 
+    
    Syndie —
+    {% trans %}Distributed forums software, originally developed by jrandom.{% endtrans %}
+    [{{ _('plugin') }}, {{ _('standalone') }}, {{ _('unmaintained') }}]
    
+  
    • 
+  
  • 
+     
    JAMWiki —
+{% trans plugins=i2pconv('plugins.i2p') -%}
+A Java-based MediaWiki clone. No external database needed.
+Plugin available here.
+{%- endtrans %}
+     [{{ _('standalone') }}, {{ _('plugin') }}]
    
+  
    • 
+

+
+
{% trans %}Decentralized File Storage{% endtrans %}

+
+
    
+  
  • Tahoe-LAFS-I2P —
+{% trans stats=i2pconv('stats.i2p') -%}
+Port of the Tahoe-LAFS
+distributed file system to the I2P network. Controller plugin here.
+{%- endtrans %}
+  [{{ _('plugin') }}, {{ _('standalone') }}]
    • 
+

+
+
{% trans %}Development Tools{% endtrans %}

+
+
{% trans %}Version control{% endtrans %}

+
+
    
+  
  • 
+    
    Git —
+    {% trans %}Most popular distributed version control system.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    Monotone —
+{% trans monotone=site_url('get-involved/guides/monotone') -%}
+Another distributed version control system. Currently
+used in I2P development.
+{%- endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+

+
+
{% trans %}Domain Naming{% endtrans %}

+
+
    
+  
  • susidns —
+{% trans naming=site_url('docs/naming') -%}
+Provides management of addressbooks, which are part of a simple,
+user-controlled I2P naming system somewhat
+analogous to the Internet's Domain Name System (DNS). Addressbooks map
+Base64 destinations to short, usually human-readable “domain” names ending
+with a .i2p suffix which the I2P router's HTTP client can resolve back to
+Base64 addresses. (Note: While Base64 destinations are globally
+unique, addressbook “domain” names only resolve to unique destinations
+locally.)
+{%- endtrans %}
+    [{{ _('bundled') }}]
+  
    • 
+

+
+
{% trans %}Email{% endtrans %}

+
+
    
+  
  • 
+    
    I2P-Bote —
+{% trans -%}
+Serverless peer-to-peer email application using a distributed hash table
+(DHT) for secure mail storage.
+{%- endtrans %}
+    [{{ _('plugin') }}]
    
+  
    • 
+
+  
  • 
+    
    Postman's anonymous email service —
+{% trans -%}
+Provides email service within the I2P network via @mail.i2p addresses,
+and email gateway service between the I2P network and the public Internet
+via @i2pmail.org addresses. One of the oldest continuous services on I2P.
+{%- endtrans %}
+    [{{ _('service') }}]
    
+  
    • 
+
+  
  • 
+    
    susimail —
+{% trans -%}
+Simple web browser-based email interface. Configured to use Postman's
+email service by default.
+{%- endtrans %}
+    [{{ _('bundled') }}]
    
+  
    • 
+

+
+
{% trans %}File Sharing{% endtrans %}

+
+
{% trans %}BitTorrent clients{% endtrans %}

+
+
    
+  
  • 
+    
    I2PSnark —
+    {% trans %}I2P's integrated BitTorrent client.{% endtrans %}
+    [{{ _('bundled') }}]
    
+  
    • 
+
+  
  • 
+    
    I2PSnarkXL —
+    {% trans %}Modified version of I2PSnark.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    Robert —
+{% trans %}
+A fork of rufus that uses the Basic Open Bridge (BOB) and has many
+improvements, including using the latest wxwidgets and python. It also
+supports use of seedless if installed for trackerless torrents and
+magnet-link like fetching of torrents within I2P.
+{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    Transmission —
+{% trans -%}
+Clean, full-featured cross-platform BitTorrent client with official
+ports for several GUI toolkits.
+{%- endtrans %}
+    [{{ _('standalone/mod') }}]
    
+  
    • 
+
+  
  • 
+    
    Azureus/Vuze —
+    {% trans %}Has a plugin providing I2P support.{% endtrans %}
+    [{{ _('standalone') }}, {{ _('unmaintained') }}]
    
+  
    • 
+

+
+
{% trans %}BitTorrent trackers and indexers{% endtrans %}

+
+
{% trans zzz=i2pconv('zzz.i2p') -%}
+For a detailed feature comparison of I2P-enabled trackers/indexers, see
+here.
+{%- endtrans %}

+
+
    
+  
  • 
+    
    Bytemonsoon —
+{% trans -%}
+The code that powered one of the first major tracker/indexer sites on the
+Internet. Patched for I2P.
+{%- endtrans %}
+    [{{ _('standalone/mod') }}]
    
+  
    • 
+
+  
  • 
+    
    opentracker —
+{% trans newdevs=site_url('get-involved/guides/new-developers') -%}
+Lightweight tracker/indexer. I2P mod available in the i2p.opentracker
+branch of the I2P Monotone repository.
+{%- endtrans %}
+    [{{ _('standalone/mod') }}]
    
+  
    • 
+
+  
  • 
+    
    zzzot —
+{% trans zzz=i2pconv('zzz.i2p') -%}
+zzz's Java-based open tracker. More info
+here.
+{%- endtrans %}
+    [{{ _('plugin') }}]
    
+  
    • 
+

+
+
ED2K

+
+
    
+  
  • 
+    iMule —
+    {% trans %}I2P port of the aMule ED2K client.{% endtrans %}
+    [{{ _('standalone') }}]
    • 
+

+
+
Gnutella

+
+
    
+  
  • 
+    
    I2Phex —
+{% trans stats=i2pconv('stats.i2p') -%}
+Port of the Phex Gnutella client. Website
+for plugin version here.
+{%- endtrans %}
+    [{{ _('plugin') }}, {{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    jwebcache —
+{% trans stats=i2pconv('stats.i2p') -%}
+Cache for Gnutella peers on I2P. Website for plugin version
+here.
+{%- endtrans %}
+    [{{ _('plugin') }}, {{ _('standalone') }}]
    
+  
    • 
+

+
+
{% trans %}Network Administration{% endtrans %}

+
+
{% trans %}General-purpose socket utilities{% endtrans %}

+
+
    
+  
  • 
+    
    netcat —
+{% trans -%}
+Unix standard tool for socket relaying. Several clones, ports, and forks
+have appeared over the years.
+{%- endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    socat —
+    {% trans %}Like netcat but more powerful.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    tsocks —
+    {% trans %}Proxy providing simple, transparent SOCKS-ification of network applications.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+

+
+
SSH/SCP/SFTP

+
+
    
+  
  • 
+    
    OpenSSH —
+    {% trans %}Most popular implementation of the Secure Shell (SSH) protocol and related tools.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    PuTTY —
+    {% trans %}Open source Secure Shell (SSH) client for Windows.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+

+
+
{% trans %}Real-time Chat{% endtrans %}

+
+
{% trans %}Instant messaging clients{% endtrans %}

+
+
    
+  
  • 
+    I2P Messenger —
+    {% trans %}IM client with multiple incarnations.{% endtrans %}
+    [{{ _('standalone') }}]
+  
    • 
+

+
+
{% trans %}IRC clients{% endtrans %}

+
+
{% trans -%}
+Many IRC clients leak identifying information to servers or other
+clients, so I2P's IRC and SOCKS IRC client tunnels filter certain inbound
+and outbound messages to scrub data such as LAN IP addresses, external IP
+addresses, local hostnames, and the name and version of the IRC client. Two
+message types in particular, DCC and CTCP, can't be sufficiently anonymized
+without changes to the protocols or to IRC client/server code, so they are
+completely blocked, except for CTCP ACTION (the message emitted by the
+/me command) which isn't inherently dangerous.
+{%- endtrans %}

+
+
{% trans -%}
+I2P's IRC filtering may not cover every possible leak — users should also
+check if their client is sending their real name or local username. Packet
+sniffers such as Wireshark are
+useful here. Eliminating remaining leaks may be as simple as changing the
+client's default configuration. If that doesn't help, inform the I2P
+developers; they may be able to solve it via additional filtering.
+{%- endtrans %}

+
+
    
+  
  • 
+    
    jIRCii —
+{% trans stats=i2pconv('stats.i2p') -%}
+Small Java-based IRC client. Plugin available here.
+{%- endtrans %}
+    [{{ _('plugin') }}, {{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    XChat —
+    {% trans %}Cross-platform graphical IRC client.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    irssi —
+    {% trans %}Unixy terminal-based IRC client.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    WeeChat —
+    {% trans %}Another Unixy terminal-based IRC client.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+

+
+
{% trans %}IRC servers{% endtrans %}

+
+
    
+  
  • 
+    
    ngIRCd —
+    {% trans %}IRC server developed from scratch.{% endtrans %}
+    [{{ _('standalone/mod') }}]
    
+  
    • 
+
+  
  • 
+    
    UnrealIRCd —
+    {% trans %}Most popular IRC server.{% endtrans %}
+    [{{ _('standalone/mod') }}]
    
+  
    • 
+

+
+
{% trans %}Web Browsing{% endtrans %}

+
+
{% trans %}Anonymous websites{% endtrans %}

+
+
    
+  
  • 
+    
    Eepsites —
+{% trans -%}
+Any website hosted anonymously on I2P, reachable through the I2P router's HTTP proxy.
+{%- endtrans %}
+    [{{ _('service') }}]
    
+  
    • 
+
+  
  • 
+    
    Deepsites —
+{% trans -%}
+Distributed anonymous websites hosted
+using Tahoe-LAFS-I2P, currently only reachable with Tahoe-LAFS-I2P
+clients or through the Tahoe-LAFS-I2P HTTP proxy.
+{%- endtrans %}
+    [{{ _('service') }}]
    
+  
    • 
+
+  
  • 
+    
    {{ i2pconv('i2host.i2p') }} —
+{% trans sponge=i2pconv('sponge.i2p') -%}
+Website for sponge's jump service.
+Source code available.
+{%- endtrans %}
+    [{{ _('service') }}]
    
+  
    • 
+
+  
  • 
+    
    {{ i2pconv('i2jump.i2p') }} —
+    {% trans %}Another jump service.{% endtrans %}
+    [{{ _('service') }}]
    
+  
    • 
+
+  
  • 
+    
    {{ i2pconv('perv.i2p') }} —
+    {% trans %}Dynamically updated eepsite index.{% endtrans %}
+    [{{ _('service') }}]
    
+  
    • 
+
+  
  • 
+    
    {{ i2pconv('stats.i2p') }} —
+    {% trans zzz=i2pconv('zzz.i2p') %}Website for zzz's jump service.{% endtrans %}
+    [{{ _('service') }}]
    
+  
    • 
+

+
+
{% trans %}Proxy software{% endtrans %}

+
+
    
+  
  • 
+    
    Polipo —
+    {% trans %}SOCKS-enabled caching web proxy with basic filtering capabilities.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    Privoxy —
+{% trans -%}
+Privacy-focused non-caching web proxy with advanced filtering
+capabilities. Excels at removing ads and other junk.
+{%- endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    Squid —
+    {% trans %}Venerable caching web proxy.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+

+
+
{% trans %}Inproxies{% endtrans %}

+
+
{% trans -%}
+Gateways allowing users on the public Internet to access eepsites.
+{%- endtrans %}

+
+
    
+  
  • 
+    i2p.to —
+{% trans tino=i2pconv('tino.i2p') -%}
+tino's inproxy on the public Internet.
+{%- endtrans %}
+    [{{ _('service') }}]
+  
    • 
+

+
+
{% trans %}Outproxies{% endtrans %}

+
+
{% trans -%}
+Gateways allowing I2P users to access content hosted on the public Internet.
+{%- endtrans %}

+
+
    
+  
  • 
+    {{ i2pconv('false.i2p') }} —
+    {% trans %}Publicly advertised outproxy running Squid, located in Germany.{% endtrans %}
+    [{{ _('service') }}]
+  
    • 
+

+
+
{% trans %}Website Hosting{% endtrans %}

+
+
    
+  
  • 
+    Jetty —
+{% trans -%}
+Lightweight web server and Java servlet container. I2P is tightly
+integrated with a bundled copy of Jetty which by default is configured to
+host the user's eepsite. The bundled
+Jetty also serves the I2P router console and web applications bundled with
+I2P.
+{%- endtrans %}
+    [{{ _('bundled') }}, {{ _('standalone') }}]
    • 
+

+
+
{% trans %}Web servers{% endtrans %}

+
+
{% trans -%}
+In addition to Jetty, any web server should function over I2P without
+modification so long as it's HTTP-compliant. Some web servers known to
+currently serve content on the I2P network are:
+{%- endtrans %}

+
+
    
+  
  • 
+    
    Apache HTTP Server —
+    {% trans %}Most popular web server on the public WWW.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    Apache Tomcat —
+    {% trans %}Web server and Java servlet container. More features than Jetty.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    lighttpd —
+    {% trans %}Fast lightweight web server.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+
+  
  • 
+    
    nginx —
+    {% trans %}High-performance lightweight web server.{% endtrans %}
+    [{{ _('standalone') }}]
    
+  
    • 
+

+
+{% endblock %}
diff --git a/www.i2p2/pages/naming_discussion.html b/i2p2www/pages/site/docs/discussions/naming.html
similarity index 74%
rename from www.i2p2/pages/naming_discussion.html
rename to i2p2www/pages/site/docs/discussions/naming.html
index 55d45258..1ae02e26 100644
--- a/www.i2p2/pages/naming_discussion.html
+++ b/i2p2www/pages/site/docs/discussions/naming.html
@@ -1,22 +1,22 @@
-{% extends "_layout.html" %}
-{% block title %}Naming discussion{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Naming discussion{% endtrans %}{% endblock %}
 {% block content %}
-

+
{% trans naming=site_url('docs/naming') -%}
 NOTE: The following is a discussion of the reasons behind the I2P naming system,
 common arguments and possible alternatives.
-See the naming page for current documentation.
-

+See the naming page for current documentation.
+{%- endtrans %}

 
-
Discarded alternatives

+
{% trans %}Discarded alternatives{% endtrans %}

 
-

+
{% trans -%}
 Naming within I2P has been an oft-debated topic since the very beginning with
 advocates across the spectrum of possibilities.  However, given I2P's inherent
 demand for secure communication and decentralized operation, the traditional
 DNS-style naming system is clearly out, as are "majority rules" voting systems.
-

+{%- endtrans %}

 
-

+
{% trans -%}
 I2P does not promote the use of DNS-like services though, as the damage done
 by hijacking a site can be tremendous - and insecure destinations have no
 value.  DNSsec itself still falls back on registrars and certificate authorities,
@@ -28,203 +28,265 @@ of service and spoofing attacks.  Adding on a certificate authenticating the
 responses as signed by some centralized certificate authority would address many of
 the hostile nameserver issues but would leave open replay attacks as well as 
 hostile certificate authority attacks.
-

+{%- endtrans %}

 
-

+
{% trans -%}
 Voting style naming is dangerous as well, especially given the effectiveness of
 Sybil attacks in anonymous systems - the attacker can simply create an arbitrarily
 high number of peers and "vote" with each to take over a given name.  Proof-of-work
 methods can be used to make identity non-free, but as the network grows the load
 required to contact everyone to conduct online voting is implausible, or if the
 full network is not queried, different sets of answers may be reachable.
-

+{%- endtrans %}

 
-

+
{% trans -%}
 As with the Internet however, I2P is keeping the design and operation of a 
 naming system out of the (IP-like) communication layer.  The bundled naming library
 includes a simple service provider interface which alternate naming systems can
 plug into, allowing end users to drive what sort of naming tradeoffs they prefer.
-

+{%- endtrans %}

 
 
Discussion

-

+
{% trans -%}
 See also Names: Decentralized, Secure, Human-Meaningful: Choose Two.
-

+{%- endtrans %}

 
 
Comments by jrandom

-
(adapted from a post in the old Syndie, November 26, 2005)

-

+
{% trans -%}
+(adapted from a post in the old Syndie, November 26, 2005)
+{%- endtrans %}

+
{% trans -%}
 Q:
 What to do if some hosts 
 do not agree on one address and if some addresses are working, others are not? 
 Who is the right source of a name?
-

+{%- endtrans %}

+
{% trans -%}
 A:
 You don't. This is actually a critical difference between names on I2P and how 
 DNS works - names in I2P are human readable, secure, but not globally 
 unique.  This is by design, and an inherent part of our need for security.  
-

+{%- endtrans %}

+
{% trans -%}
 If I could somehow convince you to change the destination associated with some 
 name, I'd successfully "take over" the site, and under no circumstances is that 
 acceptable.  Instead, what we do is make names locally unique: they are 
 what you use to call a site, just as how you can call things whatever 
 you want when you add them to your browser's bookmarks, or your IM client's 
 buddy list.  Who you call "Boss" may be who someone else calls "Sally".
-

+{%- endtrans %}

+
{% trans -%}
 Names will not, ever, be securely human readable and globally unique.
-

+{%- endtrans %}

 
 
Comments by zzz

-
The following from zzz is a review of several common
+
{% trans -%}
+The following from zzz is a review of several common
 complaints about I2P's naming system.
+{%- endtrans %}

 
    
-
  • Inefficiency
    
+
  • 
+
    {% trans -%}
+Inefficiency:
 The whole hosts.txt is downloaded (if it has changed, since eepget uses the etag and last-modified headers).
 It's about 400K right now for almost 800 hosts.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 True, but this isn't a lot of traffic in the context of i2p, which is itself wildly inefficient
 (floodfill databases, huge encryption overhead and padding, garlic routing, etc.).
 If you downloaded a hosts.txt file from someone every 12 hours it averages out to about 10 bytes/sec.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 As is usually the case in i2p, there is a fundamental tradeoff here between anonymity and efficiency.
 Some would say that using the etag and last-modified headers is hazardous because it exposes when you
 last requested the data.
 Others have suggested asking for specific keys only (similar to what jump services do, but
 in a more automated fashion), possibly at a further cost in anonymity.
-
    
-Possible improvements would be a replacement or supplement to addressbook (see i2host.i2p),
+{%- endtrans %}
    
+
    {% trans i2host=i2pconv('i2host.i2p') -%}
+Possible improvements would be a replacement or supplement to addressbook (see {{ i2host }}p),
 or something simple like subscribing to http://example.i2p/cgi-bin/recenthosts.cgi rather than http://example.i2p/hosts.txt.
 If a hypothetical recenthosts.cgi distributed all hosts from the last 24 hours, for example,
 that could be both more efficient and more anonymous than the current hosts.txt with last-modified and etag.
-
    
+{%- endtrans %}
    
+
    {% trans url='http://'+i2pconv('stats.i2p')+'/cgi-bin/newhosts.txt' -%}
 A sample implementation is on stats.i2p at
-http://stats.i2p/cgi-bin/newhosts.txt.
+{{ url }}.
 This script returns an Etag with a timestamp.
 When a request comes in with the If-None-Match etag,
 the script ONLY returns new hosts since that timestamp, or 304 Not Modified if there are none.
 In this way, the script efficiently returns only the hosts the subscriber
 does not know about, in an addressbook-compatible manner.
-
-
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 So the inefficiency is not a big issue and there are several ways to improve things without
 radical change.
+{%- endtrans %}
    
 
-
  • Not Scalable
    
+
  • 
+
    {% trans -%}
+Not Scalable:
 The 400K hosts.txt (with linear search) isn't that big at the moment and
 we can probably grow by 10x or 100x before it's a problem.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 As far as network traffic see above.
 But unless you're going to do a slow real-time query over the network for
 a key, you need to have the whole set of keys stored locally, at a cost of about 500 bytes per key.
-
  • Requires configuration and "trust"
    
+{%- endtrans %}
    
+
+
  • 
+
    {% trans -%}
+Requires configuration and "trust":
 Out-of-the-box addressbook is only subscribed to http://www.i2p2.i2p/hosts.txt, which is rarely updated,
 leading to poor new-user experience.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 This is very much intentional. jrandom wants a user to "trust" a hosts.txt
 provider, and as he likes to say, "trust is not a boolean".
 The configuration step attempts to force users to think about issues of trust in an anonymous network.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 As another example, the "Eepsite Unknown" error page in the HTTP Proxy
 lists some jump services, but doesn't "recommend" any one in particular,
 and it's up to the user to pick one (or not).
 jrandom would say we trust the listed providers enough to list them but not enough to
 automatically go fetch the key from them.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 How successful this is, I'm not sure.
 But there must be some sort of hierarchy of trust for the naming system.
 To treat everyone equally may increase the risk of hijacking.
+{%- endtrans %}
    
 
-
  • It isn't DNS
    
+
  • 
+
    {% trans -%}
+It isn't DNS
+{%- endtrans %}
    
+
    {% trans -%}
 Unfortunately real-time lookups over i2p would significantly slow down web browsing.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 Also, DNS is based on lookups with limited caching and time-to-live, while i2p
 keys are permanent.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 Sure, we could make it work, but why? It's a bad fit.
-
  • Not reliable
    
+{%- endtrans %}
    
+
+
  • 
+
    {% trans -%}
+Not reliable:
 It depends on specific servers for addressbook subscriptions.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 Yes it depends on a few servers that you have configured.
 Within i2p, servers and services come and go.
 Any other centralized system (for example DNS root servers) would
 have the same problem. A completely decentralized system (everybody is authoritative)
 is possible by implementing an "everybody is a root DNS server" solution, or by
 something even simpler, like a script that adds everybody in your hosts.txt to your addressbook.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 People advocating all-authoritative solutions generally haven't thought through
 the issues of conflicts and hijacking, however.
+{%- endtrans %}
    
 
-
  • Awkward, not real-time
    
+
  • 
+
    {% trans -%}
+Awkward, not real-time:
 It's a patchwork of hosts.txt providers, key-add web form providers, jump service providers,
 eepsite status reporters.
 Jump servers and subscriptions are a pain, it should just work like DNS.
-
    
+{%- endtrans %}
    
+
    {% trans -%}
 See the reliability and trust sections.
-
    
+{%- endtrans %}
    
+
    • 
 

-
So, in summary, the current system is not horribly broken, inefficient, or un-scalable,
+
{% trans -%}
+So, in summary, the current system is not horribly broken, inefficient, or un-scalable,
 and proposals to "just use DNS" aren't well thought-through.
-

+{%- endtrans %}

 
-
Alternatives

-
The I2P source contains several pluggable naming systems and supports configuration options
+
{% trans %}Alternatives{% endtrans %}

+
{% trans -%}
+The I2P source contains several pluggable naming systems and supports configuration options
 to enable experimentation with naming systems.
+{%- endtrans %}

 
    
-
  • Meta - calls two or more other naming systems in order.
+
  • {% trans -%}
+Meta - calls two or more other naming systems in order.
 By default, calls PetName then HostsTxt.
-
  • PetName - Looks up in a petnames.txt file.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+PetName - Looks up in a petnames.txt file.
 The format for this file is NOT the same as hosts.txt.
-
  • HostsTxt - Looks up in the following files, in order:
+{%- endtrans %}
    • 
+
  • {% trans -%}
+HostsTxt - Looks up in the following files, in order:
+{%- endtrans %}
    • 
 
      
 
    1. privatehosts.txt
 
    2. userhosts.txt
 
    3. hosts.txt
 
    
-
  • AddressDB - Each host is listed in a separate file in a addressDb/ directory.
-
  • 
+
  • {% trans -%}
+AddressDB - Each host is listed in a separate file in a addressDb/ directory.
+{%- endtrans %}
    • 
+
  • {% trans -%}
 Eepget - does an HTTP lookup request from an external
 server - must be stacked after the HostsTxt lookup with Meta.
 This could augment or replace the jump system.
 Includes in-memory caching.
-
  • 
+{%- endtrans %}
    • 
+
  • {% trans -%}
 Exec - calls an external program for lookup, allows
 additional experimentation in lookup schemes, independent of java.
 Can be used after HostsTxt or as the sole naming system.
 Includes in-memory caching.
-
  • Dummy - used as a fallback for Base64 names, otherwise fails.
+{%- endtrans %}
    • 
+
  • {% trans -%}
+Dummy - used as a fallback for Base64 names, otherwise fails.
+{%- endtrans %}
    • 
 

-

+
{% trans -%}
 The current naming system can be changed with the advanced config option 'i2p.naming.impl'
 (restart required).
 See core/java/src/net/i2p/client/naming for details.
-

+{%- endtrans %}

+
{% trans -%}
 Any new system should be stacked with HostsTxt, or should
 implement local storage and/or the addressbook subscription functions, since addressbook
 only knows about the hosts.txt files and format.
+{%- endtrans %}

 
-
Certificates

-

+
{% trans %}Certificates{% endtrans %}

+
{% trans -%}
 I2P destinations contain a certificate, however at the moment that certificate
 is always null.
 With a null certificate, base64 destinations are always 516 bytes ending in "AAAA",
 and this is checked in the addressbook merge mechanism, and possibly other places.
 Also, there is no method available to generate a certificate or add it to a
 destination. So these will have to be updated to implement certificates.
-

-One possible use of certificates is for proof of work.
-

+{%- endtrans %}

+
{% trans todo=site_url('get-involved/todo') -%}
+One possible use of certificates is for proof of work.
+{%- endtrans %}

+
{% trans -%}
 Another is for "subdomains" (in quotes because there is really no such thing,
 i2p uses a flat naming system) to be signed by the 2nd level domain's keys.
-

+{%- endtrans %}

+
{% trans -%}
 With any certificate implementation must come the method for verifying the
 certificates.
 Presumably this would happen in the addressbook merge code.
 Is there a method for multiple types of certificates, or multiple certificates?
-

+{%- endtrans %}

+
{% trans -%}
 Adding on a certificate authenticating the
 responses as signed by some centralized certificate authority would address many of
 the hostile nameserver issues but would leave open replay attacks as well as 
 hostile certificate authority attacks.
-

+{%- endtrans %}

 {% endblock %}
diff --git a/www.i2p2/pages/netdb_discussion.html b/i2p2www/pages/site/docs/discussions/netdb.html
similarity index 97%
rename from www.i2p2/pages/netdb_discussion.html
rename to i2p2www/pages/site/docs/discussions/netdb.html
index 8e0a1a7f..55b8c9fc 100644
--- a/www.i2p2/pages/netdb_discussion.html
+++ b/i2p2www/pages/site/docs/discussions/netdb.html
@@ -1,9 +1,9 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Network Database Discussion{% endblock %}
 {% block content %}
 

 NOTE: The following is a discussion of the history of netdb implementation and is not current information.
-See the main netdb page for current documentation.
+See the main netdb page for current documentation.
 
 
History

 
@@ -241,7 +241,7 @@ This just accounts for the stores - what about the queries?
 
 
The Return of the Kademlia Algorithm?

 

-(this is adapted from the I2P meeting Jan. 2, 2007)
+(this is adapted from the I2P meeting Jan. 2, 2007)
 

 The Kademlia netDb just wasn't working properly.
 Is it dead forever or will it be coming back?
@@ -282,7 +282,7 @@ Not necessarily DHT-based.
 
Floodfill TODO List

 

 NOTE: The following is not current information.
-See the main netdb page for the current status and a list of future work.
+See the main netdb page for the current status and a list of future work.
 

 The network was down to only one floodfill for a couple of hours on March 13, 2008
 (approx. 18:00 - 20:00 UTC),
@@ -365,7 +365,7 @@ we are now at the minimum number of stats required to monitor the network.
 
  • 
 [In Release 0.6.3]
 Manual list of floodfill peers to exclude?
-(blocklists by router ident)
+(blocklists by router ident)
 
  • 
 [In Release 0.6.3]
 Better floodfill peer selection for stores:
diff --git a/www.i2p2/pages/ntcp_discussion.html b/i2p2www/pages/site/docs/discussions/ntcp.html
similarity index 99%
rename from www.i2p2/pages/ntcp_discussion.html
rename to i2p2www/pages/site/docs/discussions/ntcp.html
index ce013d3f..50409695 100644
--- a/www.i2p2/pages/ntcp_discussion.html
+++ b/i2p2www/pages/site/docs/discussions/ntcp.html
@@ -1,10 +1,10 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}NTCP Discussion{% endblock %}
 {% block content %}
 
 Following is a discussion about NTCP that took place in March 2007.
 It has not been updated to reflect current implementation.
-For the current NTCP specification see the main NTCP page.
+For the current NTCP specification see the main NTCP page.
 
 
    NTCP vs. SSU Discussion, March 2007
    
 
    NTCP questions
    
diff --git a/www.i2p2/pages/tunnel_discussion.html b/i2p2www/pages/site/docs/discussions/tunnel.html
similarity index 95%
rename from www.i2p2/pages/tunnel_discussion.html
rename to i2p2www/pages/site/docs/discussions/tunnel.html
index 2b1e9dfd..e8a3b5ce 100644
--- a/www.i2p2/pages/tunnel_discussion.html
+++ b/i2p2www/pages/site/docs/discussions/tunnel.html
@@ -1,16 +1,16 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Tunnel Discussion{% endblock %}
 {% block content %}
 
 Note: This document contains older information about alternatives to the
 current tunnel implementation in I2P,
 and speculation on future possibilities. For current information see
-the tunnel page.
+the tunnel page.
 
 
    
 That page documents the current tunnel build implementation as of release 0.6.1.10.
 The older tunnel build method, used prior to release 0.6.1.10, is documented on
-the old tunnel page.
+the old tunnel page.
 
 
    Configuration Alternatives
    
 
    Beyond their length, there may be additional configurable parameters
@@ -150,7 +150,7 @@ Reference:
 
 
    Old tunnel build method
    
 The old tunnel build method, used prior to release 0.6.1.10, is documented on
-the old tunnel page.
+the old tunnel page.
 This was an "all at once" or "parallel" method,
 where messages were sent in parallel to each of the participants.
 
@@ -213,9 +213,9 @@ Sponge has proposed using 'tokens' of some sort.
 
    
 Any students of tunnel building must study the historical record leading up to the current method,
 especially the various anonymity vulnerabilities that may exist in various methods.
-The mail archives from October 2005 at zzz.i2p or
+The mail archives from October 2005 at zzz.i2p or
 osdir.com are particularly helpful.
-As stated on the tunnel creation specification,
+As stated on the tunnel creation specification,
 the current strategy came about during a discussion on the I2P mailing list between
 Michael Rogers, Matthew Toseland (toad), and jrandom regarding the predecessor attack.
 See:Summary and
@@ -240,6 +240,6 @@ reordering, rerouting, or padding messages?  To what extent should this be done
 automatically, how much should be configured as a per tunnel or per hop setting,
 and how should the tunnel's creator (and in turn, user) control this operation?
 All of this is left as unknown, to be worked out for 
-I2P 3.0
    
+I2P 3.0
    
 
 {% endblock %}
diff --git a/www.i2p2/pages/how_cryptography.html b/i2p2www/pages/site/docs/how/cryptography.html
similarity index 56%
rename from www.i2p2/pages/how_cryptography.html
rename to i2p2www/pages/site/docs/how/cryptography.html
index 08377b1f..c0bb0602 100644
--- a/www.i2p2/pages/how_cryptography.html
+++ b/i2p2www/pages/site/docs/how/cryptography.html
@@ -1,45 +1,53 @@
-{% extends "_layout.html" %}
-{% block title %}Low-level Cryptography Details{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Low-level Cryptography Details{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}March 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.13{% endblock %}
 {% block content %}
-
    
-Updated March 2012, current as of router version 0.8.13
-
    
+
    {% trans -%}
 This page specifies the low-level details of the cryptography in I2P.
-
    
+{%- endtrans %}
    
+
+
    {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
 There are a handful of cryptographic algorithms in use within I2P, but we have
 reduced them to a bare minimum to deal with our needs - one symmetric algorithm
 one asymmetric algorithm, one signing algorithm, and one hashing algorithm.  However, 
 we do combine them in some particular ways to provide message integrity (rather than
 relying on a MAC).  In addition, as much as we hate doing anything new in regards to 
 cryptography, we can't seem to find a reference discussing (or even naming) the 
-technique used in ElGamal/AES+SessionTag (but we're sure others have done it).
-
    
-
    ElGamal encryption
    
+technique used in ElGamal/AES+SessionTag (but we're sure others have done it).
+{%- endtrans %}
    
 
-
    
+
    {% trans %}ElGamal encryption{% endtrans %}
    
+
+
    {% trans %}
 ElGamal is used for asymmetric encryption.
 ElGamal is used in several places in I2P:
-
    
 
-
    
+
    {% trans -%}
 We use common primes for 2048 ElGamal encryption and decryption, as given by IETF RFC-3526.
 We currently only use ElGamal to encrypt the IV and session key in a single block, followed by the 
 AES encrypted payload using that key and IV.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The unencrypted ElGamal contains: 
-
    
-
    
-
    +{%- endtrans %}
    
+
        +----+----+----+----+----+----+----+----+
    |nonz|           H(data)                |
    +----+                                  +
@@ -52,8 +60,8 @@ The unencrypted ElGamal contains:
    |    |  data...
    +----+----+----+--//                   
 
-
    
-
    
+
    
+
    {% trans -%}
 The H(data) is the SHA256 of the data that is encrypted in the ElGamal block,
 and is preceded by a nonzero byte. 
 This byte could be random, but as implemented it is always 0xFF.
@@ -63,11 +71,13 @@ As the encrypted data may contain a substantial number of zeros if the
 cleartext is smaller than 222 bytes, it is recommended that higher layers pad
 the cleartext to 222 bytes with random data.
 Total length: typically 255 bytes.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The encrypted ElGamal contains: 
+{%- endtrans %}
    
 
    
-
    
-
    +
        +----+----+----+----+----+----+----+----+
    |  zero padding...       |              |
    +----+----+----+--// ----+              +
@@ -88,25 +98,31 @@ The encrypted ElGamal contains:
    |         +
    +----+----+
 
-
    
+
    
+
    {% trans -%}
 Each encrypted part is prepended with zeros to a size of exactly 257 bytes.
 Total length: 514 bytes.
 In typical usage, higher layers pad the cleartext data to 222 bytes,
 resulting in an unencrypted block of 255 bytes.
 This is encoded as two 256-byte encrypted parts,
 and there is a single byte of zero padding before each part at this layer.
-
    
-See 
-the ElGamal code.
-
    
-The shared prime is the 
+{%- endtrans %}
    
 
+
    {% trans url='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/ElGamalEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4' -%}
+See the ElGamal code.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The shared prime is the 
 [Oakley prime for 2048 bit keys]
-
    +{%- endtrans %}
    
+
      2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
-
    
+
    
+
    {% trans -%}
 or as a hexadecimal value:
-
    +{%- endtrans %}
    
+
      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
  29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
  EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
@@ -118,64 +134,80 @@ or as a hexadecimal value:
  E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
  DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
  15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
-
    
-
    
+
    
+
    {% trans -%}
 Using 2 as the generator.
-
    Short Exponent
    
+{%- endtrans %}
    
+
+
    {% trans %}Short Exponent{% endtrans %}
    
+
    {% trans commonstructures=site_url('docs/spec/common-structures'),
+pdf='http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.5952&rep=rep1&type=pdf',
+benchmarks=site_url('misc/benchmarks'),
+oldbenchmarks='http://www.eskimo.com/~weidai/benchmarks.html' -%}
 While the standard exponent size is 2048 bits (256 bytes) and the I2P
-PrivateKey
+PrivateKey
 is a full 256 bytes,
 we use the short exponent size of 226 bits (28.25 bytes).
-This should be safe for use with the Oakley primes,
-per
-
-On Diffie-Hellman Key Agreement with Short Exponents - van Oorschot, Weiner
-at EuroCrypt 96, and
-crypto++'s benchmarks.
-Benchmarks originally at this link, now dead,
+This should be safe for use with the Oakley primes, per
+On Diffie-Hellman Key Agreement with Short Exponents - van Oorschot, Weiner
+at EuroCrypt 96, and crypto++'s benchmarks.
+Benchmarks originally at {{ oldbenchmarks }} (now dead),
 rescued from the wayback machine, dated Apr 23, 2008.
-
    
-Also,
-
-Koshiba & Kurosawa: Short Exponent Diffie-Hellman Problems (PKC 2004, LNCS 2947, pp. 173-186) 
-
-(full text on google books)
-apparently supports this, according to
-this sci.crypt thread.
-The remainder of the PrivateKey is padded with zeroes.
+{%- endtrans %}
    
 
-
    Obsolescence
    
-
    
+
    {% trans book='http://www.springerlink.com/content/2jry7cftp5bpdghm/',
+fulltext='http://books.google.com/books?id=cXyiNZ2_Pa0C&lpg=PA173&ots=PNIz3dWe4g&pg=PA173#v=onepage&q&f=false',
+thread='http://groups.google.com/group/sci.crypt/browse_thread/thread/1855a5efa7416677/339fa2f945cc9ba0#339fa2f945cc9ba0' -%}
+Also, Koshiba & Kurosawa: Short Exponent Diffie-Hellman Problems (PKC 2004, LNCS 2947, pp. 173-186)
+(full text on Google Books) apparently supports this, according to
+this sci.crypt thread.
+The remainder of the PrivateKey is padded with zeroes.
+{%- endtrans %}
    
+
+
    {% trans %}Obsolescence{% endtrans %}
    
+
    {% trans -%}
 The vulnerability of the network to an ElGamal attack and the impact of transitioning to a longer bit length is to be studied.
 It may be quite difficult to make any change backward-compatible.
-
    
+{%- endtrans %}
    
 
 
-
    AES
    
+
    AES
    
 
-
    
+
    {% trans -%}
 AES is used for symmetric encryption, in several cases:
-
    
+
+
    {% trans rfc2313='http://tools.ietf.org/html/rfc2313',
+code1='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/CryptixAESEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4',
+code2='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/CryptixRijndael_Algorithm.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4',
+code3='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/ElGamalAESEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4' -%}
 We use AES with 256 bit keys and 128 bit blocks in CBC mode.
-The padding used is specified in IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02)).
+The padding used is specified in IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02)).
 In this case, padding exists of pseudorandomly generated octets to match 16 byte blocks.
-Specifically, see 
-[the CBC code] 
-and the Cryptix AES 
-[implementation],
-as well as the padding, found in the
-ElGamalAESEngine.getPadding function.
+Specifically, see [the CBC code] and the Cryptix AES
+[implementation], as well as the padding, found in the
+ElGamalAESEngine.getPadding function.
+{%- endtrans %}
    
 
 
 
 
-
    Obsolescence
    
-
    
+
    {% trans %}Obsolescence{% endtrans %}
    
+
    {% trans -%}
 The vulnerability of the network to an AES attack and the impact of transitioning to a longer bit length is to be studied.
 It may be quite difficult to make any change backward-compatible.
-
    
+{%- endtrans %}
    
 
-
    References
    
+
    {% trans %}References{% endtrans %}
    
 
 
 
-
    DSA
    
+
    DSA
    
 
-
    
+
    {% trans code='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/DSAEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4' -%}
 Signatures are generated and verified with 1024 bit DSA (L=1024, N=160), as implemented in
-[DSAEngine].
+[DSAEngine].
 DSA was chosen because it is much faster for signatures than ElGamal.
-
    
-
    The DSA constants
    
+{%- endtrans %}
    
 
-
    
+
    {% trans %}The DSA constants{% endtrans %}
    
 
-
    SEED
    
+
    SEED
    
 
 
    160 bit
    
 
-
    +
      86108236b8526e296e923a4015b4282845b572cc
-
    
-
    Counter
    
+
    
 
-
    +
    Counter
    
+
+
      33
-
    
+
    
 
    
 
    DSA prime (p)
    
 
 
    1024 bit
    
 
 
    
-
    +
      9C05B2AA 960D9B97 B8931963 C9CC9E8C 3026E9B8 ED92FAD0
  A69CC886 D5BF8015 FCADAE31 A0AD18FA B3F01B00 A358DE23
  7655C496 4AFAA2B3 37E96AD3 16B9FB1C C564B5AE C5B69A9F
  F6C3E454 8707FEF8 503D91DD 8602E867 E6D35D22 35C1869C
  E2479C3B 9D5401DE 04E0727F B33D6511 285D4CF2 9538D9E3
  B6051F5B 22CC1C93
-
    
+
    
 
    
 
    DSA quotient (q)
    
 
 
    
-
    +
      A5DFC28F EF4CA1E2 86744CD8 EED9D29D 684046B7
-
    
+
    
 
    
 
    DSA generator (g)
    
 
 
    1024 bit
    
 
 
    
-
    +
      C1F4D27D 40093B42 9E962D72 23824E0B BC47E7C8 32A39236
  FC683AF8 48895810 75FF9082 ED32353D 4374D730 1CDA1D23
  C431F469 8599DDA0 2451824F F3697525 93647CC3 DDC197DE
  985E43D1 36CDCFC6 BD5409CD 2F450821 142A5E6F 8EB1C3AB
  5D0484B8 129FCF17 BCE4F7F3 3321C3CB 3DBB14A9 05E7B2B3
  E93BE470 8CBCC82
-
    
+
    
 
-
    
-The Signing Public Key is 1024 bits.
-The Signing Private Key is 160 bits.
-
    
+
    {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+The Signing Public Key is 1024 bits.
+The Signing Private Key is 160 bits.
+{%- endtrans %}
    
 
 
-
    Obsolescence
    
-
    
-NIST 800-57
+
    {% trans %}Obsolescence{% endtrans %}
    
+
    {% trans pdf='http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf' -%}
+NIST 800-57
 recommends a minimum of (L=2048, N=224) for usage beyond 2010.
 This may be mitigated somewhat by the "cryptoperiod", or lifespan of a given key.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The prime number was chosen in 2003,
 and the person that chose the number (TheCrypto) is currently no longer an I2P developer.
 As such, we do not know if the prime chosen is a 'strong prime'.
 If a larger prime is chosen for future purposes, this should be a strong prime, and we will document the construction process.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The vulnerability of the network to a DSA attack and the impact of transitioning to longer keys is to be studied.
 It may be quite difficult to make any change backward-compatible.
-
    
+{%- endtrans %}
    
 
-
    References
    
+
    {% trans %}References{% endtrans %}
    
 
@@ -339,25 +374,25 @@ It may be quite difficult to make any change backward-compatible.
 
 
    SHA256
    
 
-
    
+
    {% trans code='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/SHA256Generator.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4' -%}
 Hashes within I2P are plain old SHA256, as implemented in
-[SHA256Generator]
+[SHA256Generator]
+{%- endtrans %}
    
 
-
-
    Obsolescence
    
-
    
+
    {% trans %}Obsolescence{% endtrans %}
    
+
    {% trans -%}
 The vulnerability of the network to a SHA-256 attack and the impact of transitioning to a longer hash is to be studied.
 It may be quite difficult to make any change backward-compatible.
-
    
+{%- endtrans %}
    
 
-
    References
    
+
    {% trans %}References{% endtrans %}
    
 
 
-
    Transports
    
-
    
+
    {% trans %}Transports{% endtrans %}
    
+
    {% trans -%}
 At the lowest protocol layer,
 point-to-point inter-router communication is protected by the transport layer security.
 Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange
@@ -367,52 +402,62 @@ followed by symmetric AES encryption as described above.
 This provides
 perfect forward secrecy
 on the transport links.
-
    
+{%- endtrans %}
    
 
-
    NTCP connections
    
+
    {% trans %}NTCP connections{% endtrans %}
    
 
-
    
+
    {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
 NTCP connections are negotiated with a 2048 Diffie-Hellman implementation,
 using the router's identity to proceed with a station to station agreement, followed by
 some encrypted protocol specific fields, with all subsequent data encrypted with AES
 (as above).
-The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) forward secrecy', while ElGamalAES+SessionTag does not.
-
    
-
    
+The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) forward secrecy', while ElGamalAES+SessionTag does not.
+{%- endtrans %}
    
+
+
    {% trans -%}
 In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed:
-
    
-
      
-
    1.  can we somehow reestablish sessions securely (ala session tags) or do we need to do full negotiation each time?
-
    2.  can we simplify/avoid the x509 or other certificate formats and use our own RouterInfo structure (which 
-     contains the ElGamal and DSA keys)?
-
-
    
-
    
-See the NTCP specification for details.
-
-
    UDP connections
    
+{%- endtrans %}
    
+
      
+
    1. {% trans -%}
+Can we somehow reestablish sessions securely (ala session tags) or do we need to do full negotiation each time?
+{%- endtrans %}
      2. 
+
    2. {% trans -%}
+Can we simplify/avoid the x509 or other certificate formats and use our own RouterInfo structure (which 
+contains the ElGamal and DSA keys)?
+{%- endtrans %}
      3. 
+
    
+
    {% trans ntcp=site_url('docs/transport/ntcp') -%}
+See the NTCP specification for details.
+{%- endtrans %}
    
 
+
    {% trans %}UDP connections{% endtrans %}
    
+
    {% trans -%}
 SSU (the UDP transport) encrypts each packet with AES256/CBC with both an explicit IV and MAC 
 (HMAC-MD5-128) after agreeing upon an ephemeral session key through a 2048 bit 
 Diffie-Hellman exchange, station-to-station authentication with the other 
 router's DSA key, plus each network message has their own hash for local integrity 
 checking.
-
    
-See the SSU specification for details.
-
    
+{%- endtrans %}
    
+
+
    {% trans ssu=site_url('docs/transport/ssu') -%}
+See the SSU specification for details.
+{%- endtrans %}
    
+
+
    {% trans statusnotes=get_url('blog_post', slug='2005/07/05/status') -%}
 WARNING - I2P's HMAC-MD5-128 used in SSU is apparently non-standard.
 Apparently, an early version of SSU used HMAC-SHA256, and then it was switched
 to MD5-128 for performance reasons, but left the 32-byte buffer size intact.
 See HMACGenerator.java and
-the 2005-07-05 status notes
+the 2005-07-05 status notes
 for details.
+{%- endtrans %}
    
 
 
-
    References
    
+
    {% trans %}References{% endtrans %}
    
 
 
-
 {% endblock %}
diff --git a/www.i2p2/pages/how_elgamalaes.html b/i2p2www/pages/site/docs/how/elgamal-aes.html
similarity index 53%
rename from www.i2p2/pages/how_elgamalaes.html
rename to i2p2www/pages/site/docs/how/elgamal-aes.html
index b2b501fd..ec84bc47 100644
--- a/www.i2p2/pages/how_elgamalaes.html
+++ b/i2p2www/pages/site/docs/how/elgamal-aes.html
@@ -1,87 +1,109 @@
-{% extends "_layout.html" %}
-{% block title %}ElGamal/AES + SessionTag  Encryption{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}ElGamal/AES + SessionTag Encryption{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}February 2011{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.3{% endblock %}
 {% block content %}
-Updated February 2011, current as of router version 0.8.3
-
    Overview
    
-
    
+
    {% trans %}Overview{% endtrans %}
    
+
    {% trans -%}
 ElGamal/AES+SessionTags is used for end-to-end encryption.
-
    
-  
     As an unreliable, unordered, message based system, I2P uses a simple combination 
-    of asymmetric and symmetric encryption algorithms to provide data confidentiality 
-    and integrity to garlic messages. As a whole, the combination is referred 
-    to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe 
-    the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces. 
    
-  
     The first time a router wants to encrypt a garlic message to another router, 
-    they encrypt the keying material for an AES256 session key with ElGamal and 
-    append the AES256/CBC encrypted payload after that encrypted ElGamal block. 
-    In addition to the encrypted payload, the AES encrypted section contains the 
-    payload length, the SHA256 hash of the unencrypted payload, as well as a number 
-    of "session tags" - random 32 byte nonces. The next time the sender wants 
-    to encrypt a garlic message to another router, rather than ElGamal encrypt 
-    a new session key they simply pick one of the previously delivered session 
-    tags and AES encrypt the payload like before, using the session key used with 
-    that session tag, prepended with the session tag itself. When a router receives 
-    a garlic encrypted message, they check the first 32 bytes to see if it matches 
-    an available session tag - if it does, they simply AES decrypt the message, 
-    but if it does not, they ElGamal decrypt the first block. 
    
-  
     Each session tag can be used only once so as to prevent internal adversaries 
-    from unnecessarily correlating different messages as being between the same 
-    routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses 
-    when and how many tags to deliver, prestocking the recipient with enough tags 
-    to cover a volley of messages. Garlic messages may detect the successful tag 
-    delivery by bundling a small additional message as a clove (a "delivery status 
-    message") - when the garlic message arrives at the intended recipient and 
-    is decrypted successfully, this small delivery status message is one of the 
-    cloves exposed and has instructions for the recipient to send the clove back 
-    to the original sender (through an inbound tunnel, of course). When the original 
-    sender receives this delivery status message, they know that the session tags 
-    bundled in the garlic message were successfully delivered. 
    
-  
     Session tags themselves have a short lifetime, after which they are 
-    discarded if not used. In addition, the quantity stored for each key is limited, 
-    as are the number of keys themselves - if too many arrive, either new or old 
-    messages may be dropped. The sender keeps track whether messages using session 
-    tags are getting through, and if there isn't sufficient communication it may 
-    drop the ones previously assumed to be properly delivered, reverting back 
-    to the full expensive ElGamal encryption.
-    A session will continue to exist until all its tags are exhausted or expire.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
+As an unreliable, unordered, message based system, I2P uses a simple combination 
+of asymmetric and symmetric encryption algorithms to provide data confidentiality 
+and integrity to garlic messages. As a whole, the combination is referred 
+to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe 
+the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The first time a router wants to encrypt a garlic message to another router, 
+they encrypt the keying material for an AES256 session key with ElGamal and 
+append the AES256/CBC encrypted payload after that encrypted ElGamal block. 
+In addition to the encrypted payload, the AES encrypted section contains the 
+payload length, the SHA256 hash of the unencrypted payload, as well as a number 
+of "session tags" - random 32 byte nonces. The next time the sender wants 
+to encrypt a garlic message to another router, rather than ElGamal encrypt 
+a new session key they simply pick one of the previously delivered session 
+tags and AES encrypt the payload like before, using the session key used with 
+that session tag, prepended with the session tag itself. When a router receives 
+a garlic encrypted message, they check the first 32 bytes to see if it matches 
+an available session tag - if it does, they simply AES decrypt the message, 
+but if it does not, they ElGamal decrypt the first block.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Each session tag can be used only once so as to prevent internal adversaries 
+from unnecessarily correlating different messages as being between the same 
+routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses 
+when and how many tags to deliver, prestocking the recipient with enough tags 
+to cover a volley of messages. Garlic messages may detect the successful tag 
+delivery by bundling a small additional message as a clove (a "delivery status 
+message") - when the garlic message arrives at the intended recipient and 
+is decrypted successfully, this small delivery status message is one of the 
+cloves exposed and has instructions for the recipient to send the clove back 
+to the original sender (through an inbound tunnel, of course). When the original 
+sender receives this delivery status message, they know that the session tags 
+bundled in the garlic message were successfully delivered.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Session tags themselves have a short lifetime, after which they are 
+discarded if not used. In addition, the quantity stored for each key is limited, 
+as are the number of keys themselves - if too many arrive, either new or old 
+messages may be dropped. The sender keeps track whether messages using session 
+tags are getting through, and if there isn't sufficient communication it may 
+drop the ones previously assumed to be properly delivered, reverting back 
+to the full expensive ElGamal encryption.
+A session will continue to exist until all its tags are exhausted or expire.
+{%- endtrans %}
    
+
+
    {% trans -%}
 Sessions are unidirectional. Tags are delivered from Alice to Bob,
 and Alice then uses the tags, one by one, in subsequent messages to Bob.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Sessions may be established between Destinations, between Routers, or
 between a Router and a Destination.
 Each Router and Destination maintains its own Session Key Manager to
 keep track of Session Keys and Session Tags.
 Separate Session Key Managers prevents correlation of multiple Destinations
 to each other or a Router by adversaries.
-
    
+{%- endtrans %}
    
 
 
 
-
    Message Reception
    
-
    
+
    {% trans %}Message Reception{% endtrans %}
    
+
    {% trans -%}
 Each message received has one of two
 the two possible conditions:
    
+{%- endtrans %}
    
 
-
      
-
    1.  It is part of an existing session and contains a Session Tag and an AES encrypted block
      2. 
-
    2.  It is for a new session and contains both ElGamal and AES encrypted blocks
      3. 
-
    
+
      
+
    1. {% trans %}It is part of an existing session and contains a Session Tag and an AES encrypted block{% endtrans %}
      2. 
+
    2. {% trans %}It is for a new session and contains both ElGamal and AES encrypted blocks{% endtrans %}
      3. 
+
    
+
+
    {% trans -%}
 When a router receives a message, it will first assume it is from
 an existing session and attempt to look up the Session Tag and decrypt the following data using AES.
 If that fails, it will assume it is for a new session and attempt to
 decrypt it using ElGamal.
-
    
+{%- endtrans %}
    
 
 
 
-
    New Session Message Specification
    
-
    
+
    {% trans %}New Session Message Specification{% endtrans %}
    
+
    {% trans -%}
 A New Session ElGamal Message contains two parts, an encrypted ElGamal block
 and an encrypted AES block.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The encrypted message contains:
-
    +{%- endtrans %}
    
+
        +----+----+----+----+----+----+----+----+
    |                                       |
    +                                       +
@@ -100,14 +122,17 @@ The encrypted message contains:
    |         +
    +----+----+
 
-
    
-
    
-
    ElGamal Block
    
-
    
+
    
+
+
    {% trans %}ElGamal Block{% endtrans %}
    
+
    {% trans -%}
 The encrypted ElGamal Block is always 514 bytes long.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The unencrypted ElGamal data is 222 bytes long, containing:
-
    +{%- endtrans %}
    
+
        +----+----+----+----+----+----+----+----+
    |                                       |
    +                                       +
@@ -134,21 +159,28 @@ The unencrypted ElGamal data is 222 bytes long, containing:
    +                             +----+----+
    |                             |
    +----+----+----+----+----+----+
-
    
+
    
+
+
    {% trans commonstructures=site_url('docs/spec/common-structures') -%}
 The 32-byte
-Session Key
+Session Key
 is the identifier for the session.
 The 32-byte Pre-IV will be used to generate the IV for the AES block that follows;
 the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV.
-
    
+{%- endtrans %}
    
+
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
 The 222 byte payload is encrypted
-using ElGamal
+using ElGamal
 and the encrypted block is 514 bytes long.
 
    
+{%- endtrans %}
    
 
-
    AES Block
    
-
    The unencrypted data in the AES block contains the following:
-
    +
    {% trans %}AES Block{% endtrans %}
    
+
    {% trans -%}
+The unencrypted data in the AES block contains the following:
+{%- endtrans %}
    
+
        +----+----+----+----+----+----+----+----+
    |tag count|                             |
    +----+----+                             +
@@ -189,56 +221,73 @@ and the encrypted block is 514 bytes long.
    |          Padding to 16 bytes          |
    +----+----+----+----+----+----+----+----+
 
-tag count: 2-byte Integer, 0-200
+tag count: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+2-byte Integer, 0-200
+{%- endtrans %}
 
-Session Tags: That many 32-byte Session Tags
+Session Tags: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+That many 32-byte Session Tags
+{%- endtrans %}
 
-payload size: 4-byte Integer
+payload size: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+4-byte Integer
+{%- endtrans %}
 
-Payload Hash: The 32-byte SHA256 Hash of the payload
+Payload Hash: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+The 32-byte SHA256 Hash of the payload
+{%- endtrans %}
 
-flag: A one-byte value. Normally == 0. If == 0x01, a Session Key follows
+flag: {% trans -%}
+A one-byte value. Normally == 0. If == 0x01, a Session Key follows
+{%- endtrans %}
 
-New Session Key: A 32-byte Session Key,
+New Session Key: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+A 32-byte Session Key,
                  to replace the old key, and is only present if preceding flag is 0x01
+{%- endtrans %}
 
-Payload: the data
+Payload: {% trans %}the data{% endtrans %}
 
-Padding: Random data to a multiple of 16 bytes for the total length.
+Padding: {% trans -%}
+Random data to a multiple of 16 bytes for the total length.
          May contain more than the minimum required padding.
+{%- endtrans %}
 
-Minimum length: 48 bytes
+{% trans %}Minimum length: 48 bytes{% endtrans %}
 
-
    
+
    
 
-
    
-The data is then AES Encrypted,
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+The data is then AES Encrypted,
 using the session key and IV (calculated from the pre-IV) from the ElGamal section.
 The encrypted AES Block length is variable but is always a multiple of 16 bytes.
 
    
-
    Notes
    
+{%- endtrans %}
    
+
+
    {% trans %}Notes{% endtrans %}
    
 
      
-
    • 
-  Actual max payload length, and max block length, is less than 64 KB; see the I2NP Overview.
-
    • 
-New Session Key is currently unused and is never present.
-
    
+
  • {% trans i2np=site_url('docs/protocol/i2np') -%}
+Actual max payload length, and max block length, is less than 64 KB; see the I2NP Overview.
+{%- endtrans %}
    • 
+
  • {% trans %}New Session Key is currently unused and is never present.{% endtrans %}
    • 
+
 
 
 
-
    Existing Session Message Specification
    
-
-
    The session tags delivered successfully are remembered for a 
+
    {% trans %}Existing Session Message Specification{% endtrans %}
    
+
    {% trans -%}
+The session tags delivered successfully are remembered for a 
 brief period (15 minutes currently) until they are used or discarded.
 A tag is used by packaging one in an Existing Session Message that
-contains only an AES encrypted block, and
- is not preceded by an
+contains only an AES encrypted block, and is not preceded by an
 ElGamal block.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The existing session message is
 as follows:
-
-
    +{%- endtrans %}
    
+
        +----+----+----+----+----+----+----+----+
    |                                       |
    +                                       +
@@ -257,72 +306,101 @@ as follows:
    |                                       |
    +----+----+----+----+----+----+----+----+
 
-Session Tag: A 32-byte Session Tag
+Session Tag: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+A 32-byte Session Tag
              previously delivered in an AES block
+{%- endtrans %}
 
-AES Encrypyted Block: As specified above.
+AES Encrypyted Block: {% trans %}As specified above.{% endtrans %}
 
-
    
+
    
+
+
    {% trans -%}
 The session tag also serves as
 the pre-IV. The IV is the first 16 bytes of the SHA-256 Hash of the sessionTag.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 To decode a message from an existing session, a router looks up the Session Tag to find an
 associated Session Key. If the Session Tag is found, the AES block is decrypted using the associated Session Key.
 If the tag is not found, the message is assumed to be a New Session Message.
-
    
+{%- endtrans %}
    
 
 
 
-
    Future Work
    
-
    
+
    {% trans %}Future Work{% endtrans %}
    
+
    {% trans -%}
 There are many possible areas to tune the Session Key Manager's algorithms;
 some may interact with the streaming library behavior, or have significant
 impact on overall performance.
-
    • 
+{%- endtrans %}
      
+
        
+
      • {% trans -%}
 Delivery of too many tags at one time may impose substantial overhead for brief streaming connections
 or datagrams, and increase the chance of message loss.
 We currently deliver 40 tags at a time (1280 bytes).
 32 (1024 bytes) may be better for tunnel fragmentation.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 A few tags could be delivered in each of several messages, or lots of tags all at once.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 It is also important to study and tune
 the low-tag thresholds at which more tags are sent.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 The number of tags delivered could depend on message size, keeping in mind
 the eventual padding to 1KB at the tunnel message layer.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Clients could send an estimate of session lifetime to the router, as an advisory
 on the number of tags required.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Delivery of too few tags causes the router to fall back to an expensive ElGamal encryption.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 The router may assume delivery of Session Tags, or await acknowledgement before using them;
 there are tradeoffs for each strategy.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 For very brief messages, almost the full 222 bytes of the pre-IV and padding fields in the ElGamal block
 could be used for the entire message, instead of establishing a session.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Evaluate padding strategy; currently we pad to a minimum of 128 bytes.
 Would be better to add a few tags to small messages than pad.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Perhaps things could be more efficient if the Session Tag system was bidirectional,
 so tags delivered in the 'forward' path could be used in the 'reverse' path,
 thus avoiding ElGamal in the initial response.
 The router currently plays some tricks like this when sending
 tunnel test messages to itself.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans futureperf=site_url('about/performance/future') -%}
 Change from Session Tags to
-a synchronized PRNG.
-
      • 
+a synchronized PRNG.
+{%- endtrans %}
        • 
+
+
      • {% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%}
 Several of these ideas may require a new I2NP message type, or
 set a flag in the
-Delivery Instructions,
+Delivery Instructions,
 or set a magic number in the first few bytes of the Session Key field
 and accept a small risk of the random Session Key matching the magic number.
-
      
-
-
      
+{%- endtrans %}
      • 
+
    
 
 
 
diff --git a/www.i2p2/pages/how_garlicrouting.html b/i2p2www/pages/site/docs/how/garlic-routing.html
similarity index 54%
rename from www.i2p2/pages/how_garlicrouting.html
rename to i2p2www/pages/site/docs/how/garlic-routing.html
index 71841492..f98d6f91 100644
--- a/www.i2p2/pages/how_garlicrouting.html
+++ b/i2p2www/pages/site/docs/how/garlic-routing.html
@@ -1,70 +1,80 @@
-{% extends "_layout.html" %}
-{% block title %}Garlic Routing{% endblock %}
-{% block content %}
    
-Updated August 2010 for release 0.8
-
    
-
-
    Garlic Routing and "Garlic" Terminology
    
-
    
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Garlic Routing{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
+{% block content %}
+
    {% trans %}Garlic Routing and "Garlic" Terminology{% endtrans %}
    
+
    {% trans -%}
 The terms "garlic routing" and "garlic encryption" are often used rather loosely when referring to I2P's technology.
 Here, we explain the history of the terms, the various meanings, and
 the usage of "garlic" methods in I2P.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 "Garlic routing" was first coined by
 Michael J. Freedman
 in Roger Dingledine's Free Haven 
 Master's thesis Section 8.1.1 (June 2000), as derived from 
-Onion Routing.
-
    
+Onion Routing.
+{%- endtrans %}
    
+
+
    {% trans -%}
 "Garlic" may have been used originally by I2P developers because I2P implements a form of
 bundling as Freedman describes, or simply to emphasize general differences from Tor.
 The specific reasoning may be lost to history.
 Generally, when referring to I2P, the term "garlic" may mean one of three things:
-
    1. 
-Layered Encryption
-
    2. 
-Bundling multiple messages together
-
    3. 
-ElGamal/AES Encryption
-
    
+{%- endtrans %}
    
+
      
+
    1. {% trans %}Layered Encryption{% endtrans %}
      2. 
+
    2. {% trans %}Bundling multiple messages together{% endtrans %}
      3. 
+
    3. {% trans %}ElGamal/AES Encryption{% endtrans %}
      4. 
+
    
+
+
    {% trans -%}
 Unfortunately, I2P's usage of "garlic" terminology over the past seven years has not always been precise; therefore the reader is
 cautioned when encountering the term.
 Hopefully, the explanation below will make things clear.
-
    
+{%- endtrans %}
    
 
-
    Layered Encryption
    
-
    
+
    {% trans %}Layered Encryption{% endtrans %}
    
+
    {% trans -%}
 Onion routing is a technique for building paths, or tunnels, through a series of peers,
 and then using that tunnel.
 Messages are repeatedly encrypted by the originator, and then decrypted by each hop.
 During the building phase, only the routing instructions for the next hop are exposed to each peer.
 During the operating phase, messages are passed through the tunnel, and the
 message and its routing instructions are only exposed to the endpoint of the tunnel.
-
    
+{%- endtrans %}
    
+
+
    {% trans comparisons=site_url('comparison') -%}
 This is similar to the way Mixmaster
-(see network comparisons) sends messages - taking a message, encrypting it
+(see network comparisons) sends messages - taking a message, encrypting it
 to the recipient's public key, taking that encrypted message and encrypting
 it (along with instructions specifying the next hop), and then taking that
 resulting encrypted message and so on, until it has one layer of encryption
 per hop along the path.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 In this sense, "garlic routing" as a general concept is identical to "onion routing".
 As implemented in I2P, of course, there are several differences from the implementation in Tor; see below.
 Even so, there are substantial similarities such that I2P benefits from a
 large amount of academic research on onion routing,
 Tor, and similar mixnets.
-
    
+{%- endtrans %}
    
 
 
-
    Bundling Multiple Messages
    
-
    
+
    {% trans %}Bundling Multiple Messages{% endtrans %}
    
+
    {% trans -%}
 Michael Freedman defined "garlic routing" as an extension to onion routing,
 in which multiple messages are bundled together.
 He called each message a "bulb".
 All the messages, each with its own delivery instructions, are exposed at the
 endpoint.
 This allows the efficient bundling of an onion routing "reply block" with the original message.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 This concept is implemented in I2P, as described below.
 Our term for garlic "bulbs" is "cloves".
 Any number of messages can be
@@ -72,88 +82,107 @@ contained, instead of just a single message.
 This is a significant distinction from the onion routing implemented in Tor.
 However, it is only one of many major architectural differences between I2P and Tor;
 perhaps it is not, by itself, enough to justify a change in terminology.
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 Another difference
 from the method described by Freedman
 is that the path is unidirectional - there is no "turning point" as seen in onion routing
 or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible
 and reliable delivery.
-
    
+{%- endtrans %}
    
 
 
-
    ElGamal/AES Encryption
    
+
    {% trans %}ElGamal/AES Encryption{% endtrans %}
    
+
    {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
 In some cases, "garlic encryption" may simply mean
-ElGamal/AES+SessionTag encryption
+ElGamal/AES+SessionTag encryption
 (without multiple layers).
+{%- endtrans %}
    
 
 
 
-
    "Garlic" Methods in I2P
    
-
-
    
+
    {% trans %}"Garlic" Methods in I2P{% endtrans %}
    
+
    {% trans -%}
 Now that we've defined various "garlic" terms, we can say that
 I2P uses garlic routing, bundling and encryption in three places:
+{%- endtrans %}
    
 
      
-
    1.  For building and routing through tunnels (layered encryption)
-
    2.  For determining the success or failure of end to end message delivery (bundling)
-
    3.  For publishing some network database entries (dampening the probability of a successful traffic analysis attack)
-     (ElGamal/AES)
+
    4. {% trans %}For building and routing through tunnels (layered encryption){% endtrans %}
+
    5. {% trans %}For determining the success or failure of end to end message delivery (bundling){% endtrans %}
+
    6. {% trans %}For publishing some network database entries (dampening the probability of a successful traffic analysis attack) (ElGamal/AES){% endtrans %}
 
    
-
    
+
+
    {% trans -%}
 There are also significant ways that this technique can be used to improve the performance of the network, 
 exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability.  
+{%- endtrans %}
    
 
 
-
    Tunnel Building and Routing
    
-
    
+
    {% trans %}Tunnel Building and Routing{% endtrans %}
    
+
    {% trans -%}
 In I2P, tunnels are unidirectional. Each party builds two tunnels,
 one for outbound and one for inbound traffic.
 Therefore, four tunnels are required for a single round-trip message and reply.
-
    
+{%- endtrans %}
    
+
+
    {% trans tunnelimpl=site_url('docs/tunnels/implementation'),
+tunnelcreation=site_url('docs/spec/tunnel-creation'),
+elgamalaes=site_url('docs/how/elgamal-aes') -%}
 Tunnels are built, and then used, with layered encryption.
 This is described on the
-tunnel implementation page.
+tunnel implementation page.
 Tunnel building details are defined on
-this page.
+this page.
 We use
-ElGamal/AES+SessionTag for the encryption.
-
    
+ElGamal/AES+SessionTag for the encryption.
+{%- endtrans %}
    
+
+
    {% trans i2np=site_url('docs/protocol/i2np'), i2npspec=site_url('docs/spec/i2np') -%}
 Tunnels are a general-purpose mechanism to transport all
-I2NP messages, and
-Garlic Messages are not used to build tunnels.
+I2NP messages, and
+Garlic Messages are not used to build tunnels.
 We do not bundle multiple
-I2NP messages into a single
-Garlic Message for unwrapping at the outbound tunnel endpoint;
+I2NP messages into a single
+Garlic Message for unwrapping at the outbound tunnel endpoint;
 the tunnel encryption is sufficient.
-
    
+{%- endtrans %}
    
 
 
-
    End-to-End Message Bundling
    
-
    
+
    {% trans %}End-to-End Message Bundling{% endtrans %}
    
+
    {% trans commonstructures=site_url('docs/spec/common-structures'),
+elgamalaes=site_url('docs/how/elgamal-aes'),
+i2cp=site_url('docs/protocol/i2cp'),
+i2npspec=site_url('docs/spec/i2np'),
+tunnelmessage=site_url('docs/spec/tunnel-message') -%}
 At the layer above tunnels, I2P delivers end-to-end messages between
-Destinations.
+Destinations.
 Just as within a single tunnel, we use
-ElGamal/AES+SessionTag for the encryption.
+ElGamal/AES+SessionTag for the encryption.
 Each client message as delivered to the router through the
-I2CP interface becomes a single
-Garlic Clove
+I2CP interface becomes a single
+Garlic Clove
 with its own
-Delivery Instructions,
+Delivery Instructions,
 inside a
-Garlic Message.
+Garlic Message.
 Delivery Instructions may specify a Destination, Router, or Tunnel.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Generally, a Garlic Message will contain only one clove.
 However, the router will periodically bundle two additional
 cloves in the Garlic Message:
-Garlic Message Cloves
+{%- endtrans %}
    
+{{ _('Garlic Message Cloves') }}
 
-
    1. 
+
        
+
      1. {% trans i2npspec=site_url('docs/spec/i2np'),
+tunnelmessage=site_url('docs/spec/tunnel-message') -%}
 A
-Delivery Status Message,
+Delivery Status Message,
 with
-Delivery Instructions
+Delivery Instructions
 specifying that it be sent back to the originating router as an acknowledgment.
 This is similar to the "reply block" or "reply onion"
 described in the references.
@@ -161,99 +190,121 @@ It is used for determining the success or failure of end to end message delivery
 The originating router may, upon failure to receive the Delivery Status Message
 within the expected time period, modify the routing to the far-end Destination,
 or take other actions.
-
-
      2. 
+{%- endtrans %}
        3. 
+
      3. {% trans i2npspec=site_url('docs/spec/i2np'),
+commonstructures=site_url('docs/spec/common-structures'),
+tunnelmessage=site_url('docs/spec/tunnel-message'),
+netdb=site_url('docs/how/network-database') -%}
 A
-Database Store Message,
+Database Store Message,
 containing a
-LeaseSet
+LeaseSet
 for the originating Destination, with
-Delivery Instructions
+Delivery Instructions
 specifying the far-end destination's router.
 By periodically bundling a LeaseSet, the router ensures that the far-end will be able
 to maintain communications.
 Otherwise the far-end would have to query a floodfill router for the network database entry,
 and all LeaseSets would have to be published to the network database, as explained on the
-network database page.
-
      
+network database page.
+{%- endtrans %}
      2. 
+
    
 
-
    
+
    {% trans commonstructures=site_url('docs/spec/common-structures') -%}
 In the current implementation, the Delivery Status and Database Store Messages
 are bundled when the local LeaseSet changes, when additional
-Session Tags
+Session Tags
 are delivered, or if the messages have not been bundled in the previous minute.
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 Obviously, the additional messages are currently bundled for specific purposes,
 and not part of a general-purpose routing scheme.
-
    
+{%- endtrans %}
    
 
-
     Storage to the Floodfill Network Database
    
-
    
+
+
    {% trans %}Storage to the Floodfill Network Database{% endtrans %}
    
+
    {% trans netdb=site_url('docs/how/network-database'),
+commonstructures=site_url('docs/spec/common-structures'),
+i2npspec=site_url('docs/spec/i2np') -%}
 As explained on the
-network database page,
+network database page,
 local
-LeaseSets
+LeaseSets
 are sent to floodfill routers in a
-Database Store Message
+Database Store Message
 wrapped in a
-Garlic Message
+Garlic Message
 so it is not visible to the tunnel's outbound gateway.
-
    
+{%- endtrans %}
    
 
 
-
    Future Work
    
-
    
+
    {% trans %}Future Work{% endtrans %}
    
+
    {% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%}
 The Garlic Message mechanism is very flexible and provides a structure for
 implementing many types of mixnet delivery methods.
 Together with the unused delay option in the
-tunnel message Delivery Instructions,
+tunnel message Delivery Instructions,
 a wide spectrum of batching, delay, mixing, and routing strategies are possible.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 In particular, there is potential for much more flexibility at the outbound tunnel endpoint.
 Messages could possibly be routed from there to one of several tunnels
 (thus minimizing point-to-point connections), or multicast to several tunnels
 for redundancy, or streaming audio and video.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Such experiments may conflict with the need to ensure security and anonymity, such
 as limiting certain routing paths, restricting the types of I2NP messages that may
 be forwarded along various paths, and enforcing certain message expiration times.
-
    
+{%- endtrans %}
    
+
+
    {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
 As a part of
-ElGamal/AES encryption,
+ElGamal/AES encryption,
 a garlic message contains a sender
 specified amount of padding data, allowing the sender to take active countermeasures 
 against traffic analysis.
 This is not currently used, beyond the requirement to pad to a multiple of 16 bytes.
-
    
+{%- endtrans %}
    
+
+
    {% trans netdb=site_url('docs/how/network-database') -%}
 Encryption of additional messages to and from the
-floodfill routers.
-
    
+floodfill routers.
+{%- endtrans %}
    
 
 
 
 
-
    References
    
-
 
 {% endblock %}
diff --git a/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html
new file mode 100644
index 00000000..93ec5cc1
--- /dev/null
+++ b/i2p2www/pages/site/docs/how/intro.html
@@ -0,0 +1,192 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}A Gentle Introduction{% endtrans %}{% endblock %}
+{% block content %}
+
+
    {% trans %}A Gentle Introduction to How I2P Works{% endtrans %}
    
+
+
    {% trans -%}
+I2P is a project to build, deploy, and maintain a network supporting secure and anonymous
+communication. People using I2P are in control of the tradeoffs between anonymity, reliability,
+bandwidth usage, and latency. There is no central point in the network on which pressure can be
+exerted to compromise the integrity, security, or anonymity of the system. The network supports
+dynamic reconfiguration in response to various attacks, and has been designed to make use of
+additional resources as they become available. Of course, all aspects of the network are open and
+freely available.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Unlike many other anonymizing networks, I2P doesn't try to provide anonymity by hiding the
+originator of some communication and not the recipient, or the other way around. I2P is designed to
+allow peers using I2P to communicate with each other anonymously — both sender and recipient
+are unidentifiable to each other as well as to third parties. For example, today there are both
+in-I2P web sites (allowing anonymous publishing / hosting) as well as HTTP proxies to the normal web
+(allowing anonymous web browsing). Having the ability to run servers within I2P is essential, as it
+is quite likely that any outbound proxies to the normal Internet will be monitored, disabled, or
+even taken over to attempt more malicious attacks.
+{%- endtrans %}
    
+
+
    {% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
+The network itself is message oriented - it is essentially a secure and anonymous IP layer, where
+messages are addressed to cryptographic keys (Destinations) and can be significantly larger than IP
+packets. Some example uses of the network include "eepsites" (webservers hosting normal web
+applications within I2P), a BitTorrent client ("I2PSnark"), or a distributed data store. With the
+help of the I2PTunnel application, we are able to stream traditional
+TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and even streaming audio. Most people
+will not use I2P directly, or even need to know they're using it. Instead their view will be of one
+of the I2P enabled applications, or perhaps as a little controller app to turn on and off various
+proxies to enable the anonymizing functionality.
+{%- endtrans %}
    
+
+
    {% trans threatmodel=site_url('docs/how/threat-model') -%}
+An essential part of designing, developing, and testing an anonymizing network is to define the threat model, since there is no such thing as "true" anonymity, just
+increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to
+communicate in arbitrarily hostile environments by providing good anonymity, mixed in with
+sufficient cover traffic provided by the activity of people who require less anonymity. This way,
+some users can avoid detection by a very powerful adversary, while others will try to evade a weaker
+entity, all on the same network, where each one's messages are essentially indistinguishable
+from the others.
+{%- endtrans %}
    
+
+
    {% trans %}Why?{% endtrans %}
    
+
    {% trans comparisons=site_url('comparison') -%}
+There are a multitude of reasons why we need a system to support anonymous communication, and
+everyone has their own personal rationale. There are many other
+efforts working on finding ways to provide varying degrees of anonymity to people through the
+Internet, but we could not find any that met our needs or threat model.
+{%- endtrans %}
    
+
+
    {% trans %}How?{% endtrans %}
    
+
+
    {% trans tunnelrouting=site_url('docs/how/tunnel-routing'), netdb=site_url('docs/how/network-database') -%}
+The network at a glance is made up of a set of nodes ("routers") with a number of unidirectional
+inbound and outbound virtual paths ("tunnels", as outlined on the tunnel routing page). Each router is identified by a cryptographic RouterIdentity which is
+typically long lived. These routers communicate with each other through existing transport
+mechanisms (TCP, UDP, etc), passing various messages. Client applications have their own
+cryptographic identifier ("Destination") which enables it to send and receive messages. These
+clients can connect to any router and authorize the temporary allocation ("lease") of some tunnels
+that will be used for sending and receiving messages through the network. I2P has its own internal
+network database (using a modification of the Kademlia algorithm) for
+distributing routing and contact information securely.
+{%- endtrans %}
    
+
+
    {% trans %}Network topology example{% endtrans %}
    
+
+
    {% trans -%}
+In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on
+their local router. They each have a pair of 2-hop inbound tunnels per destination (labeled 1, 2, 3,
+4, 5 and 6), and a small subset of each of those router's outbound tunnel pool is shown with 2-hop
+outbound tunnels. For simplicity, Charlie's inbound tunnels and Dave's outbound tunnels are not
+shown, nor are the rest of each router's outbound tunnel pool (typically stocked with a few tunnels
+at a time). When Alice and Bob talk to each other, Alice sends a message out one of her (pink)
+outbound tunnels targeting one of Bob's (green) inbound tunnels (tunnel 3 or 4). She knows to send
+to those tunnels on the correct router by querying the network database, which is constantly updated
+as new leases are authorized and old ones expire.
+{%- endtrans %}
    
+
+
    {% trans garlicrouting=site_url('docs/how/garlic-routing') -%}
+If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of
+his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2). To make things
+easier, most messages sent between Alice and Bob are garlic
+wrapped, bundling the sender's own current lease information so that the recipient can reply
+immediately without having to look in the network database for the current data.
+{%- endtrans %}
    
+
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
+To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and
+hence there are no directory servers keeping statistics regarding the performance and reliability of
+routers within the network. As such, each router must keep and maintain profiles of various routers
+and is responsible for selecting appropriate peers to meet the anonymity, performance, and
+reliability needs of the users, as described in the peer selection
+page.
+{%- endtrans %}
    
+
+
    {% trans cryptography=site_url('docs/how/cryptography'), elgamalaes=site_url('docs/how/elgamal-aes') -%}
+The network itself makes use of a significant number of cryptographic
+techniques and algorithms - a full laundry list includes 2048bit ElGamal encryption, 256bit AES
+in CBC mode with PKCS#5 padding, 1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman
+negotiated connections with station to station authentication, and ElGamal / AES+SessionTag.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Content sent over I2P is encrypted through three layers garlic encryption (used to verify the
+delivery of the message to the recipient), tunnel encryption (all messages passing through a tunnel
+is encrypted by the tunnel gateway to the tunnel endpoint), and inter router transport layer
+encryption (e.g. the TCP transport uses AES256 with ephemeral keys).
+{%- endtrans %}
    
+
+
    {% trans -%}
+End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release
+0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a"
+to Bob's router "h" remains. Notice the different use of terms! All data from a to h is end-to-end
+encrypted, but the I2CP connection between the I2P router and the applications is not end-to-end
+encrypted! A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the
+applications running atop of I2P.
+{%- endtrans %}
    
+
+
    {% trans %}End to end layered encryption{% endtrans %}
    
+
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+The specific use of these algorithms are outlined elsewhere.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The two main mechanisms for allowing people who need strong anonymity to use the network are
+explicitly delayed garlic routed messages and more comprehensive tunnels to include support for
+pooling and mixing messages. These are currently planned for release 3.0, but garlic routed messages
+with no delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow
+people to set up and operate behind restricted routes (perhaps with trusted peers), as well as the
+deployment of more flexible and anonymous transports.
+{%- endtrans %}
    
+
+
    {% trans netdb=site_url('docs/how/network-database') -%}
+Some questions have been raised with regards to the scalability of I2P, and reasonably so. There
+will certainly be more analysis over time, but peer lookup and integration should be bounded by
+O(log(N)) due to the network database's algorithm, while end
+to end messages should be O(1) (scale free), since messages go out K hops through the
+outbound tunnel and another K hops through the inbound tunnel, with K no longer than 3. The size of
+the network (N) bears no impact.
+{%- endtrans %}
    
+
+
    {% trans %}When?{% endtrans %}
    
+
    {% trans roadmap=site_url('get-involved/roadmap'),
+jms='http://www.oracle.com/technetwork/java/jms/index.html' -%}
+I2P initially began in Feb 2003 as a proposed modification to Freenet to allow it to use alternate transports, such as JMS, then grew into its own as an
+'anonCommFramework' in April 2003, turning into I2P in July, with code being written in earnest
+starting in August '03. I2P is currently under development, following the roadmap.
+{%- endtrans %}
    
+
+
    {% trans %}Who?{% endtrans %}
    
+
    {% trans team=site_url('about/team') -%}
+We have a small team spread around several continents, working to advance
+different aspects of the project. We are very open to other developers who want to get involved and
+anyone else who would like to contribute in other ways, such as critiques, peer review, testing,
+writing I2P enabled applications, or documentation. The entire system is open source - the router
+and most of the SDK are outright public domain with some BSD and Cryptix licensed code, while some
+applications like I2PTunnel and I2PSnark are GPL. Almost everything is written in Java (1.5+),
+though some third party applications are being written in Python and other languages. The code works
+on Sun Java SE and other Java Virtual Machines.
+{%- endtrans %}
    
+
+
    {% trans %}Where?{% endtrans %}
    
+
    {% trans meetings=get_url('meetings_index') -%}
+Anyone interested should join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net,
+irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de). There are currently no
+scheduled development meetings, however archives are available.
+{%- endtrans %}
    
+
+
    {% trans monotone=site_url('get-involved/guides/monotone') -%}
+The current source is available in monotone.
+{%- endtrans %}
    
+
+
    {% trans %}Additional Information{% endtrans %}
    
+
    {% trans docs=site_url('docs') -%}
+See the Index to Technical Documentation.
+{%- endtrans %}
    
+
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/how/network-database.html b/i2p2www/pages/site/docs/how/network-database.html
new file mode 100644
index 00000000..45bde67c
--- /dev/null
+++ b/i2p2www/pages/site/docs/how/network-database.html
@@ -0,0 +1,800 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}The Network Database{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}June 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9{% endblock %}
+{% block content %}
+
    {% trans %}Overview{% endtrans %}
    
+
+
    {% trans -%}
+I2P's netDb is a specialized distributed database, containing 
+just two types of data - router contact information (RouterInfos) and destination contact
+information (LeaseSets). Each piece of data is signed by the appropriate party and verified
+by anyone who uses or stores it. In addition, the data has liveliness information
+within it, allowing irrelevant entries to be dropped, newer entries to replace
+older ones, and protection against certain classes of attack.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The netDb is distributed with a simple technique called "floodfill",
+where a subset of all routers, called "floodfill routers", maintains the distributed database.
+{%- endtrans %}
    
+
+
+
    RouterInfo
    
+
+
    {% trans -%}
+When an I2P router wants to contact another router, they need to know some 
+key pieces of data - all of which are bundled up and signed by the router into
+a structure called the "RouterInfo", which is distributed with the SHA256 of the router's identity
+as the key. The structure itself contains:
+{%- endtrans %}
    
+
      
+  
    • {% trans %}The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA signing key, and a certificate){% endtrans %}
      • 
+  
    • {% trans %}The contact addresses at which it can be reached (e.g. TCP: example.org port 4108){% endtrans %}
      • 
+  
    • {% trans %}When this was published{% endtrans %}
      • 
+  
    • {% trans %}A set of arbitrary text options{% endtrans %}
      • 
+  
    • {% trans %}The signature of the above, generated by the identity's DSA signing key{% endtrans %}
      • 
+
    
+
+
    {% trans -%}
+The following text options, while not strictly required, are expected
+to be present:
+{%- endtrans %}
    
+
      
+  
    • caps
+({% trans %}Capabilities flags - used to indicate floodfill participation, approximate bandwidth, and perceived reachability{% endtrans %})
+  
      • 
+  
    • coreVersion
+({% trans %}The core library version, always the same as the router version{% endtrans %})
+  
      • 
+  
    • netId = 2
+({% trans %}Basic network compatibility - A router will refuse to communicate with a peer having a different netId{% endtrans %})
+  
      • 
+  
    • router.version
+({% trans %}Used to determine compatibility with newer features and messages{% endtrans %})
+  
      • 
+  
    • stat_uptime = 90m
+({% trans %}Always sent as 90m, for compatibility with an older scheme where routers published their actual uptime,
+and only sent tunnel requests to peers whose was more than 60m{% endtrans %})
+  
      • 
+
    
+
+
    {% trans -%}
+These values are used by other routers for basic decisions.
+Should we connect to this router? Should we attempt to route a tunnel through this router?
+The bandwidth capability flag, in particular, is used only to determine whether
+the router meets a minimum threshold for routing tunnels.
+Above the minimum threshold, the advertised bandwidth is not used or trusted anywhere
+in the router, except for display in the user interface and for debugging and network analysis.
+{%- endtrans %}
    
+
+
+
    {% trans stats=i2pconv('stats.i2p') -%}
+Additional text options include
+a small number of statistics about the router's health, which are aggregated by
+sites such as {{ stats }}
+for network performance analysis and debugging.
+These statistics were chosen to provide data crucial to the developers,
+such as tunnel build success rates, while balancing the need for such data
+with the side-effects that could result from revealing this data.
+Current statistics are limited to:
+{%- endtrans %}
    
+
      
+  
    • {% trans %}Client and exploratory tunnel build success, reject, and timeout rates{% endtrans %}
+  
    • {% trans %}1 hour average number of participating tunnels{% endtrans %}
+
    
+
+
    {% trans -%}
+The data published can be seen in the router's user interface,
+but is not used or trusted within the router.
+As the network has matured, we have gradually removed most of the published
+statistics to improve anonymity, and we plan to remove more in future releases.
+{%- endtrans %}
    
+
+
    
+  {% trans %}RouterInfo specification{% endtrans %}
+
    
+
    
+  {% trans %}RouterInfo Javadoc{% endtrans %}
+
    
+
+
    {% trans %}RouterInfo Expiration{% endtrans %}
    
+
    {% trans -%}
+RouterInfos have no set expiration time.
+Each router is free to maintain its own local policy to trade off the frequency of RouterInfo lookups
+with memory or disk usage.
+In the current implementation, there are the following general policies:
+{%- endtrans %}
    
+
      
+  
    • {% trans -%}
+There is no expiration during the first hour of uptime, as the persistent stored data may be old.
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+There is no expiration if there are 25 or less RouterInfos.
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+As the number of local RouterInfos grows, the expiration time shrinks, in an attempt to maintain
+a reasonable number RouterInfos. The expiration time with less than 120 routers is 72 hours,
+while expiration time with 300 routers is around 30 hours.
+{%- endtrans %}
      • 
+  
    • {% trans ssu=site_url('docs/transport/ssu') -%}
+RouterInfos containing SSU introducers expire in about an hour, as
+the introducer list expires in about that time.
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+Floodfills use a short expiration time (1 hour) for all local RouterInfos, as valid RouterInfos will
+be frequently republished to them.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans %}RouterInfo Persistent Storage{% endtrans %}
    
+
+
    {% trans -%}
+RouterInfos are periodically written to disk so that they are available after a restart.
+{%- endtrans %}
    
+
+
+
    LeaseSet
    
+
+
    {% trans -%}
+The second piece of data distributed in the netDb is a "LeaseSet" - documenting
+a group of tunnel entry points (leases) for a particular client destination.
+Each of these leases specify the following information:
+{%- endtrans %}
    
+  
      
+    
    • {% trans %}The tunnel gateway router (by specifying its identity){% endtrans %}
      • 
+    
    • {% trans %}The tunnel ID on that router to send messages with (a 4 byte number){% endtrans %}
      • 
+    
    • {% trans %}When that tunnel will expire.{% endtrans %}
      • 
+  
    
+
    {% trans -%}
+The LeaseSet itself is stored in the netDb under
+the key derived from the SHA256 of the destination.
+{%- endtrans %}
    
+
+
    {% trans -%}
+In addition to these leases, the LeaseSet includes:
+{%- endtrans %}
    
+  
      
+    
    • {% trans %}The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA signing key and a certificate){% endtrans %}
      • 
+    
    • {% trans %}Additional encryption public key: used for end-to-end encryption of garlic messages{% endtrans %}
      • 
+    
    • {% trans %}Additional signing public key: intended for LeaseSet revocation, but is currently unused.{% endtrans %}
      • 
+    
    • {% trans %}Signature of all the LeaseSet data, to make sure the Destination published the LeaseSet.{% endtrans %}
      • 
+  
    
+
+
    
+  {% trans %}Lease specification{% endtrans %}
+  
    
+  {% trans %}LeaseSet specification{% endtrans %}
+
    
+
    
+  {% trans %}Lease Javadoc{% endtrans %}
+  
    
+  {% trans %}LeaseSet Javadoc{% endtrans %}
+
    
+
+
+
    {% trans %}Unpublished LeaseSets{% endtrans %}
    
+
    {% trans -%}
+A LeaseSet for a destination used only for outgoing connections is unpublished.
+It is never sent for publication to a floodfill router.
+"Client" tunnels, such as those for web browsing and IRC clients, are unpublished.
+Servers will still be able to send messages back to those unpublished destinations,
+because of I2NP storage messages.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Revoked LeaseSets{% endtrans %}
    
+
    {% trans -%}
+A LeaseSet may be revoked by publishing a new LeaseSet with zero leases.
+Revocations must be signed by the additional signing key in the LeaseSet.
+Revocations are not fully implemented, and it is unclear if they have any practical use.
+This is the only planned use for that signing key, so it is currently unused.
+{%- endtrans %}
    
+
+
    {% trans %}Encrypted LeaseSets{% endtrans %}
    
+
    {% trans -%}
+In an encrypted LeaseSet, all Leases are encrypted with a separate DSA key.
+The leases may only be decoded, and thus the destination may only be contacted,
+by those with the key.
+There is no flag or other direct indication that the LeaseSet is encrypted.
+Encrypted LeaseSets are not widely used, and it is a topic for future work to
+research whether the user interface and implementation of encrypted LeaseSets could be improved.
+{%- endtrans %}
    
+
+
    {% trans %}LeaseSet Expiration{% endtrans %}
    
+
    {% trans -%}
+All Leases (tunnels) are valid for 10 minutes; therefore, a LeaseSet expires
+10 minutes after the earliest creation time of all its Leases.
+{%- endtrans %}
    
+
+
    {% trans %}LeaseSet Persistent Storage{% endtrans %}
    
+
    {% trans -%}
+There is no persistent storage of LeaseSet data since they expire so quickly.
+{%- endtrans %}
    
+
+
+
    {% trans %}Bootstrapping{% endtrans %}
    
+
    {% trans -%}
+The netDb is decentralized, however you do need at
+least one reference to a peer so that the integration process
+ties you in. This is accomplished by "reseeding" your router with the RouterInfo
+of an active peer - specifically, by retrieving their routerInfo-$hash.dat
+file and storing it in your netDb/ directory. Anyone can provide
+you with those files - you can even provide them to others by exposing your own
+netDb directory. To simplify the process,
+volunteers publish their netDb directories (or a subset) on the regular (non-i2p) network,
+and the URLs of these directories are hardcoded in I2P.
+When the router starts up for the first time, it automatically fetches from
+one of these URLs, selected at random.
+{%- endtrans %}
    
+
+
    {% trans %}Floodfill{% endtrans %}
    
+
    {% trans -%}
+The floodfill netDb is a simple distributed storage mechanism.
+The storage algorithm is simple: send the data to the closest peer that has advertised itself
+as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them 
+for the entry to be sent, verifying its proper insertion / distribution. If the 
+verification peer doesn't reply, or they don't have the entry, the sender 
+repeats the process. When the peer in the floodfill netDb receives a netDb 
+store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers.
+The peers selected are the ones closest (according to the XOR-metric) to a specific key.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Determining who is part of the floodfill netDb is trivial - it is exposed in each 
+router's published routerInfo as a capability.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Floodfills have no central authority and do not form a "consensus" -
+they only implement a simple DHT overlay.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Floodfill Router Opt-in{% endtrans %}
    
+
+
    {% trans -%}
+Unlike Tor, where the directory servers are hardcoded and trusted,
+and operated by known entities,
+the members of the I2P floodfill peer set need not be trusted, and
+change over time.
+{%- endtrans %}
    
+
+
    {% trans -%}
+To increase reliability of the netDb, and minimize the impact
+of netDb traffic on a router, floodfill is automatically enabled
+only on routers that are configured with high bandwidth limits.
+Routers with high bandwidth limits (which must be manually configured,
+as the default is much lower) are presumed to be on lower-latency
+connections, and are more likely to be available 24/7.
+The current minimum share bandwidth for a floodfill router is 128 KBytes/sec.
+{%- endtrans %}
    
+
+
    {% trans -%}
+In addition, a router must pass several additional tests for health
+(outbound message queue time, job lag, etc.) before floodfill operation is
+automatically enabled.
+{%- endtrans %}
    
+
+
    {% trans -%}
+With the current rules for automatic opt-in, approximately 6% of
+the routers in the network are floodfill routers.
+{%- endtrans %}
    
+
+
    {% trans -%}
+While some peers are manually configured to be floodfill,
+others are simply high-bandwidth routers who automatically volunteer
+when the number of floodfill peers drops below a threshold.
+This prevents any long-term network damage from losing most or all
+floodfills to an attack.
+In turn, these peers will un-floodfill themselves when there are
+too many floodfills outstanding.
+{%- endtrans %}
    
+
+
    {% trans %}Floodfill Router Roles{% endtrans %}
    
+
    {% trans -%}
+A floodfill router's only services that are in addition to those of non-floodfill routers
+are in accepting netDb stores and responding to netDb queries.
+Since they are generally high-bandwidth, they are more likely to participate in a high number of tunnels
+(i.e. be a "relay" for others), but this is not directly related to their distributed database services.
+{%- endtrans %}
    
+
+
+
    {% trans %}Kademlia Closeness Metric{% endtrans %}
    
+
    {% trans -%}
+The netDb uses a simple Kademlia-style XOR metric to determine closeness.
+The SHA256 hash of the key being looked up or stored is XOR-ed with
+the hash of the router in question to determine closeness.
+A modification to this algorithm is done to increase the costs of Sybil attacks.
+Instead of the SHA256 hash of the key being looked up of stored, the SHA256 hash is taken
+of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd).
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Storage, Verification, and Lookup Mechanics{% endtrans %}
    
+
+
    {% trans %}RouterInfo Storage to Peers{% endtrans %}
    
+
    {% trans i2np=site_url('docs/protocol/i2np'), ntcp=site_url('docs/transport/ntcp'), ssu=site_url('docs/transport/ssu') -%}
+I2NP DatabaseStoreMessages containing the local RouterInfo are exchanged with peers
+as a part of the initialization of a NTCP
+or SSU transport connection.
+{%- endtrans %}
    
+
+
+
    {% trans %}LeaseSet Storage to Peers{% endtrans %}
    
+
    {% trans i2np=site_url('docs/protocol/i2np') -%}
+I2NP DatabaseStoreMessages containing the local LeaseSet are periodically exchanged with peers
+by bundling them in a garlic message along with normal traffic from the related Destination.
+This allows an initial response, and later responses, to be sent to an appropriate Lease,
+without requiring any LeaseSet lookups, or requiring the communicating Destinations to have published LeaseSets at all.
+{%- endtrans %}
    
+
+
+
    {% trans %}RouterInfo Storage to Floodfills{% endtrans %}
    
+
    {% trans i2np=site_url('docs/protocol/i2np') -%}
+A router publishes its own RouterInfo by directly connecting to a floodfill router
+and sending it a I2NP DatabaseStoreMessage
+with a nonzero Reply Token. The message is not end-to-end garlic encrypted,
+as this is a direct connection, so there are no intervening routers
+(and no need to hide this data anyway).
+The floodfill router replies with a
+I2NP DeliveryStatusMessage,
+with the Message ID set to the value of the Reply Token.
+{%- endtrans %}
    
+
+
+
+
+
    {% trans %}LeaseSet Storage to Floodfills{% endtrans %}
    
+
    {% trans -%}
+Storage of LeaseSets is much more sensitive than for RouterInfos, as a router
+must take care that the LeaseSet cannot be associated with the router.
+{%- endtrans %}
    
+
+
    {% trans i2np=site_url('docs/protocol/i2np') -%}
+A router publishes a local LeaseSet by
+sending a I2NP DatabaseStoreMessage
+with a nonzero Reply Token over an outbound client tunnel for that Destination.
+The message is end-to-end garlic encrypted using the Destination's Session Key Manager,
+to hide the message from the tunnel's outbound endpoint.
+The floodfill router replies with a
+I2NP DeliveryStatusMessage,
+with the Message ID set to the value of the Reply Token.
+This message is sent back to one of the client's inbound tunnels.
+{%- endtrans %}
    
+
+
+
    {% trans %}Flooding{% endtrans %}
    
+
    {% trans -%}
+After a floodfill router receives a DatabaseStoreMessage containing a
+valid RouterInfo or LeaseSet which is newer than that previously stored in its
+local NetDb, it "floods" it.
+To flood a NetDb entry, it looks up the 7 floodfill routers closest to the key
+of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.)
+{%- endtrans %}
    
+
+
    {% trans i2np=site_url('docs/protocol/i2np') -%}
+It then directly connects to each of the 7 peers
+and sends it a I2NP DatabaseStoreMessage
+with a zero Reply Token. The message is not end-to-end garlic encrypted,
+as this is a direct connection, so there are no intervening routers
+(and no need to hide this data anyway).
+The other routers do not reply or re-flood, as the Reply Token is zero.
+{%- endtrans %}
    
+
+
+
    {% trans %}RouterInfo and LeaseSet Lookup{% endtrans %}
    
+
    {% trans i2np=site_url('docs/protocol/i2np') -%}
+The I2NP DatabaseLookupMessage is used to request a netdb entry from a floodfill router.
+Lookups are sent out one of the router's outbound exploratory tunnels.
+The replies are specified to return via one of the router's inbound exploratory tunnels.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Lookups are generally sent to the two "good" (the connection doesn't fail) floodfill routers closest to the requested key, in parallel.
+{%- endtrans %}
    
+
+
    {% trans i2np=site_url('docs/protocol/i2np') -%}
+If the key is found locally by the floodfill router, it responds with a
+I2NP DatabaseStoreMessage.
+If the key is not found locally by the floodfill router, it responds with a
+I2NP DatabaseSearchReplyMessage
+containing a list of other floodfill routers close to the key.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Lookups are not encrypted and thus are vulnerable to snooping by the outbound endpoint
+(OBEP) of the client tunnel.
+{%- endtrans %}
    
+
+
    {% trans -%}
+As the requesting router does not reveal itself, there is no recipient public key for the floodfill router to
+encrypt the reply with. Therefore, the reply is exposed to the inbound gateway (IBGW)
+of the inbound exploratory tunnel.
+An appropriate method of encrypting the reply is a topic for future work.
+{%- endtrans %}
    
+
+
    {% trans pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%}
+(Reference: Hashing it out in Public Sections 2.2-2.3 for terms below in italics)
+{%- endtrans %}
    
+
+
    {% trans -%}
+Due to the relatively small size of the network and the flooding redundancy of 8x,
+lookups are usually O(1) rather than O(log n) --
+a router is highly likely to know a floodfill router close enough to the key to get the answer on the first try.
+In releases prior to 0.8.9, routers used a lookup redundancy of two
+(that is, two lookups were performed in parallel to different peers), and
+neither recursive nor iterative routing for lookups was implemented.
+Queries were sent through multiple routes simultaneously
+to reduce the chance of query failure.
+{%- endtrans %}
    
+
+
    {% trans -%}
+As of release 0.8.9, iterative lookups are implemented with no lookup redundancy.
+This is a more efficient and reliable lookup that will work much better
+when not all floodfill peers are known, and it removes a serious
+limitation to network growth. As the network grows and each router knows only a small
+subset of the floodfill peers, lookups will become O(log n).
+Even if the peer does not return references closer to the key, the lookup continues with
+the next-closest peer, for added robustness, and to prevent a malicious floodfill from
+black-holing a part of the key space. Lookups continue until a total lookup timeout is reached,
+or the maximum number of peers is queried.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Node IDs are verifiable in that we use the router hash directly as both the node ID and the Kademlia key.
+Incorrect responses that are not closer to the search key are generally ignored.
+Given the current size of the network, a router has
+detailed knowledge of the neighborhood of the destination ID space.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}RouterInfo Storage Verification{% endtrans %}
    
+
    {% trans -%}
+To verify a storage was successful, a router simply waits about 10 seconds,
+then sends a lookup to another floodfill router close to the key
+(but not the one the store was sent to).
+Lookups sent out one of the router's outbound exploratory tunnels.
+Lookups are end-to-end garlic encrypted to prevent snooping by the outbound endpoint(OBEP).
+{%- endtrans %}
    
+
+
    {% trans %}LeaseSet Storage Verification{% endtrans %}
    
+
    {% trans -%}
+To verify a storage was successful, a router simply waits about 10 seconds,
+then sends a lookup to another floodfill router close to the key
+(but not the one the store was sent to).
+Lookups sent out one of the outbound client tunnels for the destination of the LeaseSet being verified.
+To prevent snooping by the OBEP of the outbound tunnel,
+lookups are end-to-end garlic encrypted.
+The replies are specified to return via one of the client's inbound tunnels.
+{%- endtrans %}
    
+
+
    {% trans -%}
+As for regular lookups, the reply is unencrypted,
+thus exposing the reply to the inbound gateway (IBGW) of the reply tunnel, and
+an appropriate method of encrypting the reply is a topic for future work.
+As the IBGW for the reply is one of the gateways published in the LeaseSet,
+the exposure is minimal.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Exploration{% endtrans %}
    
+
    {% trans i2np=site_url('docs/protocol/i2np') -%}
+Exploration is a special form of netdb lookup, where a router attempts to learn about
+new routers.
+It does this by sending a floodfill router a I2NP DatabaseLookupMessage, looking for a random key.
+As this lookup will fail, the floodfill would normally respond with a
+I2NP DatabaseSearchReplyMessage containing hashes of floodfill routers close to the key.
+This would not be helpful, as the requesting router probably already knows those floodfills,
+and it would be impractical to add ALL floodfill routers to the "don't include" field of the lookup.
+For an exploration query, the requesting router adds a router hash of all zeros to the
+"don't include" field of the DatabaseLookupMessage.
+The floodfill will then respond only with non-floodfill routers close to the requested key.
+{%- endtrans %}
    
+
+
+
    {% trans %}Notes on Lookup Responses{% endtrans %}
    
+
    {% trans -%}
+The response to a lookup request is either a Database Store Message (on success) or a
+Database Search Reply Message (on failure). The DSRM contains a 'from' router hash field
+to indicate the source of the reply; the DSM does not.
+The DSRM 'from' field is unauthenticated and may be spoofed or invalid.
+There are no other response tags. Therefore, when making multiple requests in parallel, it is
+difficult to monitor the performance of the various floodfill routers.
+{%- endtrans %}
    
+
+
+
    {% trans %}MultiHoming{% endtrans %}
    
+
+
    {% trans -%}
+Destinations may be hosted on multiple routers simultaneously, by using the same
+private and public keys (traditionally stored in eepPriv.dat files).
+As both instances will periodically publish their signed LeaseSets to the floodfill peers,
+the most recently published LeaseSet will be returned to a peer requesting a database lookup.
+As LeaseSets have (at most) a 10 minute lifetime, should a particular instance go down,
+the outage will be 10 minutes at most, and generally much less than that.
+The multihoming function has been verified and is in use by several services on the network.
+{%- endtrans %}
    
+
+
    {% trans %}Threat Analysis{% endtrans %}
    
+
    {% trans threatmodel=site_url('docs/how/threat-model') -%}
+Also discussed on the threat model page.
+{%- endtrans %}
    
+
+
    {% trans -%}
+A hostile user may attempt to harm the network by
+creating one or more floodfill routers and crafting them to offer
+bad, slow, or no responses.
+Some scenarios are discussed below.
+{%- endtrans %}
    
+
+
    {% trans %}General Mitigation Through Growth{% endtrans %}
    
+
    {% trans -%}
+There are currently hundreds of floodfill routers in the network.
+Most of the following attacks will become more difficult, or have less impact,
+as the network size and number of floodfill routers increase.
+{%- endtrans %}
    
+
+
+
    {% trans %}General Mitigation Through Redundancy{% endtrans %}
    
+
    {% trans -%}
+Via flooding, all netdb entries are stored on the 8 floodfill routers closest to the key.
+{%- endtrans %}
    
+
+
+
    {% trans %}Forgeries{% endtrans %}
    
+
    {% trans -%}
+All netdb entries are signed by their creators, so no router may forge a
+RouterInfo or LeaseSet.
+{%- endtrans %}
    
+
+
    {% trans %}Slow or Unresponsive{% endtrans %}
    
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
+Each router maintains an expanded set of statistics in the
+peer profile for each floodfill router,
+covering various quality metrics for that peer.
+The set includes:
+{%- endtrans %}
    
+
      
+  
    • {% trans %}Average response time{% endtrans %}
      • 
+  
    • {% trans %}Percentage of queries answered with the data requested{% endtrans %}
      • 
+  
    • {% trans %}Percentage of stores that were successfully verified{% endtrans %}
      • 
+  
    • {% trans %}Last successful store{% endtrans %}
      • 
+  
    • {% trans %}Last successful lookup{% endtrans %}
      • 
+  
    • {% trans %}Last response{% endtrans %}
      • 
+
    
+
+
    {% trans -%}
+Each time a router needs to make a determination on which floodfill router is closest to a key,
+it uses these metrics to determine which floodfill routers are "good".
+The methods, and thresholds, used to determine "goodness" are relatively new, and
+are subject to further analysis and improvement.
+While a completely unresponsive router will quickly be identified and avoided,
+routers that are only sometimes malicious may be much harder to deal with.
+{%- endtrans %}
    
+
+
+
    {% trans %}Sybil Attack (Full Keyspace){% endtrans %}
    
+
    {% trans url='http://citeseer.ist.psu.edu/douceur02sybil.html' -%}
+An attacker may mount a Sybil attack
+by creating a large number of floodfill routers spread throughout the keyspace.
+{%- endtrans %}
    
+
+
    {% trans url='http://blog.torproject.org/blog/june-2010-progress-report' -%}
+(In a related example, a researcher recently created a
+large number of Tor relays.)
+If successful, this could be an effective DOS attack on the entire network.
+{%- endtrans %}
    
+
+
    {% trans -%}
+If the floodfills are not sufficiently misbehaving to be marked as "bad" using the peer profile
+metrics described above, this is a difficult scenario to handle.
+Tor's response can be much more nimble in the relay case, as the suspicious relays
+can be manually removed from the consensus.
+Some possible responses for the I2P network are listed below, however none of them is completely satisfactory:
+{%- endtrans %}
    
+
      
+  
    • {% trans -%}
+Compile a list of bad router hashes or IPs, and announce the list through various means
+(console news, website, forum, etc.); users would have to manually download the list and
+add it to their local "blacklist".
+{%- endtrans %}
      • 
+  
    • {% trans %}Ask everyone in the network to enable floodfill manually (fight Sybil with more Sybil){% endtrans %}
      • 
+  
    • {% trans %}Release a new software version that includes the hardcoded "bad" list{% endtrans %}
      • 
+  
    • {% trans -%}
+Release a new software version that improves the peer profile metrics and thresholds,
+in an attempt to automatically identify the "bad" peers.
+{%- endtrans %}
      • 
+  
    • {% trans %}Add software that disqualifies floodfills if too many of them are in a single IP block{% endtrans %}
      • 
+  
    • {% trans -%}
+Implement an automatic subscription-based blacklist controlled by a single individual or group.
+This would essentially implement a portion of the Tor "consensus" model.
+Unfortunately it would also give a single individual or group the power to
+block participation of any particular router or IP in the network,
+or even to completely shutdown or destroy the entire network.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans -%}
+This attack becomes more difficult as the network size grows.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Sybil Attack (Partial Keyspace){% endtrans %}
    
+
    {% trans url='http://citeseer.ist.psu.edu/douceur02sybil.html' -%}
+An attacker may mount a Sybil attack
+by creating a small number (8-15) of floodfill routers clustered closely in the keyspace,
+and distribute the RouterInfos for these routers widely.
+Then, all lookups and stores for a key in that keyspace would be directed
+to one of the attacker's routers.
+If successful, this could be an effective DOS attack on a particular eepsite, for example.
+{%- endtrans %}
    
+
+
    {% trans -%}
+As the keyspace is indexed by the cryptographic (SHA256) Hash of the key,
+an attacker must use a brute-force method to repeatedly generate router hashes
+until he has enough that are sufficiently close to the key.
+The amount of computational power required for this, which is dependent on network
+size, is unknown.
+{%- endtrans %}
    
+
+
    {% trans -%}
+As a partial defense against this attack,
+the algorithm used to determine Kademlia "closeness" varies over time.
+Rather than using the Hash of the key (i.e. H(k)) to determine closeness,
+we use the Hash of the key appended with the current date string, i.e. H(k + YYYYMMDD).
+A function called the "routing key generator" does this, which transforms the original key into a "routing key".
+In other words, the entire netdb keyspace "rotates" every day at UTC midnight.
+Any partial-keyspace attack would have to be regenerated every day, for
+after the rotation, the attacking routers would no longer be close
+to the target key, or to each other.
+{%- endtrans %}
    
+
+
    {% trans -%}
+This attack becomes more difficult as the network size grows.
+{%- endtrans %}
    
+
+
    {% trans -%}
+One consequence of daily keyspace rotation is that the distributed network database
+may become unreliable for a few minutes after the rotation --
+lookups will fail because the new "closest" router has not received a store yet.
+The extent of the issue, and methods for mitigation
+(for example netdb "handoffs" at midnight)
+are a topic for further study.
+{%- endtrans %}
    
+
+
+
    {% trans %}Bootstrap Attacks{% endtrans %}
    
+
    {% trans -%}
+An attacker could attempt to boot new routers into an isolated
+or majority-controlled network by taking over a reseed website,
+or tricking the developers into adding his reseed website
+to the hardcoded list in the router.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Several defenses are possible, and most of these are planned:
+{%- endtrans %}
    
+
      
+  
    • {% trans -%}
+Disallow fallback from HTTPS to HTTP for reseeding.
+A MITM attacker could simply block HTTPS, then respond to the HTTP.
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+Changing the reseed task to fetch a subset of RouterInfos from
+each of several reseed sites rather than using only a single site
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+Creating an out-of-network reseed monitoring service that
+periodically polls reseed websites and verifies that the
+data are not stale or inconsistent with other views of the network
+{%- endtrans %}
      • 
+  
    • {% trans %}Bundling reseed data in the installer{% endtrans %}
      • 
+
    
+
+
    {% trans %}Query Capture{% endtrans %}
    
+
    {% trans pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%}
+See also lookup
+(Reference: Hashing it out in Public Sections 2.2-2.3 for terms below in italics)
+{%- endtrans %}
    
+
+
    {% trans -%}
+Similar to a bootstrap attack, an attacker using a floodfill router could attempt to "steer"
+peers to a subset of routers controlled by him by returning their references.
+{%- endtrans %}
    
+
+
    {% trans -%}
+This is unlikely to work via exploration, because exploration is a low-frequency task.
+Routers acquire a majority of their peer references through normal tunnel building activity.
+Exploration results are generally limited to a few router hashes,
+and each exploration query is directed to a random floodfill router.
+{%- endtrans %}
    
+
+
    {% trans i2np=site_url('docs/protocol/i2np'),
+pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%}
+As of release 0.8.9, iterative lookups are implemented.
+For floodfill router references returned in a
+I2NP DatabaseSearchReplyMessage
+response to a lookup,
+these references are followed if they are closer (or the next closest) to the lookup key.
+The requesting router does not trust that the references are
+closer to the key (i.e. they are verifiably correct.
+The lookup also does not stop when no closer key is found, but continues by querying the
+next-closet node, until the timeout or maximum number of queries is reached.
+This prevents a malicious floodfill from black-holing a part of the key space.
+Also, the daily keyspace rotation requires an attacker to regenerate a router info
+within the desired key space region.
+This design ensures that the query capture attack described in
+Hashing it out in Public
+is much more difficult.
+{%- endtrans %}
    
+
+
    {% trans %}DHT-Based Relay Selection{% endtrans %}
    
+
    {% trans pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%}
+(Reference: Hashing it out in Public Section 3)
+{%- endtrans %}
    
+
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
+This doesn't have much to do with floodfill, but see
+the peer selection page
+for a discussion of the vulnerabilities of peer selection for tunnels.
+{%- endtrans %}
    
+
+
    {% trans %}Information Leaks{% endtrans %}
    
+
    {% trans pdf='http://www.eecs.berkeley.edu/~pmittal/publications/nisan-torsk-ccs10.pdf' -%}
+(Reference: In Search of an Anonymous and Secure Lookup Section 3)
+{%- endtrans %}
    
+
+
    {% trans peerselection=site_url('docs/how/peer-selection'),
+tunnelrouting=site_url('docs/how/tunnel-routing') -%}
+This paper addresses weaknesses in the "Finger Table" DHT lookups used by Torsk and NISAN.
+At first glance, these do not appear to apply to I2P. First, the use of DHT by Torsk and NISAN
+is significantly different from that in I2P. Second, I2P's network database lookups are only
+loosely correlated to the peer selection and
+tunnel building processes; only previously-known peers
+are used for tunnels.
+Also, peer selection is unrelated to any notion of DHT key-closeness.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Some of this may actually be more interesting when the I2P network gets much larger.
+Right now, each router knows a large proportion of the network, so looking up a particular
+Router Info in the network database is not strongly indicative of a future intent to use
+that router in a tunnel. Perhaps when the network is 100 times larger, the lookup may be
+more correlative. Of course, a larger network makes a Sybil attack that much harder.
+{%- endtrans %}
    
+
+
    {% trans threatmodel=site_url('docs/how/threat-model') -%}
+However, the general issue of DHT information leakage in I2P needs further investigation.
+The floodfill routers are in a position to observe queries and gather information.
+Certainly, at a level of f = 0.2 (20% malicious nodes, as specifed in the paper)
+we expect that many of the Sybil threats we describe
+(here,
+here and
+here)
+become problematic for several reasons.
+{%- endtrans %}
    
+
+
+
    {% trans %}History{% endtrans %}
    
+
    
+  {% trans %}Moved to the netdb discussion page{% endtrans %}.
+
    
+
+
    {% trans %}Future Work{% endtrans %}
    
+
    {% trans -%}
+End-to-end encryption of additional netDb lookups and responses.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Better methods for tracking lookup responses.
+{%- endtrans %}
    
+
+{% endblock %}
+
diff --git a/i2p2www/pages/site/docs/how/peer-selection.html b/i2p2www/pages/site/docs/how/peer-selection.html
new file mode 100644
index 00000000..fd26f061
--- /dev/null
+++ b/i2p2www/pages/site/docs/how/peer-selection.html
@@ -0,0 +1,312 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Peer Profiling and Selection{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}July 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
+{% block content %}
+
    {% trans %}Overview{% endtrans %}
    
+
+
    {% trans %}Peer Profiling{% endtrans %}
    
+
+
    {% trans netdb=site_url('docs/how/network-database') -%}
+Peer profiling is the process of collecting data based on the observed performance
+of other routers or peers, and classifying those peers into groups.
+Profiling does not use any claimed performance data published by the peer itself
+in the network database.
+{%- endtrans %}
    
+
+
    {% trans %}Profiles are used for two purposes:{% endtrans %}
    
+
      
+
    1. {% trans %}Selecting peers to relay our traffic through, which is discussed below{% endtrans %}
      2. 
+
    2. {% trans netdb=site_url('docs/how/network-database') -%}
+Choosing peers from the set of floodfill routers to use for network database storage and queries,
+which is discussed on the network database page
+{%- endtrans %}
      3. 
+
    
+
+
+
    {% trans %}Peer Selection{% endtrans %}
    
+
    {% trans -%}
+Peer selection is the process of choosing which routers
+on the network we want to relay our messages to go through (which peers will we 
+ask to join our tunnels).  To accomplish this, we keep track of how each
+peer performs (the peer's "profile") and use that data to estimate how 
+fast they are, how often they will be able to accept our requests, and 
+whether they seem to be overloaded or otherwise unable to perform what
+they agree to reliably.
+{%- endtrans %}
    
+
+
    {% trans threatmodel=site_url('docs/how/threat-model') -%}
+Unlike some other anonymous networks, in I2P,
+claimed bandwidth is untrusted and is only used to avoid those peers
+advertising very low bandwidth insufficient for routing tunnels.
+All peer selection is done through profiling.
+This prevents simple attacks based on peers claiming high bandwidth
+in order to capture large numbers of tunnels.
+It also makes
+timing attacks
+more difficult.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Peer selection is done quite frequently, as a router may maintain a large number
+of client and exploratory tunnels, and a tunnel lifetime is only 10 minutes.
+{%- endtrans %}
    
+
+
+
    {% trans %}Further Information{% endtrans %}
    
+
    {% trans pdf=url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf'),
+url='http://www.pet-con.org/index.php/PET_Convention_2009.1' -%}
+For more information see the paper
+Peer Profiling and Selection in the I2P Anonymous Network
+presented at PET-CON 2009.1.
+See below for notes on minor changes since the paper was published.
+{%- endtrans %}
    
+
+
    {% trans %}Profiles{% endtrans %}
    
+
    {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/PeerProfile.html' -%}
+Each peer has a set of data points collected about them, including statistics 
+about how long it takes for them to reply to a network database query, how 
+often their tunnels fail, and how many new peers they are able to introduce 
+us to, as well as simple data points such as when we last heard from them or
+when the last communication error occurred.  The specific data points gathered
+can be found in the code.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Profiles are fairly small, a few KB. To control memory usage, the profile expiration time
+lessens as the number of profiles grows.
+Profiles are kept in memory until router shutdown, when they are written to disk.
+At startup, the profiles are read so the router need not reinitialize all profiles,
+thus allowing a router to quickly re-integrate into the network after startup.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Peer Summaries{% endtrans %}
    
+
    {% trans -%}
+While the profiles themselves can be considered a summary of a peer's 
+performance, to allow for effective peer selection we break each summary down 
+into four simple values, representing the peer's speed, its capacity, how well 
+integrated into the network it is, and whether it is failing.
+{%- endtrans %}
    
+
+
    {% trans %}Speed{% endtrans %}
    
+
    {% trans -%}
+The speed calculation
+simply goes through the profile and estimates how much data we can
+send or receive on a single tunnel through the peer in a minute.  For this estimate it just looks at
+performance in the previous minute.
+{%- endtrans %}
    
+
+
    {% trans %}Capacity{% endtrans %}
    
+
    {% trans -%}
+The capacity calculation
+simply goes through the profile and estimates how many tunnels the peer
+would agree to participate in over a given time period.  For this estimate it looks at 
+how many tunnel build requests
+the peer has accepted, rejected, and dropped, and how many
+of the agreed-to tunnels later failed.
+While the calculation is time-weighted so that recent activity counts more than later activity,
+statistics up to 48 hours old may be included.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Recognizing and avoiding unreliable and unreachable
+peers is critically important.
+Unfortunately, as the tunnel building and testing require the participation of several peers,
+it is difficult to positively identify the cause of a dropped build request or test failure.
+The router assigns a probability of failure to each of the
+peers, and uses that probability in the capacity calculation.
+Drops and test failures are weighted much higher than rejections.
+{%- endtrans %}
    
+
+
    {% trans %}Peer organization{% endtrans %}
    
+
    {% trans -%}
+As mentioned above, we drill through each peer's profile to come up with a 
+few key calculations, and based upon those, we organize each peer into three
+groups - fast, high capacity, and standard.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The groupings are not mutually exclusive, nor are they unrelated:
+{%- endtrans %}
    
+
       
+
    • {% trans -%}
+A peer is considered "high capacity" if its capacity calculation meets or 
+exceeds the median of all peers.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+A peer is considered "fast" if they are already "high capacity" and their 
+speed calculation meets or exceeds the median of all peers.
+{%- endtrans %}
      • 
+
    • {% trans %}A peer is considered "standard" if it is not "high capacity"{% endtrans %}
      • 
+
    
+
+
    {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/ProfileOrganizer.html' -%}
+These groupings are implemented in the router's
+ProfileOrganizer.
+{%- endtrans %}
    
+
+
    {% trans %}Group size limits{% endtrans %}
    
+
    {% trans -%}
+The size of the groups may be limited.
+{%- endtrans %}
    
+
+
      
+
    • {% trans -%}
+The fast group is limited to 30 peers.
+If there would be more, only the ones with the highest speed rating are placed in the group.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+The high capacity group is limited to 75 peers (including the fast group)
+If there would be more, only the ones with the highest capacity rating are placed in the group.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+The standard group has no fixed limit, but is somewhat smaller than the number of RouterInfos
+stored in the local network database.
+On an active router in today's network, there may be about 1000 RouterInfos and 500 peer profiles
+(including those in the fast and high capacity groups)
+{%- endtrans %}
      • 
+
    
+
+
    {% trans %}Recalculation and Stability{% endtrans %}
    
+
    {% trans -%}
+Summaries are recalculated, and peers are resorted into groups, every 45 seconds.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The groups tend to be fairly stable, that is, there is not much "churn" in the rankings
+at each recalculation.
+Peers in the fast and high capacity groups get more tunnels build through them, which increases their speed and capacity ratings,
+which reinforces their presence in the group.
+{%- endtrans %}
    
+
+
+
+
+
    {% trans %}Peer Selection{% endtrans %}
    
+
    {% trans -%}
+The router selects peers from the above groups to build tunnels through.
+{%- endtrans %}
    
+
+
+
    {% trans %}Peer Selection for Client Tunnels{% endtrans %}
    
+
    {% trans -%}
+Client tunnels are used for application traffic, such as for HTTP proxies and web servers.
+{%- endtrans %}
    
+
+
    {% trans -%}
+To reduce the susceptibility to some attacks,
+and increase performance,
+peers for building client tunnels are chosen randomly from the smallest group, which is the "fast" group.
+There is no bias toward selecting peers that were previously participants in a tunnel for the same client.
+{%- endtrans %}
    
+
+
+
    {% trans %}Peer Selection for Exploratory Tunnels{% endtrans %}
    
+
    {% trans -%}
+Exploratory tunnels are used for router administrative purposes, such as network database traffic
+and testing client tunnels.
+Exploratory tunnels are also used to contact previously unconnected routers, which is why
+they are called "exploratory".
+These tunnels are usually low-bandwidth.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Peers for building exploratory tunnels are generally chosen randomly from the standard group.
+If the success rate of these build attempts is low compared to the client tunnel build success rate,
+the router will select a weighted average of peers randomly from the high capacity group instead.
+This helps maintain a satisfactory build success rate even when network performance is poor.
+There is no bias toward selecting peers that were previously participants in an exploratory tunnel.
+{%- endtrans %}
    
+
+
    {% trans -%}
+As the standard group includes a very large subset of all peers the router knows about,
+exploratory tunnels are essentially built through a random selection of all peers,
+until the build success rate becomes too low.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Restrictions{% endtrans %}
    
+
    {% trans -%}
+To prevent some simple attacks, and for performance, there are the following restrictions:
+{%- endtrans %}
    
+
      
+
    • {% trans -%}
+Two peers from the same /16 IP space may not be in the same tunnel.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+A peer may participate in a maximum of 33% of all tunnels created by the router.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Peers with extremely low bandwidth are not used.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Peers for which a recent connection attempt failed are not used.
+{%- endtrans %}
      • 
+
    
+
+
+
+
    {% trans %}Peer Ordering in Tunnels{% endtrans %}
    
+
    {% trans pdf='http://forensics.umass.edu/pubs/wright-tissec.pdf',
+pdf2008='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf',
+tunnelimpl=site_url('docs/tunnels/implementation') -%}
+Peers are ordered within tunnels to
+to deal with the predecessor attack
+(2008 update).
+More information is on the tunnel page.
+{%- endtrans %}
    
+
+
+
+
+
    {% trans %}Future Work{% endtrans %}
    
+
+
      
+
    • {% trans -%}
+Continue to analyze an tune speed and capacity calculations as necessary
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Implement a more aggressive ejection strategy if necessary to control memory usage as the network grows
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Evaluate group size limits
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Use GeoIP data to include or exclude certain peers, if configured
+{%- endtrans %}
      • 
+
    
+
+
    {% trans %}Notes{% endtrans %}
    
+
    {% trans pdf=url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') -%}
+For those reading the paper
+Peer Profiling and Selection in the I2P Anonymous Network,
+please keep in mind the following minor changes in I2P since the paper's publication:
+{%- endtrans %}
    
+
      
+
    • {% trans %}The Integration calculation is still not used{% endtrans %}
      • 
+
    • {% trans %}In the paper, "groups" are called "tiers"{% endtrans %}
      • 
+
    • {% trans %}The "Failing" tier is no longer used{% endtrans %}
      • 
+
    • {% trans %}The "Not Failing" tier is now named "Standard"{% endtrans %}
      • 
+
    
+
+
+
    {% trans %}References{% endtrans %}
    
+
+
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/how/tech-intro.html b/i2p2www/pages/site/docs/how/tech-intro.html
new file mode 100644
index 00000000..aa7fdc9e
--- /dev/null
+++ b/i2p2www/pages/site/docs/how/tech-intro.html
@@ -0,0 +1,1070 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Introducing I2P{% endtrans %}{% endblock %}
+{% block content %}
+
+
    {% trans %}I2P: A scalable framework for anonymous communication{% endtrans %}
    
+   
+
+  
    
+  
    {% trans %}Introduction{% endtrans %}
    
+  
    {% trans -%}
+I2P is a scalable, self organizing, resilient packet switched anonymous 
+network layer, upon which any number of different anonymity or security conscious 
+applications can operate. Each of these applications may make their own anonymity, 
+latency, and throughput tradeoffs without worrying about the proper implementation 
+of a free route mixnet, allowing them to blend their activity with the larger 
+anonymity set of users already running on top of I2P.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Applications available already provide the full range of typical Internet activities -
+anonymous web browsing, web hosting, chat, file sharing, e-mail,
+blogging and content syndication, newsgroups, as well as several other applications under development.
+{%- endtrans %}
    
+    
      
+      
    • {% trans %}Web browsing: using any existing browser that supports using a proxy.{% endtrans %}
      • 
+      
    • {% trans %}Chat: IRC, Jabber, I2P-Messenger.{% endtrans %}
      • 
+      
    • {% trans -%}
+File sharing: I2PSnark, Robert, iMule, 
+I2Phex, PyBit, I2P-bt
+and others.
+{%- endtrans %}
      • 
+      
    • {% trans %}E-mail: susimail and I2P-Bote.{% endtrans %}
      • 
+      
    • {% trans %}Blog: using e.g. the pebble plugin or the distributed blogging software Syndie.{% endtrans %}
      • 
+      
    • {% trans %}Distributed Data Store: Save your data redundantly in the Tahoe-LAFS cloud over I2P.{% endtrans %}
      • 
+      
    • {% trans %}Newsgroups: using any newsgroup reader that supports using a proxy.{% endtrans %}
      • 
+    
    
+
+  
    {% trans -%}
+Unlike web sites hosted within content distribution networks like Freenet 
+or GNUnet, the services hosted on 
+I2P are fully interactive - there are traditional web-style search engines, 
+bulletin boards, blogs you can comment on, database driven sites, and bridges 
+to query static systems like Freenet without needing to install it locally. 
+{%- endtrans %}
    
+
+  
    {% trans -%}
+With all of these anonymity enabled applications, I2P takes on the role 
+of the message oriented middleware - applications say that they want to send 
+some data to a cryptographic identifier (a "destination") and I2P takes care 
+of making sure it gets there securely and anonymously. I2P also bundles a 
+simple streaming library to allow I2P's anonymous 
+best-effort messages to transfer as reliable, in-order streams, transparently 
+offering a TCP based congestion control algorithm tuned for the high bandwidth 
+delay product of the network. While there have been several simple SOCKS proxies 
+available to tie existing applications into the network, their value has been 
+limited as nearly every application routinely exposes what, in an anonymous 
+context, is sensitive information. The only safe way to go is to fully audit 
+an application to ensure proper operation and to assist in that we provide 
+a series of APIs in various languages which can be used to make the most out 
+of the network.
+{%- endtrans %}
    
+
+  
    {% trans site=site_url(), halloffame=site_url('about/hall-of-fame') -%}
+I2P is not a research project - academic, commercial, or governmental, but 
+is instead an engineering effort aimed at doing whatever is necessary to provide 
+a sufficient level of anonymity to those who need it. It has been in active 
+development since early 2003 with one full time developer and a dedicated 
+group of part time contributors from all over the world. All of the work done 
+on I2P is open source and freely available on the website, 
+with the majority of the code released outright into the public domain, though 
+making use of a few cryptographic routines under BSD-style licenses. The people 
+working on I2P do not control what people release client applications under, 
+and there are several GPL'ed applications available (I2PTunnel, 
+susimail, I2PSnark, I2P-Bote, 
+I2Phex and others.).
+Funding for I2P comes entirely from donations,
+and does not receive any tax breaks in any jurisdiction at this time,
+as many of the developers are themselves anonymous.
+{%- endtrans %}
    
+
+  
    {% trans %}Operation{% endtrans %}
    
+  
    {% trans %}Overview{% endtrans %}
    
+  
    {% trans -%}
+To understand I2P's operation, it is essential to understand a few key concepts. 
+First, I2P makes a strict separation between the software participating in 
+the network (a "router") and the anonymous endpoints ("destinations") associated 
+with individual applications. The fact that someone is running I2P is not 
+usually a secret. What is hidden is information on what the user is doing, 
+if anything at all, as well as what router a particular destination is connected 
+to. End users will typically have several local destinations on their router 
+- for instance, one proxying in to IRC servers, another supporting the user's 
+anonymous webserver ("eepsite"), another for an I2Phex instance, another for 
+torrents, etc.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Another critical concept to understand is the "tunnel".
+A tunnel is a directed path through an explicitly selected list of routers.
+Layered encryption is used, so each of the routers can only decrypt a single layer.
+The decrypted information contains the IP of the next router, along with
+the encrypted information to be forwarded.
+Each tunnel has a starting point (the first router, also known as "gateway")
+and an end point. Messages can be sent only in one way. To send messages back,
+another tunnel is required.
+{%- endtrans %}
    
+    
    
+      {{ _('Inbound and outbound tunnel schematic') }}
+      

    
+      {% trans %}Figure 1: Two types of tunnels exist: inbound and outbound.{% endtrans %}
+    
    
+
+  
    {% trans -%}
+Two types of tunnels exist:
+"outbound" tunnels send messages away from the tunnel creator,
+while "inbound" tunnels bring messages to the tunnel creator.
+Combining these two tunnels allows users to send messages to each other.
+The sender ("Alice" in the above image) sets up an outbound tunnel,
+while the receiver ("Bob" in the above image) creates an inbound tunnel.
+The gateway of an inbound tunnel can receive messages from any other user
+and will send them on until the endpoint ("Bob").
+The endpoint of the outbound tunnel will need to send the message
+on to the gateway of the inbound tunnel.
+To do this, the sender ("Alice") adds instructions to her encrypted message.
+Once the endpoint of the outbound tunnel decrypts the message,
+it will have instructions to forward the message to the correct
+inbound gateway (the gateway to "Bob").
+{%- endtrans %}
    
+
+  
    {% trans -%}
+A third critical concept to understand is I2P's "network database" (or "netDb") 
+- a pair of algorithms used to share network metadata. The two types of metadata 
+carried are "routerInfo" and "leaseSets" - the routerInfo gives routers the 
+data necessary for contacting a particular router (their public keys, transport 
+addresses, etc), while the leaseSet gives routers the information necessary 
+for contacting a particular destination. A leaseSet contains a number of "leases".
+Each of this leases specifies a tunnel gateway, which allows reaching a specific destination.
+The full information contained in a lease:
+{%- endtrans %}
    
+    
      
+      
    • {% trans %}Inbound gateway for a tunnel that allows reaching a specific destination.{% endtrans %}
      • 
+      
    • {% trans %}Time when a tunnel expires.{% endtrans %}
      • 
+      
    • {% trans %}Pair of public keys to be able to encrypt messages (to send through the tunnel and reach the destination).{% endtrans %}
      • 
+    
    
+  
    {% trans -%}
+Routers themselves send their routerInfo to the netDb directly, while leaseSets are sent through outbound tunnels
+(leaseSets need to be sent anonymously, to avoid correlating a router with his leaseSets).
+{%- endtrans %}
    
+
+  
    {% trans -%}
+We can combine the above concepts to build successful connections in the network.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+To build up her own inbound and outbound tunnels, Alice does a lookup in the netDb to collect routerInfo.
+This way, she gathers lists of peers she can use as hops in her tunnels.
+She can then send a build message to the first hop, requesting the construction of a tunnel and asking
+that router to send the construction message onward, until the tunnel has been constructed.
+{%- endtrans %}
    
+    
    
+      {{ _('Request information on other routers') }}
+                         
+      {{ _('Build tunnel using router information') }}
+      

    
+      {% trans %}Figure 2: Router information is used to build tunnels.{% endtrans %}
+    
    
+  
    
+  
    {% trans -%}
+When Alice wants to send a message to Bob, she first does a lookup in the 
+netDb to find Bob's leaseSet, giving her his current inbound tunnel gateways. 
+She then picks one of her outbound tunnels and sends the message down it with 
+instructions for the outbound tunnel's endpoint to forward the message on 
+to one of Bob's inbound tunnel gateways. When the outbound tunnel endpoint 
+receives those instructions, it forwards the message as requested, and when 
+Bob's inbound tunnel gateway receives it, it is forwarded down the tunnel 
+to Bob's router. If Alice wants Bob to be able to reply to the message, she 
+needs to transmit her own destination explicitly as part of the message itself.
+This can be done by introducing a higher-level layer, which is done in the
+streaming library.
+Alice may also cut down on the response time by bundling her most 
+recent LeaseSet with the message so that Bob doesn't need to do a netDb lookup 
+for it when he wants to reply, but this is optional.
+{%- endtrans %}
    
+    
    
+      {{ _('Connect tunnels using LeaseSets') }}
+      

    
+      {% trans %}Figure 3: LeaseSets are used to connect outbound and inbound tunnels.{% endtrans %}
+    
    
+  
    
+  
    {% trans -%}
+While the tunnels themselves have layered encryption to prevent unauthorized 
+disclosure to peers inside the network (as the transport layer itself does 
+to prevent unauthorized disclosure to peers outside the network), it is necessary 
+to add an additional end to end layer of encryption to hide the message from 
+the outbound tunnel endpoint and the inbound tunnel gateway. This "garlic 
+encryption" lets Alice's router wrap up multiple messages into a single 
+"garlic message", encrypted to a particular public key so that intermediary 
+peers cannot determine either how many messages are within the garlic, what 
+those messages say, or where those individual cloves are destined. For typical 
+end to end communication between Alice and Bob, the garlic will be encrypted 
+to the public key published in Bob's leaseSet, allowing the message to be 
+encrypted without giving out the public key to Bob's own router.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Another important fact to keep in mind is that I2P is entirely message based 
+and that some messages may be lost along the way. Applications using I2P can 
+use the message oriented interfaces and take care of their own congestion 
+control and reliability needs, but most would be best served by reusing the 
+provided streaming library to view I2P as a streams 
+based network.
+{%- endtrans %}
    
+
+  
    {% trans %}Tunnels{% endtrans %}
    
+  
    {% trans -%}
+Both inbound and outbound tunnels work along similar principles.
+The tunnel gateway accumulates a number of tunnel messages, eventually preprocessing 
+them into something for tunnel delivery. Next, the gateway encrypts that preprocessed 
+data and forwards it to the first hop. That peer and subsequent tunnel participants 
+add on a layer of encryption after verifying that it isn't a duplicate before 
+forward it on to the next peer. Eventually, the message arrives at the endpoint 
+where the messages are split out again and forwarded on as requested. The 
+difference arises in what the tunnel's creator does - for inbound tunnels, 
+the creator is the endpoint and they simply decrypt all of the layers added, 
+while for outbound tunnels, the creator is the gateway and they pre-decrypt 
+all of the layers so that after all of the layers of per-hop encryption are 
+added, the message arrives in the clear at the tunnel endpoint.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+The choice of specific peers to pass on messages as well as their particular 
+ordering is important to understanding both I2P's anonymity and performance 
+characteristics. While the network database (below) has its own criteria for 
+picking what peers to query and store entries on, tunnel creators may use any peers 
+in the network in any order (and even any number of times) in a single tunnel. 
+If perfect latency and capacity data were globally known, selection and ordering 
+would be driven by the particular needs of the client in tandem with their 
+threat model. Unfortunately, latency and capacity data is not trivial to gather 
+anonymously, and depending upon untrusted peers to provide this information 
+has its own serious anonymity implications.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+From an anonymity perspective, the simplest technique would be to pick peers 
+randomly from the entire network, order them randomly and use those peers 
+in that order for all eternity. From a performance perspective, the simplest 
+technique would be to pick the fastest peers with the necessary spare capacity, 
+spreading the load across different peers to handle transparent failover, 
+and to rebuild the tunnel whenever capacity information changes. While the 
+former is both brittle and inefficient, the later requires inaccessible information 
+and offers insufficient anonymity. I2P is instead working on offering a range 
+of peer selection strategies, coupled with anonymity aware measurement code 
+to organize the peers by their profiles.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+As a base, I2P is constantly profiling the peers with which it interacts 
+with by measuring their indirect behavior - for instance, when a peer responds 
+to a netDb lookup in 1.3 seconds, that round trip latency is recorded in the 
+profiles for all of the routers involved in the two tunnels (inbound and outbound) 
+through which the request and response passed, as well as the queried peer's 
+profile. Direct measurement, such as transport layer latency or congestion, 
+is not used as part of the profile, as it can be manipulated and associated 
+with the measuring router, exposing them to trivial attacks. While gathering 
+these profiles, a series of calculations are run on each to summarize its 
+performance - its latency, capacity to handle lots of activity, whether they 
+are currently overloaded, and how well integrated into the network they seem 
+to be. These calculations are then compared for active peers to organize the 
+routers into four tiers - fast and high capacity, high capacity, not failing, 
+and failing. The thresholds for those tiers are determined dynamically, and 
+while they currently use fairly simple algorithms, alternatives exist.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Using this profile data, the simplest reasonable peer selection strategy 
+is to pick peers randomly from the top tier (fast and high capacity), and 
+this is currently deployed for client tunnels. Exploratory tunnels (used for 
+netDb and tunnel management) pick peers randomly from the "not failing" tier 
+(which includes routers in 'better' tiers as well), allowing the peer to sample 
+routers more widely, in effect optimizing the peer selection through randomized 
+hill climbing. These strategies alone do however leak information regarding 
+the peers in the router's top tier through predecessor and netDb harvesting 
+attacks. In turn, several alternatives exist which, while not balancing the 
+load as evenly, will address the attacks mounted by particular classes of 
+adversaries.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+By picking a random key and ordering the peers according to their XOR distance 
+from it, the information leaked is reduced in predecessor and harvesting attacks 
+according to the peers' failure rate and the tier's churn. Another simple 
+strategy for dealing with netDb harvesting attacks is to simply fix the inbound 
+tunnel gateway(s) yet randomize the peers further on in the tunnels. To deal 
+with predecessor attacks for adversaries which the client contacts, the outbound 
+tunnel endpoints would also remain fixed. The selection of which peer to fix 
+on the most exposed point would of course need to have a limit to the duration, 
+as all peers fail eventually, so it could either be reactively adjusted or 
+proactively avoided to mimic a measured mean time between failures of other 
+routers. These two strategies can in turn be combined, using a fixed exposed 
+peer and an XOR based ordering within the tunnels themselves. A more rigid 
+strategy would fix the exact peers and ordering of a potential tunnel, only 
+using individual peers if all of them agree to participate in the same way 
+each time. This varies from the XOR based ordering in that the predecessor 
+and successor of each peer is always the same, while the XOR only makes sure 
+their order doesn't change.
+{%- endtrans %}
    
+
+  
    {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
+As mentioned before, I2P currently (release 0.8) includes the tiered 
+random strategy above, with XOR-based ordering. A 
+more detailed discussion of the mechanics involved in tunnel operation, management, 
+and peer selection can be found in the tunnel spec. 
+{%- endtrans %}
    
+
+  
    {% trans %}Network Database{% endtrans %}
    
+  
    {% trans netdb=site_url('docs/how/network-database') -%}
+As mentioned earlier, I2P's netDb works to share the network's metadata.
+This is detailed in the network database page,
+but a basic explanation is available below.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+A percentage of I2P users are appointed as 'floodfill peers'.
+Currently, I2P installations that have a lot of bandwidth and are fast enough,
+will appoint themselves as floodfill as soon as the number of existing floodfill routers
+drops too low.
+{%- endtrans %}
    
+
+  
    {% trans netdb=site_url('docs/how/network-database') -%}
+Other I2P routers will store their data and lookup data by sending simple 'store' and 'lookup' queries to the floodfills.
+If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers
+using the Kademlia algorithm.
+The 'lookup' queries currently function differently, to avoid an important
+security issue.
+When a lookup is done, the floodfill router will not forward the lookup to other peers,
+but will always answer by itself (if it has the requested data).
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Two types of information are stored in the network database.
+{%- endtrans %}
    
+    
      
+        
    • {% trans %}A RouterInfo stores information on a specific I2P router and how to contact it{% endtrans %}
      • 
+        
    • {% trans %}A LeaseSet stores information on a specific destination (e.g. I2P website, e-mail server...){% endtrans %}
      • 
+    
    
+  
    {% trans -%}
+All of this information is signed by the publishing party and verified by any I2P router using or storing the information.
+In addition, the data contains timing information, to avoid storage of old entries and possible attacks.
+This is also why I2P bundles the necessary code for maintaining the correct time, occasionally querying some SNTP servers 
+(the pool.ntp.org round robin by default)
+and detecting skew between routers at the transport layer.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Some additional remarks are also important.
+{%- endtrans %}
    
+    
      
+      
    • 
+        {% trans %}Unpublished and encrypted leasesets:{% endtrans %}
+        
      {% trans -%}
+One could only want specific people to be able to reach a destination.
+This is possible by not publishing the destination in the netDb. You will however have to transmit the destination by other means.
+An alternative are the 'encrypted leaseSets'. These leaseSets can only be decoded by people with access to the decryption key.
+{%- endtrans %}
      
+      
      • 
+      
    • 
+        {% trans %}Bootstrapping:{% endtrans %}
+        
      {% trans -%}
+Bootstrapping the netDb is quite simple. Once a router manages to receive a single routerInfo of a reachable peer,
+it can query that router for references to other routers in the network.
+Currently, a number of users post their routerInfo files to a website to make this information available.
+I2P automatically connects to one of these websites to gather routerInfo files and bootstrap.
+{%- endtrans %}
      
+      
      • 
+      
    • 
+        {% trans %}Lookup scalability:{% endtrans %}
+        
      {% trans -%}
+Lookups in the I2P network are not forwarded to other netDb routers.
+Currently, this is not a major problem, since the network is not very large.
+However, as the network grows, not all routerInfo and leaseSet files will be present
+on each netDb router. This will cause a deterioration of the percentage of successful lookups.
+Because of this, refinements to the netDb will be done in the next releases.
+{%- endtrans %}
      
+      
      • 
+    
    
+
+  
    {% trans %}Transport protocols{% endtrans %}
    
+  
    {% trans -%}
+Communication between routers needs to provide confidentiality and integrity 
+against external adversaries while authenticating that the router contacted 
+is the one who should receive a given message. The particulars of how routers 
+communicate with other routers aren't critical - three separate protocols 
+have been used at different points to provide those bare necessities.
+{%- endtrans %}
    
+
+  
    {% trans ssu=site_url('docs/transport/ssu') -%}
+I2P started with a TCP-based protocol which 
+has since been disabled. Then, to accommodate the need for high degree communication 
+(as a number of routers will end up speaking with many others), I2P moved 
+from a TCP based transport to a UDP-based one - "Secure 
+Semireliable UDP", or "SSU".
+{%- endtrans %}
    
+
+  
    {% trans ssu=site_url('docs/transport/ssu') -%}
+As described in the SSU spec:
+{%- endtrans %}
    
+
+  
    {% trans -%}
+The goal of this protocol is to provide secure, authenticated, 
+semireliable and unordered message delivery, exposing only a minimal amount 
+of data easily discernible to third parties. It should support high degree 
+communication as well as TCP-friendly congestion control and may include 
+PMTU detection. It should be capable of efficiently moving bulk data at rates 
+sufficient for home users. In addition, it should support techniques for addressing 
+network obstacles, like most NATs or firewalls.
+{%- endtrans %}
    
+
+  
    {% trans ntcp=site_url('docs/transport/ntcp') -%}
+Following the introduction of SSU, after issues with congestion collapse 
+appeared, a new NIO-based TCP transport called NTCP 
+was implemented. It is enabled by default for outbound connections only. Those 
+who configure their NAT/firewall to allow inbound connections and specify 
+the external host and port (dyndns/etc is ok) on /config.jsp can receive inbound 
+connections. As NTCP is NIO based, so it doesn't suffer from the 1 thread 
+per connection issues of the old TCP transport.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+I2P supports multiple transports simultaneously. A particular transport 
+for an outbound connection is selected with "bids". Each transport bids for 
+the connection and the relative value of these bids assigns the priority. 
+Transports may reply with different bids, depending on whether there is already 
+an established connection to the peer.
+{%- endtrans %}
    
+
+  
    {% trans ntcp=site_url('docs/transport/ntcp') -%}
+The current implementation ranks NTCP as the highest-priority transport 
+for outbound connections in most situations. SSU is enabled for both outbound 
+and inbound connections. Your firewall and your I2P router must be configured 
+to allow inbound NTCP connections. For further information see the NTCP 
+page.
+{%- endtrans %}
    
+
+  
    {% trans %}Cryptography{% endtrans %}
    
+  
    {% trans -%}
+A bare minimum set of cryptographic primitives are combined together to 
+provide I2P's layered defenses against a variety of adversaries. At the lowest 
+level, inter router communication is protected by the transport layer security 
+- SSU encrypts each packet with AES256/CBC with both an explicit IV and MAC 
+(HMAC-MD5-128) after agreeing upon an ephemeral session key through a 2048bit 
+Diffie-Hellman exchange, station-to-station authentication with the other 
+router's DSA key, plus each network message has their own hash for local integrity 
+checking. Tunnel messages passed over the transports 
+have their own layered AES256/CBC encryption with an explicit IV and verified 
+at the tunnel endpoint with an additional SHA256 hash. Various other messages 
+are passed along inside "garlic messages", which are encrypted with ElGamal/AES+SessionTags 
+(explained below).
+{%- endtrans %}
    
+
+  
    {% trans %}Garlic messages{% endtrans %}
    
+  
    {% trans -%}
+Garlic messages are an extension of "onion" layered encryption, allowing 
+the contents of a single message to contain multiple "cloves" - fully formed 
+messages alongside their own instructions for delivery. Messages are wrapped 
+into a garlic message whenever the message would otherwise be passing in cleartext 
+through a peer who should not have access to the information - for instance, 
+when a router wants to ask another router to participate in a tunnel, they 
+wrap the request inside a garlic, encrypt that garlic to the receiving router's 
+2048bit ElGamal public key, and forward it through a tunnel. Another example 
+is when a client wants to send a message to a destination - the sender's router 
+will wrap up that data message (alongside some other messages) into a garlic, 
+encrypt that garlic to the 2048bit ElGamal public key published in the recipient's 
+leaseSet, and forward it through the appropriate tunnels.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+The "instructions" attached to each clove inside the encryption layer includes 
+the ability to request that the clove be forwarded locally, to a remote router, 
+or to a remote tunnel on a remote router. There are fields in those instructions 
+allowing a peer to request that the delivery be delayed until a certain time 
+or condition has been met, though they won't be honored until the nontrivial 
+delays are deployed. It is possible to explicitly route garlic messages 
+any number of hops without building tunnels, or even to reroute tunnel messages 
+by wrapping them in garlic messages and forwarding them a number of hops prior 
+to delivering them to the next hop in the tunnel, but those techniques are 
+not currently used in the existing implementation.
+{%- endtrans %}
    
+
+  
    {% trans %}Session tags{% endtrans %}
    
+  
    {% trans -%}
+As an unreliable, unordered, message based system, I2P uses a simple combination 
+of asymmetric and symmetric encryption algorithms to provide data confidentiality 
+and integrity to garlic messages. As a whole, the combination is referred 
+to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe 
+the simple use of 2048bit ElGamal, AES256, SHA256 and 32 byte nonces.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+The first time a router wants to encrypt a garlic message to another router, 
+they encrypt the keying material for an AES256 session key with ElGamal and 
+append the AES256/CBC encrypted payload after that encrypted ElGamal block. 
+In addition to the encrypted payload, the AES encrypted section contains the 
+payload length, the SHA256 hash of the unencrypted payload, as well as a number 
+of "session tags" - random 32 byte nonces. The next time the sender wants 
+to encrypt a garlic message to another router, rather than ElGamal encrypt 
+a new session key they simply pick one of the previously delivered session 
+tags and AES encrypt the payload like before, using the session key used with 
+that session tag, prepended with the session tag itself. When a router receives 
+a garlic encrypted message, they check the first 32 bytes to see if it matches 
+an available session tag - if it does, they simply AES decrypt the message, 
+but if it does not, they ElGamal decrypt the first block.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Each session tag can be used only once so as to prevent internal adversaries 
+from unnecessarily correlating different messages as being between the same 
+routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses 
+when and how many tags to deliver, prestocking the recipient with enough tags 
+to cover a volley of messages. Garlic messages may detect the successful tag 
+delivery by bundling a small additional message as a clove (a "delivery status 
+message") - when the garlic message arrives at the intended recipient and 
+is decrypted successfully, this small delivery status message is one of the 
+cloves exposed and has instructions for the recipient to send the clove back 
+to the original sender (through an inbound tunnel, of course). When the original 
+sender receives this delivery status message, they know that the session tags 
+bundled in the garlic message were successfully delivered.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Session tags themselves have a very short lifetime, after which they are 
+discarded if not used. In addition, the quantity stored for each key is limited, 
+as are the number of keys themselves - if too many arrive, either new or old 
+messages may be dropped. The sender keeps track whether messages using session 
+tags are getting through, and if there isn't sufficient communication it may 
+drop the ones previously assumed to be properly delivered, reverting back 
+to the full expensive ElGamal encryption.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+One alternative is to transmit only a single session tag, and from that, 
+seed a deterministic PRNG for determining what tags to use or expect. By keeping 
+this PRNG roughly synchronized between the sender and recipient (the recipient 
+precomputes a window of the next e.g. 50 tags), the overhead of periodically 
+bundling a large number of tags is removed, allowing more options in the space/time 
+tradeoff, and perhaps reducing the number of ElGamal encryptions necessary. 
+However, it would depend upon the strength of the PRNG to provide the necessary 
+cover against internal adversaries, though perhaps by limiting the amount 
+of times each PRNG is used, any weaknesses can be minimized. At the moment, 
+there are no immediate plans to move towards these synchronized PRNGs.
+{%- endtrans %}
    
+
+  
    {% trans %}Future{% endtrans %}
    
+  
    {% trans -%}
+While I2P is currently functional and sufficient for many scenarios, there 
+are several areas which require further improvement to meet the needs of those 
+facing more powerful adversaries as well as substantial user experience optimization. 
+{%- endtrans %}
    
+
+  
    {% trans %}Restricted route operation{% endtrans %}
    
+  
    {% trans -%}
+I2P is an overlay network designed to be run on top of a functional packet 
+switched network, exploiting the end to end principle to offer anonymity and 
+security. While the Internet no longer fully embraces the end to end principle
+(due to the usage of NAT), 
+I2P does require a substantial portion of the network to be reachable - there 
+may be a number of peers along the edges running using restricted routes, 
+but I2P does not include an appropriate routing algorithm for the degenerate 
+case where most peers are unreachable. It would, however work on top of a 
+network employing such an algorithm.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Restricted route operation, where there are limits to what peers are reachable 
+directly, has several different functional and anonymity implications, dependent 
+upon how the restricted routes are handled. At the most basic level, restricted 
+routes exist when a peer is behind a NAT or firewall which does not allow 
+inbound connections. This was largely addressed in I2P 0.6.0.6 by integrating 
+distributed hole punching into the transport layer, allowing people behind 
+most NATs and firewalls to receive unsolicited connections without any configuration. 
+However, this does not limit the exposure of the peer's IP address to routers 
+inside the network, as they can simply get introduced to the peer through 
+the published introducer.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Beyond the functional handling of restricted routes, there are two levels 
+of restricted operation that can be used to limit the exposure of one's IP 
+address - using router-specific tunnels for communication, and offering 'client 
+routers'. For the former, routers can either build a new pool of tunnels or 
+reuse their exploratory pool, publishing the inbound gateways to some of them 
+as part of their routerInfo in place of their transport addresses. When a 
+peer wants to get in touch with them, they see those tunnel gateways in the 
+netDb and simply send the relevant message to them through one of the published 
+tunnels. If the peer behind the restricted route wants to reply, it may do 
+so either directly (if they are willing to expose their IP to the peer) or 
+indirectly through their outbound tunnels. When the routers that the peer 
+has direct connections to want to reach it (to forward tunnel messages, for 
+instance), they simply prioritize their direct connection over the published 
+tunnel gateway. The concept of 'client routers' simply extends the restricted 
+route by not publishing any router addresses. Such a router would not even 
+need to publish their routerInfo in the netDb, merely providing their self 
+signed routerInfo to the peers that it contacts (necessary to pass the router's 
+public keys). Both levels of restricted route operation are planned for I2P 
+2.0.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+There are tradeoffs for those behind restricted routes, as they would likely 
+participate in other people's tunnels less frequently, and the routers which 
+they are connected to would be able to infer traffic patterns that would not 
+otherwise be exposed. On the other hand, if the cost of that exposure is less 
+than the cost of an IP being made available, it may be worthwhile. This, of 
+course, assumes that the peers that the router behind a restricted route contacts 
+are not hostile - either the network is large enough that the probability 
+of using a hostile peer to get connected is small enough, or trusted (and 
+perhaps temporary) peers are used instead.
+{%- endtrans %}
    
+
+  
    {% trans %}Variable latency{% endtrans %}
    
+  
    {% trans -%}
+Even though the bulk of I2P's initial efforts have been on low latency communication, 
+it was designed with variable latency services in mind from the beginning. 
+At the most basic level, applications running on top of I2P can offer the 
+anonymity of medium and high latency communication while still blending their 
+traffic patterns in with low latency traffic. Internally though, I2P can offer 
+its own medium and high latency communication through the garlic encryption 
+- specifying that the message should be sent after a certain delay, at a certain 
+time, after a certain number of messages have passed, or another mix strategy. 
+With the layered encryption, only the router that the clove exposed the delay 
+request would know that the message requires high latency, allowing the traffic 
+to blend in further with the low latency traffic. Once the transmission precondition 
+is met, the router holding on to the clove (which itself would likely be a 
+garlic message) simply forwards it as requested - to a router, to a tunnel, 
+or, most likely, to a remote client destination.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+There are a substantial number of ways to exploit this capacity for high 
+latency comm in I2P, but for the moment, doing so has been scheduled for the 
+I2P 3.0 release. In the meantime, those requiring the anonymity that high 
+latency comm can offer should look towards the application layer to provide 
+it.
+{%- endtrans %}
    
+
+  
    {% trans %}Open questions{% endtrans %}
    
+  
      
+    
    • {% trans %}How to get rid of the timing constraint?{% endtrans %}
      • 
+    
    • {% trans %}Can we deal with the sessionTags more efficiently?{% endtrans %}
      • 
+    
    • {% trans %}What, if any, batching/mixing strategies should be made available on the tunnels?{% endtrans %}
      • 
+    
    • {% trans %}What other tunnel peer selection and ordering strategies should be available?{% endtrans %}
      • 
+  
    
+
+  
    {% trans %}Similar systems{% endtrans %}
    
+
+  
    {% trans -%}
+I2P's architecture builds on the concepts of message oriented middleware, 
+the topology of DHTs, the anonymity and cryptography of free route mixnets, 
+and the adaptability of packet switched networking. The value comes not from 
+novel concepts of algorithms though, but from careful engineering combining 
+the research results of existing systems and papers. While there are a few 
+similar efforts worth reviewing, both for technical and functional comparisons, 
+two in particular are pulled out here - Tor and Freenet.
+{%- endtrans %}
    
+
+  
    {% trans comparisons=site_url('comparison') -%}
+See also the Network Comparisons Page. 
+{%- endtrans %}
    
+
+  
    Tor
    
+  
    {% trans %}website{% endtrans %}
    
+
+  
    {% trans -%}
+At first glance, Tor and I2P have many functional and anonymity related 
+similarities. While I2P's development began before we were aware of the early 
+stage efforts on Tor, many of the lessons of the original onion routing and 
+ZKS efforts were integrated into I2P's design. Rather than building an essentially 
+trusted, centralized system with directory servers, I2P has a self organizing 
+network database with each peer taking on the responsibility of profiling 
+other routers to determine how best to exploit available resources. Another 
+key difference is that while both I2P and Tor use layered and ordered paths 
+(tunnels and circuits/streams), I2P is fundamentally a packet switched network, 
+while Tor is fundamentally a circuit switched one, allowing I2P to transparently 
+route around congestion or other network failures, operate redundant pathways, 
+and load balance the data across available resources. While Tor offers the 
+useful outproxy functionality by offering integrated outproxy discovery and 
+selection, I2P leaves such application layer decisions up to applications 
+running on top of I2P - in fact, I2P has even externalized the TCP-like streaming 
+library itself to the application layer, allowing developers to experiment 
+with different strategies, exploiting their domain specific knowledge to offer 
+better performance.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+From an anonymity perspective, there is much similarity when the core networks 
+are compared. However, there are a few key differences. When dealing with 
+an internal adversary or most external adversaries, I2P's simplex tunnels 
+expose half as much traffic data than would be exposed with Tor's duplex circuits 
+by simply looking at the flows themselves - an HTTP request and response would 
+follow the same path in Tor, while in I2P the packets making up the request 
+would go out through one or more outbound tunnels and the packets making up 
+the response would come back through one or more different inbound tunnels. 
+While I2P's peer selection and ordering strategies should sufficiently address 
+predecessor attacks, should a switch to bidirectional tunnels be necessary,
+we could simply build an inbound and outbound tunnel along the same routers.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Another anonymity issue comes up in Tor's use of telescopic tunnel creation, 
+as simple packet counting and timing measurements as the cells in a circuit 
+pass through an adversary's node exposes statistical information regarding 
+where the adversary is within the circuit. I2P's unidirectional tunnel creation 
+with a single message so that this data is not exposed. Protecting the position 
+in a tunnel is important, as an adversary would otherwise be able to mount 
+a series of powerful predecessor, intersection, and traffic confirmation attacks. 
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Tor's support for a second tier of "onion proxies" does offer a non-trivial 
+degree of anonymity while requiring a low cost of entry, while I2P will not 
+offer this topology until 2.0.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+On the whole, Tor and I2P complement each other in their focus - Tor works 
+towards offering high speed anonymous Internet outproxying, while I2P works 
+towards offering a decentralized resilient network in itself. In theory, both 
+can be used to achieve both purposes, but given limited development resources, 
+they both have their strengths and weaknesses. The I2P developers have considered 
+the steps necessary to modify Tor to take advantage of I2P's design, but concerns 
+of Tor's viability under resource scarcity suggest that I2P's packet switching 
+architecture will be able to exploit scarce resources more effectively.
+{%- endtrans %}
    
+
+  
    Freenet
    
+  
    {% trans %}website{% endtrans %}
    
+
+  
    {% trans -%}
+Freenet played a large part in the initial stages of I2P's design - giving 
+proof to the viability of a vibrant pseudonymous community completely contained 
+within the network, demonstrating that the dangers inherent in outproxies 
+could be avoided. The first seed of I2P began as a replacement communication 
+layer for Freenet, attempting to factor out the complexities of a scalable, 
+anonymous and secure point to point communication from the complexities of 
+a censorship resistant distributed data store. Over time however, some of 
+the anonymity and scalability issues inherent in Freenet's algorithms made 
+it clear that I2P's focus should stay strictly on providing a generic anonymous 
+communication layer, rather than as a component of Freenet. Over the years, 
+the Freenet developers have come to see the weaknesses in the older design, 
+prompting them to suggest that they will require a "premix" layer to offer 
+substantial anonymity. In other words, Freenet needs to run on top of a mixnet 
+such as I2P or Tor, with "client nodes" requesting and publishing data through 
+the mixnet to the "server nodes" which then fetch and store the data according 
+to Freenet's heuristic distributed data storage algorithms.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Freenet's functionality is very complementary to I2P's, as Freenet natively 
+provides many of the tools for operating medium and high latency systems, 
+while I2P natively provides the low latency mix network suitable for offering 
+adequate anonymity. The logic of separating the mixnet from the censorship-
+resistant distributed data store still seems self-evident from an engineering, 
+anonymity, security, and resource allocation perspective, so hopefully the 
+Freenet team will pursue efforts in that direction, if not simply reusing 
+(or helping to improve, as necessary) existing mixnets like I2P or Tor.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+It is worth mentioning that there has recently been discussion and work 
+by the Freenet developers on a "globally scalable darknet" using restricted 
+routes between peers of various trust. While insufficient information has 
+been made publicly available regarding how such a system would operate for 
+a full review, from what has been said the anonymity and scalability claims 
+seem highly dubious. In particular, the appropriateness for use in hostile 
+regimes against state level adversaries has been tremendously overstated, 
+and any analysis on the implications of resource scarcity upon the scalability 
+of the network has seemingly been avoided. Further questions regarding susceptibility 
+to traffic analysis, trust and other topics do exist, but a more in-depth 
+review of this "globally scalable darknet" will have to wait until the Freenet 
+team makes more information available.
+{%- endtrans %}
    
+
+  
    Appendix A: Application layer
    
+  
    {% trans -%}
+I2P itself doesn't really do much - it simply sends messages to remote destinations 
+and receives messages targeting local destinations - most of the interesting 
+work goes on at the layers above it. By itself, I2P could be seen as an anonymous 
+and secure IP layer, and the bundled streaming library 
+as an implementation of an anonymous and secure TCP layer on top of it. Beyond 
+that, I2PTunnel exposes a generic TCP proxying 
+system for either getting into or out of the I2P network, plus a variety of 
+network applications provide further functionality for end users.
+{%- endtrans %}
    
+
+  
    {% trans %}Streaming library{% endtrans %}
    
+  
    {% trans -%}
+The I2P streaming library can be viewed as a generic streaming interface (mirroring TCP sockets),
+and the implementation supports a sliding window protocol
+with several optimizations, to take into account the high delay over I2P.
+Individual streams may adjust the maximum packet size and 
+other options, though the default of 4KB compressed seems a reasonable tradeoff 
+between the bandwidth costs of retransmitting lost messages and the latency 
+of multiple messages.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+In addition, in consideration of the relatively high cost of subsequent 
+messages, the streaming library's protocol for scheduling and delivering messages 
+has been optimized to allow individual messages passed to contain as much 
+information as is available. For instance, a small HTTP transaction proxied 
+through the streaming library can be completed in a single round trip - the 
+first message bundles a SYN, FIN and the small payload (an HTTP request typically 
+fits) and the reply bundles the SYN, FIN, ACK and the small payload (many 
+HTTP responses fit). While an additional ACK must be transmitted to tell the 
+HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy can 
+deliver the full response to the browser immediately.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+On the whole, however, the streaming library bears much resemblance to an 
+abstraction of TCP, with its sliding windows, congestion control algorithms 
+(both slow start and congestion avoidance), and general packet behavior (ACK, 
+SYN, FIN, RST, etc).
+{%- endtrans %}
    
+
+  
    {% trans %}Naming library and addressbook{% endtrans %}
    
+  
    {% trans naming=site_url('docs/naming') -%}
+For more information see the Naming and Addressbook page.
+{%- endtrans %}
    
+
+  
    {% trans dev='mihi, Ragnarok' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans -%}
+Naming within I2P has been an oft-debated topic since the very beginning 
+with advocates across the spectrum of possibilities. However, given I2P's 
+inherent demand for secure communication and decentralized operation, the 
+traditional DNS-style naming system is clearly out, as are "majority rules" 
+voting systems. Instead, I2P ships with a generic naming library and a base 
+implementation designed to work off a local name to destination mapping, as 
+well as an optional add-on application called the "addressbook". The addressbook 
+is a web-of-trust-driven secure, distributed, and human readable naming system, 
+sacrificing only the call for all human readable names to be globally unique 
+by mandating only local uniqueness. While all messages in I2P are cryptographically 
+addressed by their destination, different people can have local addressbook 
+entries for "Alice" which refer to different destinations. People can still 
+discover new names by importing published addressbooks of peers specified 
+in their web of trust, by adding in the entries provided through a third party, 
+or (if some people organize a series of published addressbooks using a first 
+come first serve registration system) people can choose to treat these addressbooks 
+as name servers, emulating traditional DNS.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+I2P does not promote the use of DNS-like services though, as the damage 
+done by hijacking a site can be tremendous - and insecure destinations have 
+no value. DNSsec itself still falls back on registrars and certificate authorities, 
+while with I2P, requests sent to a destination cannot be intercepted or the 
+reply spoofed, as they are encrypted to the destination's public keys, and 
+a destination itself is just a pair of public keys and a certificate. DNS-style 
+systems on the other hand allow any of the name servers on the lookup path 
+to mount simple denial of service and spoofing attacks. Adding on a certificate 
+authenticating the responses as signed by some centralized certificate authority 
+would address many of the hostile nameserver issues but would leave open replay 
+attacks as well as hostile certificate authority attacks.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Voting style naming is dangerous as well, especially given the effectiveness 
+of Sybil attacks in anonymous systems - the attacker can simply create an 
+arbitrarily high number of peers and "vote" with each to take over a given 
+name. Proof-of-work methods can be used to make identity non-free, but as 
+the network grows the load required to contact everyone to conduct online 
+voting is implausible, or if the full network is not queried, different sets 
+of answers may be reachable.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+As with the Internet however, I2P is keeping the design and operation of 
+a naming system out of the (IP-like) communication layer. The bundled naming 
+library includes a simple service provider interface which alternate naming 
+systems can plug into, allowing end users to drive what sort of naming tradeoffs 
+they prefer.
+{%- endtrans %}
    
+
+  
    Syndie
    
+  
    {% trans -%}
+The old Syndie bundled with I2P has been replaced by the new Syndie which
+is distributed separately. For more information see the Syndie
+pages.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Syndie is a safe, anonymous blogging / content publication / content aggregation 
+system. It lets you create information, share it with others, and read posts 
+from those you're interested in, all while taking into consideration your 
+needs for security and anonymity. Rather than building its own content distribution 
+network, Syndie is designed to run on top of existing networks, syndicating 
+content through eepsites, Tor hidden services, Freenet freesites, normal websites, 
+usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie 
+is done so as to offer pseudonymous authentication to anyone reading or archiving 
+it.
+{%- endtrans %}
    
+
+  
    I2PTunnel
    
+  
    {% trans dev='mihi' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans -%}
+I2PTunnel is probably I2P's most popular and versatile client application, 
+allowing generic proxying both into and out of the I2P network. I2PTunnel 
+can be viewed as four separate proxying applications - a "client" which receives 
+inbound TCP connections and forwards them to a given I2P destination, an "httpclient" 
+(aka "eepproxy") which acts like an HTTP proxy and forwards the requests to 
+the appropriate I2P destination (after querying the naming service if necessary), 
+a "server" which receives inbound I2P streaming connections on a destination 
+and forwards them to a given TCP host+port, and an "httpserver" which extends 
+the "server" by parsing the HTTP request and responses to allow safer operation. 
+There is an additional "socksclient" application, but its use is not encouraged 
+for reasons previously mentioned.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+I2P itself is not an outproxy network - the anonymity and security concerns 
+inherent in a mix net which forwards data into and out of the mix have kept 
+I2P's design focused on providing an anonymous network which capable of meeting 
+the user's needs without requiring external resources. However, the I2PTunnel 
+"httpclient" application offers a hook for outproxying - if the hostname requested 
+doesn't end in ".i2p", it picks a random destination from a user-provided 
+set of outproxies and forwards the request to them. These destinations are 
+simply I2PTunnel "server" instances run by volunteers who have explicitly 
+chosen to run outproxies - no one is an outproxy by default, and running an 
+outproxy doesn't automatically tell other people to proxy through you. While 
+outproxies do have inherent weaknesses, they offer a simple proof of concept 
+for using I2P and provide some functionality under a threat model which may 
+be sufficient for some users.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+I2PTunnel enables most of the applications in use. An "httpserver" pointing 
+at a webserver lets anyone run their own anonymous website (or "eepsite") 
+- a webserver is bundled with I2P for this purpose, but any webserver can 
+be used. Anyone may run a "client" pointing at one of the anonymously hosted 
+IRC servers, each of which are running a "server" pointing at their local 
+IRCd and communicating between IRCds over their own "client" tunnels. End 
+users also have "client" tunnels pointing at I2Pmail's 
+POP3 and SMTP destinations (which in turn are simply "server" instances pointing 
+at POP3 and SMTP servers), as well as "client" tunnels pointing at I2P's CVS 
+server, allowing anonymous development. At times people have even run "client" 
+proxies to access the "server" instances pointing at an NNTP server.
+{%- endtrans %}
    
+
+  
    i2p-bt
    
+  
    {% trans dev='duck, et al' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans -%}
+i2p-bt is a port of the mainline python BitTorrent client to run both the 
+tracker and peer communication over I2P. Tracker requests are forwarded through 
+the eepproxy to eepsites specified in the torrent file while tracker responses 
+refer to peers by their destination explicitly, allowing i2p-bt to open up 
+a streaming lib connection to query them for 
+blocks.
+{%- endtrans %}
    
+
+  
    {% trans -%}
+In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making 
+a few modifications as necessary to strip any anonymity-compromising information 
+from the application and to take into consideration the fact that IPs cannot 
+be used for identifying peers.
+{%- endtrans %}
    
+
+  
    I2PSnark
    
+  
    {% trans -%}
+I2PSnark developed: jrandom, et al, ported from mjw's Snark client
+{%- endtrans %}
    
+
+  
    {% trans -%}
+Bundled with the I2P install, I2PSnark offers a simple anonymous BitTorrent 
+client with multitorrent capabilities, exposing all of the functionality through 
+a plain HTML web interface.
+{%- endtrans %}
    
+
+  
    Robert
    
+  
    {% trans dev='sponge' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans bob=i2pconv('bob.i2p') -%}
+Robert is a Bittorrent client written in Python.
+It is hosted on http://{{ bob }}/Robert.html 
+{%- endtrans %}
    
+
+  
    PyBit
    
+  
    {% trans dev='Blub' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans pebcache=i2pconv('pebcache.i2p') -%}
+PyBit is a Bittorrent client written in Python.
+It is hosted on http://{{ pebcache }}/ 
+{%- endtrans %}
    
+
+  
    I2Phex
    
+  
    {% trans dev='sirup' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans -%}
+I2Phex is a fairly direct port of the Phex Gnutella filesharing client to 
+run entirely on top of I2P. While it has disabled some of Phex's functionality, 
+such as integration with Gnutella webcaches, the basic file sharing and chatting 
+system is fully functional.
+{%- endtrans %}
    
+
+  
    iMule
    
+  
    {% trans dev='mkvore' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans -%}
+iMule is a fairly direct port of the aMule filesharing client 
+running entirely inside I2P.
+{%- endtrans %}
    
+
+  
    I2Pmail/susimail
    
+  
    {% trans dev='postman, susi23, mastiejaner' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans postman=i2pconv('hq.postman.i2p') -%}
+I2Pmail is more a service than an application - postman offers both internal 
+and external email with POP3 and SMTP service through I2PTunnel instances 
+accessing a series of components developed with mastiejaner, allowing people 
+to use their preferred mail clients to send and receive mail pseudonymously. 
+However, as most mail clients expose substantial identifying information, 
+I2P bundles susi23's web based susimail client which has been built specifically 
+with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers transparent 
+virus filtering as well as denial of service prevention with hashcash augmented 
+quotas. In addition, each user has control of their batching strategy prior 
+to delivery through the mail.i2p outproxies, which are separate from the mail.i2p 
+SMTP and POP3 servers - both the outproxies and inproxies communicate with 
+the mail.i2p SMTP and POP3 servers through I2P itself, so compromising those 
+non-anonymous locations does not give access to the mail accounts or activity 
+patterns of the user. At the moment the developers work on a decentralized 
+mailsystem, called "v2mail". More information can be found on the eepsite 
+{{ postman }}.
+{%- endtrans %}
    
+
+  
    I2P-Bote
    
+  
    {% trans dev='HungryHobo' -%}Developed by: {{ dev }}{%- endtrans %}
    
+
+  
    {% trans -%}
+I2P-Bote is a distributed e-mail application. It does not use the traditional
+e-mail concept of sending an e-mail to a server and retrieving it from a server.
+Instead, it uses a Kademlia Distributed Hash Table to store mails.
+One user can push a mail into the DHT, while another can request the e-mail from the DHT.
+And all the mails sent within the I2P-Bote network are automatically encrypted end-to-end. 
    
+Furthermore, I2P-Bote offers a remailer function on top of I2P, for increased high-latency anonymity.
+{%- endtrans %}
    
+
+  
    I2P-Messenger
    
+  
    {% trans -%}
+I2P-Messenger is an end-to-end encrypted serverless communication application.
+For communication between two users, they need to give each other their destination keys, to allow the other to connect.
+It supports file transfer and has a search for other users, based on Seedless.
+{%- endtrans %}
    
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/how/threat-model.html b/i2p2www/pages/site/docs/how/threat-model.html
new file mode 100644
index 00000000..33f1cd35
--- /dev/null
+++ b/i2p2www/pages/site/docs/how/threat-model.html
@@ -0,0 +1,892 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}I2P's Threat Model{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}November 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.1{% endblock %}
+{% block content %}
+
    {% trans %}What do we mean by "anonymous"?{% endtrans %}
    
+
+
    {% trans -%}
+Your level of anonymity can be described as "how hard it is for someone
+to find out information you don't want them to know?" - who you are, where
+you are located, who you communicate with, or even when you communicate.  
+"Perfect" anonymity is not a useful concept here - software will not make 
+you indistinguishable from people that don't use computers or who are not on
+the Internet.  Instead, we are working to provide sufficient anonymity to meet the
+real needs of whomever we can - from those simply browsing websites, to those exchanging
+data, to those fearful of discovery by powerful organizations or states.
+{%- endtrans %}
    
+  
+
    {% trans -%}
+The question of whether I2P provides sufficient anonymity for your 
+particular needs is a hard one, but this page will hopefully assist in 
+answering that question by exploring how I2P operates under various attacks
+so that you may decide whether it meets your needs.
+{%- endtrans %}
    
+
+
    {% trans -%}
+We welcome further research and analysis on I2P's resistance to the threats described below.
+More review of existing literature (much of it focused on Tor) and original
+work focused on I2P is needed.
+{%- endtrans %}
    
+
+
    {% trans %}Network Topology Summary{% endtrans %}
    
+
    {% trans comparisons=site_url('comparison'), links=site_url('links') -%}
+I2P builds off the ideas of many other 
+systems, but a few key points should be kept in mind when 
+reviewing related literature:
+{%- endtrans %}
    
+
      
+
    • {% trans -%}
+I2P is a free route mixnet - the message creator explicitly defines the
+path that messages will be sent out (the outbound tunnel), and the message 
+recipient explicitly defines the path that messages will be received on (the
+inbound tunnel).
+{%- endtrans %}
      • 
+
    • {% trans -%}
+I2P has no official entry and exit points - all peers fully participate in the 
+mix, and there are no network layer in- or out-proxies (however, at the 
+application layer, a few proxies do exist)
+{%- endtrans %}
      • 
+
    • {% trans -%}
+I2P is fully distributed - there are no central controls or authorities.
+One could modify some routers to operate mix cascades (building tunnels and giving
+out the keys necessary to control the forwarding at the tunnel endpoint) or directory 
+based profiling and selection, all without breaking compatibility with the rest of 
+the network, but doing so is of course not necessary (and may even harm one's
+anonymity).
+{%- endtrans %}
      • 
+
    
+
+
    {% trans todo=site_url('get-involved/todo') -%}
+We have documented plans to implement nontrivial delays
+and batching strategies 
+whose existence is only known to the particular hop or tunnel gateway that 
+receives the message, allowing a mostly low latency mixnet to provide cover 
+traffic for higher latency communication (e.g. email).
+However we are aware that significant delays are required to provide meaningful
+protection, and that implementation of such delays will be a significant challenge.
+It is not clear at this time whether we will actually implement these delay features.
+{%- endtrans %}
    
+
+
    {% trans -%}
+In theory, routers along the message path may inject an 
+arbitrary number of hops before forwarding the message to the next peer, though
+the current implementation does not.
+{%- endtrans %}
    
+
+
+
    {% trans %}The Threat Model (Attacks){% endtrans %}
    
+
    {% trans -%}
+I2P design started in 2003, not long after the advent of
+[Onion Routing],
+[Freenet], and
+[Tor].
+Our design benefits substantially from the research published around that time.
+I2P uses several onion routing techniques, so we continue to benefit
+from the significant academic interest in Tor.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Taking from the attacks and analysis put forth in the 
+anonymity literature (largely 
+Traffic Analysis: Protocols, Attacks, Design 
+Issues and Open Problems), the following briefly describes a wide variety 
+of attacks as well as many of I2Ps defenses.  We update
+this list to include new attacks as they are identified.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Included are some attacks that may be unique to I2P.
+We do not have good answers for all these attacks, however
+we continue to do research and improve our defenses.
+{%- endtrans %}
    
+
+
    {% trans -%}
+In addition, many of these attacks are significantly easier than
+they should be, due to the modest size of the current network.
+While we are aware of some limitations that need to be addressed,
+I2P is designed to support hundreds of thousands, or millions, of
+participants.
+As we continue to spread the word and grow the network,
+these attacks will become much harder.
+{%- endtrans %}
    
+
+
    {% trans comparisons=site_url('comparison'), garlicrouting=site_url('docs/how/garlic-routing') -%}
+The
+network comparisons and
+"garlic" terminology pages may also be helpful
+to review.
+{%- endtrans %}
    
+
+
    {% trans %}Index{% endtrans %}
    
+
+
+
    {% trans %}Brute force attacks{% endtrans %}
    
+
+
    {% trans -%}
+A brute force attack can be mounted by a global passive or active adversary, 
+watching all the messages pass between all of the nodes and attempting to correlate
+which message follows which path.  Mounting this attack against I2P should be 
+nontrivial, as all peers in the network are frequently sending messages (both
+end to end and network maintenance messages), plus an end to end message changes
+size and data along its path.  In addition, the external adversary does not have
+access to the messages either, as inter-router communication is both encrypted
+and streamed (making two 1024 byte messages indistinguishable from one 2048 byte
+message).
+{%- endtrans %}
    
+
+
    {% trans -%}
+However, a powerful attacker can use brute force to detect trends - if they 
+can send 5GB to an I2P destination and monitor everyone's network connection,
+they can eliminate all peers who did not receive 5GB of data.  Techniques to 
+defeat this attack exist, but may be prohibitively expensive (see: 
+Tarzan's mimics
+or constant rate traffic).  Most users are not concerned with this attack, as 
+the cost of mounting it are extreme (and often require illegal activity).  
+However, the attack is still possible, for example by an observer at
+a large ISP or an Internet exchange point.
+Those who want to defend against it 
+would want to take appropriate countermeasures, such as
+setting low bandwidth limits, and using unpublished or encrypted leasesets for eepsites.
+Other countermeasures, such as nontrivial delays and restricted routes, are
+not currently implemented.
+{%- endtrans %}
    
+
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
+As a partial defense against a single router or group of routers trying to route all the network's traffic,
+routers contain limits as to how many tunnels can be routed through a single peer.
+As the network grows, these limits are subject to further adjustment.
+Other mechanisms for peer rating, selection and avoidance
+are discussed on the
+peer selection page.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Timing attacks{% endtrans %}
    
+
+
    {% trans -%}
+I2P's messages are unidirectional and do not necessarily imply that a reply
+will be sent.  However, applications on top of I2P will most likely have
+recognizable patterns within the frequency of their messages - for instance, an 
+HTTP request will be a small message with a large sequence of reply messages 
+containing the HTTP response.  Using this data as well as a broad view of the 
+network topology, an attacker may be able to disqualify some links as being too 
+slow to have passed the message along.
+{%- endtrans %}
    
+
+
    {% trans -%}
+This sort of attack is powerful, but its applicability to I2P is non obvious,
+as the variation on message delays due to queuing, message processing, and 
+throttling will often meet or exceed the time of passing a message along a 
+single link - even when the attacker knows that a reply will be sent as soon as
+the message is received.  There are some scenarios which will expose fairly 
+automatic replies though - the streaming library does (with the SYN+ACK) as does the 
+message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).
+{%- endtrans %}
    
+
+
    {% trans todo=site_url('get-involved/todo') -%}
+Without protocol scrubbing or higher latency, global active adversaries can 
+gain substantial information.  As such, people concerned with these attacks could
+increase the latency (using nontrivial delays or 
+batching strategies), include protocol scrubbing, or
+other advanced tunnel routing techniques,
+but these are unimplemented in I2P.
+{%- endtrans %}
    
+
+
    {% trans pdf='http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf' -%}
+References: Low-Resource Routing Attacks Against Anonymous Systems
+{%- endtrans %}
    
+
+
    {% trans %}Intersection attacks{% endtrans %}
    
+
+
    {% trans -%}
+Intersection attacks against low latency systems are extremely powerful -
+periodically make contact with the target and keep track of what peers are on
+the network.  Over time, as node churn occurs the attacker will gain 
+significant information about the target by simply intersecting the sets of
+peers that are online when a message successfully goes through.  The cost of 
+this attack is significant as the network grows, but may be feasible in some
+scenarios.
+{%- endtrans %}
    
+
+
    {% trans url='https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatattacksremainagainstonionrouting' -%}
+In summary, if an attacker is at both ends of your tunnel at the same time,
+he may be successful.
+I2P does not have a full defense to this for low latency communication.
+This is an inherent weakness of low-latency onion routing.
+Tor provides a similar disclaimer.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Partial defenses implemented in I2P:
+{%- endtrans %}
    
+
      
+
    • {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
+strict ordering of peers
+{%- endtrans %}
      • 
+
    • {% trans peerselection=site_url('docs/how/peer-selection') -%}
+peer profiling and selection from a small group that changes slowly
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Limits on the number of tunnels routed through a single peer
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Prevention of peers from the same /16 IP range from being members of a single tunnel
+{%- endtrans %}
      • 
+
    • {% trans -%}
+For eepsites or other hosted services, we support
+simultaneous hosting on multiple routers, or
+multihoming
+{%- endtrans %}
      • 
+
    
+
+
    {% trans -%}
+Even in total, these defenses are not a complete solution.
+Also, we have made some design choices that may significantly increase our vulnerability:
+{%- endtrans %}
    
+
      
+
    • {% trans -%}
+We do not use low-bandwidth "guard nodes"
+{%- endtrans %}
      • 
+
    • {% trans -%}
+We use tunnel pools comprised of several tunnels, and traffic can shift from tunnel to tunnel.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Tunnels are not long-lived; new tunnels are built every 10 minutes.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Tunnel lengths are configurable.
+While 3-hop tunnels are recommended for full protection, several applications and
+services use 2-hop tunnels by default.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans todo=site_url('get-involved/todo') -%}
+In the future, it could
+for peers who can afford significant delays (per nontrivial
+delays and batching strategies).  In addition,
+this is only relevant for destinations that other people know about - a private
+group whose destination is only known to trusted peers does not have to worry,
+as an adversary can't "ping" them to mount the attack.
    
+{%- endtrans %}
    
+
+
    {% trans oce='http://blog.torproject.org/blog/one-cell-enough' -%}
+Reference: One Cell Enough
+{%- endtrans %}
    
+
+
+
    {% trans %}Denial of service attacks{% endtrans %}
    
+
+
    {% trans -%}
+There are a whole slew of denial of service attacks available against I2P,
+each with different costs and consequences:
+{%- endtrans %}
    
+
      
+
    • {% trans -%}
+Greedy user attack: This is simply
+people trying to consume significantly more resources than they are 
+willing to contribute. The defense against this is:
+{%- endtrans %}
+  
        
+  
      • {% trans comparisons=site_url('comparison') -%}
+Set defaults so that most users provide resources to the network.
+In I2P, users route traffic by default. In sharp distinction to
+other networks,
+over 95% of I2P users relay traffic for others.
+{%- endtrans %}
        • 
+  
      • {% trans -%}
+Provide easy configuration options so that users may increase their
+contribution (share percentage) to the network. Display easy-to-understand
+metrics such as "share ratio" so that users may see what they are contributing.
+{%- endtrans %}
        • 
+  
      • {% trans -%}
+Maintain a strong community with blogs, forums, IRC, and other means of communication.
+{%- endtrans %}
        • 
+  
      
+
      • 
+
    • {% trans peerselection=site_url('docs/how/peer-selection') -%}
+Starvation attack: A hostile user may attempt to harm the network by
+creating a significant number of peers in the network who are not identified as
+being under control of the same entity (as with Sybil). These nodes then 
+decide not to provide any resources to the network, causing existing peers 
+to search through a larger network database or request more tunnels than 
+should be necessary. 
+Alternatively, the nodes may provide intermittent service by periodically
+dropping selected traffic, or refusing connections to certain peers.
+This behavior may be indistinguishable from that of a heavily-loaded or failing node.
+I2P addresses these issues by maintaining profiles on the 
+peers, attempting to identify underperforming ones and simply ignoring 
+them, or using them rarely.
+We have significantly enhanced the
+ability to recognize and avoid troublesome peers; however there are still
+significant efforts required in this area.
+{%- endtrans %}
      • 
+
    • {% trans todo=site_url('get-involved/todo') -%}
+Flooding attack: A hostile user may attempt to flood the network,
+a peer, a destination, or a tunnel.  Network and peer flooding is possible,
+and I2P does nothing to prevent standard IP layer flooding.  The flooding of
+a destination with messages by sending a large number to the target's various
+inbound tunnel gateways is possible, but the destination will know this both
+by the contents of the message and because the tunnel's tests will fail.  The
+same goes for flooding just a single tunnel.  I2P has no defenses for a network
+flooding attack.  For a destination and tunnel flooding attack, the target
+identifies which tunnels are unresponsive and builds new ones.  New code could
+also be written to add even more tunnels if the client wishes to handle the
+larger load.  If, on the other hand, the load is more than the client can
+deal with, they can instruct the tunnels to throttle the number of messages or
+bytes they should pass on (once the advanced tunnel
+operation is implemented).
+{%- endtrans %}
      • 
+
    • {% trans -%}
+CPU load attack: There are currently some methods for people to 
+remotely request that a peer perform some cryptographically expensive 
+operation, and a hostile attacker could use these to flood that peer with
+a large number of them in an attempt to overload the CPU.  Both using good 
+engineering practices and potentially requiring nontrivial certificates 
+(e.g. HashCash) to be attached to these expensive requests should mitigate
+the issue, though there may be room for an attacker to exploit various
+bugs in the implementation.
+{%- endtrans %}
      • 
+
    • {% trans peerselection=site_url('docs/how/peer-selection'),
+netdb=site_url('docs/how/network-database') -%}
+Floodfill DOS attack: A hostile user may attempt to harm the network by
+becoming a floodfill router. The current defenses against unreliable,
+intermittent, or malicious floodfill routers are poor.
+A floodfill router may provide bad or no response to lookups, and
+it may also interfere with inter-floodfill communication.
+Some defenses and
+peer profiling are implemented,
+however there is much more to do.
+For more information see the
+network database page.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans %}Tagging attacks{% endtrans %}
    
+
    {% trans todo=site_url('get-involved/todo') -%}
+Tagging attacks - modifying a message so that it can later be identified 
+further along the path - are by themselves impossible in I2P, as messages 
+passed through tunnels are signed.  However, if an attacker is the inbound 
+tunnel gateway as well as a participant further along in that tunnel, with
+collusion they can identify the fact that they are in the same tunnel (and 
+prior to adding unique hop ids and other updates,
+colluding peers within the same tunnel can recognize that fact without any 
+effort).  An attacker in an outbound tunnel and any part of an inbound tunnel cannot 
+collude however, as the tunnel encryption pads and modifies the data separately
+for the inbound and outbound tunnels.  External attackers cannot do anything,
+as the links are encrypted and messages signed.
+{%- endtrans %}
    
+
+
    {% trans %}Partitioning attacks{% endtrans %}
    
+
+
    {% trans -%}
+Partitioning attacks - finding ways to segregate (technically or analytically)
+the peers in a network - are important to keep in mind when dealing with a 
+powerful adversary, since the size of the network plays a key role in determining
+your anonymity.  Technical partitioning by cutting links between peers to create
+fragmented networks is addressed by I2P's built in network database, which 
+maintains statistics about various peers so as to allow any existing connections
+to other fragmented sections to be exploited so as to heal the network.  However,
+if the attacker does disconnect all links to uncontrolled peers, essentially
+isolating the target, no amount of network database healing will fix it.  At
+that point, the only thing the router can hope to do is notice that a significant
+number of previously reliable peers have become unavailable and alert the client
+that it is temporarily disconnected (this detection code is not implemented at
+the moment).
+{%- endtrans %}
    
+
+
    {% trans todo=site_url('get-involved/todo') -%}
+Partitioning the network analytically by looking for differences in how routers 
+and destinations behave and grouping them accordingly is also a very powerful
+attack.  For instance, an attacker harvesting the network
+database will know when a particular destination has 5 inbound tunnels in their
+LeaseSet while others have only 2 or 3, allowing the adversary to potentially 
+partition clients by the number of tunnels selected.  Another partition is 
+possible when dealing with the nontrivial delays and 
+batching strategies, as the tunnel gateways and the
+particular hops with non-zero delays will likely stand out.  However, this data
+is only exposed to those specific hops, so to partition effectively on that 
+matter, the attacker would need to control a significant portion of the network
+(and still that would only be a probabilistic partition, as they wouldn't know
+which other tunnels or messages have those delays).
+{%- endtrans %}
    
+
+
    {% trans netdb=site_url('docs/how/network-database') -%}
+Also discussed on the network database page (bootstrap attack).
+{%- endtrans %}
    
+
+
    {% trans %}Predecessor attacks{% endtrans %}
    
+
+
    {% trans -%}
+The predecessor attack is passively gathering statistics in an attempt to see
+what peers are 'close' to the destination by participating in their tunnels and
+keeping track of the previous or next hop (for outbound or inbound tunnels, 
+respectively).  Over time, using a perfectly random sample of peers and random
+ordering, an attacker would be able to see which peer shows up as 'closer' 
+statistically more than the rest, and that peer would in turn be where the
+target is located.
+{%- endtrans %}
    
+
+
    {% trans peerselection=site_url('docs/how/peer-selection'),
+tunnelimpl=site_url('docs/tunnels/implementation'),
+todo=site_url('get-involved/todo') -%}
+I2P avoids this in four ways: first, the peers selected to participate in
+tunnels are not randomly sampled throughout the network - they are derived from
+the peer selection algorithm which breaks them
+into tiers.  Second, with strict ordering of peers
+in a tunnel, the fact that a peer shows up more frequently does not mean they're
+the source.  Third, with permuted tunnel length
+(not enabled by default)
+even 0 hop tunnels can provide plausible deniability as the occasional 
+variation of the gateway will look like normal tunnels.  Fourth, with 
+restricted routes (unimplemented), only the peer with
+a restricted connection to the target will ever contact the target, while 
+attackers will merely run into that gateway.
+{%- endtrans %}
    
+
+
    {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%}
+The current tunnel build method
+was specifically designed to combat the predecessor attack.
+See also the intersection attack.
+{%- endtrans %}
    
+
+
    {% trans pdf2008='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf',
+pdf2004='http://forensics.umass.edu/pubs/wright-tissec.pdf' -%}
+References: {{ pdf2008 }}
+which is an update to the 2004 predecessor attack paper
+{{ pdf2004 }}.
+{%- endtrans %}
    
+
+
+
    {% trans %}Harvesting attacks{% endtrans %}
    
+
    {% trans -%}
+"Harvesting" means compiling a list of users running I2P.
+It can be used for legal attacks and to help
+other attacks by simply running a peer, seeing who it connects to, and 
+harvesting whatever references to other peers it can find.
+{%- endtrans %}
    
+
+
    {% trans -%}
+I2P itself is not designed with effective defenses against
+this attack, since there is the distributed network database 
+containing just this information.
+The following factors make the attack somewhat harder in practice:
+{%- endtrans %}
    
+
      
+
    • {% trans -%}
+Network growth will make it more difficult to obtain a given proportion of the network
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Floodfill routers implement query limits as DOS protection
+{%- endtrans %}
      • 
+
    • {% trans -%}
+"Hidden mode", which prevents a router from publishing its information to the netDb,
+(but also prevents it from relaying data) is not widely used now but could be.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans todo=site_url('get-involved/todo') -%}
+In future implementations,
+basic and 
+comprehensive restricted routes,
+this attack loses much of its power, as the "hidden" peers do not publish their
+contact addresses in the network database - only the tunnels through which 
+they can be reached (as well as their public keys, etc).
+{%- endtrans %}
    
+
+
    {% trans -%}
+In the future, routers could use GeoIP to identify if they are in a particular
+country where identification as an I2P node would be risky.
+In that case, the router could automatically enable hidden mode, or
+enact other restricted route methods.
+{%- endtrans %}
    
+
+
+
    {% trans %}Identification Through Traffic Analysis{% endtrans %}
    
+
    {% trans transport=site_url('docs/transport') -%}
+By inspecting the traffic into and out of a router, a malicious ISP
+or state-level firewall could identify that a computer is running I2P.
+As discussed above, I2P is not specifically designed
+to hide that a computer is running I2P. However, several design decisions made
+in the design of the
+transport layer and protocols
+make it somewhat difficult to identify I2P traffic:
+{%- endtrans %}
    
+
      
+
    • {% trans -%}
+Random port selection
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Point-to-Point Encryption of all traffic
+{%- endtrans %}
      • 
+
    • {% trans -%}
+DH key exchange with no protocol bytes or other unencrypted constant fields
+{%- endtrans %}
      • 
+
    • {% trans ntcp=site_url('docs/transport/ntcp'), ssu=site_url('docs/transport/ssu') -%}
+Simultaneous use of both
+TCP and
+UDP transports.
+UDP may be much harder for some Deep Packet Inspection (DPI) equipment to track.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans -%}
+In the near future, we plan to directly address traffic analysis issues by further obfuscation of I2P transport protocols, possibly including:
+{%- endtrans %}
    
+
      
+
    • {% trans -%}
+Padding at the transport layer to random lengths, especially during the connection handshake
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Study of packet size distribution signatures, and additional padding as necessary
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Development of additional transport methods that mimic SSL or other common protocols
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Review of padding strategies at higher layers to see how they affect packet sizes at the transport layer
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Review of methods implemented by various state-level firewalls to block Tor
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Working directly with DPI and obfuscation experts
+{%- endtrans %}
      • 
+
    
+
+
    {% trans pdf='http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf' -%}
+Reference: Breaking and Improving Protocol Obfuscation
+{%- endtrans %}
    
+
+
+
    {% trans %}Sybil attacks{% endtrans %}
    
+
+
    {% trans -%}
+Sybil describes a category of attacks where the adversary creates arbitrarily
+large numbers of colluding nodes and uses the increased numbers to help 
+mounting other attacks.  For instance, if an attacker is in a network where peers
+are selected randomly and they want an 80% chance to be one of those peers, they
+simply create five times the number of nodes that are in the network and roll 
+the dice.  When identity is free, Sybil can be a very potent technique for a 
+powerful adversary.  The primary technique to address this is simply to make 
+identity 'non free' - Tarzan
+(among others) uses the fact that IP addresses are limited, while 
+IIP used 
+HashCash to 'charge' for creating a new
+identity.  We currently have not implemented any particular technique to address
+Sybil, but do include placeholder certificates in the router's and 
+destination's data structures which can contain a HashCash certificate of 
+appropriate value when necessary (or some other certificate proving scarcity).
+{%- endtrans %}
    
+
+
    {% trans -%}
+Requiring HashCash Certificates in various places has two major problems:
+{%- endtrans %}
    
+
      
+
    • {% trans -%}
+Maintaining backward compatibility
+{%- endtrans %}
      • 
+
    • {% trans -%}
+The classic HashCash problem -
+selecting HashCash values that are meaningful proofs of work on high-end machines,
+while still being feasible on low-end machines such as mobile devices.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans -%}
+Various limitations on the number of routers in a given IP range restrict
+the vulnerability to attackers that don't have the ability to put machines
+in several IP blocks.
+However, this is not a meaningful defense against a powerful adversary.
+{%- endtrans %}
    
+
+
    {% trans netdb=site_url('docs/how/network-database') -%}
+See the network database page
+for more Sybil discussion.
+{%- endtrans %}
    
+
+
+
    {% trans %}Buddy Exhaustion attacks{% endtrans %}
    
+
    {% trans pdf='http://www.eecs.berkeley.edu/~pmittal/publications/nisan-torsk-ccs10.pdf' -%}
+(Reference: In Search of an Anonymouns and Secure Lookup Section 5.2)
+{%- endtrans %}
    
+
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
+By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure
+that a tunnel is formed wholly from its set of colluding routers.
+The chances of success are enhanced if there is a large number of colluding routers,
+i.e. a Sybil attack.
+This is somewhat mitigated by our
+peer profiling methods used to monitor the performance
+of peers.
+However, this is a powerful attack as the number of routers approaches
+f = 0.2, or 20% malicious nodes, as specifed in the paper.
+The malicous routers could also maintain connections to the target router and provide
+excellent forwarding bandwidth for traffic over those connections, in an attempt
+to manipulate the profiles managed by the target and appear attractive.
+Further research and defenses may be necessary.
+{%- endtrans %}
    
+
+
+
    {% trans %}Cryptographic attacks{% endtrans %}
    
+
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+We use strong cryptography with long keys, and
+we assume the security of the industry-standard cryptographic primitives used in I2P, as documented
+on the low-level cryptography page. 
+Security features include the immediate detection of 
+altered messages along the path, the inability to decrypt messages not addressed to you,
+and defense against man-in-the-middle attacks.
+The key sizes chosen in 2003 were quite conservative at the time, and are still longer than
+those used in other anonymity networks.
+We don't think the current key lengths are our biggest weakness,
+especially for traditional, non-state-level adversaries;
+bugs and the small size of the network are much more worrisome.
+Of course, all cryptographic algorithms eventually become obsolete due to
+the advent of faster processors, cryptographic research, and advancements in
+methods such as rainbow tables, clusters of video game hardware, etc.
+Unfortunately, I2P was not designed with easy mechanisms to lengthen keys or change
+shared secret values while maintaining backward compatibility.
+{%- endtrans %}
    
+
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+Upgrading the various data structures and protocols to support longer keys
+will have to be tackled eventually, and this will be a
+major undertaking, just as it will be for 
+others.
+Hopefully, through careful planning, we can minimize the disruption, and
+implement mechanisms to make it easier for future transitions.
+{%- endtrans %}
    
+
+
    {% trans -%}
+In the future, several I2P protocols and data structures
+support securely padding messages to arbitrary sizes, so messages could be made constant
+size or garlic messages could be modified randomly so that some cloves appear to contain
+more subcloves than they actually do.  At the moment, however, garlic, tunnel, and 
+end to end messages include simple random padding.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Floodfill Anonymity attacks{% endtrans %}
    
+
    {% trans netdb=site_url('docs/how/network-database') -%}
+In addition to the floodfill DOS attacks described
+above, floodfill routers are uniquely positioned
+to learn about network participants, due to their role
+in the netDb, and the high frequency of communication with those participants.
+This is somewhat mitigated because floodfill routers only manage a portion
+of the total keyspace, and the keyspace rotates daily, as explained 
+on the network database page.
+The specific mechanisms by which routers communicate with floodfills have been
+carefully designed.
+However, these threats should be studied further.
+The specific potential threats and corresponding defenses are a topic for future research.
+{%- endtrans %}
    
+
+
+
    {% trans %}Other Network Database attacks{% endtrans %}
    
+
    {% trans netdb=site_url('docs/how/network-database') -%}
+A hostile user may attempt to harm the network by
+creating one or more floodfill routers and crafting them to offer
+bad, slow, or no responses.
+Several scenarios are discussed on the
+network database page.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Central Resource Attacks{% endtrans %}
    
+
    {% trans -%}
+There are a few centralized or limited resources (some inside I2P, some not)
+that could be attacked or used as a vector for attacks.
+The absence of jrandom starting November 2007, followed by the loss of the i2p.net hosting service in January 2008,
+highlighted numerous centralized resources in the development and operation of the I2P network,
+most of which are now distributed.
+Attacks on externally-reachable resources mainly affect the ability of new users to find us,
+not the operation of the network itself.
+{%- endtrans %}
    
+
      
+
    • {% trans site=site_url() -%}
+The website is mirrored and uses DNS round-robin for external public access.
+{%- endtrans %}
      • 
+
    • {% trans faq=site_url('faq') -%}
+Routers now support multiple external reseed locations,
+however more reseed hosts may be needed, and the handling of unreliable or malicious
+reseed hosts may need improvement.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Routers now support multiple update file locations.
+A malicious update host could feed a huge file, need to limit the size.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Routers now support multiple default trusted update signers.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Routers now better handle multiple unreliable floodfill peers.
+Malicious floodfills needs more study.
+{%- endtrans %}
      • 
+
    • {% trans monotone=site_url('get-involved/guides/monotone') -%}
+The code is now stored in a distributed source control system.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host.
+A malicious news host could feed a huge file, need to limit the size.
+{%- endtrans %}
      • 
+
    • {% trans naming=site_url('docs/naming') -%}
+Naming system services, including addressbook subscription providers, add-host services,
+and jump services, could be malicious. Substantial protections for subscriptions were implemented
+in release 0.6.1.31, with additional enhancements in subsequent releases.
+However, all naming services require some measure of trust, see
+the naming page for details.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+We remain reliant on the DNS service for i2p2.de, losing this would cause substantial
+disruption in our ability to attract new users,
+and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did.
+{%- endtrans %}
      • 
+
    
+
+
+
    {% trans %}Development attacks{% endtrans %}
    
+
+
    {% trans -%}
+These attacks aren't directly on the network, but instead go after its development team 
+by either introducing legal hurdles on anyone contributing to the development
+of the software, or by using whatever means are available to get the developers to 
+subvert the software.  Traditional technical measures cannot defeat these attacks, and
+if someone threatened the life or livelihood of a developer (or even just issuing a 
+court order along with a gag order, under threat of prison), we would have a big problem.
+{%- endtrans %}
    
+
+
    {% trans -%}
+However, two techniques help defend against these attacks:
+{%- endtrans %}
    
+
      
+
    • {% trans monotone=site_url('get-involved/guides/monotone') -%}
+All components of the network must be open source to enable inspection, verification, 
+modification, and improvement.  If a developer is compromised, once it is noticed 
+the community should demand explanation and cease to accept that developer's work.
+All checkins to our distributed source control system
+are cryptographically signed, and the release packagers use a trust-list system
+to restrict modifications to those previously approved.
+{%- endtrans %}
      • 
+
    • {% trans monotone=site_url('get-involved/guides/monotone') -%}
+Development over the network itself, allowing developers to stay anonymous but still 
+secure the development process.  All I2P development can occur through I2P - using
+a distributed source control system,
+a distributed source control system, IRC chat,
+public web servers,
+discussion forums (forum.i2p), and the software distribution sites,
+all available within I2P.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans -%}
+We also maintain relationships with various organizations that offer legal advice,
+should any defense be necessary.
+{%- endtrans %}
    
+
+
    {% trans %}Implementation attacks (bugs){% endtrans %}
    
+
    {% trans -%}
+Try as we might, most nontrivial applications include errors in the design or 
+implementation, and I2P is no exception.  There may be bugs that could be exploited to 
+attack the anonymity or security of the communication running over I2P in unexpected 
+ways.  To help withstand attacks against the design or protocols in use, we publish 
+all designs and documentation and solicit review and criticism with 
+the hope that many eyes will improve the system.
+We do not believe in
+security through obscurity.
+{%- endtrans %}
    
+
+
    {% trans -%}
+In addition, the code is being 
+treated the same way, with little aversion towards reworking or throwing out 
+something that isn't meeting the needs of the software system (including ease of 
+modification).  Documentation for the design and implementation of the network and 
+the software components are an essential part of security, as without them it is 
+unlikely that developers would be willing to spend the time to learn the software 
+enough to identify shortcomings and bugs.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Our software is likely, in particular, to contain bugs related to denial of service
+through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues  in the router console,
+and other vulnerabilities to non-standard inputs via the various protocols.
+{%- endtrans %}
    
+
+
    {% trans volunteer=site_url('get-involved') -%}
+I2P is still a small network with a small development community and almost no
+interest from academic or research groups.
+Therefore we lack the analysis that
+other anonymity networks
+may have received. We continue to recruit people to
+get involved and help.
+{%- endtrans %}
    
+
+
+
+
+
    {% trans %}Other Defenses{% endtrans %}
    
+
    {% trans %}Blocklists{% endtrans %}
    
+
    {% trans -%}
+To some extent, I2P could be enhanced to avoid peers operating at IP addresses
+listed in a blocklist. Several blocklists are commonly available in standard formats,
+listing anti-P2P organizations, potential state-level adversaries, and others.
+{%- endtrans %}
    
+
+
    {% trans -%}
+To the extent that active peers actually do show up in the actual blocklist,
+blocking by only a subset of peers would tend to segment the network,
+exacerbate reachability problems, and decrease overall reliability.
+Therefore we would want to agree on a particular blocklist and
+enable it by default.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Blocklists are only a part (perhaps a small part) of an array of defenses
+against maliciousness.
+In large part the profiling system does a good job of measuring
+router behavior so that we don't need to trust anything in netDb.
+However there is more that can be done. For each of the areas in the
+list above there are improvements we can make in detecting badness.
+{%- endtrans %}
    
+
+
    {% trans -%}
+If a blocklist is hosted at a central location with automatic updates
+the network is vulnerable to a
+central resource attack.
+Automatic subscription to a list gives the list provider the power to shut
+the i2p network down. Completely.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Currently, a default blocklist is distributed with our software,
+listing only the IPs of past DOS sources.
+There is no automatic update mechanism.
+Should a particular IP range implement serious attacks on the I2P network,
+we would have to ask people to update their blocklist manually through
+out-of-band mechanisms such as forums, blogs, etc.
+{%- endtrans %}
    
+
+
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/how/tunnel-routing.html b/i2p2www/pages/site/docs/how/tunnel-routing.html
new file mode 100644
index 00000000..31c0fd3b
--- /dev/null
+++ b/i2p2www/pages/site/docs/how/tunnel-routing.html
@@ -0,0 +1,299 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Tunnel Overview{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}July 2011{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.7{% endblock %}
+{% block content %}
+
    {% trans %}Tunnel Overview{% endtrans %}
    
+
    {% trans -%}
+This page contains an overview of I2P tunnel terminology and operation, with
+links to more technical pages, details, and specifications.
+{%- endtrans %}
    
+
+
    {% trans intro=site_url('docs/how/intro') -%}
+As briefly explained in the introduction, I2P builds virtual "tunnels" -
+temporary and unidirectional paths through a sequence of routers.  These 
+tunnels are classified as either inbound tunnels (where everything 
+given to it goes towards the creator of the tunnel) or outbound tunnels
+(where the tunnel creator shoves messages away from them).  When Alice
+wants to send a message to Bob, she will (typically) send it out one of
+her existing outbound tunnels with instructions for that tunnel's endpoint
+to forward it to the gateway router for one of Bob's current inbound 
+tunnels, which in turn passes it to Bob.
+{%- endtrans %}
    
+
+
    
+{{ _('Alice connecting through her outbound tunnel to Bob via his inbound tunnel') }}
+
    +A: {% trans %}Outbound Gateway{% endtrans %} (Alice)
+B: {% trans %}Outbound Participant{% endtrans %}
+C: {% trans %}Outbound Endpoint{% endtrans %}
+D: {% trans %}Inbound Gateway{% endtrans %}
+E: {% trans %}Inbound Participant{% endtrans %}
+F: {% trans %}Inbound Endpoint{% endtrans %} (Bob)
+
    
+
    
+
+
    {% trans %}Tunnel vocabulary{% endtrans %}
    
+
      
+
    • {% trans netdb=site_url('docs/how/network-database') -%}
+Tunnel gateway - the first router in a tunnel.  For inbound tunnels,
+this is the one mentioned in the LeaseSet published in the
+network database.  For outbound tunnels, the
+gateway is the originating router.  (e.g. both A and D above)
+{%- endtrans %}
      • 
+
    • {% trans %}Tunnel endpoint - the last router in a tunnel.  (e.g. both C and F above){% endtrans %}
      • 
+
    • {% trans -%}
+Tunnel participant - all routers in a tunnel except for the gateway or
+endpoint (e.g. both B and E above)
+{%- endtrans %}
      • 
+
    • {% trans %}n-Hop tunnel - a tunnel with a specific number of inter-router jumps, e.g.:{% endtrans %}
+  
        
+  
      • {% trans %}0-hop tunnel - a tunnel where the gateway is also the endpoint{% endtrans %}
        • 
+  
      • {% trans %}1-hop tunnel - a tunnel where the gateway talks directly to the endpoint{% endtrans %}
        • 
+  
      • {% trans -%}
+2-(or more)-hop tunnel - a tunnel where there is at least one intermediate
+tunnel participant. (the above diagram includes two 2-hop tunnels - one
+outbound from Alice, one inbound to Bob)
+{%- endtrans %}
        • 
+
      
+
      • 
+
    • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+Tunnel ID - A 4 byte integer
+different for each hop in a tunnel, and unique among all tunnels on a router.
+Chosen randomly by the tunnel creator.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans %}Tunnel Build Information{% endtrans %}
    
+
    {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%}
+Routers performing the three roles (gateway, participant, endpoint) are given
+different pieces of data in the initial
+Tunnel Build Message
+to accomplish their tasks:
+{%- endtrans %}
    
+
      
+
    • {% trans %}The tunnel gateway gets:{% endtrans %}
+  
        
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+tunnel encryption key - an AES private key for encrypting
+messages and instructions to the next hop
+{%- endtrans %}
        • 
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+tunnel IV key - an AES private key for double-encrypting
+the IV to the next hop
+{%- endtrans %}
        • 
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+reply key - an AES public key for encrypting
+the reply to the tunnel build request
+{%- endtrans %}
        • 
+  
      • {% trans %}reply IV - the IV for encrypting the reply to the tunnel build request{% endtrans %}
        • 
+  
      • {% trans %}tunnel id - 4 byte integer (inbound gateways only){% endtrans %}
        • 
+  
      • {% trans %}next hop - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint){% endtrans %}
        • 
+  
      • {% trans %}next tunnel id - The tunnel ID on the next hop{% endtrans %}
        • 
+  
      
+
      • 
+
    • {% trans %}All intermediate tunnel participants get:{% endtrans %}
+  
        
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+tunnel encryption key - an AES private key for encrypting
+messages and instructions to the next hop
+{%- endtrans %}
        • 
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+tunnel IV key - an AES private key for double-encrypting
+the IV to the next hop
+{%- endtrans %}
        • 
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+reply key - an AES public key for encrypting
+the reply to the tunnel build request
+{%- endtrans %}
        • 
+  
      • {% trans %}reply IV - the IV for encrypting the reply to the tunnel build request{% endtrans %}
        • 
+  
      • {% trans %}tunnel id - 4 byte integer{% endtrans %}
        • 
+  
      • {% trans %}next hop - what router is the next one in the path{% endtrans %}
        • 
+  
      • {% trans %}next tunnel id - The tunnel ID on the next hop{% endtrans %}
        • 
+  
      
+
      • 
+
    •  {% trans %}The tunnel endpoint gets:{% endtrans %}
+  
        
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+tunnel encryption key - an AES private key for encrypting
+messages and instructions to the the endpoint (itself)
+{%- endtrans %}
        • 
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+tunnel IV key - an AES private key for double-encrypting
+the IV to the endpoint (itself)
+{%- endtrans %}
        • 
+  
      • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+reply key - an AES public key for encrypting
+the reply to the tunnel build request (outbound endpoints only)
+{%- endtrans %}
        • 
+  
      • {% trans %}reply IV - the IV for encrypting the reply to the tunnel build request (outbound endpoints only){% endtrans %}
        • 
+  
      • {% trans %}tunnel id - 4 byte integer (outbound endpoints only){% endtrans %}
        • 
+  
      • {% trans %}reply router - the inbound gateway of the tunnel to send the reply through (outbound endpoints only){% endtrans %}
        • 
+  
      • {% trans %}reply tunnel id - The tunnel ID of the reply router (outbound endpoints only){% endtrans %}
        • 
+  
      
+
      • 
+
    
+
+
    {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%}
+Details are in the
+tunnel creation specification.
+{%- endtrans %}
    
+
+
    {% trans %}Tunnel pooling{% endtrans %}
    
+
    {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
+Several tunnels for a particular purpose may be grouped into a "tunnel pool",
+as described in the
+tunnel specification.
+This provides redundancy and additional bandwidth.
+The pools used by the router itself are called "exploratory tunnels".
+The pools used by applications are called "client tunnels".
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Tunnel length{% endtrans %}
    
+
    {% trans i2cp=site_url('docs/protocol/i2cp') -%}
+As mentioned above, each client requests that their router provide tunnels to
+include at least a certain number of hops.
+The decision as to how many routers
+to have in one's outbound and inbound tunnels has an important effect upon the
+latency, throughput, reliability, and anonymity provided by I2P - the more peers
+that messages have to go through, the longer it takes to get there and the more
+likely that one of those routers will fail prematurely.  The less routers in a
+tunnel, the easier it is for an adversary to mount traffic analysis attacks and
+pierce someone's anonymity.
+Tunnel lengths are specified by clients via
+I2CP options.
+The maximum number of hops in a tunnel is 7.
+{%- endtrans %}
    
+
+
+
    {% trans %}0-hop tunnels{% endtrans %}
    
+
    {% trans -%}
+With no remote routers in a tunnel, the user has very basic plausible
+deniability (since no one knows for sure that the peer that sent them the
+message wasn't simply just forwarding it on as part of the tunnel). However, it
+would be fairly easy to mount a statistical analysis attack and notice that
+messages targeting a specific destination are always sent through a single
+gateway.  Statistical analysis against outbound 0-hop tunnels are more complex,
+but could show similar information (though would be slightly harder to mount).
+{%- endtrans %}
    
+
+
    {% trans %}1-hop tunnels{% endtrans %}
    
+
    {% trans threatmodel=site_url('docs/how/threat-model') -%}
+With only one remote router in a tunnel, the user has both plausible
+deniability and basic anonymity, as long as they are not up against an internal
+adversary (as described on threat model). However,
+if the adversary ran a sufficient number of routers such that the single remote
+router in the tunnel is often one of those compromised ones, they would be able
+to mount the above statistical traffic analysis attack.
+{%- endtrans %}
    
+
+
    {% trans %}2-hop tunnels{% endtrans %}
    
+
    {% trans -%}
+With two or more remote routers in a tunnel, the costs of mounting the traffic
+analysis attack increases, since many remote routers would have to be compromised
+to mount it.
+{%- endtrans %}
    
+
+
    {% trans %}3-hop (or more) tunnels{% endtrans %}
    
+
    {% trans url='http://blog.torproject.org/blog/one-cell-enough' -%}
+To reduce the susceptibility to some attacks,
+3 or more hops are recommended for the highest level of protection.
+Recent studies
+also conclude that more than 3 hops does not provide additional protection.
+{%- endtrans %}
    
+
+
+
    {% trans %}Tunnel default lengths{% endtrans %}
    
+
    {% trans i2cp=site_url('docs/protocol/i2cp') -%}
+The router uses 2-hop tunnels by default for its exploratory tunnels.
+Client tunnel defaults are set by the application, using
+I2CP options.
+Most applications use 2 or 3 hops as their default.
+{%- endtrans %}
    
+
+
+
+
    {% trans %}Tunnel testing{% endtrans %}
    
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
+All tunnels are periodically tested by their creator by sending a
+DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel
+(testing both tunnels at once).  If either fails a number of consecutive tests, it is marked as no longer
+functional. If it was used for a client's inbound tunnel, a new leaseSet
+is created.
+Tunnel test failures are also reflected in the
+capacity rating in the peer profile.
+{%- endtrans %}
    
+
+
+
    {% trans %}Tunnel creation{% endtrans %}
    
+
    {% trans garlicrouting=site_url('docs/how/garlic-routing'),
+tunnelcreation=site_url('docs/spec/tunnel-creation') -%}
+Tunnel creation is handled by garlic routing
+a Tunnel Build Message to a router, requesting that they participate in the
+tunnel (providing them with all of the appropriate information, as above, along
+with a certificate, which right now is a 'null' cert, but will support hashcash
+or other non-free certificates when necessary).
+That router forwards the message to the next hop in the tunnel.
+Details are in the
+tunnel creation specification.
+{%- endtrans %}
    
+
+
+
    Tunnel encryption
    
+
    {% trans garlicrouting=site_url('docs/how/garlic-routing'),
+tunnelimpl=site_url('docs/tunnels/implementation') -%}
+Multi-layer encryption is handled by garlic encryption
+of tunnel messages.
+Details are in the
+tunnel specification.
+The IV of each hop is encrypted with a separate key as explained there.
+{%- endtrans %}
    
+
+
+
    {% trans %}Future Work{% endtrans %}
    
+
      
+
    • {% trans -%}
+Other tunnel test techniques could be used, such as
+garlic wrapping a number of tests into cloves, testing individual tunnel
+participants separately, etc.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Move to 3-hop exploratory tunnels defaults.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+In a distant future release,
+options specifying the pooling, mixing, and chaff generation settings may be implemented.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+In a distant future release,
+limits on the quantity and size of messages allowed during the
+tunnel's lifetime may be implemented (e.g. no more than 300 messages or
+1MB per minute).
+{%- endtrans %}
      • 
+
    
+
+
+
    {% trans %}See Also{% endtrans %}
    
+
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/index.html b/i2p2www/pages/site/docs/index.html
new file mode 100644
index 00000000..5b860b55
--- /dev/null
+++ b/i2p2www/pages/site/docs/index.html
@@ -0,0 +1,238 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Index to Technical Documentation{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}May 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9{% endblock %}
+{% block content %}
+
    {% trans %}How does I2P work{% endtrans %}
    
+
+
    {% trans -%}
+Following is an index to the technical documentation for I2P.
+{%- endtrans %}
    
+
+
    {% trans -%}
+This index is ordered from the highest to lowest layers.
+The higher layers are for "clients" or applications;
+the lower layers are inside the router itself.
+The interface between applications and the router is the I2CP (I2P Control Protocol) API.
+{%- endtrans %}
    
+
+
    {% trans trac=i2pconv('trac.i2p2.i2p') -%}
+The I2P Project is committed to maintaining accurate, current documentation.
+If you find any inaccuracies in the documents linked below, please
+enter a ticket identifying the problem.
+{%- endtrans %}
    
+
+
    {% trans %}Index to Technical Documentation{% endtrans %}
    
+
+
    {% trans %}Overview{% endtrans %}
    
+
+
+
    {% trans %}Application-Layer Topics{% endtrans %}
    
+
+
+
    {% trans %}Application Layer API and Protocols{% endtrans %}
    
+{% trans %}High-level, easy-to-use APIs for applications written in any language to send and receive data.{% endtrans %}
+
+
+
    {% trans %}End-to-End Transport API and Protocols{% endtrans %}
    
+{% trans %}The end-to-end protocols used by clients for reliable and unreliable communication.{% endtrans %}
+
+
+
    {% trans %}Client-to-Router Interface API and Protocol{% endtrans %}
    
+{% trans -%}
+The lowest-level API used for clients (applications) to send and receive traffic to a router.
+Traditionally used only by Java applications and higher-level APIs.
+{%- endtrans %}
+
+
+
    {% trans %}End-to-End Encryption{% endtrans %}
    
+{% trans %}How client messages are end-to-end encrypted by the router.{% endtrans %}
+
+
+
    {% trans %}Network Database{% endtrans %}
    
+{% trans %}Distributed storage and retrieval of information about routers and clients.{% endtrans %}
+
+
+
    {% trans %}Router Message Protocol{% endtrans %}
    
+{% trans %}I2P is a message-oriented router. The messages sent between routers are defined by the I2NP protocol.{% endtrans %}
+
+
+
    {% trans %}Tunnels{% endtrans %}
    
+{% trans %}Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.{% endtrans %}
+
+
+
    {% trans %}Transport Layer{% endtrans %}
    
+{% trans %}The protocols for direct (point-to-point) router to router communication.{% endtrans %}
+
+
+
    {% trans %}Other Router Topics{% endtrans %}
    
+
+
+
    {% trans %}Developer's Guides and Resources{% endtrans %}
    
+
+
+
+{% endblock %}
diff --git a/www.i2p2/pages/naming.html b/i2p2www/pages/site/docs/naming.html
similarity index 57%
rename from www.i2p2/pages/naming.html
rename to i2p2www/pages/site/docs/naming.html
index 5635ee3b..405320df 100644
--- a/www.i2p2/pages/naming.html
+++ b/i2p2www/pages/site/docs/naming.html
@@ -1,18 +1,19 @@
-{% extends "_layout.html" %}
-{% block title %}Naming and Addressbook{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Naming and Addressbook{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}March 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.13{% endblock %}
 {% block content %}
-
    Naming in I2P
    
-
    Overview
    
+
    {% trans %}Naming in I2P{% endtrans %}
    
+
    {% trans %}Overview{% endtrans %}
    
 
-This page was last updated in March 2012 and is accurate for router version 0.8.13.
-
    
+
    {% trans -%}
 I2P ships with a generic naming library and a base implementation 
 designed to work off a local name to destination mapping, as well as an
 add-on application called the addressbook. 
 I2P also supports Base32 hostnames similar to Tor's .onion addresses.
-
    
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 The addressbook is a web-of-trust
 driven secure, distributed, and human readable naming system, sacrificing only
 the call for all human readable names to be globally unique by mandating only
@@ -24,116 +25,150 @@ by adding in the entries provided through a third party, or (if some people orga
 a series of published addressbooks using a first come first serve registration
 system) people can choose to treat these addressbooks as name servers, emulating
 traditional DNS.
-
    
+{%- endtrans %}
    
 
-
    
+
    {% trans namingdiscussion=site_url('docs/discussions/naming') -%}
 NOTE: For the reasoning behind the I2P naming system, common arguments against it
-and possible alternatives see the naming discussion
+and possible alternatives see the naming discussion
 page.
-
    
+{%- endtrans %}
    
 
 
-
    Naming System Components
    
-
    
+
    {% trans %}Naming System Components{% endtrans %}
    
+
+
    {% trans -%}
 There is no central naming authority in I2P.
 All hostnames are local.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The naming system is quite simple and most of it is implemented
 in applications external to the router, but bundled with
 the I2P distribution.
 The components are:
-
    
+{%- endtrans %}
    
+
 
      
-
    1. The client application which does local lookups in hosts.txt
+
    2. {% trans -%}
+The client application which does local lookups in hosts.txt
 and also takes care of the Base32 hostnames.
-
    3. The HTTP proxy which asks the router for lookups and points
-the user to remote jump services to assist with failed lookups
-
    4. HTTP host-add forms which allow users to add hosts to their local hosts.txt
-
    5. HTTP jump services which provide their own lookups and redirection
-
    6. The addressbook application which merges external
-host lists, retrieved via HTTP, with the local list
-
    7. The SusiDNS application which is a simple web front-end
+{%- endtrans %}
      8. 
+
    8. {% trans -%}
+The HTTP proxy which asks the router for lookups and points
+the user to remote jump services to assist with failed lookups.
+{%- endtrans %}
      9. 
+
    9. {% trans -%}
+HTTP host-add forms which allow users to add hosts to their local hosts.txt
+{%- endtrans %}
      10. 
+
    10. {% trans -%}
+HTTP jump services which provide their own lookups and redirection.
+{%- endtrans %}
      11. 
+
    11. {% trans -%}
+The addressbook application which merges external
+host lists, retrieved via HTTP, with the local list.
+{%- endtrans %}
      12. 
+
    12. {% trans -%}
+The SusiDNS application which is a simple web front-end
 for addressbook configuration and viewing of the local host lists.
+{%- endtrans %}
      13. 
 
    
 
-
    Naming Files and Lookups
    
-
    
+
+
    {% trans %}Naming Files and Lookups{% endtrans %}
    
+
+
    {% trans namingdiscussion=site_url('docs/discussions/naming'), todo=site_url('get-involved/todo') -%}
 All destinations in I2P are 516-byte (or longer) keys.
 (To be more precise, it is a 256-byte public key plus a 128-byte signing key
 plus a null certificate, which in Base64 representation is 516 bytes.
-Certificates are not used now,
+Certificates are not used now,
 if they are, the keys will be longer.
-One possible use of certificates is for proof of work.)
-
    
+One possible use of certificates is for proof of work.)
+{%- endtrans %}
    
+
+
    {% trans -%}
 If an application (i2ptunnel or the HTTP proxy) wishes to access
 a destination by name, the router does a very simple local lookup
 to resolve that name.
 The client application (technically, the client side of I2CP in the I2P API)
 does a linear search through three local files, in order, to
 look up host names and convert them to a 516-byte destination key:
+{%- endtrans %}
    
+
 
      
 
    1. privatehosts.txt
 
    2. userhosts.txt
 
    3. hosts.txt
 
    
-
    The lookup is case-insensitive.
+
+
    {% trans -%}
+The lookup is case-insensitive.
 The first match is used, and conflicts are not detected.
 There is no enforcement of naming rules in lookups.
-
    
+{%- endtrans %}
    
+
+
    {% trans namingdiscussion=site_url('docs/discussions/naming') -%}
 Lookups are cached for a few minutes.
 There is an experimental facility for real-time lookups (a la DNS) over the network within the router,
 although it is not enabled by default
-(see "EepGet" under Alternatives on the discussion page).
-
    
+(see "EepGet" under Alternatives on the discussion page).
+{%- endtrans %}
    
 
-
    HTTP Proxy
    
-
    The HTTP proxy does a lookup via the router for all hostnames ending in '.i2p'.
+
    {% trans %}HTTP Proxy{% endtrans %}
    
+
+
    {% trans -%}
+The HTTP proxy does a lookup via the router for all hostnames ending in '.i2p'.
 Otherwise, it forwards the request to a configured HTTP outproxy.
 Thus, in practice, all HTTP (eepsite) hostnames must end in the pseudo-Top Level Domain '.i2p'.
-
    
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 If the router fails to resolve the hostname, the HTTP proxy returns
 an error page to the user with links to several "jump" services.
 See below for details.
-
    
+{%- endtrans %}
    
 
-
    Addressbook
    
-
    Incoming Subscriptions and Merging
    
-
    
+
    {% trans %}Addressbook{% endtrans %}
    
+
    {% trans %}Incoming Subscriptions and Merging{% endtrans %}
    
+
+
    {% trans -%}
 The addressbook application periodically
 retrieves other users' hosts.txt files and merges
 them with the local hosts.txt, after several checks.
 Naming conflicts are resolved on a first-come first-served
 basis.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Subscribing to another user's hosts.txt file involves
 giving them a certain amount of trust.
 You do not want them, for example, 'hijacking' a new site
 by quickly entering in their own key for a new site before
 passing the new host/key entry to you.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 For this reason, the only subscription configured by
 default is http://www.i2p2.i2p/hosts.txt,
 which contains a copy of the hosts.txt included
 in the I2P release.
 Users must configure additional subscriptions in their
 local addressbook application (via subscriptions.txt or SusiDNS).
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Some other public addressbook subscription links:
-
    
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 The operators of these services may have various policies for listing hosts.
 Presence on this list does not imply endorsement.
-
    
+{%- endtrans %}
    
 
-
    Naming Rules
    
-
    
+
    {% trans %}Naming Rules{% endtrans %}
    
+
    {% trans -%}
 While there are hopefully not any technical limitations within I2P on host names,
 the addressbook enforces several restrictions on host names
 imported from subscriptions.
@@ -142,30 +177,80 @@ and for security.
 The rules are essentially the same as those in RFC2396 Section 3.2.2.
 Any hostnames violating these rules may not be propagated
 to other routers.
-
    
-Naming rules:
    
+{%- endtrans %}
    
+
+
    {% trans -%}
+Naming Rules
+{%- endtrans %}:
    
 
      
-
    • Names are converted to lower case on import.
-
    • Names are checked for conflict with existing names in the existing userhosts.txt and hosts.txt
+
    • {% trans -%}
+Names are converted to lower case on import.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Names are checked for conflict with existing names in the existing userhosts.txt and hosts.txt
 (but not privatehosts.txt) after conversion to lower case.
-
    • Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case.
-
    • Must not start with '.' or '-'.
-
    • Must end with '.i2p'.
-
    • 67 characters maximum, including the '.i2p'.
-
    • Must not contain '..'.
-
    • Must not contain '.-' or '-.' (as of 0.6.1.33).
-
    • Must not contain '--' except in 'xn--' for IDN.
-
    • Base32 hostnames (*.b32.i2p) are not allowed.
-
    • Certain hostnames reserved for project use are not allowed
-    (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, and others)
-
    • Keys are checked for base64 validity.
-
    • Keys are checked for conflict with existing keys in hosts.txt (but not privatehosts.txt).
-
    • Minimum key length 516 bytes.
-
    • Maximum key length 616 bytes (to account for certs up to 100 bytes).
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Must not start with '.' or '-'.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Must end with '.i2p'.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+67 characters maximum, including the '.i2p'.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Must not contain '..'.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Must not contain '.-' or '-.' (as of 0.6.1.33).
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Must not contain '--' except in 'xn--' for IDN.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Base32 hostnames (*.b32.i2p) are not allowed.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Certain hostnames reserved for project use are not allowed
+(proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, and others)
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Keys are checked for base64 validity.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Keys are checked for conflict with existing keys in hosts.txt (but not privatehosts.txt).
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Minimum key length 516 bytes.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Maximum key length 616 bytes (to account for certs up to 100 bytes).
+{%- endtrans %}
      • 
 
    
-
    
+
+
    {% trans -%}
 Any name received via subscription that passes all the checks is added to the local hosts.txt.		
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Note that the '.' symbols in a host name are of no significance,
 and do not denote any actual naming or trust hierarchy.
 If the name 'host.i2p' already exists, there is nothing
@@ -174,70 +259,110 @@ and this name can be imported by others' addressbook.
 Methods to deny subdomains to non-domain 'owners' (certificates?),
 and the desirability and feasibility of these methods,
 are topics for future discussion.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 International Domain Names (IDN) also work in i2p (using punycode 'xn--' form).
 To see IDN .i2p domain names rendered correctly in Firefox's location bar,
 add 'network.IDN.whitelist.i2p (boolean) = true' in about:config.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 As the addressbook application does not use privatehosts.txt at all, in practice
 this file is the only place where it is appropriate to place private aliases or
 "pet names" for sites already in hosts.txt.
-
    
+{%- endtrans %}
    
 
-
    Outgoing Subscriptions
    
-
    
+
    {% trans %}Outgoing Subscriptions{% endtrans %}
    
+
    {% trans -%}
 Addressbook will publish the merged hosts.txt to a location
 (traditionally hosts.txt in the local eepsite's home directory) to be accessed by others
 for their subscriptions.
 This step is optional and is disabled by default.
-
    
+{%- endtrans %}
    
 
 
    Hosting and HTTP Transport Issues
    
-
    
+
    {% trans -%}
 The addressbook application, together with eepget, saves the Etag and/or Last-Modified
 information returned by the web server of the subscription.
 This greatly reduces the bandwidth required, as the web server will
 return a '304 Not Modified' on the next fetch if nothing has changed.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 However the entire hosts.txt is downloaded if it has changed.
 See below for discussion on this issue.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Hosts serving a static hosts.txt or an equivalent CGI application
 are strongly encouraged to deliver
 a Content-Length header, and either an Etag or Last-Modified header.
 Also ensure that the server delivers a '304 Not Modified' when appropriate.
 This will dramatically reduce the network bandwidth, and
 reduce chances of corruption.
-
    
+{%- endtrans %}
    
 
-
    Host Add Services
    
-
    
+
    {% trans %}Host Add Services{% endtrans %}
    
+
    {% trans -%}
 A host add service is a simple CGI application that takes a hostname and a Base64 key as parameters
 and adds that to its local hosts.txt.
 If other routers subscribe to that hosts.txt, the new hostname/key
 will be propagated through the network.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 It is recommended that host add services impose, at a minimum, the restrictions imposed by the addressbook application listed above.
 Host add services may impose additional restrictions on hostnames and keys, for example:
-
    
+{%- endtrans %}
    
 
      
-
    • A limit on number of 'subdomains'.
-
    • Authorization for 'subdomains' through various methods.
-
    • Hashcash or signed certificates.
-
    • Editorial review of host names and/or content.
-
    • Categorization of hosts by content.
-
    • Reservation or rejection of certain host names.
-
    • Restrictions on the number of names registered in a given time period.
-
    • Delays between registration and publication.
-
    • Requirement that the host be up for verification.
-
    • Expiration and/or revocation.
-
    • IDN spoof rejection.
+
    • {% trans -%}
+A limit on number of 'subdomains'.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Authorization for 'subdomains' through various methods.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Hashcash or signed certificates.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Editorial review of host names and/or content.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Categorization of hosts by content.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Reservation or rejection of certain host names.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Restrictions on the number of names registered in a given time period.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Delays between registration and publication.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Requirement that the host be up for verification.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Expiration and/or revocation.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+IDN spoof rejection.
+{%- endtrans %}
      • 
 
    
 
-
    Jump Services
    
-
    
+
    {% trans %}Jump Services{% endtrans %}
    
+
    {% trans -%}
 A jump service is a simple CGI application that takes a hostname as a parameter
 and returns a 301 redirect to the proper URL with a ?i2paddresshelper=key
 string appended.
@@ -245,34 +370,41 @@ The HTTP proxy will interpret the appended string and
 use that key as the actual destination.
 In addition, the proxy will cache that key so the
 address helper is not necessary until restart.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Note that, like with subscriptions, using a jump service
 implies a certain amount of trust, as a jump service could maliciously
 redirect a user to an incorrect destination.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 To provide the best service, a jump service should be subscribed to
 several hosts.txt providers so that its local host list is current.
-
    
+{%- endtrans %}
    
 
 
    SusiDNS
    
-
    
+
    {% trans -%}
 SusiDNS is simply a web interface front-end to configuring addressbook subscriptions
 and accessing the four addressbook files.
 All the real work is done by the 'addressbook' application.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Currently, there is little enforcement of addressbook naming rules within SusiDNS,
 so a user may enter hostnames locally that would be rejected by
 the addressbook subscription rules.
-
    
+{%- endtrans %}
    
 
-
    Base32 Names
    
-
    I2P supports Base32 hostnames similar to Tor's .onion addresses.
+
    {% trans %}Base32 Names{% endtrans %}
    
+
    {% trans -%}
+I2P supports Base32 hostnames similar to Tor's .onion addresses.
 Base32 addresses are much shorter and easier to handle than the
 full 516-character Base64 Destinations or addresshelpers.
 Example: ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 In Tor, the address is 16 characters (80 bits), or half of the SHA-1 hash.
 I2P uses 52 characters (256 bits) to represent the full SHA-256 hash.
 The form is {52 chars}.b32.i2p.
@@ -282,10 +414,12 @@ Base32 lookups will only be successful when the Destination is up and publishing
 a LeaseSet.
 Because resolution may require a network database lookup, it may take significantly
 longer than a local address book lookup.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Base32 addresses can be used in most places where hostnames or full destinations
 are used, however there are some exceptions where they may fail if the
 name does not immediately resolve. I2PTunnel will fail, for example, if
 the name does not resolve to a destination.
-
    
+{%- endtrans %}
    
 {% endblock %}
diff --git a/i2p2www/pages/site/docs/plugins.html b/i2p2www/pages/site/docs/plugins.html
new file mode 100644
index 00000000..0f913c1f
--- /dev/null
+++ b/i2p2www/pages/site/docs/plugins.html
@@ -0,0 +1,194 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Plugins{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}June 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9{% endblock %}
+{% block content %}
+
    {% trans %}I2P Plugins{% endtrans %}
    
+
+
    {% trans %}General Information{% endtrans %}
    
+
    {% trans -%}
+I2P includes a plugin architecture
+to support easy development and installation of additional software.
+{%- endtrans %}
    
+
+
    {% trans -%}
+There are now plugins available that support distributed email, blogs, IRC
+clients, distributed file storage, wikis, and more.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Benefits to i2p users and app developers:
+{%- endtrans %}
    
+
+
      
+
    • {% trans -%}
+Easy distribution of applications
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Allows innovation and use of additional libraries without worrying about
+increasing the size of i2pupdate.sud
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Support large or special-purpose applications that would never be bundled
+with the I2P installation
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Cryptographically signed and verified applications
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Automatic updates of applications, just like for the router
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Separate initial install and update packages, if desired, for smaller update downloads
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+One-click installation of applications. No more asking users to modify
+wrapper.config or clients.config
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Isolate applications from the base $I2P installation
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Automatic compatibility checking for I2P version, Java version, Jetty
+version, and previous installed application version
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Automatic link addition in console
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Automatic startup of application, including modifying classpath, without requiring a restart
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Automatic integration and startup of webapps into console Jetty instance
+{%- endtrans %}
      • 
+
+
    • {% trans pluginsite=i2pconv('plugins.i2p') -%}
+Facilitate creation of 'app stores' like the one at
+{{ pluginsite }}
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+One-click uninstall
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Language and theme packs for the console
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Bring detailed application information to the router console
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Non-java applications also supported
+{%- endtrans %}
      • 
+
    
+
+
+
    {% trans %}Required I2P version{% endtrans %}
    
+
    {% trans %}0.7.12 or newer.{% endtrans %}
    
+
+
    {% trans %}Installation{% endtrans %}
    
+
    {% trans -%}
+To install and start a plugin, copy the .xpi2p install link to
+the form at the bottom of
+configclients.jsp in
+your router console and click the "install plugin" button.  After a
+plugin is installed and started, a link to the plugin will usually appear at
+the top of your summary bar.
+{%- endtrans %}
    
+
+
    {% trans -%}
+To update a plugin to the latest version, just click the update button on
+configclients.jsp.
+There is also a button to check if the plugin has a more recent version, as
+well as a button to check for updates for all plugins.  Plugins will be checked
+for updates automatically when updating to a new I2P release (not including dev
+builds).
+{%- endtrans %}
    
+
+
+
    {% trans %}Development{% endtrans %}
    
+
    {% trans pluginspec=site_url('docs/spec/plugin'), zzz=i2pconv('zzz.i2p') -%}
+See the latest plugin specification and the
+plugin forum on {{ zzz }}.
+{%- endtrans %}
    
+
+
    {% trans pluginsite=i2pconv('plugins.i2p') -%}
+See also the sources for plugins developed by various people.  Some plugins, such
+as snowman, were developed
+specifically as examples.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Developers wanted! Plugins are a great way to learn more about I2P
+or easily add some feature.
+{%- endtrans %}
    
+
+
    {% trans %}Getting Started{% endtrans %}
    
+
    {% trans url='http://'+i2pconv('trac.i2p2.i2p')+'/browser/plugin/makeplugin.sh?rev=776519571fda0689ef09c42f66e7398f30432e87' -%}
+To create a plugin from an existing binary package you will need to get
+makeplugin.sh from the i2p.scripts branch in monotone.
+{%- endtrans %}
    
+
+
+
    {% trans %}Known Issues{% endtrans %}
    
+
    {% trans -%}
+Note that the router's plugin architecture does NOT currently
+provide any additional security isolation or sandboxing of plugins.
+{%- endtrans %}
    
+
+
      
+
    • {% trans -%}
+Updates of a plugin with included jars (not wars) won't be recognized if
+the plugin was already run, as it requires class loader trickery to flush the
+class cache; a full router restart is required.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+The stop button may be displayed even if there is nothing to stop.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Plugins running in a separate JVM create a logs/ directory in
+$CWD.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+No initial keys are present, except for those of jrandom and zzz (using the
+same keys as for router update), so the first key seen for a signer is
+automatically accepted—there is no signing key authority.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+When deleting a plugin, the directory is not always deleted, especially on
+Windows.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Installing a plugin requiring Java 1.6 on a Java 1.5 machine will result in a
+"plugin is corrupt" message if pack200 compression of the plugin file is used.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Theme and translation plugins are untested.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Disabling autostart doesn't always work.
+{%- endtrans %}
      • 
+
    
+
+
+{% endblock %}
diff --git a/www.i2p2/pages/ports.html b/i2p2www/pages/site/docs/ports.html
similarity index 83%
rename from www.i2p2/pages/ports.html
rename to i2p2www/pages/site/docs/ports.html
index 557746d0..19f0d864 100644
--- a/www.i2p2/pages/ports.html
+++ b/i2p2www/pages/site/docs/ports.html
@@ -1,20 +1,23 @@
-{% extends "_layout.html" %}
-{% block title %}Ports Used by I2P{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Ports Used by I2P{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}May 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9{% endblock %}
 {% block content %}
 
-
    
+
    {% trans -%}
 These are the ports used or reserved by I2P, including those for known plugins,
 common alternates,
 and some typical related applications.
-
    
-Updated May 2012, current for router version 0.9.
-
    
+{%- endtrans %}
    
+
+
    {% trans faq=site_url('faq') -%}
 Note that many of these are not enabled by default.
-There is more information in the FAQ.
+There is more information in the FAQ.
 See also the documentation for individual plugins.
 Plugin authors please add any ports you use here.
 For new plugins, we recommend using the next available port
 in the 766x range.
+{%- endtrans %}
    
 
 
@@ -45,7 +48,7 @@ in the 766x range.
 
-
+
diff --git a/i2p2www/pages/site/docs/protocol/i2cp.html b/i2p2www/pages/site/docs/protocol/i2cp.html
new file mode 100644
index 00000000..00f4eb96
--- /dev/null
+++ b/i2p2www/pages/site/docs/protocol/i2cp.html
@@ -0,0 +1,677 @@
+{% extends "global/layout.html" %}
+{% block title %}I2CP{% endblock %}
+{% block lastupdated %}{% trans %}November 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.3{% endblock %}
+{% block content %}
+
    {% trans -%}
+The I2P Client Protocol (I2CP) exposes a strong separation of concerns between
+the router and any client that wishes to communicate over the network.  It enables
+secure and asynchronous messaging by sending and receiving messages over a 
+single TCP socket, yet never exposing any private keys and authenticating itself
+to the router only through signatures.  With I2CP, a client application tells the
+router who they are (their "destination"), what anonymity, reliability, and 
+latency tradeoffs to make, and where to send messages.  In turn the router uses
+I2CP to tell the client when any messages have arrived, and to request authorization
+for some tunnels to be used.
+{%- endtrans %}
    
+
+
    {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html' -%}
+The protocol itself has only been implemented in Java, to provide the
+Client SDK.
+This SDK is exposed in the i2p.jar package, which implements the client-side of I2CP.
+Clients should never need to access the router.jar package, which contains the
+router itself and the router-side of I2CP.
+{%- endtrans %}
    
+
+
    {% trans streaming=site_url('docs/api/streaming') -%}
+While implementing the client side of I2CP in a non-Java language is certainly feasible,
+a non-Java client would also have to implement the
+streaming library for TCP-style connections.
+Together, implementing I2CP and the streaming library would be a sizable task.
+{%- endtrans %}
    
+
+
    {% trans streaming=site_url('docs/api/streaming'), datagrams=site_url('docs/spec/datagrams'),
+sam=site_url('docs/api/sam'), bob=site_url('docs/api/bob') -%}
+Applications can take advantage of the base I2CP plus the 
+streaming and datagram libraries
+by using the Simple Anonymous Messaging or BOB protocols,
+which do not require clients to deal with any sort of cryptography.
+Also, clients may access the network by one of several proxies -
+HTTP, CONNECT, and SOCKS 4/4a/5.
+Alternatively, Java clients may access those libraries in ministreaming.jar and streaming.jar.
+So there are several options for both Java and non-Java applications.
+{%- endtrans %}
    
+
+
    {% trans elgamalaes=site_url('docs/how/elgamal-aes'),
+cryptography=site_url('docs/how/cryptography'),
+i2cp=site_url('docs/spec/i2cp') -%}
+Client-side end-to-end encryption (encrypting the data over the I2CP connection)
+was disabled in I2P release 0.6,
+leaving in place the ElGamal/AES end-to-end encryption
+which is implemented in the router.
+The only cryptography that client libraries must still implement is
+DSA public/private key signing
+for LeaseSets and
+Session Configurations, and management of those keys.
+{%- endtrans %}
    
+
+
    {% trans -%}
+In a standard I2P installation, port 7654 is used by external java clients to communicate
+with the local router via I2CP.
+By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, set the
+router advanced configuration option i2cp.tcp.bindAllInterfaces=true and restart.
+Clients in the same JVM as the router pass messages directly to the router
+through an internal JVM interface.
+{%- endtrans %}
    
+
+
    {% trans %}I2CP Protocol Specification{% endtrans %}
    
+
    {% trans i2cp=site_url('docs/spec/i2cp') -%}
+Now on the I2CP Specification page.
+{%- endtrans %}
    
+
+
+
    {% trans %}I2CP Initialization{% endtrans %}
    
+
    {% trans i2cp=site_url('docs/spec/i2cp') -%}
+When a client connects to the router, it first sends a single protocol version byte (0x2A).
+Then it sends a GetDate Message and waits for the SetDate Message response.
+Next, it sends a CreateSession Message containing the session configuration.
+It next awaits a RequestLeaseSet Message from the router, indicating that inbound tunnels
+have been built, and responds with a CreateLeaseSetMessage containing the signed LeaseSet.
+The client may now initiate or receive connections from other I2P destinations.
+{%- endtrans %}
    
+
+
    {% trans %}I2CP Options{% endtrans %}
    
+
    {% trans i2cp=site_url('docs/spec/i2cp') -%}
+The following options are traditionally passed to the router via
+a SessionConfig contained in a CreateSession Message or a ReconfigureSession Message.
+{%- endtrans %}
    
+
    
 
    PortUsage
    7662Zzzot Plugin
    
 
    7663?? Plugin ??
    
 
    7664JAMWiki Plugin
    recommended spot for new plugins/applications
    {% trans %}recommended spot for new plugins/applications{% endtrans %}
    
 
    8118Privoxy (reserve)
    
 
    8123Tor Polipo (reserve)
    
 
    8887Old default network port
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    {% trans %}Router-side Options{% endtrans %}
    {% trans %}Option{% endtrans %}{% trans %}As Of Release{% endtrans %}{% trans %}Recommended Arguments{% endtrans %}{% trans %}Allowable Range{% endtrans %}{% trans %}Default{% endtrans %}{% trans %}Description{% endtrans %}
    inbound.quantity {% trans from=1, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=1, to=16 %}{{ from }} to {{ to }}{% endtrans %}2{% trans -%}
+Number of tunnels in.
+Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are not
+currently recommended, as this is untested and is incompatible with older releases.
+{%- endtrans %}
    outbound.quantity
+ {% trans from=1, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}2
+{% trans %}Number of tunnels out{% endtrans %}
    inbound.length
+ {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=7 %}{{ from }} to {{ to }}{% endtrans %}2
+{% trans %}Length of tunnels in{% endtrans %}
    outbound.length
+ {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=7 %}{{ from }} to {{ to }}{% endtrans %}2
+{% trans %}Length of tunnels out{% endtrans %}
    inbound.lengthVariance
+ {% trans from=-1, to=2 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-7, to=7 %}{{ from }} to {{ to }}{% endtrans %}0
+{% trans -%}
+Random amount to add or subtract to the length of tunnels in.
+A positive number x means add a random amount from 0 to x inclusive.
+A negative number -x means add a random amount from -x to x inclusive.
+The router will limit the total length of the tunnel to 0 to 7 inclusive.
+The default variance was 1 prior to release 0.7.6.
+{%- endtrans %}
    outbound.lengthVariance
+ {% trans from=-1, to=2 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-7, to=7 %}{{ from }} to {{ to }}{% endtrans %}0
+{% trans -%}
+Random amount to add or subtract to the length of tunnels out.
+A positive number x means add a random amount from 0 to x inclusive.
+A negative number -x means add a random amount from -x to x inclusive.
+The router will limit the total length of the tunnel to 0 to 7 inclusive.
+The default variance was 1 prior to release 0.7.6.
+{%- endtrans %}
    inbound.backupQuantity
+ {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}0
+{% trans %}Number of redundant fail-over for tunnels in{% endtrans %}
    outbound.backupQuantity
+ {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}0
+{% trans %}Number of redundant fail-over for tunnels out{% endtrans %}
    inbound.nickname
+ string
+ 
+ 
+{% trans -%}
+Name of tunnel - generally used in routerconsole, which will
+use the first few characters of the Base64 hash of the destination by default.
+{%- endtrans %}
    outbound.nickname
+ string
+ 
+ 
+{% trans %}Name of tunnel - generally ignored unless inbound.nickname is unset.{% endtrans %}
    inbound.allowZeroHop
+ true, false
+ 
+true
+{% trans %}If incoming zero hop tunnel is allowed{% endtrans %}
    outbound.allowZeroHop
+ true, false
+ 
+true
+{% trans %}If outgoing zero hop tunnel is allowed{% endtrans %}
    inbound.IPRestriction
+ {% trans from=0, to=4 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=4 %}{{ from }} to {{ to }}{% endtrans %}2
+{% trans -%}
+Number of IP bytes to match to determine if
+two routers should not be in the same tunnel. 0 to disable.
+{%- endtrans %}
    outbound.IPRestriction
+ {% trans from=0, to=4 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=4 %}{{ from }} to {{ to }}{% endtrans %}2
+{% trans -%}
+Number of IP bytes to match to determine if
+two routers should not be in the same tunnel. 0 to disable.
+{%- endtrans %}
    outbound.priority
+0.9.4{% trans from=-25, to=25 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-25, to=25 %}{{ from }} to {{ to }}{% endtrans %}0
+{% trans -%}
+Priority adjustment for outbound messages.
+Higher is higher priority.
+{%- endtrans %}
    i2cp.dontPublishLeaseSet
+ true, false
+ 
+false
+{% trans %}Should generally be set to true for clients and false for servers{% endtrans %}
    i2cp.messageReliability
+  
+BestEffort, None
+BestEffort
+{% trans -%}
+Guaranteed is disabled;
+None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4
+{%- endtrans %}
    i2cp.fastReceive
+0.9.4 
+true, false
+false
+{% trans -%}
+If true, the router just sends the MessagePayload instead
+of sending a MessageStatus and awaiting a ReceiveMessageBegin.
+{%- endtrans %}
    explicitPeers
+  
+ 
+null
+{% trans %}Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only{% endtrans %}
    i2cp.username
+0.8.2string
+ 
+ 
+{% trans -%}
+For authorization, if required by the router.
+If the client is running in the same JVM as a router, this option is not required.
+{%- endtrans %}
    i2cp.password
+0.8.2string
+ 
+ 
+{% trans -%}
+For authorization, if required by the router.
+If the client is running in the same JVM as a router, this option is not required.
+{%- endtrans %}
    crypto.tagsToSend
+0.9.2 
+1-128
+40
+{% trans -%}
+Number of ElGamal/AES Session Tags to send at a time.
+For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower.
+{%- endtrans %}
    crypto.lowTagThreshold
+0.9.2 
+1-128
+30
+{% trans -%}
+Minimum number of ElGamal/AES Session Tags before we send more.
+Recommended: approximately tagsToSend * 2/3
+{%- endtrans %}
    shouldBundleReplyInfo
+0.9.2true, false
+ 
+true
+{% trans -%}
+Set to false to disable ever bundling a reply LeaseSet.
+For clients that do not publish their LeaseSet, this option must be true
+for any reply to be possible. "true" is also recommended for multihomed servers
+with long connection times.
+{%- endtrans %}
+     
+
    {% trans -%}
+Setting to "false" may save significant outbound bandwidth, especially if
+the client is configured with a large number of inbound tunnels (Leases).
+If replies are still required, this may shift the bandwidth burden to
+the far-end client and the floodfill.
+There are several cases where "false" may be appropriate:
+{%- endtrans %}
    
+
      
+
    • {% trans %}Unidirectional communication, no reply required{% endtrans %}
      • 
+
    • {% trans %}LeaseSet is published and higher reply latency is acceptable{% endtrans %}
      • 
+
    • {% trans -%}
+LeaseSet is published, client is a "server", all connections are inbound
+so the connecting far-end destination obviously has the leaseset already.
+Connections are either short, or it is acceptable for latency on a long-lived
+connection to temporarily increase while the other end re-fetches the LeaseSet
+after expiration.
+HTTP servers may fit these requirements.
+{%- endtrans %}
      • 
+
    
+
    inbound.*
+  
+ 
+ 
+{% trans -%}
+Any other options prefixed with "inbound." are stored
+in the "unknown options" properties of the inbound tunnel pool's settings.
+{%- endtrans %}
    outbound.*
+  
+ 
+ 
+{% trans -%}
+Any other options prefixed with "outbound." are stored
+in the "unknown options" properties of the outbound tunnel pool's settings.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Note: Large quantity, length, or variance settings may cause significant performance or reliability problems.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Note: As of release 0.7.7, option names and values must use UTF-8 encoding.
+This is primarily useful for nicknames.
+Prior to that release, options with multi-byte characters were corrupted.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The following options are interpreted on the client side,
+and will be interpreted if passed to the I2PSession via the I2PClient.createSession() call.
+The streaming lib should also pass these options through to I2CP.
+Other implementations may have different defaults.
+{%- endtrans %}
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    {% trans %}Client-side Options{% endtrans %}
    {% trans %}Option{% endtrans %}{% trans %}As Of Release{% endtrans %}{% trans %}Recommended Arguments{% endtrans %}{% trans %}Allowable Range{% endtrans %}{% trans %}Default{% endtrans %}{% trans %}Description{% endtrans %}
    i2cp.tcp.host
+ 
+ 
+ 
+127.0.0.1
+{% trans -%}
+Router hostname.
+If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
+{%- endtrans %}
    i2cp.tcp.port
+ 
+ 
+1-65535
+7654
+{% trans -%}
+Router I2CP port.
+If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
+{%- endtrans %}
    i2cp.SSL
+0.8.3
+true, false
+ 
+false
+{% trans -%}
+Connect to the router using SSL.
+If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
+{%- endtrans %}
    i2cp.gzip
+0.6.5
+true, false
+ 
+true
+{% trans %}Gzip outbound data{% endtrans %}
    i2cp.reduceOnIdle
+0.7.1
+true, false
+ 
+false
+{% trans %}Reduce tunnel quantity when idle{% endtrans %}
    i2cp.closeOnIdle
+0.7.1
+true, false
+ 
+false
+{% trans %}Close I2P session when idle{% endtrans %}
    i2cp.reduceIdleTime
+0.7.1
+1200000
+{% trans num=300000 %}{{ num }} minimum{% endtrans %}
+ 
+{% trans %}(ms) Idle time required (default 20 minutes, minimum 5 minutes){% endtrans %}
    i2cp.closeIdleTime
+0.7.1
+1800000
+{% trans num=300000 %}{{ num }} minimum{% endtrans %}
+ 
+{% trans %}(ms) Idle time required (default 30 minutes){% endtrans %}
    i2cp.reduceQuantity
+0.7.1
+1
+{% trans from=1, to=5 %}{{ from }} to {{ to }}{% endtrans %}1
+{% trans %}Tunnel quantity when reduced (applies to both inbound and outbound){% endtrans %}
    i2cp.encryptLeaseSet
+0.7.1
+true, false
+ 
+false
+{% trans %}Encrypt the lease{% endtrans %}
    i2cp.leaseSetKey
+0.7.1
+ 
+ 
+ 
+{% trans %}Base64 SessionKey (44 characters){% endtrans %}
    i2cp.messageReliability
+ 
+ 
+BestEffort, None
+None
+{% trans -%}
+Guaranteed is disabled;
+None implemented in 0.8.1; None is the default as of 0.9.4
+{%- endtrans %}
    i2cp.fastReceive
+0.9.4
+ 
+true, false
+true
+{% trans -%}
+If true, the router just sends the MessagePayload instead
+of sending a MessageStatus and awaiting a ReceiveMessageBegin.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Note: All arguments, including numbers, are strings. True/false values are case-insensitive strings.
+Anything other than case-insensitive "true" is interpreted as false.
+All option names are case-sensitive.
+{%- endtrans %}
    
+
+
    {% trans %}I2CP Payload Data Format and Multiplexing{% endtrans %}
    
+
    {% trans i2cp=site_url('docs/spec/i2cp') -%}
+The end-to-end messages handled by I2CP (i.e. the data sent by the client in a
+SendMessageMessage
+and received by the client in a
+MessagePayloadMessage)
+are gzipped with a standard 10-byte gzip
+header beginning with 0x1F 0x8B 0x08 as
+specified by RFC 1952.
+As of release 0.7.1, I2P uses ignored portions of the gzip header to include
+protocol, from-port, and to-port information, thus supporting streaming and
+datagrams on the same destination, and allowing query/response using datagrams
+to work reliably in the presence of multiple channels.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The gzip function cannot be completely turned off, however setting i2cp.gzip=false
+turns the gzip effort setting to 0, which may save a little CPU.
+{%- endtrans %}
    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    {% trans %}Bytes{% endtrans %}{% trans %}Content{% endtrans %}
    0-2
+{% trans %}Gzip header{% endtrans %} 0x1F 0x8B 0x08
+
    3
+{% trans %}Gzip flags{% endtrans %}
    4-5
+{% trans %}I2P Source port (Gzip mtime){% endtrans %}
    6-7
+{% trans %}I2P Destination port (Gzip mtime){% endtrans %}
    8
+{% trans %}Gzip xflags{% endtrans %}
    9
+{% trans %}I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS){% endtrans %}
    
+
+
    {% trans -%}
+Data integrity is verified with the standard gzip CRC-32 as
+specified by RFC 1952.
+{%- endtrans %}
    
+
+
+
    {% trans %}Future Work{% endtrans %}
    
+
      
+
    • {% trans -%}
+Implement I2CP and the streaming library in another programming language.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Is the initial Get Date / Set Date handshake required?
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+The current authorization mechanism could be modified to use hashed passwords.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Private Keys are included in the Create Lease Set message,
+are they really required? Revocation is unimplemented.
+{%- endtrans %}
      • 
+
+
    • {% trans pdf1=url_for('static', filename='pdf/I2CP_spec.pdf'), pdf2=url_for('static', filename='pdf/datastructures.pdf') -%}
+Some improvements may be able to use messages previously defined but not implemented.
+For reference, here is the
+I2CP Protocol Specification Version 0.9
+(PDF) dated August 28, 2003.
+That document also references the
+Common Data Structures Specification Version 0.9.
+{%- endtrans %}
      • 
+
    
+
+
+
+{% endblock %}
diff --git a/www.i2p2/pages/i2np.html b/i2p2www/pages/site/docs/protocol/i2np.html
similarity index 56%
rename from www.i2p2/pages/i2np.html
rename to i2p2www/pages/site/docs/protocol/i2np.html
index 480e4b83..02ea85b2 100644
--- a/www.i2p2/pages/i2np.html
+++ b/i2p2www/pages/site/docs/protocol/i2np.html
@@ -1,23 +1,26 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}I2NP{% endblock %}
+{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
 {% block content %}
-Updated August 2010, current as of router version 0.8
-
    I2P Network Protocol (I2NP)
    
-
    
+
    {% trans %}I2P Network Protocol{% endtrans %} (I2NP)
    
+
    {% trans -%}
 The I2P Network Protocol (I2NP),
 which is sandwiched between I2CP and the various I2P transport protocols, manages the
 routing and mixing of messages between routers, as well as the selection of what
 transports to use when communicating with a peer for which there are multiple
 common transports supported.
-
    
+{%- endtrans %}
    
 
-
    I2NP Definition
    
-
    
+
    {% trans %}I2NP Definition{% endtrans %}
    
+
    {% trans -%}
 I2NP (I2P Network Protocol) messages can be used for one-hop, router-to-router, point-to-point messages.
 By encrypting and wrapping messages in other messages, they can be sent in a secure way
 through multiple hops to the ultimate destination.
 Priority is only used locally at the origin, i.e. when queuing for outbound delivery.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Both the NTCP and UDP transports implement priority transmission,
 but in quite different manners.
 UDP has complex code with queues for each priority, however it treats
@@ -27,42 +30,49 @@ These are global queues for all peers.
 NTCP has a trivial linear search for the highest priority within
 each buffer for a particular peer.
 This is much less effective.
+{%- endtrans %}
    
 
-
    Message Format
    
-
    
+
    {% trans %}Message Format{% endtrans %}
    
 
 
-
+
+
+
+
+
    FieldBytes
-
    Unique ID4
-
    Expiration8
-
    Payload Length2
-
    Checksum1
-
    Payload0 - 61.2KB
+
    {% trans %}Field{% endtrans %}{% trans %}Bytes{% endtrans %}
    {% trans %}Unique ID{% endtrans %}4
    {% trans %}Expiration{% endtrans %}8
    {% trans %}Payload Length{% endtrans %}2
    {% trans %}Checksum{% endtrans %}1
    {% trans %}Payload{% endtrans %}0 - 61.2KB
    
 
    
 
-
    
+
    {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
 While the maximum payload size is nominally 64KB, the size is further constrained by the
-method of fragmenting I2NP messages into multiple 1KB tunnel messages as described in
-tunnel-alt.html.
+method of fragmenting I2NP messages into multiple 1KB tunnel messages as described on
+the tunnel implementation page.
 The maximum number of fragments is 64, and the message may not be perfectly aligned,
 So the message must nominally fit in 63 fragments.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The maximum size of an initial fragment is 956 bytes (assuming TUNNEL delivery mode);
 the maximum size of a follow-on fragment is 996 bytes.
 Therefore the maximum size is approximately 956 + (62 * 996) = 62708 bytes, or 61.2 KB.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 In addition, the transports may have additional restrictions.
 NTCP currently limits to 16KB - 6 = 16378 bytes but this will be increased in a future release.
 The SSU limit is approximately 32 KB.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Note that these are not the limits for datagrams that the client sees, as the
 router may bundle a reply leaseset and/or session tags together with the client message
 in a garlic message. The leaseset and tags together may add about 5.5KB.
 Therefore the current datagram limit is about 10KB. This limit will be
 increased in a future release.
+{%- endtrans %}
    
 
-
    Message Types
    
+
    {% trans %}Message Types{% endtrans %}
    
+
    {% trans -%}
 Higher-numbered priority is higher priority.
 The majority of traffic is TunnelDataMessages (priority 400),
 so anything above 400 is essentially high priority, and
@@ -71,115 +81,162 @@ Note also that many of the messages are generally routed
 through exploratory tunnels, not client tunnels, and
 therefore may not be in the same queue unless the
 first hops happen to be on the same peer.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Also, not all message types are sent unencrypted.
 For example, when testing a tunnel, the router wraps a
 DeliveryStatusMessage, which is wrapped in a GarlicMessage,
 which is wrapped in a DataMessage.
-
    
+{%- endtrans %}
    
 
 
 
-
+
+
+
+
+
+
+
 
+
+
 
+
+
 
+
+
 
+
 
+
+
 
+
+
 
+
+
 
+
 
+
+
 
+
 
+
+
 
+
+
+
    MessageTypePayload LengthPriorityComments
+
    {% trans %}Message{% endtrans %}{% trans %}Type{% endtrans %}{% trans %}Payload Length{% endtrans %}{% trans %}Priority{% endtrans %}{% trans %}Comments{% endtrans %}
    
 DatabaseLookupMessage
 2
  
 100/400
-400 normally; 100 if from HarvesterJob and sent directly;
+{% trans -%}
+400 normally; 100 if from HarvesterJob and sent directly;
 400 for a router lookup
+{%- endtrans %}
    
 DatabaseSearchReplyMessage
 3
 Typ. 161
 300
-Size is 65 + 32*(number of hashes) where typically, the hashes for
+{% trans -%}
+Size is 65 + 32*(number of hashes) where typically, the hashes for
 three floodfill routers are returned.
+{%- endtrans %}
    
 DatabaseStoreMessage
 1
-Varies
+{% trans %}Varies{% endtrans %}
 100/400
-Usually 100 (why?)
+{% trans -%}
+Usually 100 (why?)
 Size is 898 bytes for a typical 2-lease leaseSet.
 RouterInfo structures are compressed, and size varies; however
 there is a continuing effort to reduce the amount of data published in a RouterInfo
 as we approach release 1.0.
+{%- endtrans %}
    
 DataMessage
 20
 4 - 62080
 400
 
+
    
 DeliveryStatusMessage
 10
 12
  
-Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage
+{% trans %}Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage{% endtrans %}
    
-GarlicMessage
+GarlicMessage
 11
  
  
-Generally wrapped in a DataMessage -
+{% trans -%}
+Generally wrapped in a DataMessage -
 but when unwrapped, given a priority of 100 by the forwarding router
+{%- endtrans %}
    
-TunnelBuildMessage
+TunnelBuildMessage
 21
 4224
 300/500
-Usually 500 (why?)
+{% trans %}Usually 500 (why?){% endtrans %}
    
-TunnelBuildReplyMessage
+TunnelBuildReplyMessage
 22
 4224
 300
 
+
    
 TunnelDataMessage
 18
 1028
 400
-The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was
-    reduced to 200 as of release 0.6.1.33.
-    Outbound gateway messages (i.e. those originated locally) remains at 400.
+{% trans -%}
+The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was
+reduced to 200 as of release 0.6.1.33.
+Outbound gateway messages (i.e. those originated locally) remains at 400.
+{%- endtrans %}
    
 TunnelGatewayMessage
 19
  
 300/400
 
+
    
 VariableTunnelBuildMessage
 23
 1057 - 4225
 300/500
-Shorter TunnelBuildMessage as of 0.7.12
+{% trans %}Shorter TunnelBuildMessage as of 0.7.12{% endtrans %}
    
 VariableTunnelBuildReplyMessage
 24
 1057 - 4225
 300
-Shorter TunnelBuildReplyMessage as of 0.7.12
-
    
-Others listed in
-2003 Spec
+{% trans %}Shorter TunnelBuildReplyMessage as of 0.7.12{% endtrans %}
    {% trans pdf=url_for('static', filename='pdf/I2NP_spec.pdf') -%}
+Others listed in 2003 Spec
+{%- endtrans %}
 0,4-9,12
  
  
-Obsolete, Unused
+{% trans %}Obsolete, Unused{% endtrans %}
+
    
 
    
 
-
    Full Protocol Specification
    
-On the I2NP Specification page.
+
    {% trans %}Full Protocol Specification{% endtrans %}
    
+
    {% trans i2npspec=site_url('docs/spec/i2np'), commonstructures=site_url('docs/spec/common-structures') -%}
+On the I2NP Specification page.
 See also the
-Common Data Structure Specification page.
+Common Data Structure Specification page.
+{%- endtrans %}
    
 
-
    Future Work
    
-
    
+
    {% trans %}Future Work{% endtrans %}
    
+
    {% trans -%}
 It isn't clear whether the current priority scheme is generally effective,
 and whether the priorities for various messages should be adjusted further.
 This is a topic for further research, analysis and testing.
+{%- endtrans %}
    
 
 {% endblock %}
diff --git a/i2p2www/pages/site/docs/protocol/index.html b/i2p2www/pages/site/docs/protocol/index.html
new file mode 100644
index 00000000..d2869502
--- /dev/null
+++ b/i2p2www/pages/site/docs/protocol/index.html
@@ -0,0 +1,121 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Protocol Stack{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
+{% block content %}
+
+
    {% trans docs=site_url('docs') -%}
+Here is the protocol stack for I2P.
+See also the Index to Technical Documentation.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Each of the layers in the stack provides extra capabilities.
+The capabilities are listed below, starting at the bottom of the protocol stack.
+{%- endtrans %}
    
+  
      
+    
    • 
+        {% trans %}Internet Layer:{% endtrans %}
+        
      
+        {% trans %}IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery.{% endtrans %}
+    
      • 
+    
    • 
+        {% trans %}Transport Layer:{% endtrans %}
+        
      
+        {% trans %}TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet.{% endtrans %}
+        
      
+        {% trans %}UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet.{% endtrans %}
+    
      • 
+    
    • 
+{% trans -%}
+I2P Transport Layer: provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection.
+Two protocols are implemented to provide these capabilities. NTCP builds on top of TCP, while SSU uses UDP.
+{%- endtrans %}
+        
      
+        NTCP: {% trans %}NIO-based TCP{% endtrans %}
+        
      
+        SSU: {% trans %}Secure Semi-reliable UDP{% endtrans %}
+    
      • 
+    
    • 
+        {% trans %}I2P Tunnel Layer: provide full encrypted tunnel connections.{% endtrans %}
+        
      
+{% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%}
+Tunnel messages: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery.
+The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key),
+so it will be forwarded.
+{%- endtrans %}
+        
      
+{% trans i2np=site_url('docs/protocol/i2np') -%}
+I2NP messages: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages.
+{%- endtrans %}
+    
      • 
+    
    • 
+        {% trans %}I2P Garlic Layer: provide encrypted and anonymous end-to-end I2P message delivery.{% endtrans %}
+        
      
+{% trans i2np=site_url('docs/protocol/i2np') -%}
+I2NP messages: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous.
+{%- endtrans %}
+    
      • 
+
    
+
+
    {% trans -%}
+The following layers are strictly speaking no longer part of the I2P Protocol stack, they are not part of the core 'I2P router' functionality.
+However, each of these layers adds additional functionality, to allow applications simple and convenient I2P usage.
+{%- endtrans %}
    
+
      
+    
    • 
+        {% trans %}I2P Client Layer: allow any client to use I2P functionality, without requiring the direct use of the router API.{% endtrans %}
+        
      
+{% trans i2cp=site_url('docs/protocol/i2cp') -%}
+I2CP: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket.
+{%- endtrans %}
+    
      • 
+    
    • 
+        {% trans %}I2P End-to-end Transport Layer: allow TCP- or UDP-like functionality on top of I2P.{% endtrans %}
+        
      
+{% trans streaming=site_url('docs/api/streaming') -%}
+Streaming Library: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P.
+{%- endtrans %}
+        
      
+{% trans datagrams=site_url('docs/spec/datagrams') -%}
+Datagram Library: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P.
+{%- endtrans %}
+    
      • 
+    
    • 
+        {% trans %}I2P Application Interface Layer: additional (optional) libraries allowing easier implementations on top of I2P.{% endtrans %}
+        
      
+        I2PTunnel
+        
      
+        SAM/SAMv2/SAMv3(*),
+        BOB        
+    
      • 
+    
    • 
+        {% trans %}I2P Application Proxy Layer: proxy systems.{% endtrans %}
+        
      
+        {% trans socks=site_url('docs/api/socks') %}HTTP Client/Server, IRC Client, SOCKS, Streamr{% endtrans %}
+    
      • 
+  
    
+
+
    {% trans -%}
+Finally, what could be considered the 'I2P application layer', is a large number of applications on top of I2P.
+We can order this based on the I2P stack layer they use.
+{%- endtrans %}
    
+
      
+    
    • {% trans %}Streaming/datagram applications: i2psnark, Syndie, i2phex...{% endtrans %}
      • 
+    
    • {% trans %}SAM/BOB applications: IMule, i2p-bt, i2prufus, Robert...{% endtrans %}
      • 
+    
    • {% trans plugins=site_url('docs/plugins') %}Other I2P applications: Syndie, EepGet, plugins...{% endtrans %}
      • 
+    
    • {% trans %}Regular applications: Jetty, Apache, Monotone, CVS, browsers, e-mail...{% endtrans %}
      • 
+
    
+
+    
    
+        {{ _('I2P Network stack') }}
+        

    
+        {% trans %}Figure 1: The layers in the I2P Network stack.{% endtrans %}
+    
    
+
    
+
+
    
+* {% trans %}Note: SAM/SAMv2 can use both the streaming lib and datagrams.{% endtrans %}
+
    
+
+{% endblock %}
diff --git a/www.i2p2/pages/blockfile.html b/i2p2www/pages/site/docs/spec/blockfile.html
similarity index 73%
rename from www.i2p2/pages/blockfile.html
rename to i2p2www/pages/site/docs/spec/blockfile.html
index ec25cf56..5077195a 100644
--- a/www.i2p2/pages/blockfile.html
+++ b/i2p2www/pages/site/docs/spec/blockfile.html
@@ -1,17 +1,17 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Blockfile Specification{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}I2P Blockfile Specification{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}January 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.12{% endblock %}
 {% block content %}
-
    
-Blockfile and Hosts Database Specification
-
    
-
     
-Page last updated January 2012, current as of router version 0.8.12
-
    Overview
    
-
     
+
    {% trans %}Blockfile and Hosts Database Specification{% endtrans %}
    
+
    {% trans %}Overview{% endtrans %}
    
+
    {% trans naming=site_url('docs/naming') -%} 
 This document specifies
 the I2P blockfile file format
-and the tables in the hostsdb.blockfile used by the Blockfile Naming Service.
-
    
+and the tables in the hostsdb.blockfile used by the Blockfile Naming Service.
+{%- endtrans %}
    
+
+
    {% trans -%}
 The blockfile provides fast Destination lookup in a compact format. While the blockfile page overhead is substantial,
 the destinations are stored in binary rather than in Base 64 as in the hosts.txt format.
 In addition, the blockfile provides the capability of arbitrary metadata storage
@@ -19,30 +19,37 @@ In addition, the blockfile provides the capability of arbitrary metadata storage
 The metadata may be used in the future to provide advanced addressbook features.
 The blockfile storage requirement is a modest increase over the hosts.txt format, and the blockfile provides
 approximately 10x reduction in lookup times.
-
    
+{%- endtrans %}
    
+
+
    {% trans url='http://www.metanotion.net/software/sandbox/block.html' -%}
 A blockfile is simply on-disk storage of multiple sorted maps (key-value pairs),
 implemented as skiplists.
 The blockfile format is adopted from the
-Metanotion Blockfile Database.
+Metanotion Blockfile Database.
 First we will define the file format, then the use of that format by the BlockfileNamingService.
+{%- endtrans %}
    
 
-
    Blockfile Format
    
-
    
+
    {% trans %}Blockfile Format{% endtrans %}
    
+
    {% trans -%}
 The original blockfile spec was modified to add magic numbers to each page.
 The file is structured in 1024-byte pages. Pages are numbered starting from 1.
 The "superblock" is always at page 1, i.e. starting at byte 0 in the file.
 The metaindex skiplist is always at page 2, i.e. starting at byte 1024 in the file.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 All 2-byte integer values are unsigned.
 All 4-byte integer values (page numbers) are signed and negative values are illegal.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The database is designed to be opened and accessed by a single thread.
 The BlockfileNamingService provides synchronization.
-
    
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 Superblock format:
-
    
+{%- endtrans %}
    
 
     Byte	Contents
 0-5	Magic number	0x3141de493250 ("1A" 0xde "I2P")
@@ -55,9 +62,9 @@ Byte	Contents
 24-1023	unused
 
    
 
-
    
+
    {% trans -%}
 Skip list block page format:
-
    
+{%- endtrans %}
    
 
     Byte	Contents
 0-7	Magic number	0x536b69704c697374 "SkipList"
@@ -70,10 +77,10 @@ Byte	Contents
 
    
 
 
-
    
+
    {% trans -%}
 Skip level block page format is as follows.
 All levels have a span. Not all spans have levels.
-
    
+{%- endtrans %}
    
 
     Byte	Contents
 0-7	Magic number	0x42534c6576656c73 "BSLevels"
@@ -85,12 +92,12 @@ remaining bytes unused
 
    
 
 
-
    
+
    {% trans -%}
 Skip span block page format is as follows.
 Key/value structures are sorted by key within each span and across all spans.
 Key/value structures are sorted by key within each span.
 Spans other than the first span may not be empty.
-
    
+{%- endtrans %}
    
 
     Byte	Contents
 0-3	Magic number	0x5370616e "Span"
@@ -102,9 +109,9 @@ Byte	Contents
 20-1023	key/value structures
 
    
 
-
    
+
    {% trans -%}
 Span Continuation block page format:
-
    
+{%- endtrans %}
    
 
     Byte	Contents
 0-3	Magic number	0x434f4e54 "CONT"
@@ -113,14 +120,14 @@ Byte	Contents
 
    
 
 
-
    
+
    {% trans -%}
 Key/value structure format is as follows.
 Key and value lengths must not be split across pages, i.e. all 4 bytes must be on the same page.
 If there is not enough room the last 1-3 bytes of a page are unused and the lengths will
 be at offset 8 in the continuation page.
 Key and value data may be split across pages.
 Max key and value lengths are 65535 bytes.
-
    
+{%- endtrans %}
    
 
     Byte	Contents
 0-1	key length in bytes
@@ -129,9 +136,9 @@ Byte	Contents
 	value data
 
    
 
-
    
+
    {% trans -%}
 Free list block page format:
-
    
+{%- endtrans %}
    
 
     Byte	Contents
 0-7	Magic number	0x2366724c69737423 "#frList#"
@@ -141,32 +148,32 @@ Byte	Contents
 
    
 
 
-
    
+
    {% trans -%}
 Free page block format:
-
    
+{%- endtrans %}
    
 
     Byte	Contents
 0-7	Magic number	0x7e2146524545217e "~!FREE!~"
 8-1023	unused
 
    
 
-
    
+
    {% trans -%}
 The metaindex (located at page 2) is a mapping of US-ASCII strings to 4-byte integers.
 The key is the name of the skiplist and the value is the page index of the skiplist.
-
    
+{%- endtrans %}
    
 
-
    Blockfile Naming Service Tables
    
-
    
+
    {% trans %}Blockfile Naming Service Tables{% endtrans %}
    
+
    {% trans -%}
 The tables created and used by the BlockfileNamingService are as follows.
 The maximum number of entries per span is 16.
-
    
+{%- endtrans %}
    
 
-
    Properties Skiplist
    
-
    
-"%%__INFO__%%" is the master database skiplist with  String/Properties key/value entries containing only one entry:
-
    
+
    {% trans %}Properties Skiplist{% endtrans %}
    
+
    {% trans -%}
+"%%__INFO__%%" is the master database skiplist with String/Properties key/value entries containing only one entry:
+{%- endtrans %}
    
 
    -    "info": a Properties (UTF-8 String/String Map), serialized as a Mapping:
+    "info": a Properties (UTF-8 String/String Map), serialized as a Mapping:
             "version":   "2"
             "created":   Java long time (ms)
             "upgraded":  Java long time (ms) (as of database version 2)
@@ -174,14 +181,14 @@ The maximum number of entries per span is 16.
                          searched in-order for lookups. Almost always "privatehosts.txt,userhosts.txt,hosts.txt".
 
    
 
-
    Reverse Lookup Skiplist
    
-
    
+
    {% trans %}Reverse Lookup Skiplist{% endtrans %}
    
+
    {% trans -%}
 "%%__REVERSE__%%" is the reverse lookup skiplist with Integer/Properties key/value entries
     (as of database version 2):
-
    
+{%- endtrans %}
    
 
         The skiplist keys are 4-byte Integers, the first 4 bytes of the hash of the Destination.
-    The skiplist values are each a Properties (a UTF-8 String/String Map) serialized as a Mapping
+    The skiplist values are each a Properties (a UTF-8 String/String Map) serialized as a Mapping
         There may be multiple entries in the properties, each one is a reverse mapping,
            as there may be more than one hostname for a given destination,
            or there could be collisions with the same first 4 bytes of the hash.
@@ -189,28 +196,30 @@ The maximum number of entries per span is 16.
         Each property value is the empty string.
 
    
 
-
    hosts.txt, userhosts.txt, and privatehosts.txt Skiplists
    
-
    
+
    {% trans %}hosts.txt, userhosts.txt, and privatehosts.txt Skiplists{% endtrans %}
    
+
    {% trans -%}
 For each host database, there is a skiplist containing
 the hosts for that database.
 The keys/values in these skiplists are as follows:
-
    
+{%- endtrans %}
    
 
          key:    a UTF-8 String (the hostname)
-     value:  a DestEntry, which is a Properties (a UTF-8 String/String Map) serialized as a Mapping
-             followed by a binary Destination (serialized as usual).
+     value:  a DestEntry, which is a Properties (a UTF-8 String/String Map) serialized as a Mapping
+             followed by a binary Destination (serialized as usual).
 
    
 
-
    
+
    {% trans -%}
 The DestEntry Properties typically contains:
-
    
+{%- endtrans %}
    
 
                 "a":     The time added (Java long time in ms)
             "s":     The original source of the entry (typically a file name or subscription URL)
             others:  TBD
 
    
-
    
+
+
    {% trans -%}
 Hostname keys are stored in lower-case and always end in ".i2p".
+{%- endtrans %}
    
 
 
 {% endblock %}
diff --git a/www.i2p2/pages/common_structures_spec.html b/i2p2www/pages/site/docs/spec/common-structures.html
similarity index 55%
rename from www.i2p2/pages/common_structures_spec.html
rename to i2p2www/pages/site/docs/spec/common-structures.html
index 701116fa..7dacf0e6 100644
--- a/www.i2p2/pages/common_structures_spec.html
+++ b/i2p2www/pages/site/docs/spec/common-structures.html
@@ -1,181 +1,184 @@
-{% extends "_layout.html" %}
-{% block title %}Common structure Specification{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Common structure Specification{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}March 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.13{% endblock %}
 {% block content %}
-Updated March 2012, current as of router version 0.8.13
-
    Data types Specification
    
-
    
-  This document describes some data types common to all I2P protocols, like
-  I2NP,
-  I2CP,
-  SSU,
-  etc.
-
    
+
    {% trans %}Data types Specification{% endtrans %}
    
+
    {% trans i2np=site_url('docs/protocol/i2np'),
+i2cp=site_url('docs/protocol/i2cp'),
+ssu=site_url('docs/transport/ssu') -%}
+This document describes some data types common to all I2P protocols, like
+I2NP, I2CP,
+SSU, etc.
+{%- endtrans %}
    
 
 
    Integer
    
-
    Description
    
-
    
-  Represents a non-negative integer.
-
    
-
    Contents
    
-
    
-  1 to 8 bytes in network byte order representing an unsigned integer
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+Represents a non-negative integer.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+1 to 8 bytes in network byte order representing an unsigned integer
+{% endtrans %}
    
 
 
    Date
    
-
    Description
    
-
    
-  The number of milliseconds since midnight on January 1, 1970 in the GMT timezone.
-  If the number is 0, the date is undefined or null.
-
    
-
    Contents
    
-
    
-  8 byte Integer
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+The number of milliseconds since midnight on January 1, 1970 in the GMT timezone.
+If the number is 0, the date is undefined or null.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+8 byte Integer
+{% endtrans %}
    
 
 
    String
    
-
    Description
    
-
    
-  Represents a UTF-8 encoded string.
-
    
-
    Contents
    
-
    
-  1 or more bytes where the first byte is the number of bytes (not characters!)
-  in the string and the remaining 0-255 bytes are the non-null terminated UTF-8 encoded character array.
-  Length limit is 255 bytes (not characters). Length may be 0.
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+Represents a UTF-8 encoded string.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+1 or more bytes where the first byte is the number of bytes (not characters!)
+in the string and the remaining 0-255 bytes are the non-null terminated UTF-8 encoded character array.
+Length limit is 255 bytes (not characters). Length may be 0.
+{% endtrans %}
    
 
 
    Boolean
    
-
    Description
    
-
    
-  A boolean value, supporting null/unknown representation
-  0=false, 1=true, 2=unknown/null
-
    
-
    Contents
    
-
    
-  1 byte Integer
-
    
-
    Notes
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+A boolean value, supporting null/unknown representation
+0=false, 1=true, 2=unknown/null
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+1 byte Integer
+{% endtrans %}
    
+
    {% trans %}Notes{% endtrans %}
    
+
    {% trans -%}
 Deprecated - unused
+{% endtrans %}
    
 
 
    PublicKey
    
-
    Description
    
-
    
-  This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in
-  the cryptography specification.
-
    
-
    Contents
    
-
    
-  256 bytes
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in
+the cryptography specification.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+256 bytes
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    PrivateKey
    
-
    Description
    
-
    
-  This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in
-  the cryptography specification.
-
    
-
    Contents
    
-
    
-  256 bytes
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in
+the cryptography specification.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+256 bytes
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    SessionKey
    
-
    Description
    
-
    
-  This structure is used for AES256 encryption and decryption.
-
    
-
    Contents
    
-
    
-  32 bytes
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+This structure is used for AES256 encryption and decryption.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+32 bytes
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    SigningPublicKey
    
-
    Description
    
-
    
-  This structure is used for verifying DSA signatures.
-
    
-
    Contents
    
-
    
-  128 bytes
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+This structure is used for verifying DSA signatures.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+128 bytes
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    SigningPrivateKey
    
-
    Description
    
-
    
-  This structure is used for creating DSA signatures.
-
    
-
    Contents
    
-
    
-  20 bytes
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+This structure is used for creating DSA signatures.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+20 bytes
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    Signature
    
-
    Description
    
-
    
-  This structure represents the DSA signature of some data.
-
    
-
    Contents
    
-
    
-  40 bytes
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
+This structure represents the DSA signature of some data.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+40 bytes
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    Hash
    
-
    Description
    
-
    
-  Represents the SHA256 of some data.
-
    
-
    Contents
    
-
    
-  32 bytes
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+Represents the SHA256 of some data.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+32 bytes
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    Session Tag
    
-
    Description
    
-
    
-  A random number
-
    
-
    Contents
    
-
    
-  32 bytes
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+A random number
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+32 bytes
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    TunnelId
    
-
    Description
    
-
    
-  Defines an identifier that is unique to each router in a tunnel.
-
    
-
    Contents
    
-
    
-  4 byte Integer
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+Defines an identifier that is unique to each router in a tunnel.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+4 byte Integer
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
    Certificate
    
-
    Description
    
-
    
-  A certificate is a container for various receipts or proof of works used throughout the I2P network.
-
    
-
    Contents
    
-
    
-  1 byte Integer specifying certificate type, followed by a 2 Integer specifying the size of the certificate payload, then that many bytes.
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+A certificate is a container for various receipts or proof of works used throughout the I2P network.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+1 byte Integer specifying certificate type, followed by a 2 Integer specifying the size of the certificate payload, then that many bytes.
+{% endtrans %}
    
 
     {% filter escape %}
 +----+----+----+----+----+--//
@@ -199,31 +202,38 @@ payload :: data
 {% endfilter %}
 
    
 
-
    Notes
    
+
    {% trans %}Notes{% endtrans %}
    
 
      
-
    • 
+
    • {% trans -%}
 For Router Identities, the Certificate is always NULL, no others are currently implemented.
-
    • 
-For Garlic Cloves, the Certificate is always NULL, no others are currently implemented.
-
    • 
-For Garlic Messages, the Certificate is always NULL, no others are currently implemented.
-
    • 
+{%- endtrans %}
      • 
+
+
    • {% trans i2np=site_url('docs/spec/i2np') -%}
+For Garlic Cloves, the Certificate is always NULL, no others are currently implemented.
+{%- endtrans %}
      • 
+
+
    • {% trans i2np=site_url('docs/spec/i2np') -%}
+For Garlic Messages, the Certificate is always NULL, no others are currently implemented.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
 For Destinations, the Certificate may be non-NULL,
 however non-NULL certs are not widely used, and any checking is left to the application-level.
-
    
+{%- endtrans %}
+
 
 
    Javadoc
    
 
 
 
    Mapping
    
-
    Description
    
-
    
-   A set of key/value mappings or properties
-
    
-
    Contents
    
-
    
-   A 2-byte size Integer followed by a series of String=String; pairs
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+A set of key/value mappings or properties
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+A 2-byte size Integer followed by a series of String=String; pairs
+{% endtrans %}
    
 
     {% filter escape %}
 +----+----+----+----+----+----+----+----+
@@ -248,40 +258,51 @@ val string :: String
 {% endfilter %}
 
    
 
-
    Notes
    
+
    {% trans %}Notes{% endtrans %}
    
 
      
-
    • 
+
    • {% trans -%}
 The encoding isn't optimal - we either need the '=' and ';' characters, or the string lengths, but not both
-
    • 
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
 Some documentation says that the strings may not include '=' or ';' but this encoding supports them
-
    • 
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
 Strings are defined to be UTF-8 but in the current implementation, I2CP uses UTF-8 but I2NP does not.
 For example,
 UTF-8 strings in a RouterInfo options mapping in a I2NP Database Store Message will be corrupted.
-
    • 
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
 Mappings contained in I2NP messages (i.e. in a RouterAddress or RouterInfo)
 must be sorted by key so that the signature will be invariant.
-
    • 
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
 Key and value string length limits are 255 bytes (not characters) each, plus the length byte. Length byte may be 0.
-
    • 
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
 Total length limit is 65535 bytes, plus the 2 byte size field, or 65537 total.
+{%- endtrans %}
      • 
 
    
 
 
    Javadoc
    
 
 
 
-
    Common structure specification
    
+
    {% trans %}Common structure specification{% endtrans %}
    
 
 
    RouterIdentity
    
-
    Description
    
-
    
-  Defines the way to uniquely identify a particular router
-
    
-
    Contents
    
-
    
-  PublicKey followed by SigningPublicKey and then a Certificate
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+Defines the way to uniquely identify a particular router
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+PublicKey followed by SigningPublicKey and then a Certificate
+{% endtrans %}
    
 
     {% filter escape %}
 +----+----+----+----+----+----+----+----+
@@ -317,20 +338,22 @@ Total length: 387+ bytes
 {% endfilter %}
 
    
 
-
    Notes
    
+
    {% trans %}Notes{% endtrans %}
    
+
    {% trans -%}
 The certificate for a RouterIdentity is currently unused and is always NULL.
+{%- endtrans %}
    
 
 
    Javadoc
    
 
 
    Destination
    
-
    Description
    
-
    
-  A Destination defines a particular endpoint to which messages can be directed for secure delivery.
-
    
-
    Contents
    
-
    
-  PublicKey followed by a SigningPublicKey and then a Certificate
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+A Destination defines a particular endpoint to which messages can be directed for secure delivery.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+PublicKey followed by a SigningPublicKey and then a Certificate
+{% endtrans %}
    
 
     {% filter escape %}
 +----+----+----+----+----+----+----+----+
@@ -369,15 +392,15 @@ Total length: 387+ bytes
 
    Javadoc
    
 
 
    Lease
    
-
    Description
    
-
    
-  Defines the authorization for a particular tunnel to receive messages targeting a Destination.
-
    
-
    Contents
    
-
    
-  SHA256 Hash of the
-  RouterIdentity of the gateway router, then the TunnelId, and finally an end Date
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+Defines the authorization for a particular tunnel to receive messages targeting a Destination.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+SHA256 Hash of the
+RouterIdentity of the gateway router, then the TunnelId, and finally an end Date
+{% endtrans %}
    
 
     {% filter escape %}
 +----+----+----+----+----+----+----+----+
@@ -405,27 +428,29 @@ end_date :: Date
 {% endfilter %}
 
    
 
-
    Notes
    
+
    {% trans %}Notes{% endtrans %}
    
 
      
-
    • 
+
    • {% trans -%}
 Total size: 44 bytes
-
    
+{%- endtrans %}
+
 
 
 
    Javadoc
    
 
 
    LeaseSet
    
-
    Description
    
-
    
-  Contains all of the currently authorized Leases for a particular Destination, the PublicKey to which garlic messages can be encrypted,
-  and then the public key that can be used to revoke this particular version of the structure. The LeaseSet is one of the two structures stored in the network database(
-  the other being RouterInfo), and is keyed under the SHA256 of the contained Destination.
-
    
-
    Contents
    
-
    
-  Destination, followed by a PublicKey for encryption, then a SigningPublicKey which can be used to revoke this version of the LeaseSet,
-  then a 1 byte Integer specifying how many Lease structures are in the set, followed by the actual Lease structures and finally a Signature  of the previous
-  bytes signed by the Destination's SigningPrivateKey
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+Contains all of the currently authorized Leases for a particular Destination, the PublicKey to which garlic messages can be encrypted,
+and then the public key that can be used to revoke this particular version of the structure. The LeaseSet is one of the two structures stored in the network database(
+the other being RouterInfo), and is keyed under the SHA256 of the contained Destination.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+Destination, followed by a PublicKey for encryption, then a SigningPublicKey which can be used to revoke this version of the LeaseSet,
+then a 1 byte Integer specifying how many Lease structures are in the set, followed by the actual Lease structures and finally a Signature  of the previous
+bytes signed by the Destination's SigningPrivateKey
+{%- endtrans %}
    
 
     {% filter escape %}
 +----+----+----+----+----+----+----+----+
@@ -513,35 +538,43 @@ signature :: Signature
 {% endfilter %}
 
    
 
-
    Notes
    
-
    • 
+
      {% trans %}Notes{% endtrans %}
      
+
        
+
      • {% trans -%}
 The public key of the destination was used for the old i2cp-to-i2cp encryption
 which was disabled in version 0.6, it is currently unused?
-
      • 
-The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption.
+{%- endtrans %}
        • 
+
+
      • {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
+The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption.
 It is currently generated anew at every router startup, it is not persistent.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 The signature may be verified using the signing public key of the destination.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 The signing_key is currently unused. It was intended for LeaseSet revocation, which is unimplemented.
 It is currently generated anew at every router startup, it is not persistent.
-
      
+{%- endtrans %}
      • 
+
    
 
 
    Javadoc
    
 
 
 
 
    RouterAddress
    
-
    Description
    
-
    
-  This structure defines the means to contact a router through a transport protocol.
-
    
-
    Contents
    
-
    
-  1 byte Integer defining the relative cost of using the address, where 0 is free and 255 is expensive, followed by the expiration Date after which the address should not be used, or if null, the address never expires.
-  After that comes a String defining the transport protocol this router address uses. Finally there is a Mapping containing all of the transport specific options necessary to establish the connection, such as
-  IP address, port number, email address, URL, etc.
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+This structure defines the means to contact a router through a transport protocol.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+1 byte Integer defining the relative cost of using the address, where 0 is free and 255 is expensive, followed by the expiration Date after which the address should not be used, or if null, the address never expires.
+After that comes a String defining the transport protocol this router address uses. Finally there is a Mapping containing all of the transport specific options necessary to establish the connection, such as
+IP address, port number, email address, URL, etc.
+{% endtrans %}
    
 
     {% filter escape %}
 +----+
@@ -572,27 +605,30 @@ options :: Mapping
 {% endfilter %}
 
    
 
-
    Notes
    
+
    {% trans %}Notes{% endtrans %}
    
 
      
-
    • 
+
    • {% trans -%}
 Cost is typically 5 or 6 for SSU, and 10 or 11 for NTCP.
-
    • 
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
 Expiration is currently unused, always null (all zeroes))
-
    
+{%- endtrans %}
+
 
 
 
    Javadoc
    
 
 
    RouterInfo
    
-
    Description
    
-
    
-  Defines all of the data that a router wants to publish for the network to see. The RouterInfo is one of two structures stored in the network database(the other being LeaseSet, and is keyed under the SHA256 of
-  the contained RouterIdentity.
-
    
-
    Contents
    
-
    
-  RouterIdentity followed by the Date, when the entry was published
-
    
+
    {% trans %}Description{% endtrans %}
    
+
    {% trans -%}
+Defines all of the data that a router wants to publish for the network to see. The RouterInfo is one of two structures stored in the network database(the other being LeaseSet, and is keyed under the SHA256 of
+the contained RouterIdentity.
+{% endtrans %}
    
+
    {% trans %}Contents{% endtrans %}
    
+
    {% trans -%}
+RouterIdentity followed by the Date, when the entry was published
+{% endtrans %}
    
 
     {% filter escape %}
 +----+----+----+----+----+----+----+----+
@@ -670,16 +706,21 @@ signature :: Signature
 {% endfilter %}
 
    
 
-
    Notes
    
+
    {% trans %}Notes{% endtrans %}
    
+
    {% trans -%}
 The peer_size Integer may be followed by a list of that many router hashes.
 This is currently unused. It was intended for a form of restricted routes, which is unimplemented.
-
    
+{% endtrans %}
    
+
+
    {% trans -%}
 The signature may be verified using the signing public key of the router_ident.
+{% endtrans %}
    
 
 
    Javadoc
    
 
 
 
    Delivery Instructions
    
-Defined in the Tunnel Message Specification.
-
+
    {% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%}
+Defined in the Tunnel Message Specification.
+{% endtrans %}
    
 {% endblock %}
diff --git a/i2p2www/pages/site/docs/spec/configuration.html b/i2p2www/pages/site/docs/spec/configuration.html
new file mode 100644
index 00000000..1080f830
--- /dev/null
+++ b/i2p2www/pages/site/docs/spec/configuration.html
@@ -0,0 +1,107 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Configuration File Specification{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}September 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.2{% endblock %}
+{% block content %}
+
    {% trans %}Overview{% endtrans %}
    
+
    {% trans -%}
+This page provides a general specification of I2P configuration files,
+used by the router and various applications.
+It also gives an overview of the information contained in the various files,
+and links to detailed documentation where available.
+{%- endtrans %}
    
+
+
+
    {% trans %}General Format{% endtrans %}
    
+
    {% trans url='http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Properties.html#load%28java.io.InputStream%29' -%}
+An I2P configuration file is formatted as specified in
+Java Properties
+with the following exceptions:
+{%- endtrans %}
    
+
      
+
    • {% trans %}Encoding must be UTF-8{% endtrans %}
      • 
+
    • {% trans %}Does not use or recognize any escapes, including '\', so lines may not be continued{% endtrans %}
      • 
+
    • {% trans %}'#' or ';' starts a comment, but '!' does not{% endtrans %}
      • 
+
    • {% trans %}'#' starts a comment in any position but ';' must be in column 1 to start a comment{% endtrans %}
      • 
+
    • {% trans %}Leading and trailing whitespace is not trimmed on keys{% endtrans %}
      • 
+
    • {% trans %}Leading and trailing whitespace is trimmed on values{% endtrans %}
      • 
+
    • {% trans %}'=' is the only key-termination character (not ':' or whitespace){% endtrans %}
      • 
+
    • {% trans %}Lines without '=' are ignored. It does not store the key with a value of ""{% endtrans %}
      • 
+
    • {% trans %}As there are no escapes, keys may not contain '#', '=', or '\n', or start with ';'{% endtrans %}
      • 
+
    • {% trans %}As there are no escapes, values may not contain '#' or '\n', or start or end with '\r' or whitespace{% endtrans %}
      • 
+
    
+
+
    {% trans -%}
+The file need not be sorted, but most applications do sort by key when
+writing to the file, for ease of reading and manual editing.
+{%- endtrans %}
    
+
+
    {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/data/DataHelper.html',
+commonstructures=site_url('docs/spec/common-structures') -%}
+Reads and writes are implemented in
+DataHelper loadProps() and storeProps().
+Note that the file format is significantly different than the
+serialized format for I2P protocols specified in
+Mapping.
+{%- endtrans %}
    
+
+
    {% trans %}Core library and router{% endtrans %}
    
+
+
    {% trans %}Clients{% endtrans %} (clients.config)
    
+
    {% trans -%}
+Configured via /configclients in the router console.
+{%- endtrans %}
    
+
+
    {% trans %}Logger{% endtrans %} (logger.config)
    
+
    {% trans -%}
+Configured via /configlogging in the router console.
+{%- endtrans %}
    
+
+
    {% trans %}Individual Plugin{% endtrans %} (xxx/plugin.config)
    
+
    {% trans pluginspec=site_url('docs/spec/plugin') -%}
+See the plugin specification.
+{%- endtrans %}
    
+
+
    {% trans %}Plugins{% endtrans %} (plugins.config)
    
+
    {% trans -%}
+Enable/disable for each installed plugin.
+{%- endtrans %}
    
+
+
    {% trans %}Router{% endtrans %} (router.config)
    
+
    {% trans -%}
+Configured via /configadvanced in the router console.
+{%- endtrans %}
    
+
+
    {% trans %}Applications{% endtrans %}
    
+
+
    {% trans %}Addressbook{% endtrans %} (addressbook/config.txt)
    
+
    {% trans -%}
+See documentation in SusiDNS.
+{%- endtrans %}
    
+
+
    I2PSnark (i2psnark.config)
    
+
    {% trans -%}
+Configured via the application gui.
+{%- endtrans %}
    
+
+
    I2PTunnel (i2ptunnel.config)
    
+
    {% trans -%}
+Configured via the /i2ptunnel application in the router console.
+{%- endtrans %}
    
+
+
    {% trans %}Router Console{% endtrans %}
    
+
    {% trans -%}
+The router console uses the router.config file.
+{%- endtrans %}
    
+
+
    SusiMail (susimail.config)
    
+
    {% trans -%}
+See post on zzz.i2p.
+{%- endtrans %}
    
+
+{% endblock %}
diff --git a/i2p2www/pages/site/docs/spec/datagrams.html b/i2p2www/pages/site/docs/spec/datagrams.html
new file mode 100644
index 00000000..a64a328e
--- /dev/null
+++ b/i2p2www/pages/site/docs/spec/datagrams.html
@@ -0,0 +1,100 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Datagram Specification{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
+{% block content %}
+
    {% trans -%}
+See the Datagrams page for an overview of the Datagrams API.
+{%- endtrans %}
    
+
+
    {% trans %}Specification{% endtrans %}
    
+
+
    {% trans %}Non-Repliable Datagrams{% endtrans %}
    
+
    {% trans -%}
+Non-repliable datagrams have no 'from' address and are not authenticated.
+They are also called "raw" datagrams.
+Strictly speaking, they are not "datagrams" at all, they are just raw data.
+They are not handled by the datagram API.
+However, SAM and the I2PTunnel classes support "raw datagrams".
+{%- endtrans %}
    
+
+
    {% trans %}Format{% endtrans %}
    
+
    ++----+----+----+----+----//
+| payload...
++----+----+----+----+----//
+
+
+Length: 0 - unlimited (see notes)
+
    
+
+
    {% trans %}Notes{% endtrans %}
    
+
    {% trans tunnelmessage=site_url('docs/spec/tunnel-message'),
+transports=site_url('docs/transport') -%}
+The practical length is limited by lower layers of protocols - the
+tunnel message spec
+limits messages to about 61.2 KB and the
+transports
+currently limit messages to about 32 KB, although this may be raised in the future.
+{%- endtrans %}
    
+
+
    {% trans %}Repliable Datagrams{% endtrans %}
    
+
    {% trans -%}
+Repliable datagrams contain a 'from' address and a signature. These add 427 bytes of overhead.
+{%- endtrans %}
    
+
    Format
    
+
    ++----+----+----+----+----+----+----+----+
+| from                                  |
++                                       +
+|                                       |
+~                                       ~
+~                                       ~
+|                                       |
++                                       +
+|                                       |
+|                                       |
++----+----+----+----+----+----+----+----+
+| signature                             |
++                                       +
+|                                       |
++                                       +
+|                                       |
++                                       +
+|                                       |
++                                       +
+|                                       |
++----+----+----+----+----+----+----+----+
+| payload...
++----+----+----+----//
+
+
+
+from      :: a Destination
+               length: 387+ bytes
+               The originator and signer of the datagram
+
+signature :: a Signature
+             length: 40 bytes
+             The DSA signature of the SHA256 hash of the payload, which may be verified by the
+             DSA signing public key of the 'from' Destination
+
+payload ::  The data
+            Length: 0 - 32 KB (see notes)
+
+Total length: Payload length + 427+
+
+
+
    
+
+
    {% trans %}Notes{% endtrans %}
    
+
    {% trans transports=site_url('docs/transport') -%}
+The practical length is limited by lower layers of protocols - the
+transports
+currently limit messages to about 32 KB, so the data length here is limited to about
+31.5 KB.
+{%- endtrans %}
    
+
+
+
+{% endblock %}
diff --git a/www.i2p2/pages/i2cp_spec.html b/i2p2www/pages/site/docs/spec/i2cp.html
similarity index 84%
rename from www.i2p2/pages/i2cp_spec.html
rename to i2p2www/pages/site/docs/spec/i2cp.html
index 89b9bc3c..1afc055f 100644
--- a/www.i2p2/pages/i2cp_spec.html
+++ b/i2p2www/pages/site/docs/spec/i2cp.html
@@ -1,7 +1,8 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}I2CP Specification{% endblock %}
+{% block lastupdated %}December 2012{% endblock %}
+{% block accuratefor %}0.9.4{% endblock %}
 {% block content %}
-Updated December 2012, current as of router version 0.9.4
 
    I2P Control Protocol (I2CP) Specification
    
 
    Overview
    
 
    
@@ -14,7 +15,7 @@ such as SAM or BOB.
 The protocol is only serialized if the client and router are not in the same JVM;
 otherwise, I2CP message objects are passed via an internal JVM interface.
 
    
-More information is on the I2CP Overview page.
+More information is on the I2CP Overview page.
 
    
 
 
@@ -158,9 +159,9 @@ as they generally disconnect the session upon reception of an unsupported messag
 
    
 
    Contents
    
 
    1. 
-  4 byte Integer specifying the length of the message body
+  4 byte Integer specifying the length of the message body
 
    2. 
-  1 byte Integer specifying the message type.
+  1 byte Integer specifying the message type.
 
    3. 
  The I2CP message body, 0 or more bytes
 
    
@@ -181,7 +182,7 @@ point in time.
 
    
 
    Contents
    
 
    1. 
-4 byte Integer
+4 byte Integer
 
    
 
 
    Notes
    
@@ -200,7 +201,7 @@ Destination to another.
 
    
 
    Contents
    
 
    1. 
-4 byte Integer  length
+4 byte Integer  length
 
    2. 
 That many bytes
 
    
@@ -208,7 +209,7 @@ That many bytes
 
    Notes
    
 
    
 The payload is in a gzip format as specified on the
-I2CP Overview page.
+I2CP Overview page.
 
    
 
 
@@ -221,20 +222,20 @@ Defines the configuration options for a particular client session.
 
    
 
    Contents
    
 
    1. 
-Destination
+Destination
 
    2. 
-Mapping of options
+Mapping of options
 
    3. 
-Creation Date
+Creation Date
 
    4. 
-DSA Signature of the previous 3 fields, signed by the
-Signing Private Key
+DSA Signature of the previous 3 fields, signed by the
+Signing Private Key
 
    
 
 
    Notes
    
 
    
 The options are specified on the
-I2CP Overview page.
+I2CP Overview page.
 
    
 
 
@@ -249,7 +250,7 @@ time.
 
    
 
    Contents
    
 
    1. 
-2 byte Integer
+2 byte Integer
 
    
 
 
    Notes
    
@@ -398,28 +399,28 @@ Sent from Router to Client in response to a Get Bandwidth Limits Message.
 
    
 
    Contents
    
 
    1. 
-4 byte Integer
+4 byte Integer
 Client inbound limit (KBps)
 
    2. 
-4 byte Integer
+4 byte Integer
 Client outbound limit (KBps)
 
    3. 
-4 byte Integer
+4 byte Integer
 Router inbound limit (KBps)
 
    4. 
-4 byte Integer
+4 byte Integer
 Router inbound burst limit (KBps)
 
    5. 
-4 byte Integer
+4 byte Integer
 Router outbound limit (KBps)
 
    6. 
-4 byte Integer
+4 byte Integer
 Router outbound burst limit (KBps)
 
    7. 
-4 byte Integer
+4 byte Integer
 Router burst time (seconds)
 
    8. 
-Nine 4-byte Integers
+Nine 4-byte Integers
 undefined
 
    
 
@@ -443,11 +444,11 @@ Sent from Client to Router.
 
    1. 
 Session ID
 
    2. 
-Signing Private Key
+Signing Private Key
 
    3. 
-Private Key
+Private Key
 
    4. 
-LeaseSet
+LeaseSet
 
    
 
 
    Notes
    
@@ -499,7 +500,7 @@ The router responds with a Dest Reply Message.
 
    
 
    Contents
    
 
    1. 
-SHA-256 Hash
+SHA-256 Hash
 
    
 
 
    Notes
    
@@ -518,9 +519,9 @@ Sent from Router to Client in response to a Dest Lookup Message.
 
    
 
    Contents
    
 
    1. 
-Destination
+Destination
 on success, or
-Hash
+Hash
 on failure
 
    
 
@@ -563,7 +564,7 @@ Sent either from router to client or from client to router.
 
    
 
    Contents
    
 
    1. 
-Reason String
+Reason String
 
    
 
 
    Notes
    
@@ -601,7 +602,7 @@ The router responds with a Set Date Message.
 
    
 
    Contents
    
 
    1. 
-I2CP Version String
+I2CP Version String
 
    
 
 
    Notes
    
@@ -653,11 +654,11 @@ For an outgoing message, this is a response to a
 
  • 
 Message ID
 
  • 
-1 byte Integer status
+1 byte Integer status
 
  • 
-4 byte Integer size
+4 byte Integer size
 
  • 
-4 byte Integer nonce
+4 byte Integer nonce
 
    • 
 
 
    Notes
    
@@ -767,10 +768,10 @@ Sent either from router to client or from client to router.
 
    1. 
 Session ID
 
    2. 
-1 byte Integer abuse severity
+1 byte Integer abuse severity
 (0 is minimally abusive, 255 being extremely abusive)
 
    3. 
-Reason String
+Reason String
 
    4. 
 Message ID
 
    
@@ -796,16 +797,16 @@ The client responds with a Create LeaseSet Message<
 
    1. 
 Session ID
 
    2. 
-1 byte Integer number of tunnels
+1 byte Integer number of tunnels
 
    3. 
   That many pairs of:
   
      1. 
-       Router Identity
+       Router Identity
   
      2. 
-       Tunnel ID
+       Tunnel ID
   
      
 
    4. 
-End Date
+End Date
 
    
 
 
    Notes
    
@@ -828,11 +829,11 @@ The router responds with a Message Status Message
  • 
 Session ID
 
  • 
-Destination
+Destination
 
  • 
 Payload
 
  • 
-4 byte Integer nonce
+4 byte Integer nonce
 
    • 
 
 
    Notes
    
@@ -865,15 +866,15 @@ Sent from Client to Router. Same as Send Message Message, except includes an exp
 
    1. 
 Session ID
 
    2. 
-Destination
+Destination
 
    3. 
 Payload
 
    4. 
-4 byte Integer nonce
+4 byte Integer nonce
 
    5. 
 2 bytes of flags (options)
 
    6. 
-Expiration Date
+Expiration Date
 truncated from 8 bytes to 6 bytes
 
    
 
@@ -968,7 +969,7 @@ Sent from Router to Client.
 
    1. 
 Session ID
 
    2. 
-1 byte Integer status
+1 byte Integer status
 
    
 
 
    Notes
    
@@ -988,9 +989,9 @@ Sent from Router to Client as a part of the initial handshake.
 
    
 
    Contents
    
 
    1. 
-Date
+Date
 
    2. 
-I2CP Version String
+I2CP Version String
 
    
 
 
    Notes
    
diff --git a/www.i2p2/pages/i2np_spec.html b/i2p2www/pages/site/docs/spec/i2np.html
similarity index 88%
rename from www.i2p2/pages/i2np_spec.html
rename to i2p2www/pages/site/docs/spec/i2np.html
index 56df4a8d..c0edb656 100644
--- a/www.i2p2/pages/i2np_spec.html
+++ b/i2p2www/pages/site/docs/spec/i2np.html
@@ -1,9 +1,8 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}I2NP Specification{% endblock %}
+{% block lastupdated %}September 2012{% endblock %}
+{% block accuratefor %}0.9.2{% endblock %}
 {% block content %}
-
-Updated September 2012, current as of router version 0.9.2
-
 
    I2P Network Protocol (I2NP) Specification
    
 
    
 The I2P Network Protocol (I2NP),
@@ -24,11 +23,11 @@ They are not complete messages.
 
    
 
    Contents
    
 
    
-  1 byte Integer specifying the type of this message,
- followed by a 4 byte Integer specifying the message-id.
- After that there is an expiration Date,
- followed by a 2 byte Integer specifying
- the length of the message payload, followed by a Hash,
+  1 byte Integer specifying the type of this message,
+ followed by a 4 byte Integer specifying the message-id.
+ After that there is an expiration Date,
+ followed by a 2 byte Integer specifying
+ the length of the message payload, followed by a Hash,
  which is truncated to the first byte. After that the actual message data follows.
 
    
 
    @@ -90,7 +89,7 @@ data :: Data
 
    
 
    Notes
    
 
 
 
@@ -341,7 +340,7 @@ unencrypted:
 
    Definition
    
 
     unencrypted:
-Delivery Instructions :: as defined here
+Delivery Instructions :: as defined here
        Length varies but is typically 39, 43, or 47 bytes
 
 I2NP Message :: Any I2NP Message
@@ -363,9 +362,9 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
   If 1, the clove is encrypted, and a 32 byte Session Key immediately follows the flag byte.
   Clove encryption is not fully implemented.
 
  • 
-  See also the garlic routing specification.
+  See also the garlic routing specification.
 
  • 
-  See also Delivery Instructions definition
+  See also Delivery Instructions definition
 
  • 
   Maximum length is a function of the total length of all the cloves and the
   maximum length of the GarlicMessage.
@@ -381,7 +380,7 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
 
 
 
    Delivery Instructions
    
-Defined in the Tunnel Message Specification.
+Defined in the Tunnel Message Specification.
 
 
 
    Messages
    
@@ -509,7 +508,7 @@ reply token:
 reply tunnelId:
                4 byte Tunnel ID
                only included if reply token > 0
-               This is the tunnel ID of the inbound gateway of the tunnel the response should be sent to
+               This is the tunnel ID of the inbound gateway of the tunnel the response should be sent to
 
 reply gateway:
               32 bytes
@@ -714,7 +713,7 @@ time stamp: Date
   It appears that the time stamp is always set by the creator to the current time.
   However there are several uses of this in the code, and more may be added in the future.
 
  • 
-  This message is also used as a session established confirmation in SSU.
+  This message is also used as a session established confirmation in SSU.
   In this case, the message ID is set to a random number, and the
   "arrival time" is set to the current network-wide ID, which is 2
   (i.e. 0x0000000000000002).
@@ -802,11 +801,11 @@ Expiration :: Date (8 bytes)
   the minimum size of the encrypted message is 160 bytes; with the 4 length bytes
   the minimum size of the Garlic Message is 164 bytes.
 
  • 
-  Actual max length is less than 64 KB; see the I2NP Overview.
+  Actual max length is less than 64 KB; see the I2NP Overview.
 
  • 
-  See also the ElGamal/AES specification.
+  See also the ElGamal/AES specification.
 
  • 
-  See also the garlic routing specification.
+  See also the garlic routing specification.
 
  • 
   The 128 byte minimum size of the AES encrypted block is not currently configurable,
   however the minimum size of a DataMessage in a GarlicClove in a GarlicMessage, with
@@ -852,7 +851,7 @@ data:
 
    Notes
    
 
 
 
@@ -950,7 +949,7 @@ Total size: 8*528 = 4224 bytes
 
 
    Notes
    
 
    
-  See also the tunnel creation specification.
+  See also the tunnel creation specification.
 
    
 
 
@@ -963,7 +962,7 @@ same format as TunnelBuild message, with Build Response Records
 
 
    Notes
    
 
    
-  See also the tunnel creation specification.
+  See also the tunnel creation specification.
 
    
 
 
    VariableTunnelBuild
    
@@ -994,7 +993,7 @@ Total size: 1 + $num*528
 
  • 
   This message was introduced in router version 0.7.12, and may not be sent to tunnel participants earlier than that version.
 
  • 
-  See also the tunnel creation specification.
+  See also the tunnel creation specification.
 
 
 
    VariableTunnelBuildReply
    
@@ -1015,7 +1014,7 @@ Same format as VariableTunnelBuild message, with Build Response Records.
 
  • 
   This message was introduced in router version 0.7.12, and may not be sent to tunnel participants earlier than that version.
 
  • 
-  See also the tunnel creation specification.
+  See also the tunnel creation specification.
 
 
 
diff --git a/www.i2p2/pages/plugin_spec.html b/i2p2www/pages/site/docs/spec/plugin.html
similarity index 96%
rename from www.i2p2/pages/plugin_spec.html
rename to i2p2www/pages/site/docs/spec/plugin.html
index 06690b66..406d833e 100644
--- a/www.i2p2/pages/plugin_spec.html
+++ b/i2p2www/pages/site/docs/spec/plugin.html
@@ -1,12 +1,12 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}I2P Plugin Specification{% endblock %}
+{% block lastupdated %}March 2012{% endblock %}
+{% block accuratefor %}0.8.13-13{% endblock %}
 {% block content %}
 
    
 Specification Version 0.18
 2012-03-15
 
    
-
     
-Page last updated March 2012, current as of router version 0.8.13-13
 
    Overview
    
 
     
 This document specifies
@@ -59,7 +59,7 @@ system, the router, executing external programs, etc.
 foo.xpi2p is a sud file containing the following:
 
     	Standard .sud header prepended to the zip file, containing the following:
-	        40-byte DSA signature
+	        40-byte DSA signature
 		16-byte plugin version in UTF-8, padded with trailing zeroes if necessary
 
 	Zip file containing the following:
@@ -74,7 +74,7 @@ foo.xpi2p is a sud file containing the following:
 			*name (will be installed in this directory name)
 				For native plugins, you may want separate names in different packages -
 				foo-windows and foo-linux, for example
-			*key (DSA public key as 172 B64 chars ending with '=')
+			*key (DSA public key as 172 B64 chars ending with '=')
 			*signer (yourname@mail.i2p recommended)
 
 			*version (must be in a format VersionComparator can parse, e.g. 1.2.3-4)
@@ -277,7 +277,7 @@ But that's ok. Then you can start and stop i2ptunnel and jetty together.
 So don't count on the router to automatically merge this with some existing eepsite. It probably won't happen.
 Start a new I2PTunnel and Jetty from clients.config.
 The best examples of this are the zzzot and pebble plugins,
-available at zzz's plugins page.
+available at zzz's plugins page.
 
    
 How to get path substitution into jetty.xml?
 See zzzot and pebble plugins for examples.
@@ -301,7 +301,7 @@ whether or not they were previously started.
 Shell script and external program notes
 
 
    
-To run shell scripts or other external programs, see zzz.i2p
+To run shell scripts or other external programs, see {{ i2pconv('zzz.i2p') }}
 
    
 To work on both Windows and Linux, write a small Java class that checks the OS type, then
 runs ShellCommand on either the .bat or a .sh file you provide.
@@ -346,7 +346,7 @@ could ask.
 There is no reliable way to find the i2p install or config or plugin directory without using the
 context API in i2p.jar.
 
  • 
- See Howto for info on generating signing keys and generating/verifying keys and sud files
+ See Howto for info on generating signing keys and generating/verifying keys and sud files
 
  • 
  All config files must be UTF-8.
 
  • 
@@ -407,7 +407,7 @@ the entire JVM.
 However, as of 0.7.13-3, this was fixed using class loaders, and now, as originally intended,
 the specified classpath in clients.config is only for the particular thread.
 See the section on JVM crashes below, and
-this thread on zzz.i2p for background.
+this thread on zzz.i2p for background.
 Therefore, specify the full required classpath for each client.
 
 
diff --git a/www.i2p2/pages/udp_spec.html b/i2p2www/pages/site/docs/spec/ssu.html
similarity index 94%
rename from www.i2p2/pages/udp_spec.html
rename to i2p2www/pages/site/docs/spec/ssu.html
index fcee70cc..8625d181 100644
--- a/www.i2p2/pages/udp_spec.html
+++ b/i2p2www/pages/site/docs/spec/ssu.html
@@ -1,11 +1,10 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}SSU Protocol Specification{% endblock %}
+{% block lastupdated %}October 2012{% endblock %}
+{% block accuratefor %}0.9.2{% endblock %}
 {% block content %}
-
-Updated October 2012 for release 0.9.2
-
 
    
-See the SSU page for an overview of the SSU transport.
+See the SSU page for an overview of the SSU transport.
 
 
    Specification
    
 
@@ -13,9 +12,9 @@ Updated October 2012 for release 0.9.2
 
    DH Key Exchange
    
 
    
 The initial 2048-bit DH key exchange is described on the
-SSU page.
+SSU page.
 This exchange uses the same shared  prime as that used for I2P's
-ElGamal encryption.
+ElGamal encryption.
 
    
 
 
@@ -36,7 +35,7 @@ The payload is the message starting with the flag byte.
 The macKey is either the introduction key or the
 session key, as specified for each message below.
 WARNING - the HMAC-MD5-128 used here is non-standard,
-see the cryptography page for details.
+see the cryptography page for details.
 
 
 
    The payload itself (that is, the message starting with the flag byte)
@@ -108,7 +107,7 @@ bytes.
    
 
    Padding
    
 
    
 All messages contain 0 or more bytes of padding.
-Each message must be padded to a 16 byte boundary, as required by the AES256 encryption layer.
+Each message must be padded to a 16 byte boundary, as required by the AES256 encryption layer.
 Currently, messages are not padded beyond the next 16 byte boundary.
 The fixed-size tunnel messages of 1024 bytes (at a higher layer)
 provide a significant amount of protection.
@@ -122,15 +121,15 @@ fragmentation to external adversaries.
 
    
 DSA signatures in the SessionCreated and SessionConfirmed messages are generated using
 the
-signing public key
+signing public key
 from the
-router identity
+router identity
 which is distributed out-of-band by publishing in the network database, and the associated
-signing private key.
+signing private key.
 
    
 Both introduction keys and session keys are 32 bytes,
 and are defined by the
-Common structures specification.
+Common structures specification.
 The key used for the MAC and encryption is specified for each message below.
 
    
 
    Introduction keys are delivered through an external channel 
@@ -146,7 +145,7 @@ IPv6 addressing is not currently supported within I2P.
 All IP addresses are currently 4 bytes.
 
 
    Timestamps
    
-While most of I2P uses 8-byte Date timestamps with
+While most of I2P uses 8-byte Date timestamps with
 millisecond resolution, SSU uses a 4-byte timestamp with one-second resolution.
 
 
@@ -239,7 +238,7 @@ This is the response to a Session Request.
         
  • 4 byte relay (introduction) tag which Alice can publish (else 0x00000000)
    • 
         
  • 4 byte timestamp (seconds from the epoch) for use in the DSA 
             signature
    • 
-        
  • 40 byte DSA signature of the critical exchanged data 
+        
  • 40 byte DSA signature of the critical exchanged data 
             (X + Y + Alice's IP + Alice's port + Bob's IP + Bob's port + Alice's
             new relay tag + Bob's signed on time), encrypted with another 
             layer of encryption using the negotiated sessionKey.  The IV 
@@ -327,7 +326,7 @@ bits 7-4: current identity fragment # 0-14
 bits 3-0: total identity fragments (F) 1-15
    • 
         
  • 2 byte size of the current identity fragment
    • 
         
  • that many byte fragment of Alice's
-           Router Identity
+           Router Identity
         
    • 
         
  • After the last identity fragment only:
             
    • 4 byte signed-on time
@@ -335,7 +334,7 @@ bits 3-0: total identity fragments (F) 1-15
    • 
         
  • N bytes padding, currently uninterpreted
         
  • After the last identity fragment only:
             
    • The last 40 
-            bytes contain the DSA signature of the critical exchanged 
+            bytes contain the DSA signature of the critical exchanged 
             data (X + Y + Alice's IP + Alice's port + Bob's IP + Bob's port
             + Alice's new relay key + Alice's signed on time)
      • 
             
    
@@ -393,7 +392,7 @@ Typical size including header, in current implementation: 480 bytes
 
    • 
 In the current implementation, the maximum fragment size is 512 bytes.
 
    • 
-The typical Router Identity
+The typical Router Identity
 is 387 bytes, so no fragmentation is usually necessary.
 
    • 
 There is no mechanism for requesting or redelivering missing fragments.
@@ -736,7 +735,7 @@ the message ID must be an actual random number.
 
 
      PeerTest (type 7)
      
 
      
-See the UDP overview page for details.
+See the SSU overview page for details.
 
      
 
 
diff --git a/i2p2www/pages/site/docs/spec/streaming.html b/i2p2www/pages/site/docs/spec/streaming.html
new file mode 100644
index 00000000..41e49de9
--- /dev/null
+++ b/i2p2www/pages/site/docs/spec/streaming.html
@@ -0,0 +1,135 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Streaming Library Specification{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}November 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.3{% endblock %}
+{% block content %}
+
      {% trans -%}
+See the Streaming page for an overview of the Streaming Library.
+{%- endtrans %}
      
+
+
      {% trans %}Protocol Specification{% endtrans %}
      
+
      {% trans %}Packet Format{% endtrans %}
      
+
      {% trans -%}
+The format of a single packet in the streaming protocol is:
+{%- endtrans %}
      
+
      +
++----+----+----+----+----+----+----+----+
+| send Stream ID    | rcv Stream ID     |
++----+----+----+----+----+----+----+----+
+| sequence  Num     | ack Through       |
++----+----+----+----+----+----+----+----+
+| nc |   NACKs ...
++----+----+----+----+----+----+----+----+
+     | rd |  flags  | opt size| opt data
++----+----+----+----+----+----+----+----+
+   ...                                  |
++----+----+----+----+----+----+----+----+
+|   payload ...
++----+----+----+----//
+
+
+
      
+
+
      
+
      {{ _('Field') }}{{ _('Length') }}{{ _('Contents') }}
+
      sendStreamId 4 byte IntegerRandom number selected by the connection recipient
+and constant for the life of the connection.
+0 in the SYN message sent by the originator, and in subsequent messages, until a SYN reply is received,
+containing the peer's stream ID.
+
+
      receiveStreamId 4 byte IntegerRandom number selected by the connection originator
+and constant for the life of the connection. May be 0 if unknown, for example in a RESET packet.
+
+
      sequenceNum 4 byte Integer
+The sequence for this message, starting at 0 in the SYN message,
+and incremented by 1 in each message except for plain ACKs and retransmissions.
+If the sequenceNum is 0 and the SYN flag is not set, this is a plain ACK 
+packet that should not be ACKed.
+
+
      ackThrough 4 byte Integer
+The highest packet sequence number that was received
+on the receiveStreamId.  This field is ignored on the initial
+connection packet (where receiveStreamId is the unknown id) or
+if the NO_ACK flag set.
+All packets up to and including this sequence number are ACKed,
+EXCEPT for those listed in NACKs below.
+
+
      NACK count1 byte Integer
+The number of 4-byte NACKs in the next field
+
+
      NACKs n * 4 byte Integers
+Sequence numbers less than ackThrough that are not yet received.
+Two NACKs of a packet is a request for a 'fast retransmit' of that packet.
+
+
      resendDelay1 byte Integer
+How long is the creator of this packet going to wait before
+resending this packet (if it hasn't yet been ACKed).  The 
+value is seconds since the packet was created.
+Currently ignored on receive.
+
+
      flags 2 byte value
+See below.
+
+
      option size2 byte Integer
+The number of bytes in the next field
+
+
      option data0 or more bytes
+As specified by the flags. See below.
+
+
      payload remaining packet size
+
      
+
+
      {% trans %}Flags and Option Data Fields{% endtrans %}
      
+
      {% trans -%}
+The flags field above specifies some metadata about the packet, and in
+turn may require certain additional data to be included.  The flags are
+as follows. Any data structures specified must be added to the options area
+in the given order.
+{%- endtrans %}
      
+
+
      
+Bit order: 15....0 (15 is MSB)
+
      
+
+
      BitFlagOption DataFunction
+
      0SYNCHRONIZE--
+Similar to TCP SYN. Set in the initial packet and in the first response.
+FROM_INCLUDED and SIGNATURE_INCLUDED must be set also.
+
      1CLOSE--
+Similar to TCP FIN. If the response to a SYNCHRONIZE fits in a single message, the response
+will contain both SYNCHRONIZE and CLOSE.
+SIGNATURE_INCLUDED must be set also.
+
      2RESET--
+Abnormal close.
+SIGNATURE_INCLUDED must be set also.
+
      3SIGNATURE_INCLUDED40 byte DSA Signature
+
+Currently sent only with SYNCHRONIZE, CLOSE, and RESET, where it is required.
+The signature uses the Destination's DSA signing keys 
+to sign the entire header and payload with the 40-byte space in the option data field 
+for the signature being set to all zeroes.
+
      4SIGNATURE_REQUESTED--
+Unused. Requests every packet in the other direction to have SIGNATURE_INCLUDED
+
      5FROM_INCLUDED387+ byte Destination
+
+Currently sent only with SYNCHRONIZE, where it is required.
+
      6DELAY_REQUESTED2 byte Integer
+Optional delay.
+How many milliseconds the sender of this packet wants the recipient
+to wait before sending any more data.
+A value greater than 60000 indicates choking.
+
      7MAX_PACKET_SIZE_INCLUDED2 byte Integer
+Currently sent with SYNCHRONIZE only.
+Was also sent in retransmitted packets until release 0.9.1.
+
      8PROFILE_INTERACTIVE--
+Unused or ignored; the interactive profile is unimplemented.
+
      9ECHO--
+Unused except by ping programs
+
      10NO_ACK--
+This flag simply tells the recipient to ignore the ackThrough field in the header.
+Currently unused, the ackThrough field is always valid.
+
      11-15unused
+
      
+
+{% endblock %}
diff --git a/www.i2p2/pages/tunnel-alt-creation.html b/i2p2www/pages/site/docs/spec/tunnel-creation.html
similarity index 87%
rename from www.i2p2/pages/tunnel-alt-creation.html
rename to i2p2www/pages/site/docs/spec/tunnel-creation.html
index ed9a8154..cf42d4e1 100644
--- a/www.i2p2/pages/tunnel-alt-creation.html
+++ b/i2p2www/pages/site/docs/spec/tunnel-creation.html
@@ -1,16 +1,17 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Tunnel Creation{% endblock %}
+{% block lastupdated %}August 2010{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
 {% block content %}
 
 This page documents the current tunnel build implementation.
-Updated August 2010 for release 0.8
 
 
      Tunnel Creation Specification
      
 
 
      
 This document specifies the details of the encrypted tunnel build messages
 used to create tunnels using a "non-interactive telescoping" method.
-See the tunnel build document
+See the tunnel build document
 for an overview of the process, including peer selection and ordering methods.
 
 
      The tunnel creation is accomplished by a single message passed along
@@ -18,11 +19,11 @@ the path of peers in the tunnel, rewritten in place, and transmitted
 back to the tunnel creator.  This single tunnel message is made up
 of a variable number of records (up to 8) - one for each potential peer in
 the tunnel.   Individual records are asymmetrically
-(ElGamal)
+(ElGamal)
 encrypted to be
 read only by a specific peer along the path, while an additional
 symmetric layer of encryption
-(AES)
+(AES)
 is added at each hop so as to expose
 the asymmetrically encrypted record only at the appropriate time.
      
 
@@ -31,10 +32,10 @@ Not all records must contain valid data.
 The build message for a 3-hop tunnel, for example, may contain more records
 to hide the actual length of the tunnel from the participants.
 There are two build message types. The original
-Tunnel Build Message (TBM)
+Tunnel Build Message (TBM)
 contains 8 records, which is more than enough for any practical tunnel length.
 The recently-implemented
-Variable Tunnel Build Message (VTBM)
+Variable Tunnel Build Message (VTBM)
 contains 1 to 8 records. The originator may trade off the size of the message
 with the desired amount of tunnel length obfuscation.
 
      
@@ -50,7 +51,7 @@ The reply message must be the same type and length as the build message.
 
      Request Record Specification
      
 
 Also specified in the
-I2NP Specification
+I2NP Specification
 
 
      Cleartext of the record, visible only to the hop being asked:
         bytes     0-3: tunnel ID to receive messages as
@@ -96,14 +97,14 @@ The layer and reply key pairs are generated.
 
 
      Request Record Encryption
      
 
-
      That cleartext record is ElGamal 2048 encrypted with the hop's
+
      That cleartext record is ElGamal 2048 encrypted with the hop's
 public encryption key and formatted into a 528 byte record:
         bytes   0-15: First 16 bytes of the SHA-256 of the current hop's router identity
   bytes 16-527: ElGamal-2048 encrypted request record
      
 
 In the 512-byte encrypted record,
 the ElGamal data contains bytes 1-256 and 258-513 of the
-514-byte ElGamal encrypted block.
+514-byte ElGamal encrypted block.
 The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed.
 
 
      Since the cleartext uses the full field, there is no need for
@@ -128,7 +129,7 @@ are dropped.
      
 
 
      After deciding whether they will agree to participate in the tunnel
 or not, they replace the record that had contained the request with
-an encrypted reply block.  All other records are AES-256
+an encrypted reply block.  All other records are AES-256
 encrypted with the included reply key and IV. Each is
 encrypted separately, rather than chained across records.
      
 
@@ -171,17 +172,17 @@ The padding is placed before the status byte:
 
         AES-256-CBC(SHA-256(padding+status) + padding + status, key, IV)
      
 This is also described in the
-I2NP spec.
+I2NP spec.
 
 
      Tunnel Build Message Preparation
      
 
 
      When building a new Tunnel Build Messaage, all of the Build Request Records must first be 
 built and asymmetrically encrypted using
-ElGamal.
+ElGamal.
 Each record is then
 premptively decrypted with the reply keys and IVs of the hops earlier in the
 path, using
-AES.
+AES.
 That decryption should be run in reverse order so that the
 asymmetrically encrypted data will show up in the clear at the
 right hop after their predecessor encrypts it.
      
@@ -210,14 +211,14 @@ encrypting a reply in place of the record and encrypting all of the
 other records, but since there is no 'next hop' to forward the
 TunnelBuildMessage on to, it instead places the encrypted reply
 records into a
-TunnelBuildReplyMessage
+TunnelBuildReplyMessage
 or
-VariableTunnelBuildReplyMessage
+VariableTunnelBuildReplyMessage
 (the type of message and number of records must match that of the request)
 and delivers it to the
 reply tunnel specified within the request record.  That reply tunnel
 forwards the Tunnel Build Reply Message back to the tunnel creator,
-just as for any other message.
+just as for any other message.
 The tunnel creator then
 processes it, as described below.
      
 
@@ -245,7 +246,7 @@ tunnel is discarded.
      
 
 
      
 The agreements and rejections are noted in each peer's
-profile, to be used in future assessments
+profile, to be used in future assessments
 of peer tunnel capacity.
 
 
@@ -289,10 +290,10 @@ inject a random delay before forwarding on the request?
      • 
 
      References
      
 
        
 
      • 
-Predecessor 
+Predecessor 
 attack
 
      • 
-2008 
+2008 
 update
 
      • 
 Hashing it out in Public
diff --git a/www.i2p2/pages/tunnel_message_spec.html b/i2p2www/pages/site/docs/spec/tunnel-message.html
similarity index 93%
rename from www.i2p2/pages/tunnel_message_spec.html
rename to i2p2www/pages/site/docs/spec/tunnel-message.html
index 3dbc8881..35144221 100644
--- a/www.i2p2/pages/tunnel_message_spec.html
+++ b/i2p2www/pages/site/docs/spec/tunnel-message.html
@@ -1,15 +1,14 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Tunnel Message Specification{% endblock %}
+{% block lastupdated %}October 2011{% endblock %}
+{% block accuratefor %}0.8.10{% endblock %}
 {% block content %}
-
-Updated October 2011 for release 0.8.10
-
 
        Tunnel Message Specification
        
 This document specifies the format of tunnel messages.
 For general information about tunnels see
-the tunnel documentation.
+the tunnel documentation.
 
-
        Message preprocessing
        
+
        Message preprocessing
        
 
 
 A tunnel gateway is the entrance, or first hop, of a tunnel.
@@ -17,7 +16,7 @@ For an outbound tunnel, the gateway is the creator of the tunnel.
 For an inbound tunnel, the gateway is at the opposite end from the creator of the tunnel.
 
 
        
-A gateway preprocesses I2NP messages
+A gateway preprocesses I2NP messages
 by fragmenting and combining them into tunnel messages.
 
 
        
@@ -29,7 +28,7 @@ observing message size.
 
 
        
 After the tunnel messages are created, they are encrypted as described in
-the tunnel documentation.
+the tunnel documentation.
 
 
        Tunnel Message (Encrypted)
        
 These are the contents of a tunnel data message after encryption.
@@ -166,11 +165,11 @@ set, this is a follow on fragment.
        
 
 
        
 Note that Delivery Instructions are also used inside
-Garlic Cloves,
+Garlic Cloves,
 where the format is slightly different. In a Garlic Clove,
 messages are not fragmented, and the fragment bit in the flag byte is
 redefined. See the
-Garlic Clove documentation
+Garlic Clove documentation
 for more details.
 
 
@@ -238,7 +237,7 @@ Message ID:
        4 bytes
        Optional, present if this message is the first of 2 or more fragments
        An ID that uniquely identifies all fragments as belonging to a single message
-       (the current implementation uses the I2NP Message ID)
+       (the current implementation uses the I2NP Message ID)
 
 Extended Options:
        2 or more bytes
diff --git a/www.i2p2/pages/updates.html b/i2p2www/pages/site/docs/spec/updates.html
similarity index 67%
rename from www.i2p2/pages/updates.html
rename to i2p2www/pages/site/docs/spec/updates.html
index c8ea2f08..6a69f1d3 100644
--- a/www.i2p2/pages/updates.html
+++ b/i2p2www/pages/site/docs/spec/updates.html
@@ -1,70 +1,85 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Software Update Specification{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}I2P Software Update Specification{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}November 2011{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.12{% endblock %}
 {% block content %}
-Page last updated November 2011, current as of router version 0.8.12
-
        Overview
        
-
         
+
        {% trans %}Overview{% endtrans %}
        
+
        {% trans -%}
 I2P uses a simple, yet secure, system for automated software update.
 The router console periodically pulls a news file from a configurable I2P URL.
 There is a hardcoded backup URL pointing to the project website, in case
 the default project news host goes down.
-
        
+{%- endtrans %}
        
+
+
        {% trans -%}
 The contents of the news file are displayed on the home page of the router console.
 In addition, the news file contains the most recent version number of the software.
 If the version is higher than the router's version number, it will
 display an indication to the user that an update is available.
-
        
+{%- endtrans %}
        
+
+
        {% trans -%}
 The router may optionally download, or download and install, the new version
 if configured to do so.
-
        
+{%- endtrans %}
        
 
-
        News File Specification
        
-
        
+
        {% trans %}News File Specification{% endtrans %}
        
+
        {% trans -%}
 The news.xml file may contain the following elements:
-
        
+{%- endtrans %}
        
 
         <i2p.news date="$Date: 2010-01-22 00:00:00 $" />
 <i2p.release version="0.7.14" date="2010/01/22" minVersion="0.6" />
 
        
 
-
        
+
        {% trans -%}
 The elements may be included inside XML comments to prevent interpretation by browsers.
 The i2p.release element and version are required. All others are optional and are
 currently unused.
-
        
+{%- endtrans %}
        
+
+
        {% trans -%}
 The news source is trusted only to indicate that a new version is available.
 It does not specify the URL of the update, the checksum, or any other information.
-
        
+{%- endtrans %}
        
 
 
-
        Update File Specification
        
-
        
+
        {% trans %}Update File Specification{% endtrans %}
        
+
        {% trans -%}
 The signed update file, traditionally named i2pupdate.sud,
 is simply a zip file with a prepended 56 byte header.
 The header contains:
+{%- endtrans %}
        
 
          
-
        • 
-A 40-byte DSA signature
-
        • 
+
        • {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+A 40-byte DSA signature
+{%- endtrans %}
          • 
+
        • {% trans -%}
 A 16-byte I2P version in UTF-8, padded with trailing zeroes if necessary
-
        
-
        
+{%- endtrans %}
        • 
+
      
+
+
      {% trans commonstructures=site_url('docs/spec/common-structures') -%}
 The signature covers only the zip archive - not the prepended version.
-The signature must match one of the DSA public keys configured into the router,
+The signature must match one of the DSA public keys configured into the router,
 which has a hardcoded default list of keys of the current project release managers.
-
      
+{%- endtrans %}
      
+
+
      {% trans -%}
 For version comparison purposes, version fields contain [0-9]*, field separators are
 '-', '_', and '.', and all other characters are ignored.
-
      
+{%- endtrans %}
      
+
+
      {% trans -%}
 As of version 0.8.8, the version must also be specified as a zip file comment in UTF-8,
 without the trailing zeroes.
 The updating router verifes that the version in the header (not covered by the signature)
 matches the version in the zip file comment, which is covered by the signature.
 This prevents spoofing of the version number in the header.
-
      
+{%- endtrans %}
      
 
-
      Download and Installation
      
-
      
+
      {% trans %}Download and Installation{% endtrans %}
      
+
      {% trans -%}
 The router first downloads the header of the update file from one in a configurable list of I2P URLs,
 using the built-in HTTP client and proxy,
 and checks that the version is newer.
@@ -73,45 +88,58 @@ The router then downloads the full update file.
 The router verifies that the update file version is newer before installation.
 It also, of course, verifies the signature, and
 verifes that the zip file comment matches the header version, as explained above.
-
      
+{%- endtrans %}
      
+
+
      {% trans -%}
 The zip file is extracted in the base $I2P installation directory.
-
      
+{%- endtrans %}
      
+
+
      {% trans -%}
 As of release 0.7.12, the router supports Pack200 decompression.
 Files inside the zip archive with a .jar.pack or .war.pack suffix
 are transparently decompressed to a .jar or .war file.
 Update files containing .pack files are traditionally named with a '.su2' suffix.
 Pack200 shrinks the update files by about 60%.
-
      
+{%- endtrans %}
      
+
+
      {% trans -%}
 As of release 0.8.7, the router will delete the libjbigi.so and libjcpuid.so files
 if the zip archive contains a lib/jbigi.jar file, so that the new files will
 be extracted from jbigi.jar.
-
      
+{%- endtrans %}
      
+
+
      {% trans -%}
 As of release 0.8.12, if the zip archive contains a file deletelist.txt, the router will
 delete the files listed there. The format is:
-
      • 
-One file name per line
-
      • 
-All file names are relative to the installation directory; no absolute file names allowed, no files starting with ".."
-
      • 
-Comments start with '#'
-
      
+{%- endtrans %}
      
+
        
+
      • {% trans %}One file name per line{% endtrans %}
        • 
+
      • {% trans %}All file names are relative to the installation directory; no absolute file names allowed, no files starting with ".."{% endtrans %}
        • 
+
      • {% trans %}Comments start with '#'{% endtrans %}
        • 
+
      
+
+
      {% trans -%}
 The router will then delete the deletelist.txt file.
-
      
+{%- endtrans %}
      
 
 
-
      Future Work
      
-
      • 
+
        {% trans %}Future Work{% endtrans %}
        
+
          
+
        • {% trans -%}
 When a new update file specification is defined, it should use a larger
 DSA signature, and the signature should cover the version.
 A file format version number might be a good idea too.
-
        • 
+{%- endtrans %}
          • 
+
        • {% trans -%}
 The network will eventually grow too large for update over HTTP.
 The built-in BitTorrent client, i2psnark, may be used as a distributed update method.
 This development effort was started in 2009 but is on hold until it is required.
-
        • 
+{%- endtrans %}
          • 
+
        • {% trans -%}
 The router update mechanism is part of the web router console.
 There is currently no provision for updates of an embedded router lacking the router console.
-
        
+{%- endtrans %}
        • 
+
      
 
 
 
diff --git a/i2p2www/pages/site/docs/transport/index.html b/i2p2www/pages/site/docs/transport/index.html
new file mode 100644
index 00000000..7ab5ad92
--- /dev/null
+++ b/i2p2www/pages/site/docs/transport/index.html
@@ -0,0 +1,158 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Transport Overview{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}July 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
+{% block content %}
+
      {% trans %}Transports in I2P{% endtrans %}
      
+
+
      {% trans -%}
+A "transport" in I2P is a method for direct, point-to-point communication
+between two routers.
+Transports must provide confidentiality and integrity 
+against external adversaries while authenticating that the router contacted 
+is the one who should receive a given message.
+{%- endtrans %}
      
+
+
      {% trans -%}
+I2P supports multiple transports simultaneously.
+There are two transports currently implemented:
+{%- endtrans %}
      
+
        
+
      1. {% trans ntcp=site_url('docs/transport/ntcp') %}NTCP, a Java New I/O (NIO) TCP transport{% endtrans %}
        2. 
+
      2. {% trans ssu=site_url('docs/transport/ssu') %} SSU, or Secure Semireliable UDP{% endtrans %}
        3. 
+
      
+
+
      {% trans -%}
+Each provides a "connection" paradigm, with authentication,
+flow control, acknowledgments and retransmission.
+{%- endtrans %}
      
+
+
+
      {% trans %}Transport Services{% endtrans %}
      
+
+
      {% trans -%}
+The transport subsystem in I2P provides the following services:
+{%- endtrans %}
      
+
        
+
      • {% trans -%}
+Maintain a set of router addresses, one or more for each transport,
+that the router publishes as its global contact information (the RouterInfo)
+{%- endtrans %}
        • 
+
      • {% trans %}Selection of the best transport for each outgoing message{% endtrans %}
        • 
+
      • {% trans %}Queueing of outbound messages by priority{% endtrans %}
        • 
+
      • {% trans %}Bandwidth limiting, both outbound and inbound, according to router configuration{% endtrans %}
        • 
+
      • {% trans %}Setup and teardown of transport connections{% endtrans %}
        • 
+
      • {% trans %}Encryption of point-to-point communications{% endtrans %}
        • 
+
      • {% trans -%}
+Maintenance of connection limits for each transport, implementation of various thresholds for these limits,
+and communication of threshold status to the router so it may make operational changes based on the status
+{%- endtrans %}
        • 
+
      • {% trans %}Firewall port opening using UPnP (Universal Plug and Play){% endtrans %}
        • 
+
      • {% trans %}Cooperative NAT/Firewall traversal{% endtrans %}
        • 
+
      • {% trans %}Local IP detection by various methods, including UPnP, inspection of incoming connections, and enumeration of network devices{% endtrans %}
        • 
+
      • {% trans %}Coordination of firewall status and local IP, and changes to either, among the transports{% endtrans %}
        • 
+
      • {% trans %}Communication of firewall status and local IP, and changes to either, to the router and the user interface{% endtrans %}
        • 
+
      • {% trans %}Determination of a consensus clock, which is used to periodically update the router's clock, as a backup for NTP{% endtrans %}
        • 
+
      • {% trans -%}
+Maintenance of status for each peer, including whether it is connected, whether it was recently connected,
+and whether it was reachable in the last attempt
+{%- endtrans %}
        • 
+
      • {% trans %}Qualification of valid IP addresses according to a local rule set{% endtrans %}
        • 
+
      • {% trans -%}
+Honoring the automated and manual lists of banned peers maintained by the router,
+and refusing outbound and inbound connections to those peers
+{%- endtrans %}
        • 
+
      
+
+
+
      {% trans %}Transport Addresses{% endtrans %}
      
+
+
      {% trans -%}
+The transport subsystem maintains a set of router addresses, each of which lists a transport method, IP, and port.
+These addresses constitute the advertised contact points, and are published by the router to the network database.
+{%- endtrans %}
      
+
+
      {% trans %}Typical scenarios are:{% endtrans %}
+
        
+
      • {% trans %}A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections{% endtrans %}
        • 
+
      • {% trans ssu=site_url('docs/transport/ssu') -%}
+A router is firewalled, and therefore publishes an SSU address which contains a list of cooperating
+peers or "introducers" who will assist in NAT traversal (see the SSU spec for details)
+{%- endtrans %}
        • 
+
      • {% trans -%}
+A router is not firewalled or its NAT ports  are open; it publishes both NTCP and SSU addresses containing
+directly-accessible IP and ports.
+{%- endtrans %}
        • 
+
      
+
+
      {% trans %}Transport Selection{% endtrans %}
      
+
+
      {% trans i2np=site_url('docs/protocol/i2np') -%}
+The transport system delivers I2NP messages. The transport selected for any message is
+independent of the application-layer protocol (TCP or UDP).
+{%- endtrans %}
      
+
+
      {% trans -%}
+For each outgoing message, the transport system solicits "bids" from each transport.
+The transport bidding the lowest (best) value wins the bid and receives the message for delivery.
+A transport may refuse to bid.
+{%- endtrans %}
      
+
+
      {% trans -%}
+Whether a transport bids, and with what value, depend on numerous factors:
+{%- endtrans %}
      
+
        
+
      • {% trans %}Configuration of transport preferences{% endtrans %}
        • 
+
      • {% trans %}Whether the transport is already connected to the peer{% endtrans %}
        • 
+
      • {% trans %}The number of current connections compared to various connection limit thresholds{% endtrans %}
        • 
+
      • {% trans %}Whether recent connection attempts to the peer have failed{% endtrans %}
        • 
+
      • {% trans %}The size of the message, as different transports have different size limits{% endtrans %}
        • 
+
      • {% trans %}Whether the peer can accept incoming connections for that transport, as advertised in its RouterInfo{% endtrans %}
        • 
+
      • {% trans %}Whether the connection would be indirect (requiring introducers) or direct{% endtrans %}
        • 
+
      • {% trans %}The peer's transport preference, as advertised in its RouterInfo{% endtrans %}
        • 
+
      
+
+
      {% trans -%}
+In general, the bid values are selected so that two routers are only connected by a single transport
+at any one time. However, this is not a requirement.
+{%- endtrans %}
      
+
+
+
+
      {% trans %}New Transports and Future Work{% endtrans %}
      
+
+
      {% trans -%}
+Additional transports may be developed, including:
+{%- endtrans %}
      
+
+
        
+
      • {% trans %}A TLS/SSH look-alike transport{% endtrans %}
        • 
+
      • {% trans %}An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes"){% endtrans %}
        • 
+
      
+
+
      {% trans -%}
+Also, the existing transports will be enhanced to support multiple addresses within a single transport,
+including IPV6 addresses. Currently, a transport may only advertise a single IPV4 address.
+{%- endtrans %}
      
+
+
      {% trans -%}
+Work continues on adjusting default connection limits for each transport.
+I2P is designed as a "mesh network", where it is assumed that any router can connect to any other router.
+This assumption may be broken by routers that have exceeded their connection limits, and by
+routers that are behind restrictive state firewalls (restricted routes).
+{%- endtrans %}
      
+
+
      {% trans -%}
+The current connection limits are higher for SSU than for NTCP, based on the assumption that
+the memory requirements for an NTCP connection are higher than that for SSU.
+However, as NTCP buffers are partially in the kernel and SSU buffers are on the Java heap,
+that assumption is difficult to verify.
+{%- endtrans %}
      
+
+
      {% trans pdf='http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf' -%}
+Analyze Breaking and Improving Protocol Obfuscation
+and see how transport-layer padding may improve things.
+{%- endtrans %}
      
+
+
+{% endblock %}
diff --git a/www.i2p2/pages/ntcp.html b/i2p2www/pages/site/docs/transport/ntcp.html
similarity index 52%
rename from www.i2p2/pages/ntcp.html
rename to i2p2www/pages/site/docs/transport/ntcp.html
index 54008d93..bb7053e0 100644
--- a/www.i2p2/pages/ntcp.html
+++ b/i2p2www/pages/site/docs/transport/ntcp.html
@@ -1,65 +1,65 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}NTCP{% endblock %}
+{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
 {% block content %}
+
      {% trans %}NTCP (NIO-based TCP){% endtrans %}
      
 
-Updated August 2010 for release 0.8
-
-
      NTCP (NIO-based TCP)
      
-
-
      
-NTCP
-is one of two transports currently implemented in I2P.
-The other is SSU.
-NTCP
-is a Java NIO-based transport
-introduced in I2P release 0.6.1.22.
+
      {% trans transports=site_url('docs/transport'), ssu=site_url('docs/transport/ssu') -%}
+NTCP is one of two transports currently implemented in I2P.
+The other is SSU.
+NTCP is a Java NIO-based transport introduced in I2P release 0.6.1.22.
 Java NIO (new I/O) does not suffer from the 1 thread per connection issues of the old TCP transport.
-
      
+{%- endtrans %}
      
 
-By default,
-NTCP uses the IP/Port
+
      {% trans -%}
+By default, NTCP uses the IP/Port
 auto-detected by SSU. When enabled on config.jsp,
 SSU will notify/restart NTCP when the external address changes
 or when the firewall status changes.
 Now you can enable inbound TCP without a static IP or dyndns service.
-
      
+{%- endtrans %}
      
 
+
      {% trans -%}
 The NTCP code within I2P is relatively lightweight (1/4 the size of the SSU code)
 because it uses the underlying Java TCP transport for reliable delivery.
-
      
+{%- endtrans %}
      
 
 
-
      NTCP Protocol Specification
      
+
      {% trans %}NTCP Protocol Specification{% endtrans %}
      
 
-
      Standard Message Format
      
-
      
-  After establishment,
-  the NTCP transport sends individual I2NP messages, with a simple checksum.
-  The unencrypted message is encoded as follows:
+
      {% trans %}Standard Message Format{% endtrans %}
      
+
      {% trans -%}
+After establishment,
+the NTCP transport sends individual I2NP messages, with a simple checksum.
+The unencrypted message is encoded as follows:
+{%- endtrans %}
      
 
        *  +-------+-------+--//--+---//----+-------+-------+-------+-------+
  *  | sizeof(data)  | data | padding | Adler checksum of sz+data+pad |
  *  +-------+-------+--//--+---//----+-------+-------+-------+-------+
 
      
-  The data is then AES/256/CBC encrypted. The session key for the encryption
-  is negotiated during establishment (using Diffie-Hellman 2048 bit).
-  The establishment between two routers is implemented in the EstablishState class
-  and detailed below.
-  The IV for AES/256/CBC encryption is the last 16 bytes of the previous encrypted message.
-
      
+
      {% trans -%}
+The data is then AES/256/CBC encrypted. The session key for the encryption
+is negotiated during establishment (using Diffie-Hellman 2048 bit).
+The establishment between two routers is implemented in the EstablishState class
+and detailed below.
+The IV for AES/256/CBC encryption is the last 16 bytes of the previous encrypted message.
+{%- endtrans %}
      
 
-
      
+
      {% trans -%}
 0-15 bytes of padding are required to bring the total message length
 (including the six size and checksum bytes) to a multiple of 16.
 The maximum message size is currently 16 KB.
 Therefore the maximum data size is currently 16 KB - 6, or 16378 bytes.
 The minimum data size is 1.
-
      
+{%- endtrans %}
      
 
-
      Time Sync Message Format
      
-
      
-  One special case is a metadata message where the sizeof(data) is 0.  In
-  that case, the unencrypted message is encoded as:
+
      {% trans %}Time Sync Message Format{% endtrans %}
      
+
      {% trans -%}
+One special case is a metadata message where the sizeof(data) is 0.  In
+that case, the unencrypted message is encoded as:
+{%- endtrans %}
      
 
        *  +-------+-------+-------+-------+-------+-------+-------+-------+
  *  |       0       |      timestamp in seconds     | uninterpreted             
@@ -67,19 +67,25 @@ The minimum data size is 1.
  *          uninterpreted           | Adler checksum of bytes 0-11  |
  *  +-------+-------+-------+-------+-------+-------+-------+-------+
 
      
+
      {% trans -%}
 Total length: 16 bytes. The time sync message is sent at approximately 15 minute intervals.
 The message is encrypted just as standard messages are.
+{%- endtrans %}
      
 
 
-
      Checksums
      
+
      {% trans %}Checksums{% endtrans %}
      
+
      {% trans rfc1950='http://tools.ietf.org/html/rfc1950' -%}
 The standard and time sync messages use the Adler-32 checksum
-as defined in the ZLIB Specification.
+as defined in the ZLIB Specification.
+{%- endtrans %}
      
 
 
-
      Establishment Sequence
      
+
      {% trans %}Establishment Sequence{% endtrans %}
      
+
      {% trans -%}
 In the establish state, there is a 4-phase message sequence to exchange DH keys and signatures.
 In the first two messages there is a 2048-bit Diffie Hellman exchange.
 Then, DSA signatures of the critical data are exchanged to confirm the connection.
+{%- endtrans %}
      
 
        * Alice                   contacts                      Bob
  * =========================================================
@@ -91,57 +97,58 @@ Then, DSA signatures of the critical data are exchanged to confirm the connectio
 
      
 
 
      -  Legend:
-    X, Y: 256 byte DH public keys
+  {% trans %}Legend:{% endtrans %}
+    X, Y: {% trans %}256 byte DH public keys{% endtrans %}
     H(): 32 byte SHA256 Hash
     E(data, session key, IV): AES256 Encrypt
     S(): 40 byte DSA Signature
-    tsA, tsB: timestamps (4 bytes, seconds since epoch)
-    sk: 32 byte Session key
-    sz: 2 byte size of Alice identity to follow
+    tsA, tsB: {% trans %}timestamps (4 bytes, seconds since epoch){% endtrans %}
+    sk: {% trans %}32 byte Session key{% endtrans %}
+    sz: {% trans %}2 byte size of Alice identity to follow{% endtrans %}
 
      
 
-
      DH Key Exchange
      
-
      
+
      {% trans %}DH Key Exchange{% endtrans %}
      
+
      {% trans cryptography=site_url('docs/how/cryptography') -%}
 The initial 2048-bit DH key exchange
 uses the same shared prime (p) and generator (g) as that used for I2P's
-ElGamal encryption.
-
      
+ElGamal encryption.
+{%- endtrans %}
      
 
-
      
+
      {% trans -%}
 The DH key exchange consists of a number of steps, displayed below.
 The mapping between these steps and the messages sent between I2P routers,
 is marked in bold.
+{%- endtrans %}
      
   
        
-    
      1. Alice generates a secret 226-bit integer x.
-        She then calculates X = g^x mod p.
-    
        2. 
-    
      2. Alice sends X to Bob (Message 1).
        3. 
-    
      3. Bob generates a secret 226-bit integer y.
-        He then calculates Y = g^y mod p.
        4. 
-    
      4. Bob sends Y to Alice.(Message 2)
        5. 
-    
      5. Alice can now compute sessionKey = Y^x mod p.
        6. 
-    
      6. Bob can now compute sessionKey = X^y mod p.
        7. 
-    
      7. Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod p.
        8. 
+    
      8. {% trans %}Alice generates a secret 226-bit integer x. She then calculates X = g^x mod p.{% endtrans %}
        9. 
+    
      9. {% trans %}Alice sends X to Bob (Message 1).{% endtrans %}
        10. 
+    
      10. {% trans %}Bob generates a secret 226-bit integer y. He then calculates Y = g^y mod p.{% endtrans %}
        11. 
+    
      11. {% trans %}Bob sends Y to Alice.(Message 2){% endtrans %}
        12. 
+    
      12. {% trans %}Alice can now compute sessionKey = Y^x mod p.{% endtrans %}
        13. 
+    
      13. {% trans %}Bob can now compute sessionKey = X^y mod p.{% endtrans %}
        14. 
+    
      14. {% trans %}Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod p.{% endtrans %}
        15. 
   
      
+
      {% trans -%}
 The sessionKey is then used to exchange identities in Message 3 and Message 4.
-
      
+{%- endtrans %}
      
 
-
      Message 1 (Session Request)
      
-This is the DH request.
-Alice already has Bob's
-Router Identity,
+
      {% trans %}Message 1 (Session Request){% endtrans %}
      
+
      {% trans commonstructures=site_url('docs/spec/common-structures'),
+netdb=site_url('docs/how/network-database') -%}
+This is the DH request. Alice already has Bob's
+Router Identity,
 IP address, and port, as contained in his
-Router Info,
+Router Info,
 which was published to the
-network database.
+network database.
 Alice sends Bob:
+{%- endtrans %}
      
 
        *  X+(H(X) xor Bob.identHash)----------------------------->
 
-    Size: 288 bytes
+    {% trans %}Size:{% endtrans %} 288 bytes
 
      
-Contents:
+
      {% trans %}Contents:{% endtrans %}
      
 
        +----+----+----+----+----+----+----+----+
  |         X, as calculated from DH      |
@@ -159,28 +166,32 @@ Contents:
  |                                       |
  +----+----+----+----+----+----+----+----+
 
-  X: 256 byte X from Diffie Hellman
+  X: {% trans %}256 byte X from Diffie Hellman{% endtrans %}
 
-  HXxorHI:  SHA256 Hash(X) xored with SHA256 Hash(Bob's Router Identity)
+  HXxorHI:  {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+SHA256 Hash(X) xored with SHA256 Hash(Bob's Router Identity)
+{%- endtrans %}
             (32 bytes)
 
 
      
 
-
      Notes:
-
      • 
+
        {% trans %}Notes:{% endtrans %}
+
        • {% trans -%}
 Bob verifies HXxorHI using his own router hash. If it does not verify,
 Alice has contacted the wrong router, and Bob drops the connection.
-
        
+{%- endtrans %}
      
 
 
-
      Message 2 (Session Created)
      
+
      {% trans %}Message 2 (Session Created){% endtrans %}
      
+
      {% trans -%}
 This is the DH reply. Bob sends Alice:
+{%- endtrans %}
      
 
        *  <----------------------------------------Y+E(H(X+Y)+tsB+padding, sk, Y[239:255])
 
-    Size: 304 bytes
+    {% trans %}Size:{% endtrans %} 304 bytes
 
      
-Unencrypted Contents:
+
      {% trans %}Unencrypted Contents:{% endtrans %}
      
 
        +----+----+----+----+----+----+----+----+
  |         Y as calculated from DH       |
@@ -202,19 +213,19 @@ Unencrypted Contents:
  |                                       |
  +----+----+----+----+----+----+----+----+
 
-  Y: 256 byte Y from Diffie Hellman
+  Y: {% trans %}256 byte Y from Diffie Hellman{% endtrans %}
 
-  HXY:  SHA256 Hash(X concatenated with Y)
+  HXY:  {% trans %}SHA256 Hash(X concatenated with Y){% endtrans %}
         (32 bytes)
 
-  tsB: 4 byte timestamp (seconds since the epoch)
+  tsB: {% trans %}4 byte timestamp (seconds since the epoch){% endtrans %}
 
-  padding: 12 bytes random data
+  padding: {% trans %}12 bytes random data{% endtrans %}
 
 
      
 
 
-Encrypted Contents:
+
      {% trans %}Encrypted Contents:{% endtrans %}
      
 
        +----+----+----+----+----+----+----+----+
  |         Y as calculated from DH       |
@@ -236,29 +247,31 @@ Encrypted Contents:
  |                                       |
  +----+----+----+----+----+----+----+----+
 
-  Y: 256 byte Y from Diffie Hellman
+  Y: {% trans %}256 byte Y from Diffie Hellman{% endtrans %}
 
-  encrypted data: 48 bytes AES encrypted using the DH session key and
-                  the last 16 bytes of Y as the IV
+  encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
+48 bytes AES encrypted using the DH session key and
+                  the last 16 bytes of Y as the IV{% endtrans %}
 
 
      
 
 
-
      Notes:
-
      • 
+
        {% trans %}Notes:{% endtrans %}
        
+
        • {% trans -%}
 Alice may drop the connection if the clock skew with Bob is too high as calculated using tsB.
-
        
-
        
+{%- endtrans %}
      
 
 
-
      Message 3 (Session Confirm A)
      
+
      {% trans %}Message 3 (Session Confirm A){% endtrans %}
      
+
      {% trans -%}
 This contains Alice's router identity, and a DSA signature of the critical data. Alice sends Bob:
+{%- endtrans %}
      
 
        *  E(sz+Alice.identity+tsA+padding+S(X+Y+Bob.identHash+tsA+tsB), sk, hX_xor_Bob.identHash[16:31])--->
 
-    Size: 448 bytes (typ. for 387 byte identity)
+    {% trans %}Size:{% endtrans %} 448 bytes (typ. for 387 byte identity)
 
      
-Unencrypted Contents:
+
      {% trans %}Unencrypted Contents:{% endtrans %}
      
 
        +----+----+----+----+----+----+----+----+
  |   sz    | Alice's Router Identity     |
@@ -284,21 +297,25 @@ Unencrypted Contents:
  |                                       |
  +----+----+----+----+----+----+----+----+
 
-  sz: 2 byte size of Alice's router identity to follow (should always be 387)
+  sz: {% trans %}2 byte size of Alice's router identity to follow (should always be 387){% endtrans %}
 
-  ident: Alice's 387 byte Router Identity
+  ident: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+Alice's 387 byte Router Identity
+{%- endtrans %}
 
-  tsA: 4 byte timestamp (seconds since the epoch)
+  tsA: {% trans %}4 byte timestamp (seconds since the epoch){% endtrans %}
 
-  padding: 15 bytes random data
+  padding: {% trans %}15 bytes random data{% endtrans %}
 
-  signature: the 40 byte DSA signature of the following concatenated data:
-             X, Y, Bob's Router Identity, tsA, tsB.
-             Alice signs it with the private signing key associated with the public signing key in her Router Identity
+  signature: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+the 40 byte DSA signature of the following concatenated data:
+             X, Y, Bob's Router Identity, tsA, tsB.
+             Alice signs it with the private signing key associated with the public signing key in her Router Identity
+{%- endtrans %}
 
 
      
 
-Encrypted Contents:
+
      {% trans %}Encrypted Contents:{% endtrans %}
      
 
        +----+----+----+----+----+----+----+----+
  |                                       |
@@ -308,30 +325,36 @@ Encrypted Contents:
  |                                       |
  +----+----+----+----+----+----+----+----+
 
-  encrypted data: 448 bytes AES encrypted using the DH session key and
+  encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
+448 bytes AES encrypted using the DH session key and
                   the last 16 bytes of HXxorHI (i.e., the last 16 bytes of message #1) as the IV
+{%- endtrans %}
 
 
      
 
 
-
      Notes:
-
      • 
+
        {% trans %}Notes:{% endtrans %}
        
+
          
+
        • {% trans -%}
 Bob verifies the signature, and on failure, drops the connection.
-
        • 
+{%- endtrans %}
          • 
+
        • {% trans -%}
 Bob may drop the connection if the clock skew with Alice is too high as calculated using tsA.
-
        
-
        
+{%- endtrans %}
        • 
+
      
 
 
 
-
      Message 4 (Session Confirm B)
      
+
      {% trans %}Message 4 (Session Confirm B){% endtrans %}
      
+
      {% trans -%}
 This is a DSA signature of the critical data. Bob sends Alice:
+{%- endtrans %}
      
 
        *  <----------------------E(S(X+Y+Alice.identHash+tsA+tsB)+padding, sk, prev)
 
-    Size: 48 bytes
+    {% trans %}Size:{% endtrans %} 48 bytes
 
      
-Unencrypted Contents:
+
      {% trans %}Unencrypted Contents:{% endtrans %}
      
 
        +----+----+----+----+----+----+----+----+
  |                                       |
@@ -348,16 +371,18 @@ Unencrypted Contents:
  +----+----+----+----+----+----+----+----+
 
 
-  signature: the 40 byte DSA signature of the following concatenated data:
-             X, Y, Alice's Router Identity, tsA, tsB.
-             Bob signs it with the private signing key associated with the public signing key in his Router Identity
+  signature: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
+the 40 byte DSA signature of the following concatenated data:
+             X, Y, Alice's Router Identity, tsA, tsB.
+             Bob signs it with the private signing key associated with the public signing key in his Router Identity
+{%- endtrans %}
 
-  padding: 8 bytes random data
+  padding: {% trans %}8 bytes random data{% endtrans %}
 
 
      
 
 
-Encrypted Contents:
+
      {% trans %}Encrypted Contents:{% endtrans %}
      
 
        +----+----+----+----+----+----+----+----+
  |                                       |
@@ -367,68 +392,82 @@ Encrypted Contents:
  |                                       |
  +----+----+----+----+----+----+----+----+
 
-  encrypted data: 48 bytes AES encrypted using the DH session key and
+  encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
+48 bytes AES encrypted using the DH session key and
                   the last 16 bytes of the encrypted contents of message #2 as the IV
+{%- endtrans %}
 
 
      
 
-
      Notes:
-
      • 
+
        Notes:
        
+
        • {% trans -%}
 Alice verifies the signature, and on failure, drops the connection.
-
        
-
        
+{%- endtrans %}
      
 
 
 
 
-
      After Establishment
      
-
      
+
      {% trans %}After Establishment{% endtrans %}
      
+
      {% trans -%}
 The connection is established, and standard or time sync messages may be exchanged.
 All subsequent messages are AES encrypted using the negotiated DH session key.
 Alice will use the last 16 bytes of the encrypted contents of message #3 as the next IV.
 Bob will use the last 16 bytes of the encrypted contents of message #4 as the next IV.
-
      
+{%- endtrans %}
      
 
 
 
-
      Check Connection Message
      
+
      {% trans %}Check Connection Message{% endtrans %}
      
+
      {% trans -%}
 Alternately, when Bob receives a connection, it could be a
 check connection (perhaps prompted by Bob asking for someone
 to verify his listener).
 Check Connection is not currently used.
 However, for the record, check connections are formatted as follows.
-     A check info connection will receive 256 bytes containing:
+A check info connection will receive 256 bytes containing:
+{%- endtrans %}
      
 
        
-     
      •  32 bytes of uninterpreted, ignored data
-     
      •  1 byte size
-     
      •  that many bytes making up the local router's IP address (as reached by the remote side)
-     
      •  2 byte port number that the local router was reached on
-     
      •  4 byte i2p network time as known by the remote side (seconds since the epoch)
-     
      •  uninterpreted padding data, up to byte 223
-     
      •  xor of the local router's identity hash and the SHA256 of bytes 32 through bytes 223
+     
      • {% trans %}32 bytes of uninterpreted, ignored data{% endtrans %}
        • 
+     
      • {% trans %}1 byte size{% endtrans %}
        • 
+     
      • {% trans %}that many bytes making up the local router's IP address (as reached by the remote side){% endtrans %}
        • 
+     
      • {% trans %}2 byte port number that the local router was reached on{% endtrans %}
        • 
+     
      • {% trans %}4 byte i2p network time as known by the remote side (seconds since the epoch){% endtrans %}
        • 
+     
      • {% trans %}uninterpreted padding data, up to byte 223{% endtrans %}
        • 
+     
      • {% trans %}xor of the local router's identity hash and the SHA256 of bytes 32 through bytes 223{% endtrans %}
        • 
 
      
 
    • 
 
-
    Discussion
    
-Now on the NTCP Discussion Page.
+
    {% trans %}Discussion{% endtrans %}
    
+
    {% trans ntcpdisc=site_url('docs/discussions/ntcp') -%}
+Now on the NTCP Discussion Page.
+{%- endtrans %}
    
 
-
    Future Work
    
-
    • 
+
      {% trans %}Future Work{% endtrans %}
      
+
        
+
      • {% trans -%}
 The maximum message size should be increased to approximately 32 KB.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 A set of fixed packet sizes may be appropriate to further hide the data 
 fragmentation to external adversaries, but the tunnel, garlic, and end to 
 end padding should be sufficient for most needs until then.
 However, there is currently no provision for padding beyond the next 16-byte boundary,
 to create a limited number of message sizes.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Memory utilization (including that of the kernel) for NTCP should be compared to that for SSU.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Can the establishment messages be randomly padded somehow, to frustrate
 identification of I2P traffic based on initial packet sizes?
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Review and possibly disable 'check connection'
-
      
-
      
+{%- endtrans %}
      • 
+
    
 
 {% endblock %}
diff --git a/www.i2p2/pages/udp.html b/i2p2www/pages/site/docs/transport/ssu.html
similarity index 66%
rename from www.i2p2/pages/udp.html
rename to i2p2www/pages/site/docs/transport/ssu.html
index b5b75a38..a7ae3caa 100644
--- a/www.i2p2/pages/udp.html
+++ b/i2p2www/pages/site/docs/transport/ssu.html
@@ -1,51 +1,60 @@
-{% extends "_layout.html" %}
-{% block title %}SSU Transport{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}SSU Transport{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}October 2012{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.2{% endblock %}
 {% block content %}
-
-Updated October 2012 for release 0.9.2
-
-
    Secure Semireliable UDP (SSU)
    
-
    
+
    {% trans %}Secure Semireliable UDP{% endtrans %} (SSU)
    
+
    {% trans transports=site_url('docs/transport'), ntcp=site_url('docs/transport/ntcp') -%}
 SSU (also called "UDP" in much of the I2P documentation and user interfaces)
-is one of two transports currently implemented in I2P.
-The other is NTCP.
-
    
+is one of two transports currently implemented in I2P.
+The other is NTCP.
+{%- endtrans %}
    
+
+
    {% trans -%}
 SSU is the newer of the two transports,
 introduced in I2P release 0.6.
 In a standard I2P installation, the router uses both NTCP and SSU for outbound connections.
+{%- endtrans %}
    
 
-
    SSU Services
    
+
    {% trans %}SSU Services{% endtrans %}
    
 
+
    {% trans -%}
 Like the NTCP transport, SSU provides reliable, encrypted, connection-oriented, point-to-point data transport.
 Unique to SSU, it also provides IP detection and NAT traversal services, including:
+{%- endtrans %}
    
 
 
      
-
    • Cooperative NAT/Firewall traversal using introducers
-
    • Local IP detection by inspection of incoming packets and peer testing
-
    • Communication of firewall status and local IP, and changes to either to NTCP
-
    • Communication of firewall status and local IP, and changes to either, to the router and the user interface
+
    • {% trans %}Cooperative NAT/Firewall traversal using introducers{% endtrans %}
      • 
+
    • {% trans %}Local IP detection by inspection of incoming packets and peer testing{% endtrans %}
      • 
+
    • {% trans %}Communication of firewall status and local IP, and changes to either to NTCP{% endtrans %}
      • 
+
    • {% trans %}Communication of firewall status and local IP, and changes to either, to the router and the user interface{% endtrans %}
      • 
 
    
 
 
-
    Protocol Details
    
+
    {% trans %}Protocol Details{% endtrans %}
    
 
-
    Congestion control
    
+
    {% trans %}Congestion control{% endtrans %}
    
 
-
    SSU's need for only semireliable delivery, TCP-friendly operation,
+
    {% trans -%}
+SSU's need for only semireliable delivery, TCP-friendly operation,
 and the capacity for high throughput allows a great deal of latitude in
 congestion control.  The congestion control algorithm outlined below is
-meant to be both efficient in bandwidth as well as simple to implement.
    
+meant to be both efficient in bandwidth as well as simple to implement.
+{%- endtrans %}
    
 
-
    Packets are scheduled according to the router's policy, taking care
+
    {% trans -%}
+Packets are scheduled according to the router's policy, taking care
 not to exceed the router's outbound capacity or to exceed the measured 
 capacity of the remote peer.  The measured capacity operates along the
 lines of TCP's slow start and congestion avoidance, with additive increases
 to the sending capacity and multiplicative decreases in face of congestion.
 Unlike for TCP, routers may give up on some messages after
 a given period or number of retransmissions while continuing to transmit 
-other messages.
    
+other messages.
+{%- endtrans %}
    
   
-
    The congestion detection techniques vary from TCP as well, since each 
+
    {% trans -%}
+The congestion detection techniques vary from TCP as well, since each 
 message has its own unique and nonsequential identifier, and each message
 has a limited size - at most, 32KB.  To efficiently transmit this feedback
 to the sender, the receiver periodically includes a list of fully ACKed 
@@ -53,48 +62,62 @@ message identifiers and may also include bitfields for partially received
 messages, where each bit represents the reception of a fragment.  If 
 duplicate fragments arrive, the message should be ACKed again, or if the
 message has still not been fully received, the bitfield should be 
-retransmitted with any new updates.
    
+retransmitted with any new updates.
+{%- endtrans %}
    
 
-
    The current implementation does not pad the packets to
+
    {% trans -%}
+The current implementation does not pad the packets to
 any particular size, but instead just places a single message fragment into
 a packet and sends it off (careful not to exceed the MTU).
-
    
+{%- endtrans %}
    
 
 
    MTU
    
-
    
+
    {% trans -%}
 As of router version 0.8.12,
 two MTU values are used: 620 and 1484.
 The MTU value is adjusted based on the percentage of packets that are retransmitted.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 For both MTU values, it is desirable that (MTU % 16) == 12, so that
 the payload portion after the 28-byte IP/UDP header is a multiple of
 16 bytes, for encryption purposes.
 This calculation is for IPv4 only. While the protocol as specified supports IPv6
 addresses, IPv6 is not yet implemented.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 For the small MTU value, it is desirable to pack a 2646-byte
 Variable Tunnel Build Message efficiently into multiple packets;
 with a 620-byte MTU, it fits into 5 packets with nicely.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 Based on measurements, 1492 fits nearly all reasonably small I2NP messages
 (larger I2NP messages may be up to 1900 to 4500 bytes, which isn't going to fit
 into a live network MTU anyway).
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The MTU values were 608 and 1492 for releases 0.8.9 - 0.8.11.
 The large MTU was 1350 prior to release 0.8.9.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The maximum receive packet size
 is 1571 bytes as of release 0.8.12.
 For releases 0.8.9 - 0.8.11 it was 1535 bytes.
 Prior to release 0.8.9 it was 2048 bytes.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 As of release 0.9.2, if a router's network interface MTU is less than 1484,
 it will publish that in the network database, and other routers should
 honor that when a connection is established.
-
    
+{%- endtrans %}
    
 
-
    Message Size Limits
    
-
    
+
    {% trans %}Message Size Limits{% endtrans %}
    
+
    {% trans -%}
 While the maximum message size is nominally 32KB, the practical
 limit differs. The protocol limits the number of fragments to 7 bits, or 128.
 The current implementation, however, limits each message to a maximum of 64 fragments,
@@ -103,97 +126,115 @@ Due to overhead for bundled LeaseSets and session keys, the practical limit
 at the application level is about 6KB lower, or about 26KB.
 Further work is necessary to raise the UDP transport limit above 32KB.
 For connections using the larger MTU, larger messages are possible.
-
    
+{%- endtrans %}
    
 
-
    Keys
    
+
    {% trans %}Keys{% endtrans %}
    
 
-
    All encryption used is AES256/CBC with 32 byte keys and 16 byte IVs.
+
    {% trans -%}
+All encryption used is AES256/CBC with 32 byte keys and 16 byte IVs.
 The MAC and session keys are negotiated as part of the DH exchange, used
 for the HMAC and encryption, respectively.  Prior to the DH exchange, 
-the publicly knowable introKey is used for the MAC and encryption.
    
+the publicly knowable introKey is used for the MAC and encryption.
+{%- endtrans %}
    
 
-
    When using the introKey, both the initial message and any subsequent
+
    {% trans -%}
+When using the introKey, both the initial message and any subsequent
 reply use the introKey of the responder (Bob) - the responder does 
 not need to know the introKey of the requester (Alice).  The DSA 
 signing key used by Bob should already be known to Alice when she 
 contacts him, though Alice's DSA key may not already be known by 
-Bob.
    
+Bob.
+{%- endtrans %}
    
 
-
    Upon receiving a message, the receiver checks the "from" IP address and port
+
    {% trans -%}
+Upon receiving a message, the receiver checks the "from" IP address and port
 with all established sessions - if there are matches,
 that session's MAC keys are tested in the HMAC.  If none
 of those verify or if there are no matching IP addresses, the 
 receiver tries their introKey in the MAC.  If that does not verify,
 the packet is dropped.  If it does verify, it is interpreted 
 according to the message type, though if the receiver is overloaded,
-it may be dropped anyway.
    
+it may be dropped anyway.
+{%- endtrans %}
    
 
-
    If Alice and Bob have an established session, but Alice loses the 
+
    {% trans -%}
+If Alice and Bob have an established session, but Alice loses the 
 keys for some reason and she wants to contact Bob, she may at any 
 time simply establish a new session through the SessionRequest and
 related messages.  If Bob has lost the key but Alice does not know
 that, she will first attempt to prod him to reply, by sending a 
 DataMessage with the wantReply flag set, and if Bob continually 
 fails to reply, she will assume the key is lost and reestablish a 
-new one.
    
+new one.
+{%- endtrans %}
    
 
-
    For the DH key agreement,
-RFC3526 2048bit
-MODP group (#14) is used:
    
+
    {% trans rfc3526='http://www.faqs.org/rfcs/rfc3526.html' -%}
+For the DH key agreement,
+RFC3526 2048bit
+MODP group (#14) is used:
+{%- endtrans %}
    
 
       p = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
   g = 2
 
    
 
-
    
+
    {% trans cryptography=site_url('docs/how/cryptography') -%}
 These are the same p and g used for I2P's
-ElGamal encryption.
-
    
+ElGamal encryption.
+{%- endtrans %}
    
 
-
    Replay prevention
    
+
    {% trans %}Replay prevention{% endtrans %}
    
 
-
    Replay prevention at the SSU layer occurs by rejecting packets 
+
    {% trans -%}
+Replay prevention at the SSU layer occurs by rejecting packets 
 with exceedingly old timestamps or those which reuse an IV.  To
 detect duplicate IVs, a sequence of Bloom filters are employed to
-"decay" periodically so that only recently added IVs are detected.
    
+"decay" periodically so that only recently added IVs are detected.
+{%- endtrans %}
    
 
-
    The messageIds used in DataMessages are defined at layers above
+
    {% trans -%}
+The messageIds used in DataMessages are defined at layers above
 the SSU transport and are passed through transparently.  These IDs
 are not in any particular order - in fact, they are likely to be
 entirely random.  The SSU layer makes no attempt at messageId 
-replay prevention - higher layers should take that into account.
    
+replay prevention - higher layers should take that into account.
+{%- endtrans %}
    
 
-
    Addressing
    
+
    {% trans %}Addressing{% endtrans %}
    
 
-
    To contact an SSU peer, one of two sets of information is necessary:
-a direct address, for when the peer is publicly reachable, or an 
-indirect address, for using a third party to introduce the peer.  
-There is no restriction on the number of addresses a peer may have.
    
+
    {% trans -%}
+To contact an SSU peer, one of two sets of information is necessary:
+a direct address, for when the peer is publicly reachable, or an
+indirect address, for using a third party to introduce the peer.
+There is no restriction on the number of addresses a peer may have.
+{%- endtrans %}
    
 
 
         Direct: host, port, introKey, options
   Indirect: tag, relayhost, port, relayIntroKey, targetIntroKey, options
 
    
 
-
    Each of the addresses may also expose a series of options - special
+
    {% trans -%}
+Each of the addresses may also expose a series of options - special
 capabilities of that particular peer.  For a list of available
-capabilities, see below.
    
+capabilities, see below.
+{%- endtrans %}
    
 
-
    
-The addresses, options, and capabilities are published in the network database.
-
    
+
    {% trans netdb=site_url('docs/how/network-database') -%}
+The addresses, options, and capabilities are published in the network database.
+{%- endtrans %}
    
 
 
-
    Direct Session Establishment
    
-
    
+
    {% trans %}Direct Session Establishment{% endtrans %}
    
+
    {% trans -%}
 Direct session establishment is used when no third party is required for NAT traversal.
 The message sequence is as follows:
-
    
+{%- endtrans %}
    
 
-
    Connection establishment (direct)
    
-
    
+
    {% trans %}Connection establishment (direct){% endtrans %}
    
+
    {% trans -%}
 Alice connects directly to Bob.
-
    
+{%- endtrans %}
    
 
             Alice                         Bob
     SessionRequest --------------------->
@@ -204,28 +245,35 @@ Alice connects directly to Bob.
     DatabaseStoreMessage --------------->
     Data <---------------------------> Data
 
    
-
    
+
+
    {% trans i2npspec=site_url('docs/spec/i2np') -%}
 After the SessionConfirmed message is received, Bob sends a small
-DeliveryStatus message
+DeliveryStatus message
 as a confirmation.
 In this message, the 4-byte message ID is set to a random number, and the
 8-byte "arrival time" is set to the current network-wide ID, which is 2
 (i.e. 0x0000000000000002).
-
    
+{%- endtrans %}
    
+
+
    {% trans i2npspec=site_url('docs/spec/i2np'),
+commonstructures=site_url('docs/spec/common-structures') -%}
 After the status message is sent, the peers exchange
-DatabaseStore messages
+DatabaseStore messages
 containing their
-RouterInfos.
-
    
+RouterInfos.
+{%- endtrans %}
    
+
+
    {% trans -%}
 It does not appear that the type of the status message or its contents matters.
 It was originally added becasue the DatabaseStore message was delayed
 several seconds; since the store is now sent immediately, perhaps
 the status message can be eliminated.
-
    
+{%- endtrans %}
    
 
-
    Introduction
    
+
    {% trans %}Introduction{% endtrans %}
    
 
-
    Introduction keys are delivered through an external channel 
+
    {% trans -%}
+Introduction keys are delivered through an external channel 
 (the network database, where they are identical to the router Hash for now)
 and must be used when establishing a session key.  For the indirect
 address, the peer must first contact the relayhost and ask them for
@@ -235,9 +283,11 @@ peer telling them to contact the requesting peer, and also gives
 the requesting peer the IP and port on which the addressed peer is
 located.  In addition, the peer establishing the connection must 
 already know the public keys of the peer they are connecting to (but
-not necessary to any intermediary relay peer).
    
+not necessary to any intermediary relay peer).
+{%- endtrans %}
    
 
-
    Indirect session establishment by means of a third party introduction
+
    {% trans -%}
+Indirect session establishment by means of a third party introduction
 is necessary for efficient NAT traversal.  Charlie, a router behind a
 NAT or firewall which does not allow unsolicited inbound UDP packets,
 first contacts a few peers, choosing some to serve as introducers.  Each
@@ -252,7 +302,8 @@ Alice back a RelayResponse packet containing Charlie's public IP and port
 number.  When Charlie receives the RelayIntro packet, he sends off a small
 random packet to Alice's IP and port (poking a hole in his NAT/firewall),
 and when Alice receives Bob's RelayResponse packet, she begins a new 
-full direction session establishment with the specified IP and port.
    
+full direction session establishment with the specified IP and port.
+{%- endtrans %}
    
 
 
 
-
    Connection establishment (indirect using an introducer)
    
+
    {% trans %}Connection establishment (indirect using an introducer){% endtrans %}
    
 
+
    {% trans -%}
 Alice first connects to introducer Bob, who relays the request to Charlie.
+{%- endtrans %}
    
 
 
             Alice                         Bob                  Charlie
@@ -280,18 +333,20 @@ Alice first connects to introducer Bob, who relays the request to Charlie.
     Data <--------------------------------------------------> Data
 
    
 
-
    
+
    {% trans -%}
 After the hole punch, the session is established between Alice and Charlie as in a direct establishment.
-
    
+{%- endtrans %}
    
 
 
-
    Peer testing
    
+
    {% trans %}Peer testing{% endtrans %}
    
 
-
    The automation of collaborative reachability testing for peers is
+
    {% trans -%}
+The automation of collaborative reachability testing for peers is
 enabled by a sequence of PeerTest messages.  With its proper 
 execution, a peer will be able to determine their own reachability
 and may update its behavior accordingly.  The testing process is 
-quite simple:
    
+quite simple:
+{%- endtrans %}
    
 
 
             Alice                  Bob                  Charlie
@@ -304,147 +359,193 @@ quite simple:
    
          <------------------------------------------PeerTest
 
    
 
-
    Each of the PeerTest messages carry a nonce identifying the
+
    {% trans -%}
+Each of the PeerTest messages carry a nonce identifying the
 test series itself, as initialized by Alice.  If Alice doesn't 
 get a particular message that she expects, she will retransmit
 accordingly, and based upon the data received or the messages
 missing, she will know her reachability.  The various end states
-that may be reached are as follows:
    
+that may be reached are as follows:
+{%- endtrans %}
    
 
 
      
-
    • If she doesn't receive a response from Bob, she will retransmit
+
    • {% trans -%}
+If she doesn't receive a response from Bob, she will retransmit
 up to a certain number of times, but if no response ever arrives,
 she will know that her firewall or NAT is somehow misconfigured, 
 rejecting all inbound UDP packets even in direct response to an
 outbound packet.  Alternately, Bob may be down or unable to get 
-Charlie to reply.
      • 
+Charlie to reply.
+{%- endtrans %}
 
-
    • If Alice doesn't receive a PeerTest message with the 
+
    • {% trans -%}
+If Alice doesn't receive a PeerTest message with the 
 expected nonce from a third party (Charlie), she will retransmit
 her initial request to Bob up to a certain number of times, even
 if she has received Bob's reply already.  If Charlie's first message 
 still doesn't get through but Bob's does, she knows that she is
 behind a NAT or firewall that is rejecting unsolicited connection
 attempts and that port forwarding is not operating properly (the
-IP and port that Bob offered up should be forwarded).
      • 
+IP and port that Bob offered up should be forwarded).
+{%- endtrans %}
 
-
    • If Alice receives Bob's PeerTest message and both of Charlie's
+
    • {% trans -%}
+If Alice receives Bob's PeerTest message and both of Charlie's
 PeerTest messages but the enclosed IP and port numbers in Bob's 
 and Charlie's second messages don't match, she knows that she is 
 behind a symmetric NAT, rewriting all of her outbound packets with
 different 'from' ports for each peer contacted.  She will need to
 explicitly forward a port and always have that port exposed for 
-remote connectivity, ignoring further port discovery.
      • 
+remote connectivity, ignoring further port discovery.
+{%- endtrans %}
 
-
    • If Alice receives Charlie's first message but not his second,
+
    • {% trans -%}
+If Alice receives Charlie's first message but not his second,
 she will retransmit her PeerTest message to Charlie up to a 
 certain number of times, but if no response is received she knows
-that Charlie is either confused or no longer online.
      • 
+that Charlie is either confused or no longer online.
+{%- endtrans %}
 
    
 
-
    Alice should choose Bob arbitrarily from known peers who seem
+
    {% trans -%}
+Alice should choose Bob arbitrarily from known peers who seem
 to be capable of participating in peer tests.  Bob in turn should
 choose Charlie arbitrarily from peers that he knows who seem to be
 capable of participating in peer tests and who are on a different
 IP from both Bob and Alice.  If the first error condition occurs
 (Alice doesn't get PeerTest messages from Bob), Alice may decide
-to designate a new peer as Bob and try again with a different nonce.
    
+to designate a new peer as Bob and try again with a different nonce.
+{%- endtrans %}
    
 
-
    Alice's introduction key is included in all of the PeerTest 
+
    {% trans -%}
+Alice's introduction key is included in all of the PeerTest 
 messages so that she doesn't need to already have an established
 session with Bob and so that Charlie can contact her without knowing
 any additional information.  Alice may go on to establish a session
-with either Bob or Charlie, but it is not required.
    
+with either Bob or Charlie, but it is not required.
+{%- endtrans %}
    
 
 
-
    Transmission window, ACKs and Retransmissions
    
-
    
+
    {% trans %}Transmission window, ACKs and Retransmissions{% endtrans %}
    
+
    {% trans ssuspec=site_url('docs/spec/ssu') -%}
 The DATA message may contain ACKs of full messages and
 partial ACKs of individual fragments of a message. See
 the data message section of
-the protocol specification page
+the protocol specification page
 for details.
-
    
+{%- endtrans %}
    
+
+
    {% trans streaming=site_url('docs/api/streaming') -%}
 The details of windowing, ACK, and retransmission strategies are not specified
 here. See the Java code for the current implementation.
 During the establishment phase, and for peer testing, routers
 should implement exponential backoff for retransmission.
 For an established connection, routers should implement
 an adjustable transmission window, RTT estimate and timeout, similar to TCP
-or streaming.
+or streaming.
 See the code for initial, min and max parameters.
-
    
+{%- endtrans %}
    
 
 
-
    Security
    
-
    
+
    {% trans %}Security{% endtrans %}
    
+
    {% trans -%}
 UDP source addresses may, of course, be spoofed.
 Additionally, the IPs and ports contained inside specific
 SSU messages (RelayRequest, RelayResponse, RelayIntro, PeerTest)
 may not be legitimate.
 Also, certain actions and responses may need to be rate-limited.
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 The details of validation are not specified
 here. Implementers should add defenses where appropriate.
-
    
+{%- endtrans %}
    
 
 
-
    Peer capabilities
    
+
    {% trans %}Peer capabilities{% endtrans %}
    
 
 
    
  
    B
    
- 
    If the peer address contains the 'B' capability, that means 
-     they are willing and able to participate in peer tests as
-     a 'Bob' or 'Charlie'.
    
+ 
    {% trans -%}
+If the peer address contains the 'B' capability, that means 
+they are willing and able to participate in peer tests as
+a 'Bob' or 'Charlie'.
+{%- endtrans %}
    
  
    C
    
- 
    If the peer address contains the 'C' capability, that means
-     they are willing and able to serve as an introducer - serving
-     as a Bob for an otherwise unreachable Alice.
    
+ 
    {% trans -%}
+If the peer address contains the 'C' capability, that means
+they are willing and able to serve as an introducer - serving
+as a Bob for an otherwise unreachable Alice.
+{%- endtrans %}
    
 
    
 
-
    Future Work
    
-
    • 
+
      {% trans %}Future Work{% endtrans %}
      
+
        
+
      • {% trans -%}
 Analysis of current SSU performance, including assessment of window size adjustment
 and other parameters, and adjustment of the protocol implementation to improve
 performance, is a topic for future work.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 The current implementation repeatedly sends acknowledgments for the same packets,
 which unnecessarily increases overhead.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 The default small MTU value of 620 should be analyzed and possibly increased.
 The current MTU adjustment strategy should be evaluated.
 Does a streaming lib 1730-byte packet fit in 3 small SSU packets? Probably not.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 The protocol should be extended to exchange MTUs during the setup.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Rekeying is currently unimplemented and may never be.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 The potential use of the 'challenge' fields in RelayIntro and RelayResponse,
 and use of the padding field in SessionRequest and SessionCreated, is undocumented.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 Instead of a single fragment per packet, a more efficient
 strategy may be to bundle multiple message fragments into the same packet,
 so long as it doesn't exceed the MTU.
-
      • 
+{%- endtrans %}
        • 
+
+
      • {% trans -%}
 A set of fixed packet sizes may be appropriate to further hide the data 
 fragmentation to external adversaries, but the tunnel, garlic, and end to 
 end padding should be sufficient for most needs until then.
-
      • 
-Why are introduction keys the same as the router hash, should it be changed, would there be any benefit?
-
      • 
-Capacities appear to be unused.
-
      • 
-Signed-on times in SessionCreated and SessionConfirmed appear to be unused or unverified.
-
      
+{%- endtrans %}
      • 
 
-
      Implementation Diagram
      
+
    • {% trans -%}
+Why are introduction keys the same as the router hash, should it be changed, would there be any benefit?
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Capacities appear to be unused.
+{%- endtrans %}
      • 
+
+
    • {% trans -%}
+Signed-on times in SessionCreated and SessionConfirmed appear to be unused or unverified.
+{%- endtrans %}
      • 
+
    
+
+
    {% trans %}Implementation Diagram{% endtrans %}
    
+
    {% trans -%}
 This diagram
 should accurately reflect the current implementation, however there may be small differences.
+{%- endtrans %}
    
 
    
-
+
 
-
    Specification
    
-Now on the SSU specification page.
+
    {% trans %}Specification{% endtrans %}
    
+{% trans %}Now on the SSU specification page{% endtrans %}.
 
 
 {% endblock %}
diff --git a/www.i2p2/pages/tunnel-alt.html b/i2p2www/pages/site/docs/tunnels/implementation.html
similarity index 56%
rename from www.i2p2/pages/tunnel-alt.html
rename to i2p2www/pages/site/docs/tunnels/implementation.html
index cc64b17b..3c8989a3 100644
--- a/www.i2p2/pages/tunnel-alt.html
+++ b/i2p2www/pages/site/docs/tunnels/implementation.html
@@ -1,14 +1,15 @@
-{% extends "_layout.html" %}
-{% block title %}Tunnel Implementation{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Tunnel Implementation{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}October 2010{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8{% endblock %}
 {% block content %}
 
-This page documents the current tunnel implementation.
-Updated October 2010 for release 0.8
+{% trans %}This page documents the current tunnel implementation.{% endtrans %}
 
+
    {% trans %}Tunnel overview{% endtrans %}
    
 
-
    Tunnel overview
    
-
-
    Within I2P, messages are passed in one direction through a virtual
+
    {% trans -%}
+Within I2P, messages are passed in one direction through a virtual
 tunnel of peers, using whatever means are available to pass the 
 message on to the next hop.  Messages arrive at the tunnel's 
 gateway, get bundled up and/or fragmented into fixed-size tunnel messages, 
@@ -16,175 +17,215 @@ and are forwarded on to the next hop in the tunnel, which processes and verifies
 the validity of the message and sends it on to the next hop, and so on, until
 it reaches the tunnel endpoint.  That endpoint takes the messages
 bundled up by the gateway and forwards them as instructed - either
-to another router, to another tunnel on another router, or locally.
    
+to another router, to another tunnel on another router, or locally.
+{%- endtrans %}
    
 
-
    Tunnels all work the same, but can be segmented into two different
+
    {% trans -%}
+Tunnels all work the same, but can be segmented into two different
 groups - inbound tunnels and outbound tunnels.  The inbound tunnels
 have an untrusted gateway which passes messages down towards the 
 tunnel creator, which serves as the tunnel endpoint.  For outbound 
 tunnels, the tunnel creator serves as the gateway, passing messages
-out to the remote endpoint.
    
+out to the remote endpoint.
+{%- endtrans %}
    
 
-
    The tunnel's creator selects exactly which peers will participate
+
    {% trans -%}
+The tunnel's creator selects exactly which peers will participate
 in the tunnel, and provides each with the necessary configuration
 data.  They may have any number of hops.
 It is the intent to make
 it hard for either participants or third parties to determine the length of 
 a tunnel, or even for colluding participants to determine whether they are a
 part of the same tunnel at all (barring the situation where colluding peers are
-next to each other in the tunnel).
    
+next to each other in the tunnel).
+{%- endtrans %}
    
 
-
    In practice, a series of tunnel pools are used for different
+
    {% trans -%}
+In practice, a series of tunnel pools are used for different
 purposes - each local client destination has its own set of inbound
 tunnels and outbound tunnels, configured to meet its anonymity and
 performance needs.  In addition, the router itself maintains a series
 of pools for participating in the network database and for managing
-the tunnels themselves.
    
+the tunnels themselves.
+{%- endtrans %}
    
 
-
    I2P is an inherently packet switched network, even with these 
+
    {% trans -%}
+I2P is an inherently packet switched network, even with these 
 tunnels, allowing it to take advantage of multiple tunnels running 
 in parallel, increasing resilience and balancing load.  Outside of
 the core I2P layer, there is an optional end to end streaming library 
 available for client applications, exposing TCP-esque operation,
-including message reordering, retransmission, congestion control, etc.
    
+including message reordering, retransmission, congestion control, etc.
+{%- endtrans %}
    
 
-
    
+
    {% trans tunnelrouting=site_url('docs/how/tunnel-routing') -%}
 An overview of I2P tunnel terminology is
-on the tunnel overview page.
-
    
+on the tunnel overview page.
+{%- endtrans %}
    
 
-
    Tunnel Operation (Message Processing)
    
-
    Overview
    
+
    {% trans %}Tunnel Operation (Message Processing){% endtrans %}
    
+
    {% trans %}Overview{% endtrans %}
    
 
-
    After a tunnel is built, I2NP messages are processed and passed through it.
+
    {% trans i2np=site_url('docs/spec/i2np') -%}
+After a tunnel is built, I2NP messages are processed and passed through it.
 Tunnel operation has four distinct processes, taken on by various 
-peers in the tunnel.  
    1. First, the tunnel gateway accumulates a number
+peers in the tunnel.
+{%- endtrans %}
      
+
        
+
      1. {% trans -%}
+First, the tunnel gateway accumulates a number
 of I2NP messages and preprocesses them into tunnel messages for
-delivery.  
      2. Next, that gateway encrypts that preprocessed data, then
-forwards it to the first hop.  
      3. That peer, and subsequent tunnel 
+delivery.
+{%- endtrans %}
        4. 
+
      4. {% trans -%}
+Next, that gateway encrypts that preprocessed data, then
+forwards it to the first hop.
+{%- endtrans %}
        5. 
+
      5. {% trans -%}
+That peer, and subsequent tunnel 
 participants, unwrap a layer of the encryption, verifying that it isn't
-a duplicate, then forward it on to the next peer.  
-
      6. Eventually, the tunnel messages arrive at the endpoint where the I2NP messages
+a duplicate, then forward it on to the next peer.
+{%- endtrans %}
        7. 
+
      7. {% trans -%}
+Eventually, the tunnel messages arrive at the endpoint where the I2NP messages
 originally bundled by the gateway are reassembled and forwarded on as 
-requested.
      
+requested.
+{%- endtrans %}
      2. 
+
    
 
-
    
+
    {% trans -%}
 Intermediate tunnel participants do not know whether they are in an
 inbound or an outbound tunnel; they always "encrypt" for the next hop.
 Therefore, we take advantage of symmetric AES encryption
 to "decrypt" at the outbound tunnel gateway,
 so that the plaintext is revealed at the outbound endpoint.
-
    
+{%- endtrans %}
    
 
    
 
    
-      Inbound and outbound tunnel schematic
+      {{ _('Inbound and outbound tunnel schematic') }}
 
    
 
    
 
 
-
-
-
-
+
+
+
+
 
-
-
-
-
+
+
+
+
+
 
-
+
+
-
-
+
+
 
-
+
+
-
-
+
+
 
-
-
-
-
+
+
+
+
+
 
-
+
+
-
-
+
+
 
-
+
+
-
-
+
+
    RolePreprocessingEncryption OperationPostprocessing{% trans %}Role{% endtrans %}{% trans %}Preprocessing{% endtrans %}{% trans %}Encryption Operation{% endtrans %}{% trans %}Postprocessing{% endtrans %}
 
    Outbound Gateway (Creator)Fragment, Batch, and PadIteratively encrypt (using decryption operations)Forward to next hop
    {% trans %}Outbound Gateway (Creator){% endtrans %}{% trans %}Fragment, Batch, and Pad{% endtrans %}{% trans %}Iteratively encrypt (using decryption operations){% endtrans %}{% trans %}Forward to next hop{% endtrans %}
 
    Participant
    {% trans %}Participant{% endtrans %}
  Decrypt (using an encryption operation)Forward to next hop{% trans %}Decrypt (using an encryption operation){% endtrans %}{% trans %}Forward to next hop{% endtrans %}
 
    Outbound Endpoint
    {% trans %}Outbound Endpoint{% endtrans %}
  Decrypt (using an encryption operation) to reveal plaintext tunnel messageReassemble Fragments, Forward as instructed to Inbound Gateway or Router{% trans %}Decrypt (using an encryption operation) to reveal plaintext tunnel message{% endtrans %}{% trans %}Reassemble Fragments, Forward as instructed to Inbound Gateway or Router{% endtrans %}
 
    
 
 
    Inbound GatewayFragment, Batch, and PadEncryptForward to next hop
    {% trans %}Inbound Gateway{% endtrans %}{% trans %}Fragment, Batch, and Pad{% endtrans %}{% trans %}Encrypt{% endtrans %}{% trans %}Forward to next hop{% endtrans %}
 
    Participant
    {% trans %}Participant{% endtrans %}
  EncryptForward to next hop{% trans %}Encrypt{% endtrans %}{% trans %}Forward to next hop{% endtrans %}
 
    Inbound Endpoint (Creator)
    {% trans %}Inbound Endpoint (Creator){% endtrans %}
  Iteratively decrypt to reveal plaintext tunnel messageReassemble Fragments, Receive data{% trans %}Iteratively decrypt to reveal plaintext tunnel message{% endtrans %}{% trans %}Reassemble Fragments, Receive data{% endtrans %}
 
    
 
    
 
 
 
-
    Gateway Processing
    
-
    Message Preprocessing
    
+
    {% trans %}Gateway Processing{% endtrans %}
    
+
    {% trans %}Message Preprocessing{% endtrans %}
    
 
-
    A tunnel gateway's function is to fragment and pack
-I2NP messages into fixed-size
-tunnel messages
+
    {% trans i2np=site_url('docs/spec/i2np'), tunnelmessage=site_url('docs/spec/tunnel-message') -%}
+A tunnel gateway's function is to fragment and pack
+I2NP messages into fixed-size
+tunnel messages
 and encrypt the tunnel messages.
 Tunnel messages contain the following:
-
+{%- endtrans %}
    
 
      
-
    • A 4 byte Tunnel ID
      • 
-
    • A 16 byte IV (initialization vector)
      • 
-
    • A checksum
-
    • Padding, if necessary
      • 
-
    • One or more { delivery instruction, I2NP message fragment } pairs
      • 
+
    • {% trans %}A 4 byte Tunnel ID{% endtrans %}
      • 
+
    • {% trans %}A 16 byte IV (initialization vector){% endtrans %}
      • 
+
    • {% trans %}A checksum{% endtrans %}
      • 
+
    • {% trans %}Padding, if necessary{% endtrans %}
      • 
+
    • {% trans %}One or more { delivery instruction, I2NP message fragment } pairs{% endtrans %}
      • 
 
    
 
-
    Tunnel IDs are 4 byte numbers used at each hop - participants know what
+
    {% trans -%}
+Tunnel IDs are 4 byte numbers used at each hop - participants know what
 tunnel ID to listen for messages with and what tunnel ID they should be forwarded
 on as to the next hop, and each hop chooses the tunnel ID which they receive messages
 on.  Tunnels themselves are short-lived (10 minutes).
 Even if subsequent tunnels are built using the same sequence of 
-peers, each hop's tunnel ID will change.
    
+peers, each hop's tunnel ID will change.
+{%- endtrans %}
    
 
-
    To prevent adversaries from tagging the messages along the path by adjusting
+
    {% trans -%}
+To prevent adversaries from tagging the messages along the path by adjusting
 the message size, all tunnel messages are a fixed 1024 bytes in size.  To accommodate 
 larger I2NP messages as well as to support smaller ones more efficiently, the
 gateway splits up the larger I2NP messages into fragments contained within each
 tunnel message.  The endpoint will attempt to rebuild the I2NP message from the
-fragments for a short period of time, but will discard them as necessary.
    
-
-
    
+fragments for a short period of time, but will discard them as necessary.
+{%- endtrans %}
    
 
+
    {% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%}
 Details are in the
-tunnel message specification.
+tunnel message specification.
+{%- endtrans %}
    
 
 
+
    {% trans %}Gateway Encryption{% endtrans %}
    
 
-
    Gateway Encryption
    
-
-
    After the preprocessing of messages into a padded payload, the gateway builds
+
    {% trans -%}
+After the preprocessing of messages into a padded payload, the gateway builds
 a random 16 byte IV value, iteratively encrypting it and the tunnel message as
-necessary, and forwards the tuple {tunnelID, IV, encrypted tunnel message} to the next hop.
    
+necessary, and forwards the tuple {tunnelID, IV, encrypted tunnel message} to the next hop.
+{%- endtrans %}
    
 
-
    How encryption at the gateway is done depends on whether the tunnel is an
+
    {% trans -%}
+How encryption at the gateway is done depends on whether the tunnel is an
 inbound or an outbound tunnel.  For inbound tunnels, they simply select a random
 IV, postprocessing and updating it to generate the IV for the gateway and using 
 that IV along side their own layer key to encrypt the preprocessed data.  For outbound 
 tunnels they must iteratively decrypt the (unencrypted) IV and preprocessed 
 data with the IV and layer keys for all hops in the tunnel.  The result of the outbound
 tunnel encryption is that when each peer encrypts it, the endpoint will recover 
-the initial preprocessed data.
    
+the initial preprocessed data.
+{%- endtrans %}
    
 
-
    Participant Processing
    
 
-
    When a peer receives a tunnel message, it checks that the message came from
+
    {% trans %}Participant Processing{% endtrans %}
    
+
+
    {% trans -%}
+When a peer receives a tunnel message, it checks that the message came from
 the same previous hop as before (initialized when the first message comes through
 the tunnel).  If the previous peer is a different router, or if the message has
 already been seen, the message is dropped.  The participant then encrypts the 
@@ -193,9 +234,11 @@ that IV with the participant's layer key to encrypt the data, encrypts the
 current IV with AES256/ECB using their IV key again, then forwards the tuple 
 {nextTunnelId, nextIV, encryptedData} to the next hop.  This double encryption
 of the IV (both before and after use) help address a certain class of
-confirmation attacks.
    
+confirmation attacks.
+{%- endtrans %}
    
 
-
    Duplicate message detection is handled by a decaying Bloom filter on message
+
    {% trans -%}
+Duplicate message detection is handled by a decaying Bloom filter on message
 IVs.  Each router maintains a single Bloom filter to contain the XOR of the IV and
 the first block of the message received for all of the tunnels it is participating
 in, modified to drop seen entries after 10-20 minutes (when the tunnels will have
@@ -203,155 +246,195 @@ expired).  The size of the bloom filter and the parameters used are sufficient t
 more than saturate the router's network connection with a negligible chance of 
 false positive.  The unique value fed into the Bloom filter is the XOR of the IV 
 and the first block so as to prevent nonsequential colluding peers in the tunnel 
-from tagging a message by resending it with the IV and first block switched.
    
+from tagging a message by resending it with the IV and first block switched.
+{%- endtrans %}
    
 
-
    Endpoint Processing
    
 
-
    After receiving and validating a tunnel message at the last hop in the tunnel,
+
    {% trans %}Endpoint Processing{% endtrans %}
    
+
+
    {% trans -%}
+After receiving and validating a tunnel message at the last hop in the tunnel,
 how the endpoint recovers the data encoded by the gateway depends upon whether 
 the tunnel is an inbound or an outbound tunnel.  For outbound tunnels, the 
 endpoint encrypts the message with its layer key just like any other participant, 
 exposing the preprocessed data.  For inbound tunnels, the endpoint is also the 
 tunnel creator so they can merely iteratively decrypt the IV and message, using the 
-layer and IV keys of each step in reverse order.
    
+layer and IV keys of each step in reverse order.
+{%- endtrans %}
    
 
-
    At this point, the tunnel endpoint has the preprocessed data sent by the gateway,
+
    {% trans -%}
+At this point, the tunnel endpoint has the preprocessed data sent by the gateway,
 which it may then parse out into the included I2NP messages and forwards them as
-requested in their delivery instructions.
    
+requested in their delivery instructions.
+{%- endtrans %}
    
 
 
-
    Tunnel Building
    
+
    {% trans %}Tunnel Building{% endtrans %}
    
 
-
    When building a tunnel, the creator must send a request with the necessary
+
    {% trans -%}
+When building a tunnel, the creator must send a request with the necessary
 configuration data to each of the hops and wait for all of them to agree before
 enabling the tunnel.  The requests are encrypted so that only the peers who need
 to know a piece of information (such as the tunnel layer or IV key) has that
 data.  In addition, only the tunnel creator will have access to the peer's
 reply.  There are three important dimensions to keep in mind when producing
 the tunnels: what peers are used (and where), how the requests are sent (and 
-replies received), and how they are maintained.
    
+replies received), and how they are maintained.
+{%- endtrans %}
    
 
-
    Peer Selection
    
 
-
    Beyond the two types of tunnels - inbound and outbound - there are two styles
+
    {% trans %}Peer Selection{% endtrans %}
    
+
+
    {% trans -%}
+Beyond the two types of tunnels - inbound and outbound - there are two styles
 of peer selection used for different tunnels - exploratory and client.
 Exploratory tunnels are used for both network database maintenance and tunnel
-maintenance, while client tunnels are used for end to end client messages.  
    
+maintenance, while client tunnels are used for end to end client messages.
+{%- endtrans %}
    
 
-
    Exploratory tunnel peer selection
    
 
-
    Exploratory tunnels are built out of a random selection of peers from a subset
+
    {% trans %}Exploratory tunnel peer selection{% endtrans %}
    
+
+
    {% trans -%}
+Exploratory tunnels are built out of a random selection of peers from a subset
 of the network.  The particular subset varies on the local router and on what their
 tunnel routing needs are.  In general, the exploratory tunnels are built out of
 randomly selected peers who are in the peer's "not failing but active" profile
 category.  The secondary purpose of the tunnels, beyond merely tunnel routing,
 is to find underutilized high capacity peers so that they can be promoted for
-use in client tunnels.
    
+use in client tunnels.
+{%- endtrans %}
    
 
-
    
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
 Exploratory peer selection is discussed further on the
-Peer Profiling and Selection page.
+Peer Profiling and Selection page.
+{%- endtrans %}
    
 
 
-
    Client tunnel peer selection
    
+
    {% trans %}Client tunnel peer selection{% endtrans %}
    
 
-
    Client tunnels are built with a more stringent set of requirements - the local
+
    {% trans -%}
+Client tunnels are built with a more stringent set of requirements - the local
 router will select peers out of its "fast and high capacity" profile category so
 that performance and reliability will meet the needs of the client application.
 However, there are several important details beyond that basic selection that 
-should be adhered to, depending upon the client's anonymity needs.
    
-  
-
    
+should be adhered to, depending upon the client's anonymity needs.
+{%- endtrans %}
    
+
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
 Client peer selection is discussed further on the
-Peer Profiling and Selection page.
+Peer Profiling and Selection page.
+{%- endtrans %}
    
 
-
    Peer Ordering within Tunnels
    
+
    {% trans %}Peer Ordering within Tunnels{% endtrans %}
    
 
-Peers are ordered within tunnels to
-to deal with the predecessor 
-attack (2008 
-update).
-
    To frustrate the predecessor 
+
    {% trans pdf='http://forensics.umass.edu/pubs/wright-tissec.pdf',
+pdf2008='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf' -%}
+Peers are ordered within tunnels to deal with the
+predecessor attack
+(2008 update).
+{%- endtrans %}
    
+
+
    {% trans -%}
+To frustrate the predecessor 
 attack, the tunnel selection keeps the peers selected in a strict order -
 if A, B, and C are in a tunnel for a particular tunnel pool, the hop after A is always B, and the hop after
 B is always C.
+{%- endtrans %}
    
 
-
    Ordering is implemented by generating a random 32-byte key for each
+
    {% trans -%}
+Ordering is implemented by generating a random 32-byte key for each
 tunnel pool at startup.
 Peers should not be able to guess the ordering, or an attacker could
 craft two router hashes far apart to maximize the chance of being at both
 ends of a tunnel.
 Peers are sorted by XOR distance of the
 SHA256 Hash of (the peer's hash concatenated with the random key) from the random key
+{%- endtrans %}
    
 
           p = peer hash
       k = random key
       d = XOR(H(p+k), k)
 
    
 
-
    Because each tunnel pool uses a different random key, ordering is consistent
+
    {% trans -%}
+Because each tunnel pool uses a different random key, ordering is consistent
 within a single pool but not between different pools.
 New keys are generated at each router restart.
+{%- endtrans %}
    
 
 
-
    Request delivery
    
+
    {% trans %}Request delivery{% endtrans %}
    
 
-
    
+
    {% trans pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%}
 A multi-hop tunnel is built using a single build message which is repeatedly
-decrypted and forwarded.
-In the terminology of
-Hashing it out in Public,
+decrypted and forwarded. In the terminology of
+Hashing it out in Public,
 this is "non-interactive" telescopic tunnel building.
+{%- endtrans %}
    
 
-
-
    This tunnel request preparation, delivery, and response method is
-designed to reduce the number of
+
    {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%}
+This tunnel request preparation, delivery, and response method is
+designed to reduce the number of
 predecessors exposed, cuts the number of messages transmitted, verifies proper
 connectivity, and avoids the message counting attack of traditional telescopic
 tunnel creation.
 (This method, which sends messages to extend a tunnel through the already-established
 part of the tunnel, is termed "interactive" telescopic tunnel building in
 the "Hashing it out" paper.)
+{%- endtrans %}
    
 
-
    The details of tunnel request and response messages, and their encryption,
-are specified here.
+
    {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%}
+The details of tunnel request and response messages, and their encryption,
+are specified here.
+{%- endtrans %}
    
 
-
    Peers may reject tunnel creation requests for a variety of reasons, though
+
    {% trans -%}
+Peers may reject tunnel creation requests for a variety of reasons, though
 a series of four increasingly severe rejections are known: probabilistic rejection
 (due to approaching the router's capacity, or in response to a flood of requests), 
 transient overload, bandwidth overload, and critical failure.  When received, 
 those four are interpreted by the tunnel creator to help adjust their profile of
 the router in question.
-
    
+{%- endtrans %}
    
+
+
    {% trans peerselection=site_url('docs/how/peer-selection') -%}
 For more information on peer profiling, see the
-Peer Profiling and Selection page.
+Peer Profiling and Selection page.
+{%- endtrans %}
    
 
-
    Tunnel Pools
    
 
-
    To allow efficient operation, the router maintains a series of tunnel pools,
+
    {% trans %}Tunnel Pools{% endtrans %}
    
+
+
    {% trans i2cp=site_url('docs/spec/i2cp') -%}
+To allow efficient operation, the router maintains a series of tunnel pools,
 each managing a group of tunnels used for a specific purpose with their own
 configuration.  When a tunnel is needed for that purpose, the router selects one
 out of the appropriate pool at random.  Overall, there are two exploratory tunnel
 pools - one inbound and one outbound - each using the router's default configuration.
 In addition, there is a pair of pools for each local destination -
 one inbound and one outbound tunnel pool.  Those pools use the configuration specified
-when the local destination connects to the router via I2CP, or the router's defaults if
-not specified.
    
+when the local destination connects to the router via I2CP, or the router's defaults if
+not specified.
+{%- endtrans %}
    
 
-
    Each pool has within its configuration a few key settings, defining how many
+
    {% trans i2cp=site_url('docs/spec/i2cp') -%}
+Each pool has within its configuration a few key settings, defining how many
 tunnels to keep active, how many backup tunnels to maintain in case of failure,
 how long the tunnels should be, whether those
 lengths should be randomized, as 
 well as any of the other settings allowed when configuring individual tunnels.
-Configuration options are specified on the I2CP page.
+Configuration options are specified on the I2CP page.
+{%- endtrans %}
    
 
-
    Tunnel Lengths and Defaults
    
 
-On the tunnel overview page.
+
    {% trans %}Tunnel Lengths and Defaults{% endtrans %}
    
 
-
    Anticipatory Build Strategy and Priority
    
+{% trans %}On the tunnel overview page{% endtrans %}.
 
-
    
+
    {% trans %}Anticipatory Build Strategy and Priority{% endtrans %}
    
+
+
    {% trans -%}
 Tunnel building is expensive, and tunnels expire a fixed time after they are built.
 However, when a pool that runs out of tunnels, the Destination is essentially dead.
 In addition, tunnel build success rate may vary greatly with both local and global
@@ -360,8 +443,9 @@ Therefore, it is important to maintain an anticipatory, adaptive build strategy
 to ensure that new tunnels are successfully built before they are needed,
 without building an excess of tunnels, building them too soon,
 or consuming too much CPU or bandwidth creating and sending the encrypted build messages.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 For each tuple {exploratory/client, in/out, length, length variance}
 the router maintains statistics on the time required for a successful
 tunnel build.
@@ -370,19 +454,21 @@ it should start attempting to build a replacement.
 As the expiration time approaches without a successful replacement,
 it starts multiple build attempts in parallel, and then
 will increase the number of parallel attempts if necessary.
-
    
-
    
+{%- endtrans %}
    
+
+
    {% trans -%}
 To cap bandwidth and CPU usage,
 the router also limits the maximum number of build attempts outstanding
 across all pools.
 Critical builds (those for exploratory tunnels, and for pools that have
 run out of tunnels) are prioritized.
-
    
+{%- endtrans %}
    
 
 
-
    Tunnel Message Throttling
    
+
    {% trans %}Tunnel Message Throttling{% endtrans %}
    
 
-
    Even though the tunnels within I2P bear a resemblance to a circuit switched
+
    {% trans -%}
+Even though the tunnels within I2P bear a resemblance to a circuit switched
 network, everything within I2P is strictly message based - tunnels are merely
 accounting tricks to help organize the delivery of messages.  No assumptions are
 made regarding reliability or ordering of messages, and retransmissions are left
@@ -394,9 +480,10 @@ the averages used by other tunnels the router is participating in, and be able
 to accept or reject additional tunnel participation requests based on its 
 capacity and utilization.  On the other hand, each router can simply drop 
 messages that are beyond its capacity, exploiting the research used on the 
-normal Internet.
    
+normal Internet.
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 In the current implementation, routers implement a
 weighted random early discard (WRED) strategy.
 For all participating routers (internal participant, inbound gateway, and outbound endpoint),
@@ -410,31 +497,36 @@ Larger messages are more likely to be dropped.
 Also, messages are more likely to be dropped at the outbound endpoint than the inbound gateway,
 as those messages are not as "far along" in their journey and thus the network cost of
 dropping those messages is lower.
-
    
+{%- endtrans %}
    
 
 
-
    Future Work
    
-
    Mixing/batching
    
+
    {% trans %}Future Work{% endtrans %}
    
+
    {% trans %}Mixing/batching{% endtrans %}
    
 
-
    What strategies could be used at the gateway and at each hop for delaying,
+
    {% trans -%}
+What strategies could be used at the gateway and at each hop for delaying,
 reordering, rerouting, or padding messages?  To what extent should this be done
 automatically, how much should be configured as a per tunnel or per hop setting,
 and how should the tunnel's creator (and in turn, user) control this operation?
 All of this is left as unknown, to be worked out for a distant future release. 
+{%- endtrans %}
    
 
 
-
    Padding
    
-
    The padding strategies can be used on a variety of levels, addressing the
+
    {% trans %}Padding{% endtrans %}
    
+
    {% trans -%}
+The padding strategies can be used on a variety of levels, addressing the
 exposure of message size information to different adversaries.
 The current fixed tunnel message size is 1024 bytes.  Within this however, the fragmented
 messages themselves are not padded by the tunnel at all, though for end to end 
-messages, they may be padded as part of the garlic wrapping.
    
+messages, they may be padded as part of the garlic wrapping.
+{%- endtrans %}
    
+
 
 
    WRED
    
-
    
+
    {% trans -%}
 WRED strategies have a significant impact on end-to-end performance,
 and prevention of network congestion collapse.
 The current WRED strategy should be carefully evaluated and improved.
-
    
+{%- endtrans %}
    
 
 {% endblock %}
diff --git a/www.i2p2/pages/tunnel.html b/i2p2www/pages/site/docs/tunnels/old-implementation.html
similarity index 98%
rename from www.i2p2/pages/tunnel.html
rename to i2p2www/pages/site/docs/tunnels/old-implementation.html
index c9e82cc5..88c5c40d 100644
--- a/www.i2p2/pages/tunnel.html
+++ b/i2p2www/pages/site/docs/tunnels/old-implementation.html
@@ -1,8 +1,10 @@
-{% extends "_layout.html" %}
-{% block title %}Old Tunnel Implementation{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Old Tunnel Implementation{% endtrans %}{% endblock %}
 {% block content %}
 
-Note: Obsolete - NOT used!  Replaced in 0.6.1.10 - see tunnel-alt.html for the current implementation
+{% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
+Note: Obsolete - NOT used!  Replaced in 0.6.1.10 - see here for the current implementation
+{%- endtrans %}
 
    
 
     1) Tunnel overview
@@ -529,6 +531,6 @@ reordering, rerouting, or padding messages?  To what extent should this be done
 automatically, how much should be configured as a per tunnel or per hop setting,
 and how should the tunnel's creator (and in turn, user) control this operation?
 All of this is left as unknown, to be worked out for 
-I2P 3.0
    
+I2P 3.0
    
 
 {% endblock %}
diff --git a/www.i2p2/pages/unidirectional-tunnels.html b/i2p2www/pages/site/docs/tunnels/unidirectional.html
similarity index 69%
rename from www.i2p2/pages/unidirectional-tunnels.html
rename to i2p2www/pages/site/docs/tunnels/unidirectional.html
index 5d82c220..e913e321 100644
--- a/www.i2p2/pages/unidirectional-tunnels.html
+++ b/i2p2www/pages/site/docs/tunnels/unidirectional.html
@@ -1,34 +1,33 @@
-{% extends "_layout.html" %}
-{% block title %}Unidirectional Tunnels{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Unidirectional Tunnels{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}July 2011{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.7{% endblock %}
 {% block content %}
-
    
-Updated July 2011 for release 0.8.7
-
    
-
-
    Overview
    
-
    
+
    {% trans %}Overview{% endtrans %}
    
+
    {% trans -%}
 This page describes the origins and design of I2P's unidirectional tunnels.
 For further infomrmation see:
+{%- endtrans %}
    
 
 
    
 
-
    Review
    
+
    {% trans %}Review{% endtrans %}
    
 
-
    
+
    {% trans -%}
 While we aren't aware of any published research on the advantages of 
 unidirecdtional tunnels,
 they appear to make it harder to detect a 
@@ -41,17 +40,19 @@ attacker who has only timing and traffic volume data to infer the path a
 tunnel is taking.
 Having the response come back along a different path arguably 
 makes it harder.
+{%- endtrans %}
    
 
-
    
-    When dealing with 
-    an internal adversary or most external adversaries, I2P's undirectional tunnels
-    expose half as much traffic data than would be exposed with bidirectional circuits
-    by simply looking at the flows themselves - an HTTP request and response would 
-    follow the same path in Tor, while in I2P the packets making up the request 
-    would go out through one or more outbound tunnels and the packets making up 
-    the response would come back through one or more different inbound tunnels. 
+
    {% trans -%}
+When dealing with 
+an internal adversary or most external adversaries, I2P's undirectional tunnels
+expose half as much traffic data than would be exposed with bidirectional circuits
+by simply looking at the flows themselves - an HTTP request and response would 
+follow the same path in Tor, while in I2P the packets making up the request 
+would go out through one or more outbound tunnels and the packets making up 
+the response would come back through one or more different inbound tunnels. 
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 The strategy of using two separate tunnels for inbound and outbound
 communication is not the only technique available, and it does have anonymity
 implications.  On the positive side, by using separate tunnels it lessens the
@@ -66,51 +67,57 @@ additional care must be taken to address the increased speed of predecessor
 attacks.  The tunnel pooling and building process
 (peer selection and ordering strategies)
 should minimize the worries of the predecessor attack.
-
-
    
+{%- endtrans %}
    
 
 
-
    Anonymity
    
+
    {% trans %}Anonymity{% endtrans %}
    
 
-
    
-A recent
-paper by Hermann and Grothoff
+
    {% trans pdf='http://grothoff.org/christian/i2p.pdf' -%}
+A recent paper by Hermann and Grothoff
 declared that I2P's unidirectional tunnels "seems to be a bad design decision".
+{%- endtrans %}
    
 
+
    {% trans -%}
 The paper's main point is that
 deanonymizations on unidirectional tunnels take a longer time, which is an 
 advantage, but that an attacker can be more certain in the unidirectional case. 
 Therefore, the paper claims it isn't an advantage at all, but a disadvantage, at least
 with long-living eepsites.
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 This conclusion is not fully supported by the paper. Unidirectional tunnels clearly 
 mitigate other attacks and it's not clear how to trade off the risk of the 
 attack in the paper
 with attacks on a bidirectional tunnel architecture.
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 This conclusion is based on an arbitrary certainty vs. time weighting 
 (tradeoff) that may not be applicable in all cases. For 
 example, somebody could make a list of possible IPs then issue subpoenas to 
 each. Or the attacker could DDoS each in turn and via a simple 
 intersection attack see if the eepsite goes down or is slowed down. So close 
 may be good enough, or time may be more important.
+{%- endtrans %}
    
 
+
    {% trans -%}
 The conclusion is based on a specific weighting of the importance of certainty 
 vs. time, and that weighting may be wrong, and it's definitely debatable, 
 especially in a real world with subpoenas, search warrants, and other methods 
 available for final confirmation.
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 A full analysis of the tradeoffs of unidirectional vs. bidirectional 
 tunnels is clearly outside the scope of the paper, and has not been done 
 elsewhere. For example, how does this attack compare to the numerous possible 
 timing attacks published about onion-routed networks? Clearly the authors have not
 done that analysis, if it's even possible to do it
 effectively.
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 Tor uses bidirectional tunnels and has had a lot of academic review. I2P 
 uses unidirectional tunnels and has had very little review. Does the lack of a 
 research paper defending unidirectional tunnels mean that it is a poor design 
@@ -125,14 +132,14 @@ clearly needs further investigation and analysis? There are several other reason
 to consider I2P currently inferior to Tor and other projects (small network 
 size, lack of funding, lack of review) but is unidirectional tunnels really a 
 reason?
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 In summary, "bad design decision" is apparently (since the paper does
 not label bidirectional tunnels "bad") shorthand for "unidirectional 
 tunnels are unequivocally inferior to bidirectional tunnels", yet this 
 conclusion is not supported by the paper.
-
-
    
+{%- endtrans %}
    
 
 
 {% endblock %}
diff --git a/i2p2www/pages/site/faq.html b/i2p2www/pages/site/faq.html
new file mode 100644
index 00000000..f0e8ac46
--- /dev/null
+++ b/i2p2www/pages/site/faq.html
@@ -0,0 +1,853 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Frequently Asked Questions') }}{% endblock %}
+{% block content %}
+
    {{ _('Index') }}
    
+
      
+
    1. 
+
      {{ _('General') }}
      
+
      2. 
+
    2. {% trans %}What systems will I2P run on?{% endtrans %}
      3. 
+
    3. {% trans %}Whats an "eepsite" and how do I configure my browser so I can use them?{% endtrans %}
      4. 
+
    4. {% trans %}My router has very few active peers, is this OK?{% endtrans %}
      5. 
+
    5. {% trans %}What do the Active x/y numbers mean in the router console?{% endtrans %}
      6. 
+
    6. {% trans %}My active peers / known peers / participating tunnels / connections / bandwidth vary dramatically over time! Is anything wrong?{% endtrans %}
      7. 
+
    7. {% trans %}Is using an outproxy safe?{% endtrans %}
      8. 
+
    8. {% trans %}Most of the eepsites within I2P are down?{% endtrans %}
      9. 
+
    9. {% trans %}What ports does I2P use?{% endtrans %}
      10. 
+
    10. {% trans %}Why is I2P listening for connections on port 32000?{% endtrans %}
      11. 
+
    11. {% trans %}I think I found a bug, where can I report it?{% endtrans %}
      12. 
+
    12. {% trans %}What happened to *.i2p.net? What happened to jrandom? Is I2P dead?{% endtrans %}
      13. 
+
    13. {% trans %}I have a question!{% endtrans %}
      14. 
+
    14. 
+
      {{ _('Setup') }}
      
+
      15. 
+
    15. {% trans %}My router has been up for several minutes and has zero or very few connections{% endtrans %}
      16. 
+
    16. {% trans %}Why is I2P so slow?{% endtrans %}
      17. 
+
    17. {% trans %}I'm missing lots of hosts in my addressbook. What are some good subscription links?{% endtrans %}
      18. 
+
    18. {% trans %}How do I set up my own eepsite?{% endtrans %}
      19. 
+
    19. {% trans %}Bittorrent / I2PSnark / Azureus I2P Plugin Questions?{% endtrans %}
      20. 
+
    20. {% trans %}How do I connect to IRC within I2P?{% endtrans %}
      21. 
+
    21. {% trans %}I can't access regular Internet sites through I2P.{% endtrans %}
      22. 
+
    22. {% trans %}I can't access https:// or ftp:// sites through I2P.{% endtrans %}
      23. 
+
    23. {% trans %}Is it possible to use I2P as a SOCKS proxy?{% endtrans %}
      24. 
+
    24. {% trans %}How do I configure my browser?{% endtrans %}
      25. 
+
    25. {% trans %}How can I access the web console from my other machines or password protect it?{% endtrans %}
      26. 
+
    26. {% trans %}How can I use applications from my other machines?{% endtrans %}
      27. 
+
    27. {% trans %}How do I reseed manually?{% endtrans %}
      28. 
+
    28. {% trans %}My router is using too much CPU?!?{% endtrans %}
      29. 
+
    29. 
+
      {{ _('Misconception') }}
      
+
      30. 
+
    30. {% trans %}How do I access IRC, BitTorrent, or other services on the regular Internet?{% endtrans %}
      31. 
+
    31. {% trans %}Is my router an "exit node"(outproxy) to the regular Internet? I don't want it to be.{% endtrans %}
      32. 
+
    32. {% trans %}I am opposed to certain types of content. How do I keep from distributing, storing, or accessing them?{% endtrans %}
      33. 
+
    33. 
+
      {{ _('Errors and Their Solutions') }}
      
+
      34. 
+
    34. {% trans %}I'm using FreeBSD and when I start I2P I receive an error about libm.so.4!{% endtrans %}
      35. 
+
    35. {% trans %}In wrapper.log I see an error stating Protocol family unavailable when I2P is loading{% endtrans %}
      36. 
+
    
+
+
    {% trans %}What systems will I2P run on?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans trac=i2pconv('trac.i2p2.i2p') -%}
+While I2P has been reported to run PCs as meagre as a low-end Pentium II with 64 MB of RAM, you'll have a much better experience on a Pentium III (or better) with 128MB of RAM (or more). A chart comparing the performance of the various JREs can be found at http://{{ trac }}/wiki/java, but in short: it's at all possible, use Sun/Oracle Java or OpenJDK.
+{%- endtrans %}
    
+
+
    {% trans -%}
+I2P has been tested on Windows, Linux, FreeBSD (see the note below), OSX, and OpenSolaris. There is work underway to bring I2P to the Android platform.
+{%- endtrans %}
    
+
+
+
    {% trans %}I think I found a bug, where can I report it?{% endtrans %}
+({{ _('link') }})
    
+
+{% trans -%}
+Here are some places, pick one or more.
+{%- endtrans %}
+
+
+
    {% trans -%}
+Please include relevant information from the router logs and wrapper logs.
+{%- endtrans %}
    
+
+
    {% trans %}I'm missing lots of hosts in my addressbook. What are some good subscription links?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+The default subscription is to http://www.i2p2.i2p/hosts.txt which is updated rarely.
+If you don't have another subscription, you may often have to use "jump" links which
+is annoying.
+{%- endtrans %}
    
+
+
    {% trans -%}
+Here are some other public addressbook subscription links. You may wish to add one or two
+to your susidns subscription list.
+You don't need to add all of them, as they sync with each other periodically.
+The links using a cgi-bin application employ various strategies to minimize
+the number of duplicate addresses delivered, so they should be more efficient.
+Note that subscribing to a hosts.txt service is an act of "trust", as a malicious
+subscription could give you incorrect addresses. So think about whether you
+want to trust any of these.
+The operators of these services may have various policies for listing hosts.
+Presence on this list does not imply endorsement.
+{%- endtrans %}
    
+
+
    
+
    
+
+
+
    {% trans %}What happened to *.i2p.net? What happened to jrandom? Is I2P dead?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+Jrandom was the lead developer of I2P and
+Syndie for several years.
+We do not know if or when jrandom will return.
+The *.i2p.net domains were left in a non-functioning state after a power
+outage at the hosting company.
+{%- endtrans %}
    
+
+
    {% trans jrandom=site_url('misc/jrandom-awol'), index=site_url() -%}
+See this page for jrandom's parting message and additional information
+on the migration of *.i2p.net to this website.
+{%- endtrans %}
    
+
+
    {% trans %}I2P remains in active development.{% endtrans %}
    
+
+
    {% trans %}My router is using too much CPU?!?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+There are many possible causes of high CPU usage. Here is a checklist:
+{%- endtrans %}
    
+
      
+
    • 
+{% trans -%}
+Try to use either OpenJDK or Sun/Oracle Java if it's available for your system. You can check 
+which version of java you have installed by typing java -version at a 
+command/shell prompt. Performance tends to suffer with other implementations of java.
+{%- endtrans %}
+
      • 
+
    • 
+{% trans -%}
+Are you running a BitTorrent client over I2P? Try reducing the number of torrents, the bandwidth limits,
+or try turning it off completely to see if that helps.
+{%- endtrans %}
+
      • 
+
    • 
+{% trans -%}
+Are your bandwidth limits set too high? It is possible that too much traffic is going through your
+I2P router and it is overloaded. Try reducing the setting for share bandwidth percentage on the configuration page.
+{%- endtrans %}
      • 
+
    • 
+{% trans -%}
+Make sure that you're running the latest version of I2P to get the benefits of increased performance and bug fixes.
+{%- endtrans %}
+
      • 
+
    • 
+{% trans -%}
+Has enough memory been set aside for use by I2P? Look at the memory graph on the graphs page to see
+if the memory usage is "pegged"—the JVM is spending most of its time in
+garbage collection. Increase the setting wrapper.java.maxmemory in wrapper.config.
+{%- endtrans %}
+
      • 
+
    • 
+{% trans -%}
+Is the CPU usage simply higher than you would like, or is it pegged at 100% for a long time?
+If it's pegged, this could be a bug. Look in the logs for clues.
+{%- endtrans %}
+
      • 
+
    • 
+{% trans jbigi=site_url('misc/jbigi') -%}
+You may be using the Java-based BigInteger library instead of the native version,
+especially if you are running on a new or unusual OS or hardware (OpenSolaris, mipsel, etc.).
+See the jbigi page for instructions on
+diagnosing, building, and testing methods.
+{%- endtrans %}
+
      • 
+
    • 
+{% trans -%}
+If your native jbigi library is working fine, the biggest user of
+CPU may be routing traffic for participating tunnels. This uses CPU
+because at each hop a layer of encryption must be decoded.
+You can limit participating traffic in two ways - by reducing the
+share bandwidth on
+confignet.jsp,
+or by setting router.maxParticipatingTunnels=nnn on
+configadvanced.jsp.
+{%- endtrans %}
+
      • 
+
    
+
+
    {% trans %}I am opposed to certain types of content. How do I keep from distributing, storing, or accessing them?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+Hmm. I2P is an anonymous network, so that's a tricky one.
+I2P is designed to withstand censorship, providing a means for everyone to communicate freely. 
+The best way to keep your PC free of (encrypted) traffic that you dislike is to not use I2P.
+Freedom of speech has some costs.
+But let's address your question in three parts:
+{%- endtrans %}
    
+
      
+
    • 
+{% trans -%}
+Distribution - All traffic on I2P is encrypted in multiple layers. You don't know
+a message's contents, source, or destination.
+All traffic you route is internal to the I2P network, you are not an exit node (outproxy).
+Your only alternative is to refuse to route
+any traffic, by setting your share bandwidth or maximum participating tunnels to 0 (see above).
+It would be nice if you didn't do this, you should help the network by routing traffic for others.
+Over 95% of users route traffic for others.
+{%- endtrans %}
+
      • 
+
    • 
+{% trans -%}
+Storage - I2P does not do distributed storage of content. You must be thinking of
+Freenet.
+Nobody's content is being stored on your computer by running I2P.
+{%- endtrans %}
+
      • 
+
    • 
+{% trans -%}
+Access - If there are some eepsites you don't like, don't go there.
+Or, use a blocking proxy like Privoxy or some type of "net nanny".
+{%- endtrans %}
+
      • 
+
    
+
+
+
    {% trans %}My active peers / known peers / participating tunnels / connections / bandwidth vary dramatically over time! Is anything wrong?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+No. This is normal.
+All routers adjust dynamically to changing network conditions and demands.
+{%- endtrans %}
    
+
+
    {% trans %}My router has been up for several minutes and has zero or very few connections{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+You may need to reseed your I2P router. With recent versions of I2P you can go to http://localhost:7657/configreseed and click the Save Changes and Reseed Now button. If this method doesn't work—or you're using a very old version—you may need to reseed manually.
+{%- endtrans %}
    
+
    {% trans -%}
+The reseed URL changed a few years ago. If this is your first install and you have installed
+an old (0.6.1.30 or earlier) release, or
+you have not run I2P in a long time, you must change the URL and then
+click "Reseed" on the console to find other routers.
+After your router is running,
+on configadvanced.jsp,
+add the line i2p.reseedURL=http://netdb.i2p2.de/
+OR i2p.reseedURL=http://i2pdb.tin0.de/netDb/ (either should work),
+then click "Apply", then click the "reseed" link on the left.
+{%- endtrans %}
    
+
    {% trans downloadslist=get_url('downloads_list') -%}
+This works if you are running 0.6.1.27 or later.
+If you are running release 0.6.1.31 or later, you probably don't need to do this.
+If you are running release 0.6.1.26 or earlier, either follow the
+manual reseed instructions below
+or install the latest release.
+Possible alternate method - add
+wrapper.java.additional.5=-Di2p.reseedURL=http://netdb.i2p2.de/
+to wrapper.config, shutdown the router completely, then start again, then click "reseed".
+Let us know if this works.
+{%- endtrans %}
    
+
    {% trans downloadslist=get_url('downloads_list') -%}
+...but you *really* should upgrade to the latest version.
+{%- endtrans %}
    
+
+
    {% trans %}My router has very few active peers, is this OK?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+If your router has 10 or more active peers, everything is fine. Changes in releases 0.6.1.31 and 0.6.1.32 improved the
+efficiency of the router and effectively reduced the number of active peers.
+The router should maintain connections to a few peers at all times.
+The best way to stay "better-connected" to the network is to share more bandwidth.
+{%- endtrans %}
    
+
+
    {% trans %}Is my router an "exit node" to the regular Internet? I don't want it to be.{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+No. Unlike Tor,
+"exit nodes" or "outproxies" are not an inherent part of the network.
+Only volunteers who set up and run separate applications will relay traffic to the regular Internet.
+There are very, very few of these.
+{%- endtrans %}
    
+
+
    {% trans %}I can't access regular Internet sites through I2P.{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+See above. There are very few HTTP "outproxies", they are not an inherent part of the network,
+and they may not be up.
+In addition, the old outproxies squid.i2p, true.i2p, and krabs.i2p have vanished.
+The only outproxy at the moment is false.i2p.
+To use it, edit your i2ptunnel settings for eepProxy
+and set your outproxy list to 'false.i2p' (only).
+Then stop and restart the eepProxy.
+If it doesn't work, the outproxy is not up. It is not I2P's fault.
+If your primary reason to use an anonymous network is to anonymously access sites
+on the regular Internet, you should probably try Tor.
+{%- endtrans %}
    
+
+
    {% trans %}I can't access https:// or ftp:// sites through I2P.{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+Within I2P, there is no need for HTTPS, as all traffic is encrypted end-to-end.
+FTP is not supported for technical reasons.
+{%- endtrans %}
    
+
    {% trans -%}
+There are no FTP "outproxies" to the Internet—it may not even be possible to set up one.
+Any other kind of outproxy may work if it's set up with a standard tunnel. 
+If you would like to set up some type of outproxy, carefully research the potential risks.
+The I2P community may or may not be able to help with the technical aspects, feel free to ask.
+{%- endtrans %}
    
+
    {% trans -%}
+As explained several times above, any existing outproxy isn't a core part of the network.
+They are services run by individuals and they may or may not
+be operational at any given time.
+{%- endtrans %}
    
+
    {% trans -%}
+Update: Thanks to the work of h2ik, there is an https outproxy available for use via I2P. Starting with I2P 0.8.4 the tunnel is configured out of the box.
    
+In case the https outproxy is not available in your version of I2P, you can add it easily by doing the following:
+{%- endtrans %}
    
+
      
+  
    1. 
+    {% trans -%}
+Open i2p tunnel manager. Scroll down to the bottom.
+    {%- endtrans %}
+  
      2. 
+  
    2. 
+    {% trans -%}
+Choose CONNECT from New Client Tunnel dropdown list, click Create
+    {%- endtrans %}
+  
      3. 
+  
    3. 
+    {% trans forum=i2pconv('forum.i2p') -%}
+In the new page, name and describe your new https tunnel as you like.
+The Access Point is your local port for the new https proxy recommended port's 4445.
+Outproxy should be the outproxy's .i2p address which supports https. 
+See this forum post of h2ik's for the address. 
+Make sure Shared Client, Delay Connect, AutoStart are checked.
+Other options should be left at the defaults. Click Save. In tunnel manger, click the Start button next to your new tunnel.
+    {%- endtrans %}
+  
      4. 
+  
    4. 
+    {% trans -%}
+In firefox, click through Tools>Options>Advanced>Network>Setting.
+Untick Use this proxy for all protocol, set SSL proxy: to localhost:4445.
+    {%- endtrans %}
+  
      5. 
+  
    5. {{ _('Done.') }}
      6. 
+
    
+
+
+
    {% trans %}Is using an outproxy safe?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans threatmodel=site_url('docs/how/threat-model') %}
+This is a question that only you can answer because the correct answer depends on your behaviours, your
+threat model, and how much you trust the outproxy operator.
+{%- endtrans %}
    
+
    {% trans -%}
+Like Tor, I2P does not magically encrypt the Internet.
+You are vulnerable to snooping by the outproxy operators.
+The Tor FAQ
+does a good job of explaining this.
+{%- endtrans %}
    
+
    {% trans zzz=i2pconv('zzz.i2p') -%}
+In addition, you may be vulnerable to collusion between the outproxy operator
+and operators of other I2P services, if you use the same tunnels ("shared clients").
+There is additional discussion about this on {{ zzz }}.
+{%- endtrans %}
    
+
+
    {% trans %}How do I access IRC, BitTorrent, or other services on the regular Internet?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+Unless an outproxy has been set up for the service you want to connect to, this cannot be done.
+There are only three types of outproxies running right now: HTTP, HTTPS, and email. Note that there is not a SOCKS outproxy.
+If this type of service is required, try Tor.
+{%- endtrans %}
    
+
+
    {% trans %}Most of the eepsites within I2P are down?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans perv=i2pconv('perv.i2p') -%}
+If you consider every eepsite that has ever been created, yes, most of them are down.
+People and eepsites come and go.
+A good way to get started in I2P is check out a list of eepsites that are currently up.
+{{ perv }} tracks active eepsites.
+{%- endtrans %}
    
+
+
    {% trans %}How do I set up my own eepsite?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+Click on the Website link
+at the top of your router console for instructions.
+{%- endtrans %}
    
+
+
    {% trans %}Why is I2P so slow?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+Why are downloads, torrents, web browsing, and everything else so slow on I2P?
+The encryption and routing within the I2P network adds a substantial amount of overhead and limits bandwidth.
+Anonymity isn't free.
+{%- endtrans %}
    
+
    {% trans -%}
+In addition, you and everybody else probably need to increase your bandwidth limits.
+Two key settings are the inbound and outbound bandwidth limiters on
+the configuration page.
+With the default settings of 32KBps you will generally get no better than 15KBps data transfer in I2PSnark.
+Increasing the settings (but keeping within your actual connection limitations)
+will increase the potential transfer rate for I2PSnark and all other applications.
+{%- endtrans %}
    
+
    {% trans -%}
+Also, do you have sufficient share bandwidth configured to allow participating tunnels
+to route through your router? Believe it or not, allowing participating traffic
+keeps you well-integrated in the network and helps your own transfer speeds.
+{%- endtrans %}
    
+
    {% trans downloadslist=get_url('downloads_list') -%}
+I2P is a work in progress. Lots of improvements and fixes are being implemented, and
+generally speaking, running the latest release will help your performance.
+If you haven't, install the latest release.
+{%- endtrans %}
    
+
+
    {% trans %}Bittorrent / I2PSnark / Azureus I2P Plugin Questions?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans forum=i2pconv('forum.i2p') -%}
+See the
+I2P Bittorrent FAQ
+{%- endtrans %}
    
+
+
    {% trans %}How do I connect to IRC within I2P?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans %}
+A tunnel to the main IRC server within I2P, Irc2P, is created when I2P is installed (see
+the I2PTunnel configuration page),
+and is automatically started when the I2P router starts. To connect to it, tell your IRC
+client to connect to localhost 6668. XChat-like client users can create a
+new network with the server localhost/6668 (remember to tick "Bypass
+proxy server" if you have a proxy server configured).
+{%- endtrans %}
    
+
+
    {% trans %}How can I access the web console from my other machines or password protect it?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+For security purposes, the router's admin console by default only listens
+for connections on the local interface.  However, with a little hacking,
+you can make it reachable remotely:
+{%- endtrans %}
    
+
+
      
+
    1. 
+    {% trans -%}
+Open ~/.i2p/clients.config and replace
      
+clientApp.0.args=7657 ::1,127.0.0.1 ./webapps/
      
+with 
      
+clientApp.0.args=7657 0.0.0.0 ./webapps/
+    {%- endtrans %}
+  
      2. 
+  
    2. 
+    {% trans -%}
+Go to http://localhost:7657/configadvanced.jsp
+and add a new option: consolePassword=foo (or whatever password you want)
+    {%- endtrans %}
+  
      3. 
+  
    3. 
+    {% trans -%}
+Go to http://localhost:7657/index.jsp
+and hit "Graceful restart", which restarts the JVM and reloads the client applications
+    {%- endtrans %}
+  
      4. 
+
    
+
+
    {% trans -%}
+After that fires up, you should now be able to reach your console remotely.
+You will be prompted for a username and password though - the username is
+"admin" and the password is whatever you specified in step 2 above.  Note: the
+0.0.0.0 above specifies an interface, not a network or netmask.  0.0.0.0
+means "bind to all interfaces", so it can be reachable on 127.0.0.1:7657 as well as
+any LAN/WAN IP.
+{%- endtrans %}
    
+
+
    {% trans %}How can I use applications from my other machines?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+By default, the router I2CP interface (port 7654) binds to address 127.0.0.1. To bind to 0.0.0.0, set the
+router advanced configuration option i2cp.tcp.bindAllInterfaces=true and restart.
+{%- endtrans %}
    
+
+
    {% trans %}Whats an "eepsite"?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+An eepsite is a website that is hosted anonymously - you can access it by
+setting your web browser's HTTP proxy to use the web proxy (typically it
+listens on localhost port 4444), and browsing to the site.
+{%- endtrans %}
    
+
+
    {% trans %}How do I configure my browser?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans browserconfig=site_url('about/browser-config') -%}
+The proxy config for different browsers is on a 
+separate page with screenshots. More advanced configs with external tools
+are possible but could introduce leaks in your setup.
+{%- endtrans %}
    
+
+
+
    {% trans %}What do the Active x/y numbers mean in the router console?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+x is the number of peers you've sent or received a message from
+successfully in the last minute, y is the number of peers seen in the last
+hour or so.
+{%- endtrans %}
    
+
+
    {% trans %}Is it possible to use I2P as a SOCKS proxy?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are supported.
+There is no SOCKS outproxy so it is of limited use.
+{%- endtrans %}
    
+
    {% trans -%}
+In addition, many applications leak sensitive
+information that could identify you on the Internet. I2P only filters
+connection data, but if the program you intend to run sends this
+information as content, I2P has no way to protect your anonymity.  For
+example, some mail applications will send the IP address of the machine
+they are running on to a mail server. There is no way for I2P to filter
+this, thus using I2P to 'socksify' existing applications is possible, but
+extremely dangerous.
+{%- endtrans %}
    
+
    {% trans socks=site_url('docs/api/socks') -%}
+If you would like more information on the socks proxy application anyway,
+there are some helpful hints on the socks page.
+{%- endtrans %}
    
+
+
    {% trans %}What ports does I2P use?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+Okay, here's a rundown of the default ports (everything is configurable
+through various settings, of course):
+{%- endtrans %}
    
+
+
+
      
+
+
    • 
+{% trans -%}
+Internet-facing ports
+Note: New installs as of release 0.7.8 do not use port 8887; they select a random port
+between 9000 and 31000 when the program is run for the first time.
+The selected port is shown on the router configuration page.
+{%- endtrans %}
+
        
+  
      • 
+    {% trans -%}
+Outbound UDP from the random port noted on the configuration page to arbitrary remote UDP ports, allowing replies
+    {% endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+Outbound TCP from random high ports to arbitrary remote TCP ports
+    {% endtrans %}
+
        • 
+  
      • 
+    {% trans -%}
+(optional, but recommended) Inbound UDP to the port noted on configuration page from arbitrary locations
+    {% endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+(optional, but recommended) Inbound TCP to the port noted on configuration page from arbitrary locations
        
+Inbound TCP may be disabled on the configuration page.
+    {%- endtrans %}
+  
        • 
+  
      • 
+{% trans -%}
+Outbound UDP on port 123, allowing replies
        
+This is necessary for I2P's internal time sync (via SNTP - 
+querying a random SNTP host in pool.ntp.org or another
+server you specify)
+{%- endtrans %}
+  
        • 
+
      
+
      • 
+
+
    • 
+{% trans -%}
+Local I2P ports, listening only to local connections by default,
+except where noted:
+{%- endtrans %}
+
        
+  
      • 
+    {% trans -%}
+1900: UPnP SSDP UDP multicast listener.
+Cannot be changed. Binds to all interfaces.
+May be disabled on confignet.jsp.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+2827: BOB bridge, a higher level socket API for clients
+Disabled by default.
+May be enabled/disabled on configclients.jsp.
+May be changed in the bob.config file.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+4444: HTTP proxy
+May be disabled or changed on the i2ptunnel page in the router console.
+May also be configured to be bound to a specific interface or all interfaces.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+4445: HTTPS proxy
+May be disabled or changed on the i2ptunnel page in the router console.
+May also be configured to be bound to a specific interface or all interfaces.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+6668: IRC proxy
+May be disabled or changed on the i2ptunnel page in the router console.
+May also be configured to be bound to a specific interface or all interfaces.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7652: UPnP HTTP TCP event listener.
+Binds to the LAN address.
+May be changed with advanced config i2np.upnp.HTTPPort=nnnn.
+May be disabled on confignet.jsp.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7653: UPnP SSDP UDP search response listener.
+Binds to all interfaces.
+May be changed with advanced config i2np.upnp.SSDPPort=nnnn.
+May be disabled on confignet.jsp.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7654: I2P Client Protocol port, used by client apps.
+May be changed to a different port on
+configclients.jsp
+but this is not recommended.
+May be to bind to a different interface or all interfaces, or disabled, on
+configclients.jsp.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7655: UDP for SAM bridge, a higher level socket API for clients
+Only opened when a SAM V3 client requests a UDP session.
+May be enabled/disabled on configclients.jsp.
+May be changed in the clients.config file with the SAM command line option sam.udp.port=nnnn.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7656: SAM bridge, a higher level socket API for clients
+Disabled by default for new installs as of release 0.6.5.
+May be enabled/disabled on configclients.jsp.
+May be changed in the clients.config file.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7657: Your router console
+May be disabled in the clients.config file.
+May also be configured to be bound to a specific interface or all interfaces in that file.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7658: Your eepsite
+May be disabled in the clients.config file.
+May also be configured to be bound to a specific interface or all interfaces in the jetty.xml file.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7659: Outgoing mail to smtp.postman.i2p
+May be disabled or changed on the i2ptunnel page in the router console.
+May also be configured to be bound to a specific interface or all interfaces.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+7660: Incoming mail from pop.postman.i2p
+May be disabled or changed on the i2ptunnel page in the router console.
+May also be configured to be bound to a specific interface or all interfaces.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+8998: mtn.i2p2.i2p (Monotone - disabled by default)
+May be disabled or changed on the i2ptunnel page in the router console.
+May also be configured to be bound to a specific interface or all interfaces.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+31000: Local connection to the wrapper control channel port.
+Outbound to 32000 only, does not listen on this port.
+Starts at 31000 and will increment until 31999 looking for a free port.
+To change, see the
+wrapper documentation.
+For more information see below.
+    {%- endtrans %}
+  
        • 
+  
      • 
+    {% trans -%}
+32000: Local control channel for the service wrapper.
+To change, see the
+wrapper documentation.
+For more information see below.
+    {%- endtrans %}
+  
        • 
+
      
+
      • 
+
    
+
+
+
    {% trans -%}
+The local I2P ports and the I2PTunnel ports do not need to be reachable from 
+remote machines, but *should* be reachable locally.  You can also create 
+additional ports for I2PTunnel instances via http://localhost:7657/i2ptunnel/ 
+(and in turn, would need to get your firewall to allow you local access, but 
+not remote access, unless desired).
+{%- endtrans %}
    
+
+
    {% trans -%}
+So, to summarize, nothing needs to be reachable by unsolicited remote peers, but
+if you can configure your NAT/firewall to allow inbound UDP and TCP the outbound facing port, you'll
+get better performance.  You will also need to be able to send outbound UDP packets
+to arbitrary remote peers (blocking IPs randomly with something like PeerGuardian
+only hurts you - don't do it).
+{%- endtrans %}
    
+
+
    {% trans %}Why is I2P listening on port 32000?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+The Tanuki java service wrapper that we use opens this port—bound to localhost—in order 
+to communicate with software running inside the JVM. When the JVM is launched it is given a key 
+so it can connect to the wrapper. After the JVM establishes its connection 
+to the wrapper, the wrapper refuses any additional connections.
+{%- endtrans %}
    
+
    {% trans -%}
+More information can be found in the  
+wrapper documentation.
+{%- endtrans %}
    
+
+
    {% trans %}How do I reseed manually?{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+An I2P router only needs to be seeded once, to join the network for the first time.
+Reseeding is nothing more than sending plain HTTP GET requests
+to fetch a directory listing and download multiple "routerInfo" files
+from a predefined reseed URL.
+{%- endtrans %}
    
+
+
    {% trans -%}
+A typical symptom of a failed reseed is the "Known" indicator
+(on the left sidebar of the router console) displaying a very small value
+(often less than 5) which does not increase. This can occur, among other things,
+if your firewall limits outbound traffic, and blocked the reseed request.
+{%- endtrans %}
    
+
+{% trans %}To reseed an I2P router manually, do the following:{% endtrans %}
+
      
+
    • 
+{% trans %}Stop your I2P router{% endtrans %}
+
      • 
+
    • 
+{% trans %}Open http://netdb.i2p2.de/ using a web browser{% endtrans %}
+    
+
      • 
+
    • {% trans %}Save a dozen "routerInfo" files to your I2P "netDb" directory{% endtrans %}
+     
+
      • 
+
    • 
+{% trans %}Start your I2P router{% endtrans %}
+
      • 
+
    
+
+
    {% trans %}I'm using FreeBSD and when I start I2P I receive an error about libm.so.4!{% endtrans %}
+({{ _('link') }})
    
+
+{% trans %}When trying to start the router using "i2prouter start", you may see output like the following:{% endtrans %}
    
+     $ ./i2prouter start
    
+     Starting I2P Service...
    
+     /libexec/ld-elf.so.1: Shared object "libm.so.4" not found, required by "i2psvc"
+    
+
    {% trans %}
+In order to be inclusive and try to ensure that I2P will run on as many systems 
+as possible, up until I2P 0.8.9 we used a java wrapper 
+compiled for FreeBSD 6.x. If you're receiving this error you most likely are missing the necessary compatibility libraries.
+These libraries may be installed by performing the following steps:
+{%- endtrans %}
    
+
      
+  
    • 
+{% trans %}Switch to the root user with su or log in as root.{% endtrans %}
+  
      • 
+  
    • cd /usr/ports/misc/compat6x
      • 
+  
    • make install
      • 
+
    
+
+
    {% trans manualwrapper=site_url('misc/manual-wrapper') -%}
+If you cannot install these compatibility libraries (or do not want to), other
+possibilities would be to compile the wrapper for your
+system, starting I2P with the runplain.sh script, or you can
+replace the wrapper with one from the source tarball.
+{%- endtrans %}
    
+
    {% trans -%}
+For the 0.8.9 release of I2P, the wrapper was upgraded to v3.5.12 and compiled on systems running FreeBSD 7.2.
+{%- endtrans %}
    
+
+
    {% trans %}In wrapper.log I see an error that states "Protocol family unavailable" when loading the Router Console{% endtrans %}
+({{ _('link') }})
    
+
    {% trans -%}
+Often this error will occur with any network enabled java software on some systems that are configured to use IPv6 by default. There are a few ways to solve this:
+{%- endtrans %}
    
+
      
+  
    • 
+{% trans %}On Linux based systems, you can echo 0 > /proc/sys/net/ipv6/bindv6only{% endtrans %}
+
      • 
+  
    • {% trans %}Look for the following lines in wrapper.config.{% endtrans %}
      
+#wrapper.java.additional.5=-Djava.net.preferIPv4Stack=true
      
+      #wrapper.java.additional.6=-Djava.net.preferIPv6Addresses=false
      
+
      
+  {% trans %}If the lines are there, uncomment them by removing the "#"s. If the lines are not there, add them without the "#"s.{% endtrans %}
+  
      • 
+
    
+{% trans -%}
+Another option would be to remove the ::1 from ~/.i2p/clients.config
+{%- endtrans %}
+
+
    {% trans -%}
+WARNING: For any changes to wrapper.config to take effect, you must completely
+stop the router and the wrapper. Clicking Restart on your
+router console will NOT reread this file! You must
+click Shutdown, wait 11 minutes, then start I2P.
+{%- endtrans %}
    
+
+
    
+
+
    {% trans %}I have a question!{% endtrans %}
+({{ _('link') }})
    
+
    {% trans forum=i2pconv('forum.i2p') -%}
+Great!  Find us on IRC irc.freenode.net #i2p or post to
+the forum and we'll post it here (with
+the answer, hopefully).
+{%- endtrans %}
    
+
+{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/arabic-trans.html b/i2p2www/pages/site/get-involved/bounties/arabic-trans.html
new file mode 100644
index 00000000..ee6b1749
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/arabic-trans.html
@@ -0,0 +1,39 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty Arabic translation of webpage and router console') }}{% endblock %}
+{% block donatename %}{{ _('Arabic translation') }}{% endblock %}
+
+{% block bountydetails %}
+
    {% trans -%}
+To improve I2P usage and attract more people
+into I2P echelon set out this bounty for translation
+of the I2P web page and I2P router console into Arabic.
+{%- endtrans %}
    
+
    
+{{ _('This bounty is set into 2 subparts:') }}
+
    
+{{ _('Part 1 is translation of the webpage.') }}
    
+
    
+
    
+{{ _('For collecting the bounty of 20 BTC you need to translate the following pages:') }}
    
+http://www.i2p2.de/index.html
    
+http://www.i2p2.de/download.html
    
+http://www.i2p2.de/intro.html
    
+http://www.i2p2.de/faq.html
    
+http://www.i2p2.de/bounties.html
    
+http://www.i2p2.de/getinvolved.html
    
+http://www.i2p2.de/donate.html
    
+{{ _('This job was done by hamada and the bounty of 20 BTC was paid to hamada.') }}
    
+
    
+
    {% trans -%}
+Part 2 is the translation of the router console. The router console was
+partly translated and the bounty of 80 BTC was paid to hamada.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountyjudge %}
+
    {% trans -%}
+Judge is echelon.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountynotesouter %}{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/btc-client.html b/i2p2www/pages/site/get-involved/bounties/btc-client.html
new file mode 100644
index 00000000..1bcddea7
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/btc-client.html
@@ -0,0 +1,18 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty creating a I2P native Bitcoin client') }}{% endblock %}
+{% block donatename %}{{ _('BTC I2P native client') }}{% endblock %}
+
+{% block bountydetails %}
+
    {% trans -%}
+For a future of I2P and attract more people
+into I2P this bounty is to create a I2P native Bitcoin client. 
+It should integrate with other client via the I2P network and via gateways to
+the existant bitcoin network.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountyjudge %}
+
    {% trans -%}
+Judge is psychonaut who donated the first 30 € to this bounty.
+{%- endtrans %}
    
+{% endblock %}
diff --git a/www.i2p2/pages/bounty_datastore.html b/i2p2www/pages/site/get-involved/bounties/datastore.html
similarity index 51%
rename from www.i2p2/pages/bounty_datastore.html
rename to i2p2www/pages/site/get-involved/bounties/datastore.html
index 217461cb..4fef5e97 100644
--- a/www.i2p2/pages/bounty_datastore.html
+++ b/i2p2www/pages/site/get-involved/bounties/datastore.html
@@ -1,6 +1,10 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty datastorage{% endblock %}
-{% block content %}
    To improve I2P's usage and to be independent of routers 
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty datastorage') }}{% endblock %}
+{% block donatename %}{{ _('datastore') }}{% endblock %}
+
+{% block bountydetails %}
+
    {% trans -%}
+To improve I2P's usage and to be independent of routers 
 online status we want a datastorage as a extension to I2P.
 Like in Freenet the datastorage should be distributed and every
 participating node should be able to configure his options.
@@ -8,31 +12,31 @@ The files should be saved in chunks and at least 2-3 times to
 obtain redundancy. Usage of storage space should be auto balanced.
 As it is a extra application, it should work flawless within I2P and
 cooperate nice with the I2P router. Maybe a integration within the
-webpage/router could be done.
    
-
    
-
    This bounty cooperates with the 2 other bounties "frost for I2P" and 
-"eepsites in datastorage".
    
-
    
-
    The frost for I2P datastorage bounty is paid for a frost like program 
+webpage/router could be done.
+{%- endtrans %}
    
+
    {% trans -%}
+This bounty cooperates with the 2 other bounties "frost for I2P" and 
+"eepsites in datastorage".
+{%- endtrans %}
    
+
    {% trans -%}
+The frost for I2P datastorage bounty is paid for a frost like program 
 with which files/messages are stored into database and got from database.
-It needs to work with a GUI.
    
-
    
-
    The eepsite served out of I2P datastorage extends a I2P router to send
+It needs to work with a GUI.
+{%- endtrans %}
    
+
    {% trans -%}
+The eepsite served out of I2P datastorage extends a I2P router to send
 out eepsites out of the I2P datastorage. All files for eepsites need to be
 saved inside of datastorage and are taken from it.
 Extension:
 For better integration all datastorage participants could serve that eepsite.
-
    
-
    
-
    
-Note:
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountynotes %}
+
  • {% trans -%}
 For bounties to be declared done and paid, we need the program AND the source.
 Source and code need to be licensed under a free license (free to change and 
-free to distribute). To claim the bounty the author must not be paid by other
-organizations or teams for this work (e.g. GSoC students are not valid).
    
-
-
-
    Note 2: bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for the datastore bounty!
    
+free to distribute).
+{%- endtrans %}
    • 
+{{ super() }}
 {% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/deb-pack.html b/i2p2www/pages/site/get-involved/bounties/deb-pack.html
new file mode 100644
index 00000000..14ad71f8
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/deb-pack.html
@@ -0,0 +1,15 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty I2P package in Debian and Ubuntu mirrors') }}{% endblock %}
+{% block donatename %}{{ _('I2P Ubuntu/Debian package') }}{% endblock %}
+
+{% block bountydetails %}
+
    {% trans -%}
+For the future of I2P and in order to attract more people
+to I2P, this bounty was set for including an I2P package into the Ubuntu and Debian 
+archive mirrors.
+To claim this bounty, the I2P router package needs to be available from
+Ubuntu and Debian archive mirrors and Debian bug 
+448638 
+needs to be closed successfully.
+{%- endtrans %}
    
+{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/i2phex.html b/i2p2www/pages/site/get-involved/bounties/i2phex.html
new file mode 100644
index 00000000..40c2b78a
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/i2phex.html
@@ -0,0 +1,13 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty I2PHex code implementation') }}{% endblock %}
+{% block donatename %}{{ _('i2phex code implementation') }}{% endblock %}
+
+{% block bountydetails %}
+
    {% trans -%}
+To improve I2P usage and attract more people
+into I2PHex P2P ArneBab setout the bounty for implementing actual
+Phex code onto I2PHex.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountynotesouter %}{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/index.html b/i2p2www/pages/site/get-involved/bounties/index.html
new file mode 100644
index 00000000..5abaf4da
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/index.html
@@ -0,0 +1,160 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Bounties') }}{% endblock %}
+{% block content %}
+
+
    {{ _('Bounties for I2P') }}
    
+
    {% trans -%}
+While we always gratefully accept any contributions of code, 
+documentation, and the like, there are other ways to help I2P move 
+forward.  As with any open source project, our goals would be achieved more 
+rapidly if we were able to support all of our contributors to work on 
+I2P full time.  However, as with any open source project, that's not a 
+possibility.  Instead, we are making use of a bounty system, whereby 
+anyone can get support for working on something that people want 
+implemented, and people who want to contribute to I2P can be assured that 
+their support goes to what they care about.
+{%- endtrans %}
    
+
+
    {% trans -%}
+We are also keeping open the ability for people who want to support I2P 
+but don't have strong feelings about the bounties available.  Those people
+can simply put their trust in the I2P team to do what we feel is best by
+donating to a catch-all general fund that will be used as deemed 
+necessary - allocated to various bounties, covering incidentals (hosting, 
+etc), and the like.
+{%- endtrans %}
    
+
+
    {{ _('Current bounties') }}
    
+
+
+ 
+ 
+  
+  
+  
+  
+  
+ 
+ 
+  
+  
+  
+  
+  
+ 
+ 
+  
+  
+  
+  
+  
+  
+ 
+  
+  
+  
+  
+  
+ 
+ 
+  
+  
+  
+  
+  
+ 
+ 
+  
+  
+  
+  
+  
+ 
+ 
+  
+  
+  
+  
+  
+ 
+ 
+  
+  
+  
+  
+  
+ 
+ 
    {{ _('Name') }}
    {{ _('Status') }}
    {{ _('Judge') }}
    {{ _('Dev') }} *
    {{ _('Bounty') }}
    {{ _('Frost for I2P datastorage') }}
    {{ _('Proposal in development') }}
    echelon
    [{{ _('vacant') }}]
    €50 EUR
    {{ _('Eepsites served out of I2P datastorage') }}
    {{ _('Proposal in development') }}
    echelon
    [{{ _('vacant') }}]
    €65 EUR and 2 BTC
    {{ _('Backporting Phex code onto I2PHex') }}
    {{ _('Proposal in development') }}
    Arne Bab
    [{{ _('vacant') }}]
    €100 EUR
    {{ _('Make I2P IPv6 native') }}
    {{ _('Proposal in development') }}
    Amiga4000
    [{{ _('vacant') }}]
    €100 EUR and 50BTC
    {{ _('I2P package in Debian and Ubuntu mirrors') }}
    {{ _('Proposal in development') }}
    h2ik
    [{{ _('vacant') }}]
    €113 EUR
    {{ _('Bitcoin client for I2P') }}
    {{ _('Done, phase of verification') }}
    psychonaut
    giv
    €30 EUR and 118,34BTC
    {{ _('Unit tests and Multi-router Simulation') }}
    {{ _('Partly done, partly in work, partly still open') }}
    anonymous
    str4d,hottuna,zzz,sponge,dg
    3000 €, of which 700 € already paid for done jobs
    Syndie
    {{ _('Proposal in development') }}
    I2P team
    [{{ _('vacant') }}]
    50 BTC
    
+
+
    {{ _('Hold bounties, set on hold due to jrandom AWOL and missing funding') }}
    
+
+
+ 
+ 
+  
+  
+  
+  
+  
+ 
+
    {{ _('Name') }}
    {{ _('Status') }}
    {{ _('Judge') }}
    {{ _('Dev') }} *
    {{ _('Bounty') }}
    {{ _('Bundling bounties') }}
    {{ _('Proposed') }}
    jrandom
    [{{ _('vacant') }}]
    $0 USD each, or $0 for all
    
+
+
    {{ _('Claimed bounties') }}
    
+
+
+ 
+ 
+  
+  
+  
+ 
+ 
+   
+   
+   
+  
+ 
+  
+  
+  
+ 
+ 
+  
+  
+  
+ 
+ 
+  
+  
+  
+ 
+ 
+  
+  
+  
+ 
+ 
+  
+  
+  
+ 
+ 
+  
+  
+  
+ 
+ 
+  
+  
+  
+ 
+
    {{ _('Name') }}
    {{ _('Status') }}
    {{ _('Dev team') }}*
    {{ _('Setting up a SILC server') }}
    withdrawn and bounty divided between ReturningNovice and the general fund
    An Anonymous Secret Society, society@mail.i2p
    {{ _('Arabic translation') }}
    both parts were taken by hamada for 100 BTC
    hamada
    {{ _('Datastore over I2P') }}
    CLAIMED for 700 €
    duck, smeghead
      
    { _('Russian translation') }}
    claimed for $230 USD sponsored by russian sponsor
    4get
    {{ _('Swarming file transfer') }}
    CLAIMED for €250 EUR
    duck, ragnarok, dinoman, connelly, drwoo
    {{ _('Streaming library window size') }}
    Claimed (archived link)
    jrandom
    {{ _('IRC connect time monitor') }}
    		CLAIMED for $10 USD
    hypercubus
    {{ _('Unit tests (part 1)') }}
    		CLAIMED for $300 USD
    Comwiz
    GCJ support
    Claimed
    jrandom
    
+
+
+
    * {% trans -%}
+Dev lists anyone who may already be working on the bounty - collaboration is
+preferred, so if you're interested in working on it, please contact one of the
+people listed!
+{%- endtrans %}
    
+
+{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/ipv6.html b/i2p2www/pages/site/get-involved/bounties/ipv6.html
new file mode 100644
index 00000000..0da3382d
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/ipv6.html
@@ -0,0 +1,21 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty I2P IPv6 native') }}{% endblock %}
+{% block donatename %}{{ _('native IPv6 I2P') }}{% endblock %}
+
+{% block bountydetails %}
+
    {% trans -%}
+For a future of I2P and attract more people
+into I2P I withdrawal the vuze bounty and offer a IPv6 bounty.
+To claim this bounty, the I2P router needs to run full on native
+IPv6 connections like it does on IPv4.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountynotes %}
+
  • {% trans -%}
+For bounties to be declared done and paid, we need the plugin AND the source.
+Source and code need to be licensed under a free license (free to change and 
+free to distribute).
+{%- endtrans %}
    • 
+{{ super() }}
+{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/russian-trans.html b/i2p2www/pages/site/get-involved/bounties/russian-trans.html
new file mode 100644
index 00000000..eeb69844
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/russian-trans.html
@@ -0,0 +1,42 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty russian translation of webpage and router console') }}{% endblock %}
+{% block donatename %}{{ _('Russian translation') }}{% endblock %}
+
+{% block bountydetails %}
+
    {% trans -%}
+To improve I2P usage and attract more people
+into I2P a anonymous donator set out the bounty for translation
+of the I2P web page and I2P router console into russian language.
+{%- endtrans %}
    
+
    
+{{ _('This bounty is set into 2 subparts:') }}
+
    
+{{ _('Part 1 is translation of the webpage.') }}
    
+
    
+
    
+{{ _('For collecting the bounty of $115 USD you need to translate the following pages:') }}
    
+http://www.i2p2.de/index.html
    
+http://www.i2p2.de/download.html
    
+http://www.i2p2.de/intro.html
    
+http://www.i2p2.de/faq.html
    
+http://www.i2p2.de/bounties.html
    
+http://www.i2p2.de/bounty_datastore
    
+http://www.i2p2.de/bounty_i2phex
    
+http://www.i2p2.de/bounty_vuzeplugin
    
+http://www.i2p2.de/getinvolved.html
    
+http://www.i2p2.de/donate.html
    
+
+
    
+
    {% trans -%}
+Part 2 is the translation of the router console. The whole router console needs
+to be translated to collect the bounty of $115 USD.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountyjudge %}
+
    {% trans -%}
+Judge is the russian donor.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountynotesouter %}{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/silc.html b/i2p2www/pages/site/get-involved/bounties/silc.html
new file mode 100644
index 00000000..c1ba05da
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/silc.html
@@ -0,0 +1,26 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty migrate I2P IRC to SILC') }}{% endblock %}
+{% block donatename %}{{ _('I2P silc server') }}{% endblock %}
+
+{% block bountydetails %}
+
+
    {% trans -%}
+For a future of I2P and attract more people
+into I2P this bounty is to setup and host a I2P SILC server.   
+This will allow people to send files over their messaging servers and have intrinsic security built into the protocol.
+{%- endtrans %}
    
+
    {% trans -%}
+A silc server needs to be set up and run for at least 3 month time to get payed. 
+A second server should be set up, to.
+{%- endtrans %}
    
+
    {% trans -%}
+Bounty was withdrawn and money donated to returningnovice and general fund.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountyjudge %}
+
    {% trans -%}
+Judge is An Anonymous Secret Society, society@mail.i2p.
+{%- endtrans %}
    
+{% endblock %}
+                                             
diff --git a/i2p2www/pages/site/get-involved/bounties/syndie-2012.html b/i2p2www/pages/site/get-involved/bounties/syndie-2012.html
new file mode 100644
index 00000000..076d702d
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/syndie-2012.html
@@ -0,0 +1,31 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Syndie development') }}{% endblock %}
+{% block donatename %}{{ _('Syndie development') }}{% endblock %}
+
+{% block bountydetails %}
+
+
    {% trans -%}
+Beside of I2P we want to encourage users
+to care more about anonymity and security. As I2P is a low 
+latency network with its natural limits, the software SYNDIE
+can overcome some of these limits and provide better anonymity
+for people who really need it.
+{%- endtrans %}
    
+
    {% trans -%}
+For our bad sake the syndie project is out of development for 
+quite a long time yet (5 years). To get a fresh and new built 
+with needed bugfixes we set out this bounty. Also syndie needs
+some enhancements and a better GUI for users to work with it.
+Current bounty sum is 50 Bitcoin.
+{%- endtrans %}
    
+
+
    {% trans -%}
+The latest Syndie coding rally did improve the situation of the
+Syndie package dramatically. A new Syndie package with bugfixes
+was created and made available on different webpages.
+As a result of this work, the bounty sum was reduced and
+the withdrawn money moved to the IPv6 bounty.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountynotesouter %}{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/bounties/unit-tests.html b/i2p2www/pages/site/get-involved/bounties/unit-tests.html
new file mode 100644
index 00000000..9a14fe2c
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/bounties/unit-tests.html
@@ -0,0 +1,132 @@
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty unittests') }}{% endblock %}
+{% block donatename %}{{ _('unit test') }}{% endblock %}
+
+{% block bountydetails %}
+
+
    {% trans -%}
+To improve I2P's maintainability, we want to have a solid set of
+automated unit tests for the critical code.  While we do have some
+unit tests at the moment, they are ad-hoc and partly unfinished.  
+This bounty is for someone to check the existing tests and move over
+old ones to jUnit, automate their execution, extend them to provide 
+better code coverage, and publish the report online.  Its a massive 
+effort, but can be broken down into phases, listed below (phase 2 
+must occur first, but further phases may happen in any order).
+As this needs some reading of code, it is the best start point for
+new devs to get a good overview of I2P code and coding. A good job
+for college students, interns or anyone who is just interested.
+{%- endtrans %}
    
+
    {% trans -%}
+Take care! Jobs and bounties shuffled a bit!
+Phase 6,7 and 8 are still open!
+{%- endtrans %}
    
+
+
+
    {% trans phase=1 %}Phase {{ phase }}:{% endtrans %}
+{{ _('CI jenkins and IRC bot') }}
    
+{% trans euro=500 %}Bounty: {{ euro }} €
+{%- endtrans %} {{ _('server runs and this section is blocked') }}
    
+
+
    {% trans -%}
+To collect this bounty, a continuous integration server (Jenkins,
+old name was Hudson) must be set up and a connected IRC bot needs 
+to set up in the channel #i2p-dev on IRC2p network to print out
+results of build tests.
    
+The server needs to be run long term.
+{%- endtrans %}
      
+
    
+
+
    {% trans phase=2 %}Phase {{ phase }}:{% endtrans %}
+{{ _('Check existing SDK tests') }}
    
+{% trans euro=150 %}Bounty: {{ euro }} €
+{%- endtrans %} {{ _('paid to str4d') }}
    
+
+
    {% trans clover='https://www.atlassian.com/software/clover/overview' -%}
+To collect this bounty, the existing SDK tests must be checked 
+and made to work again. The need to be integrated into the ant 
+build scripts ("ant test"), and tied in with a code coverage tool (e.g. 
+Clover).  The ant script
+must be capable of generating test status results as a web page, 
+which will be published online.
+{%- endtrans %}
    
+
    
+
+
    {% trans phase=3 %}Phase {{ phase }}:{% endtrans %}
+{{ _('SDK test coverage') }}
    
+{% trans euro=200 %}Bounty: {{ euro }} €
+{%- endtrans %} {{ _('paid to unittests dev team') }}
    
+
+
    {% trans -%}
+To collect this bounty, the automated unit tests of the SDK 
+(i2p/core/java/src) must work again.
+{%- endtrans %}
    
+
    
+
+
    {% trans phase=4 %}Phase {{ phase }}:{% endtrans %}
+{{ _('Router test migration') }}
    
+{% trans euro=150 %}Bounty: {{ euro }} €
+{%- endtrans %} {{ _('paid to str4d') }}
    
+
+
    {% trans -%}
+As with phase 2, the existing unit tests for the router must be
+moved over to the automated system.
+{%- endtrans %}
    
+
    
+
+
    {% trans phase=5 %}Phase {{ phase }}:{% endtrans %}
+{{ _('Router test coverage') }}
    
+{% trans euro=200 %}Bounty: {{ euro }} €
+{%- endtrans %} {{ _('paid to unittests dev team') }}
    
+
+
    {% trans -%}
+To collect this bounty, the automated unit tests of the router 
+(i2p/router/java/src) must work again.
+{%- endtrans %}
    
+
    
+
+
    {% trans phase=6 %}Phase {{ phase }}:{% endtrans %}
+{{ _('Streaming lib tests') }}
    
+{% trans euro=300 %}Bounty: {{ euro }} €
+{%- endtrans %}
    
+
+
+
    {% trans -%}
+To collect this bounty, a new set of unit tests must meet a 
+measured code coverage of 90% of the streaming lib 
+(i2p/apps/ministreaming/ and i2p/apps/streaming/).
+{%- endtrans %}
    
+
    
+
+
    {% trans phase=7 %}Phase {{ phase }}:{% endtrans %}
+{{ _('Unit tests coverage') }}
    
+{% trans euro=500 %}Bounty: {{ euro }} €
+{%- endtrans %}
    
+
+
    {% trans -%}
+To collect this bounty, all above unit tests must meet the 100%
+coverage marker (except for log statements).
+{%- endtrans %}
    
+
    
+
+
    {% trans phase=8 %}Phase {{ phase }}:{% endtrans %}
+{{ _('MultiRouter simulation') }}
    
+{% trans euro=1000 %}Bounty: {{ euro }} €
+{%- endtrans %} {{ _('will be split in more sub-tasks') }}
    
+
+
    {% trans -%}
+To collect this bounty, the existing in-memory multi-router
+simulation must be checked, made work again and extend to simulate
+lots of routers in memory on a single machine. This bounty will
+be split in more fine grained subworks.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountyjudge %}
+
    {% trans -%}
+Judge on all these works is the donor and donor decides if a phase is
+called succesfull done and money can be paid.
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountynotesouter %}{% endblock %}
diff --git a/www.i2p2/pages/bounty_vuzeplugin.html b/i2p2www/pages/site/get-involved/bounties/vuze-plugin.html
similarity index 52%
rename from www.i2p2/pages/bounty_vuzeplugin.html
rename to i2p2www/pages/site/get-involved/bounties/vuze-plugin.html
index 33380136..d67d26cd 100644
--- a/www.i2p2/pages/bounty_vuzeplugin.html
+++ b/i2p2www/pages/site/get-involved/bounties/vuze-plugin.html
@@ -1,6 +1,10 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty I2P vuze plugin{% endblock %}
-{% block content %}
    To improve I2P usage and attract more people
+{% extends "global/bounty.html" %}
+{% block title %}{{ _('Bounty I2P vuze plugin') }}{% endblock %}
+{% block donatename %}{{ _('vuze plugin') }}{% endblock %}
+
+{% block bountydetails %}
+
    {% trans -%}
+To improve I2P usage and attract more people
 into I2P torrent P2P I setout the bounty for a working I2P vuze
 plugin.
 The plugin needs to be official and submitted to vuze for publication
@@ -9,18 +13,14 @@ It should be easy to install and configured, work smooth and flawless.
 Configuration should be friendly to starters and made easy to be anonymous.
 It should work with *.b32.i2p destinations as with signed (516++ bits) 
 destinations.
-
    
-
    
-
    
-Note:
+{%- endtrans %}
    
+{% endblock %}
+
+{% block bountynotes %}
+
  • {% trans -%}
 For bounties to be declared done and paid, we need the plugin AND the source.
 Source and code need to be licensed under a free license (free to change and 
-free to distribute). To claim the bounty the author must not be paid by other
-organizations or teams for this work (e.g. GSoC students are not valid).
    
-
-
-
    Note 2: bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for the vuze plugin bounty!
    
-
+free to distribute).
+{%- endtrans %}
    • 
+{{ super() }}
 {% endblock %}
diff --git a/www.i2p2/pages/applications.html b/i2p2www/pages/site/get-involved/develop/applications.html
similarity index 50%
rename from www.i2p2/pages/applications.html
rename to i2p2www/pages/site/get-involved/develop/applications.html
index fa6c2409..db4eae61 100644
--- a/www.i2p2/pages/applications.html
+++ b/i2p2www/pages/site/get-involved/develop/applications.html
@@ -1,120 +1,130 @@
-{% extends "_layout.html" %}
-{% block title %}Application Development{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Application Development') }}{% endblock %}
 {% block content %}
-
    Application Development Guide
    
+
    {{ _('Application Development Guide') }}
    
 
-
    Contents
    
+
    {{ _('Contents') }}
    
 
 
-
    Why write I2P-specific code?
    
+
    {{ _('Why write I2P-specific code?') }}
    
+
+
    {% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
+There are multiple ways to use applications in I2P.
+Using I2PTunnel,
+you can use regular applications without needing to program explicit I2P support.
+This is very effective for client-server scenario's,
+where you need to connect to a single website.
+You can simply create a tunnel using I2PTunnel to connect to that website, as shown in Figure 1.
+{%- endtrans %}
    
+
    {% trans -%}
+If your application is distributed, it will require connections to a large amount of peers.
+Using I2PTunnel, you will need to create a new tunnel for each peer you want to contact,
+as shown in Figure 2.
+This process can of course be automated, but running a lot of I2PTunnel instances creates a large amount of overhead.
+In addition, with many protocols you will need to force everyone to 
+use the same set of ports for all peers - e.g. if you want to reliably run DCC 
+chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port 
+10003 is Charlie, and so on, since the protocol includes TCP/IP specific information
+(host and port).
+{%- endtrans %}
    
+
    {% trans -%}
+General network applications often send a lot of additional data that could be used to identify users.
+Hostnames, port numbers, time zones, character sets, etc. are often sent without informing the user.
+As such, designing the network protocol specifically with anonymity in mind
+can avoid compromising user identities.
+{%- endtrans %}
    
+
    {% trans -%}
+There are also efficiency considerations to review when determining how to 
+interact on top of I2P.  The streaming library and things built on top of it
+operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP)
+are strictly message based (like UDP or in some instances raw IP).  The important
+distinction is that with I2P, communication is operating over a long fat network - 
+each end to end message will have nontrivial latencies, but may contain payloads 
+of up to 32KB.  An application that needs a simple request and response can get rid
+of any state and drop the latency incurred by the startup and teardown handshakes
+by using (best effort) datagrams without having to worry about MTU detection or 
+fragmentation of messages under 32KB.
+{%- endtrans %}
    
 
-
    
-    There are multiple ways to use applications in I2P.
-    Using I2PTunnel,
-    you can use regular applications without needing to program explicit I2P support.
-    This is very effective for client-server scenario's,
-    where you need to connect to a single website.
-    You can simply create a tunnel using I2PTunnel to connect to that website, as shown in Figure 1.
-
    
-
    
-    If your application is distributed, it will require connections to a large amount of peers.
-    Using I2PTunnel, you will need to create a new tunnel for each peer you want to contact,
-    as shown in Figure 2.
-    This process can of course be automated, but running a lot of I2PTunnel instances creates a large amount of overhead.
-    In addition, with many protocols you will need to force everyone to 
-    use the same set of ports for all peers - e.g. if you want to reliably run DCC 
-    chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port 
-    10003 is Charlie, and so on, since the protocol includes TCP/IP specific information
-    (host and port).
-
    
-
    
-    General network applications often send a lot of additional data that could be used to identify users.
-    Hostnames, port numbers, time zones, character sets, etc. are often sent without informing the user.
-    As such, designing the network protocol specifically with anonymity in mind
-    can avoid compromising user identities.
-
    
-
    
-    There are also efficiency considerations to review when determining how to 
-    interact on top of I2P.  The streaming library and things built on top of it
-    operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP)
-    are strictly message based (like UDP or in some instances raw IP).  The important
-    distinction is that with I2P, communication is operating over a long fat network - 
-    each end to end message will have nontrivial latencies, but may contain payloads 
-    of up to 32KB.  An application that needs a simple request and response can get rid
-    of any state and drop the latency incurred by the startup and teardown handshakes
-    by using (best effort) datagrams without having to worry about MTU detection or 
-    fragmentation of messages under 32KB.
-
    
-   
         
    
-        Creating a server-client connection using I2PTunnel only requires creating a single tunnel.
+        {{ _('Creating a server-client connection using I2PTunnel only requires creating a single tunnel.') }}
         

    
-        Figure 1: Creating a server-client connection using I2PTunnel only requires creating a single tunnel.
+        {{ _('Figure 1:') }} {{ _('Creating a server-client connection using I2PTunnel only requires creating a single tunnel.') }}
         
    
    
    
-  
+
         
    
-        Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.
+        {{ _('Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.') }}
         

    
-        Figure 2: Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.
+        {{ _('Figure 2:') }} {{ _('Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.') }}
         
    
     
    
 
-    In summary, a number of reasons to write I2P-specific code:
-    
      
-        
    • 
-            Creating a large amount of I2PTunnel instances consumes a non-trivial amount of resources,
-            which is problematic for distributed applications (a new tunnel is required for each peer).
-        
      • 
-        
    • 
-            General network protocols often send a lot of additional data that can be used to identify users.
-            Programming specifically for I2P allows the creation of a network protocol
-            that does not leak such information, keeping users anonymous and secure.
-        
      • 
-        
    • 
-            Network protocols designed for use on the regular internet can be inefficient
-            on I2P, which is a network with a much higher latency.
-        
      • 
-    
    
+{% trans -%}
+In summary, a number of reasons to write I2P-specific code:
+{%- endtrans %}
+
      
+    
    • {% trans -%}
+Creating a large amount of I2PTunnel instances consumes a non-trivial amount of resources,
+which is problematic for distributed applications (a new tunnel is required for each peer).
+{%- endtrans %}
      • 
+    
    • {% trans -%}
+General network protocols often send a lot of additional data that can be used to identify users.
+Programming specifically for I2P allows the creation of a network protocol
+that does not leak such information, keeping users anonymous and secure.
+{%- endtrans %}
      • 
+    
    • {% trans -%}
+Network protocols designed for use on the regular internet can be inefficient
+on I2P, which is a network with a much higher latency.
+{%- endtrans %}
      • 
+
    
 
 
-
    
-    Applications written in Java and accessible/runnable
-    using an HTML interface via the standard webapps/app.war
-    may be considered for inclusion in the i2p distribution.
-
    
+
    {% trans -%}
+Applications written in Java and accessible/runnable
+using an HTML interface via the standard webapps/app.war
+may be considered for inclusion in the i2p distribution.
+{%- endtrans %}
    
 
-
    Important concepts
    
+
    {{ _('Important concepts') }}
    
 
-
    There are a few changes that require adjusting to when using I2P:
    
+
    {% trans -%}
+There are a few changes that require adjusting to when using I2P:
+{%- endtrans %}
    
 
-
    Destination ~= host+port
    
+
    {{ _('Destination ~= host+port') }}
    
 
-
    An application running on I2P sends messages from and receives messages to a
+
    {% trans -%}
+An application running on I2P sends messages from and receives messages to a
 unique cryptographically secure end point - a "destination".  In TCP or UDP
 terms, a destination could (largely) be considered the equivalent of a hostname
-plus port number pair, though there are a few differences.  
     
+plus port number pair, though there are a few differences.
+{%- endtrans %}
    
 
 
      
-
    • An I2P destination itself is a cryptographic construct - all data sent to one is 
+
    • {% trans -%}
+An I2P destination itself is a cryptographic construct - all data sent to one is 
 encrypted as if there were universal deployment of IPsec with the (anonymized)
-location of the end point signed as if there were universal deployment of DNSSEC. 
      • 
-
    • I2P destinations are mobile identifiers - they can be moved from one I2P router
+location of the end point signed as if there were universal deployment of DNSSEC.
+{%- endtrans %}
      • 
+
    • {% trans -%}
+I2P destinations are mobile identifiers - they can be moved from one I2P router
 to another (or with some special software, it can even operate on multiple routers at
 once).  This is quite different from the TCP or UDP world where a single end point (port)
-must stay on a single host.
      • 
+must stay on a single host.
+{%- endtrans %}
 
    • 
-
      
+
      {% trans -%}
 I2P destinations are ugly and large - behind the scenes, they contain a 2048bit ElGamal
 public key for encryption, a 1024bit DSA public key for signing, and a variable size 
 certificate, which may contain proof of work or blinded data.
-
      
-
      
+{%- endtrans %}
      
+
      {% trans naming=site_url('docs/naming') -%}
 There are existing ways to refer to these large and ugly destinations by short
 and pretty names (e.g. "irc.duck.i2p"), but at the moment those techniques do not guarantee
 globally uniqueness (since they're stored locally at each person's machine as "hosts.txt")
@@ -123,146 +133,174 @@ manually managed within Monotone, and as such, anyone with commit rights on the
 change the destinations).  There may be some secure, human readable, scalable, and globally 
 unique, naming system some day, but applications shouldn't depend upon it being in place,
 since there are those who don't think such a beast is possible.
-Further information on the naming system is available.
-
      
+Further information on the naming system is available.
+{%- endtrans %}
      
 
      • 
 
    
 
-
    Anonymity and confidentiality
    
+
    {{ _('Anonymity and confidentiality') }}
    
 
-
    A useful thing to remember is that I2P has transparent end to end encryption
+
    {% trans -%}
+A useful thing to remember is that I2P has transparent end to end encryption
 and authentication for all data passed over the network - if Bob sends to Alice's destination,
 only Alice's destination can receive it, and if Bob is using the datagrams or streaming 
-library, Alice knows for certain that Bob's destination is the one who sent the data. 
    
+library, Alice knows for certain that Bob's destination is the one who sent the data.
+{%- endtrans %}
    
 
-
    Of course, another useful thing to remember is that I2P transparently anonymizes the
+
    {% trans -%}
+Of course, another useful thing to remember is that I2P transparently anonymizes the
 data sent between Alice and Bob, but it does nothing to anonymize the content of what they
 send.  For instance, if Alice sends Bob a form with her full name, government IDs, and 
 credit card numbers, there is nothing I2P can do.  As such, protocols and applications should 
 keep in mind what information they are trying to protect and what information they are willing
-to expose.
    
+to expose.
+{%- endtrans %}
    
 
-
    I2P datagrams can be up to 32KB
    
+
    {{ _('I2P datagrams can be up to 32KB') }}
    
 
-
    Applications that use I2P datagrams (either raw or repliable ones) can essentially be thought
+
    {% trans -%}
+Applications that use I2P datagrams (either raw or repliable ones) can essentially be thought
 of in terms of UDP - the datagrams are unordered, best effort, and connectionless - but unlike
 UDP, applications don't need to worry about MTU detection and can simply fire off 32KB datagrams
 (31KB when using the repliable kind).  For many applications, 32KB of data is sufficient for an
 entire request or response, allowing them to transparently operate in I2P as a UDP-like 
-application without having to write fragmentation, resends, etc.
    
+application without having to write fragmentation, resends, etc.
+{%- endtrans %}
    
 
-
    Development options
    
+
    {{ _('Development options') }}
    
 
-
    There are several means of sending data over I2P, each with their own pros and cons.
+
    {% trans -%}
+There are several means of sending data over I2P, each with their own pros and cons.
 The streaming lib is the recommended interface, used by the majority of I2P applications.
-
    
+{%- endtrans %}
    
 
-
    Streaming Lib
    
-
    
-The full streaming library is now the standard
+
    {{ _('Streaming Lib') }}
    
+
    {% trans streaming=site_url('docs/api/streaming') -%}
+The full streaming library is now the standard
 interface. It allows programming using TCP-like sockets, as explained in the Streaming development guide.
-
    
+{%- endtrans %}
    
 
 
    BOB
    
-
    BOB is the Basic Open Bridge,
+
    {% trans bob=site_url('docs/api/bob'), boburl=i2pconv('bob.i2p') -%}
+BOB is the Basic Open Bridge,
 allowing an application in any language to make streaming connections 
 to and from I2P. At this point in time it lacks UDP support, but UDP support
 is planned in the near future. BOB also contains several tools, such as 
 destination key generation, and verification that an address conforms to 
 I2P specifications. Up to date info and applications that use BOB can be 
-found at this eepsite.
    
+found at this eepsite.
+{%- endtrans %}
    
 
 
 
    SAM, SAM V2, SAM V3
    
 
-
    SAM is not recommended. SAM V2 is okay, SAM V3 is beta.
    
-
    SAM is the Simple Anonymous Messaging protocol, allowing an
+
    {{ _('SAM is not recommended. SAM V2 is okay, SAM V3 is beta.') }}
    
+
    {% trans sam=site_url('docs/api/sam') -%}
+SAM is the Simple Anonymous Messaging protocol, allowing an
 application written in any language to talk to a SAM bridge through a plain TCP socket and have
 that bridge multiplex all of its I2P traffic, transparently coordinating the encryption/decryption
-and event based handling.  SAM supports three styles of operation:
    
+and event based handling.  SAM supports three styles of operation:
+{%- endtrans %}
    
 
      
-
    • streams, for when Alice and Bob want to send data to each other reliably and in order
      • 
-
    • repliable datagrams, for when Alice wants to send Bob a message that Bob can reply to
      • 
-
    • raw datagrams, for when Alice wants to squeeze the most bandwidth and performance as possible,
-    and Bob doesn't care whether the data's sender is authenticated or not (e.g. the data transferred
-    is self authenticating)
      • 
+
    • {% trans -%}
+streams, for when Alice and Bob want to send data to each other reliably and in order
+{%- endtrans %}
      • 
+
    • {% trans -%}
+repliable datagrams, for when Alice wants to send Bob a message that Bob can reply to
+{%- endtrans %}
      • 
+
    • {% trans -%}
+raw datagrams, for when Alice wants to squeeze the most bandwidth and performance as possible,
+and Bob doesn't care whether the data's sender is authenticated or not (e.g. the data transferred
+is self authenticating)
+{%- endtrans %}
      • 
 
    
-
    SAM V3 aims at the same goal as SAM and SAM V2, but does not require
+
    {% trans -%}
+SAM V3 aims at the same goal as SAM and SAM V2, but does not require
 multiplexing/demultiplexing. Each I2P stream is handled by its own socket between the application
 and the SAM bridge. Besides, datagrams can be sent and received by the application through datagram
 communications with the SAM bridge.
+{%- endtrans %}
    
 
-
    
-
-
    
-SAM V2 is a new version used by imule
-that fixes some of the problems in SAM.
+
    {% trans sam=site_url('docs/api/sam'), samv2=site_url('docs/api/samv2'), samv3=site_url('docs/api/samv3') -%}
+SAM V2 is a new version used by imule
+that fixes some of the problems in SAM.
 
    
-SAM V3 is used by imule since version 1.4.0.
-
    
+SAM V3 is used by imule since version 1.4.0.
+{%- endtrans %}
    
 
 
    I2PTunnel
    
-
    The I2PTunnel application allows applications to build specific TCP-like tunnels to peers 
+
    {% trans -%}
+The I2PTunnel application allows applications to build specific TCP-like tunnels to peers 
 by creating either I2PTunnel 'client' applications (which listen on a specific port and connect
 to a specific I2P destination whenever a socket to that port is opened) or I2PTunnel 'server'
 applications (which listen to a specific I2P destination and whenever it gets a new I2P 
 connection it outproxies to a specific TCP host/port).  These streams are 8bit clean and are
 authenticated and secured through the same streaming library that SAM uses, but there is a 
 nontrivial overhead involved with creating multiple unique I2PTunnel instances, since each have
-their own unique I2P destination and their own set of tunnels, keys, etc.
    
+their own unique I2P destination and their own set of tunnels, keys, etc.
+{%- endtrans %}
    
 
 
    Ministreaming
    
-
    Not recommended
    
-
    
+
    {{ _('Not recommended') }}
    
+
    {% trans -%}
 It was possible to write I2P applications in Java using the ministreaming library.
 However, the Streaming library has superceded this, and provides better functionality.
-
    
+{%- endtrans %}
    
 
-
    Datagrams
    
-
    Not recommended
    
-The Datagram library allows sending UDP-like packets.
+
    {{ _('Datagrams') }}
    
+
    {{ _('Not recommended') }}
    
+
    {% trans datagrams=site_url('docs/spec/datagrams') -%}
+The Datagram library allows sending UDP-like packets.
 It's possible to use:
+{%- endtrans %}
    
 
      
-    
    • Repliable datagrams
      • 
-    
    • Raw datagrams
      • 
+    
    • {{ _('Repliable datagrams') }}
      • 
+    
    • {{ _('Raw datagrams') }}
      • 
 
    
 
 
    I2CP
    
-
    Not recommended
    
-
    I2CP itself is a language independent protocol, but to implement an I2CP library 
+
    {{ _('Not recommended') }}
    
+
    {% trans i2cp=site_url('docs/protocol/i2cp') -%}
+I2CP itself is a language independent protocol, but to implement an I2CP library 
 in something other than Java there is a significant amount of code to be written (encryption routines, 
 object marshalling, asynchronous message handling, etc).  While someone could write an I2CP library in 
 C or something else, it would most likely be more useful to use the C SAM library instead.
-
    
+{%- endtrans %}
    
 
-
    Web Applications
    
+
    {{ _('Web Applications') }}
    
+
    {% trans -%}
 I2P comes with the Jetty webserver, and configuring to use the Apache server instead is straightforward.
 Any standard web app technology should work.
+{%- endtrans %}
    
 
-
    Start developing - a simple guide
    
+
    {{ _('Start developing - a simple guide') }}
    
+
    {% trans -%}
 Developing using I2P requires a working I2P installation and a development environment of your own choice.
 If you are using Java, you can start development with the streaming library or datagram library.
 Using another programming language, SAM or BOB can be used.
+{%- endtrans %}
    
 
-
    Developing with the streaming library
    
+
    {{ _('Developing with the streaming library') }}
    
 
-    Development using the streaming library requires the following libraries in your classpath:
-    
      
-        
    • $I2P/lib/streaming.jar: the streaming library itself.
      • 
-        
    • $I2P/lib/mstreaming.jar: the ministreaming library is used as the base for the streaming library.
      • 
-        
    • $I2P/lib/i2p.jar: some standard I2P classes (like the Destination class) are very convenient when developing.
      • 
-    
    
+
    {% trans -%}
+Development using the streaming library requires the following libraries in your classpath:
+{%- endtrans %}
    
+
      
+    
    • $I2P/lib/streaming.jar: {{ _('the streaming library itself.') }}
      • 
+    
    • $I2P/lib/mstreaming.jar: {{ _('the ministreaming library is used as the base for the streaming library.') }}
      • 
+    
    • $I2P/lib/i2p.jar: {{ _('some standard I2P classes (like the Destination class) are very convenient when developing.') }}
      • 
+
    
 
-
    
-    Network communication requires the usage of I2P network sockets.
-    To demonstrate this, we will create an application where a client can send text messages to a server,
-    who will print the messages and send them back to the client. In other words, the server will function as an echo.
-
    
-
    
-    We will start by initializing the server application. This requires getting an I2PSocketManager
-    and creating an I2PServerSocket.
-    In addition, we will ask the I2PSocketManager for an I2PSession, so we can find out the Destination we use.
-
    
+
    {% trans -%}
+Network communication requires the usage of I2P network sockets.
+To demonstrate this, we will create an application where a client can send text messages to a server,
+who will print the messages and send them back to the client. In other words, the server will function as an echo.
+{%- endtrans %}
    
+
    {% trans -%}
+We will start by initializing the server application. This requires getting an I2PSocketManager
+and creating an I2PServerSocket.
+In addition, we will ask the I2PSocketManager for an I2PSession, so we can find out the Destination we use.
+{%- endtrans %}
    
 
    
     
         package i2p.echoserver;
@@ -286,16 +324,16 @@ Using another programming language, SAM or BOB can be used.
     }
     
    
     

    
-    
    Code example 1: initializing the server application.
    
+    
    {{ _('Code example 1: initializing the server application.') }}
    
 
    
-
    
-    Once we have an I2PServerSocket, we can create I2PSocket instances to accept connections from clients.
-    In this example, we will create a single I2PSocket instance, that can only handle one client at a time.
-    A real server would have to be able to handle multiple clients.
-    To do this, multiple I2PSocket instances would have to be created, each in separate threads.
-    Once we have created the I2PSocket instance, we read data, print it and send it back to the client.
-    The bold code is the new code we add.
-
    
+
    {% trans -%}
+Once we have an I2PServerSocket, we can create I2PSocket instances to accept connections from clients.
+In this example, we will create a single I2PSocket instance, that can only handle one client at a time.
+A real server would have to be able to handle multiple clients.
+To do this, multiple I2PSocket instances would have to be created, each in separate threads.
+Once we have created the I2PSocket instance, we read data, print it and send it back to the client.
+The bold code is the new code we add.
+{%- endtrans %}
    
 
    
     
         package i2p.echoserver;
@@ -374,12 +412,14 @@ Using another programming language, SAM or BOB can be used.
     }
     
    
     

    
-    
    Code example 2: accepting connections from clients and handling messages.
    
+    
    {{ _('Code example 2: accepting connections from clients and handling messages.') }}
    
 
    
 
 
-    When you run the above server code, it should print something like this (but without the line endings, it should just be
-    one huge block of characters):
+
    {% trans -%}
+When you run the above server code, it should print something like this (but without the line endings, it should just be
+one huge block of characters):
+{%- endtrans %}
     
         y17s~L3H9q5xuIyyynyWahAuj6Jeg5VC~Klu9YPquQvD4vlgzmxn4yy~5Z0zVvKJiS2Lk
     poPIcB3r9EbFYkz1mzzE3RYY~XFyPTaFQY8omDv49nltI2VCQ5cx7gAt~y4LdWqkyk3au
@@ -390,16 +430,18 @@ Using another programming language, SAM or BOB can be used.
     BOF6kbxV7NPRPnivbNekd1E1GUq08ltDPVMO1pKJuGMsFyZC4Q~osZ8nI59ryouXgn97Q
     5ZDEO8-Iazx50~yUQTRgLMOTC5hqnAAAA
     
    
-    This is the base64-representation of the server Destination. The client will need this string to reach the server.
+{% trans -%}
+This is the base64-representation of the server Destination. The client will need this string to reach the server.
+{%- endtrans %}
    
 
-
    
-    Now, we will create the client application. Again, a number of steps are required for initialization.
-    Again, we will need to start by getting an I2PSocketManager.
-    We won't use an I2PSession and an I2PServerSocket this time.
-    Instead, we will use the server Destination string to start our connection.
-    We will ask the user for the Destination string, and create an I2PSocket using this string.
-    Once we have an I2PSocket, we can start sending and receiving data to and from the server.
-
    
+
    {% trans -%}
+Now, we will create the client application. Again, a number of steps are required for initialization.
+Again, we will need to start by getting an I2PSocketManager.
+We won't use an I2PSession and an I2PServerSocket this time.
+Instead, we will use the server Destination string to start our connection.
+We will ask the user for the Destination string, and create an I2PSocket using this string.
+Once we have an I2PSocket, we can start sending and receiving data to and from the server.
+{%- endtrans %}
    
 
    
     
         package i2p.echoclient;
@@ -474,53 +516,70 @@ Using another programming language, SAM or BOB can be used.
     }
     
    
     

    
-    
    Code example 3: starting the client and connecting it to the server application.
    
+    
    {{ _('Code example 3: starting the client and connecting it to the server application.') }}
    
 
    
-
    
-    Finally, you can run both the server and the client application.
-    First, start the server application. It will print a Destination string (like shown above).
-    Next, start the client application. When it requests a Destination string, you can enter the string printed by the server.
-    The client will then send 'Hello I2P!' (along with a newline) to the server, who will print the message and send it back to the client.
-
    
-
    
-    Congratulations, you have successfully communicated over I2P!
-
    
+
    {% trans -%}
+Finally, you can run both the server and the client application.
+First, start the server application. It will print a Destination string (like shown above).
+Next, start the client application. When it requests a Destination string, you can enter the string printed by the server.
+The client will then send 'Hello I2P!' (along with a newline) to the server, who will print the message and send it back to the client.
+{%- endtrans %}
    
+
    {% trans -%}
+Congratulations, you have successfully communicated over I2P!
+{%- endtrans %}
    
 
-
    Existing Applications in Development
    
+
    {{ _('Existing Applications in Development') }}
    
+
    {% trans -%}
 Contact us if you would like to help.
+{%- endtrans %}
    
 
 
-
    Application Ideas
    
+
    {{ _('Application Ideas') }}
    
 
      
-
    • NNTP server - there have been some in the past, none at the moment
-
    • Jabber server - there have been some in the past, and there is one at the moment, with access to the public internet
-
    • PGP Key server and/or proxy
-
    • Download manager / eepget scheduler -
+  
    • {% trans -%}
+NNTP server - there have been some in the past, none at the moment
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+Jabber server - there have been some in the past, and there is one at the moment, with access to the public internet
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+PGP Key server and/or proxy
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+Download manager / eepget scheduler -
 We use eepget to fetch lots of things reliably over i2p, and there's already an
 implementation of a sequential download manager (net.i2p.util.EepGetScheduler),
 but there isn't any sort of user interface to it.  A web based UI would be
 great.
-
    • Content Distribution / DHT applications - help out with feedspace,
+{%- endtrans %}
      • 
+  
    • {% trans feedspace=i2pconv('feedspace.i2p') -%}
+Content Distribution / DHT applications - help out with feedspace,
 port dijjer, look for alternatives
-
    • Help out with Syndie development
-
    • Web-based applications - The sky is the limit for hosting web-server-based
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+Help out with Syndie development
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+Web-based applications - The sky is the limit for hosting web-server-based
 applications such as blogs, pastebins, storage, tracking, feeds, etc.
 Any web or CGI technology such as Perl, PHP, Python, or Ruby will work.
-
    • Resurrect some old apps - in the i2p source package -
+{%- endtrans %}
      • 
+  
    • {% trans -%}
+Resurrect some old apps - in the i2p source package -
 bogobot, pants, proxyscript, q, stasher, socks proxy, i2ping
-
    
+{%- endtrans %}
+
 
 {% endblock %}
diff --git a/www.i2p2/pages/developerskeys.html b/i2p2www/pages/site/get-involved/develop/developers-keys.html
similarity index 91%
rename from www.i2p2/pages/developerskeys.html
rename to i2p2www/pages/site/get-involved/develop/developers-keys.html
index 4649b9e8..cf8f0176 100644
--- a/www.i2p2/pages/developerskeys.html
+++ b/i2p2www/pages/site/get-involved/develop/developers-keys.html
@@ -1,17 +1,23 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Developer's MTN Keys{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}I2P Developer's MTN Keys{% endtrans %}{% endblock %}
 {% block content %}
-
    MTN Keys
    
-
    Monotone servers used by the I2P project require two types of keys to be used.
+
    {{ _('MTN Keys') }}
    
+
    {% trans -%}
+Monotone servers used by the I2P project require two types of keys to be used.
+{%- endtrans %}
    
 
      
-  
    • Commit Keys to sign changes checked-in to the respository; and
      • 
-  
    • Transport Keys to push changes to remote servers.
      • 
+  
    • {% trans %}Commit Keys to sign changes checked-in to the respository; and{% endtrans %}
      • 
+  
    • {% trans %}Transport Keys to push changes to remote servers.{% endtrans %}
      • 
 
    
 
-
    Everyone that uses Monotone to checkout the I2P codebase will need to import the
-developer commit keys, but only Monotone server operators will need to import the transport keys.
    
+
    {% trans monotone=site_url('get-involved/guides/monotone') -%}
+Everyone that uses Monotone to checkout the I2P codebase will need to
+import the
+developer commit keys, but only Monotone 
+server operators will need to import the transport keys.
+{%- endtrans %}
    
 
-
    Developer Commit keys
    
+
    {{ _('Developer Commit keys') }}
    
 
     [pubkey jrandom@i2p.net]
 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLw05kZbux5KLdp
@@ -223,8 +229,11 @@ rIeB7/2uVOpe+3FrFgUzIiWsx6I2yiNI3TscDvQsa5wG0Z2G4BbHXj
 ONyiUzzO+j2TWPs3x35r2LCy8plRzPAswCF1GaIEjJCce5zwIDAQAB
 [end]
 
    
-
    Developer Transport Keys
    
-
    Note: Transport keys are only needed for setting up a Monotone server.
    
+
    {{ _('Developer Transport Keys') }}
    
+
    {% trans monotone=site_url('get-involved/guides/monotone') -%}
+Note: Transport keys are only needed for setting up a
+Monotone server.
+{%- endtrans %}
    
 
 
     [pubkey zzz-transport@mail.i2p]
diff --git a/www.i2p2/pages/license-agreements.html b/i2p2www/pages/site/get-involved/develop/license-agreements.html
similarity index 98%
rename from www.i2p2/pages/license-agreements.html
rename to i2p2www/pages/site/get-involved/develop/license-agreements.html
index 3562fd5f..cbe9f4e5 100644
--- a/www.i2p2/pages/license-agreements.html
+++ b/i2p2www/pages/site/get-involved/develop/license-agreements.html
@@ -1,15 +1,20 @@
-{% extends "_layout.html" %}
-{% block title %}License Agreements{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('License Agreements') }}{% endblock %}
 {% block content %}
 
-
    For more information see licenses.html.
-
    Following is a monotonerc file defining the current trust list.
+
    {% trans licenses=site_url('get-involved/develop/licenses') -%}
+For more information see the licenses page.
+{%- endtrans %}
    
+
    {% trans -%}
+Following is a monotonerc file defining the current trust list.
 Developers must use this file in ~/.monotone/monotonerc or
 _MTN/montonerc in their i2p.i2p workspace.
+{%- endtrans %}
 
-{% include "_monotonerc.html" %}
+{% include "include/monotonerc.html" %}
 
-
    Agreements:
+
    
+
    {{ _('Agreements') }}:
 
     
 Complication:
diff --git a/www.i2p2/pages/licenses.html b/i2p2www/pages/site/get-involved/develop/licenses.html
similarity index 77%
rename from www.i2p2/pages/licenses.html
rename to i2p2www/pages/site/get-involved/develop/licenses.html
index 327a21c4..9010e94e 100644
--- a/www.i2p2/pages/licenses.html
+++ b/i2p2www/pages/site/get-involved/develop/licenses.html
@@ -1,30 +1,34 @@
-{% extends "_layout.html" %}
-{% block title %}Licenses{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Licenses') }}{% endblock %}
 {% block content %}
-
    I2P Software Licenses
    
-
    
+
    {{ _('I2P Software Licenses') }}
    
+
    {% trans threatmodel=site_url('docs/how/threat-model') -%}
 As required by our
-threat model (among other reasons), the 
+threat model (among other reasons), the 
 software developed to support the anonymous communication 
 network we call I2P must be freely available, open source, 
 and user modifiable.  To meet these criteria, we make use of
 a variety of legal and software engineering techniques so
 as to remove as many barriers to entry for those considering
-making use of or contributing to the I2P effort.
    
+making use of or contributing to the I2P effort.
+{%- endtrans %}
    
 
-
    While the information below may be more confusing than just simply 
+
    {% trans -%}
+While the information below may be more confusing than just simply 
 stating "I2P is BSD", "I2P is GPL", or "I2P is public domain",
-the short answer to the question "How is I2P licensed?" is this:
    
+the short answer to the question "How is I2P licensed?" is this:
+{%- endtrans %}
    
 
-
    All software bundled in the I2P distributions will allow:
    
+
    {{ _('All software bundled in the I2P distributions will allow:') }}
    
 
      
- 
    1. use without fee
      2. 
- 
    2. use with no restrictions on how, when, where, why, or by whom is running it
      3. 
- 
    3. access to the source code without fee
      4. 
- 
    4. modifications to the source
      5. 
+ 
    5. {{ _('use without fee') }}
      6. 
+ 
    6. {{ _('use with no restrictions on how, when, where, why, or by whom is running it') }}
      7. 
+ 
    7. {{ _('access to the source code without fee') }}
      8. 
+ 
    8. {{ _('modifications to the source') }}
      9. 
 
    
 
-
    Most of the software guarantees much more - the ability of anyone to 
+
    {% trans -%}
+Most of the software guarantees much more - the ability of anyone to 
 distribute the modified source however they choose.  However, not all of the 
 software bundled provides this freedom - the GPL restricts the ability of 
 developers who wish to integrate I2P with their own applications that are not 
@@ -33,26 +37,29 @@ increasing the resources in the commons, I2P is best served by removing any
 barriers that stand in the way of its adoption - if a developer considering whether
 they can integrate I2P with their application has to stop and check with their lawyer,
 or conduct a code audit to make sure their own source can be released as GPL-compatible,
-we lose out.
    
+we lose out.
+{%- endtrans %}
    
 
-
    Component licenses
    
-
    The I2P distribution contains several resources, reflecting the partitioning of 
+
    {{ _('Component licenses') }}
    
+
    {% trans -%}
+The I2P distribution contains several resources, reflecting the partitioning of 
 the source code into components.  Each component has its own license, which all 
 developers who contribute to it agree to - either by explicitly declaring the release
 of code committed under a license compatible with that component, or by implicitly
 releasing the code committed under the component's primary license.  Each of these 
 components has a lead developer who has the final say as to what license is compatible
 with the component's primary license, and the I2P project manager has the final say as
-to what licenses meet the above four guarantees for inclusion in the I2P distribution.
    
+to what licenses meet the above four guarantees for inclusion in the I2P distribution.
+{%- endtrans %}
    
 
 
-  
-  
-  
-  
-  
-  
+  
+  
+  
+  
+  
+  
@@ -130,7 +137,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
   
-  
+  
 
@@ -143,12 +150,12 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
   
-  
+  
+	  Artistic
-  
+  
 
@@ -170,7 +177,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
   
-  
+  
 
@@ -183,7 +190,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
   
-  
+  
 
@@ -261,11 +268,13 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
  
    
  
    ComponentSource pathResourcePrimary licenseAlternate licensesLead developer{{ _('Component') }}{{ _('Source path') }}{{ _('Resource') }}{{ _('Primary license') }}{{ _('Alternate licenses') }}{{ _('Lead developer') }}
  
    
  
    
   I2P SDKmihi
  
    
  
    SAM BridgeSAM Bridge
   apps/sam
   sam.jarhuman
  
    
  
    SAM perl librarySAM perl library
   apps/sam/perl
   SAM.pm
 
   
-	  Artistic
   
     Public domain
    
     Cryptix
    
@@ -157,7 +164,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
       		BrianR
  
    
  
    SAM C librarySAM C library
   apps/sam/c
   libSAMNightblade
  
    
  
    SAM Python librarySAM Python library
   apps/sam/python
   i2p.pyConnelly
  
    
  
    SAM C# librarySAM C# library
   apps/sam/csharp/
   n/a
    
 
     
 
-
    GPL + java exception
    
-
    While it may be redundant, just for clarity the
-GPL'ed code included within
+
    {{ _('GPL + java exception') }}
    
+
    {% trans gpl='https://www.gnu.org/licenses/gpl.html' -%}
+While it may be redundant, just for clarity the
+GPL'ed code included within
 I2PTunnel and other apps must be released under the GPL with an additional "exception"
-explicitly authorizing the use of Java's standard libraries:
    
+explicitly authorizing the use of Java's standard libraries:
+{%- endtrans %}
    
 
 
    In addition, as a special exception, XXXX gives permission to link the
 code of this program with the proprietary Java implementation provided by Sun
@@ -276,36 +285,46 @@ file, you may extend this exception to your version of the file, but you are not
 obligated to do so. If you do not wish to do so, delete this exception statement
 from your version.
    
 
-
    All source code under each component will by default be licensed under the
+
    {% trans -%}
+All source code under each component will by default be licensed under the
 primary license, unless marked otherwise in the code.  All of the above is
 summary of the license terms - please see the specific license for the component
 or source code in question for authoritative terms.  Component source locations and
-resource packaging may be changed if the repository is reorganized.
    
+resource packaging may be changed if the repository is reorganized.
+{%- endtrans %}
    
 
-
    Commit privileges
    
-
    
+
    {{ _('Commit privileges') }}
    
+
    {% trans monotone=site_url('get-involved/guides/monotone') -%}
 Developers may push changes to a distributed monotone repository if you
 receive permission from the person running that repository.
-See the Monotone Page for details.
-
    
+See the Monotone Page for details.
+{%- endtrans %}
    
 
-
    
+
    {% trans -%}
 However, to have changes included in a release, developers
 must be trusted by the release manager (currently zzz).
 In addition, they must explicitly agree with the above terms to be trusted.
-That means that they must send one of the release managers a signed message affirming that:
    
+That means that they must send one of the release managers a signed message affirming that:
+{%- endtrans %}
    
 
      
- 
    • Unless marked otherwise, all code I commit is implicitly licensed under
- the component's primary license
      • 
- 
    • If specified in the source, the code may be explicitly licensed under one
- of the component's alternate licenses
      • 
- 
    • I have the right to release the code I commit under the terms I
- am committing it
      • 
+ 
    • {% trans -%}
+Unless marked otherwise, all code I commit is implicitly licensed under
+the component's primary license
+{%- endtrans %}
      • 
+ 
    • {% trans -%}
+If specified in the source, the code may be explicitly licensed under one
+of the component's alternate licenses
+{%- endtrans %}
      • 
+ 
    • {% trans -%}
+I have the right to release the code I commit under the terms I
+am committing it
+{%- endtrans %}
      • 
 
    
 
-
    If anyone is aware of any instances where the above conditions are not met,
+
    {% trans licenseagreements=site_url('get-involved/develop/license-agreements') -%}
+If anyone is aware of any instances where the above conditions are not met,
 please contact the component lead and/or an I2P release manager with further
 information.
-See developers' license agreements.
-
    
+See developers' license agreements.
+{%- endtrans %}
    
 {% endblock %}
diff --git a/www.i2p2/pages/release-signing-key.html b/i2p2www/pages/site/get-involved/develop/release-signing-key.html
similarity index 96%
rename from www.i2p2/pages/release-signing-key.html
rename to i2p2www/pages/site/get-involved/develop/release-signing-key.html
index 33531665..aa532823 100644
--- a/www.i2p2/pages/release-signing-key.html
+++ b/i2p2www/pages/site/get-involved/develop/release-signing-key.html
@@ -1,7 +1,9 @@
-{% extends "_layout.html" %}
-{% block title %}Release Signing Key{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Release Signing Key') }}{% endblock %}
 {% block content %}
+
    {% trans -%}
 Releases 0.7.6 and later are signed by zzz. His public key is:
+{%- endtrans %}
    
 
    
 
     -----BEGIN PGP PUBLIC KEY BLOCK-----
@@ -35,8 +37,9 @@ njMu9ueCFbsjme7nwsz96PdazJcHAKCce17hGI25QNXDZyHohrjha6IxDg==
 -----END PGP PUBLIC KEY BLOCK-----
 
 
    
-
    
+
    {% trans -%}
 Releases 0.6.1.31 through 0.7.5 were signed by Complication. His public key is:
+{%- endtrans %}
    
 
    
 
     -----BEGIN PGP SIGNED MESSAGE-----
diff --git a/www.i2p2/pages/signedkeys.html b/i2p2www/pages/site/get-involved/develop/signed-keys.html
similarity index 53%
rename from www.i2p2/pages/signedkeys.html
rename to i2p2www/pages/site/get-involved/develop/signed-keys.html
index 27277d08..3befbb97 100644
--- a/www.i2p2/pages/signedkeys.html
+++ b/i2p2www/pages/site/get-involved/develop/signed-keys.html
@@ -1,22 +1,24 @@
-{% extends "_layout.html" %}
-{% block title %}Signed Developer Keys{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Signed Developer Keys') }}{% endblock %}
 {% block content %}
-
    Keys for zzz, Complication and welterde are provided clearsigned. The key for jrandom must be
-  verified differently, since he's away, and only left a binary detached
-  signature for his key.
+
    {% trans -%}
+Keys for zzz, Complication and welterde are provided clearsigned. The key for jrandom must be
+verified differently, since he's away, and only left a binary detached
+signature for his key.
+{%- endtrans %}
    
   
      
-    
    1. Monotone keys for zzz
      2. 
-            
    2. Monotone keys for welterde
      3. 
-            
    3. Monotone keys for Complication
      4. 
-            
    4. Monotone keys for jrandom
      5. 
-            
    5. Others
      6. 
+    
    6. {{ _('Monotone keys for zzz') }}
      7. 
+            
    7. {{ _('Monotone keys for welterde') }}
      8. 
+            
    8. {{ _('Monotone keys for Complication') }}
      9. 
+            
    9. {{ _('Monotone keys for jrandom') }}
      10. 
+            
    10. {{ _('Others') }}
      11. 
   
    
-
    Monotone keys for zzz
    
-
    
-  Tip: To find zzz's GPG key, on his eepsite locate the key `0xA76E0BED`, with
-  the name `zzz@mail.i2p` and the fingerprint `4456 EBBE C805 63FE 57E6 B310 4155
-  76BA A76E 0BED`.
-
    
+
    {{ _('Monotone keys for zzz') }}
    
+
    {% trans -%}
+Tip: To find zzz's GPG key, on his eepsite locate the key `0xA76E0BED`, with
+the name `zzz@mail.i2p` and the fingerprint `4456 EBBE C805 63FE 57E6 B310 4155
+76BA A76E 0BED`.
+{%- endtrans %}
    
 
 
         -----BEGIN PGP SIGNED MESSAGE-----
@@ -42,13 +44,13 @@
 
    
 
 
-
    Monotone keys for welterde
    
+
    {{ _('Monotone keys for welterde') }}
    
 
-
    
-  Tip: To find welterde's GPG key, on public keyservers locate the key
-  `0x62E011A1`, with the name `welterde@arcor.de` and the fingerprint `6720 FD81
-  3872 6DFC 6016 64D1 EBBC 0374 62E0 11A1`.
-
    
+
    {% trans -%}
+Tip: To find welterde's GPG key, on public keyservers locate the key
+`0x62E011A1`, with the name `welterde@arcor.de` and the fingerprint `6720 FD81
+3872 6DFC 6016 64D1 EBBC 0374 62E0 11A1`.
+{%- endtrans %}
    
 
 
         -----BEGIN PGP SIGNED MESSAGE-----
@@ -74,13 +76,13 @@
 
    
 
 
-
    Monotone keys for Complication
    
+
    {{ _('Monotone keys for Complication') }}
    
 
-
    
-  Tip: To find Complication's GPG key, on his eepsite locate the key
-  `0x79FCCE33`, with the name `complication@mail.i2p` and the fingerprint `73CF
-  2862 87A7 E7D2 19FF DB66 FA1D FC6B 79FC CE33`.
-
    
+
    {% trans -%}
+Tip: To find Complication's GPG key, on his eepsite locate the key
+`0x79FCCE33`, with the name `complication@mail.i2p` and the fingerprint `73CF
+2862 87A7 E7D2 19FF DB66 FA1D FC6B 79FC CE33`.
+{%- endtrans %}
    
 
 
         -----BEGIN PGP SIGNED MESSAGE-----
@@ -109,27 +111,27 @@
     -----END PGP SIGNATURE-----
 
    
 
-
    Monotone keys for jrandom
    
+
    {{ _('Monotone keys for jrandom') }}
    
 
-
    
-  Tip: To find jrandom's GPG key for Syndie releases, on public keyservers locate
-  the key `0x393F2DF9`, with the name `syndie-dist-key@i2p.net` and the
-  fingerprint `AE89 D080 0E85 72F0 B777 B2ED C2FA 68C0 393F 2DF9`.
-
    
+
    {% trans -%}
+Tip: To find jrandom's GPG key for Syndie releases, on public keyservers locate
+the key `0x393F2DF9`, with the name `syndie-dist-key@i2p.net` and the
+fingerprint `AE89 D080 0E85 72F0 B777 B2ED C2FA 68C0 393F 2DF9`.
+{%- endtrans %}
    
 
-
    
-  Jrandom had to leave unexpectedly in the end of 2007. His commit key was
-  deployed in the Syndie Monotone repository, in a file named `mtn-committers`.
-  That file also had a GPG signature, `mtn-committers.sig`, but it was a binary
-  detached signature. I am going to supply both files in GPG ASCII-armoured form
-  below.
-
    
+
    {% trans -%}
+Jrandom had to leave unexpectedly in the end of 2007. His commit key was
+deployed in the Syndie Monotone repository, in a file named `mtn-committers`.
+That file also had a GPG signature, `mtn-committers.sig`, but it was a binary
+detached signature. I am going to supply both files in GPG ASCII-armoured form
+below.
+{%- endtrans %}
    
 
-
    
-  First, the file `mtn-committers` containing jrandom's Monotone key. Save as
-  `mtn-committers.asc` and unpack it using `gpg --output mtn-committers --dearmor
-  mtn-committers.asc`:
-
    
+
    {% trans -%}
+First, the file `mtn-committers` containing jrandom's Monotone key. Save as
+`mtn-committers.asc` and unpack it using `gpg --output mtn-committers --dearmor
+mtn-committers.asc`:
+{%- endtrans %}
    
 
 
         -----BEGIN PGP ARMORED FILE-----
@@ -146,12 +148,12 @@
     -----END PGP ARMORED FILE-----
 
    
 
-
    
-  Now the file `mtn-committers.sig`, containing the GPG signature. Save as
-  `mtn-committers.sig.asc` and unpack it using `gpg --output mtn-committers.sig
-  --dearmor mtn-committers.sig.asc`. Use it to verify the above supplied
-  `mtn-committers` file:
-
    
+
    {% trans -%}
+Now the file `mtn-committers.sig`, containing the GPG signature. Save as
+`mtn-committers.sig.asc` and unpack it using `gpg --output mtn-committers.sig
+--dearmor mtn-committers.sig.asc`. Use it to verify the above supplied
+`mtn-committers` file:
+{%- endtrans %}
    
 
 
         -----BEGIN PGP ARMORED FILE-----
@@ -164,8 +166,10 @@
     -----END PGP ARMORED FILE-----
 
    
 
-
    Others
    
-Some of the developers have included their Monotone keys in their signed license agreement.
+
    {{ _('Others') }}
    
+
    {% trans licenseagreements=site_url('get-involved/develop/license-agreements') -%}
+Some of the developers have included their Monotone keys in their signed license agreement.
+{%- endtrans %}
    
 
 {% endblock %}
 
diff --git a/www.i2p2/pages/donate.html b/i2p2www/pages/site/get-involved/donate.html
similarity index 56%
rename from www.i2p2/pages/donate.html
rename to i2p2www/pages/site/get-involved/donate.html
index 5652ee67..3d4e7c3b 100644
--- a/www.i2p2/pages/donate.html
+++ b/i2p2www/pages/site/get-involved/donate.html
@@ -1,17 +1,22 @@
-{% extends "_layout.html" %}
-{% block title %}Donate{% endblock %}
-{% block content %}
    Thank you for your interest in contributing to I2P!
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Donate') }}{% endblock %}
+{% block content %}
+
    {% trans -%}
+Thank you for your interest in contributing to I2P!
 The details of how you
-can make your contribution are provided below.
    
+can make your contribution are provided below.
+{%- endtrans %}
    
 
 
 
    PayPal
    
 
    
-You can donate direct via PayPal to the account "echelon@i2pmail.org".
    
+{% trans account='echelon@i2pmail.org' -%}
+You can donate direct via PayPal to the account "{{ account }}".
+{%- endtrans %}
    
 
    
 
-
+
-
+
-
+
-
+
-
+
    
 
    One time donation:{{ _('One time donation:') }}
 
 
    
 
@@ -25,7 +30,7 @@ You can donate direct via PayPal to the account "echelon@i2pmail.org".
    
 
    
 
 
    Donate 10 €/month for 12 months: {{ _('Donate 10 €/month for 12 months:') }}
 
 
 
    
@@ -33,63 +38,71 @@ You can donate direct via PayPal to the account "echelon@i2pmail.org".
    
 
 
 
-
+
 
    
 
     		
 
    
 
    Donate 20 €/month for 12 months: {{ _('Donate 20 €/month for 12 months:') }}
 
 
    
 
    
 
 
-
+
 
    
 
    
     		
 
    
 
    Donate 30 €/month for 12 months: {{ _('Donate 30 €/month for 12 months:') }}
 
 
    
 
    
 
 
-
+
 
    
 
    
     		
 
    
 
    Donate 50 €/month for 12 months: {{ _('Donate 50 €/month for 12 months:') }}
 
 
    
 
    
 
 
-
+
 
    
 
    
     		
 
    
 
    
 
    
-
    Flattr
    
+
    Flattr
    
 
-Flattr this
+{{ _('Flattr this') }}
 
    
 
    
-
    Bitcoin
    
-
    As of December 2010, eche|on has been running a Bitcoin account for the I2P project. 
+
    Bitcoin
    
+
    {% trans account='1HkJCceXf7of1sTNRVJbXiZHfDTLL71Siy' -%}
+As of December 2010, eche|on has been running a Bitcoin account for the I2P project. 
 If you'd like to donate using Bitcoin, just transfer your desired amount of coins to the account 
-1HkJCceXf7of1sTNRVJbXiZHfDTLL71Siy and leave eche|on a note if you'd like your donation to be mentioned on the I2P webpage.
    
-
    
-
    If you want to keep more or less anonymous, the option to send money via mail is also available. But it is less secure
-as the envelope can be lost on the way to us. 
    
-
    If you'd like to donate via  snail mail, send an email to echelon@i2pmail.org
- and you'll receive an email with instructions detailing how to proceed.
    
+{{ account }} and leave eche|on a note if you'd like your donation to be mentioned on the I2P webpage.
+{%- endtrans %}
    
+
    {% trans -%}
+If you want to keep more or less anonymous, the option to send money via mail is also available. But it is less secure
+as the envelope can be lost on the way to us.
+{%- endtrans %}
    
+
    {% trans email='echelon@i2pmail.org' -%}
+If you'd like to donate via  snail mail, send an email to {{ email }}
+ and you'll receive an email with instructions detailing how to proceed.
+{%- endtrans %}
    
 
-
    In the meantime, feel free to take a look at the generous donations that have been given in support of the I2P Project at the hall of fame.
    
+
    {% trans halloffame=site_url('about/hall-of-fame') -%}
+In the meantime, feel free to take a look at the generous donations that have been
+given in support of the I2P Project at the hall of fame.
+{%- endtrans %}
    
 {% endblock %}
diff --git a/www.i2p2/pages/dev-guidelines.html b/i2p2www/pages/site/get-involved/guides/dev-guidelines.html
similarity index 72%
rename from www.i2p2/pages/dev-guidelines.html
rename to i2p2www/pages/site/get-involved/guides/dev-guidelines.html
index 2943f1ad..a57427f1 100644
--- a/www.i2p2/pages/dev-guidelines.html
+++ b/i2p2www/pages/site/get-involved/guides/dev-guidelines.html
@@ -1,42 +1,45 @@
-{% extends "_layout.html" %}
-{% block title %}Developer Guidelines and Coding Style{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Developer Guidelines and Coding Style') }}{% endblock %}
 {% block content %}
-
    
-  Read the new developers guide first.  
-
    
+
    {% trans newdevs=site_url('get-involved/guides/new-developers') -%}
+Read the new developers guide first.
+{%- endtrans %}
    
 
-
    Basic Guidelines and Coding Style
    
+
    {{ _('Basic Guidelines and Coding Style') }}
    
 
-
    
-  Most of the following should be common sense for anybody who has worked on open source or in a commercial
-  programming envrionment.
-  The following applies mostly to the main development branch i2p.i2p.
-  Guidelines for other branches, plugins, and external apps may be substantially different;
-  check with the appropriate developer for guidance.
-
    
+
    {% trans -%}
+Most of the following should be common sense for anybody who has worked on open source or in a commercial
+programming envrionment.
+The following applies mostly to the main development branch i2p.i2p.
+Guidelines for other branches, plugins, and external apps may be substantially different;
+check with the appropriate developer for guidance.
+{%- endtrans %}
    
 
-
    Community
    
+
    {{ _('Community') }}
    
 
      
-
    • 
+
    • {% trans -%}
 Please don't just "write code". If you can, participate in other development activities, including:
 development discussions and support on IRC, zzz.i2p, and forum.i2p; testing;
 bug reporting and responses; documentation; code reviews; etc.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Active devs should be available periodically on IRC #i2p-dev.
 Be aware of the current release cycle.
 Adhere to release milestones such as feature freeze, tag freeze, and
 the checkin deadline for a release.
-
    
+{%- endtrans %}
+
 
 
    Monotone
    
 
      
-
    • 
+
    • {% trans -%}
 Have a basic understanding of distributed source control systems, even if you haven't
 used monotone before. Ask for help if you need it.
 Once pushed, checkins are forever, there is no undo. Please be careful.
 If you have not used monotone before, start with baby steps.
 Check in some small changes and see how it goes.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Test your changes before checking them in.
 If you prefer the checkin-before-test development model,
 use your own development branch (e.g. i2p.i2p.yourname.test)
@@ -44,87 +47,102 @@ and propagate back to i2p.i2p once it is working well.
 Do not break the build. Do not cause regressions.
 In case you do (it happens), please do not vanish for a long period after
 you push your change.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 If your change is non-trivial, or you want people to test it and need good test reports
 to know whether your change was tested or not, add a checkin comment to history.txt
 and increment the build revision in RouterVersion.java.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Ensure that you have the latest monotonerc file in _MTN.
 Do not check in on top of untrusted revisions.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Ensure that you pull the latest revision before you check in.
 If you inadvertently diverge, merge and push as soon as possible.
 Don't routinely make others merge for you.
 Yes, we know that monotone says you should push and then merge,
 but in our experience, in-workspace merge works just as well as in-database merge,
 without creating a merge revision.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Do not check in major changes into the main i2p.i2p branch late in the release cycle.
 If a project will take you more than a couple days, create your own branch in monotone
 and do the development there so you do not block releases.
-
    
+{%- endtrans %}
+
 
-
    Coding Style
    
+
    {{ _('Coding Style') }}
    
 
      
-
    • 
+
    • {% trans -%}
 Coding style throughout most of the code is 4-spaces for indentation. Do not use tabs.
 Do not reformat code. If your IDE or editor wants to reformat everything, get control of it.
 Yes, we know 4 spaces is a pain, but perhaps you can configure your editor appropriately.
 In some places, the coding style is different.
 Use common sense. Emulate the style in the file you are modifying.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 New classes and methods require at least brief javadocs. Add @since release-number.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Classes in core/ (i2p.jar) and portions of i2ptunnel are part of our official API.
 There are several out-of-tree plugins and other applications that rely on this API.
 Be careful not to make any changes that break compatibility.
 Don't add methods to the API unless they are of general utility.
 Javadocs for API methods should be clear and complete.
 If you add or change the API, also update the documentation on the website (i2p.www branch).
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Tag strings for translation where appropriate.
 Don't change existing tagged strings unless really necessary, as it will break existing translations.
 Do not add or change tagged strings after the "tag freeze" in the release cycle so that
 translators have a chance to update before the release.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Use generics and concurrent classes where possible. I2P is a highly multi-threaded application.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 We require Java 6 to build but only Java 5 to run I2P.
 Do not use Java 6 classes or methods without handling the class not found exceptions
 and providing alternate Java 5 code. See classes in net.i2p.util for examples.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Explicitly convert between primitive types and classes;
 don't rely on autoboxing/unboxing.
-
    
+{%- endtrans %}
+
 
-
    Licenses
    
+
    {{ _('Licenses') }}
    
 
      
-
    • 
+
    • {% trans -%}
 Only check in code that you wrote yourself.
 Before checking in any code or library jars from other sources,
 justify why it is necessary,
 verify the license is compatible,
 and obtain approval from the lead developer.
-
    • 
+{%- endtrans %}
      • 
+
    • {% trans -%}
 For any images checked in from external sources,
 it is your responsibility to first verify the license is compatible.
 Include the license and source information in the checkin comment.
-
    
+{%- endtrans %}
+
 
-
    Bugs
    
+
    {{ _('Bugs') }}
    
 
      
-
    • 
+
    • {% trans trac=i2pconv('trac.i2p2.i2p') -%}
 Managing Trac tickets is everybody's job, please help.
-Monitor trac.i2p2.i2p for tickets you have been assigned or can help with.
-Asssign, categorize, comment on, fix, or close tickets if you can.
-
    • 
+Monitor {{ trac }} for tickets you have been assigned or can help with.
+Assign, categorize, comment on, fix, or close tickets if you can.
+{%- endtrans %}
      • 
+
    • {% trans -%}
 Close a ticket when you think you've fixed it.
 We don't have a test department to verify and close tickets.
 If you arent sure you fixed it, close it and add a note saying
 "I think I fixed it, please test and reopen if it's still broken".
 Add a comment with the dev build number or revision and set
 the milestone to the next release.
-
      • 
+{%- endtrans %}
 
    
 
 {% endblock %}
diff --git a/i2p2www/pages/site/get-involved/guides/ides.html b/i2p2www/pages/site/get-involved/guides/ides.html
new file mode 100644
index 00000000..bb116c0f
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/guides/ides.html
@@ -0,0 +1,51 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Using an IDE with I2P') }}{% endblock %}
+{% block content %}
+
    {% trans -%}
+The main I2P development branch (i2p.i2p) has been set up to enable developers to easily set up two of the commonly-used IDEs for Java development: Eclipse and NetBeans.
+{%- endtrans %}
    
+
+
    Eclipse
    
+
+
    {% trans -%}
+The main I2P development branches (i2p.i2p and branches from it) contain .project and .classpath Eclipse files, to enable the branch to be easily set up in Eclipse.
+{%- endtrans %}
    
+
+
      
+
+
    1. {% trans -%}
+Check out the I2P branch into some directory (e.g. $HOME/dev/i2p.i2p).
+{%- endtrans %}
      2. 
+
+
    2. {% trans -%}
+Open Eclipse and create a new Workspace, based in the directory that the I2P branch was checked out to.
+{%- endtrans %}
      3. 
+
+
    3. {% trans -%}
+Select "File - Import..." and then under "General" select "Existing Projects into Workspace".
+{%- endtrans %}
      4. 
+
+
    4. {% trans -%}
+For "Select root directory:" choose the directory that the I2P branch was checked out to.
+{%- endtrans %}
      5. 
+
+
    5. {% trans -%}
+If necessary, click "Refresh" to refresh the list of projects.
+{%- endtrans %}
      6. 
+
+
    6. {% trans -%}
+Select every project in the list, and click "Finish".
+{%- endtrans %}
      7. 
+
+
    7. {% trans -%}
+Done! Your workspace should now contain all projects within the I2P branch, and their build dependencies should be correctly set up.
+{%- endtrans %}
      8. 
+
+
    
+
+
    NetBeans
    
+
+
    {% trans -%}
+The main I2P development branches (i2p.i2p and branches from it) contain NetBeans project files.
+{%- endtrans %}
    
+{% endblock %}
diff --git a/www.i2p2/pages/monotone.html b/i2p2www/pages/site/get-involved/guides/monotone.html
similarity index 50%
rename from www.i2p2/pages/monotone.html
rename to i2p2www/pages/site/get-involved/guides/monotone.html
index 76cc983f..362b62f1 100644
--- a/www.i2p2/pages/monotone.html
+++ b/i2p2www/pages/site/get-involved/guides/monotone.html
@@ -1,91 +1,108 @@
-{% extends "_layout.html" %}
-{% block title %}Monotone{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Monotone{% endtrans %}{% endblock %}
 {% block content %}
-
    Monotone Guide
    
+
    {% trans %}Monotone Guide{% endtrans %}
    
 
 
 
-
    
-  This is a revised version of Complication's original
+
    
+  {% trans transitionguide=site_url('misc/transition-guide'), newdevs=site_url('get-involved/guides/new-developers') -%}
+  This is a revised version of Complication's original
   guide detailing the use of Monotone in I2P development.
-  For basic instructions see the quick-start guide.
-
    
+  For basic instructions see the quick-start guide.
+  {%- endtrans %}
+
    
 
 
    
+  {% trans licenses=site_url('get-involved/develop/licenses') -%}
   I2P has a distributed development model. The source code is replicated across
   independently administered Monotone ("MTN") repositories.
-  Developers with commit rights are able to push their changes to the repository (a license agreement
-  needs to be signed before commit rights are granted).
+  Developers with commit rights are able to push their changes to the repository
+  (a license agreement needs to be signed
+  before commit rights are granted).
+  {%- endtrans %}
 
    
 
 
    
+  {% trans -%}
   Some of Monotone's noteworthy qualities are: distributed
   version control, cryptographic authentication, access control, its small size, having few
   dependencies, storage of projects in a compressed SQLite database file, and
   having the ability to resume interrupted synchronization attempts.
+  {%- endtrans %}
 
    
 
 
-
    Operating a Monotone Client
    
+
    {% trans %}Operating a Monotone Client{% endtrans %}
    
 
-
    Generating Monotone keys
    
+
    {% trans %}Generating Monotone keys{% endtrans %}
    
 
 
    
+  {% trans -%}
   A transport key grants you the ability to push your changes to a Monotone repository server.
   In order to commit code into Monotone (in essence signing your code), a commit key is also needed.
   None of the public Monotone servers on I2P currently require a key in order to read (or pull) the source code.
+  {%- endtrans %}
 
    
 
 
    
+  {% trans -%}
   Without a transport key, one cannot:
   
      
     
    • pull code from a server which doesn't allow global read access
      • 
     
    • push code to any server
      • 
     
    • run a Monotone server
      • 
   
    
+  {%- endtrans %}
 
    
 
 
    
+  {% trans -%}
   Without a commit key, one cannot:
   
      
     
    • commit any code
      • 
   
    
+  {%- endtrans %}
 
    
 
 
    
+  {% trans -%}
   If you only intend to retrieve code from MTN, feel free to skip to the
   next section. If you want
   to generate keys, read the following.
+  {%- endtrans %}
 
    
 
 
    
+  {% trans -%}
   By convention keys are named like an e-mail addresses, but a corresponding e-mail
   address does not need to exist. For example, your keys might be named:
+  {%- endtrans %}
   
      
     
    • yourname@mail.i2p
      • 
     
    • yourname-transport@mail.i2p
      • 
@@ -93,15 +110,19 @@
 
      
 
 
      
+  {% trans -%}
   Monotone stores keys under $HOME/.monotone/keys in text files which
   are named identically to the keys. For example:
+  {%- endtrans %}
   
        
     
      • /home/complication/.monotone/keys/complication@mail.i2p
        • 
   
      
 
      
 
 
      
+  {% trans -%}
   To generate transport and commit keys, enter the following commands at a prompt:
+  {%- endtrans %}
   
        
     
      • $ mtn genkey yourname-transport@someplace
        • 
     
      • $ mtn genkey yourname@someplace
        • 
@@ -109,163 +130,211 @@
 
        
 
 
        
+  {% trans -%}
   Monotone will prompt you for a password to protect your keys. You are very strongly encouraged to set a password
   for the commit key. Many users will leave an empty password for the transport key, especially those running a
   Monotone server.
+  {%- endtrans %}
 
        
 
 
-
        Trust, and initializing your repository
        
+
        {% trans %}Trust, and initializing your repository{% endtrans %}
        
 
 
        
   
+  {% trans -%}
   Monotone's security model helps to ensure that nobody can easily impersonate a developer without
   it being noticed. Since developers can make mistakes and become compromised,only manual review can
   ensure quality of code. Monotone's trust model will ensure that you read the right diffs. It does
   not replace reading diffs.
+  {%- endtrans %}
   
 
        
 
 
        
+  {% trans -%}
   A Monotone repository is a single file (a compressed SQLite database) which contains all of the project's source code and history.
+  {%- endtrans %}
 
        
 
 
        
+  {% trans -%}
   After importing the developers' keys into Monotone and
   setting up trust evaluation hooks,
   Monotone will prevent untrusted code from being checked out into your workspace.
   There are commands available to clean untrusted code from your workspace but in practice they've not been
   needed due to the push access policies in place.
+  {%- endtrans %}
 
        
 
 
        
+  {% trans -%}
   A repository can hold many branches. For example, our repository holds the
   following main branches:
+  {%- endtrans %}
   
          
-    
        • i2p.i2p — The I2P router and associated programs
          • 
-    
        • i2p.www — The I2P project website
          • 
-    
        • i2p.syndie — Syndie, a distributed forums tool
          • 
+    
        • i2p.i2p — {% trans %}The I2P router and associated programs{% endtrans %}
          • 
+    
        • i2p.www — {% trans %}The I2P project website{% endtrans %}
          • 
+    
        • i2p.syndie — {% trans %}Syndie, a distributed forums tool{% endtrans %}
          • 
   
        
 
        
 
 
        
-By convention, the I2P Monotone repository is named i2p.mtn. Before pulling
+  {% trans -%}
+  By convention, the I2P Monotone repository is named i2p.mtn. Before pulling
   source code from servers, a database for your repository will need to be initialized.
   To initialize your local repository, change into the directory that you want the
   i2p.mtn file and branch directories to be stored and issue the following
   command:
+  {%- endtrans %}
   
          
     
        • $ mtn --db="i2p.mtn" db init
          • 
   
        
 
        
 
 
-
        Obtaining and deploying developers' keys
        
+
        {% trans %}Obtaining and deploying developers' keys{% endtrans %}
        
 
 
        
+  {% trans -%}
   Keys which developers use to commit code are essential for trust evaluation in
   Monotone. The other developers' transport keys are only required for Monotone server operators.
+  {% endtrans %}
 
        
 
 
        
-Developers' commit keys are provided GPG-signed on another page.
+  {% trans signedkeys=site_url('get-involved/develop/signed-keys') -%}
+  Developers' commit keys are provided GPG-signed on another page.
+  {%- endtrans %}
 
        
 
 
        
-To import developers' keys after verifying their authenticity, copy all of the keys into a new
-file. Create this file (e.g. keys.txt) in the same directory where i2p.mtn is located. Import the keys with the command:
-  
          
-    
        • $ mtn --db="i2p.mtn" read < keys.txt
          • 
-  
        
+  {% trans devkeys=site_url('get-involved/develop/developers-keys') -%}
+  To import developers' keys after verifying their authenticity, copy all of the keys into a new
+  file. Create this file (e.g. keys.txt) in the same directory where i2p.mtn is located. Import the keys with the command:
+  {%- endtrans %}
+    
          
+      
        • $ mtn --db="i2p.mtn" read < keys.txt
          • 
+    
        
 
        
 
 
        
+  {% trans -%}
   Note: Never add keys to $HOME/.monotone/keys manually.
+  {%- endtrans %}
 
        
 
-
        Setting up trust evaluation hooks
        
+
        {% trans %}Setting up trust evaluation hooks{% endtrans %}
        
 
 
        
+  {% trans -%}
   The default Monotone trust policy is way too lax for our requirements: every comitter is trusted by default.
   That is not acceptable for I2P development.
+  {%- endtrans %}
 
        
 
 
        
-Change into the directory $HOME/.monotone and open the file
-monotonerc with a text editor. Copy and paste the following two functions into this file:
+  {% trans -%}
+  Change into the directory $HOME/.monotone and open the file
+  monotonerc with a text editor. Copy and paste the following two functions into this file:
+  {%- endtrans %}
 
        
 
-{% include "_monotonerc.html" %}
+{% include "include/monotonerc.html" %}
 
 
        
+  {% trans -%}
   The first function determines an intersection between two sets, in our case a
   revision's signers and trusted signers.
+  {%- endtrans %}
 
        
 
 
        
+  {% trans -%}
   The second function determines trust in a given revision, by calling the first
   function with "signers" and "trusted" as arguments. If the intersection is
   null, the revision is not trusted. If the intersection is not empty, the
   revision is trusted. Otherwise, the revision is not trusted.
+  {%- endtrans %}
 
        
 
 
        
-More information about Trust Evauluation Hooks can be found in the official Monotone documentation.
+  {% trans -%}
+  More information about Trust Evauluation Hooks can be found in the official Monotone documentation.
+  {%- endtrans %}
 
        
 
 
-
        Pulling the i2p.i2p, i2p.www and i2p.syndie branches
        
+
        {% trans %}Pulling the i2p.i2p, i2p.www and i2p.syndie branches{% endtrans %}
        
 
 
        
-Enter the directory where you initialized i2p.mtn. Depending on whether you
+  {% trans -%}
+  Enter the directory where you initialized i2p.mtn. Depending on whether you
   want only I2P sources, or also sources for the I2P website and Syndie, you can
   perform the pull operation in different ways.
+  {%- endtrans %}
 
        
 
 
        
+  {% trans -%}
   If you only want I2P sources:
+  {%- endtrans %}
   
          
     
        • $ mtn --db="i2p.mtn" -k "" pull 127.0.0.1:8998 i2p.i2p
          • 
   
        
 
        
 
 
        
+  {% trans -%}
   If you want all branches:
+  {%- endtrans %}
   
          
     
        • $ mtn --db="i2p.mtn" -k "" pull 127.0.0.1:8998 "i2p.*"
          • 
   
        
+  {% trans -%}
   If the transfer aborts before completing sucessfully, simply repeating the pull command will resume the transfer.
+  {%- endtrans %}
 
        
 
 
        
+  {% trans -%}
   Pulling in the above examples is done anonymously by specifying an empty transport key.
   If everyone pulls anonymously it will be harder for an attacker who gains control of the server
   to selectively provide some people with tampered data.
+  {%- endtrans %}
 
        
 
 
-
        Verifying that trust evaluation works
        
+
        {% trans %}Verifying that trust evaluation works{% endtrans %}
        
 
 
        
-To verify that trust evaluation works:
-
        • Make a backup of your monotonerc file.
          • 
-  
        • Modify monotonerc by setting the trusted_signers variable in the following way:
-
          -     local trusted_signers = {}
-
          
-
          • 
-  
        • With monotonerc configured as above, Monotone will no longer trust any committers. Confirm this by changing into the
-  directory where i2p.mtn was created and attempt a checkout of the I2P branch:
+  {% trans -%}
+  To verify that trust evaluation works:
+  {%- endtrans %}
   
            
-    
          • $ mtn --db="i2p.mtn" co --branch="i2p.i2p"
            • 
-  
          
+    
        • {% trans %}Make a backup of your monotonerc file.{% endtrans %}
          • 
+    
        • {% trans %}Modify monotonerc by setting the trusted_signers variable in the following way:{% endtrans %}
+  
          +       local trusted_signers = {}
+  
          
+    
          • 
+    
        • 
+  {% trans -%}
+With monotonerc configured as above, Monotone will no longer trust any committers. Confirm this by changing into the
+directory where i2p.mtn was created and attempt a checkout of the I2P branch:
+  {%- endtrans %}
+    
            
+      
          • $ mtn --db="i2p.mtn" co --branch="i2p.i2p"
            • 
+    
          
 
          
 
 
          
-A directory named i2p.i2p should not appear. You should encounter many
+  {% trans -%}
+  A directory named i2p.i2p should not appear. You should encounter many
   error messages like:
+  {%- endtrans %}
 
-
          +  
               mtn: warning: trust function disliked 1 signers
     of branch cert on revision 523c15f6f50cad3bb002f830111fc189732f693b
     mtn: warning: trust function disliked 1 signers
@@ -273,77 +342,97 @@ A directory named i2p.i2p should not appear. You should enco
     mtn: warning: trust function disliked 1 signers
     of branch cert on revision 8c4dd8ad4053baabb102a01cd3f91278142a2cd1
     mtn: misuse: branch 'i2p.i2p' is empty
-
          
+  
          
 
          
 
 
          
-If you are satisfied with results, restore the backup of
-monotonerc that was created above. If you didn't create a backup
-as advised, re-read Setting up trust evaluation hools.
+  {% trans -%}
+  If you are satisfied with results, restore the backup of
+  monotonerc that was created above. If you didn't create a backup
+  as advised, re-read Setting up trust evaluation hools.
+  {%- endtrans %}
 
          
 
 
-
          Checking out a working copy of the latest version
          
+
          {% trans %}Checking out a working copy of the latest version{% endtrans %}
          
 
 
          
+  {% trans -%}
   If you already have a branch checked out, skip to the next
   section.
+  {%- endtrans %}
 
          
 
 
          
-Change into the directory where i2p.mtn is located. Over there issue:
+  {% trans -%}
+  Change into the directory where i2p.mtn is located. Over there issue:
+  {%- endtrans %}
   
            
     
          • $ mtn --db="i2p.mtn" co --branch="i2p.i2p"
            • 
   
          
 
          
 
 
          
+  {% trans -%}
   The checkout should complete without error messages and a directory named
   i2p.i2p should appear in the current directory. Congratulations! You have
   successfully checked out the latest I2P sources, ready to be compiled.
+  {%- endtrans %}
 
          
 
 
-
          Updating your working copy to the latest version
          
+
          {% trans %}Updating your working copy to the latest version{% endtrans %}
          
 
 
          
+  {% trans -%}
   If you haven't done this already, pull fresh code from the server to your local
   Monotone repository. To accomplish this, change into the directory where
   i2p.mtn is located and issue:
   
            
     
          • $ mtn --db="i2p.mtn" -k "" pull 127.0.0.1:8998 i2p.i2p
            • 
   
          
+  {%- endtrans %}
 
          
 
 
          
-Now change into your i2p.i2p directory, and over there issue:
+  {% trans -%}
+  Now change into your i2p.i2p directory, and over there issue:
+  {%- endtrans %}
   
            
     
          • $ mtn update
            • 
   
          
 
          
 
 
          
+  {% trans -%}
   As long as there were no errors…Congratulations! You have successfully updated to the latest I2P sources. They
   should be ready to compile.
+  {%- endtrans %}
 
          
 
 
-
          Operating a Monotone Server
          
+
          {% trans %}Operating a Monotone Server{% endtrans %}
          
 
-
          Obtaining and deploying developers' transport keys
          
+
          {% trans %}Obtaining and deploying developers' transport keys{% endtrans %}
          
 
 
          
+  {% trans -%}
   As a server operator you may want to grant push access to certain developers.
+  {%- endtrans %}
 
          
 
-
          Granting push and pull access
          
+
          {% trans %}Granting push and pull access{% endtrans %}
          
 
 
          
+  {% trans -%}
   By default the Monotone server denies all access.
+  {%- endtrans %}
 
          
 
 
          
+  {% trans -%}
   To grant pull access to all clients, set the following in
+  {%- endtrans %}
   $HOME/.monotone/read-permissions:
 
 
          @@ -352,53 +441,73 @@ Now change into your i2p.i2p directory, and over there issue:
 
          
 
          
 
-
          No one will not be able to push code to your server without permission being explicitly granted. To grant push access:
-
          • Add the name of the user's transport key to
-  $HOME/.monotone/write-permissions, such as
-
+
            
+{% trans -%}
+No one will not be able to push code to your server without permission being explicitly granted. To grant push access:
+{%- endtrans %}
+
            
+
              
+  
            • 
+{% trans -%}
+Add the name of the user's transport key to
+$HOME/.monotone/write-permissions, such as
 
                   zzz-transport@mail.i2p
     complication-transport@mail.i2p
 
              
-  with one key per line.
+with one key per line.
+{%- endtrans %}
   
              • 
-
            • Import the transport key(s) into your database. The procedure for importing transport keys is the same as for
+  
            • 
+{% trans -%}
+Import the transport key(s) into your database. The procedure for importing transport keys is the same as for
 importing commit keys, which is described in the section Obtaining and deploying developers' keys.
-
            
-
            
+{%- endtrans %}
+  
            • 
+
          
 
-
          Running Monotone in server mode
          
+
          {% trans %}Running Monotone in server mode{% endtrans %}
          
 
 
          
+  {% trans -%}
   A separate database should be used for your Monotone server because monotone will lock the database while it is served to others.
   Make a copy of your development database, then start the server with:
+  {%- endtrans %}
   
            
     
          • $ mtn serve --bind="127.0.0.1:8998" --db="i2p.mtn" --key "myserver-transport@mail.i2p"
            • 
   
          
+  {% trans -%}
   If your key is protected with a passphrase, Monotone may request the passphrase
   when the first client connects. You can work around this by connecting making the first client connection to your server
   (or by clearing the password for your transport key).
+  {%- endtrans %}
 
          
 
 
          
-For your server to be accessible for others over I2P, you will need to create a
-server tunnel for it. Use the "Standard" tunnel type and "Bulk" profile.
+  {% trans -%}
+  For your server to be accessible for others over I2P, you will need to create a
+  server tunnel for it. Use the "Standard" tunnel type and "Bulk" profile.
+  {%- endtrans %}
 
          
 
 
-
          Differences under Debian GNU/Linux
          
+
          {% trans %}Differences under Debian GNU/Linux{% endtrans %}
          
 
 
          
+  {% trans -%}
   Debian (amongst other distributions) has integrated Monotone into their
   framework of daemons/services. Although Monotone servers can still be run
   "the ordinary way" on Debian systems, doing it the "Debian way" may be more straightforward.
+  {%- endtrans %}
 
          
 
 
          
-Permissions are granted by editing the files
-/etc/monotone/read-permissions and
-/etc/monotone/write-permissions. You'll also need to edit
-/etc/default/monotone to enable monotone to start at boot or to
-customize the host, port, or database location.
+  {% trans -%}
+  Permissions are granted by editing the files
+  /etc/monotone/read-permissions and
+  /etc/monotone/write-permissions. You'll also need to edit
+  /etc/default/monotone to enable monotone to start at boot or to
+  customize the host, port, or database location.
+  {%- endtrans %}
 
          
 {% endblock %}
diff --git a/i2p2www/pages/site/get-involved/guides/new-developers.html b/i2p2www/pages/site/get-involved/guides/new-developers.html
new file mode 100644
index 00000000..277b62f0
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/guides/new-developers.html
@@ -0,0 +1,190 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}New Developer's Guide{% endtrans %}{% endblock %}
+{% block content %}
+
          {% trans %}
+So you want to start work on I2P? Great!
+Here's a quick guide to getting started
+on contributing to the website or the software, doing development or creating translations.
+{%- endtrans %}
          
+
          {% trans volunteer=site_url('get-involved') %}
+Not quite ready for coding?
+Try getting involved first.
+{%- endtrans %}
          
+
+
+
+
          {% trans %}Basic study{% endtrans %}
          
+
+
          {% trans -%}
+Basic development on the I2P router or the embedded applications uses Java as the main development language.
+If you don't have experience with Java, you can always have a look at Thinking in Java.
+{%- endtrans %}
          
+
          {% trans intro=site_url('docs/how/intro'), docs=site_url('docs'), techintro=site_url('docs/how/tech-intro') -%}
+Study the how intro,
+the other "how" documents,
+the tech intro,
+and associated documents.
+These will give you a good overview of how I2P is structured and what different things it does.
+{%- endtrans %}
          
+
+
          {% trans %}Getting the I2P code{% endtrans %}
          
+
+
          {% trans -%}
+For development on the i2p router or the embedded applications,
+get the monotone source repository installed - short instructions:
+{%- endtrans %}
          
+
            
+  
          • {% trans -%}
+Install monotone.
+Monotone is a version control system.
+We use it because it allows us to keep track of who does what changes to the source code (and for a lot of complicated things, but 'keeping track of changes' is the basic idea).
+  {%- endtrans %}
            • 
+  
          • {% trans -%}
+Skim over the monotone tutorial, to make sure you understand the concepts.
+  {%- endtrans %}
            • 
+  
          • 
+    
            {% trans -%}
+      If you want to remain anonymous, you need to do an additional step, to set up a connection to a monotone server over I2P:
+    {%- endtrans %}
            
+    
            {% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
+      Enable the i2ptunnel client tunnel on port 8998 pointing to mtn.i2p2.i2p.
+    {%- endtrans %}
            
+  
            • 
+  
          • {% trans -%}
+  Pick a directory where you want to put all your I2P files, and create a monotone database:{% endtrans %} mtn -d i2p.mtn db init
+  
            • 
+  
          • {% trans -%}
+Define the trust list by creating ~/.monotone/monotonerc (or _MTN/monotonerc in the i2p.i2p workspace) with the following contents:
+{%- endtrans %}
+{% include "include/monotonerc.html" %}
+
            • 
+  
          • {% trans devkeys=site_url('get-involved/develop/developers-keys') -%}
+Copy and paste the developer's commit keys into a new file (e.g. keys.txt) in the same directory
+  that i2p.mtn is in. Import the keys into your database with 
                  mtn -d i2p.mtn read < keys.txt
            
+  {%- endtrans %}
            • 
+  
          • {% trans %}Pull the I2P sources to your machine. This may take a long time, especially if you are doing this over I2P!{% endtrans %}
+    
              
+      
            • {% trans %}Anonymously:{% endtrans %} mtn -d i2p.mtn pull 127.0.0.1:8998 i2p.i2p -k""
              • 
+      
            • 
+        
              
+           {% trans %}Non-anonymously:{% endtrans %} mtn -d i2p.mtn pull mtn.i2p2.de i2p.i2p -k"" 
+        
              
+        
              {% trans -%}
+          Alternatively, instead of 'mtn.i2p2.de', you can also download from mtn.i2p-projekt.de.
+        {%- endtrans %}
              
+    
            
+  
            • 
+  
          • 
+    
            
+    {% trans %}All the sources are now present on your machine, in the database file. To make them available in a directory, you need to check them out:{% endtrans %} mtn -d i2p.mtn co --branch=i2p.i2p
+    
            
+    
            {% trans %}The above command creates a directory i2p.i2p, which contains all of the I2P sources.{% endtrans %}
            
+  
            • 
+
          
+
+
          {% trans %}Remarks{% endtrans %}
          
+
          {% trans %}
+To download the website files instead of the I2P source files, use 'i2p.www' instead of 'i2p.i2p'.
+{%- endtrans %}
          
+
          {% trans -%}
+The initial pull may take several hours using the tunnel.
+If it fails after a partial pull, simply rerun it, it will start where it left off.
+If you are in a hurry, use the non-anonymous access.
+{%- endtrans %}
          
+
          {% trans viewmtn='http://'+i2pconv('stats.i2p')+'/cgi-bin/viewmtn/' -%}
+A full list of branches, including i2p.i2p and i2p.www can be found on viewmtn.
+{%- endtrans %}
          
+
          {% trans monotone=site_url('get-involved/guides/monotone') -%}
+A long explanation about using monotone is available on the monotone page.
+{%- endtrans %}
          
+
+
          {% trans %}Building I2P{% endtrans %}
          
+
+
          {% trans sunjdk6='http://www.oracle.com/technetwork/java/javase/downloads/index.html' -%}
+To compile the code, you need the Sun Java Development Kit 6 or higher, or equivalent JDK
+(Sun JDK 6 strongly recommended) and
+Apache ant
+version 1.7.0 or higher.
+If you go are working on the main I2P code, you can go into the i2p.i2p directory and run 'ant' to see the build options.
+{%- endtrans %}
          
+
+
          {% trans -%}
+To build or work on console translations, you need
+the xgettext, msgfmt, and msgmerge tools from the
+GNU gettext package.
+{%- endtrans %}
          
+
+
          {% trans apps=site_url('get-involved/develop/applications') -%}
+For development on new applications,
+see the application development guide.
+{%- endtrans %}
          
+
+
          {% trans %}Development ideas{% endtrans %}
          
+
          {% trans zzz=i2pconv('zzz.i2p'), todo=site_url('get-involved/todo'), trac=i2pconv('trac.i2p2.i2p') -%}
+See zzz's TODO lists,
+this website's TODO list or
+Trac
+for ideas.
+{%- endtrans %}
          
+
+
          {% trans %}Making the results available{% endtrans %}
          
+
+
          {% trans licenses=site_url('get-involved/develop/licenses') -%}
+See the bottom of the licenses page for
+commit privilege requirements. You need these to put code into i2p.i2p (not required for the website!).
+{%- endtrans %}
          
+
+
          {% trans %}Short version of how to generate and use keys if you plan to commit:{% endtrans %}
+  
            
+    
          • mtn genkey yourname-transport@mail.i2p ({% trans %}use an empty passphrase{% endtrans %})
+    
          • mtn genkey yourname@mail.i2p ({% trans %}enter a passphrase{% endtrans %})
+    
          • mtn pubkey yourname-transport@mail.i2p ({% trans email='mtn@welterde.de' %}send this to a mtn repo operator to get push privileges{% endtrans %})
+    
          • mtn pubkey yourname@mail.i2p ({% trans email='zzz@'+i2pconv('mail.i2p') %}send this to a release manager to get commit privileges - not required for website{% endtrans %})
+    
          • mtn ci -k yourname@mail.i2p ({% trans %}check in with this key{% endtrans %})
+    
          • mtn sync -k yourname-transport@mail.i2p ({% trans %}push with this key{% endtrans %})
+  
          
+{% trans monotone=site_url('get-involved/guides/monotone') -%}
+Long version: see the monotone page.
+{%- endtrans %}
+
          
+
+
          {% trans %}Get to know us!{% endtrans %}
          
+
          {% trans guidelines=site_url('get-involved/guides/dev-guidelines') -%}
+The developers hang around on IRC. They can be reached on the Freenode network, OFTC, and on the I2P internal networks. The usual place to look is #i2p-dev. Join the channel and say hi!
+We also have additional guidelines for regular developers.
+{%- endtrans %}
          
+
+
          {% trans %}Translations{% endtrans %}
          
+
          {% trans newtrans=site_url('get-involved/guides/new-translators') -%}
+Website and router console translators: See the New Translator's Guide
+for next steps.
+{%- endtrans %}
          
+
+
          {% trans %}Tools{% endtrans %}
          
+
          {% trans -%}
+I2P is open source software that is mostly developed using open sourced
+toolkits. The I2P project recently acquired a license for the YourKit Java
+Profiler. Open source projects are eligible to receive a free license provided
+that YourKit is referenced on the project web site. Please get in touch if you
+are interested in profiling the I2P codebase.
+{%- endtrans %}
          
+
+
          {% trans java='http://www.yourkit.com/java/profiler/index.jsp', dotnet='http://www.yourkit.com/.net/profiler/index.jsp' -%}
+YourKit is kindly supporting open source projects with its full-featured Java Profiler.
+YourKit, LLC is the creator of innovative and intelligent tools for profiling
+Java and .NET applications. Take a look at YourKit's leading software products:
+YourKit Java Profiler and
+YourKit .NET Profiler.
+{%- endtrans %}
          
+{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/guides/new-translators.html b/i2p2www/pages/site/get-involved/guides/new-translators.html
new file mode 100644
index 00000000..43849b96
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/guides/new-translators.html
@@ -0,0 +1,225 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}New Translator's Guide{% endtrans %}{% endblock %}
+{% block content %}
+{% trans %}Here's a very quick guide to getting started.{% endtrans %}
+
+
          {% trans %}How to Translate the Website{% endtrans %}
          
+
+
          {% trans transifex='https://www.transifex.com/projects/p/I2P/' -%}
+Translation of the website is done with .po files. The easiest way by far to
+translate the website is to sign up for an account at 
+Transifex and request to join a translation team. 
+Alternatively it can be done "the old way" as outlined below.
+{%- endtrans %}
          
+
+
            
+
          1. 
+{% trans %}Preparation{% endtrans %}
+  
              
+  
            1. {% trans url='http://'+i2pconv('ugha.i2p')+'/i2pTranslation' -%}
+Come to #i2p-dev on irc and talk to people.
+Claim the language -
+To make sure other coworkers don't bump onto the files you are working on,
+please update the translation status on this wiki page.
+{%- endtrans %}
              2. 
+  
            2. {% trans newdevs=site_url('get-involved/guides/new-developers') -%}
+Follow the new developer's guide,
+Including the installation of monotone,
+checking out i2p.www branch, and generate your own monotone keys.
+It is not required that you sign a dev agreement.
+{%- endtrans %}
              3. 
+  
            
+
+
          2. {% trans -%}
+Create files:
+If the file for your language does not exist yet:
+{%- endtrans %}
+  
              
+  
            1. {% trans -%}
+Run "./extract-messages.sh" to generate a messages.pot in the base directory.
+Edit the header of this file, then run "./init-new-po.sh locale" to generate the file
+i2p2www/translations/locale/LC_MESSAGES/messages.po. "mtn add" this file.
+{%- endtrans %}
              2. 
+  
            2. {% trans -%}
+Edit i2p2www/pages/global/lang.html and add a line for your language (copy an existing line).
+{%- endtrans %}
              3. 
+  
            3. {% trans -%}
+Add a flag image file to i2p2www/static/images/flags/ for the menu (copy from the router).
+{%- endtrans %}
              4. 
+  
            
+
            3. 
+
+
          3. {% trans -%}
+Edit files:
+Edit i2p2www/translations/locale/LC_MESSAGES/messages.po.
+To work with .po files efficiently, you may wish to use POEdit
+{%- endtrans %}
            4. 
+
+
          4. {% trans -%}
+Check in:
+"mtn pull", "mtn update". Then check in by "mtn ci -k yourname@mail.i2p file1 file2 ..."
+This collects the diff info of your changed file into your local repo. Then "mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p i2p.i2p".
+This synchronizes your local repo with the repo on the target machine.
+{%- endtrans %}
            5. 
+
+
          5. {% trans -%}
+Repeat. Check in often. Don't wait until it is perfect.
+{%- endtrans %}
            6. 
+
+
+
          
+
+
          {% trans %}How to Translate the Router Console{% endtrans %}
          
+
+
          {% trans transifex='https://www.transifex.com/projects/p/I2P/' -%}
+The easiest way by far to translate the router console is to sign up for an account at 
+Transifex and request to join a translation team. 
+Alternatively it can be done "the old way" as outlined below.
+{%- endtrans %}
          
+
+
            
+
          1. 
+{% trans %}Preparation{% endtrans %}
+  
              
+  
            1. {% trans url='http://'+i2pconv('ugha.i2p')+'/i2pTranslation' -%}
+Come to #i2p-dev on irc and talk to people.
+Claim the language -
+To make sure other coworkers don't bump onto the files you are working on,
+please update the translation status on this wiki page.
+{%- endtrans %}
              2. 
+  
            2. {% trans newdevs=site_url('get-involved/guides/new-developers') -%}
+Follow the new developer's guide,
+including the installation of monotone and the gettext tools,
+checking out i2p.i2p branch, and generate your own monotone keys.
+{%- endtrans %}
              3. 
+  
            3. {% trans -%}
+Generate your own gpg key and sign the dev agreement.
+{%- endtrans %}
              4. 
+  
            
+
            2. 
+
+
          2. {% trans -%}
+Before starting a console translation, better help translate some i2p webpages first.
+At least an i2p homepage in your language would be great.
+{%- endtrans %}
            3. 
+
+
          3. {% trans -%}
+What to translate:
+There are about 15 files in the i2p.i2p branch that needs translation:
+{%- endtrans %}
+
+  
              
+  
            • 
+    installer/resources/readme/readme_xx.html
              • 
+  
            • 
+    installer/resources/initialNews/initialNews_xx.xml
              • 
+  
            • 
+    apps/routerconsole/locale/messages_xx.po
              • 
+  
            • 
+    installer/resources/proxy/*_xx.ht (about 9 files)
              • 
+  
            • 
+    apps/routerconsole/jsp/help_xx.jsp
              • 
+  
            • 
+    installer/resources/eepsite.help/help/index_xx.html
              • 
+  
            • 
+    apps/i2ptunnel/locale/messages_xx.po
              • 
+  
            • 
+    apps/i2psnark/locale/messages_xx.po
              • 
+  
            • 
+    apps/susidns/locale/messages_xx.po
              • 
+  
            
+
+{% trans -%}
+Where xx is your language code like fr/de/ch/zh/...
+There may be or may not be files with your lang code. If not, you can create your own. by copying and renaming other language files you know with your own lang code.
+{%- endtrans %}
            4. 
+
+
          4. {% trans -%}
+Create files:
+If the file for your language does not exist yet, copy another language file to a new file foo_xx.bar for your language.
+Then "mtn add" the file.
+After creating a .po file, edit the headers. Then run "ant distclean poupdate".
+{%- endtrans %}
            5. 
+
+
          5. {% trans -%}
+Start to work:
+Edit the HTML files with any text editor.
+Be sure not to use an editor in HTML mode that reformats everything.
+To work with .po files efficiently, you may wish to use POEdit
+{%- endtrans %}
            6. 
+
+
          6. {% trans -%}
+Check in:
+"mtn pull", "mtn update". Then check in by "mtn ci -k yourname@mail.i2p file1 file2 ..."
+This collects the diff info of your changed file into your local repo. Then "mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p i2p.i2p".
+This synchronizes your local repo with the repo on the target machine.
+{%- endtrans %}
            7. 
+
+
          7. {% trans -%}
+Repeat. Check in often. Don't wait until it is perfect.
+{%- endtrans %}
            8. 
+
          
+
+
          {% trans -%}
+As you can see, it's not that difficult.
+If you have questions about the meaning of the terms in the console, ask in #i2p-dev on IRC.
+{%- endtrans %}
          
+
+
+
          {% trans %}FAQ{% endtrans %}
          
+
+
          {% trans -%}
+Q: Why do I have to install monotone, Java, jsp, learn about .po files and html, etc.? Why can't I just do a translation and email it to you?
+{%- endtrans %}
          
+
+
          {% trans %}A: Several reasons:{% endtrans %}
          
+
+
            
+
          • {% trans transifex='https://www.transifex.com/projects/p/I2P/' -%}
+You might be interested in translating via Transifex. Request to join a translation team here.
+{%- endtrans %}
            • 
+
+
          • {% trans -%}
+We don't have anybody who has time to accept manual contributions and submit them to our source control system on your behalf. Even if we did, it doesn't scale.
+{%- endtrans %}
            • 
+
+
          • {% trans -%}
+Maybe you are thinking translation is a one-step process. It isn't. You can't do it all at once. You will make mistakes. You need to test it and tweak it to make it look right before you submit it. Developers will update or add to the English text, thus requiring a translation update.
+{%- endtrans %}
            • 
+
+
          • {% trans -%}
+Having translators use a source control system directly provides authentication and accountablility - we know who is doing what, and we can track changes, and revert them if necessary.
+{%- endtrans %}
            • 
+
+
          • {% trans -%}
+.po files are not difficult. If you don't want to work directly with them, we recommend 'poedit'.
+{%- endtrans %}
            • 
+
+
          • {% trans -%}
+HTML files are not difficult. Just ignore the html stuff and translate the text.
+{%- endtrans %}
            • 
+
+
          • {% trans -%}
+Installing and using monotone is not that difficult. Several of the translators and other contributors to I2P are non-programmers, and they use monotone regularly. Monotone is simply a source control system, it is not about "coding".
+{%- endtrans %}
            • 
+
+
          • {% trans -%}
+Our items to translate are not "documents". They are html files and po files, with a specific format and character encoding (UTF-8) that must be maintained, and not corrupted by email programs or other methods of transfer.
+{%- endtrans %}
            • 
+
+
          • {% trans -%}
+We looked at 'pootle' as a front-end for translators. It didn't work well, needed an administrator, and a pootle-based process would suffer from a number of the above flaws.
+{%- endtrans %}
            • 
+
          
+
+
          {% trans -%}
+In summary:
+Yes, we know it is somewhat of a hurdle to get started. It's really the only possible way we can do it. Give it a try, it really isn't that hard.
+{%- endtrans %}
+
+
          {% trans %}More Information{% endtrans %}
          
+
          {% trans zzz=i2pconv('zzz.i2p') -%}
+The #i2p-dev channel on IRC, or the translation forum on {{ zzz }}.
+{%- endtrans %}
          
+
+{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/index.html b/i2p2www/pages/site/get-involved/index.html
new file mode 100644
index 00000000..e73b584e
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/index.html
@@ -0,0 +1,77 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Get Involved!{% endtrans %}{% endblock %}
+{% block content %}
+
          {% trans %}We need your help!{% endtrans %}
          
+
          {% trans -%}
+To get involved, please feel free to join us on the #i2p IRC channel (on
+irc.freenode.net, or within I2P on irc.freshcoffee.i2p or irc.postman.i2p).
+{%- endtrans %}
          
+
          {% trans team=site_url('about/team') -%}
+If you're interested in joining our team, please get in
+touch as we're always looking for eager contributors!
+{%- endtrans %}
              
+
          {% trans -%}
+We need help in many areas, and you don't need to know Java to contribute!
+Here's a list to help you get started!
+{%- endtrans %}
          
+
            
+
          • {% trans %}Spread the Word!{% endtrans %} —
+{% trans -%}
+Tell people about I2P on forums, blogs, and comments to articles.
+Fix up the Wikipedia article about I2P in your language.
+Tell your friends.
+{%- endtrans %}
+
          • {{ _('Testing') }} —
+{% trans monotone=site_url('get-involved/guides/monotone'), trac=i2pconv('trac.i2p2.i2p') -%}
+Run the latest builds from monotone
+and report results on #i2p or as bugs on Trac.
+{%- endtrans %}
+
          • {{ _('Documentation') }} —
+{% trans -%}
+Help fix the parts of the website that are outdated or incomplete.
+Translate pages into other languages.
+{%- endtrans %}
+
          • {{ _('Pictures') }} —
+{% trans -%}
+Make some more pictures, fix the old ones on the website
+{%- endtrans %}
+
          • {{ _('Content') }} —
+{% trans -%}
+Make an eepsite! Add some content! Contribute to the community!
+{%- endtrans %}
+
          • {{ _('Services') }} —
+{% trans -%}
+Run a service on an eepsite. It could be a proxy, a forum, a tracker,
+a naming service, a search engine, an eepsite monitor... many of these
+aren't that hard.
+{%- endtrans %}
+
          • {{ _('Applications') }} —
+{% trans apps=site_url('get-involved/develop/applications') -%}
+Write or port applications for I2P! There's some guidelines and
+a list of ideas on the applications page.
+{%- endtrans %}
+
          • {{ _('Coding') }} —
+{% trans trac=i2pconv('trac.i2p2.i2p'), zzz=i2pconv('zzz.i2p'), newdevs=site_url('get-involved/guides/new-developers') -%}
+There's plenty to do if you know Java or are ready to learn.
+Check for open tickets on Trac
+or the TODO list on {{ zzz }} for
+some ideas on where to start.
+See the new developer's guide for details.
+{%- endtrans %}
+
          • {{ _('Translation') }} —
+{% trans newtrans=site_url('get-involved/guides/new-translators') -%}
+Help translate the website and the software into your language.
+See the new translator's guide for details.
+{%- endtrans %}
+
          • {{ _('Analysis') }} —
+{% trans threatmodel=site_url('docs/how/threat-model') -%}
+Study or test the code to look for vulnerabilities.
+Both anonymity vulnerabilities from the various
+threat models,
+and DOS and other weaknesses due to securities holes,
+need researching.
+{%- endtrans %}
+
          • {{ _('Donate') }}
+
+
          
+{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/roadmap.html b/i2p2www/pages/site/get-involved/roadmap.html
new file mode 100644
index 00000000..55b4b758
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/roadmap.html
@@ -0,0 +1,42 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Roadmap') }}{% endblock %}
+{% block content %}
+
+
          0.9
          
+
            
+
          • {% trans -%}
+Include some seed data in the distribution so a central reseed location isn't required?
+{%- endtrans %}
            • 
+
          • {% trans todo=site_url('get-involved/todo') -%}
+Reachability Mapping / handle peers partially reachable / enhanced restricted routes
+{%- endtrans %}
            • 
+
          • {% trans %}Improve help pages and website{% endtrans %}
            • 
+
          • {% trans %}More translations{% endtrans %}
            • 
+
          • {% trans %}SSU disconnect message{% endtrans %}
            • 
+
          • {% trans %}Iterative floodfill lookups{% endtrans %}
            • 
+
          
+
+
          1.0
          
+
            
+
          • {% trans %}Full review of anonymity issues and other vulnerabilities{% endtrans %}
            • 
+
          • {% trans -%}
+Reduce memory usage, remove debugging overhead, make it run better on slow and embedded machines
+{%- endtrans %}
            • 
+
          • {{ _('Docs') }}
            • 
+
          
+
+
          2.0
          
+
            
+
          • {% trans %}Full restricted routes{% endtrans %}
            • 
+
          
+
+
          3.0
          
+
            
+
          • {% trans %}Tunnel mixing and padding{% endtrans %}
            • 
+
          • {% trans %}User defined message delays{% endtrans %}
            • 
+
          
+
+
          {% trans todo=site_url('get-involved/todo') -%}
+Please see the TODO list for more detailed info about some of these tasks.
+{%- endtrans %}
          
+{% endblock %}
diff --git a/i2p2www/pages/site/get-involved/todo.html b/i2p2www/pages/site/get-involved/todo.html
new file mode 100644
index 00000000..166d8e11
--- /dev/null
+++ b/i2p2www/pages/site/get-involved/todo.html
@@ -0,0 +1,461 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('To Do List') }}{% endblock %}
+{% block content %}
+
          {{ _('I2P Project Targets') }}
          
+
          {% trans roadmap=site_url('get-involved/roadmap'), volunteer=site_url('get-involved') -%}
+Below is a more detailed (yet still incomplete) discussion of the major areas
+of future development on the core I2P network, spanning the plausibly planned
+releases. This does not include stego transports, porting to wireless devices,
+or tools to secure the local machine, nor does it include client applications
+that will be essential in I2P's success. There are probably other things that
+will come up, especially as I2P gets more peer review, but these are the main
+'big things'. See also the roadmap. Want to help?
+Get involved!
+{%- endtrans %}
          
+
+
          {{ _('Core functionality') }} [{{ _('link') }}]
          
+  
+
          {{ _('Security / anonymity') }} [{{ _('link') }}]
          
+  
+
          {{ _('Performance') }} [{{ _('link') }}]
          
+
+  
          {{ _('Core functionality') }}
          
+  
            
+    
          •  
+      
            {% trans -%}
+NAT/Firewall bridging via 1-hop restricted routes
+{%- endtrans %}
            
+    
            • 
+    
+    {{ _('Implemented in I2P 0.6.0.6') }}
+
            {% trans -%}
+The functionality of allowing routers to fully participate within the network 
+while behind firewalls and NATs that they do not control requires some basic 
+restricted route operation (since those peers will not be able to receive 
+inbound connections). To do this successfully, you consider peers one of 
+two ways:
+{%- endtrans %}
            
+      
+  
          
+  
            
+    
          • {% trans -%}
+Peers who have reachable interfaces - these peers do not need to 
+do anything special
+{%- endtrans %}
            • 
+    
          • {% trans -%}
+Peers who do not have reachable interfaces - these peers must build 
+a tunnel pointing at them where the gateway is one of the peers they have 
+established a connection with who has both a publicly reachable interface 
+and who has agreed to serve as their 'introducer'.
+{%- endtrans %}
            • 
+  
          
+  
          
+
          {% trans -%}
+To do this, peers who have no IP address simply connect to a few peers, 
+build a tunnel through them, and publish a reference to those tunnels within 
+their RouterInfo structure in the network database.
+{%- endtrans %}
          
+
          {% trans -%}
+When someone wants to contact any particular router, they first must get 
+its RouterInfo from the network database, which will tell them whether they 
+can connect directly (e.g. the peer has a publicly reachable interface) 
+or whether they need to contact them indirectly. Direct connections occur 
+as normal, while indirect connections are done through one of the published 
+tunnels.
+{%- endtrans %}
          
+
          {% trans -%}
+When a router just wants to get a message or two to a specific hidden peer, 
+they can just use the indirect tunnel for sending the payload. However, 
+if the router wants to talk to the hidden peer often (for instance, as part 
+of a tunnel), they will send a garlic routed message through the indirect 
+tunnel to that hidden peer which unwraps to contain a message which should 
+be sent to the originating router. That hidden peer then establishes an 
+outbound connection to the originating router and from then on, those two 
+routers can talk to each other directly over that newly established direct 
+connection.
+{%- endtrans %}
          
+
          {% trans -%}
+Of course, that only works if the originating peer can receive connections 
+(they aren't also hidden). However, if the originating peer is hidden, they 
+can simply direct the garlic routed message to come back to the originating 
+peer's inbound tunnel.
+{%- endtrans %}
          
+
          {% trans -%}
+This is not meant to provide a way for a peer's IP address to be concealed, 
+merely as a way to let people behind firewalls and NATs fully operate within 
+the network. Concealing the peer's IP address adds a little more work, as 
+described below.
+{%- endtrans %}
          
+
          {% trans -%}
+With this technique, any router can participate as any part of a tunnel. 
+For efficiency purposes, a hidden peer would be a bad choice for an inbound 
+gateway, and within any given tunnel, two neighboring peers wouldn't want 
+to be hidden. But that is not technically necessary.
+{%- endtrans %}
          
+  
          
+  
            
+    
          •  
+      
            {% trans -%}
+High degree transport layer with UDP, NBIO, or NIO
+{%- endtrans %}
            
+      {{ _('Both UDP and NIO have been Implemented in I2P') }} 
+
            {% trans -%}
+Standard TCP communication in Java generally requires blocking socket 
+calls, and to keep a blocked socket from hanging the entire system, those 
+blocking calls are done on their own threads. Our current TCP transport 
+is implemented in a naive fashion - for each peer we are talking to, we 
+have one thread reading and one thread writing. The reader thread simply 
+loops a bunch of read() calls, building I2NP messages and adding them 
+to our internal inbound message queue, and the writer thread pulls messages 
+off a per-connection outbound message queue and shoves the data through 
+write() calls.
+{%- endtrans %}
            
+
            {% trans -%}
+We do this fairly efficiently, from a CPU perspective - at any time, 
+almost all of these threads are sitting idle, blocked waiting for something 
+to do. However, each thread consumes real resources (on older Linux kernels, 
+for instance, each thread would often be implemented as a fork()'ed process). 
+As the network grows, the number of peers each router will want to talk 
+with will increase (remember, I2P is fully connected, meaning that any 
+given peer should know how to get a message to any other peer, and restricted 
+route support will probably not significantly reduce the number of connections 
+necessary). This means that with a 100,000 router network, each router 
+will have up to 199,998 threads just to deal with the TCP connections!
+{%- endtrans %}
            
+
            {% trans -%}
+Obviously, that just won't work. We need to use a transport layer that 
+can scale. In Java, we have two main camps:
+{%- endtrans %}
            
+      
            UDP
            
+      {% trans ssu=site_url('docs/transport/ssu') -%}
+Implemented in I2P 0.6 ("SSU") as documented elsewhere
+{%- endtrans %} 
+
            {% trans -%}
+Sending and receiving UDP datagrams is a connectionless operation - if 
+we are communicating with 100,000 peers, we simply stick the UDP packets 
+in a queue and have a single thread pulling them off the queue and shoving 
+them out the pipe (and to receive, have a single thread pulling in any 
+UDP packets received and adding them to an inbound queue).
+{%- endtrans %}
            
+
            {% trans -%}
+However, moving to UDP means losing the benefits of TCP's ordering, congestion 
+control, MTU discovery, etc. Implementing that code will take significant 
+work, however I2P doesn't need it to be as strong as TCP. Specifically, 
+a while ago I was taking some measurements in the simulator and on the 
+live net, and the vast majority of messages transferred would fit easily 
+within a single unfragmented UDP packet, and the largest of the messages 
+would fit within 20-30 packets. As mule pointed out, TCP adds a significant 
+overhead when dealing with so many small packets, as the ACKs are within 
+an order of magnitude in size. With UDP, we can optimize the transport 
+for both efficiency and resilience by taking into account I2P's particular 
+needs.
+{%- endtrans %}
            
+
            {% trans -%}
+It will be a lot of work though.
+{%- endtrans %}
            
+      
            {{ _('NIO or NBIO') }}
            
+      {% trans -%}
+NIO Implemented in I2P 0.6.1.22 ("NTCP")
+{%- endtrans %} 
+
            {% trans -%}
+In Java 1.4, a set of "New I/O" packages was introduced, allowing Java 
+developers to take advantage of the operating system's nonblocking IO 
+capabilities - allowing you to maintain a large number of concurrent IO 
+operations without requiring a separate thread for each. There is much 
+promise with this approach, as we can scalable handle a large number of 
+concurrent connections and we don't have to write a mini-TCP stack with 
+UDP. However, the NIO packages have not proven themselves to be battle-ready, 
+as the Freenet developer's found. In addition, requiring NIO support would 
+mean we can't run on any of the open source JVMs like Kaffe, 
+as GNU/Classpath has only limited 
+support for NIO. (note: this may not be the case anymore, as there 
+has been some progress on Classpath's NIO, but it is an unknown quantity)
+{%- endtrans %}
            
+
            {% trans link='http://www.eecs.harvard.edu/~mdw/proj/java-nbio/' -%}
+Another alternative along the same lines is the Non 
+Blocking I/O package - essentially a cleanroom NIO implementation 
+(written before NIO was around). It works by using some native OS code 
+to do the nonblocking IO, passing off events through Java. It seems to 
+be working with Kaffe, though there doesn't seem to be much development 
+activity on it lately (likely due to 1.4's NIO deployment).
+{%- endtrans %}
            
+    
            • 
+  
          
+  
            
+    
          •  
+      
            {% trans -%}
+NetworkDB and profile tuning and ejection policy for large nets
+{%- endtrans %}
            
+
            {% trans -%}
+Within the current network database and profile management implementation, 
+we have taken the liberty of some practical shortcuts. For instance, we 
+don't have the code to drop peer references from the K-buckets, as we 
+don't have enough peers to even plausibly fill any of them, so instead, 
+we just keep the peers in whatever bucket is appropriate. Another example 
+deals with the peer profiles - the memory required to maintain each peer's 
+profile is small enough that we can keep thousands of full blown profiles 
+in memory without problems. While we have the capacity to use trimmed 
+down profiles (which we can maintain 100s of thousands in memory), we 
+don't have any code to deal with moving a profile from a "minimal profile" 
+to a "full profile", a "full profile" to a "minimal profile", or to simply 
+eject a profile altogether. It just wouldn't be practical to write that 
+code yet, since we aren't going to need it for a while.
+{%- endtrans %}
            
+
            {% trans -%}
+That said, as the network grows we are going to want to keep these considerations 
+in mind. We will have some work to do, but we can put it off for later.
+{%- endtrans %}
            
+    
            • 
+  
          
+  
          {{ _('Security / anonymity') }}
          
+  
            
+    
          •  
+      
            {% trans -%}
+Per-hop tunnel id & new permuted TunnelVerificationStructure encryption
+{%- endtrans %}
            
+      {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
+Addressed in I2P 0.5 as documented elsewhere
+{%- endtrans %} 
+
            {% trans -%}
+Right now, if Alice builds a four hop inbound tunnel starting at Elvis, 
+going to Dave, then to Charlie, then Bob, and finally Alice (A<--B<--C<--D<--E), 
+all five of them will know they are participating in tunnel "123", as 
+the messages are tagged as such. What we want to do is give each hop their 
+own unique tunnel hop ID - Charlie will receive messages on tunnel 234 
+and forward them to tunnel 876 on Bob. The intent is to prevent Bob or 
+Charlie from knowing that they are in Alice's tunnel, as if each hop in 
+the tunnel had the same tunnel ID, collusion attacks aren't much work. 
+{%- endtrans %}
            
+
            {% trans -%}
+Adding a unique tunnel ID per hop isn't hard, but by itself, insufficient. 
+If Dave and Bob are under the control of the same attacker, they wouldn't 
+be able to tell they are in the same tunnel due to the tunnel ID, but 
+would be able to tell by the message bodies and verification structures 
+by simply comparing them. To prevent that, the tunnel must use layered 
+encryption along the path, both on the payload of the tunneled message 
+and on the verification structure (used to prevent simple tagging attacks). 
+This requires some simple modifications to the TunnelMessage, as well 
+as the inclusion of per-hop secret keys delivered during tunnel creation 
+and given to the tunnel's gateway. We must fix a maximum tunnel length 
+(e.g. 16 hops) and instruct the gateway to encrypt the message to each 
+of the 16 delivered secret keys, in reverse order, and to encrypt the 
+signature of the hash of the (encrypted) payload at each step. The gateway 
+then sends that 16-step encrypted message, along with a 16-step and 16-wide 
+encrypted mapping to the first hop, which then decrypts the mapping and 
+the payload with their secret key, looking in the 16-wide mapping for 
+the entry associated with their own hop (keyed by the per-hop tunnel ID) 
+and verifying the payload by checking it against the associated signed 
+hash.
+{%- endtrans %}
            
+
            {% trans -%}
+The tunnel gateway does still have more information than the other peers 
+in the tunnel, and compromising both the gateway and a tunnel participant 
+would allow those peers to collude, exposing the fact that they are both 
+in the same tunnel. In addition, neighboring peers know that they are 
+in the same tunnel anyway, as they know who they send the message to (and 
+with IP-based transports without restricted routes, they know who they 
+got it from). However, the above two techniques significantly increase 
+the cost of gaining meaningful samples when dealing with longer tunnels.
+{%- endtrans %}
            
+    
          
+    
            
+      
          •  
+        
            {% trans -%}
+Strict ordering of participants within tunnels
+{%- endtrans %}
            
+        {{ _('Implemented in release 0.6.2') }}
            • 
+    
          
+    
          
+
          {% trans link='http://article.gmane.org/gmane.network.i2p/22/',
+pdf1='http://forensics.umass.edu/pubs/wright-tissec.pdf',
+pdf2='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf' -%}
+As Connelly proposed to deal with the
+predecessor attack (2008
+update), keeping the order of peers within our tunnels consistent 
+(aka whenever Alice creates a tunnel with both Bob and Charlie in it, 
+Bob's next hop is always Charlie), we address the issue as Bob doesn't 
+get to substantially sample Alice's peer selection group. We may even 
+want to explicitly allow Bob to participate in Alice's tunnels in only 
+one way - receiving a message from Dave and sending it to Charlie - and 
+if any of those peers are not available to participate in the tunnel (due 
+to overload, network disconnection, etc), avoid asking Bob to participate 
+in any tunnels until they are back online.
+{%- endtrans %}
          
+
          {% trans -%}
+More analysis is necessary for revising the tunnel creation - at the 
+moment, we simply select and order randomly within the peer's top tier 
+of peers (ones with fast + high capacity).
+{%- endtrans %}
          
+
          {% trans -%}
+Adding a strict ordering to peers in a tunnel also improves the anonymity 
+of peers with 0-hop tunnels, as otherwise the fact that a peer's gateway 
+is always the same would be particularly damning. However, peers with 
+0-hop tunnels may want to periodically use a 1-hop tunnel to simulate 
+the failure of a normally reliable gateway peer (so every MTBF*(tunnel 
+duration) minutes, use a 1-hop tunnel).
+{%- endtrans %}
          
+    
          
+    
          •  
+      
            Randomly permuted tunnel lengths
            
+      {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
+Addressed in I2P 0.5 as documented elsewhere
+{%- endtrans %}
            • 
+  
          
+  
            
+    
+
            {% trans -%}
+Without tunnel length permutation, if someone were to somehow detect that 
+a destination had a particular number of hops, it might be able to use that 
+information to identify the router the destination is located on, per the 
+predecessor attack. For instance, if everyone has 2-hop tunnels, if Bob 
+receives a tunnel message from Charlie and forwards it to Alice, Bob knows 
+Alice is the final router in the tunnel. If Bob were to identify what destination 
+that tunnel served (by means of colluding with the gateway and harvesting 
+the network database for all of the LeaseSets), he would know the router 
+on which that destination is located (and without restricted routes, that 
+would mean what IP address the destination is on).
+{%- endtrans %}
            
+
            {% trans -%}
+It is to counter user behavior that tunnel lengths should be permuted, 
+using algorithms based on the length requested (for example, the 1/MTBF 
+length change for 0-hop tunnels outlined above).
+{%- endtrans %}
            
+      
+    
          •  
+      
            {% trans -%}
+Full blown n-hop restricted routes with optional trusted links
+{%- endtrans %}
            
+
            {% trans -%}
+The restricted route functionality described before was simply a functional 
+issue - how to let peers who would not otherwise be able to communicate 
+do so. However, the concept of allowing restricted routes includes additional 
+capabilities. For instance, if a router absolutely cannot risk communicating 
+directly with any untrusted peers, they can set up trusted links through 
+those peers, using them to both send and receive all of its messages. 
+Those hidden peers who want to be completely isolated would also refuse 
+to connect to peers who attempt to get them to (as demonstrated by the 
+garlic routing technique outlined before) - they can simply take the garlic 
+clove that has a request for delivery to a particular peer and tunnel 
+route that message out one of the hidden peer's trusted links with instructions 
+to forward it as requested.
+{%- endtrans %}
            
+    
            • 
+    
          •  
+      
            {% trans -%}
+Hashcash for routerIdentity, destination, and tunnel request
+{%- endtrans %}
            
+
            {% trans link='http://citeseer.ist.psu.edu/douceur02sybil.html' -%}
+Within the network, we will want some way to deter people from consuming 
+too many resources or from creating so many peers to mount a Sybil 
+attack. Traditional techniques such as having a peer see who is requesting 
+a resource or running a peer aren't appropriate for use within I2P, as 
+doing so would compromise the anonymity of the system. Instead, we want 
+to make certain requests "expensive".
+{%- endtrans %}
            
+
            {% trans -%}
+Hashcash is one technique that 
+we can use to anonymously increase the "cost" of doing certain activities, 
+such as creating a new router identity (done only once on installation), 
+creating a new destination (done only once when creating a service), or 
+requesting that a peer participate in a tunnel (done often, perhaps 2-300 
+times per hour). We don't know the "correct" cost of each type of certificate 
+yet, but with some research and experimentation, we could set a base level 
+that is sufficiently expensive while not an excessive burden for people 
+with few resources.
+{%- endtrans %}
            
+
            {% trans -%}
+There are a few other algorithms that we can explore for making those 
+requests for resources "nonfree", and further research on that front is 
+appropriate.
+{%- endtrans %}
            
+    
            • 
+    
          •  
+      
            {% trans -%}
+Advanced tunnel operation (batching/mixing/throttling/padding)
+{%- endtrans %}
            
+
            {% trans pdf='http://freehaven.net/doc/sync-batching/sync-batching.pdf' -%}
+To powerful passive external observers as well as large colluding internal 
+observers, standard tunnel routing is vulnerable to traffic analysis attacks 
+- simply watching the size and frequency of messages being passed between 
+routers. To defend against these, we will want to essentially turn some 
+of the tunnels into its own mix cascade - delaying messages received at 
+the gateway and passing them in batches, reordering them as necessary, 
+and injecting dummy messages (indistinguishable from other "real" tunnel 
+messages by peers in the path). There has been a significant amount of 
+research 
+on these algorithms that we can lean on prior to implementing the various 
+tunnel mixing strategies.
+{%- endtrans %}
            
+
            {% trans -%}
+In addition to the anonymity aspects of more varied tunnel operation, 
+there is a functional dimension as well. Each peer only has a certain 
+amount of data they can route for the network, and to keep any particular 
+tunnel from consuming an unreasonable portion of that bandwidth, they 
+will want to include some throttles on the tunnel. For instance, a tunnel 
+may be configured to throttle itself after passing 600 messages (1 per 
+second), 2.4MB (4KBps), or exceeding some moving average (8KBps for the 
+last minute). Excess messages may be delayed or summarily dropped. With 
+this sort of throttling, peers can provide ATM-like QoS support for their 
+tunnels, refusing to agree to allocate more bandwidth than the peer has 
+available.
+{%- endtrans %}
            
+
            {% trans -%}
+In addition, we may want to implement code to dynamically reroute tunnels 
+to avoid failed peers or to inject additional hops into the path. This 
+can be done by garlic routing a message to any particular peer in a tunnel 
+with instructions to redefine the next-hop in the tunnel.
+{%- endtrans %}
            
+    
            • 
+    
          •  
+      
            {% trans -%}
+Stop & go mix w/ garlics & tunnels
+{%- endtrans %}
            
+
            {% trans -%}
+Beyond the per-tunnel batching and mixing strategy, there are further 
+capabilities for protecting against powerful attackers, such as allowing 
+each step in a garlic routed path to define a delay or window in which 
+it should be forwarded on. This would enable protections against the long 
+term intersection attack, as a peer could send a message that looks perfectly 
+standard to most peers that pass it along, except at any peers where the 
+clove exposed includes delay instructions.
+{%- endtrans %}
            
+    
            • 
+  
          
+  
          {{ _('Performance') }}
          
+
          {% trans futureperf=site_url('about/performance/future') -%}
+Performance related improvements are listed on the
+Performance page.
+{%- endtrans %}
          
+{% endblock %}
diff --git a/www.i2p2/pages/impressum.html b/i2p2www/pages/site/impressum.html
similarity index 61%
rename from www.i2p2/pages/impressum.html
rename to i2p2www/pages/site/impressum.html
index cdfdcc28..325a9d11 100644
--- a/www.i2p2/pages/impressum.html
+++ b/i2p2www/pages/site/impressum.html
@@ -1,8 +1,8 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Impressum{% endblock %}
 {% block content %}
-  
          [German laws...]
          
+  
          [{{ _('German laws') }}]...
          
   
          Tassilo Schweyer
          
     Weitfelderweg 8b
          
     89275 Elchingen
          
-{% endblock %}
\ No newline at end of file
+{% endblock %}
diff --git a/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html
new file mode 100644
index 00000000..a8e7237b
--- /dev/null
+++ b/i2p2www/pages/site/index.html
@@ -0,0 +1,80 @@
+{% extends "global/layout.html" %}
+{% block title_outer %}{{ _('I2P Anonymous Network') }}{% endblock %}
+{% block title %}{{ _('The Invisible Internet Project') }}{% endblock %}
+{% block metadesc %}{{ _('Anonymous peer-to-peer distributed communication layer built with open source tools and designed to run any traditional Internet service such as email, IRC or web hosting.') }}{% endblock %}
+{% block content_outer %}
+
          
+  
          {{ _('What does I2P do for you?') }}
          
+  
          {% trans %}The I2P network provides strong privacy protections for communication over the Internet. Many activities that would risk your privacy on the public Internet can be conducted anonymously inside I2P.{% endtrans %}
          
+  {% trans version=ver() %}Get I2P {{ version }}{% endtrans %}
+
          
+
          
+  
          
+    
          {{ _('What is I2P?') }}
          
+    
            
+      
          • {% trans -%}
+I2P is a full darknet implementation - a network within a network, and is intended to protect against monitoring by third parties, such as hostile governments or ISPs.
+{% endtrans %}
            • 
+      
          • {% trans -%}
+I2P is used by many people who care about their privacy, as well as those in high-risk situations. It is designed to protect activists, oppressed people, journalists and whistle-blowers - as well as the average person.
+{% endtrans %}
            • 
+      
          • {% trans -%}
+I2P runs on Java and is therefore available anywhere Java will run, including desktops, embedded systems (like the Raspberry Pi)  and Android phones.
+{% endtrans %}
            • 
+      
          • 
+        {% trans %}Read more…{% endtrans %}
+      
            • 
+    
          
+  
          
+  
          
+    
          {{ _('What can you do with I2P?') }}
          
+    
            
+      
          • 
+      {% trans supported=site_url('docs/applications/supported') -%}
+      Email Integrated web mail interface, plugin for serverless email.
+      {%- endtrans %}
+      
            • 
+      
          • 
+      {% trans supported=site_url('docs/applications/supported') -%}
+      Web browsing Anonymous websites, gateways to and from the public Internet.
+      {%- endtrans %}
+      
            • 
+      
          • 
+      {% trans supported=site_url('docs/applications/supported') -%}
+      Blogging and forums Blogging and Syndie plugins.
+      {%- endtrans %}
+      
            • 
+      
          • 
+      {% trans supported=site_url('docs/applications/supported') -%}
+      Website hosting Integrated anonymous web server.
+      {%- endtrans %}
+      
            • 
+      
          • 
+      {% trans supported=site_url('docs/applications/supported') -%}
+      Real-time chat Instant messaging and IRC clients.
+      {%- endtrans %}
+      
            • 
+      
          • 
+      {% trans supported=site_url('docs/applications/supported') -%}
+      File sharing ED2K and Gnutella clients, integrated BitTorrent client.
+      {%- endtrans %}
+      
            • 
+      
          • 
+      {% trans supported=site_url('docs/applications/supported') -%}
+      Decentralized file storage Tahoe-LAFS distributed filesystem plugin.
+      {%- endtrans %}
+      
            • 
+      
          • 
+      {% trans supported=site_url('docs/applications/supported') -%}
+      More supported applications…
+      {%- endtrans %}
+      
            • 
+    
          
+  
          
+  
          
+    {{ _('I2P Blog ATOM Feed') }}
+    
          {% trans %}News & Updates{% endtrans %}
          
+      {% include "blog/latest.html" %}
+  
          
+
          
+{% endblock %}
diff --git a/www.i2p2/pages/links.html b/i2p2www/pages/site/links.html
similarity index 78%
rename from www.i2p2/pages/links.html
rename to i2p2www/pages/site/links.html
index 242320c5..eb137ba3 100644
--- a/www.i2p2/pages/links.html
+++ b/i2p2www/pages/site/links.html
@@ -1,17 +1,17 @@
-{% extends "_layout.html" %}
-{% block title %}Links{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Links') }}{% endblock %}
 {% block content %}
-
          Recommended Links & Resources
          
-
          
+
          {{ _('Recommended Links & Resources') }}
          
+
          {% trans media=site_url('about/media') -%}
 See also the page with
-links to papers, presentations, videos, and tutorials about I2P.
-
          
+links to presentations, videos, and tutorials about I2P.
+{%- endtrans %}
          
 
 
          
 
            
-
            Friends of I2P
            
+
            {{ _('Friends of I2P') }}
            
 
          • Anomos Pseudonymous Encrypted Bittorrent
            • 
-
          • EFF
            • 
+
          • EFF
            • 
 
          • GNUnet
            • 
 
          • Ipredator
            • 
 
          • InfoSec Daily Podcast
            • 
@@ -21,25 +21,25 @@ See also the page with
 
          • The Pegasus Press
            • 
 
          • Telecomix
            • 
 
          • Tor
            • 
-
            More Projects and Documentation
            
+
            {{ _('More Projects and Documentation') }}
            
 
          • Freehaven's Anonymity Bibliography
            • 
-
          • GNUNet's related projects
            • 
-
          • Morphmix
            • 
+
          • GNUNet's related projects
            • 
+
          • Morphmix
            • 
 
          • Tarzan
            • 
 
          • Onion Routing
            • 
 
          • Mixmaster
            • 
 
          • Mixminion
            • 
 
          • Freenet
            • 
 
          • JAP
            • 
-
            Press
            
+
            {{ _('Press') }}
            
 
          • zzz interviewed on the InfoSec Daily Podcast (mp3) (August 18, 2011)
            • 
 
          • zzz interviewed by gulli.com (March '09)
            • 
 
          • Netzwelt.de article about being anonymous in the Internet
            • 
-
            Boards, newssite, others
            
+
            {{ _('Boards, newssite, others') }}
            
 
          • i2p (zzz) on twitter
            • 
 
          • Planet Peer Board (English)
            • 
 
          • Planet Peer Board (Deutsch)
            • 
-
            Very Old Stuff
            
+
            {{ _('Very Old Stuff') }}
            
 
          • Invisible IRC Project - the distant predecessor of I2P
            • 
 
          • The ancient I2P mailing list 2004-07 to 2006-10 (gmane)
 
          • The even more ancient invisiblenet mailing list 2002-10 to 2004-01 (gmane)
diff --git a/www.i2p2/pages/benchmarks.html b/i2p2www/pages/site/misc/benchmarks.html
similarity index 100%
rename from www.i2p2/pages/benchmarks.html
rename to i2p2www/pages/site/misc/benchmarks.html
diff --git a/i2p2www/pages/site/misc/clt.html b/i2p2www/pages/site/misc/clt.html
new file mode 100644
index 00000000..f3264513
--- /dev/null
+++ b/i2p2www/pages/site/misc/clt.html
@@ -0,0 +1,19 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}I2P at CLT and PetCon 2009.1{% endtrans %}{% endblock %}
+{% block content %}
+
            {% trans -%}
+Members of I2P will held a talk at CLT and PetCon 2009.1
+Two members of the I2P team will be at two forthcoming Linux day and security convention.
+{%- endtrans %}
            
+
+
            {% trans chemnitzer='http://chemnitzer.linux-tage.de/2009/info/' -%}
+On 14th march of 2009 there will be a short talk about general introduction to I2P at the Chemnitz Linux Tag 2009 hold by echelon.
+Echelon and some other members of the I2P family will attend to the Linux meeting the whole two days (Saturday and Sunday) and will be recognizable as I2P family members. Meet them, ask them your questions, show them your props! Show your support!
+{%- endtrans %}
            
+
+
            {% trans petcon='http://www.pet-con.org/index.php/PET_Convention_2009.1' -%}
+Just 10 days later the Privacy and Data Security convention in Dresden will take place.
+Again, echelon will attend this event and hold a short talk about general introduction to I2P. Another talk about the profiling by the I2P clients will be held.
+{%- endtrans %}
            
+
+{% endblock %}
diff --git a/www.i2p2/pages/cvs.html b/i2p2www/pages/site/misc/cvs.html
similarity index 70%
rename from www.i2p2/pages/cvs.html
rename to i2p2www/pages/site/misc/cvs.html
index 26f93a9f..554cd63c 100644
--- a/www.i2p2/pages/cvs.html
+++ b/i2p2www/pages/site/misc/cvs.html
@@ -1,11 +1,14 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}CVS{% endblock %}
-{% block content %}
            The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in an Monotone repository.
+{% block content %}
+
            {% trans monotone=site_url('get-involved/guides/monotone') -%}
+The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in a Monotone repository.
 For those who aren't very familiar with CVS, there is a
 fantastic book on the
 subject (developers only need to deal with the first chapter - "An Overview of
 CVS", as subsequent chapters go into some nasty details very few ever need to
-touch).
            
+touch).
+{%- endtrans %}
            
 
 
            Unix CVS
            
 
            cvs -d:pserver:anoncvs@cvs.i2p.net:/cvsroot login
            
@@ -25,6 +28,8 @@ Password: anoncvs
            
 
            Commits are sent to the CVS mailinglist
 
            
 
-
            Humorous quote from WinCVS: "Did you know...  Never experiment with new CVS
-commands on your working repository.  Create a sample module instead."
            
+
            {% trans -%}
+Humorous quote from WinCVS: "Did you know...  Never experiment with new CVS
+commands on your working repository.  Create a sample module instead."
+{%- endtrans %}
            
 {% endblock %}
diff --git a/i2p2www/pages/site/misc/i2ptunnel-migration.html b/i2p2www/pages/site/misc/i2ptunnel-migration.html
new file mode 100644
index 00000000..ab32d273
--- /dev/null
+++ b/i2p2www/pages/site/misc/i2ptunnel-migration.html
@@ -0,0 +1,54 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}I2PTunnel migration{% endtrans %}{% endblock %}
+{% block content %}
+
            {% trans %}I2PTunnel migration{% endtrans %}
            
+
+
            {% trans -%}
+After upgrading to the new architecture, you'll have to do a 
+little work to get your old I2PTunnel-driven servers running.  
+Lets walk through a simple example.  For an eepsite with the 
+old clientApp configuration, you had:
+{%- endtrans %}
            
+
            +  -e "server localhost 80 myWebPriv.dat"
+
            
+
+
            {% trans -%}To provide that same functionality on the new web architecture:{%- endtrans %}
            
+
              
+
            • {% trans url='http://localhost:7657/i2ptunnel/' %}Jump to {{ url }}{% endtrans %}
              • 
+
            • {% trans %}Click on Add new: [Server tunnel] "GO"{% endtrans %}
              • 
+
              • 
+ 
              • {% trans %}For the name: "eepsite"{% endtrans %}
                • 
+ 
              • {% trans %}For the description: "My eepsite, isn't it pretty?"{% endtrans %}
                • 
+ For the target host:{% endtrans %} localhost
+ 
              • {% trans %}For the target port:{% endtrans %} 80
                • 
+ 
              • {% trans -%}
+For the private key file: path to "myWebPriv.dat"
                 
+(it is recommended to copy that .dat to your new install dir)
+{%- endtrans %}
                • 
+ 
              • {% trans %}Check the "Start automatically?" checkbox{% endtrans %} [X]
                • 
+ 
              • {% trans %}Click "Save"{% endtrans %}
                • 
+
              • 
+
            • {% trans %}It will come back saying:{% endtrans %}
              
+
              +  * Not overwriting existing private keys in /usr/home/jrandom/routers/i2p/myWebPriv.dat
+  * Ready!
+
              • 
+
            
+
+
            {% trans -%}
+That's it!  Creating a new I2PTunnel server works the same way too, except you
+don't need to "copy the old file", obviously.  Behind the scenes, it is all driven
+by the i2ptunnel.config file, which you may modify externally (if you do,
+hit "Reload config" on the I2PTunnel web page, which will tear down all of your 
+existing tunnels and rebuild new ones)
+{%- endtrans %}
            
+
+
            {% trans -%}
+Note that you WILL need to wait until your router is integrated
+into the network before you are able to use the /i2ptunnel/ web
+interface.  It will say "Please be patient" if you try to 
+beforehand, which means that it is still trying to build the 
+necessary I2PTunnel sessions it has been configured to create.
+{%- endtrans %}
            
+{% endblock %}
diff --git a/i2p2www/pages/site/misc/i2ptunnel-services.html b/i2p2www/pages/site/misc/i2ptunnel-services.html
new file mode 100644
index 00000000..c9c6f6cf
--- /dev/null
+++ b/i2p2www/pages/site/misc/i2ptunnel-services.html
@@ -0,0 +1,180 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}I2PTunnel services{% endtrans %}{% endblock %}
+{% block content %}
+
            {% trans -%}
+Below is quick copy of aum's eepsite deployment guide.
+{%- endtrans %}
            
+
+{% trans %}1. - Deploy a local server{%- endtrans %}
+
              
+
            • {% trans -%}
+For simplicity's sake, we will walk through the setup of a web server; however, this procedure is the same regardless what protocol of servers and/or clients you are setting up.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+I recommend the Tiny Httpd web server, thttpd, (windows version available on site) although you can use anything that you feel comfortable with.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Another more robust option would be to use EasyPHP, which is also open source. It comes with PHP, PHPmyadmin, mySQL, and Apache web server. For newbies who have no experience setting up and hosting content over servers, see the hosting page for help.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+With the web server you've chosen, configure it to listen on a port of your choice, and serve its documents from a directory of your choice. For this example, we'll assume port 10880.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Make sure your firewall is set up so that you cannot receive incoming connections on this port (which would breach your anonymity).
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Test the webserver, by pointing your normal browser (the one with the "direct connection") at http://localhost:10880 (changing the 10880 to the port number you have chosen).
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Once your webserver is working, and you can access it locally with your browser, continue to the next step.
+{%- endtrans %}
              • 
+
            
+
+{% trans %}2 - Generate an I2P Destination Keypair{% endtrans %}
+
              
+
            • {% trans -%}
+I2P does not deal in IP addresses. To protect your anonymity, it deals in unique addresses called destination keys.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+A destination key works a lot like a regular IP address, except that it can't be traced to your IP address or physical location. When users place a request to speak with you, your gateways are the ones that answer for you. So the requesting user can only know the IP address of your gateways. However, gateways don't know your IP address, because gateways are the last nodes on your tunnels, and you anonymously create tunnels by way of garlic routing. (So gateways are like puppets that can't see their masters, and everyone communicates through these puppets)
+{%- endtrans %}
              • 
+
            • {% trans -%}
+To deploy a server on I2P, you create a destination keypair. You use the private key to authenticate your server when connecting it to I2P, and you make the public key (aka destination key) known publicly, so others can connect to your server. (indirectly, through your gateways)
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Each service you run on I2P requires a different keypair.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+To generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" (all on one line)
+{%- endtrans %}
              • 
+
            • {% trans -%}
+In windows, to generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat"
+{%- endtrans %}
              • 
+
            • {% trans -%}
+The filenames myWebPrivKey.dat and myWebPubKey.dat are arbitrary - choose whatever you want here, as long as you understand your own choices.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+We now need to export your public key into base64 format, which you will share with others.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+To convert your myWebPubKey.dat file into shareable base64, type the command java -cp lib/i2p.jar net.i2p.data.Base64 encode myWebPubKey.dat > myWebPubKey.txt (all on one line).
+{%- endtrans %}
              • 
+
            • {% trans -%}
+This file you have just generated, myWebPubKey.txt, contains a long base64 string (516 chars at last count), which we call a destination key. All you need to know about this string for now is that it allows remote clients to uniquely pinpoint and connect to your server, just the same way as an IP address allows remote machines to pinpoint and connect to your machine.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+However, in contrast to an IP address, there is no way to trace your machine's physical location - even though your server can be addressed via I2P, your IP address cannot be traced or associated with this destination key.
+{%- endtrans %}
              • 
+
            
+
+{% trans %}3 - Open a 'Tunnel' from I2P To Your Server{% endtrans %}
+
              
+
            • {% trans -%}
+For clients elsewhere in I2P to be able to access your server, you must run a 'bridge' or 'tunnel', which takes connections from these clients and forwards them to your local server.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+To activate such a tunnel, type the command java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" (all one line).
+{%- endtrans %}
              • 
+
            • {% trans -%}
+If you used different filenames or port number earlier on, change these accordingly
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Windows users, remember to replace apostrophes with double quotes. Thus: java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat"
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Within a few seconds, the 'tunnel' should now be active, and remote clients should be able to reach your server anonymously. Remember to let your router "warm up" before opening clients to it.
+{%- endtrans %}
              • 
+
            
+
+{% trans %}4 - Update Your hosts.txt File {% endtrans %}
+
              
+
            • {% trans -%}
+To test your own server locally, you'll need to create an entry in your hosts.txt file, so I2P can translate the simple URL you place in the browser's address bar into the full public key text needed to find your server.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where myserver.i2p is an I2P 'domain' you want to associate with your site, and the blahblahblah is the text of the base64 public key you created earlier in the file myWebPubKey.txt
+{%- endtrans %}
              • 
+
            • {% trans -%}
+With this in place, you and others can reach your server with the simple domain name myserver.i2p in the browser's address bar.
+{%- endtrans %}
              • 
+
            
+
+{% trans %}5 - Surf Your Site Within I2P{% endtrans %}
+
              
+
            • {% trans -%}
+Using your secondary browser - the one you earlier configured to use localhost:4444 as a proxy - point this browser to the address http://myserver.i2p
+{%- endtrans %}
              • 
+
            • {% trans -%}
+You should see the main page of your webserver come up.
+{%- endtrans %}
              • 
+
            
+
+{% trans %}6 - Create a Local Client Tunnel Connection {% endtrans %}
+
              
+
            • {% trans -%}
+We now have to think beyond just web servers.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+As you grow into I2P and get more of a 'feel' for it, you will want to use all manner of servers and clients.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+The beauty of I2P is that it allows standard Internet clients and servers for most protocols to be transparently 'tunneled' through the anonymous network.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+You can run mailservers/clients, nameservers/clients, newsservers/clients - almost anything at all - perhaps even FTP in passive mode.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Now, we'll create a client tunnel. This is like the server tunnel we created earlier, but works in reverse. It listens to a port on your local machine; your local client connects to this port; the connection gets forwarded through I2P to the service on the other end.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+To open your client tunnel for your server, type the command java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 10888 textofbase64key" (all one line).
+{%- endtrans %}
              • 
+
            • {% trans -%}
+The port 10888 is arbitrary - it just needs to be something other than the physical port your server is listening on.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+textofbase64key is simply the contents of the public key text file myWebPubKey.txt, reproduced fully on one line (alternately, instead of textofbase64key, you can specify the name from your hosts.txt - e.g. myserver.i2p)
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Within a minute or two of launching this command, the client tunnel from your local machine into I2P will be open and ready for use.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Point your regular web browser (ie, not the one you configured to use localhost:4444), and point it to http://localhost:10888
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Verify that the main page of your server eventually comes up in your browser.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+You use the same procedure for using any local client program to access a remote I2P server - just get the base64 public key (called destination key) of the remote server, choose a local port to connect to the remote server, open the tunnel, and just connect with your client to your heart's content.
+{%- endtrans %}
              • 
+
            
+
+{% trans %}7 - Share your server details with others{% endtrans %}
+
              
+
            • {% trans -%}
+Using an anonymous medium (eg the one of the I2P IRC servers or ugha's wiki), post your domain name (eg www.mynick.i2p as well as your destination key. Others will then be able to reach your server remotely, without either of you jeopardizing your anonymity.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Remember, you can go to What's on I2P and find the latest public keys linked to their URL. You should also post your own public key and URL their. However, you will want to do this anonymously, of course. Drupal.i2p.net is currently, as of this writing, only accessible from the net. So, to access the outside WWW anonymously from inside of I2P, you will need to start up your script called startSquid. Do it the same way you have been doing these other scripts. Reconfigure your browser to proxy on localhost:5555, as defined in the script, and when the script has generated it's keys, you can access the squid proxy. Put any WWW URL (such as Google or this i2p site) into your browser's address bar and you will be surfing the World Wide Web anonymously. Now you can safely post your public key, and no one can detect your IP address.
+{%- endtrans %}
              • 
+
            
+
+{% trans %}8 - Write Some Scripts To Handle All This Menial Nonsense{% endtrans %}
+
              
+
            • {% trans -%}
+It would drive most people crazy, going through all these steps every time one sets up an I2P server, and/or deploys a client.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Aum's website http://www.freenet.org.nz/i2p/ has a script called setupServer.py which automates all this nonsense into one simple command line . But I respect that people's tastes in user interfaces differ, and trying to write something which satisfies everyone's needs usually results in something so complex that it turns into newbie-repellent.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+So please feel free to use and/or customize setupServer.py to taste, or write your own in Python or another language.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Also, you may want to write a script which handles the startup of the I2P Router, the eepProxy, plus any and all tunnels you are using. I've got such a script called startEverything.sh, which gets launched at system startup. (Be sure to search this site for template scripts to automate your I2P commands. If I create a page for one, I'll try to remember to link it here.
+{%- endtrans %}
              • 
+
            • {% trans -%}
+Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file.
+{%- endtrans %}
              • 
+
            
+{% endblock %}
diff --git a/i2p2www/pages/site/misc/invisiblenet.html b/i2p2www/pages/site/misc/invisiblenet.html
new file mode 100644
index 00000000..7331d313
--- /dev/null
+++ b/i2p2www/pages/site/misc/invisiblenet.html
@@ -0,0 +1,24 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Old Documents{% endtrans %}{% endblock %}
+{% block content %}
+
+
            {% trans -%}
+Following is a list of documents originally on www.invisiblenet.net/i2p/ and
+rescued via the
+Wayback Machine.
+They are quite dated and may or may not be accurate.
+However, the I2CP and I2NP documents in particular have some good information.
+{%- endtrans %}
            
+
+
            Index of /i2p
            
+
            Name                    Last modified       Size
+
            
+I2CP_spec.pdf           03-Sep-2003 12:49   119k  
+I2NP_spec.pdf           03-Sep-2003 12:49   356k  
+datastructures.pdf      03-Sep-2003 12:49   149k  
+i2p_philosophy.pdf      03-Sep-2003 12:52   126k  
+polling_http_transpo..> 03-Sep-2003 12:49   189k  
+
            
+
+
+{% endblock %}
diff --git a/i2p2www/pages/site/misc/jbigi.html b/i2p2www/pages/site/misc/jbigi.html
new file mode 100644
index 00000000..caa4123f
--- /dev/null
+++ b/i2p2www/pages/site/misc/jbigi.html
@@ -0,0 +1,137 @@
+{% extends "global/layout.html" %}
+{% block title %}jbigi{% endblock %}
+{% block lastupdated %}{% trans %}August 2011{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.7{% endblock %}
+{% block content %}
+
            {% trans %}Overview{% endtrans %}
            
+
            {% trans -%}
+Using JNI (Java Native Interface), a bit of C code (thanks ugha!), a little
+manual work and a piece of chewing gum we have made several
+cryptography operations quite a bit faster.
+{%- endtrans %}
            
+
+
            {% trans gmplib='http://gmplib.org/',
+func='http://gmplib.org/manual-4.3.2/Integer-Exponentiation.html#Integer-Exponentiation',
+bigint='http://download.oracle.com/javase/1.5.0/docs/api/java/math/BigInteger.html#modPow%28java.math.BigInteger,%20java.math.BigInteger%29' -%}
+The speedup comes from the super-fast
+GNU MP Bignum library (libgmp).
+We use a single function from libgmp -
+mpz_powm()
+as a replacement for the
+Java Math library's BigInteger modPow().
+As modPow() is a significant computational portion of many crypto operations, this is of significant benefit.
+{%- endtrans %}
            
+
+
            {% trans nativebigint='http://docs.i2p-projekt.de/javadoc/net/i2p/util/NativeBigInteger.html',
+bigint='http://download.oracle.com/javase/1.5.0/docs/api/java/math/BigInteger.html#modPow%28java.math.BigInteger,%20java.math.BigInteger%29' -%}
+The standard I2P installation includes about 20 versions of the library for different platforms,
+each about 50KB, inside the jbigi.jar file.
+The initialization of the JBigI library, including CPU identification, selection, and extraction
+of the correct loadable module, is handled by the
+NativeBigInteger class.
+If no module is available for the current platform, the standard
+Java Math library's BigInteger modPow()
+is used.
+{%- endtrans %}
            
+
+
+
            {% trans %}Rebuilding and Testing JBigI{% endtrans %}
            
+{% trans %}Following are the instructions to build a new jbigi library for your own platform
+and testing its performance.{% endtrans %}
+
+
            {% trans %}Requirements{% endtrans %}
            
+
            {% trans -%}
+This works on Linux, and with a few changes in build.sh probably also on
+other platforms. FreeBSD has also been reported to work too. On Kaffee the
+speedup is very small, because it already uses native BitInteger internally.
+Blackdown seems to cause strange errors. Because you are going to do
+compilation, you need JDK; JRE won't work.
+{%- endtrans %}
            
+
            {% trans %}The required code is available in monotone database and the latest source tarball. {% endtrans %}
            
+
            {% trans -%}
+The GNU MP Bignum library (libgmp) needs to be installed, if it isn't
+included in your OS / distribution or installed already, it can be received from
+http://gmplib.org/#DOWNLOAD. Even if you
+have already installed it as binary, it might still be worth a try to compile
+GMP yourself, since then it will be able to use the specific instructions of
+your processor. The latest GMP may also
+be used instead of GMP 5.0.2, but it hasn't been tested by us.
+{%- endtrans %}
            
+
+
            {% trans %}Step-by-step instructions{% endtrans %}
            
+
              
+
            1. {% trans %}Look at your running environment on the logs.jsp page.
+There should be one of two status messages for JBigI - either{% endtrans %}
+
+{% trans %}Locally optimized native BigInteger loaded from the library path{% endtrans %}
+
+{% trans %}or{% endtrans %}
+
+{% trans %}Native BigInteger library jbigi not loaded - using pure java{% endtrans %}.
+{% trans %}If the native BitInteger library was NOT loaded, you definitely need to
+compile your own.
+Certain platforms, such as OS X, OpenSolaris, and 64-bit systems,
+may require you to compile your own library.
+If the BigInteger library was loaded, do at least the next step to see
+what your performance is.{% endtrans %}
+
              2. 
+
            2. {% trans -%}
+Look on http://localhost:7657/stats.jsp
+to see what the lifetime average values for crypto.elGamal.decrypt and
+crypto.elGamal.encrypt are. The numbers are times in milliseconds. Copy these somewhere so you can compare
+them later on.
+The network average for encrypt time is about 20ms.
+If your encrypt time is less than 50ms for a relatively new processor, or less than 100ms
+for an older processor, and the native BigInteger library was loaded, you are probably fine.
+{%- endtrans %}
              3. 
+
            3. {% trans downloads=get_url('downloads_list') -%}
+Get the latest released source code of I2P from
+the download page, or get the cutting-edge source
+out of the monotone database mtn.i2p2.de
+{%- endtrans %}
              4. 
+
            4. {% trans %}Inside the source tree change directory to: core/c/jbigi{% endtrans %}
              5. 
+
            5. {% trans -%}
+Read the README file.
+If you have a /usr/lib/libgmp.so file, you do not have to download GMP.
+Use the 'dynamic' argument to build.sh.
+Otherwise, you must download GMP version 5.0.2 from
+from http://gmplib.org/#DOWNLOAD, saving it to gmp-5.0.2.tar.bz2.
+If you decide to use a newer version, change the VER= line in core/c/jbigi/build.sh.
+{%- endtrans %}
+
            6. {% trans -%}
+Take a look at build.sh, if your JAVA_HOME
+environment variable is set and you are using Linux then it might just work.
+Otherwise change the settings. Remember, you need the Java SDK installed.
+{%- endtrans %}
              7. 
+
            7. {% trans -%}
+Run build.sh (if you downloaded GMP) or
+build.sh dynamic (if you have /usr/lib/libgmp.so).
              
+Maybe the build spewed out some errors of missing jni.h and jni_md.h files.
+Either copy these files from your java install into the core/c/jbigi/jbigi/include/ directory,
+or fix $JAVA_HOME.
              
+You can run the build.sh from the core/c/ directory which will
+build all available jbigi libs into a jbigi.jar.
              
+A file named libjbigi.so should be created in the current
+directory. If this doesn't happen and/or you get errors then please report
+them.
+{%- endtrans %}
              8. 
+
            8. {% trans -%}
+Follow the instructions in core/c/README to install the library and run
+the speed test.
+Read the final lines of the speed test's output for some additional
+info, it will be something like this:
+{%- endtrans %}
              +native run time:  5842ms ( 57ms each)
+java run time:   41072ms (406ms each)
+native = 14.223802103622907% of pure java time
+
              
+{% trans %}If the native is indeed 5-7x faster (or more) then it looks all good. If not, please report.{% endtrans %}
              9. 
+
            9. {% trans %}Copy libjbigi.so to your i2p directory{% endtrans %}
              10. 
+
            10. {% trans %}Restart your I2P programs.{% endtrans %}
              11. 
+
            11. {% trans -%}
+On http://localhost:7657/stats.jsp
+the crypto.elGamal.decrypt and crypto.elGamal.encrypt
+should be a lot faster.
+{%- endtrans %}
              12. 
+
            
+{% endblock %}
diff --git a/www.i2p2/pages/jrandom-awol.html b/i2p2www/pages/site/misc/jrandom-awol.html
similarity index 85%
rename from www.i2p2/pages/jrandom-awol.html
rename to i2p2www/pages/site/misc/jrandom-awol.html
index 5ca4aff9..afdbf49e 100644
--- a/www.i2p2/pages/jrandom-awol.html
+++ b/i2p2www/pages/site/misc/jrandom-awol.html
@@ -1,20 +1,25 @@
-{% extends "_layout.html" %}
-{% block title %}Jrandom's Announcement{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Jrandom's Announcement{% endtrans %}{% endblock %}
 {% block content %}
+
            {% trans -%}
 The following message was received in mid-November 2007. We have no further information
 on jrandom's status.
-
            
+{%- endtrans %}
            
+
+
            {% trans site=site_url() -%}
 Subsequently, in an unrelated incident, the hosting company for
 all *.i2p.net servers (except forum.i2p.net) suffered a power outage
 on January 13, 2008, and the i2p.net servers did not fully return to service.
 As only jrandom has the credentials required to restore service,
 and he could not be contacted,
-we moved all public services to www.i2p2.de
+we moved all public services to www.i2p2.de
 and related subdomains.
-
            
+{%- endtrans %}
            
+
+
            {% trans forum=i2pconv('forum.i2p') -%}
 Approximately two months later, for unrelated reasons,
-forum.i2p.net was moved to forum.i2p2.de.
-
            
+forum.i2p.net was moved to {{ forum }}.
+{%- endtrans %}
            
 
             -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
diff --git a/i2p2www/pages/site/misc/manual-wrapper.html b/i2p2www/pages/site/misc/manual-wrapper.html
new file mode 100644
index 00000000..9b08a600
--- /dev/null
+++ b/i2p2www/pages/site/misc/manual-wrapper.html
@@ -0,0 +1,68 @@
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}Manually Installing the Java Wrapper{% endtrans %}{% endblock %}
+{% block content %}
+
            {% trans %}Manually Installing the Java Wrapper{% endtrans %}
            
+
+
            {% trans downloads=get_url('downloads_list') -%}
+The installation package for the I2P router comes
+with a Java wrapper for the most common architectures. If your system is not
+supported by our installer—or if you want to update the wrapper to a
+newer version—the following steps describe installing the wrapper manually.
+{%- endtrans %}
            
+
+
              
+  
            • {% trans -%}
+Check Tanuki Software's download page
+for your platform. Is your platform listed? If so, you're in
+luck! Download the most recent version of the Community Edition for your OS and
+CPU and move to the next step.
+{%- endtrans %}
              • 
+  
            • {% trans -%}
+If your platform does not have an already compiled wrapper available, you
+may be able to compile it yourself. If you are willing to have a go at it, move
+on to compiling the wrapper for your system.
+{%- endtrans %}
              • 
+
            
+
+
            {% trans %}Using existing binaries{% endtrans %}
            
+
            {% trans -%}
+In the steps below, $I2P means the location I2P was installed to.
+{%- endtrans %}
            
+
              
+  
            1. tar xzf wrapper-*.tar.gz
              2. 
+  
            2. cp wrapper*/bin/wrapper $I2P/i2psvc
              3. 
+  
            3. cp wrapper*/lib/wrapper.jar $I2P/lib
              4. 
+  
            4. cp wrapper*/lib/libwrapper.so $I2P/lib
              5. 
+  
            5. {% trans %}Try to start I2P using $I2P/i2prouter start{% endtrans %}
              6. 
+  
            6. {% trans %}tail -f /tmp/wrapper.log and look for any problems.{% endtrans %}
              7. 
+
            
+
            {% trans -%}
+If this did not work you'll need to use runplain.sh to start I2P.
+{%- endtrans %}
            
+
+
            {% trans %}Compiling from source{% endtrans %}
            
+
            {% trans -%}
+These steps worked to compile the wrapper for use on a mipsel system running Debian. The steps will need to be altered for your system.
+{%- endtrans %}
            
+
              
+  
            1. {% trans %}Download the source archive for the community version of the wrapper from wrapper download page.{% endtrans %}
              2. 
+  
            2. {% trans %}Extract the tarball{% endtrans %}
              
+    tar xzf wrapper_3.5.13_src.tar.gz
              3. 
+  
            3. {% trans %}Set environment variables ANT_HOME and JAVA_HOME. For example, in Debian:{% endtrans %}
              
+    export ANT_HOME=/usr/share/ant
              
+    export JAVA_HOME=/usr/lib/jvm/default-java
              4. 
+  
            4. {% trans %}Since there isn't a Makefile for Mipsel, we'll make a copy of an already existing makefile:{% endtrans %}
              
+    cp src/c/Makefile-linux-x86-32.make src/c/Makefile-linux-mipsel-32.make
              5. 
+  
            5. {% trans %}Now we can attempt to compile the wrapper:{% endtrans %}
              
+    ./build32.sh   ({% trans %}use ./build64.sh if you have a 64bit CPU and JVM{% endtrans %})
              6. 
+  
            6. {% trans %}Copy the wrapper into its proper place:{% endtrans %}
+  
                
+    
              • cp bin/wrapper $I2P/i2psvc
                • 
+    
              • cp lib/wrapper.jar $I2P/lib
                • 
+    
              • cp lib/libwrapper.so $I2P/lib
                • 
+  
              7. 
+  
            7. {% trans %}Try to start I2P using $I2P/i2prouter start{% endtrans %}
              8. 
+  
            8. {% trans %}tail -f /tmp/wrapper.log and look for any problems.{% endtrans %}
              9. 
+
            
+
            {% trans %}If this did not work you'll need to use runplain.sh to start I2P.{% endtrans %}
            
+{% endblock %}
diff --git a/www.i2p2/pages/minwww.html b/i2p2www/pages/site/misc/minwww.html
similarity index 77%
rename from www.i2p2/pages/minwww.html
rename to i2p2www/pages/site/misc/minwww.html
index 2fc32768..c6590361 100644
--- a/www.i2p2/pages/minwww.html
+++ b/i2p2www/pages/site/misc/minwww.html
@@ -1,13 +1,18 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}minwww{% endblock %}
-{% block content %}
            Here's an outline and rationale for a minimal WWW proxy app for use over
-I2P.
            
-
            HTTP operation over I2P using I2PTunnel.  When the base SocketLibrary
+{% block content %}
+
            {% trans -%}
+Here's an outline and rationale for a minimal WWW proxy app for use over I2P.
+{%- endtrans %}
            
+
+
            {% trans -%}
+HTTP operation over I2P using I2PTunnel.  When the base SocketLibrary
 is out, the only significant difference will be the 'wrapRequest' and
 'unwrapRequest' will functionally be placed in the socketLibrary, not
 in the router (but later versions of the SocketLibrary will be able to
 use selective ACK and large window sizes, allowing more ACKs to be
-skipped)
            
+skipped)
+{%- endtrans %}
            
 
             ---BROWSER--->-I2PTUNNEL--->-ROUTERA--->-ROUTERB--->-I2PTUNNEL--->-HTTPD----------
  1: openCon
@@ -38,8 +43,11 @@ skipped)
            
 26:                         receiveACK               receiveClose
 27:            sentSuccess
 
            
-
            An optimized form, designed to handle only 128KB [1] files and pages, can
-operate significantly faster:
            
+
+
            {% trans -%}
+An optimized form, designed to handle only 128KB [1] files and pages, can
+operate significantly faster:
+{%- endtrans %}
            
 
                BROWSER --> MinWWW   --> ROUTERA --> ROUTERB --> MinWWW    --> HTTPD
  1: openCon
@@ -59,7 +67,9 @@ operate significantly faster:
            
 15: closeCon
 16:            closed
 
            
-
            The difference in network load and latency is significant - this is
+
+
            {% trans -%}
+The difference in network load and latency is significant - this is
 essentially a UDP version of HTTP.  On the normal web, we can't really do that,
 since most HTTP requests and responses are orders of magnitude larger than UDP
 packets functionally support, but in I2P, messages can be large.  The savings
@@ -67,20 +77,29 @@ for the network load comes from the fact that we don't need to send any ACK
 messages - rather than the earlier wrap/unwrap request (that bundles a
 DataMessage with a DeliveryStatusMessage to provide guaranteed delivery), the
 MinWWW proxy deals with resends (if necessary - in I2PTunnel today, there are no
-resends).
            
-
            The data that the MinWWW proxy and server need to wrap is trivial - when the
+resends).
+{%- endtrans %}
            
+
+
            {% trans -%}
+The data that the MinWWW proxy and server need to wrap is trivial - when the
 proxy wants to send "GET /", it prepends it with the I2P Destination sending
 the request, followed by a 4 byte request ID.  The MinWWW server receives those
 requests, contacts the appropriate HTTPD, sends the request, waits for the
 response, and sends a reply to the MinWWW proxy containing the response,
 prefixed with the original request ID.  That response is taken and passed back
-to the browser and the connection is closed.
            
-
            In addition, the MinWWW proxy can choose the MinWWW server to use from a
+to the browser and the connection is closed.
+{%- endtrans %}
            
+
+
            {% trans -%}
+In addition, the MinWWW proxy can choose the MinWWW server to use from a
 list, going through some round robin or other algorithm, so that there are
 multiple outproxies merged transparently.  The bandwidth required for running
 one of these outproxies is also greatly reduced, since it will only handle 128KB
-files (aka no one is going to be downloading porn, warez, etc).
            
-
            The functionality /is/ limited, but 128KB of data is a lot for a single HTTP
+files (aka no one is going to be downloading porn, warez, etc).
+{%- endtrans %}
            
+
+
            {% trans -%}
+The functionality /is/ limited, but 128KB of data is a lot for a single HTTP
 request or response.  The above diagrams are also unrealistic in their hops -
 ROUTERA will really never talk directly to ROUTERB.  ROUTERA will send each
 of the messages through two additional outbound routers, then forwarded to
@@ -88,16 +107,23 @@ two additional inbound routers to ROUTERB, so the lag there is significant -
 while the above only saves 11 steps, 8 of those steps need to traverse the
 entire tunnel path (4+ remote hops each time when tunnels are 2 remote hops
 in each stretch), leaving MinWWW with only two full traversals (one for the
-request, one for the response), instead of 10.
            
-
            Implementing the MinWWW proxy and server should be fairly easy - read an HTTP
+request, one for the response), instead of 10.
+{%- endtrans %}
            
+
+
            {% trans -%}
+Implementing the MinWWW proxy and server should be fairly easy - read an HTTP
 request from the client fully (perhaps only start out with HTTP GET, leaving
 HTTP POST for later), wrap the message, and wait for the response.  The server
 in turn simply needs to parse the request to either open a socket or URL,
 send the request, wait for the response, and send it back through the network.
-If someone were to implement this, it would be Good :)
            
-
            [1] Why 128KB files?  Currently I2CP allows functionally arbitrary message
+If someone were to implement this, it would be Good :)
+{%- endtrans %}
            
+
+
            {% trans -%}
+[1] Why 128KB files?  Currently I2CP allows functionally arbitrary message
 size, but that's going to be going away since it involves either excessive memory
 overhead on intermediary routers, or additional implementation details to
 handle.  I2PTunnel is currently limited to 128KB and hasn't been a burden,
-so perhaps it could be increased to 256KB when the I2CP spec is updated)
            
-{% endblock %}
\ No newline at end of file
+so perhaps it could be increased to 256KB when the I2CP spec is updated)
+{%- endtrans %}
            
+{% endblock %}
diff --git a/www.i2p2/pages/myi2p.html b/i2p2www/pages/site/misc/myi2p.html
similarity index 67%
rename from www.i2p2/pages/myi2p.html
rename to i2p2www/pages/site/misc/myi2p.html
index 4daf83c2..e7457b05 100644
--- a/www.i2p2/pages/myi2p.html
+++ b/i2p2www/pages/site/misc/myi2p.html
@@ -1,14 +1,18 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}MYI2P{% endblock %}
-{% block content %}
            There has been discussion about a distributed blogging application for a few
+{% block content %}
+
            {% trans -%}
+There has been discussion about a distributed blogging application for a few
 months now called "MyI2P".  While the original discussions were lost, we were 
 able to retrieve a Google cache
 of it.  It isn't pretty, but it includes the basic overview and some discussion
-that ensued.
            
+that ensued.
+{%- endtrans %}
            
 
-
            The application itself is not yet implemented, and the ideas behind it have 
+
            {% trans roadmap=site_url('get-involved/roadmap'), datagrams=site_url('docs/spec/datagrams') -%}
+The application itself is not yet implemented, and the ideas behind it have 
 been made less ambitious over time, but they are still valid and the current 
-plan is to have the core MyI2P functionality available 
+plan is to have the core MyI2P functionality available 
 along side the I2P 1.0 release.  That will include a distributed address book
 to enable secure, distributed, and human readable naming by sacrificing the 
 need for global uniqueness - basically everyone has their own local address book 
@@ -19,12 +23,15 @@ system using a reduced and secured subset of
 bbcode to essentially
 provide an anonymous LiveJournal with
 a 'friends list' and transparent access control (authenticated by the I2P
-datagrams with rules defined based on the address book).
            
+datagrams with rules defined based on the address book).
+{%- endtrans %}
            
 
-
            Additional functionality, such as integration with a DHT backing store or 
+
            {% trans -%}
+Additional functionality, such as integration with a DHT backing store or 
 swarming file transfers for 'attachments' can be added later.  Email may or may
 not get in the first pass either, though its implementation is essentially just
 a blog entry with private access, so perhaps some UI designer can come up with
 something.  Exporting the data to RSS or access through ATOM will be an option 
-down the road as well.
            
-{% endblock %}
\ No newline at end of file
+down the road as well.
+{%- endtrans %}
            
+{% endblock %}
diff --git a/www.i2p2/pages/ratestats.html b/i2p2www/pages/site/misc/ratestats.html
similarity index 96%
rename from www.i2p2/pages/ratestats.html
rename to i2p2www/pages/site/misc/ratestats.html
index e51b0c01..6a1fb1ac 100644
--- a/www.i2p2/pages/ratestats.html
+++ b/i2p2www/pages/site/misc/ratestats.html
@@ -1,13 +1,13 @@
-{% extends "_layout.html" %}
-{% block title %}RateStat list{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}RateStat list{% endtrans %}{% endblock %}
+{% block accuratefor %}0.8.7{% endblock %}
 {% block content %}
-
            RateStat list
            
-
            I2P enables the collection of a wide range of rates, the list published here is accurate as of I2P version 0.8.7.
            
-
            The list was gathered using the following command in the top directory of the branch i2p.i2p,
+
            {% trans %}RateStat list{% endtrans %}
            
+
            {% trans %}I2P enables the collection of a wide range of rates.{% endtrans %}
            
+
            {% trans %}The list was gathered using the following command in the top directory of the branch i2p.i2p:{% endtrans %}
            
 
             find . -name '*' -print | xargs --max-args=3 grep -n --color=auto addRateData | awk 'match($0, /addRateData\(\"(.*)\"/, a) {print a[1]}' | awk '!_[$0]++' | sort > rates.txt
 
            
-All options aren't needed, but it works.
-
            
+
            {% trans %}All options aren't needed, but it works.{% endtrans %}
            
 
 
            RateStats
            
 
            diff --git a/i2p2www/pages/site/misc/transition-guide.html b/i2p2www/pages/site/misc/transition-guide.html
new file mode 100644
index 00000000..7b6ce216
--- /dev/null
+++ b/i2p2www/pages/site/misc/transition-guide.html
@@ -0,0 +1,29 @@
+{% extends "global/layout.html" %}
+{% block title %}Monotone{% endblock %}
+{% block content %}
+
            {% trans forum=i2pconv('forum.i2p'), newdevs=site_url('get-involved/guides/new-developers') -%}
+The I2P sourcecode is kept in several distributed monotone repositories.
+See the
+Monotone website for information
+on monotone.
+See
+this forum post on i2p monotone
+for more information on how to get started and check out the source anonymously.
+There is also a quick-start guide on the
+new developer's page.
+{%- endtrans %}
            
+
+
            {% trans -%}
+If you want to get the source non-anonymously, pull from the public server mtn.welterde.de.
+The i2p source code branch is "i2p.i2p".
+{%- endtrans %}
            
+
+
            {% trans %}Guide{% endtrans %}
            
+
            {%- trans %}
+The following is a detailed guide by Complication.
+{%- endtrans %}
            
+
            +  {% include "site/misc/transition-guide.txt" %}
+
            
+
+{% endblock %}
diff --git a/www.i2p2/pages/transition-guide.txt b/i2p2www/pages/site/misc/transition-guide.txt
similarity index 100%
rename from www.i2p2/pages/transition-guide.txt
rename to i2p2www/pages/site/misc/transition-guide.txt
diff --git a/www.i2p2/pages/upgrade-0.6.1.30.html b/i2p2www/pages/site/misc/upgrade-0.6.1.30.html
similarity index 59%
rename from www.i2p2/pages/upgrade-0.6.1.30.html
rename to i2p2www/pages/site/misc/upgrade-0.6.1.30.html
index 5adc7362..c0d267fc 100644
--- a/www.i2p2/pages/upgrade-0.6.1.30.html
+++ b/i2p2www/pages/site/misc/upgrade-0.6.1.30.html
@@ -1,60 +1,73 @@
-{% extends "_layout.html" %}
-{% block title %}How to Upgrade from 0.6.1.30 and Earlier{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}{% trans %}How to Upgrade from 0.6.1.30 and Earlier{% endtrans %}{% endblock %}
 {% block content %}
 
            
 •
-2008-02-05: Upgrading from 0.6.1.30 and Earlier Releases
-
            
+2008-02-05: {% trans %}Upgrading from 0.6.1.30 and Earlier Releases{% endtrans %}
+
            
+
            {% trans jrandom=site_url('misc/jrandom-awol') -%}
 Since i2p's lead developer
-has gone AWOL,
+has gone AWOL,
 we do not have his update signing key or access to
 www.i2p[.net] or dev.i2p[.net].
 Complication and zzz have generated new signing keys, and they and Amiga are providing
 update file hosting. These changes must be configured in your router to take effect.
-
            
+{%- endtrans %}
            
+
+
            {% trans -%}
 Make the following configuration changes and your router will automatically install
 the latest release.
-
            
+{%- endtrans %}
            
+
+
            {% trans downloads=get_url('downloads_list') -%}
 We recommend the automated process as it will verify the key of the signed update file.
 If you do not make these changes,
 you may manually download the i2pupdate.zip file from
-the download page.
-
            1. 
+the download page.
+{%- endtrans %}
              
+
+
                
+
              1. 
 On
 configupdate.jsp:
-
                1. 
-Change the News URL to: http://complication.i2p/news.xml
-
                2. 
-Select ONE of the following new Update URLs at random and enter it into the Update URL box: 
+  
                    
+    
                  1. {% trans url='http://complication.i2p/news.xml' -%}
+Change the News URL to: {{ url }}
+{%- endtrans %}
                    2. 
+    
                  2. 
+{% trans %}Select ONE of the following new Update URLs at random and enter it into the Update URL box: {% endtrans %}
 
                    http://amiga.i2p/i2p/i2pupdate.sud
 
                    http://complication.i2p/i2p/i2pupdate.sud
 
                    http://stats.i2p/i2p/i2pupdate.sud
-
                  3. 
-Check the box "Update through the eepProxy?"
-
                  4. 
-Click "Save"
-
                  
+
                  3. 
+    
                3. {% trans %}Check the box "Update through the eepProxy?"{% endtrans %}
                  4. 
+    
                4. {% trans %}Click "Save"{% endtrans %}
                  5. 
+  
                
+
 
              2. 
 On
 configadvanced.jsp:
-
                1. 
-Add the following line:
+  
                    
+    
                  1. {% trans %}Add the following line:{% endtrans %}
 
                    
 
-
                  2. 
-Click "Apply"
-
                  
-
                2. 
+
                  3. 
+    
                3. {% trans %}Click "Apply"{% endtrans %}
                  4. 
+  
                
+
                3. 
+
              3. {% trans -%}
 You are now ready to automatically receive the release update file,
 either by setting your update policy to "download and install" or by clicking on the
 "update available" link when it appears.
-
              
-
              
+{%- endtrans %}
              2. 
+
            
+
+
            {% trans url='http://'+i2pconv('stats.i2p')+'/i2p/signingkeys.html' -%}
 If you would like to verify the trusted update keys, they are also
-posted and signed here.
+posted and signed here.
 Thank you for your support during this transition. For help please contact us on #i2p.
-
            
-Amiga, Complication, welterde, zzz
-
            
+{%- endtrans %}
            
+
+
            Amiga, Complication, welterde, zzz
            
 
 {% endblock %}
diff --git a/i2p2www/pages/site/research/index.html b/i2p2www/pages/site/research/index.html
new file mode 100644
index 00000000..5135e74d
--- /dev/null
+++ b/i2p2www/pages/site/research/index.html
@@ -0,0 +1,21 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Academic Research') }}{% endblock %}
+{% block content %}
+
            {% trans -%}
+Academic research and analysis of I2P is an important part of ensuring that the software and network performs as expected and is safe for users in hostile environments.
+{%- endtrans %}
            
+
+
            {% trans -%}
+I2P can be run as a separate test network by controlling the locations that a new router reseeds from so that it only finds other test routers. Additionally, the router can be run on its own in a virtual network mode to enable testing the router in isolation; to enable this mode, add i2p.vmCommSystem=true to the router.config before starting.
+{%- endtrans %}
            
+
+
            {% trans contact=site_url('contact') -%}
+If you are planning on conducting research on the live I2P network, please contact us before you commence your testing. While we do not discourage researchers from responsibly testing their ideas on the live network, if an attack becomes apparent and we don't have any line of communication then we will end up taking countermeasures which could interfere with the test.
+{%- endtrans %}
            
+
+
            {{ _('Prior Research') }}
            
+
+
            {% trans papers=site_url('research/papers') -%}
+A list of known published papers about I2P is available here.
+{%- endtrans %}
            
+{% endblock %}
diff --git a/i2p2www/pages/site/research/papers.html b/i2p2www/pages/site/research/papers.html
new file mode 100644
index 00000000..674db864
--- /dev/null
+++ b/i2p2www/pages/site/research/papers.html
@@ -0,0 +1,113 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ _('Papers on I2P') }}{% endblock %}
+{% block content %}
+
            {{ _('Papers on I2P') }}
            
+
            
+{% trans %}Following are links to research papers about I2P.{% endtrans %}
+
            
+
            {% trans email='press ~~~at~~~ i2p2.de' -%}
+To request an addition to this page, please send to {{ email }}.
+{%- endtrans %}
            
+
            
+{% trans %}Newest links are at the top of the page.{% endtrans %}
+
            
+
+
            
+
+
            {{ _('Papers and Research') }}
            
+
+
+
            
+{% endblock %}
diff --git a/i2p2www/sitemap.py b/i2p2www/sitemap.py
new file mode 100644
index 00000000..ccbddf6a
--- /dev/null
+++ b/i2p2www/sitemap.py
@@ -0,0 +1,94 @@
+from flask import make_response, render_template, request, safe_join
+import os.path
+
+from i2p2www import SITE_DIR, SUPPORTED_LANGS, cache
+from i2p2www.blog.helpers import get_blog_slugs
+from i2p2www.meetings.helpers import get_meetings_ids
+
+
+##########
+# Sitemaps
+
+def get_sitemap_cache_key():
+    return 'view/%s/%s' % (request.url_root, request.path)
+
+@cache.cached(600, get_sitemap_cache_key)
+def render_sitemap_index():
+    # Include the / at the end, so the language can be
+    # sandwiched between url_root and /sitemap.xml in
+    # the template.
+    url_root = request.url_root
+
+    # Render and return the sitemap index
+    response = make_response(render_template('global/sitemap_index.xml', url_root=url_root, langs=SUPPORTED_LANGS))
+    response.headers['Content-Type'] = 'application/xml'
+    return response
+
+@cache.cached(600, get_sitemap_cache_key)
+def render_sitemap():
+    # Include the / at the end, so the language can be
+    # sandwiched between url_root and url.path in the
+    # template.
+    url_root = request.url_root
+    urls = []
+
+    # --------------
+    # Main site urls
+    # --------------
+    # walk over all directories/files
+    for v in os.walk(SITE_DIR):
+        # iterate over all files
+        pathbase = os.path.relpath(v[0], SITE_DIR)
+        for f in v[2]:
+            # ignore all non-.html files
+            if not f.endswith('.html'):
+                continue
+            path = pathbase
+            if f != 'index.html':
+                path = safe_join(pathbase, f[:-5])
+            if path.startswith('.'):
+                path = path[1:]
+            if not path.startswith('/'):
+                path = '/%s' % path
+            urls.append({
+                'path': path,
+                })
+
+    # ---------
+    # Blog urls
+    # ---------
+    urls.append({
+        'path': '/blog/',
+        })
+    blog_slugs = get_blog_slugs()
+    for slug in blog_slugs:
+        urls.append({
+            'path': '/blog/entry/%s' % slug,
+            })
+
+    # -------------
+    # Meetings urls
+    # -------------
+    urls.append({
+        'path': '/meetings/',
+        })
+    meetings = get_meetings_ids()
+    for id in meetings:
+        urls.append({
+            'path': '/meetings/%d' % id,
+            })
+
+    # --------------
+    # Downloads urls
+    # --------------
+    urls.append({
+        'path': '/download',
+        })
+    urls.append({
+        'path': '/download/debian',
+        })
+
+    # Render and return the sitemap
+    response = make_response(render_template('global/sitemap.xml', url_root=url_root, langs=SUPPORTED_LANGS, urls=urls))
+    response.headers['Content-Type'] = 'application/xml'
+    return response
diff --git a/www.i2p2/pages/BingSiteAuth.xml b/i2p2www/static/BingSiteAuth.xml
similarity index 100%
rename from www.i2p2/pages/BingSiteAuth.xml
rename to i2p2www/static/BingSiteAuth.xml
diff --git a/www.i2p2/static/favicon.ico b/i2p2www/static/favicon.ico
similarity index 100%
rename from www.i2p2/static/favicon.ico
rename to i2p2www/static/favicon.ico
diff --git a/www.i2p2/pages/googleadcf8b9c9f4ff24f.html b/i2p2www/static/googleadcf8b9c9f4ff24f.html
similarity index 100%
rename from www.i2p2/pages/googleadcf8b9c9f4ff24f.html
rename to i2p2www/static/googleadcf8b9c9f4ff24f.html
diff --git a/www.i2p2/pages/hosts.txt b/i2p2www/static/hosts.txt
similarity index 100%
rename from www.i2p2/pages/hosts.txt
rename to i2p2www/static/hosts.txt
diff --git a/www.i2p2/static/images/I2PTunnel-streamr.png b/i2p2www/static/images/I2PTunnel-streamr.png
similarity index 100%
rename from www.i2p2/static/images/I2PTunnel-streamr.png
rename to i2p2www/static/images/I2PTunnel-streamr.png
diff --git a/www.i2p2/static/images/add-key-terminal.png b/i2p2www/static/images/add-key-terminal.png
similarity index 100%
rename from www.i2p2/static/images/add-key-terminal.png
rename to i2p2www/static/images/add-key-terminal.png
diff --git a/www.i2p2/static/images/bandwidth2009.png b/i2p2www/static/images/bandwidth2009.png
similarity index 100%
rename from www.i2p2/static/images/bandwidth2009.png
rename to i2p2www/static/images/bandwidth2009.png
diff --git a/i2p2www/static/images/btn_left.png b/i2p2www/static/images/btn_left.png
new file mode 100644
index 00000000..9e49dd00
Binary files /dev/null and b/i2p2www/static/images/btn_left.png differ
diff --git a/i2p2www/static/images/btn_right.png b/i2p2www/static/images/btn_right.png
new file mode 100644
index 00000000..d4a6d2b8
Binary files /dev/null and b/i2p2www/static/images/btn_right.png differ
diff --git a/i2p2www/static/images/btn_stretch.png b/i2p2www/static/images/btn_stretch.png
new file mode 100644
index 00000000..4dd0197e
Binary files /dev/null and b/i2p2www/static/images/btn_stretch.png differ
diff --git a/www.i2p2/static/images/dark.png b/i2p2www/static/images/dark.png
similarity index 100%
rename from www.i2p2/static/images/dark.png
rename to i2p2www/static/images/dark.png
diff --git a/www.i2p2/static/images/darkbluebg.png b/i2p2www/static/images/darkbluebg.png
similarity index 100%
rename from www.i2p2/static/images/darkbluebg.png
rename to i2p2www/static/images/darkbluebg.png
diff --git a/www.i2p2/static/images/darkbluetile.png b/i2p2www/static/images/darkbluetile.png
similarity index 100%
rename from www.i2p2/static/images/darkbluetile.png
rename to i2p2www/static/images/darkbluetile.png
diff --git a/www.i2p2/static/images/darkerbluetile.png b/i2p2www/static/images/darkerbluetile.png
similarity index 100%
rename from www.i2p2/static/images/darkerbluetile.png
rename to i2p2www/static/images/darkerbluetile.png
diff --git a/i2p2www/static/images/dots.png b/i2p2www/static/images/dots.png
new file mode 100644
index 00000000..2909e4a6
Binary files /dev/null and b/i2p2www/static/images/dots.png differ
diff --git a/www.i2p2/static/images/download.png b/i2p2www/static/images/download.png
similarity index 100%
rename from www.i2p2/static/images/download.png
rename to i2p2www/static/images/download.png
diff --git a/www.i2p2/static/images/download_dark.png b/i2p2www/static/images/download_dark.png
similarity index 100%
rename from www.i2p2/static/images/download_dark.png
rename to i2p2www/static/images/download_dark.png
diff --git a/www.i2p2/static/images/endToEndEncryption.png b/i2p2www/static/images/endToEndEncryption.png
similarity index 100%
rename from www.i2p2/static/images/endToEndEncryption.png
rename to i2p2www/static/images/endToEndEncryption.png
diff --git a/www.i2p2/static/images/endToEndEncryption_fr.png b/i2p2www/static/images/endToEndEncryption_fr.png
similarity index 100%
rename from www.i2p2/static/images/endToEndEncryption_fr.png
rename to i2p2www/static/images/endToEndEncryption_fr.png
diff --git a/www.i2p2/static/images/endToEndEncryption_zh.png b/i2p2www/static/images/endToEndEncryption_zh.png
similarity index 100%
rename from www.i2p2/static/images/endToEndEncryption_zh.png
rename to i2p2www/static/images/endToEndEncryption_zh.png
diff --git a/i2p2www/static/images/feed-icon-28x28.png b/i2p2www/static/images/feed-icon-28x28.png
new file mode 100644
index 00000000..d64c669c
Binary files /dev/null and b/i2p2www/static/images/feed-icon-28x28.png differ
diff --git a/www.i2p2/static/images/firefox.options.jpg b/i2p2www/static/images/firefox.options.jpg
similarity index 100%
rename from www.i2p2/static/images/firefox.options.jpg
rename to i2p2www/static/images/firefox.options.jpg
diff --git a/www.i2p2/static/images/firefox.options_fr.png b/i2p2www/static/images/firefox.options_fr.png
similarity index 100%
rename from www.i2p2/static/images/firefox.options_fr.png
rename to i2p2www/static/images/firefox.options_fr.png
diff --git a/www.i2p2/static/images/firefox.proxyports.jpg b/i2p2www/static/images/firefox.proxyports.jpg
similarity index 100%
rename from www.i2p2/static/images/firefox.proxyports.jpg
rename to i2p2www/static/images/firefox.proxyports.jpg
diff --git a/www.i2p2/static/images/firefox.proxyports_fr.png b/i2p2www/static/images/firefox.proxyports_fr.png
similarity index 100%
rename from www.i2p2/static/images/firefox.proxyports_fr.png
rename to i2p2www/static/images/firefox.proxyports_fr.png
diff --git a/www.i2p2/static/images/lang_ar.png b/i2p2www/static/images/flags/ar.png
similarity index 100%
rename from www.i2p2/static/images/lang_ar.png
rename to i2p2www/static/images/flags/ar.png
diff --git a/www.i2p2/static/images/cz.png b/i2p2www/static/images/flags/cs.png
similarity index 100%
rename from www.i2p2/static/images/cz.png
rename to i2p2www/static/images/flags/cs.png
diff --git a/www.i2p2/static/images/de.png b/i2p2www/static/images/flags/de.png
similarity index 100%
rename from www.i2p2/static/images/de.png
rename to i2p2www/static/images/flags/de.png
diff --git a/www.i2p2/static/images/el.png b/i2p2www/static/images/flags/el.png
similarity index 100%
rename from www.i2p2/static/images/el.png
rename to i2p2www/static/images/flags/el.png
diff --git a/www.i2p2/static/images/us.png b/i2p2www/static/images/flags/en.png
similarity index 100%
rename from www.i2p2/static/images/us.png
rename to i2p2www/static/images/flags/en.png
diff --git a/www.i2p2/static/images/es.png b/i2p2www/static/images/flags/es.png
similarity index 100%
rename from www.i2p2/static/images/es.png
rename to i2p2www/static/images/flags/es.png
diff --git a/www.i2p2/static/images/eu.png b/i2p2www/static/images/flags/eu.png
similarity index 100%
rename from www.i2p2/static/images/eu.png
rename to i2p2www/static/images/flags/eu.png
diff --git a/www.i2p2/static/images/fr.png b/i2p2www/static/images/flags/fr.png
similarity index 100%
rename from www.i2p2/static/images/fr.png
rename to i2p2www/static/images/flags/fr.png
diff --git a/www.i2p2/static/images/it.png b/i2p2www/static/images/flags/it.png
similarity index 100%
rename from www.i2p2/static/images/it.png
rename to i2p2www/static/images/flags/it.png
diff --git a/i2p2www/static/images/flags/lu.png b/i2p2www/static/images/flags/lu.png
new file mode 100644
index 00000000..4cabba98
Binary files /dev/null and b/i2p2www/static/images/flags/lu.png differ
diff --git a/www.i2p2/static/images/nl.png b/i2p2www/static/images/flags/nl.png
similarity index 100%
rename from www.i2p2/static/images/nl.png
rename to i2p2www/static/images/flags/nl.png
diff --git a/www.i2p2/static/images/ru.png b/i2p2www/static/images/flags/ru.png
similarity index 100%
rename from www.i2p2/static/images/ru.png
rename to i2p2www/static/images/flags/ru.png
diff --git a/i2p2www/static/images/flags/sv.png b/i2p2www/static/images/flags/sv.png
new file mode 100644
index 00000000..1994653d
Binary files /dev/null and b/i2p2www/static/images/flags/sv.png differ
diff --git a/i2p2www/static/images/flags/us.png b/i2p2www/static/images/flags/us.png
new file mode 100644
index 00000000..10f451fe
Binary files /dev/null and b/i2p2www/static/images/flags/us.png differ
diff --git a/www.i2p2/static/images/zh.png b/i2p2www/static/images/flags/zh.png
similarity index 100%
rename from www.i2p2/static/images/zh.png
rename to i2p2www/static/images/flags/zh.png
diff --git a/www.i2p2/static/images/garliccloves.png b/i2p2www/static/images/garliccloves.png
similarity index 100%
rename from www.i2p2/static/images/garliccloves.png
rename to i2p2www/static/images/garliccloves.png
diff --git a/www.i2p2/static/images/help.png b/i2p2www/static/images/help.png
similarity index 100%
rename from www.i2p2/static/images/help.png
rename to i2p2www/static/images/help.png
diff --git a/www.i2p2/static/images/help_dark.png b/i2p2www/static/images/help_dark.png
similarity index 100%
rename from www.i2p2/static/images/help_dark.png
rename to i2p2www/static/images/help_dark.png
diff --git a/mirror.i2p2/static/images/i2plogo.png b/i2p2www/static/images/i2plogo.png
similarity index 100%
rename from mirror.i2p2/static/images/i2plogo.png
rename to i2p2www/static/images/i2plogo.png
diff --git a/www.i2p2/static/images/i2ptunnel_peertopeer.png b/i2p2www/static/images/i2ptunnel_peertopeer.png
similarity index 100%
rename from www.i2p2/static/images/i2ptunnel_peertopeer.png
rename to i2p2www/static/images/i2ptunnel_peertopeer.png
diff --git a/www.i2p2/static/images/i2ptunnel_serverclient.png b/i2p2www/static/images/i2ptunnel_serverclient.png
similarity index 100%
rename from www.i2p2/static/images/i2ptunnel_serverclient.png
rename to i2p2www/static/images/i2ptunnel_serverclient.png
diff --git a/www.i2p2/static/images/i2pvstor_zh.png b/i2p2www/static/images/i2pvstor_zh.png
similarity index 100%
rename from www.i2p2/static/images/i2pvstor_zh.png
rename to i2p2www/static/images/i2pvstor_zh.png
diff --git a/www.i2p2/static/images/ie.options.jpg b/i2p2www/static/images/ie.options.jpg
similarity index 100%
rename from www.i2p2/static/images/ie.options.jpg
rename to i2p2www/static/images/ie.options.jpg
diff --git a/www.i2p2/static/images/ie.options_fr.png b/i2p2www/static/images/ie.options_fr.png
similarity index 100%
rename from www.i2p2/static/images/ie.options_fr.png
rename to i2p2www/static/images/ie.options_fr.png
diff --git a/www.i2p2/static/images/ie.proxyports.jpg b/i2p2www/static/images/ie.proxyports.jpg
similarity index 100%
rename from www.i2p2/static/images/ie.proxyports.jpg
rename to i2p2www/static/images/ie.proxyports.jpg
diff --git a/www.i2p2/static/images/ie.proxyports_fr.png b/i2p2www/static/images/ie.proxyports_fr.png
similarity index 100%
rename from www.i2p2/static/images/ie.proxyports_fr.png
rename to i2p2www/static/images/ie.proxyports_fr.png
diff --git a/www.i2p2/static/images/info.png b/i2p2www/static/images/info.png
similarity index 100%
rename from www.i2p2/static/images/info.png
rename to i2p2www/static/images/info.png
diff --git a/www.i2p2/static/images/info_dark.png b/i2p2www/static/images/info_dark.png
similarity index 100%
rename from www.i2p2/static/images/info_dark.png
rename to i2p2www/static/images/info_dark.png
diff --git a/www.i2p2/static/images/itoopie.png b/i2p2www/static/images/itoopie.png
similarity index 100%
rename from www.i2p2/static/images/itoopie.png
rename to i2p2www/static/images/itoopie.png
diff --git a/www.i2p2/static/images/konqueror.options.jpg b/i2p2www/static/images/konqueror.options.jpg
similarity index 100%
rename from www.i2p2/static/images/konqueror.options.jpg
rename to i2p2www/static/images/konqueror.options.jpg
diff --git a/www.i2p2/static/images/konqueror.options_fr.jpg b/i2p2www/static/images/konqueror.options_fr.jpg
similarity index 100%
rename from www.i2p2/static/images/konqueror.options_fr.jpg
rename to i2p2www/static/images/konqueror.options_fr.jpg
diff --git a/www.i2p2/static/images/konqueror.proxyports.jpg b/i2p2www/static/images/konqueror.proxyports.jpg
similarity index 100%
rename from www.i2p2/static/images/konqueror.proxyports.jpg
rename to i2p2www/static/images/konqueror.proxyports.jpg
diff --git a/www.i2p2/static/images/konqueror.proxyports_fr.jpg b/i2p2www/static/images/konqueror.proxyports_fr.jpg
similarity index 100%
rename from www.i2p2/static/images/konqueror.proxyports_fr.jpg
rename to i2p2www/static/images/konqueror.proxyports_fr.jpg
diff --git a/www.i2p2/static/images/light.png b/i2p2www/static/images/light.png
similarity index 100%
rename from www.i2p2/static/images/light.png
rename to i2p2www/static/images/light.png
diff --git a/www.i2p2/static/images/lightbluetile.png b/i2p2www/static/images/lightbluetile.png
similarity index 100%
rename from www.i2p2/static/images/lightbluetile.png
rename to i2p2www/static/images/lightbluetile.png
diff --git a/www.i2p2/static/images/link.png b/i2p2www/static/images/link.png
similarity index 100%
rename from www.i2p2/static/images/link.png
rename to i2p2www/static/images/link.png
diff --git a/www.i2p2/static/images/link_dark.png b/i2p2www/static/images/link_dark.png
similarity index 100%
rename from www.i2p2/static/images/link_dark.png
rename to i2p2www/static/images/link_dark.png
diff --git a/www.i2p2/static/images/logo07c.jpg b/i2p2www/static/images/logo07c.jpg
similarity index 100%
rename from www.i2p2/static/images/logo07c.jpg
rename to i2p2www/static/images/logo07c.jpg
diff --git a/www.i2p2/static/images/net.png b/i2p2www/static/images/net.png
similarity index 100%
rename from www.i2p2/static/images/net.png
rename to i2p2www/static/images/net.png
diff --git a/www.i2p2/static/images/net_fr.png b/i2p2www/static/images/net_fr.png
similarity index 100%
rename from www.i2p2/static/images/net_fr.png
rename to i2p2www/static/images/net_fr.png
diff --git a/www.i2p2/static/images/netdb_get_leaseset.png b/i2p2www/static/images/netdb_get_leaseset.png
similarity index 100%
rename from www.i2p2/static/images/netdb_get_leaseset.png
rename to i2p2www/static/images/netdb_get_leaseset.png
diff --git a/www.i2p2/static/images/netdb_get_leaseset_fr.png b/i2p2www/static/images/netdb_get_leaseset_fr.png
similarity index 100%
rename from www.i2p2/static/images/netdb_get_leaseset_fr.png
rename to i2p2www/static/images/netdb_get_leaseset_fr.png
diff --git a/www.i2p2/static/images/netdb_get_routerinfo_1.png b/i2p2www/static/images/netdb_get_routerinfo_1.png
similarity index 100%
rename from www.i2p2/static/images/netdb_get_routerinfo_1.png
rename to i2p2www/static/images/netdb_get_routerinfo_1.png
diff --git a/www.i2p2/static/images/netdb_get_routerinfo_1_fr.png b/i2p2www/static/images/netdb_get_routerinfo_1_fr.png
similarity index 100%
rename from www.i2p2/static/images/netdb_get_routerinfo_1_fr.png
rename to i2p2www/static/images/netdb_get_routerinfo_1_fr.png
diff --git a/www.i2p2/static/images/netdb_get_routerinfo_2.png b/i2p2www/static/images/netdb_get_routerinfo_2.png
similarity index 100%
rename from www.i2p2/static/images/netdb_get_routerinfo_2.png
rename to i2p2www/static/images/netdb_get_routerinfo_2.png
diff --git a/www.i2p2/static/images/netdb_get_routerinfo_2_fr.png b/i2p2www/static/images/netdb_get_routerinfo_2_fr.png
similarity index 100%
rename from www.i2p2/static/images/netdb_get_routerinfo_2_fr.png
rename to i2p2www/static/images/netdb_get_routerinfo_2_fr.png
diff --git a/www.i2p2/static/images/plan.png b/i2p2www/static/images/plan.png
similarity index 100%
rename from www.i2p2/static/images/plan.png
rename to i2p2www/static/images/plan.png
diff --git a/www.i2p2/static/images/protocol_stack.png b/i2p2www/static/images/protocol_stack.png
similarity index 100%
rename from www.i2p2/static/images/protocol_stack.png
rename to i2p2www/static/images/protocol_stack.png
diff --git a/www.i2p2/static/images/protocol_stack_fr.png b/i2p2www/static/images/protocol_stack_fr.png
similarity index 100%
rename from www.i2p2/static/images/protocol_stack_fr.png
rename to i2p2www/static/images/protocol_stack_fr.png
diff --git a/www.i2p2/static/images/sqbullet.png b/i2p2www/static/images/sqbullet.png
similarity index 100%
rename from www.i2p2/static/images/sqbullet.png
rename to i2p2www/static/images/sqbullet.png
diff --git a/www.i2p2/static/images/stackoverflow_ad.png b/i2p2www/static/images/stackoverflow_ad.png
similarity index 100%
rename from www.i2p2/static/images/stackoverflow_ad.png
rename to i2p2www/static/images/stackoverflow_ad.png
diff --git a/www.i2p2/static/images/tabletile.png b/i2p2www/static/images/tabletile.png
similarity index 100%
rename from www.i2p2/static/images/tabletile.png
rename to i2p2www/static/images/tabletile.png
diff --git a/www.i2p2/static/images/tabletile_alt.png b/i2p2www/static/images/tabletile_alt.png
similarity index 100%
rename from www.i2p2/static/images/tabletile_alt.png
rename to i2p2www/static/images/tabletile_alt.png
diff --git a/www.i2p2/static/images/tabletitledark.png b/i2p2www/static/images/tabletitledark.png
similarity index 100%
rename from www.i2p2/static/images/tabletitledark.png
rename to i2p2www/static/images/tabletitledark.png
diff --git a/www.i2p2/static/images/tabletitlelight-tall.png b/i2p2www/static/images/tabletitlelight-tall.png
similarity index 100%
rename from www.i2p2/static/images/tabletitlelight-tall.png
rename to i2p2www/static/images/tabletitlelight-tall.png
diff --git a/www.i2p2/static/images/tabletitlelight.png b/i2p2www/static/images/tabletitlelight.png
similarity index 100%
rename from www.i2p2/static/images/tabletitlelight.png
rename to i2p2www/static/images/tabletitlelight.png
diff --git a/www.i2p2/static/images/target.png b/i2p2www/static/images/target.png
similarity index 100%
rename from www.i2p2/static/images/target.png
rename to i2p2www/static/images/target.png
diff --git a/www.i2p2/static/images/tunnelSending.png b/i2p2www/static/images/tunnelSending.png
similarity index 100%
rename from www.i2p2/static/images/tunnelSending.png
rename to i2p2www/static/images/tunnelSending.png
diff --git a/www.i2p2/static/images/tunnels.png b/i2p2www/static/images/tunnels.png
similarity index 100%
rename from www.i2p2/static/images/tunnels.png
rename to i2p2www/static/images/tunnels.png
diff --git a/www.i2p2/static/images/tunnels_fr.png b/i2p2www/static/images/tunnels_fr.png
similarity index 100%
rename from www.i2p2/static/images/tunnels_fr.png
rename to i2p2www/static/images/tunnels_fr.png
diff --git a/www.i2p2/static/images/udp.png b/i2p2www/static/images/udp.png
similarity index 100%
rename from www.i2p2/static/images/udp.png
rename to i2p2www/static/images/udp.png
diff --git a/www.i2p2/static/news/news.xml b/i2p2www/static/news/news.xml
similarity index 100%
rename from www.i2p2/static/news/news.xml
rename to i2p2www/static/news/news.xml
diff --git a/www.i2p2/static/pdf/I2CP_spec.pdf b/i2p2www/static/pdf/I2CP_spec.pdf
similarity index 100%
rename from www.i2p2/static/pdf/I2CP_spec.pdf
rename to i2p2www/static/pdf/I2CP_spec.pdf
diff --git a/www.i2p2/static/pdf/I2NP_spec.pdf b/i2p2www/static/pdf/I2NP_spec.pdf
similarity index 100%
rename from www.i2p2/static/pdf/I2NP_spec.pdf
rename to i2p2www/static/pdf/I2NP_spec.pdf
diff --git a/www.i2p2/static/pdf/I2P-PET-CON-2009.1.pdf b/i2p2www/static/pdf/I2P-PET-CON-2009.1.pdf
similarity index 100%
rename from www.i2p2/static/pdf/I2P-PET-CON-2009.1.pdf
rename to i2p2www/static/pdf/I2P-PET-CON-2009.1.pdf
diff --git a/www.i2p2/static/pdf/datastructures.pdf b/i2p2www/static/pdf/datastructures.pdf
similarity index 100%
rename from www.i2p2/static/pdf/datastructures.pdf
rename to i2p2www/static/pdf/datastructures.pdf
diff --git a/www.i2p2/static/pdf/i2p_philosophy.pdf b/i2p2www/static/pdf/i2p_philosophy.pdf
similarity index 100%
rename from www.i2p2/static/pdf/i2p_philosophy.pdf
rename to i2p2www/static/pdf/i2p_philosophy.pdf
diff --git a/www.i2p2/static/pdf/polling_http_transport.pdf b/i2p2www/static/pdf/polling_http_transport.pdf
similarity index 100%
rename from www.i2p2/static/pdf/polling_http_transport.pdf
rename to i2p2www/static/pdf/polling_http_transport.pdf
diff --git a/i2p2www/static/robots.txt b/i2p2www/static/robots.txt
new file mode 100644
index 00000000..2c16e0e7
--- /dev/null
+++ b/i2p2www/static/robots.txt
@@ -0,0 +1,12 @@
+# Disallow auto-generated index pages
+User-agent: *
+Disallow: /*/blog/$
+
+User-agent: *
+Disallow: /*/blog/page/
+
+User-agent: *
+Disallow: /*/meetings/$
+
+User-agent: *
+Disallow: /*/meetings/page/
diff --git a/i2p2www/static/styles/danimoth/default.css b/i2p2www/static/styles/danimoth/default.css
new file mode 100644
index 00000000..e69de29b
diff --git a/i2p2www/static/styles/danimoth/desktop.css b/i2p2www/static/styles/danimoth/desktop.css
new file mode 100644
index 00000000..338d416a
--- /dev/null
+++ b/i2p2www/static/styles/danimoth/desktop.css
@@ -0,0 +1,2536 @@
+html {
+margin:0;
+padding:0;
+}
+
+body {
+    margin: 0;
+    /*padding-top: 70px;*/
+}
+
+.news {
+    font-size: 11px;
+}
+
+.news li {
+    list-style: none;
+    margin: 0 -25px;
+}
+
+div#cssmenu div.menuitem {
+    display: inline;
+}
+
+div#cssmenu > ul > li {
+    list-style: none;
+    margin: 0 -25px;
+}
+
+div#cssmenu > ul > li > div.menuitem {
+    font-size: 14px;
+    line-height: 36px;
+}
+
+div#cssmenu .right {
+    display: none;
+}
+
+nav.navigation {
+    position: absolute;
+    margin: 13px 0 20px 20px;
+    padding-top: 10px;
+    padding-bottom: 0;
+    width: 180px;
+    z-index: 1;
+}
+
+div#content .feed-icon {
+    background-image: url('../../images/feed-icon-28x28.png');
+    display: block;
+    float: right;
+    height: 28px;
+    margin: 4px 10px;
+    text-indent: -9999px;
+    width: 28px;
+}
+
+h1,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,address,cite,code,del,dfn,em,img,q,s,samp,small,strike,strong,sub,sup,tt,var,dd,dl,dt,li,ol,ul,fieldset,form,label,legend,button,table,caption,tbody,tfoot,thead,tr,th,td {
+margin:0;
+padding:0;
+border:0;
+font-weight:normal;
+font-style:normal;
+font-size:100%;
+line-height:1;
+font-family:inherit;
+}
+
+table {
+border-collapse:collapse;
+border-spacing:0;
+}
+
+ol,ul {
+list-style:none;
+}
+
+q:before,q:after,blockquote:before,blockquote:after {
+content:"";
+}
+
+html {
+overflow-y:scroll;
+font-size:100%;
+-webkit-text-size-adjust:100%;
+-ms-text-size-adjust:100%;
+}
+
+a:focus {
+outline:thin dotted;
+}
+
+a:hover,a:active {
+outline:0;
+}
+
+article,aside,details,figcaption,figure,footer,header,hgroup,nav,section {
+display:block;
+}
+
+audio,canvas,video {
+display:inline-block;
+*display:inline;
+*zoom:1;
+}
+
+audio:not([controls]) {
+display:none;
+}
+
+sub,sup {
+font-size:75%;
+line-height:0;
+position:relative;
+vertical-align:baseline;
+}
+
+sup {
+top:-0.5em;
+}
+
+sub {
+bottom:-0.25em;
+}
+
+img {
+border:0;
+-ms-interpolation-mode:bicubic;
+}
+
+button,input,select,textarea {
+font-size:100%;
+margin:0;
+vertical-align:baseline;
+*vertical-align:middle;
+}
+
+button,input {
+line-height:normal;
+*overflow:visible;
+}
+
+button::-moz-focus-inner,input::-moz-focus-inner {
+border:0;
+padding:0;
+}
+
+button,input[type="button"],input[type="reset"],input[type="submit"] {
+cursor:pointer;
+-webkit-appearance:button;
+}
+
+input[type="search"] {
+-webkit-appearance:textfield;
+-webkit-box-sizing:content-box;
+-moz-box-sizing:content-box;
+box-sizing:content-box;
+}
+
+input[type="search"]::-webkit-search-decoration {
+-webkit-appearance:none;
+}
+
+textarea {
+overflow:auto;
+vertical-align:top;
+}
+
+html,body {
+background-color:#ffffff;
+}
+
+body {
+margin:0;
+font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;
+font-size:13px;
+font-weight:normal;
+line-height:18px;
+color:#404040;
+}
+
+.container {
+width:940px;
+margin-left:auto;
+margin-right:auto;
+zoom:1;
+}
+.container:before,.container:after {
+display:table;
+content:"";
+zoom:1;
+*display:inline;
+}
+
+.container:after {
+clear:both;
+}
+
+.container-fluid {
+position:relative;
+min-width:660px;
+/*padding-left:20px;
+padding-right:20px;
+padding-top: 13px;*/
+zoom:1;
+margin: 13px 20px 20px 260px;
+}
+.container-fluid:before,.container-fluid:after {
+display:table;
+content:"";
+zoom:1;
+*display:inline;
+}
+
+.container-fluid:after {
+clear:both;
+}
+
+.container-fluid> aside {
+float:left;
+width:220px;
+}
+
+/*
+.container-fluid>.content {
+margin-left:240px;
+}
+*/
+
+a {
+color:#0069d6;
+text-decoration:none;
+line-height:inherit;
+font-weight:inherit;
+}
+a:hover {
+color:#00438a;
+text-decoration:underline;
+}
+
+div#topbar .title {
+float: right;
+padding: 0 20px;
+}
+
+.pull-left {
+float:left;
+}
+
+.hide {
+display:none;
+}
+
+.show {
+display:block;
+}
+
+.row, .aside-wrap {
+zoom:1;
+/*margin-left:-20px;*/
+}
+.row:before,.row:after, .aside-wrap:before, .aside-wrap:after {
+display:table;
+content:"";
+zoom:1;
+*display:inline;
+}
+
+.row:after, .aside-wrap:after {
+clear:both;
+}
+
+[class*="span"], .aside {
+display:inline;
+float:left;
+margin-left:20px;
+}
+
+.span1 {
+width:40px;
+}
+
+.span2 {
+width:100px;
+}
+
+.span3 {
+width:160px;
+}
+
+.span4 {
+width:220px;
+}
+
+.span5 {
+width:280px;
+}
+
+.span6 {
+width:340px;
+}
+
+.span7 {
+width:400px;
+}
+
+.span8 {
+width:460px;
+}
+
+.span9 {
+width:520px;
+}
+
+.span10 {
+width:580px;
+}
+
+.span11 {
+width:640px;
+}
+
+.span12 {
+width:700px;
+}
+
+.span13 {
+width:760px;
+}
+
+.span14 {
+width:820px;
+}
+
+.span15 {
+width:880px;
+}
+
+.span16 {
+width:940px;
+}
+
+.span17 {
+width:1000px;
+}
+
+.span18 {
+width:1060px;
+}
+
+.span19 {
+width:1120px;
+}
+
+.span20 {
+width:1180px;
+}
+
+.span21 {
+width:1240px;
+}
+
+.span22 {
+width:1300px;
+}
+
+.span23 {
+width:1360px;
+}
+
+.span24 {
+width:1420px;
+}
+
+.offset1 {
+margin-left:80px;
+}
+
+.offset2 {
+margin-left:140px;
+}
+
+.offset3 {
+margin-left:200px;
+}
+
+.offset4 {
+margin-left:260px;
+}
+
+.offset5 {
+margin-left:320px;
+}
+
+.offset6 {
+margin-left:380px;
+}
+
+.offset7 {
+margin-left:440px;
+}
+
+.offset8 {
+margin-left:500px;
+}
+
+.offset9 {
+margin-left:560px;
+}
+
+.offset10 {
+margin-left:620px;
+}
+
+.offset11 {
+margin-left:680px;
+}
+
+.offset12 {
+margin-left:740px;
+}
+
+.span-one-third, .aside-wrap .aside {
+width:300px;
+}
+
+.span-two-thirds {
+width:620px;
+}
+
+.offset-one-third {
+margin-left:340px;
+}
+
+.offset-two-thirds {
+margin-left:660px;
+}
+
+p {
+font-size:13px;
+font-weight:normal;
+line-height:18px;
+margin-bottom:9px;
+}
+p small {
+font-size:11px;
+color:#bfbfbf;
+}
+
+h1,h2,h3,h4,h5,h6 {
+font-weight:bold;
+color:#404040;
+}
+h1 small,h2 small,h3 small,h4 small,h5 small,h6 small {
+color:#bfbfbf;
+}
+
+h1 {
+margin-bottom:18px;
+font-size:30px;
+line-height:36px;
+}
+h1 small {
+font-size:18px;
+}
+
+h2 {
+font-size:24px;
+line-height:36px;
+}
+h2 small {
+font-size:14px;
+}
+
+h3,h4,h5,h6 {
+line-height:36px;
+}
+
+h3 {
+font-size:18px;
+}
+h3 small {
+font-size:14px;
+}
+
+h4 {
+font-size:16px;
+}
+h4 small {
+font-size:12px;
+}
+
+h5 {
+font-size:14px;
+}
+
+h6 {
+font-size:13px;
+color:#bfbfbf;
+text-transform:uppercase;
+}
+
+ul,ol {
+margin:0 0 18px 25px;
+}
+
+ul ul,ul ol,ol ol,ol ul {
+margin-bottom:0;
+}
+
+ul {
+list-style:disc;
+}
+
+ol {
+list-style:decimal;
+}
+
+li {
+line-height:18px;
+color:#808080;
+}
+
+ul.unstyled {
+list-style:none;
+margin-left:0;
+}
+
+dl {
+margin-bottom:18px;
+}
+dl dt,dl dd {
+line-height:18px;
+}
+
+dl dt {
+font-weight:bold;
+}
+
+dl dd {
+margin-left:9px;
+}
+
+hr {
+margin:20px 0 19px;
+border:0;
+border-bottom:1px solid #eee;
+}
+
+strong {
+font-style:inherit;
+font-weight:bold;
+}
+
+em {
+font-style:italic;
+font-weight:inherit;
+line-height:inherit;
+}
+
+.muted {
+color:#bfbfbf;
+}
+
+blockquote {
+margin-bottom:18px;
+border-left:5px solid #eee;
+padding-left:15px;
+}
+blockquote p {
+font-size:14px;
+font-weight:300;
+line-height:18px;
+margin-bottom:0;
+}
+
+blockquote small {
+display:block;
+font-size:12px;
+font-weight:300;
+line-height:18px;
+color:#bfbfbf;
+}
+blockquote small:before {
+content:'\2014 \00A0';
+}
+
+address {
+display:block;
+line-height:18px;
+margin-bottom:18px;
+}
+
+code,pre {
+padding:0 3px 2px;
+font-family:Monaco, Andale Mono, Courier New, monospace;
+font-size:12px;
+-webkit-border-radius:3px;
+-moz-border-radius:3px;
+border-radius:3px;
+}
+
+code {
+background-color:#fee9cc;
+color:rgba(0, 0, 0, 0.75);
+padding:1px 3px;
+}
+
+pre {
+background-color:#f5f5f5;
+display:block;
+padding:8.5px;
+margin:0 0 18px;
+line-height:18px;
+font-size:12px;
+border:1px solid #ccc;
+border:1px solid rgba(0, 0, 0, 0.15);
+-webkit-border-radius:3px;
+-moz-border-radius:3px;
+border-radius:3px;
+white-space:pre;
+white-space:pre-wrap;
+word-wrap:break-word;
+}
+
+form {
+margin-bottom:18px;
+}
+
+fieldset {
+margin-bottom:18px;
+padding-top:18px;
+}
+fieldset legend {
+display:block;
+padding-left:150px;
+font-size:19.5px;
+line-height:1;
+color:#404040;
+*padding:0 0 5px 145px;
+*line-height:1.5;
+}
+
+form .clearfix {
+margin-bottom:18px;
+zoom:1;
+}
+form .clearfix:before,form .clearfix:after {
+display:table;
+content:"";
+zoom:1;
+*display:inline;
+}
+
+form .clearfix:after {
+clear:both;
+}
+
+label,input,select,textarea {
+font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;
+font-size:13px;
+font-weight:normal;
+line-height:normal;
+}
+
+label {
+padding-top:6px;
+font-size:13px;
+line-height:18px;
+float:left;
+width:130px;
+text-align:right;
+color:#404040;
+}
+
+form .input {
+margin-left:150px;
+}
+
+input[type=checkbox],input[type=radio] {
+cursor:pointer;
+}
+
+input,textarea,select,.uneditable-input {
+display:inline-block;
+width:210px;
+height:18px;
+padding:4px;
+font-size:13px;
+line-height:18px;
+color:#808080;
+border:1px solid #ccc;
+-webkit-border-radius:3px;
+-moz-border-radius:3px;
+border-radius:3px;
+}
+
+input[type=checkbox],input[type=radio] {
+width:auto;
+height:auto;
+padding:0;
+margin:3px 0;
+*margin-top:0;
+line-height:normal;
+border:none;
+}
+
+input[type=file] {
+background-color:#ffffff;
+padding:initial;
+border:initial;
+line-height:initial;
+-webkit-box-shadow:none;
+-moz-box-shadow:none;
+box-shadow:none;
+}
+
+input[type=button],input[type=reset],input[type=submit] {
+width:auto;
+height:auto;
+}
+
+select,input[type=file] {
+height:27px;
+line-height:27px;
+*margin-top:4px;
+}
+
+select[multiple] {
+height:inherit;
+}
+
+textarea {
+height:auto;
+}
+
+.uneditable-input {
+background-color:#ffffff;
+display:block;
+border-color:#eee;
+-webkit-box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.025);
+-moz-box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.025);
+box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.025);
+cursor:not-allowed;
+}
+
+:-moz-placeholder {
+color:#bfbfbf;
+}
+
+::-webkit-input-placeholder {
+color:#bfbfbf;
+}
+
+input,textarea {
+-webkit-transition:border linear 0.2s,box-shadow linear 0.2s;
+-moz-transition:border linear 0.2s,box-shadow linear 0.2s;
+-ms-transition:border linear 0.2s,box-shadow linear 0.2s;
+-o-transition:border linear 0.2s,box-shadow linear 0.2s;
+transition:border linear 0.2s,box-shadow linear 0.2s;
+-webkit-box-shadow:inset 0 1px 3px rgba(0, 0, 0, 0.1);
+-moz-box-shadow:inset 0 1px 3px rgba(0, 0, 0, 0.1);
+box-shadow:inset 0 1px 3px rgba(0, 0, 0, 0.1);
+}
+
+input:focus,textarea:focus {
+outline:0;
+border-color:rgba(82, 168, 236, 0.8);
+-webkit-box-shadow:inset 0 1px 3px rgba(0, 0, 0, 0.1),0 0 8px rgba(82, 168, 236, 0.6);
+-moz-box-shadow:inset 0 1px 3px rgba(0, 0, 0, 0.1),0 0 8px rgba(82, 168, 236, 0.6);
+box-shadow:inset 0 1px 3px rgba(0, 0, 0, 0.1),0 0 8px rgba(82, 168, 236, 0.6);
+}
+
+input[type=file]:focus,input[type=checkbox]:focus,select:focus {
+-webkit-box-shadow:none;
+-moz-box-shadow:none;
+box-shadow:none;
+outline:1px dotted #666;
+}
+
+form div.clearfix.error {
+background:#fae5e3;
+padding:10px 0;
+margin:-10px 0 10px;
+-webkit-border-radius:4px;
+-moz-border-radius:4px;
+border-radius:4px;
+}
+form div.clearfix.error>label,form div.clearfix.error span.help-inline,form div.clearfix.error span.help-block {
+color:#9d261d;
+}
+
+form div.clearfix.error input,form div.clearfix.error textarea {
+border-color:#c87872;
+-webkit-box-shadow:0 0 3px rgba(171, 41, 32, 0.25);
+-moz-box-shadow:0 0 3px rgba(171, 41, 32, 0.25);
+box-shadow:0 0 3px rgba(171, 41, 32, 0.25);
+}
+form div.clearfix.error input:focus,form div.clearfix.error textarea:focus {
+border-color:#b9554d;
+-webkit-box-shadow:0 0 6px rgba(171, 41, 32, 0.5);
+-moz-box-shadow:0 0 6px rgba(171, 41, 32, 0.5);
+box-shadow:0 0 6px rgba(171, 41, 32, 0.5);
+}
+
+form div.clearfix.error .input-prepend span.add-on,form div.clearfix.error .input-append span.add-on {
+background:#f4c8c5;
+border-color:#c87872;
+color:#b9554d;
+}
+
+.input-mini,input.mini,textarea.mini,select.mini {
+width:60px;
+}
+
+.input-small,input.small,textarea.small,select.small {
+width:90px;
+}
+
+.input-medium,input.medium,textarea.medium,select.medium {
+width:150px;
+}
+
+.input-large,input.large,textarea.large,select.large {
+width:210px;
+}
+
+.input-xlarge,input.xlarge,textarea.xlarge,select.xlarge {
+width:270px;
+}
+
+.input-xxlarge,input.xxlarge,textarea.xxlarge,select.xxlarge {
+width:530px;
+}
+
+textarea.xxlarge {
+overflow-y:auto;
+}
+
+input.span1,textarea.span1,select.span1 {
+display:inline-block;
+float:none;
+width:30px;
+margin-left:0;
+}
+
+input.span2,textarea.span2,select.span2 {
+display:inline-block;
+float:none;
+width:90px;
+margin-left:0;
+}
+
+input.span3,textarea.span3,select.span3 {
+display:inline-block;
+float:none;
+width:150px;
+margin-left:0;
+}
+
+input.span4,textarea.span4,select.span4 {
+display:inline-block;
+float:none;
+width:210px;
+margin-left:0;
+}
+
+input.span5,textarea.span5,select.span5 {
+display:inline-block;
+float:none;
+width:270px;
+margin-left:0;
+}
+
+input.span6,textarea.span6,select.span6 {
+display:inline-block;
+float:none;
+width:330px;
+margin-left:0;
+}
+
+input.span7,textarea.span7,select.span7 {
+display:inline-block;
+float:none;
+width:390px;
+margin-left:0;
+}
+
+input.span8,textarea.span8,select.span8 {
+display:inline-block;
+float:none;
+width:450px;
+margin-left:0;
+}
+
+input.span9,textarea.span9,select.span9 {
+display:inline-block;
+float:none;
+width:510px;
+margin-left:0;
+}
+
+input.span10,textarea.span10,select.span10 {
+display:inline-block;
+float:none;
+width:570px;
+margin-left:0;
+}
+
+input.span11,textarea.span11,select.span11 {
+display:inline-block;
+float:none;
+width:630px;
+margin-left:0;
+}
+
+input.span12,textarea.span12,select.span12 {
+display:inline-block;
+float:none;
+width:690px;
+margin-left:0;
+}
+
+input.span13,textarea.span13,select.span13 {
+display:inline-block;
+float:none;
+width:750px;
+margin-left:0;
+}
+
+input.span14,textarea.span14,select.span14 {
+display:inline-block;
+float:none;
+width:810px;
+margin-left:0;
+}
+
+input.span15,textarea.span15,select.span15 {
+display:inline-block;
+float:none;
+width:870px;
+margin-left:0;
+}
+
+input.span16,textarea.span16,select.span16 {
+display:inline-block;
+float:none;
+width:930px;
+margin-left:0;
+}
+
+input[disabled],select[disabled],textarea[disabled],input[readonly],select[readonly],textarea[readonly] {
+background-color:#f5f5f5;
+border-color:#ddd;
+cursor:not-allowed;
+}
+
+.actions {
+background:#f5f5f5;
+margin-top:18px;
+margin-bottom:18px;
+padding:17px 20px 18px 150px;
+border-top:1px solid #ddd;
+-webkit-border-radius:0 0 3px 3px;
+-moz-border-radius:0 0 3px 3px;
+border-radius:0 0 3px 3px;
+}
+.actions .secondary-action {
+float:right;
+}
+.actions .secondary-action a {
+line-height:30px;
+}
+.actions .secondary-action a:hover {
+text-decoration:underline;
+}
+
+.help-inline,.help-block {
+font-size:11px;
+line-height:18px;
+color:#bfbfbf;
+}
+
+.help-inline {
+padding-left:5px;
+*position:relative;
+*top:-5px;
+}
+
+.help-block {
+display:block;
+max-width:600px;
+}
+
+.inline-inputs {
+color:#808080;
+}
+.inline-inputs span,.inline-inputs input {
+display:inline-block;
+}
+
+.inline-inputs input.mini {
+width:60px;
+}
+
+.inline-inputs input.small {
+width:90px;
+}
+
+.inline-inputs span {
+padding:0 2px 0 1px;
+}
+
+.input-prepend input,.input-append input {
+-webkit-border-radius:0 3px 3px 0;
+-moz-border-radius:0 3px 3px 0;
+border-radius:0 3px 3px 0;
+}
+
+.input-prepend .add-on,.input-append .add-on {
+position:relative;
+background:#f5f5f5;
+border:1px solid #ccc;
+z-index:2;
+float:left;
+display:block;
+width:auto;
+min-width:16px;
+height:18px;
+padding:4px 4px 4px 5px;
+margin-right:-1px;
+font-weight:normal;
+line-height:18px;
+color:#bfbfbf;
+text-align:center;
+text-shadow:0 1px 0 #ffffff;
+-webkit-border-radius:3px 0 0 3px;
+-moz-border-radius:3px 0 0 3px;
+border-radius:3px 0 0 3px;
+}
+
+.input-prepend .active,.input-append .active {
+background:#a9dba9;
+border-color:#46a546;
+}
+
+.input-prepend .add-on {
+*margin-top:1px;
+}
+
+.input-append input {
+float:left;
+-webkit-border-radius:3px 0 0 3px;
+-moz-border-radius:3px 0 0 3px;
+border-radius:3px 0 0 3px;
+}
+
+.input-append .add-on {
+-webkit-border-radius:0 3px 3px 0;
+-moz-border-radius:0 3px 3px 0;
+border-radius:0 3px 3px 0;
+margin-right:0;
+margin-left:-1px;
+}
+
+.inputs-list {
+margin:0 0 5px;
+width:100%;
+}
+.inputs-list li {
+display:block;
+padding:0;
+width:100%;
+}
+
+.inputs-list label {
+display:block;
+float:none;
+width:auto;
+padding:0;
+line-height:18px;
+text-align:left;
+white-space:normal;
+}
+.inputs-list label strong {
+color:#808080;
+}
+
+.inputs-list label small {
+font-size:11px;
+font-weight:normal;
+}
+
+.inputs-list .inputs-list {
+margin-left:25px;
+margin-bottom:10px;
+padding-top:0;
+}
+
+.inputs-list:first-child {
+padding-top:6px;
+}
+
+.inputs-list li+li {
+padding-top:2px;
+}
+
+.inputs-list input[type=radio],.inputs-list input[type=checkbox] {
+margin-bottom:0;
+}
+
+.form-stacked {
+padding-left:20px;
+}
+.form-stacked fieldset {
+padding-top:9px;
+}
+
+.form-stacked legend {
+padding-left:0;
+}
+
+.form-stacked label {
+display:block;
+float:none;
+width:auto;
+font-weight:bold;
+text-align:left;
+line-height:20px;
+padding-top:0;
+}
+
+.form-stacked .clearfix {
+margin-bottom:9px;
+}
+.form-stacked .clearfix div.input {
+margin-left:0;
+}
+
+.form-stacked .inputs-list {
+margin-bottom:0;
+}
+.form-stacked .inputs-list li {
+padding-top:0;
+}
+.form-stacked .inputs-list li label {
+font-weight:normal;
+padding-top:0;
+}
+
+.form-stacked div.clearfix.error {
+padding-top:10px;
+padding-bottom:10px;
+padding-left:10px;
+margin-top:0;
+margin-left:-10px;
+}
+
+.form-stacked .actions {
+margin-left:-20px;
+padding-left:20px;
+}
+
+table {
+width:100%;
+margin-bottom:18px;
+padding:0;
+border-collapse:separate;
+*border-collapse:collapse;
+font-size:13px;
+border:1px solid #ddd;
+-webkit-border-radius:4px;
+-moz-border-radius:4px;
+border-radius:4px;
+}
+table th,table td {
+padding:10px 10px 9px;
+line-height:18px;
+text-align:left;
+}
+
+table th {
+padding-top:9px;
+font-weight:bold;
+vertical-align:middle;
+border-bottom:1px solid #ddd;
+}
+
+table td {
+vertical-align:top;
+}
+
+table th+th,table td+td {
+border-left:1px solid #ddd;
+}
+
+table tr+tr td {
+border-top:1px solid #ddd;
+}
+
+table tbody tr:first-child td:first-child {
+-webkit-border-radius:4px 0 0 0;
+-moz-border-radius:4px 0 0 0;
+border-radius:4px 0 0 0;
+}
+
+table tbody tr:first-child td:last-child {
+-webkit-border-radius:0 4px 0 0;
+-moz-border-radius:0 4px 0 0;
+border-radius:0 4px 0 0;
+}
+
+table tbody tr:last-child td:first-child {
+-webkit-border-radius:0 0 0 4px;
+-moz-border-radius:0 0 0 4px;
+border-radius:0 0 0 4px;
+}
+
+table tbody tr:last-child td:last-child {
+-webkit-border-radius:0 0 4px 0;
+-moz-border-radius:0 0 4px 0;
+border-radius:0 0 4px 0;
+}
+
+.zebra-striped tbody tr:nth-child(odd) td {
+background-color:#f9f9f9;
+}
+
+.zebra-striped tbody tr:hover td {
+background-color:#f5f5f5;
+}
+
+.zebra-striped .header {
+cursor:pointer;
+}
+.zebra-striped .header:after {
+content:"";
+float:right;
+margin-top:7px;
+border-width:0 4px 4px;
+border-style:solid;
+border-color:#000 transparent;
+visibility:hidden;
+}
+
+.zebra-striped .headerSortUp,.zebra-striped .headerSortDown {
+background-color:rgba(141, 192, 219, 0.25);
+text-shadow:0 1px 1px rgba(255, 255, 255, 0.75);
+}
+
+.zebra-striped .header:hover:after {
+visibility:visible;
+}
+
+.zebra-striped .headerSortDown:after,.zebra-striped .headerSortDown:hover:after {
+visibility:visible;
+filter:alpha(opacity=60);
+-khtml-opacity:0.6;
+-moz-opacity:0.6;
+opacity:0.6;
+}
+
+.zebra-striped .headerSortUp:after {
+border-bottom:none;
+border-left:4px solid transparent;
+border-right:4px solid transparent;
+border-top:4px solid #000;
+visibility:visible;
+-webkit-box-shadow:none;
+-moz-box-shadow:none;
+box-shadow:none;
+filter:alpha(opacity=60);
+-khtml-opacity:0.6;
+-moz-opacity:0.6;
+opacity:0.6;
+}
+
+table .blue {
+color:#049cdb;
+border-bottom-color:#049cdb;
+}
+
+table .headerSortUp.blue,table .headerSortDown.blue {
+background-color:#ade6fe;
+}
+
+table .green {
+color:#46a546;
+border-bottom-color:#46a546;
+}
+
+table .headerSortUp.green,table .headerSortDown.green {
+background-color:#cdeacd;
+}
+
+table .red {
+color:#9d261d;
+border-bottom-color:#9d261d;
+}
+
+table .headerSortUp.red,table .headerSortDown.red {
+background-color:#f4c8c5;
+}
+
+table .yellow {
+color:#ffc40d;
+border-bottom-color:#ffc40d;
+}
+
+table .headerSortUp.yellow,table .headerSortDown.yellow {
+background-color:#fff6d9;
+}
+
+table .orange {
+color:#f89406;
+border-bottom-color:#f89406;
+}
+
+table .headerSortUp.orange,table .headerSortDown.orange {
+background-color:#fee9cc;
+}
+
+table .purple {
+color:#7a43b6;
+border-bottom-color:#7a43b6;
+}
+
+table .headerSortUp.purple,table .headerSortDown.purple {
+background-color:#e2d5f0;
+}
+
+#topbar {
+/*height:40px;
+position:fixed;
+top:0;
+left:0;
+right:0;*/
+z-index:10000;
+/*overflow:visible;*/
+overflow: hidden;
+min-width: 980px;
+background-color:#222222;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#333333), to(#222222));
+background-image:-moz-linear-gradient(top, #333333, #222222);
+background-image:-ms-linear-gradient(top, #333333, #222222);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #333333), color-stop(100%, #222222));
+background-image:-webkit-linear-gradient(top, #333333, #222222);
+background-image:-o-linear-gradient(top, #333333, #222222);
+background-image:linear-gradient(top, #333333, #222222);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#333333', endColorstr='#222222', GradientType=0);
+-webkit-box-shadow:0 1px 3px rgba(0, 0, 0, 0.25),inset 0 -1px 0 rgba(0, 0, 0, 0.1);
+-moz-box-shadow:0 1px 3px rgba(0, 0, 0, 0.25),inset 0 -1px 0 rgba(0, 0, 0, 0.1);
+box-shadow:0 1px 3px rgba(0, 0, 0, 0.25),inset 0 -1px 0 rgba(0, 0, 0, 0.1);
+}
+.topbar a {
+color:#bfbfbf;
+text-shadow:0 -1px 0 rgba(0, 0, 0, 0.25);
+}
+
+.topbar h3 a:hover,.topbar .brand a:hover,.topbar ul .active>a {
+background-color:#333;
+background-color:rgba(255, 255, 255, 0.05);
+color:#ffffff;
+text-decoration:none;
+}
+
+.topbar h3 {
+position:relative;
+}
+
+#topbar a#logo {
+float:left;
+display:block;
+padding:8px 20px 12px;
+/*margin-left:-20px;*/
+color:#ffffff;
+font-size:20px;
+font-weight:200;
+line-height:1;
+}
+
+#topbar .title h1 {
+    color: #bfbfbf;
+    font-size: 13px;
+    margin: 0;
+    text-transform: uppercase;
+}
+
+.topbar p {
+margin:0;
+line-height:40px;
+}
+.topbar p a:hover {
+background-color:transparent;
+color:#ffffff;
+}
+
+.topbar form {
+float:left;
+margin:5px 0 0 0;
+position:relative;
+filter:alpha(opacity=100);
+-khtml-opacity:1;
+-moz-opacity:1;
+opacity:1;
+}
+
+.topbar form.pull-right {
+float:right;
+}
+
+.topbar input {
+background-color:#444;
+background-color:rgba(255, 255, 255, 0.3);
+font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;
+font-size:normal;
+font-weight:13px;
+line-height:1;
+padding:4px 9px;
+color:#ffffff;
+color:rgba(255, 255, 255, 0.75);
+border:1px solid #111;
+-webkit-border-radius:4px;
+-moz-border-radius:4px;
+border-radius:4px;
+-webkit-box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.1),0 1px 0px rgba(255, 255, 255, 0.25);
+-moz-box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.1),0 1px 0px rgba(255, 255, 255, 0.25);
+box-shadow:inset 0 1px 2px rgba(0, 0, 0, 0.1),0 1px 0px rgba(255, 255, 255, 0.25);
+-webkit-transition:none;
+-moz-transition:none;
+-ms-transition:none;
+-o-transition:none;
+transition:none;
+}
+.topbar input:-moz-placeholder {
+color:#e6e6e6;
+}
+
+.topbar input::-webkit-input-placeholder {
+color:#e6e6e6;
+}
+
+.topbar input:hover {
+background-color:#bfbfbf;
+background-color:rgba(255, 255, 255, 0.5);
+color:#ffffff;
+}
+
+.topbar input:focus,.topbar input.focused {
+outline:0;
+background-color:#ffffff;
+color:#404040;
+text-shadow:0 1px 0 #ffffff;
+border:0;
+padding:5px 10px;
+-webkit-box-shadow:0 0 3px rgba(0, 0, 0, 0.15);
+-moz-box-shadow:0 0 3px rgba(0, 0, 0, 0.15);
+box-shadow:0 0 3px rgba(0, 0, 0, 0.15);
+}
+
+.topbar-inner,.topbar .fill {
+background-color:#222;
+background-color:#222222;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#333333), to(#222222));
+background-image:-moz-linear-gradient(top, #333333, #222222);
+background-image:-ms-linear-gradient(top, #333333, #222222);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #333333), color-stop(100%, #222222));
+background-image:-webkit-linear-gradient(top, #333333, #222222);
+background-image:-o-linear-gradient(top, #333333, #222222);
+background-image:linear-gradient(top, #333333, #222222);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#333333', endColorstr='#222222', GradientType=0);
+-webkit-box-shadow:0 1px 3px rgba(0, 0, 0, 0.25),inset 0 -1px 0 rgba(0, 0, 0, 0.1);
+-moz-box-shadow:0 1px 3px rgba(0, 0, 0, 0.25),inset 0 -1px 0 rgba(0, 0, 0, 0.1);
+box-shadow:0 1px 3px rgba(0, 0, 0, 0.25),inset 0 -1px 0 rgba(0, 0, 0, 0.1);
+}
+
+#topbar div>ul,.nav {
+display:block;
+float:left;
+margin:0 10px 0 0;
+position:relative;
+left:0;
+}
+#topbar div>ul>li,.nav>li {
+display:block;
+float:left;
+}
+
+#topbar div>ul a,.nav a {
+display:block;
+float:none;
+/*padding:10px 10px 11px;*/
+padding:0 2px;
+line-height:19px;
+text-decoration:none;
+}
+.topbar div>ul a:hover,.nav a:hover {
+color:#ffffff;
+text-decoration:none;
+}
+
+.topbar div>ul .active>a,.nav .active>a {
+background-color:#222;
+background-color:rgba(0, 0, 0, 0.5);
+}
+
+.topbar div>ul.secondary-nav,.nav.secondary-nav {
+float:right;
+margin-left:10px;
+margin-right:0;
+}
+.topbar div>ul.secondary-nav .menu-dropdown,.nav.secondary-nav .menu-dropdown,.topbar div>ul.secondary-nav .dropdown-menu,.nav.secondary-nav .dropdown-menu {
+right:0;
+border:0;
+}
+
+.topbar div>ul a.menu:hover,.nav a.menu:hover,.topbar div>ul li.open .menu,.nav li.open .menu,.topbar div>ul .dropdown-toggle:hover,.nav .dropdown-toggle:hover,.topbar div>ul .dropdown.open .dropdown-toggle,.nav .dropdown.open .dropdown-toggle {
+background:#444;
+background:rgba(255, 255, 255, 0.05);
+}
+
+.topbar div>ul .menu-dropdown,.nav .menu-dropdown,.topbar div>ul .dropdown-menu,.nav .dropdown-menu {
+background-color:#333;
+}
+.topbar div>ul .menu-dropdown a.menu,.nav .menu-dropdown a.menu,.topbar div>ul .dropdown-menu a.menu,.nav .dropdown-menu a.menu,.topbar div>ul .menu-dropdown .dropdown-toggle,.nav .menu-dropdown .dropdown-toggle,.topbar div>ul .dropdown-menu .dropdown-toggle,.nav .dropdown-menu .dropdown-toggle {
+color:#ffffff;
+}
+.topbar div>ul .menu-dropdown a.menu.open,.nav .menu-dropdown a.menu.open,.topbar div>ul .dropdown-menu a.menu.open,.nav .dropdown-menu a.menu.open,.topbar div>ul .menu-dropdown .dropdown-toggle.open,.nav .menu-dropdown .dropdown-toggle.open,.topbar div>ul .dropdown-menu .dropdown-toggle.open,.nav .dropdown-menu .dropdown-toggle.open {
+background:#444;
+background:rgba(255, 255, 255, 0.05);
+}
+
+.topbar div>ul .menu-dropdown li a,.nav .menu-dropdown li a,.topbar div>ul .dropdown-menu li a,.nav .dropdown-menu li a {
+color:#999;
+text-shadow:0 1px 0 rgba(0, 0, 0, 0.5);
+}
+.topbar div>ul .menu-dropdown li a:hover,.nav .menu-dropdown li a:hover,.topbar div>ul .dropdown-menu li a:hover,.nav .dropdown-menu li a:hover {
+background-color:#191919;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#292929), to(#191919));
+background-image:-moz-linear-gradient(top, #292929, #191919);
+background-image:-ms-linear-gradient(top, #292929, #191919);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #292929), color-stop(100%, #191919));
+background-image:-webkit-linear-gradient(top, #292929, #191919);
+background-image:-o-linear-gradient(top, #292929, #191919);
+background-image:linear-gradient(top, #292929, #191919);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#292929', endColorstr='#191919', GradientType=0);
+color:#ffffff;
+}
+
+.topbar div>ul .menu-dropdown .active a,.nav .menu-dropdown .active a,.topbar div>ul .dropdown-menu .active a,.nav .dropdown-menu .active a {
+color:#ffffff;
+}
+
+.topbar div>ul .menu-dropdown .divider,.nav .menu-dropdown .divider,.topbar div>ul .dropdown-menu .divider,.nav .dropdown-menu .divider {
+background-color:#222;
+border-color:#444;
+}
+
+.topbar ul .menu-dropdown li a,.topbar ul .dropdown-menu li a {
+padding:4px 15px;
+}
+
+li.menu,.dropdown {
+position:relative;
+}
+
+a.menu:after,.dropdown-toggle:after {
+width:0;
+height:0;
+display:inline-block;
+content:"↓
+";
+text-indent:-99999px;
+vertical-align:top;
+margin-top:8px;
+margin-left:4px;
+border-left:4px solid transparent;
+border-right:4px solid transparent;
+border-top:4px solid #ffffff;
+filter:alpha(opacity=50);
+-khtml-opacity:0.5;
+-moz-opacity:0.5;
+opacity:0.5;
+}
+
+.menu-dropdown,.dropdown-menu {
+background-color:#ffffff;
+float:left;
+display:none;
+position:absolute;
+top:40px;
+z-index:900;
+min-width:160px;
+max-width:220px;
+_width:160px;
+margin-left:0;
+margin-right:0;
+padding:6px 0;
+zoom:1;
+border-color:#999;
+border-color:rgba(0, 0, 0, 0.2);
+border-style:solid;
+border-width:0 1px 1px;
+-webkit-border-radius:0 0 6px 6px;
+-moz-border-radius:0 0 6px 6px;
+border-radius:0 0 6px 6px;
+-webkit-box-shadow:0 2px 4px rgba(0, 0, 0, 0.2);
+-moz-box-shadow:0 2px 4px rgba(0, 0, 0, 0.2);
+box-shadow:0 2px 4px rgba(0, 0, 0, 0.2);
+-webkit-background-clip:padding-box;
+-moz-background-clip:padding-box;
+background-clip:padding-box;
+}
+.menu-dropdown li,.dropdown-menu li {
+float:none;
+display:block;
+background-color:none;
+}
+
+.menu-dropdown .divider,.dropdown-menu .divider {
+height:1px;
+margin:5px 0;
+overflow:hidden;
+background-color:#eee;
+border-bottom:1px solid #ffffff;
+}
+
+.topbar .dropdown-menu a,.dropdown-menu a {
+display:block;
+padding:4px 15px;
+clear:both;
+font-weight:normal;
+line-height:18px;
+color:#808080;
+text-shadow:0 1px 0 #ffffff;
+}
+.topbar .dropdown-menu a:hover,.dropdown-menu a:hover {
+background-color:#dddddd;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#eeeeee), to(#dddddd));
+background-image:-moz-linear-gradient(top, #eeeeee, #dddddd);
+background-image:-ms-linear-gradient(top, #eeeeee, #dddddd);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #eeeeee), color-stop(100%, #dddddd));
+background-image:-webkit-linear-gradient(top, #eeeeee, #dddddd);
+background-image:-o-linear-gradient(top, #eeeeee, #dddddd);
+background-image:linear-gradient(top, #eeeeee, #dddddd);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#eeeeee', endColorstr='#dddddd', GradientType=0);
+color:#404040;
+text-decoration:none;
+-webkit-box-shadow:inset 0 1px 0 rgba(0, 0, 0, 0.025),inset 0 -1px rgba(0, 0, 0, 0.025);
+-moz-box-shadow:inset 0 1px 0 rgba(0, 0, 0, 0.025),inset 0 -1px rgba(0, 0, 0, 0.025);
+box-shadow:inset 0 1px 0 rgba(0, 0, 0, 0.025),inset 0 -1px rgba(0, 0, 0, 0.025);
+}
+
+.open .menu,.dropdown.open .menu,.open .dropdown-toggle,.dropdown.open .dropdown-toggle {
+color:#ffffff;
+background:#ccc;
+background:rgba(0, 0, 0, 0.3);
+}
+
+.open .menu-dropdown,.dropdown.open .menu-dropdown,.open .dropdown-menu,.dropdown.open .dropdown-menu {
+display:block;
+}
+
+.tabs,.pills {
+margin:0 0 20px;
+padding:0;
+list-style:none;
+zoom:1;
+}
+.tabs:before,.pills:before,.tabs:after,.pills:after {
+display:table;
+content:"";
+zoom:1;
+*display:inline;
+}
+
+.tabs:after,.pills:after {
+clear:both;
+}
+
+.tabs>li,.pills>li {
+float:left;
+}
+.tabs>li>a,.pills>li>a {
+display:block;
+}
+
+.tabs {
+float:left;
+width:100%;
+border-bottom:1px solid #ddd;
+}
+.tabs>li {
+position:relative;
+top:1px;
+}
+.tabs>li>a {
+padding:0 15px;
+margin-right:2px;
+line-height:36px;
+border:1px solid transparent;
+-webkit-border-radius:4px 4px 0 0;
+-moz-border-radius:4px 4px 0 0;
+border-radius:4px 4px 0 0;
+}
+.tabs>li>a:hover {
+text-decoration:none;
+background-color:#eee;
+border-color:#eee #eee #ddd;
+}
+
+.tabs>li.active>a {
+color:#808080;
+background-color:#ffffff;
+border:1px solid #ddd;
+border-bottom-color:transparent;
+}
+
+.tabs .menu-dropdown,.tabs .dropdown-menu {
+top:35px;
+border-width:1px;
+-webkit-border-radius:0 6px 6px 6px;
+-moz-border-radius:0 6px 6px 6px;
+border-radius:0 6px 6px 6px;
+}
+
+.tabs a.menu:after,.tabs .dropdown-toggle:after {
+border-top-color:#999;
+margin-top:15px;
+margin-left:5px;
+}
+
+.tabs li.open.menu .menu,.tabs .open.dropdown .dropdown-toggle {
+border-color:#999;
+}
+
+.tabs li.open a.menu:after,.tabs .dropdown.open .dropdown-toggle:after {
+border-top-color:#555;
+}
+
+.tab-content {
+clear:both;
+}
+
+.pills a {
+margin:5px 3px 5px 0;
+padding:0 15px;
+text-shadow:0 1px 1px #ffffff;
+line-height:30px;
+-webkit-border-radius:15px;
+-moz-border-radius:15px;
+border-radius:15px;
+}
+.pills a:hover {
+background:#00438a;
+color:#ffffff;
+text-decoration:none;
+text-shadow:0 1px 1px rgba(0, 0, 0, 0.25);
+}
+
+.pills .active a {
+background:#0069d6;
+color:#ffffff;
+text-shadow:0 1px 1px rgba(0, 0, 0, 0.25);
+}
+
+.tab-content>*,.pill-content>* {
+display:none;
+}
+
+.tab-content>.active,.pill-content>.active {
+display:block;
+}
+
+.breadcrumb {
+margin:0 0 18px;
+padding:7px 14px;
+background-color:#f5f5f5;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#ffffff), to(#f5f5f5));
+background-image:-moz-linear-gradient(top, #ffffff, #f5f5f5);
+background-image:-ms-linear-gradient(top, #ffffff, #f5f5f5);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #ffffff), color-stop(100%, #f5f5f5));
+background-image:-webkit-linear-gradient(top, #ffffff, #f5f5f5);
+background-image:-o-linear-gradient(top, #ffffff, #f5f5f5);
+background-image:linear-gradient(top, #ffffff, #f5f5f5);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#f5f5f5', GradientType=0);
+border:1px solid #ddd;
+-webkit-border-radius:3px;
+-moz-border-radius:3px;
+border-radius:3px;
+-webkit-box-shadow:inset 0 1px 0 #ffffff;
+-moz-box-shadow:inset 0 1px 0 #ffffff;
+box-shadow:inset 0 1px 0 #ffffff;
+}
+.breadcrumb li {
+display:inline;
+text-shadow:0 1px 0 #ffffff;
+}
+
+.breadcrumb .divider {
+padding:0 5px;
+color:#bfbfbf;
+}
+
+.breadcrumb .active a {
+color:#404040;
+}
+
+.main {
+background-color:#f5f5f5;
+margin-bottom:30px;
+padding:60px;
+-webkit-border-radius:6px;
+-moz-border-radius:6px;
+border-radius:6px;
+}
+.main h1 {
+margin-bottom:0;
+font-size:60px;
+line-height:1;
+letter-spacing:-1px;
+}
+
+.main p {
+font-size:18px;
+font-weight:200;
+line-height:27px;
+}
+
+#global-footer {
+margin-top:17px;
+padding-top:17px;
+border-top:1px solid #eee;
+}
+
+.page-header {
+margin-bottom:17px;
+border-bottom:1px solid #ddd;
+-webkit-box-shadow:0 1px 0 rgba(255, 255, 255, 0.5);
+-moz-box-shadow:0 1px 0 rgba(255, 255, 255, 0.5);
+box-shadow:0 1px 0 rgba(255, 255, 255, 0.5);
+}
+.page-header h1 {
+margin-bottom:8px;
+}
+
+.btn.danger,.alert-message.danger,.btn.danger:hover,.alert-message.danger:hover,.btn.error,.alert-message.error,.btn.error:hover,.alert-message.error:hover,.btn.success,.alert-message.success,.btn.success:hover,.alert-message.success:hover,.btn.info,.alert-message.info,.btn.info:hover,.alert-message.info:hover {
+color:#ffffff;
+}
+
+.btn.danger,.alert-message.danger,.btn.error,.alert-message.error {
+background-color:#c43c35;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#ee5f5b), to(#c43c35));
+background-image:-moz-linear-gradient(top, #ee5f5b, #c43c35);
+background-image:-ms-linear-gradient(top, #ee5f5b, #c43c35);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #ee5f5b), color-stop(100%, #c43c35));
+background-image:-webkit-linear-gradient(top, #ee5f5b, #c43c35);
+background-image:-o-linear-gradient(top, #ee5f5b, #c43c35);
+background-image:linear-gradient(top, #ee5f5b, #c43c35);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#ee5f5b', endColorstr='#c43c35', GradientType=0);
+text-shadow:0 -1px 0 rgba(0, 0, 0, 0.25);
+border-color:#c43c35 #c43c35 #882a25;
+border-color:rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);
+}
+
+.btn.success,.alert-message.success {
+background-color:#57a957;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#62c462), to(#57a957));
+background-image:-moz-linear-gradient(top, #62c462, #57a957);
+background-image:-ms-linear-gradient(top, #62c462, #57a957);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #62c462), color-stop(100%, #57a957));
+background-image:-webkit-linear-gradient(top, #62c462, #57a957);
+background-image:-o-linear-gradient(top, #62c462, #57a957);
+background-image:linear-gradient(top, #62c462, #57a957);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#62c462', endColorstr='#57a957', GradientType=0);
+text-shadow:0 -1px 0 rgba(0, 0, 0, 0.25);
+border-color:#57a957 #57a957 #3d773d;
+border-color:rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);
+}
+
+.btn.info,.alert-message.info {
+background-color:#339bb9;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#5bc0de), to(#339bb9));
+background-image:-moz-linear-gradient(top, #5bc0de, #339bb9);
+background-image:-ms-linear-gradient(top, #5bc0de, #339bb9);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #5bc0de), color-stop(100%, #339bb9));
+background-image:-webkit-linear-gradient(top, #5bc0de, #339bb9);
+background-image:-o-linear-gradient(top, #5bc0de, #339bb9);
+background-image:linear-gradient(top, #5bc0de, #339bb9);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#5bc0de', endColorstr='#339bb9', GradientType=0);
+text-shadow:0 -1px 0 rgba(0, 0, 0, 0.25);
+border-color:#339bb9 #339bb9 #22697d;
+border-color:rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);
+}
+
+.btn, .get-i2p {
+cursor:pointer;
+display:inline-block;
+background-color:#e6e6e6;
+background-repeat:no-repeat;
+background-image:-webkit-gradient(linear, 0 0, 0 100%, from(#ffffff), color-stop(25%, #ffffff), to(#e6e6e6));
+background-image:-webkit-linear-gradient(#ffffff, #ffffff 25%, #e6e6e6);
+background-image:-moz-linear-gradient(top, #ffffff, #ffffff 25%, #e6e6e6);
+background-image:-ms-linear-gradient(#ffffff, #ffffff 25%, #e6e6e6);
+background-image:-o-linear-gradient(#ffffff, #ffffff 25%, #e6e6e6);
+background-image:linear-gradient(#ffffff, #ffffff 25%, #e6e6e6);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#e6e6e6', GradientType=0);
+padding:5px 14px 6px;
+text-shadow:0 1px 1px rgba(255, 255, 255, 0.75);
+color:#333;
+font-size:13px;
+line-height:normal;
+border:1px solid #ccc;
+border-bottom-color:#bbb;
+-webkit-border-radius:4px;
+-moz-border-radius:4px;
+border-radius:4px;
+-webkit-box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.2),0 1px 2px rgba(0, 0, 0, 0.05);
+-moz-box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.2),0 1px 2px rgba(0, 0, 0, 0.05);
+box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.2),0 1px 2px rgba(0, 0, 0, 0.05);
+-webkit-transition:0.1s linear all;
+-moz-transition:0.1s linear all;
+-ms-transition:0.1s linear all;
+-o-transition:0.1s linear all;
+transition:0.1s linear all;
+}
+.btn:hover {
+background-position:0 -15px;
+color:#333;
+text-decoration:none;
+}
+
+.btn:focus {
+outline:1px dotted #666;
+}
+
+.btn.primary, .get-i2p {
+color:#ffffff;
+background-color:#0064cd;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#049cdb), to(#0064cd));
+background-image:-moz-linear-gradient(top, #049cdb, #0064cd);
+background-image:-ms-linear-gradient(top, #049cdb, #0064cd);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #049cdb), color-stop(100%, #0064cd));
+background-image:-webkit-linear-gradient(top, #049cdb, #0064cd);
+background-image:-o-linear-gradient(top, #049cdb, #0064cd);
+background-image:linear-gradient(top, #049cdb, #0064cd);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#049cdb', endColorstr='#0064cd', GradientType=0);
+text-shadow:0 -1px 0 rgba(0, 0, 0, 0.25);
+border-color:#0064cd #0064cd #003f81;
+border-color:rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);
+}
+
+.btn:active {
+-webkit-box-shadow:inset 0 2px 4px rgba(0, 0, 0, 0.25),0 1px 2px rgba(0, 0, 0, 0.05);
+-moz-box-shadow:inset 0 2px 4px rgba(0, 0, 0, 0.25),0 1px 2px rgba(0, 0, 0, 0.05);
+box-shadow:inset 0 2px 4px rgba(0, 0, 0, 0.25),0 1px 2px rgba(0, 0, 0, 0.05);
+}
+
+.btn.disabled {
+cursor:default;
+background-image:none;
+filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);
+filter:alpha(opacity=65);
+-khtml-opacity:0.65;
+-moz-opacity:0.65;
+opacity:0.65;
+-webkit-box-shadow:none;
+-moz-box-shadow:none;
+box-shadow:none;
+}
+
+.btn[disabled] {
+cursor:default;
+background-image:none;
+filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);
+filter:alpha(opacity=65);
+-khtml-opacity:0.65;
+-moz-opacity:0.65;
+opacity:0.65;
+-webkit-box-shadow:none;
+-moz-box-shadow:none;
+box-shadow:none;
+}
+
+.btn.large, .get-i2p {
+font-size:15px;
+line-height:normal;
+padding:9px 14px 9px;
+-webkit-border-radius:6px;
+-moz-border-radius:6px;
+border-radius:6px;
+}
+
+.btn.small {
+padding:7px 9px 7px;
+font-size:11px;
+}
+
+:root .alert-message,:root .btn {
+border-radius:0 \0;
+}
+
+button.btn::-moz-focus-inner,input[type=submit].btn::-moz-focus-inner {
+padding:0;
+border:0;
+}
+
+.close {
+float:right;
+color:#000000;
+font-size:20px;
+font-weight:bold;
+line-height:13.5px;
+text-shadow:0 1px 0 #ffffff;
+filter:alpha(opacity=20);
+-khtml-opacity:0.2;
+-moz-opacity:0.2;
+opacity:0.2;
+}
+.close:hover {
+color:#000000;
+text-decoration:none;
+filter:alpha(opacity=40);
+-khtml-opacity:0.4;
+-moz-opacity:0.4;
+opacity:0.4;
+}
+
+.alert-message {
+position:relative;
+padding:7px 15px;
+margin-bottom:18px;
+color:#404040;
+background-color:#eedc94;
+background-repeat:repeat-x;
+background-image:-khtml-gradient(linear, left top, left bottom, from(#fceec1), to(#eedc94));
+background-image:-moz-linear-gradient(top, #fceec1, #eedc94);
+background-image:-ms-linear-gradient(top, #fceec1, #eedc94);
+background-image:-webkit-gradient(linear, left top, left bottom, color-stop(0%, #fceec1), color-stop(100%, #eedc94));
+background-image:-webkit-linear-gradient(top, #fceec1, #eedc94);
+background-image:-o-linear-gradient(top, #fceec1, #eedc94);
+background-image:linear-gradient(top, #fceec1, #eedc94);
+filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#fceec1', endColorstr='#eedc94', GradientType=0);
+text-shadow:0 -1px 0 rgba(0, 0, 0, 0.25);
+border-color:#eedc94 #eedc94 #e4c652;
+border-color:rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.1) rgba(0, 0, 0, 0.25);
+text-shadow:0 1px 0 rgba(255, 255, 255, 0.5);
+border-width:1px;
+border-style:solid;
+-webkit-border-radius:4px;
+-moz-border-radius:4px;
+border-radius:4px;
+-webkit-box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.25);
+-moz-box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.25);
+box-shadow:inset 0 1px 0 rgba(255, 255, 255, 0.25);
+}
+.alert-message .close {
+*margin-top:3px;
+}
+
+.alert-message h5 {
+line-height:18px;
+}
+
+.alert-message p {
+margin-bottom:0;
+}
+
+.alert-message div {
+margin-top:5px;
+margin-bottom:2px;
+line-height:28px;
+}
+
+.alert-message .btn {
+-webkit-box-shadow:0 1px 0 rgba(255, 255, 255, 0.25);
+-moz-box-shadow:0 1px 0 rgba(255, 255, 255, 0.25);
+box-shadow:0 1px 0 rgba(255, 255, 255, 0.25);
+}
+
+.alert-message.block-message {
+background-image:none;
+background-color:#fdf5d9;
+filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);
+padding:14px;
+border-color:#fceec1;
+-webkit-box-shadow:none;
+-moz-box-shadow:none;
+box-shadow:none;
+}
+.alert-message.block-message ul,.alert-message.block-message p {
+margin-right:30px;
+}
+
+.alert-message.block-message ul {
+margin-bottom:0;
+}
+
+.alert-message.block-message li {
+color:#404040;
+}
+
+.alert-message.block-message .alert-actions {
+margin-top:5px;
+}
+
+.alert-message.block-message.error,.alert-message.block-message.success,.alert-message.block-message.info {
+color:#404040;
+text-shadow:0 1px 0 rgba(255, 255, 255, 0.5);
+}
+
+.alert-message.block-message.error {
+background-color:#fddfde;
+border-color:#fbc7c6;
+}
+
+.alert-message.block-message.success {
+background-color:#d1eed1;
+border-color:#bfe7bf;
+}
+
+.alert-message.block-message.info {
+background-color:#ddf4fb;
+border-color:#c6edf9;
+}
+
+.pagination {
+height:36px;
+margin:18px 0;
+}
+.pagination ul {
+float:left;
+margin:0;
+border:1px solid #ddd;
+border:1px solid rgba(0, 0, 0, 0.15);
+-webkit-border-radius:3px;
+-moz-border-radius:3px;
+border-radius:3px;
+-webkit-box-shadow:0 1px 2px rgba(0, 0, 0, 0.05);
+-moz-box-shadow:0 1px 2px rgba(0, 0, 0, 0.05);
+box-shadow:0 1px 2px rgba(0, 0, 0, 0.05);
+}
+
+.pagination li {
+display:inline;
+}
+
+.pagination a {
+float:left;
+padding:0 14px;
+line-height:34px;
+border-right:1px solid;
+border-right-color:#ddd;
+border-right-color:rgba(0, 0, 0, 0.15);
+*border-right-color:#ddd;
+text-decoration:none;
+}
+
+.pagination a:hover,.pagination .active a {
+background-color:#c7eefe;
+}
+
+.pagination .disabled a,.pagination .disabled a:hover {
+background-color:transparent;
+color:#bfbfbf;
+}
+
+.pagination .next a {
+border:0;
+}
+
+.well, .navigation, .package {
+background-color:#f5f5f5;
+margin-bottom:20px;
+padding:19px;
+min-height:20px;
+border:1px solid #eee;
+border:1px solid rgba(0, 0, 0, 0.05);
+-webkit-border-radius:4px;
+-moz-border-radius:4px;
+border-radius:4px;
+-webkit-box-shadow:inset 0 1px 1px rgba(0, 0, 0, 0.05);
+-moz-box-shadow:inset 0 1px 1px rgba(0, 0, 0, 0.05);
+box-shadow:inset 0 1px 1px rgba(0, 0, 0, 0.05);
+}
+.well blockquote {
+border-color:#ddd;
+border-color:rgba(0, 0, 0, 0.15);
+}
+
+.modal-backdrop {
+background-color:#000000;
+position:fixed;
+top:0;
+left:0;
+right:0;
+bottom:0;
+z-index:10000;
+}
+.modal-backdrop.fade {
+opacity:0;
+}
+
+.modal-backdrop,.modal-backdrop.fade.in {
+filter:alpha(opacity=80);
+-khtml-opacity:0.8;
+-moz-opacity:0.8;
+opacity:0.8;
+}
+
+.modal {
+position:fixed;
+top:50%;
+left:50%;
+z-index:11000;
+width:560px;
+margin:-250px 0 0 -250px;
+background-color:#ffffff;
+border:1px solid #999;
+border:1px solid rgba(0, 0, 0, 0.3);
+*border:1px solid #999;
+-webkit-border-radius:6px;
+-moz-border-radius:6px;
+border-radius:6px;
+-webkit-box-shadow:0 3px 7px rgba(0, 0, 0, 0.3);
+-moz-box-shadow:0 3px 7px rgba(0, 0, 0, 0.3);
+box-shadow:0 3px 7px rgba(0, 0, 0, 0.3);
+-webkit-background-clip:padding-box;
+-moz-background-clip:padding-box;
+background-clip:padding-box;
+}
+.modal .close {
+margin-top:7px;
+}
+
+.modal.fade {
+-webkit-transition:opacity .3s linear, top .3s ease-out;
+-moz-transition:opacity .3s linear, top .3s ease-out;
+-ms-transition:opacity .3s linear, top .3s ease-out;
+-o-transition:opacity .3s linear, top .3s ease-out;
+transition:opacity .3s linear, top .3s ease-out;
+top:-25%;
+}
+
+.modal.fade.in {
+top:50%;
+}
+
+.modal-header {
+border-bottom:1px solid #eee;
+padding:5px 15px;
+}
+
+.modal-body {
+padding:15px;
+}
+
+.modal-footer {
+background-color:#f5f5f5;
+padding:14px 15px 15px;
+border-top:1px solid #ddd;
+-webkit-border-radius:0 0 6px 6px;
+-moz-border-radius:0 0 6px 6px;
+border-radius:0 0 6px 6px;
+-webkit-box-shadow:inset 0 1px 0 #ffffff;
+-moz-box-shadow:inset 0 1px 0 #ffffff;
+box-shadow:inset 0 1px 0 #ffffff;
+zoom:1;
+margin-bottom:0;
+}
+.modal-footer:before,.modal-footer:after {
+display:table;
+content:"";
+zoom:1;
+*display:inline;
+}
+
+.modal-footer:after {
+clear:both;
+}
+
+.modal-footer .btn {
+float:right;
+margin-left:5px;
+}
+
+.twipsy {
+display:block;
+position:absolute;
+visibility:visible;
+padding:5px;
+font-size:11px;
+z-index:1000;
+filter:alpha(opacity=80);
+-khtml-opacity:0.8;
+-moz-opacity:0.8;
+opacity:0.8;
+}
+.twipsy.fade.in {
+filter:alpha(opacity=80);
+-khtml-opacity:0.8;
+-moz-opacity:0.8;
+opacity:0.8;
+}
+
+.twipsy.above .twipsy-arrow {
+bottom:0;
+left:50%;
+margin-left:-5px;
+border-left:5px solid transparent;
+border-right:5px solid transparent;
+border-top:5px solid #000000;
+}
+
+.twipsy.left .twipsy-arrow {
+top:50%;
+right:0;
+margin-top:-5px;
+border-top:5px solid transparent;
+border-bottom:5px solid transparent;
+border-left:5px solid #000000;
+}
+
+.twipsy.below .twipsy-arrow {
+top:0;
+left:50%;
+margin-left:-5px;
+border-left:5px solid transparent;
+border-right:5px solid transparent;
+border-bottom:5px solid #000000;
+}
+
+.twipsy.right .twipsy-arrow {
+top:50%;
+left:0;
+margin-top:-5px;
+border-top:5px solid transparent;
+border-bottom:5px solid transparent;
+border-right:5px solid #000000;
+}
+
+.twipsy-inner {
+padding:3px 8px;
+background-color:#000000;
+color:white;
+text-align:center;
+max-width:200px;
+text-decoration:none;
+-webkit-border-radius:4px;
+-moz-border-radius:4px;
+border-radius:4px;
+}
+
+.twipsy-arrow {
+position:absolute;
+width:0;
+height:0;
+}
+
+.popover {
+position:absolute;
+top:0;
+left:0;
+z-index:1000;
+padding:5px;
+display:none;
+}
+.popover.above .arrow {
+bottom:0;
+left:50%;
+margin-left:-5px;
+border-left:5px solid transparent;
+border-right:5px solid transparent;
+border-top:5px solid #000000;
+}
+
+.popover.right .arrow {
+top:50%;
+left:0;
+margin-top:-5px;
+border-top:5px solid transparent;
+border-bottom:5px solid transparent;
+border-right:5px solid #000000;
+}
+
+.popover.below .arrow {
+top:0;
+left:50%;
+margin-left:-5px;
+border-left:5px solid transparent;
+border-right:5px solid transparent;
+border-bottom:5px solid #000000;
+}
+
+.popover.left .arrow {
+top:50%;
+right:0;
+margin-top:-5px;
+border-top:5px solid transparent;
+border-bottom:5px solid transparent;
+border-left:5px solid #000000;
+}
+
+.popover .arrow {
+position:absolute;
+width:0;
+height:0;
+}
+
+.popover .inner {
+background-color:#000000;
+background-color:rgba(0, 0, 0, 0.8);
+padding:3px;
+overflow:hidden;
+width:280px;
+-webkit-border-radius:6px;
+-moz-border-radius:6px;
+border-radius:6px;
+-webkit-box-shadow:0 3px 7px rgba(0, 0, 0, 0.3);
+-moz-box-shadow:0 3px 7px rgba(0, 0, 0, 0.3);
+box-shadow:0 3px 7px rgba(0, 0, 0, 0.3);
+}
+
+.popover .title {
+background-color:#f5f5f5;
+padding:9px 15px;
+line-height:1;
+-webkit-border-radius:3px 3px 0 0;
+-moz-border-radius:3px 3px 0 0;
+border-radius:3px 3px 0 0;
+border-bottom:1px solid #eee;
+}
+
+.popover .content {
+background-color:#ffffff;
+padding:14px;
+-webkit-border-radius:0 0 3px 3px;
+-moz-border-radius:0 0 3px 3px;
+border-radius:0 0 3px 3px;
+-webkit-background-clip:padding-box;
+-moz-background-clip:padding-box;
+background-clip:padding-box;
+}
+.popover .content p,.popover .content ul,.popover .content ol {
+margin-bottom:0;
+}
+
+.fade {
+-webkit-transition:opacity 0.15s linear;
+-moz-transition:opacity 0.15s linear;
+-ms-transition:opacity 0.15s linear;
+-o-transition:opacity 0.15s linear;
+transition:opacity 0.15s linear;
+opacity:0;
+}
+.fade.in {
+opacity:1;
+}
+
+.label {
+padding:1px 3px 2px;
+background-color:#bfbfbf;
+font-size:9.75px;
+font-weight:bold;
+color:#ffffff;
+text-transform:uppercase;
+-webkit-border-radius:3px;
+-moz-border-radius:3px;
+border-radius:3px;
+}
+.label.important {
+background-color:#c43c35;
+}
+
+.label.warning {
+background-color:#f89406;
+}
+
+.label.success {
+background-color:#46a546;
+}
+
+.label.notice {
+background-color:#62cffc;
+}
+
+.media-grid {
+margin-left:-20px;
+margin-bottom:0;
+zoom:1;
+}
+.media-grid:before,.media-grid:after {
+display:table;
+content:"";
+zoom:1;
+*display:inline;
+}
+
+.media-grid:after {
+clear:both;
+}
+
+.media-grid li {
+display:inline;
+}
+
+.media-grid a {
+float:left;
+padding:4px;
+margin:0 0 20px 20px;
+border:1px solid #ddd;
+-webkit-border-radius:4px;
+-moz-border-radius:4px;
+border-radius:4px;
+-webkit-box-shadow:0 1px 1px rgba(0, 0, 0, 0.075);
+-moz-box-shadow:0 1px 1px rgba(0, 0, 0, 0.075);
+box-shadow:0 1px 1px rgba(0, 0, 0, 0.075);
+}
+.media-grid a img {
+display:block;
+}
+
+.media-grid a:hover {
+border-color:#0069d6;
+-webkit-box-shadow:0 1px 4px rgba(0, 105, 214, 0.25);
+-moz-box-shadow:0 1px 4px rgba(0, 105, 214, 0.25);
+box-shadow:0 1px 4px rgba(0, 105, 214, 0.25);
+}
diff --git a/i2p2www/static/styles/danimoth/mobile.css b/i2p2www/static/styles/danimoth/mobile.css
new file mode 100644
index 00000000..e69de29b
diff --git a/i2p2www/static/styles/dark/default.css b/i2p2www/static/styles/dark/default.css
new file mode 100644
index 00000000..e69de29b
diff --git a/www.i2p2/static/styles/dark.css b/i2p2www/static/styles/dark/desktop.css
similarity index 89%
rename from www.i2p2/static/styles/dark.css
rename to i2p2www/static/styles/dark/desktop.css
index 0b86749a..f94c2803 100644
--- a/www.i2p2/static/styles/dark.css
+++ b/i2p2www/static/styles/dark/desktop.css
@@ -25,7 +25,7 @@ img {
 	border: none
 }
 
-div.logo {
+a#logo {
 	float: left;
 /*	left: 1em;
 	top: 1em;
@@ -38,7 +38,23 @@ div.logo {
   font-color: #fff;
 }
 
-div.menu {
+a#logo img {
+  filter:alpha(opacity=100);
+  -moz-opacity: 1.0;
+  opacity: 1.0;
+}
+
+a#logo:hover img {
+  filter:alpha(opacity=60);
+  -moz-opacity: 0.6;
+  opacity: 0.6;
+}
+
+div#topbar ul.languages {
+  display: none;
+}
+
+div#cssmenu {
 	/* width: 8em; */
 	/* height: 5em; */
 	/* position: fixed; */
@@ -48,7 +64,7 @@ div.menu {
 	/*margin: 0em;*/
 /*	padding: .5em;*/
 	margin: 0px 20px 20px 0px;
-	padding: 5px 20px 20px 20px;
+	padding: 5px 20px 20px 0;
 	text-align: left;
 	border: 1px solid #99f;
 	border-top: 1px solid #99f;
@@ -63,7 +79,7 @@ div.menu {
 }
 
 /*
-div.menu a:link {
+div#cssmenu a:link {
 border:1px solid #000022;
 border-left: 3px solid #000022;
 margin: 10px 0;
@@ -76,13 +92,27 @@ background-color: #9999ff;
 */
 
 /*
-div.menu a:link{color:#99f;margin: 15px 0;padding: 0px 5px 0px 10px; border-left: 5px solid #99f;line-height: 240%; text-decoration: none;}
+div#cssmenu a:link{color:#99f;margin: 15px 0;padding: 0px 5px 0px 10px; border-left: 5px solid #99f;line-height: 240%; text-decoration: none;}
 */
-div.menu a:link{color:#99f;}
-div.menu a:visited{color:#60f}
-div.menu a:hover{color:#ff6600;}
-/* div.menu a:hover{color:#ff6600;border-left: 5px solid #fff;}*/
-div.menu a:active{color:#900}
+div#cssmenu a:link{color:#99f;}
+div#cssmenu a:visited{color:#60f}
+div#cssmenu a:hover{color:#ff6600;}
+/* div#cssmenu a:hover{color:#ff6600;border-left: 5px solid #fff;}*/
+div#cssmenu a:active{color:#900}
+
+div#cssmenu ul {
+  margin: 0;
+  padding: 5px 0px 5px 20px;
+}
+
+div#cssmenu li {
+  padding: 5px 0px 5px 0px;
+  margin: 0;
+}
+
+div#cssmenu div.menuitem {
+  display: inline;
+}
 
 div.warning {
 	margin: 0em 1em 1em 12em;
@@ -93,9 +123,9 @@ div.warning {
 	color: inherit;
 }
 
-div.main {
+div#content {
 	margin: 0px 0px 0px 0px;
-	padding: 25px 40px 20px 190px;
+	padding: 25px 40px 20px 325px;
 	background-color: #001;
 	text-align: justify;
 	color: #eeeeff;
@@ -103,7 +133,7 @@ div.main {
 	border-bottom: 1px solid #99f;
 }
 
-div.main h1 {
+div#content h1 {
 	text-align: left;
 	color: #99f;
 	padding-left: 10px;
@@ -437,4 +467,4 @@ td.announce {
 
 .targetlist {
 	list-style-image: url(/_static/images/target.png);
-}
\ No newline at end of file
+}
diff --git a/i2p2www/static/styles/dark/mobile.css b/i2p2www/static/styles/dark/mobile.css
new file mode 100644
index 00000000..e69de29b
diff --git a/i2p2www/static/styles/default.css b/i2p2www/static/styles/default.css
new file mode 100644
index 00000000..11a4aa40
--- /dev/null
+++ b/i2p2www/static/styles/default.css
@@ -0,0 +1,84 @@
+html,body,h1,h2,h3,ol,ul,p{margin:0;padding:0}
+
+body {
+    font-family: sans-serif;
+}
+
+p,ol,ul {margin-bottom:10px}
+
+img {border:0;}
+
+.hide {
+      display: none;
+}
+
+#header {
+    border-bottom:1px solid black;        /* give us a black border underneath */
+    margin-bottom: 10px;
+}
+
+#logo {
+    margin-top: 12px;
+    height: 42px;
+}
+
+#slogan {
+    margin-top: 12px;
+    height: 42px;
+}
+
+#searchbox {
+    margin-top: 18px;
+}
+
+#searchbox form{
+    float: right;
+}
+
+#flags {
+    float: right;
+}
+
+.content li {
+    margin-left: 1.4em;
+}
+
+#try_i2p_now {
+    margin-top: 6px;
+    margin-bottom: 10px;
+}
+
+#supported_applications {
+    font-size: smaller;
+}
+
+#news {
+    font-size: smaller;
+}
+
+.btn {
+    float: left;
+    clear: both;
+    background: url(../images/btn_left.png) no-repeat;
+    padding: 0 0 0 10px;
+    margin: 5px 0;
+}
+.btn a{
+    float: left;
+    height: 40px;
+    background: url(../images/btn_stretch.png) repeat-x left top;
+    line-height: 40px;
+    padding: 0 10px;
+    color: #fff;
+    font-size: 1.5em;
+    font-weight: bold;
+    text-decoration: none;
+}
+.btn span {
+    background: url(../images/btn_right.png) no-repeat;
+    float: left;
+    width: 10px;
+    height: 40px;
+}
+.btn_download { background-color: red; }
+.btn_donate { background-color: green; }
diff --git a/i2p2www/static/styles/duck/default.css b/i2p2www/static/styles/duck/default.css
new file mode 100644
index 00000000..31bf033e
--- /dev/null
+++ b/i2p2www/static/styles/duck/default.css
@@ -0,0 +1,271 @@
+@import url('reset.css');
+
+body {
+    font-family: Droid Sans, Helvetica, sans-serif;
+    font-size: 10px;
+    background-color: #ffffdd;
+    min-height:800px;
+    width:100%;
+    background:-moz-radial-gradient(50% 30% , circle , #fffff9, #ffffcc) no-repeat scroll 0 0 #ffffcc;
+    background:-webkit-radial-gradient(50% 30% , circle , #fffff9, #ffffcc) no-repeat scroll 0 0 #ffffcc;
+}
+
+a {
+    color:#d00e0e;
+    text-decoration:none;
+}
+
+a:hover {
+    color:#f00e0e;
+}
+
+div.hide {
+    display:none;
+}
+
+div#topbar {
+    width:80%;
+    /*margin:1em auto;*/
+    margin: 1em auto;
+    position:relative;
+}
+
+div#topbar #logo img:hover {
+    filter:alpha(opacity=60);
+    -moz-opacity: 0.6;
+    opacity: 0.6;
+}
+
+div#content {
+    display:block;
+}
+
+/**
+ * The .main class is for content wrapper on the home page (with the big banner)
+ */
+div#content .main {
+    background:url('../../images/dots.png') 0 10% no-repeat rgba(171, 204, 113, 0.6);
+    background-size:100% auto;
+    width:auto;
+    padding:4em 10% 4em 10%;
+    position:relative;
+    margin:0 auto;
+    text-shadow:1px 1px 1px rgba(255,255,255,.5);
+    font-size:1.6em;
+    line-height:1.5em;
+    border:2px solid #abcc71;
+    border-left:none;
+    border-right:none;
+    box-shadow:0px 2px 8px rgba(0,0,0,.2)
+}
+
+div#content .main h1 {
+    font-family:"URW Gothic L", "Century Gothic", sans-serif;
+    font-size:2.5em; 
+    text-shadow:1px 1px 2px rgba(0,0,0,.3);
+    color:white;
+    margin-bottom:.5em;
+}
+
+.main .get-i2p {
+    display:block;
+    top:50%;
+    height:1em;
+    padding:.5em;
+    line-height:1em;
+    font-size:2em;
+    color:white;
+    font-family:Arial, Helvetica, sans-serif;
+    font-weight:bold; 
+    text-transform:uppercase;
+    text-decoration:none;
+    text-align:center; 
+    background:green;
+    border-radius:.3em;
+    text-shadow:1px 1px 1px rgba(0,0,0,.2);
+    box-shadow:2px 2px 4px rgba(0, 0, 0, 0.3), 1em 3em 2em 0.5em rgba(255, 255, 255, 0.3) inset, inset -.2em -.5em 1em -0em rgba(0,0,0,.3)
+}
+
+div#content .aside-wrap {
+    width:80%;
+    margin:2em auto;
+}
+
+div#content .aside {
+    position:relative;
+    display:inline-block;
+    vertical-align:top;
+    font-size:1.2em
+}
+
+div#content .aside a {
+    font-weight:bold;
+}
+
+div#content .aside h1 {
+    padding:1em 0;
+    border-bottom:1px solid rgba(171, 204, 113, 0.6);
+    font-size:1.4em;
+    color:#222200;
+    text-shadow:1px 1px 1px rgba(0,0,0,.3)
+}
+
+div#content .aside p {
+    margin:1em 0;
+}
+
+div#content .aside ul {
+    margin:1em 0;
+}
+
+div#content .aside ul li {
+    list-style-type:none;
+    margin:1em 0;
+    line-height:1.3em;
+}
+
+div#content .feed-icon {
+    background-image: url('../../images/feed-icon-28x28.png');
+    display: block;
+    float: right;
+    height: 28px;
+    margin: 1em;
+    text-indent: -9999px;
+    width: 28px;
+}
+
+div#content .lastupdated {
+    background-color: #ffffdd;
+    border-radius: 0 0 5px 5px;
+    padding: 2px 4px;
+    position: absolute;
+    right: 10%;
+    text-align: right;
+    top: 0;
+    width: 200px;
+}
+
+/**
+ * The .inner class is for the content wrapper on inner pages (as opposed to the home page)
+ */
+div#content .inner {
+    width:auto;
+    margin: 0 5%;
+    padding: 4em 5%;
+    position:relative;
+    background: rgba(171, 204, 113, 0.6);
+    border-top:2px solid #abcc71;
+    border-left: 2px solid #abcc71;
+    border-right: 2px solid #abcc71;
+    border-radius: 5px 5px 0 0;
+    color:black;
+    font-size:1.2em;
+    line-height:1.4em;
+}
+
+div#content .inner h1, div#content .inner h2, div#content .inner h3 {
+    color:white;
+    text-shadow:1px 1px 1px rgba(0,0,0,.3);
+    margin:1em 0 .5em;
+    border-bottom:1px solid white;
+    padding-bottom:.2em;
+}
+
+div#content .inner h1 {
+    font-size:2.2em;
+    margin:0em 0 1em;
+    width:auto;
+}
+
+div#content .inner h2 {
+    font-size:1.6em;
+}
+
+div#content .inner h3 {
+    font-size:1.4em;
+}
+
+div#content .inner ol {
+    margin:1.5em;
+}
+
+div#content .inner ul {
+    margin:1.5em; 1em;
+}
+
+div#content .inner p {
+    margin:1em 0;
+}
+
+div#content .inner td {
+    padding:2px 5px;
+}
+
+.package {
+    border: 2px solid #d00e0e;
+    border-radius: 5px;
+    margin: 10px;
+    padding: 10px;
+}
+
+.file {
+    border: 1px dashed #d00e0e;
+    margin: 5px;
+    padding: 5px;
+}
+
+#global-footer {
+    width:auto;
+    border-top:3px
+    solid #883333;
+    background:#552222;
+    box-shadow:0px -4px 8px rgba(0,0,0,.3);
+    padding:1em 10%;
+    background:-moz-linear-gradient(#883333, #772222);
+}
+
+#global-footer .aside {
+    display:inline-block;
+    vertical-align:top;
+}
+
+#global-footer .aside h1 {
+    color:#ffdd88;
+    font-size:1.2em;
+    text-shadow:-1px -1px 1px rgba(0,0,0,.2);
+    border-bottom:1px solid #ccaa66;
+    margin:1em 0;
+    line-height:1.3em;
+}
+
+#global-footer .aside ul {
+    margin:0;
+    padding:0;
+}
+
+#global-footer .aside ul li {
+    list-style-type:none;
+    line-height:1.5em;
+}
+
+#global-footer .aside ul li a {
+    color:#ccaa66;
+    font-weight:bold;
+}
+
+#global-footer .aside ul li a:hover {
+    text-decoration:underline;
+}
+
+#global-footer a.button {
+    padding:.5em 2em;
+    background-color:#cc2222;
+    border:1px solid #bb2222;
+    border-radius:3px;
+    display:inline-block;
+    color:white;
+    margin:1em auto;
+    text-align:center;
+    width:auto;
+    font-weight:bold;
+}
diff --git a/i2p2www/static/styles/duck/desktop.css b/i2p2www/static/styles/duck/desktop.css
new file mode 100644
index 00000000..7859031f
--- /dev/null
+++ b/i2p2www/static/styles/duck/desktop.css
@@ -0,0 +1,315 @@
+body {
+    font-family:Droid Sans, Helvetica, sans-serif; font-size:10px;
+    background-color:#ffffdd;
+    min-height:800px; width:100%; padding-top:1em;
+    background:-moz-radial-gradient(50% 30% , circle , #fffff9, #ffffcc) no-repeat scroll 0 0 #ffffcc;
+    background:-webkit-radial-gradient(50% 30% , circle , #fffff9, #ffffcc) no-repeat scroll 0 0 #ffffcc;
+}
+a {color:#d00e0e; text-decoration:none;}
+    a:hover {color:#f00e0e;}
+
+div.hide {display:none;}
+
+div#topbar {width:80%; /*margin:1em auto;*/ margin: 1em auto 0; position:relative;}
+    div#topbar #logo img:hover {
+        filter:alpha(opacity=60);
+        -moz-opacity: 0.6;
+        opacity: 0.6;
+    }
+    div#topbar .title {
+        font-family:"URW Gothic L", "Century Gothic", sans-serif; text-transform:uppercase; font-size:3.5em; 
+        font-weight:bold; text-shadow:1px 1px 1px rgba(0,0,0,.2); color:#333333;
+        position:absolute; top:0; right:0; line-height:41px; vertical-align:middle;
+        max-width: 70%; text-align: right;
+    }
+    div#topbar .languages {
+        display: none;
+    }
+
+div.navigation {position:relative;}
+    ul.languages {margin: 0 2px !important;}
+    ul.languages li {display:inline-block; *display:inline; *zoom:1; margin: 0 -2px !important;}
+
+/* Dropdown menu CSS */
+
+menu ul,
+#cssmenu li,
+#cssmenu span,
+#cssmenu div.menuitem {
+  margin: 0;
+  padding: 0;
+  position: relative;
+}
+#cssmenu {
+  /*height: 49px;*/
+  height: 40px;
+  /*background: #141414;
+  background: -moz-linear-gradient(top, #32323a 0%, #141414 100%);
+  background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #32323a), color-stop(100%, #141414));
+  background: -webkit-linear-gradient(top, #32323a 0%, #141414 100%);
+  background: -o-linear-gradient(top, #32323a 0%, #141414 100%);
+  background: -ms-linear-gradient(top, #32323a 0%, #141414 100%);
+  background: linear-gradient(to bottom, #32323a 0%, #141414 100%);*/
+  filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#32323a', EndColorStr='#141414', GradientType=0);
+  /*border-bottom: 2px solid #0fa1e0;*/
+}
+#cssmenu:after,
+#cssmenu ul:after {
+  content: '';
+  display: block;
+  clear: both;
+}
+#cssmenu div.menuitem {
+  /*background: #141414;
+  background: -moz-linear-gradient(top, #32323a 0%, #141414 100%);
+  background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #32323a), color-stop(100%, #141414));
+  background: -webkit-linear-gradient(top, #32323a 0%, #141414 100%);
+  background: -o-linear-gradient(top, #32323a 0%, #141414 100%);
+  background: -ms-linear-gradient(top, #32323a 0%, #141414 100%);
+  background: linear-gradient(to bottom, #32323a 0%, #141414 100%);*/
+  filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#32323a', EndColorStr='#141414', GradientType=0);
+  /*color: #ffffff;*/
+  color: #d00e0e;
+  display: inline-block;
+  font-family: "URW Gothic L", "Century Gothic", sans-serif;
+  /*font-size: 11pt;*/
+  font-size: 2em;
+  font-weight: bold;
+  text-shadow: 1px 1px 1px rgba(100,20,20,.2);
+  /*line-height: 49px;*/
+  line-height: 40px;
+  /*padding: 0 20px;*/
+  padding: 0 10px;
+  text-decoration: none;
+}
+#cssmenu ul {
+  list-style: none;
+}
+#cssmenu > ul {
+  float: left;
+  padding: 0 10%;
+}
+#cssmenu > ul > li {
+  float: left;
+}
+#cssmenu > ul > li.right {
+  position: absolute;
+  right: 10%;
+}
+#cssmenu > ul > li:hover:after {
+  content: '';
+  display: block;
+  width: 0;
+  height: 0;
+  position: absolute;
+  left: 50%;
+  bottom: 0;
+  border-left: 10px solid transparent;
+  border-right: 10px solid transparent;
+  /*border-bottom: 10px solid #0fa1e0;*/
+  border-bottom: 10px solid #abcc71;
+  margin-left: -10px;
+}
+/*#cssmenu > ul > li:first-child > div.menuitem {
+  border-radius: 5px 0 0 0;
+  -moz-border-radius: 5px 0 0 0;
+  -webkit-border-radius: 5px 0 0 0;
+}
+#cssmenu > ul > li:last-child > div.menuitem {
+  border-radius: 0 5px 0 0;
+  -moz-border-radius: 0 5px 0 0;
+  -webkit-border-radius: 0 5px 0 0;
+}*/
+#cssmenu > ul > li > div.menuitem {
+  border-radius: 5px 5px 0 0;
+  -moz-border-radius: 5px 5px 0 0;
+  -webkit-border-radius: 5px 5px 0 0;
+}
+#cssmenu > ul > li.active > div.menuitem {
+  box-shadow: inset 0 0 3px #000000;
+  -moz-box-shadow: inset 0 0 3px #000000;
+  -webkit-box-shadow: inset 0 0 3px #000000;
+  background: #070707;
+  background: -moz-linear-gradient(top, #26262c 0%, #070707 100%);
+  background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #26262c), color-stop(100%, #070707));
+  background: -webkit-linear-gradient(top, #26262c 0%, #070707 100%);
+  background: -o-linear-gradient(top, #26262c 0%, #070707 100%);
+  background: -ms-linear-gradient(top, #26262c 0%, #070707 100%);
+  background: linear-gradient(to bottom, #26262c 0%, #070707 100%);
+  filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#26262c', EndColorStr='#070707', GradientType=0);
+}
+/*
+#cssmenu > ul > li:hover > div.menuitem {
+  /*background: #070707;
+  background: -moz-linear-gradient(top, #26262c 0%, #070707 100%);
+  background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #26262c), color-stop(100%, #070707));
+  background: -webkit-linear-gradient(top, #26262c 0%, #070707 100%);
+  background: -o-linear-gradient(top, #26262c 0%, #070707 100%);
+  background: -ms-linear-gradient(top, #26262c 0%, #070707 100%);
+  background: linear-gradient(to bottom, #26262c 0%, #070707 100%);*//*
+  filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#26262c', EndColorStr='#070707', GradientType=0);
+  box-shadow: inset 0 0 3px #000000;
+  -moz-box-shadow: inset 0 0 3px #000000;
+  -webkit-box-shadow: inset 0 0 3px #000000;
+}
+*/
+#cssmenu .has-sub {
+  z-index: 1;
+}
+#cssmenu .has-sub:hover > ul {
+  display: block;
+}
+#cssmenu .has-sub ul {
+  display: none;
+  position: absolute;
+  width: 200px;
+  top: 100%;
+  left: 0;
+}
+#cssmenu .has-sub ul li {
+  border-left: 1px solid #ffffcc;
+  /*margin-bottom: -1px;*/
+}
+#cssmenu .has-sub ul li.has-sub > div.menuitem:after {
+    content: "►";
+    color: rgba(255,255,255,.5);
+    float: right;
+}
+#cssmenu .has-sub ul li div.menuitem {
+  /*background: #0fa1e0;*/
+  /*border-bottom: 1px dotted #6fc7ec;*/
+  background: #abcc71;
+  border-bottom: 1px dotted #ffffcc;
+  filter: none;
+  font-size: 9pt;
+  display: block;
+  line-height: 120%;
+  padding: 10px;
+}
+#cssmenu .has-sub ul li:hover div.menuitem {
+  /*background: #0c7fb0;*/
+  background: #8bbc51;
+}
+#cssmenu .has-sub .has-sub:hover > ul {
+  display: block;
+}
+#cssmenu .has-sub .has-sub ul {
+  display: none;
+  position: absolute;
+  left: 100%;
+  top: 0;
+}
+#cssmenu .has-sub .has-sub ul li:first-child {
+  border-left: none;
+}
+#cssmenu .has-sub .has-sub ul li div.menuitem {
+  /*background: #0c7fb0;
+  border-bottom: 1px dotted #6db2d0;*/
+  background: #8bbc51;
+  border-bottom: 1px dotted #ffffcc;
+}
+#cssmenu .has-sub .has-sub ul li div.menuitem:hover {
+  /*background: #095c80;*/
+  background: #6bac31;
+}
+
+/* End of dropdown menu CSS */
+
+div#content {display:block;}
+    /**
+     * The .main class is for content wrapper on the home page (with the big banner)
+     */
+div#content .main {
+    background:url('../../images/dots.png') 0 10% no-repeat rgba(171, 204, 113, 0.6); background-size:100% auto; width:auto; padding:4em 35% 4em 10%; position:relative;
+    margin:0 auto; text-shadow:1px 1px 1px rgba(255,255,255,.5); font-size:1.6em; line-height:1.5em;
+    border:2px solid #abcc71; border-left:none; border-right:none;  box-shadow:0px 2px 8px rgba(0,0,0,.2)}
+    div#content .main h1 {font-family:"URW Gothic L", "Century Gothic", sans-serif; font-size:2.5em; 
+    text-shadow:1px 1px 2px rgba(0,0,0,.3); color:white; margin-bottom:.5em;}
+    .main .get-i2p {
+        position:absolute; display:block; top:50%; right: 10%;
+        margin-top:-1em; height:1em; padding:.5em; line-height:1em;
+        font-size:2em; color:white; font-family:Arial, Helvetica, sans-serif; font-weight:bold; 
+        text-transform:uppercase; text-decoration:none; text-align:center; 
+        background:green; border-radius:.3em; -moz-transform:rotate(-5deg); 
+        text-shadow:1px 1px 1px rgba(0,0,0,.2);
+        box-shadow:2px 2px 4px rgba(0, 0, 0, 0.3), 1em 3em 2em 0.5em rgba(255, 255, 255, 0.3) inset, inset -.2em -.5em 1em -0em rgba(0,0,0,.3)}
+    .main .get-i2p:hover {box-shadow:2px 2px 2px rgba(0, 0, 0, 0.3), inset 0 -2.2em 2.2em rgba(255, 255, 255, 0.3), inset .2em .5em 1em 0em rgba(0,0,0,.3);}
+    div#content .aside-wrap {width:80%; margin:2em auto;}
+    div#content .aside {position:relative; width:30.9%; margin-left:3%;    display:inline-block; vertical-align:top; font-size:1.2em}
+        div#content .aside:first-child {margin-left:0%;}
+        div#content .aside a {font-weight:bold;}
+        div#content .aside h1 {padding:1em 0; border-bottom:1px solid rgba(171, 204, 113, 0.6); font-size:1.4em; color:#222200; text-shadow:1px 1px 1px rgba(0,0,0,.3)}
+        div#content .aside p {margin:1em 0;}
+            div#content .aside ul {margin:1em 0;}
+                div#content .aside ul li {list-style-type:none; margin:1em 0; line-height:1.3em;}
+
+    div#content .feed-icon {
+        background-image: url('../../images/feed-icon-28x28.png');
+        display: block;
+        float: right;
+        height: 28px;
+        margin: 1em;
+        text-indent: -9999px;
+        width: 28px;
+    }
+
+    div#content .lastupdated {
+        background-color: #ffffdd;
+        border-radius: 0 0 5px 5px;
+        padding: 2px 4px;
+        position: absolute;
+        right: 10%;
+        text-align: right;
+        top: 0;
+        width: 200px;
+    }
+
+    /**
+     * The .inner class is for the content wrapper on inner pages (as opposed to the home page)
+     */
+    div#content .inner {
+        width:auto; margin: 0 5%; padding: 4em 5%; position:relative;
+        background: rgba(171, 204, 113, 0.6); border-top:2px solid #abcc71;
+        border-left: 2px solid #abcc71; border-right: 2px solid #abcc71; border-radius: 5px 5px 0 0;
+        color:black; font-size:1.2em; line-height:1.4em;
+    }
+    div#content .inner h1, div#content .inner h2, div#content .inner h3 {color:white; text-shadow:1px 1px 1px rgba(0,0,0,.3); margin:1em 0 .5em; border-bottom:1px solid white; padding-bottom:.2em;}
+    div#content .inner h1 {font-size:2.2em; margin:0em 0 1em;  width:auto;}
+    div#content .inner h2 {font-size:1.6em;}
+    div#content .inner h3 {font-size:1.4em;}
+    div#content .inner ol {margin:1.5em;}
+    div#content .inner ul {margin:1.5em; 1em;}
+    div#content .inner p {margin:1em 0;}
+    div#content .inner td {padding:2px 5px;}
+
+/* CSS for downloads list */
+
+.package {
+    border: 2px solid #d00e0e;
+    border-radius: 5px;
+    margin: 10px;
+    padding: 10px;
+}
+
+.file {
+    border: 1px dashed #d00e0e;
+    margin: 5px;
+    padding: 5px;
+}
+
+.sig {
+    float: right;
+}
+
+/* End of downloads list CSS */
+
+#global-footer {width:auto; border-top:3px solid #883333; background:#552222; box-shadow:0px -4px 8px rgba(0,0,0,.3); padding:1em 10%; background:-moz-linear-gradient(#883333, #772222);}
+    #global-footer .aside {display:inline-block; width:15%; margin-left:1%; vertical-align:top;}
+        #global-footer .aside.first {margin-left:0;}
+        #global-footer .aside.third, div##global-footer .aside.fifth {margin-left:2.5%}
+        #global-footer .aside h1 {color:#ffdd88; font-size:1.2em; text-shadow:-1px -1px 1px rgba(0,0,0,.2); border-bottom:1px solid #ccaa66; margin:1em 0; line-height:1.3em;}
+        #global-footer .aside ul {margin:0; padding:0;}
+        #global-footer .aside ul li {list-style-type:none; line-height:1.5em;}
+        #global-footer .aside ul li a {color:#ccaa66; font-weight:bold;}
+        #global-footer .aside ul li a:hover {text-decoration:underline;}
+        #global-footer a.button {padding:.5em 2em; background-color:#cc2222; border:1px solid #bb2222; border-radius:3px; display:inline-block; color:white; margin:1em auto; text-align:center; width:auto; font-weight:bold;}
diff --git a/i2p2www/static/styles/duck/images/i2plogo.png b/i2p2www/static/styles/duck/images/i2plogo.png
new file mode 100644
index 00000000..809d3005
Binary files /dev/null and b/i2p2www/static/styles/duck/images/i2plogo.png differ
diff --git a/i2p2www/static/styles/duck/mobile.css b/i2p2www/static/styles/duck/mobile.css
new file mode 100644
index 00000000..86f1b200
--- /dev/null
+++ b/i2p2www/static/styles/duck/mobile.css
@@ -0,0 +1,135 @@
+#topbar .title {
+    display: none;
+}
+
+/* Dropdown menu CSS */
+
+#cssmenu > ul {
+    width: 100%;
+    float: none;
+    background-color: #abcc71; /* change the menu color */
+    background-image: -webkit-linear-gradient(top, rgba(0,0,0,0), rgba(0,0,0,.2));
+    background-image:    -moz-linear-gradient(top, rgba(0,0,0,0), rgba(0,0,0,.2));
+    background-image:     -ms-linear-gradient(top, rgba(0,0,0,0), rgba(0,0,0,.2));
+    background-image:      -o-linear-gradient(top, rgba(0,0,0,0), rgba(0,0,0,.2));
+    display: block;
+    /*height: 0;*/
+    height: auto;
+    margin: 0;
+    padding: 0;
+    overflow: hidden;
+    box-shadow: 0 1px 2px rgba(0,0,0,.6);
+    /*position: absolute;*/
+    top: 0px;
+    left: 0px;
+    z-index: 998;
+    clear: both;
+}
+
+#cssmenu > ul li {
+    /*display: none;*/
+    display: block; 
+    width: 100%;
+    font-family: Arial;
+}
+
+#cssmenu > ul li div.menuitem {
+    display: block;
+    width: 90%;
+    padding: 10px 5%;
+    font-size: 14px;
+    font-weight: bold;
+    text-shadow: -1px -1px 0 rgba(0,0,0,.15);
+    color: white;
+    text-decoration: none;
+    border-bottom: 1px solid rgba(0,0,0,.2);
+    border-top: 1px solid rgba(255,255,255,.1); 
+}
+
+#cssmenu > ul li div.menuitem:hover {
+    background-color: rgba(0,0,0,.5);
+    border-top-color: transparent;
+}
+
+#cssmenu > ul > li:first-child {
+    border-top: 1px solid rgba(0,0,0,.2);
+}
+
+/* Toggle the navigation bar open  */
+
+#cssmenu > ul.open { 
+    height: auto; 
+    /*padding-top: 50px;*/
+}
+
+#cssmenu > ul.open li { 
+    display: block; 
+}
+
+/* Submenus – .has-sub class indicates dropdowns */
+
+#cssmenu > ul > li:hover > div.menuitem {
+    background: rgba(0,0,0,.5);
+    border-bottom-color: transparent;
+}
+
+#cssmenu > ul li.has-sub > div.menuitem:after {
+    content: "▼";
+    color: rgba(255,255,255,.5);
+    float: right;
+}
+
+#cssmenu > ul li.has-sub > div.menuitem:hover {
+    background: rgba(0,0,0,.75);
+}
+
+#cssmenu > ul li ul {
+    display: none;
+    background: rgba(0,0,0,.5);
+    border-top: 0 none;
+    padding: 0;
+}
+
+#cssmenu > ul li ul div.menuitem {
+    border: 0 none;
+    font-size: 12px;
+    padding: 10px 5%;
+    font-weight: normal;
+}
+
+#cssmenu > ul li:hover > ul {
+    display: block;
+    border-top: 0 none;
+}
+
+/* End of dropdown menu CSS */
+
+div#content .main {
+    padding: 4em 10%;
+}
+
+.main .get-i2p {
+    margin-bottom: -1.5em;
+    margin-top: .5em;
+}
+
+div#content .aside {
+    width: 100%;
+}
+
+div#content .inner {
+    margin-top: 1em;
+}
+
+.sig {
+    display: none;
+}
+
+#global-footer .aside {
+    margin-left: 1%;
+    width: 49%;
+}
+
+#global-footer .aside.first, #global-footer .aside.third, #global-footer .aside.fifth {
+    margin-left: 0;
+}
diff --git a/i2p2www/static/styles/duck/reset.css b/i2p2www/static/styles/duck/reset.css
new file mode 100644
index 00000000..907f6e20
--- /dev/null
+++ b/i2p2www/static/styles/duck/reset.css
@@ -0,0 +1,102 @@
+/* 
+ * html5doctor.com Reset Stylesheet
+ * v1.6.1
+ * Last Updated: 2010-09-17
+ * Author: Richard Clark - http://richclarkdesign.com 
+ * Twitter: @rich_clark
+ * */
+
+html, body, div, span, object, iframe,
+h1, h2, h3, h4, h5, h6, p, blockquote, pre,
+abbr, address, cite, code,
+del, dfn, em, img, ins, kbd, q, samp,
+small, strong, sub, sup, var,
+b, i,
+dl, dt, dd, ol, ul, li,
+fieldset, form, label, legend,
+table, caption, tbody, tfoot, thead, tr, th, td,
+article, aside, canvas, details, figcaption, figure, 
+footer, header, hgroup, menu, nav, section, summary,
+time, mark, audio, video {
+	margin:0;
+	padding:0;
+	border:0;
+	outline:0;
+	font-size:100%;
+	vertical-align:baseline;
+	background:transparent;
+}
+
+body {
+	line-height:1;
+}
+
+article,aside,details,figcaption,figure,
+footer,header,hgroup,menu,nav,section { 
+	display:block;
+}
+
+nav ul {
+	list-style:none;
+}
+
+blockquote, q {
+	quotes:none;
+}
+
+blockquote:before, blockquote:after,
+q:before, q:after {
+	content:'';
+	content:none;
+}
+
+a {
+	margin:0;
+	padding:0;
+	font-size:100%;
+	vertical-align:baseline;
+	background:transparent;
+}
+
+/* change colours to suit your needs */
+ins {
+	background-color:#ff9;
+	color:#000;
+	text-decoration:none;
+}
+
+/* change colours to suit your needs */
+mark {
+	background-color:#ff9;
+	color:#000; 
+	font-style:italic;
+	font-weight:bold;
+}
+
+del {
+	text-decoration: line-through;
+}
+
+abbr[title], dfn[title] {
+	border-bottom:1px dotted;
+	cursor:help;
+}
+
+table {
+	border-collapse:collapse;
+	border-spacing:0;
+}
+
+/* change border colour to suit your needs */
+hr {
+	display:block;
+	height:1px;
+	border:0;   
+	border-top:1px solid #cccccc;
+	margin:1em 0;
+	padding:0;
+}
+
+input, select {
+	vertical-align:middle;
+}
diff --git a/i2p2www/static/styles/light/default.css b/i2p2www/static/styles/light/default.css
new file mode 100644
index 00000000..e69de29b
diff --git a/www.i2p2/static/styles/light.css b/i2p2www/static/styles/light/desktop.css
similarity index 89%
rename from www.i2p2/static/styles/light.css
rename to i2p2www/static/styles/light/desktop.css
index d339a9c7..cda2553a 100644
--- a/www.i2p2/static/styles/light.css
+++ b/i2p2www/static/styles/light/desktop.css
@@ -25,7 +25,7 @@ img {
   border: none
 }
 
-div.logo {
+a#logo {
   float: left;
 /*  left: 1em;
   top: 1em;
@@ -38,7 +38,23 @@ div.logo {
   font-color: #fff;
 }
 
-div.menu {
+a#logo img {
+  filter:alpha(opacity=100);
+  -moz-opacity: 1.0;
+  opacity: 1.0;
+}
+
+a#logo:hover img {
+  filter:alpha(opacity=60);
+  -moz-opacity: 0.6;
+  opacity: 0.6;
+}
+
+div#topbar ul.languages {
+  display: none;
+}
+
+div#cssmenu {
   /* width: 8em; */
   /* height: 5em; */
   /* position: fixed; */
@@ -48,7 +64,7 @@ div.menu {
   /*margin: 0em;*/
 /*  padding: .5em;*/
   margin: 0px 20px 20px 0px;
-  padding: 5px 20px 20px 20px;
+  padding: 5px 20px 20px 0;
   text-align: left;
   border: 1px solid #000022;
   border-top: 1px solid #000;
@@ -63,7 +79,7 @@ div.menu {
 }
 
 /*
-div.menu a:link {
+div#cssmenu a:link {
 border:1px solid #000022;
 border-left: 3px solid #000022;
 margin: 10px 0;
@@ -74,6 +90,21 @@ line-height: 240%;
 background-color: #9999ff;
 }
 */
+
+div#cssmenu ul {
+  margin: 0;
+  padding: 5px 0px 5px 20px;
+}
+
+div#cssmenu li {
+  padding: 5px 0px 5px 0px;
+  margin: 0;
+}
+
+div#cssmenu div.menuitem {
+  display: inline;
+}
+
 div.warning {
   margin: 0em 1em 1em 12em;
   padding: .5em 1em;
@@ -83,9 +114,9 @@ div.warning {
   color: inherit;
 }
 
-div.main {
+div#content {
   margin: 0px 0px 0px 0px;
-  padding: 25px 40px 20px 190px;
+  padding: 25px 40px 20px 325px;
   background-color: #eeeeff;
   text-align: justify;
   color: #000011;
@@ -93,7 +124,7 @@ div.main {
   border-bottom: 1px solid #000;
 }
 
-div.main h1 {
+div#content h1 {
   text-align: left;
   color: #000022;
   padding-left: 10px;
diff --git a/i2p2www/static/styles/light/mobile.css b/i2p2www/static/styles/light/mobile.css
new file mode 100644
index 00000000..e69de29b
diff --git a/www.i2p2/static/styles/light_ar.css b/i2p2www/static/styles/light_ar.css
similarity index 89%
rename from www.i2p2/static/styles/light_ar.css
rename to i2p2www/static/styles/light_ar.css
index 88cedcec..cab6bc07 100644
--- a/www.i2p2/static/styles/light_ar.css
+++ b/i2p2www/static/styles/light_ar.css
@@ -25,7 +25,7 @@ img {
   border: none
 }
 
-div.logo {
+a#logo {
   float: right;
 /*  left: 1em;
   top: 1em;
@@ -38,7 +38,23 @@ div.logo {
   font-color: #fff;
 }
 
-div.menu {
+a#logo img {
+  filter:alpha(opacity=100);
+  -moz-opacity: 1.0;
+  opacity: 1.0;
+}
+
+a#logo:hover img {
+  filter:alpha(opacity=60);
+  -moz-opacity: 0.6;
+  opacity: 0.6;
+}
+
+div#topbar ul.languages {
+  display: none;
+}
+
+div#cssmenu {
   /* width: 8em; */
   /* height: 5em; */
   /* position: fixed; */
@@ -48,7 +64,7 @@ div.menu {
   /*margin: 0em;*/
 /*  padding: .5em;*/
   margin: 0px 20px 20px 0px;
-  padding: 5px 20px 20px 20px;
+  padding: 5px 20px 20px 0;
   text-align: right;
   border: 1px solid #000022;
   border-top: 1px solid #000;
@@ -63,7 +79,7 @@ div.menu {
 }
 
 /*
-div.menu a:link {
+div#cssmenu a:link {
 border:1px solid #000022;
 border-left: 3px solid #000022;
 margin: 10px 0;
@@ -74,6 +90,21 @@ line-height: 240%;
 background-color: #9999ff;
 }
 */
+
+div#cssmenu ul {
+  margin: 0;
+  padding: 5px 0px 5px 20px;
+}
+
+div#cssmenu li {
+  padding: 5px 0px 5px 0px;
+  margin: 0;
+}
+
+div#cssmenu div.menuitem {
+  display: inline;
+}
+
 div.warning {
   margin: 0em 1em 1em 12em;
   padding: .5em 1em;
@@ -83,9 +114,9 @@ div.warning {
   color: inherit;
 }
 
-div.main {
+div#content {
   margin: 0px 0px 0px 0px;
-  padding: 30px 200px 20px 19px;
+  padding: 30px 335px 20px 19px;
   background-color: #eeeeff;
   text-align: justify;
   color: #000011;
@@ -93,7 +124,7 @@ div.main {
   border-bottom: 1px solid #000;
 }
 
-div.main h1 {
+div#content h1 {
   text-align: right;
   color: #000022;
   padding-left: 10px;
diff --git a/www.i2p2/static/styles/light_zh.css b/i2p2www/static/styles/light_zh.css
similarity index 89%
rename from www.i2p2/static/styles/light_zh.css
rename to i2p2www/static/styles/light_zh.css
index 337ae867..19a7a671 100644
--- a/www.i2p2/static/styles/light_zh.css
+++ b/i2p2www/static/styles/light_zh.css
@@ -25,7 +25,7 @@ img {
   border: none
 }
 
-div.logo {
+a#logo {
   float: left;
 /*  left: 1em;
   top: 1em;
@@ -38,7 +38,23 @@ div.logo {
   font-color: #fff;
 }
 
-div.menu {
+a#logo img {
+  filter:alpha(opacity=100);
+  -moz-opacity: 1.0;
+  opacity: 1.0;
+}
+
+a#logo:hover img {
+  filter:alpha(opacity=60);
+  -moz-opacity: 0.6;
+  opacity: 0.6;
+}
+
+div#topbar ul.languages {
+  display: none;
+}
+
+div#cssmenu {
   width: 8em;
   /* height: 5em; */
   /* position: fixed; */
@@ -48,7 +64,7 @@ div.menu {
   /*margin: 0em;*/
 /*  padding: .5em;*/
   margin: 0px 20px 20px 0px;
-  padding: 5px 20px 20px 20px;
+  padding: 5px 20px 20px 0;
   text-align: left;
   border: 1px solid #000022;
   border-top: 1px solid #000;
@@ -64,7 +80,7 @@ div.menu {
 }
 
 /*
-div.menu a:link {
+div#cssmenu a:link {
 border:1px solid #000022;
 border-left: 3px solid #000022;
 margin: 10px 0;
@@ -75,6 +91,21 @@ line-height: 240%;
 background-color: #9999ff;
 }
 */
+
+div#cssmenu ul {
+  margin: 0;
+  padding: 5px 0px 5px 20px;
+}
+
+div#cssmenu li {
+  padding: 5px 0px 5px 0px;
+  margin: 0;
+}
+
+div#cssmenu div.menuitem {
+  display: inline;
+}
+
 div.warning {
   margin: 0em 1em 1em 12em;
   padding: .5em 1em;
@@ -84,7 +115,7 @@ div.warning {
   color: inherit;
 }
 
-div.main {
+div#content {
   margin: 0px 0px 0px 0px;
   padding: 25px 40px 20px 190px;
   background-color: #eeeeff;
@@ -95,7 +126,7 @@ div.main {
   line-height: 21px;
 }
 
-div.main h1 {
+div#content h1 {
   text-align: left;
   color: #000022;
   padding-left: 10px;
diff --git a/i2p2www/static/styles/mainmenu.css b/i2p2www/static/styles/mainmenu.css
new file mode 100644
index 00000000..ea350e57
--- /dev/null
+++ b/i2p2www/static/styles/mainmenu.css
@@ -0,0 +1,165 @@
+/*==============================================================================
+
+    GRC multi-level script-free pure-CSS menuing system stylesheet.
+   This code is hereby placed into the public domain by its author
+   Steve Gibson. It may be freely used for any purpose whatsoever.
+
+    Computed Geometries:    with a default 12px font, 1.0em == 12px and
+    1px == 0.08333em.
+    Thus, our 98px wide Freeware & Research buttons are 8.166666em wide.
+
+                      PUBLIC DOMAIN CONTRIBUTION NOTICE
+   This work has been explicitly placed into the Public Domain for the
+    benefit of anyone who may find it useful for any purpose whatsoever.
+
+==============================================================================*/
+
+ /*========================= TOP OF THE MENU CASCADE =========================*/
+
+#cssmenu {
+    position:relative;        /* establish a menu-relative positioning context */
+    float:left;                                     /* play nicely with others */
+    margin:0;
+    padding:0;
+    border:0;
+    height:24px;                                  /* the menu's overall height */
+}
+
+#cssmenu img {
+    vertical-align: top;      /* prevent images from being pushed down by text */
+}
+
+#cssmenu ul {
+    margin:0;
+    list-style-type:none;          /* we don't want to view the list as a list */
+    line-height:1.5em;           /* globally set the menu's item spacing. note */
+}                               /* this must be 1.0 or 1.5 or 2.0 for Mozilla */
+
+#cssmenu li {
+    float:left;    /* this creates the side-by-side array of top-level buttons */
+    position:relative;    /* create local positioning contexts for each button */
+    margin:0;
+    margin-right: 2em;
+}
+
+.drop {
+    display:block;
+    padding:0px 0.33em;           /* this sets the l/r margins for our menu item */
+    margin:0;
+    text-align:right;   /* this right alignment goes with the float:left below */
+    cursor:pointer;      /* IE tries to switch back to an I-beam, don't let it */
+    cursor:hand;           /* IE5 only knows about "hand", so set it both ways */
+}
+
+.drop span {        /* this simultaneously left and right aligns the text and */
+    float:left;       /* the >> in the drop-down menus which link to sub-menus */
+}
+
+.rightmenu {
+    position:relative;  /* establish a local positioning context for YAH label */
+    float:right;                  /* and right-align it at the top of our page */
+}
+
+/*======================== TOP LEVEL MENU DEFINITIONS ========================*/
+
+#cssmenu ul li ul {
+    display:none;                  /* initially hide the entire list hierarchy */
+    padding:1px;                               /* this is our box border width */
+}
+
+#cssmenu ul li a,
+#cssmenu ul li a:visited {                    /* unselected top-level menu items */
+    display:block;
+    float:left;
+    text-decoration:none;
+    height:24px;
+}
+
+/*======================== 2ND LEVEL MENU DEFINITIONS ========================*/
+
+#cssmenu ul li:hover ul,
+#cssmenu ul li a:hover ul {                           /* 2nd level drop-down box */
+    display:block;
+    position:absolute;
+    margin:0;
+    top:24px;              /* place us just up underneath the top-level images */
+    left:-1px;       /* left-align our drop-down to the previous button border */
+    height:auto;      /* the drop-down height will be determiend by line count */
+    width:13.5em;
+    color:black;                        /* this sets the unselected-text color */
+    background:black;         /* this sets our menu's effective "border" color */
+}
+
+#cssmenu ul li:hover ul.leftbutton,
+#cssmenu ul li a:hover ul.leftbutton {/* our first dropdown should not be skewed */
+    left:0px;
+}
+
+#cssmenu ul li:hover ul.skinny,
+#cssmenu ul li a:hover ul.skinny {             /* 2nd level skinny drop-down box */
+    width:8.08333em;   /* with a 12px default font, this is 97px width (97/12) */
+}
+
+#cssmenu ul.rightmenu li:hover ul,
+#cssmenu ul.rightmenu li a:hover ul {    /* 2nd level neighborhood drop-down box */
+    left:auto;
+    right:0;         /* nudge the right menu right to line up under the border */
+    width:400px;      /* with a 12px default font, this is 228px width (228/12) */
+}
+
+* html #cssmenu ul.rightmenu li a:hover ul {         /* IE5/6 needs a tweak here */
+    right:-1px;
+}
+
+#cssmenu ul li:hover ul li a,
+#cssmenu ul li a:hover ul li a {                   /* 2nd level unselected items */
+    border:0;
+    margin:0;
+    padding:0;
+    height:auto;
+    color:#000;               /* this sets the unselected drop-down text color */
+    background:#d8d8d8;       /* this sets the drop-down menu background color */
+    width:13.5em;
+}
+
+#cssmenu ul li:hover ul li:hover a,
+#cssmenu ul li a:hover ul li a:hover {                /* 2nd level selected item */
+    color:black;
+    background:white;
+}
+
+#cssmenu ul li:hover ul.skinny li a,
+#cssmenu ul li a:hover ul.skinny li a,
+#cssmenu ul li:hover ul.skinny li a:hover,
+#cssmenu ul li a:hover ul.skinny li a:hover {     /* 2nd level un+selected items */
+    width:8.08333em;
+}
+
+/*======================== 3RD LEVEL MENU DEFINITIONS ========================*/
+
+#cssmenu ul li:hover ul li ul,
+#cssmenu ul li a:hover ul li a ul {             /* hide inactive 3rd-level menus */
+    visibility:hidden;
+}
+
+#cssmenu ul li:hover ul li:hover ul,
+#cssmenu ul li a:hover ul li a:hover ul {             /* 3rd level drop-down box */
+    visibility:visible;
+    position:absolute;
+    margin-top:-1px;          /* bring the top edge of the 3rd level menu up one */
+    top:0;
+    left:8.08333em;
+    width:14em;
+}
+
+#cssmenu ul li:hover ul li:hover ul li a,
+#cssmenu ul li a:hover ul li a:hover ul li a {     /* 3rd level unselected items */
+    width:14em;
+    background:#d8d8d8;
+}
+
+#cssmenu ul li:hover ul li:hover ul li a:hover,
+#cssmenu ul li a:hover ul li a:hover ul li a:hover {    /* level3 selected items */
+    width:14em;
+    background:white;
+}
diff --git a/i2p2www/templatevars.py b/i2p2www/templatevars.py
new file mode 100644
index 00000000..cd3660bd
--- /dev/null
+++ b/i2p2www/templatevars.py
@@ -0,0 +1,103 @@
+from flask import g, request, safe_join, url_for
+import os.path
+
+from i2p2www import CANONICAL_DOMAIN, CURRENT_I2P_VERSION, STATIC_DIR, app
+
+I2P_TO_CLEAR = {
+    'www.i2p2.i2p': 'www.i2p2.de',
+    #'forum.i2p': 'forum.i2p2.de',
+    'trac.i2p2.i2p': 'trac.i2p2.de',
+    'mail.i2p': 'i2pmail.org',
+    }
+
+
+####################
+# Template functions
+
+@app.context_processor
+def utility_processor():
+    # Shorthand for getting a site url
+    def get_site_url(path=None):
+        lang = 'en'
+        if hasattr(g, 'lang') and g.lang:
+            lang = g.lang
+        if path:
+            return url_for('site_show', lang=lang, page=path)
+        else:
+            return url_for('site_show', lang=lang)
+
+    # Shorthand for getting a language-specific url
+    def get_url_with_lang(endpoint, **args):
+        lang = 'en'
+        if hasattr(g, 'lang') and g.lang:
+            lang = g.lang
+        return url_for(endpoint, lang=lang, **args)
+
+    # Get a specific language flag, or the flag for the current language
+    def get_flag(lang=None):
+        if not lang:
+            if hasattr(g, 'lang') and g.lang:
+                lang = g.lang
+            else:
+                lang = 'en'
+        return url_for('static', filename='images/flags/'+lang+'.png')
+
+    # Provide the canonical link to the current page
+    def get_canonical_link():
+        protocol = request.url.split('//')[0]
+        return protocol + '//' + CANONICAL_DOMAIN + request.path
+
+    # Convert an I2P url to an equivalent clearnet one
+    def convert_url_to_clearnet(value):
+        if not value.endswith('.i2p'):
+            # The url being passed in isn't an I2P url, so just return it
+            return value
+        if request.headers.get('X-I2P-Desthash') and not request.headers.get('X-Forwarded-Server'):
+            # The request is from within I2P, so use I2P url
+            return value
+        # The request is either directly from clearnet or through an inproxy
+        try:
+            # Return the known clearnet url corresponding to the I2P url
+            return I2P_TO_CLEAR[value]
+        except KeyError:
+            # The I2P site has no known clearnet address, so use an inproxy
+            return value + '.to'
+
+    # Convert a paginated URL to that of another page
+    def url_for_other_page(page):
+        args = request.view_args.copy()
+        args['page'] = page
+        return url_for(request.endpoint, **args)
+
+    # Change the theme of the current page
+    def change_theme(theme):
+        args = {}
+        if request.view_args:
+            args = request.view_args.copy()
+        args['theme'] = theme
+        if request.endpoint:
+            return url_for(request.endpoint, **args)
+        # Probably a 404 error page
+        return url_for('main_index', **args)
+
+    # Shorthand for getting the logo for the current theme
+    def get_logo_for_theme():
+        logo = 'styles/' + g.theme + '/images/i2plogo.png'
+        if not os.path.isfile(safe_join(STATIC_DIR, logo)):
+            logo = 'images/i2plogo.png'
+        return logo
+
+    def get_current_version(string=None):
+        if string:
+            return string % CURRENT_I2P_VERSION
+        return CURRENT_I2P_VERSION
+
+    return dict(i2pconv=convert_url_to_clearnet,
+                url_for_other_page=url_for_other_page,
+                change_theme=change_theme,
+                logo_url=get_logo_for_theme,
+                site_url=get_site_url,
+                get_url=get_url_with_lang,
+                get_flag=get_flag,
+                ver=get_current_version,
+                canonical=get_canonical_link)
diff --git a/i2p2www/translations/de/LC_MESSAGES/messages.po b/i2p2www/translations/de/LC_MESSAGES/messages.po
new file mode 100644
index 00000000..f5bec46b
--- /dev/null
+++ b/i2p2www/translations/de/LC_MESSAGES/messages.po
@@ -0,0 +1,2639 @@
+# German translations for I2P website.
+# Copyright (C) 2008 I2P
+# This file is distributed under the same license as the I2P website
+# project.
+# amiga4000 , 2008.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: I2P website\n"
+"Report-Msgid-Bugs-To: EMAIL@ADDRESS\n"
+"POT-Creation-Date: 2013-01-18 11:24+0000\n"
+"PO-Revision-Date: 2013-01-19 00:47+1200\n"
+"Last-Translator: echelon \n"
+"Language-Team: de \n"
+"Plural-Forms: nplurals=2; plural=(n != 1)\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Generated-By: Babel 0.9.6\n"
+
+#: i2p2www/pages/blog/index.html:2
+msgid "Blog Index"
+msgstr ""
+
+#: i2p2www/pages/blog/index.html:4
+#: i2p2www/pages/site/index.html:75
+msgid "I2P Blog ATOM Feed"
+msgstr ""
+
+#: i2p2www/pages/blog/latest.html:5
+msgid "More blog posts…"
+msgstr ""
+
+#: i2p2www/pages/blog/post.html:2
+#: i2p2www/pages/global/nav.html:92
+msgid "Blog"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:4
+msgid "Debian I2P Packages"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:6
+#, python-format
+msgid ""
+"The packages hosted on the I2P Launchpad site\n"
+"have been tested and should work on x86/x86_64 platforms running:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:11
+msgid "Ubuntu (Hardy 8.04 and newer)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:13
+msgid "Debian Linux (Lenny and newer) & kFreeBSD (Wheezy)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:21
+#, python-format
+msgid ""
+"The I2P packages may work on systems not listed above. Please report any issues\n"
+"with these packages on Trac at\n"
+"http://%(trac)s."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:27
+msgid "Option 1: Recent versions of Ubuntu and its derivatives (Try this if you're not using Debian)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:28
+msgid "Option 2: Debian (including systems based on Debian and older versions of Ubuntu)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:29
+msgid "Option 3: Non-Linux (and possibly Non-x86 architectures)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:32
+msgid "Instructions for Ubuntu Lucid Lynx (and newer) and derivatives like Linux Mint & Trisquel"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:33
+msgid "Adding the PPA via the command line and installing I2P"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:36
+msgid "Open a terminal and enter:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:38
+msgid ""
+"This command will add the PPA to /etc/apt/sources.list.d and fetch the\n"
+"gpg key that the repository has been signed with. The GPG key ensures\n"
+"that the packages have not been tampered with since being built."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:45
+msgid "Notify your package manager of the new PPA by entering:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:47
+msgid ""
+"This command will retrieve the latest list of software from each\n"
+"repository that is enabled on your system, including the I2P PPA that\n"
+"was added with the earlier command."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:53
+#: i2p2www/pages/downloads/debian.html:118
+#: i2p2www/pages/downloads/debian.html:141
+msgid "You are now ready to install I2P!"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:57
+msgid "Adding the PPA Using Synaptic"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:60
+msgid "Open Synaptic (System -> Administration -> Synaptic Package Manager)."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:65
+msgid "Once Synaptic opens, select Repositories from the Settings menu."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:70
+msgid "Click the Other Sources tab and click Add. Paste ppa:i2p-maintainers/i2p into the APT-line field and click Add Source. Click the Close button then Reload."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:75
+msgid "In the Quick Filter box, type in i2p and press enter. When i2p is returned in the results list, right click i2p and select Mark for Installation. After doing so you may see a Mark additional required changes? popup. If so, click Mark then Apply."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:81
+msgid ""
+"After the installation process completes you can move on to the next\n"
+"part of starting I2P and configuring it for your system."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:86
+msgid "Instructions for Debian Lenny and newer"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:88
+msgid ""
+"The steps below should be performed with root access (i.e., switching\n"
+"user to root with \"su\" or by prefixing each command with \"sudo\")."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:94
+msgid "Add the GPG key that signs the repository with the following command:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:96
+msgid "You'll have output like the following if the command was successful:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:100
+msgid "For Debian Oldstable (Lenny) and Stable (Squeeze): Add the following entries to /etc/apt/sources.list.d/i2p.list"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:104
+msgid "For Debian Testing (Wheezy) or Unstable (Sid), use the following:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:109
+msgid "Notify your package manager of the new PPA by entering"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:111
+msgid ""
+"This command will retrieve the latest list of software from every\n"
+"repository enabled on your system, including the I2P PPA added in step\n"
+"1."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:122
+#: i2p2www/pages/downloads/debian.html:151
+msgid "After the installation process completes you can move on to the next part of starting I2P and configuring it for your system."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:126
+msgid "Instructions for Non-Linux / Non-x86"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:128
+msgid ""
+"The steps below should be performed with root access (i.e., switching\n"
+"user to root with \"su\" or by prefixing each command with \"sudo\")."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:134
+msgid "Download the i2p-router package from the PPA."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:139
+msgid "Make sure that you have Java installed. Running apt-get install default-jre should be sufficient."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:145
+#, python-format
+msgid "It is recommended to compile jbigi for your system to achieve better performance. Instructions are available here."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:155
+#: i2p2www/pages/downloads/list.html:163
+msgid "Post-install work"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:158
+msgid ""
+"Using these I2P packages the I2P router can be started in the following\n"
+"three ways:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:164
+msgid ""
+""on demand" using the i2prouter script. Simply run "i2prouter\n"
+"start" from a command prompt. (Note: Do not use\n"
+"sudo or run it as root!)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:171
+msgid ""
+""on demand" without the java service wrapper\n"
+"(needed on non-Linux/non-x86 systems) by running \"i2prouter-nowrapper\".\n"
+"(Note: Do not\n"
+"use sudo or run it as root!)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:179
+msgid ""
+"as a service that automatically runs when your system boots, even\n"
+"before logging in. The service can be enabled with \"dpkg-reconfigure\n"
+"i2p\" as root or using sudo. This is the recommended means of operation."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:187
+msgid ""
+"When installing for the first time, please remember to adjust your NAT/firewall\n"
+"if you can. The ports to forward can be found on the \n"
+"network configuration page in the router console. If guidance with respect to forwarding ports is needed,\n"
+"you may portforward.com to be helpful."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:194
+msgid ""
+"Please review and adjust the bandwidth settings on the\n"
+"configuration page,\n"
+"as the default settings of 96 KB/s down / 40 KB/s up are fairly conservative."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:200
+#: i2p2www/pages/downloads/list.html:196
+#, python-format
+msgid "If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy howto."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:2
+#: i2p2www/pages/downloads/select.html:12
+#: i2p2www/pages/global/nav.html:3
+msgid "Download"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:4
+msgid "Download I2P"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:6
+msgid "Dependency"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:7
+msgid ""
+"\n"
+"Java Runtime 1.5 or higher.\n"
+"(Oracle/Sun Java Version 6,\n"
+"OpenJDK 6, or\n"
+"IcedTea6\n"
+" recommended)\n"
+"
            \n"
+"Determine your installed Java version here\n"
+"or type java -version at your command prompt.\n"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:18
+msgid "Clean installs"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:32
+msgid "Download that file and run it."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:49
+msgid ""
+"Download that file and double-click it (if that works) or\n"
+"    type java -jar i2pinstall_0.9.4-1_osx.jar in a terminal to run the\n"
+"    installer.\n"
+"    You may be able to right-click and select\n"
+"    "Open with Java"."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:57
+#, python-format
+msgid ""
+"Due to a wrapper bug, the 0.9.4 installer\n"
+"      will NOT work on OS X. Use the fixed 0.9.4-1 OSX installer above."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:63
+#: i2p2www/pages/downloads/list.html:90
+msgid "Command line (headless) install:"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:64
+msgid ""
+"Download the 0.9.4-1 OSX graphical installer file above and\n"
+"    run java -jar i2pinstall_0.9.4-1_osx.jar -console from the command line."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:82
+#, python-format
+msgid ""
+"Download that file and double-click it (if that works) or\n"
+"    type java -jar i2pinstall_%(i2pversion)s.jar in a terminal to run the\n"
+"    installer.\n"
+"    On some platforms you may be able to right-click and select\n"
+"    "Open with Java"."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:91
+#, python-format
+msgid ""
+"Download the graphical installer file above and\n"
+"    run java -jar i2pinstall_%(i2pversion)s.jar -console from the command line."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:101
+msgid "Packages for Debian & Ubuntu are available."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:116
+#, python-format
+msgid ""
+"The Android version of I2P is being actively developed.\n"
+"    The latest dev build is version 0.9.3-5_b2-API8, and is available from\n"
+"    sponge's eepsite -\n"
+"    scan or click the QR code."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:123
+msgid ""
+"The release and dev versions of the I2P APK are not compatible, as they\n"
+"      are signed by zzz and sponge respectively. Uninstall one before installing\n"
+"      the other."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:133
+msgid "Source package"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:143
+#, python-format
+msgid ""
+"Alternately, you can fetch the source from monotone.\n"
+"    
            \n"
+"    Run (tar xjvf i2psource_%(i2pversion)s.tar.bz2 ; cd i2p-%(i2pversion)s ; ant pkg) then either\n"
+"    run the GUI installer or headless install as above."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:154
+#, python-format
+msgid ""
+"The files are signed by zzz,\n"
+"whose key is here."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:159
+msgid "I2P can also be downloaded from our project pages on Launchpad and Google Code."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:165
+msgid ""
+"After running the installer on windows, simply click on the \"Start I2P\" button\n"
+"which will bring up the router console,\n"
+"which has further instructions."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:171
+msgid ""
+"On Unix-like systems, I2P can be started as a service\n"
+"using the \"i2prouter\" script, located in the directory you selected for I2P.\n"
+"Changing to that directory in a console and issuing \"sh i2prouter status\"\n"
+"should tell you the router's status. The arguments \"start\", \"stop\" and \"restart\"\n"
+"control the service. The router console\n"
+"can be accessed at its usual location.\n"
+"For users on OpenSolaris and other systems for which the wrapper (i2psvc) is not supported,\n"
+"start the router with \"sh runplain.sh\" instead."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:182
+#, python-format
+msgid ""
+"When installing for the first time, please remember to adjust your NAT/firewall\n"
+"if you can, bearing in mind the Internet-facing ports I2P uses,\n"
+"described here among other ports.\n"
+"If you have successfully opened your port to inbound TCP, also enable inbound TCP on the\n"
+"configuration page."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:190
+msgid ""
+"Also, please review and adjust the bandwidth settings on the\n"
+"configuration page,\n"
+"as the default settings of 96 KBps down / 40 KBps up are fairly slow."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:200
+msgid "Updates from earlier releases:"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:202
+msgid "Both automatic and manual upgrades are available for the release."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:207
+msgid "Automatic updates"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:209
+msgid ""
+"If you are running 0.7.5 or later, your router should detect the\n"
+"new release. To upgrade simply click the 'Download Update' button on your router console\n"
+"when it appears."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:215
+msgid ""
+"Due to a bug in release 0.7.6, those whose first I2P installation was that version\n"
+"and have not upgraded manually\n"
+"may get a \"downloaded version is not greater than current version\" error,\n"
+"and should use the manual update method below."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:223
+#, python-format
+msgid ""
+"If you are running 0.7.4 or earlier, please see\n"
+"the 0.7.5 release notes\n"
+"for important information about how to configure your router to automatically\n"
+"receive the release."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:231
+#, python-format
+msgid ""
+"If you are running 0.6.1.30 or earlier, please see\n"
+"instructions\n"
+"for important information about how to configure your router to automatically\n"
+"receive the release."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:240
+#, python-format
+msgid ""
+"If you have reconfigured your router following the instructions, you should see a link on your \n"
+"    router console allowing\n"
+"    you to download and install the new release by just clicking on that\n"
+"    link."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:248
+msgid "Alternately, you can use the manual method specified below."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:258
+msgid "Manual updates"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:270
+msgid ""
+"Download that file to your I2P\n"
+"    installation directory and rename as i2pupdate.zip.\n"
+"    (alternately, you can get the source as above and run \"ant updater\", then copy the\n"
+"    resulting i2pupdate.zip to your I2P installation directory).  You do \n"
+"    NOT need to unzip that file."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:279
+msgid "Click \"Restart\""
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:284
+msgid "Grab a cup of coffee and come back in 11 minutes"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:292
+#, python-format
+msgid ""
+"The file is signed by zzz,\n"
+"whose key is here."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:297
+msgid "Previous Releases"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:299
+#, python-format
+msgid ""
+"Previous releases are available on Google Code\n"
+"and Launchpad\n"
+"and within the I2P network on %(echelon)s."
+msgstr ""
+
+#: i2p2www/pages/downloads/select.html:2
+#: i2p2www/pages/downloads/select.html:4
+msgid "Mirror selection"
+msgstr ""
+
+#: i2p2www/pages/downloads/select.html:5
+msgid "File:"
+msgstr ""
+
+#: i2p2www/pages/downloads/select.html:10
+msgid "Any mirror"
+msgstr ""
+
+#: i2p2www/pages/global/error_404.html:3
+msgid "Not found"
+msgstr ""
+
+#: i2p2www/pages/global/error_404.html:9
+msgid "Yep... the resource, you were searching for, is named differently, doesn't exist or was removed."
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:5
+msgid "Server error"
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:13
+msgid "500 Server error"
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:17
+msgid "Umm... the server encountered some sort of error."
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:2
+msgid "Themes"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:4
+msgid "Duck"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:5
+msgid "Danimoth"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:6
+msgid "Light"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:7
+msgid "Dark"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:8
+msgid "Barebones styling"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:9
+msgid "Dropdown menu only"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:13
+msgid "Mirrors"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:21
+msgid "Secure"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:27
+msgid "Misc."
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:30
+#: i2p2www/pages/site/links.html:2
+msgid "Links"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:31
+msgid "Impressum"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:35
+msgid "T-Shirts!"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:37
+msgid "Europe"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:38
+msgid "USA"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:42
+msgid "Donate"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:19
+msgid "Skip navigation"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:22
+msgid "I2P Logo"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:22
+msgid "Invisible Internet Project (I2P)"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:46
+#, python-format
+msgid "This page was last updated in %(lastupdated)s and is accurate for router version %(accuratefor)s."
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:50
+#, python-format
+msgid "This page was last updated in %(lastupdated)s."
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:54
+#, python-format
+msgid "This page is accurate for router version %(accuratefor)s."
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:4
+msgid "About"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:6
+msgid "Introduction to I2P"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:7
+msgid "Comparisons"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:9
+msgid "Overview of comparisons"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:10
+msgid "Tor"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:11
+msgid "Freenet"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:13
+msgid "Other anonymous networks"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:16
+msgid "Documentation"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:18
+msgid "Documentation index"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:19
+msgid "How does it work?"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:21
+msgid "Gentle intro"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:22
+msgid "Tech intro"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:23
+msgid "Threat model"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:24
+msgid "Garlic routing"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:25
+msgid "Network database"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:26
+msgid "Tunnel routing"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:27
+msgid "Peer selection"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:28
+msgid "Cryptography"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:29
+msgid "ElGamal/AES+SessionTags"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:32
+#: i2p2www/pages/global/nav.html:113
+msgid "Applications"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:34
+msgid "Supported applications"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:35
+msgid "Bittorrent"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:38
+msgid "API"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:40
+msgid "I2PTunnel"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:41
+msgid "SOCKS"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:42
+msgid "SAM v1"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:43
+msgid "SAM v2"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:44
+msgid "SAM v3"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:45
+msgid "BOB"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:46
+msgid "Streaming library"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:47
+msgid "Ministreaming library"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:48
+msgid "I2PControl"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:51
+msgid "Protocols"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:53
+msgid "Protocol stack"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:58
+msgid "Transports"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:60
+msgid "Transport layer overview"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:61
+msgid "NTCP"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:62
+msgid "SSU"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:65
+msgid "Specifications"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:67
+msgid "Blockfile"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:68
+msgid "Common structures"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:69
+msgid "Configuration files"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:70
+msgid "Datagrams"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:73
+#: i2p2www/pages/global/nav.html:88
+msgid "Plugins"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:75
+msgid "Tunnel creation"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:76
+msgid "Tunnel messages"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:77
+msgid "Software updates"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:80
+msgid "Tunnels"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:82
+msgid "Tunnel implementation"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:83
+msgid "Unidirectional tunnels"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:84
+msgid "Old implementation"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:87
+msgid "Naming and addressbook"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:91
+msgid "Team"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:93
+msgid "Hall of Fame"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:94
+msgid "Academic papers and peer review"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:95
+msgid "Presentations, tutorials and articles"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:96
+msgid "Contact us"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:99
+msgid "Help"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:101
+msgid "FAQ"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:102
+msgid "How to browse I2P"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:103
+msgid "Glossary"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:104
+msgid "Performance"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:105
+#: i2p2www/pages/site/contact.html:22
+msgid "Forums"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:108
+msgid "Volunteer"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:110
+msgid "Get involved!"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:111
+msgid "Develop"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:114
+msgid "Licenses"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:115
+msgid "Release signing keys"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:116
+msgid "Signed keys"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:117
+msgid "Developers keys"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:118
+msgid "Bug tracker"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:121
+msgid "Academic research"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:122
+msgid "Guides"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:124
+msgid "New developers"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:125
+msgid "Using an IDE with I2P"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:126
+msgid "Developer guidelines and coding style"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:127
+msgid "New translators"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:130
+msgid "Bounties"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:131
+#: i2p2www/pages/meetings/index.html:2
+msgid "Meetings"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:132
+msgid "Roadmap"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:133
+msgid "Task list"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:136
+msgid "Language"
+msgstr ""
+
+#: i2p2www/pages/meetings/index.html:4
+msgid "I2P Meetings ATOM Feed"
+msgstr ""
+
+#: i2p2www/pages/meetings/index.html:7
+msgid "Logs of past I2P meetings"
+msgstr ""
+
+#: i2p2www/pages/meetings/index.html:9
+#, python-format
+msgid ""
+"If you have something to discuss, please find the developers on IRC in #i2p-dev.\n"
+"Status updates from developers are also available."
+msgstr ""
+
+#: i2p2www/pages/meetings/show.html:2
+#, python-format
+msgid "I2P Development Meeting %(id)s"
+msgstr ""
+
+#: i2p2www/pages/meetings/show.html:10
+msgid "Full IRC Log"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:2
+msgid "Contact"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:5
+msgid ""
+"Our primary IRC network is the Irc2P network within I2P; a default tunnel to this network is set up with new router installs.\n"
+"  We are also present on multiple standard networks like OFTC,\n"
+"  EIN and Freenode.\n"
+"  All I2P-related channels on all these network are linked to the main channels on Irc2P via relay bots."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:13
+msgid "Channel list:"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:15
+msgid "General i2p discussion"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:16
+msgid "Offtopic"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:17
+msgid "Development talk"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:18
+msgid "Help channel"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:23
+#, python-format
+msgid "Most of the discussion about I2P's development happens on the I2P developer forum. This is usually the best place to start with inquiries, if the dev IRC channel is inactive."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:27
+msgid "Mailing lists"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:28
+msgid "I2P does have a mailing list, but it is rarely used as the current small team of developers prefer to communicate via IRC or the developer forum. This may change in future."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:33
+msgid "Subscribing"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:34
+msgid "To subscribe to a mailing list, go to the list information page (linked below) and fill out the form. I2P-internal email addresses (foobar@mail.i2p) can be used."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:38
+msgid "Unsubscribing"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:39
+msgid "To unsubscribe from a mailing list or edit your subscription options, go to the list information page (linked below) and enter your subscription email address."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:43
+msgid "Lists"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:46
+msgid "Archive"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:47
+msgid "General I2P discussion - anything that doesn't fit in a different list goes here."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:53
+msgid "You don't like mailing lists? Then this is for you. All mailing lists are available via NNTP as well."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:58
+msgid "Group-List-mapping:"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:62
+msgid "Servers:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:2
+msgid "Frequently Asked Questions"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:4
+msgid "Index"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:7
+msgid "General"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:9
+#: i2p2www/pages/site/faq.html:51
+msgid "What systems will I2P run on?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:10
+msgid "Whats an \"eepsite\" and how do I configure my browser so I can use them?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:11
+#: i2p2www/pages/site/faq.html:263
+msgid "My router has very few active peers, is this OK?"
+msgstr "Mein Router hat sehr wenige  aktive Peers, ist das OK?"
+
+#: i2p2www/pages/site/faq.html:12
+#: i2p2www/pages/site/faq.html:496
+msgid "What do the Active x/y numbers mean in the router console?"
+msgstr "Was bedeuten die Active x/y Nummern in der Router Konsole?"
+
+#: i2p2www/pages/site/faq.html:13
+#: i2p2www/pages/site/faq.html:225
+msgid "My active peers / known peers / participating tunnels / connections / bandwidth vary dramatically over time! Is anything wrong?"
+msgstr "Meine active Peers / known Peers / Participating Tunnel / Verbindungen / Bandbeite ändern sich stark! Ist irgendwas kaputt?"
+
+#: i2p2www/pages/site/faq.html:14
+#: i2p2www/pages/site/faq.html:348
+msgid "Is using an outproxy safe?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:15
+#: i2p2www/pages/site/faq.html:374
+msgid "Most of the eepsites within I2P are down?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:16
+#: i2p2www/pages/site/faq.html:525
+msgid "What ports does I2P use?"
+msgstr "Welche Ports werden von I2P genutzt?"
+
+#: i2p2www/pages/site/faq.html:17
+msgid "Why is I2P listening for connections on port 32000?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:18
+#: i2p2www/pages/site/faq.html:62
+msgid "I think I found a bug, where can I report it?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:19
+#: i2p2www/pages/site/faq.html:107
+msgid "What happened to *.i2p.net? What happened to jrandom? Is I2P dead?"
+msgstr "Was passierte mit *.i2p.net? Was passierte mit jrandom? Ist I2P tot?"
+
+#: i2p2www/pages/site/faq.html:20
+#: i2p2www/pages/site/faq.html:843
+msgid "I have a question!"
+msgstr "Ich habe eine Frage!"
+
+#: i2p2www/pages/site/faq.html:22
+msgid "Setup"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:24
+#: i2p2www/pages/site/faq.html:232
+msgid "My router has been up for several minutes and has zero or very few connections"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:25
+#: i2p2www/pages/site/faq.html:390
+msgid "Why is I2P so slow?"
+msgstr "Warum ist I2P so langsam?"
+
+#: i2p2www/pages/site/faq.html:26
+#: i2p2www/pages/site/faq.html:79
+msgid "I'm missing lots of hosts in my addressbook. What are some good subscription links?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:27
+#: i2p2www/pages/site/faq.html:383
+msgid "How do I set up my own eepsite?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:28
+#: i2p2www/pages/site/faq.html:416
+msgid "Bittorrent / I2PSnark / Azureus I2P Plugin Questions?"
+msgstr "Bittorrent / I2PSnark / Azureus I2P Plugin Fragen?"
+
+#: i2p2www/pages/site/faq.html:29
+#: i2p2www/pages/site/faq.html:423
+msgid "How do I connect to IRC within I2P?"
+msgstr "Wie verbinde ich mich mit dem IRC innerhalb von I2P?"
+
+#: i2p2www/pages/site/faq.html:30
+#: i2p2www/pages/site/faq.html:281
+msgid "I can't access regular Internet sites through I2P."
+msgstr "Ich kann keine normalen Internetseiten über I2P erreichen."
+
+#: i2p2www/pages/site/faq.html:31
+#: i2p2www/pages/site/faq.html:296
+msgid "I can't access https:// or ftp:// sites through I2P."
+msgstr "Ich kann keine https:// oder ftp:// Seiten ü I2P besuchen."
+
+#: i2p2www/pages/site/faq.html:32
+#: i2p2www/pages/site/faq.html:504
+msgid "Is it possible to use I2P as a SOCKS proxy?"
+msgstr "Ist es möglich, I2P als SOCKS Proxy zu nutzen?"
+
+#: i2p2www/pages/site/faq.html:33
+#: i2p2www/pages/site/faq.html:487
+msgid "How do I configure my browser?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:34
+#: i2p2www/pages/site/faq.html:432
+msgid "How can I access the web console from my other machines or password protect it?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:35
+#: i2p2www/pages/site/faq.html:472
+msgid "How can I use applications from my other machines?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:36
+#: i2p2www/pages/site/faq.html:746
+msgid "How do I reseed manually?"
+msgstr "Wie reseede ich manuell?"
+
+#: i2p2www/pages/site/faq.html:37
+#: i2p2www/pages/site/faq.html:124
+msgid "My router is using too much CPU?!?"
+msgstr "Mein Router nutzt viel zu viel CPU?!?"
+
+#: i2p2www/pages/site/faq.html:39
+msgid "Misconception"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:41
+#: i2p2www/pages/site/faq.html:366
+msgid "How do I access IRC, BitTorrent, or other services on the regular Internet?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:42
+msgid "Is my router an \"exit node\"(outproxy) to the regular Internet? I don't want it to be."
+msgstr "Ist mein Router ein \"Exit Punkt\" ins normale Internet? Das will ich nicht!"
+
+#: i2p2www/pages/site/faq.html:43
+#: i2p2www/pages/site/faq.html:188
+#, fuzzy
+msgid "I am opposed to certain types of content. How do I keep from distributing, storing, or accessing them?"
+msgstr "ich mag einen bestimmten Teil der Daten/Inhalte nicht. Wie kann ich verhindern, das ich diese verbreite, speichere oder auf sie zugreifen kann?"
+
+#: i2p2www/pages/site/faq.html:45
+msgid "Errors and Their Solutions"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:47
+#: i2p2www/pages/site/faq.html:782
+msgid "I'm using FreeBSD and when I start I2P I receive an error about libm.so.4!"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:48
+msgid "In wrapper.log I see an error stating Protocol family unavailable when I2P is loading"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:52
+#: i2p2www/pages/site/faq.html:63
+#: i2p2www/pages/site/faq.html:80
+#: i2p2www/pages/site/faq.html:108
+#: i2p2www/pages/site/faq.html:125
+#: i2p2www/pages/site/faq.html:189
+#: i2p2www/pages/site/faq.html:226
+#: i2p2www/pages/site/faq.html:233
+#: i2p2www/pages/site/faq.html:264
+#: i2p2www/pages/site/faq.html:273
+#: i2p2www/pages/site/faq.html:282
+#: i2p2www/pages/site/faq.html:297
+#: i2p2www/pages/site/faq.html:349
+#: i2p2www/pages/site/faq.html:367
+#: i2p2www/pages/site/faq.html:375
+#: i2p2www/pages/site/faq.html:384
+#: i2p2www/pages/site/faq.html:391
+#: i2p2www/pages/site/faq.html:417
+#: i2p2www/pages/site/faq.html:424
+#: i2p2www/pages/site/faq.html:433
+#: i2p2www/pages/site/faq.html:473
+#: i2p2www/pages/site/faq.html:480
+#: i2p2www/pages/site/faq.html:488
+#: i2p2www/pages/site/faq.html:497
+#: i2p2www/pages/site/faq.html:505
+#: i2p2www/pages/site/faq.html:526
+#: i2p2www/pages/site/faq.html:734
+#: i2p2www/pages/site/faq.html:747
+#: i2p2www/pages/site/faq.html:783
+#: i2p2www/pages/site/faq.html:815
+#: i2p2www/pages/site/faq.html:844
+msgid "link"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:53
+#, python-format
+msgid "While I2P has been reported to run PCs as meagre as a low-end Pentium II with 64 MB of RAM, you'll have a much better experience on a Pentium III (or better) with 128MB of RAM (or more). A chart comparing the performance of the various JREs can be found at http://%(trac)s/wiki/java, but in short: it's at all possible, use Sun/Oracle Java or OpenJDK."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:57
+msgid "I2P has been tested on Windows, Linux, FreeBSD (see the note below), OSX, and OpenSolaris. There is work underway to bring I2P to the Android platform."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:65
+msgid "Here are some places, pick one or more."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:71
+msgid "Discuss with the developers on IRC in #i2p-dev"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:75
+msgid "Please include relevant information from the router logs and wrapper logs."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:81
+msgid ""
+"The default subscription is to http://www.i2p2.i2p/hosts.txt which is updated rarely.\n"
+"If you don't have another subscription, you may often have to use \"jump\" links which\n"
+"is annoying."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:87
+msgid ""
+"Here are some other public addressbook subscription links. You may wish to add one or two\n"
+"to your susidns subscription list.\n"
+"You don't need to add all of them, as they sync with each other periodically.\n"
+"The links using a cgi-bin application employ various strategies to minimize\n"
+"the number of duplicate addresses delivered, so they should be more efficient.\n"
+"Note that subscribing to a hosts.txt service is an act of \"trust\", as a malicious\n"
+"subscription could give you incorrect addresses. So think about whether you\n"
+"want to trust any of these.\n"
+"The operators of these services may have various policies for listing hosts.\n"
+"Presence on this list does not imply endorsement."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:109
+#, fuzzy
+msgid ""
+"Jrandom was the lead developer of I2P and\n"
+"Syndie for several years.\n"
+"We do not know if or when jrandom will return.\n"
+"The *.i2p.net domains were left in a non-functioning state after a power\n"
+"outage at the hosting company."
+msgstr "Jrandom war der Hauptentwickler von I2P und Syndie für mehrere Jahre. Wir rechnen mit der Abwesenheit von Jrandom bis mindestens Ende des Jahres 2008. Die *.i2p.net Domains wurden durch einen Stromausfall in deren Rechenzentrum in einen nicht funktionierenden Status versetzt und da nur Jrandom administrativen Zugriff auf diese hat, konnte dieser Fehler nicht korrigiert werden."
+
+#: i2p2www/pages/site/faq.html:117
+#, python-format
+msgid ""
+"See this page for jrandom's parting message and additional information\n"
+"on the migration of *.i2p.net to this website."
+msgstr "Sschaue auf diese Seite für Jrandoms Abschiedsnachricht und weitere Informationen zur Migration von *.i2p.net zu dieser Webseite."
+
+#: i2p2www/pages/site/faq.html:122
+msgid "I2P remains in active development."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:126
+msgid "There are many possible causes of high CPU usage. Here is a checklist:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:131
+msgid ""
+"Try to use either OpenJDK or Sun/Oracle Java if it's available for your system. You can check \n"
+"which version of java you have installed by typing java -version at a \n"
+"command/shell prompt. Performance tends to suffer with other implementations of java."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:138
+msgid ""
+"Are you running a BitTorrent client over I2P? Try reducing the number of torrents, the bandwidth limits,\n"
+"or try turning it off completely to see if that helps."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:144
+msgid ""
+"Are your bandwidth limits set too high? It is possible that too much traffic is going through your\n"
+"I2P router and it is overloaded. Try reducing the setting for share bandwidth percentage on the configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:149
+msgid "Make sure that you're running the latest version of I2P to get the benefits of increased performance and bug fixes."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:154
+msgid ""
+"Has enough memory been set aside for use by I2P? Look at the memory graph on the graphs page to see\n"
+"if the memory usage is \"pegged\"—the JVM is spending most of its time in\n"
+"garbage collection. Increase the setting wrapper.java.maxmemory in wrapper.config."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:161
+#, python-format
+msgid ""
+"Is the CPU usage simply higher than you would like, or is it pegged at 100% for a long time?\n"
+"If it's pegged, this could be a bug. Look in the logs for clues."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:167
+#, python-format
+msgid ""
+"You may be using the Java-based BigInteger library instead of the native version,\n"
+"especially if you are running on a new or unusual OS or hardware (OpenSolaris, mipsel, etc.).\n"
+"See the jbigi page for instructions on\n"
+"diagnosing, building, and testing methods."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:175
+msgid ""
+"If your native jbigi library is working fine, the biggest user of\n"
+"CPU may be routing traffic for participating tunnels. This uses CPU\n"
+"because at each hop a layer of encryption must be decoded.\n"
+"You can limit participating traffic in two ways - by reducing the\n"
+"share bandwidth on\n"
+"confignet.jsp,\n"
+"or by setting router.maxParticipatingTunnels=nnn on\n"
+"configadvanced.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:190
+msgid ""
+"Hmm. I2P is an anonymous network, so that's a tricky one.\n"
+"I2P is designed to withstand censorship, providing a means for everyone to communicate freely. \n"
+"The best way to keep your PC free of (encrypted) traffic that you dislike is to not use I2P.\n"
+"Freedom of speech has some costs.\n"
+"But let's address your question in three parts:"
+msgstr "Hmm. I2P ist ein anonymes Netzwerk, somit ist dieses Thema schwer zu lösen. I2P ist für jeden aufgebaut und nicht zum zensieren von ein paar/allen Daten. Der Beste Weg um deinen PC frei von (verschlüsseltem) Material, welches Du nicht magst, zu halten, ist I2P nicht zu nutzen. Die Redefreiheit für jeden (Freedom of Speech) hat gewisse Kosten, die wir akzeptieren müssen. Aber lass uns die Frage in 3 Teilen beantworten:"
+
+#: i2p2www/pages/site/faq.html:199
+#, fuzzy, python-format
+msgid ""
+"Distribution - All traffic on I2P is encrypted in multiple layers. You don't know\n"
+"a message's contents, source, or destination.\n"
+"All traffic you route is internal to the I2P network, you are not an exit node (outproxy).\n"
+"Your only alternative is to refuse to route\n"
+"any traffic, by setting your share bandwidth or maximum participating tunnels to 0 (see above).\n"
+"It would be nice if you didn't do this, you should help the network by routing traffic for others.\n"
+"Over 95% of users route traffic for others."
+msgstr "Verteilen - Alle Daten in I2P sind in mehreren Schichten verschlüsselt. Du kennst weder den Inhalt der Nachricht noch ihren Ausgangspunkt oder ihr Ziel. Deine einzige Auswahl ist nur, generell keine Daten zu routen, indem Du die \"Share\" Bandbreite oder die maximale Anzahl der \"Participating Tunnel\" auf 0 setzt (siehe oben). Es wäre schön, wenn du dieses nicht machst, du solltest dem Netzwerk helfen, in dem du fremde Daten weiter leitest."
+
+#: i2p2www/pages/site/faq.html:210
+#, fuzzy
+msgid ""
+"Storage - I2P does not do distributed storage of content. You must be thinking of\n"
+"Freenet.\n"
+"Nobody's content is being stored on your computer by running I2P."
+msgstr "Speichern - I2P hat keinen verteilten Datenspeicher, du musst an Freenet denken. Du speicherst keine Daten für jemand anderen."
+
+#: i2p2www/pages/site/faq.html:217
+#, fuzzy
+msgid ""
+"Access - If there are some eepsites you don't like, don't go there.\n"
+"Or, use a blocking proxy like Privoxy or some type of \"net nanny\"."
+msgstr "Zugriff - Falls es Eepsites gibt, die Du nicht magst, besuche sie nicht! Oder benutze einen Proxy wie Privoxy, der den Zugriff dazu für dich sperrt."
+
+#: i2p2www/pages/site/faq.html:227
+msgid ""
+"No. This is normal.\n"
+"All routers adjust dynamically to changing network conditions and demands."
+msgstr "Nein, das ist normal. Alle Router passen sich dynamisch an die sich veränderne Netzwerkbedingunen und Anforderungen an."
+
+#: i2p2www/pages/site/faq.html:234
+msgid "You may need to reseed your I2P router. With recent versions of I2P you can go to http://localhost:7657/configreseed and click the Save Changes and Reseed Now button. If this method doesn't work—or you're using a very old version—you may need to reseed manually."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:237
+msgid ""
+"The reseed URL changed a few years ago. If this is your first install and you have installed\n"
+"an old (0.6.1.30 or earlier) release, or\n"
+"you have not run I2P in a long time, you must change the URL and then\n"
+"click \"Reseed\" on the console to find other routers.\n"
+"After your router is running,\n"
+"on configadvanced.jsp,\n"
+"add the line i2p.reseedURL=http://netdb.i2p2.de/\n"
+"OR i2p.reseedURL=http://i2pdb.tin0.de/netDb/ (either should work),\n"
+"then click \"Apply\", then click the \"reseed\" link on the left."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:248
+#, python-format
+msgid ""
+"This works if you are running 0.6.1.27 or later.\n"
+"If you are running release 0.6.1.31 or later, you probably don't need to do this.\n"
+"If you are running release 0.6.1.26 or earlier, either follow the\n"
+"manual reseed instructions below\n"
+"or install the latest release.\n"
+"Possible alternate method - add\n"
+"wrapper.java.additional.5=-Di2p.reseedURL=http://netdb.i2p2.de/\n"
+"to wrapper.config, shutdown the router completely, then start again, then click \"reseed\".\n"
+"Let us know if this works."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:259
+#, python-format
+msgid "...but you *really* should upgrade to the latest version."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:265
+msgid ""
+"If your router has 10 or more active peers, everything is fine. Changes in releases 0.6.1.31 and 0.6.1.32 improved the\n"
+"efficiency of the router and effectively reduced the number of active peers.\n"
+"The router should maintain connections to a few peers at all times.\n"
+"The best way to stay \"better-connected\" to the network is to share more bandwidth."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:272
+msgid "Is my router an \"exit node\" to the regular Internet? I don't want it to be."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:274
+msgid ""
+"No. Unlike Tor,\n"
+"\"exit nodes\" or \"outproxies\" are not an inherent part of the network.\n"
+"Only volunteers who set up and run separate applications will relay traffic to the regular Internet.\n"
+"There are very, very few of these."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:283
+msgid ""
+"See above. There are very few HTTP \"outproxies\", they are not an inherent part of the network,\n"
+"and they may not be up.\n"
+"In addition, the old outproxies squid.i2p, true.i2p, and krabs.i2p have vanished.\n"
+"The only outproxy at the moment is false.i2p.\n"
+"To use it, edit your i2ptunnel settings for eepProxy\n"
+"and set your outproxy list to 'false.i2p' (only).\n"
+"Then stop and restart the eepProxy.\n"
+"If it doesn't work, the outproxy is not up. It is not I2P's fault.\n"
+"If your primary reason to use an anonymous network is to anonymously access sites\n"
+"on the regular Internet, you should probably try Tor."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:298
+msgid ""
+"Within I2P, there is no need for HTTPS, as all traffic is encrypted end-to-end.\n"
+"FTP is not supported for technical reasons."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:302
+msgid ""
+"There are no FTP \"outproxies\" to the Internet—it may not even be possible to set up one.\n"
+"Any other kind of outproxy may work if it's set up with a standard tunnel. \n"
+"If you would like to set up some type of outproxy, carefully research the potential risks.\n"
+"The I2P community may or may not be able to help with the technical aspects, feel free to ask."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:308
+msgid ""
+"As explained several times above, any existing outproxy isn't a core part of the network.\n"
+"They are services run by individuals and they may or may not\n"
+"be operational at any given time."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:313
+msgid ""
+"Update: Thanks to the work of h2ik, there is an https outproxy available for use via I2P. Starting with I2P 0.8.4 the tunnel is configured out of the box.
            \n"
+"In case the https outproxy is not available in your version of I2P, you can add it easily by doing the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:319
+msgid "Open i2p tunnel manager. Scroll down to the bottom."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:324
+msgid "Choose CONNECT from New Client Tunnel dropdown list, click Create"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:329
+#, python-format
+msgid ""
+"In the new page, name and describe your new https tunnel as you like.\n"
+"The Access Point is your local port for the new https proxy recommended port's 4445.\n"
+"Outproxy should be the outproxy's .i2p address which supports https. \n"
+"See this forum post of h2ik's for the address. \n"
+"Make sure Shared Client, Delay Connect, AutoStart are checked.\n"
+"Other options should be left at the defaults. Click Save. In tunnel manger, click the Start button next to your new tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:339
+msgid ""
+"In firefox, click through Tools>Options>Advanced>Network>Setting.\n"
+"Untick Use this proxy for all protocol, set SSL proxy: to localhost:4445."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:344
+msgid "Done."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:350
+#, python-format
+msgid ""
+"\n"
+"This is a question that only you can answer because the correct answer depends on your behaviours, your\n"
+"threat model, and how much you trust the outproxy operator."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:354
+msgid ""
+"Like Tor, I2P does not magically encrypt the Internet.\n"
+"You are vulnerable to snooping by the outproxy operators.\n"
+"The Tor FAQ\n"
+"does a good job of explaining this."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:360
+#, python-format
+msgid ""
+"In addition, you may be vulnerable to collusion between the outproxy operator\n"
+"and operators of other I2P services, if you use the same tunnels (\"shared clients\").\n"
+"There is additional discussion about this on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:368
+msgid ""
+"Unless an outproxy has been set up for the service you want to connect to, this cannot be done.\n"
+"There are only three types of outproxies running right now: HTTP, HTTPS, and email. Note that there is not a SOCKS outproxy.\n"
+"If this type of service is required, try Tor."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:376
+#, python-format
+msgid ""
+"If you consider every eepsite that has ever been created, yes, most of them are down.\n"
+"People and eepsites come and go.\n"
+"A good way to get started in I2P is check out a list of eepsites that are currently up.\n"
+"%(perv)s tracks active eepsites."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:385
+msgid ""
+"Click on the Website link\n"
+"at the top of your router console for instructions."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:392
+msgid ""
+"Why are downloads, torrents, web browsing, and everything else so slow on I2P?\n"
+"The encryption and routing within the I2P network adds a substantial amount of overhead and limits bandwidth.\n"
+"Anonymity isn't free."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:397
+msgid ""
+"In addition, you and everybody else probably need to increase your bandwidth limits.\n"
+"Two key settings are the inbound and outbound bandwidth limiters on\n"
+"the configuration page.\n"
+"With the default settings of 32KBps you will generally get no better than 15KBps data transfer in I2PSnark.\n"
+"Increasing the settings (but keeping within your actual connection limitations)\n"
+"will increase the potential transfer rate for I2PSnark and all other applications."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:405
+msgid ""
+"Also, do you have sufficient share bandwidth configured to allow participating tunnels\n"
+"to route through your router? Believe it or not, allowing participating traffic\n"
+"keeps you well-integrated in the network and helps your own transfer speeds."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:410
+#, python-format
+msgid ""
+"I2P is a work in progress. Lots of improvements and fixes are being implemented, and\n"
+"generally speaking, running the latest release will help your performance.\n"
+"If you haven't, install the latest release."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:418
+#, python-format
+msgid ""
+"See the\n"
+"I2P Bittorrent FAQ"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:425
+msgid ""
+"\n"
+"On the\n"
+"I2PTunnel configuration page,\n"
+"start the ircProxy.\n"
+"Then tell your IRC client to connect to localhost port 6668."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:434
+msgid ""
+"For security purposes, the router's admin console by default only listens\n"
+"for connections on the local interface.  However, with a little hacking,\n"
+"you can make it reachable remotely:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:442
+msgid ""
+"Open ~/.i2p/clients.config and replace
            \n"
+"clientApp.0.args=7657 ::1,127.0.0.1 ./webapps/
            \n"
+"with 
            \n"
+"clientApp.0.args=7657 0.0.0.0 ./webapps/"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:450
+msgid ""
+"Go to http://localhost:7657/configadvanced.jsp\n"
+"and add a new option: consolePassword=foo (or whatever password you want)"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:456
+msgid ""
+"Go to http://localhost:7657/index.jsp\n"
+"and hit \"Graceful restart\", which restarts the JVM and reloads the client applications"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:463
+msgid ""
+"After that fires up, you should now be able to reach your console remotely.\n"
+"You will be prompted for a username and password though - the username is\n"
+"\"admin\" and the password is whatever you specified in step 2 above.  Note: the\n"
+"0.0.0.0 above specifies an interface, not a network or netmask.  0.0.0.0\n"
+"means \"bind to all interfaces\", so it can be reachable on 127.0.0.1:7657 as well as\n"
+"any LAN/WAN IP."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:474
+msgid ""
+"By default, the router I2CP interface (port 7654) binds to address 127.0.0.1. To bind to 0.0.0.0, set the\n"
+"router advanced configuration option i2cp.tcp.bindAllInterfaces=true and restart."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:479
+msgid "Whats an \"eepsite\"?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:481
+msgid ""
+"An eepsite is a website that is hosted anonymously - you can access it by\n"
+"setting your web browser's HTTP proxy to use the web proxy (typically it\n"
+"listens on localhost port 4444), and browsing to the site."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:489
+#, python-format
+msgid ""
+"The proxy config for different browsers is on a \n"
+"separate page with screenshots. More advanced configs with external tools\n"
+"are possible but could introduce leaks in your setup."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:498
+msgid ""
+"x is the number of peers you've sent or received a message from\n"
+"successfully in the last minute, y is the number of peers seen in the last\n"
+"hour or so."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:506
+msgid ""
+"The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are supported.\n"
+"There is no SOCKS outproxy so it is of limited use."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:510
+msgid ""
+"In addition, many applications leak sensitive\n"
+"information that could identify you on the Internet. I2P only filters\n"
+"connection data, but if the program you intend to run sends this\n"
+"information as content, I2P has no way to protect your anonymity.  For\n"
+"example, some mail applications will send the IP address of the machine\n"
+"they are running on to a mail server. There is no way for I2P to filter\n"
+"this, thus using I2P to 'socksify' existing applications is possible, but\n"
+"extremely dangerous."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:520
+#, python-format
+msgid ""
+"If you would like more information on the socks proxy application anyway,\n"
+"there are some helpful hints on the socks page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:527
+msgid ""
+"Okay, here's a rundown of the default ports (everything is configurable\n"
+"through various settings, of course):"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:536
+msgid ""
+"Internet-facing ports\n"
+"Note: New installs as of release 0.7.8 do not use port 8887; they select a random port\n"
+"between 9000 and 31000 when the program is run for the first time.\n"
+"The selected port is shown on the router configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:544
+msgid ""
+"Outbound UDP from the random port noted on the configuration page to arbitrary remote UDP ports, allowing replies\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:549
+msgid ""
+"Outbound TCP from random high ports to arbitrary remote TCP ports\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:554
+msgid ""
+"(optional, but recommended) Inbound UDP to the port noted on configuration page from arbitrary locations\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:559
+msgid ""
+"(optional, but recommended) Inbound TCP to the port noted on configuration page from arbitrary locations
            \n"
+"Inbound TCP may be disabled on the configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:565
+msgid ""
+"Outbound UDP on port 123, allowing replies
            \n"
+"This is necessary for I2P's internal time sync (via SNTP - \n"
+"querying a random SNTP host in pool.ntp.org or another\n"
+"server you specify)"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:576
+msgid ""
+"Local I2P ports, listening only to local connections by default,\n"
+"except where noted:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:582
+msgid ""
+"1900: UPnP SSDP UDP multicast listener.\n"
+"Cannot be changed. Binds to all interfaces.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:589
+msgid ""
+"2827: BOB bridge, a higher level socket API for clients\n"
+"Disabled by default.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the bob.config file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:597
+msgid ""
+"4444: HTTP proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router console.\n"
+"May also be configured to be bound to a specific interface or all interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:604
+msgid ""
+"4445: HTTPS proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router console.\n"
+"May also be configured to be bound to a specific interface or all interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:611
+msgid ""
+"6668: IRC proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router console.\n"
+"May also be configured to be bound to a specific interface or all interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:618
+msgid ""
+"7652: UPnP HTTP TCP event listener.\n"
+"Binds to the LAN address.\n"
+"May be changed with advanced config i2np.upnp.HTTPPort=nnnn.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:626
+msgid ""
+"7653: UPnP SSDP UDP search response listener.\n"
+"Binds to all interfaces.\n"
+"May be changed with advanced config i2np.upnp.SSDPPort=nnnn.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:634
+msgid ""
+"7654: I2P Client Protocol port, used by client apps.\n"
+"May be changed to a different port on\n"
+"configclients.jsp\n"
+"but this is not recommended.\n"
+"May be to bind to a different interface or all interfaces, or disabled, on\n"
+"configclients.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:644
+msgid ""
+"7655: UDP for SAM bridge, a higher level socket API for clients\n"
+"Only opened when a SAM V3 client requests a UDP session.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the clients.config file with the SAM command line option sam.udp.port=nnnn."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:652
+msgid ""
+"7656: SAM bridge, a higher level socket API for clients\n"
+"Disabled by default for new installs as of release 0.6.5.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the clients.config file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:660
+msgid ""
+"7657: Your router console\n"
+"May be disabled in the clients.config file.\n"
+"May also be configured to be bound to a specific interface or all interfaces in that file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:667
+msgid ""
+"7658: Your eepsite\n"
+"May be disabled in the clients.config file.\n"
+"May also be configured to be bound to a specific interface or all interfaces in the jetty.xml file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:674
+msgid ""
+"7659: Outgoing mail to smtp.postman.i2p\n"
+"May be disabled or changed on the i2ptunnel page in the router console.\n"
+"May also be configured to be bound to a specific interface or all interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:681
+msgid ""
+"7660: Incoming mail from pop.postman.i2p\n"
+"May be disabled or changed on the i2ptunnel page in the router console.\n"
+"May also be configured to be bound to a specific interface or all interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:688
+msgid ""
+"8998: mtn.i2p2.i2p (Monotone - disabled by default)\n"
+"May be disabled or changed on the i2ptunnel page in the router console.\n"
+"May also be configured to be bound to a specific interface or all interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:695
+msgid ""
+"31000: Local connection to the wrapper control channel port.\n"
+"Outbound to 32000 only, does not listen on this port.\n"
+"Starts at 31000 and will increment until 31999 looking for a free port.\n"
+"To change, see the\n"
+"wrapper documentation.\n"
+"For more information see below."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:705
+msgid ""
+"32000: Local control channel for the service wrapper.\n"
+"To change, see the\n"
+"wrapper documentation.\n"
+"For more information see below."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:717
+msgid ""
+"The local I2P ports and the I2PTunnel ports do not need to be reachable from \n"
+"remote machines, but *should* be reachable locally.  You can also create \n"
+"additional ports for I2PTunnel instances via http://localhost:7657/i2ptunnel/ \n"
+"(and in turn, would need to get your firewall to allow you local access, but \n"
+"not remote access, unless desired)."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:725
+msgid ""
+"So, to summarize, nothing needs to be reachable by unsolicited remote peers, but\n"
+"if you can configure your NAT/firewall to allow inbound UDP and TCP the outbound facing port, you'll\n"
+"get better performance.  You will also need to be able to send outbound UDP packets\n"
+"to arbitrary remote peers (blocking IPs randomly with something like PeerGuardian\n"
+"only hurts you - don't do it)."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:733
+msgid "Why is I2P listening on port 32000?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:735
+msgid ""
+"The Tanuki java service wrapper that we use opens this port—bound to localhost—in order \n"
+"to communicate with software running inside the JVM. When the JVM is launched it is given a key \n"
+"so it can connect to the wrapper. After the JVM establishes its connection \n"
+"to the wrapper, the wrapper refuses any additional connections."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:741
+msgid ""
+"More information can be found in the  \n"
+"wrapper documentation."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:748
+msgid ""
+"An I2P router only needs to be seeded once, to join the network for the first time.\n"
+"Reseeding is nothing more than sending plain HTTP GET requests\n"
+"to fetch a directory listing and download multiple \"routerInfo\" files\n"
+"from a predefined reseed URL."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:755
+msgid ""
+"A typical symptom of a failed reseed is the \"Known\" indicator\n"
+"(on the left sidebar of the router console) displaying a very small value\n"
+"(often less than 5) which does not increase. This can occur, among other things,\n"
+"if your firewall limits outbound traffic, and blocked the reseed request."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:762
+msgid "To reseed an I2P router manually, do the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:765
+msgid "Stop your I2P router"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:768
+msgid "Open http://netdb.i2p2.de/ using a web browser"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:771
+msgid "Save a dozen \"routerInfo\" files to your I2P \"netDb\" directory"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:778
+msgid "Start your I2P router"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:785
+msgid "When trying to start the router using \"i2prouter start\", you may see output like the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:790
+msgid ""
+"\n"
+"In order to be inclusive and try to ensure that I2P will run on as many systems \n"
+"as possible, up until I2P 0.8.9 we used a java wrapper \n"
+"compiled for FreeBSD 6.x. If you're receiving this error you most likely are missing the necessary compatibility libraries.\n"
+"These libraries may be installed by performing the following steps:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:798
+msgid "Switch to the root user with su or log in as root."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:804
+#, python-format
+msgid ""
+"If you cannot install these compatibility libraries (or do not want to), other\n"
+"possibilities would be to compile the wrapper for your\n"
+"system, starting I2P with the runplain.sh script, or you can\n"
+"replace the wrapper with one from the source tarball."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:810
+msgid "For the 0.8.9 release of I2P, the wrapper was upgraded to v3.5.12 and compiled on systems running FreeBSD 7.2."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:814
+msgid "In wrapper.log I see an error that states \"Protocol family unavailable\" when loading the Router Console"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:816
+msgid "Often this error will occur with any network enabled java software on some systems that are configured to use IPv6 by default. There are a few ways to solve this:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:821
+msgid "On Linux based systems, you can echo 0 > /proc/sys/net/ipv6/bindv6only"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:823
+msgid "Look for the following lines in wrapper.config."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:827
+msgid "If the lines are there, uncomment them by removing the \"#\"s. If the lines are not there, add them without the \"#\"s."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:830
+msgid "Another option would be to remove the ::1 from ~/.i2p/clients.config"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:834
+msgid ""
+"WARNING: For any changes to wrapper.config to take effect, you must completely\n"
+"stop the router and the wrapper. Clicking Restart on your\n"
+"router console will NOT reread this file! You must\n"
+"click Shutdown, wait 11 minutes, then start I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:845
+#, python-format
+msgid ""
+"Great!  Find us on IRC irc.freenode.net #i2p or post to\n"
+"the forum and we'll post it here (with\n"
+"the answer, hopefully)."
+msgstr "Bestens! Du findest uns im IRC auf irc.freenode.net im Kanal #i2p oder frage im Forum und wir werden das hier anfügen (mit der Antwort, hoffentlich)."
+
+#: i2p2www/pages/site/impressum.html:4
+msgid "German laws..."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:2
+msgid "I2P Anonymous Network"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:3
+msgid "The Invisible Internet Project"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:4
+msgid "Anonymous peer-to-peer distributed communication layer built with open source tools and designed to run any traditional Internet service such as email, IRC or web hosting."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:7
+msgid "What does I2P do for you?"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:8
+msgid "The I2P network provides strong privacy protections for communication over the Internet. Many activities that would risk your privacy on the public Internet can be conducted anonymously inside I2P."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:9
+#, python-format
+msgid "Get I2P %(version)s"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:13
+msgid "What is I2P?"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:15
+msgid "I2P is a full darknet implementation - a network within a network, and is intended to protect against monitoring by third parties, such as hostile governments or ISPs.\n"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:18
+msgid "I2P is used by many people who care about their privacy, as well as those in high-risk situations. It is designed to protect activists, oppressed people, journalists and whistle-blowers - as well as the average person.\n"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:21
+msgid "I2P runs on Java and is therefore available anywhere Java will run, including desktops, embedded systems (like the Raspberry Pi)  and Android phones.\n"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:25
+msgid "Read more…"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:30
+msgid "What can you do with I2P?"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:33
+#, python-format
+msgid "Email Integrated web mail interface, plugin for serverless email."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:38
+#, python-format
+msgid "Web browsing Anonymous websites, gateways to and from the public Internet."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:43
+#, python-format
+msgid "Blogging and forums Blogging and Syndie plugins."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:48
+#, python-format
+msgid "Website hosting Integrated anonymous web server."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:53
+#, python-format
+msgid "Real-time chat Instant messaging and IRC clients."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:58
+#, python-format
+msgid "File sharing ED2K and Gnutella clients, integrated BitTorrent client."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:63
+#, python-format
+msgid "Decentralized file storage Tahoe-LAFS distributed filesystem plugin."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:68
+#, python-format
+msgid "More supported applications…"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:76
+msgid "News & Updates"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:4
+msgid "Recommended Links & Resources"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:5
+#, python-format
+msgid ""
+"See also the page with\n"
+"links to papers, presentations, videos, and tutorials about I2P."
+msgstr ""
+
+#: i2p2www/pages/site/links.html:12
+msgid "Friends of I2P"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:24
+msgid "More Projects and Documentation"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:34
+msgid "Press"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:38
+msgid "Boards, newssite, others"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:42
+msgid "Very Old Stuff"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:2
+msgid "A Gentle Introduction"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:5
+msgid "A Gentle Introduction to How I2P Works"
+msgstr "Einführung in die Arbeitsweise von I2P"
+
+#: i2p2www/pages/site/docs/how/intro.html:7
+msgid ""
+"I2P is a project to build, deploy, and maintain a network supporting secure and anonymous\n"
+"communication. People using I2P are in control of the tradeoffs between anonymity, reliability,\n"
+"bandwidth usage, and latency. There is no central point in the network on which pressure can be\n"
+"exerted to compromise the integrity, security, or anonymity of the system. The network supports\n"
+"dynamic reconfiguration in response to various attacks, and has been designed to make use of\n"
+"additional resources as they become available. Of course, all aspects of the network are open and\n"
+"freely available."
+msgstr ""
+"I2P ist ein Projekt, welches ein Netzwerk zum sicheren und anonymen Kommunizieren planen, aufbauen\n"
+"und betreuen wird. Nutzer von I2P haben die Kontrolle über die Verteilung zwischen Anonymität,\n"
+"Verlässlichkeit, genutzter Bandbreite und Verzögerung. Es gibt keinen zentralen Punkt im Netzwerk,\n"
+"welcher übernommen werden kann um die Integrität, Sicherheit oder Anonymität des Systems zu\n"
+"komprimieren. Das Netzwerk kann sich in einer Reaktion auf Angriffe selber rekonfiguriern und\n"
+"wurde so geplant, das es zusätzliche Ressourcen bei deren Verfügbarkeit nutzen wird.\n"
+"Selbstverständlich sind alle Aspekte des Netzwerkes offen und frei verfügbar."
+
+#: i2p2www/pages/site/docs/how/intro.html:17
+msgid ""
+"Unlike many other anonymizing networks, I2P doesn't try to provide anonymity by hiding the\n"
+"originator of some communication and not the recipient, or the other way around. I2P is designed to\n"
+"allow peers using I2P to communicate with each other anonymously — both sender and recipient\n"
+"are unidentifiable to each other as well as to third parties. For example, today there are both\n"
+"in-I2P web sites (allowing anonymous publishing / hosting) as well as HTTP proxies to the normal web\n"
+"(allowing anonymous web browsing). Having the ability to run servers within I2P is essential, as it\n"
+"is quite likely that any outbound proxies to the normal Internet will be monitored, disabled, or\n"
+"even taken over to attempt more malicious attacks."
+msgstr ""
+"Im Gegensatz zu vielen anderen anonymen Netzwerken versucht I2P nicht die Anonymität durch\n"
+"verstecken eines Teils einer Kommunikation, der Sender oder der Empfänger, herzustellen. I2P\n"
+"wurde so geplant, das Nutzer von I2P untereinander anonym kommunizieren können - Sender und\n"
+"Empfänger sind für den jeweils anderen anonym als auch für nicht beteiligte dritte. Zum Beispiel\n"
+"gibt es zur Zeit I2P interne Webseiten (die anonymes Publizieren/hosten erlauben) und einen\n"
+"HTTP Proxy in das normale Internet (der anonymes Browsing bietet). Server im I2P Netz betreiben\n"
+"zu können ist eine essentielle Angelegenheit, da angenommen werden kann, das die Proxis ins\n"
+"normale Internet überwacht werden, abgeschaltet werden oder gar zu schlimmeren Angriffen genutzt\n"
+"werden."
+
+#: i2p2www/pages/site/docs/how/intro.html:28
+#, python-format
+msgid ""
+"The network itself is message oriented - it is essentially a secure and anonymous IP layer, where\n"
+"messages are addressed to cryptographic keys (Destinations) and can be significantly larger than IP\n"
+"packets. Some example uses of the network include \"eepsites\" (webservers hosting normal web\n"
+"applications within I2P), a BitTorrent client (\"I2PSnark\"), or a distributed data store. With the\n"
+"help of the I2PTunnel application, we are able to stream traditional\n"
+"TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and even streaming audio. Most people\n"
+"will not use I2P directly, or even need to know they're using it. Instead their view will be of one\n"
+"of the I2P enabled applications, or perhaps as a little controller app to turn on and off various\n"
+"proxies to enable the anonymizing functionality."
+msgstr ""
+"Das Netzwerk selber ist Nachrichten basiert - es ist essentiell eine sichere und anonyme IP Schicht,\n"
+"in der Nachrichten an kryptographische Schlüssel (Ziele) geschickt werden;die Nachrichten selber\n"
+"können signifikant grösser als IP Pakete werden. Beispiele für die Nutzung des Netzwerkes sind\n"
+"unter anderem \"Eepsites\" (Webserver mit normalen Webapplikationen innerhalb von I2P), ein\n"
+"BitTorrent Klient (\"I2Psnark\") oder ein verteilter\n"
+"Datencontainer. Mit der Hilfe von mihis I2PTunnel\n"
+"Applikation können wir die üblichen TCP/IP Anwendungen über I2P tunneln, z.B. SSH, IRC, ein squid\n"
+"Proxy oder gar Audio. Viele Leute werden I2P nicht direkt nutzen oder nicht bemerken, das sie I2P\n"
+"nutzen. Stattdessen sehen sie nur eine der I2P fähigen Anwendungen oder nur eine Einstellung für\n"
+"verschiedene Proxies, die ihnen Anonyme Verbindungen anbieten."
+
+#: i2p2www/pages/site/docs/how/intro.html:40
+#, python-format
+msgid ""
+"An essential part of designing, developing, and testing an anonymizing network is to define the threat model, since there is no such thing as \"true\" anonymity, just\n"
+"increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to\n"
+"communicate in arbitrarily hostile environments by providing good anonymity, mixed in with\n"
+"sufficient cover traffic provided by the activity of people who require less anonymity. This way,\n"
+"some users can avoid detection by a very powerful adversary, while others will try to evade a weaker\n"
+"entity, all on the same network, where each one's messages are essentially indistinguishable\n"
+"from the others."
+msgstr ""
+"Ein wichtiger Teil des Planens, Entwickelns und Testens eines anonymen Netzwerkes ist das\n"
+"Definieren des Angriffsszenarios, da es \"echte\" Anonymität nicht gibt,\n"
+"nur steigende Kosten und.\n"
+"Aufwand jemanden zu identifizieren. Kurz gesagt: I2P Absicht ist es, Personen in willkürlichen\n"
+"feindseligen Umgebungen einen militärischen Grad der Anonymität zu bieten, versteckt in dem\n"
+"hinreichendem Datenstrom aus der Aktivität anderer Leute, die weniger Anonymität benötigen.\n"
+"Dieses beinhaltet den Chat von Joe Sixpack mit seinen Freuden, den niemanden mitlesen kann,\n"
+"Jane Filesharer, die wei?~_ das die grossen Konzerne sie beim Tauschen von Dateien nicht\n"
+"identifizieren können, als auch Will Geheimnisverräter, der geheime Dokumente veröffentlicht -\n"
+"alles in dem selben Netzwerk, in dem eine Nachricht nicht von einer anderen unterschieden werden\n"
+"kann."
+
+#: i2p2www/pages/site/docs/how/intro.html:51
+msgid "Why?"
+msgstr "Warum?"
+
+#: i2p2www/pages/site/docs/how/intro.html:52
+#, python-format
+msgid ""
+"There are a multitude of reasons why we need a system to support anonymous communication, and\n"
+"everyone has their own personal rationale. There are many other\n"
+"efforts working on finding ways to provide varying degrees of anonymity to people through the\n"
+"Internet, but we could not find any that met our needs or threat model."
+msgstr ""
+"Es existieren eine unglaubliche Anzahl an fantastischen Gründen, weswegen wir ein System zum\n"
+"anonymen Kommunizieren benötigen und jeder hat seine eigenen persönlichen rationalen Gründe.\n"
+"Es gibt viele andere Bestrebungen, die auf dem einem oder anderen Weg\n"
+"unterschiedliche\n"
+"Arten der Anonymität im Internet zu erreichen versuchen, aber wir fanden keine, die unsere\n"
+"Anforderungen oder unser Angriffszenario abdeckten."
+
+#: i2p2www/pages/site/docs/how/intro.html:59
+msgid "How?"
+msgstr "Wie?"
+
+#: i2p2www/pages/site/docs/how/intro.html:61
+#, python-format
+msgid ""
+"The network at a glance is made up of a set of nodes (\"routers\") with a number of unidirectional\n"
+"inbound and outbound virtual paths (\"tunnels\", as outlined on the tunnel routing page). Each router is identified by a cryptographic RouterIdentity which is\n"
+"typically long lived. These routers communicate with each other through existing transport\n"
+"mechanisms (TCP, UDP, etc), passing various messages. Client applications have their own\n"
+"cryptographic identifier (\"Destination\") which enables it to send and receive messages. These\n"
+"clients can connect to any router and authorize the temporary allocation (\"lease\") of some tunnels\n"
+"that will be used for sending and receiving messages through the network. I2P has its own internal\n"
+"network database (using a modification of the Kademlia algorithm) for\n"
+"distributing routing and contact information securely."
+msgstr ""
+"In einer übersicht existiert das Netzwerk aus einer Gruppe von Knoten (\"Router\") mit einer\n"
+"Anzahl an unidirektionalen virtueller Eingangs und Ausgangs Wege (\"Tunnel\", wie in der\n"
+"Tunnel Routing  Seite beschrieben). Jeder Router wird duch eine kryptographische RouterIdentity\n"
+"eindeutig indentifiziert, diese ist für gewöhnlich dauerhaft gültig. Diese Router kommunizieren\n"
+"über vorhandene Transportmechanosmen (TCP, UDP, etc.) und tauschen verschiedene Nachrichten aus.\n"
+"Klientprogramme haben ihre eigenen kryptographischen Ident (\"Destination\"), durch den sie\n"
+"zum Senden und Empfangen von Nachrichten befähigt sind. Diese Klienten können zu irgendwelchen\n"
+"Routern Verbindung aufnehmen und authorisieren ihre derzeitige Belegung (\"lease\") von ein paar\n"
+"Tunneln, die zum Senden und Empfangen von Nachrichten durch das Netzwerk benutzt werden. I2P\n"
+"hat eine eigene Netzwerk Datenbank (\"Floodfill\")\n"
+"zum skalierbaren sicherem Verteilen von Routing und Kontaktinformationen."
+
+#: i2p2www/pages/site/docs/how/intro.html:74
+msgid "Network topology example"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:76
+msgid ""
+"In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on\n"
+"their local router. They each have a pair of 2-hop inbound tunnels per destination (labeled 1, 2, 3,\n"
+"4, 5 and 6), and a small subset of each of those router's outbound tunnel pool is shown with 2-hop\n"
+"outbound tunnels. For simplicity, Charlie's inbound tunnels and Dave's outbound tunnels are not\n"
+"shown, nor are the rest of each router's outbound tunnel pool (typically stocked with a few tunnels\n"
+"at a time). When Alice and Bob talk to each other, Alice sends a message out one of her (pink)\n"
+"outbound tunnels targeting one of Bob's (green) inbound tunnels (tunnel 3 or 4). She knows to send\n"
+"to those tunnels on the correct router by querying the network database, which is constantly updated\n"
+"as new leases are authorized and old ones expire."
+msgstr ""
+"Im oberen Bild betreiben Alice, Bob, Charlie und Dave je einen Router mit einer einzigen\n"
+"Destination auf ihren lokalen Router. Sie haben alle ein paar 2-Hop Eingangstunnel je\n"
+"Destination (mit 1, 2, 3, 4, 5 und 6 bezeichnet) und ein paar haben 2-Hop Ausgangstunnel.\n"
+"Zur Vereinfachung sind Charlies Eingangstunnel und Daves Ausgangstunnel nicht eingezeichnet,\n"
+"ebenso wie weitere Ausgangstunnel der Router (normalerweise so 5-10 Tunnel gleichzeitig).\n"
+"Sobald Alice und Bob miteiander reden, sendet Alice eine Nachricht über ihren (pinken)\n"
+"Ausgangstunnel in Richtung eines vons Bobs Eingangstunneln (grün, Tunnel 3 oder 4). Sie lernt\n"
+"den Eingangstunnel durch eine Abfrage der Netzwerk Datenbank kennen, diese Datenbank wird\n"
+"dauerhaft aktualisiert sobald neue Leases authorisiert sind und ältere auslaufen."
+
+#: i2p2www/pages/site/docs/how/intro.html:88
+#, python-format
+msgid ""
+"If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of\n"
+"his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2). To make things\n"
+"easier, most messages sent between Alice and Bob are garlic\n"
+"wrapped, bundling the sender's own current lease information so that the recipient can reply\n"
+"immediately without having to look in the network database for the current data."
+msgstr ""
+"Antwortet Bob nun Alice, geschieht dieses auf der selben Art und Weise - er sendet eine Nachricht\n"
+"über einen seiner Ausgangstunnel in Richtung eines von Alice Eingangstunnels (Tunnel 1 oder 2).\n"
+"Um vieles einfacher zu machen, sind viele Nachrichten zwischen Bob und Alice in sogenannte\n"
+"\"Garlics\" eingepackt, in denen die Lease Information vom\n"
+"Sender enthalten ist, so das der Empfänger sofort antworten kann ohne in der Netzwerk\n"
+"Datenbank nach den benötigten Informationen suchen zu müssen."
+
+#: i2p2www/pages/site/docs/how/intro.html:96
+#, python-format
+msgid ""
+"To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and\n"
+"hence there are no directory servers keeping statistics regarding the performance and reliability of\n"
+"routers within the network. As such, each router must keep and maintain profiles of various routers\n"
+"and is responsible for selecting appropriate peers to meet the anonymity, performance, and\n"
+"reliability needs of the users, as described in the peer selection\n"
+"page."
+msgstr ""
+"Um einigen Attacken aus dem Wege zu gehen ist I2P dezentral aufgebaut, ohne eine zentrale Instanz -\n"
+"und wie schon richtig geraten existiert kein zentraler Verzeichnisdienst, der Informationen\n"
+"zur Performance und Kontinuität der Router im Netzwerk verwaltet. Daraus folgt, da?~_jeder Router\n"
+"eigene Profile verschiedener Router halten und pflegen muss. Ebenso ist jeder Router selber\n"
+"verantwortlich für die Auswahl der korrekten Knoten um die Anforderungen an die Anonymität,\n"
+"Performance und Konitnuität des Benutzers zu erfüllen, so wie es in der\n"
+"\"Knoten Auswahl\" Seite beschrieben ist."
+
+#: i2p2www/pages/site/docs/how/intro.html:105
+#, python-format
+msgid ""
+"The network itself makes use of a significant number of cryptographic\n"
+"techniques and algorithms - a full laundry list includes 2048bit ElGamal encryption, 256bit AES\n"
+"in CBC mode with PKCS#5 padding, 1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman\n"
+"negotiated connections with station to station authentication, and ElGamal / AES+SessionTag."
+msgstr ""
+"Das Netzwerk selber nutzt eine signifikante Anzahl von Kryptographischen\n"
+"Techniken und Algorhytmen - die Liste umfässt 2048bit ElGamal Verschlüsselung, 256bit\n"
+"AES im CBC Modus mit PKCS#5 Padding, 1024bit DSA Signaturen, SHA256 Hashes, 2048bit Diffie-Hellmann\n"
+"vermittelte Verbindungen mit Station-zu-Station Authentifizierung und \n"
+"ElGamal / AES+SessionTag."
+
+#: i2p2www/pages/site/docs/how/intro.html:113
+msgid ""
+"Content sent over I2P is encrypted through three layers garlic encryption (used to verify the\n"
+"delivery of the message to the recipient), tunnel encryption (all messages passing through a tunnel\n"
+"is encrypted by the tunnel gateway to the tunnel endpoint), and inter router transport layer\n"
+"encryption (e.g. the TCP transport uses AES256 with ephemeral keys)."
+msgstr ""
+"Daten die über I2P gesendet werden, durchlaufen 3 Verschlüsselungen: garlic\n"
+"Verschlüsselung (zur überprüfung ob die Nachrichten beim Empfänger\n"
+"angekommen ist), Tunnel Verschlüsselung  (alle Nachrichten, die durch einen Tunnel gehen,\n"
+"sind vom Tunnel Gateway bis zum Tunnel Endpunkt verschlüsselt) und\n"
+"Zwischen-den-Routern-Transport-Schicht Verschlüsselung (z.B. benutzt der TCP Transport\n"
+"AES256 mit Ephemeral Schlüssel)."
+
+#: i2p2www/pages/site/docs/how/intro.html:120
+msgid ""
+"End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release\n"
+"0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router \"a\"\n"
+"to Bob's router \"h\" remains. Notice the different use of terms! All data from a to h is end-to-end\n"
+"encrypted, but the I2CP connection between the I2P router and the applications is not end-to-end\n"
+"encrypted! A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the\n"
+"applications running atop of I2P."
+msgstr ""
+"Ende-zu-Ende (I2CP) Verschlüsselung (von Programm zu Programm) wurde in der I2P Version 0.6 deaktiviert;\n"
+"Ende-zu-Ende (garlic) Verschlüsselung von Alice Router \"a\" zu Bobs Router \"h\" existiert weiterhin.\n"
+"Bitte beachte im foglendem Bild den anderen Gebrauch der Wörter! a und h sind die I2P Router mit\n"
+"der Ende-zu-Ende Verschlüsselung von Router zu Router, Alice und Bob hingegen sind die Programme\n"
+"die mittels(unverschlüsseltem) I2CP mit den I2P Routern kommunizieren! Sprich: bis zum I2P Router\n"
+"sind die Daten unverschlüsselt, ab dem I2P Router ist alles Ende-zu-Ende verschlüsselt."
+
+#: i2p2www/pages/site/docs/how/intro.html:129
+msgid "End to end layered encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:131
+#, python-format
+msgid "The specific use of these algorithms are outlined elsewhere."
+msgstr "Die genaue Anwendung dieser Algorhytmen sind woanders beschrieben."
+
+#: i2p2www/pages/site/docs/how/intro.html:135
+msgid ""
+"The two main mechanisms for allowing people who need strong anonymity to use the network are\n"
+"explicitly delayed garlic routed messages and more comprehensive tunnels to include support for\n"
+"pooling and mixing messages. These are currently planned for release 3.0, but garlic routed messages\n"
+"with no delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow\n"
+"people to set up and operate behind restricted routes (perhaps with trusted peers), as well as the\n"
+"deployment of more flexible and anonymous transports."
+msgstr ""
+"Die zwei Hauptbestandteile für den militärischen Grad der Anonymität sind explizite, verzögerte\n"
+"garlic geroutete Nachrichten und mehr umfassende Tunnel mit Unterstützung von Pooling und Mixen\n"
+"von Nachrichten. Diese Funktionen sind zur Zeit für Version 3.0 geplant, aber garlic geroutete\n"
+"Nachrichten mit keiner Verzögerung und FIFO Tunnels sind schon implementiert. Zusätzlich wird\n"
+"die Version 2.0 den Leuten erlauben, I2P hinter beschränkten Routen (möglicherweise mit vertrauten\n"
+"Knoten) aufzusetzen und zu betreiben; ebenso werden die flexiblere und anonymere Transports\n"
+"eingebaut werden."
+
+#: i2p2www/pages/site/docs/how/intro.html:144
+#, fuzzy, python-format
+msgid ""
+"Some questions have been raised with regards to the scalability of I2P, and reasonably so. There\n"
+"will certainly be more analysis over time, but peer lookup and integration should be bounded by\n"
+"O(log(N)) due to the network database's algorithm, while end\n"
+"to end messages should be O(1) (scale free), since messages go out K hops through the\n"
+"outbound tunnel and another K hops through the inbound tunnel, with K no longer than 3. The size of\n"
+"the network (N) bears no impact."
+msgstr ""
+"Es kamen ein paar berechtigte Fragen bezüglich der Skalierbarkeit von I2P auf. Mit der Zeit werden\n"
+"sicher detailiertere Analysen kommen, aber Knoten suchen und Integration sollte mit O(log(N))\n"
+"Komplexität eingehen due to the network database's algorithm,\n"
+"während Ende-zu-Ende Nachrichten mit O(1) (frei skalierend) eingehen, da\n"
+"Nachrichten durch K Hops im Ausgangstunnel und durch weitere K Hops im Eingangstunnel gehen -\n"
+"die Grösse des Netzwerkes (N) hat hier keinen Einfluss."
+
+#: i2p2www/pages/site/docs/how/intro.html:153
+msgid "When?"
+msgstr "Wann?"
+
+#: i2p2www/pages/site/docs/how/intro.html:154
+#, fuzzy, python-format
+msgid ""
+"I2P initially began in Feb 2003 as a proposed modification to Freenet to allow it to use alternate transports, such as JMS, then grew into its own as an\n"
+"'anonCommFramework' in April 2003, turning into I2P in July, with code being written in earnest\n"
+"starting in August '03. I2P is currently under development, following the roadmap."
+msgstr ""
+"I2P startete im Februar 2003 als eine vorgeschlagene Modifizierung zu \n"
+"Freenet, damit dieses alternative Transports, wie z.B. \n"
+"JMS, nutzen könne. Dann wuchs es in ein eigenes 'anonCommFramework' im April 2003,\n"
+"worauf es im July zu I2P wurde. Ersten Quelltext gab es im August 2003. I2P folgt in der Entwicklung\n"
+"derderzeitigen Roadmap."
+
+#: i2p2www/pages/site/docs/how/intro.html:163
+msgid "Who?"
+msgstr "Wer?"
+
+#: i2p2www/pages/site/docs/how/intro.html:164
+#, fuzzy, python-format
+msgid ""
+"We have a small team spread around several continents, working to advance\n"
+"different aspects of the project. We are very open to other developers who want to get involved and\n"
+"anyone else who would like to contribute in other ways, such as critiques, peer review, testing,\n"
+"writing I2P enabled applications, or documentation. The entire system is open source - the router\n"
+"and most of the SDK are outright public domain with some BSD and Cryptix licensed code, while some\n"
+"applications like I2PTunnel and I2PSnark are GPL. Almost everything is written in Java (1.5+),\n"
+"though some third party applications are being written in Python and other languages. The code works\n"
+"on Sun Java SE and other Java Virtual Machines."
+msgstr ""
+"Wir sind ein kleines Team aus merhren Ländern aus verschiedenen Kontinenten, das an der\n"
+"Weiterentwicklung von einzelnen Aspekten des Projektes arbeitet. Wir sind offen für weitere\n"
+"Entwickler, die sich einbringen wollen und auch gegenüber jedem anderen, der etwas zum\n"
+"Projekt beibringen kann, sei es Kritiken, Peer Review, Testen, schreiben neuer I2P\n"
+"kompatibler Anwendungen oder aber auch Dokumentationen. Das gesamte System ist Open Source -\n"
+"Der Router und ein Gro?~_eil des SDK sind zur Gänze Public Domain mit ein wenig BSD und\n"
+"Cryptix Lizensiertem Code, wohingegen einige Anwendungen wie I2PTunnel und I2PSnark\n"
+"GPL lizensiert sind. Fast alles ist in Java (1.5+) geschrieben, einige externe Anwendungen sind jedoch in\n"
+"Python geschrieben. Der Code arbeitet im aktuellen Kaffee und wir hoffen ihn möglichst bald\n"
+"auf GCJ lauffähig zu bekommen."
+
+#: i2p2www/pages/site/docs/how/intro.html:175
+msgid "Where?"
+msgstr "Wo?"
+
+#: i2p2www/pages/site/docs/how/intro.html:176
+#, python-format
+msgid ""
+"Anyone interested should join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net,\n"
+"irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de). There are currently no\n"
+"scheduled development meetings, however archives are available."
+msgstr ""
+"Jeder mit Interesse an I2P sollte uns im #i2p IRC Raum (gehostet auf irc.freenode.net,\n"
+"irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p und irc.einirc.de) besuchen. Es gibt zur Zeit\n"
+"keine fest geplanten Entwicklertreffen, dennoch existiert ein Archiv\n"
+"von abgehaltenen Entwickler Treffen."
+
+#: i2p2www/pages/site/docs/how/intro.html:182
+#, python-format
+msgid "The current source is available in monotone."
+msgstr "Der aktuelle Quelltext ist in Monotone verfügbar."
+
+#: i2p2www/pages/site/docs/how/intro.html:186
+msgid "Additional Information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:187
+#, python-format
+msgid "See the Index to Technical Documentation."
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:2
+msgid "Academic Research"
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:4
+msgid "Academic research and analysis of I2P is an important part of ensuring that the software and network performs as expected and is safe for users in hostile environments."
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:8
+msgid "I2P can be run as a separate test network by controlling the locations that a new router reseeds from so that it only finds other test routers. Additionally, the router can be run on its own in a virtual network mode to enable testing the router in isolation; to enable this mode, add i2p.vmCommSystem=true to the router.config before starting."
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:12
+#, python-format
+msgid "If you are planning on conducting research on the live I2P network, please contact us before you commence your testing. While we do not discourage researchers from responsibly testing their ideas on the live network, if an attack becomes apparent and we don't have any line of communication then we will end up taking countermeasures which could interfere with the test."
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:16
+msgid "Prior Research"
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:18
+#, python-format
+msgid "A list of known published papers about I2P is available here."
+msgstr ""
+
+#: i2p2www/pages/site/research/papers.html:2
+#: i2p2www/pages/site/research/papers.html:4
+msgid "Papers on I2P"
+msgstr ""
+
+#: i2p2www/pages/site/research/papers.html:6
+msgid "Following are links to research papers about I2P."
+msgstr ""
+
+#: i2p2www/pages/site/research/papers.html:8
+#, python-format
+msgid "To request an addition to this page, please send to %(email)s."
+msgstr ""
+
+#: i2p2www/pages/site/research/papers.html:12
+msgid "Newest links are at the top of the page."
+msgstr ""
+
+#: i2p2www/pages/site/research/papers.html:17
+msgid "Papers and Research"
+msgstr ""
+
diff --git a/i2p2www/translations/es/LC_MESSAGES/messages.po b/i2p2www/translations/es/LC_MESSAGES/messages.po
new file mode 100644
index 00000000..d893db61
--- /dev/null
+++ b/i2p2www/translations/es/LC_MESSAGES/messages.po
@@ -0,0 +1,27375 @@
+# Spanish translations for I2P website.
+# Copyright (C) 2013 I2P
+# This file is distributed under the same license as the I2P project.
+#
+# Translators:
+# trolly, 2013.
+# Adolfo Jayme Barrientos , 2013.
+# m1xxy , 2011.
+msgid ""
+msgstr ""
+"Project-Id-Version: I2P website\n"
+"Report-Msgid-Bugs-To: https://trac.i2p2.de/\n"
+"POT-Creation-Date: 2013-02-06 20:57+0000\n"
+"PO-Revision-Date: 2013-02-24 18:45+0000\n"
+"Last-Translator: trolly\n"
+"Language-Team: Spanish "
+"(http://www.transifex.com/projects/p/I2P/language/es/)\n"
+"Language: es\n"
+"Plural-Forms: nplurals=2; plural=(n != 1)\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Generated-By: Babel 0.9.6\n"
+"X-Generator: Poedit 1.5.3\n"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:2
+msgid "0.9.3 Release"
+msgstr "Versión 0.9.3"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:7
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:9
+msgid ""
+"0.9.3 includes extensive low-level changes to the queueing of messages in"
+" the router.  We implement the CoDel Active Queue Management (AQM) "
+"algorithm.  We also unify the queueing and priority mechanisms in the "
+"transports to aid diagnosis and reduce network latency.  Work continues "
+"on fixing UDP transport bugs and making UDP more resistant to attacks.  "
+"There are more changes to improve the performance of the router and "
+"reduce its memory usage.  Also, we enable i2psnark's DHT support, "
+"introduced last release, by default."
+msgstr "0.9.3 incluye muchos arreglos de bajo nivel en la cola de mensajes en el ruter. Hemos implementado el algoritmo CoDel Active Queue Management (AQM). También hemos unificado los mecanismos de prioridades y colas en los transportes para ayudar al diagnóstico y reducir la latencia de la red. El trabajo continua arreglando el transporte UDP haciendolo mas resistente a los ataques. Hay mas cambios para mejorar el rendimiento del ruter y reducir el uso de memoria. Además, hemos habilitado por defecto el suporte, introducido en la versión anterior, para DHT en i2psnark."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:12
+msgid ""
+"As usual, there's also lots of bug fixes in this release, so updating is "
+"recommended."
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:16
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:26
+msgid "Files are available on the `download page`_."
+msgstr "Los archivos están disponibles en la `página de descargas`_."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:20
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:30
+msgid "`download page`"
+msgstr "`página de descargas`"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:22
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:32
+msgid "RELEASE DETAILS"
+msgstr "DETALLES DEL LANZAMIENTO"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:24
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:34
+msgid "Major Changes"
+msgstr "Cambios mayores"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:26
+msgid "Active Queue Management"
+msgstr "Gestión de cola activa"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:27
+msgid "Priority queues"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:28
+msgid "I2PSnark DHT: Several bug fixes, enable by default."
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:30
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:39
+msgid "Bug Fixes"
+msgstr "Correcciones de errores"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:32
+msgid ""
+"Several SSU fixes including memory leak, and better handling of routers "
+"behind firewalls that change UDP ports; additional defenses for malicious"
+" packets."
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:33
+msgid "Fix piece selection (rarest-first) bugs in i2psnark"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:34
+msgid "Fix bug causing multiple browsers to open at startup"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:36
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:51
+msgid "Other"
+msgstr "Otro"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:38
+msgid "Improvements in caching"
+msgstr "Mejoras en almacenamiento en caché"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:39
+msgid "Several synchronization fixes and lock contention reduction"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:40
+msgid "Major reduction in SSU buffers memory use"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:41
+msgid ""
+"Fix streaming connection timeout back to 1 minute, was inadvertently "
+"changed to 5 minutes; set i2ptunnel server read timeout to 5 minutes, was"
+" unlimited"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:42
+msgid "Improved defenses in i2ptunnel for \"darkloris\""
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:43
+msgid "More validation at torrent creation in i2psnark"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:44
+msgid "Several parameter changes in SSU to improve throughput"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:45
+msgid ""
+"New event log for major events including restarts; show multiple restart "
+"lines on graphs"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:46
+msgid "Remove duplicate messages from logs"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:47
+msgid "Don't respond to blocked streaming connections with a reset, just drop"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:48
+msgid "Remove all uses of inefficient SimpleTimer"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:49
+msgid "More checks for valid IPs and ports entered in console"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:50
+msgid "Fix bug that wasted a lot of entropy"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:51
+msgid "Translation updates: Italian, Portuguese, Spanish, Swedish"
+msgstr "Actualizaciones de traducciones: italiano, portugués, español y sueco"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:52
+msgid "Add non-NIO configuration in jetty.xml, recommended for Java 5"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:53
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:63
+msgid "Update GeoIP data (new installs and PPA only)"
+msgstr ""
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:56
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:67
+msgid "SHA256 Checksums:"
+msgstr "Sumas de comprobación SHA256:"
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:2
+msgid "0.9.4 Release"
+msgstr "Versión 0.9.4"
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:7
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:9
+msgid ""
+"0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, "
+"that was reducing network performance and reliability. It also includes "
+"major changes in the in-network update system, and adds the capability to"
+" update via in-network torrents."
+msgstr "0.9.4 incluye un arreglo de la capacidad de la red, inrtoducido en 0.9.2, que estaba reduciendo el rendimiento y estabilidad de la red. Además incluye cambios en el sistema de actualización de la red, y añade la capacidad de actualizar a trevés de torrents de dentro de la red I2P."
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:13
+msgid ""
+"We fixed several bugs in the i2psnark DHT implementation that was "
+"introduced\n"
+"last release. For those of you using console or http proxy passwords,\n"
+"we converted to the more-secure digest method and improved the security "
+"for console forms."
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:19
+msgid ""
+"For those of you already running development builds, your router should "
+"automatically\n"
+"update to 0.9.4-0 using the new in-network torrent facility.\n"
+"For those running 0.9.3-0, you will update normally using in-network "
+"HTTP, and\n"
+"we will have more information for you when we release 0.9.5."
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:36
+msgid ""
+"Big rework of the update system; Preliminary support for updates via "
+"i2psnark"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:37
+msgid "Add per-destination outbound priorities"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:41
+msgid ""
+"Fix major bug that reduced SSU connection limits which reduced tunnel "
+"build success rates"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:42
+msgid "Fix bug with external I2CP that prevented some external apps from working"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:43
+msgid "Fixed several bugs in i2psnark DHT"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:44
+msgid "Fixed bug in i2psnark PEX that inflated peer counts"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:45
+msgid "Handle dropped I2CP messages better"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:46
+msgid "Reduce overhead of I2CP messages"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:47
+msgid "Enforce max size in transport outbound message queues"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:48
+msgid "Fixes for Windows eepget.bat (new installs and PPA only)"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:49
+msgid "Fix a bug that would drop messages of exactly 512 bytes in SSU"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:53
+msgid ""
+"More performance improvements, memory reduction, and object churn "
+"reduction"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:54
+msgid "Better detection of network disconnections"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:55
+msgid "Further improvements in the SSU transport"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:56
+msgid "Add console password form"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:57
+msgid ""
+"Convert http proxy and console from basic to digest authentication for "
+"added security"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:58
+msgid ""
+"Improved verification of console form submissions, using jsp sessions. "
+"Cookies may now be required on forms, except when the console password is"
+" enabled"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:59
+msgid ""
+"Initial work on new interfaces to manage applications started via "
+"clients.config"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:60
+msgid "Increase minimum peer port to 1024"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:61
+msgid "Increase granularity of bandwidth limiter for smoother transmissions"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:62
+msgid ""
+"Translation updates: Chinese, French, German, Italian, Polish, "
+"Portuguese, Swedish, and Ukrainian"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:64
+msgid "Update wrapper to 3.5.16 (new installs and PPA only)"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:65
+msgid "New ARMv6 wrapper for Raspberry Pi"
+msgstr ""
+
+#: i2p2www/pages/blog/category.html:2
+msgid "Blog Category"
+msgstr ""
+
+#: i2p2www/pages/blog/category.html:4
+#, python-format
+msgid "I2P Blog ATOM Feed for Category: %(category)s"
+msgstr ""
+
+#: i2p2www/pages/blog/index.html:2
+msgid "Blog Index"
+msgstr ""
+
+#: i2p2www/pages/blog/index.html:4 i2p2www/pages/site/index.html:75
+msgid "I2P Blog ATOM Feed"
+msgstr ""
+
+#: i2p2www/pages/blog/latest.html:5
+msgid "More blog posts…"
+msgstr "Mas entradas en blog…"
+
+#: i2p2www/pages/downloads/debian.html:4
+msgid "Debian I2P Packages"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:6
+#, python-format
+msgid ""
+"The packages hosted on the I2P Launchpad site\n"
+"have been tested and should work on x86/x86_64 platforms running:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:11
+msgid "Ubuntu (Hardy 8.04 and newer)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:13
+msgid ""
+"Debian Linux (Lenny and newer) & kFreeBSD (Wheezy)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:21
+#, python-format
+msgid ""
+"The I2P packages may work on systems not listed above. Please "
+"report any issues\n"
+"with these packages on Trac at\n"
+"http://%(trac)s."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:27
+msgid ""
+"Option 1: Recent versions of Ubuntu and its "
+"derivatives (Try this if you're not using Debian)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:28
+msgid ""
+"Option 2: Debian (including systems based on "
+"Debian and older versions of Ubuntu)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:29
+msgid ""
+"Option 3: Non-Linux (and possibly Non-x86 "
+"architectures)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:32
+msgid ""
+"Instructions for Ubuntu Lucid Lynx (and newer) and derivatives like Linux"
+" Mint & Trisquel"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:33
+msgid "Adding the PPA via the command line and installing I2P"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:36
+msgid "Open a terminal and enter:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:38
+msgid ""
+"This command will add the PPA to /etc/apt/sources.list.d and fetch the\n"
+"gpg key that the repository has been signed with. The GPG key ensures\n"
+"that the packages have not been tampered with since being built."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:45
+msgid "Notify your package manager of the new PPA by entering:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:47
+msgid ""
+"This command will retrieve the latest list of software from each\n"
+"repository that is enabled on your system, including the I2P PPA that\n"
+"was added with the earlier command."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:53
+#: i2p2www/pages/downloads/debian.html:118
+#: i2p2www/pages/downloads/debian.html:141
+msgid "You are now ready to install I2P!"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:57
+msgid "Adding the PPA Using Synaptic"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:60
+msgid ""
+"Open Synaptic (System -> Administration -> Synaptic Package "
+"Manager)."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:65
+msgid ""
+"Once Synaptic opens, select Repositories from the "
+"Settings menu."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:70
+msgid ""
+"Click the Other Sources tab and click Add. Paste "
+"ppa:i2p-maintainers/i2p into the APT-line field and click "
+"Add Source. Click the Close button then "
+"Reload."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:75
+msgid ""
+"In the Quick Filter box, type in i2p and press enter. When "
+"i2p is returned in the results list, right click "
+"i2p and select Mark for Installation. After doing "
+"so you may see a Mark additional required changes? popup. If so,"
+" click Mark then Apply."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:81
+msgid ""
+"After the installation process completes you can move on to the next\n"
+"part of starting I2P and configuring "
+"it for your system."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:86
+msgid "Instructions for Debian Lenny and newer"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:88
+msgid ""
+"The steps below should be performed with root access (i.e., switching\n"
+"user to root with \"su\" or by prefixing each command with \"sudo\")."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:94
+msgid "Add the GPG key that signs the repository with the following command:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:96
+msgid "You'll have output like the following if the command was successful:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:100
+msgid ""
+"For Debian Oldstable (Lenny) and Stable (Squeeze): Add the following "
+"entries to /etc/apt/sources.list.d/i2p.list"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:104
+msgid "For Debian Testing (Wheezy) or Unstable (Sid), use the following:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:109
+msgid "Notify your package manager of the new PPA by entering"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:111
+msgid ""
+"This command will retrieve the latest list of software from every\n"
+"repository enabled on your system, including the I2P PPA added in step\n"
+"1."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:122
+#: i2p2www/pages/downloads/debian.html:151
+msgid ""
+"After the installation process completes you can move on to the next part"
+" of starting I2P and configuring it "
+"for your system."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:126
+msgid "Instructions for Non-Linux / Non-x86"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:128
+msgid ""
+"The steps below should be performed with root access (i.e., switching\n"
+"user to root with \"su\" or by prefixing each command with "
+"\"sudo\")."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:134
+msgid ""
+"Download the i2p-router package from the"
+" PPA."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:139
+msgid ""
+"Make sure that you have Java installed. Running apt-get install"
+" default-jre should be sufficient."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:145
+#, python-format
+msgid ""
+"It is recommended to compile jbigi for your "
+"system to achieve better performance. Instructions are available here."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:155
+#: i2p2www/pages/downloads/list.html:165
+msgid "Post-install work"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:158
+msgid ""
+"Using these I2P packages the I2P router can be started in the following\n"
+"three ways:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:164
+msgid ""
+""on demand" using the i2prouter script. Simply run "
+""i2prouter\n"
+"start" from a command prompt. (Note: Do "
+"not use\n"
+"sudo or run it as root!)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:171
+msgid ""
+""on demand" without the java service wrapper\n"
+"(needed on non-Linux/non-x86 systems) by running \"i2prouter-"
+"nowrapper\".\n"
+"(Note: Do not\n"
+"use sudo or run it as root!)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:179
+msgid ""
+"as a service that automatically runs when your system boots, even\n"
+"before logging in. The service can be enabled with \"dpkg-"
+"reconfigure\n"
+"i2p\" as root or using sudo. This is the recommended means of "
+"operation."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:187
+msgid ""
+"When installing for the first time, please remember to adjust your "
+"NAT/firewall\n"
+"if you can. The ports to forward can be found on the \n"
+"network configuration page in the router console. If guidance with "
+"respect to forwarding ports is needed,\n"
+"you may find portforward.com to be"
+" helpful."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:194
+msgid ""
+"Please review and adjust the bandwidth settings on the\n"
+"configuration page,\n"
+"as the default settings of 96 KB/s down / 40 KB/s up are fairly "
+"conservative."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:200
+#: i2p2www/pages/downloads/list.html:198
+#, python-format
+msgid ""
+"If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy "
+"howto."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:2 i2p2www/pages/downloads/select.html:12
+#: i2p2www/pages/global/nav.html:3
+msgid "Download"
+msgstr "Descargas"
+
+#: i2p2www/pages/downloads/list.html:4
+msgid "Download I2P"
+msgstr "Descarga I2P"
+
+#: i2p2www/pages/downloads/list.html:6
+msgid "Dependency"
+msgstr "Dependencias"
+
+#: i2p2www/pages/downloads/list.html:7
+#, python-format
+#, fuzzy
+msgid ""
+"\n"
+"Java Runtime 1.5 or higher.\n"
+"(Oracle/Sun Java Version 6,\n"
+"OpenJDK 6, or\n"
+"IcedTea6\n"
+" recommended)\n"
+"
            \n"
+"Determine"
+" your installed Java version here\n"
+"or type java -version at your command prompt.\n"
+msgstr ""
+"\n"
+"Java Runtime 1.5 o mayor.\n"
+"(Oracle/Sun Java Version 6,\n"
+"OpenJDK 6, o\n"
+"IcedTea6\n"
+" recomendado)\n"
+"
            \n"
+"Averigua tu versión de java aquí\n"
+"or type java -version at your command prompt.\n"
+
+#: i2p2www/pages/downloads/list.html:20
+msgid "Clean installs"
+msgstr "Instalación"
+
+#: i2p2www/pages/downloads/list.html:34
+msgid "Download that file and run it."
+msgstr "Descargue este archivo y ejecútelo."
+
+#: i2p2www/pages/downloads/list.html:51
+msgid ""
+"Download that file and double-click it (if that works) or\n"
+"    type java -jar i2pinstall_0.9.4-1_osx.jar in a terminal "
+"to run the\n"
+"    installer.\n"
+"    You may be able to right-click and select\n"
+"    "Open with Java"."
+msgstr ""
+"Descargue el archivo y pulse doble click sobre él (si funciona) o\n"
+"    escriba java -jar i2pinstall_0.9.4-1_osx.jar en una terminal para ejecutar \n"
+"    el instalador.\n"
+"    Debería poder pulsar botón derecho sobre el archivo y seleccionar\n"
+"    "Abrir con Java"."
+
+#: i2p2www/pages/downloads/list.html:59
+#, python-format
+msgid ""
+"Due to a wrapper bug, the 0.9.4 installer\n"
+"      will NOT work on OS X. Use the fixed 0.9.4-1 OSX installer "
+"above."
+msgstr ""
+"Debido al  wrapper bug, el instaldor de 0.9.4 \n"
+"    NO funcionará en OS X. Use el instalador 0.9.4-1 OSX ya arreglado."
+
+#: i2p2www/pages/downloads/list.html:65 i2p2www/pages/downloads/list.html:92
+msgid "Command line (headless) install:"
+msgstr "Comando de instalación (headless):"
+
+#: i2p2www/pages/downloads/list.html:66
+msgid ""
+"Download the 0.9.4-1 OSX graphical installer file above and\n"
+"    run java -jar i2pinstall_0.9.4-1_osx.jar -console from "
+"the command line."
+msgstr ""
+"Descargue el instaldor gráfico 0.9.4-1 OSX y\n"
+"    ejecute java -jar i2pinstall_0.9.4-1_osx.jar -console en la terminal."
+
+#: i2p2www/pages/downloads/list.html:84
+#, python-format
+msgid ""
+"Download that file and double-click it (if that works) or\n"
+"    type java -jar i2pinstall_%(i2pversion)s.jar in a "
+"terminal to run the\n"
+"    installer.\n"
+"    On some platforms you may be able to right-click and select\n"
+"    "Open with Java"."
+msgstr ""
+"Descargue el archivo y pulse doble click sobre él (si funciona) o\n"
+"    escriba java -jar i2pinstall_%(i2pversion)s.jar en una terminal para ejecutar\n"
+"    el instalador.\n"
+"    En algunos sistemas debería poder pulsar botón derecho sobre el archivo y seleccionar\n"
+"    "Abrir con Java"."
+
+#: i2p2www/pages/downloads/list.html:93
+#, python-format
+msgid ""
+"Download the graphical installer file above and\n"
+"    run java -jar i2pinstall_%(i2pversion)s.jar -console "
+"from the command line."
+msgstr ""
+"Descargue el instaldor gráfico y \n"
+"    ejecute java -jar i2pinstall_%(i2pversion)s.jar -console en una terminal."
+
+#: i2p2www/pages/downloads/list.html:103
+msgid "Packages for Debian & Ubuntu are available."
+msgstr "Hay disponibles paquetes para debian & Ubuntu."
+
+#: i2p2www/pages/downloads/list.html:118
+#, python-format
+msgid ""
+"The Android version of I2P is being actively developed.\n"
+"    The latest dev build is version 0.9.3-5_b2-API8, and is available "
+"from\n"
+"    sponge's eepsite -\n"
+"    scan or click the QR code."
+msgstr ""
+"La versión de I2P para android está actualmente desarrollandóse activamente.\n"
+"    Los última versión compilada es 0.9.3-5_b2-API8, y está disponible en\n"
+"    la eepsite de Sponge -\n"
+"    Scanee o pulse sobre el código QR."
+
+#: i2p2www/pages/downloads/list.html:125
+msgid ""
+"The release and dev versions of the I2P APK are not compatible, as they\n"
+"      are signed by zzz and sponge respectively. Uninstall one before "
+"installing\n"
+"      the other."
+msgstr ""
+"Las versiones 'release' y en desarrollo del paquete APK de I2P no son compatibles, \n"
+"    ya que están firmadas por zzz y sponge respectivamente. Desinstale una antes de \n"
+"    instalar la otra."
+
+#: i2p2www/pages/downloads/list.html:135
+msgid "Source package"
+msgstr "Archivo con el código fuente "
+
+#: i2p2www/pages/downloads/list.html:145
+#, python-format
+msgid ""
+"Alternately, you can fetch the source from monotone.\n"
+"    
            \n"
+"    Run (tar xjvf i2psource_%(i2pversion)s.tar.bz2 ; cd "
+"i2p-%(i2pversion)s ; ant pkg) then either\n"
+"    run the GUI installer or headless install as above."
+msgstr ""
+"También puede obtener el cúdigo fuente de monotone.\n"
+"    
            \n"
+"    Ejecute (tar xjvf i2psource_%(i2pversion)s.tar.bz2 ; cd i2p-%(i2pversion)s ; ant pkg) y entonces\n"
+"    ejecute el instalador gráfico o el instalador 'headless'."
+
+#: i2p2www/pages/downloads/list.html:156
+#, python-format
+msgid ""
+"The files are signed by zzz,\n"
+"whose key is here."
+msgstr ""
+"Estos archivos están firmados por zzz,\n"
+"cuya clave está aquí."
+
+#: i2p2www/pages/downloads/list.html:161
+msgid ""
+"I2P can also be downloaded from our project pages on Launchpad and Google Code."
+msgstr "I2P también puede ser descargado de la web de nuestro proyecto en Launchpad y en Google Code."
+
+#: i2p2www/pages/downloads/list.html:167
+msgid ""
+"After running the installer on windows, simply click on the \"Start I2P\""
+" button\n"
+"which will bring up the router console,\n"
+"which has further instructions."
+msgstr ""
+"Después de ejecutar el instalador en Windows simplemente pulse en el botón \"Start I2P\" \n"
+"lo cual abrirá laconsola del ruter,\n"
+"donde encontrará mas instrucciones."
+
+#: i2p2www/pages/downloads/list.html:173
+msgid ""
+"On Unix-like systems, I2P can be started as a service\n"
+"using the \"i2prouter\" script, located in the directory you selected for"
+" I2P.\n"
+"Changing to that directory in a console and issuing \"sh i2prouter "
+"status\"\n"
+"should tell you the router's status. The arguments \"start\", \"stop\" "
+"and \"restart\"\n"
+"control the service. The router console\n"
+"can be accessed at its usual location.\n"
+"For users on OpenSolaris and other systems for which the wrapper (i2psvc)"
+" is not supported,\n"
+"start the router with \"sh runplain.sh\" instead."
+msgstr ""
+"En los sistemas basados en unix I2P puede ser ejecutado como un servicio\n"
+"usando el script \"i2prouter\" localizado en la carpeta seleccionada para I2P.\n"
+"Entrando a esa carpeta en al terminal y ejecutando \"sh i2prouter status\"\n"
+"debería mostrar el estado del ruter. Los argumentos \"start\", \"stop\" y \"restart\"\n"
+"controlan el servicio. A la consola del ruter\n"
+"puede accederse en la localización usual.\n"
+"Para usuarios de Opensolaris y otros sistemas donde el 'wrapper' (i2psvc) no está soportado,\n"
+"ejecute el ruter con \"sh runplain.sh\"."
+
+#: i2p2www/pages/downloads/list.html:184
+#, python-format
+msgid ""
+"When installing for the first time, please remember to adjust your "
+"NAT/firewall\n"
+"if you can, bearing in mind the Internet-facing ports I2P uses,\n"
+"described here among other ports.\n"
+"If you have successfully opened your port to inbound TCP, also enable "
+"inbound TCP on the\n"
+"configuration page."
+msgstr ""
+"Cuando instale I2P por primera vez, por favor recuerde ajustar su NAT/firewall\n"
+"si puede, sin olvidarse de los puertos que I2P abre a Internet,\n"
+"descritos aquí.\n"
+"Si ha abierto con éxito el puerto TCP de entrada en su NAT/firewall, abra también el puerto TCP de \n"
+"entrada en la página de configuración."
+
+#: i2p2www/pages/downloads/list.html:192
+msgid ""
+"Also, please review and adjust the bandwidth settings on the\n"
+"configuration page,\n"
+"as the default settings of 96 KBps down / 40 KBps up are fairly slow."
+msgstr ""
+"Además, por favor revise y ajuste su configuración de ancho de banda en la \n"
+"página de configuración,\n"
+"ya que la configuración por defecto de 96 KBps de descarga  / 40 KBps de subida es \n"
+"bastante lenta."
+
+#: i2p2www/pages/downloads/list.html:202
+msgid "Updates from earlier releases:"
+msgstr "Actualizaciones desde versiones anteriores:"
+
+#: i2p2www/pages/downloads/list.html:204
+msgid "Both automatic and manual upgrades are available for the release."
+msgstr "Están disponibles actualizaciones manuales y automáticas."
+
+#: i2p2www/pages/downloads/list.html:209
+msgid "Automatic updates"
+msgstr "Actualizaciones Auutomáticas"
+
+#: i2p2www/pages/downloads/list.html:211
+msgid ""
+"If you are running 0.7.5 or later, your router should detect the\n"
+"new release. To upgrade simply click the 'Download Update' button on your"
+" router console\n"
+"when it appears."
+msgstr ""
+"Si estas usando 0.7.5 o posterior su ruter debería detectar la nueva \n"
+"versión. Para actualizar simplemente pulse en el botón 'Descargar actualización' en la consola\n"
+"cuando aparezca."
+
+#: i2p2www/pages/downloads/list.html:217
+msgid ""
+"Due to a bug in release 0.7.6, those whose first I2P installation was "
+"that version\n"
+"and have not upgraded manually\n"
+"may get a \"downloaded version is not greater than current version\" "
+"error,\n"
+"and should use the manual update method below."
+msgstr ""
+"Debido a un fallo en la versión 0.7.6, aquellos en los cuales su primera instalación \n"
+"es esta versión y no han actualizado manualmente\n"
+"pueden obtener el error \"downloaded version is not greater than current version\",\n"
+"y deben usar la actualización manual de abajo."
+
+#: i2p2www/pages/downloads/list.html:225
+#, python-format
+msgid ""
+"If you are running 0.7.4 or earlier, please see\n"
+"the 0.7.5 release notes\n"
+"for important information about how to configure your router to "
+"automatically\n"
+"receive the release."
+msgstr ""
+"Si utiliza la version 0.7.4 o anterior, por favor lea\n"
+"the 0.7.5 release notes\n"
+"para obtener información importante de como configurar el ruter para descargar \n"
+"las actualizaciones automáticamente."
+
+#: i2p2www/pages/downloads/list.html:233
+#, python-format
+msgid ""
+"If you are running 0.6.1.30 or earlier, please see\n"
+"instructions\n"
+"for important information about how to configure your router to "
+"automatically\n"
+"receive the release."
+msgstr ""
+"Si utiliza la version 0.6.1.30 o anterior, por favor lea\n"
+"instruccioness\n"
+"para obtener información importante de como configurar el ruter para descargar \n"
+"las actualizaciones automáticamente."
+
+#: i2p2www/pages/downloads/list.html:242
+#, python-format
+msgid ""
+"If you have reconfigured your router following the instructions, you should see a link on your"
+" \n"
+"    router console "
+"allowing\n"
+"    you to download and install the new release by just clicking on that\n"
+"    link."
+msgstr ""
+"Si ha reconfigurado su ruter siguendo las instrucciones, debería ver un enlace en su \n"
+"    consola del ruter permitiendole\n"
+"    descargar e instalar la nueva versión pulsando en ese link."
+
+#: i2p2www/pages/downloads/list.html:250
+msgid "Alternately, you can use the manual method specified below."
+msgstr "De otra forma, puede usar el método manual especificado debajo."
+
+#: i2p2www/pages/downloads/list.html:260
+msgid "Manual updates"
+msgstr "Actualizaciones manuales"
+
+#: i2p2www/pages/downloads/list.html:272
+msgid ""
+"Download that file to your I2P\n"
+"    installation directory and rename as i2pupdate.zip.\n"
+"    (alternately, you can get the source as above and run \"ant "
+"updater\", then copy the\n"
+"    resulting i2pupdate.zip to your I2P installation directory).  You do"
+" \n"
+"    NOT need to unzip that file."
+msgstr ""
+"Descargue el archivo en su \b    carpeta de instalción de I2P y renómblelo como i2pupdate.zip.\n"
+"    (alternativamente, puede obtener el código como arriba ejecutando  \"ant updater\", y \n"
+"    entonces copiar el archivo resultante i2pupdate.zip a la carpeta de instalción de I2P). \n"
+"    No necesita descomprimir este archivo .zip."
+
+#: i2p2www/pages/downloads/list.html:281
+msgid "Click \"Restart\""
+msgstr "Pulse \"Restart\""
+
+#: i2p2www/pages/downloads/list.html:286
+msgid "Grab a cup of coffee and come back in 11 minutes"
+msgstr "Vaya a por una taza de horchata/café/mate y vuelva en 11 minutos."
+
+#: i2p2www/pages/downloads/list.html:294
+#, python-format
+msgid ""
+"The file is signed by zzz,\n"
+"whose key is here."
+msgstr ""
+"El archivo está firmado por zzz,\n"
+"cuya clave está aquí."
+
+#: i2p2www/pages/downloads/list.html:299
+msgid "Previous Releases"
+msgstr "Versiones Anteriores"
+
+#: i2p2www/pages/downloads/list.html:301
+#, python-format
+msgid ""
+"Previous releases are available on Google "
+"Code\n"
+"and Launchpad\n"
+"and within the I2P network on %(echelon)s."
+msgstr ""
+"Versiones anteriores disponibles en Google Code\n"
+"y Launchpad\n"
+"y dentro de la red I2P en %(echelon)s."
+
+#: i2p2www/pages/downloads/select.html:2 i2p2www/pages/downloads/select.html:4
+msgid "Mirror selection"
+msgstr ""
+
+#: i2p2www/pages/downloads/select.html:5
+msgid "File:"
+msgstr ""
+
+#: i2p2www/pages/downloads/select.html:10
+msgid "Any mirror"
+msgstr ""
+
+#: i2p2www/pages/global/bounty.html:19
+msgid ""
+"To claim the bounty the author must not be paid by other organizations\n"
+"or teams for this work (e.g. GSoC students are not valid)."
+msgstr ""
+
+#: i2p2www/pages/global/bounty.html:29
+#, python-format
+msgid ""
+"Bounty amounts may be increased by further donations.  Do\n"
+"you think these are important? Add in your "
+"donation, \n"
+"marking the amount for the %(donatename)s bounty!"
+msgstr ""
+
+#: i2p2www/pages/global/error_404.html:3
+msgid "Not found"
+msgstr ""
+
+#: i2p2www/pages/global/error_404.html:9
+msgid ""
+"Yep... the resource, you were searching for, is named differently, "
+"doesn't exist or was removed."
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:5
+msgid "Server error"
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:13
+msgid "500 Server error"
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:17
+msgid "Umm... the server encountered some sort of error."
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:2
+msgid "Mirrors"
+msgstr "Mirrors"
+
+#: i2p2www/pages/global/footer.html:10
+msgid "Secure"
+msgstr "Seguro"
+
+#: i2p2www/pages/global/footer.html:16
+msgid "Misc."
+msgstr "Varios"
+
+#: i2p2www/pages/global/footer.html:19 i2p2www/pages/site/links.html:2
+msgid "Links"
+msgstr "Links"
+
+#: i2p2www/pages/global/footer.html:20
+msgid "Impressum"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:24
+msgid "T-Shirts!"
+msgstr "Camisetas!"
+
+#: i2p2www/pages/global/footer.html:26
+msgid "Europe"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:27
+msgid "USA"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:31
+#: i2p2www/pages/site/get-involved/donate.html:2
+#: i2p2www/pages/site/get-involved/index.html:74
+msgid "Donate"
+msgstr "Donar"
+
+#: i2p2www/pages/global/layout.html:28
+msgid "Skip navigation"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:31
+msgid "I2P Logo"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:31 i2p2www/pages/site/index.html:3
+#: i2p2www/pages/site/about/intro.html:4
+msgid "The Invisible Internet Project"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:55
+#, python-format
+msgid ""
+"This page was last updated in %(lastupdated)s and is accurate for router "
+"version %(accuratefor)s."
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:59
+#, python-format
+msgid "This page was last updated in %(lastupdated)s."
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:63
+#, python-format
+msgid "This page is accurate for router version %(accuratefor)s."
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:4
+msgid "About"
+msgstr "Sobre"
+
+#: i2p2www/pages/global/nav.html:6
+msgid "Introduction to I2P"
+msgstr "Introducción a I2P"
+
+#: i2p2www/pages/global/nav.html:7
+msgid "Comparisons"
+msgstr "Comparaciones"
+
+#: i2p2www/pages/global/nav.html:9
+msgid "Overview of comparisons"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:13
+msgid "Other anonymous networks"
+msgstr "Otras redes anónimas"
+
+#: i2p2www/pages/global/nav.html:16
+#: i2p2www/pages/site/get-involved/index.html:29
+msgid "Documentation"
+msgstr "Documentación"
+
+#: i2p2www/pages/global/nav.html:18
+msgid "Documentation index"
+msgstr "Indice de documentación"
+
+#: i2p2www/pages/global/nav.html:19 i2p2www/pages/site/about/intro.html:17
+msgid "How does it work?"
+msgstr "¿Cómo funciona?"
+
+#: i2p2www/pages/global/nav.html:21
+#, fuzzy
+msgid "Gentle intro"
+msgstr "Una Introducción Sencilla"
+
+#: i2p2www/pages/global/nav.html:22
+msgid "Tech intro"
+msgstr "Introducción técnica"
+
+#: i2p2www/pages/global/nav.html:23
+msgid "Threat model"
+msgstr "Modelo de amenazas"
+
+#: i2p2www/pages/global/nav.html:24
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:292
+msgid "Garlic routing"
+msgstr "Garlic routing"
+
+#: i2p2www/pages/global/nav.html:25
+msgid "Network database"
+msgstr "Base de datos de la red"
+
+#: i2p2www/pages/global/nav.html:26
+msgid "Tunnel routing"
+msgstr "Ruteado de red"
+
+#: i2p2www/pages/global/nav.html:27
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:21
+msgid "Peer selection"
+msgstr "Selección de pares"
+
+#: i2p2www/pages/global/nav.html:28
+#: i2p2www/pages/site/docs/how/tech-intro.html:17
+#: i2p2www/pages/site/docs/how/tech-intro.html:458
+msgid "Cryptography"
+msgstr "Cifrado"
+
+#: i2p2www/pages/global/nav.html:29
+msgid "ElGamal/AES+SessionTags"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:32 i2p2www/pages/global/nav.html:115
+#: i2p2www/pages/site/docs/spec/configuration.html:75
+#: i2p2www/pages/site/get-involved/index.html:48
+msgid "Applications"
+msgstr "Aplicaciones"
+
+#: i2p2www/pages/global/nav.html:34
+msgid "Supported applications"
+msgstr "Aplicaciones soportadas"
+
+#: i2p2www/pages/global/nav.html:35
+msgid "Bittorrent"
+msgstr "Bittorrent"
+
+#: i2p2www/pages/global/nav.html:38
+#: i2p2www/pages/site/docs/api/streaming.html:58
+msgid "API"
+msgstr "API"
+
+#: i2p2www/pages/global/nav.html:46 i2p2www/pages/global/nav.html:76
+#: i2p2www/pages/site/docs/how/tech-intro.html:808
+msgid "Streaming library"
+msgstr "Librería de transmisión"
+
+#: i2p2www/pages/global/nav.html:47
+msgid "Ministreaming library"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:48 i2p2www/pages/global/nav.html:71
+#: i2p2www/pages/site/docs/index.html:87
+#: i2p2www/pages/site/docs/api/datagrams.html:2
+#: i2p2www/pages/site/get-involved/develop/applications.html:250
+msgid "Datagrams"
+msgstr "Datagramas"
+
+#: i2p2www/pages/global/nav.html:52
+msgid "Protocols"
+msgstr "Protocolos"
+
+#: i2p2www/pages/global/nav.html:54
+msgid "Protocol stack"
+msgstr "Pila del protocolo"
+
+#: i2p2www/pages/global/nav.html:59
+#: i2p2www/pages/site/docs/how/cryptography.html:394
+msgid "Transports"
+msgstr "Transportes"
+
+#: i2p2www/pages/global/nav.html:61 i2p2www/pages/site/docs/index.html:157
+msgid "Transport layer overview"
+msgstr "Visión general de la capa de transporte"
+
+#: i2p2www/pages/global/nav.html:66
+msgid "Specifications"
+msgstr "Especificaciones"
+
+#: i2p2www/pages/global/nav.html:68
+msgid "Blockfile"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:69
+msgid "Common structures"
+msgstr "Estructuras habituales"
+
+#: i2p2www/pages/global/nav.html:70
+msgid "Configuration files"
+msgstr "Archivos de configuración"
+
+#: i2p2www/pages/global/nav.html:74 i2p2www/pages/global/nav.html:90
+#: i2p2www/pages/site/docs/plugins.html:2
+#: i2p2www/pages/site/docs/spec/configuration.html:65
+msgid "Plugins"
+msgstr "Pluguins"
+
+#: i2p2www/pages/global/nav.html:77
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:230
+msgid "Tunnel creation"
+msgstr "Creación de túneles"
+
+#: i2p2www/pages/global/nav.html:78
+msgid "Tunnel messages"
+msgstr "Mensajes de túneles"
+
+#: i2p2www/pages/global/nav.html:79
+msgid "Software updates"
+msgstr "Actualizaciones de software"
+
+#: i2p2www/pages/global/nav.html:82 i2p2www/pages/site/docs/index.html:138
+#: i2p2www/pages/site/docs/how/tech-intro.html:14
+#: i2p2www/pages/site/docs/how/tech-intro.html:228
+msgid "Tunnels"
+msgstr "Túneles"
+
+#: i2p2www/pages/global/nav.html:84
+msgid "Tunnel implementation"
+msgstr "Implementacion de túneles"
+
+#: i2p2www/pages/global/nav.html:85
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:288
+msgid "Unidirectional tunnels"
+msgstr "Túneles unidireccionales"
+
+#: i2p2www/pages/global/nav.html:86
+msgid "Old implementation"
+msgstr "Implementacion antigua"
+
+#: i2p2www/pages/global/nav.html:89
+msgid "Naming and addressbook"
+msgstr "Nombres y lista de direcciones"
+
+#: i2p2www/pages/global/nav.html:93 i2p2www/pages/site/about/team.html:2
+msgid "Team"
+msgstr "Equipo"
+
+#: i2p2www/pages/global/nav.html:94
+msgid "Blog"
+msgstr "Blog"
+
+#: i2p2www/pages/global/nav.html:95
+msgid "Hall of Fame"
+msgstr "Podium"
+
+#: i2p2www/pages/global/nav.html:96
+msgid "Academic papers and peer review"
+msgstr "Documentos académicos y revisión por pares"
+
+#: i2p2www/pages/global/nav.html:97
+msgid "Presentations, tutorials and articles"
+msgstr "Presentaciones, artículos y tutoriales"
+
+#: i2p2www/pages/global/nav.html:98
+msgid "Contact us"
+msgstr "Contacto"
+
+#: i2p2www/pages/global/nav.html:101
+msgid "Help"
+msgstr "Ayuda"
+
+#: i2p2www/pages/global/nav.html:103
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:169
+msgid "FAQ"
+msgstr "Preguntas frecuentes"
+
+#: i2p2www/pages/global/nav.html:104
+msgid "How to browse I2P"
+msgstr "Como navegar I2P"
+
+#: i2p2www/pages/global/nav.html:105 i2p2www/pages/site/about/glossary.html:2
+msgid "Glossary"
+msgstr "Glosario"
+
+#: i2p2www/pages/global/nav.html:106
+#: i2p2www/pages/site/about/performance/index.html:2
+#: i2p2www/pages/site/docs/index.html:182
+#: i2p2www/pages/site/get-involved/todo.html:52
+#: i2p2www/pages/site/get-involved/todo.html:456
+msgid "Performance"
+msgstr "Rendimiento"
+
+#: i2p2www/pages/global/nav.html:107 i2p2www/pages/site/contact.html:22
+msgid "Forums"
+msgstr "Foros"
+
+#: i2p2www/pages/global/nav.html:110
+msgid "Volunteer"
+msgstr "Voluntario"
+
+#: i2p2www/pages/global/nav.html:112
+msgid "Get involved!"
+msgstr "¡Únete!"
+
+#: i2p2www/pages/global/nav.html:113
+msgid "Develop"
+msgstr "Desarrollo"
+
+#: i2p2www/pages/global/nav.html:116
+#: i2p2www/pages/site/get-involved/develop/licenses.html:2
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:115
+msgid "Licenses"
+msgstr "Licencias"
+
+#: i2p2www/pages/global/nav.html:117
+msgid "Release signing keys"
+msgstr "Publicar claves de firmas."
+
+#: i2p2www/pages/global/nav.html:118
+msgid "Signed keys"
+msgstr "Claves firmadas"
+
+#: i2p2www/pages/global/nav.html:119
+msgid "Developers keys"
+msgstr "Claves de los desarrolladores"
+
+#: i2p2www/pages/global/nav.html:120 i2p2www/pages/site/docs/index.html:220
+msgid "Bug tracker"
+msgstr "Bug tracker"
+
+#: i2p2www/pages/global/nav.html:123
+msgid "Academic research"
+msgstr "Búsqueda académica"
+
+#: i2p2www/pages/global/nav.html:124
+msgid "Guides"
+msgstr "Guías"
+
+#: i2p2www/pages/global/nav.html:126
+msgid "New developers"
+msgstr "Nuevos programadores"
+
+#: i2p2www/pages/global/nav.html:127
+#: i2p2www/pages/site/get-involved/guides/ides.html:2
+msgid "Using an IDE with I2P"
+msgstr "Usando un IDE con I2P"
+
+#: i2p2www/pages/global/nav.html:128
+msgid "Developer guidelines and coding style"
+msgstr "Guías de desarrollo y estilo del código"
+
+#: i2p2www/pages/global/nav.html:129
+#: i2p2www/pages/site/get-involved/guides/monotone.html:2
+msgid "Monotone"
+msgstr "Monotone"
+
+#: i2p2www/pages/global/nav.html:130
+msgid "New translators"
+msgstr "Nuevos traductores"
+
+#: i2p2www/pages/global/nav.html:133
+#: i2p2www/pages/site/get-involved/bounties/index.html:2
+msgid "Bounties"
+msgstr "Recompensas"
+
+#: i2p2www/pages/global/nav.html:134 i2p2www/pages/meetings/index.html:2
+msgid "Meetings"
+msgstr "Reuniones"
+
+#: i2p2www/pages/global/nav.html:135
+#: i2p2www/pages/site/get-involved/roadmap.html:2
+msgid "Roadmap"
+msgstr "Hoja de ruta"
+
+#: i2p2www/pages/global/nav.html:136
+msgid "Task list"
+msgstr "Lista de tareas"
+
+#: i2p2www/pages/global/nav.html:139
+msgid "Language"
+msgstr "Idioma"
+
+#: i2p2www/pages/meetings/index.html:4
+msgid "I2P Meetings ATOM Feed"
+msgstr ""
+
+#: i2p2www/pages/meetings/index.html:7
+msgid "Logs of past I2P meetings"
+msgstr "Logs de las reuniones de I2P pasadas "
+
+#: i2p2www/pages/meetings/index.html:9
+#, python-format
+msgid ""
+"If you have something to discuss, please find the developers on IRC in "
+"#i2p-dev.\n"
+"Status updates from developers are also "
+"available."
+msgstr ""
+"Por favor, si tienes algo que discutir busca a los desarrolladores en #i2p-dev en el IRC.\n"
+"Las Actualizaciones del estado de los desarrolladores están\n"
+" también disponibles."
+
+#: i2p2www/pages/site/contact.html:2
+msgid "Contact"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:5
+msgid ""
+"Our primary IRC network is the Irc2P network within I2P; a default tunnel"
+" to this network is set up with new router installs.\n"
+"  We are also present on multiple standard networks like OFTC,\n"
+"  EIN and Freenode.\n"
+"  All I2P-related channels on all these network are linked to the main "
+"channels on Irc2P via relay bots."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:13
+msgid "Channel list:"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:15
+msgid "General i2p discussion"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:16
+msgid "Offtopic"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:17
+msgid "Development talk"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:18
+msgid "Help channel"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:23
+#, python-format
+msgid ""
+"Most of the discussion about I2P's development happens on the I2P developer forum. This is usually the best"
+" place to start with inquiries, if the dev IRC channel is inactive."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:27
+msgid "Mailing lists"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:28
+msgid ""
+"I2P does have a mailing list, but it is rarely used as the current small "
+"team of developers prefer to communicate via IRC or the developer forum. "
+"This may change in future."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:33
+msgid "Subscribing"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:34
+msgid ""
+"To subscribe to a mailing list, go to the list information page (linked "
+"below) and fill out the form. I2P-internal email addresses "
+"(foobar@mail.i2p) can be used."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:38
+msgid "Unsubscribing"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:39
+msgid ""
+"To unsubscribe from a mailing list or edit your subscription options, go "
+"to the list information page (linked below) and enter your subscription "
+"email address."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:43
+msgid "Lists"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:46
+msgid "Archive"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:47
+msgid ""
+"General I2P discussion - anything that doesn't fit in a different list "
+"goes here."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:53
+msgid ""
+"You don't like mailing lists? Then this is for you. All mailing lists are"
+" available via NNTP as well."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:58
+msgid "Group-List-mapping:"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:62
+msgid "Servers:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:2
+msgid "Frequently Asked Questions"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:4
+#: i2p2www/pages/site/docs/how/threat-model.html:121
+msgid "Index"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:7
+msgid "General"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:9 i2p2www/pages/site/faq.html:51
+msgid "What systems will I2P run on?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:10
+msgid "Whats an \"eepsite\" and how do I configure my browser so I can use them?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:11 i2p2www/pages/site/faq.html:263
+msgid "My router has very few active peers, is this OK?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:12 i2p2www/pages/site/faq.html:498
+msgid "What do the Active x/y numbers mean in the router console?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:13 i2p2www/pages/site/faq.html:225
+msgid ""
+"My active peers / known peers / participating tunnels / connections / "
+"bandwidth vary dramatically over time! Is anything wrong?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:14 i2p2www/pages/site/faq.html:348
+msgid "Is using an outproxy safe?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:15 i2p2www/pages/site/faq.html:374
+msgid "Most of the eepsites within I2P are down?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:16 i2p2www/pages/site/faq.html:527
+msgid "What ports does I2P use?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:17
+msgid "Why is I2P listening for connections on port 32000?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:18 i2p2www/pages/site/faq.html:62
+msgid "I think I found a bug, where can I report it?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:19 i2p2www/pages/site/faq.html:107
+msgid "What happened to *.i2p.net? What happened to jrandom? Is I2P dead?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:20 i2p2www/pages/site/faq.html:845
+msgid "I have a question!"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:22
+#: i2p2www/pages/site/docs/api/streaming.html:292
+msgid "Setup"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:24 i2p2www/pages/site/faq.html:232
+msgid ""
+"My router has been up for several minutes and has zero or very few "
+"connections"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:25 i2p2www/pages/site/faq.html:390
+msgid "Why is I2P so slow?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:26 i2p2www/pages/site/faq.html:79
+msgid ""
+"I'm missing lots of hosts in my addressbook. What are some good "
+"subscription links?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:27 i2p2www/pages/site/faq.html:383
+msgid "How do I set up my own eepsite?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:28 i2p2www/pages/site/faq.html:416
+msgid "Bittorrent / I2PSnark / Azureus I2P Plugin Questions?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:29 i2p2www/pages/site/faq.html:423
+msgid "How do I connect to IRC within I2P?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:30 i2p2www/pages/site/faq.html:281
+msgid "I can't access regular Internet sites through I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:31 i2p2www/pages/site/faq.html:296
+msgid "I can't access https:// or ftp:// sites through I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:32 i2p2www/pages/site/faq.html:506
+msgid "Is it possible to use I2P as a SOCKS proxy?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:33 i2p2www/pages/site/faq.html:489
+msgid "How do I configure my browser?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:34 i2p2www/pages/site/faq.html:434
+msgid ""
+"How can I access the web console from my other machines or password "
+"protect it?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:35 i2p2www/pages/site/faq.html:474
+msgid "How can I use applications from my other machines?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:36 i2p2www/pages/site/faq.html:748
+msgid "How do I reseed manually?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:37 i2p2www/pages/site/faq.html:124
+msgid "My router is using too much CPU?!?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:39
+msgid "Misconception"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:41 i2p2www/pages/site/faq.html:366
+msgid ""
+"How do I access IRC, BitTorrent, or other services on the regular "
+"Internet?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:42
+msgid ""
+"Is my router an \"exit node\"(outproxy) to the regular Internet? I don't "
+"want it to be."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:43 i2p2www/pages/site/faq.html:188
+msgid ""
+"I am opposed to certain types of content. How do I keep from "
+"distributing, storing, or accessing them?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:45
+msgid "Errors and Their Solutions"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:47 i2p2www/pages/site/faq.html:784
+msgid ""
+"I'm using FreeBSD and when I start I2P I receive an error about "
+"libm.so.4!"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:48
+msgid ""
+"In wrapper.log I see an error stating Protocol family "
+"unavailable when I2P is loading"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:52 i2p2www/pages/site/faq.html:63
+#: i2p2www/pages/site/faq.html:80 i2p2www/pages/site/faq.html:108
+#: i2p2www/pages/site/faq.html:125 i2p2www/pages/site/faq.html:189
+#: i2p2www/pages/site/faq.html:226 i2p2www/pages/site/faq.html:233
+#: i2p2www/pages/site/faq.html:264 i2p2www/pages/site/faq.html:273
+#: i2p2www/pages/site/faq.html:282 i2p2www/pages/site/faq.html:297
+#: i2p2www/pages/site/faq.html:349 i2p2www/pages/site/faq.html:367
+#: i2p2www/pages/site/faq.html:375 i2p2www/pages/site/faq.html:384
+#: i2p2www/pages/site/faq.html:391 i2p2www/pages/site/faq.html:417
+#: i2p2www/pages/site/faq.html:424 i2p2www/pages/site/faq.html:435
+#: i2p2www/pages/site/faq.html:475 i2p2www/pages/site/faq.html:482
+#: i2p2www/pages/site/faq.html:490 i2p2www/pages/site/faq.html:499
+#: i2p2www/pages/site/faq.html:507 i2p2www/pages/site/faq.html:528
+#: i2p2www/pages/site/faq.html:736 i2p2www/pages/site/faq.html:749
+#: i2p2www/pages/site/faq.html:785 i2p2www/pages/site/faq.html:817
+#: i2p2www/pages/site/faq.html:846 i2p2www/pages/site/get-involved/todo.html:16
+#: i2p2www/pages/site/get-involved/todo.html:28
+#: i2p2www/pages/site/get-involved/todo.html:52
+msgid "link"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:53
+#, python-format
+msgid ""
+"While I2P has been reported to run PCs as meagre as a low-end Pentium II "
+"with 64 MB of RAM, you'll have a much better experience on a Pentium III "
+"(or better) with 128MB of RAM (or more). A chart comparing the performance of"
+" the various JREs can be found at http://%(trac)s/wiki/java, but in "
+"short: it's at all possible, use Sun/Oracle Java or OpenJDK."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:57
+msgid ""
+"I2P has been tested on Windows, Linux, FreeBSD (see the note below), OSX, and OpenSolaris. There is work "
+"underway to bring I2P to the Android platform."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:65
+msgid "Here are some places, pick one or more."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:71
+msgid "Discuss with the developers on IRC in #i2p-dev"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:75
+msgid "Please include relevant information from the router logs and wrapper logs."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:81
+msgid ""
+"The default subscription is to http://www.i2p2.i2p/hosts.txt which is "
+"updated rarely.\n"
+"If you don't have another subscription, you may often have to use "
+"\"jump\" links which\n"
+"is annoying."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:87
+msgid ""
+"Here are some other public addressbook subscription links. You may wish "
+"to add one or two\n"
+"to your susidns "
+"subscription list.\n"
+"You don't need to add all of them, as they sync with each other "
+"periodically.\n"
+"The links using a cgi-bin application employ various strategies to "
+"minimize\n"
+"the number of duplicate addresses delivered, so they should be more "
+"efficient.\n"
+"Note that subscribing to a hosts.txt service is an act of \"trust\", as a"
+" malicious\n"
+"subscription could give you incorrect addresses. So think about whether "
+"you\n"
+"want to trust any of these.\n"
+"The operators of these services may have various policies for listing "
+"hosts.\n"
+"Presence on this list does not imply endorsement."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:109
+msgid ""
+"Jrandom was the lead developer of I2P and\n"
+"Syndie for several years.\n"
+"We do not know if or when jrandom will return.\n"
+"The *.i2p.net domains were left in a non-functioning state after a power\n"
+"outage at the hosting company."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:117
+#, python-format
+msgid ""
+"See this page for jrandom's parting message "
+"and additional information\n"
+"on the migration of *.i2p.net to this website."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:122
+msgid "I2P remains in active development."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:126
+msgid "There are many possible causes of high CPU usage. Here is a checklist:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:131
+msgid ""
+"Try to use either OpenJDK or Sun/Oracle Java if it's available for your "
+"system. You can check \n"
+"which version of java you have installed by typing java "
+"-version at a \n"
+"command/shell prompt. Performance tends to suffer with other "
+"implementations of java."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:138
+msgid ""
+"Are you running a BitTorrent client over I2P? Try reducing the number of "
+"torrents, the bandwidth limits,\n"
+"or try turning it off completely to see if that helps."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:144
+msgid ""
+"Are your bandwidth limits set too high? It is possible that too much "
+"traffic is going through your\n"
+"I2P router and it is overloaded. Try reducing the setting for share "
+"bandwidth percentage on the configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:149
+msgid ""
+"Make sure that you're running the latest version of I2P to get the "
+"benefits of increased performance and bug fixes."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:154
+msgid ""
+"Has enough memory been set aside for use by I2P? Look at the memory graph"
+" on the graphs page to see\n"
+"if the memory usage is \"pegged\"—the JVM is spending most of its "
+"time in\n"
+"garbage collection. Increase the setting "
+"wrapper.java.maxmemory in wrapper.config."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:161
+#, python-format
+msgid ""
+"Is the CPU usage simply higher than you would like, or is it pegged at "
+"100% for a long time?\n"
+"If it's pegged, this could be a bug. Look in the logs for clues."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:167
+#, python-format
+msgid ""
+"You may be using the Java-based BigInteger library instead of the native "
+"version,\n"
+"especially if you are running on a new or unusual OS or hardware "
+"(OpenSolaris, mipsel, etc.).\n"
+"See the jbigi page for instructions on\n"
+"diagnosing, building, and testing methods."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:175
+msgid ""
+"If your native jbigi library is working fine, the biggest user of\n"
+"CPU may be routing traffic for participating tunnels. This uses CPU\n"
+"because at each hop a layer of encryption must be decoded.\n"
+"You can limit participating traffic in two ways - by reducing the\n"
+"share bandwidth on\n"
+"confignet.jsp,\n"
+"or by setting router.maxParticipatingTunnels=nnn on\n"
+"configadvanced.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:190
+msgid ""
+"Hmm. I2P is an anonymous network, so that's a tricky one.\n"
+"I2P is designed to withstand censorship, providing a means for everyone "
+"to communicate freely. \n"
+"The best way to keep your PC free of (encrypted) traffic that you dislike"
+" is to not use I2P.\n"
+"Freedom of speech has some costs.\n"
+"But let's address your question in three parts:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:199
+#, python-format
+msgid ""
+"Distribution - All traffic on I2P is encrypted in multiple layers."
+" You don't know\n"
+"a message's contents, source, or destination.\n"
+"All traffic you route is internal to the I2P network, you are not an exit node (outproxy).\n"
+"Your only alternative is to refuse to route\n"
+"any traffic, by setting your share bandwidth or maximum "
+"participating tunnels to 0 (see above).\n"
+"It would be nice if you didn't do this, you should help the network by "
+"routing traffic for others.\n"
+"Over 95% of users route traffic for others."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:210
+msgid ""
+"Storage - I2P does not do distributed storage of content. You must"
+" be thinking of\n"
+"Freenet.\n"
+"Nobody's content is being stored on your computer by running I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:217
+msgid ""
+"Access - If there are some eepsites you don't like, don't go "
+"there.\n"
+"Or, use a blocking proxy like Privoxy or some type of \"net nanny\"."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:227
+msgid ""
+"No. This is normal.\n"
+"All routers adjust dynamically to changing network conditions and demands."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:234
+msgid ""
+"You may need to reseed your I2P router. With recent versions of I2P you "
+"can go to http://localhost:7657/configreseed"
+" and click the Save Changes and Reseed Now button. If this "
+"method doesn't work—or you're using a very old version—you "
+"may need to reseed manually."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:237
+msgid ""
+"The reseed URL changed a few years ago. If this is your first install and"
+" you have installed\n"
+"an old (0.6.1.30 or earlier) release, or\n"
+"you have not run I2P in a long time, you must change the URL and then\n"
+"click \"Reseed\" on the console to find other routers.\n"
+"After your router is running,\n"
+"on configadvanced.jsp,"
+"\n"
+"add the line i2p.reseedURL=http://netdb.i2p2.de/\n"
+"OR i2p.reseedURL=http://i2pdb.tin0.de/netDb/ (either should "
+"work),\n"
+"then click \"Apply\", then click the \"reseed\" link on the left."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:248
+#, python-format
+msgid ""
+"This works if you are running 0.6.1.27 or later.\n"
+"If you are running release 0.6.1.31 or later, you probably don't need to "
+"do this.\n"
+"If you are running release 0.6.1.26 or earlier, either follow the\n"
+"manual reseed instructions below\n"
+"or install the latest release.\n"
+"Possible alternate method - add\n"
+"wrapper.java.additional.5=-Di2p.reseedURL=http://netdb.i2p2.de/\n"
+"to wrapper.config, shutdown the router completely, then start again, then"
+" click \"reseed\".\n"
+"Let us know if this works."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:259
+#, python-format
+msgid ""
+"...but you *really* should upgrade to "
+"the latest version."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:265
+msgid ""
+"If your router has 10 or more active peers, everything is fine. Changes "
+"in releases 0.6.1.31 and 0.6.1.32 improved the\n"
+"efficiency of the router and effectively reduced the number of active "
+"peers.\n"
+"The router should maintain connections to a few peers at all "
+"times.\n"
+"The best way to stay \"better-connected\" to the network is to share more bandwidth."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:272
+msgid ""
+"Is my router an \"exit node\" to the regular Internet? I don't want it to"
+" be."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:274
+msgid ""
+"No. Unlike Tor,\n"
+"\"exit nodes\" or \"outproxies\" are not an inherent part of the network."
+"\n"
+"Only volunteers who set up and run separate applications will relay "
+"traffic to the regular Internet.\n"
+"There are very, very few of these."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:283
+msgid ""
+"See above. There are very few HTTP \"outproxies\", they are not an "
+"inherent part of the network,\n"
+"and they may not be up.\n"
+"In addition, the old outproxies squid.i2p, true.i2p, and krabs.i2p have "
+"vanished.\n"
+"The only outproxy at the moment is false.i2p.\n"
+"To use it, edit your i2ptunnel "
+"settings for eepProxy\n"
+"and set your outproxy list to 'false.i2p' (only).\n"
+"Then stop and restart the eepProxy.\n"
+"If it doesn't work, the outproxy is not up. It is not I2P's fault.\n"
+"If your primary reason to use an anonymous network is to anonymously "
+"access sites\n"
+"on the regular Internet, you should probably try Tor."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:298
+msgid ""
+"Within I2P, there is no need for HTTPS, as all traffic is encrypted end-"
+"to-end.\n"
+"FTP is not supported for technical reasons."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:302
+msgid ""
+"There are no FTP \"outproxies\" to the Internet—it may not even be "
+"possible to set up one.\n"
+"Any other kind of outproxy may work if it's set up with a standard "
+"tunnel. \n"
+"If you would like to set up some type of outproxy, carefully research the"
+" potential risks.\n"
+"The I2P community may or may not be able to help with the technical "
+"aspects, feel free to ask."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:308
+msgid ""
+"As explained several times above, any existing outproxy isn't a core part"
+" of the network.\n"
+"They are services run by individuals and they may or may not\n"
+"be operational at any given time."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:313
+msgid ""
+"Update: Thanks to the work of h2ik, there is an https outproxy "
+"available for use via I2P. Starting with I2P 0.8.4 the tunnel is "
+"configured out of the box.
            \n"
+"In case the https outproxy is not available in your version of I2P, you "
+"can add it easily by doing the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:319
+msgid ""
+"Open i2p tunnel "
+"manager. Scroll down to the bottom."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:324
+msgid ""
+"Choose CONNECT from New Client Tunnel dropdown list, click "
+"Create"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:329
+#, python-format
+msgid ""
+"In the new page, name and describe your new https tunnel as"
+" you like.\n"
+"The Access Point is your local port for the new https proxy "
+"recommended port's 4445.\n"
+"Outproxy should be the outproxy's .i2p address which supports "
+"https. \n"
+"See this forum post of h2ik's for the "
+"address. \n"
+"Make sure Shared Client, Delay Connect, AutoStart "
+"are checked.\n"
+"Other options should be left at the defaults. Click Save. In tunnel "
+"manger, click the Start button next to your new tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:339
+msgid ""
+"In firefox, click through "
+"Tools>Options>Advanced>Network>Setting."
+"\n"
+"Untick Use this proxy for all protocol, set SSL proxy: to "
+"localhost:4445."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:344
+msgid "Done."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:350
+#, python-format
+msgid ""
+"\n"
+"This is a question that only you can answer because the correct answer "
+"depends on your behaviours, your\n"
+"threat model, and how much you trust the "
+"outproxy operator."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:354
+msgid ""
+"Like Tor, I2P does not magically encrypt the Internet.\n"
+"You are vulnerable to snooping by the outproxy operators.\n"
+"The Tor"
+" FAQ\n"
+"does a good job of explaining this."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:360
+#, python-format
+msgid ""
+"In addition, you may be vulnerable to collusion between the outproxy "
+"operator\n"
+"and operators of other I2P services, if you use the same tunnels "
+"(\"shared clients\").\n"
+"There is additional discussion about this on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:368
+msgid ""
+"Unless an outproxy has been set up for the service you want to connect "
+"to, this cannot be done.\n"
+"There are only three types of outproxies running right now: HTTP, HTTPS, "
+"and email. Note that there is not a SOCKS outproxy.\n"
+"If this type of service is required, try Tor."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:376
+#, python-format
+msgid ""
+"If you consider every eepsite that has ever been created, yes, most of "
+"them are down.\n"
+"People and eepsites come and go.\n"
+"A good way to get started in I2P is check out a list of eepsites that are"
+" currently up.\n"
+"%(perv)s tracks active eepsites."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:385
+msgid ""
+"Click on the Website link\n"
+"at the top of your router console for instructions."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:392
+msgid ""
+"Why are downloads, torrents, web browsing, and everything else so slow on"
+" I2P?\n"
+"The encryption and routing within the I2P network adds a substantial "
+"amount of overhead and limits bandwidth.\n"
+"Anonymity isn't free."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:397
+msgid ""
+"In addition, you and everybody else probably need to increase your "
+"bandwidth limits.\n"
+"Two key settings are the inbound and outbound bandwidth limiters on\n"
+"the configuration page.\n"
+"With the default settings of 32KBps you will generally get no better than"
+" 15KBps data transfer in I2PSnark.\n"
+"Increasing the settings (but keeping within your actual connection "
+"limitations)\n"
+"will increase the potential transfer rate for I2PSnark and all other "
+"applications."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:405
+msgid ""
+"Also, do you have sufficient share bandwidth configured to allow "
+"participating tunnels\n"
+"to route through your router? Believe it or not, allowing participating "
+"traffic\n"
+"keeps you well-integrated in the network and helps your own transfer "
+"speeds."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:410
+#, python-format
+msgid ""
+"I2P is a work in progress. Lots of improvements and fixes are being "
+"implemented, and\n"
+"generally speaking, running the latest release will help your "
+"performance.\n"
+"If you haven't, install the latest "
+"release."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:418
+#, python-format
+msgid ""
+"See the\n"
+"I2P Bittorrent FAQ"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:425
+msgid ""
+"\n"
+"A tunnel to the main IRC server within I2P, Irc2P, is created when I2P is"
+" installed (see\n"
+"the I2PTunnel "
+"configuration page),\n"
+"and is automatically started when the I2P router starts. To connect to "
+"it, tell your IRC\n"
+"client to connect to localhost 6668. XChat-like client users"
+" can create a\n"
+"new network with the server localhost/6668 (remember to tick"
+" "Bypass\n"
+"proxy server" if you have a proxy server configured)."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:436
+msgid ""
+"For security purposes, the router's admin console by default only listens"
+"\n"
+"for connections on the local interface.  However, with a little hacking,\n"
+"you can make it reachable remotely:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:444
+msgid ""
+"Open ~/.i2p/clients.config and replace
            \n"
+"clientApp.0.args=7657 ::1,127.0.0.1 ./webapps/
            \n"
+"with 
            \n"
+"clientApp.0.args=7657 0.0.0.0 ./webapps/"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:452
+msgid ""
+"Go to http://localhost:7657/configadvanced.jsp"
+"\n"
+"and add a new option: consolePassword=foo (or whatever "
+"password you want)"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:458
+msgid ""
+"Go to http://localhost:7657/index.jsp"
+"\n"
+"and hit \"Graceful restart\", which restarts the JVM and reloads the "
+"client applications"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:465
+msgid ""
+"After that fires up, you should now be able to reach your console "
+"remotely.\n"
+"You will be prompted for a username and password though - the username is"
+"\n"
+"\"admin\" and the password is whatever you specified in step 2 above.  "
+"Note: the\n"
+"0.0.0.0 above specifies an interface, not a network "
+"or netmask.  0.0.0.0\n"
+"means \"bind to all interfaces\", so it can be reachable on "
+"127.0.0.1:7657 as well as\n"
+"any LAN/WAN IP."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:476
+msgid ""
+"By default, the router I2CP interface (port 7654) binds to address "
+"127.0.0.1. To bind to 0.0.0.0, set the\n"
+"router advanced configuration option "
+"i2cp.tcp.bindAllInterfaces=true and restart."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:481
+msgid "Whats an \"eepsite\"?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:483
+msgid ""
+"An eepsite is a website that is hosted anonymously - you can access it by"
+"\n"
+"setting your web browser's HTTP proxy to use the web proxy (typically it\n"
+"listens on localhost port 4444), and browsing to the site."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:491
+#, python-format
+msgid ""
+"The proxy config for different browsers is on a \n"
+"separate page with screenshots. More advanced configs with external "
+"tools\n"
+"are possible but could introduce leaks in your setup."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:500
+msgid ""
+"x is the number of peers you've sent or received a message from\n"
+"successfully in the last minute, y is the number of peers seen in the "
+"last\n"
+"hour or so."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:508
+msgid ""
+"The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are "
+"supported.\n"
+"There is no SOCKS outproxy so it is of limited use."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:512
+msgid ""
+"In addition, many applications leak sensitive\n"
+"information that could identify you on the Internet. I2P only filters\n"
+"connection data, but if the program you intend to run sends this\n"
+"information as content, I2P has no way to protect your anonymity.  For\n"
+"example, some mail applications will send the IP address of the machine\n"
+"they are running on to a mail server. There is no way for I2P to filter\n"
+"this, thus using I2P to 'socksify' existing applications is possible, but"
+"\n"
+"extremely dangerous."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:522
+#, python-format
+msgid ""
+"If you would like more information on the socks proxy application anyway,"
+"\n"
+"there are some helpful hints on the socks page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:529
+msgid ""
+"Okay, here's a rundown of the default ports (everything is configurable\n"
+"through various settings, of course):"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:538
+msgid ""
+"Internet-facing ports\n"
+"Note: New installs as of release 0.7.8 do not use port 8887; they select "
+"a random port\n"
+"between 9000 and 31000 when the program is run for the first time.\n"
+"The selected port is shown on the router configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:546
+msgid ""
+"Outbound UDP from the random port noted on the configuration page to "
+"arbitrary remote UDP ports, allowing replies\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:551
+msgid ""
+"Outbound TCP from random high ports to arbitrary remote TCP ports\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:556
+msgid ""
+"(optional, but recommended) Inbound UDP to the port noted on configuration page from "
+"arbitrary locations\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:561
+msgid ""
+"(optional, but recommended) Inbound TCP to the port noted on configuration page from "
+"arbitrary locations
            \n"
+"Inbound TCP may be disabled on the configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:567
+msgid ""
+"Outbound UDP on port 123, allowing replies
            \n"
+"This is necessary for I2P's internal time sync (via SNTP - \n"
+"querying a random SNTP host in pool.ntp.org or another\n"
+"server you specify)"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:578
+msgid ""
+"Local I2P ports, listening only to local connections by default,\n"
+"except where noted:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:584
+msgid ""
+"1900: UPnP SSDP UDP multicast listener.\n"
+"Cannot be changed. Binds to all interfaces.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:591
+msgid ""
+"2827: BOB bridge, a higher level socket API for clients\n"
+"Disabled by default.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the bob.config file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:599
+msgid ""
+"4444: HTTP proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:606
+msgid ""
+"4445: HTTPS proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:613
+msgid ""
+"6668: IRC proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:620
+msgid ""
+"7652: UPnP HTTP TCP event listener.\n"
+"Binds to the LAN address.\n"
+"May be changed with advanced config i2np.upnp.HTTPPort=nnnn.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:628
+msgid ""
+"7653: UPnP SSDP UDP search response listener.\n"
+"Binds to all interfaces.\n"
+"May be changed with advanced config i2np.upnp.SSDPPort=nnnn.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:636
+msgid ""
+"7654: I2P Client Protocol port, used by client apps.\n"
+"May be changed to a different port on\n"
+"configclients.jsp"
+"\n"
+"but this is not recommended.\n"
+"May be to bind to a different interface or all interfaces, or disabled, "
+"on\n"
+"configclients.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:646
+msgid ""
+"7655: UDP for SAM bridge, a higher level socket API for clients\n"
+"Only opened when a SAM V3 client requests a UDP session.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the clients.config file with the SAM command line "
+"option sam.udp.port=nnnn."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:654
+msgid ""
+"7656: SAM bridge, a higher level socket API for clients\n"
+"Disabled by default for new installs as of release 0.6.5.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the clients.config file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:662
+msgid ""
+"7657: Your router console\n"
+"May be disabled in the clients.config file.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces in that file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:669
+msgid ""
+"7658: Your eepsite\n"
+"May be disabled in the clients.config file.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces in the jetty.xml file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:676
+msgid ""
+"7659: Outgoing mail to smtp.postman.i2p\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:683
+msgid ""
+"7660: Incoming mail from pop.postman.i2p\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:690
+msgid ""
+"8998: mtn.i2p2.i2p (Monotone - disabled by default)\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:697
+msgid ""
+"31000: Local connection to the wrapper control channel port.\n"
+"Outbound to 32000 only, does not listen on this port.\n"
+"Starts at 31000 and will increment until 31999 looking for a free port.\n"
+"To change, see the\n"
+"wrapper documentation.\n"
+"For more information see below."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:707
+msgid ""
+"32000: Local control channel for the service wrapper.\n"
+"To change, see the\n"
+"wrapper documentation.\n"
+"For more information see below."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:719
+msgid ""
+"The local I2P ports and the I2PTunnel ports do not need to be reachable "
+"from \n"
+"remote machines, but *should* be reachable locally.  You can also create"
+" \n"
+"additional ports for I2PTunnel instances via "
+"http://localhost:7657/i2ptunnel/ \n"
+"(and in turn, would need to get your firewall to allow you local access, "
+"but \n"
+"not remote access, unless desired)."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:727
+msgid ""
+"So, to summarize, nothing needs to be reachable by unsolicited remote "
+"peers, but\n"
+"if you can configure your NAT/firewall to allow inbound UDP and TCP the "
+"outbound facing port, you'll"
+"\n"
+"get better performance.  You will also need to be able to send outbound "
+"UDP packets\n"
+"to arbitrary remote peers (blocking IPs randomly with something like "
+"PeerGuardian\n"
+"only hurts you - don't do it)."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:735
+msgid "Why is I2P listening on port 32000?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:737
+msgid ""
+"The Tanuki java service wrapper that we use opens this port—bound "
+"to localhost—in order \n"
+"to communicate with software running inside the JVM. When the JVM is "
+"launched it is given a key \n"
+"so it can connect to the wrapper. After the JVM establishes its "
+"connection \n"
+"to the wrapper, the wrapper refuses any additional connections."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:743
+msgid ""
+"More information can be found in the  \n"
+"wrapper documentation."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:750
+msgid ""
+"An I2P router only needs to be seeded once, to join the network for the "
+"first time.\n"
+"Reseeding is nothing more than sending plain HTTP GET requests\n"
+"to fetch a directory listing and download multiple \"routerInfo\" files\n"
+"from a predefined reseed URL."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:757
+msgid ""
+"A typical symptom of a failed reseed is the \"Known\" indicator\n"
+"(on the left sidebar of the router console) displaying a very small value"
+"\n"
+"(often less than 5) which does not increase. This can occur, among other "
+"things,\n"
+"if your firewall limits outbound traffic, and blocked the reseed request."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:764
+msgid "To reseed an I2P router manually, do the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:767
+msgid "Stop your I2P router"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:770
+msgid ""
+"Open http://netdb.i2p2.de/ using a "
+"web browser"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:773
+msgid "Save a dozen \"routerInfo\" files to your I2P \"netDb\" directory"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:780
+msgid "Start your I2P router"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:787
+msgid ""
+"When trying to start the router using \"i2prouter start\", you may see "
+"output like the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:792
+msgid ""
+"\n"
+"In order to be inclusive and try to ensure that I2P will run on as many "
+"systems \n"
+"as possible, up until I2P 0.8.9 we used a java wrapper \n"
+"compiled for FreeBSD 6.x. If you're receiving this error you most likely "
+"are missing the necessary compatibility libraries.\n"
+"These libraries may be installed by performing the following steps:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:800
+msgid ""
+"Switch to the root user with su or log in as "
+"root."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:806
+#, python-format
+msgid ""
+"If you cannot install these compatibility libraries (or do not want to), "
+"other\n"
+"possibilities would be to compile the wrapper for your\n"
+"system, starting I2P with the runplain.sh script, or you"
+" can\n"
+"replace the wrapper with one from the source tarball."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:812
+msgid ""
+"For the 0.8.9 release of I2P, the wrapper was upgraded to v3.5.12 and "
+"compiled on systems running FreeBSD 7.2."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:816
+msgid ""
+"In wrapper.log I see an error that states \"Protocol "
+"family unavailable\" when loading the Router Console"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:818
+msgid ""
+"Often this error will occur with any network enabled java software on "
+"some systems that are configured to use IPv6 by default. There are a few "
+"ways to solve this:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:823
+msgid ""
+"On Linux based systems, you can echo 0 > "
+"/proc/sys/net/ipv6/bindv6only"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:825
+msgid "Look for the following lines in wrapper.config."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:829
+msgid ""
+"If the lines are there, uncomment them by removing the \"#\"s. If the "
+"lines are not there, add them without the \"#\"s."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:832
+msgid ""
+"Another option would be to remove the ::1 from "
+"~/.i2p/clients.config"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:836
+msgid ""
+"WARNING: For any changes to wrapper.config "
+"to take effect, you must completely\n"
+"stop the router and the wrapper. Clicking Restart on your\n"
+"router console will NOT reread this file! You must\n"
+"click Shutdown, wait 11 minutes, then start I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:847
+#, python-format
+msgid ""
+"Great!  Find us on IRC irc.freenode.net #i2p or post to\n"
+"the forum and we'll post it here (with\n"
+"the answer, hopefully)."
+msgstr ""
+
+#: i2p2www/pages/site/impressum.html:4
+msgid "German laws"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:2
+msgid "I2P Anonymous Network"
+msgstr "Red anónima I2P"
+
+#: i2p2www/pages/site/index.html:4
+msgid ""
+"Anonymous peer-to-peer distributed communication layer built with open "
+"source tools and designed to run any traditional Internet service such as"
+" email, IRC or web hosting."
+msgstr "Capa anónima de comunicación distribuida peer-to-peer construida con herramientas de código libre y diseñada para usar cualquier servicio de internet tradicional como email, IRC, foros o páginas webs."
+
+#: i2p2www/pages/site/index.html:7
+msgid "What does I2P do for you?"
+msgstr "¿Qué hace I2P por tí?"
+
+#: i2p2www/pages/site/index.html:8
+msgid ""
+"The I2P network provides strong privacy protections for communication "
+"over the Internet. Many activities that would risk your privacy on the "
+"public Internet can be conducted anonymously inside I2P."
+msgstr "La red I2p proporciona una fuerte privacidad de las comunicaciones sobre Internet. Muchas actividades que podrían poner en riesgo su privacidad en Internet pueden hacerse anónimamente dentro de I2P."
+
+#: i2p2www/pages/site/index.html:9
+#, python-format
+msgid "Get I2P %(version)s"
+msgstr "Descarga I2P %(version)s"
+
+#: i2p2www/pages/site/index.html:13
+msgid "What is I2P?"
+msgstr "¿Qué es I2P?"
+
+#: i2p2www/pages/site/index.html:15
+msgid ""
+"I2P is a full darknet implementation - a network within a network, and is"
+" intended to protect against monitoring by third parties, such as hostile"
+" governments or ISPs.\n"
+msgstr "I2p es una implementación completa de una darkent - una red dentro de otra red, y está destinada a proteger contra la monitarización de terceras partes, como gobiernos hostiles o ISPs.\n"
+
+#: i2p2www/pages/site/index.html:18
+msgid ""
+"I2P is used by many people who care about their privacy, as well as those"
+" in high-risk situations. It is designed to protect activists, oppressed "
+"people, journalists and whistle-blowers - as well as the average person."
+"\n"
+msgstr "I2P es usado por mucha gente que se preocupa de su privacidad, y también por otras personas en situaciones de alto reisgo. Está diseñado para proteger activistas, periodistas y personas que denuncian la corrupción.\n"
+
+#: i2p2www/pages/site/index.html:21
+msgid ""
+"I2P runs on Java and is therefore available anywhere Java will run, "
+"including desktops, embedded systems (like the Raspberry Pi)  and Android"
+" phones.\n"
+msgstr "I2p se ejecuta con Java por lo cual está disponible allí donde Java funcione, incluyendo sistemas de escritorio, embebidos (como Raspberry Pi) y móbiles Android.\n"
+
+#: i2p2www/pages/site/index.html:25
+msgid "Read more…"
+msgstr "Leer mas…"
+
+#: i2p2www/pages/site/index.html:30
+msgid "What can you do with I2P?"
+msgstr "¿Qué puede hacer con I2P?"
+
+#: i2p2www/pages/site/index.html:33
+#, python-format
+msgid ""
+"Email Integrated web mail interface, "
+"plugin for serverless email."
+msgstr "Email Interfaz de correo web incluido, pluguin para emails sin servidor."
+
+#: i2p2www/pages/site/index.html:38
+#, python-format
+msgid ""
+"Web browsing Anonymous "
+"websites, gateways to and from the public Internet."
+msgstr "Navegación web Webs anónimas, gateways desde y hacia el Internel público."
+
+#: i2p2www/pages/site/index.html:43
+#, python-format
+msgid ""
+"Blogging and forums "
+"Blogging and Syndie plugins."
+msgstr "Blogs y foros Blogs y pluguins para Syndie."
+
+#: i2p2www/pages/site/index.html:48
+#, python-format
+msgid ""
+"Website hosting Integrated "
+"anonymous web server."
+msgstr "Alojamiento web Servidor web anónimo integrado."
+
+#: i2p2www/pages/site/index.html:53
+#, python-format
+msgid ""
+"Real-time chat Instant "
+"messaging and IRC clients."
+msgstr "Chat en tiempo real Mensajería instantánea y clientes IRC."
+
+#: i2p2www/pages/site/index.html:58
+#, python-format
+msgid ""
+"File sharing ED2K and Gnutella"
+" clients, integrated BitTorrent client."
+msgstr "Compartición de archivos Clientes ED2K y Gnutella, cliente de BitTorrent integrado."
+
+#: i2p2www/pages/site/index.html:63
+#, python-format
+msgid ""
+"Decentralized file "
+"storage Tahoe-LAFS distributed filesystem plugin."
+msgstr "Almacenamiento de archivos descentralizado Pluguin para el sistema de archivos distribuido Tahoe-LAFS."
+
+#: i2p2www/pages/site/index.html:68
+#, python-format
+msgid "More supported applications…"
+msgstr "Mas aplicaciones soportadas…"
+
+#: i2p2www/pages/site/index.html:76
+msgid "News & Updates"
+msgstr "Noticias & Actualizaciones"
+
+#: i2p2www/pages/site/links.html:4
+msgid "Recommended Links & Resources"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:5
+#, python-format
+msgid ""
+"See also the page with\n"
+"links to presentations, videos, and tutorials about"
+" I2P."
+msgstr ""
+
+#: i2p2www/pages/site/links.html:12
+msgid "Friends of I2P"
+msgstr "Amigos de I2P"
+
+#: i2p2www/pages/site/links.html:24
+msgid "More Projects and Documentation"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:34
+msgid "Press"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:38
+msgid "Boards, newssite, others"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:42
+msgid "Very Old Stuff"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:2
+msgid "Web Browser Configuration"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:5
+msgid ""
+"Your web browser will need to be configured in order to browse eepsites "
+"and to\n"
+"utilize the outproxies available within I2P. Below are walkthroughs for "
+"some of\n"
+"the most popular browsers."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:11
+msgid "How to configure your browser"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:17
+#: i2p2www/pages/site/about/browser-config.html:73
+msgid "Outproxy Terms Of Service"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:22
+msgid "Internet Explorer 8 or Chrome"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:23
+msgid ""
+"In the tools menu select the \"Internet Options\" line to open the "
+"settings. In the\n"
+"settings window choose the connections tab and click on LAN settings for "
+"the\n"
+"proxy port configuration."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:28
+msgid "IE Internet Options"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:29
+msgid ""
+"Now set the checkmark at \"use a proxy server for your LAN\" and at the "
+"\"Bypass\n"
+"proxy server for local addresses\". With a click on Advanced-button you "
+"open the\n"
+"window to open the ports. Enter the values like on the picture, IP "
+"127.0.0.1\n"
+"and port 4444 for HTTP, port 4445 for HTTPS. With clicks on OK you save "
+"the\n"
+"settings and your browser is set to use the I2P proxy."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:36
+msgid "IE Proxy Settings"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:40
+msgid ""
+"From the Tools menu, select Options to bring up the Firefox settings "
+"panel.\n"
+"Click the icon labelled Advanced, then click on the "
+"Network\n"
+"tab. In the Connections section, click on the Settings button. "
+"You'll\n"
+"see a Window like the following:"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:46
+msgid "Firefox Network Options"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:47
+msgid ""
+"In the Connection Settings window, click the circle next to "
+"Manual\n"
+"    proxy configuration, then enter 127.0.0.1, port 4444 in the HTTP"
+" Proxy\n"
+"field.  Enter 127.0.0.1, port 4445 in the SSL Proxy field.\n"
+"Be sure to enter localhost and 127.0.0.1 into the \"No Proxy for\" box."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:53
+msgid "Firefox Proxy Settings"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:57
+msgid ""
+"From the Settings menu, select Configure Konqueror. In "
+"the\n"
+"Web Browsing group on the left side, select Proxy Services.\n"
+"In this new window, select the option \"Manually specify the proxy "
+"settings\" and\n"
+"click the Setup box."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:63
+msgid "Konqueror Proxy Options"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:64
+msgid ""
+"Enter 127.0.0.1 and port 4444 into the HTTP box. Enter 127.0.0.1 and port"
+" 4445 into\n"
+"HTTPS box. Click the New button in the Exceptions section. Enter"
+"\n"
+"localhost and click OK. Click the New button once more and enter"
+"\n"
+"127.0.0.1 and OK. Hit OK once more to close the configuration window."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:70
+msgid "Konqueror Proxy Ports"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:74
+msgid ""
+"Remember: I2P was not designed for creating proxies to the outer "
+"Internet.\n"
+"Instead, it is meant to be used as an internal network."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:78
+msgid ""
+"The I2P project itself does not run any proxies to the Internet. Any "
+"such proxy\n"
+"services are run by by private volunteers and could be shut down or\n"
+"unreachable at anytime."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:83
+msgid ""
+"By default, I2P comes with two outproxies configured: "
+"false.i2p\n"
+"(an HTTP-only proxy) and outproxyng.h2ik.i2p (an HTTPS proxy"
+"\n"
+"routed through Tor."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:88
+msgid ""
+"Both of these outproxies are configured with connection limits. This "
+"means\n"
+"that only set amount of accesses are allowed per client. Once the limit "
+"is\n"
+"reached, the client is blocked out for a timeframe of 1min/1h/1 day. Be\n"
+"respectful and do not overload these services with too many requests!"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:94
+#, python-format
+msgid ""
+"Filtering is active on these outproxies (for example, mibbit and torrent\n"
+"tracker access is blocked). Note that even though the pirate bay is "
+"blocked\n"
+"they host an official eepsite at %(tpb)s. "
+"Eepsites\n"
+"that are accessible via .i2p addresses are also not allowed via the "
+"outproxies.\n"
+"As a convenience, False.i2p blocks ad servers."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:101
+msgid ""
+"Tor is good application to use"
+" as an\n"
+"outproxy to the Internet."
+msgstr ""
+
+#: i2p2www/pages/site/about/glossary.html:4
+msgid ""
+"This page lists often-used terminology when discussing I2P and "
+"cryptography."
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:2
+msgid "Hall Of Fame"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:5
+msgid "I2P's Hall of Fame"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:6
+#, python-format
+msgid "Current balance: as of %(date)s"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:9
+#: i2p2www/pages/site/about/hall-of-fame.html:46
+#: i2p2www/pages/site/about/hall-of-fame.html:53
+#: i2p2www/pages/site/about/hall-of-fame.html:54
+#: i2p2www/pages/site/about/hall-of-fame.html:55
+#: i2p2www/pages/site/about/hall-of-fame.html:56
+#: i2p2www/pages/site/about/hall-of-fame.html:58
+#: i2p2www/pages/site/about/hall-of-fame.html:59
+#: i2p2www/pages/site/about/hall-of-fame.html:60
+#: i2p2www/pages/site/about/hall-of-fame.html:63
+#: i2p2www/pages/site/about/hall-of-fame.html:64
+#: i2p2www/pages/site/about/hall-of-fame.html:65
+#: i2p2www/pages/site/about/hall-of-fame.html:68
+#: i2p2www/pages/site/about/hall-of-fame.html:69
+#: i2p2www/pages/site/about/hall-of-fame.html:70
+#: i2p2www/pages/site/about/hall-of-fame.html:71
+#: i2p2www/pages/site/about/hall-of-fame.html:72
+#: i2p2www/pages/site/about/hall-of-fame.html:73
+#: i2p2www/pages/site/about/hall-of-fame.html:74
+#: i2p2www/pages/site/about/hall-of-fame.html:75
+#: i2p2www/pages/site/about/hall-of-fame.html:76
+#: i2p2www/pages/site/about/hall-of-fame.html:77
+#: i2p2www/pages/site/about/hall-of-fame.html:78
+#: i2p2www/pages/site/about/hall-of-fame.html:79
+#: i2p2www/pages/site/about/hall-of-fame.html:80
+#: i2p2www/pages/site/about/hall-of-fame.html:83
+#: i2p2www/pages/site/about/hall-of-fame.html:84
+#: i2p2www/pages/site/about/hall-of-fame.html:85
+#: i2p2www/pages/site/about/hall-of-fame.html:86
+#: i2p2www/pages/site/about/hall-of-fame.html:87
+#: i2p2www/pages/site/about/hall-of-fame.html:88
+#: i2p2www/pages/site/about/hall-of-fame.html:90
+#: i2p2www/pages/site/about/hall-of-fame.html:91
+#: i2p2www/pages/site/about/hall-of-fame.html:94
+#: i2p2www/pages/site/about/hall-of-fame.html:95
+#: i2p2www/pages/site/about/hall-of-fame.html:96
+#: i2p2www/pages/site/about/hall-of-fame.html:97
+#: i2p2www/pages/site/about/hall-of-fame.html:98
+#: i2p2www/pages/site/about/hall-of-fame.html:100
+#: i2p2www/pages/site/about/hall-of-fame.html:101
+#: i2p2www/pages/site/about/hall-of-fame.html:102
+#: i2p2www/pages/site/about/hall-of-fame.html:103
+#: i2p2www/pages/site/about/hall-of-fame.html:104
+#: i2p2www/pages/site/about/hall-of-fame.html:105
+#: i2p2www/pages/site/about/hall-of-fame.html:107
+#: i2p2www/pages/site/about/hall-of-fame.html:108
+#: i2p2www/pages/site/about/hall-of-fame.html:109
+#: i2p2www/pages/site/about/hall-of-fame.html:110
+#: i2p2www/pages/site/about/hall-of-fame.html:112
+#: i2p2www/pages/site/about/hall-of-fame.html:113
+#: i2p2www/pages/site/about/hall-of-fame.html:114
+#: i2p2www/pages/site/about/hall-of-fame.html:115
+#: i2p2www/pages/site/about/hall-of-fame.html:116
+#: i2p2www/pages/site/about/hall-of-fame.html:119
+#: i2p2www/pages/site/about/hall-of-fame.html:120
+#: i2p2www/pages/site/about/hall-of-fame.html:121
+#: i2p2www/pages/site/about/hall-of-fame.html:122
+#: i2p2www/pages/site/about/hall-of-fame.html:124
+#: i2p2www/pages/site/about/hall-of-fame.html:125
+#: i2p2www/pages/site/about/hall-of-fame.html:126
+#: i2p2www/pages/site/about/hall-of-fame.html:128
+#: i2p2www/pages/site/about/hall-of-fame.html:129
+#: i2p2www/pages/site/about/hall-of-fame.html:130
+#: i2p2www/pages/site/about/hall-of-fame.html:131
+#: i2p2www/pages/site/about/hall-of-fame.html:133
+#: i2p2www/pages/site/about/hall-of-fame.html:134
+#: i2p2www/pages/site/about/hall-of-fame.html:135
+#: i2p2www/pages/site/about/hall-of-fame.html:136
+#: i2p2www/pages/site/about/hall-of-fame.html:137
+#: i2p2www/pages/site/about/hall-of-fame.html:143
+#: i2p2www/pages/site/about/hall-of-fame.html:146
+#: i2p2www/pages/site/about/hall-of-fame.html:147
+#: i2p2www/pages/site/about/hall-of-fame.html:148
+#: i2p2www/pages/site/about/hall-of-fame.html:149
+#: i2p2www/pages/site/about/hall-of-fame.html:150
+#: i2p2www/pages/site/about/hall-of-fame.html:152
+#: i2p2www/pages/site/about/hall-of-fame.html:153
+#: i2p2www/pages/site/about/hall-of-fame.html:154
+#: i2p2www/pages/site/about/hall-of-fame.html:159
+#: i2p2www/pages/site/about/hall-of-fame.html:160
+#: i2p2www/pages/site/about/hall-of-fame.html:161
+#: i2p2www/pages/site/about/hall-of-fame.html:162
+#: i2p2www/pages/site/about/hall-of-fame.html:163
+#: i2p2www/pages/site/about/hall-of-fame.html:164
+#: i2p2www/pages/site/about/hall-of-fame.html:165
+#: i2p2www/pages/site/about/hall-of-fame.html:166
+#: i2p2www/pages/site/about/hall-of-fame.html:167
+#: i2p2www/pages/site/about/hall-of-fame.html:168
+#: i2p2www/pages/site/about/hall-of-fame.html:170
+#: i2p2www/pages/site/about/hall-of-fame.html:171
+#: i2p2www/pages/site/about/hall-of-fame.html:180
+#: i2p2www/pages/site/about/hall-of-fame.html:181
+#: i2p2www/pages/site/about/hall-of-fame.html:182
+#: i2p2www/pages/site/about/hall-of-fame.html:183
+#: i2p2www/pages/site/about/hall-of-fame.html:184
+#: i2p2www/pages/site/about/hall-of-fame.html:185
+#: i2p2www/pages/site/about/hall-of-fame.html:186
+#: i2p2www/pages/site/about/hall-of-fame.html:187
+#: i2p2www/pages/site/about/hall-of-fame.html:188
+#: i2p2www/pages/site/about/hall-of-fame.html:189
+#: i2p2www/pages/site/about/hall-of-fame.html:190
+#: i2p2www/pages/site/about/hall-of-fame.html:191
+#: i2p2www/pages/site/about/hall-of-fame.html:192
+#: i2p2www/pages/site/about/hall-of-fame.html:193
+#: i2p2www/pages/site/about/hall-of-fame.html:194
+#: i2p2www/pages/site/about/hall-of-fame.html:195
+#: i2p2www/pages/site/about/hall-of-fame.html:196
+#: i2p2www/pages/site/about/hall-of-fame.html:197
+#: i2p2www/pages/site/about/hall-of-fame.html:198
+#: i2p2www/pages/site/about/hall-of-fame.html:199
+#: i2p2www/pages/site/about/hall-of-fame.html:200
+#: i2p2www/pages/site/about/hall-of-fame.html:204
+#: i2p2www/pages/site/about/hall-of-fame.html:205
+#: i2p2www/pages/site/about/hall-of-fame.html:206
+#: i2p2www/pages/site/about/hall-of-fame.html:207
+#: i2p2www/pages/site/about/hall-of-fame.html:208
+#: i2p2www/pages/site/about/hall-of-fame.html:209
+#: i2p2www/pages/site/about/hall-of-fame.html:210
+#: i2p2www/pages/site/about/hall-of-fame.html:212
+#: i2p2www/pages/site/about/hall-of-fame.html:213
+#: i2p2www/pages/site/about/hall-of-fame.html:214
+#: i2p2www/pages/site/about/hall-of-fame.html:215
+#: i2p2www/pages/site/about/hall-of-fame.html:216
+#: i2p2www/pages/site/about/hall-of-fame.html:217
+#: i2p2www/pages/site/about/hall-of-fame.html:218
+#: i2p2www/pages/site/about/hall-of-fame.html:219
+#: i2p2www/pages/site/about/hall-of-fame.html:220
+#: i2p2www/pages/site/about/hall-of-fame.html:223
+#: i2p2www/pages/site/about/hall-of-fame.html:224
+#: i2p2www/pages/site/about/hall-of-fame.html:225
+#: i2p2www/pages/site/about/hall-of-fame.html:226
+#: i2p2www/pages/site/about/hall-of-fame.html:227
+#: i2p2www/pages/site/about/hall-of-fame.html:229
+#: i2p2www/pages/site/about/hall-of-fame.html:231
+#: i2p2www/pages/site/about/hall-of-fame.html:232
+#: i2p2www/pages/site/about/hall-of-fame.html:233
+#: i2p2www/pages/site/about/hall-of-fame.html:234
+#: i2p2www/pages/site/about/hall-of-fame.html:235
+#: i2p2www/pages/site/about/hall-of-fame.html:236
+#: i2p2www/pages/site/about/hall-of-fame.html:237
+#: i2p2www/pages/site/about/hall-of-fame.html:239
+#: i2p2www/pages/site/about/hall-of-fame.html:240
+#: i2p2www/pages/site/about/hall-of-fame.html:241
+#: i2p2www/pages/site/about/hall-of-fame.html:242
+#: i2p2www/pages/site/about/hall-of-fame.html:243
+#: i2p2www/pages/site/about/hall-of-fame.html:244
+#: i2p2www/pages/site/about/hall-of-fame.html:245
+#: i2p2www/pages/site/about/hall-of-fame.html:246
+#: i2p2www/pages/site/about/hall-of-fame.html:247
+#: i2p2www/pages/site/about/hall-of-fame.html:248
+#: i2p2www/pages/site/about/hall-of-fame.html:249
+#: i2p2www/pages/site/about/hall-of-fame.html:250
+#: i2p2www/pages/site/about/hall-of-fame.html:251
+#: i2p2www/pages/site/about/hall-of-fame.html:252
+#: i2p2www/pages/site/about/hall-of-fame.html:254
+#: i2p2www/pages/site/about/hall-of-fame.html:255
+#: i2p2www/pages/site/about/hall-of-fame.html:256
+#: i2p2www/pages/site/about/hall-of-fame.html:259
+#: i2p2www/pages/site/about/hall-of-fame.html:260
+#: i2p2www/pages/site/about/hall-of-fame.html:263
+#: i2p2www/pages/site/about/hall-of-fame.html:264
+#: i2p2www/pages/site/about/hall-of-fame.html:266
+#: i2p2www/pages/site/about/hall-of-fame.html:267
+#: i2p2www/pages/site/about/hall-of-fame.html:280
+#: i2p2www/pages/site/about/hall-of-fame.html:281
+#: i2p2www/pages/site/about/hall-of-fame.html:282
+#: i2p2www/pages/site/about/hall-of-fame.html:283
+#: i2p2www/pages/site/about/hall-of-fame.html:284
+#: i2p2www/pages/site/about/hall-of-fame.html:285
+#: i2p2www/pages/site/about/hall-of-fame.html:286
+#: i2p2www/pages/site/about/hall-of-fame.html:287
+#: i2p2www/pages/site/about/hall-of-fame.html:288
+#: i2p2www/pages/site/about/hall-of-fame.html:289
+#: i2p2www/pages/site/about/hall-of-fame.html:290
+#: i2p2www/pages/site/about/hall-of-fame.html:291
+#: i2p2www/pages/site/about/hall-of-fame.html:292
+#: i2p2www/pages/site/about/hall-of-fame.html:293
+#: i2p2www/pages/site/about/hall-of-fame.html:294
+#: i2p2www/pages/site/about/hall-of-fame.html:295
+#: i2p2www/pages/site/about/hall-of-fame.html:296
+#: i2p2www/pages/site/about/hall-of-fame.html:297
+#: i2p2www/pages/site/about/hall-of-fame.html:298
+#: i2p2www/pages/site/about/hall-of-fame.html:299
+#: i2p2www/pages/site/about/hall-of-fame.html:300
+#: i2p2www/pages/site/about/hall-of-fame.html:301
+#: i2p2www/pages/site/about/hall-of-fame.html:302
+#: i2p2www/pages/site/about/hall-of-fame.html:303
+#: i2p2www/pages/site/about/hall-of-fame.html:304
+#: i2p2www/pages/site/about/hall-of-fame.html:305
+#: i2p2www/pages/site/about/hall-of-fame.html:306
+#: i2p2www/pages/site/about/hall-of-fame.html:307
+#: i2p2www/pages/site/about/hall-of-fame.html:308
+#: i2p2www/pages/site/about/hall-of-fame.html:309
+#: i2p2www/pages/site/about/hall-of-fame.html:310
+#: i2p2www/pages/site/about/hall-of-fame.html:311
+#: i2p2www/pages/site/about/hall-of-fame.html:312
+#: i2p2www/pages/site/about/hall-of-fame.html:313
+#: i2p2www/pages/site/about/hall-of-fame.html:314
+#: i2p2www/pages/site/about/hall-of-fame.html:316
+#: i2p2www/pages/site/about/hall-of-fame.html:317
+#: i2p2www/pages/site/about/hall-of-fame.html:318
+#: i2p2www/pages/site/about/hall-of-fame.html:319
+#: i2p2www/pages/site/about/hall-of-fame.html:320
+#: i2p2www/pages/site/about/hall-of-fame.html:321
+#: i2p2www/pages/site/about/hall-of-fame.html:322
+#: i2p2www/pages/site/about/hall-of-fame.html:323
+#: i2p2www/pages/site/about/hall-of-fame.html:325
+#: i2p2www/pages/site/about/hall-of-fame.html:326
+#: i2p2www/pages/site/about/hall-of-fame.html:327
+#: i2p2www/pages/site/about/hall-of-fame.html:329
+#: i2p2www/pages/site/about/hall-of-fame.html:330
+#: i2p2www/pages/site/about/hall-of-fame.html:331
+#: i2p2www/pages/site/about/hall-of-fame.html:332
+#: i2p2www/pages/site/about/hall-of-fame.html:333
+#: i2p2www/pages/site/about/hall-of-fame.html:335
+#: i2p2www/pages/site/about/hall-of-fame.html:338
+#: i2p2www/pages/site/about/hall-of-fame.html:339
+#: i2p2www/pages/site/about/hall-of-fame.html:340
+#: i2p2www/pages/site/about/hall-of-fame.html:341
+#: i2p2www/pages/site/about/hall-of-fame.html:342
+#: i2p2www/pages/site/about/hall-of-fame.html:343
+#: i2p2www/pages/site/about/hall-of-fame.html:344
+#: i2p2www/pages/site/about/hall-of-fame.html:345
+#: i2p2www/pages/site/about/hall-of-fame.html:346
+#: i2p2www/pages/site/about/hall-of-fame.html:347
+#: i2p2www/pages/site/about/hall-of-fame.html:348
+#: i2p2www/pages/site/about/hall-of-fame.html:349
+#: i2p2www/pages/site/about/hall-of-fame.html:350
+#: i2p2www/pages/site/about/hall-of-fame.html:351
+#: i2p2www/pages/site/about/hall-of-fame.html:353
+#: i2p2www/pages/site/about/hall-of-fame.html:354
+#: i2p2www/pages/site/about/hall-of-fame.html:355
+#: i2p2www/pages/site/about/hall-of-fame.html:357
+#: i2p2www/pages/site/about/hall-of-fame.html:360
+#: i2p2www/pages/site/about/hall-of-fame.html:361
+#: i2p2www/pages/site/about/hall-of-fame.html:362
+#: i2p2www/pages/site/about/hall-of-fame.html:363
+#: i2p2www/pages/site/about/hall-of-fame.html:364
+#: i2p2www/pages/site/about/hall-of-fame.html:365
+#: i2p2www/pages/site/about/hall-of-fame.html:366
+#: i2p2www/pages/site/about/hall-of-fame.html:367
+#: i2p2www/pages/site/about/hall-of-fame.html:368
+#: i2p2www/pages/site/about/hall-of-fame.html:369
+#: i2p2www/pages/site/about/hall-of-fame.html:370
+#: i2p2www/pages/site/about/hall-of-fame.html:371
+#: i2p2www/pages/site/about/hall-of-fame.html:372
+#: i2p2www/pages/site/about/hall-of-fame.html:373
+#: i2p2www/pages/site/about/hall-of-fame.html:374
+#: i2p2www/pages/site/about/hall-of-fame.html:375
+#: i2p2www/pages/site/about/hall-of-fame.html:376
+#: i2p2www/pages/site/about/hall-of-fame.html:377
+#: i2p2www/pages/site/about/hall-of-fame.html:378
+#: i2p2www/pages/site/about/hall-of-fame.html:380
+#: i2p2www/pages/site/about/hall-of-fame.html:381
+#: i2p2www/pages/site/about/hall-of-fame.html:382
+msgid "General fund"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:10
+#: i2p2www/pages/site/about/hall-of-fame.html:12
+#: i2p2www/pages/site/about/hall-of-fame.html:20
+#, python-format
+msgid "%(euroval)s € and %(btcval)s BTC"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:11
+msgid "Datastorage bounty"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:13
+msgid "Native IPv6 I2P"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:14
+#: i2p2www/pages/site/about/hall-of-fame.html:16
+#: i2p2www/pages/site/about/hall-of-fame.html:18
+#: i2p2www/pages/site/about/hall-of-fame.html:22
+#, python-format
+msgid "%(euroval)s €"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:15
+msgid "I2PHex bounty"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:17
+msgid "I2P in debian mirrors"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:19
+#: i2p2www/pages/site/get-involved/bounties/index.html:67
+msgid "Bitcoin client for I2P"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:21
+msgid "Unit Tests for I2P router"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:23
+msgid "Bounty Robert"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:24
+msgid "Bounty Syndie"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:27
+msgid "Current monthly running costs:"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:38
+msgid "Big thanks go to the following people who have donated to I2P!"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:39
+#, python-format
+msgid ""
+"If you have made a donation, please send an email to echelon\n"
+"with your name or nick (and optionally homepage) so we can list you here."
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:44
+msgid "Current monthly subscriptions:"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:177
+msgid "2011 donations and costs:"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:278
+msgid "Previous to 2011 donations:"
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:2
+msgid "Intro"
+msgstr "Introducción"
+
+#: i2p2www/pages/site/about/intro.html:5
+msgid ""
+"I2P is an anonymous network, exposing a simple layer that applications "
+"can \n"
+"use to anonymously and securely send messages to each other. The network "
+"itself is \n"
+"strictly message based (a la \n"
+"IP), but "
+"there is a \n"
+"library available to allow reliable streaming communication on top of it "
+"(a la \n"
+"TCP)."
+"  \n"
+"All communication is end to end encrypted (in total there are four layers"
+" of \n"
+"encryption used when sending a message), and even the end points "
+"(\"destinations\") \n"
+"are cryptographic identifiers (essentially a pair of public "
+"keys)."
+msgstr ""
+"I2P es una red anónima que da acceso a una capa de red que las aplicaciones pueden\n"
+"utilizar para anonimizar y cifrar el envío de mensajes de uno a otro. La red en sí está\n"
+"estrictamente basada en el envío de mensajes.(a la \n"
+" IP), pero existe una \n"
+"librería disponible que permite la comunicación segura sobre él ((a la \n"
+"TCP).  \n"
+"Todas las comunicaciones están cifradas de extremo a extremo ( en total de usan 4 \n"
+"caps de cifrados cifrados por cada mensaje enviado), e incluso el extremo final \n"
+"(\"destinations\") son identificados criptográficamente (básicamente con un par de \n"
+"claves públicas)."
+
+#: i2p2www/pages/site/about/intro.html:19
+#, python-format
+msgid ""
+"To anonymize the messages sent, each client application has their I2P "
+"\"router\"\n"
+"build a few inbound and outbound \"tunnels\" - a \n"
+"sequence of peers that pass messages in one direction (to and from the "
+"client, \n"
+"respectively).  In turn, when a client wants to send a message to another"
+" client, \n"
+"the client passes that message out one of their outbound tunnels "
+"targeting one of the \n"
+"other client's inbound tunnels, eventually reaching the destination.  "
+"Every \n"
+"participant in the network chooses the length of these tunnels, and in "
+"doing so, \n"
+"makes a tradeoff between anonymity, latency, and throughput according to "
+"their \n"
+"own needs.  The result is that the number of peers relaying each end to "
+"end \n"
+"message is the absolute minimum necessary to meet both the sender's and "
+"the \n"
+"receiver's threat model."
+msgstr ""
+"Para a anonimizar los mensajes enviados, cada aplicación cliente tiene su \"ruter\" I2P\n"
+"que crea unos cuantos túneles\"  de entrada y \n"
+"salida - una secuehcia de pares que pasan el mensaje en una dirección\n"
+"(hacia y desde el cliente, respectivamente ) A su vez, cuando un cliente \n"
+"quiere enviar un mensaje a otro cliente, el cliente envía ese mansaje a través \n"
+"de uno de sus túneles de salida hacia uno de los túneles de \n"
+"entrada del otro cliente, eventualmente alcanzando su destino."
+
+#: i2p2www/pages/site/about/intro.html:33
+#, python-format
+msgid ""
+"The first time a client wants to contact another client, they make a "
+"query \n"
+"against the fully distributed \"network \n"
+"database\" - a custom structured \n"
+"distributed hash table (DHT) based off the \n"
+" Kademlia "
+"algorithm. This is done \n"
+"to find the other client's inbound tunnels efficiently, but subsequent "
+"messages \n"
+"between them usually includes that data so no further network database "
+"lookups \n"
+"are required."
+msgstr ""
+"La primera vez que un cliente quiere contactar con otro cliente, consultan \n"
+"la \"base de datos distribuida de la red\" - unas \n"
+" tablas de \n"
+"hash distribuidas propia (DHT) basada en el  \n"
+"algoritmo Kademlia. Esto se\n"
+"hace para encontrar el túnel de entrada del otro cliente eficientemente, pero los \n"
+"mensajes siguientes entre los clientes usualmente incluye la información, con lo cual\n"
+"no hace falta buscar en la base de datos de la red otra vez."
+
+#: i2p2www/pages/site/about/intro.html:44
+#, python-format
+msgid "More details about how I2P works are available."
+msgstr ""
+"Puede encontrar mas detalles sobre el funcionamienteo de I2P en \n"
+"available."
+
+#: i2p2www/pages/site/about/intro.html:48
+msgid "What can you do with it?"
+msgstr "¿Qué puede hacer con él?"
+
+#: i2p2www/pages/site/about/intro.html:50
+#, python-format
+msgid ""
+"Within the I2P network, applications are not restricted in how they can \n"
+"communicate - those that typically use UDP can make use of the base I2P \n"
+"functionality, and those that typically use TCP can use the TCP-like "
+"streaming\n"
+"library.  We have a generic TCP/I2P bridge application \n"
+"(\"I2PTunnel\") that enables people to "
+"forward TCP streams\n"
+"into the I2P network as well as to receive streams out of the network and"
+" \n"
+"forward them towards a specific TCP/IP address."
+msgstr ""
+"Dentro de la red I2P las aplicaciones no tienen restricciones en como \n"
+"pueden comunicarse - aquellas que normalmente usan UDP pueden usar\n"
+"las funcionalidades básicas de I2P, y aquellas aplicaciones que normalmete \n"
+"usan TCP pueden utilizar la y la librería 'TCP-like streaming'. I2P Iincluye  una \n"
+"aplicación generica de puente TCP/I2P (\"I2PTunnel\") \n"
+"que permite enviar flujos TCP dentro de la red I2P, también recibir flujos TCP de fuera \n"
+"de la red y  enviar estos a una dirección IP específica."
+
+#: i2p2www/pages/site/about/intro.html:60
+msgid ""
+"I2PTunnel is currently used to let people run their own anonymous website"
+" \n"
+"(\"eepsite\") by running a normal webserver and pointing an I2PTunnel "
+"'server' \n"
+"at it, which people can access anonymously over I2P with a normal web "
+"browser \n"
+"by running an I2PTunnel HTTP proxy (\"eepproxy\").  In addition, we use "
+"the same \n"
+"technique to run an anonymous IRC network (where the IRC server is hosted"
+" \n"
+"anonymously, and standard IRC clients use an I2PTunnel to contact it).  "
+"There \n"
+"are other application development efforts going on as well, such as one "
+"to \n"
+"build an optimized swarming file transfer application (a la \n"
+"BitTorrent), a \n"
+"distributed data store (a la Freenet / \n"
+"MNet), and a blogging system (a "
+"fully \n"
+"distributed LiveJournal), but"
+" those are \n"
+"not ready for use yet."
+msgstr ""
+"El túnel I2P (I2Ptunnel) es actualmente usado para permitir a la gente tener su\n"
+"propia web anónima (\"eepsite\"), ejecutando un servidor web normal y creando un \n"
+"túnel 'servidor' hacia ella, esta eepsite podrá ser accedida anónimamente sobre I2P \n"
+"con un navegador web normal usando un túnel proxy I2P (\"eepproxy\"). Además \n"
+"usamos la misma técnica para ejecutar redes IRC anónimas (donde el servidor\n"
+"IRC esta hospedado anónimamente y los clientes normales de IRC usan un túnel I2P\n"
+"para conectarse). Se están haciendo esfuerzos para programar otras palicaciones, \n"
+"como una aplicación optimizada para compartir archivos (a la \n"
+"BitTorrent), \n"
+"almacenamiento de datos distribuido (a la Freenet / \n"
+"MNet), y un sistema de blogs totalmente\n"
+"distribuido LiveJournal, pero estos \n"
+"no están totalmente listos todavía. "
+
+#: i2p2www/pages/site/about/intro.html:76
+msgid ""
+"I2P is not inherently an \"outproxy\" network - the client you send a "
+"message \n"
+"to is the cryptographic identifier, not some IP address, so the message "
+"must \n"
+"be addressed to someone running I2P.  However, it is possible for that "
+"client\n"
+"to be an outproxy, allowing you to anonymously make use of their Internet"
+" \n"
+"connection.  To demonstrate this, the \"eepproxy\" will accept normal "
+"non-I2P \n"
+"URLs (e.g. \"http://www.i2p.net\") and forward them to a specific "
+"destination\n"
+"that runs a squid HTTP proxy,"
+" allowing \n"
+"simple anonymous browsing of the normal web.  Simple outproxies like that"
+" are \n"
+"not viable in the long run for several reasons (including the cost of "
+"running \n"
+"one as well as the anonymity and security issues they introduce), but in"
+" \n"
+"certain circumstances the technique could be appropriate."
+msgstr ""
+"I2P no es inherentemente una red \"outproxy\" - el cliente al que envías\n"
+"un mensaje es un identificador criptográfico, no una dirección IP, por lo cual\n"
+"el mensaje debe ser enviado a alguien que use I2P. Aunque es posible que \n"
+"un cliente sea un 'outproxy', permitiendo el uso de una conexión a Internet \n"
+"anónima, el \"eepproxy\"  aceptará URLs normales (no I2P) (e.g. \"http://www.i2p.net\")\n"
+"y las reenviará a una destinación específica que usa un proxy HTTP \n"
+"squid, permitiendo navegar Internet \n"
+"de una forma anónima y fácil. Outproxies como estos no son siempre viables  por\n"
+"varias razones (incluyendo el coste de tener uno y los problemas de anonimato y\n"
+"seguridad que acarrea), pero en ciertas circunstancias su uso puede ser apropiado"
+
+#: i2p2www/pages/site/about/intro.html:90
+#, python-format
+msgid ""
+"The I2P development team is an open group, "
+"welcome to all \n"
+"who are interested in getting involved, and"
+" all of \n"
+"the code is open source.  The core I2P SDK "
+"and the \n"
+"current router implementation is done in Java (currently working with "
+"both \n"
+"sun and kaffe, gcj support planned for later), and there is a \n"
+"simple socket based API for accessing the network"
+" from \n"
+"other languages (with a C library available, and both Python and Perl in"
+" \n"
+"development).  The network is actively being developed and has not yet "
+"reached \n"
+"the 1.0 release, but the current roadmap "
+"describes \n"
+"our schedule."
+msgstr ""
+"El equipo de desarrollo de I2P es un grupo abierto, todos \n"
+"los que estén interesados son bienvenidos a involucrarse\n"
+"en el proyecto, y todo el código es libre. El núcleo de I2P \n"
+"y la implementación del ruter están en java (actualmente trabajando con sun y kaffe, \n"
+"el soporte para gjc está planeado para mas adelante), y hay un simpl \n"
+"socket based API para acceder a la red desde otros lenguajes (con una librería C \n"
+"disponible, y con Python y Perl en desarrollo). La red está en estos momentos en desarrollo \n"
+"activamente y aún no ha alcanzado la versión 1.0, pero la actual \n"
+"hoja de ruta describe nuestro programa."
+
+#: i2p2www/pages/site/about/media.html:2 i2p2www/pages/site/about/media.html:4
+msgid "Presentations on I2P"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:5
+#, python-format
+msgid ""
+"Following are links to presentations, videos, and tutorials about I2P. "
+"Links to research papers on I2P are available here."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:8
+#: i2p2www/pages/site/research/papers.html:8
+#, python-format
+msgid "To request an addition to this page, please send to %(email)s."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:11
+msgid ""
+"\n"
+"Newest links are at the bottom of each section."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:16
+msgid "Presentations"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:19
+#, python-format
+msgid ""
+"IIP Presentation at CodeCon\n"
+"MP3 audio\n"
+"transcript\n"
+"Lance James (0x90), February 2002."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:27
+#, python-format
+msgid ""
+"IIP Presentation at ToorCon\n"
+"MP3 audio\n"
+"slides\n"
+"Lance James (0x90), September 2002."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:35
+#, python-format
+msgid ""
+"To Be or I2P\n"
+"(Youtube Video)\n"
+"An introduction into anonymous communication with I2P.\n"
+"To Be or I2P (PDF presentation),\n"
+"Jens Kubieziel, 24C3 Berlin, December 28, 2007."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:44
+#, python-format
+msgid ""
+"Video of I2P talk at Chemnitz Linux Tag,\n"
+"Lars Schimmer,\n"
+"March 14-15, 2009"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:50
+#, python-format
+msgid ""
+"HOPE New York July 17, 2010 - Brief overview of I2P by zzz, at the end of"
+" Adrian Hong's talk\n"
+"\"Hackers for Human Rights\".\n"
+"MP3 audio"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:56
+#, python-format
+msgid ""
+"Into the I2P Darknet: Welcome to Cipherspace\n"
+"Adrian Crenshaw. Schmoocon Firetalk, January 2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:61
+#, python-format
+msgid ""
+"Using techhnology to advance liberty\n"
+"(Youtube Video)\n"
+"Eric Johnson.\n"
+"Agora I/O Unconference, March 27,"
+" 2011.\n"
+"I2P covered from 10:00 to 20:00 in the video."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:69
+#, python-format
+msgid ""
+"The Bright side of darknets, FOSSCOMM Patras May "
+"2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:73
+#, python-format
+msgid ""
+"Common Darknet Weaknesses\n"
+"(Youtube Video)\n"
+"Adrian Crenshaw, AIDE, July "
+"11-15, 2011."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:79
+#, python-format
+msgid ""
+"I2P / Tor Workshop Notes\n"
+"Adrian Crenshaw. DEF CON 19, Las Vegas, August 6, 2011."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:84
+#, python-format
+msgid ""
+"Cipherspaces/Darknets: An Overview Of Attack "
+"Strategies -\n"
+"DEF CON Live version (Youtube Video),\n"
+"\"Studio\" version (Youtube Video),\n"
+"Slides (ppt)\n"
+"Adrian Crenshaw. DEF CON 19, Las Vegas, August 7, 2011."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:94
+msgid ""
+"Modern cipherspace ecosystems, 0x375 "
+"0x06 4/11/2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:100
+msgid "Tutorials"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:103
+#, python-format
+msgid ""
+"I2P Windows Tutorial\n"
+"(Youtube Video)\n"
+"This guide will show you how to install I2P in Windows XP.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:111
+#, python-format
+msgid ""
+"I2P Debian Tutorial\n"
+"(Youtube Video)\n"
+"This will guide you through how to install I2P on a Debian Linux System.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:119
+#, python-format
+msgid ""
+"How to set up anonymous site in I2P\n"
+"(Youtube Video)\n"
+"How to set up an anonymous web site in I2P.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:126
+#, python-format
+msgid ""
+"I2P Tutorial Mac OS X\n"
+"(Youtube Video)\n"
+"A tutorial on how to run i2p on Mac OS X and how to connect to "
+"irc.telecomix.i2p.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:133
+#, python-format
+msgid ""
+"Felix Atari explains the basic principles of I2P"
+"\n"
+"(Youtube Video)\n"
+"Agent Felix Atari of the Telecomix Crypto Munitions Bureau.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:140
+#, python-format
+msgid ""
+"How to get onto I2P, the anonymous P2P Darknet "
+"(Windows Install)\n"
+"(Youtube Video)\n"
+"This tutorial shows how to install and configure software needed to "
+"access I2P."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:146
+#, python-format
+msgid ""
+"How to connect to I2P\n"
+"(Youtube Video)\n"
+"How to install I2P on Ubuntu."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:152
+#, python-format
+msgid ""
+"Installing the I2P darknet software in Linux\n"
+"(Video)\n"
+"Adrian Crenshaw.\n"
+"January 2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:159
+#, python-format
+msgid ""
+"Short garlic routing animation\n"
+"(Youtube Video)\n"
+"Adrian Crenshaw.\n"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:167
+msgid "Articles and Interviews"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:170
+#, python-format
+msgid ""
+"0x90 Interviewed by DistributedCity\n"
+"Part 1\n"
+"Part 2\n"
+"July 26, 2002."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:178
+#, python-format
+msgid ""
+"0x90 Interviewed by El Pais\n"
+"(original in Spanish)\n"
+"English translation\n"
+"October 31, 2002."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:185
+#, python-format
+msgid ""
+"2003 Business Week article referencing "
+"invisiblenet"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:189
+#, python-format
+msgid ""
+"Netzwelt.de article about being anonymous in the "
+"Internet\n"
+"(German)\n"
+"November 2007."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:195
+#, python-format
+msgid ""
+"zzz interviewed by gulli.com\n"
+"March 2009\n"
+"German translation\n"
+"Russian translation"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:204
+#, python-format
+msgid ""
+"zzz interviewed on the InfoSec Daily Podcast Ep. 454 "
+"(mp3)\n"
+"August 18, 2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:209
+#, python-format
+msgid ""
+"I2P - Anonymity for the Masses,\n"
+"Jonathan Cox,\n"
+"November 11, 2011."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:215
+#, python-format
+msgid ""
+"zzz and Lance James interviewed on the InfoSec Daily "
+"Podcast Ep. 596 (mp3)\n"
+"February 16, 2012"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:4
+msgid "I2P Project Members"
+msgstr "Miembros del proyecto I2P"
+
+#: i2p2www/pages/site/about/team.html:5
+#, python-format
+msgid ""
+"We are a small group of people spread around several continents, working "
+"to\n"
+"advance different aspects of the project and discussing the design of the"
+"\n"
+"network.\n"
+"Get involved!"
+msgstr ""
+"Somos un pequeño grupo de personas repartidas por varios continentes, trabajando\n"
+"para mejorar diferentes aspectos del proyecto y discutir el diseño de la red.\n"
+"¿Unete!"
+
+#: i2p2www/pages/site/about/team.html:14
+msgid "Admin"
+msgstr "Administradores"
+
+#: i2p2www/pages/site/about/team.html:15
+msgid "Project Manager"
+msgstr "Director del protecyo"
+
+#: i2p2www/pages/site/about/team.html:17
+msgid "point of contact of last resort"
+msgstr "contacto como último recurso"
+
+#: i2p2www/pages/site/about/team.html:20
+msgid "Treasurer"
+msgstr "Tesorero"
+
+#: i2p2www/pages/site/about/team.html:22
+msgid "manage donations / accounts / bounties"
+msgstr "administra las donaciones / cuentas / recompensas"
+
+#: i2p2www/pages/site/about/team.html:25
+msgid "PR manager"
+msgstr "Administrador PR"
+
+#: i2p2www/pages/site/about/team.html:27
+msgid "press contact, manages public relations and affairs"
+msgstr "contacto con la prensa, relaciones públicas y negocios"
+
+#: i2p2www/pages/site/about/team.html:30
+#, python-format
+msgid "Forum admin"
+msgstr "Administrador del Foro"
+
+#: i2p2www/pages/site/about/team.html:32
+msgid "manage the public user forum"
+msgstr "administrador del foro público"
+
+#: i2p2www/pages/site/about/team.html:35
+msgid "Mirrors admin"
+msgstr "Administrador de mirrors"
+
+#: i2p2www/pages/site/about/team.html:37
+msgid "manage the project mirrors"
+msgstr "administrador de los proyectos de los mirrors"
+
+#: i2p2www/pages/site/about/team.html:40
+#, python-format
+msgid "Monotone guru"
+msgstr "El código actual está disponible en monotone."
+
+#: i2p2www/pages/site/about/team.html:42
+msgid "manage the public monotone repositories"
+msgstr "administrador de los repositorios públlicos de monotone"
+
+#: i2p2www/pages/site/about/team.html:45
+msgid "Packager; Linux"
+msgstr "Empaquetador; Linux"
+
+#: i2p2www/pages/site/about/team.html:47
+msgid "Linux (Debian/Ubuntu) distribution packager"
+msgstr "Mantenimiento de paquetes para distribuciones Linux (Debian/Ubuntu)"
+
+#: i2p2www/pages/site/about/team.html:50
+msgid "Packager; Windows"
+msgstr "Empaquetador; Windows"
+
+#: i2p2www/pages/site/about/team.html:52
+msgid "Windows installer packager"
+msgstr "Paquetes instaladores para Windows"
+
+#: i2p2www/pages/site/about/team.html:55
+msgid "Release Manager"
+msgstr "Administrador de versiones"
+
+#: i2p2www/pages/site/about/team.html:57
+msgid "Builds and signs the releases"
+msgstr "Compila y firma los paquetes"
+
+#: i2p2www/pages/site/about/team.html:60
+msgid "Update admin"
+msgstr "Administrador de actualizaciones"
+
+#: i2p2www/pages/site/about/team.html:62
+#, fuzzy
+msgid "Monitors and recruits in-network update hosts"
+msgstr "Supervisa y recluta hosts de la red"
+
+#: i2p2www/pages/site/about/team.html:65
+msgid "Reseed admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:67
+msgid "Monitors, advises and recruits reseed hosts"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:70
+msgid "Security expert"
+msgstr "Experto en seguridad"
+
+#: i2p2www/pages/site/about/team.html:71 i2p2www/pages/site/about/team.html:76
+#: i2p2www/pages/site/about/team.html:81 i2p2www/pages/site/about/team.html:91
+#: i2p2www/pages/site/about/team.html:101
+#: i2p2www/pages/site/about/team.html:138
+#: i2p2www/pages/site/about/team.html:148
+#: i2p2www/pages/site/about/team.html:153
+#: i2p2www/pages/site/about/team.html:158
+#: i2p2www/pages/site/about/team.html:163
+#: i2p2www/pages/site/about/team.html:168
+#: i2p2www/pages/site/about/team.html:201
+#: i2p2www/pages/site/about/team.html:219
+#: i2p2www/pages/site/get-involved/bounties/index.html:35
+#: i2p2www/pages/site/get-involved/bounties/index.html:42
+#: i2p2www/pages/site/get-involved/bounties/index.html:49
+#: i2p2www/pages/site/get-involved/bounties/index.html:56
+#: i2p2www/pages/site/get-involved/bounties/index.html:63
+#: i2p2www/pages/site/get-involved/bounties/index.html:70
+#: i2p2www/pages/site/get-involved/bounties/index.html:84
+#: i2p2www/pages/site/get-involved/bounties/index.html:97
+msgid "vacant"
+msgstr "vacante"
+
+#: i2p2www/pages/site/about/team.html:72
+msgid "threat model / crypto expert"
+msgstr "experto en modelos de amenazas / encifrados"
+
+#: i2p2www/pages/site/about/team.html:75
+msgid "User Advocate"
+msgstr "Defensor del usuario"
+
+#: i2p2www/pages/site/about/team.html:77
+msgid "gather, prioritize, advocate for user needs"
+msgstr "recogida, priorización y enfocado en las necesidades de los usuarios"
+
+#: i2p2www/pages/site/about/team.html:80
+msgid "Web Designer"
+msgstr "Diseñador web"
+
+#: i2p2www/pages/site/about/team.html:82
+msgid "manage the public project website content design"
+msgstr "administrar el diseño de la web del proyecto"
+
+#: i2p2www/pages/site/about/team.html:85
+#, python-format
+msgid "Webserver admin"
+msgstr "Administrador del servidor web"
+
+#: i2p2www/pages/site/about/team.html:87
+msgid "manage the public project webservers"
+msgstr "administrador de los servidores web públicos del proyecto"
+
+#: i2p2www/pages/site/about/team.html:90
+#, python-format
+msgid "Website admin"
+msgstr "Administrador de la página web"
+
+#: i2p2www/pages/site/about/team.html:92
+msgid "manage the public project website content"
+msgstr "administrador del contenido del la web de l proyecto"
+
+#: i2p2www/pages/site/about/team.html:95
+msgid "News Admin"
+msgstr "Aministrador de noticias"
+
+#: i2p2www/pages/site/about/team.html:97
+msgid "manage router console news feed"
+msgstr "administrador de las noticias de la consola del ruter"
+
+#: i2p2www/pages/site/about/team.html:100
+msgid "Director of passion"
+msgstr "Director de pasión"
+
+#: i2p2www/pages/site/about/team.html:102
+msgid "community motivator"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:106
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+msgid "Dev"
+msgstr "Desarrolladores"
+
+#: i2p2www/pages/site/about/team.html:107
+msgid "Core Lead"
+msgstr "Encargado del núcleo"
+
+#: i2p2www/pages/site/about/team.html:109
+msgid "lead dev for the SDK and router"
+msgstr "lider del SDK y del ruter"
+
+#: i2p2www/pages/site/about/team.html:112
+#, python-format
+msgid "I2P mail lead"
+msgstr "Encargado deI2P mail"
+
+#: i2p2www/pages/site/about/team.html:114
+msgid "organize and develop the i2p mail system"
+msgstr "organiza y desarrolla el istema de mail de I2P"
+
+#: i2p2www/pages/site/about/team.html:117
+#, python-format
+msgid "I2Host lead"
+msgstr "Encargado del I2Host"
+
+#: i2p2www/pages/site/about/team.html:119
+msgid "I2Host addressbook application"
+msgstr "aplicación de la lista de direcciones de I2Host"
+
+#: i2p2www/pages/site/about/team.html:122
+#, python-format
+msgid "BOB lead"
+msgstr "Encargado de BOB"
+
+#: i2p2www/pages/site/about/team.html:124
+msgid "Basic Open Bridge"
+msgstr "Basic Open Bridge"
+
+#: i2p2www/pages/site/about/team.html:127
+#, python-format
+msgid "I2P-Bote lead"
+msgstr "Encargado de I2P-Bote"
+
+#: i2p2www/pages/site/about/team.html:129
+msgid "I2PBote plugin"
+msgstr "pluguin I2PBote"
+
+#: i2p2www/pages/site/about/team.html:132
+#, python-format
+msgid "Robert lead"
+msgstr "Encargado de Robert"
+
+#: i2p2www/pages/site/about/team.html:134
+msgid "Robert BitTorrent client"
+msgstr "cliente de bittorrent Robert"
+
+#: i2p2www/pages/site/about/team.html:137
+#, python-format
+msgid "I2Phex lead"
+msgstr "Encargado de I2Phex "
+
+#: i2p2www/pages/site/about/team.html:139
+msgid "I2Phex Gnutella client"
+msgstr "clente de I2Phex Gnutella"
+
+#: i2p2www/pages/site/about/team.html:142
+#, python-format
+msgid "I2PSnark lead"
+msgstr "Encargado de I2PSnark"
+
+#: i2p2www/pages/site/about/team.html:144
+msgid "Maintains the integrated Bittorrent client"
+msgstr "Mantiene el cliente Bittorrent"
+
+#: i2p2www/pages/site/about/team.html:147
+#, python-format
+msgid "iMule lead"
+msgstr "Encargado de iMule"
+
+#: i2p2www/pages/site/about/team.html:149
+msgid "eMule client over I2P"
+msgstr "cliente e2dk sobre I2P"
+
+#: i2p2www/pages/site/about/team.html:152
+#, python-format
+msgid "Syndie lead"
+msgstr "Encargado de Syndie"
+
+#: i2p2www/pages/site/about/team.html:154
+#: i2p2www/pages/site/get-involved/bounties/syndie-2012.html:2
+#: i2p2www/pages/site/get-involved/bounties/syndie-2012.html:3
+msgid "Syndie development"
+msgstr "Desarrollode Syndie"
+
+#: i2p2www/pages/site/about/team.html:157
+msgid "Susimail lead"
+msgstr "Encargado de Susimail"
+
+#: i2p2www/pages/site/about/team.html:159
+msgid "Susimail development"
+msgstr "Desarrollo de Susimail"
+
+#: i2p2www/pages/site/about/team.html:162
+msgid "Console"
+msgstr "Consola"
+
+#: i2p2www/pages/site/about/team.html:164
+msgid "Router console HTML/CSS design"
+msgstr "Diseño del HTML/CSS de la consola del ruter"
+
+#: i2p2www/pages/site/about/team.html:167
+msgid "SAM"
+msgstr "SAM"
+
+#: i2p2www/pages/site/about/team.html:169
+msgid "SAM maintainer"
+msgstr "Encargado de SAM"
+
+#: i2p2www/pages/site/about/team.html:172
+msgid "Console Translations"
+msgstr "Traducciones de la Consola"
+
+#: i2p2www/pages/site/about/team.html:174
+msgid "Chinese"
+msgstr "Chino"
+
+#: i2p2www/pages/site/about/team.html:178
+msgid "Dutch"
+msgstr "Holandés"
+
+#: i2p2www/pages/site/about/team.html:182
+msgid "French"
+msgstr "Francés"
+
+#: i2p2www/pages/site/about/team.html:186
+msgid "German"
+msgstr "Aleman"
+
+#: i2p2www/pages/site/about/team.html:190
+msgid "Russian"
+msgstr "Ruso"
+
+#: i2p2www/pages/site/about/team.html:194
+msgid "Spanish"
+msgstr "Castellano"
+
+#: i2p2www/pages/site/about/team.html:198
+msgid "Arabic"
+msgstr "Árabe"
+
+#: i2p2www/pages/site/about/team.html:202
+msgid "Other languages"
+msgstr "Otros idiomas"
+
+#: i2p2www/pages/site/about/team.html:205
+msgid "Contributors"
+msgstr "Contribuidores"
+
+#: i2p2www/pages/site/about/team.html:207
+msgid "fire2pe dev, console enhancements"
+msgstr "Desarrollador de fire2pe, mejoras de la consola"
+
+#: i2p2www/pages/site/about/team.html:211
+msgid "desktopgui, dijjer port"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:215
+msgid "Debian/Ubuntu Packager and PPA maintainer"
+msgstr "Encargado de los paquetes para Debian/Ubuntu y del PPA"
+
+#: i2p2www/pages/site/about/team.html:220
+msgid "Help needed on many fronts!"
+msgstr "Se necesta diversas formas de ayuda"
+
+#: i2p2www/pages/site/about/team.html:224
+msgid "Past contributors"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:226
+msgid "I2PTunnel development, ministreaming library"
+msgstr "Desarrollo de I2PTunnel, librería de miniflujos"
+
+#: i2p2www/pages/site/about/team.html:230
+msgid "Project lead, Syndie lead"
+msgstr "Encargado del proyecto, encargado de Syndie"
+
+#: i2p2www/pages/site/about/team.html:234
+msgid "Project lead, Syndie lead, I2Phex, support guru"
+msgstr "Encargado del proyecto, encargado de Syndie, I2Phex, soporte"
+
+#: i2p2www/pages/site/about/team.html:238
+msgid "iMule lead"
+msgstr "Encargado de IMule"
+
+#: i2p2www/pages/site/about/team.html:242
+#: i2p2www/pages/site/about/team.html:246
+#: i2p2www/pages/site/about/team.html:250
+msgid "I2Phex work"
+msgstr "Trabajo en I2Phex"
+
+#: i2p2www/pages/site/about/team.html:254
+msgid "Python SAM library, attack simulations"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:258
+msgid "i2pmail development"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:262
+msgid "Syndie help"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:266
+msgid "i2p mail,susimail and susidns apps"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:270
+msgid "I2Phex (port of Phex to I2P)"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:274
+msgid "addressbook,i2p-bt,syndie client"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:278
+msgid "organize and develop the i2p-bt BitTorrent port"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:282
+msgid "addressbook, i2p-bt, syndie client development"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:286
+msgid "encryption and signature routines, I2PIM"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:290
+msgid "SAM jython code, work on stasher (DHT) and v2v (VoI2P)"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:294
+msgid "installer, systray, bogobot"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:298
+msgid "jbigi development, wiki migration, doc cleanup"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:302
+msgid "java debugging and client development on I2PTunnel and the router console"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:306
+msgid "SAM perl module"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:310
+msgid "i2psnark work"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:314
+msgid "java cleanup"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:318
+msgid "docs. wiki migration"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:322
+msgid "translations into French"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:326
+msgid "C port of jcpuid"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:330
+msgid "C# SAM library, pants, fortuna integration"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:334
+msgid "libSAM"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:338
+#: i2p2www/pages/site/about/team.html:342
+msgid "i2p-bt tracker development"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:346
+msgid "Console and website themes"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:349
+msgid "… and many others"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:2
+msgid "Future Performance Improvements"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:4
+#: i2p2www/pages/site/docs/api/bob.html:3
+#: i2p2www/pages/site/docs/api/datagrams.html:3
+#: i2p2www/pages/site/docs/how/garlic-routing.html:3
+#: i2p2www/pages/site/docs/protocol/i2np.html:3
+#: i2p2www/pages/site/docs/protocol/index.html:3
+#: i2p2www/pages/site/docs/spec/datagrams.html:3
+#: i2p2www/pages/site/docs/transport/ntcp.html:3
+msgid "August 2010"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:7
+msgid ""
+"There are a few major techniques that can be done to improve the "
+"perceived\n"
+"performance of I2P - some of the following are CPU related, others "
+"bandwidth\n"
+"related, and others still are protocol related.  However, all of those\n"
+"dimensions affect the latency, throughput, and perceived performance of "
+"the\n"
+"network, as they reduce contention for scarce resources.  This list is of"
+" course\n"
+"not comprehensive, but it does cover the major ones that are seen."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:15
+#: i2p2www/pages/site/about/performance/index.html:106
+#, python-format
+msgid ""
+"For past performance improvements see the \n"
+"Performance History."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:20
+msgid "Better peer profiling and selection"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:21
+#, python-format
+msgid ""
+"Probably one of the most important parts of getting faster performance "
+"will\n"
+"be improving how routers choose the peers that they build their tunnels "
+"through\n"
+"- making sure they don't use peers with slow links or ones with fast "
+"links that\n"
+"are overloaded, etc.  In addition, we've got to make sure we don't expose"
+"\n"
+"ourselves to a Sybil attack\n"
+"from a powerful adversary with lots of fast machines."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:30
+msgid "Network database tuning"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:31
+msgid ""
+"We're going to want to be more efficient with the network database's "
+"healing\n"
+"and maintenance algorithms - rather than constantly explore the keyspace "
+"for new\n"
+"peers - causing a significant number of network messages and router load "
+"- we\n"
+"can slow down or even stop exploring until we detect that there's "
+"something new\n"
+"worth finding (e.g. decay the exploration rate based upon the last time "
+"someone\n"
+"gave us a reference to someone we had never heard of).  We can also do "
+"some\n"
+"tuning on what we actually send - how many peers we bounce back (or even "
+"if we\n"
+"bounce back a reply), as well as how many concurrent searches we perform."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:42
+msgid "Session Tag Tuning and Improvements"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:43
+#, python-format
+msgid ""
+"The way the ElGamal/AES+SessionTag "
+"algorithm\n"
+"works is by managing a set of random one-time-use 32 byte arrays, and "
+"expiring\n"
+"them if they aren't used quickly enough.  If we expire them too soon, "
+"we're\n"
+"forced to fall back on a full (expensive) ElGamal encryption, but if we "
+"don't\n"
+"expire them quickly enough, we've got to reduce their quantity so that we"
+" don't\n"
+"run out of memory (and if the recipient somehow gets corrupted and loses "
+"some\n"
+"tags, even more encryption failures may occur prior to detection).  With "
+"some\n"
+"more active detection and feedback driven algorithms, we can safely and "
+"more\n"
+"efficiently tune the lifetime of the tags, replacing the ElGamal "
+"encryption with\n"
+"a trivial AES operation."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:55
+#, python-format
+msgid ""
+"Additional ideas for improving Session Tag delivery are described on the\n"
+"ElGamal/AES+SessionTag page."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:61
+msgid "Migrate sessionTag to synchronized PRNG"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:62
+#, python-format
+msgid ""
+"Right now, our ElGamal/AES+SessionTag \n"
+"algorithm works by tagging each encrypted message with a unique random \n"
+"32 byte nonce (a \"session tag\"), identifying that message as being "
+"encrypted \n"
+"with the associated AES session's key. This prevents peers from "
+"distinguishing \n"
+"messages that are part of the same session, since each message has a "
+"completely \n"
+"new random tag. To accomplish this, every few messages bundle a whole \n"
+"new set of session tags within the encrypted message itself, "
+"transparently \n"
+"delivering a way to identify future messages. We then have to keep track"
+" \n"
+"of what messages are successfully delivered so that we know what tags \n"
+"we may use."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:74
+msgid ""
+"This works fine and is fairly robust, however it is inefficient in terms"
+" \n"
+"of bandwidth usage, as it requires the delivery of these tags ahead of \n"
+"time (and not all tags may be necessary, or some may be wasted, due to \n"
+"their expiration). On average though, predelivering the session tag costs"
+" \n"
+"32 bytes per message (the size of a tag). As Taral suggested though, that"
+" \n"
+"size can be avoided by replacing the delivery of the tags with a "
+"synchronized \n"
+"PRNG - when a new session is established (through an ElGamal encrypted \n"
+"block), both sides seed a PRNG for use and generate the session tags on \n"
+"demand (with the recipient precalculating the next few possible values \n"
+"to handle out of order delivery)."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:87
+msgid "Longer lasting tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:88
+msgid ""
+"The current default tunnel duration of 10 minutes is fairly arbitrary, "
+"though\n"
+"it \"feels okay\".  Once we've got tunnel healing code and more effective"
+" failure\n"
+"detection, we'll be able to more safely vary those durations, reducing "
+"the\n"
+"network and CPU load (due to expensive tunnel creation messages)."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:95
+msgid ""
+"This appears to be an easy fix for high load on the big-bandwidth "
+"routers, but\n"
+"we should not resort to it until we've tuned the tunnel building "
+"algorithms further.\n"
+"However, the 10 minute tunnel lifetime is hardcoded in quite a few "
+"places,\n"
+"so substantial effort would be required to change the duration.\n"
+"Also, it would be difficult to maintain backward compatibility with such "
+"a change."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:102
+msgid ""
+"Currently, since the network average tunnel build success rate is fairly "
+"high,\n"
+"there are no current plans to extend tunnel lifetime."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:108
+msgid "Adjust the timeouts"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:109
+msgid ""
+"Yet another of the fairly arbitrary but \"okay feeling\" things we've got"
+" are the\n"
+"current timeouts for various activities.  Why do we have a 60 second "
+"\"peer\n"
+"unreachable\" timeout?  Why do we try sending through a different tunnel "
+"that a\n"
+"LeaseSet advertises after 10 seconds?  Why are the network database "
+"queries\n"
+"bounded by 60 or 20 second limits?  Why are destinations configured to "
+"ask for a\n"
+"new set of tunnels every 10 minutes?  Why do we allow 60 seconds for a "
+"peer to\n"
+"reply to our request that they join a tunnel?  Why do we consider a "
+"tunnel that\n"
+"doesn't pass our test within 60 seconds \"dead\"?"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:119
+msgid ""
+"Each of those imponderables can be addressed with more adaptive code, as "
+"well\n"
+"as tunable parameters to allow for more appropriate tradeoffs between\n"
+"bandwidth, latency, and CPU usage."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:125
+msgid "Full streaming protocol improvements"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:128
+msgid ""
+"Perhaps re-enable the interactive stream profile (the \n"
+"current implementation only uses the bulk stream profile)."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:134
+msgid ""
+"Client level bandwidth limiting (in either or both directions on a "
+"stream, \n"
+"or possibly shared across multiple streams). This would be in addition to"
+" \n"
+"the router's overall bandwidth limiting, of course."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:141
+msgid ""
+"Access control lists (only allowing streams to or from certain other "
+"known \n"
+"destinations)."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:147
+msgid ""
+"Web controls and monitoring the health of the various streams, as well \n"
+"as the ability to explicitly close or throttle them."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:153
+#, python-format
+msgid ""
+"Additional ideas for improving the streaming library are described on the"
+"\n"
+"streaming library page."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:2
+msgid "Performance History"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:4
+#, python-format
+msgid ""
+"Notable performance improvements have been made using the techniques "
+"below.\n"
+"There is more to do, see the Performance "
+"page\n"
+"for current issues and thoughts."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:10
+msgid "Native math"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:11
+#: i2p2www/pages/site/about/performance/history.html:67
+#: i2p2www/pages/site/about/performance/history.html:82
+#: i2p2www/pages/site/about/performance/history.html:105
+#: i2p2www/pages/site/about/performance/history.html:133
+msgid "implemented"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:12
+#, python-format
+msgid ""
+"When I last profiled the I2P code, the vast majority of time was spent "
+"within\n"
+"one function: java.math.BigInteger's\n"
+"modPow.\n"
+"Rather than try to tune this method, we'll call out to\n"
+"GNU MP - an insanely fast math library\n"
+"(with tuned assembler for many architectures). (Editor: see\n"
+"NativeBigInteger for faster public key "
+"cryptography)"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:23
+#, python-format
+msgid ""
+"\n"
+"ugha and duck are working on the C/JNI glue code, and the existing java "
+"code\n"
+"is already deployed with hooks for that whenever its ready.  Preliminary "
+"results\n"
+"look fantastic - running the router with the native GMP modPow is "
+"providing over\n"
+"a 800% speedup in encryption performance, and the load was cut in half.  "
+"This\n"
+"was just on one user's machine, and things are nowhere near ready for "
+"packaging\n"
+"and deployment, yet."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:32
+msgid "Garlic wrapping a \"reply\" LeaseSet"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:33
+msgid "implemented but needs tuning"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:34
+msgid ""
+"This algorithm tweak will only be relevant for applications that want "
+"their\n"
+"peers to reply to them (though that includes everything that uses "
+"I2PTunnel or\n"
+"mihi's ministreaming lib):"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:39
+msgid ""
+"Previously, when Alice sent Bob a message, when Bob replied he had to do "
+"a\n"
+"lookup in the network database - sending out a few requests to get "
+"Alice's\n"
+"current LeaseSet.  If he already has Alice's current LeaseSet, he can "
+"instead\n"
+"just send his reply immediately - this is (part of) why it typically "
+"takes a\n"
+"little longer talking to someone the first time you connect, but "
+"subsequent\n"
+"communication is faster.  Currently - for all clients - we wrap\n"
+"the sender's current LeaseSet in the garlic that is delivered to the "
+"recipient,\n"
+"so that when they go to reply, they'll always have the LeaseSet "
+"locally\n"
+"stored - completely removing any need for a network database lookup on "
+"replies.\n"
+"This trades off a large portion of the sender's bandwidth for that faster"
+" reply.\n"
+"If we didn't do this very often,\n"
+"overall network bandwidth usage would decrease, since the recipient "
+"doesn't\n"
+"have to do the network database lookup."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:54
+#, python-format
+msgid ""
+"For unpublished LeaseSets such as \"shared clients\", this is the only "
+"way to\n"
+"get the LeaseSet to Bob. Unfortunately this bundling every time adds\n"
+"almost 100% overhead to a high-bandwidth connection, and much more to\n"
+"a connection with smaller messages."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:60
+msgid ""
+"Changes scheduled for release 0.6.2 will bundle the LeaseSet only when\n"
+"necessary, at the beginning of a connection or when the LeaseSet changes."
+"\n"
+"This will substantially reduce the total overhead of I2P messaging."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:66
+msgid "More efficient TCP rejection"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:68
+msgid ""
+"At the moment, all TCP connections do all of their peer validation after\n"
+"going through the full (expensive) Diffie-Hellman handshaking to "
+"negotiate a\n"
+"private session key.  This means that if someone's clock is really wrong,"
+" or\n"
+"their NAT/firewall/etc is improperly configured (or they're just running "
+"an\n"
+"incompatible version of the router), they're going to consistently "
+"(though not\n"
+"constantly, thanks to the shitlist) cause a futile expensive "
+"cryptographic\n"
+"operation on all the peers they know about.  While we will want to keep "
+"some\n"
+"verification/validation within the encryption boundary, we'll want to "
+"update the\n"
+"protocol to do some of it first, so that we can reject them cleanly\n"
+"without wasting much CPU or other resources."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:81
+msgid "Adjust the tunnel testing"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:83
+msgid ""
+"Rather than going with the fairly random scheme we have now, we should "
+"use a\n"
+"more context aware algorithm for testing tunnels.  e.g. if we already "
+"know its\n"
+"passing valid data correctly, there's no need to test it, while if we "
+"haven't\n"
+"seen any data through it recently, perhaps its worthwhile to throw some "
+"data its\n"
+"way.  This will reduce the tunnel contention due to excess messages, as "
+"well as\n"
+"improve the speed at which we detect - and address - failing tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:92
+msgid "Persistent Tunnel / Lease Selection"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:93
+msgid ""
+"Outbound tunnel selection implemented in 0.6.1.30, inbound lease "
+"selection \n"
+"implemented in release 0.6.2."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:97
+msgid ""
+"Selecting tunnels and leases at random for every message creates a large"
+" \n"
+"incidence of out-of-order delivery, which prevents the streaming lib from"
+" \n"
+"increasing its window size as much as it could. By persisting with the \n"
+"same selections for a given connection, the transfer rate is much faster."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:104
+msgid "Compress some data structures"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:106
+msgid ""
+"The I2NP messages and the data they contain is already defined in a "
+"fairly\n"
+"compact structure, though one attribute of the RouterInfo structure is "
+"not -\n"
+"\"options\" is a plain ASCII name = value mapping.  Right now, we're "
+"filling it\n"
+"with those published statistics - around 3300 bytes per peer.  Trivial to"
+"\n"
+"implement GZip compression would nearly cut that to 1/3 its size, and "
+"when you\n"
+"consider how often RouterInfo structures are passed across the network, "
+"that's\n"
+"significant savings - every time a router asks another router for a "
+"networkDb\n"
+"entry that the peer doesn't have, it sends back 3-10 RouterInfo of them."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:117
+msgid "Update the ministreaming protocol"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:118
+msgid "replaced by full streaming protocol"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:119
+msgid ""
+"Currently mihi's ministreaming library has a fairly simple stream "
+"negotiation\n"
+"protocol - Alice sends Bob a SYN message, Bob replies with an ACK "
+"message, then\n"
+"Alice and Bob send each other some data, until one of them sends the "
+"other a\n"
+"CLOSE message.  For long lasting connections (to an IRC server, for "
+"instance),\n"
+"that overhead is negligible, but for simple one-off request/response "
+"situations\n"
+"(an HTTP request/reply, for instance), that's more than twice as many "
+"messages as\n"
+"necessary.  If, however, Alice piggybacked her first payload in with the "
+"SYN\n"
+"message, and Bob piggybacked his first reply with the ACK - and perhaps "
+"also\n"
+"included the CLOSE flag - transient streams such as HTTP requests could "
+"be\n"
+"reduced to a pair of messages, instead of the "
+"SYN+ACK+request+response+CLOSE."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:132
+msgid "Implement full streaming protocol"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:134
+msgid ""
+"The ministreaming protocol takes advantage of a poor design decision in "
+"the\n"
+"I2P client protocol (I2CP) - the exposure of \"mode=GUARANTEED\", "
+"allowing what\n"
+"would otherwise be an unreliable, best-effort, message based protocol to "
+"be used\n"
+"for reliable, blocking operation (under the covers, its still all "
+"unreliable and\n"
+"message based, with the router providing delivery guarantees by garlic "
+"wrapping\n"
+"an \"ACK\" message in with the payload, so once the data gets to the "
+"target, the\n"
+"ACK message is forwarded back to us [through tunnels, of course])."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:143
+#, python-format
+msgid ""
+"As I've said, having\n"
+"I2PTunnel (and the ministreaming lib) go this route was the best thing "
+"that\n"
+"could be done, but more efficient mechanisms are available.  When we rip "
+"out the\n"
+"\"mode=GUARANTEED\" functionality, we're essentially leaving ourselves "
+"with an\n"
+"I2CP that looks like an anonymous IP layer, and as such, we'll be able to"
+"\n"
+"implement the streaming library to take advantage of the design "
+"experiences of\n"
+"the TCP layer - selective ACKs, congestion detection, nagle, etc."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:5
+msgid ""
+"How does I2P work, why is it slow, and why does it not use my full "
+"bandwidth?"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:7
+msgid ""
+"Probably one of the most frequent things people ask is \"how fast is "
+"I2P?\",\n"
+"and no one seems to like the answer - \"it depends\".  After trying out "
+"I2P, the\n"
+"next thing they ask is \"will it get faster?\", and the answer to that is"
+" a most\n"
+"emphatic yes."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:14
+msgid ""
+"I2P is a full dynamic network. Each client is known to other nodes and "
+"tests local known nodes for reachability and capacity.\n"
+"Only reachable and capable nodes are saved to a local NetDB (This is "
+"generally only a portion of the network, around 500-1000).\n"
+"When I2P builds tunnels, it selects the best resource from this pool. For"
+" example, a small subset of 20-50 nodes are only available to build "
+"tunnels with.\n"
+"Because testing happens every minute, the pool of used nodes changes "
+"every minute.\n"
+"Each I2P node knows a different part of the net, meaning that each router"
+" has a different set of I2P nodes to be used for tunnels.\n"
+"Even if two routers have the same subset of known nodes, the tests for "
+"reachability and capacity will likely show different results, as the "
+"other routers could be under load just as one router tests, but be free "
+"if the second router tests."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:23
+msgid ""
+"The above describes why each I2P node has different nodes to build "
+"tunnels.\n"
+"Because every I2P node has a different latency and bandwith, tunnels "
+"(which are built via those nodes) have different latency and bandwidth "
+"values.\n"
+"And because every I2P node has different tunnels built, no two I2P nodes "
+"have the same tunnel sets."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:29
+msgid ""
+"A server/client is known as a \"destination\" and each destination has at"
+" least one inbound and one outbound tunnel. The default is 3 hops per "
+"tunnel.\n"
+"This adds up to 12 hops (aka 12 different I2P nodes) for a full roundtrip"
+" client-server-client."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:34
+msgid ""
+"Each data package is sent through 6 other I2P nodes until it reaches the "
+"server:"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:40
+msgid "and on way back 6 different I2P nodes:"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:47
+msgid ""
+"As most traffic on I2P (www, torrent,...) needs ack packages until new "
+"data is sent, it needs to wait until a ack package returns from the "
+"server.\n"
+"In the end: send data, wait for ack, send more data, wait for ack,..\n"
+"As the RTT (RoundTripTime) adds up from the latency of each individual "
+"I2P node and each connection on this roundtrip, it takes usually 1-3 "
+"seconds until a ack package comes back to the client.\n"
+"With some internals of TCP and I2P transport, a data package has a "
+"limited size and cannot be as large as we want it to be.\n"
+"Together these conditions set a limit of max bandwidth per tunnel of "
+"20-50 kbyte/sec.\n"
+"But if ONLY ONE hop in the tunnel has only 5 kb/sec bandwidth to spend, "
+"the whole tunnel is limited to 5 kb/sec, independent of the \n"
+"latency and other limitations."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:57
+msgid ""
+"Due to encryption used and other setups in I2P (howto built up tunnels, "
+"latency, ...) it is quite expensive in CPU time to build a tunnel. This "
+"is \n"
+"why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels"
+" to transport data. With a max of 50 kb/sec per tunnel, a destination "
+"could \n"
+"use roughly 300 kb/sec traffic combined ( in reality it could be more if "
+"shorter tunnels are used with low or no anonymity available).\n"
+"Used tunnels are discarded every 10 minutes and new ones are built up.\n"
+"This change of tunnels (and sometimes clients that shutdown hard due to "
+"usage of \"shut down at once\" or situations where there is power loss) "
+"does \n"
+"sometimes break tunnels and connections, as seen on the IRC2P Network in "
+"loss of connection (ping timeout) or on when using eepget."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:66
+msgid ""
+"With a limited set of destinations and a limited set of tunnels per "
+"destination, one I2P node only uses a limited set of tunnels across other"
+" I2P nodes.\n"
+"For example, if an I2P node is \"hop1\" in the small example above, we "
+"only see 1 participating tunnel originating from the client.\n"
+"If we sum up the whole I2P network, only a rather limited number of "
+"participating tunnels could be built with a limited amount of bandwidth "
+"all together.\n"
+"If one distributes these limited numbers across the number of I2P nodes, "
+"there is only a fraction of available bandwidth/capacity available for "
+"use."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:73
+msgid ""
+"To remain anonymous one router should not be used by the whole network "
+"for building tunnels.\n"
+"If one router does act as a tunnel router for ALL I2P nodes, it becomes a"
+" very real central point of failure as well as a central point to grab "
+"IPs and data from the clients. This is not good.\n"
+"I2P attempts to spread the load across a lot of I2P nodes because of this"
+" reason."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:79
+msgid ""
+"Another point is the full mesh network. Each connection hop-hop utilizes "
+"one TCP or UDP connection on the I2P nodes. With 1000 connections, one "
+"sees \n"
+"1000 TCP connections. That is quite a lot and some home and small office "
+"routers (DSL, cable,..) only allow a small number of connections (or just"
+" go mad if you use more than X connections).\n"
+"I2P tries to limit these connections to be under 1500 per UDP and per TCP"
+" type.\n"
+"This limits the amount of traffic routed across your I2P node as well."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:86
+msgid ""
+"In summary, I2P is very complex and there is no easy way to pinpoint why "
+"your node is not used.\n"
+"If your node is reachable and has a bandwidth setting of >128 kbyte/sec "
+"shared and is reachable 24/7, it should be used after some time for "
+"participating traffic.\n"
+"If it is down in between, the testing of your I2P node done by other "
+"nodes will tell them: you are not reachable. This blocks your node for at"
+" least \n"
+"24h on other nodes. So, the other nodes which tested you as down will not"
+" use your node for 24h for building tunnels. This is why your traffic "
+"will \n"
+"be lower after a restart/shutdown for a minimum of 24h."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:94
+msgid ""
+"Also: other I2P nodes needs to know your I2P router to test it for "
+"reachability and capacity. It takes time for other nodes to get known to "
+"your node. \n"
+"It will be faster if you use I2P and build more tunnels, e.g. use a "
+"torrent or www for some time."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:99
+msgid "Performance Improvements"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:101
+#, python-format
+msgid ""
+"For possible future performance improvements see\n"
+"Future Performance Improvements."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/freenet.html:2
+msgid "I2P Compared to Freenet"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/freenet.html:8
+msgid ""
+"Freenet is a fully distributed, peer to peer anonymous publishing "
+"network, offering \n"
+"secure ways to store data, as well as some approaches attempting to "
+"address the loads\n"
+"of a flash flood.  While Freenet is designed as a distributed data store,"
+" people have\n"
+"built applications on top of it to do more generic anonymous "
+"communication, such as \n"
+"static websites and message boards."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/freenet.html:16
+#, python-format
+msgid ""
+"Compared to I2P, Freenet offers some substantial benefits - it is a "
+"distributed data\n"
+"store, while I2P is not, allowing people to retrieve the content "
+"published by others \n"
+"even when the publisher is no longer online.  In addition, it should be "
+"able to \n"
+"distribute popular data fairly efficiently.  I2P itself does not and will"
+" not provide \n"
+"this functionality.  On the other hand, there is overlap for users who "
+"simply want to \n"
+"communicate with each other anonymously through websites, message boards,"
+" file sharing\n"
+"programs, etc.  There have also been some attempts to develop a "
+"distributed data \n"
+"store to run on top of I2P,\n"
+"(most recently a port of Tahoe-LAFS)\n"
+"but nothing is yet ready for general use."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/freenet.html:29
+msgid ""
+"However, even ignoring any implementations issues, there are some "
+"concerns \n"
+"about Freenet's algorithms from both a scalability and anonymity "
+"perspective, owing \n"
+"largely to Freenet's heuristic driven routing.  The interactions of "
+"various techniques \n"
+"certainly may successfully deter various attacks, and perhaps some "
+"aspects of the \n"
+"routing algorithms will provide the hoped for scalability.  "
+"Unfortunately, not much\n"
+"analysis of the algorithms involved has resulted in positive results, but"
+" there is still\n"
+"hope.  At the very least, Freenet does provide substantial anonymity "
+"against an attacker\n"
+"who does not have the resources necessary to analyze it further."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/index.html:2
+msgid "Comparing I2P to other projects"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/index.html:4
+msgid ""
+"There are a great many other applications and projects working on "
+"anonymous \n"
+"communication and I2P has been inspired by much of their efforts.  This "
+"is not \n"
+"a comprehensive list of anonymity resources - both freehaven's \n"
+"Anonymity "
+"Bibliography\n"
+"and GNUnet's related "
+"projects\n"
+"serve that purpose well.  That said, a few systems stand out for further\n"
+"comparison. The following have individual comparison pages:"
+msgstr ""
+"Hay muchas otras aplicaciones y proyectos trabajando en comunicaciones\n"
+"anónimas e I2P se ha inspirado en muchos de sus esfuerzos. Esto no es una \n"
+"lista completa de recursos para el anonimato - ambos \n"
+"Anonymity Bibliography\n"
+"y los proyectos relacionados con \n"
+"GNUnet sirven también para ese mismo propósito. Dicho eso, pocos proyectos \n"
+"destacan como para comparaciones adicionals. Los siguientes proyectos \n"
+"tienen webs con comparaciones individuales:"
+
+#: i2p2www/pages/site/comparison/index.html:20
+#, python-format
+msgid ""
+"The following are discussed on the other "
+"networks page:"
+msgstr "Los siguentes son discutidos en la página sobre otras redes:"
+
+#: i2p2www/pages/site/comparison/index.html:32
+#, python-format
+msgid ""
+"The content of this page is subject to update, discussion and dispute, "
+"and we welcome comments and additions.\n"
+"You may contribute an analysis by entering a new ticket on Trac."
+msgstr ""
+"El contenido de esta página puede ser objeto de actualizaciones, discusion y disputa, y aprobamos comentarios y \n"
+"adiciones. Puede contribuir al análisis creando una nueva entrada en el Trac."
+
+#: i2p2www/pages/site/comparison/other-networks.html:2
+msgid "I2P Compared to Other Anonymous Networks"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:5
+msgid "The following networks are discussed on this page."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:16
+#, python-format
+msgid ""
+"Most of the following sections are fairly old, and may not be accurate.\n"
+"For an overview of available comparisons, see the\n"
+"main network comparisons page.\n"
+"You may contribute an analysis by entering a\n"
+"new ticket on %(trac)s."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:29
+#, python-format
+msgid ""
+"Morphmix and Tarzan are both fully distributed, peer to peer networks of"
+" \n"
+"anonymizing proxies, allowing people to tunnel out through the low "
+"latency \n"
+"mix network.  Morphmix includes some very interesting collusion detection"
+" \n"
+"algorithms and Sybil defenses, while Tarzan makes use of the scarcity of "
+"IP\n"
+"addresses to accomplish the same.  The two primary differences between \n"
+"these systems and I2P are related to I2P's threat model \n"
+"and their out-proxy design (as opposed to providing both sender and "
+"receiver \n"
+"anonymity).  There is source code available to both systems, but we are "
+"not aware \n"
+"of their use outside of academic environments."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:153
+msgid ""
+"\n"
+"Mixminion and Mixmaster are networks to support anonymous email against a"
+" very\n"
+"powerful adversary.\n"
+"High-latency messaging applications running on top of I2P\n"
+"(for example\n"
+"Syndie or\n"
+"I2PBote)\n"
+"may perhaps prove adequate to meet the threat\n"
+"model of those adversaries, while running in parallel along side the "
+"needs of low latency users, to provide\n"
+"a significantly larger anonymity set.\n"
+"High-latency support within the I2P router itself may or may not be added"
+" in a distant future release.\n"
+"It is too early to say if I2P will meet the needs of users requiring "
+"extreme protection for email."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:167
+msgid ""
+"As with Tor and Onion Routing, \n"
+"both Mixminion and Mixmaster take the directory based approach as well."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:177
+#, python-format
+msgid ""
+"JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing "
+"web requests,\n"
+"and as such it has a few centralized nodes (participants in the cascade) "
+"that blend\n"
+"and mix requests from clients through the sequence of nodes (the cascade)"
+" before \n"
+"proxying out onto the web.  The scope, threat model, and security is "
+"substantially \n"
+"different from I2P, but for those who don't require significant anonymity"
+" but still\n"
+"are not satisfied with an Anonymizer-like service, JAP is worth "
+"reviewing.  One\n"
+"caution to note is that anyone under the jurisdiction of the German "
+"courts may want\n"
+"to take care, as the German Federal Bureau of Criminal Investigation "
+"(FBCI) has \n"
+"successfully mounted an \n"
+"attack \n"
+"on the network.  Even though the method of this attack was later found to"
+" be illegal \n"
+"in the German courts, the fact that the data was successfully collected "
+"is the \n"
+"concern.  Courts change their minds based upon circumstance, and this is "
+"evidence that \n"
+"if a government body or intelligence agency wanted to, they could gather "
+"the data, even \n"
+"if it may be found inadmissible in some courts later)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:199
+#, python-format
+msgid ""
+"Both of these systems work through the same basic \n"
+"antnet routing, providing some degree of\n"
+"anonymity based on the threat model of providing plausible deniability "
+"against a simple \n"
+"non-colluding adversary.  With the antnet routing, they first either do a"
+" random walk or a \n"
+"broadcast search to find some peer with the data or identity desired, and"
+" then use a feedback\n"
+"algorithm to optimize that found path.  This works well for applications "
+"that merely want to know \n"
+"what other people around them have to offer - \"How are y'all doing\" vs."
+" \"Hey Alice, how are you\" - \n"
+"you basically get a local cluster of nodes that can share files with and "
+"maintain some degree of \n"
+"anonymity (though you don't have much control over who is in that group "
+"of peers)."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:211
+msgid ""
+"However, the algorithm does not scale well at all - if the application "
+"wants to speak with a \n"
+"particular peer it ends up doing a broadcast search or random walk "
+"(though if they are lucky enough\n"
+"for that to succeed, the antnet routing should optimize that found "
+"connection).  This means that \n"
+"while these networks can work great at small scales, they are not "
+"suitable for large networks where\n"
+"someone wants to get in touch with another specific peer.  That does not "
+"mean that there is no \n"
+"value in these systems, just that their applicability is limited to "
+"situations where their \n"
+"particular issues can be addressed."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:222
+#, python-format
+msgid ""
+"This was a closed-source network targeted at Iranian users.\n"
+"Tor did a\n"
+"good writeup on what to look for in a circumvention tool.\n"
+"Suffice it to say that being closed source and publicly targeting a "
+"specific country are not good ideas.\n"
+"I2P is, of course, open source. However, that source, and our\n"
+"technical documentation, need much more review."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:231
+msgid "Paid VPN Services"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:232
+#: i2p2www/pages/site/comparison/other-networks.html:238
+#, python-format
+msgid ""
+"You may contribute an analysis by entering a\n"
+"new ticket on %(trac)s."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:237
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:14
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:169
+msgid "Others"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:2
+msgid "I2P Compared to Tor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:8
+#, python-format
+msgid ""
+"Tor and Onion Routing are both anonymizing proxy networks, \n"
+"allowing people to tunnel out through their low latency mix \n"
+"network. The two primary differences between Tor / \n"
+"Onion-Routing and I2P are again related to differences in \n"
+"the threat model and the out-proxy design (though Tor\n"
+"supports hidden services as well).  In addition, Tor\n"
+"takes the directory-based approach - providing a \n"
+"centralized point to manage the overall 'view' of the \n"
+"network, as well as gather and report statistics, as \n"
+"opposed to I2P's distributed network \n"
+"database and peer selection."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:22
+msgid ""
+"The I2P/Tor outproxy functionality does have a few \n"
+"substantial weaknesses against certain attackers - \n"
+"once the communication leaves the mixnet, global passive\n"
+"adversaries can more easily mount traffic analysis.  In \n"
+"addition, the outproxies have access to the cleartext \n"
+"of the data transferred in both directions, and \n"
+"outproxies are prone to abuse, along with all of the \n"
+"other security issues we've come to know and love with \n"
+"normal Internet traffic."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:34
+msgid ""
+"However, many people don't need to worry about those \n"
+"situations, as they are outside their threat model.  It\n"
+"is, also, outside I2P's (formal) functional scope (if people want\n"
+"to build outproxy functionality on top of an anonymous\n"
+"communication layer, they can).  In fact, some I2P users\n"
+"currently take advantage of Tor to outproxy."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:48
+msgid "Comparison of Tor and I2P Terminology"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:49
+msgid ""
+"While Tor and I2P are similar in many ways, much of the terminology is "
+"different."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:54
+msgid "Cell"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:54
+#: i2p2www/pages/site/docs/protocol/i2np.html:96
+msgid "Message"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:55
+msgid "Client"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:55
+msgid "Router or Client"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:56
+msgid "Circuit"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:56
+msgid "Tunnel"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:57
+msgid "Directory"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:57
+msgid "NetDb"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:58
+msgid "Directory Server"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:58
+msgid "Floodfill Router"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:59
+msgid "Entry Guards"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:59
+msgid "Fast Peers"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:60
+msgid "Entry Node"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:60
+msgid "Inproxy"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:61
+msgid "Exit Node"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:61
+msgid "Outproxy"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:62
+msgid "Hidden Service"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:62
+msgid "Eepsite or Destination"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:63
+msgid "Hidden Service Descriptor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:63
+msgid "LeaseSet"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:64
+msgid "Introduction point"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:64
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:30
+#: i2p2www/pages/site/docs/tunnels/implementation.html:140
+msgid "Inbound Gateway"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:65
+msgid "Node"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:65
+#: i2p2www/pages/site/comparison/tor.html:67
+#: i2p2www/pages/site/comparison/tor.html:70
+#: i2p2www/pages/site/docs/spec/configuration.html:70
+msgid "Router"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:66
+msgid "Onion Proxy"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:66
+msgid "I2PTunnel Client (more or less)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:67
+msgid "Relay"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:68
+msgid "Rendezvous Point"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:68
+msgid "somewhat like Inbound Gateway + Outbound Endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:69
+msgid "Router Descriptor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:69
+msgid "RouterInfo"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:70
+msgid "Server"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:73
+msgid "Benefits of Tor over I2P"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:76
+msgid ""
+"Much bigger user base; much more visibility in the academic and hacker "
+"communities; benefits from\n"
+"formal studies of anonymity, resistance, and performance;\n"
+"has a non-anonymous, visible, university-based leader"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:82
+msgid "Has already solved some scaling issues I2P has yet to address"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:83
+msgid "Has significant funding"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:84
+msgid "Has more developers, including several that are funded"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:86
+msgid ""
+"More resistant to state-level blocking due to TLS transport layer and "
+"bridges\n"
+"(I2P has proposals for \"full restricted routes\" but these are not yet "
+"implemented)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:91
+msgid "Big enough that it has had to adapt to blocking and DOS attempts"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:92
+msgid "Designed and optimized for exit traffic, with a large number of exit nodes"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:94
+msgid ""
+"Better documentation, has formal papers and specifications,\n"
+"better website, many more translations"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:99
+msgid "More efficient with memory usage"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:100
+msgid "Tor client nodes have very low bandwidth overhead"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:102
+msgid ""
+"Centralized control reduces the complexity at each\n"
+"node and can efficiently address Sybil attacks"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:108
+msgid ""
+"A core of high capacity nodes provides higher\n"
+"throughput and lower latency"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:113
+msgid "C, not Java (ewww)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:116
+msgid "Benefits of I2P over Tor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:118
+msgid ""
+"Designed and optimized for hidden services, which are much faster than in"
+" Tor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:119
+msgid "Fully distributed and self organizing"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:121
+msgid ""
+"Peers are selected by continuously profiling and ranking performance,\n"
+"rather than trusting claimed capacity"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:127
+msgid ""
+"Floodfill peers (\"directory servers\") are varying and untrusted,\n"
+"rather than hardcoded"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:132
+msgid "Small enough that it hasn't been blocked or DOSed much, or at all"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:133
+msgid "Peer-to-peer friendly"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:134
+msgid "Packet switched instead of circuit switched"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:137
+msgid ""
+"implicit transparent load balancing of messages \n"
+"across multiple peers, rather than a single path"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:143
+msgid ""
+"resilience vs. failures by running multiple \n"
+"tunnels in parallel, plus rotating tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:149
+msgid ""
+"scale each client's connections at O(1) instead \n"
+"of O(N) (Alice has e.g. 2 inbound tunnels that are \n"
+"used by all of the peers Alice is talking with, \n"
+"rather than a circuit for each)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:159
+msgid ""
+"Unidirectional tunnels instead of bidirectional\n"
+"circuits, doubling the number of nodes a peer has to\n"
+"compromise to get the same information."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:166
+msgid ""
+"Protection against detecting client activity, even\n"
+"when an attacker is participating in the tunnel, as\n"
+"tunnels are used for more than simply passing end \n"
+"to end messages (e.g. netDb, tunnel management, \n"
+"tunnel testing)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:175
+msgid ""
+"Tunnels in I2P are short lived, decreasing the number\n"
+"of samples that an attacker can use to mount an \n"
+"active attack with, unlike circuits in Tor, which are\n"
+"typically long lived."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:183
+msgid ""
+"I2P APIs are designed specifically for anonymity and\n"
+"security, while SOCKS is designed for functionality."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:188
+msgid "Essentially all peers participate in routing for others"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:190
+msgid ""
+"The bandwidth overhead of being a full peer is low, \n"
+"while in Tor, while client nodes don't require much\n"
+"bandwidth, they don't fully participate in the mixnet."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:196
+msgid "Integrated automatic update mechanism"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:197
+msgid "Both TCP and UDP transports"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:198
+msgid "Java, not C (ewww)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:201
+msgid "Other potential benefits of I2P but not yet implemented"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:202
+msgid "...and may never be implemented, so don't count on them!"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:205
+msgid ""
+"Defense vs. message count analysis by garlic wrapping \n"
+"multiple messages"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:211
+msgid ""
+"Defense vs. long term intersection by adding delays \n"
+"at various hops (where the delays are not discernible\n"
+"by other hops)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:218
+msgid ""
+"Various mixing strategies at the tunnel level (e.g.\n"
+"create a tunnel that will handle 500 messages / minute,\n"
+"where the endpoint will inject dummy messages if there\n"
+"are insufficient messages, etc)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:2 i2p2www/pages/site/docs/index.html:25
+msgid "Index to Technical Documentation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:3 i2p2www/pages/site/docs/ports.html:3
+msgid "May 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:6
+msgid "How does I2P work"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:8
+msgid "Following is an index to the technical documentation for I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:12
+msgid ""
+"This index is ordered from the highest to lowest layers.\n"
+"The higher layers are for \"clients\" or applications;\n"
+"the lower layers are inside the router itself.\n"
+"The interface between applications and the router is the I2CP (I2P "
+"Control Protocol) API."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:19
+#, python-format
+msgid ""
+"The I2P Project is committed to maintaining accurate, current "
+"documentation.\n"
+"If you find any inaccuracies in the documents linked below, please\n"
+"enter a ticket identifying the "
+"problem."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:27 i2p2www/pages/site/docs/naming.html:7
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:12
+#: i2p2www/pages/site/docs/api/streaming.html:6
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:6
+#: i2p2www/pages/site/docs/how/network-database.html:6
+#: i2p2www/pages/site/docs/how/peer-selection.html:6
+#: i2p2www/pages/site/docs/how/tech-intro.html:13
+#: i2p2www/pages/site/docs/how/tech-intro.html:97
+#: i2p2www/pages/site/docs/spec/blockfile.html:7
+#: i2p2www/pages/site/docs/spec/configuration.html:6
+#: i2p2www/pages/site/docs/spec/updates.html:6
+#: i2p2www/pages/site/docs/tunnels/implementation.html:67
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:6
+#: i2p2www/pages/site/misc/jbigi.html:6
+msgid "Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:29
+msgid "Technical Introduction"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:30
+#, fuzzy
+msgid "A Less-Technical Introduction"
+msgstr "Una Introducción Sencilla"
+
+#: i2p2www/pages/site/docs/index.html:31
+msgid "Threat model and analysis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:32
+msgid "Comparisons to other anonymous networks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:33
+msgid "Protocol stack chart"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:34
+#: i2p2www/pages/site/research/papers.html:2
+#: i2p2www/pages/site/research/papers.html:4
+msgid "Papers on I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:35
+#, python-format
+msgid ""
+"Invisible Internet Project (I2P) Project Overview"
+" August 28, 2003 (pdf)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:38
+msgid "Application-Layer Topics"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:40 i2p2www/pages/site/docs/naming.html:2
+msgid "Naming and Addressbook"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:41
+msgid "Plugins Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:42
+msgid "Plugin Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:43
+msgid "Router software updates"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:44
+#: i2p2www/pages/site/docs/applications/bittorrent.html:2
+msgid "Bittorrent over I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:45
+msgid "I2PControl Plugin API"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:46
+msgid "hostsdb.blockfile Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:47 i2p2www/pages/site/docs/index.html:184
+msgid "Configuration File Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:50
+msgid "Application Layer API and Protocols"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:51
+msgid ""
+"High-level, easy-to-use APIs for applications written in any language to "
+"send and receive data."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:53
+msgid "Application Development Overview and Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:71
+msgid "SAM Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:73
+msgid "SAMv2 Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:75
+msgid "SAMv3 Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:77
+msgid "BOB Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:80
+msgid "End-to-End Transport API and Protocols"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:81
+msgid ""
+"The end-to-end protocols used by clients for reliable and unreliable "
+"communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:83
+#: i2p2www/pages/site/docs/api/streaming.html:2
+msgid "Streaming Library"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:85
+msgid "Streaming Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:89
+msgid "Datagram Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:92
+msgid "Client-to-Router Interface API and Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:93
+msgid ""
+"The lowest-level API used for clients (applications) to send and receive "
+"traffic to a router.\n"
+"Traditionally used only by Java applications and higher-level APIs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:98
+msgid "I2CP - I2P Control Protocol / API overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:100
+msgid "I2CP Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:102
+msgid "I2CP API Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:104
+#: i2p2www/pages/site/docs/index.html:133
+msgid "Common data structures specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:106
+#: i2p2www/pages/site/docs/index.html:135
+msgid "Data Structures Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:109
+msgid "End-to-End Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:110
+msgid "How client messages are end-to-end encrypted by the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:112
+msgid "ElGamal/AES+SessionTag encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:113
+#: i2p2www/pages/site/docs/index.html:146
+msgid "ElGamal and AES cryptography details"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:116
+#: i2p2www/pages/site/docs/how/tech-intro.html:15
+#: i2p2www/pages/site/docs/how/tech-intro.html:329
+msgid "Network Database"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:117
+msgid ""
+"Distributed storage and retrieval of information about routers and "
+"clients."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:119
+msgid "Network database overview, details, and threat analysis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:120
+msgid "Cryptographic hashes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:121
+msgid "Cryptographic signatures"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:124
+msgid "Router Message Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:125
+msgid ""
+"I2P is a message-oriented router. The messages sent between routers are "
+"defined by the I2NP protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:127
+msgid "I2NP - I2P Network Protocol Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:129
+msgid "I2NP Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:131
+msgid "I2NP Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:139
+msgid ""
+"Selecting peers, requesting tunnels through those peers, and encrypting "
+"and routing messages through these tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:141
+msgid "Peer profiling and selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:142
+msgid "Tunnel routing overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:143
+msgid "Garlic routing and \"garlic\" terminology"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:144
+msgid "Tunnel building and encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:145
+msgid "ElGamal/AES"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:145
+msgid "for build request encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:147
+msgid "Tunnel building specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:148
+msgid "Low-level tunnel message specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:149
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:2
+msgid "Unidirectional Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:150
+#: i2p2www/pages/site/docs/how/peer-selection.html:299
+msgid "Peer Profiling and Selection in the I2P Anonymous Network"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:151
+msgid "2009 paper (pdf), not current but still generally accurate"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:154
+msgid "Transport Layer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:155
+msgid "The protocols for direct (point-to-point) router to router communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:159
+msgid "TCP-based transport overview and specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:161
+msgid "UDP-based transport overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:163
+msgid "SSU specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:165
+msgid "NTCP transport encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:167
+msgid "SSU transport encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:169
+msgid "Transport Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:171
+msgid "NTCP Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:173
+msgid "SSU Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:176
+msgid "Other Router Topics"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:178
+msgid "Native BigInteger Library"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:180
+msgid "Time synchronization and NTP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:187
+msgid "Developer's Guides and Resources"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:189
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:2
+msgid "New Developer's Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:191
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:2
+msgid "New Translator's Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:193
+#: i2p2www/pages/site/get-involved/guides/monotone.html:4
+msgid "Monotone Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:195
+msgid "Developer Guidelines"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:197
+msgid "Javadocs on the standard internet:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:198
+#: i2p2www/pages/site/docs/index.html:202
+#: i2p2www/pages/site/docs/index.html:203
+#: i2p2www/pages/site/docs/index.html:204
+#, python-format
+msgid "Server %(num)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:199
+#: i2p2www/pages/site/docs/index.html:208
+msgid ""
+"Note: always verify that javadocs are current by checking the release "
+"number."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:201
+msgid "Javadocs inside I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:210
+msgid "Ports used by I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:212
+msgid "Automatic updates to development builds inside I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:214
+msgid "Updating the wrapper manually"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:216
+msgid "User forum"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:218
+msgid "Developer forum inside I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:222
+msgid "Viewmtn inside I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:224
+msgid "I2P Source exported to GitHub"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:226
+msgid "I2P Source Git Repo inside I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:228
+msgid "Source translation at Transifex"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:230
+msgid "Roadmap wiki"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:232
+msgid "Old roadmap"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:232
+#: i2p2www/pages/site/docs/index.html:234
+msgid "not current"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:234
+#: i2p2www/pages/site/get-involved/todo.html:2
+msgid "To Do List"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:3
+#: i2p2www/pages/site/docs/how/cryptography.html:3
+#: i2p2www/pages/site/docs/spec/common-structures.html:3
+msgid "March 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:6
+msgid "Naming in I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:9
+msgid ""
+"I2P ships with a generic naming library and a base implementation \n"
+"designed to work off a local name to destination mapping, as well as an\n"
+"add-on application called the addressbook. \n"
+"I2P also supports Base32 hostnames similar to "
+"Tor's .onion addresses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:16
+msgid ""
+"The addressbook is a web-of-trust\n"
+"driven secure, distributed, and human readable naming system, sacrificing"
+" only\n"
+"the call for all human readable names to be globally unique by mandating "
+"only\n"
+"local uniqueness.  While all messages in I2P are cryptographically "
+"addressed\n"
+"by their destination, different people can have local addressbook entries"
+" for\n"
+"\"Alice\" which refer to different destinations.  People can still "
+"discover new\n"
+"names by importing published addressbooks of peers specified in their web"
+" of trust,\n"
+"by adding in the entries provided through a third party, or (if some "
+"people organize\n"
+"a series of published addressbooks using a first come first serve "
+"registration\n"
+"system) people can choose to treat these addressbooks as name servers, "
+"emulating\n"
+"traditional DNS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:30
+#, python-format
+msgid ""
+"NOTE: For the reasoning behind the I2P naming system, common arguments "
+"against it\n"
+"and possible alternatives see the naming"
+" discussion\n"
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:37
+msgid "Naming System Components"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:39
+msgid ""
+"There is no central naming authority in I2P.\n"
+"All hostnames are local."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:44
+msgid ""
+"The naming system is quite simple and most of it is implemented\n"
+"in applications external to the router, but bundled with\n"
+"the I2P distribution.\n"
+"The components are:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:52
+msgid ""
+"The client application which does local lookups "
+"in hosts.txt\n"
+"and also takes care of the Base32 hostnames."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:56
+msgid ""
+"The HTTP proxy which asks the router for "
+"lookups and points\n"
+"the user to remote jump services to assist with failed lookups."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:60
+msgid ""
+"HTTP host-add forms which allow users to "
+"add hosts to their local hosts.txt"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:63
+msgid ""
+"HTTP jump services which provide their own"
+" lookups and redirection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:66
+msgid ""
+"The addressbook application which merges "
+"external\n"
+"host lists, retrieved via HTTP, with the local list."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:70
+msgid ""
+"The SusiDNS application which is a simple web "
+"front-end\n"
+"for addressbook configuration and viewing of the local host lists."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:77
+msgid "Naming Files and Lookups"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:79
+#, python-format
+msgid ""
+"All destinations in I2P are 516-byte (or longer) keys.\n"
+"(To be more precise, it is a 256-byte public key plus a 128-byte signing "
+"key\n"
+"plus a null certificate, which in Base64 representation is 516 bytes.\n"
+"Certificates are not "
+"used now,\n"
+"if they are, the keys will be longer.\n"
+"One possible use of certificates is for proof of work.)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:88
+msgid ""
+"If an application (i2ptunnel or the HTTP proxy) wishes to access\n"
+"a destination by name, the router does a very simple local lookup\n"
+"to resolve that name.\n"
+"The client application (technically, the client side of I2CP in the I2P "
+"API)\n"
+"does a linear search through three local files, in order, to\n"
+"look up host names and convert them to a 516-byte destination key:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:103
+msgid ""
+"The lookup is case-insensitive.\n"
+"The first match is used, and conflicts are not detected.\n"
+"There is no enforcement of naming rules in lookups."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:109
+#, python-format
+msgid ""
+"Lookups are cached for a few minutes.\n"
+"There is an experimental facility for real-time lookups (a la DNS) over "
+"the network within the router,\n"
+"although it is not enabled by default\n"
+"(see \"EepGet\" under Alternatives on the discussion"
+" page)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:116
+msgid "HTTP Proxy"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:118
+msgid ""
+"The HTTP proxy does a lookup via the router for all hostnames ending in "
+"'.i2p'.\n"
+"Otherwise, it forwards the request to a configured HTTP outproxy.\n"
+"Thus, in practice, all HTTP (eepsite) hostnames must end in the pseudo-"
+"Top Level Domain '.i2p'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:124
+msgid ""
+"If the router fails to resolve the hostname, the HTTP proxy returns\n"
+"an error page to the user with links to several \"jump\" services.\n"
+"See below for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:130
+#: i2p2www/pages/site/docs/spec/configuration.html:77
+msgid "Addressbook"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:131
+msgid "Incoming Subscriptions and Merging"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:133
+msgid ""
+"The addressbook application periodically\n"
+"retrieves other users' hosts.txt files and merges\n"
+"them with the local hosts.txt, after several checks.\n"
+"Naming conflicts are resolved on a first-come first-served\n"
+"basis."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:141
+msgid ""
+"Subscribing to another user's hosts.txt file involves\n"
+"giving them a certain amount of trust.\n"
+"You do not want them, for example, 'hijacking' a new site\n"
+"by quickly entering in their own key for a new site before\n"
+"passing the new host/key entry to you."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:149
+msgid ""
+"For this reason, the only subscription configured by\n"
+"default is http://www.i2p2.i2p/hosts.txt,\n"
+"which contains a copy of the hosts.txt included\n"
+"in the I2P release.\n"
+"Users must configure additional subscriptions in their\n"
+"local addressbook application (via subscriptions.txt or SusiDNS)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:158
+msgid "Some other public addressbook subscription links:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:165
+msgid ""
+"The operators of these services may have various policies for listing "
+"hosts.\n"
+"Presence on this list does not imply endorsement."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:170
+#: i2p2www/pages/site/docs/naming.html:182
+msgid "Naming Rules"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:171
+msgid ""
+"While there are hopefully not any technical limitations within I2P on "
+"host names,\n"
+"the addressbook enforces several restrictions on host names\n"
+"imported from subscriptions.\n"
+"It does this for basic typographical sanity and compatibility with "
+"browsers,\n"
+"and for security.\n"
+"The rules are essentially the same as those in RFC2396 Section 3.2.2.\n"
+"Any hostnames violating these rules may not be propagated\n"
+"to other routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:186
+msgid "Names are converted to lower case on import."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:190
+msgid ""
+"Names are checked for conflict with existing names in the existing "
+"userhosts.txt and hosts.txt\n"
+"(but not privatehosts.txt) after conversion to lower case."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:195
+msgid "Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:199
+msgid "Must not start with '.' or '-'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:203
+msgid "Must end with '.i2p'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:207
+msgid "67 characters maximum, including the '.i2p'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:211
+msgid "Must not contain '..'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:215
+msgid "Must not contain '.-' or '-.' (as of 0.6.1.33)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:219
+msgid "Must not contain '--' except in 'xn--' for IDN."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:223
+msgid "Base32 hostnames (*.b32.i2p) are not allowed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:227
+msgid ""
+"Certain hostnames reserved for project use are not allowed\n"
+"(proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, "
+"*.console.i2p, and others)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:232
+msgid "Keys are checked for base64 validity."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:236
+msgid ""
+"Keys are checked for conflict with existing keys in hosts.txt (but not "
+"privatehosts.txt)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:240
+msgid "Minimum key length 516 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:244
+msgid "Maximum key length 616 bytes (to account for certs up to 100 bytes)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:249
+msgid ""
+"Any name received via subscription that passes all the checks is added to"
+" the local hosts.txt."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:253
+msgid ""
+"Note that the '.' symbols in a host name are of no significance,\n"
+"and do not denote any actual naming or trust hierarchy.\n"
+"If the name 'host.i2p' already exists, there is nothing\n"
+"to prevent anybody from adding a name 'a.host.i2p' to their hosts.txt,\n"
+"and this name can be imported by others' addressbook.\n"
+"Methods to deny subdomains to non-domain 'owners' (certificates?),\n"
+"and the desirability and feasibility of these methods,\n"
+"are topics for future discussion."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:264
+msgid ""
+"International Domain Names (IDN) also work in i2p (using punycode 'xn--' "
+"form).\n"
+"To see IDN .i2p domain names rendered correctly in Firefox's location "
+"bar,\n"
+"add 'network.IDN.whitelist.i2p (boolean) = true' in about:config."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:270
+msgid ""
+"As the addressbook application does not use privatehosts.txt at all, in "
+"practice\n"
+"this file is the only place where it is appropriate to place private "
+"aliases or\n"
+"\"pet names\" for sites already in hosts.txt."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:276
+msgid "Outgoing Subscriptions"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:277
+msgid ""
+"Addressbook will publish the merged hosts.txt to a location\n"
+"(traditionally hosts.txt in the local eepsite's home directory) to be "
+"accessed by others\n"
+"for their subscriptions.\n"
+"This step is optional and is disabled by default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:285
+msgid ""
+"The addressbook application, together with eepget, saves the Etag and/or "
+"Last-Modified\n"
+"information returned by the web server of the subscription.\n"
+"This greatly reduces the bandwidth required, as the web server will\n"
+"return a '304 Not Modified' on the next fetch if nothing has changed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:292
+msgid ""
+"However the entire hosts.txt is downloaded if it has changed.\n"
+"See below for discussion on this issue."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:297
+msgid ""
+"Hosts serving a static hosts.txt or an equivalent CGI application\n"
+"are strongly encouraged to deliver\n"
+"a Content-Length header, and either an Etag or Last-Modified header.\n"
+"Also ensure that the server delivers a '304 Not Modified' when "
+"appropriate.\n"
+"This will dramatically reduce the network bandwidth, and\n"
+"reduce chances of corruption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:306
+msgid "Host Add Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:307
+msgid ""
+"A host add service is a simple CGI application that takes a hostname and "
+"a Base64 key as parameters\n"
+"and adds that to its local hosts.txt.\n"
+"If other routers subscribe to that hosts.txt, the new hostname/key\n"
+"will be propagated through the network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:314
+msgid ""
+"It is recommended that host add services impose, at a minimum, the "
+"restrictions imposed by the addressbook application listed above.\n"
+"Host add services may impose additional restrictions on hostnames and "
+"keys, for example:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:319
+msgid "A limit on number of 'subdomains'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:323
+msgid "Authorization for 'subdomains' through various methods."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:327
+msgid "Hashcash or signed certificates."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:331
+msgid "Editorial review of host names and/or content."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:335
+msgid "Categorization of hosts by content."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:339
+msgid "Reservation or rejection of certain host names."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:343
+msgid "Restrictions on the number of names registered in a given time period."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:347
+msgid "Delays between registration and publication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:351
+msgid "Requirement that the host be up for verification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:355
+msgid "Expiration and/or revocation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:359
+msgid "IDN spoof rejection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:364
+msgid "Jump Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:365
+msgid ""
+"A jump service is a simple CGI application that takes a hostname as a "
+"parameter\n"
+"and returns a 301 redirect to the proper URL with a "
+"?i2paddresshelper=key\n"
+"string appended.\n"
+"The HTTP proxy will interpret the appended string and\n"
+"use that key as the actual destination.\n"
+"In addition, the proxy will cache that key so the\n"
+"address helper is not necessary until restart."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:375
+msgid ""
+"Note that, like with subscriptions, using a jump service\n"
+"implies a certain amount of trust, as a jump service could maliciously\n"
+"redirect a user to an incorrect destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:381
+msgid ""
+"To provide the best service, a jump service should be subscribed to\n"
+"several hosts.txt providers so that its local host list is current."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:387
+msgid ""
+"SusiDNS is simply a web interface front-end to configuring addressbook "
+"subscriptions\n"
+"and accessing the four addressbook files.\n"
+"All the real work is done by the 'addressbook' application."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:393
+msgid ""
+"Currently, there is little enforcement of addressbook naming rules within"
+" SusiDNS,\n"
+"so a user may enter hostnames locally that would be rejected by\n"
+"the addressbook subscription rules."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:399
+msgid "Base32 Names"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:400
+msgid ""
+"I2P supports Base32 hostnames similar to Tor's .onion addresses.\n"
+"Base32 addresses are much shorter and easier to handle than the\n"
+"full 516-character Base64 Destinations or addresshelpers.\n"
+"Example: "
+"ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:407
+msgid ""
+"In Tor, the address is 16 characters (80 bits), or half of the SHA-1 "
+"hash.\n"
+"I2P uses 52 characters (256 bits) to represent the full SHA-256 hash.\n"
+"The form is {52 chars}.b32.i2p.\n"
+"Base32 is implemented in the naming service, which queries the\n"
+"router over I2CP to lookup the LeaseSet to get the full Destination.\n"
+"Base32 lookups will only be successful when the Destination is up and "
+"publishing\n"
+"a LeaseSet.\n"
+"Because resolution may require a network database lookup, it may take "
+"significantly\n"
+"longer than a local address book lookup."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:419
+msgid ""
+"Base32 addresses can be used in most places where hostnames or full "
+"destinations\n"
+"are used, however there are some exceptions where they may fail if the\n"
+"name does not immediately resolve. I2PTunnel will fail, for example, if\n"
+"the name does not resolve to a destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:3
+#: i2p2www/pages/site/docs/how/network-database.html:3
+msgid "June 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:6
+msgid "I2P Plugins"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:8
+#, fuzzy
+msgid "General Information"
+msgstr "Información adicional"
+
+#: i2p2www/pages/site/docs/plugins.html:9
+msgid ""
+"I2P includes a plugin architecture\n"
+"to support easy development and installation of additional software."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:14
+msgid ""
+"There are now plugins available that support distributed email, blogs, "
+"IRC\n"
+"clients, distributed file storage, wikis, and more."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:19
+msgid "Benefits to i2p users and app developers:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:24
+msgid "Easy distribution of applications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:28
+msgid ""
+"Allows innovation and use of additional libraries without worrying about\n"
+"increasing the size of i2pupdate.sud"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:33
+msgid ""
+"Support large or special-purpose applications that would never be bundled"
+"\n"
+"with the I2P installation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:38
+msgid "Cryptographically signed and verified applications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:42
+msgid "Automatic updates of applications, just like for the router"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:46
+msgid ""
+"Separate initial install and update packages, if desired, for smaller "
+"update downloads"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:50
+msgid ""
+"One-click installation of applications. No more asking users to modify\n"
+"wrapper.config or clients.config"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:55
+msgid "Isolate applications from the base $I2P installation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:59
+msgid ""
+"Automatic compatibility checking for I2P version, Java version, Jetty\n"
+"version, and previous installed application version"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:64
+msgid "Automatic link addition in console"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:68
+msgid ""
+"Automatic startup of application, including modifying classpath, without "
+"requiring a restart"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:72
+msgid "Automatic integration and startup of webapps into console Jetty instance"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:76
+#, python-format
+msgid ""
+"Facilitate creation of 'app stores' like the one at\n"
+"%(pluginsite)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:81
+msgid "One-click uninstall"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:85
+msgid "Language and theme packs for the console"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:89
+msgid "Bring detailed application information to the router console"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:93
+msgid "Non-java applications also supported"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:99
+msgid "Required I2P version"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:100
+msgid "0.7.12 or newer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:102
+msgid "Installation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:103
+msgid ""
+"To install and start a plugin, copy the .xpi2p install link "
+"to\n"
+"the form at the bottom of\n"
+"configclients.jsp"
+" in\n"
+"your router console and click the \"install plugin\" button.  After a"
+"\n"
+"plugin is installed and started, a link to the plugin will usually appear"
+" at\n"
+"the top of your summary bar."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:112
+msgid ""
+"To update a plugin to the latest version, just click the update button on"
+"\n"
+"configclients.jsp."
+"\n"
+"There is also a button to check if the plugin has a more recent version, "
+"as\n"
+"well as a button to check for updates for all plugins.  Plugins will be "
+"checked\n"
+"for updates automatically when updating to a new I2P release (not "
+"including dev\n"
+"builds)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:122
+msgid "Development"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:123
+#, python-format
+msgid ""
+"See the latest plugin specification and "
+"the\n"
+"plugin forum on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:128
+#, python-format
+msgid ""
+"See also the sources for plugins developed by various people.  Some "
+"plugins, such\n"
+"as snowman, were "
+"developed\n"
+"specifically as examples."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:134
+msgid ""
+"Developers wanted! Plugins are a great way to learn more about I2P"
+"\n"
+"or easily add some feature."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:139
+msgid "Getting Started"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:140
+#, python-format
+msgid ""
+"To create a plugin from an existing binary package you will need to get\n"
+"makeplugin.sh from the i2p.scripts branch in "
+"monotone."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:146
+msgid "Known Issues"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:147
+msgid ""
+"Note that the router's plugin architecture does NOT currently\n"
+"provide any additional security isolation or sandboxing of plugins."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:153
+msgid ""
+"Updates of a plugin with included jars (not wars) won't be recognized if\n"
+"the plugin was already run, as it requires class loader trickery to flush"
+" the\n"
+"class cache; a full router restart is required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:159
+msgid "The stop button may be displayed even if there is nothing to stop."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:163
+msgid ""
+"Plugins running in a separate JVM create a logs/ directory "
+"in\n"
+"$CWD."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:168
+msgid ""
+"No initial keys are present, except for those of jrandom and zzz (using "
+"the\n"
+"same keys as for router update), so the first key seen for a signer is\n"
+"automatically accepted—there is no signing key authority."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:174
+msgid ""
+"When deleting a plugin, the directory is not always deleted, especially "
+"on\n"
+"Windows."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:179
+msgid ""
+"Installing a plugin requiring Java 1.6 on a Java 1.5 machine will result "
+"in a\n"
+"\"plugin is corrupt\" message if pack200 compression of the plugin file "
+"is used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:184
+msgid "Theme and translation plugins are untested."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:188
+msgid "Disabling autostart doesn't always work."
+msgstr ""
+
+#: i2p2www/pages/site/docs/ports.html:2
+msgid "Ports Used by I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/ports.html:7
+msgid ""
+"These are the ports used or reserved by I2P, including those for known "
+"plugins,\n"
+"common alternates,\n"
+"and some typical related applications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/ports.html:13
+#, python-format
+msgid ""
+"Note that many of these are not enabled by default.\n"
+"There is more information in the FAQ.\n"
+"See also the documentation for individual plugins.\n"
+"Plugin authors please add any ports you use here.\n"
+"For new plugins, we recommend using the next available port\n"
+"in the 766x range."
+msgstr ""
+
+#: i2p2www/pages/site/docs/ports.html:51
+msgid "recommended spot for new plugins/applications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:5
+msgid "BOB - Basic Open Bridge"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:7
+msgid "Technical differences from SAM (for the better?)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:9
+msgid ""
+"BOB has separate command and data channels. \n"
+"One, an application command channel socket to router to configure.\n"
+"Two, the application data sockets to/from router that carry only data.\n"
+"The command channel is only needed for making or setting the initial\n"
+"destination key, and to set the destination key to port bindings. \n"
+"All connections run in parallel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:18
+msgid ""
+"SAM has one connection that does everything, and you need to parse every "
+"packet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:22
+msgid ""
+"BOB does not hold keypair values, nor does the router.\n"
+"Your application holds the keypair values. \n"
+"This is to reduce any extra complexity in the router code, it also adds "
+"to\n"
+"your privacy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:29
+msgid "SAM router stores every keypair you ever make."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:33
+msgid "Those are the important differences."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:37
+msgid "KEYS = keypair public+private, these are BASE64"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:40
+msgid "KEY = public key, also BASE64"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:43
+msgid ""
+"ERROR as is implied returns the message \"ERROR "
+"\"+DESCRIPTION+\"\n"
+"\", where the DESCRIPTION is what went wrong."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:46
+msgid ""
+"OK returns \"OK\", and if data is to be "
+"returned, it is on the same line. OK means the command is "
+"finished."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:49
+msgid ""
+"DATA lines contain information that you requested. There may"
+" be multiple DATA lines per request."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:53
+msgid ""
+"NOTE: The help command is the ONLY command that has an exception "
+"to\n"
+"the rules... it can actually return nothing! This is intentional, since\n"
+"help is a HUMAN and not an APPLICATION command."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:59
+msgid ""
+"PLEASE NOTE:\n"
+"For CURRENT details on the commands PLEASE use the built-in help command."
+" \n"
+"Just telnet to localhost 2827 and type help and you can get full "
+"documentation on each command."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:65
+msgid ""
+"Commands never get obsoleted or changed, however new commands do get "
+"added from time to time."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:69
+msgid "Here are the commands we have as of this writing:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:74
+msgid "COMMAND"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:74
+msgid "OPERAND"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:74
+msgid "RETURNS"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:101
+msgid ""
+"Once set up, all TCP sockets can and will block as needed, and there is "
+"no need for any \n"
+"additional messages to/from the command channel. This allows the router "
+"to pace the\n"
+"stream without exploding with OOM like SAM does as it chokes on "
+"attempting to shove \n"
+"many streams in or out one socket -- that can't scale when you have alot "
+"of connections!"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:108
+msgid ""
+"What is also nice about this particular interface is that writing "
+"anything to interface \n"
+"to it, is much much easier than SAM. There is no other processing to do "
+"after the set up.\n"
+"It's configuration is so simple, that very simple tools, such as nc "
+"(netcat) can be used \n"
+"to point to some application. The value there is that one could schedule "
+"up and down times \n"
+"for an application, and not have to change the application to do that, or"
+" to even have \n"
+"to stop that application. Instead, you can literally \"unplug\" the "
+"destination, and \n"
+"\"plug it in\" again. As long as the same IP/port addresses and "
+"destination keys are used \n"
+"when bringing the bridge up, the normal TCP application won't care, and "
+"won't notice.\n"
+"It will simply be fooled -- the destinations are not reachable, and that "
+"nothing is coming in."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:120
+msgid ""
+"For the following example, we'll setup a very simple local loopback "
+"connection, \n"
+"with two destinations. Destination \"mouth\" will be the CHARGEN service "
+"from \n"
+"the INET superserver daemon. Destination \"ear\" will be a local port "
+"that you\n"
+"can telnet into, and watch the pretty ASCII test puke forth."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:128
+msgid "EXAMPLE SESSION DIALOGUE -- simple telnet 127.0.0.1 2827 works"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:129
+msgid "Application"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:130
+msgid "BOB's Command response."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:132
+#: i2p2www/pages/site/docs/api/bob.html:144
+#: i2p2www/pages/site/docs/api/bob.html:164
+#: i2p2www/pages/site/docs/api/bob.html:272
+#: i2p2www/pages/site/docs/api/bob.html:284
+#: i2p2www/pages/site/docs/api/bob.html:299
+msgid "FROM"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:132
+#: i2p2www/pages/site/docs/api/bob.html:144
+#: i2p2www/pages/site/docs/api/bob.html:164
+#: i2p2www/pages/site/docs/api/bob.html:272
+#: i2p2www/pages/site/docs/api/bob.html:284
+#: i2p2www/pages/site/docs/api/bob.html:299
+msgid "TO"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:132
+#: i2p2www/pages/site/docs/api/bob.html:144
+#: i2p2www/pages/site/docs/api/bob.html:164
+#: i2p2www/pages/site/docs/api/bob.html:272
+#: i2p2www/pages/site/docs/api/bob.html:284
+#: i2p2www/pages/site/docs/api/bob.html:299
+msgid "DIALOGUE"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:139
+msgid "MAKE NOTE OF THE ABOVE DESTINATION KEY, YOURS WILL BE DIFFERENT!"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:153
+msgid ""
+"At this point, there was no error, a destination with a nickname of "
+"\"mouth\" \n"
+"is set up. When you contact the destination provided, you actually "
+"connect \n"
+"to the CHARGEN service on 19/TCP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:159
+msgid "Now for the other half, so that we can actually contact this destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:179
+msgid ""
+"Now all we need to do is telnet into 127.0.0.1, port 37337,\n"
+"send the destination key or host address from addressbook we want to "
+"contact.\n"
+"In this case, we want to contact \"mouth\", all we do is paste in the\n"
+"key and it goes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:186
+msgid ""
+"NOTE: The \"quit\" command in the command channel does NOT "
+"disconnect the tunnels like SAM."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:203
+msgid "After a few virtual miles of this spew, press Control-]"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:215
+msgid "Here is what happened..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:223
+msgid "You can connect to EEPSITES too!"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:256
+msgid ""
+"Pretty cool isn't it? Try some other well known EEPSITES if you like, "
+"nonexistent ones, \n"
+"etc, to get a feel for what kind of output to expect in different "
+"situations. \n"
+"For the most part, it is suggested that you ignore any of the error "
+"messages. \n"
+"They would be meaningless to the application, and are only presented for "
+"human debugging."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:263
+msgid "Let's put down our destinations now that we are all done with them."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:267
+msgid "First, lets see what destination nicknames we have."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:279
+msgid "Alright, there they are. First, let's remove \"mouth\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:293
+msgid ""
+"Now to remove \"ear\", note that this is what happens when you type too "
+"fast,\n"
+"and shows you what typical ERROR messages looks like."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:312
+msgid ""
+"I won't bother to show an example of the receiver end of a bridge\n"
+"because it is very simple. There are two possible settings for it, and\n"
+"it is toggled with the \"quiet\" command."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:318
+msgid ""
+"The default is NOT quiet, and the first data to come into your\n"
+"listening socket is the destination that is making the contact. It is a\n"
+"single line consisting of the BASE64 address followed by a newline.\n"
+"Everything after that is for the application to actually consume."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:325
+msgid ""
+"In quiet mode, think of it as a regular Internet connection. No\n"
+"extra data comes in at all. It's just as if you are plain connected to\n"
+"the regular Internet. This mode allows a form of transparency much like\n"
+"is available on the router console tunnel settings pages, so that you\n"
+"can use BOB to point a destination at a web server, for example, and\n"
+"you would not have to modify the web server at all."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:334
+msgid ""
+"The advantage with using BOB for this is as discussed\n"
+"previously. You could schedule random uptimes for the application,\n"
+"redirect to a different machine, etc. One use of this may be something\n"
+"like wanting to try to goof up router-to-destination upness guessing.\n"
+"You could stop and start the destination with a totally different\n"
+"process to make random up and down times on services. That way you\n"
+"would only be stopping the ability to contact such a service, and not\n"
+"have to bother shutting it down and restarting it. You could redirect\n"
+"and point to a different machine on your LAN while you do updates, or\n"
+"point to a set of backup machines depending on what is running, etc,\n"
+"etc. Only your imagination limits what you could do with BOB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:6
+msgid "Datagram Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:7
+#, python-format
+msgid ""
+"Datagrams build upon the base I2CP to provide "
+"authenticated\n"
+"and repliable messages in a standard format.  This lets applications "
+"reliably read\n"
+"the \"from\" address out of a datagram and know that the address really "
+"sent the\n"
+"message.  This is necessary for some applications since the base I2P "
+"message is\n"
+"completely raw - it has no \"from\" address (unlike IP packets).  In "
+"addition, the\n"
+"message and sender are authenticated by signing the payload."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:16
+#, python-format
+msgid ""
+"Datagrams, like streaming library packets,\n"
+"are an application-level construct.\n"
+"These protocols are independent of the low-level transports;\n"
+"the protocols are converted to I2NP messages by the router, and\n"
+"either protocol may be carried by either transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:25
+msgid "Application Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:26
+#, python-format
+msgid ""
+"Applications written in Java may use the \n"
+"datagram API,\n"
+"while applications in other languages \n"
+"can use SAM's datagram support.\n"
+"There is also limited support in i2ptunnel in the SOCKS proxy,\n"
+"the 'streamr' tunnel types, and udpTunnel classes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:37
+msgid "Datagram Length"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:38
+msgid ""
+"The application designer should carefully consider the tradeoff of "
+"repliable vs. non-repliable\n"
+"datagrams. Also, the datagram size will affect reliability, due to tunnel"
+" fragmentation into 1KB\n"
+"tunnel messages. The more message fragments, the more likely that one of "
+"them will be dropped\n"
+"by an intermediate hop. Messages larger than a few KB are not recommended."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:45
+#, python-format
+msgid ""
+"Also note that the various overheads added by lower layers, in particular"
+" asymmetric\n"
+"ElGamal/AES, place a large burden on "
+"intermittent messages\n"
+"such as used by a Kademlia-over-UDP application. The implementations are "
+"currently tuned\n"
+"for frequent traffic using the streaming library. There are a high number"
+"\n"
+"of session tags delivered, and a short session tag lifetime, for example."
+"\n"
+"There are currently no configuration parameters available within I2CP to "
+"tune\n"
+"the ElGamal Session Tag parameters."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:55
+msgid "I2CP Protocol Number and Ports"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:56
+msgid ""
+"The standard I2CP protocol number for datagrams is 17. Applications may "
+"or may not choose to set the\n"
+"protocol in the I2CP header. It is not set by default.\n"
+"It must be set to demultiplex datagram and streaming traffic received on "
+"the same Destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:62
+#, python-format
+msgid ""
+"As datagrams are not connection-oriented, the application may require\n"
+"port numbers to correlate datagrams with particular peers or "
+"communications sessions,\n"
+"as is traditional with UDP over IP.\n"
+"Applications may add 'from' and 'to' ports to the I2CP (gzip) header as "
+"described in\n"
+"the I2CP page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:70
+msgid ""
+"There is no method within the datagram API to specify whether it is non-"
+"repliable (raw)\n"
+"or repliable. The application should be designed to expect the "
+"appropriate type.\n"
+"The I2CP protocol number or port could also be used by the application to"
+"\n"
+"indicate datagram type."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:77
+#, python-format
+msgid ""
+"The protocols and ports may be set in I2CP's\n"
+"I2PSession API,\n"
+"as implemented in\n"
+"I2PSessionMuxedImpl."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:85
+#: i2p2www/pages/site/docs/api/streaming.html:325
+msgid "Data Integrity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:86
+#, python-format
+msgid ""
+"Data integrity is assured by the gzip CRC-32 checksum implemented in\n"
+"the I2CP layer.\n"
+"There is no checksum field in the datagram protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:92
+#: i2p2www/pages/site/docs/api/streaming.html:333
+msgid "Packet Encapsulation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:93
+#, python-format
+msgid ""
+"Each datagram is sent through I2P as a single message (or as an "
+"individual clove in a\n"
+"Garlic Message).\n"
+"Message encapsulation is implemented in the underlying\n"
+"I2CP,\n"
+"I2NP, and\n"
+"tunnel message layers.\n"
+"There is no packet delimiter mechanism or length field in the datagram "
+"protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:106
+#: i2p2www/pages/site/docs/spec/datagrams.html:10
+#: i2p2www/pages/site/docs/transport/ssu.html:547
+msgid "Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:108
+msgid "See the Datagrams Specification page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:4
+msgid "I2PControl - Remote Control Service"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:5
+#, python-format
+msgid ""
+"I2P enables a JSONRPC2 interface via the plugin I2PControl.\n"
+"The aim of the interface is to provide simple way to interface with a "
+"running I2P node. A client, itoopie, has been developed in parallel.\n"
+"The JSONRPC2 implementation for the client as well as the plugin is "
+"provided by the java libraries JSON-RPC 2.0.  \n"
+"A list of implementations of JSON-RPC for various languages can be found "
+"at the JSON-RPC "
+"wiki."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:12
+msgid "I2PControl is by default listening on localhost:7650"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:14
+msgid "API, version 1."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:15
+msgid "Parameters are only provided in a named way (maps)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:19
+msgid "JSON-RPC 2 format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:21
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:27
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:40
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:50
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:59
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:69
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:84
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:137
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:154
+msgid "Request:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:23
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:32
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:44
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:54
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:64
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:75
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:101
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:145
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:169
+msgid "Response:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:26
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:28
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:29
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:33
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:34
+#: i2p2www/pages/site/docs/protocol/i2cp.html:99
+#: i2p2www/pages/site/docs/protocol/i2cp.html:442
+#: i2p2www/pages/site/docs/spec/common-structures.html:16
+#: i2p2www/pages/site/docs/spec/common-structures.html:26
+#: i2p2www/pages/site/docs/spec/common-structures.html:37
+#: i2p2www/pages/site/docs/spec/common-structures.html:49
+#: i2p2www/pages/site/docs/spec/common-structures.html:64
+#: i2p2www/pages/site/docs/spec/common-structures.html:77
+#: i2p2www/pages/site/docs/spec/common-structures.html:90
+#: i2p2www/pages/site/docs/spec/common-structures.html:102
+#: i2p2www/pages/site/docs/spec/common-structures.html:114
+#: i2p2www/pages/site/docs/spec/common-structures.html:126
+#: i2p2www/pages/site/docs/spec/common-structures.html:138
+#: i2p2www/pages/site/docs/spec/common-structures.html:150
+#: i2p2www/pages/site/docs/spec/common-structures.html:162
+#: i2p2www/pages/site/docs/spec/common-structures.html:174
+#: i2p2www/pages/site/docs/spec/common-structures.html:229
+#: i2p2www/pages/site/docs/spec/common-structures.html:298
+#: i2p2www/pages/site/docs/spec/common-structures.html:349
+#: i2p2www/pages/site/docs/spec/common-structures.html:395
+#: i2p2www/pages/site/docs/spec/common-structures.html:442
+#: i2p2www/pages/site/docs/spec/common-structures.html:568
+#: i2p2www/pages/site/docs/spec/common-structures.html:623
+msgid "Description"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:30
+msgid ""
+"Token used for authenticating every request (excluding the 'Authenticate'"
+" RPC method)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:38
+msgid "Implemented methods"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:39
+msgid ""
+"Creates and returns an authentication token used for further "
+"communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:41
+msgid "The version of the I2PControl API used by the client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:42
+msgid "The password used for authenticating against the remote server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:45
+msgid "The primary I2PControl API version implemented by the server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:46
+msgid "The token used for further communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:49
+msgid "Echoes the value of the echo key, used for debugging and testing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:51
+msgid "Value will be returned in response."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:52
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:62
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:73
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:99
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:143
+msgid ""
+"Token used for authenticating the client. Is provided by the server via "
+"the 'Authenticate' RPC method."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:55
+msgid "Value of the key 'echo' in the request."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:58
+msgid ""
+"Fetches rateStat from router statManager. Creates stat if not already "
+"created."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:60
+#, python-format
+msgid ""
+"Determines which rateStat to fetch, see ratestats."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:61
+msgid "Determines which period a stat is fetched for. Measured in ms."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:65
+msgid "Returns the average value for the reuested rateStat and period."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:68
+msgid "Manages I2PControl. Ports, passwords and the like."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:70
+msgid ""
+"Sets a new listen address for I2PControl (only 127.0.0.1 and 0.0.0.0 are "
+"implemented in I2PControl currently)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:71
+msgid ""
+"Sets a new password for I2PControl, all Authentication tokens will be "
+"revoked."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:72
+msgid "Switches which port I2PControl will listen for connections on."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:76
+msgid "Returned if address was changed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:77
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:78
+msgid "Returned if setting was changed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:79
+msgid "Returns true if any changes were made."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:80
+msgid "Returns true if any changes requiring a restart to take effect were made."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:83
+msgid "Fetches basic information about the I2P router. Uptime, version etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:102
+msgid "What the status of the router is."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:103
+msgid "What the uptime of the router is in ms."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:104
+msgid "What version of I2P the router is running."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:105
+msgid "The 1 second average inbound bandwidth in Bps."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:106
+msgid "The 15 second average inbound bandwidth in Bps."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:107
+msgid "The 1 second average outbound bandwidth in Bps."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:108
+msgid "The 15 second average outbound bandwidth in Bps."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:109
+msgid "What the current network status is. According to the below enum:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:128
+msgid "How many tunnels on the I2P net are we participating in."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:129
+msgid "How many peers have we communicated with recently."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:130
+msgid "How many peers are considered 'fast'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:131
+msgid "How many peers are considered 'high capacity'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:132
+msgid "Is the router reseeding hosts to its NetDB?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:133
+msgid "How many peers are known to us (listed in our NetDB)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:136
+msgid "Manages I2P router restart/shutdown."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:138
+msgid ""
+"Initiates a router reseed, fetching peers into our NetDB from a remote "
+"host."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:139
+msgid "Restarts the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:140
+msgid ""
+"Restarts the router gracefully (waits for participating tunnels to "
+"expire)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:141
+msgid "Shuts down the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:142
+msgid ""
+"Shuts down the router gracefully (waits for participating tunnels to "
+"expire)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:146
+msgid "If requested, verifies that a reseed has been initiated."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:147
+msgid "If requested, verifies that a restart has been initiated."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:148
+msgid "If requested, verifies that a graceful restart has been initiated."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:149
+msgid "If requested, verifies that a shutdown has been initiated"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:150
+msgid "If requested, verifies that a graceful shutdown has been initiated"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:153
+msgid "Fetches or sets various network related settings. Ports, addresses etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:155
+msgid ""
+"What port is used for the TCP transport. If null is submitted, current "
+"setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:156
+msgid ""
+"What hostname is used for the TCP transport. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:157
+msgid ""
+"Use automatically detected ip for TCP transport. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:158
+msgid ""
+"What port is used for the UDP transport. If null is submitted, current "
+"setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:159
+msgid ""
+"What hostname is used for the UDP transport. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:160
+msgid ""
+"Which methods should be used for detecting the ip address of the UDP "
+"transport. If null is submitted, current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:161
+msgid "What ip has been detected by the UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:162
+msgid "Is UPnP enabled. If null is submitted, current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:163
+msgid ""
+"How many percent of bandwidth is usable for participating tunnels. If "
+"null is submitted, current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:164
+msgid ""
+"How many KB/s of inbound bandwidth is allowed. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:165
+msgid ""
+"How many KB/s of outbound bandwidth is allowed. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:166
+msgid ""
+"Is laptop mode enabled (change router identity and UDP port when IP "
+"changes ). If null is submitted, current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:167
+msgid ""
+"Token used for authenticating the client. Is provided by the server via "
+"the 'Authenticate' RPC method. If null is submitted, current setting will"
+" be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:170
+msgid "If requested, returns the port used for the TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:171
+msgid "If requested, returns the hostname used for the TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:172
+msgid ""
+"If requested, returns the method used for automatically detecting ip for "
+"the TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:173
+msgid "If requested, returns the port used for the UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:174
+msgid "If requested, returns the hostname used for the UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:175
+msgid ""
+"If requested, returns methods used for detecting the ip address of the "
+"UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:176
+msgid "If requested, returns what ip has been detected by the UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:177
+msgid "If requested, returns the UPNP setting."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:178
+msgid ""
+"If requested, returns how many percent of bandwidth is usable for "
+"participating tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:179
+msgid "If requested, returns how many KB/s of inbound bandwidth is allowed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:180
+msgid "If requested, returns how many KB/s of outbound bandwidth is allowed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:181
+msgid "If requested, returns the laptop mode."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:182
+msgid "Have the provided settings been saved."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:183
+msgid "Is a restart needed for the new settings to be used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:186
+msgid "denotes an optional value."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:187
+msgid "denotes a possibly occuring return value"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:189
+msgid "Error codes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:190
+msgid "Standard JSON-RPC2 error codes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:191
+msgid "JSON parse error."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:192
+msgid "Invalid request."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:193
+msgid "Method not found."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:194
+msgid "Internal error."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:196
+msgid "I2PControl specific error codes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:197
+msgid "Invalid password provided."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:198
+msgid "No authentication token presented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:199
+msgid "Authentication token doesn't exist."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:200
+msgid "The provided authentication token was expired and will be removed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:201
+msgid ""
+"The version of the I2PControl API used wasn't specified, but is required "
+"to be specified."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:202
+msgid ""
+"The version of the I2PControl API specified is not supported by "
+"I2PControl."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:13
+#, python-format
+msgid ""
+"I2PTunnel is a tool for interfacing with and providing services on I2P.\n"
+"Destination of an I2PTunnel can be defined using a hostname,\n"
+"Base32, or a full 516-byte destination "
+"key.\n"
+"An established I2PTunnel will be available on your client machine as "
+"localhost:port.\n"
+"If you wish to provide a service on I2P network, you simply create "
+"I2PTunnel to the\n"
+"appropriate ip_address:port. A corresponding 516-byte destination key "
+"will be generated\n"
+"for the service and it will become avaliable throughout I2P.\n"
+"A web interface for I2PTunnel management is avaliable on\n"
+"localhost:7657/i2ptunnel/."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:25
+msgid "Default Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:26
+msgid "Server tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:28
+msgid ""
+"I2P Webserver - A tunnel pointed to a Jetty webserver run\n"
+"on localhost:7658 for convenient "
+"and quick hosting on I2P.\n"
+"
            The document root is:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:36
+msgid "Client tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:38
+msgid ""
+"A HTTP proxy used for browsing I2P and the regular internet anonymously "
+"through I2P. \n"
+"Browsing internet through I2P uses a random proxy specified by the "
+"\"Outproxies:\" option."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:42
+msgid "An IRC tunnel to the default anonymous IRC network, Irc2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:43
+#, python-format
+msgid ""
+"The anonymous monotone"
+"\n"
+"sourcecode repository for I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:47
+#, python-format
+msgid ""
+"A SMTP service provided by postman at %(postman)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:50
+#, python-format
+msgid ""
+"The accompanying POP sevice of postman at %(postman)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:55
+msgid "Client Modes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:56
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:138
+msgid "Standard"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:57
+msgid ""
+"Opens a local TCP port that connects to a service (like HTTP, FTP or "
+"SMTP) on a destination inside of I2P.\n"
+"The tunnel is directed to a random host from the comma seperated (\", \")"
+" list of destinations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:63
+msgid ""
+"A HTTP-client tunnel. The tunnel connects to the destination specified by"
+" the URL\n"
+"in a HTTP request. Supports proxying onto internet if an outproxy is "
+"provided. Strips HTTP connections of the following headers:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:68
+msgid ""
+"Accept, Accept-Charset, Accept-Encoding, Accept-Language\n"
+" and Accept-Ranges as they vary greatly between browsers and can be "
+"used as an identifier."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:76
+msgid ""
+"HTTP client/server tunnels are via I2Ptunnel force-enabling compression "
+"via the following http headers:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:83
+msgid ""
+"Depending on if the tunnel is using an outproxy or not it will append the"
+" following User-Agent:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:87
+msgid "Outproxy:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:88
+msgid "Internal I2P use:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:93
+msgid ""
+"Creates a connection to a random IRC server specified by the comma "
+"seprated (\", \") \n"
+"list of destinations. Only a whitelisted subset of IRC commands are "
+"allowed due to anonymity concerns."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:97
+msgid "Whitelist:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:112
+msgid "Enables using the I2P router as a SOCKS proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:117
+msgid ""
+"Enables using the I2P router as a SOCKS proxy with the command whitelist "
+"specified by\n"
+"IRC client mode."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:123
+msgid ""
+"Creates a HTTP tunnel and uses the HTTP request method \"CONNECT\" \n"
+"to build a TCP tunnel that usually is used for SSL and HTTPS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:129
+msgid ""
+"Creates a UDP-server attached to a Streamr client I2PTunnel. The streamr "
+"client tunnel will \n"
+"subscribe to a streamr server tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:137
+msgid "Server Modes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:139
+msgid "Creates a destination to a local ip:port with an open TCP port."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:144
+msgid ""
+"Creates a destination to a local HTTP server ip:port. Supports gzip for "
+"requests with \n"
+"Accept-encoding: x-i2p-gzip, replies with Content-encoding: x-i2p-gzip in"
+" such a request."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:150
+msgid ""
+"Functions as both a I2PTunnel HTTP Server, and a I2PTunnel HTTP client "
+"with no outproxying\n"
+"capabilities. An example application would be a web application that does"
+" client-type\n"
+"requests, or loopback-testing an eepsite as a diagnostic tool."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:157
+msgid ""
+"Creates a destination that filters the reqistration sequence of a client "
+"and passes \n"
+"the clients destination key as a hostname to the IRC-server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:163
+msgid ""
+"A UDP-client that connects to a media server is created. The UDP-Client "
+"is coupled with a Streamr server I2PTunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:2
+#: i2p2www/pages/site/docs/api/ministreaming.html:17
+msgid "Ministreaming Library"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:5
+msgid "Note"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:7
+#, python-format
+msgid ""
+"The ministreaming library has been enhanced and extended by the\n"
+"\"full\" streaming library.\n"
+"Ministreaming is deprecated and is incompatible with today's "
+"applications.\n"
+"The following documentation is old.\n"
+"Also note that streaming extends ministreaming in the same Java package "
+"(net.i2p.client.streaming),\n"
+"so the current API documentation contains both.\n"
+"Obsolete ministreaming classes and methods are clearly marked as "
+"deprecated in the Javadocs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:19
+#, python-format
+msgid ""
+"\n"
+"The ministreaming library is a layer on top of the core \n"
+"I2CP that allows reliable, in order, and "
+"authenticated streams\n"
+"of messages to operate across an unreliable, unordered, and "
+"unauthenticated \n"
+"message layer.  Just like the TCP to IP relationship, this streaming \n"
+"functionality has a whole series of tradeoffs and optimizations "
+"available, but\n"
+"rather than embed that functionality into the base I2P code, it has been "
+"factored\n"
+"off into its own library both to keep the TCP-esque complexities separate"
+" and to\n"
+"allow alternative optimized implementations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:30
+#, python-format
+msgid ""
+"The ministreaming library was written by mihi as a part of his \n"
+"I2PTunnel application and then factored out"
+" and released\n"
+"under the BSD license.  It is called the \"mini\"streaming library "
+"because it makes\n"
+"some simplifications in the implementation, while a more robust streaming"
+" library\n"
+"could be further optimized for operation over I2P.  The two main issues "
+"with \n"
+"the ministreaming library are its use of the traditional TCP two phase \n"
+"establishment protocol and the current fixed window size of 1.  The "
+"establishment\n"
+"issue is minor for long lived streams, but for short ones, such as quick "
+"HTTP\n"
+"requests, the impact can be significant.  As "
+"for the window\n"
+"size, the ministreaming library doesn't maintain any ID or ordering "
+"within the \n"
+"messages sent (or include any application level ACK or SACK), so it must "
+"wait \n"
+"on average twice the time it takes to send a message before sending "
+"another."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:45
+#, python-format
+msgid ""
+"Even with those issues, the ministreaming library performs quite well in "
+"many\n"
+"situations, and its API\n"
+"is both quite simple and capable of remaining unchanged as different "
+"streaming\n"
+"implementations are introduced.  The library is deployed in its own \n"
+"ministreaming.jar.\n"
+"Developers in Java who would like to use it can\n"
+"access the API directly, while developers in other languages can use it "
+"through\n"
+"SAM's streaming support."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:4
+msgid "SOCKS and SOCKS proxies"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:5
+msgid ""
+"\n"
+"The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are "
+"supported.\n"
+"Enable SOCKS by creating a SOCKS client tunnel in i2ptunnel.\n"
+"Both shared-clients and non-shared are supported.\n"
+"There is no SOCKS outproxy so it is of limited use."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:12
+#, python-format
+msgid ""
+"\n"
+"As it says on the FAQ:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:15
+msgid ""
+"Many applications leak sensitive\n"
+"information that could identify you on the Internet. I2P only filters\n"
+"connection data, but if the program you intend to run sends this\n"
+"information as content, I2P has no way to protect your anonymity.  For\n"
+"example, some mail applications will send the IP address of the machine\n"
+"they are running on to a mail server. There is no way for I2P to filter\n"
+"this, thus using I2P to 'socksify' existing applications is possible, but"
+"\n"
+"extremely dangerous."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:25
+msgid "And quoting from a 2005 email:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:28
+msgid ""
+"... there is a reason why human and\n"
+"others have both built and abandoned the SOCKS proxies.  Forwarding\n"
+"arbitrary traffic is just plain unsafe, and it behooves us as\n"
+"developers of anonymity and security software to have the safety of\n"
+"our end users foremost in our minds."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:36
+msgid ""
+"Hoping that we can simply strap an arbitrary client on top of I2P\n"
+"without auditing both its behavior and its exposed protocols for\n"
+"security and anonymity is naive.  Pretty much *every* application\n"
+"and protocol violates anonymity, unless it was designed for it\n"
+"specifically, and even then, most of those do too.  That's the\n"
+"reality.  End users are better served with systems designed for\n"
+"anonymity and security.  Modifying existing systems to work in\n"
+"anonymous environments is no small feat, orders of magnitude more\n"
+"work that simply using the existing I2P APIs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:48
+msgid ""
+"The SOCKS proxy\n"
+"supports standard addressbook names, but not Base64 destinations.\n"
+"Base32 hashes should work as of release 0.7.\n"
+"It supports outgoing connections only, i.e. an I2PTunnel Client.\n"
+"UDP support is stubbed out but not working yet.\n"
+"Outproxy selection by port number is stubbed out."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:57
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:281
+msgid "See Also"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:59
+#, python-format
+msgid ""
+"The notes for Meeting 81 and\n"
+"Meeting 82 in March 2004."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:69
+msgid "If You Do Get Something Working"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:70
+msgid ""
+"Please let us know. And please provide substantial warnings about the\n"
+"risks of socks proxies."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:3
+#: i2p2www/pages/site/docs/protocol/i2cp.html:3
+#: i2p2www/pages/site/docs/spec/streaming.html:3
+msgid "November 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:8
+#, python-format
+msgid ""
+"The streaming library is technically part of the \"application\" layer,\n"
+"as it is not a core router function.\n"
+"In practice, however, it provides a vital function for almost all\n"
+"existing I2P applications, by providing a TCP-like\n"
+"streams over I2P, and allowing existing apps to be easily ported to I2P.\n"
+"The other end-to-end transport library for client communication is the\n"
+"datagram library."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:18
+#, python-format
+msgid ""
+"The streaming library is a layer on top of the core \n"
+"I2CP API that allows reliable, in-order, and "
+"authenticated streams\n"
+"of messages to operate across an unreliable, unordered, and "
+"unauthenticated \n"
+"message layer.  Just like the TCP to IP relationship, this streaming \n"
+"functionality has a whole series of tradeoffs and optimizations "
+"available, but\n"
+"rather than embed that functionality into the base I2P code, it has been "
+"factored\n"
+"off into its own library both to keep the TCP-esque complexities separate"
+" and to\n"
+"allow alternative optimized implementations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:29
+msgid ""
+"In consideration of the relatively high cost of messages, \n"
+"the streaming library's protocol for scheduling and delivering those "
+"messages has been optimized to\n"
+"allow individual messages passed to contain as much information as is "
+"available.\n"
+"For instance, a small HTTP transaction proxied through the streaming "
+"library can\n"
+"be completed in a single round trip - the first messages bundle a SYN, "
+"FIN, and\n"
+"the small HTTP request payload, and the reply bundles the SYN,\n"
+"FIN, ACK, and the HTTP response payload.  While an additional\n"
+"ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has "
+"been\n"
+"received, the local HTTP proxy can often deliver the full response to the"
+" browser \n"
+"immediately."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:42
+msgid ""
+"The streaming library bears much resemblance to an \n"
+"abstraction of TCP, with its sliding windows, congestion control "
+"algorithms\n"
+"(both slow start and congestion avoidance), and general packet behavior "
+"(ACK,\n"
+"SYN, FIN, RST, rto calculation, etc)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:49
+msgid ""
+"The streaming library is\n"
+"a robust library\n"
+"which is optimized for operation over I2P.\n"
+"It has a one-phase setup, and\n"
+"it contains a full windowing implementation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:60
+#, python-format
+msgid ""
+"The streaming library API provides a standard socket paradigm to Java "
+"applications.\n"
+"The lower-level I2CP API is completely hidden, "
+"except that\n"
+"applications may pass I2CP parameters "
+"through the\n"
+"streaming library, to be interpreted by I2CP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:67
+#, python-format
+msgid ""
+"The standard interface to the streaming lib is for the application to use"
+" the\n"
+"I2PSocketManagerFactory to create an\n"
+"I2PSocketManager. The application then asks "
+"the\n"
+"socket manager for an I2PSession, which will "
+"cause\n"
+"a connection to the router via I2CP. The "
+"application\n"
+"can then setup connections with an I2PSocket "
+"or\n"
+"receive connections with an I2PServerSocket."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:82
+#, python-format
+msgid "Here are the full streaming library Javadocs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:86
+msgid "For a good example of usage, see the i2psnark code."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:91
+msgid "Options and Defaults"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:92
+#, python-format
+msgid ""
+"The options and current default values are listed below.\n"
+"Options are case-sensitive and may be set for the whole router, for a "
+"particular client, or for an individual socket on a\n"
+"per-connection basis.\n"
+"Many values are tuned for HTTP performance over typical I2P conditions. "
+"Other applications such\n"
+"as peer-to-peer services are strongly encouraged to\n"
+"modify as necessary, by setting the options and passing them via the call"
+" to\n"
+"I2PSocketManagerFactory.createManager(_i2cpHost,"
+" _i2cpPort, opts).\n"
+"Time values are in ms."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:103
+#, python-format
+msgid ""
+"Note that higher-layer APIs, such as SAM,\n"
+"BOB, and I2PTunnel,"
+"\n"
+"may override these defaults with their own defaults.\n"
+"Also note that many options only apply to servers listening for incoming "
+"connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:110
+msgid ""
+"As of release 0.9.1, most, but not all, options may be changed on an "
+"active socket manager or session.\n"
+"See the javadocs for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:117
+#: i2p2www/pages/site/docs/protocol/i2cp.html:94
+#: i2p2www/pages/site/docs/protocol/i2cp.html:437
+msgid "Option"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:117
+#: i2p2www/pages/site/docs/protocol/i2cp.html:98
+#: i2p2www/pages/site/docs/protocol/i2cp.html:441
+msgid "Default"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:117
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:267
+#: i2p2www/pages/site/docs/how/peer-selection.html:282
+#: i2p2www/pages/site/docs/spec/common-structures.html:58
+#: i2p2www/pages/site/docs/spec/common-structures.html:205
+#: i2p2www/pages/site/docs/spec/common-structures.html:261
+#: i2p2www/pages/site/docs/spec/common-structures.html:341
+#: i2p2www/pages/site/docs/spec/common-structures.html:431
+#: i2p2www/pages/site/docs/spec/common-structures.html:541
+#: i2p2www/pages/site/docs/spec/common-structures.html:608
+#: i2p2www/pages/site/docs/spec/common-structures.html:709
+#: i2p2www/pages/site/docs/spec/datagrams.html:31
+#: i2p2www/pages/site/docs/spec/datagrams.html:90
+msgid "Notes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:119
+msgid ""
+"Comma- or space-separated list of Base64 peer Hashes used for either "
+"access list or blacklist."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:121
+#: i2p2www/pages/site/docs/api/streaming.html:127
+#: i2p2www/pages/site/docs/api/streaming.html:133
+#: i2p2www/pages/site/docs/api/streaming.html:147
+#: i2p2www/pages/site/docs/api/streaming.html:176
+#: i2p2www/pages/site/docs/api/streaming.html:184
+#: i2p2www/pages/site/docs/api/streaming.html:214
+#: i2p2www/pages/site/docs/api/streaming.html:220
+#: i2p2www/pages/site/docs/api/streaming.html:226
+#: i2p2www/pages/site/docs/api/streaming.html:240
+#: i2p2www/pages/site/docs/api/streaming.html:247
+#: i2p2www/pages/site/docs/api/streaming.html:254
+#, python-format
+msgid "As of release %(release)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:125
+msgid "Use the access list as a whitelist for incoming connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:131
+msgid "Use the access list as a blacklist for incoming connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:137
+msgid "Whether to respond to incoming pings"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:141
+msgid ""
+"Comma- or space-separated list of Base64 peer Hashes to be\n"
+"blacklisted for incoming connections to ALL destinations in the context.\n"
+"This option must be set in the context properties, NOT in the "
+"createManager() options argument.\n"
+"Note that setting this in the router context will not affect clients "
+"outside the\n"
+"router in a separate JVM and context."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:151
+msgid ""
+"How much transmit data (in bytes) will be accepted that hasn't been "
+"written out yet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:155
+msgid ""
+"When we're in congestion avoidance, we grow the window size at the rate\n"
+"of 1/(windowSize*factor).  In standard TCP, window sizes are"
+" in bytes,\n"
+"while in I2P, window sizes are in messages.\n"
+"A higher number means slower growth."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:162
+msgid ""
+"How long to wait after instantiating a new con \n"
+"before actually attempting to connect.  If this is\n"
+"<= 0, connect immediately with no initial data.  If greater than 0, "
+"wait\n"
+"until the output stream is flushed, the buffer fills, \n"
+"or that many milliseconds pass, and include any initial data with the SYN."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:170
+msgid ""
+"How long to block on connect, in milliseconds. Negative means "
+"indefinitely. Default is 5 minutes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:174
+msgid ""
+"Whether to disable warnings in the logs when an incoming connection is "
+"rejected due to connection limits."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:180
+msgid ""
+"Whether to listen only for the streaming protocol.\n"
+"Setting to true will prohibit communication with Destinations earlier "
+"than release 0.7.1\n"
+"(released March 2009). Set to true if running multiple protocols on this "
+"Destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:188
+msgid ""
+"(0=noop, 1=disconnect)\n"
+"What to do on an inactivity timeout - do nothing, disconnect, or send a "
+"duplicate ack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:196
+msgid ""
+"The initial value of the resend delay field in the packet header, times "
+"1000.\n"
+"Not fully implemented; see below."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:201
+#: i2p2www/pages/site/docs/api/streaming.html:203
+msgid "if no sharing data available"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:203
+msgid ""
+"In standard TCP, window sizes are in bytes, while in I2P, window sizes "
+"are in messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:207
+msgid ""
+"(0 or negative value means unlimited)\n"
+"This is a total limit for incoming and outgoing combined."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:212
+msgid "Incoming connection limit (per peer; 0 means disabled)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:218
+#: i2p2www/pages/site/docs/api/streaming.html:224
+msgid "(per peer; 0 means disabled)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:230
+msgid "The MTU in bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:234
+msgid "Maximum number of retransmissions before failure."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:238
+msgid "Incoming connection limit (all peers; 0 means disabled)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:244
+#: i2p2www/pages/site/docs/api/streaming.html:251
+msgid ""
+"(all peers; 0 means disabled)\n"
+"Use with caution as exceeding this will disable a server for a long time."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:260
+msgid ""
+"(2=interactive not supported)\n"
+"This doesn't currently do anything, but setting it to a value other than "
+"1 will cause an error."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:265
+msgid "How long to block on read, in milliseconds. Negative means indefinitely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:269
+msgid ""
+"When we're in slow start, we grow the window size at the rate\n"
+"of 1/(factor).  In standard TCP, window sizes are in bytes,\n"
+"while in I2P, window sizes are in messages.\n"
+"A higher number means slower growth."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:276
+msgid ""
+"How long to block on write/flush, in milliseconds. Negative means "
+"indefinitely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:284
+#: i2p2www/pages/site/docs/spec/streaming.html:10
+msgid "Protocol Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:286
+msgid "See the Streaming Library Specification page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:290
+msgid "Implementation Details"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:293
+msgid ""
+"The initiator sends a packet with the SYNCHRONIZE flag set. This packet "
+"may contain the initial data as well.\n"
+"The peer replies with a packet with the SYNCHRONIZE flag set. This packet"
+" may contain the initial response data as well."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:298
+msgid ""
+"The initiator may send additional data packets, up to the initial window "
+"size, before receiving the SYNCHRONIZE response.\n"
+"These packets will also have the send Stream ID field set to 0.\n"
+"Recipients must buffer packets received on unknown streams for a short "
+"period of time, as they may\n"
+"arrive out of order, in advance of the SYNCHRONIZE packet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:305
+msgid "MTU Selection and Negotiation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:306
+msgid ""
+"The maximum message size (also called the MTU / MRU) is negotiated to the"
+" lower value supported by\n"
+"the two peers. As tunnel messages are padded to 1KB, a poor MTU selection"
+" will lead to\n"
+"a large amount of overhead.\n"
+"The MTU is specified by the option i2p.streaming.maxMessageSize.\n"
+"The current default MTU of 1730 was chosen to fit precisely into two 1K "
+"I2NP tunnel messages,\n"
+"including overhead for the typical case."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:315
+msgid ""
+"The first message in a connection includes a 387 byte (typical) "
+"Destination added by the streaming layer,\n"
+"and usually a 898 byte (typical) LeaseSet, and Session keys, bundled in "
+"the Garlic message by the router.\n"
+"(The LeaseSet and Session Keys will not be bundled if an ElGamal Session "
+"was previously established).\n"
+"Therefore, the goal of fitting a complete HTTP request in a single 1KB "
+"I2NP message is not always attainable.\n"
+"However, the selection of the MTU, together with careful implementation "
+"of fragmentation\n"
+"and batching strategies in the tunnel gateway processor, are important "
+"factors in network bandwidth,\n"
+"latency, reliability, and efficiency, especially for long-lived "
+"connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:326
+#, python-format
+msgid ""
+"Data integrity is assured by the gzip CRC-32 checksum implemented in\n"
+"the I2CP layer.\n"
+"There is no checksum field in the streaming protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:334
+#, python-format
+msgid ""
+"Each packet is sent through I2P as a single message (or as an individual "
+"clove in a\n"
+"Garlic Message). Message encapsulation "
+"is implemented\n"
+"in the underlying I2CP, I2NP, and\n"
+"tunnel message layers. There is no "
+"packet delimiter\n"
+"mechanism or payload length field in the streaming protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:344
+msgid "Windowing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:345
+msgid ""
+"The streaming lib uses standard slow-start (exponential window growth) "
+"and congestion avoidance (linear window growth)\n"
+"phases, with exponential backoff.\n"
+"Windowing and acknowledgments use packet count, not byte count."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:352
+msgid "Close"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:353
+msgid ""
+"Any packet, including one with the SYNCHRONIZE flag set, may have the "
+"CLOSE flag sent as well.\n"
+"The connection is not closed until the peer responds with the CLOSE flag."
+"\n"
+"CLOSE packets may contain data as well."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:360
+msgid "Control Block Sharing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:361
+msgid ""
+"The streaming lib supports \"TCP\" Control Block sharing.\n"
+"This shares two important streaming lib parameters\n"
+"(window size and round trip time)\n"
+"across connections to the same remote peer.\n"
+"This is used for \"temporal\" sharing at connection open/close time,\n"
+"not \"ensemble\" sharing during a connection (See\n"
+"RFC 2140).\n"
+"There is a separate share per ConnectionManager (i.e. per local "
+"Destination)\n"
+"so that there is no information leakage to other Destinations on the\n"
+"same router.\n"
+"The share data for a given peer expires after a few minutes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:375
+msgid "Other Parameters"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:376
+msgid ""
+"The following parameters are hardcoded, but may be of interest for "
+"analysis:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:393
+#: i2p2www/pages/site/docs/how/network-database.html:785
+msgid "History"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:394
+msgid ""
+"The streaming library has grown organically for I2P - first mihi "
+"implemented the\n"
+"\"mini streaming library\" as part of I2PTunnel, which was limited to a "
+"window\n"
+"size of 1 message (requiring an ACK before sending the next one), and "
+"then it was\n"
+"refactored out into a generic streaming interface (mirroring TCP sockets)"
+" and the\n"
+"full streaming implementation was deployed with a sliding window protocol"
+" and \n"
+"optimizations to take into account the high bandwidth x delay product.  "
+"Individual\n"
+"streams may adjust the maximum packet size and other options. The default"
+"\n"
+"message size is selected to fit precisely in two 1K I2NP tunnel messages,"
+"\n"
+"and is a reasonable tradeoff between the bandwidth costs of \n"
+"retransmitting lost messages, and the latency and overhead of multiple "
+"messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:408
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:331
+#: i2p2www/pages/site/docs/how/garlic-routing.html:242
+#: i2p2www/pages/site/docs/how/network-database.html:790
+#: i2p2www/pages/site/docs/how/peer-selection.html:265
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:255
+#: i2p2www/pages/site/docs/protocol/i2cp.html:646
+#: i2p2www/pages/site/docs/protocol/i2np.html:235
+#: i2p2www/pages/site/docs/spec/updates.html:126
+#: i2p2www/pages/site/docs/transport/ntcp.html:445
+#: i2p2www/pages/site/docs/transport/ssu.html:482
+#: i2p2www/pages/site/docs/tunnels/implementation.html:503
+msgid "Future Work"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:409
+msgid ""
+"The behavior of the streaming library has a profound impact on\n"
+"application-level performance, and as such, is an important\n"
+"area for further analysis."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:415
+msgid "Additional tuning of the streaming lib parameters may be necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:418
+#, python-format
+msgid ""
+"Another area for research is the interaction of the streaming lib with "
+"the\n"
+"NTCP and SSU transport layers.\n"
+"See the NTCP discussion page for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:423
+msgid ""
+"The interaction of the routing algorithms with the streaming lib strongly"
+" affects performance.\n"
+"In particular, random distribution of messages to multiple tunnels in a "
+"pool\n"
+"leads to a high degree of out-of-order delivery which results in smaller "
+"window\n"
+"sizes than would otherwise be the case. The router currently routes \n"
+"messages for a single from/to destination pair through a consistent set \n"
+"of tunnels, until tunnel expiration or delivery failure. The router's \n"
+"failure and tunnel selection algorithms should be reviewed for possible \n"
+"improvements."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:433
+msgid "The data in the first SYN packet may exceed the receiver's MTU."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:436
+msgid "The DELAY_REQUESTED field could be used more."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:439
+msgid ""
+"Duplicate initial SYNCHRONIZE packets on short-lived streams may not be "
+"recognized and removed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:442
+msgid "Don't send the MTU in a retransmission."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:445
+msgid ""
+"Data is sent along unless the outbound window is full.\n"
+"(i.e. no-Nagle or TCP_NODELAY)\n"
+"Probably should have a configuration option for this."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:450
+msgid ""
+"zzz has added debug code to the streaming library to log packets in a "
+"wireshark-compatible\n"
+"(pcap) format; Use this to further analyze performance.\n"
+"The format may require enhancement to map more streaming lib parameters "
+"to TCP fields."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:455
+msgid ""
+"There are proposals to replace the streaming lib with standard TCP\n"
+"(or perhaps a null layer together with raw sockets).\n"
+"This would unfortunately be incompatible with the streaming lib\n"
+"but it would be good to compare the performance of the two."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:3
+#: i2p2www/pages/site/docs/spec/configuration.html:3
+msgid "September 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:7
+msgid ""
+"There are several bittorrent clients and trackers on I2P.\n"
+"As I2P addressing uses a Destination instead of an IP and port, minor\n"
+"changes are required to tracker and client software for operation on I2P."
+"\n"
+"These changes are specified below.\n"
+"Note carefully the guidelines for compatibility with older I2P clients "
+"and trackers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:15
+msgid ""
+"This page specifies protocol details common to all clients and trackers.\n"
+"Specific clients and trackers may implement other unique features or "
+"protocols."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:20
+msgid "We welcome additional ports of client and tracker software to I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:26
+msgid "Announces"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:27
+msgid ""
+"Clients generally include a fake port=6881 parameter in the announce, for"
+" compatibility with older trackers.\n"
+"Trackers may ignore the port parameter, and should not require it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:32
+#, python-format
+msgid ""
+"The ip parameter is the base 64 of the client's\n"
+"Destination,\n"
+"using the I2P Base 64 alphabet [A-Z][a-z][0-9]-~.\n"
+"Destinations\n"
+"are 387+ bytes, so the Base 64 is 516+ bytes.\n"
+"Clients generally append \".i2p\" to the Base 64 Destination for "
+"compatibility with older trackers.\n"
+"Trackers should not require an appended \".i2p\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:42
+msgid "Other parameters are the same as in standard bittorrent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:46
+msgid ""
+"While all current Destinations for clients are exactly 387 bytes, a "
+"tracker should not\n"
+"presume that will always be so. A reasonable maximum to assume, for now, "
+"is 475 bytes.\n"
+"As the tracker must decode the Base64 to deliver compact responses (see "
+"below),\n"
+"the tracker should probably decode and reject bad Base64 when announced."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:53
+msgid ""
+"The default response type is non-compact. Clients may request a compact "
+"response with\n"
+"the parameter compact=1. A tracker may, but is not required to, return\n"
+"a compact response when requested."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:59
+msgid ""
+"Developers of new I2P clients\n"
+"are strongly encouraged to implemenent announces over their own tunnel "
+"rather than\n"
+"the HTTP client proxy at port 4444. Doing so is both more efficient and "
+"it allows\n"
+"destination enforcement by the tracker (see below)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:66
+msgid ""
+"There are no known I2P clients or trackers that currently support UDP "
+"announce/responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:71
+msgid "Non-Compact Tracker Responses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:72
+msgid ""
+"The non-compact response is just as in standard bittorrent, with an I2P "
+"\"ip\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:76
+msgid ""
+"Trackers generally include a fake port key, or use the port from the "
+"announce, for compatibility with older clients.\n"
+"Clients must ignore the port parameter, and should not require it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:81
+#, python-format
+msgid ""
+"The value of the ip key is the base 64 of the client's\n"
+"Destination, as "
+"described above.\n"
+"Trackers generally append \".i2p\" to the Base 64 Destination if it "
+"wasn't in the announce ip, for compatibility with older clients.\n"
+"Clients should not require an appended \".i2p\" in the responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:88
+msgid "Other response keys and values are the same as in standard bittorrent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:94
+msgid "Compact Tracker Responses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:95
+#, python-format
+msgid ""
+"In the compact response, the value of the \"peers\" dictionary key is a "
+"single byte string,\n"
+"whose length is a multiple of 32 bytes.\n"
+"This string contains the concatenated\n"
+"32-byte SHA-256 Hashes\n"
+"of the binary\n"
+"Destinations\n"
+"of the peers.\n"
+"This hash must be computed by the tracker, unless destination enforcement"
+"\n"
+"(see below) is used, in which case the hash delivered in the X-I2P-"
+"DestHash\n"
+"or X-I2P-DestB32 HTTP headers may be converted to binary and stored.\n"
+"The peers key may be absent, or the peers value may be zero-length."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:109
+msgid ""
+"While compact response support is optional for both clients and trackers,"
+" it is highly\n"
+"recommended as it reduces the nominal response size by over 90%."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:116
+msgid "Destination Enforcement"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:117
+#, python-format
+msgid ""
+"Some, but not all, I2P bittorrent clients announce over their own "
+"tunnels.\n"
+"Trackers may choose to prevent spoofing by requiring this, and verifying "
+"the\n"
+"client's\n"
+"Destination\n"
+"using HTTP headers added by the I2PTunnel HTTP Server tunnel.\n"
+"The headers are X-I2P-DestHash, X-I2P-DestB64, and X-I2P-DestB32, which "
+"are\n"
+"different formats for the same information.\n"
+"These headers cannot be spoofed by the client.\n"
+"A tracker enforcing destinations need not require the ip announce "
+"parameter at all."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:129
+msgid ""
+"As several clients use the HTTP proxy instead of their own tunnel for "
+"announces,\n"
+"destination enforcement will prevent usage by those clients unless or "
+"until\n"
+"those clients are converted to announcing over their own tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:135
+msgid ""
+"Unfortunately, as the network grows, so will the amount of maliciousness,"
+"\n"
+"so we expect that all trackers will eventually enforce destinations.\n"
+"Both tracker and client developers should anticipate it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:143
+msgid "Announce Host Names"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:144
+#, python-format
+msgid ""
+"Announce URL host names in torrent files generally follow the\n"
+"I2P naming standards.\n"
+"In addition to host names from address books and \".b32.i2p\" Base 32 "
+"hostnames,\n"
+"the full Base 64 Destination (with [or without?] \".i2p\" appended) "
+"should be supported.\n"
+"Non-open trackers should recognize their own host name in any of these "
+"formats."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:152
+msgid ""
+"To preserve anonymity,\n"
+"clients should generally ignore non-I2P announce URLs in torrent files."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:159
+msgid "Client Connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:160
+msgid ""
+"Client-to-client connections use the standard protocol over TCP.\n"
+"There are no known I2P clients that currently support uTP communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:165
+#, python-format
+msgid ""
+"I2P uses 387+ byte Destinations\n"
+"for addresses, as explained above."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:170
+msgid ""
+"If the client has only the hash of the destination (such as from a "
+"compact response or PEX), it must perform a lookup\n"
+"by encoding it with Base 32, appending \".b32.i2p\", and querying the "
+"Naming Service,\n"
+"which will return the full Destination if available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:176
+msgid ""
+"If the client has a peer's full Destination it received in a non-compact "
+"response, it should use it\n"
+"directly in the connection setup.\n"
+"Do not convert a Destination back to a Base 32 hash for lookup, this is "
+"quite inefficient."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:183
+msgid "Cross-Network Prevention"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:184
+msgid ""
+"To preserve anonymity,\n"
+"I2P bittorrent clients generally do not support non-I2P announces or peer"
+" connections.\n"
+"I2P HTTP outproxies often block announces.\n"
+"There are no known SOCKS outproxies supporting bittorrent traffic."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:191
+msgid ""
+"To prevent usage by non-I2P clients via an HTTP inproxy, I2P trackers "
+"often\n"
+"block accesses or announces that contain an X-Forwarded-For HTTP header.\n"
+"Trackers should reject standard network announces with IPv4 or IPv6 IPs, "
+"and not deliver them in responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:200
+#, python-format
+msgid ""
+"I2P PEX is based on ut_pex.\n"
+"As there does not appear to be a formal specification of ut_pex "
+"available,\n"
+"it may be necessary to review the libtorrent source for assistance.\n"
+"It is an extension message, identified as \"i2p_pex\" in\n"
+"the extension "
+"handshake.\n"
+"It contains a bencoded dictionary with up to 3 keys, \"added\", "
+"\"added.f\", and \"dropped\".\n"
+"The added and dropped values are each a single byte string, whose length "
+"is a multiple of 32 bytes.\n"
+"These byte strings are the concatenated SHA-256 Hashes of the binary\n"
+"Destinations\n"
+"of the peers.\n"
+"This is the same format as the peers dictionary value in the i2p compact "
+"response format specified above.\n"
+"The added.f value, if present, is the same as in ut_pex."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:218
+msgid ""
+"DHT support is included in the i2psnark client as of version 0.9.2.\n"
+"Preliminary differences from\n"
+"BEP 5\n"
+"are described below, and are subject to change.\n"
+"Contact the I2P developers if you wish to develop a client supporting DHT."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:226
+msgid ""
+"Unlike standard DHT, I2P DHT does not use a bit in the options handshake,"
+" or the PORT message.\n"
+"It is advertised with an extension message, identified as \"i2p_dht\" in\n"
+"the extension "
+"handshake.\n"
+"It contains a bencoded dictionary with two keys, \"port\" and \"rport\", "
+"both integers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:233
+msgid ""
+"The UDP (datagram) port listed in the compact node info is used\n"
+"to receive repliable (signed) datagrams.\n"
+"This is used for queries, except for announces.\n"
+"We call this the \"query port\".\n"
+"This is the \"port\" value from the extension message.\n"
+"Queries use I2CP protocol number 17."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:242
+msgid ""
+"In addition to that UDP port, we use a second datagram\n"
+"port equal to the query port + 1. This is used to receive\n"
+"unsigned (raw) datagrams for replies, errors, and announces.\n"
+"This port provides increased efficiency since replies\n"
+"contain tokens sent in the query, and need not be signed.\n"
+"We call this the \"response port\".\n"
+"This is the \"rport\" value from the extension message.\n"
+"It must be 1 + the query port.\n"
+"Responses and announces use I2CP protocol number 18."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:254
+msgid ""
+"Compact peer info is 32 bytes (32 byte SHA256 Hash)\n"
+"instead of 4 byte IP + 2 byte port. There is no peer port.\n"
+"In a response, the \"values\" key is a list of strings, each containing a"
+" single compact peer info."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:260
+msgid ""
+"Compact node info is 54 bytes (20 byte SHA1 Hash + 32 byte SHA256 Hash + "
+"2 byte port)\n"
+"instead of 20 byte SHA1 Hash + 4 byte IP + 2 byte port.\n"
+"In a response, the \"nodes\" key is a\n"
+"single byte string with concatenated compact node info."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:267
+msgid ""
+"Secure node ID requirement: To make various DHT attacks more difficult,\n"
+"the first 4 bytes of the Node ID must match the first 4 bytes of the "
+"destination Hash,\n"
+"and the next two bytes of the Node ID must match the next two bytes of "
+"the\n"
+"destination hash exclusive-ORed with the port."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:274
+msgid ""
+"In a torrent file,\n"
+"the trackerless torrent dictionary \"nodes\" key is TBD.\n"
+"It could be a list of\n"
+"32 byte binary strings (SHA256 Hashes) instead of a list of lists\n"
+"containing a host string and a port integer.\n"
+"Alternatives: A single byte string with concatenated hashes,\n"
+"or a list of strings alone."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:285
+#: i2p2www/pages/site/docs/how/intro.html:187
+msgid "Additional Information"
+msgstr "Información adicional"
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:287
+#, python-format
+msgid ""
+"I2P bittorrent standards are generally discussed on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:290
+#, python-format
+msgid ""
+"A chart of current tracker software capabilities is also available there."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:293
+#, python-format
+msgid ""
+"The\n"
+"I2P bittorrent FAQ"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:297
+#, python-format
+msgid "DHT on I2P discussion"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:2
+#: i2p2www/pages/site/docs/applications/supported.html:5
+msgid "Supported Applications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:9
+#: i2p2www/pages/site/docs/applications/supported.html:186
+msgid "Blogging, Forums, and Wikis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:11
+#: i2p2www/pages/site/docs/applications/supported.html:232
+msgid "Decentralized File Storage"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:14
+#: i2p2www/pages/site/docs/applications/supported.html:244
+msgid "Development Tools"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:17
+#: i2p2www/pages/site/docs/applications/supported.html:246
+msgid "Version control"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:21
+#: i2p2www/pages/site/docs/applications/supported.html:265
+msgid "Domain Naming"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:23
+#: i2p2www/pages/site/docs/applications/supported.html:283
+msgid "Email"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:26
+#: i2p2www/pages/site/docs/applications/supported.html:315
+msgid "File Sharing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:29
+#: i2p2www/pages/site/docs/applications/supported.html:317
+msgid "BitTorrent clients"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:31
+#: i2p2www/pages/site/docs/applications/supported.html:359
+msgid "BitTorrent trackers and indexers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:40
+#: i2p2www/pages/site/docs/applications/supported.html:426
+msgid "Network Administration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:43
+#: i2p2www/pages/site/docs/applications/supported.html:428
+msgid "General-purpose socket utilities"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:50
+#: i2p2www/pages/site/docs/applications/supported.html:469
+msgid "Real-time Chat"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:53
+#: i2p2www/pages/site/docs/applications/supported.html:471
+msgid "Instant messaging clients"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:55
+#: i2p2www/pages/site/docs/applications/supported.html:481
+msgid "IRC clients"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:57
+#: i2p2www/pages/site/docs/applications/supported.html:532
+msgid "IRC servers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:62
+#: i2p2www/pages/site/docs/applications/supported.html:548
+msgid "Web Browsing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:65
+#: i2p2www/pages/site/docs/applications/supported.html:550
+msgid "Anonymous websites"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:67
+#: i2p2www/pages/site/docs/applications/supported.html:599
+msgid "Proxy software"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:69
+#: i2p2www/pages/site/docs/applications/supported.html:624
+msgid "Inproxies"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:71
+#: i2p2www/pages/site/docs/applications/supported.html:640
+msgid "Outproxies"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:76
+#: i2p2www/pages/site/docs/applications/supported.html:654
+msgid "Website Hosting"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:79
+#: i2p2www/pages/site/docs/applications/supported.html:669
+msgid "Web servers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:85
+#, python-format
+msgid ""
+"This is intended to be a comprehensive listing of applications used with\n"
+"I2P. If you know of something that's missing please submit a ticket on\n"
+"Trac, and be sure to select the"
+"\n"
+"“www” component in the submission form."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:92
+msgid ""
+"\n"
+"Supported applications are tagged with one or more of the following:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:97
+#: i2p2www/pages/site/docs/applications/supported.html:279
+#: i2p2www/pages/site/docs/applications/supported.html:311
+#: i2p2www/pages/site/docs/applications/supported.html:323
+#: i2p2www/pages/site/docs/applications/supported.html:666
+msgid "bundled"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:100
+msgid ""
+"Bundled application — I2P ships with a few officially\n"
+"supported applications that let new users take immediate advantage of\n"
+"some of I2P's more useful capabilities."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:107
+#: i2p2www/pages/site/docs/applications/supported.html:195
+#: i2p2www/pages/site/docs/applications/supported.html:208
+#: i2p2www/pages/site/docs/applications/supported.html:220
+#: i2p2www/pages/site/docs/applications/supported.html:228
+#: i2p2www/pages/site/docs/applications/supported.html:241
+#: i2p2www/pages/site/docs/applications/supported.html:292
+#: i2p2www/pages/site/docs/applications/supported.html:391
+#: i2p2www/pages/site/docs/applications/supported.html:413
+#: i2p2www/pages/site/docs/applications/supported.html:422
+#: i2p2www/pages/site/docs/applications/supported.html:510
+msgid "plugin"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:110
+#, python-format
+msgid ""
+"Third-party plugin — I2P's plugin system provides convenient\n"
+"deployment of I2P-enabled applications and allows tighter integration\n"
+"with the router. Plugins are [reviewed by the community](http://%(plugins)s) to identify security and\n"
+"anonymity issues."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:121
+#: i2p2www/pages/site/docs/applications/supported.html:220
+#: i2p2www/pages/site/docs/applications/supported.html:228
+#: i2p2www/pages/site/docs/applications/supported.html:241
+#: i2p2www/pages/site/docs/applications/supported.html:252
+#: i2p2www/pages/site/docs/applications/supported.html:261
+#: i2p2www/pages/site/docs/applications/supported.html:329
+#: i2p2www/pages/site/docs/applications/supported.html:340
+#: i2p2www/pages/site/docs/applications/supported.html:355
+#: i2p2www/pages/site/docs/applications/supported.html:401
+#: i2p2www/pages/site/docs/applications/supported.html:413
+#: i2p2www/pages/site/docs/applications/supported.html:422
+#: i2p2www/pages/site/docs/applications/supported.html:437
+#: i2p2www/pages/site/docs/applications/supported.html:443
+#: i2p2www/pages/site/docs/applications/supported.html:449
+#: i2p2www/pages/site/docs/applications/supported.html:459
+#: i2p2www/pages/site/docs/applications/supported.html:465
+#: i2p2www/pages/site/docs/applications/supported.html:477
+#: i2p2www/pages/site/docs/applications/supported.html:510
+#: i2p2www/pages/site/docs/applications/supported.html:516
+#: i2p2www/pages/site/docs/applications/supported.html:522
+#: i2p2www/pages/site/docs/applications/supported.html:528
+#: i2p2www/pages/site/docs/applications/supported.html:605
+#: i2p2www/pages/site/docs/applications/supported.html:614
+#: i2p2www/pages/site/docs/applications/supported.html:620
+#: i2p2www/pages/site/docs/applications/supported.html:666
+#: i2p2www/pages/site/docs/applications/supported.html:681
+#: i2p2www/pages/site/docs/applications/supported.html:687
+#: i2p2www/pages/site/docs/applications/supported.html:693
+#: i2p2www/pages/site/docs/applications/supported.html:699
+msgid "standalone"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:121
+#: i2p2www/pages/site/docs/applications/supported.html:195
+#: i2p2www/pages/site/docs/applications/supported.html:202
+#: i2p2www/pages/site/docs/applications/supported.html:208
+#: i2p2www/pages/site/docs/applications/supported.html:214
+#: i2p2www/pages/site/docs/applications/supported.html:349
+#: i2p2www/pages/site/docs/applications/supported.html:373
+#: i2p2www/pages/site/docs/applications/supported.html:382
+#: i2p2www/pages/site/docs/applications/supported.html:538
+#: i2p2www/pages/site/docs/applications/supported.html:544
+msgid "standalone/mod"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:124
+msgid ""
+"Third-party standalone application — Many standard network\n"
+"applications only require careful setup and configuration to communicate\n"
+"anonymously over I2P. These are tagged with standalone. Some\n"
+"applications, tagged with standalone/mod, require patching to\n"
+"function properly over I2P or to prevent inadvertent disclosure of\n"
+"identifying information such as the user's hostname or external IP\n"
+"address."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:135
+#: i2p2www/pages/site/docs/applications/supported.html:302
+#: i2p2www/pages/site/docs/applications/supported.html:558
+#: i2p2www/pages/site/docs/applications/supported.html:568
+#: i2p2www/pages/site/docs/applications/supported.html:577
+#: i2p2www/pages/site/docs/applications/supported.html:583
+#: i2p2www/pages/site/docs/applications/supported.html:589
+#: i2p2www/pages/site/docs/applications/supported.html:595
+#: i2p2www/pages/site/docs/applications/supported.html:636
+#: i2p2www/pages/site/docs/applications/supported.html:650
+msgid "service"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:138
+msgid ""
+"Third-party essential network service — Services which on\n"
+"the I2P network are analogous to those provided on the public Internet\n"
+"by hosting providers, ISPs, and Google: eepsite indexes and jump\n"
+"services, search engines, email, DNS-style name services, hosting,\n"
+"proxies, etc. These services focus on boosting the usefulness of the\n"
+"network as a whole, and making network content more discoverable."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:148
+#: i2p2www/pages/site/docs/applications/supported.html:220
+#: i2p2www/pages/site/docs/applications/supported.html:355
+msgid "unmaintained"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:151
+msgid ""
+"Unmaintained — This is used to tag plugins, applications,\n"
+"and services which appear to be unmaintained and may be removed from\n"
+"this listing in the future."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:159
+#, python-format
+msgid ""
+"Warning: Using an application, plugin, or service with I2P\n"
+"doesn't automatically protect your anonymity. I2P is merely a set of "
+"tools\n"
+"which can help you mitigate certain identified\n"
+"threats to anonymity. We do not and cannot make any guarantees about "
+"the\n"
+"safety of the applications, plugins, and services listed below. Most\n"
+"applications and plugins must be properly configured, and some will need "
+"to\n"
+"be patched — and even then your anonymity might not be assured. "
+"Similarly,\n"
+"services could put your anonymity at risk, either by design or through\n"
+"carelessness on their part or your own."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:171
+msgid ""
+"If you have doubts about the suitability of an application,\n"
+"plugin, or service for use with I2P, you are urged to inquire about "
+"privacy\n"
+"issues with its maintainers, to search its mailing lists and bug tracker "
+"if\n"
+"one exists, and consult trusted, knowledgeable members of the I2P\n"
+"community."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:179
+msgid ""
+"Take responsibility for your own anonymity and safety — always\n"
+"seek expert advice, educate yourself, practice good judgment, be mindful "
+"of\n"
+"disclosing personally identifying information, and don't take\n"
+"shortcuts."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:201
+msgid "Lightweight forum software."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:207
+msgid "Another lightweight blogging platform."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:213
+msgid "Most popular open source forum software."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:219
+msgid "Distributed forums software, originally developed by jrandom."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:224
+#, python-format
+msgid ""
+"A Java-based MediaWiki clone. No external database needed.\n"
+"Plugin available here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:236
+#, python-format
+msgid ""
+"Port of the Tahoe-"
+"LAFS\n"
+"distributed file system to the I2P network. Controller plugin here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:251
+msgid "Most popular distributed version control system."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:257
+#, python-format
+msgid ""
+"Another distributed version control system. Currently\n"
+"used in I2P development."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:269
+#, python-format
+msgid ""
+"Provides management of addressbooks, which are part of a simple,\n"
+"user-controlled I2P naming system somewhat\n"
+"analogous to the Internet's Domain Name System (DNS). Addressbooks map\n"
+"Base64 destinations to short, usually human-readable “domain” names "
+"ending\n"
+"with a .i2p suffix which the I2P router's HTTP client can resolve back to"
+"\n"
+"Base64 addresses. (Note: While Base64 destinations are globally\n"
+"unique, addressbook “domain” names only resolve to unique destinations\n"
+"locally.)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:288
+msgid ""
+"Serverless peer-to-peer email application using a distributed hash table\n"
+"(DHT) for secure mail storage."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:297
+msgid ""
+"Provides email service within the I2P network via @mail.i2p addresses,\n"
+"and email gateway service between the I2P network and the public Internet"
+"\n"
+"via @i2pmail.org addresses. One of the oldest continuous services on I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:307
+msgid ""
+"Simple web browser-based email interface. Configured to use Postman's\n"
+"email service by default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:322
+msgid "I2P's integrated BitTorrent client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:328
+msgid "Modified version of I2PSnark."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:334
+msgid ""
+"\n"
+"A fork of rufus that uses the Basic Open Bridge (BOB) and has many\n"
+"improvements, including using the latest wxwidgets and python. It also\n"
+"supports use of seedless if installed for trackerless torrents and\n"
+"magnet-link like fetching of torrents within I2P.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:345
+msgid ""
+"Clean, full-featured cross-platform BitTorrent client with official\n"
+"ports for several GUI toolkits."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:354
+msgid "Has a plugin providing I2P support."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:361
+#, python-format
+msgid ""
+"For a detailed feature comparison of I2P-enabled trackers/indexers, see\n"
+"here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:369
+msgid ""
+"The code that powered one of the first major tracker/indexer sites on the"
+"\n"
+"Internet. Patched for I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:378
+#, python-format
+msgid ""
+"Lightweight tracker/indexer. I2P mod available in the i2p.opentracker\n"
+"branch of the I2P Monotone repository."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:387
+#, python-format
+msgid ""
+"zzz's Java-based open tracker. More info\n"
+"here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:400
+msgid "I2P port of the aMule ED2K client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:409
+#, python-format
+msgid ""
+"Port of the Phex Gnutella "
+"client. Website\n"
+"for plugin version here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:418
+#, python-format
+msgid ""
+"Cache for Gnutella peers on I2P. Website for plugin version\n"
+"here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:433
+msgid ""
+"Unix standard tool for socket relaying. Several clones, ports, and forks\n"
+"have appeared over the years."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:442
+msgid "Like netcat but more powerful."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:448
+msgid ""
+"Proxy providing simple, transparent SOCKS-ification of network "
+"applications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:458
+msgid ""
+"Most popular implementation of the Secure Shell (SSH) protocol and "
+"related tools."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:464
+msgid "Open source Secure Shell (SSH) client for Windows."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:476
+msgid "IM client with multiple incarnations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:483
+msgid ""
+"Many IRC clients leak identifying information to servers or other\n"
+"clients, so I2P's IRC and SOCKS IRC client tunnels filter certain inbound"
+"\n"
+"and outbound messages to scrub data such as LAN IP addresses, external IP"
+"\n"
+"addresses, local hostnames, and the name and version of the IRC client. "
+"Two\n"
+"message types in particular, DCC and CTCP, can't be sufficiently "
+"anonymized\n"
+"without changes to the protocols or to IRC client/server code, so they "
+"are\n"
+"completely blocked, except for CTCP ACTION (the message emitted by the\n"
+"/me command) which isn't inherently dangerous."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:494
+msgid ""
+"I2P's IRC filtering may not cover every possible leak — users should also"
+"\n"
+"check if their client is sending their real name or local username. "
+"Packet\n"
+"sniffers such as Wireshark are\n"
+"useful here. Eliminating remaining leaks may be as simple as changing the"
+"\n"
+"client's default configuration. If that doesn't help, inform the I2P\n"
+"developers; they may be able to solve it via additional filtering."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:506
+#, python-format
+msgid ""
+"Small Java-based IRC client. Plugin available here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:515
+msgid "Cross-platform graphical IRC client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:521
+msgid "Unixy terminal-based IRC client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:527
+msgid "Another Unixy terminal-based IRC client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:537
+msgid "IRC server developed from scratch."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:543
+msgid "Most popular IRC server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:555
+msgid ""
+"Any website hosted anonymously on I2P, reachable through the I2P router's"
+" HTTP proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:563
+msgid ""
+"Distributed anonymous websites hosted\n"
+"using Tahoe-LAFS-I2P, currently only reachable with Tahoe-LAFS-I2P\n"
+"clients or through the Tahoe-LAFS-I2P HTTP proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:573
+#, python-format
+msgid ""
+"Website for sponge's jump service.\n"
+"Source code available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:582
+msgid "Another jump service."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:588
+msgid "Dynamically updated eepsite index."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:594
+#, python-format
+msgid "Website for zzz's jump service."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:604
+msgid "SOCKS-enabled caching web proxy with basic filtering capabilities."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:610
+msgid ""
+"Privacy-focused non-caching web proxy with advanced filtering\n"
+"capabilities. Excels at removing ads and other junk."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:619
+msgid "Venerable caching web proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:626
+msgid "Gateways allowing users on the public Internet to access eepsites."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:633
+#, python-format
+msgid "tino's inproxy on the public Internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:642
+msgid ""
+"Gateways allowing I2P users to access content hosted on the public "
+"Internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:649
+msgid "Publicly advertised outproxy running Squid, located in Germany."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:659
+msgid ""
+"Lightweight web server and Java servlet container. I2P is tightly\n"
+"integrated with a bundled copy of Jetty which by default is configured to"
+"\n"
+"host the user's eepsite. The "
+"bundled\n"
+"Jetty also serves the I2P router console and web applications bundled "
+"with\n"
+"I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:671
+msgid ""
+"In addition to Jetty, any web server should function over I2P without\n"
+"modification so long as it's HTTP-compliant. Some web servers known to\n"
+"currently serve content on the I2P network are:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:680
+msgid "Most popular web server on the public WWW."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:686
+msgid "Web server and Java servlet container. More features than Jetty."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:692
+msgid "Fast lightweight web server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:698
+msgid "High-performance lightweight web server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:2
+msgid "Naming discussion"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:4
+#, python-format
+msgid ""
+"NOTE: The following is a discussion of the reasons behind the I2P naming "
+"system,\n"
+"common arguments and possible alternatives.\n"
+"See the naming page for current documentation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:10
+msgid "Discarded alternatives"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:12
+msgid ""
+"Naming within I2P has been an oft-debated topic since the very beginning "
+"with\n"
+"advocates across the spectrum of possibilities.  However, given I2P's "
+"inherent\n"
+"demand for secure communication and decentralized operation, the "
+"traditional\n"
+"DNS-style naming system is clearly out, as are \"majority rules\" voting "
+"systems."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:19
+msgid ""
+"I2P does not promote the use of DNS-like services though, as the damage "
+"done\n"
+"by hijacking a site can be tremendous - and insecure destinations have no"
+"\n"
+"value.  DNSsec itself still falls back on registrars and certificate "
+"authorities,\n"
+"while with I2P, requests sent to a destination cannot be intercepted or "
+"the reply\n"
+"spoofed, as they are encrypted to the destination's public keys, and a "
+"destination\n"
+"itself is just a pair of public keys and a certificate.  DNS-style "
+"systems on the\n"
+"other hand allow any of the name servers on the lookup path to mount "
+"simple denial\n"
+"of service and spoofing attacks.  Adding on a certificate authenticating "
+"the\n"
+"responses as signed by some centralized certificate authority would "
+"address many of\n"
+"the hostile nameserver issues but would leave open replay attacks as well"
+" as \n"
+"hostile certificate authority attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:33
+msgid ""
+"Voting style naming is dangerous as well, especially given the "
+"effectiveness of\n"
+"Sybil attacks in anonymous systems - the attacker can simply create an "
+"arbitrarily\n"
+"high number of peers and \"vote\" with each to take over a given name.  "
+"Proof-of-work\n"
+"methods can be used to make identity non-free, but as the network grows "
+"the load\n"
+"required to contact everyone to conduct online voting is implausible, or "
+"if the\n"
+"full network is not queried, different sets of answers may be reachable."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:42
+msgid ""
+"As with the Internet however, I2P is keeping the design and operation of "
+"a \n"
+"naming system out of the (IP-like) communication layer.  The bundled "
+"naming library\n"
+"includes a simple service provider interface which alternate naming systems can\n"
+"plug into, allowing end users to drive what sort of naming tradeoffs they"
+" prefer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:50
+msgid ""
+"See also Names: "
+"Decentralized, Secure, Human-Meaningful: Choose Two."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:55
+msgid "(adapted from a post in the old Syndie, November 26, 2005)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:58
+msgid ""
+"Q:\n"
+"What to do if some hosts \n"
+"do not agree on one address and if some addresses are working, others are"
+" not? \n"
+"Who is the right source of a name?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:64
+msgid ""
+"A:\n"
+"You don't. This is actually a critical difference between names on I2P "
+"and how \n"
+"DNS works - names in I2P are human readable, secure, but not globally"
+" \n"
+"unique.  This is by design, and an inherent part of our need for "
+"security."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:70
+msgid ""
+"If I could somehow convince you to change the destination associated with"
+" some \n"
+"name, I'd successfully \"take over\" the site, and under no circumstances"
+" is that \n"
+"acceptable.  Instead, what we do is make names locally unique: "
+"they are \n"
+"what you use to call a site, just as how you can call things "
+"whatever \n"
+"you want when you add them to your browser's bookmarks, or your IM "
+"client's \n"
+"buddy list.  Who you call \"Boss\" may be who someone else calls "
+"\"Sally\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:78
+msgid "Names will not, ever, be securely human readable and globally unique."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:83
+msgid ""
+"The following from zzz is a review of several common\n"
+"complaints about I2P's naming system."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:89
+msgid ""
+"Inefficiency:\n"
+"The whole hosts.txt is downloaded (if it has changed, since eepget uses "
+"the etag and last-modified headers).\n"
+"It's about 400K right now for almost 800 hosts."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:94
+msgid ""
+"True, but this isn't a lot of traffic in the context of i2p, which is "
+"itself wildly inefficient\n"
+"(floodfill databases, huge encryption overhead and padding, garlic "
+"routing, etc.).\n"
+"If you downloaded a hosts.txt file from someone every 12 hours it "
+"averages out to about 10 bytes/sec."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:99
+msgid ""
+"As is usually the case in i2p, there is a fundamental tradeoff here "
+"between anonymity and efficiency.\n"
+"Some would say that using the etag and last-modified headers is hazardous"
+" because it exposes when you\n"
+"last requested the data.\n"
+"Others have suggested asking for specific keys only (similar to what jump"
+" services do, but\n"
+"in a more automated fashion), possibly at a further cost in anonymity."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:106
+#, python-format
+msgid ""
+"Possible improvements would be a replacement or supplement to addressbook"
+" (see %(i2host)sp),\n"
+"or something simple like subscribing to http://example.i2p/cgi-"
+"bin/recenthosts.cgi rather than http://example.i2p/hosts.txt.\n"
+"If a hypothetical recenthosts.cgi distributed all hosts from the last 24 "
+"hours, for example,\n"
+"that could be both more efficient and more anonymous than the current "
+"hosts.txt with last-modified and etag."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:112
+#, python-format
+msgid ""
+"A sample implementation is on stats.i2p at\n"
+"%(url)s.\n"
+"This script returns an Etag with a timestamp.\n"
+"When a request comes in with the If-None-Match etag,\n"
+"the script ONLY returns new hosts since that timestamp, or 304 Not "
+"Modified if there are none.\n"
+"In this way, the script efficiently returns only the hosts the subscriber"
+"\n"
+"does not know about, in an addressbook-compatible manner."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:121
+msgid ""
+"So the inefficiency is not a big issue and there are several ways to "
+"improve things without\n"
+"radical change."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:127
+msgid ""
+"Not Scalable:\n"
+"The 400K hosts.txt (with linear search) isn't that big at the moment and\n"
+"we can probably grow by 10x or 100x before it's a problem."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:132
+msgid ""
+"As far as network traffic see above.\n"
+"But unless you're going to do a slow real-time query over the network for"
+"\n"
+"a key, you need to have the whole set of keys stored locally, at a cost "
+"of about 500 bytes per key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:139
+msgid ""
+"Requires configuration and \"trust\":\n"
+"Out-of-the-box addressbook is only subscribed to "
+"http://www.i2p2.i2p/hosts.txt, which is rarely updated,\n"
+"leading to poor new-user experience."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:144
+msgid ""
+"This is very much intentional. jrandom wants a user to \"trust\" a "
+"hosts.txt\n"
+"provider, and as he likes to say, \"trust is not a boolean\".\n"
+"The configuration step attempts to force users to think about issues of "
+"trust in an anonymous network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:149
+msgid ""
+"As another example, the \"Eepsite Unknown\" error page in the HTTP Proxy\n"
+"lists some jump services, but doesn't \"recommend\" any one in "
+"particular,\n"
+"and it's up to the user to pick one (or not).\n"
+"jrandom would say we trust the listed providers enough to list them but "
+"not enough to\n"
+"automatically go fetch the key from them."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:156
+msgid ""
+"How successful this is, I'm not sure.\n"
+"But there must be some sort of hierarchy of trust for the naming system.\n"
+"To treat everyone equally may increase the risk of hijacking."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:163
+msgid "It isn't DNS"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:166
+msgid ""
+"Unfortunately real-time lookups over i2p would significantly slow down "
+"web browsing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:169
+msgid ""
+"Also, DNS is based on lookups with limited caching and time-to-live, "
+"while i2p\n"
+"keys are permanent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:173
+msgid "Sure, we could make it work, but why? It's a bad fit."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:178
+msgid ""
+"Not reliable:\n"
+"It depends on specific servers for addressbook subscriptions."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:182
+msgid ""
+"Yes it depends on a few servers that you have configured.\n"
+"Within i2p, servers and services come and go.\n"
+"Any other centralized system (for example DNS root servers) would\n"
+"have the same problem. A completely decentralized system (everybody is "
+"authoritative)\n"
+"is possible by implementing an \"everybody is a root DNS server\" "
+"solution, or by\n"
+"something even simpler, like a script that adds everybody in your "
+"hosts.txt to your addressbook."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:190
+msgid ""
+"People advocating all-authoritative solutions generally haven't thought "
+"through\n"
+"the issues of conflicts and hijacking, however."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:196
+msgid ""
+"Awkward, not real-time:\n"
+"It's a patchwork of hosts.txt providers, key-add web form providers, jump"
+" service providers,\n"
+"eepsite status reporters.\n"
+"Jump servers and subscriptions are a pain, it should just work like DNS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:202
+msgid "See the reliability and trust sections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:207
+msgid ""
+"So, in summary, the current system is not horribly broken, inefficient, "
+"or un-scalable,\n"
+"and proposals to \"just use DNS\" aren't well thought-through."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:212
+msgid "Alternatives"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:213
+msgid ""
+"The I2P source contains several pluggable naming systems and supports "
+"configuration options\n"
+"to enable experimentation with naming systems."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:218
+msgid ""
+"Meta - calls two or more other naming systems in order.\n"
+"By default, calls PetName then HostsTxt."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:222
+msgid ""
+"PetName - Looks up in a petnames.txt file.\n"
+"The format for this file is NOT the same as hosts.txt."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:226
+msgid "HostsTxt - Looks up in the following files, in order:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:234
+msgid ""
+"AddressDB - Each host is listed in a separate file in a addressDb/"
+" directory."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:237
+msgid ""
+"Eepget - does an HTTP lookup request from an external\n"
+"server - must be stacked after the HostsTxt lookup with Meta.\n"
+"This could augment or replace the jump system.\n"
+"Includes in-memory caching."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:243
+msgid ""
+"Exec - calls an external program for lookup, allows\n"
+"additional experimentation in lookup schemes, independent of java.\n"
+"Can be used after HostsTxt or as the sole naming system.\n"
+"Includes in-memory caching."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:249
+msgid "Dummy - used as a fallback for Base64 names, otherwise fails."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:253
+msgid ""
+"The current naming system can be changed with the advanced config option "
+"'i2p.naming.impl'\n"
+"(restart required).\n"
+"See core/java/src/net/i2p/client/naming for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:258
+msgid ""
+"Any new system should be stacked with HostsTxt, or should\n"
+"implement local storage and/or the addressbook subscription functions, "
+"since addressbook\n"
+"only knows about the hosts.txt files and format."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:264
+msgid "Certificates"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:265
+msgid ""
+"I2P destinations contain a certificate, however at the moment that "
+"certificate\n"
+"is always null.\n"
+"With a null certificate, base64 destinations are always 516 bytes ending "
+"in \"AAAA\",\n"
+"and this is checked in the addressbook merge mechanism, and possibly "
+"other places.\n"
+"Also, there is no method available to generate a certificate or add it to"
+" a\n"
+"destination. So these will have to be updated to implement certificates."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:273
+#, python-format
+msgid ""
+"One possible use of certificates is for proof of work."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:276
+msgid ""
+"Another is for \"subdomains\" (in quotes because there is really no such "
+"thing,\n"
+"i2p uses a flat naming system) to be signed by the 2nd level domain's "
+"keys."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:280
+msgid ""
+"With any certificate implementation must come the method for verifying "
+"the\n"
+"certificates.\n"
+"Presumably this would happen in the addressbook merge code.\n"
+"Is there a method for multiple types of certificates, or multiple "
+"certificates?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:286
+msgid ""
+"Adding on a certificate authenticating the\n"
+"responses as signed by some centralized certificate authority would "
+"address many of\n"
+"the hostile nameserver issues but would leave open replay attacks as well"
+" as \n"
+"hostile certificate authority attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:2
+msgid "Low-level Cryptography Details"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:6
+msgid "This page specifies the low-level details of the cryptography in I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:10
+#, python-format
+msgid ""
+"There are a handful of cryptographic algorithms in use within I2P, but we"
+" have\n"
+"reduced them to a bare minimum to deal with our needs - one symmetric "
+"algorithm\n"
+"one asymmetric algorithm, one signing algorithm, and one hashing "
+"algorithm.  However, \n"
+"we do combine them in some particular ways to provide message integrity "
+"(rather than\n"
+"relying on a MAC).  In addition, as much as we hate doing anything new in"
+" regards to \n"
+"cryptography, we can't seem to find a reference discussing (or even "
+"naming) the \n"
+"technique used in ElGamal/AES+SessionTag "
+"(but we're sure others have done it)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:20
+msgid "ElGamal encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:22
+msgid ""
+"\n"
+"ElGamal is used for asymmetric encryption.\n"
+"ElGamal is used in several places in I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:27
+#, python-format
+msgid ""
+"To encrypt router-to-router Tunnel Build "
+"Messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:30
+#, python-format
+msgid ""
+"For end-to-end (destination-to-destination) encryption as a part of ElGamal/AES+SessionTag\n"
+"using the encryption key in the LeaseSet"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:34
+#: i2p2www/pages/site/docs/how/cryptography.html:189
+#, python-format
+msgid ""
+"For encryption of some netDb stores and "
+"queries sent to floodfill routers\n"
+"as a part of ElGamal/AES+SessionTag\n"
+"(destination-to-router or router-to-router)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:41
+msgid ""
+"We use common primes for 2048 ElGamal encryption and decryption, as given"
+" by IETF RFC-3526.\n"
+"We currently only use ElGamal to encrypt the IV and session key in a "
+"single block, followed by the \n"
+"AES encrypted payload using that key and IV."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:47
+msgid "The unencrypted ElGamal contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:64
+msgid ""
+"The H(data) is the SHA256 of the data that is encrypted in the ElGamal "
+"block,\n"
+"and is preceded by a nonzero byte. \n"
+"This byte could be random, but as implemented it is always 0xFF.\n"
+"It could possibly be used for flags in the future.\n"
+"The data encrypted in the block may be up to 222 bytes long.\n"
+"As the encrypted data may contain a substantial number of zeros if the\n"
+"cleartext is smaller than 222 bytes, it is recommended that higher layers"
+" pad\n"
+"the cleartext to 222 bytes with random data.\n"
+"Total length: typically 255 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:76
+msgid "The encrypted ElGamal contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:102
+msgid ""
+"Each encrypted part is prepended with zeros to a size of exactly 257 "
+"bytes.\n"
+"Total length: 514 bytes.\n"
+"In typical usage, higher layers pad the cleartext data to 222 bytes,\n"
+"resulting in an unencrypted block of 255 bytes.\n"
+"This is encoded as two 256-byte encrypted parts,\n"
+"and there is a single byte of zero padding before each part at this layer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:111
+#, python-format
+msgid "See the ElGamal code."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:115
+msgid ""
+"The shared prime is the \n"
+"[Oakley prime "
+"for 2048 bit keys]"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:122
+msgid "or as a hexadecimal value:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:138
+msgid "Using 2 as the generator."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:142
+msgid "Short Exponent"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:143
+#, python-format
+msgid ""
+"While the standard exponent size is 2048 bits (256 bytes) and the I2P\n"
+"PrivateKey\n"
+"is a full 256 bytes,\n"
+"we use the short exponent size of 226 bits (28.25 bytes).\n"
+"This should be safe for use with the Oakley primes, per\n"
+"On Diffie-Hellman Key Agreement with Short Exponents "
+"- van Oorschot, Weiner\n"
+"at EuroCrypt 96, and crypto++'s "
+"benchmarks.\n"
+"Benchmarks originally at %(oldbenchmarks)s (now dead),\n"
+"rescued from the wayback machine,"
+" dated Apr 23, 2008."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:158
+#, python-format
+msgid ""
+"Also, Koshiba & Kurosawa: Short Exponent Diffie-"
+"Hellman Problems (PKC 2004, LNCS 2947, pp. 173-186)\n"
+"(full text on Google Books) apparently "
+"supports this, according to\n"
+"this sci.crypt thread.\n"
+"The remainder of the PrivateKey is padded with zeroes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:167
+#: i2p2www/pages/site/docs/how/cryptography.html:264
+#: i2p2www/pages/site/docs/how/cryptography.html:343
+#: i2p2www/pages/site/docs/how/cryptography.html:382
+msgid "Obsolescence"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:168
+msgid ""
+"The vulnerability of the network to an ElGamal attack and the impact of "
+"transitioning to a longer bit length is to be studied.\n"
+"It may be quite difficult to make any change backward-compatible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:176
+msgid "AES is used for symmetric encryption, in several cases:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:181
+msgid "For transport encryption after DH key exchange"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:185
+#, python-format
+msgid ""
+"For end-to-end (destination-to-destination) encryption as a part of ElGamal/AES+SessionTag"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:195
+#, python-format
+msgid ""
+"For encryption of periodic tunnel "
+"test messages sent from the router to itself, through its own "
+"tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:200
+#, python-format
+msgid ""
+"We use AES with 256 bit keys and 128 bit blocks in CBC mode.\n"
+"The padding used is specified in IETF RFC-2313 "
+"(PKCS#5 1.5, section 8.1 (for block type 02)).\n"
+"In this case, padding exists of pseudorandomly generated octets to match "
+"16 byte blocks.\n"
+"Specifically, see [the CBC code] and the "
+"Cryptix AES\n"
+"[implementation], as well as the padding, found"
+" in the\n"
+"ElGamalAESEngine.getPadding function."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:265
+msgid ""
+"The vulnerability of the network to an AES attack and the impact of "
+"transitioning to a longer bit length is to be studied.\n"
+"It may be quite difficult to make any change backward-compatible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:270
+#: i2p2www/pages/site/docs/how/cryptography.html:362
+#: i2p2www/pages/site/docs/how/cryptography.html:388
+#: i2p2www/pages/site/docs/how/cryptography.html:456
+#: i2p2www/pages/site/docs/how/garlic-routing.html:281
+#: i2p2www/pages/site/docs/how/peer-selection.html:296
+msgid "References"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:273
+msgid "Feb. 7, 2006 Status Notes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:280
+#, python-format
+msgid ""
+"Signatures are generated and verified with 1024 bit DSA (L=1024, N=160), "
+"as implemented in\n"
+"[DSAEngine].\n"
+"DSA was chosen because it is much faster for signatures than ElGamal."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:286
+msgid "The DSA constants"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:337
+#, python-format
+msgid ""
+"The Signing Public"
+" Key is 1024 bits.\n"
+"The Signing "
+"Private Key is 160 bits."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:344
+#, python-format
+msgid ""
+"NIST 800-57\n"
+"recommends a minimum of (L=2048, N=224) for usage beyond 2010.\n"
+"This may be mitigated somewhat by the \"cryptoperiod\", or lifespan of a "
+"given key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:350
+msgid ""
+"The prime number was chosen in 2003,\n"
+"and the person that chose the number (TheCrypto) is currently no longer "
+"an I2P developer.\n"
+"As such, we do not know if the prime chosen is a 'strong prime'.\n"
+"If a larger prime is chosen for future purposes, this should be a strong "
+"prime, and we will document the construction process."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:357
+msgid ""
+"The vulnerability of the network to a DSA attack and the impact of "
+"transitioning to longer keys is to be studied.\n"
+"It may be quite difficult to make any change backward-compatible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:365
+#: i2p2www/pages/site/docs/how/cryptography.html:367
+#, python-format
+msgid "Meeting %(num)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:369
+msgid "Choosing the constants"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:377
+#, python-format
+msgid ""
+"Hashes within I2P are plain old SHA256, as implemented in\n"
+"[SHA256Generator]"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:383
+msgid ""
+"The vulnerability of the network to a SHA-256 attack and the impact of "
+"transitioning to a longer hash is to be studied.\n"
+"It may be quite difficult to make any change backward-compatible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:395
+msgid ""
+"At the lowest protocol layer,\n"
+"point-to-point inter-router communication is protected by the transport "
+"layer security.\n"
+"Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange\n"
+"using\n"
+"the same shared prime and generator as specified "
+"above for ElGamal,\n"
+"followed by symmetric AES encryption as described above.\n"
+"This provides\n"
+"perfect "
+"forward secrecy\n"
+"on the transport links."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:407
+msgid "NTCP connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:409
+#, python-format
+msgid ""
+"NTCP connections are negotiated with a 2048 Diffie-Hellman "
+"implementation,\n"
+"using the router's identity to proceed with a station to station "
+"agreement, followed by\n"
+"some encrypted protocol specific fields, with all subsequent data "
+"encrypted with AES\n"
+"(as above).\n"
+"The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) "
+"forward secrecy', while ElGamalAES+SessionTag does not."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:417
+msgid ""
+"In order to migrate to a more standardized implementation (TLS/SSL or "
+"even SSH), the following issues must be addressed:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:421
+msgid ""
+"Can we somehow reestablish sessions securely (ala session tags) or do we "
+"need to do full negotiation each time?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:424
+msgid ""
+"Can we simplify/avoid the x509 or other certificate formats and use our "
+"own RouterInfo structure (which \n"
+"contains the ElGamal and DSA keys)?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:429
+#, python-format
+msgid "See the NTCP specification for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:433
+msgid "UDP connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:434
+msgid ""
+"SSU (the UDP transport) encrypts each packet with AES256/CBC with both an"
+" explicit IV and MAC \n"
+"(HMAC-MD5-128) after agreeing upon an ephemeral session key through a "
+"2048 bit \n"
+"Diffie-Hellman exchange, station-to-station authentication with the other"
+" \n"
+"router's DSA key, plus each network message has their own hash for local "
+"integrity \n"
+"checking."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:442
+#, python-format
+msgid "See the SSU specification for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:446
+#, python-format
+msgid ""
+"WARNING - I2P's HMAC-MD5-128 used in SSU is apparently non-standard.\n"
+"Apparently, an early version of SSU used HMAC-SHA256, and then it was "
+"switched\n"
+"to MD5-128 for performance reasons, but left the 32-byte buffer size "
+"intact.\n"
+"See HMACGenerator.java and\n"
+"the 2005-07-05 status notes\n"
+"for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:2
+msgid "ElGamal/AES + SessionTag Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:3
+msgid "February 2011"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:7
+msgid "ElGamal/AES+SessionTags is used for end-to-end encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:11
+msgid ""
+"As an unreliable, unordered, message based system, I2P uses a simple "
+"combination \n"
+"of asymmetric and symmetric encryption algorithms to provide data "
+"confidentiality \n"
+"and integrity to garlic messages. As a whole, the combination is referred"
+" \n"
+"to as ElGamal/AES+SessionTags, but that is an excessively verbose way to "
+"describe \n"
+"the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:19
+#: i2p2www/pages/site/docs/how/tech-intro.html:512
+msgid ""
+"The first time a router wants to encrypt a garlic message to another "
+"router, \n"
+"they encrypt the keying material for an AES256 session key with ElGamal "
+"and \n"
+"append the AES256/CBC encrypted payload after that encrypted ElGamal "
+"block. \n"
+"In addition to the encrypted payload, the AES encrypted section contains "
+"the \n"
+"payload length, the SHA256 hash of the unencrypted payload, as well as a "
+"number \n"
+"of \"session tags\" - random 32 byte nonces. The next time the sender "
+"wants \n"
+"to encrypt a garlic message to another router, rather than ElGamal "
+"encrypt \n"
+"a new session key they simply pick one of the previously delivered "
+"session \n"
+"tags and AES encrypt the payload like before, using the session key used "
+"with \n"
+"that session tag, prepended with the session tag itself. When a router "
+"receives \n"
+"a garlic encrypted message, they check the first 32 bytes to see if it "
+"matches \n"
+"an available session tag - if it does, they simply AES decrypt the "
+"message, \n"
+"but if it does not, they ElGamal decrypt the first block."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:35
+#: i2p2www/pages/site/docs/how/tech-intro.html:528
+msgid ""
+"Each session tag can be used only once so as to prevent internal "
+"adversaries \n"
+"from unnecessarily correlating different messages as being between the "
+"same \n"
+"routers. The sender of an ElGamal/AES+SessionTag encrypted message "
+"chooses \n"
+"when and how many tags to deliver, prestocking the recipient with enough "
+"tags \n"
+"to cover a volley of messages. Garlic messages may detect the successful "
+"tag \n"
+"delivery by bundling a small additional message as a clove (a \"delivery "
+"status \n"
+"message\") - when the garlic message arrives at the intended recipient "
+"and \n"
+"is decrypted successfully, this small delivery status message is one of "
+"the \n"
+"cloves exposed and has instructions for the recipient to send the clove "
+"back \n"
+"to the original sender (through an inbound tunnel, of course). When the "
+"original \n"
+"sender receives this delivery status message, they know that the session "
+"tags \n"
+"bundled in the garlic message were successfully delivered."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:50
+msgid ""
+"Session tags themselves have a short lifetime, after which they are \n"
+"discarded if not used. In addition, the quantity stored for each key is "
+"limited, \n"
+"as are the number of keys themselves - if too many arrive, either new or "
+"old \n"
+"messages may be dropped. The sender keeps track whether messages using "
+"session \n"
+"tags are getting through, and if there isn't sufficient communication it "
+"may \n"
+"drop the ones previously assumed to be properly delivered, reverting back"
+" \n"
+"to the full expensive ElGamal encryption.\n"
+"A session will continue to exist until all its tags are exhausted or "
+"expire."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:61
+msgid ""
+"Sessions are unidirectional. Tags are delivered from Alice to Bob,\n"
+"and Alice then uses the tags, one by one, in subsequent messages to Bob."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:66
+msgid ""
+"Sessions may be established between Destinations, between Routers, or\n"
+"between a Router and a Destination.\n"
+"Each Router and Destination maintains its own Session Key Manager to\n"
+"keep track of Session Keys and Session Tags.\n"
+"Separate Session Key Managers prevents correlation of multiple "
+"Destinations\n"
+"to each other or a Router by adversaries."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:77
+msgid "Message Reception"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:78
+msgid ""
+"Each message received has one of two\n"
+"the two possible conditions:
            "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:84
+msgid ""
+"It is part of an existing session and contains a Session Tag and an AES "
+"encrypted block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:85
+msgid "It is for a new session and contains both ElGamal and AES encrypted blocks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:88
+msgid ""
+"When a router receives a message, it will first assume it is from\n"
+"an existing session and attempt to look up the Session Tag and decrypt "
+"the following data using AES.\n"
+"If that fails, it will assume it is for a new session and attempt to\n"
+"decrypt it using ElGamal."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:97
+msgid "New Session Message Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:98
+msgid ""
+"A New Session ElGamal Message contains two parts, an encrypted ElGamal "
+"block\n"
+"and an encrypted AES block."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:103
+msgid "The encrypted message contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:127
+msgid "ElGamal Block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:128
+msgid "The encrypted ElGamal Block is always 514 bytes long."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:132
+msgid "The unencrypted ElGamal data is 222 bytes long, containing:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:164
+#, python-format
+msgid ""
+"The 32-byte\n"
+"Session Key\n"
+"is the identifier for the session.\n"
+"The 32-byte Pre-IV will be used to generate the IV for the AES block that"
+" follows;\n"
+"the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:172
+#, python-format
+msgid ""
+"The 222 byte payload is encrypted\n"
+"using ElGamal\n"
+"and the encrypted block is 514 bytes long.\n"
+"
            "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:179
+msgid "AES Block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:180
+msgid "The unencrypted data in the AES block contains the following:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:224
+#, python-format
+msgid "2-byte Integer, 0-200"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:228
+#, python-format
+msgid ""
+"That many 32-byte Session Tags"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:232
+#, python-format
+msgid "4-byte Integer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:236
+#, python-format
+msgid ""
+"The 32-byte SHA256 Hash of"
+" the payload"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:240
+msgid "A one-byte value. Normally == 0. If == 0x01, a Session Key follows"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:244
+#, python-format
+msgid ""
+"A 32-byte Session "
+"Key,\n"
+"                 to replace the old key, and is only present if preceding"
+" flag is 0x01"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:249
+msgid "the data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:251
+msgid ""
+"Random data to a multiple of 16 bytes for the total length.\n"
+"         May contain more than the minimum required padding."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:256
+msgid "Minimum length: 48 bytes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:260
+#, python-format
+msgid ""
+"The data is then AES Encrypted,\n"
+"using the session key and IV (calculated from the pre-IV) from the "
+"ElGamal section.\n"
+"The encrypted AES Block length is variable but is always a multiple of 16"
+" bytes.\n"
+"
            "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:269
+#, python-format
+msgid ""
+"Actual max payload length, and max block length, is less than 64 KB; see "
+"the I2NP Overview."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:272
+msgid "New Session Key is currently unused and is never present."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:277
+msgid "Existing Session Message Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:278
+msgid ""
+"The session tags delivered successfully are remembered for a \n"
+"brief period (15 minutes currently) until they are used or discarded.\n"
+"A tag is used by packaging one in an Existing Session Message that\n"
+"contains only an AES encrypted block, and is not preceded by an\n"
+"ElGamal block."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:286
+msgid ""
+"The existing session message is\n"
+"as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:309
+#, python-format
+msgid ""
+"A 32-byte Session "
+"Tag\n"
+"             previously delivered in an AES block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:314
+msgid "As specified above."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:318
+msgid ""
+"The session tag also serves as\n"
+"the pre-IV. The IV is the first 16 bytes of the SHA-256 Hash of the "
+"sessionTag."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:323
+msgid ""
+"To decode a message from an existing session, a router looks up the "
+"Session Tag to find an\n"
+"associated Session Key. If the Session Tag is found, the AES block is "
+"decrypted using the associated Session Key.\n"
+"If the tag is not found, the message is assumed to be a New Session Message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:332
+msgid ""
+"There are many possible areas to tune the Session Key Manager's "
+"algorithms;\n"
+"some may interact with the streaming library behavior, or have "
+"significant\n"
+"impact on overall performance."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:338
+msgid ""
+"Delivery of too many tags at one time may impose substantial overhead for"
+" brief streaming connections\n"
+"or datagrams, and increase the chance of message loss.\n"
+"We currently deliver 40 tags at a time (1280 bytes).\n"
+"32 (1024 bytes) may be better for tunnel fragmentation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:345
+msgid ""
+"A few tags could be delivered in each of several messages, or lots of "
+"tags all at once."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:349
+msgid ""
+"It is also important to study and tune\n"
+"the low-tag thresholds at which more tags are sent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:354
+msgid ""
+"The number of tags delivered could depend on message size, keeping in "
+"mind\n"
+"the eventual padding to 1KB at the tunnel message layer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:359
+msgid ""
+"Clients could send an estimate of session lifetime to the router, as an "
+"advisory\n"
+"on the number of tags required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:364
+msgid ""
+"Delivery of too few tags causes the router to fall back to an expensive "
+"ElGamal encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:368
+msgid ""
+"The router may assume delivery of Session Tags, or await acknowledgement "
+"before using them;\n"
+"there are tradeoffs for each strategy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:373
+msgid ""
+"For very brief messages, almost the full 222 bytes of the pre-IV and "
+"padding fields in the ElGamal block\n"
+"could be used for the entire message, instead of establishing a session."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:378
+msgid ""
+"Evaluate padding strategy; currently we pad to a minimum of 128 bytes.\n"
+"Would be better to add a few tags to small messages than pad."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:383
+msgid ""
+"Perhaps things could be more efficient if the Session Tag system was "
+"bidirectional,\n"
+"so tags delivered in the 'forward' path could be used in the 'reverse' "
+"path,\n"
+"thus avoiding ElGamal in the initial response.\n"
+"The router currently plays some tricks like this when sending\n"
+"tunnel test messages to itself."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:391
+#, python-format
+msgid ""
+"Change from Session Tags to\n"
+"a synchronized PRNG."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:396
+#, python-format
+msgid ""
+"Several of these ideas may require a new I2NP message type, or\n"
+"set a flag in the\n"
+"Delivery Instructions,\n"
+"or set a magic number in the first few bytes of the Session Key field\n"
+"and accept a small risk of the random Session Key matching the magic "
+"number."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:2
+msgid "Garlic Routing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:6
+msgid "Garlic Routing and \"Garlic\" Terminology"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:7
+msgid ""
+"The terms \"garlic routing\" and \"garlic encryption\" are often used "
+"rather loosely when referring to I2P's technology.\n"
+"Here, we explain the history of the terms, the various meanings, and\n"
+"the usage of \"garlic\" methods in I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:13
+msgid ""
+"\"Garlic routing\" was first coined by\n"
+"Michael J. Freedman\n"
+"in Roger Dingledine's Free Haven \n"
+"Master's thesis "
+"Section 8.1.1 (June 2000), as derived from \n"
+"Onion Routing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:21
+msgid ""
+"\"Garlic\" may have been used originally by I2P developers because I2P "
+"implements a form of\n"
+"bundling as Freedman describes, or simply to emphasize general "
+"differences from Tor.\n"
+"The specific reasoning may be lost to history.\n"
+"Generally, when referring to I2P, the term \"garlic\" may mean one of "
+"three things:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:28
+#: i2p2www/pages/site/docs/how/garlic-routing.html:39
+msgid "Layered Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:29
+msgid "Bundling multiple messages together"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:30
+#: i2p2www/pages/site/docs/how/garlic-routing.html:96
+msgid "ElGamal/AES Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:33
+msgid ""
+"Unfortunately, I2P's usage of \"garlic\" terminology over the past seven "
+"years has not always been precise; therefore the reader is\n"
+"cautioned when encountering the term.\n"
+"Hopefully, the explanation below will make things clear."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:40
+msgid ""
+"Onion routing is a technique for building paths, or tunnels, through a "
+"series of peers,\n"
+"and then using that tunnel.\n"
+"Messages are repeatedly encrypted by the originator, and then decrypted "
+"by each hop.\n"
+"During the building phase, only the routing instructions for the next hop"
+" are exposed to each peer.\n"
+"During the operating phase, messages are passed through the tunnel, and "
+"the\n"
+"message and its routing instructions are only exposed to the endpoint of "
+"the tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:49
+#, python-format
+msgid ""
+"This is similar to the way Mixmaster\n"
+"(see network comparisons) sends messages "
+"- taking a message, encrypting it\n"
+"to the recipient's public key, taking that encrypted message and "
+"encrypting\n"
+"it (along with instructions specifying the next hop), and then taking "
+"that\n"
+"resulting encrypted message and so on, until it has one layer of "
+"encryption\n"
+"per hop along the path."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:58
+msgid ""
+"In this sense, \"garlic routing\" as a general concept is identical to "
+"\"onion routing\".\n"
+"As implemented in I2P, of course, there are several differences from the "
+"implementation in Tor; see below.\n"
+"Even so, there are substantial similarities such that I2P benefits from a"
+"\n"
+"large amount of"
+" academic research on onion routing,\n"
+"Tor, and similar "
+"mixnets."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:67
+msgid "Bundling Multiple Messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:68
+msgid ""
+"Michael Freedman defined \"garlic routing\" as an extension to onion "
+"routing,\n"
+"in which multiple messages are bundled together.\n"
+"He called each message a \"bulb\".\n"
+"All the messages, each with its own delivery instructions, are exposed at"
+" the\n"
+"endpoint.\n"
+"This allows the efficient bundling of an onion routing \"reply block\" "
+"with the original message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:77
+msgid ""
+"This concept is implemented in I2P, as described below.\n"
+"Our term for garlic \"bulbs\" is \"cloves\".\n"
+"Any number of messages can be\n"
+"contained, instead of just a single message.\n"
+"This is a significant distinction from the onion routing implemented in "
+"Tor.\n"
+"However, it is only one of many major architectural differences between "
+"I2P and Tor;\n"
+"perhaps it is not, by itself, enough to justify a change in terminology."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:87
+msgid ""
+"Another difference\n"
+"from the method described by Freedman\n"
+"is that the path is unidirectional - there is no \"turning point\" as "
+"seen in onion routing\n"
+"or mixmaster reply blocks, which greatly simplifies the algorithm and "
+"allows for more flexible\n"
+"and reliable delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:97
+#, python-format
+msgid ""
+"In some cases, \"garlic encryption\" may simply mean\n"
+"ElGamal/AES+SessionTag encryption\n"
+"(without multiple layers)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:105
+msgid "\"Garlic\" Methods in I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:106
+msgid ""
+"Now that we've defined various \"garlic\" terms, we can say that\n"
+"I2P uses garlic routing, bundling and encryption in three places:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:111
+msgid "For building and routing through tunnels (layered encryption)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:112
+msgid ""
+"For determining the success or failure of end to end message delivery "
+"(bundling)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:113
+msgid ""
+"For publishing some network database entries (dampening the probability "
+"of a successful traffic analysis attack) (ElGamal/AES)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:116
+msgid ""
+"There are also significant ways that this technique can be used to "
+"improve the performance of the network, \n"
+"exploiting transport latency/throughput tradeoffs, and branching data "
+"through redundant paths to increase reliability."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:122
+msgid "Tunnel Building and Routing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:123
+msgid ""
+"In I2P, tunnels are unidirectional. Each party builds two tunnels,\n"
+"one for outbound and one for inbound traffic.\n"
+"Therefore, four tunnels are required for a single round-trip message and "
+"reply."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:129
+#, python-format
+msgid ""
+"Tunnels are built, and then used, with layered encryption.\n"
+"This is described on the\n"
+"tunnel implementation page.\n"
+"Tunnel building details are defined on\n"
+"this page.\n"
+"We use\n"
+"ElGamal/AES+SessionTag for the encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:141
+#, python-format
+msgid ""
+"Tunnels are a general-purpose mechanism to transport all\n"
+"I2NP messages, and\n"
+"Garlic Messages are not used to "
+"build tunnels.\n"
+"We do not bundle multiple\n"
+"I2NP messages into a single\n"
+"Garlic Message for unwrapping at "
+"the outbound tunnel endpoint;\n"
+"the tunnel encryption is sufficient."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:152
+msgid "End-to-End Message Bundling"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:153
+#, python-format
+msgid ""
+"At the layer above tunnels, I2P delivers end-to-end messages between\n"
+"Destinations.\n"
+"Just as within a single tunnel, we use\n"
+"ElGamal/AES+SessionTag for the encryption."
+"\n"
+"Each client message as delivered to the router through the\n"
+"I2CP interface becomes a single\n"
+"Garlic Clove\n"
+"with its own\n"
+"Delivery Instructions,\n"
+"inside a\n"
+"Garlic Message.\n"
+"Delivery Instructions may specify a Destination, Router, or Tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:172
+msgid ""
+"Generally, a Garlic Message will contain only one clove.\n"
+"However, the router will periodically bundle two additional\n"
+"cloves in the Garlic Message:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:177
+msgid "Garlic Message Cloves"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:180
+#, python-format
+msgid ""
+"A\n"
+"Delivery Status Message,\n"
+"with\n"
+"Delivery Instructions\n"
+"specifying that it be sent back to the originating router as an "
+"acknowledgment.\n"
+"This is similar to the \"reply block\" or \"reply onion\"\n"
+"described in the references.\n"
+"It is used for determining the success or failure of end to end message "
+"delivery.\n"
+"The originating router may, upon failure to receive the Delivery Status "
+"Message\n"
+"within the expected time period, modify the routing to the far-end "
+"Destination,\n"
+"or take other actions."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:194
+#, python-format
+msgid ""
+"A\n"
+"Database Store Message,\n"
+"containing a\n"
+"LeaseSet\n"
+"for the originating Destination, with\n"
+"Delivery Instructions\n"
+"specifying the far-end destination's router.\n"
+"By periodically bundling a LeaseSet, the router ensures that the far-end "
+"will be able\n"
+"to maintain communications.\n"
+"Otherwise the far-end would have to query a floodfill router for the "
+"network database entry,\n"
+"and all LeaseSets would have to be published to the network database, as "
+"explained on the\n"
+"network database page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:213
+#, python-format
+msgid ""
+"In the current implementation, the Delivery Status and Database Store "
+"Messages\n"
+"are bundled when the local LeaseSet changes, when additional\n"
+"Session Tags\n"
+"are delivered, or if the messages have not been bundled in the previous "
+"minute."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:220
+msgid ""
+"Obviously, the additional messages are currently bundled for specific "
+"purposes,\n"
+"and not part of a general-purpose routing scheme."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:226
+msgid "Storage to the Floodfill Network Database"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:227
+#, python-format
+msgid ""
+"As explained on the\n"
+"network database page,\n"
+"local\n"
+"LeaseSets\n"
+"are sent to floodfill routers in a\n"
+"Database Store Message\n"
+"wrapped in a\n"
+"Garlic Message\n"
+"so it is not visible to the tunnel's outbound gateway."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:243
+#, python-format
+msgid ""
+"The Garlic Message mechanism is very flexible and provides a structure "
+"for\n"
+"implementing many types of mixnet delivery methods.\n"
+"Together with the unused delay option in the\n"
+"tunnel message Delivery "
+"Instructions,\n"
+"a wide spectrum of batching, delay, mixing, and routing strategies are "
+"possible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:251
+msgid ""
+"In particular, there is potential for much more flexibility at the "
+"outbound tunnel endpoint.\n"
+"Messages could possibly be routed from there to one of several tunnels\n"
+"(thus minimizing point-to-point connections), or multicast to several "
+"tunnels\n"
+"for redundancy, or streaming audio and video."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:258
+msgid ""
+"Such experiments may conflict with the need to ensure security and "
+"anonymity, such\n"
+"as limiting certain routing paths, restricting the types of I2NP messages"
+" that may\n"
+"be forwarded along various paths, and enforcing certain message "
+"expiration times."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:264
+#, python-format
+msgid ""
+"As a part of\n"
+"ElGamal/AES encryption,\n"
+"a garlic message contains a sender\n"
+"specified amount of padding data, allowing the sender to take active "
+"countermeasures \n"
+"against traffic analysis.\n"
+"This is not currently used, beyond the requirement to pad to a multiple "
+"of 16 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:273
+#, python-format
+msgid ""
+"Encryption of additional messages to and from the\n"
+"floodfill routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:283
+msgid ""
+"The term garlic routing was first coined in Roger Dingledine's Free Haven"
+" \n"
+"Master's thesis "
+"(June 2000),\n"
+"see Section 8.1.1 authored by\n"
+"Michael J. Freedman."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:290
+msgid "Onion router publications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:292
+msgid "Onion Routing on Wikipedia"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:294
+msgid "Garlic Routing on Wikipedia"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:296
+#, python-format
+msgid ""
+"I2P Meeting 58 (2003) discussing the "
+"implementation of garlic routing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:302
+msgid "Free Haven publications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:304
+msgid ""
+"Onion routing was first described in Hiding Routing Information\n"
+"by David M. Goldschlag, Michael G. Reed, and Paul F. Syverson in 1996."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:2
+msgid "A Gentle Introduction"
+msgstr "Una Introducción Sencilla"
+
+#: i2p2www/pages/site/docs/how/intro.html:5
+msgid "A Gentle Introduction to How I2P Works"
+msgstr "Una breve presentación de cómo funciona I2P"
+
+#: i2p2www/pages/site/docs/how/intro.html:7
+msgid ""
+"I2P is a project to build, deploy, and maintain a network supporting "
+"secure and anonymous\n"
+"communication. People using I2P are in control of the tradeoffs between "
+"anonymity, reliability,\n"
+"bandwidth usage, and latency. There is no central point in the network on"
+" which pressure can be\n"
+"exerted to compromise the integrity, security, or anonymity of the "
+"system. The network supports\n"
+"dynamic reconfiguration in response to various attacks, and has been "
+"designed to make use of\n"
+"additional resources as they become available. Of course, all aspects of "
+"the network are open and\n"
+"freely available."
+msgstr ""
+"I2P es un proyecto para construir, desplegar y mantener una red que "
+"soporte comunicación\n"
+"segura y anónima. Los usuarios de I2P pueden administrar el balance entre"
+" el anonimato,\n"
+"fiabilidad, uso de ancho de banda y latencia. No hay un punto central en "
+"la red sobre el cual\n"
+"se pueda ejercer presión para comprometer la integridad, seguridad y "
+"anonimato del sistema.\n"
+"La red soporta reconfiguración dinámica en respuesta a diversos ataques, "
+"y ha sido diseñada\n"
+"para hacer uso de recursos adicionales según vayan estando disponibles. "
+"Por supuesto, todos\n"
+"los aspectos de la red son abiertos y están a libre disposición."
+
+#: i2p2www/pages/site/docs/how/intro.html:17
+msgid ""
+"Unlike many other anonymizing networks, I2P doesn't try to provide "
+"anonymity by hiding the\n"
+"originator of some communication and not the recipient, or the other way "
+"around. I2P is designed to\n"
+"allow peers using I2P to communicate with each other anonymously — "
+"both sender and recipient\n"
+"are unidentifiable to each other as well as to third parties. For "
+"example, today there are both\n"
+"in-I2P web sites (allowing anonymous publishing / hosting) as well as "
+"HTTP proxies to the normal web\n"
+"(allowing anonymous web browsing). Having the ability to run servers "
+"within I2P is essential, as it\n"
+"is quite likely that any outbound proxies to the normal Internet will be "
+"monitored, disabled, or\n"
+"even taken over to attempt more malicious attacks."
+msgstr ""
+"A diferencia de la mayoría de las redes anónimas, I2P no intenta "
+"suministrar anonimato ocultándole\n"
+"sí al origen de una comunicación y no al destinatario, o víceversa. De lo"
+" contrario: I2P está\n"
+"diseñada para permitir a los pares comunicarse unos con otros "
+"anónimamente - ambos, quien\n"
+"envía y el que recibe, no son identificables entre ellos y tampoco por "
+"terceras partes. Por ejemplo,\n"
+"actualmente hay sitios web I2P internos (permitiendo publicación y "
+"hospedaje anónimo) además\n"
+"de proxies HTTP hacia la web normal (permitiendo navegación anónima). "
+"Disponer de la posibilidad\n"
+"de correr servidores internamente en I2p es esencial,  ya que es bastante"
+" probable que cualquier\n"
+"proxy de salida hacia la Internet normal pudiera ser monitorizado, "
+"desactivado o comprometido\n"
+"con el intento de ataques más maliciosos."
+
+#: i2p2www/pages/site/docs/how/intro.html:28
+#, python-format
+msgid ""
+"The network itself is message oriented - it is essentially a secure and "
+"anonymous IP layer, where\n"
+"messages are addressed to cryptographic keys (Destinations) and can be "
+"significantly larger than IP\n"
+"packets. Some example uses of the network include \"eepsites\" "
+"(webservers hosting normal web\n"
+"applications within I2P), a BitTorrent client (\"I2PSnark\"), or a "
+"distributed data store. With the\n"
+"help of the I2PTunnel application, we are "
+"able to stream traditional\n"
+"TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and even "
+"streaming audio. Most people\n"
+"will not use I2P directly, or even need to know they're using it. Instead"
+" their view will be of one\n"
+"of the I2P enabled applications, or perhaps as a little controller app to"
+" turn on and off various\n"
+"proxies to enable the anonymizing functionality."
+msgstr ""
+"La red es en sí misma orientada a mensajes - es en esencia una capa IP "
+"segura y anónima donde\n"
+"los mensajes son direccionados hacia claves criptográficas (Destinos) y "
+"pueden ser considerablemente\n"
+"más largos que los paquetes IP. Algunos ejemplos del uso de la red "
+"incluyen \"eepsites\"  (servidores\n"
+"web hospedando aplicaciones web normales dentro de I2P), un cliente "
+"BitTorrent (\"I2PSnark\"),\n"
+"o un sistema de almacenaje de datos distribuido. Con la ayuda de la "
+"aplicación \n"
+"I2PTunnel, somos capaces de correr aplicaciones TCP/IP tradicionales "
+"sobre I2P, como SSH,\n"
+"IRC, un proxy Squid, e igualmente streaming de audio. Mucha gente no "
+"usará I2P directamente,\n"
+"o mismamentee no necesitarán saber que lo están usando. En vez de eso, su"
+" percepción será la\n"
+"de una de las aplicaciones I2P habilitadas, o quizá la de una pequeña "
+"aplicación de control para\n"
+"activar y desactivar varios proxies que permitan funccionalidades de "
+"anonimato."
+
+#: i2p2www/pages/site/docs/how/intro.html:40
+#, python-format
+msgid ""
+"An essential part of designing, developing, and testing an anonymizing "
+"network is to define the threat model, since there is no such thing "
+"as \"true\" anonymity, just\n"
+"increasingly expensive costs to identify someone. Briefly, I2P's intent "
+"is to allow people to\n"
+"communicate in arbitrarily hostile environments by providing good "
+"anonymity, mixed in with\n"
+"sufficient cover traffic provided by the activity of people who require "
+"less anonymity. This way,\n"
+"some users can avoid detection by a very powerful adversary, while others"
+" will try to evade a weaker\n"
+"entity, all on the same network, where each one's messages are "
+"essentially indistinguishable\n"
+"from the others."
+msgstr ""
+"Una parte esencial de diseñar, desarrollar y probar una red anónima es "
+"definir el modelo de amenaza, si partimos de que no "
+"existe lo que podría\n"
+"ser considerado anonimato auténtico,  solamente se puede hacer más "
+"costoso el identificar\n"
+"a alguien. Brevemente, el propósito de I2P es permitir comunicarse a la "
+"gente en ambientes\n"
+"arbitrariamente hostiles suministrando buen anonimato, mezclado con "
+"suficiente tráfico de\n"
+"cobertura proporcionado por la actividad de gente que requiere menos "
+"anonimato. De esta\n"
+"forma algunos usuarios pueden evitar ser detectados por poderosos "
+"adversarios, mientras\n"
+"otros intentarán ocultar su identidad de forma más débil, todo en la "
+"misma red, donde\n"
+"los mensajes de cada uno son ensencialmente indistinguibles de los del "
+"resto."
+
+#: i2p2www/pages/site/docs/how/intro.html:51
+msgid "Why?"
+msgstr "¿Por qué?"
+
+#: i2p2www/pages/site/docs/how/intro.html:52
+#, python-format
+msgid ""
+"There are a multitude of reasons why we need a system to support "
+"anonymous communication, and\n"
+"everyone has their own personal rationale. There are many other\n"
+"efforts working on finding ways to provide varying degrees of "
+"anonymity to people through the\n"
+"Internet, but we could not find any that met our needs or threat model."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:59
+msgid "How?"
+msgstr "¿Cómo?"
+
+#: i2p2www/pages/site/docs/how/intro.html:61
+#, python-format
+msgid ""
+"The network at a glance is made up of a set of nodes (\"routers\") with a"
+" number of unidirectional\n"
+"inbound and outbound virtual paths (\"tunnels\", as outlined on the tunnel routing page). Each router is "
+"identified by a cryptographic RouterIdentity which is\n"
+"typically long lived. These routers communicate with each other through "
+"existing transport\n"
+"mechanisms (TCP, UDP, etc), passing various messages. Client applications"
+" have their own\n"
+"cryptographic identifier (\"Destination\") which enables it to send and "
+"receive messages. These\n"
+"clients can connect to any router and authorize the temporary allocation "
+"(\"lease\") of some tunnels\n"
+"that will be used for sending and receiving messages through the network."
+" I2P has its own internal\n"
+"network database (using a modification of the "
+"Kademlia algorithm) for\n"
+"distributing routing and contact information securely."
+msgstr ""
+"Un vistazo a la red muestra que se compone de una instalación de nodos "
+"(\"routers\") con un\n"
+"número de rutas virtuales unidireccionales entrantes y salientes "
+"(Tunnels, como se describen\n"
+"en la página tunnel routing). Cada "
+"router está identificado\n"
+"por una RouterIdentity cifrada que es permanente normalmente. Estos "
+"routers se comunican\n"
+"entre ellos a través de mecanismo de transporte existentes (TCP, UDP, "
+"etc) enviandose distintos\n"
+"mensajes. Las aplicaciones clientes tienen su propio identificador "
+"criptográfico (\"Destino\") que\n"
+"las habilita para enviar y recibir mensajes. Estos clientes pueden "
+"conectarse a cualquier router y\n"
+"autorizar la asignación temporal (\"arrendamiento\") de varios tuneles "
+"que serán usados para enviar\n"
+"y recibir mensaje a través de la red. I2P tiene su propia base de datos de\n"
+"red (utilizando una modificación del algoritmo Kadeemlia) para "
+"distribuir información de\n"
+"rutas y contactos de forma segura."
+
+#: i2p2www/pages/site/docs/how/intro.html:74
+msgid "Network topology example"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:76
+msgid ""
+"In the above, Alice, Bob, Charlie, and Dave are all running routers with "
+"a single Destination on\n"
+"their local router. They each have a pair of 2-hop inbound tunnels per "
+"destination (labeled 1, 2, 3,\n"
+"4, 5 and 6), and a small subset of each of those router's outbound tunnel"
+" pool is shown with 2-hop\n"
+"outbound tunnels. For simplicity, Charlie's inbound tunnels and Dave's "
+"outbound tunnels are not\n"
+"shown, nor are the rest of each router's outbound tunnel pool (typically "
+"stocked with a few tunnels\n"
+"at a time). When Alice and Bob talk to each other, Alice sends a message "
+"out one of her (pink)\n"
+"outbound tunnels targeting one of Bob's (green) inbound tunnels (tunnel 3"
+" or 4). She knows to send\n"
+"to those tunnels on the correct router by querying the network database, "
+"which is constantly updated\n"
+"as new leases are authorized and old ones expire."
+msgstr ""
+"En la imagen, Alice, Bob, Charlie and Dave están corriendo routers con un"
+" simple Destino en\n"
+"su router local. Cada uno de ellos tiene un par de túneles de dos saltos "
+"entrantes por destino\n"
+"(etiquetados como 1, 2, 3, 4, 5 y 6), y una pequeña parte del grupo de "
+"los túneles de salida de\n"
+"esos routers se representa con tuneles de salida de dos saltos. Para "
+"simplificar, los túneles entrantes\n"
+"de Charlie y los de salida de Dave no se muestran, tampoco está el resto "
+"del grupo de túneles\n"
+"de salida de cada router (típicamente compuesto por varios túneles a la "
+"vez). Cuando Alice y\n"
+"Bob se comunican entre ellos, Alice envía un mensaje por uno de sus "
+"túneles de salida (rosa)\n"
+"en dirección a uno de los túneles entrantes (verde) de Bob (túnel 3 o 4)."
+" Ella conoce cómo enviar\n"
+"a los túneles del router correcto mediante consultas a la base de datos "
+"de red, que está\n"
+"constantemente actualizándose tan pronto cómo son autorizados nuevos "
+"arrendamientos y\n"
+"expiran los viejos."
+
+#: i2p2www/pages/site/docs/how/intro.html:88
+#, python-format
+msgid ""
+"If Bob wants to reply to Alice, he simply goes through the same process -"
+" send a message out one of\n"
+"his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 "
+"or 2). To make things\n"
+"easier, most messages sent between Alice and Bob are garlic\n"
+"wrapped, bundling the sender's own current lease information so that the "
+"recipient can reply\n"
+"immediately without having to look in the network database for the "
+"current data."
+msgstr ""
+"Si Bob quiere contestar a Alice, simplemente utilizará el mismo proceso -"
+" envía un mensaje\n"
+"por uno de sus túneles de salida en dirección hacia uno de los túneles de"
+" entrada de Alice (túnel\n"
+"1 o 2). Para hacer las cosas más sencillas, la mayor parte de los "
+"mensajes enviados entre Alice\n"
+"y Bob usan el envoltorio garlic, "
+"incluyendo la información\n"
+"de arrendamiento propia del remitente en el paquete, de esta forma el "
+"destinatario puede contestar\n"
+"inmediatamente sin necesidad de buscar el dato en su base de datos de red."
+
+#: i2p2www/pages/site/docs/how/intro.html:96
+#, python-format
+msgid ""
+"To deal with a wide range of attacks, I2P is fully distributed with no "
+"centralized resources - and\n"
+"hence there are no directory servers keeping statistics regarding the "
+"performance and reliability of\n"
+"routers within the network. As such, each router must keep and maintain "
+"profiles of various routers\n"
+"and is responsible for selecting appropriate peers to meet the anonymity,"
+" performance, and\n"
+"reliability needs of the users, as described in the peer selection\n"
+"page."
+msgstr ""
+"Para tratar con un ámplio rango de ataques, I2P es completamente "
+"distribuida sin recursos\n"
+"centralizados - no hay servidores de directorio manteniendo estadísticas "
+"sobre el rendimiento\n"
+"y fiabilidad de los routers dentro de la red. De esta forma cada router "
+"debe guardar y mantener\n"
+"los perfiles de varios routers y es responsable de seleccionar los pares "
+"apropiados para satisfacer\n"
+"el anonimato, rendimiento y fiabilidad requeridos por los usuarios tal y "
+"como se describe en la\n"
+"página selección de pares."
+
+#: i2p2www/pages/site/docs/how/intro.html:105
+#, python-format
+msgid ""
+"The network itself makes use of a significant number of cryptographic\n"
+"techniques and algorithms - a full laundry list includes 2048bit "
+"ElGamal encryption, 256bit AES\n"
+"in CBC mode with PKCS#5 padding, 1024bit DSA signatures, SHA256 hashes, "
+"2048bit Diffie-Hellman\n"
+"negotiated connections with station to station authentication, and ElGamal / AES+SessionTag."
+msgstr ""
+"La red hace uso de un significante número de técnicas criptográficas\n"
+"y algoritmos - una lista completa incluye cifrado El Gamal de 2048 "
+"bits, AES de 256 bits\n"
+"en modo CBC con relleno PKCS#5, firmas DSA de 1024 bits, hashes SHA256, "
+"negociación de\n"
+"conexiones Diffie-Hellman de 2048 bits con autenticación estación a "
+"estación y \n"
+"ElGamal / AES+SessionTag."
+
+#: i2p2www/pages/site/docs/how/intro.html:113
+msgid ""
+"Content sent over I2P is encrypted through three layers garlic encryption"
+" (used to verify the\n"
+"delivery of the message to the recipient), tunnel encryption (all "
+"messages passing through a tunnel\n"
+"is encrypted by the tunnel gateway to the tunnel endpoint), and inter "
+"router transport layer\n"
+"encryption (e.g. the TCP transport uses AES256 with ephemeral keys)."
+msgstr ""
+"El contenido enviado sobre I2P está cifrado a través del cifrado garlic "
+"de tres capas (usado\n"
+"para verificar la entrega del mensaje a destinatario), cifrado de túnel "
+"(todos los mensajes\n"
+"cruzando a través de un túnel están cifrados desde el túnel gateway hasta"
+" el túnel destino\n"
+"final) y cifrado de la capa de transporte inter-router (e. g. el "
+"transporte TCP usa AES256 con\n"
+"claves efímeras)."
+
+#: i2p2www/pages/site/docs/how/intro.html:120
+msgid ""
+"End-to-end (I2CP) encryption (client application to server application) "
+"was disabled in I2P release\n"
+"0.6; end-to-end (garlic) encryption (I2P client router to I2P server "
+"router) from Alice's router \"a\"\n"
+"to Bob's router \"h\" remains. Notice the different use of terms! All "
+"data from a to h is end-to-end\n"
+"encrypted, but the I2CP connection between the I2P router and the "
+"applications is not end-to-end\n"
+"encrypted! A and h are the routers of Alice and Bob, while Alice and Bob "
+"in following chart are the\n"
+"applications running atop of I2P."
+msgstr ""
+"El cifrado (I2CP) punto a punto  (aplicación cliente hacia aplicación "
+"servidor) fué deshabilitado\n"
+"en la versión 0.6 de I2P; el cifrado (garlic) punto a punto (router "
+"cliente I2P hacia router servidor\n"
+"I2P) desde el router de Alice \"a\" hasta el router de Bob \"h\" "
+"permanece. ¡Observa el diferente uso\n"
+"de términos! Todos los datos desde \"a\" hasta \"h\" están cifrados punto"
+" a punto, pero las conexiones\n"
+"I2CP entre el router I2P y las aplicaciones no son cifradas punto a "
+"punto. \"A\" y \"h\" son los routers\n"
+"de Alice y Bob, mientras que, y siguiendo el diagrama, Alice y Bob son "
+"las aplicaciones corriendo\n"
+"encima de I2P."
+
+#: i2p2www/pages/site/docs/how/intro.html:129
+msgid "End to end layered encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:131
+#, python-format
+msgid ""
+"The specific use of these algorithms are outlined elsewhere."
+msgstr ""
+"El uso específico de estos algoritmos está descrito en otra parte."
+
+#: i2p2www/pages/site/docs/how/intro.html:135
+msgid ""
+"The two main mechanisms for allowing people who need strong anonymity to "
+"use the network are\n"
+"explicitly delayed garlic routed messages and more comprehensive tunnels "
+"to include support for\n"
+"pooling and mixing messages. These are currently planned for release 3.0,"
+" but garlic routed messages\n"
+"with no delays and FIFO tunnels are currently in place. Additionally, the"
+" 2.0 release will allow\n"
+"people to set up and operate behind restricted routes (perhaps with "
+"trusted peers), as well as the\n"
+"deployment of more flexible and anonymous transports."
+msgstr ""
+"Los dos mecanismos principales que permiten usar la red a gente que "
+"necesita fuerte anonimato\n"
+"son explicitamente mensajes enrutados garlic con retardo y túneles más "
+"completos que incluyan\n"
+"agrupamiento y mezcla de mensajes. Estos están actualmente planeados para"
+" la release 3.0, pero\n"
+"los mensajes enrutados garlic sin retardo y túneles FIFO están ya "
+"implementados. Adicionalmente\n"
+"la release 2.0 permitirá a los usuarios establecerse y operar detrás de "
+"routers restrictivos (puede\n"
+"que con pares de confianza), así como el despliegue de transportes más "
+"flexibles y anónimos."
+
+#: i2p2www/pages/site/docs/how/intro.html:144
+#, python-format
+msgid ""
+"Some questions have been raised with regards to the scalability of I2P, "
+"and reasonably so. There\n"
+"will certainly be more analysis over time, but peer lookup and "
+"integration should be bounded by\n"
+"O(log(N)) due to the network "
+"database's algorithm, while end\n"
+"to end messages should be O(1) (scale free), since messages "
+"go out K hops through the\n"
+"outbound tunnel and another K hops through the inbound tunnel, with K no "
+"longer than 3. The size of\n"
+"the network (N) bears no impact."
+msgstr ""
+"Han surgido algunas preguntas referentes a la escalabilidad de I2P. Habrá"
+" ciertamente más\n"
+"análisis con el tiempo, pero la búsqueda e integración de pares debería "
+"ser limitado por\n"
+"O(log(N)) debido al algoritmo de base "
+"de datos de\n"
+"red, mientras que los mensajes punto a punto serían O(1)"
+" (escala libre),\n"
+"puesto que los mensajes pasan por K saltos a través del túnel de salida y"
+" otros K saltos por el\n"
+"túnel de entrada, donde K no es mayor de 3.  El tamaño de la red (N) no "
+"acarrea impacto."
+
+#: i2p2www/pages/site/docs/how/intro.html:153
+msgid "When?"
+msgstr "¿Cuándo?"
+
+#: i2p2www/pages/site/docs/how/intro.html:154
+#, fuzzy, python-format
+msgid ""
+"I2P initially began in Feb 2003 as a proposed modification to Freenet to allow it to use "
+"alternate transports, such as JMS, then grew into its own as an\n"
+"'anonCommFramework' in April 2003, turning into I2P in July, with code "
+"being written in earnest\n"
+"starting in August '03. I2P is currently under development, following the"
+" roadmap."
+msgstr ""
+"I2P comenzó inicialmente en 2003 como una propuesta de modificar\n"
+"Freenet para permitir el uso de"
+" transportes alternativos,\n"
+"como puede ser JMS, después\n"
+"se desarrolló con identidad propia como una 'anonCommFramework' en Abril "
+"de 2003,\n"
+"convirtiendose en I2P en Julio y comenzando a escribir código seriamente "
+"en Agosto de 2003.\n"
+"I2P está actualmente bajo desarrollo siguendo la hoja de ruta."
+
+#: i2p2www/pages/site/docs/how/intro.html:164
+msgid "Who?"
+msgstr "¿Quiénes?"
+
+#: i2p2www/pages/site/docs/how/intro.html:165
+#, python-format
+msgid ""
+"We have a small team spread around several "
+"continents, working to advance\n"
+"different aspects of the project. We are very open to other developers "
+"who want to get involved and\n"
+"anyone else who would like to contribute in other ways, such as "
+"critiques, peer review, testing,\n"
+"writing I2P enabled applications, or documentation. The entire system is "
+"open source - the router\n"
+"and most of the SDK are outright public domain with some BSD and Cryptix "
+"licensed code, while some\n"
+"applications like I2PTunnel and I2PSnark are GPL. Almost everything is "
+"written in Java (1.5+),\n"
+"though some third party applications are being written in Python and "
+"other languages. The code works\n"
+"on Sun Java SE and other Java Virtual"
+" Machines."
+msgstr ""
+"Tenemos un pequeño equipo desperdigado por "
+"varios continentes\n"
+"y trabajando en el avance de diferentes aspectos del proyecto. Estamos "
+"abiertos a otros\n"
+"desarrolladores que deseen involucrarse en el proyecto, y a cualquier "
+"otra persona que quiera\n"
+"contribuir de cualquier forma, como críticas, revisión de pares, pruebas,"
+" programación de\n"
+"aplicaciones compatibles I2P, o documentación. El sistema completo es "
+"código abierto - el\n"
+"router y la mayor parte del SDK tienen licencia de dominio público con "
+"algo de código licenciado\n"
+"con BSD y Cryptix, mientras que aplicaciones como I2PTunnel e I2PSnark "
+"son GPL. Casi todo\n"
+"está escrito en Java (1.5+), aunque algunas aplicaciones de terceros "
+"están siendo escritas en\n"
+"Python u otros lenguajes. El código funciona en Sun Java SE\n"
+"y otras máquinas virtuales Java."
+
+#: i2p2www/pages/site/docs/how/intro.html:176
+msgid "Where?"
+msgstr "¿Dónde?"
+
+#: i2p2www/pages/site/docs/how/intro.html:177
+#, python-format
+msgid ""
+"Anyone interested should join us on the IRC channel #i2p (hosted "
+"concurrently on irc.freenode.net,\n"
+"irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and "
+"irc.einirc.de). There are currently no\n"
+"scheduled development meetings, however archives"
+" are available."
+msgstr ""
+"Cualquiera interesado puede unirse a nosotros en el canal IRC #i2p "
+"(hospedado concurrentemente\n"
+"en irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, "
+"irc.welterde.i2p e irc.einirc.de). Actualmente\n"
+"no hay agenda de encuentros de desarrollo, no obstante hay archivos\n"
+"disponibles."
+
+#: i2p2www/pages/site/docs/how/intro.html:183
+#, python-format
+msgid "The current source is available in monotone."
+msgstr "El código actual está disponible en monotone."
+
+#: i2p2www/pages/site/docs/how/intro.html:188
+#, fuzzy, python-format
+msgid "See the Index to Technical Documentation."
+msgstr "Ver el Indice de la Documentación Técnica."
+
+#: i2p2www/pages/site/docs/how/network-database.html:2
+msgid "The Network Database"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:8
+msgid ""
+"I2P's netDb is a specialized distributed database, containing \n"
+"just two types of data - router contact information (RouterInfos) "
+"and destination contact\n"
+"information (LeaseSets). Each piece of data is signed by the "
+"appropriate party and verified\n"
+"by anyone who uses or stores it. In addition, the data has liveliness "
+"information\n"
+"within it, allowing irrelevant entries to be dropped, newer entries to "
+"replace\n"
+"older ones, and protection against certain classes of attack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:17
+msgid ""
+"The netDb is distributed with a simple technique called \"floodfill\",\n"
+"where a subset of all routers, called \"floodfill routers\", maintains "
+"the distributed database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:25
+msgid ""
+"When an I2P router wants to contact another router, they need to know "
+"some \n"
+"key pieces of data - all of which are bundled up and signed by the router"
+" into\n"
+"a structure called the \"RouterInfo\", which is distributed with the "
+"SHA256 of the router's identity\n"
+"as the key. The structure itself contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:32
+msgid ""
+"The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA "
+"signing key, and a certificate)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:33
+msgid ""
+"The contact addresses at which it can be reached (e.g. TCP: example.org "
+"port 4108)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:34
+msgid "When this was published"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:35
+msgid "A set of arbitrary text options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:36
+msgid "The signature of the above, generated by the identity's DSA signing key"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:39
+msgid ""
+"The following text options, while not strictly required, are expected\n"
+"to be present:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:45
+msgid ""
+"Capabilities flags - used to indicate floodfill participation, "
+"approximate bandwidth, and perceived reachability"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:48
+msgid "The core library version, always the same as the router version"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:51
+msgid ""
+"Basic network compatibility - A router will refuse to communicate with a "
+"peer having a different netId"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:54
+msgid "Used to determine compatibility with newer features and messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:57
+msgid ""
+"Always sent as 90m, for compatibility with an older scheme where routers "
+"published their actual uptime,\n"
+"and only sent tunnel requests to peers whose was more than 60m"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:62
+msgid ""
+"These values are used by other routers for basic decisions.\n"
+"Should we connect to this router? Should we attempt to route a tunnel "
+"through this router?\n"
+"The bandwidth capability flag, in particular, is used only to determine "
+"whether\n"
+"the router meets a minimum threshold for routing tunnels.\n"
+"Above the minimum threshold, the advertised bandwidth is not used or "
+"trusted anywhere\n"
+"in the router, except for display in the user interface and for debugging"
+" and network analysis."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:72
+#, python-format
+msgid ""
+"Additional text options include\n"
+"a small number of statistics about the router's health, which are "
+"aggregated by\n"
+"sites such as %(stats)s\n"
+"for network performance analysis and debugging.\n"
+"These statistics were chosen to provide data crucial to the developers,\n"
+"such as tunnel build success rates, while balancing the need for such "
+"data\n"
+"with the side-effects that could result from revealing this data.\n"
+"Current statistics are limited to:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:83
+msgid "Client and exploratory tunnel build success, reject, and timeout rates"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:84
+msgid "1 hour average number of participating tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:87
+msgid ""
+"The data published can be seen in the router's user interface,\n"
+"but is not used or trusted within the router.\n"
+"As the network has matured, we have gradually removed most of the "
+"published\n"
+"statistics to improve anonymity, and we plan to remove more in future "
+"releases."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:95
+msgid "RouterInfo specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:98
+msgid "RouterInfo Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:101
+msgid "RouterInfo Expiration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:102
+msgid ""
+"RouterInfos have no set expiration time.\n"
+"Each router is free to maintain its own local policy to trade off the "
+"frequency of RouterInfo lookups\n"
+"with memory or disk usage.\n"
+"In the current implementation, there are the following general policies:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:109
+msgid ""
+"There is no expiration during the first hour of uptime, as the persistent"
+" stored data may be old."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:112
+msgid "There is no expiration if there are 25 or less RouterInfos."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:115
+msgid ""
+"As the number of local RouterInfos grows, the expiration time shrinks, in"
+" an attempt to maintain\n"
+"a reasonable number RouterInfos. The expiration time with less than 120 "
+"routers is 72 hours,\n"
+"while expiration time with 300 routers is around 30 hours."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:120
+#, python-format
+msgid ""
+"RouterInfos containing SSU introducers expire in "
+"about an hour, as\n"
+"the introducer list expires in about that time."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:124
+msgid ""
+"Floodfills use a short expiration time (1 hour) for all local "
+"RouterInfos, as valid RouterInfos will\n"
+"be frequently republished to them."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:130
+msgid "RouterInfo Persistent Storage"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:132
+msgid ""
+"RouterInfos are periodically written to disk so that they are available "
+"after a restart."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:139
+msgid ""
+"The second piece of data distributed in the netDb is a \"LeaseSet\" - "
+"documenting\n"
+"a group of tunnel entry points (leases) for a particular client "
+"destination.\n"
+"Each of these leases specify the following information:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:145
+msgid "The tunnel gateway router (by specifying its identity)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:146
+msgid "The tunnel ID on that router to send messages with (a 4 byte number)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:147
+msgid "When that tunnel will expire."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:149
+msgid ""
+"The LeaseSet itself is stored in the netDb under\n"
+"the key derived from the SHA256 of the destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:154
+msgid "In addition to these leases, the LeaseSet includes:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:158
+msgid ""
+"The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA "
+"signing key and a certificate)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:159
+msgid ""
+"Additional encryption public key: used for end-to-end encryption of "
+"garlic messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:160
+msgid ""
+"Additional signing public key: intended for LeaseSet revocation, but is "
+"currently unused."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:161
+msgid ""
+"Signature of all the LeaseSet data, to make sure the Destination "
+"published the LeaseSet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:165
+msgid "Lease specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:167
+msgid "LeaseSet specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:170
+msgid "Lease Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:172
+msgid "LeaseSet Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:176
+msgid "Unpublished LeaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:177
+msgid ""
+"A LeaseSet for a destination used only for outgoing connections is "
+"unpublished.\n"
+"It is never sent for publication to a floodfill router.\n"
+"\"Client\" tunnels, such as those for web browsing and IRC clients, are "
+"unpublished.\n"
+"Servers will still be able to send messages back to those unpublished "
+"destinations,\n"
+"because of I2NP storage messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:187
+msgid "Revoked LeaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:188
+msgid ""
+"A LeaseSet may be revoked by publishing a new LeaseSet with zero "
+"leases.\n"
+"Revocations must be signed by the additional signing key in the LeaseSet."
+"\n"
+"Revocations are not fully implemented, and it is unclear if they have any"
+" practical use.\n"
+"This is the only planned use for that signing key, so it is currently "
+"unused."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:195
+msgid "Encrypted LeaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:196
+msgid ""
+"In an encrypted LeaseSet, all Leases are encrypted with a separate"
+" DSA key.\n"
+"The leases may only be decoded, and thus the destination may only be "
+"contacted,\n"
+"by those with the key.\n"
+"There is no flag or other direct indication that the LeaseSet is "
+"encrypted.\n"
+"Encrypted LeaseSets are not widely used, and it is a topic for future "
+"work to\n"
+"research whether the user interface and implementation of encrypted "
+"LeaseSets could be improved."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:205
+msgid "LeaseSet Expiration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:206
+msgid ""
+"All Leases (tunnels) are valid for 10 minutes; therefore, a LeaseSet "
+"expires\n"
+"10 minutes after the earliest creation time of all its Leases."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:211
+msgid "LeaseSet Persistent Storage"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:212
+msgid ""
+"There is no persistent storage of LeaseSet data since they expire so "
+"quickly."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:217
+msgid "Bootstrapping"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:218
+msgid ""
+"The netDb is decentralized, however you do need at\n"
+"least one reference to a peer so that the integration process\n"
+"ties you in. This is accomplished by \"reseeding\" your router with the "
+"RouterInfo\n"
+"of an active peer - specifically, by retrieving their "
+"routerInfo-$hash.dat\n"
+"file and storing it in your netDb/ directory. Anyone can "
+"provide\n"
+"you with those files - you can even provide them to others by exposing "
+"your own\n"
+"netDb directory. To simplify the process,\n"
+"volunteers publish their netDb directories (or a subset) on the regular "
+"(non-i2p) network,\n"
+"and the URLs of these directories are hardcoded in I2P.\n"
+"When the router starts up for the first time, it automatically fetches "
+"from\n"
+"one of these URLs, selected at random."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:232
+msgid "Floodfill"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:233
+msgid ""
+"The floodfill netDb is a simple distributed storage mechanism.\n"
+"The storage algorithm is simple: send the data to the closest peer that "
+"has advertised itself\n"
+"as a floodfill router. Then wait 10 seconds, pick another floodfill "
+"router and ask them \n"
+"for the entry to be sent, verifying its proper insertion / distribution. "
+"If the \n"
+"verification peer doesn't reply, or they don't have the entry, the sender"
+" \n"
+"repeats the process. When the peer in the floodfill netDb receives a "
+"netDb \n"
+"store from a peer not in the floodfill netDb, they send it to a subset of"
+" the floodfill netDb-peers.\n"
+"The peers selected are the ones closest (according to the XOR-metric) to a specific key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:244
+msgid ""
+"Determining who is part of the floodfill netDb is trivial - it is exposed"
+" in each \n"
+"router's published routerInfo as a capability."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:249
+msgid ""
+"Floodfills have no central authority and do not form a \"consensus\" -\n"
+"they only implement a simple DHT overlay."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:256
+msgid "Floodfill Router Opt-in"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:258
+msgid ""
+"Unlike Tor, where the directory servers are hardcoded and trusted,\n"
+"and operated by known entities,\n"
+"the members of the I2P floodfill peer set need not be trusted, and\n"
+"change over time."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:265
+msgid ""
+"To increase reliability of the netDb, and minimize the impact\n"
+"of netDb traffic on a router, floodfill is automatically enabled\n"
+"only on routers that are configured with high bandwidth limits.\n"
+"Routers with high bandwidth limits (which must be manually configured,\n"
+"as the default is much lower) are presumed to be on lower-latency\n"
+"connections, and are more likely to be available 24/7.\n"
+"The current minimum share bandwidth for a floodfill router is 128 "
+"KBytes/sec."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:275
+msgid ""
+"In addition, a router must pass several additional tests for health\n"
+"(outbound message queue time, job lag, etc.) before floodfill operation "
+"is\n"
+"automatically enabled."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:281
+#, python-format
+msgid ""
+"With the current rules for automatic opt-in, approximately 6% of\n"
+"the routers in the network are floodfill routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:286
+msgid ""
+"While some peers are manually configured to be floodfill,\n"
+"others are simply high-bandwidth routers who automatically volunteer\n"
+"when the number of floodfill peers drops below a threshold.\n"
+"This prevents any long-term network damage from losing most or all\n"
+"floodfills to an attack.\n"
+"In turn, these peers will un-floodfill themselves when there are\n"
+"too many floodfills outstanding."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:296
+msgid "Floodfill Router Roles"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:297
+msgid ""
+"A floodfill router's only services that are in addition to those of non-"
+"floodfill routers\n"
+"are in accepting netDb stores and responding to netDb queries.\n"
+"Since they are generally high-bandwidth, they are more likely to "
+"participate in a high number of tunnels\n"
+"(i.e. be a \"relay\" for others), but this is not directly related to "
+"their distributed database services."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:305
+msgid "Kademlia Closeness Metric"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:306
+msgid ""
+"The netDb uses a simple Kademlia-style XOR metric to determine closeness."
+"\n"
+"The SHA256 hash of the key being looked up or stored is XOR-ed with\n"
+"the hash of the router in question to determine closeness.\n"
+"A modification to this algorithm is done to increase the costs of Sybil attacks.\n"
+"Instead of the SHA256 hash of the key being looked up of stored, the "
+"SHA256 hash is taken\n"
+"of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:317
+msgid "Storage, Verification, and Lookup Mechanics"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:319
+msgid "RouterInfo Storage to Peers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:320
+#, python-format
+msgid ""
+"I2NP DatabaseStoreMessages containing the local "
+"RouterInfo are exchanged with peers\n"
+"as a part of the initialization of a NTCP\n"
+"or SSU transport connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:327
+msgid "LeaseSet Storage to Peers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:328
+#, python-format
+msgid ""
+"I2NP DatabaseStoreMessages containing the local "
+"LeaseSet are periodically exchanged with peers\n"
+"by bundling them in a garlic message along with normal traffic from the "
+"related Destination.\n"
+"This allows an initial response, and later responses, to be sent to an "
+"appropriate Lease,\n"
+"without requiring any LeaseSet lookups, or requiring the communicating "
+"Destinations to have published LeaseSets at all."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:336
+msgid "RouterInfo Storage to Floodfills"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:337
+#, python-format
+msgid ""
+"A router publishes its own RouterInfo by directly connecting to a "
+"floodfill router\n"
+"and sending it a I2NP DatabaseStoreMessage\n"
+"with a nonzero Reply Token. The message is not end-to-end garlic "
+"encrypted,\n"
+"as this is a direct connection, so there are no intervening routers\n"
+"(and no need to hide this data anyway).\n"
+"The floodfill router replies with a\n"
+"I2NP DeliveryStatusMessage,\n"
+"with the Message ID set to the value of the Reply Token."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:351
+msgid "LeaseSet Storage to Floodfills"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:352
+msgid ""
+"Storage of LeaseSets is much more sensitive than for RouterInfos, as a "
+"router\n"
+"must take care that the LeaseSet cannot be associated with the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:357
+#, python-format
+msgid ""
+"A router publishes a local LeaseSet by\n"
+"sending a I2NP DatabaseStoreMessage\n"
+"with a nonzero Reply Token over an outbound client tunnel for that "
+"Destination.\n"
+"The message is end-to-end garlic encrypted using the Destination's "
+"Session Key Manager,\n"
+"to hide the message from the tunnel's outbound endpoint.\n"
+"The floodfill router replies with a\n"
+"I2NP DeliveryStatusMessage,\n"
+"with the Message ID set to the value of the Reply Token.\n"
+"This message is sent back to one of the client's inbound tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:370
+msgid "Flooding"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:371
+msgid ""
+"After a floodfill router receives a DatabaseStoreMessage containing a\n"
+"valid RouterInfo or LeaseSet which is newer than that previously stored "
+"in its\n"
+"local NetDb, it \"floods\" it.\n"
+"To flood a NetDb entry, it looks up the 7 floodfill routers closest to "
+"the key\n"
+"of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or "
+"Destination with the date (yyyyMMdd) appended.)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:379
+#, python-format
+msgid ""
+"It then directly connects to each of the 7 peers\n"
+"and sends it a I2NP DatabaseStoreMessage\n"
+"with a zero Reply Token. The message is not end-to-end garlic encrypted,\n"
+"as this is a direct connection, so there are no intervening routers\n"
+"(and no need to hide this data anyway).\n"
+"The other routers do not reply or re-flood, as the Reply Token is zero."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:389
+msgid "RouterInfo and LeaseSet Lookup"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:390
+#, python-format
+msgid ""
+"The I2NP DatabaseLookupMessage is used to "
+"request a netdb entry from a floodfill router.\n"
+"Lookups are sent out one of the router's outbound exploratory tunnels.\n"
+"The replies are specified to return via one of the router's inbound "
+"exploratory tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:396
+msgid ""
+"Lookups are generally sent to the two \"good\" (the connection doesn't "
+"fail) floodfill routers closest to the requested key, in parallel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:400
+#, python-format
+msgid ""
+"If the key is found locally by the floodfill router, it responds with a\n"
+"I2NP DatabaseStoreMessage.\n"
+"If the key is not found locally by the floodfill router, it responds with"
+" a\n"
+"I2NP DatabaseSearchReplyMessage\n"
+"containing a list of other floodfill routers close to the key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:408
+msgid ""
+"Lookups are not encrypted and thus are vulnerable to snooping by the "
+"outbound endpoint\n"
+"(OBEP) of the client tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:413
+msgid ""
+"As the requesting router does not reveal itself, there is no recipient "
+"public key for the floodfill router to\n"
+"encrypt the reply with. Therefore, the reply is exposed to the inbound "
+"gateway (IBGW)\n"
+"of the inbound exploratory tunnel.\n"
+"An appropriate method of encrypting the reply is a topic for future work."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:420
+#, python-format
+msgid ""
+"(Reference: Hashing it out in Public Sections "
+"2.2-2.3 for terms below in italics)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:424
+msgid ""
+"Due to the relatively small size of the network and the flooding "
+"redundancy of 8x,\n"
+"lookups are usually O(1) rather than O(log n) --\n"
+"a router is highly likely to know a floodfill router close enough to the "
+"key to get the answer on the first try.\n"
+"In releases prior to 0.8.9, routers used a lookup redundancy of two\n"
+"(that is, two lookups were performed in parallel to different peers), and"
+"\n"
+"neither recursive nor iterative routing for lookups was "
+"implemented.\n"
+"Queries were sent through multiple routes simultaneously\n"
+"to reduce the chance of query failure."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:435
+msgid ""
+"As of release 0.8.9, iterative lookups are implemented with no "
+"lookup redundancy.\n"
+"This is a more efficient and reliable lookup that will work much better\n"
+"when not all floodfill peers are known, and it removes a serious\n"
+"limitation to network growth. As the network grows and each router knows "
+"only a small\n"
+"subset of the floodfill peers, lookups will become O(log n).\n"
+"Even if the peer does not return references closer to the key, the lookup"
+" continues with\n"
+"the next-closest peer, for added robustness, and to prevent a malicious "
+"floodfill from\n"
+"black-holing a part of the key space. Lookups continue until a total "
+"lookup timeout is reached,\n"
+"or the maximum number of peers is queried."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:447
+msgid ""
+"Node IDs are verifiable in that we use the router hash "
+"directly as both the node ID and the Kademlia key.\n"
+"Incorrect responses that are not closer to the search key are generally "
+"ignored.\n"
+"Given the current size of the network, a router has\n"
+"detailed knowledge of the neighborhood of the destination ID space."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:456
+msgid "RouterInfo Storage Verification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:457
+msgid ""
+"To verify a storage was successful, a router simply waits about 10 "
+"seconds,\n"
+"then sends a lookup to another floodfill router close to the key\n"
+"(but not the one the store was sent to).\n"
+"Lookups sent out one of the router's outbound exploratory tunnels.\n"
+"Lookups are end-to-end garlic encrypted to prevent snooping by the "
+"outbound endpoint(OBEP)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:465
+msgid "LeaseSet Storage Verification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:466
+msgid ""
+"To verify a storage was successful, a router simply waits about 10 "
+"seconds,\n"
+"then sends a lookup to another floodfill router close to the key\n"
+"(but not the one the store was sent to).\n"
+"Lookups sent out one of the outbound client tunnels for the destination "
+"of the LeaseSet being verified.\n"
+"To prevent snooping by the OBEP of the outbound tunnel,\n"
+"lookups are end-to-end garlic encrypted.\n"
+"The replies are specified to return via one of the client's inbound "
+"tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:476
+msgid ""
+"As for regular lookups, the reply is unencrypted,\n"
+"thus exposing the reply to the inbound gateway (IBGW) of the reply "
+"tunnel, and\n"
+"an appropriate method of encrypting the reply is a topic for future work."
+"\n"
+"As the IBGW for the reply is one of the gateways published in the "
+"LeaseSet,\n"
+"the exposure is minimal."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:486
+msgid "Exploration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:487
+#, python-format
+msgid ""
+"Exploration is a special form of netdb lookup, where a router "
+"attempts to learn about\n"
+"new routers.\n"
+"It does this by sending a floodfill router a I2NP DatabaseLookupMessage, looking for a random "
+"key.\n"
+"As this lookup will fail, the floodfill would normally respond with a\n"
+"I2NP DatabaseSearchReplyMessage containing "
+"hashes of floodfill routers close to the key.\n"
+"This would not be helpful, as the requesting router probably already "
+"knows those floodfills,\n"
+"and it would be impractical to add ALL floodfill routers to the \"don't "
+"include\" field of the lookup.\n"
+"For an exploration query, the requesting router adds a router hash of all"
+" zeros to the\n"
+"\"don't include\" field of the DatabaseLookupMessage.\n"
+"The floodfill will then respond only with non-floodfill routers close to "
+"the requested key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:501
+msgid "Notes on Lookup Responses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:502
+msgid ""
+"The response to a lookup request is either a Database Store Message (on "
+"success) or a\n"
+"Database Search Reply Message (on failure). The DSRM contains a 'from' "
+"router hash field\n"
+"to indicate the source of the reply; the DSM does not.\n"
+"The DSRM 'from' field is unauthenticated and may be spoofed or invalid.\n"
+"There are no other response tags. Therefore, when making multiple "
+"requests in parallel, it is\n"
+"difficult to monitor the performance of the various floodfill routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:512
+msgid "MultiHoming"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:514
+msgid ""
+"Destinations may be hosted on multiple routers simultaneously, by using "
+"the same\n"
+"private and public keys (traditionally stored in eepPriv.dat files).\n"
+"As both instances will periodically publish their signed LeaseSets to the"
+" floodfill peers,\n"
+"the most recently published LeaseSet will be returned to a peer "
+"requesting a database lookup.\n"
+"As LeaseSets have (at most) a 10 minute lifetime, should a particular "
+"instance go down,\n"
+"the outage will be 10 minutes at most, and generally much less than that."
+"\n"
+"The multihoming function has been verified and is in use by several "
+"services on the network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:524
+msgid "Threat Analysis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:525
+#, python-format
+msgid ""
+"Also discussed on the threat model "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:529
+msgid ""
+"A hostile user may attempt to harm the network by\n"
+"creating one or more floodfill routers and crafting them to offer\n"
+"bad, slow, or no responses.\n"
+"Some scenarios are discussed below."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:536
+msgid "General Mitigation Through Growth"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:537
+msgid ""
+"There are currently hundreds of floodfill routers in the network.\n"
+"Most of the following attacks will become more difficult, or have less "
+"impact,\n"
+"as the network size and number of floodfill routers increase."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:544
+msgid "General Mitigation Through Redundancy"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:545
+msgid ""
+"Via flooding, all netdb entries are stored on the 8 floodfill routers "
+"closest to the key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:550
+msgid "Forgeries"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:551
+msgid ""
+"All netdb entries are signed by their creators, so no router may forge a\n"
+"RouterInfo or LeaseSet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:556
+msgid "Slow or Unresponsive"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:557
+#, python-format
+msgid ""
+"Each router maintains an expanded set of statistics in the\n"
+"peer profile for each floodfill router,"
+"\n"
+"covering various quality metrics for that peer.\n"
+"The set includes:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:564
+msgid "Average response time"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:565
+msgid "Percentage of queries answered with the data requested"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:566
+msgid "Percentage of stores that were successfully verified"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:567
+msgid "Last successful store"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:568
+msgid "Last successful lookup"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:569
+msgid "Last response"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:572
+msgid ""
+"Each time a router needs to make a determination on which floodfill "
+"router is closest to a key,\n"
+"it uses these metrics to determine which floodfill routers are \"good\".\n"
+"The methods, and thresholds, used to determine \"goodness\" are "
+"relatively new, and\n"
+"are subject to further analysis and improvement.\n"
+"While a completely unresponsive router will quickly be identified and "
+"avoided,\n"
+"routers that are only sometimes malicious may be much harder to deal with."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:582
+msgid "Sybil Attack (Full Keyspace)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:583
+#, python-format
+msgid ""
+"An attacker may mount a Sybil attack\n"
+"by creating a large number of floodfill routers spread throughout the "
+"keyspace."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:588
+#, python-format
+msgid ""
+"(In a related example, a researcher recently created a\n"
+"large number of Tor relays.)\n"
+"If successful, this could be an effective DOS attack on the entire "
+"network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:594
+msgid ""
+"If the floodfills are not sufficiently misbehaving to be marked as "
+"\"bad\" using the peer profile\n"
+"metrics described above, this is a difficult scenario to handle.\n"
+"Tor's response can be much more nimble in the relay case, as the "
+"suspicious relays\n"
+"can be manually removed from the consensus.\n"
+"Some possible responses for the I2P network are listed below, however "
+"none of them is completely satisfactory:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:602
+msgid ""
+"Compile a list of bad router hashes or IPs, and announce the list through"
+" various means\n"
+"(console news, website, forum, etc.); users would have to manually "
+"download the list and\n"
+"add it to their local \"blacklist\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:607
+msgid ""
+"Ask everyone in the network to enable floodfill manually (fight Sybil "
+"with more Sybil)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:608
+msgid "Release a new software version that includes the hardcoded \"bad\" list"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:609
+msgid ""
+"Release a new software version that improves the peer profile metrics and"
+" thresholds,\n"
+"in an attempt to automatically identify the \"bad\" peers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:613
+msgid ""
+"Add software that disqualifies floodfills if too many of them are in a "
+"single IP block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:614
+msgid ""
+"Implement an automatic subscription-based blacklist controlled by a "
+"single individual or group.\n"
+"This would essentially implement a portion of the Tor \"consensus\" "
+"model.\n"
+"Unfortunately it would also give a single individual or group the power "
+"to\n"
+"block participation of any particular router or IP in the network,\n"
+"or even to completely shutdown or destroy the entire network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:623
+#: i2p2www/pages/site/docs/how/network-database.html:659
+msgid "This attack becomes more difficult as the network size grows."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:629
+msgid "Sybil Attack (Partial Keyspace)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:630
+#, python-format
+msgid ""
+"An attacker may mount a Sybil attack\n"
+"by creating a small number (8-15) of floodfill routers clustered closely "
+"in the keyspace,\n"
+"and distribute the RouterInfos for these routers widely.\n"
+"Then, all lookups and stores for a key in that keyspace would be directed"
+"\n"
+"to one of the attacker's routers.\n"
+"If successful, this could be an effective DOS attack on a particular "
+"eepsite, for example."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:639
+msgid ""
+"As the keyspace is indexed by the cryptographic (SHA256) Hash of the key,"
+"\n"
+"an attacker must use a brute-force method to repeatedly generate router "
+"hashes\n"
+"until he has enough that are sufficiently close to the key.\n"
+"The amount of computational power required for this, which is dependent "
+"on network\n"
+"size, is unknown."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:647
+msgid ""
+"As a partial defense against this attack,\n"
+"the algorithm used to determine Kademlia \"closeness\" varies over time.\n"
+"Rather than using the Hash of the key (i.e. H(k)) to determine closeness,"
+"\n"
+"we use the Hash of the key appended with the current date string, i.e. "
+"H(k + YYYYMMDD).\n"
+"A function called the \"routing key generator\" does this, which "
+"transforms the original key into a \"routing key\".\n"
+"In other words, the entire netdb keyspace \"rotates\" every day at UTC "
+"midnight.\n"
+"Any partial-keyspace attack would have to be regenerated every day, for\n"
+"after the rotation, the attacking routers would no longer be close\n"
+"to the target key, or to each other."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:663
+msgid ""
+"One consequence of daily keyspace rotation is that the distributed "
+"network database\n"
+"may become unreliable for a few minutes after the rotation --\n"
+"lookups will fail because the new \"closest\" router has not received a "
+"store yet.\n"
+"The extent of the issue, and methods for mitigation\n"
+"(for example netdb \"handoffs\" at midnight)\n"
+"are a topic for further study."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:673
+msgid "Bootstrap Attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:674
+msgid ""
+"An attacker could attempt to boot new routers into an isolated\n"
+"or majority-controlled network by taking over a reseed website,\n"
+"or tricking the developers into adding his reseed website\n"
+"to the hardcoded list in the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:681
+msgid "Several defenses are possible, and most of these are planned:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:685
+msgid ""
+"Disallow fallback from HTTPS to HTTP for reseeding.\n"
+"A MITM attacker could simply block HTTPS, then respond to the HTTP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:689
+msgid ""
+"Changing the reseed task to fetch a subset of RouterInfos from\n"
+"each of several reseed sites rather than using only a single site"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:693
+msgid ""
+"Creating an out-of-network reseed monitoring service that\n"
+"periodically polls reseed websites and verifies that the\n"
+"data are not stale or inconsistent with other views of the network"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:698
+msgid "Bundling reseed data in the installer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:701
+msgid "Query Capture"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:702
+#, python-format
+msgid ""
+"See also lookup\n"
+"(Reference: Hashing it out in Public Sections "
+"2.2-2.3 for terms below in italics)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:707
+msgid ""
+"Similar to a bootstrap attack, an attacker using a floodfill router could"
+" attempt to \"steer\"\n"
+"peers to a subset of routers controlled by him by returning their "
+"references."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:712
+msgid ""
+"This is unlikely to work via exploration, because exploration is a low-"
+"frequency task.\n"
+"Routers acquire a majority of their peer references through normal tunnel"
+" building activity.\n"
+"Exploration results are generally limited to a few router hashes,\n"
+"and each exploration query is directed to a random floodfill router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:719
+#, python-format
+msgid ""
+"As of release 0.8.9, iterative lookups are implemented.\n"
+"For floodfill router references returned in a\n"
+"I2NP DatabaseSearchReplyMessage\n"
+"response to a lookup,\n"
+"these references are followed if they are closer (or the next closest) to"
+" the lookup key.\n"
+"The requesting router does not trust that the references are\n"
+"closer to the key (i.e. they are verifiably correct.\n"
+"The lookup also does not stop when no closer key is found, but continues "
+"by querying the\n"
+"next-closet node, until the timeout or maximum number of queries is "
+"reached.\n"
+"This prevents a malicious floodfill from black-holing a part of the key "
+"space.\n"
+"Also, the daily keyspace rotation requires an attacker to regenerate a "
+"router info\n"
+"within the desired key space region.\n"
+"This design ensures that the query capture attack described in\n"
+"Hashing it out in Public\n"
+"is much more difficult."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:738
+msgid "DHT-Based Relay Selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:739
+#, python-format
+msgid "(Reference: Hashing it out in Public Section 3)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:743
+#, python-format
+msgid ""
+"This doesn't have much to do with floodfill, but see\n"
+"the peer selection page\n"
+"for a discussion of the vulnerabilities of peer selection for tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:749
+msgid "Information Leaks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:750
+#, python-format
+msgid ""
+"(Reference: In Search of an Anonymous and Secure "
+"Lookup Section 3)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:754
+#, python-format
+msgid ""
+"This paper addresses weaknesses in the \"Finger Table\" DHT lookups used "
+"by Torsk and NISAN.\n"
+"At first glance, these do not appear to apply to I2P. First, the use of "
+"DHT by Torsk and NISAN\n"
+"is significantly different from that in I2P. Second, I2P's network "
+"database lookups are only\n"
+"loosely correlated to the peer "
+"selection and\n"
+"tunnel building processes; only "
+"previously-known peers\n"
+"are used for tunnels.\n"
+"Also, peer selection is unrelated to any notion of DHT key-closeness."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:765
+msgid ""
+"Some of this may actually be more interesting when the I2P network gets "
+"much larger.\n"
+"Right now, each router knows a large proportion of the network, so "
+"looking up a particular\n"
+"Router Info in the network database is not strongly indicative of a "
+"future intent to use\n"
+"that router in a tunnel. Perhaps when the network is 100 times larger, "
+"the lookup may be\n"
+"more correlative. Of course, a larger network makes a Sybil attack that "
+"much harder."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:773
+#, python-format
+msgid ""
+"However, the general issue of DHT information leakage in I2P needs "
+"further investigation.\n"
+"The floodfill routers are in a position to observe queries and gather "
+"information.\n"
+"Certainly, at a level of f = 0.2 (20%% malicious nodes, as "
+"specifed in the paper)\n"
+"we expect that many of the Sybil threats we describe\n"
+"(here,\n"
+"here and\n"
+"here)\n"
+"become problematic for several reasons."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:787
+msgid "Moved to the netdb discussion page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:791
+msgid "End-to-end encryption of additional netDb lookups and responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:795
+msgid "Better methods for tracking lookup responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:2
+msgid "Peer Profiling and Selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:3
+#: i2p2www/pages/site/docs/transport/index.html:3
+msgid "July 2010"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:8
+msgid "Peer Profiling"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:10
+#, python-format
+msgid ""
+"Peer profiling is the process of collecting data based on the "
+"observed performance\n"
+"of other routers or peers, and classifying those peers into groups.\n"
+"Profiling does not use any claimed performance data published by "
+"the peer itself\n"
+"in the network database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:17
+msgid "Profiles are used for two purposes:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:19
+msgid "Selecting peers to relay our traffic through, which is discussed below"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:20
+#, python-format
+msgid ""
+"Choosing peers from the set of floodfill routers to use for network "
+"database storage and queries,\n"
+"which is discussed on the network database page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:27
+#: i2p2www/pages/site/docs/how/peer-selection.html:187
+#: i2p2www/pages/site/docs/tunnels/implementation.html:286
+msgid "Peer Selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:28
+msgid ""
+"Peer selection is the process of choosing which routers\n"
+"on the network we want to relay our messages to go through (which peers "
+"will we \n"
+"ask to join our tunnels).  To accomplish this, we keep track of how each\n"
+"peer performs (the peer's \"profile\") and use that data to estimate how"
+" \n"
+"fast they are, how often they will be able to accept our requests, and \n"
+"whether they seem to be overloaded or otherwise unable to perform what\n"
+"they agree to reliably."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:38
+#, python-format
+msgid ""
+"Unlike some other anonymous networks, in I2P,\n"
+"claimed bandwidth is untrusted and is only used to avoid those "
+"peers\n"
+"advertising very low bandwidth insufficient for routing tunnels.\n"
+"All peer selection is done through profiling.\n"
+"This prevents simple attacks based on peers claiming high bandwidth\n"
+"in order to capture large numbers of tunnels.\n"
+"It also makes\n"
+"timing attacks\n"
+"more difficult."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:50
+msgid ""
+"Peer selection is done quite frequently, as a router may maintain a large"
+" number\n"
+"of client and exploratory tunnels, and a tunnel lifetime is only 10 "
+"minutes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:56
+msgid "Further Information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:57
+#, python-format
+msgid ""
+"For more information see the paper\n"
+"Peer Profiling and Selection in the I2P Anonymous "
+"Network\n"
+"presented at PET-CON 2009.1.\n"
+"See below for notes on minor changes since the "
+"paper was published."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:65
+msgid "Profiles"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:66
+#, python-format
+msgid ""
+"Each peer has a set of data points collected about them, including "
+"statistics \n"
+"about how long it takes for them to reply to a network database query, "
+"how \n"
+"often their tunnels fail, and how many new peers they are able to "
+"introduce \n"
+"us to, as well as simple data points such as when we last heard from them"
+" or\n"
+"when the last communication error occurred.  The specific data points "
+"gathered\n"
+"can be found in the code."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:75
+msgid ""
+"Profiles are fairly small, a few KB. To control memory usage, the profile"
+" expiration time\n"
+"lessens as the number of profiles grows.\n"
+"Profiles are kept in memory until router shutdown, when they are written "
+"to disk.\n"
+"At startup, the profiles are read so the router need not reinitialize all"
+" profiles,\n"
+"thus allowing a router to quickly re-integrate into the network after "
+"startup."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:85
+msgid "Peer Summaries"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:86
+msgid ""
+"While the profiles themselves can be considered a summary of a peer's \n"
+"performance, to allow for effective peer selection we break each summary "
+"down \n"
+"into four simple values, representing the peer's speed, its capacity, how"
+" well \n"
+"integrated into the network it is, and whether it is failing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:93
+msgid "Speed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:94
+msgid ""
+"The speed calculation\n"
+"simply goes through the profile and estimates how much data we can\n"
+"send or receive on a single tunnel through the peer in a minute.  For "
+"this estimate it just looks at\n"
+"performance in the previous minute."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:101
+msgid "Capacity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:102
+msgid ""
+"The capacity calculation\n"
+"simply goes through the profile and estimates how many tunnels the peer\n"
+"would agree to participate in over a given time period.  For this "
+"estimate it looks at \n"
+"how many tunnel build requests\n"
+"the peer has accepted, rejected, and dropped, and how many\n"
+"of the agreed-to tunnels later failed.\n"
+"While the calculation is time-weighted so that recent activity counts "
+"more than later activity,\n"
+"statistics up to 48 hours old may be included."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:113
+msgid ""
+"Recognizing and avoiding unreliable and unreachable\n"
+"peers is critically important.\n"
+"Unfortunately, as the tunnel building and testing require the "
+"participation of several peers,\n"
+"it is difficult to positively identify the cause of a dropped build "
+"request or test failure.\n"
+"The router assigns a probability of failure to each of the\n"
+"peers, and uses that probability in the capacity calculation.\n"
+"Drops and test failures are weighted much higher than rejections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:123
+msgid "Peer organization"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:124
+msgid ""
+"As mentioned above, we drill through each peer's profile to come up with "
+"a \n"
+"few key calculations, and based upon those, we organize each peer into "
+"three\n"
+"groups - fast, high capacity, and standard."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:130
+msgid "The groupings are not mutually exclusive, nor are they unrelated:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:134
+msgid ""
+"A peer is considered \"high capacity\" if its capacity calculation meets "
+"or \n"
+"exceeds the median of all peers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:138
+msgid ""
+"A peer is considered \"fast\" if they are already \"high capacity\" and "
+"their \n"
+"speed calculation meets or exceeds the median of all peers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:142
+msgid "A peer is considered \"standard\" if it is not \"high capacity\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:145
+#, python-format
+msgid ""
+"These groupings are implemented in the router's\n"
+"ProfileOrganizer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:150
+msgid "Group size limits"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:151
+msgid "The size of the groups may be limited."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:156
+msgid ""
+"The fast group is limited to 30 peers.\n"
+"If there would be more, only the ones with the highest speed rating are "
+"placed in the group."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:160
+msgid ""
+"The high capacity group is limited to 75 peers (including the fast group)"
+"\n"
+"If there would be more, only the ones with the highest capacity rating "
+"are placed in the group."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:164
+msgid ""
+"The standard group has no fixed limit, but is somewhat smaller than the "
+"number of RouterInfos\n"
+"stored in the local network database.\n"
+"On an active router in today's network, there may be about 1000 "
+"RouterInfos and 500 peer profiles\n"
+"(including those in the fast and high capacity groups)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:172
+msgid "Recalculation and Stability"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:173
+msgid ""
+"Summaries are recalculated, and peers are resorted into groups, every 45 "
+"seconds."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:177
+msgid ""
+"The groups tend to be fairly stable, that is, there is not much \"churn\""
+" in the rankings\n"
+"at each recalculation.\n"
+"Peers in the fast and high capacity groups get more tunnels build through"
+" them, which increases their speed and capacity ratings,\n"
+"which reinforces their presence in the group."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:188
+msgid "The router selects peers from the above groups to build tunnels through."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:193
+msgid "Peer Selection for Client Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:194
+msgid ""
+"Client tunnels are used for application traffic, such as for HTTP proxies"
+" and web servers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:198
+msgid ""
+"To reduce the susceptibility to some attacks,\n"
+"and increase performance,\n"
+"peers for building client tunnels are chosen randomly from the smallest "
+"group, which is the \"fast\" group.\n"
+"There is no bias toward selecting peers that were previously participants"
+" in a tunnel for the same client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:206
+msgid "Peer Selection for Exploratory Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:207
+msgid ""
+"Exploratory tunnels are used for router administrative purposes, such as "
+"network database traffic\n"
+"and testing client tunnels.\n"
+"Exploratory tunnels are also used to contact previously unconnected "
+"routers, which is why\n"
+"they are called \"exploratory\".\n"
+"These tunnels are usually low-bandwidth."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:215
+msgid ""
+"Peers for building exploratory tunnels are generally chosen randomly from"
+" the standard group.\n"
+"If the success rate of these build attempts is low compared to the client"
+" tunnel build success rate,\n"
+"the router will select a weighted average of peers randomly from the high"
+" capacity group instead.\n"
+"This helps maintain a satisfactory build success rate even when network "
+"performance is poor.\n"
+"There is no bias toward selecting peers that were previously participants"
+" in an exploratory tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:223
+msgid ""
+"As the standard group includes a very large subset of all peers the "
+"router knows about,\n"
+"exploratory tunnels are essentially built through a random selection of "
+"all peers,\n"
+"until the build success rate becomes too low."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:231
+msgid "Restrictions"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:232
+msgid ""
+"To prevent some simple attacks, and for performance, there are the "
+"following restrictions:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:236
+msgid "Two peers from the same /16 IP space may not be in the same tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:239
+#, python-format
+msgid ""
+"A peer may participate in a maximum of 33% of all tunnels created by the "
+"router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:242
+msgid "Peers with extremely low bandwidth are not used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:245
+msgid "Peers for which a recent connection attempt failed are not used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:252
+msgid "Peer Ordering in Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:253
+#, python-format
+msgid ""
+"Peers are ordered within tunnels to\n"
+"to deal with the predecessor attack\n"
+"(2008 update).\n"
+"More information is on the tunnel "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:268
+msgid "Continue to analyze an tune speed and capacity calculations as necessary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:271
+msgid ""
+"Implement a more aggressive ejection strategy if necessary to control "
+"memory usage as the network grows"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:274
+msgid "Evaluate group size limits"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:277
+msgid "Use GeoIP data to include or exclude certain peers, if configured"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:283
+#, python-format
+msgid ""
+"For those reading the paper\n"
+"Peer Profiling and Selection in the I2P Anonymous "
+"Network,\n"
+"please keep in mind the following minor changes in I2P since the paper's "
+"publication:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:289
+msgid "The Integration calculation is still not used"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:290
+msgid "In the paper, \"groups\" are called \"tiers\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:291
+msgid "The \"Failing\" tier is no longer used"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:292
+msgid "The \"Not Failing\" tier is now named \"Standard\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:301
+msgid "One Cell Enough"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:303
+msgid "Tor Entry Guards"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:305
+msgid "Murdoch 2007 Paper"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:307
+msgid "Tune-up for Tor"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:309
+msgid "Low-resource Routing Attacks Against Tor"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:2
+msgid "Introducing I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:5
+msgid "I2P: A scalable framework for anonymous communication"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:7
+msgid "Table of Contents"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:9
+#: i2p2www/pages/site/docs/how/tech-intro.html:24
+#: i2p2www/pages/site/docs/transport/ssu.html:273
+msgid "Introduction"
+msgstr "Introducción"
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:11
+msgid "I2P Operation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:16
+#: i2p2www/pages/site/docs/how/tech-intro.html:401
+msgid "Transport protocols"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:25
+msgid ""
+"I2P is a scalable, self organizing, resilient packet switched anonymous \n"
+"network layer, upon which any number of different anonymity or security "
+"conscious \n"
+"applications can operate. Each of these applications may make their own "
+"anonymity, \n"
+"latency, and throughput tradeoffs without worrying about the proper "
+"implementation \n"
+"of a free route mixnet, allowing them to blend their activity with the "
+"larger \n"
+"anonymity set of users already running on top of I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:34
+msgid ""
+"Applications available already provide the full range of typical Internet"
+" activities -\n"
+"anonymous web browsing, web hosting, chat, file sharing, e-mail,\n"
+"blogging and content syndication, newsgroups, as well as several other "
+"applications under development."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:40
+msgid "Web browsing: using any existing browser that supports using a proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:41
+msgid "Chat: IRC, Jabber, I2P-Messenger."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:42
+msgid ""
+"File sharing: I2PSnark, Robert, iMule, \n"
+"I2Phex, PyBit, I2P-bt\n"
+"and others."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:47
+msgid ""
+"E-mail: susimail and I2P-Bote."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:48
+msgid ""
+"Blog: using e.g. the pebble plugin or the distributed blogging software "
+"Syndie."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:49
+msgid ""
+"Distributed Data Store: Save your data redundantly in the Tahoe-LAFS "
+"cloud over I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:50
+msgid "Newsgroups: using any newsgroup reader that supports using a proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:53
+msgid ""
+"Unlike web sites hosted within content distribution networks like Freenet \n"
+"or GNUnet, the services "
+"hosted on \n"
+"I2P are fully interactive - there are traditional web-style search "
+"engines, \n"
+"bulletin boards, blogs you can comment on, database driven sites, and "
+"bridges \n"
+"to query static systems like Freenet without needing to install it "
+"locally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:61
+msgid ""
+"With all of these anonymity enabled applications, I2P takes on the role \n"
+"of the message oriented middleware - applications say that they want to "
+"send \n"
+"some data to a cryptographic identifier (a \"destination\") and I2P takes"
+" care \n"
+"of making sure it gets there securely and anonymously. I2P also bundles a"
+" \n"
+"simple streaming library to allow I2P's "
+"anonymous \n"
+"best-effort messages to transfer as reliable, in-order streams, "
+"transparently \n"
+"offering a TCP based congestion control algorithm tuned for the high "
+"bandwidth \n"
+"delay product of the network. While there have been several simple SOCKS "
+"proxies \n"
+"available to tie existing applications into the network, their value has "
+"been \n"
+"limited as nearly every application routinely exposes what, in an "
+"anonymous \n"
+"context, is sensitive information. The only safe way to go is to fully "
+"audit \n"
+"an application to ensure proper operation and to assist in that we "
+"provide \n"
+"a series of APIs in various languages which can be used to make the most "
+"out \n"
+"of the network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:78
+#, python-format
+msgid ""
+"I2P is not a research project - academic, commercial, or governmental, "
+"but \n"
+"is instead an engineering effort aimed at doing whatever is necessary to "
+"provide \n"
+"a sufficient level of anonymity to those who need it. It has been in "
+"active \n"
+"development since early 2003 with one full time developer and a dedicated"
+" \n"
+"group of part time contributors from all over the world. All of the work "
+"done \n"
+"on I2P is open source and freely available on the website, \n"
+"with the majority of the code released outright into the public domain, "
+"though \n"
+"making use of a few cryptographic routines under BSD-style licenses. The "
+"people \n"
+"working on I2P do not control what people release client applications "
+"under, \n"
+"and there are several GPL'ed applications available (I2PTunnel, \n"
+"susimail, I2PSnark, I2P-"
+"Bote, \n"
+"I2Phex and others.).\n"
+"Funding for I2P comes entirely from "
+"donations,\n"
+"and does not receive any tax breaks in any jurisdiction at this time,\n"
+"as many of the developers are themselves anonymous."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:96
+msgid "Operation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:98
+msgid ""
+"To understand I2P's operation, it is essential to understand a few key "
+"concepts. \n"
+"First, I2P makes a strict separation between the software participating "
+"in \n"
+"the network (a \"router\") and the anonymous endpoints (\"destinations\")"
+" associated \n"
+"with individual applications. The fact that someone is running I2P is not"
+" \n"
+"usually a secret. What is hidden is information on what the user is "
+"doing, \n"
+"if anything at all, as well as what router a particular destination is "
+"connected \n"
+"to. End users will typically have several local destinations on their "
+"router \n"
+"- for instance, one proxying in to IRC servers, another supporting the "
+"user's \n"
+"anonymous webserver (\"eepsite\"), another for an I2Phex instance, "
+"another for \n"
+"torrents, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:111
+msgid ""
+"Another critical concept to understand is the \"tunnel\".\n"
+"A tunnel is a directed path through an explicitly selected list of "
+"routers.\n"
+"Layered encryption is used, so each of the routers can only decrypt a "
+"single layer.\n"
+"The decrypted information contains the IP of the next router, along with\n"
+"the encrypted information to be forwarded.\n"
+"Each tunnel has a starting point (the first router, also known as "
+"\"gateway\")\n"
+"and an end point. Messages can be sent only in one way. To send messages "
+"back,\n"
+"another tunnel is required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:122
+#: i2p2www/pages/site/docs/tunnels/implementation.html:105
+msgid "Inbound and outbound tunnel schematic"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:124
+msgid "Figure 1: Two types of tunnels exist: inbound and outbound."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:127
+msgid ""
+"Two types of tunnels exist:\n"
+"\"outbound\" tunnels send messages away from the tunnel creator,\n"
+"while \"inbound\" tunnels bring messages to the tunnel creator.\n"
+"Combining these two tunnels allows users to send messages to each other.\n"
+"The sender (\"Alice\" in the above image) sets up an outbound tunnel,\n"
+"while the receiver (\"Bob\" in the above image) creates an inbound "
+"tunnel.\n"
+"The gateway of an inbound tunnel can receive messages from any other user"
+"\n"
+"and will send them on until the endpoint (\"Bob\").\n"
+"The endpoint of the outbound tunnel will need to send the message\n"
+"on to the gateway of the inbound tunnel.\n"
+"To do this, the sender (\"Alice\") adds instructions to her encrypted "
+"message.\n"
+"Once the endpoint of the outbound tunnel decrypts the message,\n"
+"it will have instructions to forward the message to the correct\n"
+"inbound gateway (the gateway to \"Bob\")."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:144
+msgid ""
+"A third critical concept to understand is I2P's \"network "
+"database\" (or \"netDb\") \n"
+"- a pair of algorithms used to share network metadata. The two types of "
+"metadata \n"
+"carried are \"routerInfo\" and \"leaseSets\" - the "
+"routerInfo gives routers the \n"
+"data necessary for contacting a particular router (their public keys, "
+"transport \n"
+"addresses, etc), while the leaseSet gives routers the information "
+"necessary \n"
+"for contacting a particular destination. A leaseSet contains a number of "
+"\"leases\".\n"
+"Each of this leases specifies a tunnel gateway, which allows reaching a "
+"specific destination.\n"
+"The full information contained in a lease:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:155
+msgid "Inbound gateway for a tunnel that allows reaching a specific destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:156
+msgid "Time when a tunnel expires."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:157
+msgid ""
+"Pair of public keys to be able to encrypt messages (to send through the "
+"tunnel and reach the destination)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:159
+msgid ""
+"Routers themselves send their routerInfo to the netDb directly, while "
+"leaseSets are sent through outbound tunnels\n"
+"(leaseSets need to be sent anonymously, to avoid correlating a router "
+"with his leaseSets)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:164
+msgid ""
+"We can combine the above concepts to build successful connections in the "
+"network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:168
+msgid ""
+"To build up her own inbound and outbound tunnels, Alice does a lookup in "
+"the netDb to collect routerInfo.\n"
+"This way, she gathers lists of peers she can use as hops in her tunnels.\n"
+"She can then send a build message to the first hop, requesting the "
+"construction of a tunnel and asking\n"
+"that router to send the construction message onward, until the tunnel has"
+" been constructed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:175
+msgid "Request information on other routers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:177
+msgid "Build tunnel using router information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:179
+msgid "Figure 2: Router information is used to build tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:182
+msgid ""
+"When Alice wants to send a message to Bob, she first does a lookup in the"
+" \n"
+"netDb to find Bob's leaseSet, giving her his current inbound tunnel "
+"gateways. \n"
+"She then picks one of her outbound tunnels and sends the message down it "
+"with \n"
+"instructions for the outbound tunnel's endpoint to forward the message on"
+" \n"
+"to one of Bob's inbound tunnel gateways. When the outbound tunnel "
+"endpoint \n"
+"receives those instructions, it forwards the message as requested, and "
+"when \n"
+"Bob's inbound tunnel gateway receives it, it is forwarded down the tunnel"
+" \n"
+"to Bob's router. If Alice wants Bob to be able to reply to the message, "
+"she \n"
+"needs to transmit her own destination explicitly as part of the message "
+"itself.\n"
+"This can be done by introducing a higher-level layer, which is done in "
+"the\n"
+"streaming library.\n"
+"Alice may also cut down on the response time by bundling her most \n"
+"recent LeaseSet with the message so that Bob doesn't need to do a netDb "
+"lookup \n"
+"for it when he wants to reply, but this is optional."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:199
+msgid "Connect tunnels using LeaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:199
+msgid "Connect tunnels using leaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:201
+msgid "Figure 3: LeaseSets are used to connect outbound and inbound tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:204
+msgid ""
+"While the tunnels themselves have layered encryption to prevent "
+"unauthorized \n"
+"disclosure to peers inside the network (as the transport layer itself "
+"does \n"
+"to prevent unauthorized disclosure to peers outside the network), it is "
+"necessary \n"
+"to add an additional end to end layer of encryption to hide the message "
+"from \n"
+"the outbound tunnel endpoint and the inbound tunnel gateway. This \"garlic \n"
+"encryption\" lets Alice's router wrap up multiple messages into a "
+"single \n"
+"\"garlic message\", encrypted to a particular public key so that "
+"intermediary \n"
+"peers cannot determine either how many messages are within the garlic, "
+"what \n"
+"those messages say, or where those individual cloves are destined. For "
+"typical \n"
+"end to end communication between Alice and Bob, the garlic will be "
+"encrypted \n"
+"to the public key published in Bob's leaseSet, allowing the message to be"
+" \n"
+"encrypted without giving out the public key to Bob's own router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:219
+msgid ""
+"Another important fact to keep in mind is that I2P is entirely message "
+"based \n"
+"and that some messages may be lost along the way. Applications using I2P "
+"can \n"
+"use the message oriented interfaces and take care of their own congestion"
+" \n"
+"control and reliability needs, but most would be best served by reusing "
+"the \n"
+"provided streaming library to view I2P as "
+"a streams \n"
+"based network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:229
+msgid ""
+"Both inbound and outbound tunnels work along similar principles.\n"
+"The tunnel gateway accumulates a number of tunnel messages, eventually "
+"preprocessing \n"
+"them into something for tunnel delivery. Next, the gateway encrypts that "
+"preprocessed \n"
+"data and forwards it to the first hop. That peer and subsequent tunnel "
+"participants \n"
+"add on a layer of encryption after verifying that it isn't a duplicate "
+"before \n"
+"forward it on to the next peer. Eventually, the message arrives at the "
+"endpoint \n"
+"where the messages are split out again and forwarded on as requested. The"
+" \n"
+"difference arises in what the tunnel's creator does - for inbound "
+"tunnels, \n"
+"the creator is the endpoint and they simply decrypt all of the layers "
+"added, \n"
+"while for outbound tunnels, the creator is the gateway and they pre-"
+"decrypt \n"
+"all of the layers so that after all of the layers of per-hop encryption "
+"are \n"
+"added, the message arrives in the clear at the tunnel endpoint."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:244
+msgid ""
+"The choice of specific peers to pass on messages as well as their "
+"particular \n"
+"ordering is important to understanding both I2P's anonymity and "
+"performance \n"
+"characteristics. While the network database (below) has its own criteria "
+"for \n"
+"picking what peers to query and store entries on, tunnel creators may use"
+" any peers \n"
+"in the network in any order (and even any number of times) in a single "
+"tunnel. \n"
+"If perfect latency and capacity data were globally known, selection and "
+"ordering \n"
+"would be driven by the particular needs of the client in tandem with "
+"their \n"
+"threat model. Unfortunately, latency and capacity data is not trivial to "
+"gather \n"
+"anonymously, and depending upon untrusted peers to provide this "
+"information \n"
+"has its own serious anonymity implications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:257
+msgid ""
+"From an anonymity perspective, the simplest technique would be to pick "
+"peers \n"
+"randomly from the entire network, order them randomly and use those peers"
+" \n"
+"in that order for all eternity. From a performance perspective, the "
+"simplest \n"
+"technique would be to pick the fastest peers with the necessary spare "
+"capacity, \n"
+"spreading the load across different peers to handle transparent failover,"
+" \n"
+"and to rebuild the tunnel whenever capacity information changes. While "
+"the \n"
+"former is both brittle and inefficient, the later requires inaccessible "
+"information \n"
+"and offers insufficient anonymity. I2P is instead working on offering a "
+"range \n"
+"of peer selection strategies, coupled with anonymity aware measurement "
+"code \n"
+"to organize the peers by their profiles."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:270
+msgid ""
+"As a base, I2P is constantly profiling the peers with which it interacts"
+" \n"
+"with by measuring their indirect behavior - for instance, when a peer "
+"responds \n"
+"to a netDb lookup in 1.3 seconds, that round trip latency is recorded in "
+"the \n"
+"profiles for all of the routers involved in the two tunnels (inbound and "
+"outbound) \n"
+"through which the request and response passed, as well as the queried "
+"peer's \n"
+"profile. Direct measurement, such as transport layer latency or "
+"congestion, \n"
+"is not used as part of the profile, as it can be manipulated and "
+"associated \n"
+"with the measuring router, exposing them to trivial attacks. While "
+"gathering \n"
+"these profiles, a series of calculations are run on each to summarize its"
+" \n"
+"performance - its latency, capacity to handle lots of activity, whether "
+"they \n"
+"are currently overloaded, and how well integrated into the network they "
+"seem \n"
+"to be. These calculations are then compared for active peers to organize "
+"the \n"
+"routers into four tiers - fast and high capacity, high capacity, not "
+"failing, \n"
+"and failing. The thresholds for those tiers are determined dynamically, "
+"and \n"
+"while they currently use fairly simple algorithms, alternatives exist."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:288
+msgid ""
+"Using this profile data, the simplest reasonable peer selection strategy"
+" \n"
+"is to pick peers randomly from the top tier (fast and high capacity), and"
+" \n"
+"this is currently deployed for client tunnels. Exploratory tunnels (used "
+"for \n"
+"netDb and tunnel management) pick peers randomly from the \"not failing\""
+" tier \n"
+"(which includes routers in 'better' tiers as well), allowing the peer to "
+"sample \n"
+"routers more widely, in effect optimizing the peer selection through "
+"randomized \n"
+"hill climbing. These strategies alone do however leak information "
+"regarding \n"
+"the peers in the router's top tier through predecessor and netDb "
+"harvesting \n"
+"attacks. In turn, several alternatives exist which, while not balancing "
+"the \n"
+"load as evenly, will address the attacks mounted by particular classes of"
+" \n"
+"adversaries."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:302
+msgid ""
+"By picking a random key and ordering the peers according to their XOR "
+"distance \n"
+"from it, the information leaked is reduced in predecessor and harvesting "
+"attacks \n"
+"according to the peers' failure rate and the tier's churn. Another simple"
+" \n"
+"strategy for dealing with netDb harvesting attacks is to simply fix the "
+"inbound \n"
+"tunnel gateway(s) yet randomize the peers further on in the tunnels. To "
+"deal \n"
+"with predecessor attacks for adversaries which the client contacts, the "
+"outbound \n"
+"tunnel endpoints would also remain fixed. The selection of which peer to "
+"fix \n"
+"on the most exposed point would of course need to have a limit to the "
+"duration, \n"
+"as all peers fail eventually, so it could either be reactively adjusted "
+"or \n"
+"proactively avoided to mimic a measured mean time between failures of "
+"other \n"
+"routers. These two strategies can in turn be combined, using a fixed "
+"exposed \n"
+"peer and an XOR based ordering within the tunnels themselves. A more "
+"rigid \n"
+"strategy would fix the exact peers and ordering of a potential tunnel, "
+"only \n"
+"using individual peers if all of them agree to participate in the same "
+"way \n"
+"each time. This varies from the XOR based ordering in that the "
+"predecessor \n"
+"and successor of each peer is always the same, while the XOR only makes "
+"sure \n"
+"their order doesn't change."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:322
+#, python-format
+msgid ""
+"As mentioned before, I2P currently (release 0.8) includes the tiered \n"
+"random strategy above, with XOR-based ordering. A \n"
+"more detailed discussion of the mechanics involved in tunnel operation, "
+"management, \n"
+"and peer selection can be found in the tunnel "
+"spec."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:330
+#, python-format
+msgid ""
+"As mentioned earlier, I2P's netDb works to share the network's metadata.\n"
+"This is detailed in the network database page,\n"
+"but a basic explanation is available below."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:336
+msgid ""
+"A percentage of I2P users are appointed as 'floodfill peers'.\n"
+"Currently, I2P installations that have a lot of bandwidth and are fast "
+"enough,\n"
+"will appoint themselves as floodfill as soon as the number of existing "
+"floodfill routers\n"
+"drops too low."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:343
+#, python-format
+msgid ""
+"Other I2P routers will store their data and lookup data by sending simple"
+" 'store' and 'lookup' queries to the floodfills.\n"
+"If a floodfill router receives a 'store' query, it will spread the "
+"information to other floodfill routers\n"
+"using the Kademlia "
+"algorithm.\n"
+"The 'lookup' queries currently function differently, to avoid an "
+"important\n"
+"security issue.\n"
+"When a lookup is done, the floodfill router will not forward the lookup "
+"to other peers,\n"
+"but will always answer by itself (if it has the requested data)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:353
+msgid "Two types of information are stored in the network database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:357
+msgid ""
+"A RouterInfo stores information on a specific I2P router and how "
+"to contact it"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:358
+msgid ""
+"A LeaseSet stores information on a specific destination (e.g. I2P "
+"website, e-mail server...)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:360
+msgid ""
+"All of this information is signed by the publishing party and verified by"
+" any I2P router using or storing the information.\n"
+"In addition, the data contains timing information, to avoid storage of "
+"old entries and possible attacks.\n"
+"This is also why I2P bundles the necessary code for maintaining the "
+"correct time, occasionally querying some SNTP servers \n"
+"(the pool.ntp.org round robin by"
+" default)\n"
+"and detecting skew between routers at the transport layer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:368
+msgid "Some additional remarks are also important."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:373
+msgid "Unpublished and encrypted leasesets:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:374
+msgid ""
+"One could only want specific people to be able to reach a destination.\n"
+"This is possible by not publishing the destination in the netDb. You will"
+" however have to transmit the destination by other means.\n"
+"An alternative are the 'encrypted leaseSets'. These leaseSets can only be"
+" decoded by people with access to the decryption key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:381
+msgid "Bootstrapping:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:382
+msgid ""
+"Bootstrapping the netDb is quite simple. Once a router manages to receive"
+" a single routerInfo of a reachable peer,\n"
+"it can query that router for references to other routers in the network.\n"
+"Currently, a number of users post their routerInfo files to a website to "
+"make this information available.\n"
+"I2P automatically connects to one of these websites to gather routerInfo "
+"files and bootstrap."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:390
+msgid "Lookup scalability:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:391
+msgid ""
+"Lookups in the I2P network are not forwarded to other netDb routers.\n"
+"Currently, this is not a major problem, since the network is not very "
+"large.\n"
+"However, as the network grows, not all routerInfo and leaseSet files will"
+" be present\n"
+"on each netDb router. This will cause a deterioration of the percentage "
+"of successful lookups.\n"
+"Because of this, refinements to the netDb will be done in the next "
+"releases."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:402
+msgid ""
+"Communication between routers needs to provide confidentiality and "
+"integrity \n"
+"against external adversaries while authenticating that the router "
+"contacted \n"
+"is the one who should receive a given message. The particulars of how "
+"routers \n"
+"communicate with other routers aren't critical - three separate protocols"
+" \n"
+"have been used at different points to provide those bare necessities."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:410
+#, python-format
+msgid ""
+"I2P started with a TCP-based protocol which \n"
+"has since been disabled. Then, to accommodate the need for high degree "
+"communication \n"
+"(as a number of routers will end up speaking with many others), I2P moved"
+" \n"
+"from a TCP based transport to a UDP-based one - "
+"\"Secure \n"
+"Semireliable UDP\", or \"SSU\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:418
+#, python-format
+msgid "As described in the SSU spec:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:422
+msgid ""
+"The goal of this protocol is to provide secure, authenticated, \n"
+"semireliable and unordered message delivery, exposing only a minimal "
+"amount \n"
+"of data easily discernible to third parties. It should support high "
+"degree \n"
+"communication as well as TCP-friendly congestion control and may include"
+" \n"
+"PMTU detection. It should be capable of efficiently moving bulk data at "
+"rates \n"
+"sufficient for home users. In addition, it should support techniques for "
+"addressing \n"
+"network obstacles, like most NATs or firewalls."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:432
+#, python-format
+msgid ""
+"Following the introduction of SSU, after issues with congestion collapse"
+" \n"
+"appeared, a new NIO-based TCP transport called NTCP \n"
+"was implemented. It is enabled by default for outbound connections only. "
+"Those \n"
+"who configure their NAT/firewall to allow inbound connections and specify"
+" \n"
+"the external host and port (dyndns/etc is ok) on /config.jsp can receive "
+"inbound \n"
+"connections. As NTCP is NIO based, so it doesn't suffer from the 1 thread"
+" \n"
+"per connection issues of the old TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:442
+msgid ""
+"I2P supports multiple transports simultaneously. A particular transport \n"
+"for an outbound connection is selected with \"bids\". Each transport bids"
+" for \n"
+"the connection and the relative value of these bids assigns the priority."
+" \n"
+"Transports may reply with different bids, depending on whether there is "
+"already \n"
+"an established connection to the peer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:450
+#, python-format
+msgid ""
+"The current implementation ranks NTCP as the highest-priority transport \n"
+"for outbound connections in most situations. SSU is enabled for both "
+"outbound \n"
+"and inbound connections. Your firewall and your I2P router must be "
+"configured \n"
+"to allow inbound NTCP connections. For further information see the NTCP \n"
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:459
+msgid ""
+"A bare minimum set of cryptographic primitives are combined together to \n"
+"provide I2P's layered defenses against a variety of adversaries. At the "
+"lowest \n"
+"level, inter router communication is protected by the transport layer "
+"security \n"
+"- SSU encrypts each packet with AES256/CBC with both an explicit IV and "
+"MAC \n"
+"(HMAC-MD5-128) after agreeing upon an ephemeral session key through a "
+"2048bit \n"
+"Diffie-Hellman exchange, station-to-station authentication with the other"
+" \n"
+"router's DSA key, plus each network message has their own hash for local "
+"integrity \n"
+"checking. Tunnel messages passed over the "
+"transports \n"
+"have their own layered AES256/CBC encryption with an explicit IV and "
+"verified \n"
+"at the tunnel endpoint with an additional SHA256 hash. Various other "
+"messages \n"
+"are passed along inside \"garlic messages\", which are encrypted with "
+"ElGamal/AES+SessionTags \n"
+"(explained below)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:474
+msgid "Garlic messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:475
+msgid ""
+"Garlic messages are an extension of \"onion\" layered encryption, "
+"allowing \n"
+"the contents of a single message to contain multiple \"cloves\" - fully "
+"formed \n"
+"messages alongside their own instructions for delivery. Messages are "
+"wrapped \n"
+"into a garlic message whenever the message would otherwise be passing in "
+"cleartext \n"
+"through a peer who should not have access to the information - for "
+"instance, \n"
+"when a router wants to ask another router to participate in a tunnel, "
+"they \n"
+"wrap the request inside a garlic, encrypt that garlic to the receiving "
+"router's \n"
+"2048bit ElGamal public key, and forward it through a tunnel. Another "
+"example \n"
+"is when a client wants to send a message to a destination - the sender's "
+"router \n"
+"will wrap up that data message (alongside some other messages) into a "
+"garlic, \n"
+"encrypt that garlic to the 2048bit ElGamal public key published in the "
+"recipient's \n"
+"leaseSet, and forward it through the appropriate tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:490
+msgid ""
+"The \"instructions\" attached to each clove inside the encryption layer "
+"includes \n"
+"the ability to request that the clove be forwarded locally, to a remote "
+"router, \n"
+"or to a remote tunnel on a remote router. There are fields in those "
+"instructions \n"
+"allowing a peer to request that the delivery be delayed until a certain "
+"time \n"
+"or condition has been met, though they won't be honored until the nontrivial \n"
+"delays are deployed. It is possible to explicitly route garlic "
+"messages \n"
+"any number of hops without building tunnels, or even to reroute tunnel "
+"messages \n"
+"by wrapping them in garlic messages and forwarding them a number of hops "
+"prior \n"
+"to delivering them to the next hop in the tunnel, but those techniques "
+"are \n"
+"not currently used in the existing implementation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:503
+msgid "Session tags"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:504
+msgid ""
+"As an unreliable, unordered, message based system, I2P uses a simple "
+"combination \n"
+"of asymmetric and symmetric encryption algorithms to provide data "
+"confidentiality \n"
+"and integrity to garlic messages. As a whole, the combination is referred"
+" \n"
+"to as ElGamal/AES+SessionTags, but that is an excessively verbose way to "
+"describe \n"
+"the simple use of 2048bit ElGamal, AES256, SHA256 and 32 byte nonces."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:543
+msgid ""
+"Session tags themselves have a very short lifetime, after which they are"
+" \n"
+"discarded if not used. In addition, the quantity stored for each key is "
+"limited, \n"
+"as are the number of keys themselves - if too many arrive, either new or "
+"old \n"
+"messages may be dropped. The sender keeps track whether messages using "
+"session \n"
+"tags are getting through, and if there isn't sufficient communication it "
+"may \n"
+"drop the ones previously assumed to be properly delivered, reverting back"
+" \n"
+"to the full expensive ElGamal encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:553
+msgid ""
+"One alternative is to transmit only a single session tag, and from that,"
+" \n"
+"seed a deterministic PRNG for determining what tags to use or expect. By "
+"keeping \n"
+"this PRNG roughly synchronized between the sender and recipient (the "
+"recipient \n"
+"precomputes a window of the next e.g. 50 tags), the overhead of "
+"periodically \n"
+"bundling a large number of tags is removed, allowing more options in the "
+"space/time \n"
+"tradeoff, and perhaps reducing the number of ElGamal encryptions "
+"necessary. \n"
+"However, it would depend upon the strength of the PRNG to provide the "
+"necessary \n"
+"cover against internal adversaries, though perhaps by limiting the amount"
+" \n"
+"of times each PRNG is used, any weaknesses can be minimized. At the "
+"moment, \n"
+"there are no immediate plans to move towards these synchronized PRNGs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:566
+msgid "Future"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:567
+msgid ""
+"While I2P is currently functional and sufficient for many scenarios, "
+"there \n"
+"are several areas which require further improvement to meet the needs of "
+"those \n"
+"facing more powerful adversaries as well as substantial user experience "
+"optimization."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:573
+msgid "Restricted route operation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:574
+msgid ""
+"I2P is an overlay network designed to be run on top of a functional "
+"packet \n"
+"switched network, exploiting the end to end principle to offer anonymity "
+"and \n"
+"security. While the Internet no longer fully embraces the end to end "
+"principle\n"
+"(due to the usage of NAT), \n"
+"I2P does require a substantial portion of the network to be reachable - "
+"there \n"
+"may be a number of peers along the edges running using restricted routes,"
+" \n"
+"but I2P does not include an appropriate routing algorithm for the "
+"degenerate \n"
+"case where most peers are unreachable. It would, however work on top of a"
+" \n"
+"network employing such an algorithm."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:586
+msgid ""
+"Restricted route operation, where there are limits to what peers are "
+"reachable \n"
+"directly, has several different functional and anonymity implications, "
+"dependent \n"
+"upon how the restricted routes are handled. At the most basic level, "
+"restricted \n"
+"routes exist when a peer is behind a NAT or firewall which does not allow"
+" \n"
+"inbound connections. This was largely addressed in I2P 0.6.0.6 by "
+"integrating \n"
+"distributed hole punching into the transport layer, allowing people "
+"behind \n"
+"most NATs and firewalls to receive unsolicited connections without any "
+"configuration. \n"
+"However, this does not limit the exposure of the peer's IP address to "
+"routers \n"
+"inside the network, as they can simply get introduced to the peer through"
+" \n"
+"the published introducer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:599
+msgid ""
+"Beyond the functional handling of restricted routes, there are two levels"
+" \n"
+"of restricted operation that can be used to limit the exposure of one's "
+"IP \n"
+"address - using router-specific tunnels for communication, and offering "
+"'client \n"
+"routers'. For the former, routers can either build a new pool of tunnels "
+"or \n"
+"reuse their exploratory pool, publishing the inbound gateways to some of "
+"them \n"
+"as part of their routerInfo in place of their transport addresses. When a"
+" \n"
+"peer wants to get in touch with them, they see those tunnel gateways in "
+"the \n"
+"netDb and simply send the relevant message to them through one of the "
+"published \n"
+"tunnels. If the peer behind the restricted route wants to reply, it may "
+"do \n"
+"so either directly (if they are willing to expose their IP to the peer) "
+"or \n"
+"indirectly through their outbound tunnels. When the routers that the peer"
+" \n"
+"has direct connections to want to reach it (to forward tunnel messages, "
+"for \n"
+"instance), they simply prioritize their direct connection over the "
+"published \n"
+"tunnel gateway. The concept of 'client routers' simply extends the "
+"restricted \n"
+"route by not publishing any router addresses. Such a router would not "
+"even \n"
+"need to publish their routerInfo in the netDb, merely providing their "
+"self \n"
+"signed routerInfo to the peers that it contacts (necessary to pass the "
+"router's \n"
+"public keys). Both levels of restricted route operation are planned for "
+"I2P \n"
+"2.0."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:621
+msgid ""
+"There are tradeoffs for those behind restricted routes, as they would "
+"likely \n"
+"participate in other people's tunnels less frequently, and the routers "
+"which \n"
+"they are connected to would be able to infer traffic patterns that would "
+"not \n"
+"otherwise be exposed. On the other hand, if the cost of that exposure is "
+"less \n"
+"than the cost of an IP being made available, it may be worthwhile. This, "
+"of \n"
+"course, assumes that the peers that the router behind a restricted route "
+"contacts \n"
+"are not hostile - either the network is large enough that the probability"
+" \n"
+"of using a hostile peer to get connected is small enough, or trusted (and"
+" \n"
+"perhaps temporary) peers are used instead."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:633
+msgid "Variable latency"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:634
+msgid ""
+"Even though the bulk of I2P's initial efforts have been on low latency "
+"communication, \n"
+"it was designed with variable latency services in mind from the "
+"beginning. \n"
+"At the most basic level, applications running on top of I2P can offer the"
+" \n"
+"anonymity of medium and high latency communication while still blending "
+"their \n"
+"traffic patterns in with low latency traffic. Internally though, I2P can "
+"offer \n"
+"its own medium and high latency communication through the garlic "
+"encryption \n"
+"- specifying that the message should be sent after a certain delay, at a "
+"certain \n"
+"time, after a certain number of messages have passed, or another mix "
+"strategy. \n"
+"With the layered encryption, only the router that the clove exposed the "
+"delay \n"
+"request would know that the message requires high latency, allowing the "
+"traffic \n"
+"to blend in further with the low latency traffic. Once the transmission "
+"precondition \n"
+"is met, the router holding on to the clove (which itself would likely be "
+"a \n"
+"garlic message) simply forwards it as requested - to a router, to a "
+"tunnel, \n"
+"or, most likely, to a remote client destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:651
+msgid ""
+"There are a substantial number of ways to exploit this capacity for high"
+" \n"
+"latency comm in I2P, but for the moment, doing so has been scheduled for "
+"the \n"
+"I2P 3.0 release. In the meantime, those requiring the anonymity that high"
+" \n"
+"latency comm can offer should look towards the application layer to "
+"provide \n"
+"it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:659
+msgid "Open questions"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:661
+msgid "How to get rid of the timing constraint?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:662
+msgid "Can we deal with the sessionTags more efficiently?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:663
+msgid ""
+"What, if any, batching/mixing strategies should be made available on the "
+"tunnels?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:664
+msgid ""
+"What other tunnel peer selection and ordering strategies should be "
+"available?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:667
+msgid "Similar systems"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:669
+msgid ""
+"I2P's architecture builds on the concepts of message oriented middleware,"
+" \n"
+"the topology of DHTs, the anonymity and cryptography of free route "
+"mixnets, \n"
+"and the adaptability of packet switched networking. The value comes not "
+"from \n"
+"novel concepts of algorithms though, but from careful engineering "
+"combining \n"
+"the research results of existing systems and papers. While there are a "
+"few \n"
+"similar efforts worth reviewing, both for technical and functional "
+"comparisons, \n"
+"two in particular are pulled out here - Tor and Freenet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:679
+#, python-format
+msgid "See also the Network Comparisons Page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:684
+#: i2p2www/pages/site/docs/how/tech-intro.html:749
+msgid "website"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:686
+msgid ""
+"At first glance, Tor and I2P have many functional and anonymity related \n"
+"similarities. While I2P's development began before we were aware of the "
+"early \n"
+"stage efforts on Tor, many of the lessons of the original onion routing "
+"and \n"
+"ZKS efforts were integrated into I2P's design. Rather than building an "
+"essentially \n"
+"trusted, centralized system with directory servers, I2P has a self "
+"organizing \n"
+"network database with each peer taking on the responsibility of profiling"
+" \n"
+"other routers to determine how best to exploit available resources. "
+"Another \n"
+"key difference is that while both I2P and Tor use layered and ordered "
+"paths \n"
+"(tunnels and circuits/streams), I2P is fundamentally a packet switched "
+"network, \n"
+"while Tor is fundamentally a circuit switched one, allowing I2P to "
+"transparently \n"
+"route around congestion or other network failures, operate redundant "
+"pathways, \n"
+"and load balance the data across available resources. While Tor offers "
+"the \n"
+"useful outproxy functionality by offering integrated outproxy discovery "
+"and \n"
+"selection, I2P leaves such application layer decisions up to applications"
+" \n"
+"running on top of I2P - in fact, I2P has even externalized the TCP-like "
+"streaming \n"
+"library itself to the application layer, allowing developers to "
+"experiment \n"
+"with different strategies, exploiting their domain specific knowledge to "
+"offer \n"
+"better performance."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:707
+msgid ""
+"From an anonymity perspective, there is much similarity when the core "
+"networks \n"
+"are compared. However, there are a few key differences. When dealing with"
+" \n"
+"an internal adversary or most external adversaries, I2P's simplex tunnels"
+" \n"
+"expose half as much traffic data than would be exposed with Tor's duplex "
+"circuits \n"
+"by simply looking at the flows themselves - an HTTP request and response "
+"would \n"
+"follow the same path in Tor, while in I2P the packets making up the "
+"request \n"
+"would go out through one or more outbound tunnels and the packets making "
+"up \n"
+"the response would come back through one or more different inbound "
+"tunnels. \n"
+"While I2P's peer selection and ordering strategies should sufficiently "
+"address \n"
+"predecessor attacks, should a switch to bidirectional tunnels be "
+"necessary,\n"
+"we could simply build an inbound and outbound tunnel along the same "
+"routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:721
+msgid ""
+"Another anonymity issue comes up in Tor's use of telescopic tunnel "
+"creation, \n"
+"as simple packet counting and timing measurements as the cells in a "
+"circuit \n"
+"pass through an adversary's node exposes statistical information "
+"regarding \n"
+"where the adversary is within the circuit. I2P's unidirectional tunnel "
+"creation \n"
+"with a single message so that this data is not exposed. Protecting the "
+"position \n"
+"in a tunnel is important, as an adversary would otherwise be able to "
+"mount \n"
+"a series of powerful predecessor, intersection, and traffic confirmation "
+"attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:731
+msgid ""
+"Tor's support for a second tier of \"onion proxies\" does offer a non-"
+"trivial \n"
+"degree of anonymity while requiring a low cost of entry, while I2P will "
+"not \n"
+"offer this topology until 2.0."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:737
+msgid ""
+"On the whole, Tor and I2P complement each other in their focus - Tor "
+"works \n"
+"towards offering high speed anonymous Internet outproxying, while I2P "
+"works \n"
+"towards offering a decentralized resilient network in itself. In theory, "
+"both \n"
+"can be used to achieve both purposes, but given limited development "
+"resources, \n"
+"they both have their strengths and weaknesses. The I2P developers have "
+"considered \n"
+"the steps necessary to modify Tor to take advantage of I2P's design, but "
+"concerns \n"
+"of Tor's viability under resource scarcity suggest that I2P's packet "
+"switching \n"
+"architecture will be able to exploit scarce resources more effectively."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:751
+msgid ""
+"Freenet played a large part in the initial stages of I2P's design - "
+"giving \n"
+"proof to the viability of a vibrant pseudonymous community completely "
+"contained \n"
+"within the network, demonstrating that the dangers inherent in outproxies"
+" \n"
+"could be avoided. The first seed of I2P began as a replacement "
+"communication \n"
+"layer for Freenet, attempting to factor out the complexities of a "
+"scalable, \n"
+"anonymous and secure point to point communication from the complexities "
+"of \n"
+"a censorship resistant distributed data store. Over time however, some of"
+" \n"
+"the anonymity and scalability issues inherent in Freenet's algorithms "
+"made \n"
+"it clear that I2P's focus should stay strictly on providing a generic "
+"anonymous \n"
+"communication layer, rather than as a component of Freenet. Over the "
+"years, \n"
+"the Freenet developers have come to see the weaknesses in the older "
+"design, \n"
+"prompting them to suggest that they will require a \"premix\" layer to "
+"offer \n"
+"substantial anonymity. In other words, Freenet needs to run on top of a "
+"mixnet \n"
+"such as I2P or Tor, with \"client nodes\" requesting and publishing data "
+"through \n"
+"the mixnet to the \"server nodes\" which then fetch and store the data "
+"according \n"
+"to Freenet's heuristic distributed data storage algorithms."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:770
+msgid ""
+"Freenet's functionality is very complementary to I2P's, as Freenet "
+"natively \n"
+"provides many of the tools for operating medium and high latency systems,"
+" \n"
+"while I2P natively provides the low latency mix network suitable for "
+"offering \n"
+"adequate anonymity. The logic of separating the mixnet from the "
+"censorship-\n"
+"resistant distributed data store still seems self-evident from an "
+"engineering, \n"
+"anonymity, security, and resource allocation perspective, so hopefully "
+"the \n"
+"Freenet team will pursue efforts in that direction, if not simply reusing"
+" \n"
+"(or helping to improve, as necessary) existing mixnets like I2P or Tor."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:781
+msgid ""
+"It is worth mentioning that there has recently been discussion and work \n"
+"by the Freenet developers on a \"globally scalable darknet\" using "
+"restricted \n"
+"routes between peers of various trust. While insufficient information has"
+" \n"
+"been made publicly available regarding how such a system would operate "
+"for \n"
+"a full review, from what has been said the anonymity and scalability "
+"claims \n"
+"seem highly dubious. In particular, the appropriateness for use in "
+"hostile \n"
+"regimes against state level adversaries has been tremendously overstated,"
+" \n"
+"and any analysis on the implications of resource scarcity upon the "
+"scalability \n"
+"of the network has seemingly been avoided. Further questions regarding "
+"susceptibility \n"
+"to traffic analysis, trust and other topics do exist, but a more in-depth"
+" \n"
+"review of this \"globally scalable darknet\" will have to wait until the "
+"Freenet \n"
+"team makes more information available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:797
+msgid ""
+"I2P itself doesn't really do much - it simply sends messages to remote "
+"destinations \n"
+"and receives messages targeting local destinations - most of the "
+"interesting \n"
+"work goes on at the layers above it. By itself, I2P could be seen as an "
+"anonymous \n"
+"and secure IP layer, and the bundled streaming"
+" library \n"
+"as an implementation of an anonymous and secure TCP layer on top of it. "
+"Beyond \n"
+"that, I2PTunnel exposes a generic TCP "
+"proxying \n"
+"system for either getting into or out of the I2P network, plus a variety "
+"of \n"
+"network applications provide further functionality for end users."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:809
+msgid ""
+"The I2P streaming library can be viewed as a generic streaming interface "
+"(mirroring TCP sockets),\n"
+"and the implementation supports a sliding "
+"window protocol\n"
+"with several optimizations, to take into account the high delay over I2P."
+"\n"
+"Individual streams may adjust the maximum packet size and \n"
+"other options, though the default of 4KB compressed seems a reasonable "
+"tradeoff \n"
+"between the bandwidth costs of retransmitting lost messages and the "
+"latency \n"
+"of multiple messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:819
+msgid ""
+"In addition, in consideration of the relatively high cost of subsequent \n"
+"messages, the streaming library's protocol for scheduling and delivering "
+"messages \n"
+"has been optimized to allow individual messages passed to contain as much"
+" \n"
+"information as is available. For instance, a small HTTP transaction "
+"proxied \n"
+"through the streaming library can be completed in a single round trip - "
+"the \n"
+"first message bundles a SYN, FIN and the small payload (an HTTP request "
+"typically \n"
+"fits) and the reply bundles the SYN, FIN, ACK and the small payload (many"
+" \n"
+"HTTP responses fit). While an additional ACK must be transmitted to tell "
+"the \n"
+"HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy "
+"can \n"
+"deliver the full response to the browser immediately."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:832
+msgid ""
+"On the whole, however, the streaming library bears much resemblance to an"
+" \n"
+"abstraction of TCP, with its sliding windows, congestion control "
+"algorithms \n"
+"(both slow start and congestion avoidance), and general packet behavior "
+"(ACK, \n"
+"SYN, FIN, RST, etc)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:839
+msgid "Naming library and addressbook"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:840
+#, python-format
+msgid ""
+"For more information see the Naming and "
+"Addressbook page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:844
+#: i2p2www/pages/site/docs/how/tech-intro.html:918
+#: i2p2www/pages/site/docs/how/tech-intro.html:965
+#: i2p2www/pages/site/docs/how/tech-intro.html:997
+#: i2p2www/pages/site/docs/how/tech-intro.html:1005
+#: i2p2www/pages/site/docs/how/tech-intro.html:1013
+#: i2p2www/pages/site/docs/how/tech-intro.html:1023
+#: i2p2www/pages/site/docs/how/tech-intro.html:1031
+#: i2p2www/pages/site/docs/how/tech-intro.html:1053
+#, python-format
+msgid "Developed by: %(dev)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:846
+msgid ""
+"Naming within I2P has been an oft-debated topic since the very beginning"
+" \n"
+"with advocates across the spectrum of possibilities. However, given I2P's"
+" \n"
+"inherent demand for secure communication and decentralized operation, the"
+" \n"
+"traditional DNS-style naming system is clearly out, as are \"majority "
+"rules\" \n"
+"voting systems. Instead, I2P ships with a generic naming library and a "
+"base \n"
+"implementation designed to work off a local name to destination mapping, "
+"as \n"
+"well as an optional add-on application called the \"addressbook\". The "
+"addressbook \n"
+"is a web-of-trust-driven secure, distributed, and human readable naming "
+"system, \n"
+"sacrificing only the call for all human readable names to be globally "
+"unique \n"
+"by mandating only local uniqueness. While all messages in I2P are "
+"cryptographically \n"
+"addressed by their destination, different people can have local "
+"addressbook \n"
+"entries for \"Alice\" which refer to different destinations. People can "
+"still \n"
+"discover new names by importing published addressbooks of peers specified"
+" \n"
+"in their web of trust, by adding in the entries provided through a third "
+"party, \n"
+"or (if some people organize a series of published addressbooks using a "
+"first \n"
+"come first serve registration system) people can choose to treat these "
+"addressbooks \n"
+"as name servers, emulating traditional DNS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:866
+msgid ""
+"I2P does not promote the use of DNS-like services though, as the damage \n"
+"done by hijacking a site can be tremendous - and insecure destinations "
+"have \n"
+"no value. DNSsec itself still falls back on registrars and certificate "
+"authorities, \n"
+"while with I2P, requests sent to a destination cannot be intercepted or "
+"the \n"
+"reply spoofed, as they are encrypted to the destination's public keys, "
+"and \n"
+"a destination itself is just a pair of public keys and a certificate. "
+"DNS-style \n"
+"systems on the other hand allow any of the name servers on the lookup "
+"path \n"
+"to mount simple denial of service and spoofing attacks. Adding on a "
+"certificate \n"
+"authenticating the responses as signed by some centralized certificate "
+"authority \n"
+"would address many of the hostile nameserver issues but would leave open "
+"replay \n"
+"attacks as well as hostile certificate authority attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:880
+msgid ""
+"Voting style naming is dangerous as well, especially given the "
+"effectiveness \n"
+"of Sybil attacks in anonymous systems - the attacker can simply create an"
+" \n"
+"arbitrarily high number of peers and \"vote\" with each to take over a "
+"given \n"
+"name. Proof-of-work methods can be used to make identity non-free, but as"
+" \n"
+"the network grows the load required to contact everyone to conduct online"
+" \n"
+"voting is implausible, or if the full network is not queried, different "
+"sets \n"
+"of answers may be reachable."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:890
+msgid ""
+"As with the Internet however, I2P is keeping the design and operation of"
+" \n"
+"a naming system out of the (IP-like) communication layer. The bundled "
+"naming \n"
+"library includes a simple service provider interface which alternate "
+"naming \n"
+"systems can plug into, allowing end users to drive what sort of naming "
+"tradeoffs \n"
+"they prefer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:899
+msgid ""
+"The old Syndie bundled with I2P has been replaced by the new Syndie which"
+"\n"
+"is distributed separately. For more information see the Syndie\n"
+"pages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:905
+msgid ""
+"Syndie is a safe, anonymous blogging / content publication / content "
+"aggregation \n"
+"system. It lets you create information, share it with others, and read "
+"posts \n"
+"from those you're interested in, all while taking into consideration your"
+" \n"
+"needs for security and anonymity. Rather than building its own content "
+"distribution \n"
+"network, Syndie is designed to run on top of existing networks, "
+"syndicating \n"
+"content through eepsites, Tor hidden services, Freenet freesites, normal "
+"websites, \n"
+"usenet newsgroups, email lists, RSS feeds, etc. Data published with "
+"Syndie \n"
+"is done so as to offer pseudonymous authentication to anyone reading or "
+"archiving \n"
+"it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:920
+msgid ""
+"I2PTunnel is probably I2P's most popular and versatile client "
+"application, \n"
+"allowing generic proxying both into and out of the I2P network. I2PTunnel"
+" \n"
+"can be viewed as four separate proxying applications - a \"client\" which"
+" receives \n"
+"inbound TCP connections and forwards them to a given I2P destination, an "
+"\"httpclient\" \n"
+"(aka \"eepproxy\") which acts like an HTTP proxy and forwards the "
+"requests to \n"
+"the appropriate I2P destination (after querying the naming service if "
+"necessary), \n"
+"a \"server\" which receives inbound I2P streaming connections on a "
+"destination \n"
+"and forwards them to a given TCP host+port, and an \"httpserver\" which "
+"extends \n"
+"the \"server\" by parsing the HTTP request and responses to allow safer "
+"operation. \n"
+"There is an additional \"socksclient\" application, but its use is not "
+"encouraged \n"
+"for reasons previously mentioned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:934
+msgid ""
+"I2P itself is not an outproxy network - the anonymity and security "
+"concerns \n"
+"inherent in a mix net which forwards data into and out of the mix have "
+"kept \n"
+"I2P's design focused on providing an anonymous network which capable of "
+"meeting \n"
+"the user's needs without requiring external resources. However, the "
+"I2PTunnel \n"
+"\"httpclient\" application offers a hook for outproxying - if the "
+"hostname requested \n"
+"doesn't end in \".i2p\", it picks a random destination from a user-"
+"provided \n"
+"set of outproxies and forwards the request to them. These destinations "
+"are \n"
+"simply I2PTunnel \"server\" instances run by volunteers who have "
+"explicitly \n"
+"chosen to run outproxies - no one is an outproxy by default, and running "
+"an \n"
+"outproxy doesn't automatically tell other people to proxy through you. "
+"While \n"
+"outproxies do have inherent weaknesses, they offer a simple proof of "
+"concept \n"
+"for using I2P and provide some functionality under a threat model which "
+"may \n"
+"be sufficient for some users."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:950
+msgid ""
+"I2PTunnel enables most of the applications in use. An \"httpserver\" "
+"pointing \n"
+"at a webserver lets anyone run their own anonymous website (or "
+"\"eepsite\") \n"
+"- a webserver is bundled with I2P for this purpose, but any webserver can"
+" \n"
+"be used. Anyone may run a \"client\" pointing at one of the anonymously "
+"hosted \n"
+"IRC servers, each of which are running a \"server\" pointing at their "
+"local \n"
+"IRCd and communicating between IRCds over their own \"client\" tunnels. "
+"End \n"
+"users also have \"client\" tunnels pointing at I2Pmail's \n"
+"POP3 and SMTP destinations (which in turn are simply \"server\" instances"
+" pointing \n"
+"at POP3 and SMTP servers), as well as \"client\" tunnels pointing at "
+"I2P's CVS \n"
+"server, allowing anonymous development. At times people have even run "
+"\"client\" \n"
+"proxies to access the \"server\" instances pointing at an NNTP server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:967
+msgid ""
+"i2p-bt is a port of the mainline python BitTorrent client to run both the"
+" \n"
+"tracker and peer communication over I2P. Tracker requests are forwarded "
+"through \n"
+"the eepproxy to eepsites specified in the torrent file while tracker "
+"responses \n"
+"refer to peers by their destination explicitly, allowing i2p-bt to open "
+"up \n"
+"a streaming lib connection to query them "
+"for \n"
+"blocks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:976
+msgid ""
+"In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making"
+" \n"
+"a few modifications as necessary to strip any anonymity-compromising "
+"information \n"
+"from the application and to take into consideration the fact that IPs "
+"cannot \n"
+"be used for identifying peers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:984
+msgid ""
+"I2PSnark developed: jrandom, et al, ported from mjw's Snark client"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:990
+msgid ""
+"Bundled with the I2P install, I2PSnark offers a simple anonymous "
+"BitTorrent \n"
+"client with multitorrent capabilities, exposing all of the functionality "
+"through \n"
+"a plain HTML web interface."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:999
+#, python-format
+msgid ""
+"Robert is a Bittorrent client written in Python.\n"
+"It is hosted on http://%(bob)s/Robert.html "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1007
+#, python-format
+msgid ""
+"PyBit is a Bittorrent client written in Python.\n"
+"It is hosted on http://%(pebcache)s/"
+" "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1015
+msgid ""
+"I2Phex is a fairly direct port of the Phex Gnutella filesharing client to"
+" \n"
+"run entirely on top of I2P. While it has disabled some of Phex's "
+"functionality, \n"
+"such as integration with Gnutella webcaches, the basic file sharing and "
+"chatting \n"
+"system is fully functional."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1025
+msgid ""
+"iMule is a fairly direct port of the aMule filesharing client \n"
+"running entirely inside I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1033
+#, python-format
+msgid ""
+"I2Pmail is more a service than an application - postman offers both "
+"internal \n"
+"and external email with POP3 and SMTP service through I2PTunnel instances"
+" \n"
+"accessing a series of components developed with mastiejaner, allowing "
+"people \n"
+"to use their preferred mail clients to send and receive mail "
+"pseudonymously. \n"
+"However, as most mail clients expose substantial identifying information,"
+" \n"
+"I2P bundles susi23's web based susimail client which has been built "
+"specifically \n"
+"with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers "
+"transparent \n"
+"virus filtering as well as denial of service prevention with hashcash "
+"augmented \n"
+"quotas. In addition, each user has control of their batching strategy "
+"prior \n"
+"to delivery through the mail.i2p outproxies, which are separate from the "
+"mail.i2p \n"
+"SMTP and POP3 servers - both the outproxies and inproxies communicate "
+"with \n"
+"the mail.i2p SMTP and POP3 servers through I2P itself, so compromising "
+"those \n"
+"non-anonymous locations does not give access to the mail accounts or "
+"activity \n"
+"patterns of the user. At the moment the developers work on a "
+"decentralized \n"
+"mailsystem, called \"v2mail\". More information can be found on the "
+"eepsite \n"
+"%(postman)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1055
+msgid ""
+"I2P-Bote is a distributed e-mail application. It does not use the "
+"traditional\n"
+"e-mail concept of sending an e-mail to a server and retrieving it from a "
+"server.\n"
+"Instead, it uses a Kademlia Distributed Hash Table to store mails.\n"
+"One user can push a mail into the DHT, while another can request the "
+"e-mail from the DHT.\n"
+"And all the mails sent within the I2P-Bote network are automatically "
+"encrypted end-to-end. 
            \n"
+"Furthermore, I2P-Bote offers a remailer function on top of I2P, for "
+"increased high-latency anonymity."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1065
+msgid ""
+"I2P-Messenger is an end-to-end encrypted serverless communication "
+"application.\n"
+"For communication between two users, they need to give each other their "
+"destination keys, to allow the other to connect.\n"
+"It supports file transfer and has a search for other users, based on "
+"Seedless."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:2
+msgid "I2P's Threat Model"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:3
+msgid "November 2010"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:6
+msgid "What do we mean by \"anonymous\"?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:8
+msgid ""
+"Your level of anonymity can be described as \"how hard it is for someone\n"
+"to find out information you don't want them to know?\" - who you are, "
+"where\n"
+"you are located, who you communicate with, or even when you communicate."
+"  \n"
+"\"Perfect\" anonymity is not a useful concept here - software will not "
+"make \n"
+"you indistinguishable from people that don't use computers or who are not"
+" on\n"
+"the Internet.  Instead, we are working to provide sufficient anonymity to"
+" meet the\n"
+"real needs of whomever we can - from those simply browsing websites, to "
+"those exchanging\n"
+"data, to those fearful of discovery by powerful organizations or states."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:19
+msgid ""
+"The question of whether I2P provides sufficient anonymity for your \n"
+"particular needs is a hard one, but this page will hopefully assist in \n"
+"answering that question by exploring how I2P operates under various "
+"attacks\n"
+"so that you may decide whether it meets your needs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:26
+msgid ""
+"We welcome further research and analysis on I2P's resistance to the "
+"threats described below.\n"
+"More review of existing literature (much of it focused on Tor) and "
+"original\n"
+"work focused on I2P is needed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:32
+msgid "Network Topology Summary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:33
+#, python-format
+msgid ""
+"I2P builds off the ideas of many other \n"
+"systems, but a few key points should be kept in"
+" mind when \n"
+"reviewing related literature:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:39
+msgid ""
+"I2P is a free route mixnet - the message creator explicitly "
+"defines the\n"
+"path that messages will be sent out (the outbound tunnel), and the "
+"message \n"
+"recipient explicitly defines the path that messages will be received on "
+"(the\n"
+"inbound tunnel)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:45
+msgid ""
+"I2P has no official entry and exit points - all peers fully "
+"participate in the \n"
+"mix, and there are no network layer in- or out-proxies (however, at the \n"
+"application layer, a few proxies do exist)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:50
+msgid ""
+"I2P is fully distributed - there are no central controls or "
+"authorities.\n"
+"One could modify some routers to operate mix cascades (building tunnels "
+"and giving\n"
+"out the keys necessary to control the forwarding at the tunnel endpoint) "
+"or directory \n"
+"based profiling and selection, all without breaking compatibility with "
+"the rest of \n"
+"the network, but doing so is of course not necessary (and may even harm "
+"one's\n"
+"anonymity)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:60
+#, python-format
+msgid ""
+"We have documented plans to implement nontrivial delays\n"
+"and batching strategies \n"
+"whose existence is only known to the particular hop or tunnel gateway "
+"that \n"
+"receives the message, allowing a mostly low latency mixnet to provide "
+"cover \n"
+"traffic for higher latency communication (e.g. email).\n"
+"However we are aware that significant delays are required to provide "
+"meaningful\n"
+"protection, and that implementation of such delays will be a significant "
+"challenge.\n"
+"It is not clear at this time whether we will actually implement these "
+"delay features."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:71
+msgid ""
+"In theory, routers along the message path may inject an \n"
+"arbitrary number of hops before forwarding the message to the next peer, "
+"though\n"
+"the current implementation does not."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:78
+msgid "The Threat Model (Attacks)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:79
+msgid ""
+"I2P design started in 2003, not long after the advent of\n"
+"[Onion Routing],\n"
+"[Freenet], and\n"
+"[Tor].\n"
+"Our design benefits substantially from the research published around that"
+" time.\n"
+"I2P uses several onion routing techniques, so we continue to benefit\n"
+"from the significant academic interest in Tor."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:89
+msgid ""
+"Taking from the attacks and analysis put forth in the \n"
+"anonymity "
+"literature (largely \n"
+"Traffic Analysis: "
+"Protocols, Attacks, Design \n"
+"Issues and Open Problems), the following briefly describes a wide "
+"variety \n"
+"of attacks as well as many of I2Ps defenses.  We update\n"
+"this list to include new attacks as they are identified."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:98
+msgid ""
+"Included are some attacks that may be unique to I2P.\n"
+"We do not have good answers for all these attacks, however\n"
+"we continue to do research and improve our defenses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:104
+msgid ""
+"In addition, many of these attacks are significantly easier than\n"
+"they should be, due to the modest size of the current network.\n"
+"While we are aware of some limitations that need to be addressed,\n"
+"I2P is designed to support hundreds of thousands, or millions, of\n"
+"participants.\n"
+"As we continue to spread the word and grow the network,\n"
+"these attacks will become much harder."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:114
+#, python-format
+msgid ""
+"The\n"
+"network comparisons and\n"
+"\"garlic\" terminology pages may also "
+"be helpful\n"
+"to review."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:123
+#: i2p2www/pages/site/docs/how/threat-model.html:143
+msgid "Brute force attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:124
+#: i2p2www/pages/site/docs/how/threat-model.html:185
+msgid "Timing attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:125
+#: i2p2www/pages/site/docs/how/threat-model.html:220
+msgid "Intersection attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:126
+#: i2p2www/pages/site/docs/how/threat-model.html:298
+msgid "Denial of service attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:127
+#: i2p2www/pages/site/docs/how/threat-model.html:385
+msgid "Tagging attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:128
+#: i2p2www/pages/site/docs/how/threat-model.html:400
+msgid "Partitioning attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:129
+#: i2p2www/pages/site/docs/how/threat-model.html:438
+msgid "Predecessor attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:130
+#: i2p2www/pages/site/docs/how/threat-model.html:481
+msgid "Harvesting attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:131
+#: i2p2www/pages/site/docs/how/threat-model.html:525
+msgid "Identification Through Traffic Analysis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:132
+#: i2p2www/pages/site/docs/how/threat-model.html:582
+msgid "Sybil attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:133
+#: i2p2www/pages/site/docs/how/threat-model.html:629
+msgid "Buddy Exhaustion attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:134
+#: i2p2www/pages/site/docs/how/threat-model.html:651
+msgid "Cryptographic attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:135
+msgid "Floodfill attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:136
+#: i2p2www/pages/site/docs/how/threat-model.html:707
+msgid "Other Network Database attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:137
+msgid "Attacks on centralized resources"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:138
+#: i2p2www/pages/site/docs/how/threat-model.html:770
+msgid "Development attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:139
+msgid "Implementation attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:140
+#: i2p2www/pages/site/docs/how/threat-model.html:849
+msgid "Other Defenses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:145
+msgid ""
+"A brute force attack can be mounted by a global passive or active "
+"adversary, \n"
+"watching all the messages pass between all of the nodes and attempting to"
+" correlate\n"
+"which message follows which path.  Mounting this attack against I2P "
+"should be \n"
+"nontrivial, as all peers in the network are frequently sending messages "
+"(both\n"
+"end to end and network maintenance messages), plus an end to end message "
+"changes\n"
+"size and data along its path.  In addition, the external adversary does "
+"not have\n"
+"access to the messages either, as inter-router communication is both "
+"encrypted\n"
+"and streamed (making two 1024 byte messages indistinguishable from one "
+"2048 byte\n"
+"message)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:157
+msgid ""
+"However, a powerful attacker can use brute force to detect trends - if "
+"they \n"
+"can send 5GB to an I2P destination and monitor everyone's network "
+"connection,\n"
+"they can eliminate all peers who did not receive 5GB of data.  Techniques"
+" to \n"
+"defeat this attack exist, but may be prohibitively expensive (see: \n"
+"Tarzan's "
+"mimics\n"
+"or constant rate traffic).  Most users are not concerned with this "
+"attack, as \n"
+"the cost of mounting it are extreme (and often require illegal activity)."
+"  \n"
+"However, the attack is still possible, for example by an observer at\n"
+"a large ISP or an Internet exchange point.\n"
+"Those who want to defend against it \n"
+"would want to take appropriate countermeasures, such as\n"
+"setting low bandwidth limits, and using unpublished or encrypted "
+"leasesets for eepsites.\n"
+"Other countermeasures, such as nontrivial delays and restricted routes, "
+"are\n"
+"not currently implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:174
+#, python-format
+msgid ""
+"As a partial defense against a single router or group of routers trying "
+"to route all the network's traffic,\n"
+"routers contain limits as to how many tunnels can be routed through a "
+"single peer.\n"
+"As the network grows, these limits are subject to further adjustment.\n"
+"Other mechanisms for peer rating, selection and avoidance\n"
+"are discussed on the\n"
+"peer selection page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:187
+msgid ""
+"I2P's messages are unidirectional and do not necessarily imply that a "
+"reply\n"
+"will be sent.  However, applications on top of I2P will most likely have\n"
+"recognizable patterns within the frequency of their messages - for "
+"instance, an \n"
+"HTTP request will be a small message with a large sequence of reply "
+"messages \n"
+"containing the HTTP response.  Using this data as well as a broad view of"
+" the \n"
+"network topology, an attacker may be able to disqualify some links as "
+"being too \n"
+"slow to have passed the message along."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:197
+msgid ""
+"This sort of attack is powerful, but its applicability to I2P is non "
+"obvious,\n"
+"as the variation on message delays due to queuing, message processing, "
+"and \n"
+"throttling will often meet or exceed the time of passing a message along "
+"a \n"
+"single link - even when the attacker knows that a reply will be sent as "
+"soon as\n"
+"the message is received.  There are some scenarios which will expose "
+"fairly \n"
+"automatic replies though - the streaming library does (with the SYN+ACK) "
+"as does the \n"
+"message mode of guaranteed delivery (with the "
+"DataMessage+DeliveryStatusMessage)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:207
+#, python-format
+msgid ""
+"Without protocol scrubbing or higher latency, global active adversaries "
+"can \n"
+"gain substantial information.  As such, people concerned with these "
+"attacks could\n"
+"increase the latency (using nontrivial "
+"delays or \n"
+"batching strategies), include protocol "
+"scrubbing, or\n"
+"other advanced tunnel routing techniques,\n"
+"but these are unimplemented in I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:216
+#, python-format
+msgid ""
+"References: Low-Resource Routing Attacks Against "
+"Anonymous Systems"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:222
+msgid ""
+"Intersection attacks against low latency systems are extremely powerful -"
+"\n"
+"periodically make contact with the target and keep track of what peers "
+"are on\n"
+"the network.  Over time, as node churn occurs the attacker will gain \n"
+"significant information about the target by simply intersecting the sets "
+"of\n"
+"peers that are online when a message successfully goes through.  The cost"
+" of \n"
+"this attack is significant as the network grows, but may be feasible in "
+"some\n"
+"scenarios."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:232
+#, python-format
+msgid ""
+"In summary, if an attacker is at both ends of your tunnel at the same "
+"time,\n"
+"he may be successful.\n"
+"I2P does not have a full defense to this for low latency communication.\n"
+"This is an inherent weakness of low-latency onion routing.\n"
+"Tor provides a similar disclaimer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:240
+msgid "Partial defenses implemented in I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:244
+#, python-format
+msgid "strict ordering of peers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:247
+#, python-format
+msgid ""
+"peer profiling and selection from a "
+"small group that changes slowly"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:250
+msgid "Limits on the number of tunnels routed through a single peer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:253
+msgid ""
+"Prevention of peers from the same /16 IP range from being members of a "
+"single tunnel"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:256
+msgid ""
+"For eepsites or other hosted services, we support\n"
+"simultaneous hosting on multiple routers, or\n"
+"multihoming"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:263
+msgid ""
+"Even in total, these defenses are not a complete solution.\n"
+"Also, we have made some design choices that may significantly increase "
+"our vulnerability:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:268
+msgid "We do not use low-bandwidth \"guard nodes\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:271
+msgid ""
+"We use tunnel pools comprised of several tunnels, and traffic can shift "
+"from tunnel to tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:274
+msgid "Tunnels are not long-lived; new tunnels are built every 10 minutes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:277
+msgid ""
+"Tunnel lengths are configurable.\n"
+"While 3-hop tunnels are recommended for full protection, several "
+"applications and\n"
+"services use 2-hop tunnels by default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:284
+#, python-format
+msgid ""
+"In the future, it could\n"
+"for peers who can afford significant delays (per nontrivial\n"
+"delays and batching strategies).  "
+"In addition,\n"
+"this is only relevant for destinations that other people know about - a "
+"private\n"
+"group whose destination is only known to trusted peers does not have to "
+"worry,\n"
+"as an adversary can't \"ping\" them to mount the attack.
            "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:293
+#, python-format
+msgid "Reference: One Cell Enough"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:300
+msgid ""
+"There are a whole slew of denial of service attacks available against "
+"I2P,\n"
+"each with different costs and consequences:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:305
+msgid ""
+"Greedy user attack: This is simply\n"
+"people trying to consume significantly more resources than they are \n"
+"willing to contribute. The defense against this is:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:311
+#, python-format
+msgid ""
+"Set defaults so that most users provide resources to the network.\n"
+"In I2P, users route traffic by default. In sharp distinction to\n"
+"other networks,\n"
+"over 95%% of I2P users relay traffic for others."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:317
+msgid ""
+"Provide easy configuration options so that users may increase their\n"
+"contribution (share percentage) to the network. Display easy-to-"
+"understand\n"
+"metrics such as \"share ratio\" so that users may see what they are "
+"contributing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:322
+msgid ""
+"Maintain a strong community with blogs, forums, IRC, and other means of "
+"communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:327
+#, python-format
+msgid ""
+"Starvation attack: A hostile user may attempt to harm the network "
+"by\n"
+"creating a significant number of peers in the network who are not "
+"identified as\n"
+"being under control of the same entity (as with Sybil). These nodes then"
+" \n"
+"decide not to provide any resources to the network, causing existing "
+"peers \n"
+"to search through a larger network database or request more tunnels than"
+" \n"
+"should be necessary. \n"
+"Alternatively, the nodes may provide intermittent service by periodically"
+"\n"
+"dropping selected traffic, or refusing connections to certain peers.\n"
+"This behavior may be indistinguishable from that of a heavily-loaded or "
+"failing node.\n"
+"I2P addresses these issues by maintaining profiles on the \n"
+"peers, attempting to identify underperforming ones and simply ignoring \n"
+"them, or using them rarely.\n"
+"We have significantly enhanced the\n"
+"ability to recognize and avoid troublesome peers; however there are still"
+"\n"
+"significant efforts required in this area."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:344
+#, python-format
+msgid ""
+"Flooding attack: A hostile user may attempt to flood the network,\n"
+"a peer, a destination, or a tunnel.  Network and peer flooding is "
+"possible,\n"
+"and I2P does nothing to prevent standard IP layer flooding.  The flooding"
+" of\n"
+"a destination with messages by sending a large number to the target's "
+"various\n"
+"inbound tunnel gateways is possible, but the destination will know this "
+"both\n"
+"by the contents of the message and because the tunnel's tests will fail."
+"  The\n"
+"same goes for flooding just a single tunnel.  I2P has no defenses for a "
+"network\n"
+"flooding attack.  For a destination and tunnel flooding attack, the "
+"target\n"
+"identifies which tunnels are unresponsive and builds new ones.  New code "
+"could\n"
+"also be written to add even more tunnels if the client wishes to handle "
+"the\n"
+"larger load.  If, on the other hand, the load is more than the client can"
+"\n"
+"deal with, they can instruct the tunnels to throttle the number of "
+"messages or\n"
+"bytes they should pass on (once the advanced tunnel\n"
+"operation is implemented)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:360
+msgid ""
+"CPU load attack: There are currently some methods for people to \n"
+"remotely request that a peer perform some cryptographically expensive \n"
+"operation, and a hostile attacker could use these to flood that peer with"
+"\n"
+"a large number of them in an attempt to overload the CPU.  Both using "
+"good \n"
+"engineering practices and potentially requiring nontrivial certificates \n"
+"(e.g. HashCash) to be attached to these expensive requests should "
+"mitigate\n"
+"the issue, though there may be room for an attacker to exploit various\n"
+"bugs in the implementation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:370
+#, python-format
+msgid ""
+"Floodfill DOS attack: A hostile user may attempt to harm the "
+"network by\n"
+"becoming a floodfill router. The current defenses against unreliable,\n"
+"intermittent, or malicious floodfill routers are poor.\n"
+"A floodfill router may provide bad or no response to lookups, and\n"
+"it may also interfere with inter-floodfill communication.\n"
+"Some defenses and\n"
+"peer profiling are implemented,\n"
+"however there is much more to do.\n"
+"For more information see the\n"
+"network database page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:386
+#, python-format
+msgid ""
+"Tagging attacks - modifying a message so that it can later be identified"
+" \n"
+"further along the path - are by themselves impossible in I2P, as messages"
+" \n"
+"passed through tunnels are signed.  However, if an attacker is the "
+"inbound \n"
+"tunnel gateway as well as a participant further along in that tunnel, "
+"with\n"
+"collusion they can identify the fact that they are in the same tunnel "
+"(and \n"
+"prior to adding unique hop ids and "
+"other updates,\n"
+"colluding peers within the same tunnel can recognize that fact without "
+"any \n"
+"effort).  An attacker in an outbound tunnel and any part of an inbound "
+"tunnel cannot \n"
+"collude however, as the tunnel encryption pads and modifies the data "
+"separately\n"
+"for the inbound and outbound tunnels.  External attackers cannot do "
+"anything,\n"
+"as the links are encrypted and messages signed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:402
+msgid ""
+"Partitioning attacks - finding ways to segregate (technically or "
+"analytically)\n"
+"the peers in a network - are important to keep in mind when dealing with "
+"a \n"
+"powerful adversary, since the size of the network plays a key role in "
+"determining\n"
+"your anonymity.  Technical partitioning by cutting links between peers to"
+" create\n"
+"fragmented networks is addressed by I2P's built in network database, "
+"which \n"
+"maintains statistics about various peers so as to allow any existing "
+"connections\n"
+"to other fragmented sections to be exploited so as to heal the network.  "
+"However,\n"
+"if the attacker does disconnect all links to uncontrolled peers, "
+"essentially\n"
+"isolating the target, no amount of network database healing will fix it."
+"  At\n"
+"that point, the only thing the router can hope to do is notice that a "
+"significant\n"
+"number of previously reliable peers have become unavailable and alert the"
+" client\n"
+"that it is temporarily disconnected (this detection code is not "
+"implemented at\n"
+"the moment)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:418
+#, python-format
+msgid ""
+"Partitioning the network analytically by looking for differences in how "
+"routers \n"
+"and destinations behave and grouping them accordingly is also a very "
+"powerful\n"
+"attack.  For instance, an attacker harvesting"
+" the network\n"
+"database will know when a particular destination has 5 inbound tunnels in"
+" their\n"
+"LeaseSet while others have only 2 or 3, allowing the adversary to "
+"potentially \n"
+"partition clients by the number of tunnels selected.  Another partition "
+"is \n"
+"possible when dealing with the nontrivial "
+"delays and \n"
+"batching strategies, as the tunnel "
+"gateways and the\n"
+"particular hops with non-zero delays will likely stand out.  However, "
+"this data\n"
+"is only exposed to those specific hops, so to partition effectively on "
+"that \n"
+"matter, the attacker would need to control a significant portion of the "
+"network\n"
+"(and still that would only be a probabilistic partition, as they wouldn't"
+" know\n"
+"which other tunnels or messages have those delays)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:434
+#, python-format
+msgid ""
+"Also discussed on the network database "
+"page (bootstrap attack)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:440
+msgid ""
+"The predecessor attack is passively gathering statistics in an attempt to"
+" see\n"
+"what peers are 'close' to the destination by participating in their "
+"tunnels and\n"
+"keeping track of the previous or next hop (for outbound or inbound "
+"tunnels, \n"
+"respectively).  Over time, using a perfectly random sample of peers and "
+"random\n"
+"ordering, an attacker would be able to see which peer shows up as "
+"'closer' \n"
+"statistically more than the rest, and that peer would in turn be where "
+"the\n"
+"target is located."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:450
+#, python-format
+msgid ""
+"I2P avoids this in four ways: first, the peers selected to participate in"
+"\n"
+"tunnels are not randomly sampled throughout the network - they are "
+"derived from\n"
+"the peer selection algorithm which "
+"breaks them\n"
+"into tiers.  Second, with strict "
+"ordering of peers\n"
+"in a tunnel, the fact that a peer shows up more frequently does not mean "
+"they're\n"
+"the source.  Third, with permuted "
+"tunnel length\n"
+"(not enabled by default)\n"
+"even 0 hop tunnels can provide plausible deniability as the occasional \n"
+"variation of the gateway will look like normal tunnels.  Fourth, with \n"
+"restricted routes "
+"(unimplemented), only the peer with\n"
+"a restricted connection to the target will ever contact the target, while"
+" \n"
+"attackers will merely run into that gateway."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:467
+#, python-format
+msgid ""
+"The current tunnel build method\n"
+"was specifically designed to combat the predecessor attack.\n"
+"See also the intersection attack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:473
+#, python-format
+msgid ""
+"References: %(pdf2008)s\n"
+"which is an update to the 2004 predecessor attack paper\n"
+"%(pdf2004)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:482
+msgid ""
+"\"Harvesting\" means compiling a list of users running I2P.\n"
+"It can be used for legal attacks and to help\n"
+"other attacks by simply running a peer, seeing who it connects to, and \n"
+"harvesting whatever references to other peers it can find."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:489
+msgid ""
+"I2P itself is not designed with effective defenses against\n"
+"this attack, since there is the distributed network database \n"
+"containing just this information.\n"
+"The following factors make the attack somewhat harder in practice:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:496
+msgid ""
+"Network growth will make it more difficult to obtain a given proportion "
+"of the network"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:499
+msgid "Floodfill routers implement query limits as DOS protection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:502
+msgid ""
+"\"Hidden mode\", which prevents a router from publishing its information "
+"to the netDb,\n"
+"(but also prevents it from relaying data) is not widely used now but "
+"could be."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:508
+#, python-format
+msgid ""
+"In future implementations,\n"
+"basic and \n"
+"comprehensive restricted "
+"routes,\n"
+"this attack loses much of its power, as the \"hidden\" peers do not "
+"publish their\n"
+"contact addresses in the network database - only the tunnels through "
+"which \n"
+"they can be reached (as well as their public keys, etc)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:517
+msgid ""
+"In the future, routers could use GeoIP to identify if they are in a "
+"particular\n"
+"country where identification as an I2P node would be risky.\n"
+"In that case, the router could automatically enable hidden mode, or\n"
+"enact other restricted route methods."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:526
+#, python-format
+msgid ""
+"By inspecting the traffic into and out of a router, a malicious ISP\n"
+"or state-level firewall could identify that a computer is running I2P.\n"
+"As discussed above, I2P is not specifically "
+"designed\n"
+"to hide that a computer is running I2P. However, several design decisions"
+" made\n"
+"in the design of the\n"
+"transport layer and protocols\n"
+"make it somewhat difficult to identify I2P traffic:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:536
+msgid "Random port selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:539
+msgid "Point-to-Point Encryption of all traffic"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:542
+msgid ""
+"DH key exchange with no protocol bytes or other unencrypted constant "
+"fields"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:545
+#, python-format
+msgid ""
+"Simultaneous use of both\n"
+"TCP and\n"
+"UDP transports.\n"
+"UDP may be much harder for some Deep Packet Inspection (DPI) equipment to"
+" track."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:553
+msgid ""
+"In the near future, we plan to directly address traffic analysis issues "
+"by further obfuscation of I2P transport protocols, possibly including:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:557
+msgid ""
+"Padding at the transport layer to random lengths, especially during the "
+"connection handshake"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:560
+msgid ""
+"Study of packet size distribution signatures, and additional padding as "
+"necessary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:563
+msgid ""
+"Development of additional transport methods that mimic SSL or other "
+"common protocols"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:566
+msgid ""
+"Review of padding strategies at higher layers to see how they affect "
+"packet sizes at the transport layer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:569
+msgid ""
+"Review of methods implemented by various state-level firewalls to block "
+"Tor"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:572
+msgid "Working directly with DPI and obfuscation experts"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:577
+#, python-format
+msgid ""
+"Reference: Breaking and Improving Protocol "
+"Obfuscation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:584
+#, python-format
+msgid ""
+"Sybil describes a category of attacks where the adversary creates "
+"arbitrarily\n"
+"large numbers of colluding nodes and uses the increased numbers to help \n"
+"mounting other attacks.  For instance, if an attacker is in a network "
+"where peers\n"
+"are selected randomly and they want an 80% chance to be one of those "
+"peers, they\n"
+"simply create five times the number of nodes that are in the network and "
+"roll \n"
+"the dice.  When identity is free, Sybil can be a very potent technique "
+"for a \n"
+"powerful adversary.  The primary technique to address this is simply to "
+"make \n"
+"identity 'non free' - Tarzan\n"
+"(among others) uses the fact that IP addresses are limited, while \n"
+"IIP used \n"
+"HashCash to 'charge' for "
+"creating a new\n"
+"identity.  We currently have not implemented any particular technique to "
+"address\n"
+"Sybil, but do include placeholder certificates in the router's and \n"
+"destination's data structures which can contain a HashCash certificate of"
+" \n"
+"appropriate value when necessary (or some other certificate proving "
+"scarcity)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:602
+msgid "Requiring HashCash Certificates in various places has two major problems:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:606
+msgid "Maintaining backward compatibility"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:609
+msgid ""
+"The classic HashCash problem -\n"
+"selecting HashCash values that are meaningful proofs of work on high-end "
+"machines,\n"
+"while still being feasible on low-end machines such as mobile devices."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:616
+msgid ""
+"Various limitations on the number of routers in a given IP range restrict"
+"\n"
+"the vulnerability to attackers that don't have the ability to put "
+"machines\n"
+"in several IP blocks.\n"
+"However, this is not a meaningful defense against a powerful adversary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:623
+#, python-format
+msgid ""
+"See the network database page\n"
+"for more Sybil discussion."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:630
+#, python-format
+msgid ""
+"(Reference: In Search of an Anonymouns and Secure "
+"Lookup Section 5.2)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:634
+#, python-format
+msgid ""
+"By refusing to accept or forward tunnel build requests, except to a "
+"colluding peer, a router could ensure\n"
+"that a tunnel is formed wholly from its set of colluding routers.\n"
+"The chances of success are enhanced if there is a large number of "
+"colluding routers,\n"
+"i.e. a Sybil attack.\n"
+"This is somewhat mitigated by our\n"
+"peer profiling methods used to monitor "
+"the performance\n"
+"of peers.\n"
+"However, this is a powerful attack as the number of routers approaches\n"
+"f = 0.2, or 20%% malicious nodes, as specifed in the paper.\n"
+"The malicous routers could also maintain connections to the target router"
+" and provide\n"
+"excellent forwarding bandwidth for traffic over those connections, in an "
+"attempt\n"
+"to manipulate the profiles managed by the target and appear attractive.\n"
+"Further research and defenses may be necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:653
+#, python-format
+msgid ""
+"We use strong cryptography with long keys, and\n"
+"we assume the security of the industry-standard cryptographic primitives "
+"used in I2P, as documented\n"
+"on the low-level cryptography page. \n"
+"Security features include the immediate detection of \n"
+"altered messages along the path, the inability to decrypt messages not "
+"addressed to you,\n"
+"and defense against man-in-the-middle attacks.\n"
+"The key sizes chosen in 2003 were quite conservative at the time, and are"
+" still longer than\n"
+"those used in other anonymity "
+"networks.\n"
+"We don't think the current key lengths are our biggest weakness,\n"
+"especially for traditional, non-state-level adversaries;\n"
+"bugs and the small size of the network are much more worrisome.\n"
+"Of course, all cryptographic algorithms eventually become obsolete due to"
+"\n"
+"the advent of faster processors, cryptographic research, and advancements"
+" in\n"
+"methods such as rainbow tables, clusters of video game hardware, etc.\n"
+"Unfortunately, I2P was not designed with easy mechanisms to lengthen keys"
+" or change\n"
+"shared secret values while maintaining backward compatibility."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:672
+#, python-format
+msgid ""
+"Upgrading the various data structures and protocols to support longer "
+"keys\n"
+"will have to be tackled eventually, and this will be a\n"
+"major undertaking, just as it will be "
+"for \n"
+"others.\n"
+"Hopefully, through careful planning, we can minimize the disruption, and\n"
+"implement mechanisms to make it easier for future transitions."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:681
+msgid ""
+"In the future, several I2P protocols and data structures\n"
+"support securely padding messages to arbitrary sizes, so messages could "
+"be made constant\n"
+"size or garlic messages could be modified randomly so that some cloves "
+"appear to contain\n"
+"more subcloves than they actually do.  At the moment, however, garlic, "
+"tunnel, and \n"
+"end to end messages include simple random padding."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:691
+msgid "Floodfill Anonymity attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:692
+#, python-format
+msgid ""
+"In addition to the floodfill DOS attacks described\n"
+"above, floodfill routers are uniquely positioned\n"
+"to learn about network participants, due to their role\n"
+"in the netDb, and the high frequency of communication with those "
+"participants.\n"
+"This is somewhat mitigated because floodfill routers only manage a "
+"portion\n"
+"of the total keyspace, and the keyspace rotates daily, as explained \n"
+"on the network database page.\n"
+"The specific mechanisms by which routers communicate with floodfills have"
+" been\n"
+"carefully designed.\n"
+"However, these threats should be studied further.\n"
+"The specific potential threats and corresponding defenses are a topic for"
+" future research."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:708
+#, python-format
+msgid ""
+"A hostile user may attempt to harm the network by\n"
+"creating one or more floodfill routers and crafting them to offer\n"
+"bad, slow, or no responses.\n"
+"Several scenarios are discussed on the\n"
+"network database page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:718
+msgid "Central Resource Attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:719
+msgid ""
+"There are a few centralized or limited resources (some inside I2P, some "
+"not)\n"
+"that could be attacked or used as a vector for attacks.\n"
+"The absence of jrandom starting November 2007, followed by the loss of "
+"the i2p.net hosting service in January 2008,\n"
+"highlighted numerous centralized resources in the development and "
+"operation of the I2P network,\n"
+"most of which are now distributed.\n"
+"Attacks on externally-reachable resources mainly affect the ability of "
+"new users to find us,\n"
+"not the operation of the network itself."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:729
+#, python-format
+msgid ""
+"The website is mirrored and uses DNS round-robin"
+" for external public access."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:732
+#, python-format
+msgid ""
+"Routers now support multiple external reseed "
+"locations,\n"
+"however more reseed hosts may be needed, and the handling of unreliable "
+"or malicious\n"
+"reseed hosts may need improvement."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:737
+msgid ""
+"Routers now support multiple update file locations.\n"
+"A malicious update host could feed a huge file, need to limit the size."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:741
+msgid "Routers now support multiple default trusted update signers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:744
+msgid ""
+"Routers now better handle multiple unreliable "
+"floodfill peers.\n"
+"Malicious floodfills needs more study."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:748
+#, fuzzy, python-format
+msgid ""
+"The code is now stored in a distributed source "
+"control system."
+msgstr "El código actual está disponible en monotone."
+
+#: i2p2www/pages/site/docs/how/threat-model.html:751
+msgid ""
+"Routers rely on a single news host, but there is a hardcoded backup URL "
+"pointing to a different host.\n"
+"A malicious news host could feed a huge file, need to limit the size."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:755
+#, python-format
+msgid ""
+"Naming system services, including addressbook "
+"subscription providers, add-host services,\n"
+"and jump services, could be malicious. Substantial protections for "
+"subscriptions were implemented\n"
+"in release 0.6.1.31, with additional enhancements in subsequent releases."
+"\n"
+"However, all naming services require some measure of trust, see\n"
+"the naming page for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:762
+msgid ""
+"We remain reliant on the DNS service for i2p2.de, losing this would cause"
+" substantial\n"
+"disruption in our ability to attract new users,\n"
+"and would shrink the network (in the short-to-medium term), just as the "
+"loss of i2p.net did."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:772
+msgid ""
+"These attacks aren't directly on the network, but instead go after its "
+"development team \n"
+"by either introducing legal hurdles on anyone contributing to the "
+"development\n"
+"of the software, or by using whatever means are available to get the "
+"developers to \n"
+"subvert the software.  Traditional technical measures cannot defeat these"
+" attacks, and\n"
+"if someone threatened the life or livelihood of a developer (or even just"
+" issuing a \n"
+"court order along with a gag order, under threat of prison), we would "
+"have a big problem."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:781
+msgid "However, two techniques help defend against these attacks:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:785
+#, python-format
+msgid ""
+"All components of the network must be open source to enable inspection, "
+"verification, \n"
+"modification, and improvement.  If a developer is compromised, once it is"
+" noticed \n"
+"the community should demand explanation and cease to accept that "
+"developer's work.\n"
+"All checkins to our distributed source control "
+"system\n"
+"are cryptographically signed, and the release packagers use a trust-list "
+"system\n"
+"to restrict modifications to those previously approved."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:793
+#, python-format
+msgid ""
+"Development over the network itself, allowing developers to stay "
+"anonymous but still \n"
+"secure the development process.  All I2P development can occur through "
+"I2P - using\n"
+"a distributed source control system,\n"
+"a distributed source control system, IRC chat,\n"
+"public web servers,\n"
+"discussion forums (forum.i2p), and the software distribution sites,\n"
+"all available within I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:804
+msgid ""
+"We also maintain relationships with various organizations that offer "
+"legal advice,\n"
+"should any defense be necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:809
+msgid "Implementation attacks (bugs)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:810
+msgid ""
+"Try as we might, most nontrivial applications include errors in the "
+"design or \n"
+"implementation, and I2P is no exception.  There may be bugs that could be"
+" exploited to \n"
+"attack the anonymity or security of the communication running over I2P in"
+" unexpected \n"
+"ways.  To help withstand attacks against the design or protocols in use, "
+"we publish \n"
+"all designs and documentation and solicit review and criticism with \n"
+"the hope that many eyes will improve the system.\n"
+"We do not believe in\n"
+"security through "
+"obscurity."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:821
+msgid ""
+"In addition, the code is being \n"
+"treated the same way, with little aversion towards reworking or throwing "
+"out \n"
+"something that isn't meeting the needs of the software system (including "
+"ease of \n"
+"modification).  Documentation for the design and implementation of the "
+"network and \n"
+"the software components are an essential part of security, as without "
+"them it is \n"
+"unlikely that developers would be willing to spend the time to learn the "
+"software \n"
+"enough to identify shortcomings and bugs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:831
+msgid ""
+"Our software is likely, in particular, to contain bugs related to denial "
+"of service\n"
+"through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues  "
+"in the router console,\n"
+"and other vulnerabilities to non-standard inputs via the various "
+"protocols."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:837
+#, python-format
+msgid ""
+"I2P is still a small network with a small development community and "
+"almost no\n"
+"interest from academic or research groups.\n"
+"Therefore we lack the analysis that\n"
+"other anonymity networks\n"
+"may have received. We continue to recruit people to\n"
+"get involved and help."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:850
+msgid "Blocklists"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:851
+msgid ""
+"To some extent, I2P could be enhanced to avoid peers operating at IP "
+"addresses\n"
+"listed in a blocklist. Several blocklists are commonly available in "
+"standard formats,\n"
+"listing anti-P2P organizations, potential state-level adversaries, and "
+"others."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:857
+msgid ""
+"To the extent that active peers actually do show up in the actual "
+"blocklist,\n"
+"blocking by only a subset of peers would tend to segment the network,\n"
+"exacerbate reachability problems, and decrease overall reliability.\n"
+"Therefore we would want to agree on a particular blocklist and\n"
+"enable it by default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:865
+msgid ""
+"Blocklists are only a part (perhaps a small part) of an array of defenses"
+"\n"
+"against maliciousness.\n"
+"In large part the profiling system does a good job of measuring\n"
+"router behavior so that we don't need to trust anything in netDb.\n"
+"However there is more that can be done. For each of the areas in the\n"
+"list above there are improvements we can make in detecting badness."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:874
+msgid ""
+"If a blocklist is hosted at a central location with automatic updates\n"
+"the network is vulnerable to a\n"
+"central resource attack.\n"
+"Automatic subscription to a list gives the list provider the power to "
+"shut\n"
+"the i2p network down. Completely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:882
+msgid ""
+"Currently, a default blocklist is distributed with our software,\n"
+"listing only the IPs of past DOS sources.\n"
+"There is no automatic update mechanism.\n"
+"Should a particular IP range implement serious attacks on the I2P "
+"network,\n"
+"we would have to ask people to update their blocklist manually through\n"
+"out-of-band mechanisms such as forums, blogs, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:2
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:6
+msgid "Tunnel Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:3
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:3
+msgid "July 2011"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:7
+msgid ""
+"This page contains an overview of I2P tunnel terminology and operation, "
+"with\n"
+"links to more technical pages, details, and specifications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:12
+#, python-format
+msgid ""
+"As briefly explained in the introduction, I2P "
+"builds virtual \"tunnels\" -\n"
+"temporary and unidirectional paths through a sequence of routers.  These"
+" \n"
+"tunnels are classified as either inbound tunnels (where everything \n"
+"given to it goes towards the creator of the tunnel) or outbound tunnels\n"
+"(where the tunnel creator shoves messages away from them).  When Alice\n"
+"wants to send a message to Bob, she will (typically) send it out one of\n"
+"her existing outbound tunnels with instructions for that tunnel's "
+"endpoint\n"
+"to forward it to the gateway router for one of Bob's current inbound \n"
+"tunnels, which in turn passes it to Bob."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:25
+msgid "Alice connecting through her outbound tunnel to Bob via his inbound tunnel"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:27
+msgid "Outbound Gateway"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:28
+msgid "Outbound Participant"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:29
+#: i2p2www/pages/site/docs/tunnels/implementation.html:131
+msgid "Outbound Endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:31
+msgid "Inbound Participant"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:32
+msgid "Inbound Endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:36
+msgid "Tunnel vocabulary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:38
+#, python-format
+msgid ""
+"Tunnel gateway - the first router in a tunnel.  For inbound "
+"tunnels,\n"
+"this is the one mentioned in the LeaseSet published in the\n"
+"network database.  For outbound tunnels, the\n"
+"gateway is the originating router.  (e.g. both A and D above)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:44
+msgid ""
+"Tunnel endpoint - the last router in a tunnel.  (e.g. both C and F"
+" above)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:45
+msgid ""
+"Tunnel participant - all routers in a tunnel except for the "
+"gateway or\n"
+"endpoint (e.g. both B and E above)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:49
+msgid ""
+"n-Hop tunnel - a tunnel with a specific number of inter-router "
+"jumps, e.g.:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:51
+msgid "0-hop tunnel - a tunnel where the gateway is also the endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:52
+msgid ""
+"1-hop tunnel - a tunnel where the gateway talks directly to the "
+"endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:53
+msgid ""
+"2-(or more)-hop tunnel - a tunnel where there is at least one "
+"intermediate\n"
+"tunnel participant. (the above diagram includes two 2-hop tunnels - one\n"
+"outbound from Alice, one inbound to Bob)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:60
+#, python-format
+msgid ""
+"Tunnel ID - A 4 "
+"byte integer\n"
+"different for each hop in a tunnel, and unique among all tunnels on a "
+"router.\n"
+"Chosen randomly by the tunnel creator."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:67
+msgid "Tunnel Build Information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:68
+#, python-format
+msgid ""
+"Routers performing the three roles (gateway, participant, endpoint) are "
+"given\n"
+"different pieces of data in the initial\n"
+"Tunnel Build Message\n"
+"to accomplish their tasks:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:75
+msgid "The tunnel gateway gets:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:77
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:97
+#, python-format
+msgid ""
+"tunnel encryption key - an AES private key for "
+"encrypting\n"
+"messages and instructions to the next hop"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:81
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:101
+#, python-format
+msgid ""
+"tunnel IV key - an AES private key for "
+"double-encrypting\n"
+"the IV to the next hop"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:85
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:105
+#, python-format
+msgid ""
+"reply key - an AES public key for "
+"encrypting\n"
+"the reply to the tunnel build request"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:89
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:109
+msgid ""
+"reply IV - the IV for encrypting the reply to the tunnel build "
+"request"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:90
+msgid "tunnel id - 4 byte integer (inbound gateways only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:91
+msgid ""
+"next hop - what router is the next one in the path (unless this is"
+" a 0-hop tunnel, and the gateway is also the endpoint)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:92
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:112
+msgid "next tunnel id - The tunnel ID on the next hop"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:95
+msgid "All intermediate tunnel participants get:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:110
+msgid "tunnel id - 4 byte integer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:111
+msgid "next hop - what router is the next one in the path"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:115
+msgid "The tunnel endpoint gets:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:117
+#, python-format
+msgid ""
+"tunnel encryption key - an AES private key for "
+"encrypting\n"
+"messages and instructions to the the endpoint (itself)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:121
+#, python-format
+msgid ""
+"tunnel IV key - an AES private key for "
+"double-encrypting\n"
+"the IV to the endpoint (itself)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:125
+#, python-format
+msgid ""
+"reply key - an AES public key for "
+"encrypting\n"
+"the reply to the tunnel build request (outbound endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:129
+msgid ""
+"reply IV - the IV for encrypting the reply to the tunnel build "
+"request (outbound endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:130
+msgid "tunnel id - 4 byte integer (outbound endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:131
+msgid ""
+"reply router - the inbound gateway of the tunnel to send the reply"
+" through (outbound endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:132
+msgid ""
+"reply tunnel id - The tunnel ID of the reply router (outbound "
+"endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:137
+#, python-format
+msgid ""
+"Details are in the\n"
+"tunnel creation specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:142
+msgid "Tunnel pooling"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:143
+#, python-format
+msgid ""
+"Several tunnels for a particular purpose may be grouped into a \"tunnel "
+"pool\",\n"
+"as described in the\n"
+"tunnel specification.\n"
+"This provides redundancy and additional bandwidth.\n"
+"The pools used by the router itself are called \"exploratory tunnels\".\n"
+"The pools used by applications are called \"client tunnels\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:154
+msgid "Tunnel length"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:155
+#, python-format
+msgid ""
+"As mentioned above, each client requests that their router provide "
+"tunnels to\n"
+"include at least a certain number of hops.\n"
+"The decision as to how many routers\n"
+"to have in one's outbound and inbound tunnels has an important effect "
+"upon the\n"
+"latency, throughput, reliability, and anonymity provided by I2P - the "
+"more peers\n"
+"that messages have to go through, the longer it takes to get there and "
+"the more\n"
+"likely that one of those routers will fail prematurely.  The less routers"
+" in a\n"
+"tunnel, the easier it is for an adversary to mount traffic analysis "
+"attacks and\n"
+"pierce someone's anonymity.\n"
+"Tunnel lengths are specified by clients via\n"
+"I2CP options.\n"
+"The maximum number of hops in a tunnel is 7."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:171
+msgid "0-hop tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:172
+msgid ""
+"With no remote routers in a tunnel, the user has very basic plausible\n"
+"deniability (since no one knows for sure that the peer that sent them the"
+"\n"
+"message wasn't simply just forwarding it on as part of the tunnel). "
+"However, it\n"
+"would be fairly easy to mount a statistical analysis attack and notice "
+"that\n"
+"messages targeting a specific destination are always sent through a "
+"single\n"
+"gateway.  Statistical analysis against outbound 0-hop tunnels are more "
+"complex,\n"
+"but could show similar information (though would be slightly harder to "
+"mount)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:182
+msgid "1-hop tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:183
+#, python-format
+msgid ""
+"With only one remote router in a tunnel, the user has both plausible\n"
+"deniability and basic anonymity, as long as they are not up against an "
+"internal\n"
+"adversary (as described on threat model)."
+" However,\n"
+"if the adversary ran a sufficient number of routers such that the single "
+"remote\n"
+"router in the tunnel is often one of those compromised ones, they would "
+"be able\n"
+"to mount the above statistical traffic analysis attack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:192
+msgid "2-hop tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:193
+msgid ""
+"With two or more remote routers in a tunnel, the costs of mounting the "
+"traffic\n"
+"analysis attack increases, since many remote routers would have to be "
+"compromised\n"
+"to mount it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:199
+msgid "3-hop (or more) tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:200
+#, python-format
+msgid ""
+"To reduce the susceptibility to some attacks,\n"
+"3 or more hops are recommended for the highest level of protection.\n"
+"Recent studies\n"
+"also conclude that more than 3 hops does not provide additional "
+"protection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:208
+msgid "Tunnel default lengths"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:209
+#, python-format
+msgid ""
+"The router uses 2-hop tunnels by default for its exploratory tunnels.\n"
+"Client tunnel defaults are set by the application, using\n"
+"I2CP options.\n"
+"Most applications use 2 or 3 hops as their default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:218
+msgid "Tunnel testing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:219
+#, python-format
+msgid ""
+"All tunnels are periodically tested by their creator by sending a\n"
+"DeliveryStatusMessage out an outbound tunnel and bound for another "
+"inbound tunnel\n"
+"(testing both tunnels at once).  If either fails a number of consecutive "
+"tests, it is marked as no longer\n"
+"functional. If it was used for a client's inbound tunnel, a new leaseSet\n"
+"is created.\n"
+"Tunnel test failures are also reflected in the\n"
+"capacity rating in the peer "
+"profile."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:231
+#, python-format
+msgid ""
+"Tunnel creation is handled by garlic "
+"routing\n"
+"a Tunnel Build Message to a router, requesting that they participate in "
+"the\n"
+"tunnel (providing them with all of the appropriate information, as above,"
+" along\n"
+"with a certificate, which right now is a 'null' cert, but will support "
+"hashcash\n"
+"or other non-free certificates when necessary).\n"
+"That router forwards the message to the next hop in the tunnel.\n"
+"Details are in the\n"
+"tunnel creation specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:245
+#, python-format
+msgid ""
+"Multi-layer encryption is handled by garlic"
+" encryption\n"
+"of tunnel messages.\n"
+"Details are in the\n"
+"tunnel specification.\n"
+"The IV of each hop is encrypted with a separate key as explained there."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:257
+msgid ""
+"Other tunnel test techniques could be used, such as\n"
+"garlic wrapping a number of tests into cloves, testing individual tunnel\n"
+"participants separately, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:263
+msgid "Move to 3-hop exploratory tunnels defaults."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:267
+msgid ""
+"In a distant future release,\n"
+"options specifying the pooling, mixing, and chaff generation settings may"
+" be implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:272
+msgid ""
+"In a distant future release,\n"
+"limits on the quantity and size of messages allowed during the\n"
+"tunnel's lifetime may be implemented (e.g. no more than 300 messages or\n"
+"1MB per minute)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:284
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:15
+msgid "Tunnel specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:286
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:17
+msgid "Tunnel creation specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:290
+msgid "Tunnel message specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:294
+msgid "ElGamal/AES+SessionTag"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:296
+msgid "I2CP options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:6
+msgid ""
+"The I2P Client Protocol (I2CP) exposes a strong separation of concerns "
+"between\n"
+"the router and any client that wishes to communicate over the network.  "
+"It enables\n"
+"secure and asynchronous messaging by sending and receiving messages over "
+"a \n"
+"single TCP socket, yet never exposing any private keys and authenticating"
+" itself\n"
+"to the router only through signatures.  With I2CP, a client application "
+"tells the\n"
+"router who they are (their \"destination\"), what anonymity, reliability,"
+" and \n"
+"latency tradeoffs to make, and where to send messages.  In turn the "
+"router uses\n"
+"I2CP to tell the client when any messages have arrived, and to request "
+"authorization\n"
+"for some tunnels to be used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:18
+#, python-format
+msgid ""
+"The protocol itself has only been implemented in Java, to provide the\n"
+"Client SDK.\n"
+"This SDK is exposed in the i2p.jar package, which implements the client-"
+"side of I2CP.\n"
+"Clients should never need to access the router.jar package, which "
+"contains the\n"
+"router itself and the router-side of I2CP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:26
+#, python-format
+msgid ""
+"While implementing the client side of I2CP in a non-Java language is "
+"certainly feasible,\n"
+"a non-Java client would also have to implement the\n"
+"streaming library for TCP-style "
+"connections.\n"
+"Together, implementing I2CP and the streaming library would be a sizable "
+"task."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:33
+#, python-format
+msgid ""
+"Applications can take advantage of the base I2CP plus the \n"
+"streaming and datagram libraries\n"
+"by using the Simple Anonymous Messaging or BOB protocols,\n"
+"which do not require clients to deal with any sort of cryptography.\n"
+"Also, clients may access the network by one of several proxies -\n"
+"HTTP, CONNECT, and SOCKS 4/4a/5.\n"
+"Alternatively, Java clients may access those libraries in "
+"ministreaming.jar and streaming.jar.\n"
+"So there are several options for both Java and non-Java applications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:45
+#, python-format
+msgid ""
+"Client-side end-to-end encryption (encrypting the data over the I2CP "
+"connection)\n"
+"was disabled in I2P release 0.6,\n"
+"leaving in place the ElGamal/AES end-to-end "
+"encryption\n"
+"which is implemented in the router.\n"
+"The only cryptography that client libraries must still implement is\n"
+"DSA public/private key signing\n"
+"for LeaseSets and\n"
+"Session Configurations, and"
+" management of those keys."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:58
+msgid ""
+"In a standard I2P installation, port 7654 is used by external java "
+"clients to communicate\n"
+"with the local router via I2CP.\n"
+"By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, "
+"set the\n"
+"router advanced configuration option "
+"i2cp.tcp.bindAllInterfaces=true and restart.\n"
+"Clients in the same JVM as the router pass messages directly to the "
+"router\n"
+"through an internal JVM interface."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:67
+msgid "I2CP Protocol Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:68
+#, python-format
+msgid "Now on the I2CP Specification page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:73
+msgid "I2CP Initialization"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:74
+#, python-format
+msgid ""
+"When a client connects to the router, it first sends a single protocol "
+"version byte (0x2A).\n"
+"Then it sends a GetDate Message and "
+"waits for the SetDate Message "
+"response.\n"
+"Next, it sends a CreateSession "
+"Message containing the session configuration.\n"
+"It next awaits a RequestLeaseSet"
+" Message from the router, indicating that inbound tunnels\n"
+"have been built, and responds with a CreateLeaseSetMessage containing the"
+" signed LeaseSet.\n"
+"The client may now initiate or receive connections from other I2P "
+"destinations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:83
+msgid "I2CP Options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:84
+#, python-format
+msgid ""
+"The following options are traditionally passed to the router via\n"
+"a SessionConfig contained "
+"in a CreateSession Message or "
+"a ReconfigureSession "
+"Message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:90
+msgid "Router-side Options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:95
+#: i2p2www/pages/site/docs/protocol/i2cp.html:438
+msgid "As Of Release"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:96
+#: i2p2www/pages/site/docs/protocol/i2cp.html:439
+msgid "Recommended Arguments"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:97
+#: i2p2www/pages/site/docs/protocol/i2cp.html:440
+msgid "Allowable Range"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:105
+#: i2p2www/pages/site/docs/protocol/i2cp.html:118
+#: i2p2www/pages/site/docs/protocol/i2cp.html:127
+#: i2p2www/pages/site/docs/protocol/i2cp.html:136
+#: i2p2www/pages/site/docs/protocol/i2cp.html:145
+#: i2p2www/pages/site/docs/protocol/i2cp.html:160
+#: i2p2www/pages/site/docs/protocol/i2cp.html:175
+#: i2p2www/pages/site/docs/protocol/i2cp.html:184
+#: i2p2www/pages/site/docs/protocol/i2cp.html:232
+#: i2p2www/pages/site/docs/protocol/i2cp.html:244
+#: i2p2www/pages/site/docs/protocol/i2cp.html:256
+#, python-format
+msgid "number from %(from)s to %(to)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:106
+#: i2p2www/pages/site/docs/protocol/i2cp.html:128
+#: i2p2www/pages/site/docs/protocol/i2cp.html:137
+#: i2p2www/pages/site/docs/protocol/i2cp.html:146
+#: i2p2www/pages/site/docs/protocol/i2cp.html:161
+#: i2p2www/pages/site/docs/protocol/i2cp.html:233
+#: i2p2www/pages/site/docs/protocol/i2cp.html:245
+#: i2p2www/pages/site/docs/protocol/i2cp.html:257
+#: i2p2www/pages/site/docs/protocol/i2cp.html:530
+#, python-format
+msgid "%(from)s to %(to)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:108
+msgid ""
+"Number of tunnels in.\n"
+"Limit was increased from 6 to 16 in release 0.9; however, numbers higher "
+"than 6 are not\n"
+"currently recommended, as this is untested and is incompatible with older"
+" releases."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:119
+#: i2p2www/pages/site/docs/protocol/i2cp.html:176
+#: i2p2www/pages/site/docs/protocol/i2cp.html:185
+msgid "No limit"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:121
+msgid "Number of tunnels out"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:130
+msgid "Length of tunnels in"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:139
+msgid "Length of tunnels out"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:148
+msgid ""
+"Random amount to add or subtract to the length of tunnels in.\n"
+"A positive number x means add a random amount from 0 to x inclusive.\n"
+"A negative number -x means add a random amount from -x to x inclusive.\n"
+"The router will limit the total length of the tunnel to 0 to 7 inclusive."
+"\n"
+"The default variance was 1 prior to release 0.7.6."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:163
+msgid ""
+"Random amount to add or subtract to the length of tunnels out.\n"
+"A positive number x means add a random amount from 0 to x inclusive.\n"
+"A negative number -x means add a random amount from -x to x inclusive.\n"
+"The router will limit the total length of the tunnel to 0 to 7 inclusive."
+"\n"
+"The default variance was 1 prior to release 0.7.6."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:178
+msgid "Number of redundant fail-over for tunnels in"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:187
+msgid "Number of redundant fail-over for tunnels out"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:196
+msgid ""
+"Name of tunnel - generally used in routerconsole, which will\n"
+"use the first few characters of the Base64 hash of the destination by "
+"default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:208
+msgid "Name of tunnel - generally ignored unless inbound.nickname is unset."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:217
+msgid "If incoming zero hop tunnel is allowed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:226
+msgid "If outgoing zero hop tunnel is allowed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:235
+#: i2p2www/pages/site/docs/protocol/i2cp.html:247
+msgid ""
+"Number of IP bytes to match to determine if\n"
+"two routers should not be in the same tunnel. 0 to disable."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:259
+msgid ""
+"Priority adjustment for outbound messages.\n"
+"Higher is higher priority."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:271
+msgid "Should generally be set to true for clients and false for servers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:280
+msgid ""
+"Guaranteed is disabled;\n"
+"None implemented in 0.8.1; the streaming lib default is None as of 0.8.1,"
+" the client side default is None as of 0.9.4"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:292
+#: i2p2www/pages/site/docs/protocol/i2cp.html:571
+msgid ""
+"If true, the router just sends the MessagePayload instead\n"
+"of sending a MessageStatus and awaiting a ReceiveMessageBegin."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:304
+msgid ""
+"Comma-separated list of Base 64 Hashes of peers to build tunnels through;"
+" for debugging only"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:313
+#: i2p2www/pages/site/docs/protocol/i2cp.html:325
+msgid ""
+"For authorization, if required by the router.\n"
+"If the client is running in the same JVM as a router, this option is not "
+"required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:337
+msgid ""
+"Number of ElGamal/AES Session Tags to send at a time.\n"
+"For clients with relatively low bandwidth per-client-pair (IRC, some UDP "
+"apps), this may be set lower."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:349
+msgid ""
+"Minimum number of ElGamal/AES Session Tags before we send more.\n"
+"Recommended: approximately tagsToSend * 2/3"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:361
+msgid ""
+"Set to false to disable ever bundling a reply LeaseSet.\n"
+"For clients that do not publish their LeaseSet, this option must be true\n"
+"for any reply to be possible. \"true\" is also recommended for multihomed"
+" servers\n"
+"with long connection times."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:368
+msgid ""
+"Setting to \"false\" may save significant outbound bandwidth, especially "
+"if\n"
+"the client is configured with a large number of inbound tunnels (Leases)."
+"\n"
+"If replies are still required, this may shift the bandwidth burden to\n"
+"the far-end client and the floodfill.\n"
+"There are several cases where \"false\" may be appropriate:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:376
+msgid "Unidirectional communication, no reply required"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:377
+msgid "LeaseSet is published and higher reply latency is acceptable"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:378
+msgid ""
+"LeaseSet is published, client is a \"server\", all connections are "
+"inbound\n"
+"so the connecting far-end destination obviously has the leaseset already."
+"\n"
+"Connections are either short, or it is acceptable for latency on a long-"
+"lived\n"
+"connection to temporarily increase while the other end re-fetches the "
+"LeaseSet\n"
+"after expiration.\n"
+"HTTP servers may fit these requirements."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:396
+msgid ""
+"Any other options prefixed with \"inbound.\" are stored\n"
+"in the \"unknown options\" properties of the inbound tunnel pool's "
+"settings."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:408
+msgid ""
+"Any other options prefixed with \"outbound.\" are stored\n"
+"in the \"unknown options\" properties of the outbound tunnel pool's "
+"settings."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:415
+msgid ""
+"Note: Large quantity, length, or variance settings may cause significant "
+"performance or reliability problems."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:419
+msgid ""
+"Note: As of release 0.7.7, option names and values must use UTF-8 "
+"encoding.\n"
+"This is primarily useful for nicknames.\n"
+"Prior to that release, options with multi-byte characters were corrupted."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:425
+msgid ""
+"The following options are interpreted on the client side,\n"
+"and will be interpreted if passed to the I2PSession via the "
+"I2PClient.createSession() call.\n"
+"The streaming lib should also pass these options through to I2CP.\n"
+"Other implementations may have different defaults."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:433
+msgid "Client-side Options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:451
+msgid ""
+"Router hostname.\n"
+"If the client is running in the same JVM as a router, this option is "
+"ignored, and the client connects to that router internally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:463
+msgid ""
+"Router I2CP port.\n"
+"If the client is running in the same JVM as a router, this option is "
+"ignored, and the client connects to that router internally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:475
+msgid ""
+"Connect to the router using SSL.\n"
+"If the client is running in the same JVM as a router, this option is "
+"ignored, and the client connects to that router internally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:487
+msgid "Gzip outbound data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:496
+msgid "Reduce tunnel quantity when idle"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:505
+msgid "Close I2P session when idle"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:512
+#: i2p2www/pages/site/docs/protocol/i2cp.html:521
+#, python-format
+msgid "%(num)s minimum"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:514
+msgid "(ms) Idle time required (default 20 minutes, minimum 5 minutes)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:523
+msgid "(ms) Idle time required (default 30 minutes)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:532
+msgid "Tunnel quantity when reduced (applies to both inbound and outbound)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:541
+msgid "Encrypt the lease"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:550
+msgid "Base64 SessionKey (44 characters)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:559
+msgid ""
+"Guaranteed is disabled;\n"
+"None implemented in 0.8.1; None is the default as of 0.9.4"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:578
+msgid ""
+"Note: All arguments, including numbers, are strings. True/false values "
+"are case-insensitive strings.\n"
+"Anything other than case-insensitive \"true\" is interpreted as false.\n"
+"All option names are case-sensitive."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:584
+msgid "I2CP Payload Data Format and Multiplexing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:585
+#, python-format
+msgid ""
+"The end-to-end messages handled by I2CP (i.e. the data sent by the client"
+" in a\n"
+"SendMessageMessage\n"
+"and received by the client in a\n"
+"MessagePayloadMessage)\n"
+"are gzipped with a standard 10-byte gzip\n"
+"header beginning with 0x1F 0x8B 0x08 as\n"
+"specified by RFC "
+"1952.\n"
+"As of release 0.7.1, I2P uses ignored portions of the gzip header to "
+"include\n"
+"protocol, from-port, and to-port information, thus supporting streaming "
+"and\n"
+"datagrams on the same destination, and allowing query/response using "
+"datagrams\n"
+"to work reliably in the presence of multiple channels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:599
+msgid ""
+"The gzip function cannot be completely turned off, however setting "
+"i2cp.gzip=false\n"
+"turns the gzip effort setting to 0, which may save a little CPU."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:605
+#: i2p2www/pages/site/docs/protocol/i2np.html:38
+msgid "Bytes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:606
+#: i2p2www/pages/site/get-involved/index.html:38
+msgid "Content"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:611
+msgid "Gzip header"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:616
+msgid "Gzip flags"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:621
+msgid "I2P Source port (Gzip mtime)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:626
+msgid "I2P Destination port (Gzip mtime)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:631
+msgid "Gzip xflags"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:636
+msgid "I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:640
+msgid ""
+"Data integrity is verified with the standard gzip CRC-32 as\n"
+"specified by RFC 1952."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:648
+msgid "Implement I2CP and the streaming library in another programming language."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:652
+msgid "Is the initial Get Date / Set Date handshake required?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:656
+msgid ""
+"The current authorization mechanism could be modified to use hashed "
+"passwords."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:660
+msgid ""
+"Private Keys are included in the Create Lease Set message,\n"
+"are they really required? Revocation is unimplemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:665
+#, python-format
+msgid ""
+"Some improvements may be able to use messages previously defined but not "
+"implemented.\n"
+"For reference, here is the\n"
+"I2CP Protocol Specification Version 0.9\n"
+"(PDF) dated August 28, 2003.\n"
+"That document also references the\n"
+"Common Data Structures Specification Version 0.9."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:6
+msgid "I2P Network Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:7
+msgid ""
+"The I2P Network Protocol (I2NP),\n"
+"which is sandwiched between I2CP and the various I2P transport protocols,"
+" manages the\n"
+"routing and mixing of messages between routers, as well as the selection "
+"of what\n"
+"transports to use when communicating with a peer for which there are "
+"multiple\n"
+"common transports supported."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:15
+msgid "I2NP Definition"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:16
+msgid ""
+"I2NP (I2P Network Protocol) messages can be used for one-hop, router-to-"
+"router, point-to-point messages.\n"
+"By encrypting and wrapping messages in other messages, they can be sent "
+"in a secure way\n"
+"through multiple hops to the ultimate destination.\n"
+"Priority is only used locally at the origin, i.e. when queuing for "
+"outbound delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:23
+msgid ""
+"Both the NTCP and UDP transports implement priority transmission,\n"
+"but in quite different manners.\n"
+"UDP has complex code with queues for each priority, however it treats\n"
+"messages with priorities 400-499, for example, the same.\n"
+"(The priority queues are 100, 200, 300, 400, 500, and 1000)\n"
+"These are global queues for all peers.\n"
+"NTCP has a trivial linear search for the highest priority within\n"
+"each buffer for a particular peer.\n"
+"This is much less effective."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:35
+msgid "Message Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:38
+#: i2p2www/pages/site/docs/spec/streaming.html:35
+msgid "Field"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:39
+msgid "Unique ID"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:40
+msgid "Expiration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:41
+#: i2p2www/pages/site/docs/protocol/i2np.html:98
+msgid "Payload Length"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:42
+msgid "Checksum"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:43
+msgid "Payload"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:46
+#, python-format
+msgid ""
+"While the maximum payload size is nominally 64KB, the size is further "
+"constrained by the\n"
+"method of fragmenting I2NP messages into multiple 1KB tunnel messages as "
+"described on\n"
+"the tunnel implementation page.\n"
+"The maximum number of fragments is 64, and the message may not be "
+"perfectly aligned,\n"
+"So the message must nominally fit in 63 fragments."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:54
+msgid ""
+"The maximum size of an initial fragment is 956 bytes (assuming TUNNEL "
+"delivery mode);\n"
+"the maximum size of a follow-on fragment is 996 bytes.\n"
+"Therefore the maximum size is approximately 956 + (62 * 996) = 62708 "
+"bytes, or 61.2 KB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:60
+msgid ""
+"In addition, the transports may have additional restrictions.\n"
+"NTCP currently limits to 16KB - 6 = 16378 bytes but this will be "
+"increased in a future release.\n"
+"The SSU limit is approximately 32 KB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:66
+msgid ""
+"Note that these are not the limits for datagrams that the client sees, as"
+" the\n"
+"router may bundle a reply leaseset and/or session tags together with the "
+"client message\n"
+"in a garlic message. The leaseset and tags together may add about 5.5KB.\n"
+"Therefore the current datagram limit is about 10KB. This limit will be\n"
+"increased in a future release."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:74
+msgid "Message Types"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:75
+msgid ""
+"Higher-numbered priority is higher priority.\n"
+"The majority of traffic is TunnelDataMessages (priority 400),\n"
+"so anything above 400 is essentially high priority, and\n"
+"anything below is low priority.\n"
+"Note also that many of the messages are generally routed\n"
+"through exploratory tunnels, not client tunnels, and\n"
+"therefore may not be in the same queue unless the\n"
+"first hops happen to be on the same peer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:86
+msgid ""
+"Also, not all message types are sent unencrypted.\n"
+"For example, when testing a tunnel, the router wraps a\n"
+"DeliveryStatusMessage, which is wrapped in a GarlicMessage,\n"
+"which is wrapped in a DataMessage."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:97
+msgid "Type"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:99
+msgid "Priority"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:100
+msgid "Comments"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:108
+msgid ""
+"400 normally; 100 if from HarvesterJob and sent directly;\n"
+"400 for a router lookup"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:119
+msgid ""
+"Size is 65 + 32*(number of hashes) where typically, the hashes for\n"
+"three floodfill routers are returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:128
+msgid "Varies"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:130
+msgid ""
+"Usually 100 (why?)\n"
+"Size is 898 bytes for a typical 2-lease leaseSet.\n"
+"RouterInfo structures are compressed, and size varies; however\n"
+"there is a continuing effort to reduce the amount of data published in a "
+"RouterInfo\n"
+"as we approach release 1.0."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:152
+msgid ""
+"Used for message replies, and for testing tunnels - generally wrapped in "
+"a GarlicMessage"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:160
+msgid ""
+"Generally wrapped in a DataMessage -\n"
+"but when unwrapped, given a priority of 100 by the forwarding router"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:171
+msgid "Usually 500 (why?)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:187
+msgid ""
+"The most common message. Priority for tunnel participants, outbound "
+"endpoints, and inbound gateways was\n"
+"reduced to 200 as of release 0.6.1.33.\n"
+"Outbound gateway messages (i.e. those originated locally) remains at 400."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:207
+msgid "Shorter TunnelBuildMessage as of 0.7.12"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:215
+msgid "Shorter TunnelBuildReplyMessage as of 0.7.12"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:218
+#, python-format
+msgid "Others listed in 2003 Spec"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:224
+msgid "Obsolete, Unused"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:228
+msgid "Full Protocol Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:229
+#, python-format
+msgid ""
+"On the I2NP Specification page.\n"
+"See also the\n"
+"Common Data Structure Specification "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:236
+msgid ""
+"It isn't clear whether the current priority scheme is generally "
+"effective,\n"
+"and whether the priorities for various messages should be adjusted "
+"further.\n"
+"This is a topic for further research, analysis and testing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:2
+msgid "Protocol Stack"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:7
+#, python-format
+msgid ""
+"Here is the protocol stack for I2P.\n"
+"See also the Index to Technical Documentation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:12
+msgid ""
+"Each of the layers in the stack provides extra capabilities.\n"
+"The capabilities are listed below, starting at the bottom of the protocol"
+" stack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:18
+msgid "Internet Layer:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:20
+msgid ""
+"IP: Internet Protocol, allow addressing hosts on the regular internet and"
+" routing packets across the internet using best-effort delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:23
+msgid "Transport Layer:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:25
+msgid ""
+"TCP: Transmission Control Protocol, allow reliable, in-order delivery of "
+"packets across the internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:27
+msgid ""
+"UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of "
+"packets across the internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:30
+msgid ""
+"I2P Transport Layer: provide encrypted connections between 2 I2P "
+"routers. These are not anonymous yet, this is strictly a hop-to-hop "
+"connection.\n"
+"Two protocols are implemented to provide these capabilities. NTCP builds "
+"on top of TCP, while SSU uses UDP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:35
+msgid "NIO-based TCP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:37
+msgid "Secure Semi-reliable UDP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:40
+msgid "I2P Tunnel Layer: provide full encrypted tunnel connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:42
+#, python-format
+msgid ""
+"Tunnel messages: tunnel messages are "
+"large messages containing encrypted I2NP (see below) messages and "
+"encrypted instructions for their delivery.\n"
+"The encryption is layered. The first hop will decrypt the tunnel message "
+"and read a part. Another part can still be encrypted (with another key),"
+"\n"
+"so it will be forwarded."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:48
+#, python-format
+msgid ""
+"I2NP messages: I2P Network Protocol messages are"
+" used to pass messages through multiple routers. These I2NP messages are "
+"combined in tunnel messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:53
+msgid ""
+"I2P Garlic Layer: provide encrypted and anonymous end-to-end I2P "
+"message delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:55
+#, python-format
+msgid ""
+"I2NP messages: I2P Network Protocol messages are"
+" wrapped in each other and used to ensure encryption between two tunnels "
+"and are passed along from source to destination, keeping both anonymous."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:61
+msgid ""
+"The following layers are strictly speaking no longer part of the I2P "
+"Protocol stack, they are not part of the core 'I2P router' functionality."
+"\n"
+"However, each of these layers adds additional functionality, to allow "
+"applications simple and convenient I2P usage."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:67
+msgid ""
+"I2P Client Layer: allow any client to use I2P functionality, "
+"without requiring the direct use of the router API."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:69
+#, python-format
+msgid ""
+"I2CP: I2P Client Protocol, allows secure and "
+"asynchronous messaging over I2P by communicating messages over the I2CP "
+"TCP socket."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:74
+msgid ""
+"I2P End-to-end Transport Layer: allow TCP- or UDP-like "
+"functionality on top of I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:76
+#, python-format
+msgid ""
+"Streaming Library: an implementation of "
+"TCP-like streams over I2P. This allows easier porting of existing "
+"applications to I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:80
+#, python-format
+msgid ""
+"Datagram Library: an implementation of UDP-"
+"like messages over I2P. This allows easier porting of existing "
+"applications to I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:85
+msgid ""
+"I2P Application Interface Layer: additional (optional) libraries "
+"allowing easier implementations on top of I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:93
+msgid "I2P Application Proxy Layer: proxy systems."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:95
+#, python-format
+msgid "HTTP Client/Server, IRC Client, SOCKS, Streamr"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:99
+msgid ""
+"Finally, what could be considered the 'I2P application layer', is "
+"a large number of applications on top of I2P.\n"
+"We can order this based on the I2P stack layer they use."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:104
+msgid "Streaming/datagram applications: i2psnark, Syndie, i2phex..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:105
+msgid "SAM/BOB applications: IMule, i2p-bt, i2prufus, Robert..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:106
+#, python-format
+msgid ""
+"Other I2P applications: Syndie, EepGet, plugins..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:107
+msgid ""
+"Regular applications: Jetty, Apache, Monotone, CVS, browsers, "
+"e-mail..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:111
+msgid "I2P Network stack"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:113
+msgid "Figure 1: The layers in the I2P Network stack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:118
+msgid "Note: SAM/SAMv2 can use both the streaming lib and datagrams."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:2
+msgid "I2P Blockfile Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:3
+msgid "January 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:6
+msgid "Blockfile and Hosts Database Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:8
+#, python-format
+msgid ""
+"This document specifies\n"
+"the I2P blockfile file format\n"
+"and the tables in the hostsdb.blockfile used by the Blockfile Naming Service."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:14
+msgid ""
+"The blockfile provides fast Destination lookup in a compact format. While"
+" the blockfile page overhead is substantial,\n"
+"the destinations are stored in binary rather than in Base 64 as in the "
+"hosts.txt format.\n"
+"In addition, the blockfile provides the capability of arbitrary metadata "
+"storage\n"
+"(such as added date, source, and comments) for each entry.\n"
+"The metadata may be used in the future to provide advanced addressbook "
+"features.\n"
+"The blockfile storage requirement is a modest increase over the hosts.txt"
+" format, and the blockfile provides\n"
+"approximately 10x reduction in lookup times."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:24
+#, python-format
+msgid ""
+"A blockfile is simply on-disk storage of multiple sorted maps (key-value "
+"pairs),\n"
+"implemented as skiplists.\n"
+"The blockfile format is adopted from the\n"
+"Metanotion Blockfile Database.\n"
+"First we will define the file format, then the use of that format by the "
+"BlockfileNamingService."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:32
+msgid "Blockfile Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:33
+msgid ""
+"The original blockfile spec was modified to add magic numbers to each "
+"page.\n"
+"The file is structured in 1024-byte pages. Pages are numbered starting "
+"from 1.\n"
+"The \"superblock\" is always at page 1, i.e. starting at byte 0 in the "
+"file.\n"
+"The metaindex skiplist is always at page 2, i.e. starting at byte 1024 in"
+" the file."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:40
+msgid ""
+"All 2-byte integer values are unsigned.\n"
+"All 4-byte integer values (page numbers) are signed and negative values "
+"are illegal."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:45
+msgid ""
+"The database is designed to be opened and accessed by a single thread.\n"
+"The BlockfileNamingService provides synchronization."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:50
+msgid "Superblock format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:65
+msgid "Skip list block page format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:80
+msgid ""
+"Skip level block page format is as follows.\n"
+"All levels have a span. Not all spans have levels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:95
+msgid ""
+"Skip span block page format is as follows.\n"
+"Key/value structures are sorted by key within each span and across all "
+"spans.\n"
+"Key/value structures are sorted by key within each span.\n"
+"Spans other than the first span may not be empty."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:112
+msgid "Span Continuation block page format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:123
+msgid ""
+"Key/value structure format is as follows.\n"
+"Key and value lengths must not be split across pages, i.e. all 4 bytes "
+"must be on the same page.\n"
+"If there is not enough room the last 1-3 bytes of a page are unused and "
+"the lengths will\n"
+"be at offset 8 in the continuation page.\n"
+"Key and value data may be split across pages.\n"
+"Max key and value lengths are 65535 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:139
+msgid "Free list block page format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:151
+msgid "Free page block format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:160
+msgid ""
+"The metaindex (located at page 2) is a mapping of US-ASCII strings to "
+"4-byte integers.\n"
+"The key is the name of the skiplist and the value is the page index of "
+"the skiplist."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:165
+msgid "Blockfile Naming Service Tables"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:166
+msgid ""
+"The tables created and used by the BlockfileNamingService are as follows."
+"\n"
+"The maximum number of entries per span is 16."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:171
+msgid "Properties Skiplist"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:172
+#, python-format
+msgid ""
+"\"%%__INFO__%%\" is the master database skiplist with String/Properties "
+"key/value entries containing only one entry:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:184
+msgid "Reverse Lookup Skiplist"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:185
+#, python-format
+msgid ""
+"\"%%__REVERSE__%%\" is the reverse lookup skiplist with "
+"Integer/Properties key/value entries\n"
+"    (as of database version 2):"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:199
+msgid "hosts.txt, userhosts.txt, and privatehosts.txt Skiplists"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:200
+msgid ""
+"For each host database, there is a skiplist containing\n"
+"the hosts for that database.\n"
+"The keys/values in these skiplists are as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:211
+msgid "The DestEntry Properties typically contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:220
+msgid "Hostname keys are stored in lower-case and always end in \".i2p\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:2
+msgid "Common structure Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:6
+msgid "Data types Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:7
+#, python-format
+msgid ""
+"This document describes some data types common to all I2P protocols, like"
+"\n"
+"I2NP, I2CP,\n"
+"SSU, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:17
+msgid "Represents a non-negative integer.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:20
+#: i2p2www/pages/site/docs/spec/common-structures.html:31
+#: i2p2www/pages/site/docs/spec/common-structures.html:41
+#: i2p2www/pages/site/docs/spec/common-structures.html:54
+#: i2p2www/pages/site/docs/spec/common-structures.html:69
+#: i2p2www/pages/site/docs/spec/common-structures.html:82
+#: i2p2www/pages/site/docs/spec/common-structures.html:94
+#: i2p2www/pages/site/docs/spec/common-structures.html:106
+#: i2p2www/pages/site/docs/spec/common-structures.html:118
+#: i2p2www/pages/site/docs/spec/common-structures.html:130
+#: i2p2www/pages/site/docs/spec/common-structures.html:142
+#: i2p2www/pages/site/docs/spec/common-structures.html:154
+#: i2p2www/pages/site/docs/spec/common-structures.html:166
+#: i2p2www/pages/site/docs/spec/common-structures.html:178
+#: i2p2www/pages/site/docs/spec/common-structures.html:233
+#: i2p2www/pages/site/docs/spec/common-structures.html:302
+#: i2p2www/pages/site/docs/spec/common-structures.html:353
+#: i2p2www/pages/site/docs/spec/common-structures.html:399
+#: i2p2www/pages/site/docs/spec/common-structures.html:448
+#: i2p2www/pages/site/docs/spec/common-structures.html:572
+#: i2p2www/pages/site/docs/spec/common-structures.html:628
+#: i2p2www/pages/site/docs/spec/streaming.html:35
+#: i2p2www/pages/site/get-involved/develop/applications.html:6
+msgid "Contents"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:21
+msgid "1 to 8 bytes in network byte order representing an unsigned integer\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:27
+msgid ""
+"The number of milliseconds since midnight on January 1, 1970 in the GMT "
+"timezone.\n"
+"If the number is 0, the date is undefined or null.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:32
+msgid "8 byte Integer\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:38
+msgid "Represents a UTF-8 encoded string.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:42
+msgid ""
+"1 or more bytes where the first byte is the number of bytes (not "
+"characters!)\n"
+"in the string and the remaining 0-255 bytes are the non-null terminated "
+"UTF-8 encoded character array.\n"
+"Length limit is 255 bytes (not characters). Length may be 0.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:50
+msgid ""
+"A boolean value, supporting null/unknown representation\n"
+"0=false, 1=true, 2=unknown/null\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:55
+msgid "1 byte Integer\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:59
+msgid "Deprecated - unused\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:65
+#, python-format
+msgid ""
+"This structure is used in ElGamal encryption, representing only the "
+"exponent, not the primes, which are constant and defined in\n"
+"the cryptography specification.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:70
+#: i2p2www/pages/site/docs/spec/common-structures.html:83
+msgid "256 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:78
+#, python-format
+msgid ""
+"This structure is used in ElGamal decryption, representing only the "
+"exponent, not the primes which are constant and defined in\n"
+"the cryptography specification.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:91
+msgid "This structure is used for AES256 encryption and decryption.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:95
+#: i2p2www/pages/site/docs/spec/common-structures.html:143
+#: i2p2www/pages/site/docs/spec/common-structures.html:155
+msgid "32 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:103
+#, python-format
+msgid ""
+"This structure is used for verifying DSA signatures.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:107
+msgid "128 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:115
+#, python-format
+msgid ""
+"This structure is used for creating DSA signatures.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:119
+msgid "20 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:127
+#, python-format
+msgid ""
+"This structure represents the DSA "
+"signature of some data.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:131
+msgid "40 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:139
+msgid "Represents the SHA256 of some data.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:151
+msgid "A random number\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:163
+msgid "Defines an identifier that is unique to each router in a tunnel.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:167
+msgid "4 byte Integer\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:175
+msgid ""
+"A certificate is a container for various receipts or proof of works used "
+"throughout the I2P network.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:179
+msgid ""
+"1 byte Integer specifying certificate type,"
+" followed by a 2 Integer specifying the "
+"size of the certificate payload, then that many bytes.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:207
+msgid ""
+"For Router Identities, the "
+"Certificate is always NULL, no others are currently implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:211
+#, python-format
+msgid ""
+"For Garlic Cloves, the "
+"Certificate is always NULL, no others are currently implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:215
+#, python-format
+msgid ""
+"For Garlic Messages, the Certificate "
+"is always NULL, no others are currently implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:219
+msgid ""
+"For Destinations, the Certificate may"
+" be non-NULL,\n"
+"however non-NULL certs are not widely used, and any checking is left to "
+"the application-level."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:230
+msgid "A set of key/value mappings or properties\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:234
+msgid "A 2-byte size Integer followed by a series of String=String; pairs\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:263
+msgid ""
+"The encoding isn't optimal - we either need the '=' and ';' characters, "
+"or the string lengths, but not both"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:267
+msgid ""
+"Some documentation says that the strings may not include '=' or ';' but "
+"this encoding supports them"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:271
+msgid ""
+"Strings are defined to be UTF-8 but in the current implementation, I2CP "
+"uses UTF-8 but I2NP does not.\n"
+"For example,\n"
+"UTF-8 strings in a RouterInfo options mapping in a I2NP Database Store "
+"Message will be corrupted."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:277
+msgid ""
+"Mappings contained in I2NP messages (i.e. in a RouterAddress or "
+"RouterInfo)\n"
+"must be sorted by key so that the signature will be invariant."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:282
+msgid ""
+"Key and value string length limits are 255 bytes (not characters) each, "
+"plus the length byte. Length byte may be 0."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:286
+msgid ""
+"Total length limit is 65535 bytes, plus the 2 byte size field, or 65537 "
+"total."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:295
+msgid "Common structure specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:299
+msgid "Defines the way to uniquely identify a particular router\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:303
+msgid ""
+"PublicKey followed by SigningPublicKey and then a Certificate\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:342
+msgid ""
+"The certificate for a RouterIdentity is currently unused and is always "
+"NULL."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:350
+msgid ""
+"A Destination defines a particular endpoint to which messages can be "
+"directed for secure delivery.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:354
+msgid ""
+"PublicKey followed by a SigningPublicKey and then a Certificate\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:396
+msgid ""
+"Defines the authorization for a particular tunnel to receive messages "
+"targeting a Destination.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:400
+msgid ""
+"SHA256 Hash of the\n"
+"RouterIdentity of the gateway "
+"router, then the TunnelId, and finally an "
+"end Date\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:433
+msgid "Total size: 44 bytes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:443
+msgid ""
+"Contains all of the currently authorized Leases for a particular Destination, the PublicKey to which garlic messages can be "
+"encrypted,\n"
+"and then the public key that can "
+"be used to revoke this particular version of the structure. The LeaseSet is one of the two structures "
+"stored in the network database(\n"
+"the other being RouterInfo), and is "
+"keyed under the SHA256 of the contained Destination.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:449
+msgid ""
+"Destination, followed by a PublicKey for encryption, then a SigningPublicKey which can be used to"
+" revoke this version of the LeaseSet,\n"
+"then a 1 byte Integer specifying how many "
+"Lease structures are in the set, followed "
+"by the actual Lease structures and finally "
+"a Signature  of the previous\n"
+"bytes signed by the Destination's SigningPrivateKey"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:543
+msgid ""
+"The public key of the destination was used for the old i2cp-to-i2cp "
+"encryption\n"
+"which was disabled in version 0.6, it is currently unused?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:548
+#, python-format
+msgid ""
+"The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption.\n"
+"It is currently generated anew at every router startup, it is not "
+"persistent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:553
+msgid ""
+"The signature may be verified using the signing public key of the "
+"destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:557
+msgid ""
+"The signing_key is currently unused. It was intended for LeaseSet "
+"revocation, which is unimplemented.\n"
+"It is currently generated anew at every router startup, it is not "
+"persistent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:569
+msgid ""
+"This structure defines the means to contact a router through a transport "
+"protocol.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:573
+msgid ""
+"1 byte Integer defining the relative cost "
+"of using the address, where 0 is free and 255 is expensive, followed by "
+"the expiration Date after which the address "
+"should not be used, or if null, the address never expires.\n"
+"After that comes a String defining the "
+"transport protocol this router address uses. Finally there is a Mapping containing all of the transport "
+"specific options necessary to establish the connection, such as\n"
+"IP address, port number, email address, URL, etc.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:610
+msgid "Cost is typically 5 or 6 for SSU, and 10 or 11 for NTCP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:614
+msgid "Expiration is currently unused, always null (all zeroes))"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:624
+msgid ""
+"Defines all of the data that a router wants to publish for the network to"
+" see. The RouterInfo is one of two "
+"structures stored in the network database(the other being LeaseSet, and is keyed under the SHA256 of"
+"\n"
+"the contained RouterIdentity.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:629
+msgid ""
+"RouterIdentity followed by the Date, when the entry was published\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:710
+msgid ""
+"The peer_size Integer may be followed by a list of that many router "
+"hashes.\n"
+"This is currently unused. It was intended for a form of restricted "
+"routes, which is unimplemented.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:715
+msgid ""
+"The signature may be verified using the signing public key of the "
+"router_ident.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:723
+#, python-format
+msgid ""
+"Defined in the Tunnel Message "
+"Specification.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:2
+msgid "Configuration File Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:7
+msgid ""
+"This page provides a general specification of I2P configuration files,\n"
+"used by the router and various applications.\n"
+"It also gives an overview of the information contained in the various "
+"files,\n"
+"and links to detailed documentation where available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:15
+msgid "General Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:16
+#, python-format
+msgid ""
+"An I2P configuration file is formatted as specified in\n"
+"Java Properties\n"
+"with the following exceptions:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:22
+msgid "Encoding must be UTF-8"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:23
+msgid ""
+"Does not use or recognize any escapes, including '\\', so lines may not "
+"be continued"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:24
+msgid "'#' or ';' starts a comment, but '!' does not"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:25
+msgid ""
+"'#' starts a comment in any position but ';' must be in column 1 to start"
+" a comment"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:26
+msgid "Leading and trailing whitespace is not trimmed on keys"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:27
+msgid "Leading and trailing whitespace is trimmed on values"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:28
+msgid "'=' is the only key-termination character (not ':' or whitespace)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:29
+msgid ""
+"Lines without '=' are ignored. It does not store the key with a value of "
+"\"\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:30
+msgid ""
+"As there are no escapes, keys may not contain '#', '=', or '\n"
+"', or start with ';'"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:31
+msgid ""
+"As there are no escapes, values may not contain '#' or '\n"
+"', or start or end with '\r"
+"' or whitespace"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:34
+msgid ""
+"The file need not be sorted, but most applications do sort by key when\n"
+"writing to the file, for ease of reading and manual editing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:39
+#, python-format
+msgid ""
+"Reads and writes are implemented in\n"
+"DataHelper loadProps() and storeProps().\n"
+"Note that the file format is significantly different than the\n"
+"serialized format for I2P protocols specified in\n"
+"Mapping."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:48
+msgid "Core library and router"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:50
+msgid "Clients"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:51
+msgid "Configured via /configclients in the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:55
+msgid "Logger"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:56
+msgid "Configured via /configlogging in the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:60
+msgid "Individual Plugin"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:61
+#, python-format
+msgid "See the plugin specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:66
+msgid "Enable/disable for each installed plugin."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:71
+msgid "Configured via /configadvanced in the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:78
+msgid "See documentation in SusiDNS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:83
+msgid "Configured via the application gui."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:88
+msgid "Configured via the /i2ptunnel application in the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:92
+msgid "Router Console"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:93
+msgid "The router console uses the router.config file."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:98
+msgid "See post on zzz.i2p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:2
+msgid "Datagram Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:6
+msgid "See the Datagrams page for an overview of the Datagrams API."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:12
+msgid "Non-Repliable Datagrams"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:13
+msgid ""
+"Non-repliable datagrams have no 'from' address and are not authenticated."
+"\n"
+"They are also called \"raw\" datagrams.\n"
+"Strictly speaking, they are not \"datagrams\" at all, they are just raw "
+"data.\n"
+"They are not handled by the datagram API.\n"
+"However, SAM and the I2PTunnel classes support \"raw datagrams\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:21
+msgid "Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:32
+#, python-format
+msgid ""
+"The practical length is limited by lower layers of protocols - the\n"
+"tunnel message spec\n"
+"limits messages to about 61.2 KB and the\n"
+"transports\n"
+"currently limit messages to about 32 KB, although this may be raised in "
+"the future."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:41
+msgid "Repliable Datagrams"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:42
+msgid ""
+"Repliable datagrams contain a 'from' address and a signature. These add "
+"427 bytes of overhead."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:91
+#, python-format
+msgid ""
+"The practical length is limited by lower layers of protocols - the\n"
+"transports\n"
+"currently limit messages to about 32 KB, so the data length here is "
+"limited to about\n"
+"31.5 KB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:2
+msgid "Streaming Library Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:6
+msgid "See the Streaming page for an overview of the Streaming Library."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:11
+msgid "Packet Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:12
+msgid "The format of a single packet in the streaming protocol is:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:35
+msgid "Length"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:83
+msgid "Flags and Option Data Fields"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:84
+msgid ""
+"The flags field above specifies some metadata about the packet, and in\n"
+"turn may require certain additional data to be included.  The flags are\n"
+"as follows. Any data structures specified must be added to the options "
+"area\n"
+"in the given order."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:2
+msgid "I2P Software Update Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:3
+msgid "November 2011"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:7
+msgid ""
+"I2P uses a simple, yet secure, system for automated software update.\n"
+"The router console periodically pulls a news file from a configurable I2P"
+" URL.\n"
+"There is a hardcoded backup URL pointing to the project website, in case\n"
+"the default project news host goes down."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:14
+msgid ""
+"The contents of the news file are displayed on the home page of the "
+"router console.\n"
+"In addition, the news file contains the most recent version number of the"
+" software.\n"
+"If the version is higher than the router's version number, it will\n"
+"display an indication to the user that an update is available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:21
+msgid ""
+"The router may optionally download, or download and install, the new "
+"version\n"
+"if configured to do so."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:26
+msgid "News File Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:27
+msgid "The news.xml file may contain the following elements:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:35
+msgid ""
+"The elements may be included inside XML comments to prevent "
+"interpretation by browsers.\n"
+"The i2p.release element and version are required. All others are optional"
+" and are\n"
+"currently unused."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:41
+msgid ""
+"The news source is trusted only to indicate that a new version is "
+"available.\n"
+"It does not specify the URL of the update, the checksum, or any other "
+"information."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:47
+msgid "Update File Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:48
+msgid ""
+"The signed update file, traditionally named i2pupdate.sud,\n"
+"is simply a zip file with a prepended 56 byte header.\n"
+"The header contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:54
+#, python-format
+msgid ""
+"A 40-byte DSA "
+"signature"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:57
+msgid "A 16-byte I2P version in UTF-8, padded with trailing zeroes if necessary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:62
+#, python-format
+msgid ""
+"The signature covers only the zip archive - not the prepended version.\n"
+"The signature must match one of the DSA public keys "
+"configured into the router,\n"
+"which has a hardcoded default list of keys of the current project release"
+" managers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:68
+msgid ""
+"For version comparison purposes, version fields contain [0-9]*, field "
+"separators are\n"
+"'-', '_', and '.', and all other characters are ignored."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:73
+msgid ""
+"As of version 0.8.8, the version must also be specified as a zip file "
+"comment in UTF-8,\n"
+"without the trailing zeroes.\n"
+"The updating router verifes that the version in the header (not covered "
+"by the signature)\n"
+"matches the version in the zip file comment, which is covered by the "
+"signature.\n"
+"This prevents spoofing of the version number in the header."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:81
+msgid "Download and Installation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:82
+msgid ""
+"The router first downloads the header of the update file from one in a "
+"configurable list of I2P URLs,\n"
+"using the built-in HTTP client and proxy,\n"
+"and checks that the version is newer.\n"
+"This prevents the problem of update hosts that do not have the latest "
+"file.\n"
+"The router then downloads the full update file.\n"
+"The router verifies that the update file version is newer before "
+"installation.\n"
+"It also, of course, verifies the signature, and\n"
+"verifes that the zip file comment matches the header version, as "
+"explained above."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:93
+msgid "The zip file is extracted in the base $I2P installation directory."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:97
+msgid ""
+"As of release 0.7.12, the router supports Pack200 decompression.\n"
+"Files inside the zip archive with a .jar.pack or .war.pack suffix\n"
+"are transparently decompressed to a .jar or .war file.\n"
+"Update files containing .pack files are traditionally named with a '.su2'"
+" suffix.\n"
+"Pack200 shrinks the update files by about 60%."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:105
+msgid ""
+"As of release 0.8.7, the router will delete the libjbigi.so and "
+"libjcpuid.so files\n"
+"if the zip archive contains a lib/jbigi.jar file, so that the new files "
+"will\n"
+"be extracted from jbigi.jar."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:111
+msgid ""
+"As of release 0.8.12, if the zip archive contains a file deletelist.txt, "
+"the router will\n"
+"delete the files listed there. The format is:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:116
+msgid "One file name per line"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:117
+msgid ""
+"All file names are relative to the installation directory; no absolute "
+"file names allowed, no files starting with \"..\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:118
+msgid "Comments start with '#'"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:121
+msgid "The router will then delete the deletelist.txt file."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:128
+msgid ""
+"When a new update file specification is defined, it should use a larger\n"
+"DSA signature, and the signature should cover the version.\n"
+"A file format version number might be a good idea too."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:133
+msgid ""
+"The network will eventually grow too large for update over HTTP.\n"
+"The built-in BitTorrent client, i2psnark, may be used as a distributed "
+"update method.\n"
+"This development effort was started in 2009 but is on hold until it is "
+"required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:138
+msgid ""
+"The router update mechanism is part of the web router console.\n"
+"There is currently no provision for updates of an embedded router lacking"
+" the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:2
+msgid "Transport Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:6
+msgid "Transports in I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:8
+msgid ""
+"A \"transport\" in I2P is a method for direct, point-to-point "
+"communication\n"
+"between two routers.\n"
+"Transports must provide confidentiality and integrity \n"
+"against external adversaries while authenticating that the router "
+"contacted \n"
+"is the one who should receive a given message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:16
+msgid ""
+"I2P supports multiple transports simultaneously.\n"
+"There are two transports currently implemented:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:21
+#, python-format
+msgid "NTCP, a Java New I/O (NIO) TCP transport"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:22
+#, python-format
+msgid " SSU, or Secure Semireliable UDP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:25
+msgid ""
+"Each provides a \"connection\" paradigm, with authentication,\n"
+"flow control, acknowledgments and retransmission."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:31
+msgid "Transport Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:33
+msgid "The transport subsystem in I2P provides the following services:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:37
+msgid ""
+"Maintain a set of router addresses, one or more for each transport,\n"
+"that the router publishes as its global contact information (the "
+"RouterInfo)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:41
+msgid "Selection of the best transport for each outgoing message"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:42
+msgid "Queueing of outbound messages by priority"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:43
+msgid ""
+"Bandwidth limiting, both outbound and inbound, according to router "
+"configuration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:44
+msgid "Setup and teardown of transport connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:45
+msgid "Encryption of point-to-point communications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:46
+msgid ""
+"Maintenance of connection limits for each transport, implementation of "
+"various thresholds for these limits,\n"
+"and communication of threshold status to the router so it may make "
+"operational changes based on the status"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:50
+msgid "Firewall port opening using UPnP (Universal Plug and Play)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:51
+msgid "Cooperative NAT/Firewall traversal"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:52
+msgid ""
+"Local IP detection by various methods, including UPnP, inspection of "
+"incoming connections, and enumeration of network devices"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:53
+msgid ""
+"Coordination of firewall status and local IP, and changes to either, "
+"among the transports"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:54
+#: i2p2www/pages/site/docs/transport/ssu.html:30
+msgid ""
+"Communication of firewall status and local IP, and changes to either, to "
+"the router and the user interface"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:55
+msgid ""
+"Determination of a consensus clock, which is used to periodically update "
+"the router's clock, as a backup for NTP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:56
+msgid ""
+"Maintenance of status for each peer, including whether it is connected, "
+"whether it was recently connected,\n"
+"and whether it was reachable in the last attempt"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:60
+msgid "Qualification of valid IP addresses according to a local rule set"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:61
+msgid ""
+"Honoring the automated and manual lists of banned peers maintained by the"
+" router,\n"
+"and refusing outbound and inbound connections to those peers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:68
+msgid "Transport Addresses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:70
+msgid ""
+"The transport subsystem maintains a set of router addresses, each of "
+"which lists a transport method, IP, and port.\n"
+"These addresses constitute the advertised contact points, and are "
+"published by the router to the network database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:75
+msgid "Typical scenarios are:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:77
+msgid ""
+"A router has no published addresses, so it is considered \"hidden\" and "
+"cannot receive incoming connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:78
+#, python-format
+msgid ""
+"A router is firewalled, and therefore publishes an SSU address which "
+"contains a list of cooperating\n"
+"peers or \"introducers\" who will assist in NAT traversal (see the SSU spec for details)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:82
+msgid ""
+"A router is not firewalled or its NAT ports  are open; it publishes both "
+"NTCP and SSU addresses containing\n"
+"directly-accessible IP and ports."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:88
+msgid "Transport Selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:90
+#, python-format
+msgid ""
+"The transport system delivers I2NP messages. The"
+" transport selected for any message is\n"
+"independent of the application-layer protocol (TCP or UDP)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:95
+msgid ""
+"For each outgoing message, the transport system solicits \"bids\" from "
+"each transport.\n"
+"The transport bidding the lowest (best) value wins the bid and receives "
+"the message for delivery.\n"
+"A transport may refuse to bid."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:101
+msgid "Whether a transport bids, and with what value, depend on numerous factors:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:105
+msgid "Configuration of transport preferences"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:106
+msgid "Whether the transport is already connected to the peer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:107
+msgid ""
+"The number of current connections compared to various connection limit "
+"thresholds"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:108
+msgid "Whether recent connection attempts to the peer have failed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:109
+msgid ""
+"The size of the message, as different transports have different size "
+"limits"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:110
+msgid ""
+"Whether the peer can accept incoming connections for that transport, as "
+"advertised in its RouterInfo"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:111
+msgid "Whether the connection would be indirect (requiring introducers) or direct"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:112
+msgid "The peer's transport preference, as advertised in its RouterInfo"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:115
+msgid ""
+"In general, the bid values are selected so that two routers are only "
+"connected by a single transport\n"
+"at any one time. However, this is not a requirement."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:122
+msgid "New Transports and Future Work"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:124
+msgid "Additional transports may be developed, including:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:129
+msgid "A TLS/SSH look-alike transport"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:130
+msgid ""
+"An \"indirect\" transport for routers that are not reachable by all other"
+" routers (one form of \"restricted routes\")"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:133
+msgid ""
+"Also, the existing transports will be enhanced to support multiple "
+"addresses within a single transport,\n"
+"including IPV6 addresses. Currently, a transport may only advertise a "
+"single IPV4 address."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:138
+msgid ""
+"Work continues on adjusting default connection limits for each transport."
+"\n"
+"I2P is designed as a \"mesh network\", where it is assumed that any "
+"router can connect to any other router.\n"
+"This assumption may be broken by routers that have exceeded their "
+"connection limits, and by\n"
+"routers that are behind restrictive state firewalls (restricted routes)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:145
+msgid ""
+"The current connection limits are higher for SSU than for NTCP, based on "
+"the assumption that\n"
+"the memory requirements for an NTCP connection are higher than that for "
+"SSU.\n"
+"However, as NTCP buffers are partially in the kernel and SSU buffers are "
+"on the Java heap,\n"
+"that assumption is difficult to verify."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:152
+#, python-format
+msgid ""
+"Analyze Breaking and Improving Protocol "
+"Obfuscation\n"
+"and see how transport-layer padding may improve things."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:6
+msgid "NTCP (NIO-based TCP)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:8
+#, python-format
+msgid ""
+"NTCP is one of two transports currently "
+"implemented in I2P.\n"
+"The other is SSU.\n"
+"NTCP is a Java NIO-based transport introduced in I2P release 0.6.1.22.\n"
+"Java NIO (new I/O) does not suffer from the 1 thread per connection "
+"issues of the old TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:15
+msgid ""
+"By default, NTCP uses the IP/Port\n"
+"auto-detected by SSU. When enabled on config.jsp,\n"
+"SSU will notify/restart NTCP when the external address changes\n"
+"or when the firewall status changes.\n"
+"Now you can enable inbound TCP without a static IP or dyndns service."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:23
+msgid ""
+"The NTCP code within I2P is relatively lightweight (1/4 the size of the "
+"SSU code)\n"
+"because it uses the underlying Java TCP transport for reliable delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:29
+msgid "NTCP Protocol Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:31
+msgid "Standard Message Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:32
+msgid ""
+"After establishment,\n"
+"the NTCP transport sends individual I2NP messages, with a simple "
+"checksum.\n"
+"The unencrypted message is encoded as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:42
+msgid ""
+"The data is then AES/256/CBC encrypted. The session key for the "
+"encryption\n"
+"is negotiated during establishment (using Diffie-Hellman 2048 bit).\n"
+"The establishment between two routers is implemented in the "
+"EstablishState class\n"
+"and detailed below.\n"
+"The IV for AES/256/CBC encryption is the last 16 bytes of the previous "
+"encrypted message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:50
+msgid ""
+"0-15 bytes of padding are required to bring the total message length\n"
+"(including the six size and checksum bytes) to a multiple of 16.\n"
+"The maximum message size is currently 16 KB.\n"
+"Therefore the maximum data size is currently 16 KB - 6, or 16378 bytes.\n"
+"The minimum data size is 1."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:58
+msgid "Time Sync Message Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:59
+msgid ""
+"One special case is a metadata message where the sizeof(data) is 0.  In\n"
+"that case, the unencrypted message is encoded as:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:70
+msgid ""
+"Total length: 16 bytes. The time sync message is sent at approximately 15"
+" minute intervals.\n"
+"The message is encrypted just as standard messages are."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:76
+#, fuzzy
+msgid "Checksums"
+msgstr "Sumas de comprobación SHA256:"
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:77
+#, python-format
+msgid ""
+"The standard and time sync messages use the Adler-32 checksum\n"
+"as defined in the ZLIB Specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:83
+msgid "Establishment Sequence"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:84
+msgid ""
+"In the establish state, there is a 4-phase message sequence to exchange "
+"DH keys and signatures.\n"
+"In the first two messages there is a 2048-bit Diffie Hellman exchange.\n"
+"Then, DSA signatures of the critical data are exchanged to confirm the "
+"connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:100
+msgid "Legend:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:101
+msgid "256 byte DH public keys"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:105
+msgid "timestamps (4 bytes, seconds since epoch)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:106
+msgid "32 byte Session key"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:107
+msgid "2 byte size of Alice identity to follow"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:110
+msgid "DH Key Exchange"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:111
+#, python-format
+msgid ""
+"The initial 2048-bit DH key exchange\n"
+"uses the same shared prime (p) and generator (g) as that used for I2P's\n"
+"ElGamal encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:117
+msgid ""
+"The DH key exchange consists of a number of steps, displayed below.\n"
+"The mapping between these steps and the messages sent between I2P "
+"routers,\n"
+"is marked in bold."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:123
+msgid ""
+"Alice generates a secret 226-bit integer x. She then calculates X ="
+" g^x mod p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:124
+msgid "Alice sends X to Bob (Message 1)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:125
+msgid ""
+"Bob generates a secret 226-bit integer y. He then calculates Y = "
+"g^y mod p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:126
+msgid "Bob sends Y to Alice.(Message 2)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:127
+msgid "Alice can now compute sessionKey = Y^x mod p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:128
+msgid "Bob can now compute sessionKey = X^y mod p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:129
+msgid ""
+"Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod "
+"p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:131
+msgid ""
+"The sessionKey is then used to exchange identities in Message 3 "
+"and Message 4."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:135
+msgid "Message 1 (Session Request)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:136
+#, python-format
+msgid ""
+"This is the DH request. Alice already has Bob's\n"
+"Router "
+"Identity,\n"
+"IP address, and port, as contained in his\n"
+"Router Info,\n"
+"which was published to the\n"
+"network database.\n"
+"Alice sends Bob:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:149
+#: i2p2www/pages/site/docs/transport/ntcp.html:192
+#: i2p2www/pages/site/docs/transport/ntcp.html:272
+#: i2p2www/pages/site/docs/transport/ntcp.html:355
+msgid "Size:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:151
+msgid "Contents:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:169
+msgid "256 byte X from Diffie Hellman"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:171
+#, python-format
+msgid ""
+"SHA256 Hash(X) xored with SHA256 Hash(Bob's Router Identity)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:178
+#: i2p2www/pages/site/docs/transport/ntcp.html:259
+#: i2p2www/pages/site/docs/transport/ntcp.html:336
+msgid "Notes:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:179
+msgid ""
+"Bob verifies HXxorHI using his own router hash. If it does not verify,\n"
+"Alice has contacted the wrong router, and Bob drops the connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:185
+msgid "Message 2 (Session Created)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:186
+msgid "This is the DH reply. Bob sends Alice:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:194
+#: i2p2www/pages/site/docs/transport/ntcp.html:274
+#: i2p2www/pages/site/docs/transport/ntcp.html:357
+msgid "Unencrypted Contents:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:216
+#: i2p2www/pages/site/docs/transport/ntcp.html:250
+msgid "256 byte Y from Diffie Hellman"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:218
+msgid "SHA256 Hash(X concatenated with Y)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:221
+#: i2p2www/pages/site/docs/transport/ntcp.html:306
+msgid "4 byte timestamp (seconds since the epoch)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:223
+msgid "12 bytes random data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:228
+#: i2p2www/pages/site/docs/transport/ntcp.html:318
+#: i2p2www/pages/site/docs/transport/ntcp.html:385
+msgid "Encrypted Contents:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:252
+#, python-format
+msgid ""
+"48 bytes AES encrypted using the DH "
+"session key and\n"
+"                  the last 16 bytes of Y as the IV"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:260
+msgid ""
+"Alice may drop the connection if the clock skew with Bob is too high as "
+"calculated using tsB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:265
+msgid "Message 3 (Session Confirm A)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:266
+msgid ""
+"This contains Alice's router identity, and a DSA signature of the "
+"critical data. Alice sends Bob:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:300
+msgid "2 byte size of Alice's router identity to follow (should always be 387)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:302
+#, python-format
+msgid ""
+"Alice's 387 byte Router Identity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:308
+msgid "15 bytes random data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:310
+#, python-format
+msgid ""
+"the 40 byte DSA "
+"signature of the following concatenated data:\n"
+"             X, Y, Bob's Router Identity, "
+"tsA, tsB.\n"
+"             Alice signs it with the private signing "
+"key associated with the public signing "
+"key in her Router Identity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:328
+#, python-format
+msgid ""
+"448 bytes AES encrypted using the DH"
+" session key and\n"
+"                  the last 16 bytes of HXxorHI (i.e., the last 16 bytes "
+"of message #1) as the IV"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:338
+msgid "Bob verifies the signature, and on failure, drops the connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:341
+msgid ""
+"Bob may drop the connection if the clock skew with Alice is too high as "
+"calculated using tsA."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:348
+msgid "Message 4 (Session Confirm B)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:349
+msgid "This is a DSA signature of the critical data. Bob sends Alice:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:374
+#, python-format
+msgid ""
+"the 40 byte DSA "
+"signature of the following concatenated data:\n"
+"             X, Y, Alice's Router Identity, "
+"tsA, tsB.\n"
+"             Bob signs it with the private signing "
+"key associated with the public signing "
+"key in his Router Identity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:380
+msgid "8 bytes random data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:395
+#, python-format
+msgid ""
+"48 bytes AES encrypted using the DH "
+"session key and\n"
+"                  the last 16 bytes of the encrypted contents of message "
+"#2 as the IV"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:403
+msgid "Alice verifies the signature, and on failure, drops the connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:410
+msgid "After Establishment"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:411
+msgid ""
+"The connection is established, and standard or time sync messages may be "
+"exchanged.\n"
+"All subsequent messages are AES encrypted using the negotiated DH session"
+" key.\n"
+"Alice will use the last 16 bytes of the encrypted contents of message #3 "
+"as the next IV.\n"
+"Bob will use the last 16 bytes of the encrypted contents of message #4 as"
+" the next IV."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:420
+msgid "Check Connection Message"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:421
+msgid ""
+"Alternately, when Bob receives a connection, it could be a\n"
+"check connection (perhaps prompted by Bob asking for someone\n"
+"to verify his listener).\n"
+"Check Connection is not currently used.\n"
+"However, for the record, check connections are formatted as follows.\n"
+"A check info connection will receive 256 bytes containing:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:430
+msgid "32 bytes of uninterpreted, ignored data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:431
+msgid "1 byte size"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:432
+msgid ""
+"that many bytes making up the local router's IP address (as reached by "
+"the remote side)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:433
+msgid "2 byte port number that the local router was reached on"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:434
+msgid ""
+"4 byte i2p network time as known by the remote side (seconds since the "
+"epoch)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:435
+msgid "uninterpreted padding data, up to byte 223"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:436
+msgid ""
+"xor of the local router's identity hash and the SHA256 of bytes 32 "
+"through bytes 223"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:440
+msgid "Discussion"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:441
+#, python-format
+msgid "Now on the NTCP Discussion Page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:447
+msgid "The maximum message size should be increased to approximately 32 KB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:451
+msgid ""
+"A set of fixed packet sizes may be appropriate to further hide the data \n"
+"fragmentation to external adversaries, but the tunnel, garlic, and end to"
+" \n"
+"end padding should be sufficient for most needs until then.\n"
+"However, there is currently no provision for padding beyond the next "
+"16-byte boundary,\n"
+"to create a limited number of message sizes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:459
+msgid ""
+"Memory utilization (including that of the kernel) for NTCP should be "
+"compared to that for SSU."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:463
+msgid ""
+"Can the establishment messages be randomly padded somehow, to frustrate\n"
+"identification of I2P traffic based on initial packet sizes?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:468
+msgid "Review and possibly disable 'check connection'"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:2
+msgid "SSU Transport"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:3
+msgid "October 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:6
+msgid "Secure Semireliable UDP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:7
+#, python-format
+msgid ""
+"SSU (also called \"UDP\" in much of the I2P documentation and user "
+"interfaces)\n"
+"is one of two transports currently "
+"implemented in I2P.\n"
+"The other is NTCP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:13
+msgid ""
+"SSU is the newer of the two transports,\n"
+"introduced in I2P release 0.6.\n"
+"In a standard I2P installation, the router uses both NTCP and SSU for "
+"outbound connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:19
+msgid "SSU Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:21
+msgid ""
+"Like the NTCP transport, SSU provides reliable, encrypted, connection-"
+"oriented, point-to-point data transport.\n"
+"Unique to SSU, it also provides IP detection and NAT traversal services, "
+"including:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:27
+msgid ""
+"Cooperative NAT/Firewall traversal using introducers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:28
+msgid ""
+"Local IP detection by inspection of incoming packets and peer testing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:29
+msgid ""
+"Communication of firewall status and local IP, and changes to either to "
+"NTCP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:34
+msgid "Protocol Details"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:36
+msgid "Congestion control"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:38
+msgid ""
+"SSU's need for only semireliable delivery, TCP-friendly operation,\n"
+"and the capacity for high throughput allows a great deal of latitude in\n"
+"congestion control.  The congestion control algorithm outlined below is\n"
+"meant to be both efficient in bandwidth as well as simple to implement."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:45
+msgid ""
+"Packets are scheduled according to the router's policy, taking care\n"
+"not to exceed the router's outbound capacity or to exceed the measured \n"
+"capacity of the remote peer.  The measured capacity operates along the\n"
+"lines of TCP's slow start and congestion avoidance, with additive "
+"increases\n"
+"to the sending capacity and multiplicative decreases in face of "
+"congestion.\n"
+"Unlike for TCP, routers may give up on some messages after\n"
+"a given period or number of retransmissions while continuing to transmit"
+" \n"
+"other messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:56
+msgid ""
+"The congestion detection techniques vary from TCP as well, since each \n"
+"message has its own unique and nonsequential identifier, and each message"
+"\n"
+"has a limited size - at most, 32KB.  To efficiently transmit this "
+"feedback\n"
+"to the sender, the receiver periodically includes a list of fully ACKed \n"
+"message identifiers and may also include bitfields for partially received"
+"\n"
+"messages, where each bit represents the reception of a fragment.  If \n"
+"duplicate fragments arrive, the message should be ACKed again, or if the\n"
+"message has still not been fully received, the bitfield should be \n"
+"retransmitted with any new updates."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:68
+msgid ""
+"The current implementation does not pad the packets to\n"
+"any particular size, but instead just places a single message fragment "
+"into\n"
+"a packet and sends it off (careful not to exceed the MTU)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:75
+msgid ""
+"As of router version 0.8.12,\n"
+"two MTU values are used: 620 and 1484.\n"
+"The MTU value is adjusted based on the percentage of packets that are "
+"retransmitted."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:81
+msgid ""
+"For both MTU values, it is desirable that (MTU % 16) == 12, so that\n"
+"the payload portion after the 28-byte IP/UDP header is a multiple of\n"
+"16 bytes, for encryption purposes.\n"
+"This calculation is for IPv4 only. While the protocol as specified "
+"supports IPv6\n"
+"addresses, IPv6 is not yet implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:89
+msgid ""
+"For the small MTU value, it is desirable to pack a 2646-byte\n"
+"Variable Tunnel Build Message efficiently into multiple packets;\n"
+"with a 620-byte MTU, it fits into 5 packets with nicely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:95
+msgid ""
+"Based on measurements, 1492 fits nearly all reasonably small I2NP "
+"messages\n"
+"(larger I2NP messages may be up to 1900 to 4500 bytes, which isn't going "
+"to fit\n"
+"into a live network MTU anyway)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:101
+msgid ""
+"The MTU values were 608 and 1492 for releases 0.8.9 - 0.8.11.\n"
+"The large MTU was 1350 prior to release 0.8.9."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:106
+msgid ""
+"The maximum receive packet size\n"
+"is 1571 bytes as of release 0.8.12.\n"
+"For releases 0.8.9 - 0.8.11 it was 1535 bytes.\n"
+"Prior to release 0.8.9 it was 2048 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:113
+msgid ""
+"As of release 0.9.2, if a router's network interface MTU is less than "
+"1484,\n"
+"it will publish that in the network database, and other routers should\n"
+"honor that when a connection is established."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:119
+msgid "Message Size Limits"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:120
+msgid ""
+"While the maximum message size is nominally 32KB, the practical\n"
+"limit differs. The protocol limits the number of fragments to 7 bits, or "
+"128.\n"
+"The current implementation, however, limits each message to a maximum of "
+"64 fragments,\n"
+"which is sufficient for 64 * 534 = 33.3 KB when using the 608 MTU.\n"
+"Due to overhead for bundled LeaseSets and session keys, the practical "
+"limit\n"
+"at the application level is about 6KB lower, or about 26KB.\n"
+"Further work is necessary to raise the UDP transport limit above 32KB.\n"
+"For connections using the larger MTU, larger messages are possible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:131
+msgid "Keys"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:133
+msgid ""
+"All encryption used is AES256/CBC with 32 byte keys and 16 byte IVs.\n"
+"The MAC and session keys are negotiated as part of the DH exchange, used\n"
+"for the HMAC and encryption, respectively.  Prior to the DH exchange, \n"
+"the publicly knowable introKey is used for the MAC and encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:140
+msgid ""
+"When using the introKey, both the initial message and any subsequent\n"
+"reply use the introKey of the responder (Bob) - the responder does \n"
+"not need to know the introKey of the requester (Alice).  The DSA \n"
+"signing key used by Bob should already be known to Alice when she \n"
+"contacts him, though Alice's DSA key may not already be known by \n"
+"Bob."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:149
+msgid ""
+"Upon receiving a message, the receiver checks the \"from\" IP address and"
+" port\n"
+"with all established sessions - if there are matches,\n"
+"that session's MAC keys are tested in the HMAC.  If none\n"
+"of those verify or if there are no matching IP addresses, the \n"
+"receiver tries their introKey in the MAC.  If that does not verify,\n"
+"the packet is dropped.  If it does verify, it is interpreted \n"
+"according to the message type, though if the receiver is overloaded,\n"
+"it may be dropped anyway."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:160
+msgid ""
+"If Alice and Bob have an established session, but Alice loses the \n"
+"keys for some reason and she wants to contact Bob, she may at any \n"
+"time simply establish a new session through the SessionRequest and\n"
+"related messages.  If Bob has lost the key but Alice does not know\n"
+"that, she will first attempt to prod him to reply, by sending a \n"
+"DataMessage with the wantReply flag set, and if Bob continually \n"
+"fails to reply, she will assume the key is lost and reestablish a \n"
+"new one."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:171
+#, python-format
+msgid ""
+"For the DH key agreement,\n"
+"RFC3526 2048bit\n"
+"MODP group (#14) is used:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:181
+#, python-format
+msgid ""
+"These are the same p and g used for I2P's\n"
+"ElGamal encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:186
+msgid "Replay prevention"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:188
+msgid ""
+"Replay prevention at the SSU layer occurs by rejecting packets \n"
+"with exceedingly old timestamps or those which reuse an IV.  To\n"
+"detect duplicate IVs, a sequence of Bloom filters are employed to\n"
+"\"decay\" periodically so that only recently added IVs are detected."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:195
+msgid ""
+"The messageIds used in DataMessages are defined at layers above\n"
+"the SSU transport and are passed through transparently.  These IDs\n"
+"are not in any particular order - in fact, they are likely to be\n"
+"entirely random.  The SSU layer makes no attempt at messageId \n"
+"replay prevention - higher layers should take that into account."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:203
+msgid "Addressing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:205
+msgid ""
+"To contact an SSU peer, one of two sets of information is necessary:\n"
+"a direct address, for when the peer is publicly reachable, or an\n"
+"indirect address, for using a third party to introduce the peer.\n"
+"There is no restriction on the number of addresses a peer may have."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:217
+msgid ""
+"Each of the addresses may also expose a series of options - special\n"
+"capabilities of that particular peer.  For a list of available\n"
+"capabilities, see below."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:223
+#, python-format
+msgid ""
+"The addresses, options, and capabilities are published in the network database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:228
+msgid "Direct Session Establishment"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:229
+msgid ""
+"Direct session establishment is used when no third party is required for "
+"NAT traversal.\n"
+"The message sequence is as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:234
+msgid "Connection establishment (direct)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:235
+msgid "Alice connects directly to Bob."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:249
+#, python-format
+msgid ""
+"After the SessionConfirmed message is received, Bob sends a small\n"
+"DeliveryStatus message\n"
+"as a confirmation.\n"
+"In this message, the 4-byte message ID is set to a random number, and the"
+"\n"
+"8-byte \"arrival time\" is set to the current network-wide ID, which is 2"
+"\n"
+"(i.e. 0x0000000000000002)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:258
+#, python-format
+msgid ""
+"After the status message is sent, the peers exchange\n"
+"DatabaseStore messages\n"
+"containing their\n"
+"RouterInfos."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:266
+msgid ""
+"It does not appear that the type of the status message or its contents "
+"matters.\n"
+"It was originally added becasue the DatabaseStore message was delayed\n"
+"several seconds; since the store is now sent immediately, perhaps\n"
+"the status message can be eliminated."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:275
+msgid ""
+"Introduction keys are delivered through an external channel \n"
+"(the network database, where they are identical to the router Hash for "
+"now)\n"
+"and must be used when establishing a session key.  For the indirect\n"
+"address, the peer must first contact the relayhost and ask them for\n"
+"an introduction to the peer known at that relayhost under the given\n"
+"tag.  If possible, the relayhost sends a message to the addressed\n"
+"peer telling them to contact the requesting peer, and also gives \n"
+"the requesting peer the IP and port on which the addressed peer is\n"
+"located.  In addition, the peer establishing the connection must \n"
+"already know the public keys of the peer they are connecting to (but\n"
+"not necessary to any intermediary relay peer)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:289
+msgid ""
+"Indirect session establishment by means of a third party introduction\n"
+"is necessary for efficient NAT traversal.  Charlie, a router behind a\n"
+"NAT or firewall which does not allow unsolicited inbound UDP packets,\n"
+"first contacts a few peers, choosing some to serve as introducers.  Each\n"
+"of these peers (Bob, Bill, Betty, etc) provide Charlie with an "
+"introduction\n"
+"tag - a 4 byte random number - which he then makes available to the "
+"public\n"
+"as methods of contacting him.  Alice, a router who has Charlie's "
+"published\n"
+"contact methods, first sends a RelayRequest packet to one or more of the"
+" \n"
+"introducers, asking each to introduce her to Charlie (offering the \n"
+"introduction tag to identify Charlie).  Bob then forwards a RelayIntro\n"
+"packet to Charlie including Alice's public IP and port number, then sends"
+"\n"
+"Alice back a RelayResponse packet containing Charlie's public IP and port"
+"\n"
+"number.  When Charlie receives the RelayIntro packet, he sends off a "
+"small\n"
+"random packet to Alice's IP and port (poking a hole in his NAT/firewall),"
+"\n"
+"and when Alice receives Bob's RelayResponse packet, she begins a new \n"
+"full direction session establishment with the specified IP and port."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:316
+msgid "Connection establishment (indirect using an introducer)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:318
+msgid "Alice first connects to introducer Bob, who relays the request to Charlie."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:336
+msgid ""
+"After the hole punch, the session is established between Alice and "
+"Charlie as in a direct establishment."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:341
+msgid "Peer testing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:343
+msgid ""
+"The automation of collaborative reachability testing for peers is\n"
+"enabled by a sequence of PeerTest messages.  With its proper \n"
+"execution, a peer will be able to determine their own reachability\n"
+"and may update its behavior accordingly.  The testing process is \n"
+"quite simple:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:362
+msgid ""
+"Each of the PeerTest messages carry a nonce identifying the\n"
+"test series itself, as initialized by Alice.  If Alice doesn't \n"
+"get a particular message that she expects, she will retransmit\n"
+"accordingly, and based upon the data received or the messages\n"
+"missing, she will know her reachability.  The various end states\n"
+"that may be reached are as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:372
+msgid ""
+"If she doesn't receive a response from Bob, she will retransmit\n"
+"up to a certain number of times, but if no response ever arrives,\n"
+"she will know that her firewall or NAT is somehow misconfigured, \n"
+"rejecting all inbound UDP packets even in direct response to an\n"
+"outbound packet.  Alternately, Bob may be down or unable to get \n"
+"Charlie to reply."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:381
+msgid ""
+"If Alice doesn't receive a PeerTest message with the \n"
+"expected nonce from a third party (Charlie), she will retransmit\n"
+"her initial request to Bob up to a certain number of times, even\n"
+"if she has received Bob's reply already.  If Charlie's first message \n"
+"still doesn't get through but Bob's does, she knows that she is\n"
+"behind a NAT or firewall that is rejecting unsolicited connection\n"
+"attempts and that port forwarding is not operating properly (the\n"
+"IP and port that Bob offered up should be forwarded)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:392
+msgid ""
+"If Alice receives Bob's PeerTest message and both of Charlie's\n"
+"PeerTest messages but the enclosed IP and port numbers in Bob's \n"
+"and Charlie's second messages don't match, she knows that she is \n"
+"behind a symmetric NAT, rewriting all of her outbound packets with\n"
+"different 'from' ports for each peer contacted.  She will need to\n"
+"explicitly forward a port and always have that port exposed for \n"
+"remote connectivity, ignoring further port discovery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:402
+msgid ""
+"If Alice receives Charlie's first message but not his second,\n"
+"she will retransmit her PeerTest message to Charlie up to a \n"
+"certain number of times, but if no response is received she knows\n"
+"that Charlie is either confused or no longer online."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:410
+msgid ""
+"Alice should choose Bob arbitrarily from known peers who seem\n"
+"to be capable of participating in peer tests.  Bob in turn should\n"
+"choose Charlie arbitrarily from peers that he knows who seem to be\n"
+"capable of participating in peer tests and who are on a different\n"
+"IP from both Bob and Alice.  If the first error condition occurs\n"
+"(Alice doesn't get PeerTest messages from Bob), Alice may decide\n"
+"to designate a new peer as Bob and try again with a different nonce."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:420
+msgid ""
+"Alice's introduction key is included in all of the PeerTest \n"
+"messages so that she doesn't need to already have an established\n"
+"session with Bob and so that Charlie can contact her without knowing\n"
+"any additional information.  Alice may go on to establish a session\n"
+"with either Bob or Charlie, but it is not required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:429
+msgid "Transmission window, ACKs and Retransmissions"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:430
+#, python-format
+msgid ""
+"The DATA message may contain ACKs of full messages and\n"
+"partial ACKs of individual fragments of a message. See\n"
+"the data message section of\n"
+"the protocol specification page\n"
+"for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:438
+#, python-format
+msgid ""
+"The details of windowing, ACK, and retransmission strategies are not "
+"specified\n"
+"here. See the Java code for the current implementation.\n"
+"During the establishment phase, and for peer testing, routers\n"
+"should implement exponential backoff for retransmission.\n"
+"For an established connection, routers should implement\n"
+"an adjustable transmission window, RTT estimate and timeout, similar to "
+"TCP\n"
+"or streaming.\n"
+"See the code for initial, min and max parameters."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:450
+msgid "Security"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:451
+msgid ""
+"UDP source addresses may, of course, be spoofed.\n"
+"Additionally, the IPs and ports contained inside specific\n"
+"SSU messages (RelayRequest, RelayResponse, RelayIntro, PeerTest)\n"
+"may not be legitimate.\n"
+"Also, certain actions and responses may need to be rate-limited."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:459
+msgid ""
+"The details of validation are not specified\n"
+"here. Implementers should add defenses where appropriate."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:465
+msgid "Peer capabilities"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:469
+msgid ""
+"If the peer address contains the 'B' capability, that means \n"
+"they are willing and able to participate in peer tests as\n"
+"a 'Bob' or 'Charlie'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:475
+msgid ""
+"If the peer address contains the 'C' capability, that means\n"
+"they are willing and able to serve as an introducer - serving\n"
+"as a Bob for an otherwise unreachable Alice."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:484
+msgid ""
+"Analysis of current SSU performance, including assessment of window size "
+"adjustment\n"
+"and other parameters, and adjustment of the protocol implementation to "
+"improve\n"
+"performance, is a topic for future work."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:490
+msgid ""
+"The current implementation repeatedly sends acknowledgments for the same "
+"packets,\n"
+"which unnecessarily increases overhead."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:495
+msgid ""
+"The default small MTU value of 620 should be analyzed and possibly "
+"increased.\n"
+"The current MTU adjustment strategy should be evaluated.\n"
+"Does a streaming lib 1730-byte packet fit in 3 small SSU packets? "
+"Probably not."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:501
+msgid "The protocol should be extended to exchange MTUs during the setup."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:505
+msgid "Rekeying is currently unimplemented and may never be."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:509
+msgid ""
+"The potential use of the 'challenge' fields in RelayIntro and "
+"RelayResponse,\n"
+"and use of the padding field in SessionRequest and SessionCreated, is "
+"undocumented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:514
+msgid ""
+"Instead of a single fragment per packet, a more efficient\n"
+"strategy may be to bundle multiple message fragments into the same "
+"packet,\n"
+"so long as it doesn't exceed the MTU."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:520
+msgid ""
+"A set of fixed packet sizes may be appropriate to further hide the data \n"
+"fragmentation to external adversaries, but the tunnel, garlic, and end to"
+" \n"
+"end padding should be sufficient for most needs until then."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:526
+msgid ""
+"Why are introduction keys the same as the router hash, should it be "
+"changed, would there be any benefit?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:530
+msgid "Capacities appear to be unused."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:534
+msgid ""
+"Signed-on times in SessionCreated and SessionConfirmed appear to be "
+"unused or unverified."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:539
+msgid "Implementation Diagram"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:540
+msgid ""
+"This diagram\n"
+"should accurately reflect the current implementation, however there may "
+"be small differences."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:548
+msgid "Now on the SSU specification page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:2
+msgid "Tunnel Implementation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:3
+msgid "October 2010"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:7
+msgid "This page documents the current tunnel implementation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:9
+msgid "Tunnel overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:11
+msgid ""
+"Within I2P, messages are passed in one direction through a virtual\n"
+"tunnel of peers, using whatever means are available to pass the \n"
+"message on to the next hop.  Messages arrive at the tunnel's \n"
+"gateway, get bundled up and/or fragmented into fixed-size tunnel "
+"messages, \n"
+"and are forwarded on to the next hop in the tunnel, which processes and "
+"verifies\n"
+"the validity of the message and sends it on to the next hop, and so on, "
+"until\n"
+"it reaches the tunnel endpoint.  That endpoint takes the messages\n"
+"bundled up by the gateway and forwards them as instructed - either\n"
+"to another router, to another tunnel on another router, or locally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:23
+msgid ""
+"Tunnels all work the same, but can be segmented into two different\n"
+"groups - inbound tunnels and outbound tunnels.  The inbound tunnels\n"
+"have an untrusted gateway which passes messages down towards the \n"
+"tunnel creator, which serves as the tunnel endpoint.  For outbound \n"
+"tunnels, the tunnel creator serves as the gateway, passing messages\n"
+"out to the remote endpoint."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:32
+msgid ""
+"The tunnel's creator selects exactly which peers will participate\n"
+"in the tunnel, and provides each with the necessary configuration\n"
+"data.  They may have any number of hops.\n"
+"It is the intent to make\n"
+"it hard for either participants or third parties to determine the length "
+"of \n"
+"a tunnel, or even for colluding participants to determine whether they "
+"are a\n"
+"part of the same tunnel at all (barring the situation where colluding "
+"peers are\n"
+"next to each other in the tunnel)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:43
+msgid ""
+"In practice, a series of tunnel pools are used for different\n"
+"purposes - each local client destination has its own set of inbound\n"
+"tunnels and outbound tunnels, configured to meet its anonymity and\n"
+"performance needs.  In addition, the router itself maintains a series\n"
+"of pools for participating in the network database and for managing\n"
+"the tunnels themselves."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:52
+msgid ""
+"I2P is an inherently packet switched network, even with these \n"
+"tunnels, allowing it to take advantage of multiple tunnels running \n"
+"in parallel, increasing resilience and balancing load.  Outside of\n"
+"the core I2P layer, there is an optional end to end streaming library \n"
+"available for client applications, exposing TCP-esque operation,\n"
+"including message reordering, retransmission, congestion control, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:61
+#, python-format
+msgid ""
+"An overview of I2P tunnel terminology is\n"
+"on the tunnel overview page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:66
+msgid "Tunnel Operation (Message Processing)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:69
+#, python-format
+msgid ""
+"After a tunnel is built, I2NP messages are "
+"processed and passed through it.\n"
+"Tunnel operation has four distinct processes, taken on by various \n"
+"peers in the tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:75
+msgid ""
+"First, the tunnel gateway accumulates a number\n"
+"of I2NP messages and preprocesses them into tunnel messages for\n"
+"delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:80
+msgid ""
+"Next, that gateway encrypts that preprocessed data, then\n"
+"forwards it to the first hop."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:84
+msgid ""
+"That peer, and subsequent tunnel \n"
+"participants, unwrap a layer of the encryption, verifying that it isn't\n"
+"a duplicate, then forward it on to the next peer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:89
+msgid ""
+"Eventually, the tunnel messages arrive at the endpoint where the I2NP "
+"messages\n"
+"originally bundled by the gateway are reassembled and forwarded on as \n"
+"requested."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:96
+msgid ""
+"Intermediate tunnel participants do not know whether they are in an\n"
+"inbound or an outbound tunnel; they always \"encrypt\" for the next hop.\n"
+"Therefore, we take advantage of symmetric AES encryption\n"
+"to \"decrypt\" at the outbound tunnel gateway,\n"
+"so that the plaintext is revealed at the outbound endpoint."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:110
+msgid "Role"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:111
+msgid "Preprocessing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:112
+msgid "Encryption Operation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:113
+msgid "Postprocessing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:117
+msgid "Outbound Gateway (Creator)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:118
+#: i2p2www/pages/site/docs/tunnels/implementation.html:141
+msgid "Fragment, Batch, and Pad"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:119
+msgid "Iteratively encrypt (using decryption operations)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:120
+#: i2p2www/pages/site/docs/tunnels/implementation.html:127
+#: i2p2www/pages/site/docs/tunnels/implementation.html:143
+#: i2p2www/pages/site/docs/tunnels/implementation.html:150
+msgid "Forward to next hop"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:124
+#: i2p2www/pages/site/docs/tunnels/implementation.html:147
+msgid "Participant"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:126
+msgid "Decrypt (using an encryption operation)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:133
+msgid "Decrypt (using an encryption operation) to reveal plaintext tunnel message"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:134
+msgid "Reassemble Fragments, Forward as instructed to Inbound Gateway or Router"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:142
+#: i2p2www/pages/site/docs/tunnels/implementation.html:149
+msgid "Encrypt"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:154
+msgid "Inbound Endpoint (Creator)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:156
+msgid "Iteratively decrypt to reveal plaintext tunnel message"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:157
+msgid "Reassemble Fragments, Receive data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:163
+msgid "Gateway Processing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:164
+msgid "Message Preprocessing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:166
+#, python-format
+msgid ""
+"A tunnel gateway's function is to fragment and pack\n"
+"I2NP messages into fixed-size\n"
+"tunnel messages\n"
+"and encrypt the tunnel messages.\n"
+"Tunnel messages contain the following:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:174
+msgid "A 4 byte Tunnel ID"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:175
+msgid "A 16 byte IV (initialization vector)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:176
+msgid "A checksum"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:177
+msgid "Padding, if necessary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:178
+msgid "One or more { delivery instruction, I2NP message fragment } pairs"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:181
+msgid ""
+"Tunnel IDs are 4 byte numbers used at each hop - participants know what\n"
+"tunnel ID to listen for messages with and what tunnel ID they should be "
+"forwarded\n"
+"on as to the next hop, and each hop chooses the tunnel ID which they "
+"receive messages\n"
+"on.  Tunnels themselves are short-lived (10 minutes).\n"
+"Even if subsequent tunnels are built using the same sequence of \n"
+"peers, each hop's tunnel ID will change."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:190
+msgid ""
+"To prevent adversaries from tagging the messages along the path by "
+"adjusting\n"
+"the message size, all tunnel messages are a fixed 1024 bytes in size.  To"
+" accommodate \n"
+"larger I2NP messages as well as to support smaller ones more efficiently,"
+" the\n"
+"gateway splits up the larger I2NP messages into fragments contained "
+"within each\n"
+"tunnel message.  The endpoint will attempt to rebuild the I2NP message "
+"from the\n"
+"fragments for a short period of time, but will discard them as necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:199
+#, python-format
+msgid ""
+"Details are in the\n"
+"tunnel message specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:205
+msgid "Gateway Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:207
+msgid ""
+"After the preprocessing of messages into a padded payload, the gateway "
+"builds\n"
+"a random 16 byte IV value, iteratively encrypting it and the tunnel "
+"message as\n"
+"necessary, and forwards the tuple {tunnelID, IV, encrypted tunnel "
+"message} to the next hop."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:213
+msgid ""
+"How encryption at the gateway is done depends on whether the tunnel is an"
+"\n"
+"inbound or an outbound tunnel.  For inbound tunnels, they simply select a"
+" random\n"
+"IV, postprocessing and updating it to generate the IV for the gateway and"
+" using \n"
+"that IV along side their own layer key to encrypt the preprocessed data."
+"  For outbound \n"
+"tunnels they must iteratively decrypt the (unencrypted) IV and "
+"preprocessed \n"
+"data with the IV and layer keys for all hops in the tunnel.  The result "
+"of the outbound\n"
+"tunnel encryption is that when each peer encrypts it, the endpoint will "
+"recover \n"
+"the initial preprocessed data."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:225
+msgid "Participant Processing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:227
+msgid ""
+"When a peer receives a tunnel message, it checks that the message came "
+"from\n"
+"the same previous hop as before (initialized when the first message comes"
+" through\n"
+"the tunnel).  If the previous peer is a different router, or if the "
+"message has\n"
+"already been seen, the message is dropped.  The participant then encrypts"
+" the \n"
+"received IV with AES256/ECB using their IV key to determine the current "
+"IV, uses \n"
+"that IV with the participant's layer key to encrypt the data, encrypts "
+"the \n"
+"current IV with AES256/ECB using their IV key again, then forwards the "
+"tuple \n"
+"{nextTunnelId, nextIV, encryptedData} to the next hop.  This double "
+"encryption\n"
+"of the IV (both before and after use) help address a certain class of\n"
+"confirmation attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:240
+msgid ""
+"Duplicate message detection is handled by a decaying Bloom filter on "
+"message\n"
+"IVs.  Each router maintains a single Bloom filter to contain the XOR of "
+"the IV and\n"
+"the first block of the message received for all of the tunnels it is "
+"participating\n"
+"in, modified to drop seen entries after 10-20 minutes (when the tunnels "
+"will have\n"
+"expired).  The size of the bloom filter and the parameters used are "
+"sufficient to\n"
+"more than saturate the router's network connection with a negligible "
+"chance of \n"
+"false positive.  The unique value fed into the Bloom filter is the XOR of"
+" the IV \n"
+"and the first block so as to prevent nonsequential colluding peers in the"
+" tunnel \n"
+"from tagging a message by resending it with the IV and first block "
+"switched."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:253
+msgid "Endpoint Processing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:255
+msgid ""
+"After receiving and validating a tunnel message at the last hop in the "
+"tunnel,\n"
+"how the endpoint recovers the data encoded by the gateway depends upon "
+"whether \n"
+"the tunnel is an inbound or an outbound tunnel.  For outbound tunnels, "
+"the \n"
+"endpoint encrypts the message with its layer key just like any other "
+"participant, \n"
+"exposing the preprocessed data.  For inbound tunnels, the endpoint is "
+"also the \n"
+"tunnel creator so they can merely iteratively decrypt the IV and message,"
+" using the \n"
+"layer and IV keys of each step in reverse order."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:265
+msgid ""
+"At this point, the tunnel endpoint has the preprocessed data sent by the "
+"gateway,\n"
+"which it may then parse out into the included I2NP messages and forwards "
+"them as\n"
+"requested in their delivery instructions."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:272
+msgid "Tunnel Building"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:274
+msgid ""
+"When building a tunnel, the creator must send a request with the "
+"necessary\n"
+"configuration data to each of the hops and wait for all of them to agree "
+"before\n"
+"enabling the tunnel.  The requests are encrypted so that only the peers "
+"who need\n"
+"to know a piece of information (such as the tunnel layer or IV key) has "
+"that\n"
+"data.  In addition, only the tunnel creator will have access to the "
+"peer's\n"
+"reply.  There are three important dimensions to keep in mind when "
+"producing\n"
+"the tunnels: what peers are used (and where), how the requests are sent "
+"(and \n"
+"replies received), and how they are maintained."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:288
+msgid ""
+"Beyond the two types of tunnels - inbound and outbound - there are two "
+"styles\n"
+"of peer selection used for different tunnels - exploratory and client.\n"
+"Exploratory tunnels are used for both network database maintenance and "
+"tunnel\n"
+"maintenance, while client tunnels are used for end to end client messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:296
+msgid "Exploratory tunnel peer selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:298
+msgid ""
+"Exploratory tunnels are built out of a random selection of peers from a "
+"subset\n"
+"of the network.  The particular subset varies on the local router and on "
+"what their\n"
+"tunnel routing needs are.  In general, the exploratory tunnels are built "
+"out of\n"
+"randomly selected peers who are in the peer's \"not failing but active\" "
+"profile\n"
+"category.  The secondary purpose of the tunnels, beyond merely tunnel "
+"routing,\n"
+"is to find underutilized high capacity peers so that they can be promoted"
+" for\n"
+"use in client tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:308
+#, python-format
+msgid ""
+"Exploratory peer selection is discussed further on the\n"
+"Peer Profiling and Selection page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:314
+msgid "Client tunnel peer selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:316
+msgid ""
+"Client tunnels are built with a more stringent set of requirements - the "
+"local\n"
+"router will select peers out of its \"fast and high capacity\" profile "
+"category so\n"
+"that performance and reliability will meet the needs of the client "
+"application.\n"
+"However, there are several important details beyond that basic selection "
+"that \n"
+"should be adhered to, depending upon the client's anonymity needs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:324
+#, python-format
+msgid ""
+"Client peer selection is discussed further on the\n"
+"Peer Profiling and Selection page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:329
+msgid "Peer Ordering within Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:331
+#, python-format
+msgid ""
+"Peers are ordered within tunnels to deal with the\n"
+"predecessor attack\n"
+"(2008 update)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:338
+msgid ""
+"To frustrate the predecessor \n"
+"attack, the tunnel selection keeps the peers selected in a strict order -"
+"\n"
+"if A, B, and C are in a tunnel for a particular tunnel pool, the hop "
+"after A is always B, and the hop after\n"
+"B is always C."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:345
+msgid ""
+"Ordering is implemented by generating a random 32-byte key for each\n"
+"tunnel pool at startup.\n"
+"Peers should not be able to guess the ordering, or an attacker could\n"
+"craft two router hashes far apart to maximize the chance of being at both"
+"\n"
+"ends of a tunnel.\n"
+"Peers are sorted by XOR distance of the\n"
+"SHA256 Hash of (the peer's hash concatenated with the random key) from "
+"the random key"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:360
+msgid ""
+"Because each tunnel pool uses a different random key, ordering is "
+"consistent\n"
+"within a single pool but not between different pools.\n"
+"New keys are generated at each router restart."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:367
+msgid "Request delivery"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:369
+#, python-format
+msgid ""
+"A multi-hop tunnel is built using a single build message which is "
+"repeatedly\n"
+"decrypted and forwarded. In the terminology of\n"
+"Hashing it out in Public,\n"
+"this is \"non-interactive\" telescopic tunnel building."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:376
+#, python-format
+msgid ""
+"This tunnel request preparation, delivery, and response method is\n"
+"designed to reduce the number of\n"
+"predecessors exposed, cuts the number of messages transmitted, verifies "
+"proper\n"
+"connectivity, and avoids the message counting attack of traditional "
+"telescopic\n"
+"tunnel creation.\n"
+"(This method, which sends messages to extend a tunnel through the "
+"already-established\n"
+"part of the tunnel, is termed \"interactive\" telescopic tunnel building "
+"in\n"
+"the \"Hashing it out\" paper.)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:387
+#, python-format
+msgid ""
+"The details of tunnel request and response messages, and their "
+"encryption,\n"
+"are specified here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:392
+msgid ""
+"Peers may reject tunnel creation requests for a variety of reasons, "
+"though\n"
+"a series of four increasingly severe rejections are known: probabilistic "
+"rejection\n"
+"(due to approaching the router's capacity, or in response to a flood of "
+"requests), \n"
+"transient overload, bandwidth overload, and critical failure.  When "
+"received, \n"
+"those four are interpreted by the tunnel creator to help adjust their "
+"profile of\n"
+"the router in question."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:401
+#, python-format
+msgid ""
+"For more information on peer profiling, see the\n"
+"Peer Profiling and Selection page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:407
+msgid "Tunnel Pools"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:409
+#, python-format
+msgid ""
+"To allow efficient operation, the router maintains a series of tunnel "
+"pools,\n"
+"each managing a group of tunnels used for a specific purpose with their "
+"own\n"
+"configuration.  When a tunnel is needed for that purpose, the router "
+"selects one\n"
+"out of the appropriate pool at random.  Overall, there are two "
+"exploratory tunnel\n"
+"pools - one inbound and one outbound - each using the router's default "
+"configuration.\n"
+"In addition, there is a pair of pools for each local destination -\n"
+"one inbound and one outbound tunnel pool.  Those pools use the "
+"configuration specified\n"
+"when the local destination connects to the router via I2CP, or the router's defaults if\n"
+"not specified."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:421
+#, python-format
+msgid ""
+"Each pool has within its configuration a few key settings, defining how "
+"many\n"
+"tunnels to keep active, how many backup tunnels to maintain in case of "
+"failure,\n"
+"how long the tunnels should be, whether those\n"
+"lengths should be randomized, as \n"
+"well as any of the other settings allowed when configuring individual "
+"tunnels.\n"
+"Configuration options are specified on the I2CP "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:431
+msgid "Tunnel Lengths and Defaults"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:433
+msgid "On the tunnel overview page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:435
+msgid "Anticipatory Build Strategy and Priority"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:437
+msgid ""
+"Tunnel building is expensive, and tunnels expire a fixed time after they "
+"are built.\n"
+"However, when a pool that runs out of tunnels, the Destination is "
+"essentially dead.\n"
+"In addition, tunnel build success rate may vary greatly with both local "
+"and global\n"
+"network conditions.\n"
+"Therefore, it is important to maintain an anticipatory, adaptive build "
+"strategy\n"
+"to ensure that new tunnels are successfully built before they are needed,"
+"\n"
+"without building an excess of tunnels, building them too soon,\n"
+"or consuming too much CPU or bandwidth creating and sending the encrypted"
+" build messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:448
+msgid ""
+"For each tuple {exploratory/client, in/out, length, length variance}\n"
+"the router maintains statistics on the time required for a successful\n"
+"tunnel build.\n"
+"Using these statistics, it calculates how long before a tunnel's "
+"expiration\n"
+"it should start attempting to build a replacement.\n"
+"As the expiration time approaches without a successful replacement,\n"
+"it starts multiple build attempts in parallel, and then\n"
+"will increase the number of parallel attempts if necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:459
+msgid ""
+"To cap bandwidth and CPU usage,\n"
+"the router also limits the maximum number of build attempts outstanding\n"
+"across all pools.\n"
+"Critical builds (those for exploratory tunnels, and for pools that have\n"
+"run out of tunnels) are prioritized."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:468
+msgid "Tunnel Message Throttling"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:470
+msgid ""
+"Even though the tunnels within I2P bear a resemblance to a circuit "
+"switched\n"
+"network, everything within I2P is strictly message based - tunnels are "
+"merely\n"
+"accounting tricks to help organize the delivery of messages.  No "
+"assumptions are\n"
+"made regarding reliability or ordering of messages, and retransmissions "
+"are left\n"
+"to higher levels (e.g. I2P's client layer streaming library).  This "
+"allows I2P\n"
+"to take advantage of throttling techniques available to both packet "
+"switched and\n"
+"circuit switched networks.  For instance, each router may keep track of "
+"the \n"
+"moving average of how much data each tunnel is using, combine that with "
+"all of \n"
+"the averages used by other tunnels the router is participating in, and be"
+" able\n"
+"to accept or reject additional tunnel participation requests based on its"
+" \n"
+"capacity and utilization.  On the other hand, each router can simply drop"
+" \n"
+"messages that are beyond its capacity, exploiting the research used on "
+"the \n"
+"normal Internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:486
+msgid ""
+"In the current implementation, routers implement a\n"
+"weighted random early discard (WRED) strategy.\n"
+"For all participating routers (internal participant, inbound gateway, and"
+" outbound endpoint),\n"
+"the router will start randomly dropping a portion of messages as the\n"
+"bandwidth limits are approached.\n"
+"As traffic gets closer to, or exceeds, the limits, more messages are "
+"dropped.\n"
+"For an internal participant, all messages are fragmented and padded and "
+"therefore are the same size.\n"
+"At the inbound gateway and outbound endpoint, however, the dropping "
+"decision is made\n"
+"on the full (coalesced) message, and the message size is taken into "
+"account.\n"
+"Larger messages are more likely to be dropped.\n"
+"Also, messages are more likely to be dropped at the outbound endpoint "
+"than the inbound gateway,\n"
+"as those messages are not as \"far along\" in their journey and thus the "
+"network cost of\n"
+"dropping those messages is lower."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:504
+msgid "Mixing/batching"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:506
+msgid ""
+"What strategies could be used at the gateway and at each hop for "
+"delaying,\n"
+"reordering, rerouting, or padding messages?  To what extent should this "
+"be done\n"
+"automatically, how much should be configured as a per tunnel or per hop "
+"setting,\n"
+"and how should the tunnel's creator (and in turn, user) control this "
+"operation?\n"
+"All of this is left as unknown, to be worked out for a distant future "
+"release."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:515
+msgid "Padding"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:516
+msgid ""
+"The padding strategies can be used on a variety of levels, addressing the"
+"\n"
+"exposure of message size information to different adversaries.\n"
+"The current fixed tunnel message size is 1024 bytes.  Within this "
+"however, the fragmented\n"
+"messages themselves are not padded by the tunnel at all, though for end "
+"to end \n"
+"messages, they may be padded as part of the garlic wrapping."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:526
+msgid ""
+"WRED strategies have a significant impact on end-to-end performance,\n"
+"and prevention of network congestion collapse.\n"
+"The current WRED strategy should be carefully evaluated and improved."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/old-implementation.html:2
+msgid "Old Tunnel Implementation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/old-implementation.html:5
+#, python-format
+msgid ""
+"Note: Obsolete - NOT used!  Replaced in 0.6.1.10 - see here for the current implementation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:7
+msgid ""
+"This page describes the origins and design of I2P's unidirectional "
+"tunnels.\n"
+"For further infomrmation see:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:13
+msgid "Tunnel overview page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:19
+msgid "Tunnel design discussion"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:23
+msgid "Meeting 125 (~13:12-13:30)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:28
+msgid "Review"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:30
+msgid ""
+"While we aren't aware of any published research on the advantages of \n"
+"unidirecdtional tunnels,\n"
+"they appear to make it harder to detect a \n"
+"request/response pattern, which is quite possible to detect over a \n"
+"bidirectional tunnel.\n"
+"Several apps and protocols, notably HTTP,\n"
+"do transfer data in such manner. Having the traffic follow the same \n"
+"route to its destination and back could make it easier for an \n"
+"attacker who has only timing and traffic volume data to infer the path a"
+" \n"
+"tunnel is taking.\n"
+"Having the response come back along a different path arguably \n"
+"makes it harder."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:45
+msgid ""
+"When dealing with \n"
+"an internal adversary or most external adversaries, I2P's undirectional "
+"tunnels\n"
+"expose half as much traffic data than would be exposed with bidirectional"
+" circuits\n"
+"by simply looking at the flows themselves - an HTTP request and response "
+"would \n"
+"follow the same path in Tor, while in I2P the packets making up the "
+"request \n"
+"would go out through one or more outbound tunnels and the packets making "
+"up \n"
+"the response would come back through one or more different inbound "
+"tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:55
+msgid ""
+"The strategy of using two separate tunnels for inbound and outbound\n"
+"communication is not the only technique available, and it does have "
+"anonymity\n"
+"implications.  On the positive side, by using separate tunnels it lessens"
+" the\n"
+"traffic data exposed for analysis to participants in a tunnel - for "
+"instance,\n"
+"peers in an outbound tunnel from a web browser would only see the traffic"
+" of\n"
+"an HTTP GET, while the peers in an inbound tunnel would see the payload \n"
+"delivered along the tunnel.  With bidirectional tunnels, all participants"
+" would\n"
+"have access to the fact that e.g. 1KB was sent in one direction, then "
+"100KB\n"
+"in the other.  On the negative side, using unidirectional tunnels means "
+"that\n"
+"there are two sets of peers which need to be profiled and accounted for, "
+"and\n"
+"additional care must be taken to address the increased speed of "
+"predecessor\n"
+"attacks.  The tunnel pooling and building process\n"
+"(peer selection and ordering strategies)\n"
+"should minimize the worries of the predecessor attack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:73
+msgid "Anonymity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:75
+#, python-format
+msgid ""
+"A recent paper by Hermann and Grothoff\n"
+"declared that I2P's unidirectional tunnels \"seems to be a bad design "
+"decision\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:80
+msgid ""
+"The paper's main point is that\n"
+"deanonymizations on unidirectional tunnels take a longer time, which is "
+"an \n"
+"advantage, but that an attacker can be more certain in the unidirectional"
+" case. \n"
+"Therefore, the paper claims it isn't an advantage at all, but a "
+"disadvantage, at least\n"
+"with long-living eepsites."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:88
+msgid ""
+"This conclusion is not fully supported by the paper. Unidirectional "
+"tunnels clearly \n"
+"mitigate other attacks and it's not clear how to trade off the risk of "
+"the \n"
+"attack in the paper\n"
+"with attacks on a bidirectional tunnel architecture."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:95
+msgid ""
+"This conclusion is based on an arbitrary certainty vs. time weighting \n"
+"(tradeoff) that may not be applicable in all cases. For \n"
+"example, somebody could make a list of possible IPs then issue subpoenas "
+"to \n"
+"each. Or the attacker could DDoS each in turn and via a simple \n"
+"intersection attack see if the eepsite goes down or is slowed down. So "
+"close \n"
+"may be good enough, or time may be more important."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:104
+msgid ""
+"The conclusion is based on a specific weighting of the importance of "
+"certainty \n"
+"vs. time, and that weighting may be wrong, and it's definitely debatable,"
+" \n"
+"especially in a real world with subpoenas, search warrants, and other "
+"methods \n"
+"available for final confirmation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:111
+msgid ""
+"A full analysis of the tradeoffs of unidirectional vs. bidirectional \n"
+"tunnels is clearly outside the scope of the paper, and has not been done"
+" \n"
+"elsewhere. For example, how does this attack compare to the numerous "
+"possible \n"
+"timing attacks published about onion-routed networks? Clearly the authors"
+" have not\n"
+"done that analysis, if it's even possible to do it\n"
+"effectively."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:120
+msgid ""
+"Tor uses bidirectional tunnels and has had a lot of academic review. I2P"
+" \n"
+"uses unidirectional tunnels and has had very little review. Does the lack"
+" of a \n"
+"research paper defending unidirectional tunnels mean that it is a poor "
+"design \n"
+"choice, or just that it needs more study? Timing attacks and \n"
+"distributed attacks are difficult to defend against in both I2P and Tor. "
+"The \n"
+"design intent (see references above) was that unidirectional tunnels are "
+"more \n"
+"resistant to timing attacks. However, the paper presents a somewhat "
+"different type of timing \n"
+"attack. Is this attack, innovative as it is, sufficient to label I2P's \n"
+"tunnel architecture (and thus I2P as a whole) a \"bad design\", and by \n"
+"implication clearly inferior to Tor, or is it just a design alternative "
+"that \n"
+"clearly needs further investigation and analysis? There are several other"
+" reasons \n"
+"to consider I2P currently inferior to Tor and other projects (small "
+"network \n"
+"size, lack of funding, lack of review) but is unidirectional tunnels "
+"really a \n"
+"reason?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:137
+msgid ""
+"In summary, \"bad design decision\" is apparently (since the paper does\n"
+"not label bidirectional tunnels \"bad\") shorthand for \"unidirectional \n"
+"tunnels are unequivocally inferior to bidirectional tunnels\", yet this \n"
+"conclusion is not supported by the paper."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:4
+msgid ""
+"Thank you for your interest in contributing to I2P!\n"
+"The details of how you\n"
+"can make your contribution are provided below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:13
+#, python-format
+msgid "You can donate direct via PayPal to the account \"%(account)s\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:19
+msgid "One time donation:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:33
+msgid "Donate 10 €/month for 12 months:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:41
+#: i2p2www/pages/site/get-involved/donate.html:53
+#: i2p2www/pages/site/get-involved/donate.html:65
+#: i2p2www/pages/site/get-involved/donate.html:77
+msgid "I2P donation "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:47
+msgid "Donate 20 €/month for 12 months:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:59
+msgid "Donate 30 €/month for 12 months:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:71
+msgid "Donate 50 €/month for 12 months:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:86
+msgid "Flattr this"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:90
+#, python-format
+msgid ""
+"As of December 2010, eche|on has been running a Bitcoin account for the I2P project. \n"
+"If you'd like to donate using Bitcoin, just transfer your desired amount "
+"of coins to the account \n"
+"%(account)s and leave eche|on a note if you'd like your donation "
+"to be mentioned on the I2P webpage."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:95
+msgid ""
+"If you want to keep more or less anonymous, the option to send money via "
+"mail is also available. But it is less secure\n"
+"as the envelope can be lost on the way to us."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:99
+#, python-format
+msgid ""
+"If you'd like to donate via  snail mail, send an email to %(email)s\n"
+" and you'll receive an email with instructions detailing how to proceed."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:104
+#, python-format
+msgid ""
+"In the meantime, feel free to take a look at the generous donations that "
+"have been\n"
+"given in support of the I2P Project at the hall of fame."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:2
+msgid "Get Involved!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:4
+msgid "We need your help!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:5
+msgid ""
+"To get involved, please feel free to join us on the #i2p IRC channel (on\n"
+"irc.freenode.net, or within I2P on irc.freshcoffee.i2p or "
+"irc.postman.i2p)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:9
+#, python-format
+msgid ""
+"If you're interested in joining our team, please"
+" get in\n"
+"touch as we're always looking for eager contributors!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:13
+msgid ""
+"We need help in many areas, and you don't need to know Java to "
+"contribute!\n"
+"Here's a list to help you get started!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:18
+msgid "Spread the Word!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:19
+msgid ""
+"Tell people about I2P on forums, blogs, and comments to articles.\n"
+"Fix up the Wikipedia article about I2P in your language.\n"
+"Tell your friends."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:24
+msgid "Testing"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:25
+#, python-format
+msgid ""
+"Run the latest builds from monotone\n"
+"and report results on #i2p or as bugs on Trac."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:30
+msgid ""
+"Help fix the parts of the website that are outdated or incomplete.\n"
+"Translate pages into other languages."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:34
+msgid "Pictures"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:35
+msgid "Make some more pictures, fix the old ones on the website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:39
+msgid "Make an eepsite! Add some content! Contribute to the community!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:42
+msgid "Services"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:43
+msgid ""
+"Run a service on an eepsite. It could be a proxy, a forum, a tracker,\n"
+"a naming service, a search engine, an eepsite monitor... many of these\n"
+"aren't that hard."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:49
+#, python-format
+msgid ""
+"Write or port applications for I2P! There's some guidelines and\n"
+"a list of ideas on the applications page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:53
+msgid "Coding"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:54
+#, python-format
+msgid ""
+"There's plenty to do if you know Java or are ready to learn.\n"
+"Check for open tickets on Trac\n"
+"or the TODO list on %(zzz)s for\n"
+"some ideas on where to start.\n"
+"See the new developer's guide for details."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:61
+msgid "Translation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:62
+#, python-format
+msgid ""
+"Help translate the website and the software into your language.\n"
+"See the new translator's guide for details."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:66
+msgid "Analysis"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:67
+#, python-format
+msgid ""
+"Study or test the code to look for vulnerabilities.\n"
+"Both anonymity vulnerabilities from the various\n"
+"threat models,\n"
+"and DOS and other weaknesses due to securities holes,\n"
+"need researching."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:7
+msgid ""
+"Include some seed data in the distribution so a central reseed location "
+"isn't required?"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:10
+#, python-format
+msgid ""
+"Reachability Mapping / handle peers partially reachable / enhanced restricted routes"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:13
+msgid "Improve help pages and website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:14
+msgid "More translations"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:15
+msgid "SSU disconnect message"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:16
+msgid "Iterative floodfill lookups"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:21
+msgid "Full review of anonymity issues and other vulnerabilities"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:22
+msgid ""
+"Reduce memory usage, remove debugging overhead, make it run better on "
+"slow and embedded machines"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:25
+msgid "Docs"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:30
+msgid "Full restricted routes"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:35
+msgid "Tunnel mixing and padding"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:36
+msgid "User defined message delays"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:39
+#, python-format
+msgid ""
+"Please see the TODO list for more detailed info "
+"about some of these tasks."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:4
+msgid "I2P Project Targets"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:5
+#, python-format
+msgid ""
+"Below is a more detailed (yet still incomplete) discussion of the major "
+"areas\n"
+"of future development on the core I2P network, spanning the plausibly "
+"planned\n"
+"releases. This does not include stego transports, porting to wireless "
+"devices,\n"
+"or tools to secure the local machine, nor does it include client "
+"applications\n"
+"that will be essential in I2P's success. There are probably other things "
+"that\n"
+"will come up, especially as I2P gets more peer review, but these are the "
+"main\n"
+"'big things'. See also the roadmap. Want to "
+"help?\n"
+"Get involved!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:16
+#: i2p2www/pages/site/get-involved/todo.html:54
+msgid "Core functionality"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:18
+#: i2p2www/pages/site/get-involved/todo.html:57
+msgid "NAT/Firewall bridging via 1-hop restricted routes"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:21
+#: i2p2www/pages/site/get-involved/todo.html:130
+msgid "High degree transport layer with UDP, NBIO, or NIO"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:24
+#: i2p2www/pages/site/get-involved/todo.html:218
+msgid "NetworkDB and profile tuning and ejection policy for large nets"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:28
+#: i2p2www/pages/site/get-involved/todo.html:242
+msgid "Security / anonymity"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:30
+#: i2p2www/pages/site/get-involved/todo.html:245
+msgid ""
+"Per-hop tunnel id & new permuted TunnelVerificationStructure "
+"encryption"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:33
+#: i2p2www/pages/site/get-involved/todo.html:295
+msgid "Strict ordering of participants within tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:36
+msgid "Randomly permuted tunnel lengths"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:39
+#: i2p2www/pages/site/get-involved/todo.html:357
+msgid "Full blown n-hop restricted routes with optional trusted links"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:42
+#: i2p2www/pages/site/get-involved/todo.html:376
+msgid "Hashcash for routerIdentity, destination, and tunnel request"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:45
+#: i2p2www/pages/site/get-involved/todo.html:405
+msgid "Advanced tunnel operation (batching/mixing/throttling/padding)"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:48
+#: i2p2www/pages/site/get-involved/todo.html:442
+msgid "Stop & go mix w/ garlics & tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:62
+msgid "Implemented in I2P 0.6.0.6"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:63
+msgid ""
+"The functionality of allowing routers to fully participate within the "
+"network \n"
+"while behind firewalls and NATs that they do not control requires some "
+"basic \n"
+"restricted route operation (since those peers will not be able to receive"
+" \n"
+"inbound connections). To do this successfully, you consider peers one of"
+" \n"
+"two ways:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:73
+msgid ""
+"Peers who have reachable interfaces - these peers do not need to \n"
+"do anything special"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:77
+msgid ""
+"Peers who do not have reachable interfaces - these peers must "
+"build \n"
+"a tunnel pointing at them where the gateway is one of the peers they have"
+" \n"
+"established a connection with who has both a publicly reachable interface"
+" \n"
+"and who has agreed to serve as their 'introducer'."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:85
+msgid ""
+"To do this, peers who have no IP address simply connect to a few peers, \n"
+"build a tunnel through them, and publish a reference to those tunnels "
+"within \n"
+"their RouterInfo structure in the network database."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:90
+msgid ""
+"When someone wants to contact any particular router, they first must get"
+" \n"
+"its RouterInfo from the network database, which will tell them whether "
+"they \n"
+"can connect directly (e.g. the peer has a publicly reachable interface) \n"
+"or whether they need to contact them indirectly. Direct connections occur"
+" \n"
+"as normal, while indirect connections are done through one of the "
+"published \n"
+"tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:98
+msgid ""
+"When a router just wants to get a message or two to a specific hidden "
+"peer, \n"
+"they can just use the indirect tunnel for sending the payload. However, \n"
+"if the router wants to talk to the hidden peer often (for instance, as "
+"part \n"
+"of a tunnel), they will send a garlic routed message through the indirect"
+" \n"
+"tunnel to that hidden peer which unwraps to contain a message which "
+"should \n"
+"be sent to the originating router. That hidden peer then establishes an \n"
+"outbound connection to the originating router and from then on, those two"
+" \n"
+"routers can talk to each other directly over that newly established "
+"direct \n"
+"connection."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:109
+msgid ""
+"Of course, that only works if the originating peer can receive "
+"connections \n"
+"(they aren't also hidden). However, if the originating peer is hidden, "
+"they \n"
+"can simply direct the garlic routed message to come back to the "
+"originating \n"
+"peer's inbound tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:115
+msgid ""
+"This is not meant to provide a way for a peer's IP address to be "
+"concealed, \n"
+"merely as a way to let people behind firewalls and NATs fully operate "
+"within \n"
+"the network. Concealing the peer's IP address adds a little more work, as"
+" \n"
+"described below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:121
+msgid ""
+"With this technique, any router can participate as any part of a tunnel."
+" \n"
+"For efficiency purposes, a hidden peer would be a bad choice for an "
+"inbound \n"
+"gateway, and within any given tunnel, two neighboring peers wouldn't want"
+" \n"
+"to be hidden. But that is not technically necessary."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:133
+msgid "Both UDP and NIO have been Implemented in I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:134
+msgid ""
+"Standard TCP communication in Java generally requires blocking socket \n"
+"calls, and to keep a blocked socket from hanging the entire system, those"
+" \n"
+"blocking calls are done on their own threads. Our current TCP transport \n"
+"is implemented in a naive fashion - for each peer we are talking to, we \n"
+"have one thread reading and one thread writing. The reader thread simply"
+" \n"
+"loops a bunch of read() calls, building I2NP messages and adding them \n"
+"to our internal inbound message queue, and the writer thread pulls "
+"messages \n"
+"off a per-connection outbound message queue and shoves the data through \n"
+"write() calls."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:145
+msgid ""
+"We do this fairly efficiently, from a CPU perspective - at any time, \n"
+"almost all of these threads are sitting idle, blocked waiting for "
+"something \n"
+"to do. However, each thread consumes real resources (on older Linux "
+"kernels, \n"
+"for instance, each thread would often be implemented as a fork()'ed "
+"process). \n"
+"As the network grows, the number of peers each router will want to talk \n"
+"with will increase (remember, I2P is fully connected, meaning that any \n"
+"given peer should know how to get a message to any other peer, and "
+"restricted \n"
+"route support will probably not significantly reduce the number of "
+"connections \n"
+"necessary). This means that with a 100,000 router network, each router \n"
+"will have up to 199,998 threads just to deal with the TCP connections!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:157
+msgid ""
+"Obviously, that just won't work. We need to use a transport layer that \n"
+"can scale. In Java, we have two main camps:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:162
+#, python-format
+msgid ""
+"Implemented in I2P 0.6 (\"SSU\") as documented elsewhere"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:165
+msgid ""
+"Sending and receiving UDP datagrams is a connectionless operation - if \n"
+"we are communicating with 100,000 peers, we simply stick the UDP packets"
+" \n"
+"in a queue and have a single thread pulling them off the queue and "
+"shoving \n"
+"them out the pipe (and to receive, have a single thread pulling in any \n"
+"UDP packets received and adding them to an inbound queue)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:172
+msgid ""
+"However, moving to UDP means losing the benefits of TCP's ordering, "
+"congestion \n"
+"control, MTU discovery, etc. Implementing that code will take significant"
+" \n"
+"work, however I2P doesn't need it to be as strong as TCP. Specifically, \n"
+"a while ago I was taking some measurements in the simulator and on the \n"
+"live net, and the vast majority of messages transferred would fit easily"
+" \n"
+"within a single unfragmented UDP packet, and the largest of the messages"
+" \n"
+"would fit within 20-30 packets. As mule pointed out, TCP adds a "
+"significant \n"
+"overhead when dealing with so many small packets, as the ACKs are within"
+" \n"
+"an order of magnitude in size. With UDP, we can optimize the transport \n"
+"for both efficiency and resilience by taking into account I2P's "
+"particular \n"
+"needs."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:185
+msgid "It will be a lot of work though."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:188
+msgid "NIO or NBIO"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:189
+msgid "NIO Implemented in I2P 0.6.1.22 (\"NTCP\")"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:192
+msgid ""
+"In Java 1.4, a set of \"New I/O\" packages was introduced, allowing Java"
+" \n"
+"developers to take advantage of the operating system's nonblocking IO \n"
+"capabilities - allowing you to maintain a large number of concurrent IO \n"
+"operations without requiring a separate thread for each. There is much \n"
+"promise with this approach, as we can scalable handle a large number of \n"
+"concurrent connections and we don't have to write a mini-TCP stack with \n"
+"UDP. However, the NIO packages have not proven themselves to be battle-"
+"ready, \n"
+"as the Freenet developer's found. In addition, requiring NIO support "
+"would \n"
+"mean we can't run on any of the open source JVMs like Kaffe, \n"
+"as GNU/Classpath has only "
+"limited \n"
+"support for NIO. (note: this may not be the case anymore, as there \n"
+"has been some progress on Classpath's NIO, but it is an unknown "
+"quantity)"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:206
+#, python-format
+msgid ""
+"Another alternative along the same lines is the Non"
+" \n"
+"Blocking I/O package - essentially a cleanroom NIO implementation \n"
+"(written before NIO was around). It works by using some native OS code \n"
+"to do the nonblocking IO, passing off events through Java. It seems to \n"
+"be working with Kaffe, though there doesn't seem to be much development \n"
+"activity on it lately (likely due to 1.4's NIO deployment)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:221
+msgid ""
+"Within the current network database and profile management "
+"implementation, \n"
+"we have taken the liberty of some practical shortcuts. For instance, we \n"
+"don't have the code to drop peer references from the K-buckets, as we \n"
+"don't have enough peers to even plausibly fill any of them, so instead, \n"
+"we just keep the peers in whatever bucket is appropriate. Another example"
+" \n"
+"deals with the peer profiles - the memory required to maintain each "
+"peer's \n"
+"profile is small enough that we can keep thousands of full blown profiles"
+" \n"
+"in memory without problems. While we have the capacity to use trimmed \n"
+"down profiles (which we can maintain 100s of thousands in memory), we \n"
+"don't have any code to deal with moving a profile from a \"minimal "
+"profile\" \n"
+"to a \"full profile\", a \"full profile\" to a \"minimal profile\", or to"
+" simply \n"
+"eject a profile altogether. It just wouldn't be practical to write that \n"
+"code yet, since we aren't going to need it for a while."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:236
+msgid ""
+"That said, as the network grows we are going to want to keep these "
+"considerations \n"
+"in mind. We will have some work to do, but we can put it off for later."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:248
+#: i2p2www/pages/site/get-involved/todo.html:332
+#, python-format
+msgid ""
+"Addressed in I2P 0.5 as documented elsewhere"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:251
+msgid ""
+"Right now, if Alice builds a four hop inbound tunnel starting at Elvis, \n"
+"going to Dave, then to Charlie, then Bob, and finally Alice "
+"(A<--B<--C<--D<--E), \n"
+"all five of them will know they are participating in tunnel \"123\", as \n"
+"the messages are tagged as such. What we want to do is give each hop "
+"their \n"
+"own unique tunnel hop ID - Charlie will receive messages on tunnel 234 \n"
+"and forward them to tunnel 876 on Bob. The intent is to prevent Bob or \n"
+"Charlie from knowing that they are in Alice's tunnel, as if each hop in \n"
+"the tunnel had the same tunnel ID, collusion attacks aren't much work."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:261
+msgid ""
+"Adding a unique tunnel ID per hop isn't hard, but by itself, "
+"insufficient. \n"
+"If Dave and Bob are under the control of the same attacker, they wouldn't"
+" \n"
+"be able to tell they are in the same tunnel due to the tunnel ID, but \n"
+"would be able to tell by the message bodies and verification structures \n"
+"by simply comparing them. To prevent that, the tunnel must use layered \n"
+"encryption along the path, both on the payload of the tunneled message \n"
+"and on the verification structure (used to prevent simple tagging "
+"attacks). \n"
+"This requires some simple modifications to the TunnelMessage, as well \n"
+"as the inclusion of per-hop secret keys delivered during tunnel creation"
+" \n"
+"and given to the tunnel's gateway. We must fix a maximum tunnel length \n"
+"(e.g. 16 hops) and instruct the gateway to encrypt the message to each \n"
+"of the 16 delivered secret keys, in reverse order, and to encrypt the \n"
+"signature of the hash of the (encrypted) payload at each step. The "
+"gateway \n"
+"then sends that 16-step encrypted message, along with a 16-step and "
+"16-wide \n"
+"encrypted mapping to the first hop, which then decrypts the mapping and \n"
+"the payload with their secret key, looking in the 16-wide mapping for \n"
+"the entry associated with their own hop (keyed by the per-hop tunnel ID)"
+" \n"
+"and verifying the payload by checking it against the associated signed \n"
+"hash."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:282
+msgid ""
+"The tunnel gateway does still have more information than the other peers"
+" \n"
+"in the tunnel, and compromising both the gateway and a tunnel participant"
+" \n"
+"would allow those peers to collude, exposing the fact that they are both"
+" \n"
+"in the same tunnel. In addition, neighboring peers know that they are \n"
+"in the same tunnel anyway, as they know who they send the message to (and"
+" \n"
+"with IP-based transports without restricted routes, they know who they \n"
+"got it from). However, the above two techniques significantly increase \n"
+"the cost of gaining meaningful samples when dealing with longer tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:298
+msgid "Implemented in release 0.6.2"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:301
+#, python-format
+msgid ""
+"As Connelly proposed to deal with the\n"
+"predecessor attack (2008\n"
+"update), keeping the order of peers within our tunnels consistent \n"
+"(aka whenever Alice creates a tunnel with both Bob and Charlie in it, \n"
+"Bob's next hop is always Charlie), we address the issue as Bob doesn't \n"
+"get to substantially sample Alice's peer selection group. We may even \n"
+"want to explicitly allow Bob to participate in Alice's tunnels in only \n"
+"one way - receiving a message from Dave and sending it to Charlie - and \n"
+"if any of those peers are not available to participate in the tunnel (due"
+" \n"
+"to overload, network disconnection, etc), avoid asking Bob to participate"
+" \n"
+"in any tunnels until they are back online."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:316
+msgid ""
+"More analysis is necessary for revising the tunnel creation - at the \n"
+"moment, we simply select and order randomly within the peer's top tier \n"
+"of peers (ones with fast + high capacity)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:321
+msgid ""
+"Adding a strict ordering to peers in a tunnel also improves the anonymity"
+" \n"
+"of peers with 0-hop tunnels, as otherwise the fact that a peer's gateway"
+" \n"
+"is always the same would be particularly damning. However, peers with \n"
+"0-hop tunnels may want to periodically use a 1-hop tunnel to simulate \n"
+"the failure of a normally reliable gateway peer (so every MTBF*(tunnel \n"
+"duration) minutes, use a 1-hop tunnel)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:338
+msgid ""
+"Without tunnel length permutation, if someone were to somehow detect that"
+" \n"
+"a destination had a particular number of hops, it might be able to use "
+"that \n"
+"information to identify the router the destination is located on, per the"
+" \n"
+"predecessor attack. For instance, if everyone has 2-hop tunnels, if Bob \n"
+"receives a tunnel message from Charlie and forwards it to Alice, Bob "
+"knows \n"
+"Alice is the final router in the tunnel. If Bob were to identify what "
+"destination \n"
+"that tunnel served (by means of colluding with the gateway and harvesting"
+" \n"
+"the network database for all of the LeaseSets), he would know the router"
+" \n"
+"on which that destination is located (and without restricted routes, that"
+" \n"
+"would mean what IP address the destination is on)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:350
+msgid ""
+"It is to counter user behavior that tunnel lengths should be permuted, \n"
+"using algorithms based on the length requested (for example, the 1/MTBF \n"
+"length change for 0-hop tunnels outlined above)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:360
+msgid ""
+"The restricted route functionality described before was simply a "
+"functional \n"
+"issue - how to let peers who would not otherwise be able to communicate \n"
+"do so. However, the concept of allowing restricted routes includes "
+"additional \n"
+"capabilities. For instance, if a router absolutely cannot risk "
+"communicating \n"
+"directly with any untrusted peers, they can set up trusted links through"
+" \n"
+"those peers, using them to both send and receive all of its messages. \n"
+"Those hidden peers who want to be completely isolated would also refuse \n"
+"to connect to peers who attempt to get them to (as demonstrated by the \n"
+"garlic routing technique outlined before) - they can simply take the "
+"garlic \n"
+"clove that has a request for delivery to a particular peer and tunnel \n"
+"route that message out one of the hidden peer's trusted links with "
+"instructions \n"
+"to forward it as requested."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:379
+#, python-format
+msgid ""
+"Within the network, we will want some way to deter people from consuming"
+" \n"
+"too many resources or from creating so many peers to mount a Sybil \n"
+"attack. Traditional techniques such as having a peer see who is "
+"requesting \n"
+"a resource or running a peer aren't appropriate for use within I2P, as \n"
+"doing so would compromise the anonymity of the system. Instead, we want \n"
+"to make certain requests \"expensive\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:387
+msgid ""
+"Hashcash is one technique that \n"
+"we can use to anonymously increase the \"cost\" of doing certain "
+"activities, \n"
+"such as creating a new router identity (done only once on installation),"
+" \n"
+"creating a new destination (done only once when creating a service), or \n"
+"requesting that a peer participate in a tunnel (done often, perhaps 2-300"
+" \n"
+"times per hour). We don't know the \"correct\" cost of each type of "
+"certificate \n"
+"yet, but with some research and experimentation, we could set a base "
+"level \n"
+"that is sufficiently expensive while not an excessive burden for people \n"
+"with few resources."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:398
+msgid ""
+"There are a few other algorithms that we can explore for making those \n"
+"requests for resources \"nonfree\", and further research on that front is"
+" \n"
+"appropriate."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:408
+#, python-format
+msgid ""
+"To powerful passive external observers as well as large colluding "
+"internal \n"
+"observers, standard tunnel routing is vulnerable to traffic analysis "
+"attacks \n"
+"- simply watching the size and frequency of messages being passed between"
+" \n"
+"routers. To defend against these, we will want to essentially turn some \n"
+"of the tunnels into its own mix cascade - delaying messages received at \n"
+"the gateway and passing them in batches, reordering them as necessary, \n"
+"and injecting dummy messages (indistinguishable from other \"real\" "
+"tunnel \n"
+"messages by peers in the path). There has been a significant amount of \n"
+"research \n"
+"on these algorithms that we can lean on prior to implementing the various"
+" \n"
+"tunnel mixing strategies."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:421
+msgid ""
+"In addition to the anonymity aspects of more varied tunnel operation, \n"
+"there is a functional dimension as well. Each peer only has a certain \n"
+"amount of data they can route for the network, and to keep any particular"
+" \n"
+"tunnel from consuming an unreasonable portion of that bandwidth, they \n"
+"will want to include some throttles on the tunnel. For instance, a tunnel"
+" \n"
+"may be configured to throttle itself after passing 600 messages (1 per \n"
+"second), 2.4MB (4KBps), or exceeding some moving average (8KBps for the \n"
+"last minute). Excess messages may be delayed or summarily dropped. With \n"
+"this sort of throttling, peers can provide ATM-like QoS support for their"
+" \n"
+"tunnels, refusing to agree to allocate more bandwidth than the peer has \n"
+"available."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:434
+msgid ""
+"In addition, we may want to implement code to dynamically reroute tunnels"
+" \n"
+"to avoid failed peers or to inject additional hops into the path. This \n"
+"can be done by garlic routing a message to any particular peer in a "
+"tunnel \n"
+"with instructions to redefine the next-hop in the tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:445
+msgid ""
+"Beyond the per-tunnel batching and mixing strategy, there are further \n"
+"capabilities for protecting against powerful attackers, such as allowing"
+" \n"
+"each step in a garlic routed path to define a delay or window in which \n"
+"it should be forwarded on. This would enable protections against the long"
+" \n"
+"term intersection attack, as a peer could send a message that looks "
+"perfectly \n"
+"standard to most peers that pass it along, except at any peers where the"
+" \n"
+"clove exposed includes delay instructions."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:457
+#, python-format
+msgid ""
+"Performance related improvements are listed on the\n"
+"Performance page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:2
+msgid "Bounty Arabic translation of webpage and router console"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:3
+#: i2p2www/pages/site/get-involved/bounties/index.html:112
+msgid "Arabic translation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:6
+msgid ""
+"To improve I2P usage and attract more people\n"
+"into I2P echelon set out this bounty for translation\n"
+"of the I2P web page and I2P router console into Arabic."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:12
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:12
+msgid "This bounty is set into 2 subparts:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:14
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:14
+msgid "Part 1 is translation of the webpage."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:17
+msgid ""
+"For collecting the bounty of 20 BTC you need to translate the following "
+"pages:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:25
+msgid "This job was done by hamada and the bounty of 20 BTC was paid to hamada."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:27
+msgid ""
+"Part 2 is the translation of the router console. The router console was\n"
+"partly translated and the bounty of 80 BTC was paid to hamada."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:34
+msgid "Judge is echelon."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/btc-client.html:2
+msgid "Bounty creating a I2P native Bitcoin client"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/btc-client.html:3
+msgid "BTC I2P native client"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/btc-client.html:6
+msgid ""
+"For a future of I2P and attract more people\n"
+"into I2P this bounty is to create a I2P native Bitcoin client. \n"
+"It should integrate with other client via the I2P network and via "
+"gateways to\n"
+"the existant bitcoin network."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/btc-client.html:15
+msgid "Judge is psychonaut who donated the first 30 € to this bounty."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:2
+msgid "Bounty datastorage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:3
+msgid "datastore"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:6
+msgid ""
+"To improve I2P's usage and to be independent of routers \n"
+"online status we want a datastorage as a extension to I2P.\n"
+"Like in Freenet the datastorage should be distributed and every\n"
+"participating node should be able to configure his options.\n"
+"The files should be saved in chunks and at least 2-3 times to\n"
+"obtain redundancy. Usage of storage space should be auto balanced.\n"
+"As it is a extra application, it should work flawless within I2P and\n"
+"cooperate nice with the I2P router. Maybe a integration within the\n"
+"webpage/router could be done."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:17
+msgid ""
+"This bounty cooperates with the 2 other bounties \"frost for I2P\" and \n"
+"\"eepsites in datastorage\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:21
+msgid ""
+"The frost for I2P datastorage bounty is paid for a frost like program \n"
+"with which files/messages are stored into database and got from database."
+"\n"
+"It needs to work with a GUI."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:26
+msgid ""
+"The eepsite served out of I2P datastorage extends a I2P router to send\n"
+"out eepsites out of the I2P datastorage. All files for eepsites need to "
+"be\n"
+"saved inside of datastorage and are taken from it.\n"
+"Extension:\n"
+"For better integration all datastorage participants could serve that "
+"eepsite."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:36
+msgid ""
+"For bounties to be declared done and paid, we need the program AND the "
+"source.\n"
+"Source and code need to be licensed under a free license (free to change "
+"and \n"
+"free to distribute)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/deb-pack.html:2
+msgid "Bounty I2P package in Debian and Ubuntu mirrors"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/deb-pack.html:3
+msgid "I2P Ubuntu/Debian package"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/deb-pack.html:6
+msgid ""
+"For the future of I2P and in order to attract more people\n"
+"to I2P, this bounty was set for including an I2P package into the Ubuntu "
+"and Debian \n"
+"archive mirrors.\n"
+"To claim this bounty, the I2P router package needs to be available from\n"
+"Ubuntu and Debian archive mirrors and Debian bug \n"
+"448638 \n"
+"needs to be closed successfully."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/i2phex.html:2
+msgid "Bounty I2PHex code implementation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/i2phex.html:3
+msgid "i2phex code implementation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/i2phex.html:6
+msgid ""
+"To improve I2P usage and attract more people\n"
+"into I2PHex P2P ArneBab setout the bounty for implementing actual\n"
+"Phex code onto I2PHex."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:5
+msgid "Bounties for I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:6
+msgid ""
+"While we always gratefully accept any contributions of code, \n"
+"documentation, and the like, there are other ways to help I2P move \n"
+"forward.  As with any open source project, our goals would be achieved "
+"more \n"
+"rapidly if we were able to support all of our contributors to work on \n"
+"I2P full time.  However, as with any open source project, that's not a \n"
+"possibility.  Instead, we are making use of a bounty system, whereby \n"
+"anyone can get support for working on something that people want \n"
+"implemented, and people who want to contribute to I2P can be assured that"
+" \n"
+"their support goes to what they care about."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:18
+msgid ""
+"We are also keeping open the ability for people who want to support I2P \n"
+"but don't have strong feelings about the bounties available.  Those "
+"people\n"
+"can simply put their trust in the I2P team to do what we feel is best by\n"
+"donating to a catch-all general fund that will be used as deemed \n"
+"necessary - allocated to various bounties, covering incidentals (hosting,"
+" \n"
+"etc), and the like."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:27
+msgid "Current bounties"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+#: i2p2www/pages/site/get-involved/bounties/index.html:105
+msgid "Name"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+#: i2p2www/pages/site/get-involved/bounties/index.html:105
+msgid "Status"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+msgid "Judge"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+msgid "Bounty"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:32
+msgid "Frost for I2P datastorage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:33
+#: i2p2www/pages/site/get-involved/bounties/index.html:40
+#: i2p2www/pages/site/get-involved/bounties/index.html:47
+#: i2p2www/pages/site/get-involved/bounties/index.html:54
+#: i2p2www/pages/site/get-involved/bounties/index.html:61
+#: i2p2www/pages/site/get-involved/bounties/index.html:68
+#: i2p2www/pages/site/get-involved/bounties/index.html:82
+msgid "Proposal in development"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:39
+msgid "Eepsites served out of I2P datastorage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:46
+msgid "Backporting Phex code onto I2PHex"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:53
+msgid "Make I2P IPv6 native"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:60
+msgid "I2P package in Debian and Ubuntu mirrors"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:74
+msgid "Unit tests and Multi-router Simulation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:75
+msgid "Partly done, partly in work, partly still open"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:89
+msgid "Hold bounties, set on hold due to jrandom AWOL and missing funding"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:94
+msgid "Bundling bounties"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:95
+msgid "Proposed"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:102
+msgid "Claimed bounties"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:105
+msgid "Dev team"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:107
+msgid "Setting up a SILC server"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:117
+msgid "Datastore over I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:127
+msgid "Swarming file transfer"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:132
+msgid "Streaming library window size"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:137
+msgid "IRC connect time monitor"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:142
+msgid "Unit tests (part 1)"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:154
+msgid ""
+"Dev lists anyone who may already be working on the bounty - collaboration"
+" is\n"
+"preferred, so if you're interested in working on it, please contact one "
+"of the\n"
+"people listed!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/ipv6.html:2
+msgid "Bounty I2P IPv6 native"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/ipv6.html:3
+msgid "native IPv6 I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/ipv6.html:6
+msgid ""
+"For a future of I2P and attract more people\n"
+"into I2P I withdrawal the vuze bounty and offer a IPv6 bounty.\n"
+"To claim this bounty, the I2P router needs to run full on native\n"
+"IPv6 connections like it does on IPv4."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/ipv6.html:15
+#: i2p2www/pages/site/get-involved/bounties/vuze-plugin.html:20
+msgid ""
+"For bounties to be declared done and paid, we need the plugin AND the "
+"source.\n"
+"Source and code need to be licensed under a free license (free to change "
+"and \n"
+"free to distribute)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:2
+msgid "Bounty russian translation of webpage and router console"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:3
+msgid "Russian translation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:6
+msgid ""
+"To improve I2P usage and attract more people\n"
+"into I2P a anonymous donator set out the bounty for translation\n"
+"of the I2P web page and I2P router console into russian language."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:17
+msgid ""
+"For collecting the bounty of $115 USD you need to translate the following"
+" pages:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:30
+msgid ""
+"Part 2 is the translation of the router console. The whole router console"
+" needs\n"
+"to be translated to collect the bounty of $115 USD."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:37
+msgid "Judge is the russian donor."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:2
+msgid "Bounty migrate I2P IRC to SILC"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:3
+msgid "I2P silc server"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:7
+msgid ""
+"For a future of I2P and attract more people\n"
+"into I2P this bounty is to setup and host a I2P SILC server.   \n"
+"This will allow people to send files over their messaging servers and "
+"have intrinsic security built into the protocol."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:12
+msgid ""
+"A silc server needs to be set up and run for at least 3 month time to get"
+" payed. \n"
+"A second server should be set up, to."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:16
+msgid ""
+"Bounty was withdrawn and money donated to returningnovice and general "
+"fund."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:22
+msgid "Judge is An Anonymous Secret Society, society@mail.i2p."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/syndie-2012.html:7
+msgid ""
+"Beside of I2P we want to encourage users\n"
+"to care more about anonymity and security. As I2P is a low \n"
+"latency network with its natural limits, the software SYNDIE\n"
+"can overcome some of these limits and provide better anonymity\n"
+"for people who really need it."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/syndie-2012.html:14
+msgid ""
+"For our bad sake the syndie project is out of development for \n"
+"quite a long time yet (5 years). To get a fresh and new built \n"
+"with needed bugfixes we set out this bounty. Also syndie needs\n"
+"some enhancements and a better GUI for users to work with it.\n"
+"Current bounty sum is 100 Bitcoin."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:2
+msgid "Bounty unittests"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:3
+msgid "unit test"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:7
+msgid ""
+"To improve I2P's maintainability, we want to have a solid set of\n"
+"automated unit tests for the critical code.  While we do have some\n"
+"unit tests at the moment, they are ad-hoc and partly unfinished.  \n"
+"This bounty is for someone to check the existing tests and move over\n"
+"old ones to jUnit, automate their execution, extend them to provide \n"
+"better code coverage, and publish the report online.  Its a massive \n"
+"effort, but can be broken down into phases, listed below (phase 2 \n"
+"must occur first, but further phases may happen in any order).\n"
+"As this needs some reading of code, it is the best start point for\n"
+"new devs to get a good overview of I2P code and coding. A good job\n"
+"for college students, interns or anyone who is just interested."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:20
+msgid ""
+"Take care! Jobs and bounties shuffled a bit!\n"
+"Phase 6,7 and 8 are still open!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:26
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:40
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:55
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:66
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:77
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:88
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:101
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:112
+#, python-format
+msgid "Phase %(phase)s:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:27
+msgid "CI jenkins and IRC bot"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:28
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:42
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:57
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:68
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:79
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:90
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:103
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:114
+#, python-format
+msgid "Bounty: %(euro)s €"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:29
+msgid "server runs and this section is blocked"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:31
+msgid ""
+"To collect this bounty, a continuous integration server (Jenkins,\n"
+"old name was Hudson) must be set up and a connected IRC bot needs \n"
+"to set up in the channel #i2p-dev on IRC2p network to print out\n"
+"results of build tests.
            \n"
+"The server needs to be run long term."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:41
+msgid "Check existing SDK tests"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:43
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:69
+msgid "paid to str4d"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:45
+#, python-format
+msgid ""
+"To collect this bounty, the existing SDK tests must be checked \n"
+"and made to work again. The need to be integrated into the ant \n"
+"build scripts (\"ant test\"), and tied in with a code coverage tool (e.g."
+" \n"
+"Clover).  The ant script\n"
+"must be capable of generating test status results as a web page, \n"
+"which will be published online."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:56
+msgid "SDK test coverage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:58
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:80
+msgid "paid to unittests dev team"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:60
+msgid ""
+"To collect this bounty, the automated unit tests of the SDK \n"
+"(i2p/core/java/src) must work again."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:67
+msgid "Router test migration"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:71
+msgid ""
+"As with phase 2, the existing unit tests for the router must be\n"
+"moved over to the automated system."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:78
+msgid "Router test coverage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:82
+msgid ""
+"To collect this bounty, the automated unit tests of the router \n"
+"(i2p/router/java/src) must work again."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:89
+msgid "Streaming lib tests"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:94
+#, python-format
+msgid ""
+"To collect this bounty, a new set of unit tests must meet a \n"
+"measured code coverage of 90% of the streaming lib \n"
+"(i2p/apps/ministreaming/ and i2p/apps/streaming/)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:102
+msgid "Unit tests coverage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:106
+msgid ""
+"To collect this bounty, all above unit tests must meet the 100%\n"
+"coverage marker (except for log statements)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:113
+msgid "MultiRouter simulation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:115
+msgid "will be split in more sub-tasks"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:117
+msgid ""
+"To collect this bounty, the existing in-memory multi-router\n"
+"simulation must be checked, made work again and extend to simulate\n"
+"lots of routers in memory on a single machine. This bounty will\n"
+"be split in more fine grained subworks."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:126
+msgid ""
+"Judge on all these works is the donor and donor decides if a phase is\n"
+"called succesfull done and money can be paid."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/vuze-plugin.html:2
+msgid "Bounty I2P vuze plugin"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/vuze-plugin.html:3
+msgid "vuze plugin"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/vuze-plugin.html:6
+msgid ""
+"To improve I2P usage and attract more people\n"
+"into I2P torrent P2P I setout the bounty for a working I2P vuze\n"
+"plugin.\n"
+"The plugin needs to be official and submitted to vuze for publication\n"
+"on their webpage/repository for plugins.\n"
+"It should be easy to install and configured, work smooth and flawless.\n"
+"Configuration should be friendly to starters and made easy to be "
+"anonymous.\n"
+"It should work with *.b32.i2p destinations as with signed (516++ bits) \n"
+"destinations."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:2
+msgid "Application Development"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:4
+msgid "Application Development Guide"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:8
+#: i2p2www/pages/site/get-involved/develop/applications.html:14
+msgid "Why write I2P-specific code?"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:9
+#: i2p2www/pages/site/get-involved/develop/applications.html:94
+msgid "Important concepts"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:10
+#: i2p2www/pages/site/get-involved/develop/applications.html:170
+msgid "Development options"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:11
+#: i2p2www/pages/site/get-involved/develop/applications.html:276
+msgid "Start developing - a simple guide"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:16
+#, python-format
+msgid ""
+"There are multiple ways to use applications in I2P.\n"
+"Using I2PTunnel,\n"
+"you can use regular applications without needing to program explicit I2P "
+"support.\n"
+"This is very effective for client-server scenario's,\n"
+"where you need to connect to a single website.\n"
+"You can simply create a tunnel using I2PTunnel to connect to that "
+"website, as shown in Figure 1."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:24
+msgid ""
+"If your application is distributed, it will require connections to a "
+"large amount of peers.\n"
+"Using I2PTunnel, you will need to create a new tunnel for each peer you "
+"want to contact,\n"
+"as shown in Figure 2.\n"
+"This process can of course be automated, but running a lot of I2PTunnel "
+"instances creates a large amount of overhead.\n"
+"In addition, with many protocols you will need to force everyone to \n"
+"use the same set of ports for all peers - e.g. if you want to reliably "
+"run DCC \n"
+"chat, everyone needs to agree that port 10001 is Alice, port 10002 is "
+"Bob, port \n"
+"10003 is Charlie, and so on, since the protocol includes TCP/IP specific "
+"information\n"
+"(host and port)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:35
+msgid ""
+"General network applications often send a lot of additional data that "
+"could be used to identify users.\n"
+"Hostnames, port numbers, time zones, character sets, etc. are often sent "
+"without informing the user.\n"
+"As such, designing the network protocol specifically with anonymity in "
+"mind\n"
+"can avoid compromising user identities."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:41
+msgid ""
+"There are also efficiency considerations to review when determining how "
+"to \n"
+"interact on top of I2P.  The streaming library and things built on top of"
+" it\n"
+"operate with handshakes similar to TCP, while the core I2P protocols "
+"(I2NP and I2CP)\n"
+"are strictly message based (like UDP or in some instances raw IP).  The "
+"important\n"
+"distinction is that with I2P, communication is operating over a long fat "
+"network - \n"
+"each end to end message will have nontrivial latencies, but may contain "
+"payloads \n"
+"of up to 32KB.  An application that needs a simple request and response "
+"can get rid\n"
+"of any state and drop the latency incurred by the startup and teardown "
+"handshakes\n"
+"by using (best effort) datagrams without having to worry about MTU "
+"detection or \n"
+"fragmentation of messages under 32KB."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:55
+#: i2p2www/pages/site/get-involved/develop/applications.html:57
+msgid ""
+"Creating a server-client connection using I2PTunnel only requires "
+"creating a single tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:57
+msgid "Figure 1:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:62
+#: i2p2www/pages/site/get-involved/develop/applications.html:64
+msgid ""
+"Setting up connections for a peer-to-peer applications requires a very "
+"large amount of tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:64
+msgid "Figure 2:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:68
+msgid "In summary, a number of reasons to write I2P-specific code:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:72
+msgid ""
+"Creating a large amount of I2PTunnel instances consumes a non-trivial "
+"amount of resources,\n"
+"which is problematic for distributed applications (a new tunnel is "
+"required for each peer)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:76
+msgid ""
+"General network protocols often send a lot of additional data that can be"
+" used to identify users.\n"
+"Programming specifically for I2P allows the creation of a network "
+"protocol\n"
+"that does not leak such information, keeping users anonymous and secure."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:81
+msgid ""
+"Network protocols designed for use on the regular internet can be "
+"inefficient\n"
+"on I2P, which is a network with a much higher latency."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:88
+msgid ""
+"Applications written in Java and accessible/runnable\n"
+"using an HTML interface via the standard webapps/app.war\n"
+"may be considered for inclusion in the i2p distribution."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:96
+msgid "There are a few changes that require adjusting to when using I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:100
+msgid "Destination ~= host+port"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:102
+msgid ""
+"An application running on I2P sends messages from and receives messages "
+"to a\n"
+"unique cryptographically secure end point - a \"destination\".  In TCP or"
+" UDP\n"
+"terms, a destination could (largely) be considered the equivalent of a "
+"hostname\n"
+"plus port number pair, though there are a few differences."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:110
+msgid ""
+"An I2P destination itself is a cryptographic construct - all data sent to"
+" one is \n"
+"encrypted as if there were universal deployment of IPsec with the "
+"(anonymized)\n"
+"location of the end point signed as if there were universal deployment of"
+" DNSSEC."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:115
+msgid ""
+"I2P destinations are mobile identifiers - they can be moved from one I2P "
+"router\n"
+"to another (or with some special software, it can even operate on "
+"multiple routers at\n"
+"once).  This is quite different from the TCP or UDP world where a single "
+"end point (port)\n"
+"must stay on a single host."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:122
+msgid ""
+"I2P destinations are ugly and large - behind the scenes, they contain a "
+"2048bit ElGamal\n"
+"public key for encryption, a 1024bit DSA public key for signing, and a "
+"variable size \n"
+"certificate, which may contain proof of work or blinded data."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:127
+#, python-format
+msgid ""
+"There are existing ways to refer to these large and ugly destinations by "
+"short\n"
+"and pretty names (e.g. \"irc.duck.i2p\"), but at the moment those "
+"techniques do not guarantee\n"
+"globally uniqueness (since they're stored locally at each person's "
+"machine as \"hosts.txt\")\n"
+"and the current mechanism is not especially scalable nor secure (updates "
+"to one host file are\n"
+"manually managed within Monotone, and as such, anyone with commit rights "
+"on the repository can\n"
+"change the destinations).  There may be some secure, human readable, "
+"scalable, and globally \n"
+"unique, naming system some day, but applications shouldn't depend upon it"
+" being in place,\n"
+"since there are those who don't think such a beast is possible.\n"
+"Further information on the naming system is "
+"available."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:141
+msgid "Anonymity and confidentiality"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:143
+msgid ""
+"A useful thing to remember is that I2P has transparent end to end "
+"encryption\n"
+"and authentication for all data passed over the network - if Bob sends to"
+" Alice's destination,\n"
+"only Alice's destination can receive it, and if Bob is using the "
+"datagrams or streaming \n"
+"library, Alice knows for certain that Bob's destination is the one who "
+"sent the data."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:150
+msgid ""
+"Of course, another useful thing to remember is that I2P transparently "
+"anonymizes the\n"
+"data sent between Alice and Bob, but it does nothing to anonymize the "
+"content of what they\n"
+"send.  For instance, if Alice sends Bob a form with her full name, "
+"government IDs, and \n"
+"credit card numbers, there is nothing I2P can do.  As such, protocols and"
+" applications should \n"
+"keep in mind what information they are trying to protect and what "
+"information they are willing\n"
+"to expose."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:159
+msgid "I2P datagrams can be up to 32KB"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:161
+msgid ""
+"Applications that use I2P datagrams (either raw or repliable ones) can "
+"essentially be thought\n"
+"of in terms of UDP - the datagrams are unordered, best effort, and "
+"connectionless - but unlike\n"
+"UDP, applications don't need to worry about MTU detection and can simply "
+"fire off 32KB datagrams\n"
+"(31KB when using the repliable kind).  For many applications, 32KB of "
+"data is sufficient for an\n"
+"entire request or response, allowing them to transparently operate in I2P"
+" as a UDP-like \n"
+"application without having to write fragmentation, resends, etc."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:172
+msgid ""
+"There are several means of sending data over I2P, each with their own "
+"pros and cons.\n"
+"The streaming lib is the recommended interface, used by the majority of "
+"I2P applications."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:177
+msgid "Streaming Lib"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:178
+#, python-format
+msgid ""
+"The full streaming library is now the "
+"standard\n"
+"interface. It allows programming using TCP-like sockets, as explained in "
+"the Streaming development guide."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:184
+#, python-format
+msgid ""
+"BOB is the Basic Open Bridge,\n"
+"allowing an application in any language to make streaming connections \n"
+"to and from I2P. At this point in time it lacks UDP support, but UDP "
+"support\n"
+"is planned in the near future. BOB also contains several tools, such as \n"
+"destination key generation, and verification that an address conforms to"
+" \n"
+"I2P specifications. Up to date info and applications that use BOB can be"
+" \n"
+"found at this eepsite."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:197
+msgid "SAM is not recommended. SAM V2 is okay, SAM V3 is beta."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:198
+#, python-format
+msgid ""
+"SAM is the Simple Anonymous Messaging protocol, "
+"allowing an\n"
+"application written in any language to talk to a SAM bridge through a "
+"plain TCP socket and have\n"
+"that bridge multiplex all of its I2P traffic, transparently coordinating "
+"the encryption/decryption\n"
+"and event based handling.  SAM supports three styles of operation:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:205
+msgid ""
+"streams, for when Alice and Bob want to send data to each other reliably "
+"and in order"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:208
+msgid ""
+"repliable datagrams, for when Alice wants to send Bob a message that Bob "
+"can reply to"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:211
+msgid ""
+"raw datagrams, for when Alice wants to squeeze the most bandwidth and "
+"performance as possible,\n"
+"and Bob doesn't care whether the data's sender is authenticated or not "
+"(e.g. the data transferred\n"
+"is self authenticating)"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:217
+msgid ""
+"SAM V3 aims at the same goal as SAM and SAM V2, but does not require\n"
+"multiplexing/demultiplexing. Each I2P stream is handled by its own socket"
+" between the application\n"
+"and the SAM bridge. Besides, datagrams can be sent and received by the "
+"application through datagram\n"
+"communications with the SAM bridge."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:224
+#, python-format
+msgid ""
+"SAM V2 is a new version used by imule\n"
+"that fixes some of the problems in SAM.\n"
+"
            \n"
+"SAM V3 is used by imule since version 1.4.0."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:232
+msgid ""
+"The I2PTunnel application allows applications to build specific TCP-like "
+"tunnels to peers \n"
+"by creating either I2PTunnel 'client' applications (which listen on a "
+"specific port and connect\n"
+"to a specific I2P destination whenever a socket to that port is opened) "
+"or I2PTunnel 'server'\n"
+"applications (which listen to a specific I2P destination and whenever it "
+"gets a new I2P \n"
+"connection it outproxies to a specific TCP host/port).  These streams are"
+" 8bit clean and are\n"
+"authenticated and secured through the same streaming library that SAM "
+"uses, but there is a \n"
+"nontrivial overhead involved with creating multiple unique I2PTunnel "
+"instances, since each have\n"
+"their own unique I2P destination and their own set of tunnels, keys, etc."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:244
+#: i2p2www/pages/site/get-involved/develop/applications.html:251
+#: i2p2www/pages/site/get-involved/develop/applications.html:262
+msgid "Not recommended"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:245
+msgid ""
+"It was possible to write I2P applications in Java using the ministreaming"
+" library.\n"
+"However, the Streaming library has superceded this, and provides better "
+"functionality."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:252
+#, python-format
+msgid ""
+"The Datagram library allows sending UDP-"
+"like packets.\n"
+"It's possible to use:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:257
+msgid "Repliable datagrams"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:258
+msgid "Raw datagrams"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:263
+#, python-format
+msgid ""
+"I2CP itself is a language independent protocol, "
+"but to implement an I2CP library \n"
+"in something other than Java there is a significant amount of code to be "
+"written (encryption routines, \n"
+"object marshalling, asynchronous message handling, etc).  While someone "
+"could write an I2CP library in \n"
+"C or something else, it would most likely be more useful to use the C SAM"
+" library instead."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:270
+msgid "Web Applications"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:271
+msgid ""
+"I2P comes with the Jetty webserver, and configuring to use the Apache "
+"server instead is straightforward.\n"
+"Any standard web app technology should work."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:277
+msgid ""
+"Developing using I2P requires a working I2P installation and a "
+"development environment of your own choice.\n"
+"If you are using Java, you can start development with the streaming library or datagram library.\n"
+"Using another programming language, SAM or BOB can be used."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:283
+msgid "Developing with the streaming library"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:285
+msgid ""
+"Development using the streaming library requires the following libraries "
+"in your classpath:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:289
+msgid "the streaming library itself."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:290
+msgid "the ministreaming library is used as the base for the streaming library."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:291
+msgid ""
+"some standard I2P classes (like the Destination class) are very "
+"convenient when developing."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:294
+msgid ""
+"Network communication requires the usage of I2P network sockets.\n"
+"To demonstrate this, we will create an application where a client can "
+"send text messages to a server,\n"
+"who will print the messages and send them back to the client. In other "
+"words, the server will function as an echo."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:299
+msgid ""
+"We will start by initializing the server application. This requires "
+"getting an I2PSocketManager\n"
+"and creating an I2PServerSocket.\n"
+"In addition, we will ask the I2PSocketManager for an I2PSession, so we "
+"can find out the Destination we use."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:327
+msgid "Code example 1: initializing the server application."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:329
+msgid ""
+"Once we have an I2PServerSocket, we can create I2PSocket instances to "
+"accept connections from clients.\n"
+"In this example, we will create a single I2PSocket instance, that can "
+"only handle one client at a time.\n"
+"A real server would have to be able to handle multiple clients.\n"
+"To do this, multiple I2PSocket instances would have to be created, each "
+"in separate threads.\n"
+"Once we have created the I2PSocket instance, we read data, print it and "
+"send it back to the client.\n"
+"The bold code is the new code we add."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:415
+msgid "Code example 2: accepting connections from clients and handling messages."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:419
+msgid ""
+"When you run the above server code, it should print something like this "
+"(but without the line endings, it should just be\n"
+"one huge block of characters):"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:433
+msgid ""
+"This is the base64-representation of the server Destination. The client "
+"will need this string to reach the server."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:437
+msgid ""
+"Now, we will create the client application. Again, a number of steps are "
+"required for initialization.\n"
+"Again, we will need to start by getting an I2PSocketManager.\n"
+"We won't use an I2PSession and an I2PServerSocket this time.\n"
+"Instead, we will use the server Destination string to start our "
+"connection.\n"
+"We will ask the user for the Destination string, and create an I2PSocket "
+"using this string.\n"
+"Once we have an I2PSocket, we can start sending and receiving data to and"
+" from the server."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:519
+msgid ""
+"Code example 3: starting the client and connecting it to the server "
+"application."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:521
+msgid ""
+"Finally, you can run both the server and the client application.\n"
+"First, start the server application. It will print a Destination string "
+"(like shown above).\n"
+"Next, start the client application. When it requests a Destination "
+"string, you can enter the string printed by the server.\n"
+"The client will then send 'Hello I2P!' (along with a newline) to the "
+"server, who will print the message and send it back to the client."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:527
+msgid "Congratulations, you have successfully communicated over I2P!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:531
+msgid "Existing Applications in Development"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:532
+msgid "Contact us if you would like to help."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:549
+msgid "Application Ideas"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:551
+msgid "NNTP server - there have been some in the past, none at the moment"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:554
+msgid ""
+"Jabber server - there have been some in the past, and there is one at the"
+" moment, with access to the public internet"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:557
+msgid "PGP Key server and/or proxy"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:560
+msgid ""
+"Download manager / eepget scheduler -\n"
+"We use eepget to fetch lots of things reliably over i2p, and there's "
+"already an\n"
+"implementation of a sequential download manager "
+"(net.i2p.util.EepGetScheduler),\n"
+"but there isn't any sort of user interface to it.  A web based UI would "
+"be\n"
+"great."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:567
+#, python-format
+msgid ""
+"Content Distribution / DHT applications - help out with feedspace,\n"
+"port dijjer, look for alternatives"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:571
+msgid "Help out with Syndie development"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:574
+msgid ""
+"Web-based applications - The sky is the limit for hosting web-server-"
+"based\n"
+"applications such as blogs, pastebins, storage, tracking, feeds, etc.\n"
+"Any web or CGI technology such as Perl, PHP, Python, or Ruby will work."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:579
+msgid ""
+"Resurrect some old apps - in the i2p source package -\n"
+"bogobot, pants, proxyscript, q, stasher, socks proxy, i2ping"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:2
+msgid "I2P Developer's MTN Keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:4
+msgid "MTN Keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:5
+msgid ""
+"Monotone servers used by the I2P project require two types of keys to be "
+"used."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:9
+msgid ""
+"Commit Keys to sign changes checked-in to the "
+"respository; and"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:10
+msgid ""
+"Transport Keys to push changes to remote "
+"servers."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:13
+#, python-format
+msgid ""
+"Everyone that uses Monotone to checkout the I2P codebase will need to\n"
+"import the\n"
+"developer commit keys, but only Monotone \n"
+"server operators will need to import the transport keys."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:20
+msgid "Developer Commit keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:232
+msgid "Developer Transport Keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:233
+#, python-format
+msgid ""
+"Note: Transport keys are only needed for setting up a\n"
+"Monotone server."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/license-agreements.html:2
+msgid "License Agreements"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/license-agreements.html:5
+#, python-format
+msgid "For more information see the licenses page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/license-agreements.html:8
+msgid ""
+"Following is a monotonerc file defining the current trust list.\n"
+"Developers must use this file in ~/.monotone/monotonerc or\n"
+"_MTN/montonerc in their i2p.i2p workspace."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/license-agreements.html:17
+msgid "Agreements"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:4
+msgid "I2P Software Licenses"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:5
+#, python-format
+msgid ""
+"As required by our\n"
+"threat model (among other reasons), the \n"
+"software developed to support the anonymous communication \n"
+"network we call I2P must be freely available, open source, \n"
+"and user modifiable.  To meet these criteria, we make use of\n"
+"a variety of legal and software engineering techniques so\n"
+"as to remove as many barriers to entry for those considering\n"
+"making use of or contributing to the I2P effort."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:16
+msgid ""
+"While the information below may be more confusing than just simply \n"
+"stating \"I2P is BSD\", \"I2P is GPL\", or \"I2P is public domain\",\n"
+"the short answer to the question \"How is I2P licensed?\" is this:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:22
+msgid "All software bundled in the I2P distributions will allow:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:24
+msgid "use without fee"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:25
+msgid ""
+"use with no restrictions on how, when, where, why, or by whom is running "
+"it"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:26
+msgid "access to the source code without fee"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:27
+msgid "modifications to the source"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:30
+msgid ""
+"Most of the software guarantees much more - the ability of anyone "
+"to \n"
+"distribute the modified source however they choose.  However, not all of "
+"the \n"
+"software bundled provides this freedom - the GPL restricts the ability of"
+" \n"
+"developers who wish to integrate I2P with their own applications that are"
+" not \n"
+"themselves open source applications.  While we applaud the noble goals of"
+" \n"
+"increasing the resources in the commons, I2P is best served by removing "
+"any\n"
+"barriers that stand in the way of its adoption - if a developer "
+"considering whether\n"
+"they can integrate I2P with their application has to stop and check with "
+"their lawyer,\n"
+"or conduct a code audit to make sure their own source can be released as "
+"GPL-compatible,\n"
+"we lose out."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:43
+msgid "Component licenses"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:44
+msgid ""
+"The I2P distribution contains several resources, reflecting the "
+"partitioning of \n"
+"the source code into components.  Each component has its own license, "
+"which all \n"
+"developers who contribute to it agree to - either by explicitly declaring"
+" the release\n"
+"of code committed under a license compatible with that component, or by "
+"implicitly\n"
+"releasing the code committed under the component's primary license.  Each"
+" of these \n"
+"components has a lead developer who has the final say as to what license "
+"is compatible\n"
+"with the component's primary license, and the I2P project manager has the"
+" final say as\n"
+"to what licenses meet the above four guarantees for inclusion in the I2P "
+"distribution."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:57
+msgid "Component"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:58
+msgid "Source path"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:59
+msgid "Resource"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:60
+msgid "Primary license"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:61
+msgid "Alternate licenses"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:62
+msgid "Lead developer"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:271
+msgid "GPL + java exception"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:272
+#, python-format
+msgid ""
+"While it may be redundant, just for clarity the\n"
+"GPL'ed code included within\n"
+"I2PTunnel and other apps must be released under the GPL with an "
+"additional \"exception\"\n"
+"explicitly authorizing the use of Java's standard libraries:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:288
+msgid ""
+"All source code under each component will by default be licensed under "
+"the\n"
+"primary license, unless marked otherwise in the code.  All of the above "
+"is\n"
+"summary of the license terms - please see the specific license for the "
+"component\n"
+"or source code in question for authoritative terms.  Component source "
+"locations and\n"
+"resource packaging may be changed if the repository is reorganized."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:296
+msgid "Commit privileges"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:297
+#, python-format
+msgid ""
+"Developers may push changes to a distributed monotone repository if you\n"
+"receive permission from the person running that repository.\n"
+"See the Monotone Page for details."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:303
+msgid ""
+"However, to have changes included in a release, developers\n"
+"must be trusted by the release manager (currently zzz).\n"
+"In addition, they must explicitly agree with the above terms to be "
+"trusted.\n"
+"That means that they must send one of the release managers a signed "
+"message affirming that:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:310
+msgid ""
+"Unless marked otherwise, all code I commit is implicitly licensed under\n"
+"the component's primary license"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:314
+msgid ""
+"If specified in the source, the code may be explicitly licensed under one"
+"\n"
+"of the component's alternate licenses"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:318
+msgid ""
+"I have the right to release the code I commit under the terms I\n"
+"am committing it"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:324
+#, python-format
+msgid ""
+"If anyone is aware of any instances where the above conditions are not "
+"met,\n"
+"please contact the component lead and/or an I2P release manager with "
+"further\n"
+"information.\n"
+"See developers' license agreements."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/release-signing-key.html:2
+msgid "Release Signing Key"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/release-signing-key.html:4
+msgid "Releases 0.7.6 and later are signed by zzz. His public key is:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/release-signing-key.html:40
+msgid ""
+"Releases 0.6.1.31 through 0.7.5 were signed by Complication. His public "
+"key is:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:2
+msgid "Signed Developer Keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:4
+msgid ""
+"Keys for zzz, Complication and welterde are provided clearsigned. The key"
+" for jrandom must be\n"
+"verified differently, since he's away, and only left a binary detached\n"
+"signature for his key."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:10
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:16
+msgid "Monotone keys for zzz"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:11
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:47
+msgid "Monotone keys for welterde"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:12
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:79
+msgid "Monotone keys for Complication"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:13
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:114
+msgid "Monotone keys for jrandom"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:17
+msgid ""
+"Tip: To find zzz's GPG key, on his eepsite locate the key "
+"`0xA76E0BED`, with\n"
+"the name `zzz@mail.i2p` and the fingerprint `4456 EBBE C805 63FE 57E6 "
+"B310 4155\n"
+"76BA A76E 0BED`."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:49
+msgid ""
+"Tip: To find welterde's GPG key, on public keyservers locate the "
+"key\n"
+"`0x62E011A1`, with the name `welterde@arcor.de` and the fingerprint `6720"
+" FD81\n"
+"3872 6DFC 6016 64D1 EBBC 0374 62E0 11A1`."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:81
+msgid ""
+"Tip: To find Complication's GPG key, on his eepsite locate the key"
+"\n"
+"`0x79FCCE33`, with the name `complication@mail.i2p` and the fingerprint "
+"`73CF\n"
+"2862 87A7 E7D2 19FF DB66 FA1D FC6B 79FC CE33`."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:116
+msgid ""
+"Tip: To find jrandom's GPG key for Syndie releases, on public "
+"keyservers locate\n"
+"the key `0x393F2DF9`, with the name `syndie-dist-key@i2p.net` and the\n"
+"fingerprint `AE89 D080 0E85 72F0 B777 B2ED C2FA 68C0 393F 2DF9`."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:122
+msgid ""
+"Jrandom had to leave unexpectedly in the end of 2007. His commit key was\n"
+"deployed in the Syndie Monotone repository, in a file named `mtn-"
+"committers`.\n"
+"That file also had a GPG signature, `mtn-committers.sig`, but it was a "
+"binary\n"
+"detached signature. I am going to supply both files in GPG ASCII-armoured"
+" form\n"
+"below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:130
+msgid ""
+"First, the file `mtn-committers` containing jrandom's Monotone key. Save "
+"as\n"
+"`mtn-committers.asc` and unpack it using `gpg --output mtn-committers "
+"--dearmor\n"
+"mtn-committers.asc`:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:151
+msgid ""
+"Now the file `mtn-committers.sig`, containing the GPG signature. Save as\n"
+"`mtn-committers.sig.asc` and unpack it using `gpg --output mtn-"
+"committers.sig\n"
+"--dearmor mtn-committers.sig.asc`. Use it to verify the above supplied\n"
+"`mtn-committers` file:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:170
+#, python-format
+msgid ""
+"Some of the developers have included their Monotone keys in their signed license agreement."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:2
+msgid "Developer Guidelines and Coding Style"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:4
+#, python-format
+msgid "Read the new developers guide first."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:8
+msgid "Basic Guidelines and Coding Style"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:10
+msgid ""
+"Most of the following should be common sense for anybody who has worked "
+"on open source or in a commercial\n"
+"programming envrionment.\n"
+"The following applies mostly to the main development branch i2p.i2p.\n"
+"Guidelines for other branches, plugins, and external apps may be "
+"substantially different;\n"
+"check with the appropriate developer for guidance."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:18
+msgid "Community"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:20
+msgid ""
+"Please don't just \"write code\". If you can, participate in other "
+"development activities, including:\n"
+"development discussions and support on IRC, zzz.i2p, and forum.i2p; "
+"testing;\n"
+"bug reporting and responses; documentation; code reviews; etc."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:25
+msgid ""
+"Active devs should be available periodically on IRC #i2p-dev.\n"
+"Be aware of the current release cycle.\n"
+"Adhere to release milestones such as feature freeze, tag freeze, and\n"
+"the checkin deadline for a release."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:35
+msgid ""
+"Have a basic understanding of distributed source control systems, even if"
+" you haven't\n"
+"used monotone before. Ask for help if you need it.\n"
+"Once pushed, checkins are forever, there is no undo. Please be careful.\n"
+"If you have not used monotone before, start with baby steps.\n"
+"Check in some small changes and see how it goes."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:42
+msgid ""
+"Test your changes before checking them in.\n"
+"If you prefer the checkin-before-test development model,\n"
+"use your own development branch (e.g. i2p.i2p.yourname.test)\n"
+"and propagate back to i2p.i2p once it is working well.\n"
+"Do not break the build. Do not cause regressions.\n"
+"In case you do (it happens), please do not vanish for a long period after"
+"\n"
+"you push your change."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:51
+msgid ""
+"If your change is non-trivial, or you want people to test it and need "
+"good test reports\n"
+"to know whether your change was tested or not, add a checkin comment to "
+"history.txt\n"
+"and increment the build revision in RouterVersion.java."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:56
+msgid ""
+"Ensure that you have the latest monotonerc file in _MTN.\n"
+"Do not check in on top of untrusted revisions."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:60
+msgid ""
+"Ensure that you pull the latest revision before you check in.\n"
+"If you inadvertently diverge, merge and push as soon as possible.\n"
+"Don't routinely make others merge for you.\n"
+"Yes, we know that monotone says you should push and then merge,\n"
+"but in our experience, in-workspace merge works just as well as in-"
+"database merge,\n"
+"without creating a merge revision."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:68
+msgid ""
+"Do not check in major changes into the main i2p.i2p branch late in the "
+"release cycle.\n"
+"If a project will take you more than a couple days, create your own "
+"branch in monotone\n"
+"and do the development there so you do not block releases."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:75
+msgid "Coding Style"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:77
+msgid ""
+"Coding style throughout most of the code is 4-spaces for indentation. Do "
+"not use tabs.\n"
+"Do not reformat code. If your IDE or editor wants to reformat everything,"
+" get control of it.\n"
+"Yes, we know 4 spaces is a pain, but perhaps you can configure your "
+"editor appropriately.\n"
+"In some places, the coding style is different.\n"
+"Use common sense. Emulate the style in the file you are modifying."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:84
+msgid ""
+"New classes and methods require at least brief javadocs. Add @since "
+"release-number."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:87
+msgid ""
+"Classes in core/ (i2p.jar) and portions of i2ptunnel are part of our "
+"official API.\n"
+"There are several out-of-tree plugins and other applications that rely on"
+" this API.\n"
+"Be careful not to make any changes that break compatibility.\n"
+"Don't add methods to the API unless they are of general utility.\n"
+"Javadocs for API methods should be clear and complete.\n"
+"If you add or change the API, also update the documentation on the "
+"website (i2p.www branch)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:95
+msgid ""
+"Tag strings for translation where appropriate.\n"
+"Don't change existing tagged strings unless really necessary, as it will "
+"break existing translations.\n"
+"Do not add or change tagged strings after the \"tag freeze\" in the "
+"release cycle so that\n"
+"translators have a chance to update before the release."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:101
+msgid ""
+"Use generics and concurrent classes where possible. I2P is a highly "
+"multi-threaded application."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:104
+msgid ""
+"We require Java 6 to build but only Java 5 to run I2P.\n"
+"Do not use Java 6 classes or methods without handling the class not found"
+" exceptions\n"
+"and providing alternate Java 5 code. See classes in net.i2p.util for "
+"examples."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:109
+msgid ""
+"Explicitly convert between primitive types and classes;\n"
+"don't rely on autoboxing/unboxing."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:117
+msgid ""
+"Only check in code that you wrote yourself.\n"
+"Before checking in any code or library jars from other sources,\n"
+"justify why it is necessary,\n"
+"verify the license is compatible,\n"
+"and obtain approval from the lead developer."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:124
+msgid ""
+"For any images checked in from external sources,\n"
+"it is your responsibility to first verify the license is compatible.\n"
+"Include the license and source information in the checkin comment."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:131
+msgid "Bugs"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:133
+#, python-format
+msgid ""
+"Managing Trac tickets is everybody's job, please help.\n"
+"Monitor %(trac)s for tickets you have been assigned or can help with.\n"
+"Assign, categorize, comment on, fix, or close tickets if you can."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:138
+msgid ""
+"Close a ticket when you think you've fixed it.\n"
+"We don't have a test department to verify and close tickets.\n"
+"If you arent sure you fixed it, close it and add a note saying\n"
+"\"I think I fixed it, please test and reopen if it's still broken\".\n"
+"Add a comment with the dev build number or revision and set\n"
+"the milestone to the next release."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:4
+msgid ""
+"The main I2P development branch (i2p.i2p) has been set up to"
+" enable developers to easily set up two of the commonly-used IDEs for "
+"Java development: Eclipse and NetBeans."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:10
+msgid ""
+"The main I2P development branches (i2p.i2p and branches from"
+" it) contain .project and .classpath Eclipse files, to enable the branch "
+"to be easily set up in Eclipse."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:16
+msgid ""
+"Check out the I2P branch into some directory (e.g. "
+"$HOME/dev/i2p.i2p)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:20
+msgid ""
+"Open Eclipse and create a new Workspace, based in the directory that the "
+"I2P branch was checked out to."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:24
+msgid ""
+"Select \"File - Import...\" and then under \"General\" select \"Existing "
+"Projects into Workspace\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:28
+msgid ""
+"For \"Select root directory:\" choose the directory that the I2P branch "
+"was checked out to."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:32
+msgid "If necessary, click \"Refresh\" to refresh the list of projects."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:36
+msgid "Select every project in the list, and click \"Finish\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:40
+msgid ""
+"Done! Your workspace should now contain all projects within the I2P "
+"branch, and their build dependencies should be correctly set up."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:48
+msgid ""
+"The main I2P development branches (i2p.i2p and branches from"
+" it) contain NetBeans project files."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:9
+msgid "Operating a Monotone client"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:11
+#: i2p2www/pages/site/get-involved/guides/monotone.html:63
+msgid "Generating Monotone keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:12
+msgid "Trust and initializing your repository"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:13
+#: i2p2www/pages/site/get-involved/guides/monotone.html:196
+msgid "Obtaining and deploying developers' keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:14
+#: i2p2www/pages/site/get-involved/guides/monotone.html:227
+msgid "Setting up trust evaluation hooks"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:15
+#: i2p2www/pages/site/get-involved/guides/monotone.html:268
+msgid ""
+"Pulling the i2p.i2p, i2p.www and "
+"i2p.syndie branches"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:16
+#: i2p2www/pages/site/get-involved/guides/monotone.html:308
+msgid "Verifying that trust evaluation works"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:17
+#: i2p2www/pages/site/get-involved/guides/monotone.html:357
+msgid "Checking out a working copy of the latest version"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:18
+#: i2p2www/pages/site/get-involved/guides/monotone.html:384
+msgid "Updating your working copy to the latest version"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:22
+#: i2p2www/pages/site/get-involved/guides/monotone.html:414
+msgid "Operating a Monotone Server"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:24
+msgid "Obtaining and deploying developers’ transport keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:25
+#: i2p2www/pages/site/get-involved/guides/monotone.html:424
+msgid "Granting push and pull access"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:26
+#: i2p2www/pages/site/get-involved/guides/monotone.html:469
+msgid "Running Monotone in server mode"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:27
+#: i2p2www/pages/site/get-involved/guides/monotone.html:494
+msgid "Differences under Debian GNU/Linux"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:34
+#, python-format
+msgid ""
+"This is a revised version of Complication's original\n"
+"  guide detailing the use of Monotone in I2P development.\n"
+"  For basic instructions see the quick-start "
+"guide."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:42
+#, python-format
+msgid ""
+"I2P has a distributed development model. The source code is replicated "
+"across\n"
+"  independently administered Monotone (\"MTN\") repositories.\n"
+"  Developers with commit rights are able to push their changes to the "
+"repository\n"
+"  (a license agreement needs to be "
+"signed\n"
+"  before commit rights are granted)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:52
+msgid ""
+"Some of Monotone's noteworthy qualities are: distributed\n"
+"  version control, cryptographic authentication, access control, its "
+"small size, having few\n"
+"  dependencies, storage of projects in a compressed SQLite database file,"
+" and\n"
+"  having the ability to resume interrupted synchronization attempts."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:61
+msgid "Operating a Monotone Client"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:66
+msgid ""
+"A transport key grants you the ability to push your changes to a Monotone"
+" repository server.\n"
+"  In order to commit code into Monotone (in essence signing your code), a"
+" commit key is also needed.\n"
+"  None of the public Monotone servers on I2P currently require a key in "
+"order to read (or pull) the source code."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:74
+msgid ""
+"Without a transport key, one cannot:\n"
+"  
              \n"
+"    
            • pull code from a server which doesn't allow global read "
+"access
              • \n"
+"    
            • push code to any server
              • \n"
+"    
            • run a Monotone server
              • \n"
+"  
            "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:85
+msgid ""
+"Without a commit key, one cannot:\n"
+"  
              \n"
+"    
            • commit any code
              • \n"
+"  
            "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:94
+msgid ""
+"If you only intend to retrieve code from MTN, feel free to skip to the\n"
+"  next section. "
+"If you want\n"
+"  to generate keys, read the following."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:102
+msgid ""
+"By convention keys are named like an e-mail addresses, but a "
+"corresponding e-mail\n"
+"  address does not need to exist. For example, your keys might be named:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:113
+msgid ""
+"Monotone stores keys under $HOME/.monotone/keys in "
+"text files which\n"
+"  are named identically to the keys. For example:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:123
+msgid ""
+"To generate transport and commit keys, enter the following commands at a "
+"prompt:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:133
+msgid ""
+"Monotone will prompt you for a password to protect your keys. You are "
+"very strongly encouraged to set a password\n"
+"  for the commit key. Many users will leave an empty password for the "
+"transport key, especially those running a\n"
+"  Monotone server."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:141
+msgid "Trust, and initializing your repository"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:145
+msgid ""
+"Monotone's security model helps to ensure that nobody can easily "
+"impersonate a developer without\n"
+"  it being noticed. Since developers can make mistakes and become "
+"compromised,only manual review can\n"
+"  ensure quality of code. Monotone's trust model will ensure that you "
+"read the right diffs. It does\n"
+"  not replace reading diffs."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:155
+msgid ""
+"A Monotone repository is a single file (a compressed SQLite database) "
+"which contains all of the project's source code and history."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:161
+msgid ""
+"After importing the "
+"developers' keys into Monotone and\n"
+"  setting up trust "
+"evaluation hooks,\n"
+"  Monotone will prevent untrusted code from being checked out into your "
+"workspace.\n"
+"  There are commands available to clean untrusted code from your "
+"workspace but in practice they've not been\n"
+"  needed due to the push access policies in place."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:171
+msgid ""
+"A repository can hold many branches. For example, our repository holds "
+"the\n"
+"  following main branches:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:176
+msgid "The I2P router and associated programs"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:177
+msgid "The I2P project website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:178
+msgid "Syndie, a distributed forums tool"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:183
+msgid ""
+"By convention, the I2P Monotone repository is named i2p.mtn."
+" Before pulling\n"
+"  source code from servers, a database for your repository will need to "
+"be initialized.\n"
+"  To initialize your local repository, change into the directory that you"
+" want the\n"
+"  i2p.mtn file and branch directories to be stored and issue"
+" the following\n"
+"  command:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:199
+msgid ""
+"Keys which developers use to commit code are essential for trust "
+"evaluation in\n"
+"  Monotone. The other developers' transport keys are only required for "
+"Monotone server operators.\n"
+"  "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:206
+#, python-format
+msgid ""
+"Developers' commit keys are provided GPG-signed on another page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:212
+#, python-format
+msgid ""
+"To import developers' keys after verifying their authenticity, copy all of the keys into a new\n"
+"  file. Create this file (e.g. keys.txt) in the same "
+"directory where i2p.mtn is located. Import the keys with the"
+" command:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:222
+msgid ""
+"Note: Never add keys to "
+"$HOME/.monotone/keys manually."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:230
+msgid ""
+"The default Monotone trust policy is way too lax for our requirements: "
+"every comitter is trusted by default.\n"
+"  That is not acceptable for I2P development."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:237
+msgid ""
+"Change into the directory $HOME/.monotone and open "
+"the file\n"
+"  monotonerc with a text editor. Copy and paste the "
+"following two functions into this file:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:246
+msgid ""
+"The first function determines an intersection between two sets, in our "
+"case a\n"
+"  revision's signers and trusted signers."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:253
+msgid ""
+"The second function determines trust in a given revision, by calling the "
+"first\n"
+"  function with \"signers\" and \"trusted\" as arguments. If the "
+"intersection is\n"
+"  null, the revision is not trusted. If the intersection is not empty, "
+"the\n"
+"  revision is trusted. Otherwise, the revision is not trusted."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:262
+msgid ""
+"More information about Trust Evauluation Hooks can be found in the official Monotone "
+"documentation."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:271
+msgid ""
+"Enter the directory where you initialized i2p.mtn. Depending "
+"on whether you\n"
+"  want only I2P sources, or also sources for the I2P website and Syndie, "
+"you can\n"
+"  perform the pull operation in different ways."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:279
+msgid "If you only want I2P sources:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:288
+msgid "If you want all branches:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:294
+msgid ""
+"If the transfer aborts before completing sucessfully, simply repeating "
+"the pull command will resume the transfer."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:300
+msgid ""
+"Pulling in the above examples is done anonymously by specifying an empty "
+"transport key.\n"
+"  If everyone pulls anonymously it will be harder for an attacker who "
+"gains control of the server\n"
+"  to selectively provide some people with tampered data."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:311
+msgid "To verify that trust evaluation works:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:315
+msgid "Make a backup of your monotonerc file."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:316
+msgid ""
+"Modify monotonerc by setting the trusted_signers "
+"variable in the following way:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:322
+msgid ""
+"With monotonerc configured as above, Monotone will no"
+" longer trust any committers. Confirm this by changing into the\n"
+"directory where i2p.mtn was created and attempt a checkout "
+"of the I2P branch:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:332
+msgid ""
+"A directory named i2p.i2p should not appear. You "
+"should encounter many\n"
+"  error messages like:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:349
+msgid ""
+"If you are satisfied with results, restore the backup of\n"
+"  monotonerc that was created above. If you didn't create a "
+"backup\n"
+"  as advised, re-read Setting up trust evaluation hools."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:360
+msgid ""
+"If you already have a branch checked out, skip to the next\n"
+"  section."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:367
+msgid ""
+"Change into the directory where i2p.mtn is located. Over "
+"there issue:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:376
+msgid ""
+"The checkout should complete without error messages and a directory named"
+"\n"
+"  i2p.i2p should appear in the current directory. "
+"Congratulations! You have\n"
+"  successfully checked out the latest I2P sources, ready to be compiled."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:387
+msgid ""
+"If you haven't done this already, pull fresh code from the server to your"
+" local\n"
+"  Monotone repository. To accomplish this, change into the directory "
+"where\n"
+"  i2p.mtn is located and issue:\n"
+"  
              \n"
+"    
            • $ mtn --db=\"i2p.mtn\" -k \"\" pull 127.0.0.1:8998 "
+"i2p.i2p
              • \n"
+"  
            "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:398
+msgid "Now change into your i2p.i2p directory, and over there issue:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:407
+msgid ""
+"As long as there were no errors…Congratulations! You have "
+"successfully updated to the latest I2P sources. They\n"
+"  should be ready to compile."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:416
+msgid "Obtaining and deploying developers' transport keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:419
+msgid ""
+"As a server operator you may want to grant push access to certain "
+"developers."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:427
+msgid "By default the Monotone server denies all access."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:433
+msgid "To grant pull access to all clients, set the following in"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:445
+msgid ""
+"No one will not be able to push code to your server without permission "
+"being explicitly granted. To grant push access:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:451
+msgid ""
+"Add the name of the user's transport key to\n"
+"$HOME/.monotone/write-permissions, such as\n"
+"
            \n"
+"    zzz-transport@mail.i2p\n"
+"    complication-transport@mail.i2p\n"
+"
            \n"
+"with one key per line."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:462
+msgid ""
+"Import the transport key(s) into your database. The procedure for "
+"importing transport keys is the same as for\n"
+"importing commit keys, which is described in the section Obtaining and deploying "
+"developers' keys."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:472
+msgid ""
+"A separate database should be used for your Monotone server because "
+"monotone will lock the database while it is served to others.\n"
+"  Make a copy of your development database, then start the server with:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:479
+msgid ""
+"If your key is protected with a passphrase, Monotone may request the "
+"passphrase\n"
+"  when the first client connects. You can work around this by connecting "
+"making the first client connection to your server\n"
+"  (or by clearing the password for your transport key)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:487
+msgid ""
+"For your server to be accessible for others over I2P, you will need to "
+"create a\n"
+"  server tunnel for it. Use the \"Standard\" tunnel type and \"Bulk\" "
+"profile."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:497
+msgid ""
+"Debian (amongst other distributions) has integrated Monotone into their\n"
+"  framework of daemons/services. Although Monotone servers can still be "
+"run\n"
+"  \"the ordinary way\" on Debian systems, doing it the \"Debian way\" may"
+" be more straightforward."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:505
+msgid ""
+"Permissions are granted by editing the files\n"
+"  /etc/monotone/read-permissions and\n"
+"  /etc/monotone/write-permissions. You'll also need to edit\n"
+"  /etc/default/monotone to enable monotone to start at boot "
+"or to\n"
+"  customize the host, port, or database location."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:4
+msgid ""
+"\n"
+"So you want to start work on I2P? Great!\n"
+"Here's a quick guide to getting started\n"
+"on contributing to the website or the software, doing development or "
+"creating translations."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:9
+#, python-format
+msgid ""
+"\n"
+"Not quite ready for coding?\n"
+"Try getting involved first."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:16
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:27
+msgid "Basic study"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:17
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:41
+msgid "Getting the I2P code"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:18
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:112
+msgid "Building I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:19
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:133
+msgid "Development ideas"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:20
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:141
+msgid "Making the results available"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:21
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:162
+msgid "Get to know us!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:22
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:168
+msgid "Translations"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:23
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:174
+msgid "Tools"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:29
+msgid ""
+"Basic development on the I2P router or the embedded applications uses "
+"Java as the main development language.\n"
+"If you don't have experience with Java, you can always have a look at Thinking in Java."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:33
+#, python-format
+msgid ""
+"Study the how intro,\n"
+"the other \"how\" documents,\n"
+"the tech intro,\n"
+"and associated documents.\n"
+"These will give you a good overview of how I2P is structured and what "
+"different things it does."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:43
+msgid ""
+"For development on the i2p router or the embedded applications,\n"
+"get the monotone source repository installed - short instructions:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:48
+msgid ""
+"Install monotone.\n"
+"Monotone is a version control system.\n"
+"We use it because it allows us to keep track of who does what changes to "
+"the source code (and for a lot of complicated things, but 'keeping track "
+"of changes' is the basic idea)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:53
+msgid ""
+"Skim over the monotone tutorial,"
+" to make sure you understand the concepts."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:57
+msgid ""
+"If you want to remain anonymous, you need to do an additional step, to "
+"set up a connection to a monotone server over I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:60
+#, python-format
+msgid ""
+"Enable the i2ptunnel client tunnel on port "
+"8998 pointing to mtn.i2p2.i2p."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:64
+msgid ""
+"Pick a directory where you want to put all your I2P files, and create a "
+"monotone database:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:67
+msgid ""
+"Define the trust list by creating ~/.monotone/monotonerc (or"
+" _MTN/monotonerc in the i2p.i2p workspace) with the "
+"following contents:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:72
+#, python-format
+msgid ""
+"Copy and paste the developer's commit keys "
+"into a new file (e.g. keys.txt) in the same directory\n"
+"  that i2p.mtn is in. Import the keys into your database "
+"with 
                  mtn -d i2p.mtn read < keys.txt
            "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:76
+msgid ""
+"Pull the I2P sources to your machine. This may take a long time, "
+"especially if you are doing this over I2P!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:78
+msgid "Anonymously:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:81
+msgid "Non-anonymously:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:83
+msgid ""
+"Alternatively, instead of 'mtn.i2p2.de', you can also download from mtn"
+".i2p-projekt.de."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:90
+msgid ""
+"All the sources are now present on your machine, in the database file. To"
+" make them available in a directory, you need to check them out:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:92
+msgid ""
+"The above command creates a directory i2p.i2p, which contains all of the "
+"I2P sources."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:96
+msgid "Remarks"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:97
+msgid ""
+"\n"
+"To download the website files instead of the I2P source files, use "
+"'i2p.www' instead of 'i2p.i2p'."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:100
+msgid ""
+"The initial pull may take several hours using the tunnel.\n"
+"If it fails after a partial pull, simply rerun it, it will start where it"
+" left off.\n"
+"If you are in a hurry, use the non-anonymous access."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:105
+#, python-format
+msgid ""
+"A full list of branches, including i2p.i2p and i2p.www can be found on viewmtn."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:108
+#, python-format
+msgid ""
+"A long explanation about using monotone is available on the monotone page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:114
+#, python-format
+msgid ""
+"To compile the code, you need the Sun Java Development Kit 6 or higher, "
+"or equivalent JDK\n"
+"(Sun JDK 6 strongly recommended) and\n"
+"Apache ant\n"
+"version 1.7.0 or higher.\n"
+"If you go are working on the main I2P code, you can go into the i2p.i2p "
+"directory and run 'ant' to see the build options."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:122
+msgid ""
+"To build or work on console translations, you need\n"
+"the xgettext, msgfmt, and msgmerge tools from the\n"
+"GNU gettext package."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:128
+#, python-format
+msgid ""
+"For development on new applications,\n"
+"see the application development guide."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:134
+#, python-format
+msgid ""
+"See zzz's TODO lists,\n"
+"this website's TODO list or\n"
+"Trac\n"
+"for ideas."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:143
+#, python-format
+msgid ""
+"See the bottom of the licenses page "
+"for\n"
+"commit privilege requirements. You need these to put code into i2p.i2p "
+"(not required for the website!)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:148
+msgid "Short version of how to generate and use keys if you plan to commit:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:150
+msgid "use an empty passphrase"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:151
+msgid "enter a passphrase"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:152
+#, python-format
+msgid ""
+"send this to a mtn repo operator to get "
+"push privileges"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:153
+#, python-format
+msgid ""
+"send this to a release manager to get "
+"commit privileges - not required for website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:154
+msgid "check in with this key"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:155
+msgid "push with this key"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:157
+#, python-format
+msgid "Long version: see the monotone page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:163
+#, python-format
+msgid ""
+"The developers hang around on IRC. They can be reached on the Freenode "
+"network, OFTC, and on the I2P internal networks. The usual place to look "
+"is #i2p-dev. Join the channel and say hi!\n"
+"We also have additional guidelines for regular"
+" developers."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:169
+#, python-format
+msgid ""
+"Website and router console translators: See the New Translator's Guide\n"
+"for next steps."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:175
+msgid ""
+"I2P is open source software that is mostly developed using open sourced\n"
+"toolkits. The I2P project recently acquired a license for the YourKit "
+"Java\n"
+"Profiler. Open source projects are eligible to receive a free license "
+"provided\n"
+"that YourKit is referenced on the project web site. Please get in touch "
+"if you\n"
+"are interested in profiling the I2P codebase."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:183
+#, python-format
+msgid ""
+"YourKit is kindly supporting open source projects with its full-featured "
+"Java Profiler.\n"
+"YourKit, LLC is the creator of innovative and intelligent tools for "
+"profiling\n"
+"Java and .NET applications. Take a look at YourKit's leading software "
+"products:\n"
+"YourKit Java Profiler and\n"
+"YourKit .NET Profiler."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:4
+msgid "Here's a very quick guide to getting started."
+msgstr "Aquí hay a guia rápida para comenzar."
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:6
+msgid "How to Translate the Website"
+msgstr "Como traducir la página web"
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:8
+#, python-format
+msgid ""
+"Translation of the website is done with .po files. The easiest way by far"
+" to\n"
+"translate the website is to sign up for an account at \n"
+"Transifex and request to join a translation"
+" team. \n"
+"Alternatively it can be done \"the old way\" as outlined below."
+msgstr ""
+"La traducción de las páginas webs se hace con archivos .po. La forma mas facil con diferencia\n"
+"para traducir una página web es crearse una cuenta en \n"
+"Transifex y solicitar unirse aun grupo de traducción. \n"
+"Alternativamente se puede hacer a la \"form antigua \" como se muestra debajo."
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:17
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:82
+msgid "Preparation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:19
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:84
+#, python-format
+msgid ""
+"Come to #i2p-dev on irc and talk to people.\n"
+"Claim the language -\n"
+"To make sure other coworkers don't bump onto the files you are working "
+"on,\n"
+"please update the translation status on this wiki "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:25
+#, python-format
+msgid ""
+"Follow the new developer's guide,\n"
+"Including the installation of monotone,\n"
+"checking out i2p.www branch, and generate your own monotone keys.\n"
+"It is not required that you sign a dev agreement."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:33
+msgid ""
+"Create files:\n"
+"If the file for your language does not exist yet:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:38
+msgid ""
+"Run \"./extract-messages.sh\" to generate a "
+"messages.pot in the base directory.\n"
+"Edit the header of this file, then run \"./init-new-po.sh "
+"locale\" to generate the file\n"
+"i2p2www/translations/locale/LC_MESSAGES/messages.po. "
+"\"mtn add\" this file."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:43
+msgid ""
+"Edit i2p2www/pages/global/lang.html and add a line for your "
+"language (copy an existing line)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:46
+msgid ""
+"Add a flag image file to i2p2www/static/images/flags/ for "
+"the menu (copy from the router)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:52
+msgid ""
+"Edit files:\n"
+"Edit i2p2www/translations/locale/LC_MESSAGES/messages.po.\n"
+"To work with .po files efficiently, you may wish to use POEdit"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:58
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:151
+msgid ""
+"Check in:\n"
+"\"mtn pull\", \"mtn update\". Then check in by "
+"\"mtn ci -k yourname@mail.i2p file1 file2 ...\"\n"
+"This collects the diff info of your changed file into your local repo. "
+"Then \"mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p "
+"i2p.i2p\".\n"
+"This synchronizes your local repo with the repo on the target machine."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:65
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:158
+msgid "Repeat. Check in often. Don't wait until it is perfect."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:72
+msgid "How to Translate the Router Console"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:74
+#, python-format
+msgid ""
+"The easiest way by far to translate the router console is to sign up for "
+"an account at \n"
+"Transifex and request to join a translation"
+" team. \n"
+"Alternatively it can be done \"the old way\" as outlined below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:90
+#, python-format
+msgid ""
+"Follow the new developer's guide,\n"
+"including the installation of monotone and the gettext tools,\n"
+"checking out i2p.i2p branch, and generate your own monotone keys."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:95
+msgid "Generate your own gpg key and sign the dev agreement."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:101
+msgid ""
+"Before starting a console translation, better help translate some i2p "
+"webpages first.\n"
+"At least an i2p homepage in your language would be great."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:106
+msgid ""
+"What to translate:\n"
+"There are about 15 files in the i2p.i2p branch that needs translation:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:132
+msgid ""
+"Where xx is your language code like fr/de/ch/zh/...\n"
+"There may be or may not be files with your lang code. If not, you can "
+"create your own. by copying and renaming other language files you know "
+"with your own lang code."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:137
+msgid ""
+"Create files:\n"
+"If the file for your language does not exist yet, copy another language "
+"file to a new file foo_xx.bar for your language.\n"
+"Then \"mtn add\" the file.\n"
+"After creating a .po file, edit the headers. Then run \"ant "
+"distclean poupdate\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:144
+msgid ""
+"Start to work:\n"
+"Edit the HTML files with any text editor.\n"
+"Be sure not to use an editor in HTML mode that reformats everything.\n"
+"To work with .po files efficiently, you may wish to use POEdit"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:163
+msgid ""
+"As you can see, it's not that difficult.\n"
+"If you have questions about the meaning of the terms in the console, ask "
+"in #i2p-dev on IRC."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:171
+msgid ""
+"Q: Why do I have to install monotone, Java, jsp, learn about .po files "
+"and html, etc.? Why can't I just do a translation and email it to you?"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:175
+msgid "A: Several reasons:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:178
+#, python-format
+msgid ""
+"You might be interested in translating via Transifex. Request to join a "
+"translation team here."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:182
+msgid ""
+"We don't have anybody who has time to accept manual contributions and "
+"submit them to our source control system on your behalf. Even if we did, "
+"it doesn't scale."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:186
+msgid ""
+"Maybe you are thinking translation is a one-step process. It isn't. You "
+"can't do it all at once. You will make mistakes. You need to test it and "
+"tweak it to make it look right before you submit it. Developers "
+"will update or add to the English text, thus requiring a translation "
+"update."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:190
+msgid ""
+"Having translators use a source control system directly provides "
+"authentication and accountablility - we know who is doing what, and we "
+"can track changes, and revert them if necessary."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:194
+msgid ""
+".po files are not difficult. If you don't want to work directly with "
+"them, we recommend 'poedit'."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:198
+msgid ""
+"HTML files are not difficult. Just ignore the html stuff and translate "
+"the text."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:202
+msgid ""
+"Installing and using monotone is not that difficult. Several of the "
+"translators and other contributors to I2P are non-programmers, and they "
+"use monotone regularly. Monotone is simply a source control system, it is"
+" not about \"coding\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:206
+msgid ""
+"Our items to translate are not \"documents\". They are html files and po "
+"files, with a specific format and character encoding (UTF-8) that must be"
+" maintained, and not corrupted by email programs or other methods of "
+"transfer."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:210
+msgid ""
+"We looked at 'pootle' as a front-end for translators. It didn't work "
+"well, needed an administrator, and a pootle-based process would suffer "
+"from a number of the above flaws."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:215
+msgid ""
+"In summary:\n"
+"Yes, we know it is somewhat of a hurdle to get started. It's really the "
+"only possible way we can do it. Give it a try, it really isn't that hard."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:220
+msgid "More Information"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:221
+#, python-format
+msgid ""
+"The #i2p-dev channel on IRC, or the translation forum on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/misc/clt.html:2
+msgid "I2P at CLT and PetCon 2009.1"
+msgstr ""
+
+#: i2p2www/pages/site/misc/clt.html:4
+msgid ""
+"Members of I2P will held a talk at CLT and PetCon 2009.1\n"
+"Two members of the I2P team will be at two forthcoming Linux day and "
+"security convention."
+msgstr ""
+
+#: i2p2www/pages/site/misc/clt.html:9
+#, python-format
+msgid ""
+"On 14th march of 2009 there will be a short talk about general "
+"introduction to I2P at the Chemnitz Linux Tag "
+"2009 hold by echelon.\n"
+"Echelon and some other members of the I2P family will attend to the Linux"
+" meeting the whole two days (Saturday and Sunday) and will be "
+"recognizable as I2P family members. Meet them, ask them your questions, "
+"show them your props! Show your support!"
+msgstr ""
+
+#: i2p2www/pages/site/misc/clt.html:14
+#, python-format
+msgid ""
+"Just 10 days later the Privacy and Data Security "
+"convention in Dresden will take place.\n"
+"Again, echelon will attend this event and hold a short talk about general"
+" introduction to I2P. Another talk about the profiling by the I2P clients"
+" will be held."
+msgstr ""
+
+#: i2p2www/pages/site/misc/cvs.html:4
+#, python-format
+msgid ""
+"The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in a"
+" Monotone repository.\n"
+"For those who aren't very familiar with CVS, there is a\n"
+"fantastic book "
+"on the\n"
+"subject (developers only need to deal with the first chapter - \"An "
+"Overview of\n"
+"CVS\", as subsequent chapters go into some nasty details very few ever "
+"need to\n"
+"touch)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/cvs.html:31
+msgid ""
+"Humorous quote from WinCVS: \"Did you know...  Never experiment with new "
+"CVS\n"
+"commands on your working repository.  Create a sample module instead.\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:2
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:4
+msgid "I2PTunnel migration"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:6
+msgid ""
+"After upgrading to the new architecture, you'll have to do a \n"
+"little work to get your old I2PTunnel-driven servers running.  \n"
+"Lets walk through a simple example.  For an eepsite with the \n"
+"old clientApp configuration, you had:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:16
+msgid "To provide that same functionality on the new web architecture:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:18
+#, python-format
+msgid "Jump to %(url)s"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:19
+msgid "Click on Add new: [Server tunnel] \"GO\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:21
+msgid "For the name: \"eepsite\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:22
+msgid "For the description: \"My eepsite, isn't it pretty?\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:23
+msgid ">For the target host:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:24
+msgid "For the target port:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:25
+msgid ""
+"For the private key file: path to \"myWebPriv.dat\"
             \n"
+"(it is recommended to copy that .dat to your new install dir)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:29
+msgid "Check the \"Start automatically?\" checkbox"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:30
+msgid "Click \"Save\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:32
+msgid "It will come back saying:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:39
+msgid ""
+"That's it!  Creating a new I2PTunnel server works the same way too, "
+"except you\n"
+"don't need to \"copy the old file\", obviously.  Behind the scenes, it is"
+" all driven\n"
+"by the i2ptunnel.config file, which you may modify "
+"externally (if you do,\n"
+"hit \"Reload config\" on the I2PTunnel web page, which will tear down all"
+" of your \n"
+"existing tunnels and rebuild new ones)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:47
+msgid ""
+"Note that you WILL need to wait until your router is integrated\n"
+"into the network before you are able to use the /i2ptunnel/ web\n"
+"interface.  It will say \"Please be patient\" if you try to \n"
+"beforehand, which means that it is still trying to build the \n"
+"necessary I2PTunnel sessions it has been configured to create."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:2
+msgid "I2PTunnel services"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:4
+msgid "Below is quick copy of aum's eepsite deployment guide."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:8
+msgid "1. - Deploy a local server"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:10
+msgid ""
+"For simplicity's sake, we will walk through the setup of a web server; "
+"however, this procedure is the same regardless what protocol of servers "
+"and/or clients you are setting up."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:13
+msgid ""
+"I recommend the Tiny Httpd web server, thttpd, (windows version available"
+" on site) although you can use anything that you feel comfortable with."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:16
+msgid ""
+"Another more robust option would be to use EasyPHP, which is also open "
+"source. It comes with PHP, PHPmyadmin, mySQL, and Apache web server. For "
+"newbies who have no experience setting up and hosting content over "
+"servers, see the hosting page for help."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:19
+msgid ""
+"With the web server you've chosen, configure it to listen on a port of "
+"your choice, and serve its documents from a directory of your choice. For"
+" this example, we'll assume port 10880."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:22
+msgid ""
+"Make sure your firewall is set up so that you cannot receive incoming "
+"connections on this port (which would breach your anonymity)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:25
+msgid ""
+"Test the webserver, by pointing your normal browser (the one with the "
+"\"direct connection\") at http://localhost:10880 (changing the 10880 to the "
+"port number you have chosen)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:28
+msgid ""
+"Once your webserver is working, and you can access it locally with your "
+"browser, continue to the next step."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:33
+msgid "2 - Generate an I2P Destination Keypair"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:35
+msgid ""
+"I2P does not deal in IP addresses. To protect your anonymity, it deals in"
+" unique addresses called destination keys."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:38
+msgid ""
+"A destination key works a lot like a regular IP address, except that it "
+"can't be traced to your IP address or physical location. When users place"
+" a request to speak with you, your gateways are the ones that answer for "
+"you. So the requesting user can only know the IP address of your "
+"gateways. However, gateways don't know your IP address, because gateways "
+"are the last nodes on your tunnels, and you anonymously create tunnels by"
+" way of garlic routing. (So gateways are like puppets that can't see "
+"their masters, and everyone communicates through these puppets)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:41
+msgid ""
+"To deploy a server on I2P, you create a destination keypair. You use the "
+"private key to authenticate your server when connecting it to I2P, and "
+"you make the public key (aka destination key) known publicly, so others "
+"can connect to your server. (indirectly, through your gateways)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:44
+msgid "Each service you run on I2P requires a different keypair."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:47
+msgid ""
+"To generate your keypair, type the command: java -jar "
+"lib/i2ptunnel.jar -nogui -e \"genkeys myWebPrivKey.dat "
+"myWebPubKey.dat\" (all on one line)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:50
+msgid ""
+"In windows, to generate your keypair, type the command: java -jar "
+"lib/i2ptunnel.jar -nogui -e \"genkeys myWebPrivKey.dat "
+"myWebPubKey.dat\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:53
+msgid ""
+"The filenames myWebPrivKey.dat and "
+"myWebPubKey.dat are arbitrary - choose whatever you want "
+"here, as long as you understand your own choices."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:56
+msgid ""
+"We now need to export your public key into base64 format, which you will "
+"share with others."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:59
+msgid ""
+"To convert your myWebPubKey.dat file into shareable base64, type the "
+"command java -cp lib/i2p.jar net.i2p.data.Base64 encode "
+"myWebPubKey.dat > myWebPubKey.txt (all on one line)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:62
+msgid ""
+"This file you have just generated, myWebPubKey.txt, contains"
+" a long base64 string (516 chars at last count), which we call a "
+"destination key. All you need to know about this string for now is that "
+"it allows remote clients to uniquely pinpoint and connect to your server,"
+" just the same way as an IP address allows remote machines to pinpoint "
+"and connect to your machine."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:65
+msgid ""
+"However, in contrast to an IP address, there is no way to trace your "
+"machine's physical location - even though your server can be addressed "
+"via I2P, your IP address cannot be traced or associated with this "
+"destination key."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:70
+msgid "3 - Open a 'Tunnel' from I2P To Your Server"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:72
+msgid ""
+"For clients elsewhere in I2P to be able to access your server, you must "
+"run a 'bridge' or 'tunnel', which takes connections from these clients "
+"and forwards them to your local server."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:75
+msgid ""
+"To activate such a tunnel, type the command java -jar "
+"lib/i2ptunnel.jar -nogui -e \"server localhost 10880 "
+"myWebPrivKey.dat\" (all one line)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:78
+msgid ""
+"If you used different filenames or port number earlier on, change these "
+"accordingly"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:81
+msgid ""
+"Windows users, remember to replace apostrophes with double quotes. Thus: "
+"java -jar lib/i2ptunnel.jar -nogui -e \"server localhost 10880 "
+"myWebPrivKey.dat\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:84
+msgid ""
+"Within a few seconds, the 'tunnel' should now be active, and remote "
+"clients should be able to reach your server anonymously. Remember to let "
+"your router \"warm up\" before opening clients to it."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:89
+msgid "4 - Update Your hosts.txt File "
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:91
+msgid ""
+"To test your own server locally, you'll need to create an entry in your "
+"hosts.txt file, so I2P can translate the simple URL you place in the "
+"browser's address bar into the full public key text needed to find your "
+"server."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:94
+msgid ""
+"Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where "
+"myserver.i2p is an I2P 'domain' you want to associate with your site, and"
+" the blahblahblah is the text of the base64 public key you created "
+"earlier in the file myWebPubKey.txt"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:97
+msgid ""
+"With this in place, you and others can reach your server with the simple "
+"domain name myserver.i2p in the browser's address bar."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:102
+msgid "5 - Surf Your Site Within I2P"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:104
+msgid ""
+"Using your secondary browser - the one you earlier configured to use "
+"localhost:4444 as a proxy - point this browser to the address http://myserver.i2p"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:107
+msgid "You should see the main page of your webserver come up."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:112
+msgid "6 - Create a Local Client Tunnel Connection "
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:114
+msgid "We now have to think beyond just web servers."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:117
+msgid ""
+"As you grow into I2P and get more of a 'feel' for it, you will want to "
+"use all manner of servers and clients."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:120
+msgid ""
+"The beauty of I2P is that it allows standard Internet clients and servers"
+" for most protocols to be transparently 'tunneled' through the anonymous "
+"network."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:123
+msgid ""
+"You can run mailservers/clients, nameservers/clients, newsservers/clients"
+" - almost anything at all - perhaps even FTP in passive mode."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:126
+msgid ""
+"Now, we'll create a client tunnel. This is like the server tunnel we "
+"created earlier, but works in reverse. It listens to a port on your local"
+" machine; your local client connects to this port; the connection gets "
+"forwarded through I2P to the service on the other end."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:129
+msgid ""
+"To open your client tunnel for your server, type the command java "
+"-jar lib/i2ptunnel.jar -nogui -e \"config localhost 7654\" -e \"client "
+"10888 textofbase64key\" (all one line)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:132
+msgid ""
+"The port 10888 is arbitrary - it just needs to be something other than "
+"the physical port your server is listening on."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:135
+msgid ""
+"textofbase64key is simply the contents of the public key text file "
+"myWebPubKey.txt, reproduced fully on one line (alternately, instead of "
+"textofbase64key, you can specify the name from your hosts.txt - e.g. "
+"myserver.i2p)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:138
+msgid ""
+"Within a minute or two of launching this command, the client tunnel from "
+"your local machine into I2P will be open and ready for use."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:141
+msgid ""
+"Point your regular web browser (ie, not the one you configured to use "
+"localhost:4444), and point it to http://localhost:10888"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:144
+msgid ""
+"Verify that the main page of your server eventually comes up in your "
+"browser."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:147
+msgid ""
+"You use the same procedure for using any local client program to access a"
+" remote I2P server - just get the base64 public key (called destination "
+"key) of the remote server, choose a local port to connect to the remote "
+"server, open the tunnel, and just connect with your client to your "
+"heart's content."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:152
+msgid "7 - Share your server details with others"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:154
+msgid ""
+"Using an anonymous medium (eg the one of the I2P IRC servers or ugha's "
+"wiki), post your domain name (eg www.mynick.i2p as well as your destination key. "
+"Others will then be able to reach your server remotely, without either of"
+" you jeopardizing your anonymity."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:157
+msgid ""
+"Remember, you can go to What's on I2P and find the latest public keys "
+"linked to their URL. You should also post your own public key and URL "
+"their. However, you will want to do this anonymously, of course. "
+"Drupal.i2p.net is currently, as of this writing, only accessible from the"
+" net. So, to access the outside WWW anonymously from inside of I2P, you "
+"will need to start up your script called startSquid. Do it the same way "
+"you have been doing these other scripts. Reconfigure your browser to "
+"proxy on localhost:5555, as defined in the script, and when the script "
+"has generated it's keys, you can access the squid proxy. Put any WWW URL "
+"(such as Google or this i2p site) into your browser's address bar and you"
+" will be surfing the World Wide Web anonymously. Now you can safely post "
+"your public key, and no one can detect your IP address."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:162
+msgid "8 - Write Some Scripts To Handle All This Menial Nonsense"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:164
+msgid ""
+"It would drive most people crazy, going through all these steps every "
+"time one sets up an I2P server, and/or deploys a client."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:167
+msgid ""
+"Aum's website http://www.freenet.org.nz/i2p/ has a script called "
+"setupServer.py which automates all this nonsense into one simple command "
+"line . But I respect that people's tastes in user interfaces differ, and "
+"trying to write something which satisfies everyone's needs usually "
+"results in something so complex that it turns into newbie-repellent."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:170
+msgid ""
+"So please feel free to use and/or customize setupServer.py to taste, or "
+"write your own in Python or another language."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:173
+msgid ""
+"Also, you may want to write a script which handles the startup of the I2P"
+" Router, the eepProxy, plus any and all tunnels you are using. I've got "
+"such a script called startEverything.sh, which gets launched at system "
+"startup. (Be sure to search this site for template scripts to automate "
+"your I2P commands. If I create a page for one, I'll try to remember to "
+"link it here."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:176
+msgid "Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file."
+msgstr ""
+
+#: i2p2www/pages/site/misc/invisiblenet.html:2
+msgid "Old Documents"
+msgstr ""
+
+#: i2p2www/pages/site/misc/invisiblenet.html:5
+msgid ""
+"Following is a list of documents originally on www.invisiblenet.net/i2p/ "
+"and\n"
+"rescued via the\n"
+"Wayback Machine.\n"
+"They are quite dated and may or may not be accurate.\n"
+"However, the I2CP and I2NP documents in particular have some good "
+"information."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:3
+msgid "August 2011"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:7
+msgid ""
+"Using JNI (Java Native Interface), a bit of C code (thanks ugha!), a "
+"little\n"
+"manual work and a piece of chewing gum we have made several\n"
+"cryptography operations quite a bit faster."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:13
+#, python-format
+msgid ""
+"The speedup comes from the super-fast\n"
+"GNU MP Bignum library (libgmp).\n"
+"We use a single function from libgmp -\n"
+"mpz_powm()\n"
+"as a replacement for the\n"
+"Java Math library's BigInteger modPow().\n"
+"As modPow() is a significant computational portion of many crypto "
+"operations, this is of significant benefit."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:25
+#, python-format
+msgid ""
+"The standard I2P installation includes about 20 versions of the library "
+"for different platforms,\n"
+"each about 50KB, inside the jbigi.jar file.\n"
+"The initialization of the JBigI library, including CPU identification, "
+"selection, and extraction\n"
+"of the correct loadable module, is handled by the\n"
+"NativeBigInteger class.\n"
+"If no module is available for the current platform, the standard\n"
+"Java Math library's BigInteger modPow()\n"
+"is used."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:38
+msgid "Rebuilding and Testing JBigI"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:39
+msgid ""
+"Following are the instructions to build a new jbigi library for your own "
+"platform\n"
+"and testing its performance."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:42
+msgid "Requirements"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:43
+msgid ""
+"This works on Linux, and with a few changes in build.sh probably also on\n"
+"other platforms. FreeBSD has also been reported to work too. On Kaffee "
+"the\n"
+"speedup is very small, because it already uses native BitInteger "
+"internally.\n"
+"Blackdown seems to cause strange errors. Because you are going to do\n"
+"compilation, you need JDK; JRE won't work."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:50
+msgid ""
+"The required code is available in monotone database and the latest source"
+" tarball. "
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:51
+msgid ""
+"The GNU MP Bignum library (libgmp) needs to be installed, if it isn't\n"
+"included in your OS / distribution or installed already, it can be "
+"received from\n"
+"http://gmplib.org/#DOWNLOAD. "
+"Even if you\n"
+"have already installed it as binary, it might still be worth a try to "
+"compile\n"
+"GMP yourself, since then it will be able to use the specific instructions"
+" of\n"
+"your processor. The latest GMP may also\n"
+"be used instead of GMP 5.0.2, but it hasn't been tested by us."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:61
+msgid "Step-by-step instructions"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:63
+msgid ""
+"Look at your running "
+"environment on the logs.jsp page.\n"
+"There should be one of two status messages for JBigI - either"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:66
+msgid "Locally optimized native BigInteger loaded from the library path"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:68
+msgid "or"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:70
+msgid "Native BigInteger library jbigi not loaded - using pure java"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:71
+msgid ""
+"If the native BitInteger library was NOT loaded, you definitely need to\n"
+"compile your own.\n"
+"Certain platforms, such as OS X, OpenSolaris, and 64-bit systems,\n"
+"may require you to compile your own library.\n"
+"If the BigInteger library was loaded, do at least the next step to see\n"
+"what your performance is."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:78
+msgid ""
+"Look on http://localhost:7657/stats.jsp"
+"\n"
+"to see what the lifetime average values for "
+"crypto.elGamal.decrypt and\n"
+"crypto.elGamal.encrypt are. The numbers are times in "
+"milliseconds. Copy these somewhere so you can compare\n"
+"them later on.\n"
+"The network average for encrypt time is about 20ms.\n"
+"If your encrypt time is less than 50ms for a relatively new processor, or"
+" less than 100ms\n"
+"for an older processor, and the native BigInteger library was loaded, you"
+" are probably fine."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:87
+#, python-format
+msgid ""
+"Get the latest released source code of I2P from\n"
+"the download page, or get the cutting-edge "
+"source\n"
+"out of the monotone database mtn.i2p2.de"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:92
+msgid "Inside the source tree change directory to: core/c/jbigi"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:93
+msgid ""
+"Read the README file.\n"
+"If you have a /usr/lib/libgmp.so file, you do not have to download GMP.\n"
+"Use the 'dynamic' argument to build.sh.\n"
+"Otherwise, you must download GMP version 5.0.2 from\n"
+"from http://gmplib.org/#DOWNLOAD, "
+"saving it to gmp-5.0.2.tar.bz2.\n"
+"If you decide to use a newer version, change the VER= line in "
+"core/c/jbigi/build.sh."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:101
+msgid ""
+"Take a look at build.sh, if your JAVA_HOME\n"
+"environment variable is set and you are using Linux then it might just "
+"work.\n"
+"Otherwise change the settings. Remember, you need the Java SDK installed."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:106
+msgid ""
+"Run build.sh (if you downloaded GMP) or\n"
+"build.sh dynamic (if you have /usr/lib/libgmp.so).
            \n"
+"Maybe the build spewed out some errors of missing jni.h and jni_md.h "
+"files.\n"
+"Either copy these files from your java install into the "
+"core/c/jbigi/jbigi/include/ directory,\n"
+"or fix $JAVA_HOME.
            \n"
+"You can run the build.sh from the core/c/ "
+"directory which will\n"
+"build all available jbigi libs into a jbigi.jar.
            \n"
+"A file named libjbigi.so should be created in the current\n"
+"directory. If this doesn't happen and/or you get errors then please "
+"report\n"
+"them."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:118
+msgid ""
+"Follow the instructions in core/c/README to install the library and run\n"
+"the speed test.\n"
+"Read the final lines of the speed test's output for some additional\n"
+"info, it will be something like this:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:128
+msgid ""
+"If the native is indeed 5-7x faster (or more) then it looks all good. If "
+"not, please report."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:129
+msgid "Copy libjbigi.so to your i2p directory"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:130
+msgid "Restart your I2P programs."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:131
+msgid ""
+"On http://localhost:7657/stats.jsp"
+"\n"
+"the crypto.elGamal.decrypt and "
+"crypto.elGamal.encrypt\n"
+"should be a lot faster."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jrandom-awol.html:2
+msgid "Jrandom's Announcement"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jrandom-awol.html:4
+msgid ""
+"The following message was received in mid-November 2007. We have no "
+"further information\n"
+"on jrandom's status."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jrandom-awol.html:9
+#, python-format
+msgid ""
+"Subsequently, in an unrelated incident, the hosting company for\n"
+"all *.i2p.net servers (except forum.i2p.net) suffered a power outage\n"
+"on January 13, 2008, and the i2p.net servers did not fully return to "
+"service.\n"
+"As only jrandom has the credentials required to restore service,\n"
+"and he could not be contacted,\n"
+"we moved all public services to www.i2p2.de\n"
+"and related subdomains."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jrandom-awol.html:19
+#, python-format
+msgid ""
+"Approximately two months later, for unrelated reasons,\n"
+"forum.i2p.net was moved to %(forum)s."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:2
+#: i2p2www/pages/site/misc/manual-wrapper.html:4
+msgid "Manually Installing the Java Wrapper"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:6
+#, python-format
+msgid ""
+"The installation package for the I2P router"
+" comes\n"
+"with a Java wrapper for the most common architectures. If your system is "
+"not\n"
+"supported by our installer—or if you want to update the wrapper to "
+"a\n"
+"newer version—the following steps describe installing the wrapper "
+"manually."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:14
+msgid ""
+"Check Tanuki Software's download"
+" page\n"
+"for your platform. Is your platform listed? If so, you're in\n"
+"luck! Download the most recent version of the Community Edition for your "
+"OS and\n"
+"CPU and move to the next step."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:20
+msgid ""
+"If your platform does not have an already compiled wrapper available, you"
+"\n"
+"may be able to compile it yourself. If you are willing to have a go at "
+"it, move\n"
+"on to compiling the wrapper for your system."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:27
+msgid "Using existing binaries"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:28
+msgid "In the steps below, $I2P means the location I2P was installed to."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:36
+#: i2p2www/pages/site/misc/manual-wrapper.html:64
+msgid "Try to start I2P using $I2P/i2prouter start"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:37
+#: i2p2www/pages/site/misc/manual-wrapper.html:65
+msgid "tail -f /tmp/wrapper.log and look for any problems."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:39
+#: i2p2www/pages/site/misc/manual-wrapper.html:67
+msgid ""
+"If this did not work you'll need to use runplain.sh to start"
+" I2P."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:43
+msgid "Compiling from source"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:44
+msgid ""
+"These steps worked to compile the wrapper for use on a mipsel system "
+"running Debian. The steps will need to be altered for "
+"your system."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:48
+msgid ""
+"Download the source archive for the community version of the wrapper from"
+" wrapper download"
+" page."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:49
+msgid "Extract the tarball"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:51
+msgid ""
+"Set environment variables ANT_HOME and "
+"JAVA_HOME. For example, in Debian:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:54
+msgid ""
+"Since there isn't a Makefile for Mipsel, we'll make a copy of an already "
+"existing makefile:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:56
+msgid "Now we can attempt to compile the wrapper:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:57
+msgid "use ./build64.sh if you have a 64bit CPU and JVM"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:58
+msgid "Copy the wrapper into its proper place:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:4
+msgid ""
+"Here's an outline and rationale for a minimal WWW proxy app for use over "
+"I2P."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:8
+msgid ""
+"HTTP operation over I2P using I2PTunnel.  When the base SocketLibrary\n"
+"is out, the only significant difference will be the 'wrapRequest' and\n"
+"'unwrapRequest' will functionally be placed in the socketLibrary, not\n"
+"in the router (but later versions of the SocketLibrary will be able to\n"
+"use selective ACK and large window sizes, allowing more ACKs to be\n"
+"skipped)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:47
+msgid ""
+"An optimized form, designed to handle only 128KB [1] files and pages, can"
+"\n"
+"operate significantly faster:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:71
+msgid ""
+"The difference in network load and latency is significant - this is\n"
+"essentially a UDP version of HTTP.  On the normal web, we can't really do"
+" that,\n"
+"since most HTTP requests and responses are orders of magnitude larger "
+"than UDP\n"
+"packets functionally support, but in I2P, messages can be large.  The "
+"savings\n"
+"for the network load comes from the fact that we don't need to send any "
+"ACK\n"
+"messages - rather than the earlier wrap/unwrap request (that bundles a\n"
+"DataMessage with a DeliveryStatusMessage to provide guaranteed delivery),"
+" the\n"
+"MinWWW proxy deals with resends (if necessary - in I2PTunnel today, there"
+" are no\n"
+"resends)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:83
+msgid ""
+"The data that the MinWWW proxy and server need to wrap is trivial - when "
+"the\n"
+"proxy wants to send \"GET /\", it prepends it with the I2P Destination "
+"sending\n"
+"the request, followed by a 4 byte request ID.  The MinWWW server receives"
+" those\n"
+"requests, contacts the appropriate HTTPD, sends the request, waits for "
+"the\n"
+"response, and sends a reply to the MinWWW proxy containing the response,\n"
+"prefixed with the original request ID.  That response is taken and passed"
+" back\n"
+"to the browser and the connection is closed."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:93
+msgid ""
+"In addition, the MinWWW proxy can choose the MinWWW server to use from a\n"
+"list, going through some round robin or other algorithm, so that there "
+"are\n"
+"multiple outproxies merged transparently.  The bandwidth required for "
+"running\n"
+"one of these outproxies is also greatly reduced, since it will only "
+"handle 128KB\n"
+"files (aka no one is going to be downloading porn, warez, etc)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:101
+msgid ""
+"The functionality /is/ limited, but 128KB of data is a lot for a single "
+"HTTP\n"
+"request or response.  The above diagrams are also unrealistic in their "
+"hops -\n"
+"ROUTERA will really never talk directly to ROUTERB.  ROUTERA will send "
+"each\n"
+"of the messages through two additional outbound routers, then forwarded "
+"to\n"
+"two additional inbound routers to ROUTERB, so the lag there is "
+"significant -\n"
+"while the above only saves 11 steps, 8 of those steps need to traverse "
+"the\n"
+"entire tunnel path (4+ remote hops each time when tunnels are 2 remote "
+"hops\n"
+"in each stretch), leaving MinWWW with only two full traversals (one for "
+"the\n"
+"request, one for the response), instead of 10."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:113
+msgid ""
+"Implementing the MinWWW proxy and server should be fairly easy - read an "
+"HTTP\n"
+"request from the client fully (perhaps only start out with HTTP GET, "
+"leaving\n"
+"HTTP POST for later), wrap the message, and wait for the response.  The "
+"server\n"
+"in turn simply needs to parse the request to either open a socket or URL,"
+"\n"
+"send the request, wait for the response, and send it back through the "
+"network.\n"
+"If someone were to implement this, it would be Good :)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:122
+msgid ""
+"[1] Why 128KB files?  Currently I2CP allows functionally arbitrary "
+"message\n"
+"size, but that's going to be going away since it involves either "
+"excessive memory\n"
+"overhead on intermediary routers, or additional implementation details to"
+"\n"
+"handle.  I2PTunnel is currently limited to 128KB and hasn't been a "
+"burden,\n"
+"so perhaps it could be increased to 256KB when the I2CP spec is updated)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/myi2p.html:4
+msgid ""
+"There has been discussion about a distributed blogging application for a "
+"few\n"
+"months now called \"MyI2P\".  While the original discussions were lost, "
+"we were \n"
+"able to retrieve a Google cache\n"
+"of it.  It isn't pretty, but it includes the basic overview and some "
+"discussion\n"
+"that ensued."
+msgstr ""
+
+#: i2p2www/pages/site/misc/myi2p.html:12
+#, python-format
+msgid ""
+"The application itself is not yet implemented, and the ideas behind it "
+"have \n"
+"been made less ambitious over time, but they are still valid and the "
+"current \n"
+"plan is to have the core MyI2P functionality "
+"available \n"
+"along side the I2P 1.0 release.  That will include a distributed address "
+"book\n"
+"to enable secure, distributed, and human readable naming by sacrificing "
+"the \n"
+"need for global uniqueness - basically everyone has their own local "
+"address book \n"
+"and can 'subscribe' to other people's address books, letting MyI2P "
+"periodically\n"
+"retrieve new name to destination mappings (leaving conflicts up to the "
+"user to\n"
+"resolve).  In addition to the address book, there will be a distributed "
+"blogging\n"
+"system using a reduced and secured subset of \n"
+"bbcode to "
+"essentially\n"
+"provide an anonymous LiveJournal with\n"
+"a 'friends list' and transparent access control (authenticated by the I2P"
+"\n"
+"datagrams with rules defined based on the "
+"address book)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/myi2p.html:29
+msgid ""
+"Additional functionality, such as integration with a DHT backing store or"
+" \n"
+"swarming file transfers for 'attachments' can be added later.  Email may "
+"or may\n"
+"not get in the first pass either, though its implementation is "
+"essentially just\n"
+"a blog entry with private access, so perhaps some UI designer can come up"
+" with\n"
+"something.  Exporting the data to RSS or access through ATOM will be an "
+"option \n"
+"down the road as well."
+msgstr ""
+
+#: i2p2www/pages/site/misc/ratestats.html:2
+#: i2p2www/pages/site/misc/ratestats.html:5
+msgid "RateStat list"
+msgstr "Lista de RateStat"
+
+#: i2p2www/pages/site/misc/ratestats.html:6
+msgid "I2P enables the collection of a wide range of rates."
+msgstr ""
+
+#: i2p2www/pages/site/misc/ratestats.html:7
+msgid ""
+"The list was gathered using the following command in the top directory of"
+" the branch i2p.i2p:"
+msgstr "La lista fue obtenida usando el siguente comando en el directorio principal de la rama 2p.i2p:"
+
+#: i2p2www/pages/site/misc/ratestats.html:10
+msgid "All options aren't needed, but it works."
+msgstr "No son necesarias todas las opciones, pero funciona."
+
+#: i2p2www/pages/site/misc/transition-guide.html:4
+#, python-format
+msgid ""
+"The I2P sourcecode is kept in several distributed monotone repositories.\n"
+"See the\n"
+"Monotone website for information\n"
+"on monotone.\n"
+"See\n"
+"this forum post on i2p "
+"monotone\n"
+"for more information on how to get started and check out the source "
+"anonymously.\n"
+"There is also a quick-start guide on the\n"
+"new developer's page."
+msgstr ""
+"El código fuente de i2p es mantenido en varios repositorios distribuidos de monotone.\n"
+"Vea el\n"
+"Web de Monotone para mas información\n"
+"sobre monotone.\n"
+"Vea\n"
+"este foro sobre i2p y monotone\n"
+"para obtener mas información de como comenzar y descargar el código fuente anónimamente.\n"
+"También hay una guía rápida en la\n"
+"web de nuevos desarrolladores."
+
+#: i2p2www/pages/site/misc/transition-guide.html:16
+msgid ""
+"If you want to get the source non-anonymously, pull from the public "
+"server mtn.welterde.de.\n"
+"The i2p source code branch is \"i2p.i2p\"."
+msgstr ""
+"Si desea obtener el código fuente no anónimamante, descargue desde el servidor publico mtn.welterde.de.\n"
+"La rama del código fuente de i2p es \"i2p.i2p\"."
+
+#: i2p2www/pages/site/misc/transition-guide.html:21
+msgid "Guide"
+msgstr "Guía"
+
+#: i2p2www/pages/site/misc/transition-guide.html:22
+msgid ""
+"\n"
+"The following is a detailed guide by Complication."
+msgstr ""
+"\n"
+"Lo siguiente es una guía detallada hecha por Complication."
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:2
+msgid "How to Upgrade from 0.6.1.30 and Earlier"
+msgstr "Como actualizar desde la versión 0.6.1.30 y anteriores."
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:6
+msgid "Upgrading from 0.6.1.30 and Earlier Releases"
+msgstr "Actualizando desde 0.6.1.30 y versiones anteriores."
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:8
+#, python-format
+msgid ""
+"Since i2p's lead developer\n"
+"has gone AWOL,\n"
+"we do not have his update signing key or access to\n"
+"www.i2p[.net] or dev.i2p[.net].\n"
+"Complication and zzz have generated new signing keys, and they and Amiga "
+"are providing\n"
+"update file hosting. These changes must be configured in your router to "
+"take effect."
+msgstr ""
+"Desde que el progrmador principal de i2p\n"
+"se ausentó sin irse oficalmente(AWOL),\n"
+"no tenemos su clave de actualización firmada o acceso a\n"
+"www.i2p[.net] o dev.i2p[.net].\n"
+"Complication y zzz han generado nuevas claves de firmado, y ellos y Amiga proveen\n"
+"alojamiento a los archivos de actualización. Estos cambios tienen que ser configurados en su ruter para que tengan efecto. "
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:17
+msgid ""
+"Make the following configuration changes and your router will "
+"automatically install\n"
+"the latest release."
+msgstr ""
+"Haga los siguientes cambios de configuración y su tuter instalará automáticamente\n"
+"la última versión"
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:22
+#, python-format
+msgid ""
+"We recommend the automated process as it will verify the key of the "
+"signed update file.\n"
+"If you do not make these changes,\n"
+"you may manually download the i2pupdate.zip file from\n"
+"the download page."
+msgstr ""
+"Recomendamos el proceso automático ya que verificará la clave del archivo de actualización firmado.\n"
+"Si no hace estos cambios,\n"
+"puede descargar manualmente el archivo i2pupdate.zip de\n"
+"página de descargas."
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:34
+#, python-format
+msgid "Change the News URL to: %(url)s"
+msgstr "Cambia el enlace de noticias a: %(url)s"
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:38
+msgid ""
+"Select ONE of the following new Update URLs at random and enter it into "
+"the Update URL box: "
+msgstr "Seleccione una de las siguientes enlaces de actualización aleatoriamente e introdúzaclo dentro de la casilla Update URL:"
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:43
+msgid "Check the box \"Update through the eepProxy?\""
+msgstr "Active la casilla \"Actualizar a través del eepProxy?\""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:44
+msgid "Click \"Save\""
+msgstr "Pulse \"Guardar\""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:51
+msgid "Add the following line:"
+msgstr "Añade la siguiente línea:"
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:55
+msgid "Click \"Apply\""
+msgstr "Pulse \"Aplicar\""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:58
+msgid ""
+"You are now ready to automatically receive the release update file,\n"
+"either by setting your update policy to \"download and install\" or by "
+"clicking on the\n"
+"\"update available\" link when it appears."
+msgstr ""
+"Ahora estas listo para recibir automaticamente el archivo de actualización,\n"
+"ya sea configurando tu política de actualizaciones a \"descaragr e instalar\" or pulsando en el link\n"
+"\"actualización disponible\" cuando aparezca."
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:65
+#, python-format
+msgid ""
+"If you would like to verify the trusted update keys, they are also\n"
+"posted and signed here.\n"
+"Thank you for your support during this transition. For help please "
+"contact us on #i2p."
+msgstr ""
+"Si deseas verificar las claves de actualización de confianza, se encuentran también\n"
+"subidas y firmadas aquí.\n"
+"Gracias por tu ayuda durante la transición. Para pedir ayuda por favor contacta con nosotros en #I2P."
+
+#: i2p2www/pages/site/research/index.html:2
+msgid "Academic Research"
+msgstr "Investigación académica"
+
+#: i2p2www/pages/site/research/index.html:4
+msgid ""
+"Academic research and analysis of I2P is an important part of ensuring "
+"that the software and network performs as expected and is safe for users "
+"in hostile environments."
+msgstr "El análisis y la investigación académica de I2P es una parte importante pra asegurar que la aplicación y la red funcionan como deben y es segura para los usuarios en ambientes hostiles."
+
+#: i2p2www/pages/site/research/index.html:8
+msgid ""
+"I2P can be run as a separate test network by controlling the locations "
+"that a new router reseeds from so that it only finds other test routers. "
+"Additionally, the router can be run on its own in a virtual network mode "
+"to enable testing the router in isolation; to enable this mode, add "
+"i2p.vmCommSystem=true to the router.config before starting."
+msgstr "I2P puede ser ejecutado como una red aparte de pruebas controlando la localización desde la que el nuevo ruter resiembra, con lo cual solo conectaría con otros ruters de pruebas. Adicionalmente el ruter se puede ejecutar el solo en una red virtual para permitir probar el ruter en aislamiento; para activar este modo, añade i2p.vmCommSystem=true en router.config antes de arrancar."
+
+#: i2p2www/pages/site/research/index.html:12
+#, python-format
+msgid ""
+"If you are planning on conducting research on the live I2P network, "
+"please contact us before you commence your "
+"testing. While we do not discourage researchers from responsibly testing "
+"their ideas on the live network, if an attack becomes apparent and we "
+"don't have any line of communication then we will end up taking "
+"countermeasures which could interfere with the test."
+msgstr "Si estas planeando hacer algún estudio sobre la red de I2P online,  por favor contáctanos antes de comenzar las pruebas.  Aunque no desalentamos a los desarrolladores a propar sus ideas responsablemente en la red, si algún ataque se hace aparente y no tenemos una línea de comunicación terminaremos tomando medidas que podrían interferir con las pruebas."
+
+#: i2p2www/pages/site/research/index.html:16
+msgid "Prior Research"
+msgstr "Estudios anteriores"
+
+#: i2p2www/pages/site/research/index.html:18
+#, python-format
+msgid ""
+"A list of known published papers about I2P is available here."
+msgstr "Una lista de doumentos publiados sobre I2P está disponible en here."
+
+#: i2p2www/pages/site/research/papers.html:6
+msgid "Following are links to research papers about I2P."
+msgstr "A Continuación unos links para investigar trabajos sobre I2P."
+
+#: i2p2www/pages/site/research/papers.html:12
+msgid "Newest links are at the top of the page."
+msgstr "Los links mas nuevos se enuentran en el enabezado de la página."
+
+#: i2p2www/pages/site/research/papers.html:17
+msgid "Papers and Research"
+msgstr "Documentos e investigación"
+
diff --git a/i2p2www/translations/fr/LC_MESSAGES/messages.po b/i2p2www/translations/fr/LC_MESSAGES/messages.po
new file mode 100644
index 00000000..ebf8117f
--- /dev/null
+++ b/i2p2www/translations/fr/LC_MESSAGES/messages.po
@@ -0,0 +1,573 @@
+# French translations for I2P website.
+# Copyright (C) 2011 I2P
+# This file is distributed under the same license as the I2P website
+# project.
+# magma , 2011.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: I2P website\n"
+"Report-Msgid-Bugs-To: EMAIL@ADDRESS\n"
+"POT-Creation-Date: 2012-09-17 06:34+0000\n"
+"PO-Revision-Date: 2011-03-23 09:28+0000\n"
+"Last-Translator: magma \n"
+"Language-Team: fr \n"
+"Plural-Forms: nplurals=2; plural=(n > 1);\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Generated-By: Babel 0.9.6\n"
+"X-Generator: Poedit 1.5.3\n"
+
+#: pages/site/docs/how/intro.html:2
+msgid "A Gentle Introduction"
+msgstr "Introduction en douceur"
+
+#: pages/site/docs/how/intro.html:5
+msgid "A Gentle Introduction to How I2P Works"
+msgstr "Une présentation allégée du fonctionnement d'I2P"
+
+#: pages/site/docs/how/intro.html:7
+msgid ""
+"I2P is a project to build, deploy, and maintain a network supporting secure "
+"and anonymous\n"
+"communication. People using I2P are in control of the tradeoffs between "
+"anonymity, reliability,\n"
+"bandwidth usage, and latency. There is no central point in the network on "
+"which pressure can be\n"
+"exerted to compromise the integrity, security, or anonymity of the system. "
+"The network supports\n"
+"dynamic reconfiguration in response to various attacks, and has been "
+"designed to make use of\n"
+"additional resources as they become available. Of course, all aspects of the "
+"network are open and\n"
+"freely available."
+msgstr ""
+"I2P est un projet dont le but est de construire, déployer, et maintenir un "
+"réseau fournissant\n"
+"des communications sécurisées et anonymes.\n"
+"Les gens utilisant I2P ont le contrôle de l'arbitrage entre l'anonymat, la "
+"fiabilité,\n"
+"l'utilisation de la bande passante, et la latence. Il n'y a dans ce réseau, "
+"pas de centre sur lequel pourrait\n"
+"être exercée une pression en vue de compromettre l'intégrité, la sécurité, "
+"ou l'anonymat du système.\n"
+"Le réseau intègre sa propre reconfiguration dynamique en réponse aux "
+"diverses attaques,\n"
+"et a été conçu pour utiliser de nouvelles ressources au fur et ?|  mesure de "
+"leur disponibilité.\n"
+"Bien entendu, tous les aspects du réseau sont publics et disponibles "
+"gratuitement."
+
+#: pages/site/docs/how/intro.html:17
+msgid ""
+"Unlike many other anonymizing networks, I2P doesn't try to provide anonymity "
+"by hiding the\n"
+"originator of some communication and not the recipient, or the other way "
+"around. I2P is designed to\n"
+"allow peers using I2P to communicate with each other anonymously — "
+"both sender and recipient\n"
+"are unidentifiable to each other as well as to third parties. For example, "
+"today there are both\n"
+"in-I2P web sites (allowing anonymous publishing / hosting) as well as HTTP "
+"proxies to the normal web\n"
+"(allowing anonymous web browsing). Having the ability to run servers within "
+"I2P is essential, as it\n"
+"is quite likely that any outbound proxies to the normal Internet will be "
+"monitored, disabled, or\n"
+"even taken over to attempt more malicious attacks."
+msgstr ""
+"Contrairement ?|  de nombreux autres réseaux anonymisants, I2P ne tente pas "
+"de procurer l'anonymat en masquant\n"
+"l'initiateur et pas le destinataire, ou le contraire. I2P est conçu pour "
+"permettre\n"
+"aux pairs l'utilisant de communiquer anonymement — l'émetteur et le "
+"récepteur sont non-identifiables\n"
+"l'un par l'autre comme par un tiers. Par exemple, il y a aujourd'hui des "
+"sites web intra-I2P\n"
+"(permettant la publication/hébergement anonymes) tout comme des serveurs "
+"mandataires HTTP vers le web normal\n"
+"(permettant la navigation anonyme). La possibilité d'avoir des serveurs dans "
+"I2P est essentielle,\n"
+"car il est plus que certain que n'importe quel proxy sortant vers l'Internet "
+"sera surveillé, désactivé,\n"
+"ou même piraté pour tenter des attaques encore plus pernicieuses."
+
+#: pages/site/docs/how/intro.html:28
+#, python-format
+msgid ""
+"The network itself is message oriented - it is essentially a secure and "
+"anonymous IP layer, where\n"
+"messages are addressed to cryptographic keys (Destinations) and can be "
+"significantly larger than IP\n"
+"packets. Some example uses of the network include \"eepsites\" (webservers "
+"hosting normal web\n"
+"applications within I2P), a BitTorrent client (\"I2PSnark\"), or a "
+"distributed data store. With the\n"
+"help of the I2PTunnel application, we are able "
+"to stream traditional\n"
+"TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and even "
+"streaming audio. Most people\n"
+"will not use I2P directly, or even need to know they're using it. Instead "
+"their view will be of one\n"
+"of the I2P enabled applications, or perhaps as a little controller app to "
+"turn on and off various\n"
+"proxies to enable the anonymizing functionality."
+msgstr ""
+"Le réseau lui-même est \"orienté messages\": il est principalement constitué "
+"d'une couche IP sécurisée\n"
+"et anonyme, dans laquelle les messages sont adressés ?|  des clés "
+"cryptographiques (Destinations) et\n"
+"peuvent être sensiblement plus gros que des paquets IP. ?~@ titre d'exemples "
+"d'utilisation du réseau\n"
+"citons les \"eepsites\" (serveurs web hébergeant des applications Internet "
+"normales au sein d'I2P), un\n"
+"client BitTorrent (\"I2PSnark\"), ou un système de stckage distribué.  "
+"Grâce ?|  l'application\n"
+"I2PTunnel, nous pouvons utiliser des "
+"applications TCP/IP traditionnelles\n"
+"sur I2P, telles que SSH, IRC, un proxy squid, et même du flux audio. La "
+"plupart des gens n'utilisent pas\n"
+"I2P directement, ou ne ressentent même pas le besoin de savoir qu'ils "
+"l'utilisent. Au lieu de ça ils verront\n"
+"une des application compatibles avec I2P, ou peut-être une petite "
+"application de contrôle qui va activer\n"
+"ou désactiver divers proxies pour piloter la fonctionnalité d'anonymisation."
+
+#: pages/site/docs/how/intro.html:40
+#, python-format
+msgid ""
+"An essential part of designing, developing, and testing an anonymizing "
+"network is to define the threat model, since there is no such thing as "
+"\"true\" anonymity, just\n"
+"increasingly expensive costs to identify someone. Briefly, I2P's intent is "
+"to allow people to\n"
+"communicate in arbitrarily hostile environments by providing good anonymity, "
+"mixed in with\n"
+"sufficient cover traffic provided by the activity of people who require less "
+"anonymity. This way,\n"
+"some users can avoid detection by a very powerful adversary, while others "
+"will try to evade a weaker\n"
+"entity, all on the same network, where each one's messages are "
+"essentially indistinguishable\n"
+"from the others."
+msgstr ""
+"Un des points clés de la conception, dus développement, et du test d'un "
+"réseau anonyme est la définition de son\n"
+"modèle de sécurité, car il n'existe nulle "
+"part un \"vrai\" anonymat, mais uniquement\n"
+"des moyens d'augmenter les coûts d'identification de quelqu'un. "
+"Succinctement, le but d'I2P est de permettre de\n"
+"communiquer dans des environnements hostiles en procurant un bon anonymat, "
+"mélangé ?|  un trafic de camouflage\n"
+"suffisant fourni par l'activité de ceux qui ont besoin de moins d'anonymat, "
+"de sorte que certains utilisateurs puissent\n"
+"se soustraire ?|  la détection par un adversaire très puissant, quand "
+"d'autres pourront esquiver une entité plus faible,\n"
+"tout ceci sur le même réseau dans lequel les messages des uns sont "
+"fondamentalement indistinguables de ceux des\n"
+"autres."
+
+#: pages/site/docs/how/intro.html:51
+msgid "Why?"
+msgstr "Pourquoi?"
+
+#: pages/site/docs/how/intro.html:52
+#, python-format
+msgid ""
+"There are a multitude of reasons why we need a system to support anonymous "
+"communication, and\n"
+"everyone has their own personal rationale. There are many other\n"
+"efforts working on finding ways to provide varying degrees of anonymity "
+"to people through the\n"
+"Internet, but we could not find any that met our needs or threat model."
+msgstr ""
+"Il y a une multitude de raisons qui justifient que nous ayons besoin d'un "
+"système de communication anonyme,\n"
+"et chacun a les siennes propres. Il y a de nombreux autres efforts\n"
+"pour trouver les moyens de fournir divers niveaux d'anonymat sur Internet, "
+"mais nous n'en avons trouvé aucun\n"
+"qui réponde ?|  nos besoins ou ?|  notre modèle de sécurité."
+
+#: pages/site/docs/how/intro.html:59
+msgid "How?"
+msgstr "Comment?"
+
+#: pages/site/docs/how/intro.html:61
+#, python-format
+msgid ""
+"The network at a glance is made up of a set of nodes (\"routers\") with a "
+"number of unidirectional\n"
+"inbound and outbound virtual paths (\"tunnels\", as outlined on the tunnel routing page). Each router is identified by "
+"a cryptographic RouterIdentity which is\n"
+"typically long lived. These routers communicate with each other through "
+"existing transport\n"
+"mechanisms (TCP, UDP, etc), passing various messages. Client applications "
+"have their own\n"
+"cryptographic identifier (\"Destination\") which enables it to send and "
+"receive messages. These\n"
+"clients can connect to any router and authorize the temporary allocation "
+"(\"lease\") of some tunnels\n"
+"that will be used for sending and receiving messages through the network. "
+"I2P has its own internal\n"
+"network database (using a modification of the "
+"Kademlia algorithm) for\n"
+"distributing routing and contact information securely."
+msgstr ""
+"Au premier coup d'?~Sil le réseau est constitué d'un tas de n?~Suds "
+"(\"routeurs\") dotés d'un certain nombre\n"
+"de chemins virtuels entrants et sortants unidirectionnels (appelés \"tunnels"
+"\", expliqués sur la page\n"
+"routage en tunnel).) Chaque routeur est "
+"identifié par l'identifiant\n"
+"cryptographique \"RouterIdentity\", typiquement de longue durée de vie. Ces "
+"routeurs communiquent\n"
+"par des mécanismes existants (TCP, UDP, etc). Les applications clientes ont "
+"leur propre identifiant\n"
+"cryptographique (\"Destination\") qui leur permet d'envoyer et de recevoir "
+"des messages. Ces clients peuvent\n"
+"se connecter ?|  n'importe quel routeur et autoriser l'allocation temporaire "
+"(\"lease\") de quelques tunnels\n"
+"qui seront utilisés pour l'envoi et la réception ?|  travers le réseau. I2P "
+"dispose de sa propre\n"
+"base de donnée réseau interne (avec une "
+"modification de l'algorithme Kademlia)\n"
+"pour une distribution sécurisée des informations de routage et de contacts."
+
+#: pages/site/docs/how/intro.html:74
+msgid "Network topology example"
+msgstr "Exemple de topologie du réseau"
+
+#: pages/site/docs/how/intro.html:76
+msgid ""
+"In the above, Alice, Bob, Charlie, and Dave are all running routers with a "
+"single Destination on\n"
+"their local router. They each have a pair of 2-hop inbound tunnels per "
+"destination (labeled 1, 2, 3,\n"
+"4, 5 and 6), and a small subset of each of those router's outbound tunnel "
+"pool is shown with 2-hop\n"
+"outbound tunnels. For simplicity, Charlie's inbound tunnels and Dave's "
+"outbound tunnels are not\n"
+"shown, nor are the rest of each router's outbound tunnel pool (typically "
+"stocked with a few tunnels\n"
+"at a time). When Alice and Bob talk to each other, Alice sends a message out "
+"one of her (pink)\n"
+"outbound tunnels targeting one of Bob's (green) inbound tunnels (tunnel 3 or "
+"4). She knows to send\n"
+"to those tunnels on the correct router by querying the network database, "
+"which is constantly updated\n"
+"as new leases are authorized and old ones expire."
+msgstr ""
+"Ci-dessus, Alice, Bob, Charlie, et Dave ont tous leur routeur, avec une "
+"seule Destination locale.\n"
+"Ils ont chacun une paire de tunnels entrants ?|  deux sauts par destination "
+"(repérés 1, 2, 3, 4, 5 et 6),\n"
+"et une petite partie des tunnels sortants de chacun de ces routeurs est "
+"montré avec des tunnels sortants ?|  deux sauts.\n"
+"Pour simplifier, ne sont représentés ni les tunnels entrants de Charlie et "
+"les tunnels sortants de Dave,\n"
+"ni le reste du groupe de tunnels sortants de chaque routeur (fourni par "
+"défaut avec quelques tunnels).\n"
+"Quand Alice et Bob discutent ensemble, Alice envoie un message vers un de "
+"ses tunnels sortants (en rose)\n"
+"avec pour cible un des tunnels entrants de Bob (3 ou 4, en vert). Elle sait "
+"qu'elle doit envoyer vers ces tunnels\n"
+"sur le bon routeur en interrogeant la base de donnée du réseau qui est "
+"actualisée en permanence\n"
+"au fur et ?|  mesure que les nouveaux baux sont autorisés et que les anciens "
+"expirent."
+
+#: pages/site/docs/how/intro.html:88
+#, python-format
+msgid ""
+"If Bob wants to reply to Alice, he simply goes through the same process - "
+"send a message out one of\n"
+"his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or "
+"2). To make things\n"
+"easier, most messages sent between Alice and Bob are garlic\n"
+"wrapped, bundling the sender's own current lease information so that the "
+"recipient can reply\n"
+"immediately without having to look in the network database for the current "
+"data."
+msgstr ""
+"Si Bob veut répondre ?|  Alice, il utilise simplement la même procédure: "
+"envoyer un message via un de ses\n"
+"tunnels sortants en ciblant un des tunnels entrants d'Alice (tunnel 1 ou 2). "
+"Pour rendre les choses plus faciles,\n"
+"la plupart des messages circulant entre Alice et Bob sont empaquetés \"?|  "
+"la garlic\",\n"
+"embarquant les informations sur le bail actuel de l'expéditeur, de sorte que "
+"le destinataire puisse répondre\n"
+"immédiatement sans avoir ?|  interroger la base de donnée."
+
+#: pages/site/docs/how/intro.html:96
+#, python-format
+msgid ""
+"To deal with a wide range of attacks, I2P is fully distributed with no "
+"centralized resources - and\n"
+"hence there are no directory servers keeping statistics regarding the "
+"performance and reliability of\n"
+"routers within the network. As such, each router must keep and maintain "
+"profiles of various routers\n"
+"and is responsible for selecting appropriate peers to meet the anonymity, "
+"performance, and\n"
+"reliability needs of the users, as described in the peer selection\n"
+"page."
+msgstr ""
+"Pour gérer une grande gamme d'attaques, I2P est entièrement décentralisé et en conséquence\n"
+"il n'y a pas de serveur d'annuaire conservant des statistiques de "
+"performances et de fiabilité  Donc chaque routeur doit garder et entretenir les profils de "
+"divers routeurs\n"
+"et est responsable de la sélection de pairs appropriés aux besoins "
+"d'anonymat, de performance et de fiabilité\n"
+"des utilisateurs, comme expliqué sur la page sélection de pairs."
+
+#: pages/site/docs/how/intro.html:105
+#, python-format
+msgid ""
+"The network itself makes use of a significant number of cryptographic\n"
+"techniques and algorithms - a full laundry list includes 2048bit ElGamal "
+"encryption, 256bit AES\n"
+"in CBC mode with PKCS#5 padding, 1024bit DSA signatures, SHA256 hashes, "
+"2048bit Diffie-Hellman\n"
+"negotiated connections with station to station authentication, and ElGamal / AES+SessionTag."
+msgstr ""
+"Le réseau fait usage d'un nombre significatif de techniques et algorithmes\n"
+"cryptographiques: la liste complète est constituée des cryptages "
+"ElGamal ?|  2048bits, AES 256bits\n"
+"en mode CBC avec bourrage PKCS#5, des signatures DSA ?|  1024bits, des "
+"hachages SHA256, de\n"
+"l'authentification de connexions station ?|  station négociée en Diffie-"
+"Hellman 2048bit, et\n"
+"ElGamal / AES+SessionTag."
+
+#: pages/site/docs/how/intro.html:113
+msgid ""
+"Content sent over I2P is encrypted through three layers garlic encryption "
+"(used to verify the\n"
+"delivery of the message to the recipient), tunnel encryption (all messages "
+"passing through a tunnel\n"
+"is encrypted by the tunnel gateway to the tunnel endpoint), and inter router "
+"transport layer\n"
+"encryption (e.g. the TCP transport uses AES256 with ephemeral keys)."
+msgstr ""
+"Les contenus envoyés sur I2P sont cryptés ?|  travers un cryptage en têtes "
+"d'ail (\"garlic\") ?|  trois niveaux\n"
+"(utilisé pour vérifier la réception du message par le destinataire), par le "
+"cryptage de tunnel (tous les messages\n"
+"traversant un tunnel sont cryptés par la passerelle du tunnel ?|  "
+"l'intention du point de sortie du tunnel),\n"
+"et par un cryptage de la couche transport inter routeurs (p.e. le transport "
+"TCP utilise des clés AES256 éphémères)."
+
+#: pages/site/docs/how/intro.html:120
+msgid ""
+"End-to-end (I2CP) encryption (client application to server application) was "
+"disabled in I2P release\n"
+"0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) "
+"from Alice's router \"a\"\n"
+"to Bob's router \"h\" remains. Notice the different use of terms! All data "
+"from a to h is end-to-end\n"
+"encrypted, but the I2CP connection between the I2P router and the "
+"applications is not end-to-end\n"
+"encrypted! A and h are the routers of Alice and Bob, while Alice and Bob in "
+"following chart are the\n"
+"applications running atop of I2P."
+msgstr ""
+"Le cryptage de bout en bout (I2CP) (application cliente ?|  application "
+"serveur) a été désactivée dans\n"
+"la version 0.6; Le cryptage (garlic) de bout en bout (routeur I2P client ?|  "
+"routeur I2P serveur) depuis\n"
+"le routeur \"a\" d'Alice vers le \"h\" de Bob est restée. Remarquez "
+"l'utilisation différente des termes! Toutes\n"
+"les données transitant de \"a\" ?|  \"h\" sont cryptées de bout en bout, "
+"mais la connexion I2CP entre le\n"
+"routeur et les applications ne l'est pas! \"a\" et \"h\" sont les routeurs "
+"d'Alice et Bob, alors qu'Alice et Bob\n"
+"dans le schéma suivant sont les applications qui tournent sur I2P."
+
+#: pages/site/docs/how/intro.html:129
+msgid "End to end layered encryption"
+msgstr "Cryptage en couches de bout en bout"
+
+#: pages/site/docs/how/intro.html:131
+#, python-format
+msgid ""
+"The specific use of these algorithms are outlined elsewhere."
+msgstr ""
+"Les utilisations spécifiques de ces algorithmes sont précisées ailleurs."
+
+#: pages/site/docs/how/intro.html:135
+msgid ""
+"The two main mechanisms for allowing people who need strong anonymity to use "
+"the network are\n"
+"explicitly delayed garlic routed messages and more comprehensive tunnels to "
+"include support for\n"
+"pooling and mixing messages. These are currently planned for release 3.0, "
+"but garlic routed messages\n"
+"with no delays and FIFO tunnels are currently in place. Additionally, the "
+"2.0 release will allow\n"
+"people to set up and operate behind restricted routes (perhaps with trusted "
+"peers), as well as the\n"
+"deployment of more flexible and anonymous transports."
+msgstr ""
+"Les deux mécanismes principaux permettant l'usage du réseau ?|  ceux qui ont "
+"besoin d'un anonymat fort\n"
+"sont très explicitement le routage \"garlic\" retardé et des tunnels plus "
+"évolués incluant la possibilité d'appeler et\n"
+"de croiser les messages. Ils sont actuellement planifiés pour la version "
+"3.0, mais le routage \"garlic\" instantané et\n"
+"les tunnels FIFO sont d'ores et déj?|  opérationnels. La version 2.0 "
+"permettra de mettre en place des routes réservées\n"
+"(peut-être avec des pairs de confiance), ainsi que des transports plus "
+"souples et plus anonymes."
+
+#: pages/site/docs/how/intro.html:144
+#, python-format
+msgid ""
+"Some questions have been raised with regards to the scalability of I2P, and "
+"reasonably so. There\n"
+"will certainly be more analysis over time, but peer lookup and integration "
+"should be bounded by\n"
+"O(log(N)) due to the network database's algorithm, while end\n"
+"to end messages should be O(1) (scale free), since messages go "
+"out K hops through the\n"
+"outbound tunnel and another K hops through the inbound tunnel, with K no "
+"longer than 3. The size of\n"
+"the network (N) bears no impact."
+msgstr ""
+"Des questions on surgit ?|  juste titre sur l'évolutivité d'I2P en terme "
+"d'échelle. Il y aura certainement plus\n"
+"d'analyse avec le temps, mais l'intégration et la recherche des pairs "
+"devraient répondre ?|  \n"
+"O(log(N)) grâce ?|  l'algorithme de la base de données,\n"
+"alors que les messages seraient plutôt liés ?| O(1) (non "
+"dépendance ?|  l'échelle),\n"
+"car les messages passent par K sauts du tunnel sortant puis encore K sauts "
+"via le tunnel entrant, avec K\n"
+"inférieur ou égal ?|  3. La taille du réseau (N) n'a aucun impact."
+
+#: pages/site/docs/how/intro.html:153
+msgid "When?"
+msgstr "Quand?"
+
+#: pages/site/docs/how/intro.html:154
+#, python-format
+msgid ""
+"I2P initially began in Feb 2003 as a proposed modification to Freenet to allow it to use alternate "
+"transports, such as JMS, then grew into "
+"its own as an\n"
+"'anonCommFramework' in April 2003, turning into I2P in July, with code being "
+"written in earnest\n"
+"starting in August '03. I2P is currently under development, following the roadmap."
+msgstr ""
+"I2P a commencé en février 2003 en tant que proposition de modification de\n"
+"Freenet pour lui permettre "
+"d'utiliser d'autres modes de transferts,\n"
+"comme JMS, puis a "
+"évolué de son côté en\n"
+"'anonCommFramework' en avril 2003, pour devenir I2P en juillet, l'écriture "
+"du code ayant sérieusement\n"
+"commencé en août 2003. I2P est actuellement en phase de développement et "
+"suit sa \n"
+"feuille de route."
+
+#: pages/site/docs/how/intro.html:163
+msgid "Who?"
+msgstr "Qui?"
+
+#: pages/site/docs/how/intro.html:164
+#, python-format
+msgid ""
+"We have a small team spread around several "
+"continents, working to advance\n"
+"different aspects of the project. We are very open to other developers who "
+"want to get involved and\n"
+"anyone else who would like to contribute in other ways, such as critiques, "
+"peer review, testing,\n"
+"writing I2P enabled applications, or documentation. The entire system is "
+"open source - the router\n"
+"and most of the SDK are outright public domain with some BSD and Cryptix "
+"licensed code, while some\n"
+"applications like I2PTunnel and I2PSnark are GPL. Almost everything is "
+"written in Java (1.5+),\n"
+"though some third party applications are being written in Python and other "
+"languages. The code works\n"
+"on Sun Java SE and other Java Virtual "
+"Machines."
+msgstr ""
+"Nous sommes une petite équipe répartie sur "
+"plusieurs continents, qui travaille ?| \n"
+"l'avancement de différents aspects du projet.  Nous sommes complètement "
+"ouverts ?|  l'arrivée d'autre développeurs\n"
+"qui voudraient s'impliquer et ?|  celle de quiconque préfèrerait participer "
+"d'autres façons, telles que la critique,\n"
+"l'analyse de pair, le test, l'écriture d'applications compatibles, ou de "
+"documentation. Le système est totalement\n"
+"\"open source\": le routeur et presque tout l'outil de développement sont de "
+"plein droit dans le domaine public avec\n"
+"quelques lignes de code sous licence BSD et Cryptix, et quelques "
+"applications comme I2PTunnel\n"
+"et I2PSnark sous GPL. Presque tout est écrit en Java (1.5+), bien que "
+"quelques applications tierce partie soient\n"
+"écrites en Python et autres langages. Le code fonctionne sur Oracle/Sun Java SE et\n"
+"d'autres Machines Virtuelles Java."
+
+#: pages/site/docs/how/intro.html:175
+msgid "Where?"
+msgstr "Où?"
+
+#: pages/site/docs/how/intro.html:176
+#, python-format
+msgid ""
+"Anyone interested should join us on the IRC channel #i2p (hosted "
+"concurrently on irc.freenode.net,\n"
+"irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de). "
+"There are currently no\n"
+"scheduled development meetings, however archives "
+"are available."
+msgstr ""
+"Toute personne intéressée peut nous joindre sur le canal IRC #i2p "
+"actuellement hébergé\n"
+"sur les serveurs irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, irc."
+"welterde.i2p et irc.einirc.de.\n"
+"Il n'y a pas de rencontre de développement planifiée actuellement, mais\n"
+"les archives sont disponibles."
+
+#: pages/site/docs/how/intro.html:182
+#, python-format
+msgid ""
+"The current source is available in monotone."
+msgstr ""
+"Le code source est disponible dans monotone."
+
+#: pages/site/docs/how/intro.html:186
+msgid "Additional Information"
+msgstr "Plus d'infos"
+
+#: pages/site/docs/how/intro.html:187
+#, python-format
+msgid "See the Index to Technical Documentation."
+msgstr ""
+"Voir la table des matières de la documentation "
+"technique."
+
diff --git a/i2p2www/translations/sv/LC_MESSAGES/messages.po b/i2p2www/translations/sv/LC_MESSAGES/messages.po
new file mode 100644
index 00000000..e3470e4f
--- /dev/null
+++ b/i2p2www/translations/sv/LC_MESSAGES/messages.po
@@ -0,0 +1,27292 @@
+# Swedish translations for I2P.
+# Copyright (C) 2013 ORGANIZATION
+# This file is distributed under the same license as the I2P project.
+#
+# Translators:
+# , 2013.
+msgid ""
+msgstr ""
+"Project-Id-Version:  I2P\n"
+"Report-Msgid-Bugs-To: https://trac.i2p2.de/\n"
+"POT-Creation-Date: 2013-02-06 20:57+0000\n"
+"PO-Revision-Date: 2013-02-05 17:57+0000\n"
+"Last-Translator: hottuna \n"
+"Language-Team: Swedish (Sweden) "
+"(http://www.transifex.com/projects/p/I2P/language/sv_SE/)\n"
+"Plural-Forms: nplurals=2; plural=(n != 1)\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Generated-By: Babel 0.9.6\n"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:2
+msgid "0.9.3 Release"
+msgstr "0.9.3 Release"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:7
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:9
+msgid ""
+"0.9.3 includes extensive low-level changes to the queueing of messages in"
+" the router.  We implement the CoDel Active Queue Management (AQM) "
+"algorithm.  We also unify the queueing and priority mechanisms in the "
+"transports to aid diagnosis and reduce network latency.  Work continues "
+"on fixing UDP transport bugs and making UDP more resistant to attacks.  "
+"There are more changes to improve the performance of the router and "
+"reduce its memory usage.  Also, we enable i2psnark's DHT support, "
+"introduced last release, by default."
+msgstr ""
+"0.9.3 inkluderar utförliga låg-nivå förändringar vid köandet av "
+"meddelanden i routern. "
+"Vi implementerar CoDel Active Queue Management (AQM) algoritmen. "
+"Vi förenar även kö och prioritets mekanismerna i transportlagret för att "
+"underlätta diagnos och reducera nätverksfördröjningar. "
+"Arbete fortsätter med att korrigera buggar i UDP transportlagret och att "
+"göra UDP mer motståndskraftigt mot attacker. "
+"Det finns fler förändringar som förbättrar prestandan av routern och "
+"reducerar dess minnesanvändning. "
+"Vi slår även på i2psnarks DHT-stöd, som introducerades i förra releasen, "
+"som standard."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:12
+msgid ""
+"As usual, there's also lots of bug fixes in this release, so updating is "
+"recommended."
+msgstr ""
+"Som vanligt finns även många buggficar i denhär releasen, så uppdatering "
+"rekommenderas."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:16
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:26
+msgid "Files are available on the `download page`_."
+msgstr "Filerna finns på `nerladdningssidan`_."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:20
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:30
+msgid "`download page`"
+msgstr "`nerladdningssidan`"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:22
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:32
+msgid "RELEASE DETAILS"
+msgstr "RELEASE DETALJER"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:24
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:34
+msgid "Major Changes"
+msgstr "Stora Förändringar"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:26
+msgid "Active Queue Management"
+msgstr "Active Queue Management"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:27
+msgid "Priority queues"
+msgstr "Prioritetsköer"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:28
+msgid "I2PSnark DHT: Several bug fixes, enable by default."
+msgstr "I2PSnark DHT: Flera buggfixar, påslaget som standard."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:30
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:39
+msgid "Bug Fixes"
+msgstr "Buggfixar"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:32
+msgid ""
+"Several SSU fixes including memory leak, and better handling of routers "
+"behind firewalls that change UDP ports; additional defenses for malicious"
+" packets."
+msgstr ""
+"Flera SSU-fixar inklusive minnesläcka, bättra hantering av routrar bakom "
+"brandväggar som byter UDP-port och ytterliggare försvar mot illvilliga "
+"paket."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:33
+msgid "Fix piece selection (rarest-first) bugs in i2psnark"
+msgstr "Fixa del val (ovanligaste först)  buggar i i2psnark"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:34
+msgid "Fix bug causing multiple browsers to open at startup"
+msgstr "Fixa bugg som får multipla webbläsare att öppnas vid start"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:36
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:51
+msgid "Other"
+msgstr "Andra"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:38
+msgid "Improvements in caching"
+msgstr "Förbättringar i caching."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:39
+msgid "Several synchronization fixes and lock contention reduction"
+msgstr "Flera synkroniserings-fixar och minskning i lås-kamp."
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:40
+msgid "Major reduction in SSU buffers memory use"
+msgstr "Stor förminskning i SSU-bufferns minnesanvändning"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:41
+msgid ""
+"Fix streaming connection timeout back to 1 minute, was inadvertently "
+"changed to 5 minutes; set i2ptunnel server read timeout to 5 minutes, was"
+" unlimited"
+msgstr ""
+"Fixa timeout för strömmande anslutningar tillbaka till 1 minut, råkades "
+"ändras till 5 minuter. Sätt i2ptunnel server timout till 5 minuter, was "
+"obegränsad"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:42
+msgid "Improved defenses in i2ptunnel for \"darkloris\""
+msgstr "Förbättra försvaret mot \"darkloris\" attacker i i2ptunnel"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:43
+msgid "More validation at torrent creation in i2psnark"
+msgstr "Mera validering vid torrent-skapning i i2psnark"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:44
+msgid "Several parameter changes in SSU to improve throughput"
+msgstr "Flera parameterförändringar i SSU för att förbättra genomströming"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:45
+msgid ""
+"New event log for major events including restarts; show multiple restart "
+"lines on graphs"
+msgstr ""
+"Ny händelselogg för stora händelser som omstarter, visa flera "
+"omstartningslinjer på grafer"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:46
+msgid "Remove duplicate messages from logs"
+msgstr "Ta bort duplicerade meddelanden från loggar"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:47
+msgid "Don't respond to blocked streaming connections with a reset, just drop"
+msgstr ""
+"Svara inte på blockerade strömmande anslutningar med ett 'reset' "
+"kommando, bara släpp"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:48
+msgid "Remove all uses of inefficient SimpleTimer"
+msgstr "Ta bort alla användningar av den ineffektiva SimpleTimer"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:49
+msgid "More checks for valid IPs and ports entered in console"
+msgstr "Flera kontroller för giltiga IP-adresser och portar inskrivna i konsollen"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:50
+msgid "Fix bug that wasted a lot of entropy"
+msgstr "Fixa en bugg som slösade mycket entropi"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:51
+msgid "Translation updates: Italian, Portuguese, Spanish, Swedish"
+msgstr "Översättningsuppdateringar: Italienska, Portugisiska, Spanska, Svenska"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:52
+msgid "Add non-NIO configuration in jetty.xml, recommended for Java 5"
+msgstr "La till icke-NIO konfiguration i jetty.xml, rekommenderas för Java 5"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:53
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:63
+msgid "Update GeoIP data (new installs and PPA only)"
+msgstr "Uppdatera GeoIP data (enbart nya installationer och PPA)"
+
+#: i2p2www/blog/2012/10/27/0.9.3-Release.rst:56
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:67
+msgid "SHA256 Checksums:"
+msgstr "SHA256 Kontrollsummor:"
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:2
+msgid "0.9.4 Release"
+msgstr "0.9.4 Release"
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:7
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:9
+msgid ""
+"0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, "
+"that was reducing network performance and reliability. It also includes "
+"major changes in the in-network update system, and adds the capability to"
+" update via in-network torrents."
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:13
+msgid ""
+"We fixed several bugs in the i2psnark DHT implementation that was "
+"introduced\n"
+"last release. For those of you using console or http proxy passwords,\n"
+"we converted to the more-secure digest method and improved the security "
+"for console forms."
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:19
+msgid ""
+"For those of you already running development builds, your router should "
+"automatically\n"
+"update to 0.9.4-0 using the new in-network torrent facility.\n"
+"For those running 0.9.3-0, you will update normally using in-network "
+"HTTP, and\n"
+"we will have more information for you when we release 0.9.5."
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:36
+msgid ""
+"Big rework of the update system; Preliminary support for updates via "
+"i2psnark"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:37
+msgid "Add per-destination outbound priorities"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:41
+msgid ""
+"Fix major bug that reduced SSU connection limits which reduced tunnel "
+"build success rates"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:42
+msgid "Fix bug with external I2CP that prevented some external apps from working"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:43
+msgid "Fixed several bugs in i2psnark DHT"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:44
+msgid "Fixed bug in i2psnark PEX that inflated peer counts"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:45
+msgid "Handle dropped I2CP messages better"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:46
+msgid "Reduce overhead of I2CP messages"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:47
+msgid "Enforce max size in transport outbound message queues"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:48
+msgid "Fixes for Windows eepget.bat (new installs and PPA only)"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:49
+msgid "Fix a bug that would drop messages of exactly 512 bytes in SSU"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:53
+msgid ""
+"More performance improvements, memory reduction, and object churn "
+"reduction"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:54
+msgid "Better detection of network disconnections"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:55
+msgid "Further improvements in the SSU transport"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:56
+msgid "Add console password form"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:57
+msgid ""
+"Convert http proxy and console from basic to digest authentication for "
+"added security"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:58
+msgid ""
+"Improved verification of console form submissions, using jsp sessions. "
+"Cookies may now be required on forms, except when the console password is"
+" enabled"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:59
+msgid ""
+"Initial work on new interfaces to manage applications started via "
+"clients.config"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:60
+msgid "Increase minimum peer port to 1024"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:61
+msgid "Increase granularity of bandwidth limiter for smoother transmissions"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:62
+msgid ""
+"Translation updates: Chinese, French, German, Italian, Polish, "
+"Portuguese, Swedish, and Ukrainian"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:64
+msgid "Update wrapper to 3.5.16 (new installs and PPA only)"
+msgstr ""
+
+#: i2p2www/blog/2012/12/17/0.9.4-Release.rst:65
+msgid "New ARMv6 wrapper for Raspberry Pi"
+msgstr ""
+
+#: i2p2www/pages/blog/category.html:2
+msgid "Blog Category"
+msgstr ""
+
+#: i2p2www/pages/blog/category.html:4
+#, python-format
+msgid "I2P Blog ATOM Feed for Category: %(category)s"
+msgstr ""
+
+#: i2p2www/pages/blog/index.html:2
+msgid "Blog Index"
+msgstr ""
+
+#: i2p2www/pages/blog/index.html:4 i2p2www/pages/site/index.html:75
+msgid "I2P Blog ATOM Feed"
+msgstr ""
+
+#: i2p2www/pages/blog/latest.html:5
+msgid "More blog posts…"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:4
+msgid "Debian I2P Packages"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:6
+#, python-format
+msgid ""
+"The packages hosted on the I2P Launchpad site\n"
+"have been tested and should work on x86/x86_64 platforms running:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:11
+msgid "Ubuntu (Hardy 8.04 and newer)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:13
+msgid ""
+"Debian Linux (Lenny and newer) & kFreeBSD (Wheezy)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:21
+#, python-format
+msgid ""
+"The I2P packages may work on systems not listed above. Please "
+"report any issues\n"
+"with these packages on Trac at\n"
+"http://%(trac)s."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:27
+msgid ""
+"Option 1: Recent versions of Ubuntu and its "
+"derivatives (Try this if you're not using Debian)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:28
+msgid ""
+"Option 2: Debian (including systems based on "
+"Debian and older versions of Ubuntu)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:29
+msgid ""
+"Option 3: Non-Linux (and possibly Non-x86 "
+"architectures)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:32
+msgid ""
+"Instructions for Ubuntu Lucid Lynx (and newer) and derivatives like Linux"
+" Mint & Trisquel"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:33
+msgid "Adding the PPA via the command line and installing I2P"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:36
+msgid "Open a terminal and enter:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:38
+msgid ""
+"This command will add the PPA to /etc/apt/sources.list.d and fetch the\n"
+"gpg key that the repository has been signed with. The GPG key ensures\n"
+"that the packages have not been tampered with since being built."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:45
+msgid "Notify your package manager of the new PPA by entering:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:47
+msgid ""
+"This command will retrieve the latest list of software from each\n"
+"repository that is enabled on your system, including the I2P PPA that\n"
+"was added with the earlier command."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:53
+#: i2p2www/pages/downloads/debian.html:118
+#: i2p2www/pages/downloads/debian.html:141
+msgid "You are now ready to install I2P!"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:57
+msgid "Adding the PPA Using Synaptic"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:60
+msgid ""
+"Open Synaptic (System -> Administration -> Synaptic Package "
+"Manager)."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:65
+msgid ""
+"Once Synaptic opens, select Repositories from the "
+"Settings menu."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:70
+msgid ""
+"Click the Other Sources tab and click Add. Paste "
+"ppa:i2p-maintainers/i2p into the APT-line field and click "
+"Add Source. Click the Close button then "
+"Reload."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:75
+msgid ""
+"In the Quick Filter box, type in i2p and press enter. When "
+"i2p is returned in the results list, right click "
+"i2p and select Mark for Installation. After doing "
+"so you may see a Mark additional required changes? popup. If so,"
+" click Mark then Apply."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:81
+msgid ""
+"After the installation process completes you can move on to the next\n"
+"part of starting I2P and configuring "
+"it for your system."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:86
+msgid "Instructions for Debian Lenny and newer"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:88
+msgid ""
+"The steps below should be performed with root access (i.e., switching\n"
+"user to root with \"su\" or by prefixing each command with \"sudo\")."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:94
+msgid "Add the GPG key that signs the repository with the following command:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:96
+msgid "You'll have output like the following if the command was successful:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:100
+msgid ""
+"For Debian Oldstable (Lenny) and Stable (Squeeze): Add the following "
+"entries to /etc/apt/sources.list.d/i2p.list"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:104
+msgid "For Debian Testing (Wheezy) or Unstable (Sid), use the following:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:109
+msgid "Notify your package manager of the new PPA by entering"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:111
+msgid ""
+"This command will retrieve the latest list of software from every\n"
+"repository enabled on your system, including the I2P PPA added in step\n"
+"1."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:122
+#: i2p2www/pages/downloads/debian.html:151
+msgid ""
+"After the installation process completes you can move on to the next part"
+" of starting I2P and configuring it "
+"for your system."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:126
+msgid "Instructions for Non-Linux / Non-x86"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:128
+msgid ""
+"The steps below should be performed with root access (i.e., switching\n"
+"user to root with \"su\" or by prefixing each command with "
+"\"sudo\")."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:134
+msgid ""
+"Download the i2p-router package from the"
+" PPA."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:139
+msgid ""
+"Make sure that you have Java installed. Running apt-get install"
+" default-jre should be sufficient."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:145
+#, python-format
+msgid ""
+"It is recommended to compile jbigi for your "
+"system to achieve better performance. Instructions are available here."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:155
+#: i2p2www/pages/downloads/list.html:165
+msgid "Post-install work"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:158
+msgid ""
+"Using these I2P packages the I2P router can be started in the following\n"
+"three ways:"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:164
+msgid ""
+""on demand" using the i2prouter script. Simply run "
+""i2prouter\n"
+"start" from a command prompt. (Note: Do "
+"not use\n"
+"sudo or run it as root!)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:171
+msgid ""
+""on demand" without the java service wrapper\n"
+"(needed on non-Linux/non-x86 systems) by running \"i2prouter-"
+"nowrapper\".\n"
+"(Note: Do not\n"
+"use sudo or run it as root!)"
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:179
+msgid ""
+"as a service that automatically runs when your system boots, even\n"
+"before logging in. The service can be enabled with \"dpkg-"
+"reconfigure\n"
+"i2p\" as root or using sudo. This is the recommended means of "
+"operation."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:187
+msgid ""
+"When installing for the first time, please remember to adjust your "
+"NAT/firewall\n"
+"if you can. The ports to forward can be found on the \n"
+"network configuration page in the router console. If guidance with "
+"respect to forwarding ports is needed,\n"
+"you may find portforward.com to be"
+" helpful."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:194
+msgid ""
+"Please review and adjust the bandwidth settings on the\n"
+"configuration page,\n"
+"as the default settings of 96 KB/s down / 40 KB/s up are fairly "
+"conservative."
+msgstr ""
+
+#: i2p2www/pages/downloads/debian.html:200
+#: i2p2www/pages/downloads/list.html:198
+#, python-format
+msgid ""
+"If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy "
+"howto."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:2 i2p2www/pages/downloads/select.html:12
+#: i2p2www/pages/global/nav.html:3
+msgid "Download"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:4
+msgid "Download I2P"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:6
+msgid "Dependency"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:7
+#, python-format
+msgid ""
+"\n"
+"Java Runtime 1.5 or higher.\n"
+"(Oracle/Sun Java Version 6,\n"
+"OpenJDK 6, or\n"
+"IcedTea6\n"
+" recommended)\n"
+"
            \n"
+"Determine"
+" your installed Java version here\n"
+"or type java -version at your command prompt.\n"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:20
+msgid "Clean installs"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:34
+msgid "Download that file and run it."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:51
+msgid ""
+"Download that file and double-click it (if that works) or\n"
+"    type java -jar i2pinstall_0.9.4-1_osx.jar in a terminal "
+"to run the\n"
+"    installer.\n"
+"    You may be able to right-click and select\n"
+"    "Open with Java"."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:59
+#, python-format
+msgid ""
+"Due to a wrapper bug, the 0.9.4 installer\n"
+"      will NOT work on OS X. Use the fixed 0.9.4-1 OSX installer "
+"above."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:65 i2p2www/pages/downloads/list.html:92
+msgid "Command line (headless) install:"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:66
+msgid ""
+"Download the 0.9.4-1 OSX graphical installer file above and\n"
+"    run java -jar i2pinstall_0.9.4-1_osx.jar -console from "
+"the command line."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:84
+#, python-format
+msgid ""
+"Download that file and double-click it (if that works) or\n"
+"    type java -jar i2pinstall_%(i2pversion)s.jar in a "
+"terminal to run the\n"
+"    installer.\n"
+"    On some platforms you may be able to right-click and select\n"
+"    "Open with Java"."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:93
+#, python-format
+msgid ""
+"Download the graphical installer file above and\n"
+"    run java -jar i2pinstall_%(i2pversion)s.jar -console "
+"from the command line."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:103
+msgid "Packages for Debian & Ubuntu are available."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:118
+#, python-format
+msgid ""
+"The Android version of I2P is being actively developed.\n"
+"    The latest dev build is version 0.9.3-5_b2-API8, and is available "
+"from\n"
+"    sponge's eepsite -\n"
+"    scan or click the QR code."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:125
+msgid ""
+"The release and dev versions of the I2P APK are not compatible, as they\n"
+"      are signed by zzz and sponge respectively. Uninstall one before "
+"installing\n"
+"      the other."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:135
+msgid "Source package"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:145
+#, python-format
+msgid ""
+"Alternately, you can fetch the source from monotone.\n"
+"    
            \n"
+"    Run (tar xjvf i2psource_%(i2pversion)s.tar.bz2 ; cd "
+"i2p-%(i2pversion)s ; ant pkg) then either\n"
+"    run the GUI installer or headless install as above."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:156
+#, python-format
+msgid ""
+"The files are signed by zzz,\n"
+"whose key is here."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:161
+msgid ""
+"I2P can also be downloaded from our project pages on Launchpad and Google Code."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:167
+msgid ""
+"After running the installer on windows, simply click on the \"Start I2P\""
+" button\n"
+"which will bring up the router console,\n"
+"which has further instructions."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:173
+msgid ""
+"On Unix-like systems, I2P can be started as a service\n"
+"using the \"i2prouter\" script, located in the directory you selected for"
+" I2P.\n"
+"Changing to that directory in a console and issuing \"sh i2prouter "
+"status\"\n"
+"should tell you the router's status. The arguments \"start\", \"stop\" "
+"and \"restart\"\n"
+"control the service. The router console\n"
+"can be accessed at its usual location.\n"
+"For users on OpenSolaris and other systems for which the wrapper (i2psvc)"
+" is not supported,\n"
+"start the router with \"sh runplain.sh\" instead."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:184
+#, python-format
+msgid ""
+"When installing for the first time, please remember to adjust your "
+"NAT/firewall\n"
+"if you can, bearing in mind the Internet-facing ports I2P uses,\n"
+"described here among other ports.\n"
+"If you have successfully opened your port to inbound TCP, also enable "
+"inbound TCP on the\n"
+"configuration page."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:192
+msgid ""
+"Also, please review and adjust the bandwidth settings on the\n"
+"configuration page,\n"
+"as the default settings of 96 KBps down / 40 KBps up are fairly slow."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:202
+msgid "Updates from earlier releases:"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:204
+msgid "Both automatic and manual upgrades are available for the release."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:209
+msgid "Automatic updates"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:211
+msgid ""
+"If you are running 0.7.5 or later, your router should detect the\n"
+"new release. To upgrade simply click the 'Download Update' button on your"
+" router console\n"
+"when it appears."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:217
+msgid ""
+"Due to a bug in release 0.7.6, those whose first I2P installation was "
+"that version\n"
+"and have not upgraded manually\n"
+"may get a \"downloaded version is not greater than current version\" "
+"error,\n"
+"and should use the manual update method below."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:225
+#, python-format
+msgid ""
+"If you are running 0.7.4 or earlier, please see\n"
+"the 0.7.5 release notes\n"
+"for important information about how to configure your router to "
+"automatically\n"
+"receive the release."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:233
+#, python-format
+msgid ""
+"If you are running 0.6.1.30 or earlier, please see\n"
+"instructions\n"
+"for important information about how to configure your router to "
+"automatically\n"
+"receive the release."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:242
+#, python-format
+msgid ""
+"If you have reconfigured your router following the instructions, you should see a link on your"
+" \n"
+"    router console "
+"allowing\n"
+"    you to download and install the new release by just clicking on that\n"
+"    link."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:250
+msgid "Alternately, you can use the manual method specified below."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:260
+msgid "Manual updates"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:272
+msgid ""
+"Download that file to your I2P\n"
+"    installation directory and rename as i2pupdate.zip.\n"
+"    (alternately, you can get the source as above and run \"ant "
+"updater\", then copy the\n"
+"    resulting i2pupdate.zip to your I2P installation directory).  You do"
+" \n"
+"    NOT need to unzip that file."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:281
+msgid "Click \"Restart\""
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:286
+msgid "Grab a cup of coffee and come back in 11 minutes"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:294
+#, python-format
+msgid ""
+"The file is signed by zzz,\n"
+"whose key is here."
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:299
+msgid "Previous Releases"
+msgstr ""
+
+#: i2p2www/pages/downloads/list.html:301
+#, python-format
+msgid ""
+"Previous releases are available on Google "
+"Code\n"
+"and Launchpad\n"
+"and within the I2P network on %(echelon)s."
+msgstr ""
+
+#: i2p2www/pages/downloads/select.html:2 i2p2www/pages/downloads/select.html:4
+msgid "Mirror selection"
+msgstr ""
+
+#: i2p2www/pages/downloads/select.html:5
+msgid "File:"
+msgstr ""
+
+#: i2p2www/pages/downloads/select.html:10
+msgid "Any mirror"
+msgstr ""
+
+#: i2p2www/pages/global/bounty.html:19
+msgid ""
+"To claim the bounty the author must not be paid by other organizations\n"
+"or teams for this work (e.g. GSoC students are not valid)."
+msgstr ""
+
+#: i2p2www/pages/global/bounty.html:29
+#, python-format
+msgid ""
+"Bounty amounts may be increased by further donations.  Do\n"
+"you think these are important? Add in your "
+"donation, \n"
+"marking the amount for the %(donatename)s bounty!"
+msgstr ""
+
+#: i2p2www/pages/global/error_404.html:3
+msgid "Not found"
+msgstr ""
+
+#: i2p2www/pages/global/error_404.html:9
+msgid ""
+"Yep... the resource, you were searching for, is named differently, "
+"doesn't exist or was removed."
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:5
+msgid "Server error"
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:13
+msgid "500 Server error"
+msgstr ""
+
+#: i2p2www/pages/global/error_500.html:17
+msgid "Umm... the server encountered some sort of error."
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:2
+msgid "Mirrors"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:10
+msgid "Secure"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:16
+msgid "Misc."
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:19 i2p2www/pages/site/links.html:2
+msgid "Links"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:20
+msgid "Impressum"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:24
+msgid "T-Shirts!"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:26
+msgid "Europe"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:27
+msgid "USA"
+msgstr ""
+
+#: i2p2www/pages/global/footer.html:31
+#: i2p2www/pages/site/get-involved/donate.html:2
+#: i2p2www/pages/site/get-involved/index.html:74
+msgid "Donate"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:28
+msgid "Skip navigation"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:31
+msgid "I2P Logo"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:31 i2p2www/pages/site/index.html:3
+#: i2p2www/pages/site/about/intro.html:4
+msgid "The Invisible Internet Project"
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:55
+#, python-format
+msgid ""
+"This page was last updated in %(lastupdated)s and is accurate for router "
+"version %(accuratefor)s."
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:59
+#, python-format
+msgid "This page was last updated in %(lastupdated)s."
+msgstr ""
+
+#: i2p2www/pages/global/layout.html:63
+#, python-format
+msgid "This page is accurate for router version %(accuratefor)s."
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:4
+msgid "About"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:6
+msgid "Introduction to I2P"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:7
+msgid "Comparisons"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:9
+msgid "Overview of comparisons"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:13
+msgid "Other anonymous networks"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:16
+#: i2p2www/pages/site/get-involved/index.html:29
+msgid "Documentation"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:18
+msgid "Documentation index"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:19 i2p2www/pages/site/about/intro.html:17
+msgid "How does it work?"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:21
+msgid "Gentle intro"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:22
+msgid "Tech intro"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:23
+msgid "Threat model"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:24
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:292
+msgid "Garlic routing"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:25
+msgid "Network database"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:26
+msgid "Tunnel routing"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:27
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:21
+msgid "Peer selection"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:28
+#: i2p2www/pages/site/docs/how/tech-intro.html:17
+#: i2p2www/pages/site/docs/how/tech-intro.html:458
+msgid "Cryptography"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:29
+msgid "ElGamal/AES+SessionTags"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:32 i2p2www/pages/global/nav.html:115
+#: i2p2www/pages/site/docs/spec/configuration.html:75
+#: i2p2www/pages/site/get-involved/index.html:48
+msgid "Applications"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:34
+msgid "Supported applications"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:35
+msgid "Bittorrent"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:38
+#: i2p2www/pages/site/docs/api/streaming.html:58
+msgid "API"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:46 i2p2www/pages/global/nav.html:76
+#: i2p2www/pages/site/docs/how/tech-intro.html:808
+msgid "Streaming library"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:47
+msgid "Ministreaming library"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:48 i2p2www/pages/global/nav.html:71
+#: i2p2www/pages/site/docs/index.html:87
+#: i2p2www/pages/site/docs/api/datagrams.html:2
+#: i2p2www/pages/site/get-involved/develop/applications.html:250
+msgid "Datagrams"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:52
+msgid "Protocols"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:54
+msgid "Protocol stack"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:59
+#: i2p2www/pages/site/docs/how/cryptography.html:394
+msgid "Transports"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:61 i2p2www/pages/site/docs/index.html:157
+msgid "Transport layer overview"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:66
+msgid "Specifications"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:68
+msgid "Blockfile"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:69
+msgid "Common structures"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:70
+msgid "Configuration files"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:74 i2p2www/pages/global/nav.html:90
+#: i2p2www/pages/site/docs/plugins.html:2
+#: i2p2www/pages/site/docs/spec/configuration.html:65
+msgid "Plugins"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:77
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:230
+msgid "Tunnel creation"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:78
+msgid "Tunnel messages"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:79
+msgid "Software updates"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:82 i2p2www/pages/site/docs/index.html:138
+#: i2p2www/pages/site/docs/how/tech-intro.html:14
+#: i2p2www/pages/site/docs/how/tech-intro.html:228
+msgid "Tunnels"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:84
+msgid "Tunnel implementation"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:85
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:288
+msgid "Unidirectional tunnels"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:86
+msgid "Old implementation"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:89
+msgid "Naming and addressbook"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:93 i2p2www/pages/site/about/team.html:2
+msgid "Team"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:94
+msgid "Blog"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:95
+msgid "Hall of Fame"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:96
+msgid "Academic papers and peer review"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:97
+msgid "Presentations, tutorials and articles"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:98
+msgid "Contact us"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:101
+msgid "Help"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:103
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:169
+msgid "FAQ"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:104
+msgid "How to browse I2P"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:105 i2p2www/pages/site/about/glossary.html:2
+msgid "Glossary"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:106
+#: i2p2www/pages/site/about/performance/index.html:2
+#: i2p2www/pages/site/docs/index.html:182
+#: i2p2www/pages/site/get-involved/todo.html:52
+#: i2p2www/pages/site/get-involved/todo.html:456
+msgid "Performance"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:107 i2p2www/pages/site/contact.html:22
+msgid "Forums"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:110
+msgid "Volunteer"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:112
+msgid "Get involved!"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:113
+msgid "Develop"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:116
+#: i2p2www/pages/site/get-involved/develop/licenses.html:2
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:115
+msgid "Licenses"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:117
+msgid "Release signing keys"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:118
+msgid "Signed keys"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:119
+msgid "Developers keys"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:120 i2p2www/pages/site/docs/index.html:220
+msgid "Bug tracker"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:123
+msgid "Academic research"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:124
+msgid "Guides"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:126
+msgid "New developers"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:127
+#: i2p2www/pages/site/get-involved/guides/ides.html:2
+msgid "Using an IDE with I2P"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:128
+msgid "Developer guidelines and coding style"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:129
+#: i2p2www/pages/site/get-involved/guides/monotone.html:2
+msgid "Monotone"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:130
+msgid "New translators"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:133
+#: i2p2www/pages/site/get-involved/bounties/index.html:2
+msgid "Bounties"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:134 i2p2www/pages/meetings/index.html:2
+msgid "Meetings"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:135
+#: i2p2www/pages/site/get-involved/roadmap.html:2
+msgid "Roadmap"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:136
+msgid "Task list"
+msgstr ""
+
+#: i2p2www/pages/global/nav.html:139
+msgid "Language"
+msgstr ""
+
+#: i2p2www/pages/meetings/index.html:4
+msgid "I2P Meetings ATOM Feed"
+msgstr ""
+
+#: i2p2www/pages/meetings/index.html:7
+msgid "Logs of past I2P meetings"
+msgstr ""
+
+#: i2p2www/pages/meetings/index.html:9
+#, python-format
+msgid ""
+"If you have something to discuss, please find the developers on IRC in "
+"#i2p-dev.\n"
+"Status updates from developers are also "
+"available."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:2
+msgid "Contact"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:5
+msgid ""
+"Our primary IRC network is the Irc2P network within I2P; a default tunnel"
+" to this network is set up with new router installs.\n"
+"  We are also present on multiple standard networks like OFTC,\n"
+"  EIN and Freenode.\n"
+"  All I2P-related channels on all these network are linked to the main "
+"channels on Irc2P via relay bots."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:13
+msgid "Channel list:"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:15
+msgid "General i2p discussion"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:16
+msgid "Offtopic"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:17
+msgid "Development talk"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:18
+msgid "Help channel"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:23
+#, python-format
+msgid ""
+"Most of the discussion about I2P's development happens on the I2P developer forum. This is usually the best"
+" place to start with inquiries, if the dev IRC channel is inactive."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:27
+msgid "Mailing lists"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:28
+msgid ""
+"I2P does have a mailing list, but it is rarely used as the current small "
+"team of developers prefer to communicate via IRC or the developer forum. "
+"This may change in future."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:33
+msgid "Subscribing"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:34
+msgid ""
+"To subscribe to a mailing list, go to the list information page (linked "
+"below) and fill out the form. I2P-internal email addresses "
+"(foobar@mail.i2p) can be used."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:38
+msgid "Unsubscribing"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:39
+msgid ""
+"To unsubscribe from a mailing list or edit your subscription options, go "
+"to the list information page (linked below) and enter your subscription "
+"email address."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:43
+msgid "Lists"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:46
+msgid "Archive"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:47
+msgid ""
+"General I2P discussion - anything that doesn't fit in a different list "
+"goes here."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:53
+msgid ""
+"You don't like mailing lists? Then this is for you. All mailing lists are"
+" available via NNTP as well."
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:58
+msgid "Group-List-mapping:"
+msgstr ""
+
+#: i2p2www/pages/site/contact.html:62
+msgid "Servers:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:2
+msgid "Frequently Asked Questions"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:4
+#: i2p2www/pages/site/docs/how/threat-model.html:121
+msgid "Index"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:7
+msgid "General"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:9 i2p2www/pages/site/faq.html:51
+msgid "What systems will I2P run on?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:10
+msgid "Whats an \"eepsite\" and how do I configure my browser so I can use them?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:11 i2p2www/pages/site/faq.html:263
+msgid "My router has very few active peers, is this OK?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:12 i2p2www/pages/site/faq.html:498
+msgid "What do the Active x/y numbers mean in the router console?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:13 i2p2www/pages/site/faq.html:225
+msgid ""
+"My active peers / known peers / participating tunnels / connections / "
+"bandwidth vary dramatically over time! Is anything wrong?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:14 i2p2www/pages/site/faq.html:348
+msgid "Is using an outproxy safe?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:15 i2p2www/pages/site/faq.html:374
+msgid "Most of the eepsites within I2P are down?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:16 i2p2www/pages/site/faq.html:527
+msgid "What ports does I2P use?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:17
+msgid "Why is I2P listening for connections on port 32000?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:18 i2p2www/pages/site/faq.html:62
+msgid "I think I found a bug, where can I report it?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:19 i2p2www/pages/site/faq.html:107
+msgid "What happened to *.i2p.net? What happened to jrandom? Is I2P dead?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:20 i2p2www/pages/site/faq.html:845
+msgid "I have a question!"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:22
+#: i2p2www/pages/site/docs/api/streaming.html:292
+msgid "Setup"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:24 i2p2www/pages/site/faq.html:232
+msgid ""
+"My router has been up for several minutes and has zero or very few "
+"connections"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:25 i2p2www/pages/site/faq.html:390
+msgid "Why is I2P so slow?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:26 i2p2www/pages/site/faq.html:79
+msgid ""
+"I'm missing lots of hosts in my addressbook. What are some good "
+"subscription links?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:27 i2p2www/pages/site/faq.html:383
+msgid "How do I set up my own eepsite?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:28 i2p2www/pages/site/faq.html:416
+msgid "Bittorrent / I2PSnark / Azureus I2P Plugin Questions?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:29 i2p2www/pages/site/faq.html:423
+msgid "How do I connect to IRC within I2P?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:30 i2p2www/pages/site/faq.html:281
+msgid "I can't access regular Internet sites through I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:31 i2p2www/pages/site/faq.html:296
+msgid "I can't access https:// or ftp:// sites through I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:32 i2p2www/pages/site/faq.html:506
+msgid "Is it possible to use I2P as a SOCKS proxy?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:33 i2p2www/pages/site/faq.html:489
+msgid "How do I configure my browser?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:34 i2p2www/pages/site/faq.html:434
+msgid ""
+"How can I access the web console from my other machines or password "
+"protect it?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:35 i2p2www/pages/site/faq.html:474
+msgid "How can I use applications from my other machines?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:36 i2p2www/pages/site/faq.html:748
+msgid "How do I reseed manually?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:37 i2p2www/pages/site/faq.html:124
+msgid "My router is using too much CPU?!?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:39
+msgid "Misconception"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:41 i2p2www/pages/site/faq.html:366
+msgid ""
+"How do I access IRC, BitTorrent, or other services on the regular "
+"Internet?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:42
+msgid ""
+"Is my router an \"exit node\"(outproxy) to the regular Internet? I don't "
+"want it to be."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:43 i2p2www/pages/site/faq.html:188
+msgid ""
+"I am opposed to certain types of content. How do I keep from "
+"distributing, storing, or accessing them?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:45
+msgid "Errors and Their Solutions"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:47 i2p2www/pages/site/faq.html:784
+msgid ""
+"I'm using FreeBSD and when I start I2P I receive an error about "
+"libm.so.4!"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:48
+msgid ""
+"In wrapper.log I see an error stating Protocol family "
+"unavailable when I2P is loading"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:52 i2p2www/pages/site/faq.html:63
+#: i2p2www/pages/site/faq.html:80 i2p2www/pages/site/faq.html:108
+#: i2p2www/pages/site/faq.html:125 i2p2www/pages/site/faq.html:189
+#: i2p2www/pages/site/faq.html:226 i2p2www/pages/site/faq.html:233
+#: i2p2www/pages/site/faq.html:264 i2p2www/pages/site/faq.html:273
+#: i2p2www/pages/site/faq.html:282 i2p2www/pages/site/faq.html:297
+#: i2p2www/pages/site/faq.html:349 i2p2www/pages/site/faq.html:367
+#: i2p2www/pages/site/faq.html:375 i2p2www/pages/site/faq.html:384
+#: i2p2www/pages/site/faq.html:391 i2p2www/pages/site/faq.html:417
+#: i2p2www/pages/site/faq.html:424 i2p2www/pages/site/faq.html:435
+#: i2p2www/pages/site/faq.html:475 i2p2www/pages/site/faq.html:482
+#: i2p2www/pages/site/faq.html:490 i2p2www/pages/site/faq.html:499
+#: i2p2www/pages/site/faq.html:507 i2p2www/pages/site/faq.html:528
+#: i2p2www/pages/site/faq.html:736 i2p2www/pages/site/faq.html:749
+#: i2p2www/pages/site/faq.html:785 i2p2www/pages/site/faq.html:817
+#: i2p2www/pages/site/faq.html:846 i2p2www/pages/site/get-involved/todo.html:16
+#: i2p2www/pages/site/get-involved/todo.html:28
+#: i2p2www/pages/site/get-involved/todo.html:52
+msgid "link"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:53
+#, python-format
+msgid ""
+"While I2P has been reported to run PCs as meagre as a low-end Pentium II "
+"with 64 MB of RAM, you'll have a much better experience on a Pentium III "
+"(or better) with 128MB of RAM (or more). A chart comparing the performance of"
+" the various JREs can be found at http://%(trac)s/wiki/java, but in "
+"short: it's at all possible, use Sun/Oracle Java or OpenJDK."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:57
+msgid ""
+"I2P has been tested on Windows, Linux, FreeBSD (see the note below), OSX, and OpenSolaris. There is work "
+"underway to bring I2P to the Android platform."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:65
+msgid "Here are some places, pick one or more."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:71
+msgid "Discuss with the developers on IRC in #i2p-dev"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:75
+msgid "Please include relevant information from the router logs and wrapper logs."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:81
+msgid ""
+"The default subscription is to http://www.i2p2.i2p/hosts.txt which is "
+"updated rarely.\n"
+"If you don't have another subscription, you may often have to use "
+"\"jump\" links which\n"
+"is annoying."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:87
+msgid ""
+"Here are some other public addressbook subscription links. You may wish "
+"to add one or two\n"
+"to your susidns "
+"subscription list.\n"
+"You don't need to add all of them, as they sync with each other "
+"periodically.\n"
+"The links using a cgi-bin application employ various strategies to "
+"minimize\n"
+"the number of duplicate addresses delivered, so they should be more "
+"efficient.\n"
+"Note that subscribing to a hosts.txt service is an act of \"trust\", as a"
+" malicious\n"
+"subscription could give you incorrect addresses. So think about whether "
+"you\n"
+"want to trust any of these.\n"
+"The operators of these services may have various policies for listing "
+"hosts.\n"
+"Presence on this list does not imply endorsement."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:109
+msgid ""
+"Jrandom was the lead developer of I2P and\n"
+"Syndie for several years.\n"
+"We do not know if or when jrandom will return.\n"
+"The *.i2p.net domains were left in a non-functioning state after a power\n"
+"outage at the hosting company."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:117
+#, python-format
+msgid ""
+"See this page for jrandom's parting message "
+"and additional information\n"
+"on the migration of *.i2p.net to this website."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:122
+msgid "I2P remains in active development."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:126
+msgid "There are many possible causes of high CPU usage. Here is a checklist:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:131
+msgid ""
+"Try to use either OpenJDK or Sun/Oracle Java if it's available for your "
+"system. You can check \n"
+"which version of java you have installed by typing java "
+"-version at a \n"
+"command/shell prompt. Performance tends to suffer with other "
+"implementations of java."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:138
+msgid ""
+"Are you running a BitTorrent client over I2P? Try reducing the number of "
+"torrents, the bandwidth limits,\n"
+"or try turning it off completely to see if that helps."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:144
+msgid ""
+"Are your bandwidth limits set too high? It is possible that too much "
+"traffic is going through your\n"
+"I2P router and it is overloaded. Try reducing the setting for share "
+"bandwidth percentage on the configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:149
+msgid ""
+"Make sure that you're running the latest version of I2P to get the "
+"benefits of increased performance and bug fixes."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:154
+msgid ""
+"Has enough memory been set aside for use by I2P? Look at the memory graph"
+" on the graphs page to see\n"
+"if the memory usage is \"pegged\"—the JVM is spending most of its "
+"time in\n"
+"garbage collection. Increase the setting "
+"wrapper.java.maxmemory in wrapper.config."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:161
+#, python-format
+msgid ""
+"Is the CPU usage simply higher than you would like, or is it pegged at "
+"100% for a long time?\n"
+"If it's pegged, this could be a bug. Look in the logs for clues."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:167
+#, python-format
+msgid ""
+"You may be using the Java-based BigInteger library instead of the native "
+"version,\n"
+"especially if you are running on a new or unusual OS or hardware "
+"(OpenSolaris, mipsel, etc.).\n"
+"See the jbigi page for instructions on\n"
+"diagnosing, building, and testing methods."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:175
+msgid ""
+"If your native jbigi library is working fine, the biggest user of\n"
+"CPU may be routing traffic for participating tunnels. This uses CPU\n"
+"because at each hop a layer of encryption must be decoded.\n"
+"You can limit participating traffic in two ways - by reducing the\n"
+"share bandwidth on\n"
+"confignet.jsp,\n"
+"or by setting router.maxParticipatingTunnels=nnn on\n"
+"configadvanced.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:190
+msgid ""
+"Hmm. I2P is an anonymous network, so that's a tricky one.\n"
+"I2P is designed to withstand censorship, providing a means for everyone "
+"to communicate freely. \n"
+"The best way to keep your PC free of (encrypted) traffic that you dislike"
+" is to not use I2P.\n"
+"Freedom of speech has some costs.\n"
+"But let's address your question in three parts:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:199
+#, python-format
+msgid ""
+"Distribution - All traffic on I2P is encrypted in multiple layers."
+" You don't know\n"
+"a message's contents, source, or destination.\n"
+"All traffic you route is internal to the I2P network, you are not an exit node (outproxy).\n"
+"Your only alternative is to refuse to route\n"
+"any traffic, by setting your share bandwidth or maximum "
+"participating tunnels to 0 (see above).\n"
+"It would be nice if you didn't do this, you should help the network by "
+"routing traffic for others.\n"
+"Over 95% of users route traffic for others."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:210
+msgid ""
+"Storage - I2P does not do distributed storage of content. You must"
+" be thinking of\n"
+"Freenet.\n"
+"Nobody's content is being stored on your computer by running I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:217
+msgid ""
+"Access - If there are some eepsites you don't like, don't go "
+"there.\n"
+"Or, use a blocking proxy like Privoxy or some type of \"net nanny\"."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:227
+msgid ""
+"No. This is normal.\n"
+"All routers adjust dynamically to changing network conditions and demands."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:234
+msgid ""
+"You may need to reseed your I2P router. With recent versions of I2P you "
+"can go to http://localhost:7657/configreseed"
+" and click the Save Changes and Reseed Now button. If this "
+"method doesn't work—or you're using a very old version—you "
+"may need to reseed manually."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:237
+msgid ""
+"The reseed URL changed a few years ago. If this is your first install and"
+" you have installed\n"
+"an old (0.6.1.30 or earlier) release, or\n"
+"you have not run I2P in a long time, you must change the URL and then\n"
+"click \"Reseed\" on the console to find other routers.\n"
+"After your router is running,\n"
+"on configadvanced.jsp,"
+"\n"
+"add the line i2p.reseedURL=http://netdb.i2p2.de/\n"
+"OR i2p.reseedURL=http://i2pdb.tin0.de/netDb/ (either should "
+"work),\n"
+"then click \"Apply\", then click the \"reseed\" link on the left."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:248
+#, python-format
+msgid ""
+"This works if you are running 0.6.1.27 or later.\n"
+"If you are running release 0.6.1.31 or later, you probably don't need to "
+"do this.\n"
+"If you are running release 0.6.1.26 or earlier, either follow the\n"
+"manual reseed instructions below\n"
+"or install the latest release.\n"
+"Possible alternate method - add\n"
+"wrapper.java.additional.5=-Di2p.reseedURL=http://netdb.i2p2.de/\n"
+"to wrapper.config, shutdown the router completely, then start again, then"
+" click \"reseed\".\n"
+"Let us know if this works."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:259
+#, python-format
+msgid ""
+"...but you *really* should upgrade to "
+"the latest version."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:265
+msgid ""
+"If your router has 10 or more active peers, everything is fine. Changes "
+"in releases 0.6.1.31 and 0.6.1.32 improved the\n"
+"efficiency of the router and effectively reduced the number of active "
+"peers.\n"
+"The router should maintain connections to a few peers at all "
+"times.\n"
+"The best way to stay \"better-connected\" to the network is to share more bandwidth."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:272
+msgid ""
+"Is my router an \"exit node\" to the regular Internet? I don't want it to"
+" be."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:274
+msgid ""
+"No. Unlike Tor,\n"
+"\"exit nodes\" or \"outproxies\" are not an inherent part of the network."
+"\n"
+"Only volunteers who set up and run separate applications will relay "
+"traffic to the regular Internet.\n"
+"There are very, very few of these."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:283
+msgid ""
+"See above. There are very few HTTP \"outproxies\", they are not an "
+"inherent part of the network,\n"
+"and they may not be up.\n"
+"In addition, the old outproxies squid.i2p, true.i2p, and krabs.i2p have "
+"vanished.\n"
+"The only outproxy at the moment is false.i2p.\n"
+"To use it, edit your i2ptunnel "
+"settings for eepProxy\n"
+"and set your outproxy list to 'false.i2p' (only).\n"
+"Then stop and restart the eepProxy.\n"
+"If it doesn't work, the outproxy is not up. It is not I2P's fault.\n"
+"If your primary reason to use an anonymous network is to anonymously "
+"access sites\n"
+"on the regular Internet, you should probably try Tor."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:298
+msgid ""
+"Within I2P, there is no need for HTTPS, as all traffic is encrypted end-"
+"to-end.\n"
+"FTP is not supported for technical reasons."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:302
+msgid ""
+"There are no FTP \"outproxies\" to the Internet—it may not even be "
+"possible to set up one.\n"
+"Any other kind of outproxy may work if it's set up with a standard "
+"tunnel. \n"
+"If you would like to set up some type of outproxy, carefully research the"
+" potential risks.\n"
+"The I2P community may or may not be able to help with the technical "
+"aspects, feel free to ask."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:308
+msgid ""
+"As explained several times above, any existing outproxy isn't a core part"
+" of the network.\n"
+"They are services run by individuals and they may or may not\n"
+"be operational at any given time."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:313
+msgid ""
+"Update: Thanks to the work of h2ik, there is an https outproxy "
+"available for use via I2P. Starting with I2P 0.8.4 the tunnel is "
+"configured out of the box.
            \n"
+"In case the https outproxy is not available in your version of I2P, you "
+"can add it easily by doing the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:319
+msgid ""
+"Open i2p tunnel "
+"manager. Scroll down to the bottom."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:324
+msgid ""
+"Choose CONNECT from New Client Tunnel dropdown list, click "
+"Create"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:329
+#, python-format
+msgid ""
+"In the new page, name and describe your new https tunnel as"
+" you like.\n"
+"The Access Point is your local port for the new https proxy "
+"recommended port's 4445.\n"
+"Outproxy should be the outproxy's .i2p address which supports "
+"https. \n"
+"See this forum post of h2ik's for the "
+"address. \n"
+"Make sure Shared Client, Delay Connect, AutoStart "
+"are checked.\n"
+"Other options should be left at the defaults. Click Save. In tunnel "
+"manger, click the Start button next to your new tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:339
+msgid ""
+"In firefox, click through "
+"Tools>Options>Advanced>Network>Setting."
+"\n"
+"Untick Use this proxy for all protocol, set SSL proxy: to "
+"localhost:4445."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:344
+msgid "Done."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:350
+#, python-format
+msgid ""
+"\n"
+"This is a question that only you can answer because the correct answer "
+"depends on your behaviours, your\n"
+"threat model, and how much you trust the "
+"outproxy operator."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:354
+msgid ""
+"Like Tor, I2P does not magically encrypt the Internet.\n"
+"You are vulnerable to snooping by the outproxy operators.\n"
+"The Tor"
+" FAQ\n"
+"does a good job of explaining this."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:360
+#, python-format
+msgid ""
+"In addition, you may be vulnerable to collusion between the outproxy "
+"operator\n"
+"and operators of other I2P services, if you use the same tunnels "
+"(\"shared clients\").\n"
+"There is additional discussion about this on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:368
+msgid ""
+"Unless an outproxy has been set up for the service you want to connect "
+"to, this cannot be done.\n"
+"There are only three types of outproxies running right now: HTTP, HTTPS, "
+"and email. Note that there is not a SOCKS outproxy.\n"
+"If this type of service is required, try Tor."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:376
+#, python-format
+msgid ""
+"If you consider every eepsite that has ever been created, yes, most of "
+"them are down.\n"
+"People and eepsites come and go.\n"
+"A good way to get started in I2P is check out a list of eepsites that are"
+" currently up.\n"
+"%(perv)s tracks active eepsites."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:385
+msgid ""
+"Click on the Website link\n"
+"at the top of your router console for instructions."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:392
+msgid ""
+"Why are downloads, torrents, web browsing, and everything else so slow on"
+" I2P?\n"
+"The encryption and routing within the I2P network adds a substantial "
+"amount of overhead and limits bandwidth.\n"
+"Anonymity isn't free."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:397
+msgid ""
+"In addition, you and everybody else probably need to increase your "
+"bandwidth limits.\n"
+"Two key settings are the inbound and outbound bandwidth limiters on\n"
+"the configuration page.\n"
+"With the default settings of 32KBps you will generally get no better than"
+" 15KBps data transfer in I2PSnark.\n"
+"Increasing the settings (but keeping within your actual connection "
+"limitations)\n"
+"will increase the potential transfer rate for I2PSnark and all other "
+"applications."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:405
+msgid ""
+"Also, do you have sufficient share bandwidth configured to allow "
+"participating tunnels\n"
+"to route through your router? Believe it or not, allowing participating "
+"traffic\n"
+"keeps you well-integrated in the network and helps your own transfer "
+"speeds."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:410
+#, python-format
+msgid ""
+"I2P is a work in progress. Lots of improvements and fixes are being "
+"implemented, and\n"
+"generally speaking, running the latest release will help your "
+"performance.\n"
+"If you haven't, install the latest "
+"release."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:418
+#, python-format
+msgid ""
+"See the\n"
+"I2P Bittorrent FAQ"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:425
+msgid ""
+"\n"
+"A tunnel to the main IRC server within I2P, Irc2P, is created when I2P is"
+" installed (see\n"
+"the I2PTunnel "
+"configuration page),\n"
+"and is automatically started when the I2P router starts. To connect to "
+"it, tell your IRC\n"
+"client to connect to localhost 6668. XChat-like client users"
+" can create a\n"
+"new network with the server localhost/6668 (remember to tick"
+" "Bypass\n"
+"proxy server" if you have a proxy server configured)."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:436
+msgid ""
+"For security purposes, the router's admin console by default only listens"
+"\n"
+"for connections on the local interface.  However, with a little hacking,\n"
+"you can make it reachable remotely:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:444
+msgid ""
+"Open ~/.i2p/clients.config and replace
            \n"
+"clientApp.0.args=7657 ::1,127.0.0.1 ./webapps/
            \n"
+"with 
            \n"
+"clientApp.0.args=7657 0.0.0.0 ./webapps/"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:452
+msgid ""
+"Go to http://localhost:7657/configadvanced.jsp"
+"\n"
+"and add a new option: consolePassword=foo (or whatever "
+"password you want)"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:458
+msgid ""
+"Go to http://localhost:7657/index.jsp"
+"\n"
+"and hit \"Graceful restart\", which restarts the JVM and reloads the "
+"client applications"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:465
+msgid ""
+"After that fires up, you should now be able to reach your console "
+"remotely.\n"
+"You will be prompted for a username and password though - the username is"
+"\n"
+"\"admin\" and the password is whatever you specified in step 2 above.  "
+"Note: the\n"
+"0.0.0.0 above specifies an interface, not a network "
+"or netmask.  0.0.0.0\n"
+"means \"bind to all interfaces\", so it can be reachable on "
+"127.0.0.1:7657 as well as\n"
+"any LAN/WAN IP."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:476
+msgid ""
+"By default, the router I2CP interface (port 7654) binds to address "
+"127.0.0.1. To bind to 0.0.0.0, set the\n"
+"router advanced configuration option "
+"i2cp.tcp.bindAllInterfaces=true and restart."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:481
+msgid "Whats an \"eepsite\"?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:483
+msgid ""
+"An eepsite is a website that is hosted anonymously - you can access it by"
+"\n"
+"setting your web browser's HTTP proxy to use the web proxy (typically it\n"
+"listens on localhost port 4444), and browsing to the site."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:491
+#, python-format
+msgid ""
+"The proxy config for different browsers is on a \n"
+"separate page with screenshots. More advanced configs with external "
+"tools\n"
+"are possible but could introduce leaks in your setup."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:500
+msgid ""
+"x is the number of peers you've sent or received a message from\n"
+"successfully in the last minute, y is the number of peers seen in the "
+"last\n"
+"hour or so."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:508
+msgid ""
+"The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are "
+"supported.\n"
+"There is no SOCKS outproxy so it is of limited use."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:512
+msgid ""
+"In addition, many applications leak sensitive\n"
+"information that could identify you on the Internet. I2P only filters\n"
+"connection data, but if the program you intend to run sends this\n"
+"information as content, I2P has no way to protect your anonymity.  For\n"
+"example, some mail applications will send the IP address of the machine\n"
+"they are running on to a mail server. There is no way for I2P to filter\n"
+"this, thus using I2P to 'socksify' existing applications is possible, but"
+"\n"
+"extremely dangerous."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:522
+#, python-format
+msgid ""
+"If you would like more information on the socks proxy application anyway,"
+"\n"
+"there are some helpful hints on the socks page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:529
+msgid ""
+"Okay, here's a rundown of the default ports (everything is configurable\n"
+"through various settings, of course):"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:538
+msgid ""
+"Internet-facing ports\n"
+"Note: New installs as of release 0.7.8 do not use port 8887; they select "
+"a random port\n"
+"between 9000 and 31000 when the program is run for the first time.\n"
+"The selected port is shown on the router configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:546
+msgid ""
+"Outbound UDP from the random port noted on the configuration page to "
+"arbitrary remote UDP ports, allowing replies\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:551
+msgid ""
+"Outbound TCP from random high ports to arbitrary remote TCP ports\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:556
+msgid ""
+"(optional, but recommended) Inbound UDP to the port noted on configuration page from "
+"arbitrary locations\n"
+"    "
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:561
+msgid ""
+"(optional, but recommended) Inbound TCP to the port noted on configuration page from "
+"arbitrary locations
            \n"
+"Inbound TCP may be disabled on the configuration page."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:567
+msgid ""
+"Outbound UDP on port 123, allowing replies
            \n"
+"This is necessary for I2P's internal time sync (via SNTP - \n"
+"querying a random SNTP host in pool.ntp.org or another\n"
+"server you specify)"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:578
+msgid ""
+"Local I2P ports, listening only to local connections by default,\n"
+"except where noted:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:584
+msgid ""
+"1900: UPnP SSDP UDP multicast listener.\n"
+"Cannot be changed. Binds to all interfaces.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:591
+msgid ""
+"2827: BOB bridge, a higher level socket API for clients\n"
+"Disabled by default.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the bob.config file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:599
+msgid ""
+"4444: HTTP proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:606
+msgid ""
+"4445: HTTPS proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:613
+msgid ""
+"6668: IRC proxy\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:620
+msgid ""
+"7652: UPnP HTTP TCP event listener.\n"
+"Binds to the LAN address.\n"
+"May be changed with advanced config i2np.upnp.HTTPPort=nnnn.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:628
+msgid ""
+"7653: UPnP SSDP UDP search response listener.\n"
+"Binds to all interfaces.\n"
+"May be changed with advanced config i2np.upnp.SSDPPort=nnnn.\n"
+"May be disabled on confignet.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:636
+msgid ""
+"7654: I2P Client Protocol port, used by client apps.\n"
+"May be changed to a different port on\n"
+"configclients.jsp"
+"\n"
+"but this is not recommended.\n"
+"May be to bind to a different interface or all interfaces, or disabled, "
+"on\n"
+"configclients.jsp."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:646
+msgid ""
+"7655: UDP for SAM bridge, a higher level socket API for clients\n"
+"Only opened when a SAM V3 client requests a UDP session.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the clients.config file with the SAM command line "
+"option sam.udp.port=nnnn."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:654
+msgid ""
+"7656: SAM bridge, a higher level socket API for clients\n"
+"Disabled by default for new installs as of release 0.6.5.\n"
+"May be enabled/disabled on configclients.jsp.\n"
+"May be changed in the clients.config file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:662
+msgid ""
+"7657: Your router console\n"
+"May be disabled in the clients.config file.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces in that file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:669
+msgid ""
+"7658: Your eepsite\n"
+"May be disabled in the clients.config file.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces in the jetty.xml file."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:676
+msgid ""
+"7659: Outgoing mail to smtp.postman.i2p\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:683
+msgid ""
+"7660: Incoming mail from pop.postman.i2p\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:690
+msgid ""
+"8998: mtn.i2p2.i2p (Monotone - disabled by default)\n"
+"May be disabled or changed on the i2ptunnel page in the router "
+"console.\n"
+"May also be configured to be bound to a specific interface or all "
+"interfaces."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:697
+msgid ""
+"31000: Local connection to the wrapper control channel port.\n"
+"Outbound to 32000 only, does not listen on this port.\n"
+"Starts at 31000 and will increment until 31999 looking for a free port.\n"
+"To change, see the\n"
+"wrapper documentation.\n"
+"For more information see below."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:707
+msgid ""
+"32000: Local control channel for the service wrapper.\n"
+"To change, see the\n"
+"wrapper documentation.\n"
+"For more information see below."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:719
+msgid ""
+"The local I2P ports and the I2PTunnel ports do not need to be reachable "
+"from \n"
+"remote machines, but *should* be reachable locally.  You can also create"
+" \n"
+"additional ports for I2PTunnel instances via "
+"http://localhost:7657/i2ptunnel/ \n"
+"(and in turn, would need to get your firewall to allow you local access, "
+"but \n"
+"not remote access, unless desired)."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:727
+msgid ""
+"So, to summarize, nothing needs to be reachable by unsolicited remote "
+"peers, but\n"
+"if you can configure your NAT/firewall to allow inbound UDP and TCP the "
+"outbound facing port, you'll"
+"\n"
+"get better performance.  You will also need to be able to send outbound "
+"UDP packets\n"
+"to arbitrary remote peers (blocking IPs randomly with something like "
+"PeerGuardian\n"
+"only hurts you - don't do it)."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:735
+msgid "Why is I2P listening on port 32000?"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:737
+msgid ""
+"The Tanuki java service wrapper that we use opens this port—bound "
+"to localhost—in order \n"
+"to communicate with software running inside the JVM. When the JVM is "
+"launched it is given a key \n"
+"so it can connect to the wrapper. After the JVM establishes its "
+"connection \n"
+"to the wrapper, the wrapper refuses any additional connections."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:743
+msgid ""
+"More information can be found in the  \n"
+"wrapper documentation."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:750
+msgid ""
+"An I2P router only needs to be seeded once, to join the network for the "
+"first time.\n"
+"Reseeding is nothing more than sending plain HTTP GET requests\n"
+"to fetch a directory listing and download multiple \"routerInfo\" files\n"
+"from a predefined reseed URL."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:757
+msgid ""
+"A typical symptom of a failed reseed is the \"Known\" indicator\n"
+"(on the left sidebar of the router console) displaying a very small value"
+"\n"
+"(often less than 5) which does not increase. This can occur, among other "
+"things,\n"
+"if your firewall limits outbound traffic, and blocked the reseed request."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:764
+msgid "To reseed an I2P router manually, do the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:767
+msgid "Stop your I2P router"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:770
+msgid ""
+"Open http://netdb.i2p2.de/ using a "
+"web browser"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:773
+msgid "Save a dozen \"routerInfo\" files to your I2P \"netDb\" directory"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:780
+msgid "Start your I2P router"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:787
+msgid ""
+"When trying to start the router using \"i2prouter start\", you may see "
+"output like the following:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:792
+msgid ""
+"\n"
+"In order to be inclusive and try to ensure that I2P will run on as many "
+"systems \n"
+"as possible, up until I2P 0.8.9 we used a java wrapper \n"
+"compiled for FreeBSD 6.x. If you're receiving this error you most likely "
+"are missing the necessary compatibility libraries.\n"
+"These libraries may be installed by performing the following steps:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:800
+msgid ""
+"Switch to the root user with su or log in as "
+"root."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:806
+#, python-format
+msgid ""
+"If you cannot install these compatibility libraries (or do not want to), "
+"other\n"
+"possibilities would be to compile the wrapper for your\n"
+"system, starting I2P with the runplain.sh script, or you"
+" can\n"
+"replace the wrapper with one from the source tarball."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:812
+msgid ""
+"For the 0.8.9 release of I2P, the wrapper was upgraded to v3.5.12 and "
+"compiled on systems running FreeBSD 7.2."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:816
+msgid ""
+"In wrapper.log I see an error that states \"Protocol "
+"family unavailable\" when loading the Router Console"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:818
+msgid ""
+"Often this error will occur with any network enabled java software on "
+"some systems that are configured to use IPv6 by default. There are a few "
+"ways to solve this:"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:823
+msgid ""
+"On Linux based systems, you can echo 0 > "
+"/proc/sys/net/ipv6/bindv6only"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:825
+msgid "Look for the following lines in wrapper.config."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:829
+msgid ""
+"If the lines are there, uncomment them by removing the \"#\"s. If the "
+"lines are not there, add them without the \"#\"s."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:832
+msgid ""
+"Another option would be to remove the ::1 from "
+"~/.i2p/clients.config"
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:836
+msgid ""
+"WARNING: For any changes to wrapper.config "
+"to take effect, you must completely\n"
+"stop the router and the wrapper. Clicking Restart on your\n"
+"router console will NOT reread this file! You must\n"
+"click Shutdown, wait 11 minutes, then start I2P."
+msgstr ""
+
+#: i2p2www/pages/site/faq.html:847
+#, python-format
+msgid ""
+"Great!  Find us on IRC irc.freenode.net #i2p or post to\n"
+"the forum and we'll post it here (with\n"
+"the answer, hopefully)."
+msgstr ""
+
+#: i2p2www/pages/site/impressum.html:4
+msgid "German laws"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:2
+msgid "I2P Anonymous Network"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:4
+msgid ""
+"Anonymous peer-to-peer distributed communication layer built with open "
+"source tools and designed to run any traditional Internet service such as"
+" email, IRC or web hosting."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:7
+msgid "What does I2P do for you?"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:8
+msgid ""
+"The I2P network provides strong privacy protections for communication "
+"over the Internet. Many activities that would risk your privacy on the "
+"public Internet can be conducted anonymously inside I2P."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:9
+#, python-format
+msgid "Get I2P %(version)s"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:13
+msgid "What is I2P?"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:15
+msgid ""
+"I2P is a full darknet implementation - a network within a network, and is"
+" intended to protect against monitoring by third parties, such as hostile"
+" governments or ISPs.\n"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:18
+msgid ""
+"I2P is used by many people who care about their privacy, as well as those"
+" in high-risk situations. It is designed to protect activists, oppressed "
+"people, journalists and whistle-blowers - as well as the average person."
+"\n"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:21
+msgid ""
+"I2P runs on Java and is therefore available anywhere Java will run, "
+"including desktops, embedded systems (like the Raspberry Pi)  and Android"
+" phones.\n"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:25
+msgid "Read more…"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:30
+msgid "What can you do with I2P?"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:33
+#, python-format
+msgid ""
+"Email Integrated web mail interface, "
+"plugin for serverless email."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:38
+#, python-format
+msgid ""
+"Web browsing Anonymous "
+"websites, gateways to and from the public Internet."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:43
+#, python-format
+msgid ""
+"Blogging and forums "
+"Blogging and Syndie plugins."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:48
+#, python-format
+msgid ""
+"Website hosting Integrated "
+"anonymous web server."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:53
+#, python-format
+msgid ""
+"Real-time chat Instant "
+"messaging and IRC clients."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:58
+#, python-format
+msgid ""
+"File sharing ED2K and Gnutella"
+" clients, integrated BitTorrent client."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:63
+#, python-format
+msgid ""
+"Decentralized file "
+"storage Tahoe-LAFS distributed filesystem plugin."
+msgstr ""
+
+#: i2p2www/pages/site/index.html:68
+#, python-format
+msgid "More supported applications…"
+msgstr ""
+
+#: i2p2www/pages/site/index.html:76
+msgid "News & Updates"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:4
+msgid "Recommended Links & Resources"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:5
+#, python-format
+msgid ""
+"See also the page with\n"
+"links to presentations, videos, and tutorials about"
+" I2P."
+msgstr ""
+
+#: i2p2www/pages/site/links.html:12
+msgid "Friends of I2P"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:24
+msgid "More Projects and Documentation"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:34
+msgid "Press"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:38
+msgid "Boards, newssite, others"
+msgstr ""
+
+#: i2p2www/pages/site/links.html:42
+msgid "Very Old Stuff"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:2
+msgid "Web Browser Configuration"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:5
+msgid ""
+"Your web browser will need to be configured in order to browse eepsites "
+"and to\n"
+"utilize the outproxies available within I2P. Below are walkthroughs for "
+"some of\n"
+"the most popular browsers."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:11
+msgid "How to configure your browser"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:17
+#: i2p2www/pages/site/about/browser-config.html:73
+msgid "Outproxy Terms Of Service"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:22
+msgid "Internet Explorer 8 or Chrome"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:23
+msgid ""
+"In the tools menu select the \"Internet Options\" line to open the "
+"settings. In the\n"
+"settings window choose the connections tab and click on LAN settings for "
+"the\n"
+"proxy port configuration."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:28
+msgid "IE Internet Options"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:29
+msgid ""
+"Now set the checkmark at \"use a proxy server for your LAN\" and at the "
+"\"Bypass\n"
+"proxy server for local addresses\". With a click on Advanced-button you "
+"open the\n"
+"window to open the ports. Enter the values like on the picture, IP "
+"127.0.0.1\n"
+"and port 4444 for HTTP, port 4445 for HTTPS. With clicks on OK you save "
+"the\n"
+"settings and your browser is set to use the I2P proxy."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:36
+msgid "IE Proxy Settings"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:40
+msgid ""
+"From the Tools menu, select Options to bring up the Firefox settings "
+"panel.\n"
+"Click the icon labelled Advanced, then click on the "
+"Network\n"
+"tab. In the Connections section, click on the Settings button. "
+"You'll\n"
+"see a Window like the following:"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:46
+msgid "Firefox Network Options"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:47
+msgid ""
+"In the Connection Settings window, click the circle next to "
+"Manual\n"
+"    proxy configuration, then enter 127.0.0.1, port 4444 in the HTTP"
+" Proxy\n"
+"field.  Enter 127.0.0.1, port 4445 in the SSL Proxy field.\n"
+"Be sure to enter localhost and 127.0.0.1 into the \"No Proxy for\" box."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:53
+msgid "Firefox Proxy Settings"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:57
+msgid ""
+"From the Settings menu, select Configure Konqueror. In "
+"the\n"
+"Web Browsing group on the left side, select Proxy Services.\n"
+"In this new window, select the option \"Manually specify the proxy "
+"settings\" and\n"
+"click the Setup box."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:63
+msgid "Konqueror Proxy Options"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:64
+msgid ""
+"Enter 127.0.0.1 and port 4444 into the HTTP box. Enter 127.0.0.1 and port"
+" 4445 into\n"
+"HTTPS box. Click the New button in the Exceptions section. Enter"
+"\n"
+"localhost and click OK. Click the New button once more and enter"
+"\n"
+"127.0.0.1 and OK. Hit OK once more to close the configuration window."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:70
+msgid "Konqueror Proxy Ports"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:74
+msgid ""
+"Remember: I2P was not designed for creating proxies to the outer "
+"Internet.\n"
+"Instead, it is meant to be used as an internal network."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:78
+msgid ""
+"The I2P project itself does not run any proxies to the Internet. Any "
+"such proxy\n"
+"services are run by by private volunteers and could be shut down or\n"
+"unreachable at anytime."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:83
+msgid ""
+"By default, I2P comes with two outproxies configured: "
+"false.i2p\n"
+"(an HTTP-only proxy) and outproxyng.h2ik.i2p (an HTTPS proxy"
+"\n"
+"routed through Tor."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:88
+msgid ""
+"Both of these outproxies are configured with connection limits. This "
+"means\n"
+"that only set amount of accesses are allowed per client. Once the limit "
+"is\n"
+"reached, the client is blocked out for a timeframe of 1min/1h/1 day. Be\n"
+"respectful and do not overload these services with too many requests!"
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:94
+#, python-format
+msgid ""
+"Filtering is active on these outproxies (for example, mibbit and torrent\n"
+"tracker access is blocked). Note that even though the pirate bay is "
+"blocked\n"
+"they host an official eepsite at %(tpb)s. "
+"Eepsites\n"
+"that are accessible via .i2p addresses are also not allowed via the "
+"outproxies.\n"
+"As a convenience, False.i2p blocks ad servers."
+msgstr ""
+
+#: i2p2www/pages/site/about/browser-config.html:101
+msgid ""
+"Tor is good application to use"
+" as an\n"
+"outproxy to the Internet."
+msgstr ""
+
+#: i2p2www/pages/site/about/glossary.html:4
+msgid ""
+"This page lists often-used terminology when discussing I2P and "
+"cryptography."
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:2
+msgid "Hall Of Fame"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:5
+msgid "I2P's Hall of Fame"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:6
+#, python-format
+msgid "Current balance: as of %(date)s"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:9
+#: i2p2www/pages/site/about/hall-of-fame.html:46
+#: i2p2www/pages/site/about/hall-of-fame.html:53
+#: i2p2www/pages/site/about/hall-of-fame.html:54
+#: i2p2www/pages/site/about/hall-of-fame.html:55
+#: i2p2www/pages/site/about/hall-of-fame.html:56
+#: i2p2www/pages/site/about/hall-of-fame.html:58
+#: i2p2www/pages/site/about/hall-of-fame.html:59
+#: i2p2www/pages/site/about/hall-of-fame.html:60
+#: i2p2www/pages/site/about/hall-of-fame.html:63
+#: i2p2www/pages/site/about/hall-of-fame.html:64
+#: i2p2www/pages/site/about/hall-of-fame.html:65
+#: i2p2www/pages/site/about/hall-of-fame.html:68
+#: i2p2www/pages/site/about/hall-of-fame.html:69
+#: i2p2www/pages/site/about/hall-of-fame.html:70
+#: i2p2www/pages/site/about/hall-of-fame.html:71
+#: i2p2www/pages/site/about/hall-of-fame.html:72
+#: i2p2www/pages/site/about/hall-of-fame.html:73
+#: i2p2www/pages/site/about/hall-of-fame.html:74
+#: i2p2www/pages/site/about/hall-of-fame.html:75
+#: i2p2www/pages/site/about/hall-of-fame.html:76
+#: i2p2www/pages/site/about/hall-of-fame.html:77
+#: i2p2www/pages/site/about/hall-of-fame.html:78
+#: i2p2www/pages/site/about/hall-of-fame.html:79
+#: i2p2www/pages/site/about/hall-of-fame.html:80
+#: i2p2www/pages/site/about/hall-of-fame.html:83
+#: i2p2www/pages/site/about/hall-of-fame.html:84
+#: i2p2www/pages/site/about/hall-of-fame.html:85
+#: i2p2www/pages/site/about/hall-of-fame.html:86
+#: i2p2www/pages/site/about/hall-of-fame.html:87
+#: i2p2www/pages/site/about/hall-of-fame.html:88
+#: i2p2www/pages/site/about/hall-of-fame.html:90
+#: i2p2www/pages/site/about/hall-of-fame.html:91
+#: i2p2www/pages/site/about/hall-of-fame.html:94
+#: i2p2www/pages/site/about/hall-of-fame.html:95
+#: i2p2www/pages/site/about/hall-of-fame.html:96
+#: i2p2www/pages/site/about/hall-of-fame.html:97
+#: i2p2www/pages/site/about/hall-of-fame.html:98
+#: i2p2www/pages/site/about/hall-of-fame.html:100
+#: i2p2www/pages/site/about/hall-of-fame.html:101
+#: i2p2www/pages/site/about/hall-of-fame.html:102
+#: i2p2www/pages/site/about/hall-of-fame.html:103
+#: i2p2www/pages/site/about/hall-of-fame.html:104
+#: i2p2www/pages/site/about/hall-of-fame.html:105
+#: i2p2www/pages/site/about/hall-of-fame.html:107
+#: i2p2www/pages/site/about/hall-of-fame.html:108
+#: i2p2www/pages/site/about/hall-of-fame.html:109
+#: i2p2www/pages/site/about/hall-of-fame.html:110
+#: i2p2www/pages/site/about/hall-of-fame.html:112
+#: i2p2www/pages/site/about/hall-of-fame.html:113
+#: i2p2www/pages/site/about/hall-of-fame.html:114
+#: i2p2www/pages/site/about/hall-of-fame.html:115
+#: i2p2www/pages/site/about/hall-of-fame.html:116
+#: i2p2www/pages/site/about/hall-of-fame.html:119
+#: i2p2www/pages/site/about/hall-of-fame.html:120
+#: i2p2www/pages/site/about/hall-of-fame.html:121
+#: i2p2www/pages/site/about/hall-of-fame.html:122
+#: i2p2www/pages/site/about/hall-of-fame.html:124
+#: i2p2www/pages/site/about/hall-of-fame.html:125
+#: i2p2www/pages/site/about/hall-of-fame.html:126
+#: i2p2www/pages/site/about/hall-of-fame.html:128
+#: i2p2www/pages/site/about/hall-of-fame.html:129
+#: i2p2www/pages/site/about/hall-of-fame.html:130
+#: i2p2www/pages/site/about/hall-of-fame.html:131
+#: i2p2www/pages/site/about/hall-of-fame.html:133
+#: i2p2www/pages/site/about/hall-of-fame.html:134
+#: i2p2www/pages/site/about/hall-of-fame.html:135
+#: i2p2www/pages/site/about/hall-of-fame.html:136
+#: i2p2www/pages/site/about/hall-of-fame.html:137
+#: i2p2www/pages/site/about/hall-of-fame.html:143
+#: i2p2www/pages/site/about/hall-of-fame.html:146
+#: i2p2www/pages/site/about/hall-of-fame.html:147
+#: i2p2www/pages/site/about/hall-of-fame.html:148
+#: i2p2www/pages/site/about/hall-of-fame.html:149
+#: i2p2www/pages/site/about/hall-of-fame.html:150
+#: i2p2www/pages/site/about/hall-of-fame.html:152
+#: i2p2www/pages/site/about/hall-of-fame.html:153
+#: i2p2www/pages/site/about/hall-of-fame.html:154
+#: i2p2www/pages/site/about/hall-of-fame.html:159
+#: i2p2www/pages/site/about/hall-of-fame.html:160
+#: i2p2www/pages/site/about/hall-of-fame.html:161
+#: i2p2www/pages/site/about/hall-of-fame.html:162
+#: i2p2www/pages/site/about/hall-of-fame.html:163
+#: i2p2www/pages/site/about/hall-of-fame.html:164
+#: i2p2www/pages/site/about/hall-of-fame.html:165
+#: i2p2www/pages/site/about/hall-of-fame.html:166
+#: i2p2www/pages/site/about/hall-of-fame.html:167
+#: i2p2www/pages/site/about/hall-of-fame.html:168
+#: i2p2www/pages/site/about/hall-of-fame.html:170
+#: i2p2www/pages/site/about/hall-of-fame.html:171
+#: i2p2www/pages/site/about/hall-of-fame.html:180
+#: i2p2www/pages/site/about/hall-of-fame.html:181
+#: i2p2www/pages/site/about/hall-of-fame.html:182
+#: i2p2www/pages/site/about/hall-of-fame.html:183
+#: i2p2www/pages/site/about/hall-of-fame.html:184
+#: i2p2www/pages/site/about/hall-of-fame.html:185
+#: i2p2www/pages/site/about/hall-of-fame.html:186
+#: i2p2www/pages/site/about/hall-of-fame.html:187
+#: i2p2www/pages/site/about/hall-of-fame.html:188
+#: i2p2www/pages/site/about/hall-of-fame.html:189
+#: i2p2www/pages/site/about/hall-of-fame.html:190
+#: i2p2www/pages/site/about/hall-of-fame.html:191
+#: i2p2www/pages/site/about/hall-of-fame.html:192
+#: i2p2www/pages/site/about/hall-of-fame.html:193
+#: i2p2www/pages/site/about/hall-of-fame.html:194
+#: i2p2www/pages/site/about/hall-of-fame.html:195
+#: i2p2www/pages/site/about/hall-of-fame.html:196
+#: i2p2www/pages/site/about/hall-of-fame.html:197
+#: i2p2www/pages/site/about/hall-of-fame.html:198
+#: i2p2www/pages/site/about/hall-of-fame.html:199
+#: i2p2www/pages/site/about/hall-of-fame.html:200
+#: i2p2www/pages/site/about/hall-of-fame.html:204
+#: i2p2www/pages/site/about/hall-of-fame.html:205
+#: i2p2www/pages/site/about/hall-of-fame.html:206
+#: i2p2www/pages/site/about/hall-of-fame.html:207
+#: i2p2www/pages/site/about/hall-of-fame.html:208
+#: i2p2www/pages/site/about/hall-of-fame.html:209
+#: i2p2www/pages/site/about/hall-of-fame.html:210
+#: i2p2www/pages/site/about/hall-of-fame.html:212
+#: i2p2www/pages/site/about/hall-of-fame.html:213
+#: i2p2www/pages/site/about/hall-of-fame.html:214
+#: i2p2www/pages/site/about/hall-of-fame.html:215
+#: i2p2www/pages/site/about/hall-of-fame.html:216
+#: i2p2www/pages/site/about/hall-of-fame.html:217
+#: i2p2www/pages/site/about/hall-of-fame.html:218
+#: i2p2www/pages/site/about/hall-of-fame.html:219
+#: i2p2www/pages/site/about/hall-of-fame.html:220
+#: i2p2www/pages/site/about/hall-of-fame.html:223
+#: i2p2www/pages/site/about/hall-of-fame.html:224
+#: i2p2www/pages/site/about/hall-of-fame.html:225
+#: i2p2www/pages/site/about/hall-of-fame.html:226
+#: i2p2www/pages/site/about/hall-of-fame.html:227
+#: i2p2www/pages/site/about/hall-of-fame.html:229
+#: i2p2www/pages/site/about/hall-of-fame.html:231
+#: i2p2www/pages/site/about/hall-of-fame.html:232
+#: i2p2www/pages/site/about/hall-of-fame.html:233
+#: i2p2www/pages/site/about/hall-of-fame.html:234
+#: i2p2www/pages/site/about/hall-of-fame.html:235
+#: i2p2www/pages/site/about/hall-of-fame.html:236
+#: i2p2www/pages/site/about/hall-of-fame.html:237
+#: i2p2www/pages/site/about/hall-of-fame.html:239
+#: i2p2www/pages/site/about/hall-of-fame.html:240
+#: i2p2www/pages/site/about/hall-of-fame.html:241
+#: i2p2www/pages/site/about/hall-of-fame.html:242
+#: i2p2www/pages/site/about/hall-of-fame.html:243
+#: i2p2www/pages/site/about/hall-of-fame.html:244
+#: i2p2www/pages/site/about/hall-of-fame.html:245
+#: i2p2www/pages/site/about/hall-of-fame.html:246
+#: i2p2www/pages/site/about/hall-of-fame.html:247
+#: i2p2www/pages/site/about/hall-of-fame.html:248
+#: i2p2www/pages/site/about/hall-of-fame.html:249
+#: i2p2www/pages/site/about/hall-of-fame.html:250
+#: i2p2www/pages/site/about/hall-of-fame.html:251
+#: i2p2www/pages/site/about/hall-of-fame.html:252
+#: i2p2www/pages/site/about/hall-of-fame.html:254
+#: i2p2www/pages/site/about/hall-of-fame.html:255
+#: i2p2www/pages/site/about/hall-of-fame.html:256
+#: i2p2www/pages/site/about/hall-of-fame.html:259
+#: i2p2www/pages/site/about/hall-of-fame.html:260
+#: i2p2www/pages/site/about/hall-of-fame.html:263
+#: i2p2www/pages/site/about/hall-of-fame.html:264
+#: i2p2www/pages/site/about/hall-of-fame.html:266
+#: i2p2www/pages/site/about/hall-of-fame.html:267
+#: i2p2www/pages/site/about/hall-of-fame.html:280
+#: i2p2www/pages/site/about/hall-of-fame.html:281
+#: i2p2www/pages/site/about/hall-of-fame.html:282
+#: i2p2www/pages/site/about/hall-of-fame.html:283
+#: i2p2www/pages/site/about/hall-of-fame.html:284
+#: i2p2www/pages/site/about/hall-of-fame.html:285
+#: i2p2www/pages/site/about/hall-of-fame.html:286
+#: i2p2www/pages/site/about/hall-of-fame.html:287
+#: i2p2www/pages/site/about/hall-of-fame.html:288
+#: i2p2www/pages/site/about/hall-of-fame.html:289
+#: i2p2www/pages/site/about/hall-of-fame.html:290
+#: i2p2www/pages/site/about/hall-of-fame.html:291
+#: i2p2www/pages/site/about/hall-of-fame.html:292
+#: i2p2www/pages/site/about/hall-of-fame.html:293
+#: i2p2www/pages/site/about/hall-of-fame.html:294
+#: i2p2www/pages/site/about/hall-of-fame.html:295
+#: i2p2www/pages/site/about/hall-of-fame.html:296
+#: i2p2www/pages/site/about/hall-of-fame.html:297
+#: i2p2www/pages/site/about/hall-of-fame.html:298
+#: i2p2www/pages/site/about/hall-of-fame.html:299
+#: i2p2www/pages/site/about/hall-of-fame.html:300
+#: i2p2www/pages/site/about/hall-of-fame.html:301
+#: i2p2www/pages/site/about/hall-of-fame.html:302
+#: i2p2www/pages/site/about/hall-of-fame.html:303
+#: i2p2www/pages/site/about/hall-of-fame.html:304
+#: i2p2www/pages/site/about/hall-of-fame.html:305
+#: i2p2www/pages/site/about/hall-of-fame.html:306
+#: i2p2www/pages/site/about/hall-of-fame.html:307
+#: i2p2www/pages/site/about/hall-of-fame.html:308
+#: i2p2www/pages/site/about/hall-of-fame.html:309
+#: i2p2www/pages/site/about/hall-of-fame.html:310
+#: i2p2www/pages/site/about/hall-of-fame.html:311
+#: i2p2www/pages/site/about/hall-of-fame.html:312
+#: i2p2www/pages/site/about/hall-of-fame.html:313
+#: i2p2www/pages/site/about/hall-of-fame.html:314
+#: i2p2www/pages/site/about/hall-of-fame.html:316
+#: i2p2www/pages/site/about/hall-of-fame.html:317
+#: i2p2www/pages/site/about/hall-of-fame.html:318
+#: i2p2www/pages/site/about/hall-of-fame.html:319
+#: i2p2www/pages/site/about/hall-of-fame.html:320
+#: i2p2www/pages/site/about/hall-of-fame.html:321
+#: i2p2www/pages/site/about/hall-of-fame.html:322
+#: i2p2www/pages/site/about/hall-of-fame.html:323
+#: i2p2www/pages/site/about/hall-of-fame.html:325
+#: i2p2www/pages/site/about/hall-of-fame.html:326
+#: i2p2www/pages/site/about/hall-of-fame.html:327
+#: i2p2www/pages/site/about/hall-of-fame.html:329
+#: i2p2www/pages/site/about/hall-of-fame.html:330
+#: i2p2www/pages/site/about/hall-of-fame.html:331
+#: i2p2www/pages/site/about/hall-of-fame.html:332
+#: i2p2www/pages/site/about/hall-of-fame.html:333
+#: i2p2www/pages/site/about/hall-of-fame.html:335
+#: i2p2www/pages/site/about/hall-of-fame.html:338
+#: i2p2www/pages/site/about/hall-of-fame.html:339
+#: i2p2www/pages/site/about/hall-of-fame.html:340
+#: i2p2www/pages/site/about/hall-of-fame.html:341
+#: i2p2www/pages/site/about/hall-of-fame.html:342
+#: i2p2www/pages/site/about/hall-of-fame.html:343
+#: i2p2www/pages/site/about/hall-of-fame.html:344
+#: i2p2www/pages/site/about/hall-of-fame.html:345
+#: i2p2www/pages/site/about/hall-of-fame.html:346
+#: i2p2www/pages/site/about/hall-of-fame.html:347
+#: i2p2www/pages/site/about/hall-of-fame.html:348
+#: i2p2www/pages/site/about/hall-of-fame.html:349
+#: i2p2www/pages/site/about/hall-of-fame.html:350
+#: i2p2www/pages/site/about/hall-of-fame.html:351
+#: i2p2www/pages/site/about/hall-of-fame.html:353
+#: i2p2www/pages/site/about/hall-of-fame.html:354
+#: i2p2www/pages/site/about/hall-of-fame.html:355
+#: i2p2www/pages/site/about/hall-of-fame.html:357
+#: i2p2www/pages/site/about/hall-of-fame.html:360
+#: i2p2www/pages/site/about/hall-of-fame.html:361
+#: i2p2www/pages/site/about/hall-of-fame.html:362
+#: i2p2www/pages/site/about/hall-of-fame.html:363
+#: i2p2www/pages/site/about/hall-of-fame.html:364
+#: i2p2www/pages/site/about/hall-of-fame.html:365
+#: i2p2www/pages/site/about/hall-of-fame.html:366
+#: i2p2www/pages/site/about/hall-of-fame.html:367
+#: i2p2www/pages/site/about/hall-of-fame.html:368
+#: i2p2www/pages/site/about/hall-of-fame.html:369
+#: i2p2www/pages/site/about/hall-of-fame.html:370
+#: i2p2www/pages/site/about/hall-of-fame.html:371
+#: i2p2www/pages/site/about/hall-of-fame.html:372
+#: i2p2www/pages/site/about/hall-of-fame.html:373
+#: i2p2www/pages/site/about/hall-of-fame.html:374
+#: i2p2www/pages/site/about/hall-of-fame.html:375
+#: i2p2www/pages/site/about/hall-of-fame.html:376
+#: i2p2www/pages/site/about/hall-of-fame.html:377
+#: i2p2www/pages/site/about/hall-of-fame.html:378
+#: i2p2www/pages/site/about/hall-of-fame.html:380
+#: i2p2www/pages/site/about/hall-of-fame.html:381
+#: i2p2www/pages/site/about/hall-of-fame.html:382
+msgid "General fund"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:10
+#: i2p2www/pages/site/about/hall-of-fame.html:12
+#: i2p2www/pages/site/about/hall-of-fame.html:20
+#, python-format
+msgid "%(euroval)s € and %(btcval)s BTC"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:11
+msgid "Datastorage bounty"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:13
+msgid "Native IPv6 I2P"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:14
+#: i2p2www/pages/site/about/hall-of-fame.html:16
+#: i2p2www/pages/site/about/hall-of-fame.html:18
+#: i2p2www/pages/site/about/hall-of-fame.html:22
+#, python-format
+msgid "%(euroval)s €"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:15
+msgid "I2PHex bounty"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:17
+msgid "I2P in debian mirrors"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:19
+#: i2p2www/pages/site/get-involved/bounties/index.html:67
+msgid "Bitcoin client for I2P"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:21
+msgid "Unit Tests for I2P router"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:23
+msgid "Bounty Robert"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:24
+msgid "Bounty Syndie"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:27
+msgid "Current monthly running costs:"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:38
+msgid "Big thanks go to the following people who have donated to I2P!"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:39
+#, python-format
+msgid ""
+"If you have made a donation, please send an email to echelon\n"
+"with your name or nick (and optionally homepage) so we can list you here."
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:44
+msgid "Current monthly subscriptions:"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:177
+msgid "2011 donations and costs:"
+msgstr ""
+
+#: i2p2www/pages/site/about/hall-of-fame.html:278
+msgid "Previous to 2011 donations:"
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:2
+msgid "Intro"
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:5
+msgid ""
+"I2P is an anonymous network, exposing a simple layer that applications "
+"can \n"
+"use to anonymously and securely send messages to each other. The network "
+"itself is \n"
+"strictly message based (a la \n"
+"IP), but "
+"there is a \n"
+"library available to allow reliable streaming communication on top of it "
+"(a la \n"
+"TCP)."
+"  \n"
+"All communication is end to end encrypted (in total there are four layers"
+" of \n"
+"encryption used when sending a message), and even the end points "
+"(\"destinations\") \n"
+"are cryptographic identifiers (essentially a pair of public "
+"keys)."
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:19
+#, python-format
+msgid ""
+"To anonymize the messages sent, each client application has their I2P "
+"\"router\"\n"
+"build a few inbound and outbound \"tunnels\" - a \n"
+"sequence of peers that pass messages in one direction (to and from the "
+"client, \n"
+"respectively).  In turn, when a client wants to send a message to another"
+" client, \n"
+"the client passes that message out one of their outbound tunnels "
+"targeting one of the \n"
+"other client's inbound tunnels, eventually reaching the destination.  "
+"Every \n"
+"participant in the network chooses the length of these tunnels, and in "
+"doing so, \n"
+"makes a tradeoff between anonymity, latency, and throughput according to "
+"their \n"
+"own needs.  The result is that the number of peers relaying each end to "
+"end \n"
+"message is the absolute minimum necessary to meet both the sender's and "
+"the \n"
+"receiver's threat model."
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:33
+#, python-format
+msgid ""
+"The first time a client wants to contact another client, they make a "
+"query \n"
+"against the fully distributed \"network \n"
+"database\" - a custom structured \n"
+"distributed hash table (DHT) based off the \n"
+" Kademlia "
+"algorithm. This is done \n"
+"to find the other client's inbound tunnels efficiently, but subsequent "
+"messages \n"
+"between them usually includes that data so no further network database "
+"lookups \n"
+"are required."
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:44
+#, python-format
+msgid "More details about how I2P works are available."
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:48
+msgid "What can you do with it?"
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:50
+#, python-format
+msgid ""
+"Within the I2P network, applications are not restricted in how they can \n"
+"communicate - those that typically use UDP can make use of the base I2P \n"
+"functionality, and those that typically use TCP can use the TCP-like "
+"streaming\n"
+"library.  We have a generic TCP/I2P bridge application \n"
+"(\"I2PTunnel\") that enables people to "
+"forward TCP streams\n"
+"into the I2P network as well as to receive streams out of the network and"
+" \n"
+"forward them towards a specific TCP/IP address."
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:60
+msgid ""
+"I2PTunnel is currently used to let people run their own anonymous website"
+" \n"
+"(\"eepsite\") by running a normal webserver and pointing an I2PTunnel "
+"'server' \n"
+"at it, which people can access anonymously over I2P with a normal web "
+"browser \n"
+"by running an I2PTunnel HTTP proxy (\"eepproxy\").  In addition, we use "
+"the same \n"
+"technique to run an anonymous IRC network (where the IRC server is hosted"
+" \n"
+"anonymously, and standard IRC clients use an I2PTunnel to contact it).  "
+"There \n"
+"are other application development efforts going on as well, such as one "
+"to \n"
+"build an optimized swarming file transfer application (a la \n"
+"BitTorrent), a \n"
+"distributed data store (a la Freenet / \n"
+"MNet), and a blogging system (a "
+"fully \n"
+"distributed LiveJournal), but"
+" those are \n"
+"not ready for use yet."
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:76
+msgid ""
+"I2P is not inherently an \"outproxy\" network - the client you send a "
+"message \n"
+"to is the cryptographic identifier, not some IP address, so the message "
+"must \n"
+"be addressed to someone running I2P.  However, it is possible for that "
+"client\n"
+"to be an outproxy, allowing you to anonymously make use of their Internet"
+" \n"
+"connection.  To demonstrate this, the \"eepproxy\" will accept normal "
+"non-I2P \n"
+"URLs (e.g. \"http://www.i2p.net\") and forward them to a specific "
+"destination\n"
+"that runs a squid HTTP proxy,"
+" allowing \n"
+"simple anonymous browsing of the normal web.  Simple outproxies like that"
+" are \n"
+"not viable in the long run for several reasons (including the cost of "
+"running \n"
+"one as well as the anonymity and security issues they introduce), but in"
+" \n"
+"certain circumstances the technique could be appropriate."
+msgstr ""
+
+#: i2p2www/pages/site/about/intro.html:90
+#, python-format
+msgid ""
+"The I2P development team is an open group, "
+"welcome to all \n"
+"who are interested in getting involved, and"
+" all of \n"
+"the code is open source.  The core I2P SDK "
+"and the \n"
+"current router implementation is done in Java (currently working with "
+"both \n"
+"sun and kaffe, gcj support planned for later), and there is a \n"
+"simple socket based API for accessing the network"
+" from \n"
+"other languages (with a C library available, and both Python and Perl in"
+" \n"
+"development).  The network is actively being developed and has not yet "
+"reached \n"
+"the 1.0 release, but the current roadmap "
+"describes \n"
+"our schedule."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:2 i2p2www/pages/site/about/media.html:4
+msgid "Presentations on I2P"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:5
+#, python-format
+msgid ""
+"Following are links to presentations, videos, and tutorials about I2P. "
+"Links to research papers on I2P are available here."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:8
+#: i2p2www/pages/site/research/papers.html:8
+#, python-format
+msgid "To request an addition to this page, please send to %(email)s."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:11
+msgid ""
+"\n"
+"Newest links are at the bottom of each section."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:16
+msgid "Presentations"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:19
+#, python-format
+msgid ""
+"IIP Presentation at CodeCon\n"
+"MP3 audio\n"
+"transcript\n"
+"Lance James (0x90), February 2002."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:27
+#, python-format
+msgid ""
+"IIP Presentation at ToorCon\n"
+"MP3 audio\n"
+"slides\n"
+"Lance James (0x90), September 2002."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:35
+#, python-format
+msgid ""
+"To Be or I2P\n"
+"(Youtube Video)\n"
+"An introduction into anonymous communication with I2P.\n"
+"To Be or I2P (PDF presentation),\n"
+"Jens Kubieziel, 24C3 Berlin, December 28, 2007."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:44
+#, python-format
+msgid ""
+"Video of I2P talk at Chemnitz Linux Tag,\n"
+"Lars Schimmer,\n"
+"March 14-15, 2009"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:50
+#, python-format
+msgid ""
+"HOPE New York July 17, 2010 - Brief overview of I2P by zzz, at the end of"
+" Adrian Hong's talk\n"
+"\"Hackers for Human Rights\".\n"
+"MP3 audio"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:56
+#, python-format
+msgid ""
+"Into the I2P Darknet: Welcome to Cipherspace\n"
+"Adrian Crenshaw. Schmoocon Firetalk, January 2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:61
+#, python-format
+msgid ""
+"Using techhnology to advance liberty\n"
+"(Youtube Video)\n"
+"Eric Johnson.\n"
+"Agora I/O Unconference, March 27,"
+" 2011.\n"
+"I2P covered from 10:00 to 20:00 in the video."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:69
+#, python-format
+msgid ""
+"The Bright side of darknets, FOSSCOMM Patras May "
+"2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:73
+#, python-format
+msgid ""
+"Common Darknet Weaknesses\n"
+"(Youtube Video)\n"
+"Adrian Crenshaw, AIDE, July "
+"11-15, 2011."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:79
+#, python-format
+msgid ""
+"I2P / Tor Workshop Notes\n"
+"Adrian Crenshaw. DEF CON 19, Las Vegas, August 6, 2011."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:84
+#, python-format
+msgid ""
+"Cipherspaces/Darknets: An Overview Of Attack "
+"Strategies -\n"
+"DEF CON Live version (Youtube Video),\n"
+"\"Studio\" version (Youtube Video),\n"
+"Slides (ppt)\n"
+"Adrian Crenshaw. DEF CON 19, Las Vegas, August 7, 2011."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:94
+msgid ""
+"Modern cipherspace ecosystems, 0x375 "
+"0x06 4/11/2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:100
+msgid "Tutorials"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:103
+#, python-format
+msgid ""
+"I2P Windows Tutorial\n"
+"(Youtube Video)\n"
+"This guide will show you how to install I2P in Windows XP.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:111
+#, python-format
+msgid ""
+"I2P Debian Tutorial\n"
+"(Youtube Video)\n"
+"This will guide you through how to install I2P on a Debian Linux System.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:119
+#, python-format
+msgid ""
+"How to set up anonymous site in I2P\n"
+"(Youtube Video)\n"
+"How to set up an anonymous web site in I2P.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:126
+#, python-format
+msgid ""
+"I2P Tutorial Mac OS X\n"
+"(Youtube Video)\n"
+"A tutorial on how to run i2p on Mac OS X and how to connect to "
+"irc.telecomix.i2p.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:133
+#, python-format
+msgid ""
+"Felix Atari explains the basic principles of I2P"
+"\n"
+"(Youtube Video)\n"
+"Agent Felix Atari of the Telecomix Crypto Munitions Bureau.\n"
+"By Telecomix"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:140
+#, python-format
+msgid ""
+"How to get onto I2P, the anonymous P2P Darknet "
+"(Windows Install)\n"
+"(Youtube Video)\n"
+"This tutorial shows how to install and configure software needed to "
+"access I2P."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:146
+#, python-format
+msgid ""
+"How to connect to I2P\n"
+"(Youtube Video)\n"
+"How to install I2P on Ubuntu."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:152
+#, python-format
+msgid ""
+"Installing the I2P darknet software in Linux\n"
+"(Video)\n"
+"Adrian Crenshaw.\n"
+"January 2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:159
+#, python-format
+msgid ""
+"Short garlic routing animation\n"
+"(Youtube Video)\n"
+"Adrian Crenshaw.\n"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:167
+msgid "Articles and Interviews"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:170
+#, python-format
+msgid ""
+"0x90 Interviewed by DistributedCity\n"
+"Part 1\n"
+"Part 2\n"
+"July 26, 2002."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:178
+#, python-format
+msgid ""
+"0x90 Interviewed by El Pais\n"
+"(original in Spanish)\n"
+"English translation\n"
+"October 31, 2002."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:185
+#, python-format
+msgid ""
+"2003 Business Week article referencing "
+"invisiblenet"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:189
+#, python-format
+msgid ""
+"Netzwelt.de article about being anonymous in the "
+"Internet\n"
+"(German)\n"
+"November 2007."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:195
+#, python-format
+msgid ""
+"zzz interviewed by gulli.com\n"
+"March 2009\n"
+"German translation\n"
+"Russian translation"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:204
+#, python-format
+msgid ""
+"zzz interviewed on the InfoSec Daily Podcast Ep. 454 "
+"(mp3)\n"
+"August 18, 2011"
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:209
+#, python-format
+msgid ""
+"I2P - Anonymity for the Masses,\n"
+"Jonathan Cox,\n"
+"November 11, 2011."
+msgstr ""
+
+#: i2p2www/pages/site/about/media.html:215
+#, python-format
+msgid ""
+"zzz and Lance James interviewed on the InfoSec Daily "
+"Podcast Ep. 596 (mp3)\n"
+"February 16, 2012"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:4
+msgid "I2P Project Members"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:5
+#, python-format
+msgid ""
+"We are a small group of people spread around several continents, working "
+"to\n"
+"advance different aspects of the project and discussing the design of the"
+"\n"
+"network.\n"
+"Get involved!"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:14
+msgid "Admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:15
+msgid "Project Manager"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:17
+msgid "point of contact of last resort"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:20
+msgid "Treasurer"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:22
+msgid "manage donations / accounts / bounties"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:25
+msgid "PR manager"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:27
+msgid "press contact, manages public relations and affairs"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:30
+#, python-format
+msgid "Forum admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:32
+msgid "manage the public user forum"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:35
+msgid "Mirrors admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:37
+msgid "manage the project mirrors"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:40
+#, python-format
+msgid "Monotone guru"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:42
+msgid "manage the public monotone repositories"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:45
+msgid "Packager; Linux"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:47
+msgid "Linux (Debian/Ubuntu) distribution packager"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:50
+msgid "Packager; Windows"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:52
+msgid "Windows installer packager"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:55
+msgid "Release Manager"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:57
+msgid "Builds and signs the releases"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:60
+msgid "Update admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:62
+msgid "Monitors and recruits in-network update hosts"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:65
+msgid "Reseed admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:67
+msgid "Monitors, advises and recruits reseed hosts"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:70
+msgid "Security expert"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:71 i2p2www/pages/site/about/team.html:76
+#: i2p2www/pages/site/about/team.html:81 i2p2www/pages/site/about/team.html:91
+#: i2p2www/pages/site/about/team.html:101
+#: i2p2www/pages/site/about/team.html:138
+#: i2p2www/pages/site/about/team.html:148
+#: i2p2www/pages/site/about/team.html:153
+#: i2p2www/pages/site/about/team.html:158
+#: i2p2www/pages/site/about/team.html:163
+#: i2p2www/pages/site/about/team.html:168
+#: i2p2www/pages/site/about/team.html:201
+#: i2p2www/pages/site/about/team.html:219
+#: i2p2www/pages/site/get-involved/bounties/index.html:35
+#: i2p2www/pages/site/get-involved/bounties/index.html:42
+#: i2p2www/pages/site/get-involved/bounties/index.html:49
+#: i2p2www/pages/site/get-involved/bounties/index.html:56
+#: i2p2www/pages/site/get-involved/bounties/index.html:63
+#: i2p2www/pages/site/get-involved/bounties/index.html:70
+#: i2p2www/pages/site/get-involved/bounties/index.html:84
+#: i2p2www/pages/site/get-involved/bounties/index.html:97
+msgid "vacant"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:72
+msgid "threat model / crypto expert"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:75
+msgid "User Advocate"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:77
+msgid "gather, prioritize, advocate for user needs"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:80
+msgid "Web Designer"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:82
+msgid "manage the public project website content design"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:85
+#, python-format
+msgid "Webserver admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:87
+msgid "manage the public project webservers"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:90
+#, python-format
+msgid "Website admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:92
+msgid "manage the public project website content"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:95
+msgid "News Admin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:97
+msgid "manage router console news feed"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:100
+msgid "Director of passion"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:102
+msgid "community motivator"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:106
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+msgid "Dev"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:107
+msgid "Core Lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:109
+msgid "lead dev for the SDK and router"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:112
+#, python-format
+msgid "I2P mail lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:114
+msgid "organize and develop the i2p mail system"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:117
+#, python-format
+msgid "I2Host lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:119
+msgid "I2Host addressbook application"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:122
+#, python-format
+msgid "BOB lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:124
+msgid "Basic Open Bridge"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:127
+#, python-format
+msgid "I2P-Bote lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:129
+msgid "I2PBote plugin"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:132
+#, python-format
+msgid "Robert lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:134
+msgid "Robert BitTorrent client"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:137
+#, python-format
+msgid "I2Phex lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:139
+msgid "I2Phex Gnutella client"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:142
+#, python-format
+msgid "I2PSnark lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:144
+msgid "Maintains the integrated Bittorrent client"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:147
+#, python-format
+msgid "iMule lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:149
+msgid "eMule client over I2P"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:152
+#, python-format
+msgid "Syndie lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:154
+#: i2p2www/pages/site/get-involved/bounties/syndie-2012.html:2
+#: i2p2www/pages/site/get-involved/bounties/syndie-2012.html:3
+msgid "Syndie development"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:157
+msgid "Susimail lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:159
+msgid "Susimail development"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:162
+msgid "Console"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:164
+msgid "Router console HTML/CSS design"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:167
+msgid "SAM"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:169
+msgid "SAM maintainer"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:172
+msgid "Console Translations"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:174
+msgid "Chinese"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:178
+msgid "Dutch"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:182
+msgid "French"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:186
+msgid "German"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:190
+msgid "Russian"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:194
+msgid "Spanish"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:198
+msgid "Arabic"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:202
+msgid "Other languages"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:205
+msgid "Contributors"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:207
+msgid "fire2pe dev, console enhancements"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:211
+msgid "desktopgui, dijjer port"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:215
+msgid "Debian/Ubuntu Packager and PPA maintainer"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:220
+msgid "Help needed on many fronts!"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:224
+msgid "Past contributors"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:226
+msgid "I2PTunnel development, ministreaming library"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:230
+msgid "Project lead, Syndie lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:234
+msgid "Project lead, Syndie lead, I2Phex, support guru"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:238
+msgid "iMule lead"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:242
+#: i2p2www/pages/site/about/team.html:246
+#: i2p2www/pages/site/about/team.html:250
+msgid "I2Phex work"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:254
+msgid "Python SAM library, attack simulations"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:258
+msgid "i2pmail development"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:262
+msgid "Syndie help"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:266
+msgid "i2p mail,susimail and susidns apps"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:270
+msgid "I2Phex (port of Phex to I2P)"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:274
+msgid "addressbook,i2p-bt,syndie client"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:278
+msgid "organize and develop the i2p-bt BitTorrent port"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:282
+msgid "addressbook, i2p-bt, syndie client development"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:286
+msgid "encryption and signature routines, I2PIM"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:290
+msgid "SAM jython code, work on stasher (DHT) and v2v (VoI2P)"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:294
+msgid "installer, systray, bogobot"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:298
+msgid "jbigi development, wiki migration, doc cleanup"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:302
+msgid "java debugging and client development on I2PTunnel and the router console"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:306
+msgid "SAM perl module"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:310
+msgid "i2psnark work"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:314
+msgid "java cleanup"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:318
+msgid "docs. wiki migration"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:322
+msgid "translations into French"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:326
+msgid "C port of jcpuid"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:330
+msgid "C# SAM library, pants, fortuna integration"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:334
+msgid "libSAM"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:338
+#: i2p2www/pages/site/about/team.html:342
+msgid "i2p-bt tracker development"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:346
+msgid "Console and website themes"
+msgstr ""
+
+#: i2p2www/pages/site/about/team.html:349
+msgid "… and many others"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:2
+msgid "Future Performance Improvements"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:4
+#: i2p2www/pages/site/docs/api/bob.html:3
+#: i2p2www/pages/site/docs/api/datagrams.html:3
+#: i2p2www/pages/site/docs/how/garlic-routing.html:3
+#: i2p2www/pages/site/docs/protocol/i2np.html:3
+#: i2p2www/pages/site/docs/protocol/index.html:3
+#: i2p2www/pages/site/docs/spec/datagrams.html:3
+#: i2p2www/pages/site/docs/transport/ntcp.html:3
+msgid "August 2010"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:7
+msgid ""
+"There are a few major techniques that can be done to improve the "
+"perceived\n"
+"performance of I2P - some of the following are CPU related, others "
+"bandwidth\n"
+"related, and others still are protocol related.  However, all of those\n"
+"dimensions affect the latency, throughput, and perceived performance of "
+"the\n"
+"network, as they reduce contention for scarce resources.  This list is of"
+" course\n"
+"not comprehensive, but it does cover the major ones that are seen."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:15
+#: i2p2www/pages/site/about/performance/index.html:106
+#, python-format
+msgid ""
+"For past performance improvements see the \n"
+"Performance History."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:20
+msgid "Better peer profiling and selection"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:21
+#, python-format
+msgid ""
+"Probably one of the most important parts of getting faster performance "
+"will\n"
+"be improving how routers choose the peers that they build their tunnels "
+"through\n"
+"- making sure they don't use peers with slow links or ones with fast "
+"links that\n"
+"are overloaded, etc.  In addition, we've got to make sure we don't expose"
+"\n"
+"ourselves to a Sybil attack\n"
+"from a powerful adversary with lots of fast machines."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:30
+msgid "Network database tuning"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:31
+msgid ""
+"We're going to want to be more efficient with the network database's "
+"healing\n"
+"and maintenance algorithms - rather than constantly explore the keyspace "
+"for new\n"
+"peers - causing a significant number of network messages and router load "
+"- we\n"
+"can slow down or even stop exploring until we detect that there's "
+"something new\n"
+"worth finding (e.g. decay the exploration rate based upon the last time "
+"someone\n"
+"gave us a reference to someone we had never heard of).  We can also do "
+"some\n"
+"tuning on what we actually send - how many peers we bounce back (or even "
+"if we\n"
+"bounce back a reply), as well as how many concurrent searches we perform."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:42
+msgid "Session Tag Tuning and Improvements"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:43
+#, python-format
+msgid ""
+"The way the ElGamal/AES+SessionTag "
+"algorithm\n"
+"works is by managing a set of random one-time-use 32 byte arrays, and "
+"expiring\n"
+"them if they aren't used quickly enough.  If we expire them too soon, "
+"we're\n"
+"forced to fall back on a full (expensive) ElGamal encryption, but if we "
+"don't\n"
+"expire them quickly enough, we've got to reduce their quantity so that we"
+" don't\n"
+"run out of memory (and if the recipient somehow gets corrupted and loses "
+"some\n"
+"tags, even more encryption failures may occur prior to detection).  With "
+"some\n"
+"more active detection and feedback driven algorithms, we can safely and "
+"more\n"
+"efficiently tune the lifetime of the tags, replacing the ElGamal "
+"encryption with\n"
+"a trivial AES operation."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:55
+#, python-format
+msgid ""
+"Additional ideas for improving Session Tag delivery are described on the\n"
+"ElGamal/AES+SessionTag page."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:61
+msgid "Migrate sessionTag to synchronized PRNG"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:62
+#, python-format
+msgid ""
+"Right now, our ElGamal/AES+SessionTag \n"
+"algorithm works by tagging each encrypted message with a unique random \n"
+"32 byte nonce (a \"session tag\"), identifying that message as being "
+"encrypted \n"
+"with the associated AES session's key. This prevents peers from "
+"distinguishing \n"
+"messages that are part of the same session, since each message has a "
+"completely \n"
+"new random tag. To accomplish this, every few messages bundle a whole \n"
+"new set of session tags within the encrypted message itself, "
+"transparently \n"
+"delivering a way to identify future messages. We then have to keep track"
+" \n"
+"of what messages are successfully delivered so that we know what tags \n"
+"we may use."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:74
+msgid ""
+"This works fine and is fairly robust, however it is inefficient in terms"
+" \n"
+"of bandwidth usage, as it requires the delivery of these tags ahead of \n"
+"time (and not all tags may be necessary, or some may be wasted, due to \n"
+"their expiration). On average though, predelivering the session tag costs"
+" \n"
+"32 bytes per message (the size of a tag). As Taral suggested though, that"
+" \n"
+"size can be avoided by replacing the delivery of the tags with a "
+"synchronized \n"
+"PRNG - when a new session is established (through an ElGamal encrypted \n"
+"block), both sides seed a PRNG for use and generate the session tags on \n"
+"demand (with the recipient precalculating the next few possible values \n"
+"to handle out of order delivery)."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:87
+msgid "Longer lasting tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:88
+msgid ""
+"The current default tunnel duration of 10 minutes is fairly arbitrary, "
+"though\n"
+"it \"feels okay\".  Once we've got tunnel healing code and more effective"
+" failure\n"
+"detection, we'll be able to more safely vary those durations, reducing "
+"the\n"
+"network and CPU load (due to expensive tunnel creation messages)."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:95
+msgid ""
+"This appears to be an easy fix for high load on the big-bandwidth "
+"routers, but\n"
+"we should not resort to it until we've tuned the tunnel building "
+"algorithms further.\n"
+"However, the 10 minute tunnel lifetime is hardcoded in quite a few "
+"places,\n"
+"so substantial effort would be required to change the duration.\n"
+"Also, it would be difficult to maintain backward compatibility with such "
+"a change."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:102
+msgid ""
+"Currently, since the network average tunnel build success rate is fairly "
+"high,\n"
+"there are no current plans to extend tunnel lifetime."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:108
+msgid "Adjust the timeouts"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:109
+msgid ""
+"Yet another of the fairly arbitrary but \"okay feeling\" things we've got"
+" are the\n"
+"current timeouts for various activities.  Why do we have a 60 second "
+"\"peer\n"
+"unreachable\" timeout?  Why do we try sending through a different tunnel "
+"that a\n"
+"LeaseSet advertises after 10 seconds?  Why are the network database "
+"queries\n"
+"bounded by 60 or 20 second limits?  Why are destinations configured to "
+"ask for a\n"
+"new set of tunnels every 10 minutes?  Why do we allow 60 seconds for a "
+"peer to\n"
+"reply to our request that they join a tunnel?  Why do we consider a "
+"tunnel that\n"
+"doesn't pass our test within 60 seconds \"dead\"?"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:119
+msgid ""
+"Each of those imponderables can be addressed with more adaptive code, as "
+"well\n"
+"as tunable parameters to allow for more appropriate tradeoffs between\n"
+"bandwidth, latency, and CPU usage."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:125
+msgid "Full streaming protocol improvements"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:128
+msgid ""
+"Perhaps re-enable the interactive stream profile (the \n"
+"current implementation only uses the bulk stream profile)."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:134
+msgid ""
+"Client level bandwidth limiting (in either or both directions on a "
+"stream, \n"
+"or possibly shared across multiple streams). This would be in addition to"
+" \n"
+"the router's overall bandwidth limiting, of course."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:141
+msgid ""
+"Access control lists (only allowing streams to or from certain other "
+"known \n"
+"destinations)."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:147
+msgid ""
+"Web controls and monitoring the health of the various streams, as well \n"
+"as the ability to explicitly close or throttle them."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/future.html:153
+#, python-format
+msgid ""
+"Additional ideas for improving the streaming library are described on the"
+"\n"
+"streaming library page."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:2
+msgid "Performance History"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:4
+#, python-format
+msgid ""
+"Notable performance improvements have been made using the techniques "
+"below.\n"
+"There is more to do, see the Performance "
+"page\n"
+"for current issues and thoughts."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:10
+msgid "Native math"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:11
+#: i2p2www/pages/site/about/performance/history.html:67
+#: i2p2www/pages/site/about/performance/history.html:82
+#: i2p2www/pages/site/about/performance/history.html:105
+#: i2p2www/pages/site/about/performance/history.html:133
+msgid "implemented"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:12
+#, python-format
+msgid ""
+"When I last profiled the I2P code, the vast majority of time was spent "
+"within\n"
+"one function: java.math.BigInteger's\n"
+"modPow.\n"
+"Rather than try to tune this method, we'll call out to\n"
+"GNU MP - an insanely fast math library\n"
+"(with tuned assembler for many architectures). (Editor: see\n"
+"NativeBigInteger for faster public key "
+"cryptography)"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:23
+#, python-format
+msgid ""
+"\n"
+"ugha and duck are working on the C/JNI glue code, and the existing java "
+"code\n"
+"is already deployed with hooks for that whenever its ready.  Preliminary "
+"results\n"
+"look fantastic - running the router with the native GMP modPow is "
+"providing over\n"
+"a 800% speedup in encryption performance, and the load was cut in half.  "
+"This\n"
+"was just on one user's machine, and things are nowhere near ready for "
+"packaging\n"
+"and deployment, yet."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:32
+msgid "Garlic wrapping a \"reply\" LeaseSet"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:33
+msgid "implemented but needs tuning"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:34
+msgid ""
+"This algorithm tweak will only be relevant for applications that want "
+"their\n"
+"peers to reply to them (though that includes everything that uses "
+"I2PTunnel or\n"
+"mihi's ministreaming lib):"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:39
+msgid ""
+"Previously, when Alice sent Bob a message, when Bob replied he had to do "
+"a\n"
+"lookup in the network database - sending out a few requests to get "
+"Alice's\n"
+"current LeaseSet.  If he already has Alice's current LeaseSet, he can "
+"instead\n"
+"just send his reply immediately - this is (part of) why it typically "
+"takes a\n"
+"little longer talking to someone the first time you connect, but "
+"subsequent\n"
+"communication is faster.  Currently - for all clients - we wrap\n"
+"the sender's current LeaseSet in the garlic that is delivered to the "
+"recipient,\n"
+"so that when they go to reply, they'll always have the LeaseSet "
+"locally\n"
+"stored - completely removing any need for a network database lookup on "
+"replies.\n"
+"This trades off a large portion of the sender's bandwidth for that faster"
+" reply.\n"
+"If we didn't do this very often,\n"
+"overall network bandwidth usage would decrease, since the recipient "
+"doesn't\n"
+"have to do the network database lookup."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:54
+#, python-format
+msgid ""
+"For unpublished LeaseSets such as \"shared clients\", this is the only "
+"way to\n"
+"get the LeaseSet to Bob. Unfortunately this bundling every time adds\n"
+"almost 100% overhead to a high-bandwidth connection, and much more to\n"
+"a connection with smaller messages."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:60
+msgid ""
+"Changes scheduled for release 0.6.2 will bundle the LeaseSet only when\n"
+"necessary, at the beginning of a connection or when the LeaseSet changes."
+"\n"
+"This will substantially reduce the total overhead of I2P messaging."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:66
+msgid "More efficient TCP rejection"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:68
+msgid ""
+"At the moment, all TCP connections do all of their peer validation after\n"
+"going through the full (expensive) Diffie-Hellman handshaking to "
+"negotiate a\n"
+"private session key.  This means that if someone's clock is really wrong,"
+" or\n"
+"their NAT/firewall/etc is improperly configured (or they're just running "
+"an\n"
+"incompatible version of the router), they're going to consistently "
+"(though not\n"
+"constantly, thanks to the shitlist) cause a futile expensive "
+"cryptographic\n"
+"operation on all the peers they know about.  While we will want to keep "
+"some\n"
+"verification/validation within the encryption boundary, we'll want to "
+"update the\n"
+"protocol to do some of it first, so that we can reject them cleanly\n"
+"without wasting much CPU or other resources."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:81
+msgid "Adjust the tunnel testing"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:83
+msgid ""
+"Rather than going with the fairly random scheme we have now, we should "
+"use a\n"
+"more context aware algorithm for testing tunnels.  e.g. if we already "
+"know its\n"
+"passing valid data correctly, there's no need to test it, while if we "
+"haven't\n"
+"seen any data through it recently, perhaps its worthwhile to throw some "
+"data its\n"
+"way.  This will reduce the tunnel contention due to excess messages, as "
+"well as\n"
+"improve the speed at which we detect - and address - failing tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:92
+msgid "Persistent Tunnel / Lease Selection"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:93
+msgid ""
+"Outbound tunnel selection implemented in 0.6.1.30, inbound lease "
+"selection \n"
+"implemented in release 0.6.2."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:97
+msgid ""
+"Selecting tunnels and leases at random for every message creates a large"
+" \n"
+"incidence of out-of-order delivery, which prevents the streaming lib from"
+" \n"
+"increasing its window size as much as it could. By persisting with the \n"
+"same selections for a given connection, the transfer rate is much faster."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:104
+msgid "Compress some data structures"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:106
+msgid ""
+"The I2NP messages and the data they contain is already defined in a "
+"fairly\n"
+"compact structure, though one attribute of the RouterInfo structure is "
+"not -\n"
+"\"options\" is a plain ASCII name = value mapping.  Right now, we're "
+"filling it\n"
+"with those published statistics - around 3300 bytes per peer.  Trivial to"
+"\n"
+"implement GZip compression would nearly cut that to 1/3 its size, and "
+"when you\n"
+"consider how often RouterInfo structures are passed across the network, "
+"that's\n"
+"significant savings - every time a router asks another router for a "
+"networkDb\n"
+"entry that the peer doesn't have, it sends back 3-10 RouterInfo of them."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:117
+msgid "Update the ministreaming protocol"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:118
+msgid "replaced by full streaming protocol"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:119
+msgid ""
+"Currently mihi's ministreaming library has a fairly simple stream "
+"negotiation\n"
+"protocol - Alice sends Bob a SYN message, Bob replies with an ACK "
+"message, then\n"
+"Alice and Bob send each other some data, until one of them sends the "
+"other a\n"
+"CLOSE message.  For long lasting connections (to an IRC server, for "
+"instance),\n"
+"that overhead is negligible, but for simple one-off request/response "
+"situations\n"
+"(an HTTP request/reply, for instance), that's more than twice as many "
+"messages as\n"
+"necessary.  If, however, Alice piggybacked her first payload in with the "
+"SYN\n"
+"message, and Bob piggybacked his first reply with the ACK - and perhaps "
+"also\n"
+"included the CLOSE flag - transient streams such as HTTP requests could "
+"be\n"
+"reduced to a pair of messages, instead of the "
+"SYN+ACK+request+response+CLOSE."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:132
+msgid "Implement full streaming protocol"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:134
+msgid ""
+"The ministreaming protocol takes advantage of a poor design decision in "
+"the\n"
+"I2P client protocol (I2CP) - the exposure of \"mode=GUARANTEED\", "
+"allowing what\n"
+"would otherwise be an unreliable, best-effort, message based protocol to "
+"be used\n"
+"for reliable, blocking operation (under the covers, its still all "
+"unreliable and\n"
+"message based, with the router providing delivery guarantees by garlic "
+"wrapping\n"
+"an \"ACK\" message in with the payload, so once the data gets to the "
+"target, the\n"
+"ACK message is forwarded back to us [through tunnels, of course])."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/history.html:143
+#, python-format
+msgid ""
+"As I've said, having\n"
+"I2PTunnel (and the ministreaming lib) go this route was the best thing "
+"that\n"
+"could be done, but more efficient mechanisms are available.  When we rip "
+"out the\n"
+"\"mode=GUARANTEED\" functionality, we're essentially leaving ourselves "
+"with an\n"
+"I2CP that looks like an anonymous IP layer, and as such, we'll be able to"
+"\n"
+"implement the streaming library to take advantage of the design "
+"experiences of\n"
+"the TCP layer - selective ACKs, congestion detection, nagle, etc."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:5
+msgid ""
+"How does I2P work, why is it slow, and why does it not use my full "
+"bandwidth?"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:7
+msgid ""
+"Probably one of the most frequent things people ask is \"how fast is "
+"I2P?\",\n"
+"and no one seems to like the answer - \"it depends\".  After trying out "
+"I2P, the\n"
+"next thing they ask is \"will it get faster?\", and the answer to that is"
+" a most\n"
+"emphatic yes."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:14
+msgid ""
+"I2P is a full dynamic network. Each client is known to other nodes and "
+"tests local known nodes for reachability and capacity.\n"
+"Only reachable and capable nodes are saved to a local NetDB (This is "
+"generally only a portion of the network, around 500-1000).\n"
+"When I2P builds tunnels, it selects the best resource from this pool. For"
+" example, a small subset of 20-50 nodes are only available to build "
+"tunnels with.\n"
+"Because testing happens every minute, the pool of used nodes changes "
+"every minute.\n"
+"Each I2P node knows a different part of the net, meaning that each router"
+" has a different set of I2P nodes to be used for tunnels.\n"
+"Even if two routers have the same subset of known nodes, the tests for "
+"reachability and capacity will likely show different results, as the "
+"other routers could be under load just as one router tests, but be free "
+"if the second router tests."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:23
+msgid ""
+"The above describes why each I2P node has different nodes to build "
+"tunnels.\n"
+"Because every I2P node has a different latency and bandwith, tunnels "
+"(which are built via those nodes) have different latency and bandwidth "
+"values.\n"
+"And because every I2P node has different tunnels built, no two I2P nodes "
+"have the same tunnel sets."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:29
+msgid ""
+"A server/client is known as a \"destination\" and each destination has at"
+" least one inbound and one outbound tunnel. The default is 3 hops per "
+"tunnel.\n"
+"This adds up to 12 hops (aka 12 different I2P nodes) for a full roundtrip"
+" client-server-client."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:34
+msgid ""
+"Each data package is sent through 6 other I2P nodes until it reaches the "
+"server:"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:40
+msgid "and on way back 6 different I2P nodes:"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:47
+msgid ""
+"As most traffic on I2P (www, torrent,...) needs ack packages until new "
+"data is sent, it needs to wait until a ack package returns from the "
+"server.\n"
+"In the end: send data, wait for ack, send more data, wait for ack,..\n"
+"As the RTT (RoundTripTime) adds up from the latency of each individual "
+"I2P node and each connection on this roundtrip, it takes usually 1-3 "
+"seconds until a ack package comes back to the client.\n"
+"With some internals of TCP and I2P transport, a data package has a "
+"limited size and cannot be as large as we want it to be.\n"
+"Together these conditions set a limit of max bandwidth per tunnel of "
+"20-50 kbyte/sec.\n"
+"But if ONLY ONE hop in the tunnel has only 5 kb/sec bandwidth to spend, "
+"the whole tunnel is limited to 5 kb/sec, independent of the \n"
+"latency and other limitations."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:57
+msgid ""
+"Due to encryption used and other setups in I2P (howto built up tunnels, "
+"latency, ...) it is quite expensive in CPU time to build a tunnel. This "
+"is \n"
+"why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels"
+" to transport data. With a max of 50 kb/sec per tunnel, a destination "
+"could \n"
+"use roughly 300 kb/sec traffic combined ( in reality it could be more if "
+"shorter tunnels are used with low or no anonymity available).\n"
+"Used tunnels are discarded every 10 minutes and new ones are built up.\n"
+"This change of tunnels (and sometimes clients that shutdown hard due to "
+"usage of \"shut down at once\" or situations where there is power loss) "
+"does \n"
+"sometimes break tunnels and connections, as seen on the IRC2P Network in "
+"loss of connection (ping timeout) or on when using eepget."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:66
+msgid ""
+"With a limited set of destinations and a limited set of tunnels per "
+"destination, one I2P node only uses a limited set of tunnels across other"
+" I2P nodes.\n"
+"For example, if an I2P node is \"hop1\" in the small example above, we "
+"only see 1 participating tunnel originating from the client.\n"
+"If we sum up the whole I2P network, only a rather limited number of "
+"participating tunnels could be built with a limited amount of bandwidth "
+"all together.\n"
+"If one distributes these limited numbers across the number of I2P nodes, "
+"there is only a fraction of available bandwidth/capacity available for "
+"use."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:73
+msgid ""
+"To remain anonymous one router should not be used by the whole network "
+"for building tunnels.\n"
+"If one router does act as a tunnel router for ALL I2P nodes, it becomes a"
+" very real central point of failure as well as a central point to grab "
+"IPs and data from the clients. This is not good.\n"
+"I2P attempts to spread the load across a lot of I2P nodes because of this"
+" reason."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:79
+msgid ""
+"Another point is the full mesh network. Each connection hop-hop utilizes "
+"one TCP or UDP connection on the I2P nodes. With 1000 connections, one "
+"sees \n"
+"1000 TCP connections. That is quite a lot and some home and small office "
+"routers (DSL, cable,..) only allow a small number of connections (or just"
+" go mad if you use more than X connections).\n"
+"I2P tries to limit these connections to be under 1500 per UDP and per TCP"
+" type.\n"
+"This limits the amount of traffic routed across your I2P node as well."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:86
+msgid ""
+"In summary, I2P is very complex and there is no easy way to pinpoint why "
+"your node is not used.\n"
+"If your node is reachable and has a bandwidth setting of >128 kbyte/sec "
+"shared and is reachable 24/7, it should be used after some time for "
+"participating traffic.\n"
+"If it is down in between, the testing of your I2P node done by other "
+"nodes will tell them: you are not reachable. This blocks your node for at"
+" least \n"
+"24h on other nodes. So, the other nodes which tested you as down will not"
+" use your node for 24h for building tunnels. This is why your traffic "
+"will \n"
+"be lower after a restart/shutdown for a minimum of 24h."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:94
+msgid ""
+"Also: other I2P nodes needs to know your I2P router to test it for "
+"reachability and capacity. It takes time for other nodes to get known to "
+"your node. \n"
+"It will be faster if you use I2P and build more tunnels, e.g. use a "
+"torrent or www for some time."
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:99
+msgid "Performance Improvements"
+msgstr ""
+
+#: i2p2www/pages/site/about/performance/index.html:101
+#, python-format
+msgid ""
+"For possible future performance improvements see\n"
+"Future Performance Improvements."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/freenet.html:2
+msgid "I2P Compared to Freenet"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/freenet.html:8
+msgid ""
+"Freenet is a fully distributed, peer to peer anonymous publishing "
+"network, offering \n"
+"secure ways to store data, as well as some approaches attempting to "
+"address the loads\n"
+"of a flash flood.  While Freenet is designed as a distributed data store,"
+" people have\n"
+"built applications on top of it to do more generic anonymous "
+"communication, such as \n"
+"static websites and message boards."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/freenet.html:16
+#, python-format
+msgid ""
+"Compared to I2P, Freenet offers some substantial benefits - it is a "
+"distributed data\n"
+"store, while I2P is not, allowing people to retrieve the content "
+"published by others \n"
+"even when the publisher is no longer online.  In addition, it should be "
+"able to \n"
+"distribute popular data fairly efficiently.  I2P itself does not and will"
+" not provide \n"
+"this functionality.  On the other hand, there is overlap for users who "
+"simply want to \n"
+"communicate with each other anonymously through websites, message boards,"
+" file sharing\n"
+"programs, etc.  There have also been some attempts to develop a "
+"distributed data \n"
+"store to run on top of I2P,\n"
+"(most recently a port of Tahoe-LAFS)\n"
+"but nothing is yet ready for general use."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/freenet.html:29
+msgid ""
+"However, even ignoring any implementations issues, there are some "
+"concerns \n"
+"about Freenet's algorithms from both a scalability and anonymity "
+"perspective, owing \n"
+"largely to Freenet's heuristic driven routing.  The interactions of "
+"various techniques \n"
+"certainly may successfully deter various attacks, and perhaps some "
+"aspects of the \n"
+"routing algorithms will provide the hoped for scalability.  "
+"Unfortunately, not much\n"
+"analysis of the algorithms involved has resulted in positive results, but"
+" there is still\n"
+"hope.  At the very least, Freenet does provide substantial anonymity "
+"against an attacker\n"
+"who does not have the resources necessary to analyze it further."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/index.html:2
+msgid "Comparing I2P to other projects"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/index.html:4
+msgid ""
+"There are a great many other applications and projects working on "
+"anonymous \n"
+"communication and I2P has been inspired by much of their efforts.  This "
+"is not \n"
+"a comprehensive list of anonymity resources - both freehaven's \n"
+"Anonymity "
+"Bibliography\n"
+"and GNUnet's related "
+"projects\n"
+"serve that purpose well.  That said, a few systems stand out for further\n"
+"comparison. The following have individual comparison pages:"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/index.html:20
+#, python-format
+msgid ""
+"The following are discussed on the other "
+"networks page:"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/index.html:32
+#, python-format
+msgid ""
+"The content of this page is subject to update, discussion and dispute, "
+"and we welcome comments and additions.\n"
+"You may contribute an analysis by entering a new ticket on Trac."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:2
+msgid "I2P Compared to Other Anonymous Networks"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:5
+msgid "The following networks are discussed on this page."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:16
+#, python-format
+msgid ""
+"Most of the following sections are fairly old, and may not be accurate.\n"
+"For an overview of available comparisons, see the\n"
+"main network comparisons page.\n"
+"You may contribute an analysis by entering a\n"
+"new ticket on %(trac)s."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:29
+#, python-format
+msgid ""
+"Morphmix and Tarzan are both fully distributed, peer to peer networks of"
+" \n"
+"anonymizing proxies, allowing people to tunnel out through the low "
+"latency \n"
+"mix network.  Morphmix includes some very interesting collusion detection"
+" \n"
+"algorithms and Sybil defenses, while Tarzan makes use of the scarcity of "
+"IP\n"
+"addresses to accomplish the same.  The two primary differences between \n"
+"these systems and I2P are related to I2P's threat model \n"
+"and their out-proxy design (as opposed to providing both sender and "
+"receiver \n"
+"anonymity).  There is source code available to both systems, but we are "
+"not aware \n"
+"of their use outside of academic environments."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:153
+msgid ""
+"\n"
+"Mixminion and Mixmaster are networks to support anonymous email against a"
+" very\n"
+"powerful adversary.\n"
+"High-latency messaging applications running on top of I2P\n"
+"(for example\n"
+"Syndie or\n"
+"I2PBote)\n"
+"may perhaps prove adequate to meet the threat\n"
+"model of those adversaries, while running in parallel along side the "
+"needs of low latency users, to provide\n"
+"a significantly larger anonymity set.\n"
+"High-latency support within the I2P router itself may or may not be added"
+" in a distant future release.\n"
+"It is too early to say if I2P will meet the needs of users requiring "
+"extreme protection for email."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:167
+msgid ""
+"As with Tor and Onion Routing, \n"
+"both Mixminion and Mixmaster take the directory based approach as well."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:177
+#, python-format
+msgid ""
+"JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing "
+"web requests,\n"
+"and as such it has a few centralized nodes (participants in the cascade) "
+"that blend\n"
+"and mix requests from clients through the sequence of nodes (the cascade)"
+" before \n"
+"proxying out onto the web.  The scope, threat model, and security is "
+"substantially \n"
+"different from I2P, but for those who don't require significant anonymity"
+" but still\n"
+"are not satisfied with an Anonymizer-like service, JAP is worth "
+"reviewing.  One\n"
+"caution to note is that anyone under the jurisdiction of the German "
+"courts may want\n"
+"to take care, as the German Federal Bureau of Criminal Investigation "
+"(FBCI) has \n"
+"successfully mounted an \n"
+"attack \n"
+"on the network.  Even though the method of this attack was later found to"
+" be illegal \n"
+"in the German courts, the fact that the data was successfully collected "
+"is the \n"
+"concern.  Courts change their minds based upon circumstance, and this is "
+"evidence that \n"
+"if a government body or intelligence agency wanted to, they could gather "
+"the data, even \n"
+"if it may be found inadmissible in some courts later)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:199
+#, python-format
+msgid ""
+"Both of these systems work through the same basic \n"
+"antnet routing, providing some degree of\n"
+"anonymity based on the threat model of providing plausible deniability "
+"against a simple \n"
+"non-colluding adversary.  With the antnet routing, they first either do a"
+" random walk or a \n"
+"broadcast search to find some peer with the data or identity desired, and"
+" then use a feedback\n"
+"algorithm to optimize that found path.  This works well for applications "
+"that merely want to know \n"
+"what other people around them have to offer - \"How are y'all doing\" vs."
+" \"Hey Alice, how are you\" - \n"
+"you basically get a local cluster of nodes that can share files with and "
+"maintain some degree of \n"
+"anonymity (though you don't have much control over who is in that group "
+"of peers)."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:211
+msgid ""
+"However, the algorithm does not scale well at all - if the application "
+"wants to speak with a \n"
+"particular peer it ends up doing a broadcast search or random walk "
+"(though if they are lucky enough\n"
+"for that to succeed, the antnet routing should optimize that found "
+"connection).  This means that \n"
+"while these networks can work great at small scales, they are not "
+"suitable for large networks where\n"
+"someone wants to get in touch with another specific peer.  That does not "
+"mean that there is no \n"
+"value in these systems, just that their applicability is limited to "
+"situations where their \n"
+"particular issues can be addressed."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:222
+#, python-format
+msgid ""
+"This was a closed-source network targeted at Iranian users.\n"
+"Tor did a\n"
+"good writeup on what to look for in a circumvention tool.\n"
+"Suffice it to say that being closed source and publicly targeting a "
+"specific country are not good ideas.\n"
+"I2P is, of course, open source. However, that source, and our\n"
+"technical documentation, need much more review."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:231
+msgid "Paid VPN Services"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:232
+#: i2p2www/pages/site/comparison/other-networks.html:238
+#, python-format
+msgid ""
+"You may contribute an analysis by entering a\n"
+"new ticket on %(trac)s."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/other-networks.html:237
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:14
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:169
+msgid "Others"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:2
+msgid "I2P Compared to Tor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:8
+#, python-format
+msgid ""
+"Tor and Onion Routing are both anonymizing proxy networks, \n"
+"allowing people to tunnel out through their low latency mix \n"
+"network. The two primary differences between Tor / \n"
+"Onion-Routing and I2P are again related to differences in \n"
+"the threat model and the out-proxy design (though Tor\n"
+"supports hidden services as well).  In addition, Tor\n"
+"takes the directory-based approach - providing a \n"
+"centralized point to manage the overall 'view' of the \n"
+"network, as well as gather and report statistics, as \n"
+"opposed to I2P's distributed network \n"
+"database and peer selection."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:22
+msgid ""
+"The I2P/Tor outproxy functionality does have a few \n"
+"substantial weaknesses against certain attackers - \n"
+"once the communication leaves the mixnet, global passive\n"
+"adversaries can more easily mount traffic analysis.  In \n"
+"addition, the outproxies have access to the cleartext \n"
+"of the data transferred in both directions, and \n"
+"outproxies are prone to abuse, along with all of the \n"
+"other security issues we've come to know and love with \n"
+"normal Internet traffic."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:34
+msgid ""
+"However, many people don't need to worry about those \n"
+"situations, as they are outside their threat model.  It\n"
+"is, also, outside I2P's (formal) functional scope (if people want\n"
+"to build outproxy functionality on top of an anonymous\n"
+"communication layer, they can).  In fact, some I2P users\n"
+"currently take advantage of Tor to outproxy."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:48
+msgid "Comparison of Tor and I2P Terminology"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:49
+msgid ""
+"While Tor and I2P are similar in many ways, much of the terminology is "
+"different."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:54
+msgid "Cell"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:54
+#: i2p2www/pages/site/docs/protocol/i2np.html:96
+msgid "Message"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:55
+msgid "Client"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:55
+msgid "Router or Client"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:56
+msgid "Circuit"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:56
+msgid "Tunnel"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:57
+msgid "Directory"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:57
+msgid "NetDb"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:58
+msgid "Directory Server"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:58
+msgid "Floodfill Router"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:59
+msgid "Entry Guards"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:59
+msgid "Fast Peers"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:60
+msgid "Entry Node"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:60
+msgid "Inproxy"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:61
+msgid "Exit Node"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:61
+msgid "Outproxy"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:62
+msgid "Hidden Service"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:62
+msgid "Eepsite or Destination"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:63
+msgid "Hidden Service Descriptor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:63
+msgid "LeaseSet"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:64
+msgid "Introduction point"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:64
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:30
+#: i2p2www/pages/site/docs/tunnels/implementation.html:140
+msgid "Inbound Gateway"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:65
+msgid "Node"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:65
+#: i2p2www/pages/site/comparison/tor.html:67
+#: i2p2www/pages/site/comparison/tor.html:70
+#: i2p2www/pages/site/docs/spec/configuration.html:70
+msgid "Router"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:66
+msgid "Onion Proxy"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:66
+msgid "I2PTunnel Client (more or less)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:67
+msgid "Relay"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:68
+msgid "Rendezvous Point"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:68
+msgid "somewhat like Inbound Gateway + Outbound Endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:69
+msgid "Router Descriptor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:69
+msgid "RouterInfo"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:70
+msgid "Server"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:73
+msgid "Benefits of Tor over I2P"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:76
+msgid ""
+"Much bigger user base; much more visibility in the academic and hacker "
+"communities; benefits from\n"
+"formal studies of anonymity, resistance, and performance;\n"
+"has a non-anonymous, visible, university-based leader"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:82
+msgid "Has already solved some scaling issues I2P has yet to address"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:83
+msgid "Has significant funding"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:84
+msgid "Has more developers, including several that are funded"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:86
+msgid ""
+"More resistant to state-level blocking due to TLS transport layer and "
+"bridges\n"
+"(I2P has proposals for \"full restricted routes\" but these are not yet "
+"implemented)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:91
+msgid "Big enough that it has had to adapt to blocking and DOS attempts"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:92
+msgid "Designed and optimized for exit traffic, with a large number of exit nodes"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:94
+msgid ""
+"Better documentation, has formal papers and specifications,\n"
+"better website, many more translations"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:99
+msgid "More efficient with memory usage"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:100
+msgid "Tor client nodes have very low bandwidth overhead"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:102
+msgid ""
+"Centralized control reduces the complexity at each\n"
+"node and can efficiently address Sybil attacks"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:108
+msgid ""
+"A core of high capacity nodes provides higher\n"
+"throughput and lower latency"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:113
+msgid "C, not Java (ewww)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:116
+msgid "Benefits of I2P over Tor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:118
+msgid ""
+"Designed and optimized for hidden services, which are much faster than in"
+" Tor"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:119
+msgid "Fully distributed and self organizing"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:121
+msgid ""
+"Peers are selected by continuously profiling and ranking performance,\n"
+"rather than trusting claimed capacity"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:127
+msgid ""
+"Floodfill peers (\"directory servers\") are varying and untrusted,\n"
+"rather than hardcoded"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:132
+msgid "Small enough that it hasn't been blocked or DOSed much, or at all"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:133
+msgid "Peer-to-peer friendly"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:134
+msgid "Packet switched instead of circuit switched"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:137
+msgid ""
+"implicit transparent load balancing of messages \n"
+"across multiple peers, rather than a single path"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:143
+msgid ""
+"resilience vs. failures by running multiple \n"
+"tunnels in parallel, plus rotating tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:149
+msgid ""
+"scale each client's connections at O(1) instead \n"
+"of O(N) (Alice has e.g. 2 inbound tunnels that are \n"
+"used by all of the peers Alice is talking with, \n"
+"rather than a circuit for each)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:159
+msgid ""
+"Unidirectional tunnels instead of bidirectional\n"
+"circuits, doubling the number of nodes a peer has to\n"
+"compromise to get the same information."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:166
+msgid ""
+"Protection against detecting client activity, even\n"
+"when an attacker is participating in the tunnel, as\n"
+"tunnels are used for more than simply passing end \n"
+"to end messages (e.g. netDb, tunnel management, \n"
+"tunnel testing)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:175
+msgid ""
+"Tunnels in I2P are short lived, decreasing the number\n"
+"of samples that an attacker can use to mount an \n"
+"active attack with, unlike circuits in Tor, which are\n"
+"typically long lived."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:183
+msgid ""
+"I2P APIs are designed specifically for anonymity and\n"
+"security, while SOCKS is designed for functionality."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:188
+msgid "Essentially all peers participate in routing for others"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:190
+msgid ""
+"The bandwidth overhead of being a full peer is low, \n"
+"while in Tor, while client nodes don't require much\n"
+"bandwidth, they don't fully participate in the mixnet."
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:196
+msgid "Integrated automatic update mechanism"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:197
+msgid "Both TCP and UDP transports"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:198
+msgid "Java, not C (ewww)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:201
+msgid "Other potential benefits of I2P but not yet implemented"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:202
+msgid "...and may never be implemented, so don't count on them!"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:205
+msgid ""
+"Defense vs. message count analysis by garlic wrapping \n"
+"multiple messages"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:211
+msgid ""
+"Defense vs. long term intersection by adding delays \n"
+"at various hops (where the delays are not discernible\n"
+"by other hops)"
+msgstr ""
+
+#: i2p2www/pages/site/comparison/tor.html:218
+msgid ""
+"Various mixing strategies at the tunnel level (e.g.\n"
+"create a tunnel that will handle 500 messages / minute,\n"
+"where the endpoint will inject dummy messages if there\n"
+"are insufficient messages, etc)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:2 i2p2www/pages/site/docs/index.html:25
+msgid "Index to Technical Documentation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:3 i2p2www/pages/site/docs/ports.html:3
+msgid "May 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:6
+msgid "How does I2P work"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:8
+msgid "Following is an index to the technical documentation for I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:12
+msgid ""
+"This index is ordered from the highest to lowest layers.\n"
+"The higher layers are for \"clients\" or applications;\n"
+"the lower layers are inside the router itself.\n"
+"The interface between applications and the router is the I2CP (I2P "
+"Control Protocol) API."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:19
+#, python-format
+msgid ""
+"The I2P Project is committed to maintaining accurate, current "
+"documentation.\n"
+"If you find any inaccuracies in the documents linked below, please\n"
+"enter a ticket identifying the "
+"problem."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:27 i2p2www/pages/site/docs/naming.html:7
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:12
+#: i2p2www/pages/site/docs/api/streaming.html:6
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:6
+#: i2p2www/pages/site/docs/how/network-database.html:6
+#: i2p2www/pages/site/docs/how/peer-selection.html:6
+#: i2p2www/pages/site/docs/how/tech-intro.html:13
+#: i2p2www/pages/site/docs/how/tech-intro.html:97
+#: i2p2www/pages/site/docs/spec/blockfile.html:7
+#: i2p2www/pages/site/docs/spec/configuration.html:6
+#: i2p2www/pages/site/docs/spec/updates.html:6
+#: i2p2www/pages/site/docs/tunnels/implementation.html:67
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:6
+#: i2p2www/pages/site/misc/jbigi.html:6
+msgid "Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:29
+msgid "Technical Introduction"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:30
+msgid "A Less-Technical Introduction"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:31
+msgid "Threat model and analysis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:32
+msgid "Comparisons to other anonymous networks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:33
+msgid "Protocol stack chart"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:34
+#: i2p2www/pages/site/research/papers.html:2
+#: i2p2www/pages/site/research/papers.html:4
+msgid "Papers on I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:35
+#, python-format
+msgid ""
+"Invisible Internet Project (I2P) Project Overview"
+" August 28, 2003 (pdf)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:38
+msgid "Application-Layer Topics"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:40 i2p2www/pages/site/docs/naming.html:2
+msgid "Naming and Addressbook"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:41
+msgid "Plugins Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:42
+msgid "Plugin Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:43
+msgid "Router software updates"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:44
+#: i2p2www/pages/site/docs/applications/bittorrent.html:2
+msgid "Bittorrent over I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:45
+msgid "I2PControl Plugin API"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:46
+msgid "hostsdb.blockfile Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:47 i2p2www/pages/site/docs/index.html:184
+msgid "Configuration File Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:50
+msgid "Application Layer API and Protocols"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:51
+msgid ""
+"High-level, easy-to-use APIs for applications written in any language to "
+"send and receive data."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:53
+msgid "Application Development Overview and Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:71
+msgid "SAM Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:73
+msgid "SAMv2 Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:75
+msgid "SAMv3 Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:77
+msgid "BOB Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:80
+msgid "End-to-End Transport API and Protocols"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:81
+msgid ""
+"The end-to-end protocols used by clients for reliable and unreliable "
+"communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:83
+#: i2p2www/pages/site/docs/api/streaming.html:2
+msgid "Streaming Library"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:85
+msgid "Streaming Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:89
+msgid "Datagram Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:92
+msgid "Client-to-Router Interface API and Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:93
+msgid ""
+"The lowest-level API used for clients (applications) to send and receive "
+"traffic to a router.\n"
+"Traditionally used only by Java applications and higher-level APIs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:98
+msgid "I2CP - I2P Control Protocol / API overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:100
+msgid "I2CP Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:102
+msgid "I2CP API Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:104
+#: i2p2www/pages/site/docs/index.html:133
+msgid "Common data structures specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:106
+#: i2p2www/pages/site/docs/index.html:135
+msgid "Data Structures Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:109
+msgid "End-to-End Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:110
+msgid "How client messages are end-to-end encrypted by the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:112
+msgid "ElGamal/AES+SessionTag encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:113
+#: i2p2www/pages/site/docs/index.html:146
+msgid "ElGamal and AES cryptography details"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:116
+#: i2p2www/pages/site/docs/how/tech-intro.html:15
+#: i2p2www/pages/site/docs/how/tech-intro.html:329
+msgid "Network Database"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:117
+msgid ""
+"Distributed storage and retrieval of information about routers and "
+"clients."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:119
+msgid "Network database overview, details, and threat analysis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:120
+msgid "Cryptographic hashes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:121
+msgid "Cryptographic signatures"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:124
+msgid "Router Message Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:125
+msgid ""
+"I2P is a message-oriented router. The messages sent between routers are "
+"defined by the I2NP protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:127
+msgid "I2NP - I2P Network Protocol Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:129
+msgid "I2NP Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:131
+msgid "I2NP Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:139
+msgid ""
+"Selecting peers, requesting tunnels through those peers, and encrypting "
+"and routing messages through these tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:141
+msgid "Peer profiling and selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:142
+msgid "Tunnel routing overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:143
+msgid "Garlic routing and \"garlic\" terminology"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:144
+msgid "Tunnel building and encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:145
+msgid "ElGamal/AES"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:145
+msgid "for build request encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:147
+msgid "Tunnel building specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:148
+msgid "Low-level tunnel message specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:149
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:2
+msgid "Unidirectional Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:150
+#: i2p2www/pages/site/docs/how/peer-selection.html:299
+msgid "Peer Profiling and Selection in the I2P Anonymous Network"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:151
+msgid "2009 paper (pdf), not current but still generally accurate"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:154
+msgid "Transport Layer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:155
+msgid "The protocols for direct (point-to-point) router to router communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:159
+msgid "TCP-based transport overview and specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:161
+msgid "UDP-based transport overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:163
+msgid "SSU specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:165
+msgid "NTCP transport encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:167
+msgid "SSU transport encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:169
+msgid "Transport Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:171
+msgid "NTCP Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:173
+msgid "SSU Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:176
+msgid "Other Router Topics"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:178
+msgid "Native BigInteger Library"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:180
+msgid "Time synchronization and NTP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:187
+msgid "Developer's Guides and Resources"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:189
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:2
+msgid "New Developer's Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:191
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:2
+msgid "New Translator's Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:193
+#: i2p2www/pages/site/get-involved/guides/monotone.html:4
+msgid "Monotone Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:195
+msgid "Developer Guidelines"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:197
+msgid "Javadocs on the standard internet:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:198
+#: i2p2www/pages/site/docs/index.html:202
+#: i2p2www/pages/site/docs/index.html:203
+#: i2p2www/pages/site/docs/index.html:204
+#, python-format
+msgid "Server %(num)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:199
+#: i2p2www/pages/site/docs/index.html:208
+msgid ""
+"Note: always verify that javadocs are current by checking the release "
+"number."
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:201
+msgid "Javadocs inside I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:210
+msgid "Ports used by I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:212
+msgid "Automatic updates to development builds inside I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:214
+msgid "Updating the wrapper manually"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:216
+msgid "User forum"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:218
+msgid "Developer forum inside I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:222
+msgid "Viewmtn inside I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:224
+msgid "I2P Source exported to GitHub"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:226
+msgid "I2P Source Git Repo inside I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:228
+msgid "Source translation at Transifex"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:230
+msgid "Roadmap wiki"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:232
+msgid "Old roadmap"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:232
+#: i2p2www/pages/site/docs/index.html:234
+msgid "not current"
+msgstr ""
+
+#: i2p2www/pages/site/docs/index.html:234
+#: i2p2www/pages/site/get-involved/todo.html:2
+msgid "To Do List"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:3
+#: i2p2www/pages/site/docs/how/cryptography.html:3
+#: i2p2www/pages/site/docs/spec/common-structures.html:3
+msgid "March 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:6
+msgid "Naming in I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:9
+msgid ""
+"I2P ships with a generic naming library and a base implementation \n"
+"designed to work off a local name to destination mapping, as well as an\n"
+"add-on application called the addressbook. \n"
+"I2P also supports Base32 hostnames similar to "
+"Tor's .onion addresses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:16
+msgid ""
+"The addressbook is a web-of-trust\n"
+"driven secure, distributed, and human readable naming system, sacrificing"
+" only\n"
+"the call for all human readable names to be globally unique by mandating "
+"only\n"
+"local uniqueness.  While all messages in I2P are cryptographically "
+"addressed\n"
+"by their destination, different people can have local addressbook entries"
+" for\n"
+"\"Alice\" which refer to different destinations.  People can still "
+"discover new\n"
+"names by importing published addressbooks of peers specified in their web"
+" of trust,\n"
+"by adding in the entries provided through a third party, or (if some "
+"people organize\n"
+"a series of published addressbooks using a first come first serve "
+"registration\n"
+"system) people can choose to treat these addressbooks as name servers, "
+"emulating\n"
+"traditional DNS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:30
+#, python-format
+msgid ""
+"NOTE: For the reasoning behind the I2P naming system, common arguments "
+"against it\n"
+"and possible alternatives see the naming"
+" discussion\n"
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:37
+msgid "Naming System Components"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:39
+msgid ""
+"There is no central naming authority in I2P.\n"
+"All hostnames are local."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:44
+msgid ""
+"The naming system is quite simple and most of it is implemented\n"
+"in applications external to the router, but bundled with\n"
+"the I2P distribution.\n"
+"The components are:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:52
+msgid ""
+"The client application which does local lookups "
+"in hosts.txt\n"
+"and also takes care of the Base32 hostnames."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:56
+msgid ""
+"The HTTP proxy which asks the router for "
+"lookups and points\n"
+"the user to remote jump services to assist with failed lookups."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:60
+msgid ""
+"HTTP host-add forms which allow users to "
+"add hosts to their local hosts.txt"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:63
+msgid ""
+"HTTP jump services which provide their own"
+" lookups and redirection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:66
+msgid ""
+"The addressbook application which merges "
+"external\n"
+"host lists, retrieved via HTTP, with the local list."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:70
+msgid ""
+"The SusiDNS application which is a simple web "
+"front-end\n"
+"for addressbook configuration and viewing of the local host lists."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:77
+msgid "Naming Files and Lookups"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:79
+#, python-format
+msgid ""
+"All destinations in I2P are 516-byte (or longer) keys.\n"
+"(To be more precise, it is a 256-byte public key plus a 128-byte signing "
+"key\n"
+"plus a null certificate, which in Base64 representation is 516 bytes.\n"
+"Certificates are not "
+"used now,\n"
+"if they are, the keys will be longer.\n"
+"One possible use of certificates is for proof of work.)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:88
+msgid ""
+"If an application (i2ptunnel or the HTTP proxy) wishes to access\n"
+"a destination by name, the router does a very simple local lookup\n"
+"to resolve that name.\n"
+"The client application (technically, the client side of I2CP in the I2P "
+"API)\n"
+"does a linear search through three local files, in order, to\n"
+"look up host names and convert them to a 516-byte destination key:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:103
+msgid ""
+"The lookup is case-insensitive.\n"
+"The first match is used, and conflicts are not detected.\n"
+"There is no enforcement of naming rules in lookups."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:109
+#, python-format
+msgid ""
+"Lookups are cached for a few minutes.\n"
+"There is an experimental facility for real-time lookups (a la DNS) over "
+"the network within the router,\n"
+"although it is not enabled by default\n"
+"(see \"EepGet\" under Alternatives on the discussion"
+" page)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:116
+msgid "HTTP Proxy"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:118
+msgid ""
+"The HTTP proxy does a lookup via the router for all hostnames ending in "
+"'.i2p'.\n"
+"Otherwise, it forwards the request to a configured HTTP outproxy.\n"
+"Thus, in practice, all HTTP (eepsite) hostnames must end in the pseudo-"
+"Top Level Domain '.i2p'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:124
+msgid ""
+"If the router fails to resolve the hostname, the HTTP proxy returns\n"
+"an error page to the user with links to several \"jump\" services.\n"
+"See below for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:130
+#: i2p2www/pages/site/docs/spec/configuration.html:77
+msgid "Addressbook"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:131
+msgid "Incoming Subscriptions and Merging"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:133
+msgid ""
+"The addressbook application periodically\n"
+"retrieves other users' hosts.txt files and merges\n"
+"them with the local hosts.txt, after several checks.\n"
+"Naming conflicts are resolved on a first-come first-served\n"
+"basis."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:141
+msgid ""
+"Subscribing to another user's hosts.txt file involves\n"
+"giving them a certain amount of trust.\n"
+"You do not want them, for example, 'hijacking' a new site\n"
+"by quickly entering in their own key for a new site before\n"
+"passing the new host/key entry to you."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:149
+msgid ""
+"For this reason, the only subscription configured by\n"
+"default is http://www.i2p2.i2p/hosts.txt,\n"
+"which contains a copy of the hosts.txt included\n"
+"in the I2P release.\n"
+"Users must configure additional subscriptions in their\n"
+"local addressbook application (via subscriptions.txt or SusiDNS)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:158
+msgid "Some other public addressbook subscription links:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:165
+msgid ""
+"The operators of these services may have various policies for listing "
+"hosts.\n"
+"Presence on this list does not imply endorsement."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:170
+#: i2p2www/pages/site/docs/naming.html:182
+msgid "Naming Rules"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:171
+msgid ""
+"While there are hopefully not any technical limitations within I2P on "
+"host names,\n"
+"the addressbook enforces several restrictions on host names\n"
+"imported from subscriptions.\n"
+"It does this for basic typographical sanity and compatibility with "
+"browsers,\n"
+"and for security.\n"
+"The rules are essentially the same as those in RFC2396 Section 3.2.2.\n"
+"Any hostnames violating these rules may not be propagated\n"
+"to other routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:186
+msgid "Names are converted to lower case on import."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:190
+msgid ""
+"Names are checked for conflict with existing names in the existing "
+"userhosts.txt and hosts.txt\n"
+"(but not privatehosts.txt) after conversion to lower case."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:195
+msgid "Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:199
+msgid "Must not start with '.' or '-'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:203
+msgid "Must end with '.i2p'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:207
+msgid "67 characters maximum, including the '.i2p'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:211
+msgid "Must not contain '..'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:215
+msgid "Must not contain '.-' or '-.' (as of 0.6.1.33)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:219
+msgid "Must not contain '--' except in 'xn--' for IDN."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:223
+msgid "Base32 hostnames (*.b32.i2p) are not allowed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:227
+msgid ""
+"Certain hostnames reserved for project use are not allowed\n"
+"(proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, "
+"*.console.i2p, and others)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:232
+msgid "Keys are checked for base64 validity."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:236
+msgid ""
+"Keys are checked for conflict with existing keys in hosts.txt (but not "
+"privatehosts.txt)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:240
+msgid "Minimum key length 516 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:244
+msgid "Maximum key length 616 bytes (to account for certs up to 100 bytes)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:249
+msgid ""
+"Any name received via subscription that passes all the checks is added to"
+" the local hosts.txt."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:253
+msgid ""
+"Note that the '.' symbols in a host name are of no significance,\n"
+"and do not denote any actual naming or trust hierarchy.\n"
+"If the name 'host.i2p' already exists, there is nothing\n"
+"to prevent anybody from adding a name 'a.host.i2p' to their hosts.txt,\n"
+"and this name can be imported by others' addressbook.\n"
+"Methods to deny subdomains to non-domain 'owners' (certificates?),\n"
+"and the desirability and feasibility of these methods,\n"
+"are topics for future discussion."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:264
+msgid ""
+"International Domain Names (IDN) also work in i2p (using punycode 'xn--' "
+"form).\n"
+"To see IDN .i2p domain names rendered correctly in Firefox's location "
+"bar,\n"
+"add 'network.IDN.whitelist.i2p (boolean) = true' in about:config."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:270
+msgid ""
+"As the addressbook application does not use privatehosts.txt at all, in "
+"practice\n"
+"this file is the only place where it is appropriate to place private "
+"aliases or\n"
+"\"pet names\" for sites already in hosts.txt."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:276
+msgid "Outgoing Subscriptions"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:277
+msgid ""
+"Addressbook will publish the merged hosts.txt to a location\n"
+"(traditionally hosts.txt in the local eepsite's home directory) to be "
+"accessed by others\n"
+"for their subscriptions.\n"
+"This step is optional and is disabled by default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:285
+msgid ""
+"The addressbook application, together with eepget, saves the Etag and/or "
+"Last-Modified\n"
+"information returned by the web server of the subscription.\n"
+"This greatly reduces the bandwidth required, as the web server will\n"
+"return a '304 Not Modified' on the next fetch if nothing has changed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:292
+msgid ""
+"However the entire hosts.txt is downloaded if it has changed.\n"
+"See below for discussion on this issue."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:297
+msgid ""
+"Hosts serving a static hosts.txt or an equivalent CGI application\n"
+"are strongly encouraged to deliver\n"
+"a Content-Length header, and either an Etag or Last-Modified header.\n"
+"Also ensure that the server delivers a '304 Not Modified' when "
+"appropriate.\n"
+"This will dramatically reduce the network bandwidth, and\n"
+"reduce chances of corruption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:306
+msgid "Host Add Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:307
+msgid ""
+"A host add service is a simple CGI application that takes a hostname and "
+"a Base64 key as parameters\n"
+"and adds that to its local hosts.txt.\n"
+"If other routers subscribe to that hosts.txt, the new hostname/key\n"
+"will be propagated through the network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:314
+msgid ""
+"It is recommended that host add services impose, at a minimum, the "
+"restrictions imposed by the addressbook application listed above.\n"
+"Host add services may impose additional restrictions on hostnames and "
+"keys, for example:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:319
+msgid "A limit on number of 'subdomains'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:323
+msgid "Authorization for 'subdomains' through various methods."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:327
+msgid "Hashcash or signed certificates."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:331
+msgid "Editorial review of host names and/or content."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:335
+msgid "Categorization of hosts by content."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:339
+msgid "Reservation or rejection of certain host names."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:343
+msgid "Restrictions on the number of names registered in a given time period."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:347
+msgid "Delays between registration and publication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:351
+msgid "Requirement that the host be up for verification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:355
+msgid "Expiration and/or revocation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:359
+msgid "IDN spoof rejection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:364
+msgid "Jump Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:365
+msgid ""
+"A jump service is a simple CGI application that takes a hostname as a "
+"parameter\n"
+"and returns a 301 redirect to the proper URL with a "
+"?i2paddresshelper=key\n"
+"string appended.\n"
+"The HTTP proxy will interpret the appended string and\n"
+"use that key as the actual destination.\n"
+"In addition, the proxy will cache that key so the\n"
+"address helper is not necessary until restart."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:375
+msgid ""
+"Note that, like with subscriptions, using a jump service\n"
+"implies a certain amount of trust, as a jump service could maliciously\n"
+"redirect a user to an incorrect destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:381
+msgid ""
+"To provide the best service, a jump service should be subscribed to\n"
+"several hosts.txt providers so that its local host list is current."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:387
+msgid ""
+"SusiDNS is simply a web interface front-end to configuring addressbook "
+"subscriptions\n"
+"and accessing the four addressbook files.\n"
+"All the real work is done by the 'addressbook' application."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:393
+msgid ""
+"Currently, there is little enforcement of addressbook naming rules within"
+" SusiDNS,\n"
+"so a user may enter hostnames locally that would be rejected by\n"
+"the addressbook subscription rules."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:399
+msgid "Base32 Names"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:400
+msgid ""
+"I2P supports Base32 hostnames similar to Tor's .onion addresses.\n"
+"Base32 addresses are much shorter and easier to handle than the\n"
+"full 516-character Base64 Destinations or addresshelpers.\n"
+"Example: "
+"ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p"
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:407
+msgid ""
+"In Tor, the address is 16 characters (80 bits), or half of the SHA-1 "
+"hash.\n"
+"I2P uses 52 characters (256 bits) to represent the full SHA-256 hash.\n"
+"The form is {52 chars}.b32.i2p.\n"
+"Base32 is implemented in the naming service, which queries the\n"
+"router over I2CP to lookup the LeaseSet to get the full Destination.\n"
+"Base32 lookups will only be successful when the Destination is up and "
+"publishing\n"
+"a LeaseSet.\n"
+"Because resolution may require a network database lookup, it may take "
+"significantly\n"
+"longer than a local address book lookup."
+msgstr ""
+
+#: i2p2www/pages/site/docs/naming.html:419
+msgid ""
+"Base32 addresses can be used in most places where hostnames or full "
+"destinations\n"
+"are used, however there are some exceptions where they may fail if the\n"
+"name does not immediately resolve. I2PTunnel will fail, for example, if\n"
+"the name does not resolve to a destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:3
+#: i2p2www/pages/site/docs/how/network-database.html:3
+msgid "June 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:6
+msgid "I2P Plugins"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:8
+msgid "General Information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:9
+msgid ""
+"I2P includes a plugin architecture\n"
+"to support easy development and installation of additional software."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:14
+msgid ""
+"There are now plugins available that support distributed email, blogs, "
+"IRC\n"
+"clients, distributed file storage, wikis, and more."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:19
+msgid "Benefits to i2p users and app developers:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:24
+msgid "Easy distribution of applications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:28
+msgid ""
+"Allows innovation and use of additional libraries without worrying about\n"
+"increasing the size of i2pupdate.sud"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:33
+msgid ""
+"Support large or special-purpose applications that would never be bundled"
+"\n"
+"with the I2P installation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:38
+msgid "Cryptographically signed and verified applications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:42
+msgid "Automatic updates of applications, just like for the router"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:46
+msgid ""
+"Separate initial install and update packages, if desired, for smaller "
+"update downloads"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:50
+msgid ""
+"One-click installation of applications. No more asking users to modify\n"
+"wrapper.config or clients.config"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:55
+msgid "Isolate applications from the base $I2P installation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:59
+msgid ""
+"Automatic compatibility checking for I2P version, Java version, Jetty\n"
+"version, and previous installed application version"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:64
+msgid "Automatic link addition in console"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:68
+msgid ""
+"Automatic startup of application, including modifying classpath, without "
+"requiring a restart"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:72
+msgid "Automatic integration and startup of webapps into console Jetty instance"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:76
+#, python-format
+msgid ""
+"Facilitate creation of 'app stores' like the one at\n"
+"%(pluginsite)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:81
+msgid "One-click uninstall"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:85
+msgid "Language and theme packs for the console"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:89
+msgid "Bring detailed application information to the router console"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:93
+msgid "Non-java applications also supported"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:99
+msgid "Required I2P version"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:100
+msgid "0.7.12 or newer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:102
+msgid "Installation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:103
+msgid ""
+"To install and start a plugin, copy the .xpi2p install link "
+"to\n"
+"the form at the bottom of\n"
+"configclients.jsp"
+" in\n"
+"your router console and click the \"install plugin\" button.  After a"
+"\n"
+"plugin is installed and started, a link to the plugin will usually appear"
+" at\n"
+"the top of your summary bar."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:112
+msgid ""
+"To update a plugin to the latest version, just click the update button on"
+"\n"
+"configclients.jsp."
+"\n"
+"There is also a button to check if the plugin has a more recent version, "
+"as\n"
+"well as a button to check for updates for all plugins.  Plugins will be "
+"checked\n"
+"for updates automatically when updating to a new I2P release (not "
+"including dev\n"
+"builds)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:122
+msgid "Development"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:123
+#, python-format
+msgid ""
+"See the latest plugin specification and "
+"the\n"
+"plugin forum on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:128
+#, python-format
+msgid ""
+"See also the sources for plugins developed by various people.  Some "
+"plugins, such\n"
+"as snowman, were "
+"developed\n"
+"specifically as examples."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:134
+msgid ""
+"Developers wanted! Plugins are a great way to learn more about I2P"
+"\n"
+"or easily add some feature."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:139
+msgid "Getting Started"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:140
+#, python-format
+msgid ""
+"To create a plugin from an existing binary package you will need to get\n"
+"makeplugin.sh from the i2p.scripts branch in "
+"monotone."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:146
+msgid "Known Issues"
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:147
+msgid ""
+"Note that the router's plugin architecture does NOT currently\n"
+"provide any additional security isolation or sandboxing of plugins."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:153
+msgid ""
+"Updates of a plugin with included jars (not wars) won't be recognized if\n"
+"the plugin was already run, as it requires class loader trickery to flush"
+" the\n"
+"class cache; a full router restart is required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:159
+msgid "The stop button may be displayed even if there is nothing to stop."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:163
+msgid ""
+"Plugins running in a separate JVM create a logs/ directory "
+"in\n"
+"$CWD."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:168
+msgid ""
+"No initial keys are present, except for those of jrandom and zzz (using "
+"the\n"
+"same keys as for router update), so the first key seen for a signer is\n"
+"automatically accepted—there is no signing key authority."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:174
+msgid ""
+"When deleting a plugin, the directory is not always deleted, especially "
+"on\n"
+"Windows."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:179
+msgid ""
+"Installing a plugin requiring Java 1.6 on a Java 1.5 machine will result "
+"in a\n"
+"\"plugin is corrupt\" message if pack200 compression of the plugin file "
+"is used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:184
+msgid "Theme and translation plugins are untested."
+msgstr ""
+
+#: i2p2www/pages/site/docs/plugins.html:188
+msgid "Disabling autostart doesn't always work."
+msgstr ""
+
+#: i2p2www/pages/site/docs/ports.html:2
+msgid "Ports Used by I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/ports.html:7
+msgid ""
+"These are the ports used or reserved by I2P, including those for known "
+"plugins,\n"
+"common alternates,\n"
+"and some typical related applications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/ports.html:13
+#, python-format
+msgid ""
+"Note that many of these are not enabled by default.\n"
+"There is more information in the FAQ.\n"
+"See also the documentation for individual plugins.\n"
+"Plugin authors please add any ports you use here.\n"
+"For new plugins, we recommend using the next available port\n"
+"in the 766x range."
+msgstr ""
+
+#: i2p2www/pages/site/docs/ports.html:51
+msgid "recommended spot for new plugins/applications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:5
+msgid "BOB - Basic Open Bridge"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:7
+msgid "Technical differences from SAM (for the better?)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:9
+msgid ""
+"BOB has separate command and data channels. \n"
+"One, an application command channel socket to router to configure.\n"
+"Two, the application data sockets to/from router that carry only data.\n"
+"The command channel is only needed for making or setting the initial\n"
+"destination key, and to set the destination key to port bindings. \n"
+"All connections run in parallel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:18
+msgid ""
+"SAM has one connection that does everything, and you need to parse every "
+"packet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:22
+msgid ""
+"BOB does not hold keypair values, nor does the router.\n"
+"Your application holds the keypair values. \n"
+"This is to reduce any extra complexity in the router code, it also adds "
+"to\n"
+"your privacy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:29
+msgid "SAM router stores every keypair you ever make."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:33
+msgid "Those are the important differences."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:37
+msgid "KEYS = keypair public+private, these are BASE64"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:40
+msgid "KEY = public key, also BASE64"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:43
+msgid ""
+"ERROR as is implied returns the message \"ERROR "
+"\"+DESCRIPTION+\"\n"
+"\", where the DESCRIPTION is what went wrong."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:46
+msgid ""
+"OK returns \"OK\", and if data is to be "
+"returned, it is on the same line. OK means the command is "
+"finished."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:49
+msgid ""
+"DATA lines contain information that you requested. There may"
+" be multiple DATA lines per request."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:53
+msgid ""
+"NOTE: The help command is the ONLY command that has an exception "
+"to\n"
+"the rules... it can actually return nothing! This is intentional, since\n"
+"help is a HUMAN and not an APPLICATION command."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:59
+msgid ""
+"PLEASE NOTE:\n"
+"For CURRENT details on the commands PLEASE use the built-in help command."
+" \n"
+"Just telnet to localhost 2827 and type help and you can get full "
+"documentation on each command."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:65
+msgid ""
+"Commands never get obsoleted or changed, however new commands do get "
+"added from time to time."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:69
+msgid "Here are the commands we have as of this writing:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:74
+msgid "COMMAND"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:74
+msgid "OPERAND"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:74
+msgid "RETURNS"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:101
+msgid ""
+"Once set up, all TCP sockets can and will block as needed, and there is "
+"no need for any \n"
+"additional messages to/from the command channel. This allows the router "
+"to pace the\n"
+"stream without exploding with OOM like SAM does as it chokes on "
+"attempting to shove \n"
+"many streams in or out one socket -- that can't scale when you have alot "
+"of connections!"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:108
+msgid ""
+"What is also nice about this particular interface is that writing "
+"anything to interface \n"
+"to it, is much much easier than SAM. There is no other processing to do "
+"after the set up.\n"
+"It's configuration is so simple, that very simple tools, such as nc "
+"(netcat) can be used \n"
+"to point to some application. The value there is that one could schedule "
+"up and down times \n"
+"for an application, and not have to change the application to do that, or"
+" to even have \n"
+"to stop that application. Instead, you can literally \"unplug\" the "
+"destination, and \n"
+"\"plug it in\" again. As long as the same IP/port addresses and "
+"destination keys are used \n"
+"when bringing the bridge up, the normal TCP application won't care, and "
+"won't notice.\n"
+"It will simply be fooled -- the destinations are not reachable, and that "
+"nothing is coming in."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:120
+msgid ""
+"For the following example, we'll setup a very simple local loopback "
+"connection, \n"
+"with two destinations. Destination \"mouth\" will be the CHARGEN service "
+"from \n"
+"the INET superserver daemon. Destination \"ear\" will be a local port "
+"that you\n"
+"can telnet into, and watch the pretty ASCII test puke forth."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:128
+msgid "EXAMPLE SESSION DIALOGUE -- simple telnet 127.0.0.1 2827 works"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:129
+msgid "Application"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:130
+msgid "BOB's Command response."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:132
+#: i2p2www/pages/site/docs/api/bob.html:144
+#: i2p2www/pages/site/docs/api/bob.html:164
+#: i2p2www/pages/site/docs/api/bob.html:272
+#: i2p2www/pages/site/docs/api/bob.html:284
+#: i2p2www/pages/site/docs/api/bob.html:299
+msgid "FROM"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:132
+#: i2p2www/pages/site/docs/api/bob.html:144
+#: i2p2www/pages/site/docs/api/bob.html:164
+#: i2p2www/pages/site/docs/api/bob.html:272
+#: i2p2www/pages/site/docs/api/bob.html:284
+#: i2p2www/pages/site/docs/api/bob.html:299
+msgid "TO"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:132
+#: i2p2www/pages/site/docs/api/bob.html:144
+#: i2p2www/pages/site/docs/api/bob.html:164
+#: i2p2www/pages/site/docs/api/bob.html:272
+#: i2p2www/pages/site/docs/api/bob.html:284
+#: i2p2www/pages/site/docs/api/bob.html:299
+msgid "DIALOGUE"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:139
+msgid "MAKE NOTE OF THE ABOVE DESTINATION KEY, YOURS WILL BE DIFFERENT!"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:153
+msgid ""
+"At this point, there was no error, a destination with a nickname of "
+"\"mouth\" \n"
+"is set up. When you contact the destination provided, you actually "
+"connect \n"
+"to the CHARGEN service on 19/TCP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:159
+msgid "Now for the other half, so that we can actually contact this destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:179
+msgid ""
+"Now all we need to do is telnet into 127.0.0.1, port 37337,\n"
+"send the destination key or host address from addressbook we want to "
+"contact.\n"
+"In this case, we want to contact \"mouth\", all we do is paste in the\n"
+"key and it goes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:186
+msgid ""
+"NOTE: The \"quit\" command in the command channel does NOT "
+"disconnect the tunnels like SAM."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:203
+msgid "After a few virtual miles of this spew, press Control-]"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:215
+msgid "Here is what happened..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:223
+msgid "You can connect to EEPSITES too!"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:256
+msgid ""
+"Pretty cool isn't it? Try some other well known EEPSITES if you like, "
+"nonexistent ones, \n"
+"etc, to get a feel for what kind of output to expect in different "
+"situations. \n"
+"For the most part, it is suggested that you ignore any of the error "
+"messages. \n"
+"They would be meaningless to the application, and are only presented for "
+"human debugging."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:263
+msgid "Let's put down our destinations now that we are all done with them."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:267
+msgid "First, lets see what destination nicknames we have."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:279
+msgid "Alright, there they are. First, let's remove \"mouth\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:293
+msgid ""
+"Now to remove \"ear\", note that this is what happens when you type too "
+"fast,\n"
+"and shows you what typical ERROR messages looks like."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:312
+msgid ""
+"I won't bother to show an example of the receiver end of a bridge\n"
+"because it is very simple. There are two possible settings for it, and\n"
+"it is toggled with the \"quiet\" command."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:318
+msgid ""
+"The default is NOT quiet, and the first data to come into your\n"
+"listening socket is the destination that is making the contact. It is a\n"
+"single line consisting of the BASE64 address followed by a newline.\n"
+"Everything after that is for the application to actually consume."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:325
+msgid ""
+"In quiet mode, think of it as a regular Internet connection. No\n"
+"extra data comes in at all. It's just as if you are plain connected to\n"
+"the regular Internet. This mode allows a form of transparency much like\n"
+"is available on the router console tunnel settings pages, so that you\n"
+"can use BOB to point a destination at a web server, for example, and\n"
+"you would not have to modify the web server at all."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/bob.html:334
+msgid ""
+"The advantage with using BOB for this is as discussed\n"
+"previously. You could schedule random uptimes for the application,\n"
+"redirect to a different machine, etc. One use of this may be something\n"
+"like wanting to try to goof up router-to-destination upness guessing.\n"
+"You could stop and start the destination with a totally different\n"
+"process to make random up and down times on services. That way you\n"
+"would only be stopping the ability to contact such a service, and not\n"
+"have to bother shutting it down and restarting it. You could redirect\n"
+"and point to a different machine on your LAN while you do updates, or\n"
+"point to a set of backup machines depending on what is running, etc,\n"
+"etc. Only your imagination limits what you could do with BOB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:6
+msgid "Datagram Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:7
+#, python-format
+msgid ""
+"Datagrams build upon the base I2CP to provide "
+"authenticated\n"
+"and repliable messages in a standard format.  This lets applications "
+"reliably read\n"
+"the \"from\" address out of a datagram and know that the address really "
+"sent the\n"
+"message.  This is necessary for some applications since the base I2P "
+"message is\n"
+"completely raw - it has no \"from\" address (unlike IP packets).  In "
+"addition, the\n"
+"message and sender are authenticated by signing the payload."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:16
+#, python-format
+msgid ""
+"Datagrams, like streaming library packets,\n"
+"are an application-level construct.\n"
+"These protocols are independent of the low-level transports;\n"
+"the protocols are converted to I2NP messages by the router, and\n"
+"either protocol may be carried by either transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:25
+msgid "Application Guide"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:26
+#, python-format
+msgid ""
+"Applications written in Java may use the \n"
+"datagram API,\n"
+"while applications in other languages \n"
+"can use SAM's datagram support.\n"
+"There is also limited support in i2ptunnel in the SOCKS proxy,\n"
+"the 'streamr' tunnel types, and udpTunnel classes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:37
+msgid "Datagram Length"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:38
+msgid ""
+"The application designer should carefully consider the tradeoff of "
+"repliable vs. non-repliable\n"
+"datagrams. Also, the datagram size will affect reliability, due to tunnel"
+" fragmentation into 1KB\n"
+"tunnel messages. The more message fragments, the more likely that one of "
+"them will be dropped\n"
+"by an intermediate hop. Messages larger than a few KB are not recommended."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:45
+#, python-format
+msgid ""
+"Also note that the various overheads added by lower layers, in particular"
+" asymmetric\n"
+"ElGamal/AES, place a large burden on "
+"intermittent messages\n"
+"such as used by a Kademlia-over-UDP application. The implementations are "
+"currently tuned\n"
+"for frequent traffic using the streaming library. There are a high number"
+"\n"
+"of session tags delivered, and a short session tag lifetime, for example."
+"\n"
+"There are currently no configuration parameters available within I2CP to "
+"tune\n"
+"the ElGamal Session Tag parameters."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:55
+msgid "I2CP Protocol Number and Ports"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:56
+msgid ""
+"The standard I2CP protocol number for datagrams is 17. Applications may "
+"or may not choose to set the\n"
+"protocol in the I2CP header. It is not set by default.\n"
+"It must be set to demultiplex datagram and streaming traffic received on "
+"the same Destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:62
+#, python-format
+msgid ""
+"As datagrams are not connection-oriented, the application may require\n"
+"port numbers to correlate datagrams with particular peers or "
+"communications sessions,\n"
+"as is traditional with UDP over IP.\n"
+"Applications may add 'from' and 'to' ports to the I2CP (gzip) header as "
+"described in\n"
+"the I2CP page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:70
+msgid ""
+"There is no method within the datagram API to specify whether it is non-"
+"repliable (raw)\n"
+"or repliable. The application should be designed to expect the "
+"appropriate type.\n"
+"The I2CP protocol number or port could also be used by the application to"
+"\n"
+"indicate datagram type."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:77
+#, python-format
+msgid ""
+"The protocols and ports may be set in I2CP's\n"
+"I2PSession API,\n"
+"as implemented in\n"
+"I2PSessionMuxedImpl."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:85
+#: i2p2www/pages/site/docs/api/streaming.html:325
+msgid "Data Integrity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:86
+#, python-format
+msgid ""
+"Data integrity is assured by the gzip CRC-32 checksum implemented in\n"
+"the I2CP layer.\n"
+"There is no checksum field in the datagram protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:92
+#: i2p2www/pages/site/docs/api/streaming.html:333
+msgid "Packet Encapsulation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:93
+#, python-format
+msgid ""
+"Each datagram is sent through I2P as a single message (or as an "
+"individual clove in a\n"
+"Garlic Message).\n"
+"Message encapsulation is implemented in the underlying\n"
+"I2CP,\n"
+"I2NP, and\n"
+"tunnel message layers.\n"
+"There is no packet delimiter mechanism or length field in the datagram "
+"protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:106
+#: i2p2www/pages/site/docs/spec/datagrams.html:10
+#: i2p2www/pages/site/docs/transport/ssu.html:547
+msgid "Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/datagrams.html:108
+msgid "See the Datagrams Specification page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:4
+msgid "I2PControl - Remote Control Service"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:5
+#, python-format
+msgid ""
+"I2P enables a JSONRPC2 interface via the plugin I2PControl.\n"
+"The aim of the interface is to provide simple way to interface with a "
+"running I2P node. A client, itoopie, has been developed in parallel.\n"
+"The JSONRPC2 implementation for the client as well as the plugin is "
+"provided by the java libraries JSON-RPC 2.0.  \n"
+"A list of implementations of JSON-RPC for various languages can be found "
+"at the JSON-RPC "
+"wiki."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:12
+msgid "I2PControl is by default listening on localhost:7650"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:14
+msgid "API, version 1."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:15
+msgid "Parameters are only provided in a named way (maps)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:19
+msgid "JSON-RPC 2 format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:21
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:27
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:40
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:50
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:59
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:69
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:84
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:137
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:154
+msgid "Request:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:23
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:32
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:44
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:54
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:64
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:75
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:101
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:145
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:169
+msgid "Response:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:26
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:28
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:29
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:33
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:34
+#: i2p2www/pages/site/docs/protocol/i2cp.html:99
+#: i2p2www/pages/site/docs/protocol/i2cp.html:442
+#: i2p2www/pages/site/docs/spec/common-structures.html:16
+#: i2p2www/pages/site/docs/spec/common-structures.html:26
+#: i2p2www/pages/site/docs/spec/common-structures.html:37
+#: i2p2www/pages/site/docs/spec/common-structures.html:49
+#: i2p2www/pages/site/docs/spec/common-structures.html:64
+#: i2p2www/pages/site/docs/spec/common-structures.html:77
+#: i2p2www/pages/site/docs/spec/common-structures.html:90
+#: i2p2www/pages/site/docs/spec/common-structures.html:102
+#: i2p2www/pages/site/docs/spec/common-structures.html:114
+#: i2p2www/pages/site/docs/spec/common-structures.html:126
+#: i2p2www/pages/site/docs/spec/common-structures.html:138
+#: i2p2www/pages/site/docs/spec/common-structures.html:150
+#: i2p2www/pages/site/docs/spec/common-structures.html:162
+#: i2p2www/pages/site/docs/spec/common-structures.html:174
+#: i2p2www/pages/site/docs/spec/common-structures.html:229
+#: i2p2www/pages/site/docs/spec/common-structures.html:298
+#: i2p2www/pages/site/docs/spec/common-structures.html:349
+#: i2p2www/pages/site/docs/spec/common-structures.html:395
+#: i2p2www/pages/site/docs/spec/common-structures.html:442
+#: i2p2www/pages/site/docs/spec/common-structures.html:568
+#: i2p2www/pages/site/docs/spec/common-structures.html:623
+msgid "Description"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:30
+msgid ""
+"Token used for authenticating every request (excluding the 'Authenticate'"
+" RPC method)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:38
+msgid "Implemented methods"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:39
+msgid ""
+"Creates and returns an authentication token used for further "
+"communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:41
+msgid "The version of the I2PControl API used by the client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:42
+msgid "The password used for authenticating against the remote server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:45
+msgid "The primary I2PControl API version implemented by the server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:46
+msgid "The token used for further communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:49
+msgid "Echoes the value of the echo key, used for debugging and testing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:51
+msgid "Value will be returned in response."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:52
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:62
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:73
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:99
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:143
+msgid ""
+"Token used for authenticating the client. Is provided by the server via "
+"the 'Authenticate' RPC method."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:55
+msgid "Value of the key 'echo' in the request."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:58
+msgid ""
+"Fetches rateStat from router statManager. Creates stat if not already "
+"created."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:60
+#, python-format
+msgid ""
+"Determines which rateStat to fetch, see ratestats."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:61
+msgid "Determines which period a stat is fetched for. Measured in ms."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:65
+msgid "Returns the average value for the reuested rateStat and period."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:68
+msgid "Manages I2PControl. Ports, passwords and the like."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:70
+msgid ""
+"Sets a new listen address for I2PControl (only 127.0.0.1 and 0.0.0.0 are "
+"implemented in I2PControl currently)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:71
+msgid ""
+"Sets a new password for I2PControl, all Authentication tokens will be "
+"revoked."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:72
+msgid "Switches which port I2PControl will listen for connections on."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:76
+msgid "Returned if address was changed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:77
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:78
+msgid "Returned if setting was changed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:79
+msgid "Returns true if any changes were made."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:80
+msgid "Returns true if any changes requiring a restart to take effect were made."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:83
+msgid "Fetches basic information about the I2P router. Uptime, version etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:102
+msgid "What the status of the router is."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:103
+msgid "What the uptime of the router is in ms."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:104
+msgid "What version of I2P the router is running."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:105
+msgid "The 1 second average inbound bandwidth in Bps."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:106
+msgid "The 15 second average inbound bandwidth in Bps."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:107
+msgid "The 1 second average outbound bandwidth in Bps."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:108
+msgid "The 15 second average outbound bandwidth in Bps."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:109
+msgid "What the current network status is. According to the below enum:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:128
+msgid "How many tunnels on the I2P net are we participating in."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:129
+msgid "How many peers have we communicated with recently."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:130
+msgid "How many peers are considered 'fast'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:131
+msgid "How many peers are considered 'high capacity'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:132
+msgid "Is the router reseeding hosts to its NetDB?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:133
+msgid "How many peers are known to us (listed in our NetDB)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:136
+msgid "Manages I2P router restart/shutdown."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:138
+msgid ""
+"Initiates a router reseed, fetching peers into our NetDB from a remote "
+"host."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:139
+msgid "Restarts the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:140
+msgid ""
+"Restarts the router gracefully (waits for participating tunnels to "
+"expire)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:141
+msgid "Shuts down the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:142
+msgid ""
+"Shuts down the router gracefully (waits for participating tunnels to "
+"expire)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:146
+msgid "If requested, verifies that a reseed has been initiated."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:147
+msgid "If requested, verifies that a restart has been initiated."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:148
+msgid "If requested, verifies that a graceful restart has been initiated."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:149
+msgid "If requested, verifies that a shutdown has been initiated"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:150
+msgid "If requested, verifies that a graceful shutdown has been initiated"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:153
+msgid "Fetches or sets various network related settings. Ports, addresses etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:155
+msgid ""
+"What port is used for the TCP transport. If null is submitted, current "
+"setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:156
+msgid ""
+"What hostname is used for the TCP transport. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:157
+msgid ""
+"Use automatically detected ip for TCP transport. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:158
+msgid ""
+"What port is used for the UDP transport. If null is submitted, current "
+"setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:159
+msgid ""
+"What hostname is used for the UDP transport. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:160
+msgid ""
+"Which methods should be used for detecting the ip address of the UDP "
+"transport. If null is submitted, current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:161
+msgid "What ip has been detected by the UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:162
+msgid "Is UPnP enabled. If null is submitted, current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:163
+msgid ""
+"How many percent of bandwidth is usable for participating tunnels. If "
+"null is submitted, current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:164
+msgid ""
+"How many KB/s of inbound bandwidth is allowed. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:165
+msgid ""
+"How many KB/s of outbound bandwidth is allowed. If null is submitted, "
+"current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:166
+msgid ""
+"Is laptop mode enabled (change router identity and UDP port when IP "
+"changes ). If null is submitted, current setting will be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:167
+msgid ""
+"Token used for authenticating the client. Is provided by the server via "
+"the 'Authenticate' RPC method. If null is submitted, current setting will"
+" be returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:170
+msgid "If requested, returns the port used for the TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:171
+msgid "If requested, returns the hostname used for the TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:172
+msgid ""
+"If requested, returns the method used for automatically detecting ip for "
+"the TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:173
+msgid "If requested, returns the port used for the UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:174
+msgid "If requested, returns the hostname used for the UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:175
+msgid ""
+"If requested, returns methods used for detecting the ip address of the "
+"UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:176
+msgid "If requested, returns what ip has been detected by the UDP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:177
+msgid "If requested, returns the UPNP setting."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:178
+msgid ""
+"If requested, returns how many percent of bandwidth is usable for "
+"participating tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:179
+msgid "If requested, returns how many KB/s of inbound bandwidth is allowed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:180
+msgid "If requested, returns how many KB/s of outbound bandwidth is allowed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:181
+msgid "If requested, returns the laptop mode."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:182
+msgid "Have the provided settings been saved."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:183
+msgid "Is a restart needed for the new settings to be used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:186
+msgid "denotes an optional value."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:187
+msgid "denotes a possibly occuring return value"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:189
+msgid "Error codes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:190
+msgid "Standard JSON-RPC2 error codes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:191
+msgid "JSON parse error."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:192
+msgid "Invalid request."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:193
+msgid "Method not found."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:194
+msgid "Internal error."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:196
+msgid "I2PControl specific error codes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:197
+msgid "Invalid password provided."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:198
+msgid "No authentication token presented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:199
+msgid "Authentication token doesn't exist."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:200
+msgid "The provided authentication token was expired and will be removed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:201
+msgid ""
+"The version of the I2PControl API used wasn't specified, but is required "
+"to be specified."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2pcontrol.html:202
+msgid ""
+"The version of the I2PControl API specified is not supported by "
+"I2PControl."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:13
+#, python-format
+msgid ""
+"I2PTunnel is a tool for interfacing with and providing services on I2P.\n"
+"Destination of an I2PTunnel can be defined using a hostname,\n"
+"Base32, or a full 516-byte destination "
+"key.\n"
+"An established I2PTunnel will be available on your client machine as "
+"localhost:port.\n"
+"If you wish to provide a service on I2P network, you simply create "
+"I2PTunnel to the\n"
+"appropriate ip_address:port. A corresponding 516-byte destination key "
+"will be generated\n"
+"for the service and it will become avaliable throughout I2P.\n"
+"A web interface for I2PTunnel management is avaliable on\n"
+"localhost:7657/i2ptunnel/."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:25
+msgid "Default Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:26
+msgid "Server tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:28
+msgid ""
+"I2P Webserver - A tunnel pointed to a Jetty webserver run\n"
+"on localhost:7658 for convenient "
+"and quick hosting on I2P.\n"
+"
            The document root is:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:36
+msgid "Client tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:38
+msgid ""
+"A HTTP proxy used for browsing I2P and the regular internet anonymously "
+"through I2P. \n"
+"Browsing internet through I2P uses a random proxy specified by the "
+"\"Outproxies:\" option."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:42
+msgid "An IRC tunnel to the default anonymous IRC network, Irc2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:43
+#, python-format
+msgid ""
+"The anonymous monotone"
+"\n"
+"sourcecode repository for I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:47
+#, python-format
+msgid ""
+"A SMTP service provided by postman at %(postman)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:50
+#, python-format
+msgid ""
+"The accompanying POP sevice of postman at %(postman)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:55
+msgid "Client Modes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:56
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:138
+msgid "Standard"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:57
+msgid ""
+"Opens a local TCP port that connects to a service (like HTTP, FTP or "
+"SMTP) on a destination inside of I2P.\n"
+"The tunnel is directed to a random host from the comma seperated (\", \")"
+" list of destinations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:63
+msgid ""
+"A HTTP-client tunnel. The tunnel connects to the destination specified by"
+" the URL\n"
+"in a HTTP request. Supports proxying onto internet if an outproxy is "
+"provided. Strips HTTP connections of the following headers:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:68
+msgid ""
+"Accept, Accept-Charset, Accept-Encoding, Accept-Language\n"
+" and Accept-Ranges as they vary greatly between browsers and can be "
+"used as an identifier."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:76
+msgid ""
+"HTTP client/server tunnels are via I2Ptunnel force-enabling compression "
+"via the following http headers:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:83
+msgid ""
+"Depending on if the tunnel is using an outproxy or not it will append the"
+" following User-Agent:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:87
+msgid "Outproxy:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:88
+msgid "Internal I2P use:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:93
+msgid ""
+"Creates a connection to a random IRC server specified by the comma "
+"seprated (\", \") \n"
+"list of destinations. Only a whitelisted subset of IRC commands are "
+"allowed due to anonymity concerns."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:97
+msgid "Whitelist:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:112
+msgid "Enables using the I2P router as a SOCKS proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:117
+msgid ""
+"Enables using the I2P router as a SOCKS proxy with the command whitelist "
+"specified by\n"
+"IRC client mode."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:123
+msgid ""
+"Creates a HTTP tunnel and uses the HTTP request method \"CONNECT\" \n"
+"to build a TCP tunnel that usually is used for SSL and HTTPS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:129
+msgid ""
+"Creates a UDP-server attached to a Streamr client I2PTunnel. The streamr "
+"client tunnel will \n"
+"subscribe to a streamr server tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:137
+msgid "Server Modes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:139
+msgid "Creates a destination to a local ip:port with an open TCP port."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:144
+msgid ""
+"Creates a destination to a local HTTP server ip:port. Supports gzip for "
+"requests with \n"
+"Accept-encoding: x-i2p-gzip, replies with Content-encoding: x-i2p-gzip in"
+" such a request."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:150
+msgid ""
+"Functions as both a I2PTunnel HTTP Server, and a I2PTunnel HTTP client "
+"with no outproxying\n"
+"capabilities. An example application would be a web application that does"
+" client-type\n"
+"requests, or loopback-testing an eepsite as a diagnostic tool."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:157
+msgid ""
+"Creates a destination that filters the reqistration sequence of a client "
+"and passes \n"
+"the clients destination key as a hostname to the IRC-server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/i2ptunnel.html:163
+msgid ""
+"A UDP-client that connects to a media server is created. The UDP-Client "
+"is coupled with a Streamr server I2PTunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:2
+#: i2p2www/pages/site/docs/api/ministreaming.html:17
+msgid "Ministreaming Library"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:5
+msgid "Note"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:7
+#, python-format
+msgid ""
+"The ministreaming library has been enhanced and extended by the\n"
+"\"full\" streaming library.\n"
+"Ministreaming is deprecated and is incompatible with today's "
+"applications.\n"
+"The following documentation is old.\n"
+"Also note that streaming extends ministreaming in the same Java package "
+"(net.i2p.client.streaming),\n"
+"so the current API documentation contains both.\n"
+"Obsolete ministreaming classes and methods are clearly marked as "
+"deprecated in the Javadocs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:19
+#, python-format
+msgid ""
+"\n"
+"The ministreaming library is a layer on top of the core \n"
+"I2CP that allows reliable, in order, and "
+"authenticated streams\n"
+"of messages to operate across an unreliable, unordered, and "
+"unauthenticated \n"
+"message layer.  Just like the TCP to IP relationship, this streaming \n"
+"functionality has a whole series of tradeoffs and optimizations "
+"available, but\n"
+"rather than embed that functionality into the base I2P code, it has been "
+"factored\n"
+"off into its own library both to keep the TCP-esque complexities separate"
+" and to\n"
+"allow alternative optimized implementations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:30
+#, python-format
+msgid ""
+"The ministreaming library was written by mihi as a part of his \n"
+"I2PTunnel application and then factored out"
+" and released\n"
+"under the BSD license.  It is called the \"mini\"streaming library "
+"because it makes\n"
+"some simplifications in the implementation, while a more robust streaming"
+" library\n"
+"could be further optimized for operation over I2P.  The two main issues "
+"with \n"
+"the ministreaming library are its use of the traditional TCP two phase \n"
+"establishment protocol and the current fixed window size of 1.  The "
+"establishment\n"
+"issue is minor for long lived streams, but for short ones, such as quick "
+"HTTP\n"
+"requests, the impact can be significant.  As "
+"for the window\n"
+"size, the ministreaming library doesn't maintain any ID or ordering "
+"within the \n"
+"messages sent (or include any application level ACK or SACK), so it must "
+"wait \n"
+"on average twice the time it takes to send a message before sending "
+"another."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/ministreaming.html:45
+#, python-format
+msgid ""
+"Even with those issues, the ministreaming library performs quite well in "
+"many\n"
+"situations, and its API\n"
+"is both quite simple and capable of remaining unchanged as different "
+"streaming\n"
+"implementations are introduced.  The library is deployed in its own \n"
+"ministreaming.jar.\n"
+"Developers in Java who would like to use it can\n"
+"access the API directly, while developers in other languages can use it "
+"through\n"
+"SAM's streaming support."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:4
+msgid "SOCKS and SOCKS proxies"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:5
+msgid ""
+"\n"
+"The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are "
+"supported.\n"
+"Enable SOCKS by creating a SOCKS client tunnel in i2ptunnel.\n"
+"Both shared-clients and non-shared are supported.\n"
+"There is no SOCKS outproxy so it is of limited use."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:12
+#, python-format
+msgid ""
+"\n"
+"As it says on the FAQ:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:15
+msgid ""
+"Many applications leak sensitive\n"
+"information that could identify you on the Internet. I2P only filters\n"
+"connection data, but if the program you intend to run sends this\n"
+"information as content, I2P has no way to protect your anonymity.  For\n"
+"example, some mail applications will send the IP address of the machine\n"
+"they are running on to a mail server. There is no way for I2P to filter\n"
+"this, thus using I2P to 'socksify' existing applications is possible, but"
+"\n"
+"extremely dangerous."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:25
+msgid "And quoting from a 2005 email:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:28
+msgid ""
+"... there is a reason why human and\n"
+"others have both built and abandoned the SOCKS proxies.  Forwarding\n"
+"arbitrary traffic is just plain unsafe, and it behooves us as\n"
+"developers of anonymity and security software to have the safety of\n"
+"our end users foremost in our minds."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:36
+msgid ""
+"Hoping that we can simply strap an arbitrary client on top of I2P\n"
+"without auditing both its behavior and its exposed protocols for\n"
+"security and anonymity is naive.  Pretty much *every* application\n"
+"and protocol violates anonymity, unless it was designed for it\n"
+"specifically, and even then, most of those do too.  That's the\n"
+"reality.  End users are better served with systems designed for\n"
+"anonymity and security.  Modifying existing systems to work in\n"
+"anonymous environments is no small feat, orders of magnitude more\n"
+"work that simply using the existing I2P APIs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:48
+msgid ""
+"The SOCKS proxy\n"
+"supports standard addressbook names, but not Base64 destinations.\n"
+"Base32 hashes should work as of release 0.7.\n"
+"It supports outgoing connections only, i.e. an I2PTunnel Client.\n"
+"UDP support is stubbed out but not working yet.\n"
+"Outproxy selection by port number is stubbed out."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:57
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:281
+msgid "See Also"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:59
+#, python-format
+msgid ""
+"The notes for Meeting 81 and\n"
+"Meeting 82 in March 2004."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:69
+msgid "If You Do Get Something Working"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/socks.html:70
+msgid ""
+"Please let us know. And please provide substantial warnings about the\n"
+"risks of socks proxies."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:3
+#: i2p2www/pages/site/docs/protocol/i2cp.html:3
+#: i2p2www/pages/site/docs/spec/streaming.html:3
+msgid "November 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:8
+#, python-format
+msgid ""
+"The streaming library is technically part of the \"application\" layer,\n"
+"as it is not a core router function.\n"
+"In practice, however, it provides a vital function for almost all\n"
+"existing I2P applications, by providing a TCP-like\n"
+"streams over I2P, and allowing existing apps to be easily ported to I2P.\n"
+"The other end-to-end transport library for client communication is the\n"
+"datagram library."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:18
+#, python-format
+msgid ""
+"The streaming library is a layer on top of the core \n"
+"I2CP API that allows reliable, in-order, and "
+"authenticated streams\n"
+"of messages to operate across an unreliable, unordered, and "
+"unauthenticated \n"
+"message layer.  Just like the TCP to IP relationship, this streaming \n"
+"functionality has a whole series of tradeoffs and optimizations "
+"available, but\n"
+"rather than embed that functionality into the base I2P code, it has been "
+"factored\n"
+"off into its own library both to keep the TCP-esque complexities separate"
+" and to\n"
+"allow alternative optimized implementations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:29
+msgid ""
+"In consideration of the relatively high cost of messages, \n"
+"the streaming library's protocol for scheduling and delivering those "
+"messages has been optimized to\n"
+"allow individual messages passed to contain as much information as is "
+"available.\n"
+"For instance, a small HTTP transaction proxied through the streaming "
+"library can\n"
+"be completed in a single round trip - the first messages bundle a SYN, "
+"FIN, and\n"
+"the small HTTP request payload, and the reply bundles the SYN,\n"
+"FIN, ACK, and the HTTP response payload.  While an additional\n"
+"ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has "
+"been\n"
+"received, the local HTTP proxy can often deliver the full response to the"
+" browser \n"
+"immediately."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:42
+msgid ""
+"The streaming library bears much resemblance to an \n"
+"abstraction of TCP, with its sliding windows, congestion control "
+"algorithms\n"
+"(both slow start and congestion avoidance), and general packet behavior "
+"(ACK,\n"
+"SYN, FIN, RST, rto calculation, etc)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:49
+msgid ""
+"The streaming library is\n"
+"a robust library\n"
+"which is optimized for operation over I2P.\n"
+"It has a one-phase setup, and\n"
+"it contains a full windowing implementation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:60
+#, python-format
+msgid ""
+"The streaming library API provides a standard socket paradigm to Java "
+"applications.\n"
+"The lower-level I2CP API is completely hidden, "
+"except that\n"
+"applications may pass I2CP parameters "
+"through the\n"
+"streaming library, to be interpreted by I2CP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:67
+#, python-format
+msgid ""
+"The standard interface to the streaming lib is for the application to use"
+" the\n"
+"I2PSocketManagerFactory to create an\n"
+"I2PSocketManager. The application then asks "
+"the\n"
+"socket manager for an I2PSession, which will "
+"cause\n"
+"a connection to the router via I2CP. The "
+"application\n"
+"can then setup connections with an I2PSocket "
+"or\n"
+"receive connections with an I2PServerSocket."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:82
+#, python-format
+msgid "Here are the full streaming library Javadocs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:86
+msgid "For a good example of usage, see the i2psnark code."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:91
+msgid "Options and Defaults"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:92
+#, python-format
+msgid ""
+"The options and current default values are listed below.\n"
+"Options are case-sensitive and may be set for the whole router, for a "
+"particular client, or for an individual socket on a\n"
+"per-connection basis.\n"
+"Many values are tuned for HTTP performance over typical I2P conditions. "
+"Other applications such\n"
+"as peer-to-peer services are strongly encouraged to\n"
+"modify as necessary, by setting the options and passing them via the call"
+" to\n"
+"I2PSocketManagerFactory.createManager(_i2cpHost,"
+" _i2cpPort, opts).\n"
+"Time values are in ms."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:103
+#, python-format
+msgid ""
+"Note that higher-layer APIs, such as SAM,\n"
+"BOB, and I2PTunnel,"
+"\n"
+"may override these defaults with their own defaults.\n"
+"Also note that many options only apply to servers listening for incoming "
+"connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:110
+msgid ""
+"As of release 0.9.1, most, but not all, options may be changed on an "
+"active socket manager or session.\n"
+"See the javadocs for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:117
+#: i2p2www/pages/site/docs/protocol/i2cp.html:94
+#: i2p2www/pages/site/docs/protocol/i2cp.html:437
+msgid "Option"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:117
+#: i2p2www/pages/site/docs/protocol/i2cp.html:98
+#: i2p2www/pages/site/docs/protocol/i2cp.html:441
+msgid "Default"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:117
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:267
+#: i2p2www/pages/site/docs/how/peer-selection.html:282
+#: i2p2www/pages/site/docs/spec/common-structures.html:58
+#: i2p2www/pages/site/docs/spec/common-structures.html:205
+#: i2p2www/pages/site/docs/spec/common-structures.html:261
+#: i2p2www/pages/site/docs/spec/common-structures.html:341
+#: i2p2www/pages/site/docs/spec/common-structures.html:431
+#: i2p2www/pages/site/docs/spec/common-structures.html:541
+#: i2p2www/pages/site/docs/spec/common-structures.html:608
+#: i2p2www/pages/site/docs/spec/common-structures.html:709
+#: i2p2www/pages/site/docs/spec/datagrams.html:31
+#: i2p2www/pages/site/docs/spec/datagrams.html:90
+msgid "Notes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:119
+msgid ""
+"Comma- or space-separated list of Base64 peer Hashes used for either "
+"access list or blacklist."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:121
+#: i2p2www/pages/site/docs/api/streaming.html:127
+#: i2p2www/pages/site/docs/api/streaming.html:133
+#: i2p2www/pages/site/docs/api/streaming.html:147
+#: i2p2www/pages/site/docs/api/streaming.html:176
+#: i2p2www/pages/site/docs/api/streaming.html:184
+#: i2p2www/pages/site/docs/api/streaming.html:214
+#: i2p2www/pages/site/docs/api/streaming.html:220
+#: i2p2www/pages/site/docs/api/streaming.html:226
+#: i2p2www/pages/site/docs/api/streaming.html:240
+#: i2p2www/pages/site/docs/api/streaming.html:247
+#: i2p2www/pages/site/docs/api/streaming.html:254
+#, python-format
+msgid "As of release %(release)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:125
+msgid "Use the access list as a whitelist for incoming connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:131
+msgid "Use the access list as a blacklist for incoming connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:137
+msgid "Whether to respond to incoming pings"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:141
+msgid ""
+"Comma- or space-separated list of Base64 peer Hashes to be\n"
+"blacklisted for incoming connections to ALL destinations in the context.\n"
+"This option must be set in the context properties, NOT in the "
+"createManager() options argument.\n"
+"Note that setting this in the router context will not affect clients "
+"outside the\n"
+"router in a separate JVM and context."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:151
+msgid ""
+"How much transmit data (in bytes) will be accepted that hasn't been "
+"written out yet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:155
+msgid ""
+"When we're in congestion avoidance, we grow the window size at the rate\n"
+"of 1/(windowSize*factor).  In standard TCP, window sizes are"
+" in bytes,\n"
+"while in I2P, window sizes are in messages.\n"
+"A higher number means slower growth."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:162
+msgid ""
+"How long to wait after instantiating a new con \n"
+"before actually attempting to connect.  If this is\n"
+"<= 0, connect immediately with no initial data.  If greater than 0, "
+"wait\n"
+"until the output stream is flushed, the buffer fills, \n"
+"or that many milliseconds pass, and include any initial data with the SYN."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:170
+msgid ""
+"How long to block on connect, in milliseconds. Negative means "
+"indefinitely. Default is 5 minutes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:174
+msgid ""
+"Whether to disable warnings in the logs when an incoming connection is "
+"rejected due to connection limits."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:180
+msgid ""
+"Whether to listen only for the streaming protocol.\n"
+"Setting to true will prohibit communication with Destinations earlier "
+"than release 0.7.1\n"
+"(released March 2009). Set to true if running multiple protocols on this "
+"Destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:188
+msgid ""
+"(0=noop, 1=disconnect)\n"
+"What to do on an inactivity timeout - do nothing, disconnect, or send a "
+"duplicate ack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:196
+msgid ""
+"The initial value of the resend delay field in the packet header, times "
+"1000.\n"
+"Not fully implemented; see below."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:201
+#: i2p2www/pages/site/docs/api/streaming.html:203
+msgid "if no sharing data available"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:203
+msgid ""
+"In standard TCP, window sizes are in bytes, while in I2P, window sizes "
+"are in messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:207
+msgid ""
+"(0 or negative value means unlimited)\n"
+"This is a total limit for incoming and outgoing combined."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:212
+msgid "Incoming connection limit (per peer; 0 means disabled)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:218
+#: i2p2www/pages/site/docs/api/streaming.html:224
+msgid "(per peer; 0 means disabled)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:230
+msgid "The MTU in bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:234
+msgid "Maximum number of retransmissions before failure."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:238
+msgid "Incoming connection limit (all peers; 0 means disabled)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:244
+#: i2p2www/pages/site/docs/api/streaming.html:251
+msgid ""
+"(all peers; 0 means disabled)\n"
+"Use with caution as exceeding this will disable a server for a long time."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:260
+msgid ""
+"(2=interactive not supported)\n"
+"This doesn't currently do anything, but setting it to a value other than "
+"1 will cause an error."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:265
+msgid "How long to block on read, in milliseconds. Negative means indefinitely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:269
+msgid ""
+"When we're in slow start, we grow the window size at the rate\n"
+"of 1/(factor).  In standard TCP, window sizes are in bytes,\n"
+"while in I2P, window sizes are in messages.\n"
+"A higher number means slower growth."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:276
+msgid ""
+"How long to block on write/flush, in milliseconds. Negative means "
+"indefinitely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:284
+#: i2p2www/pages/site/docs/spec/streaming.html:10
+msgid "Protocol Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:286
+msgid "See the Streaming Library Specification page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:290
+msgid "Implementation Details"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:293
+msgid ""
+"The initiator sends a packet with the SYNCHRONIZE flag set. This packet "
+"may contain the initial data as well.\n"
+"The peer replies with a packet with the SYNCHRONIZE flag set. This packet"
+" may contain the initial response data as well."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:298
+msgid ""
+"The initiator may send additional data packets, up to the initial window "
+"size, before receiving the SYNCHRONIZE response.\n"
+"These packets will also have the send Stream ID field set to 0.\n"
+"Recipients must buffer packets received on unknown streams for a short "
+"period of time, as they may\n"
+"arrive out of order, in advance of the SYNCHRONIZE packet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:305
+msgid "MTU Selection and Negotiation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:306
+msgid ""
+"The maximum message size (also called the MTU / MRU) is negotiated to the"
+" lower value supported by\n"
+"the two peers. As tunnel messages are padded to 1KB, a poor MTU selection"
+" will lead to\n"
+"a large amount of overhead.\n"
+"The MTU is specified by the option i2p.streaming.maxMessageSize.\n"
+"The current default MTU of 1730 was chosen to fit precisely into two 1K "
+"I2NP tunnel messages,\n"
+"including overhead for the typical case."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:315
+msgid ""
+"The first message in a connection includes a 387 byte (typical) "
+"Destination added by the streaming layer,\n"
+"and usually a 898 byte (typical) LeaseSet, and Session keys, bundled in "
+"the Garlic message by the router.\n"
+"(The LeaseSet and Session Keys will not be bundled if an ElGamal Session "
+"was previously established).\n"
+"Therefore, the goal of fitting a complete HTTP request in a single 1KB "
+"I2NP message is not always attainable.\n"
+"However, the selection of the MTU, together with careful implementation "
+"of fragmentation\n"
+"and batching strategies in the tunnel gateway processor, are important "
+"factors in network bandwidth,\n"
+"latency, reliability, and efficiency, especially for long-lived "
+"connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:326
+#, python-format
+msgid ""
+"Data integrity is assured by the gzip CRC-32 checksum implemented in\n"
+"the I2CP layer.\n"
+"There is no checksum field in the streaming protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:334
+#, python-format
+msgid ""
+"Each packet is sent through I2P as a single message (or as an individual "
+"clove in a\n"
+"Garlic Message). Message encapsulation "
+"is implemented\n"
+"in the underlying I2CP, I2NP, and\n"
+"tunnel message layers. There is no "
+"packet delimiter\n"
+"mechanism or payload length field in the streaming protocol."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:344
+msgid "Windowing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:345
+msgid ""
+"The streaming lib uses standard slow-start (exponential window growth) "
+"and congestion avoidance (linear window growth)\n"
+"phases, with exponential backoff.\n"
+"Windowing and acknowledgments use packet count, not byte count."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:352
+msgid "Close"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:353
+msgid ""
+"Any packet, including one with the SYNCHRONIZE flag set, may have the "
+"CLOSE flag sent as well.\n"
+"The connection is not closed until the peer responds with the CLOSE flag."
+"\n"
+"CLOSE packets may contain data as well."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:360
+msgid "Control Block Sharing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:361
+msgid ""
+"The streaming lib supports \"TCP\" Control Block sharing.\n"
+"This shares two important streaming lib parameters\n"
+"(window size and round trip time)\n"
+"across connections to the same remote peer.\n"
+"This is used for \"temporal\" sharing at connection open/close time,\n"
+"not \"ensemble\" sharing during a connection (See\n"
+"RFC 2140).\n"
+"There is a separate share per ConnectionManager (i.e. per local "
+"Destination)\n"
+"so that there is no information leakage to other Destinations on the\n"
+"same router.\n"
+"The share data for a given peer expires after a few minutes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:375
+msgid "Other Parameters"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:376
+msgid ""
+"The following parameters are hardcoded, but may be of interest for "
+"analysis:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:393
+#: i2p2www/pages/site/docs/how/network-database.html:785
+msgid "History"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:394
+msgid ""
+"The streaming library has grown organically for I2P - first mihi "
+"implemented the\n"
+"\"mini streaming library\" as part of I2PTunnel, which was limited to a "
+"window\n"
+"size of 1 message (requiring an ACK before sending the next one), and "
+"then it was\n"
+"refactored out into a generic streaming interface (mirroring TCP sockets)"
+" and the\n"
+"full streaming implementation was deployed with a sliding window protocol"
+" and \n"
+"optimizations to take into account the high bandwidth x delay product.  "
+"Individual\n"
+"streams may adjust the maximum packet size and other options. The default"
+"\n"
+"message size is selected to fit precisely in two 1K I2NP tunnel messages,"
+"\n"
+"and is a reasonable tradeoff between the bandwidth costs of \n"
+"retransmitting lost messages, and the latency and overhead of multiple "
+"messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:408
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:331
+#: i2p2www/pages/site/docs/how/garlic-routing.html:242
+#: i2p2www/pages/site/docs/how/network-database.html:790
+#: i2p2www/pages/site/docs/how/peer-selection.html:265
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:255
+#: i2p2www/pages/site/docs/protocol/i2cp.html:646
+#: i2p2www/pages/site/docs/protocol/i2np.html:235
+#: i2p2www/pages/site/docs/spec/updates.html:126
+#: i2p2www/pages/site/docs/transport/ntcp.html:445
+#: i2p2www/pages/site/docs/transport/ssu.html:482
+#: i2p2www/pages/site/docs/tunnels/implementation.html:503
+msgid "Future Work"
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:409
+msgid ""
+"The behavior of the streaming library has a profound impact on\n"
+"application-level performance, and as such, is an important\n"
+"area for further analysis."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:415
+msgid "Additional tuning of the streaming lib parameters may be necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:418
+#, python-format
+msgid ""
+"Another area for research is the interaction of the streaming lib with "
+"the\n"
+"NTCP and SSU transport layers.\n"
+"See the NTCP discussion page for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:423
+msgid ""
+"The interaction of the routing algorithms with the streaming lib strongly"
+" affects performance.\n"
+"In particular, random distribution of messages to multiple tunnels in a "
+"pool\n"
+"leads to a high degree of out-of-order delivery which results in smaller "
+"window\n"
+"sizes than would otherwise be the case. The router currently routes \n"
+"messages for a single from/to destination pair through a consistent set \n"
+"of tunnels, until tunnel expiration or delivery failure. The router's \n"
+"failure and tunnel selection algorithms should be reviewed for possible \n"
+"improvements."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:433
+msgid "The data in the first SYN packet may exceed the receiver's MTU."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:436
+msgid "The DELAY_REQUESTED field could be used more."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:439
+msgid ""
+"Duplicate initial SYNCHRONIZE packets on short-lived streams may not be "
+"recognized and removed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:442
+msgid "Don't send the MTU in a retransmission."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:445
+msgid ""
+"Data is sent along unless the outbound window is full.\n"
+"(i.e. no-Nagle or TCP_NODELAY)\n"
+"Probably should have a configuration option for this."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:450
+msgid ""
+"zzz has added debug code to the streaming library to log packets in a "
+"wireshark-compatible\n"
+"(pcap) format; Use this to further analyze performance.\n"
+"The format may require enhancement to map more streaming lib parameters "
+"to TCP fields."
+msgstr ""
+
+#: i2p2www/pages/site/docs/api/streaming.html:455
+msgid ""
+"There are proposals to replace the streaming lib with standard TCP\n"
+"(or perhaps a null layer together with raw sockets).\n"
+"This would unfortunately be incompatible with the streaming lib\n"
+"but it would be good to compare the performance of the two."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:3
+#: i2p2www/pages/site/docs/spec/configuration.html:3
+msgid "September 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:7
+msgid ""
+"There are several bittorrent clients and trackers on I2P.\n"
+"As I2P addressing uses a Destination instead of an IP and port, minor\n"
+"changes are required to tracker and client software for operation on I2P."
+"\n"
+"These changes are specified below.\n"
+"Note carefully the guidelines for compatibility with older I2P clients "
+"and trackers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:15
+msgid ""
+"This page specifies protocol details common to all clients and trackers.\n"
+"Specific clients and trackers may implement other unique features or "
+"protocols."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:20
+msgid "We welcome additional ports of client and tracker software to I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:26
+msgid "Announces"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:27
+msgid ""
+"Clients generally include a fake port=6881 parameter in the announce, for"
+" compatibility with older trackers.\n"
+"Trackers may ignore the port parameter, and should not require it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:32
+#, python-format
+msgid ""
+"The ip parameter is the base 64 of the client's\n"
+"Destination,\n"
+"using the I2P Base 64 alphabet [A-Z][a-z][0-9]-~.\n"
+"Destinations\n"
+"are 387+ bytes, so the Base 64 is 516+ bytes.\n"
+"Clients generally append \".i2p\" to the Base 64 Destination for "
+"compatibility with older trackers.\n"
+"Trackers should not require an appended \".i2p\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:42
+msgid "Other parameters are the same as in standard bittorrent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:46
+msgid ""
+"While all current Destinations for clients are exactly 387 bytes, a "
+"tracker should not\n"
+"presume that will always be so. A reasonable maximum to assume, for now, "
+"is 475 bytes.\n"
+"As the tracker must decode the Base64 to deliver compact responses (see "
+"below),\n"
+"the tracker should probably decode and reject bad Base64 when announced."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:53
+msgid ""
+"The default response type is non-compact. Clients may request a compact "
+"response with\n"
+"the parameter compact=1. A tracker may, but is not required to, return\n"
+"a compact response when requested."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:59
+msgid ""
+"Developers of new I2P clients\n"
+"are strongly encouraged to implemenent announces over their own tunnel "
+"rather than\n"
+"the HTTP client proxy at port 4444. Doing so is both more efficient and "
+"it allows\n"
+"destination enforcement by the tracker (see below)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:66
+msgid ""
+"There are no known I2P clients or trackers that currently support UDP "
+"announce/responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:71
+msgid "Non-Compact Tracker Responses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:72
+msgid ""
+"The non-compact response is just as in standard bittorrent, with an I2P "
+"\"ip\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:76
+msgid ""
+"Trackers generally include a fake port key, or use the port from the "
+"announce, for compatibility with older clients.\n"
+"Clients must ignore the port parameter, and should not require it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:81
+#, python-format
+msgid ""
+"The value of the ip key is the base 64 of the client's\n"
+"Destination, as "
+"described above.\n"
+"Trackers generally append \".i2p\" to the Base 64 Destination if it "
+"wasn't in the announce ip, for compatibility with older clients.\n"
+"Clients should not require an appended \".i2p\" in the responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:88
+msgid "Other response keys and values are the same as in standard bittorrent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:94
+msgid "Compact Tracker Responses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:95
+#, python-format
+msgid ""
+"In the compact response, the value of the \"peers\" dictionary key is a "
+"single byte string,\n"
+"whose length is a multiple of 32 bytes.\n"
+"This string contains the concatenated\n"
+"32-byte SHA-256 Hashes\n"
+"of the binary\n"
+"Destinations\n"
+"of the peers.\n"
+"This hash must be computed by the tracker, unless destination enforcement"
+"\n"
+"(see below) is used, in which case the hash delivered in the X-I2P-"
+"DestHash\n"
+"or X-I2P-DestB32 HTTP headers may be converted to binary and stored.\n"
+"The peers key may be absent, or the peers value may be zero-length."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:109
+msgid ""
+"While compact response support is optional for both clients and trackers,"
+" it is highly\n"
+"recommended as it reduces the nominal response size by over 90%."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:116
+msgid "Destination Enforcement"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:117
+#, python-format
+msgid ""
+"Some, but not all, I2P bittorrent clients announce over their own "
+"tunnels.\n"
+"Trackers may choose to prevent spoofing by requiring this, and verifying "
+"the\n"
+"client's\n"
+"Destination\n"
+"using HTTP headers added by the I2PTunnel HTTP Server tunnel.\n"
+"The headers are X-I2P-DestHash, X-I2P-DestB64, and X-I2P-DestB32, which "
+"are\n"
+"different formats for the same information.\n"
+"These headers cannot be spoofed by the client.\n"
+"A tracker enforcing destinations need not require the ip announce "
+"parameter at all."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:129
+msgid ""
+"As several clients use the HTTP proxy instead of their own tunnel for "
+"announces,\n"
+"destination enforcement will prevent usage by those clients unless or "
+"until\n"
+"those clients are converted to announcing over their own tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:135
+msgid ""
+"Unfortunately, as the network grows, so will the amount of maliciousness,"
+"\n"
+"so we expect that all trackers will eventually enforce destinations.\n"
+"Both tracker and client developers should anticipate it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:143
+msgid "Announce Host Names"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:144
+#, python-format
+msgid ""
+"Announce URL host names in torrent files generally follow the\n"
+"I2P naming standards.\n"
+"In addition to host names from address books and \".b32.i2p\" Base 32 "
+"hostnames,\n"
+"the full Base 64 Destination (with [or without?] \".i2p\" appended) "
+"should be supported.\n"
+"Non-open trackers should recognize their own host name in any of these "
+"formats."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:152
+msgid ""
+"To preserve anonymity,\n"
+"clients should generally ignore non-I2P announce URLs in torrent files."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:159
+msgid "Client Connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:160
+msgid ""
+"Client-to-client connections use the standard protocol over TCP.\n"
+"There are no known I2P clients that currently support uTP communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:165
+#, python-format
+msgid ""
+"I2P uses 387+ byte Destinations\n"
+"for addresses, as explained above."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:170
+msgid ""
+"If the client has only the hash of the destination (such as from a "
+"compact response or PEX), it must perform a lookup\n"
+"by encoding it with Base 32, appending \".b32.i2p\", and querying the "
+"Naming Service,\n"
+"which will return the full Destination if available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:176
+msgid ""
+"If the client has a peer's full Destination it received in a non-compact "
+"response, it should use it\n"
+"directly in the connection setup.\n"
+"Do not convert a Destination back to a Base 32 hash for lookup, this is "
+"quite inefficient."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:183
+msgid "Cross-Network Prevention"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:184
+msgid ""
+"To preserve anonymity,\n"
+"I2P bittorrent clients generally do not support non-I2P announces or peer"
+" connections.\n"
+"I2P HTTP outproxies often block announces.\n"
+"There are no known SOCKS outproxies supporting bittorrent traffic."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:191
+msgid ""
+"To prevent usage by non-I2P clients via an HTTP inproxy, I2P trackers "
+"often\n"
+"block accesses or announces that contain an X-Forwarded-For HTTP header.\n"
+"Trackers should reject standard network announces with IPv4 or IPv6 IPs, "
+"and not deliver them in responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:200
+#, python-format
+msgid ""
+"I2P PEX is based on ut_pex.\n"
+"As there does not appear to be a formal specification of ut_pex "
+"available,\n"
+"it may be necessary to review the libtorrent source for assistance.\n"
+"It is an extension message, identified as \"i2p_pex\" in\n"
+"the extension "
+"handshake.\n"
+"It contains a bencoded dictionary with up to 3 keys, \"added\", "
+"\"added.f\", and \"dropped\".\n"
+"The added and dropped values are each a single byte string, whose length "
+"is a multiple of 32 bytes.\n"
+"These byte strings are the concatenated SHA-256 Hashes of the binary\n"
+"Destinations\n"
+"of the peers.\n"
+"This is the same format as the peers dictionary value in the i2p compact "
+"response format specified above.\n"
+"The added.f value, if present, is the same as in ut_pex."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:218
+msgid ""
+"DHT support is included in the i2psnark client as of version 0.9.2.\n"
+"Preliminary differences from\n"
+"BEP 5\n"
+"are described below, and are subject to change.\n"
+"Contact the I2P developers if you wish to develop a client supporting DHT."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:226
+msgid ""
+"Unlike standard DHT, I2P DHT does not use a bit in the options handshake,"
+" or the PORT message.\n"
+"It is advertised with an extension message, identified as \"i2p_dht\" in\n"
+"the extension "
+"handshake.\n"
+"It contains a bencoded dictionary with two keys, \"port\" and \"rport\", "
+"both integers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:233
+msgid ""
+"The UDP (datagram) port listed in the compact node info is used\n"
+"to receive repliable (signed) datagrams.\n"
+"This is used for queries, except for announces.\n"
+"We call this the \"query port\".\n"
+"This is the \"port\" value from the extension message.\n"
+"Queries use I2CP protocol number 17."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:242
+msgid ""
+"In addition to that UDP port, we use a second datagram\n"
+"port equal to the query port + 1. This is used to receive\n"
+"unsigned (raw) datagrams for replies, errors, and announces.\n"
+"This port provides increased efficiency since replies\n"
+"contain tokens sent in the query, and need not be signed.\n"
+"We call this the \"response port\".\n"
+"This is the \"rport\" value from the extension message.\n"
+"It must be 1 + the query port.\n"
+"Responses and announces use I2CP protocol number 18."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:254
+msgid ""
+"Compact peer info is 32 bytes (32 byte SHA256 Hash)\n"
+"instead of 4 byte IP + 2 byte port. There is no peer port.\n"
+"In a response, the \"values\" key is a list of strings, each containing a"
+" single compact peer info."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:260
+msgid ""
+"Compact node info is 54 bytes (20 byte SHA1 Hash + 32 byte SHA256 Hash + "
+"2 byte port)\n"
+"instead of 20 byte SHA1 Hash + 4 byte IP + 2 byte port.\n"
+"In a response, the \"nodes\" key is a\n"
+"single byte string with concatenated compact node info."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:267
+msgid ""
+"Secure node ID requirement: To make various DHT attacks more difficult,\n"
+"the first 4 bytes of the Node ID must match the first 4 bytes of the "
+"destination Hash,\n"
+"and the next two bytes of the Node ID must match the next two bytes of "
+"the\n"
+"destination hash exclusive-ORed with the port."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:274
+msgid ""
+"In a torrent file,\n"
+"the trackerless torrent dictionary \"nodes\" key is TBD.\n"
+"It could be a list of\n"
+"32 byte binary strings (SHA256 Hashes) instead of a list of lists\n"
+"containing a host string and a port integer.\n"
+"Alternatives: A single byte string with concatenated hashes,\n"
+"or a list of strings alone."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:285
+#: i2p2www/pages/site/docs/how/intro.html:187
+msgid "Additional Information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:287
+#, python-format
+msgid ""
+"I2P bittorrent standards are generally discussed on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:290
+#, python-format
+msgid ""
+"A chart of current tracker software capabilities is also available there."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:293
+#, python-format
+msgid ""
+"The\n"
+"I2P bittorrent FAQ"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/bittorrent.html:297
+#, python-format
+msgid "DHT on I2P discussion"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:2
+#: i2p2www/pages/site/docs/applications/supported.html:5
+msgid "Supported Applications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:9
+#: i2p2www/pages/site/docs/applications/supported.html:186
+msgid "Blogging, Forums, and Wikis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:11
+#: i2p2www/pages/site/docs/applications/supported.html:232
+msgid "Decentralized File Storage"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:14
+#: i2p2www/pages/site/docs/applications/supported.html:244
+msgid "Development Tools"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:17
+#: i2p2www/pages/site/docs/applications/supported.html:246
+msgid "Version control"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:21
+#: i2p2www/pages/site/docs/applications/supported.html:265
+msgid "Domain Naming"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:23
+#: i2p2www/pages/site/docs/applications/supported.html:283
+msgid "Email"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:26
+#: i2p2www/pages/site/docs/applications/supported.html:315
+msgid "File Sharing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:29
+#: i2p2www/pages/site/docs/applications/supported.html:317
+msgid "BitTorrent clients"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:31
+#: i2p2www/pages/site/docs/applications/supported.html:359
+msgid "BitTorrent trackers and indexers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:40
+#: i2p2www/pages/site/docs/applications/supported.html:426
+msgid "Network Administration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:43
+#: i2p2www/pages/site/docs/applications/supported.html:428
+msgid "General-purpose socket utilities"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:50
+#: i2p2www/pages/site/docs/applications/supported.html:469
+msgid "Real-time Chat"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:53
+#: i2p2www/pages/site/docs/applications/supported.html:471
+msgid "Instant messaging clients"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:55
+#: i2p2www/pages/site/docs/applications/supported.html:481
+msgid "IRC clients"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:57
+#: i2p2www/pages/site/docs/applications/supported.html:532
+msgid "IRC servers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:62
+#: i2p2www/pages/site/docs/applications/supported.html:548
+msgid "Web Browsing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:65
+#: i2p2www/pages/site/docs/applications/supported.html:550
+msgid "Anonymous websites"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:67
+#: i2p2www/pages/site/docs/applications/supported.html:599
+msgid "Proxy software"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:69
+#: i2p2www/pages/site/docs/applications/supported.html:624
+msgid "Inproxies"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:71
+#: i2p2www/pages/site/docs/applications/supported.html:640
+msgid "Outproxies"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:76
+#: i2p2www/pages/site/docs/applications/supported.html:654
+msgid "Website Hosting"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:79
+#: i2p2www/pages/site/docs/applications/supported.html:669
+msgid "Web servers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:85
+#, python-format
+msgid ""
+"This is intended to be a comprehensive listing of applications used with\n"
+"I2P. If you know of something that's missing please submit a ticket on\n"
+"Trac, and be sure to select the"
+"\n"
+"“www” component in the submission form."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:92
+msgid ""
+"\n"
+"Supported applications are tagged with one or more of the following:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:97
+#: i2p2www/pages/site/docs/applications/supported.html:279
+#: i2p2www/pages/site/docs/applications/supported.html:311
+#: i2p2www/pages/site/docs/applications/supported.html:323
+#: i2p2www/pages/site/docs/applications/supported.html:666
+msgid "bundled"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:100
+msgid ""
+"Bundled application — I2P ships with a few officially\n"
+"supported applications that let new users take immediate advantage of\n"
+"some of I2P's more useful capabilities."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:107
+#: i2p2www/pages/site/docs/applications/supported.html:195
+#: i2p2www/pages/site/docs/applications/supported.html:208
+#: i2p2www/pages/site/docs/applications/supported.html:220
+#: i2p2www/pages/site/docs/applications/supported.html:228
+#: i2p2www/pages/site/docs/applications/supported.html:241
+#: i2p2www/pages/site/docs/applications/supported.html:292
+#: i2p2www/pages/site/docs/applications/supported.html:391
+#: i2p2www/pages/site/docs/applications/supported.html:413
+#: i2p2www/pages/site/docs/applications/supported.html:422
+#: i2p2www/pages/site/docs/applications/supported.html:510
+msgid "plugin"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:110
+#, python-format
+msgid ""
+"Third-party plugin — I2P's plugin system provides convenient\n"
+"deployment of I2P-enabled applications and allows tighter integration\n"
+"with the router. Plugins are [reviewed by the community](http://%(plugins)s) to identify security and\n"
+"anonymity issues."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:121
+#: i2p2www/pages/site/docs/applications/supported.html:220
+#: i2p2www/pages/site/docs/applications/supported.html:228
+#: i2p2www/pages/site/docs/applications/supported.html:241
+#: i2p2www/pages/site/docs/applications/supported.html:252
+#: i2p2www/pages/site/docs/applications/supported.html:261
+#: i2p2www/pages/site/docs/applications/supported.html:329
+#: i2p2www/pages/site/docs/applications/supported.html:340
+#: i2p2www/pages/site/docs/applications/supported.html:355
+#: i2p2www/pages/site/docs/applications/supported.html:401
+#: i2p2www/pages/site/docs/applications/supported.html:413
+#: i2p2www/pages/site/docs/applications/supported.html:422
+#: i2p2www/pages/site/docs/applications/supported.html:437
+#: i2p2www/pages/site/docs/applications/supported.html:443
+#: i2p2www/pages/site/docs/applications/supported.html:449
+#: i2p2www/pages/site/docs/applications/supported.html:459
+#: i2p2www/pages/site/docs/applications/supported.html:465
+#: i2p2www/pages/site/docs/applications/supported.html:477
+#: i2p2www/pages/site/docs/applications/supported.html:510
+#: i2p2www/pages/site/docs/applications/supported.html:516
+#: i2p2www/pages/site/docs/applications/supported.html:522
+#: i2p2www/pages/site/docs/applications/supported.html:528
+#: i2p2www/pages/site/docs/applications/supported.html:605
+#: i2p2www/pages/site/docs/applications/supported.html:614
+#: i2p2www/pages/site/docs/applications/supported.html:620
+#: i2p2www/pages/site/docs/applications/supported.html:666
+#: i2p2www/pages/site/docs/applications/supported.html:681
+#: i2p2www/pages/site/docs/applications/supported.html:687
+#: i2p2www/pages/site/docs/applications/supported.html:693
+#: i2p2www/pages/site/docs/applications/supported.html:699
+msgid "standalone"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:121
+#: i2p2www/pages/site/docs/applications/supported.html:195
+#: i2p2www/pages/site/docs/applications/supported.html:202
+#: i2p2www/pages/site/docs/applications/supported.html:208
+#: i2p2www/pages/site/docs/applications/supported.html:214
+#: i2p2www/pages/site/docs/applications/supported.html:349
+#: i2p2www/pages/site/docs/applications/supported.html:373
+#: i2p2www/pages/site/docs/applications/supported.html:382
+#: i2p2www/pages/site/docs/applications/supported.html:538
+#: i2p2www/pages/site/docs/applications/supported.html:544
+msgid "standalone/mod"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:124
+msgid ""
+"Third-party standalone application — Many standard network\n"
+"applications only require careful setup and configuration to communicate\n"
+"anonymously over I2P. These are tagged with standalone. Some\n"
+"applications, tagged with standalone/mod, require patching to\n"
+"function properly over I2P or to prevent inadvertent disclosure of\n"
+"identifying information such as the user's hostname or external IP\n"
+"address."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:135
+#: i2p2www/pages/site/docs/applications/supported.html:302
+#: i2p2www/pages/site/docs/applications/supported.html:558
+#: i2p2www/pages/site/docs/applications/supported.html:568
+#: i2p2www/pages/site/docs/applications/supported.html:577
+#: i2p2www/pages/site/docs/applications/supported.html:583
+#: i2p2www/pages/site/docs/applications/supported.html:589
+#: i2p2www/pages/site/docs/applications/supported.html:595
+#: i2p2www/pages/site/docs/applications/supported.html:636
+#: i2p2www/pages/site/docs/applications/supported.html:650
+msgid "service"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:138
+msgid ""
+"Third-party essential network service — Services which on\n"
+"the I2P network are analogous to those provided on the public Internet\n"
+"by hosting providers, ISPs, and Google: eepsite indexes and jump\n"
+"services, search engines, email, DNS-style name services, hosting,\n"
+"proxies, etc. These services focus on boosting the usefulness of the\n"
+"network as a whole, and making network content more discoverable."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:148
+#: i2p2www/pages/site/docs/applications/supported.html:220
+#: i2p2www/pages/site/docs/applications/supported.html:355
+msgid "unmaintained"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:151
+msgid ""
+"Unmaintained — This is used to tag plugins, applications,\n"
+"and services which appear to be unmaintained and may be removed from\n"
+"this listing in the future."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:159
+#, python-format
+msgid ""
+"Warning: Using an application, plugin, or service with I2P\n"
+"doesn't automatically protect your anonymity. I2P is merely a set of "
+"tools\n"
+"which can help you mitigate certain identified\n"
+"threats to anonymity. We do not and cannot make any guarantees about "
+"the\n"
+"safety of the applications, plugins, and services listed below. Most\n"
+"applications and plugins must be properly configured, and some will need "
+"to\n"
+"be patched — and even then your anonymity might not be assured. "
+"Similarly,\n"
+"services could put your anonymity at risk, either by design or through\n"
+"carelessness on their part or your own."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:171
+msgid ""
+"If you have doubts about the suitability of an application,\n"
+"plugin, or service for use with I2P, you are urged to inquire about "
+"privacy\n"
+"issues with its maintainers, to search its mailing lists and bug tracker "
+"if\n"
+"one exists, and consult trusted, knowledgeable members of the I2P\n"
+"community."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:179
+msgid ""
+"Take responsibility for your own anonymity and safety — always\n"
+"seek expert advice, educate yourself, practice good judgment, be mindful "
+"of\n"
+"disclosing personally identifying information, and don't take\n"
+"shortcuts."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:201
+msgid "Lightweight forum software."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:207
+msgid "Another lightweight blogging platform."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:213
+msgid "Most popular open source forum software."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:219
+msgid "Distributed forums software, originally developed by jrandom."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:224
+#, python-format
+msgid ""
+"A Java-based MediaWiki clone. No external database needed.\n"
+"Plugin available here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:236
+#, python-format
+msgid ""
+"Port of the Tahoe-"
+"LAFS\n"
+"distributed file system to the I2P network. Controller plugin here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:251
+msgid "Most popular distributed version control system."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:257
+#, python-format
+msgid ""
+"Another distributed version control system. Currently\n"
+"used in I2P development."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:269
+#, python-format
+msgid ""
+"Provides management of addressbooks, which are part of a simple,\n"
+"user-controlled I2P naming system somewhat\n"
+"analogous to the Internet's Domain Name System (DNS). Addressbooks map\n"
+"Base64 destinations to short, usually human-readable “domain” names "
+"ending\n"
+"with a .i2p suffix which the I2P router's HTTP client can resolve back to"
+"\n"
+"Base64 addresses. (Note: While Base64 destinations are globally\n"
+"unique, addressbook “domain” names only resolve to unique destinations\n"
+"locally.)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:288
+msgid ""
+"Serverless peer-to-peer email application using a distributed hash table\n"
+"(DHT) for secure mail storage."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:297
+msgid ""
+"Provides email service within the I2P network via @mail.i2p addresses,\n"
+"and email gateway service between the I2P network and the public Internet"
+"\n"
+"via @i2pmail.org addresses. One of the oldest continuous services on I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:307
+msgid ""
+"Simple web browser-based email interface. Configured to use Postman's\n"
+"email service by default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:322
+msgid "I2P's integrated BitTorrent client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:328
+msgid "Modified version of I2PSnark."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:334
+msgid ""
+"\n"
+"A fork of rufus that uses the Basic Open Bridge (BOB) and has many\n"
+"improvements, including using the latest wxwidgets and python. It also\n"
+"supports use of seedless if installed for trackerless torrents and\n"
+"magnet-link like fetching of torrents within I2P.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:345
+msgid ""
+"Clean, full-featured cross-platform BitTorrent client with official\n"
+"ports for several GUI toolkits."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:354
+msgid "Has a plugin providing I2P support."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:361
+#, python-format
+msgid ""
+"For a detailed feature comparison of I2P-enabled trackers/indexers, see\n"
+"here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:369
+msgid ""
+"The code that powered one of the first major tracker/indexer sites on the"
+"\n"
+"Internet. Patched for I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:378
+#, python-format
+msgid ""
+"Lightweight tracker/indexer. I2P mod available in the i2p.opentracker\n"
+"branch of the I2P Monotone repository."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:387
+#, python-format
+msgid ""
+"zzz's Java-based open tracker. More info\n"
+"here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:400
+msgid "I2P port of the aMule ED2K client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:409
+#, python-format
+msgid ""
+"Port of the Phex Gnutella "
+"client. Website\n"
+"for plugin version here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:418
+#, python-format
+msgid ""
+"Cache for Gnutella peers on I2P. Website for plugin version\n"
+"here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:433
+msgid ""
+"Unix standard tool for socket relaying. Several clones, ports, and forks\n"
+"have appeared over the years."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:442
+msgid "Like netcat but more powerful."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:448
+msgid ""
+"Proxy providing simple, transparent SOCKS-ification of network "
+"applications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:458
+msgid ""
+"Most popular implementation of the Secure Shell (SSH) protocol and "
+"related tools."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:464
+msgid "Open source Secure Shell (SSH) client for Windows."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:476
+msgid "IM client with multiple incarnations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:483
+msgid ""
+"Many IRC clients leak identifying information to servers or other\n"
+"clients, so I2P's IRC and SOCKS IRC client tunnels filter certain inbound"
+"\n"
+"and outbound messages to scrub data such as LAN IP addresses, external IP"
+"\n"
+"addresses, local hostnames, and the name and version of the IRC client. "
+"Two\n"
+"message types in particular, DCC and CTCP, can't be sufficiently "
+"anonymized\n"
+"without changes to the protocols or to IRC client/server code, so they "
+"are\n"
+"completely blocked, except for CTCP ACTION (the message emitted by the\n"
+"/me command) which isn't inherently dangerous."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:494
+msgid ""
+"I2P's IRC filtering may not cover every possible leak — users should also"
+"\n"
+"check if their client is sending their real name or local username. "
+"Packet\n"
+"sniffers such as Wireshark are\n"
+"useful here. Eliminating remaining leaks may be as simple as changing the"
+"\n"
+"client's default configuration. If that doesn't help, inform the I2P\n"
+"developers; they may be able to solve it via additional filtering."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:506
+#, python-format
+msgid ""
+"Small Java-based IRC client. Plugin available here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:515
+msgid "Cross-platform graphical IRC client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:521
+msgid "Unixy terminal-based IRC client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:527
+msgid "Another Unixy terminal-based IRC client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:537
+msgid "IRC server developed from scratch."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:543
+msgid "Most popular IRC server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:555
+msgid ""
+"Any website hosted anonymously on I2P, reachable through the I2P router's"
+" HTTP proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:563
+msgid ""
+"Distributed anonymous websites hosted\n"
+"using Tahoe-LAFS-I2P, currently only reachable with Tahoe-LAFS-I2P\n"
+"clients or through the Tahoe-LAFS-I2P HTTP proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:573
+#, python-format
+msgid ""
+"Website for sponge's jump service.\n"
+"Source code available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:582
+msgid "Another jump service."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:588
+msgid "Dynamically updated eepsite index."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:594
+#, python-format
+msgid "Website for zzz's jump service."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:604
+msgid "SOCKS-enabled caching web proxy with basic filtering capabilities."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:610
+msgid ""
+"Privacy-focused non-caching web proxy with advanced filtering\n"
+"capabilities. Excels at removing ads and other junk."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:619
+msgid "Venerable caching web proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:626
+msgid "Gateways allowing users on the public Internet to access eepsites."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:633
+#, python-format
+msgid "tino's inproxy on the public Internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:642
+msgid ""
+"Gateways allowing I2P users to access content hosted on the public "
+"Internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:649
+msgid "Publicly advertised outproxy running Squid, located in Germany."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:659
+msgid ""
+"Lightweight web server and Java servlet container. I2P is tightly\n"
+"integrated with a bundled copy of Jetty which by default is configured to"
+"\n"
+"host the user's eepsite. The "
+"bundled\n"
+"Jetty also serves the I2P router console and web applications bundled "
+"with\n"
+"I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:671
+msgid ""
+"In addition to Jetty, any web server should function over I2P without\n"
+"modification so long as it's HTTP-compliant. Some web servers known to\n"
+"currently serve content on the I2P network are:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:680
+msgid "Most popular web server on the public WWW."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:686
+msgid "Web server and Java servlet container. More features than Jetty."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:692
+msgid "Fast lightweight web server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/applications/supported.html:698
+msgid "High-performance lightweight web server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:2
+msgid "Naming discussion"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:4
+#, python-format
+msgid ""
+"NOTE: The following is a discussion of the reasons behind the I2P naming "
+"system,\n"
+"common arguments and possible alternatives.\n"
+"See the naming page for current documentation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:10
+msgid "Discarded alternatives"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:12
+msgid ""
+"Naming within I2P has been an oft-debated topic since the very beginning "
+"with\n"
+"advocates across the spectrum of possibilities.  However, given I2P's "
+"inherent\n"
+"demand for secure communication and decentralized operation, the "
+"traditional\n"
+"DNS-style naming system is clearly out, as are \"majority rules\" voting "
+"systems."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:19
+msgid ""
+"I2P does not promote the use of DNS-like services though, as the damage "
+"done\n"
+"by hijacking a site can be tremendous - and insecure destinations have no"
+"\n"
+"value.  DNSsec itself still falls back on registrars and certificate "
+"authorities,\n"
+"while with I2P, requests sent to a destination cannot be intercepted or "
+"the reply\n"
+"spoofed, as they are encrypted to the destination's public keys, and a "
+"destination\n"
+"itself is just a pair of public keys and a certificate.  DNS-style "
+"systems on the\n"
+"other hand allow any of the name servers on the lookup path to mount "
+"simple denial\n"
+"of service and spoofing attacks.  Adding on a certificate authenticating "
+"the\n"
+"responses as signed by some centralized certificate authority would "
+"address many of\n"
+"the hostile nameserver issues but would leave open replay attacks as well"
+" as \n"
+"hostile certificate authority attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:33
+msgid ""
+"Voting style naming is dangerous as well, especially given the "
+"effectiveness of\n"
+"Sybil attacks in anonymous systems - the attacker can simply create an "
+"arbitrarily\n"
+"high number of peers and \"vote\" with each to take over a given name.  "
+"Proof-of-work\n"
+"methods can be used to make identity non-free, but as the network grows "
+"the load\n"
+"required to contact everyone to conduct online voting is implausible, or "
+"if the\n"
+"full network is not queried, different sets of answers may be reachable."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:42
+msgid ""
+"As with the Internet however, I2P is keeping the design and operation of "
+"a \n"
+"naming system out of the (IP-like) communication layer.  The bundled "
+"naming library\n"
+"includes a simple service provider interface which alternate naming systems can\n"
+"plug into, allowing end users to drive what sort of naming tradeoffs they"
+" prefer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:50
+msgid ""
+"See also Names: "
+"Decentralized, Secure, Human-Meaningful: Choose Two."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:55
+msgid "(adapted from a post in the old Syndie, November 26, 2005)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:58
+msgid ""
+"Q:\n"
+"What to do if some hosts \n"
+"do not agree on one address and if some addresses are working, others are"
+" not? \n"
+"Who is the right source of a name?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:64
+msgid ""
+"A:\n"
+"You don't. This is actually a critical difference between names on I2P "
+"and how \n"
+"DNS works - names in I2P are human readable, secure, but not globally"
+" \n"
+"unique.  This is by design, and an inherent part of our need for "
+"security."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:70
+msgid ""
+"If I could somehow convince you to change the destination associated with"
+" some \n"
+"name, I'd successfully \"take over\" the site, and under no circumstances"
+" is that \n"
+"acceptable.  Instead, what we do is make names locally unique: "
+"they are \n"
+"what you use to call a site, just as how you can call things "
+"whatever \n"
+"you want when you add them to your browser's bookmarks, or your IM "
+"client's \n"
+"buddy list.  Who you call \"Boss\" may be who someone else calls "
+"\"Sally\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:78
+msgid "Names will not, ever, be securely human readable and globally unique."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:83
+msgid ""
+"The following from zzz is a review of several common\n"
+"complaints about I2P's naming system."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:89
+msgid ""
+"Inefficiency:\n"
+"The whole hosts.txt is downloaded (if it has changed, since eepget uses "
+"the etag and last-modified headers).\n"
+"It's about 400K right now for almost 800 hosts."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:94
+msgid ""
+"True, but this isn't a lot of traffic in the context of i2p, which is "
+"itself wildly inefficient\n"
+"(floodfill databases, huge encryption overhead and padding, garlic "
+"routing, etc.).\n"
+"If you downloaded a hosts.txt file from someone every 12 hours it "
+"averages out to about 10 bytes/sec."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:99
+msgid ""
+"As is usually the case in i2p, there is a fundamental tradeoff here "
+"between anonymity and efficiency.\n"
+"Some would say that using the etag and last-modified headers is hazardous"
+" because it exposes when you\n"
+"last requested the data.\n"
+"Others have suggested asking for specific keys only (similar to what jump"
+" services do, but\n"
+"in a more automated fashion), possibly at a further cost in anonymity."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:106
+#, python-format
+msgid ""
+"Possible improvements would be a replacement or supplement to addressbook"
+" (see %(i2host)sp),\n"
+"or something simple like subscribing to http://example.i2p/cgi-"
+"bin/recenthosts.cgi rather than http://example.i2p/hosts.txt.\n"
+"If a hypothetical recenthosts.cgi distributed all hosts from the last 24 "
+"hours, for example,\n"
+"that could be both more efficient and more anonymous than the current "
+"hosts.txt with last-modified and etag."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:112
+#, python-format
+msgid ""
+"A sample implementation is on stats.i2p at\n"
+"%(url)s.\n"
+"This script returns an Etag with a timestamp.\n"
+"When a request comes in with the If-None-Match etag,\n"
+"the script ONLY returns new hosts since that timestamp, or 304 Not "
+"Modified if there are none.\n"
+"In this way, the script efficiently returns only the hosts the subscriber"
+"\n"
+"does not know about, in an addressbook-compatible manner."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:121
+msgid ""
+"So the inefficiency is not a big issue and there are several ways to "
+"improve things without\n"
+"radical change."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:127
+msgid ""
+"Not Scalable:\n"
+"The 400K hosts.txt (with linear search) isn't that big at the moment and\n"
+"we can probably grow by 10x or 100x before it's a problem."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:132
+msgid ""
+"As far as network traffic see above.\n"
+"But unless you're going to do a slow real-time query over the network for"
+"\n"
+"a key, you need to have the whole set of keys stored locally, at a cost "
+"of about 500 bytes per key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:139
+msgid ""
+"Requires configuration and \"trust\":\n"
+"Out-of-the-box addressbook is only subscribed to "
+"http://www.i2p2.i2p/hosts.txt, which is rarely updated,\n"
+"leading to poor new-user experience."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:144
+msgid ""
+"This is very much intentional. jrandom wants a user to \"trust\" a "
+"hosts.txt\n"
+"provider, and as he likes to say, \"trust is not a boolean\".\n"
+"The configuration step attempts to force users to think about issues of "
+"trust in an anonymous network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:149
+msgid ""
+"As another example, the \"Eepsite Unknown\" error page in the HTTP Proxy\n"
+"lists some jump services, but doesn't \"recommend\" any one in "
+"particular,\n"
+"and it's up to the user to pick one (or not).\n"
+"jrandom would say we trust the listed providers enough to list them but "
+"not enough to\n"
+"automatically go fetch the key from them."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:156
+msgid ""
+"How successful this is, I'm not sure.\n"
+"But there must be some sort of hierarchy of trust for the naming system.\n"
+"To treat everyone equally may increase the risk of hijacking."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:163
+msgid "It isn't DNS"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:166
+msgid ""
+"Unfortunately real-time lookups over i2p would significantly slow down "
+"web browsing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:169
+msgid ""
+"Also, DNS is based on lookups with limited caching and time-to-live, "
+"while i2p\n"
+"keys are permanent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:173
+msgid "Sure, we could make it work, but why? It's a bad fit."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:178
+msgid ""
+"Not reliable:\n"
+"It depends on specific servers for addressbook subscriptions."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:182
+msgid ""
+"Yes it depends on a few servers that you have configured.\n"
+"Within i2p, servers and services come and go.\n"
+"Any other centralized system (for example DNS root servers) would\n"
+"have the same problem. A completely decentralized system (everybody is "
+"authoritative)\n"
+"is possible by implementing an \"everybody is a root DNS server\" "
+"solution, or by\n"
+"something even simpler, like a script that adds everybody in your "
+"hosts.txt to your addressbook."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:190
+msgid ""
+"People advocating all-authoritative solutions generally haven't thought "
+"through\n"
+"the issues of conflicts and hijacking, however."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:196
+msgid ""
+"Awkward, not real-time:\n"
+"It's a patchwork of hosts.txt providers, key-add web form providers, jump"
+" service providers,\n"
+"eepsite status reporters.\n"
+"Jump servers and subscriptions are a pain, it should just work like DNS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:202
+msgid "See the reliability and trust sections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:207
+msgid ""
+"So, in summary, the current system is not horribly broken, inefficient, "
+"or un-scalable,\n"
+"and proposals to \"just use DNS\" aren't well thought-through."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:212
+msgid "Alternatives"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:213
+msgid ""
+"The I2P source contains several pluggable naming systems and supports "
+"configuration options\n"
+"to enable experimentation with naming systems."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:218
+msgid ""
+"Meta - calls two or more other naming systems in order.\n"
+"By default, calls PetName then HostsTxt."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:222
+msgid ""
+"PetName - Looks up in a petnames.txt file.\n"
+"The format for this file is NOT the same as hosts.txt."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:226
+msgid "HostsTxt - Looks up in the following files, in order:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:234
+msgid ""
+"AddressDB - Each host is listed in a separate file in a addressDb/"
+" directory."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:237
+msgid ""
+"Eepget - does an HTTP lookup request from an external\n"
+"server - must be stacked after the HostsTxt lookup with Meta.\n"
+"This could augment or replace the jump system.\n"
+"Includes in-memory caching."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:243
+msgid ""
+"Exec - calls an external program for lookup, allows\n"
+"additional experimentation in lookup schemes, independent of java.\n"
+"Can be used after HostsTxt or as the sole naming system.\n"
+"Includes in-memory caching."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:249
+msgid "Dummy - used as a fallback for Base64 names, otherwise fails."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:253
+msgid ""
+"The current naming system can be changed with the advanced config option "
+"'i2p.naming.impl'\n"
+"(restart required).\n"
+"See core/java/src/net/i2p/client/naming for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:258
+msgid ""
+"Any new system should be stacked with HostsTxt, or should\n"
+"implement local storage and/or the addressbook subscription functions, "
+"since addressbook\n"
+"only knows about the hosts.txt files and format."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:264
+msgid "Certificates"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:265
+msgid ""
+"I2P destinations contain a certificate, however at the moment that "
+"certificate\n"
+"is always null.\n"
+"With a null certificate, base64 destinations are always 516 bytes ending "
+"in \"AAAA\",\n"
+"and this is checked in the addressbook merge mechanism, and possibly "
+"other places.\n"
+"Also, there is no method available to generate a certificate or add it to"
+" a\n"
+"destination. So these will have to be updated to implement certificates."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:273
+#, python-format
+msgid ""
+"One possible use of certificates is for proof of work."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:276
+msgid ""
+"Another is for \"subdomains\" (in quotes because there is really no such "
+"thing,\n"
+"i2p uses a flat naming system) to be signed by the 2nd level domain's "
+"keys."
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:280
+msgid ""
+"With any certificate implementation must come the method for verifying "
+"the\n"
+"certificates.\n"
+"Presumably this would happen in the addressbook merge code.\n"
+"Is there a method for multiple types of certificates, or multiple "
+"certificates?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/discussions/naming.html:286
+msgid ""
+"Adding on a certificate authenticating the\n"
+"responses as signed by some centralized certificate authority would "
+"address many of\n"
+"the hostile nameserver issues but would leave open replay attacks as well"
+" as \n"
+"hostile certificate authority attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:2
+msgid "Low-level Cryptography Details"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:6
+msgid "This page specifies the low-level details of the cryptography in I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:10
+#, python-format
+msgid ""
+"There are a handful of cryptographic algorithms in use within I2P, but we"
+" have\n"
+"reduced them to a bare minimum to deal with our needs - one symmetric "
+"algorithm\n"
+"one asymmetric algorithm, one signing algorithm, and one hashing "
+"algorithm.  However, \n"
+"we do combine them in some particular ways to provide message integrity "
+"(rather than\n"
+"relying on a MAC).  In addition, as much as we hate doing anything new in"
+" regards to \n"
+"cryptography, we can't seem to find a reference discussing (or even "
+"naming) the \n"
+"technique used in ElGamal/AES+SessionTag "
+"(but we're sure others have done it)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:20
+msgid "ElGamal encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:22
+msgid ""
+"\n"
+"ElGamal is used for asymmetric encryption.\n"
+"ElGamal is used in several places in I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:27
+#, python-format
+msgid ""
+"To encrypt router-to-router Tunnel Build "
+"Messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:30
+#, python-format
+msgid ""
+"For end-to-end (destination-to-destination) encryption as a part of ElGamal/AES+SessionTag\n"
+"using the encryption key in the LeaseSet"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:34
+#: i2p2www/pages/site/docs/how/cryptography.html:189
+#, python-format
+msgid ""
+"For encryption of some netDb stores and "
+"queries sent to floodfill routers\n"
+"as a part of ElGamal/AES+SessionTag\n"
+"(destination-to-router or router-to-router)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:41
+msgid ""
+"We use common primes for 2048 ElGamal encryption and decryption, as given"
+" by IETF RFC-3526.\n"
+"We currently only use ElGamal to encrypt the IV and session key in a "
+"single block, followed by the \n"
+"AES encrypted payload using that key and IV."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:47
+msgid "The unencrypted ElGamal contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:64
+msgid ""
+"The H(data) is the SHA256 of the data that is encrypted in the ElGamal "
+"block,\n"
+"and is preceded by a nonzero byte. \n"
+"This byte could be random, but as implemented it is always 0xFF.\n"
+"It could possibly be used for flags in the future.\n"
+"The data encrypted in the block may be up to 222 bytes long.\n"
+"As the encrypted data may contain a substantial number of zeros if the\n"
+"cleartext is smaller than 222 bytes, it is recommended that higher layers"
+" pad\n"
+"the cleartext to 222 bytes with random data.\n"
+"Total length: typically 255 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:76
+msgid "The encrypted ElGamal contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:102
+msgid ""
+"Each encrypted part is prepended with zeros to a size of exactly 257 "
+"bytes.\n"
+"Total length: 514 bytes.\n"
+"In typical usage, higher layers pad the cleartext data to 222 bytes,\n"
+"resulting in an unencrypted block of 255 bytes.\n"
+"This is encoded as two 256-byte encrypted parts,\n"
+"and there is a single byte of zero padding before each part at this layer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:111
+#, python-format
+msgid "See the ElGamal code."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:115
+msgid ""
+"The shared prime is the \n"
+"[Oakley prime "
+"for 2048 bit keys]"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:122
+msgid "or as a hexadecimal value:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:138
+msgid "Using 2 as the generator."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:142
+msgid "Short Exponent"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:143
+#, python-format
+msgid ""
+"While the standard exponent size is 2048 bits (256 bytes) and the I2P\n"
+"PrivateKey\n"
+"is a full 256 bytes,\n"
+"we use the short exponent size of 226 bits (28.25 bytes).\n"
+"This should be safe for use with the Oakley primes, per\n"
+"On Diffie-Hellman Key Agreement with Short Exponents "
+"- van Oorschot, Weiner\n"
+"at EuroCrypt 96, and crypto++'s "
+"benchmarks.\n"
+"Benchmarks originally at %(oldbenchmarks)s (now dead),\n"
+"rescued from the wayback machine,"
+" dated Apr 23, 2008."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:158
+#, python-format
+msgid ""
+"Also, Koshiba & Kurosawa: Short Exponent Diffie-"
+"Hellman Problems (PKC 2004, LNCS 2947, pp. 173-186)\n"
+"(full text on Google Books) apparently "
+"supports this, according to\n"
+"this sci.crypt thread.\n"
+"The remainder of the PrivateKey is padded with zeroes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:167
+#: i2p2www/pages/site/docs/how/cryptography.html:264
+#: i2p2www/pages/site/docs/how/cryptography.html:343
+#: i2p2www/pages/site/docs/how/cryptography.html:382
+msgid "Obsolescence"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:168
+msgid ""
+"The vulnerability of the network to an ElGamal attack and the impact of "
+"transitioning to a longer bit length is to be studied.\n"
+"It may be quite difficult to make any change backward-compatible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:176
+msgid "AES is used for symmetric encryption, in several cases:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:181
+msgid "For transport encryption after DH key exchange"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:185
+#, python-format
+msgid ""
+"For end-to-end (destination-to-destination) encryption as a part of ElGamal/AES+SessionTag"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:195
+#, python-format
+msgid ""
+"For encryption of periodic tunnel "
+"test messages sent from the router to itself, through its own "
+"tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:200
+#, python-format
+msgid ""
+"We use AES with 256 bit keys and 128 bit blocks in CBC mode.\n"
+"The padding used is specified in IETF RFC-2313 "
+"(PKCS#5 1.5, section 8.1 (for block type 02)).\n"
+"In this case, padding exists of pseudorandomly generated octets to match "
+"16 byte blocks.\n"
+"Specifically, see [the CBC code] and the "
+"Cryptix AES\n"
+"[implementation], as well as the padding, found"
+" in the\n"
+"ElGamalAESEngine.getPadding function."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:265
+msgid ""
+"The vulnerability of the network to an AES attack and the impact of "
+"transitioning to a longer bit length is to be studied.\n"
+"It may be quite difficult to make any change backward-compatible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:270
+#: i2p2www/pages/site/docs/how/cryptography.html:362
+#: i2p2www/pages/site/docs/how/cryptography.html:388
+#: i2p2www/pages/site/docs/how/cryptography.html:456
+#: i2p2www/pages/site/docs/how/garlic-routing.html:281
+#: i2p2www/pages/site/docs/how/peer-selection.html:296
+msgid "References"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:273
+msgid "Feb. 7, 2006 Status Notes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:280
+#, python-format
+msgid ""
+"Signatures are generated and verified with 1024 bit DSA (L=1024, N=160), "
+"as implemented in\n"
+"[DSAEngine].\n"
+"DSA was chosen because it is much faster for signatures than ElGamal."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:286
+msgid "The DSA constants"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:337
+#, python-format
+msgid ""
+"The Signing Public"
+" Key is 1024 bits.\n"
+"The Signing "
+"Private Key is 160 bits."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:344
+#, python-format
+msgid ""
+"NIST 800-57\n"
+"recommends a minimum of (L=2048, N=224) for usage beyond 2010.\n"
+"This may be mitigated somewhat by the \"cryptoperiod\", or lifespan of a "
+"given key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:350
+msgid ""
+"The prime number was chosen in 2003,\n"
+"and the person that chose the number (TheCrypto) is currently no longer "
+"an I2P developer.\n"
+"As such, we do not know if the prime chosen is a 'strong prime'.\n"
+"If a larger prime is chosen for future purposes, this should be a strong "
+"prime, and we will document the construction process."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:357
+msgid ""
+"The vulnerability of the network to a DSA attack and the impact of "
+"transitioning to longer keys is to be studied.\n"
+"It may be quite difficult to make any change backward-compatible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:365
+#: i2p2www/pages/site/docs/how/cryptography.html:367
+#, python-format
+msgid "Meeting %(num)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:369
+msgid "Choosing the constants"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:377
+#, python-format
+msgid ""
+"Hashes within I2P are plain old SHA256, as implemented in\n"
+"[SHA256Generator]"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:383
+msgid ""
+"The vulnerability of the network to a SHA-256 attack and the impact of "
+"transitioning to a longer hash is to be studied.\n"
+"It may be quite difficult to make any change backward-compatible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:395
+msgid ""
+"At the lowest protocol layer,\n"
+"point-to-point inter-router communication is protected by the transport "
+"layer security.\n"
+"Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange\n"
+"using\n"
+"the same shared prime and generator as specified "
+"above for ElGamal,\n"
+"followed by symmetric AES encryption as described above.\n"
+"This provides\n"
+"perfect "
+"forward secrecy\n"
+"on the transport links."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:407
+msgid "NTCP connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:409
+#, python-format
+msgid ""
+"NTCP connections are negotiated with a 2048 Diffie-Hellman "
+"implementation,\n"
+"using the router's identity to proceed with a station to station "
+"agreement, followed by\n"
+"some encrypted protocol specific fields, with all subsequent data "
+"encrypted with AES\n"
+"(as above).\n"
+"The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) "
+"forward secrecy', while ElGamalAES+SessionTag does not."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:417
+msgid ""
+"In order to migrate to a more standardized implementation (TLS/SSL or "
+"even SSH), the following issues must be addressed:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:421
+msgid ""
+"Can we somehow reestablish sessions securely (ala session tags) or do we "
+"need to do full negotiation each time?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:424
+msgid ""
+"Can we simplify/avoid the x509 or other certificate formats and use our "
+"own RouterInfo structure (which \n"
+"contains the ElGamal and DSA keys)?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:429
+#, python-format
+msgid "See the NTCP specification for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:433
+msgid "UDP connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:434
+msgid ""
+"SSU (the UDP transport) encrypts each packet with AES256/CBC with both an"
+" explicit IV and MAC \n"
+"(HMAC-MD5-128) after agreeing upon an ephemeral session key through a "
+"2048 bit \n"
+"Diffie-Hellman exchange, station-to-station authentication with the other"
+" \n"
+"router's DSA key, plus each network message has their own hash for local "
+"integrity \n"
+"checking."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:442
+#, python-format
+msgid "See the SSU specification for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/cryptography.html:446
+#, python-format
+msgid ""
+"WARNING - I2P's HMAC-MD5-128 used in SSU is apparently non-standard.\n"
+"Apparently, an early version of SSU used HMAC-SHA256, and then it was "
+"switched\n"
+"to MD5-128 for performance reasons, but left the 32-byte buffer size "
+"intact.\n"
+"See HMACGenerator.java and\n"
+"the 2005-07-05 status notes\n"
+"for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:2
+msgid "ElGamal/AES + SessionTag Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:3
+msgid "February 2011"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:7
+msgid "ElGamal/AES+SessionTags is used for end-to-end encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:11
+msgid ""
+"As an unreliable, unordered, message based system, I2P uses a simple "
+"combination \n"
+"of asymmetric and symmetric encryption algorithms to provide data "
+"confidentiality \n"
+"and integrity to garlic messages. As a whole, the combination is referred"
+" \n"
+"to as ElGamal/AES+SessionTags, but that is an excessively verbose way to "
+"describe \n"
+"the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:19
+#: i2p2www/pages/site/docs/how/tech-intro.html:512
+msgid ""
+"The first time a router wants to encrypt a garlic message to another "
+"router, \n"
+"they encrypt the keying material for an AES256 session key with ElGamal "
+"and \n"
+"append the AES256/CBC encrypted payload after that encrypted ElGamal "
+"block. \n"
+"In addition to the encrypted payload, the AES encrypted section contains "
+"the \n"
+"payload length, the SHA256 hash of the unencrypted payload, as well as a "
+"number \n"
+"of \"session tags\" - random 32 byte nonces. The next time the sender "
+"wants \n"
+"to encrypt a garlic message to another router, rather than ElGamal "
+"encrypt \n"
+"a new session key they simply pick one of the previously delivered "
+"session \n"
+"tags and AES encrypt the payload like before, using the session key used "
+"with \n"
+"that session tag, prepended with the session tag itself. When a router "
+"receives \n"
+"a garlic encrypted message, they check the first 32 bytes to see if it "
+"matches \n"
+"an available session tag - if it does, they simply AES decrypt the "
+"message, \n"
+"but if it does not, they ElGamal decrypt the first block."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:35
+#: i2p2www/pages/site/docs/how/tech-intro.html:528
+msgid ""
+"Each session tag can be used only once so as to prevent internal "
+"adversaries \n"
+"from unnecessarily correlating different messages as being between the "
+"same \n"
+"routers. The sender of an ElGamal/AES+SessionTag encrypted message "
+"chooses \n"
+"when and how many tags to deliver, prestocking the recipient with enough "
+"tags \n"
+"to cover a volley of messages. Garlic messages may detect the successful "
+"tag \n"
+"delivery by bundling a small additional message as a clove (a \"delivery "
+"status \n"
+"message\") - when the garlic message arrives at the intended recipient "
+"and \n"
+"is decrypted successfully, this small delivery status message is one of "
+"the \n"
+"cloves exposed and has instructions for the recipient to send the clove "
+"back \n"
+"to the original sender (through an inbound tunnel, of course). When the "
+"original \n"
+"sender receives this delivery status message, they know that the session "
+"tags \n"
+"bundled in the garlic message were successfully delivered."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:50
+msgid ""
+"Session tags themselves have a short lifetime, after which they are \n"
+"discarded if not used. In addition, the quantity stored for each key is "
+"limited, \n"
+"as are the number of keys themselves - if too many arrive, either new or "
+"old \n"
+"messages may be dropped. The sender keeps track whether messages using "
+"session \n"
+"tags are getting through, and if there isn't sufficient communication it "
+"may \n"
+"drop the ones previously assumed to be properly delivered, reverting back"
+" \n"
+"to the full expensive ElGamal encryption.\n"
+"A session will continue to exist until all its tags are exhausted or "
+"expire."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:61
+msgid ""
+"Sessions are unidirectional. Tags are delivered from Alice to Bob,\n"
+"and Alice then uses the tags, one by one, in subsequent messages to Bob."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:66
+msgid ""
+"Sessions may be established between Destinations, between Routers, or\n"
+"between a Router and a Destination.\n"
+"Each Router and Destination maintains its own Session Key Manager to\n"
+"keep track of Session Keys and Session Tags.\n"
+"Separate Session Key Managers prevents correlation of multiple "
+"Destinations\n"
+"to each other or a Router by adversaries."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:77
+msgid "Message Reception"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:78
+msgid ""
+"Each message received has one of two\n"
+"the two possible conditions:
            "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:84
+msgid ""
+"It is part of an existing session and contains a Session Tag and an AES "
+"encrypted block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:85
+msgid "It is for a new session and contains both ElGamal and AES encrypted blocks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:88
+msgid ""
+"When a router receives a message, it will first assume it is from\n"
+"an existing session and attempt to look up the Session Tag and decrypt "
+"the following data using AES.\n"
+"If that fails, it will assume it is for a new session and attempt to\n"
+"decrypt it using ElGamal."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:97
+msgid "New Session Message Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:98
+msgid ""
+"A New Session ElGamal Message contains two parts, an encrypted ElGamal "
+"block\n"
+"and an encrypted AES block."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:103
+msgid "The encrypted message contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:127
+msgid "ElGamal Block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:128
+msgid "The encrypted ElGamal Block is always 514 bytes long."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:132
+msgid "The unencrypted ElGamal data is 222 bytes long, containing:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:164
+#, python-format
+msgid ""
+"The 32-byte\n"
+"Session Key\n"
+"is the identifier for the session.\n"
+"The 32-byte Pre-IV will be used to generate the IV for the AES block that"
+" follows;\n"
+"the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:172
+#, python-format
+msgid ""
+"The 222 byte payload is encrypted\n"
+"using ElGamal\n"
+"and the encrypted block is 514 bytes long.\n"
+"
            "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:179
+msgid "AES Block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:180
+msgid "The unencrypted data in the AES block contains the following:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:224
+#, python-format
+msgid "2-byte Integer, 0-200"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:228
+#, python-format
+msgid ""
+"That many 32-byte Session Tags"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:232
+#, python-format
+msgid "4-byte Integer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:236
+#, python-format
+msgid ""
+"The 32-byte SHA256 Hash of"
+" the payload"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:240
+msgid "A one-byte value. Normally == 0. If == 0x01, a Session Key follows"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:244
+#, python-format
+msgid ""
+"A 32-byte Session "
+"Key,\n"
+"                 to replace the old key, and is only present if preceding"
+" flag is 0x01"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:249
+msgid "the data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:251
+msgid ""
+"Random data to a multiple of 16 bytes for the total length.\n"
+"         May contain more than the minimum required padding."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:256
+msgid "Minimum length: 48 bytes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:260
+#, python-format
+msgid ""
+"The data is then AES Encrypted,\n"
+"using the session key and IV (calculated from the pre-IV) from the "
+"ElGamal section.\n"
+"The encrypted AES Block length is variable but is always a multiple of 16"
+" bytes.\n"
+"
            "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:269
+#, python-format
+msgid ""
+"Actual max payload length, and max block length, is less than 64 KB; see "
+"the I2NP Overview."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:272
+msgid "New Session Key is currently unused and is never present."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:277
+msgid "Existing Session Message Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:278
+msgid ""
+"The session tags delivered successfully are remembered for a \n"
+"brief period (15 minutes currently) until they are used or discarded.\n"
+"A tag is used by packaging one in an Existing Session Message that\n"
+"contains only an AES encrypted block, and is not preceded by an\n"
+"ElGamal block."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:286
+msgid ""
+"The existing session message is\n"
+"as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:309
+#, python-format
+msgid ""
+"A 32-byte Session "
+"Tag\n"
+"             previously delivered in an AES block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:314
+msgid "As specified above."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:318
+msgid ""
+"The session tag also serves as\n"
+"the pre-IV. The IV is the first 16 bytes of the SHA-256 Hash of the "
+"sessionTag."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:323
+msgid ""
+"To decode a message from an existing session, a router looks up the "
+"Session Tag to find an\n"
+"associated Session Key. If the Session Tag is found, the AES block is "
+"decrypted using the associated Session Key.\n"
+"If the tag is not found, the message is assumed to be a New Session Message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:332
+msgid ""
+"There are many possible areas to tune the Session Key Manager's "
+"algorithms;\n"
+"some may interact with the streaming library behavior, or have "
+"significant\n"
+"impact on overall performance."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:338
+msgid ""
+"Delivery of too many tags at one time may impose substantial overhead for"
+" brief streaming connections\n"
+"or datagrams, and increase the chance of message loss.\n"
+"We currently deliver 40 tags at a time (1280 bytes).\n"
+"32 (1024 bytes) may be better for tunnel fragmentation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:345
+msgid ""
+"A few tags could be delivered in each of several messages, or lots of "
+"tags all at once."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:349
+msgid ""
+"It is also important to study and tune\n"
+"the low-tag thresholds at which more tags are sent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:354
+msgid ""
+"The number of tags delivered could depend on message size, keeping in "
+"mind\n"
+"the eventual padding to 1KB at the tunnel message layer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:359
+msgid ""
+"Clients could send an estimate of session lifetime to the router, as an "
+"advisory\n"
+"on the number of tags required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:364
+msgid ""
+"Delivery of too few tags causes the router to fall back to an expensive "
+"ElGamal encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:368
+msgid ""
+"The router may assume delivery of Session Tags, or await acknowledgement "
+"before using them;\n"
+"there are tradeoffs for each strategy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:373
+msgid ""
+"For very brief messages, almost the full 222 bytes of the pre-IV and "
+"padding fields in the ElGamal block\n"
+"could be used for the entire message, instead of establishing a session."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:378
+msgid ""
+"Evaluate padding strategy; currently we pad to a minimum of 128 bytes.\n"
+"Would be better to add a few tags to small messages than pad."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:383
+msgid ""
+"Perhaps things could be more efficient if the Session Tag system was "
+"bidirectional,\n"
+"so tags delivered in the 'forward' path could be used in the 'reverse' "
+"path,\n"
+"thus avoiding ElGamal in the initial response.\n"
+"The router currently plays some tricks like this when sending\n"
+"tunnel test messages to itself."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:391
+#, python-format
+msgid ""
+"Change from Session Tags to\n"
+"a synchronized PRNG."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/elgamal-aes.html:396
+#, python-format
+msgid ""
+"Several of these ideas may require a new I2NP message type, or\n"
+"set a flag in the\n"
+"Delivery Instructions,\n"
+"or set a magic number in the first few bytes of the Session Key field\n"
+"and accept a small risk of the random Session Key matching the magic "
+"number."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:2
+msgid "Garlic Routing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:6
+msgid "Garlic Routing and \"Garlic\" Terminology"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:7
+msgid ""
+"The terms \"garlic routing\" and \"garlic encryption\" are often used "
+"rather loosely when referring to I2P's technology.\n"
+"Here, we explain the history of the terms, the various meanings, and\n"
+"the usage of \"garlic\" methods in I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:13
+msgid ""
+"\"Garlic routing\" was first coined by\n"
+"Michael J. Freedman\n"
+"in Roger Dingledine's Free Haven \n"
+"Master's thesis "
+"Section 8.1.1 (June 2000), as derived from \n"
+"Onion Routing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:21
+msgid ""
+"\"Garlic\" may have been used originally by I2P developers because I2P "
+"implements a form of\n"
+"bundling as Freedman describes, or simply to emphasize general "
+"differences from Tor.\n"
+"The specific reasoning may be lost to history.\n"
+"Generally, when referring to I2P, the term \"garlic\" may mean one of "
+"three things:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:28
+#: i2p2www/pages/site/docs/how/garlic-routing.html:39
+msgid "Layered Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:29
+msgid "Bundling multiple messages together"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:30
+#: i2p2www/pages/site/docs/how/garlic-routing.html:96
+msgid "ElGamal/AES Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:33
+msgid ""
+"Unfortunately, I2P's usage of \"garlic\" terminology over the past seven "
+"years has not always been precise; therefore the reader is\n"
+"cautioned when encountering the term.\n"
+"Hopefully, the explanation below will make things clear."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:40
+msgid ""
+"Onion routing is a technique for building paths, or tunnels, through a "
+"series of peers,\n"
+"and then using that tunnel.\n"
+"Messages are repeatedly encrypted by the originator, and then decrypted "
+"by each hop.\n"
+"During the building phase, only the routing instructions for the next hop"
+" are exposed to each peer.\n"
+"During the operating phase, messages are passed through the tunnel, and "
+"the\n"
+"message and its routing instructions are only exposed to the endpoint of "
+"the tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:49
+#, python-format
+msgid ""
+"This is similar to the way Mixmaster\n"
+"(see network comparisons) sends messages "
+"- taking a message, encrypting it\n"
+"to the recipient's public key, taking that encrypted message and "
+"encrypting\n"
+"it (along with instructions specifying the next hop), and then taking "
+"that\n"
+"resulting encrypted message and so on, until it has one layer of "
+"encryption\n"
+"per hop along the path."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:58
+msgid ""
+"In this sense, \"garlic routing\" as a general concept is identical to "
+"\"onion routing\".\n"
+"As implemented in I2P, of course, there are several differences from the "
+"implementation in Tor; see below.\n"
+"Even so, there are substantial similarities such that I2P benefits from a"
+"\n"
+"large amount of"
+" academic research on onion routing,\n"
+"Tor, and similar "
+"mixnets."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:67
+msgid "Bundling Multiple Messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:68
+msgid ""
+"Michael Freedman defined \"garlic routing\" as an extension to onion "
+"routing,\n"
+"in which multiple messages are bundled together.\n"
+"He called each message a \"bulb\".\n"
+"All the messages, each with its own delivery instructions, are exposed at"
+" the\n"
+"endpoint.\n"
+"This allows the efficient bundling of an onion routing \"reply block\" "
+"with the original message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:77
+msgid ""
+"This concept is implemented in I2P, as described below.\n"
+"Our term for garlic \"bulbs\" is \"cloves\".\n"
+"Any number of messages can be\n"
+"contained, instead of just a single message.\n"
+"This is a significant distinction from the onion routing implemented in "
+"Tor.\n"
+"However, it is only one of many major architectural differences between "
+"I2P and Tor;\n"
+"perhaps it is not, by itself, enough to justify a change in terminology."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:87
+msgid ""
+"Another difference\n"
+"from the method described by Freedman\n"
+"is that the path is unidirectional - there is no \"turning point\" as "
+"seen in onion routing\n"
+"or mixmaster reply blocks, which greatly simplifies the algorithm and "
+"allows for more flexible\n"
+"and reliable delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:97
+#, python-format
+msgid ""
+"In some cases, \"garlic encryption\" may simply mean\n"
+"ElGamal/AES+SessionTag encryption\n"
+"(without multiple layers)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:105
+msgid "\"Garlic\" Methods in I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:106
+msgid ""
+"Now that we've defined various \"garlic\" terms, we can say that\n"
+"I2P uses garlic routing, bundling and encryption in three places:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:111
+msgid "For building and routing through tunnels (layered encryption)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:112
+msgid ""
+"For determining the success or failure of end to end message delivery "
+"(bundling)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:113
+msgid ""
+"For publishing some network database entries (dampening the probability "
+"of a successful traffic analysis attack) (ElGamal/AES)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:116
+msgid ""
+"There are also significant ways that this technique can be used to "
+"improve the performance of the network, \n"
+"exploiting transport latency/throughput tradeoffs, and branching data "
+"through redundant paths to increase reliability."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:122
+msgid "Tunnel Building and Routing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:123
+msgid ""
+"In I2P, tunnels are unidirectional. Each party builds two tunnels,\n"
+"one for outbound and one for inbound traffic.\n"
+"Therefore, four tunnels are required for a single round-trip message and "
+"reply."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:129
+#, python-format
+msgid ""
+"Tunnels are built, and then used, with layered encryption.\n"
+"This is described on the\n"
+"tunnel implementation page.\n"
+"Tunnel building details are defined on\n"
+"this page.\n"
+"We use\n"
+"ElGamal/AES+SessionTag for the encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:141
+#, python-format
+msgid ""
+"Tunnels are a general-purpose mechanism to transport all\n"
+"I2NP messages, and\n"
+"Garlic Messages are not used to "
+"build tunnels.\n"
+"We do not bundle multiple\n"
+"I2NP messages into a single\n"
+"Garlic Message for unwrapping at "
+"the outbound tunnel endpoint;\n"
+"the tunnel encryption is sufficient."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:152
+msgid "End-to-End Message Bundling"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:153
+#, python-format
+msgid ""
+"At the layer above tunnels, I2P delivers end-to-end messages between\n"
+"Destinations.\n"
+"Just as within a single tunnel, we use\n"
+"ElGamal/AES+SessionTag for the encryption."
+"\n"
+"Each client message as delivered to the router through the\n"
+"I2CP interface becomes a single\n"
+"Garlic Clove\n"
+"with its own\n"
+"Delivery Instructions,\n"
+"inside a\n"
+"Garlic Message.\n"
+"Delivery Instructions may specify a Destination, Router, or Tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:172
+msgid ""
+"Generally, a Garlic Message will contain only one clove.\n"
+"However, the router will periodically bundle two additional\n"
+"cloves in the Garlic Message:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:177
+msgid "Garlic Message Cloves"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:180
+#, python-format
+msgid ""
+"A\n"
+"Delivery Status Message,\n"
+"with\n"
+"Delivery Instructions\n"
+"specifying that it be sent back to the originating router as an "
+"acknowledgment.\n"
+"This is similar to the \"reply block\" or \"reply onion\"\n"
+"described in the references.\n"
+"It is used for determining the success or failure of end to end message "
+"delivery.\n"
+"The originating router may, upon failure to receive the Delivery Status "
+"Message\n"
+"within the expected time period, modify the routing to the far-end "
+"Destination,\n"
+"or take other actions."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:194
+#, python-format
+msgid ""
+"A\n"
+"Database Store Message,\n"
+"containing a\n"
+"LeaseSet\n"
+"for the originating Destination, with\n"
+"Delivery Instructions\n"
+"specifying the far-end destination's router.\n"
+"By periodically bundling a LeaseSet, the router ensures that the far-end "
+"will be able\n"
+"to maintain communications.\n"
+"Otherwise the far-end would have to query a floodfill router for the "
+"network database entry,\n"
+"and all LeaseSets would have to be published to the network database, as "
+"explained on the\n"
+"network database page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:213
+#, python-format
+msgid ""
+"In the current implementation, the Delivery Status and Database Store "
+"Messages\n"
+"are bundled when the local LeaseSet changes, when additional\n"
+"Session Tags\n"
+"are delivered, or if the messages have not been bundled in the previous "
+"minute."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:220
+msgid ""
+"Obviously, the additional messages are currently bundled for specific "
+"purposes,\n"
+"and not part of a general-purpose routing scheme."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:226
+msgid "Storage to the Floodfill Network Database"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:227
+#, python-format
+msgid ""
+"As explained on the\n"
+"network database page,\n"
+"local\n"
+"LeaseSets\n"
+"are sent to floodfill routers in a\n"
+"Database Store Message\n"
+"wrapped in a\n"
+"Garlic Message\n"
+"so it is not visible to the tunnel's outbound gateway."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:243
+#, python-format
+msgid ""
+"The Garlic Message mechanism is very flexible and provides a structure "
+"for\n"
+"implementing many types of mixnet delivery methods.\n"
+"Together with the unused delay option in the\n"
+"tunnel message Delivery "
+"Instructions,\n"
+"a wide spectrum of batching, delay, mixing, and routing strategies are "
+"possible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:251
+msgid ""
+"In particular, there is potential for much more flexibility at the "
+"outbound tunnel endpoint.\n"
+"Messages could possibly be routed from there to one of several tunnels\n"
+"(thus minimizing point-to-point connections), or multicast to several "
+"tunnels\n"
+"for redundancy, or streaming audio and video."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:258
+msgid ""
+"Such experiments may conflict with the need to ensure security and "
+"anonymity, such\n"
+"as limiting certain routing paths, restricting the types of I2NP messages"
+" that may\n"
+"be forwarded along various paths, and enforcing certain message "
+"expiration times."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:264
+#, python-format
+msgid ""
+"As a part of\n"
+"ElGamal/AES encryption,\n"
+"a garlic message contains a sender\n"
+"specified amount of padding data, allowing the sender to take active "
+"countermeasures \n"
+"against traffic analysis.\n"
+"This is not currently used, beyond the requirement to pad to a multiple "
+"of 16 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:273
+#, python-format
+msgid ""
+"Encryption of additional messages to and from the\n"
+"floodfill routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:283
+msgid ""
+"The term garlic routing was first coined in Roger Dingledine's Free Haven"
+" \n"
+"Master's thesis "
+"(June 2000),\n"
+"see Section 8.1.1 authored by\n"
+"Michael J. Freedman."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:290
+msgid "Onion router publications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:292
+msgid "Onion Routing on Wikipedia"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:294
+msgid "Garlic Routing on Wikipedia"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:296
+#, python-format
+msgid ""
+"I2P Meeting 58 (2003) discussing the "
+"implementation of garlic routing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:302
+msgid "Free Haven publications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/garlic-routing.html:304
+msgid ""
+"Onion routing was first described in Hiding Routing Information\n"
+"by David M. Goldschlag, Michael G. Reed, and Paul F. Syverson in 1996."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:2
+msgid "A Gentle Introduction"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:5
+msgid "A Gentle Introduction to How I2P Works"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:7
+msgid ""
+"I2P is a project to build, deploy, and maintain a network supporting "
+"secure and anonymous\n"
+"communication. People using I2P are in control of the tradeoffs between "
+"anonymity, reliability,\n"
+"bandwidth usage, and latency. There is no central point in the network on"
+" which pressure can be\n"
+"exerted to compromise the integrity, security, or anonymity of the "
+"system. The network supports\n"
+"dynamic reconfiguration in response to various attacks, and has been "
+"designed to make use of\n"
+"additional resources as they become available. Of course, all aspects of "
+"the network are open and\n"
+"freely available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:17
+msgid ""
+"Unlike many other anonymizing networks, I2P doesn't try to provide "
+"anonymity by hiding the\n"
+"originator of some communication and not the recipient, or the other way "
+"around. I2P is designed to\n"
+"allow peers using I2P to communicate with each other anonymously — "
+"both sender and recipient\n"
+"are unidentifiable to each other as well as to third parties. For "
+"example, today there are both\n"
+"in-I2P web sites (allowing anonymous publishing / hosting) as well as "
+"HTTP proxies to the normal web\n"
+"(allowing anonymous web browsing). Having the ability to run servers "
+"within I2P is essential, as it\n"
+"is quite likely that any outbound proxies to the normal Internet will be "
+"monitored, disabled, or\n"
+"even taken over to attempt more malicious attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:28
+#, python-format
+msgid ""
+"The network itself is message oriented - it is essentially a secure and "
+"anonymous IP layer, where\n"
+"messages are addressed to cryptographic keys (Destinations) and can be "
+"significantly larger than IP\n"
+"packets. Some example uses of the network include \"eepsites\" "
+"(webservers hosting normal web\n"
+"applications within I2P), a BitTorrent client (\"I2PSnark\"), or a "
+"distributed data store. With the\n"
+"help of the I2PTunnel application, we are "
+"able to stream traditional\n"
+"TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and even "
+"streaming audio. Most people\n"
+"will not use I2P directly, or even need to know they're using it. Instead"
+" their view will be of one\n"
+"of the I2P enabled applications, or perhaps as a little controller app to"
+" turn on and off various\n"
+"proxies to enable the anonymizing functionality."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:40
+#, python-format
+msgid ""
+"An essential part of designing, developing, and testing an anonymizing "
+"network is to define the threat model, since there is no such thing "
+"as \"true\" anonymity, just\n"
+"increasingly expensive costs to identify someone. Briefly, I2P's intent "
+"is to allow people to\n"
+"communicate in arbitrarily hostile environments by providing good "
+"anonymity, mixed in with\n"
+"sufficient cover traffic provided by the activity of people who require "
+"less anonymity. This way,\n"
+"some users can avoid detection by a very powerful adversary, while others"
+" will try to evade a weaker\n"
+"entity, all on the same network, where each one's messages are "
+"essentially indistinguishable\n"
+"from the others."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:51
+msgid "Why?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:52
+#, python-format
+msgid ""
+"There are a multitude of reasons why we need a system to support "
+"anonymous communication, and\n"
+"everyone has their own personal rationale. There are many other\n"
+"efforts working on finding ways to provide varying degrees of "
+"anonymity to people through the\n"
+"Internet, but we could not find any that met our needs or threat model."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:59
+msgid "How?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:61
+#, python-format
+msgid ""
+"The network at a glance is made up of a set of nodes (\"routers\") with a"
+" number of unidirectional\n"
+"inbound and outbound virtual paths (\"tunnels\", as outlined on the tunnel routing page). Each router is "
+"identified by a cryptographic RouterIdentity which is\n"
+"typically long lived. These routers communicate with each other through "
+"existing transport\n"
+"mechanisms (TCP, UDP, etc), passing various messages. Client applications"
+" have their own\n"
+"cryptographic identifier (\"Destination\") which enables it to send and "
+"receive messages. These\n"
+"clients can connect to any router and authorize the temporary allocation "
+"(\"lease\") of some tunnels\n"
+"that will be used for sending and receiving messages through the network."
+" I2P has its own internal\n"
+"network database (using a modification of the "
+"Kademlia algorithm) for\n"
+"distributing routing and contact information securely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:74
+msgid "Network topology example"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:76
+msgid ""
+"In the above, Alice, Bob, Charlie, and Dave are all running routers with "
+"a single Destination on\n"
+"their local router. They each have a pair of 2-hop inbound tunnels per "
+"destination (labeled 1, 2, 3,\n"
+"4, 5 and 6), and a small subset of each of those router's outbound tunnel"
+" pool is shown with 2-hop\n"
+"outbound tunnels. For simplicity, Charlie's inbound tunnels and Dave's "
+"outbound tunnels are not\n"
+"shown, nor are the rest of each router's outbound tunnel pool (typically "
+"stocked with a few tunnels\n"
+"at a time). When Alice and Bob talk to each other, Alice sends a message "
+"out one of her (pink)\n"
+"outbound tunnels targeting one of Bob's (green) inbound tunnels (tunnel 3"
+" or 4). She knows to send\n"
+"to those tunnels on the correct router by querying the network database, "
+"which is constantly updated\n"
+"as new leases are authorized and old ones expire."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:88
+#, python-format
+msgid ""
+"If Bob wants to reply to Alice, he simply goes through the same process -"
+" send a message out one of\n"
+"his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 "
+"or 2). To make things\n"
+"easier, most messages sent between Alice and Bob are garlic\n"
+"wrapped, bundling the sender's own current lease information so that the "
+"recipient can reply\n"
+"immediately without having to look in the network database for the "
+"current data."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:96
+#, python-format
+msgid ""
+"To deal with a wide range of attacks, I2P is fully distributed with no "
+"centralized resources - and\n"
+"hence there are no directory servers keeping statistics regarding the "
+"performance and reliability of\n"
+"routers within the network. As such, each router must keep and maintain "
+"profiles of various routers\n"
+"and is responsible for selecting appropriate peers to meet the anonymity,"
+" performance, and\n"
+"reliability needs of the users, as described in the peer selection\n"
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:105
+#, python-format
+msgid ""
+"The network itself makes use of a significant number of cryptographic\n"
+"techniques and algorithms - a full laundry list includes 2048bit "
+"ElGamal encryption, 256bit AES\n"
+"in CBC mode with PKCS#5 padding, 1024bit DSA signatures, SHA256 hashes, "
+"2048bit Diffie-Hellman\n"
+"negotiated connections with station to station authentication, and ElGamal / AES+SessionTag."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:113
+msgid ""
+"Content sent over I2P is encrypted through three layers garlic encryption"
+" (used to verify the\n"
+"delivery of the message to the recipient), tunnel encryption (all "
+"messages passing through a tunnel\n"
+"is encrypted by the tunnel gateway to the tunnel endpoint), and inter "
+"router transport layer\n"
+"encryption (e.g. the TCP transport uses AES256 with ephemeral keys)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:120
+msgid ""
+"End-to-end (I2CP) encryption (client application to server application) "
+"was disabled in I2P release\n"
+"0.6; end-to-end (garlic) encryption (I2P client router to I2P server "
+"router) from Alice's router \"a\"\n"
+"to Bob's router \"h\" remains. Notice the different use of terms! All "
+"data from a to h is end-to-end\n"
+"encrypted, but the I2CP connection between the I2P router and the "
+"applications is not end-to-end\n"
+"encrypted! A and h are the routers of Alice and Bob, while Alice and Bob "
+"in following chart are the\n"
+"applications running atop of I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:129
+msgid "End to end layered encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:131
+#, python-format
+msgid ""
+"The specific use of these algorithms are outlined elsewhere."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:135
+msgid ""
+"The two main mechanisms for allowing people who need strong anonymity to "
+"use the network are\n"
+"explicitly delayed garlic routed messages and more comprehensive tunnels "
+"to include support for\n"
+"pooling and mixing messages. These are currently planned for release 3.0,"
+" but garlic routed messages\n"
+"with no delays and FIFO tunnels are currently in place. Additionally, the"
+" 2.0 release will allow\n"
+"people to set up and operate behind restricted routes (perhaps with "
+"trusted peers), as well as the\n"
+"deployment of more flexible and anonymous transports."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:144
+#, python-format
+msgid ""
+"Some questions have been raised with regards to the scalability of I2P, "
+"and reasonably so. There\n"
+"will certainly be more analysis over time, but peer lookup and "
+"integration should be bounded by\n"
+"O(log(N)) due to the network "
+"database's algorithm, while end\n"
+"to end messages should be O(1) (scale free), since messages "
+"go out K hops through the\n"
+"outbound tunnel and another K hops through the inbound tunnel, with K no "
+"longer than 3. The size of\n"
+"the network (N) bears no impact."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:153
+msgid "When?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:154
+#, python-format
+msgid ""
+"I2P initially began in Feb 2003 as a proposed modification to Freenet to allow it to use "
+"alternate transports, such as JMS, then grew into its own as an\n"
+"'anonCommFramework' in April 2003, turning into I2P in July, with code "
+"being written in earnest\n"
+"starting in August '03. I2P is currently under development, following the"
+" roadmap."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:164
+msgid "Who?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:165
+#, python-format
+msgid ""
+"We have a small team spread around several "
+"continents, working to advance\n"
+"different aspects of the project. We are very open to other developers "
+"who want to get involved and\n"
+"anyone else who would like to contribute in other ways, such as "
+"critiques, peer review, testing,\n"
+"writing I2P enabled applications, or documentation. The entire system is "
+"open source - the router\n"
+"and most of the SDK are outright public domain with some BSD and Cryptix "
+"licensed code, while some\n"
+"applications like I2PTunnel and I2PSnark are GPL. Almost everything is "
+"written in Java (1.5+),\n"
+"though some third party applications are being written in Python and "
+"other languages. The code works\n"
+"on Sun Java SE and other Java Virtual"
+" Machines."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:176
+msgid "Where?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:177
+#, python-format
+msgid ""
+"Anyone interested should join us on the IRC channel #i2p (hosted "
+"concurrently on irc.freenode.net,\n"
+"irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and "
+"irc.einirc.de). There are currently no\n"
+"scheduled development meetings, however archives"
+" are available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:183
+#, python-format
+msgid "The current source is available in monotone."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/intro.html:188
+#, python-format
+msgid "See the Index to Technical Documentation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:2
+msgid "The Network Database"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:8
+msgid ""
+"I2P's netDb is a specialized distributed database, containing \n"
+"just two types of data - router contact information (RouterInfos) "
+"and destination contact\n"
+"information (LeaseSets). Each piece of data is signed by the "
+"appropriate party and verified\n"
+"by anyone who uses or stores it. In addition, the data has liveliness "
+"information\n"
+"within it, allowing irrelevant entries to be dropped, newer entries to "
+"replace\n"
+"older ones, and protection against certain classes of attack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:17
+msgid ""
+"The netDb is distributed with a simple technique called \"floodfill\",\n"
+"where a subset of all routers, called \"floodfill routers\", maintains "
+"the distributed database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:25
+msgid ""
+"When an I2P router wants to contact another router, they need to know "
+"some \n"
+"key pieces of data - all of which are bundled up and signed by the router"
+" into\n"
+"a structure called the \"RouterInfo\", which is distributed with the "
+"SHA256 of the router's identity\n"
+"as the key. The structure itself contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:32
+msgid ""
+"The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA "
+"signing key, and a certificate)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:33
+msgid ""
+"The contact addresses at which it can be reached (e.g. TCP: example.org "
+"port 4108)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:34
+msgid "When this was published"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:35
+msgid "A set of arbitrary text options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:36
+msgid "The signature of the above, generated by the identity's DSA signing key"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:39
+msgid ""
+"The following text options, while not strictly required, are expected\n"
+"to be present:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:45
+msgid ""
+"Capabilities flags - used to indicate floodfill participation, "
+"approximate bandwidth, and perceived reachability"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:48
+msgid "The core library version, always the same as the router version"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:51
+msgid ""
+"Basic network compatibility - A router will refuse to communicate with a "
+"peer having a different netId"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:54
+msgid "Used to determine compatibility with newer features and messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:57
+msgid ""
+"Always sent as 90m, for compatibility with an older scheme where routers "
+"published their actual uptime,\n"
+"and only sent tunnel requests to peers whose was more than 60m"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:62
+msgid ""
+"These values are used by other routers for basic decisions.\n"
+"Should we connect to this router? Should we attempt to route a tunnel "
+"through this router?\n"
+"The bandwidth capability flag, in particular, is used only to determine "
+"whether\n"
+"the router meets a minimum threshold for routing tunnels.\n"
+"Above the minimum threshold, the advertised bandwidth is not used or "
+"trusted anywhere\n"
+"in the router, except for display in the user interface and for debugging"
+" and network analysis."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:72
+#, python-format
+msgid ""
+"Additional text options include\n"
+"a small number of statistics about the router's health, which are "
+"aggregated by\n"
+"sites such as %(stats)s\n"
+"for network performance analysis and debugging.\n"
+"These statistics were chosen to provide data crucial to the developers,\n"
+"such as tunnel build success rates, while balancing the need for such "
+"data\n"
+"with the side-effects that could result from revealing this data.\n"
+"Current statistics are limited to:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:83
+msgid "Client and exploratory tunnel build success, reject, and timeout rates"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:84
+msgid "1 hour average number of participating tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:87
+msgid ""
+"The data published can be seen in the router's user interface,\n"
+"but is not used or trusted within the router.\n"
+"As the network has matured, we have gradually removed most of the "
+"published\n"
+"statistics to improve anonymity, and we plan to remove more in future "
+"releases."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:95
+msgid "RouterInfo specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:98
+msgid "RouterInfo Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:101
+msgid "RouterInfo Expiration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:102
+msgid ""
+"RouterInfos have no set expiration time.\n"
+"Each router is free to maintain its own local policy to trade off the "
+"frequency of RouterInfo lookups\n"
+"with memory or disk usage.\n"
+"In the current implementation, there are the following general policies:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:109
+msgid ""
+"There is no expiration during the first hour of uptime, as the persistent"
+" stored data may be old."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:112
+msgid "There is no expiration if there are 25 or less RouterInfos."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:115
+msgid ""
+"As the number of local RouterInfos grows, the expiration time shrinks, in"
+" an attempt to maintain\n"
+"a reasonable number RouterInfos. The expiration time with less than 120 "
+"routers is 72 hours,\n"
+"while expiration time with 300 routers is around 30 hours."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:120
+#, python-format
+msgid ""
+"RouterInfos containing SSU introducers expire in "
+"about an hour, as\n"
+"the introducer list expires in about that time."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:124
+msgid ""
+"Floodfills use a short expiration time (1 hour) for all local "
+"RouterInfos, as valid RouterInfos will\n"
+"be frequently republished to them."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:130
+msgid "RouterInfo Persistent Storage"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:132
+msgid ""
+"RouterInfos are periodically written to disk so that they are available "
+"after a restart."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:139
+msgid ""
+"The second piece of data distributed in the netDb is a \"LeaseSet\" - "
+"documenting\n"
+"a group of tunnel entry points (leases) for a particular client "
+"destination.\n"
+"Each of these leases specify the following information:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:145
+msgid "The tunnel gateway router (by specifying its identity)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:146
+msgid "The tunnel ID on that router to send messages with (a 4 byte number)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:147
+msgid "When that tunnel will expire."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:149
+msgid ""
+"The LeaseSet itself is stored in the netDb under\n"
+"the key derived from the SHA256 of the destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:154
+msgid "In addition to these leases, the LeaseSet includes:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:158
+msgid ""
+"The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA "
+"signing key and a certificate)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:159
+msgid ""
+"Additional encryption public key: used for end-to-end encryption of "
+"garlic messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:160
+msgid ""
+"Additional signing public key: intended for LeaseSet revocation, but is "
+"currently unused."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:161
+msgid ""
+"Signature of all the LeaseSet data, to make sure the Destination "
+"published the LeaseSet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:165
+msgid "Lease specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:167
+msgid "LeaseSet specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:170
+msgid "Lease Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:172
+msgid "LeaseSet Javadoc"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:176
+msgid "Unpublished LeaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:177
+msgid ""
+"A LeaseSet for a destination used only for outgoing connections is "
+"unpublished.\n"
+"It is never sent for publication to a floodfill router.\n"
+"\"Client\" tunnels, such as those for web browsing and IRC clients, are "
+"unpublished.\n"
+"Servers will still be able to send messages back to those unpublished "
+"destinations,\n"
+"because of I2NP storage messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:187
+msgid "Revoked LeaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:188
+msgid ""
+"A LeaseSet may be revoked by publishing a new LeaseSet with zero "
+"leases.\n"
+"Revocations must be signed by the additional signing key in the LeaseSet."
+"\n"
+"Revocations are not fully implemented, and it is unclear if they have any"
+" practical use.\n"
+"This is the only planned use for that signing key, so it is currently "
+"unused."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:195
+msgid "Encrypted LeaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:196
+msgid ""
+"In an encrypted LeaseSet, all Leases are encrypted with a separate"
+" DSA key.\n"
+"The leases may only be decoded, and thus the destination may only be "
+"contacted,\n"
+"by those with the key.\n"
+"There is no flag or other direct indication that the LeaseSet is "
+"encrypted.\n"
+"Encrypted LeaseSets are not widely used, and it is a topic for future "
+"work to\n"
+"research whether the user interface and implementation of encrypted "
+"LeaseSets could be improved."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:205
+msgid "LeaseSet Expiration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:206
+msgid ""
+"All Leases (tunnels) are valid for 10 minutes; therefore, a LeaseSet "
+"expires\n"
+"10 minutes after the earliest creation time of all its Leases."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:211
+msgid "LeaseSet Persistent Storage"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:212
+msgid ""
+"There is no persistent storage of LeaseSet data since they expire so "
+"quickly."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:217
+msgid "Bootstrapping"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:218
+msgid ""
+"The netDb is decentralized, however you do need at\n"
+"least one reference to a peer so that the integration process\n"
+"ties you in. This is accomplished by \"reseeding\" your router with the "
+"RouterInfo\n"
+"of an active peer - specifically, by retrieving their "
+"routerInfo-$hash.dat\n"
+"file and storing it in your netDb/ directory. Anyone can "
+"provide\n"
+"you with those files - you can even provide them to others by exposing "
+"your own\n"
+"netDb directory. To simplify the process,\n"
+"volunteers publish their netDb directories (or a subset) on the regular "
+"(non-i2p) network,\n"
+"and the URLs of these directories are hardcoded in I2P.\n"
+"When the router starts up for the first time, it automatically fetches "
+"from\n"
+"one of these URLs, selected at random."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:232
+msgid "Floodfill"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:233
+msgid ""
+"The floodfill netDb is a simple distributed storage mechanism.\n"
+"The storage algorithm is simple: send the data to the closest peer that "
+"has advertised itself\n"
+"as a floodfill router. Then wait 10 seconds, pick another floodfill "
+"router and ask them \n"
+"for the entry to be sent, verifying its proper insertion / distribution. "
+"If the \n"
+"verification peer doesn't reply, or they don't have the entry, the sender"
+" \n"
+"repeats the process. When the peer in the floodfill netDb receives a "
+"netDb \n"
+"store from a peer not in the floodfill netDb, they send it to a subset of"
+" the floodfill netDb-peers.\n"
+"The peers selected are the ones closest (according to the XOR-metric) to a specific key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:244
+msgid ""
+"Determining who is part of the floodfill netDb is trivial - it is exposed"
+" in each \n"
+"router's published routerInfo as a capability."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:249
+msgid ""
+"Floodfills have no central authority and do not form a \"consensus\" -\n"
+"they only implement a simple DHT overlay."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:256
+msgid "Floodfill Router Opt-in"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:258
+msgid ""
+"Unlike Tor, where the directory servers are hardcoded and trusted,\n"
+"and operated by known entities,\n"
+"the members of the I2P floodfill peer set need not be trusted, and\n"
+"change over time."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:265
+msgid ""
+"To increase reliability of the netDb, and minimize the impact\n"
+"of netDb traffic on a router, floodfill is automatically enabled\n"
+"only on routers that are configured with high bandwidth limits.\n"
+"Routers with high bandwidth limits (which must be manually configured,\n"
+"as the default is much lower) are presumed to be on lower-latency\n"
+"connections, and are more likely to be available 24/7.\n"
+"The current minimum share bandwidth for a floodfill router is 128 "
+"KBytes/sec."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:275
+msgid ""
+"In addition, a router must pass several additional tests for health\n"
+"(outbound message queue time, job lag, etc.) before floodfill operation "
+"is\n"
+"automatically enabled."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:281
+#, python-format
+msgid ""
+"With the current rules for automatic opt-in, approximately 6% of\n"
+"the routers in the network are floodfill routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:286
+msgid ""
+"While some peers are manually configured to be floodfill,\n"
+"others are simply high-bandwidth routers who automatically volunteer\n"
+"when the number of floodfill peers drops below a threshold.\n"
+"This prevents any long-term network damage from losing most or all\n"
+"floodfills to an attack.\n"
+"In turn, these peers will un-floodfill themselves when there are\n"
+"too many floodfills outstanding."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:296
+msgid "Floodfill Router Roles"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:297
+msgid ""
+"A floodfill router's only services that are in addition to those of non-"
+"floodfill routers\n"
+"are in accepting netDb stores and responding to netDb queries.\n"
+"Since they are generally high-bandwidth, they are more likely to "
+"participate in a high number of tunnels\n"
+"(i.e. be a \"relay\" for others), but this is not directly related to "
+"their distributed database services."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:305
+msgid "Kademlia Closeness Metric"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:306
+msgid ""
+"The netDb uses a simple Kademlia-style XOR metric to determine closeness."
+"\n"
+"The SHA256 hash of the key being looked up or stored is XOR-ed with\n"
+"the hash of the router in question to determine closeness.\n"
+"A modification to this algorithm is done to increase the costs of Sybil attacks.\n"
+"Instead of the SHA256 hash of the key being looked up of stored, the "
+"SHA256 hash is taken\n"
+"of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:317
+msgid "Storage, Verification, and Lookup Mechanics"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:319
+msgid "RouterInfo Storage to Peers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:320
+#, python-format
+msgid ""
+"I2NP DatabaseStoreMessages containing the local "
+"RouterInfo are exchanged with peers\n"
+"as a part of the initialization of a NTCP\n"
+"or SSU transport connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:327
+msgid "LeaseSet Storage to Peers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:328
+#, python-format
+msgid ""
+"I2NP DatabaseStoreMessages containing the local "
+"LeaseSet are periodically exchanged with peers\n"
+"by bundling them in a garlic message along with normal traffic from the "
+"related Destination.\n"
+"This allows an initial response, and later responses, to be sent to an "
+"appropriate Lease,\n"
+"without requiring any LeaseSet lookups, or requiring the communicating "
+"Destinations to have published LeaseSets at all."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:336
+msgid "RouterInfo Storage to Floodfills"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:337
+#, python-format
+msgid ""
+"A router publishes its own RouterInfo by directly connecting to a "
+"floodfill router\n"
+"and sending it a I2NP DatabaseStoreMessage\n"
+"with a nonzero Reply Token. The message is not end-to-end garlic "
+"encrypted,\n"
+"as this is a direct connection, so there are no intervening routers\n"
+"(and no need to hide this data anyway).\n"
+"The floodfill router replies with a\n"
+"I2NP DeliveryStatusMessage,\n"
+"with the Message ID set to the value of the Reply Token."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:351
+msgid "LeaseSet Storage to Floodfills"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:352
+msgid ""
+"Storage of LeaseSets is much more sensitive than for RouterInfos, as a "
+"router\n"
+"must take care that the LeaseSet cannot be associated with the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:357
+#, python-format
+msgid ""
+"A router publishes a local LeaseSet by\n"
+"sending a I2NP DatabaseStoreMessage\n"
+"with a nonzero Reply Token over an outbound client tunnel for that "
+"Destination.\n"
+"The message is end-to-end garlic encrypted using the Destination's "
+"Session Key Manager,\n"
+"to hide the message from the tunnel's outbound endpoint.\n"
+"The floodfill router replies with a\n"
+"I2NP DeliveryStatusMessage,\n"
+"with the Message ID set to the value of the Reply Token.\n"
+"This message is sent back to one of the client's inbound tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:370
+msgid "Flooding"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:371
+msgid ""
+"After a floodfill router receives a DatabaseStoreMessage containing a\n"
+"valid RouterInfo or LeaseSet which is newer than that previously stored "
+"in its\n"
+"local NetDb, it \"floods\" it.\n"
+"To flood a NetDb entry, it looks up the 7 floodfill routers closest to "
+"the key\n"
+"of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or "
+"Destination with the date (yyyyMMdd) appended.)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:379
+#, python-format
+msgid ""
+"It then directly connects to each of the 7 peers\n"
+"and sends it a I2NP DatabaseStoreMessage\n"
+"with a zero Reply Token. The message is not end-to-end garlic encrypted,\n"
+"as this is a direct connection, so there are no intervening routers\n"
+"(and no need to hide this data anyway).\n"
+"The other routers do not reply or re-flood, as the Reply Token is zero."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:389
+msgid "RouterInfo and LeaseSet Lookup"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:390
+#, python-format
+msgid ""
+"The I2NP DatabaseLookupMessage is used to "
+"request a netdb entry from a floodfill router.\n"
+"Lookups are sent out one of the router's outbound exploratory tunnels.\n"
+"The replies are specified to return via one of the router's inbound "
+"exploratory tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:396
+msgid ""
+"Lookups are generally sent to the two \"good\" (the connection doesn't "
+"fail) floodfill routers closest to the requested key, in parallel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:400
+#, python-format
+msgid ""
+"If the key is found locally by the floodfill router, it responds with a\n"
+"I2NP DatabaseStoreMessage.\n"
+"If the key is not found locally by the floodfill router, it responds with"
+" a\n"
+"I2NP DatabaseSearchReplyMessage\n"
+"containing a list of other floodfill routers close to the key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:408
+msgid ""
+"Lookups are not encrypted and thus are vulnerable to snooping by the "
+"outbound endpoint\n"
+"(OBEP) of the client tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:413
+msgid ""
+"As the requesting router does not reveal itself, there is no recipient "
+"public key for the floodfill router to\n"
+"encrypt the reply with. Therefore, the reply is exposed to the inbound "
+"gateway (IBGW)\n"
+"of the inbound exploratory tunnel.\n"
+"An appropriate method of encrypting the reply is a topic for future work."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:420
+#, python-format
+msgid ""
+"(Reference: Hashing it out in Public Sections "
+"2.2-2.3 for terms below in italics)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:424
+msgid ""
+"Due to the relatively small size of the network and the flooding "
+"redundancy of 8x,\n"
+"lookups are usually O(1) rather than O(log n) --\n"
+"a router is highly likely to know a floodfill router close enough to the "
+"key to get the answer on the first try.\n"
+"In releases prior to 0.8.9, routers used a lookup redundancy of two\n"
+"(that is, two lookups were performed in parallel to different peers), and"
+"\n"
+"neither recursive nor iterative routing for lookups was "
+"implemented.\n"
+"Queries were sent through multiple routes simultaneously\n"
+"to reduce the chance of query failure."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:435
+msgid ""
+"As of release 0.8.9, iterative lookups are implemented with no "
+"lookup redundancy.\n"
+"This is a more efficient and reliable lookup that will work much better\n"
+"when not all floodfill peers are known, and it removes a serious\n"
+"limitation to network growth. As the network grows and each router knows "
+"only a small\n"
+"subset of the floodfill peers, lookups will become O(log n).\n"
+"Even if the peer does not return references closer to the key, the lookup"
+" continues with\n"
+"the next-closest peer, for added robustness, and to prevent a malicious "
+"floodfill from\n"
+"black-holing a part of the key space. Lookups continue until a total "
+"lookup timeout is reached,\n"
+"or the maximum number of peers is queried."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:447
+msgid ""
+"Node IDs are verifiable in that we use the router hash "
+"directly as both the node ID and the Kademlia key.\n"
+"Incorrect responses that are not closer to the search key are generally "
+"ignored.\n"
+"Given the current size of the network, a router has\n"
+"detailed knowledge of the neighborhood of the destination ID space."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:456
+msgid "RouterInfo Storage Verification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:457
+msgid ""
+"To verify a storage was successful, a router simply waits about 10 "
+"seconds,\n"
+"then sends a lookup to another floodfill router close to the key\n"
+"(but not the one the store was sent to).\n"
+"Lookups sent out one of the router's outbound exploratory tunnels.\n"
+"Lookups are end-to-end garlic encrypted to prevent snooping by the "
+"outbound endpoint(OBEP)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:465
+msgid "LeaseSet Storage Verification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:466
+msgid ""
+"To verify a storage was successful, a router simply waits about 10 "
+"seconds,\n"
+"then sends a lookup to another floodfill router close to the key\n"
+"(but not the one the store was sent to).\n"
+"Lookups sent out one of the outbound client tunnels for the destination "
+"of the LeaseSet being verified.\n"
+"To prevent snooping by the OBEP of the outbound tunnel,\n"
+"lookups are end-to-end garlic encrypted.\n"
+"The replies are specified to return via one of the client's inbound "
+"tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:476
+msgid ""
+"As for regular lookups, the reply is unencrypted,\n"
+"thus exposing the reply to the inbound gateway (IBGW) of the reply "
+"tunnel, and\n"
+"an appropriate method of encrypting the reply is a topic for future work."
+"\n"
+"As the IBGW for the reply is one of the gateways published in the "
+"LeaseSet,\n"
+"the exposure is minimal."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:486
+msgid "Exploration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:487
+#, python-format
+msgid ""
+"Exploration is a special form of netdb lookup, where a router "
+"attempts to learn about\n"
+"new routers.\n"
+"It does this by sending a floodfill router a I2NP DatabaseLookupMessage, looking for a random "
+"key.\n"
+"As this lookup will fail, the floodfill would normally respond with a\n"
+"I2NP DatabaseSearchReplyMessage containing "
+"hashes of floodfill routers close to the key.\n"
+"This would not be helpful, as the requesting router probably already "
+"knows those floodfills,\n"
+"and it would be impractical to add ALL floodfill routers to the \"don't "
+"include\" field of the lookup.\n"
+"For an exploration query, the requesting router adds a router hash of all"
+" zeros to the\n"
+"\"don't include\" field of the DatabaseLookupMessage.\n"
+"The floodfill will then respond only with non-floodfill routers close to "
+"the requested key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:501
+msgid "Notes on Lookup Responses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:502
+msgid ""
+"The response to a lookup request is either a Database Store Message (on "
+"success) or a\n"
+"Database Search Reply Message (on failure). The DSRM contains a 'from' "
+"router hash field\n"
+"to indicate the source of the reply; the DSM does not.\n"
+"The DSRM 'from' field is unauthenticated and may be spoofed or invalid.\n"
+"There are no other response tags. Therefore, when making multiple "
+"requests in parallel, it is\n"
+"difficult to monitor the performance of the various floodfill routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:512
+msgid "MultiHoming"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:514
+msgid ""
+"Destinations may be hosted on multiple routers simultaneously, by using "
+"the same\n"
+"private and public keys (traditionally stored in eepPriv.dat files).\n"
+"As both instances will periodically publish their signed LeaseSets to the"
+" floodfill peers,\n"
+"the most recently published LeaseSet will be returned to a peer "
+"requesting a database lookup.\n"
+"As LeaseSets have (at most) a 10 minute lifetime, should a particular "
+"instance go down,\n"
+"the outage will be 10 minutes at most, and generally much less than that."
+"\n"
+"The multihoming function has been verified and is in use by several "
+"services on the network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:524
+msgid "Threat Analysis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:525
+#, python-format
+msgid ""
+"Also discussed on the threat model "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:529
+msgid ""
+"A hostile user may attempt to harm the network by\n"
+"creating one or more floodfill routers and crafting them to offer\n"
+"bad, slow, or no responses.\n"
+"Some scenarios are discussed below."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:536
+msgid "General Mitigation Through Growth"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:537
+msgid ""
+"There are currently hundreds of floodfill routers in the network.\n"
+"Most of the following attacks will become more difficult, or have less "
+"impact,\n"
+"as the network size and number of floodfill routers increase."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:544
+msgid "General Mitigation Through Redundancy"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:545
+msgid ""
+"Via flooding, all netdb entries are stored on the 8 floodfill routers "
+"closest to the key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:550
+msgid "Forgeries"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:551
+msgid ""
+"All netdb entries are signed by their creators, so no router may forge a\n"
+"RouterInfo or LeaseSet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:556
+msgid "Slow or Unresponsive"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:557
+#, python-format
+msgid ""
+"Each router maintains an expanded set of statistics in the\n"
+"peer profile for each floodfill router,"
+"\n"
+"covering various quality metrics for that peer.\n"
+"The set includes:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:564
+msgid "Average response time"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:565
+msgid "Percentage of queries answered with the data requested"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:566
+msgid "Percentage of stores that were successfully verified"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:567
+msgid "Last successful store"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:568
+msgid "Last successful lookup"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:569
+msgid "Last response"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:572
+msgid ""
+"Each time a router needs to make a determination on which floodfill "
+"router is closest to a key,\n"
+"it uses these metrics to determine which floodfill routers are \"good\".\n"
+"The methods, and thresholds, used to determine \"goodness\" are "
+"relatively new, and\n"
+"are subject to further analysis and improvement.\n"
+"While a completely unresponsive router will quickly be identified and "
+"avoided,\n"
+"routers that are only sometimes malicious may be much harder to deal with."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:582
+msgid "Sybil Attack (Full Keyspace)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:583
+#, python-format
+msgid ""
+"An attacker may mount a Sybil attack\n"
+"by creating a large number of floodfill routers spread throughout the "
+"keyspace."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:588
+#, python-format
+msgid ""
+"(In a related example, a researcher recently created a\n"
+"large number of Tor relays.)\n"
+"If successful, this could be an effective DOS attack on the entire "
+"network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:594
+msgid ""
+"If the floodfills are not sufficiently misbehaving to be marked as "
+"\"bad\" using the peer profile\n"
+"metrics described above, this is a difficult scenario to handle.\n"
+"Tor's response can be much more nimble in the relay case, as the "
+"suspicious relays\n"
+"can be manually removed from the consensus.\n"
+"Some possible responses for the I2P network are listed below, however "
+"none of them is completely satisfactory:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:602
+msgid ""
+"Compile a list of bad router hashes or IPs, and announce the list through"
+" various means\n"
+"(console news, website, forum, etc.); users would have to manually "
+"download the list and\n"
+"add it to their local \"blacklist\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:607
+msgid ""
+"Ask everyone in the network to enable floodfill manually (fight Sybil "
+"with more Sybil)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:608
+msgid "Release a new software version that includes the hardcoded \"bad\" list"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:609
+msgid ""
+"Release a new software version that improves the peer profile metrics and"
+" thresholds,\n"
+"in an attempt to automatically identify the \"bad\" peers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:613
+msgid ""
+"Add software that disqualifies floodfills if too many of them are in a "
+"single IP block"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:614
+msgid ""
+"Implement an automatic subscription-based blacklist controlled by a "
+"single individual or group.\n"
+"This would essentially implement a portion of the Tor \"consensus\" "
+"model.\n"
+"Unfortunately it would also give a single individual or group the power "
+"to\n"
+"block participation of any particular router or IP in the network,\n"
+"or even to completely shutdown or destroy the entire network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:623
+#: i2p2www/pages/site/docs/how/network-database.html:659
+msgid "This attack becomes more difficult as the network size grows."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:629
+msgid "Sybil Attack (Partial Keyspace)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:630
+#, python-format
+msgid ""
+"An attacker may mount a Sybil attack\n"
+"by creating a small number (8-15) of floodfill routers clustered closely "
+"in the keyspace,\n"
+"and distribute the RouterInfos for these routers widely.\n"
+"Then, all lookups and stores for a key in that keyspace would be directed"
+"\n"
+"to one of the attacker's routers.\n"
+"If successful, this could be an effective DOS attack on a particular "
+"eepsite, for example."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:639
+msgid ""
+"As the keyspace is indexed by the cryptographic (SHA256) Hash of the key,"
+"\n"
+"an attacker must use a brute-force method to repeatedly generate router "
+"hashes\n"
+"until he has enough that are sufficiently close to the key.\n"
+"The amount of computational power required for this, which is dependent "
+"on network\n"
+"size, is unknown."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:647
+msgid ""
+"As a partial defense against this attack,\n"
+"the algorithm used to determine Kademlia \"closeness\" varies over time.\n"
+"Rather than using the Hash of the key (i.e. H(k)) to determine closeness,"
+"\n"
+"we use the Hash of the key appended with the current date string, i.e. "
+"H(k + YYYYMMDD).\n"
+"A function called the \"routing key generator\" does this, which "
+"transforms the original key into a \"routing key\".\n"
+"In other words, the entire netdb keyspace \"rotates\" every day at UTC "
+"midnight.\n"
+"Any partial-keyspace attack would have to be regenerated every day, for\n"
+"after the rotation, the attacking routers would no longer be close\n"
+"to the target key, or to each other."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:663
+msgid ""
+"One consequence of daily keyspace rotation is that the distributed "
+"network database\n"
+"may become unreliable for a few minutes after the rotation --\n"
+"lookups will fail because the new \"closest\" router has not received a "
+"store yet.\n"
+"The extent of the issue, and methods for mitigation\n"
+"(for example netdb \"handoffs\" at midnight)\n"
+"are a topic for further study."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:673
+msgid "Bootstrap Attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:674
+msgid ""
+"An attacker could attempt to boot new routers into an isolated\n"
+"or majority-controlled network by taking over a reseed website,\n"
+"or tricking the developers into adding his reseed website\n"
+"to the hardcoded list in the router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:681
+msgid "Several defenses are possible, and most of these are planned:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:685
+msgid ""
+"Disallow fallback from HTTPS to HTTP for reseeding.\n"
+"A MITM attacker could simply block HTTPS, then respond to the HTTP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:689
+msgid ""
+"Changing the reseed task to fetch a subset of RouterInfos from\n"
+"each of several reseed sites rather than using only a single site"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:693
+msgid ""
+"Creating an out-of-network reseed monitoring service that\n"
+"periodically polls reseed websites and verifies that the\n"
+"data are not stale or inconsistent with other views of the network"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:698
+msgid "Bundling reseed data in the installer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:701
+msgid "Query Capture"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:702
+#, python-format
+msgid ""
+"See also lookup\n"
+"(Reference: Hashing it out in Public Sections "
+"2.2-2.3 for terms below in italics)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:707
+msgid ""
+"Similar to a bootstrap attack, an attacker using a floodfill router could"
+" attempt to \"steer\"\n"
+"peers to a subset of routers controlled by him by returning their "
+"references."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:712
+msgid ""
+"This is unlikely to work via exploration, because exploration is a low-"
+"frequency task.\n"
+"Routers acquire a majority of their peer references through normal tunnel"
+" building activity.\n"
+"Exploration results are generally limited to a few router hashes,\n"
+"and each exploration query is directed to a random floodfill router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:719
+#, python-format
+msgid ""
+"As of release 0.8.9, iterative lookups are implemented.\n"
+"For floodfill router references returned in a\n"
+"I2NP DatabaseSearchReplyMessage\n"
+"response to a lookup,\n"
+"these references are followed if they are closer (or the next closest) to"
+" the lookup key.\n"
+"The requesting router does not trust that the references are\n"
+"closer to the key (i.e. they are verifiably correct.\n"
+"The lookup also does not stop when no closer key is found, but continues "
+"by querying the\n"
+"next-closet node, until the timeout or maximum number of queries is "
+"reached.\n"
+"This prevents a malicious floodfill from black-holing a part of the key "
+"space.\n"
+"Also, the daily keyspace rotation requires an attacker to regenerate a "
+"router info\n"
+"within the desired key space region.\n"
+"This design ensures that the query capture attack described in\n"
+"Hashing it out in Public\n"
+"is much more difficult."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:738
+msgid "DHT-Based Relay Selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:739
+#, python-format
+msgid "(Reference: Hashing it out in Public Section 3)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:743
+#, python-format
+msgid ""
+"This doesn't have much to do with floodfill, but see\n"
+"the peer selection page\n"
+"for a discussion of the vulnerabilities of peer selection for tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:749
+msgid "Information Leaks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:750
+#, python-format
+msgid ""
+"(Reference: In Search of an Anonymous and Secure "
+"Lookup Section 3)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:754
+#, python-format
+msgid ""
+"This paper addresses weaknesses in the \"Finger Table\" DHT lookups used "
+"by Torsk and NISAN.\n"
+"At first glance, these do not appear to apply to I2P. First, the use of "
+"DHT by Torsk and NISAN\n"
+"is significantly different from that in I2P. Second, I2P's network "
+"database lookups are only\n"
+"loosely correlated to the peer "
+"selection and\n"
+"tunnel building processes; only "
+"previously-known peers\n"
+"are used for tunnels.\n"
+"Also, peer selection is unrelated to any notion of DHT key-closeness."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:765
+msgid ""
+"Some of this may actually be more interesting when the I2P network gets "
+"much larger.\n"
+"Right now, each router knows a large proportion of the network, so "
+"looking up a particular\n"
+"Router Info in the network database is not strongly indicative of a "
+"future intent to use\n"
+"that router in a tunnel. Perhaps when the network is 100 times larger, "
+"the lookup may be\n"
+"more correlative. Of course, a larger network makes a Sybil attack that "
+"much harder."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:773
+#, python-format
+msgid ""
+"However, the general issue of DHT information leakage in I2P needs "
+"further investigation.\n"
+"The floodfill routers are in a position to observe queries and gather "
+"information.\n"
+"Certainly, at a level of f = 0.2 (20%% malicious nodes, as "
+"specifed in the paper)\n"
+"we expect that many of the Sybil threats we describe\n"
+"(here,\n"
+"here and\n"
+"here)\n"
+"become problematic for several reasons."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:787
+msgid "Moved to the netdb discussion page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:791
+msgid "End-to-end encryption of additional netDb lookups and responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/network-database.html:795
+msgid "Better methods for tracking lookup responses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:2
+msgid "Peer Profiling and Selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:3
+#: i2p2www/pages/site/docs/transport/index.html:3
+msgid "July 2010"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:8
+msgid "Peer Profiling"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:10
+#, python-format
+msgid ""
+"Peer profiling is the process of collecting data based on the "
+"observed performance\n"
+"of other routers or peers, and classifying those peers into groups.\n"
+"Profiling does not use any claimed performance data published by "
+"the peer itself\n"
+"in the network database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:17
+msgid "Profiles are used for two purposes:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:19
+msgid "Selecting peers to relay our traffic through, which is discussed below"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:20
+#, python-format
+msgid ""
+"Choosing peers from the set of floodfill routers to use for network "
+"database storage and queries,\n"
+"which is discussed on the network database page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:27
+#: i2p2www/pages/site/docs/how/peer-selection.html:187
+#: i2p2www/pages/site/docs/tunnels/implementation.html:286
+msgid "Peer Selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:28
+msgid ""
+"Peer selection is the process of choosing which routers\n"
+"on the network we want to relay our messages to go through (which peers "
+"will we \n"
+"ask to join our tunnels).  To accomplish this, we keep track of how each\n"
+"peer performs (the peer's \"profile\") and use that data to estimate how"
+" \n"
+"fast they are, how often they will be able to accept our requests, and \n"
+"whether they seem to be overloaded or otherwise unable to perform what\n"
+"they agree to reliably."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:38
+#, python-format
+msgid ""
+"Unlike some other anonymous networks, in I2P,\n"
+"claimed bandwidth is untrusted and is only used to avoid those "
+"peers\n"
+"advertising very low bandwidth insufficient for routing tunnels.\n"
+"All peer selection is done through profiling.\n"
+"This prevents simple attacks based on peers claiming high bandwidth\n"
+"in order to capture large numbers of tunnels.\n"
+"It also makes\n"
+"timing attacks\n"
+"more difficult."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:50
+msgid ""
+"Peer selection is done quite frequently, as a router may maintain a large"
+" number\n"
+"of client and exploratory tunnels, and a tunnel lifetime is only 10 "
+"minutes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:56
+msgid "Further Information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:57
+#, python-format
+msgid ""
+"For more information see the paper\n"
+"Peer Profiling and Selection in the I2P Anonymous "
+"Network\n"
+"presented at PET-CON 2009.1.\n"
+"See below for notes on minor changes since the "
+"paper was published."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:65
+msgid "Profiles"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:66
+#, python-format
+msgid ""
+"Each peer has a set of data points collected about them, including "
+"statistics \n"
+"about how long it takes for them to reply to a network database query, "
+"how \n"
+"often their tunnels fail, and how many new peers they are able to "
+"introduce \n"
+"us to, as well as simple data points such as when we last heard from them"
+" or\n"
+"when the last communication error occurred.  The specific data points "
+"gathered\n"
+"can be found in the code."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:75
+msgid ""
+"Profiles are fairly small, a few KB. To control memory usage, the profile"
+" expiration time\n"
+"lessens as the number of profiles grows.\n"
+"Profiles are kept in memory until router shutdown, when they are written "
+"to disk.\n"
+"At startup, the profiles are read so the router need not reinitialize all"
+" profiles,\n"
+"thus allowing a router to quickly re-integrate into the network after "
+"startup."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:85
+msgid "Peer Summaries"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:86
+msgid ""
+"While the profiles themselves can be considered a summary of a peer's \n"
+"performance, to allow for effective peer selection we break each summary "
+"down \n"
+"into four simple values, representing the peer's speed, its capacity, how"
+" well \n"
+"integrated into the network it is, and whether it is failing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:93
+msgid "Speed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:94
+msgid ""
+"The speed calculation\n"
+"simply goes through the profile and estimates how much data we can\n"
+"send or receive on a single tunnel through the peer in a minute.  For "
+"this estimate it just looks at\n"
+"performance in the previous minute."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:101
+msgid "Capacity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:102
+msgid ""
+"The capacity calculation\n"
+"simply goes through the profile and estimates how many tunnels the peer\n"
+"would agree to participate in over a given time period.  For this "
+"estimate it looks at \n"
+"how many tunnel build requests\n"
+"the peer has accepted, rejected, and dropped, and how many\n"
+"of the agreed-to tunnels later failed.\n"
+"While the calculation is time-weighted so that recent activity counts "
+"more than later activity,\n"
+"statistics up to 48 hours old may be included."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:113
+msgid ""
+"Recognizing and avoiding unreliable and unreachable\n"
+"peers is critically important.\n"
+"Unfortunately, as the tunnel building and testing require the "
+"participation of several peers,\n"
+"it is difficult to positively identify the cause of a dropped build "
+"request or test failure.\n"
+"The router assigns a probability of failure to each of the\n"
+"peers, and uses that probability in the capacity calculation.\n"
+"Drops and test failures are weighted much higher than rejections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:123
+msgid "Peer organization"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:124
+msgid ""
+"As mentioned above, we drill through each peer's profile to come up with "
+"a \n"
+"few key calculations, and based upon those, we organize each peer into "
+"three\n"
+"groups - fast, high capacity, and standard."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:130
+msgid "The groupings are not mutually exclusive, nor are they unrelated:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:134
+msgid ""
+"A peer is considered \"high capacity\" if its capacity calculation meets "
+"or \n"
+"exceeds the median of all peers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:138
+msgid ""
+"A peer is considered \"fast\" if they are already \"high capacity\" and "
+"their \n"
+"speed calculation meets or exceeds the median of all peers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:142
+msgid "A peer is considered \"standard\" if it is not \"high capacity\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:145
+#, python-format
+msgid ""
+"These groupings are implemented in the router's\n"
+"ProfileOrganizer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:150
+msgid "Group size limits"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:151
+msgid "The size of the groups may be limited."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:156
+msgid ""
+"The fast group is limited to 30 peers.\n"
+"If there would be more, only the ones with the highest speed rating are "
+"placed in the group."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:160
+msgid ""
+"The high capacity group is limited to 75 peers (including the fast group)"
+"\n"
+"If there would be more, only the ones with the highest capacity rating "
+"are placed in the group."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:164
+msgid ""
+"The standard group has no fixed limit, but is somewhat smaller than the "
+"number of RouterInfos\n"
+"stored in the local network database.\n"
+"On an active router in today's network, there may be about 1000 "
+"RouterInfos and 500 peer profiles\n"
+"(including those in the fast and high capacity groups)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:172
+msgid "Recalculation and Stability"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:173
+msgid ""
+"Summaries are recalculated, and peers are resorted into groups, every 45 "
+"seconds."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:177
+msgid ""
+"The groups tend to be fairly stable, that is, there is not much \"churn\""
+" in the rankings\n"
+"at each recalculation.\n"
+"Peers in the fast and high capacity groups get more tunnels build through"
+" them, which increases their speed and capacity ratings,\n"
+"which reinforces their presence in the group."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:188
+msgid "The router selects peers from the above groups to build tunnels through."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:193
+msgid "Peer Selection for Client Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:194
+msgid ""
+"Client tunnels are used for application traffic, such as for HTTP proxies"
+" and web servers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:198
+msgid ""
+"To reduce the susceptibility to some attacks,\n"
+"and increase performance,\n"
+"peers for building client tunnels are chosen randomly from the smallest "
+"group, which is the \"fast\" group.\n"
+"There is no bias toward selecting peers that were previously participants"
+" in a tunnel for the same client."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:206
+msgid "Peer Selection for Exploratory Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:207
+msgid ""
+"Exploratory tunnels are used for router administrative purposes, such as "
+"network database traffic\n"
+"and testing client tunnels.\n"
+"Exploratory tunnels are also used to contact previously unconnected "
+"routers, which is why\n"
+"they are called \"exploratory\".\n"
+"These tunnels are usually low-bandwidth."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:215
+msgid ""
+"Peers for building exploratory tunnels are generally chosen randomly from"
+" the standard group.\n"
+"If the success rate of these build attempts is low compared to the client"
+" tunnel build success rate,\n"
+"the router will select a weighted average of peers randomly from the high"
+" capacity group instead.\n"
+"This helps maintain a satisfactory build success rate even when network "
+"performance is poor.\n"
+"There is no bias toward selecting peers that were previously participants"
+" in an exploratory tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:223
+msgid ""
+"As the standard group includes a very large subset of all peers the "
+"router knows about,\n"
+"exploratory tunnels are essentially built through a random selection of "
+"all peers,\n"
+"until the build success rate becomes too low."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:231
+msgid "Restrictions"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:232
+msgid ""
+"To prevent some simple attacks, and for performance, there are the "
+"following restrictions:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:236
+msgid "Two peers from the same /16 IP space may not be in the same tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:239
+#, python-format
+msgid ""
+"A peer may participate in a maximum of 33% of all tunnels created by the "
+"router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:242
+msgid "Peers with extremely low bandwidth are not used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:245
+msgid "Peers for which a recent connection attempt failed are not used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:252
+msgid "Peer Ordering in Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:253
+#, python-format
+msgid ""
+"Peers are ordered within tunnels to\n"
+"to deal with the predecessor attack\n"
+"(2008 update).\n"
+"More information is on the tunnel "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:268
+msgid "Continue to analyze an tune speed and capacity calculations as necessary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:271
+msgid ""
+"Implement a more aggressive ejection strategy if necessary to control "
+"memory usage as the network grows"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:274
+msgid "Evaluate group size limits"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:277
+msgid "Use GeoIP data to include or exclude certain peers, if configured"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:283
+#, python-format
+msgid ""
+"For those reading the paper\n"
+"Peer Profiling and Selection in the I2P Anonymous "
+"Network,\n"
+"please keep in mind the following minor changes in I2P since the paper's "
+"publication:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:289
+msgid "The Integration calculation is still not used"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:290
+msgid "In the paper, \"groups\" are called \"tiers\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:291
+msgid "The \"Failing\" tier is no longer used"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:292
+msgid "The \"Not Failing\" tier is now named \"Standard\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:301
+msgid "One Cell Enough"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:303
+msgid "Tor Entry Guards"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:305
+msgid "Murdoch 2007 Paper"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:307
+msgid "Tune-up for Tor"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/peer-selection.html:309
+msgid "Low-resource Routing Attacks Against Tor"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:2
+msgid "Introducing I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:5
+msgid "I2P: A scalable framework for anonymous communication"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:7
+msgid "Table of Contents"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:9
+#: i2p2www/pages/site/docs/how/tech-intro.html:24
+#: i2p2www/pages/site/docs/transport/ssu.html:273
+msgid "Introduction"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:11
+msgid "I2P Operation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:16
+#: i2p2www/pages/site/docs/how/tech-intro.html:401
+msgid "Transport protocols"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:25
+msgid ""
+"I2P is a scalable, self organizing, resilient packet switched anonymous \n"
+"network layer, upon which any number of different anonymity or security "
+"conscious \n"
+"applications can operate. Each of these applications may make their own "
+"anonymity, \n"
+"latency, and throughput tradeoffs without worrying about the proper "
+"implementation \n"
+"of a free route mixnet, allowing them to blend their activity with the "
+"larger \n"
+"anonymity set of users already running on top of I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:34
+msgid ""
+"Applications available already provide the full range of typical Internet"
+" activities -\n"
+"anonymous web browsing, web hosting, chat, file sharing, e-mail,\n"
+"blogging and content syndication, newsgroups, as well as several other "
+"applications under development."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:40
+msgid "Web browsing: using any existing browser that supports using a proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:41
+msgid "Chat: IRC, Jabber, I2P-Messenger."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:42
+msgid ""
+"File sharing: I2PSnark, Robert, iMule, \n"
+"I2Phex, PyBit, I2P-bt\n"
+"and others."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:47
+msgid ""
+"E-mail: susimail and I2P-Bote."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:48
+msgid ""
+"Blog: using e.g. the pebble plugin or the distributed blogging software "
+"Syndie."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:49
+msgid ""
+"Distributed Data Store: Save your data redundantly in the Tahoe-LAFS "
+"cloud over I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:50
+msgid "Newsgroups: using any newsgroup reader that supports using a proxy."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:53
+msgid ""
+"Unlike web sites hosted within content distribution networks like Freenet \n"
+"or GNUnet, the services "
+"hosted on \n"
+"I2P are fully interactive - there are traditional web-style search "
+"engines, \n"
+"bulletin boards, blogs you can comment on, database driven sites, and "
+"bridges \n"
+"to query static systems like Freenet without needing to install it "
+"locally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:61
+msgid ""
+"With all of these anonymity enabled applications, I2P takes on the role \n"
+"of the message oriented middleware - applications say that they want to "
+"send \n"
+"some data to a cryptographic identifier (a \"destination\") and I2P takes"
+" care \n"
+"of making sure it gets there securely and anonymously. I2P also bundles a"
+" \n"
+"simple streaming library to allow I2P's "
+"anonymous \n"
+"best-effort messages to transfer as reliable, in-order streams, "
+"transparently \n"
+"offering a TCP based congestion control algorithm tuned for the high "
+"bandwidth \n"
+"delay product of the network. While there have been several simple SOCKS "
+"proxies \n"
+"available to tie existing applications into the network, their value has "
+"been \n"
+"limited as nearly every application routinely exposes what, in an "
+"anonymous \n"
+"context, is sensitive information. The only safe way to go is to fully "
+"audit \n"
+"an application to ensure proper operation and to assist in that we "
+"provide \n"
+"a series of APIs in various languages which can be used to make the most "
+"out \n"
+"of the network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:78
+#, python-format
+msgid ""
+"I2P is not a research project - academic, commercial, or governmental, "
+"but \n"
+"is instead an engineering effort aimed at doing whatever is necessary to "
+"provide \n"
+"a sufficient level of anonymity to those who need it. It has been in "
+"active \n"
+"development since early 2003 with one full time developer and a dedicated"
+" \n"
+"group of part time contributors from all over the world. All of the work "
+"done \n"
+"on I2P is open source and freely available on the website, \n"
+"with the majority of the code released outright into the public domain, "
+"though \n"
+"making use of a few cryptographic routines under BSD-style licenses. The "
+"people \n"
+"working on I2P do not control what people release client applications "
+"under, \n"
+"and there are several GPL'ed applications available (I2PTunnel, \n"
+"susimail, I2PSnark, I2P-"
+"Bote, \n"
+"I2Phex and others.).\n"
+"Funding for I2P comes entirely from "
+"donations,\n"
+"and does not receive any tax breaks in any jurisdiction at this time,\n"
+"as many of the developers are themselves anonymous."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:96
+msgid "Operation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:98
+msgid ""
+"To understand I2P's operation, it is essential to understand a few key "
+"concepts. \n"
+"First, I2P makes a strict separation between the software participating "
+"in \n"
+"the network (a \"router\") and the anonymous endpoints (\"destinations\")"
+" associated \n"
+"with individual applications. The fact that someone is running I2P is not"
+" \n"
+"usually a secret. What is hidden is information on what the user is "
+"doing, \n"
+"if anything at all, as well as what router a particular destination is "
+"connected \n"
+"to. End users will typically have several local destinations on their "
+"router \n"
+"- for instance, one proxying in to IRC servers, another supporting the "
+"user's \n"
+"anonymous webserver (\"eepsite\"), another for an I2Phex instance, "
+"another for \n"
+"torrents, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:111
+msgid ""
+"Another critical concept to understand is the \"tunnel\".\n"
+"A tunnel is a directed path through an explicitly selected list of "
+"routers.\n"
+"Layered encryption is used, so each of the routers can only decrypt a "
+"single layer.\n"
+"The decrypted information contains the IP of the next router, along with\n"
+"the encrypted information to be forwarded.\n"
+"Each tunnel has a starting point (the first router, also known as "
+"\"gateway\")\n"
+"and an end point. Messages can be sent only in one way. To send messages "
+"back,\n"
+"another tunnel is required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:122
+#: i2p2www/pages/site/docs/tunnels/implementation.html:105
+msgid "Inbound and outbound tunnel schematic"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:124
+msgid "Figure 1: Two types of tunnels exist: inbound and outbound."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:127
+msgid ""
+"Two types of tunnels exist:\n"
+"\"outbound\" tunnels send messages away from the tunnel creator,\n"
+"while \"inbound\" tunnels bring messages to the tunnel creator.\n"
+"Combining these two tunnels allows users to send messages to each other.\n"
+"The sender (\"Alice\" in the above image) sets up an outbound tunnel,\n"
+"while the receiver (\"Bob\" in the above image) creates an inbound "
+"tunnel.\n"
+"The gateway of an inbound tunnel can receive messages from any other user"
+"\n"
+"and will send them on until the endpoint (\"Bob\").\n"
+"The endpoint of the outbound tunnel will need to send the message\n"
+"on to the gateway of the inbound tunnel.\n"
+"To do this, the sender (\"Alice\") adds instructions to her encrypted "
+"message.\n"
+"Once the endpoint of the outbound tunnel decrypts the message,\n"
+"it will have instructions to forward the message to the correct\n"
+"inbound gateway (the gateway to \"Bob\")."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:144
+msgid ""
+"A third critical concept to understand is I2P's \"network "
+"database\" (or \"netDb\") \n"
+"- a pair of algorithms used to share network metadata. The two types of "
+"metadata \n"
+"carried are \"routerInfo\" and \"leaseSets\" - the "
+"routerInfo gives routers the \n"
+"data necessary for contacting a particular router (their public keys, "
+"transport \n"
+"addresses, etc), while the leaseSet gives routers the information "
+"necessary \n"
+"for contacting a particular destination. A leaseSet contains a number of "
+"\"leases\".\n"
+"Each of this leases specifies a tunnel gateway, which allows reaching a "
+"specific destination.\n"
+"The full information contained in a lease:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:155
+msgid "Inbound gateway for a tunnel that allows reaching a specific destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:156
+msgid "Time when a tunnel expires."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:157
+msgid ""
+"Pair of public keys to be able to encrypt messages (to send through the "
+"tunnel and reach the destination)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:159
+msgid ""
+"Routers themselves send their routerInfo to the netDb directly, while "
+"leaseSets are sent through outbound tunnels\n"
+"(leaseSets need to be sent anonymously, to avoid correlating a router "
+"with his leaseSets)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:164
+msgid ""
+"We can combine the above concepts to build successful connections in the "
+"network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:168
+msgid ""
+"To build up her own inbound and outbound tunnels, Alice does a lookup in "
+"the netDb to collect routerInfo.\n"
+"This way, she gathers lists of peers she can use as hops in her tunnels.\n"
+"She can then send a build message to the first hop, requesting the "
+"construction of a tunnel and asking\n"
+"that router to send the construction message onward, until the tunnel has"
+" been constructed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:175
+msgid "Request information on other routers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:177
+msgid "Build tunnel using router information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:179
+msgid "Figure 2: Router information is used to build tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:182
+msgid ""
+"When Alice wants to send a message to Bob, she first does a lookup in the"
+" \n"
+"netDb to find Bob's leaseSet, giving her his current inbound tunnel "
+"gateways. \n"
+"She then picks one of her outbound tunnels and sends the message down it "
+"with \n"
+"instructions for the outbound tunnel's endpoint to forward the message on"
+" \n"
+"to one of Bob's inbound tunnel gateways. When the outbound tunnel "
+"endpoint \n"
+"receives those instructions, it forwards the message as requested, and "
+"when \n"
+"Bob's inbound tunnel gateway receives it, it is forwarded down the tunnel"
+" \n"
+"to Bob's router. If Alice wants Bob to be able to reply to the message, "
+"she \n"
+"needs to transmit her own destination explicitly as part of the message "
+"itself.\n"
+"This can be done by introducing a higher-level layer, which is done in "
+"the\n"
+"streaming library.\n"
+"Alice may also cut down on the response time by bundling her most \n"
+"recent LeaseSet with the message so that Bob doesn't need to do a netDb "
+"lookup \n"
+"for it when he wants to reply, but this is optional."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:199
+msgid "Connect tunnels using LeaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:199
+msgid "Connect tunnels using leaseSets"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:201
+msgid "Figure 3: LeaseSets are used to connect outbound and inbound tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:204
+msgid ""
+"While the tunnels themselves have layered encryption to prevent "
+"unauthorized \n"
+"disclosure to peers inside the network (as the transport layer itself "
+"does \n"
+"to prevent unauthorized disclosure to peers outside the network), it is "
+"necessary \n"
+"to add an additional end to end layer of encryption to hide the message "
+"from \n"
+"the outbound tunnel endpoint and the inbound tunnel gateway. This \"garlic \n"
+"encryption\" lets Alice's router wrap up multiple messages into a "
+"single \n"
+"\"garlic message\", encrypted to a particular public key so that "
+"intermediary \n"
+"peers cannot determine either how many messages are within the garlic, "
+"what \n"
+"those messages say, or where those individual cloves are destined. For "
+"typical \n"
+"end to end communication between Alice and Bob, the garlic will be "
+"encrypted \n"
+"to the public key published in Bob's leaseSet, allowing the message to be"
+" \n"
+"encrypted without giving out the public key to Bob's own router."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:219
+msgid ""
+"Another important fact to keep in mind is that I2P is entirely message "
+"based \n"
+"and that some messages may be lost along the way. Applications using I2P "
+"can \n"
+"use the message oriented interfaces and take care of their own congestion"
+" \n"
+"control and reliability needs, but most would be best served by reusing "
+"the \n"
+"provided streaming library to view I2P as "
+"a streams \n"
+"based network."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:229
+msgid ""
+"Both inbound and outbound tunnels work along similar principles.\n"
+"The tunnel gateway accumulates a number of tunnel messages, eventually "
+"preprocessing \n"
+"them into something for tunnel delivery. Next, the gateway encrypts that "
+"preprocessed \n"
+"data and forwards it to the first hop. That peer and subsequent tunnel "
+"participants \n"
+"add on a layer of encryption after verifying that it isn't a duplicate "
+"before \n"
+"forward it on to the next peer. Eventually, the message arrives at the "
+"endpoint \n"
+"where the messages are split out again and forwarded on as requested. The"
+" \n"
+"difference arises in what the tunnel's creator does - for inbound "
+"tunnels, \n"
+"the creator is the endpoint and they simply decrypt all of the layers "
+"added, \n"
+"while for outbound tunnels, the creator is the gateway and they pre-"
+"decrypt \n"
+"all of the layers so that after all of the layers of per-hop encryption "
+"are \n"
+"added, the message arrives in the clear at the tunnel endpoint."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:244
+msgid ""
+"The choice of specific peers to pass on messages as well as their "
+"particular \n"
+"ordering is important to understanding both I2P's anonymity and "
+"performance \n"
+"characteristics. While the network database (below) has its own criteria "
+"for \n"
+"picking what peers to query and store entries on, tunnel creators may use"
+" any peers \n"
+"in the network in any order (and even any number of times) in a single "
+"tunnel. \n"
+"If perfect latency and capacity data were globally known, selection and "
+"ordering \n"
+"would be driven by the particular needs of the client in tandem with "
+"their \n"
+"threat model. Unfortunately, latency and capacity data is not trivial to "
+"gather \n"
+"anonymously, and depending upon untrusted peers to provide this "
+"information \n"
+"has its own serious anonymity implications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:257
+msgid ""
+"From an anonymity perspective, the simplest technique would be to pick "
+"peers \n"
+"randomly from the entire network, order them randomly and use those peers"
+" \n"
+"in that order for all eternity. From a performance perspective, the "
+"simplest \n"
+"technique would be to pick the fastest peers with the necessary spare "
+"capacity, \n"
+"spreading the load across different peers to handle transparent failover,"
+" \n"
+"and to rebuild the tunnel whenever capacity information changes. While "
+"the \n"
+"former is both brittle and inefficient, the later requires inaccessible "
+"information \n"
+"and offers insufficient anonymity. I2P is instead working on offering a "
+"range \n"
+"of peer selection strategies, coupled with anonymity aware measurement "
+"code \n"
+"to organize the peers by their profiles."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:270
+msgid ""
+"As a base, I2P is constantly profiling the peers with which it interacts"
+" \n"
+"with by measuring their indirect behavior - for instance, when a peer "
+"responds \n"
+"to a netDb lookup in 1.3 seconds, that round trip latency is recorded in "
+"the \n"
+"profiles for all of the routers involved in the two tunnels (inbound and "
+"outbound) \n"
+"through which the request and response passed, as well as the queried "
+"peer's \n"
+"profile. Direct measurement, such as transport layer latency or "
+"congestion, \n"
+"is not used as part of the profile, as it can be manipulated and "
+"associated \n"
+"with the measuring router, exposing them to trivial attacks. While "
+"gathering \n"
+"these profiles, a series of calculations are run on each to summarize its"
+" \n"
+"performance - its latency, capacity to handle lots of activity, whether "
+"they \n"
+"are currently overloaded, and how well integrated into the network they "
+"seem \n"
+"to be. These calculations are then compared for active peers to organize "
+"the \n"
+"routers into four tiers - fast and high capacity, high capacity, not "
+"failing, \n"
+"and failing. The thresholds for those tiers are determined dynamically, "
+"and \n"
+"while they currently use fairly simple algorithms, alternatives exist."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:288
+msgid ""
+"Using this profile data, the simplest reasonable peer selection strategy"
+" \n"
+"is to pick peers randomly from the top tier (fast and high capacity), and"
+" \n"
+"this is currently deployed for client tunnels. Exploratory tunnels (used "
+"for \n"
+"netDb and tunnel management) pick peers randomly from the \"not failing\""
+" tier \n"
+"(which includes routers in 'better' tiers as well), allowing the peer to "
+"sample \n"
+"routers more widely, in effect optimizing the peer selection through "
+"randomized \n"
+"hill climbing. These strategies alone do however leak information "
+"regarding \n"
+"the peers in the router's top tier through predecessor and netDb "
+"harvesting \n"
+"attacks. In turn, several alternatives exist which, while not balancing "
+"the \n"
+"load as evenly, will address the attacks mounted by particular classes of"
+" \n"
+"adversaries."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:302
+msgid ""
+"By picking a random key and ordering the peers according to their XOR "
+"distance \n"
+"from it, the information leaked is reduced in predecessor and harvesting "
+"attacks \n"
+"according to the peers' failure rate and the tier's churn. Another simple"
+" \n"
+"strategy for dealing with netDb harvesting attacks is to simply fix the "
+"inbound \n"
+"tunnel gateway(s) yet randomize the peers further on in the tunnels. To "
+"deal \n"
+"with predecessor attacks for adversaries which the client contacts, the "
+"outbound \n"
+"tunnel endpoints would also remain fixed. The selection of which peer to "
+"fix \n"
+"on the most exposed point would of course need to have a limit to the "
+"duration, \n"
+"as all peers fail eventually, so it could either be reactively adjusted "
+"or \n"
+"proactively avoided to mimic a measured mean time between failures of "
+"other \n"
+"routers. These two strategies can in turn be combined, using a fixed "
+"exposed \n"
+"peer and an XOR based ordering within the tunnels themselves. A more "
+"rigid \n"
+"strategy would fix the exact peers and ordering of a potential tunnel, "
+"only \n"
+"using individual peers if all of them agree to participate in the same "
+"way \n"
+"each time. This varies from the XOR based ordering in that the "
+"predecessor \n"
+"and successor of each peer is always the same, while the XOR only makes "
+"sure \n"
+"their order doesn't change."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:322
+#, python-format
+msgid ""
+"As mentioned before, I2P currently (release 0.8) includes the tiered \n"
+"random strategy above, with XOR-based ordering. A \n"
+"more detailed discussion of the mechanics involved in tunnel operation, "
+"management, \n"
+"and peer selection can be found in the tunnel "
+"spec."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:330
+#, python-format
+msgid ""
+"As mentioned earlier, I2P's netDb works to share the network's metadata.\n"
+"This is detailed in the network database page,\n"
+"but a basic explanation is available below."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:336
+msgid ""
+"A percentage of I2P users are appointed as 'floodfill peers'.\n"
+"Currently, I2P installations that have a lot of bandwidth and are fast "
+"enough,\n"
+"will appoint themselves as floodfill as soon as the number of existing "
+"floodfill routers\n"
+"drops too low."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:343
+#, python-format
+msgid ""
+"Other I2P routers will store their data and lookup data by sending simple"
+" 'store' and 'lookup' queries to the floodfills.\n"
+"If a floodfill router receives a 'store' query, it will spread the "
+"information to other floodfill routers\n"
+"using the Kademlia "
+"algorithm.\n"
+"The 'lookup' queries currently function differently, to avoid an "
+"important\n"
+"security issue.\n"
+"When a lookup is done, the floodfill router will not forward the lookup "
+"to other peers,\n"
+"but will always answer by itself (if it has the requested data)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:353
+msgid "Two types of information are stored in the network database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:357
+msgid ""
+"A RouterInfo stores information on a specific I2P router and how "
+"to contact it"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:358
+msgid ""
+"A LeaseSet stores information on a specific destination (e.g. I2P "
+"website, e-mail server...)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:360
+msgid ""
+"All of this information is signed by the publishing party and verified by"
+" any I2P router using or storing the information.\n"
+"In addition, the data contains timing information, to avoid storage of "
+"old entries and possible attacks.\n"
+"This is also why I2P bundles the necessary code for maintaining the "
+"correct time, occasionally querying some SNTP servers \n"
+"(the pool.ntp.org round robin by"
+" default)\n"
+"and detecting skew between routers at the transport layer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:368
+msgid "Some additional remarks are also important."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:373
+msgid "Unpublished and encrypted leasesets:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:374
+msgid ""
+"One could only want specific people to be able to reach a destination.\n"
+"This is possible by not publishing the destination in the netDb. You will"
+" however have to transmit the destination by other means.\n"
+"An alternative are the 'encrypted leaseSets'. These leaseSets can only be"
+" decoded by people with access to the decryption key."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:381
+msgid "Bootstrapping:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:382
+msgid ""
+"Bootstrapping the netDb is quite simple. Once a router manages to receive"
+" a single routerInfo of a reachable peer,\n"
+"it can query that router for references to other routers in the network.\n"
+"Currently, a number of users post their routerInfo files to a website to "
+"make this information available.\n"
+"I2P automatically connects to one of these websites to gather routerInfo "
+"files and bootstrap."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:390
+msgid "Lookup scalability:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:391
+msgid ""
+"Lookups in the I2P network are not forwarded to other netDb routers.\n"
+"Currently, this is not a major problem, since the network is not very "
+"large.\n"
+"However, as the network grows, not all routerInfo and leaseSet files will"
+" be present\n"
+"on each netDb router. This will cause a deterioration of the percentage "
+"of successful lookups.\n"
+"Because of this, refinements to the netDb will be done in the next "
+"releases."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:402
+msgid ""
+"Communication between routers needs to provide confidentiality and "
+"integrity \n"
+"against external adversaries while authenticating that the router "
+"contacted \n"
+"is the one who should receive a given message. The particulars of how "
+"routers \n"
+"communicate with other routers aren't critical - three separate protocols"
+" \n"
+"have been used at different points to provide those bare necessities."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:410
+#, python-format
+msgid ""
+"I2P started with a TCP-based protocol which \n"
+"has since been disabled. Then, to accommodate the need for high degree "
+"communication \n"
+"(as a number of routers will end up speaking with many others), I2P moved"
+" \n"
+"from a TCP based transport to a UDP-based one - "
+"\"Secure \n"
+"Semireliable UDP\", or \"SSU\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:418
+#, python-format
+msgid "As described in the SSU spec:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:422
+msgid ""
+"The goal of this protocol is to provide secure, authenticated, \n"
+"semireliable and unordered message delivery, exposing only a minimal "
+"amount \n"
+"of data easily discernible to third parties. It should support high "
+"degree \n"
+"communication as well as TCP-friendly congestion control and may include"
+" \n"
+"PMTU detection. It should be capable of efficiently moving bulk data at "
+"rates \n"
+"sufficient for home users. In addition, it should support techniques for "
+"addressing \n"
+"network obstacles, like most NATs or firewalls."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:432
+#, python-format
+msgid ""
+"Following the introduction of SSU, after issues with congestion collapse"
+" \n"
+"appeared, a new NIO-based TCP transport called NTCP \n"
+"was implemented. It is enabled by default for outbound connections only. "
+"Those \n"
+"who configure their NAT/firewall to allow inbound connections and specify"
+" \n"
+"the external host and port (dyndns/etc is ok) on /config.jsp can receive "
+"inbound \n"
+"connections. As NTCP is NIO based, so it doesn't suffer from the 1 thread"
+" \n"
+"per connection issues of the old TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:442
+msgid ""
+"I2P supports multiple transports simultaneously. A particular transport \n"
+"for an outbound connection is selected with \"bids\". Each transport bids"
+" for \n"
+"the connection and the relative value of these bids assigns the priority."
+" \n"
+"Transports may reply with different bids, depending on whether there is "
+"already \n"
+"an established connection to the peer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:450
+#, python-format
+msgid ""
+"The current implementation ranks NTCP as the highest-priority transport \n"
+"for outbound connections in most situations. SSU is enabled for both "
+"outbound \n"
+"and inbound connections. Your firewall and your I2P router must be "
+"configured \n"
+"to allow inbound NTCP connections. For further information see the NTCP \n"
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:459
+msgid ""
+"A bare minimum set of cryptographic primitives are combined together to \n"
+"provide I2P's layered defenses against a variety of adversaries. At the "
+"lowest \n"
+"level, inter router communication is protected by the transport layer "
+"security \n"
+"- SSU encrypts each packet with AES256/CBC with both an explicit IV and "
+"MAC \n"
+"(HMAC-MD5-128) after agreeing upon an ephemeral session key through a "
+"2048bit \n"
+"Diffie-Hellman exchange, station-to-station authentication with the other"
+" \n"
+"router's DSA key, plus each network message has their own hash for local "
+"integrity \n"
+"checking. Tunnel messages passed over the "
+"transports \n"
+"have their own layered AES256/CBC encryption with an explicit IV and "
+"verified \n"
+"at the tunnel endpoint with an additional SHA256 hash. Various other "
+"messages \n"
+"are passed along inside \"garlic messages\", which are encrypted with "
+"ElGamal/AES+SessionTags \n"
+"(explained below)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:474
+msgid "Garlic messages"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:475
+msgid ""
+"Garlic messages are an extension of \"onion\" layered encryption, "
+"allowing \n"
+"the contents of a single message to contain multiple \"cloves\" - fully "
+"formed \n"
+"messages alongside their own instructions for delivery. Messages are "
+"wrapped \n"
+"into a garlic message whenever the message would otherwise be passing in "
+"cleartext \n"
+"through a peer who should not have access to the information - for "
+"instance, \n"
+"when a router wants to ask another router to participate in a tunnel, "
+"they \n"
+"wrap the request inside a garlic, encrypt that garlic to the receiving "
+"router's \n"
+"2048bit ElGamal public key, and forward it through a tunnel. Another "
+"example \n"
+"is when a client wants to send a message to a destination - the sender's "
+"router \n"
+"will wrap up that data message (alongside some other messages) into a "
+"garlic, \n"
+"encrypt that garlic to the 2048bit ElGamal public key published in the "
+"recipient's \n"
+"leaseSet, and forward it through the appropriate tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:490
+msgid ""
+"The \"instructions\" attached to each clove inside the encryption layer "
+"includes \n"
+"the ability to request that the clove be forwarded locally, to a remote "
+"router, \n"
+"or to a remote tunnel on a remote router. There are fields in those "
+"instructions \n"
+"allowing a peer to request that the delivery be delayed until a certain "
+"time \n"
+"or condition has been met, though they won't be honored until the nontrivial \n"
+"delays are deployed. It is possible to explicitly route garlic "
+"messages \n"
+"any number of hops without building tunnels, or even to reroute tunnel "
+"messages \n"
+"by wrapping them in garlic messages and forwarding them a number of hops "
+"prior \n"
+"to delivering them to the next hop in the tunnel, but those techniques "
+"are \n"
+"not currently used in the existing implementation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:503
+msgid "Session tags"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:504
+msgid ""
+"As an unreliable, unordered, message based system, I2P uses a simple "
+"combination \n"
+"of asymmetric and symmetric encryption algorithms to provide data "
+"confidentiality \n"
+"and integrity to garlic messages. As a whole, the combination is referred"
+" \n"
+"to as ElGamal/AES+SessionTags, but that is an excessively verbose way to "
+"describe \n"
+"the simple use of 2048bit ElGamal, AES256, SHA256 and 32 byte nonces."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:543
+msgid ""
+"Session tags themselves have a very short lifetime, after which they are"
+" \n"
+"discarded if not used. In addition, the quantity stored for each key is "
+"limited, \n"
+"as are the number of keys themselves - if too many arrive, either new or "
+"old \n"
+"messages may be dropped. The sender keeps track whether messages using "
+"session \n"
+"tags are getting through, and if there isn't sufficient communication it "
+"may \n"
+"drop the ones previously assumed to be properly delivered, reverting back"
+" \n"
+"to the full expensive ElGamal encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:553
+msgid ""
+"One alternative is to transmit only a single session tag, and from that,"
+" \n"
+"seed a deterministic PRNG for determining what tags to use or expect. By "
+"keeping \n"
+"this PRNG roughly synchronized between the sender and recipient (the "
+"recipient \n"
+"precomputes a window of the next e.g. 50 tags), the overhead of "
+"periodically \n"
+"bundling a large number of tags is removed, allowing more options in the "
+"space/time \n"
+"tradeoff, and perhaps reducing the number of ElGamal encryptions "
+"necessary. \n"
+"However, it would depend upon the strength of the PRNG to provide the "
+"necessary \n"
+"cover against internal adversaries, though perhaps by limiting the amount"
+" \n"
+"of times each PRNG is used, any weaknesses can be minimized. At the "
+"moment, \n"
+"there are no immediate plans to move towards these synchronized PRNGs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:566
+msgid "Future"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:567
+msgid ""
+"While I2P is currently functional and sufficient for many scenarios, "
+"there \n"
+"are several areas which require further improvement to meet the needs of "
+"those \n"
+"facing more powerful adversaries as well as substantial user experience "
+"optimization."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:573
+msgid "Restricted route operation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:574
+msgid ""
+"I2P is an overlay network designed to be run on top of a functional "
+"packet \n"
+"switched network, exploiting the end to end principle to offer anonymity "
+"and \n"
+"security. While the Internet no longer fully embraces the end to end "
+"principle\n"
+"(due to the usage of NAT), \n"
+"I2P does require a substantial portion of the network to be reachable - "
+"there \n"
+"may be a number of peers along the edges running using restricted routes,"
+" \n"
+"but I2P does not include an appropriate routing algorithm for the "
+"degenerate \n"
+"case where most peers are unreachable. It would, however work on top of a"
+" \n"
+"network employing such an algorithm."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:586
+msgid ""
+"Restricted route operation, where there are limits to what peers are "
+"reachable \n"
+"directly, has several different functional and anonymity implications, "
+"dependent \n"
+"upon how the restricted routes are handled. At the most basic level, "
+"restricted \n"
+"routes exist when a peer is behind a NAT or firewall which does not allow"
+" \n"
+"inbound connections. This was largely addressed in I2P 0.6.0.6 by "
+"integrating \n"
+"distributed hole punching into the transport layer, allowing people "
+"behind \n"
+"most NATs and firewalls to receive unsolicited connections without any "
+"configuration. \n"
+"However, this does not limit the exposure of the peer's IP address to "
+"routers \n"
+"inside the network, as they can simply get introduced to the peer through"
+" \n"
+"the published introducer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:599
+msgid ""
+"Beyond the functional handling of restricted routes, there are two levels"
+" \n"
+"of restricted operation that can be used to limit the exposure of one's "
+"IP \n"
+"address - using router-specific tunnels for communication, and offering "
+"'client \n"
+"routers'. For the former, routers can either build a new pool of tunnels "
+"or \n"
+"reuse their exploratory pool, publishing the inbound gateways to some of "
+"them \n"
+"as part of their routerInfo in place of their transport addresses. When a"
+" \n"
+"peer wants to get in touch with them, they see those tunnel gateways in "
+"the \n"
+"netDb and simply send the relevant message to them through one of the "
+"published \n"
+"tunnels. If the peer behind the restricted route wants to reply, it may "
+"do \n"
+"so either directly (if they are willing to expose their IP to the peer) "
+"or \n"
+"indirectly through their outbound tunnels. When the routers that the peer"
+" \n"
+"has direct connections to want to reach it (to forward tunnel messages, "
+"for \n"
+"instance), they simply prioritize their direct connection over the "
+"published \n"
+"tunnel gateway. The concept of 'client routers' simply extends the "
+"restricted \n"
+"route by not publishing any router addresses. Such a router would not "
+"even \n"
+"need to publish their routerInfo in the netDb, merely providing their "
+"self \n"
+"signed routerInfo to the peers that it contacts (necessary to pass the "
+"router's \n"
+"public keys). Both levels of restricted route operation are planned for "
+"I2P \n"
+"2.0."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:621
+msgid ""
+"There are tradeoffs for those behind restricted routes, as they would "
+"likely \n"
+"participate in other people's tunnels less frequently, and the routers "
+"which \n"
+"they are connected to would be able to infer traffic patterns that would "
+"not \n"
+"otherwise be exposed. On the other hand, if the cost of that exposure is "
+"less \n"
+"than the cost of an IP being made available, it may be worthwhile. This, "
+"of \n"
+"course, assumes that the peers that the router behind a restricted route "
+"contacts \n"
+"are not hostile - either the network is large enough that the probability"
+" \n"
+"of using a hostile peer to get connected is small enough, or trusted (and"
+" \n"
+"perhaps temporary) peers are used instead."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:633
+msgid "Variable latency"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:634
+msgid ""
+"Even though the bulk of I2P's initial efforts have been on low latency "
+"communication, \n"
+"it was designed with variable latency services in mind from the "
+"beginning. \n"
+"At the most basic level, applications running on top of I2P can offer the"
+" \n"
+"anonymity of medium and high latency communication while still blending "
+"their \n"
+"traffic patterns in with low latency traffic. Internally though, I2P can "
+"offer \n"
+"its own medium and high latency communication through the garlic "
+"encryption \n"
+"- specifying that the message should be sent after a certain delay, at a "
+"certain \n"
+"time, after a certain number of messages have passed, or another mix "
+"strategy. \n"
+"With the layered encryption, only the router that the clove exposed the "
+"delay \n"
+"request would know that the message requires high latency, allowing the "
+"traffic \n"
+"to blend in further with the low latency traffic. Once the transmission "
+"precondition \n"
+"is met, the router holding on to the clove (which itself would likely be "
+"a \n"
+"garlic message) simply forwards it as requested - to a router, to a "
+"tunnel, \n"
+"or, most likely, to a remote client destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:651
+msgid ""
+"There are a substantial number of ways to exploit this capacity for high"
+" \n"
+"latency comm in I2P, but for the moment, doing so has been scheduled for "
+"the \n"
+"I2P 3.0 release. In the meantime, those requiring the anonymity that high"
+" \n"
+"latency comm can offer should look towards the application layer to "
+"provide \n"
+"it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:659
+msgid "Open questions"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:661
+msgid "How to get rid of the timing constraint?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:662
+msgid "Can we deal with the sessionTags more efficiently?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:663
+msgid ""
+"What, if any, batching/mixing strategies should be made available on the "
+"tunnels?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:664
+msgid ""
+"What other tunnel peer selection and ordering strategies should be "
+"available?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:667
+msgid "Similar systems"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:669
+msgid ""
+"I2P's architecture builds on the concepts of message oriented middleware,"
+" \n"
+"the topology of DHTs, the anonymity and cryptography of free route "
+"mixnets, \n"
+"and the adaptability of packet switched networking. The value comes not "
+"from \n"
+"novel concepts of algorithms though, but from careful engineering "
+"combining \n"
+"the research results of existing systems and papers. While there are a "
+"few \n"
+"similar efforts worth reviewing, both for technical and functional "
+"comparisons, \n"
+"two in particular are pulled out here - Tor and Freenet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:679
+#, python-format
+msgid "See also the Network Comparisons Page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:684
+#: i2p2www/pages/site/docs/how/tech-intro.html:749
+msgid "website"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:686
+msgid ""
+"At first glance, Tor and I2P have many functional and anonymity related \n"
+"similarities. While I2P's development began before we were aware of the "
+"early \n"
+"stage efforts on Tor, many of the lessons of the original onion routing "
+"and \n"
+"ZKS efforts were integrated into I2P's design. Rather than building an "
+"essentially \n"
+"trusted, centralized system with directory servers, I2P has a self "
+"organizing \n"
+"network database with each peer taking on the responsibility of profiling"
+" \n"
+"other routers to determine how best to exploit available resources. "
+"Another \n"
+"key difference is that while both I2P and Tor use layered and ordered "
+"paths \n"
+"(tunnels and circuits/streams), I2P is fundamentally a packet switched "
+"network, \n"
+"while Tor is fundamentally a circuit switched one, allowing I2P to "
+"transparently \n"
+"route around congestion or other network failures, operate redundant "
+"pathways, \n"
+"and load balance the data across available resources. While Tor offers "
+"the \n"
+"useful outproxy functionality by offering integrated outproxy discovery "
+"and \n"
+"selection, I2P leaves such application layer decisions up to applications"
+" \n"
+"running on top of I2P - in fact, I2P has even externalized the TCP-like "
+"streaming \n"
+"library itself to the application layer, allowing developers to "
+"experiment \n"
+"with different strategies, exploiting their domain specific knowledge to "
+"offer \n"
+"better performance."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:707
+msgid ""
+"From an anonymity perspective, there is much similarity when the core "
+"networks \n"
+"are compared. However, there are a few key differences. When dealing with"
+" \n"
+"an internal adversary or most external adversaries, I2P's simplex tunnels"
+" \n"
+"expose half as much traffic data than would be exposed with Tor's duplex "
+"circuits \n"
+"by simply looking at the flows themselves - an HTTP request and response "
+"would \n"
+"follow the same path in Tor, while in I2P the packets making up the "
+"request \n"
+"would go out through one or more outbound tunnels and the packets making "
+"up \n"
+"the response would come back through one or more different inbound "
+"tunnels. \n"
+"While I2P's peer selection and ordering strategies should sufficiently "
+"address \n"
+"predecessor attacks, should a switch to bidirectional tunnels be "
+"necessary,\n"
+"we could simply build an inbound and outbound tunnel along the same "
+"routers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:721
+msgid ""
+"Another anonymity issue comes up in Tor's use of telescopic tunnel "
+"creation, \n"
+"as simple packet counting and timing measurements as the cells in a "
+"circuit \n"
+"pass through an adversary's node exposes statistical information "
+"regarding \n"
+"where the adversary is within the circuit. I2P's unidirectional tunnel "
+"creation \n"
+"with a single message so that this data is not exposed. Protecting the "
+"position \n"
+"in a tunnel is important, as an adversary would otherwise be able to "
+"mount \n"
+"a series of powerful predecessor, intersection, and traffic confirmation "
+"attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:731
+msgid ""
+"Tor's support for a second tier of \"onion proxies\" does offer a non-"
+"trivial \n"
+"degree of anonymity while requiring a low cost of entry, while I2P will "
+"not \n"
+"offer this topology until 2.0."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:737
+msgid ""
+"On the whole, Tor and I2P complement each other in their focus - Tor "
+"works \n"
+"towards offering high speed anonymous Internet outproxying, while I2P "
+"works \n"
+"towards offering a decentralized resilient network in itself. In theory, "
+"both \n"
+"can be used to achieve both purposes, but given limited development "
+"resources, \n"
+"they both have their strengths and weaknesses. The I2P developers have "
+"considered \n"
+"the steps necessary to modify Tor to take advantage of I2P's design, but "
+"concerns \n"
+"of Tor's viability under resource scarcity suggest that I2P's packet "
+"switching \n"
+"architecture will be able to exploit scarce resources more effectively."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:751
+msgid ""
+"Freenet played a large part in the initial stages of I2P's design - "
+"giving \n"
+"proof to the viability of a vibrant pseudonymous community completely "
+"contained \n"
+"within the network, demonstrating that the dangers inherent in outproxies"
+" \n"
+"could be avoided. The first seed of I2P began as a replacement "
+"communication \n"
+"layer for Freenet, attempting to factor out the complexities of a "
+"scalable, \n"
+"anonymous and secure point to point communication from the complexities "
+"of \n"
+"a censorship resistant distributed data store. Over time however, some of"
+" \n"
+"the anonymity and scalability issues inherent in Freenet's algorithms "
+"made \n"
+"it clear that I2P's focus should stay strictly on providing a generic "
+"anonymous \n"
+"communication layer, rather than as a component of Freenet. Over the "
+"years, \n"
+"the Freenet developers have come to see the weaknesses in the older "
+"design, \n"
+"prompting them to suggest that they will require a \"premix\" layer to "
+"offer \n"
+"substantial anonymity. In other words, Freenet needs to run on top of a "
+"mixnet \n"
+"such as I2P or Tor, with \"client nodes\" requesting and publishing data "
+"through \n"
+"the mixnet to the \"server nodes\" which then fetch and store the data "
+"according \n"
+"to Freenet's heuristic distributed data storage algorithms."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:770
+msgid ""
+"Freenet's functionality is very complementary to I2P's, as Freenet "
+"natively \n"
+"provides many of the tools for operating medium and high latency systems,"
+" \n"
+"while I2P natively provides the low latency mix network suitable for "
+"offering \n"
+"adequate anonymity. The logic of separating the mixnet from the "
+"censorship-\n"
+"resistant distributed data store still seems self-evident from an "
+"engineering, \n"
+"anonymity, security, and resource allocation perspective, so hopefully "
+"the \n"
+"Freenet team will pursue efforts in that direction, if not simply reusing"
+" \n"
+"(or helping to improve, as necessary) existing mixnets like I2P or Tor."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:781
+msgid ""
+"It is worth mentioning that there has recently been discussion and work \n"
+"by the Freenet developers on a \"globally scalable darknet\" using "
+"restricted \n"
+"routes between peers of various trust. While insufficient information has"
+" \n"
+"been made publicly available regarding how such a system would operate "
+"for \n"
+"a full review, from what has been said the anonymity and scalability "
+"claims \n"
+"seem highly dubious. In particular, the appropriateness for use in "
+"hostile \n"
+"regimes against state level adversaries has been tremendously overstated,"
+" \n"
+"and any analysis on the implications of resource scarcity upon the "
+"scalability \n"
+"of the network has seemingly been avoided. Further questions regarding "
+"susceptibility \n"
+"to traffic analysis, trust and other topics do exist, but a more in-depth"
+" \n"
+"review of this \"globally scalable darknet\" will have to wait until the "
+"Freenet \n"
+"team makes more information available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:797
+msgid ""
+"I2P itself doesn't really do much - it simply sends messages to remote "
+"destinations \n"
+"and receives messages targeting local destinations - most of the "
+"interesting \n"
+"work goes on at the layers above it. By itself, I2P could be seen as an "
+"anonymous \n"
+"and secure IP layer, and the bundled streaming"
+" library \n"
+"as an implementation of an anonymous and secure TCP layer on top of it. "
+"Beyond \n"
+"that, I2PTunnel exposes a generic TCP "
+"proxying \n"
+"system for either getting into or out of the I2P network, plus a variety "
+"of \n"
+"network applications provide further functionality for end users."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:809
+msgid ""
+"The I2P streaming library can be viewed as a generic streaming interface "
+"(mirroring TCP sockets),\n"
+"and the implementation supports a sliding "
+"window protocol\n"
+"with several optimizations, to take into account the high delay over I2P."
+"\n"
+"Individual streams may adjust the maximum packet size and \n"
+"other options, though the default of 4KB compressed seems a reasonable "
+"tradeoff \n"
+"between the bandwidth costs of retransmitting lost messages and the "
+"latency \n"
+"of multiple messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:819
+msgid ""
+"In addition, in consideration of the relatively high cost of subsequent \n"
+"messages, the streaming library's protocol for scheduling and delivering "
+"messages \n"
+"has been optimized to allow individual messages passed to contain as much"
+" \n"
+"information as is available. For instance, a small HTTP transaction "
+"proxied \n"
+"through the streaming library can be completed in a single round trip - "
+"the \n"
+"first message bundles a SYN, FIN and the small payload (an HTTP request "
+"typically \n"
+"fits) and the reply bundles the SYN, FIN, ACK and the small payload (many"
+" \n"
+"HTTP responses fit). While an additional ACK must be transmitted to tell "
+"the \n"
+"HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy "
+"can \n"
+"deliver the full response to the browser immediately."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:832
+msgid ""
+"On the whole, however, the streaming library bears much resemblance to an"
+" \n"
+"abstraction of TCP, with its sliding windows, congestion control "
+"algorithms \n"
+"(both slow start and congestion avoidance), and general packet behavior "
+"(ACK, \n"
+"SYN, FIN, RST, etc)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:839
+msgid "Naming library and addressbook"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:840
+#, python-format
+msgid ""
+"For more information see the Naming and "
+"Addressbook page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:844
+#: i2p2www/pages/site/docs/how/tech-intro.html:918
+#: i2p2www/pages/site/docs/how/tech-intro.html:965
+#: i2p2www/pages/site/docs/how/tech-intro.html:997
+#: i2p2www/pages/site/docs/how/tech-intro.html:1005
+#: i2p2www/pages/site/docs/how/tech-intro.html:1013
+#: i2p2www/pages/site/docs/how/tech-intro.html:1023
+#: i2p2www/pages/site/docs/how/tech-intro.html:1031
+#: i2p2www/pages/site/docs/how/tech-intro.html:1053
+#, python-format
+msgid "Developed by: %(dev)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:846
+msgid ""
+"Naming within I2P has been an oft-debated topic since the very beginning"
+" \n"
+"with advocates across the spectrum of possibilities. However, given I2P's"
+" \n"
+"inherent demand for secure communication and decentralized operation, the"
+" \n"
+"traditional DNS-style naming system is clearly out, as are \"majority "
+"rules\" \n"
+"voting systems. Instead, I2P ships with a generic naming library and a "
+"base \n"
+"implementation designed to work off a local name to destination mapping, "
+"as \n"
+"well as an optional add-on application called the \"addressbook\". The "
+"addressbook \n"
+"is a web-of-trust-driven secure, distributed, and human readable naming "
+"system, \n"
+"sacrificing only the call for all human readable names to be globally "
+"unique \n"
+"by mandating only local uniqueness. While all messages in I2P are "
+"cryptographically \n"
+"addressed by their destination, different people can have local "
+"addressbook \n"
+"entries for \"Alice\" which refer to different destinations. People can "
+"still \n"
+"discover new names by importing published addressbooks of peers specified"
+" \n"
+"in their web of trust, by adding in the entries provided through a third "
+"party, \n"
+"or (if some people organize a series of published addressbooks using a "
+"first \n"
+"come first serve registration system) people can choose to treat these "
+"addressbooks \n"
+"as name servers, emulating traditional DNS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:866
+msgid ""
+"I2P does not promote the use of DNS-like services though, as the damage \n"
+"done by hijacking a site can be tremendous - and insecure destinations "
+"have \n"
+"no value. DNSsec itself still falls back on registrars and certificate "
+"authorities, \n"
+"while with I2P, requests sent to a destination cannot be intercepted or "
+"the \n"
+"reply spoofed, as they are encrypted to the destination's public keys, "
+"and \n"
+"a destination itself is just a pair of public keys and a certificate. "
+"DNS-style \n"
+"systems on the other hand allow any of the name servers on the lookup "
+"path \n"
+"to mount simple denial of service and spoofing attacks. Adding on a "
+"certificate \n"
+"authenticating the responses as signed by some centralized certificate "
+"authority \n"
+"would address many of the hostile nameserver issues but would leave open "
+"replay \n"
+"attacks as well as hostile certificate authority attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:880
+msgid ""
+"Voting style naming is dangerous as well, especially given the "
+"effectiveness \n"
+"of Sybil attacks in anonymous systems - the attacker can simply create an"
+" \n"
+"arbitrarily high number of peers and \"vote\" with each to take over a "
+"given \n"
+"name. Proof-of-work methods can be used to make identity non-free, but as"
+" \n"
+"the network grows the load required to contact everyone to conduct online"
+" \n"
+"voting is implausible, or if the full network is not queried, different "
+"sets \n"
+"of answers may be reachable."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:890
+msgid ""
+"As with the Internet however, I2P is keeping the design and operation of"
+" \n"
+"a naming system out of the (IP-like) communication layer. The bundled "
+"naming \n"
+"library includes a simple service provider interface which alternate "
+"naming \n"
+"systems can plug into, allowing end users to drive what sort of naming "
+"tradeoffs \n"
+"they prefer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:899
+msgid ""
+"The old Syndie bundled with I2P has been replaced by the new Syndie which"
+"\n"
+"is distributed separately. For more information see the Syndie\n"
+"pages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:905
+msgid ""
+"Syndie is a safe, anonymous blogging / content publication / content "
+"aggregation \n"
+"system. It lets you create information, share it with others, and read "
+"posts \n"
+"from those you're interested in, all while taking into consideration your"
+" \n"
+"needs for security and anonymity. Rather than building its own content "
+"distribution \n"
+"network, Syndie is designed to run on top of existing networks, "
+"syndicating \n"
+"content through eepsites, Tor hidden services, Freenet freesites, normal "
+"websites, \n"
+"usenet newsgroups, email lists, RSS feeds, etc. Data published with "
+"Syndie \n"
+"is done so as to offer pseudonymous authentication to anyone reading or "
+"archiving \n"
+"it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:920
+msgid ""
+"I2PTunnel is probably I2P's most popular and versatile client "
+"application, \n"
+"allowing generic proxying both into and out of the I2P network. I2PTunnel"
+" \n"
+"can be viewed as four separate proxying applications - a \"client\" which"
+" receives \n"
+"inbound TCP connections and forwards them to a given I2P destination, an "
+"\"httpclient\" \n"
+"(aka \"eepproxy\") which acts like an HTTP proxy and forwards the "
+"requests to \n"
+"the appropriate I2P destination (after querying the naming service if "
+"necessary), \n"
+"a \"server\" which receives inbound I2P streaming connections on a "
+"destination \n"
+"and forwards them to a given TCP host+port, and an \"httpserver\" which "
+"extends \n"
+"the \"server\" by parsing the HTTP request and responses to allow safer "
+"operation. \n"
+"There is an additional \"socksclient\" application, but its use is not "
+"encouraged \n"
+"for reasons previously mentioned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:934
+msgid ""
+"I2P itself is not an outproxy network - the anonymity and security "
+"concerns \n"
+"inherent in a mix net which forwards data into and out of the mix have "
+"kept \n"
+"I2P's design focused on providing an anonymous network which capable of "
+"meeting \n"
+"the user's needs without requiring external resources. However, the "
+"I2PTunnel \n"
+"\"httpclient\" application offers a hook for outproxying - if the "
+"hostname requested \n"
+"doesn't end in \".i2p\", it picks a random destination from a user-"
+"provided \n"
+"set of outproxies and forwards the request to them. These destinations "
+"are \n"
+"simply I2PTunnel \"server\" instances run by volunteers who have "
+"explicitly \n"
+"chosen to run outproxies - no one is an outproxy by default, and running "
+"an \n"
+"outproxy doesn't automatically tell other people to proxy through you. "
+"While \n"
+"outproxies do have inherent weaknesses, they offer a simple proof of "
+"concept \n"
+"for using I2P and provide some functionality under a threat model which "
+"may \n"
+"be sufficient for some users."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:950
+msgid ""
+"I2PTunnel enables most of the applications in use. An \"httpserver\" "
+"pointing \n"
+"at a webserver lets anyone run their own anonymous website (or "
+"\"eepsite\") \n"
+"- a webserver is bundled with I2P for this purpose, but any webserver can"
+" \n"
+"be used. Anyone may run a \"client\" pointing at one of the anonymously "
+"hosted \n"
+"IRC servers, each of which are running a \"server\" pointing at their "
+"local \n"
+"IRCd and communicating between IRCds over their own \"client\" tunnels. "
+"End \n"
+"users also have \"client\" tunnels pointing at I2Pmail's \n"
+"POP3 and SMTP destinations (which in turn are simply \"server\" instances"
+" pointing \n"
+"at POP3 and SMTP servers), as well as \"client\" tunnels pointing at "
+"I2P's CVS \n"
+"server, allowing anonymous development. At times people have even run "
+"\"client\" \n"
+"proxies to access the \"server\" instances pointing at an NNTP server."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:967
+msgid ""
+"i2p-bt is a port of the mainline python BitTorrent client to run both the"
+" \n"
+"tracker and peer communication over I2P. Tracker requests are forwarded "
+"through \n"
+"the eepproxy to eepsites specified in the torrent file while tracker "
+"responses \n"
+"refer to peers by their destination explicitly, allowing i2p-bt to open "
+"up \n"
+"a streaming lib connection to query them "
+"for \n"
+"blocks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:976
+msgid ""
+"In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making"
+" \n"
+"a few modifications as necessary to strip any anonymity-compromising "
+"information \n"
+"from the application and to take into consideration the fact that IPs "
+"cannot \n"
+"be used for identifying peers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:984
+msgid ""
+"I2PSnark developed: jrandom, et al, ported from mjw's Snark client"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:990
+msgid ""
+"Bundled with the I2P install, I2PSnark offers a simple anonymous "
+"BitTorrent \n"
+"client with multitorrent capabilities, exposing all of the functionality "
+"through \n"
+"a plain HTML web interface."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:999
+#, python-format
+msgid ""
+"Robert is a Bittorrent client written in Python.\n"
+"It is hosted on http://%(bob)s/Robert.html "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1007
+#, python-format
+msgid ""
+"PyBit is a Bittorrent client written in Python.\n"
+"It is hosted on http://%(pebcache)s/"
+" "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1015
+msgid ""
+"I2Phex is a fairly direct port of the Phex Gnutella filesharing client to"
+" \n"
+"run entirely on top of I2P. While it has disabled some of Phex's "
+"functionality, \n"
+"such as integration with Gnutella webcaches, the basic file sharing and "
+"chatting \n"
+"system is fully functional."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1025
+msgid ""
+"iMule is a fairly direct port of the aMule filesharing client \n"
+"running entirely inside I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1033
+#, python-format
+msgid ""
+"I2Pmail is more a service than an application - postman offers both "
+"internal \n"
+"and external email with POP3 and SMTP service through I2PTunnel instances"
+" \n"
+"accessing a series of components developed with mastiejaner, allowing "
+"people \n"
+"to use their preferred mail clients to send and receive mail "
+"pseudonymously. \n"
+"However, as most mail clients expose substantial identifying information,"
+" \n"
+"I2P bundles susi23's web based susimail client which has been built "
+"specifically \n"
+"with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers "
+"transparent \n"
+"virus filtering as well as denial of service prevention with hashcash "
+"augmented \n"
+"quotas. In addition, each user has control of their batching strategy "
+"prior \n"
+"to delivery through the mail.i2p outproxies, which are separate from the "
+"mail.i2p \n"
+"SMTP and POP3 servers - both the outproxies and inproxies communicate "
+"with \n"
+"the mail.i2p SMTP and POP3 servers through I2P itself, so compromising "
+"those \n"
+"non-anonymous locations does not give access to the mail accounts or "
+"activity \n"
+"patterns of the user. At the moment the developers work on a "
+"decentralized \n"
+"mailsystem, called \"v2mail\". More information can be found on the "
+"eepsite \n"
+"%(postman)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1055
+msgid ""
+"I2P-Bote is a distributed e-mail application. It does not use the "
+"traditional\n"
+"e-mail concept of sending an e-mail to a server and retrieving it from a "
+"server.\n"
+"Instead, it uses a Kademlia Distributed Hash Table to store mails.\n"
+"One user can push a mail into the DHT, while another can request the "
+"e-mail from the DHT.\n"
+"And all the mails sent within the I2P-Bote network are automatically "
+"encrypted end-to-end. 
            \n"
+"Furthermore, I2P-Bote offers a remailer function on top of I2P, for "
+"increased high-latency anonymity."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tech-intro.html:1065
+msgid ""
+"I2P-Messenger is an end-to-end encrypted serverless communication "
+"application.\n"
+"For communication between two users, they need to give each other their "
+"destination keys, to allow the other to connect.\n"
+"It supports file transfer and has a search for other users, based on "
+"Seedless."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:2
+msgid "I2P's Threat Model"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:3
+msgid "November 2010"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:6
+msgid "What do we mean by \"anonymous\"?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:8
+msgid ""
+"Your level of anonymity can be described as \"how hard it is for someone\n"
+"to find out information you don't want them to know?\" - who you are, "
+"where\n"
+"you are located, who you communicate with, or even when you communicate."
+"  \n"
+"\"Perfect\" anonymity is not a useful concept here - software will not "
+"make \n"
+"you indistinguishable from people that don't use computers or who are not"
+" on\n"
+"the Internet.  Instead, we are working to provide sufficient anonymity to"
+" meet the\n"
+"real needs of whomever we can - from those simply browsing websites, to "
+"those exchanging\n"
+"data, to those fearful of discovery by powerful organizations or states."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:19
+msgid ""
+"The question of whether I2P provides sufficient anonymity for your \n"
+"particular needs is a hard one, but this page will hopefully assist in \n"
+"answering that question by exploring how I2P operates under various "
+"attacks\n"
+"so that you may decide whether it meets your needs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:26
+msgid ""
+"We welcome further research and analysis on I2P's resistance to the "
+"threats described below.\n"
+"More review of existing literature (much of it focused on Tor) and "
+"original\n"
+"work focused on I2P is needed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:32
+msgid "Network Topology Summary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:33
+#, python-format
+msgid ""
+"I2P builds off the ideas of many other \n"
+"systems, but a few key points should be kept in"
+" mind when \n"
+"reviewing related literature:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:39
+msgid ""
+"I2P is a free route mixnet - the message creator explicitly "
+"defines the\n"
+"path that messages will be sent out (the outbound tunnel), and the "
+"message \n"
+"recipient explicitly defines the path that messages will be received on "
+"(the\n"
+"inbound tunnel)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:45
+msgid ""
+"I2P has no official entry and exit points - all peers fully "
+"participate in the \n"
+"mix, and there are no network layer in- or out-proxies (however, at the \n"
+"application layer, a few proxies do exist)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:50
+msgid ""
+"I2P is fully distributed - there are no central controls or "
+"authorities.\n"
+"One could modify some routers to operate mix cascades (building tunnels "
+"and giving\n"
+"out the keys necessary to control the forwarding at the tunnel endpoint) "
+"or directory \n"
+"based profiling and selection, all without breaking compatibility with "
+"the rest of \n"
+"the network, but doing so is of course not necessary (and may even harm "
+"one's\n"
+"anonymity)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:60
+#, python-format
+msgid ""
+"We have documented plans to implement nontrivial delays\n"
+"and batching strategies \n"
+"whose existence is only known to the particular hop or tunnel gateway "
+"that \n"
+"receives the message, allowing a mostly low latency mixnet to provide "
+"cover \n"
+"traffic for higher latency communication (e.g. email).\n"
+"However we are aware that significant delays are required to provide "
+"meaningful\n"
+"protection, and that implementation of such delays will be a significant "
+"challenge.\n"
+"It is not clear at this time whether we will actually implement these "
+"delay features."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:71
+msgid ""
+"In theory, routers along the message path may inject an \n"
+"arbitrary number of hops before forwarding the message to the next peer, "
+"though\n"
+"the current implementation does not."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:78
+msgid "The Threat Model (Attacks)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:79
+msgid ""
+"I2P design started in 2003, not long after the advent of\n"
+"[Onion Routing],\n"
+"[Freenet], and\n"
+"[Tor].\n"
+"Our design benefits substantially from the research published around that"
+" time.\n"
+"I2P uses several onion routing techniques, so we continue to benefit\n"
+"from the significant academic interest in Tor."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:89
+msgid ""
+"Taking from the attacks and analysis put forth in the \n"
+"anonymity "
+"literature (largely \n"
+"Traffic Analysis: "
+"Protocols, Attacks, Design \n"
+"Issues and Open Problems), the following briefly describes a wide "
+"variety \n"
+"of attacks as well as many of I2Ps defenses.  We update\n"
+"this list to include new attacks as they are identified."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:98
+msgid ""
+"Included are some attacks that may be unique to I2P.\n"
+"We do not have good answers for all these attacks, however\n"
+"we continue to do research and improve our defenses."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:104
+msgid ""
+"In addition, many of these attacks are significantly easier than\n"
+"they should be, due to the modest size of the current network.\n"
+"While we are aware of some limitations that need to be addressed,\n"
+"I2P is designed to support hundreds of thousands, or millions, of\n"
+"participants.\n"
+"As we continue to spread the word and grow the network,\n"
+"these attacks will become much harder."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:114
+#, python-format
+msgid ""
+"The\n"
+"network comparisons and\n"
+"\"garlic\" terminology pages may also "
+"be helpful\n"
+"to review."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:123
+#: i2p2www/pages/site/docs/how/threat-model.html:143
+msgid "Brute force attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:124
+#: i2p2www/pages/site/docs/how/threat-model.html:185
+msgid "Timing attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:125
+#: i2p2www/pages/site/docs/how/threat-model.html:220
+msgid "Intersection attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:126
+#: i2p2www/pages/site/docs/how/threat-model.html:298
+msgid "Denial of service attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:127
+#: i2p2www/pages/site/docs/how/threat-model.html:385
+msgid "Tagging attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:128
+#: i2p2www/pages/site/docs/how/threat-model.html:400
+msgid "Partitioning attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:129
+#: i2p2www/pages/site/docs/how/threat-model.html:438
+msgid "Predecessor attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:130
+#: i2p2www/pages/site/docs/how/threat-model.html:481
+msgid "Harvesting attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:131
+#: i2p2www/pages/site/docs/how/threat-model.html:525
+msgid "Identification Through Traffic Analysis"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:132
+#: i2p2www/pages/site/docs/how/threat-model.html:582
+msgid "Sybil attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:133
+#: i2p2www/pages/site/docs/how/threat-model.html:629
+msgid "Buddy Exhaustion attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:134
+#: i2p2www/pages/site/docs/how/threat-model.html:651
+msgid "Cryptographic attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:135
+msgid "Floodfill attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:136
+#: i2p2www/pages/site/docs/how/threat-model.html:707
+msgid "Other Network Database attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:137
+msgid "Attacks on centralized resources"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:138
+#: i2p2www/pages/site/docs/how/threat-model.html:770
+msgid "Development attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:139
+msgid "Implementation attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:140
+#: i2p2www/pages/site/docs/how/threat-model.html:849
+msgid "Other Defenses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:145
+msgid ""
+"A brute force attack can be mounted by a global passive or active "
+"adversary, \n"
+"watching all the messages pass between all of the nodes and attempting to"
+" correlate\n"
+"which message follows which path.  Mounting this attack against I2P "
+"should be \n"
+"nontrivial, as all peers in the network are frequently sending messages "
+"(both\n"
+"end to end and network maintenance messages), plus an end to end message "
+"changes\n"
+"size and data along its path.  In addition, the external adversary does "
+"not have\n"
+"access to the messages either, as inter-router communication is both "
+"encrypted\n"
+"and streamed (making two 1024 byte messages indistinguishable from one "
+"2048 byte\n"
+"message)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:157
+msgid ""
+"However, a powerful attacker can use brute force to detect trends - if "
+"they \n"
+"can send 5GB to an I2P destination and monitor everyone's network "
+"connection,\n"
+"they can eliminate all peers who did not receive 5GB of data.  Techniques"
+" to \n"
+"defeat this attack exist, but may be prohibitively expensive (see: \n"
+"Tarzan's "
+"mimics\n"
+"or constant rate traffic).  Most users are not concerned with this "
+"attack, as \n"
+"the cost of mounting it are extreme (and often require illegal activity)."
+"  \n"
+"However, the attack is still possible, for example by an observer at\n"
+"a large ISP or an Internet exchange point.\n"
+"Those who want to defend against it \n"
+"would want to take appropriate countermeasures, such as\n"
+"setting low bandwidth limits, and using unpublished or encrypted "
+"leasesets for eepsites.\n"
+"Other countermeasures, such as nontrivial delays and restricted routes, "
+"are\n"
+"not currently implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:174
+#, python-format
+msgid ""
+"As a partial defense against a single router or group of routers trying "
+"to route all the network's traffic,\n"
+"routers contain limits as to how many tunnels can be routed through a "
+"single peer.\n"
+"As the network grows, these limits are subject to further adjustment.\n"
+"Other mechanisms for peer rating, selection and avoidance\n"
+"are discussed on the\n"
+"peer selection page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:187
+msgid ""
+"I2P's messages are unidirectional and do not necessarily imply that a "
+"reply\n"
+"will be sent.  However, applications on top of I2P will most likely have\n"
+"recognizable patterns within the frequency of their messages - for "
+"instance, an \n"
+"HTTP request will be a small message with a large sequence of reply "
+"messages \n"
+"containing the HTTP response.  Using this data as well as a broad view of"
+" the \n"
+"network topology, an attacker may be able to disqualify some links as "
+"being too \n"
+"slow to have passed the message along."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:197
+msgid ""
+"This sort of attack is powerful, but its applicability to I2P is non "
+"obvious,\n"
+"as the variation on message delays due to queuing, message processing, "
+"and \n"
+"throttling will often meet or exceed the time of passing a message along "
+"a \n"
+"single link - even when the attacker knows that a reply will be sent as "
+"soon as\n"
+"the message is received.  There are some scenarios which will expose "
+"fairly \n"
+"automatic replies though - the streaming library does (with the SYN+ACK) "
+"as does the \n"
+"message mode of guaranteed delivery (with the "
+"DataMessage+DeliveryStatusMessage)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:207
+#, python-format
+msgid ""
+"Without protocol scrubbing or higher latency, global active adversaries "
+"can \n"
+"gain substantial information.  As such, people concerned with these "
+"attacks could\n"
+"increase the latency (using nontrivial "
+"delays or \n"
+"batching strategies), include protocol "
+"scrubbing, or\n"
+"other advanced tunnel routing techniques,\n"
+"but these are unimplemented in I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:216
+#, python-format
+msgid ""
+"References: Low-Resource Routing Attacks Against "
+"Anonymous Systems"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:222
+msgid ""
+"Intersection attacks against low latency systems are extremely powerful -"
+"\n"
+"periodically make contact with the target and keep track of what peers "
+"are on\n"
+"the network.  Over time, as node churn occurs the attacker will gain \n"
+"significant information about the target by simply intersecting the sets "
+"of\n"
+"peers that are online when a message successfully goes through.  The cost"
+" of \n"
+"this attack is significant as the network grows, but may be feasible in "
+"some\n"
+"scenarios."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:232
+#, python-format
+msgid ""
+"In summary, if an attacker is at both ends of your tunnel at the same "
+"time,\n"
+"he may be successful.\n"
+"I2P does not have a full defense to this for low latency communication.\n"
+"This is an inherent weakness of low-latency onion routing.\n"
+"Tor provides a similar disclaimer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:240
+msgid "Partial defenses implemented in I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:244
+#, python-format
+msgid "strict ordering of peers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:247
+#, python-format
+msgid ""
+"peer profiling and selection from a "
+"small group that changes slowly"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:250
+msgid "Limits on the number of tunnels routed through a single peer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:253
+msgid ""
+"Prevention of peers from the same /16 IP range from being members of a "
+"single tunnel"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:256
+msgid ""
+"For eepsites or other hosted services, we support\n"
+"simultaneous hosting on multiple routers, or\n"
+"multihoming"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:263
+msgid ""
+"Even in total, these defenses are not a complete solution.\n"
+"Also, we have made some design choices that may significantly increase "
+"our vulnerability:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:268
+msgid "We do not use low-bandwidth \"guard nodes\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:271
+msgid ""
+"We use tunnel pools comprised of several tunnels, and traffic can shift "
+"from tunnel to tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:274
+msgid "Tunnels are not long-lived; new tunnels are built every 10 minutes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:277
+msgid ""
+"Tunnel lengths are configurable.\n"
+"While 3-hop tunnels are recommended for full protection, several "
+"applications and\n"
+"services use 2-hop tunnels by default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:284
+#, python-format
+msgid ""
+"In the future, it could\n"
+"for peers who can afford significant delays (per nontrivial\n"
+"delays and batching strategies).  "
+"In addition,\n"
+"this is only relevant for destinations that other people know about - a "
+"private\n"
+"group whose destination is only known to trusted peers does not have to "
+"worry,\n"
+"as an adversary can't \"ping\" them to mount the attack.
            "
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:293
+#, python-format
+msgid "Reference: One Cell Enough"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:300
+msgid ""
+"There are a whole slew of denial of service attacks available against "
+"I2P,\n"
+"each with different costs and consequences:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:305
+msgid ""
+"Greedy user attack: This is simply\n"
+"people trying to consume significantly more resources than they are \n"
+"willing to contribute. The defense against this is:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:311
+#, python-format
+msgid ""
+"Set defaults so that most users provide resources to the network.\n"
+"In I2P, users route traffic by default. In sharp distinction to\n"
+"other networks,\n"
+"over 95%% of I2P users relay traffic for others."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:317
+msgid ""
+"Provide easy configuration options so that users may increase their\n"
+"contribution (share percentage) to the network. Display easy-to-"
+"understand\n"
+"metrics such as \"share ratio\" so that users may see what they are "
+"contributing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:322
+msgid ""
+"Maintain a strong community with blogs, forums, IRC, and other means of "
+"communication."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:327
+#, python-format
+msgid ""
+"Starvation attack: A hostile user may attempt to harm the network "
+"by\n"
+"creating a significant number of peers in the network who are not "
+"identified as\n"
+"being under control of the same entity (as with Sybil). These nodes then"
+" \n"
+"decide not to provide any resources to the network, causing existing "
+"peers \n"
+"to search through a larger network database or request more tunnels than"
+" \n"
+"should be necessary. \n"
+"Alternatively, the nodes may provide intermittent service by periodically"
+"\n"
+"dropping selected traffic, or refusing connections to certain peers.\n"
+"This behavior may be indistinguishable from that of a heavily-loaded or "
+"failing node.\n"
+"I2P addresses these issues by maintaining profiles on the \n"
+"peers, attempting to identify underperforming ones and simply ignoring \n"
+"them, or using them rarely.\n"
+"We have significantly enhanced the\n"
+"ability to recognize and avoid troublesome peers; however there are still"
+"\n"
+"significant efforts required in this area."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:344
+#, python-format
+msgid ""
+"Flooding attack: A hostile user may attempt to flood the network,\n"
+"a peer, a destination, or a tunnel.  Network and peer flooding is "
+"possible,\n"
+"and I2P does nothing to prevent standard IP layer flooding.  The flooding"
+" of\n"
+"a destination with messages by sending a large number to the target's "
+"various\n"
+"inbound tunnel gateways is possible, but the destination will know this "
+"both\n"
+"by the contents of the message and because the tunnel's tests will fail."
+"  The\n"
+"same goes for flooding just a single tunnel.  I2P has no defenses for a "
+"network\n"
+"flooding attack.  For a destination and tunnel flooding attack, the "
+"target\n"
+"identifies which tunnels are unresponsive and builds new ones.  New code "
+"could\n"
+"also be written to add even more tunnels if the client wishes to handle "
+"the\n"
+"larger load.  If, on the other hand, the load is more than the client can"
+"\n"
+"deal with, they can instruct the tunnels to throttle the number of "
+"messages or\n"
+"bytes they should pass on (once the advanced tunnel\n"
+"operation is implemented)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:360
+msgid ""
+"CPU load attack: There are currently some methods for people to \n"
+"remotely request that a peer perform some cryptographically expensive \n"
+"operation, and a hostile attacker could use these to flood that peer with"
+"\n"
+"a large number of them in an attempt to overload the CPU.  Both using "
+"good \n"
+"engineering practices and potentially requiring nontrivial certificates \n"
+"(e.g. HashCash) to be attached to these expensive requests should "
+"mitigate\n"
+"the issue, though there may be room for an attacker to exploit various\n"
+"bugs in the implementation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:370
+#, python-format
+msgid ""
+"Floodfill DOS attack: A hostile user may attempt to harm the "
+"network by\n"
+"becoming a floodfill router. The current defenses against unreliable,\n"
+"intermittent, or malicious floodfill routers are poor.\n"
+"A floodfill router may provide bad or no response to lookups, and\n"
+"it may also interfere with inter-floodfill communication.\n"
+"Some defenses and\n"
+"peer profiling are implemented,\n"
+"however there is much more to do.\n"
+"For more information see the\n"
+"network database page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:386
+#, python-format
+msgid ""
+"Tagging attacks - modifying a message so that it can later be identified"
+" \n"
+"further along the path - are by themselves impossible in I2P, as messages"
+" \n"
+"passed through tunnels are signed.  However, if an attacker is the "
+"inbound \n"
+"tunnel gateway as well as a participant further along in that tunnel, "
+"with\n"
+"collusion they can identify the fact that they are in the same tunnel "
+"(and \n"
+"prior to adding unique hop ids and "
+"other updates,\n"
+"colluding peers within the same tunnel can recognize that fact without "
+"any \n"
+"effort).  An attacker in an outbound tunnel and any part of an inbound "
+"tunnel cannot \n"
+"collude however, as the tunnel encryption pads and modifies the data "
+"separately\n"
+"for the inbound and outbound tunnels.  External attackers cannot do "
+"anything,\n"
+"as the links are encrypted and messages signed."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:402
+msgid ""
+"Partitioning attacks - finding ways to segregate (technically or "
+"analytically)\n"
+"the peers in a network - are important to keep in mind when dealing with "
+"a \n"
+"powerful adversary, since the size of the network plays a key role in "
+"determining\n"
+"your anonymity.  Technical partitioning by cutting links between peers to"
+" create\n"
+"fragmented networks is addressed by I2P's built in network database, "
+"which \n"
+"maintains statistics about various peers so as to allow any existing "
+"connections\n"
+"to other fragmented sections to be exploited so as to heal the network.  "
+"However,\n"
+"if the attacker does disconnect all links to uncontrolled peers, "
+"essentially\n"
+"isolating the target, no amount of network database healing will fix it."
+"  At\n"
+"that point, the only thing the router can hope to do is notice that a "
+"significant\n"
+"number of previously reliable peers have become unavailable and alert the"
+" client\n"
+"that it is temporarily disconnected (this detection code is not "
+"implemented at\n"
+"the moment)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:418
+#, python-format
+msgid ""
+"Partitioning the network analytically by looking for differences in how "
+"routers \n"
+"and destinations behave and grouping them accordingly is also a very "
+"powerful\n"
+"attack.  For instance, an attacker harvesting"
+" the network\n"
+"database will know when a particular destination has 5 inbound tunnels in"
+" their\n"
+"LeaseSet while others have only 2 or 3, allowing the adversary to "
+"potentially \n"
+"partition clients by the number of tunnels selected.  Another partition "
+"is \n"
+"possible when dealing with the nontrivial "
+"delays and \n"
+"batching strategies, as the tunnel "
+"gateways and the\n"
+"particular hops with non-zero delays will likely stand out.  However, "
+"this data\n"
+"is only exposed to those specific hops, so to partition effectively on "
+"that \n"
+"matter, the attacker would need to control a significant portion of the "
+"network\n"
+"(and still that would only be a probabilistic partition, as they wouldn't"
+" know\n"
+"which other tunnels or messages have those delays)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:434
+#, python-format
+msgid ""
+"Also discussed on the network database "
+"page (bootstrap attack)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:440
+msgid ""
+"The predecessor attack is passively gathering statistics in an attempt to"
+" see\n"
+"what peers are 'close' to the destination by participating in their "
+"tunnels and\n"
+"keeping track of the previous or next hop (for outbound or inbound "
+"tunnels, \n"
+"respectively).  Over time, using a perfectly random sample of peers and "
+"random\n"
+"ordering, an attacker would be able to see which peer shows up as "
+"'closer' \n"
+"statistically more than the rest, and that peer would in turn be where "
+"the\n"
+"target is located."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:450
+#, python-format
+msgid ""
+"I2P avoids this in four ways: first, the peers selected to participate in"
+"\n"
+"tunnels are not randomly sampled throughout the network - they are "
+"derived from\n"
+"the peer selection algorithm which "
+"breaks them\n"
+"into tiers.  Second, with strict "
+"ordering of peers\n"
+"in a tunnel, the fact that a peer shows up more frequently does not mean "
+"they're\n"
+"the source.  Third, with permuted "
+"tunnel length\n"
+"(not enabled by default)\n"
+"even 0 hop tunnels can provide plausible deniability as the occasional \n"
+"variation of the gateway will look like normal tunnels.  Fourth, with \n"
+"restricted routes "
+"(unimplemented), only the peer with\n"
+"a restricted connection to the target will ever contact the target, while"
+" \n"
+"attackers will merely run into that gateway."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:467
+#, python-format
+msgid ""
+"The current tunnel build method\n"
+"was specifically designed to combat the predecessor attack.\n"
+"See also the intersection attack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:473
+#, python-format
+msgid ""
+"References: %(pdf2008)s\n"
+"which is an update to the 2004 predecessor attack paper\n"
+"%(pdf2004)s."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:482
+msgid ""
+"\"Harvesting\" means compiling a list of users running I2P.\n"
+"It can be used for legal attacks and to help\n"
+"other attacks by simply running a peer, seeing who it connects to, and \n"
+"harvesting whatever references to other peers it can find."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:489
+msgid ""
+"I2P itself is not designed with effective defenses against\n"
+"this attack, since there is the distributed network database \n"
+"containing just this information.\n"
+"The following factors make the attack somewhat harder in practice:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:496
+msgid ""
+"Network growth will make it more difficult to obtain a given proportion "
+"of the network"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:499
+msgid "Floodfill routers implement query limits as DOS protection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:502
+msgid ""
+"\"Hidden mode\", which prevents a router from publishing its information "
+"to the netDb,\n"
+"(but also prevents it from relaying data) is not widely used now but "
+"could be."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:508
+#, python-format
+msgid ""
+"In future implementations,\n"
+"basic and \n"
+"comprehensive restricted "
+"routes,\n"
+"this attack loses much of its power, as the \"hidden\" peers do not "
+"publish their\n"
+"contact addresses in the network database - only the tunnels through "
+"which \n"
+"they can be reached (as well as their public keys, etc)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:517
+msgid ""
+"In the future, routers could use GeoIP to identify if they are in a "
+"particular\n"
+"country where identification as an I2P node would be risky.\n"
+"In that case, the router could automatically enable hidden mode, or\n"
+"enact other restricted route methods."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:526
+#, python-format
+msgid ""
+"By inspecting the traffic into and out of a router, a malicious ISP\n"
+"or state-level firewall could identify that a computer is running I2P.\n"
+"As discussed above, I2P is not specifically "
+"designed\n"
+"to hide that a computer is running I2P. However, several design decisions"
+" made\n"
+"in the design of the\n"
+"transport layer and protocols\n"
+"make it somewhat difficult to identify I2P traffic:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:536
+msgid "Random port selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:539
+msgid "Point-to-Point Encryption of all traffic"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:542
+msgid ""
+"DH key exchange with no protocol bytes or other unencrypted constant "
+"fields"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:545
+#, python-format
+msgid ""
+"Simultaneous use of both\n"
+"TCP and\n"
+"UDP transports.\n"
+"UDP may be much harder for some Deep Packet Inspection (DPI) equipment to"
+" track."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:553
+msgid ""
+"In the near future, we plan to directly address traffic analysis issues "
+"by further obfuscation of I2P transport protocols, possibly including:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:557
+msgid ""
+"Padding at the transport layer to random lengths, especially during the "
+"connection handshake"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:560
+msgid ""
+"Study of packet size distribution signatures, and additional padding as "
+"necessary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:563
+msgid ""
+"Development of additional transport methods that mimic SSL or other "
+"common protocols"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:566
+msgid ""
+"Review of padding strategies at higher layers to see how they affect "
+"packet sizes at the transport layer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:569
+msgid ""
+"Review of methods implemented by various state-level firewalls to block "
+"Tor"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:572
+msgid "Working directly with DPI and obfuscation experts"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:577
+#, python-format
+msgid ""
+"Reference: Breaking and Improving Protocol "
+"Obfuscation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:584
+#, python-format
+msgid ""
+"Sybil describes a category of attacks where the adversary creates "
+"arbitrarily\n"
+"large numbers of colluding nodes and uses the increased numbers to help \n"
+"mounting other attacks.  For instance, if an attacker is in a network "
+"where peers\n"
+"are selected randomly and they want an 80% chance to be one of those "
+"peers, they\n"
+"simply create five times the number of nodes that are in the network and "
+"roll \n"
+"the dice.  When identity is free, Sybil can be a very potent technique "
+"for a \n"
+"powerful adversary.  The primary technique to address this is simply to "
+"make \n"
+"identity 'non free' - Tarzan\n"
+"(among others) uses the fact that IP addresses are limited, while \n"
+"IIP used \n"
+"HashCash to 'charge' for "
+"creating a new\n"
+"identity.  We currently have not implemented any particular technique to "
+"address\n"
+"Sybil, but do include placeholder certificates in the router's and \n"
+"destination's data structures which can contain a HashCash certificate of"
+" \n"
+"appropriate value when necessary (or some other certificate proving "
+"scarcity)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:602
+msgid "Requiring HashCash Certificates in various places has two major problems:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:606
+msgid "Maintaining backward compatibility"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:609
+msgid ""
+"The classic HashCash problem -\n"
+"selecting HashCash values that are meaningful proofs of work on high-end "
+"machines,\n"
+"while still being feasible on low-end machines such as mobile devices."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:616
+msgid ""
+"Various limitations on the number of routers in a given IP range restrict"
+"\n"
+"the vulnerability to attackers that don't have the ability to put "
+"machines\n"
+"in several IP blocks.\n"
+"However, this is not a meaningful defense against a powerful adversary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:623
+#, python-format
+msgid ""
+"See the network database page\n"
+"for more Sybil discussion."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:630
+#, python-format
+msgid ""
+"(Reference: In Search of an Anonymouns and Secure "
+"Lookup Section 5.2)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:634
+#, python-format
+msgid ""
+"By refusing to accept or forward tunnel build requests, except to a "
+"colluding peer, a router could ensure\n"
+"that a tunnel is formed wholly from its set of colluding routers.\n"
+"The chances of success are enhanced if there is a large number of "
+"colluding routers,\n"
+"i.e. a Sybil attack.\n"
+"This is somewhat mitigated by our\n"
+"peer profiling methods used to monitor "
+"the performance\n"
+"of peers.\n"
+"However, this is a powerful attack as the number of routers approaches\n"
+"f = 0.2, or 20%% malicious nodes, as specifed in the paper.\n"
+"The malicous routers could also maintain connections to the target router"
+" and provide\n"
+"excellent forwarding bandwidth for traffic over those connections, in an "
+"attempt\n"
+"to manipulate the profiles managed by the target and appear attractive.\n"
+"Further research and defenses may be necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:653
+#, python-format
+msgid ""
+"We use strong cryptography with long keys, and\n"
+"we assume the security of the industry-standard cryptographic primitives "
+"used in I2P, as documented\n"
+"on the low-level cryptography page. \n"
+"Security features include the immediate detection of \n"
+"altered messages along the path, the inability to decrypt messages not "
+"addressed to you,\n"
+"and defense against man-in-the-middle attacks.\n"
+"The key sizes chosen in 2003 were quite conservative at the time, and are"
+" still longer than\n"
+"those used in other anonymity "
+"networks.\n"
+"We don't think the current key lengths are our biggest weakness,\n"
+"especially for traditional, non-state-level adversaries;\n"
+"bugs and the small size of the network are much more worrisome.\n"
+"Of course, all cryptographic algorithms eventually become obsolete due to"
+"\n"
+"the advent of faster processors, cryptographic research, and advancements"
+" in\n"
+"methods such as rainbow tables, clusters of video game hardware, etc.\n"
+"Unfortunately, I2P was not designed with easy mechanisms to lengthen keys"
+" or change\n"
+"shared secret values while maintaining backward compatibility."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:672
+#, python-format
+msgid ""
+"Upgrading the various data structures and protocols to support longer "
+"keys\n"
+"will have to be tackled eventually, and this will be a\n"
+"major undertaking, just as it will be "
+"for \n"
+"others.\n"
+"Hopefully, through careful planning, we can minimize the disruption, and\n"
+"implement mechanisms to make it easier for future transitions."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:681
+msgid ""
+"In the future, several I2P protocols and data structures\n"
+"support securely padding messages to arbitrary sizes, so messages could "
+"be made constant\n"
+"size or garlic messages could be modified randomly so that some cloves "
+"appear to contain\n"
+"more subcloves than they actually do.  At the moment, however, garlic, "
+"tunnel, and \n"
+"end to end messages include simple random padding."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:691
+msgid "Floodfill Anonymity attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:692
+#, python-format
+msgid ""
+"In addition to the floodfill DOS attacks described\n"
+"above, floodfill routers are uniquely positioned\n"
+"to learn about network participants, due to their role\n"
+"in the netDb, and the high frequency of communication with those "
+"participants.\n"
+"This is somewhat mitigated because floodfill routers only manage a "
+"portion\n"
+"of the total keyspace, and the keyspace rotates daily, as explained \n"
+"on the network database page.\n"
+"The specific mechanisms by which routers communicate with floodfills have"
+" been\n"
+"carefully designed.\n"
+"However, these threats should be studied further.\n"
+"The specific potential threats and corresponding defenses are a topic for"
+" future research."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:708
+#, python-format
+msgid ""
+"A hostile user may attempt to harm the network by\n"
+"creating one or more floodfill routers and crafting them to offer\n"
+"bad, slow, or no responses.\n"
+"Several scenarios are discussed on the\n"
+"network database page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:718
+msgid "Central Resource Attacks"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:719
+msgid ""
+"There are a few centralized or limited resources (some inside I2P, some "
+"not)\n"
+"that could be attacked or used as a vector for attacks.\n"
+"The absence of jrandom starting November 2007, followed by the loss of "
+"the i2p.net hosting service in January 2008,\n"
+"highlighted numerous centralized resources in the development and "
+"operation of the I2P network,\n"
+"most of which are now distributed.\n"
+"Attacks on externally-reachable resources mainly affect the ability of "
+"new users to find us,\n"
+"not the operation of the network itself."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:729
+#, python-format
+msgid ""
+"The website is mirrored and uses DNS round-robin"
+" for external public access."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:732
+#, python-format
+msgid ""
+"Routers now support multiple external reseed "
+"locations,\n"
+"however more reseed hosts may be needed, and the handling of unreliable "
+"or malicious\n"
+"reseed hosts may need improvement."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:737
+msgid ""
+"Routers now support multiple update file locations.\n"
+"A malicious update host could feed a huge file, need to limit the size."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:741
+msgid "Routers now support multiple default trusted update signers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:744
+msgid ""
+"Routers now better handle multiple unreliable "
+"floodfill peers.\n"
+"Malicious floodfills needs more study."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:748
+#, python-format
+msgid ""
+"The code is now stored in a distributed source "
+"control system."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:751
+msgid ""
+"Routers rely on a single news host, but there is a hardcoded backup URL "
+"pointing to a different host.\n"
+"A malicious news host could feed a huge file, need to limit the size."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:755
+#, python-format
+msgid ""
+"Naming system services, including addressbook "
+"subscription providers, add-host services,\n"
+"and jump services, could be malicious. Substantial protections for "
+"subscriptions were implemented\n"
+"in release 0.6.1.31, with additional enhancements in subsequent releases."
+"\n"
+"However, all naming services require some measure of trust, see\n"
+"the naming page for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:762
+msgid ""
+"We remain reliant on the DNS service for i2p2.de, losing this would cause"
+" substantial\n"
+"disruption in our ability to attract new users,\n"
+"and would shrink the network (in the short-to-medium term), just as the "
+"loss of i2p.net did."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:772
+msgid ""
+"These attacks aren't directly on the network, but instead go after its "
+"development team \n"
+"by either introducing legal hurdles on anyone contributing to the "
+"development\n"
+"of the software, or by using whatever means are available to get the "
+"developers to \n"
+"subvert the software.  Traditional technical measures cannot defeat these"
+" attacks, and\n"
+"if someone threatened the life or livelihood of a developer (or even just"
+" issuing a \n"
+"court order along with a gag order, under threat of prison), we would "
+"have a big problem."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:781
+msgid "However, two techniques help defend against these attacks:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:785
+#, python-format
+msgid ""
+"All components of the network must be open source to enable inspection, "
+"verification, \n"
+"modification, and improvement.  If a developer is compromised, once it is"
+" noticed \n"
+"the community should demand explanation and cease to accept that "
+"developer's work.\n"
+"All checkins to our distributed source control "
+"system\n"
+"are cryptographically signed, and the release packagers use a trust-list "
+"system\n"
+"to restrict modifications to those previously approved."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:793
+#, python-format
+msgid ""
+"Development over the network itself, allowing developers to stay "
+"anonymous but still \n"
+"secure the development process.  All I2P development can occur through "
+"I2P - using\n"
+"a distributed source control system,\n"
+"a distributed source control system, IRC chat,\n"
+"public web servers,\n"
+"discussion forums (forum.i2p), and the software distribution sites,\n"
+"all available within I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:804
+msgid ""
+"We also maintain relationships with various organizations that offer "
+"legal advice,\n"
+"should any defense be necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:809
+msgid "Implementation attacks (bugs)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:810
+msgid ""
+"Try as we might, most nontrivial applications include errors in the "
+"design or \n"
+"implementation, and I2P is no exception.  There may be bugs that could be"
+" exploited to \n"
+"attack the anonymity or security of the communication running over I2P in"
+" unexpected \n"
+"ways.  To help withstand attacks against the design or protocols in use, "
+"we publish \n"
+"all designs and documentation and solicit review and criticism with \n"
+"the hope that many eyes will improve the system.\n"
+"We do not believe in\n"
+"security through "
+"obscurity."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:821
+msgid ""
+"In addition, the code is being \n"
+"treated the same way, with little aversion towards reworking or throwing "
+"out \n"
+"something that isn't meeting the needs of the software system (including "
+"ease of \n"
+"modification).  Documentation for the design and implementation of the "
+"network and \n"
+"the software components are an essential part of security, as without "
+"them it is \n"
+"unlikely that developers would be willing to spend the time to learn the "
+"software \n"
+"enough to identify shortcomings and bugs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:831
+msgid ""
+"Our software is likely, in particular, to contain bugs related to denial "
+"of service\n"
+"through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues  "
+"in the router console,\n"
+"and other vulnerabilities to non-standard inputs via the various "
+"protocols."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:837
+#, python-format
+msgid ""
+"I2P is still a small network with a small development community and "
+"almost no\n"
+"interest from academic or research groups.\n"
+"Therefore we lack the analysis that\n"
+"other anonymity networks\n"
+"may have received. We continue to recruit people to\n"
+"get involved and help."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:850
+msgid "Blocklists"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:851
+msgid ""
+"To some extent, I2P could be enhanced to avoid peers operating at IP "
+"addresses\n"
+"listed in a blocklist. Several blocklists are commonly available in "
+"standard formats,\n"
+"listing anti-P2P organizations, potential state-level adversaries, and "
+"others."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:857
+msgid ""
+"To the extent that active peers actually do show up in the actual "
+"blocklist,\n"
+"blocking by only a subset of peers would tend to segment the network,\n"
+"exacerbate reachability problems, and decrease overall reliability.\n"
+"Therefore we would want to agree on a particular blocklist and\n"
+"enable it by default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:865
+msgid ""
+"Blocklists are only a part (perhaps a small part) of an array of defenses"
+"\n"
+"against maliciousness.\n"
+"In large part the profiling system does a good job of measuring\n"
+"router behavior so that we don't need to trust anything in netDb.\n"
+"However there is more that can be done. For each of the areas in the\n"
+"list above there are improvements we can make in detecting badness."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:874
+msgid ""
+"If a blocklist is hosted at a central location with automatic updates\n"
+"the network is vulnerable to a\n"
+"central resource attack.\n"
+"Automatic subscription to a list gives the list provider the power to "
+"shut\n"
+"the i2p network down. Completely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/threat-model.html:882
+msgid ""
+"Currently, a default blocklist is distributed with our software,\n"
+"listing only the IPs of past DOS sources.\n"
+"There is no automatic update mechanism.\n"
+"Should a particular IP range implement serious attacks on the I2P "
+"network,\n"
+"we would have to ask people to update their blocklist manually through\n"
+"out-of-band mechanisms such as forums, blogs, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:2
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:6
+msgid "Tunnel Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:3
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:3
+msgid "July 2011"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:7
+msgid ""
+"This page contains an overview of I2P tunnel terminology and operation, "
+"with\n"
+"links to more technical pages, details, and specifications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:12
+#, python-format
+msgid ""
+"As briefly explained in the introduction, I2P "
+"builds virtual \"tunnels\" -\n"
+"temporary and unidirectional paths through a sequence of routers.  These"
+" \n"
+"tunnels are classified as either inbound tunnels (where everything \n"
+"given to it goes towards the creator of the tunnel) or outbound tunnels\n"
+"(where the tunnel creator shoves messages away from them).  When Alice\n"
+"wants to send a message to Bob, she will (typically) send it out one of\n"
+"her existing outbound tunnels with instructions for that tunnel's "
+"endpoint\n"
+"to forward it to the gateway router for one of Bob's current inbound \n"
+"tunnels, which in turn passes it to Bob."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:25
+msgid "Alice connecting through her outbound tunnel to Bob via his inbound tunnel"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:27
+msgid "Outbound Gateway"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:28
+msgid "Outbound Participant"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:29
+#: i2p2www/pages/site/docs/tunnels/implementation.html:131
+msgid "Outbound Endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:31
+msgid "Inbound Participant"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:32
+msgid "Inbound Endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:36
+msgid "Tunnel vocabulary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:38
+#, python-format
+msgid ""
+"Tunnel gateway - the first router in a tunnel.  For inbound "
+"tunnels,\n"
+"this is the one mentioned in the LeaseSet published in the\n"
+"network database.  For outbound tunnels, the\n"
+"gateway is the originating router.  (e.g. both A and D above)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:44
+msgid ""
+"Tunnel endpoint - the last router in a tunnel.  (e.g. both C and F"
+" above)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:45
+msgid ""
+"Tunnel participant - all routers in a tunnel except for the "
+"gateway or\n"
+"endpoint (e.g. both B and E above)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:49
+msgid ""
+"n-Hop tunnel - a tunnel with a specific number of inter-router "
+"jumps, e.g.:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:51
+msgid "0-hop tunnel - a tunnel where the gateway is also the endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:52
+msgid ""
+"1-hop tunnel - a tunnel where the gateway talks directly to the "
+"endpoint"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:53
+msgid ""
+"2-(or more)-hop tunnel - a tunnel where there is at least one "
+"intermediate\n"
+"tunnel participant. (the above diagram includes two 2-hop tunnels - one\n"
+"outbound from Alice, one inbound to Bob)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:60
+#, python-format
+msgid ""
+"Tunnel ID - A 4 "
+"byte integer\n"
+"different for each hop in a tunnel, and unique among all tunnels on a "
+"router.\n"
+"Chosen randomly by the tunnel creator."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:67
+msgid "Tunnel Build Information"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:68
+#, python-format
+msgid ""
+"Routers performing the three roles (gateway, participant, endpoint) are "
+"given\n"
+"different pieces of data in the initial\n"
+"Tunnel Build Message\n"
+"to accomplish their tasks:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:75
+msgid "The tunnel gateway gets:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:77
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:97
+#, python-format
+msgid ""
+"tunnel encryption key - an AES private key for "
+"encrypting\n"
+"messages and instructions to the next hop"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:81
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:101
+#, python-format
+msgid ""
+"tunnel IV key - an AES private key for "
+"double-encrypting\n"
+"the IV to the next hop"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:85
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:105
+#, python-format
+msgid ""
+"reply key - an AES public key for "
+"encrypting\n"
+"the reply to the tunnel build request"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:89
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:109
+msgid ""
+"reply IV - the IV for encrypting the reply to the tunnel build "
+"request"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:90
+msgid "tunnel id - 4 byte integer (inbound gateways only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:91
+msgid ""
+"next hop - what router is the next one in the path (unless this is"
+" a 0-hop tunnel, and the gateway is also the endpoint)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:92
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:112
+msgid "next tunnel id - The tunnel ID on the next hop"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:95
+msgid "All intermediate tunnel participants get:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:110
+msgid "tunnel id - 4 byte integer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:111
+msgid "next hop - what router is the next one in the path"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:115
+msgid "The tunnel endpoint gets:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:117
+#, python-format
+msgid ""
+"tunnel encryption key - an AES private key for "
+"encrypting\n"
+"messages and instructions to the the endpoint (itself)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:121
+#, python-format
+msgid ""
+"tunnel IV key - an AES private key for "
+"double-encrypting\n"
+"the IV to the endpoint (itself)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:125
+#, python-format
+msgid ""
+"reply key - an AES public key for "
+"encrypting\n"
+"the reply to the tunnel build request (outbound endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:129
+msgid ""
+"reply IV - the IV for encrypting the reply to the tunnel build "
+"request (outbound endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:130
+msgid "tunnel id - 4 byte integer (outbound endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:131
+msgid ""
+"reply router - the inbound gateway of the tunnel to send the reply"
+" through (outbound endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:132
+msgid ""
+"reply tunnel id - The tunnel ID of the reply router (outbound "
+"endpoints only)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:137
+#, python-format
+msgid ""
+"Details are in the\n"
+"tunnel creation specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:142
+msgid "Tunnel pooling"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:143
+#, python-format
+msgid ""
+"Several tunnels for a particular purpose may be grouped into a \"tunnel "
+"pool\",\n"
+"as described in the\n"
+"tunnel specification.\n"
+"This provides redundancy and additional bandwidth.\n"
+"The pools used by the router itself are called \"exploratory tunnels\".\n"
+"The pools used by applications are called \"client tunnels\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:154
+msgid "Tunnel length"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:155
+#, python-format
+msgid ""
+"As mentioned above, each client requests that their router provide "
+"tunnels to\n"
+"include at least a certain number of hops.\n"
+"The decision as to how many routers\n"
+"to have in one's outbound and inbound tunnels has an important effect "
+"upon the\n"
+"latency, throughput, reliability, and anonymity provided by I2P - the "
+"more peers\n"
+"that messages have to go through, the longer it takes to get there and "
+"the more\n"
+"likely that one of those routers will fail prematurely.  The less routers"
+" in a\n"
+"tunnel, the easier it is for an adversary to mount traffic analysis "
+"attacks and\n"
+"pierce someone's anonymity.\n"
+"Tunnel lengths are specified by clients via\n"
+"I2CP options.\n"
+"The maximum number of hops in a tunnel is 7."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:171
+msgid "0-hop tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:172
+msgid ""
+"With no remote routers in a tunnel, the user has very basic plausible\n"
+"deniability (since no one knows for sure that the peer that sent them the"
+"\n"
+"message wasn't simply just forwarding it on as part of the tunnel). "
+"However, it\n"
+"would be fairly easy to mount a statistical analysis attack and notice "
+"that\n"
+"messages targeting a specific destination are always sent through a "
+"single\n"
+"gateway.  Statistical analysis against outbound 0-hop tunnels are more "
+"complex,\n"
+"but could show similar information (though would be slightly harder to "
+"mount)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:182
+msgid "1-hop tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:183
+#, python-format
+msgid ""
+"With only one remote router in a tunnel, the user has both plausible\n"
+"deniability and basic anonymity, as long as they are not up against an "
+"internal\n"
+"adversary (as described on threat model)."
+" However,\n"
+"if the adversary ran a sufficient number of routers such that the single "
+"remote\n"
+"router in the tunnel is often one of those compromised ones, they would "
+"be able\n"
+"to mount the above statistical traffic analysis attack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:192
+msgid "2-hop tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:193
+msgid ""
+"With two or more remote routers in a tunnel, the costs of mounting the "
+"traffic\n"
+"analysis attack increases, since many remote routers would have to be "
+"compromised\n"
+"to mount it."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:199
+msgid "3-hop (or more) tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:200
+#, python-format
+msgid ""
+"To reduce the susceptibility to some attacks,\n"
+"3 or more hops are recommended for the highest level of protection.\n"
+"Recent studies\n"
+"also conclude that more than 3 hops does not provide additional "
+"protection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:208
+msgid "Tunnel default lengths"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:209
+#, python-format
+msgid ""
+"The router uses 2-hop tunnels by default for its exploratory tunnels.\n"
+"Client tunnel defaults are set by the application, using\n"
+"I2CP options.\n"
+"Most applications use 2 or 3 hops as their default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:218
+msgid "Tunnel testing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:219
+#, python-format
+msgid ""
+"All tunnels are periodically tested by their creator by sending a\n"
+"DeliveryStatusMessage out an outbound tunnel and bound for another "
+"inbound tunnel\n"
+"(testing both tunnels at once).  If either fails a number of consecutive "
+"tests, it is marked as no longer\n"
+"functional. If it was used for a client's inbound tunnel, a new leaseSet\n"
+"is created.\n"
+"Tunnel test failures are also reflected in the\n"
+"capacity rating in the peer "
+"profile."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:231
+#, python-format
+msgid ""
+"Tunnel creation is handled by garlic "
+"routing\n"
+"a Tunnel Build Message to a router, requesting that they participate in "
+"the\n"
+"tunnel (providing them with all of the appropriate information, as above,"
+" along\n"
+"with a certificate, which right now is a 'null' cert, but will support "
+"hashcash\n"
+"or other non-free certificates when necessary).\n"
+"That router forwards the message to the next hop in the tunnel.\n"
+"Details are in the\n"
+"tunnel creation specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:245
+#, python-format
+msgid ""
+"Multi-layer encryption is handled by garlic"
+" encryption\n"
+"of tunnel messages.\n"
+"Details are in the\n"
+"tunnel specification.\n"
+"The IV of each hop is encrypted with a separate key as explained there."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:257
+msgid ""
+"Other tunnel test techniques could be used, such as\n"
+"garlic wrapping a number of tests into cloves, testing individual tunnel\n"
+"participants separately, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:263
+msgid "Move to 3-hop exploratory tunnels defaults."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:267
+msgid ""
+"In a distant future release,\n"
+"options specifying the pooling, mixing, and chaff generation settings may"
+" be implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:272
+msgid ""
+"In a distant future release,\n"
+"limits on the quantity and size of messages allowed during the\n"
+"tunnel's lifetime may be implemented (e.g. no more than 300 messages or\n"
+"1MB per minute)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:284
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:15
+msgid "Tunnel specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:286
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:17
+msgid "Tunnel creation specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:290
+msgid "Tunnel message specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:294
+msgid "ElGamal/AES+SessionTag"
+msgstr ""
+
+#: i2p2www/pages/site/docs/how/tunnel-routing.html:296
+msgid "I2CP options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:6
+msgid ""
+"The I2P Client Protocol (I2CP) exposes a strong separation of concerns "
+"between\n"
+"the router and any client that wishes to communicate over the network.  "
+"It enables\n"
+"secure and asynchronous messaging by sending and receiving messages over "
+"a \n"
+"single TCP socket, yet never exposing any private keys and authenticating"
+" itself\n"
+"to the router only through signatures.  With I2CP, a client application "
+"tells the\n"
+"router who they are (their \"destination\"), what anonymity, reliability,"
+" and \n"
+"latency tradeoffs to make, and where to send messages.  In turn the "
+"router uses\n"
+"I2CP to tell the client when any messages have arrived, and to request "
+"authorization\n"
+"for some tunnels to be used."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:18
+#, python-format
+msgid ""
+"The protocol itself has only been implemented in Java, to provide the\n"
+"Client SDK.\n"
+"This SDK is exposed in the i2p.jar package, which implements the client-"
+"side of I2CP.\n"
+"Clients should never need to access the router.jar package, which "
+"contains the\n"
+"router itself and the router-side of I2CP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:26
+#, python-format
+msgid ""
+"While implementing the client side of I2CP in a non-Java language is "
+"certainly feasible,\n"
+"a non-Java client would also have to implement the\n"
+"streaming library for TCP-style "
+"connections.\n"
+"Together, implementing I2CP and the streaming library would be a sizable "
+"task."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:33
+#, python-format
+msgid ""
+"Applications can take advantage of the base I2CP plus the \n"
+"streaming and datagram libraries\n"
+"by using the Simple Anonymous Messaging or BOB protocols,\n"
+"which do not require clients to deal with any sort of cryptography.\n"
+"Also, clients may access the network by one of several proxies -\n"
+"HTTP, CONNECT, and SOCKS 4/4a/5.\n"
+"Alternatively, Java clients may access those libraries in "
+"ministreaming.jar and streaming.jar.\n"
+"So there are several options for both Java and non-Java applications."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:45
+#, python-format
+msgid ""
+"Client-side end-to-end encryption (encrypting the data over the I2CP "
+"connection)\n"
+"was disabled in I2P release 0.6,\n"
+"leaving in place the ElGamal/AES end-to-end "
+"encryption\n"
+"which is implemented in the router.\n"
+"The only cryptography that client libraries must still implement is\n"
+"DSA public/private key signing\n"
+"for LeaseSets and\n"
+"Session Configurations, and"
+" management of those keys."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:58
+msgid ""
+"In a standard I2P installation, port 7654 is used by external java "
+"clients to communicate\n"
+"with the local router via I2CP.\n"
+"By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, "
+"set the\n"
+"router advanced configuration option "
+"i2cp.tcp.bindAllInterfaces=true and restart.\n"
+"Clients in the same JVM as the router pass messages directly to the "
+"router\n"
+"through an internal JVM interface."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:67
+msgid "I2CP Protocol Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:68
+#, python-format
+msgid "Now on the I2CP Specification page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:73
+msgid "I2CP Initialization"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:74
+#, python-format
+msgid ""
+"When a client connects to the router, it first sends a single protocol "
+"version byte (0x2A).\n"
+"Then it sends a GetDate Message and "
+"waits for the SetDate Message "
+"response.\n"
+"Next, it sends a CreateSession "
+"Message containing the session configuration.\n"
+"It next awaits a RequestLeaseSet"
+" Message from the router, indicating that inbound tunnels\n"
+"have been built, and responds with a CreateLeaseSetMessage containing the"
+" signed LeaseSet.\n"
+"The client may now initiate or receive connections from other I2P "
+"destinations."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:83
+msgid "I2CP Options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:84
+#, python-format
+msgid ""
+"The following options are traditionally passed to the router via\n"
+"a SessionConfig contained "
+"in a CreateSession Message or "
+"a ReconfigureSession "
+"Message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:90
+msgid "Router-side Options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:95
+#: i2p2www/pages/site/docs/protocol/i2cp.html:438
+msgid "As Of Release"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:96
+#: i2p2www/pages/site/docs/protocol/i2cp.html:439
+msgid "Recommended Arguments"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:97
+#: i2p2www/pages/site/docs/protocol/i2cp.html:440
+msgid "Allowable Range"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:105
+#: i2p2www/pages/site/docs/protocol/i2cp.html:118
+#: i2p2www/pages/site/docs/protocol/i2cp.html:127
+#: i2p2www/pages/site/docs/protocol/i2cp.html:136
+#: i2p2www/pages/site/docs/protocol/i2cp.html:145
+#: i2p2www/pages/site/docs/protocol/i2cp.html:160
+#: i2p2www/pages/site/docs/protocol/i2cp.html:175
+#: i2p2www/pages/site/docs/protocol/i2cp.html:184
+#: i2p2www/pages/site/docs/protocol/i2cp.html:232
+#: i2p2www/pages/site/docs/protocol/i2cp.html:244
+#: i2p2www/pages/site/docs/protocol/i2cp.html:256
+#, python-format
+msgid "number from %(from)s to %(to)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:106
+#: i2p2www/pages/site/docs/protocol/i2cp.html:128
+#: i2p2www/pages/site/docs/protocol/i2cp.html:137
+#: i2p2www/pages/site/docs/protocol/i2cp.html:146
+#: i2p2www/pages/site/docs/protocol/i2cp.html:161
+#: i2p2www/pages/site/docs/protocol/i2cp.html:233
+#: i2p2www/pages/site/docs/protocol/i2cp.html:245
+#: i2p2www/pages/site/docs/protocol/i2cp.html:257
+#: i2p2www/pages/site/docs/protocol/i2cp.html:530
+#, python-format
+msgid "%(from)s to %(to)s"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:108
+msgid ""
+"Number of tunnels in.\n"
+"Limit was increased from 6 to 16 in release 0.9; however, numbers higher "
+"than 6 are not\n"
+"currently recommended, as this is untested and is incompatible with older"
+" releases."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:119
+#: i2p2www/pages/site/docs/protocol/i2cp.html:176
+#: i2p2www/pages/site/docs/protocol/i2cp.html:185
+msgid "No limit"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:121
+msgid "Number of tunnels out"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:130
+msgid "Length of tunnels in"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:139
+msgid "Length of tunnels out"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:148
+msgid ""
+"Random amount to add or subtract to the length of tunnels in.\n"
+"A positive number x means add a random amount from 0 to x inclusive.\n"
+"A negative number -x means add a random amount from -x to x inclusive.\n"
+"The router will limit the total length of the tunnel to 0 to 7 inclusive."
+"\n"
+"The default variance was 1 prior to release 0.7.6."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:163
+msgid ""
+"Random amount to add or subtract to the length of tunnels out.\n"
+"A positive number x means add a random amount from 0 to x inclusive.\n"
+"A negative number -x means add a random amount from -x to x inclusive.\n"
+"The router will limit the total length of the tunnel to 0 to 7 inclusive."
+"\n"
+"The default variance was 1 prior to release 0.7.6."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:178
+msgid "Number of redundant fail-over for tunnels in"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:187
+msgid "Number of redundant fail-over for tunnels out"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:196
+msgid ""
+"Name of tunnel - generally used in routerconsole, which will\n"
+"use the first few characters of the Base64 hash of the destination by "
+"default."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:208
+msgid "Name of tunnel - generally ignored unless inbound.nickname is unset."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:217
+msgid "If incoming zero hop tunnel is allowed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:226
+msgid "If outgoing zero hop tunnel is allowed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:235
+#: i2p2www/pages/site/docs/protocol/i2cp.html:247
+msgid ""
+"Number of IP bytes to match to determine if\n"
+"two routers should not be in the same tunnel. 0 to disable."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:259
+msgid ""
+"Priority adjustment for outbound messages.\n"
+"Higher is higher priority."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:271
+msgid "Should generally be set to true for clients and false for servers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:280
+msgid ""
+"Guaranteed is disabled;\n"
+"None implemented in 0.8.1; the streaming lib default is None as of 0.8.1,"
+" the client side default is None as of 0.9.4"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:292
+#: i2p2www/pages/site/docs/protocol/i2cp.html:571
+msgid ""
+"If true, the router just sends the MessagePayload instead\n"
+"of sending a MessageStatus and awaiting a ReceiveMessageBegin."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:304
+msgid ""
+"Comma-separated list of Base 64 Hashes of peers to build tunnels through;"
+" for debugging only"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:313
+#: i2p2www/pages/site/docs/protocol/i2cp.html:325
+msgid ""
+"For authorization, if required by the router.\n"
+"If the client is running in the same JVM as a router, this option is not "
+"required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:337
+msgid ""
+"Number of ElGamal/AES Session Tags to send at a time.\n"
+"For clients with relatively low bandwidth per-client-pair (IRC, some UDP "
+"apps), this may be set lower."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:349
+msgid ""
+"Minimum number of ElGamal/AES Session Tags before we send more.\n"
+"Recommended: approximately tagsToSend * 2/3"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:361
+msgid ""
+"Set to false to disable ever bundling a reply LeaseSet.\n"
+"For clients that do not publish their LeaseSet, this option must be true\n"
+"for any reply to be possible. \"true\" is also recommended for multihomed"
+" servers\n"
+"with long connection times."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:368
+msgid ""
+"Setting to \"false\" may save significant outbound bandwidth, especially "
+"if\n"
+"the client is configured with a large number of inbound tunnels (Leases)."
+"\n"
+"If replies are still required, this may shift the bandwidth burden to\n"
+"the far-end client and the floodfill.\n"
+"There are several cases where \"false\" may be appropriate:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:376
+msgid "Unidirectional communication, no reply required"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:377
+msgid "LeaseSet is published and higher reply latency is acceptable"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:378
+msgid ""
+"LeaseSet is published, client is a \"server\", all connections are "
+"inbound\n"
+"so the connecting far-end destination obviously has the leaseset already."
+"\n"
+"Connections are either short, or it is acceptable for latency on a long-"
+"lived\n"
+"connection to temporarily increase while the other end re-fetches the "
+"LeaseSet\n"
+"after expiration.\n"
+"HTTP servers may fit these requirements."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:396
+msgid ""
+"Any other options prefixed with \"inbound.\" are stored\n"
+"in the \"unknown options\" properties of the inbound tunnel pool's "
+"settings."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:408
+msgid ""
+"Any other options prefixed with \"outbound.\" are stored\n"
+"in the \"unknown options\" properties of the outbound tunnel pool's "
+"settings."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:415
+msgid ""
+"Note: Large quantity, length, or variance settings may cause significant "
+"performance or reliability problems."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:419
+msgid ""
+"Note: As of release 0.7.7, option names and values must use UTF-8 "
+"encoding.\n"
+"This is primarily useful for nicknames.\n"
+"Prior to that release, options with multi-byte characters were corrupted."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:425
+msgid ""
+"The following options are interpreted on the client side,\n"
+"and will be interpreted if passed to the I2PSession via the "
+"I2PClient.createSession() call.\n"
+"The streaming lib should also pass these options through to I2CP.\n"
+"Other implementations may have different defaults."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:433
+msgid "Client-side Options"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:451
+msgid ""
+"Router hostname.\n"
+"If the client is running in the same JVM as a router, this option is "
+"ignored, and the client connects to that router internally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:463
+msgid ""
+"Router I2CP port.\n"
+"If the client is running in the same JVM as a router, this option is "
+"ignored, and the client connects to that router internally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:475
+msgid ""
+"Connect to the router using SSL.\n"
+"If the client is running in the same JVM as a router, this option is "
+"ignored, and the client connects to that router internally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:487
+msgid "Gzip outbound data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:496
+msgid "Reduce tunnel quantity when idle"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:505
+msgid "Close I2P session when idle"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:512
+#: i2p2www/pages/site/docs/protocol/i2cp.html:521
+#, python-format
+msgid "%(num)s minimum"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:514
+msgid "(ms) Idle time required (default 20 minutes, minimum 5 minutes)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:523
+msgid "(ms) Idle time required (default 30 minutes)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:532
+msgid "Tunnel quantity when reduced (applies to both inbound and outbound)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:541
+msgid "Encrypt the lease"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:550
+msgid "Base64 SessionKey (44 characters)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:559
+msgid ""
+"Guaranteed is disabled;\n"
+"None implemented in 0.8.1; None is the default as of 0.9.4"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:578
+msgid ""
+"Note: All arguments, including numbers, are strings. True/false values "
+"are case-insensitive strings.\n"
+"Anything other than case-insensitive \"true\" is interpreted as false.\n"
+"All option names are case-sensitive."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:584
+msgid "I2CP Payload Data Format and Multiplexing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:585
+#, python-format
+msgid ""
+"The end-to-end messages handled by I2CP (i.e. the data sent by the client"
+" in a\n"
+"SendMessageMessage\n"
+"and received by the client in a\n"
+"MessagePayloadMessage)\n"
+"are gzipped with a standard 10-byte gzip\n"
+"header beginning with 0x1F 0x8B 0x08 as\n"
+"specified by RFC "
+"1952.\n"
+"As of release 0.7.1, I2P uses ignored portions of the gzip header to "
+"include\n"
+"protocol, from-port, and to-port information, thus supporting streaming "
+"and\n"
+"datagrams on the same destination, and allowing query/response using "
+"datagrams\n"
+"to work reliably in the presence of multiple channels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:599
+msgid ""
+"The gzip function cannot be completely turned off, however setting "
+"i2cp.gzip=false\n"
+"turns the gzip effort setting to 0, which may save a little CPU."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:605
+#: i2p2www/pages/site/docs/protocol/i2np.html:38
+msgid "Bytes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:606
+#: i2p2www/pages/site/get-involved/index.html:38
+msgid "Content"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:611
+msgid "Gzip header"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:616
+msgid "Gzip flags"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:621
+msgid "I2P Source port (Gzip mtime)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:626
+msgid "I2P Destination port (Gzip mtime)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:631
+msgid "Gzip xflags"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:636
+msgid "I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:640
+msgid ""
+"Data integrity is verified with the standard gzip CRC-32 as\n"
+"specified by RFC 1952."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:648
+msgid "Implement I2CP and the streaming library in another programming language."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:652
+msgid "Is the initial Get Date / Set Date handshake required?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:656
+msgid ""
+"The current authorization mechanism could be modified to use hashed "
+"passwords."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:660
+msgid ""
+"Private Keys are included in the Create Lease Set message,\n"
+"are they really required? Revocation is unimplemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2cp.html:665
+#, python-format
+msgid ""
+"Some improvements may be able to use messages previously defined but not "
+"implemented.\n"
+"For reference, here is the\n"
+"I2CP Protocol Specification Version 0.9\n"
+"(PDF) dated August 28, 2003.\n"
+"That document also references the\n"
+"Common Data Structures Specification Version 0.9."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:6
+msgid "I2P Network Protocol"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:7
+msgid ""
+"The I2P Network Protocol (I2NP),\n"
+"which is sandwiched between I2CP and the various I2P transport protocols,"
+" manages the\n"
+"routing and mixing of messages between routers, as well as the selection "
+"of what\n"
+"transports to use when communicating with a peer for which there are "
+"multiple\n"
+"common transports supported."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:15
+msgid "I2NP Definition"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:16
+msgid ""
+"I2NP (I2P Network Protocol) messages can be used for one-hop, router-to-"
+"router, point-to-point messages.\n"
+"By encrypting and wrapping messages in other messages, they can be sent "
+"in a secure way\n"
+"through multiple hops to the ultimate destination.\n"
+"Priority is only used locally at the origin, i.e. when queuing for "
+"outbound delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:23
+msgid ""
+"Both the NTCP and UDP transports implement priority transmission,\n"
+"but in quite different manners.\n"
+"UDP has complex code with queues for each priority, however it treats\n"
+"messages with priorities 400-499, for example, the same.\n"
+"(The priority queues are 100, 200, 300, 400, 500, and 1000)\n"
+"These are global queues for all peers.\n"
+"NTCP has a trivial linear search for the highest priority within\n"
+"each buffer for a particular peer.\n"
+"This is much less effective."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:35
+msgid "Message Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:38
+#: i2p2www/pages/site/docs/spec/streaming.html:35
+msgid "Field"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:39
+msgid "Unique ID"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:40
+msgid "Expiration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:41
+#: i2p2www/pages/site/docs/protocol/i2np.html:98
+msgid "Payload Length"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:42
+msgid "Checksum"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:43
+msgid "Payload"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:46
+#, python-format
+msgid ""
+"While the maximum payload size is nominally 64KB, the size is further "
+"constrained by the\n"
+"method of fragmenting I2NP messages into multiple 1KB tunnel messages as "
+"described on\n"
+"the tunnel implementation page.\n"
+"The maximum number of fragments is 64, and the message may not be "
+"perfectly aligned,\n"
+"So the message must nominally fit in 63 fragments."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:54
+msgid ""
+"The maximum size of an initial fragment is 956 bytes (assuming TUNNEL "
+"delivery mode);\n"
+"the maximum size of a follow-on fragment is 996 bytes.\n"
+"Therefore the maximum size is approximately 956 + (62 * 996) = 62708 "
+"bytes, or 61.2 KB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:60
+msgid ""
+"In addition, the transports may have additional restrictions.\n"
+"NTCP currently limits to 16KB - 6 = 16378 bytes but this will be "
+"increased in a future release.\n"
+"The SSU limit is approximately 32 KB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:66
+msgid ""
+"Note that these are not the limits for datagrams that the client sees, as"
+" the\n"
+"router may bundle a reply leaseset and/or session tags together with the "
+"client message\n"
+"in a garlic message. The leaseset and tags together may add about 5.5KB.\n"
+"Therefore the current datagram limit is about 10KB. This limit will be\n"
+"increased in a future release."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:74
+msgid "Message Types"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:75
+msgid ""
+"Higher-numbered priority is higher priority.\n"
+"The majority of traffic is TunnelDataMessages (priority 400),\n"
+"so anything above 400 is essentially high priority, and\n"
+"anything below is low priority.\n"
+"Note also that many of the messages are generally routed\n"
+"through exploratory tunnels, not client tunnels, and\n"
+"therefore may not be in the same queue unless the\n"
+"first hops happen to be on the same peer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:86
+msgid ""
+"Also, not all message types are sent unencrypted.\n"
+"For example, when testing a tunnel, the router wraps a\n"
+"DeliveryStatusMessage, which is wrapped in a GarlicMessage,\n"
+"which is wrapped in a DataMessage."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:97
+msgid "Type"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:99
+#, fuzzy
+msgid "Priority"
+msgstr "Prioritetsköer"
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:100
+msgid "Comments"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:108
+msgid ""
+"400 normally; 100 if from HarvesterJob and sent directly;\n"
+"400 for a router lookup"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:119
+msgid ""
+"Size is 65 + 32*(number of hashes) where typically, the hashes for\n"
+"three floodfill routers are returned."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:128
+msgid "Varies"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:130
+msgid ""
+"Usually 100 (why?)\n"
+"Size is 898 bytes for a typical 2-lease leaseSet.\n"
+"RouterInfo structures are compressed, and size varies; however\n"
+"there is a continuing effort to reduce the amount of data published in a "
+"RouterInfo\n"
+"as we approach release 1.0."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:152
+msgid ""
+"Used for message replies, and for testing tunnels - generally wrapped in "
+"a GarlicMessage"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:160
+msgid ""
+"Generally wrapped in a DataMessage -\n"
+"but when unwrapped, given a priority of 100 by the forwarding router"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:171
+msgid "Usually 500 (why?)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:187
+msgid ""
+"The most common message. Priority for tunnel participants, outbound "
+"endpoints, and inbound gateways was\n"
+"reduced to 200 as of release 0.6.1.33.\n"
+"Outbound gateway messages (i.e. those originated locally) remains at 400."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:207
+msgid "Shorter TunnelBuildMessage as of 0.7.12"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:215
+msgid "Shorter TunnelBuildReplyMessage as of 0.7.12"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:218
+#, python-format
+msgid "Others listed in 2003 Spec"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:224
+msgid "Obsolete, Unused"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:228
+msgid "Full Protocol Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:229
+#, python-format
+msgid ""
+"On the I2NP Specification page.\n"
+"See also the\n"
+"Common Data Structure Specification "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/i2np.html:236
+msgid ""
+"It isn't clear whether the current priority scheme is generally "
+"effective,\n"
+"and whether the priorities for various messages should be adjusted "
+"further.\n"
+"This is a topic for further research, analysis and testing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:2
+msgid "Protocol Stack"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:7
+#, python-format
+msgid ""
+"Here is the protocol stack for I2P.\n"
+"See also the Index to Technical Documentation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:12
+msgid ""
+"Each of the layers in the stack provides extra capabilities.\n"
+"The capabilities are listed below, starting at the bottom of the protocol"
+" stack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:18
+msgid "Internet Layer:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:20
+msgid ""
+"IP: Internet Protocol, allow addressing hosts on the regular internet and"
+" routing packets across the internet using best-effort delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:23
+msgid "Transport Layer:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:25
+msgid ""
+"TCP: Transmission Control Protocol, allow reliable, in-order delivery of "
+"packets across the internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:27
+msgid ""
+"UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of "
+"packets across the internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:30
+msgid ""
+"I2P Transport Layer: provide encrypted connections between 2 I2P "
+"routers. These are not anonymous yet, this is strictly a hop-to-hop "
+"connection.\n"
+"Two protocols are implemented to provide these capabilities. NTCP builds "
+"on top of TCP, while SSU uses UDP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:35
+msgid "NIO-based TCP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:37
+msgid "Secure Semi-reliable UDP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:40
+msgid "I2P Tunnel Layer: provide full encrypted tunnel connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:42
+#, python-format
+msgid ""
+"Tunnel messages: tunnel messages are "
+"large messages containing encrypted I2NP (see below) messages and "
+"encrypted instructions for their delivery.\n"
+"The encryption is layered. The first hop will decrypt the tunnel message "
+"and read a part. Another part can still be encrypted (with another key),"
+"\n"
+"so it will be forwarded."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:48
+#, python-format
+msgid ""
+"I2NP messages: I2P Network Protocol messages are"
+" used to pass messages through multiple routers. These I2NP messages are "
+"combined in tunnel messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:53
+msgid ""
+"I2P Garlic Layer: provide encrypted and anonymous end-to-end I2P "
+"message delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:55
+#, python-format
+msgid ""
+"I2NP messages: I2P Network Protocol messages are"
+" wrapped in each other and used to ensure encryption between two tunnels "
+"and are passed along from source to destination, keeping both anonymous."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:61
+msgid ""
+"The following layers are strictly speaking no longer part of the I2P "
+"Protocol stack, they are not part of the core 'I2P router' functionality."
+"\n"
+"However, each of these layers adds additional functionality, to allow "
+"applications simple and convenient I2P usage."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:67
+msgid ""
+"I2P Client Layer: allow any client to use I2P functionality, "
+"without requiring the direct use of the router API."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:69
+#, python-format
+msgid ""
+"I2CP: I2P Client Protocol, allows secure and "
+"asynchronous messaging over I2P by communicating messages over the I2CP "
+"TCP socket."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:74
+msgid ""
+"I2P End-to-end Transport Layer: allow TCP- or UDP-like "
+"functionality on top of I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:76
+#, python-format
+msgid ""
+"Streaming Library: an implementation of "
+"TCP-like streams over I2P. This allows easier porting of existing "
+"applications to I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:80
+#, python-format
+msgid ""
+"Datagram Library: an implementation of UDP-"
+"like messages over I2P. This allows easier porting of existing "
+"applications to I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:85
+msgid ""
+"I2P Application Interface Layer: additional (optional) libraries "
+"allowing easier implementations on top of I2P."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:93
+msgid "I2P Application Proxy Layer: proxy systems."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:95
+#, python-format
+msgid "HTTP Client/Server, IRC Client, SOCKS, Streamr"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:99
+msgid ""
+"Finally, what could be considered the 'I2P application layer', is "
+"a large number of applications on top of I2P.\n"
+"We can order this based on the I2P stack layer they use."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:104
+msgid "Streaming/datagram applications: i2psnark, Syndie, i2phex..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:105
+msgid "SAM/BOB applications: IMule, i2p-bt, i2prufus, Robert..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:106
+#, python-format
+msgid ""
+"Other I2P applications: Syndie, EepGet, plugins..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:107
+msgid ""
+"Regular applications: Jetty, Apache, Monotone, CVS, browsers, "
+"e-mail..."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:111
+msgid "I2P Network stack"
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:113
+msgid "Figure 1: The layers in the I2P Network stack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/protocol/index.html:118
+msgid "Note: SAM/SAMv2 can use both the streaming lib and datagrams."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:2
+msgid "I2P Blockfile Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:3
+msgid "January 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:6
+msgid "Blockfile and Hosts Database Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:8
+#, python-format
+msgid ""
+"This document specifies\n"
+"the I2P blockfile file format\n"
+"and the tables in the hostsdb.blockfile used by the Blockfile Naming Service."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:14
+msgid ""
+"The blockfile provides fast Destination lookup in a compact format. While"
+" the blockfile page overhead is substantial,\n"
+"the destinations are stored in binary rather than in Base 64 as in the "
+"hosts.txt format.\n"
+"In addition, the blockfile provides the capability of arbitrary metadata "
+"storage\n"
+"(such as added date, source, and comments) for each entry.\n"
+"The metadata may be used in the future to provide advanced addressbook "
+"features.\n"
+"The blockfile storage requirement is a modest increase over the hosts.txt"
+" format, and the blockfile provides\n"
+"approximately 10x reduction in lookup times."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:24
+#, python-format
+msgid ""
+"A blockfile is simply on-disk storage of multiple sorted maps (key-value "
+"pairs),\n"
+"implemented as skiplists.\n"
+"The blockfile format is adopted from the\n"
+"Metanotion Blockfile Database.\n"
+"First we will define the file format, then the use of that format by the "
+"BlockfileNamingService."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:32
+msgid "Blockfile Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:33
+msgid ""
+"The original blockfile spec was modified to add magic numbers to each "
+"page.\n"
+"The file is structured in 1024-byte pages. Pages are numbered starting "
+"from 1.\n"
+"The \"superblock\" is always at page 1, i.e. starting at byte 0 in the "
+"file.\n"
+"The metaindex skiplist is always at page 2, i.e. starting at byte 1024 in"
+" the file."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:40
+msgid ""
+"All 2-byte integer values are unsigned.\n"
+"All 4-byte integer values (page numbers) are signed and negative values "
+"are illegal."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:45
+msgid ""
+"The database is designed to be opened and accessed by a single thread.\n"
+"The BlockfileNamingService provides synchronization."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:50
+msgid "Superblock format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:65
+msgid "Skip list block page format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:80
+msgid ""
+"Skip level block page format is as follows.\n"
+"All levels have a span. Not all spans have levels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:95
+msgid ""
+"Skip span block page format is as follows.\n"
+"Key/value structures are sorted by key within each span and across all "
+"spans.\n"
+"Key/value structures are sorted by key within each span.\n"
+"Spans other than the first span may not be empty."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:112
+msgid "Span Continuation block page format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:123
+msgid ""
+"Key/value structure format is as follows.\n"
+"Key and value lengths must not be split across pages, i.e. all 4 bytes "
+"must be on the same page.\n"
+"If there is not enough room the last 1-3 bytes of a page are unused and "
+"the lengths will\n"
+"be at offset 8 in the continuation page.\n"
+"Key and value data may be split across pages.\n"
+"Max key and value lengths are 65535 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:139
+msgid "Free list block page format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:151
+msgid "Free page block format:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:160
+msgid ""
+"The metaindex (located at page 2) is a mapping of US-ASCII strings to "
+"4-byte integers.\n"
+"The key is the name of the skiplist and the value is the page index of "
+"the skiplist."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:165
+msgid "Blockfile Naming Service Tables"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:166
+msgid ""
+"The tables created and used by the BlockfileNamingService are as follows."
+"\n"
+"The maximum number of entries per span is 16."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:171
+msgid "Properties Skiplist"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:172
+#, python-format
+msgid ""
+"\"%%__INFO__%%\" is the master database skiplist with String/Properties "
+"key/value entries containing only one entry:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:184
+msgid "Reverse Lookup Skiplist"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:185
+#, python-format
+msgid ""
+"\"%%__REVERSE__%%\" is the reverse lookup skiplist with "
+"Integer/Properties key/value entries\n"
+"    (as of database version 2):"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:199
+msgid "hosts.txt, userhosts.txt, and privatehosts.txt Skiplists"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:200
+msgid ""
+"For each host database, there is a skiplist containing\n"
+"the hosts for that database.\n"
+"The keys/values in these skiplists are as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:211
+msgid "The DestEntry Properties typically contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/blockfile.html:220
+msgid "Hostname keys are stored in lower-case and always end in \".i2p\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:2
+msgid "Common structure Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:6
+msgid "Data types Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:7
+#, python-format
+msgid ""
+"This document describes some data types common to all I2P protocols, like"
+"\n"
+"I2NP, I2CP,\n"
+"SSU, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:17
+msgid "Represents a non-negative integer.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:20
+#: i2p2www/pages/site/docs/spec/common-structures.html:31
+#: i2p2www/pages/site/docs/spec/common-structures.html:41
+#: i2p2www/pages/site/docs/spec/common-structures.html:54
+#: i2p2www/pages/site/docs/spec/common-structures.html:69
+#: i2p2www/pages/site/docs/spec/common-structures.html:82
+#: i2p2www/pages/site/docs/spec/common-structures.html:94
+#: i2p2www/pages/site/docs/spec/common-structures.html:106
+#: i2p2www/pages/site/docs/spec/common-structures.html:118
+#: i2p2www/pages/site/docs/spec/common-structures.html:130
+#: i2p2www/pages/site/docs/spec/common-structures.html:142
+#: i2p2www/pages/site/docs/spec/common-structures.html:154
+#: i2p2www/pages/site/docs/spec/common-structures.html:166
+#: i2p2www/pages/site/docs/spec/common-structures.html:178
+#: i2p2www/pages/site/docs/spec/common-structures.html:233
+#: i2p2www/pages/site/docs/spec/common-structures.html:302
+#: i2p2www/pages/site/docs/spec/common-structures.html:353
+#: i2p2www/pages/site/docs/spec/common-structures.html:399
+#: i2p2www/pages/site/docs/spec/common-structures.html:448
+#: i2p2www/pages/site/docs/spec/common-structures.html:572
+#: i2p2www/pages/site/docs/spec/common-structures.html:628
+#: i2p2www/pages/site/docs/spec/streaming.html:35
+#: i2p2www/pages/site/get-involved/develop/applications.html:6
+msgid "Contents"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:21
+msgid "1 to 8 bytes in network byte order representing an unsigned integer\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:27
+msgid ""
+"The number of milliseconds since midnight on January 1, 1970 in the GMT "
+"timezone.\n"
+"If the number is 0, the date is undefined or null.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:32
+msgid "8 byte Integer\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:38
+msgid "Represents a UTF-8 encoded string.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:42
+msgid ""
+"1 or more bytes where the first byte is the number of bytes (not "
+"characters!)\n"
+"in the string and the remaining 0-255 bytes are the non-null terminated "
+"UTF-8 encoded character array.\n"
+"Length limit is 255 bytes (not characters). Length may be 0.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:50
+msgid ""
+"A boolean value, supporting null/unknown representation\n"
+"0=false, 1=true, 2=unknown/null\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:55
+msgid "1 byte Integer\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:59
+msgid "Deprecated - unused\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:65
+#, python-format
+msgid ""
+"This structure is used in ElGamal encryption, representing only the "
+"exponent, not the primes, which are constant and defined in\n"
+"the cryptography specification.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:70
+#: i2p2www/pages/site/docs/spec/common-structures.html:83
+msgid "256 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:78
+#, python-format
+msgid ""
+"This structure is used in ElGamal decryption, representing only the "
+"exponent, not the primes which are constant and defined in\n"
+"the cryptography specification.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:91
+msgid "This structure is used for AES256 encryption and decryption.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:95
+#: i2p2www/pages/site/docs/spec/common-structures.html:143
+#: i2p2www/pages/site/docs/spec/common-structures.html:155
+msgid "32 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:103
+#, python-format
+msgid ""
+"This structure is used for verifying DSA signatures.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:107
+msgid "128 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:115
+#, python-format
+msgid ""
+"This structure is used for creating DSA signatures.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:119
+msgid "20 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:127
+#, python-format
+msgid ""
+"This structure represents the DSA "
+"signature of some data.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:131
+msgid "40 bytes\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:139
+msgid "Represents the SHA256 of some data.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:151
+msgid "A random number\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:163
+msgid "Defines an identifier that is unique to each router in a tunnel.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:167
+msgid "4 byte Integer\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:175
+msgid ""
+"A certificate is a container for various receipts or proof of works used "
+"throughout the I2P network.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:179
+msgid ""
+"1 byte Integer specifying certificate type,"
+" followed by a 2 Integer specifying the "
+"size of the certificate payload, then that many bytes.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:207
+msgid ""
+"For Router Identities, the "
+"Certificate is always NULL, no others are currently implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:211
+#, python-format
+msgid ""
+"For Garlic Cloves, the "
+"Certificate is always NULL, no others are currently implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:215
+#, python-format
+msgid ""
+"For Garlic Messages, the Certificate "
+"is always NULL, no others are currently implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:219
+msgid ""
+"For Destinations, the Certificate may"
+" be non-NULL,\n"
+"however non-NULL certs are not widely used, and any checking is left to "
+"the application-level."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:230
+msgid "A set of key/value mappings or properties\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:234
+msgid "A 2-byte size Integer followed by a series of String=String; pairs\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:263
+msgid ""
+"The encoding isn't optimal - we either need the '=' and ';' characters, "
+"or the string lengths, but not both"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:267
+msgid ""
+"Some documentation says that the strings may not include '=' or ';' but "
+"this encoding supports them"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:271
+msgid ""
+"Strings are defined to be UTF-8 but in the current implementation, I2CP "
+"uses UTF-8 but I2NP does not.\n"
+"For example,\n"
+"UTF-8 strings in a RouterInfo options mapping in a I2NP Database Store "
+"Message will be corrupted."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:277
+msgid ""
+"Mappings contained in I2NP messages (i.e. in a RouterAddress or "
+"RouterInfo)\n"
+"must be sorted by key so that the signature will be invariant."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:282
+msgid ""
+"Key and value string length limits are 255 bytes (not characters) each, "
+"plus the length byte. Length byte may be 0."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:286
+msgid ""
+"Total length limit is 65535 bytes, plus the 2 byte size field, or 65537 "
+"total."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:295
+msgid "Common structure specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:299
+msgid "Defines the way to uniquely identify a particular router\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:303
+msgid ""
+"PublicKey followed by SigningPublicKey and then a Certificate\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:342
+msgid ""
+"The certificate for a RouterIdentity is currently unused and is always "
+"NULL."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:350
+msgid ""
+"A Destination defines a particular endpoint to which messages can be "
+"directed for secure delivery.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:354
+msgid ""
+"PublicKey followed by a SigningPublicKey and then a Certificate\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:396
+msgid ""
+"Defines the authorization for a particular tunnel to receive messages "
+"targeting a Destination.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:400
+msgid ""
+"SHA256 Hash of the\n"
+"RouterIdentity of the gateway "
+"router, then the TunnelId, and finally an "
+"end Date\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:433
+msgid "Total size: 44 bytes"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:443
+msgid ""
+"Contains all of the currently authorized Leases for a particular Destination, the PublicKey to which garlic messages can be "
+"encrypted,\n"
+"and then the public key that can "
+"be used to revoke this particular version of the structure. The LeaseSet is one of the two structures "
+"stored in the network database(\n"
+"the other being RouterInfo), and is "
+"keyed under the SHA256 of the contained Destination.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:449
+msgid ""
+"Destination, followed by a PublicKey for encryption, then a SigningPublicKey which can be used to"
+" revoke this version of the LeaseSet,\n"
+"then a 1 byte Integer specifying how many "
+"Lease structures are in the set, followed "
+"by the actual Lease structures and finally "
+"a Signature  of the previous\n"
+"bytes signed by the Destination's SigningPrivateKey"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:543
+msgid ""
+"The public key of the destination was used for the old i2cp-to-i2cp "
+"encryption\n"
+"which was disabled in version 0.6, it is currently unused?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:548
+#, python-format
+msgid ""
+"The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption.\n"
+"It is currently generated anew at every router startup, it is not "
+"persistent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:553
+msgid ""
+"The signature may be verified using the signing public key of the "
+"destination."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:557
+msgid ""
+"The signing_key is currently unused. It was intended for LeaseSet "
+"revocation, which is unimplemented.\n"
+"It is currently generated anew at every router startup, it is not "
+"persistent."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:569
+msgid ""
+"This structure defines the means to contact a router through a transport "
+"protocol.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:573
+msgid ""
+"1 byte Integer defining the relative cost "
+"of using the address, where 0 is free and 255 is expensive, followed by "
+"the expiration Date after which the address "
+"should not be used, or if null, the address never expires.\n"
+"After that comes a String defining the "
+"transport protocol this router address uses. Finally there is a Mapping containing all of the transport "
+"specific options necessary to establish the connection, such as\n"
+"IP address, port number, email address, URL, etc.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:610
+msgid "Cost is typically 5 or 6 for SSU, and 10 or 11 for NTCP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:614
+msgid "Expiration is currently unused, always null (all zeroes))"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:624
+msgid ""
+"Defines all of the data that a router wants to publish for the network to"
+" see. The RouterInfo is one of two "
+"structures stored in the network database(the other being LeaseSet, and is keyed under the SHA256 of"
+"\n"
+"the contained RouterIdentity.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:629
+msgid ""
+"RouterIdentity followed by the Date, when the entry was published\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:710
+msgid ""
+"The peer_size Integer may be followed by a list of that many router "
+"hashes.\n"
+"This is currently unused. It was intended for a form of restricted "
+"routes, which is unimplemented.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:715
+msgid ""
+"The signature may be verified using the signing public key of the "
+"router_ident.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/common-structures.html:723
+#, python-format
+msgid ""
+"Defined in the Tunnel Message "
+"Specification.\n"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:2
+msgid "Configuration File Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:7
+msgid ""
+"This page provides a general specification of I2P configuration files,\n"
+"used by the router and various applications.\n"
+"It also gives an overview of the information contained in the various "
+"files,\n"
+"and links to detailed documentation where available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:15
+msgid "General Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:16
+#, python-format
+msgid ""
+"An I2P configuration file is formatted as specified in\n"
+"Java Properties\n"
+"with the following exceptions:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:22
+msgid "Encoding must be UTF-8"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:23
+msgid ""
+"Does not use or recognize any escapes, including '\\', so lines may not "
+"be continued"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:24
+msgid "'#' or ';' starts a comment, but '!' does not"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:25
+msgid ""
+"'#' starts a comment in any position but ';' must be in column 1 to start"
+" a comment"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:26
+msgid "Leading and trailing whitespace is not trimmed on keys"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:27
+msgid "Leading and trailing whitespace is trimmed on values"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:28
+msgid "'=' is the only key-termination character (not ':' or whitespace)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:29
+msgid ""
+"Lines without '=' are ignored. It does not store the key with a value of "
+"\"\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:30
+msgid ""
+"As there are no escapes, keys may not contain '#', '=', or '\n"
+"', or start with ';'"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:31
+msgid ""
+"As there are no escapes, values may not contain '#' or '\n"
+"', or start or end with '\r"
+"' or whitespace"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:34
+msgid ""
+"The file need not be sorted, but most applications do sort by key when\n"
+"writing to the file, for ease of reading and manual editing."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:39
+#, python-format
+msgid ""
+"Reads and writes are implemented in\n"
+"DataHelper loadProps() and storeProps().\n"
+"Note that the file format is significantly different than the\n"
+"serialized format for I2P protocols specified in\n"
+"Mapping."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:48
+msgid "Core library and router"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:50
+msgid "Clients"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:51
+msgid "Configured via /configclients in the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:55
+msgid "Logger"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:56
+msgid "Configured via /configlogging in the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:60
+msgid "Individual Plugin"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:61
+#, python-format
+msgid "See the plugin specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:66
+msgid "Enable/disable for each installed plugin."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:71
+msgid "Configured via /configadvanced in the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:78
+msgid "See documentation in SusiDNS."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:83
+msgid "Configured via the application gui."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:88
+msgid "Configured via the /i2ptunnel application in the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:92
+msgid "Router Console"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:93
+msgid "The router console uses the router.config file."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/configuration.html:98
+msgid "See post on zzz.i2p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:2
+msgid "Datagram Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:6
+msgid "See the Datagrams page for an overview of the Datagrams API."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:12
+msgid "Non-Repliable Datagrams"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:13
+msgid ""
+"Non-repliable datagrams have no 'from' address and are not authenticated."
+"\n"
+"They are also called \"raw\" datagrams.\n"
+"Strictly speaking, they are not \"datagrams\" at all, they are just raw "
+"data.\n"
+"They are not handled by the datagram API.\n"
+"However, SAM and the I2PTunnel classes support \"raw datagrams\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:21
+msgid "Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:32
+#, python-format
+msgid ""
+"The practical length is limited by lower layers of protocols - the\n"
+"tunnel message spec\n"
+"limits messages to about 61.2 KB and the\n"
+"transports\n"
+"currently limit messages to about 32 KB, although this may be raised in "
+"the future."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:41
+msgid "Repliable Datagrams"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:42
+msgid ""
+"Repliable datagrams contain a 'from' address and a signature. These add "
+"427 bytes of overhead."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/datagrams.html:91
+#, python-format
+msgid ""
+"The practical length is limited by lower layers of protocols - the\n"
+"transports\n"
+"currently limit messages to about 32 KB, so the data length here is "
+"limited to about\n"
+"31.5 KB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:2
+msgid "Streaming Library Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:6
+msgid "See the Streaming page for an overview of the Streaming Library."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:11
+msgid "Packet Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:12
+msgid "The format of a single packet in the streaming protocol is:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:35
+msgid "Length"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:83
+msgid "Flags and Option Data Fields"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/streaming.html:84
+msgid ""
+"The flags field above specifies some metadata about the packet, and in\n"
+"turn may require certain additional data to be included.  The flags are\n"
+"as follows. Any data structures specified must be added to the options "
+"area\n"
+"in the given order."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:2
+msgid "I2P Software Update Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:3
+msgid "November 2011"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:7
+msgid ""
+"I2P uses a simple, yet secure, system for automated software update.\n"
+"The router console periodically pulls a news file from a configurable I2P"
+" URL.\n"
+"There is a hardcoded backup URL pointing to the project website, in case\n"
+"the default project news host goes down."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:14
+msgid ""
+"The contents of the news file are displayed on the home page of the "
+"router console.\n"
+"In addition, the news file contains the most recent version number of the"
+" software.\n"
+"If the version is higher than the router's version number, it will\n"
+"display an indication to the user that an update is available."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:21
+msgid ""
+"The router may optionally download, or download and install, the new "
+"version\n"
+"if configured to do so."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:26
+msgid "News File Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:27
+msgid "The news.xml file may contain the following elements:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:35
+msgid ""
+"The elements may be included inside XML comments to prevent "
+"interpretation by browsers.\n"
+"The i2p.release element and version are required. All others are optional"
+" and are\n"
+"currently unused."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:41
+msgid ""
+"The news source is trusted only to indicate that a new version is "
+"available.\n"
+"It does not specify the URL of the update, the checksum, or any other "
+"information."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:47
+msgid "Update File Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:48
+msgid ""
+"The signed update file, traditionally named i2pupdate.sud,\n"
+"is simply a zip file with a prepended 56 byte header.\n"
+"The header contains:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:54
+#, python-format
+msgid ""
+"A 40-byte DSA "
+"signature"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:57
+msgid "A 16-byte I2P version in UTF-8, padded with trailing zeroes if necessary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:62
+#, python-format
+msgid ""
+"The signature covers only the zip archive - not the prepended version.\n"
+"The signature must match one of the DSA public keys "
+"configured into the router,\n"
+"which has a hardcoded default list of keys of the current project release"
+" managers."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:68
+msgid ""
+"For version comparison purposes, version fields contain [0-9]*, field "
+"separators are\n"
+"'-', '_', and '.', and all other characters are ignored."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:73
+msgid ""
+"As of version 0.8.8, the version must also be specified as a zip file "
+"comment in UTF-8,\n"
+"without the trailing zeroes.\n"
+"The updating router verifes that the version in the header (not covered "
+"by the signature)\n"
+"matches the version in the zip file comment, which is covered by the "
+"signature.\n"
+"This prevents spoofing of the version number in the header."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:81
+msgid "Download and Installation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:82
+msgid ""
+"The router first downloads the header of the update file from one in a "
+"configurable list of I2P URLs,\n"
+"using the built-in HTTP client and proxy,\n"
+"and checks that the version is newer.\n"
+"This prevents the problem of update hosts that do not have the latest "
+"file.\n"
+"The router then downloads the full update file.\n"
+"The router verifies that the update file version is newer before "
+"installation.\n"
+"It also, of course, verifies the signature, and\n"
+"verifes that the zip file comment matches the header version, as "
+"explained above."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:93
+msgid "The zip file is extracted in the base $I2P installation directory."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:97
+msgid ""
+"As of release 0.7.12, the router supports Pack200 decompression.\n"
+"Files inside the zip archive with a .jar.pack or .war.pack suffix\n"
+"are transparently decompressed to a .jar or .war file.\n"
+"Update files containing .pack files are traditionally named with a '.su2'"
+" suffix.\n"
+"Pack200 shrinks the update files by about 60%."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:105
+msgid ""
+"As of release 0.8.7, the router will delete the libjbigi.so and "
+"libjcpuid.so files\n"
+"if the zip archive contains a lib/jbigi.jar file, so that the new files "
+"will\n"
+"be extracted from jbigi.jar."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:111
+msgid ""
+"As of release 0.8.12, if the zip archive contains a file deletelist.txt, "
+"the router will\n"
+"delete the files listed there. The format is:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:116
+msgid "One file name per line"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:117
+msgid ""
+"All file names are relative to the installation directory; no absolute "
+"file names allowed, no files starting with \"..\""
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:118
+msgid "Comments start with '#'"
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:121
+msgid "The router will then delete the deletelist.txt file."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:128
+msgid ""
+"When a new update file specification is defined, it should use a larger\n"
+"DSA signature, and the signature should cover the version.\n"
+"A file format version number might be a good idea too."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:133
+msgid ""
+"The network will eventually grow too large for update over HTTP.\n"
+"The built-in BitTorrent client, i2psnark, may be used as a distributed "
+"update method.\n"
+"This development effort was started in 2009 but is on hold until it is "
+"required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/spec/updates.html:138
+msgid ""
+"The router update mechanism is part of the web router console.\n"
+"There is currently no provision for updates of an embedded router lacking"
+" the router console."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:2
+msgid "Transport Overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:6
+msgid "Transports in I2P"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:8
+msgid ""
+"A \"transport\" in I2P is a method for direct, point-to-point "
+"communication\n"
+"between two routers.\n"
+"Transports must provide confidentiality and integrity \n"
+"against external adversaries while authenticating that the router "
+"contacted \n"
+"is the one who should receive a given message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:16
+msgid ""
+"I2P supports multiple transports simultaneously.\n"
+"There are two transports currently implemented:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:21
+#, python-format
+msgid "NTCP, a Java New I/O (NIO) TCP transport"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:22
+#, python-format
+msgid " SSU, or Secure Semireliable UDP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:25
+msgid ""
+"Each provides a \"connection\" paradigm, with authentication,\n"
+"flow control, acknowledgments and retransmission."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:31
+msgid "Transport Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:33
+msgid "The transport subsystem in I2P provides the following services:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:37
+msgid ""
+"Maintain a set of router addresses, one or more for each transport,\n"
+"that the router publishes as its global contact information (the "
+"RouterInfo)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:41
+msgid "Selection of the best transport for each outgoing message"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:42
+msgid "Queueing of outbound messages by priority"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:43
+msgid ""
+"Bandwidth limiting, both outbound and inbound, according to router "
+"configuration"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:44
+msgid "Setup and teardown of transport connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:45
+msgid "Encryption of point-to-point communications"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:46
+msgid ""
+"Maintenance of connection limits for each transport, implementation of "
+"various thresholds for these limits,\n"
+"and communication of threshold status to the router so it may make "
+"operational changes based on the status"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:50
+msgid "Firewall port opening using UPnP (Universal Plug and Play)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:51
+msgid "Cooperative NAT/Firewall traversal"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:52
+msgid ""
+"Local IP detection by various methods, including UPnP, inspection of "
+"incoming connections, and enumeration of network devices"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:53
+msgid ""
+"Coordination of firewall status and local IP, and changes to either, "
+"among the transports"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:54
+#: i2p2www/pages/site/docs/transport/ssu.html:30
+msgid ""
+"Communication of firewall status and local IP, and changes to either, to "
+"the router and the user interface"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:55
+msgid ""
+"Determination of a consensus clock, which is used to periodically update "
+"the router's clock, as a backup for NTP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:56
+msgid ""
+"Maintenance of status for each peer, including whether it is connected, "
+"whether it was recently connected,\n"
+"and whether it was reachable in the last attempt"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:60
+msgid "Qualification of valid IP addresses according to a local rule set"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:61
+msgid ""
+"Honoring the automated and manual lists of banned peers maintained by the"
+" router,\n"
+"and refusing outbound and inbound connections to those peers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:68
+msgid "Transport Addresses"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:70
+msgid ""
+"The transport subsystem maintains a set of router addresses, each of "
+"which lists a transport method, IP, and port.\n"
+"These addresses constitute the advertised contact points, and are "
+"published by the router to the network database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:75
+msgid "Typical scenarios are:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:77
+msgid ""
+"A router has no published addresses, so it is considered \"hidden\" and "
+"cannot receive incoming connections"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:78
+#, python-format
+msgid ""
+"A router is firewalled, and therefore publishes an SSU address which "
+"contains a list of cooperating\n"
+"peers or \"introducers\" who will assist in NAT traversal (see the SSU spec for details)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:82
+msgid ""
+"A router is not firewalled or its NAT ports  are open; it publishes both "
+"NTCP and SSU addresses containing\n"
+"directly-accessible IP and ports."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:88
+msgid "Transport Selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:90
+#, python-format
+msgid ""
+"The transport system delivers I2NP messages. The"
+" transport selected for any message is\n"
+"independent of the application-layer protocol (TCP or UDP)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:95
+msgid ""
+"For each outgoing message, the transport system solicits \"bids\" from "
+"each transport.\n"
+"The transport bidding the lowest (best) value wins the bid and receives "
+"the message for delivery.\n"
+"A transport may refuse to bid."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:101
+msgid "Whether a transport bids, and with what value, depend on numerous factors:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:105
+msgid "Configuration of transport preferences"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:106
+msgid "Whether the transport is already connected to the peer"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:107
+msgid ""
+"The number of current connections compared to various connection limit "
+"thresholds"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:108
+msgid "Whether recent connection attempts to the peer have failed"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:109
+msgid ""
+"The size of the message, as different transports have different size "
+"limits"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:110
+msgid ""
+"Whether the peer can accept incoming connections for that transport, as "
+"advertised in its RouterInfo"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:111
+msgid "Whether the connection would be indirect (requiring introducers) or direct"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:112
+msgid "The peer's transport preference, as advertised in its RouterInfo"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:115
+msgid ""
+"In general, the bid values are selected so that two routers are only "
+"connected by a single transport\n"
+"at any one time. However, this is not a requirement."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:122
+msgid "New Transports and Future Work"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:124
+msgid "Additional transports may be developed, including:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:129
+msgid "A TLS/SSH look-alike transport"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:130
+msgid ""
+"An \"indirect\" transport for routers that are not reachable by all other"
+" routers (one form of \"restricted routes\")"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:133
+msgid ""
+"Also, the existing transports will be enhanced to support multiple "
+"addresses within a single transport,\n"
+"including IPV6 addresses. Currently, a transport may only advertise a "
+"single IPV4 address."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:138
+msgid ""
+"Work continues on adjusting default connection limits for each transport."
+"\n"
+"I2P is designed as a \"mesh network\", where it is assumed that any "
+"router can connect to any other router.\n"
+"This assumption may be broken by routers that have exceeded their "
+"connection limits, and by\n"
+"routers that are behind restrictive state firewalls (restricted routes)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:145
+msgid ""
+"The current connection limits are higher for SSU than for NTCP, based on "
+"the assumption that\n"
+"the memory requirements for an NTCP connection are higher than that for "
+"SSU.\n"
+"However, as NTCP buffers are partially in the kernel and SSU buffers are "
+"on the Java heap,\n"
+"that assumption is difficult to verify."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/index.html:152
+#, python-format
+msgid ""
+"Analyze Breaking and Improving Protocol "
+"Obfuscation\n"
+"and see how transport-layer padding may improve things."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:6
+msgid "NTCP (NIO-based TCP)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:8
+#, python-format
+msgid ""
+"NTCP is one of two transports currently "
+"implemented in I2P.\n"
+"The other is SSU.\n"
+"NTCP is a Java NIO-based transport introduced in I2P release 0.6.1.22.\n"
+"Java NIO (new I/O) does not suffer from the 1 thread per connection "
+"issues of the old TCP transport."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:15
+msgid ""
+"By default, NTCP uses the IP/Port\n"
+"auto-detected by SSU. When enabled on config.jsp,\n"
+"SSU will notify/restart NTCP when the external address changes\n"
+"or when the firewall status changes.\n"
+"Now you can enable inbound TCP without a static IP or dyndns service."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:23
+msgid ""
+"The NTCP code within I2P is relatively lightweight (1/4 the size of the "
+"SSU code)\n"
+"because it uses the underlying Java TCP transport for reliable delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:29
+msgid "NTCP Protocol Specification"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:31
+msgid "Standard Message Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:32
+msgid ""
+"After establishment,\n"
+"the NTCP transport sends individual I2NP messages, with a simple "
+"checksum.\n"
+"The unencrypted message is encoded as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:42
+msgid ""
+"The data is then AES/256/CBC encrypted. The session key for the "
+"encryption\n"
+"is negotiated during establishment (using Diffie-Hellman 2048 bit).\n"
+"The establishment between two routers is implemented in the "
+"EstablishState class\n"
+"and detailed below.\n"
+"The IV for AES/256/CBC encryption is the last 16 bytes of the previous "
+"encrypted message."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:50
+msgid ""
+"0-15 bytes of padding are required to bring the total message length\n"
+"(including the six size and checksum bytes) to a multiple of 16.\n"
+"The maximum message size is currently 16 KB.\n"
+"Therefore the maximum data size is currently 16 KB - 6, or 16378 bytes.\n"
+"The minimum data size is 1."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:58
+msgid "Time Sync Message Format"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:59
+msgid ""
+"One special case is a metadata message where the sizeof(data) is 0.  In\n"
+"that case, the unencrypted message is encoded as:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:70
+msgid ""
+"Total length: 16 bytes. The time sync message is sent at approximately 15"
+" minute intervals.\n"
+"The message is encrypted just as standard messages are."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:76
+#, fuzzy
+msgid "Checksums"
+msgstr "SHA256 Kontrollsummor:"
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:77
+#, python-format
+msgid ""
+"The standard and time sync messages use the Adler-32 checksum\n"
+"as defined in the ZLIB Specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:83
+msgid "Establishment Sequence"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:84
+msgid ""
+"In the establish state, there is a 4-phase message sequence to exchange "
+"DH keys and signatures.\n"
+"In the first two messages there is a 2048-bit Diffie Hellman exchange.\n"
+"Then, DSA signatures of the critical data are exchanged to confirm the "
+"connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:100
+msgid "Legend:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:101
+msgid "256 byte DH public keys"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:105
+msgid "timestamps (4 bytes, seconds since epoch)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:106
+msgid "32 byte Session key"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:107
+msgid "2 byte size of Alice identity to follow"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:110
+msgid "DH Key Exchange"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:111
+#, python-format
+msgid ""
+"The initial 2048-bit DH key exchange\n"
+"uses the same shared prime (p) and generator (g) as that used for I2P's\n"
+"ElGamal encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:117
+msgid ""
+"The DH key exchange consists of a number of steps, displayed below.\n"
+"The mapping between these steps and the messages sent between I2P "
+"routers,\n"
+"is marked in bold."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:123
+msgid ""
+"Alice generates a secret 226-bit integer x. She then calculates X ="
+" g^x mod p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:124
+msgid "Alice sends X to Bob (Message 1)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:125
+msgid ""
+"Bob generates a secret 226-bit integer y. He then calculates Y = "
+"g^y mod p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:126
+msgid "Bob sends Y to Alice.(Message 2)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:127
+msgid "Alice can now compute sessionKey = Y^x mod p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:128
+msgid "Bob can now compute sessionKey = X^y mod p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:129
+msgid ""
+"Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod "
+"p."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:131
+msgid ""
+"The sessionKey is then used to exchange identities in Message 3 "
+"and Message 4."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:135
+msgid "Message 1 (Session Request)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:136
+#, python-format
+msgid ""
+"This is the DH request. Alice already has Bob's\n"
+"Router "
+"Identity,\n"
+"IP address, and port, as contained in his\n"
+"Router Info,\n"
+"which was published to the\n"
+"network database.\n"
+"Alice sends Bob:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:149
+#: i2p2www/pages/site/docs/transport/ntcp.html:192
+#: i2p2www/pages/site/docs/transport/ntcp.html:272
+#: i2p2www/pages/site/docs/transport/ntcp.html:355
+msgid "Size:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:151
+msgid "Contents:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:169
+msgid "256 byte X from Diffie Hellman"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:171
+#, python-format
+msgid ""
+"SHA256 Hash(X) xored with SHA256 Hash(Bob's Router Identity)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:178
+#: i2p2www/pages/site/docs/transport/ntcp.html:259
+#: i2p2www/pages/site/docs/transport/ntcp.html:336
+msgid "Notes:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:179
+msgid ""
+"Bob verifies HXxorHI using his own router hash. If it does not verify,\n"
+"Alice has contacted the wrong router, and Bob drops the connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:185
+msgid "Message 2 (Session Created)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:186
+msgid "This is the DH reply. Bob sends Alice:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:194
+#: i2p2www/pages/site/docs/transport/ntcp.html:274
+#: i2p2www/pages/site/docs/transport/ntcp.html:357
+msgid "Unencrypted Contents:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:216
+#: i2p2www/pages/site/docs/transport/ntcp.html:250
+msgid "256 byte Y from Diffie Hellman"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:218
+msgid "SHA256 Hash(X concatenated with Y)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:221
+#: i2p2www/pages/site/docs/transport/ntcp.html:306
+msgid "4 byte timestamp (seconds since the epoch)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:223
+msgid "12 bytes random data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:228
+#: i2p2www/pages/site/docs/transport/ntcp.html:318
+#: i2p2www/pages/site/docs/transport/ntcp.html:385
+msgid "Encrypted Contents:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:252
+#, python-format
+msgid ""
+"48 bytes AES encrypted using the DH "
+"session key and\n"
+"                  the last 16 bytes of Y as the IV"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:260
+msgid ""
+"Alice may drop the connection if the clock skew with Bob is too high as "
+"calculated using tsB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:265
+msgid "Message 3 (Session Confirm A)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:266
+msgid ""
+"This contains Alice's router identity, and a DSA signature of the "
+"critical data. Alice sends Bob:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:300
+msgid "2 byte size of Alice's router identity to follow (should always be 387)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:302
+#, python-format
+msgid ""
+"Alice's 387 byte Router Identity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:308
+msgid "15 bytes random data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:310
+#, python-format
+msgid ""
+"the 40 byte DSA "
+"signature of the following concatenated data:\n"
+"             X, Y, Bob's Router Identity, "
+"tsA, tsB.\n"
+"             Alice signs it with the private signing "
+"key associated with the public signing "
+"key in her Router Identity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:328
+#, python-format
+msgid ""
+"448 bytes AES encrypted using the DH"
+" session key and\n"
+"                  the last 16 bytes of HXxorHI (i.e., the last 16 bytes "
+"of message #1) as the IV"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:338
+msgid "Bob verifies the signature, and on failure, drops the connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:341
+msgid ""
+"Bob may drop the connection if the clock skew with Alice is too high as "
+"calculated using tsA."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:348
+msgid "Message 4 (Session Confirm B)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:349
+msgid "This is a DSA signature of the critical data. Bob sends Alice:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:374
+#, python-format
+msgid ""
+"the 40 byte DSA "
+"signature of the following concatenated data:\n"
+"             X, Y, Alice's Router Identity, "
+"tsA, tsB.\n"
+"             Bob signs it with the private signing "
+"key associated with the public signing "
+"key in his Router Identity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:380
+msgid "8 bytes random data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:395
+#, python-format
+msgid ""
+"48 bytes AES encrypted using the DH "
+"session key and\n"
+"                  the last 16 bytes of the encrypted contents of message "
+"#2 as the IV"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:403
+msgid "Alice verifies the signature, and on failure, drops the connection."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:410
+msgid "After Establishment"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:411
+msgid ""
+"The connection is established, and standard or time sync messages may be "
+"exchanged.\n"
+"All subsequent messages are AES encrypted using the negotiated DH session"
+" key.\n"
+"Alice will use the last 16 bytes of the encrypted contents of message #3 "
+"as the next IV.\n"
+"Bob will use the last 16 bytes of the encrypted contents of message #4 as"
+" the next IV."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:420
+msgid "Check Connection Message"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:421
+msgid ""
+"Alternately, when Bob receives a connection, it could be a\n"
+"check connection (perhaps prompted by Bob asking for someone\n"
+"to verify his listener).\n"
+"Check Connection is not currently used.\n"
+"However, for the record, check connections are formatted as follows.\n"
+"A check info connection will receive 256 bytes containing:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:430
+msgid "32 bytes of uninterpreted, ignored data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:431
+msgid "1 byte size"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:432
+msgid ""
+"that many bytes making up the local router's IP address (as reached by "
+"the remote side)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:433
+msgid "2 byte port number that the local router was reached on"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:434
+msgid ""
+"4 byte i2p network time as known by the remote side (seconds since the "
+"epoch)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:435
+msgid "uninterpreted padding data, up to byte 223"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:436
+msgid ""
+"xor of the local router's identity hash and the SHA256 of bytes 32 "
+"through bytes 223"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:440
+msgid "Discussion"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:441
+#, python-format
+msgid "Now on the NTCP Discussion Page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:447
+msgid "The maximum message size should be increased to approximately 32 KB."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:451
+msgid ""
+"A set of fixed packet sizes may be appropriate to further hide the data \n"
+"fragmentation to external adversaries, but the tunnel, garlic, and end to"
+" \n"
+"end padding should be sufficient for most needs until then.\n"
+"However, there is currently no provision for padding beyond the next "
+"16-byte boundary,\n"
+"to create a limited number of message sizes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:459
+msgid ""
+"Memory utilization (including that of the kernel) for NTCP should be "
+"compared to that for SSU."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:463
+msgid ""
+"Can the establishment messages be randomly padded somehow, to frustrate\n"
+"identification of I2P traffic based on initial packet sizes?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ntcp.html:468
+msgid "Review and possibly disable 'check connection'"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:2
+msgid "SSU Transport"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:3
+msgid "October 2012"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:6
+msgid "Secure Semireliable UDP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:7
+#, python-format
+msgid ""
+"SSU (also called \"UDP\" in much of the I2P documentation and user "
+"interfaces)\n"
+"is one of two transports currently "
+"implemented in I2P.\n"
+"The other is NTCP."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:13
+msgid ""
+"SSU is the newer of the two transports,\n"
+"introduced in I2P release 0.6.\n"
+"In a standard I2P installation, the router uses both NTCP and SSU for "
+"outbound connections."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:19
+msgid "SSU Services"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:21
+msgid ""
+"Like the NTCP transport, SSU provides reliable, encrypted, connection-"
+"oriented, point-to-point data transport.\n"
+"Unique to SSU, it also provides IP detection and NAT traversal services, "
+"including:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:27
+msgid ""
+"Cooperative NAT/Firewall traversal using introducers"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:28
+msgid ""
+"Local IP detection by inspection of incoming packets and peer testing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:29
+msgid ""
+"Communication of firewall status and local IP, and changes to either to "
+"NTCP"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:34
+msgid "Protocol Details"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:36
+msgid "Congestion control"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:38
+msgid ""
+"SSU's need for only semireliable delivery, TCP-friendly operation,\n"
+"and the capacity for high throughput allows a great deal of latitude in\n"
+"congestion control.  The congestion control algorithm outlined below is\n"
+"meant to be both efficient in bandwidth as well as simple to implement."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:45
+msgid ""
+"Packets are scheduled according to the router's policy, taking care\n"
+"not to exceed the router's outbound capacity or to exceed the measured \n"
+"capacity of the remote peer.  The measured capacity operates along the\n"
+"lines of TCP's slow start and congestion avoidance, with additive "
+"increases\n"
+"to the sending capacity and multiplicative decreases in face of "
+"congestion.\n"
+"Unlike for TCP, routers may give up on some messages after\n"
+"a given period or number of retransmissions while continuing to transmit"
+" \n"
+"other messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:56
+msgid ""
+"The congestion detection techniques vary from TCP as well, since each \n"
+"message has its own unique and nonsequential identifier, and each message"
+"\n"
+"has a limited size - at most, 32KB.  To efficiently transmit this "
+"feedback\n"
+"to the sender, the receiver periodically includes a list of fully ACKed \n"
+"message identifiers and may also include bitfields for partially received"
+"\n"
+"messages, where each bit represents the reception of a fragment.  If \n"
+"duplicate fragments arrive, the message should be ACKed again, or if the\n"
+"message has still not been fully received, the bitfield should be \n"
+"retransmitted with any new updates."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:68
+msgid ""
+"The current implementation does not pad the packets to\n"
+"any particular size, but instead just places a single message fragment "
+"into\n"
+"a packet and sends it off (careful not to exceed the MTU)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:75
+msgid ""
+"As of router version 0.8.12,\n"
+"two MTU values are used: 620 and 1484.\n"
+"The MTU value is adjusted based on the percentage of packets that are "
+"retransmitted."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:81
+msgid ""
+"For both MTU values, it is desirable that (MTU % 16) == 12, so that\n"
+"the payload portion after the 28-byte IP/UDP header is a multiple of\n"
+"16 bytes, for encryption purposes.\n"
+"This calculation is for IPv4 only. While the protocol as specified "
+"supports IPv6\n"
+"addresses, IPv6 is not yet implemented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:89
+msgid ""
+"For the small MTU value, it is desirable to pack a 2646-byte\n"
+"Variable Tunnel Build Message efficiently into multiple packets;\n"
+"with a 620-byte MTU, it fits into 5 packets with nicely."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:95
+msgid ""
+"Based on measurements, 1492 fits nearly all reasonably small I2NP "
+"messages\n"
+"(larger I2NP messages may be up to 1900 to 4500 bytes, which isn't going "
+"to fit\n"
+"into a live network MTU anyway)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:101
+msgid ""
+"The MTU values were 608 and 1492 for releases 0.8.9 - 0.8.11.\n"
+"The large MTU was 1350 prior to release 0.8.9."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:106
+msgid ""
+"The maximum receive packet size\n"
+"is 1571 bytes as of release 0.8.12.\n"
+"For releases 0.8.9 - 0.8.11 it was 1535 bytes.\n"
+"Prior to release 0.8.9 it was 2048 bytes."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:113
+msgid ""
+"As of release 0.9.2, if a router's network interface MTU is less than "
+"1484,\n"
+"it will publish that in the network database, and other routers should\n"
+"honor that when a connection is established."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:119
+msgid "Message Size Limits"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:120
+msgid ""
+"While the maximum message size is nominally 32KB, the practical\n"
+"limit differs. The protocol limits the number of fragments to 7 bits, or "
+"128.\n"
+"The current implementation, however, limits each message to a maximum of "
+"64 fragments,\n"
+"which is sufficient for 64 * 534 = 33.3 KB when using the 608 MTU.\n"
+"Due to overhead for bundled LeaseSets and session keys, the practical "
+"limit\n"
+"at the application level is about 6KB lower, or about 26KB.\n"
+"Further work is necessary to raise the UDP transport limit above 32KB.\n"
+"For connections using the larger MTU, larger messages are possible."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:131
+msgid "Keys"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:133
+msgid ""
+"All encryption used is AES256/CBC with 32 byte keys and 16 byte IVs.\n"
+"The MAC and session keys are negotiated as part of the DH exchange, used\n"
+"for the HMAC and encryption, respectively.  Prior to the DH exchange, \n"
+"the publicly knowable introKey is used for the MAC and encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:140
+msgid ""
+"When using the introKey, both the initial message and any subsequent\n"
+"reply use the introKey of the responder (Bob) - the responder does \n"
+"not need to know the introKey of the requester (Alice).  The DSA \n"
+"signing key used by Bob should already be known to Alice when she \n"
+"contacts him, though Alice's DSA key may not already be known by \n"
+"Bob."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:149
+msgid ""
+"Upon receiving a message, the receiver checks the \"from\" IP address and"
+" port\n"
+"with all established sessions - if there are matches,\n"
+"that session's MAC keys are tested in the HMAC.  If none\n"
+"of those verify or if there are no matching IP addresses, the \n"
+"receiver tries their introKey in the MAC.  If that does not verify,\n"
+"the packet is dropped.  If it does verify, it is interpreted \n"
+"according to the message type, though if the receiver is overloaded,\n"
+"it may be dropped anyway."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:160
+msgid ""
+"If Alice and Bob have an established session, but Alice loses the \n"
+"keys for some reason and she wants to contact Bob, she may at any \n"
+"time simply establish a new session through the SessionRequest and\n"
+"related messages.  If Bob has lost the key but Alice does not know\n"
+"that, she will first attempt to prod him to reply, by sending a \n"
+"DataMessage with the wantReply flag set, and if Bob continually \n"
+"fails to reply, she will assume the key is lost and reestablish a \n"
+"new one."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:171
+#, python-format
+msgid ""
+"For the DH key agreement,\n"
+"RFC3526 2048bit\n"
+"MODP group (#14) is used:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:181
+#, python-format
+msgid ""
+"These are the same p and g used for I2P's\n"
+"ElGamal encryption."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:186
+msgid "Replay prevention"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:188
+msgid ""
+"Replay prevention at the SSU layer occurs by rejecting packets \n"
+"with exceedingly old timestamps or those which reuse an IV.  To\n"
+"detect duplicate IVs, a sequence of Bloom filters are employed to\n"
+"\"decay\" periodically so that only recently added IVs are detected."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:195
+msgid ""
+"The messageIds used in DataMessages are defined at layers above\n"
+"the SSU transport and are passed through transparently.  These IDs\n"
+"are not in any particular order - in fact, they are likely to be\n"
+"entirely random.  The SSU layer makes no attempt at messageId \n"
+"replay prevention - higher layers should take that into account."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:203
+msgid "Addressing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:205
+msgid ""
+"To contact an SSU peer, one of two sets of information is necessary:\n"
+"a direct address, for when the peer is publicly reachable, or an\n"
+"indirect address, for using a third party to introduce the peer.\n"
+"There is no restriction on the number of addresses a peer may have."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:217
+msgid ""
+"Each of the addresses may also expose a series of options - special\n"
+"capabilities of that particular peer.  For a list of available\n"
+"capabilities, see below."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:223
+#, python-format
+msgid ""
+"The addresses, options, and capabilities are published in the network database."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:228
+msgid "Direct Session Establishment"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:229
+msgid ""
+"Direct session establishment is used when no third party is required for "
+"NAT traversal.\n"
+"The message sequence is as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:234
+msgid "Connection establishment (direct)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:235
+msgid "Alice connects directly to Bob."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:249
+#, python-format
+msgid ""
+"After the SessionConfirmed message is received, Bob sends a small\n"
+"DeliveryStatus message\n"
+"as a confirmation.\n"
+"In this message, the 4-byte message ID is set to a random number, and the"
+"\n"
+"8-byte \"arrival time\" is set to the current network-wide ID, which is 2"
+"\n"
+"(i.e. 0x0000000000000002)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:258
+#, python-format
+msgid ""
+"After the status message is sent, the peers exchange\n"
+"DatabaseStore messages\n"
+"containing their\n"
+"RouterInfos."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:266
+msgid ""
+"It does not appear that the type of the status message or its contents "
+"matters.\n"
+"It was originally added becasue the DatabaseStore message was delayed\n"
+"several seconds; since the store is now sent immediately, perhaps\n"
+"the status message can be eliminated."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:275
+msgid ""
+"Introduction keys are delivered through an external channel \n"
+"(the network database, where they are identical to the router Hash for "
+"now)\n"
+"and must be used when establishing a session key.  For the indirect\n"
+"address, the peer must first contact the relayhost and ask them for\n"
+"an introduction to the peer known at that relayhost under the given\n"
+"tag.  If possible, the relayhost sends a message to the addressed\n"
+"peer telling them to contact the requesting peer, and also gives \n"
+"the requesting peer the IP and port on which the addressed peer is\n"
+"located.  In addition, the peer establishing the connection must \n"
+"already know the public keys of the peer they are connecting to (but\n"
+"not necessary to any intermediary relay peer)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:289
+msgid ""
+"Indirect session establishment by means of a third party introduction\n"
+"is necessary for efficient NAT traversal.  Charlie, a router behind a\n"
+"NAT or firewall which does not allow unsolicited inbound UDP packets,\n"
+"first contacts a few peers, choosing some to serve as introducers.  Each\n"
+"of these peers (Bob, Bill, Betty, etc) provide Charlie with an "
+"introduction\n"
+"tag - a 4 byte random number - which he then makes available to the "
+"public\n"
+"as methods of contacting him.  Alice, a router who has Charlie's "
+"published\n"
+"contact methods, first sends a RelayRequest packet to one or more of the"
+" \n"
+"introducers, asking each to introduce her to Charlie (offering the \n"
+"introduction tag to identify Charlie).  Bob then forwards a RelayIntro\n"
+"packet to Charlie including Alice's public IP and port number, then sends"
+"\n"
+"Alice back a RelayResponse packet containing Charlie's public IP and port"
+"\n"
+"number.  When Charlie receives the RelayIntro packet, he sends off a "
+"small\n"
+"random packet to Alice's IP and port (poking a hole in his NAT/firewall),"
+"\n"
+"and when Alice receives Bob's RelayResponse packet, she begins a new \n"
+"full direction session establishment with the specified IP and port."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:316
+msgid "Connection establishment (indirect using an introducer)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:318
+msgid "Alice first connects to introducer Bob, who relays the request to Charlie."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:336
+msgid ""
+"After the hole punch, the session is established between Alice and "
+"Charlie as in a direct establishment."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:341
+msgid "Peer testing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:343
+msgid ""
+"The automation of collaborative reachability testing for peers is\n"
+"enabled by a sequence of PeerTest messages.  With its proper \n"
+"execution, a peer will be able to determine their own reachability\n"
+"and may update its behavior accordingly.  The testing process is \n"
+"quite simple:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:362
+msgid ""
+"Each of the PeerTest messages carry a nonce identifying the\n"
+"test series itself, as initialized by Alice.  If Alice doesn't \n"
+"get a particular message that she expects, she will retransmit\n"
+"accordingly, and based upon the data received or the messages\n"
+"missing, she will know her reachability.  The various end states\n"
+"that may be reached are as follows:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:372
+msgid ""
+"If she doesn't receive a response from Bob, she will retransmit\n"
+"up to a certain number of times, but if no response ever arrives,\n"
+"she will know that her firewall or NAT is somehow misconfigured, \n"
+"rejecting all inbound UDP packets even in direct response to an\n"
+"outbound packet.  Alternately, Bob may be down or unable to get \n"
+"Charlie to reply."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:381
+msgid ""
+"If Alice doesn't receive a PeerTest message with the \n"
+"expected nonce from a third party (Charlie), she will retransmit\n"
+"her initial request to Bob up to a certain number of times, even\n"
+"if she has received Bob's reply already.  If Charlie's first message \n"
+"still doesn't get through but Bob's does, she knows that she is\n"
+"behind a NAT or firewall that is rejecting unsolicited connection\n"
+"attempts and that port forwarding is not operating properly (the\n"
+"IP and port that Bob offered up should be forwarded)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:392
+msgid ""
+"If Alice receives Bob's PeerTest message and both of Charlie's\n"
+"PeerTest messages but the enclosed IP and port numbers in Bob's \n"
+"and Charlie's second messages don't match, she knows that she is \n"
+"behind a symmetric NAT, rewriting all of her outbound packets with\n"
+"different 'from' ports for each peer contacted.  She will need to\n"
+"explicitly forward a port and always have that port exposed for \n"
+"remote connectivity, ignoring further port discovery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:402
+msgid ""
+"If Alice receives Charlie's first message but not his second,\n"
+"she will retransmit her PeerTest message to Charlie up to a \n"
+"certain number of times, but if no response is received she knows\n"
+"that Charlie is either confused or no longer online."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:410
+msgid ""
+"Alice should choose Bob arbitrarily from known peers who seem\n"
+"to be capable of participating in peer tests.  Bob in turn should\n"
+"choose Charlie arbitrarily from peers that he knows who seem to be\n"
+"capable of participating in peer tests and who are on a different\n"
+"IP from both Bob and Alice.  If the first error condition occurs\n"
+"(Alice doesn't get PeerTest messages from Bob), Alice may decide\n"
+"to designate a new peer as Bob and try again with a different nonce."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:420
+msgid ""
+"Alice's introduction key is included in all of the PeerTest \n"
+"messages so that she doesn't need to already have an established\n"
+"session with Bob and so that Charlie can contact her without knowing\n"
+"any additional information.  Alice may go on to establish a session\n"
+"with either Bob or Charlie, but it is not required."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:429
+msgid "Transmission window, ACKs and Retransmissions"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:430
+#, python-format
+msgid ""
+"The DATA message may contain ACKs of full messages and\n"
+"partial ACKs of individual fragments of a message. See\n"
+"the data message section of\n"
+"the protocol specification page\n"
+"for details."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:438
+#, python-format
+msgid ""
+"The details of windowing, ACK, and retransmission strategies are not "
+"specified\n"
+"here. See the Java code for the current implementation.\n"
+"During the establishment phase, and for peer testing, routers\n"
+"should implement exponential backoff for retransmission.\n"
+"For an established connection, routers should implement\n"
+"an adjustable transmission window, RTT estimate and timeout, similar to "
+"TCP\n"
+"or streaming.\n"
+"See the code for initial, min and max parameters."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:450
+msgid "Security"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:451
+msgid ""
+"UDP source addresses may, of course, be spoofed.\n"
+"Additionally, the IPs and ports contained inside specific\n"
+"SSU messages (RelayRequest, RelayResponse, RelayIntro, PeerTest)\n"
+"may not be legitimate.\n"
+"Also, certain actions and responses may need to be rate-limited."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:459
+msgid ""
+"The details of validation are not specified\n"
+"here. Implementers should add defenses where appropriate."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:465
+msgid "Peer capabilities"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:469
+msgid ""
+"If the peer address contains the 'B' capability, that means \n"
+"they are willing and able to participate in peer tests as\n"
+"a 'Bob' or 'Charlie'."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:475
+msgid ""
+"If the peer address contains the 'C' capability, that means\n"
+"they are willing and able to serve as an introducer - serving\n"
+"as a Bob for an otherwise unreachable Alice."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:484
+msgid ""
+"Analysis of current SSU performance, including assessment of window size "
+"adjustment\n"
+"and other parameters, and adjustment of the protocol implementation to "
+"improve\n"
+"performance, is a topic for future work."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:490
+msgid ""
+"The current implementation repeatedly sends acknowledgments for the same "
+"packets,\n"
+"which unnecessarily increases overhead."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:495
+msgid ""
+"The default small MTU value of 620 should be analyzed and possibly "
+"increased.\n"
+"The current MTU adjustment strategy should be evaluated.\n"
+"Does a streaming lib 1730-byte packet fit in 3 small SSU packets? "
+"Probably not."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:501
+msgid "The protocol should be extended to exchange MTUs during the setup."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:505
+msgid "Rekeying is currently unimplemented and may never be."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:509
+msgid ""
+"The potential use of the 'challenge' fields in RelayIntro and "
+"RelayResponse,\n"
+"and use of the padding field in SessionRequest and SessionCreated, is "
+"undocumented."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:514
+msgid ""
+"Instead of a single fragment per packet, a more efficient\n"
+"strategy may be to bundle multiple message fragments into the same "
+"packet,\n"
+"so long as it doesn't exceed the MTU."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:520
+msgid ""
+"A set of fixed packet sizes may be appropriate to further hide the data \n"
+"fragmentation to external adversaries, but the tunnel, garlic, and end to"
+" \n"
+"end padding should be sufficient for most needs until then."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:526
+msgid ""
+"Why are introduction keys the same as the router hash, should it be "
+"changed, would there be any benefit?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:530
+msgid "Capacities appear to be unused."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:534
+msgid ""
+"Signed-on times in SessionCreated and SessionConfirmed appear to be "
+"unused or unverified."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:539
+msgid "Implementation Diagram"
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:540
+msgid ""
+"This diagram\n"
+"should accurately reflect the current implementation, however there may "
+"be small differences."
+msgstr ""
+
+#: i2p2www/pages/site/docs/transport/ssu.html:548
+msgid "Now on the SSU specification page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:2
+msgid "Tunnel Implementation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:3
+msgid "October 2010"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:7
+msgid "This page documents the current tunnel implementation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:9
+msgid "Tunnel overview"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:11
+msgid ""
+"Within I2P, messages are passed in one direction through a virtual\n"
+"tunnel of peers, using whatever means are available to pass the \n"
+"message on to the next hop.  Messages arrive at the tunnel's \n"
+"gateway, get bundled up and/or fragmented into fixed-size tunnel "
+"messages, \n"
+"and are forwarded on to the next hop in the tunnel, which processes and "
+"verifies\n"
+"the validity of the message and sends it on to the next hop, and so on, "
+"until\n"
+"it reaches the tunnel endpoint.  That endpoint takes the messages\n"
+"bundled up by the gateway and forwards them as instructed - either\n"
+"to another router, to another tunnel on another router, or locally."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:23
+msgid ""
+"Tunnels all work the same, but can be segmented into two different\n"
+"groups - inbound tunnels and outbound tunnels.  The inbound tunnels\n"
+"have an untrusted gateway which passes messages down towards the \n"
+"tunnel creator, which serves as the tunnel endpoint.  For outbound \n"
+"tunnels, the tunnel creator serves as the gateway, passing messages\n"
+"out to the remote endpoint."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:32
+msgid ""
+"The tunnel's creator selects exactly which peers will participate\n"
+"in the tunnel, and provides each with the necessary configuration\n"
+"data.  They may have any number of hops.\n"
+"It is the intent to make\n"
+"it hard for either participants or third parties to determine the length "
+"of \n"
+"a tunnel, or even for colluding participants to determine whether they "
+"are a\n"
+"part of the same tunnel at all (barring the situation where colluding "
+"peers are\n"
+"next to each other in the tunnel)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:43
+msgid ""
+"In practice, a series of tunnel pools are used for different\n"
+"purposes - each local client destination has its own set of inbound\n"
+"tunnels and outbound tunnels, configured to meet its anonymity and\n"
+"performance needs.  In addition, the router itself maintains a series\n"
+"of pools for participating in the network database and for managing\n"
+"the tunnels themselves."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:52
+msgid ""
+"I2P is an inherently packet switched network, even with these \n"
+"tunnels, allowing it to take advantage of multiple tunnels running \n"
+"in parallel, increasing resilience and balancing load.  Outside of\n"
+"the core I2P layer, there is an optional end to end streaming library \n"
+"available for client applications, exposing TCP-esque operation,\n"
+"including message reordering, retransmission, congestion control, etc."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:61
+#, python-format
+msgid ""
+"An overview of I2P tunnel terminology is\n"
+"on the tunnel overview page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:66
+msgid "Tunnel Operation (Message Processing)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:69
+#, python-format
+msgid ""
+"After a tunnel is built, I2NP messages are "
+"processed and passed through it.\n"
+"Tunnel operation has four distinct processes, taken on by various \n"
+"peers in the tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:75
+msgid ""
+"First, the tunnel gateway accumulates a number\n"
+"of I2NP messages and preprocesses them into tunnel messages for\n"
+"delivery."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:80
+msgid ""
+"Next, that gateway encrypts that preprocessed data, then\n"
+"forwards it to the first hop."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:84
+msgid ""
+"That peer, and subsequent tunnel \n"
+"participants, unwrap a layer of the encryption, verifying that it isn't\n"
+"a duplicate, then forward it on to the next peer."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:89
+msgid ""
+"Eventually, the tunnel messages arrive at the endpoint where the I2NP "
+"messages\n"
+"originally bundled by the gateway are reassembled and forwarded on as \n"
+"requested."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:96
+msgid ""
+"Intermediate tunnel participants do not know whether they are in an\n"
+"inbound or an outbound tunnel; they always \"encrypt\" for the next hop.\n"
+"Therefore, we take advantage of symmetric AES encryption\n"
+"to \"decrypt\" at the outbound tunnel gateway,\n"
+"so that the plaintext is revealed at the outbound endpoint."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:110
+msgid "Role"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:111
+msgid "Preprocessing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:112
+msgid "Encryption Operation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:113
+msgid "Postprocessing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:117
+msgid "Outbound Gateway (Creator)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:118
+#: i2p2www/pages/site/docs/tunnels/implementation.html:141
+msgid "Fragment, Batch, and Pad"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:119
+msgid "Iteratively encrypt (using decryption operations)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:120
+#: i2p2www/pages/site/docs/tunnels/implementation.html:127
+#: i2p2www/pages/site/docs/tunnels/implementation.html:143
+#: i2p2www/pages/site/docs/tunnels/implementation.html:150
+msgid "Forward to next hop"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:124
+#: i2p2www/pages/site/docs/tunnels/implementation.html:147
+msgid "Participant"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:126
+msgid "Decrypt (using an encryption operation)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:133
+msgid "Decrypt (using an encryption operation) to reveal plaintext tunnel message"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:134
+msgid "Reassemble Fragments, Forward as instructed to Inbound Gateway or Router"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:142
+#: i2p2www/pages/site/docs/tunnels/implementation.html:149
+msgid "Encrypt"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:154
+msgid "Inbound Endpoint (Creator)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:156
+msgid "Iteratively decrypt to reveal plaintext tunnel message"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:157
+msgid "Reassemble Fragments, Receive data"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:163
+msgid "Gateway Processing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:164
+msgid "Message Preprocessing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:166
+#, python-format
+msgid ""
+"A tunnel gateway's function is to fragment and pack\n"
+"I2NP messages into fixed-size\n"
+"tunnel messages\n"
+"and encrypt the tunnel messages.\n"
+"Tunnel messages contain the following:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:174
+msgid "A 4 byte Tunnel ID"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:175
+msgid "A 16 byte IV (initialization vector)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:176
+msgid "A checksum"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:177
+msgid "Padding, if necessary"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:178
+msgid "One or more { delivery instruction, I2NP message fragment } pairs"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:181
+msgid ""
+"Tunnel IDs are 4 byte numbers used at each hop - participants know what\n"
+"tunnel ID to listen for messages with and what tunnel ID they should be "
+"forwarded\n"
+"on as to the next hop, and each hop chooses the tunnel ID which they "
+"receive messages\n"
+"on.  Tunnels themselves are short-lived (10 minutes).\n"
+"Even if subsequent tunnels are built using the same sequence of \n"
+"peers, each hop's tunnel ID will change."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:190
+msgid ""
+"To prevent adversaries from tagging the messages along the path by "
+"adjusting\n"
+"the message size, all tunnel messages are a fixed 1024 bytes in size.  To"
+" accommodate \n"
+"larger I2NP messages as well as to support smaller ones more efficiently,"
+" the\n"
+"gateway splits up the larger I2NP messages into fragments contained "
+"within each\n"
+"tunnel message.  The endpoint will attempt to rebuild the I2NP message "
+"from the\n"
+"fragments for a short period of time, but will discard them as necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:199
+#, python-format
+msgid ""
+"Details are in the\n"
+"tunnel message specification."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:205
+msgid "Gateway Encryption"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:207
+msgid ""
+"After the preprocessing of messages into a padded payload, the gateway "
+"builds\n"
+"a random 16 byte IV value, iteratively encrypting it and the tunnel "
+"message as\n"
+"necessary, and forwards the tuple {tunnelID, IV, encrypted tunnel "
+"message} to the next hop."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:213
+msgid ""
+"How encryption at the gateway is done depends on whether the tunnel is an"
+"\n"
+"inbound or an outbound tunnel.  For inbound tunnels, they simply select a"
+" random\n"
+"IV, postprocessing and updating it to generate the IV for the gateway and"
+" using \n"
+"that IV along side their own layer key to encrypt the preprocessed data."
+"  For outbound \n"
+"tunnels they must iteratively decrypt the (unencrypted) IV and "
+"preprocessed \n"
+"data with the IV and layer keys for all hops in the tunnel.  The result "
+"of the outbound\n"
+"tunnel encryption is that when each peer encrypts it, the endpoint will "
+"recover \n"
+"the initial preprocessed data."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:225
+msgid "Participant Processing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:227
+msgid ""
+"When a peer receives a tunnel message, it checks that the message came "
+"from\n"
+"the same previous hop as before (initialized when the first message comes"
+" through\n"
+"the tunnel).  If the previous peer is a different router, or if the "
+"message has\n"
+"already been seen, the message is dropped.  The participant then encrypts"
+" the \n"
+"received IV with AES256/ECB using their IV key to determine the current "
+"IV, uses \n"
+"that IV with the participant's layer key to encrypt the data, encrypts "
+"the \n"
+"current IV with AES256/ECB using their IV key again, then forwards the "
+"tuple \n"
+"{nextTunnelId, nextIV, encryptedData} to the next hop.  This double "
+"encryption\n"
+"of the IV (both before and after use) help address a certain class of\n"
+"confirmation attacks."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:240
+msgid ""
+"Duplicate message detection is handled by a decaying Bloom filter on "
+"message\n"
+"IVs.  Each router maintains a single Bloom filter to contain the XOR of "
+"the IV and\n"
+"the first block of the message received for all of the tunnels it is "
+"participating\n"
+"in, modified to drop seen entries after 10-20 minutes (when the tunnels "
+"will have\n"
+"expired).  The size of the bloom filter and the parameters used are "
+"sufficient to\n"
+"more than saturate the router's network connection with a negligible "
+"chance of \n"
+"false positive.  The unique value fed into the Bloom filter is the XOR of"
+" the IV \n"
+"and the first block so as to prevent nonsequential colluding peers in the"
+" tunnel \n"
+"from tagging a message by resending it with the IV and first block "
+"switched."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:253
+msgid "Endpoint Processing"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:255
+msgid ""
+"After receiving and validating a tunnel message at the last hop in the "
+"tunnel,\n"
+"how the endpoint recovers the data encoded by the gateway depends upon "
+"whether \n"
+"the tunnel is an inbound or an outbound tunnel.  For outbound tunnels, "
+"the \n"
+"endpoint encrypts the message with its layer key just like any other "
+"participant, \n"
+"exposing the preprocessed data.  For inbound tunnels, the endpoint is "
+"also the \n"
+"tunnel creator so they can merely iteratively decrypt the IV and message,"
+" using the \n"
+"layer and IV keys of each step in reverse order."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:265
+msgid ""
+"At this point, the tunnel endpoint has the preprocessed data sent by the "
+"gateway,\n"
+"which it may then parse out into the included I2NP messages and forwards "
+"them as\n"
+"requested in their delivery instructions."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:272
+msgid "Tunnel Building"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:274
+msgid ""
+"When building a tunnel, the creator must send a request with the "
+"necessary\n"
+"configuration data to each of the hops and wait for all of them to agree "
+"before\n"
+"enabling the tunnel.  The requests are encrypted so that only the peers "
+"who need\n"
+"to know a piece of information (such as the tunnel layer or IV key) has "
+"that\n"
+"data.  In addition, only the tunnel creator will have access to the "
+"peer's\n"
+"reply.  There are three important dimensions to keep in mind when "
+"producing\n"
+"the tunnels: what peers are used (and where), how the requests are sent "
+"(and \n"
+"replies received), and how they are maintained."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:288
+msgid ""
+"Beyond the two types of tunnels - inbound and outbound - there are two "
+"styles\n"
+"of peer selection used for different tunnels - exploratory and client.\n"
+"Exploratory tunnels are used for both network database maintenance and "
+"tunnel\n"
+"maintenance, while client tunnels are used for end to end client messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:296
+msgid "Exploratory tunnel peer selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:298
+msgid ""
+"Exploratory tunnels are built out of a random selection of peers from a "
+"subset\n"
+"of the network.  The particular subset varies on the local router and on "
+"what their\n"
+"tunnel routing needs are.  In general, the exploratory tunnels are built "
+"out of\n"
+"randomly selected peers who are in the peer's \"not failing but active\" "
+"profile\n"
+"category.  The secondary purpose of the tunnels, beyond merely tunnel "
+"routing,\n"
+"is to find underutilized high capacity peers so that they can be promoted"
+" for\n"
+"use in client tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:308
+#, python-format
+msgid ""
+"Exploratory peer selection is discussed further on the\n"
+"Peer Profiling and Selection page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:314
+msgid "Client tunnel peer selection"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:316
+msgid ""
+"Client tunnels are built with a more stringent set of requirements - the "
+"local\n"
+"router will select peers out of its \"fast and high capacity\" profile "
+"category so\n"
+"that performance and reliability will meet the needs of the client "
+"application.\n"
+"However, there are several important details beyond that basic selection "
+"that \n"
+"should be adhered to, depending upon the client's anonymity needs."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:324
+#, python-format
+msgid ""
+"Client peer selection is discussed further on the\n"
+"Peer Profiling and Selection page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:329
+msgid "Peer Ordering within Tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:331
+#, python-format
+msgid ""
+"Peers are ordered within tunnels to deal with the\n"
+"predecessor attack\n"
+"(2008 update)."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:338
+msgid ""
+"To frustrate the predecessor \n"
+"attack, the tunnel selection keeps the peers selected in a strict order -"
+"\n"
+"if A, B, and C are in a tunnel for a particular tunnel pool, the hop "
+"after A is always B, and the hop after\n"
+"B is always C."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:345
+msgid ""
+"Ordering is implemented by generating a random 32-byte key for each\n"
+"tunnel pool at startup.\n"
+"Peers should not be able to guess the ordering, or an attacker could\n"
+"craft two router hashes far apart to maximize the chance of being at both"
+"\n"
+"ends of a tunnel.\n"
+"Peers are sorted by XOR distance of the\n"
+"SHA256 Hash of (the peer's hash concatenated with the random key) from "
+"the random key"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:360
+msgid ""
+"Because each tunnel pool uses a different random key, ordering is "
+"consistent\n"
+"within a single pool but not between different pools.\n"
+"New keys are generated at each router restart."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:367
+msgid "Request delivery"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:369
+#, python-format
+msgid ""
+"A multi-hop tunnel is built using a single build message which is "
+"repeatedly\n"
+"decrypted and forwarded. In the terminology of\n"
+"Hashing it out in Public,\n"
+"this is \"non-interactive\" telescopic tunnel building."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:376
+#, python-format
+msgid ""
+"This tunnel request preparation, delivery, and response method is\n"
+"designed to reduce the number of\n"
+"predecessors exposed, cuts the number of messages transmitted, verifies "
+"proper\n"
+"connectivity, and avoids the message counting attack of traditional "
+"telescopic\n"
+"tunnel creation.\n"
+"(This method, which sends messages to extend a tunnel through the "
+"already-established\n"
+"part of the tunnel, is termed \"interactive\" telescopic tunnel building "
+"in\n"
+"the \"Hashing it out\" paper.)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:387
+#, python-format
+msgid ""
+"The details of tunnel request and response messages, and their "
+"encryption,\n"
+"are specified here."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:392
+msgid ""
+"Peers may reject tunnel creation requests for a variety of reasons, "
+"though\n"
+"a series of four increasingly severe rejections are known: probabilistic "
+"rejection\n"
+"(due to approaching the router's capacity, or in response to a flood of "
+"requests), \n"
+"transient overload, bandwidth overload, and critical failure.  When "
+"received, \n"
+"those four are interpreted by the tunnel creator to help adjust their "
+"profile of\n"
+"the router in question."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:401
+#, python-format
+msgid ""
+"For more information on peer profiling, see the\n"
+"Peer Profiling and Selection page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:407
+msgid "Tunnel Pools"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:409
+#, python-format
+msgid ""
+"To allow efficient operation, the router maintains a series of tunnel "
+"pools,\n"
+"each managing a group of tunnels used for a specific purpose with their "
+"own\n"
+"configuration.  When a tunnel is needed for that purpose, the router "
+"selects one\n"
+"out of the appropriate pool at random.  Overall, there are two "
+"exploratory tunnel\n"
+"pools - one inbound and one outbound - each using the router's default "
+"configuration.\n"
+"In addition, there is a pair of pools for each local destination -\n"
+"one inbound and one outbound tunnel pool.  Those pools use the "
+"configuration specified\n"
+"when the local destination connects to the router via I2CP, or the router's defaults if\n"
+"not specified."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:421
+#, python-format
+msgid ""
+"Each pool has within its configuration a few key settings, defining how "
+"many\n"
+"tunnels to keep active, how many backup tunnels to maintain in case of "
+"failure,\n"
+"how long the tunnels should be, whether those\n"
+"lengths should be randomized, as \n"
+"well as any of the other settings allowed when configuring individual "
+"tunnels.\n"
+"Configuration options are specified on the I2CP "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:431
+msgid "Tunnel Lengths and Defaults"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:433
+msgid "On the tunnel overview page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:435
+msgid "Anticipatory Build Strategy and Priority"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:437
+msgid ""
+"Tunnel building is expensive, and tunnels expire a fixed time after they "
+"are built.\n"
+"However, when a pool that runs out of tunnels, the Destination is "
+"essentially dead.\n"
+"In addition, tunnel build success rate may vary greatly with both local "
+"and global\n"
+"network conditions.\n"
+"Therefore, it is important to maintain an anticipatory, adaptive build "
+"strategy\n"
+"to ensure that new tunnels are successfully built before they are needed,"
+"\n"
+"without building an excess of tunnels, building them too soon,\n"
+"or consuming too much CPU or bandwidth creating and sending the encrypted"
+" build messages."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:448
+msgid ""
+"For each tuple {exploratory/client, in/out, length, length variance}\n"
+"the router maintains statistics on the time required for a successful\n"
+"tunnel build.\n"
+"Using these statistics, it calculates how long before a tunnel's "
+"expiration\n"
+"it should start attempting to build a replacement.\n"
+"As the expiration time approaches without a successful replacement,\n"
+"it starts multiple build attempts in parallel, and then\n"
+"will increase the number of parallel attempts if necessary."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:459
+msgid ""
+"To cap bandwidth and CPU usage,\n"
+"the router also limits the maximum number of build attempts outstanding\n"
+"across all pools.\n"
+"Critical builds (those for exploratory tunnels, and for pools that have\n"
+"run out of tunnels) are prioritized."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:468
+msgid "Tunnel Message Throttling"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:470
+msgid ""
+"Even though the tunnels within I2P bear a resemblance to a circuit "
+"switched\n"
+"network, everything within I2P is strictly message based - tunnels are "
+"merely\n"
+"accounting tricks to help organize the delivery of messages.  No "
+"assumptions are\n"
+"made regarding reliability or ordering of messages, and retransmissions "
+"are left\n"
+"to higher levels (e.g. I2P's client layer streaming library).  This "
+"allows I2P\n"
+"to take advantage of throttling techniques available to both packet "
+"switched and\n"
+"circuit switched networks.  For instance, each router may keep track of "
+"the \n"
+"moving average of how much data each tunnel is using, combine that with "
+"all of \n"
+"the averages used by other tunnels the router is participating in, and be"
+" able\n"
+"to accept or reject additional tunnel participation requests based on its"
+" \n"
+"capacity and utilization.  On the other hand, each router can simply drop"
+" \n"
+"messages that are beyond its capacity, exploiting the research used on "
+"the \n"
+"normal Internet."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:486
+msgid ""
+"In the current implementation, routers implement a\n"
+"weighted random early discard (WRED) strategy.\n"
+"For all participating routers (internal participant, inbound gateway, and"
+" outbound endpoint),\n"
+"the router will start randomly dropping a portion of messages as the\n"
+"bandwidth limits are approached.\n"
+"As traffic gets closer to, or exceeds, the limits, more messages are "
+"dropped.\n"
+"For an internal participant, all messages are fragmented and padded and "
+"therefore are the same size.\n"
+"At the inbound gateway and outbound endpoint, however, the dropping "
+"decision is made\n"
+"on the full (coalesced) message, and the message size is taken into "
+"account.\n"
+"Larger messages are more likely to be dropped.\n"
+"Also, messages are more likely to be dropped at the outbound endpoint "
+"than the inbound gateway,\n"
+"as those messages are not as \"far along\" in their journey and thus the "
+"network cost of\n"
+"dropping those messages is lower."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:504
+msgid "Mixing/batching"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:506
+msgid ""
+"What strategies could be used at the gateway and at each hop for "
+"delaying,\n"
+"reordering, rerouting, or padding messages?  To what extent should this "
+"be done\n"
+"automatically, how much should be configured as a per tunnel or per hop "
+"setting,\n"
+"and how should the tunnel's creator (and in turn, user) control this "
+"operation?\n"
+"All of this is left as unknown, to be worked out for a distant future "
+"release."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:515
+msgid "Padding"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:516
+msgid ""
+"The padding strategies can be used on a variety of levels, addressing the"
+"\n"
+"exposure of message size information to different adversaries.\n"
+"The current fixed tunnel message size is 1024 bytes.  Within this "
+"however, the fragmented\n"
+"messages themselves are not padded by the tunnel at all, though for end "
+"to end \n"
+"messages, they may be padded as part of the garlic wrapping."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/implementation.html:526
+msgid ""
+"WRED strategies have a significant impact on end-to-end performance,\n"
+"and prevention of network congestion collapse.\n"
+"The current WRED strategy should be carefully evaluated and improved."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/old-implementation.html:2
+msgid "Old Tunnel Implementation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/old-implementation.html:5
+#, python-format
+msgid ""
+"Note: Obsolete - NOT used!  Replaced in 0.6.1.10 - see here for the current implementation"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:7
+msgid ""
+"This page describes the origins and design of I2P's unidirectional "
+"tunnels.\n"
+"For further infomrmation see:"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:13
+msgid "Tunnel overview page"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:19
+msgid "Tunnel design discussion"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:23
+msgid "Meeting 125 (~13:12-13:30)"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:28
+msgid "Review"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:30
+msgid ""
+"While we aren't aware of any published research on the advantages of \n"
+"unidirecdtional tunnels,\n"
+"they appear to make it harder to detect a \n"
+"request/response pattern, which is quite possible to detect over a \n"
+"bidirectional tunnel.\n"
+"Several apps and protocols, notably HTTP,\n"
+"do transfer data in such manner. Having the traffic follow the same \n"
+"route to its destination and back could make it easier for an \n"
+"attacker who has only timing and traffic volume data to infer the path a"
+" \n"
+"tunnel is taking.\n"
+"Having the response come back along a different path arguably \n"
+"makes it harder."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:45
+msgid ""
+"When dealing with \n"
+"an internal adversary or most external adversaries, I2P's undirectional "
+"tunnels\n"
+"expose half as much traffic data than would be exposed with bidirectional"
+" circuits\n"
+"by simply looking at the flows themselves - an HTTP request and response "
+"would \n"
+"follow the same path in Tor, while in I2P the packets making up the "
+"request \n"
+"would go out through one or more outbound tunnels and the packets making "
+"up \n"
+"the response would come back through one or more different inbound "
+"tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:55
+msgid ""
+"The strategy of using two separate tunnels for inbound and outbound\n"
+"communication is not the only technique available, and it does have "
+"anonymity\n"
+"implications.  On the positive side, by using separate tunnels it lessens"
+" the\n"
+"traffic data exposed for analysis to participants in a tunnel - for "
+"instance,\n"
+"peers in an outbound tunnel from a web browser would only see the traffic"
+" of\n"
+"an HTTP GET, while the peers in an inbound tunnel would see the payload \n"
+"delivered along the tunnel.  With bidirectional tunnels, all participants"
+" would\n"
+"have access to the fact that e.g. 1KB was sent in one direction, then "
+"100KB\n"
+"in the other.  On the negative side, using unidirectional tunnels means "
+"that\n"
+"there are two sets of peers which need to be profiled and accounted for, "
+"and\n"
+"additional care must be taken to address the increased speed of "
+"predecessor\n"
+"attacks.  The tunnel pooling and building process\n"
+"(peer selection and ordering strategies)\n"
+"should minimize the worries of the predecessor attack."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:73
+msgid "Anonymity"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:75
+#, python-format
+msgid ""
+"A recent paper by Hermann and Grothoff\n"
+"declared that I2P's unidirectional tunnels \"seems to be a bad design "
+"decision\"."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:80
+msgid ""
+"The paper's main point is that\n"
+"deanonymizations on unidirectional tunnels take a longer time, which is "
+"an \n"
+"advantage, but that an attacker can be more certain in the unidirectional"
+" case. \n"
+"Therefore, the paper claims it isn't an advantage at all, but a "
+"disadvantage, at least\n"
+"with long-living eepsites."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:88
+msgid ""
+"This conclusion is not fully supported by the paper. Unidirectional "
+"tunnels clearly \n"
+"mitigate other attacks and it's not clear how to trade off the risk of "
+"the \n"
+"attack in the paper\n"
+"with attacks on a bidirectional tunnel architecture."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:95
+msgid ""
+"This conclusion is based on an arbitrary certainty vs. time weighting \n"
+"(tradeoff) that may not be applicable in all cases. For \n"
+"example, somebody could make a list of possible IPs then issue subpoenas "
+"to \n"
+"each. Or the attacker could DDoS each in turn and via a simple \n"
+"intersection attack see if the eepsite goes down or is slowed down. So "
+"close \n"
+"may be good enough, or time may be more important."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:104
+msgid ""
+"The conclusion is based on a specific weighting of the importance of "
+"certainty \n"
+"vs. time, and that weighting may be wrong, and it's definitely debatable,"
+" \n"
+"especially in a real world with subpoenas, search warrants, and other "
+"methods \n"
+"available for final confirmation."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:111
+msgid ""
+"A full analysis of the tradeoffs of unidirectional vs. bidirectional \n"
+"tunnels is clearly outside the scope of the paper, and has not been done"
+" \n"
+"elsewhere. For example, how does this attack compare to the numerous "
+"possible \n"
+"timing attacks published about onion-routed networks? Clearly the authors"
+" have not\n"
+"done that analysis, if it's even possible to do it\n"
+"effectively."
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:120
+msgid ""
+"Tor uses bidirectional tunnels and has had a lot of academic review. I2P"
+" \n"
+"uses unidirectional tunnels and has had very little review. Does the lack"
+" of a \n"
+"research paper defending unidirectional tunnels mean that it is a poor "
+"design \n"
+"choice, or just that it needs more study? Timing attacks and \n"
+"distributed attacks are difficult to defend against in both I2P and Tor. "
+"The \n"
+"design intent (see references above) was that unidirectional tunnels are "
+"more \n"
+"resistant to timing attacks. However, the paper presents a somewhat "
+"different type of timing \n"
+"attack. Is this attack, innovative as it is, sufficient to label I2P's \n"
+"tunnel architecture (and thus I2P as a whole) a \"bad design\", and by \n"
+"implication clearly inferior to Tor, or is it just a design alternative "
+"that \n"
+"clearly needs further investigation and analysis? There are several other"
+" reasons \n"
+"to consider I2P currently inferior to Tor and other projects (small "
+"network \n"
+"size, lack of funding, lack of review) but is unidirectional tunnels "
+"really a \n"
+"reason?"
+msgstr ""
+
+#: i2p2www/pages/site/docs/tunnels/unidirectional.html:137
+msgid ""
+"In summary, \"bad design decision\" is apparently (since the paper does\n"
+"not label bidirectional tunnels \"bad\") shorthand for \"unidirectional \n"
+"tunnels are unequivocally inferior to bidirectional tunnels\", yet this \n"
+"conclusion is not supported by the paper."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:4
+msgid ""
+"Thank you for your interest in contributing to I2P!\n"
+"The details of how you\n"
+"can make your contribution are provided below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:13
+#, python-format
+msgid "You can donate direct via PayPal to the account \"%(account)s\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:19
+msgid "One time donation:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:33
+msgid "Donate 10 €/month for 12 months:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:41
+#: i2p2www/pages/site/get-involved/donate.html:53
+#: i2p2www/pages/site/get-involved/donate.html:65
+#: i2p2www/pages/site/get-involved/donate.html:77
+msgid "I2P donation "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:47
+msgid "Donate 20 €/month for 12 months:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:59
+msgid "Donate 30 €/month for 12 months:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:71
+msgid "Donate 50 €/month for 12 months:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:86
+msgid "Flattr this"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:90
+#, python-format
+msgid ""
+"As of December 2010, eche|on has been running a Bitcoin account for the I2P project. \n"
+"If you'd like to donate using Bitcoin, just transfer your desired amount "
+"of coins to the account \n"
+"%(account)s and leave eche|on a note if you'd like your donation "
+"to be mentioned on the I2P webpage."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:95
+msgid ""
+"If you want to keep more or less anonymous, the option to send money via "
+"mail is also available. But it is less secure\n"
+"as the envelope can be lost on the way to us."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:99
+#, python-format
+msgid ""
+"If you'd like to donate via  snail mail, send an email to %(email)s\n"
+" and you'll receive an email with instructions detailing how to proceed."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/donate.html:104
+#, python-format
+msgid ""
+"In the meantime, feel free to take a look at the generous donations that "
+"have been\n"
+"given in support of the I2P Project at the hall of fame."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:2
+msgid "Get Involved!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:4
+msgid "We need your help!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:5
+msgid ""
+"To get involved, please feel free to join us on the #i2p IRC channel (on\n"
+"irc.freenode.net, or within I2P on irc.freshcoffee.i2p or "
+"irc.postman.i2p)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:9
+#, python-format
+msgid ""
+"If you're interested in joining our team, please"
+" get in\n"
+"touch as we're always looking for eager contributors!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:13
+msgid ""
+"We need help in many areas, and you don't need to know Java to "
+"contribute!\n"
+"Here's a list to help you get started!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:18
+msgid "Spread the Word!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:19
+msgid ""
+"Tell people about I2P on forums, blogs, and comments to articles.\n"
+"Fix up the Wikipedia article about I2P in your language.\n"
+"Tell your friends."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:24
+msgid "Testing"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:25
+#, python-format
+msgid ""
+"Run the latest builds from monotone\n"
+"and report results on #i2p or as bugs on Trac."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:30
+msgid ""
+"Help fix the parts of the website that are outdated or incomplete.\n"
+"Translate pages into other languages."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:34
+msgid "Pictures"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:35
+msgid "Make some more pictures, fix the old ones on the website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:39
+msgid "Make an eepsite! Add some content! Contribute to the community!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:42
+msgid "Services"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:43
+msgid ""
+"Run a service on an eepsite. It could be a proxy, a forum, a tracker,\n"
+"a naming service, a search engine, an eepsite monitor... many of these\n"
+"aren't that hard."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:49
+#, python-format
+msgid ""
+"Write or port applications for I2P! There's some guidelines and\n"
+"a list of ideas on the applications page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:53
+msgid "Coding"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:54
+#, python-format
+msgid ""
+"There's plenty to do if you know Java or are ready to learn.\n"
+"Check for open tickets on Trac\n"
+"or the TODO list on %(zzz)s for\n"
+"some ideas on where to start.\n"
+"See the new developer's guide for details."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:61
+msgid "Translation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:62
+#, python-format
+msgid ""
+"Help translate the website and the software into your language.\n"
+"See the new translator's guide for details."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:66
+msgid "Analysis"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/index.html:67
+#, python-format
+msgid ""
+"Study or test the code to look for vulnerabilities.\n"
+"Both anonymity vulnerabilities from the various\n"
+"threat models,\n"
+"and DOS and other weaknesses due to securities holes,\n"
+"need researching."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:7
+msgid ""
+"Include some seed data in the distribution so a central reseed location "
+"isn't required?"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:10
+#, python-format
+msgid ""
+"Reachability Mapping / handle peers partially reachable / enhanced restricted routes"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:13
+msgid "Improve help pages and website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:14
+msgid "More translations"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:15
+msgid "SSU disconnect message"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:16
+msgid "Iterative floodfill lookups"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:21
+msgid "Full review of anonymity issues and other vulnerabilities"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:22
+msgid ""
+"Reduce memory usage, remove debugging overhead, make it run better on "
+"slow and embedded machines"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:25
+msgid "Docs"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:30
+msgid "Full restricted routes"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:35
+msgid "Tunnel mixing and padding"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:36
+msgid "User defined message delays"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/roadmap.html:39
+#, python-format
+msgid ""
+"Please see the TODO list for more detailed info "
+"about some of these tasks."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:4
+msgid "I2P Project Targets"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:5
+#, python-format
+msgid ""
+"Below is a more detailed (yet still incomplete) discussion of the major "
+"areas\n"
+"of future development on the core I2P network, spanning the plausibly "
+"planned\n"
+"releases. This does not include stego transports, porting to wireless "
+"devices,\n"
+"or tools to secure the local machine, nor does it include client "
+"applications\n"
+"that will be essential in I2P's success. There are probably other things "
+"that\n"
+"will come up, especially as I2P gets more peer review, but these are the "
+"main\n"
+"'big things'. See also the roadmap. Want to "
+"help?\n"
+"Get involved!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:16
+#: i2p2www/pages/site/get-involved/todo.html:54
+msgid "Core functionality"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:18
+#: i2p2www/pages/site/get-involved/todo.html:57
+msgid "NAT/Firewall bridging via 1-hop restricted routes"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:21
+#: i2p2www/pages/site/get-involved/todo.html:130
+msgid "High degree transport layer with UDP, NBIO, or NIO"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:24
+#: i2p2www/pages/site/get-involved/todo.html:218
+msgid "NetworkDB and profile tuning and ejection policy for large nets"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:28
+#: i2p2www/pages/site/get-involved/todo.html:242
+msgid "Security / anonymity"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:30
+#: i2p2www/pages/site/get-involved/todo.html:245
+msgid ""
+"Per-hop tunnel id & new permuted TunnelVerificationStructure "
+"encryption"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:33
+#: i2p2www/pages/site/get-involved/todo.html:295
+msgid "Strict ordering of participants within tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:36
+msgid "Randomly permuted tunnel lengths"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:39
+#: i2p2www/pages/site/get-involved/todo.html:357
+msgid "Full blown n-hop restricted routes with optional trusted links"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:42
+#: i2p2www/pages/site/get-involved/todo.html:376
+msgid "Hashcash for routerIdentity, destination, and tunnel request"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:45
+#: i2p2www/pages/site/get-involved/todo.html:405
+msgid "Advanced tunnel operation (batching/mixing/throttling/padding)"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:48
+#: i2p2www/pages/site/get-involved/todo.html:442
+msgid "Stop & go mix w/ garlics & tunnels"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:62
+msgid "Implemented in I2P 0.6.0.6"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:63
+msgid ""
+"The functionality of allowing routers to fully participate within the "
+"network \n"
+"while behind firewalls and NATs that they do not control requires some "
+"basic \n"
+"restricted route operation (since those peers will not be able to receive"
+" \n"
+"inbound connections). To do this successfully, you consider peers one of"
+" \n"
+"two ways:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:73
+msgid ""
+"Peers who have reachable interfaces - these peers do not need to \n"
+"do anything special"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:77
+msgid ""
+"Peers who do not have reachable interfaces - these peers must "
+"build \n"
+"a tunnel pointing at them where the gateway is one of the peers they have"
+" \n"
+"established a connection with who has both a publicly reachable interface"
+" \n"
+"and who has agreed to serve as their 'introducer'."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:85
+msgid ""
+"To do this, peers who have no IP address simply connect to a few peers, \n"
+"build a tunnel through them, and publish a reference to those tunnels "
+"within \n"
+"their RouterInfo structure in the network database."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:90
+msgid ""
+"When someone wants to contact any particular router, they first must get"
+" \n"
+"its RouterInfo from the network database, which will tell them whether "
+"they \n"
+"can connect directly (e.g. the peer has a publicly reachable interface) \n"
+"or whether they need to contact them indirectly. Direct connections occur"
+" \n"
+"as normal, while indirect connections are done through one of the "
+"published \n"
+"tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:98
+msgid ""
+"When a router just wants to get a message or two to a specific hidden "
+"peer, \n"
+"they can just use the indirect tunnel for sending the payload. However, \n"
+"if the router wants to talk to the hidden peer often (for instance, as "
+"part \n"
+"of a tunnel), they will send a garlic routed message through the indirect"
+" \n"
+"tunnel to that hidden peer which unwraps to contain a message which "
+"should \n"
+"be sent to the originating router. That hidden peer then establishes an \n"
+"outbound connection to the originating router and from then on, those two"
+" \n"
+"routers can talk to each other directly over that newly established "
+"direct \n"
+"connection."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:109
+msgid ""
+"Of course, that only works if the originating peer can receive "
+"connections \n"
+"(they aren't also hidden). However, if the originating peer is hidden, "
+"they \n"
+"can simply direct the garlic routed message to come back to the "
+"originating \n"
+"peer's inbound tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:115
+msgid ""
+"This is not meant to provide a way for a peer's IP address to be "
+"concealed, \n"
+"merely as a way to let people behind firewalls and NATs fully operate "
+"within \n"
+"the network. Concealing the peer's IP address adds a little more work, as"
+" \n"
+"described below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:121
+msgid ""
+"With this technique, any router can participate as any part of a tunnel."
+" \n"
+"For efficiency purposes, a hidden peer would be a bad choice for an "
+"inbound \n"
+"gateway, and within any given tunnel, two neighboring peers wouldn't want"
+" \n"
+"to be hidden. But that is not technically necessary."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:133
+msgid "Both UDP and NIO have been Implemented in I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:134
+msgid ""
+"Standard TCP communication in Java generally requires blocking socket \n"
+"calls, and to keep a blocked socket from hanging the entire system, those"
+" \n"
+"blocking calls are done on their own threads. Our current TCP transport \n"
+"is implemented in a naive fashion - for each peer we are talking to, we \n"
+"have one thread reading and one thread writing. The reader thread simply"
+" \n"
+"loops a bunch of read() calls, building I2NP messages and adding them \n"
+"to our internal inbound message queue, and the writer thread pulls "
+"messages \n"
+"off a per-connection outbound message queue and shoves the data through \n"
+"write() calls."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:145
+msgid ""
+"We do this fairly efficiently, from a CPU perspective - at any time, \n"
+"almost all of these threads are sitting idle, blocked waiting for "
+"something \n"
+"to do. However, each thread consumes real resources (on older Linux "
+"kernels, \n"
+"for instance, each thread would often be implemented as a fork()'ed "
+"process). \n"
+"As the network grows, the number of peers each router will want to talk \n"
+"with will increase (remember, I2P is fully connected, meaning that any \n"
+"given peer should know how to get a message to any other peer, and "
+"restricted \n"
+"route support will probably not significantly reduce the number of "
+"connections \n"
+"necessary). This means that with a 100,000 router network, each router \n"
+"will have up to 199,998 threads just to deal with the TCP connections!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:157
+msgid ""
+"Obviously, that just won't work. We need to use a transport layer that \n"
+"can scale. In Java, we have two main camps:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:162
+#, python-format
+msgid ""
+"Implemented in I2P 0.6 (\"SSU\") as documented elsewhere"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:165
+msgid ""
+"Sending and receiving UDP datagrams is a connectionless operation - if \n"
+"we are communicating with 100,000 peers, we simply stick the UDP packets"
+" \n"
+"in a queue and have a single thread pulling them off the queue and "
+"shoving \n"
+"them out the pipe (and to receive, have a single thread pulling in any \n"
+"UDP packets received and adding them to an inbound queue)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:172
+msgid ""
+"However, moving to UDP means losing the benefits of TCP's ordering, "
+"congestion \n"
+"control, MTU discovery, etc. Implementing that code will take significant"
+" \n"
+"work, however I2P doesn't need it to be as strong as TCP. Specifically, \n"
+"a while ago I was taking some measurements in the simulator and on the \n"
+"live net, and the vast majority of messages transferred would fit easily"
+" \n"
+"within a single unfragmented UDP packet, and the largest of the messages"
+" \n"
+"would fit within 20-30 packets. As mule pointed out, TCP adds a "
+"significant \n"
+"overhead when dealing with so many small packets, as the ACKs are within"
+" \n"
+"an order of magnitude in size. With UDP, we can optimize the transport \n"
+"for both efficiency and resilience by taking into account I2P's "
+"particular \n"
+"needs."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:185
+msgid "It will be a lot of work though."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:188
+msgid "NIO or NBIO"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:189
+msgid "NIO Implemented in I2P 0.6.1.22 (\"NTCP\")"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:192
+msgid ""
+"In Java 1.4, a set of \"New I/O\" packages was introduced, allowing Java"
+" \n"
+"developers to take advantage of the operating system's nonblocking IO \n"
+"capabilities - allowing you to maintain a large number of concurrent IO \n"
+"operations without requiring a separate thread for each. There is much \n"
+"promise with this approach, as we can scalable handle a large number of \n"
+"concurrent connections and we don't have to write a mini-TCP stack with \n"
+"UDP. However, the NIO packages have not proven themselves to be battle-"
+"ready, \n"
+"as the Freenet developer's found. In addition, requiring NIO support "
+"would \n"
+"mean we can't run on any of the open source JVMs like Kaffe, \n"
+"as GNU/Classpath has only "
+"limited \n"
+"support for NIO. (note: this may not be the case anymore, as there \n"
+"has been some progress on Classpath's NIO, but it is an unknown "
+"quantity)"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:206
+#, python-format
+msgid ""
+"Another alternative along the same lines is the Non"
+" \n"
+"Blocking I/O package - essentially a cleanroom NIO implementation \n"
+"(written before NIO was around). It works by using some native OS code \n"
+"to do the nonblocking IO, passing off events through Java. It seems to \n"
+"be working with Kaffe, though there doesn't seem to be much development \n"
+"activity on it lately (likely due to 1.4's NIO deployment)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:221
+msgid ""
+"Within the current network database and profile management "
+"implementation, \n"
+"we have taken the liberty of some practical shortcuts. For instance, we \n"
+"don't have the code to drop peer references from the K-buckets, as we \n"
+"don't have enough peers to even plausibly fill any of them, so instead, \n"
+"we just keep the peers in whatever bucket is appropriate. Another example"
+" \n"
+"deals with the peer profiles - the memory required to maintain each "
+"peer's \n"
+"profile is small enough that we can keep thousands of full blown profiles"
+" \n"
+"in memory without problems. While we have the capacity to use trimmed \n"
+"down profiles (which we can maintain 100s of thousands in memory), we \n"
+"don't have any code to deal with moving a profile from a \"minimal "
+"profile\" \n"
+"to a \"full profile\", a \"full profile\" to a \"minimal profile\", or to"
+" simply \n"
+"eject a profile altogether. It just wouldn't be practical to write that \n"
+"code yet, since we aren't going to need it for a while."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:236
+msgid ""
+"That said, as the network grows we are going to want to keep these "
+"considerations \n"
+"in mind. We will have some work to do, but we can put it off for later."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:248
+#: i2p2www/pages/site/get-involved/todo.html:332
+#, python-format
+msgid ""
+"Addressed in I2P 0.5 as documented elsewhere"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:251
+msgid ""
+"Right now, if Alice builds a four hop inbound tunnel starting at Elvis, \n"
+"going to Dave, then to Charlie, then Bob, and finally Alice "
+"(A<--B<--C<--D<--E), \n"
+"all five of them will know they are participating in tunnel \"123\", as \n"
+"the messages are tagged as such. What we want to do is give each hop "
+"their \n"
+"own unique tunnel hop ID - Charlie will receive messages on tunnel 234 \n"
+"and forward them to tunnel 876 on Bob. The intent is to prevent Bob or \n"
+"Charlie from knowing that they are in Alice's tunnel, as if each hop in \n"
+"the tunnel had the same tunnel ID, collusion attacks aren't much work."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:261
+msgid ""
+"Adding a unique tunnel ID per hop isn't hard, but by itself, "
+"insufficient. \n"
+"If Dave and Bob are under the control of the same attacker, they wouldn't"
+" \n"
+"be able to tell they are in the same tunnel due to the tunnel ID, but \n"
+"would be able to tell by the message bodies and verification structures \n"
+"by simply comparing them. To prevent that, the tunnel must use layered \n"
+"encryption along the path, both on the payload of the tunneled message \n"
+"and on the verification structure (used to prevent simple tagging "
+"attacks). \n"
+"This requires some simple modifications to the TunnelMessage, as well \n"
+"as the inclusion of per-hop secret keys delivered during tunnel creation"
+" \n"
+"and given to the tunnel's gateway. We must fix a maximum tunnel length \n"
+"(e.g. 16 hops) and instruct the gateway to encrypt the message to each \n"
+"of the 16 delivered secret keys, in reverse order, and to encrypt the \n"
+"signature of the hash of the (encrypted) payload at each step. The "
+"gateway \n"
+"then sends that 16-step encrypted message, along with a 16-step and "
+"16-wide \n"
+"encrypted mapping to the first hop, which then decrypts the mapping and \n"
+"the payload with their secret key, looking in the 16-wide mapping for \n"
+"the entry associated with their own hop (keyed by the per-hop tunnel ID)"
+" \n"
+"and verifying the payload by checking it against the associated signed \n"
+"hash."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:282
+msgid ""
+"The tunnel gateway does still have more information than the other peers"
+" \n"
+"in the tunnel, and compromising both the gateway and a tunnel participant"
+" \n"
+"would allow those peers to collude, exposing the fact that they are both"
+" \n"
+"in the same tunnel. In addition, neighboring peers know that they are \n"
+"in the same tunnel anyway, as they know who they send the message to (and"
+" \n"
+"with IP-based transports without restricted routes, they know who they \n"
+"got it from). However, the above two techniques significantly increase \n"
+"the cost of gaining meaningful samples when dealing with longer tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:298
+msgid "Implemented in release 0.6.2"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:301
+#, python-format
+msgid ""
+"As Connelly proposed to deal with the\n"
+"predecessor attack (2008\n"
+"update), keeping the order of peers within our tunnels consistent \n"
+"(aka whenever Alice creates a tunnel with both Bob and Charlie in it, \n"
+"Bob's next hop is always Charlie), we address the issue as Bob doesn't \n"
+"get to substantially sample Alice's peer selection group. We may even \n"
+"want to explicitly allow Bob to participate in Alice's tunnels in only \n"
+"one way - receiving a message from Dave and sending it to Charlie - and \n"
+"if any of those peers are not available to participate in the tunnel (due"
+" \n"
+"to overload, network disconnection, etc), avoid asking Bob to participate"
+" \n"
+"in any tunnels until they are back online."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:316
+msgid ""
+"More analysis is necessary for revising the tunnel creation - at the \n"
+"moment, we simply select and order randomly within the peer's top tier \n"
+"of peers (ones with fast + high capacity)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:321
+msgid ""
+"Adding a strict ordering to peers in a tunnel also improves the anonymity"
+" \n"
+"of peers with 0-hop tunnels, as otherwise the fact that a peer's gateway"
+" \n"
+"is always the same would be particularly damning. However, peers with \n"
+"0-hop tunnels may want to periodically use a 1-hop tunnel to simulate \n"
+"the failure of a normally reliable gateway peer (so every MTBF*(tunnel \n"
+"duration) minutes, use a 1-hop tunnel)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:338
+msgid ""
+"Without tunnel length permutation, if someone were to somehow detect that"
+" \n"
+"a destination had a particular number of hops, it might be able to use "
+"that \n"
+"information to identify the router the destination is located on, per the"
+" \n"
+"predecessor attack. For instance, if everyone has 2-hop tunnels, if Bob \n"
+"receives a tunnel message from Charlie and forwards it to Alice, Bob "
+"knows \n"
+"Alice is the final router in the tunnel. If Bob were to identify what "
+"destination \n"
+"that tunnel served (by means of colluding with the gateway and harvesting"
+" \n"
+"the network database for all of the LeaseSets), he would know the router"
+" \n"
+"on which that destination is located (and without restricted routes, that"
+" \n"
+"would mean what IP address the destination is on)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:350
+msgid ""
+"It is to counter user behavior that tunnel lengths should be permuted, \n"
+"using algorithms based on the length requested (for example, the 1/MTBF \n"
+"length change for 0-hop tunnels outlined above)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:360
+msgid ""
+"The restricted route functionality described before was simply a "
+"functional \n"
+"issue - how to let peers who would not otherwise be able to communicate \n"
+"do so. However, the concept of allowing restricted routes includes "
+"additional \n"
+"capabilities. For instance, if a router absolutely cannot risk "
+"communicating \n"
+"directly with any untrusted peers, they can set up trusted links through"
+" \n"
+"those peers, using them to both send and receive all of its messages. \n"
+"Those hidden peers who want to be completely isolated would also refuse \n"
+"to connect to peers who attempt to get them to (as demonstrated by the \n"
+"garlic routing technique outlined before) - they can simply take the "
+"garlic \n"
+"clove that has a request for delivery to a particular peer and tunnel \n"
+"route that message out one of the hidden peer's trusted links with "
+"instructions \n"
+"to forward it as requested."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:379
+#, python-format
+msgid ""
+"Within the network, we will want some way to deter people from consuming"
+" \n"
+"too many resources or from creating so many peers to mount a Sybil \n"
+"attack. Traditional techniques such as having a peer see who is "
+"requesting \n"
+"a resource or running a peer aren't appropriate for use within I2P, as \n"
+"doing so would compromise the anonymity of the system. Instead, we want \n"
+"to make certain requests \"expensive\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:387
+msgid ""
+"Hashcash is one technique that \n"
+"we can use to anonymously increase the \"cost\" of doing certain "
+"activities, \n"
+"such as creating a new router identity (done only once on installation),"
+" \n"
+"creating a new destination (done only once when creating a service), or \n"
+"requesting that a peer participate in a tunnel (done often, perhaps 2-300"
+" \n"
+"times per hour). We don't know the \"correct\" cost of each type of "
+"certificate \n"
+"yet, but with some research and experimentation, we could set a base "
+"level \n"
+"that is sufficiently expensive while not an excessive burden for people \n"
+"with few resources."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:398
+msgid ""
+"There are a few other algorithms that we can explore for making those \n"
+"requests for resources \"nonfree\", and further research on that front is"
+" \n"
+"appropriate."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:408
+#, python-format
+msgid ""
+"To powerful passive external observers as well as large colluding "
+"internal \n"
+"observers, standard tunnel routing is vulnerable to traffic analysis "
+"attacks \n"
+"- simply watching the size and frequency of messages being passed between"
+" \n"
+"routers. To defend against these, we will want to essentially turn some \n"
+"of the tunnels into its own mix cascade - delaying messages received at \n"
+"the gateway and passing them in batches, reordering them as necessary, \n"
+"and injecting dummy messages (indistinguishable from other \"real\" "
+"tunnel \n"
+"messages by peers in the path). There has been a significant amount of \n"
+"research \n"
+"on these algorithms that we can lean on prior to implementing the various"
+" \n"
+"tunnel mixing strategies."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:421
+msgid ""
+"In addition to the anonymity aspects of more varied tunnel operation, \n"
+"there is a functional dimension as well. Each peer only has a certain \n"
+"amount of data they can route for the network, and to keep any particular"
+" \n"
+"tunnel from consuming an unreasonable portion of that bandwidth, they \n"
+"will want to include some throttles on the tunnel. For instance, a tunnel"
+" \n"
+"may be configured to throttle itself after passing 600 messages (1 per \n"
+"second), 2.4MB (4KBps), or exceeding some moving average (8KBps for the \n"
+"last minute). Excess messages may be delayed or summarily dropped. With \n"
+"this sort of throttling, peers can provide ATM-like QoS support for their"
+" \n"
+"tunnels, refusing to agree to allocate more bandwidth than the peer has \n"
+"available."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:434
+msgid ""
+"In addition, we may want to implement code to dynamically reroute tunnels"
+" \n"
+"to avoid failed peers or to inject additional hops into the path. This \n"
+"can be done by garlic routing a message to any particular peer in a "
+"tunnel \n"
+"with instructions to redefine the next-hop in the tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:445
+msgid ""
+"Beyond the per-tunnel batching and mixing strategy, there are further \n"
+"capabilities for protecting against powerful attackers, such as allowing"
+" \n"
+"each step in a garlic routed path to define a delay or window in which \n"
+"it should be forwarded on. This would enable protections against the long"
+" \n"
+"term intersection attack, as a peer could send a message that looks "
+"perfectly \n"
+"standard to most peers that pass it along, except at any peers where the"
+" \n"
+"clove exposed includes delay instructions."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/todo.html:457
+#, python-format
+msgid ""
+"Performance related improvements are listed on the\n"
+"Performance page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:2
+msgid "Bounty Arabic translation of webpage and router console"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:3
+#: i2p2www/pages/site/get-involved/bounties/index.html:112
+msgid "Arabic translation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:6
+msgid ""
+"To improve I2P usage and attract more people\n"
+"into I2P echelon set out this bounty for translation\n"
+"of the I2P web page and I2P router console into Arabic."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:12
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:12
+msgid "This bounty is set into 2 subparts:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:14
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:14
+msgid "Part 1 is translation of the webpage."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:17
+msgid ""
+"For collecting the bounty of 20 BTC you need to translate the following "
+"pages:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:25
+msgid "This job was done by hamada and the bounty of 20 BTC was paid to hamada."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:27
+msgid ""
+"Part 2 is the translation of the router console. The router console was\n"
+"partly translated and the bounty of 80 BTC was paid to hamada."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/arabic-trans.html:34
+msgid "Judge is echelon."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/btc-client.html:2
+msgid "Bounty creating a I2P native Bitcoin client"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/btc-client.html:3
+msgid "BTC I2P native client"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/btc-client.html:6
+msgid ""
+"For a future of I2P and attract more people\n"
+"into I2P this bounty is to create a I2P native Bitcoin client. \n"
+"It should integrate with other client via the I2P network and via "
+"gateways to\n"
+"the existant bitcoin network."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/btc-client.html:15
+msgid "Judge is psychonaut who donated the first 30 € to this bounty."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:2
+msgid "Bounty datastorage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:3
+msgid "datastore"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:6
+msgid ""
+"To improve I2P's usage and to be independent of routers \n"
+"online status we want a datastorage as a extension to I2P.\n"
+"Like in Freenet the datastorage should be distributed and every\n"
+"participating node should be able to configure his options.\n"
+"The files should be saved in chunks and at least 2-3 times to\n"
+"obtain redundancy. Usage of storage space should be auto balanced.\n"
+"As it is a extra application, it should work flawless within I2P and\n"
+"cooperate nice with the I2P router. Maybe a integration within the\n"
+"webpage/router could be done."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:17
+msgid ""
+"This bounty cooperates with the 2 other bounties \"frost for I2P\" and \n"
+"\"eepsites in datastorage\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:21
+msgid ""
+"The frost for I2P datastorage bounty is paid for a frost like program \n"
+"with which files/messages are stored into database and got from database."
+"\n"
+"It needs to work with a GUI."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:26
+msgid ""
+"The eepsite served out of I2P datastorage extends a I2P router to send\n"
+"out eepsites out of the I2P datastorage. All files for eepsites need to "
+"be\n"
+"saved inside of datastorage and are taken from it.\n"
+"Extension:\n"
+"For better integration all datastorage participants could serve that "
+"eepsite."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/datastore.html:36
+msgid ""
+"For bounties to be declared done and paid, we need the program AND the "
+"source.\n"
+"Source and code need to be licensed under a free license (free to change "
+"and \n"
+"free to distribute)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/deb-pack.html:2
+msgid "Bounty I2P package in Debian and Ubuntu mirrors"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/deb-pack.html:3
+msgid "I2P Ubuntu/Debian package"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/deb-pack.html:6
+msgid ""
+"For the future of I2P and in order to attract more people\n"
+"to I2P, this bounty was set for including an I2P package into the Ubuntu "
+"and Debian \n"
+"archive mirrors.\n"
+"To claim this bounty, the I2P router package needs to be available from\n"
+"Ubuntu and Debian archive mirrors and Debian bug \n"
+"448638 \n"
+"needs to be closed successfully."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/i2phex.html:2
+msgid "Bounty I2PHex code implementation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/i2phex.html:3
+msgid "i2phex code implementation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/i2phex.html:6
+msgid ""
+"To improve I2P usage and attract more people\n"
+"into I2PHex P2P ArneBab setout the bounty for implementing actual\n"
+"Phex code onto I2PHex."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:5
+msgid "Bounties for I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:6
+msgid ""
+"While we always gratefully accept any contributions of code, \n"
+"documentation, and the like, there are other ways to help I2P move \n"
+"forward.  As with any open source project, our goals would be achieved "
+"more \n"
+"rapidly if we were able to support all of our contributors to work on \n"
+"I2P full time.  However, as with any open source project, that's not a \n"
+"possibility.  Instead, we are making use of a bounty system, whereby \n"
+"anyone can get support for working on something that people want \n"
+"implemented, and people who want to contribute to I2P can be assured that"
+" \n"
+"their support goes to what they care about."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:18
+msgid ""
+"We are also keeping open the ability for people who want to support I2P \n"
+"but don't have strong feelings about the bounties available.  Those "
+"people\n"
+"can simply put their trust in the I2P team to do what we feel is best by\n"
+"donating to a catch-all general fund that will be used as deemed \n"
+"necessary - allocated to various bounties, covering incidentals (hosting,"
+" \n"
+"etc), and the like."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:27
+msgid "Current bounties"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+#: i2p2www/pages/site/get-involved/bounties/index.html:105
+msgid "Name"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+#: i2p2www/pages/site/get-involved/bounties/index.html:105
+msgid "Status"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+msgid "Judge"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:30
+#: i2p2www/pages/site/get-involved/bounties/index.html:92
+msgid "Bounty"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:32
+msgid "Frost for I2P datastorage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:33
+#: i2p2www/pages/site/get-involved/bounties/index.html:40
+#: i2p2www/pages/site/get-involved/bounties/index.html:47
+#: i2p2www/pages/site/get-involved/bounties/index.html:54
+#: i2p2www/pages/site/get-involved/bounties/index.html:61
+#: i2p2www/pages/site/get-involved/bounties/index.html:68
+#: i2p2www/pages/site/get-involved/bounties/index.html:82
+msgid "Proposal in development"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:39
+msgid "Eepsites served out of I2P datastorage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:46
+msgid "Backporting Phex code onto I2PHex"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:53
+msgid "Make I2P IPv6 native"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:60
+msgid "I2P package in Debian and Ubuntu mirrors"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:74
+msgid "Unit tests and Multi-router Simulation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:75
+msgid "Partly done, partly in work, partly still open"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:89
+msgid "Hold bounties, set on hold due to jrandom AWOL and missing funding"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:94
+msgid "Bundling bounties"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:95
+msgid "Proposed"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:102
+msgid "Claimed bounties"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:105
+msgid "Dev team"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:107
+msgid "Setting up a SILC server"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:117
+msgid "Datastore over I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:127
+msgid "Swarming file transfer"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:132
+msgid "Streaming library window size"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:137
+msgid "IRC connect time monitor"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:142
+msgid "Unit tests (part 1)"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/index.html:154
+msgid ""
+"Dev lists anyone who may already be working on the bounty - collaboration"
+" is\n"
+"preferred, so if you're interested in working on it, please contact one "
+"of the\n"
+"people listed!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/ipv6.html:2
+msgid "Bounty I2P IPv6 native"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/ipv6.html:3
+msgid "native IPv6 I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/ipv6.html:6
+msgid ""
+"For a future of I2P and attract more people\n"
+"into I2P I withdrawal the vuze bounty and offer a IPv6 bounty.\n"
+"To claim this bounty, the I2P router needs to run full on native\n"
+"IPv6 connections like it does on IPv4."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/ipv6.html:15
+#: i2p2www/pages/site/get-involved/bounties/vuze-plugin.html:20
+msgid ""
+"For bounties to be declared done and paid, we need the plugin AND the "
+"source.\n"
+"Source and code need to be licensed under a free license (free to change "
+"and \n"
+"free to distribute)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:2
+msgid "Bounty russian translation of webpage and router console"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:3
+msgid "Russian translation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:6
+msgid ""
+"To improve I2P usage and attract more people\n"
+"into I2P a anonymous donator set out the bounty for translation\n"
+"of the I2P web page and I2P router console into russian language."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:17
+msgid ""
+"For collecting the bounty of $115 USD you need to translate the following"
+" pages:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:30
+msgid ""
+"Part 2 is the translation of the router console. The whole router console"
+" needs\n"
+"to be translated to collect the bounty of $115 USD."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/russian-trans.html:37
+msgid "Judge is the russian donor."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:2
+msgid "Bounty migrate I2P IRC to SILC"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:3
+msgid "I2P silc server"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:7
+msgid ""
+"For a future of I2P and attract more people\n"
+"into I2P this bounty is to setup and host a I2P SILC server.   \n"
+"This will allow people to send files over their messaging servers and "
+"have intrinsic security built into the protocol."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:12
+msgid ""
+"A silc server needs to be set up and run for at least 3 month time to get"
+" payed. \n"
+"A second server should be set up, to."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:16
+msgid ""
+"Bounty was withdrawn and money donated to returningnovice and general "
+"fund."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/silc.html:22
+msgid "Judge is An Anonymous Secret Society, society@mail.i2p."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/syndie-2012.html:7
+msgid ""
+"Beside of I2P we want to encourage users\n"
+"to care more about anonymity and security. As I2P is a low \n"
+"latency network with its natural limits, the software SYNDIE\n"
+"can overcome some of these limits and provide better anonymity\n"
+"for people who really need it."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/syndie-2012.html:14
+msgid ""
+"For our bad sake the syndie project is out of development for \n"
+"quite a long time yet (5 years). To get a fresh and new built \n"
+"with needed bugfixes we set out this bounty. Also syndie needs\n"
+"some enhancements and a better GUI for users to work with it.\n"
+"Current bounty sum is 100 Bitcoin."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:2
+msgid "Bounty unittests"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:3
+msgid "unit test"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:7
+msgid ""
+"To improve I2P's maintainability, we want to have a solid set of\n"
+"automated unit tests for the critical code.  While we do have some\n"
+"unit tests at the moment, they are ad-hoc and partly unfinished.  \n"
+"This bounty is for someone to check the existing tests and move over\n"
+"old ones to jUnit, automate their execution, extend them to provide \n"
+"better code coverage, and publish the report online.  Its a massive \n"
+"effort, but can be broken down into phases, listed below (phase 2 \n"
+"must occur first, but further phases may happen in any order).\n"
+"As this needs some reading of code, it is the best start point for\n"
+"new devs to get a good overview of I2P code and coding. A good job\n"
+"for college students, interns or anyone who is just interested."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:20
+msgid ""
+"Take care! Jobs and bounties shuffled a bit!\n"
+"Phase 6,7 and 8 are still open!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:26
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:40
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:55
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:66
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:77
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:88
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:101
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:112
+#, python-format
+msgid "Phase %(phase)s:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:27
+msgid "CI jenkins and IRC bot"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:28
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:42
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:57
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:68
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:79
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:90
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:103
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:114
+#, python-format
+msgid "Bounty: %(euro)s €"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:29
+msgid "server runs and this section is blocked"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:31
+msgid ""
+"To collect this bounty, a continuous integration server (Jenkins,\n"
+"old name was Hudson) must be set up and a connected IRC bot needs \n"
+"to set up in the channel #i2p-dev on IRC2p network to print out\n"
+"results of build tests.
            \n"
+"The server needs to be run long term."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:41
+msgid "Check existing SDK tests"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:43
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:69
+msgid "paid to str4d"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:45
+#, python-format
+msgid ""
+"To collect this bounty, the existing SDK tests must be checked \n"
+"and made to work again. The need to be integrated into the ant \n"
+"build scripts (\"ant test\"), and tied in with a code coverage tool (e.g."
+" \n"
+"Clover).  The ant script\n"
+"must be capable of generating test status results as a web page, \n"
+"which will be published online."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:56
+msgid "SDK test coverage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:58
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:80
+msgid "paid to unittests dev team"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:60
+msgid ""
+"To collect this bounty, the automated unit tests of the SDK \n"
+"(i2p/core/java/src) must work again."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:67
+msgid "Router test migration"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:71
+msgid ""
+"As with phase 2, the existing unit tests for the router must be\n"
+"moved over to the automated system."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:78
+msgid "Router test coverage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:82
+msgid ""
+"To collect this bounty, the automated unit tests of the router \n"
+"(i2p/router/java/src) must work again."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:89
+msgid "Streaming lib tests"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:94
+#, python-format
+msgid ""
+"To collect this bounty, a new set of unit tests must meet a \n"
+"measured code coverage of 90% of the streaming lib \n"
+"(i2p/apps/ministreaming/ and i2p/apps/streaming/)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:102
+msgid "Unit tests coverage"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:106
+msgid ""
+"To collect this bounty, all above unit tests must meet the 100%\n"
+"coverage marker (except for log statements)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:113
+msgid "MultiRouter simulation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:115
+msgid "will be split in more sub-tasks"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:117
+msgid ""
+"To collect this bounty, the existing in-memory multi-router\n"
+"simulation must be checked, made work again and extend to simulate\n"
+"lots of routers in memory on a single machine. This bounty will\n"
+"be split in more fine grained subworks."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/unit-tests.html:126
+msgid ""
+"Judge on all these works is the donor and donor decides if a phase is\n"
+"called succesfull done and money can be paid."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/vuze-plugin.html:2
+msgid "Bounty I2P vuze plugin"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/vuze-plugin.html:3
+msgid "vuze plugin"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/bounties/vuze-plugin.html:6
+msgid ""
+"To improve I2P usage and attract more people\n"
+"into I2P torrent P2P I setout the bounty for a working I2P vuze\n"
+"plugin.\n"
+"The plugin needs to be official and submitted to vuze for publication\n"
+"on their webpage/repository for plugins.\n"
+"It should be easy to install and configured, work smooth and flawless.\n"
+"Configuration should be friendly to starters and made easy to be "
+"anonymous.\n"
+"It should work with *.b32.i2p destinations as with signed (516++ bits) \n"
+"destinations."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:2
+msgid "Application Development"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:4
+msgid "Application Development Guide"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:8
+#: i2p2www/pages/site/get-involved/develop/applications.html:14
+msgid "Why write I2P-specific code?"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:9
+#: i2p2www/pages/site/get-involved/develop/applications.html:94
+msgid "Important concepts"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:10
+#: i2p2www/pages/site/get-involved/develop/applications.html:170
+msgid "Development options"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:11
+#: i2p2www/pages/site/get-involved/develop/applications.html:276
+msgid "Start developing - a simple guide"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:16
+#, python-format
+msgid ""
+"There are multiple ways to use applications in I2P.\n"
+"Using I2PTunnel,\n"
+"you can use regular applications without needing to program explicit I2P "
+"support.\n"
+"This is very effective for client-server scenario's,\n"
+"where you need to connect to a single website.\n"
+"You can simply create a tunnel using I2PTunnel to connect to that "
+"website, as shown in Figure 1."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:24
+msgid ""
+"If your application is distributed, it will require connections to a "
+"large amount of peers.\n"
+"Using I2PTunnel, you will need to create a new tunnel for each peer you "
+"want to contact,\n"
+"as shown in Figure 2.\n"
+"This process can of course be automated, but running a lot of I2PTunnel "
+"instances creates a large amount of overhead.\n"
+"In addition, with many protocols you will need to force everyone to \n"
+"use the same set of ports for all peers - e.g. if you want to reliably "
+"run DCC \n"
+"chat, everyone needs to agree that port 10001 is Alice, port 10002 is "
+"Bob, port \n"
+"10003 is Charlie, and so on, since the protocol includes TCP/IP specific "
+"information\n"
+"(host and port)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:35
+msgid ""
+"General network applications often send a lot of additional data that "
+"could be used to identify users.\n"
+"Hostnames, port numbers, time zones, character sets, etc. are often sent "
+"without informing the user.\n"
+"As such, designing the network protocol specifically with anonymity in "
+"mind\n"
+"can avoid compromising user identities."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:41
+msgid ""
+"There are also efficiency considerations to review when determining how "
+"to \n"
+"interact on top of I2P.  The streaming library and things built on top of"
+" it\n"
+"operate with handshakes similar to TCP, while the core I2P protocols "
+"(I2NP and I2CP)\n"
+"are strictly message based (like UDP or in some instances raw IP).  The "
+"important\n"
+"distinction is that with I2P, communication is operating over a long fat "
+"network - \n"
+"each end to end message will have nontrivial latencies, but may contain "
+"payloads \n"
+"of up to 32KB.  An application that needs a simple request and response "
+"can get rid\n"
+"of any state and drop the latency incurred by the startup and teardown "
+"handshakes\n"
+"by using (best effort) datagrams without having to worry about MTU "
+"detection or \n"
+"fragmentation of messages under 32KB."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:55
+#: i2p2www/pages/site/get-involved/develop/applications.html:57
+msgid ""
+"Creating a server-client connection using I2PTunnel only requires "
+"creating a single tunnel."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:57
+msgid "Figure 1:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:62
+#: i2p2www/pages/site/get-involved/develop/applications.html:64
+msgid ""
+"Setting up connections for a peer-to-peer applications requires a very "
+"large amount of tunnels."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:64
+msgid "Figure 2:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:68
+msgid "In summary, a number of reasons to write I2P-specific code:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:72
+msgid ""
+"Creating a large amount of I2PTunnel instances consumes a non-trivial "
+"amount of resources,\n"
+"which is problematic for distributed applications (a new tunnel is "
+"required for each peer)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:76
+msgid ""
+"General network protocols often send a lot of additional data that can be"
+" used to identify users.\n"
+"Programming specifically for I2P allows the creation of a network "
+"protocol\n"
+"that does not leak such information, keeping users anonymous and secure."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:81
+msgid ""
+"Network protocols designed for use on the regular internet can be "
+"inefficient\n"
+"on I2P, which is a network with a much higher latency."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:88
+msgid ""
+"Applications written in Java and accessible/runnable\n"
+"using an HTML interface via the standard webapps/app.war\n"
+"may be considered for inclusion in the i2p distribution."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:96
+msgid "There are a few changes that require adjusting to when using I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:100
+msgid "Destination ~= host+port"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:102
+msgid ""
+"An application running on I2P sends messages from and receives messages "
+"to a\n"
+"unique cryptographically secure end point - a \"destination\".  In TCP or"
+" UDP\n"
+"terms, a destination could (largely) be considered the equivalent of a "
+"hostname\n"
+"plus port number pair, though there are a few differences."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:110
+msgid ""
+"An I2P destination itself is a cryptographic construct - all data sent to"
+" one is \n"
+"encrypted as if there were universal deployment of IPsec with the "
+"(anonymized)\n"
+"location of the end point signed as if there were universal deployment of"
+" DNSSEC."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:115
+msgid ""
+"I2P destinations are mobile identifiers - they can be moved from one I2P "
+"router\n"
+"to another (or with some special software, it can even operate on "
+"multiple routers at\n"
+"once).  This is quite different from the TCP or UDP world where a single "
+"end point (port)\n"
+"must stay on a single host."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:122
+msgid ""
+"I2P destinations are ugly and large - behind the scenes, they contain a "
+"2048bit ElGamal\n"
+"public key for encryption, a 1024bit DSA public key for signing, and a "
+"variable size \n"
+"certificate, which may contain proof of work or blinded data."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:127
+#, python-format
+msgid ""
+"There are existing ways to refer to these large and ugly destinations by "
+"short\n"
+"and pretty names (e.g. \"irc.duck.i2p\"), but at the moment those "
+"techniques do not guarantee\n"
+"globally uniqueness (since they're stored locally at each person's "
+"machine as \"hosts.txt\")\n"
+"and the current mechanism is not especially scalable nor secure (updates "
+"to one host file are\n"
+"manually managed within Monotone, and as such, anyone with commit rights "
+"on the repository can\n"
+"change the destinations).  There may be some secure, human readable, "
+"scalable, and globally \n"
+"unique, naming system some day, but applications shouldn't depend upon it"
+" being in place,\n"
+"since there are those who don't think such a beast is possible.\n"
+"Further information on the naming system is "
+"available."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:141
+msgid "Anonymity and confidentiality"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:143
+msgid ""
+"A useful thing to remember is that I2P has transparent end to end "
+"encryption\n"
+"and authentication for all data passed over the network - if Bob sends to"
+" Alice's destination,\n"
+"only Alice's destination can receive it, and if Bob is using the "
+"datagrams or streaming \n"
+"library, Alice knows for certain that Bob's destination is the one who "
+"sent the data."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:150
+msgid ""
+"Of course, another useful thing to remember is that I2P transparently "
+"anonymizes the\n"
+"data sent between Alice and Bob, but it does nothing to anonymize the "
+"content of what they\n"
+"send.  For instance, if Alice sends Bob a form with her full name, "
+"government IDs, and \n"
+"credit card numbers, there is nothing I2P can do.  As such, protocols and"
+" applications should \n"
+"keep in mind what information they are trying to protect and what "
+"information they are willing\n"
+"to expose."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:159
+msgid "I2P datagrams can be up to 32KB"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:161
+msgid ""
+"Applications that use I2P datagrams (either raw or repliable ones) can "
+"essentially be thought\n"
+"of in terms of UDP - the datagrams are unordered, best effort, and "
+"connectionless - but unlike\n"
+"UDP, applications don't need to worry about MTU detection and can simply "
+"fire off 32KB datagrams\n"
+"(31KB when using the repliable kind).  For many applications, 32KB of "
+"data is sufficient for an\n"
+"entire request or response, allowing them to transparently operate in I2P"
+" as a UDP-like \n"
+"application without having to write fragmentation, resends, etc."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:172
+msgid ""
+"There are several means of sending data over I2P, each with their own "
+"pros and cons.\n"
+"The streaming lib is the recommended interface, used by the majority of "
+"I2P applications."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:177
+msgid "Streaming Lib"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:178
+#, python-format
+msgid ""
+"The full streaming library is now the "
+"standard\n"
+"interface. It allows programming using TCP-like sockets, as explained in "
+"the Streaming development guide."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:184
+#, python-format
+msgid ""
+"BOB is the Basic Open Bridge,\n"
+"allowing an application in any language to make streaming connections \n"
+"to and from I2P. At this point in time it lacks UDP support, but UDP "
+"support\n"
+"is planned in the near future. BOB also contains several tools, such as \n"
+"destination key generation, and verification that an address conforms to"
+" \n"
+"I2P specifications. Up to date info and applications that use BOB can be"
+" \n"
+"found at this eepsite."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:197
+msgid "SAM is not recommended. SAM V2 is okay, SAM V3 is beta."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:198
+#, python-format
+msgid ""
+"SAM is the Simple Anonymous Messaging protocol, "
+"allowing an\n"
+"application written in any language to talk to a SAM bridge through a "
+"plain TCP socket and have\n"
+"that bridge multiplex all of its I2P traffic, transparently coordinating "
+"the encryption/decryption\n"
+"and event based handling.  SAM supports three styles of operation:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:205
+msgid ""
+"streams, for when Alice and Bob want to send data to each other reliably "
+"and in order"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:208
+msgid ""
+"repliable datagrams, for when Alice wants to send Bob a message that Bob "
+"can reply to"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:211
+msgid ""
+"raw datagrams, for when Alice wants to squeeze the most bandwidth and "
+"performance as possible,\n"
+"and Bob doesn't care whether the data's sender is authenticated or not "
+"(e.g. the data transferred\n"
+"is self authenticating)"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:217
+msgid ""
+"SAM V3 aims at the same goal as SAM and SAM V2, but does not require\n"
+"multiplexing/demultiplexing. Each I2P stream is handled by its own socket"
+" between the application\n"
+"and the SAM bridge. Besides, datagrams can be sent and received by the "
+"application through datagram\n"
+"communications with the SAM bridge."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:224
+#, python-format
+msgid ""
+"SAM V2 is a new version used by imule\n"
+"that fixes some of the problems in SAM.\n"
+"
            \n"
+"SAM V3 is used by imule since version 1.4.0."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:232
+msgid ""
+"The I2PTunnel application allows applications to build specific TCP-like "
+"tunnels to peers \n"
+"by creating either I2PTunnel 'client' applications (which listen on a "
+"specific port and connect\n"
+"to a specific I2P destination whenever a socket to that port is opened) "
+"or I2PTunnel 'server'\n"
+"applications (which listen to a specific I2P destination and whenever it "
+"gets a new I2P \n"
+"connection it outproxies to a specific TCP host/port).  These streams are"
+" 8bit clean and are\n"
+"authenticated and secured through the same streaming library that SAM "
+"uses, but there is a \n"
+"nontrivial overhead involved with creating multiple unique I2PTunnel "
+"instances, since each have\n"
+"their own unique I2P destination and their own set of tunnels, keys, etc."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:244
+#: i2p2www/pages/site/get-involved/develop/applications.html:251
+#: i2p2www/pages/site/get-involved/develop/applications.html:262
+msgid "Not recommended"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:245
+msgid ""
+"It was possible to write I2P applications in Java using the ministreaming"
+" library.\n"
+"However, the Streaming library has superceded this, and provides better "
+"functionality."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:252
+#, python-format
+msgid ""
+"The Datagram library allows sending UDP-"
+"like packets.\n"
+"It's possible to use:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:257
+msgid "Repliable datagrams"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:258
+msgid "Raw datagrams"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:263
+#, python-format
+msgid ""
+"I2CP itself is a language independent protocol, "
+"but to implement an I2CP library \n"
+"in something other than Java there is a significant amount of code to be "
+"written (encryption routines, \n"
+"object marshalling, asynchronous message handling, etc).  While someone "
+"could write an I2CP library in \n"
+"C or something else, it would most likely be more useful to use the C SAM"
+" library instead."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:270
+msgid "Web Applications"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:271
+msgid ""
+"I2P comes with the Jetty webserver, and configuring to use the Apache "
+"server instead is straightforward.\n"
+"Any standard web app technology should work."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:277
+msgid ""
+"Developing using I2P requires a working I2P installation and a "
+"development environment of your own choice.\n"
+"If you are using Java, you can start development with the streaming library or datagram library.\n"
+"Using another programming language, SAM or BOB can be used."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:283
+msgid "Developing with the streaming library"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:285
+msgid ""
+"Development using the streaming library requires the following libraries "
+"in your classpath:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:289
+msgid "the streaming library itself."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:290
+msgid "the ministreaming library is used as the base for the streaming library."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:291
+msgid ""
+"some standard I2P classes (like the Destination class) are very "
+"convenient when developing."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:294
+msgid ""
+"Network communication requires the usage of I2P network sockets.\n"
+"To demonstrate this, we will create an application where a client can "
+"send text messages to a server,\n"
+"who will print the messages and send them back to the client. In other "
+"words, the server will function as an echo."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:299
+msgid ""
+"We will start by initializing the server application. This requires "
+"getting an I2PSocketManager\n"
+"and creating an I2PServerSocket.\n"
+"In addition, we will ask the I2PSocketManager for an I2PSession, so we "
+"can find out the Destination we use."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:327
+msgid "Code example 1: initializing the server application."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:329
+msgid ""
+"Once we have an I2PServerSocket, we can create I2PSocket instances to "
+"accept connections from clients.\n"
+"In this example, we will create a single I2PSocket instance, that can "
+"only handle one client at a time.\n"
+"A real server would have to be able to handle multiple clients.\n"
+"To do this, multiple I2PSocket instances would have to be created, each "
+"in separate threads.\n"
+"Once we have created the I2PSocket instance, we read data, print it and "
+"send it back to the client.\n"
+"The bold code is the new code we add."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:415
+msgid "Code example 2: accepting connections from clients and handling messages."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:419
+msgid ""
+"When you run the above server code, it should print something like this "
+"(but without the line endings, it should just be\n"
+"one huge block of characters):"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:433
+msgid ""
+"This is the base64-representation of the server Destination. The client "
+"will need this string to reach the server."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:437
+msgid ""
+"Now, we will create the client application. Again, a number of steps are "
+"required for initialization.\n"
+"Again, we will need to start by getting an I2PSocketManager.\n"
+"We won't use an I2PSession and an I2PServerSocket this time.\n"
+"Instead, we will use the server Destination string to start our "
+"connection.\n"
+"We will ask the user for the Destination string, and create an I2PSocket "
+"using this string.\n"
+"Once we have an I2PSocket, we can start sending and receiving data to and"
+" from the server."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:519
+msgid ""
+"Code example 3: starting the client and connecting it to the server "
+"application."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:521
+msgid ""
+"Finally, you can run both the server and the client application.\n"
+"First, start the server application. It will print a Destination string "
+"(like shown above).\n"
+"Next, start the client application. When it requests a Destination "
+"string, you can enter the string printed by the server.\n"
+"The client will then send 'Hello I2P!' (along with a newline) to the "
+"server, who will print the message and send it back to the client."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:527
+msgid "Congratulations, you have successfully communicated over I2P!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:531
+msgid "Existing Applications in Development"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:532
+msgid "Contact us if you would like to help."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:549
+msgid "Application Ideas"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:551
+msgid "NNTP server - there have been some in the past, none at the moment"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:554
+msgid ""
+"Jabber server - there have been some in the past, and there is one at the"
+" moment, with access to the public internet"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:557
+msgid "PGP Key server and/or proxy"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:560
+msgid ""
+"Download manager / eepget scheduler -\n"
+"We use eepget to fetch lots of things reliably over i2p, and there's "
+"already an\n"
+"implementation of a sequential download manager "
+"(net.i2p.util.EepGetScheduler),\n"
+"but there isn't any sort of user interface to it.  A web based UI would "
+"be\n"
+"great."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:567
+#, python-format
+msgid ""
+"Content Distribution / DHT applications - help out with feedspace,\n"
+"port dijjer, look for alternatives"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:571
+msgid "Help out with Syndie development"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:574
+msgid ""
+"Web-based applications - The sky is the limit for hosting web-server-"
+"based\n"
+"applications such as blogs, pastebins, storage, tracking, feeds, etc.\n"
+"Any web or CGI technology such as Perl, PHP, Python, or Ruby will work."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/applications.html:579
+msgid ""
+"Resurrect some old apps - in the i2p source package -\n"
+"bogobot, pants, proxyscript, q, stasher, socks proxy, i2ping"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:2
+msgid "I2P Developer's MTN Keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:4
+msgid "MTN Keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:5
+msgid ""
+"Monotone servers used by the I2P project require two types of keys to be "
+"used."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:9
+msgid ""
+"Commit Keys to sign changes checked-in to the "
+"respository; and"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:10
+msgid ""
+"Transport Keys to push changes to remote "
+"servers."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:13
+#, python-format
+msgid ""
+"Everyone that uses Monotone to checkout the I2P codebase will need to\n"
+"import the\n"
+"developer commit keys, but only Monotone \n"
+"server operators will need to import the transport keys."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:20
+msgid "Developer Commit keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:232
+msgid "Developer Transport Keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/developers-keys.html:233
+#, python-format
+msgid ""
+"Note: Transport keys are only needed for setting up a\n"
+"Monotone server."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/license-agreements.html:2
+msgid "License Agreements"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/license-agreements.html:5
+#, python-format
+msgid "For more information see the licenses page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/license-agreements.html:8
+msgid ""
+"Following is a monotonerc file defining the current trust list.\n"
+"Developers must use this file in ~/.monotone/monotonerc or\n"
+"_MTN/montonerc in their i2p.i2p workspace."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/license-agreements.html:17
+msgid "Agreements"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:4
+msgid "I2P Software Licenses"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:5
+#, python-format
+msgid ""
+"As required by our\n"
+"threat model (among other reasons), the \n"
+"software developed to support the anonymous communication \n"
+"network we call I2P must be freely available, open source, \n"
+"and user modifiable.  To meet these criteria, we make use of\n"
+"a variety of legal and software engineering techniques so\n"
+"as to remove as many barriers to entry for those considering\n"
+"making use of or contributing to the I2P effort."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:16
+msgid ""
+"While the information below may be more confusing than just simply \n"
+"stating \"I2P is BSD\", \"I2P is GPL\", or \"I2P is public domain\",\n"
+"the short answer to the question \"How is I2P licensed?\" is this:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:22
+msgid "All software bundled in the I2P distributions will allow:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:24
+msgid "use without fee"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:25
+msgid ""
+"use with no restrictions on how, when, where, why, or by whom is running "
+"it"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:26
+msgid "access to the source code without fee"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:27
+msgid "modifications to the source"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:30
+msgid ""
+"Most of the software guarantees much more - the ability of anyone "
+"to \n"
+"distribute the modified source however they choose.  However, not all of "
+"the \n"
+"software bundled provides this freedom - the GPL restricts the ability of"
+" \n"
+"developers who wish to integrate I2P with their own applications that are"
+" not \n"
+"themselves open source applications.  While we applaud the noble goals of"
+" \n"
+"increasing the resources in the commons, I2P is best served by removing "
+"any\n"
+"barriers that stand in the way of its adoption - if a developer "
+"considering whether\n"
+"they can integrate I2P with their application has to stop and check with "
+"their lawyer,\n"
+"or conduct a code audit to make sure their own source can be released as "
+"GPL-compatible,\n"
+"we lose out."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:43
+msgid "Component licenses"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:44
+msgid ""
+"The I2P distribution contains several resources, reflecting the "
+"partitioning of \n"
+"the source code into components.  Each component has its own license, "
+"which all \n"
+"developers who contribute to it agree to - either by explicitly declaring"
+" the release\n"
+"of code committed under a license compatible with that component, or by "
+"implicitly\n"
+"releasing the code committed under the component's primary license.  Each"
+" of these \n"
+"components has a lead developer who has the final say as to what license "
+"is compatible\n"
+"with the component's primary license, and the I2P project manager has the"
+" final say as\n"
+"to what licenses meet the above four guarantees for inclusion in the I2P "
+"distribution."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:57
+msgid "Component"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:58
+msgid "Source path"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:59
+msgid "Resource"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:60
+msgid "Primary license"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:61
+msgid "Alternate licenses"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:62
+msgid "Lead developer"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:271
+msgid "GPL + java exception"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:272
+#, python-format
+msgid ""
+"While it may be redundant, just for clarity the\n"
+"GPL'ed code included within\n"
+"I2PTunnel and other apps must be released under the GPL with an "
+"additional \"exception\"\n"
+"explicitly authorizing the use of Java's standard libraries:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:288
+msgid ""
+"All source code under each component will by default be licensed under "
+"the\n"
+"primary license, unless marked otherwise in the code.  All of the above "
+"is\n"
+"summary of the license terms - please see the specific license for the "
+"component\n"
+"or source code in question for authoritative terms.  Component source "
+"locations and\n"
+"resource packaging may be changed if the repository is reorganized."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:296
+msgid "Commit privileges"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:297
+#, python-format
+msgid ""
+"Developers may push changes to a distributed monotone repository if you\n"
+"receive permission from the person running that repository.\n"
+"See the Monotone Page for details."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:303
+msgid ""
+"However, to have changes included in a release, developers\n"
+"must be trusted by the release manager (currently zzz).\n"
+"In addition, they must explicitly agree with the above terms to be "
+"trusted.\n"
+"That means that they must send one of the release managers a signed "
+"message affirming that:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:310
+msgid ""
+"Unless marked otherwise, all code I commit is implicitly licensed under\n"
+"the component's primary license"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:314
+msgid ""
+"If specified in the source, the code may be explicitly licensed under one"
+"\n"
+"of the component's alternate licenses"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:318
+msgid ""
+"I have the right to release the code I commit under the terms I\n"
+"am committing it"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/licenses.html:324
+#, python-format
+msgid ""
+"If anyone is aware of any instances where the above conditions are not "
+"met,\n"
+"please contact the component lead and/or an I2P release manager with "
+"further\n"
+"information.\n"
+"See developers' license agreements."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/release-signing-key.html:2
+msgid "Release Signing Key"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/release-signing-key.html:4
+msgid "Releases 0.7.6 and later are signed by zzz. His public key is:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/release-signing-key.html:40
+msgid ""
+"Releases 0.6.1.31 through 0.7.5 were signed by Complication. His public "
+"key is:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:2
+msgid "Signed Developer Keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:4
+msgid ""
+"Keys for zzz, Complication and welterde are provided clearsigned. The key"
+" for jrandom must be\n"
+"verified differently, since he's away, and only left a binary detached\n"
+"signature for his key."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:10
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:16
+msgid "Monotone keys for zzz"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:11
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:47
+msgid "Monotone keys for welterde"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:12
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:79
+msgid "Monotone keys for Complication"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:13
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:114
+msgid "Monotone keys for jrandom"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:17
+msgid ""
+"Tip: To find zzz's GPG key, on his eepsite locate the key "
+"`0xA76E0BED`, with\n"
+"the name `zzz@mail.i2p` and the fingerprint `4456 EBBE C805 63FE 57E6 "
+"B310 4155\n"
+"76BA A76E 0BED`."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:49
+msgid ""
+"Tip: To find welterde's GPG key, on public keyservers locate the "
+"key\n"
+"`0x62E011A1`, with the name `welterde@arcor.de` and the fingerprint `6720"
+" FD81\n"
+"3872 6DFC 6016 64D1 EBBC 0374 62E0 11A1`."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:81
+msgid ""
+"Tip: To find Complication's GPG key, on his eepsite locate the key"
+"\n"
+"`0x79FCCE33`, with the name `complication@mail.i2p` and the fingerprint "
+"`73CF\n"
+"2862 87A7 E7D2 19FF DB66 FA1D FC6B 79FC CE33`."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:116
+msgid ""
+"Tip: To find jrandom's GPG key for Syndie releases, on public "
+"keyservers locate\n"
+"the key `0x393F2DF9`, with the name `syndie-dist-key@i2p.net` and the\n"
+"fingerprint `AE89 D080 0E85 72F0 B777 B2ED C2FA 68C0 393F 2DF9`."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:122
+msgid ""
+"Jrandom had to leave unexpectedly in the end of 2007. His commit key was\n"
+"deployed in the Syndie Monotone repository, in a file named `mtn-"
+"committers`.\n"
+"That file also had a GPG signature, `mtn-committers.sig`, but it was a "
+"binary\n"
+"detached signature. I am going to supply both files in GPG ASCII-armoured"
+" form\n"
+"below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:130
+msgid ""
+"First, the file `mtn-committers` containing jrandom's Monotone key. Save "
+"as\n"
+"`mtn-committers.asc` and unpack it using `gpg --output mtn-committers "
+"--dearmor\n"
+"mtn-committers.asc`:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:151
+msgid ""
+"Now the file `mtn-committers.sig`, containing the GPG signature. Save as\n"
+"`mtn-committers.sig.asc` and unpack it using `gpg --output mtn-"
+"committers.sig\n"
+"--dearmor mtn-committers.sig.asc`. Use it to verify the above supplied\n"
+"`mtn-committers` file:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/develop/signed-keys.html:170
+#, python-format
+msgid ""
+"Some of the developers have included their Monotone keys in their signed license agreement."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:2
+msgid "Developer Guidelines and Coding Style"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:4
+#, python-format
+msgid "Read the new developers guide first."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:8
+msgid "Basic Guidelines and Coding Style"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:10
+msgid ""
+"Most of the following should be common sense for anybody who has worked "
+"on open source or in a commercial\n"
+"programming envrionment.\n"
+"The following applies mostly to the main development branch i2p.i2p.\n"
+"Guidelines for other branches, plugins, and external apps may be "
+"substantially different;\n"
+"check with the appropriate developer for guidance."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:18
+msgid "Community"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:20
+msgid ""
+"Please don't just \"write code\". If you can, participate in other "
+"development activities, including:\n"
+"development discussions and support on IRC, zzz.i2p, and forum.i2p; "
+"testing;\n"
+"bug reporting and responses; documentation; code reviews; etc."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:25
+msgid ""
+"Active devs should be available periodically on IRC #i2p-dev.\n"
+"Be aware of the current release cycle.\n"
+"Adhere to release milestones such as feature freeze, tag freeze, and\n"
+"the checkin deadline for a release."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:35
+msgid ""
+"Have a basic understanding of distributed source control systems, even if"
+" you haven't\n"
+"used monotone before. Ask for help if you need it.\n"
+"Once pushed, checkins are forever, there is no undo. Please be careful.\n"
+"If you have not used monotone before, start with baby steps.\n"
+"Check in some small changes and see how it goes."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:42
+msgid ""
+"Test your changes before checking them in.\n"
+"If you prefer the checkin-before-test development model,\n"
+"use your own development branch (e.g. i2p.i2p.yourname.test)\n"
+"and propagate back to i2p.i2p once it is working well.\n"
+"Do not break the build. Do not cause regressions.\n"
+"In case you do (it happens), please do not vanish for a long period after"
+"\n"
+"you push your change."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:51
+msgid ""
+"If your change is non-trivial, or you want people to test it and need "
+"good test reports\n"
+"to know whether your change was tested or not, add a checkin comment to "
+"history.txt\n"
+"and increment the build revision in RouterVersion.java."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:56
+msgid ""
+"Ensure that you have the latest monotonerc file in _MTN.\n"
+"Do not check in on top of untrusted revisions."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:60
+msgid ""
+"Ensure that you pull the latest revision before you check in.\n"
+"If you inadvertently diverge, merge and push as soon as possible.\n"
+"Don't routinely make others merge for you.\n"
+"Yes, we know that monotone says you should push and then merge,\n"
+"but in our experience, in-workspace merge works just as well as in-"
+"database merge,\n"
+"without creating a merge revision."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:68
+msgid ""
+"Do not check in major changes into the main i2p.i2p branch late in the "
+"release cycle.\n"
+"If a project will take you more than a couple days, create your own "
+"branch in monotone\n"
+"and do the development there so you do not block releases."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:75
+msgid "Coding Style"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:77
+msgid ""
+"Coding style throughout most of the code is 4-spaces for indentation. Do "
+"not use tabs.\n"
+"Do not reformat code. If your IDE or editor wants to reformat everything,"
+" get control of it.\n"
+"Yes, we know 4 spaces is a pain, but perhaps you can configure your "
+"editor appropriately.\n"
+"In some places, the coding style is different.\n"
+"Use common sense. Emulate the style in the file you are modifying."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:84
+msgid ""
+"New classes and methods require at least brief javadocs. Add @since "
+"release-number."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:87
+msgid ""
+"Classes in core/ (i2p.jar) and portions of i2ptunnel are part of our "
+"official API.\n"
+"There are several out-of-tree plugins and other applications that rely on"
+" this API.\n"
+"Be careful not to make any changes that break compatibility.\n"
+"Don't add methods to the API unless they are of general utility.\n"
+"Javadocs for API methods should be clear and complete.\n"
+"If you add or change the API, also update the documentation on the "
+"website (i2p.www branch)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:95
+msgid ""
+"Tag strings for translation where appropriate.\n"
+"Don't change existing tagged strings unless really necessary, as it will "
+"break existing translations.\n"
+"Do not add or change tagged strings after the \"tag freeze\" in the "
+"release cycle so that\n"
+"translators have a chance to update before the release."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:101
+msgid ""
+"Use generics and concurrent classes where possible. I2P is a highly "
+"multi-threaded application."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:104
+msgid ""
+"We require Java 6 to build but only Java 5 to run I2P.\n"
+"Do not use Java 6 classes or methods without handling the class not found"
+" exceptions\n"
+"and providing alternate Java 5 code. See classes in net.i2p.util for "
+"examples."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:109
+msgid ""
+"Explicitly convert between primitive types and classes;\n"
+"don't rely on autoboxing/unboxing."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:117
+msgid ""
+"Only check in code that you wrote yourself.\n"
+"Before checking in any code or library jars from other sources,\n"
+"justify why it is necessary,\n"
+"verify the license is compatible,\n"
+"and obtain approval from the lead developer."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:124
+msgid ""
+"For any images checked in from external sources,\n"
+"it is your responsibility to first verify the license is compatible.\n"
+"Include the license and source information in the checkin comment."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:131
+msgid "Bugs"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:133
+#, python-format
+msgid ""
+"Managing Trac tickets is everybody's job, please help.\n"
+"Monitor %(trac)s for tickets you have been assigned or can help with.\n"
+"Assign, categorize, comment on, fix, or close tickets if you can."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/dev-guidelines.html:138
+msgid ""
+"Close a ticket when you think you've fixed it.\n"
+"We don't have a test department to verify and close tickets.\n"
+"If you arent sure you fixed it, close it and add a note saying\n"
+"\"I think I fixed it, please test and reopen if it's still broken\".\n"
+"Add a comment with the dev build number or revision and set\n"
+"the milestone to the next release."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:4
+msgid ""
+"The main I2P development branch (i2p.i2p) has been set up to"
+" enable developers to easily set up two of the commonly-used IDEs for "
+"Java development: Eclipse and NetBeans."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:10
+msgid ""
+"The main I2P development branches (i2p.i2p and branches from"
+" it) contain .project and .classpath Eclipse files, to enable the branch "
+"to be easily set up in Eclipse."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:16
+msgid ""
+"Check out the I2P branch into some directory (e.g. "
+"$HOME/dev/i2p.i2p)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:20
+msgid ""
+"Open Eclipse and create a new Workspace, based in the directory that the "
+"I2P branch was checked out to."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:24
+msgid ""
+"Select \"File - Import...\" and then under \"General\" select \"Existing "
+"Projects into Workspace\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:28
+msgid ""
+"For \"Select root directory:\" choose the directory that the I2P branch "
+"was checked out to."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:32
+msgid "If necessary, click \"Refresh\" to refresh the list of projects."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:36
+msgid "Select every project in the list, and click \"Finish\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:40
+msgid ""
+"Done! Your workspace should now contain all projects within the I2P "
+"branch, and their build dependencies should be correctly set up."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/ides.html:48
+msgid ""
+"The main I2P development branches (i2p.i2p and branches from"
+" it) contain NetBeans project files."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:9
+msgid "Operating a Monotone client"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:11
+#: i2p2www/pages/site/get-involved/guides/monotone.html:63
+msgid "Generating Monotone keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:12
+msgid "Trust and initializing your repository"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:13
+#: i2p2www/pages/site/get-involved/guides/monotone.html:196
+msgid "Obtaining and deploying developers' keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:14
+#: i2p2www/pages/site/get-involved/guides/monotone.html:227
+msgid "Setting up trust evaluation hooks"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:15
+#: i2p2www/pages/site/get-involved/guides/monotone.html:268
+msgid ""
+"Pulling the i2p.i2p, i2p.www and "
+"i2p.syndie branches"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:16
+#: i2p2www/pages/site/get-involved/guides/monotone.html:308
+msgid "Verifying that trust evaluation works"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:17
+#: i2p2www/pages/site/get-involved/guides/monotone.html:357
+msgid "Checking out a working copy of the latest version"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:18
+#: i2p2www/pages/site/get-involved/guides/monotone.html:384
+msgid "Updating your working copy to the latest version"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:22
+#: i2p2www/pages/site/get-involved/guides/monotone.html:414
+msgid "Operating a Monotone Server"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:24
+msgid "Obtaining and deploying developers’ transport keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:25
+#: i2p2www/pages/site/get-involved/guides/monotone.html:424
+msgid "Granting push and pull access"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:26
+#: i2p2www/pages/site/get-involved/guides/monotone.html:469
+msgid "Running Monotone in server mode"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:27
+#: i2p2www/pages/site/get-involved/guides/monotone.html:494
+msgid "Differences under Debian GNU/Linux"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:34
+#, python-format
+msgid ""
+"This is a revised version of Complication's original\n"
+"  guide detailing the use of Monotone in I2P development.\n"
+"  For basic instructions see the quick-start "
+"guide."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:42
+#, python-format
+msgid ""
+"I2P has a distributed development model. The source code is replicated "
+"across\n"
+"  independently administered Monotone (\"MTN\") repositories.\n"
+"  Developers with commit rights are able to push their changes to the "
+"repository\n"
+"  (a license agreement needs to be "
+"signed\n"
+"  before commit rights are granted)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:52
+msgid ""
+"Some of Monotone's noteworthy qualities are: distributed\n"
+"  version control, cryptographic authentication, access control, its "
+"small size, having few\n"
+"  dependencies, storage of projects in a compressed SQLite database file,"
+" and\n"
+"  having the ability to resume interrupted synchronization attempts."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:61
+msgid "Operating a Monotone Client"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:66
+msgid ""
+"A transport key grants you the ability to push your changes to a Monotone"
+" repository server.\n"
+"  In order to commit code into Monotone (in essence signing your code), a"
+" commit key is also needed.\n"
+"  None of the public Monotone servers on I2P currently require a key in "
+"order to read (or pull) the source code."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:74
+msgid ""
+"Without a transport key, one cannot:\n"
+"  
              \n"
+"    
            • pull code from a server which doesn't allow global read "
+"access
              • \n"
+"    
            • push code to any server
              • \n"
+"    
            • run a Monotone server
              • \n"
+"  
            "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:85
+msgid ""
+"Without a commit key, one cannot:\n"
+"  
              \n"
+"    
            • commit any code
              • \n"
+"  
            "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:94
+msgid ""
+"If you only intend to retrieve code from MTN, feel free to skip to the\n"
+"  next section. "
+"If you want\n"
+"  to generate keys, read the following."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:102
+msgid ""
+"By convention keys are named like an e-mail addresses, but a "
+"corresponding e-mail\n"
+"  address does not need to exist. For example, your keys might be named:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:113
+msgid ""
+"Monotone stores keys under $HOME/.monotone/keys in "
+"text files which\n"
+"  are named identically to the keys. For example:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:123
+msgid ""
+"To generate transport and commit keys, enter the following commands at a "
+"prompt:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:133
+msgid ""
+"Monotone will prompt you for a password to protect your keys. You are "
+"very strongly encouraged to set a password\n"
+"  for the commit key. Many users will leave an empty password for the "
+"transport key, especially those running a\n"
+"  Monotone server."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:141
+msgid "Trust, and initializing your repository"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:145
+msgid ""
+"Monotone's security model helps to ensure that nobody can easily "
+"impersonate a developer without\n"
+"  it being noticed. Since developers can make mistakes and become "
+"compromised,only manual review can\n"
+"  ensure quality of code. Monotone's trust model will ensure that you "
+"read the right diffs. It does\n"
+"  not replace reading diffs."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:155
+msgid ""
+"A Monotone repository is a single file (a compressed SQLite database) "
+"which contains all of the project's source code and history."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:161
+msgid ""
+"After importing the "
+"developers' keys into Monotone and\n"
+"  setting up trust "
+"evaluation hooks,\n"
+"  Monotone will prevent untrusted code from being checked out into your "
+"workspace.\n"
+"  There are commands available to clean untrusted code from your "
+"workspace but in practice they've not been\n"
+"  needed due to the push access policies in place."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:171
+msgid ""
+"A repository can hold many branches. For example, our repository holds "
+"the\n"
+"  following main branches:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:176
+msgid "The I2P router and associated programs"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:177
+msgid "The I2P project website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:178
+msgid "Syndie, a distributed forums tool"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:183
+msgid ""
+"By convention, the I2P Monotone repository is named i2p.mtn."
+" Before pulling\n"
+"  source code from servers, a database for your repository will need to "
+"be initialized.\n"
+"  To initialize your local repository, change into the directory that you"
+" want the\n"
+"  i2p.mtn file and branch directories to be stored and issue"
+" the following\n"
+"  command:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:199
+msgid ""
+"Keys which developers use to commit code are essential for trust "
+"evaluation in\n"
+"  Monotone. The other developers' transport keys are only required for "
+"Monotone server operators.\n"
+"  "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:206
+#, python-format
+msgid ""
+"Developers' commit keys are provided GPG-signed on another page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:212
+#, python-format
+msgid ""
+"To import developers' keys after verifying their authenticity, copy all of the keys into a new\n"
+"  file. Create this file (e.g. keys.txt) in the same "
+"directory where i2p.mtn is located. Import the keys with the"
+" command:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:222
+msgid ""
+"Note: Never add keys to "
+"$HOME/.monotone/keys manually."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:230
+msgid ""
+"The default Monotone trust policy is way too lax for our requirements: "
+"every comitter is trusted by default.\n"
+"  That is not acceptable for I2P development."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:237
+msgid ""
+"Change into the directory $HOME/.monotone and open "
+"the file\n"
+"  monotonerc with a text editor. Copy and paste the "
+"following two functions into this file:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:246
+msgid ""
+"The first function determines an intersection between two sets, in our "
+"case a\n"
+"  revision's signers and trusted signers."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:253
+msgid ""
+"The second function determines trust in a given revision, by calling the "
+"first\n"
+"  function with \"signers\" and \"trusted\" as arguments. If the "
+"intersection is\n"
+"  null, the revision is not trusted. If the intersection is not empty, "
+"the\n"
+"  revision is trusted. Otherwise, the revision is not trusted."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:262
+msgid ""
+"More information about Trust Evauluation Hooks can be found in the official Monotone "
+"documentation."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:271
+msgid ""
+"Enter the directory where you initialized i2p.mtn. Depending "
+"on whether you\n"
+"  want only I2P sources, or also sources for the I2P website and Syndie, "
+"you can\n"
+"  perform the pull operation in different ways."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:279
+msgid "If you only want I2P sources:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:288
+msgid "If you want all branches:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:294
+msgid ""
+"If the transfer aborts before completing sucessfully, simply repeating "
+"the pull command will resume the transfer."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:300
+msgid ""
+"Pulling in the above examples is done anonymously by specifying an empty "
+"transport key.\n"
+"  If everyone pulls anonymously it will be harder for an attacker who "
+"gains control of the server\n"
+"  to selectively provide some people with tampered data."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:311
+msgid "To verify that trust evaluation works:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:315
+msgid "Make a backup of your monotonerc file."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:316
+msgid ""
+"Modify monotonerc by setting the trusted_signers "
+"variable in the following way:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:322
+msgid ""
+"With monotonerc configured as above, Monotone will no"
+" longer trust any committers. Confirm this by changing into the\n"
+"directory where i2p.mtn was created and attempt a checkout "
+"of the I2P branch:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:332
+msgid ""
+"A directory named i2p.i2p should not appear. You "
+"should encounter many\n"
+"  error messages like:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:349
+msgid ""
+"If you are satisfied with results, restore the backup of\n"
+"  monotonerc that was created above. If you didn't create a "
+"backup\n"
+"  as advised, re-read Setting up trust evaluation hools."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:360
+msgid ""
+"If you already have a branch checked out, skip to the next\n"
+"  section."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:367
+msgid ""
+"Change into the directory where i2p.mtn is located. Over "
+"there issue:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:376
+msgid ""
+"The checkout should complete without error messages and a directory named"
+"\n"
+"  i2p.i2p should appear in the current directory. "
+"Congratulations! You have\n"
+"  successfully checked out the latest I2P sources, ready to be compiled."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:387
+msgid ""
+"If you haven't done this already, pull fresh code from the server to your"
+" local\n"
+"  Monotone repository. To accomplish this, change into the directory "
+"where\n"
+"  i2p.mtn is located and issue:\n"
+"  
              \n"
+"    
            • $ mtn --db=\"i2p.mtn\" -k \"\" pull 127.0.0.1:8998 "
+"i2p.i2p
              • \n"
+"  
            "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:398
+msgid "Now change into your i2p.i2p directory, and over there issue:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:407
+msgid ""
+"As long as there were no errors…Congratulations! You have "
+"successfully updated to the latest I2P sources. They\n"
+"  should be ready to compile."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:416
+msgid "Obtaining and deploying developers' transport keys"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:419
+msgid ""
+"As a server operator you may want to grant push access to certain "
+"developers."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:427
+msgid "By default the Monotone server denies all access."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:433
+msgid "To grant pull access to all clients, set the following in"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:445
+msgid ""
+"No one will not be able to push code to your server without permission "
+"being explicitly granted. To grant push access:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:451
+msgid ""
+"Add the name of the user's transport key to\n"
+"$HOME/.monotone/write-permissions, such as\n"
+"
            \n"
+"    zzz-transport@mail.i2p\n"
+"    complication-transport@mail.i2p\n"
+"
            \n"
+"with one key per line."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:462
+msgid ""
+"Import the transport key(s) into your database. The procedure for "
+"importing transport keys is the same as for\n"
+"importing commit keys, which is described in the section Obtaining and deploying "
+"developers' keys."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:472
+msgid ""
+"A separate database should be used for your Monotone server because "
+"monotone will lock the database while it is served to others.\n"
+"  Make a copy of your development database, then start the server with:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:479
+msgid ""
+"If your key is protected with a passphrase, Monotone may request the "
+"passphrase\n"
+"  when the first client connects. You can work around this by connecting "
+"making the first client connection to your server\n"
+"  (or by clearing the password for your transport key)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:487
+msgid ""
+"For your server to be accessible for others over I2P, you will need to "
+"create a\n"
+"  server tunnel for it. Use the \"Standard\" tunnel type and \"Bulk\" "
+"profile."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:497
+msgid ""
+"Debian (amongst other distributions) has integrated Monotone into their\n"
+"  framework of daemons/services. Although Monotone servers can still be "
+"run\n"
+"  \"the ordinary way\" on Debian systems, doing it the \"Debian way\" may"
+" be more straightforward."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/monotone.html:505
+msgid ""
+"Permissions are granted by editing the files\n"
+"  /etc/monotone/read-permissions and\n"
+"  /etc/monotone/write-permissions. You'll also need to edit\n"
+"  /etc/default/monotone to enable monotone to start at boot "
+"or to\n"
+"  customize the host, port, or database location."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:4
+msgid ""
+"\n"
+"So you want to start work on I2P? Great!\n"
+"Here's a quick guide to getting started\n"
+"on contributing to the website or the software, doing development or "
+"creating translations."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:9
+#, python-format
+msgid ""
+"\n"
+"Not quite ready for coding?\n"
+"Try getting involved first."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:16
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:27
+msgid "Basic study"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:17
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:41
+msgid "Getting the I2P code"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:18
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:112
+msgid "Building I2P"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:19
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:133
+msgid "Development ideas"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:20
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:141
+msgid "Making the results available"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:21
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:162
+msgid "Get to know us!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:22
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:168
+msgid "Translations"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:23
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:174
+msgid "Tools"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:29
+msgid ""
+"Basic development on the I2P router or the embedded applications uses "
+"Java as the main development language.\n"
+"If you don't have experience with Java, you can always have a look at Thinking in Java."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:33
+#, python-format
+msgid ""
+"Study the how intro,\n"
+"the other \"how\" documents,\n"
+"the tech intro,\n"
+"and associated documents.\n"
+"These will give you a good overview of how I2P is structured and what "
+"different things it does."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:43
+msgid ""
+"For development on the i2p router or the embedded applications,\n"
+"get the monotone source repository installed - short instructions:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:48
+msgid ""
+"Install monotone.\n"
+"Monotone is a version control system.\n"
+"We use it because it allows us to keep track of who does what changes to "
+"the source code (and for a lot of complicated things, but 'keeping track "
+"of changes' is the basic idea)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:53
+msgid ""
+"Skim over the monotone tutorial,"
+" to make sure you understand the concepts."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:57
+msgid ""
+"If you want to remain anonymous, you need to do an additional step, to "
+"set up a connection to a monotone server over I2P:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:60
+#, python-format
+msgid ""
+"Enable the i2ptunnel client tunnel on port "
+"8998 pointing to mtn.i2p2.i2p."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:64
+msgid ""
+"Pick a directory where you want to put all your I2P files, and create a "
+"monotone database:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:67
+msgid ""
+"Define the trust list by creating ~/.monotone/monotonerc (or"
+" _MTN/monotonerc in the i2p.i2p workspace) with the "
+"following contents:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:72
+#, python-format
+msgid ""
+"Copy and paste the developer's commit keys "
+"into a new file (e.g. keys.txt) in the same directory\n"
+"  that i2p.mtn is in. Import the keys into your database "
+"with 
                  mtn -d i2p.mtn read < keys.txt
            "
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:76
+msgid ""
+"Pull the I2P sources to your machine. This may take a long time, "
+"especially if you are doing this over I2P!"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:78
+msgid "Anonymously:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:81
+msgid "Non-anonymously:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:83
+msgid ""
+"Alternatively, instead of 'mtn.i2p2.de', you can also download from mtn"
+".i2p-projekt.de."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:90
+msgid ""
+"All the sources are now present on your machine, in the database file. To"
+" make them available in a directory, you need to check them out:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:92
+msgid ""
+"The above command creates a directory i2p.i2p, which contains all of the "
+"I2P sources."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:96
+msgid "Remarks"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:97
+msgid ""
+"\n"
+"To download the website files instead of the I2P source files, use "
+"'i2p.www' instead of 'i2p.i2p'."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:100
+msgid ""
+"The initial pull may take several hours using the tunnel.\n"
+"If it fails after a partial pull, simply rerun it, it will start where it"
+" left off.\n"
+"If you are in a hurry, use the non-anonymous access."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:105
+#, python-format
+msgid ""
+"A full list of branches, including i2p.i2p and i2p.www can be found on viewmtn."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:108
+#, python-format
+msgid ""
+"A long explanation about using monotone is available on the monotone page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:114
+#, python-format
+msgid ""
+"To compile the code, you need the Sun Java Development Kit 6 or higher, "
+"or equivalent JDK\n"
+"(Sun JDK 6 strongly recommended) and\n"
+"Apache ant\n"
+"version 1.7.0 or higher.\n"
+"If you go are working on the main I2P code, you can go into the i2p.i2p "
+"directory and run 'ant' to see the build options."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:122
+msgid ""
+"To build or work on console translations, you need\n"
+"the xgettext, msgfmt, and msgmerge tools from the\n"
+"GNU gettext package."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:128
+#, python-format
+msgid ""
+"For development on new applications,\n"
+"see the application development guide."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:134
+#, python-format
+msgid ""
+"See zzz's TODO lists,\n"
+"this website's TODO list or\n"
+"Trac\n"
+"for ideas."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:143
+#, python-format
+msgid ""
+"See the bottom of the licenses page "
+"for\n"
+"commit privilege requirements. You need these to put code into i2p.i2p "
+"(not required for the website!)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:148
+msgid "Short version of how to generate and use keys if you plan to commit:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:150
+msgid "use an empty passphrase"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:151
+msgid "enter a passphrase"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:152
+#, python-format
+msgid ""
+"send this to a mtn repo operator to get "
+"push privileges"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:153
+#, python-format
+msgid ""
+"send this to a release manager to get "
+"commit privileges - not required for website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:154
+msgid "check in with this key"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:155
+msgid "push with this key"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:157
+#, python-format
+msgid "Long version: see the monotone page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:163
+#, python-format
+msgid ""
+"The developers hang around on IRC. They can be reached on the Freenode "
+"network, OFTC, and on the I2P internal networks. The usual place to look "
+"is #i2p-dev. Join the channel and say hi!\n"
+"We also have additional guidelines for regular"
+" developers."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:169
+#, python-format
+msgid ""
+"Website and router console translators: See the New Translator's Guide\n"
+"for next steps."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:175
+msgid ""
+"I2P is open source software that is mostly developed using open sourced\n"
+"toolkits. The I2P project recently acquired a license for the YourKit "
+"Java\n"
+"Profiler. Open source projects are eligible to receive a free license "
+"provided\n"
+"that YourKit is referenced on the project web site. Please get in touch "
+"if you\n"
+"are interested in profiling the I2P codebase."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-developers.html:183
+#, python-format
+msgid ""
+"YourKit is kindly supporting open source projects with its full-featured "
+"Java Profiler.\n"
+"YourKit, LLC is the creator of innovative and intelligent tools for "
+"profiling\n"
+"Java and .NET applications. Take a look at YourKit's leading software "
+"products:\n"
+"YourKit Java Profiler and\n"
+"YourKit .NET Profiler."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:4
+msgid "Here's a very quick guide to getting started."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:6
+msgid "How to Translate the Website"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:8
+#, python-format
+msgid ""
+"Translation of the website is done with .po files. The easiest way by far"
+" to\n"
+"translate the website is to sign up for an account at \n"
+"Transifex and request to join a translation"
+" team. \n"
+"Alternatively it can be done \"the old way\" as outlined below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:17
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:82
+msgid "Preparation"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:19
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:84
+#, python-format
+msgid ""
+"Come to #i2p-dev on irc and talk to people.\n"
+"Claim the language -\n"
+"To make sure other coworkers don't bump onto the files you are working "
+"on,\n"
+"please update the translation status on this wiki "
+"page."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:25
+#, python-format
+msgid ""
+"Follow the new developer's guide,\n"
+"Including the installation of monotone,\n"
+"checking out i2p.www branch, and generate your own monotone keys.\n"
+"It is not required that you sign a dev agreement."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:33
+msgid ""
+"Create files:\n"
+"If the file for your language does not exist yet:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:38
+msgid ""
+"Run \"./extract-messages.sh\" to generate a "
+"messages.pot in the base directory.\n"
+"Edit the header of this file, then run \"./init-new-po.sh "
+"locale\" to generate the file\n"
+"i2p2www/translations/locale/LC_MESSAGES/messages.po. "
+"\"mtn add\" this file."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:43
+msgid ""
+"Edit i2p2www/pages/global/lang.html and add a line for your "
+"language (copy an existing line)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:46
+msgid ""
+"Add a flag image file to i2p2www/static/images/flags/ for "
+"the menu (copy from the router)."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:52
+msgid ""
+"Edit files:\n"
+"Edit i2p2www/translations/locale/LC_MESSAGES/messages.po.\n"
+"To work with .po files efficiently, you may wish to use POEdit"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:58
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:151
+msgid ""
+"Check in:\n"
+"\"mtn pull\", \"mtn update\". Then check in by "
+"\"mtn ci -k yourname@mail.i2p file1 file2 ...\"\n"
+"This collects the diff info of your changed file into your local repo. "
+"Then \"mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p "
+"i2p.i2p\".\n"
+"This synchronizes your local repo with the repo on the target machine."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:65
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:158
+msgid "Repeat. Check in often. Don't wait until it is perfect."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:72
+msgid "How to Translate the Router Console"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:74
+#, python-format
+msgid ""
+"The easiest way by far to translate the router console is to sign up for "
+"an account at \n"
+"Transifex and request to join a translation"
+" team. \n"
+"Alternatively it can be done \"the old way\" as outlined below."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:90
+#, python-format
+msgid ""
+"Follow the new developer's guide,\n"
+"including the installation of monotone and the gettext tools,\n"
+"checking out i2p.i2p branch, and generate your own monotone keys."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:95
+msgid "Generate your own gpg key and sign the dev agreement."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:101
+msgid ""
+"Before starting a console translation, better help translate some i2p "
+"webpages first.\n"
+"At least an i2p homepage in your language would be great."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:106
+msgid ""
+"What to translate:\n"
+"There are about 15 files in the i2p.i2p branch that needs translation:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:132
+msgid ""
+"Where xx is your language code like fr/de/ch/zh/...\n"
+"There may be or may not be files with your lang code. If not, you can "
+"create your own. by copying and renaming other language files you know "
+"with your own lang code."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:137
+msgid ""
+"Create files:\n"
+"If the file for your language does not exist yet, copy another language "
+"file to a new file foo_xx.bar for your language.\n"
+"Then \"mtn add\" the file.\n"
+"After creating a .po file, edit the headers. Then run \"ant "
+"distclean poupdate\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:144
+msgid ""
+"Start to work:\n"
+"Edit the HTML files with any text editor.\n"
+"Be sure not to use an editor in HTML mode that reformats everything.\n"
+"To work with .po files efficiently, you may wish to use POEdit"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:163
+msgid ""
+"As you can see, it's not that difficult.\n"
+"If you have questions about the meaning of the terms in the console, ask "
+"in #i2p-dev on IRC."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:171
+msgid ""
+"Q: Why do I have to install monotone, Java, jsp, learn about .po files "
+"and html, etc.? Why can't I just do a translation and email it to you?"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:175
+msgid "A: Several reasons:"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:178
+#, python-format
+msgid ""
+"You might be interested in translating via Transifex. Request to join a "
+"translation team here."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:182
+msgid ""
+"We don't have anybody who has time to accept manual contributions and "
+"submit them to our source control system on your behalf. Even if we did, "
+"it doesn't scale."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:186
+msgid ""
+"Maybe you are thinking translation is a one-step process. It isn't. You "
+"can't do it all at once. You will make mistakes. You need to test it and "
+"tweak it to make it look right before you submit it. Developers "
+"will update or add to the English text, thus requiring a translation "
+"update."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:190
+msgid ""
+"Having translators use a source control system directly provides "
+"authentication and accountablility - we know who is doing what, and we "
+"can track changes, and revert them if necessary."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:194
+msgid ""
+".po files are not difficult. If you don't want to work directly with "
+"them, we recommend 'poedit'."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:198
+msgid ""
+"HTML files are not difficult. Just ignore the html stuff and translate "
+"the text."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:202
+msgid ""
+"Installing and using monotone is not that difficult. Several of the "
+"translators and other contributors to I2P are non-programmers, and they "
+"use monotone regularly. Monotone is simply a source control system, it is"
+" not about \"coding\"."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:206
+msgid ""
+"Our items to translate are not \"documents\". They are html files and po "
+"files, with a specific format and character encoding (UTF-8) that must be"
+" maintained, and not corrupted by email programs or other methods of "
+"transfer."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:210
+msgid ""
+"We looked at 'pootle' as a front-end for translators. It didn't work "
+"well, needed an administrator, and a pootle-based process would suffer "
+"from a number of the above flaws."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:215
+msgid ""
+"In summary:\n"
+"Yes, we know it is somewhat of a hurdle to get started. It's really the "
+"only possible way we can do it. Give it a try, it really isn't that hard."
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:220
+msgid "More Information"
+msgstr ""
+
+#: i2p2www/pages/site/get-involved/guides/new-translators.html:221
+#, python-format
+msgid ""
+"The #i2p-dev channel on IRC, or the translation forum on %(zzz)s."
+msgstr ""
+
+#: i2p2www/pages/site/misc/clt.html:2
+msgid "I2P at CLT and PetCon 2009.1"
+msgstr ""
+
+#: i2p2www/pages/site/misc/clt.html:4
+msgid ""
+"Members of I2P will held a talk at CLT and PetCon 2009.1\n"
+"Two members of the I2P team will be at two forthcoming Linux day and "
+"security convention."
+msgstr ""
+
+#: i2p2www/pages/site/misc/clt.html:9
+#, python-format
+msgid ""
+"On 14th march of 2009 there will be a short talk about general "
+"introduction to I2P at the Chemnitz Linux Tag "
+"2009 hold by echelon.\n"
+"Echelon and some other members of the I2P family will attend to the Linux"
+" meeting the whole two days (Saturday and Sunday) and will be "
+"recognizable as I2P family members. Meet them, ask them your questions, "
+"show them your props! Show your support!"
+msgstr ""
+
+#: i2p2www/pages/site/misc/clt.html:14
+#, python-format
+msgid ""
+"Just 10 days later the Privacy and Data Security "
+"convention in Dresden will take place.\n"
+"Again, echelon will attend this event and hold a short talk about general"
+" introduction to I2P. Another talk about the profiling by the I2P clients"
+" will be held."
+msgstr ""
+
+#: i2p2www/pages/site/misc/cvs.html:4
+#, python-format
+msgid ""
+"The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in a"
+" Monotone repository.\n"
+"For those who aren't very familiar with CVS, there is a\n"
+"fantastic book "
+"on the\n"
+"subject (developers only need to deal with the first chapter - \"An "
+"Overview of\n"
+"CVS\", as subsequent chapters go into some nasty details very few ever "
+"need to\n"
+"touch)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/cvs.html:31
+msgid ""
+"Humorous quote from WinCVS: \"Did you know...  Never experiment with new "
+"CVS\n"
+"commands on your working repository.  Create a sample module instead.\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:2
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:4
+msgid "I2PTunnel migration"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:6
+msgid ""
+"After upgrading to the new architecture, you'll have to do a \n"
+"little work to get your old I2PTunnel-driven servers running.  \n"
+"Lets walk through a simple example.  For an eepsite with the \n"
+"old clientApp configuration, you had:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:16
+msgid "To provide that same functionality on the new web architecture:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:18
+#, python-format
+msgid "Jump to %(url)s"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:19
+msgid "Click on Add new: [Server tunnel] \"GO\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:21
+msgid "For the name: \"eepsite\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:22
+msgid "For the description: \"My eepsite, isn't it pretty?\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:23
+msgid ">For the target host:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:24
+msgid "For the target port:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:25
+msgid ""
+"For the private key file: path to \"myWebPriv.dat\"
             \n"
+"(it is recommended to copy that .dat to your new install dir)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:29
+msgid "Check the \"Start automatically?\" checkbox"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:30
+msgid "Click \"Save\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:32
+msgid "It will come back saying:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:39
+msgid ""
+"That's it!  Creating a new I2PTunnel server works the same way too, "
+"except you\n"
+"don't need to \"copy the old file\", obviously.  Behind the scenes, it is"
+" all driven\n"
+"by the i2ptunnel.config file, which you may modify "
+"externally (if you do,\n"
+"hit \"Reload config\" on the I2PTunnel web page, which will tear down all"
+" of your \n"
+"existing tunnels and rebuild new ones)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-migration.html:47
+msgid ""
+"Note that you WILL need to wait until your router is integrated\n"
+"into the network before you are able to use the /i2ptunnel/ web\n"
+"interface.  It will say \"Please be patient\" if you try to \n"
+"beforehand, which means that it is still trying to build the \n"
+"necessary I2PTunnel sessions it has been configured to create."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:2
+msgid "I2PTunnel services"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:4
+msgid "Below is quick copy of aum's eepsite deployment guide."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:8
+msgid "1. - Deploy a local server"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:10
+msgid ""
+"For simplicity's sake, we will walk through the setup of a web server; "
+"however, this procedure is the same regardless what protocol of servers "
+"and/or clients you are setting up."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:13
+msgid ""
+"I recommend the Tiny Httpd web server, thttpd, (windows version available"
+" on site) although you can use anything that you feel comfortable with."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:16
+msgid ""
+"Another more robust option would be to use EasyPHP, which is also open "
+"source. It comes with PHP, PHPmyadmin, mySQL, and Apache web server. For "
+"newbies who have no experience setting up and hosting content over "
+"servers, see the hosting page for help."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:19
+msgid ""
+"With the web server you've chosen, configure it to listen on a port of "
+"your choice, and serve its documents from a directory of your choice. For"
+" this example, we'll assume port 10880."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:22
+msgid ""
+"Make sure your firewall is set up so that you cannot receive incoming "
+"connections on this port (which would breach your anonymity)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:25
+msgid ""
+"Test the webserver, by pointing your normal browser (the one with the "
+"\"direct connection\") at http://localhost:10880 (changing the 10880 to the "
+"port number you have chosen)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:28
+msgid ""
+"Once your webserver is working, and you can access it locally with your "
+"browser, continue to the next step."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:33
+msgid "2 - Generate an I2P Destination Keypair"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:35
+msgid ""
+"I2P does not deal in IP addresses. To protect your anonymity, it deals in"
+" unique addresses called destination keys."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:38
+msgid ""
+"A destination key works a lot like a regular IP address, except that it "
+"can't be traced to your IP address or physical location. When users place"
+" a request to speak with you, your gateways are the ones that answer for "
+"you. So the requesting user can only know the IP address of your "
+"gateways. However, gateways don't know your IP address, because gateways "
+"are the last nodes on your tunnels, and you anonymously create tunnels by"
+" way of garlic routing. (So gateways are like puppets that can't see "
+"their masters, and everyone communicates through these puppets)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:41
+msgid ""
+"To deploy a server on I2P, you create a destination keypair. You use the "
+"private key to authenticate your server when connecting it to I2P, and "
+"you make the public key (aka destination key) known publicly, so others "
+"can connect to your server. (indirectly, through your gateways)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:44
+msgid "Each service you run on I2P requires a different keypair."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:47
+msgid ""
+"To generate your keypair, type the command: java -jar "
+"lib/i2ptunnel.jar -nogui -e \"genkeys myWebPrivKey.dat "
+"myWebPubKey.dat\" (all on one line)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:50
+msgid ""
+"In windows, to generate your keypair, type the command: java -jar "
+"lib/i2ptunnel.jar -nogui -e \"genkeys myWebPrivKey.dat "
+"myWebPubKey.dat\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:53
+msgid ""
+"The filenames myWebPrivKey.dat and "
+"myWebPubKey.dat are arbitrary - choose whatever you want "
+"here, as long as you understand your own choices."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:56
+msgid ""
+"We now need to export your public key into base64 format, which you will "
+"share with others."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:59
+msgid ""
+"To convert your myWebPubKey.dat file into shareable base64, type the "
+"command java -cp lib/i2p.jar net.i2p.data.Base64 encode "
+"myWebPubKey.dat > myWebPubKey.txt (all on one line)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:62
+msgid ""
+"This file you have just generated, myWebPubKey.txt, contains"
+" a long base64 string (516 chars at last count), which we call a "
+"destination key. All you need to know about this string for now is that "
+"it allows remote clients to uniquely pinpoint and connect to your server,"
+" just the same way as an IP address allows remote machines to pinpoint "
+"and connect to your machine."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:65
+msgid ""
+"However, in contrast to an IP address, there is no way to trace your "
+"machine's physical location - even though your server can be addressed "
+"via I2P, your IP address cannot be traced or associated with this "
+"destination key."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:70
+msgid "3 - Open a 'Tunnel' from I2P To Your Server"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:72
+msgid ""
+"For clients elsewhere in I2P to be able to access your server, you must "
+"run a 'bridge' or 'tunnel', which takes connections from these clients "
+"and forwards them to your local server."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:75
+msgid ""
+"To activate such a tunnel, type the command java -jar "
+"lib/i2ptunnel.jar -nogui -e \"server localhost 10880 "
+"myWebPrivKey.dat\" (all one line)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:78
+msgid ""
+"If you used different filenames or port number earlier on, change these "
+"accordingly"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:81
+msgid ""
+"Windows users, remember to replace apostrophes with double quotes. Thus: "
+"java -jar lib/i2ptunnel.jar -nogui -e \"server localhost 10880 "
+"myWebPrivKey.dat\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:84
+msgid ""
+"Within a few seconds, the 'tunnel' should now be active, and remote "
+"clients should be able to reach your server anonymously. Remember to let "
+"your router \"warm up\" before opening clients to it."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:89
+msgid "4 - Update Your hosts.txt File "
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:91
+msgid ""
+"To test your own server locally, you'll need to create an entry in your "
+"hosts.txt file, so I2P can translate the simple URL you place in the "
+"browser's address bar into the full public key text needed to find your "
+"server."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:94
+msgid ""
+"Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where "
+"myserver.i2p is an I2P 'domain' you want to associate with your site, and"
+" the blahblahblah is the text of the base64 public key you created "
+"earlier in the file myWebPubKey.txt"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:97
+msgid ""
+"With this in place, you and others can reach your server with the simple "
+"domain name myserver.i2p in the browser's address bar."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:102
+msgid "5 - Surf Your Site Within I2P"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:104
+msgid ""
+"Using your secondary browser - the one you earlier configured to use "
+"localhost:4444 as a proxy - point this browser to the address http://myserver.i2p"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:107
+msgid "You should see the main page of your webserver come up."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:112
+msgid "6 - Create a Local Client Tunnel Connection "
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:114
+msgid "We now have to think beyond just web servers."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:117
+msgid ""
+"As you grow into I2P and get more of a 'feel' for it, you will want to "
+"use all manner of servers and clients."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:120
+msgid ""
+"The beauty of I2P is that it allows standard Internet clients and servers"
+" for most protocols to be transparently 'tunneled' through the anonymous "
+"network."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:123
+msgid ""
+"You can run mailservers/clients, nameservers/clients, newsservers/clients"
+" - almost anything at all - perhaps even FTP in passive mode."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:126
+msgid ""
+"Now, we'll create a client tunnel. This is like the server tunnel we "
+"created earlier, but works in reverse. It listens to a port on your local"
+" machine; your local client connects to this port; the connection gets "
+"forwarded through I2P to the service on the other end."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:129
+msgid ""
+"To open your client tunnel for your server, type the command java "
+"-jar lib/i2ptunnel.jar -nogui -e \"config localhost 7654\" -e \"client "
+"10888 textofbase64key\" (all one line)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:132
+msgid ""
+"The port 10888 is arbitrary - it just needs to be something other than "
+"the physical port your server is listening on."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:135
+msgid ""
+"textofbase64key is simply the contents of the public key text file "
+"myWebPubKey.txt, reproduced fully on one line (alternately, instead of "
+"textofbase64key, you can specify the name from your hosts.txt - e.g. "
+"myserver.i2p)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:138
+msgid ""
+"Within a minute or two of launching this command, the client tunnel from "
+"your local machine into I2P will be open and ready for use."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:141
+msgid ""
+"Point your regular web browser (ie, not the one you configured to use "
+"localhost:4444), and point it to http://localhost:10888"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:144
+msgid ""
+"Verify that the main page of your server eventually comes up in your "
+"browser."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:147
+msgid ""
+"You use the same procedure for using any local client program to access a"
+" remote I2P server - just get the base64 public key (called destination "
+"key) of the remote server, choose a local port to connect to the remote "
+"server, open the tunnel, and just connect with your client to your "
+"heart's content."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:152
+msgid "7 - Share your server details with others"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:154
+msgid ""
+"Using an anonymous medium (eg the one of the I2P IRC servers or ugha's "
+"wiki), post your domain name (eg www.mynick.i2p as well as your destination key. "
+"Others will then be able to reach your server remotely, without either of"
+" you jeopardizing your anonymity."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:157
+msgid ""
+"Remember, you can go to What's on I2P and find the latest public keys "
+"linked to their URL. You should also post your own public key and URL "
+"their. However, you will want to do this anonymously, of course. "
+"Drupal.i2p.net is currently, as of this writing, only accessible from the"
+" net. So, to access the outside WWW anonymously from inside of I2P, you "
+"will need to start up your script called startSquid. Do it the same way "
+"you have been doing these other scripts. Reconfigure your browser to "
+"proxy on localhost:5555, as defined in the script, and when the script "
+"has generated it's keys, you can access the squid proxy. Put any WWW URL "
+"(such as Google or this i2p site) into your browser's address bar and you"
+" will be surfing the World Wide Web anonymously. Now you can safely post "
+"your public key, and no one can detect your IP address."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:162
+msgid "8 - Write Some Scripts To Handle All This Menial Nonsense"
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:164
+msgid ""
+"It would drive most people crazy, going through all these steps every "
+"time one sets up an I2P server, and/or deploys a client."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:167
+msgid ""
+"Aum's website http://www.freenet.org.nz/i2p/ has a script called "
+"setupServer.py which automates all this nonsense into one simple command "
+"line . But I respect that people's tastes in user interfaces differ, and "
+"trying to write something which satisfies everyone's needs usually "
+"results in something so complex that it turns into newbie-repellent."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:170
+msgid ""
+"So please feel free to use and/or customize setupServer.py to taste, or "
+"write your own in Python or another language."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:173
+msgid ""
+"Also, you may want to write a script which handles the startup of the I2P"
+" Router, the eepProxy, plus any and all tunnels you are using. I've got "
+"such a script called startEverything.sh, which gets launched at system "
+"startup. (Be sure to search this site for template scripts to automate "
+"your I2P commands. If I create a page for one, I'll try to remember to "
+"link it here."
+msgstr ""
+
+#: i2p2www/pages/site/misc/i2ptunnel-services.html:176
+msgid "Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file."
+msgstr ""
+
+#: i2p2www/pages/site/misc/invisiblenet.html:2
+msgid "Old Documents"
+msgstr ""
+
+#: i2p2www/pages/site/misc/invisiblenet.html:5
+msgid ""
+"Following is a list of documents originally on www.invisiblenet.net/i2p/ "
+"and\n"
+"rescued via the\n"
+"Wayback Machine.\n"
+"They are quite dated and may or may not be accurate.\n"
+"However, the I2CP and I2NP documents in particular have some good "
+"information."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:3
+msgid "August 2011"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:7
+msgid ""
+"Using JNI (Java Native Interface), a bit of C code (thanks ugha!), a "
+"little\n"
+"manual work and a piece of chewing gum we have made several\n"
+"cryptography operations quite a bit faster."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:13
+#, python-format
+msgid ""
+"The speedup comes from the super-fast\n"
+"GNU MP Bignum library (libgmp).\n"
+"We use a single function from libgmp -\n"
+"mpz_powm()\n"
+"as a replacement for the\n"
+"Java Math library's BigInteger modPow().\n"
+"As modPow() is a significant computational portion of many crypto "
+"operations, this is of significant benefit."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:25
+#, python-format
+msgid ""
+"The standard I2P installation includes about 20 versions of the library "
+"for different platforms,\n"
+"each about 50KB, inside the jbigi.jar file.\n"
+"The initialization of the JBigI library, including CPU identification, "
+"selection, and extraction\n"
+"of the correct loadable module, is handled by the\n"
+"NativeBigInteger class.\n"
+"If no module is available for the current platform, the standard\n"
+"Java Math library's BigInteger modPow()\n"
+"is used."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:38
+msgid "Rebuilding and Testing JBigI"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:39
+msgid ""
+"Following are the instructions to build a new jbigi library for your own "
+"platform\n"
+"and testing its performance."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:42
+msgid "Requirements"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:43
+msgid ""
+"This works on Linux, and with a few changes in build.sh probably also on\n"
+"other platforms. FreeBSD has also been reported to work too. On Kaffee "
+"the\n"
+"speedup is very small, because it already uses native BitInteger "
+"internally.\n"
+"Blackdown seems to cause strange errors. Because you are going to do\n"
+"compilation, you need JDK; JRE won't work."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:50
+msgid ""
+"The required code is available in monotone database and the latest source"
+" tarball. "
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:51
+msgid ""
+"The GNU MP Bignum library (libgmp) needs to be installed, if it isn't\n"
+"included in your OS / distribution or installed already, it can be "
+"received from\n"
+"http://gmplib.org/#DOWNLOAD. "
+"Even if you\n"
+"have already installed it as binary, it might still be worth a try to "
+"compile\n"
+"GMP yourself, since then it will be able to use the specific instructions"
+" of\n"
+"your processor. The latest GMP may also\n"
+"be used instead of GMP 5.0.2, but it hasn't been tested by us."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:61
+msgid "Step-by-step instructions"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:63
+msgid ""
+"Look at your running "
+"environment on the logs.jsp page.\n"
+"There should be one of two status messages for JBigI - either"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:66
+msgid "Locally optimized native BigInteger loaded from the library path"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:68
+msgid "or"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:70
+msgid "Native BigInteger library jbigi not loaded - using pure java"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:71
+msgid ""
+"If the native BitInteger library was NOT loaded, you definitely need to\n"
+"compile your own.\n"
+"Certain platforms, such as OS X, OpenSolaris, and 64-bit systems,\n"
+"may require you to compile your own library.\n"
+"If the BigInteger library was loaded, do at least the next step to see\n"
+"what your performance is."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:78
+msgid ""
+"Look on http://localhost:7657/stats.jsp"
+"\n"
+"to see what the lifetime average values for "
+"crypto.elGamal.decrypt and\n"
+"crypto.elGamal.encrypt are. The numbers are times in "
+"milliseconds. Copy these somewhere so you can compare\n"
+"them later on.\n"
+"The network average for encrypt time is about 20ms.\n"
+"If your encrypt time is less than 50ms for a relatively new processor, or"
+" less than 100ms\n"
+"for an older processor, and the native BigInteger library was loaded, you"
+" are probably fine."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:87
+#, python-format
+msgid ""
+"Get the latest released source code of I2P from\n"
+"the download page, or get the cutting-edge "
+"source\n"
+"out of the monotone database mtn.i2p2.de"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:92
+msgid "Inside the source tree change directory to: core/c/jbigi"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:93
+msgid ""
+"Read the README file.\n"
+"If you have a /usr/lib/libgmp.so file, you do not have to download GMP.\n"
+"Use the 'dynamic' argument to build.sh.\n"
+"Otherwise, you must download GMP version 5.0.2 from\n"
+"from http://gmplib.org/#DOWNLOAD, "
+"saving it to gmp-5.0.2.tar.bz2.\n"
+"If you decide to use a newer version, change the VER= line in "
+"core/c/jbigi/build.sh."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:101
+msgid ""
+"Take a look at build.sh, if your JAVA_HOME\n"
+"environment variable is set and you are using Linux then it might just "
+"work.\n"
+"Otherwise change the settings. Remember, you need the Java SDK installed."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:106
+msgid ""
+"Run build.sh (if you downloaded GMP) or\n"
+"build.sh dynamic (if you have /usr/lib/libgmp.so).
            \n"
+"Maybe the build spewed out some errors of missing jni.h and jni_md.h "
+"files.\n"
+"Either copy these files from your java install into the "
+"core/c/jbigi/jbigi/include/ directory,\n"
+"or fix $JAVA_HOME.
            \n"
+"You can run the build.sh from the core/c/ "
+"directory which will\n"
+"build all available jbigi libs into a jbigi.jar.
            \n"
+"A file named libjbigi.so should be created in the current\n"
+"directory. If this doesn't happen and/or you get errors then please "
+"report\n"
+"them."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:118
+msgid ""
+"Follow the instructions in core/c/README to install the library and run\n"
+"the speed test.\n"
+"Read the final lines of the speed test's output for some additional\n"
+"info, it will be something like this:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:128
+msgid ""
+"If the native is indeed 5-7x faster (or more) then it looks all good. If "
+"not, please report."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:129
+msgid "Copy libjbigi.so to your i2p directory"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:130
+msgid "Restart your I2P programs."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jbigi.html:131
+msgid ""
+"On http://localhost:7657/stats.jsp"
+"\n"
+"the crypto.elGamal.decrypt and "
+"crypto.elGamal.encrypt\n"
+"should be a lot faster."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jrandom-awol.html:2
+msgid "Jrandom's Announcement"
+msgstr ""
+
+#: i2p2www/pages/site/misc/jrandom-awol.html:4
+msgid ""
+"The following message was received in mid-November 2007. We have no "
+"further information\n"
+"on jrandom's status."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jrandom-awol.html:9
+#, python-format
+msgid ""
+"Subsequently, in an unrelated incident, the hosting company for\n"
+"all *.i2p.net servers (except forum.i2p.net) suffered a power outage\n"
+"on January 13, 2008, and the i2p.net servers did not fully return to "
+"service.\n"
+"As only jrandom has the credentials required to restore service,\n"
+"and he could not be contacted,\n"
+"we moved all public services to www.i2p2.de\n"
+"and related subdomains."
+msgstr ""
+
+#: i2p2www/pages/site/misc/jrandom-awol.html:19
+#, python-format
+msgid ""
+"Approximately two months later, for unrelated reasons,\n"
+"forum.i2p.net was moved to %(forum)s."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:2
+#: i2p2www/pages/site/misc/manual-wrapper.html:4
+msgid "Manually Installing the Java Wrapper"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:6
+#, python-format
+msgid ""
+"The installation package for the I2P router"
+" comes\n"
+"with a Java wrapper for the most common architectures. If your system is "
+"not\n"
+"supported by our installer—or if you want to update the wrapper to "
+"a\n"
+"newer version—the following steps describe installing the wrapper "
+"manually."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:14
+msgid ""
+"Check Tanuki Software's download"
+" page\n"
+"for your platform. Is your platform listed? If so, you're in\n"
+"luck! Download the most recent version of the Community Edition for your "
+"OS and\n"
+"CPU and move to the next step."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:20
+msgid ""
+"If your platform does not have an already compiled wrapper available, you"
+"\n"
+"may be able to compile it yourself. If you are willing to have a go at "
+"it, move\n"
+"on to compiling the wrapper for your system."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:27
+msgid "Using existing binaries"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:28
+msgid "In the steps below, $I2P means the location I2P was installed to."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:36
+#: i2p2www/pages/site/misc/manual-wrapper.html:64
+msgid "Try to start I2P using $I2P/i2prouter start"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:37
+#: i2p2www/pages/site/misc/manual-wrapper.html:65
+msgid "tail -f /tmp/wrapper.log and look for any problems."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:39
+#: i2p2www/pages/site/misc/manual-wrapper.html:67
+msgid ""
+"If this did not work you'll need to use runplain.sh to start"
+" I2P."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:43
+msgid "Compiling from source"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:44
+msgid ""
+"These steps worked to compile the wrapper for use on a mipsel system "
+"running Debian. The steps will need to be altered for "
+"your system."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:48
+msgid ""
+"Download the source archive for the community version of the wrapper from"
+" wrapper download"
+" page."
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:49
+msgid "Extract the tarball"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:51
+msgid ""
+"Set environment variables ANT_HOME and "
+"JAVA_HOME. For example, in Debian:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:54
+msgid ""
+"Since there isn't a Makefile for Mipsel, we'll make a copy of an already "
+"existing makefile:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:56
+msgid "Now we can attempt to compile the wrapper:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:57
+msgid "use ./build64.sh if you have a 64bit CPU and JVM"
+msgstr ""
+
+#: i2p2www/pages/site/misc/manual-wrapper.html:58
+msgid "Copy the wrapper into its proper place:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:4
+msgid ""
+"Here's an outline and rationale for a minimal WWW proxy app for use over "
+"I2P."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:8
+msgid ""
+"HTTP operation over I2P using I2PTunnel.  When the base SocketLibrary\n"
+"is out, the only significant difference will be the 'wrapRequest' and\n"
+"'unwrapRequest' will functionally be placed in the socketLibrary, not\n"
+"in the router (but later versions of the SocketLibrary will be able to\n"
+"use selective ACK and large window sizes, allowing more ACKs to be\n"
+"skipped)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:47
+msgid ""
+"An optimized form, designed to handle only 128KB [1] files and pages, can"
+"\n"
+"operate significantly faster:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:71
+msgid ""
+"The difference in network load and latency is significant - this is\n"
+"essentially a UDP version of HTTP.  On the normal web, we can't really do"
+" that,\n"
+"since most HTTP requests and responses are orders of magnitude larger "
+"than UDP\n"
+"packets functionally support, but in I2P, messages can be large.  The "
+"savings\n"
+"for the network load comes from the fact that we don't need to send any "
+"ACK\n"
+"messages - rather than the earlier wrap/unwrap request (that bundles a\n"
+"DataMessage with a DeliveryStatusMessage to provide guaranteed delivery),"
+" the\n"
+"MinWWW proxy deals with resends (if necessary - in I2PTunnel today, there"
+" are no\n"
+"resends)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:83
+msgid ""
+"The data that the MinWWW proxy and server need to wrap is trivial - when "
+"the\n"
+"proxy wants to send \"GET /\", it prepends it with the I2P Destination "
+"sending\n"
+"the request, followed by a 4 byte request ID.  The MinWWW server receives"
+" those\n"
+"requests, contacts the appropriate HTTPD, sends the request, waits for "
+"the\n"
+"response, and sends a reply to the MinWWW proxy containing the response,\n"
+"prefixed with the original request ID.  That response is taken and passed"
+" back\n"
+"to the browser and the connection is closed."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:93
+msgid ""
+"In addition, the MinWWW proxy can choose the MinWWW server to use from a\n"
+"list, going through some round robin or other algorithm, so that there "
+"are\n"
+"multiple outproxies merged transparently.  The bandwidth required for "
+"running\n"
+"one of these outproxies is also greatly reduced, since it will only "
+"handle 128KB\n"
+"files (aka no one is going to be downloading porn, warez, etc)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:101
+msgid ""
+"The functionality /is/ limited, but 128KB of data is a lot for a single "
+"HTTP\n"
+"request or response.  The above diagrams are also unrealistic in their "
+"hops -\n"
+"ROUTERA will really never talk directly to ROUTERB.  ROUTERA will send "
+"each\n"
+"of the messages through two additional outbound routers, then forwarded "
+"to\n"
+"two additional inbound routers to ROUTERB, so the lag there is "
+"significant -\n"
+"while the above only saves 11 steps, 8 of those steps need to traverse "
+"the\n"
+"entire tunnel path (4+ remote hops each time when tunnels are 2 remote "
+"hops\n"
+"in each stretch), leaving MinWWW with only two full traversals (one for "
+"the\n"
+"request, one for the response), instead of 10."
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:113
+msgid ""
+"Implementing the MinWWW proxy and server should be fairly easy - read an "
+"HTTP\n"
+"request from the client fully (perhaps only start out with HTTP GET, "
+"leaving\n"
+"HTTP POST for later), wrap the message, and wait for the response.  The "
+"server\n"
+"in turn simply needs to parse the request to either open a socket or URL,"
+"\n"
+"send the request, wait for the response, and send it back through the "
+"network.\n"
+"If someone were to implement this, it would be Good :)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/minwww.html:122
+msgid ""
+"[1] Why 128KB files?  Currently I2CP allows functionally arbitrary "
+"message\n"
+"size, but that's going to be going away since it involves either "
+"excessive memory\n"
+"overhead on intermediary routers, or additional implementation details to"
+"\n"
+"handle.  I2PTunnel is currently limited to 128KB and hasn't been a "
+"burden,\n"
+"so perhaps it could be increased to 256KB when the I2CP spec is updated)"
+msgstr ""
+
+#: i2p2www/pages/site/misc/myi2p.html:4
+msgid ""
+"There has been discussion about a distributed blogging application for a "
+"few\n"
+"months now called \"MyI2P\".  While the original discussions were lost, "
+"we were \n"
+"able to retrieve a Google cache\n"
+"of it.  It isn't pretty, but it includes the basic overview and some "
+"discussion\n"
+"that ensued."
+msgstr ""
+
+#: i2p2www/pages/site/misc/myi2p.html:12
+#, python-format
+msgid ""
+"The application itself is not yet implemented, and the ideas behind it "
+"have \n"
+"been made less ambitious over time, but they are still valid and the "
+"current \n"
+"plan is to have the core MyI2P functionality "
+"available \n"
+"along side the I2P 1.0 release.  That will include a distributed address "
+"book\n"
+"to enable secure, distributed, and human readable naming by sacrificing "
+"the \n"
+"need for global uniqueness - basically everyone has their own local "
+"address book \n"
+"and can 'subscribe' to other people's address books, letting MyI2P "
+"periodically\n"
+"retrieve new name to destination mappings (leaving conflicts up to the "
+"user to\n"
+"resolve).  In addition to the address book, there will be a distributed "
+"blogging\n"
+"system using a reduced and secured subset of \n"
+"bbcode to "
+"essentially\n"
+"provide an anonymous LiveJournal with\n"
+"a 'friends list' and transparent access control (authenticated by the I2P"
+"\n"
+"datagrams with rules defined based on the "
+"address book)."
+msgstr ""
+
+#: i2p2www/pages/site/misc/myi2p.html:29
+msgid ""
+"Additional functionality, such as integration with a DHT backing store or"
+" \n"
+"swarming file transfers for 'attachments' can be added later.  Email may "
+"or may\n"
+"not get in the first pass either, though its implementation is "
+"essentially just\n"
+"a blog entry with private access, so perhaps some UI designer can come up"
+" with\n"
+"something.  Exporting the data to RSS or access through ATOM will be an "
+"option \n"
+"down the road as well."
+msgstr ""
+
+#: i2p2www/pages/site/misc/ratestats.html:2
+#: i2p2www/pages/site/misc/ratestats.html:5
+msgid "RateStat list"
+msgstr ""
+
+#: i2p2www/pages/site/misc/ratestats.html:6
+msgid "I2P enables the collection of a wide range of rates."
+msgstr ""
+
+#: i2p2www/pages/site/misc/ratestats.html:7
+msgid ""
+"The list was gathered using the following command in the top directory of"
+" the branch i2p.i2p:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/ratestats.html:10
+msgid "All options aren't needed, but it works."
+msgstr ""
+
+#: i2p2www/pages/site/misc/transition-guide.html:4
+#, python-format
+msgid ""
+"The I2P sourcecode is kept in several distributed monotone repositories.\n"
+"See the\n"
+"Monotone website for information\n"
+"on monotone.\n"
+"See\n"
+"this forum post on i2p "
+"monotone\n"
+"for more information on how to get started and check out the source "
+"anonymously.\n"
+"There is also a quick-start guide on the\n"
+"new developer's page."
+msgstr ""
+
+#: i2p2www/pages/site/misc/transition-guide.html:16
+msgid ""
+"If you want to get the source non-anonymously, pull from the public "
+"server mtn.welterde.de.\n"
+"The i2p source code branch is \"i2p.i2p\"."
+msgstr ""
+
+#: i2p2www/pages/site/misc/transition-guide.html:21
+msgid "Guide"
+msgstr ""
+
+#: i2p2www/pages/site/misc/transition-guide.html:22
+msgid ""
+"\n"
+"The following is a detailed guide by Complication."
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:2
+msgid "How to Upgrade from 0.6.1.30 and Earlier"
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:6
+msgid "Upgrading from 0.6.1.30 and Earlier Releases"
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:8
+#, python-format
+msgid ""
+"Since i2p's lead developer\n"
+"has gone AWOL,\n"
+"we do not have his update signing key or access to\n"
+"www.i2p[.net] or dev.i2p[.net].\n"
+"Complication and zzz have generated new signing keys, and they and Amiga "
+"are providing\n"
+"update file hosting. These changes must be configured in your router to "
+"take effect."
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:17
+msgid ""
+"Make the following configuration changes and your router will "
+"automatically install\n"
+"the latest release."
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:22
+#, python-format
+msgid ""
+"We recommend the automated process as it will verify the key of the "
+"signed update file.\n"
+"If you do not make these changes,\n"
+"you may manually download the i2pupdate.zip file from\n"
+"the download page."
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:34
+#, python-format
+msgid "Change the News URL to: %(url)s"
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:38
+msgid ""
+"Select ONE of the following new Update URLs at random and enter it into "
+"the Update URL box: "
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:43
+msgid "Check the box \"Update through the eepProxy?\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:44
+msgid "Click \"Save\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:51
+msgid "Add the following line:"
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:55
+msgid "Click \"Apply\""
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:58
+msgid ""
+"You are now ready to automatically receive the release update file,\n"
+"either by setting your update policy to \"download and install\" or by "
+"clicking on the\n"
+"\"update available\" link when it appears."
+msgstr ""
+
+#: i2p2www/pages/site/misc/upgrade-0.6.1.30.html:65
+#, python-format
+msgid ""
+"If you would like to verify the trusted update keys, they are also\n"
+"posted and signed here.\n"
+"Thank you for your support during this transition. For help please "
+"contact us on #i2p."
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:2
+msgid "Academic Research"
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:4
+msgid ""
+"Academic research and analysis of I2P is an important part of ensuring "
+"that the software and network performs as expected and is safe for users "
+"in hostile environments."
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:8
+msgid ""
+"I2P can be run as a separate test network by controlling the locations "
+"that a new router reseeds from so that it only finds other test routers. "
+"Additionally, the router can be run on its own in a virtual network mode "
+"to enable testing the router in isolation; to enable this mode, add "
+"i2p.vmCommSystem=true to the router.config before starting."
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:12
+#, python-format
+msgid ""
+"If you are planning on conducting research on the live I2P network, "
+"please contact us before you commence your "
+"testing. While we do not discourage researchers from responsibly testing "
+"their ideas on the live network, if an attack becomes apparent and we "
+"don't have any line of communication then we will end up taking "
+"countermeasures which could interfere with the test."
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:16
+msgid "Prior Research"
+msgstr ""
+
+#: i2p2www/pages/site/research/index.html:18
+#, python-format
+msgid ""
+"A list of known published papers about I2P is available here."
+msgstr ""
+
+#: i2p2www/pages/site/research/papers.html:6
+msgid "Following are links to research papers about I2P."
+msgstr ""
+
+#: i2p2www/pages/site/research/papers.html:12
+msgid "Newest links are at the top of the page."
+msgstr ""
+
+#: i2p2www/pages/site/research/papers.html:17
+msgid "Papers and Research"
+msgstr ""
+
+#~ msgid ""
+#~ "When installing for the first time, "
+#~ "please remember to adjust your "
+#~ "NAT/firewall\n"
+#~ "if you can. The ports to forward"
+#~ " can be found on the \n"
+#~ "network configuration page in the "
+#~ "router console. If guidance with respect"
+#~ " to forwarding ports is needed,\n"
+#~ "you may find portforward.com to "
+#~ "be helpful."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "\n"
+#~ "Java Runtime 1.5 or higher.\n"
+#~ "(Oracle/Sun Java Version 6,\n"
+#~ "OpenJDK 6, or\n"
+#~ "IcedTea6\n"
+#~ " recommended)\n"
+#~ "
            \n"
+#~ "Determine"
+#~ " your installed Java version here\n"
+#~ ""
+#~ "or type java -version at your command prompt.\n"
+#~ msgstr ""
+
+#~ msgid "Themes"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Our primary IRC network is the "
+#~ "Irc2P network within I2P; a default "
+#~ "tunnel to this network is set up"
+#~ " with new router installs.\n"
+#~ "  We are also present on multiple"
+#~ " standard networks like OFTC,\n"
+#~ "  EIN and "
+#~ "Freenode.\n"
+#~ "  All I2P-related channels on all"
+#~ " these network are linked to the "
+#~ "main channels on Irc2P via relay "
+#~ "bots."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "See also the page with\n"
+#~ "links to papers, "
+#~ "presentations, videos, and tutorials about "
+#~ "I2P."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Filtering is active on these outproxies"
+#~ " (for example, mibbit and torrent\n"
+#~ "tracker access is blocked). Note that"
+#~ " even though the pirate bay is "
+#~ "blocked\n"
+#~ "they host an official eepsite at "
+#~ "tpb.i2p. Eepsites\n"
+#~ "that are accessible via .i2p addresses"
+#~ " are also not allowed via the "
+#~ "outproxies.\n"
+#~ "As a convenience, False.i2p blocks ad servers."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "I2PTunnel is currently used to let "
+#~ "people run their own anonymous website"
+#~ " \n"
+#~ "(\"eepsite\") by running a normal "
+#~ "webserver and pointing an I2PTunnel "
+#~ "'server' \n"
+#~ "at it, which people can access "
+#~ "anonymously over I2P with a normal "
+#~ "web browser \n"
+#~ "by running an I2PTunnel HTTP proxy "
+#~ "(\"eepproxy\").  In addition, we use the"
+#~ " same \n"
+#~ "technique to run an anonymous IRC "
+#~ "network (where the IRC server is "
+#~ "hosted \n"
+#~ "anonymously, and standard IRC clients "
+#~ "use an I2PTunnel to contact it).  "
+#~ "There \n"
+#~ "are other application development efforts "
+#~ "going on as well, such as one "
+#~ "to \n"
+#~ "build an optimized swarming file transfer application (a la \n"
+#~ "BitTorrent), a \n"
+#~ "distributed data store (a la Freenet / \n"
+#~ "MNet), and a"
+#~ " blogging system (a fully \n"
+#~ "distributed LiveJournal), but "
+#~ "those are \n"
+#~ "not ready for use yet."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "When I last profiled the I2P code,"
+#~ " the vast majority of time was "
+#~ "spent within\n"
+#~ "one function: java.math.BigInteger's\n"
+#~ "modPow.\n"
+#~ "Rather than try to tune this method, we'll call out to\n"
+#~ "GNU MP -"
+#~ " an insanely fast math library\n"
+#~ "(with tuned assembler for many architectures). (Editor: see\n"
+#~ "NativeBigInteger for faster"
+#~ " public key cryptography)"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Compared to I2P, Freenet offers some "
+#~ "substantial benefits - it is a "
+#~ "distributed data\n"
+#~ "store, while I2P is not, allowing "
+#~ "people to retrieve the content published"
+#~ " by others \n"
+#~ "even when the publisher is no "
+#~ "longer online.  In addition, it should"
+#~ " be able to \n"
+#~ "distribute popular data fairly efficiently."
+#~ "  I2P itself does not and will "
+#~ "not provide \n"
+#~ "this functionality.  On the other hand,"
+#~ " there is overlap for users who "
+#~ "simply want to \n"
+#~ "communicate with each other anonymously "
+#~ "through websites, message boards, file "
+#~ "sharing\n"
+#~ "programs, etc.  There have also been "
+#~ "some attempts to develop a distributed"
+#~ " data \n"
+#~ "store to run on top of I2P,\n"
+#~ "(most recently a port of Tahoe-"
+#~ "LAFS)\n"
+#~ "but nothing is yet ready for general use."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "JAP (Java Anonymous Proxy) is a "
+#~ "network of mix cascades for anonymizing"
+#~ " web requests,\n"
+#~ "and as such it has a few "
+#~ "centralized nodes (participants in the "
+#~ "cascade) that blend\n"
+#~ "and mix requests from clients through"
+#~ " the sequence of nodes (the cascade)"
+#~ " before \n"
+#~ "proxying out onto the web.  The "
+#~ "scope, threat model, and security is "
+#~ "substantially \n"
+#~ "different from I2P, but for those "
+#~ "who don't require significant anonymity "
+#~ "but still\n"
+#~ "are not satisfied with an Anonymizer-"
+#~ "like service, JAP is worth reviewing."
+#~ "  One\n"
+#~ "caution to note is that anyone "
+#~ "under the jurisdiction of the German "
+#~ "courts may want\n"
+#~ "to take care, as the German "
+#~ "Federal Bureau of Criminal Investigation "
+#~ "(FBCI) has \n"
+#~ "successfully mounted an \n"
+#~ "attack"
+#~ " \n"
+#~ "on the network.  Even though the "
+#~ "method of this attack was later "
+#~ "found to be illegal \n"
+#~ "in the German courts, the fact "
+#~ "that the data was successfully collected"
+#~ " is the \n"
+#~ "concern.  Courts change their minds "
+#~ "based upon circumstance, and this is "
+#~ "evidence that \n"
+#~ "if a government body or intelligence "
+#~ "agency wanted to, they could gather "
+#~ "the data, even \n"
+#~ "if it may be found inadmissible in some courts later)"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Both of these systems work through the same basic \n"
+#~ "antnet"
+#~ " routing, providing some degree of\n"
+#~ "anonymity based on the threat model "
+#~ "of providing plausible deniability against "
+#~ "a simple \n"
+#~ "non-colluding adversary.  With the "
+#~ "antnet routing, they first either do "
+#~ "a random walk or a \n"
+#~ "broadcast search to find some peer "
+#~ "with the data or identity desired, "
+#~ "and then use a feedback\n"
+#~ "algorithm to optimize that found path."
+#~ "  This works well for applications "
+#~ "that merely want to know \n"
+#~ "what other people around them have "
+#~ "to offer - \"How are y'all doing\""
+#~ " vs. \"Hey Alice, how are you\" "
+#~ "- \n"
+#~ "you basically get a local cluster "
+#~ "of nodes that can share files with"
+#~ " and maintain some degree of \n"
+#~ "anonymity (though you don't have much"
+#~ " control over who is in that "
+#~ "group of peers)."
+#~ msgstr ""
+
+#~ msgid "0.9 roadmap wiki"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Determines which rateStat to fetch, see"
+#~ " ratestats."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Port of the Phex Gnutella client."
+#~ " Website\n"
+#~ "for plugin version here."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "While the standard exponent size is 2048 bits (256 bytes) and the I2P\n"
+#~ "PrivateKey\n"
+#~ "is a full 256 bytes,\n"
+#~ "we use the short exponent size of 226 bits (28.25 bytes).\n"
+#~ "This should be safe for use with the Oakley primes, per\n"
+#~ "On Diffie-Hellman Key "
+#~ "Agreement with Short Exponents - van "
+#~ "Oorschot, Weiner\n"
+#~ "at EuroCrypt 96, and crypto++'s benchmarks.\n"
+#~ "Benchmarks originally at this "
+#~ "link, now dead,\n"
+#~ "rescued from the"
+#~ " wayback machine, dated Apr 23, "
+#~ "2008."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "\"Garlic routing\" was first coined by\n"
+#~ "Michael "
+#~ "J. Freedman\n"
+#~ "in Roger Dingledine's Free Haven \n"
+#~ "Master's "
+#~ "thesis Section 8.1.1 (June 2000), as"
+#~ " derived from \n"
+#~ "Onion Routing."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "I2P initially began in Feb 2003 as a proposed modification to Freenet to allow"
+#~ " it to use alternate transports, such"
+#~ " as JMS, "
+#~ "then grew into its own as an\n"
+#~ ""
+#~ "'anonCommFramework' in April 2003, turning "
+#~ "into I2P in July, with code being"
+#~ " written in earnest\n"
+#~ "starting in August '03. I2P is "
+#~ "currently under development, following the "
+#~ "roadmap."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "As of December 2010, eche|on has "
+#~ "been running a Bitcoin account for"
+#~ " the I2P project. \n"
+#~ "If you'd like to donate using "
+#~ "Bitcoin, just transfer your desired "
+#~ "amount of coins to the account \n"
+#~ "%(account)s and leave eche|on a "
+#~ "note if you'd like your donation "
+#~ "to be mentioned on the I2P "
+#~ "webpage."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "To collect this bounty, the existing SDK tests must be checked \n"
+#~ "and made to work again. The need to be integrated into the ant \n"
+#~ "build scripts (\"ant test\"), and tied"
+#~ " in with a code coverage tool "
+#~ "(e.g. \n"
+#~ "Clover).  "
+#~ "The ant script\n"
+#~ "must be capable of generating test status results as a web page, \n"
+#~ "which will be published online."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "While it may be redundant, just for clarity the\n"
+#~ "GPL'ed "
+#~ "code included within\n"
+#~ "I2PTunnel and other apps must be "
+#~ "released under the GPL with an "
+#~ "additional \"exception\"\n"
+#~ "explicitly authorizing the use of Java's standard libraries:"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "More information about Trust Evauluation "
+#~ "Hooks can be found in the official Monotone"
+#~ " documentation."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Skim over the monotone "
+#~ "tutorial, to make sure you "
+#~ "understand the concepts."
+#~ msgstr ""
+
diff --git a/i2p2www/urls.py b/i2p2www/urls.py
new file mode 100644
index 00000000..532ef141
--- /dev/null
+++ b/i2p2www/urls.py
@@ -0,0 +1,79 @@
+from werkzeug.routing import BaseConverter
+
+from i2p2www import app
+from i2p2www.helpers import LazyView
+
+
+#######################
+# Custom URL converters
+
+class LangConverter(BaseConverter):
+    def __init__(self, url_map):
+        super(LangConverter, self).__init__(url_map)
+        self.regex = '(?:[a-z]{2})(-[a-z]{2})?'
+
+    def to_python(self, value):
+        parts = value.split('-')
+        if len(parts) == 2:
+            return parts[0] + '_' + parts[1].upper()
+        return value
+
+    def to_url(self, value):
+        parts = value.split('_')
+        if len(parts) == 2:
+            return parts[0] + '-' + parts[1].lower()
+        return value
+
+app.url_map.converters['lang'] = LangConverter
+
+
+######
+# URLs
+
+def url(url_rule, import_name, **options):
+    view = LazyView('i2p2www.' + import_name)
+    app.add_url_rule(url_rule, view_func=view, **options)
+
+url('/', 'views.main_index')
+url('//', 'views.site_show', defaults={'page': 'index'})
+url('//', 'views.site_show')
+
+url('//blog/', 'blog.views.blog_index', defaults={'page': 1})
+url('//blog/page/', 'blog.views.blog_index')
+url('//blog/category/', 'blog.views.blog_index', defaults={'page': 1})
+url('//blog/category//page/', 'blog.views.blog_index')
+url('//blog/post/', 'blog.views.blog_post')
+url('//feed/blog/rss', 'blog.views.blog_rss')
+url('//feed/blog/atom', 'blog.views.blog_atom')
+url('//feed/blog/category//atom', 'blog.views.blog_atom')
+
+url('//meetings/', 'meetings.views.meetings_index', defaults={'page': 1})
+url('//meetings/page/', 'meetings.views.meetings_index')
+url('//meetings/', 'meetings.views.meetings_show')
+url('//meetings/.log', 'meetings.views.meetings_show_log')
+url('//meetings/.rst', 'meetings.views.meetings_show_rst')
+url('//feed/meetings/atom', 'meetings.views.meetings_atom')
+
+url('//download', 'downloads.downloads_list')
+url('//download/', 'downloads.downloads_select')
+url('/download//any/', 'downloads.downloads_redirect', defaults={'mirror': None})
+url('/download///', 'downloads.downloads_redirect')
+
+url('/meeting', 'legacy.legacy_meeting')
+url('/meeting.html', 'legacy.legacy_meeting')
+url('/status---', 'legacy.legacy_status')
+url('/status---.html', 'legacy.legacy_status')
+url('/_', 'legacy.legacy_show')
+url('/_.html', 'legacy.legacy_show')
+url('//', 'legacy.legacy_show')
+url('/.html', 'legacy.legacy_show')
+
+url('/hosts.txt', 'views.hosts')
+url('/robots.txt', 'views.robots')
+url('/favicon.ico', 'views.favicon')
+
+url('/googleadcf8b9c9f4ff24f.html', 'views.google')
+url('/BingSiteAuth.xml', 'views.bing')
+
+url('/sitemap_index.xml', 'sitemap.render_sitemap_index')
+url('//sitemap.xml', 'sitemap.render_sitemap')
diff --git a/i2p2www/views.py b/i2p2www/views.py
new file mode 100644
index 00000000..5fb71db7
--- /dev/null
+++ b/i2p2www/views.py
@@ -0,0 +1,60 @@
+from flask import abort, redirect, render_template, safe_join, send_from_directory, url_for
+import os.path
+
+from i2p2www import STATIC_DIR, TEMPLATE_DIR
+from i2p2www.blog.helpers import get_blog_posts
+
+
+#######################
+# General page handlers
+
+# Index - redirects to en homepage
+def main_index():
+    return redirect(url_for('site_show', lang='en'))
+
+# Site pages
+def site_show(page):
+    if page.endswith('.html'):
+        return redirect(url_for('site_show', page=page[:-5]))
+    name = 'site/%s.html' % page
+    page_file = safe_join(TEMPLATE_DIR, name)
+
+    if not os.path.exists(page_file):
+        # Could be a directory, so try index.html
+        name = 'site/%s/index.html' % page
+        page_file = safe_join(TEMPLATE_DIR, name)
+        if not os.path.exists(page_file):
+            # bah! those damn users all the time!
+            abort(404)
+
+    options = {
+        'page': page,
+        }
+    if (page == 'index'):
+        options['blog_posts'] = get_blog_posts(8)
+
+    # hah!
+    return render_template(name, **options)
+
+
+############
+# Root files
+
+def hosts():
+    return send_from_directory(STATIC_DIR, 'hosts.txt', mimetype='text/plain')
+
+def robots():
+    return send_from_directory(STATIC_DIR, 'robots.txt', mimetype='text/plain')
+
+def favicon():
+    return send_from_directory(STATIC_DIR, 'favicon.ico', mimetype='image/vnd.microsoft.icon')
+
+
+#######################################
+# Verification pages for search engines
+
+def google():
+    return send_from_directory(STATIC_DIR, 'googleadcf8b9c9f4ff24f.html')
+
+def bing():
+    return send_from_directory(STATIC_DIR, 'BingSiteAuth.xml', mimetype='application/xml')
diff --git a/init-new-po.sh b/init-new-po.sh
new file mode 100755
index 00000000..4d9ea0f7
--- /dev/null
+++ b/init-new-po.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+. ./translation.vars
+
+if [ $# -ge 1 ]
+then
+    TZ=UTC env/bin/pybabel init -i $POTFILE -d $TRANSDIR -l $1
+else
+    echo "Usage: ./init-new-po.sh lang"
+fi
diff --git a/mirror.i2p2/mirror.god b/mirror.god.old
similarity index 100%
rename from mirror.i2p2/mirror.god
rename to mirror.god.old
diff --git a/mirror.i2p2/app.py b/mirror.i2p2/app.py
deleted file mode 100644
index 8c26e237..00000000
--- a/mirror.i2p2/app.py
+++ /dev/null
@@ -1,80 +0,0 @@
-from flask import Flask, redirect, request, render_template, abort
-from random import randint
-from sys import argv
-try:
-    import json
-except ImportError:
-    import simplejson as json
-
-
-# try to create an memcache client
-if len(argv[3:]) > 0:
-    try:
-        try:
-            from cmemcache import Client
-        except ImportError:
-            from memcache import Client
-        client=Client(argv[3:])
-    except ImportError:
-        client=None
-
-# create application
-app=Flask(__name__)
-
-# extract domain
-domain=argv[1]
-
-# extract port
-port=int(argv[2])
-
-def read_mirrors():
-    file = open('mirrors', 'r')
-    dat = file.read()
-    file.close()
-    lines=dat.split('\n')
-    ret={}
-    for line in lines:
-        try:
-            obj=json.loads(line)
-        except ValueError:
-            pass
-        if 'protocol' not in obj:
-            continue
-        protocol=obj['protocol']
-        if protocol not in ret:
-            ret[protocol]=[]
-        ret[protocol].append(obj)
-    return ret
-
-
-@app.route('/')
-def index():
-    return redirect('http://www.%s/download' % domain)
-
-@app.route('/select/')
-def select(f):
-    mirrors=read_mirrors()
-    obj=[]
-    for protocol in mirrors.keys():
-        a={}
-        a['name']=protocol.upper()
-        a['mirrors']=mirrors[protocol]
-        for mirror in a['mirrors']:
-            mirror['url']=mirror['url'] % f
-        obj.append(a)
-    return render_template('select.html', mirrors=obj, file=f, domain=domain)
-
-@app.route('//')
-def get(protocol, f):
-    mirrors=read_mirrors()
-    if not protocol in mirrors:
-        abort(404)
-    mirrors=mirrors[protocol]
-    return redirect(mirrors[randint(0, len(mirrors) - 1)]['url'] % f)
-
-@app.route('/')
-def old_get(f):
-    return redirect('http://i2p.googlecode.com/files/%s' % f)
-
-if __name__ == '__main__':
-    app.run(port=port)
diff --git a/mirror.i2p2/mirrors b/mirror.i2p2/mirrors
deleted file mode 100644
index 5afeaf67..00000000
--- a/mirror.i2p2/mirrors
+++ /dev/null
@@ -1,2 +0,0 @@
-{"url": "http://golden.mtveurope.org/~yang/i2p_mirror/%s", "org": "VServer.si", "org_url": "http://www.vserver.si", "protocol": "http", "country": "lu"}
-{"url": "http://a.mirror.geti2p.net/releases/current/%s", "org": "welterde", "protocol": "http", "country": "de"}
\ No newline at end of file
diff --git a/mirror.i2p2/templates/select.html b/mirror.i2p2/templates/select.html
deleted file mode 100644
index fc031ca1..00000000
--- a/mirror.i2p2/templates/select.html
+++ /dev/null
@@ -1,29 +0,0 @@
-
-
-
-  
-    I2P - Mirror selection - /{{ file }}
-    
-  
-  
-    
-    
            
-      
            Mirror selection
            
-      
            File: /{{ file }}
            
-    
            
-    {% for protocol in mirrors -%}
-    
            
-      
            {{ protocol.name }}
            
-      
-    
            
-    {%- endfor %}
-  
-  
-
diff --git a/project.vars b/project.vars
new file mode 100644
index 00000000..da768a33
--- /dev/null
+++ b/project.vars
@@ -0,0 +1,2 @@
+export venv_dir="env"
+export venv="`which virtualenv-2.7 || which virtualenv`"
diff --git a/reqs.txt b/reqs.txt
new file mode 100644
index 00000000..9bdbcceb
--- /dev/null
+++ b/reqs.txt
@@ -0,0 +1,6 @@
+Flask==0.9
+Flask-Babel==0.8
+Flask-Cache==0.10.1
+Jinja2==2.6
+docutils==0.9.1
+gunicorn==0.17.2
diff --git a/runserver.py b/runserver.py
new file mode 100755
index 00000000..9884e219
--- /dev/null
+++ b/runserver.py
@@ -0,0 +1,3 @@
+#!env/bin/python
+from i2p2www import app
+app.run(debug=False)
diff --git a/setup_venv.sh b/setup_venv.sh
new file mode 100755
index 00000000..af98f169
--- /dev/null
+++ b/setup_venv.sh
@@ -0,0 +1,14 @@
+#!/bin/sh
+set -e
+. ./project.vars
+
+if [ ! $venv ]; then
+    echo "ERROR: virtualenv not found!" >&2
+else
+    if [ ! -d $venv_dir ] ; then
+        $venv --distribute $venv_dir
+    fi
+
+    . $venv_dir/bin/activate
+    pip install -r reqs.txt
+fi
diff --git a/translation.vars b/translation.vars
new file mode 100644
index 00000000..27a7c47e
--- /dev/null
+++ b/translation.vars
@@ -0,0 +1,6 @@
+PROJECT=I2P
+VERSION=website
+PROJDIR=i2p2www
+BABELCFG=$PROJDIR/babel.cfg
+POTFILE=messages.pot
+TRANSDIR=$PROJDIR/translations
diff --git a/update-existing-po.sh b/update-existing-po.sh
new file mode 100755
index 00000000..6d4d1717
--- /dev/null
+++ b/update-existing-po.sh
@@ -0,0 +1,4 @@
+#!/bin/sh
+. ./translation.vars
+
+TZ=UTC env/bin/pybabel update -i $POTFILE -d $TRANSDIR
diff --git a/www.i2p2/pages/_layout.html b/www.i2p2/pages/_layout.html
deleted file mode 100644
index 26fa7599..00000000
--- a/www.i2p2/pages/_layout.html
+++ /dev/null
@@ -1,27 +0,0 @@
-{% include "_urlify" -%}
-
-
-
-  
-    {% filter capture('title') %}{% block title %}{% endblock %}{% endfilter %} - I2P
-    
-    
-    
-    
-    
-  
-  
-    
            Skip navigation
            
-    
-    
            {{ title }}
            
-    
            
-      {% include "_menu.html" %}
-    
            
-    
            
-      {% block content %}{% endblock %}
-    
            
-  
-
diff --git a/www.i2p2/pages/_menu.html b/www.i2p2/pages/_menu.html
deleted file mode 100644
index 8e6d2dca..00000000
--- a/www.i2p2/pages/_menu.html
+++ /dev/null
@@ -1,501 +0,0 @@
-
            
-English
-Deutsch
-Castellano
-中文
-
            
-Français
-Italiano
-Nederlands
-Русский
-
            
-Čeština
-العربية
-Ελληνικά
-
            
-
-
            Dark 
-Light
-
            
-
-{% if lang == "de" %}
-
            Willkommen bei I2P
            
-
            Download
            
-
            Neuigkeiten
            
-* Ankündigungen
            
-
-* Entwicklertreffen
            
-* Zeitplan
            
-* Aufgabenliste
            
-
            Über I2P
            
-* FAQ
            
-* Forum (within I2P)
            
-* Prämien
            
-* Beteilige dich!
            
-* Spende!
            
-
-* I2P-Team
            
-* Ruhmeshalle
            
-
            Dokumentationen
            
-* Wie funktioniert es?
            
-* Tech-intro
            
-* Anwendungen
            
-* Papers
            
-
            Entwickeln
            
-* API
            
-* Lizenzen
            
-* Fehler melden
-
-

            Syndie (I2P mirror)
            
-
            Links
            
-
            T-Shirt
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            Mirror
-
-
            Mirror 2
-
            Secure Site
-
-
            
-
            Impressum
            
-
-{% elif lang == "es" %}
-
            Bienvenido a I2P
            
-
            Descargas
            
-
            Novedades
            
-* Anuncios
            
-
-* Encuentros
            
-* Itinerario
            
-* Tareas
            
-
            Acerca de I2P
            
-* FAQ
            
-* Foro (within I2P)
            
-* Premias
            
-* ¡Participa!
            
-* Donaciones
            
-
-* Equipo I2P
            
-* Panteón
            
-
            Documentación
            
-* Cómo funciona
            
-* Tec-intro
            
-* Aplicaciones
            
-* Papers
            
-
            Desarollo
            
-* API
            
-* Licencias
            
-* Reportar errores
-
-

            Syndie (I2P mirror)
            
-
            Enlaces
            
-
            T-Shirt
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            Espejo
-
-
            Espejo 2
-
            Página Segura
-
-
            
-
            Pie de imprenta
            
-
-{% elif lang == "it" %}
-
            Benvenuti su I2P!
-
            Download
-
            News
            
-* Versioni
            
-
-* Incontraci
            
-* Roadmap
            
-* Cose-da-fare
            
-
            Informazioni su I2P
            
-* FAQ
            
-* Forum (within I2P)
            
-* Bounties
            
-* Get Involved!
            
-* Donazioni
            
-
-* Team I2P
            
-* Hall of Fame
            
-
            Documentazione
            
-* Come funziona?
            
-* Introduzione Tecnica
            
-* Applicazioni
            
-* Papers
            
-
            Sviluppo
            
-* API
            
-* Licenze
            
-* Report a Bug
-
-

            Syndie (I2P mirror)
            
-
            Links
            
-
            T-Shirt
-I2P T-Shirt for Europe>
-I2P T-Shirt for North America
-
            
-
            Mirror 1
-
-
            Mirror 2
-
            Secure Site
-
-
            
-
            Impressum
            
-
-{% elif lang == "nl" %}
-
            Welkom bij I2P
            
-
            Download
            
-
            Nieuws
            
-* Aankondigingen
            
-* Vergaderingen
            
-* Routekaart
            
-* Taken lijst
            
-
            Over I2P
            
-* FAQ
            
-* Forum (within I2P)
            
-* Premies
            
-* Werk mee
            
-* Doneer!
            
-
-* I2P Team
            
-* Eregalerij
            
-
            Documentation
            
-* Hoe werkt het?
            
-* Tech intro
            
-* Apps ontwikkelen
            
-* Papers
            
-
            Development
            
-* API
            
-* Licenties
            
-* Report a Bug
-
-

            Syndie (I2P mirror)
            
-
            Links
            
-
            T-Shirt
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            Mirror
-
-
            Mirror 2
-
            Beveiligde Site
-
-
            
-
            Impressum
            
-
-{% elif lang == "zh" %}
-
            √ I2P首页
            
-
            √ I2P下载
            
-
-
-
            项目动态
            
-* 公告
            
-
-
-* 会议
            
-* 路线图
            
-* 任务
            
-
            I2P简介
            
-* √ 常见问题集
            
-* i2p论坛 (within I2P)
            
-* 赏金项目
            
-* 志愿者
            
-* 捐助!
            
-
-* I2P团队
            
-* 名人堂
            
-
            技术文档
            
-* 工作原理
            
-* 技术内幕
            
-* 程序开发
            
-
            开发
            
-* API
            
-* 许可证
            
-* Report a Bug
-
-

            Syndie (I2P mirror)
            
-
            链接
            
-
            T恤
-I2P T-Shirt for Europe
-I2P T-Shirt for North America>
-
            
-
            Mirror
-
-
            Mirror 2
-
            Secure Site
-
-
            
-
            Impressum
            
-
-{% elif lang == "fr" %}
-
-
            Bienvenue sur I2P
            
-
            Téléchargements
            
-
-
-
            Nouvelles
            
-* Versions
            
-
-
-* Rencontres i2p
            
-* Feuille de route
            
-* Les choses à faire
            
-
            À propos d'i2p
            
-* Foire aux questions
            
-* I2P forums (within I2P)
            
-* Primes
            
-* Impliquez-vous!
            
-* Faire un don
            
-
-* L'équipe
            
-* La tirelire (i2pig)
            
-
            Documentation
            
-* Fonctionnement
            
-* Intro technique
            
-* Applications pour I2P
            
-* Papers
            
-
            Développement
            
-* API
            
-* Licences
            
-* Signaler un bug
-
-

            Syndie (I2P mirror)
            
-
            Liens
            
-
            T-Shirt
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            Miroir
-
-
            Miroir 2
-
            Site Sécurisé
-
-
            
-
            Impressum
            
-
-
-{% elif lang == "ru" %}
-
            Добро пожаловать
            
-
            Скачать
            
-
-
            Новости
            
-* Объявления
            
-* Проектные митинги
            
-* План развития
            
-* Список задач
            
-
-
            О проекте I2P
            
-* FAQ
            
-* Форумы (within I2P)
            
-* Премии за проекты
            
-* Как стать участником
            
-* Donate!
            
-
-* Команда I2P
            
-* Зал Славы
            
-
-
            Документация
            
-* Как это работает?
            
-* Техническая вводная
            
-* Приложения
            
-
-* Papers
            
-
            Разработка
            
-* API
            
-* Лицензии
            
-* Багтрекер
-
-

            Syndie (I2P mirror)
            
-
            Ссылки
            
-
            майка
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            Mirror
-
-
            Mirror 2
-
            Secure Site
-
-
            
-
            Impressum
            
-
-{% elif lang == "cs" %}
-
            Vítejte v síti I2P
            
-
            Stáhnout
            
-
-
-
            Novinky
            
-* Poznámky k vydání
            
-
-* Projektové schůzky
            
-* Plán rozvoje
            
-* Seznam úkolů
            
-
-
            Co je I2P
            
-* FAQ
            
-* Diskuzní fóra (within I2P)
            
-* Projektové odměny
            
-* Zapojte se
            
-* Dotace!
            
-
-* Tým I2P
            
-* Síň slávy
            
-
-
            Dokumentace
            
-* Jak to funguje?
            
-* Technický úvod
            
-* Aplikace
            
-* Papers
            
-
-
            Vývoj
            
-* API
            
-* Licence
            
-* Report a Bug
-
-

            Syndie (I2P mirror)
            
-
            Odkazy
            
-
            T-Shirt
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            Kopie
-
-
            Kopie
-
            Bezpečné stránky
-
-
            
-
            Tiráž
            
-
-{% elif lang == "ar" %}
-
            أهلاً بكم في I2P
            
-
            تحميل
            
-
-
            أخبار
            
-* اصدارات
            
-
-
-* لقاءات
            
-* خطة العمل
            
-* قائمة المهام
            
-
             I2P حول 
            
-* أسئلة متكررة
            
-* المنتديات (within I2P)
            
-* العطاءات
            
-* شاركنا
            
-* ! تبرع
            
-
-* فريق I2P
            
-* ساحة الشهرة
            
-
            التوثيق
            
-* كيف تعمل ؟
            
-* مقدمة تقنية
            
-* تطوير التطبيقات
            
-
            التطوير
            
-* API
            
-* التراخيص
            
-* أبلغ عن خلل
-
-

            Syndie (I2P mirror)
            
-
            الروابط
            
-
            التي شيرت
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            نسخة من الموقع
-
-
            2 نسخة من الموقع
-
            الموقع الآمن 
-
-
            
-
            Impressum
            
-
-{% elif lang == "el" %}
-
            Καλώς Ήρθατε στο I2P
            
-
            Λήψη
            
-
-
            Νέα
            
-* Ανακοινώσεις
            
-
-
-* Συναντήσεις
            
-* Σχέδια
            
-* Λίστα Εργασιών
            
-
            Σχετικά με το I2P
            
-* FAQ
            
-* Forums (στο I2P)
            
-* Bounties
            
-* Συμμετοχή
            
-* Δωρεές!
            
-
-* Η ομάδα του I2P
            
-* Hall of Fame
            
-
            Τεκμηρίωση
            
-* Πώς λειτουργεί;
            
-* Τεχνική Εισαγωγή
            
-* Ανάπτυξη Εφαρμογών
            
-* Άρθρα
            
-
            Ανάπτυξη
            
-* API
            
-* Άδειες
            
-* Αναφορά Λαθών
-
-

            Syndie (I2P mirror)
            
-
            Σύνδεσμοι
            
-
            T-Shirt
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            Mirror
-
-
            Mirror 2
-
            Ασφαλής Τοποθεσία
-
-
            
-
            Impressum
            
-
-{% else %}
-
            Welcome to I2P
            
-
            Download
            
-
-
            News
            
-* Announcements
            
-
-
-* Meetings
            
-* Roadmap
            
-* Task list
            
-
            About I2P
            
-* FAQ
            
-* Forums (within I2P)
            
-* Bounties
            
-* Get involved
            
-* Donate!
            
-
-* I2P Team
            
-* Hall of Fame
            
-
            Documentation
            
-* How does it work?
            
-* Tech intro
            
-* App Dev
            
-* Papers
            
-
            Development
            
-* API
            
-* Licenses
            
-* Report a Bug
-
-

            Syndie (I2P mirror)
            
-
            Links
            
-
            T-Shirt
-I2P T-Shirt for Europe
-I2P T-Shirt for North America
-
            
-
            Mirror
-
-
            Mirror 2
-
            Secure Site
-
-
            
-
            Impressum
            
-{% endif %}
diff --git a/www.i2p2/pages/_urlify b/www.i2p2/pages/_urlify
deleted file mode 100644
index a9bdbf3d..00000000
--- a/www.i2p2/pages/_urlify
+++ /dev/null
@@ -1,7 +0,0 @@
-{% macro urlify url, title, suffix %}
-    {% if static %}
-    {{title}}
-    {% else %}
-    {{title}}
-    {% endif %}
-{% endmacro %}
\ No newline at end of file
diff --git a/www.i2p2/pages/api.html b/www.i2p2/pages/api.html
deleted file mode 100644
index 7e59a415..00000000
--- a/www.i2p2/pages/api.html
+++ /dev/null
@@ -1,5 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}API{% endblock %}
-{% block content %}
-See the Index to Technical Documentation.
-{% endblock %}
diff --git a/www.i2p2/pages/bounties.html b/www.i2p2/pages/bounties.html
deleted file mode 100644
index 8c02315c..00000000
--- a/www.i2p2/pages/bounties.html
+++ /dev/null
@@ -1,152 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounties{% endblock %}
-{% block content %}
-
-
            Bounties for I2P
                  
-
            While we always gratefully accept any contributions of code, 
-documentation, and the like, there are other ways to help I2P move 
-forward.  As with any open source project, our goals would be achieved more 
-rapidly if we were able to support all of our contributors to work on 
-I2P full time.  However, as with any open source project, that's not a 
-possibility.  Instead, we are making use of a bounty system, whereby 
-anyone can get support for working on something that people want 
-implemented, and people who want to contribute to I2P can be assured that 
-their support goes to what they care about.
            
-
-
            We are also keeping open the ability for people who want to support I2P 
-but don't have strong feelings about the bounties available.  Those people
-can simply put their trust in the I2P team to do what we feel is best by
-donating to a catch-all general fund that will be used as deemed 
-necessary - allocated to various bounties, covering incidentals (hosting, 
-etc), and the like.
            
-
-
            Current bounties
            
-
-
- 
- 
-  
-  
-  
-  
-  
- 
- 
-  
-  
-  
-  
-  
- 
- 
-  
-  
-  
-  
-  
-  
- 
-  
-  
-  
-  
-  
- 
- 
-  
-  
-  
-  
-  
- 
- 
-  
-  
-  
-  
-  
- 
- 
-  
-  
-  
-  
-  
- 
- 
-  
-  
-  
-  
-  
- 
- 
            Name
            Status
            Judge
            Dev *
            Bounty
            Frost for I2P datastorage
            Proposal in development
            echelon
            [vacant]
            €50 EUR
            Eepsites served out of I2P datastorage
            Proposal in development
            echelon
            [vacant]
            €65 EUR and 2 BTC
            Backporting Phex code onto I2PHex
            Proposal in development
            Arne Bab
            [vacant]
            €100 EUR
            make I2P IPv6 native
            Proposal in development
            Amiga4000
            [vacant]
            €100 EUR and 50BTC
            I2P package in Debian and Ubuntu mirrors
            Proposal in development
            h2ik
            [vacant]
            €113 EUR
            Bitcoin client for I2P
            Done, phase of verification
            psychonaut
            giv
            €30 EUR and 118,34BTC
            Unit tests and Multi-router Simulation
            Partly done, partly in work, partly still open
            anonymous
            str4d,hottuna,zzz,sponge,dg
            3000 €, of which 700 € already paid for done jobs
            Syndie
            Proposal in development
            I2P team
            [vacant]
            50 BTC
            
-
-
            Hold bounties, set on hold due to jrandom AWOL and missing funding
            
-
-
- 
- 
-  
-  
-  
-  
-  
- 
-
            Name
            Status
            Judge
            Dev *
            Bounty
            Bundling bounties
            Proposed
            jrandom
            [vacant]
            $0 USD each, or $0 for all
            
-
-
            Claimed bounties
            
-
-
- 
- 
-  
-  
-  
- 
- 
-   
-   
-   
-  
- 
-  
-  
-  
- 
- 
-  
-  
-  
- 
- 
-  
-  
-  
- 
- 
-  
-  
-  
- 
- 
-  
-  
-  
- 
- 
-  
-  
-  
- 
- 
-  
-  
-  
- 
-
            Name
            Status
            Dev team*
            Setting up a SILC server
            withdrawn and bounty divided between ReturningNovice and the general fund
            An Anonymous Secret Society, society@mail.i2p
            arabic translation
            both parts were taken by hamada for 100 BTC
            hamada
            Datastore over I2P
            CLAIMED for 700 €
            duck, smeghead
              
            translation into Russian
            claimed for $230 USD sponsored by russian sponsor
            4get
            Swarming file transfer
            CLAIMED for €250 EUR
            duck, ragnarok, dinoman, connelly, drwoo
            Streaming library window size
            Claimed (archived link)
            jrandom
            IRC connect time monitor
            		CLAIMED for $10 USD
            hypercubus
            Unit tests (part 1)
            		CLAIMED for $300 USD
            Comwiz
            GCJ support
            Claimed
            jrandom
            
-
-
-
            * Dev lists anyone who may already be working on the bounty - collaboration is preferred, so if you're interested in working on it, please contact one of the people listed!
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/bounty_arabic.html b/www.i2p2/pages/bounty_arabic.html
deleted file mode 100644
index 448f9002..00000000
--- a/www.i2p2/pages/bounty_arabic.html
+++ /dev/null
@@ -1,36 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty Arabic translation of webpage and router console{% endblock %}
-{% block content %}
            To improve I2P usage and attract more people
-into I2P echelon set out this bounty for translation
-of the I2P web page and I2P router console into Arabic.
-
            
-
            
-This bounty is set into 2 subparts:
-
            
-Part 1 is translation of the webpage.   
            
-
            
-
            
-For collecting the bounty of 20 BTC you need to translate the following pages:
            
-http://www.i2p2.de/index.html
            
-http://www.i2p2.de/download.html
            
-http://www.i2p2.de/intro.html       
            
-http://www.i2p2.de/faq.html             
            
-http://www.i2p2.de/bounties.html            
            
-http://www.i2p2.de/getinvolved.html                         
            
-http://www.i2p2.de/donate.html                                  
            
-This job was done by hamada and the bounty of 20 BTC was paid to hamada.
            
-
            
-
            
-Part 2 is the translation of the router console. The router console was
-partly translated and the bounty of 80 BTC was paid to hamada.
-
            
-
            
-Judge is echelon.
-
            
-
            
-Note:
-
-
            bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for this translation bounty!
            
-{% endblock %}
diff --git a/www.i2p2/pages/bounty_btcclient.html b/www.i2p2/pages/bounty_btcclient.html
deleted file mode 100644
index 52318a96..00000000
--- a/www.i2p2/pages/bounty_btcclient.html
+++ /dev/null
@@ -1,20 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty creating a I2P native Bitcoin client {% endblock %}
-{% block content %}
            For a future of I2P and attract more people
-into I2P this bounty is to create a I2P native Bitcoin client. 
-It should integrate with other client via the I2P network and via gateways to
-the existant bitcoin network.
-
            
-Judge is psychonaut who donated the first 30 € to this bounty.
-
            
-
            
-Note:
-To claim the bounty the author must not be paid by other organizations or teams 
-for this work (e.g. GSoC students are not valid).
            
-
-
-
            Note 2: bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for the BTC I2P native client bounty!
            
-{% endblock %}
-                                             
diff --git a/www.i2p2/pages/bounty_debpack.html b/www.i2p2/pages/bounty_debpack.html
deleted file mode 100644
index 4d25029b..00000000
--- a/www.i2p2/pages/bounty_debpack.html
+++ /dev/null
@@ -1,22 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty I2P package in Debian and Ubuntu mirrors{% endblock %}
-{% block content %}
            For the future of I2P and in order to attract more people
-to I2P, this bounty was set for including an I2P package into the Ubuntu and Debian 
-archive mirrors.
-To claim this bounty, the I2P router package needs to be available from
-Ubuntu and Debian archive mirrors and Debian bug 
-448638 
-needs to be closed successfully.
-
            
-
            
-
            
-Note:
-To claim the bounty, the author must not be paid by other organizations or teams 
-for this work (e.g. GSoC students are not permitted to claim it).
            
-
-
-
            Note 2: Bounty amounts can be increased by further donations. Do
-you think these are important? Make a donation, 
-marking the amount for the I2P Ubuntu/Debian package bounty!
            
-{% endblock %}
-                                             
diff --git a/www.i2p2/pages/bounty_i2phex.html b/www.i2p2/pages/bounty_i2phex.html
deleted file mode 100644
index 80198738..00000000
--- a/www.i2p2/pages/bounty_i2phex.html
+++ /dev/null
@@ -1,15 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty I2PHex code implementation{% endblock %}
-{% block content %}
            To improve I2P usage and attract more people
-into I2PHex P2P ArneBab setout the bounty for implementing actual
-Phex code onto I2PHex.
-
            
-
            
-
            
-Note:
-
-
            bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for the i2phex code implementation bounty!
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/bounty_ipv6.html b/www.i2p2/pages/bounty_ipv6.html
deleted file mode 100644
index 064a7e04..00000000
--- a/www.i2p2/pages/bounty_ipv6.html
+++ /dev/null
@@ -1,20 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty I2P IPv6 native{% endblock %}
-{% block content %}
            For a future of I2P and attract more people
-into I2P I withdrawal the vuze bounty and offer a IPv6 bounty.
-To claim this bounty, the I2P router needs to run full on native
-IPv6 connections like it does on IPv4.
-
            
-
            
-
            
-Note:
-For bounties to be declared done and paid, we need the plugin AND the source.
-Source and code need to be licensed under a free license (free to change and 
-free to distribute). To claim the bounty the author must not be paid by other
-organizations or teams for this work (e.g. GSoC students are not valid).
            
-
-
-
            Note 2: bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for the native IPv6 I2P bounty!
            
-{% endblock %}
diff --git a/www.i2p2/pages/bounty_rutrans.html b/www.i2p2/pages/bounty_rutrans.html
deleted file mode 100644
index 2be64c47..00000000
--- a/www.i2p2/pages/bounty_rutrans.html
+++ /dev/null
@@ -1,41 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty russian translation of webpage and router console{% endblock %}
-{% block content %}
            To improve I2P usage and attract more people
-into I2P a anonymous donator set out the bounty for translation
-of the I2P web page and I2P router console into russian language.
-
            
-
            
-This bounty is set into 2 subparts:
-
            
-Part 1 is translation of the webpage.   
            
-
            
-
            
-For collecting the bounty of $115 USD you need to translate the following pages:
            
-http://www.i2p2.de/index.html
            
-http://www.i2p2.de/download.html
            
-http://www.i2p2.de/intro.html       
            
-http://www.i2p2.de/faq.html             
            
-http://www.i2p2.de/bounties.html            
            
-http://www.i2p2.de/bounty_datastore             
            
-http://www.i2p2.de/bounty_i2phex                    
            
-http://www.i2p2.de/bounty_vuzeplugin                    
            
-http://www.i2p2.de/getinvolved.html                         
            
-http://www.i2p2.de/donate.html                                  
            
-
-
            
-
            
-Part 2 is the translation of the router console. The whole router console needs
-to be translated to collect the bounty of $115 USD.
-
            
-
            
-Judge is the russian donor.
-
            
-russian short version of this page available.
            
-
            
-
            
-Note:
-
-
            bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for this translation bounty!
            
-{% endblock %}
diff --git a/www.i2p2/pages/bounty_silc.html b/www.i2p2/pages/bounty_silc.html
deleted file mode 100644
index 7989923c..00000000
--- a/www.i2p2/pages/bounty_silc.html
+++ /dev/null
@@ -1,28 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty migrate I2P IRC to SILC {% endblock %}
-{% block content %}
-
-
            For a future of I2P and attract more people
-into I2P this bounty is to setup and host a I2P SILC server.   
-This will allow people to send files over their messaging servers and have intrinsic security built into the protocol.
-Judge is An Anonymous Secret Society, society@mail.i2p.
-
            
-
            
-A silc server needs to be set up and run for at least 3 month time to get payed. 
-A second server should be set up, to.
-
            
-
            
-Bounty was withdrawn and money donated to returningnovice and general fund.
-
            
-
            
-
            
-Note:
-To claim the bounty the author must not be paid by other organizations or teams 
-for this work (e.g. GSoC students are not valid).
            
-
-
-
            Note 2: bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for the I2P silc server bounty!
            
-{% endblock %}
-                                             
diff --git a/www.i2p2/pages/bounty_syndie2012.html b/www.i2p2/pages/bounty_syndie2012.html
deleted file mode 100644
index 6908bf02..00000000
--- a/www.i2p2/pages/bounty_syndie2012.html
+++ /dev/null
@@ -1,32 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Syndie development{% endblock %}
-{% block content %}
-
-
            Beside of I2P we want to encourage users
-to care more about anonymity and security. As I2P is a low 
-latency network with its natural limits, the software SYNDIE
-can overcome some of these limits and provide better anonymity
-for people who really need it. 
            
-
            
-For our bad sake the syndie project is out of development for 
-quite a long time yet (5 years). To get a fresh and new built 
-with needed bugfixes we set out this bounty. Also syndie needs
-some enhancements and a better GUI for users to work with it.
-Current bounty sum is 50 Bitcoin.
-
            
-
            
-The latest syndie coding rallye did improve the situation of the
-synide package dramatically. A new syndie package with bugfixes
-was created and made available on different webpages.
-As of this work been done, the bounty sum was reduced and
-the withdrawn money moved to the IPv6 bounty.
-
            
-
            
-Note:
-
-
            bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for the syndie development bounty!
            
-
-{% endblock %}
-                                                          
diff --git a/www.i2p2/pages/bounty_unittests.html b/www.i2p2/pages/bounty_unittests.html
deleted file mode 100644
index 1ae7cb83..00000000
--- a/www.i2p2/pages/bounty_unittests.html
+++ /dev/null
@@ -1,116 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Bounty unittests{% endblock %}
-{% block content %}
-
-
            To improve I2P's maintainability, we want to have a solid set of
-automated unit tests for the critical code.  While we do have some
-unit tests at the moment, they are ad-hoc and partly unfinished.  
-This bounty is for someone to check the existing tests and move over
-old ones to jUnit, automate their execution, extend them to provide 
-better code coverage, and publish the report online.  Its a massive 
-effort, but can be broken down into phases, listed below (phase 2 
-must occur first, but further phases may happen in any order).
-As this needs some reading of code, it is the best start point for
-new devs to get a good overview of I2P code and coding. A good job
-for college students, interns or anyone who is just interested.
-
            
-
            
-Take care! Jobs and bounties shuffled a bit!
-Phase 6,7 and 8 are still open!
-
            
-
            
-
-
-
            Phase 1: CI jenkins and IRC bot
            
-Bounty: 500 € server runs and this section is blocked
            
-
-
            
-To collect this bounty, a continuous integration server (Jenkins,
-old name was Hudson) must be set up and a connected IRC bot needs 
-to set up in the channel #i2p-dev on IRC2p network to print out
-results of build tests.
            
-The server needs to be run long term.
-
              
-
            
-
-
            Phase 2: Check existing SDK tests 
            
-Bounty: 150 € paid to str4d 
            
-
-
            
-To collect this bounty, the existing SDK tests must be checked 
-and made to work again. The need to be integrated into the ant 
-build scripts ("ant test"), and tied in with a code coverage tool (e.g. 
-Clover).  The ant script
-must be capable of generating test status results as a web page, 
-which will be published online.
-
            
-
            
-
-
            Phase 3: SDK test coverage
            
-Bounty: 200 € paid to unittests dev team
            
-
-
            
-To collect this bounty, the automated unit tests of the SDK 
-(i2p/core/java/src) must work again.
-
            
-
            
-
-
            Phase 4: Router test migration
            
-Bounty: 150 € paid to str4d
            
-
-
            
-As with phase 2, the existing unit tests for the router must be
-moved over to the automated system.
-
            
-
            
-
-
            Phase 5: Router test coverage
            
-Bounty: 200 € paid to unittests dev team
            
-
-
            
-To collect this bounty, the automated unit tests of the router 
-(i2p/router/java/src) must work again.
-
            
-
            
-
-
            Phase 6: Streaming lib tests
            
-Bounty: 300 €
            
-
-
-
            
-To collect this bounty, a new set of unit tests must meet a 
-measured code coverage of 90% of the streaming lib 
-(i2p/apps/ministreaming/ and i2p/apps/streaming/).
-
            
-
            
-
-
            Phase 7: Unit tests coverage
            
-Bounty: 500 €
            
-
-
             
-To collect this bounty, all above unit tests must meet the 100%
-coverage marker (except for log statements).
-
            
-
            
-
-
-
            Phase 8: MultiRouter simulation
            
-Bounty: 1000 € will be split in more sub-tasks
            
-
-
            
-To collect this bounty, the existing in-memory multi-router
-simulation must be checked, made work again and extend to simulate
-lots of routers in memory on a single machine. This bounty will
-be split in more fine grained subworks.
-
            
-
            
-
-
            
-Judge on all these works is the donor and donor decides if a phase is
-called succesfull done and money can be paid.
-
            
-
-
            Note: bounty amounts may be increased by further donations.  Do
-you think these are important?  Add in your donation, 
-marking the amount for the unit test bounty!
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/clt.html b/www.i2p2/pages/clt.html
deleted file mode 100644
index 0532fdee..00000000
--- a/www.i2p2/pages/clt.html
+++ /dev/null
@@ -1,13 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P at CLT and PetCon 2009.1{% endblock %}
-{% block content %}
            Members of I2P will held a talk at CLT and PetCon 2009.1
            
-Two members of the I2P team will be at two forthcoming Linux day and security convention. 
-On 14th march of 2009 there will be a short talk about general introduction to I2P at the Chemnitz Linux Tag 2009 hold by echelon.
            
-Echelon and some other members of the I2P family will attend to the Linux meeting the whole two days (Saturday and Sunday) and will be recognizable as I2P family members. Meet them, ask them your questions, show them your props!
            
-Show your support!
            
-
            
-Just 10 days later the Privacy and Data Security convention in Dresden will take place.
            
-Again, echelon will attend this event and hold a short talk about general introduction to I2P. Another talk about the profiling by the I2P clients will be held.
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/configuration.html b/www.i2p2/pages/configuration.html
deleted file mode 100644
index ed3b75c1..00000000
--- a/www.i2p2/pages/configuration.html
+++ /dev/null
@@ -1,105 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Configuration File Specification{% endblock %}
-{% block content %}
-Updated September 2012, current as of router version 0.9.2
-
-
-
            Overview
            
-
            
-This page provides a general specification of I2P configuration files,
-used by the router and various applications.
-It also gives an overview of the information contained in the various files,
-and links to detailed documentation where available.
-
            
-
-
-
            General Format
            
-
            
-An I2P configuration file is formatted as specified in
-Java Properties
-with the following exceptions:
-
              
-
            • Encoding must be UTF-8
-
            • Does not use or recognize any escapes, including '\', so lines may not be continued
-
            • '#' or ';' starts a comment, but '!' does not
-
            • '#' starts a comment in any position but ';' must be in column 1 to start a comment
-
            • Leading and trailing whitespace is not trimmed on keys
-
            • Leading and trailing whitespace is trimmed on values
-
            • '=' is the only key-termination character (not ':' or whitespace)
-
            • Lines without '=' are ignored. It does not store the key with a value of ""
-
            • As there are no escapes,
-    keys may not contain '#', '=', or '\n', or start with ';'
-
            • As there are no escapes,
-    values may not contain '#' or '\n', or start or end with '\r' or whitespace
-
            
-
            
-The file need not be sorted, but most applications do sort by key when
-writing to the file, for ease of reading and manual editing.
-
            
-Reads and writes are implemented in
-DataHelper loadProps() and storeProps().
-Note that the file format is significantly different than the
-serialized format for I2P protocols specified in
-Mapping.
-
            
-
-
            Core library and router
            
-
-
            Clients (clients.config)
            
-
            
-Configured via /configclients in the router console.
-
            
-
-
            Logger (logger.config)
            
-
            
-Configured via /configlogging in the router console.
-
            
-
-
            Individual Plugin (xxx/plugin.config)
            
-
            
-See the plugin specification.
-
            
-
-
            Plugins (plugins.config)
            
-
            
-Enable/disable for each installed plugin..
-
            
-
-
            Router (router.config)
            
-
            
-Configured via /configadvanced in the router console.
-
            
-
-
            Applications
            
-
-
            Addressbook (addressbook/config.txt)
            
-
            
-See documentation in SusiDNS.
-
            
-
-
            I2PSnark (i2psnark.config)
            
-
            
-Configured via the application gui.
-
            
-
-
            I2PTunnel (i2ptunnel.config)
            
-
            
-Configured via the /i2ptunnel application in the router console.
-
            
-
-
            Router Console
            
-
            
-The router console uses the router.config file.
-
            
-
-
            SusiMail (susimail.config)
            
-
            
-See post on zzz.i2p.
-
            
-
-
            Systray (systray.config)
            
-
            
-TBD
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/datagrams.html b/www.i2p2/pages/datagrams.html
deleted file mode 100644
index 6af812b0..00000000
--- a/www.i2p2/pages/datagrams.html
+++ /dev/null
@@ -1,172 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Datagram Specification{% endblock %}
-{% block content %}
-
-Updated August 2010, current as of router version 0.8
-
-
            Datagram Overview
            
-
            Datagrams build upon the base I2CP to provide authenticated
-and repliable messages in a standard format.  This lets applications reliably read
-the "from" address out of a datagram and know that the address really sent the
-message.  This is necessary for some applications since the base I2P message is
-completely raw - it has no "from" address (unlike IP packets).  In addition, the
-message and sender are authenticated by signing the payload.
            
-
            
-Datagrams, like streaming library packets,
-are an application-level construct.
-These protocols are independent of the low-level transports;
-the protocols are converted to I2NP messages by the router, and
-either protocol may be carried by either transport.
-
            
-
-
            Application Guide
            
-
            Applications written in Java may use the 
-datagram API,
-while applications in other languages 
-can use SAM's datagram support.
-There is also limited support in i2ptunnel in the SOCKS proxy,
-the 'streamr' tunnel types, and udpTunnel classes.
-
            
-
-
            Datagram Length
            
-
            
-The application designer should carefully consider the tradeoff of repliable vs. non-repliable
-datagrams. Also, the datagram size will affect reliability, due to tunnel fragmentation into 1KB
-tunnel messages. The more message fragments, the more likely that one of them will be dropped
-by an intermediate hop. Messages larger than a few KB are not recommended.
-
            
-
            
-Also note that the various overheads added by lower layers, in particular asymmetric
-ElGamal/AES, place a large burden on intermittent messages
-such as used by a Kademlia-over-UDP application. The implementations are currently tuned
-for frequent traffic using the streaming library. There are a high number
-of session tags delivered, and a short session tag lifetime, for example.
-There are currently no configuration parameters available within I2CP to tune
-the ElGamal Session Tag parameters.
-
            
-
-
            I2CP Protocol Number and Ports
            
-
            
-The standard I2CP protocol number for datagrams is 17. Applications may or may not choose to set the
-protocol in the I2CP header. It is not set by default.
-It must be set to demultiplex datagram and streaming traffic received on the same Destination.
-
            
-
            
-As datagrams are not connection-oriented, the application may require
-port numbers to correlate datagrams with particular peers or communications sessions,
-as is traditional with UDP over IP.
-Applications may add 'from' and 'to' ports to the I2CP (gzip) header as described in
-the I2CP page.
-
            
-
            
-There is no method within the datagram API to specify whether it is non-repliable (raw)
-or repliable. The application should be designed to expect the appropriate type.
-The I2CP protocol number or port could also be used by the application to
-indicate datagram type.
-
            
-
            
-The protocols and ports may be set in I2CP's
-I2PSession API,
-as implemented in
-I2PSessionMuxedImpl.
-
            
-
-
            Data Integrity
            
-Data integrity is assured by the gzip CRC-32 checksum implemented in
-the I2CP layer.
-There is no checksum field in the datagram protocol.
-
-
            Packet Encapsulation
            
-Each datagram is sent through I2P as a single message (or as an individual clove in a
-Garlic Message).
-Message encapsulation is implemented in the underlying
-I2CP,
-I2NP, and
-tunnel message layers.
-There is no packet delimiter mechanism or length field in the datagram protocol.
-
-
-
            Specification
            
-
-
            Non-Repliable Datagrams
            
-Non-repliable datagrams have no 'from' address and are not authenticated.
-They are also called "raw" datagrams.
-Strictly speaking, they are not "datagrams" at all, they are just raw data.
-They are not handled by the datagram API.
-However, SAM and the I2PTunnel classes support "raw datagrams".
-
-
            Format
            
-
            -+----+----+----+----+----//
-| payload...
-+----+----+----+----+----//
-
-
-Length: 0 - unlimited (see notes)
-
            
-
-
            Notes
            
-The practical length is limited by lower layers of protocols - the
-tunnel message spec
-limits messages to about 61.2 KB and the
-transports
-currently limit messages to about 32 KB, although this may be raised in the future.
-
-
-
            Repliable Datagrams
            
-Repliable datagrams contain a 'from' address and a signature. These add 427 bytes of overhead.
-
            Format
            
-
            -+----+----+----+----+----+----+----+----+
-| from                                  |
-+                                       +
-|                                       |
-~                                       ~
-~                                       ~
-|                                       |
-+                                       +
-|                                       |
-|                                       |
-+----+----+----+----+----+----+----+----+
-| signature                             |
-+                                       +
-|                                       |
-+                                       +
-|                                       |
-+                                       +
-|                                       |
-+                                       +
-|                                       |
-+----+----+----+----+----+----+----+----+
-| payload...
-+----+----+----+----//
-
-
-
-from      :: a Destination
-               length: 387+ bytes
-               The originator and signer of the datagram
-
-signature :: a Signature
-             length: 40 bytes
-             The DSA signature of the SHA256 hash of the payload, which may be verified by the
-             DSA signing public key of the 'from' Destination
-
-payload ::  The data
-            Length: 0 - 32 KB (see notes)
-
-Total length: Payload length + 427+
-
-
-
            
-
-
            Notes
            
-The practical length is limited by lower layers of protocols - the
-transports
-currently limit messages to about 32 KB, so the data length here is limited to about
-31.5 KB.
-
-
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/debian.html b/www.i2p2/pages/debian.html
deleted file mode 100644
index 71a19ba6..00000000
--- a/www.i2p2/pages/debian.html
+++ /dev/null
@@ -1,112 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Debian/Ubuntu{% endblock %}
-{% block content %}
-
            Debian I2P Packages
            
-
-The packages hosted on the I2P Launchpad site
-have been tested and should work on x86/x86_64 platforms running
-
-The I2P packages may work on systems not listed above. Please report any issues with these packages on Trac at http://trac.i2p2.de.
-
              
-  
            • Option 1: Recent versions of Ubuntu and its derivatives (Try this if you're not using Debian)
              • 
-  
            • Option 2: Debian (including systems based on Debian and older versions of Ubuntu)
              • 
-  
            • Option 3: Non-Linux (and possibly Non-x86 architectures)
              • 
-
            
-
            Instructions for Ubuntu Lucid Lynx (and newer) and derivatives like Linux Mint & Trisquel
            
-
            Adding the PPA via the command line and installing I2P
            
-
              
-  
            1. Open a terminal and enter: 
              
-        sudo apt-add-repository ppa:i2p-maintainers/i2p
              
-This command will add the PPA to /etc/apt/sources.list.d and fetch the
-gpg key that the repository has been signed with. The GPG key ensures
-that the packages have not been tampered with since being built.
              2. 
-  
            2. Notify your package manager of the new PPA by entering
              
-        sudo apt-get update
              
-This command will retrieve the latest list of software from each
-repository that is enabled on your system, including the I2P PPA that
-was added with the earlier command.
              3. 
-  
            3. You are now ready to install I2P! 
              
-        sudo apt-get install i2p
              4. 
-
            
-
            Adding the PPA Using Synaptic
            
-
              
-
            1. Open Synaptic (System -> Administration -> Synaptic Package Manager).
              2. 
-
            2. Once Synaptic opens, select Repositories from the Settings menu.
              3. 
-
            3. Click the Other Sources tab and click Add. Paste ppa:i2p-maintainers/i2p into the APT-line field and click Add Source. Click the Close button then Reload.
              4. 
-
            4. In the Quick Filter box, type in i2p and press enter. When i2p is returned in the results list, right click i2p and select Mark for Installation. After doing so you may see a Mark additional required changes? popup. If so, click Mark then Apply.
              5. 
-
             
-
-After the installation process completes you can move on to the next
-part of starting I2P and configuring it for your system.
-
-
            Instructions for Debian Lenny and newer
            
-The steps below should be performed with root access (i.e., switching
-user to root with "su" or by prefixing each command with "sudo").
-
              
-  
            1. Add the GPG key that signs the repository with the following command:
              
-    apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EB2CC88B
              
-You'll have output like the following if the command was successful: 
              
-    
              2. 
-  
            2. For Debian Oldstable (Lenny) and Stable (Squeeze): Add the following entries to /etc/apt/sources.list.d/i2p.list
              
-        deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu natty main 
              
-    deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu natty main 
              
-
              
-For Debian Testing (Wheezy) or Unstable (Sid), use the following: 
              
-        deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main 
              
-    deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu precise main 
              3. 
-  
            3. Notify your package manager of the new PPA by entering
              
-        apt-get update
              
-This command will retrieve the latest list of software from every
-repository enabled on your system, including the I2P PPA added in step
-1.
              4. 
-  
            4. You are now ready to install I2P! 
              
-        apt-get install i2p
              5. 
-
            
-After the installation process completes you can move on to the next part of starting I2P and configuring it for your system.
-
            Instructions for Non-Linux / Non-x86
            
-The steps below should be performed with root access (i.e., switching
-user to root with "su" or by prefixing each command with "sudo").
            
-
              
-  
            1. Download the i2p-router package from the PPA.
              2. 
-  
            2. Make sure that you have Java installed. Running apt-get install default-jre should be sufficient.
              
-You are now ready to install I2P! 
              
-        dpkg -i i2p-router_*.deb
              3. 
-  
            3. It is recommended to compile jbigi for your system to achieve better performance. Instructions are available here.
              4. 
-
            
-After the installation process completes you can move on to the next part of starting I2P and configuring it for your system.
-
            Post-install work
            
-Using these I2P packages the I2P router can be started in the following
-three ways:
-
              
-  
            • "on demand" using the i2prouter script. Simply run "i2prouter
-start" from a command prompt. (Note: Do not use
-sudo or run it as root!)
              • 
-  
            • "on demand" without the java service wrapper
-(needed on non-Linux/non-x86 systems) by running "i2prouter-nowrapper".
-(Note: Do not
-use sudo or run it as root!)
              • 
-  
            • as a service that automatically runs when your system boots, even
-before logging in. The service can be enabled with "dpkg-reconfigure
-i2p" as root or using sudo. This is the recommended means of operation.
              • 
-
            
-
            When installing for the first time, please remember to adjust
-your NAT/firewall
-if you can. The ports to forward can be found on the 
-	network configuration page in the router console. If guidance with respect to forwarding ports is needed,
-you may portforward.com to be helpful.
-
            
-
            Please review and adjust the bandwidth settings on the
-configuration page,
-as the default settings of 96 KB/s down / 40 KB/s up are fairly conservative.
-
            
-
            
-If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy howto.
            
-{% endblock %}
diff --git a/www.i2p2/pages/download.html b/www.i2p2/pages/download.html
deleted file mode 100644
index 5f90ce50..00000000
--- a/www.i2p2/pages/download.html
+++ /dev/null
@@ -1,160 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Download{% endblock %}
-{% block content %}
-
            Download I2P
            
-
            Dependency
            
-Java Runtime 1.5 or higher.
-(Oracle/Sun Java Version 6,
-OpenJDK 6, or
-IcedTea6
- recommended)
-
            
-Determine your installed Java version here
-or type java -version at your command prompt.
-
            Clean installs
            
-
              
-
            • Windows Graphical installer:
              
-    i2pinstall_0.9.5_windows.exe
-    (SHA256
-d904878f1feb758afb75cae31af52e3504b43b5ff531c060d902145a19eec56e
-    sig)
              
-    Download that file and run it.
-
              • 
-
-
            • Linux / BSD / Solaris Graphical installer:
              
-    i2pinstall_0.9.5.jar
-    (SHA256
-af251596e034b751dc17b73bd35254b94f92d4a3121a6e96479c45c4d846ab30
-    sig)
              
-    Download that file and double-click it (if that works) or
-    type java -jar i2pinstall_0.9.5.jar in a terminal to run the
-    installer.
-    On some platforms you may be able to right-click and select
-    "Open with Java".
              • 
-
-
            • Linux / BSD / Solaris Command line (headless) install:
              
-    Download the graphical installer file above and
-    run java -jar i2pinstall_0.9.5.jar -console from the command line.
-
              • 
-
-
            • Packages for Debian & Ubuntu
              • 
-
-
            • OS X Graphical installer:
              
-    i2pinstall_0.9.5.jar
-    (SHA256
-af251596e034b751dc17b73bd35254b94f92d4a3121a6e96479c45c4d846ab30
-    sig)
              
-    Download that file and double-click it (if that works) or
-    type java -jar i2pinstall_0.9.5.jar in a terminal to run the
-    installer.
-    You may be able to right-click and select
-    "Open with Java".
-
              • 
-
-
            • OS X Command line (headless) install:
              
-    Download the 0.9.5 OSX graphical installer file above and
-    run java -jar i2pinstall_0.9.5.jar -console from the command line.
-
              • 
-
-
            • Source install:
              
-    i2psource_0.9.5.tar.bz2
-    (SHA256
-441eac3cb7f25c03e7711c7d516626dc86ba6ad373145ab802d150848262c7c2
-     sig)
              
-    Alternately, you can fetch the source from monotone.
-    
              
-    Run (tar xjvf i2psource_0.9.5.tar.bz2 ; cd i2p-0.9.5 ; ant pkg) then either
-    run the GUI installer or headless install as above
              • 
-
            
-
-The files are signed by zzz,
-whose key is here.
-
            I2P can also be downloaded from our project pages on Launchpad and Google Code.
            
-
            Post-install work
            
-
-
            After running the installer on windows, simply click on the "Start I2P" button
-which will bring up the router console,
-which has further instructions.
            
-
-
            On Unix-like systems, I2P can be started as a service
-using the "i2prouter" script, located in the directory you selected for I2P.
-Changing to that directory in a console and issuing "sh i2prouter status"
-should tell you the router's status. The arguments "start", "stop" and "restart"
-control the service. The router console
-can be accessed at its usual location.
-For users on OpenSolaris and other systems for which the wrapper (i2psvc) is not supported,
-start the router with "sh runplain.sh" instead.
-
            
-
-
            When installing for the first time, please remember to adjust your NAT/firewall
-if you can, bearing in mind the Internet-facing ports I2P uses,
-described here among other ports.
-If you have successfully opened your port to inbound TCP, also enable inbound TCP on the
-configuration page.
-
            
-
-
            Also, please review and adjust the bandwidth settings on the
-configuration page,
-as the default settings of 96 KBps down / 40 KBps up are fairly slow.
-
            
-
-
            
-If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy howto.
-
            
-
-
            Updates from earlier releases:
            
-
            
-Both automatic and manual upgrades are available for the release.
-
            
-If you are running 0.7.5 or later, your router should detect the
-new release. To upgrade simply click the 'Download Update' button on your router console
-when it appears.
-
            
-Due to a bug in release 0.7.6, those whose first I2P installation was that version
-and have not upgraded manually
-may get a "downloaded version is not greater than current version" error,
-and should use the manual update method below.
-
            
-If you are running 0.7.4 or earlier, please see
-the 0.7.5 release notes
-for important information about how to configure your router to automatically
-receive the release.
-
            
-If you are running 0.6.1.30 or earlier, please see
-instructions
-for important information about how to configure your router to automatically
-receive the release.
-
            
-
-
              
-
            1. If you have reconfigured your router following the instructions, you should see a link on your 
-    router console allowing
-    you to download and install the new release by just clicking on that
-    link.
              2. 
-
            2. Alternately, you can use the manual method specified below.
              3. 
-
            
-
-
            Updates from earlier releases (manual method):
            
-
              
-
            1. Download i2pupdate_0.9.5.zip
-    (SHA256
-d20c3f3845c1f4a4cf734dc69cae7de72ff0874cea1382d03d8ac953c50fb139
-     sig) to your I2P 
-    installation directory and rename as i2pupdate.zip.
-    (alternately, you can get the source as above and run "ant updater", then copy the
-    resulting i2pupdate.zip to your I2P installation directory).  You do 
-    NOT need to unzip that file.
              2. 
-
            2. Click "Restart"
              3. 
-
            3. Grab a cup of coffee and come back in 11 minutes
              4. 
-
            
-
-The file is signed by zzz,
-whose key is here.
-
-
            Previous Releases
            
-Previous releases are available on Google Code
-and Launchpad
-and within the I2P network on echelon.i2p.
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/faq.html b/www.i2p2/pages/faq.html
deleted file mode 100644
index 351fda17..00000000
--- a/www.i2p2/pages/faq.html
+++ /dev/null
@@ -1,646 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}FAQ{% endblock %}
-{% block content %}
-
            I2P - FREQUENTLY ASKED QUESTIONS
            
-
             Index 
            
-
              
-
            1. 
-
              General
              
-
              2. 
-
            2. What systems will I2P run on?
              3. 
-
            3. Whats an "eepsite" and how do I configure my browser so I can use them?
              4. 
-
            4. My router has very few active peers, is this OK?
              5. 
-
            5. What do the Active x/y numbers mean in the router console?
              6. 
-
            6. My active peers / known peers / participating tunnels / connections / bandwidth vary dramatically over time! Is anything wrong?
              7. 
-
            7. Is using an outproxy safe?
              8. 
-
            8. Most of the eepsites within I2P are down?
              9. 
-
            9. What ports does I2P use?
              10. 
-
            10. Why is I2P listening for connections on port 32000?
              11. 
-
            11. I think I found a bug, where can I report it?
              12. 
-
            12. What happened to *.i2p.net? What happened to jrandom? Is I2P dead?
              13. 
-
            13. I have a question!
              14. 
-
            14. 
-
              Setup
              
-
              15. 
-
            15. My router has been up for several minutes and has zero or very few connections
              16. 
-
            16. Why is I2P so slow?
              17. 
-
            17. I'm missing lots of hosts in my addressbook. What are some good subscription links?
              18. 
-
            18. How do I set up my own eepsite?
              19. 
-
            19. Bittorrent / I2PSnark / Azureus I2P Plugin Questions?
              20. 
-
            20. How do I connect to IRC within I2P?
              21. 
-
            21. I can't access regular Internet sites through I2P.
              22. 
-
            22. I can't access https:// or ftp:// sites through I2P.
              23. 
-
            23. Is it possible to use I2P as a SOCKS proxy?
              24. 
-
            24. How do I configure my browser?
              25. 
-
            25. How can I access the web console from my other machines or password protect it?
              26. 
-
            26. How can I use applications from my other machines?
              27. 
-
            27. How do I reseed manually?
              28. 
-
            28. My router is using too much CPU?!?
              29. 
-
            29. 
-
              Misconception
              
-
              30. 
-
            30. How do I access IRC, BitTorrent, or other services on the regular Internet?
              31. 
-
            31. Is my router an "exit node"(outproxy) to the regular Internet? I don't want it to be.
              32. 
-
            32. I am opposed to certain types of content. How do I keep from distributing, storing, or accessing them?
              33. 
-
            33. 
-
              Errors and Their Solutions
              
-
              34. 
-
            34. I'm using FreeBSD and when I start I2P I receive an error about libm.so.4!
              35. 
-
            35. In wrapper.log I see an error stating Protocol family unavailable when I2P is loading
              36. 
-
            
-
            What systems will I2P run on?
-(link)
            
-
            While I2P has been reported to run PCs as meagre as a low-end Pentium II with 64 MB of RAM, you'll have a much better experience on a Pentium III (or better) with 128MB of RAM (or more). A chart comparing the performance of the various JREs can be found at http://trac.i2p2.de/wiki/java, but in short: it's at all possible, use Sun/Oracle Java or OpenJDK.
            
-
            I2P has been tested on Windows, Linux, FreeBSD (see the note below), OSX, and OpenSolaris. There is work underway to bring I2P to the Android platform.
            
-
-
-
            I think I found a bug, where can I report it?
-(link)
            
-
-Here are some places, pick one or more.
-
              
-
            • trac.i2p2.de ticket (preferred method)
              • 
-
            • pastethis.i2p and follow up on IRC in #i2p
              • 
-
            • Discuss with the developers on IRC in #i2p-dev
            
-
-
            
-Please include relevant information from the router logs and wrapper logs.
-
            
-
-
            I'm missing lots of hosts in my addressbook. What are some good subscription links?
-(link)
            
-
            
-The default subscription is to http://www.i2p2.i2p/hosts.txt which is updated rarely.
-If you don't have another subscription, you may often have to use "jump" links which
-is annoying.
            
-
            Here are some other public addressbook subscription links. You may wish to add one or two
-to your susidns subscription list.
-You don't need to add all of them, as they sync with each other periodically.
-The links using a cgi-bin application employ various strategies to minimize
-the number of duplicate addresses delivered, so they should be more efficient.
-Note that subscribing to a hosts.txt service is an act of "trust", as a malicious
-subscription could give you incorrect addresses. So think about whether you
-want to trust any of these.
-The operators of these services may have various policies for listing hosts.
-Presence on this list does not imply endorsement.
            
-
            
-
            
-
-
-
            What happened to *.i2p.net? What happened to jrandom? Is I2P dead?
-(link)
            
-
            Jrandom was the lead developer of I2P and
-Syndie for several years.
-We do not know if or when jrandom will return.
-The *.i2p.net domains were left in a non-functioning state after a power
-outage at the hosting company.
            
-
            See this page for jrandom's parting message and additional information
- on the migration of *.i2p.net to this website.
            
-
            I2P remains in active development.
            
-
-
            My router is using too much CPU?!?
-(link)
            
-
            
-There are many possible causes of high CPU usage. Here is a checklist:
-
              
-
            • 
-Try to use either OpenJDK or Sun/Oracle Java if it's available for your system. You can check 
-which version of java you have installed by typing java -version at a 
-command/shell prompt. Performance tends to suffer with other implementations of java.
-
              • 
-
            • 
-Are you running a BitTorrent client over I2P? Try reducing the number of torrents, the bandwidth limits,
-or try turning it off completely to see if that helps.
-
              • 
-
            • 
-Are your bandwidth limits set too high? It is possible that too much traffic is going through your
-I2P router and it is overloaded. Try reducing the setting for share bandwidth percentage on the configuration page.
-
              • 
-
            • 
-Make sure that you're running the latest version of I2P to get the benefits of increased performance and bug fixes.
-
              • 
-
            • 
-Has enough memory been set aside for use by I2P? Look at the memory graph on the graphs page to see
-if the memory usage is "pegged"—the JVM is spending most of its time in
-garbage collection. Increase the setting wrapper.java.maxmemory in wrapper.config.
-
              • 
-
            • 
-Is the CPU usage simply higher than you would like, or is it pegged at 100% for a long time?
-If it's pegged, this could be a bug. Look in the logs for clues.
-
              • 
-
            • 
-You may be using the Java-based BigInteger library instead of the native version,
-especially if you are running on a new or unusual OS or hardware (OpenSolaris, mipsel, etc.).
-See the jbigi page for instructions on
-diagnosing, building, and testing methods.
-
              • 
-
            • 
-If your native jbigi library is working fine, the biggest user of
-CPU may be routing traffic for participating tunnels. This uses CPU
-because at each hop a layer of encryption must be decoded.
-You can limit participating traffic in two ways - by reducing the
-share bandwidth on
-confignet.jsp,
-or by setting router.maxParticipatingTunnels=nnn on
-configadvanced.jsp.
-
            
-
-
            I am opposed to certain types of content. How do I keep from distributing, storing, or accessing them?
-(link)
            
-
            
-Hmm. I2P is an anonymous network, so that's a tricky one.
-I2P is designed to withstand censorship, providing a means for everyone to communicate freely. 
-The best way to keep your PC free of (encrypted) traffic that you dislike is to not use I2P.
-Freedom of speech has some costs.
-But let's address your question in three parts:
            
-
              
-
            • Distribution - All traffic on I2P is encrypted in multiple layers. You don't know
-a message's contents, source, or destination.
-All traffic you route is internal to the I2P network, you are not an exit node (outproxy).
-Your only alternative is to refuse to route
-any traffic, by setting your share bandwidth or maximum participating tunnels to 0 (see above).
-It would be nice if you didn't do this, you should help the network by routing traffic for others.
-Over 95% of users route traffic for others.
-
            • Storage - I2P does not do distributed storage of content. You must be thinking of
-Freenet.
-Nobody's content is being stored on your computer by running I2P.
-
              • 
-
            • Access - If there are some eepsites you don't like, don't go there.
-Or, use a blocking proxy like Privoxy or some type of "net nanny".
-
            
-
-
-
            My active peers / known peers / participating tunnels / connections / bandwidth vary dramatically over time! Is anything wrong?
-(link)
            
-
            
-No. This is normal.
-All routers adjust dynamically to changing network conditions and demands.
-
            
-
-
            My router has been up for several minutes and has zero or very few connections
-(link)
            
-
            
-   You may need to reseed your I2P router. With recent versions of I2P you can go to http://localhost:7657/configreseed and click the Save Changes and Reseed Now button. If this method doesn't work—or you're using a very old version—you may need to reseed manually.
            
-   
            
-   The reseed URL changed a few years ago. If this is your first install and you have installed
-   an old (0.6.1.30 or earlier) release, or
-   you have not run I2P in a long time, you must change the URL and then
-   click "Reseed" on the console to find other routers.
-   After your router is running,
-   on configadvanced.jsp,
-   add the line i2p.reseedURL=http://netdb.i2p2.de/
-   OR i2p.reseedURL=http://i2pdb.tin0.de/netDb/ (either should work),
-   then click "Apply", then click the "reseed" link on the left.
-
            
-   This works if you are running 0.6.1.27 or later.
-   If you are running release 0.6.1.31 or later, you probably don't need to do this.
-   If you are running release 0.6.1.26 or earlier, either follow the
-   manual reseed instructions below
-   or install the latest release.
-   Possible alternate method - add
-   wrapper.java.additional.5=-Di2p.reseedURL=http://netdb.i2p2.de/
-   to wrapper.config, shutdown the router completely, then start again, then click "reseed".
-   Let us know if this works.
-
            
-
            ...but you *really* should upgrade to the latest version.
            
-
-
            My router has very few active peers, is this OK?
-(link)
            
-
            
-If your router has 10 or more active peers, everything is fine. Changes in releases 0.6.1.31 and 0.6.1.32 improved the
-efficiency of the router and effectively reduced the number of active peers.
-The router should maintain connections to a few peers at all times.
-The best way to stay "better-connected" to the network is to share more bandwidth.
-
            
-
-
            Is my router an "exit node" to the regular Internet? I don't want it to be.
-(link)
            
-
            
-   No. Unlike Tor,
-   "exit nodes" or "outproxies" are not an inherent part of the network.
-   Only volunteers who set up and run separate applications will relay traffic to the regular Internet.
-   There are very, very few of these.
-
            
-
-
            I can't access regular Internet sites through I2P.
-(link)
            
-
            
-   See above. There are very few HTTP "outproxies", they are not an inherent part of the network,
-   and they may not be up.
-   In addition, the old outproxies squid.i2p, true.i2p, and krabs.i2p have vanished.
-   The only outproxy at the moment is false.i2p.
-   To use it, edit your i2ptunnel settings for eepProxy
-   and set your outproxy list to 'false.i2p' (only).
-   Then stop and restart the eepProxy.
-   If it doesn't work, the outproxy is not up. It is not I2P's fault.
-   If your primary reason to use an anonymous network is to anonymously access sites
-   on the regular Internet, you should probably try Tor.
-
            
-
-
            I can't access https:// or ftp:// sites through I2P.
-(link)
            
-
            
-   Within I2P, there is no need for HTTPS, as all traffic is encrypted end-to-end.
-   FTP is not supported for technical reasons.
-
            
-   There are no FTP "outproxies" to the Internet—it may not even be possible to set up one.
-   Any other kind of outproxy may work if it's set up with a standard tunnel. 
-   If you would like to set up some type of outproxy, carefully research the potential risks.
-   The I2P community may or may not be able to help with the technical aspects, feel free to ask.
            
-   
            As explained several times above, any existing outproxy isn't a core part of the network.
-   They are services run by individuals and they may or may not
-   be operational at any given time.
-   
-
            
-   
            Update: Thanks to the work of h2ik, there is an https outproxy available for use via I2P. Starting with I2P 0.8.4 the tunnel is configured out of the box.
            
-   In case the https outproxy is not available in your version of I2P, you can add it easily by doing the following:
            
-
            1. Open i2p tunnel manager. Scroll down to the bottom.
-
            2. Choose CONNECT from New Client Tunnel dropdown list, click Create
-
            3. In the new page, name and describe your new https tunnel as you like.
-		The Access Point is your local port for the new https proxy recommended port's 4445.
-		Outproxy should be the outproxy's .i2p address which supports https. 
-		 See this forum post of h2ik's for the address. 
-		Make sure Shared Client, Delay Connect, AutoStart are checked.
-		Other options should be left at the defaults. Click Save. In tunnel manger, click the Start button next to your new tunnel.
-
            4. In firefox, click through Tools>Options>Advanced>Network>Setting.
-		Untick Use this proxy for all protocol, set SSL proxy: to localhost:4445.
-
            5. Done.
-
            
-
-
-
-
            Is using an outproxy safe?
-(link)
            
-
            
-   This is a question that only you can answer because the correct answer depends on your behaviours, your
-   threat model, and how much you trust the outproxy operator.
-
            
-   Like Tor, I2P does not magically encrypt the Internet.
-   You are vulnerable to snooping by the outproxy operators.
-   The Tor FAQ
-   does a good job of explaining this.
-   
            
-   In addition, you may be vulnerable to collusion between the outproxy operator
-   and operators of other I2P services, if you use the same tunnels ("shared clients").
-   There is additional discussion about this on zzz.i2p.
-
            
-
-
            How do I access IRC, BitTorrent, or other services on the regular Internet?
-(link)
            
-
            
-   Unless an outproxy has been set up for the service you want to connect to, this cannot be done.
-   There are only three types of outproxies running right now: HTTP, HTTPS, and email. Note that there is not a SOCKS outproxy.
-   If this type of service is required, try Tor.
-
            
-
-
            Most of the eepsites within I2P are down?
-(link)
            
-
            
-   If you consider every eepsite that has ever been created, yes, most of them are down.
-   People and eepsites come and go.
-   A good way to get started in I2P is check out a list of eepsites that are currently up.
-   perv.i2p tracks active eepsites.
-
            
-
-
            How do I set up my own eepsite?
-(link)
            
-
            
-   Click on the Website link
-   at the top of your router console for instructions.
-
            
-
-
            Why is I2P so slow?
-(link)
            
-
            
-Why are downloads, torrents, web browsing, and everything else so slow on I2P?
-The encryption and routing within the I2P network adds a substantial amount of overhead and limits bandwidth.
-Anonymity isn't free.
-
            
-
            
-In addition, you and everybody else probably need to increase your bandwidth limits.
-Two key settings are the inbound and outbound bandwidth limiters on
-the configuration page.
-With the default settings of 32KBps you will generally get no better than 15KBps data transfer in I2PSnark.
-Increasing the settings (but keeping within your actual connection limitations)
-will increase the potential transfer rate for I2PSnark and all other applications.
-
            
-Also, do you have sufficient share bandwidth configured to allow participating tunnels
-to route through your router? Believe it or not, allowing participating traffic
-keeps you well-integrated in the network and helps your own transfer speeds.
-
            
-I2P is a work in progress. Lots of improvements and fixes are being implemented, and
-generally speaking, running the latest release will help your performance.
-If you haven't, install the latest release.
-
            
-
-
            Bittorrent / I2PSnark / Azureus I2P Plugin Questions?
-(link)
            
-
            
-See the
-I2P Bittorrent FAQ
-(outside I2P)
-
            
-
            How do I connect to IRC within I2P?
-(link)
            
-
            
-On the
-I2PTunnel configuration page,
-start the ircProxy.
-Then tell your IRC client to connect to localhost port 6668.
-
            
-
            How can I access the web console from my other machines or password protect it?
-(link)
            
-
            
-    For security purposes, the router's admin console by default only listens
-    for connections on the local interface.  However, with a little hacking,
-    you can make it reachable remotely:
-
            
-
-
              
-	
            1. Open ~/.i2p/clients.config and replace
              
-    clientApp.0.args=7657 ::1,127.0.0.1 ./webapps/
              
-    with 
              
-    clientApp.0.args=7657 0.0.0.0 ./webapps/
              2. 
-
            2. Go to http://localhost:7657/configadvanced.jsp
-    and add a new option: consolePassword=foo (or whatever password you want)
              3. 
-
            3. Go to http://localhost:7657/index.jsp
-    and hit "Graceful restart", which restarts the JVM and reloads the client applications
              4. 
-
            
-
-
            
-    After that fires up, you should now be able to reach your console remotely.
-    You will be prompted for a username and password though - the username is
-    "admin" and the password is whatever you specified in step 2 above.  Note: the
-    0.0.0.0 above specifies an interface, not a network or netmask.  0.0.0.0
-    means "bind to all interfaces", so it can be reachable on 127.0.0.1:7657 as well as
-    any LAN/WAN IP.
-
            
-
-
            How can I use applications from my other machines?
-(link)
            
-
            
-By default, the router I2CP interface (port 7654) binds to address 127.0.0.1. To bind to 0.0.0.0, set the
-router advanced configuration option i2cp.tcp.bindAllInterfaces=true and restart.
-
            
-
-
            Whats an "eepsite"?
-(link)
            
-
            
-	An eepsite is a website that is hosted anonymously - you can access it by
-	setting your web browser's HTTP proxy to use the web proxy (typically it
-	listens on localhost port 4444), and browsing to the site.
-
            
-
-
            How do I configure my browser?
-(link)
            
-
            
-  The proxy config for different browsers is on a 
-  separate page with screenshots. More advanced configs with external tools
-  are possible but could introduce leaks in your setup.
-
            
-
-
-
            What do the Active x/y numbers mean in the router console?
-(link)
            
-
            
-    x is the number of peers you've sent or received a message from
-    successfully in the last minute, y is the number of peers seen in the last
-    hour or so.
-
            
-
-
            Is it possible to use I2P as a SOCKS proxy?
-(link)
            
-
            
-    The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are supported.
-    There is no SOCKS outproxy so it is of limited use.
-
            
-    In addition, many applications leak sensitive
-    information that could identify you on the Internet. I2P only filters
-    connection data, but if the program you intend to run sends this
-    information as content, I2P has no way to protect your anonymity.  For
-    example, some mail applications will send the IP address of the machine
-    they are running on to a mail server. There is no way for I2P to filter
-    this, thus using I2P to 'socksify' existing applications is possible, but
-    extremely dangerous.
-
            
-    If you would like more information on the socks proxy application anyway,
-    there are some helpful hints on the socks page.
-
            
-
-
            What ports does I2P use?
-(link)
            
-
            
-	Okay, here's a rundown of the default ports (everything is configurable
-	through various settings, of course):
-
            
-
-
-	
              
-		
            • Internet-facing ports
-		Note: New installs as of release 0.7.8 do not use port 8887; they select a random port
-		between 9000 and 31000 when the program is run for the first time.
-                The selected port is shown on the router configuration page.
-		
                
-		
              • Outbound UDP from the random port noted on the configuration page to arbitrary remote UDP ports, allowing replies
                • 
-		
              • Outbound TCP from random high ports to arbitrary remote TCP ports
                • 
-		
              • (optional, but recommended) Inbound UDP to the port noted on configuration page from arbitrary locations
                • 
-		
              • (optional, but recommended) Inbound TCP to the port noted on configuration page from arbitrary locations
                
-			Inbound TCP may be disabled on the configuration page.
                • 
-		
              • Outbound UDP on port 123, allowing replies
                
-			This is necessary for I2P's internal time sync (via SNTP - 
-			querying a random SNTP host in pool.ntp.org or another
-			server you specify)
                • 
-		
              
-		
              • 
-	
            
-
-	
              
-		
            • Local I2P ports, listening only to local connections by default,
-                       except where noted:
-		
                
-			
              • 1900: UPnP SSDP UDP multicast listener.
-                            Cannot be changed. Binds to all interfaces.
-                            May be disabled on confignet.jsp.
-                            
                • 
-			
              • 2827: BOB bridge, a higher level socket API for clients
-                            Disabled by default.
-                               May be enabled/disabled on configclients.jsp.
-                               May be changed in the bob.config file.
-                            
                • 
-			
              • 4444: HTTP proxy
-                            May be disabled or changed on the i2ptunnel page in the router console.
-			    May also be configured to be bound to a specific interface or all interfaces.
-                            
                • 
-			
              • 4445: HTTPS proxy
-                            May be disabled or changed on the i2ptunnel page in the router console.
-			    May also be configured to be bound to a specific interface or all interfaces.
-                            
                • 
-			
              • 6668: IRC proxy
-                            May be disabled or changed on the i2ptunnel page in the router console.
-			    May also be configured to be bound to a specific interface or all interfaces.
-                            
                • 
-			
              • 7652: UPnP HTTP TCP event listener.
-                            Binds to the LAN address.
-                            May be changed with advanced config i2np.upnp.HTTPPort=nnnn.
-                            May be disabled on confignet.jsp.
-                            
                • 
-			
              • 7653: UPnP SSDP UDP search response listener.
-                            Binds to all interfaces.
-                            May be changed with advanced config i2np.upnp.SSDPPort=nnnn.
-                            May be disabled on confignet.jsp.
-                            
                • 
-			
              • 7654: I2P Client Protocol port, used by client apps.
-                            May be changed to a different port on
-                            configclients.jsp
-                               but this is not recommended.
-			    May be to bind to a different interface or all interfaces, or disabled, on
-                            configclients.jsp.
-                            
                • 
-			
              • 7655: UDP for SAM bridge, a higher level socket API for clients
-                            Only opened when a SAM V3 client requests a UDP session.
-                               May be enabled/disabled on configclients.jsp.
-                               May be changed in the clients.config file with the SAM command line option sam.udp.port=nnnn.
-                            
                • 
-			
              • 7656: SAM bridge, a higher level socket API for clients
-                            Disabled by default for new installs as of release 0.6.5.
-                               May be enabled/disabled on configclients.jsp.
-                               May be changed in the clients.config file.
-                            
                • 
-			
              • 7657: Your router console
-                            May be disabled in the clients.config file.
-			    May also be configured to be bound to a specific interface or all interfaces in that file.
-			    
                • 
-			
              • 7658: Your eepsite
-                            May be disabled in the clients.config file.
-			    May also be configured to be bound to a specific interface or all interfaces in the jetty.xml file.
-			    
                • 
-			
              • 7659: Outgoing mail to smtp.postman.i2p
-                            May be disabled or changed on the i2ptunnel page in the router console.
-			    May also be configured to be bound to a specific interface or all interfaces.
-                            
                • 
-			
              • 7660: Incoming mail from pop.postman.i2p
-                            May be disabled or changed on the i2ptunnel page in the router console.
-			    May also be configured to be bound to a specific interface or all interfaces.
-                            
                • 
-			
              • 8998: mtn.i2p2.i2p (Monotone - disabled by default)
-                            May be disabled or changed on the i2ptunnel page in the router console.
-			    May also be configured to be bound to a specific interface or all interfaces.
-                            
                • 
-			
              • 31000: Local connection to the wrapper control channel port.
-                            Outbound to 32000 only, does not listen on this port.
-                            Starts at 31000 and will increment until 31999 looking for a free port.
-                            To change, see the
-                            wrapper documentation.
-                            For more information see below.
-                            
                • 
-			
              • 32000: Local control channel for the service wrapper.
-                            To change, see the
-                            wrapper documentation.
-                            For more information see below.
-                            
                • 
-		
              
-		
              • 
-	
            
-
-
-
            
-	The local I2P ports and the I2PTunnel ports do not need to be reachable from 
-	remote machines, but *should* be reachable locally.  You can also create 
-	additional ports for I2PTunnel instances via http://localhost:7657/i2ptunnel/ 
-	(and in turn, would need to get your firewall to allow you local access, but 
-	not remote access, unless desired).
-
            
-
-
            
-	So, to summarize, nothing needs to be reachable by unsolicited remote peers, but
-	if you can configure your NAT/firewall to allow inbound UDP and TCP the outbound facing port, you'll
-	get better performance.  You will also need to be able to send outbound UDP packets
-	to arbitrary remote peers (blocking IPs randomly with something like PeerGuardian
-	only hurts you - don't do it).
-
            
-
-
            Why is I2P listening on port 32000?
-(link)
            
-
            The Tanuki java service wrapper that we use opens this port—bound to localhost—in order 
-to communicate with software running inside the JVM. When the JVM is launched it is given a key 
-so it can connect to the wrapper. After the JVM establishes its connection 
-to the wrapper, the wrapper refuses any additional connections.
            
-
            More information can be found in the  
-wrapper documentation.
            
-
-
            How do I reseed manually?
-(link)
            
-
            
-	An I2P router only needs to be seeded once, to join the network for the first time.
-	Reseeding is nothing more than sending plain HTTP GET requests
-	to fetch a directory listing and download multiple "routerInfo" files
-	from a predefined reseed URL.
-
            
-
-
            
-	A typical symptom of a failed reseed is the "Known" indicator
-	(on the left sidebar of the router console) displaying a very small value
-	(often less than 5) which does not increase. This can occur, among other things,
-	if your firewall limits outbound traffic, and blocked the reseed request.
-
            
-
-	To reseed an I2P router manually, do the following:
-	
              
-	
            • Stop your I2P router
-	
            • Open 
-	    http://netdb.i2p2.de/ using a web browser
-	
            • Save a dozen "routerInfo" files to your I2P "netDb" directory
-     
-	
            • Start your I2P router
-	
            
-
            I'm using FreeBSD and when I start I2P I receive an error about libm.so.4!
-(link)
            
-When trying to start the router using "i2prouter start", you may see output like the following:
            
-     $ ./i2prouter start
            
-     Starting I2P Service...
            
-     /libexec/ld-elf.so.1: Shared object "libm.so.4" not found, required by "i2psvc"
-            
-
            In order to be inclusive and try to ensure that I2P will run on as many systems 
-   as possible, up until I2P 0.8.9 we used a java wrapper 
-   compiled for FreeBSD 6.x. If you're receiving this error you most likely are missing the necessary compatibility libraries.
-   These libraries may be installed by performing the following steps:
            
-
              
-   
            • Switch to the root user with su or log in as root.
              • 
-   
            • cd /usr/ports/misc/compat6x
              • 
-   
            • make install
              • 
-
            
-
            If you cannot install these compatibility libraries (or do not want to), other possibilities would be to compile the wrapper for your system, 
-  starting I2P with the runplain.sh script, or you can replace the wrapper with one from the source tarball.
            
-
            For the 0.8.9 release of I2P, the wrapper was upgraded to v3.5.12 and compiled on systems running FreeBSD 7.2.
            
-
-
            In wrapper.log I see an error that states "Protocol family unavailable" when loading the Router Console
-(link)
            
-
            Often this error will occur with any network enabled java software on some systems that are configured to use IPv6 by default. There are a few ways to solve this:
            
-
              
-   
            • On Linux based systems, you can echo 0 > /proc/sys/net/ipv6/bindv6only
              • 
-   
            • Look for the following lines in wrapper.config.
              
-#wrapper.java.additional.5=-Djava.net.preferIPv4Stack=true
              
-      #wrapper.java.additional.6=-Djava.net.preferIPv6Addresses=false
              
-
              
-   If the lines are there, uncomment them by removing the "#"s. If the lines are not there, add them without the "#"s.
              • 
-   
            
-Another option would be to remove the ::1 from ~/.i2p/clients.config
-
            WARNING: For any changes to wrapper.config to take effect, you must completely
-stop the router and the wrapper. Clicking Restart on your
-router console will NOT reread this file! You must
-click Shutdown, wait 11 minutes, then start I2P.
            
-
            
-
            I have a question!
-(link)
            
-
            
-    Great!  Find us on IRC irc.freenode.net #i2p or post to
-    the forum (within I2P) and we'll post it here (with
-    the answer, hopefully).
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/getinvolved.html b/www.i2p2/pages/getinvolved.html
deleted file mode 100644
index 68981373..00000000
--- a/www.i2p2/pages/getinvolved.html
+++ /dev/null
@@ -1,52 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Get Involved!{% endblock %}
-{% block content %}
-
            We need your help!
            
-
            To get involved, please feel free to join us on the #i2p IRC channel (on
-irc.freenode.net, or within I2P on irc.freshcoffee.i2p or irc.postman.i2p).
            
-
            If you're interested in joining our team, please get in
-touch as we're always looking for eager contributors!
                
-
            
-We need help in many areas, and you don't need to know Java to contribute!
-Here's a list to help you get started!
            
-
              
-
            • Spread the Word! —
-Tell people about I2P on forums, blogs, and comments to articles.
-Fix up the Wikipedia article about I2P in your language.
-Tell your friends.
-
            • Testing —
-Run the latest builds from monotone
-and report results on #i2p or as bugs on Trac.
-
            • Documentation —
-Help fix the parts of the website that are outdated or incomplete.
-Translate pages into other languages.
-
            • Pictures —
-Make some more pictures, fix the old ones on the website
-
            • Content —
-Make an eepsite! Add some content! Contribute to the community!
-
            • Services —
-Run a service on an eepsite. It could be a proxy, a forum, a tracker,
-a naming service, a search engine, an eepsite monitor... many of these
-aren't that hard.
-
            • Applications —
-Write or port applications for I2P! There's some guidelines and
-a list of ideas on the applications page.
-
            • Coding —
-There's plenty to do if you know Java or are ready to learn.
-Check for open tickets on Trac
-or the TODO list on zzz.i2p for
-some ideas on where to start.
-See the new developer's guide for details.
-
            • Translation —
-Help translate the website and the software into your language.
-See the new translator's guide for details.
-
            • Analysis —
-Study or test the code to look for vulnerabilities.
-Both anonymity vulnerabilities from the various
-threat models,
-and DOS and other weaknesses due to securities holes,
-need researching.
-
            • Donate
-
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/how.html b/www.i2p2/pages/how.html
deleted file mode 100644
index 597a9cf5..00000000
--- a/www.i2p2/pages/how.html
+++ /dev/null
@@ -1,230 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Index to Technical Documentation{% endblock %}
-{% block content %}
-
            How does I2P work?
            
-
-
            
-Following is an index to the technical documentation for I2P.
-This page was last updated in May 2012 and is accurate for router version 0.9.
-
            
-This index is ordered from the highest to lowest layers.
-The higher layers are for "clients" or applications;
-the lower layers are inside the router itself.
-The interface between applications and the router is the I2CP (I2P Control Protocol) API.
-
            
-The I2P Project is committed to maintaining accurate, current documentation.
-If you find any inaccuracies in the documents linked below, please
-enter a ticket identifying the problem.
-
            
-
-
            Index to Technical Documentation
            
-
-
            Overview
            
-
-
-
            Application-Layer Topics
            
-
-
-
            Application Layer API and Protocols
            
-High-level, easy-to-use APIs for applications written in any language to send and receive data.
-
-
-
            End-to-End Transport API and Protocols
            
-The end-to-end protocols used by clients for reliable and unreliable communication.
-
-
-
            Client-to-Router Interface API and Protocol
            
-The lowest-level API used for clients (applications) to send and receive traffic to a router.
-Traditionally used only by Java applications and higher-level APIs.
-
-
-
            End-to-End Encryption
            
-How client messages are end-to-end encrypted by the router.
-
-
-
            Network Database
            
-Distributed storage and retrieval of information about routers and clients.
-
-
-
            Router Message Protocol
            
-I2P is a message-oriented router. The messages sent between routers are defined by the I2NP protocol.
-
-
-
            Tunnels
            
-Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.
-
-
-
            Transport Layer
            
-The protocols for direct (point-to-point) router to router communication.
-
-
-
            Other Router Topics
            
-
-
-
            Developer's Guides and Resources
            
-
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/how_intro.html b/www.i2p2/pages/how_intro.html
deleted file mode 100644
index d56bf2ca..00000000
--- a/www.i2p2/pages/how_intro.html
+++ /dev/null
@@ -1,150 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}A Gentle Introduction{% endblock %}
-{% block content %}
-
-
            A Gentle Introduction to How I2P Works
            
-
-
            I2P is a project to build, deploy, and maintain a network supporting secure and anonymous 
-communication. People using I2P are in control of the tradeoffs between anonymity, reliability, 
-bandwidth usage, and latency. There is no central point in the network on which pressure can be 
-exerted to compromise the integrity, security, or anonymity of the system. The network supports 
-dynamic reconfiguration in response to various attacks, and has been designed to make use of 
-additional resources as they become available. Of course, all aspects of the network are open 
-and freely available.
            
-
-
            Unlike many other anonymizing networks, I2P doesn't try to provide anonymity by hiding the 
-originator of some communication and not the recipient, or the other way around. I2P is designed 
-to allow peers using I2P to communicate with each other anonymously — both sender and recipient 
-are unidentifiable to each other as well as to third parties. For example, today there are both 
-in-I2P web sites (allowing anonymous publishing / hosting) as well as HTTP proxies to the normal 
-web (allowing anonymous web browsing). Having the ability to run servers within I2P is essential, 
-as it is quite likely that any outbound proxies to the normal Internet will be monitored, disabled, 
-or even taken over to attempt more malicious attacks.
            
-
-
            The network itself is message oriented - it is essentially a secure and anonymous IP layer, 
-where messages are addressed to cryptographic keys (Destinations) and can be significantly larger 
-than IP packets. Some example uses of the network include "eepsites" (webservers hosting normal web
-applications within I2P), a BitTorrent client ("I2PSnark"), 
-or a distributed data store.  With the help of the I2PTunnel application, 
-we are able to stream traditional TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and 
-even streaming audio. Most people will not use I2P directly, or even need to know they're using it. 
-Instead their view will be of one of the I2P enabled applications, or perhaps as a little controller 
-app to turn on and off various proxies to enable the anonymizing functionality.
            
-
-
            An essential part of designing, developing, and testing an anonymizing network is to define the 
-threat model, since there is no such thing as "true" anonymity, just 
-increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to communicate 
-in arbitrarily hostile environments by providing good anonymity, mixed in with sufficient cover 
-traffic provided by the activity of people who require less anonymity. This way, some users can avoid
-detection by a very powerful adversary, while others will try to evade a weaker entity,
-all on the same network, where each one's messages are essentially indistinguishable from the 
-others.
            
-
-
            Why?
            
-
            There are a multitude of reasons why we need a system to support 
-anonymous communication, and everyone has their own personal rationale. There are many 
-other efforts working on finding ways to provide varying degrees of 
-anonymity to people through the Internet, but we could not find any that met our needs or threat 
-model.
            
-
-
            How?
            
-
-
            The network at a glance is made up of a set of nodes ("routers") with a number of unidirectional 
-inbound and outbound virtual paths ("tunnels", as outlined on the tunnel routing page). 
-Each router is identified by a cryptographic RouterIdentity which is typically long lived. These routers 
-communicate with each other through existing transport mechanisms (TCP, UDP, etc), passing various 
-messages.  Client applications have their own cryptographic identifier ("Destination") which enables it 
-to send and receive messages. These clients can connect to any router and authorize the temporary 
-allocation ("lease") of some tunnels that will be used for sending and receiving messages through the 
-network.  I2P has its own internal network database (using a modification of 
-the Kademlia algorithm) for distributing routing and contact information securely.
            
-
-
            Network topology example
            
-
-
-
            In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their 
-local router.  They each have a pair of 2-hop inbound tunnels per destination (labeled 1,2,3,4,5 and 6),
-and a small subset of each of those router's outbound tunnel pool is shown with 2-hop outbound tunnels.
-For simplicity, Charlie's inbound tunnels and Dave's outbound tunnels are not shown, nor are the rest of
-each router's outbound tunnel pool (typically stocked with a few tunnels at a time).  When Alice and Bob
-talk to each other, Alice sends a message out one of her (pink) outbound tunnels targeting one of Bob's
-(green) inbound tunnels (tunnel 3 or 4).  She knows to send to those tunnels on the correct router by querying the
-network database, which is constantly updated as new leases are authorized and old ones expire.
            
-  
-
            If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of his
-outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2).  To make things easier, most 
-messages sent between Alice and Bob are garlic wrapped, bundling the 
-sender's own current lease information so that the recipient can reply immediately without having to look 
-in the network database for the current data.
            
-
-
            To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and 
-hence there are no directory servers keeping statistics regarding the performance and reliability of 
-routers within the network. As such, each router must keep and maintain profiles of various routers 
-and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability 
-needs of the users, as described in the peer selection page.
            
-
-
            The network itself makes use of a significant number of cryptographic techniques and algorithms - 
-a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding, 
-1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to 
-station authentication, and ElGamal / AES+SessionTag.
            
-
-
            Content sent over I2P is encrypted through three layers garlic encryption (used to verify the delivery of the message to 
-the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel 
-gateway to the tunnel endpoint), and inter router transport layer encryption (e.g. the TCP transport 
-uses AES256 with ephemeral keys):
            
-
            End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; 
-end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a" to Bob's router "h" remains.
-Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection
-between the I2P router and the applications is not end-to-end encrypted!
-A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the applications running atop of I2P.
            
-
-
            End to end layered encryption
            
-
-
            The specific use of these algorithms are outlined elsewhere.
            
-
-
            The two main mechanisms for allowing people who need strong anonymity to use the network are 
-explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling 
-and mixing messages. These are currently planned for release 3.0, but garlic routed messages with no 
-delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow people to set 
-up and operate behind restricted routes (perhaps with trusted peers), as well as the deployment of more 
-flexible and anonymous transports.
            
-
-
            Some questions have been raised with regards to the scalability of I2P, and reasonably so. There 
-will certainly be more analysis over time, but peer lookup and integration should be bounded by 
-O(log(N)) due to the network database's algorithm, while end to end 
-messages should be O(1) (scale free), since messages go out K hops through the outbound 
-tunnel and another K hops through the inbound tunnel, with K no longer than 3.
-The size of the network (N) bears no impact.
            
-
-
            When?
            
-
            I2P initially began in Feb 2003 as a proposed modification to 
-Freenet to allow it to use alternate transports, such as 
-JMS, then grew into its own as an 
-'anonCommFramework' in April 2003, turning into I2P in July, with code being written in earnest starting in August '03.
-I2P is currently under development, following
-the roadmap.
            
-
-
            Who?
            
-
            We have a small team spread around several continents, working to advance different 
-aspects of the project.  We are very open to other developers who want to get involved and anyone else 
-who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled 
-applications, or documentation. The entire system is open source - the router and most of the SDK are 
-outright public domain with some BSD and Cryptix licensed code, while some applications like I2PTunnel 
-and I2PSnark are GPL. Almost everything is written in Java (1.5+), though some third party applications 
-are being written in Python and other languages. The code works on Sun Java SE and other Java Virtual Machines.
-
            
-
-
            Where?
            
-
            Anyone interested should
-join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de).
-There are currently no scheduled development meetings, however
-archives are available.
            
-
-
            The current source is available in monotone.
            
-
-
            Additional Information
            
-
            
-See the Index to Technical Documentation
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/how_intro_de.html b/www.i2p2/pages/how_intro_de.html
deleted file mode 100644
index 333fd9c9..00000000
--- a/www.i2p2/pages/how_intro_de.html
+++ /dev/null
@@ -1,163 +0,0 @@
-{% extends "_layout_de.html" %}
-{% block title %}Einführung in die Arbeitsweise von I2P{% endblock %}
-{% block content %}
-
            Die Webseite wird gerade überholt und dieses Dokument kann alte Informationen enthalten
            
-
-
            I2P ist ein Projekt, welches ein Netzwerk zum sicheren und anonymen Kommunizieren planen, aufbauen
-und betreuen wird. Nutzer von I2P haben die Kontrolle über die Verteilung zwischen Anonymität,
-Verlässlichkeit, genutzter Bandbreite und Verzögerung. Es gibt keinen zentralen Punkt im Netzwerk,
-welcher übernommen werden kann um die Integrität, Sicherheit oder Anonymität des Systems zu 
-komprimieren. Das Netzwerk kann sich in einer Reaktion auf Angriffe selber rekonfiguriern und
-wurde so geplant, das es zusätzliche Ressourcen bei deren Verfügbarkeit nutzen wird. 
-Selbstverständlich sind alle Aspekte des Netzwerkes offen und frei verfügbar.
            
-
-
            Im Gegensatz zu vielen anderen anonymen Netzwerken versucht I2P nicht die Anonymität durch 
-verstecken eines Teils einer Kommunikation, der Sender oder der Empfänger, herzustellen. I2P
-wurde so geplant, das Nutzer von I2P untereinander anonym kommunizieren können - Sender und
-Empfänger sind für den jeweils anderen anonym als auch für nicht beteiligte dritte. Zum Beispiel
-gibt es zur Zeit I2P interne Webseiten (die anonymes Publizieren/hosten erlauben) und einen
-HTTP Proxy in das normale Internet (der anonymes Browsing bietet). Server im I2P Netz betreiben 
-zu können ist eine essentielle Angelegenheit, da angenommen werden kann, das die Proxis ins
-normale Internet überwacht werden, abgeschaltet werden oder gar zu schlimmeren Angriffen genutzt 
-werden.
            
-
-
            Das Netzwerk selber ist Nachrichten basiert - es ist essentiell eine sichere und anonyme IP Schicht,
-in der Nachrichten an kryptographische Schlüssel (Ziele) geschickt werden;die Nachrichten selber
-können signifikant grösser als IP Pakete werden. Beispiele für die Nutzung des Netzwerkes sind
-unter anderem "Eepsites" (Webserver mit normalen Webapplikationen innerhalb von I2P), ein 
-BitTorrent Klient ("I2Psnark") oder ein verteilter 
-Datencontainer. Mit der Hilfe von mihis I2PTunnel
-Applikation können wir die üblichen TCP/IP Anwendungen über I2P tunneln, z.B. SSH, IRC, ein squid 
-Proxy oder gar Audio. Viele Leute werden I2P nicht direkt nutzen oder nicht bemerken, das sie I2P
-nutzen. Stattdessen sehen sie nur eine der I2P fähigen Anwendungen oder nur eine Einstellung für
-verschiedene Proxies, die ihnen Anonyme Verbindungen anbieten.
            
-
-
            Ein wichtiger Teil des Planens, Entwickelns und Testens eines anonymen Netzwerkes ist das 
-Definieren des Angriffsszenarios, da es "echte" Anonymität nicht gibt, 
-nur steigende Kosten und 
-Aufwand jemanden zu identifizieren. Kurz gesagt: I2P Absicht ist es, Personen in willkürlichen
-feindseligen Umgebungen einen militärischen Grad der Anonymität zu bieten, versteckt in dem
-hinreichendem Datenstrom aus der Aktivität anderer Leute, die weniger Anonymität benötigen. 
-Dieses beinhaltet den Chat von Joe Sixpack mit seinen Freuden, den niemanden mitlesen kann,
-Jane Filesharer, die weiß das die grossen Konzerne sie beim Tauschen von Dateien nicht 
-identifizieren können, als auch Will Geheimnisverräter, der geheime Dokumente veröffentlicht -
-alles in dem selben Netzwerk, in dem eine Nachricht nicht von einer anderen unterschieden werden
-kann.
            
-
-
            Warum?
            
-
            Es existieren eine unglaubliche Anzahl an fantastischen Gründen, weswegen wir ein System zum
-anonymen Kommunizieren benötigen und jeder hat seine eigenen persönlichen rationalen Gründe.
-Es gibt viele andere Bestrebungen, die auf dem einem oder anderen Weg 
-unterschiedliche
-Arten der Anonymität im Internet zu erreichen versuchen, aber wir fanden keine, die unsere
-Anforderungen oder unser Angriffszenario abdeckten.
            
-
-
            Wie?
            
-
-
            In einer übersicht existiert das Netzwerk aus einer Gruppe von Knoten ("Router") mit einer 
-Anzahl an unidirektionalen virtueller Eingangs und Ausgangs Wege ("Tunnel", wie in der 
-Tunnel Routing  Seite beschrieben). Jeder Router wird duch eine kryptographische RouterIdentity
-eindeutig indentifiziert, diese ist für gewöhnlich dauerhaft gültig. Diese Router kommunizieren
-über vorhandene Transportmechanosmen (TCP, UDP, etc.) und tauschen verschiedene Nachrichten aus.
-Klientprogramme haben ihre eigenen kryptographischen Ident ("Destination"), durch den sie 
-zum Senden und Empfangen von Nachrichten befähigt sind. Diese Klienten können zu irgendwelchen
-Routern Verbindung aufnehmen und authorisieren ihre derzeitige Belegung ("lease") von ein paar
-Tunneln, die zum Senden und Empfangen von Nachrichten durch das Netzwerk benutzt werden. I2P 
-hat eine eigene Netzwerk Datenbank ("Floodfill") zum skalierbaren sicherem Verteilen von Routing
-und Kontaktinformationen.
            
-
-
            Network topology example
            
-
-
            Im oberen Bild betreiben Alice, Bob, Charlie und Dave je einen Router mit einer einzigen 
-Destination auf ihren lokalen Router. Sie haben alle ein paar 2-Hop Eingangstunnel je
-Destination (mit 1,2,3,4,5 und 6 bezeichnet) und ein paar haben 2-Hop Ausgangstunnel.
-Zur Vereinfachung sind Charlies Eingangstunnel und Daves Ausgangstunnel nicht eingezeichnet,
-ebenso wie weitere Ausgangstunnel der Router (normalerweise so 5-10 Tunnel gleichzeitig).
-Sobald Alice und Bob miteiander reden, sendet Alice eine Nachricht über ihren (pinken)
-Ausgangstunnel in Richtung eines vons Bobs Eingangstunneln (grün, Tunnel 3 oder 4). Sie lernt
-den Eingangstunnel durch eine Abfrage der Netzwerk Datenbank kennen, diese Datenbank wird
-dauerhaft aktualisiert sobald neue Leases authorisiert sind und ältere auslaufen.
            
-  
-
            Antwortet Bob nun Alice, geschieht dieses auf der selben Art und Weise - er sendet eine Nachricht
-über einen seiner Ausgangstunnel in Richtung eines von Alice Eingangstunnels (Tunnel 1 oder 2).
-Um vieles einfacher zu machen, sind viele Nachrichten zwischen Bob und Alice in sogenannte
-"Garlics" eingepackt, in denen die Lease Information vom Sender enthalten ist, so das der
-Empfänger sofort antworten kann ohne in der Netzwerk Datenbank nach den benötigten Informationen
-suchen zu müssen.
            
-
-
            Um einigen Attacken aus dem Wege zu gehen ist I2P dezentral aufgebaut, ohne eine zentrale Instanz -
-und wie schon richtig geraten existiert kein zentraler Verzeichnisdienst, der Informationen
-zur Performance und Kontinuität der Router im Netzwerk verwaltet. Daraus folgt, daßjeder Router
-eigene Profile verschiedener Router halten und pflegen muss. Ebenso ist jeder Router selber 
-verantwortlich für die Auswahl der korrekten Knoten um die Anforderungen an die Anonymität,
-Performance und Konitnuität des Benutzers zu erfüllen, so wie es in der "
-Knoten Auswahl" Seite beschrieben ist.
            
-
-
            Das Netzwerk selber nutzt eine signifikante Anzahl von Kryptographischen Techniken und Algorhytmen -
-die Liste umfässt 2048bit ElGamal Verschlüsselung, 256bit AES im CBC Modus mit PKCS#5 Padding,
-1024bit DSA Signaturen, SHA256 Hashes, 2048bit Diffie-Hellmann vermittelte Verbindungen mit
-Station-zu-Station Authentifizierung und ElGamal / AES+SessionTag.
            
-
-
            Daten die über I2P gesendet werden, durchlaufen 3 Verschlüsselungen: garlic Verschlüsselung (zur 
-überprüfung ob die Nachrichten beim Empfänger angekommen ist), Tunnel Verschlüsselung  (alle 
-Nachrichten, die durch einen Tunnel gehen, sind vom Tunnel Gateway bis zum Tunnel Endpunkt 
-verschlüsselt) und Zwischen-den-Routern-Transport-Schicht Verschlüsselung (z.B. benutzt der TCP
-Transport AES256 mit Ephemeral Schlüssel).
            
-
            Ende-zu-Ende (I2CP) Verschlüsselung (von Programm zu Programm) wurde in der I2P Version 0.6 deaktiviert;
-Ende-zu-Ende (garlic) Verschlüsselung von Alice Router "a" zu Bobs Router "h" existiert weiterhin.
-Bitte beachte im foglendem Bild den anderen Gebrauch der Wörter! a und h sind die I2P Router mit
-der Ende-zu-Ende Verschlüsselung von Router zu Router, Alice und Bob hingegen sind die Programme
-die mittels(unverschlüsseltem) I2CP mit den I2P Routern kommunizieren! Sprich: bis zum I2P Router
-sind die Daten unverschlüsselt, ab dem I2P Router ist alles Ende-zu-Ende verschlüsselt.
            
-
-
            End to end layered encryption
            
-
-
            Die genaue Anwendung dieser Algorhytmen sind woanders beschrieben.
            
-
-
            Die zwei Hauptbestandteile für den militärischen Grad der Anonymität sind explizite, verzögerte
-garlic geroutete Nachrichten und mehr umfassende Tunnel mit Unterstützung von Pooling und Mixen
-von Nachrichten. Diese Funktionen sind zur Zeit für Version 3.0 geplant, aber garlic geroutete
-Nachrichten mit keiner Verzögerung und FIFO Tunnels sind schon implementiert. Zusätzlich wird
-die Version 2.0 den Leuten erlauben, I2P hinter beschränkten Routen (möglicherweise mit vertrauten
-Knoten) aufzusetzen und zu betreiben; ebenso werden die flexiblere und anonymere Transports 
-eingebaut werden.
            
-
-
            Es kamen ein paar berechtigte Fragen bezüglich der Skalierbarkeit von I2P auf. Mit der Zeit werden
-sicher detailiertere Analysen kommen, aber Knoten suchen und Integration sollte mit O(log(N)) 
-Komplexität eingehen, während Ende-zu-Ende Nachrichten mit O(1) (frei skalierend) eingehen, da
-Nachrichten durch K Hops im Ausgangstunnel und durch weitere K Hops im Eingangstunnel gehen - 
-die Grösse des Netzwerkes (N) hat hier keinen Einfluss.
            
-
-
            Wann?
            
-
            I2P startete im Februar 2003 als eine vorgeschlagene Modifizierung zu Freenet, damit dieses
-alternative Transports, wie z.B. JMS, nutzen könne. Dann wuchs es in ein eigenes 
-'anonCommFramework' im April 2003, worauf es im July zu I2P wurde. Ersten Quelltext gab es im
-August 2003, Version 0.2 folgte im September, 0.3 in März 2004, 0.4 im September 2004, 0.5 
-wurde Anfang 2005 veröffentlicht, gefolgt von Version 0.6 Mitte 2005. I2P folgt in der 
-Entwicklung der derzeitigen Roadmap.
            
-
-
            Das Netzwerk selber ist noch nicht fertig zum allgemeinem Nutzen und sollte nicht von Leuten
-mit Bedarf an Anonymität genutzt werden bevor es nicht ausführlichen überprüfungen stand 
-gehalten halt.
            
-
-
            Wer?
            
-
            Wir sind ein kleines Team aus merhren Ländern aus verschiedenen Kontinenten, das an der
-Weiterentwicklung von einzelnen Aspekten des Projektes arbeitet. Wir sind offen für weitere
-Entwickler, die sich einbringen wollen und auch gegenüber jedem anderen, der etwas zum 
-Projekt beibringen kann, sei es Kritiken, Peer Review, Testen, schreiben neuer I2P
-kompatibler Anwendungen oder aber auch Dokumentationen. Das gesamte System ist Open Source -
-Der Router und ein Großeil des SDK sind zur Gänze Public Domain mit ein wenig BSD und 
-Cryptix Lizensiertem Code, wohingegen einige Anwendungen wie I2PTunnel und I2PSnark
-GPL lizensiert sind.
-Fast alles ist in Java (1.3+/1.5+) geschrieben, einige externe Anwendungen sind jedoch in
-Python geschrieben. Der Code arbeitet im aktuellen Kaffee und wir hoffen ihn möglichst bald
-auf GCJ lauffähig zu bekommen.
            
-
-
            Wo?
            
-
            Jeder mit Interesse an I2P sollte uns im #I2P IRC Raum (gehostet auf irc.freenode.net, 
-irc.postman.i2p und irc.freshcoffee.i2p) besuchen. Es gibt zur Zeit keine fest geplanten
-Entwicklertreffen, dennoch existiert ein Archiv von abgehaltenen Entwickler Treffen.
            
-
-
            Der aktuelle Quelltext ist in Monotone verfügbar.
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/how_intro_es.html b/www.i2p2/pages/how_intro_es.html
deleted file mode 100644
index 7ad82c64..00000000
--- a/www.i2p2/pages/how_intro_es.html
+++ /dev/null
@@ -1,177 +0,0 @@
-{% extends "_layout_es.html" %}
-{% block title %}Una Introducción sencilla{% endblock %}
-{% block content %}
-
-
            Una breve presentación de cómo funciona I2P
            
-
-
            I2P es un proyecto para construir, desplegar y mantener una red que soporte 
-comunicación segura y anónima. Los usuarios de I2P pueden administrar
-el balance entre el anonimato, fiabilidad, uso de ancho de banda y latencia.
-No hay un punto central en la red sobre el cual se pueda ejercer presión para
-comprometer la integridad, seguridad y anonimato del sistema. La red soporta
-reconfiguración dinámica en respuesta a diversos ataques, y ha sido diseñada
-para hacer uso de recursos adicionales según vayan estando disponibles. Por
-supuesto, todos los aspectos de la red son abiertos y están a libre disposición.
-
            
-
-
            A diferencia de la mayoría de las redes anónimas, I2P no intenta suministrar
-anonimato ocultándole sí al origen de una comunicación y no al destinatario,
-o víceversa. De lo contrario: I2P está diseñada para permitir a los pares comunicarse
-unos con otros anónimamente - ambos, quien envía y el que recibe, no son
-identificables entre ellos y tampoco por terceras partes. Por ejemplo, 
-actualmente hay sitios web I2P internos (permitiendo publicación y hospedaje
-anónimo) además de proxies HTTP hacia la web normal (permitiendo 
-navegación anónima). Disponer de la posibilidad de correr servidores
-internamente en I2p es esencial,  ya que es bastante probable que cualquier
-proxy de salida hacia la Internet normal pudiera ser monitorizado, desactivado
-o comprometido con el intento de ataques más maliciosos.
            
-
-
            La red es en sí misma orientada a mensajes - es en esencia una capa IP segura
-y anónima donde los mensajes son direccionados hacia claves criptográficas
-(Destinos) y pueden ser considerablemente más largos que los paquetes IP.
-Algunos ejemplos del uso de la red incluyen "eepsites"  (servidores web
-hospedando aplicaciones web normales dentro de I2P), un cliente BitTorrent
-("I2PSnark"), o un sistema de almacenaje de datos distribuido. Con la ayuda
-de la aplicación I2PTunnel,somos capaces de correr aplicaciones TCP/IP tradicionales sobre I2P, como SSH, IRC, un proxy Squid, e igualmente streaming de audio. Mucha gente no usará I2P directamente, o mismamente no necesitarán saber que lo están usando. En vez de eso, su percepción será la de una de las aplicaciones I2P habilitadas, o quizá la de una pequeña aplicación de control para activar y desactivar varios proxies que permitan funcionalidades de anonimato.
            
-
-
            Una parte esencial de diseñar, desarrollar y probar una red anónima es definir el 
-modelo de amenaza, si partimos de que no existe lo que podría ser
-considerado anonimato auténtico,  solamente se puede hacer más costoso el
-identificar a alguien. Brevemente, el propósito de I2P es permitir comunicarse
-a la gente en ambientes arbitrariamente hostiles suministrando buen anonimato,
-mezclado con suficiente tráfico de cobertura proporcionado por la actividad
-de gente que requiere menos anonimato. De esta forma algunos usuarios pueden
-evitar ser detectados por poderosos adversarios, mientras otros intentarán 
-ocultar su identidad de forma más débil,
-todo en la misma red, donde los
-mensajes de cada uno son ensencialmente indistinguibles de los del resto.
            
-
-
            ¿Por qué?
            
-
             Puede haber multitud de razones por las que necesitemos un sistema que soporte
-comunicación anónima, y cada cual tendrá su razonamiento personal. Hay muchos 
-otros proyectos trabajando en encontrar formas de suministrar
-a la gente diferentes grados de anonimato a través de Internet, pero no 
-podríamos encontrar ninguno que se ajuste a nuestras necesidades o al
-modelo de amenaza.
            
-
-
            ¿Cómo?
            
-
-
            Un vistazo a la red muestra que se compone de una instalación de nodos
-("routers") con un número de rutas virtuales unidireccionales entrantes y salientes (Tunnels, como se describen en la página tunnel routing). 
-Cada router está identificado por una RouterIdentity cifrada que es
-permanente normalmente. Estos routers se comunican entre ellos a través
-de mecanismo de transporte existentes (TCP, UDP, etc) enviandose
-distintos mensajes. Las aplicaciones clientes tienen su propio identificador
-criptográfico ("Destino") que las habilita para enviar y recibir mensajes.
-Estos clientes pueden conectarse a cualquier router y autorizar la asignación
-temporal ("arrendamiento") de varios tuneles que serán usados para enviar y recibir mensaje a través de la red. I2P tiene su propia base de datos de red (utilizando una modificación del algoritmo Kademlia) para distribuir
-información de rutas y contactos de forma segura.
            
-
-
            Network topology example
            
-
-
-
            En la imagen, Alice, Bob, Charlie and Dave están corriendo routers con un
-simple Destino en su router local. Cada uno de ellos tiene un par de túneles
-de dos saltos entrantes por destino (etiquetados como 1, 2, 3, 4, 5 y 6), y una
-pequeña parte del grupo de los túneles de salida de esos routers se representa
-con tuneles de salida de dos saltos. Para simplificar, los túneles entrantes de
-Charlie y los de salida de Dave no se muestran, tampoco está el resto del grupo
-de túneles de salida de cada router (típicamente compuesto por varios túneles
-a la vez). Cuando Alice y Bob se comunican entre ellos, Alice envía un mensaje
-por uno de sus túneles de salida (rosa) en dirección a uno de los túneles 
-entrantes (verde) de Bob (túnel 3 o 4). Ella conoce cómo enviar a los túneles
-del router correcto mediante consultas a la base de datos de red, que está
-constantemente actualizándose tan pronto cómo son autorizados nuevos
-arrendamientos y expiran los viejos.
            
-  
-
            Si Bob quiere contestar a Alice, simplemente utilizará el mismo proceso
-- envía un mensaje por uno de sus túneles de salida en dirección hacia
-uno de los túneles de entrada de Alice (túnel 1 o 2). Para hacer las cosas
-más sencillas, la mayor parte de los mensajes enviados entre Alice y Bob
-usan el envoltorio garlic, incluyendo la información de arrendamiento propia
-del remitente en el paquete, de esta forma el destinatario puede contestar inmediatamente sin necesidad de buscar el dato en su base de datos de red.
            
-
-
            Para tratar con un ámplio rango de ataques, I2P es completamente distribuida
-sin recursos centralizados - no hay servidores de directorio manteniendo
-estadísticas sobre el rendimiento y fiabilidad de los routers dentro de la red.
-De esta forma cada router debe guardar y mantener los perfiles de varios routers
-y es responsable de seleccionar los pares apropiados para satisfacer el anonimato, rendimiento y fiabilidad requeridos por los usuarios tal y como 
-se describe en la página  selección de pares
            
-
-
            La red hace uso de un significante número de técnicas criptográficas y algoritmos - 
-una lista completa incluye cifrado El Gamal de 2048 bits,
-AES de 256 bits en modo CBC con relleno PKCS#5, firmas DSA de
-1024 bits, hashes SHA256, negociación de conexiones Diffie-Hellman de
-2048 bits con autenticación estación a estación y ElGamal / AES+SessionTag.
            
-
-
            El contenido enviado sobre I2P está cifrado a través del cifrado garlic de tres
-capas (usado para verificar la entrega del mensaje a destinatario), cifrado
-de túnel (todos los mensajes cruzando a través de un túnel están cifrados desde
-el túnel gateway hasta el túnel destino final) y cifrado de la capa de transporte
-inter-router (e. g. el transporte TCP usa AES256 con claves efímeras).
            
-
-
            El cifrado (I2CP) punto a punto  (aplicación cliente hacia aplicación servidor)
-fué deshabilitado en la versión 0.6 de I2P; el cifrado (garlic) punto a punto 
-(router cliente I2P hacia router servidor I2P) desde el router de Alice "a"
-hasta el router de Bob "h" permanece. ¡Observa el diferente uso de términos!
-Todos los datos desde "a" hasta "h" están cifrados punto a punto, pero las
-conexiones I2CP entre el router I2P y las aplicaciones no son cifradas punto
-a punto. "A" y "h" son los routers de Alice y Bob, mientras que, y siguiendo 
-el diagrama, Alice y Bob son las aplicaciones corriendo encima de I2P.
            
-
-
            End to end layered encryption
            
-
-
            El uso específico de estos algoritmos está descrito en otra parte.
            
-
-
            Los dos mecanismos principales que permiten usar la red a gente que
-necesita fuerte anonimato son explicitamente mensajes enrutados garlic
-con retardo y túneles más completos que incluyan agrupamiento y mezcla
-de mensajes. Éstos están actualmente planeados para la release 3.0, pero
-los mensajes enrutados garlic sin retardo y túneles FIFO están ya 
-implementados. Adicionalmente la release 2.0 permitirá a los usuarios
-establecerse y operar detrás de routers restrictivos (puede que con pares
-de confianza), así como el despliegue de transportes más flexibles y
-anónimos.
            
-
-
            Han surgido algunas preguntas referentes a la escalabilidad de I2P.
-Habrá ciertamente más análisis con el tiempo, pero la búsqueda e integración
-de pares debería ser limitado por
-O(log(N)) debido al algoritmo de base de datos de red, mientras que los mensajes punto a punto serían O(1) (escala libre), puesto que los mensajes pasan por K saltos a través del túnel de salida y otros
-K saltos por el túnel de entrada, donde K no es mayor de 3.  El tamaño de la
-red (N) no acarrea impacto.
            
-
-
            ¿Cuándo?
            
-
            I2P comenzó inicialmente en 2003 como una propuesta de modificar
-Freenet para permitir el uso de transportes alternativos, como puede ser 
-JMS, después
-se desarrolló con identidad propia como una “anonCommFramework” en 
-Abril de 2003, convirtiendose en I2P en Julio y comenzando a escribir código
-seriamente en Agosto de 2003. I2P está actualmente bajo desarrollo siguendo la hoja de ruta.
            
-
-
            ¿Quiénes?
            
-
            Tenemos un pequeño equipo desperdigado por varios continentes y trabajando
-en el avance de diferentes aspectos del proyecto. Estamos abiertos a otros
-desarrolladores que deseen involucrarse en el proyecto, y a cualquier otra
-persona que quiera contribuir de cualquier forma, como críticas, revisión de
-pares, pruebas, programación de aplicaciones compatibles I2P, o documentación. El sistema completo es código abierto - el router y la
-mayor parte del SDK tienen licencia de dominio público con algo de
-código licenciado con BSD y Cryptix, mientras que aplicaciones como
-I2PTunnel e I2PSnark son GPL. Casi todo está escrito en Java (1.5+),
-aunque algunas aplicaciones de terceros están siendo escritas en Python
-u otros lenguajes. El código funciona en Sun Java SE y otras máquinas virtuales Java.
-
            
-
-
            ¿Dónde?
            
-
            Cualquiera interesado puede unirse a nosotros en el canal IRC #i2p
-(hospedado concurrentemente en irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p e irc.einirc.de). Actualmente no
-hay agenda de encuentros de desarrollo, no obstante hay
-archivos disponibles.
            
-
-
            El código actual está disponible en monotone.
            
-
-
            Información adicional
            
-
            
-Ver el Índice de la Documentación Técnica
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/how_intro_fr.html b/www.i2p2/pages/how_intro_fr.html
deleted file mode 100644
index fa682b28..00000000
--- a/www.i2p2/pages/how_intro_fr.html
+++ /dev/null
@@ -1,160 +0,0 @@
-{% extends "_layout_fr.html" %}
-{% block title %}Introduction en douceur{% endblock %}
-{% block content %}
-Traduction de mars 2011. Version anglaise actuelle
-
            Une présentation allégée du fonctionnement d'I2P
            
-
            I2P est un projet dont le but est de construire, déployer, et maintenir un réseau fournissant 
-des communications sécurisées et anonymes. 
-Les gens utilisant I2P ont le contrôle de l'arbitrage entre l'anonymat, la fiabilité, 
-l'utilisation de la bande passante, et la latence. Il n'y a dans ce réseau, pas de centre sur lequel pourrait 
-être exercée une pression en vue de compromettre l'intégrité, la sécurité, ou l'anonymat du système. 
-Le réseau intègre sa propre reconfiguration dynamique en réponse aux diverses attaques, 
-et a été conçu pour utiliser de nouvelles ressources au fur et à mesure de leur disponibilité. 
-Bien entendu, tous les aspects du réseau sont publics et disponibles gratuitement.
            
-
-
            Contrairement à de nombreux autres réseaux anonymisants, I2P ne tente pas de procurer l'anonymat en masquant 
-l'initiateur et pas le destinataire, ou le contraire. I2P est conçu pour permettre  
-aux pairs l'utilisant de communiquer anonymement — l'émetteur et le récepteur sont non-identifiables  
-l'un par l'autre comme par un tiers. Par exemple, il y a aujourd'hui des sites web intra-I2P 
-(permettant la publication/hébergement anonymes) tout comme des serveurs mandataires HTTP vers le web normal 
-(permettant la navigation anonyme). La possibilité d'avoir des serveurs dans I2P est essentielle, 
-car il est plus que certain que n'importe quel proxy sortant vers l'Internet sera surveillé, désactivé, 
-ou même piraté pour tenter des attaques encore plus pernicieuses.
            
-
-
            Le réseau lui-même est "orienté messages": il est principalement constitué d'une couche IP sécurisée et anonyme, 
-dans laquelle les messages sont adressés à des clés cryptographiques (Destinations) et peuvent être sensiblement
-plus gros que des paquets IP. À titre d'exemples d'utilisation du réseau citons les "eepsites" (serveurs web hébergeant
-des applications Internet normales au sein d'I2P), un client BitTorrent ("I2PSnark"), 
-ou un système de stckage distribué.  Grâce à l'application I2PTunnel, 
-nous pouvons utiliser des applications TCP/IP traditionnelles sur I2P, telles que SSH, IRC, un proxy squid, et même 
-du flux audio. La plupart des gens n'utilisent pas I2P directement, ou ne ressentent même pas le besoin de savoir
-qu'ils l'utilisent. 
-Au lieu de ça ils verront une des application compatibles avec I2P, ou peut-être une petite application  
-de contrôle qui va activer ou désactiver divers proxies pour piloter la fonctionnalité d'anonymisation.
            
-
-
            Un des points clés de la conception, dus développement, et du test d'un réseau anonyme est la définition de son
-modèle de sécurité, car il n'existe nulle part un "vrai" anonymat, mais uniquement 
-des moyens d'augmenter les coûts d'identification de quelqu'un. Succinctement, le but d'I2P est de permettre de 
-communiquer dans des environnements hostiles en procurant un bon anonymat, mélangé à un trafic de camouflage  
-suffisant fourni par l'activité de ceux qui ont besoin de moins d'anonymat, de sorte que certains utilisateurs puissent
-se soustraire à la détection par un adversaire très puissant, quand d'autres pourront esquiver une entité plus faible,
-tout ceci sur le même réseau dans lequel les messages des uns sont fondamentalement indistinguables de ceux des 
-autres.
            
-
-
            Pourquoi?
            
-
            Il y a une multitude de raisons qui justifient que nous ayons besoin d'un système de communication anonyme,  
-et chacun a les siennes propres. Il y a de nombreux  
-autres efforts pour trouver les moyens de fournir divers niveaux  
-d'anonymat sur Internet, mais nous n'en avons trouvé aucun qui réponde à nos besoins ou à notre modèle de sécurité.
            
-
-
            Comment?
            
-
-
            Au premier coup d'œil le réseau est constitué d'un tas de nœuds ("routeurs") dotés d'un certain nombre
-de chemins virtuels entrants et sortants unidirectionnels
-(appelés "tunnels", expliqués sur la page routage en tunnel). 
-Chaque routeur est identifié par l'identifiant cryptographique "RouterIdentity", 
-typiquement de longue durée de vie. Ces routeurs communiquent par des mécanismes existants 
-(TCP, UDP, etc). Les applications clientes ont leur propre identifiant cryptographique ("Destination") qui leur 
-permet d'envoyer et de recevoir des messages. Ces clients peuvent se connecter à n'importe quel routeur et 
-autoriser l'allocation temporaire ("lease") de quelques tunnels qui seront utilisés pour l'envoi et la réception
-à travers le réseau. I2P dispose de sa propre base de donnée réseau interne 
-(avec une modification de l'algorithme Kademlia) pour une distribution sécurisée 
-des informations de routage et de contacts.
            
-
-
            
-Exemple de topologie du réseau
            
-
-
-
            Ci-dessus, Alice, Bob, Charlie, et Dave ont tous leur routeur, avec une seule Destination locale. 
-Ils ont chacun une paire de tunnels entrants à deux sauts par destination (repérés 1,2,3,4,5 et 6),
-et une petite partie des tunnels sortants de chacun de ces routeurs est montré avec des tunnels sortants à deux sauts.
-Pour simplifier, ne sont représentés ni les tunnels entrants de Charlie et les tunnels sortants de Dave, 
-ni le reste du groupe de tunnels sortants de chaque routeur (fourni par défaut avec quelques tunnels). 
-Quand Alice et Bob discutent ensemble, Alice envoie un message vers un de ses tunnels sortants (en rose) 
-avec pour cible un des tunnels entrants de Bob (3 ou 4, en vert). Elle sait qu'elle doit envoyer vers ces tunnels
-sur le bon routeur en interrogeant la base de donnée du réseau qui est actualisée en permanence 
-au fur et à mesure que les nouveaux baux sont autorisés et que les anciens expirent.
            
-  
-
            Si Bob veut répondre à Alice, il utilise simplement la même procédure: envoyer un message via un de ses 
-tunnels sortants en ciblant un des tunnels entrants d'Alice (tunnel 1 ou 2). Pour rendre les choses plus faciles, 
-la plupart des messages circulant entre Alice et Bob sont empaquetés "à la garlic", 
-embarquant les informations sur le bail actuel de l'expéditeur, de sorte que le destinataire puisse répondre 
-immédiatement sans avoir à interroger la base de donnée.
            
-
-
            Pour gérer une grande gamme d'attaques, I2P est entièrement décentralisé et en conséquence 
-il n'y a pas de serveur d'annuaire conservant des statistiques de performances et de fiabilité des routeurs 
-du réseau. Donc chaque routeur doit garder et entretenir les profils de divers routeurs 
-et est responsable de la sélection de pairs appropriés aux besoins d'anonymat, de performance et de fiabilité 
-des utilisateurs, comme expliqué sur la page sélection de pairs.
            
-
-
            Le réseau fait usage d'un nombre significatif de 
-techniques et algorithmes cryptographiques: la liste complète est constituée des 
-cryptages ElGamal à 2048bits, AES 256bits en mode CBC avec bourrage PKCS#5, 
-des signatures DSA à 1024bits, des hachages SHA256, de l'authentification de connexions station à station négociée en
-Diffie-Hellman 2048bit, et ElGamal / AES+SessionTag.
            
-
-
            Les contenus envoyés sur I2P sont cryptés à travers un cryptage en têtes d'ail ("garlic") à trois niveaux 
-(utilisé pour vérifier la réception du message par le destinataire), par le cryptage de tunnel (tous les messages
-traversant un tunnel sont cryptés par la passerelle du tunnel à l'intention du point de sortie du tunnel), 
-et par un cryptage de la couche transport inter routeurs (p.e. le transport TCP utilise des clés AES256 éphémères):
            
-
            Le cryptage de bout en bout (I2CP) (application cliente à application serveur) a été désactivée dans la version 0.6; 
-Le cryptage (garlic) de bout en bout (routeur I2P client à routeur I2P serveur) depuis le routeur "a" d'Alice 
-vers le "h" de Bob est restée.
-Remarquez l'utilisation différente des termes! Toutes les données transitant de "a" à "h" sont cryptées de bout en 
-bout, mais la connexion I2CP entre le routeur et les applications ne l'est pas!
-"a" et "h" sont les routeurs d'Alice et Bob, alors qu'Alice et Bob dans le schéma suivant sont les applications 
-qui tournent sur I2P.
            
-
-
            
-
-
            Les utilisations spécifiques de ces algorithmes sont précisées ailleurs.
            
-
-
            Les deux mécanismes principaux permettant l'usage du réseau à ceux qui ont besoin d'un anonymat fort 
-sont très explicitement le routage "garlic" retardé et des tunnels plus évolués incluant la possibilité d'appeler et 
-de croiser les messages. Ils sont actuellement planifiés pour la version 3.0, mais le routage "garlic" instantané et 
-les tunnels FIFO sont d'ores et déjà opérationnels. La version 2.0 permettra de mettre en place des routes réservées 
-(peut-être avec des pairs de confiance), ainsi que des transports plus souples et plus anonymes.
            
-
-
            Des questions on surgit à juste titre sur l'évolutivité d'I2P en terme d'échelle. Il y aura certainement plus 
-d'analyse avec le temps, mais l'intégration et la recherche des pairs devraient répondre à O(log(N)) 
-grâce à l'algorithme de la base de données, alors que les messages seraient plutôt 
-liés à O(1) (non dépendance à l'échelle), car les messages passent par K sauts du tunnel sortant 
-puis encore K sauts via le tunnel entrant, avec K inférieur ou égal à 3.
-La taille du réseau (N) n'a aucun impact.
            
-
-
            Quand?
            
-
            I2P a commencé en février 2003 en tant que proposition de modification de 
-Freenet pour lui permettre d'utiliser d'autres modes de transferts, comme 
-JMS, puis a évolué de son côté en  
-'anonCommFramework' en avril 2003, pour devenir I2P en juillet, l'écriture du code ayant sérieusement commencé 
-en août 2003.
-I2P est actuellement en phase de développement et suit sa feuille de route.
            
-
-
            Qui?
            
-
            Nous sommes une petite équipe répartie sur plusieurs continents, qui travaille à 
-l'avancement de différents aspects du projet.  Nous sommes complètement ouverts à l'arrivée d'autre développeurs 
-qui voudraient s'impliquer et à celle de quiconque préfèrerait participer d'autres façons, telles que la critique, 
-l'analyse de pair, le test, l'écriture d'applications compatibles, ou de documentation. Le système est totalement 
-"open source": le routeur et presque tout l'outil de développement sont de plein droit dans le domaine public avec
-quelques lignes de code sous licence BSD et Cryptix, et quelques applications comme I2PTunnel 
-et I2PSnark sous GPL. Presque tout est écrit en Java (1.5+), bien que quelques applications tierce partie soient  
-écrites en Python et autres langages. Le code fonctionne sur Oracle/Sun Java SE et 
-d'autres Machines Virtuelles Java.
-
            
-
-
            Où?
            
-
            Toute personne intéressée peut nous joindre sur le canal IRC #i2p actuellement hébergé 
-sur les serveurs irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p et irc.einirc.de.
-Il n'y a pas de rencontre de développement planifiée actuellement, mais 
-les archives sont disponibles.
            
-
-
            Le code source est disponible dans monotone.
            
-
-
            Plus d'infos
            
-
            
-Voir la table des matières de la documentation technique.
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/how_networkcomparisons.html b/www.i2p2/pages/how_networkcomparisons.html
deleted file mode 100644
index f3733e99..00000000
--- a/www.i2p2/pages/how_networkcomparisons.html
+++ /dev/null
@@ -1,198 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Compared to Tor and Freenet{% endblock %}
-{% block content %}
            There are a great many other applications and projects working on anonymous 
-communication and I2P has been inspired by much of their efforts.  This is not 
-a comprehensive list of anonymity resources - both freehaven's 
-Anonymity Bibliography
-and GNUnet's related projects
-serve that purpose well.  That said, a few systems stand out for further
-comparison. The following are discussed on this page:
            
-
              
-
            • Tor / Onion Routing
              • 
-
            • Freenet
              • 
-
            
-
            The following are discussed on the other networks page:
            
-
              
-
            • Morphmix and Tarzan
              • 
-
            • Mixminion / Mixmaster
              • 
-
            • JAP
              • 
-
            • MUTE / AntsP2P
              • 
-
            • Haystack
              • 
-
            
-
-
            The content of this page is subject to update, discussion and dispute, and we welcome comments and additions.
-You may contribute an analysis by entering a
-new ticket on trac.i2p2.de.
-
            
-
-
            Tor / Onion Routing
            
-[Tor] 
-   [Onion Routing]
-
            Tor and Onion Routing are both anonymizing proxy networks, 
-allowing people to tunnel out through their low latency mix 
-network. The two primary differences between Tor / 
-Onion-Routing and I2P are again related to differences in 
-the threat model and the out-proxy design (though Tor
-supports hidden services as well).  In addition, Tor
-takes the directory-based approach - providing a 
-centralized point to manage the overall 'view' of the 
-network, as well as gather and report statistics, as 
-opposed to I2P's distributed network 
-database and peer selection.
            
-
-
            The I2P/Tor outproxy functionality does have a few 
-substantial weaknesses against certain attackers - 
-once the communication leaves the mixnet, global passive
-adversaries can more easily mount traffic analysis.  In 
-addition, the outproxies have access to the cleartext 
-of the data transferred in both directions, and 
-outproxies are prone to abuse, along with all of the 
-other security issues we've come to know and love with 
-normal Internet traffic.
            
-
-
            However, many people don't need to worry about those 
-situations, as they are outside their threat model.  It
-is, also, outside I2P's (formal) functional scope (if people want
-to build outproxy functionality on top of an anonymous
-communication layer, they can).  In fact, some I2P users
-currently take advantage of Tor to outproxy.
            
-
-
-
            Comparison of Tor and I2P Terminology
            
-While Tor and I2P are similar in many ways, much of the terminology is different.
-
-
            TorI2P
-
            CellMessage
-
            ClientRouter or Client
-
            CircuitTunnel
-
            DirectoryNetDb
-
            Directory ServerFloodfill Router
-
            Entry GuardsFast Peers
-
            Entry NodeInproxy
-
            Exit NodeOutproxy
-
            Hidden ServiceEepsite or Destination
-
            Hidden Service DescriptorLeaseSet
-
            Introduction pointInbound Gateway
-
            NodeRouter
-
            Onion ProxyI2PTunnel Client (more or less)
-
            RelayRouter
-
            Rendezvous Pointsomewhat like Inbound Gateway + Outbound Endpoint
-
            Router DescriptorRouterInfo
-
            ServerRouter
-
            
-
-
            Benefits of Tor over I2P
            
-
              
- 
            • Much bigger user base; much more visibility in the academic and hacker communities; benefits from
-     formal studies of anonymity, resistance, and performance;
-     has a non-anonymous, visible, university-based leader
              • 
- 
            • Has already solved some scaling issues I2P has yet to address
              • 
- 
            • Has significant funding
              • 
- 
            • Has more developers, including several that are funded
              • 
- 
            • More resistant to state-level blocking due to TLS transport layer and bridges
-     (I2P has proposals for "full restricted routes" but these are not yet implemented)
              • 
- 
            • Big enough that it has had to adapt to blocking and DOS attempts
              • 
- 
            • Designed and optimized for exit traffic, with a large number of exit nodes
              • 
- 
            • Better documentation, has formal papers and specifications, better website, many more translations
              • 
- 
            • More efficient with memory usage
              • 
- 
            • Tor client nodes have very low bandwidth overhead
              • 
- 
            • Centralized control reduces the complexity at each
-     node and can efficiently address Sybil attacks
              • 
- 
            • A core of high capacity nodes provides higher
-     throughput and lower latency
              • 
- 
            • C, not Java (ewww)
              • 
-
            
-
-
            Benefits of I2P over Tor
            
-
              
- 
            • Designed and optimized for hidden services, which are much faster than in Tor
              • 
- 
            • Fully distributed and self organizing
              • 
- 
            • Peers are selected by continuously profiling and ranking performance,
-     rather than trusting claimed capacity
              • 
- 
            • Floodfill peers ("directory servers") are varying and untrusted,
-     rather than hardcoded
              • 
- 
            • Small enough that it hasn't been blocked or DOSed much, or at all
              • 
- 
            • Peer-to-peer friendly
              • 
- 
            • Packet switched instead of circuit switched
-  
                
-   
              • implicit transparent load balancing of messages 
-      across multiple peers, rather than a single path
                • 
-   
              • resilience vs. failures by running multiple 
-       tunnels in parallel, plus rotating tunnels
                • 
-   
              • scale each client's connections at O(1) instead 
-       of O(N) (Alice has e.g. 2 inbound tunnels that are 
-       used by all of the peers Alice is talking with, 
-       rather than a circuit for each)
                • 
-  
              • 
- 
            • Unidirectional tunnels instead of bidirectional
-    circuits, doubling the number of nodes a peer has to
-    compromise to get the same information.
              • 
- 
            • Protection against detecting client activity, even
-     when an attacker is participating in the tunnel, as
-     tunnels are used for more than simply passing end 
-     to end messages (e.g. netDb, tunnel management, 
-     tunnel testing)
              • 
- 
            • Tunnels in I2P are short lived, decreasing the number
-     of samples that an attacker can use to mount an 
-     active attack with, unlike circuits in Tor, which are
-     typically long lived.
              • 
- 
            • I2P APIs are designed specifically for anonymity and
-     security, while SOCKS is designed for functionality.
              • 
- 
            • Essentially all peers participate in routing for others
              • 
- 
            • The bandwidth overhead of being a full peer is low, 
-     while in Tor, while client nodes don't require much
-     bandwidth, they don't fully participate in the mixnet.
              • 
- 
            • Integrated automatic update mechanism
              • 
- 
            • Both TCP and UDP transports
              • 
- 
            • Java, not C (ewww)
              • 
-
            
-
-
            Other potential benefits of I2P but not yet implemented
            
-
            ...and may never be implemented, so don't count on them!
            
-
              
- 
            • Defense vs. message count analysis by garlic wrapping 
-     multiple messages
              • 
- 
            • Defense vs. long term intersection by adding delays 
-     at various hops (where the delays are not discernible
-     by other hops)
              • 
- 
            • Various mixing strategies at the tunnel level (e.g.
-     create a tunnel that will handle 500 messages / minute,
-     where the endpoint will inject dummy messages if there
-     are insufficient messages, etc)
              • 
-
            
-
-
-
            Freenet
            
-[Freenet]
-
-
            Freenet is a fully distributed, peer to peer anonymous publishing network, offering 
-secure ways to store data, as well as some approaches attempting to address the loads
-of a flash flood.  While Freenet is designed as a distributed data store, people have
-built applications on top of it to do more generic anonymous communication, such as 
-static websites and message boards.
            
-
-
            Compared to I2P, Freenet offers some substantial benefits - it is a distributed data
-store, while I2P is not, allowing people to retrieve the content published by others 
-even when the publisher is no longer online.  In addition, it should be able to 
-distribute popular data fairly efficiently.  I2P itself does not and will not provide 
-this functionality.  On the other hand, there is overlap for users who simply want to 
-communicate with each other anonymously through websites, message boards, file sharing
-programs, etc.  There have also been some attempts to develop a distributed data 
-store to run on top of I2P,
-(most recently a port of Tahoe-LAFS)
-but nothing is yet ready for general use.
            
-
-
            However, even ignoring any implementations issues, there are some concerns 
-about Freenet's algorithms from both a scalability and anonymity perspective, owing 
-largely to Freenet's heuristic driven routing.  The interactions of various techniques 
-certainly may successfully deter various attacks, and perhaps some aspects of the 
-routing algorithms will provide the hoped for scalability.  Unfortunately, not much
-analysis of the algorithms involved has resulted in positive results, but there is still
-hope.  At the very least, Freenet does provide substantial anonymity against an attacker
-who does not have the resources necessary to analyze it further.
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/how_networkdatabase.html b/www.i2p2/pages/how_networkdatabase.html
deleted file mode 100644
index 3f44ccba..00000000
--- a/www.i2p2/pages/how_networkdatabase.html
+++ /dev/null
@@ -1,764 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}The Network Database{% endblock %}
-{% block content %}
-
-
            
-  Updated June 2012, current as of router version 0.9
-
            
-
-
            Overview
            
-
-
            
-  I2P's netDb is a specialized distributed database, containing 
-  just two types of data - router contact information (RouterInfos) and destination contact
-  information (LeaseSets).  Each piece of data is signed by the appropriate party and verified
-  by anyone who uses or stores it.  In addition, the data has liveliness information
-  within it, allowing irrelevant entries to be dropped, newer entries to replace
-  older ones, and protection against certain classes of attack.
-
            
-
-
            
-  The netDb is distributed with a simple technique called "floodfill",
-  where a subset of all routers, called "floodfill routers", maintains the distributed database.
-
            
-
-
-
            RouterInfo
            
-
-
            
-  When an I2P router wants to contact another router, they need to know some 
-  key pieces of data - all of which are bundled up and signed by the router into
-  a structure called the "RouterInfo", which is distributed with the SHA256 of the router's identity
-  as the key.  The structure itself contains:
-
            
-
              
-  
            • The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA signing key, and a certificate)
              • 
-  
            • The contact addresses at which it can be reached (e.g. TCP: example.org port 4108)
              • 
-  
            • When this was published
              • 
-  
            • A set of arbitrary text options
              • 
-  
            • The signature of the above, generated by the identity's DSA signing key
              • 
-
            
-
-
            
-  The following text options, while not strictly required, are expected
-  to be present:
-
            
-
              
-  
            • caps
-    (Capabilities flags - used to indicate floodfill participation, approximate bandwidth, and perceived reachability)
-  
            • coreVersion
-    (The core library version, always the same as the router version)
-  
            • netId = 2
-    (Basic network compatibility - A router will refuse to communicate with a peer having a different netId)
-  
            • router.version
-    (Used to determine compatibility with newer features and messages)
-  
            • stat_uptime = 90m
-    (Always sent as 90m, for compatibility with an older scheme where routers published their actual uptime,
-    and only sent tunnel requests to peers whose was more than 60m)
-
            
-
-
            
-  These values are used by other routers for basic decisions.
-  Should we connect to this router? Should we attempt to route a tunnel through this router?
-  The bandwidth capability flag, in particular, is used only to determine whether
-  the router meets a minimum threshold for routing tunnels.
-  Above the minimum threshold, the advertised bandwidth is not used or trusted anywhere
-  in the router, except for display in the user interface and for debugging and network analysis.
-
            
-
-
-
            
-  Additional text options include
-  a small number of statistics about the router's health, which are aggregated by
-  sites such as stats.i2p
-  for network performance analysis and debugging.
-  These statistics were chosen to provide data crucial to the developers,
-  such as tunnel build success rates, while balancing the need for such data
-  with the side-effects that could result from revealing this data.
-  Current statistics are limited to:
-
            
-
              
-  
            • Client and exploratory tunnel build success, reject, and timeout rates
-  
            • 1 hour average number of participating tunnels
-
            
-
-
            
-  The data 
-  published can be seen in the router's user interface,
-  but is not used or trusted within the router.
-  As the network has matured, we have gradually removed most of the published
-  statistics to improve anonymity, and we plan to remove more in future releases.
-
            
-
-
            
-  RouterInfo specification
-
            
-
            
-  RouterInfo Javadoc
-
            
-
-
            RouterInfo Expiration
            
-
            
-  RouterInfos have no set expiration time.
-  Each router is free to maintain its own local policy to trade off the frequency of RouterInfo lookups
-  with memory or disk usage.
-  In the current implementation, there are the following general policies:
-
            
-
              
-  
            • There is no expiration during the first hour of uptime, as the persistent stored data may be old.
              • 
-  
            • There is no expiration if there are 25 or less RouterInfos.
              • 
-  
            • As the number of local RouterInfos grows, the expiration time shrinks, in an attempt to maintain
-    a reasonable number RouterInfos. The expiration time with less than 120 routers is 72 hours,
-    while expiration time with 300 routers is around 30 hours.
              • 
-  
            • RouterInfos containing SSU introducers expire in about an hour, as
-    the introducer list expires in about that time.
              • 
-  
            • Floodfills use a short expiration time (1 hour) for all local RouterInfos, as valid RouterInfos will
-    be frequently republished to them.
              • 
-
            
-
-
            RouterInfo Persistent Storage
            
-
-
            
-  RouterInfos are periodically written to disk so that they are available after a restart.
-
            
-
-
-
            LeaseSet
            
-
-
            
-  The second piece of data distributed in the netDb is a "LeaseSet" - documenting
-  a group of tunnel entry points (leases) for a particular client destination.  
-  Each of these leases specify the following information:
-  
              
-    
            • The tunnel gateway router (by specifying its identity)
              • 
-    
            • The tunnel ID on that router to send messages with (a 4 byte number)
              • 
-    
            • When that tunnel will expire.
              • 
-  
            
-  The LeaseSet itself is stored in the netDb under
-  the key derived from the SHA256 of the destination.
-
            
-
-
            
-  In addition to these leases, the LeaseSet includes:
-  
              
-    
            • The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA signing key and a certificate)
              • 
-    
            • Additional encryption public key: used for end-to-end encryption of garlic messages
              • 
-    
            • Additional signing public key: intended for LeaseSet revocation, but is currently unused.
              • 
-    
            • Signature of all the LeaseSet data, to make sure the Destination published the LeaseSet.
              • 
-  
            
-
            
-
-
            
-  Lease specification
-  
            
-  LeaseSet specification
-
            
-
            
-  Lease Javadoc
-  
            
-  LeaseSet Javadoc
-
            
-
-
-
            Unpublished LeaseSets
            
-
            
-  A LeaseSet for a destination used only for outgoing connections is unpublished.
-  It is never sent for publication to a floodfill router.
-  "Client" tunnels, such as those for web browsing and IRC clients, are unpublished.
-  Servers will still be able to send messages back to those unpublished destinations,
-  because of I2NP storage messages.
-
            
-
-
-
-
            Revoked LeaseSets
            
-
            
-  A LeaseSet may be revoked by publishing a new LeaseSet with zero leases.
-  Revocations must be signed by the additional signing key in the LeaseSet.
-  Revocations are not fully implemented, and it is unclear if they have any practical use.
-  This is the only planned use for that signing key, so it is currently unused.
-
            
-
-
            Encrypted LeaseSets
            
-
            
-  In an encrypted LeaseSet, all Leases are encrypted with a separate DSA key.
-  The leases may only be decoded, and thus the destination may only be contacted,
-  by those with the key.
-  There is no flag or other direct indication that the LeaseSet is encrypted.
-  Encrypted LeaseSets are not widely used, and it is a topic for future work to
-  research whether the user interface and implementation of encrypted LeaseSets could be improved.
-
            
-
-
            LeaseSet Expiration
            
-
            
-  All Leases (tunnels) are valid for 10 minutes; therefore, a LeaseSet expires
-  10 minutes after the earliest creation time of all its Leases.
-
            
-
-
            LeaseSet Persistent Storage
            
-
            
-  There is no persistent storage of LeaseSet data since they expire so quickly.
-
            
-
-
-
            Bootstrapping
            
-
            
-  The netDb is decentralized, however you do need at
-  least one reference to a peer so that the integration process
-  ties you in.  This is accomplished by "reseeding" your router with the RouterInfo
-  of an active peer - specifically, by retrieving their routerInfo-$hash.dat
-  file and storing it in your netDb/ directory.  Anyone can provide
-  you with those files - you can even provide them to others by exposing your own
-  netDb directory.  To simplify the process,
-  volunteers publish their netDb directories (or a subset) on the regular (non-i2p) network,
-  and the URLs of these directories are hardcoded in I2P.
-  When the router starts up for the first time, it automatically fetches from
-  one of these URLs, selected at random.
-
            
-
-
            Floodfill
            
-
            
-  The floodfill netDb is a simple distributed storage mechanism.
-  The storage algorithm is simple: send the data to the closest peer that has advertised itself
-  as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them 
-  for the entry to be sent, verifying its proper insertion / distribution.  If the 
-  verification peer doesn't reply, or they don't have the entry, the sender 
-  repeats the process.  When the peer in the floodfill netDb receives a netDb 
-  store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers.
-  The peers selected are the ones closest (according to the XOR-metric) to a specific key.
-
            
-
            
-  Determining who is part of the floodfill netDb is trivial - it is exposed in each 
-  router's published routerInfo as a capability.
-
            
-
            
-  Floodfills have no central authority and do not form a "consensus" -
-  they only implement a simple DHT overlay.
-
            
-
-
-
-
            Floodfill Router Opt-in
            
-
-
            
-  Unlike Tor, where the directory servers are hardcoded and trusted,
-  and operated by known entities,
-  the members of the I2P floodfill peer set need not be trusted, and
-  change over time.
-
            
-
            
-  To increase reliability of the netDb, and minimize the impact
-  of netDb traffic on a router, floodfill is automatically enabled
-  only on routers that are configured with high bandwidth limits.
-  Routers with high bandwidth limits (which must be manually configured,
-  as the default is much lower) are presumed to be on lower-latency
-  connections, and are more likely to be available 24/7.
-  The current minimum share bandwidth for a floodfill router is 128 KBytes/sec.
-
            
-
            
-  In addition, a router must pass several additional tests for health
-  (outbound message queue time, job lag, etc.) before floodfill operation is
-  automatically enabled.
-
            
-
            
-  With the current rules for automatic opt-in, approximately 6% of
-  the routers in the network are floodfill routers.
-
            
-
-
            
-  While some peers are manually configured to be floodfill,
-  others are simply high-bandwidth routers who automatically volunteer
-  when the number of floodfill peers drops below a threshold.
-  This prevents any long-term network damage from losing most or all
-  floodfills to an attack.
-  In turn, these peers will un-floodfill themselves when there are
-  too many floodfills outstanding.
-
            
-
-
            Floodfill Router Roles
            
-
            
-  A floodfill router's only services that are in addition to those of non-floodfill routers
-  are in accepting netDb stores and responding to netDb queries.
-  Since they are generally high-bandwidth, they are more likely to participate in a high number of tunnels
-  (i.e. be a "relay" for others), but this is not directly related to their distributed database services.
-
            
-
-
-
            Kademlia Closeness Metric
            
-
            
-  The netDb uses a simple Kademlia-style XOR metric to determine closeness.
-  The SHA256 hash of the key being looked up or stored is XOR-ed with
-  the hash of the router in question to determine closeness.
-  A modification to this algorithm is done to increase the costs of Sybil attacks.
-  Instead of the SHA256 hash of the key being looked up of stored, the SHA256 hash is taken
-  of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd).
-
            
-
-
-
-
            Storage, Verification, and Lookup Mechanics
            
-
-
            RouterInfo Storage to Peers
            
-
            
-  I2NP DatabaseStoreMessages containing the local RouterInfo are exchanged with peers
-  as a part of the initialization of a
-  NTCP
-  or
-  SSU
-  transport connection.
-
            
-
-
-
            LeaseSet Storage to Peers
            
-
            
-  I2NP DatabaseStoreMessages containing the local LeaseSet are periodically exchanged with peers
-  by bundling them in a garlic message along with normal traffic from the related Destination.
-  This allows an initial response, and later responses, to be sent to an appropriate Lease,
-  without requiring any LeaseSet lookups, or requiring the communicating Destinations to have published LeaseSets at all.
-
            
-
-
-
            RouterInfo Storage to Floodfills
            
-
            
-  A router publishes its own RouterInfo by directly connecting to a floodfill router
-  and sending it a I2NP DatabaseStoreMessage
-  with a nonzero Reply Token. The message is not end-to-end garlic encrypted,
-  as this is a direct connection, so there are no intervening routers
-  (and no need to hide this data anyway).
-  The floodfill router replies with a
-  I2NP DeliveryStatusMessage,
-  with the Message ID set to the value of the Reply Token.
-
            
-
-
-
-
-
            LeaseSet Storage to Floodfills
            
-
            
-  Storage of LeaseSets is much more sensitive than for RouterInfos, as a router
-  must take care that the LeaseSet cannot be associated with the router.
-
            
-
-
            
-  A router publishes a local LeaseSet by
-  sending a I2NP DatabaseStoreMessage
-  with a nonzero Reply Token over an outbound client tunnel for that Destination.
-  The message is end-to-end garlic encrypted using the Destination's Session Key Manager,
-  to hide the message from the tunnel's outbound endpoint.
-  The floodfill router replies with a
-  I2NP DeliveryStatusMessage,
-  with the Message ID set to the value of the Reply Token.
-  This message is sent back to one of the client's inbound tunnels.
-
            
-
-
-
-
-
-
-
-
            Flooding
            
-
            
-  After a floodfill router receives a DatabaseStoreMessage containing a
-  valid RouterInfo or LeaseSet which is newer than that previously stored in its
-  local NetDb, it "floods" it.
-  To flood a NetDb entry, it looks up the 7 floodfill routers closest to the key
-  of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.)
-
            
-
            
-  It then directly connects to each of the 7 peers
-  and sends it a I2NP DatabaseStoreMessage
-  with a zero Reply Token. The message is not end-to-end garlic encrypted,
-  as this is a direct connection, so there are no intervening routers
-  (and no need to hide this data anyway).
-  The other routers do not reply or re-flood, as the Reply Token is zero.
-
            
-
-
-
            RouterInfo and LeaseSet Lookup
            
-
            
-  The I2NP DatabaseLookupMessage is used to request a netdb entry from a floodfill router.
-  Lookups are sent out one of the router's outbound exploratory tunnels.
-  The replies are specified to return via one of the router's inbound exploratory tunnels.
-
            
-
            
-  Lookups are generally sent to the two "good" (the connection doesn't fail) floodfill routers closest to the requested key, in parallel.
-
            
-
            
-  If the key is found locally by the floodfill router, it responds with a
-  I2NP DatabaseStoreMessage.
-  If the key is not found locally by the floodfill router, it responds with a
-  I2NP DatabaseSearchReplyMessage
-  containing a list of other floodfill routers close to the key.
-
            
-
-
            
-  Lookups are not encrypted and thus are vulnerable to snooping by the outbound endpoint
-  (OBEP) of the client tunnel.
-
            
-
            
-  As the requesting router does not reveal itself, there is no recipient public key for the floodfill router to
-  encrypt the reply with. Therefore, the reply is exposed to the inbound gateway (IBGW)
-  of the inbound exploratory tunnel.
-  An appropriate method of encrypting the reply is a topic for future work.
-
            
-
-
            
-  (Reference:
-  Hashing it out in Public Sections 2.2-2.3 for terms below in italics)
-
            
-
            
-  Due to the relatively small size of the network and the flooding redundancy of 8x,
-  lookups are usually O(1) rather than O(log n) --
-  a router is highly likely to know a floodfill router close enough to the key to get the answer on the first try.
-  In releases prior to 0.8.9, routers used a lookup redundancy of two
-  (that is, two lookups were performed in parallel to different peers), and
-  neither recursive nor iterative routing for lookups was implemented.
-  Queries were sent through multiple routes simultaneously
-  to reduce the chance of query failure.
-
            
-
            
-  As of release 0.8.9, iterative lookups are implemented with no lookup redundancy.
-  This is a more efficient and reliable lookup that will work much better
-  when not all floodfill peers are known, and it removes a serious
-  limitation to network growth. As the network grows and each router knows only a small
-  subset of the floodfill peers, lookups will become O(log n).
-  Even if the peer does not return references closer to the key, the lookup continues with
-  the next-closest peer, for added robustness, and to prevent a malicious floodfill from
-  black-holing a part of the key space. Lookups continue until a total lookup timeout is reached,
-  or the maximum number of peers is queried.
-
            
-
            
-  Node IDs are verifiable in that we use the router hash directly as both the node ID and the Kademlia key.
-  Incorrect responses that are not closer to the search key are generally ignored.
-  Given the current size of the network, a router has
-  detailed knowledge of the neighborhood of the destination ID space.
-
            
-
-
-
-
            RouterInfo Storage Verification
            
-
            
-  To verify a storage was successful, a router simply waits about 10 seconds,
-  then sends a lookup to another floodfill router close to the key
-  (but not the one the store was sent to).
-  Lookups sent out one of the router's outbound exploratory tunnels.
-  Lookups are end-to-end garlic encrypted to prevent snooping by the outbound endpoint(OBEP).
-
            
-
-
            LeaseSet Storage Verification
            
-
            
-  To verify a storage was successful, a router simply waits about 10 seconds,
-  then sends a lookup to another floodfill router close to the key
-  (but not the one the store was sent to).
-  Lookups sent out one of the outbound client tunnels for the destination of the LeaseSet being verified.
-  To prevent snooping by the OBEP of the outbound tunnel,
-  lookups are end-to-end garlic encrypted.
-  The replies are specified to return via one of the client's inbound tunnels.
-
            
-
            
-  As for regular lookups, the reply is unencrypted,
-  thus exposing the reply to the inbound gateway (IBGW) of the reply tunnel, and
-  an appropriate method of encrypting the reply is a topic for future work.
-  As the IBGW for the reply is one of the gateways published in the LeaseSet,
-  the exposure is minimal.
-
            
-
-
-
-
            Exploration
            
-
            
-  Exploration is a special form of netdb lookup, where a router attempts to learn about
-  new routers.
-  It does this by sending a floodfill router a I2NP DatabaseLookupMessage, looking for a random key.
-  As this lookup will fail, the floodfill would normally respond with a
-  I2NP DatabaseSearchReplyMessage containing hashes of floodfill routers close to the key.
-  This would not be helpful, as the requesting router probably already knows those floodfills,
-  and it would be impractical to add ALL floodfill routers to the "don't include" field of the lookup.
-  For an exploration query, the requesting router adds a router hash of all zeros to the
-  "don't include" field of the DatabaseLookupMessage.
-  The floodfill will then respond only with non-floodfill routers close to the requested key.
-
            
-
-
-
            Notes on Lookup Responses
            
-
            
-   The response to a lookup request is either a Database Store Message (on success) or a
-   Database Search Reply Message (on failure). The DSRM contains a 'from' router hash field
-   to indicate the source of the reply; the DSM does not.
-   The DSRM 'from' field is unauthenticated and may be spoofed or invalid.
-   There are no other response tags. Therefore, when making multiple requests in parallel, it is
-   difficult to monitor the performance of the various floodfill routers.
-
            
-
-
-
            MultiHoming
            
-
-
            
-  Destinations may be hosted on multiple routers simultaneously, by using the same
-  private and public keys (traditionally stored in eepPriv.dat files).
-  As both instances will periodically publish their signed LeaseSets to the floodfill peers,
-  the most recently published LeaseSet will be returned to a peer requesting a database lookup.
-  As LeaseSets have (at most) a 10 minute lifetime, should a particular instance go down,
-  the outage will be 10 minutes at most, and generally much less than that.
-  The multihoming function has been verified and is in use by several services on the network.
-
            
-
-
            Threat Analysis
            
-
            
-  Also discussed on the threat model page.
-
            
-
            
-  A hostile user may attempt to harm the network by
-  creating one or more floodfill routers and crafting them to offer
-  bad, slow, or no responses.
-  Some scenarios are discussed below.
-
            
-
-
            General Mitigation Through Growth
            
-
            
-  There are currently almost 100 floodfill routers in the network.
-  Most of the following attacks will become more difficult, or have less impact,
-  as the network size and number of floodfill routers increase.
-
            
-
-
-
            General Mitigation Through Redundancy
            
-
            
-  Via flooding, all netdb entries are stored on the 8 floodfill routers closest to the key.
-
            
-
-
-
            Forgeries
            
-
            
-  All netdb entries are signed by their creators, so no router may forge a
-  RouterInfo or LeaseSet.
-
            
-
-
            Slow or Unresponsive
            
-
            
-  Each router maintains an expanded set of statistics in the
-  peer profile for each floodfill router,
-  covering various quality metrics for that peer.
-  The set includes:
-
            
-
              
-  
            • Average response time
-  
            • Percentage of queries answered with the data requested
-  
            • Percentage of stores that were successfully verified
-  
            • Last successful store
-  
            • Last successful lookup
-  
            • Last response
-
            
-
-
            
-  Each time a router needs to make a determination on which floodfill router is closest to a key,
-  it uses these metrics to determine which floodfill routers are "good".
-  The methods, and thresholds, used to determine "goodness" are relatively new, and
-  are subject to further analysis and improvement.
-  While a completely unresponsive router will quickly be identified and avoided,
-  routers that are only sometimes malicious may be much harder to deal with.
-
            
-
-
-
            Sybil Attack (Full Keyspace)
            
-
            
-  An attacker may mount a
-  Sybil attack
-  by creating a large number of floodfill routers spread throughout the keyspace.
-
            
-
-
            
-  (In a related example, a researcher recently created a
-  large number of Tor relays.)
-
-  If successful, this could be an effective DOS attack on the entire network.
-
            
-
-
            
-  If the floodfills are not sufficiently misbehaving to be marked as "bad" using the peer profile
-  metrics described above, this is a difficult scenario to handle.
-  Tor's response can be much more nimble in the relay case, as the suspicious relays
-  can be manually removed from the consensus.
-  Some possible responses for the I2P network are listed below, however none of them is completely satisfactory:
-
            
-
              
-  
            • Compile a list of bad router hashes or IPs, and announce the list through various means
-    (console news, website, forum, etc.); users would have to manually download the list and
-    add it to their local "blacklist"
-  
            • Ask everyone in the network to enable floodfill manually (fight Sybil with more Sybil)
-  
            • Release a new software version that includes the hardcoded "bad" list
-  
            • Release a new software version that improves the peer profile metrics and thresholds,
-    in an attempt to automatically identify the "bad" peers
-  
            • Add software that disqualifies floodfills if too many of them are in a single IP block
-  
            • Implement an automatic subscription-based blacklist controlled by a single individual or group.
-    This would essentially implement a portion of the Tor "consensus" model.
-    Unfortunately it would also give a single individual or group the power to
-    block participation of any particular router or IP in the network,
-    or even to completely shutdown or destroy the entire network.
-
            
-
-
            
-This attack becomes more difficult as the network size grows.
-
            
-
-
-
-
            Sybil Attack (Partial Keyspace)
            
-
            
-  An attacker may mount a
-  Sybil attack
-  by creating a small number (8-15) of floodfill routers clustered closely in the keyspace,
-  and distribute the RouterInfos for these routers widely.
-  Then, all lookups and stores for a key in that keyspace would be directed
-  to one of the attacker's routers.
-  If successful, this could be an effective DOS attack on a particular eepsite, for example.
-
            
-
            
-  As the keyspace is indexed by the cryptographic (SHA256) Hash of the key,
-  an attacker must use a brute-force method to repeatedly generate router hashes
-  until he has enough that are sufficiently close to the key.
-  The amount of computational power required for this, which is dependent on network
-  size, is unknown.
-
            
-
-
            
-  As a partial defense against this attack,
-  the algorithm used to determine Kademlia "closeness" varies over time.
-  Rather than using the Hash of the key (i.e. H(k)) to determine closeness,
-  we use the Hash of the key appended with the current date string, i.e. H(k + YYYYMMDD).
-  A function called the "routing key generator" does this, which transforms the original key into a "routing key".
-  In other words, the entire netdb keyspace "rotates" every day at UTC midnight.
-  Any partial-keyspace attack would have to be regenerated every day, for
-  after the rotation, the attacking routers would no longer be close
-  to the target key, or to each other.
-
            
-
            
-This attack becomes more difficult as the network size grows.
-
            
-
-
            
-  One consequence of daily keyspace rotation is that the distributed network database
-  may become unreliable for a few minutes after the rotation --
-  lookups will fail because the new "closest" router has not received a store yet.
-  The extent of the issue, and methods for mitigation
-  (for example netdb "handoffs" at midnight)
-  are a topic for further study.
-
            
-
-
-
            Bootstrap Attacks
            
-
            
-  An attacker could attempt to boot new routers into an isolated
-  or majority-controlled network by taking over a reseed website,
-  or tricking the developers into adding his reseed website
-  to the hardcoded list in the router.
-
            
-
            
-  Several defenses are possible, and most of these are planned:
-
            
-
              
-  
            • Disallow fallback from HTTPS to HTTP for reseeding.
-    A MITM attacker could simply block HTTPS, then respond to the HTTP.
-  
            • Changing the reseed task to fetch a subset of RouterInfos from
-    each of several reseed sites rather than using only a single site
-  
            • Creating an out-of-network reseed monitoring service that
-    periodically polls reseed websites and verifies that the
-    data are not stale or inconsistent with other views of the network
-  
            • Bundling reseed data in the installer
-
            
-
-
            Query Capture
            
-
            
-  See also lookup
-  (Reference:
-  Hashing it out in Public Sections 2.2-2.3 for terms below in italics)
-
            
-
            
-  Similar to a bootstrap attack, an attacker using a floodfill router could attempt to "steer"
-  peers to a subset of routers controlled by him by returning their references.
-
            
-
            
-  This is unlikely to work via exploration, because exploration is a low-frequency task.
-  Routers acquire a majority of their peer references through normal tunnel building activity.
-  Exploration results are generally limited to a few router hashes,
-  and each exploration query is directed to a random floodfill router.
-
            
-
            
-  As of release 0.8.9, iterative lookups are implemented.
-  For floodfill router references returned in a
-  I2NP DatabaseSearchReplyMessage
-  response to a lookup,
-  these references are followed if they are closer (or the next closest) to the lookup key.
-  The requesting router does not trust that the references are
-  closer to the key (i.e. they are verifiably correct.
-  The lookup also does not stop when no closer key is found, but continues by querying the
-  next-closet node, until the timeout or maximum number of queries is reached.
-  This prevents a malicious floodfill from black-holing a part of the key space.
-  Also, the daily keyspace rotation requires an attacker to regenerate a router info
-  within the desired key space region.
-  This design ensures that the query capture attack described in
-  Hashing it out in Public
-  is much more difficult.
-
            
-
-
            DHT-Based Relay Selection
            
-
            
-  (Reference:
-  Hashing it out in Public Section 3)
-
            
-
            
-  This doesn't have much to do with floodfill, but see
-  the peer selection page
-  for a discussion of the vulnerabilities of peer selection for tunnels.
-
            
-
-
            Information Leaks
            
-
            
-  (Reference:
-  In Search of an Anonymous and Secure Lookup Section 3)
-
            
-
            
-  This paper addresses weaknesses in the "Finger Table" DHT lookups used by Torsk and NISAN.
-  At first glance, these do not appear to apply to I2P. First, the use of DHT by Torsk and NISAN
-  is significantly different from that in I2P. Second, I2P's network database lookups are only
-  loosely correlated to the peer selection and
-  tunnel building processes; only previously-known peers
-  are used for tunnels.
-  Also, peer selection is unrelated to any notion of DHT key-closeness.
-
            
-
            
-  Some of this may actually be more interesting when the I2P network gets much larger.
-  Right now, each router knows a large proportion of the network, so looking up a particular
-  Router Info in the network database is not strongly indicative of a future intent to use
-  that router in a tunnel. Perhaps when the network is 100 times larger, the lookup may be
-  more correlative. Of course, a larger network makes a Sybil attack that much harder.
-
            
-
            
-  However, the general issue of DHT information leakage in I2P needs further investigation.
-  The floodfill routers are in a position to observe queries and gather information.
-  Certainly, at a level of f = 0.2 (20% malicious nodes, as specifed in the paper)
-  we expect that many of the Sybil threats we describe
-  (here,
-  here and
-  here)
-  become problematic for several reasons.
-
            
-
-
-
            History
            
-
            
-  Moved to the netdb discussion page.
-
            
-
-
            Future Work
            
-
            
-  End-to-end encryption of additional netDb lookups and responses.
-
            
-
            
-  Better methods for tracking lookup responses.
-
            
-
-
-{% endblock %}
-
diff --git a/www.i2p2/pages/how_peerselection.html b/www.i2p2/pages/how_peerselection.html
deleted file mode 100644
index 429a028d..00000000
--- a/www.i2p2/pages/how_peerselection.html
+++ /dev/null
@@ -1,259 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Peer Profiling and Selection{% endblock %}
-{% block content %}
-
-Updated July 2010 for release 0.8
-
-
            Overview
            
-
-
            Peer Profiling
            
-
-
            Peer profiling is the process of collecting data based on the observed performance
-of other routers or peers, and classifying those peers into groups.
-Profiling does not use any claimed performance data published by the peer itself
-in the network database.
-
-
            
-Profiles are used for two purposes:
-
              
-
            1. Selecting peers to relay our traffic through, which is discussed below
-
            2. Choosing peers from the set of floodfill routers to use for network database storage and queries,
-    which is discussed on the network database page
-
            
-
-
-
            Peer Selection
            
-
            Peer selection is the process of choosing which routers
-on the network we want to relay our messages to go through (which peers will we 
-ask to join our tunnels).  To accomplish this, we keep track of how each
-peer performs (the peer's "profile") and use that data to estimate how 
-fast they are, how often they will be able to accept our requests, and 
-whether they seem to be overloaded or otherwise unable to perform what
-they agree to reliably.
            
-
            
-Unlike some other anonymous networks, in I2P,
-claimed bandwidth is untrusted and is only used to avoid those peers
-advertising very low bandwidth insufficient for routing tunnels.
-All peer selection is done through profiling.
-This prevents simple attacks based on peers claiming high bandwidth
-in order to capture large numbers of tunnels.
-It also makes
-timing attacks
-more difficult.
-
            
-
            
-Peer selection is done quite frequently, as a router may maintain a large number
-of client and exploratory tunnels, and a tunnel lifetime is only 10 minutes.
-
-
-
            Further Information
            
-
            
-For more information see the paper
-Peer Profiling and Selection in the I2P Anonymous Network
-presented at
-PET-CON 2009.1.
-See below for notes on minor changes since the paper was published.
-
            
-
-
            Profiles
            
-
-
            Each peer has a set of data points collected about them, including statistics 
-about how long it takes for them to reply to a network database query, how 
-often their tunnels fail, and how many new peers they are able to introduce 
-us to, as well as simple data points such as when we last heard from them or
-when the last communication error occurred.  The specific data points gathered
-can be found in the code
-
            
-
-
            
-Profiles are fairly small, a few KB. To control memory usage, the profile expiration time
-lessens as the number of profiles grows.
-Profiles are kept in memory until router shutdown, when they are written to disk.
-At startup, the profiles are read so the router need not reinitialize all profiles,
-thus allowing a router to quickly re-integrate into the network after startup.
-
            
-
-
-
-
            Peer Summaries
            
-
-
            While the profiles themselves can be considered a summary of a peer's 
-performance, to allow for effective peer selection we break each summary down 
-into four simple values, representing the peer's speed, its capacity, how well 
-integrated into the network it is, and whether it is failing.
            
-
-
            Speed
            
-
-
            The speed calculation
-simply goes through the profile and estimates how much data we can
-send or receive on a single tunnel through the peer in a minute.  For this estimate it just looks at
-performance in the previous minute.
-
            
-
-
            Capacity
            
-
-
            The capacity calculation
-simply goes through the profile and estimates how many tunnels the peer
-would agree to participate in over a given time period.  For this estimate it looks at 
-how many tunnel build requests
-the peer has accepted, rejected, and dropped, and how many
-of the agreed-to tunnels later failed.
-While the calculation is time-weighted so that recent activity counts more than later activity,
-statistics up to 48 hours old may be included.
-
            
-Recognizing and avoiding unreliable and unreachable
-peers is critically important.
-Unfortunately, as the tunnel building and testing require the participation of several peers,
-it is difficult to positively identify the cause of a dropped build request or test failure.
-The router assigns a probability of failure to each of the
-peers, and uses that probability in the capacity calculation.
-Drops and test failures are weighted much higher than rejections.
-
            
-
-
            Peer organization
            
-
-
            As mentioned above, we drill through each peer's profile to come up with a 
-few key calculations, and based upon those, we organize each peer into three
-groups - fast, high capacity, and standard.
-
-
            The groupings are not mutually exclusive, nor are they unrelated:  
               
-
            • A peer is considered "high capacity" if its capacity calculation meets or 
-     exceeds the median of all peers.  
              • 
-
            • A peer is considered "fast" if they are already "high capacity" and their 
-    speed calculation meets or exceeds the median of all peers.
              • 
-
            • A peer is considered "standard" if it is not "high capacity"
              • 
-
            
-
-These groupings are implemented in the router's ProfileOrganizer.
-
-
            Group size limits
            
-
-The size of the groups may be limited.
-
-
              
-
            • The fast group is limited to 30 peers.
-    If there would be more, only the ones with the highest speed rating are placed in the group.
-
            • The high capacity group is limited to 75 peers (including the fast group)
-    If there would be more, only the ones with the highest capacity rating are placed in the group.
-
            • The standard group has no fixed limit, but is somewhat smaller than the number of RouterInfos
-    stored in the local network database.
-    On an active router in today's network, there may be about 1000 RouterInfos and 500 peer profiles
-    (including those in the fast and high capacity groups)
-
            
-
-
            Recalculation and Stability
            
-Summaries are recalculated, and peers are resorted into groups, every 45 seconds.
-
-
            
-The groups tend to be fairly stable, that is, there is not much "churn" in the rankings
-at each recalculation.
-Peers in the fast and high capacity groups get more tunnels build through them, which increases their speed and capacity ratings,
-which reinforces their presence in the group.
-
-
-
-
-
            Peer Selection
            
-
-The router selects peers from the above groups to build tunnels through.
-
-
-
            Peer Selection for Client Tunnels
            
-
-Client tunnels are used for application traffic, such as for HTTP proxies and web servers.
-
            
-To reduce the susceptibility to some attacks,
-and increase performance,
-peers for building client tunnels are chosen randomly from the smallest group, which is the "fast" group.
-There is no bias toward selecting peers that were previously participants in a tunnel for the same client.
-
-
-
            Peer Selection for Exploratory Tunnels
            
-
-Exploratory tunnels are used for router administrative purposes, such as network database traffic
-and testing client tunnels.
-Exploratory tunnels are also used to contact previously unconnected routers, which is why
-they are called "exploratory".
-These tunnels are usually low-bandwidth.
-
            
-Peers for building exploratory tunnels are generally chosen randomly from the standard group.
-If the success rate of these build attempts is low compared to the client tunnel build success rate,
-the router will select a weighted average of peers randomly from the high capacity group instead.
-This helps maintain a satisfactory build success rate even when network performance is poor.
-There is no bias toward selecting peers that were previously participants in an exploratory tunnel.
-
            
-As the standard group includes a very large subset of all peers the router knows about,
-exploratory tunnels are essentially built through a random selection of all peers,
-until the build success rate becomes too low.
-
-
-
-
            Restrictions
            
-To prevent some simple attacks, and for performance, there are the following restrictions:
-
              
-
            • 
-Two peers from the same /16 IP space may not be in the same tunnel.
-
            • 
-A peer may participate in a maximum of 33% of all tunnels created by the router.
-
            • 
-Peers with extremely low bandwidth are not used.
-
            • 
-Peers for which a recent connection attempt failed are not used.
-
            
-
-
-
-
            Peer Ordering in Tunnels
            
-
-Peers are ordered within tunnels to
-to deal with the predecessor 
-attack (2008 
-update).
-More information is on the tunnel page.
-
-
-
-
-
            Future Work
            
-
-
              
-
            • 
-Continue to analyze an tune speed and capacity calculations as necessary
-
            • 
-Implement a more aggressive ejection strategy if necessary to control memory usage as the network grows
-
            • 
-Evaluate group size limits
-
            • 
-Use GeoIP data to include or exclude certain peers, if configured
-
            
-
-
            Notes
            
-For those reading the paper
-Peer Profiling and Selection in the I2P Anonymous Network,
-please keep in mind the following minor changes in I2P since the paper's publication:
-
              
-
            • The Integration calculation is still not used
-
            • In the paper, "groups" are called "tiers"
-
            • The "Failing" tier is no longer used
-
            • The "Not Failing" tier is now named "Standard"
-
            
-
-
-
            References
            
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/how_threatmodel.html b/www.i2p2/pages/how_threatmodel.html
deleted file mode 100644
index 604cd01c..00000000
--- a/www.i2p2/pages/how_threatmodel.html
+++ /dev/null
@@ -1,737 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P's Threat Model{% endblock %}
-{% block content %}
-
-Updated November 2010, current as of router version 0.8.1
-
            What do we mean by "anonymous"?
            
-
-
            Your level of anonymity can be described as "how hard it is for someone
-to find out information you don't want them to know?" - who you are, where
-you are located, who you communicate with, or even when you communicate.  
-"Perfect" anonymity is not a useful concept here - software will not make 
-you indistinguishable from people that don't use computers or who are not on
-the Internet.  Instead, we are working to provide sufficient anonymity to meet the
-real needs of whomever we can - from those simply browsing websites, to those exchanging
-data, to those fearful of discovery by powerful organizations or states.
            
-  
-
            The question of whether I2P provides sufficient anonymity for your 
-particular needs is a hard one, but this page will hopefully assist in 
-answering that question by exploring how I2P operates under various attacks
-so that you may decide whether it meets your needs.
            
-
-
            We welcome further research and analysis on I2P's resistance to the threats described below.
-More review of existing literature (much of it focused on Tor) and original
-work focused on I2P is needed.
            
-
-
            Network Topology Summary
            
-
            I2P builds off the ideas of many other 
-systems, but a few key points should be kept in mind when 
-reviewing related literature:
              
-
            • I2P is a free route mixnet - the message creator explicitly defines the
-    path that messages will be sent out (the outbound tunnel), and the message 
-    recipient explicitly defines the path that messages will be received on (the
-    inbound tunnel).
-
              • 
-
            • I2P has no official entry and exit points - all peers fully participate in the 
-    mix, and there are no network layer in- or out-proxies (however, at the 
-    application layer, a few proxies do exist)
              • 
-
            • I2P is fully distributed - there are no central controls or authorities.
-    One could modify some routers to operate mix cascades (building tunnels and giving
-    out the keys necessary to control the forwarding at the tunnel endpoint) or directory 
-    based profiling and selection, all without breaking compatibility with the rest of 
-    the network, but doing so is of course not necessary (and may even harm one's
-    anonymity).
              • 
-
            
-
            
-   We have documented plans to implement
-    nontrivial delays and batching strategies 
-    whose existence is only known to the particular hop or tunnel gateway that 
-    receives the message, allowing a mostly low latency mixnet to provide cover 
-    traffic for higher latency communication (e.g. email).
-   However we are aware that significant delays are required to provide meaningful
-   protection, and that implementation of such delays will be a significant challenge.
-   It is not clear at this time whether we will actually implement these delay features.
-
            
-  In theory, routers along the message path may inject an 
-    arbitrary number of hops before forwarding the message to the next peer, though
-    the current implementation does not.
-
            
-
-
-
            The Threat Model (Attacks)
            
-
            
-I2P design started in 2003, not long after the advent of
-[Onion Routing],
-[Freenet], and
-[Tor].
-Our design benefits substantially from the research published around that time.
-I2P uses several onion routing techniques, so we continue to benefit
-from the significant academic interest in Tor.
-
            
-Taking from the attacks and analysis put forth in the 
-anonymity literature (largely 
-Traffic Analysis: Protocols, Attacks, Design 
-Issues and Open Problems), the following briefly describes a wide variety 
-of attacks as well as many of I2Ps defenses.  We update
-this list to include new attacks as they are identified.
-
            
-Included are some attacks that may be unique to I2P.
-We do not have good answers for all these attacks, however
-we continue to do research and improve our defenses.
-
            
-In addition, many of these attacks are significantly easier than
-they should be, due to the modest size of the current network.
-While we are aware of some limitations that need to be addressed,
-I2P is designed to support hundreds of thousands, or millions, of
-participants.
-As we continue to spread the word and grow the network,
-these attacks will become much harder.
-
            
-The
-network comparisons and
-"garlic" terminology pages may also be helpful
-to review.
-
            
-
-
            Index
            
-
-
-
            Brute force attacks
            
-
-
            A brute force attack can be mounted by a global passive or active adversary, 
-watching all the messages pass between all of the nodes and attempting to correlate
-which message follows which path.  Mounting this attack against I2P should be 
-nontrivial, as all peers in the network are frequently sending messages (both
-end to end and network maintenance messages), plus an end to end message changes
-size and data along its path.  In addition, the external adversary does not have
-access to the messages either, as inter-router communication is both encrypted
-and streamed (making two 1024 byte messages indistinguishable from one 2048 byte
-message).
            
-
-
            However, a powerful attacker can use brute force to detect trends - if they 
-can send 5GB to an I2P destination and monitor everyone's network connection,
-they can eliminate all peers who did not receive 5GB of data.  Techniques to 
-defeat this attack exist, but may be prohibitively expensive (see: 
-Tarzan's mimics
-or constant rate traffic).  Most users are not concerned with this attack, as 
-the cost of mounting it are extreme (and often require illegal activity).  
-However, the attack is still possible, for example by an observer at
-a large ISP or an Internet exchange point.
-Those who want to defend against it 
-would want to take appropriate countermeasures, such as
-setting low bandwidth limits, and using unpublished or encrypted leasesets for eepsites.
-Other countermeasures, such as nontrivial delays and restricted routes, are
-not currently implemented.
-
            
-As a partial defense against a single router or group of routers trying to route all the network's traffic,
-routers contain limits as to how many tunnels can be routed through a single peer.
-As the network grows, these limits are subject to further adjustment.
-Other mechanisms for peer rating, selection and avoidance
-are discussed on the
-peer selection page.
-
            
-
-
-
-
            Timing attacks
            
-
-
            I2P's messages are unidirectional and do not necessarily imply that a reply
-will be sent.  However, applications on top of I2P will most likely have
-recognizable patterns within the frequency of their messages - for instance, an 
-HTTP request will be a small message with a large sequence of reply messages 
-containing the HTTP response.  Using this data as well as a broad view of the 
-network topology, an attacker may be able to disqualify some links as being too 
-slow to have passed the message along.
            
-
-
            This sort of attack is powerful, but its applicability to I2P is non obvious,
-as the variation on message delays due to queuing, message processing, and 
-throttling will often meet or exceed the time of passing a message along a 
-single link - even when the attacker knows that a reply will be sent as soon as
-the message is received.  There are some scenarios which will expose fairly 
-automatic replies though - the streaming library does (with the SYN+ACK) as does the 
-message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).
            
-
-
            Without protocol scrubbing or higher latency, global active adversaries can 
-gain substantial information.  As such, people concerned with these attacks could
-increase the latency (using nontrivial delays or 
-batching strategies), include protocol scrubbing, or
-other advanced tunnel routing techniques,
-but these are unimplemented in I2P.
-
            
-
-
            References:
-Low-Resource Routing Attacks Against Anonymous Systems
-
            
-
-
            Intersection attacks
            
-
-
            Intersection attacks against low latency systems are extremely powerful -
-periodically make contact with the target and keep track of what peers are on
-the network.  Over time, as node churn occurs the attacker will gain 
-significant information about the target by simply intersecting the sets of
-peers that are online when a message successfully goes through.  The cost of 
-this attack is significant as the network grows, but may be feasible in some
-scenarios.
            
-  
-
            
-In summary, if an attacker is at both ends of your tunnel at the same time,
-he may be successful.
-I2P does not have a full defense to this for low latency communication.
-This is an inherent weakness of low-latency onion routing.
-Tor provides a similar disclaimer.
-
            
-Partial defenses implemented in I2P:
-
            • 
-strict ordering of peers
-
            • 
-peer profiling and selection from a small group that changes slowly
-
            • 
-Limits on the number of tunnels routed through a single peer
-
            • 
-Prevention of peers from the same /16 IP range from being members of a single tunnel
-
            • 
-For eepsites or other hosted services, we support
-simultaneous hosting on multiple routers, or
-multihoming
-
            
-
-Even in total, these defenses are not a complete solution.
-Also, we have made some design choices that may significantly increase our vulnerability:
-
            • 
-We do not use low-bandwidth "guard nodes"
-
            • 
-We use tunnel pools comprised of several tunnels, and traffic can shift from tunnel to tunnel.
-
            • 
-Tunnels are not long-lived; new tunnels are built every 10 minutes.
-
            • 
-Tunnel lengths are configurable.
-While 3-hop tunnels are recommended for full protection, several applications and
-services use 2-hop tunnels by default.
-
            
-
-
-
            
-In the future, it could
-for peers who can afford significant delays (per nontrivial 
-delays and batching strategies).  In addition,
-this is only relevant for destinations that other people know about - a private
-group whose destination is only known to trusted peers does not have to worry,
-as an adversary can't "ping" them to mount the attack.
            
-
-
            Reference:
-One Cell Enough
-
            
-
-
-
-
            Denial of service attacks
            
-
-
            There are a whole slew of denial of service attacks available against I2P,
-each with different costs and consequences:
              
-
            • Greedy user attack: This is simply
-    people trying to consume significantly more resources than they are 
-    willing to contribute.  The defense against this is:
                
-    
              • Set defaults so that most users provide resources to the network.
-    In I2P, users route traffic by default. In sharp distinction to
-    other networks,
-    over 95% of I2P users relay traffic for others.
-   
                • 
-    
              • Provide easy configuration options so that users may increase their
-    contribution (share percentage) to the network. Display easy-to-understand
-    metrics such as "share ratio" so that users may see what they are contributing.
-   
                • 
-     Maintain a strong community with blogs, forums, IRC, and other means of communication.
-   
              
-
            • Starvation attack: A hostile user may attempt to harm the network by
-    creating a significant number of peers in the network who are not identified as
-    being under control of the same entity (as with Sybil).  These nodes then 
-    decide not to provide any resources to the network, causing existing peers 
-    to search through a larger network database or request more tunnels than 
-    should be necessary. 
-    Alternatively, the nodes may provide intermittent service by periodically
-    dropping selected traffic, or refusing connections to certain peers.
-    This behavior may be indistinguishable from that of a heavily-loaded or failing node.
-    I2P addresses these issues by maintaining profiles on the 
-    peers, attempting to identify underperforming ones and simply ignoring 
-    them, or using them rarely.
-    We have significantly enhanced the
-    ability to recognize and avoid troublesome peers; however there are still
-    significant efforts required in this area.
-
              • 
-
            • Flooding attack: A hostile user may attempt to flood the network,
-    a peer, a destination, or a tunnel.  Network and peer flooding is possible,
-    and I2P does nothing to prevent standard IP layer flooding.  The flooding of
-    a destination with messages by sending a large number to the target's various
-    inbound tunnel gateways is possible, but the destination will know this both
-    by the contents of the message and because the tunnel's tests will fail.  The
-    same goes for flooding just a single tunnel.  I2P has no defenses for a network
-    flooding attack.  For a destination and tunnel flooding attack, the target
-    identifies which tunnels are unresponsive and builds new ones.  New code could
-    also be written to add even more tunnels if the client wishes to handle the
-    larger load.  If, on the other hand, the load is more than the client can
-    deal with, they can instruct the tunnels to throttle the number of messages or
-    bytes they should pass on (once the advanced tunnel
-    operation is implemented).
              • 
-
            • CPU load attack: There are currently some methods for people to 
-    remotely request that a peer perform some cryptographically expensive 
-    operation, and a hostile attacker could use these to flood that peer with
-    a large number of them in an attempt to overload the CPU.  Both using good 
-    engineering practices and potentially requiring nontrivial certificates 
-    (e.g. HashCash) to be attached to these expensive requests should mitigate
-    the issue, though there may be room for an attacker to exploit various
-    bugs in the implementation.
              • 
-
            • Floodfill DOS attack: A hostile user may attempt to harm the network by
-    becoming a floodfill router. The current defenses against unreliable,
-    intermittent, or malicious floodfill routers are poor.
-    A floodfill router may provide bad or no response to lookups, and
-    it may also interfere with inter-floodfill communication.
-    Some defenses and
-    peer profiling are implemented,
-    however there is much more to do.
-    For more information see the
-    network database page.
-
              • 
-
            
-
-
            Tagging attacks
            
-
            Tagging attacks - modifying a message so that it can later be identified 
-further along the path - are by themselves impossible in I2P, as messages 
-passed through tunnels are signed.  However, if an attacker is the inbound 
-tunnel gateway as well as a participant further along in that tunnel, with
-collusion they can identify the fact that they are in the same tunnel (and 
-prior to adding unique hop ids and other updates,
-colluding peers within the same tunnel can recognize that fact without any 
-effort).  An attacker in an outbound tunnel and any part of an inbound tunnel cannot 
-collude however, as the tunnel encryption pads and modifies the data separately
-for the inbound and outbound tunnels.  External attackers cannot do anything,
-as the links are encrypted and messages signed.
            
-
-
            Partitioning attacks
            
-
-
            Partitioning attacks - finding ways to segregate (technically or analytically)
-the peers in a network - are important to keep in mind when dealing with a 
-powerful adversary, since the size of the network plays a key role in determining
-your anonymity.  Technical partitioning by cutting links between peers to create
-fragmented networks is addressed by I2P's built in network database, which 
-maintains statistics about various peers so as to allow any existing connections
-to other fragmented sections to be exploited so as to heal the network.  However,
-if the attacker does disconnect all links to uncontrolled peers, essentially
-isolating the target, no amount of network database healing will fix it.  At
-that point, the only thing the router can hope to do is notice that a significant
-number of previously reliable peers have become unavailable and alert the client
-that it is temporarily disconnected (this detection code is not implemented at
-the moment).
            
-
-
            Partitioning the network analytically by looking for differences in how routers 
-and destinations behave and grouping them accordingly is also a very powerful
-attack.  For instance, an attacker harvesting the network
-database will know when a particular destination has 5 inbound tunnels in their
-LeaseSet while others have only 2 or 3, allowing the adversary to potentially 
-partition clients by the number of tunnels selected.  Another partition is 
-possible when dealing with the nontrivial delays and 
-batching strategies, as the tunnel gateways and the
-particular hops with non-zero delays will likely stand out.  However, this data
-is only exposed to those specific hops, so to partition effectively on that 
-matter, the attacker would need to control a significant portion of the network
-(and still that would only be a probabilistic partition, as they wouldn't know
-which other tunnels or messages have those delays).
-
            
-Also discussed on the
-    network database page (bootstrap attack).
-
            
-
-
            Predecessor attacks
            
-
-
            The predecessor attack is passively gathering statistics in an attempt to see
-what peers are 'close' to the destination by participating in their tunnels and
-keeping track of the previous or next hop (for outbound or inbound tunnels, 
-respectively).  Over time, using a perfectly random sample of peers and random
-ordering, an attacker would be able to see which peer shows up as 'closer' 
-statistically more than the rest, and that peer would in turn be where the
-target is located.  
            
-
-
            I2P avoids this in four ways: first, the peers selected to participate in
-tunnels are not randomly sampled throughout the network - they are derived from
-the peer selection algorithm which breaks them
-into tiers.  Second, with strict ordering of peers
-in a tunnel, the fact that a peer shows up more frequently does not mean they're
-the source.  Third, with permuted tunnel length
-(not enabled by default)
-even 0 hop tunnels can provide plausible deniability as the occasional 
-variation of the gateway will look like normal tunnels.  Fourth, with 
-restricted routes (unimplemented), only the peer with
-a restricted connection to the target will ever contact the target, while 
-attackers will merely run into that gateway.
-
            
-The current
-tunnel build method
-was specifically designed to combat the predecessor attack.
-See also the intersection attack.
-
            
-
-
            References:
-http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf
-which is an update to the 2004 predecessor attack paper
-http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf.
-
            
-
-
-
            Harvesting attacks
            
-
            
-"Harvesting" means compiling a list of users running I2P.
-It can be used for legal attacks and to help
-other attacks by simply running a peer, seeing who it connects to, and 
-harvesting whatever references to other peers it can find.
-
            
-I2P itself is not designed with effective defenses against
-this attack, since there is the distributed network database 
-containing just this information.
-The following factors make the attack somewhat harder in practice:
-
            • 
-Network growth will make it more difficult to obtain a given proportion of the network
-
            • 
-Floodfill routers implement query limits as DOS protection
-
            • 
-"Hidden mode", which prevents a router from publishing its information to the netDb,
-(but also prevents it from relaying data) is not widely used now but could be.
-
            
-In future implementations,
-basic and 
-comprehensive restricted routes,
-this attack loses much of its power, as the "hidden" peers do not publish their
-contact addresses in the network database - only the tunnels through which 
-they can be reached (as well as their public keys, etc).
-
            
-In the future, routers could use GeoIP to identify if they are in a particular
-country where identification as an I2P node would be risky.
-In that case, the router could automatically enable hidden mode, or
-enact other restricted route methods.
-
            
-
-
-
-
            Identification Through Traffic Analysis
            
-
            
-By inspecting the traffic into and out of a router, a malicious ISP
-or state-level firewall could identify that a computer is running I2P.
-As discussed above, I2P is not specifically designed
-to hide that a computer is running I2P. However, several design decisions made
-in the design of the
-transport layer and protocols
-make it somewhat difficult to identify I2P traffic:
-
            • 
-Random port selection
-
            • 
-Point-to-Point Encryption of all traffic
-
            • 
-DH key exchange with no protocol bytes or other unencrypted constant fields
-
            • 
-Simultaneous use of both
-TCP and
-UDP transports.
-UDP may be much harder for some Deep Packet Inspection (DPI) equipment to track.
-
            
-
-In the near future, we plan to directly address traffic analysis issues by further obfuscation of I2P transport protocols, possibly including:
-
            • 
-Padding at the transport layer to random lengths, especially during the connection handshake
-
            • 
-Study of packet size distribution signatures, and additional padding as necessary
-
            • 
-Development of additional transport methods that mimic SSL or other common protocols
-
            • 
-Review of padding strategies at higher layers to see how they affect packet sizes at the transport layer
-
            • 
-Review of methods implemented by various state-level firewalls to block Tor
-
            • 
-Working directly with DPI and obfuscation experts
-
            
-
            
-Reference:
-Breaking and Improving Protocol Obfuscation
-
            
-
-
-
-
            Sybil attacks
            
-
-
            Sybil describes a category of attacks where the adversary creates arbitrarily
-large numbers of colluding nodes and uses the increased numbers to help 
-mounting other attacks.  For instance, if an attacker is in a network where peers
-are selected randomly and they want an 80% chance to be one of those peers, they
-simply create five times the number of nodes that are in the network and roll 
-the dice.  When identity is free, Sybil can be a very potent technique for a 
-powerful adversary.  The primary technique to address this is simply to make 
-identity 'non free' - Tarzan
-(among others) uses the fact that IP addresses are limited, while 
-IIP used 
-HashCash to 'charge' for creating a new
-identity.  We currently have not implemented any particular technique to address
-Sybil, but do include placeholder certificates in the router's and 
-destination's data structures which can contain a HashCash certificate of 
-appropriate value when necessary (or some other certificate proving scarcity).
-
            
-Requiring HashCash Certificates in various places has two major problems:
-
            • 
-Maintaining backward compatibility
-
            • 
-The classic HashCash problem -
-selecting HashCash values that are meaningful proofs of work on high-end machines,
-while still being feasible on low-end machines such as mobile devices.
-
            
-
            
-Various limitations on the number of routers in a given IP range restrict
-the vulnerability to attackers that don't have the ability to put machines
-in several IP blocks.
-However, this is not a meaningful defense against a powerful adversary.
-
            
-See the
-  network database page
-for more Sybil discussion.
-
            
-
-
-
            Buddy Exhaustion attacks
            
-
            
-  (Reference:
-  In Search of an Anonymouns and Secure Lookup Section 5.2)
-
            
-
            
-By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure
-that a tunnel is formed wholly from its set of colluding routers.
-The chances of success are enhanced if there is a large number of colluding routers,
-i.e. a Sybil attack.
-This is somewhat mitigated by our
-peer profiling methods used to monitor the performance
-of peers.
-However, this is a powerful attack as the number of routers approaches
-f = 0.2, or 20% malicious nodes, as specifed in the paper.
-The malicous routers could also maintain connections to the target router and provide
-excellent forwarding bandwidth for traffic over those connections, in an attempt
-to manipulate the profiles managed by the target and appear attractive.
-Further research and defenses may be necessary.
-
            
-
-
-
            Cryptographic attacks
            
-
-
            
-We use strong cryptography with long keys, and
-we assume the security of the industry-standard cryptographic primitives used in I2P, as documented
-on the low-level cryptography page. 
-Security features
-include the immediate detection of 
-altered messages along the path, the inability to decrypt messages not addressed to you,
-and defense against man-in-the-middle attacks.
-The key sizes chosen in 2003 were quite conservative at the time, and are still longer than
-those used in other anonymity networks.
-We don't think the current key lengths are our biggest weakness,
-especially for traditional, non-state-level adversaries;
-bugs and the small size of the network are much more worrisome.
-Of course, all cryptographic algorithms eventually become obsolete due to
-the advent of faster processors, cryptographic research, and advancements in
-methods such as rainbow tables, clusters of video game hardware, etc.
-Unfortunately, I2P was not designed with easy mechanisms to lengthen keys or change
-shared secret values while maintaining backward compatibility.
-
            
-Upgrading the various data structures and protocols to support longer keys
-will have to be tackled eventually, and this will be a
-major undertaking, just as it will be for 
-others.
-Hopefully, through careful planning, we can minimize the disruption, and
-implement mechanisms to make it easier for future transitions.
-
            
-In the future,
-several I2P protocols and data structures
-support securely padding messages to arbitrary sizes, so messages could be made constant
-size or garlic messages could be modified randomly so that some cloves appear to contain
-more subcloves than they actually do.  At the moment, however, garlic, tunnel, and 
-end to end messages include simple random padding.
            
-
-
-
-
            Floodfill Anonymity attacks
            
-
            
-In addition to the floodfill DOS attacks described
-above, floodfill routers are uniquely positioned
-to learn about network participants, due to their role
-in the netDb, and the high frequency of communication with those participants.
-This is somewhat mitigated because floodfill routers only manage a portion
-of the total keyspace, and the keyspace rotates daily, as explained 
-on the
-  network database page.
-The specific mechanisms by which routers communicate with floodfills have been
-  carefully designed.
-However, these threats should be studied further.
-The specific potential threats and corresponding defenses are a topic for future research.
-
            
-
-
-
            Other Network Database attacks
            
-
            
-  A hostile user may attempt to harm the network by
-  creating one or more floodfill routers and crafting them to offer
-  bad, slow, or no responses.
-  Several scenarios are discussed on the
-  network database page.
-
            
-
-
-
-
            Central Resource Attacks
            
-
            
-There are a few centralized or limited resources (some inside I2P, some not)
-that could be attacked or used as a vector for attacks.
-The absence of jrandom starting November 2007, followed by the loss of the i2p.net hosting service in January 2008,
-highlighted numerous centralized resources in the development and operation of the I2P network,
-most of which are now distributed.
-Attacks on externally-reachable resources mainly affect the ability of new users to find us,
-not the operation of the network itself.
-
              
-
            • The website is mirrored and uses DNS round-robin for external public access.
-
            • Routers now support multiple external reseed locations,
-    however more reseed hosts may be needed, and the handling of unreliable or malicious
-    reseed hosts may need improvement.
-
            • Routers now support multiple update file locations.
-    A malicious update host could feed a huge file, need to limit the size.
-
            • Routers now support multiple default trusted update signers.
-
            • Routers now better handle multiple unreliable floodfill peers.
-    Malicious floodfills needs more study.
-
            • The code is now stored in a distributed source control system.
-
            • Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host.
-    A malicious news host could feed a huge file, need to limit the size.
-
            • Naming system services, including addressbook subscription providers, add-host services,
-    and jump services, could be malicious. Substantial protections for subscriptions were implemented
-    in release 0.6.1.31, with additional enhancements in subsequent releases.
-    However, all naming services require some measure of trust, see
-    the naming page for details.
-
            • We remain reliant on the DNS service for i2p2.de, losing this would cause substantial
-    disruption in our ability to attract new users,
-    and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did.
-
            
-
-
-
            Development attacks
            
-
-
            
-These attacks aren't directly on the network, but instead go after its development team 
-by either introducing legal hurdles on anyone contributing to the development
-of the software, or by using whatever means are available to get the developers to 
-subvert the software.  Traditional technical measures cannot defeat these attacks, and
-if someone threatened the life or livelihood of a developer (or even just issuing a 
-court order along with a gag order, under threat of prison), we would have a big problem.
-
            
-
-
            
-However, two techniques help defend against these attacks:
-
              
-
            •  All components of the network must be open source to enable inspection, verification, 
-     modification, and improvement.  If a developer is compromised, once it is noticed 
-     the community should demand explanation and cease to accept that developer's work.
-     All checkins to our distributed source control system
-     are cryptographically signed, and the release packagers use a trust-list system
-     to restrict modifications to those previously approved.
-
              • 
-
            •  Development over the network itself, allowing developers to stay anonymous but still 
-     secure the development process.  All I2P development can occur through I2P - using
-     a distributed source control system,
-     a distributed source control system, IRC chat,
-     public web servers,
-     discussion forums (forum.i2p), and the software distribution sites,
-     all available within I2P.
              • 
-
            
-We also maintain relationships with various organizations that offer legal advice,
-should any defense be necessary.
-
            
-
-
            Implementation attacks (bugs)
            
-
            
-Try as we might, most nontrivial applications include errors in the design or 
-implementation, and I2P is no exception.  There may be bugs that could be exploited to 
-attack the anonymity or security of the communication running over I2P in unexpected 
-ways.  To help withstand attacks against the design or protocols in use, we publish 
-all designs and documentation and solicit review and criticism with 
-the hope that many eyes will improve the system.
-We do not believe in
-security through obscurity.
-
            
-In addition, the code is being 
-treated the same way, with little aversion towards reworking or throwing out 
-something that isn't meeting the needs of the software system (including ease of 
-modification).  Documentation for the design and implementation of the network and 
-the software components are an essential part of security, as without them it is 
-unlikely that developers would be willing to spend the time to learn the software 
-enough to identify shortcomings and bugs.
-
            
-Our software is likely, in particular, to contain bugs related to denial of service
-through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues  in the router console,
-and other vulnerabilities to non-standard inputs via the various protocols.
-
            
-I2P is still a small network with a small development community and almost no
-interest from academic or research groups.
-Therefore we lack the analysis that
-other anonymity networks
-may have received. We continue to recruit people to
-get involved and help.
-
            
-
-
-
-
-
            Other Defenses
            
-
            Blocklists
            
-
            
-To some extent, I2P could be enhanced to avoid peers operating at IP addresses
-listed in a blocklist. Several blocklists are commonly available in standard formats,
-listing anti-P2P organizations, potential state-level adversaries, and others.
-
            
-To the extent that active peers actually do show up in the actual blocklist,
-blocking by only a subset of peers would tend to segment the network,
-exacerbate reachability problems, and decrease overall reliability.
-Therefore we would want to agree on a particular blocklist and
-enable it by default.
-
-
            
-Blocklists are only a part (perhaps a small part) of an array of defenses
-against maliciousness.
-In large part the profiling system does a good job of measuring
-router behavior so that we don't need to trust anything in netDb.
-However there is more that can be done. For each of the areas in the
-list above there are improvements we can make in detecting badness.
-
            
-If a blocklist is hosted at a central location with automatic updates
-the network is vulnerable to a
-central resource attack.
-Automatic subscription to a list gives the list provider the power to shut
-the i2p network down. Completely.
-
            
-Currently, a default blocklist is distributed with our software,
-listing only the IPs of past DOS sources.
-There
-is no automatic update mechanism.
-Should a particular IP range implement serious attacks on the I2P network,
-we would have to ask people to update their blocklist manually through
-out-of-band mechanisms such as forums, blogs, etc.
-
            
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/how_tunnelrouting.html b/www.i2p2/pages/how_tunnelrouting.html
deleted file mode 100644
index cc9849de..00000000
--- a/www.i2p2/pages/how_tunnelrouting.html
+++ /dev/null
@@ -1,255 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Tunnel Overview{% endblock %}
-{% block content %}
-
            
-Updated July 2011 for release 0.8.7
-
            
-
-
            Tunnel Overview
            
-
            
-This page contains an overview of I2P tunnel terminology and operation, with
-links to more technical pages, details, and specifications.
-
            
-
            As briefly explained in the introduction, I2P builds virtual "tunnels" -
-temporary and unidirectional paths through a sequence of routers.  These 
-tunnels are classified as either inbound tunnels (where everything 
-given to it goes towards the creator of the tunnel) or outbound tunnels
-(where the tunnel creator shoves messages away from them).  When Alice
-wants to send a message to Bob, she will (typically) send it out one of
-her existing outbound tunnels with instructions for that tunnel's endpoint
-to forward it to the gateway router for one of Bob's current inbound 
-tunnels, which in turn passes it to Bob.
            
-
            
-Tunnel
-
            -A: Outbound Gateway (Alice)
-B: Outbound Participant
-C: Outbound Endpoint
-D: Inbound Gateway
-E: Inbound Participant
-F: Inbound Endpoint (Bob)
-
            
-
            
-
-
            Tunnel vocabulary
            
-
              
-	
            • Tunnel gateway - the first router in a tunnel.  For inbound tunnels,
-		this is the one mentioned in the LeaseSet published in the
-	network database.  For outbound tunnels, the
-		gateway is the originating router.  (e.g. both A and D above)
              • 
-	
            • Tunnel endpoint - the last router in a tunnel.  (e.g. both C and F above)
              • 
-	
            • Tunnel participant - all routers in a tunnel except for the gateway or
-		endpoint (e.g. both B and E above)
              • 
-	
            • n-Hop tunnel - a tunnel with a specific number of inter-router jumps, e.g.:
-		
                
-			
              • 0-hop tunnel - a tunnel where the gateway is also the endpoint
                • 
-			
              • 1-hop tunnel - a tunnel where the gateway talks directly to the
-				endpoint
                • 
-			
              • 2-(or more)-hop tunnel - a tunnel where there is at least one intermediate
-				tunnel participant. (the above diagram includes two 2-hop tunnels - one
-				outbound from Alice, one inbound to Bob)
                • 
-		
              
-	
              • 
-	
            • Tunnel ID - A 4 byte integer
-                 different for each hop in a tunnel, and unique among all tunnels on a router.
-                 Chosen randomly by the tunnel creator.
              • 
-
            
-
-
            Tunnel Build Information
            
-
            Routers performing the three roles (gateway, participant, endpoint) are given
-different pieces of data in the initial
-Tunnel Build Message
-to accomplish their tasks:
            
-
-
              
-	
            • The tunnel gateway gets:
-		
                
-			
              • tunnel encryption key - an AES private key for encrypting
-				messages and instructions to the next hop
                • 
-			
              • tunnel IV key - an AES private key for double-encrypting
-				the IV to the next hop
                • 
-			
              • reply key - an AES public key for encrypting
-				the reply to the tunnel build request
                • 
-			
              • reply IV - the IV for encrypting
-				the reply to the tunnel build request
                • 
-			
              • tunnel id - 4 byte integer (inbound gateways only)
-				
                • 
-			
              • next hop - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint)
                • 
-			
              • next tunnel id - The tunnel ID on the next hop
                • 
-		
              
-	
              • 
-	
            • All intermediate tunnel participants get:
-		
                
-			
              • tunnel encryption key - an AES private key for encrypting
-				messages and instructions to the next hop
                • 
-			
              • tunnel IV key - an AES private key for double-encrypting
-				the IV to the next hop
                • 
-			
              • reply key - an AES public key for encrypting
-				the reply to the tunnel build request
                • 
-			
              • reply IV - the IV for encrypting
-				the reply to the tunnel build request
                • 
-			
              • tunnel id - 4 byte integer
-				
                • 
-			
              • next hop - what router is the next one in the path
                • 
-			
              • next tunnel id - The tunnel ID on the next hop
                • 
-		
              
-	
              • 
-	
            •  The tunnel endpoint gets:
-		
                
-			
              • tunnel encryption key - an AES private key for encrypting
-				messages and instructions to the the endpoint (itself)
                • 
-			
              • tunnel IV key - an AES private key for double-encrypting
-				the IV to the endpoint (itself)
                • 
-			
              • reply key - an AES public key for encrypting
-				the reply to the tunnel build request (outbound endpoints only)
                • 
-			
              • reply IV - the IV for encrypting
-				the reply to the tunnel build request (outbound endpoints only)
                • 
-			
              • tunnel id - 4 byte integer (outbound endpoints only)
-				
                • 
-			
              • reply router - the inbound gateway of the tunnel to send the reply through (outbound endpoints only)
                • 
-			
              • reply tunnel id - The tunnel ID of the reply router (outbound endpoints only)
                • 
-		
              
-	
              • 
-
            
-
-
            
-Details are in the
-tunnel creation specification.
-
            
-
-
            Tunnel pooling
            
-
            
-Several tunnels for a particular purpose may be grouped into a "tunnel pool",
-as described in the
-tunnel specification.
-This provides redundancy and additional bandwidth.
-The pools used by the router itself are called "exploratory tunnels".
-The pools used by applications are called "client tunnels".
-
            
-
-
-
-
            Tunnel length
            
-
            As mentioned above, each client requests that their router provide tunnels to
-include at least a certain number of hops.
-The decision as to how many routers
-to have in one's outbound and inbound tunnels has an important effect upon the
-latency, throughput, reliability, and anonymity provided by I2P - the more peers
-that messages have to go through, the longer it takes to get there and the more
-likely that one of those routers will fail prematurely.  The less routers in a
-tunnel, the easier it is for an adversary to mount traffic analysis attacks and
-pierce someone's anonymity.
-Tunnel lengths are specified by clients via
-I2CP options.
-The maximum number of hops in a tunnel is 7.
-
            
-
-
-
            0-hop tunnels
            
-
            With no remote routers in a tunnel, the user has very basic plausible
-deniability (since no one knows for sure that the peer that sent them the
-message wasn't simply just forwarding it on as part of the tunnel). However, it
-would be fairly easy to mount a statistical analysis attack and notice that
-messages targeting a specific destination are always sent through a single
-gateway.  Statistical analysis against outbound 0-hop tunnels are more complex,
-but could show similar information (though would be slightly harder to mount)
            
-
-
            1-hop tunnels
            
-
            With only one remote router in a tunnel, the user has both plausible
-deniability and basic anonymity, as long as they are not up against an internal
-adversary (as described on threat model). However,
-if the adversary ran a sufficient number of routers such that the single remote
-router in the tunnel is often one of those compromised ones, they would be able
-to mount the above statistical traffic analysis attack.
            
-
-
            2-hop tunnels
            
-
            With two or more remote routers in a tunnel, the costs of mounting the traffic
-analysis attack increases, since many remote routers would have to be compromised
-to mount it.
            
-
-
            3-hop (or more) tunnels
            
-To reduce the susceptibility to some attacks,
-3 or more hops are recommended for the highest level of protection.
-recent studies
-also conclude that more than 3 hops does not provide additional protection.
-
-
-
            Tunnel default lengths
            
-
            The router uses 2-hop tunnels by default for its exploratory tunnels.
-Client tunnel defaults are set by the application, using
-I2CP options.
-Most applications use 2 or 3 hops as their default.
-
            
-
-
-
-
            Tunnel testing
            
-
            All tunnels are periodically tested by their creator by sending a
-DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel
-(testing both tunnels at once).  If either fails a number of consecutive tests, it is marked as no longer
-functional. If it was used for a client's inbound tunnel, a new leaseSet
-is created.
-Tunnel test failures are also reflected in the
-capacity rating in the peer profile.
-
            
-
-
-
            Tunnel creation
            
-
            Tunnel creation is handled by garlic routing
-a Tunnel Build Message to a router, requesting that they participate in the
-tunnel (providing them with all of the appropriate information, as above, along
-with a certificate, which right now is a 'null' cert, but will support hashcash
-or other non-free certificates when necessary).
-That router forwards the message to the next hop in the tunnel.
-Details are in the
-tunnel creation specification.
-
            
-
-
-
            Tunnel encryption
            
-
            Multi-layer encryption is handled by garlic encryption
-of tunnel messages.
-Details are in the
-tunnel specification.
-The IV of each hop is encrypted with a separate key as explained there.
-
            
-
-
-
            Future Work
            
-
            • 
-Other tunnel test techniques could be used, such as
-garlic wrapping a number of tests into cloves, testing individual tunnel
-participants separately,
-etc.
-
            • 
-Move to 3-hop exploratory tunnels defaults.
-
            • 
-In a distant future release,
-options specifying the pooling, mixing, and chaff generation settings may be implemented.
-
            • 
-In a distant future release,
-limits on the quantity and size of messages allowed during the
-tunnel's lifetime may be implemented (e.g. no more than 300 messages or
-1MB per minute).
-
            
-
-
-
            See Also
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/i2cp.html b/www.i2p2/pages/i2cp.html
deleted file mode 100644
index f1401b6f..00000000
--- a/www.i2p2/pages/i2cp.html
+++ /dev/null
@@ -1,250 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2CP{% endblock %}
-{% block content %}
-Updated November 2012, current as of router version 0.9.3
-
-
            The I2P Client Protocol (I2CP) exposes a strong separation of concerns between
-the router and any client that wishes to communicate over the network.  It enables
-secure and asynchronous messaging by sending and receiving messages over a 
-single TCP socket, yet never exposing any private keys and authenticating itself
-to the router only through signatures.  With I2CP, a client application tells the
-router who they are (their "destination"), what anonymity, reliability, and 
-latency tradeoffs to make, and where to send messages.  In turn the router uses
-I2CP to tell the client when any messages have arrived, and to request authorization
-for some tunnels to be used.
-
            
-
-
            
-The protocol itself has only been implemented in Java, to provide the
-Client SDK.
-This SDK is exposed in the i2p.jar package, which implements the client-side of I2CP.
-Clients should never need to access the router.jar package, which contains the
-router itself and the router-side of I2CP.
-
            
-
-
            
-While implementing the client side of I2CP in a non-Java language is certainly feasible,
-a non-Java client would also have to implement the
-streaming library for TCP-style connections.
-Together, implementing I2CP and the streaming library would be a sizable task.
-
            
-
-
            
-Applications can take advantage of the base I2CP plus the 
-streaming and datagram libraries
-by using the Simple Anonymous Messaging or BOB protocols,
-which do not require clients to deal with any sort of cryptography.
-Also, clients may access the network by one of several proxies -
-HTTP, CONNECT, and SOCKS 4/4a/5.
-Alternatively, Java clients may access those libraries in ministreaming.jar and streaming.jar.
-So there are several options for both Java and non-Java applications.
-
            
-
-
            Client-side end-to-end encryption (encrypting the data over the I2CP connection)
-was disabled in I2P release 0.6,
-leaving in place the ElGamal/AES end-to-end encryption
-which is implemented in the router.
-The only cryptography that client libraries must still implement is
-DSA public/private key signing
-for LeaseSets and Session Configurations, and management of those keys.
-
            
-
-
            In a standard I2P installation, port 7654 is used by external java clients to communicate
-with the local router via I2CP.
-By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, set the
-router advanced configuration option i2cp.tcp.bindAllInterfaces=true and restart.
-Clients in the same JVM as the router pass messages directly to the router
-through an internal JVM interface.
-
            
-
-
            I2CP Protocol Specification
            
-
            
-Now on the
-I2CP Specification page.
-
            
-
-
-
            I2CP Initialization
            
-
            
-When a client connects to the router, it first sends a single protocol version byte (0x2A).
-Then it sends a GetDate Message and waits for the SetDate Message response.
-Next, it sends a CreateSession Message containing the session configuration.
-It next awaits a RequestLeaseSet Message from the router, indicating that inbound tunnels
-have been built, and responds with a CreateLeaseSetMessage containing the signed LeaseSet.
-The client may now initiate or receive connections from other I2P destinations.
-
-
            I2CP Options
            
-
            
-The following options are traditionally passed to the router via
-a SessionConfig contained in a CreateSession Message or a ReconfigureSession Message.
-
            
-
-
-
            Router-side Options
            Option Recommended Arguments Allowable RangeDefaultDescription
-
            inbound.quantity number from 1 to 3 1 to 162Number of tunnels in.
-     Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are not
-     currently recommended, as this is untested and is incompatible with older releases.
-
            outbound.quantity number from 1 to 3 No limit2Number of tunnels out
-
            inbound.length number from 0 to 3 0 to 72Length of  tunnels in
-
            outbound.length number from 0 to 3 0 to 72Length of tunnels out
-
            inbound.lengthVariance number from -1 to 2 -7 to 70Random amount to add or subtract to the length of tunnels in.
-     A positive number x means add a random amount from 0 to x inclusive.
-     A negative number -x means add a random amount from -x to x inclusive.
-     The router will limit the total length of the tunnel to 0 to 7 inclusive.
-     The default variance was 1 prior to release 0.7.6.
-
            outbound.lengthVariance number from -1 to 2 -7 to 70Random amount to add or subtract to the length of tunnels out.
-     A positive number x means add a random amount from 0 to x inclusive.
-     A negative number -x means add a random amount from -x to x inclusive.
-     The router will limit the total length of the tunnel to 0 to 7 inclusive.
-     The default variance was 1 prior to release 0.7.6.
-
            inbound.backupQuantity number from 0 to 3 No limit0Number of redundant fail-over for tunnels in
-
            outbound.backupQuantity number from 0 to 3 No limit0Number of redundant fail-over for tunnels out
-
            inbound.nickname string  Name of tunnel - generally used in routerconsole, which will
-     use the first few characters of the Base64 hash of the destination by default.
-
            outbound.nickname string  Name of tunnel - generally ignored unless inbound.nickname is unset.
-
            inbound.allowZeroHop true, false trueIf incoming zero hop tunnel is allowed
-
            outbound.allowZeroHop true, false trueIf outgoing zero hop tunnel is allowed
-
            inbound.IPRestriction number from 0 to 4 0 to 42Number of IP bytes to match to determine if
-     two routers should not be in the same tunnel. 0 to disable.
-
            outbound.IPRestriction number from 0 to 4 0 to 42Number of IP bytes to match to determine if
-     two routers should not be in the same tunnel. 0 to disable.
-
            outbound.prioritynumber from -25 to 25 -25 to 250Priority adjustment for outbound messages.
-     Higher is higher priority. As of 0.9.4.
-
            i2cp.dontPublishLeaseSet true, false falseShould generally be set to true for clients
-     and false for servers
-
            i2cp.messageReliability  BestEffort, NoneBestEffortGuaranteed is disabled;
-     None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4
-
            i2cp.fastReceive true, falsefalseIf true, the router just sends the MessagePayload instead
-     of sending a MessageStatus and awaiting a ReceiveMessageBegin.
-     As of 0.9.4
-
            explicitPeers  nullComma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only
-
            i2cp.usernamestring  For authorization, if required by the router (since 0.8.2).
-        If the client is running in the same JVM as a router, this option is not required.
-
            i2cp.passwordstring  For authorization, if required by the router (since 0.8.2).
-        If the client is running in the same JVM as a router, this option is not required.
-
            crypto.tagsToSend 1-12840Number of ElGamal/AES Session Tags to send at a time (since 0.9.2).
-        For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower.
-
            crypto.lowTagThreshold 1-12830Minimum number of ElGamal/AES Session Tags before we send more (since 0.9.2).
-        Recommended: approximately tagsToSend * 2/3
-
            shouldBundleReplyInfotrue, false trueSet to false to disable ever bundling a reply LeaseSet (since 0.9.2).
-      For clients that do not publish their LeaseSet, this option must be true
-      for any reply to be possible. "true" is also recommended for multihomed servers
-      with long connection times.
-     
-  
             Setting to "false" may save significant outbound bandwidth, especially if
-      the client is configured with a large number of inbound tunnels (Leases).
-      If replies are still required, this may shift the bandwidth burden to
-      the far-end client and the floodfill.
-      There are several cases where "false" may be appropriate:
-     
            • 
-      Unidirectional communication, no reply required
-      
            • 
-      LeaseSet is published and higher reply latency is acceptable
-      
            • 
-     LeaseSet is published, client is a "server", all connections are inbound
-      so the connecting far-end destination obviously has the leaseset already.
-      Connections are either short, or it is acceptable for latency on a long-lived
-      connection to temporarily increase while the other end re-fetches the LeaseSet
-      after expiration.
-      HTTP servers may fit these requirements.
-      
            
-
            inbound.*   Any other options prefixed with "inbound." are stored
-        in the "unknown options" properties of the inbound tunnel pool's settings.
-
            outbound.*   Any other options prefixed with "outbound." are stored
-        in the "unknown options" properties of the outbound tunnel pool's settings.
-
            
-
            
-Note: Large quantity, length, or variance settings may cause significant performance or reliability problems.
-
            
-Note: As of release 0.7.7, option names and values must use UTF-8 encoding.
-This is primarily useful for nicknames.
-Prior to that release, options with multi-byte characters were corrupted.
-
-
            
-The following options are interpreted on the client side,
-and will be interpreted if passed to the I2PSession via the I2PClient.createSession() call.
-The streaming lib should also pass these options through to I2CP.
-Other implementations may have different defaults.
-
            
-
-
-
            Client-side Options
            Option As Of ReleaseRecommended Arguments Allowable RangeDefaultDescription
-
            i2cp.tcp.host    127.0.0.1Router hostname.
-        If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
-
            i2cp.tcp.port   1-655357654Router I2CP port.
-        If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
-
            i2cp.SSL0.8.3true, false falseConnect to the router using SSL.
-        If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
-
            i2cp.gzip0.6.5true, false  trueGzip outbound data
-
            i2cp.reduceOnIdle0.7.1true, false  falseReduce tunnel quantity when idle
-
            i2cp.closeOnIdle0.7.1true, false  falseClose I2P session when idle
-
            i2cp.reduceIdleTime0.7.11200000300000 minimum (ms) Idle time required (default 20 minutes, minimum 5 minutes)
-
            i2cp.closeIdleTime0.7.11800000300000 minimum (ms) Idle time required (default 30 minutes)
-
            i2cp.reduceQuantity0.7.111 to 51Tunnel quantity when reduced (applies to both inbound and outbound)
-
            i2cp.encryptLeaseSet0.7.1true, false  falseEncrypt the lease
-
            i2cp.leaseSetKey0.7.1   Base64 SessionKey (44 characters)
-
            i2cp.messageReliability  BestEffort, NoneNoneGuaranteed is disabled;
-     None implemented in 0.8.1; None is the default as of 0.9.4
-
            i2cp.fastReceive0.9.4 true, falsetrueIf true, the router just sends the MessagePayload instead
-     of sending a MessageStatus and awaiting a ReceiveMessageBegin.
-
            
-
            
-Note: All arguments, including numbers, are strings. True/false values are case-insensitive strings.
-Anything other than case-insensitive "true" is interpreted as false.
-All option names are case-sensitive.
-
-
            I2CP Payload Data Format and Multiplexing
            
-
            
-The end-to-end messages handled by I2CP (i.e. the data sent by the client in a
-SendMessageMessage
-and received by the client in a
-MessagePayloadMessage)
-are gzipped with a standard 10-byte gzip
-header beginning with 0x1F 0x8B 0x08 as
-specified by RFC 1952.
-As of release 0.7.1, I2P uses ignored portions of the gzip header to include
-protocol, from-port, and to-port information, thus supporting streaming and
-datagrams on the same destination, and allowing query/response using datagrams
-to work reliably in the presence of multiple channels.
-
            
-The gzip function cannot be completely turned off, however setting i2cp.gzip=false
-turns the gzip effort setting to 0, which may save a little CPU.
-
            
-
-
            BytesContent
-
            0-2Gzip header 0x1F 0x8B 0x08
-
            3Gzip flags
-
            4-5I2P Source port (Gzip mtime)
-
            6-7I2P Destination port (Gzip mtime)
-
            8Gzip xflags
-
            9I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS)
-
            
-
-
            
-Data integrity is verified with the standard gzip CRC-32 as
-specified by RFC 1952.
-
            
-
-
-
            Future Work
            
-
            • 
-Implement I2CP and the streaming library in another programming language.
-
            • 
-Is the initial Get Date / Set Date handshake required?
-
            • 
-The current authorization mechanism could be modified to use hashed passwords.
-
            • 
-Private Keys are included in the Create Lease Set message,
-are they really required? Revocation is unimplemented.
-
            • 
-Some improvements may be able to use messages previously defined but not implemented.
-For reference, here is the
-I2CP Protocol Specification Version 0.9
-(PDF) dated August 28, 2003.
-That document also references the
-Common Data Structures Specification Version 0.9.
-
            
-
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/i2pcontrol.html b/www.i2p2/pages/i2pcontrol.html
deleted file mode 100644
index c4abdb29..00000000
--- a/www.i2p2/pages/i2pcontrol.html
+++ /dev/null
@@ -1,206 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2PControl API{% endblock %}
-{% block content %}
-
            I2PControl - Remote Control Service
            
-
            I2P enables a JSONRPC2 interface via the plugin I2PControl.
-The aim of the interface is to provide simple way to interface with a running I2P node. A client, itoopie, has been developed in parallel.
-The JSONRPC2 implementation for the client as well as the plugin is provided by the java libraries JSON-RPC 2.0.  
-A list of implementations of JSON-RPC for various languages can be found at the JSON-RPC wiki.
-
            
-
            I2PControl is by default listening on localhost:7650
            
-
-
            API, version 1.
            
-
            
-Parameters are only provided in a named way (maps).
-
-
            JSON-RPC 2 format
            
-
            -Request:
-{"id":"id", "method":"Method-name","params":{"Param-key-1":"param-value-1", "Param-key-2":"param-value-2", "Token":"**actual token**"}, "jsonrpc":"2.0"}
-Response:
-{"id":"id","result":{"Result-key-1":"result-value-1","Result-key-2":"result-value-2"},"jsonrpc":"2.0"}
-
-
            
-
            
-
              method-name – Description
-	
                Request
-		
              • Param-key-1 – Description
                • 
-		
              • Param-key-2 – Description
                • 
-		
              • Token – Token used for authenticating every request (excluding the 'Authenticate' RPC method)
                • 
-	
              
-	
                Response
-		
              • Result-key-1 – Description
                • 
-		
              • Result-key-2 – Description
                • 
-	
              
-
            
-
-
            Implemented methods
            
-
              Authenticate – Creates and returns an authentication token used for further communication.
-	
                Request
-		
              • API – [long] The version of the I2PControl API used by the client.
                • 
-		
              • Password – [String] The password used for authenticating against the remote server.
                • 
-	
              
-	
                Response
-		
              • API – [long] The primare I2PControl API version implemented by the server.
                • 
-		
              • Token – [String] The token used for further communication.
                • 
-	
              
-
            
-
              Echo – Echoes the value of the echo key, used for debugging and testing.
-	
                Request
-		
              • Echo – [String] Value will be returned in response.
                • 
-		
              • Token – [String]Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                • 
-	
              
-	
                Response
-		
              • Result – [String] Value of the key 'echo' in the request.
                • 
-	
              
-
            
-
              GetRate – Fetches rateStat from router statManager. Creates stat if not already created.
-	
                Request
-		
              • Stat – [String] Determines which rateStat to fetch, see ratestats.
                • 
-		
              • Period – [long] Determines which period a stat is fetched for. Measured in ms.
                • 
-		
              • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                • 
-	
              
-	
                Response
-		
              • Result – [double] Returns the average value for the reuested rateStat and period.
                • 
-	
              
-
            
-
              I2PControl – Manages I2PControl. Ports, passwords and the like.
-	
                Request
-		
              • *i2pcontrol.address – [String] Sets a new listen address for I2PControl (only 127.0.0.1 and 0.0.0.0 are implemented in I2PControl currently).
                • 
-		
              • *i2pcontrol.password – [String] Sets a new password for I2PControl, all Authentication tokens will be revoked.
                • 
-		
              • *i2pcontrol.port – [String] Switches which port I2PControl will listen for connections on.
                • 
-		
              • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                • 
-	
              
-	
                Response
-		
              • **i2pcontrol.address – [null] Returned if address was changed
                • 
-		
              • **i2pcontrol.password – [null] Returned if setting was changed
                • 
-		
              • **i2pcontrol.port – [null] Returned if setting was changed
                • 
-		
              • SettingsSaved – [Boolean] Returns true if any changes were made.
                • 
-		
              • RestartNeeded – [Boolean] Returns true if any changes requiring a restart to take effect were made.
                • 
-	
              
-
            
-
              RouterInfo – Fetches basic information about hte I2P router. Uptime, version etc.
-	
                Request
-		
              • *i2p.router.status – [n/a]
                • 
-		
              • *i2p.router.uptime – [n/a]
                • 
-		
              • *i2p.router.version	– [n/a]
                • 
-		
              • *i2p.router.net.bw.inbound.1s – [n/a] 
                • 
-		
              • *i2p.router.net.bw.inbound.15s – [n/a] 
                • 
-		
              • *i2p.router.net.bw.outbound.1s – [n/a] 
                • 
-		
              • *i2p.router.net.bw.outbound.15s – [n/a] 
                • 
-		
              • *i2p.router.net.status – [n/a]
                • 
-		
              • *i2p.router.net.tunnels.participating – [n/a] 
                • 
-		
              • *i2p.router.netdb.activepeers – [n/a] 
                • 
-		
              • *i2p.router.netdb.fastpeers – [n/a] 
                • 
-		
              • *i2p.router.netdb.highcapacitypeers – [n/a] 
                • 
-		
              • *i2p.router.netdb.isreseeding – [n/a] 
                • 
-		
              • *i2p.router.netdb.knownpeers – [n/a] 
                • 
-		
              • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                • 
-	
              
-	
                Response
-		
              • **i2p.router.status – [String] What the status of the router is.
                • 
-		
              • **i2p.router.uptime – [long] What the uptime of the router is in ms.
                • 
-		
              • **i2p.router.version – [String] What version of I2P the router is running.
                • 
-		
              • **i2p.router.net.bw.inbound.1s – [double] The 1 second average inbound bandwidth in Bps.
                • 
-		
              • **i2p.router.net.bw.inbound.15s – [double] The 15 second average inbound bandwidth in Bps.
                • 
-		
              • **i2p.router.net.bw.outbound.1s – [double] The 1 second average outbound bandwidth in Bps.
                • 
-		
              • **i2p.router.net.bw.outbound.15s – [double] The 15 second average outbound bandwidth in Bps.
                • 
-		
              • **i2p.router.net.status – [long] What the current network status is. According to the below enum:
-			
                  
-				
                • 0 – OK
                  • 
-				
                • 1 – TESTING
                  • 
-				
                • 2 – FIREWALLED
                  • 
-				
                • 3 – HIDDEN
                  • 
-				
                • 4 – WARN_FIREWALLED_AND_FAST
                  • 
-				
                • 5 – WARN_FIREWALLED_AND_FLOODFILL
                  • 
-				
                • 6 – WARN_FIREWALLED_WITH_INBOUND_TCP
                  • 
-				
                • 7 – WARN_FIREWALLED_WITH_UDP_DISABLED
                  • 
-				
                • 8 – ERROR_I2CP
                  • 
-				
                • 9 – ERROR_CLOCK_SKEW
                  • 
-				
                • 10 – ERROR_PRIVATE_TCP_ADDRESS
                  • 
-				
                • 11 – ERROR_SYMMETRIC_NAT
                  • 
-				
                • 12 – ERROR_UDP_PORT_IN_USE
                  • 
-				
                • 13 – ERROR_NO_ACTIVE_PEERS_CHECK_CONNECTION_AND_FIREWALL
                  • 
-				
                • 14 – ERROR_UDP_DISABLED_AND_TCP_UNSET
                  • 
-			
                
-		
                • 
-		
              • **i2p.router.net.tunnels.participating – [long] How many tunnels on the I2P net are we participating in.
                • 
-		
              • **i2p.router.netdb.activepeers – [long] How many peers have we communicated with recently.
                • 
-		
              • **i2p.router.netdb.fastpeers &ndasg; [long] How many peers are considered 'fast'.
                • 
-		
              • **i2p.router.netdb.highcapacitypeers – [long] How many peers are considered 'high capacity'.
                • 
-		
              • **i2p.router.netdb.isreseeding – [boolean] Is the router reseeding hosts to its NetDB?
                • 
-		
              • **i2p.router.netdb.knownpeers – [long] How many peers are known to us (listed in our NetDB).
                • 
-	
              
-
            
-
              RouterManager – Manages I2P router restart/shutdown.
-	
                Request
-		
              • *Reseed – [n/a] Initiates a router reseed, fetching peers into our NetDB from a remote host.
                • 
-		
              • *Restart – [n/a] Restarts the router.
                • 
-		
              • *RestartGraceful – [n/a] Restarts the router gracefully (waits for participating tunnels to expire).
                • 
-		
              • *Shutdown – [n/a] Shuts down the router.
                • 
-		
              • *ShutdownGraceful – [n/a] Shuts down the router gracefully (waits for participating tunnels to expire).
                • 
-		
              • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                • 
-	
              
-	
                Response
-		
              • **Reseed – [null] If requested, verifies that a reseed has been initiated.
                • 
-		
              • **Restart – [null] If requested, verifies that a restart has been initiated.
                • 
-		
              • **RestartGraceful – [null] If requested, verifies that a graceful restart has been initiated.
                • 
-		
              • **Shutdown – [null] If requested, verifies that a shutdown has been initiated
                • 
-		
              • **ShutdownGraceful – [null] If requested, verifies that a graceful shutdown has been initiated
                • 
-	
              
-
            
-
              NetworkSetting – Fetches or sets various network related settings. Ports, addresses etc.
-	
                Request
-		
              • *i2p.router.net.ntcp.port – [String] What port is used for the TCP transport. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.ntcp.hostname – [String] What hostname is used for the TCP transport. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.ntcp.autoip – [String] Use automatically detected ip for TCP transport. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.ssu.port – [String] What port is used for the UDP transport. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.ssu.hostname – [String] What hostname is used for the UDP transport. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.ssu.autoip – [String] Which methods should be used for detecting the ip address of the UDP transport. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.ssu.detectedip – [null] What ip has been detected by the UDP transport.
                • 
-		
              • *i2p.router.net.upnp – [String] Is UPNP enabled. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.bw.share – [String] How many percent of bandwidth is usable for participating tunnels. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.bw.in – [String] How many KB/s of inbound bandwidth is allowed. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.bw.out – [String] How many KB/s of outbound bandwidth is allowed. If null is submitted, current setting will be returned.
                • 
-		
              • *i2p.router.net.laptopmode – [String] Is laptop mode enabled (change router identity and UDP port when IP changes ). If null is submitted, current setting will be returned.
                • 
-		
              • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method. If null is submitted, current setting will be returned.
                • 
-	
              
-	
                Response
-		
              • **i2p.router.net.ntcp.port – [String] If requested, returns the port used for the TCP transport.
                • 
-		
              • **i2p.router.net.ntcp.hostname – [String] If requested, returns the hostname used for the TCP transport.
                • 
-		
              • **i2p.router.net.ntcp.autoip – [String] If requested, returns the method used for automatically detecting ip for the TCP transport.
                • 
-		
              • **i2p.router.net.ssu.port – [String] If requested, returns the port used for the UDP transport.
                • 
-		
              • **i2p.router.net.ssu.hostname – [String] If requested, returns the hostname used for the UDP transport.
                • 
-		
              • **i2p.router.net.ssu.autoip – [String] If requested, returns methods used for detecting the ip address of the UDP transport.
                • 
-		
              • **i2p.router.net.ssu.detectedip – [String] If requested, returns what ip has been detected by the UDP transport.
                • 
-		
              • **i2p.router.net.upnp – [String] If requested, returns the UPNP setting.
                • 
-		
              • **i2p.router.net.bw.share – [String] If requested, returns how many percent of bandwidth is usable for participating tunnels.
                • 
-		
              • **i2p.router.net.bw.in – [String] If requested, returns how many KB/s of inbound bandwidth is allowed.
                • 
-		
              • **i2p.router.net.bw.out – [String] If requested, returns how many KB/s of outbound bandwidth is allowed.
                • 
-		
              • **i2p.router.net.laptopmode – [String] If requested, returns the laptop mode.
                • 
-		
              • SettingsSaved – [boolean] Have the provided settings been saved.
                • 
-		
              • RestartNeeded – [boolean] Is a restart needed for the new settings to be used.
                • 
-	
              
-
            
-
            * denotes an optional value.
            
-
            ** denotes a possibly occuring return value
            
-
-
            Error codes
            
-
              Standard JSON-RPC2 error codes.
-	
            • -32700 – JSON parse error.
              • 
-	
            • -32600 – Invalid request.
              • 
-	
            • -32601 – Method not found.
              • 
-	
            • -32603 – Internal error.
              • 
-
            
-
              I2PControl specific error codes.
-	
            • -32001 – Invalid password provided.
              • 
-	
            • -32002 – No authentication token presented.
              • 
-	
            • -32003 – Authentication token doesn't exist.
              • 
-	
            • -32004 – The provided authentication token was expired and will be removed.
              • 
-	
            • -32005 – The version of the I2PControl API used wasn't specified, but is required to be specified.
              • 
-	
            • -32006 – The version of the I2PControl API specified is not supported by I2PControl.
              • 
-
            
-
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/i2ptunnel.html b/www.i2p2/pages/i2ptunnel.html
deleted file mode 100644
index 643796f4..00000000
--- a/www.i2p2/pages/i2ptunnel.html
+++ /dev/null
@@ -1,141 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}i2ptunnel{% endblock %}
-{% block content %}Description of i2ptunnel and tunneling modes
-
-default services
-client modes
-serrver modes
-
-
            I2PTunnel
            
-
            Overview
            
-
            
-I2PTunnel is a tool for interfacing with and providing services on I2P.
-Destination of an I2PTunnel can be defined using a hostname,
-Base32, or a full 516-byte destination key.
-An established I2PTunnel will be available on your client machine as localhost:port.
-If you wish to provide a service on I2P network, you simply create I2PTunnel to the
-appropriate ip_address:port. A corresponding 516-byte destination key will be generated
-for the service and it will become avaliable throughout I2P.
-A web interface for I2PTunnel management is avaliable on
-localhost:7657/i2ptunnel/.
-
            
-
-
            
-
            Default Services
            
-
            Server tunnels
            
-
              
-
            • I2P Webserver - A tunnel pointed to a Jetty webserver run
- on localhost:7658 for convenient and quick hosting on I2P.
-
              The document root is:
-
              Unix - %APPDATA%\I2P\eepsite\docroot
-
              Windows - C:\Users\**username**\AppData\Roaming\I2P\eepsite\docroot
-
              • 
-
            
-
            Client tunnels
            
-
              
-
            • I2P HTTP Proxy - localhost:4444 - A HTTP proxy used for browsing I2P and the regular internet anonymously through I2P. 
-Browsing internet through I2P uses a random proxy specified by the "Outproxies:" option.
-
              • 
-
            • IRC Proxy - localhost:6668 - A IRC proxy to the default anonymous IRC-servers.
              • 
-
            • mtn.i2p2.i2p - localhost:8998 - The anonymous monotone
- sourcecode repository for I2P
-
              • 
-
            • smtp.postman.i2p - localhost:7659 - A SMTP service provided by postman at
- hq.postman.i2p
- (via inproxy)
-
              • 
-
            • pop3.postman.i2p - localhost:7660 - The accompanying POP sevice of postman at
- hq.postman.i2p
- (via inproxy)
-
            
-
-
            
-
            Client Modes
            
-
            Standard
            
-Opens a local TCP port that connects to a service (like HTTP, FTP or SMTP) on a destination inside of I2P.
-The tunnel is directed to a random host from the comma seperated (", ") list of destinations.
-
-
            
-
            HTTP
            
-
            A HTTP-client tunnel. The tunnel connects to the destination specified by the URL
- in a HTTP request. Supports proxying onto internet if an outproxy is provided. Strips HTTP connections of the following headers:
-
            
-
              
-
            • Accept, Accept-Charset, Accept-Encoding, Accept-Language
- and Accept-Ranges as they vary greatly between browsers and can be used as an identifier.
-
              • 
-
            • Referer:
              • 
-
            • Via:
              • 
-
            • From:
              • 
-
            
-
            
-HTTP client/server tunnels are via I2Ptunnel force-enabling compression via the following http headers:
-
              
-
            • Accept-Encoding: 
              • 
-
            • X-Accept-Encoding:  x-i2p-gzip;q=1.0, identity;q=0.5, deflate;q=0, gzip;q=0, *;q=0
              • 
-
            
-
            
-Depending on if the tunnel is using an outproxy or not it will append the following User-Agent: 
-
            
-
              
-
            • Outproxy: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
              • 
-
            • Internal I2P use: User-Agent: MYOB/6.66 (AN/ON)
              • 
-
            
-
            
-
-
            IRC
            
-Creates a connection to a random IRC server specified by the comma seprated (", ") 
-list of destinations. Only a whitelisted subset of IRC commands are allowed due to anonymity concerns.
-
            Whitelist:
-
              
-
            • MODE
              • 
-
            • JOIN
              • 
-
            • NICK
              • 
-
            • QUIT
              • 
-
            • PART
              • 
-
            • WALLOPS
              • 
-
            • ERROR
              • 
-
            • KICK
              • 
-
            • H
              • 
-
            • TOPIC
              • 
-
            
-
-
            SOCKS 4/4a/5
            
-Enables using the I2P router as a SOCKS proxy.
-
-
            SOCKS IRC
            
-Enables using the I2P router as a SOCKS proxy with the command whitelist specified by
- IRC client mode.
-
-
            CONNECT
            
-Creates a HTTP tunnel and uses the HTTP request method "CONNECT" 
-to build a TCP tunnel that usually is used for SSL and HTTPS.
-
-
            Streamr
            
-Creates a UDP-server attached to a Streamr client I2PTunnel. The streamr client tunnel will 
-subscribe to a streamr server tunnel.
-
            
-
-
-
-
            
-
            Server Modes
            
-
            Standard
            
-Creates a destination to a local ip:port with an open TCP port.
-
-
            HTTP
            
-Creates a destination to a local HTTP server ip:port. Supports gzip for requests with 
-Accept-encoding: x-i2p-gzip, replies with Content-encoding: x-i2p-gzip in such a request.
-
-
            HTTP Bidirectional
            
-Functions as both a I2PTunnel HTTP Server, and a I2PTunnel HTTP client with no outproxying
- capabilities. An example application would be a web application that does client-type
- requests, or loopback-testing an eepsite as a diagnostic tool.
-
-
            IRC
            
-Creates a destination that filters the reqistration sequence of a client and passes 
-the clients destination key as a hostname to the IRC-server.
-
-
            Streamr
            
-A UDP-client that connects to a media server is created. The UDP-Client is coupled with a Streamr server I2PTunnel.
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/i2ptunnel_migration.html b/www.i2p2/pages/i2ptunnel_migration.html
deleted file mode 100644
index 888ce4ab..00000000
--- a/www.i2p2/pages/i2ptunnel_migration.html
+++ /dev/null
@@ -1,44 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}i2ptunnel migration{% endblock %}
-{% block content %}
            I2PTunnel migration:
            
-
-
            After upgrading to the new architecture, you'll have to do a 
-little work to get your old I2PTunnel-driven servers running.  
-Lets walk through a simple example.  For an eepsite with the 
-old clientApp configuration, you had:
            
-
            -  -e "server localhost 80 myWebPriv.dat"
-
            
-
-
            To provide that same functionality on the new web architecture:
            
-
              
-
            • Jump to http://localhost:7657/i2ptunnel/
              • 
-
            • Click on Add new: [Server tunnel] "GO"
              • 
-
              • 
- 
              • For the name: "eepsite"
                • 
- 
              • For the description: "My eepsite, isn't it pretty?"
                • 
- 
              • For the target host: localhost
                • 
- 
              • For the target port: 80
                • 
- 
              • For the private key file: path to "myWebPriv.dat"
                 
-  (it is recommended to copy that .dat to your new install dir)
                • 
- 
              • Check the "Start automatically?" checkbox [X]
                • 
- 
              • Click "Save"
                • 
-
              • 
-
            • It will come back saying:
              
-
              -  * Not overwriting existing private keys in /usr/home/jrandom/routers/i2p/myWebPriv.dat
-  * Ready!
-
              • 
-
            
-
-
            That's it!  Creating a new I2PTunnel server works the same way too, except you
-don't need to "copy the old file", obviously.  Behind the scenes, it is all driven
-by the i2ptunnel.config file, which you may modify externally (if you do,
-hit "Reload config" on the I2PTunnel web page, which will tear down all of your 
-existing tunnels and rebuild new ones)
            
-
-
            Note that you WILL need to wait until your router is integrated
-into the network before you are able to use the /i2ptunnel/ web
-interface.  It will say "Please be patient" if you try to 
-beforehand, which means that it is still trying to build the 
-necessary I2PTunnel sessions it has been configured to create.  
            {% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/i2ptunnel_services.html b/www.i2p2/pages/i2ptunnel_services.html
deleted file mode 100644
index 507cdf2b..00000000
--- a/www.i2p2/pages/i2ptunnel_services.html
+++ /dev/null
@@ -1,109 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}i2ptunnel services{% endblock %}
-{% block content %}Below is quick copy of aum's eepsite deployment guide.
-
            
-
-
            
-1. - Deploy a local server
            • For simplicity's sake, we will walk through the setup of a web server; however, this procedure is the same regardless what protocol of servers and/or clients you are setting up. 
-
              
-
-
            • I recommend the Tiny Httpd web server , thttpd, (windows version available on site) although you can use anything that you feel comfortable with. 
-
              
-
            • Another more robust option would be to use EasyPHP, which is also open source. It comes with PHP, PHPmyadmin, mySQL, and Apache web server. For newbies who have no experience setting up and hosting content over servers, see the hosting page for help. 
-
              
-
            • With the web server you've chosen, configure it to listen on a port of your choice, and serve its documents from a directory of your choice. For this example, we'll assume port 10880. 
-
              
-
            • Make sure your firewall is set up so that you cannot receive incoming connections on this port (which would breach your anonymity). 
-
              
-
            • Test the webserver, by pointing your normal browser (the one with the "direct connection") at http://localhost:10880 (changing the 10880 to the port number you have chosen). 
-
              
-
            • Once your webserver is working, and you can access it locally with your browser, continue to the next step. 
-
              
-
            2 - Generate an I2P Destination Keypair
            • I2P does not deal in IP addresses. To protect your anonymity, it deals in unique addresses called destination keys. 
-
-
              
-
            • A destination key works a lot like a regular IP address, except that it can't be traced to your IP address or physical location. When users place a request to speak with you, your gateways are the ones that answer for you. So the requesting user can only know the IP address of your gateways. However, gateways don't know your IP address, because gateways are the last nodes on your tunnels, and you anonymously create tunnels by way of garlic routing. (So gateways are like puppets that can't see their masters, and everyone communicates through these puppets) 
-
              
-
            • To deploy a server on I2P, you create a destination keypair. You use the private key to authenticate your server when connecting it to I2P, and you make the public key (aka destination key) known publicly, so others can connect to your server. (indirectly, through your gateways) 
-
              
-
            • Each service you run on I2P requires a different keypair. 
-
              
-
            • To generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" (all on one line) 
-
              
-
            • In windows, to generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" 
-
              
-
            • The filenames myWebPrivKey.dat and myWebPubKey.dat are arbitrary - choose whatever you want here, as long as you understand your own choices. 
-
              
-
            • We now need to export your public key into base64 format, which you will share with others. 
-
              
-
            • To convert your myWebPubKey.dat file into shareable base64, type the command java -cp lib/i2p.jar net.i2p.data.Base64 encode myWebPubKey.dat > myWebPubKey.txt (all on one line). 
-
-
              
-
            • This file you have just generated, myWebPubKey.txt, contains a long base64 string (516 chars at last count), which we call a destination key. All you need to know about this string for now is that it allows remote clients to uniquely pinpoint and connect to your server, just the same way as an IP address allows remote machines to pinpoint and connect to your machine. 
-
              
-
            • However, in contrast to an IP address, there is no way to trace your machine's physical location - even though your server can be addressed via I2P, your IP address cannot be traced or associated with this destination key. 
-
              
-
            3 - Open a 'Tunnel' from I2P To Your Server
            • For clients elsewhere in I2P to be able to access your server, you must run a 'bridge' or 'tunnel', which takes connections from these clients and forwards them to your local server 
-
              
-
            • To activate such a tunnel, type the command java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" (all one line) 
-
              
-
            • If you used different filenames or port number earlier on, change these accordingly 
-
              
-
            • Windows users, remember to replace apostrophes with double quotes. Thus: java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" 
-
              
-
            • Within a few seconds, the 'tunnel' should now be active, and remote clients should be able to reach your server anonymously. Remember to let your router "warm up" before opening clients to it. 
-
              
-
            4 - Update Your hosts.txt File
            • To test your own server locally, you'll need to create an entry in your hosts.txt file, so I2P can translate the simple URL you place in the browser's address bar into the full public key text needed to find your server. 
-
-
              
-
            • Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where myserver.i2p is an I2P 'domain' you want to associate with your site, and the blahblahblah is the text of the base64 public key you created earlier in the file myWebPubKey.txt 
-
              
-
            • With this in place, you and others can reach your server with the simple domain name myserver.i2p in the browser's address bar. 
-
              
-
            5 - Surf Your Site Within I2P
            • Using your secondary browser - the one you earlier configured to use localhost:4444 as a proxy - point this browser to the address http://myserver.i2p 
-
              
-
            • You should see the main page of your webserver come up. 
-
              
-
            6 - Create a Local Client Tunnel Connection
            • We now have to think beyond just web servers. 
-
              
-
            • As you grow into I2P and get more of a 'feel' for it, you will want to use all manner of servers and clients. 
-
              
-
-
            • The beauty of I2P is that it allows standard Internet clients and servers for most protocols to be transparently 'tunneled' through the anonymous network. 
-
              
-
            • You can run mailservers/clients, nameservers/clients, newsservers/clients - almost anything at all - perhaps even FTP in passive mode. 
-
              
-
            • Now, we'll create a client tunnel. This is like the server tunnel we created earlier, but works in reverse. It listens to a port on your local machine; your local client connects to this port; the connection gets forwarded through I2P to the service on the other end. 
-
              
-
            • To open your client tunnel for your server, type the command java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 10888 textofbase64key" (all one line). 
-
              
-
            • The port 10888 is arbitrary - it just needs to be something other than the physical port your server is listening on. 
-
              
-
            • textofbase64key is simply the contents of the public key text file myWebPubKey.txt, reproduced fully on one line (alternately, instead of textofbase64key, you can specify the name from your hosts.txt - e.g. myserver.i2p) 
-
              
-
            • Within a minute or two of launching this command, the client tunnel from your local machine into I2P will be open and ready for use. 
-
              
-
            • Point your regular web browser (ie, not the one you configured to use localhost:4444), and point it to http://localhost:10888 
-
-
              
-
            • Verify that the main page of your server eventually comes up in your browser. 
-
              
-
            • You use the same procedure for using any local client program to access a remote I2P server - just get the base64 public key (called destination key) of the remote server, choose a local port to connect to the remote server, open the tunnel, and just connect with your client to your heart's content. 
-
              
-
            7 - Share your server details with others
            • Using an anonymous medium (eg the one of the I2P IRC servers or ugha's wiki), post your domain name (eg www.mynick.i2p as well as your destination key. Others will then be able to reach your server remotely, without either of you jeopardizing your anonymity. 
-
              
-
            • Remember, you can go to What's on I2P and find the latest public keys linked to their URL. You should also post your own public key and URL their. However, you will want to do this anonymously, of course. Drupal.i2p.net is currently, as of this writing, only accessible from the net. So, to access the outside WWW anonymously from inside of I2P, you will need to start up your script called startSquid. Do it the same way you have been doing these other scripts. Reconfigure your browser to proxy on localhost:5555, as defined in the script, and when the script has generated it's keys, you can access the squid proxy. Put any WWW URL (such as Google or this i2p site) into your browser's address bar and you will be surfing the World Wide Web anonymously. Now you can safely post your public key, and no one can detect your IP address. 
-
              
-
            8 - Write Some Scripts To Handle All This Menial Nonsense
            • It would drive most people crazy, going through all these steps every time one sets up an I2P server, and/or deploys a client. 
-
              
-
            • Aum's website http://www.freenet.org.nz/i2p/ has a script called setupServer.py which automates all this nonsense into one simple command line . But I respect that people's tastes in user interfaces differ, and trying to write something which satisfies everyone's needs usually results in something so complex that it turns into newbie-repellent. 
-
-
              
-
            • So please feel free to use and/or customize setupServer.py to taste, or write your own in Python or another language. 
-
              
-
            • Also, you may want to write a script which handles the startup of the I2P Router, the eepProxy, plus any and all tunnels you are using. I've got such a script called startEverything.sh, which gets launched at system startup. (Be sure to search this site for template scripts to automate your I2P commands. If I create a page for one, I'll try to remember to link it here.
-
              
-
            • Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file.
-
              
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/index.html b/www.i2p2/pages/index.html
deleted file mode 100644
index b0fcef20..00000000
--- a/www.i2p2/pages/index.html
+++ /dev/null
@@ -1,81 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Anonymous Network{% endblock %}
-{% block content %}
-
            
-
            
-Latest version:
            
-2013-03-08 - I2P 0.9.5 - {{ urlify("release-0.9.5", "Announcement", "html")}}
-- Download
            
-2013-02-03 - Syndie 1.103b -
-
-- Download
-
            
-
            
-Latest News:
            
-2013-03-08 - I2P 0.9.5 Released
            
-2012-12-17 - I2P 0.9.4 Released
            
-2012-10-27 - I2P 0.9.3 Released
            
-2012-09-21 - I2P 0.9.2 Released
            
-
            
-
-
            
-
            
-
            I2P is an anonymizing network, offering a simple layer that identity-sensitive
-applications can use to securely communicate.  All data is wrapped with several
-layers of encryption, and the network is both distributed and dynamic, with no trusted parties.
            
-
-
            
-Many applications are available that interface with I2P, including
-mail, peer-peer, IRC chat, and others.
            
-
-
-
            
-The I2P project was formed in 2003 to support the efforts of
-those trying to build a more free society by offering them an uncensorable,
-anonymous, and secure communication system. I2P is a development effort
-producing a low latency, fully distributed, autonomous, scalable, anonymous,
-resilient, and secure network. The goal is to operate successfully in
-hostile environments - even when an organization with substantial financial
-or political resources attacks it. All aspects of the network are open source and
-available without cost, as this should both assure the people using it that the software
-does what it claims, as well as enable others to contribute and improve
-upon it to defeat aggressive attempts to
-stifle free speech.
-
            
-
-
            Anonymity is not a boolean - we are not trying to make something
-"perfectly anonymous", but instead are working at making attacks more and more
-expensive to mount.  I2P is a low latency mix network,
-and there are limits to the anonymity offered by such a system, but the applications
-on top of I2P, such as Syndie, I2P mail,
-and I2PSnark extend it to offer both additional functionality and protection.
            
-
-
            I2P is still a work in progress.
-It should not be relied upon for "guaranteed" anonymity at this time,
-due to the relatively small size of the network and the lack of extensive academic review.
-It is not immune to attacks from those with unlimited resources, and may never be,
-due to the inherent limitations of low-latency mix networks.
-
            
-
-
            
-I2P works by routing traffic through other peers, as shown in the following picture.
-All traffic is encrypted end-to-end.
-For more information about how I2P works, see the
-Introduction.
-
            
-
-
            
-end to end layered encryption
-
            
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/invisiblenet.html b/www.i2p2/pages/invisiblenet.html
deleted file mode 100644
index de48244f..00000000
--- a/www.i2p2/pages/invisiblenet.html
+++ /dev/null
@@ -1,23 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Old Documents{% endblock %}
-{% block content %}
-
-Following is a list of documents originally on www.invisiblenet.net/i2p/ and
-rescued via the
-Wayback Machine.
-They are quite dated and may or may not be accurate.
-However, the I2CP and I2NP documents in particular have some good information.
-
-
-
            Index of /i2p
            
-
            Name                    Last modified       Size
-
            
-I2CP_spec.pdf           03-Sep-2003 12:49   119k  
-I2NP_spec.pdf           03-Sep-2003 12:49   356k  
-datastructures.pdf      03-Sep-2003 12:49   149k  
-i2p_philosophy.pdf      03-Sep-2003 12:52   126k  
-polling_http_transpo..> 03-Sep-2003 12:49   189k  
-
            
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/jbigi.html b/www.i2p2/pages/jbigi.html
deleted file mode 100644
index 47747a4d..00000000
--- a/www.i2p2/pages/jbigi.html
+++ /dev/null
@@ -1,123 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}jbigi{% endblock %}
-{% block content %}
-
-Updated August 2011, current as of router version 0.8.7
-
-
            Overview
            
-
            Using JNI (Java Native Interface), a bit of C code (thanks ugha!), a little
-manual work and a piece of chewing gum we have made several
-cryptography operations quite a bit faster.
            
-
-
            
-The speedup comes from the super-fast
-GNU MP Bignum library (libgmp).
-We use a single function from libgmp -
-mpz_powm()
-as a replacement for the
-Java Math library's BigInteger modPow().
-As modPow() is a significant computational portion of many crypto operations, this is of significant benefit.
-
            
-
-
            
-The standard I2P installation includes about 20 versions of the library for different platforms,
-each about 50KB, inside the jbigi.jar file.
-The initialization of the JBigI library, including CPU identification, selection, and extraction
-of the correct loadable module, is handled by the
-NativeBigInteger class.
-If no module is available for the current platform, the standard
-Java Math library's BigInteger modPow()
-is used.
-
            
-
-
-
            Rebuilding and Testing JBigI
            
-Following are the instructions to build a new jbigi library for your own platform
-and testing its performance.
-
-
            Requirements
            
-
            This works on Linux, and with a few changes in build.sh probably also on
-other platforms. FreeBSD has also been reported to work too. On Kaffee the
-speedup is very small, because it already uses native BitInteger internally.
-Blackdown seems to cause strange errors. Because you are going to do
-compilation, you need JDK; JRE won't work.
            
-
            The required code is available in monotone database and the latest source tarball.
            
-
            The GNU MP Bignum library (libgmp) needs to be installed, if it isn't
-included in your OS / distribution or installed already, it can be received from
-http://gmplib.org/#DOWNLOAD. Even if you
-have already installed it as binary, it might still be worth a try to compile
-GMP yourself, since then it will be able to use the specific instructions of
-your processor. The latest GMP may also
-be used instead of GMP 5.0.2, but it hasn't been tested by us.
-
            
-
-
            Step-by-step instructions
            
-
              
-
            1. Look at your running environment on the logs.jsp page.
-There should be one of two status messages for JBigI - either
-
-Locally optimized native BigInteger loaded from the library path
-
-or
-
-Native BigInteger library jbigi not loaded - using pure java.
-If the native BitInteger library was NOT loaded, you definitely need to
-compile your own.
-Certain platforms, such as OS X, OpenSolaris, and 64-bit systems,
-may require you to compile your own library.
-If the BigInteger library was loaded, do at least the next step to see
-what your performance is.
-
              2. 
-
            2. Look on http://localhost:7657/stats.jsp
-to see what the lifetime average values for crypto.elGamal.decrypt and
-crypto.elGamal.encrypt are. The numbers are times in milliseconds. Copy these somewhere so you can compare
-them later on.
-The network average for encrypt time is about 20ms.
-If your encrypt time is less than 50ms for a relatively new processor, or less than 100ms
-for an older processor, and the native BigInteger library was loaded, you are probably fine.
-
              3. 
-
            3. Get the latest released source code of I2P from
-the download page, or get the cutting-edge source
-out of the monotone database mtn.i2p2.de
              4. 
-
            4. Inside the source tree change directory to: core/c/jbigi
              5. 
-
            5. Read the README file.
-If you have a /usr/lib/libgmp.so file, you do not have to download GMP.
-Use the 'dynamic' argument to build.sh.
-Otherwise, you must download GMP version 5.0.2 from
-from http://gmplib.org/#DOWNLOAD, saving it to gmp-5.0.2.tar.bz2.
-If you decide to use a newer version, change the VER= line in core/c/jbigi/build.sh.
-
            6. Take a look at build.sh, if your JAVA_HOME
-environment variable is set and you are using Linux then it might just work.
-Otherwise change the settings. Remember, you need the Java SDK installed.
              7. 
-
            7. Run build.sh (if you downloaded GMP) or
- build.sh dynamic (if you have /usr/lib/libgmp.so).
              
-Maybe the build spewed out some errors of missing jni.h and jni_md.h files.
-Either copy these files from your java install into the core/c/jbigi/jbigi/include/ directory,
-or fix $JAVA_HOME.
              
-You can run the build.sh from the core/c/ directory which will
-build all available jbigi libs into a jbigi.jar.
              
-A file named libjbigi.so should be created in the current
-directory. If this doesn't happen and/or you get errors then please report
-them.
              8. 
-
            8. Follow the instructions in core/c/README to install the library and run
-the speed test.
-Read the final lines of the speed test's output for some additional
-info, it will be something like this:
-
              -native run time:  5842ms ( 57ms each)
-java run time:   41072ms (406ms each)
-native = 14.223802103622907% of pure java time
-
              
-If the native is indeed 5-7x faster (or more) then it looks all good. If not, please
-report.
              9. 
-
            9. Copy libjbigi.so to your i2p directory
              10. 
-
            10. Restart your I2P programs.
              11. 
-
            11. On
-http://localhost:7657/stats.jsp
-the crypto.elGamal.decrypt and crypto.elGamal.encrypt
-should be a lot faster.
              12. 
-
            
-
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/manualwrapper.html b/www.i2p2/pages/manualwrapper.html
deleted file mode 100644
index b2c71411..00000000
--- a/www.i2p2/pages/manualwrapper.html
+++ /dev/null
@@ -1,54 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Manually Installing the Java Wrapper{% endblock %}
-{% block content %}
-
            Manually Installing the Java Wrapper
            
-
-
            The installation package for the I2P router comes
-with a Java wrapper for the most common architectures. If your system is not
-supported by our installer—or if you want to update the wrapper to a
-newer version—the following steps describe installing the wrapper manually.
-
            
-
-
              
-  
            •  Check Tanuki Software's download page
-       for your platform. Is your platform listed? If so, you're in
-       luck! Download the most recent version of the Community Edition for your OS and
-       CPU and move to the next step
              • 
-  
            • If your platform does not have an already compiled wrapper available, you
-      may be able to compile it yourself. If you are willing to have a go at it, move
-      on to compiling the wrapper for your system.
              • 
-
            
-
            Using existing binaries
            
-In the steps below, $I2P means the location I2P was installed to.
-
              
-  
            1. tar xzf wrapper-*.tar.gz
              2. 
-  
            2. cp wrapper*/bin/wrapper $I2P/i2psvc
              3. 
-  
            3. cp wrapper*/lib/wrapper.jar $I2P/lib
              4. 
-  
            4. cp wrapper*/lib/libwrapper.so $I2P/lib
              5. 
-  
            5. Try to start I2P using $I2P/i2prouter start
              6. 
-  
            6. tail -f /tmp/wrapper.log and look for any problems.
            
-If this did not work you'll need to use runplain.sh to start I2P.
-
            Compiling from source
            
-These steps worked to compile the wrapper for use on a mipsel system running Debian. The steps will need to be altered for your system.
-
              
-  
            1. Download the source archive for the community version of the wrapper from wrapper download page.
              2. 
-  
            2. Extract the tarball
              
-    tar xzf wrapper_3.5.13_src.tar.gz
              3. 
-  
            3. Set environment variables ANT_HOME and JAVA_HOME. In Debian, one can
              
-    export ANT_HOME=/usr/share/ant
              
-    export JAVA_HOME=/usr/lib/jvm/default-java
              4. 
-  
            4. Since there isn't a Makefile for Mipsel, we'll make a copy of an already existing makefile
              
-    cp src/c/Makefile-linux-x86-32.make src/c/Makefile-linux-mipsel-32.make
              5. 
-  
            5. Now we can attempt to compile the wrapper
              
-    ./build32.sh   (use ./build64.sh if you have a 64bit CPU and JVM)
              6. 
-  
            6. Copy the wrapper into its proper place:
-  
                
-    
              • cp bin/wrapper $I2P/i2psvc
                • 
-    
              • cp lib/wrapper.jar $I2P/lib
                • 
-    
              • cp lib/libwrapper.so $I2P/lib
                • 
-  
              7. 
-  
            7. Try to start I2P using $I2P/i2prouter start
              8. 
-  
            8. tail -f /tmp/wrapper.log and look for any problems.
              9. 
-
            
-If this did not work you'll need to use runplain.sh to start I2P.
-{% endblock %}
diff --git a/www.i2p2/pages/meeting1.html b/www.i2p2/pages/meeting1.html
deleted file mode 100644
index 2912916a..00000000
--- a/www.i2p2/pages/meeting1.html
+++ /dev/null
@@ -1,704 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 1{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 1
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Wed May 22 02:01:22 2002
-
            02:01 <+logger> Logging started
-
            02:01 <@nop> ok
-
            02:01 <@nop> welcome to this humble first meeting
-
            02:01 <@nop> first and foremost
-
            02:02 <@nop> Thank you's to all of you for your efforts
-
            02:02 <@nop> especially as we all know that there is Real life to deal with
-
            02:02 <@nop> and that we've done pretty well so far
-
            02:02 <@nop> meeting: The reason for this meeting(s) will be plural hopefully
-
            02:03 <@nop> we need to gain some order for development and schedules and tasks that are being done for IIP
-
            02:03 <@nop> whether it's contributed tasks, ala #factory, or backend, ala inform, or core ala IIP software
-
            02:03 <@nop> or ircd
-
            02:03 <@nop> :)
-
            02:03 <@mids> .
-
            02:04 <@mids> (to indicate I am here)
-
            02:04 <@nop> I think we all share a common goal in supporting this project, and it has it's rewards just knowing the technology is becoming possible to help a lot of people with free speech, privacy, anonymity and security
-
            02:04 <@nop> this is a great project in the matter, because it challenges all of these topics, and is sparking intereests especially in these times
-
            02:05 <@mids> agenda:
-
            02:05 <@mids> - Welcome (nop)
-
            02:05 <@mids> - Status of developers / projects (nop)
-
            02:05 <@mids> - Website (nym)
-
            02:05 <@mids> - Release Roadmap
-
            02:05 <@mids> - Documentation (cohesion, codeshark, mids)
-
            02:05 <@mids> - Question Round
-
            02:05 <@nop> so welcome all, and again thank you.
-
            02:05 <@Chocolate> (still connected)
-
            02:05 <@nop> next on the agenda: Status of developers
-
            02:05 <@nop> hehe
-
            02:06 <@nop> before we get there
-
            02:06 <@nop> a side not, this meeting is invite only
-
            02:06 <@nop> but will be logged and published to the public for viewing and/or comments
-
            02:06 <@nop> as well as the results 
-
            02:06 <@mids> live logging is on http://mids.student.utwente.nl/~mids/iip-dev.txt
-
            02:06 <@mids> (in case you drop out)
-
            02:07 <@nop> ok
-
            02:07 <@nop> Status of developers
-
            02:07 <@mids> who first? :)
-
            02:08 <@nop> UserX and I have been focusing on IIP 1.1 to be released, but we're to the point of no return where we would like to release iip rc2 for running tests by the team and public, but would like more thorough docs, so that's the hold up there
-
            02:08 <@nop> let's talk about docs
-
            02:08 <@nop> status : mids, cs, ?
-
            02:08 <@codeshark> you :)
-
            02:08 <@mids> .
-
            02:08 <@mids> me
-
            02:09 <@mids> I joined IIP when I heared about it on Freenet
-
            02:09 <@mids> after some chatting etc, I made Trent
-
            02:09 <@mids> our big friend :)
-
            02:09 <@nop> yes
-
            02:09 <@mids> also done some ircd patches
-
            02:09 <@mids> helped by Chocolate, thanks!
-
            02:10 <@mids> I promised 0x90 to look into doing client 2 client encryption
-
            02:10 <@mids> I did a lot of talking and research
-
            02:10 <@mids> but nothing is done :(
-
            02:10 <@nop> tis ok
-
            02:10 <@mids> currently I kind of dropped it, because I lacked time and willing
-
            02:10 <@mids> something slightly related:
-
            02:11 <@mids> I coded bankbot
-
            02:11 <@mids> another helpfull application for IIP :)
-
            02:11 < nym> hey
-
            02:11 <@nop> welcome
-
            02:11 < nym> only non op ;)
-
            02:11 <@nop> mids
-
            02:11 <@nop> continue
-
            02:11 -!- mode/#iip-dev [+o nym] by Chocolate
-
            02:11 -!- mode/#iip-dev [+o nym] by mids
-
            02:11 <@nym> sorry, i was under the impression the meeting was tomorrow
-
            02:12 <@mids> last act of me was that I ported the docs to LaTeX, more about that later
-
            02:12 <@mids> .
-
            02:12 <@nop> k
-
            02:12 <@nop> cs
-
            02:12 <@codeshark> ok, like mids i heared about iip on freenet
-
            02:12 <@codeshark> and chatted with nop about it :)
-
            02:13 <@codeshark> then i made our inform relaychecker script, that keeps a list of the running nodes
-
            02:13 <@codeshark> now i'm doing some anonymail stuff...
-
            02:14 <@nop> on a note
-
            02:14 <@nop> cs is responsible for the "dynamic routing system" that being the inform server
-
            02:14 <@nym> freenet is too slow, so i came here
-
            02:15 <@codeshark> anything else?
-
            02:15 <@codeshark> hmm, the docs
-
            02:16 <@codeshark> i created a windows version of our docs (.chm format)
-
            02:16 <@nop> yes
-
            02:16 <@nop> which will need updating once cohesion finishes the docs
-
            02:17 <@codeshark> i also made a test for the docbook format
-
            02:17 <@codeshark> but we'll come back to this later
-
            02:17 <@mids> you bet I will
-
            02:17 <@codeshark> that's it for now
-
            02:18 <@codeshark> chocolate?
-
            02:19 <@Chocolate> I first heard of IIP on freenet from CofE
-
            02:19 <@Chocolate> after seeing a couple of anouncements about it on his freesite
-
            02:19 <@Chocolate> I decided to try it out
-
            02:19 <@Chocolate> since then I have helped with misc things
-
            02:20 <@Chocolate> running a relay (precrypto, the DH didnt work on my 486)
-
            02:20 <@Chocolate> helping to debug the memory leak (by killing the ircd for about 5 hours...)
-
            02:21 <@Chocolate> my first main codeing cotribution to IIP was helping mids with Trent
-
            02:21 <@nop> kewl
-
            02:21 <@nop> don't forget hydrabot
-
            02:21 <@nop> or eyek0n
-
            02:21 <@Chocolate> oh yea right
-
            02:22 <@Chocolate> hydrabot came out of a disire to be able to see waht was happening on #freenet on OPN
-
            02:22 <@Chocolate> unfortunetly the bot died the sad death of flexibilitise
-
            02:23 <@nop> and along came eyek0n
-
            02:23 <@nop> :)
-
            02:23 <@Chocolate> yes, eyek0n is a modified changate that was hacked up to serve the purpos that HydraBot was intended to fill
-
            02:25 <@Chocolate> I also maintain a misc group of xchat and other scripts for IIP, some donated, others my own
-
            02:25 <@Chocolate> my current area of work is on ThreadChat, a realtime BBS/forums type sytem over IRC
-
            02:25 <@Chocolate> .
-
            02:25 <@nop> kewlness
-
            02:26 <@nop> ok
-
            02:26 <@nop> is that all?
-
            02:26 <@mids> ardvark just joined, he isnt a developer, but a zeroday user... he isnt allowed to introduce himself because otherwise this will take too long
-
            02:26 <@mids> maybe a quicky for nym?
-
            02:26 <@nop> ok
-
            02:27 <@nop> nym : developer intro
-
            02:28 <@nop> ok
-
            02:28 <@nop> I'll say it
-
            02:28 <@nop> he seems to be off somewhere
-
            02:28 <@mids> go for it
-
            02:28 <@nop> he comes to us as the web developer of freenetprojects' site
-
            02:29 <@nop> and we're open he can give us a make over to give us a more global appeal of anonymous irc/internet projects
-
            02:29 <@nop> open == hoping
-
            02:29 <@nop> he will be focusing on a lighter design with press releases etc
-
            02:29 <@nop> gives us less of a hobby and more of a serious developer team look to us
-
            02:30 <@nop> even though you can't see us
-
            02:30 <@nop> :)
-
            02:30 <@nop> hehe
-
            02:30 <@mids> :)
-
            02:30 <@nop> ok
-
            02:30 <@nop> agenda list
-
            02:30 <@nop> please
-
            02:30 <@mids> - Website (nym)
-
            02:30 <@mids> - Release Roadmap
-
            02:30 <@mids> - Documentation (cohesion, codeshark, mids)
-
            02:30 <@mids> - Question Round
-
            02:31 <@Chocolate> can't do website now if nym isnt here
-
            02:31 <@nop> ok well let's talk about website when nym seems awake
-
            02:31 <@nop> so Release Roadmap
-
            02:31 <@mids> .
-
            02:31 <@nop> our first focus on this is rc2
-
            02:31 <@nop> This is for testing the changes and added features and to break in any network changes that may occur before 1.1
-
            02:32 <@nym> hi
-
            02:32 <@nym> i'm here
-
            02:32 <@nop> ok
-
            02:32 <@nop> website
-
            02:32 <@nop> please
-
            02:32 <@nop> then we'll go back
-
            02:33 <@nop> to roadmap
-
            02:33 <@nym> well the website is coming along, although i thought i had another day to get something to you guys
-
            02:33 <@nop> do you have any screen shots at all
-
            02:33 <@nym> not on hand
-
            02:33 <@nop> hmm mids
-
            02:34 <@mids> http://mids.student.utwente.nl/~mids/draft2.jpg
-
            02:34 <@nop> do you have draft2?
-
            02:34 <@nop> ok
-
            02:34 <@nop> that will give people an idea
-
            02:34 <@nop> this is older
-
            02:34 <@nop> but it's what we have
-
            02:34 <@nym> okay, well what i need to know is what release this is going to correspond with
-
            02:34 <@nop> the current release
-
            02:34 <@nop> and we can modify easily
-
            02:34 <@mids> nop: current as in rc2 ?
-
            02:35 <@nop> current as as soon as we can get something
-
            02:35 <@nym> i thought you had a big release on the horizon
-
            02:35 <@nop> so focus on iip 1.1 rc1
-
            02:35 <@mids> :)
-
            02:35 <@nop> yes
-
            02:35 <@nop> but
-
            02:35 <@nop> we need something going
-
            02:35 <@nop> other than what we have
-
            02:35 <@nop> something that has a easily modifiable template
-
            02:35 <@mids> we want to have the site betatested too, same with the rcs
-
            02:35 <@nop> so that it can be prepped for released
-
            02:35 <@mids> so we can go 'big' on 1.1
-
            02:35 <@nop> releases
-
            02:35 <@nop> ok
-
            02:35 <@nop> site betatested
-
            02:35 <@nym> yeah, but what releases do you have coming, and when?
-
            02:36 <@nop> rc 2
-
            02:36 <@nop> is coming
-
            02:36 <@nop> cohesion is working on docs
-
            02:36 <@nop> cs it's easy for you to do .chm correct?
-
            02:36 <@nym> no idea what those are
-
            02:36 <@codeshark> nop: we'll have to talk about docs later :)
-
            02:36 <@nop> ok
-
            02:36 <@Chocolate> are we on the relese roadmap now or are we still on the website?
-
            02:36 <@nop> website
-
            02:36 <@nop> we went back
-
            02:36 <@nop> because nym is awake ;)
-
            02:36 <@nym> aye
-
            02:37 <@nop> let's focus on getting somethign up
-
            02:37 <@nop> then we can be focused on release
-
            02:37 <@nym> hrm okay
-
            02:37 <@nym> well i'll get something going
-
            02:37 <@nop> we would like to have it modifiable
-
            02:37 <@nop> this is key
-
            02:37 <@nop> so it's template based
-
            02:38 <@mids> nym: can you name the changes between the draft and current?
-
            02:38 <@nym> umm
-
            02:38 <@nop> umm, current I have no clue on
-
            02:38 <@nop> he might
-
            02:38 <@nop> I saw n : and answered
-
            02:38 <@nop> my bad
-
            02:38  * nop will shut up now
-
            02:39 <@nym> okay..
-
            02:39 <@nym> well lots 
-
            02:39 <@nym> font changes
-
            02:39 <@nym> drop shadows
-
            02:39 <@nym> the logo looks different (invisiblenet.net/iip/)
-
            02:40 <@nym> better crunchbox logo
-
            02:40 <@mids> great
-
            02:40 <@nym> we don't have a mac version, so i dropped that
-
            02:41 <@nym> plus i dropped anything to do with invisible im because that's not happening
-
            02:41 <@nop> not as that title
-
            02:41 <@nop> no
-
            02:41 <@nym> that's confusing
-
            02:41 <@nop> IIP is simple and makes sense
-
            02:41 <@mids> question: what about FreeBSD & OpenBSD ? its the same release as linux
-
            02:41 <@nop> let's focus on the now for that
-
            02:42 <@nop> yes
-
            02:42 <@nop> mids it is
-
            02:42 <@mids> freebsd users will be offended if they would have to click on a Tux
-
            02:42 <@nop> hmm
-
            02:42 <@nop> good point
-
            02:42 <@nym> i worry about the neiche market still tho
-
            02:42 <@nop> can we have maybe a tux and a devil fucking ;)
-
            02:42 <@nop> hehe
-
            02:43 <@nym> well we'll offer source
-
            02:43 <@nym> freebsd doesn't need a logo
-
            02:43  * nop says bad jokes too oftne
-
            02:43 <@nop> often
-
            02:43 <@nop> ok
-
            02:43 <@nop> so when can we get a new draft
-
            02:43 <@nop> give us a solid date
-
            02:43 <@nop> GMT
-
            02:43 <@mids> :)
-
            02:44 <@nym> well i can promise progress by next meeting
-
            02:44 <@nym> but i'm in the middle of a big contract atm
-
            02:44 <@nop> how much progress, like something we can put up?
-
            02:44 <@nym> well no
-
            02:44 <@nop> hmm
-
            02:44 <@codeshark> nop: it's better to wait until it's complete anyway
-
            02:45 <@nym> ditto
-
            02:45 <@mids> codeshark: current looks is terrible
-
            02:45 <@nop> understood codeshark : just thinking maybe we can revamp the current look though
-
            02:45 <@mids> I suggest reverting to the old look
-
            02:45 <@nop> it needs a lighter feel
-
            02:45 <@mids> till the site is done
-
            02:46 <@nop> we could do that unless nym can maybe dish out a slightly lighter look for it possibly
-
            02:46 <@nop> with a donation button and just like an intro page
-
            02:46 <@nym> for what?
-
            02:46 <@nop> for the site, instead of the under construction we have now
-
            02:46 <@nop> maybe like something gives more an intro and download software right off the bat
-
            02:47 <@Chocolate> well the old site is linked
-
            02:47 <@nop> then take them to the site behind it
-
            02:47 <@codeshark> nop: just make the old page easier to find
-
            02:47 <@codeshark> put the link up a bit
-
            02:47 <@nop> ok
-
            02:47 <@nym> well edit that as needed
-
            02:47 <@nop> ok
-
            02:47 <@nop> we'll figure something out
-
            02:47 <@mids> k
-
            02:47 <@nym> i'm going to keep working on the big release
-
            02:47 <@nop> can you give us a draft by friday?
-
            02:48 <@nym> most likely
-
            02:48 <@nop> ok
-
            02:48 <@codeshark> but keep the intro page until the new site is complete
-
            02:48 <@mids> screenshot is enough
-
            02:48 <@nop> thnk you
-
            02:48 <@nop> yes
-
            02:48 <@nop> screenshot/draft
-
            02:48 <@nop> same thing to me
-
            02:48 <@nym> i've got everything on my laptop now.. 
-
            02:48 <@nym> it shouldn't be a problem
-
            02:48 <@nop> ok
-
            02:49 <@nop> next part
-
            02:49 <@nop> back to roadmap release
-
            02:49 <@mids> what are the current limits for doing RC2 ?
-
            02:49 <@codeshark> what's missing except the docs?
-
            02:49 <@nop> RC2 as stated earlier is designed to get all the bugs out and adjust to changes for 1.1 final release
-
            02:49 <@nop> that's it
-
            02:49 <@nop> docs are needed
-
            02:49 <@nop> and new .chm
-
            02:49 <@nop> and cs
-
            02:49 <@nop> make sure we don't include .ini or listen.ref this time
-
            02:49 <@nop> :)
-
            02:49 <@codeshark> sure :)
-
            02:50 <@codeshark> has been removed
-
            02:50 <@nop> ok
-
            02:50 <@nop> also
-
            02:50 <@nop> cs
-
            02:50 <@nop> in the future
-
            02:50 <@nop> as people move over
-
            02:50 <@nop> to rc2
-
            02:50 <@nop> we can wait a week
-
            02:50 <@nop> but then after that I need you to add closedelay: infront of the networkprotocol = closedelay:etc
-
            02:50 <@nop> this is a key feature
-
            02:50 <@nop> that has been wanted
-
            02:51 <@codeshark> ok
-
            02:51 <@nop> this tells the network to hold on to the user even if he dies out from 15-45 seconds
-
            02:51 <@mids> (closedelays makes your connection staying up for a little while if your client or node disconnects)
-
            02:51 <@mids> (making it harder to track you to your IP)
-
            02:51 <@nop> yes
-
            02:51 <@codeshark> will it break rc-1 clients completely?
-
            02:51 <@Chocolate> can you reconnect to the held connection?
-
            02:51 <@nop> if we wait a week
-
            02:52 <@nop> most people should have upgraded
-
            02:52 <@codeshark> i'd wait a bit longer than a week
-
            02:52 <@nop> ok
-
            02:52 <@nop> maybe 2
-
            02:52 <@nop> because the network side will have it
-
            02:52 <@nop> it will still help you
-
            02:52 <@nop> but by the time rc2 is everyone
-
            02:52 <@nop> the entire network will help support your delayed presence
-
            02:53 <@nop> please send a ! now if you guys are willing to pre-test before we officially release rc2
-
            02:53 <@nop> making sure things go smoothly
-
            02:53 <@mids> !
-
            02:53 <@codeshark> !I have to do that anyway ;)
-
            02:53 <@nop> hehe
-
            02:53 <@nop> anyone else?
-
            02:54 <@codeshark> tell me if you're ready for rc-2 and i'll prepare the windows installer and *nix tgz
-
            02:54 <@nop> irc is tough for this anyway
-
            02:54 <@codeshark> you have my pager e-mail?
-
            02:54 <@nop> ok, should be ready for friday, but I really want docs updated 
-
            02:54 <@nop> no I don't
-
            02:54 <@Chocolate> !
-
            02:54 <@nop> please send it privately
-
            02:54 <@codeshark> sure
-
            02:55 <@nop> this is a publicly logged channel
-
            02:55 <@nop> you all have mine I assume
-
            02:55 <@Chocolate> the one that's only outgoing?
-
            02:56 <@nop> hehe
-
            02:56 <@nop> ok, to answer cs's question
-
            02:57 <@nop> closedelay - we need to hold off at least 2 weeks
-
            02:57 <@nop> and promote it well enough
-
            02:57 <@nop> so that people do upgrade
-
            02:57 <@nop> the challenge is
-
            02:57 <@nop> making sure relay users can just simply upgrade
-
            02:57 <@nop> without redoing the relay system
-
            02:57 <@nop> that should be trivial
-
            02:57 <@nop> but it's a necessity to make sure it's done right
-
            02:57 <@nop> choc
-
            02:57 <@nop> your question of reconnecting to help connection
-
            02:57 <@nop> can you elaborate
-
            02:57 <@nop> held
-
            02:57 <@nop> not help
-
            02:58 -!- mode/#iip-dev [+o UserX] by mids
-
            02:58 <@nop> welcome userx
-
            02:58 <@UserX> hi
-
            02:58 <@nop> can you redisplay agenda list for userx
-
            02:58 <@nop> please
-
            02:58 <@mids> - Welcome (nop)
-
            02:58 <@mids> - Status of developers / projects (nop)
-
            02:58 <@mids> - Website (nym)
-
            02:58 <@mids> - Release Roadmap
-
            02:58 <@mids> - Documentation (cohesion, codeshark, mids)
-
            02:59 <@mids> - Question Round
-
            02:59 <@nop> we're on release roadmap
-
            02:59 <@Chocolate> the closedelay holds the connection open after the user drops from IP change, or (ip) network failure
-
            02:59 <@nop> yes
-
            02:59 <@Chocolate> can you reconnect to this help connection?
-
            02:59 <@nop> no
-
            02:59 <@nop> it's just for traffic analysis preventative assistance
-
            02:59 <@Chocolate> ok, great
-
            02:59 <@nop> but there is a major other feature that works
-
            02:59 <@Chocolate> I assume it's help for a random time?
-
            02:59 <@mids> s/help/held/
-
            03:00 <@codeshark> nop: did you include the feature that tries another relay if the first doesn't work?
-
            03:00 <@Chocolate> s/help/held/
-
            03:00 <@nop> it will retry (default 5 tries) (random time yes) when connecting to network nodes so you won't get disconnected each time a relay doesn't work
-
            03:00 <@codeshark> ok, cool
-
            03:00 <@nop> codeshark see above, yes
-
            03:00 <@mids> wow, cool
-
            03:00 <@nop> this does not help you if a relay fails and you're already conencted to it
-
            03:01 <@nop> that is what closedelay does though
-
            03:01 <@nop> is makes you stall a bit visually
-
            03:01 <@codeshark> btw: we should stop adding features now
-
            03:01 <@nop> it's already stopped
-
            03:01 <@nop> :)
-
            03:01 <@codeshark> :)
-
            03:01 <@nop> cvs rc2 is tagged I believe is it not userx?
-
            03:01 <@UserX> it's not tagged yet
-
            03:01 <@codeshark> nop: not only to rc-2 but also to 1.1
-
            03:01 <@nop> correct
-
            03:02 <@nop> rc2 is just testing of the already set features
-
            03:02 <@nop> and changes
-
            03:02 <@nop> also cs
-
            03:02 <@nop> make sure we have a decent changelog
-
            03:02 <@nop> I sent you that list
-
            03:02 <@codeshark> hmm
-
            03:02 <@codeshark> email?
-
            03:02 <@nop> the changes and features
-
            03:02 <@nop> yes
-
            03:02 <@nop> I cc'd to you and cohesion
-
            03:02 <@Chocolate> could there be someway to verify that a relay has been added to the check list?
-
            03:02 <@nop> UserX - we're covering roadmap release, is there anything you would like to add
-
            03:02 <@codeshark> k, got it
-
            03:03 <@Chocolate> like I have no idea if my relay isnt on the public list becouse it didnt inform right, or becouse it's to unreliable
-
            03:03 <@nop> choc it's most likely not
-
            03:03 <@nop> but that's ok
-
            03:03 <@nop> we forgive you
-
            03:03 <@nop> :)
-
            03:04 <@codeshark> hmm, i think i should add a page where you can get infos about you relays
-
            03:04 <@mids> Chocolate's question is often asked
-
            03:04 <@codeshark> "you relays" = "your relay"
-
            03:04 <@nop> and you don't think that would compromise anything
-
            03:05 <@Chocolate> make the request come from the IP that the relay in question would have?
-
            03:05 <@codeshark> i won't show too much info
-
            03:05 <@codeshark> and i need to keep the deleted relays too
-
            03:05 <@codeshark> just mark them as deleted
-
            03:05 <@nop> spoofing 
-
            03:05 <@nop> UserX - looks like that's a no
-
            03:05 <@nop> hehe
-
            03:06 <@codeshark> nop: tcp/ip conections can't easily be spoofed
-
            03:06 <@nop> easily, but they can be
-
            03:06 <@codeshark> except you are somewhere between the relay and me
-
            03:06 <@mids> it is a php thing isnt it? (not an isproxy one)
-
            03:06 <@codeshark> yes
-
            03:06 <@nop> agenda list please
-
            03:07 <@mids> - Welcome (nop)
-
            03:07 <@mids> - Status of developers / projects (nop)
-
            03:07 <@mids> - Website (nym)
-
            03:07 <@mids> - Release Roadmap
-
            03:07 <@mids> - Documentation (cohesion, codeshark, mids)
-
            03:07 <@mids> - Question Round
-
            03:07 <@codeshark> i'll just show a small status message ("your node is on the public list", "your node has been deleted because it was down to often..."
-
            03:07 <@nop> ok
-
            03:07 <@nop> cs that's fine
-
            03:07 <@nop> any more questions on roadmap release
-
            03:07 <@mids> .
-
            03:07 <@nop> ok next part
-
            03:07 <@nop> documentation
-
            03:07 <@mids> ill do intro
-
            03:07 <@nop> k
-
            03:08 <@mids> cohesion is document manager
-
            03:08 <@mids> but he isnt here
-
            03:08 <@mids> codeshark and me are both working on it
-
            03:08 <@mids> codeshark did .chm (windows help) and Docbook
-
            03:08 <@mids> and will tell about that
-
            03:08 <@mids> I did a LaTeX version, and will explain that
-
            03:08 <@mids> why 2 systems?
-
            03:08 <@mids> docbook was taking long, and I was getting impatient
-
            03:09 <@mids> I knew that a release should be soon, so docs are wanted
-
            03:09 <@mids> I have no hate regarding codeshark or anything :)
-
            03:09 <@codeshark> :)
-
            03:09 <@mids> codeshark, can you tell us about docbook? pro and con and status?
-
            03:09 <@nop> also note
-
            03:09 <@codeshark> ok
-
            03:09 <@nop> cs was in the process of moving
-
            03:10 <@codeshark> pro's: docbook uses xml; it can generate different output formats: pdf, html, and "CHM"
-
            03:10 <@codeshark> cons: it's not that easy to learn. I think i'm the only one who wrote some help pages in it yet :(
-
            03:10 <@mids> hey, I ported trent!
-
            03:11 <@codeshark> completely?
-
            03:11 <@codeshark> cool
-
            03:12 <@codeshark> another thing about the docbook stuff we use: it's taken from the phphelp
-
            03:12 <@codeshark> so we have all the tools/templates for the different output formats
-
            03:12 <@mids> http://cvs.php.net/cvs.php/phpdoc
-
            03:12 <@mids> they made the CHM link with M$ chm cooking facility
-
            03:13 <@codeshark> it has been tested. it works. i converted some chapters of the doc to docbook
-
            03:13 <@codeshark> about CHM: why CHM?
-
            03:14 <@mids> proprietary fileformats are cool? :)
-
            03:14 <@codeshark> nope :)
-
            03:14 <@codeshark> it's the default help format on windows. it supports keyword search, fulltext search and has a nice grouping of the help chapters
-
            03:15 <@codeshark> it allows you to add bitmap to the helps (see iip.chm)
-
            03:15 <@nop> also very handy for IIP help systray  option
-
            03:15 <@codeshark> btw: mids, there's also a *nix chm viewer
-
            03:15 <@mids> sure
-
            03:16 <@mids> done?
-
            03:16 <@codeshark> yes
-
            03:16 <@mids> okay, LaTeX is a much older system then docbook
-
            03:17 <@mids> pro: its well known in the academic word, it doesnt use XML, it support different outputs: ps, dvi, pdf, html, txt. and I know it
-
            03:17 <@mids> con: it doesnt use XML, it is not very easy to learn, no native .CHM support
-
            03:17 <@nop> interrupt
-
            03:17 <@nop> real quick
-
            03:17 <@mids> I converted the whole v1.1.2-pre9 doc
-
            03:17 <@mids> ok
-
            03:18 <@nop> for pdf I notice the casper logo
-
            03:18 <@nop> can we change that to nyms logo
-
            03:18 <@nop> for reasons of copyright
-
            03:18 <@mids> sure
-
            03:18 <@nop> and at the bottom
-
            03:18 <@nop> I will send you guys a powered by InvisibleNet
-
            03:18 <@nop> which is us
-
            03:18 <@nop> logo
-
            03:18 <@nop> to put at bottom of page
-
            03:18 <@nop> :)
-
            03:18 <@codeshark> nop: the existing pdf is just a test anyway
-
            03:18 <@nop> yes
-
            03:18 <@nop> I understand
-
            03:18 <@nop> I'm just requesting
-
            03:18 <@codeshark> it doesn't use either docbook nor latex
-
            03:19 <@nop> k
-
            03:19 <@nop> well, anyway
-
            03:19 <@nop> that's a yes I assume
-
            03:19 <@codeshark> yes
-
            03:19 <@nop> kewl
-
            03:20 <@mids> I converted the whole v1.1.2-pre9 doc; its on http://mids.student.utwente.nl/~mids/docdemo/
-
            03:20 <@mids> take a look
-
            03:20 <@mids> it has the *.tex sourcefiles
-
            03:20 <@mids> the Makefile
-
            03:20 <@mids> and all the outputs... pdf, ps, dvi, txt, html and bightml
-
            03:20 <@nop> mids
-
            03:20 <@nop> you also have a sourceforge account
-
            03:20 <@mids> about chm: why does chm suck?
-
            03:20 <@nop> you have rights to make directories on the website
-
            03:20 <@nop> so that they can be there as well
-
            03:20 <@mids> nop: I know
-
            03:20 <@nop> ok
-
            03:20 <@nop> kewl
-
            03:21 <@mids> chm sucks because it is a proprietary microsoft format
-
            03:21 <@mids> there are no good opensource tools for it
-
            03:21 <@codeshark> nop: these are just experiments right now. that's why they're not on the sf server
-
            03:21 <@mids> the chm viewer for *nix is just a hard to use extractor
-
            03:21 <@mids> nobody uses windows help files anyway
-
            03:21 <@nop> ok
-
            03:21 <@mids> :)
-
            03:21 <@codeshark> hehe )
-
            03:21 <@codeshark> :)
-
            03:21 <@nop> mids
-
            03:21 <@nop> it's helpful for win32 users
-
            03:22 <@nop> and I say we can use it for help systray option
-
            03:22 <@mids> you can also put the pdf file in the IIP dir or the html ones
-
            03:22 <@nop> yes
-
            03:22 <@mids> and start the browser in the systray option
-
            03:22 <@nop> umm
-
            03:22 <@nop> trust me .chm looks nice in windows
-
            03:22 <@codeshark> sure, but do you have a chapter list in html?
-
            03:22 <@nop> so stick with that for win32
-
            03:22 <@mids> I am not against CHM for IIP, I am just not going to do it
-
            03:22 <@nop> cs will
-
            03:22 <@nop> no worries
-
            03:22 <@codeshark> aehm
-
            03:23 <@codeshark> there's a small problem
-
            03:23 <@mids> have fun codeshark :P
-
            03:23 <@nop> uhh
-
            03:23 <@codeshark> i don't want to have 2 version of the docs like we have now
-
            03:23 <@nop> sup?
-
            03:23 <@nop> umm
-
            03:23 <@nop> maybe we can make chm a separate doc
-
            03:23 <@nop> :)
-
            03:23 <@codeshark> that's how it is now
-
            03:23 <@codeshark> chm and pdf are seperate
-
            03:23 <@nop> that's all I'm saying
-
            03:23 <@nop> welcome back userx
-
            03:23 <@codeshark> but that's not how it should be
-
            03:23 <@codeshark> right mis?
-
            03:23 <@codeshark> mids?
-
            03:23 <@mids> right
-
            03:24 <@codeshark> what are the possibilities?
-
            03:24 <@nop> chm is a nice plus
-
            03:24 <@codeshark> 1) use docbook,...
-
            03:24 <@nop> one
-
            03:24 <@nop> not everyone has pdf viewers
-
            03:24 <@nop> chm for win32 is built in
-
            03:24 <@codeshark> 2) use latex and try to create the chm's from the htmls
-
            03:24 <@codeshark> 3) manually synchronize chm and html
-
            03:24 <@codeshark> 4) drop chm support
-
            03:25 <@nop> x on 4
-
            03:25 <@mids> 5) make a light chm with only the menu functions explained
-
            03:25 <@nop> hopefully x 3
-
            03:25 <@nop> yes
-
            03:25 <@nop> that's what I was thinkign
-
            03:25 <@nop> 5
-
            03:25 <@mids> (manually)
-
            03:25 <@nop> like a man page
-
            03:25 <@nop> :)
-
            03:25 <@Chocolate> eavryon on win will have a web browser
-
            03:25 <@mids> and link it for more info to the full doc as html, pdf , dvi, ps whatever
-
            03:25 <@nop> sounds good
-
            03:25 <@Chocolate> you should be able to generate an index page from the LaTeX/docbook
-
            03:25 <@codeshark> ok, i'll look at it
-
            03:25 <@nop> ok
-
            03:26 <@nop> is that it for docs?
-
            03:26 <@mids> no
-
            03:26 <@nop> ok
-
            03:26 <@nop> sorry
-
            03:26 <@mids> still pieces of doc should be written on the unix part
-
            03:26 <@nop> continue
-
            03:26 <@nop> also man page
-
            03:26 <@nop> is that completed
-
            03:26 <@mids> its still missing in the current one, cohesions work didnt have it
-
            03:26 <@nop> and symbolicly link iip with isproxy
-
            03:26 <@nop> like man iip
-
            03:26 <@mids> man page is in CVS for weeks
-
            03:26 <@nop> will give man isproxy
-
            03:26 <@mids> nobody commented on it, so I assume it is perfect
-
            03:26 <@nop> ok
-
            03:26 <@nop> nice
-
            03:27 <@nop> UserX
-
            03:27 <@nop> will IIP as is auto-install man pages
-
            03:27 <@codeshark> nop: does it have "make install" yet?
-
            03:27 <@nop> he might be having connectivity issues
-
            03:27 <@nop> yes
-
            03:27 <@mids> hairy topic
-
            03:28 <@nop> the concern is upgrading relay node users
-
            03:28 <@mids> location of manpages is really system dependant
-
            03:28 <@nop> right
-
            03:28 < UserX> make install should install the man page
-
            03:28 <@codeshark> yeah, they have to manually upgrade from rc1 to rc2
-
            03:28 <@mids> configure in 1.2 will fix that
-
            03:28 <@nop> ok
-
            03:29 -!- mode/#iip-dev [+o UserX] by mids
-
            03:29 <@nop> userx hasn't identified - policy
-
            03:29 <@nop> no ops to unidentified users
-
            03:29 <@nop> ok
-
            03:29 <@nop> spoken late
-
            03:29 <@mids> The nickname userx is registered and identified
-
            03:29 <@nop> :)
-
            03:29 <@nop> I am really lagging
-
            03:29 <@mids> np
-
            03:29 <@nop> I still have it saying that it's not
-
            03:30 <@nop> ok
-
            03:30 <@nop> continue
-
            03:30 <@mids> I am finished with my part of docs
-
            03:30 <@nop> cs
-
            03:30 <@nop> what did you mean they have to manually upgrade
-
            03:30 <@codeshark> hmm
-
            03:30 <@codeshark> docbook vs latex? ;)
-
            03:30 <@mids> latex short term, docbook long term?
-
            03:31 <@codeshark> output of both formats is ok (except missing chm support of latex)
-
            03:31 <@nop> I just want to make sure installer sees already known node.ref and listen.ref in there
-
            03:31 <@nop> as well as isproxy.ini
-
            03:31 <@nop> cohesion needs to get on the unix stuff
-
            03:31 <@codeshark> nop: windows?
-
            03:31 <@mids> mind you that we also have 2 translatins
-
            03:31 <@nop> yes
-
            03:31 <@nop> obviously as long as we don't include our own isproxy.ini, node.ref or listen.ref for unix
-
            03:32 <@nop> we should be fine
-
            03:32 <@nop> we might want to have a blurb in doc about upgrading
-
            03:32 <@nop> to install in same directory
-
            03:32 <@nop> for upgraded node
-
            03:32 <@nop> or import your .ref and .ini files
-
            03:32 <@nop> etc
-
            03:32 <@nop> to be discussed later
-
            03:32 <@mids> .
-
            03:32 <@nop> agenda list please
-
            03:33 <@mids> - Welcome (nop)
-
            03:33 <@mids> - Status of developers / projects (nop)
-
            03:33 <@mids> - Website (nym)
-
            03:33 <@mids> - Release Roadmap
-
            03:33 <@mids> - Documentation (cohesion, codeshark, mids)
-
            03:33 <@mids> - Question Round
-
            03:33 <@nop> ok
-
            03:33 <@nop> question round
-
            03:33 <@nop> any questions
-
            03:33 <@codeshark> nop: i think i'm already handling the upgrading stuff. but i have to check
-
            03:33 <@nop> ok
-
            03:33 <@mids> why is not everybody here?
-
            03:33 <@nop> thnx cs
-
            03:33 <@codeshark> we looked at it on rc1 already
-
            03:33 <@nop> answer : real life
-
            03:33 <@nop> :)
-
            03:33 <@nop> ok
-
            03:33 <@mids> is this time correct or need a better one?
-
            03:34 <@nop> so far it's not conflicting
-
            03:34 <@mids> (it took 1:30 hours now_
-
            03:34 <@nop> well
-
            03:34 <@nop> this is a first meeting
-
            03:34 <@nop> so I can see why
-
            03:34 <@nop> we'll get better
-
            03:34 <@codeshark> well a bit earlier would be nice
-
            03:34 <@nop> and shorter
-
            03:34 <@nop> :)
-
            03:34 <@codeshark> if possible
-
            03:34 <@nop> the conflict with that
-
            03:34 <@mids> yes, please
-
            03:34 <@nop> hmm
-
            03:34 <@nop> I can't do too much earlier
-
            03:34 <@codeshark> it's 4 am soon :(
-
            03:34 <@mids> 1 hour shorter would be fine
-
            03:34 <@codeshark> yeah, right
-
            03:35 <@nop> hmm
-
            03:35 <@mids> more q's?
-
            03:36 <@codeshark> mids: what is cohesion doing right now?
-
            03:36 <@nop> let's try this for a bit, and see if it's workable
-
            03:36 <@codeshark> on the docs?
-
            03:36 <@nop> dunno
-
            03:36 <@mids> codeshark: dont ask me
-
            03:36 <@nop> he needs to work on contact
-
            03:36 <@mids> btw 1 yodel for everybody attending this meeting
-
            03:36 <@nop> thnx
-
            03:36 <@nop> :)
-
            03:36 <@codeshark> hehe, thanks mids :)
-
            03:37 <@codeshark> btw: right now we have 4 systems to create help files :(
-
            03:37 <@nop> closing
-
            03:38 <@mids> I will leave the log running for a couple of hours
-
            03:38 <@mids> its available on that url
-
            03:38 <@nop> meeting ajouned, thank you for all attending
-
            03:38 <@nop> see you next week
-
            03:38 <@codeshark> same time, same place?
-
            03:38 <@nop> yes
-
            03:39 <@nop> thnx all
-
            03:39  * nop will brb after these messages
-
            03:39  * codeshark will go to sleep soon
-
            03:39 <@mids> night
-
            03:46 <@nop> night
-
            03:47 <+logger> Ended logging
-
            --- Log closed Wed May 22 03:47:55 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting10.html b/www.i2p2/pages/meeting10.html
deleted file mode 100644
index 8ac88997..00000000
--- a/www.i2p2/pages/meeting10.html
+++ /dev/null
@@ -1,171 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 10{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 10
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Sep 03 23:55:46 2002
-
            23:56 <@mids> test
-
            --- Day changed Wed Sep 04 2002
-
            00:34 < athena> hello :)
-
            00:34 < athena> no specific agenda today?
-
            00:36 -!- mode/#iip-dev [+o nop] by mids
-
            00:36 -!- mode/#iip-dev [+v logger] by mids
-
            00:36 <@mids> not yet atleast
-
            00:55 < athena> OQP... cute :)
-
            00:56 <@mids> what is OQP?
-
            00:56 < athena> occupe', i'm guessing
-
            00:56 <@mids> ic
-
            00:58 < gabierOQP> OQP=occupé in french
-
            00:58 < gabierOQP> busy
-
            00:58 -!- gabierOQP is now known as legabier
-
            00:59 <@mids> compris
-
            01:00 <@mids> Tue Sep  3 23:00:00 UTC 2002
-
            01:00 <@mids> Welcome to the 10th IIP meeting
-
            01:00 <@mids> Agenda:
-
            01:00 <@mids> 1) Welcome
-
            01:00 <@mids> 2) Website status update
-
            01:00 <@mids> 3) ...
-
            01:00 <@mids> a) Questions
-
            01:00 <@mids> .
-
            01:00 <@mids> lets go to point 1
-
            01:00 <@mids> welcome all
-
            01:00 < legabier> why freenet is so slow and iip so fast?
-
            01:01 <@mids> legabier: can we keep that till part a ?
-
            01:01 < legabier> ok
-
            01:01 <@mids> part 2
-
            01:01 <@mids> nop: status update?
-
            01:02 <@mids> hm
-
            01:02 <@mids> the website is in CVS
-
            01:02 <@mids> nop has reviewed the files
-
            01:03 <@mids> but there are some parts without good text
-
            01:03 <@mids> and the support area needs a better layout
-
            01:03 <@mids> appart from that it is done
-
            01:03 <@mids> I wont tell you when the site is up
-
            01:03 <@mids> but you are free to do private bettings on the online time :)
-
            01:04 <@mids> .
-
            01:04 <@mids> nop probably has something to add
-
            01:04 <@mids> lets wait 3 min or something
-
            01:06 < athena> lol
-
            01:06 <@mids> I guess nop is too busy with editing the website to answer
-
            01:06 <@mids> okay well...
-
            01:06 <@mids> before we go to the question round.. any other items we should discuss?
-
            01:08 <@mids> guess not :-)
-
            01:08 <@mids> I like it when everybody agrees :)
-
            01:08 <@mids> .
-
            01:08 <@mids> question from legabier: "why freenet is so slow and iip so fast?"
-
            01:08 <@mids> freenet is a different program, there is no technical relationship between IIP and Freenet
-
            01:08 <@mids> Freenet is completely decentralized.. IIP isn't (yet)
-
            01:08 <@nop> haha
-
            01:09 <@mids> Freenet is intended for file transfer, while IRC over IIP uses short lines
-
            01:09 <@nop> just because freenet is decentralized
-
            01:09 <@nop> is not the reason why IIP is fast
-
            01:09 <@mids> well, enlighten us, o master yoda :)
-
            01:10 <@nop> differences
-
            01:10 <@nop> freenet == high volume, low speed, static (archived) content
-
            01:10 <@nop> iip == low volume, high speed, dynamic content
-
            01:10 <@nop> different concepts all together, centralized or decentralized, IIP will remain fast
-
            01:11  * mids hopes that too
-
            01:11  * nop knows that
-
            01:11 <@mids> ok
-
            01:11 <@mids> does that answer your question legabier ? 
-
            01:12 < legabier> yes merci :)
-
            01:13  * mids aims the spotlight in the audience.. searching for the next question and/or comment
-
            01:13 < athena> why are there so few public relays (besides the ones nop runs and mids', i see only 2 or 3 others usually)?  do we have no volunteers or does the uptime checker reject a lot of them?
-
            01:13 < Sheige> I got 8 of them.... I guess
-
            01:14 < Sheige> (still a few)
-
            01:14 < athena> how many is that if you don't count mids' and nop's?
-
            01:14 <@mids> 5
-
            01:14 <@mids> source: http://invisiblenet.net/iip/crypto/node.ref
-
            01:15 < athena> hmmm, ok... guess i need to pull down a new one... still, 20 or so public nodes would be nice :)
-
            01:15 <@mids> I _think_ that the uptime checker is a bit too strict
-
            01:16 <@mids> codeshark had to pause it some time ago when the net was down
-
            01:16 <@mids> otherwise it would kick all relays out
-
            01:17 <@nop> the strict checking is a good thing
-
            01:17 <@nop> you'd have more problems if you had a lot of relays not working
-
            01:17 <@nop> it's better to have lower number with solid relay connection
-
            01:17 <@mids> nop: well.. but the reannounces dont seem to work
-
            01:17 <@nop> than a bunch of crappy ones
-
            01:17 <@nop> yes they do
-
            01:17 <@mids> hm
-
            01:17 <@nop> it just takes time
-
            01:17 <@nop> plus if you're a relay you won't see your route
-
            01:17 <@mids> then why do we only have 7 :)
-
            01:17 <@nop> because the stability of the relays
-
            01:18 <@nop> it may take a few more days for them to show up
-
            01:20 <@nop> talk to codeshark about this
-
            01:20 <@nop> he would have more detail
-
            01:20 <@nop> I will test it with him
-
            01:20 <@mids> ok
-
            01:21 <@mids> I think that I have somehow too many nodes connecting to my relay
-
            01:21 <@mids> but maybe there are a lot more users then we know about :)
-
            01:21 < athena> how many connections do you have?
-
            01:22 <@mids> I dont know if I should tell that
-
            01:22  * mids does some back channel talking
-
            01:22 < athena> could be that you're the best reachable relay
-
            01:22 <@mids> heh, I wouldnt say that with the recent lack of stability
-
            01:22 < athena> i often find that i can't connect through half of the hosts in node.ref
-
            01:23 < athena> and when you start with 7 that's not a whole lot of reliable relays
-
            01:23 <@nop> well, most usually are that are on
-
            01:23 < athena> just relating my experience...
-
            01:24 <@nop> maybe it's recent
-
            01:25 <@mids> it would be interesting to measure uptime...
-
            01:25 <@mids> but...
-
            01:25 < athena> you'd have to measure it from topologically diverse sites
-
            01:27 <@mids> nop: would you be against that?
-
            01:27 <@mids> if this whole thing wasn't about anonymity, I would love to see a lot of statistics :)
-
            01:27 <@nop> umm, if it exposes attacking info, yes
-
            01:28 <@nop> maybe we'll set up a non-anonymous weary system later and take stats
-
            01:28 < athena> i would say any publicly available stats SHOULD be published
-
            01:28 <@nop> especially as it gets bigger
-
            01:28 < athena> rely on the security of IIP, not on keeping info secret
-
            01:28 <@nop> well athena, if anyone was taking stats, they should be published
-
            01:28 <@nop> but no one is so far
-
            01:28 <@nop> anyone who is please publish your findings
-
            01:28 <@nop> ;)
-
            01:29 < athena> maybe i will :p
-
            01:29 <@mids> well.. I'll try to collect stats in a 'fair' way
-
            01:29 <@mids> without abusing my public node-powers
-
            01:29 <@mids> what I can collect that way, everybody can
-
            01:29 < athena> that's exactly what i meant, great
-
            01:30 < ArdVark> why not abuse your public node power and show us what that entails too mids?
-
            01:30 <@mids> now if I disappear from the IIP chat system... it is because someone doesnt like me collecting the stats ;)
-
            01:30 <@mids> ArdVark: maybe that is the next step...
-
            01:30 < athena> ArdVark: lol, excellent point!  since anyway can become a public node...
-
            01:31 < athena> s/anyway/anyone/
-
            01:31 <@mids> athena: install a public relay and you do it :)
-
            01:31 < ArdVark> I wanna see the failures as well as the successes of this beast reported
-
            01:32 <@mids> would be cool to have 100 'agencies' all running a public relay to log connections, but in the meanwhile helping to boost the anonymity
-
            01:33 < ArdVark> on a different topic, not to end the current one, has there ever been any thought to adding wiki to invisiblnet?  or too much trouble?
-
            01:33 <@mids> wiki as in wikiwiki?
-
            01:33 < ArdVark> yes
-
            01:33 <@mids> those $#@&%@ infobots are already some wiki
-
            01:33 < athena> mids: how do you know i don't already run a public relay ;)
-
            01:34 < ArdVark> I love those infobots mids   ;)
-
            01:34 <@mids> ArdVark: I know you do
-
            01:34 <@mids> ArdVark: if you put a webserver 'behind' IIP.. then you could install a wiki on it
-
            01:35 < ArdVark> ok, that is reasonable I guess
-
            01:35 <@mids> but running a webserver over irc isnt too great
-
            01:35 < ArdVark> no I meant the website
-
            01:35 <@mids> oh
-
            01:35 <@mids> you mean on the normal website
-
            01:35 < ArdVark> yes
-
            01:36 <@mids> guess you could do that
-
            01:36 <@mids> otoh.. you could use a public wiki too....
-
            01:36 < ArdVark> ok
-
            01:37 <@mids> I think we shouldnt really install the wiki on sourceforge.... not now
-
            01:37 <@mids> since it is some work to install/tweak etc
-
            01:38 <@mids> but someone could run a wiki, and then IIP could point to it
-
            01:38 < ArdVark> fine
-
            01:39 <@mids> ArdVark: but maybe a public wiki for IIP (like freenet has now) is the way to go
-
            01:39 <@mids> .
-
            01:39 < ArdVark> yeah ok  
-
            01:41 <@mids> I am going to sleep. feel free to keep chatting here :)
-
            01:41 < athena> night mids
-
            01:49 <@mids> for those who want to play with a wiki: http://mids.student.utwente.nl/~mids/phpwiki/
-
            01:49 <@mids> I dont care what you do with it :)
-
            02:00 -!- mode/#iip-dev [+o codeshark] by Trent
-
            --- Log closed Wed Sep 04 07:03:17 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting100.html b/www.i2p2/pages/meeting100.html
deleted file mode 100644
index fd073647..00000000
--- a/www.i2p2/pages/meeting100.html
+++ /dev/null
@@ -1,195 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 100{% endblock %}
-{% block content %}
            I2P dev meeting, July 27 @ 21:00 GMT
            
-
            
-
            14:02 < jrandom> 0) hi
            
-
            14:02 < jrandom> 1) 0.3.3 & current updates
            
-
            14:02 < jrandom> 2) NativeBigInteger
            
-
            14:03 < jrandom> 3) ???
            
-
            14:03 < jrandom> 0) hi
            
-
            14:03  * jrandom waves
            
-
            14:03 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-July/000372.html
            
-
            14:03 < jrandom> (thanks to hypercubus' prodding i got it out before the meeting :)
            
-
            14:04 < jrandom> ok, jumping on in
            
-
            14:04 < jrandom> 1) 0.3.3 & current updates
            
-
            14:06 < jrandom> there's a truckload of info in the email describing whats going on, and there should be a substantial reduction in bandwidth usage coming up
            
-
            14:07 < jrandom> it won't be backwards compatible because it changes a lot of things, so the next release will be a bumpy upgrade as well, but c'est la vie
            
-
            14:08 < jrandom> anyone have any questions wrt the 0.3.3 rev or the things posted in the status notes?
            
-
            14:08  * dm waves
            
-
            14:08  * jrandom is seeing 23s lag here @ freenode
            
-
            14:09  * hypercubus sees 0.10 secs lag
            
-
            14:09 < jrandom> ah back to normal
            
-
            14:09 < jrandom> ok, if there's nthing, we can just jump in to 2) NativeBigInteger
            
-
            14:10 < jrandom> Iakin3 has modified some things so it'll be simpler to deploy the crypto code out of the box, which is Good
            
-
            14:10 < jrandom> every once in a while i look in the netDb and see some people with 2-400ms delays when doing ElGamal encryption, which means some people aren't using jbigi
            
-
            14:11 < jrandom> (and everyone should use jbigi)
            
-
            14:12 < deer> <Nightblade> how do you know they are not just on slow computers
            
-
            14:12 < Sonium> why isn't it use automaticaly?
            
-
            14:12 < hypercubus> because it must be custom compiled for each platform
            
-
            14:12 < jrandom> we might be able to get that deployed in this next rev, but we'll see
            
-
            14:12 < deer> <oOo> If the DLL is not present, the program continue using java-only code (needed for cross-platform support)
            
-
            14:12 < hypercubus> and currently the platform is not detected
            
-
            14:12 < jrandom> Nightblade: thats possible, of course
            
-
            14:13 < jrandom> oOo right, we definitely will keep that functionality
            
-
            14:13 < deer> <oOo> Nope, force the existence of the dll an .so files, even if empty or useless
            
-
            14:13 < jrandom> actually, thats another one of the things we're gaining with some of the current mods i'm working on - we only need to do half as many elGamal encryptions (since the sourceRouteBlock is gone)
            
-
            14:14 < jrandom> hmm oOo?
            
-
            14:14 < jrandom> why would we want to do that?
            
-
            14:15 < deer> <oOo> Force a check of the _existence_ of the library files. If they are not use, you most likely aren't on a x86 Win/Linux platform and are forced to use the Java code. Anyway you did your best to force the use of native stuff
            
-
            14:15 < jrandom> oh, right, we have always checked for libjbigi.so / jbigi.dll, the thing Iakin's code adds is the ability to package up a whole bunch of DLL and .so files into a jar and choose the *right* one at runtime
            
-
            14:16 < hypercubus> </obvious>
            
-
            14:16 < jrandom> (falling back on pure java if none match)
            
-
            14:17 < jrandom> anyway, thats some good stuff that'll hopefully help new users out a bunch
            
-
            14:17 < jrandom> (and saves me the time of doing some ugly drop down boxes on the admin interface :)
            
-
            14:18 < jrandom> ok, if there's nothing more on that, i think thats all i've got
            
-
            14:18 < jrandom> so moving on to 3) ???
            
-
            14:18 < jrandom> anyone else have anything they want to bring up?
            
-
            14:18 < hypercubus> someone should run a spellchecker on the new website ;-)
            
-
            14:19 < jrandom> you've got cvs access now... :)
            
-
            14:19 < jrandom> (module: i2pwww)
            
-
            14:19 < hypercubus> damn
            
-
            14:19 < deer> <oOo> The corruption on big transfer, even local one, is under investigation (like grabbing several Mb from your own eepsite) ?
            
-
            14:20 < hypercubus> i've had many interrupted downloads of big files, but never a corruption
            
-
            14:20 < jrandom> hmm, most instances of that issue have been resolved, but i've heard reports recently about it.  i haven't gone through the app layer and audited things yet again
            
-
            14:21 < jrandom> i consider interrupted downloads corrupted
            
-
            14:21 < jrandom> it must work first time, all the way through
            
-
            14:21 < hypercubus> well you can't help it, because that's what happens on the real WWW too ;-)
            
-
            14:21 < deer> <oOo> Not when the grabber is on the same computer then the server ^^
            
-
            14:22 < jrandom> oOo: can you reproduce that?
            
-
            14:22 < jrandom> (or is it intermittent?)
            
-
            14:22 < deer> <oOo> jrandom: Did twice, was thinking it was knowed, will try again
            
-
            14:23 < jrandom> thanks.  if you can reproduce it, please let me know the details of the test and i'll dig further into it.  
            
-
            14:23 < jrandom> (i've got to audit the app layer again anyway soo)
            
-
            14:23 < deer> <oOo> jrandom: No problem, thanks
            
-
            14:24 < jrandom> ok, anyone else have anything they want to ask/bring up?
            
-
            14:25 < cat-a-puss> I'm still interested in talking about how to do myI2P
            
-
            14:25 < cat-a-puss> I may be able to bring a few people in in a few months
            
-
            14:25 < jrandom> awesome!
            
-
            14:26 < hypercubus> a class project? ;-)
            
-
            14:26 < cat-a-puss> something like that ;-)
            
-
            14:27 < jrandom> i think once we get 0.4 out there with the new web interface, it should be much easier to put together apps (like myi2p) w/ a web frontend
            
-
            14:27 < cat-a-puss> so you think that can be done on the purely application layer?
            
-
            14:27 < jrandom> absolutely
            
-
            14:28 < jrandom> what else did you have in mind?
            
-
            14:28 < cat-a-puss> well the network DB could be used to store metadata
            
-
            14:28 < jrandom> ahh
            
-
            14:28 < cat-a-puss> would it have access to that?
            
-
            14:28 < hypercubus> *cough*
            
-
            14:28 < jrandom> no, nothing has access to the netDb
            
-
            14:29 < jrandom> we're able to work some magic in the netDb because its quite focused just on serving as our distributed routing table
            
-
            14:29 < hypercubus> cat-a-puss: what you want is the DHT that Nightblade is working on
            
-
            14:29 < jrandom> myi2p (et al) could certainly use a DHT on top of i2p though
            
-
            14:30 < hypercubus> (enclave)
            
-
            14:30 < jrandom> what sort of metadata were you thinking about?
            
-
            14:31 < cat-a-puss> well I invesioned doing something like chanels in Frost which runs off of an ssk in freenet
            
-
            14:31 < cat-a-puss> so you run the ssks on the DHT on top of I2p
            
-
            14:31 < jrandom> right
            
-
            14:31 < jrandom> that might be a bit of an overkill for some things though
            
-
            14:31 < cat-a-puss> but you still need a metakey that lists all the people's ssks that are subscribed to the channel
            
-
            14:32 < dm> dht over i2p... 
            
-
            14:32  * dm doesn't see that working reliable any time soon.
            
-
            14:32 < Connelly> a generic DHT library would be nice
            
-
            14:32 < dm> reliably
            
-
            14:32 < deer> <Nightblade> what's a dht library
            
-
            14:32 < cat-a-puss> that needs to work diferently ...
            
-
            14:33 < jrandom> cat-a-puss: i suppose it depends on what sort of activity would go on, but while frost style boards might be good for some things, fmb style boards might be good for others, and blog aggregators might be good for still others
            
-
            14:34 < Connelly> well a kademlia implementation or somesuch
            
-
            14:34 < Connelly> I assume enclave would be something like it
            
-
            14:34 < deer> <Nightblade> i think i'm going to do some changes on LibSAM first
            
-
            14:34 < deer> <Nightblade> only two weeks of classes left, for me, counting this week
            
-
            14:34 < deer> <Nightblade> then I will be able to do some stuff I hope
            
-
            14:35 < jrandom> w00t!  :)
            
-
            14:37 < cat-a-puss> jrandom: basicly the goal is to be all things to all people. If the network does not do everything, people will use something else. (and it needs to be better at it to attract cover traffic)
            
-
            14:38 < jrandom> i've worked on too many projects that try to do the 'swiss army knife' style - if you build it, they will come
            
-
            14:38 < hypercubus> the network is a transport layer, not the application layer ;-)
            
-
            14:38 < jrandom> it very, very, very rarely works out.
            
-
            14:38 < jrandom> the i2p transport layer should support all possible point to point comm, definitely
            
-
            14:38 < jrandom> but applications on top of i2p should be user friendly - meaning they address a specific user need and help them with it
            
-
            14:39 < jrandom> the masses don't want a comm layer, they want a way to talk to people, to read what people say, and to explore
            
-
            14:39 < Connelly> naw, we should create an XUL, and all new Gecko system
            
-
            14:39 < Connelly> then build a conglomerate of Mozilla programs on top of that
            
-
            14:39 < Connelly> then integrate collaborative systems into Mozilla ;)
            
-
            14:40 < cat-a-puss> great provided the app has enough control over the comm layer to make it do what it wants.
            
-
            14:40 < dm> Maxthon > Mozilla
            
-
            14:40 < jrandom> cat-a-puss: absolutely.  all apps using SAM, I2CP, or the SDK can do what every other app can do
            
-
            14:41 < jrandom> (which should be sufficient [the functionality / API is modelled after JMS and MOMs, which has been battle tested for well over a decade in industry])
            
-
            14:43 < cat-a-puss> ok, so I've essencialy got: Tcp, datagram, both of those + anonymity if I want it, and a DHT that operates above all that.
            
-
            14:44 < hypercubus> you have some anonymity, whether you like it or not ;-)
            
-
            14:44 < cat-a-puss> so the app cannot set the tunnel lenth to 0 even if it wants to?
            
-
            14:44 < jrandom> right - i2p itself is the TCP/datagram stuff, and the enclave DHT app could be used as a base for the data store
            
-
            14:44 < jrandom> absolutely
            
-
            14:45 < jrandom> in fact, with 0 hop tunnels and the defense Connelly outlined last week, it can be pretty anon vs some attackers
            
-
            14:45 < jrandom> er, i misread what you said.  yes the app can set the tunnel length to 0, but in fact, that still provides some degree of anonymity
            
-
            14:46 < cat-a-puss> ok
            
-
            14:46 < jrandom> (sufficient for some people, but insufficient vs some statistical attacks)
            
-
            14:46 < hypercubus> if you wanted no anonymity, you shouldn't be running your traffic over i2p
            
-
            14:47 < cat-a-puss> and different apps on the same host/port I assume are just handled with seperate keys?
            
-
            14:47 < jrandom> exactly
            
-
            14:47 < deer> <DrWoo> low anonymity could be popular for running p2p over I2P ?
            
-
            14:47 < cat-a-puss> then the only question I have left is some sort of an "answering service"
            
-
            14:47 < jrandom> right DrWoo - filesharing / etc would probably be able to use 0 hop tunnels
            
-
            14:48 < deer> <DrWoo> hey soros!
            
-
            14:48 < hypercubus> i'm thinking BitTorrent-style apps on i2p would likely need 0-1 hop tunnels
            
-
            14:48 < Connelly> jrandom: which defense for 0 hop tunnels?
            
-
            14:48 < deer> <soros> hey woo :D
            
-
            14:48 < deer> <DrWoo> soros: you were hiding hehe
            
-
            14:48 < cat-a-puss> IE: set something up in the i2p database where my traffic goes to someone else while I am offline, and then when I come back up I contact them and they fill me in on what I missed?
            
-
            14:48 < cat-a-puss> they needn't be able to decrypt it
            
-
            14:48 < deer> <soros> gave up on iip for a few months
            
-
            14:48 < dm> soros and drwoo reunion...
            
-
            14:48 < dm> TEAR
            
-
            14:48 < hypercubus> cat-a-puss: again, app layer stuff
            
-
            14:49 < jrandom> cat-a-puss: i don't know, that sort of functionality i hadn't really envisioned w/ myi2p, but there are a few ways to do it
            
-
            14:49 < deer> <soros> is this going to freenode automatically ?
            
-
            14:49 < deer> <soros> oops.. this is i2p sorry
            
-
            14:49 < jrandom> Connelly: using strict ordering for the peers in the tunnel
            
-
            14:49 < deer> <DrWoo> soros: it's a little confusing lol
            
-
            14:50 < Connelly> ok
            
-
            14:50 < hypercubus> we need to run a poll on the forum to vote for a new name for myI2P ;-)
            
-
            14:51 < jrandom> betty
            
-
            14:51 < hypercubus> MyBetty?
            
-
            14:51 < dm> MY TOOPIE
            
-
            14:51 < jrandom> heh
            
-
            14:51 < deer> <Nightblade> how about acropolis....... was that it?
            
-
            14:51 < hypercubus> Betty Toop?
            
-
            14:51 < deer> <soros> MOAP2P
            
-
            14:51 < deer> <DrWoo> I2P H@ME
            
-
            14:51 < deer> <soros> Mother of all P2P
            
-
            14:52 < hypercubus> nightblade: yeah, acropolis
            
-
            14:52 < hypercubus> i like it
            
-
            14:53 < dm> How about: Pipi in your face
            
-
            14:53 < hypercubus> dm: you do know this is all going in the meeting log right? ;-)
            
-
            14:53 < Connelly> man, I got a great idea
            
-
            14:53 < deer> <DrWoo> Center of the Known I2P
            
-
            14:53 < dm> hypercubus: pipi in your face
            
-
            14:53 < Connelly> let's integrate a 3D user-programmable RPG into I2P H@ME
            
-
            14:53 < deer> <soros> call it HyperCube.
            
-
            14:54 < Connelly> and use Mozilla technology to do it :)
            
-
            14:54 < dm> Maxthon pipi on mozilla
            
-
            14:54 < Connelly> fine, Maxthon
            
-
            14:54 < hypercubus> you on a xul kick connelly? ;-)
            
-
            14:54 < Connelly> yeah!
            
-
            14:55 < Connelly> but we should create a whole XML-based programming language
            
-
            14:55 < Connelly> it would be more flexible that way
            
-
            14:55 < jrandom> and then lets build our own hardware too
            
-
            14:55 < hypercubus> i2p custom wireless mesh routers
            
-
            14:55 < jrandom> and put together a distribution company with ships and trains to get 'em out there! :)
            
-
            14:55 < dm> I know CPUs
            
-
            14:55 < dm> I build one
            
-
            14:56 < deer> <mule> plus build the chip production facilities ...
            
-
            14:56 < Connelly> yeah, an anonymous shipping corporation
            
-
            14:56 < hypercubus> call it WhoEx
            
-
            14:56 < Connelly> and use reflectors on the moon to beam laser internet traffic to each other!
            
-
            14:57 < hypercubus> time to boof the meeting i sense
            
-
            14:57 < jrandom> on that not..
            
-
            14:57 < jrandom> er, note
            
-
            14:57 < jrandom> anything else people want to bring up?  if not, we've got the forums and the mailing list
            
-
            14:57 < jrandom> (and we're here all the time ;)
            
-
            14:57  * jrandom winds up
            
-
            14:57 < dm> not me, I have a life.
            
-
            14:57 < dm> LOSERS
            
-
            14:57 < dm> NEEEEEEEEEEEEEEEERRRRRRRRRDDDDDDDSSSSS
            
-
            14:57  * jrandom *baf*s dm on the head
            
-
            14:58 < jrandom> (closing the meeting)
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting101.html b/www.i2p2/pages/meeting101.html
deleted file mode 100644
index 7822425b..00000000
--- a/www.i2p2/pages/meeting101.html
+++ /dev/null
@@ -1,221 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 101{% endblock %}
-{% block content %}
            I2P dev meeting, August 3 @ 21:00 GMT
            
-
            
-
            14:05 <jrandomi2p> 0) hi
            
-
            14:05 <jrandomi2p> 1) 0.3.4 status
            
-
            14:05 <hypercubus> i guarantee that on PDforge your project will be confirmed virtually immediately ;-)
            
-
            14:05 <jrandomi2p> 2) On deck for 0.3.4.1
            
-
            14:05 <jrandomi2p> 3) New web console / I2PTunnel controller
            
-
            14:05 <jrandomi2p> 4) 0.4 stuff
            
-
            14:05 <jrandomi2p> 5) Other development activities
            
-
            14:05 <jrandomi2p> 6) ???
            
-
            14:05 <jrandomi2p> 0) hi
            
-
            14:05 * jrandomi2p waves
            
-
            14:05 < mihi> lla ih
            
-
            14:05 * oOo goof
            
-
            14:06 <mihi> hi all
            
-
            14:06 <jrandomi2p> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-August/000388.html
            
-
            14:06 <jrandomi2p> jumping right in to 1) 0.3.4 status
            
-
            14:07 <jrandomi2p> the net seems generally functional, both for irc and eepsites
            
-
            14:07 <jrandomi2p> what kind of eepsite reliability / failures are y'all seeing?
            
-
            14:07 * jrandomi2p can see the irc failures here, as i see when people disconnect / etc
            
-
            14:08 <mule2p> in general good, got out-of-memory after approx 25MBytes
            
-
            14:08 <mule2p> but that should be fixed in cvs, as you mentioned
            
-
            14:08 <jrandomi2p> ah ok thats on a single 25MB download right?
            
-
            14:09 <mule2p> yes
            
-
            14:09 <jrandomi2p> right
            
-
            14:10 <jrandomi2p> large file transfers do still seem to have problems (disconnect over time, not  corruption though).  i think that may be fixed with the mod mentioned, but i'm not sure
            
-
            14:11 * jrandomi2p forgot to mention that oOo's roundtrip/connections_reliability.php includes both irc servers here, not just i2p, so doesnt really have the right data atm
            
-
            14:11 <jrandomi2p> oOo - any thoughts on what it'd take to get the bogobot code to ignore @irc.metropipe.net?
            
-
            14:12 < duck> kicking hypercubus
            
-
            14:12 < duck> and me to upgrade
            
-
            14:12 <oOo> Very few coding, a peer review by hypercubus and the update of bogobot by duke
            
-
            14:13 <jrandomi2p> ok cool
            
-
            14:13 <hypercubus> duke?
            
-
            14:13 <oOo> duck, sorry :p
            
-
            14:13 * jrandomi2p thinks that sort of statistical summary would be very helpful
            
-
            14:13 <jrandomi2p> duke duck
            
-
            14:14 <oOo> The stats are made on PHP, could be given to duck, too
            
-
            14:14 <jrandomi2p> ok, anyone have anything to bring up wrt 0.3.4?
            
-
            14:14 <jrandomi2p> w3rd
            
-
            14:15 <jrandomi2p> ok, moving on to 2) 0.3.4.1
            
-
            14:15 <jrandomi2p> i dont know what else to mention beyond whats mentioned in the mail
            
-
            14:16 <jrandomi2p> the StreamSinkServer and StreamSinkClient apps are compact demo apps for ministreaming (for any java devs who want to write streaming over i2p)
            
-
            14:16 <jrandomi2p> oh, and StreamSinkServer is kind of like aum's dropbox python app (it takes any data anyone sends it and writes it to a file)
            
-
            14:17 <jrandomi2p> (StreamSinkClient sends a fixed size of random data, so not too useful ;)
            
-
            14:17 <jrandomi2p> any thoughts / concerns / questions wrt 0.3.4.1?
            
-
            14:18 * jrandomi2p estimates it'll be out in a day or two
            
-
            14:19 <jrandomi2p> ok, moving on at a good clip to 3) New web console / I2PTunnel controller
            
-
            14:20 <jrandomi2p> as mentioned in the mail, we've got the new web console pretty much functional, and a simple web interface to control / edit / create i2ptunnel instances
            
-
            14:21 < protok0l> where can the protok0l get it
            
-
            14:22 < protok0l> and what do i do with jetty
            
-
            14:22 <jrandomi2p> its all in cvs now, but i need to put up some docs on how to set it up
            
-
            14:22 < protok0l> ok
            
-
            14:23 * jrandomi2p wrote up and posted a ~5 step process to the channel a few days ago, but we need a simpler proc (or at least a more clear one)
            
-
            14:23 < protok0l> i heard that CVS sucks
            
-
            14:23 <mule2p> ok, can tell you once i have the docs :)
            
-
            14:23 < protok0l> and there was some better CVS thingy
            
-
            14:23 * oOo logged only the first 2 steps before getting disconnected :p
            
-
            14:24 < protok0l> same thing with Vi
            
-
            14:24 < protok0l> lol
            
-
            14:24 <jrandomi2p> we'll eventually moving to have this new console be the 'standard', but that'll probably wait until we've got everything integrated with hypercubus' new installer
            
-
            14:26 <jrandomi2p> actually
            
-
            14:26 <jrandomi2p> for the brave, here's the ugly steps from before:
            
-
            14:26 <jrandomi2p> 20:19 < jrandom> w3rd hyper - could you pull latest from cvs, 'ant dist', grab build/*jar and toss them into your lib dir, mkdir $instDir/webapps/ ; cp build/routerconsole.war $instDir/webapps/  ; edit your router.config to uncomment the clientApp.3.* lines and update your classpath
            
-
            14:26 <jrandomi2p> 20:19 < jrandom> (in the classpath, set it to: lib/i2p.jar:lib/router.jar:lib/mstreaming.jar:lib/heartbeat.jar:lib/i2ptunnel.jar:lib/netmonitor.jar:lib/sam.jar:lib/timestamper.jar:lib/ant.jar:lib/jasper-compiler.jar:lib/jasper-runtime.jar:\
            
-
            14:26 <jrandomi2p> 20:19 < jrandom> lib/jnet.jar:lib/org.mortbay.jetty.jar:lib/routerconsole.jar:lib/xercesImpl.jar:lib/xml-apis.jar:lib/javax.servlet.jar
            
-
            14:26 < protok0l> ok screw it
            
-
            14:27 <jrandomi2p> in addition to that, there's a new i2ptunnel.war - take that and drop it into $instDir/webapps/ and go to http://localhost:7657/i2ptunnel/
            
-
            14:27 <jrandomi2p> yeah, as i said, its a pain
            
-
            14:27 <jrandomi2p> *but* its functional, and I dont really have either the time or the expertise to make it much better
            
-
            14:27 <oOo> That's all it needs to be done ?
            
-
            14:28 <jrandomi2p> yup
            
-
            14:28 <oOo> Ok, thanks
            
-
            14:28 <jrandomi2p> (you'll get something looking like http://dev.i2p.net/~jrandom/config.png when you go to http://localhost:7657/config.jsp
            
-
            14:29 <jrandomi2p> anyway, thats that
            
-
            14:29 <jrandomi2p> i'd appreciate if/when people can kick it around, and hopefully come up with ways to improve it :)
            
-
            14:30 <jrandomi2p> mihi: any thoughts on the whole web interface idea?
            
-
            14:30 < duck> nice layout
            
-
            14:31 <jrandomi2p> thought you'd like it duck ;)
            
-
            14:31 <mrflibble> nice
            
-
            14:31 * mihi likes the layout as well
            
-
            14:31 <mihi> web interfaces are always great
            
-
            14:32 <jrandomi2p> the one i put together for i2ptunnel.war is pretty bland... functional, but bland
            
-
            14:33 <jrandomi2p> ok, thats that - if/when people wanna chat about it further, we've got irc and the list, etc :)
            
-
            14:33 <mule2p> jrandomi2p: clientApp.3 is netmonitor for me
            
-
            14:34 <jrandomi2p> ah ok mule2p - check the router.config from cvs -
            
-
            14:34 <jrandomi2p> #clientApp.3.main=net.i2p.router.web.RouterConsoleRunner
            
-
            14:34 <jrandomi2p> #clientApp.3.name=webConsole
            
-
            14:34 <jrandomi2p> #clientApp.3.args=7657 127.0.0.1 ./webapps/
            
-
            14:34 <jrandomi2p> obviously change the 3 to 4 and uncomment :)
            
-
            14:35 <jrandomi2p> replace 127.0.0.1 if you want to be able to access it remotely
            
-
            14:35 <jrandomi2p> (and 7657 to use a different port)
            
-
            14:36 <mule2p> ok, thanks, have looked in the checked out i2p tree for a new router.config, but it may be elsewhere in cvs
            
-
            14:36 <jrandomi2p> ah sorry, yeah its i2p/installer/java/src/router.config.template
            
-
            14:37 <mule2p> k
            
-
            14:37 <jrandomi2p> ok, unless there's anything else, swinging on to 4) 0.4 stuff 
            
-
            14:38 <jrandomi2p> hmm, i dont know if there's anything i can add to whats in that paragraph in the mail
            
-
            14:38 <jrandomi2p> basically just a bunch of entries on my todo list :)
            
-
            14:39 <jrandomi2p> anyone have any questions / concerns wrt things posted there?
            
-
            14:40 <oOo> How is the installer doing ? ^^
            
-
            14:40 <jrandomi2p> hypercubus?  que tal?
            
-
            14:40 <hypercubus> patience, danielsan... good things come to those who chafe... uh, wait ;-)
            
-
            14:40 <jrandomi2p> hehe
            
-
            14:41 <jrandomi2p> no rush, just wondering how things are goin'
            
-
            14:41 <jrandomi2p> any problems you're running into, things we can help with, etc?
            
-
            14:41 <mihi> who is danielsan?
            
-
            14:41 <hypercubus> no problems, just the tedium of testing atm
            
-
            14:42 <jrandomi2p> w3rd
            
-
            14:42 <hypercubus> i should have written unit tests first, but oh well ;-)
            
-
            14:42 <jrandomi2p> hehe
            
-
            14:43 <hypercubus> java's supposed platform independence really breaks down in the area of installation tasks
            
-
            14:44  * jrandom senses a bulk disconnect
            
-
            14:45 <oOo> Uh oh
            
-
            14:45 <hypercubus_> hmmm, wonderful... what was the last thing i said?
            
-
            14:45 <oOo> <hypercubus> java's supposed platform independence really breaks down in the area of installation tasks
            
-
            14:46 <hypercubus> ok, who sabotaged the meeting? ;-)
            
-
            14:46  * jrandom blames jebus
            
-
            14:46 <hypercubus> maybe it was duke
            
-
            14:46 <mule> you don't want to tell me my router is that important :)
            
-
            14:46 < jrandom> heh
            
-
            14:47 <mihi> [23:46] * jrandomi2p has quit IRC (Client exited)
            
-
            14:47 <mihi> hehe...
            
-
            14:47 <mule> if so, sorry.
            
-
            14:47 <hypercubus> anyhow, no worries about the installer's progress, i fully expect it to be ready when 0.4 is
            
-
            14:47 < jrandom> duck: how many inbound tunnels do you have listening on irc.duck.i2p? 
            
-
            14:47 <hypercubus> i'm not running into any head-scratchers
            
-
            14:47 < jrandom> cool hypercubus
            
-
            14:47 < hobbs> Reminds me -- is there a commandline-accessible way to spit out a new router.config from router.config.template?
            
-
            14:47 < jrandom> nope
            
-
            14:48 < jrandom> not afaik
            
-
            14:48 < mihi> run the installer and copy it
            
-
            14:48 < jrandom> other than java -jar install.jar 
            
-
            14:48 < jrandom> heh
            
-
            14:48 < mihi> into a new dir i mean
            
-
            14:48 < cervantes> at least not the head scratching you're all thinking of
            
-
            14:48 < jrandom> ooh neat, my router dumped core
            
-
            14:48 < duck> jrandom: remind me how I know the hash of irc.duck.i2p
            
-
            14:48 * hypercubus wonders what cervantes means
            
-
            14:49 < jrandom> cd lib ; java -cp i2p.jar net.i2p.data.TestData display Destination ../irc.privKey
            
-
            14:49 < cervantes> hyper: you'd be more familiar with the term strunking :)
            
-
            14:49 <hypercubus> duck: try increasing to 3 or more inbound tunnels... seems to have helped me some
            
-
            14:50 < duck> *** Building a seperate global context!
            
-
            14:50 < duck> Log file logger.config does not exist
            
-
            14:50 < duck> 23:49:47.387 ERROR [main        ] net.i2p.util.LogManager       : Log file logger.config does not exist
            
-
            14:50 < duck> 23:49:49.589 CRIT  [ 1 shutdown ] net.i2p.util.LogManager       : Shutting down logger
            
-
            14:50 < jrandom> ah hrm
            
-
            14:50 <hypercubus> guess it couldn't handle your log *cough*
            
-
            14:51 < mihi> copy your logger.config everywhere ;)
            
-
            14:51 < mihi> at least everywhere where your pwd could be when you run any i2p app
            
-
            14:51 < duck> no I wont
            
-
            14:51 < jrandom> ok, echo logger.record.net.i2p.data.TestData=INFO >> logger.config
            
-
            14:52 < jrandom> actually, thats why i said (cd lib), but i forgot that i changed the default from DEBUG to ERROR in cvs
            
-
            14:52 < duck> 4 inbounds
            
-
            14:52 < jrandom> 4 current & ready?
            
-
            14:52 < jrandom> or 2 not ready (or recently expired) and 2 ready?
            
-
            14:53 < duck> now it changed to 3 with 1 not ready
            
-
            14:53 < jrandom> 'k so its probably during tunnel expiration / replacement
            
-
            14:54 <jrandomi2p> if you update your router.config to specify 3 inbound tunnels that should help with reliability
            
-
            14:54 <jrandomi2p> (or you can use the new i2ptunnel web interface to do it ;)
            
-
            14:54 <hypercubus> perhaps tunnel expiration for a single client with multiple tunnels should be staggered
            
-
            14:55 <jrandomi2p> they are, generally - new tunnels are allocated & a new leaseSet created 60s before tunnel expiration
            
-
            14:55 <hypercubus> ah
            
-
            14:55 <jrandomi2p> however, during tunnel failure it has to create a new leaseSet on demand which doesnt immediately propogate
            
-
            14:56 <jrandomi2p> (well, it goes out on the netDb, but clients wont get that for up to a few seconds)
            
-
            14:57 <jteitel> !who
            
-
            14:57 < alpaca_> Userlist for #i2p: [hobbs] [Iakin3] [duck] [pwk__] [Sonium] [jar] [alpaca_] [interrupt] [protok0l] [mihi] [aum] [Shaun-Away] [cervantes] [jrandom] [deer] [hirvox] [Bladenight] 
            
-
            14:57 <bogobot> Userlist for #i2p: [shendaras] [duck] [josh] [mule2p] [aum] [mrflibble] [hypercubus] [TrueSeeker] [laggybot] [bogobot] [ion_] [mihi] [ion] [mule] [jteitel] [ant] [oOo_] [jrandomi2p] [dm] [ugha2p] [Ch0Hag] [jnk] [oOo] [soros] [bob] [revival] [DrWoo] [thetower] 
            
-
            14:57 <jrandomi2p> there are some further optimizations that can be done to the tunnel pool, but i'm not sure how useful it'd be atm
            
-
            14:57 <jrandomi2p> ok, jumping back on track - anyone else have anything wrt 4) 0.4. stuff?
            
-
            14:57 <oOo> About 'large scale simulations' for 0.4, any way to prepare thus ? Need 'new' specifics applications/tools ? (transition to point 5 ? ;) )
            
-
            14:58 <jrandomi2p> actually, for the sim it would be great if someone could help mod the heartbeat (or a sam-powered app) to be kind of a scriptable client / server
            
-
            14:59 -!- Bladenight is now known as Nightblade
            
-
            14:59 <jrandomi2p> (e.g. rather than the current "every 30s, send 20KB to peer X", a "for 10 minutes, ask peer X for a 1MB file, and then pause for 60m, then  ask peer Y for 1KB files" etc)
            
-
            15:00 <jrandomi2p> but if someone is interested in helping out with that, please let me know and we can chan
            
-
            15:00 <jrandomi2p> er, chat
            
-
            15:00 <jrandomi2p> taking that lead in, lets jump to 5) stuff y'all are doing :)
            
-
            15:01 <jrandomi2p> not sure how to go about covering this, lets just go down in the (arbitrary) order listed in the mail for updates?
            
-
            15:01 <jrandomi2p> i dont see sunshine here, and aum probably isn't up yet ;)
            
-
            15:02 <jrandomi2p> nightblade - how goes the battle? 
            
-
            15:02 < Nightblade> i have some plans for making the libsam interface like bsd sockets
            
-
            15:02 < Nightblade> but i haven't done any coding on that part yet
            
-
            15:02 < duck> changed to tunnels.numInbound=3
            
-
            15:03 <jrandomi2p> cool duck (hopefully wait until after the meeting to restart your tunnel ;)
            
-
            15:03 < duck> oh, it doesnt detect the changes?
            
-
            15:03 <jrandomi2p> word nightblade - is there a problem w/ the way things are now?
            
-
            15:03 <hypercubus> not until you code it to ;-)
            
-
            15:03 <jrandomi2p> naw duck, the clientApp lines are only read on startup
            
-
            15:04 <jrandomi2p> (clientApp is really outside the control of the router - thats what the i2ptunnel web app is for)
            
-
            15:04 < Nightblade> no there is no problem with it the way it is now.... what i would be doing is in addition to the interface that is already there (developers could choose what they want to use)
            
-
            15:04 <jrandomi2p> wikked
            
-
            15:05 <jrandomi2p> ok, you're the boss.  having variety is good, though variety means more code to maintain / etc, but its a balance
            
-
            15:06 <jrandomi2p> ok, moving on down the list - mule2p - how goes the outproxy stuff?
            
-
            15:07 <mule> nothing done beyond the patch you have
            
-
            15:07 <jrandomi2p> ah ok i thought you were working on a further mod
            
-
            15:07 <mule> need to find some spare time for real load balancing
            
-
            15:07 <jrandomi2p> w3rd
            
-
            15:08 <jrandomi2p> i'll get that patch applied then
            
-
            15:08 <mule> thanks. and include my outproxy in the client app :) seems to be faster
            
-
            15:08 <jrandomi2p> heh, well, of course your proxy will be faster for you, its local :)
            
-
            15:09 <oOo> And no one else use it ^^
            
-
            15:09 <mule> no, it isn't
            
-
            15:09 <jrandomi2p> ooh, its on a different router?  cool
            
-
            15:09 <mule> yep, on a root server at an isp
            
-
            15:10 <jrandomi2p> the i2ptunnel web interface has a field for people to specify the list of outproxies, so it should be easy enough for people to tweak, but we'll get it out in the next rev & release notes
            
-
            15:10 <jrandomi2p> nice
            
-
            15:11 <jrandomi2p> ok, nickster seems to be offline atm
            
-
            15:12 <jrandomi2p> are there any other active client development efforts going on?
            
-
            15:12 <jrandomi2p> (or are any of the paused ones active, etc?)
            
-
            15:13 <jrandomi2p> ok, if someone wants to mention anything else on that front, we've got the list and the channel, as always :)
            
-
            15:13 <jrandomi2p> moving on to 6) ???
            
-
            15:13 <jrandomi2p> anyone else have anything they want to bring up?
            
-
            15:14 < Nightblade> nope
            
-
            15:15 <mihi> duck has anything to bring down ;)
            
-
            15:15 <mihi> s/any/some/
            
-
            15:15 * jrandomi2p pingfloods mihi
            
-
            15:15 <jrandomi2p> ok, on that note
            
-
            15:15 * jrandomi2p winds up
            
-
            15:15 * jrandomi2p *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting102.html b/www.i2p2/pages/meeting102.html
deleted file mode 100644
index 260ccac8..00000000
--- a/www.i2p2/pages/meeting102.html
+++ /dev/null
@@ -1,120 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 102{% endblock %}
-{% block content %}
            I2P dev meeting, August 10 @ 21:00 GMT
            
-
            
-
            14:04 < jrandom> 0) hi
            
-
            14:04 < jrandom> 1) 0.3.4.1 status
            
-
            14:04 < jrandom> 2) Updated docs
            
-
            14:04 < jrandom> 3) 0.4 progress
            
-
            14:04 < jrandom> 4) ???
            
-
            14:04 < jrandom> 0) hi
            
-
            14:04  * jrandom waves
            
-
            14:04 < jrandom> weekly status notes just posted a few seconds ago @ http://dev.i2p.net/pipermail/i2p/2004-August/000404.html
            
-
            14:04 < deer> <mrflibble> ooh
            
-
            14:04  * jrandom will give y'all a sec to pull those up ;)
            
-
            14:05 < jrandom> anyway, while y'all are reading, might as well swing into 1) 0.3.4.1 status
            
-
            14:05 < jrandom> 0.3.4.1 is out, as you've seen
            
-
            14:06 < jrandom> its only been a day or two though, but its generally seemed to be going pretty well, at least, up through a few hours ago
            
-
            14:07 < jrandom> there are a pair of bugs just recently tracked down (and fixed locally, testing ongoing), and those are pretty substantial, so we'll be seeing a new release in a day or two
            
-
            14:07 < jrandom> has anyone had any problems with the new web console?
            
-
            14:07 < jrandom> (or, more specifically, has anyone tried it and had problems?  :)(
            
-
            14:07 < deer> <oOo> Tried it, work well ^^
            
-
            14:07 < jrandom> w3rd
            
-
            14:08 < deer> <oOo> Even without any Java compiler ^^
            
-
            14:08 < jrandom> nice, yeah, it should precompile all the JSPs so people won't need javac
            
-
            14:08 < jrandom> thats one thing that web app devs will need to do, but its really really easy, especially with ant
            
-
            14:09 < jrandom> (template code to do it is in i2p/apps/routerconsole/java/build.xml in the 'precompilejsp' target)
            
-
            14:09 < deer> <identiguy> jrandom, what are your concerns about outproxies?
            
-
            14:09 < jrandom> i've also added in optional basic HTTP authentication to protect the console, so you'll be able to have it listen on 0.0.0.0 and access it remotely
            
-
            14:10 < jrandom> oh, my concerns w/ outproxies are threefold - the cost (technical and social) of maangement, the security (outproxies get cleartext), and the anonymity (when you leave a mixnet, you are much more vulnerable to attack)
            
-
            14:10 < deer> <oOo> The servlet console misses a few stats from :7655 (memory consumption), and may some other stuff (shitlist), but it's great ^^
            
-
            14:11 < deer> <identiguy> Thanks. Just wondering.
            
-
            14:11 < jrandom> "private" outproxies are different though - e.g. an anonymizer.i2p could work great without requiring trust
            
-
            14:11 < jrandom> (but still limiting access to pseudonymously known clients, etc)
            
-
            14:12 < jrandom> ah right oOo, I'm going to add in a new page that mirrors the old one
            
-
            14:12 < jrandom> or would you suggest a new page for more stats?  could you draft up what you'd like it to look like?
            
-
            14:12 < jrandom> (or even code it?  :)
            
-
            14:12 < deer> <oOo> Well, it could have been left as an exrcercice for the reader ;)
            
-
            14:12 < jrandom> lol
            
-
            14:13 < deer> <oOo> I was only thinking of memory consumption (on main page) and a Shitlist tab, that's all _I_ miss
            
-
            14:13 < deer> <oOo> Might need to add shitlist reason to shitlisting, BTW ;)
            
-
            14:13 < jrandom> we could probably toss the detailed shitlist into the peer profile page
            
-
            14:14 < jrandom> we dont actually keep track of that right now, but you're right, we could and it'd be nice
            
-
            14:14 < deer> <oOo> IMHO the peer profile page is too big to be really usefull :*)
            
-
            14:14 < deer> <oOo> And easy to do, every code to .addshitlist() stuff have good comments just the next line ;)
            
-
            14:14 < jrandom> any suggestions on improvement?
            
-
            14:15 < jrandom> heh :)
            
-
            14:15 < jrandom> (the netDb page imho is pretty nasty)
            
-
            14:16 < jrandom> hi fvw 
            
-
            14:16 < fvw> heyas jrandom, everyone.
            
-
            14:16 < jrandom> ok, well, if anyone has any more suggestions for the web side, please let me know
            
-
            14:16 < jrandom> this new web console is really just a first pass at things, and most of my attention has been paid to the configuration side
            
-
            14:17 < jrandom> ok, anyone have anything else to bring up wrt 0.3.4.1?
            
-
            14:17 < jrandom> ok, moving on to 2) Updated docs
            
-
            14:17 < jrandom> [see email for list of updated pages]
            
-
            14:18 < jrandom> we've finally gotten all the details out of the paypal/e-gold accts as well (sorry for the delay!)
            
-
            14:19 < cervantes> w00t
            
-
            14:19 < jrandom> another aspect of the docs not mentioned is what we should ship with the router - on the new web console, we can easily package up any html / jsp files to serve as context sensitive help
            
-
            14:19 < cervantes> sheeeit....did I really donate all that
            
-
            14:20 < jrandom> cervantes definitely gets the cervantes++ this week :)
            
-
            14:20 < cervantes> must have miscounted my foreign currency ;-)
            
-
            14:20 < jrandom> lol
            
-
            14:20  * fvw cheers for cervantes.
            
-
            14:20 < jrandom> mos def
            
-
            14:20 < cervantes> btw I've found an old stash of hungarian dollars....
            
-
            14:21 < jrandom> lol do you keep these under your mattress or something?
            
-
            14:21 < cervantes> or forints ..
            
-
            14:21 < cervantes> I always overestimate my holiday spending ;-)
            
-
            14:21 < jrandom> heh
            
-
            14:22 < fvw> hmm, forints. How odd.
            
-
            14:22  * fvw mumbles "forinti=0..."
            
-
            14:23 < jrandom> (no wonder hungarian notation doesn't use 'i')
            
-
            14:23 < jrandom> </derail>
            
-
            14:23 < fvw> hehe. Yes, getting back on track. New docs. very pretty.
            
-
            14:23 < jrandom> w3rd
            
-
            14:23 < deer> <kling> g`evening 
            
-
            14:24 < jrandom> there is still much to be cleaned up, so hopefully people can take a page or two and give it a once over, sending in your results / updates
            
-
            14:24 < jrandom> hi kling
            
-
            14:24 < jrandom> ok, anything else wrt docs?
            
-
            14:24 < fvw> pweh
            
-
            14:25 < jrandom> if not, moving on to 3) 0.4 progress
            
-
            14:25 < fvw> perhaps not totally on topic, but the download page needs some work too.
            
-
            14:25 < jrandom> ah
            
-
            14:25 < jrandom> yeah
            
-
            14:25 < deer> <oOo> Missings Bounties deatails ? ;)
            
-
            14:25 < jrandom> that particular page i'm not /too/ worried about, since it'll all be changing with the new installer, so we'll have to rewrite it anyway
            
-
            14:25 < fvw> I'll kick it a bit and ask the necessary questions on the mailinglist.
            
-
            14:25 < jrandom> r0x0r fvw
            
-
            14:25 < fvw> oh, ok. Then I won't,.
            
-
            14:26 < deer> <kling> router still up nothing special to report Uptime 32h
            
-
            14:26 < jrandom> yeah, we'll still have some of that info, but most will change
            
-
            14:26 < jrandom> nice kling - are you on 0.3.4.1 or 0.3.4?
            
-
            14:26 < deer> <kling> .1
            
-
            14:26 < jrandom> oOo: unfortunately, we lost most of the details pages
            
-
            14:27 < jrandom> but you're right, we need some filler there
            
-
            14:27 < deer> <oOo> Ok, too bad but can live without them ^^
            
-
            14:27 < jrandom> or to remove the links
            
-
            14:27 < jrandom> that also reminds me that aum is now working on a DHT, and it seems Nightblade isn't anymore
            
-
            14:27 < jrandom> (so the distributed data store 'dev' should be updated)
            
-
            14:29 < jrandom> ok, anway, the 0.4 stuff is coming along - i smacked around a 100 router sim the other day with a few different bandwidth loads, and it held up pretty well
            
-
            14:29 < jrandom> also fixed a nasty bug in kaffe's jthread scheduler, but there is still some funkiness on fbsd there (but not on linux)
            
-
            14:30 < jrandom> i dont know how things are coming with the installer..
            
-
            14:30 < jrandom> but i do recall hypercubus working on it today, so i'm sure we'll find out more when more is ready to be found out
            
-
            14:31 < deer> <oOo> Hehe
            
-
            14:31 < jrandom> does anyone have any questions / concerns / suggestions wrt the 0.4 rev?
            
-
            14:31 < deer> <oOo> "When ?" J/K ;)
            
-
            14:32 < jrandom> we really don't have much more to add to the code before its ready for 0.4
            
-
            14:32 < jrandom> (but its not like 0.4 is the end game, we've got a truckload more to do after it)
            
-
            14:32 < deer> <oOo> To Infinity and Beyond !
            
-
            14:32 < jrandom> exactly ;)
            
-
            14:33 < jrandom> ok, I guess thats all I've got to bring up, so 4) ???
            
-
            14:33 < jrandom> anyone have anything they want to discuss?
            
-
            14:33 < deer> <oOo> i2pcvs.i2p  revival ?
            
-
            14:34 < jrandom> yeah, i should probably start that up again
            
-
            14:34 < jrandom> probably will once we bundle the new router console as primary, with the i2ptunnel.cfg
            
-
            14:35 < deer> <oOo> Ok, thanks
            
-
            14:36 < jrandom> ok, if there's nothing else...
            
-
            14:36  * jrandom winds up
            
-
            14:36  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting103.html b/www.i2p2/pages/meeting103.html
deleted file mode 100644
index 5bc00e09..00000000
--- a/www.i2p2/pages/meeting103.html
+++ /dev/null
@@ -1,217 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 103{% endblock %}
-{% block content %}
            I2P dev meeting, August 17, 2004
            
-
            
-
            14:05 < jrandom> 0) hi
            
-
            14:05 < jrandom> 1) Network status and 0.3.4.3
            
-
            14:05 < jrandom> 2) Stasher
            
-
            14:06 < jrandom> 3) ???
            
-
            14:06 < jrandom> 0) hi
            
-
            14:06  * jrandom waves to all the i[2i]p & freenode gang
            
-
            14:06  * hypercubus waves
            
-
            14:06 < jrandom> weekly status notes posted a few seconds ago to http://dev.i2p.net/pipermail/i2p/2004-August/000409.html
            
-
            14:06 < deer> <oOo_itwop> It's Show Time !
            
-
            14:07 < deer> <mule> seems i2p irc doesn't love me. or it wants to keep me hot longer by regular interruptions
            
-
            14:07 < jrandom> heh, yeah, that actually leads us in to 1) Network status and 0.3.4.3 :)
            
-
            14:07 < jrandom> the network is pretty shitty right now
            
-
            14:07 < kaji> yep
            
-
            14:08 < jrandom> the problems are showing up largely from incompatabilities with the different releases that people are running, which has been injecting all sorts of neat ways to break things
            
-
            14:09 < jrandom> if you check the links in the email, you can see the flooding and netDb DoS that has gone on, but it has largely subsided
            
-
            14:09 < jrandom> we still do have a half dozen people running old releases (and probably 20-25 people running vanilla 0.3.4.2, with its own problems)
            
-
            14:10 < jrandom> i appreciate your patience as we move forward on this.  i dont want to rush a new release without first being able to effeciently route around bad nodes
            
-
            14:10 < jrandom> in the past we have been able to route around bad nodes that merely perform poorly, but havent had to deal with nodes who do Bad Things
            
-
            14:11 < deer> <oOo_itwop> Guinea pigs bows to jrandom !
            
-
            14:11 < duck> will the next release be backward compatible?
            
-
            14:11 < jrandom> perhaps duck.  if we can work around those old nodes, there's no reason to make it incompatible
            
-
            14:12 < duck> cool
            
-
            14:12 < jrandom> anyway, there's lots of activity going on, even though y'all aren't seeing any new releases yet
            
-
            14:13 < jrandom> i dont know when 0.3.4.3 will be out.  perhaps tomorrow, or perhaps later this week.
            
-
            14:14 < jrandom> anyone have any questions / comments / concerns they'd like to bring up wrt network status?
            
-
            14:14 < kaji> will *.3 have hyper's new gui install?
            
-
            14:14 < jrandom> probably not
            
-
            14:14 < deer> <mule> the network looks good to me in the profiles of my boxes, just that i frequently drop
            
-
            14:15 < jrandom> yeah, i understand mule.  the irc con has been pretty bad for me too, but its been getting better lately
            
-
            14:15 < deer> <mule> but i missed most of your discussion, so i'll shut up for now
            
-
            14:15 < jrandom> if you want to try pulling from CVS, that should have an improvement, but there are frequent updates so you may want to wait until the release
            
-
            14:16 < jrandom> ok anything else?  if not, moving briskly along to 2) Stasher
            
-
            14:16 < kaji> woot stasher
            
-
            14:17 < jrandom> stasher is looking pretty cool.  still quite limited functionality, but its making progress
            
-
            14:17 < jrandom> if aum were awake he could give us an update...
            
-
            14:17 < jrandom> aum: ping?  :)
            
-
            14:17 < kaji>  /kick aum
            
-
            14:18 < jrandom> (its early for him though, so he is probably still sleeping)
            
-
            14:18 < duck> how selfish
            
-
            14:18 < hypercubus> i'm impressed by it so far
            
-
            14:18 < jrandom> Anyway, installing and running stasher is pretty painless, so if you can help him test it out, that'd be great
            
-
            14:18 < jrandom> yeah, mos' def'
            
-
            14:18 < hypercubus> it has allowed me to pull off mass goatse'ing
            
-
            14:19 < jrandom> and whats an app without a goatse, 'eh?  
            
-
            14:19 < hypercubus> you gotta love an app that lets you upload goatse to someone's drive ;-)
            
-
            14:19 < aum> pong
            
-
            14:19 < jrandom> w0ah 
            
-
            14:19 < jrandom> 'mornin aum
            
-
            14:19 < deer> <ardvark> quick question: do I get stasher via i2p CVS?
            
-
            14:19 < aum> hi all
            
-
            14:19 < jrandom> ardvark: in i2p/apps/stasher/
            
-
            14:19 < aum> ardvark: hi!!!! :) long time!
            
-
            14:20 < deer> <ardvark> yes hi aum! good to see you mate!
            
-
            14:20 < aum> ardvark: prolly easier via tarball - http://stasher.i2p or http://www.freenet.org.nz/python/stasher
            
-
            14:21 < deer> <ardvark> ok aum, I got the tarball but needs other stuff it says?  I'll not hold back the meeting, maybe I can contact you?
            
-
            14:21 < aum> sure thing
            
-
            14:22 < hypercubus> so, any update on stasher aum? ;-)
            
-
            14:23 < aum> small update, i've added a '-l' option which allows local-only get/put
            
-
            14:23 < aum> also, thinking of implementing a 'put' option which returns immediately 
            
-
            14:24 < aum> last night, was thinking thru issues of implementing freenet keytypes
            
-
            14:24 < hypercubus> i'd like to request that successful put operations return a status... scp and many other command line net apps do this
            
-
            14:24 < jrandom> SSK would quite kick ass
            
-
            14:25 < jrandom> (while CHK is of course what imho is most essential)
            
-
            14:25 < MikeW> One thing I always found interesting about freenet was: It would tell you why there could be high CPU usage. Sometimes (usually at startup for a minute or two) and randomly, CPU usage spikes to 100%, perhaps a estimation why it thinks java is eating my cpu?
            
-
            14:25 < deer> <oOo> Splitfiles ^^
            
-
            14:26 < jrandom> MikeW: if i2p is eating your CPU there is most certainly something broken going on
            
-
            14:26 < aum> i've tentatively implemented splitfiles already, but haven't enabled it - want to test locally first
            
-
            14:26 < jrandom> MikeW: you can tell exactly whats going on in your router by looking at the 'current job' in the router console, which is (almost always) where the CPU crunch is
            
-
            14:26 < jrandom> ah cool aum
            
-
            14:27 < aum> due to a recursive algo, the splitfiles thing should allow unlimited file sizes when it's done
            
-
            14:27 < deer> <oOo> Great, splitfiles are mandatory for serious goatse and pr0n stuff...
            
-
            14:27 < deer> <identiguy> aum: does that include FEC?
            
-
            14:27 < aum> fec not needed
            
-
            14:27 < aum> fec is only required on flaky networks
            
-
            14:27 < deer> <identiguy> Ah, I see.
            
-
            14:27 < aum> i'm using kademlia, which has far better retrievability guarantee
            
-
            14:27 < duck> unless nodes go down
            
-
            14:28 < aum> plus, i can't be fscked doing fec anyway, it's a pain
            
-
            14:28 < aum> duck: there's redundancy - refer the 'k' value in kademlia
            
-
            14:28 < jrandom> duck: with a k of 20, even without any republishing it'd be ok ;)
            
-
            14:28 < duck> heh, okay
            
-
            14:28 < deer> <mule> aum: fec might help in case a number of nodes are removed
            
-
            14:28 < jrandom> (and with republishing, it'd only hurt if all k died at the same time)
            
-
            14:28 < aum> naah, i'll just increase k
            
-
            14:28 < jrandom> k of 20 imho is pretty substantial
            
-
            14:29 < jrandom> (since that means you have 20 full replicas of the file)
            
-
            14:29 < hypercubus> users can always use standalone fec tools
            
-
            14:29 < MikeW> jrandom: Under JobQueue, runners:1, active jobs:0, just finished:1, ready/waiting: 0, timed: 28
            
-
            14:29 < aum> that means 20 goatses, guys :P
            
-
            14:29 < hypercubus> and publish the results
            
-
            14:29 < duck> what about the britneyspears effect?
            
-
            14:29 < duck> of very popular keys ending up on 1 node
            
-
            14:29 < jrandom> (aka insert a 740MB file and you get 14.8GB of data you need to send)
            
-
            14:30 < aum> duck: popularity is not a concept in kademlia
            
-
            14:30 < duck> (ofcourse with 32KB keys that might not be terrible)
            
-
            14:30 < jrandom> ok cool MikeW, but is i2p eating your CPU now?
            
-
            14:30 < deer> <ardvark> all these kademlia messages I see on i2p are stasher related?
            
-
            14:30 < MikeW> jrandom: yes
            
-
            14:30 < aum> duck: and kademlia has no relaying
            
-
            14:30 < hypercubus> ardvark: the stuff in the router console is the netdb kad implementation
            
-
            14:31 < aum> the ideas of 'relaying', 'popularity', 'caching' etc are for freenet, which has to expose itself naked to the world, without the cloaking of I2P
            
-
            14:31 < deer> <ardvark> runnin i2p and tor here and my cpu usage is at 3% now so :/  *shrug*
            
-
            14:31 < jrandom> MikeW: then your router is unable to maintain connections and is gobbling CPU doing lots of concurrent connection establishment
            
-
            14:31 < duck> ok, my brain is rotten by freenet
            
-
            14:31 < duck> please have mercy :)
            
-
            14:31 < deer> * shendaras comforts.
            
-
            14:31 < jrandom> MikeW: if you can hang around after the meeting to debug, that'd be great
            
-
            14:32 < MikeW> will do
            
-
            14:32 < jrandom> ok cool aum, anything people can do to help?
            
-
            14:32 < jrandom> or should we just kick the tires and file bugs?
            
-
            14:33 < duck> I am trying to get used to leo
            
-
            14:33 < aum> yep, file bugs to the list, if that's ok people
            
-
            14:33 < duck> already like it more than eclipse
            
-
            14:33 < hypercubus> what's leo?
            
-
            14:33 < jrandom> (uh oh, here comes the rant ;)
            
-
            14:33 < aum> duck: i use nothing but leo these days - except emacs for quick hacks, and zile for even quicker hacks
            
-
            14:34 < hypercubus> as long as you're not using vi or emacs ;-)
            
-
            14:34 < aum> http://leo.sf.net - gives you an outline view of your code
            
-
            14:34 < hypercubus> but i'll have to try this leo myself
            
-
            14:34 < aum> leo even integrates with emacs if you want
            
-
            14:34 < hypercubus> it's not an editor?
            
-
            14:35 < aum> <bile>
            
-
            14:35 < aum> fucking msvc - it allows __int64 for 64-bit ints, but doesn't allow 'LL' or 'ULL' for 64-bit int literals
            
-
            14:35 < aum> !!
            
-
            14:35 < aum> </bile>
            
-
            14:35 < hypercubus> ah i see
            
-
            14:37 < jrandom> ok, if thats that, then we've got nothing left and can move to 3) ???
            
-
            14:37 < jrandom> anyone have anything else they want to bring up?
            
-
            14:37 < hypercubus> yeah i guess i'll say a bit about the new direction of the installer
            
-
            14:37 < jrandom> ok word
            
-
            14:38 < hypercubus> from 0.4 onward, command line users will merely grab the i2p tarball and unpack it, then run a script to start the router and pop open the router console in lynx or whatever
            
-
            14:39 < hypercubus> so not much has changed, except you don't have to go through a silly Q/A session with an installer
            
-
            14:39 < hypercubus> you do all the configuration in the router console
            
-
            14:39 < hypercubus> for GUI users, we have something spiffy
            
-
            14:39 < jrandom> (w00t)
            
-
            14:40 < hypercubus> which you can preview at http://files.hypercubus.i2p/install.jar
            
-
            14:40 < jrandom> or from cvs (ant pkg ; java -jar install.jar) right?
            
-
            14:40 < aum> hypercubus: how are you going with the winstaller? does it autodetect/autodownload/autoinstall java ?
            
-
            14:41 < hypercubus> menu shortcuts are forthcoming, as well as systray integration and a way to install the router as a daemon
            
-
            14:41 < aum> daemon? as in windows 'service' ?
            
-
            14:41 < hypercubus> no, at least not for the forseeable future, they will need to click on a link on the i2p site that takes them to the official java download page
            
-
            14:42 < hypercubus> the installer requires java, but that's ok since i2p does as well
            
-
            14:42 < aum> hypercubus: sorry, but that'll lose 80% of users
            
-
            14:42 < hypercubus> name one java project that doesn't do that
            
-
            14:42 < jrandom> we'll have it eventually.
            
-
            14:42 < jrandom> just not now.
            
-
            14:42 < aum> freenet did it well - their winstaller takes you through the download
            
-
            14:43 < jrandom> (we have so many other more important fish to fry.  we dont *want* thousands upon thousands of users now)
            
-
            14:43 < hypercubus> that's a consideration for 1.0
            
-
            14:43 < hypercubus> i have most of the code to pull it off done already
            
-
            14:43 < aum> jrandom: i thought you said it would be for 0.4
            
-
            14:43 < deer> <mule> so you should require that java is built from source :)
            
-
            14:44 < jrandom> the new installer will be for 0.4
            
-
            14:44 < hypercubus> we have scrapped all the code i have written thus far
            
-
            14:44 < hypercubus> in favor of IzPack
            
-
            14:44 < hypercubus> http://izpack.sf.net
            
-
            14:44 < jrandom> we can offer a 15MB download bundling the two as one, but most users who will use i2p prior to 1.0 will know what "java" is
            
-
            14:45 < hypercubus> this gives me time to perfect a fully public domain java installer framework which i eventually hope to move i2p back to
            
-
            14:45 < hypercubus> but the priority right now is to get rid of the awful current installer ;-)
            
-
            14:46 < hypercubus> (no offense to whoever hacked it together)
            
-
            14:46 < deer> <shendaras> Got a 404....
            
-
            14:46 < duck> http://www.izforge.com/izpack/
            
-
            14:46 < hypercubus> http://www.izforge.com/izpack/
            
-
            14:47 < hypercubus> sorry about that
            
-
            14:47 < hypercubus> anyhow, i would appreciate feedback on the preview installer i've put up on my eepsite
            
-
            14:48 < hypercubus> it's been tested on *nix and windows, it should work on os x and solaris too
            
-
            14:48 < jrandom> r0x0r
            
-
            14:48 < duck> its sweet
            
-
            14:48 < jrandom> yeah, it kicks ass
            
-
            14:49 < hypercubus> i may hack izpack to remove those dorky icons from the buttons
            
-
            14:49 < deer> <mule> hypercubus: will it destroy existing configurations or preserve them?
            
-
            14:49 < hypercubus> there are no config files contained in the package
            
-
            14:49 < hypercubus> so it will only overwrite jars and wars
            
-
            14:49 < jrandom> (at the moment ;)
            
-
            14:49 < hypercubus> well, we'll take configs into account
            
-
            14:49 < deer> <mule> k, thanks
            
-
            14:49 < duck> how will one start the whole jetty thang?
            
-
            14:50 < duck> still a sh/bat ?
            
-
            14:50 < jrandom> yes
            
-
            14:50 < jrandom> the router will start w/ a script, and/or a service (calling that script)
            
-
            14:50 < hypercubus> yes, and i'll throw in an exe for win users
            
-
            14:50 < jrandom> w00t
            
-
            14:50 < hypercubus> that will launch from the Start menu
            
-
            14:50 < hypercubus> the Windows Start menu
            
-
            14:51 < hypercubus> should have jetty working as a windows service by tomorrow
            
-
            14:51  * jrandom mumbles *its not jetty, its i2p*
            
-
            14:51 < hypercubus> ah right ;-)
            
-
            14:52 < hypercubus> jetty comes with a win32 service wrapper though
            
-
            14:52 < hypercubus> we can use it to wrap anything
            
-
            14:52 < jrandom> yeah, there are 3-4 PD/BSD java service wrappers out there
            
-
            14:52 < hypercubus> yeah, there are probably some for linux too
            
-
            14:53 < jrandom> well, linux service == init script :)
            
-
            14:53 < hypercubus> yeah but linux services are handled differently among even the major distros
            
-
            14:53 < hypercubus> for example, gentoo uses the rc-setup script scheme
            
-
            14:54 < jrandom> w3rd
            
-
            14:54 < hypercubus> anyhow, i'll get it working for all the major distros and *bsd's
            
-
            14:54 < hypercubus> if not more
            
-
            14:55 < hypercubus> oops, s/rc-setup/rc-update/
            
-
            14:55 < hypercubus> ok, that covers everything i guess
            
-
            14:55 < hypercubus> you guys can wake up now ;-)
            
-
            14:55 < deer> * shendaras yawns
            
-
            14:55 < jrandom> cool, thanks hyper, sounds good.
            
-
            14:56 < jrandom> anyone else have anything they want to bring up?
            
-
            14:56 < aum> sorry if i missed earlier discussion, but..
            
-
            14:56 < aum> what's the weather like vis a vis datagram latency etc?
            
-
            14:57 < jrandom> i dont know about datagrams - the only apps i use run on top of datagrams via streams
            
-
            14:57 < jrandom> network status is still pretty bad - see status notes @ http://dev.i2p.net/pipermail/i2p/2004-August/000409.html
            
-
            14:58 < aum> k
            
-
            14:58 < jrandom> ok, if there's nothing else...
            
-
            14:58  * jrandom winds up
            
-
            14:59  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting104.html b/www.i2p2/pages/meeting104.html
deleted file mode 100644
index a8de2da6..00000000
--- a/www.i2p2/pages/meeting104.html
+++ /dev/null
@@ -1,422 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 104{% endblock %}
-{% block content %}
            I2P dev meeting, August 24, 2004
            
-
            
-
            14:01 < jrandom> 0) hi
            
-
            14:01 < jrandom> 1) 0.3.4.3 status
            
-
            14:01 < jrandom> 1.1) timestamper
            
-
            14:02 < jrandom> 1.2) new router console authentication
            
-
            14:02 < jrandom> 2) 0.4 status
            
-
            14:02 < jrandom> 2.1) service & systray integration
            
-
            14:02 < jrandom> 2.2) jbigi & jcpuid
            
-
            14:02 < jrandom> 2.3) i2paddresshelper
            
-
            14:02 < jrandom> 3) AMOC vs. restricted routes
            
-
            14:02 < jrandom> 4) stasher
            
-
            14:02 < jrandom> 5) pages of note
            
-
            14:02 < jrandom> 6) ???
            
-
            14:02 < jrandom> 0) hi
            
-
            14:02  * jrandom waves
            
-
            14:02 < deer> <ugha2p> Hi.
            
-
            14:02 < jrandom> weekly notes posted (waaay early) at http://dev.i2p.net/pipermail/i2p/2004-August/000419.html
            
-
            14:03 < jrandom> so i expect you've all done your homework and have read them diligently
            
-
            14:03 < jrandom> (or something)
            
-
            14:03 < jrandom> ok, 1) 0.3.4.3 status
            
-
            14:04 < kaji> (late hi)
            
-
            14:04 < jrandom> there are a few things adjusted since the 0.3.4.3 release came out last friday, but overall the rev seems pretty stable, from what i can tell
            
-
            14:04 < deer> <luckypunk> huh. whats going on?
            
-
            14:04 < deer> <luckypunk> Oh.  Nm.  sorry, i usually sleep thorugh the meeting though.  Hi :)
            
-
            14:05 < jrandom> what are people's experiences with 0.3.4.3 with regards to eepsites / squid / etc?
            
-
            14:05 < luckypunk> very quick.
            
-
            14:05 < jrandom> (i can tell what people are seeing with irc)
            
-
            14:05 < luckypunk> Under 3 seconds page loading sometimes.
            
-
            14:06 < deer> <oOo> Jrandom do kick squid's router too often ;)
            
-
            14:06 < jrandom> cool lucky
            
-
            14:06 < deer> <mule> working well
            
-
            14:06 < luckypunk> i can open up 10 pages of things through the squid and I2P keeps up, pretty slowly though, on my 350 mhz.
            
-
            14:06 < deer> <hypercubus> snappiest it's ever been
            
-
            14:06 < jrandom> yeah, i do oOo, but thats why we have www1.squid.i2p :)
            
-
            14:06 < jrandom> r0x0r
            
-
            14:06 < jrandom> i've heard a few reports of excessive CPU usage - is that hitting people often?
            
-
            14:07 < deer> <hypercubus> not i... i suspect it's just the people with 386s *cough*lucky*cough*
            
-
            14:07 < deer> <oOo> Some very rare peaks here. Related to another erro, I might trace it back one day :p
            
-
            14:07 < deer> <mule> not here
            
-
            14:07 < luckypunk> I think, if its affecting all platforms and stuff, i would feel it hard, and no not really.  Only when its serving the new config pages or downloading a lot of stuff does I2P pin my processor.
            
-
            14:08 < jrandom> ok cool.  there are a few scenarios where i2p will be a bitch wrt CPU, but hopefully those are few and far between
            
-
            14:08 < jrandom> actually, that leads us in to 1.1) timestamper :)
            
-
            14:09 < jrandom> (one of the problems can occur when the timestamper gets goofy / loses track of the correct time)
            
-
            14:10 < jrandom> the whole timestamping stuff has been revamped and integrated into the router, thanks to Adam Buckley being kickass and releasing his work under the BSD license
            
-
            14:10 < jrandom> (yay Adam)
            
-
            14:11 < jrandom> we had previously used the SNTP code as a standalone client app, but we are not doing that anymore - instead we have a tight integration with the router
            
-
            14:11 < jrandom> (so people may need to update their config files as mentioned in the email)
            
-
            14:11 < jrandom> SNTP alone is only a part of the solution though
            
-
            14:12 < jrandom> long term we need some better (read: NTP) synchronization, as SNTP is prone to flux
            
-
            14:12 < jrandom> (especially in light of high network congestion)
            
-
            14:12 < jrandom> Adam sent me some code he has for dealing with it, but i dont really have the time to work through that side of things atm
            
-
            14:13 < deer> <oOo> Using SNTP only ?
            
-
            14:13 < jrandom> i dont recall - i think it may be ntp-esque via sntp queries
            
-
            14:13 < deer> <oOo> Ok, thanks
            
-
            14:14 < luckypunk> uh
            
-
            14:14 < luckypunk> i have a suggestion about that..
            
-
            14:14 < jrandom> anyway, if anyone ever feels bored and wants to do some crazy ntp hacking, that'd Rule
            
-
            14:14 < luckypunk> Maybe it's wrong though.
            
-
            14:14 < jrandom> mmhmm lucky?
            
-
            14:14 < luckypunk> use ntpdate -q
            
-
            14:14 < luckypunk> get the offset.
            
-
            14:14 < jrandom> ntpdate -q == SNTP
            
-
            14:14 < luckypunk> or something similar.
            
-
            14:14 < deer> <oOo> That is what the current code do, more or less ;)
            
-
            14:14  * cervantes catches up what he's mised
            
-
            14:14 < luckypunk> oh.
            
-
            14:15 < luckypunk> sorry.
            
-
            14:15 < cervantes> missed
            
-
            14:15 < deer> <oOo> But we need variable seconds length & co ;)
            
-
            14:15 < cervantes> cpu usuage on my system is the lowest it's ever been....
            
-
            14:15 < jrandom> nice
            
-
            14:15 < cervantes> but I've got 700 odd java threads now and rising
            
-
            14:15 < jrandom> yeah oOo, and the skew detection / candidate selection
            
-
            14:16 < luckypunk> yes, last time i ran it, about a month ago, it seriously affected my usability of my box, now i don't even notice if I2P is running.
            
-
            14:16 < jrandom> yeah i've been looking into that cervantes
            
-
            14:16 < deer> <oOo> True, even if it's a weak part of the whole stuff ;)
            
-
            14:16 < luckypunk> i have about 200 threads.
            
-
            14:16 < luckypunk> 219, to be precise.
            
-
            14:16 < jrandom> cervantes: i've tracked down the threads to the transport layer (we do some *uuugly* stuff to get timeouts), and we can do some better cleanup later
            
-
            14:16 -!- TheCrypto__ is now known as thecrypto
            
-
            14:18 < jrandom> basically some oddities are occurring with the increased # of peers on the network & the churn.  all workable, but it can be annoying
            
-
            14:18 < jrandom> anyway, thats it for 1.1, now 1.2) new router console authentication :)
            
-
            14:19 < jrandom> (no one probably cares about this, but we have basic http authentication working.  see the email for more info)
            
-
            14:19 < cervantes> cool
            
-
            14:19 < cervantes> despite that though the memory handling rocks... haven't had an oom in ages
            
-
            14:19 < jrandom> ah wikked
            
-
            14:20 < jrandom> actually, that gets us towards 2) 0.4 status
            
-
            14:22 < luckypunk> Yes.  If I2P were a MS product, we'd be ready for 1.0 :)
            
-
            14:22 < jrandom> arggg, damn net connection dropped
            
-
            14:22 < jrandom> (screen++)
            
-
            14:23 < jrandom> ok, anyway, there has been a lot going on, and there are still a few more back end things left to do (some client tunnel pool management, as oOo is seeing, and some peer selection testing, as is in cvs)
            
-
            14:24 < jrandom> there's also been a lot of progress on the installer / service / systray side of things 
            
-
            14:24 < jrandom> hypercubus: want to give us an update?
            
-
            14:24 < deer> <hypercubus> sure
            
-
            14:25 < deer> <hypercubus> the service wrapper installation is nearing completion, perhaps today or tomorrow... the service wrapper takes care of OOMs by automatically restarting the i2p router
            
-
            14:25 < jrandom> (yay)
            
-
            14:25 < deer> <hypercubus> so it covers our butts there somewhat
            
-
            14:26 < deer> <hypercubus> systray integration is complete and works great... it's only for Win32 currently, since the systray4j lib seems to have some bugs in its KDE implementation
            
-
            14:26 < deer> <hypercubus> i'll be tracking the KDE progress and hopefully we'll have that in the near future
            
-
            14:27 < deer> <hypercubus> the installer is almost complete as well, all that remains to be added are post-installation tasks
            
-
            14:27 < deer> <hypercubus> i expect that will be done by the weekend
            
-
            14:27 < deer> <hypercubus> (as it depends on the complete integration of the service wrapper)
            
-
            14:28 < jrandom> r0x0r
            
-
            14:28 < deer> <hypercubus> i'll be making available a pre-0.4 installer package for people to test
            
-
            14:28 < deer> <hypercubus> so i will let you all know when that's ready
            
-
            14:28 < luckypunk> What about GNOME?
            
-
            14:28 < cervantes> increment(hypercubus)
            
-
            14:28 < deer> <hypercubus> the systray4j project hasn't taken on gnome yet
            
-
            14:29 < deer> <hypercubus> we'll be adding additional desktop environments as becomes available with systray4j
            
-
            14:29 < luckypunk> well, no biggie, i'mm gonna switch once/if KDE compiles.
            
-
            14:30 < deer> <hypercubus> the systray icon is only for launching the router console in your browser anyhow
            
-
            14:30 < deer> <hypercubus> so its main use will be by windows users ;-)
            
-
            14:30 < jrandom> yeah, we expect *nix users to know how to bookmark ;)
            
-
            14:30 < deer> <hypercubus> but we will of course cater to the lazy *nix users when we can ;-)
            
-
            14:30 < deer> <oOo> N/C...
            
-
            14:30 < luckypunk> Oh, I have a link in my firefox link hings like, with slashdot and BSD Google.
            
-
            14:31 < deer> <hypercubus> but the icon does also serve as a convenient status indicator
            
-
            14:31 < jrandom> agreed
            
-
            14:31 < deer> <hypercubus> i.e. if the icon is gone, your router is gone too ;-)
            
-
            14:31 < deer> <hypercubus> unless of course you chose to hide the icon from your router console
            
-
            14:32 < deer> <hypercubus> which you can do, and it works great
            
-
            14:32 < deer> <hypercubus> ok, i think that's all, unless there are any questions
            
-
            14:33 < protok0l> whats a good PDA that runs linux well?
            
-
            14:33 < jrandom> word hyper
            
-
            14:33 < jrandom> proto: #i2p-chat (or after the meeting)
            
-
            14:33 < protok0l> oops
            
-
            14:33 < deer> <hypercubus> *snicker*
            
-
            14:33 < jrandom> ok, movin' on to 2.2) jbigi & jcpuid
            
-
            14:34 < jrandom> iakin has put together some kickass JNI/asm code to detect the exact CPU architecture used (on x86 boxen), and he has jbigi rigged up for freenet to auto-select the right .so/.dll based on that
            
-
            14:35 < jrandom> he has also released that work into the public domain, and we've snagged a copy and integrated it back into i2p
            
-
            14:35 < luckypunk> So we won't have to chose which jbigi to download?  Won't that make the install somewhat larger?
            
-
            14:35 < jrandom> correct
            
-
            14:35 < jrandom> yeah, it adds a few hundred KB
            
-
            14:36 < jrandom> but, well, the new install is, um, larger than the old one
            
-
            14:36 < luckypunk> oh, i thought it would be more than a few hundred kb.
            
-
            14:36 < luckypunk> Yea, between the new console...I'm guessing 6 - 10 mb?
            
-
            14:36 < deer> * Myo9 has only got 99 mb left on this drive.
            
-
            14:36 < deer> <Myo9> ;)
            
-
            14:36 < jrandom> (especially since i'm being an ass and insisting on .war support rather than direct servlets, requiring xerces, which weighs in at 800KB)
            
-
            14:36 < jrandom> the new install is looking ~4-6MB
            
-
            14:37 < jrandom> but the good thing is, only ~1MB of that is i2p specific, so updates will be lightweight ;)
            
-
            14:38 < deer> <Myo9> I2P hasn't got much publication has it?
            
-
            14:38 < deer> <Myo9> Compared to freenet and TOR?
            
-
            14:38 < jrandom> correct, we're staying fairly quiet
            
-
            14:38 < protok0l> is download size a real consern? most people have broadband
            
-
            14:38 < protok0l> i'm use it if it were 100megs
            
-
            14:38 < luckypunk> protok0l, most people don't, actually.  Most people that'd use I2P do.  though i think I2P still supports dialup (sort of)
            
-
            14:38 < deer> <mule> for i2p users it shouldn't
            
-
            14:39 < jrandom> in my view, the development effort is best served with gradual adoption after sufficient testing goes on at different crititcal points
            
-
            14:39 < luckypunk> yes.  I2P isn't ready for 500 slashdot users :)
            
-
            14:39 < jrandom> though our recent growth has been good, helping to poke different parts of the system
            
-
            14:40 < jrandom> as we launch the 0.4 rev, we will want to move towards the 100-router mark
            
-
            14:40 < deer> <mule> ok, i'll set up another 50 :)
            
-
            14:40 < jrandom> plus, that'll give more incentive for client app devs to build client apps ;)
            
-
            14:40 < jrandom> lol mule :)
            
-
            14:41 < deer> <ugha2p> Arr.
            
-
            14:41 < cervantes> at the rate of adoption we could probably reach 100 in about a month
            
-
            14:41 < cervantes> without evangelising
            
-
            14:41 < jrandom> that would be a good rate of growth
            
-
            14:42 < jrandom> but anyway, back to the agenda :)
            
-
            14:42 < protok0l> i cant wait to evangelize
            
-
            14:42 < jrandom> jbigi + jcpuid == integrated (and see the mailing list if you want to run CVS HEAD) :)
            
-
            14:42 < jrandom> heh we can tell proto ;)
            
-
            14:42 < deer> <hypercubus> lucky: more than half of US internet users have broadband... report was released the other day
            
-
            14:43 < jrandom> and less than 1/10th of the world is in the us ;)
            
-
            14:43 < deer> <oOo> Who mind about the USA ? ^^
            
-
            14:43 < jrandom> but moving on to 2.3) i2paddresshelper
            
-
            14:44 < jrandom> oOo has put together yet another patch, this one letting people hit eepsites with linked pages without editing hosts.txt
            
-
            14:45 < jrandom> the details are listed in the weekly status notes
            
-
            14:45 < jrandom> oOo - is there anything you want to add?
            
-
            14:45 < deer> <oOo> Hum... Let's the eepsites number grow fast and Cervantes add his promised support :p
            
-
            14:46 < jrandom> ah, cervantes has already added the "Try it [i2p]" link :)
            
-
            14:46 < jrandom> (only people on CVS HEAD can use it, until 0.4 is out)
            
-
            14:46 < cervantes> :o)
            
-
            14:46 < jrandom> ((works great, btw))
            
-
            14:46 < deer> <oOo> Great ^^  Will play with it as soon as I manage to get my router back online ;)
            
-
            14:47 < kaji> you could password the client download and roll it gmail style
            
-
            14:47 < jrandom> hmm?
            
-
            14:48 < kaji> small base + invitation only
            
-
            14:48 < kaji> but that would take work
            
-
            14:48 < jrandom> oh, for 0.4 release?  
            
-
            14:48 < kaji> oh, for the 1.0
            
-
            14:48 < jrandom> no, not worth the effort atm.  if we get flooded with new users we may want to look at using certificates, etc
            
-
            14:48 < deer> <oOo> 1.0 is for mass audience :p
            
-
            14:49 < jrandom> well, for 1.0 we're going to be up past the 1000 user mark already
            
-
            14:49 < jrandom> (at least, thats my hope ;)
            
-
            14:49  * kaji thinks it would be fun to watch i2p go from 50 to 5000 node in 3 hours
            
-
            14:49 < jrandom> heh
            
-
            14:49 < deer> <oOo> And then down to 100 ;)
            
-
            14:49 < luckypunk> hypercubus, whoo hoo for americans!  they're catching up ;)
            
-
            14:49 < jrandom> heh, thats one way to test churn ;)
            
-
            14:50 < cervantes> if aum gets stasher working...and hyper increases his goatse library then you'll see it jump 50 to 5000 is less than 3 hours ;-)
            
-
            14:50 < kaji> and then 50100 as the nsa brings their node onlin
            
-
            14:50 < jrandom> actually that kind of brings us forward to 3) AMOC vs. restricted routes
            
-
            14:51 < jrandom> one of the interesting aspects of restricted routes is the ability to mount a 'sybil' attack really, really, really easily.
            
-
            14:51 < jrandom> while mule was just mentioning a few minutes ago installing 50 new nodes, it'd be possible to bring online a significant number 
            
-
            14:52 < jrandom> one of the ways to address this is through a certificate authority, limiting the introduction of new routerIdentity certificates
            
-
            14:52 < jrandom> another is through hashcash
            
-
            14:52 < jrandom> another is through morphmix/tarzan style ip prefix detection
            
-
            14:53 < jrandom> but, yet another is to say "fuck it" and hope we get sufficient 'good' peers to outnumber the 'bad' ones
            
-
            14:53 < fvw> I think that's ok for the time being yes.
            
-
            14:54 < protok0l> heres an idea
            
-
            14:54 < jrandom> yeah, its the simplest thing to do, and adding artificial barriers to join a p2p network at this stage seems... foolish
            
-
            14:54 < fvw> I think perhaps a mix of hashcash and ip-based would be nice to have for 1.0, but all in all you can't defend against a powerful enough adversary.
            
-
            14:54 < protok0l> cut off the inital noderef access
            
-
            14:54 < protok0l> if someone wants on, we can give them your noderefs
            
-
            14:54 < protok0l> *uor
            
-
            14:54 < fvw> and how would that help?
            
-
            14:55 < jrandom> right fvw, and we might be able to put it off until after 1.0, as well
            
-
            14:55 < fvw> depends on your definition of 1.0 :)
            
-
            14:55 < jrandom> proto: i'm not sure that'd help much
            
-
            14:55 < jrandom> heh fvw, we're not like freenet ;)
            
-
            14:56 < jrandom> 1.0 == functional, secure, [sufficiently] anonymous, and scalable
            
-
            14:56 < deer> <oOo> and well documented ;)
            
-
            14:56 < jrandom> documentation is a prerequisite to secure :)
            
-
            14:56 < deer> <Myo9> Are all users added to the noderef at the moment?
            
-
            14:57 < jrandom> Myo9: yes - http://dev.i2p.net/i2pdb/ is just a link into one of my router's netDb/ dir
            
-
            14:57 < jrandom> (so it will list everyone my router has a reference for, at any time)
            
-
            14:58 < jrandom> ((and everyone has a ref for people they talk to, which, at our current scale, is everyone))
            
-
            14:58 < jrandom> ok, but back to 3) AMOC vs. restricted routes
            
-
            14:59 < deer> <Myo9> Ok.
            
-
            14:59 < jrandom> as mentioned in the email, mule's ideas might be able to get us to drop the 0.4.2 AMOC transport and instead implement basic restricted route support, treating people behind NATs/firewalls as simply being behind a restricted route
            
-
            15:00 < fvw> it would be kind of cool
            
-
            15:00 < jrandom> yeah, and save us from writing yet another transport protocol
            
-
            15:01 < deer> <ugha2p> But how would make performing sybil attack that much easier?
            
-
            15:01 < jrandom> s/writing/designing,implementing,reviewing,debugging,deploying,debugging,debugging,debugging,debugging.../
            
-
            15:01 < deer> <ugha2p> how would it make*
            
-
            15:02 < jrandom> ugha2p: there is no way to tell how many *real* routers are behind a restricted route - all we know about them is that they have a unique router identity and are reachable through a certain router
            
-
            15:02 < deer> <ugha2p> Ah.
            
-
            15:03 < jrandom> that certain router could in fact be one sim instance, running 100 other routers in the same JVM, each pretending to be behind firwalls
            
-
            15:03 < deer> <ugha2p> Right.
            
-
            15:03 < deer> <oOo> They could as easily been using 100 ports on the same host...
            
-
            15:03 < fvw> however assuming you're willing to spend a few 100 euros on your attack, you can get a large number of spread out IPs anyway.
            
-
            15:03 < jrandom> agreed fvw
            
-
            15:04 < jrandom> oOo: true, though ports cost memory (and some CPU)
            
-
            15:04 < deer> <ugha2p> I don't think that presumption is going to stop more powerful enemies though.
            
-
            15:04 < jrandom> (which is why when i do larger sims, i need to switch from the TCP comm system to the VM comm system)
            
-
            15:04 < jrandom> agreed ugha2p
            
-
            15:04 < jrandom> it just makes it easier
            
-
            15:05 < fvw> I think we're going to have to assume that anybody with more than a bored-sunday-afternoon desire to attack the system is going to be able to get at least 10^3 nodes on the network easy.
            
-
            15:05 < deer> <oOo> Not *that* much
            
-
            15:05 < jrandom> right fvw
            
-
            15:05 < deer> <oOo> (+ easier)
            
-
            15:05 < fvw> and at that order of magnitude, nothing apart from central certification is going to stop them.
            
-
            15:06 < deer> <ugha2p> 100 open ports on one single host would be trivial to detect, but 100 restricted routes behind a machine might not be.
            
-
            15:06 < jrandom> well, thats open to debate fvw, but yeah, sybil is a bitch
            
-
            15:06 < deer> <oOo> 100 zombies are tricky to detect ;)
            
-
            15:06 < fvw> which means we ideally need a 10^4 network.
            
-
            15:06 < jrandom> definitely oOo
            
-
            15:06 < fvw> (loose estimates)
            
-
            15:07 < deer> <ugha2p> We'll ideally have a 10^4+ network.
            
-
            15:07 < jrandom> fvw: i'd go higher than that - imho we need to grow this into the millions
            
-
            15:07 < deer> <oOo> Ideally would be more then half available IPs ;)
            
-
            15:07 < jrandom> heh oOo
            
-
            15:07 < fvw> It'd be nice if we could yeah.
            
-
            15:08 < jrandom> (but, of course, to grow it into hte millions we need sufficient reason to do so.  i think we will be able to make the case for that eventually though)
            
-
            15:08 < deer> <ugha2p> I'm not sure if Kademlia could be held in one piece for that long. ;)
            
-
            15:08 < fvw> at which point beating people up would definately become the low-cost attack. Which, unintuitively enough, would be a good thing.
            
-
            15:08 < jrandom> heh
            
-
            15:08 < deer> <DrWoo> jrandom: millions would need serious useability and benefit
            
-
            15:09 < jrandom> agreed DrWoo
            
-
            15:09 < fvw> luckily, a lot of (non-nice) people are working very hard on that now.
            
-
            15:09 < deer> <oOo> Pr0n for masses :p
            
-
            15:10 < deer> <jrandom> which is why imho we need a kickass filesharing app
            
-
            15:10 < deer> <oOo> "One human, One goatse", which lead us to stasher :p
            
-
            15:10 < cervantes> download->install->share musi
            
-
            15:10 < deer> <DrWoo> jrandom: it would have to be order of an anonymous kazza, luckily the motivation is being taken care of by the RIAA & co.
            
-
            15:10 < fvw> pr0n is already easy to get (see usenet and such). I think big record company assocs and such are going to crack down a lot harder on p2p than pornographers ever could.
            
-
            15:10 < cervantes> music
            
-
            15:10 < fvw> but once again we drift offtopic.
            
-
            15:11 < fvw> "4) stasher"?
            
-
            15:11 < deer> <oOo> Yeah ! 4) !
            
-
            15:11 < jrandom> agreed - we can all think up some reasons to justify use, but first we need to get it *working* :)
            
-
            15:11 < cervantes> ah for once a non-tenuous link into the next item
            
-
            15:11 < jrandom> movin' to 4) stasher
            
-
            15:12 < jrandom> aum: you awake yet?
            
-
            15:12  * hypercubus chants auuuuuummmmmmmmm
            
-
            15:12 < jrandom> well, in case he isn't, i know he's been doing a lot of work on adding CHK and SVK support to stasher
            
-
            15:13 < jrandom> which is Cool
            
-
            15:13 < deer> <oOo> And splitfiles
            
-
            15:13 < jrandom> yeah, the splitfile support is interesting
            
-
            15:13 < fvw> in the 'interesting times' sense? 
            
-
            15:14 < jrandom> thats one of the differences between freenet and stasher, in that stasher already has a fixed 31KB max size per key
            
-
            15:14 < deer> <oOo> "Useful, great, don't need anything from user application"
            
-
            15:14 < jrandom> (since afaik stasher uses SAM datagrams)
            
-
            15:14 < luckypunk> can't you impliment lik..split files?
            
-
            15:15 < jrandom> ooohhh!  i just realized what bug he was running into wrt reliability!  
            
-
            15:15 < jrandom> (fixed the other day in cvs, significantly killing the bug)
            
-
            15:15 < jrandom> yeah lucky
            
-
            15:15 < jrandom> but the splitfile implementation is inherently different from how freenet splitfiles work, due to max keysize limitations
            
-
            15:15 < deer> <oOo> So Stasher over-I2P just be healthy again ? ^^
            
-
            15:16 < jrandom> (if you read freenet devl or tech lately, you'll hear toad and hobx talking it over)
            
-
            15:16 < deer> <oOo> *should
            
-
            15:16 < jrandom> oOo: with HEAD, yeah
            
-
            15:16  * jrandom hasnt heard any reports of people even trying it since 0.3.4.3 came out (or was it 0.3.4.2)
            
-
            15:16 < jrandom> but anyway, he is planning on another new test build by end of the week
            
-
            15:17 < jrandom> anyone have anything to mention / discuss wrt stasher?
            
-
            15:17 < jrandom> (other than yay!  go aum!)
            
-
            15:18 < deer> <oOo> Yeah, there is an urge to find non-goatse contents there ;)
            
-
            15:18 < jrandom> heh
            
-
            15:18 < deer> <oOo> ex-Freeneter, start your engines ;)
            
-
            15:18 < jrandom> yeah splitfile support should definitely help with that, as would ssk & fcp support
            
-
            15:19 < fvw> I'd like to second the 'go aum!' if I may.
            
-
            15:19 < deer> <oOo> yay !
            
-
            15:19 < jrandom> motion is seconded, and thirded :)
            
-
            15:19 < jrandom> ok, swingin' forward to 5) pages of note
            
-
            15:20 < jrandom> i just wanted to point out three new pages
            
-
            15:20 < jrandom> DrWoo's safe browsing guide gives a pretty good rundown on the dangers of eepsites & the outproxies
            
-
            15:20 < jrandom> the problems can be addressed in code, but we just havent had time to do it yet, so its Good to be informed
            
-
            15:21 < jrandom> lucky has also put together a good doc on the freebsd+java side of things as well
            
-
            15:21  * jrandom hasnt tried too many jvms on fbsd, just kaffe, so nag him if you have questions :)
            
-
            15:22 < jrandom> hyper has also put together the doc for upgrading to the 0.4 dev code, which he'll likely be updating once we want more people to test it ;)
            
-
            15:22 < hypercubus> my post on the forum covers installation of the service wrapper... the howto for the new router console is here --> http://files.hypercubus.i2p/New_I2P_Router_Console_Howto.txt
            
-
            15:23 < jrandom> wr0d
            
-
            15:23 < jrandom> oh, there's also a new pretty picture & some new text @ http://www.i2p.net/how_intro (hopefully making things a bit more clear)
            
-
            15:24 < fvw> ooh, that looks pretty. Who did that? Good work.
            
-
            15:25 < hypercubus> it was actually copied directly from a crop circle
            
-
            15:25  * fvw tries not to mention the resemblence between jrandom and Dave but fails miserably.
            
-
            15:25 < jrandom> heh
            
-
            15:25 < fvw> ah, that explains jrandom's feelers.
            
-
            15:25 < jrandom> the pic was beautified by our anonymous designer
            
-
            15:25 < jrandom> (thankfully so, my ms paint skills suck :)
            
-
            15:26 < hypercubus> we're still trying to decipher the significane of Charlie's long chin
            
-
            15:26 < deer> <ugha2p> Arr, this sucks.
            
-
            15:26 < jrandom> how about alice's skewed eyes?  ;)
            
-
            15:26 < hypercubus> heh
            
-
            15:26 < deer> <jrandom> yeah, it'll be nice when we get irc.duck.i2p upgraded (if it hasnt been already..)
            
-
            15:27 < fvw> never mind that, she looks like she's doing a double alien-bursting-from-stomach-scene with her cheeks.
            
-
            15:27 < jrandom> lol
            
-
            15:27 < jrandom> *thats* why she is talking to dave
            
-
            15:27 < jrandom> well, anyway, i think this leads us to 6) ???
            
-
            15:27 < fvw> haha
            
-
            15:27 < jrandom> anyone have anything they want to bring up?
            
-
            15:28 < deer> <oOo> Can't you build the skeleton of certificates' stuff in I2P and let *others* fill it and have fun ? (Or his this already done ? :p)
            
-
            15:28 < deer> <oOo> Or is this absolutely useless ?
            
-
            15:28 < deer> <oOo> (for now)
            
-
            15:28 < jrandom> hmm?  
            
-
            15:28 < jrandom> the hashcash / etc certificate stuff?
            
-
            15:28 < deer> <oOo> Ok, nevermind ^^
            
-
            15:28 < deer> <oOo> Yes
            
-
            15:29 < jrandom> ok yes, we already have the infrastructure for that
            
-
            15:29 < jrandom> (though things like libSAM will need to be modified to interpret the destination properly, since iirc nightblade assumed 384bytes always ;)
            
-
            15:30 < jrandom> but the router will handle different types of certificates transparently
            
-
            15:30 < deer> <oOo> The code is ready for this ? Just missing some 'content' ?
            
-
            15:31 < jrandom> yes - the RouterIdentity created currently always attaches a NullCertificate (certificate type == 0)
            
-
            15:31 < jrandom> if it attaches another type, another type of certificate is attached 
            
-
            15:31 < jrandom> e.g. hashcash cert, CA signed cert, etc
            
-
            15:31 < jrandom> verification infrastructure is there as well (RouterInfo.verify)
            
-
            15:32 < deer> <oOo> Oh, great :)
            
-
            15:32 < deer> <oOo> So someone may play with this code and adding hashcash and stuff in advance ?
            
-
            15:32 < jrandom> if we had a flash flood i could probably lock down the net in a day or two
            
-
            15:32 < jrandom> right
            
-
            15:33 < jrandom> (though i think fvw is right in that it wont be pressing for at least a little while)
            
-
            15:33 < deer> <oOo> Ok. I don't volunteer ;)  But someone might :p
            
-
            15:33 < Nightblade> on i2p.net, the aug 24 meeting log link is pointed at the aug 17 log
            
-
            15:33 < jrandom> right, sorry, meeting isn't over yet :)
            
-
            15:33 < Nightblade> oh haha
            
-
            15:34 < jrandom> so, anyone have anything else they want to bring up?  :)
            
-
            15:34 < hypercubus> new rule... whoever edits the website: no smokin' the funny stuff while editing!
            
-
            15:34 < jrandom> uh oh...
            
-
            15:34 < jrandom> what'd i do?
            
-
            15:34 < hypercubus> i was referring to broken links ;-)
            
-
            15:34 < jrandom> oh
            
-
            15:35 < hypercubus> we need a full time web editor... i nominate lucky
            
-
            15:35 < jrandom> well, yeah, i updated the link to this weeks weekly status notes before the meeting, in case anyone went to the page ;)
            
-
            15:35 < jrandom> we certainly do need someone to keep track of the web site and poke people when things are funky
            
-
            15:36 < luckypunk> me?  web enditor?
            
-
            15:36 < luckypunk> enditor haha
            
-
            15:36 < luckypunk> i dunno
            
-
            15:36 < Nightblade> spelchek reqwired
            
-
            15:36 < luckypunk> i'll probably be pretyt busy once school start.s
            
-
            15:36 < jrandom> bah, drop out!  work on i2p fulltime!
            
-
            15:36 < luckypunk> if i drop out
            
-
            15:37 < luckypunk> my parents will make me get a job
            
-
            15:37 < deer> <hypercubus> excuses excuses ;-)
            
-
            15:37 < luckypunk> and i'm still busy
            
-
            15:37 < deer> <hypercubus> amen
            
-
            15:37 < deer> * oOo will happily renovate the English used on the website ;)
            
-
            15:37 < luckypunk> anyway, i don't think i'm gonna be allowed to drop out
            
-
            15:38 < luckypunk> they're raising the legal dropout age to 18
            
-
            15:38 < luckypunk> or high school diploma
            
-
            15:38 < luckypunk> whatever comes first.  (usually the latter)
            
-
            15:38 < hypercubus> er
            
-
            15:38 < Nightblade> haha "legal dropout age" - what will they come up with next?
            
-
            15:38 < luckypunk> it's 16 now.
            
-
            15:38 < luckypunk> You can't leave school before that, else they'll arrest you.
            
-
            15:38 < jrandom> actually, thats a good point.. as we move towards 1.0 it'd be good to offer different translations of various pages
            
-
            15:39  * luckypunk can make a vague translation intro french, if absolutely required.
            
-
            15:39 < Nightblade> I'll do the Klingon and Ebonics translations
            
-
            15:39 < deer> <oOo> Yeah, Klingon translation of the website :p
            
-
            15:39 < hypercubus> yes, we can offer English, B0rk, and oOo-fried English
            
-
            15:39 < deer> <oOo> Damned, same idea ><
            
-
            15:39 < Nightblade> ooo, a mindreader
            
-
            15:39 < luckypunk> (with the theory that babelfish aided with a human is better than no translation at all.)
            
-
            15:39 < jrandom> i think we might be able to scam jar into updating his French translation lucky, but thanks ;)
            
-
            15:39 < deer> <oOo> hyper: will gladly for free like in beer :p
            
-
            15:40 < jrandom> thats actually one of the big things post 0.4 - getting the docs solid
            
-
            15:40 < luckypunk> hey, my french is completely intelligible to a french speaker
            
-
            15:40 < luckypunk> Though i probabxly sound equivilent to godmode0
            
-
            15:40 < hypercubus> the installer already has native language packs btw
            
-
            15:40 < jrandom> (perhaps a whitepaper or two on various aspects)
            
-
            15:40 < jrandom> w3rd hyper
            
-
            15:40 < deer> * oOo suspect we can master quite some language with the people online here ;)
            
-
            15:40 < jrandom> (yeah, it'll be tough to translate the paragraph license ;)
            
-
            15:40 < hypercubus> i could just make it throw up the panel to choose a language
            
-
            15:40 < jrandom> agreed oOo
            
-
            15:40 < hypercubus> heheh... libre: 
            
-
            15:40 < jrandom> gratis:
            
-
            15:41 < luckypunk> gratis and libre
            
-
            15:41 < luckypunk> damn french and their ability to have two words.
            
-
            15:41 < jrandom> ok, anything else?
            
-
            15:41 < hypercubus> we have 10 words for everything
            
-
            15:41 < luckypunk> though libre also means free beer in quebec french.  =(
            
-
            15:41 < luckypunk> so much for that theory.
            
-
            15:42 < jrandom> ok... if there's nothing else...
            
-
            15:42  * jrandom winds up
            
-
            15:42  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting105.html b/www.i2p2/pages/meeting105.html
deleted file mode 100644
index 84a2fc26..00000000
--- a/www.i2p2/pages/meeting105.html
+++ /dev/null
@@ -1,225 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 105{% endblock %}
-{% block content %}
            I2P dev meeting, August 31, 2004
            
-
            
-
            14:04 < jrandom> 0) hi
            
-
            14:04 < jrandom> 1) 0.3.4.3
            
-
            14:04 < jrandom> 2) 0.3.5 and 0.4
            
-
            14:04 < jrandom> 3) docs
            
-
            14:04 < jrandom> 4) stasher update
            
-
            14:04 < jrandom> 5) ???
            
-
            14:04 < jrandom> 0) hi
            
-
            14:04  * jrandom waves
            
-
            14:05 < deer> * Pseudonym waves
            
-
            14:05  * hypercubus flaps
            
-
            14:05 < deer> * detonate waves
            
-
            14:05 < jrandom> weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-August/000425.html
            
-
            14:05 < jrandom> moving on to 1) 0.3.4.3
            
-
            14:06 < jrandom> as it says in the notes, and as you all know from firsthand experience, the net isn't too healthy atm
            
-
            14:06 < jrandom> lots of messages are lost, and people are often seeing warnings about their leases having expired a while back
            
-
            14:07 < jrandom> this is unfortunate, and largely addressed in CVS, which will be rolled out when we can (see item 2)
            
-
            14:07 < kaji> (late) hi
            
-
            14:08 < jrandom> anyway, i think thats all i've got to mention on 0.3.4.3, beyond whats in the email.  i appreciate your patience as we move forward through the rough patches
            
-
            14:08 < jrandom> swinging on up to 2) 0.3.5 and 0.4 (unless someone has anything else they'd like to add..?)
            
-
            14:09 < deer> <oOo> So 90% of broken nodes can knock down the network ^^
            
-
            14:09 < deer> * Pseudonym eagerly awaits the release of 0.3.5
            
-
            14:09 < kaji> who was running the dos? they did a good job
            
-
            14:10 < jrandom> well, I can reach squid consistently from my other CVS HEAD boxes
            
-
            14:10 < jrandom> so the network isn't 'knocked out' for people on cvs head :)
            
-
            14:10  * lucky is having partial success with .3.4.3 still.
            
-
            14:10 < jrandom> but yeah, the old peer selection algorithm did some Stupid Things
            
-
            14:10 < deer> <oOo> I'm on CVS head and lost suid.i2p a lot of time ;)
            
-
            14:11 < jrandom> hmm
            
-
            14:11 < jrandom> what are you seeing for a tunnel failure rate? 
            
-
            14:12 < jrandom> (total # events at /routerStats.html#tunnel.failAfterTime compared with total # events at #tunnel.buildFrequency )
            
-
            14:13 < deer> <oOo> lifetime average value: 288 268,91 over 339,00 events
            
-
            14:13 < jrandom> and tunnel.buildFrequency?
            
-
            14:14 < deer> <oOo> But you might have been restarting your router too much while repairing thread leaks ;)
            
-
            14:14 < jrandom> what is your lifetime # of tunnel.buildFrequency?
            
-
            14:14 < deer> <oOo> 24h frequency: avg per period: (2,76, max 2,76, current is 100,00% of max) strict average per period: 5 645,58 events (averaged using the lifetime of 5 729,00 events)
            
-
            14:14 < deer> <oOo> 24h ~= router lifetime
            
-
            14:15 < jrandom> so ~5% tunnel failure
            
-
            14:15 < jrandom> thats about what i've been seeing on CVS HEAD, as opposed to the 40-60% tunnel failure of 0.3.4.3
            
-
            14:16 < deer> <oOo> Let's swing on up to 2) then ;)
            
-
            14:16 < jrandom> consider it swung
            
-
            14:16 < jrandom> ok, as mentioned in the email, the next rev will be 0.3.5, not 0.4
            
-
            14:16 < jrandom> it'll have all the goodies y'all have been waiting for, but it won't have the "0.4 stamp of approval" ;)
            
-
            14:17 < deer> <Pseudonym> 0.4.rc-1
            
-
            14:17 < jrandom> well, i considered going down the rc road, but I dont want to be overconfident
            
-
            14:17 < kaji> 0.4.rc-0.9
            
-
            14:17 < deer> <Pseudonym> heh
            
-
            14:18 < kaji> beta
            
-
            14:18 < jrandom> while 0.3.5 is out, I'm going to see if we can mount the DoS again, as well as a variety of new issues that we should be able to come up with
            
-
            14:18 < lucky> we have to keep DoSing it till it works while being DoSed
            
-
            14:18 < jrandom> right
            
-
            14:19 < kaji> dos it till it cant be dosed no more
            
-
            14:19 < deer> <Pseudonym> but no new features between 0.3.5 and 0.4 right?
            
-
            14:19 < jrandom> perhaps someone can be inspired to help out with implementing some churn and fail cases in the simulator, so we can test this stuff more easily and automatically... ;)
            
-
            14:20 < jrandom> correct Pseudonym, I do not expect any significant new features to come during 0.3.5
            
-
            14:20 < jrandom> at least, from an app user perspective
            
-
            14:20 < jrandom> perhaps some developer will take this time to improve upon the eepproxy, a transparent webserver, help out aum, etc 
            
-
            14:21  * jrandom pokes at someone hacking on an irc proxy w/ DCC support ;)
            
-
            14:21 < deer> <duck> a public inproxy for i2p/tor is in the make
            
-
            14:21 < jrandom> ah nice, html specific, or bitpipe?
            
-
            14:21 < jrandom> er, web specific, that is
            
-
            14:22 < deer> <duck> web specific
            
-
            14:22 < jrandom> w3rd
            
-
            14:22 < deer> <duck> the idea being that an ISP can put up some gateways to specific sites
            
-
            14:22 < deer> <duck> so the world can access alexandria
            
-
            14:23 < jrandom> ooh, what would *really* rule is if those gateways could act as vhosts
            
-
            14:23 < jrandom> (maybe thats what you're talking about anyway)
            
-
            14:23 < deer> <duck> http://anonygateway.com/home.duck.i2p/~alexandria/
            
-
            14:23 < jrandom> ah ok
            
-
            14:23 < jrandom> still cool
            
-
            14:23 < deer> <duck> http://anonygateway.com/6sxoyfb3h2nvok2d.onion/
            
-
            14:24 < deer> <duck> virtual host is also possible; just for a next iteration
            
-
            14:24 < jrandom> (though 6sxoyfb3h2nvok2d.onion.anonygateway.com would be cooler ;)
            
-
            14:24 < jrandom> right right
            
-
            14:24 < deer> <duck> easy to do with a mod_rewrite ofcourse
            
-
            14:25 < cervantes> or just set up a subdomain :)
            
-
            14:25 < kaji> hah vhost a bittorent seed
            
-
            14:25 < deer> <duck> I am paying dev out of my pocket; patch will be pub domain
            
-
            14:25 < jrandom> duck++
            
-
            14:26 < deer> <duck> also talking with an ISP who might want to offer it as a paid service
            
-
            14:26 < jrandom> nice
            
-
            14:26 < deer> <duck> ofcourse it is better when anarchistgang.org does so
            
-
            14:26 < deer> <duck> but you know the stability of those types
            
-
            14:26 < jrandom> *cough*
            
-
            14:27 < cervantes> their quackers
            
-
            14:27 < cervantes> *they're
            
-
            14:27 < deer> <jon2> hi!!!!!!
            
-
            14:27  * hypercubus snickers
            
-
            14:27 < jrandom> hi jon2
            
-
            14:27 < deer> <jon2> I like meeting >:-D
            
-
            14:28 < jrandom> i think after the net is settled down a bit more (once 0.3.5 is out there), we'll want to reevaluate some app level activities
            
-
            14:28 < deer> <duck> *cough* myi2p?
            
-
            14:28 < jrandom> heh
            
-
            14:29 < kaji> what about access behind a firewall?
            
-
            14:29 < deer> <jon2> yes, firewall access :)
            
-
            14:29 < jrandom> we need something rock solid, usable, *and* secure, that provides functionality that people want (and hopefully, that we can use to encourage community)
            
-
            14:30 < deer> * duck points at 0.4.2 @ http://www.i2p.net/roadmap
            
-
            14:30 < jrandom> believe me, i want access behind firewalls / uncontrollable NATs / etc just as much as the rest of you.
            
-
            14:30 < deer> <jon2> I can do the secure part, I know cryptophagy.
            
-
            14:30 < jrandom> (someone has to add that as a quote ;)
            
-
            14:30  * hypercubus wonders what a cryptophage is
            
-
            14:31 < jrandom> jon2 - we definitely need help on this stuff and would love to snag some of your time!
            
-
            14:31  * kaji just started back to school, he would like to take i2p with him ;)
            
-
            14:31 < aum> morning all
            
-
            14:31 < cervantes> btw I'm wondering if any devs miss their little i2p blogs.... if perhaps they should get devoted forum sections, at least in the short term...
            
-
            14:31 < cervantes> *if so
            
-
            14:31 < deer> <jon2> cryptophagy, science of security.
            
-
            14:31 < jrandom> 'mornin aum
            
-
            14:32 < hypercubus> jon2: do you also know cryptography?
            
-
            14:32 < deer> <jon2> Good morning aum.
            
-
            14:32 < jrandom> cervantes: i'm holding off until i can get a blog of my own, which hopefully wont be too far off
            
-
            14:32 < deer> <jon2> no :-(
            
-
            14:33 < cervantes> jrandom: and everyone else?
            
-
            14:33 < jrandom> nightblade has been using his blog @ cashdollar.org
            
-
            14:33 < deer> <jon2> I have a blog on blogs.aspnet.com
            
-
            14:33 < jrandom> though i suppose it'd be cool to have people posting on the forum
            
-
            14:34 < cervantes> ah good...well it seems most have found alternatives....but it's a same they've become fragmented
            
-
            14:34 < jrandom> yeah
            
-
            14:34 < cervantes> *shame
            
-
            14:34 < cervantes> darn fingerzzz
            
-
            14:34 < lucky> well, a phage is part oft he immune system.
            
-
            14:34 < jrandom> i liked having the devblogs on the site.  we'll get something back eventually
            
-
            14:34 < hypercubus> jon2: funny, blogs.aspnet.com is an unclaimed domain
            
-
            14:34 < jrandom> ok, anyway, anything else for 2) 0.3.5 and 0.4 ?
            
-
            14:35 < hypercubus> yeah
            
-
            14:35 < hypercubus> i've got the firefox problem solved now, in cvs
            
-
            14:35 < jrandom> w000t
            
-
            14:36 < deer> <jon2> I am asp developer.
            
-
            14:36 < hypercubus> reads the default from the registry
            
-
            14:36 < cervantes> :)
            
-
            14:36 < deer> <jon2> sorry.. I mean blogs.asp.net
            
-
            14:36 < hypercubus> no you don't
            
-
            14:36 < deer> <jon2> weblogs.asp.net
            
-
            14:36 < jrandom> ah, great hypercubus.  so we're almost there for the 0.3.5 release
            
-
            14:37 < cervantes> shudder....asp
            
-
            14:37 < hypercubus> yes i can feel it getting close
            
-
            14:37 < jrandom> ok, moving on to 3) docs
            
-
            14:37 < jrandom> well, I dont have anything to add beyond my request in the email
            
-
            14:38 < jrandom> (send in your questions!  post 'em to the list, send 'em in email, post 'em on the forum)
            
-
            14:38 < deer> <oOo> Yeah, anonymously use the forum and make Cervantes happy ;)
            
-
            14:39  * cervantes gets all tingly
            
-
            14:39  * hypercubus adjusts the rabbit ears
            
-
            14:40 < nicktastic> haha
            
-
            14:40 < deer> <jon2> I liked this meeting..
            
-
            14:40 < cervantes> you said that...
            
-
            14:40 < cervantes> <deer> <jon2> I like meeting >:-D
            
-
            14:40 < hypercubus> great, you get to buy the donuts next time ;-)
            
-
            14:40 < jrandom> ok, if there's nothing else, 4) stasher update
            
-
            14:41 < jrandom> aum seems to have awoken early... you still 'round?
            
-
            14:41 < deer> <jon2> GREAT MEETING!
            
-
            14:41  * hypercubus wonders if dm has children
            
-
            14:41 < jrandom> heh, yeah, he's back ;)
            
-
            14:41 < cervantes> I'd think it's an impossibility
            
-
            14:42 < hypercubus> guess aum missed that first cuppa
            
-
            14:42 < jrandom> ok, maybe he'll swing back to the term
            
-
            14:42 < jrandom> anyway, his general update was posted in the email
            
-
            14:42 < jrandom> looks like there's lots of progress going on
            
-
            14:43 < jrandom> some questions remain, but ever onward 
            
-
            14:43 < deer> <oOo> But no release date given ;)
            
-
            14:43 < hypercubus> how many people are testing it atm?
            
-
            14:43 < jrandom> i dont know if the code he has now w/ the things mentioned is public yet
            
-
            14:43 < hypercubus> ah
            
-
            14:44 < deer> <jon2> BAF BAF BAF BAF BAF
            
-
            14:44 < kaji> whats new about stasher?
            
-
            14:44 < jrandom> kaji: see the http://dev.i2p.net/pipermail/i2p/2004-August/000425.html
            
-
            14:45 < deer> <oOo> It now use less water to wash the dishes
            
-
            14:45 < hypercubus> i've been waiting for that feature
            
-
            14:45  * jrandom too
            
-
            14:45 < jrandom> ok
            
-
            14:45 < jrandom> if aum is still afk, swinging on to 5) ???
            
-
            14:45 < jrandom> does anyone else have something they want to bring up?
            
-
            14:45  * cervantes puts on a tin hat
            
-
            14:46 < lucky> How's jetta for serving web pages coming along?
            
-
            14:46 < jrandom> i dont know of anyone working on an app to safely allow people to host pages with jetty
            
-
            14:46 < jrandom> (host pages that can be served as an eepsite, that is)
            
-
            14:47 < jrandom> jetty does allow people to deploy client applications (though i dont know anyone working on a web based app yet either)
            
-
            14:47 < hypercubus> i'd like to say something about systray4j vs. SWT
            
-
            14:47 < jrandom> mmhmm?
            
-
            14:47 < hypercubus> the cost of ditching systray4j for SWT: we'd be dropping systray4j.jar and systray4j.dll, shedding 147 KB from our distribution size -- and replacing that with swt.jar (885 KB) + native libs (332 KB on Win, 639 KB on *nix), a net difference of 1.2-1.5 MB, but with that we gain systray icons on KDE, Gnome, and OS X as well as Win32, and also launch icons for plain X environments a la NextStep/GNUstep
            
-
            14:48 < hypercubus> and this will give us the ability to add other GUI components later, independent of the JRE the user has (otherwise, accomodating Kaffe users would limit us to using AWT only)
            
-
            14:48 < hypercubus> just food for thought... maybe down the road
            
-
            14:48 < jrandom> worth discussing, down the road, as users demand it
            
-
            14:49 < jrandom> if the value is there, the value is there
            
-
            14:49 < deer> <oOo> Web interface is intend to be the GUI, isn't it ?
            
-
            14:49 < hypercubus> cervantes had a cool idea to make further use of SWT
            
-
            14:49 < hypercubus> an I2P dashboard ;-)
            
-
            14:49 < jrandom> yes oOo
            
-
            14:49 < hypercubus> oh, and skins! j/k
            
-
            14:49 < jrandom> i'd really much rather have that sort of functionality built into the router console, if you mean what i think you mean
            
-
            14:50 < hypercubus> point is...
            
-
            14:50 < cervantes> it might also encourage application development if i2p comes with a nice set of SWT libraries
            
-
            14:50 < hypercubus> it seems development on systray4j is winding down or otherwise mired
            
-
            14:50 < deer> <oOo> As long as systray and GUI stuff aren't mandatory to have a fully working router...
            
-
            14:50 < jrandom> right oOo
            
-
            14:50 < hypercubus> i don't see them fixing the KDE version anytime soon
            
-
            14:51 < hypercubus> correct, we could just add a hook in the router's systray class
            
-
            14:51 < hypercubus> and the user could optionally download the systray/SWT stuff
            
-
            14:51 < jrandom> hypercubus: personally, i'm not entirely 100% sure the user base will even need a systray.  i think we need to deploy it and get feedback to know the value
            
-
            14:51 < jrandom> cervantes: client application developers can absolutely bundle SWT with their app
            
-
            14:51 < jrandom> (or say "get SWT")
            
-
            14:51 < hypercubus> i suspect we'll get requests for expanded systray options
            
-
            14:52 < jrandom> and if a client app dev gets something we want to bundle with the router, we'll deploy swt with the bundle
            
-
            14:52 < jrandom> (etc)
            
-
            14:52 < deer> <oOo> Too late to split the console/status monitor/whatever from the really-routing-stuff ?
            
-
            14:52 < jrandom> really routing stuff?
            
-
            14:52 < jrandom> the router console is a fully seperate client application
            
-
            14:53 < jrandom> (apps/routnerconsole/)
            
-
            14:53 < deer> <oOo> The stuff needed to have the bytes anonymously flowing
            
-
            14:53 < jrandom> i do think down the line we will want to have a minimal-router install as well
            
-
            14:53 < jrandom> (with nothing in clients.config, etc)
            
-
            14:53 < jrandom> but we dont have the developer hours to maintain multiple sets of things
            
-
            14:55 < jrandom> ok, anyone else have anything they want to bring up?
            
-
            14:57 < jrandom> if not
            
-
            14:57  * jrandom winds up
            
-
            14:57 < deer> <oOo> 0.3.5, when ? ;)
            
-
            14:57 < jrandom> it'll be out hopefully this week
            
-
            14:57 < jrandom> (in the next day or two if all goes well)
            
-
            14:57 < deer> <oOo> Ok ^^
            
-
            14:57  * jrandom stops winding up
            
-
            14:57  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting106.html b/www.i2p2/pages/meeting106.html
deleted file mode 100644
index 5983e3b1..00000000
--- a/www.i2p2/pages/meeting106.html
+++ /dev/null
@@ -1,476 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 106{% endblock %}
-{% block content %}
            I2P dev meeting, September 7, 2004
            
-
            
-
            14:09 < jrandom> 0) hi
            
-
            14:09 < jrandom> 1) 0.4
            
-
            14:09 < jrandom> 2) Capacity and overload
            
-
            14:09  * cervantes pulls up a bar stool
            
-
            14:09 < jrandom> 3) Website updates
            
-
            14:09 < jrandom> 4) I2PTunnel web interface
            
-
            14:09 < jrandom> 5) Roadmap and todo
            
-
            14:09 < jrandom> 6) ???
            
-
            14:09 < jrandom> 0) hi
            
-
            14:09 < nicktastic> ugha, Ah, -x isn't even necessary to see what's being resolved - silly me
            
-
            14:09 < cervantes> hullo
            
-
            14:09  * nicktastic resumes lurking
            
-
            14:10 < jrandom> 'lo all, sorry for the delay in the notes - http://dev.i2p.net/pipermail/i2p/2004-September/000437.html
            
-
            14:10  * jrandom just had to reply to Derick's E post :)
            
-
            14:10 < deer> <ugha2p> nicktastic: Right. The meeting already started though. :)
            
-
            14:10 < luckypunk> h wow, i didn't miss it.
            
-
            14:10 < jrandom> !hi5
            
-
            14:10 < jrandom> ok, swinging on in to 1) 0.4
            
-
            14:11 < jrandom> we finally got it out the door, and it doesn't seem to have bitten us too bad
            
-
            14:12 < jrandom> the network is larger than its ever been (I counted 60 TCP connections a few hours back), eepsites are retrievable, and irc is often usable
            
-
            14:12 < dm> hey!! meeting?
            
-
            14:12 < jrandom> hypercubus has done some great work with the new install, systray, and service manager, which I know has helped us out a bunch
            
-
            14:13 < modulus> yay
            
-
            14:13 < hypercubus> still a ways to go though
            
-
            14:13 < hypercubus> but i think we're getting somewhere now
            
-
            14:13 < jrandom> agreed, ever onwards :)
            
-
            14:14 < jrandom> this release also has the widespread deployment of oOo's ?i2paddresshelper 
            
-
            14:14 < jrandom> we covered that a bit the other week [http://dev.i2p.net/pipermail/i2p/2004-August/000419.html item 2.3], but now its probably a good idea for people to consider using it for their links
            
-
            14:15 < hypercubus> does it work with name-based vhosts?
            
-
            14:15 < jrandom> the i2ptunnel httpclient still correctly sends Host: $base64dest
            
-
            14:17 < jrandom> on that note, there has been some more talk about using the bundled webserver to serve some eepsites, and i think if someone has some time to figure out the configuration necessary, that'd be pretty kickass (saving us from the vhost / apache config problems)
            
-
            14:18 < jrandom> ok, anyone else have anything to bring up about 0.4?
            
-
            14:18 < deer> <baffled> is this web server in cvs?
            
-
            14:18 < demonic_1> ?
            
-
            14:18 < hypercubus> the web server is in 0.4
            
-
            14:18 < demonic_1> what i miss
            
-
            14:18 < deer> <ugha2p> baffled: It's going to be.
            
-
            14:18 < hypercubus> hence CVS
            
-
            14:18 < jrandom> baffled: yeah, its all in cvs (lib/org.mortbay.*)
            
-
            14:18 < cervantes> btw I experimented with window's url protocol handers... it's very easy to set the registry up so "i2p://base64" will launch in a browser with a http://site.i2p?i2paddresshelper=base64 ...
            
-
            14:19 < deer> <ugha2p> Oh, it already is.
            
-
            14:19 < dm> this is all very very cool
            
-
            14:19 < hypercubus> i already wrote registry interfacing code
            
-
            14:19 < hypercubus> we can use that to set up an .i2p association
            
-
            14:19 < fvw> cervantes: i2p:// wouldn't be quite right I think. After all, it's http over i2p; just as you could have irc:// over i2p.
            
-
            14:19 < cervantes> you can also specify security and proxy settings on a per protocol basis
            
-
            14:19 < jrandom> cervantes: does firefox/etc honor those?
            
-
            14:19 < cervantes> yup
            
-
            14:20 -!- shardy_ is now known as shardy
            
-
            14:20 < jrandom> woah, hi shardy_ 
            
-
            14:20 < shardy> hey jrandom, long time no talk
            
-
            14:20 < cervantes> although admittedly I need more testing...
            
-
            14:20 < nicktastic> konqueror should, too
            
-
            14:20 < cervantes> I was just playing in a spare moment ;-)
            
-
            14:20 < deer> <ugha2p> Opera doesn't.
            
-
            14:20 < cervantes> although I doubt firefox takes any notice of windows proxy and security settings
            
-
            14:20 < hypercubus> you can set it in opera's ini file
            
-
            14:21 < hypercubus> i did that to opera so ed2k:// would work
            
-
            14:21 < deer> <ugha2p> hypercubus: Ah, cool.
            
-
            14:21 < fvw> only up to a point. You can't turn URL handlers into http:// handlers handled by opera itsself alas.
            
-
            14:21 < hypercubus> though they don't document it very well
            
-
            14:21 < deer> <duck> really, what benefit does i2p:// give?
            
-
            14:22 < fvw> hypercube: You're handing it off to a helper app I suppose? I did much the same, but I couldn't find a way to make opera display a "download started" page.
            
-
            14:22 < hypercubus> yes, it gets handed to eMule
            
-
            14:22 < dm> yes, who wants to pee in public anyway?
            
-
            14:22 < hypercubus> we could hand i2p:// to the eeproxy
            
-
            14:22 < hypercubus> then you web guys can figure out the rest from there ;-)
            
-
            14:22 < Sciatica> is https not http over, uh, "s"?
            
-
            14:23 < jrandom> but, as i think duck is getting at, we'll already be tied in to the eepproxy anyway?
            
-
            14:23 < deer> <ugha2p> Sciatica: It's HTTP over SSL, yes. :)
            
-
            14:23 < jrandom> Sciatica: http over i2p (well, anything over i2p) is secure and authenticated.  what happens after it reaches the other side is outside i2p's scope
            
-
            14:23 < deer> <ugha2p> But that's an established convention.
            
-
            14:24 < Sciatica> yes, I knew that.  I'm just saying that the argument against i2p:// isn't as clear as "isn't it juts http _over_ i2p?"
            
-
            14:24 < dm> htt2p
            
-
            14:24 < hypercubus> i don't know if i2p:// is necessary, but i do believe it's possbile to get the major browsers at least to work with it
            
-
            14:24 < deer> <ugha2p> jrandom: I think he just referred to the 'https://' prefix.
            
-
            14:24 < jrandom> ah, sorry.
            
-
            14:24 < deer> <duck> we need an anonymizing filter plus http://127.0.0.1:7657/www.duck.i2p/ anyway
            
-
            14:25 < deer> <duck> with those you dont need to tweak browser settings
            
-
            14:25 < jrandom> but yeah, I agree with fvw, this sounds like excessive overloading of the url protocol
            
-
            14:25 < demonic_1> not here >> as a lame use i feel i2p:// links would rule << not here
            
-
            14:25 < jrandom> right duck
            
-
            14:25 < jrandom> hehe
            
-
            14:25 < cervantes> perhaps i2p:// could me made to operate as a protocol arbiter:  i2p://irc/base64
            
-
            14:26 < fvw> ungh, that's ugly and abusing URLs in the worst possible way.
            
-
            14:26 < deer> <ugha2p> cervantes: How would that work in IRC's case?
            
-
            14:26 < deer> <duck> URIs :)
            
-
            14:26 < cervantes> that way you can launch different apps based on a single url standard
            
-
            14:26 < fvw> (not that there's anything wrong with that)
            
-
            14:26 < jrandom> wouldn't the more appropriate URL mod be irc://i2p/base64/#i2p ?
            
-
            14:27 < jrandom> but, ok, we're a bit off track..
            
-
            14:27 < jrandom> anything else on 0.4?  :)
            
-
            14:28 < fvw> I don't think that URI's allow for specifying transport mechanism seperately from protocol, which is a shame really.
            
-
            14:28 < dm> you can use the filesystem
            
-
            14:28 < fvw> Yes, sort of: *applause*
            
-
            14:28 < dm> c:\i2p\irc #i2p
            
-
            14:29 < dm> ha! I confused you all
            
-
            14:29 < deer> * mule_iip agrees with fvw
            
-
            14:29 < fvw> dm: I'm going to seriously hurt you. Maybe not today, maybe not tomorrow, but soon and for the rest of your life.
            
-
            14:29 < jrandom> :) thanks, we do our best
            
-
            14:29 < fvw> </pinky and the brain>
            
-
            14:29 < jrandom> heh
            
-
            14:29 < jrandom> ok, jumping on to 2) Capacity and overload
            
-
            14:30 < deer> <DrVince> Hi everyone
            
-
            14:30 < jrandom> i'd rather not just copy out what was posted in the notes, so review whats there :)
            
-
            14:30 < dm> hi
            
-
            14:30 < hypercubus> welcome to our meeting DrVince ;-)
            
-
            14:30 < deer> <ugha2p> Hi, DrVince.
            
-
            14:31 < jrandom> one thing I'd like to mention wrt 2) was something a few people have seen - severe skew in participating tunnels
            
-
            14:31 < jrandom> e.g. someone with DSL had 300+ tunnels the other day
            
-
            14:31 < dm> me
            
-
            14:31 < modulus> yeah
            
-
            14:31 < jrandom> (and when they go down, that breaks a *lot* of tunnels)
            
-
            14:31 < jrandom> the problem is tunnels are really lightweight - 2-20bps on average
            
-
            14:31 < cervantes> and my OC3 has practically nada
            
-
            14:31 < hypercubus> i only have 8 atm
            
-
            14:32 < dm> i had 270+, and I am on 150kbps
            
-
            14:32 < jrandom> overall, the network has ~ 20*n tunnels on average at any given time
            
-
            14:32 < jrandom> (where n = # nodes in the network)
            
-
            14:32 < jrandom> at an average of 2 hops per node, that means every node participates in an average of 40 tunnels
            
-
            14:33 < hypercubus> ideally ;-)
            
-
            14:33 < jrandom> well, thats the thing, balancing like that *isnt* ideal
            
-
            14:33 < jrandom> since not all nodes are as fast or have as much bandwidth
            
-
            14:33 < jrandom> on the ohter hand, balancing the tunnels so they all go through 2 or 3 really fast peers also sucks
            
-
            14:33 < jrandom> since if one of those go down, *boom*
            
-
            14:34 < hypercubus> right, so why is dm's inferior DSL connection so overloaded, while my much faster DSL connection has been under-utilized?
            
-
            14:34 < Sciatica> will this problem go away as the # of nodes in the network grows beyond 100, 200, etc.?
            
-
            14:34 < dm> inferior? :'(
            
-
            14:34 < jrandom> hypercubus: because i2p is currently nonresponsive to the bandwidth available, unless people turn on bandwidth limiting
            
-
            14:34 < hypercubus> dm: technically speaking ;-)
            
-
            14:34 < hypercubus> ok i have bandwidth limiting enabled... dm must not?
            
-
            14:35 < Sciatica> (at some point won't the number of nodes a server can host be greatly dwarfed compared the the number of total nodes [e.g., tunnels]?
            
-
            14:35 < ugha_node> Arrr!
            
-
            14:35 < ugha_node> '(the local message processing time exceeds 1s)' -- I don't think we should program any such constants into the router. I think all such values should be taken from the (I2P network) environment, so it would still work in case the router lands in an unexpected enviromnent.
            
-
            14:35 < dm> yeah, I don't, also my uplink is decent: 256kbps (downlink 150kbps)
            
-
            14:35 < Sciatica> bad terminiology -- I type too slow for such issues :-)
            
-
            14:35 < jrandom> Sciatica: it isn't a problem, is just a reality.  if every node maintains 20 tunnels at any given time, with each tunnel an average of 2 hops, no matter how large the network is, it averages out
            
-
            14:36 < jrandom> ugha_node: agreed - the 1s thing is random #, but how can we derive the "right" value?  what amount of delay is "a lot"?
            
-
            14:37 < jrandom> we do have some code in the RouterThrottleImpl that tracks "how much bandwidth we've agreed to allocate"
            
-
            14:37 < jrandom> but at the moment, it doesn't throttle based on that
            
-
            14:37 < dm> hmmmm I don't like these overload discussions... flashbacks of freenet.
            
-
            14:37 < jrandom> (bandwidth agreed to == # participating tunnels * # messages per tunnel on average * # bytes per message on average)
            
-
            14:37 < dm> Maybe we should use estimators?
            
-
            14:38  * jrandom kicks dm
            
-
            14:38 < hypercubus> dm: are you using bandwidth limiting in your router?
            
-
            14:38 < dm> hypercubus: no
            
-
            14:38 < hypercubus> dm: i highly recommend using it ;-)
            
-
            14:38 < dm> jrandom: three words... NGR
            
-
            14:38 < fvw> It's really up to the node that requested the tunnel, right? What kind of lag are they willing to put up with? Would it be viable to make it one of the tunnel parameters?
            
-
            14:39  * fvw wonders if dm is trying to scare us or if it's merely an added benefit.
            
-
            14:39 < jrandom> hmm, that has potential
            
-
            14:39 < dm> errr.. won't that just move the arbitrary threshold to the requesting router? ;)
            
-
            14:39 < dm> I don't want to choose, you choose!
            
-
            14:40 < jrandom> yes dm, but the requesting router knows what the tunnel will be used for (irc w/ low lag vs bulk w/ high lag and high throughput)
            
-
            14:40 < fvw> yes, but for some things 10s lag is no problem (think file transfers), whereas other stuff (irc) needs low latency.
            
-
            14:40 < dm> yeah, so you have the app layer decide the threshold?
            
-
            14:40 < jrandom> that is, however, dangerous
            
-
            14:40 < fvw> the only problem is using high-latency links will not increase capacity, so in the end file transfers get all the resources.
            
-
            14:41 < cat-a-puss> can you really trust any load claims made by the router, otherwise a malicious preson could try to get another nodes traffic to go through all their routers
            
-
            14:41 < jrandom> cat-a-puss: these are only used to reject requests to participate, not to solicit
            
-
            14:41 < ugha_node> You can't.
            
-
            14:41 < cat-a-puss> ok
            
-
            14:42 < jrandom> a malicious user can of course accept tunnels when they're totally overloaded, but we'll detect that when the tunnel fails
            
-
            14:42 < jrandom> (and the freeloader can reject the tunnel when they arent loaded, but, c'est la vie)
            
-
            14:43 < jrandom> the throttle based on local overload is pretty effective though.  however, that isn't enough
            
-
            14:43 < dm> greedy bastard
            
-
            14:43 < jrandom> i've been trying to find out an ideal way to work out whether to accept it or not, and i think that there is some potential for probabalistically rejecting requests we would otherwise accept, based on how many tunnels we are already in
            
-
            14:44 < jrandom> the concept there is that the peer wants other people to take on some load
            
-
            14:44 < cat-a-puss> should we run as many virtual routers as avalable bandwidth?
            
-
            14:44 < jrandom> (so as to distribute the failure)
            
-
            14:44 < jrandom> hmm cat-a-puss?
            
-
            14:44 < jrandom> are you running the sim on the live net?
            
-
            14:45 < jrandom> in any case, no, a single router should be able to address the local capacity
            
-
            14:46 < deer> <mule_iip> problem is that bandwidth used in a tunnel may change significantly over time, right?
            
-
            14:46 < cervantes> which is not currently happening...at least not for me
            
-
            14:46 < cat-a-puss> well if it's all random how can you take advantage of an oc3 any more than some poor guy on a 56k? You ether have to advertise: problematic, or run virtual routers, ether way I think a malicious party could try to encircle a node for some sort of stistical attack
            
-
            14:46 < jrandom> right mule_i2p.  we need to do some more monitoring of the tunnel activity
            
-
            14:46 < cervantes> 14 participents each have 11.5mbit ... that's a bit of a waste :)
            
-
            14:47 < jrandom> cat-a-puss: probabalistic != random :)  
            
-
            14:47 < jrandom> heh cervantes 
            
-
            14:48 < jrandom> the basic idea behind probabalistically rejecting would be to spread the load out to other peers.  however, if the network really is saturated, the probability won't be a problem as people will just ask again
            
-
            14:48 < jrandom> the issue is that we currently have an overwhelming *excess* of capacity
            
-
            14:48 < Sugadude> Poor i2p, having *too* much capacity. Don't worry, I'm on it. ;)
            
-
            14:49 < fvw> assuming everyone is wellbehaved, you could perhaps not reject from people who come back within a short interval of being probabilisticly rejected?
            
-
            14:49 < deer> <mule_iip> so fill any tunnel with some cover traffic
            
-
            14:49 < jrandom> heh Sugadude :)
            
-
            14:49 < cervantes> that's because everyone's requests are being handled by dm's router ;-)
            
-
            14:49 < jrandom> fvw: we dont know who requests a tunnel
            
-
            14:49 < fvw> hmm, good point. *screws head back on*
            
-
            14:50 < jrandom> fvw: probabalistically, subsequent requests would be accepted - we'd want the 'reject' factor to stay low enough
            
-
            14:50 < deer> <mule_iip> which will increase anonymity and make load calculation easier
            
-
            14:51 < jrandom> true mule_iip, but it'd be nice to actually have the net operate effectively without requiring high load :)
            
-
            14:51 < jrandom> but that is definitely a worthwhile scenario for the sim
            
-
            14:51 < deer> <mule_iip> effectively make i2p use a constant bitrate with cover traffic. but that was for a future release, i guess :)
            
-
            14:52 < jrandom> we *could* use ATM-style allocation
            
-
            14:52 < fvw> Doesn't bandwidth usage vary too much for that to be viable?
            
-
            14:52 < jrandom> e.g. assume 5 messages per minute per tunnel @ 32KB each, and compare that with the bandwidth limits, and reject accordingly
            
-
            14:52 < cervantes> hyper has some ascii we can use to pad the messages out
            
-
            14:52 < hypercubus> hmmmm, i don't like that constant bitrate idea... i2p would be filtered by ISPs very quickly if that were implemented
            
-
            14:53 < jrandom> heh cervantes 
            
-
            14:53 < deer> <kaji> yes
            
-
            14:53  * hypercubus doesn't know what cervantes is talking about
            
-
            14:53  * hypercubus hides his floppy
            
-
            14:53 < jrandom> fvw: padding?  or allocation?
            
-
            14:53 < fvw> allocation
            
-
            14:53 < cervantes> ah ya plausable deniability huh
            
-
            14:54 < jrandom> hmm fvw.  perhaps, but I think we can monitor them statistically and compensate
            
-
            14:54 < deer> <kaji> constant bitrate sounds like Waste
            
-
            14:54 < jrandom> for instance, http://localhost:7657/oldstats.jsp#tunnel.bytesAllocatedAtAccept
            
-
            14:54 < hypercubus> hence its name ;-)
            
-
            14:55 < jrandom> that stat monitors how much bandwidth we have agreed to pass on for other people's tunnels
            
-
            14:55 < jrandom> (using the last 10 minutes as a guideline)
            
-
            14:56 < jrandom> so my peer with 85 tunnels says it will transfer 3,676,945.65 bytes over the next 10 minutes for all of those tunnels, combined
            
-
            14:56 < deer> <mule_iip> kaji: it is waste, and we probably should use it only for the more severe threat models. but would be nice for low latency like irc.
            
-
            14:56 < jrandom> thats 72bps each, but I'm not sure how skewed it is (probably *very*)
            
-
            14:57 < jrandom> however, if all of those tunnels started using lots and lots of bandwidth, the total value would shoot up, and we could throttle it
            
-
            14:57  * fvw nods. 
            
-
            14:57  * fvw notes this is in fact a wildly interesting problem, theoreticly speaking.
            
-
            14:57 < fvw> (but maybe that's just me being weird)
            
-
            14:57 < jrandom> agreed
            
-
            14:58 < jrandom> (to both ;)
            
-
            14:58 < jrandom> but yeah, we dont have the Right Answer yet.  but its something to be worked on
            
-
            14:59 < jrandom> ok, unless there's anything else on that, moving on to 3) Website updates
            
-
            14:59 < fvw> We could ofcourse go totally lossy and just drop datagrams when we're overloaded, and make people run something like tcp over that.
            
-
            14:59 < jrandom> we tried that, and lots and lots and lots of tunnels failed
            
-
            15:00 < jrandom> (since if a tunnel drops 1 message, we mark it as failed)
            
-
            15:00 < fvw> yes, you shouldn't do that if you take that approach.
            
-
            15:00 < jrandom> ((and when we tried not being such fascists, we didn't notice when a tunnel *really* fails))
            
-
            15:00  * fvw nods and strokes his beard. Good point. (mental note to self: grow beard to stroke in situations like this)
            
-
            15:01 < jrandom> heh
            
-
            15:01 < jrandom> ok, anyway, as you've all seen, our new installer and new web interface is completely different from the old way of doing things
            
-
            15:01  * hypercubus gives fvw his beard
            
-
            15:02 < jrandom> while that is Good, since the old way was Painful, all our old docs are now wildly incorrect
            
-
            15:02 < fvw> could we stick on 2) a few minutes longer? I still have a few bad ideas I want you to shoot down.
            
-
            15:02 < jrandom> sure
            
-
            15:02 < dm> I can't use the internet... 
            
-
            15:02 < dm> Bandwidth in/out
            
-
            15:02 < dm> 1m: 13.32/11.98KBps
            
-
            15:02 < dm> 5m: 10.74/9.46KBps
            
-
            15:02 < jrandom> how many tunnels dm?
            
-
            15:02 < hypercubus> dm: that's why i suggested you turn on i2p's bandwidth limiting ;-)
            
-
            15:02 < dm> only 166
            
-
            15:02 < jrandom> yeah, throttle it down to 6KBps
            
-
            15:02 < jrandom> lol
            
-
            15:03 < dm> (participating)
            
-
            15:03 < jrandom> (or maybe 8KBps if you're nice)
            
-
            15:03 < dm> I'll leave it as is, I just need to view this one page
            
-
            15:03 < jrandom> btw, the 13.32 vs 11.98 lets us know you're downloading approximately 1KBps locally
            
-
            15:03 < jrandom> (through i2p)
            
-
            15:03 < fvw> What happens if we just time-out tunnels at a reasonably large idle-time? Say 30 mins or something. The next protocol up would have to do keepalives, but wouldn't that solve the not-detecting-dead-tunnels thing?
            
-
            15:03 < hypercubus> he's downloading far more than that actually
            
-
            15:04 < jrandom> ((though that 1KBps might be small enough to be netDb))
            
-
            15:04 < dm> hypercubus: our transfer is stalling badly, actually.
            
-
            15:04 < jrandom> fvw: tunnels expire after 10 minutes
            
-
            15:04 < deer> <kaji> hold it, is bandwidth working now? if so what sould i turn it to?
            
-
            15:04 < dm> dissapointed in the getright/i2p combo
            
-
            15:04 < jrandom> they're not long lived fvw, unlike TOR
            
-
            15:04 < fvw> and that had most tunnels failing, even with keepalives?
            
-
            15:04 < hypercubus> dm: periodically yes... i think the solution would be to limit your upstream to about 8KB/s
            
-
            15:04 < jrandom> kaji: http://localhost:7657/
            
-
            15:05 < hypercubus> since it seems you're saturated
            
-
            15:05 < jrandom> er, /config.jsp
            
-
            15:05 < fvw> ok, but you don't want them dissapearing in flurries of packet loss.
            
-
            15:05 < jrandom> every minute (on average) each peer tests each tunnel to make sure its alive (so that other people can send us data - without tunnels, we're fucked)
            
-
            15:06 < fvw> Ok. I need to read more of how i2p currently works. On to 3) as far as I'm concerned.
            
-
            15:06 < deer> <kaji> right now its set on the default -1 but I dont know what a 1.5/750@1.2ghz connections translates to from maximum tunnel partisipation
            
-
            15:07 < deer> <kaji> i seem to be participation in 166
            
-
            15:07 < jrandom> kaji: your router will never get so many tunnels that it'll be CPU congested ;)
            
-
            15:07 < deer> <mule_iip> off-topic: don't you need a tunnel to be fucked :)
            
-
            15:07 < deer> <kaji> *ing
            
-
            15:07 < jrandom> heh
            
-
            15:07  * fvw votes "nay"
            
-
            15:08 < deer> <kaji> jrandom, i just finnished reading the letter about tunnels without bandwidth, i just didnt know what to set the limmit to
            
-
            15:08 < jrandom> ok, i agree, lots more to be done to figure this stuff out
            
-
            15:08 < jrandom> ok cool kaji, just enable your bandwidth limiter to something like 8KBps
            
-
            15:08 < jrandom> (or 12 if you're nice :)
            
-
            15:09 < deer> <kaji> </oftopic>
            
-
            15:09 < jrandom> ok, on to 3) website updates
            
-
            15:09 < deer> <kaji> inbound and outbound?
            
-
            15:09 < jrandom> yes kaji
            
-
            15:09 < jrandom> ok, as I said, we need help with the docs
            
-
            15:09 < jrandom> (heeeeeeeeelp!)
            
-
            15:09 < hypercubus> i move we fill the long-vacant team positions of Webmaster and Web Editor
            
-
            15:10  * jrandom seconds that motion
            
-
            15:10 < jrandom> (now all we need is someone to volunteer ;)
            
-
            15:10 < hypercubus> i know cervantes is a busy guy
            
-
            15:10 < jrandom> its more up to the invidual to volunteer /themselves/ hyper ;)
            
-
            15:10 < hypercubus> i nominate Curiosity for Webmaster or Web Editor, or both if she's up for it ;-)
            
-
            15:11 < deer> <ugha2p> Uhh.
            
-
            15:11 < dm> Man, even my CPU is starting to max out because of I2P...
            
-
            15:11 < dm> You love, you REALLY love me :'(
            
-
            15:11 < dm> oops, :')
            
-
            15:12  * cervantes feels someone pushing him into the bull ring
            
-
            15:12 < jrandom> i think we can use all the help we can get, and if she is up for helping, we'd love it
            
-
            15:13 < hypercubus> i've seen her web designs and can vouch for her work
            
-
            15:13 < hypercubus> and she expressed interest, i don't know what she finally decided however
            
-
            15:13 < jrandom> ok great
            
-
            15:13 < dm> she?
            
-
            15:13 < cervantes> I'm sure she can devote far more care and attention to it than I ever could
            
-
            15:14 < dm> that word must not be used in our world
            
-
            15:14 < fvw> never mind that, he said 'care and attention'.
            
-
            15:15  * jrandom groans
            
-
            15:15 < fvw> present company excluded ofcourse.
            
-
            15:15 < jrandom> ok, in any case, we'll need some people to help out on the docs - generating new walk throughs, intro docs, etc
            
-
            15:16 < jrandom> we'll chat with Curiosity about what we can get her to hack on :)
            
-
            15:16 < hypercubus> i can take on the installation related stuff
            
-
            15:16 < hypercubus> s/on/of/
            
-
            15:16 < hypercubus> i know how everyone loves to read these baroque howto's that i write ;-)
            
-
            15:16 < jrandom> :)
            
-
            15:17 < jrandom> an install guide / walkthrough would KickAss
            
-
            15:17 < fvw> that's not how you spell 'broke'.
            
-
            15:17 < jrandom> heh
            
-
            15:17  * hypercubus snickers, then steals fvw's wallet
            
-
            15:17 < hypercubus> that's how you spell "broke" ;-)
            
-
            15:17 < deer> <kaji> hyper what system are you on? i'll take a crack on the winxp version but im not very reliable, i may see something shiny and quit
            
-
            15:17 < deer> * Curiosity is away for a bit...
            
-
            15:18 < hypercubus> kaji: ?
            
-
            15:18 < deer> <kaji> hyper, i was asking what OS you are using
            
-
            15:18 < hypercubus> OSes
            
-
            15:18 < deer> <kaji> OSESES
            
-
            15:19 < hypercubus> i have vmware, so i can run all the windowses and freebsd and such
            
-
            15:19 < hypercubus> also have pearpc, so i can run OS X
            
-
            15:20 < jrandom> ok, if there's nothing else on the web side
            
-
            15:20 < jrandom> moving on to * 4) I2PTunnel web interface
            
-
            15:21  * jrandom declares the i2ptunnel web interface shitty.  functional.  but shitty.
            
-
            15:21 < deer> <DrVince> I could dig in for french translation if interest may be
            
-
            15:21 < jrandom> duck had a few ideas for improving it, but he had to jet, so let me paste a few lines
            
-
            15:21 < hypercubus> again, we need more web devs ;-)
            
-
            15:21 < jrandom> oh, translating web pages to french would rule
            
-
            15:22 < jrandom> s/french/french and other langs/
            
-
            15:22 < jrandom> here are some duck-isms:
            
-
            15:22 < jrandom> <duck> reduce data load on general page; use tables/div to order stuff
            
-
            15:22 < jrandom> <duck> provide a edit/detailed page with info most dont care about, tunnels, dest hash, full key
            
-
            15:22 < jrandom> <duck> feedback after clicking buttons, 'item saved' etc. give dest as output when new one created
            
-
            15:22 < jrandom> <duck> (hide under edit/details otherwise)
            
-
            15:22 < jrandom> <duck> tag the top messages as being 'log'; sometimes confusing
            
-
            15:22 < jrandom> <duck> make clear that 'confirm' is only needed for remove, not save
            
-
            15:22  * jrandom agrees with what he says
            
-
            15:23 < jrandom> there have been a slew of bugfixes behind the scenes in the /i2ptunnel/ web interface since 0.4 too, so the functional kinks should be cleaned up
            
-
            15:24 < jrandom> the code implementing those pages are pretty ugly though
            
-
            15:24 < jrandom> probably the best approach would be to write up the screens in plain html / css / images / etc, then give it to one of the java devs to integrate
            
-
            15:25 < hypercubus> whatever happened to the days when there was an overabundance of web devs? ;-)
            
-
            15:25 < jrandom> they're all working at mcdonalds
            
-
            15:25 < hypercubus> ah right
            
-
            15:25 < deer> * Curiosity is back :)
            
-
            15:25 < jrandom> anyway, if anyone is interested in helping out, or has further suggestions, please get in touch
            
-
            15:25 < jrandom> wb Curiosity
            
-
            15:26 < deer> <Curiosity> should i bring up the idea i told oyu about jrandom?
            
-
            15:26 < cat-a-puss> I know someone who might be able to help with the web stuff
            
-
            15:26 < jrandom> ah, the live cd?
            
-
            15:27 < jrandom> great cat-a-puss, we need all the help we can get
            
-
            15:27 < deer> <Curiosity> teah :)
            
-
            15:27 < deer> <Curiosity> err yeah
            
-
            15:27 < jrandom> Curiosity: yeah, please bring that up when we get to item 6) ???
            
-
            15:28 < deer> <Curiosity> okay :)
            
-
            15:28 < cat-a-puss> ok, I'll get them on the list, and give them jrandom's e-mail (curiosity I don't know your email)
            
-
            15:28 < jrandom> ok, does anyone have anything else to mention regarding the I2PTunnel web interface?
            
-
            15:28 < jrandom> r0x0r cat-a-puss
            
-
            15:29 < deer> <Curiosity> also, i don't mind helping wiht the web editing, etc. also :)
            
-
            15:29 < jrandom> ok, if there's nothing else, 5) Roadmap and todo
            
-
            15:30 < jrandom> awesome Curiosity, thanks!  we can chat a bit after the meeting about taking over the world^W^W^W^Wweb stuff
            
-
            15:30 < deer> <Curiosity> okies :)
            
-
            15:30 < jrandom> as y'all probably saw, there's a new big scary page on the website (http://www.i2p.net/todo)
            
-
            15:31 < jrandom> that covers the big scary issues we have ahead of us (and doesnt even touch on all the client apps we need, etc)
            
-
            15:31 < jrandom> as you can see, we've got a shitload to do, but the good news is, we dont have to have it all done right away. 
            
-
            15:32 < jrandom> in fact, those things are really just the bullet items from the roadmap page (with a heap of text introducing each)
            
-
            15:33 < jrandom> while i know thats a lot to sort through, what would be great is if people could let me know if they come across something that we will need to deal with that isn't on that page
            
-
            15:34 < jrandom> that isn't necessary today or this week even, just a general "hey, let us know"
            
-
            15:35 < jrandom> with mule's suggestion (http://www.i2p.net/todo#nat) i've been doing a lot of soul searching, and the roadmap will likely be moved around a bit
            
-
            15:35 < jrandom> but we'll see.
            
-
            15:36 < jrandom> if you have any strong feelings on certain issues ("omg we *cannot* function without X, Y, and Z!"), please let me know or post onto the list
            
-
            15:36 < jrandom> while i'm no champion of democracy, i am open to reason :)
            
-
            15:37 < jrandom> ok, thats all i've got to say about that.. anyone have anything to throw out there?
            
-
            15:37 < deer> <Curiosity> benevolent dictatorship :)
            
-
            15:37 -!- Sonium_ is now known as Sonium
            
-
            15:37 < jrandom> bah, i'm no dictator - i dont control what other people code :)
            
-
            15:37 < cervantes> tranquil hegemony
            
-
            15:37 < cat-a-puss> I've aquired two more developers
            
-
            15:37 < jrandom> w00t!
            
-
            15:38 < cat-a-puss> and have grand plans for a distributed search engine
            
-
            15:38 < jrandom> oh, kickass
            
-
            15:38 < jrandom> would that be something http://files.i2p/ could tie into?
            
-
            15:38 < jrandom> or, well, let me just say, oh, kickass :)
            
-
            15:38 < cat-a-puss> er: I can't get there (hostile enviroment)
            
-
            15:39 < jrandom> ah 'k
            
-
            15:39 < cat-a-puss> anyway, some CVS space would be nice, once we get there
            
-
            15:40 < jrandom> certainly, space on cvs.i2p is available
            
-
            15:40 < jrandom> either within the i2p/apps/ directory or your own module, if preferred
            
-
            15:40 < jrandom> (cvs.i2p == cvs.i2p.net)
            
-
            15:40 < cat-a-puss> I should probably talk to the people working on the dht huh?
            
-
            15:41 < cat-a-puss> what is the status of that thusfar
            
-
            15:41 < jrandom> :)
            
-
            15:41 < jrandom> i haven't heard any status updates from aum in the last few days, but i'm sure he's churning away
            
-
            15:42 < jrandom> last update was in http://dev.i2p.net/pipermail/i2p/2004-August/000425.html
            
-
            15:43 < jrandom> ok, i guess that moves us on to * 6) ???
            
-
            15:44 < jrandom> Curiosity was bouncing around the idea of a 'live cd' idea with i2p
            
-
            15:44 < jrandom> which i think is pretty cool, and something we will want
            
-
            15:44 < deer> <Curiosity> kewl :)
            
-
            15:44 < jrandom> though we aren't really stable enough for that yet, with a release every 2 weeks or so
            
-
            15:44 < hypercubus> agreed... it could even be integrated into a Knoppix ISO
            
-
            15:45 < deer> <Curiosity> ?
            
-
            15:45 < hypercubus> Knoppix, a livecd distro of linux
            
-
            15:45 < hypercubus> very user friendly
            
-
            15:45 < deer> <Curiosity> k
            
-
            15:45 < jrandom> though once we have the Really Simple Update functionality that is a one click download from http://dev.i2p/i2p/i2pupdate.tar.bz2, it might not be too bad
            
-
            15:46 < jrandom> Curiosity: do you have anything else you want to discuss about that?
            
-
            15:46 < fvw> ...and as soon as it becomes widely used, anyone controlling dev.i2p can compromise the network.
            
-
            15:47 < jrandom> as long as people use that Really Simple Update functionality
            
-
            15:47  * fvw nods.
            
-
            15:47 < deer> <Curiosity> i just wanted a way for people to run it w/o having to download a bunch of stuff onto their computer
            
-
            15:47 < jrandom> (and if dev.i2p is compromised, we put up a new hosts.txt entry for dev.i2p)
            
-
            15:48 < hypercubus> a knoppix i2p livecd would be prime for cybercafe use
            
-
            15:48 < deer> <mule_iip> jarndom: won't a real i2p user grab the source, study the diff against the latest peer reviewed version and build from source :)
            
-
            15:48 < fvw> yes but people will just hit 'update'; They won't listen to discussions about whether the new version might have vulnerabilities...
            
-
            15:48 < demonic_1> is there anyway to not need hosts file. u know like a dns server?
            
-
            15:48 < deer> <Curiosity> yeah... riiiight mule_iip. lol
            
-
            15:49 < fvw> but anyway, I'll be very happy when we get to the stage where this becomes a problem.
            
-
            15:49 < fvw> demonic_l: It's possible, but there'd still be a central authority.
            
-
            15:49 < hypercubus> demonic_1: there are currently a couple of proposals for such functionality, but global names have been ruled out
            
-
            15:49 < jrandom> demonic_1: yes, see the mailing list (recent discussions on http://dev.i2p.net/pipermail/i2p/2004-September/000432.html )
            
-
            15:49 < jrandom> (and my take @ http://dev.i2p.net/pipermail/i2p/2004-September/000435.html :)
            
-
            15:50 < hypercubus> *globally unique names
            
-
            15:50 < demonic_1> k 
            
-
            15:51 < jrandom> ok, anyone have anything else they want to bring up?
            
-
            15:52 < deer> <Curiosity> I would also like ot suggest putting service only items into a service folder... i was trying to uninstall i2p (one time of many) and was hitting the wrong uninstall thingie
            
-
            15:52 < hypercubus> Curiosity: that's being done
            
-
            15:52 < jrandom> w3rd
            
-
            15:52 < hypercubus> the installer will install shortcuts for i2p to the Start menu in Windows
            
-
            15:52 < hypercubus> and optionally on your desktop
            
-
            15:52 < deer> <Curiosity> okies :)
            
-
            15:52 < hypercubus> among them will be "uninstall"
            
-
            15:53 < deer> <Curiosity> i was talking about when i go into program files/i2p 
            
-
            15:53 < hypercubus> you don't need to from there
            
-
            15:54 < hypercubus> Windows users don't ever go into the program folders ;-)
            
-
            15:54 < demonic_1> :/
            
-
            15:54 < deer> <Curiosity> i do! :P
            
-
            15:54 < jrandom> we could perhaps add a bin/ dir with all the scripts
            
-
            15:54 < jrandom> er, nm
            
-
            15:54 < hypercubus> then you would have seen the folder called "Uninstall" ;-)
            
-
            15:54  * jrandom remembers the paths
            
-
            15:54 < hypercubus> which is where the uninstaller is located
            
-
            15:54 < jrandom> we can move the service scripts into lib though
            
-
            15:54 < hypercubus> i'm not sure we can
            
-
            15:55 < cervantes> you could go the 'doze method and have the "uninstall" option in the installer ;-)
            
-
            15:55 < hypercubus> wrapper is very particular about where you put those
            
-
            15:55 < jrandom> at the very least they can "cd .." first
            
-
            15:55 < hypercubus> i'll look into changing their location
            
-
            15:55 < hypercubus> but it might not be doable
            
-
            15:55 < jrandom> cool, thanks.  it'd be nice to remove some of the clutter in the install dir
            
-
            15:55 < hypercubus> agreed
            
-
            15:55 < jrandom> (most of which is my fautlt with all those .config files :)
            
-
            15:56 < hypercubus> we could have a config dir i guess
            
-
            15:56 < cervantes> ./conf ?
            
-
            15:56 < jrandom> c'mon, we're geeks.  etc/ :)
            
-
            15:56 < jrandom> that would be Really Easy though
            
-
            15:56 < jrandom> (just a few -D parameters on the CLI)
            
-
            15:56 < hypercubus> then we'll have to field questions from Windows users that "etc" isn't obvious enough ;-)
            
-
            15:56 < jrandom> people shouldnt need to touch their config
            
-
            15:57 < jrandom> thats what the web is for
            
-
            15:57 < cervantes> I've always gone for the blatant:  ./configuration/
            
-
            15:57 < hypercubus> right, but Windows users shouldn't need to launch the uninstaller from their program directory either heheh
            
-
            15:57 < jrandom> ./thesefilestellstufftodothings/
            
-
            15:57 < cervantes> ./scripts/
            
-
            15:57 < cervantes> ./asciipr0n
            
-
            15:57 < jrandom> ok, but yeah, some work we can flesh out
            
-
            15:57 < deer> <Curiosity> lol
            
-
            15:58 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            15:58 < jrandom> if not
            
-
            15:58  * jrandom winds up
            
-
            15:59  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting107.html b/www.i2p2/pages/meeting107.html
deleted file mode 100644
index c67fe93c..00000000
--- a/www.i2p2/pages/meeting107.html
+++ /dev/null
@@ -1,500 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 107{% endblock %}
-{% block content %}
            I2P dev meeting, September 14, 2004
            
-
            
-
            14:06 < jrandom> 0) hi
            
-
            14:06 < jrandom> 1) 0.4.0.1
            
-
            14:06 < jrandom> 2) Threat model updates
            
-
            14:06 < jrandom> 3) Website updates
            
-
            14:06 < jrandom> 4) Roadmap
            
-
            14:06 < jrandom> 5) Client apps
            
-
            14:06 < jrandom> 6) ???
            
-
            14:06 < jrandom> 0) hi
            
-
            14:06  * jrandom waves
            
-
            14:06 < cervantes> evening
            
-
            14:06 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-September/000444.html
            
-
            14:07 < jrandom> (before the meeting this time too ;)
            
-
            14:07 < deer> <jrand0m> woah, 30 people over here
            
-
            14:07 -!- Irssi: #i2p: Total of 21 nicks [0 ops, 0 halfops, 0 voices, 21 normal]
            
-
            14:07 < jrandom> ok, anyway, lets jump right in to 1) 0.4.0.1
            
-
            14:08 < jrandom> the release is out and things seem to be working more or less
            
-
            14:09 < jrandom> i see a variety of connection times on irc, though in discussions with people, it seems there are congestion issues when e.g. downloading large files and using irc at the same time
            
-
            14:09 < jrandom> are many people running into that?
            
-
            14:10 < jrandom> i guess not
            
-
            14:11 < cervantes> I've been doing various bandwidth tests recently and haven't encounter problems in that area yet...although I'm not using the bandwidth limiter
            
-
            14:11  * nicktastic hasn't downloaded much since raiding alexandria weeks ago
            
-
            14:11 < dm> I remember getting disconnect more often on IRC when I was using eepsites, but that was 2 months ago
            
-
            14:11 < dm> disconnected
            
-
            14:11 < dm> not sure if it still happens
            
-
            14:11 < jrandom> ah, yeah, we need to harass the alexandria folks to give us more books :)
            
-
            14:12 < Nightblade> thanks for keeping us up to date dm
            
-
            14:12 < jrandom> i've had good luck w/ irc while downloading some large files from thetower, but, like cervantes, i dont have bandwidth limiting set
            
-
            14:13 < jrandom> (though that router's bw average was a steady 11KBps at the time, while downloading 8KBps of music)
            
-
            14:13  * nicktastic finds something to download
            
-
            14:13  * jrandom watches your irc.duck.i2p connection quickly get dropped ;)
            
-
            14:13 < jrandom> ok, anyway, does anyone have anything else they want to bring up wrt 0.4.0.1?
            
-
            14:14 < dm> Nightblade: hehe, no problem :)
            
-
            14:14 < dm> jrandom: good work, ever onwards
            
-
            14:14 < fvw> the installer is pretty? (not sure if that's new in .1?)
            
-
            14:14 < jrandom> gracias dm
            
-
            14:15 < jrandom> fvw: same as 0.4, but i agree, hyper did some great work there (as did our anonymous designer!)
            
-
            14:15 < fvw> also, I'm not going to commit myself as to pretty _what_ it is :)
            
-
            14:15 < jrandom> sonofabi...
            
-
            14:16 < jrandom> ok, moving on to 2) Threat model updates
            
-
            14:16 < cervantes> yes well done.. :) writing documentation always sucks 
            
-
            14:17 < jrandom> yeah, it was a painful 2-3 days
            
-
            14:17 < jrandom> i'm not sure if any of y'all have read http://www.i2p.net/how_threatmodel but if you ever want to know wtf we're talking about when we say "anonymous", thats what we mean
            
-
            14:18 < jrandom> most of the categories there were just ripped from http://citeseer.ist.psu.edu/454354.html (linked to on the page)
            
-
            14:18 < jrandom> there's a lot more i'd like to do in the threat model, but i just dont have the time.
            
-
            14:18 < jrandom> i'd love to see a matrix of those threats vs cost of mounting them vs the type of user who cares about them
            
-
            14:19 < jrandom> (e.g. joe sixpack does't care about global active adversaries)
            
-
            14:19 < jrandom> so if anyone is bored... ;)
            
-
            14:19 < cervantes> something that occurred to me whilst reading your doc... we need a decent glossary...
            
-
            14:20 < fvw> doesn't he? joe sixpack likes to download mp3s...
            
-
            14:20 < jrandom> someone just published one iirc...
            
-
            14:20 < cervantes> really?
            
-
            14:20 < cervantes> on an eep?
            
-
            14:20 < jrandom> no, some research paper
            
-
            14:20 < jrandom> its not on freehaven yet, lemmie dig it up
            
-
            14:21 < jrandom> bugger, i dont seem to have my copy anymore.  
            
-
            14:21 < jrandom> i'll try to track it down after the meeting
            
-
            14:22 < cervantes> does it tackle i2p specific concepts to?
            
-
            14:22 < jrandom> oh, no
            
-
            14:22 < jrandom> its just a general glossary for anonymous networks, dealing with mixes, cascades, attackers, etc
            
-
            14:22 < jrandom> no garlic routing or tunnels ;)
            
-
            14:23 < cervantes> a nice single paragraph summary of all "in" buzzwords so people can quickly see the difference between onion and garlic routing (for example) withou having to read the whole "how" document
            
-
            14:23 < jrandom> you realize a glossary would be larger than the how_* pages combined, right?  
            
-
            14:23 < jrandom> but yeah, i agree, we should do that
            
-
            14:23 < cervantes> sure... but.. ;)
            
-
            14:23  * jrandom volunteers cervantes to work on it ;)
            
-
            14:23  * dm concurs
            
-
            14:23 < cervantes> hehe I don't know what half that shit means :)
            
-
            14:24 < jrandom> write up what you do know and ask me questions
            
-
            14:24 < cervantes> I'll have a crack at it
            
-
            14:24 < jrandom> w00t!  cervantes++
            
-
            14:24 < cervantes> if I put it on the forum then others can contribute...
            
-
            14:24 < jrandom> good idea
            
-
            14:24 < deer> * Pseudonym cheers
            
-
            14:25 < cervantes> _but_ that doc you mentioned would be handy :o)
            
-
            14:25 < dm> tunnel: artificial underground passage
            
-
            14:25 < jrandom> agreed, i'll try to find it again
            
-
            14:25 < cervantes> I'll do a special version for you dm
            
-
            14:25 < dm> yay!
            
-
            14:26 < jrandom> ok, anything else on the threat model, or shall we move on to 3) Website updates ?
            
-
            14:27 < jrandom> ok, as anyone who has been to the site today has seen, Curiosity has come up with some nice usability updates
            
-
            14:27 < dm> I think cervantes and I are the only ones still awake.
            
-
            14:27 < korkakak> I think that in threat models
            
-
            14:28 < korkakak> you should add some mixnetwork attacks
            
-
            14:28 < jrandom> what sort of mix attacks?
            
-
            14:28  * dm loads up www.i2p.net
            
-
            14:28 < korkakak> like collusion attacks
            
-
            14:28 < jrandom> thats the thing that sucks about the taxonomies i used.  they're all pretty much collusion attacks.
            
-
            14:29 < korkakak> With mix attacks i mean attacks that may happen in a mix network
            
-
            14:29 < korkakak> ah ok sorry
            
-
            14:29 < jrandom> (and most can be used for either probabalistic or confirmation attacks, etc)
            
-
            14:29 < dm> I like the increasing-in-size paragraphs. Helps drag people in. Far too technical for a front page though.
            
-
            14:29 < korkakak> Another 5 cents from me: Can i2p detect a collusion automatically?
            
-
            14:30 < jrandom> but if you have some suggestions for things we need to add, please, let me know
            
-
            14:30 < jrandom> oh, definitely not.  we haven't imported morphmix's algorithms
            
-
            14:30 < korkakak> I c
            
-
            14:30 < korkakak> ok keep on
            
-
            14:30 < jrandom> though theirs wouldn't really fly with us though, since we're a free route mixnet
            
-
            14:31 < korkakak> Well yes and no
            
-
            14:31 < korkakak> but it is ok. SOrry for the interrutp
            
-
            14:32 < cat-a-puss> It might also be a good idea to mention up frount some of the obvious attacks that I2p is NOT vunerable to
            
-
            14:32 < jrandom> hmm?  their algorithms are based off detecting the influence of colluding peers in the peer selection - within i2p, the local router explicitly defines the entire peer selection algorithm
            
-
            14:33 < korkakak> I guess that this is true due to the size of todays network
            
-
            14:33 < jrandom> ah, thats a good idea cat-a-puss, w/ MITM/etc.  would you be interested in posting up some ideas for that?
            
-
            14:33 < cat-a-puss> sure
            
-
            14:33 < dm> MITM?
            
-
            14:33 < dm> Ah, man in the middle.
            
-
            14:33 < jrandom> muchas gracias cat-a-puss!
            
-
            14:34  * cervantes jots down MITM for the glossary
            
-
            14:34 < jrandom> korkakak: hmm.  i'm not sure how that aspect is affected by the size of the net, but there may be things we can learn from morphmix's collusion detection, certainly
            
-
            14:34 < jrandom> (perhaps wrt the netDb responses, for instance)
            
-
            14:34 < korkakak> wrt = ?
            
-
            14:35 < dm> hehee
            
-
            14:35 < jrandom> sorry, with regards to
            
-
            14:35 < dm> I know that one!
            
-
            14:36 < jrandom> we would certainly benefit from more discussion on the threat model.  perhaps we can start up a thread on the list or in the forum?
            
-
            14:36 < dm> "The result is that the number of peers relaying each end to end message is the absolute minimum necessary to meet both the sender's and the receiver's threat model."
            
-
            14:36 < dm> I like this way of looking at it.
            
-
            14:37 < dm> Although it's not true.
            
-
            14:37 < jrandom> hmm?  
            
-
            14:37 < jrandom> if both sender and receiver want only plausible deniability, they can talk directly
            
-
            14:37 < jrandom> (etc)
            
-
            14:37 < dm> The absolute minimum number of peers required to meet the threat model of A and B is the number of peers required by A or B, whichever has more stringent requirements :)
            
-
            14:38 < jrandom> not true dm
            
-
            14:38 < jrandom> if they both require 2 hop tunnels to defend against colluding attackers in their tunnels, they can't both have 1 hop tunnels
            
-
            14:39 < dm> If A is willing to talk to someone with 10 indirections, and B is willing with 5, the minimum needed is 10, not 15!?
            
-
            14:39 < jrandom> no, 15.  B shouldn't trust A's tunnels.
            
-
            14:39 < dm> Yeah, he shouldn't.
            
-
            14:39 < dm> But theoratically.. Anyway, stupid discussion. I like that sentence though.
            
-
            14:40 < jrandom> its one of the more important design decisions in i2p ;)
            
-
            14:40 < jrandom> anyway, back to 3) Website updates
            
-
            14:41 < deer> <nicktastic> (fyi - irc dropped while downloading two large files, but latency to the server is as it was before the downloads started, so could've been a fluke (ungraceful shutdown somewhere?))
            
-
            14:41 < jrandom> Curiosity and I discussed the length of the new homepage, and while we all agree that its a little long, its better than the old 1 liner
            
-
            14:41 < cervantes> agreed
            
-
            14:42 < jrandom> ah ok.  perhaps even network congestion while downloading, since the eepproxy and the irc client use the same I2P destination (by default)
            
-
            14:42 < nicktastic> Aaah....
            
-
            14:42 < jrandom> (so both would be trying to use the same pair of inbound tunnels)
            
-
            14:42 < nicktastic> I was wondering why only one showed up
            
-
            14:43 < jrandom> yeah, thats the default within I2PTunnel and the ministreaming lib.  perhaps if someone cares we can expose a way to configure that ;)
            
-
            14:43 < nicktastic> sorry to interrupt
            
-
            14:43 < deer> * Pseudonym cares
            
-
            14:43 < dm> such polite lads we have in this room
            
-
            14:43 < interrupt> you are forgiven
            
-
            14:44 < interrupt> ;)
            
-
            14:44  * nicktastic rolls eyes
            
-
            14:44 < jrandom> patches welcome Pseudonym ;)  (naw, i'll see if i can find an easy way.. shouldnt be too hard)
            
-
            14:44 < jrandom> ok, anyway
            
-
            14:44 < deer> <Pseudonym> good, 'cause I don't know crap about how to code in java
            
-
            14:45 < jrandom> there may be further website updates, but if anyone has any suggestions, please post 'em to the forum or the list, or point 'em out to Curiosity on irc and we'll get things rolling
            
-
            14:45 < jrandom> anyone have anything they want to bring up wrt the website?
            
-
            14:45 < cervantes> umm bouties perhaps
            
-
            14:46 < cervantes> although maybe that's best saved for 5
            
-
            14:46 < jrandom> prolly so
            
-
            14:46 < jrandom> ok, moving on to 4) Roadmap
            
-
            14:46 < jrandom> lots of updates.  see the email for info
            
-
            14:47 < jrandom> (or look at the pretty gantt chart ;)
            
-
            14:47 < dm> Was that done in MS Project?
            
-
            14:47 < jrandom> http://ganttproject.sourceforge.net/
            
-
            14:47 < cervantes> eerm gantt :)
            
-
            14:47 < dm> oh.. gantt is a product. My bad.
            
-
            14:48 < dm> Nice to see there are no dependencies in the roadmap.
            
-
            14:48 < jrandom> i've posted a few different revs of the roadmap over the last few days, but this one seems to be solid
            
-
            14:48 < cervantes> it's all dependant on jrandom ;-)
            
-
            14:48  * jrandom whimpers
            
-
            14:48 < fvw> 3.0 in febuary? Wow.
            
-
            14:48 < jrandom> the 2.0 and 3.0 releases are really just 1 (big) feature each
            
-
            14:48 < dm> Don't forget: exponential versioning
            
-
            14:49 < jrandom> heh
            
-
            14:49 < jrandom> yeah, we'll be 1183 by next july
            
-
            14:50 < dm> Well, it's more interesting than the abritrary +0.1 per build of most projects, so I'm not complaining.
            
-
            14:50 < jrandom> the 2.0 and 3.0 releases may be delayed to stay in line with other apps though.  e.g. 3.0 would work great with an email app
            
-
            14:51 < jrandom> the release criteria for 1.0 has been the usual - functional, secure, scalable, and anonymous
            
-
            14:51 < jrandom> thats why i moved the udp transport in, as our current tcp transport would shit bricks if we had a few thousand peers
            
-
            14:51 < dm> so we should have a 0.9 - The Slashdot
            
-
            14:51 < dm> if it survives we can check off scalable and move to 1.0
            
-
            14:51 < jrandom> heh
            
-
            14:52  * jrandom would rather grow organically, thankyouverymuch
            
-
            14:52 < cervantes> we don't to tell _them_ about it
            
-
            14:52 < cervantes> *don't want
            
-
            14:52 < korkakak> btw may i say something about the global timing?
            
-
            14:52 < cervantes> let them all stay on the internet while we move here
            
-
            14:52 < jrandom> sure korkakak
            
-
            14:53 < korkakak> As far as i am concerned you cannot simulate a synchronus network over an asynchronous
            
-
            14:53 < korkakak> it is just bad design and should lead to network splits [i think] in the way it is used
            
-
            14:54 < korkakak> as a timestamp for UDP packets
            
-
            14:54 < jrandom> the timing is not synchronized for messaging, merely to help us know the freshness of data
            
-
            14:54 < korkakak> yes that's the point
            
-
            14:54 < jrandom> without knowing the freshness of the netDb entries, you're vulnerable to a whole slew of attacks
            
-
            14:55 < korkakak> Yes
            
-
            14:55 < korkakak> but imagine a growing network
            
-
            14:55 < korkakak> a huge network
            
-
            14:55 < jrandom> like the internet
            
-
            14:55 < dm> bigger!
            
-
            14:55 < fvw> two internets tied together with bits of string!
            
-
            14:55 < jrandom> that has a network time protocol for scaling to such sizes... ;)
            
-
            14:56 < korkakak> I don't think I understand your point but
            
-
            14:56 < dm> korkakak: what are you trying to say?
            
-
            14:57 < korkakak> that net splits may happend due to invalid timestamps
            
-
            14:58  * dm is not sure how syncing works currently
            
-
            14:58 < korkakak> the case is called localization effect [english translation from greek]
            
-
            14:58 < deer> <soros> i hear i2p's anonymity has been cracked
            
-
            14:59 < deer> <soros> true ?
            
-
            14:59 < jrandom> i believe we can address the time sync issue the same way the NTP networks do.  there are a massive number of tier 2 and 3 NTP hosts, and while our current SNTP implementation is of course unsuitable for congested environments, there is no reason to believe time synchronization isn't possible
            
-
            14:59 < jrandom> heh soros
            
-
            14:59 < jrandom> soros: the thread you're referring to (someone else mentioned it to me) on devl was talking about JAP being compromised, not I2P.
            
-
            15:00 < dm> so all I2P nodes must stay synced at all times for it to work?
            
-
            15:00 < korkakak> NTP nets are synhcronus networks over synchronus networks ;-)
            
-
            15:00 < jrandom> but if someone has a compromise for I2P, I would certainly love to hear about it
            
-
            15:00 < deer> <soros> i have one but i'm keeping it a secret
            
-
            15:00 < jrandom> at various levels of abstraction korkakak, sure.  my ethernet cable is synchronized too
            
-
            15:01 < deer> <soros> :)
            
-
            15:01 < jrandom> yes dm, synchronized to the network time
            
-
            15:01 < korkakak> jrandom it is nick or korki :-)
            
-
            15:01 < jrandom> (the point is that we dont use synchronous messaging)
            
-
            15:01 < jrandom> :) 'k
            
-
            15:01 < jrandom> (please dont be offended if i dont tell you my name ;)
            
-
            15:02 < korkakak> No I am not
            
-
            15:02 < dm> His name is Abdul
            
-
            15:02 < jrandom> ok where were we
            
-
            15:02 < nicktastic> 4)
            
-
            15:03 < jrandom> ok right, thanks.  the roadmap
            
-
            15:03 < jrandom> anyone have any concerns / ideas / suggestions?
            
-
            15:03 < dm> so when you say some work is going to be done on the transport, do you mean reworking TCP, or moving to UDP?
            
-
            15:04 < jrandom> UDP is 0.4.4
            
-
            15:05 < dm> I thought I saw something about work on the transport layer
            
-
            15:05 < dm> in the near future
            
-
            15:05 < jrandom> yes, 0.4.1 will be a revamp of the TCP transport
            
-
            15:05 < dm> why revamp TCP in 0.4.1 if going UDP in 0.4.4?
            
-
            15:05 < dm> We'll need both?
            
-
            15:05 < cervantes> only to point out that your are still the only resource in the project plan... ...are we suffering from a lack of contributors or just project fragmentation?
            
-
            15:06 < jrandom> dm: some people cannot use UDP
            
-
            15:06 < dm> firewalls?
            
-
            15:06 < jrandom> cervantes: we certainly could parallelize many of those tasks with more contributors
            
-
            15:07 < jrandom> (but the roadmap does not assume more)
            
-
            15:07 < cervantes> so hopefully it represents the worse case scenario
            
-
            15:07 < jrandom> there is however other important work going on not reflected on the roadmap, such as client mods, services on top of i2p, etc
            
-
            15:08 < cervantes> asside from you being assassinated
            
-
            15:08 < dm> I wish we could afford toad
            
-
            15:08 < deer> <Pseudonym> now that 0.4 is out and pretty much working, should we announce somewhere (not necessarily /.) to try to increase the number of developers/testers/donors?
            
-
            15:08 < jrandom> more contributors would certainly be welcome
            
-
            15:08  * korkakak farewells all. REady to go to his bed. It is late at korkakak lands...
            
-
            15:08 < korkakak> bye gayz
            
-
            15:08 < cervantes> g'night
            
-
            15:08 < jrandom> thanks for swinging by nick, ttyl
            
-
            15:10 < dm> nite
            
-
            15:10 < jrandom> a /. would probably be premature, but it would be good to bring new folks on board through other means
            
-
            15:10 < dm> You're very open to Pseudonym's suggestion. I thought you were going to freak out.
            
-
            15:10 < jrandom> but i think through word of mouth we're growing steadily
            
-
            15:11 < deer> <Pseudonym> and if we do want to announce, where should we do it?
            
-
            15:11 < jrandom> i dont think we should have any announcements yet, not till 1.0
            
-
            15:11 < deer> <Pseudonym> seems like we could use an influx of cash/talent
            
-
            15:11 < jrandom> but if you hear someone talking about how they wish there were some way to help do stuff anonymously, point 'em at i2p ;)
            
-
            15:12 < deer> * DrWoo suggests a whisper campaign
            
-
            15:12 < cervantes> we have a fair amount of unnallocated cash already...
            
-
            15:12 < jrandom> we're an open team, but you only have one chance to make a first impression.
            
-
            15:13 < cat-a-puss> I would not recomend going from no publicity to /. there needs to be an intermediate step to make sure we can handel the load
            
-
            15:13 < deer> <Pseudonym> then we should allocate it to bounties we think are important
            
-
            15:13 < dm> We need to hire a full-time dev or find someone REALLY REALLY bored
            
-
            15:13 < jrandom> agreed.  i'd like to see at least 500 routers online prior
            
-
            15:13 < jrandom> actually, y'all are moving us right along to 5) Client apps :)
            
-
            15:14 < jrandom> we do have ~300 in the pot at the moment (well, almost, but thats another story)
            
-
            15:14 < deer> <Pseudonym> any suggestions on what the intermediate step could be?
            
-
            15:14 < jrandom> pseudonym: we can't have 1000s of nodes until 0.4.4
            
-
            15:15 < jrandom> (and we'd want to stress test the net out first)
            
-
            15:15 < fvw> Actually, we probably can on most unices. Needs adjusting the rlimits though.
            
-
            15:15 < jrandom> right right
            
-
            15:15 < jrandom> it'd be painful, anyway ;)
            
-
            15:16 < deer> <Pseudonym> right. so no /. but it seems like there should be somewhere we can get a couple hundred
            
-
            15:16 < jrandom> we can do larger sims though
            
-
            15:16 < deer> <Pseudonym> does anyone know someone at the EFF? maybe they have a mailing list
            
-
            15:17 < jrandom> yeah, i've spoken with some eff folks about some things
            
-
            15:17 < fvw> I  think any announcement will cause it to filter through to slashdot. I agree with jrandom, a little waiting isn't bad at this time.
            
-
            15:18 < dm> you have to be aware that if you hit 200-300 nodes, you're most likely to get an automatic /. mention ;)
            
-
            15:18 < jrandom> (especially since we've been going for ~ 15 months already)
            
-
            15:18 < dm> critical mass/hype and all that
            
-
            15:18 < jrandom> well, thats also another thing that leads in to 5) Client apps
            
-
            15:19 < jrandom> i'm watching some stats and it seems probably 1/4th of the routers out there aren't even really doing any client activity
            
-
            15:19 < jrandom> which is great and wonderful that people are willing to donate their resources to act as I2P routers, but its too bad that we dont have something to suck them in :)
            
-
            15:19 < fvw> Yeah, I'd like to do a proper chat app (as in irc, but in a way that makes sense for i2p), but this is very much a long term thing, no time the next few months...
            
-
            15:20 < jrandom> we have had an influx of kickass eepsites recently though
            
-
            15:20 < jrandom> ah cool fvw
            
-
            15:20 < cervantes> many people run more than 1 router though
            
-
            15:20 < jrandom> a solid IM/group chat for I2P would certainly rule
            
-
            15:20 < nicktastic> fvw: Instant messenger with multi-user chat, perhaps?
            
-
            15:20 < deer> <mrflibble> dudes, in 0.4.0.1, how do i allow the router to listen on more than just localhost?
            
-
            15:20 < cat-a-puss> hey, could someone write a gaim plugin? that would be a good way to do it
            
-
            15:20 < jrandom> right cervantes 
            
-
            15:20 < cervantes> they maybe use 1 for apps...and donate the others
            
-
            15:21 < jrandom> mrflibble: http://localhost:7657/i2ptunnel/ to configure the http and irc proxies to listen on "any interface"
            
-
            15:21 < fvw> which reminds me: could we do something multicastish for outbound tunnels? ie have one message delivered to multiple inbouds?
            
-
            15:21 < nicktastic> cat-a-puss: Certainly possible
            
-
            15:21 < fvw> yeah, in essence there's not much difference between irc and im, apart from the user interface.
            
-
            15:22 < jrandom> fvw: yes and no.  it wouldn't offer much savings (as messages are end to end encrypted, so you'd have to garlic wrap the message to the outbound tunnel's endpoint and direct the cloves seperately from there)
            
-
            15:22 < jrandom> imho multicast would want to use an application layer overlay
            
-
            15:22 < deer> <mrflibble> oh, thanks jrandom!
            
-
            15:22 < fvw> what do you mean by application layer overlay?
            
-
            15:22 < jrandom> ala shoutcast/etc
            
-
            15:23 < hypercubus> he means do the multicasting in the applcation layer
            
-
            15:23 < hypercubus> not in the i2p layer
            
-
            15:23 < cervantes> 'lo hyper
            
-
            15:23 < fvw> yes ok. Fair enough.
            
-
            15:24 < jrandom> ok, I ranted enough in the email about the client apps, so I'm not going to repeat myself here.
            
-
            15:25  * fvw pouts and puts away the popcorn.
            
-
            15:25  * jrandom !thwaps the wiseass
            
-
            15:26 < jrandom> but, basically I think before we go "live", we need something engaging to go live *with*
            
-
            15:26 < dm> If you build it, they will come...
            
-
            15:26 < dm> hahaha, or not!!!
            
-
            15:26 < fvw> yes. Though we could probably pull quite some crowd from freenet just by having dynamic (not to mention _working_) freesites.
            
-
            15:27 < deer> <Pseudonym> what about using some of the money in the general fund to create/increase bounties for the engaging stuff
            
-
            15:27 < nicktastic> ...and dht
            
-
            15:27 < cervantes> I have no knowledge of freenet... how do freesites differ to eepsites?
            
-
            15:27 < cervantes> if they are in any way the same
            
-
            15:27 < deer> <Pseudonym> eepsites work
            
-
            15:28 < deer> <soros> heh
            
-
            15:28 < hypercubus> imo you guys are impatient
            
-
            15:28 < cervantes> apart from that
            
-
            15:28 < nicktastic> hypercubus: How's that?
            
-
            15:28 < hypercubus> contribute to the project, or shut up
            
-
            15:28 < deer> <soros> freesites are static.
            
-
            15:28 < jrandom> bounties/voting some of the general fund to give $$$ to service providers / eepsites that do kickass things does sound like a good idea
            
-
            15:28  * jrandom is the impatient one hypercubus ;)
            
-
            15:28 < jrandom> Pseudonym: is that what you mean?
            
-
            15:28 < cervantes> these applications are certainly not going to materialise overnight
            
-
            15:29 < jrandom> right, thats why we need to talk about it now
            
-
            15:29 < jrandom> duck: you 'round?
            
-
            15:29 < hypercubus> it's these people pushing for public announcements
            
-
            15:29 < fvw> I doubt you'll get more eepsites with bounties. The people who build them do it because it's fun, I doubt we could pay those who don't find it fun enough.
            
-
            15:29 < deer> <soros> dynamic freesites can be updated, but only once a day... 
            
-
            15:29 < jrandom> probably true fvw
            
-
            15:29 < deer> <Pseudonym> I was thinking more of using the general fund to support bounties for apps, not services/eepsites
            
-
            15:29 < fvw> nobody's pushing for announcements, it was just discussed briefly.
            
-
            15:30 < hypercubus> the project is evolving and growing naturally, have patience
            
-
            15:30 < jrandom> ok word Pseudonym.  
            
-
            15:30  * fvw nods at pseudonym. That might be good yes.
            
-
            15:30 < jrandom> what would y'all suggest?
            
-
            15:30 < nicktastic> hypercubus: They're just brainstorming ways to grow the network without GROWING the network ;)
            
-
            15:30 < jrandom> the entire donation pool is available to be applied wherever we see fit
            
-
            15:30 < fvw> though I think small bug or feature bounties have the greatest chance of actually causing stuff to happen as opposed to being a nice gift for the person who happened to do it anyway.
            
-
            15:31 < deer> <Pseudonym> small bounties don't seem to be working. how about we push a bunch of money into the MyI2p pot
            
-
            15:32 < hypercubus> how about you donate?
            
-
            15:32 < nicktastic> jrandom: Well, for swarming file transfer and dds to be useful, we need streams faster than 4kbyte/sec, so two bounties are fairly dependent on the streaming library bounty
            
-
            15:32 < nicktastic> jrandom: But from earlier discussion, that sounds rather trivial
            
-
            15:32 < cervantes> throwing money at things isn't going to make stuff appear overnight either :)
            
-
            15:32 < deer> <Pseudonym> I have donated
            
-
            15:32 < deer> <soros> just announce i2p to slashdot
            
-
            15:32 < deer> <soros> thats all you need
            
-
            15:33 < hypercubus> that is exactly the opposite of what we need
            
-
            15:33 < deer> <Pseudonym> not overnight, but maybe somebody will start working on it
            
-
            15:33 < jrandom> nicktastic: the streaming lib will be lots of work, but thats the 0.4.3 release :)
            
-
            15:34  * nicktastic consults roadmap
            
-
            15:34 < jrandom> but I agree with cervantes, $$ doesn't make code, coders make code.
            
-
            15:34 < deer> <soros> is i2p listed on freshmeat ?
            
-
            15:34 < jrandom> if only there were some magic way to get in touch with hackers without letting general users know ;)
            
-
            15:34 < jrandom> not to my knowledge soros
            
-
            15:34 < fvw> cross-post to other anonymity-related software mailinglists?
            
-
            15:35 < fvw> actually, I think most of the people where already involved with freenet or gnunet, and have become aware of i2p already.
            
-
            15:35 < cervantes> hack into their inferior anonymity networks and say "hi come and work for us"
            
-
            15:35 < jrandom> we do get a good # of hits from gnunet's links page
            
-
            15:35 < jrandom> heh cervantes 
            
-
            15:35 < deer> <demonic_1> there r some ng's i would think
            
-
            15:36 < cervantes> (work for us or we'll give your ip to big brother)
            
-
            15:36 < cat-a-puss> you could put refrences to I2p in wikis talking about related things
            
-
            15:36 < deer> <baffled> I think one thing we need is some way to get mail in to i2p and anonymously out of it.
            
-
            15:36 < jrandom> i think someone has already placed i2p at various spots in wikipedia, though i dont know about iA lately
            
-
            15:36  * fvw doesn't see why you couldn't run smtp over a tunnel.
            
-
            15:37 < jrandom> agreed baffled, a solid way to do mail *securely* would be great
            
-
            15:37 < cervantes> is that possible though
            
-
            15:37 < fvw> we must be careful not to spam though.
            
-
            15:37 < jrandom> fvw: do you trust your mail client?
            
-
            15:37 < jrandom> however, a mixminion/mixmaster outbound gateway would *rule*
            
-
            15:37 < jrandom> (so someone go set up a web interface to one of those.  please :)
            
-
            15:37 < fvw> jrandom: as much as I trust any other client software... Do you trust your IRC client? your web browser? ...
            
-
            15:38 < cervantes> you'd have to trust the guy who owns the gateway isn't reading your mail
            
-
            15:38 < jrandom> fvw: no.
            
-
            15:38 < jrandom> fvw: and thats a problem.
            
-
            15:38 < jrandom> fvw: a problem we must fix before we can recommend that people use I2P for anything beyond testing.
            
-
            15:39 < fvw> How do you suggest making mail clients "more anonymous"?
            
-
            15:39 < jrandom> it'd need to be a local SMTP/POP3 "server" that reads from the client, parses, interprets, and acts accordingly.
            
-
            15:39 < cervantes> you'd need a bespoke mail application for a start
            
-
            15:39 < jrandom> (there are a few apps out there that do that already)
            
-
            15:39 < cervantes> (client)
            
-
            15:40  * cervantes apologies for saying "bespoke"
            
-
            15:40 < cervantes> *apologises
            
-
            15:40 < jrandom> but that gets to one of the points in the weekly status notes - there are just so many important things that need to get done
            
-
            15:40 < fvw> jrandom: That'd be very easy, at least on unix. Just hack up a sendmail drop in and something that does fetchmail and you're there. Could be done in shell scripts if you wanted to.
            
-
            15:40 < deer> <duck> me hears an echo of his name
            
-
            15:40 < jrandom> we need to focus if the bounties are going to be sufficient
            
-
            15:40 < jrandom> oh, heya duck
            
-
            15:41 < deer> <duck> sorry, I was euh.. drinking'
            
-
            15:41 < jrandom> duck: just wanted to check in to see if there was any update on that web gateway thingy?  and/or whether it might be something normal i2p users could use?
            
-
            15:41 < jrandom> heh, cheers
            
-
            15:41 < nicktastic> drunken duck
            
-
            15:41 < cervantes> pond water?
            
-
            15:41 < jrandom> fvw: get coding :)
            
-
            15:42 < deer> <duck> nope, the dev did freeze up. will have to find someone else
            
-
            15:42 < jrandom> ok, sorry to hear that
            
-
            15:42 < deer> <baffled> We told you not to keep putting them in the closet to protect them.
            
-
            15:43 < deer> <duck> my initial specs: http://duck.i2p/files/anonyproxy.txt
            
-
            15:44 < deer> <baffled> Is getting mail in/out of i2p as easy as some type of interface web/tunnel to one of these mixmaster thingies?
            
-
            15:44 < jrandom> perhaps we can work on a revamp of the spec for that and see if it could serve the needs of normal eepsites (with i2p general funds pitching in)
            
-
            15:44 < jrandom> oh ok cool duck, i'll check that out
            
-
            15:44 < jrandom> baffled: out of i2p?  yes.  in to i2p?  probably more work
            
-
            15:44 < fvw> baffled: Why do you want to add mixmaster? Everything mixmaster offers we already have.
            
-
            15:45 < jrandom> fvw: mixmaster has a network of outproxies, plus nontrivial delays
            
-
            15:45 < jrandom> ah ok duck, spec glanced over.  we may be able to figure something
            
-
            15:45 < deer> <baffled> I don't, jrandom suggested setting up a web interface to it not me.
            
-
            15:46 < jrandom> (though it seems to have some heavyweight requirements, so maybe not.  unsure, we can see)
            
-
            15:46 < deer> <duck> its very easy; expectation was 1.5h study of ingredients and then 3-4h patching
            
-
            15:46 < fvw> outproxies would be useful yes. As for nontrivial delays, someone who's not already using i2p isn't going to use i2p just for mail when there's mixmaster, whereas someone already using i2p is going to be compromised elsewhere by our lack of delays (if this is possible) anyway
            
-
            15:46 < jrandom> right right, plus ship perl, privoxy, and apache duck ;)
            
-
            15:47 < jrandom> perhaps fvw.  (though i2p 3.0 blah blah blah)
            
-
            15:47 < fvw> hehe, I hesitate to say "good point", but I get what you mean.
            
-
            15:48 < nicktastic> FYI, JES (Java Email Server) provides SMTP and POP3 servers under the GPL
            
-
            15:49 < jrandom> ok, perhaps there should be some more discussion on the list or on the forum about what one or two client apps we should explore focusing on
            
-
            15:49 < jrandom> word nicktastic, there's also a kickass one from apache too
            
-
            15:49 < nicktastic> Nice, know what its called?
            
-
            15:49 < jrandom> http://james.apache.org/
            
-
            15:49 < nicktastic> Thanks
            
-
            15:50 < jrandom> (nntp too (drooool))
            
-
            15:50 < nicktastic> Wow
            
-
            15:50  * nicktastic gets a stiffy
            
-
            15:51  * fvw has joined #i2p-porn. Or at least it feels like that.
            
-
            15:51 < fvw> Ok, next?
            
-
            15:51 < jrandom> ok, we can continue client app discussions and strategizing on the list and in the forums
            
-
            15:51 < nicktastic> Yes
            
-
            15:52 < jrandom> but for now, moving on to 6) ???
            
-
            15:52 < nicktastic> Or during non-meeting hours ;P
            
-
            15:52 < jrandom> anyone have anything else they want to bring up?
            
-
            15:52  * fvw nods. It is worth some discussion on-list.
            
-
            15:52 < deer> <duck> little explanation to the www-inproxy: the idea was to get some ISP(s) to offer such a gateway as a service
            
-
            15:52 < fvw> nah, the list is good. Gives everyone a chance to chime in, not just those who happen to be awake.
            
-
            15:52 < jrandom> word duck, which is quite cool
            
-
            15:52 < deer> <duck> so joe i2p-less-sixpack can access it using his MSIE
            
-
            15:52 < deer> <duck> but the host is anonymous
            
-
            15:52 < deer> <soros> http://it.slashdot.org/article.pl?sid=04/09/14/2226226&threshold=0&tid=172&tid=128&tid=201&tid=218    (ugly new exploit for windows xp)
            
-
            15:52 < jrandom> i2pless!  heretic!  burn them!
            
-
            15:53 < deer> <duck> ISP takes part of the risk, hence the whitelist requirement
            
-
            15:53 < deer> <duck> and ofcourse payment for domain etz
            
-
            15:53 < fvw> hehe. Then suddenly we plaster child porn all over the famous eepsites and watch half the people get arrested and the other half install i2p.
            
-
            15:53 < jrandom> heh
            
-
            15:53 < deer> * duck calls the AIVD
            
-
            15:54 < fvw> duck is dutch? *ponders*
            
-
            15:55 < deer> <duck> I think many clientapps are not really killer
            
-
            15:55 < jrandom> ok, anyone else have anything they want to bring up?
            
-
            15:55 < jrandom> agreed duck, but we need *something* 
            
-
            15:55 < deer> <duck> some self-made smtp tunnel thing is not going to be a big thing
            
-
            15:56 < deer> <duck> myi2p with IOU accounting
            
-
            15:56 < deer> <duck> fvw: Bedankt foor die bloumen
            
-
            15:57 < deer> <soros> "After complaints to NIC.CX (the regulation authority of .cx domains) by an office worker named Rhonda Clarke of Christmas Island, the site goatse.cx was taken down Friday, January 16, 2004. (Goat.cx and Hick.org/Goat remain active.) A petition has even been launched to bring goatse.cx back.  "  
            
-
            15:57 < deer> <soros> i've lost faith in humanity
            
-
            15:57 < deer> <duck> small thing about the site: I2P was added to the <title> of each page for google purposes
            
-
            15:57 < deer> <soros> sorry wrong window
            
-
            15:57 < jrandom> ah ok duck
            
-
            15:57 < deer> <duck> but I dont keep up with the latest google-dance, so it might be worthless.
            
-
            15:57 < jrandom> perhaps if there were a way to explicitly not include it?
            
-
            15:58 < jrandom> (e.g. so we can say "Welcome to I2P.net" instead of "I2P - Welcome to I2P.net", etc)
            
-
            15:58 < deer> <duck> that is ofcourse possible
            
-
            15:58 < deer> * duck looks on the fun-o-meter
            
-
            15:58 < jrandom> we can always just add title = "I2P - How does it work" to menu.ini
            
-
            15:58 < deer> <duck> nope, not today
            
-
            15:58 < deer> <thetower> Oh oh, isn't there some way we can get google to crawl i2p? Like some sort of reverse proxy or something?
            
-
            15:58 < jrandom> yeah, not worth it
            
-
            15:58 < jrandom> thetower with duck's thingamabob, probably.
            
-
            15:59 < deer> <duck> yeah
            
-
            15:59 < fvw> but as mentioned, you probably don't want to be the one running it.
            
-
            15:59 < deer> <thetower> Seems like if eepsites were coming up in google searches that would be good advertising right there.
            
-
            16:00 < deer> <duck> fvw: I have contacted an isp who is interested
            
-
            16:00 < deer> <duck> but he is not going to build it
            
-
            16:00 < jrandom> thetower: perhaps if an ht://dig were hooked up to files.i2p, and if files.i2p exposed the database as big file with html links, that could be mirrored..?
            
-
            16:00 < fvw> duck: really? How large and in which country?
            
-
            16:00 < cervantes> how about a cache instead of a proxy
            
-
            16:00 < cervantes> ah
            
-
            16:00 < deer> <duck> 20cm
            
-
            16:00 < fvw> If I were an ISP and not afraid of the legal problems, I'd still not be interested until I2P was a lot bigger.
            
-
            16:01 < jrandom> a cache would be interesting too, a swarm of squids, etc
            
-
            16:01 < deer> <duck> skynet
            
-
            16:01 < fvw> that's pretty big. Did you give them a phone book to sit on?
            
-
            16:01 < nicktastic> hehe
            
-
            16:01 < deer> <duck> fvw: they'll likely scan the site before adding it
            
-
            16:01 < deer> <duck> so you'll have to find another place for your nasty stuff
            
-
            16:01 < fvw> Once or every update?
            
-
            16:02 < fvw> the latter seems a lot of work for very little content.
            
-
            16:02 < deer> <duck> every 2nd sunday of a month with an x in it
            
-
            16:02 < deer> <duck> geeh
            
-
            16:03 < jrandom> ok, we've gone past the two hour mark, does anyone else have something to bring up, or should we continue further discussions on the list / in the forum / etc?
            
-
            16:03 < fvw> I just find it highly unlikely that a serious ISP will commit resources to I2P at this point.
            
-
            16:03  * cervantes covers his head with a saucepan
            
-
            16:03 < deer> <duck> fvw: your emotions are noted.
            
-
            16:03  * fvw nods at jrandom. I need a drink. Keep up the good work.
            
-
            16:03 < deer> <duck> when will we go for the 24h meeting?
            
-
            16:04 < jrandom> perhaps next week duck 
            
-
            16:04  * jrandom winds up
            
-
            16:04 < deer> <duck> oh boy!
            
-
            16:04 < fvw> duck: my emotions? You haven't even begun to see my emotions. Let me get a few drinks though.. *grin*
            
-
            16:04  * jrandom *baf*s cervantes on the head, closing the meeting
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting108.html b/www.i2p2/pages/meeting108.html
deleted file mode 100644
index a9b37e10..00000000
--- a/www.i2p2/pages/meeting108.html
+++ /dev/null
@@ -1,40 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 108{% endblock %}
-{% block content %}
            I2P dev meeting, September 21, 2004
            
-
            
-
            14:06 < jrandom> 0) hi
            
-
            14:06 < jrandom> 1) Dev status
            
-
            14:06 < jrandom> 2) New userhosts.txt vs. hosts.txt
            
-
            14:06 < jrandom> 3) ???
            
-
            14:06 < jrandom> 0) hi
            
-
            14:06  * jrandom waves
            
-
            14:06 < jrandom> brief weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-September/000449.html
            
-
            14:06 < jrandom> (and probably brief meeting logs to be posted once this is over ;)
            
-
            14:07  * jrandom gives y'all a good 30s to read those notes
            
-
            14:07 < jrandom> anyway, moving on to 1) dev status
            
-
            14:07 < jrandom> basic overview of whats up is in that email
            
-
            14:08 < jrandom> one thing you may notice is that i won't be missing random letters in my text anymore, as my laptop has been a bitch lately
            
-
            14:09 < jrandom> so i'm in the process of moving entirely over to my server (w/ the laptop as backup for windows testing, etc)
            
-
            14:09 < jrandom> thats all i've got to say on that front
            
-
            14:10 < jrandom> anyone have anything they want to bring up wrt 0.4.0.1 or the dev activity?
            
-
            14:11 < deer> <jrandom> no jrandom, we're just lurking
            
-
            14:11 < jrandom> ok, moving on to 2) new userhosts.txt vs. hosts.txt
            
-
            14:11 < protok0l> yey!
            
-
            14:11 < jrandom> minor new feature so people can modify their local naming while still pulling down hosts.txt
            
-
            14:12 < protok0l> which file has priority if they conflict? user i would assume
            
-
            14:13 < jrandom> it'll be rolled out in the next release, so basically just put your local changes in userhosts.txt as hosts.txt will be overridden
            
-
            14:13 < jrandom> userhosts.txt has first preference
            
-
            14:15 < jrandom> ok, thats all i've got for 2, so moving on quickly to our last point- 3) ???
            
-
            14:15 < jrandom> anyone have anything else they want to discuss?
            
-
            14:16 < deer> <Pseudonym> timetable for 0.4.1?
            
-
            14:17 < jrandom> should be out this week, but maybe not until the weekend.
            
-
            14:17 < deer> <Pseudonym> cool
            
-
            14:17 < jrandom> i finally gave up the battle with my laptop after the spacebar died
            
-
            14:17 < jrandom> (codingWithoutSpaces==lame;)
            
-
            14:18 < jrandom> ok, anyone else have anything they want to bring up?  i think we're going for a record meeting time here
            
-
            14:18 < jrandom> (not that thats a problem)
            
-
            14:19 < jrandom> ok, if not
            
-
            14:19  * jrandom winds up
            
-
            14:19  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting109.html b/www.i2p2/pages/meeting109.html
deleted file mode 100644
index 2d9d1a34..00000000
--- a/www.i2p2/pages/meeting109.html
+++ /dev/null
@@ -1,119 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 109{% endblock %}
-{% block content %}
            I2P dev meeting, September 28, 2004
            
-
            
-
            14:08 < jrandom> 0) hi
            
-
            14:08 < jrandom> 1) New transport
            
-
            14:08 < jrandom> 2) 0.4.1 status
            
-
            14:08 < jrandom> 3) ???
            
-
            14:08 < jrandom> 0) hi
            
-
            14:08 < duck> hi
            
-
            14:09 < jrandom> heya
            
-
            14:09 < deer> <ugha2p> Hi.
            
-
            14:09 < deer> <pseudonym> hi
            
-
            14:09 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-September/000454.html
            
-
            14:09 < deer> * ugha2p is looking for the weekly status notes.
            
-
            14:09 < jrandom> (hey, i'm psychic)
            
-
            14:10 < jrandom> ok, jumping in to 1) New transport
            
-
            14:10 < jrandom> the message pretty much covers the main bits
            
-
            14:11 < jrandom> its all working atm, but obviously wont talk to anyone else until the new release is out
            
-
            14:12 < jrandom> i've kicked the tires on it a bit, but its pretty hard to simulate all the possible kooky network problems that occur at the transport level
            
-
            14:12 < deer> <pseudonym> does it include windowsize?
            
-
            14:12 < deer> <ugha2p> 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).
            
-
            14:12 < deer> <ugha2p> Sounds like a potential security hole.
            
-
            14:12 < jrandom> oh, no, this is just the inter-router transport, not the streaming lib, unfortunately
            
-
            14:12 < deer> <pseudonym> ok
            
-
            14:12 < jrandom> in a way ugha, yes
            
-
            14:12 < jrandom> (which is why if people *can* set their IP, they should)
            
-
            14:13 < jrandom> ugha: however, it only 'believes' someone if they have NO connections that work
            
-
            14:13 < deer> <ugha2p> Shouldn't the router listen on 0.0.0.0 in any case?
            
-
            14:13 < jrandom> but someone pretty smart could probabalistically do some evil things
            
-
            14:14 < jrandom> ugha: it does that (almost always)
            
-
            14:14 < jrandom> however, we need to know our IP address so we can put it in our RouterInfo
            
-
            14:14 < jrandom> (since our RouterInfo is verified whenever we contact someone)
            
-
            14:14 < deer> <ugha2p> Ah, ok.
            
-
            14:15 < deer> <ugha2p> I'm sure there are ways to make this more secure (rely on more routers for detecting the IP), but I'm not sure if this is feasible.
            
-
            14:15 < jrandom> yeah ugha, there's trouble down that path, but its a numbers game
            
-
            14:16 < deer> <ugha2p> Anyhow, that was just a suggestion. We can move on.
            
-
            14:16 < jrandom> (however, they could just sybil you and mess up whatever #s you're trying)
            
-
            14:16 < deer> <ugha2p> Right.
            
-
            14:17 < deer> <ugha2p> What if the router loses all connections (eg, network failure)?
            
-
            14:17 < deer> <ugha2p> Does it redetect its IP?
            
-
            14:18 < jrandom> the IP is transmitted as part of the protocol on all connection attempts, the peer just decides to honor it if 1) no ip was explicitly set 2) there are no active TCP connections
            
-
            14:18 < deer> <ugha2p> (This would be the case with dynamic IPs)
            
-
            14:18 < jrandom> right, it'll work fine with that
            
-
            14:18 < deer> <ugha2p> Ah, ok.
            
-
            14:19 < jrandom> (see ourAddressReceived(String addr) in TCPTransport.java for the details)
            
-
            14:19 < deer> <pseudonym> what happens when reported IPs don't match?
            
-
            14:19 < jrandom> pseudonym: if you already have active TCP connections, you ignore what other people tell you
            
-
            14:20 < jrandom> if you dont have active TCP connections, you tear down the old listener and start up a new one with the new address given
            
-
            14:20 < jrandom> (updating your routerInfo)
            
-
            14:22 < deer> <pseudonym> if there are active conns, it seems like a mismatch should be a red flag
            
-
            14:22 < deer> <pseudonym> (I'm not sure what to do with it)
            
-
            14:22 < jrandom> if someone gives us the wrong IP address (and we *know* its the wrong IP address, since we already have the right one - that *works*) we ignore it
            
-
            14:23 < deer> <ugha2p> Too bad we can no longer reduce the router's reliability ranking.
            
-
            14:23 < jrandom> we can add that to the list of connection errors though
            
-
            14:24 < jrandom> ugha: but we can shitlist 'em ;)
            
-
            14:24 < jrandom> (and we do)
            
-
            14:24 < deer> <pseudonym> how do we know the one we already have is "right"?  maybe the existing conns are from black hats
            
-
            14:24 < deer> <pseudonym> especially if we have few or only recent conns
            
-
            14:24 < jrandom> pseudonym: the existing connections are "right" in that they can send and receive data
            
-
            14:24 < deer> <ugha2p> pseudonym: We can be sure when we get new inbound connections, although those can be spoofed as well.
            
-
            14:25 < jrandom> right, if we're talking about someone concerned with an active IP spoofing attack in addition to sybil...
            
-
            14:25 < jrandom> well, that person can simply set their IP address ;)
            
-
            14:25 < deer> <ugha2p> :)
            
-
            14:26 < deer> <pseudonym> but what's the likelyhood that the operator will even know what's happening
            
-
            14:26 < deer> <pseudonym> if we get a lot of mismatches there should be some active alert
            
-
            14:27 < deer> <pseudonym> (this may be something to worry about in a later release, but since it came up...)
            
-
            14:27 < jrandom> we can add an explicit message to the list of connection errors
            
-
            14:27 < jrandom> the only real concern here is that we're trying to prevent a restricted route from being formed
            
-
            14:27 < jrandom> (and the extreme of that being a full network partition)
            
-
            14:30 < jrandom> thats about all i can see us working to deal with for now, at least until the 2.0 rev when we need to worry beyond the restricted route
            
-
            14:30 < jrandom> ok, anyone else have anything wrt the new transport?
            
-
            14:31 < jrandom> if not, moving on to 2) 0.4.1 status
            
-
            14:31 < jrandom> all the "necessary" stuff is done, but theres still some debugging and minor updates to get in
            
-
            14:32 < jrandom> current target is a thursday release, but we'll see what gets added or removed from the rev ;)
            
-
            14:33 < jrandom> one thing that would be cool is if someone could download a jetty install, check out the jetty.xml config file, and could write up some docs on how to run a jetty instance (for an eepsite/etc) with what is shipped with i2p
            
-
            14:33 < deer> <ugha2p> Does 0.4.1 include other updates than the new TCP transport?
            
-
            14:33 < jrandom> not really ugha :)
            
-
            14:34 < deer> <pseudonym> is it backward compatible?
            
-
            14:34 < jrandom> (see: www.i2p.net/roadmap )
            
-
            14:34 < jrandom> no, it is not backwards compatible
            
-
            14:34 < deer> <ugha2p> :)
            
-
            14:36 < jrandom> ok, thats all ive got to mention wrt 0.4.1.. anything else on that?
            
-
            14:36 < jrandom> if not, we're on to ol' faithful: 3) ???
            
-
            14:36 < deer> <ugha2p> *silence*
            
-
            14:37 < jrandom> anyone have anything else (i2p related) they want to bring up?
            
-
            14:37 < jrandom> we're already twice as long as last week's meeting ;)
            
-
            14:37 < deer> <ugha2p> Well, I could mention that thanks to cervantes, my Wiki now has an outproxy to the real world, through http://ugha.ath.cx/
            
-
            14:38 < deer> * pseudonym is a troublemaker
            
-
            14:38 < jrandom> ooh right, v.cool
            
-
            14:38 < jrandom> s/outproxy/inproxy/ :)
            
-
            14:38  * jrandom sends the troublemaker to the corner
            
-
            14:38 < deer> <ugha2p> Right, inproxy. :)
            
-
            14:40 < jrandom> ok, if there's nothing else
            
-
            14:40 < deer> <pseudonym> I think the new mail service from the postmaster is pretty cool
            
-
            14:40 < jrandom> oh, definitely agreed
            
-
            14:40 < deer> <pseudonym> er, postman
            
-
            14:41 < deer> * ugha2p has yet to sign up.
            
-
            14:41 < deer> <baffled> has anyone heard anything of stasher recently?
            
-
            14:41 < jrandom> its nice that it works with both telnet and kmail:)
            
-
            14:41 < jrandom> naw baffled, havent heard a peep
            
-
            14:42 < deer> <baffled> I guess aum needs a boot to the head.
            
-
            14:42 < deer> <ugha2p> I would probably write a page about EepMailAnonymity, but I don't know too much about SMTP/POP3/IMAP/other e-mail-related stuff.
            
-
            14:42 < jrandom> not the head, the butt ;)
            
-
            14:43 < jrandom> ugha: www.postman.i2p has a few pages about that
            
-
            14:43 < deer> <ugha2p> Ah.
            
-
            14:43 < deer> <baffled> they may be the same.
            
-
            14:45 < deer> * ugha2p taps his fingers waiting for the baf.
            
-
            14:45 < jrandom> sorry, nearly passed out here (loong day)
            
-
            14:46 < jrandom> anything else?  if not, we've got the forum and the list
            
-
            14:46 < duck> thanks to Mi-Go we have an updated i2ptunnel page
            
-
            14:46 < duck> it is almost perfect
            
-
            14:46 < jrandom> ooh nice
            
-
            14:46 < duck> but if someone has some improvements, you know where to find me
            
-
            14:47  * jrandom traceroutes
            
-
            14:47  * jrandom winds up
            
-
            14:47  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting11.html b/www.i2p2/pages/meeting11.html
deleted file mode 100644
index 7ec568b8..00000000
--- a/www.i2p2/pages/meeting11.html
+++ /dev/null
@@ -1,161 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 11{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 11
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Sep 17 22:59:26 2002
-
            23:01 -!- mode/#iip-dev [+v logger] by mids
-
            23:54  * Roto waves
-
            23:54 <@mids> ssh, we arent started :)
-
            23:55 < Lorax> Heh, I am already logged.
-
            23:56  * Lorax waves to any SRHers.
-
            23:59 < Lorax> anyway, if IIP could pass psudonymous keys then SSL can be used, as it's the connection that is secure, not the conversation.  (Unless you have previously established socially satisfactory identification exchange.)
-
            --- Day changed Wed Sep 18 2002
-
            00:00 <@mids> hush
-
            00:01 <@mids> we start in 1 hour
-
            00:01 < Lorax> but we are here now.
-
            00:01 <@mids> but the others aint
-
            00:01 <@mids> its not fair to start :)
-
            00:01 -!- mode/#iip-dev [+m] by mids
-
            00:02 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: not started
-
            00:03 <@Chocolate> starting in about 1 hour
-
            00:04 -!- mode/#iip-dev [-m] by Chocolate
-
            00:23 < Lorax> Why are the logs recording to a website already then?  hrm?  ;)
-
            00:23 <+logger> we are testing the live nsa wiretap
-
            00:24 < Lorax> ah, that is senseable.
-
            00:51 < nop> hi
-
            00:51 < Roto> hulloz
-
            00:53 < thecrypto> hello
-
            00:53 < nop> http://www.techtv.com/screensavers/supergeek/story/0,24330,3347481,00.html
-
            00:53 < nop> friend of mine
-
            00:54 -!- mode/#iip-dev [+o codeshark] by Trent
-
            00:54 < nop> just got back from a deposition
-
            01:00 <@mids> Tue Sep 17 23:00:09 UTC 2002
-
            01:00 <@mids> Welcome everybody
-
            01:00 <@mids> this is the 11th IIP meeting
-
            01:00 <@mids> maybe more, but then I lost count
-
            01:00 <@mids> :)
-
            01:00 <@mids> Agenda for now:
-
            01:00 <@mids> rc2 status update
-
            01:00 <@mids> website
-
            01:00 <@mids> open mic
-
            01:01 <@mids> .
-
            01:01 < Roto> .
-
            01:01 <@mids> nop is on the phone, but he might drop in
-
            01:01 <@mids> like you all know, rc2 has been 'almost there' for a long time
-
            01:01 <@mids> but it didnt work
-
            01:01 <@mids> now it does better :)
-
            01:01 <@mids> userx fixed some bugs with the end-end crypto
-
            01:02 <@mids> and with the 1.1 protocol
-
            01:02 <@mids> I tested it this weekend, and it works great
-
            01:02 <@mids> you can even do 2048 bit encryption etc
-
            01:02 <@mids> so, one step closer to the release
-
            01:02 <@mids> (heh we did say that often)
-
            01:02 <@mids> .
-
            01:03 < codeshark2> what is needed for the release? except the inform stuff?
-
            01:03 -!- codeshark is now known as nickthief53256
-
            01:03 -!- codeshark2 is now known as codeshark
-
            01:03 <@mids> only some minor things: fixup of the commandline help
-
            01:03 <@mids> manpage check
-
            01:04 <@mids> cant think about more
-
            01:04 -!- mode/#iip-dev [+o codeshark] by Trent
-
            01:04 <@codeshark> so, the source is ready
-
            01:04 <@mids> I'd say so
-
            01:05 <@codeshark> ok, i think we should create a build for internal testing then
-
            01:05 <@codeshark> .
-
            01:05 <@mids> ack (pending nops status)
-
            01:05 <@codeshark> and set up inform for the new protocol
-
            01:06 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: RC2
-
            01:06 <@mids> more rc2?
-
            01:06 <@codeshark> another thing we should discuss is: version numbers
-
            01:06 <@codeshark> why call it rc2 ;)
-
            01:06 <@codeshark> .
-
            01:06 <@mids> release candidate
-
            01:07 <@codeshark> yeah sure, but we changed a lot of stuff between rc1 and rc3
-
            01:07 <@codeshark> rc2
-
            01:07 <@mids> yes we did
-
            01:07 <@mids> it aint proper naming this way
-
            01:07 <@mids> based on the changes we should be at 1.3 now
-
            01:08 <@codeshark> yes
-
            01:08 <@codeshark> we could call it 1.3 RC-2 (and then make a final 1.3 soon)
-
            01:08 <@mids> nah
-
            01:09 <@mids> I'd say continue with the numbering like we do now
-
            01:09 <@mids> and in the future, release more often
-
            01:10 <@codeshark> ack
-
            01:10 <@mids> .
-
            01:10 <@codeshark> .
-
            01:10 <@mids> next thing: website
-
            01:10 <@mids> nop reviewed most text, some stuff is reworded
-
            01:11 <@mids> ellison (the designer) is now making a layout for the support page
-
            01:11 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: website
-
            01:11 <@mids> should be there in a week
-
            01:12 <@mids> the latest version of the site is on http://mids.student.utwente.nl/~mids/iip/www/
-
            01:12 <@mids> and in CVS ofcourse
-
            01:12 <@mids> .
-
            01:12 <@mids> site should be up soon too
-
            01:12 <@mids> .
-
            01:13  * mids hands the mic over to codeshark 
-
            01:13 <@codeshark> nothing to add ;)
-
            01:13 <@codeshark> .
-
            01:13 <@mids> yes you do
-
            01:13 <@codeshark> i do?
-
            01:13 <@mids> tell em about your work with the public nodes
-
            01:13 <@codeshark> about the website?
-
            01:13 <@codeshark> ok
-
            01:13 <@mids> how you rescued 2000
-
            01:13 <@codeshark> 23
-
            01:14 <@codeshark> our inform server does very strict checking on the relay nodes: our list has been reduced to about 6 nodes
-
            01:15 <@codeshark> i disabled one of these checks to allow nodes to be down more often
-
            01:15 <@codeshark> and most important:
-
            01:15 <@codeshark> i rescued all nodes ever added to inform and checked if they're still up
-
            01:16 <@codeshark> now, we have 23 nodes in our list
-
            01:16 <@codeshark> .
-
            01:16 < _42> how are nodes added to inform?
-
            01:16 < nop> awesom
-
            01:16 < nop> when you announce
-
            01:16 < nop> it sends a message to inform
-
            01:17 <@codeshark> just for the statist guys here: i added 1125 hosts from the log
-
            01:17 < nop> you know that's a lot of downloads ;)
-
            01:18 <@codeshark> about 300 of them were valid (dns resolves...) and unique hosts
-
            01:18 <@codeshark> .
-
            01:18 <@mids> currently we have 9 nodes on the list... in about 5 days (after the inform testing) that will be 23 (if they keep up)
-
            01:18 <@mids> .
-
            01:19 <@codeshark> right now 22/23 are up
-
            01:19 <@codeshark> .
-
            01:19 -!- mids changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: hurray for the saviour of the public nodes
-
            01:20 < Roto> .
-
            01:20 <@mids> okay, I am out of agenda items
-
            01:20 < nop> rc2
-
            01:20 <@mids> maybe nop has something to add
-
            01:20 < nop> rc2 will be released with website release
-
            01:20 < nop> we will be spending this week thoroughly testing it from a developer's standpoint
-
            01:20 <@codeshark> nop: we should create an internal build of rc2 asap
-
            01:21 < nop> agreed
-
            01:21 < _42> What new features will be added to rc2?
-
            01:21 <@codeshark> so we can set up the network and test inform
-
            01:21 < nop> Perfect Forward Security
-
            01:21 < nop> 160 bit encryption end to end
-
            01:21 < nop> 1536 bit network id
-
            01:21 < nop> 2048 bit PFS keys
-
            01:21 <@codeshark> .
-
            01:21 < nop> and all around just general bug fixes
-
            01:21 < nop> I will get a changelog
-
            01:22 < nop> .
-
            01:23 <@mids> I guess its open microphone time
-
            01:24 <@mids> you can reread the chatlogs of this and the previous meetings on http://mids.student.utwente.nl/~mids/iip/
-
            01:24 <@mids> questions? (I know that Lorax had some... :)
-
            01:25 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: open mic
-
            01:25 <@Chocolate> Lorax timed out
-
            01:25 <@mids> I know :)
-
            01:26  * Roto cheerleads
-
            01:26 <@Chocolate> I'd like to raise the issue of saner version numbers
-
            01:27 <@Chocolate> the feature changes from rc1 to rc2 where realy a minor version increment, not updates to a beta release
-
            01:30 <@mids> the updates got out of hand
-
            01:30 <@mids> for the common good.. but that is no excuse :)
-
            01:37 <+logger> official part is over, if you got more questions; ask here or in #iip
-
            01:37 <+logger> cya next week
-
            --- Log closed Wed Sep 18 01:37:46 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting110.html b/www.i2p2/pages/meeting110.html
deleted file mode 100644
index 9356ffa8..00000000
--- a/www.i2p2/pages/meeting110.html
+++ /dev/null
@@ -1,186 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 110{% endblock %}
-{% block content %}
            I2P dev meeting, October 5, 2004
            
-
            
-
            14:05 < jrandom> 0) hi
            
-
            14:05 < jrandom> 1) 0.4.1.1 status
            
-
            14:05 < jrandom> 2) Pretty pictures
            
-
            14:05 < jrandom> 3) 0.4.1.2 and 0.4.2
            
-
            14:05 < jrandom> 4) Bundled eepserver
            
-
            14:05 < jrandom> 5) ???
            
-
            14:05 < jrandom> 0) hi
            
-
            14:05  * jrandom waves
            
-
            14:05 < jrandom> weekly status notes are available at http://dev.i2p.net/pipermail/i2p/2004-October/000461.html
            
-
            14:06 < jrandom> (i cant believe its october)
            
-
            14:06 < cervantes> it's december
            
-
            14:06  * jrandom disconnects from cervantes.  excess clock skew
            
-
            14:06 < deer> <baffled> could we have summer back now?
            
-
            14:07 < cervantes> damn...lost your pr0n feed
            
-
            14:07 < jrandom> sure. its a few thousand KM south of you baffled
            
-
            14:07 < jrandom> ok, jumping into 1) 0.4.1.1 status
            
-
            14:07 < deer> <baffled> will you let me know when I get there?
            
-
            14:07 < cervantes> heh
            
-
            14:07 < jrandom> click your heels three times...
            
-
            14:08 < jrandom> ok, the 0.4.1 and 0.4.1.1 revs are out, and things are pretty much working again
            
-
            14:08 < deer> <baffled> no, no, I don't want to go home it's cold there.
            
-
            14:08 < jrandom> ;)
            
-
            14:08 < jrandom> the autodetection of the external IP address seems to be working for the most part
            
-
            14:09 < jrandom> (there have been a few quirks though, due to b0rked connections that don't hang up properly)
            
-
            14:09 < jrandom> have people been using that, or had good/bad experiences with the autodetection?
            
-
            14:10 < jrandom> guess not
            
-
            14:10 < jrandom> ok, anyone have any comments/questions/concerns wrt 0.4.1.1?
            
-
            14:11 < cervantes> no complaints here....
            
-
            14:11 < dm> Haven't tried it yet, but it's on my agenda!
            
-
            14:11 < jrandom> if not, swingin on to 2) pretty pictures
            
-
            14:11 < jrandom> !thwap dm
            
-
            14:12 < deer> <Jake> dunno about autodetection, but i tried using the 'guess' button or whatever on my natted windows box and it guessed the ip right...... if thats what wer're talking bout
            
-
            14:12 < jrandom> ah ok, naw, the 'guess' button just tries to guess your IP by querying www.whatismyip.com
            
-
            14:13 < jrandom> the autodetection is where you leave the IP address field blank and it figures it out by itself
            
-
            14:13 < jrandom> most existing I2P users won't need it, since we're all used to either dyndns or static IPs anyway
            
-
            14:13 < jrandom> it'll probably only matter for new users
            
-
            14:14 < deer> <demonic_1> yea that worked a little slow for me
            
-
            14:14 < deer> <demonic_1> but it did work
            
-
            14:15 < jrandom> ok cool
            
-
            14:15 < jrandom> anyway, i dont want to rehash what i posed in this weeks email wrt the stats gathered
            
-
            14:16 < jrandom> instead, does anyone have any questions/comments/concerns about them?
            
-
            14:17 < jrandom> i was pretty glad to see the 20h summary had only 500-something send failures out of 30,000-ish
            
-
            14:17 < cervantes> how much load does the stats collecting generate?
            
-
            14:17 < cervantes> I know the filesizes...but will it impact on performance having it ticking in the background
            
-
            14:18 < jrandom> should be ~= 0.  there's no memory allocation in the stat gathering (as we use preallocated events) and everything is async
            
-
            14:18 < cervantes> cool
            
-
            14:18 -!- Sugadude [random@badfish.securityminded.net] has joined #i2p
            
-
            14:18 -!- cat-a-puss [~tom@152.228.242.159] has joined #i2p
            
-
            14:19 < jrandom> once 0.4.1.2 is outi'll probably nag some more people to gather various stats at times
            
-
            14:19 < deer> <mule_iip> you're welcome
            
-
            14:19 < cervantes> I'm happy to start collecting now... I'm already on 0.4.1.1-6
            
-
            14:20 < jrandom> w3wt
            
-
            14:21 < jrandom> ok, thats all i've got for the stats, unless anyone has anything to add?
            
-
            14:21 < jrandom> if not, 3) 0.4.1.2 and 0.4.2
            
-
            14:21 < deer> <baffled> You have my vote for streaming first.
            
-
            14:22 < jrandom> cool
            
-
            14:22 < jrandom> does anyone think we should keep the tunnel mods first?
            
-
            14:22 < deer> <mule_iip> streaming first
            
-
            14:23 < cervantes> doing the tunnel stuff now would likely cause more network distruption....it's probably good to have a breather ;-)
            
-
            14:23 < jrandom> true
            
-
            14:23 < deer> <mule_iip> all of those here today have been identified by the black hats anyhow :)
            
-
            14:23 < jrandom> though i was thinking the other day about how we could do the tunnel mods without incompatabilities
            
-
            14:23 < deer> <baffled> Comeon admit it, you just want to get your audio p0rn faster.
            
-
            14:23 < duck> (me too on streaming first)
            
-
            14:23 < jrandom> hehe
            
-
            14:24 < cervantes> hehe
            
-
            14:24 < cervantes> baffled: only if you source more of it ;-)
            
-
            14:24 < dm> I think we should stick to the tunnel stuff first
            
-
            14:24 < dm> get it out of the way...
            
-
            14:24 < cat-a-puss> how is the new encryption stuff going to be different?
            
-
            14:24  * jrandom kicks dm
            
-
            14:25 < jrandom> cat-a-puss: right now, we have blanket tunnel encryption - messages passed within the same tunnel look the same at each hop
            
-
            14:25 < deer> <baffled> I think I can get a bit more.
            
-
            14:25 < cat-a-puss> oh!
            
-
            14:26 < cervantes> http://www.i2p.net/todo#tunnelId
            
-
            14:26 < jrandom> it isn't so bad since an alice-->bob message goes through two tunnels with different encryption, but it does b0rk us for colluding attackers
            
-
            14:27 < jrandom> the per-hop tunnelId stuff is also necessary to keep harvesting from messing with predecessors (/etc)
            
-
            14:27 < dm> Yeah, we should definitely fix that first.
            
-
            14:27 < deer> <mule_iip> i vote for dm to do it
            
-
            14:28 < deer> <fidd> did i miss the meeting? ;)
            
-
            14:28 < jrandom> i was just about to suggest that mule :)
            
-
            14:28 < cervantes> I vote for dm not to have anything to do with it
            
-
            14:28 < jrandom> heh
            
-
            14:28 < jrandom> nope fidd, we're on item 3 of the agenda
            
-
            14:29 < jrandom> ok, if there are no objections to dm's suggestion (other than his own), i think we'll go ahead and move the streaming lib updates to 0.4.2 
            
-
            14:29 < dm> sweet
            
-
            14:30 < jrandom> ok, moving on to 4) Bundled eepserver
            
-
            14:30 < jrandom> if you haven't noticed, there's a bundled eepserver.
            
-
            14:30 < cervantes> "just put the war files in the webapps directory and you're ready to go"
            
-
            14:30 < jrandom> heh
            
-
            14:30 < jrandom> for sufficiently well coded .war files :)
            
-
            14:31 < cervantes> ooh does such a think exist?
            
-
            14:31 < cervantes> *thing
            
-
            14:31 < jrandom> but from a practical perspective, "just edit ./eepsite/docroot/index.html"
            
-
            14:31 < deer> <baffled> One question I have is are you wishing people would use the eepserver or use a standard httpd server?
            
-
            14:31 < cat-a-puss> do the ones generated by kde work?
            
-
            14:31 < jrandom> cervantes: phttprelay.war, i2ptunnel.war, routerconsole.war :)
            
-
            14:31 < dm> ah yes.. war. One of those J2EE things that requires 20 years experience at manually editing xml files.
            
-
            14:31 < cervantes> touche
            
-
            14:32 < jrandom> baffled: i really don't care.  if people have a webserver installed that can accept requests from kooky Host: lines, great
            
-
            14:32 < jrandom> the eepserver is just for convenience
            
-
            14:32 < jrandom> cat-a-puss: hmm, kde .war files?
            
-
            14:32 < protok0l> monoculture... monoculture...
            
-
            14:33 < deer> <duck> when playing with wars, I miss the feature to only restart jetty; which is unfortunately needed for a lot of deployment stuff
            
-
            14:33 < cat-a-puss> yeah, you need kdeaddons installed, just go to a webpage and then click archive and it makes a .war file
            
-
            14:34 < jrandom> duck: ah, thats true.  simply pull out the lines starting the eepserver from clients.config and put them into a shell script
            
-
            14:34 < jrandom> (with the same classpath as the router)
            
-
            14:34 < dm> can we integrate i2p into jboss and bundle that before 1.0?
            
-
            14:34 < jrandom> ooh, cool cat-a-puss 
            
-
            14:35 < cervantes> I take it the missing webdefault.xml has been fixed in cvs?
            
-
            14:35 < deer> <detonate> actually, jetty.xml has
            
-
            14:35 < jrandom> find us a compelling .ear dm :)
            
-
            14:35 < jrandom> cervantes: what detonate said.  (i messed up the jetty.xml)
            
-
            14:36 < cervantes> yup... think I mentioned somewhere about removing the reference in the jetty.xml so it uses it the one inside the jetty archive
            
-
            14:36 < jrandom> wr0d
            
-
            14:37 < cervantes> just wanted to check that's been fixed in cvs ;-)
            
-
            14:37 < jrandom> si sr
            
-
            14:37 < cervantes> cool
            
-
            14:37 < jrandom> (though the 0.4.1.2 release update will not overwrite people's eepsite)
            
-
            14:37 < jrandom> ((0.4.1.2+ clean installs will of course include it though))
            
-
            14:38 < cervantes> oh and did we discover the cause of DrWoo's missing eepsite keys?
            
-
            14:38 < jrandom> actually, on that note, i just want to mention that everyone should upgrade whenever there is a new release, as if you don't, you might not have an upgrade procedure
            
-
            14:38 < jrandom> no cervantes, nor a reproducable bug :/
            
-
            14:39 < cervantes> ah good we can blame user error ;-)
            
-
            14:39 < deer> <DrWoo> cervantes: almost certainly something klutzy I did
            
-
            14:39 < cervantes> :o)
            
-
            14:39  * jrandom blames the gremlins
            
-
            14:40 < deer> <Jake> http://en.wikipedia.org/wiki/User:Kmweber/List_of_Everyone_Who_Has_Ever_Lived
            
-
            14:40 < jrandom> ok, moving on to 5) ???
            
-
            14:40 < jrandom> heh
            
-
            14:40 < jrandom> well, yes, that certainly qualifies as "other"
            
-
            14:40 < jrandom> anyone have anything they want to bring up?
            
-
            14:41 < dm> I'd like to put forward, at this point, that I am pleased with the new outlook the I2P community is showing towards my suggestions.
            
-
            14:41 < dm> Kind Regards
            
-
            14:41 < cat-a-puss> oh oh pick me! I have the base code for a distrubuted search.
            
-
            14:41 < deer> <demonic_1> yea why do i2p after running 30 + hours go up to 100% cpu
            
-
            14:41 < dm> dm
            
-
            14:41 < deer> <Jake> yes, i want to bring up the issue of encryption inheritence based on 4th order gamal fractal equations and how it would apply to i2p
            
-
            14:41 < deer> <demonic_1> and most of it system?
            
-
            14:41 < jrandom> ooh kickass cat-a-puss!
            
-
            14:41 < cat-a-puss> I anounced it here the other day, nobody noticed
            
-
            14:41 < deer> <baffled> only tangentially jake.
            
-
            14:42 < cat-a-puss> anyway, could use come cvs space
            
-
            14:42 < deer> <DrWoo> cat-a-puss: do you have an eepsite for that?
            
-
            14:42 < jrandom> demonic_1: hmm, there have been some critical bugs in the last release or two.  are you on 0.4.1.1?
            
-
            14:42 < cat-a-puss> and I can start testing in about 2 weeks
            
-
            14:42 < cat-a-puss> DrWoo: nope
            
-
            14:42 < deer> <Jake> baffled, HaH !
            
-
            14:43 < deer> <demonic_1> 0.4.1.1-3
            
-
            14:43 < jrandom> cat-a-puss: r0x0r, not a problem.  bounce me an email with the name of the module you'd like it called & your pgp key and we'll get something sorted
            
-
            14:44 < cat-a-puss> jrandom: alright
            
-
            14:44 < jrandom> cat-a-puss: what sort of searching does it do?
            
-
            14:44 < jrandom> demonic_1: did it consume that much CPU prior to 0.4.1?
            
-
            14:44 < cervantes> (proxies to MSN)
            
-
            14:44 < deer> <mule_iip> demonic_1: and you get 1 meg of log every minute? sounds familiar.
            
-
            14:45 < deer> <demonic_1> no
            
-
            14:45 < jrandom> heh mule, yeah the bug you found was a nasty fast-busy
            
-
            14:45 < cat-a-puss> jrandom: it's basic keywork search, you need to specify the words to index under, and it will store the URL
            
-
            14:45 < jrandom> demonic is more likely being hit by one of the NPEs in the tcp.ConnectionBuilder
            
-
            14:46 < deer> <baffled> Well, it's dindin time so I'll go hunt up some more slut sounds in preparation for the streaming updates and chat with you all anon.
            
-
            14:46 < cat-a-puss> jrandom: It should eventualy scale well, and all that jazz, but right now, all the servers need to be connected and nobody can join or leave, and there is no way to insert content yet, but all that will get fixed
            
-
            14:46 < jrandom> ah cool, does it work with a distributed db, or is it more of a search-against-spidered?
            
-
            14:47 < jrandom> ok cool
            
-
            14:47 < cervantes> later baffled
            
-
            14:47 < jrandom> lol, ttyl baffled
            
-
            14:47 < cervantes> baffled: how do we know they're slut sounds, and not you on the end of your microphone?
            
-
            14:47 < protok0l> ALL RIGHT!
            
-
            14:47 < protok0l> i2p works again
            
-
            14:47 < jrandom> w3wt
            
-
            14:48 < jrandom> what was wrong?
            
-
            14:49 < jrandom> ok, anyone else have anything they want to bring up for the meeting?
            
-
            14:49 < deer> <Jake> can announce i2p to slashdot after the new streaming protocol is implemented ?
            
-
            14:49 < dm> preferably before
            
-
            14:49 < dm> but after will do
            
-
            14:49 < jrandom> !thwap^2
            
-
            14:50 < protok0l> POSTMAN!
            
-
            14:50 < jrandom> ok, if there's nothing else..
            
-
            14:50  * jrandom winds up
            
-
            14:51 < deer> * Jake kisses jrandom 
            
-
            14:51  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting111.html b/www.i2p2/pages/meeting111.html
deleted file mode 100644
index 810feb57..00000000
--- a/www.i2p2/pages/meeting111.html
+++ /dev/null
@@ -1,201 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 111{% endblock %}
-{% block content %}
            I2P dev meeting, October 12, 2004
            
-
            
-
            14:04 < jrandom> 0) hi
            
-
            14:04 < jrandom> 1) 0.4.1.2
            
-
            14:04 < jrandom> 2) 0.4.1.3
            
-
            14:05 < jrandom> 3) 0.4.2
            
-
            14:05 < jrandom> 4) mail discussions
            
-
            14:05 < jrandom> 5) ???
            
-
            14:05 < jrandom> 0) hi
            
-
            14:05  * jrandom waves
            
-
            14:05 < Janonymous> hello
            
-
            14:05 < jrandom> lots of #s in our agenda this week
            
-
            14:05 < jrandom> weekly status notes up @ http://i2p.net/pipermail/i2p/2004-October/000466.html
            
-
            14:05 < jrandom> (posted a min or three ago)
            
-
            14:05 < deer> * cervantes has brought a pillow
            
-
            14:06 < jrandom> oh i hope it won't be that boring ;)
            
-
            14:06 < jrandom> anyway, jumping on in to the good stuff: 1) 0.4.1.2
            
-
            14:06 < deer> <cervantes> make me up after the statistal analysis section
            
-
            14:06 < jrandom> the release is out and everyone should upgrade
            
-
            14:06 < jrandom> heh
            
-
            14:06 < deer> <cervantes> eerm wake
            
-
            14:07 < jrandom> there are some bugs with the watchdog code, which will kill your router poorly (rather than restart it when bad stuff happens)
            
-
            14:07 < jrandom> but hopefully those situations are few and far between
            
-
            14:07 < deer> <mule_iip> nope :(
            
-
            14:08 < jrandom> well, it varies by the user
            
-
            14:08 < jrandom> i'm trying to find the cause, as its been around forever and its pretty annoying
            
-
            14:08 < jrandom> (the actual hang, not the watchdog code that detects the hang)
            
-
            14:09 < jrandom> the current CVS rev (0.4.1.2-1) has the 'meat' of the watchdog disabled - it monitors, but oesn't shut down the router
            
-
            14:10 < jrandom> but 0.4.1.2 should be fine for everyone (except mule ;)
            
-
            14:10 < jrandom> oh, as mentioned before, start up some logging and send me some data, per http://dev.i2p.net/pipermail/i2p/2004-October/000465.html
            
-
            14:11 < jrandom> the more data the better - if you can leave it running overnight, that'd be great (a 20h run on duck's box generated ~60MB of data)
            
-
            14:11 < jrandom> ok, moving on to 2) 0.4.1.3
            
-
            14:12 < jrandom> well, there's not really anything i want to mention beyond wahts in the email
            
-
            14:12 < jrandom> anyone have anything they want to say re: 0.4.1.3?
            
-
            14:12 < Janonymous> nah
            
-
            14:13 < deer> <postman> no
            
-
            14:13 < Janonymous> backwards compatable?
            
-
            14:13 < jrandom> certainly
            
-
            14:13 < jrandom> ok, moving on to * 3) 0.4.2
            
-
            14:14 < jrandom> again, another "see the email" :)
            
-
            14:14 < Janonymous> xpc vs. tcp ??
            
-
            14:14 < jrandom> i've never implemented a tcp stack before, so any guidance would be appreciated
            
-
            14:15 < jrandom> xcp has better handling in networks with high delays
            
-
            14:15 < jrandom> (for congestion control)
            
-
            14:15 < Janonymous> does that include fec?
            
-
            14:15 < jrandom> no
            
-
            14:16 < Janonymous> k, cause I've been researching that some
            
-
            14:17 < jrandom> cool
            
-
            14:17 < jrandom> anything good you've found?
            
-
            14:17 < deer> <cervantes> most GET requests are sub 32kb...and your average html page should be around that size...so I'd imagine eepsurfing will be much improved... - I wouldn't mind seeing an improvement in per-tunnel throughput though...will the new stack improve upon that?
            
-
            14:17 < Janonymous> fec is used a lot for high latency/high throughput networks
            
-
            14:18 < deer> <mule_iip> jrandom: nor have i, but i could tell a folk here to support you
            
-
            14:18 < Janonymous> jrandom: some.. I'll report back
            
-
            14:18 < deer> <mule_iip> at least it would be a good learning experience for him and another pair of eyes
            
-
            14:18 < jrandom> great Janonymous 
            
-
            14:18 < jrandom> oh kickass mule
            
-
            14:18 < jrandom> cervantes: per-tunnel throughput would improve with >1 message windows
            
-
            14:19 < jrandom> (i expect we'll be able to even start with >1 as a window size, depending upon what we can gleam from the router)
            
-
            14:19 < jrandom> ((ecn++))
            
-
            14:19 < deer> <cervantes> grand
            
-
            14:20 < jrandom> ok, anything else on 0.4.2 stuff?
            
-
            14:20 < Janonymous> fresh stack.. fresh laptop.. *drools*
            
-
            14:21 < jrandom> heh
            
-
            14:21 < Janonymous> yea
            
-
            14:21 < Janonymous> one thing
            
-
            14:22 < Janonymous> this will implement the new short handshake?
            
-
            14:22 < jrandom> hmm?
            
-
            14:22 < jrandom> we have the low-cpu TCP reconnection code in the 0.4.1 transport
            
-
            14:22 < Janonymous> ah, in the email, you mention the alice-> bob handshake
            
-
            14:23 < Janonymous> ah
            
-
            14:23 < Janonymous> still catching up
            
-
            14:23 < jrandom> oh.  yeah, whatever 0.4.2 comes up with, it'll support a packet sequence like the one in the email
            
-
            14:24 < Janonymous> k
            
-
            14:24 < jrandom> we'll probably control it largely through socket options (e.g. set the stream to interactive and it sends asap, set the stream to bulk and it only sends when the buffer is full or itsflushed [or it needs to ack])
            
-
            14:25 < jrandom> ok, swinging on to 4) mail discussion
            
-
            14:25 < jrandom> postman - you 'round?
            
-
            14:26 < deer> <postman> ya
            
-
            14:26 < jrandom> word, wanna give us a run down / update wrt the mail stuff?
            
-
            14:27 < deer> <postman> hmm, ok tho i am quite shy talking in front of that many ppl :)
            
-
            14:27 < jrandom> heh just imagine we're all nak^H^H^Her... nm
            
-
            14:28  * Janonymous gets popcorn out
            
-
            14:28 < deer> <postman> since the 20th od september there is a SMTP/POP Service running - accessible with normal smtp/pop3 MUAs
            
-
            14:29 < deer> <postman> i put quite some efforts in it in a way that i analyzed the potential risks that normal mail clients bear
            
-
            14:29 < Janonymous> what about inproxies/outproxies?
            
-
            14:29 < deer> <postman> put it all together on a website 
            
-
            14:29 < deer> <postman> for those who haven't done so: www.postman.i2p
            
-
            14:29  * Janonymous has not access to the network currently
            
-
            14:30 < deer> <postman> there's a proposal on the website that tries to comprehend all the common problems dealing with anonymity and reliability of a mailservice when doing a bridging between i2p and internet
            
-
            14:30 < deer> <postman> out/inproxy does not run yet but is in the planning
            
-
            14:30 < Janonymous> I think I caught some of the discussion on the maillist or the forum
            
-
            14:30 < Janonymous> out would be more dangerous than in, right?
            
-
            14:31 < deer> <postman> first i want a commonly accepted concept
            
-
            14:31 < deer> <postman> generally YES, but i think we found a way that spam and the likes won't be sent outward
            
-
            14:31 < jrandom> what'd be neat is if the mx.postman.i2p in/outproxy could dispatch to different (or multiple redundant) pop3 accts
            
-
            14:31 < deer> <postman> simply by putting a quota on every user trying to send mails out
            
-
            14:32 < jrandom> (that way it wouldn't be tied to a particular mailhost)
            
-
            14:32 < deer> <postman> jrandom2p: please explain further
            
-
            14:33 < Janonymous> could the seperate mailhosts be syncronized too?
            
-
            14:33 < deer> <postman> jrandom2p: it's a question of account based routing
            
-
            14:33 < jrandom> right postman
            
-
            14:33 < jrandom> probably lots of work, i dont know much about the MTAs you're working on
            
-
            14:33 < deer> <postman> jrandom2p: the out/in proxy could easily handle more than one internal mailsystem - even could arrange a fallback kind of delivery 
            
-
            14:34 < jrandom> 'k, great
            
-
            14:34 < Janonymous> Q wrt in/out
            
-
            14:34 < deer> <postman> janonymous: i did not understand your question - please explain
            
-
            14:34  * jrandom dreams up uucp-style offline fetch from mx.postman :)
            
-
            14:35 < Janonymous> would mandatory mailbox to mailbox encryption make in/out sending less dangerous?
            
-
            14:35 < deer> <postman> jrandom: haha, uucp is not needed i think - maybe ETRN is sexier :)
            
-
            14:35 < deer> <postman> janonymous: right now the system works only internaly - everyone is free to apply PGP or sth similiar
            
-
            14:36 < jrandom> Janonymous: you should swing by www.postman.i2p - he's put up a chunk of ideas / issues on there
            
-
            14:36 < Janonymous> mandatory encryption/signatures is also an antispam method I believe
            
-
            14:36 < deer> <Ragnarok> would it be possible to serve the postman.i2p address book using LDAP?
            
-
            14:36 < Janonymous> I will once my laptop comes in
            
-
            14:37 < deer> <postman> rag: there's an addressbook already - it is based on SQL tho - a transfer to LDAP os possible
            
-
            14:38 < Janonymous> = server hosted address book?
            
-
            14:38 < deer> * postman invites everybody to contribute own ideas to the ideas/concepts html document
            
-
            14:38 < Janonymous> will do postman
            
-
            14:38 < deer> * cervantes spiders the address book and starts writing penis enlargement pharmacutical mails 
            
-
            14:39 < deer> <postman> janonymous: well, ALL mailusers are SQL based - thus the "addressbook" is just a view on that table
            
-
            14:39 < deer> <postman> cervantes: btw, every user can chose whether he wants to be visible or not
            
-
            14:39 < Janonymous> ah
            
-
            14:40 < Janonymous> how about selective groups ;)
            
-
            14:40 < deer> <cervantes> postman: yup I've signed up already ;-)
            
-
            14:40 < deer> <postman> cervantes: and since we HAVE a mailidentidy system , you cannot forge your senderaddress - we know it has been YOU :)
            
-
            14:40 < deer> <postman> janonymous: yeah, it's planned for version 2.0 :)
            
-
            14:41 < deer> <cervantes> postman: but I'll just spam every ircnym@postman.i2p ;-)
            
-
            14:41 < deer> <postman> cervantes: this is technically possible, yes :)
            
-
            14:42 < deer> <postman> cervantes: i hope you're able to deliver those pills too :)
            
-
            14:42 < Janonymous> sounds like a much needed and long expected development for i2p
            
-
            14:42 < Janonymous> the new email system
            
-
            14:42 < deer> <cervantes> postman: and on the sender thing..the "Cervantes' penis enlargement elixir" would indicate the sender too :)
            
-
            14:42 < deer> <postman> janonyous: i cannot tell about every detail implemented
            
-
            14:43 < deer> <postman> jan: the website is best suited for this
            
-
            14:43 < deer> <postman> cervantes: indeed - but this could be forged :)
            
-
            14:43 < Janonymous> alrighty.. I'll get there asap
            
-
            14:43 < jrandom> ok, great.  so, yeah, y'all should review whats up on www.postman.i2p and send in your ideas/comments
            
-
            14:43 < deer> * postman nods and sits down again
            
-
            14:44 < jrandom> (postman++)
            
-
            14:44 < jrandom> ok that brings us to 5) ???
            
-
            14:44 < jrandom> anyone have anything else they want to bring up?
            
-
            14:44 < jrandom> (i2p related)
            
-
            14:44 < deer> <postman> :)
            
-
            14:44 < Janonymous> just a thought
            
-
            14:45 < Janonymous> possible uses for I2P.. we know its a "distributed anonymous network layer"
            
-
            14:45 < deer> <Jake> my node is down :( moving equipment to a different part of the house
            
-
            14:46 < Janonymous> but what can that be used for.. particularly, those "common good" issues
            
-
            14:46 < Janonymous> Oppressive third world countries, freedom of speech.. etc.. thats one of the primary things that got me so interested in i2p to start with
            
-
            14:47 < Janonymous> and freenet for that matter
            
-
            14:47 < deer> <Jake> oppressed 1st world countries like the u.s.
            
-
            14:47 < Janonymous> so, I thought maybe some extrapolation on those issues, maybe starting on the forum, then some words on the site
            
-
            14:48 < jrandom> we've got a lot of work to do before we can claim any relevence for people in china
            
-
            14:48 < Janonymous> heh, yea, wouldn't want to make any false promises, but..
            
-
            14:48  * jrandom will not say we're safe when there has been so little peer review (and there are still so many outstanding issues)
            
-
            14:49 < deer> <fidd> how hard will it be for china to censor i2p?
            
-
            14:49 < deer> <cervantes> I think applications will begin to surface more readily once the underlying network has stopped "shapeshifting"
            
-
            14:49 < Janonymous> but those issues to me are one of the main things that makes i2p so exciting
            
-
            14:49 < jrandom> fidd: censor has many definitions.  in the sense "stop specific content from being transferred", pretty much impossible, short of making i2p illegal
            
-
            14:50 < Janonymous> how about, "detect i2p on networks in china"
            
-
            14:50 < Janonymous> stego?
            
-
            14:51 < jrandom> exciting, yes.  important?  yes.  necessary?  yes.  but since there's so much work to do before we're relevent, its just depressing to talk about it.
            
-
            14:51 < Janonymous> my bad :) 
            
-
            14:51 < deer> <cervantes> once the base network is solid, then we could probably do with some nice toys to play with  - eg filesharing apps, IM systems etc. Hopefully the userbase will swell at that point....before this happens there just won't be enough peers to guarantee anonymity for people who live in oppressive systems
            
-
            14:52 < jrandom> its always important to keep your eyes on the real goals Janonymous, and i appreciate that
            
-
            14:52 < Janonymous> yea, numbers of nodes has a lot to do with it
            
-
            14:52 < modulus> imo until there is stego and things like random noise to defeat traffic analysis people in oppressive countries should stay away for a while.
            
-
            14:53 < deer> <cervantes> no..they should stay here and help :)
            
-
            14:53 < modulus> :-)
            
-
            14:53  * jrandom will not describe in detail why those aspects won't be necessary, as the 3.0 rev will take care of 'em :)
            
-
            14:53 < modulus> 3.0? sounds long-term ;-)
            
-
            14:53 < jrandom> i have ~= 0 faith in stego transports for public networks
            
-
            14:54 < jrandom> it aint tomorrow, thats for sure.
            
-
            14:54 < Janonymous> word? huh
            
-
            14:54 < Janonymous> jrandom: whys that (wrt stego)?
            
-
            14:55 < jrandom> how to defeat stego on public networks with open source software: download the source, review the stego generation code, write detection code, deploy.
            
-
            14:56 < jrandom> how to defeat stego on public networks with closed source software: kidnap the dev's family, subvert the code.  deploy.
            
-
            14:56 < Janonymous> ah.. yea.. random inputs? eh.. I just read this article talking like it was the future or something
            
-
            14:56 < jrandom> how to defeat stego on private networks:  laugh at the 5 people using it, and arrest 'em all.
            
-
            14:56 < modulus> well, what about anonymous closed-source software? of course it could be a trojan ;-)
            
-
            14:57 < deer> <Jake> jrandom: if you're ever kidnapped, you can let us know by telling us "my dog fido is really upset about the food he's eating today"
            
-
            14:57 < deer> <Jake> that will be the giveaway and we'll know
            
-
            14:57 < deer> <cervantes> %s!dev's family!jrandom
            
-
            14:57 < jrandom> heh jake
            
-
            14:58 < Janonymous> whens the eta for 4.2?
            
-
            14:58 < jrandom> Janonymous: the #1 feature of anonymity or security software: snake oil.
            
-
            14:58 < jrandom> 0.4.2?  sometime this month
            
-
            14:58 < jrandom> prolly near the end
            
-
            14:58 < Janonymous> heheh. 
            
-
            14:58 < jrandom> 0.4.1.3 will prolly be out later this week or the weekend
            
-
            14:58 < deer> <cervantes> Jake: that would never work, we'll juist think you've poisoned his dog
            
-
            14:58 < deer> <cervantes> *just
            
-
            14:58 < Janonymous> I should be back on the net in a week or two
            
-
            14:59 < jrandom> r0x0r
            
-
            14:59 < jrandom> ok, anyone else have something to bring up?
            
-
            14:59 < deer> <Jake> cervantes :)
            
-
            15:00 < jrandom> if not..
            
-
            15:00  * jrandom winds up
            
-
            15:00  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting112.html b/www.i2p2/pages/meeting112.html
deleted file mode 100644
index a30b24a6..00000000
--- a/www.i2p2/pages/meeting112.html
+++ /dev/null
@@ -1,272 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 112{% endblock %}
-{% block content %}
            I2P dev meeting, October 19, 2004
            
-
            
-
            14:03 < jrandom> 1) 0.4.1.3
            
-
            14:03 < jrandom> 2) Tunnel test time, and send processing time
            
-
            14:03 < jrandom> 3) Streaming lib
            
-
            14:03 < jrandom> 4) files.i2p
            
-
            14:03 < jrandom> 5) ???
            
-
            14:03 < jrandom> 0) hi
            
-
            14:03  * jrandom waves
            
-
            14:04 < modulus> hi hi
            
-
            14:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-October/000469.html
            
-
            14:04 < deer_> <fidd> howdy
            
-
            14:04 < jrandom> i didn't spend much time on the notes, so they're pretty brief
            
-
            14:05 < jrandom> but, c'est la vie
            
-
            14:05 < jrandom> moving on to 1) 0.4.1.3
            
-
            14:05 < jrandom> the release came out the other day and its been.. well... largely like before
            
-
            14:05 < jrandom> working good enough for most things, but not as reliable as we'd like
            
-
            14:06 < jrandom> throughput is still low, but thats a know issue to be dealt with in 0.4.2
            
-
            14:06 < jrandom> as mentioned in the email, I dont expect there to be any more 0.4.1.* releases
            
-
            14:07 < jrandom> I dont have much more to say on that - anyone have any comments / concerns?
            
-
            14:07 < deer_> <newsbyte> yes: what about the freeze-up?
            
-
            14:09 < jrandom> I'm not going to discount the possibility that your machine hung due to I2P, but I severely doubt it
            
-
            14:09 < jrandom> no one else has ever reported that happening on any platform
            
-
            14:09 < deer_> <newsbyte> well...it must be related to it somehow, if not directly, IMHO
            
-
            14:09 < deer_> <newsbyte> maybe the java?
            
-
            14:10 < jrandom> you're on 1.5 on w2k?
            
-
            14:10 < jrandom> or 1.4.2_05?
            
-
            14:10 < deer_> <newsbyte> nope, 1.5
            
-
            14:10 < jrandom> ok
            
-
            14:10 < deer_> <newsbyte> I can't exclude it's something else, ofcourse
            
-
            14:11 < deer_> <newsbyte> could be coincidence it happend two times
            
-
            14:11 < jrandom> well, we can discuss further how to find out the cause after the meeting if you'd like
            
-
            14:11 < deer_> <newsbyte> but the last time..I dunno...nothing much else was running, then
            
-
            14:11 < deer_> <dinoman> 1.5 on w2k works good for me :)
            
-
            14:11 < deer_> <newsbyte> indeed, though
            
-
            14:11 < deer_> <newsbyte> isn't there a simple debug log or something?
            
-
            14:11 < jrandom> if it happens again, please send me wrapper.log and logs/log-router-*.txt
            
-
            14:11 < deer_> <newsbyte> that might be usefull when it freezes
            
-
            14:11 < jrandom> there are more logs than dirt ;)
            
-
            14:12 < jrandom> ok cool dinoman
            
-
            14:12 < jrandom> perhaps it was some interaction with your software firewall
            
-
            14:12 < deer_> <newsbyte> maybe
            
-
            14:12 < jrandom> but, yeah,bounce me logs if it happens again
            
-
            14:12 < jrandom> (please :)
            
-
            14:12 < deer_> <newsbyte> well, that  it would get blocked, I would understand
            
-
            14:12 < deer_> <newsbyte> but a total freeze...dunno...was creepy
            
-
            14:13 < deer_> <newsbyte> on the bright side: I've 27/63 now
            
-
            14:13 < jrandom> great
            
-
            14:13 < jrandom> ok, anyone else have any questions/comments/concerns with 0.4.1.3?
            
-
            14:13 < deer_> <newsbyte> I'll guees I'll ask Whoo to guide my through the eep thingy
            
-
            14:13 < deer_> <dinoman> just don't use it with Sygate Personal Firewall bad bad
            
-
            14:13 < deer_> <newsbyte> why?
            
-
            14:14 < deer_> <dinoman> crash
            
-
            14:14 < deer_> <newsbyte> yes; you forgot 6) profit!!
            
-
            14:14 < deer_> <newsbyte> ;-)
            
-
            14:14 < deer_> <newsbyte> crash?
            
-
            14:14 < deer_> <newsbyte> ermm
            
-
            14:14 < jrandom> dinoman: it crashes your OS?  the firewall?  I2P?
            
-
            14:14 < deer_> <newsbyte> well, wouldn't that explain it, then? ;-)
            
-
            14:15 < jrandom> newsbyte: are you running Sygate Personal Firewall?
            
-
            14:15 < deer_> <newsbyte> indeed
            
-
            14:15 < deer_> <newsbyte> well, not on my router
            
-
            14:15 < deer_> <newsbyte> but on the puter, yes
            
-
            14:15 < deer_> <newsbyte> seems we're on to something
            
-
            14:16 < deer_> <DrWoo> newsbyte: /join #i2p-chat so jrandom can get through his meeting
            
-
            14:16 < deer_> <newsbyte> though it doesn't crash/freeze immediately, apperently
            
-
            14:16 < deer_> <dinoman> os it crashes windows
            
-
            14:16 < deer_> <newsbyte> ?
            
-
            14:16 < deer_> <newsbyte> jrand is already here
            
-
            14:16 < deer_> <dinoman> sorry looked away
            
-
            14:16 < jrandom> ok, perhaps we can look into what SPF is b0rking on
            
-
            14:16 < jrandom> if there's nothing else on 0.4.1.3, moving on to 2) Tunnel test time, and send processing time
            
-
            14:17 < jrandom> there was some discussion yesterday exploring some of the timeouts, and basically things just occationally take too long
            
-
            14:17 < jrandom> i dont think the spikes you can see in http://dev.i2p.net/~jrandom/processingTime.png are legitimate though
            
-
            14:18 < jrandom> well, they're real - it really does take that long
            
-
            14:18 < jrandom> what i mean is, we should be able to get rid of them
            
-
            14:18 < jrandom> some queueing is going to happen, but if we are more careful with what we accept, we should be able to reduce it
            
-
            14:19 < jrandom> the delays are also likely due to some occational spikes in job processing time, which we can tune the fsck out of
            
-
            14:20 < jrandom> in general though, the message queueing seems all right, even if it spikes up some tunnel tests
            
-
            14:20 < deer_> <newsbyte> darn..I wish freenet and i2p could really merge...seems like progress would be a lot faster, possibly beneficial to both
            
-
            14:20 < deer_> <Ragnarok> yeah, I don't see why fsck would be useful for jon processing :)
            
-
            14:20 < deer_> <Ragnarok> s/jon/job/
            
-
            14:21 < jrandom> there is much potential for collaboration, but the two projects have very different aims
            
-
            14:21 < jrandom> !thwap Ragnarok
            
-
            14:21 < deer_> <newsbyte> ermm
            
-
            14:21 < jrandom> oh, one thing I mentioned yesterday 
            
-
            14:21 < deer_> <newsbyte> I don't think the projects' goals, however, are all that different...
            
-
            14:22 < deer_> <DrWoo> jrandom: technical goals
            
-
            14:22 < jrandom> newsbyte: we can discuss that in 5) ??? or later if you prefer, we're on 2) right now
            
-
            14:22 < deer_> <DrWoo> oops newsbyte: technical goals
            
-
            14:22 < deer_> <Ragnarok> hehe
            
-
            14:22 < deer_> <newsbyte> yes, and 3)profit! according to /. traditions!
            
-
            14:22 < deer_> <newsbyte> :-)
            
-
            14:22 < deer_> <Demokritos> I can't believe Tor is not backwards compatible from 0.0.8 to 0.0.8.1
            
-
            14:23 < jrandom> with the tunnel testing, there is a floor to the test period - currently set to 5 seconds by default
            
-
            14:23 < jrandom> the previous release had a hard limit of 30 seconds, but you can configure your own tunnel test time by updating http://localhost:7657/configadvanced.jsp and adding "router.tunnelTestMinimum=10000" (or whatever - that value is in milliseconds)
            
-
            14:23 < deer_> <newsbyte> those seconds, are they alchimagical?
            
-
            14:24 < jrandom> the 5s default should be fine though
            
-
            14:24 < deer_> <Demokritos> I actually upgraded Tor the day before yesterday because it stopped working, and now the network is telling me again, I have a non compatible version... what the.. 
            
-
            14:24 < deer_> <Demokritos> oh... hello everyone :)
            
-
            14:24 < jrandom> newsbyte: the tunnel test time is MAX(avgTunnelTestTime*2, minTunnelTestTime)
            
-
            14:25 < jrandom> (we have the minTunnelTestTime because otherwise a series of fast tests could cause a cascading failure)
            
-
            14:26 < jrandom> more details can be found in http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD
            
-
            14:26 < deer_> <newsbyte> hmm
            
-
            14:26 < deer_> <Demokritos> this is really funny... a job agency wants me to use Internet Explorer, otherwise I'm not able to register an application
            
-
            14:27 < jrandom> *cough* y'all realize these meeting logs go on the web, right?  :)
            
-
            14:27 < deer_> <Demokritos> <-- not too good in english
            
-
            14:27 < deer_> <newsbyte> they do?!
            
-
            14:27 < deer_> <newsbyte> Hi mum!
            
-
            14:27 < deer_> <newsbyte> ;-)
            
-
            14:27 < deer_> <Demokritos> um, sorry. .I'm disturbing the meeting.. I'm off
            
-
            14:28 < jrandom> naw, please stay, but discuss i2p stuff ;)
            
-
            14:28 < deer_> <newsbyte> don't worry; disturbing is an art, just keep an eye on me, and you'll learn
            
-
            14:28 < deer_> <newsbyte> ;-)
            
-
            14:28 < jrandom> ok, anything else on 2) Tunnel test time, and send processing time ?
            
-
            14:28 < deer_> <Ragnarok> focus people
            
-
            14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has quit [Read error: 60 (Operation timed out)]
            
-
            14:29 < jrandom> if not, moving on to 3) Streaming lib
            
-
            14:29 < jrandom> as mentioned in the status notes, lots of progress
            
-
            14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has joined #i2p
            
-
            14:29 < deer_> <newsbyte> done by you?
            
-
            14:29 < jrandom> still not there yet, but I hope to be doing some live tests in the next week
            
-
            14:30 < jrandom> i've been working on the streaming lib, yeah
            
-
            14:30 < jrandom> i finally got it ping()ing earlier today ;)
            
-
            14:30 < deer_> <Ragnarok> nice :)
            
-
            14:31 < jrandom> ok, i dont really have anything else to add about that
            
-
            14:31 < jrandom> anyone have any questions / comments / concerns?
            
-
            14:31 < deer_> <newsbyte> ermm...speed?
            
-
            14:31 < jrandom> speed is fine
            
-
            14:31 < deer_> <baffled> what type of speed up/through put do you expect?
            
-
            14:31 < jrandom> i expect significant throughput improvements
            
-
            14:32 < deer_> <newsbyte> he expects a fine, he said
            
-
            14:32 < deer_> <newsbyte> for speeding
            
-
            14:32 < deer_> <newsbyte> ;-)
            
-
            14:32 < jrandom> in addition, for small request/response connections, the latency will be dramatically reduced
            
-
            14:32 < jrandom> (cut in half)
            
-
            14:32 < deer_> <dinoman> wow
            
-
            14:32 < deer_> <dinoman> is that using udp?
            
-
            14:33 < jrandom> the new lib exposes all the neat tunable parameters for normal TCP stacks too, so apps will be able to tweak out their own setup
            
-
            14:33 < jrandom> no dinoman, this works on top of i2p's I2CP
            
-
            14:33 < deer_> <dinoman> wow x2
            
-
            14:33 < jrandom> (though we'll be writing similar code in a month or so to get the UDP transport..)
            
-
            14:34 < jrandom> but, well, we'll see.
            
-
            14:34 < deer_> <newsbyte> because...?
            
-
            14:34 < jrandom> there's still a lot of work to do
            
-
            14:34 < jrandom> because what?
            
-
            14:34 < deer_> <newsbyte> well, can't tcp do it as well?
            
-
            14:35 < jrandom> oh, why we're going to go UDP?  http://www.i2p.net/todo#transport
            
-
            14:35 < deer_> <newsbyte> I remember the same discussion on freenet too, but they sticked to tcp as yet
            
-
            14:35 < jrandom> plus TCP is a general purpose streaming transport - we can dramatically simplify it, since we can put up with a certain degree of out of order
            
-
            14:35 < deer_> <newsbyte> not that all decisions they make are good ;-)
            
-
            14:36 < jrandom> newsbyte: i've followed those discussions and we're going to go udp
            
-
            14:36 < jrandom> (that doesnt mean freenet is wrong - they've got different constraints)
            
-
            14:37 < deer_> <Ragnarok> i2p should not be compared too closely to freenet.  They're very different technically.
            
-
            14:37 < deer_> <newsbyte> (or: they ARE wrong ;-)
            
-
            14:37 < jrandom> i dont think their use of TCP right now is wrong, just as I dont think I2P's previous use of TCP is wrong.  progress requires small steps
            
-
            14:38 < deer_> <mule_iip> newsbyte makes sure the meetings don't get too short
            
-
            14:38 < jrandom> heh
            
-
            14:38 < deer_> <newsbyte> yeah, nothing worse then short meetings
            
-
            14:38 < deer_> <newsbyte> you can't eat all the popcorn and drink all the beer, then
            
-
            14:38 < jrandom> ok, anything else on 3) Streaming lib ?
            
-
            14:39 < jrandom> if not, 4) files.i2p
            
-
            14:39 < deer_> <Ragnarok> I think we're cool
            
-
            14:39 < deer_> <newsbyte> well, I know I am
            
-
            14:39 < deer_> <newsbyte> ;-)
            
-
            14:39 < deer_> <newsbyte> and funny too
            
-
            14:39 < deer_> <newsbyte> most of the time
            
-
            14:39 < deer_> <newsbyte> and also annoying
            
-
            14:39 < deer_> <newsbyte> ;-)
            
-
            14:39 < jrandom> well, i just wanted to point out files.i2p - a new search engine on i2p
            
-
            14:40 < deer_> <newsbyte> ah, I see
            
-
            14:40 < deer_> <newsbyte> I was hoping it would be about putting eepsites up
            
-
            14:40 < jrandom> one interesting thing to note is that you can reach eepsites that aren't up anymore with it, since it caches
            
-
            14:41 < deer_> <baffled> does it cache everything?
            
-
            14:41 < deer_> <newsbyte> all searchengines thusfar are server-side?
            
-
            14:41 < deer_> <Ragnarok> interesting.  Shouldn't be too hard, these days :).
            
-
            14:41 < jrandom> baffled: caches text/html from what i can tell
            
-
            14:42 < deer_> <mule_iip> at least it has limits on file size and types, so won't cache movies
            
-
            14:42 < deer_> <baffled> Auh, that's what I thought not binary.
            
-
            14:42 < deer_> <newsbyte> I mean, they are not in js, I suppose?
            
-
            14:43 < jrandom> it uses nutch if anyone wants to look into it further.  or i'm sure we'll get the site author to put up a feedback form or something ;)
            
-
            14:43 < jrandom> newsbyte: correct, this is just a normal website hosted anonymously
            
-
            14:43 < jrandom> the site contains a search engine (like google)
            
-
            14:44 < jrandom> anyway, i just wanted to mention it
            
-
            14:44 < jrandom> there have also been a lot of blogs popping up lately, which imho is really cool
            
-
            14:44 < jrandom> my 'eep' bookmark folder almost fills a screen :)
            
-
            14:44 < deer_> <Ragnarok> hehe, myi2p is happening all by itself :)
            
-
            14:45 < jrandom> you just have to bring up the sore points, dont ya ragnarok?  ;)
            
-
            14:45 < deer_> <Ragnarok> sorry :)
            
-
            14:46 < jrandom> ok, anyone have any questions/comments/concerns wrt files.i2p?
            
-
            14:46 < jrandom> if not, let me move on to 4.1) biff
            
-
            14:46  * jrandom almost forgot biff
            
-
            14:46 < jrandom> postman, you arond?
            
-
            14:47 < deer_> <newsbyte> I think he's biffed up
            
-
            14:47 < jrandom> well, if not, biff is this new kickass mail notification bot
            
-
            14:47 < jrandom> if you've got an email acct at mail.i2p, you can tell biff to notify you when you get new mail
            
-
            14:47 < deer_> <newsbyte> does it has archives?
            
-
            14:48 < jrandom> newsbyte: biff is just a notification bot, the mail is stored on the mail server (and accessed with your normal mail reader - kmail, etc)
            
-
            14:48 < jrandom> see http://www.postman.i2p/
            
-
            14:49 < jrandom> ok, so, yeah, go to the eepsite or check out #mail.i2p over there
            
-
            14:49 < deer_> <newsbyte> I will, as soon as I get my eepsite on
            
-
            14:49  * jrandom doesnt really know much more wrt biff - redirect any questions to postman
            
-
            14:50 < jrandom> instead, we can move on to 5) ???
            
-
            14:50 < deer_> <newsbyte> indeed
            
-
            14:50 < jrandom> does anyone have anything else they want to bring up?
            
-
            14:50 < deer_> * mule_iip raising hand to get voice: would like to recall my persistent FCP over I2P problems. but probably that can wait and will automagically be solved by 0.4.2.
            
-
            14:50 < deer_> <newsbyte> yes, and the freeze
            
-
            14:50 < jrandom> i hope so mule_iip
            
-
            14:50 < deer_> <mule_iip> ok, will be your test platform :)
            
-
            14:50 < jrandom> newsbyte: is there anything we need to discuss about it?  could you just email me your logs if it happens again?
            
-
            14:51 < jrandom> ooh mule, that'd rule
            
-
            14:51  * jrandom will definitelytake you up on that
            
-
            14:51 < deer_> <newsbyte> well...can i still send those, if everything is frozen?
            
-
            14:51 < jrandom> the files are written to disk.  
            
-
            14:51 < jrandom> when you restart, send me the logs
            
-
            14:51 < deer_> <newsbyte> I mean, in that case, I could send it now, since they should be somewhere 
            
-
            14:51 < jrandom> (please)
            
-
            14:51 < deer_> <dinoman> i was in the forum and see that the jabber service is gone. was thaat of us to anyone if it was i would like to run one if it would be cool?
            
-
            14:51 < jrandom> the files rotate though newsbyte
            
-
            14:52 < jrandom> duck and demonic_1 have had jabber servers at various times, but it seems most of the i2p IM activity has been on irc
            
-
            14:52 < deer_> <newsbyte> the files rotate? surely it stores quite some data before it starts deleting?
            
-
            14:53 < jrandom> newsbyte: ok, send me your logs, maybe it has something in it
            
-
            14:53 < deer_> <newsbyte> good
            
-
            14:53 < deer_> <newsbyte> ermm
            
-
            14:54 < deer_> <newsbyte> darn
            
-
            14:54 < deer_> <newsbyte> a lot of .logs
            
-
            14:54 < deer_> <dinoman> ok
            
-
            14:54 < deer_> <newsbyte> a noob is never gonna follow this
            
-
            14:54 < deer_> <newsbyte> I guess you're right in not making a /. article yet
            
-
            14:55 < jrandom> we're in no rush
            
-
            14:55 < deer_> <newsbyte> log-router.txt?
            
-
            14:55 < jrandom> wrapper.log and logs/log-router-*.txt
            
-
            14:56 < deer_> <newsbyte> and the mailaddy to use would be...?
            
-
            14:56 < deer_> <fidd> dinoman, a jabber server would be cool imo
            
-
            14:56 < jrandom> jrandom@i2p.net
            
-
            14:56 < deer_> <newsbyte> accessible by i2p, I hope?
            
-
            14:56 < deer_> <newsbyte> ;-)
            
-
            14:56 < jrandom> newsbyte: you can put your logs on your eepsite and msg me the url
            
-
            14:57 < jrandom> or you can send mail to jrandom@mail.i2p
            
-
            14:57 < deer_> <newsbyte> indeed!
            
-
            14:57 < deer_> <newsbyte> a good idea!
            
-
            14:57 < deer_> <newsbyte> there is only one little problem with it: It's not up yet
            
-
            14:57 < jrandom> ok, anyone else have anything they want to bring up?
            
-
            14:57 < jrandom> well, we can work on that newsbyte
            
-
            14:57 < jrandom> (after the meeting)
            
-
            14:59 < deer_> <newsbyte> thnks, but whoo is already helping
            
-
            14:59 < jrandom> if there's nothing else...
            
-
            14:59 < deer_> <newsbyte> we need a detailed howto/wiki/helpsite/something, though
            
-
            14:59  * jrandom winds up
            
-
            14:59 < deer_> <Jake_> i'd like to say, for the meeting, if a public release of i2p can be made before the u.s. election on november 2nd, this would go a long way to helping ensure a stable democracy 
            
-
            14:59 < deer_> <newsbyte> what about 6)?
            
-
            14:59 < jrandom> newsbyte: would you like to work on that?
            
-
            15:00 < jrandom> newsbyte: i do agree it'd be great to get some more howtos and help info
            
-
            15:00 < deer_> <Ragnarok> 6) There is no.... number 6
            
-
            15:00 < deer_> <newsbyte> well, yeah, sort of, but it's a strange thing, with me
            
-
            15:00 < deer_> <newsbyte> I'm pro-wiki and public thingy and free for everyone and all that
            
-
            15:00 < deer_> <newsbyte> but my ego protests and wants minimal control
            
-
            15:00 < jrandom> great
            
-
            15:00 < deer_> <newsbyte> go figger
            
-
            15:00 < jrandom> heh
            
-
            15:01 < jrandom> well, if you'd like to make your own eepsite into a wiki you control, that'd be great too
            
-
            15:01 < deer_> <newsbyte> indeed
            
-
            15:01 < jrandom> though ugha.i2p has a pretty good uptime
            
-
            15:01 < deer_> <newsbyte> I'll think about it
            
-
            15:01 < jrandom> cool
            
-
            15:02 < deer_> <newsbyte> 6 would be the freenet-i2p thingy
            
-
            15:02  * jrandom winds up 
            
-
            15:02  * jrandom *baf*s the meeting closed 
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting113.html b/www.i2p2/pages/meeting113.html
deleted file mode 100644
index f2bc1178..00000000
--- a/www.i2p2/pages/meeting113.html
+++ /dev/null
@@ -1,273 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 113{% endblock %}
-{% block content %}
            I2P dev meeting, October 26, 2004
            
-
            
-
            14:04 < jrandom> 0) hi
            
-
            14:04 < jrandom> 1) Net status
            
-
            14:04 < jrandom> 2) Streaming lib
            
-
            14:04 < jrandom> 3) mail.i2p progress
            
-
            14:05 < jrandom> 4) ???
            
-
            14:05 < jrandom> 0) hi
            
-
            14:05  * jrandom waves
            
-
            14:05 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-October/000474.html
            
-
            14:06  * jrandom will let y'all read ahead (damn you, read ahead!)
            
-
            14:06 < jrandom> jumping in to 1) net status
            
-
            14:07 < jrandom> i guess the email covers what i wanted to mention. nice fix wrt resume duck, and thanks for reporting it ardvark and ragnarok!
            
-
            14:07 < jrandom> does anyone have anything they want to bring up about the network status?
            
-
            14:08 < modulus> it rules.
            
-
            14:08 < deer> <postman> hi
            
-
            14:08 < jrandom> w3wt
            
-
            14:09 < jrandom> there is something funky w/ lag going on lately though, but it seems to be the same as what we discussed last week
            
-
            14:09 < jrandom> (especially since i haven't done any work on the core since then)
            
-
            14:09 < deer> <clayboy> i think everybody agrees that it has been stable and usable.
            
-
            14:09 < deer> <clayboy> i miss my 10-16 hours connected time on irc though, not important
            
-
            14:10 < deer> <jrandom2p> i'm on for 20h here
            
-
            14:10 < deer> <jrandom2p> but yeah, it varies (which hopefully agenda item 2) will help with)
            
-
            14:10 < deer> <clayboy> i can hardly get > 2h, but i always reconnect in an instant, so it's still usable
            
-
            14:11 < jrandom> cool
            
-
            14:11 < jrandom> still not good enough, but sufficient
            
-
            14:11 < jrandom> (for the time being)
            
-
            14:11 < deer> <clayboy> agreed
            
-
            14:12 < jrandom> ok, anyone have anything else, or shall we move on to 2) streaming lib?
            
-
            14:13 < jrandom> [consider us moved]
            
-
            14:13 < jrandom> the email gives a rundown of how the progress is coming
            
-
            14:14 < jrandom> the message sequences are 'correct' in most cases (matching the ones discussed before)
            
-
            14:14 < jrandom> e.g. short request/response gets the requestee a response in a single round trip
            
-
            14:15 < jrandom> i'm working on the profile=bulk right now, going through the sliding windows under lag and failure conditions
            
-
            14:15 < jrandom> still some things to clean up, and nothing ready for use, but its progress
            
-
            14:16 < deer> <clayboy> so is 0.4.2 with streaming lib en route for october? it seems like an unnecessary rush.
            
-
            14:16 < jrandom> i dont think we'll have the streaming lib ready for final deployment by next week, no
            
-
            14:17 < jrandom> so there'll be some schedule slippage, i'm not sure to what extent yet
            
-
            14:17 < deer> <duck> any test classes we can run for kicks?
            
-
            14:18 < jrandom> i havent committed the build.xml file yet to keep people from using it ;)  but i'll commit what i've got later tonight, and you can try out http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/streaming/java/test/net/i2p/client/streaming/StreamSinkTest.java?rev=1.1&content-type=text/x-cvsweb-markup
            
-
            14:19 < deer> <duck> h0t
            
-
            14:19 < jrandom> one thing is that this new streaming lib doesn't use the old mode=guaranteed anymore since it has its own ACK/NACK setup
            
-
            14:20 < jrandom> that means that after the lib works perfectly, there's still going to be some work to be done in the router itself, as the client sending tasks are designed for 'guaranteed' delivery, bundling a roundtrip message in the garlic to confirm session tag delivery
            
-
            14:21 < jrandom> we don't actually have to fix that right away though - the bandwidth usage on that DeliveryStatusMessage is... trivial
            
-
            14:21 < jrandom> but we'll want to sooner rather than later
            
-
            14:22 < jrandom> ok, thats all i've got to say on that
            
-
            14:22 < jrandom> anyone have anything to bring up wrt the streaming lib?
            
-
            14:23 < jrandom> if not, 3) mail.i2p progress
            
-
            14:23 < jrandom> postman, you 'round?
            
-
            14:23 < deer> <postman> ya
            
-
            14:24 < jrandom> any update for us, or shall we wait until there's more news?
            
-
            14:24 < deer> <postman> ok
            
-
            14:24 < deer> <postman> shall i?
            
-
            14:24 < jrandom> the mic is yours
            
-
            14:24 < deer> * gott awakens.
            
-
            14:24 < deer> <postman> 1.) the in/out proxy facility is being installed/tested atm 
            
-
            14:25 < deer> <postman> 2.) within the next 10 days we'll have a gateway service from and to the internet for emails
            
-
            14:25 < modulus> cool!
            
-
            14:25 < jrandom> cool^2!
            
-
            14:25 < deer> <clayboy> indeed
            
-
            14:25 < deer> <postman> 3.) the implementation will follow the ideas/concepts of the ideas.html document on my websote
            
-
            14:25 < deer> <gott> bravo !
            
-
            14:26 < deer> <postman> means: hashcash/recipient based quotas and all the fancy stuff
            
-
            14:26 < deer> <postman> the service should not be abused by its fellow anonymous users
            
-
            14:26 < deer> <postman> :)
            
-
            14:26 < deer> <postman> well there'e another point
            
-
            14:26 < deer> <postman> the question for webmail interfaces
            
-
            14:26 < deer> <postman> right now i don't want to host itz on my servers
            
-
            14:27 < deer> <postman> since i don't know about potential security problems
            
-
            14:27 < deer> <postman> the system that runs now is verified by me - i know the source and the security risks
            
-
            14:28 < deer> <postman> adding php and dynamic stuff and a webmail application FOR ALL users makes it much more difficult 
            
-
            14:28 < deer> <postman> the idea ( thanks jr) is:
            
-
            14:28 < deer> <postman> what if the user got his own webmail interface installed as aonthr optional jetty or whatever instance?
            
-
            14:29 < modulus> like a pop3 -> webmail thing?
            
-
            14:29 < jrandom> 'zactly
            
-
            14:29 < deer> <postman> and this local webmail application uses the postman.i2p tunnels to do smtp and pop3
            
-
            14:29 < modulus> sounds good.
            
-
            14:29 < deer> <postman> but i need help in evaluating
            
-
            14:30 < deer> <postman> right now i am quite busy with real life stuff and the in/out proxies
            
-
            14:30 < jrandom> (eww, real life!)
            
-
            14:30 < deer> <postman> and i got a peanut sized brain - so i am not good in java at all
            
-
            14:31 < deer> <postman> i need sbdy helping how this can be done as a local/optional service 
            
-
            14:31 < modulus> may there be something that does this already on tcp? if so it could be used.
            
-
            14:31 < deer> <DrWoo> postman: I doubt it's peanut sized, I think it takes walnut sized just to breath ;)
            
-
            14:32 < jrandom> after a quick glance through hotscripts, i saw one that did pop3, though i dont know if it did authenticated smtp
            
-
            14:32 < deer> <postman> modulus: i assume there's something in the wild that can be used / adapted - it would be sexy to let it run in an own jetty instance
            
-
            14:32 < jrandom> i'm sure there is something out there, we just need an adventurous soul to go find it :)
            
-
            14:32 < deer> <postman> jrandom2p: this can be hacked quite easily i think
            
-
            14:33 < jrandom> exactly - in an ideal world, someone can just grab a mywebmail.war and save it to the webapps/ directory and jump into http://localhost:7657/mywebmail/
            
-
            14:33 < deer> <postman> well, i leave this issue to you to think about it :)
            
-
            14:33 < modulus> even if it's a stand-alone app, it should be fine, with i2ptunel
            
-
            14:33 < jrandom> right modulus 
            
-
            14:33 < deer> <postman> yep :)
            
-
            14:34 < jrandom> and local >> remote, as the local side can do things like access your GPG keyrings or whatever
            
-
            14:34 < deer> <postman> i will do anything thats needed to support such a system on the server side
            
-
            14:34 < modulus> which hopefully would be very little.
            
-
            14:36 < deer> <postman> of course there will be an official announcement as soon as internet access is available - so stay tuned - maybe there will be some progress on the webmail idea as well
            
-
            14:36 < deer> <postman> so much for my department
            
-
            14:36 < deer> * postman sits down again and sips on his coffee
            
-
            14:36 < modulus> could you do something about filtering anon-revealing data?
            
-
            14:36 < jrandom> kickass, thanks postman!  sounds exciting
            
-
            14:36 < modulus> some MUAs are very misbehaved in this way.
            
-
            14:37 < deer> <postman> modules: please look at the webpage - there is a multipage sermon about that
            
-
            14:37 < jrandom> :)
            
-
            14:37 < modulus> ok
            
-
            14:37 < jrandom> http://www.postman.i2p/sec.html to start
            
-
            14:37 < modulus> i read that, i just thought maybe some fields could be filtered.
            
-
            14:37 < modulus> maybe i trust postman but not other ppl.
            
-
            14:38 < deer> <postman> modulus: They ARE filtred
            
-
            14:38 < modulus> ok, last time i treid it they weren't.
            
-
            14:38 < modulus> sorry about that.
            
-
            14:38 < deer> <postman> modulus: sec2.html describes WHAT headerlines are filtered or changed
            
-
            14:38 < deer> <postman> modulus: what headerlines are you refrring to?
            
-
            14:38 < modulus> from domain (IP) kind of thing
            
-
            14:39 < jrandom> it would be good if a local webmail script did the filtering locally
            
-
            14:39 < jrandom> (in addition to any filtering done @ smtp.postman.i2p)
            
-
            14:39 < deer> <postman> modulus: lets talk about that in pm, ok? :)
            
-
            14:40 < deer> <postman> jrandom2p: of course - i am happy about every client doing its homework
            
-
            14:40 < modulus> sure, sorry.
            
-
            14:41 < jrandom> ok, do we have anything else for mail.i2p discussions?
            
-
            14:41 < jrandom> if not, 4) ???
            
-
            14:41 < deer> * duck has something for #4
            
-
            14:42 < jrandom> sup duck?
            
-
            14:42 < deer> <duck> the HD of home.duck.i2p blew up
            
-
            14:42 < jrandom> (d'oh)
            
-
            14:42 < deer> <duck> luckily the hosting accounts were not really used, except for alexandria
            
-
            14:42 < deer> <duck> did anybody here leach all the ebooks? :)
            
-
            14:43 < deer> <duck> if so, I got some missing so msg me please
            
-
            14:43 < jrandom> actually, i think thetower did
            
-
            14:43 < deer> <duck> I know that hypercubus also has them
            
-
            14:43 < deer> <postman> damn
            
-
            14:43 < jrandom> i saw a mirror on his site a while back
            
-
            14:43 < deer> <postman> :/
            
-
            14:43 < deer> <duck> cool
            
-
            14:43 < jrandom> i dont know if it has everything though, or how up to date it was
            
-
            14:43 < deer> <duck> alexandria is now on http://duck.i2p/alexandria/
            
-
            14:44 < deer> <duck> and I am going back to being ashamed
            
-
            14:44 < deer> <duck> .
            
-
            14:44 < jrandom> no need to be ashamed, you've provided a kickass free service!
            
-
            14:45 < jrandom> perhaps now is the chance for some geocities.i2p site ;)
            
-
            14:46 < deer> <duck> oh, I made a yodel webfrontend @ http://duck.i2p/yodel/
            
-
            14:46 < jrandom> oh, one thing i didn't have in the agenda is BT related stuff.  i know dinoman is doing some hacking on that - perhaps he wants to mention something?
            
-
            14:46 < jrandom> ah nice
            
-
            14:48  * jrandom notes that thetower's alexandria mirror link 404s
            
-
            14:48 < deer> <gott> I have something to suggest.
            
-
            14:48 < jrandom> sup gott?
            
-
            14:48 < deer> <gott> I think it would be a nice feature for 0.4.2 to add a link to one of the sitelists on pages such as thetower's, baffled or mine.
            
-
            14:49 < jrandom> thats a good idea
            
-
            14:49 < jrandom> perhaps all three
            
-
            14:49 < deer> <gott> This is to (a) keep a list of active eepsites and (b) form an index for i2p similar to FIND / Dolphin
            
-
            14:49 < jrandom> yours is nice w/ the links to the eepsites too
            
-
            14:49 < deer> <gott> the one located at http://gott.i2p/sites.html is being kept up-to-date 
            
-
            14:49 < deer> <gott> and the script is run every day
            
-
            14:49 < deer> <gott> I can add optional descriptions to the links ( thanx to baffled's script )
            
-
            14:50 < deer> <gott> which would make it an index
            
-
            14:50 < jrandom> perhaps it'd be neat to have a "recently added" or "recently removed" marker too?
            
-
            14:50 < jrandom> word
            
-
            14:51 < deer> <gott> quite good.
            
-
            14:51 < deer> <gott> that's all I had to say for now.
            
-
            14:51 < deer> <gott> oh, another thing
            
-
            14:51 < deer> <gott> snipsnap works well under i2p
            
-
            14:52 < deer> <gott> so we might see kuro5hin-style eepsites being brought up sometime a la SCUM
            
-
            14:52 < jrandom> kickass
            
-
            14:52 < deer> <gott> *except more devious a la SCUM
            
-
            14:52 < jrandom> a howto for setting that up would be great
            
-
            14:52 < deer> <gott> you put the .war in webapps
            
-
            14:52 < deer> <gott> it's pretty straightforward ;-)
            
-
            14:53 < deer> <polecat> snipsnap...SCUM...?
            
-
            14:53 < jrandom> its really that easy?  booyeah!
            
-
            14:53 < jrandom> polecat - http://snipsnap.org/space/start
            
-
            14:53 < deer> <gott> I have finished my discourse.
            
-
            14:53 < deer> * gott retires.
            
-
            14:53 < jrandom> thanks gott
            
-
            14:54 < jrandom> nickster was using snipsnap for a while
            
-
            14:54 < jrandom> ok, anyone have anything else to bring up?
            
-
            14:55  * jrandom notes that we're near the hour mark even *without* newsbyte ;)
            
-
            14:55 < deer> <polecat> I like pie!
            
-
            14:55 < deer> <gott> I have another thing.
            
-
            14:55 < deer> <duck> oh, orz is awake
            
-
            14:55 < deer> <gott> I would like to announce that soon after 0.4.2 release I will publish an interview on jrandom on i2p-related things.
            
-
            14:55 < deer> <polecat> I wasn't aware this a formal meeting.  Might mention my ideas about name servers...
            
-
            14:56 < deer> <duck> I suggest all japanese ppl to check out his eepsite/ircserver
            
-
            14:56 < deer> <gott> Nothing specific to be said on it until the questions are asked and answered but you have something to look forward to.
            
-
            14:56 < deer> <gott> it will be on my eeplog and if jrandom thinks good enough, probably featured somewhere on i2p.net
            
-
            14:57 < deer> * gott retires again.
            
-
            14:57 < deer> <postman> modulus: 
            
-
            14:57 < jrandom> yeah, orz's site and irc server work great, i just dont know what it says :)
            
-
            14:58 < modulus> YES?
            
-
            14:58 < modulus> sorry for caps.
            
-
            14:58 < deer> <DrWoo> polecat: so about nameserver?
            
-
            14:58 < deer> * gott unretires
            
-
            14:58 < deer> <gott> duck: does he speak english ?
            
-
            14:59 < jrandom> oh polecat, whats up?
            
-
            14:59 < jrandom> polecat: we have our weekly meting every tuesday at 9p GMT
            
-
            14:59 < deer> <gott> I assume he does to have set everything up so well.
            
-
            14:59 < jrandom> (logs posted @ http://www.i2p/meetings once they're done ;)
            
-
            15:00 < deer> <polecat> Yes.  Well I was thinking a name server might be a good idea.  But not DNS.  c.c  I had an idea for a server that did nothing but translate between Protocol Specific Addresses and human readable names.
            
-
            15:00 < jrandom> so a URI-->URL resolver, kinda?
            
-
            15:01 < deer> <polecat> That would replace hosts.txt, and eventually replace DNS itself once it supports ipv4 and ipv6.
            
-
            15:01 < deer> <polecat> name => hash in the case of i2p.  Like duck.i2p => gobbledygook
            
-
            15:02 < jrandom> right right
            
-
            15:02 < deer> <polecat> Trouble with DNS is it has "requirements" (i.e. hacks) like MX servers, and root hierarchy, and nasty stuff like that.  The hackiness of DNS puts even Usenet to shame.
            
-
            15:03 < deer> <polecat> I was talking about this earlier, and someone mentioned http://distributeddns.sourceforge.net/
            
-
            15:03 < deer> <polecat> I haven't had a chance to look at that site though.
            
-
            15:05 < jrandom> there are lots of things to keep in mind when working through a naming system, and in turn, there are lots of tradeoffs to be made.  there have also been lots of discussions of improvements over the years (not just within i2p) to address many of the issues, but a concrete solution would be great
            
-
            15:05 < deer> <gott> quite good, quite good.
            
-
            15:07 < jrandom> i've got my own views, but thats where one of i2p's strong points comes out - my own views are irrelevent :)  any sort ofnaming srevice can be used by client apps, as all of that functionality is outside of the core scope
            
-
            15:08 < jrandom> i know nano is working on something too - there's some entries @ nano.i2p, though i dont know how thats progressing
            
-
            15:08 < deer> <polecat> Agreed; you could write clients to use a ddns server as much as you could write them to parse the local hosts.txt
            
-
            15:08 < deer> <gott> jrandom: I dread the day when hosts.txt or equivalent naming system begins to show << enlarge.your.penis.i2p >>
            
-
            15:09 < deer> <polecat> Just might be easier; at the current standing only I2PTunnel has the ability to understand hosts.txt.  Plus if we're going to compete with ipv4 and ipv6 we can't compromise limited functionality when they don't.
            
-
            15:10 < jrandom> a while back mihi factored out the naming hooks in i2ptunnel - anything that implements http://dev.i2p.net/javadoc/net/i2p/client/naming/NamingService.html can be used transparently
            
-
            15:10 < jrandom> (and that includes I2PTunnel and SAM)
            
-
            15:10 < deer> <polecat> Really?  I'll have to look at that too...
            
-
            15:11 < jrandom> well, they trade off functionality for security and identity
            
-
            15:11 < deer> <polecat> And also since i2p has such long hashes, for cryptographic security, having a name server is even more important since most people cannot remember the full i2p hash address.
            
-
            15:11 < jrandom> e.g. the jackboots can kick down $domainOwner's door
            
-
            15:11 < jrandom> (and someone can spoof dns without much trouble)
            
-
            15:12 < jrandom> but having some sort of name --> location resolution functionality is definitely important
            
-
            15:13 < deer> <polecat> Without a centralized server, you can't have a unique human readable name anyway.  Even if they're cryptographically signed, they still can be duplicated on the part that is comprehensible to us.
            
-
            15:14 < lucky> ugh.
            
-
            15:14 < lucky> Why don't you have deer block gott out?
            
-
            15:14 < jrandom> there are many tradeoffs
            
-
            15:14 < jrandom> i've outlined my preference at http://dev.i2p.net/pipermail/i2p/2004-February/000135.html
            
-
            15:15 < jrandom> but i'm not goingto write a naming service anytime soon, so whatever an implementer wants to do, they're free to :)
            
-
            15:15 < lucky> heh.  I thought that was in response to the Gott question.
            
-
            15:15 < jrandom> heh
            
-
            15:15 < jrandom> naw, gott has been contributing positively as of late
            
-
            15:16 < jrandom> ok, in any case polecat, you should put up an eepsite with your ideas
            
-
            15:16 < lucky> god, what is the world coming to?
            
-
            15:16 < deer> <polecat> I'm thinking of writing a naming service myself.  I'd like to know what everyone else prefers, and get as much guidance as possible how to implement it in a way that works really really well.
            
-
            15:16 < lucky> Oh, how can i contribute?
            
-
            15:16 < lucky> I know some java know.  Like variable assigning.
            
-
            15:16 < lucky> And what ++j means
            
-
            15:17 < deer> <polecat> Ugh... an eepsite...
            
-
            15:17 < deer> <polecat> ++j is the post-increment operator on variable j?
            
-
            15:18 < jrandom> polecat: you can post to the mailing list or forum, as well.  perhaps make a poll in the forum if you want to see what sort of preferences people have?
            
-
            15:18 < deer> <polecat> Trouble is this computer I'm on gets reset into Windoze frequently, and so unless I put my eepsite on a vfat partition, I can't share its info between operating systems.
            
-
            15:19 < jrandom> 'k, then its prolly best to have the naming stuff on the forum instead of an eepsite :)
            
-
            15:20 < deer> <polecat> Where's the forum again...?
            
-
            15:20 < jrandom> http://forum.i2p/
            
-
            15:20 < jrandom> and http://forum.i2p.net/
            
-
            15:20 < jrandom> (isnt naming wonderful?  :)
            
-
            15:21 < deer> <gott> I have always contributed positively.
            
-
            15:21 < deer> <polecat> Yes, except we all still wget the hosts.txt file from a centralized sources.  ;3
            
-
            15:22  * jrandom uses cp, not wget ;)
            
-
            15:22 < jrandom> ok, anyone have anything else to bring up?
            
-
            15:23  * jrandom doesnt mean to shut down the naming discussion, its just that we can discuss that for weeks on end
            
-
            15:23 < deer> <DrWoo> dinoman is working on a cvs server in i2p?
            
-
            15:23 < jrandom> well, there already *is* a cvs server in i2p (cvs.i2p)
            
-
            15:24 < jrandom> but thats right - dinoman was working on a full blown gforge in i2p iirc
            
-
            15:24 < deer> <DrWoo> jrandom: sorryt,I mean a fully anonymous cvs ;)
            
-
            15:25 < jrandom> hey, cvs.i2p is fully anonymous cvs :)  i2p is completely self hosting, but without all the goodies for adding on lots of other projects
            
-
            15:25 < jrandom> (and having a gforge on i2p would Kick Ass)
            
-
            15:26 < deer> <DrWoo> jrandom: doesn't cvs.i2p run on the public server?
            
-
            15:26 < deer> <polecat> gforge... dunno that...
            
-
            15:27 < jrandom> DrWoo: maaaybe ;)
            
-
            15:27 < jrandom> DrWoo: but the key is that developers can be anonymous and develop for i2p through i2p
            
-
            15:27 < jrandom> if the machine that cvs.i2p is physically located on is under attack, we can just move the destination somewhere else
            
-
            15:28 < deer> <polecat> Yes, so while the i2p source itself is vulnerable to being confiscated by the Long Arm of the Law, its developers are immune to a certain extent through anonymity.
            
-
            15:28 < jrandom> let 'em have the source, its free!  :)
            
-
            15:29 < deer> <DrWoo> jrandom: ya, i see what you're saying, but it still is at the risk of something like the indymedia thing
            
-
            15:30 < jrandom> if the jackboots kicked down the door of the colo where cvs.i2p is, i'd simply install cvs somewhere else, deploy a backup of the cvs there, and run an i2prouter with the cvs.i2p private key 
            
-
            15:30 < jrandom> (and *not* tell peole that cvs.i2p == cvs.i2p.net ;)
            
-
            15:32 < jrandom> ok, anyone else have soemthing to bring up for the meeting?
            
-
            15:32 < deer> <polecat> Hee, that's pretty cool.
            
-
            15:33 < jrandom> if not
            
-
            15:33  * jrandom winds up
            
-
            15:34  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting114.html b/www.i2p2/pages/meeting114.html
deleted file mode 100644
index 8e6a8d64..00000000
--- a/www.i2p2/pages/meeting114.html
+++ /dev/null
@@ -1,404 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 114{% endblock %}
-{% block content %}
            I2P dev meeting, November 2, 2004
            
-
            
-
            13:37 < jrandom> 0) hi
            
-
            13:37 < jrandom> 1) Net status
            
-
            13:37 < jrandom> 2) Core updates
            
-
            13:37 < jrandom> 3) Streaming lib
            
-
            13:37 < jrandom> 4) mail.i2p progress
            
-
            13:38 < jrandom> 5) BT progress
            
-
            13:38 < jrandom> 6) ???
            
-
            13:38 < jrandom> 0) hi
            
-
            13:38 < jrandom> sorry for the delay, weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2004-November/000477.html
            
-
            13:38 < dm> meeting in 24 or 84?
            
-
            13:38 < jrandom> 0
            
-
            13:38 < dm> oh.. -36?
            
-
            13:39 < jrandom> yup, 9p GMT
            
-
            13:39 < jrandom> but i forgot that, so we're starting... now ;)
            
-
            13:39 < jrandom> 1) net status
            
-
            13:39 < dm> good timing
            
-
            13:39 < jrandom> well, no real change in the net status from my end - does anyone have anything they'd like to bring up about it?
            
-
            13:41 < jrandom> if not, might as well move on to 2) core updates
            
-
            13:41 < jrandom> i dont really have anything to add beyond whats in the email, so i'll give people a min to digest
            
-
            13:42 < deer> <postman> arg
            
-
            13:42 < jrandom> there've been 8 patches since the release, with another one or two pending.  we'll probably just tag those all up into a 0.4.1.4, as the streaming lib itself isn't ready
            
-
            13:43 < deer> <jrandom> wb, its looking a bit bumpy over here
            
-
            13:43 < deer> <postman> np, i am back :)
            
-
            13:43 < protok0l> any word on aum's disappearance? i want stasher!
            
-
            13:44  * dm likes knowing that stuff is being done under the hood to optimize I2P
            
-
            13:44 < jrandom> as gott quoted, diy, do or die
            
-
            13:45 < jrandom> yeah, the memory churn was getting to be a substantial portion of the CPU time
            
-
            13:45 < jrandom> so it was finally worth the effort to optimize
            
-
            13:45 < deer> <baffled> Sorry, have to catch a bus I'll read the logs later night.
            
-
            13:45 < deer> <peer> hi just a bug report
            
-
            13:45 < jrandom> (as its cut down streaming lib test time by a factor of 5)
            
-
            13:45 < jrandom> cool baffled, ttyl
            
-
            13:46 < deer> <peer> when your net connection goes down, i2p dies
            
-
            13:46 < dm> These are the kind of things that creep up on you, good to get them out of the way while the project is still lean.
            
-
            13:46 < deer> * postman noticed this too a few days ago
            
-
            13:46 < deer> <postman> one of my servers lost its link
            
-
            13:46 < deer> <postman> for a few mins - after that i2p was good for a complete restart
            
-
            13:46 < jrandom> dies, as in, the JVM stops, or the router stops talking to peers?
            
-
            13:47 < jrandom> (it obviously stops talking to peers, i mean, after the net is back up, does it recover?)
            
-
            13:47 < deer> <postman> jrandom: in my case jvm was still running - but no connection lead to success for about 15 minutes
            
-
            13:47 < deer> <postman> jrandom: after that i restarted
            
-
            13:47 < jrandom> hmm, ok, cool
            
-
            13:48 < jrandom> thanks peer, postman.  i'll do some debugging down there
            
-
            13:48 < jrandom> what OSes, btw?
            
-
            13:48 < deer> <postman> jrandom: np - wanted to write you a mail  but forgeot
            
-
            13:49 < deer> <postman> jrandom: Linux 2.4.recent - glibc2.3.recent jvm 1.4.05
            
-
            13:49  * jrandom suspects that this week will be the week of "break shit and make i2p handle it better"
            
-
            13:49 < jrandom> word
            
-
            13:50 < deer> <peer> jrandom: in my case the jvm went completely
            
-
            13:50 < jrandom> did it say OutOfMemory or have any CRIT messages?  or did it create a hs_* file inyour i2p install dir?
            
-
            13:52 < jrandom> perhaps we could dig through the details later, after the meeting
            
-
            13:52 < jrandom> does anyone have anything else on 2) core updates?
            
-
            13:52 < jrandom> if not, on to 3) streaming lib
            
-
            13:53 < dm> yeah
            
-
            13:53 < dm> this increased latency
            
-
            13:53 < dm> do you have an estimated % increase per hop?
            
-
            13:53 < dm> we talking a couple % points or 30-40%?
            
-
            13:53 < jrandom> none, its just some situations it didn't send through an outbound tunnel
            
-
            13:54 < dm> so negligeable... 'kay
            
-
            13:54 < dm> (on average)
            
-
            13:54 < dm> 3)
            
-
            13:54 < jrandom> 0% per hop, but its as if the peer you talk to has tunnels 1 hop longer than before (on average)
            
-
            13:55 < jrandom> not many real visible updates for the streaming lib so far
            
-
            13:55 < jrandom> things work pretty well, and i've been doing a bunch of benchmarks to track the progress during the recent memory updating
            
-
            13:55 < dm> oh throughput numbers!!!
            
-
            13:57 < dm> ping
            
-
            13:57 < deer> <Natalia> .
            
-
            13:57 < jrandom> well, it varied on the message size and per-hop latency injected, but preliminary throughput has been 2-5x faster
            
-
            13:57 < jrandom> it has been CPU bound though
            
-
            13:57 < dm> hmmm, not bad.
            
-
            13:58 < dm> cpu at which end?
            
-
            13:58 < jrandom> the big benefit is in the reduction of data retransmission and the virtual elimination of failure ;)
            
-
            13:59 < jrandom> dm: these tests were done with the sim, injecting random delays per hop
            
-
            13:59 < jrandom> (e.g. 400ms each time, or 1000ms, or 2000ms)
            
-
            13:59 < dm> Is there some kind of priority scheme so that forwarding of messages of tunnels won't be too affected by people trying to download at 30k/s and maxing out their CPU?
            
-
            13:59 < jrandom> (well, the *big* benefit is the sliding window and reordering, but reduction of retransmit is good)
            
-
            14:00 < jrandom> not sure i understand
            
-
            14:00 < dm> Like if I'm downloading porn, will I inject a 3s lag to anyone who's going through me in their tunnels.
            
-
            14:00 < jrandom> (and the transfer rates were much higher than 30KBps, but again, this was local-only with random injected delays)
            
-
            14:01 < dm> I'm just wondering what happens in general if someone is maxing out their CPU, as far as their contribution to the network is concerned.
            
-
            14:01 < dm> I guess it's not specific to abusing the streaming lib.
            
-
            14:02 < jrandom> you're not going to be maxing your CPU doing streaming, the CPU load was something i run into when using the local sim running a ton of routers on a single box
            
-
            14:02 < dm> ah alright, I thought the cpu was maxed with one router trying to encrypt all the bits going down the pipe.
            
-
            14:02 < jrandom> nah, encryption is ReallyReallyFast
            
-
            14:03 < dm> coo'
            
-
            14:03 < jrandom> ok, anyone else have any questions wrt the streaming lib progress?
            
-
            14:03 < jrandom> if not, 4) mail.i2p progress
            
-
            14:04 < deer> <jrandom> postman, you 'round?
            
-
            14:04 < deer> <postman> yo :)
            
-
            14:04 < deer> <postman> ok
            
-
            14:04 < deer> * postman waves
            
-
            14:05 < deer> <postman> well, gentlemen. Some of you may have noticed that we have finally implemented in/out services
            
-
            14:05 < jrandom> [w00t!]
            
-
            14:05 < deer> <postman> please reas www.postman.i2p/inout.html
            
-
            14:05 < deer> <postman> please test the system out
            
-
            14:06 < deer> <postman> baffled will deliver the 2nd official mx
            
-
            14:06 < jrandom> word
            
-
            14:06 < deer> <postman> right now i am working on IMAP implementation
            
-
            14:07 < deer> <postman> this means a switch to maildir format soon
            
-
            14:07 < jrandom> we'll need to recheck various clients for that though, right?
            
-
            14:07 < deer> <postman> right now i am evaluating/testing
            
-
            14:07 < jrandom> cool
            
-
            14:07 < deer> <Natalia> why IMAP and not pop3 ?
            
-
            14:07 < deer> <postman> yeah, and the serverside as well
            
-
            14:08 < deer> <postman> Natalia: we have pop3 already
            
-
            14:08 < deer> <postman> pop3 can be used of course 
            
-
            14:08 < deer> <postman> IMAP4 will make us more flexible for webmail systems (hopefully)
            
-
            14:10 < deer> <postman> this is still open issue
            
-
            14:10 < deer> <Natalia> okay.
            
-
            14:10 < deer> <Natalia> you sounded like you were going to switch from pop3 to IMAP
            
-
            14:11 < deer> <postman> no, of course not
            
-
            14:11 < deer> <postman> jrandom: are there any news concerning locally run webmail?
            
-
            14:12 < jrandom> not to my knowledge.  i havent had time to look into it at all
            
-
            14:12 < deer> * postman neither
            
-
            14:12 < jrandom> there were those discussions of atmail, but they're closed source
            
-
            14:12 < deer> <postman> mmh, yes
            
-
            14:13 < deer> <postman> but something jspish ?
            
-
            14:13 < jrandom> 'twould be a really great way for a volunteer to jump in and do some legword :)
            
-
            14:13 < deer> <Natalia> well, I've added this description to gott.i2p/sites.html
            
-
            14:13 < deer> * postman is completely unable to do research on that matter
            
-
            14:13 < deer> <Natalia> for www.postman.i2p
            
-
            14:13 < deer> <Natalia> postman runs i2p's first mail-service, providing free and anonymous pop3 and SMTP 
            
-
            14:13 < deer> <Natalia> accounts over i2p. Recently implemented is the ability to send and receive e-mails to and 
            
-
            14:13 < deer> <Natalia> from outside of the i2p network, marking the services of www.postman.i2p as a nifty 
            
-
            14:13 < deer> <Natalia> destination for any concerned e-mailer and soon a must-have, as mail.i2p e-mail accounts 
            
-
            14:13 < deer> <Natalia> become the norm for eepsite-authors.
            
-
            14:14 < deer> <Natalia> sound good ?
            
-
            14:14 < deer> <postman> thanks Natalia :)
            
-
            14:14 < deer> <postman> jrandom: i think it's not a urgent issue
            
-
            14:14 < deer> * Natalia curtsies :)
            
-
            14:15 < deer> <postman> jrandom: maybe we pick up the webmail issue later again :)
            
-
            14:15 < jrandom> agreed postman
            
-
            14:15 < deer> <postman> that's all from my side , thanks :)
            
-
            14:15 < jrandom> word, thanks postman
            
-
            14:15 < deer> * postman curtsie too and sits down again
            
-
            14:15 < jrandom> ok, anything else on that, or shall we move on to 5) BT progress?
            
-
            14:16 < deer> <jrandom> dinoman: you 'round?
            
-
            14:16 < dm> Yeah, I'm still waiting for BT to reactivate my ADSL
            
-
            14:16 < jrandom> !thwap
            
-
            14:17 < deer> <duck> dino has done some good work
            
-
            14:17 < deer> <duck> with Ragnarok to fix some ends
            
-
            14:17 < deer> <duck> so far it looks like the current problems are:
            
-
            14:17 < deer> <duck> - SAM unreliability
            
-
            14:17 < deer> <duck> - Python SAM library issues
            
-
            14:17 < deer> <duck> - Incorrect usage of the Python SAM lib
            
-
            14:18 < deer> <duck> - Correct handleing of destination instead of host/ip/port
            
-
            14:18 < deer> <duck> once those are fixed it should work
            
-
            14:18 < jrandom> cool
            
-
            14:19 < deer> <duck> I think it is needed to take a little step back though
            
-
            14:19 < deer> <duck> and agree on how to modify the protocol to properly handle destinations
            
-
            14:19 < deer> <duck> it will be incompatible anyway, so better break it good
            
-
            14:19 < jrandom> i concur
            
-
            14:20 < jrandom> perhaps someone can mock up an overall plan of what needs to be done to various apps/components to get it working
            
-
            14:20 < deer> <duck> each peer has an unique peer_id of 20 bytes
            
-
            14:20 < deer> <duck> it is normally derived from the host/ip
            
-
            14:21 < deer> <duck> I think that using the full destination is a bit much
            
-
            14:21 < deer> <duck> what globally unique thing should we use?
            
-
            14:21 < jrandom> SHA1(destination)[0:19]
            
-
            14:21 < jrandom> perhaps?
            
-
            14:21 < deer> <Ragnarok> first twenty bytes of the dest? :)
            
-
            14:22 < deer> <duck> a sha1 hash is 20 bytes
            
-
            14:22 < jrandom> first 20 bytes of the dest should be pretty random too, enough to deal with random clashes, but not to deal with hostile colisions
            
-
            14:22 < jrandom> even better 
            
-
            14:22 < deer> <dinoman> if you lose the key how do peers find one another
            
-
            14:22 < jrandom> a peer *is* a key
            
-
            14:23 < jrandom> oh
            
-
            14:23  * jrandom misinterpreted
            
-
            14:23 < jrandom> the tracker must give peers the full destination, not the SHA1(destination)
            
-
            14:24 < jrandom> is that the same peer_id in question?
            
-
            14:24 < deer> <dinoman> i have fixed the php tracker to send the full key as the ip
            
-
            14:24 < deer> <duck> actually the client generates the peer_id
            
-
            14:24 < deer> <duck> (what do you mean with 'key'?)
            
-
            14:25 < deer> <dinoman> destination
            
-
            14:25 < dm> Sounds like a who's on first skit.
            
-
            14:25 < dm> Use full sentences people!
            
-
            14:26 < deer> <dinoman> ok fine :/ the tracker sends the Full destination as the ip
            
-
            14:27 < jrandom> heh dont mind dm.  sounds great
            
-
            14:27 < deer> <dinoman> peer id is just for the trackers
            
-
            14:27 < deer> <duck> maybe we could use #i2p-bt
            
-
            14:28 < jrandom> what i think would be useful though is if you (or someone else) could perhaps draft up a list of modifications that'll need to be made
            
-
            14:28 < deer> <duck> so no religious wars start each time the name of the snake is dropped
            
-
            14:29 < deer> <dinoman> works for me
            
-
            14:29 < deer> <dinoman> i don't war if it works it works
            
-
            14:29 < jrandom> (e.g. "tracker sends e full destination as the IP", "client interprets the IP as the full destination", "torrent contains the tracker's destination in the field 'trackerDest'", etc)
            
-
            14:29 < deer> <duck> definitly
            
-
            14:30 < deer> <dinoman> jrandom you got it
            
-
            14:31 < deer> <dinoman> this is the sample output of the tracker 8:intervali300e12:min intervali30e5:peersld2:ip50:klkjlkfsdjfkljkfdhjkddfsjkldsfjlkjfdlkjsfdl;kj;sdf7:peer
            
-
            14:31 < dm> copy/pastes jrandom's sentence into notepad and saves as "draft.txt"
            
-
            14:31 < cat-a-puss> will bt over i2p be intercompatible with other clients that are not over i2p?
            
-
            14:31 < jrandom> cool dinoman
            
-
            14:31 < deer> <dinoman> at ip50 you will see a junk key
            
-
            14:32 < jrandom> cat-a-puss: yes
            
-
            14:32 < deer> <dinoman> yes
            
-
            14:32 < cat-a-puss> then we should talk
            
-
            14:32 < jrandom> welcome to the weekly meeting!  :)
            
-
            14:32 < deer> <dinoman> it will need to be something like .i2ptorrent to make it live togeter
            
-
            14:32 < deer> <dinoman> for filenames and links and what not
            
-
            14:33 < jrandom> are you working on something similar cat-a-puss, or have some ideas for improvements?
            
-
            14:33 < cat-a-puss> working on something similar
            
-
            14:33 < cat-a-puss> in java
            
-
            14:33 < jrandom> cool
            
-
            14:34 < jrandom> is it necessarily java specific, or can some peers be in other langs?
            
-
            14:34 < cat-a-puss> good question, I don't know how to work that sort of thing in java, I'll have to look into it
            
-
            14:35 < deer> <duck> right
            
-
            14:35 < deer> <duck> lets use ugha.i2p to write up some specs
            
-
            14:35 < deer> <duck> .
            
-
            14:35 < jrandom> or perhaps we need a "swarming data transfer" section in the forum so we can all discuss this stuff at our own pace?
            
-
            14:35 < jrandom> or ugha.i2p, of course
            
-
            14:36 < jrandom> (while we work through some bugs in the sam impl and libs :)
            
-
            14:36 < deer> <duck> makes it all a challenge
            
-
            14:37 < deer> <dinoman> hehe ok
            
-
            14:38 < deer> <duck> ...
            
-
            14:38 < deer> <duck> mo bt?
            
-
            14:38 < deer> * dinoman gets back to work on Savane
            
-
            14:39 < jrandom> http://ugha.i2p/SwarmingTransfer / http://ugha.ath.cx/SwarmingTransfer
            
-
            14:39 < jrandom> word
            
-
            14:39 < jrandom> ok, anything else on 5) BT progress?
            
-
            14:39 < jrandom> or shall we hit 6) ???
            
-
            14:39 < jrandom> and ask dinoman how the Savane progress is coming?  :)
            
-
            14:40 < deer> * jrandom cracks whip
            
-
            14:40 < deer> <dinoman> mail i am stuck on using the i2p mail system
            
-
            14:40 < deer> <dinoman> i think i should just take the mail out
            
-
            14:40 < jrandom> is there any way to tell it to use the SMTP server at a different port?
            
-
            14:40 < jrandom> or is the problem authenticated SMTP?
            
-
            14:41 < deer> <dinoman> auth
            
-
            14:41 < protok0l> Uptime: 5d
            
-
            14:41 < protok0l> ii own
            
-
            14:41 < deer> <dinoman> it is not in the class Savane uses
            
-
            14:42 < deer> <dinoman> i can put it in 
            
-
            14:42 < protok0l> i'm "Ident: pxEI" can someone tell me my rating
            
-
            14:42 < jrandom> ok, i bet we can just get postman to set you up with a custom SMTP destination that doesnt require authentication
            
-
            14:42 < dm> I give you a 6/10
            
-
            14:42 < dm> You could work on your ass a bit
            
-
            14:42 < janonymous1> Whats savana
            
-
            14:43 < jrandom> janonymous1: its like sourceforge
            
-
            14:43 < deer> <dinoman> because i am looking at the I2P Public Domain Software Homepage in my browser now
            
-
            14:43 < jrandom> w00t
            
-
            14:45 < deer> <dinoman> that would be cool be what is being done on the server i don't want someone hacking me and the getting the info about the mail server
            
-
            14:45 < deer> <dinoman> that is what bugs me
            
-
            14:45 < jrandom> well, they wouldn't get any info on the mail server, they'd just be able to (at worst) spoof @mail.i2p
            
-
            14:45 < janonymous1> Cool
            
-
            14:46 < jrandom> but yeah, it'd be great to have authenticated SMTP support to prevent that
            
-
            14:46 < jrandom> i dont know how much work that'd be though
            
-
            14:46 < protok0l> well im glad i left my mailserver idea to postman
            
-
            14:46 < protok0l> it seem more difficult than i imagined
            
-
            14:47 < deer> <Ch0Hag> I wouldn't mind helping with that
            
-
            14:47 < dm> protocol
            
-
            14:47 < deer> <Ch0Hag> Got to do something. :-)
            
-
            14:47 < deer> <dinoman> i will do auth :( it will take a little time but i will do it
            
-
            14:47 < deer> <protokol> yes dm
            
-
            14:48 < jrandom> see, you've got a volunteer already dinoman!  :)
            
-
            14:48 < deer> <protokol> maybe i could host a nessus server
            
-
            14:48 < deer> <protokol> and tunnel it through TOR on my side
            
-
            14:49 < deer> <Ch0Hag> Plus I need a  good excuse to work on the rest of  my network.
            
-
            14:49 < deer> <protokol> and i shall dedicate myself to learning python
            
-
            14:49 < janonymous1> 'the i2p software foundation'.  I can see it now
            
-
            14:49 < deer> <protokol> and how to correctly type
            
-
            14:49 < dm> I shall dedicate myself to the pursuit of more money for myself and for those directly related to myself, who may be inclined to give me money in the near future.
            
-
            14:50 < jrandom> ok, anyone else have anything to bring up for 6) ??? 
            
-
            14:50 < dm> 7) $$$
            
-
            14:51 < duck> Roger Dingledine (arma @ freenode) published a draft for a chapter of an upcoming O'Reilly book
            
-
            14:51 < duck> http://freehaven.net/doc/wupss04/usability.pdf
            
-
            14:51 < jrandom> ah, yeah, its pretty good
            
-
            14:51 < duck> it is about anonymity and usability
            
-
            14:51 < dm> chapter on usability?
            
-
            14:51 < deer> <protokol> i can run the i2p software foundation
            
-
            14:51 < deer> <protokol> lol
            
-
            14:51 < duck> some interesting parts about negative imago
            
-
            14:52 < deer> <protokol> give me the keys the the treasury
            
-
            14:52 < duck> having good default
            
-
            14:52 < deer> <protokol> NOW!
            
-
            14:52 < duck> etc
            
-
            14:52 < duck> .
            
-
            14:52 < jrandom> and the importance of usability, even over security at times
            
-
            14:52 < dm> protok0l: you're the user advocate aren't you? You should read that document.
            
-
            14:52 < jrandom> 'k, anything else for the meeting?
            
-
            14:52 < deer> <protokol> wow, im seeing 83 peers
            
-
            14:52 < duck> now we know why there are so few known hidden sides on tor
            
-
            14:53 < deer> <protokol> dm: i shall
            
-
            14:53 < duck> arma is affraid for negative imago
            
-
            14:53 < duck> .
            
-
            14:53 < dm> "imago" ?
            
-
            14:53 < duck> image
            
-
            14:53 < deer> <duck> (psychoanalysis) an idealized image of someone
            
-
            14:53 < dm> No mention of I2P in there :(
            
-
            14:53 < duck> jrandom: aint we?
            
-
            14:54 < jrandom> hm?
            
-
            14:54 < dm> he means aren't we. He's dutch.
            
-
            14:54 < duck> if some specific group now moves to i2p,
            
-
            14:54 < duck> they could keep away much needed other users
            
-
            14:55 < jrandom> oh, thats in there?  i didnt see that
            
-
            14:55 < duck> no, I am saying that
            
-
            14:55 < duck> but it is in there too, more or less
            
-
            14:55 < duck> ofcourse andy anarchist doesnt give a fuck
            
-
            14:56 < jrandom> well, i do think there is room for both i2p and tor
            
-
            14:56 < duck> yes
            
-
            14:56 < duck> but what about early negative image on I2P
            
-
            14:56 < deer> <Natalia> this is the reason I am forced to be a somewhat mundane female on this IRC channel
            
-
            14:56 < protok0l> haha, when i get the word every major anarchist listserv and forum will hear about i2p within a day or 2
            
-
            14:56 < jrandom> oh, i dont give a flying fuck about that duck ;)
            
-
            14:56 < deer> <Natalia> jrandom doesn't approve of got
            
-
            14:56 < deer> <Natalia> *gott
            
-
            14:57 < duck> jrandom: yeah, but well
            
-
            14:57  * duck counts the amount of anarchy friendly regions on the globe
            
-
            14:57 < deer> <Natalia> so I have to be Natalia, the loved female of the channel
            
-
            14:57 < deer> <Natalia> ( lame )
            
-
            14:57 < duck> somalia?
            
-
            14:57 < duck> I bet they have flying fucks there
            
-
            14:57 < protok0l> Chiapas, mexica
            
-
            14:57 < duck> but not friendly ones
            
-
            14:57 < protok0l> mexiico
            
-
            14:58 < deer> <Ragnarok> bah, you want to be feminized
            
-
            14:58 < jrandom> duck: when it comes time to be more public, i'm certain we can put on a reasonable joe sixpack friendly face
            
-
            14:58 < duck> k
            
-
            14:58 < jrandom> will people do "bad" things with i2p?  yeah
            
-
            14:58 < dm> I think we should target joe beergut
            
-
            14:58 < protok0l> good luck, i know gott is planning something
            
-
            14:58 < protok0l> gott will destroy us
            
-
            14:58 < duck> ok
            
-
            14:58 < duck> .
            
-
            14:58 < jrandom> the only way any worthwhile anonymity or security system can survive is to be content neutral
            
-
            14:59 < deer> <Ragnarok> anonymous communication systems can only protect communication.  They don't interfere with good old police work if someone actually *does* something.
            
-
            14:59 < duck> just saying that some links placed on http://127.0.0.1:7657/index.jsp could be bad
            
-
            14:59 < dm> I2P is about technology.
            
-
            14:59 < deer> <Natalia> yes
            
-
            14:59 < jrandom> true enough duck
            
-
            15:00 < duck> and yes, the sitelist.html will turn into a TFE discussion thing all over
            
-
            15:00 < jrandom> well, mmhmm
            
-
            15:00 < deer> <Natalia> content neutrality is something I write about in the latest eeplog entry
            
-
            15:00 < deer> <Natalia> http://gott.i2p/eeplog.html
            
-
            15:01 < jrandom> this is, however, the power of interactive eepsites, like wikis
            
-
            15:01 < jrandom> (e.g. having people register their site with a sitelist.py or whatever)
            
-
            15:01 < deer> <Natalia> jrandom: do you support not support the idea of eepsite crawlers linking to illegal material, being linked from the frontpage ?
            
-
            15:01 < deer> <Natalia> +or
            
-
            15:01 < deer> <Natalia> if you were going to link to the sitelist
            
-
            15:02 < duck> from a moral point I dont give a flying fuck either
            
-
            15:02 < deer> <Natalia> jrandom: none of these are registered
            
-
            15:02 < duck> but from an usability point I might
            
-
            15:02 < deer> <Natalia> the script checks host.txt
            
-
            15:02 < deer> <Natalia> *hosts.txt
            
-
            15:02 < jrandom> from a nontechnical perspective, i support whatever the user community requires
            
-
            15:02 < deer> <Natalia> so everyone gets added to the list if they have a domain
            
-
            15:03 < deer> <Natalia> ugh, bras are so uncomfortable.
            
-
            15:03 < protok0l> yup, creepy
            
-
            15:03 < deer> <cervantes> have you _seen_ the user community?
            
-
            15:03 < cat-a-puss> The simplist solution would be to simply link to search pages, Everyone knows how to use them, they provide fast access, and nobody sees for anything they did not ask for.
            
-
            15:04 < deer> <cervantes> :)
            
-
            15:04 < protok0l> gott is a serial killer, i know it. he will be the first to offer live murders via webcam on i2p
            
-
            15:04 < deer> <Natalia> the user community consists of rather strange people.
            
-
            15:04 < jrandom> good point cat-a-puss, we could just link to files.i2p 
            
-
            15:04 < deer> <Natalia> at the moment, I am forced to be a woman because the lead developer disapproves of the immoral behaviour of my other.
            
-
            15:04 < duck> cat-a-puss++
            
-
            15:04 < deer> <Natalia> we are united through common adventure.
            
-
            15:06 < BS314159> I'm not convinced this is a good idea, but the I2P license is certainly broad enough for people to spin off their own versions, differing only in the local link pages
            
-
            15:06 < deer> <Natalia> well.
            
-
            15:06 < deer> <cervantes> lets hope DrWoo can keep his indices free of corruption
            
-
            15:06 < jrandom> certainly BS314159 
            
-
            15:06 < BS314159> not versions. distributions.
            
-
            15:06 < deer> <Natalia> files.i2p should be one link
            
-
            15:06 < jrandom> BS314159: people can even edit their own local link page
            
-
            15:06 < deer> <Natalia> and then there should be a yahoo-style internet directory link
            
-
            15:06 < protok0l> most people will be wise enuf to use the official version
            
-
            15:06 < jrandom> (in docs/readme.html)
            
-
            15:07 < deer> <Natalia> search engines and internet directories serve different roles
            
-
            15:07 < deer> <Natalia> this is why the directory is there in the first place
            
-
            15:07 < deer> <Natalia> it has been requested as independent of a search engine
            
-
            15:07 < BS314159> so if you want e.g. to target an anti-pornography demographic, find an anti-pornography maintainer who maintains a filtered default start page set
            
-
            15:07 < protok0l> unless they are willing to search for backdoors in third-party versions
            
-
            15:07 < deer> <Natalia> by people
            
-
            15:07 < deer> <Natalia> so I think the search-engine is good
            
-
            15:07 < jrandom> right BS314159 
            
-
            15:07 < deer> <Natalia> but should not be the limit
            
-
            15:07 < deer> <Natalia> search engine, internet directory, wiki, help page
            
-
            15:07 < deer> <Natalia> perhaps.
            
-
            15:08 < jrandom> we already link to fproxy.i2p, and we know what scary evil content they have on that site ;)
            
-
            15:08 < BS314159> I'm not sure I'm on topic, but that seems possible. Is there an open-source content filter that any search-engine maintainers would be willing to implement support for?
            
-
            15:08 < BS314159> I have a feeling I'm not on topic
            
-
            15:08 < protok0l> is the meeting still on?
            
-
            15:08 < jrandom> yes protok0l 
            
-
            15:08 < BS314159> sorry. (silences self)
            
-
            15:08 < deer> <Natalia> jrandom: perhaps you shouldn't link to fproxy.i2p
            
-
            15:08 < deer> <Natalia> it is almost always down
            
-
            15:08 < jrandom> BS314159: i think a cntent filter in the search engine is excessive
            
-
            15:08 < deer> <Natalia> it is down right now, it seems
            
-
            15:09 < protok0l> it is
            
-
            15:09 < deer> <Natalia> according to the recent run of the site-checking script
            
-
            15:09 < jrandom> 'k
            
-
            15:09 < jrandom> well, this has been a good discussion, lots of good ideas
            
-
            15:09 < BS314159> not _the_ search engine. _someone_'s search engine
            
-
            15:10 < deer> * Natalia smiles.
            
-
            15:10 < deer> <cervantes> BS3: aol.i2p ;-)
            
-
            15:10 < jrandom> ok, is there anything else for the meeting?
            
-
            15:10 < deer> <cervantes> whoa...still in the meeting...
            
-
            15:11 < deer> <cervantes> thought I'd missed that by an hour
            
-
            15:11 < jrandom> nope, i was late
            
-
            15:11 < jrandom> ok, if not..
            
-
            15:11  * jrandom winds up
            
-
            15:11  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting115.html b/www.i2p2/pages/meeting115.html
deleted file mode 100644
index d1a19f88..00000000
--- a/www.i2p2/pages/meeting115.html
+++ /dev/null
@@ -1,523 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 115{% endblock %}
-{% block content %}
            I2P dev meeting, November 9, 2004
            
-
            
-
            13:26 < jrandom> 0) hi
            
-
            13:26 < cervantes> lets see the menu before we order :P
            
-
            13:26 < jrandom> 1) 0.4.1.4
            
-
            13:26 < jrandom> 2) Streaming lib
            
-
            13:26 < jrandom> 3) BT progress
            
-
            13:26 < jrandom> 4) addressbook.py
            
-
            13:26 < jrandom> 5) ???
            
-
            13:26 < jrandom> 0) hi
            
-
            13:27  * jrandom waves
            
-
            13:27 < Ragnarok> hi
            
-
            13:27  * cervantes waves
            
-
            13:27 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000485.html
            
-
            13:27 < keysersoze> hi
            
-
            13:27 <+polecat> 5) can be DHTs, like that bamboo thing?
            
-
            13:27 < jrandom> (yeah, i'm late)
            
-
            13:27 < jrandom> cool polecat 
            
-
            13:27  * polecat nips at fingers again!
            
-
            13:27 < jrandom> ok, jumping into 1) 0.4.1.4
            
-
            13:28 <+Ch0Hag> 0.4.1.4 seems to die more than it should
            
-
            13:28 <+Ch0Hag> like - at all
            
-
            13:28 < jrandom> die?
            
-
            13:28 <+Ch0Hag> Though there's a chance that's kaffe's fault.
            
-
            13:28 < jrandom> drop your irc connection, or restart the router?
            
-
            13:28 < jrandom> ah, you're on kaffe?
            
-
            13:29 <+Ch0Hag> the router
            
-
            13:29 <+Ch0Hag> I am.
            
-
            13:29 <+Ch0Hag> Someone has to be :)
            
-
            13:29 < jrandom> on kaffe i've had to double the defaul mem usage (give 'er a -mx128m on startup)
            
-
            13:29 <+polecat> GAH!  No wonder!  I had hawk on ignore.
            
-
            13:29 < jrandom> well, we've got at least 3 people on kaffe these days
            
-
            13:30 < jrandom> other than that, though, how is 0.4.1.4 going for y'all?
            
-
            13:30  * polecat is on kaffe... doesn't know of a better JVM at the moment.
            
-
            13:30 < jrandom> early reports were good, but i havent heard much lately
            
-
            13:30 <+Ch0Hag> I had 64, shall try 128
            
-
            13:30 < Ragnarok> seems good
            
-
            13:30 < keysersoze> jrandom: No major problems here
            
-
            13:30 <@duck> latest major irc outage was mine
            
-
            13:30 <+Ch0Hag> And yes, much of it was OOMing
            
-
            13:31 <@duck> otherwise I think it is a bit unstable (since my bw enabling), but I dont have proof
            
-
            13:31 < jrandom> the throttling on your machine is a bit of a choke point, as e.g. each message you receive is something like 20+ messages that have to be sent out
            
-
            13:32 <@duck> ah
            
-
            13:32 < jrandom> but i agree, irc has been bumpy 
            
-
            13:32 < cervantes> 0.4.1.3 has always been rock solid on my ibm jvm, so I've avoided upgrading at this stage
            
-
            13:32 < cervantes> (22 days uptime)
            
-
            13:32 < jrandom> nice cervantes 
            
-
            13:32 < jrandom> duck: [insert comment describing hopes for new streaming lib here]
            
-
            13:33 < cervantes> baffled's irc server has been a little less bumpy
            
-
            13:33 < jrandom> word, thats a good metric
            
-
            13:33 < keysersoze> cervantes:  What version does he run? (Do you know?)
            
-
            13:33 < ant> <dm> will streaming lib have an effect on IRC, or are the messages too small anyway?
            
-
            13:33 <@duck> I have been a good duck this week, so I'll up the limit a bit
            
-
            13:33 < jrandom> lemmie check keysersoze 
            
-
            13:33 < jrandom> :)
            
-
            13:33 <+polecat> I've got 11 hours uptime.  ;.;
            
-
            13:34 < jrandom> keysersoze: 0.4.1.4
            
-
            13:34 < keysersoze> jrandom: ;) But one could ask him here when he's around
            
-
            13:34 < keysersoze> ok
            
-
            13:34 < jrandom> dm: the new streaming lib will improve resiliance and address failures, but obviously won't improve irc throughput
            
-
            13:34 < jrandom> (router versions are published in the netDb, and i know which routers are his)
            
-
            13:34 < ant> <dm> that's good
            
-
            13:35 < jrandom> ok, do we have anythingelse for 0.4.1.4?
            
-
            13:35 < jrandom> if not, swinging briefly over to 2) streaming lib progress
            
-
            13:36 < keysersoze> no
            
-
            13:36 < jrandom> as mentioned in the notes, more news when its available :)
            
-
            13:36 <+polecat> What would we be able to do with the streaming lib that we would not be able to do before it exists?
            
-
            13:36 < Ragnarok> download large files quickly
            
-
            13:36 < Ragnarok> and DOS the network :)
            
-
            13:36 < jrandom> polecat: transfer arbitrarily large files, transfer at > 4KBps
            
-
            13:37 <+Ch0Hag> and/or reliably?
            
-
            13:37 < jrandom> Ragnarok: *not* dos'ing the network is what i'm working on now ;)
            
-
            13:37 <+protokol> i've noticed over time that if i lose a connection on eepIRC, the reconnects always fail, but if i stop it for a few minutes it connects just fine
            
-
            13:37 <+polecat> It would increase the transfer rate?  o.O
            
-
            13:37 < jrandom> polecat: yes.  the current streaming lib uses a fixed 1 packet window size - waiting for an ack before sending the next message
            
-
            13:37  * polecat nods to protokol, seems so.
            
-
            13:38 < ant> <dm> The streaming lib will allow a new class of TCP-based applications to be usable on I2P. 
            
-
            13:38 < Ragnarok> jrandom: ah, good.  I've been a little concerned about that :)
            
-
            13:38 < ant> <dm> That's the marketing version.
            
-
            13:38 < jrandom> let me just say that throughput looks promising with the new lib.
            
-
            13:39 < jrandom> heh dm
            
-
            13:39 < keysersoze> jrandom: Like the extension to normal TCP, where the sending machine will keep sending even if it hasn't receivved an ACK yet, up to a certain number?
            
-
            13:39 <+polecat> jrandom: Ah, I see how that could be compromising...
            
-
            13:39 < jrandom> right keysersoze, up to a (sliding) window size
            
-
            13:39 < jrandom> (doing all that congestion control / avoidance stuff) [/arm waving]
            
-
            13:40 <+polecat> I also see how it might have congestion problems.  If many packets are sent after a connection is dropped.
            
-
            13:40 < cervantes> will be interesting to see some benchmarks comparisions for i2p BT over the new streaming lib and the old not-so-streaming lib
            
-
            13:40 < jrandom> aye cervantes 
            
-
            13:41 < jrandom> polecat: thats the biggest danger, preventing a network flood, which is why we're deploying cautiously
            
-
            13:41 < ant> <dm> I have a bug to report. Someone remind me when we hit 5.
            
-
            13:41 < cervantes> jrandom: from an application point of view, how transparent will the switch over be?
            
-
            13:42 < keysersoze> polecat: Do the current plans implement a "slow-start" idea, where the window will be 1 first, and then cautiously increased to 2, and ONLY if that works well, to 3, etc. Up to a certain maximum?
            
-
            13:42 <+polecat> Does 0.4.1.4 use the streaming lib, or has it not yet been deployed?
            
-
            13:42 < jrandom> cervantes when 0.4.2 is out, no code changes.  you can even use the streaming lib now if you want, if you specify a magic flag in the environment :)
            
-
            13:42 < cervantes> polecat: that will be with us on 0.4.2
            
-
            13:42 < ant> * dm everyone rushes towards jrandom.
            
-
            13:42 < jrandom> its with you now - see streaming.jar
            
-
            13:42 < jrandom> but disabled by default
            
-
            13:42 < ant> <dm> "flag! flag! flag!"
            
-
            13:43 < keysersoze> jrandom: Ow come on, spoil us and tell which env var ;)
            
-
            13:43 < jrandom> however, the streaming lib is *NOT BACKWARDS COMPATIBLE*
            
-
            13:43 < jrandom> aka you can't use IRC with it
            
-
            13:43 < cervantes> I have an early .1.3 remember ;-)
            
-
            13:43 < jrandom> unless duck runs a seperate newStreamingLib destination
            
-
            13:43 <+polecat> Yeah... probably best to switch in sync then, not individually.
            
-
            13:43 < jrandom> yup
            
-
            13:43 <+Ch0Hag> I think this flag is one of those "if you can't find it, you don't need it" ones.
            
-
            13:43 < ant> <dm> duck: for the love of god, do as you're told!!!
            
-
            13:43 <+Ch0Hag> Like most of GCCs...
            
-
            13:43 < jrandom> right Ch0Hag :)
            
-
            13:44 < jrandom> dm: still some other things to be tested
            
-
            13:44 < jrandom> e.g. this morning mule was helping out test with FUQID
            
-
            13:44 < keysersoze> jrandom: Does that influence any of the hosts.txt keys for existing I2P destinations?
            
-
            13:44 < mule> missed the meeting. end of daylight savings :(.
            
-
            13:44 < jrandom> (and FUQID does eeevil things :)
            
-
            13:45 < jrandom> heya mule, me too :)  you're just in time
            
-
            13:45 < ant> <dm> mule: you haven't missed section 5) ?????
            
-
            13:45 <+Ch0Hag> Oh speaking of fuqid, is there news on stasher?
            
-
            13:45 < ant> <dm> for all you know, ???? might be: GOTO 1
            
-
            13:45 < jrandom> keysersoze: no, the streaming lib isn't involved in that part of things
            
-
            13:45 <+Ch0Hag> Or is  that a big enough topic to wait until 5?
            
-
            13:45 < jrandom> Ch0Hag: no one has heard anything from aum since september, and no one else is doing anything on stasher.
            
-
            13:46 < jrandom> (but there is other DHT stuff to discuss in 5)??? i hear)
            
-
            13:46 <+Ch0Hag> Oh.
            
-
            13:46 <+Ch0Hag> Bummer.
            
-
            13:46 <+Ch0Hag> The freenet devs didn't have their competition ... removed did they?
            
-
            13:46 <+Ch0Hag> :)
            
-
            13:46 < jrandom> heh
            
-
            13:47 <+polecat> The first application of assassination politics.   x3
            
-
            13:47 <+Ch0Hag> Anyway I have nothing else, so I shan't butt in again until 5
            
-
            13:47 < jrandom> ok, there's lots going on in the streaming lib, but discussion will have to wait for later
            
-
            13:47 < jrandom> unless there's somethingelse, we can move to 3) BT progress
            
-
            13:47 < cervantes> </evasion>
            
-
            13:48 < ant> <dm> Doesn't everyone wish jrandom adopted the toad deployment process?
            
-
            13:48 < ant> <dm> Build 3435: streaming lib attempt
            
-
            13:48 < jrandom> duck: ping?
            
-
            13:48 < ant> <dm> Build 3436: streaming lib attempt 2
            
-
            13:48 <@duck> pong
            
-
            13:48 < ant> <dm> Build 3436: streaming lib attempt 3
            
-
            13:48 < jrandom> be nice
            
-
            13:48  * duck takes the mike
            
-
            13:48 < Ragnarok> no, no we don't
            
-
            13:48 <@duck> dinoman, Ragnarok and me have been working on the BT client.
            
-
            13:48 <@duck> - BT protocol analysed and changes specified on http://duck.i2p/i2p-bt/txt/i2p-bt_protocol.txt
            
-
            13:48 <@duck> - dino modified phpbt, info at http://duck.i2p/i2p-bt/txt/tracker.txt
            
-
            13:48 <@duck> dino got the client to talk with the tracker, R and me have improved it a bit.
            
-
            13:48 <@duck> the whole tracker <-> client stuff worked
            
-
            13:48 <@duck> but we got stuck at the python sam library...
            
-
            13:49 <@duck> Connelly has been helping, but also busy
            
-
            13:49 <@duck> and aum is missing
            
-
            13:49 <+polecat> I'm still stunned BT can work at all on i2p...
            
-
            13:49 <@duck> so I threw out pysam, reimplemented BT's RawServer.py and now it kinda works.
            
-
            13:49 < jrandom> (w00t!)
            
-
            13:49 <@duck> hot news: channel #i2p-bt (especially topic with latest release info)
            
-
            13:49 <@duck> now I am working at adding a lot of logging support, to catch some little flaws
            
-
            13:50 < Ragnarok> it's much nicer than the original RawServer.py
            
-
            13:50 < peer> duck: so is it ready for beta testing?
            
-
            13:50 <@duck> (for example during the EndGame it has to timeout and retry to get the last bits)
            
-
            13:50 <@duck> peer: yup
            
-
            13:50 <@duck> a little point of discussion:
            
-
            13:51 <@duck> so far it is python 2.2 (and up) compatible
            
-
            13:51 <@duck> (seems to be the same for bittorrent itself)
            
-
            13:51 <@duck> the logging stuff needs 2.3 though...
            
-
            13:51 < cervantes> yus indeed
            
-
            13:51 <@duck> how bad do you think that is?
            
-
            13:51 < jrandom> my freebsd and linux boxen have 2.3
            
-
            13:51 < ant> <dm> bad?
            
-
            13:52 < jrandom> (though they were installed within the last year)
            
-
            13:52 < Ragnarok> are there any major distros still shipping 2.2?
            
-
            13:52 <@duck> debian-stable still seems to ship 2.2, last time I checked
            
-
            13:52 < jrandom> ah, i'm on debian unstable
            
-
            13:52 <@duck> but then again that is hardly a surprise
            
-
            13:52 <+Ch0Hag> Debian ships 2.3, 2.2, 2.1 and possibly 2.0
            
-
            13:52 <+Ch0Hag> Together.
            
-
            13:52 < Ragnarok> except Debian stable, I think...
            
-
            13:53 <+Ch0Hag> That's what I'm unsure about.
            
-
            13:53 < jrandom> it'd be nice to have 2.2 support - are there no good logging libs for it?
            
-
            13:53 < Ragnarok> silly debian
            
-
            13:53 <@duck> jrandom: you could bundle the 2.3 lib
            
-
            13:54 < Ragnarok> can logging simply be made optional?
            
-
            13:54 <@duck> I guess
            
-
            13:55 < jrandom> well, its really a coder-productivity-tool, so whatever works best for the people coding
            
-
            13:55 < ant> <dm> we can worry about this when I2P + BT becomes popular.
            
-
            13:55 < keysersoze> For whom is this logging necessary? Not for the end-user, I guess, so when deploying, it shouldn't matter that logging isn't possible on some platforms, no?
            
-
            13:55 < ant> <dm> by then maybe 2.3 is standard
            
-
            13:55 < jrandom> 2.2 support would be nice, but i dont think it'd be that bad if 2.3 were required
            
-
            13:55 < cervantes> duck: so the tracker's peer announce list can be made to spew out i2p destinations instead of machine ips?
            
-
            13:56 <@duck> ok, we'll try to abstract the logging lib, with 2.2 use stdout
            
-
            13:56 <@duck> cervantes: http://duck.i2p/i2p-bt/diffs/phpbt-i2p.diff
            
-
            13:56 < jrandom> keysersoze: you want logging deployed on the clients machines so that if/when bugs arise, the dev can get detailed logs
            
-
            13:56 < jrandom> word duck
            
-
            13:56 < cervantes> ta
            
-
            13:56 <+Ch0Hag> heh if anyone's still interested, Woody has python 1.5, 2.0 and 2.1
            
-
            13:56 <+Ch0Hag> :)
            
-
            13:57 <@duck> heh
            
-
            13:57 <@duck> ok, in that case I say require 2.3
            
-
            13:57 <@duck> and fuck woody
            
-
            13:57 < cervantes> think mine is tuck on 1.5 and 2.2
            
-
            13:57 < jrandom> yeah, no need to deal with 2.1
            
-
            13:57 < cervantes> (upgrade time)
            
-
            13:57 < jrandom> heh
            
-
            13:57 <+Ch0Hag> That's the opinion of most Debian users, too
            
-
            13:58 < Ragnarok> addressbook.py requires 2.3
            
-
            13:58 <@duck> there are some interesting sub projects:
            
-
            13:58 < jrandom> ah ok cool Ragnarok 
            
-
            13:58 <@duck> researching the optimal settings for i2p
            
-
            13:58 <+polecat> That little thing requires 2.3?
            
-
            13:58 < keysersoze> jrandom: I agree, but on a small net like now (~100 peers), it's not a problem to have some beta-testers upgrade to 2.2 or 2.3. And once the most blatant bugs are stamped out, the new "real" endd-users shouldn't really need logging. So what I'm saying is: The logging is no problem at this stage, so we agree ;)
            
-
            13:58 < cervantes> when I was pulling apart BT a year or so back, this machine was pushing 6mb/sec through the tracker at times...
            
-
            13:58 <+polecat> Weird... 2.2 must be practically crippled then.
            
-
            13:58 < Ragnarok> 2.3 has better urllib proxy support
            
-
            13:58 <@duck> porting the standard bt tracker too
            
-
            13:58 < cervantes> I mean the seed
            
-
            13:59 < Ragnarok> it could work on 2.2, but it'd be too much effort :)
            
-
            13:59 <+polecat> Ah that would be important, right.
            
-
            13:59 < jrandom> duck: researching the optimal settings will be tough until 0.4.2 comes out
            
-
            13:59 <@duck> right
            
-
            14:00 < jrandom> porting the tracker would be great though. do you have the tools for creating the .torrent implemented, or did you do that manually?
            
-
            14:00 <@duck> whut?
            
-
            14:00 < cervantes> the client has tons of nice tweaks for peer takeup rates, timeouts, min/max peers etc
            
-
            14:01 < cervantes> jrandom: that shouldn't need any modification I think
            
-
            14:01 < jrandom> duck: the .torrent references the i2p destination of the tracker, right?
            
-
            14:01 <@duck> right now we ship: btdownloadheadless.py + btmakemetafile.py + btshowmetainfo.py
            
-
            14:01 < jrandom> or does it reference the name?
            
-
            14:01 < cervantes> it's just a url and a bunch of sha1 hashes
            
-
            14:01 <@duck> though btmakemetafile.py and btshowmetainfo.py are not modified
            
-
            14:01 < jrandom> "a url" is the tough part :)
            
-
            14:02 <@duck> so you can use other tools
            
-
            14:02 <@duck> its http://duck.i2p/phpbt/announce.php now
            
-
            14:02 < jrandom> ok, cool
            
-
            14:02 <@duck> guess you can use http://i2p/bigbase64/announce.php
            
-
            14:02 <+protokol> are their plans for other clients to support eepTorrent? i like azureus
            
-
            14:02 <@duck> plenty
            
-
            14:02 < cervantes> jrandom: the early version I looked at did no url validation on the announce string
            
-
            14:03 < ant> <dm> what does eep stand for again?
            
-
            14:03 < cervantes> you could put anything in there
            
-
            14:03 < jrandom> hmm, worth checking to see if that works duck ( in case phpbt does stupid url rewriting, etc)
            
-
            14:03 < cervantes> dm: look in the forum glossary
            
-
            14:03 <@duck> maybe its time for an i2p-bt forum?
            
-
            14:03 < keysersoze> duck: Especially once new users, that don't have a "registration" in hosts.txt, want to host trackers, it _must_ be possible to have a base64 iin theer
            
-
            14:03 <+Ch0Hag> Eye Eye Pee?
            
-
            14:03 < jrandom> that'd be cool duck
            
-
            14:03 <@duck> (forum section on forum.i2p)
            
-
            14:04 < ant> <dm> cervantes: that was helpful!
            
-
            14:04 < cervantes> duck: yeah no probs
            
-
            14:04 <@duck> keysersoze: it will be investigated
            
-
            14:04 < jrandom> still, as is its pretty bloody cool
            
-
            14:05 < jrandom> the 4KBps per peer isn't really that much of a problem either
            
-
            14:05 < ant> <dm> what time is it? "There's a clock just two blocks down the road"
            
-
            14:05 < cervantes> moving forward oerhaps we should set up a seperate forum space so people can publish files alla suprnova
            
-
            14:05 <@duck> eeprnova
            
-
            14:05 < jrandom> cervantes: with reviews, etc :)
            
-
            14:05 < keysersoze> jrandom: Will the transition to streaminglib require large changes to the current python I2P-BT code?
            
-
            14:05 <+polecat> I sure never get more than 4KBps even on IPv4 bittorrent streams...
            
-
            14:05 < peer> would be good if there were a command line argument for setting the i2p server address, so you can run it from other machines on a network
            
-
            14:05 < jrandom> (but i think that'd be best left outside of the forum.i2p, perhaps)
            
-
            14:06 < jrandom> keysersoze: 0 changes
            
-
            14:06 <@duck> mind you that i2p-bt trackers will scale a lot worse
            
-
            14:06 <@duck> since they have to send bloaty big keys
            
-
            14:06 < Ragnarok> polecat: you must be natted
            
-
            14:06 < keysersoze> polecat: ((OT) try the firefox torrent of today ;))
            
-
            14:06 < cervantes> jrandom: yup.
            
-
            14:06 <@duck> where the normal trackers are recently modified to only send 6 bytes / peer
            
-
            14:06 < jrandom> peer: i2p server address?
            
-
            14:07 < jrandom> peer: i use the i2p-bt with my SAM bridge locally accessing a remote router
            
-
            14:07 < jrandom> oh, but it'd be nice if there were flags to set the SAM bridge location & eep proxy location in the CLI, yeah
            
-
            14:07 < peer> jrandom: yep
            
-
            14:07 < keysersoze> duck: Can we compress the host-key? (Just asking...)
            
-
            14:08 < peer> with one cli arg
            
-
            14:08 < jrandom> (rather than remodifying the code after every release :)
            
-
            14:08 <@duck> keysersoze: using binary instead of base64 will shrink it a bit
            
-
            14:08 <@duck> like 15% 
            
-
            14:08 <@duck> no worth it
            
-
            14:08 < keysersoze> duck: I agree.
            
-
            14:09 < ant> <dm> cervantes: where is this forum glossary? I don't see anything at http://forum.i2p.net/
            
-
            14:09 < Ragnarok> could hostnames be used?
            
-
            14:09 < jrandom> Ragnarok: hostnames are not globally unique
            
-
            14:09 <@duck> Ragnarok: dont want to go there
            
-
            14:09 < cervantes> dm: only shows up for reg'd users
            
-
            14:10 < ant> <dm> cervantes: oh excellent! I'll look for eep on google then!
            
-
            14:10 < Ragnarok> fair enough
            
-
            14:11 < cervantes> dm: it's a phoneme for IIP
            
-
            14:11 < cervantes> is the word on the street
            
-
            14:11 < jrandom> ok, y'all are doing tremendous work on the bt side of things, and i look forward to hearing (and using) more :)
            
-
            14:11 < ant> <dm> cervantes: not an acronym?
            
-
            14:12  * cervantes has 1/2 of a terabyte of movies and tv shows to share
            
-
            14:12 < jrandom> do we have anything else wrt i2p-bt to discuss?
            
-
            14:12 < cervantes> dm: not that I've heard
            
-
            14:12 <@duck> (dont forget #i2p-bt)
            
-
            14:12 < jrandom> yeah, #i2p-bt, finally an incentive for people to move from freenode :)
            
-
            14:12 < ant> <dm> alrighty. Thank you sir.
            
-
            14:13 <+Ch0Hag> As if this Great network wasn't incentive enough already...
            
-
            14:13 < jrandom> ok if not, shall we move on to 4) addressbook.py
            
-
            14:13 < jrandom> Ragnarok: wanna give us the run down?
            
-
            14:13 < Ragnarok> whee
            
-
            14:14 < Ragnarok> hm, ok.  addressbook.py is a first stab at a subscribable address book system.
            
-
            14:14 < Ragnarok> It's pretty ugly at the moment, but it works
            
-
            14:14 < Ragnarok> you can get it at ragnarok.i2p
            
-
            14:14 < peer> can i just make a suggestion re: naming? i think the best method would be for the links between eepsites to use base64, but let people create their own bookmark names for sites, rather than having any centralised naming system
            
-
            14:14 < Ragnarok> um...
            
-
            14:14 < Ragnarok> any questions?
            
-
            14:15 <+postman> Ragnarok: define ugly :)
            
-
            14:15 < jrandom> Ragnarok: kickass
            
-
            14:15 < ant> <dm> jrandom: not a question
            
-
            14:15 <+polecat> What were we talking about again?  @.@
            
-
            14:15 < peer> sort of like the bookmarks on the front page of the freenet web interface, but instead with urls
            
-
            14:15 < cervantes> Ragnarok: is it all command line, or is there a gui?
            
-
            14:15 < Ragnarok> read it, it's ugly :)
            
-
            14:15 < jrandom> peer: agreed, though we need author tools
            
-
            14:15 < cervantes> there weren't any screenies so I lost interest and went away ;-)
            
-
            14:15 < jrandom> peer: though the ?i2paddresshelper helps
            
-
            14:15 <+postman> Ragnarok: ok, thanks - i will check it out
            
-
            14:16 <+polecat> Bah, GUIs are for soccer moms!
            
-
            14:16 < Ragnarok> it's all command line.  It's designed to be run as a daemon.  It doesn't run as a daemon on windows yet, but that's my next project.
            
-
            14:16 < Ragnarok> aside from the cli tool, all interactions are through config files.
            
-
            14:17 < jrandom> perhaps the next step in the namign field is a web interface for managing the entries and subscriptions?
            
-
            14:17 < cervantes> are you basically syndicating your hosts file then?
            
-
            14:17 < Ragnarok> yes
            
-
            14:17 < cervantes> right...cool
            
-
            14:17 < Ragnarok> web interface would be great.  I'm not writing it, though :)
            
-
            14:17 < jrandom> with merges and conflict management
            
-
            14:18 <+polecat> What is the conflict management, besides yelping about it in the log?
            
-
            14:18 < jrandom> yeah, the engine itself is Good Stuff, maybe we can get someone else to jump on the web side of it :)
            
-
            14:19 < Ragnarok> none.  If you want to resolve a conflict, you do it by hand :).  Though, it is a bit easier now.
            
-
            14:19 < jrandom> polecat: yelp & never overwrite an existing entry afaik
            
-
            14:19 < jrandom> (er, what he said)
            
-
            14:19 < cervantes> it would be nice as a sidebar plugin for firefox...
            
-
            14:19 <+polecat> Yes, that's what I had thought.
            
-
            14:19 < cervantes> that's something I could work into my i2p toolbar
            
-
            14:20 < Ragnarok> user changes are never overwritten, so it's reasonably secure against attack
            
-
            14:20 < jrandom> and you should only subscribe to relatively trustworthy peers
            
-
            14:20 < Ragnarok> indeed
            
-
            14:20 < cervantes> maybe a feature to lock entries?
            
-
            14:20 < cervantes> (ie move them to userhosts)
            
-
            14:21 < Ragnarok> entries are are never modified
            
-
            14:21 <+polecat> I like the concept of a myhosts.txt file for entries you want to endorse yourself.
            
-
            14:21 < cervantes> Ragnarok: ah sorry, so you said
            
-
            14:22 < Ragnarok> myhosts.txt is a dirty hack to get around a race condition, but for some reason everyone likes it as an interface thing :)
            
-
            14:22 < jrandom> if people are interested, there are ways to get the i2ptunnel / sam / etc to read from more than just hosts.txt and userhosts.txt
            
-
            14:22 < jrandom> (but only if there's a good solid reason to do so)
            
-
            14:22 < cervantes> Ragnarok: you were meant to pretend that was intentional ;-)
            
-
            14:23  * duck suggest abstracting away from hosts.txt / userhosts.txt
            
-
            14:23 <+polecat> My perl version of addressbook.pl supports the myhosts.txt thing.
            
-
            14:23 < Ragnarok> yeah, that will be part of the big rewrite :)
            
-
            14:23  * polecat notes to duck, you'd have to modify i2ptunnel and sam to do that.
            
-
            14:23 < Ragnarok> first, I want to get feature parity on windows, though.
            
-
            14:24 < jrandom> right duck, as it would have been nice for 0.4.2 if we could flag different destinations as "oldLib" and "newLib" (etc)
            
-
            14:24 <@duck> polecat: you could write the final result to something called 'hosts.txt'
            
-
            14:24 < cervantes> ideally you want a hierachical mini-database of local addresses you can catagorise 
            
-
            14:24 <@duck> but use some other structure towards the user
            
-
            14:24 <+polecat> The final result goes to userhosts.txt
            
-
            14:24 <+polecat> And also a file called "hosts.txt" on the eepsite that is not the system hosts.txt.
            
-
            14:24 <@duck> which is confusing :)
            
-
            14:25 < Ragnarok> I like to be as confusing as possible :)
            
-
            14:25 < MrEcho> hope to have the dns done by the end of the month
            
-
            14:25 <@duck> ok, then let the name depend on the checksum of the content
            
-
            14:25 < cervantes> addressbook.txt? :)
            
-
            14:25 < Ragnarok> the published address book is just called hosts.txt, because that's what it is on dev.i2p
            
-
            14:25 <+polecat> It's possible to call Ragnarok's hosts.txt file something else.  People just have to subscribe to that other filename.
            
-
            14:26 < Ragnarok> true, it's a configuration option
            
-
            14:26 <+polecat> i.e. like going http://polecat.i2p/addressbook instead of http://polecat.i2p/hosts.txt
            
-
            14:26 < MrEcho> fyi, my dns doesnt touch the hosts file .. just like a real dns
            
-
            14:27 <+polecat> Oh yeah, there's that too.  >.<
            
-
            14:27 <@duck> my dns causes world peace
            
-
            14:27 < jrandom> MrEcho: it might be worthwhile to explore interoperability
            
-
            14:27 <+polecat> There's /etc/hosts, jrandom's hosts.txt that i2ptunnel and sam use, and now the hosts.txt published by Ragnarok.
            
-
            14:28 < Ragnarok> I don't think anything that doesn't resolve names locally will ever perform acceptably over i2p, but you're welcome to prove me wrong :) 
            
-
            14:28 < mule> hostile environment :)
            
-
            14:28 < MrEcho> i could make it update the hosts text, but i was hoping to add something in other code
            
-
            14:28 < jrandom> there is some code in cvs (under apps/myi2p) for loading/storing address book entries with the data posted to that feb email, if anyone is interested ;)
            
-
            14:29 <+polecat> ?
            
-
            14:29 < MrEcho> already took a look jr
            
-
            14:30 < jrandom> polecat: http://forum.i2p.net/viewtopic.php?t=141#419
            
-
            14:30 <+polecat> You mean under apps/myi2p/java/src/net/i2p/myi2p
            
-
            14:30 < jrandom> well, yeah, if you want to get specific ;)
            
-
            14:30 <+polecat> More like hideously redundant.  ;3
            
-
            14:31 < jrandom> cool MrEcho, though i'm suggesting that sort of file format for other naming systems too, if people are going to consider replacing hosts.txt
            
-
            14:31 < jrandom> polecat: with good reason (and imho there's no redundancy in that pathname ;)
            
-
            14:31 < Ragnarok> cool.  I'll have a look
            
-
            14:32 < ant> <dm> at least it doesn't say internet three times in there anymore
            
-
            14:33 < jrandom> it'd have to be implemented as a net.i2p.client.naming.NamingService as well - something to load from that local db, but that shouldn't be too hard
            
-
            14:33 <+polecat> Eek!  No, no noo MX records... no CNAME... 
            
-
            14:33 < jrandom> having multiple destinations per name is a good idea though
            
-
            14:33 < ant> <janonymous2> Im partial to an address book/ dns hybrid
            
-
            14:34 < jrandom> an address book is a domain name system :)
            
-
            14:34 <+polecat> jrandom: How many times did you have to call it myi2p?  And how necessary is it to call it i2p if it's already called myi2p?  And is there any question whether or not that mess is a thing of java?
            
-
            14:34 < jrandom> polecat: not all myi2p code will be in java.
            
-
            14:34 <@duck> go back to your cave you perl troll :)
            
-
            14:34 <+polecat> I agree that it's all necessary, not blaming you jrandom, but blaming java and ant.
            
-
            14:35 < jrandom> polecat: and i2p's codebase is unique under the net.i2p namespace, as we don't control the net.myi2p namespace :)
            
-
            14:35  * polecat grunts and crouches under the bridge.
            
-
            14:35 < ant> <dm> polecat: it's called OCD
            
-
            14:35 < jrandom> heh
            
-
            14:35 < jrandom> its called software engineering ;)
            
-
            14:36 <+polecat> Yes, but why put everything in a directory structure parroting the namespace?
            
-
            14:36 <+polecat> Just specify like... in the file "This file is namespace net.i2p"
            
-
            14:36 < jrandom> but anyway, anything else on Ragnarok's kickass naming system?  :)
            
-
            14:36 <@duck> it kicks ass
            
-
            14:36 < Ragnarok> thank you :)
            
-
            14:36 <+polecat> Asseth Kickius.
            
-
            14:36 < jrandom> polecat: there are 1340 java files in i2p
            
-
            14:37 <@duck> I was _shocked_ when I wanted to visit an eepsite and the host was already propagated
            
-
            14:37 < Ragnarok> hehe
            
-
            14:37 < jrandom> :)
            
-
            14:37 <+polecat> Well, not saying it needs to be squashed all in one place.  1340 files seems an awful lot though, isn't there any redundant code in there?  o.O
            
-
            14:38 < Ragnarok> does anyone know a command to kill a windows process by pid?
            
-
            14:38 <@duck> like TCP stack reimplementations? :)
            
-
            14:38 <+polecat> Not to mention fully functional web servers.  c.c
            
-
            14:38 < jrandom> heh
            
-
            14:38 < jrandom> oh, lemmie skip the jetty code..
            
-
            14:39 < keysersoze> (91 peers on the net now!)
            
-
            14:39 < ant> <dm> ragnarok: kill
            
-
            14:39 < jrandom> ok, 389 in router/ and core/ 
            
-
            14:39 < Ragnarok> what versions does that exist on?
            
-
            14:39 <+polecat> That's still a lot for a lousy router... but considering the all and everything not too bad.
            
-
            14:39 < ant> <dm> not sure... Running XP here.
            
-
            14:39 < cervantes> Ragnarook: only if you have the support cd files installed
            
-
            14:40 < Ragnarok> ah
            
-
            14:40  * duck refocuses
            
-
            14:40 < cervantes> Ragnarok: otherwise download sysinternals pskill
            
-
            14:40 < jrandom> ok, anything else for 4) addressbook.py, or shall we move on to 5) ???
            
-
            14:41 < cervantes> Ragnarok: http://www.sysinternals.com/ntw2k/freeware/pstools.shtml
            
-
            14:41 < jrandom> ok, 5) it is
            
-
            14:41 < Ragnarok> neat, thanks :)
            
-
            14:41 < jrandom> polecat: iirc you wanted to bring up bamboo-dht?
            
-
            14:41 < MrEcho> ? meeting right now
            
-
            14:41 <+polecat> :chants: DHT DHT USA USA~/o
            
-
            14:42 <+polecat> Yes indeed.  I'm just looking something up...
            
-
            14:42 < jrandom> yes MrEcho 
            
-
            14:43 <+Ch0Hag> 5?
            
-
            14:43 < jrandom> 5) ???
            
-
            14:43 < MrEcho> heh
            
-
            14:43 <+Ch0Hag> ooh yes, I've found an irrelevant semantic bug
            
-
            14:43 < jrandom> sup Ch0Hag?
            
-
            14:43 <+polecat> There are 79 java files in bamboo source.  There are 253 files total.
            
-
            14:44 <+polecat> The entire project takes 4.6 megabytes in source and support files, before building.
            
-
            14:44 < jrandom> yikes
            
-
            14:44 <+Ch0Hag> in /netdb.jsp, 'our' information is given port first, whereas other peers are given host first
            
-
            14:44 <+Ch0Hag> On the Addresses line
            
-
            14:44 < jrandom> have  you played around with it polecat?
            
-
            14:44 < jrandom> Ch0Hag: the ordering is arbitrary
            
-
            14:45 <+Ch0Hag> And 0.4.1.4 has been up for an hour with 128MB under Kaffe
            
-
            14:45 <+polecat> I haven't had much of a chance.  I played around with circle, and got a nifty graphical representation of a PGP public key, but not bamboo yet.
            
-
            14:45 < ant> <dm> ah yes, ch0hag's insignificant bug report reminded me!
            
-
            14:45 < ant> <dm> on the config page it says "you should either use a service like dyndns or leave the hostname blank. If you leave it blank, your router will autodetect the 'correct' IP address by asking a peer"
            
-
            14:45 <+Ch0Hag> It seems to be host/port on all of them
            
-
            14:45 < MrEcho> Uptime: 54h Memory: 23,506KB
            
-
            14:45 <+Ch0Hag> But hey
            
-
            14:45 <+Ch0Hag> It's not like it really matters.
            
-
            14:46 < ant> <dm> which is great for me, since I have a dynamic IP address and have been waiting for this feature for some time, but when I blank and hit save, it automatically fills the box again with an (incorrect) IP
            
-
            14:46 < cervantes> polecat: do you have a url?
            
-
            14:46 < ant> <dm> Cheers!
            
-
            14:47 < jrandom> hmm dm, it doesnt honor you setting it to empty?  
            
-
            14:47 < jrandom> thats definitely a substantial bug
            
-
            14:47 <+polecat> Yes, moment please.
            
-
            14:47 < Ragnarok> it would be nice if it only recommended filling in the box if you have a real, static hostname.  Or if the box wasn't there...
            
-
            14:47 < jrandom> Ch0Hag: kaffe typically keeps a steady size
            
-
            14:47 <+polecat> http://bamboo-dht.org/
            
-
            14:48 < jrandom> Ragnarok: i'm considering removing that box altogether, leaving it for the hackers to add on /configadvanced.jsp
            
-
            14:48 < ant> <dm> I only care because the instruction paragraph makes me feel like na idiot when I can't get it to blank ;)
            
-
            14:48 < cervantes> polecat: ta
            
-
            14:48 <+Ch0Hag> dm: It's clearly an intelligence test.
            
-
            14:48 <+Ch0Hag> If you can make it stay blank, you pass.
            
-
            14:48 <+polecat> I also notice bamboo seems to compile with jikes and the kaffe jar in approximately 30 seconds.
            
-
            14:48 <+polecat> Uses some weird variables though, JAVAC and JAVAHOME instead of JAVA_HOME
            
-
            14:49 < Ragnarok> jr: I think that's a great idea.  At this point, it's a bit like a newbie trap.
            
-
            14:50 < cervantes> dm: do you click the save button, or hit enter?
            
-
            14:50 < ant> <dm> click save
            
-
            14:50 < ant> <dm>     * Updated bandwidth limits
            
-
            14:50 < ant> <dm>     * Configuration saved successfully
            
-
            14:50 <@duck> polecat: do you plan to take a closer look at it?
            
-
            14:51 <+polecat> I do indeed.  bamboo seems like the best candidate for porting over i2p, and the most "together" DHT project I see out there.
            
-
            14:52 <+polecat> The important thing is whether it "works" or not of course.
            
-
            14:52 < jrandom> bah, who needs functionality, its all about buzzword compatability!
            
-
            14:53 < jrandom> please keep us updated on how it goes
            
-
            14:53 < jrandom> (as i agree, the project does look promising)
            
-
            14:53 <@duck> probably most important is what it offers for transport level modifications
            
-
            14:54 < ant> <janonymous2> Whats the shtick on bamboo?
            
-
            14:54 < jrandom> aye, whether it requires NIO channels or uses plain sockets
            
-
            14:54 < cervantes> heh... bamboo news: "5 Aug Bamboo Now 100% Pure Java...uses Berkely DB Java Edition"   "4 Nov Bamboo No Longer 100% Pure Java...BDB Java sucked..back to C""
            
-
            14:54 < jrandom> (though we /could/ write NIO channels for i2psocket, it'd take some work)
            
-
            14:54 <+polecat> jrandom: Go back to your cathedral, java gargoyle!  X3
            
-
            14:54 <+polecat> Indeed.  If it requires TCP or UDP, or worse... DNS, then we might be hosed.
            
-
            14:54 <+polecat> NIO/
            
-
            14:54 <+polecat> NIO?
            
-
            14:55 <+polecat> All I know is ni'o means change the subject in lojban.
            
-
            14:55 < jrandom> NIO is a New I/O library in java, added in 1.4
            
-
            14:55 <+polecat> I see.  Even plain sockets though, doesn't SAM have analog objects for sockets, and analog read() and write() functions?
            
-
            14:55 < jrandom> yes
            
-
            14:56 < jrandom> if they use plain sockets, its easy as shit
            
-
            14:56 < jrandom> (...whatever that means)
            
-
            14:56 < ant> <janonymous2> Whats bamboo?
            
-
            14:56 < jrandom> bamboo-dht.org
            
-
            14:57 < cervantes> what were the problems with pysam btw?
            
-
            14:57  * polecat nods.
            
-
            14:58 <@duck> cervantes: sending / receiving data
            
-
            14:58 < cervantes> duck: oh is that all? :)
            
-
            14:58 < ant> * janonymous2 /me coweres on his inadequate phone
            
-
            14:58 <@duck> and making / detecting connections
            
-
            14:58 <+Nightblade> it didn't send?
            
-
            14:59 < Ragnarok> oy
            
-
            14:59 <@duck> Nightblade: it probably did something
            
-
            14:59 <+Nightblade> does it work at all?
            
-
            15:00 < cervantes> duck: any thoughts on i2p-bt forum section naming?
            
-
            15:00 < cervantes> d'you want you're own top level, with some subs?
            
-
            15:01 < Ragnarok> hm, I've got to hit the road.  Have a good rest-of-meeting :)
            
-
            15:01 < jrandom> Nightblade: aum was using it, so i'm sure it worked
            
-
            15:01 < jrandom> l8r Ragnarok 
            
-
            15:01 < cervantes> you're = your
            
-
            15:01 < cervantes> cya ragnarok
            
-
            15:02 < ant> <janonymous2> Status on bt?
            
-
            15:02 < jrandom> janonymous: see the meeting logs (once they come out)
            
-
            15:03 < jrandom> speaking of which, is there anything else people would like to bring up in the meeting?
            
-
            15:03 < ant> <janonymous2> Oh, my bad
            
-
            15:04  * cervantes hands jr the egold plated baffer
            
-
            15:04  * jrandom winds up
            
-
            15:04 < jrandom> ...
            
-
            15:04 < jrandom> ...
            
-
            15:04  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting116.html b/www.i2p2/pages/meeting116.html
deleted file mode 100644
index 9a1a1164..00000000
--- a/www.i2p2/pages/meeting116.html
+++ /dev/null
@@ -1,183 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 116{% endblock %}
-{% block content %}
            I2P dev meeting, November 16, 2004
            
-
            
-
            13:05 < jrandom> 0) hi
            
-
            13:05 < jrandom> 1) Congestion
            
-
            13:05 < jrandom> 2) Streaming
            
-
            13:05 <+dinoman> pgforge's key has changed :/ sorry
            
-
            13:05 < jrandom> 3) BT
            
-
            13:05 < jrandom> 4) ???
            
-
            13:05 < jrandom> ah cool, we can do some magic for that
            
-
            13:05 < jrandom> 0) hi
            
-
            13:05  * jrandom waves
            
-
            13:05 < ant> <lucky> hi
            
-
            13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000489.html
            
-
            13:05 < wiht> Hello.
            
-
            13:06 < jrandom> (and we got the notes posted *before* the meeting.  w00t)
            
-
            13:06 < jrandom> might as well jump on in to 1) Congestion
            
-
            13:07 < jrandom> for people who have been hanging around the channel the last few days, you've heard lots of discussions about wtf has been going on, and both this email and duck's post earlier should cover it generally
            
-
            13:07 < jrandom> that said, does anyone have any questions / comments / concerns that they'd like to raise/discuss?
            
-
            13:09 < wiht> What do you mean by "wild peer selection"?
            
-
            13:10 < jrandom> the way our current tunnel building works unfortunately lets things stabalize around the fast peers
            
-
            13:10 < jrandom> if those fast peers don't fail occationally, we simply use them, period, rather than explore beyond them in our tunnel building
            
-
            13:11 < jrandom> that means that when they *do* fail later on, we have pretty much no idea how much capacity the rest of the network has, and as such, choose peers fairly arbitrarily
            
-
            13:11 <+DrWoo> jrandom: what is in the pipeline to use the capacity better?
            
-
            13:12 < jrandom> DrWoo: the 0.4.3 release will include a new way of pooling tunnels so that we can have more 'experimental' backup tunnels (allowing us to learn more about the network without sacrificing performance)
            
-
            13:13 < jrandom> more aggressive load balancing through ATM-style reservations are also in the pipeline, but aren't plotted at a particular release yet (aka we'll do it when we need it)
            
-
            13:14 < ant> <Connelly> bleh
            
-
            13:14 < ant> <Connelly> no meeting yet?
            
-
            13:14 < jrandom> (ATM-style reservations, as in, keep track of how much bandwidth tunnels use, on average, multiply that by the number of tunnels we participate in, and compare that to our bandwidth limits / capacity, using that comparison to accept / reject further tunnel requests)
            
-
            13:15 < jrandom> Connelly: started 10m ago, status notes posted on the list ;)
            
-
            13:15 <+DrWoo> jrandom: what impact will that have on performance?
            
-
            13:15 <+DrWoo> local pc performance
            
-
            13:15  * wiht wonders how many different protocols are being used on the I2P network besides HTTP, IRC, and BT.
            
-
            13:16 < jrandom> DrWoo: the 0.4.3 pooling will give us greater resiliance (less failures), and the reservations will allow for more capacity-based load sharing (aka reduce contention)
            
-
            13:16 < jrandom> neither of those are particularly latency based though
            
-
            13:17 < jrandom> wiht: those three are the main ones used to my knowledge, though some ugly stuff is done over HTTP
            
-
            13:17 < jrandom> thats actually an interesting issue, wrt irc and congestion
            
-
            13:18 < jrandom> what was really killing irc.duck.i2p the other day was the fact that during congestion, duck's irc server still had to pump out 20x the number of messages it received
            
-
            13:19 < jrandom> add on the automatic message resending every.10.seconds.with.no.backoff, and that grows to 120 messages for every line of text ;)
            
-
            13:19 < jrandom> basically what i'm saying is, a decentralized chat protocol would be Good ;)
            
-
            13:19 <+DrWoo> is there such a beast?
            
-
            13:20 < jrandom> (though the new streaming lib will get rid of that 6x overhead)
            
-
            13:20 <+dinoman> is there a good one
            
-
            13:20 < jrandom> i dont know if anyone has evaluated something ala SILC for i2p within the last year
            
-
            13:20 < susi23> pop3 and smtp are _awfully_ slow on i2p
            
-
            13:21 < ant> <duck> silc == irc+somecrypto
            
-
            13:21 < susi23> (as answer on the question, which protocols are used too)
            
-
            13:21 < jrandom> ah, i thought silc got away from the ircd concept
            
-
            13:21 < jrandom> oh, shit, right, i forgot about those two :)
            
-
            13:21 < wiht> susi23: Yes, I forgot that we have mail on I2P now.
            
-
            13:21 < ant> <duck> not far atleast
            
-
            13:21 < jrandom> 'k
            
-
            13:21 < ant> <protok0l> meeting?
            
-
            13:22 < ant> <lucky> rite now protok0l 
            
-
            13:22 < ant> <protok0l> k
            
-
            13:22 < jrandom> ok, do we have anything else for 1) congestion?
            
-
            13:23 < jrandom> if not, moving on to 2) streaming
            
-
            13:23 < jrandom> [see the email]
            
-
            13:24 < jrandom> i've kept all the streaming lib updates out of the history.txt, but you can watch whats going on via the cvs list
            
-
            13:24 < jrandom> (if you're crazy)
            
-
            13:24 < jrandom> i dont really have anythign else to add though.  so, any questions/comments/concerns?  
            
-
            13:25 <+postman> just one
            
-
            13:25 <+postman> thanks :)
            
-
            13:25 < ant> <protok0l> what speed increase will there be
            
-
            13:25 < jrandom> hehe you're supposed to wait until you *get* the software postman ;)
            
-
            13:25 < jrandom> protokol: some.  varies.  
            
-
            13:25 <+postman> jrandom: i would bet on you blindfold
            
-
            13:26 <+DrWoo> jrandom: I'm going to ask you what you hate, is there an ETA on the new streaming lib, the current situation obviously is a point of vulnerability?
            
-
            13:27 < jrandom> if tests this week go well, we can pencil in next week
            
-
            13:27 < jrandom> there'll be services up and running on the new streaming lib before then though, so that we can test it under load conditions
            
-
            13:28 < wiht> As I recall, you are using a simulated network for the tests. Is that still true?
            
-
            13:29 < jrandom> for some of them, yeah
            
-
            13:29 < jrandom> when i dont use the sim, i just run it on the live net
            
-
            13:30 < jrandom> (because i like to abuse your bandwdith ;)
            
-
            13:30 < susi23> you're welcome ;)
            
-
            13:30 <+dinoman> hehe turn it on a see if it blows up?
            
-
            13:31 -!- x is now known as fidd
            
-
            13:31 < jrandom> pretty much - i've got some logging code that essentially dumps the streaming packet headers, allowing me to make sure everything is sent properly and various situations are handled as they should be
            
-
            13:32 < jrandom> the sim'ed tests are more involved though, with perhaps a half dozen unit tests w/ various runtime params
            
-
            13:33 < wiht> How well do the simulation tests reflect observed network usage?
            
-
            13:33 < jrandom> pretty well, as the simulation code is the same as the live network code
            
-
            13:34 < jrandom> i dont have the lag and drop injection perfect in the sim though, but its in the ballpark
            
-
            13:35 < ant> <cat-a-puss> will the new streaming lib use the same interface? Or will Java apps have to do something new?
            
-
            13:35 < wiht> Thanks for clarifying that.
            
-
            13:36 < jrandom> cat-a-puss: same interface.  there are a few additional config options that you might want to tack on when building an I2PSocketManager, but thats a good ol' properties map
            
-
            13:36 < ant> <cat-a-puss> k
            
-
            13:37 < jrandom> k, anything else, or shall we jump to 3) BT?
            
-
            13:38 < jrandom> duck: ping
            
-
            13:38 <@duck> *quack
            
-
            13:38 <@duck> Last week I reported that we had BitTorrent on I2P working. There has been some 
            
-
            13:38 <@duck> confusion but it is anonymous both for trackers and for clients (seeders and leechers).
            
-
            13:38 <@duck> Updates since last week:
            
-
            13:38 <@duck> GUI work (wxPython), included tracker, bugfixes.
            
-
            13:39 <@duck> full list at http://dev.i2p/cgi-bin/cvsweb.cgi/~checkout~/i2p-bt/CHANGES.txt?rev=HEAD
            
-
            13:39 <@duck> also the code is at the CVS on cvs.i2p
            
-
            13:39 <@duck> and got a dedicated eepsite: http://duck.i2p/i2p-bt/
            
-
            13:39 <@duck> The included tracker is very spartanic and you still have to provide the
            
-
            13:39 <@duck> torrents themself somewhere; so DrWoo, thetower and me have been looking at 
            
-
            13:39 <@duck> several alternatives which offer features like suprnova, until I got nuts.
            
-
            13:39 <@duck> *flierp*
            
-
            13:40 < jrandom> w00t
            
-
            13:40 <@duck> Finally bytemonsoon is selected, the original is ugly, but DrWoo has been fixing that,
            
-
            13:40 <@duck> The idea is to improve it some more and release it as an I2P ready tracker solution,
            
-
            13:40 <@duck> see: http://brittanyworld.i2p/bittorrent/
            
-
            13:40 <@duck> meeting the requirements at: http://duck.i2p/i2p-bt/txt/bytemonsoon.txt
            
-
            13:40 <@duck> .
            
-
            13:40 < jrandom> kickass
            
-
            13:40 <+DrWoo> you can check out a couple of small test files on a the nice tracker duck fixed up
            
-
            13:41 <+DrWoo> there's nothing big to gum up the net heh
            
-
            13:41 < jrandom> what, you dont want us to download more episodes of Lost?  :)
            
-
            13:41 <@duck> if thetower's is up..
            
-
            13:42 < jrandom> the bytemonsoon port is looking really nice.
            
-
            13:42 <+DrWoo> I can't get thetower right now here
            
-
            13:42 <+DrWoo> jrandom: it really seems to provide most anything you'd need
            
-
            13:42 <+dinoman> what kind of speed r ppl seeing?
            
-
            13:43 <@duck> ~5kb/s per peer
            
-
            13:43 <+DrWoo> dino: from this side it looks like 4-10K per peer
            
-
            13:43 <@duck> (optimistically, ofcourse there are those shitty adsl folks)
            
-
            13:44 <+dinoman> wow better then i thought
            
-
            13:44 <@duck> til i2p crashes; see 1)
            
-
            13:44 < jrandom> heh
            
-
            13:44 <+DrWoo> dinoman: in other works, it should look pretty impressive with a swarm
            
-
            13:44 <@duck> there have been various calls for improving the GUI
            
-
            13:45 <+DrWoo> dinoman: and some 0 hop peers ;)
            
-
            13:45 <@duck> not many takers on it though
            
-
            13:45 < jrandom> duck (& gang): what can we do to help?
            
-
            13:45 <@duck> you: get the new streaming lib ready
            
-
            13:46 <@duck> gang: look at the todo: http://duck.i2p/i2p-bt/txt/todo.txt
            
-
            13:46 <@duck> lucky is working on a howto
            
-
            13:47 <@duck> DrWoo: anything else?
            
-
            13:47 < jrandom> nice
            
-
            13:47 <+DrWoo> jrandom: can you talk a bit about where you stand regarding the importance (or not) of file sharing(and other popular services currently run over the internet) and what it's means to to I2P's anonymity prospects.
            
-
            13:47 < ant> <lucky> i am?
            
-
            13:48 < ant> <lucky> oh
            
-
            13:48 < ant> <lucky> i am
            
-
            13:48 < ant> <lucky> :)
            
-
            13:48 <+DrWoo> duck: there's always something else heh
            
-
            13:48 < jrandom> file sharing is critical to I2P's success, as its realistically the largest potential pool of users to blend into our anonymity set
            
-
            13:49 < ant> <lucky> uh oh.
            
-
            13:49 < ant> <lucky> So that means i should really, really, work on that howto then.
            
-
            13:49 < jrandom> without a viable large-file-transfer system, we've got to do some wonders for engaging user apps
            
-
            13:50 < jrandom> which we are doing - susi's and postman's work is quite promising
            
-
            13:50 < jrandom> but the market for anonymous email is much less than the market for safe file transfer
            
-
            13:51 < jrandom> while I2P itself scales to whatever size (if things are as we hope ;), we need a large anonymity set to support anything wortwhile 
            
-
            13:51 < jrandom> </my $0.02>
            
-
            13:52 <@duck> what do you think about default settings for those filesharing apps?
            
-
            13:52 < jrandom> that i dont know
            
-
            13:53 <@duck> or isn't that really relevant yet giving todays possibilities
            
-
            13:54 <+DrWoo> duck: there may be some 'thinking outside the box' needed to get over some bumps along the way?
            
-
            13:54 < jrandom> 1 hop tunnels may be relevent for the BT-ers, prior to 0.4.3
            
-
            13:57 < jrandom> ok, do we have anything else for 3) BT?
            
-
            13:57 <@duck> notme
            
-
            13:57 <+DrWoo> thanks to duck and the dudes
            
-
            13:58 <+DrWoo> that was pretty awesome work
            
-
            13:58 < jrandom> aye, y'all are doing a kickass job
            
-
            13:58 <+dinoman> i did not do it
            
-
            13:58 < jrandom> (i love watching the --spew 1 on the btdownloadheadless :)
            
-
            13:58 <@duck> dinoman: you started it
            
-
            13:58 <+Ragnarok> headless spew... sounds dirty
            
-
            13:59 <+DrWoo> dino: pushing the effort along is a real contribution
            
-
            13:59  * Ragnarok will put together a patch for the command line option stuff on the todo list
            
-
            13:59 < jrandom> w00t
            
-
            14:00 < ant> <dm> Don't forget anonymous WWW, that's a big one as well.
            
-
            14:00 < jrandom> dm: yeah, perhaps thousands or tens of thousands, but not the draw of millions
            
-
            14:01 < jrandom> (for outproxy stuff, imho)
            
-
            14:01 < jrandom> ok, if there's nothing else, moving on to good ol' fashioned 4) ???
            
-
            14:01 < jrandom> anything not yet raised that should be?
            
-
            14:02 < wiht> postman: What is the status of the mail system? How well is it working, especially with respect to communications outside the I2P network?
            
-
            14:02 <+DrWoo> dm: it's all part of life's rich pageant :)
            
-
            14:03 < ant> <dm> a lotta people use da web
            
-
            14:03 < ant> <dm> (they just installed surfcontrol at my workplace) ;)
            
-
            14:03 < jrandom> aye, anonymous www hosting will be critical for those who really need i2p, though they probably won't be the anonymity set necessary 
            
-
            14:03 < jrandom> ah, lame
            
-
            14:04 < jrandom> wiht: if he's not around, i can say that in and outproxy has worked pretty well for me - none lost yet
            
-
            14:04 < jrandom> (and checking my mail takes a few seconds, but biff tells me when i need to anyway)
            
-
            14:05 < jrandom> ok, is there anything else?
            
-
            14:06 < ant> <dm> are you baffing the meeting?
            
-
            14:07 < jrandom> seems like it
            
-
            14:07  * jrandom winds up
            
-
            14:07  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting117.html b/www.i2p2/pages/meeting117.html
deleted file mode 100644
index 354884a0..00000000
--- a/www.i2p2/pages/meeting117.html
+++ /dev/null
@@ -1,70 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 117{% endblock %}
-{% block content %}
            I2P dev meeting, November 23, 2004
            
-
            
-
            13:03 < jrandom> 0) hi
            
-
            13:03 < jrandom> 1) Net status
            
-
            13:03 < jrandom> 2) Streaming lib
            
-
            13:04 < jrandom> 3) 0.4.2
            
-
            13:04 < jrandom> 4) Addressbook.py 0.3.1
            
-
            13:04 < jrandom> 5) ??? 
            
-
            13:04 < jrandom> 0) hi
            
-
            13:04  * jrandom waves
            
-
            13:04 <+postman> hi :)
            
-
            13:04 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-November/000490.html
            
-
            13:05 < jrandom> well, might as well jump on in to 1) net status
            
-
            13:05 < jrandom> i dont have much to add to this that wasn't in the email
            
-
            13:05 < jrandom> anyone have anything they want to bring up wrt the network status over the last week?
            
-
            13:06 < jrandom> if not, we can jump on down to 2) streaming lib
            
-
            13:06 < jrandom> there's lots of info in the mail about this, so i'll let y'all digest a bit
            
-
            13:07 < jrandom> while the new lib will improve lots of things, the most important (imho) is its resiliance and handling of congestion
            
-
            13:08 < jrandom> especially the latter, as we've seen how things get funky with the old lib under heavy congestion
            
-
            13:08 < jrandom> there's also a lot of things left out of the lib though, places for people to experiment and optimize further
            
-
            13:09 < jrandom> anyone have any questions wrt this, or have we been beating a dead horse by discussing it each week for the last month?  ;)
            
-
            13:10 <+Ragnarok> we'll call that a yes
            
-
            13:10 < jrandom> heh
            
-
            13:10 < jrandom> ok, moving on to 3) 0.4.2
            
-
            13:10 < jrandom> out real soon, just doing some minor updates to the install process at the moment
            
-
            13:11 <+postman> yesss
            
-
            13:11 <+postman> :)
            
-
            13:11 < jrandom> the updated install proc will be a bit nicer for people, addressing the most common user errors
            
-
            13:12 < jrandom> (since no one ever reads the text on the router console ;)
            
-
            13:12 < jrandom> but that should be ready in the next day or two, so with some testing we should have a release out by friday
            
-
            13:12 < jrandom> (if not sooner)
            
-
            13:13 < jrandom> as i mentioned in the mail though, its both backwards compatbile and /not/ backwards compatible
            
-
            13:13 <+Ragnarok> awesome
            
-
            13:13 < jrandom> does anyone have any strong preferences as to how we should do that tap dance?
            
-
            13:13 < jrandom> should we just push out 0.4.2 and let people upgrade when they notice they cant reach any eepsites?
            
-
            13:14 < jrandom> (or will they uninstall it and say "dood i2p sux0rz")
            
-
            13:14  * jrandom neither
            
-
            13:15 <+Ragnarok> I'd say mark it as not compatible.  It's always better to be explicit.
            
-
            13:15 < jrandom> well, the docs and announcement will say not compatible, mandatory upgrade in big bold letters
            
-
            13:16 <+Ragnarok> no reason to send mixed messages, then
            
-
            13:16 < jrandom> aye
            
-
            13:16 < jrandom> though we would be able to tunnel route through those old peers
            
-
            13:16 < jrandom> i dunno, we've got a few days to finalize the decision anyway
            
-
            13:17 < jrandom> just something to think about, and a WARNING to people that they'll NEED TO UPGRADE TO 0.4.2 
            
-
            13:17 < jrandom> :)
            
-
            13:18 < jrandom> ok, anyone have any questions/comments/concerns wrt 0.4.2, or shall we move on to 4) addressbook.py?
            
-
            13:18 < jrandom> consider us moved
            
-
            13:18 < jrandom> Ragnarok: wanna give us an update?
            
-
            13:20 <+Ragnarok> sure.  Minor update released yesterday.  Fixes some bugs on windows, and doesn't violently die if the proxy isn't there.  Only really notable thing is that this will probably be the last release for this version, barring a giant bug.
            
-
            13:20 < jrandom> ok cool
            
-
            13:21 < jrandom> avoiding violent death is always a nice feature to have
            
-
            13:21 < lba> hi folks
            
-
            13:21 <+Ragnarok> I'm planning on redesigning (just designing, really) it from the ground up based on jrandom's thoughts from the mailing list.  Possibly in java too, if I can figure out the xml parsing and http stuff I'll have to do.
            
-
            13:21 < jrandom> wikked :)
            
-
            13:21 < jrandom> 'lo lba
            
-
            13:22 <+Ragnarok> well, that's all.  Carry on.
            
-
            13:22 < jrandom> cool, thanks for the update
            
-
            13:22 < jrandom> ok if there's nothing else on that, we can move on at a blazing pace to 5) ???
            
-
            13:22 < jrandom> anyone else have something they want to bring up?
            
-
            13:23 <+Ragnarok> anyone else here?
            
-
            13:23 < jrandom> heh, yeah, we dont have our usual malcontents ;)
            
-
            13:24 < jrandom> then again, they'll show up to read the logs on the site later [yeah, i mean *YOU*]
            
-
            13:24 < jrandom> ok, i think thats probably the shortest meeting we've had in over a year
            
-
            13:25 < jrandom> might as well wraper 'er up
            
-
            13:25  * jrandom winds up
            
-
            13:25  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting118.html b/www.i2p2/pages/meeting118.html
deleted file mode 100644
index 268c2470..00000000
--- a/www.i2p2/pages/meeting118.html
+++ /dev/null
@@ -1,324 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 118{% endblock %}
-{% block content %}
            I2P dev meeting, November 30, 2004
            
-
            
-
            13:08 < jrandom> 0) hi
            
-
            13:08 < jrandom> 1) 0.4.2 and 0.4.2.1
            
-
            13:08 < jrandom> 2) mail.i2p
            
-
            13:08 < jrandom> 3) i2p-bt
            
-
            13:08 < jrandom> 4) eepsites
            
-
            13:08 < jrandom> 5) ???
            
-
            13:09 < jrandom> 0) hi
            
-
            13:09 < jrandom> sorry to interrupt dm's agenda
            
-
            13:09 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000492.html
            
-
            13:09 < jrandom> [hi]
            
-
            13:10 <+postman> ((hi))
            
-
            13:10 <+postman> :)
            
-
            13:10 < jrandom> so, as y'all read through that overwhelmingly interesting email, we might as well get the meeting underway
            
-
            13:10 < jrandom> 1) 0.4.2 and 0.4.2.1
            
-
            13:11 < jrandom> 0.4.2 is out, as you know, and the results are mixed, but when its not failing bad, it seems to be doing much better ;)
            
-
            13:12 < jrandom> there will be a release with a whole slew of bugfixes soon - i've been holding off to try to get as many things improved as possible
            
-
            13:12 < jrandom> as things stand now though, it looks like the 0.4.2.1 release will not yet get the i2p-bt port into tip top shape quite yet
            
-
            13:12 <+postman> jrandom: what do the bugfixes address - all errors in the new streaminglib or other stuff as well?
            
-
            13:13 < jrandom> a fast busy loop in the streaming lib that came up from a poorly tested scenario, some SAM issues, IP address detection problems, among other things
            
-
            13:14 < jrandom> dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/history.txt?rev=HEAD has the full list
            
-
            13:14 <+postman> k
            
-
            13:14 <+postman> thx
            
-
            13:15 < jrandom> oh, one thing to note about 0.4.2.1 is that it, like 0.4.2, will need to modify your wrapper.config again, so please pay attention to the update instructions when they're out :)
            
-
            13:15 < jrandom> does anyone have any questions/comments/concerns about 0.4.2?
            
-
            13:15 < jrandom> (/0.4.2.1)
            
-
            13:16 < clayboy> been working great here, have been tracking cvs too, always smooth
            
-
            13:16 < jrandom> wikked
            
-
            13:17 < bla> It's table (0.4.2): up for days already
            
-
            13:17 < bla> s/table/stable/
            
-
            13:17 < jrandom> ah nice, yeah, the bugs havent been hitting everyone
            
-
            13:17 < jrandom> ok, if there's nothing else on that, lets jump on to 2) mail.i2p
            
-
            13:18 < jrandom> i hear postman has some things to discuss
            
-
            13:18 <+postman> hello
            
-
            13:18 < jrandom> hi postman, you're up :)
            
-
            13:18 <+postman> weeks ago i conducted a poll regarding IMAP
            
-
            13:19 <+postman> since a few weeks passed now i decided to close the polls and to count the vote
            
-
            13:19 <+postman> result is: not needed - won't be done. period
            
-
            13:19 <+postman> after talking to susi - she was quite fine wioth pop3 on her webmail interface
            
-
            13:19 < clayboy> reason wins! :)
            
-
            13:19 < jrandom> w3wt
            
-
            13:20 <+postman> so let's just stick to the pop3 end bury any silly imap ideas
            
-
            13:20 <+postman> :)
            
-
            13:20  * jrandom gets the shovel
            
-
            13:20 <+postman> 2.) we're close to 100 registered users
            
-
            13:21 < clayboy> wow
            
-
            13:21 <+postman> not all of them public of course, but it still sounds like a quite reasonable number regarding the size of the network 
            
-
            13:21 <+Ragnarok> so... how about that LDAP address book? :)
            
-
            13:21 < jrandom> nice
            
-
            13:21 <+postman> 3. a feature to upload/share you public pgp key is active since weekend
            
-
            13:21 <+postman> please use it 
            
-
            13:21 <+postman> www.postman.i2p/user/acc.html
            
-
            13:22 < clayboy> i'm not taking any credit for that idea :>
            
-
            13:22 <+postman> the public keys can easily be downloaded with the help of the addressbook
            
-
            13:22 <+postman> or direct as www.postman.i2p/public/accountname.pub
            
-
            13:22 < jrandom> ooh cool
            
-
            13:22 <+postman> the system works quite fine
            
-
            13:22 <+postman> thanks to duck for pointing at a few bugs
            
-
            13:23 <+postman> 4.) i think about offering accountbased routing
            
-
            13:23 <+postman> like ppl say
            
-
            13:23 < jrandom> account based routing?
            
-
            13:23 <+postman> all mail for foo@mail.i2p gets transported to the following destination 
            
-
            13:23 <+postman> and user presents a valid destination key for it
            
-
            13:24 <+postman> postman.i2p will then manually route mail to those accounts to mailsystems
            
-
            13:24 <+postman> just an idea(tm)
            
-
            13:24 < jrandom> ah nice
            
-
            13:24 <+postman> i am looking forward to develop and discuss the whole matter
            
-
            13:25 <+postman> that's it for now
            
-
            13:25 <+postman> more follows next week
            
-
            13:25 <+postman> thanks
            
-
            13:25 < nmi> postman: sorry, transported to a particular i2p destination you mean?
            
-
            13:25  * postman hands the mike back to jrandom 
            
-
            13:25 <+postman> nmi: yes
            
-
            13:25 < ant> <Nightblade> am SMTP i2p destination?
            
-
            13:25 < ant> <Nightblade> an
            
-
            13:25 <+postman> nmi: provided the destination accepts smtp and mail for that account
            
-
            13:25 < jrandom> that sounds very cool, gets rid of the trust aspect of the mail fiiltering
            
-
            13:26 < nmi> ah, ok. clever. i had thought of doing something similar using mixminion single-use-reply-blocks but your idea is better...
            
-
            13:26 < jrandom> its probably a lot of work to set up on the client side, but perhaps someone could do some hacking
            
-
            13:26 <+postman> jrandom: i am working on it
            
-
            13:26 < jrandom> w00t
            
-
            13:26 <+postman> jrandom: the user will have the usual webinterface ( acc.html...)
            
-
            13:27 <+postman> jrandom: and inserts the destinationkey
            
-
            13:27 < jrandom> well, right, but then there's the MTA configuration
            
-
            13:27 <+postman> the rest will be done automatigally
            
-
            13:27 <+postman> yes, on the postman.i2p AND the receiving sinde
            
-
            13:28 < nmi> jrandom: yeah, it would be cool to have a really stripped down smtp proxy for people not wanting to run a full MTA
            
-
            13:28 < jrandom> right right
            
-
            13:28 <+postman> jrandom: i will provide a simple setup config for ppl interested
            
-
            13:28 <+postman> jrandom: for postfix, exim and sendmail
            
-
            13:28 <+postman> jrandom: those can be stripped down to BARE necessities
            
-
            13:28 <@duck> seriously, do you think that there are many users for that?
            
-
            13:28 < jrandom> postman: this all sounds pretty kickass.  i look forward to hearing more when you're ready
            
-
            13:29 <+postman> jrandom: no idea about windows smtp servers tho
            
-
            13:29 <+postman> duck: well
            
-
            13:29 <+postman> duck: 8 weeks ago there was no need for a mailsystem and no users either
            
-
            13:29 <+postman> duck: it's investment
            
-
            13:29 <@duck> true
            
-
            13:29 <+postman> duck: in 6 months we'll be happy to have it
            
-
            13:29 < jrandom> duck: the potential comes with moving away from a trusted SMTP filter
            
-
            13:29 <+postman> :)
            
-
            13:30 < jrandom> er, perhaps i should say, moving /to/ a trusted smtp filter (no offense postman ;)
            
-
            13:30 <+postman> and there will be a few ones
            
-
            13:30 <+postman> AND
            
-
            13:30 <+postman> (now the punchline)
            
-
            13:30 <+postman> we could easily create maildomains :)
            
-
            13:30 <+postman> like duck@duck.i2p and other stuff
            
-
            13:30 <+postman> :)
            
-
            13:30 <@duck> ah
            
-
            13:31 <+postman> the only problem would be the official/private mapping
            
-
            13:31 < jrandom> hosts.txt!
            
-
            13:31  * jrandom ducks
            
-
            13:31 <+postman> but this is another thing for the webmanagement console :)
            
-
            13:31 <+postman> LOL
            
-
            13:31 <+postman> jrandom: i rely on shaky sql databases :)
            
-
            13:31 <@duck> ok; I see it fitting in
            
-
            13:32 <+postman> ok
            
-
            13:32 <+postman> then i will work it out and present an concept soon
            
-
            13:32 <+postman> yess, yet more work
            
-
            13:32  * postman leans back relaxed
            
-
            13:32 <+postman> :)
            
-
            13:32 < jrandom> kickass, thanks postman 
            
-
            13:33 < jrandom> ok, unless other people have further mail.i2p related questions, shall we move on to 3) i2p-bt?
            
-
            13:33 < jrandom> consider us moved
            
-
            13:34 < jrandom> ok, as the email mentioned, i broke the i2p-bt port
            
-
            13:34  * jrandom hangs head in shame
            
-
            13:34 < jrandom> in other news, duck, do you have anything wrt i2p-bt you want to discuss?
            
-
            13:34 <@duck> as a result of jrandom's work not much has been done :)
            
-
            13:35 <+Ragnarok> booo, hissss
            
-
            13:35 <@duck> oh Ragnarok had some patches
            
-
            13:35  * jrandom2p pelts jrandom with tomatoes
            
-
            13:35 <@duck> I think, see the history file :)
            
-
            13:35 < jrandom> oh cool
            
-
            13:35 <@duck> we got some things in the queue too
            
-
            13:35 <+Ragnarok> well, I was hissing at jr, but ok :)
            
-
            13:36 <@duck> but I dont want to change (too) much on the unstable ground
            
-
            13:36 <@duck> (like breaking bt while i2p is getting fixed)
            
-
            13:36 < jrandom> aye, good plan
            
-
            13:36 <@duck> .
            
-
            13:37 < jrandom> ok cool, anyone else have anything on i2p-bt?
            
-
            13:37 < jrandom> if not, moving us along to 4) eepsites
            
-
            13:38 < jrandom> well, i know the issues have been discussed a few times since we first got the eepproxy, but there have been some recent queries warranting their mention again
            
-
            13:39 < bla> yes...
            
-
            13:39 < jrandom> what we have now for browsing eepsites and normal websites anonymously just plain isn't safe
            
-
            13:39 < clayboy> disabling java, javascript, cookies and flash helps, though
            
-
            13:39 < jrandom> DrWoo has done a great job with his page describing the dangers and how you can protect yourself
            
-
            13:40 < jrandom> right clayboy, definitely
            
-
            13:40 < clayboy> url?
            
-
            13:40 < bla> clayboy: Yes, on the HTML side, but not on the HTTP side
            
-
            13:40 < jrandom> but if there's one thing i've learned with the router console, its that no one follows more than two steps into the instructions ;)
            
-
            13:40 < clayboy> bla: good point
            
-
            13:40 < jrandom> clayboy: http://brittanyworld.i2p/browsing/
            
-
            13:41 < bla> I've done some experiments here: http://forum.i2p/viewtopic.php?t=182
            
-
            13:41 < bla> Doesn't look good as it is
            
-
            13:42 <@duck> who has the evil applets?
            
-
            13:42 < ant> <Nightblade> there was a security exploit found in java
            
-
            13:43 < ant> <Nightblade> for some older 1.4.x vers
            
-
            13:43 < ant> <Nightblade> not 1.5
            
-
            13:44 < jrandom> nightblade: the 'attack' used in this person's case was really trivial, and, according to the person, worked from 1.1.6-1.5
            
-
            13:44 < ant> <Nightblade> hmm
            
-
            13:44 < jrandom> (download a .exe, run the .exe)
            
-
            13:45 < jrandom> i was suprised to see some java security permissions fire up on instantiation of new File(filename) but no security permissions fire up on instantiation of new FileOutputStream(filename)
            
-
            13:45  * jrandom stops handing out hand grenades
            
-
            13:46 < jrandom> (i havent verified their code, but did see much of it)
            
-
            13:46 < jrandom> but anyway, eepsites
            
-
            13:47 < jrandom> well, i dont think it would be prudent to remove the eepproxy altogether
            
-
            13:47 < jrandom> but i dont really have time right now to implement any of the solutions listed
            
-
            13:48 < bla> jrandom: Stripping out all Accept* headers would be a good thing, for now
            
-
            13:48 < jrandom> what do y'all think?  any volunteers?  shall we wing it until we do get time?
            
-
            13:48 < ant> <Nightblade> bla: I don't think it is a big deal that people can see some browser headers
            
-
            13:49 < ant> <Nightblade> millions of people use those browsers
            
-
            13:49 < bla> And always adding a User-Agent: header, even if the client didn't send one. I makes requests homogeneous
            
-
            13:50 < bla> Nighblade: Yes, but if your browser says Accept-Language: xx (just made up on the spot), and there happens to be only 1 I2P node in a country that speaks language xx, almonimity is gone, completely
            
-
            13:50 < bla> The Accept-Language: header is there though, in some browsers. And we can't rely on it always being "en"
            
-
            13:50 < ant> <Nightblade> ok but what if removing some of those headers violates the HTTP spec?
            
-
            13:50 < jrandom> adding those two cases are easy enough, and i'll get them into 0.4.2.1, but it really isn't safe to explicitly filter headers like this
            
-
            13:50 < jrandom> nightblade: we break so many aspects of the HTTP spec it hurts
            
-
            13:51 < bla> Nightblade: Only one of the threee browsers I listed did send the header, so it shouldn't be much of a problem
            
-
            13:51 < ant> <Connelly> HTTP was not designed for anonymity
            
-
            13:51 < jrandom> the eepproxy is duct tape and shoe polish
            
-
            13:51 < bla> jrandom: Why isn't that filttering safe?
            
-
            13:52 < bla> jrandom: We could even consider stripping _all_ headeers, except for the Host: header and the GET header
            
-
            13:52 < jrandom> bla: stripping all headers except the host would be safer, yes
            
-
            13:52 < bla> jrandom: After all, what do we need more for an anonymous HTTP?
            
-
            13:52 < jrandom> but thats beyond the amount of time i can put into it
            
-
            13:52 < jrandom> i can add the Accept and user-agent filters in ~ 30s
            
-
            13:53 < jrandom> much beyond that and i throw my hands in the air and rewrite the http proxy ;)
            
-
            13:53 < bla> jrandom: How come stripping all of them is more difficult?
            
-
            13:53 < jrandom> read the code.  
            
-
            13:54 < jrandom> (patches welcome)
            
-
            13:54 < jrandom> but what we're looking at here is still just a short term solution
            
-
            13:54 < bla> jrandom: Point well taken ;)  But seriously: I think the Accept* and User-Agent fixes would do really fine for now
            
-
            13:54 < jrandom> we need someone to work on something that will last us long term
            
-
            13:55 < ant> * dm just ate 20 slices of cheese... drool.
            
-
            13:55 < jrandom> bla: i heard that last time someone asked us to filter the User-agent and referrer headers ;)
            
-
            13:55 < jrandom> (but yeah, i'll get those two into the next rev)
            
-
            13:56 < ant> <dm> those headers are usefl
            
-
            13:56 < ant> <dm> useful
            
-
            13:56 < ant> <dm> For service providers.
            
-
            13:56 < jrandom> yes, they are
            
-
            13:57 < jrandom> we've already had some apps break because we filter referrer too
            
-
            13:57 < bla> dmm: Yes, indeed. However, they also provide a browser or OS fingerprint
            
-
            13:57 < ant> <dm> I have an idea!
            
-
            13:57  * jrandom takes cover
            
-
            13:58 < ant> <dm> Hard code the User-Agent to: Nokia6230/2.0 (03.15) Profile/MIDP-2.0 Configuration/CLDC-1.1 149.254.201.133 
            
-
            13:58 < ant> <dm> eh? eh?
            
-
            13:58 < jrandom> we already hard code the user agent header
            
-
            13:59 < ant> <Nightblade> I2P-enabled cell phones
            
-
            13:59  * jrandom mounts a DoS on that phone
            
-
            13:59 < ant> <dm> To what?
            
-
            13:59 < ant> <dm> My poor phone!!!
            
-
            13:59 < jrandom> ok, anyone else have any thoughts on the eepproxy/eepsite stuff?
            
-
            14:00 < bla> MYOB/6.ss (AN/ON)
            
-
            14:00 < bla> no\
            
-
            14:00 <+Ragnarok> we should reinvent html using s-expressions!
            
-
            14:01 < jrandom> (i really do think using a bbcode style macro language is the way to go, at least for some things ;)
            
-
            14:01 < jrandom> ((or xml for you geeks))
            
-
            14:02 < ant> <dm> Microsoft endorses use of XML
            
-
            14:02 < ant> <dm> So I'm all for it.
            
-
            14:02 <+Ragnarok> xml is just excessively wordy s-expressions :)
            
-
            14:03 < ant> <dm> Is this a good time for me to aplaud jrandom for his work on this project?
            
-
            14:03  * jrandom volunteers Ragnarok to work on it, after getting the next gen address book ;)
            
-
            14:03 <@duck> I dont think that 'invent your own markup language' will work for general browsers
            
-
            14:04 <@duck> maybe for the blog thing inside myi2p
            
-
            14:04 <+Ragnarok> it's always a good time :)
            
-
            14:04 < ant> <dm> applaud even
            
-
            14:04 < jrandom> duck: the proxy will need to filter content anyway, it would be simple enough (heh) to inject the results of macro expansions into the resulting filtered content
            
-
            14:05 < ant> * dm tips his hat to jr.
            
-
            14:05 < jrandom> gracias dm et al
            
-
            14:05 < ant> <Nightblade> something like PDF would be safer than HTML
            
-
            14:05 < jrandom> lol
            
-
            14:05 <@duck> .txt files!
            
-
            14:06 < ant> <Nightblade> i've seem PDF files with clickable links, but the files themselves are huge
            
-
            14:06 < ant> <Nightblade> seen
            
-
            14:06 < ant> <dm> Uncompressed Bitmaps?
            
-
            14:06 < jrandom> yes, lets all write in pdf
            
-
            14:07 <+Ragnarok> erg, postscript is fugly
            
-
            14:07 < ant> <cat-a-puss> how is html insecure?
            
-
            14:07 <@duck> anyway
            
-
            14:07 < ant> <Nightblade> cat: with javascript, activex, applets,...
            
-
            14:07 < jrandom> cat-a-puss: all the different ways to encode dangerous data
            
-
            14:08 < ant> <dm> languages aren't secure or insecure, clients are.
            
-
            14:08 <+Ragnarok> the realy problem is how to do anon dhtml...
            
-
            14:08 < jrandom> (and we'll never, /never/ be ahead of the game as long as we explicitly filter)
            
-
            14:08 < ant> <cat-a-puss> Java/javascript are enclosed in tags. So strip those out, plain html is not harmful right?
            
-
            14:08 < ant> <dm> We need to use a data format that is parsed by a client made by a company that we trust.
            
-
            14:08 < jrandom> Ragnarok: macros, and/or reference known safe and locally installed javascript
            
-
            14:08 < ant> <dm> I trust Microsoft, therefore I suggest Internet Explorer, Microsoft Word, or Notepad
            
-
            14:09 < ant> <dm> Flight Simulator 2002 is acceptable as well.
            
-
            14:09 < ant> <cat-a-puss> Freenet already has an "anonymity filter" strips out all Java / Javascript / ActiveX etc. Borrow that and the only thing I can think could get through would be Image exploits... unless there is something I am missing.
            
-
            14:10 < jrandom> freenet's anon filter is a good start for one or two of the different camps, but would likely require some work to get forms working as we want them
            
-
            14:10 < ant> <Nightblade> the eepproxy would have to run as a separate process, because of licensing
            
-
            14:11 < jrandom> that still leaves us a heavily crippled html
            
-
            14:11 < jrandom> (with no css)
            
-
            14:11 < ant> <dm> Okay, how about Flash?
            
-
            14:11 < jrandom> nightblade: we can work around that (same way we work around i2ptunnel being GPL)
            
-
            14:11 < ant> <dm> Imagine a world wide web with only flash.
            
-
            14:11 < ant> <dm> What a rich and wonderful world that would be.
            
-
            14:12 < ant> <Nightblade> well Just create a warning: "Eepsite browsing is hazardous to your anonymity.  Please use Gopher."
            
-
            14:12 < ant> <Nightblade> actually gopher is not a bad idea
            
-
            14:12  * jrandom ports archie
            
-
            14:12 <+Ragnarok> gopher!
            
-
            14:12 < ant> <dm> There was Betty as well, wasn't there...
            
-
            14:12 <+Ragnarok> I remember gopher :)
            
-
            14:13 <+Ragnarok> man, those were the good old days.  I think I had a screaming 14.4 baud at the time... <sigh>
            
-
            14:13 < ant> <Nightblade> I only browsed gopher in text mode, and I don't know if it supported graphics
            
-
            14:13 < jrandom> they didnt have gui browsers last time i used gopher ;)
            
-
            14:14 < jrandom> anyway, there are lots of options
            
-
            14:14 < ant> <Nightblade> what was that browser called back then?  the one before Netscape...
            
-
            14:14 < ant> <Nightblade> i forget
            
-
            14:14 < jrandom> mosaic
            
-
            14:15 < ant> <Nightblade> yeah
            
-
            14:15 < ant> <dm> Mosaic 2.0
            
-
            14:15 < ant> <Nightblade> "Welcome to I2P, please wait while we install Gopher and Mosaic."
            
-
            14:15 < jrandom> heh
            
-
            14:15 < jrandom> yeah, probably no javascript exploits in those
            
-
            14:16 < jrandom> ok, anyway, thats that, i suppose
            
-
            14:16 < jrandom> moving on to 5) ???
            
-
            14:16 <+Ragnarok> there's still a gopher package in debian
            
-
            14:16 < jrandom> anyone have anything else (not gopher related)?
            
-
            14:17 < ant> <dm> What will happen to I2P when you need to start working again?
            
-
            14:18 < jrandom> i'll be on i2p fulltime through the spring, at least.  we can discuss things beyond then as that time approaches
            
-
            14:19 < ant> <dm> o k
            
-
            14:19 < jrandom> in any case, if i got hit by a bus tomorrow, everything is in cvs and all code is free
            
-
            14:19 <+Ragnarok> I assume you're planning to have a 1.0 before then.  What do you think the odds are?
            
-
            14:19 <+Ragnarok> before spring, not your untimely demise...
            
-
            14:20 < jrandom> certainty.
            
-
            14:20 < ant> <dm> ahaha.. yes, what are the odds of 1.0 before tomorrow when you get hit by that bus?
            
-
            14:20 < jrandom> (assuming no buses ;)
            
-
            14:20 < ant> <dm> I just had a very sad thought.
            
-
            14:20 < ant> <dm> Depressing really, but... If you were to get hit by a bus, no one here would know of it.
            
-
            14:20 < ant> <cat-a-puss> On filtering: What if we created a better proxy, such that all the applications on the computer's traffic could go through it, then we would not need to filter Javascript et alt because they can't find out who we are anyway.
            
-
            14:21 < ant> <dm> You would just die, and we wouldn't know what happened :(
            
-
            14:21 < ant> <dm> God why did he have to die?!?!? why?!?!
            
-
            14:22 < ant> <dm> Can you put a clause in your will to email the mailing list if you die?
            
-
            14:22 < jrandom> cat-a-puss: javascript can send the contennts of your bookmarks, your IP address, and all sorts of things to a remote site
            
-
            14:22 < jrandom> dm: people who know me irl know i'm involved in i2p.  enough of this morbid shit
            
-
            14:23 < ant> <dm> ah cool.
            
-
            14:24 < ant> <cat-a-puss> jrandom: yeah, but that sort of thing requres an exploit right, not just say forwarding them to some page that uses a different protocall that is not proxied. We probably be reasonable safe from those with a scanner on incomming content and automatic updates.
            
-
            14:25 < jrandom> cat-a-puss: erm, perhaps i misunderstood - are you suggesting that it may be safe to have javascript enabled in the browser, as long as the connections that that javascript code makes are proxied also?
            
-
            14:26 < ant> <cat-a-puss> jrandom: yeah, as long as there is no buffer overflows etc.
            
-
            14:26 < jrandom> if so, thats still vulnerable to plain old javascript that reads the javascrip environment and sends it "anonymously" to http://cia.i2p/data.  
            
-
            14:27 < jrandom> the data available to javascript includes your IP address, as well as your bookmarks and all sorts of other things
            
-
            14:27 < jrandom> so even though the connection to cia.i2p was anonymous, the content exposes you
            
-
            14:31 < jrandom> ok, anyone else have something to bring up for the meeting?
            
-
            14:31 <@duck> yes:
            
-
            14:31 <@duck> what does the new 'active peers' counter mean
            
-
            14:31 < jrandom> ah
            
-
            14:31 < jrandom> yeah, that changed
            
-
            14:32 < jrandom> in 0.4.2.1, the new Active: x/y will have x=# of peers you've sent or received a message from successfully in the last minute, y=# peers seen in the last hour or so
            
-
            14:32 < jrandom> this is part of the code to deal with some peers giving out bad info in the IP autodetection phase
            
-
            14:33  * duck will try to remember it
            
-
            14:33 < jrandom> so it'll vary much more than before
            
-
            14:33 < jrandom> heh so dont worry when the value is lower than you're used to ;)
            
-
            14:34 < jrandom> ok, if thats it, then y'all should check back onto the mailing list and website over the next day for the 0.4.2.1 release
            
-
            14:34 < jrandom> it'll be backwards compatible, blah blah blah
            
-
            14:34 < jrandom> in any case
            
-
            14:34  * jrandom winds up
            
-
            14:35  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting119.html b/www.i2p2/pages/meeting119.html
deleted file mode 100644
index 745f3c7b..00000000
--- a/www.i2p2/pages/meeting119.html
+++ /dev/null
@@ -1,174 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 119{% endblock %}
-{% block content %}
            I2P dev meeting, December 7, 2004
            
-
            
-
            22:00:00 <@duck> Tue Dec  7 21:00:00 UTC 2004
            
-
            22:00:04 <@duck> I2P meeting time
            
-
            22:00:05 < Frooze> i just made Frooze up for i2p.  i don't even know what a 'frooze' is.
            
-
            22:00:21 <@duck> as announced on http://dev.i2p.net/pipermail/i2p/2004-December/000509.html
            
-
            22:00:29 <@duck> Agenda:
            
-
            22:00:29 <@duck> 0) hi
            
-
            22:00:29 <@duck> 1) 0.4.2.3
            
-
            22:00:29 <@duck> 2) i2p-bt
            
-
            22:00:29 <@duck> 3) #idlerpg
            
-
            22:00:29 <@duck> 4) ???
            
-
            22:00:32 <@duck> .
            
-
            22:01:09 <@duck> 0) hi
            
-
            22:01:15 < clayboy> hi
            
-
            22:01:16 <@duck> jrandom called in sick
            
-
            22:01:20 <+ugha2p> Hi.
            
-
            22:01:30 <@duck> plus msged me that he'd probably not make it
            
-
            22:01:39 <+protokol> http://www.google.com/search?q=frooze
            
-
            22:01:41 <@duck> so we'll see and just start
            
-
            22:01:46 < clayboy> hope he gets better quick
            
-
            22:02:06 <@duck> 1) 0.4.2.3
            
-
            22:02:16 <@duck> new release will be out Real Soon
            
-
            22:02:31 <@duck> so tomorrow or thursday.
            
-
            22:02:41 <@duck> there has been quite a few bugfixes
            
-
            22:03:24 <+ugha2p> Do newer CVS revisions also fix the memory/CPU issues?
            
-
            22:03:29 < clayboy> a few of us have been following the cvs builds, it's working very nicely
            
-
            22:03:33 <@duck> most streaming lib, sam bridge, etc
            
-
            22:04:17 <+ugha2p> I've been experiencing some uncommon loads from I2P.
            
-
            22:04:23 < clayboy> i think those were fixed many revisions ago, ugha2p
            
-
            22:04:41 <+ugha2p> (Running -7)
            
-
            22:04:51 < clayboy> oh, hm
            
-
            22:04:52 <@duck> ugha2p: dont see anything about that in the history
            
-
            22:05:48 <+protokol> you know what would be nice (if not feasable/worth it) is an RSS feed of the changelog
            
-
            22:05:48 <@duck> ok
            
-
            22:05:49 <+ugha2p> That's strange.
            
-
            22:06:01 <+protokol> ;-)
            
-
            22:06:17 <@duck> maybe file a bugzilla item
            
-
            22:06:25 <@duck> or dunno
            
-
            22:06:34 <+ugha2p> The Java process consumes 100% of CPU for about half of the time.
            
-
            22:07:18 <+ugha2p> So, you don't know anything about the issue? Do your routers behave OK?
            
-
            22:07:24 < dinoman> yea it is high for me to -6
            
-
            22:08:24 <@duck> top/uptime info is behaving weird for me since my nptl upgrade, so cant say
            
-
            22:09:03 <+ugha2p> Ok, maybe we should move on?
            
-
            22:09:07 <@duck> ok
            
-
            22:09:14 <@duck> 2) i2p-bt
            
-
            22:09:24 <+ugha2p> And ask jrandom when he is about to release 0.4.2.3
            
-
            22:09:40 <+ugha2p> It has worked fine for me with NPTL.
            
-
            22:09:45 <@duck> ugha2p: he said tomorrow or thursday
            
-
            22:09:58 <+ugha2p> Right.
            
-
            22:09:59 <@duck> yesterday I released a new i2p-bt
            
-
            22:10:23 <@duck> I gained some new understanding of the whole 'buffer' concept
            
-
            22:10:42 <@duck> plus there were some previous pending patches from Ragnarok
            
-
            22:11:13 < mule> duck: congratulations, good work!
            
-
            22:11:15 <@duck> also the slice size is increased, which means that instead of sending 32KB each time, it sends 128KB
            
-
            22:11:29 <@duck> which should keep the queue filled
            
-
            22:11:47 <+ugha2p> Yeah, thanks, duck. :)
            
-
            22:11:56 <@duck> DrWoo and others filed some GUI feature requests
            
-
            22:12:23 <@duck> but I never use the GUI myself, wouldnt know wxpython and probably dont care too much :)
            
-
            22:12:31 <+Ragnarok> fitting each slice into a single message didn't work as well as expected?
            
-
            22:12:57 < clayboy> many seeded torrents on http://brittanyworld.i2p/bittorrent/ if anyone want to try (with i2p 0.4.2.2-7 and i2p-bt 0.1.3)
            
-
            22:13:10 <@duck> Ragnarok: it is a bit of a guess
            
-
            22:13:27 <@duck> it gives much higher throughput values on local transfers
            
-
            22:13:51 <+ugha2p> Maybe we should wait for someone to port a full-featured client instead?
            
-
            22:14:10 <+Ragnarok> hm, ok
            
-
            22:14:13 <@duck> we can all wait :)
            
-
            22:14:37 < clayboy> BitTorrent _is_ "full featured", it's the only client i use for bt (also off i2p) :)
            
-
            22:15:15 <+ugha2p> clayboy: Not really. :)
            
-
            22:16:02 <@duck> personally I prefer things with sound defaults
            
-
            22:16:17 <@duck> take mldonkey, you can change 1 million things and most users have no idea what they do
            
-
            22:16:50 <@duck> this leads to user-myths, like i2p users hitting 'Reseed' all the time, or reinstalling if it doesnt work
            
-
            22:17:01 <+ugha2p> If you aren't willing to find out, then you shouldn't be using Linux anyway. :)
            
-
            22:17:04 <@duck> which kills kittens
            
-
            22:17:28 < slart> what about bittornado?
            
-
            22:17:43 <+Ragnarok> I suppose I could be tempted to write a pygtk gui, but I've got a lot of other stuff to do, and I'm not sure what people want
            
-
            22:17:45 <+protokol> azureus?
            
-
            22:17:57 <@duck> part of me is ofcourse making up excuses not to do things
            
-
            22:18:03 <+protokol> azureus supports plugins
            
-
            22:18:10 <@duck> protokol: well, write a plugin
            
-
            22:18:32 <+protokol> heh
            
-
            22:18:40 < slart> bittornado is based off the offical bt isnt it?
            
-
            22:18:50 <+protokol> easier said than done
            
-
            22:18:52 <@duck> slart: I have looked at it and wept
            
-
            22:19:07 <@duck> it has some improvements, which might be useful
            
-
            22:19:17 <@duck> but on the other hand it made the whole thing way more complex
            
-
            22:19:22 <@duck> without cleaning up the original code
            
-
            22:19:36 <+Ragnarok> gah
            
-
            22:19:56 <@duck> the GUI feature that you can specify a torrent if no arguments are given is taken from it and added to i2p-bt
            
-
            22:20:11 < clayboy> let's get the basic bittorrent working excellently before worrying about these fluffy gui things :)
            
-
            22:20:46 <@duck> slart: probably some other things can be used too; someone just has to do it (properly)
            
-
            22:21:23 <+ugha2p> clayboy: Well, I think it already does work excellently. :)
            
-
            22:21:53 < slart> the abc client uses tornado (i think)
            
-
            22:22:15 < clayboy> i feel like we have still to do some really heavy-duty testing to see how much data can really be pushed through i2p-bt
            
-
            22:22:21 < bushka> yes it does slart.
            
-
            22:23:49 <@duck> depending on how those work, you might be able to port the i2p-bt changes to them quite easily
            
-
            22:24:41 <@duck> please give it a try and report back
            
-
            22:25:47 <@duck> .
            
-
            22:25:55 <@duck> any other i2p-bt / bittorrent comments?
            
-
            22:26:08 < slart> python :S
            
-
            22:26:41 <+ugha2p> .
            
-
            22:26:51 <@duck> slart: if you dont like python, you can give porting azureus a try
            
-
            22:27:00 <+ugha2p> slart: What about it?
            
-
            22:27:06 < slart> how many people could we get seeding somthing like a linux is for speed testing?
            
-
            22:27:15 < slart> *iso
            
-
            22:27:34 <@duck> lets try that after the new i2p release
            
-
            22:27:57 <@duck> (since pulling an i2p router build from cvs is quite a challenge for most)
            
-
            22:28:17 <+protokol> eh
            
-
            22:28:54 <@duck> pl
            
-
            22:28:57 <@duck> err, ok
            
-
            22:29:10 <@duck> 3) #idlerpg
            
-
            22:29:22 <@duck> found this funny irc rpg game
            
-
            22:29:36 <@duck> you dont have to do anything for it, just idle 
            
-
            22:29:56 <+ugha2p> Well, you do have to LOGIN. ;)
            
-
            22:30:04 <@duck> ah ;)
            
-
            22:30:18 < mule> cvs update -dP :)
            
-
            22:30:18 < mule> ant dist updater :)
            
-
            22:30:20 <+postman> it's the most hilarious thing i've ever seen, but i LIKE it :)
            
-
            22:30:30 <+protokol> there should be prizes
            
-
            22:30:45 <@duck> on ircnet it has 779 online players 
            
-
            22:30:46 <+ugha2p> duck: I was thinking, that it could potentially be a reason not to upgrade.
            
-
            22:30:52 <+protokol> give yodels for winning stuff or reaching levels
            
-
            22:31:03 <+ugha2p> Although I'm not sure if people on I2P could be that childish. :)
            
-
            22:31:14 <+protokol> i know duck has like $10000 in yodels
            
-
            22:31:18 <@duck> protokol: yeah, I have to see how those quests work
            
-
            22:31:39 <@duck> maybe we can do some fun stuff with it
            
-
            22:31:42 <@duck> ugha2p: what do you mean?
            
-
            22:31:49 < ant> * cervantes is not going to do another 40 days without restarting his router
            
-
            22:32:08 <@duck> ugha2p: oh, not update because of the game :)
            
-
            22:32:18 <+protokol> Linux: If you can't fix it without restarting, you can't fix it.
            
-
            22:32:20 <@duck> well, I'll put it on pause while my router restarts
            
-
            22:32:24 <+ugha2p> :)
            
-
            22:32:33 <@duck> so if you sync it well, you wont lose
            
-
            22:32:35 <@duck> hehe
            
-
            22:32:55 < ant> <cervantes> thats good... since your router restarts all the time :P
            
-
            22:33:16 <@duck> thats called dedicated testing :)
            
-
            22:33:20 < ant> <cervantes> I guess that throws roulette into the equation too
            
-
            22:33:23 <@duck> ok
            
-
            22:33:38 <@duck> .
            
-
            22:33:49 <+ugha2p> .
            
-
            22:34:05 <@duck> 5) ???
            
-
            22:34:08 <@duck> s/5/4/
            
-
            22:34:12 <@duck> open mike!
            
-
            22:34:23 <+postman> .
            
-
            22:34:53 < mule> with a bit of tweaking you can two routers. one for the game only, which you upgrade only every year
            
-
            22:34:53 <@duck> questions? comments? suggestions?
            
-
            22:35:38 < ant> <mahes> Hi, i have a general non-dev question
            
-
            22:36:08 <@duck> shoot
            
-
            22:36:08 <+ugha2p> Thanks for holding the meeting, duck.
            
-
            22:36:50 < ant> <mahes> if i set up an eepsite , how can be reached with an address like i.e mahes.i2p
            
-
            22:36:59 <+protokol> i have a consern
            
-
            22:37:44 <+protokol> (start the battle) i think .i2p is a shitty TLD for many reasons
            
-
            22:38:19 <+ugha2p> mahes: What do you mean 'how'? People will configure their browsers to use the eepproxy, and just enter http://mahes.i2p/ onto their address bar.
            
-
            22:38:19 <+protokol> i think we should use one that is a) one syllable b) can be pronounced like a word c) does not include a number'
            
-
            22:38:46 <+ugha2p> protokol: Like .eep?
            
-
            22:39:07 <@duck> mahes:: to get a 'nice name' to point to your eepsite, it has to be present in your hosts.txt file
            
-
            22:39:37 <+protokol> ugha2p: sure
            
-
            22:40:01 <+ugha2p> protokol: You can make a proposal on the mailing list.
            
-
            22:40:03 <@duck> you can post it on the eepsite announcement forum so others can get it too
            
-
            22:40:09 <+ugha2p> It'll probably be considered once we have MyI2P.
            
-
            22:40:35 <+protokol> heh, ill try but jr shot it down for some reason already
            
-
            22:41:06 < ant> <mahes> well. i am just a user...  ok, so i just publish mahes.i2p=hhfbwer8328... and it will just spread
            
-
            22:41:32 <@duck> it doesnt spread automatically, ppl need to get it into their hosts.txt somehow
            
-
            22:41:39 < ant> <mahes> ok
            
-
            22:41:52 <@duck> but announce it on the forum and it is more likely to :)
            
-
            22:42:34 <@duck> .
            
-
            22:43:18 <@duck> lets give it a *baf*
            
-
            22:43:20 <+ugha2p> .
            
-
            22:43:30  * ugha2p is waiting for the baffer.
            
-
            22:43:38  * duck winds up
            
-
            22:43:45  * duck *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting12.html b/www.i2p2/pages/meeting12.html
deleted file mode 100644
index 468f604c..00000000
--- a/www.i2p2/pages/meeting12.html
+++ /dev/null
@@ -1,619 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 12{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 12
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Wed Sep 25 00:57:27 2002
-
            00:57 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ 
-
            00:57 [Users #iip-dev]
-
            00:57 [@mids] [ Dag] [ logger] [ nemesis] [ nop] [ Zwolly] 
-
            00:57 -!- Irssi: #iip-dev: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal]
-
            00:57 -!- Irssi: Join to #iip-dev was synced in 1 secs
-
            00:58 -!- mode/#iip-dev [+v logger] by mids
-
            01:00 <@mids> Tue Sep 24 23:00:38 UTC 2002
-
            01:00 <@mids> welcome et all
-
            01:00 <@mids> the 12th meeting just started 
-
            01:01 <@mids> agenda:
-
            01:01 <@mids> 1) website
-
            01:01 <@mids> 2) nop's messages
-
            01:01 <@mids> 3) question round
-
            01:01 <@mids> website:
-
            01:01 <@mids> new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/
-
            01:02 <@mids> for those who just joined:
-
            01:02 <@mids> new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/
-
            01:02 <@mids> geeh
-
            01:02 <@mids> I keep busy
-
            01:02 < nop> ok
-
            01:02 < nop> pause a sec
-
            01:02 <@mids> for those who just joined:
-
            01:02 <@mids> hehe
-
            01:02 < nop> just add it to topic
-
            01:03 < nop> ok
-
            01:03 < nop> go
-
            01:03 < nop> ;(
-
            01:03 -!- mids changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/
-
            01:03 < nop> ;)
-
            01:03 <@mids> .
-
            01:04 -!- mode/#iip-dev [+o nop] by mids
-
            01:05 <@mids> any questions about this topic? otherwise we'll go to #2
-
            01:06 <@nop> ok
-
            01:06 <@nop> thanks to ellison
-
            01:07 <@nop> and the distributedcity crew
-
            01:07 <@nop> for helping out
-
            01:07 <@nop> with the website
-
            01:07 <@nop> we owe them a lot now ;)
-
            01:07 <@nop> ok
-
            01:07 <@nop> rc2 is coming out tomorrow
-
            01:07 <@nop> we're just packaging it up
-
            01:07 <@nop> and getting it ready for release
-
            01:07 <@nop> new features
-
            01:07 <@nop> are Forward Security
-
            01:08 <@nop> Close Delay protocol for killed connections
-
            01:08 <@nop> some bug fixes
-
            01:08 <@nop> and upgrade features for future versions
-
            01:08 <@nop> I think that's about it
-
            01:08 <@nop> thank you all you users
-
            01:08 <@nop> that use IIP
-
            01:08 <@nop> without you
-
            01:08 <@nop> the project would be a waste
-
            01:08 <@nop> ;)
-
            01:09 <@nop> so thank all of you for your loyalty and support by using the software
-
            01:09 <@nop> I think that's it for my daily comments ;)
-
            01:09 <@nop> oh
-
            01:09 <@nop> wait
-
            01:09 <@nop> thank you mids
-
            01:09 <@nop> for assisting me with the website setup
-
            01:09 <@nop> and for being patient with me
-
            01:09 <@nop> thank you codeshark
-
            01:09 <@nop> for setting up the software
-
            01:09 <@mids> your welcome :)
-
            01:09 <@nop> and handling inform
-
            01:09 <@nop> thank you userx wherever you ar
-
            01:10 <@nop> are
-
            01:10 <@nop> for your hard work on core development
-
            01:10 <@nop> and putting up with my ranting ;)
-
            01:10 <@nop> thanks to chocolate
-
            01:10 <@nop> for the informity and scripts that are needed
-
            01:10 <@nop> thanks to cohesion even though long gone, for documentation in the past
-
            01:10 <@nop> umm, like to thank the academy ... j/k
-
            01:11 <@nop> everyone who has contributed thank you all
-
            01:11 <@nop> .
-
            01:11 <@mids> 3 hurrays for nop
-
            01:11 <@mids> hurray
-
            01:11 < Zwolly> hurray
-
            01:11 < thecrypto> huzzah
-
            01:11 <@nop> haha
-
            01:11 < athena> that's 2 hurrays and 1 huzzah
-
            01:11 <@nop> oh and DC people have been whispering in my ear to thank the Lord
-
            01:11 <@nop> ;)
-
            01:12 < Neo> lol
-
            01:12 <@nop> well, on a side note, thank life for it is a neat thing ;) <-- no comments
-
            01:12 <@nop> .
-
            01:13 <@nop> any questions
-
            01:13 <@nop> suggestions
-
            01:13 <@nop> review
-
            01:13 <@nop> ideas
-
            01:13 <@nop> etc
-
            01:13 < Neo> congratulations on the new site, looks great.
-
            01:13 <@nop> ?
-
            01:13 <@nop> thnx
-
            01:13 <@mids> what is forward security?
-
            01:13 <@nop> encryption can only be decrypted at time of session
-
            01:13 <@nop> aka, you can't replay the messages
-
            01:13 <@nop> and decrypt them
-
            01:14 <@nop> as that key and signature doesn't exist anymore
-
            01:14 <@nop> and will not be useful
-
            01:14 <@nop> this is designed against log and replay attacks
-
            01:14 <@nop> .
-
            01:14 <@mids> thx
-
            01:14 < athena> will you require public proxies to support these new protocol additions? (methinks all proxies should be forced to upgrade)
-
            01:14 <@nop> athena
-
            01:14 <@nop> it's a mandatory upgrade
-
            01:14 <@nop> all relay holders
-
            01:14 <@nop> will need to upgrade
-
            01:15 <@nop> to rc2 relay
-
            01:15 <@nop> and re-announce
-
            01:15 < athena> ok, thanks
-
            01:16 < sferic> I guess I cam ein late and missed something, but do you mean that we can't log anymore?
-
            01:16 <@nop> no
-
            01:16 <@nop> you can log
-
            01:16 <@nop> what I'm saying
-
            01:16 <@nop> is
-
            01:16 <@nop> if you were a gov't agent
-
            01:16 <@nop> spying on a relay
-
            01:16 <@nop> and you were logging the encrypted traffic
-
            01:16 <@nop> you couldn't then come and seize the ircd end node
-
            01:16 <@nop> and use the network secret key
-
            01:16 <@nop> to replay the traffic
-
            01:16 <@nop> and decrypt it
-
            01:17 < sferic> Ahh, thanks
-
            01:17 <@nop> it eliminates the importance of the network secret key
-
            01:17 <@nop> it's useless
-
            01:17 <@nop> all it does is authenticate
-
            01:17 <@nop> nothing more
-
            01:17 <@nop> doesn't actually encrypt
-
            01:17 <@nop> this covers two things
-
            01:17 <@nop> man in the middle attack protection
-
            01:17 <@nop> and log and relay protection
-
            01:17 <@nop> aka forward security
-
            01:17 <@nop> ;)
-
            01:17 < Zwolly> is it now without central server.
-
            01:18 <@nop> not yet
-
            01:18 <@nop> that's 1.22
-
            01:18 <@nop> 1.2
-
            01:18 <@nop> correction
-
            01:18 <@nop> 1.2.0 to be exact
-
            01:18 <@nop> ;)
-
            01:18 <@nop> after 1.1 basically is finished
-
            01:18 <@mids> (I'd say that decentralization is 2.0)
-
            01:19 < Zwolly> how about system resources memory cpu and bandwith
-
            01:19 <@nop> well, 2.0 is a more perfect form of decentralization
-
            01:19 <@nop> 1.2 we will attempt decentralization
-
            01:20 < Tanthrix> how does true p2p work, you can't exactly scan IP blocks until you find someone? isn't some sort of a central server neccessary for initial connection?
-
            01:20 <@nop> bootstrap is needed
-
            01:20 <@nop> but once connected
-
            01:20 <@nop> you have your own peer routes
-
            01:20 <@nop> so we include a small node.ref
-
            01:20 <@nop> which connects you in
-
            01:20 <@nop> then from that point
-
            01:20 < athena> thanthrix: find some friends you trust and trade node.refs :)
-
            01:20 <@nop> you are dynamically updated from the network
-
            01:21 <@nop> yes
-
            01:21 <@nop> that's the idea
-
            01:21 <@nop> in a nice world
-
            01:21 <@nop> ;)
-
            01:21 < Tanthrix> hehehe
-
            01:21 <@mids> what if you dont have friends?
-
            01:21 <@nop> then try to trust the signature on our software ;)
-
            01:21 <@nop> haha
-
            01:21 <@nop> yeah right, digital trust is rarely possible
-
            01:22 < Dag> trust no one
-
            01:22 < Dag> heh
-
            01:22 < athena> awww...i'll be your friends, mids!
-
            01:22 <@mids> hurray
-
            01:22 < athena> huzzah
-
            01:22 < Tanthrix> and grey-eyed athena comes to the rescue..
-
            01:22 <@nop> hehe
-
            01:22 <@nop> this website kicks ass
-
            01:22 <@nop> far difference then the previous one
-
            01:23 <@mids> kinda :)
-
            01:23 <@nop> umm
-
            01:23 <@nop> yeah
-
            01:23 <@nop> that nice little under construction site sucked ass
-
            01:24 < Tanthrix> heh..the new invisiblenet site looks like a page for some web-based corporation
-
            01:25 <@mids> thanks... I guess :)
-
            01:25  * mids points at ellison ... he is the one to blame; he gets all fame
-
            01:25 < Tanthrix> hehehe
-
            01:25  * ellison hides under some eye candy in the corner
-
            01:26 < Zwolly> what is the gues about how stable it will be 
-
            01:26 <@mids> Zwolly: Trent is running on a rc2 relay for 2 days now
-
            01:26 <@mids> without trouble
-
            01:27 < Zwolly> ok.
-
            01:27 <@mids> trent is the irc client/service with the heaviest traffic
-
            01:27 <@mids> so... I think it is okay
-
            01:27 < Zwolly> we will see
-
            01:27 <@nop> the reason
-
            01:27 < Zwolly> is it tomorrow already? hehe
-
            01:28 <@nop> for the middle of the road
-
            01:28 <@nop> corporate looking site
-
            01:28 <@nop> is called steganography
-
            01:28 <@nop> ;)
-
            01:28 <@nop> our evil black hat activities
-
            01:28 <@nop> wouldn't be good
-
            01:28 <@nop> if it's obvious
-
            01:28 <@nop> we're evil
-
            01:28 <@nop> now would it
-
            01:29 <@nop> so we blend in with the other evil
-
            01:29 <@nop> and they won't notice us
-
            01:29 <@nop> ;)
-
            01:29 <@nop> honestly though
-
            01:29 <@nop> it's just for attracting all audiences
-
            01:29 <@mids> in 2 month there will be an invisibleNET sponsored golf tournament
-
            01:29 <@nop> hahaha
-
            01:30 <@nop> oh and the palladium efforts
-
            01:30 <@nop> we bought it out
-
            01:30 <@nop> ;)
-
            01:31 <@nop> if you've noticed
-
            01:31 <@nop> we own www.invisiblenet.net, www.invisiblenet.com, and www.invisiblenet.org
-
            01:31 <@nop> we're evil
-
            01:31 <@nop> ;)
-
            01:31 <@nop> we've monopolized the market
-
            01:31 <@nop> we're bastards
-
            01:31 < Dag> what about getting one of those signs on the highway for cleaning up the roadside?
-
            01:31 <@nop> yeah
-
            01:31 <@nop> that's in the works
-
            01:31 <@nop> as well as OEM'ing with Microsucks, and Intel
-
            01:32 <@nop> haha
-
            01:32 <@mids> euh
-
            01:32 <@mids> you okay nop? :)
-
            01:32 < Zwolly> ok other question what to do if there are warez channels and some big stupid country lets say america for example want this network doun can it run on its own from the european nodes
-
            01:32 <@nop> yeah
-
            01:32 <@nop> yes
-
            01:32 <@nop> it will be possible to do that
-
            01:33 <@nop> plus
-
            01:33 <@nop> I advise for all warez activity
-
            01:33 < Dag> I thought there was no /dcc 
-
            01:33 < Dag> in here
-
            01:33 <@nop> to use a !anonymous mode channel
-
            01:33 <@nop> doesn't mean you can't trade ftp sites
-
            01:33 < Dag> well
-
            01:33 <@nop> then for anyone monitoring
-
            01:33 <@nop> who is saying what
-
            01:33 < Dag> google trades warez ftp sites
-
            01:33 <@nop> is a bit more tricky
-
            01:33 <@nop> ;)
-
            01:33 <@nop> exactly
-
            01:33 < Dag> so does the newsgroups
-
            01:33 <@nop> I doubt that we're a threat to that
-
            01:33 < Dag> er do
-
            01:33 <@nop> our main concern is #pedophilia public channels
-
            01:34 < Dag> I did a /list one day
-
            01:34 <@nop> as they would be a concerned threat to the existance of IIP as a whole
-
            01:34 < Dag> and saw that channel in the list
-
            01:34 <@mids> nah
-
            01:34 < Dag> was a month or so ago
-
            01:34 <@mids> I wouldnt be too affraid about that
-
            01:34 <@nop> I like as little trouble as possible while were developing
-
            01:34 <@mids> this is pure text based
-
            01:34 <@nop> true
-
            01:34 < nemesis> k
-
            01:34 < nemesis> brb
-
            01:35  * nemesis  decides to go out and tar the way to the loung ()ŻŻŻŻ)ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ)))~~~~
-
            01:35 < Dag> freenet has been overwhelmed with that crap
-
            01:35 < Dag> at least last time I used frost
-
            01:35 < Dag> it was a VERY high percentage of that crap on there
-
            01:35 < athena> comes with the territory
-
            01:35 < Dag> I think it would be good for people to spam freenet with random non porn images and media files
-
            01:36 <@nop> yeah
-
            01:36 <@nop> it's unfortunate
-
            01:36 < Dag> just to make the percentage of crap go down
-
            01:36 <@mids> I am using freenet for 3 or 4 years now and I have never seen any pedo crap...
-
            01:36 <@nop> I accidentally downloaded trash on my hardrive because of their shit
-
            01:36 <@nop> sickening
-
            01:36 <@nop> I found one
-
            01:36 <@mids> if you dont look for it, I dont think you will run into much
-
            01:36 <@nop> by accident
-
            01:36 <@nop> not true
-
            01:36 <@nop> stuff gets renamed stuf
-
            01:37 < Dag> mids I just had frost list all the files available
-
            01:37 < Dag> as there are not many
-
            01:37 < Dag> maybe a few hundred files max
-
            01:37 < Dag> its not like gnutella
-
            01:37 <@mids> well, if you view each of them.. you will probably run into stuff
-
            01:37 < Dag> I didnt download anything
-
            01:37 <@mids> but I have no reason to view a msc0001a.jpg
-
            01:38 < Dag> I just saw the listings
-
            01:38 < ellison> you guys seen www.bitzi.com?
-
            01:38 < Dag> no
-
            01:38 < Dag> isnt that some spyware
-
            01:38 < ellison> it is a database of tons of files on p2p networks
-
            01:38 < athena> no
-
            01:38 <@nop> mids
-
            01:38 < athena> the fingerprint mp3s
-
            01:38 <@nop> check iip-dev
-
            01:38 < ellison> you can enter a filename and size, and it'll tell you what it is
-
            01:38 <@nop> this can't be true
-
            01:38 <@nop> we have a few debian users
-
            01:38 <@mids> nop: iip-dev email?
-
            01:38 <@nop> yes
-
            01:38 < Dag> ellison who is funding it?
-
            01:39 < ellison> dag: dunno
-
            01:40 < Dag> ellison I would bet its the riaa
-
            01:40 < ellison> "Bitzi is a privately-held metadata publishing company based in San Francisco."
-
            01:40 < Dag> or some such org
-
            01:40 < Dag> ellision who pays the bills
-
            01:40 < Dag> follow the $$$$$
-
            01:40 < ellison> doubt it, I think you can use their service to differentiate between valid media files and the fake stuff uploaded by RIAA
-
            01:41 < ellison> the founder posted on a RIAA thread and mentioned this use of the system
-
            01:41 < Dag> find out who funds it
-
            01:41 < ellison> i brought up their site because it seems to be a good way of avoiding nasty re-named stuff
-
            01:41 < athena> bitzi is cool... their stuff is opensource
-
            01:41 < Dag> one thing is certain in this day and age
-
            01:41 < ellison> there's no reason you couldn't submit freenet files to the service
-
            01:42 < ellison> dag: there would be concern if there was any evidence that they are funded by the RIAA, but it doesn't look like it to me
-
            01:42 < Dag> ellison a md5->file content database
-
            01:42 < Dag> would maybe work
-
            01:42 < Dag> but can be abused as well
-
            01:42 < Dag> its all about who controlls the data
-
            01:43  * athena controls the data
-
            01:43 < Dag> mallicous people can change the file slightly anyhow
-
            01:43 < ellison> if course there is an issue of trust, but if you don't trust anyone then it'll be difficult to take part in a service-based economy...
-
            01:43 < ellison> then the signature would change
-
            01:44 < Dag> yes
-
            01:44 < Dag> I am addressing your wanting to avoid known bad files
-
            01:44 < ellison> if lots of people use bitzi, then all it takes is one person downloading and reporting a bad file
-
            01:45 < Dag> I could write a gnutella server to on the fly randomly tag on some byte
-
            01:45 < Dag> to a file
-
            01:45 < ellison> and bitzi will be a more and more valuable service as the RIAA begins seeding P2P networks w/ crap...
-
            01:45 < Dag> and change the file sig each time
-
            01:45 < athena> bitzi is being integrated into limewire
-
            01:45 < ellison> people could go to bitzi and find out which files are the good ones, and only download those
-
            01:45 < Dag> I think that the riaa would find the service more usefull than not
-
            01:46 < Dag> they are doing the riaas job for them
-
            01:46 < ellison> it's also about finding the good ones - avoiding the bad ones is just 1/2 of the process
-
            01:46 < Dag> finding keys to stuff they own
-
            01:46 <@mids> hey aum 
-
            01:46 < aum> hi mids
-
            01:47 <@nop> aum
-
            01:47 <@nop> it's most likely
-
            01:47 <@nop> the dh key exchange
-
            01:47 <@nop> maybe handshaking with a bad or out of date node, or so
-
            01:47 < aum> the max-out doesn't happen when i run iip as root
-
            01:47 < aum> only when i run as user
-
            01:47 <@nop> interesting
-
            01:47 < athena> huh?
-
            01:47 <@nop> have you checked your file descriptors for users
-
            01:47 <@nop> how many are allowed and such?
-
            01:48 < aum> well, all the files are owned by the same user as is running the daemno
-
            01:48 < aum> it's a severe max-out when i run as user - a 1.5GHz box grinds to a halt - even the mouse can barely move
-
            01:49 < Zwolly> people i need to go now it was fun and will install the new IIP as soon as possible (working at 7.00)
-
            01:49 < aum> compliments on the new website nop
-
            01:49 <@nop> thnx, thank ellison
-
            01:50 <@nop> he did it
-
            01:50 <@nop> ;)
-
            01:50 < aum> it looks so professional that one could expect to go to the download page, and see a link saying 'download 30-day demo'
-
            01:50 < aum> free software websites are rarely designed so professionally
-
            01:50 <@mids> :)
-
            01:50 <@nop> nor are they documented so well either
-
            01:51 <@mids> nor do they have such cool irc channels
-
            01:51 <@nop> we have kind of put the profesionallism back into open source ;)
-
            01:51 <@nop> I spelled that badly
-
            01:51 <@nop> haha
-
            01:51 < aum> the word 'free' needs to appear on the front page IMO
-
            01:51 <@nop> Professionalism
-
            01:51 <@nop> it says open 
-
            01:51 <@nop> and available
-
            01:51 <@nop> etc
-
            01:51 < aum> the word 'open' is being used more and more with commercial software
-
            01:51 <@nop> well, if people don't read
-
            01:51 <@nop> they can't be educated
-
            01:52 <@nop> and they shouldn't be running IIP anyway
-
            01:52 < ellison> :-)
-
            01:53 < aum> i saw a freaky film the other night - 'fight club'
-
            01:53 <@nop> finally?
-
            01:53 <@nop> haha
-
            01:53 <@nop> read the book
-
            01:53 <@nop> it's worse
-
            01:53 < aum> wow!
-
            01:53 <@mids> night all
-
            01:53 < aum> good concept - taking down the credit card databases
-
            01:53 < aum> night mids
-
            01:53 < ellison> night mids
-
            01:54 <@nop> night mids
-
            01:54 <@nop> thnx again
-
            01:54 <@nop> for your help
-
            01:54 < nemesis> gn8 mids
-
            01:54  * aum wonders if iip can take advantage of palladium features
-
            01:55  * nop wonders what aum means by that
-
            01:55 < aum> palladium could be a huge boon for p2p
-
            01:55 <@nop> yes
-
            01:55 <@nop> did you get my ip stego app?
-
            01:55 < aum> palladium creates a private task space that not even root can access
-
            01:55 < aum> back in 5...
-
            01:55 <@nop> k
-
            02:02 <@nop> ok
-
            02:02 < aum> back
-
            02:02 <@nop> wb 
-
            02:03 < aum> palladium can help piracy
-
            02:03 < Dag> anyone here run vmware?
-
            02:03 <@nop> I'm not convinced that palladium will be secure against the security researchers of the world
-
            02:03 < aum> yes
-
            02:03 <@nop> I do
-
            02:03 <@nop> I run it 
-
            02:03 < aum> ditto
-
            02:03 < Dag> how good a sandbox is it?
-
            02:03 <@nop> great
-
            02:03 < aum> brilliant
-
            02:03 <@nop> I use it for my windows stuff
-
            02:03 < Dag> that is my only real interest for it
-
            02:03 <@nop> while running linux as the main one
-
            02:03 <@nop> oh yeah
-
            02:03 < Dag> is a sandbox potentia;
-
            02:04 <@nop> yes
-
            02:04 <@nop> it's great
-
            02:04 <@nop> easy to set up too
-
            02:04 < aum> beautiful thing about vmware is that you can choose to discard all disk changes
-
            02:04 < Dag> well
-
            02:04 < Dag> i imagine it leaks data to the swap
-
            02:04 < aum> so if you install some windows fuckware, it's easy to get rid of it without having to hunt through c:\windows and registry etc
-
            02:04 < Dag> well yes
-
            02:05 < Dag> just delete the install
-
            02:05 < Dag> I keep a good install file
-
            02:05 < Dag> that has nothing on it
-
            02:05 < aum> i like how vers 3 does usb
-
            02:06 < Dag> its an amazing little app
-
            02:06 < Dag> wish it was open sourced
-
            02:06 < Dag> I looked at some open source attemps
-
            02:06 < Dag> at the same thing
-
            02:07 < Dag> and seemed to be stagnating
-
            02:07 < Dag> bochs and the like
-
            02:07 < aum> bochs is a nightmare
-
            02:07 < nemesis> AS/400 are better than vmware ;p
-
            02:08 < Dag> plex86 was another one I think
-
            02:08 < Dag> I have run vmware and ran some tools like filemon and regmon
-
            02:08 < Dag> etc
-
            02:09 < Dag> and they seem to show that its a decent sandbox
-
            02:09 < Dag> its not writting or reading to anything unusual
-
            02:09 < Dag> from waht I saw
-
            02:09 < Dag> winternals software rules
-
            02:09 < Dag> sysinternals/winternals that is
-
            02:10 < Dag> tcpview pro is another of their tools I like
-
            02:10 < Dag> erd commander is another
-
            02:11 < Dag> I am hoping someday soon that linux/bsd can have better ntfs support
-
            02:12 < Dag> read only access (stable) is pretty limiting
-
            02:14 <@nop> I'm so excited
-
            02:14 <@nop> this toorcon speech might get me killed ;)
-
            02:14 < nemesis> hrhr
-
            02:14 < nemesis> nooo nooo
-
            02:15 < nemesis> i linke the read only
-
            02:15 <@nop> sorry
-
            02:15 <@nop> I'm all interrupting
-
            02:15 <@nop> ;)
-
            02:15 < nemesis> because i stored some files in a ntfs5.1 part
-
            02:15 < nemesis> ;)
-
            02:15 < aum> nop - you better have a fast car out the back, and deliver the speech in a ski mask
-
            02:16 <@nop> did you read what I'm talking about
-
            02:16 <@nop> www.toorcon.org
-
            02:16 < aum> actually, a ski mask would be a good gimmick - that, and a throat-mike wired up to a harmoniser box to change your voice
-
            02:16 <@nop> and no I don't care if people know who I am, it's a risk I have to take for starting IIP anyway
-
            02:17 <@nop> haha
-
            02:17 <@nop> I have a friend who's an expert in make-up and disguise
-
            02:17 <@nop> could do that too
-
            02:17 < Dag> nop is it tammy faye"?
-
            02:17 < Dag> katherine harris?
-
            02:17 < aum> room will be fulla spooks
-
            02:18 <@nop> http://www.toorcon.org/speakers/james.html
-
            02:20 <@nop> making gov't irrelevant is the underlying tone
-
            02:21 <@nop> I contradict the keynote speaker
-
            02:21 <@nop> who works for nasa
-
            02:23 < Dag> nasa is evil
-
            02:23 < Dag> richard hoagland says so
-
            02:23 < Dag> they are withholding proof aliens exist
-
            02:24 <@nop> hehe
-
            02:24 < Dag> they bombed the face on mars
-
            02:24 <@nop> aum is quiet
-
            02:24 <@nop> hehe
-
            02:24 < Dag> to cover up that it really looked like a face
-
            02:24 < Dag> even in high res scans
-
            02:25 < Dag> if it were not for nasa, we would each have our own starship cruisers
-
            02:25 < Dag> and vacation planets as we speak
-
            02:25 < Dag> hell they even wont let that backstreet boy
-
            02:25 < Dag> on their stupid space station
-
            02:25 <@nop> haha
-
            02:25 <@nop> nsync but yeah
-
            02:26 < Dag> they dont want him to see who their real masters are
-
            02:26 <@nop> haha
-
            02:26 < Dag> and I dont mean the american taxpayer
-
            02:26 <@nop> yep
-
            02:27 < Dag> the government is not run by the taxpayer
-
            02:27 <@nop> you know what I notice
-
            02:27 <@nop> every corporate position in a company
-
            02:27 < Dag> I think the fairest govt would be one were the number of votes you have is in line with the taxes you pay
-
            02:27 <@nop> is desired by a selfish person
-
            02:27 <@nop> right
-
            02:27 < Dag> maybe 1 vote for each 5k in taxes you pay
-
            02:28 < Dag> the government is run on theft
-
            02:28 < Dag> steal steal steal
-
            02:29 < Dag> rms is a commie too
-
            02:29 < Dag> did you know that
-
            02:29 <@nop> that's why they punish drug dealers
-
            02:29 <@nop> because the gov't is stealing the money they make
-
            02:29 <@nop> you notice
-
            02:29 <@nop> they always wait
-
            02:29 <@nop> till the dealer
-
            02:29 <@nop> is making big money
-
            02:29 <@nop> to get their bust
-
            02:29 <@nop> they don't care about the lowly pot dealer
-
            02:29 <@nop> they always like to let it continue
-
            02:29 <@nop> till they know
-
            02:29 < Dag> the us govt is the biggest drug dealer out there
-
            02:29 <@nop> there is serious money coming in
-
            02:30 <@nop> then bam
-
            02:30 <@nop> robbin' from the dealer
-
            02:30 < Dag> bo gritz says so
-
            02:30 < Dag> harry brown for president
-
            02:30 < Dag> enuf said
-
            02:30 <@nop> hehe
-
            02:30 <@nop> charlie brown for president
-
            02:31 < Dag> what about snoopy
-
            02:31 <@nop> he's cool
-
            02:31 <@nop> he doesn't say much
-
            02:31 <@nop> so yeah
-
            02:31 < Dag> he always seemed level headed
-
            02:31 < Dag> cept he hung out with that bird a little to much
-
            02:31 < Dag> charlie brown was easily duped
-
            02:32 < Dag> how many times he try to kick that damn football?
-
            02:33  * aum is back
-
            02:33 < Dag> how big is a freenet install?
-
            02:33 <@nop> not big, 200 megs
-
            02:33 <@nop> for datastore
-
            02:33 <@nop> ;)
-
            02:33 < aum> default freenet datastore is 1GB these days 
-
            02:34 < Dag> yikes
-
            02:34 <@nop> what?
-
            02:34 < aum> on another subject, i uninstalled gentoo last night and went back to debian => bliss
-
            02:34 <@nop> really?
-
            02:34 < aum> the source-based distros are too flaky just now
-
            02:34 < Dag> go back to freebsd
-
            02:35 < Dag> er forward
-
            02:35 < Dag> heh
-
            02:35 < aum> debian 4 me - huge catalog of software, ready to urn
-
            02:35 < aum> s/urn/run/
-
            02:35 < Dag> well you running it as a server or desktop?
-
            02:35 < aum> debian stuff works wight out of the box - no need to read megs of manuals and grope through scripts
-
            02:36 < Dag> I always compile my servers
-
            02:36 < aum> i've had debian woody on my server for over a year - switched desktop from windows back in feb
-
            02:37 < aum> my desktop went windoes -> mandrake -> debian -> sourcemage -> gentoo -> debian
-
            02:37 < Dag> you ever try knoppix?
-
            02:37 < aum> what's that?
-
            02:37 < aum> a distro?
-
            02:37 < Dag> is a livefilesystem linux distro
-
            02:37 < Dag> based off debian
-
            02:37 < aum> huh?
-
            02:37 < aum> what does 'livefilesystem' mean?
-
            02:37 < Dag> the whole thing runs in ram and cd
-
            02:38 < Dag> boot off the cd
-
            02:38 < Dag> and away you go
-
            02:39 < Dag> its pretty good about hw detection
-
            02:39 < Dag> runs kde and even has openoffice
-
            02:39 < Dag> heh
-
            02:39 < Dag> I dont run any linux servers anymore
-
            02:39 < Dag> but its fun to have around
-
            02:39 < aum> Dag: freeBSD?
-
            02:40 < Dag> free/openbsd
-
            02:40 < Dag> solaris
-
            02:40 < aum> what's the big advantage?
-
            02:40 < Dag> depending on HW
-
            02:40 < Dag> openbsd has a good security audit
-
            02:40 < Dag> of anything they release
-
            02:40 < Dag> no distro of linux even comes close
-
            02:41 < aum> but linux 'ploits get fixed within 24 hours
-
            02:41 <@nop> true
-
            02:41 < Dag> do you check for exploits and patch every day?
-
            02:41 <@nop> I do
-
            02:41 < Dag> well
-
            02:41 < Dag> come now
-
            02:41 < Dag> heh
-
            02:41 <@nop> I'm on bugtraq
-
            02:41 <@nop> and I sometimes post
-
            02:41 <@nop> so I keep my eye out
-
            02:42 < Dag> openbsd has had ONE remote exploit in 6 years
-
            02:42 <@nop> it's my daytime job
-
            02:42 <@nop> openBSD is very conscious
-
            02:42 <@nop> which is good
-
            02:42 <@nop> proves
-
            02:42 <@nop> that all it takes
-
            02:42 <@nop> is more conscious coders
-
            02:42 <@nop> and a conscious framework
-
            02:43 < Dag> if you install redhat without patches
-
            02:43 < Dag> its a guarantee you will be hacked
-
            02:43 < Dag> I use to work in a NOC
-
            02:43 < Dag> it would piss me off when other lazy coworkers would install rh 6.2 etc
-
            02:43 < Dag> for a client
-
            02:44 < Dag> and never put any patches on
-
            02:44 < Dag> one guy worked there 3 years and his idea of rebooting a box was to hit the power switch
-
            02:46 < aum> power switch? did he think it was windows?
-
            02:46 < nemesis> lol
-
            02:46  * aum sometimes sees the linux BSOD screensaver
-
            02:47 < Dag> there was a time like 4 years back that anyone could get a tech job
-
            02:47 < Dag> now people who have a brain and experience
-
            02:47 < Dag> cant find sh*t
-
            02:47 < aum> an open source advocate here in new zealand wrote to the Minister for Information Technology expressing concerns about windows security vulnerabilities - Minister wrote back saying "we don't have a security problem - we use firewalls"
-
            02:48 < Dag> you hear the latest with XP and their help center allowing you to delete files by visiting a url
-
            02:48 < Dag> heh
-
            02:48 < Dag> there is a story at the register uk about it
-
            02:49 < Dag> there is even a link to have the exploit remove the help center from your machine
-
            02:49 < Dag> and in doing so removes the ablity to be exploited
-
            02:50 < Dag> Win-XP Help Center request wipes your HD
-
            02:50 < Dag> http://www.theregister.co.uk/content/4/27074.html
-
            03:03 < nemesis> erm, sorry
-
            03:03 < nemesis> question
-
            03:03 < nemesis> can i ban an port with bind to an nic?
-
            04:14 < nemesis> cu@all für genau 50 mins ins bett legen dann duschen und in arbeit fahren *grummel*
-
            08:05 < nop> sheesh
-
            08:05 < nop> still here
-
            --- Log closed Wed Sep 25 10:20:49 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting120.html b/www.i2p2/pages/meeting120.html
deleted file mode 100644
index 41c8cddc..00000000
--- a/www.i2p2/pages/meeting120.html
+++ /dev/null
@@ -1,490 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 120{% endblock %}
-{% block content %}
            I2P dev meeting, December 14, 2004
            
-
            
-
            13:08 < jrandom> 0) hi
            
-
            13:08 < jrandom> 1) Net status
            
-
            13:08 < jrandom> 2) mail.i2p
            
-
            13:08 < jrandom> 3) roadmap
            
-
            13:08 <+polecat> It's almost as if the nodes are using the time they got 5 min ago, and setting it to the current time instead of the real time.
            
-
            13:09 < jrandom> 4) i2pcontent
            
-
            13:09 < jrandom> 5) i2p-bt
            
-
            13:09 < jrandom> 6) ???
            
-
            13:09 < jrandom> 0) hi
            
-
            13:09 < jrandom> weekly status notes posted a few minutes back to http://dev.i2p.net/pipermail/i2p/2004-December/000522.html
            
-
            13:09  * Pseudonym waves
            
-
            13:10 < cervantes> thanks for waiting.... just got back from work ;-)
            
-
            13:10 < jrandom> polecat: it isnt exactly 5m (but we can discuss further after the meeting or in it)
            
-
            13:10  * polecat nod
            
-
            13:10 < jrandom> w3rd, well, i'll give you a moment to jump into the status notes then :)
            
-
            13:11 < jrandom> in the meantime, 1) Net status
            
-
            13:11  * postman waves
            
-
            13:11 < jrandom> the other day, as mentioned on the list, it was pretty turbulent on irc
            
-
            13:12 < jrandom> we've made some adjustments though and the bugfixes have gone pretty well
            
-
            13:12  * dm waves
            
-
            13:12 < jrandom> in addition to the time sync issue mentioned in the mail, there's also a "leases expiring" problem that some have been reporting
            
-
            13:13 < Pseudonym> are they related?
            
-
            13:13 <+protokol> (for months)
            
-
            13:13 < Pseudonym> (the issues, not the people)
            
-
            13:13 < jrandom> thats due in part to a variety of issues, some of which may be addressed by the patches in CVS, some of which may be time sync related, but most of which are due to issues we're working on for the 0.5 release
            
-
            13:14 < jrandom> the essence of the problem is that the peer is sometimes unable to build tunnels for the client, which means it won't ask the client for a new lease
            
-
            13:14 < jrandom> the solution is to make sure we can build new tunnels that meet the client's needs
            
-
            13:15 < Pseudonym> and if we can't?
            
-
            13:15 < jrandom> if we can't, the leases will stay expired until we can
            
-
            13:16 < Pseudonym> so, how is that different?
            
-
            13:16 < jrandom> it isn't :)  
            
-
            13:16 < jrandom> we need to be able to build tunnels, period.
            
-
            13:16 < jrandom> to assure that we can, we must both improve our profiling (see: cvs fixes for a long standing profiling bug) and improve our pooling strategy (see: 0.5)
            
-
            13:17 < jrandom> the only legitimate cause for not being able to build tunnels is if the entire net is completely saturated
            
-
            13:17 <+polecat> or you're cut off from it
            
-
            13:17 < jrandom> right
            
-
            13:17 < bla> jrandom: Can this be because the net has grown to ~110 peers?
            
-
            13:18 < dm> or its cut off from you
            
-
            13:18 < jrandom> nah, we've seen this before too bla
            
-
            13:18 < Pseudonym> are the "cvs fixes for a long standing profiling bug" in 0.4.2.3 or just CVS?
            
-
            13:18 < jrandom> though in a way, i suppose it is, since we now have a lot more peers that we have no profiling data on
            
-
            13:18 < jrandom> Pseudonym: CVS
            
-
            13:19 <+polecat> By profiling you mean ranking peers according to how helpful they are?
            
-
            13:19 < jrandom> yeah
            
-
            13:19  * Pseudonym wants 0.4.2.4 ;-)
            
-
            13:19 <+polecat> Phew.
            
-
            13:19 <+polecat> Thought it was some weird kinda function tracing like gprof or something.
            
-
            13:20  * orion wants 2.0 :)
            
-
            13:20 < jrandom> hehe naw, the profiling bug was in part due to some stupid code that was ignoring daily stats
            
-
            13:20  * jrandom too
            
-
            13:20  * polecat wants the larval form of a large dog.
            
-
            13:20 < jrandom> ok, well, thats about all i've got to bring up for 1) net status - anyone else have anything to add?
            
-
            13:21 < jrandom> if not, moving on to 2) mail.i2p
            
-
            13:21 < jrandom> postman: you've got the floor
            
-
            13:22 <+postman> ok
            
-
            13:22 <+postman> sorry
            
-
            13:22 <+postman> :)
            
-
            13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual
            
-
            13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual.html
            
-
            13:23 <+postman> (too much red wine)
            
-
            13:23 < dm> this is a very unprofessional presentation!
            
-
            13:23 <+postman> it tries to explain a system how to handle maildomains other than @mail.i2p addresses
            
-
            13:23 < frosk> :D
            
-
            13:24  * orion smacks dm in the head with the chalkboard eraser.
            
-
            13:24 < frosk> does that i can have frosk@frosk.i2p?
            
-
            13:24 <+postman> frosk: indeed
            
-
            13:24 < jrandom> v.cool
            
-
            13:24 <+polecat> The question is, why?  :3
            
-
            13:24 <+postman> it's quite complex, still i ask for comments and ideas for this one
            
-
            13:24 < cervantes> s/eraser/
            
-
            13:24 < frosk> froody cool
            
-
            13:25 <+postman> it might not be a needed feature for a few ppl but the future is bright and shiny
            
-
            13:25 < jrandom> there are lots of reasons why - e.g. giving each user @ forum.i2p a mail address, etc
            
-
            13:25 < susi23> its a central system bound to postman.i2p
            
-
            13:25 <+polecat> Yes, that much seems clear.
            
-
            13:25 < susi23> if that machine fails, we're all upset :)
            
-
            13:25 <+polecat> jrandom: But if it all has to go through mail.i2p in the first place...
            
-
            13:25  * postman is VERY aware of this problem 
            
-
            13:26 <+postman> :/
            
-
            13:26 < jrandom> polecat: perhaps, but perhaps not
            
-
            13:26 <+polecat> susi23: exactly!
            
-
            13:26 <+postman> the recent implementation is indeed quite single point of failure 
            
-
            13:26 <+postman> but this applys to the internet bridge as well
            
-
            13:27 < jrandom> oh, the second gateway isn't in place yet?
            
-
            13:27 <+polecat> One solution is to put multiple destinations in the client SMTP/POP3 tunnels, and have all these destinations relay only with each other.
            
-
            13:27 <+postman> jrandom: no baffled has not setup yet
            
-
            13:27 < jrandom> ah ok
            
-
            13:27 <+postman> polecat: and on WHAT pop3 server should YOUR mailbox reside
            
-
            13:27 < orion> shiny is good, but how tould that virtual address relate to an internet address?  I like the fact that orion@mail.i2p and orion@i2pmail.org are both usable.
            
-
            13:27 < orion> s/usable/identical/
            
-
            13:28 <+postman> polecat: who wants to transfer 100MBs of mailbox data every day in 1 year for all 10000 users?
            
-
            13:28 <+postman> orion: they will be usable
            
-
            13:28 <+polecat> instead of going mail.i2p -> polecat.i2p -> frosk@baffled.i2p, it could go to either of the 3, and from there straight to baffled.
            
-
            13:29 <+postman> i ask all ppl interested to contribute some ideas
            
-
            13:29 <+postman> still the virtual domains is a feature that appears useful and can be implemented regardless of the state of the network
            
-
            13:29 <+polecat> So if mail.i2p ever dies, the other two will have their server tunnels available as alternatives into the mail relay system.
            
-
            13:30 <+postman> polecat: still there is the question of your mailbox 
            
-
            13:30 <+postman> polecat: your mailbox data must be moved as well and kept synchronized between ALL possible location
            
-
            13:30 <+polecat> Ugh... yeah that's true...
            
-
            13:30 <+postman> polecat: just consider this for 1000 users in the future
            
-
            13:30 < susi23> everybody could set up a destination on their nodes where mails are delivered to... now we have to problem to connect destinations to mail addresses
            
-
            13:30 <+postman> it's not THAT easy
            
-
            13:30 <+polecat> Oh!  But this would work though...
            
-
            13:30 <+postman> indeed
            
-
            13:31 <+postman> otoh the problem of relaying from and to the internet is still there
            
-
            13:31 < dm> jrandom: you're enjoying this, aren't you?
            
-
            13:31 <+polecat> Yes!  A user chooses which server to have their POP3 mailbox on, and that is the server they choose as destination for the POP3 tunnel.
            
-
            13:31 <+postman> polecat: what if THIS server fails?
            
-
            13:32 <+polecat> So mail.i2p and polecat.i2p never even have to see baffled's POP3 mailbox, since all of baffled's POP3 users download straight from baffled.
            
-
            13:32 <+postman> a real redundant system will require a mailbox sync
            
-
            13:32 < susi23> yeah, but with such a system everybody could deliver mails within i2p, even if postman.i2p would not be there
            
-
            13:32 <+polecat> postman: Then they have to change servers.  -.-
            
-
            13:32 < dm> Students having an intelligent conversation between each other. A professor's dream :)
            
-
            13:32 <+postman> well, the meeting is hardly the place to DISCUSS all those things
            
-
            13:33 <+postman> i am just here to trigger the discussion
            
-
            13:33 <+postman> read the document first please and AFTER THAT i am ready to hear your comments
            
-
            13:33 <+postman> 2.
            
-
            13:33 <+polecat> Alright, so mail.i2p is in the works, and attempting to become less centralized and single point failurey.
            
-
            13:33 <+postman> we officially crossed the 100 users with 110 registered accounts
            
-
            13:33 <+postman> just FYI
            
-
            13:33 < jrandom> w00t
            
-
            13:34 <+postman> thats all for today :)
            
-
            13:34 <+postman> thanks 
            
-
            13:34  * dm applauds
            
-
            13:34 < jrandom> kickass, thanks postman.  it all looks promising
            
-
            13:34 <+postman> :)
            
-
            13:35 < mule2> i'd like to bring up a topic on mail, but after the meeting
            
-
            13:35 < jrandom> perhaps some mail-decentralization discussions could go on over the list or on the forum?  but for now what you've got set up more than meets our needs
            
-
            13:35 <+postman> there's even a channel for it
            
-
            13:35 <+postman> :)
            
-
            13:35 < jrandom> heh good point 
            
-
            13:35 < frosk> which one?
            
-
            13:36 < jrandom> #mail.i2p
            
-
            13:36 <+postman> frosk: #mail.i2p
            
-
            13:36 <+polecat> Oh, one quick note I just surprised myself by getting a little perl caching SMTP server going, so emacs doesn't hang waiting for postman's SMTP server to respond over i2p.
            
-
            13:36 < frosk> ok
            
-
            13:36 <+polecat> I might post some code later, if it works like, really well.
            
-
            13:36 < jrandom> oh, kickass polecat 
            
-
            13:36 < cervantes> postman: you're welcome to have a dedicated section on the forum
            
-
            13:37 <+postman> cervantes: ohh thanks
            
-
            13:37  * postman feels honoured :)
            
-
            13:37 < dm> You deserve it
            
-
            13:38  * postman hands the mike back to hr
            
-
            13:38  * postman hands the mike back to jr
            
-
            13:38 <+postman> damn
            
-
            13:38 <+postman> :)
            
-
            13:38 < jrandom> ok, if there's nothing else on 2) mail.i2p, lets jump on over to 3) roadmap
            
-
            13:38 <+polecat> vroom vroom!
            
-
            13:38 < jrandom> the old roadmap was looking a little... out of date
            
-
            13:39 < jrandom> the new one reflects the current view of things
            
-
            13:39 < jrandom> hopefully the schedule listed has enough padding, though if more people jump on board perhaps we can beat those estimates :)
            
-
            13:40 < jrandom> once we've hit 0.6, we'll be able to scale to large numbers of nodes, as we wont have the thread-imposed ceiling
            
-
            13:41 < frosk> what do you think is a realistic node limit for < 0.6?
            
-
            13:41 < jrandom> prior to 0.6 though, we'll probably need to stay under 200 active nodes, though we can probably stop being so lazy and actively kill some connections
            
-
            13:41 < jrandom> with some care, i think we'll be able to get up to 3-500
            
-
            13:42 < mule2> so no slashdotting please
            
-
            13:42 < jrandom> we'd have connection churn at that point, but our low-cost tcp transport shouldn't hurt too much
            
-
            13:42 < Pseudonym> the roadmap for 0.6 doesn't mention that. just udp and content dist
            
-
            13:42 < Pseudonym> or is it the udp that fixes it?
            
-
            13:42  * orion votes for no slashdotting ever
            
-
            13:43 < jrandom> Pseudonym: udp fixes it (http://www.i2p.net/todo#transport )
            
-
            13:43 < cervantes> postman: http://forum.i2p/viewforum.php?f=22
            
-
            13:44 < Pseudonym> orion: I disagree. to get real anonymity we're going to need LOTS of nodes eventually
            
-
            13:44 < Pseudonym> at some point we have to tell people about it
            
-
            13:44 < jrandom> agreed.  when we need 'em, we'll definitely want to do all sorts of PR
            
-
            13:44 < jrandom> the geek crowd will likely be a large part of the userbase
            
-
            13:44 < Pseudonym> when do we announce to the geek community? not as a finished product but as a beta for tire-kicking
            
-
            13:44 < Frooze> Ask JRandom
            
-
            13:45 <+polecat> I think we should be very careful about making this network too popular.
            
-
            13:45 < jrandom> Pseudonym: when we've done the best tire kicking we can without them
            
-
            13:45 <+polecat> Because one of these days someone is going to use it to do something horrible and illegal.
            
-
            13:45 <+polecat> And if we can be tracked down at that point, we will be persecuted right along with the criminal.
            
-
            13:46 < jrandom> basically, once the network works great consistently and we're not able to do tihngs to b0rk it up, /then/ we'll need to get more users to help break/test it
            
-
            13:47 < mule2> you have to kick me off before :9
            
-
            13:47 < Pseudonym> just don't fall into the same trend as Toad with freenet
            
-
            13:47 <+polecat> Because we gave them the freedom to post the source code for Windows XPQXR, and Halo 7, so we'd better as all heck have good anonymity protection.
            
-
            13:47 < orion> speaking of b0rking... was that time-skew bug ever identified?
            
-
            13:47 < jrandom> Pseudonym: i believe our roadmap is realistic
            
-
            13:48 < jrandom> polecat: agreed, people shouldn't use i2p for things that are 'dangerous' yet
            
-
            13:48 < jrandom> orion: no
            
-
            13:48 < Pseudonym> jr: I'm not complaining about the roadmap. but it doesn't address announcements
            
-
            13:48 < jrandom> true
            
-
            13:49 < dm> well, with 2 years of development/testing under its belt, it should be one of the most polished offerings of this type when it launches :)
            
-
            13:49 < Pseudonym> perhaps add slashdotting to 0.6? :-)
            
-
            13:49 <+polecat> jrandom: More importantly, people who would use i2p for things that dangerous would do us a lot of good if they didn't know about i2p just yet.
            
-
            13:49 < jrandom> i was thinking about that the other day.  perhaps some announcements for other activities (e.g. I2PContent) would make sense, to draw more people in to work on them
            
-
            13:49 < dm> as opposed the usual level of maturity when things go big
            
-
            13:50 < ant> <jnymo> i think jrandom should write the slashdot article.. he's best at describing i2p, i think
            
-
            13:50  * Pseudonym agrees
            
-
            13:51 < dm> I'm sure something will go on there before jrandom is comfortable to do it himself ;)
            
-
            13:51 < Pseudonym> I'm just trying to nudge him a bit
            
-
            13:51 < jrandom> heh
            
-
            13:51 < jrandom> well, with 0.6 we'll want to attract a larger user base in any case
            
-
            13:51 < Pseudonym> I figure if I can't code, I can at least pester the people who can
            
-
            13:51  * jrandom flings mud
            
-
            13:52 <+polecat> dm: I'm sure the Second Coming will pass before jrandom is comfortable enough to /. i2p  ;3
            
-
            13:52  * Pseudonym ducks. quack
            
-
            13:52 < jrandom> ok, in any case, anyone have anything else to discuss wrt the roadmap?
            
-
            13:52 < jrandom> or shall we move on to 4) I2PContent ?
            
-
            13:53 -!- Irssi: #i2p: Total of 36 nicks [1 ops, 0 halfops, 3 voices, 32 normal]
            
-
            13:53 < jrandom> frosk: ping
            
-
            13:53  * frosk grabs the wireless mic
            
-
            13:54 < cervantes> *zzzzzZzzzzttt*
            
-
            13:54  * orion plugs in his RF jammer. ;)
            
-
            13:54 <+polecat> I have been trying to get ahold of frosk, without luck as such yet.  Frankly I think I might never see em on IRC, and eir email is a sightless void.
            
-
            13:54 < frosk> well, jrandom put this "distributed content infrastructure" on the new roadmap for 0.6, and after hearing some thoughts about it here, it sounded really interesting, and i figure i should do whatever my skills allow to beat the schedule ;)
            
-
            13:54  * dm looks at polecat
            
-
            13:54 <+polecat> *shakes head*  Just no luck whatsoever.  No where to be FOUND.  Maybe frosk is invisible!
            
-
            13:55 < frosk> "i2pcontent" is so far a document at frosk.i2p
            
-
            13:55 < Pseudonym> how is I2PContent different from i2p-bt?
            
-
            13:55  * polecat is on 4.4 atm.
            
-
            13:55 < frosk> it merges the ideas i've heard with my own, and it has gone through some revisions with helpful comments and suggestsions from jrandom and others, and i think it's starting to look very cool :)
            
-
            13:55 < ant> * jnymo tries to find a postscript viewer to see these ideas.. :/
            
-
            13:56 < dm> what is it, I can't get to frosk.i2p. Executive summary?
            
-
            13:56 <+polecat> Pseudonym: i2p-bt only applies to 1 file at a time, and is a swarming download.
            
-
            13:56 < frosk> Pseudonym: i2pcontent is a lot like Usenet
            
-
            13:56 < frosk> it merges concepts from usenet and freenet. i shall refrain from calling it "frusenet".
            
-
            13:56 < jrandom> lol
            
-
            13:56 <+polecat> Did you get my suggestion on i2pcontent?
            
-
            13:56 < jrandom> frusenet has a ring to it...
            
-
            13:56 < frosk> i2pcontent lets you post messages to your blog or to public forums, and publish your address book for others to import
            
-
            13:56  * dm did not refrain from calling it frazaa
            
-
            13:56 <+polecat> It merges usenet, freenet and livejournal.  So.... Fusejournal?
            
-
            13:56 < jrandom> rofl
            
-
            13:57 < frosk> hm, yeah, LJ too ;)
            
-
            13:57 <+polecat> Lj is the closest parallel I've found.
            
-
            13:57 <+polecat> But here's one thing I didn't read in your i2pcontent document.
            
-
            13:57 < frosk> anyway, at this point i really want it well designed, so i urge anyone who's interested to read the document and make suggestions
            
-
            13:57 < orion> LiveFuseNet.
            
-
            13:58 <+polecat> What about making it so only a few people can /read/ a group?  Not so much encrypting it, but preventing its existence from even being known.
            
-
            13:58 < dm> How about: Contnet? ContNet
            
-
            13:58 < dm> Content, Contnet... get it? eh???
            
-
            13:58 < susi23> jnymo: regarding postscript, I kindly asked frosk to supply us with pdf *blush*
            
-
            13:58 < frosk> polecat: that may be interesting, yeah. it's hard to fit into the current design, though
            
-
            13:58 < jrandom> i'm not sure, it sounds pretty doable
            
-
            13:59 <+polecat> I want HTML or plain text myself.  -.-  Don't like bitmap ps readers. -.-
            
-
            13:59 < jrandom> rather than offering a group for syndication, only trusted/known users can get the group
            
-
            13:59 < jrandom> (off trusted/known syndication nodes)
            
-
            13:59 < frosk> polecat: http://frosk.i2p/i2pcontent-3.pdf if you can handle pdf's :)
            
-
            13:59 < jrandom> kind of like usenet's "Distribution:" header
            
-
            13:59 < susi23> polecat: ps is not bitmap :P
            
-
            13:59 <+polecat> frosk: It's important though, if you want to have things like private mailboxes, or secret groups, or livejournal's ability to block text to all but certain friends.  Also moderated forums will probably be important to have that.
            
-
            13:59 < frosk> hm, yeah
            
-
            14:00 < frosk> polecat: blocking to all but friends can be handled with encryption
            
-
            14:00 <+polecat> frosk: My PDF reader is this: $ pdf2ps file.pdf > file.ps; gs file.ps
            
-
            14:00 < jrandom> polecat: you had a good suggestion for moderated forums the other day - an unmoderated submission queue, with moderators posting to the "real" group
            
-
            14:01 <+polecat> frosk: Encryption is good, and hopefully somewhat transparent.  Otherwise users will have to type text in an xterm running gpg, copy it and paste it to the journal window.  >.<
            
-
            14:01 <+polecat> jrandom: Yes, but ideally the submission queue should be invisible to all but the moderators.
            
-
            14:01 < frosk> polecat: oh, transparency is an important keyword in the whole thing :)
            
-
            14:01 < jrandom> polecat: you'd lose 99% of the target audience if you say "xterm"
            
-
            14:02 <+polecat> jrandom: Heathens!  A grep on them!
            
-
            14:02 < ant> <jnymo> mmmmm.. what's usenet?
            
-
            14:02 < ant> <jnymo> I mean i've heard of it.. but
            
-
            14:02 < susi23> jnymo: news, nntp, google -> groups
            
-
            14:02 < frosk> http://en.wikipedia.org/Usenet :)
            
-
            14:03 <+polecat> jnymo: newsgroups, eh?
            
-
            14:03 < dm> It's good for random porn downloads.
            
-
            14:03 < frosk> it's basically the world's oldest and most proven p2p net, as jrandom wrote today
            
-
            14:03 < ant> <jnymo> so you can post files up? or links to files?
            
-
            14:03 < jrandom> and its bloody resiliant
            
-
            14:03 < susi23> dm: its 'use'ful for random porn downloads :P
            
-
            14:03 <+polecat> dm: I suppose, if you can find the porn around all the spam.
            
-
            14:04 < frosk> it's first and foremost for discussion groups, but it's widely used for files too
            
-
            14:04 <+polecat> There's another issue actually.  Spam and all..
            
-
            14:04  * dm used to run a 'porn downloader'. It worked well.
            
-
            14:04 < ant> <jnymo> so its like the forum format of irc?
            
-
            14:04 < frosk> i have thought about spam on i2pcontent, and i don't look forward to it ;)
            
-
            14:04  * susi23 points back to topic *blush*
            
-
            14:04 <+polecat> We can't have open forums, or at least we can't only have forums with 1 author, and forums without restriction.  We need some kind of happy medium where multiple people can post, but not unauthorized people.
            
-
            14:04 <+dinoman> i have just 1 thing to ask would i have to run this ie is it going to be part of i2p?
            
-
            14:05 < frosk> polecat: i2pcontent has that (groups of users editing one blog)
            
-
            14:05 < dm> It's amazing usenet is so big considering how few people actually use it.
            
-
            14:05 < dm> Average Joe doesn't know what usenet is.
            
-
            14:05 < jrandom> dinoman: its an application, definitely not required
            
-
            14:06 <+dinoman> :)
            
-
            14:06 < ant> <jnymo> yea.. i'm average joe
            
-
            14:06 < frosk> but hopefully distributed with i2p ;)
            
-
            14:06 <+polecat> So pretty much you have a list of sha4 in meta.group.*, one list for approved syndicators/readers, one for writers, one for owners, etc...
            
-
            14:06 < jrandom> (but i can see no reason why not use it, as 1) installing it doesn't add *any* overhead to your machine 2) lots of good features :)
            
-
            14:07 < jrandom> frosk: definitely 
            
-
            14:07 < dm> Google seems to be giving it some exposure. It should be presented as "the biggest message board in the world", and have a similar UI to the usual forums.
            
-
            14:07 <+polecat> jrandom: Why would you say *no* overhead?  c.c
            
-
            14:07 <+polecat> Just because you have to select syndicates and blogs to read, before you will download them?
            
-
            14:07 < jrandom> jnymo: a usenet-like itnerface to the i2p mailing list: http://news.gmane.org/gmane.network.i2p
            
-
            14:08 < jrandom> polecat: no, 0 overhead if you don't use it
            
-
            14:08 < frosk> polecat: groups have one owner who can add users. as for "secret" message namespaces, i haven't thought about that till now :)
            
-
            14:08 < jrandom> (as in, just having it installed doesnt make your machine a public data store, etc)
            
-
            14:08 -!- ]Replica[ is now known as ]Replica|zZz[
            
-
            14:08 < jrandom> and there will probably be i2p announcements done over secure blogs in i2p, worth reading, etc
            
-
            14:08 <+polecat> frosk: No reason it can't have multiple owners, though only one could go in the sha for the name.  :3  Just allow multiple people to modify the meta.* stuff for that group.
            
-
            14:09 < frosk> so in closing, if you're interested in helping out, read the document at frosk.i2p and let's talk :) anything else on i2pcontent?
            
-
            14:09 <+dinoman> oh so it is not freenet over i2p!
            
-
            14:09 < frosk> (i have quite a lag here right now)
            
-
            14:09 < jrandom> right dinoman, definitely not
            
-
            14:09 < susi23> data organized in "newsgroups" would be great...simply delete/unsubscribe i2p.childporn.* ...
            
-
            14:09 <+polecat> dinoman: En. Oh.
            
-
            14:10 < ant> <jnymo> jrandom: ah.. that's cool
            
-
            14:10 < jrandom> word frosk.  this is definitely some cool shit, and people should throw tons of email at you, and read your blog :)
            
-
            14:10 < ant> <jnymo> useful ;)
            
-
            14:10 <+polecat> susi23: Right, and if nobody wants to syndicate it, then nobody has to help move it around.
            
-
            14:10 < frosk> polecat: yeah, though it adds a bit of complexity, and i'm a simplicity freak ;)
            
-
            14:10 < jrandom> jnymo: aye.  but we can do some really cool shit beyond that, making things look like http://www.livejournal.com/ or blogger or whatever
            
-
            14:11 < jrandom> yeah, its best not to aim too high at the start (</lesson learned>).  go for the simplest thing that could possible work, with hooks for later improvement
            
-
            14:11 < frosk> the rendering is of course 100% up to the user client (web interface that looks like LJ? ok. slashdot-like? fine! etc :)
            
-
            14:12 <+polecat> frosk: I just think permissions should be generalized, and not "only one" for owner, "just a few" for writer, "everybody and their mother" for reader, unless the forum itself specifies those permissions.  Otherwise you're hardcoding many types of authorization.
            
-
            14:12 < frosk> jrandom: yes, extensionability is king
            
-
            14:12 < frosk> which is why a sound design from the start is important
            
-
            14:13 <+dinoman> so let me see if i get this to me (end user) this is going to work like newsgroups.
            
-
            14:13 < frosk> polecat: agree
            
-
            14:13 <+polecat> dinoman: More like Livejournal, but yes.
            
-
            14:14 <+dinoman> well i could learn to like this idea!
            
-
            14:14 < frosk> technically it's like newsgroups (on speed), but on the surface it can be like livejournal
            
-
            14:14 <+polecat> frosk: Also not like LIvejournal, in that it's decentralized Usenet style.  So the user has to pick syndicates, instead of the one syndicate LJ.
            
-
            14:15 < frosk> polecat: yes. the user software does the syndicate picking in most cases though, so most users won't have to know about many technicalities
            
-
            14:16 <+polecat> Hmm... perhaps.  You'd have to have a way for the software to find the syndicates though.  Aside from the user copying the hash from IRC into the i2pcontent add syndicate box.
            
-
            14:17 < jrandom> polecat: syndicate(s) used are included in the meta.* post
            
-
            14:17 < frosk> polecat: yes, i2pcontent comes with a few "seed syndicates", and the user asks them for more
            
-
            14:17 < ant> <Asciiwhite> frost, livejournal?, sounds brillient...
            
-
            14:17 <+polecat> jrandom: You need a syndicate to get a meta.* post.  8)  frosk: yeah something like that, cool.
            
-
            14:17 < frosk> ah yes, frost people will love i2pcontent ;)
            
-
            14:18 < jrandom> heh true
            
-
            14:18 < frosk> jrandom: that wasn't my plan, but it sounds very smart, actually :)
            
-
            14:18 < frosk> the current syndicate database is a sore point in some ways
            
-
            14:18 < jrandom> i thought i saw it in one of your .ps files, perhaps it was just in a conversation though
            
-
            14:19 <+polecat> Make it a kademelia DHT!  X3
            
-
            14:19  * jrandom groans
            
-
            14:19 < jrandom> but yeah, there are lots of optimizations on the syndicate database that can be done
            
-
            14:19 < frosk> perhaps you're just thinking smart thoughts and exchange what you read with that ;)
            
-
            14:19 < jrandom> lol
            
-
            14:19 < ant> <jnymo> so can you embed html?
            
-
            14:19 <+polecat> *chants*  DHT DHT DHT USA US--
            
-
            14:19 < jrandom> jnym: any content
            
-
            14:20 <+polecat> jnymo: Either that or some sort of bbcode type thing.
            
-
            14:20 < jrandom> yeah, rendering would be safest with a bbcode-like syntax
            
-
            14:20 < dm> frosk: would you like a dedicated section on cervantes' forum?
            
-
            14:20 < frosk> blogs and forums will expect text with some markup like bbcode
            
-
            14:20 < frosk> dm: i think it's kind of early yet :)
            
-
            14:21 < dm> frosk: consider it done!
            
-
            14:21 < cervantes> dm: would you like a private sound proof section on my forum?
            
-
            14:21 < dm> cervantes: make it so.
            
-
            14:21 < frosk> while i'm still on, please not that "i2pcontent" is just a dummy name since i didn't want to insult jrandom by calling it MyI2P ;) we need a more catchy name
            
-
            14:21 < dm> how about... contnet?
            
-
            14:22 < jrandom> frusejournalrent
            
-
            14:22 < frosk> i like!
            
-
            14:22  * dm rubs his hands in excitement
            
-
            14:22 < jrandom> </fark>
            
-
            14:22 < dm> </stupid jrandom tag>
            
-
            14:22 <+polecat> usejournalforrent?
            
-
            14:22 < ant> <jnymo> fusenet sounded pretty cool
            
-
            14:22 <+protokol> eepnet
            
-
            14:22 <+postman> uupnet :)
            
-
            14:22 < lurk> froops
            
-
            14:23 <+postman> LOL
            
-
            14:23 < dm> nnnnnnnnnnnntp
            
-
            14:23 <+postman> silly persons
            
-
            14:23 <+polecat> "frosk's catchy name for a content distribution syndicate network." We could say "Fcnfacdsn was inspired by Usenet..."
            
-
            14:23 < ant> <Asciiwhite> yeah i thought frusenet was good.
            
-
            14:23 < frosk> :D
            
-
            14:23 < jrandom> ok, please direct all silly names to frosk@mail.i2p :)
            
-
            14:23 <+polecat> frootloops!
            
-
            14:23 < frosk> i tried frusenet on a friend, he said "... or not."
            
-
            14:23 < jrandom> (along with any comments/concerns/etc)
            
-
            14:24 < frosk> although fusenet has a cool ring to it :)
            
-
            14:24 < dm> How about just 'Content' ?
            
-
            14:24 <+polecat> I like fusenet, it sounds... volatile.
            
-
            14:24 <+polecat> So yes.  Quieting down now.
            
-
            14:24 < Pseudonym> nn2p
            
-
            14:24 < dm> Nice and dinstinguished
            
-
            14:24 < jrandom> ooOOo
            
-
            14:24 < frosk> anyway, i'm not last on the agenda, we might want to move on ;)
            
-
            14:24 <+postman> NN2P is COOL
            
-
            14:24 < ant> <jnymo> if you had html.. you could have what looks like the net... inside froozlednet
            
-
            14:24 < jrandom> ok, moving on to 5) i2p-bt
            
-
            14:24 < jrandom> duck: you 'round?
            
-
            14:24 <@duck> meep
            
-
            14:24 < frosk> dm: "Content" is probably trademarked by Apple or whatever ;)
            
-
            14:25 < ant> <Asciiwhite> owww, is this a minutes ?
            
-
            14:25 <@duck> i2p-bt events this week:
            
-
            14:25 < dm> speeddating!@
            
-
            14:26 <@duck> - rss available on the trackers
            
-
            14:26 <@duck> - silly attempts to make a metatracker in #eeprnova
            
-
            14:26 < ant> <jnymo> noice
            
-
            14:26 < ant> <Asciiwhite> yeah, great idea.
            
-
            14:26 <+polecat> I still wish we could find a better codebase than that blasted bittorrent python source...
            
-
            14:26 < ant> <Asciiwhite> What about support for say samplers(i.e video/pics)
            
-
            14:26 <@duck> - some detailed code review leading to not finding bugs
            
-
            14:26 <@duck> most of the scary looking errors are pretty harmless
            
-
            14:27 <@duck> - I forgot
            
-
            14:27 <@duck> .
            
-
            14:27 < jrandom> word
            
-
            14:27 < jrandom> i've been watching the streaming lib activity while swarming, and there have been some improvements in cvs
            
-
            14:28 <+polecat> A metatracker lets you find trackers for files...?
            
-
            14:28 < ant> <Asciiwhite> so people can upload a small sample of video quality, or a thumbnail etc.
            
-
            14:28 < jrandom> (to keep up with the bt setup)
            
-
            14:28 <+polecat> jrandom: Improvements as of what date, this morning?  :3
            
-
            14:28 <@duck> polecat: yeah, well this one just announces new files into a channel; but it could be enhanced
            
-
            14:28 < jrandom> a day or two ago
            
-
            14:29 <+polecat> Just checking, because last time I got CVS Head, you updated to 0.4.3 a few hours later.
            
-
            14:29 < ant> <jnymo> yea.. is there some idea for i2ptorrent search some where down the eschelons?
            
-
            14:29 < jrandom> one of the neat things though is that i believe the main remaining i2p-bt bumps we're seeing are actually just i2p/streaming lib/sam problems
            
-
            14:30 <+polecat> Someone'd have to write a searching server, maybe by keyword and such.
            
-
            14:30 <@duck> or an irc bot
            
-
            14:30 < jrandom> jnymo: http://brittneyworld.i2p/bittorrent/
            
-
            14:30 < jrandom> polecat: files.i2p/
            
-
            14:30 < ant> <jnymo> hmm
            
-
            14:30 < ant> <jnymo> mmhmm.. yea. mk
            
-
            14:30 <+polecat> duck: Well a server to search, whether a bot or a eepsite like files.i2p...
            
-
            14:31 <@duck> if someone needs rss etc enhancements on the tracker for their bots etc, let me know
            
-
            14:31 < ant> <jnymo> hmm.. seems brittanyworld.i2p is down at the moment
            
-
            14:32 < jrandom> since it seems the remaining problems are i2p related, not i2p-bt related, we've marked the swarming file transfer bounty as completed
            
-
            14:32 < jrandom> (yay!)
            
-
            14:32 < ant> <jnymo> anyhoo
            
-
            14:32 < ant> * jnymo tips his hat
            
-
            14:32 < frosk> congrats to all involved, you rock
            
-
            14:33 < jrandom> aye, thanks to all the hard work of duck, ragnarok, dinoman, connelly, and drwoo
            
-
            14:33 <+polecat> ragnaroks! dinoman's da man!  Um...
            
-
            14:33 < ant> <Asciiwhite> nice work duck.
            
-
            14:33 <+polecat> I still want to get ctorrent ported to i2p.  It's a wicked efficient bittorrent thingy, if a little flaky on the UI.
            
-
            14:34 < dm> good work
            
-
            14:35 <+polecat> Anyone know where the info about SAM proxies is?
            
-
            14:36 < jrandom> about half of our general fund went towards that bounty, so our current balance is around $400USD [after some new donations today [yay!]]
            
-
            14:36 < jrandom> polecat: http://www.i2p.net/sam
            
-
            14:37 <+polecat> jrandom: Doing a swarming file transfer cost like, money?  o.O
            
-
            14:37 <+polecat> Ohh right the reward.
            
-
            14:37 < Pseudonym> it'd be kinda cool to have the general fund balance on the website
            
-
            14:37 < jrandom> right polecat :)
            
-
            14:37 < jrandom> thats a good idea Pseudonym 
            
-
            14:38 < Pseudonym> doesn't have to be updated daily, just occasionally
            
-
            14:38 < jrandom> i'll add it on to /bounties (sound good?)
            
-
            14:38 < Pseudonym> sure
            
-
            14:38 <+protokol> dont tell me they are keeping the hello chat room
            
-
            14:38 < cervantes> if he did that we'd all see how much it goes down whenever jrandom goes out for a pie and a pint lunch 
            
-
            14:39 < jrandom> heh cervantes 
            
-
            14:39 < Pseudonym> didn't somebody donate money for jrandom's beer?
            
-
            14:40 < cervantes> enough for half a pint at todays rates :)
            
-
            14:40 < jrandom> yeah we've had a few beer donations :)
            
-
            14:40 < jrandom> (list of donations up @ http://www.i2p.net/halloffame )
            
-
            14:40 < Pseudonym> are you spending them?
            
-
            14:41 < cervantes> nice...someone has money to burn I see ;-)
            
-
            14:41 < ant> <Asciiwhite> anonymous
            
-
            14:41 < ant> <Asciiwhite> $5.00 USD
            
-
            14:41 < ant> <Asciiwhite> buy jrandom a beer fund
            
-
            14:41 < ant> <Asciiwhite> lol
            
-
            14:42 < jrandom> it would be nice if we can grow the bounties on the CDN, as thats a truckload of work
            
-
            14:42 < jrandom> but we'll see how it goes over time
            
-
            14:42 < jrandom> ok, i think we're pretty off track for 5) i2p-bt
            
-
            14:42 < jrandom> so i suppose we should move to 6) ???
            
-
            14:42 <@duck> nothing to add here.
            
-
            14:43 < jrandom> is there anything else people would like to bring up?
            
-
            14:43 <@duck> - why do so many ppl have problems when they specify a hostname?
            
-
            14:43 < jrandom> not sure
            
-
            14:43 < jrandom> both of my routers use an explicit hostname
            
-
            14:43 <@duck> mine too, np
            
-
            14:44 <@duck> maybe the warning text should be more negative
            
-
            14:44 < jdot_> do we have a way to change keys on hostnames in hosts.txt?
            
-
            14:44 < jrandom> sounds good duck 
            
-
            14:44 <+polecat> Regarding addressbook...
            
-
            14:44 < jrandom> jdot_: no, not really, especially in light of the addressbook
            
-
            14:44 < jdot_> like, if I lost my previous eepsite key.  :(
            
-
            14:44 < mule2> same here - but i have problems :)
            
-
            14:44 <+polecat> Addressbook is going to be fused with i2pcontent, right?
            
-
            14:45 < mule2> but don't think these result from the hostname
            
-
            14:45 < Pseudonym> do we have a working addressbook?
            
-
            14:45 <+polecat> You subscribe to an addressbook just like you subscribe to a blog... except it overwrites userhosts.txt and such.
            
-
            14:45 < jrandom> polecat: distributing addressbooks through i2pcontent makes sense, yeah
            
-
            14:45 < jrandom> Pseudonym: http://ragnarok.i2p/
            
-
            14:45 <+polecat> Pseudonym: http://polecat.i2p/addressbook.pl.zip
            
-
            14:45 < jrandom> and http://pole...er, what he said
            
-
            14:45 < Pseudonym> thanks
            
-
            14:46 < jrandom> i think there's also another one at http://orion.i2p too
            
-
            14:46 < frosk> polecat: "overwrite" sounds dramatic. it "merges" ;)
            
-
            14:47 <+polecat> Yeah... I saw orion's too.
            
-
            14:47 < jdot_> dang
            
-
            14:47 < jrandom> jdot_: so it looks like you're outa luck :/
            
-
            14:47 < jrandom> ok, anyone else have anything for the meeting?
            
-
            14:48 < dm> merry xmas
            
-
            14:48 <+polecat> jdot: Thankfully when we've got fusenet working, you can update your i2p key with that eventually.
            
-
            14:49 < ant> <Asciiwhite> dm, 15th of december here :)
            
-
            14:49 < jrandom> and a happy Chanukah
            
-
            14:49 <+polecat> Christ was born in September, what's everyone all celebrating about?
            
-
            14:49 <+polecat> I'll stick with Yule thanks muchly.
            
-
            14:49 < jrandom> ok if thats it...
            
-
            14:49  * jrandom winds up
            
-
            14:50  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting121.html b/www.i2p2/pages/meeting121.html
deleted file mode 100644
index 70abeb3e..00000000
--- a/www.i2p2/pages/meeting121.html
+++ /dev/null
@@ -1,329 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 121{% endblock %}
-{% block content %}
            I2P dev meeting, December 21, 2004
            
-
            
-
            13:05 <@jrandom> 0) hi
            
-
            13:05 <@jrandom> 1) 0.4.2.4 & 0.4.2.5
            
-
            13:05 <@jrandom> 2) 0.5 strategy
            
-
            13:05 <@jrandom> 3) naming
            
-
            13:05 <@jrandom> 4) eepsite roundup
            
-
            13:05 <@jrandom> 5) ???
            
-
            13:06 <@jrandom> 0) hi
            
-
            13:06  * jrandom waves
            
-
            13:06 <@jrandom> weekly status notes posted a lil while ago @ http://dev.i2p.net/pipermail/i2p/2004-December/000528.html
            
-
            13:07 <@jrandom> lets jump on in to 1) 0.4.2.4 & 0.4.2.5
            
-
            13:08 <@jrandom> for those of you who have already upgraded to 0.4.2.5 - a good 1/3 of the network so far - thanks!
            
-
            13:09 <@jrandom> i do try to keep a more calm pacing to the releases, but there were some things in 0.4.2.5 that really needed wider deployment
            
-
            13:10 < Madman2003> 0.4.2.5 is working well for me when it comes to disconnects, but i don't run i2p 24/7(i had quite a few irc disconnects lately) and it's only been a few hours after the release
            
-
            13:10 <@jrandom> as mentioned later on in the email, i dont have a planned date for when the next bugfix release will be, but we shall see
            
-
            13:10 <@jrandom> ah great Madman2003 
            
-
            13:10 <@jrandom> yeah, its definitely too early to tell about 0.4.2.5
            
-
            13:11 < frosk> i used to see periods of high lag on .4, so far none of those with .5, but again, a bit early
            
-
            13:11 < frosk> (i'm talking about irc lag, of course)
            
-
            13:11 <@jrandom> the dns bug fixed could manifest itself in large numbers of peers running older releases failing at once, so the sooner people upgrade, the better
            
-
            13:12 <@duck> is that related with the failures on those manually entering a hostname?
            
-
            13:12 <@jrandom> yep
            
-
            13:12 < dm> how useless is the windows system tray I2P icon!?!?
            
-
            13:12 <@duck> ah, so that is why config.jsp is still friendly
            
-
            13:13 < Madman2003> anyone have a clue why some still run pre 0.4.2.4 routers?(it's been out a while)
            
-
            13:13 <@jrandom> dm: its more of a placeholder right now, plus a status icon saying "i2p is running"
            
-
            13:13 < dm> They have a life? :)
            
-
            13:13  * jrandom should resent that...
            
-
            13:14 < redzog> is there a way to do soft-restarts from the command line?
            
-
            13:14 <@jrandom> redzog: unfortunately not
            
-
            13:14 < redzog> hmm, pity
            
-
            13:14 <@jrandom> other than with wget, perhaps
            
-
            13:14 < redzog> would make it easier to do automatic updates
            
-
            13:14 <+detonate> i2prouter stop && i2prouter start :)
            
-
            13:14 <@jrandom> no, nm, wget wouldnt work either
            
-
            13:14 <@jrandom> (as the form requires interaction)
            
-
            13:14 < Madman2003> i generally update trough cvs several times in between releases(at best once a day), only takes a few minutes
            
-
            13:15 < redzog> lwp::simple could manage it
            
-
            13:15 < redzog> just a POST
            
-
            13:15 <@jrandom> redzog: support for that would be pretty cool
            
-
            13:15 < redzog> I'll try to whip something up
            
-
            13:15 <@jrandom> well, its more than just a post, you need to read the form presented to you then post those fields back
            
-
            13:16 <+detonate> eventually releases will be further spaced though.. right?
            
-
            13:16 <@jrandom> (there's a hidden flag to prevent people from doing things like <img src="/configservice.jsp?action=restart">
            
-
            13:16 < redzog> heh, right
            
-
            13:16 <@jrandom> right detonate, t'wasn't planned to be this rapid, once a week at most
            
-
            13:16 < redzog> does the nonce value change?
            
-
            13:17 <@jrandom> if it didn't, it wouldnt be a nonce ;)
            
-
            13:17 < redzog> hmm, seems so
            
-
            13:17 < redzog> well, between sessions, between pageloads... ;)
            
-
            13:17 < redzog> pageloads it is
            
-
            13:17 <@jrandom> right
            
-
            13:17 <@jrandom> ok, anyone have anything else wrt 0.4.2.4/0.4.2.5?
            
-
            13:18 <@jrandom> i'm sur there'll be more discussion later after we've burnt in the new release more
            
-
            13:18 < dm> oh, is this a meeting?
            
-
            13:18 <+detonate> starting up seems to be a lot less smooth
            
-
            13:18 <+detonate> than 2.3
            
-
            13:18 <@jrandom> oh?  in what way detonate - cpu, lag, memory, time?
            
-
            13:19 <+detonate> the list of peers takes forever to populate
            
-
            13:19 <+detonate> and i get a huge number of shitlisted peers
            
-
            13:19 <+detonate> also the i2ptunnel stuff sometimes hangs, but generally seems to take at least 2x as long to actually start up
            
-
            13:19 <+detonate> once it's started things smooth out
            
-
            13:19 <+detonate> it's odd
            
-
            13:19 <@jrandom> hmm, what does it list for the cause on /logs.jsp#connectionlogs ?
            
-
            13:20 < ant> <BS314159> I just did a graceful restart into 0.4.2.5. It took 120s to have Local Destinations
            
-
            13:20 < ant> <BS314159> seems good
            
-
            13:20 <@jrandom> cool BS314159 - thats pretty much the bare minimum, as we don't start i2ptunnel until 2 minutes after startup :)
            
-
            13:20 <+detonate> there's nothing out of the ordinary
            
-
            13:20 <+detonate> a shutdown exception
            
-
            13:21 <+detonate> but i think i caused that
            
-
            13:21 < mule> i have pulled over 300M through fcp for a movie with the last release. never been that good before. top rates beyond 40k. great work.
            
-
            13:21 <@jrandom> wow, nice mule!
            
-
            13:21 < mule> however i still have serious trouble with recovering from an IP change
            
-
            13:21 <@jrandom> detonate: hmm, ok, i'd love to debug this further after the meeting or another time you have available
            
-
            13:22 <+detonate> yeah
            
-
            13:22 <+detonate> ok
            
-
            13:22 < dm> tunnel lag: 364ms. What the fuck is going on , the tunnel lag is dropping 100-200ms on each release!
            
-
            13:22 <@jrandom> ah mule, ok
            
-
            13:22 <@jrandom> i've got an idea for how we could deal with those hung tcp connections - just toss on a 5m keepalive
            
-
            13:23 <@jrandom> heh dm, dont worry, it'll get back up again ;)
            
-
            13:23 < frosk> wow, i only have 261ms here :)
            
-
            13:24 <@jrandom> ok, if there's nothing else, lets jump on to 2) 0.5 strategy
            
-
            13:24 < dm> That can't be right...
            
-
            13:25 <+ugha2p> Looks like I'm late for the meeting again.
            
-
            13:26 <@jrandom> there's still a lot of work to be done with 0.5, but a broad outline of the process was included in that email
            
-
            13:26  * jrandom sends ugha2p to the principal's office
            
-
            13:27 <@jrandom> there are still some details left to be worked out on the tunnel pooling and creation, but i think we've got a few different offerings that will meet the needs of various user bases
            
-
            13:28 <@jrandom> there'll be some good ol' fashioned documentation posted once most of the kinks in the design are hammered out for y'all's review
            
-
            13:28 <@jrandom> (currently its taking up ~8 pages in the notebook, should compress well though)
            
-
            13:29 < kaji> has the meeting started yet?
            
-
            13:29 <@jrandom> but another one of the tasks listed for 0.5 is "deal with the bandwidth needs of the network", and i have no idea how to plan for that, so we'll play that by ear
            
-
            13:29 <@jrandom> yes kaji, we're on 2) 0.5 strategy
            
-
            13:30 <@jrandom> well, thats all i have to say about that at the moment, unless anyone has any questions/comments/concerns?
            
-
            13:31 <+ugha2p> Wow, most of the routers have already upgraded.
            
-
            13:31 <+detonate> is filtering http traffic to strip out javascript/etc in the roadmap?
            
-
            13:31 <+detonate> for 0.5
            
-
            13:31 <+ugha2p> detonate: No.
            
-
            13:31 <@jrandom> detonate: 0.6
            
-
            13:31 < ant> <cat-a-puss> WRT bandwidth, should we enable probabilistic tunnel length, and/or local biased tunnels, for bittorrent as in general BT users have a weaker threat modle?
            
-
            13:32 <@jrandom> cat-a-puss: yes, definitely.  thats one of the big parts of the 0.5 release
            
-
            13:32 <+ugha2p> detonate: Unless you implement it first. ;)
            
-
            13:32 <+detonate> i was thinking about it
            
-
            13:33 < ant> <cat-a-puss> will html filtering be conducted in a seperate process?
            
-
            13:33 <@jrandom> i think michelle is looking at that too, so if you two wanted to work together (michelle is learning java) that'd rule
            
-
            13:33 <+detonate> ok
            
-
            13:33 <@jrandom> cat-a-puss: i know not.  
            
-
            13:34 <+ugha2p> cat-a-puss: Why should it?
            
-
            13:35 < ant> <cat-a-puss> (I ask because I was thinking of making a proxy that ran all incomming brouser traffic through clamav) That is GPLed so if we could include that in the filter, it would probably be good.
            
-
            13:35 <@jrandom> cool cat-a-puss!
            
-
            13:35 <+ugha2p> Some people already use Privoxy for I2P.
            
-
            13:36 < bens> in general, I'm anti-including-stuff
            
-
            13:36 < susi23> I would rather see people configuring their browsers right than promising to protect them from malicious code.
            
-
            13:36 <@jrandom> susi23: no one configures their browser properly
            
-
            13:36 <@jrandom> especially not joe sixpack
            
-
            13:37 < frosk> one can wonder if Joe is even able to set a proxy for his browser
            
-
            13:37 <@jrandom> my personal view is that something cgi-proxy like would be ideal
            
-
            13:37 <@jrandom> exactly frosk
            
-
            13:37 <@jrandom> with a cgi-proxy like interface (filtering according to their preferences, safe by default), even a drooling moron could use it
            
-
            13:38 < bens> I suppose I2P needs multiple versions for multiple markets even more than MS Office
            
-
            13:38 <@jrandom> 'tis why we have small components and push this stuff out of the router bens ;)  
            
-
            13:38 < Ragnarok> a proxy auto config file would help
            
-
            13:39 <@jrandom> Ragnarok: we have one, but there are still dangerous things that can be done with it
            
-
            13:39 < frosk> maybe a specialized i2p browser even (if someone is drowning in free time ;)
            
-
            13:39 < susi23> ragnarok: that one? http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/proxyscript/i2pProxy.pac
            
-
            13:39 <@jrandom> frosk: on the specialized i2p OS and hardware too, i suppose
            
-
            13:40 < frosk> hehe, perfect
            
-
            13:40 < Ragnarok> that's not in the install, though
            
-
            13:40  * jrandom implements those in the specialized i2p universe
            
-
            13:40 < susi23> . o O ( perhaps we should try to find a dedicated i2p planet too )
            
-
            13:40 < susi23> . o O ( damn, too slow )
            
-
            13:40 < mule> ok, we'll sell the hardware :)
            
-
            13:40 < frosk> you know what they say, to create something from scratch, first create the universe
            
-
            13:41 <@jrandom> w00t, now all we need are some investors..
            
-
            13:41 < bens> seriously, a firefox autoconfigurator might be reasonable
            
-
            13:41 <@jrandom> bens: the .pac susi linked to above should do the trick
            
-
            13:41 < bens> not just for proxy; also for the security settings, homepage, etc.
            
-
            13:41 <@jrandom> we can ship that with the install too, but its insufficient for people who need anonymity (and are not ubergeeks already)
            
-
            13:42 <@jrandom> hmm, perhaps that sort of thing could go into cervantes' i2p xul app
            
-
            13:43 <@jrandom> but thats getting further off topic from the 2) 0.5 strategy
            
-
            13:43 <@jrandom> anyone else have anything for that, or shall we move on to 3) naming?
            
-
            13:44 -!- Irssi: #i2p: Total of 40 nicks [2 ops, 0 halfops, 6 voices, 32 normal]
            
-
            13:44 <@jrandom> consider us moved
            
-
            13:44 <@jrandom> ok, aparently i kind of jumped the gun w/ the 2.0.1 ref of addressbook - Ragnarok, want to give us an update?
            
-
            13:44 <+ugha2p> jrandom: Can we expect the dates on the roadmap to be correct?
            
-
            13:45 <@jrandom> ugha2p: they currently reflect my best estimate
            
-
            13:45 <+ugha2p> jrandom: Ok, right.
            
-
            13:45 < Ragnarok> it's released now
            
-
            13:45 <@jrandom> w00t
            
-
            13:45 < Ragnarok> check ragnarok.i2p
            
-
            13:45 < Ragnarok> I wasn't planning on releasing it yet, but jrandom forced my hand :)
            
-
            13:46 <@jrandom> hehe
            
-
            13:46 <+ugha2p> Ragnarok: Btw, you're missing a link from the homepage. :)
            
-
            13:46 < Ragnarok> it's just a few bug fixes, nothing major, but it should deal better with some corner cases
            
-
            13:46 <@jrandom> its on the top right ugha2p 
            
-
            13:47 < Ragnarok> ugha2p: it's on the sidebar
            
-
            13:47 < Ragnarok> I'll add links to the post as well, though :)
            
-
            13:47 < mule2> "that'll be the day when i die". daily IP change to set the clock after.
            
-
            13:48 < Ragnarok> anyway, if everyone could try it out, that'd be nice.  Bug reports are always appreciated
            
-
            13:48 <+ugha2p> Ragnarok: Oh, that sidebar is seriously fucked in Opera.
            
-
            13:48 < mule2> Lease expired 12773d ago
            
-
            13:49 <+ugha2p> Ragnarok: Well, not really fucked, but just located at the end of the page.
            
-
            13:49 <@jrandom> cool Ragnarok, thanks
            
-
            13:49 < Ragnarok> your window's probably not wide enough
            
-
            13:49 <+ugha2p> Ragnarok: Right, but it should work with any window size.
            
-
            13:50 <+ugha2p> So you might want to fix it in the future. :)
            
-
            13:50 < Ragnarok> ugha2p: should is an interesting choice of words :)
            
-
            13:50 < Frooze> ah, wrong in mozilla 1.7 too.  my window is small though.
            
-
            13:50 <+ugha2p> Why's that?
            
-
            13:50 < Frooze> thanks ragnarok.  cool stuff.
            
-
            13:51 < Ragnarok> I may fix it in the future, but it's really low on my priorities
            
-
            13:51  * jrandom prefers addressbook updates to html fixes
            
-
            13:52 < Ragnarok> anyhoo, any questions?
            
-
            13:53 < frosk> thanks for addressbook, Ragnarok, sounds very useful
            
-
            13:54 <+ugha2p> Is the documented way of loading addressbook the only way, or are there any less intrusive ones?
            
-
            13:54 < kaji> i just installed it, it rocks
            
-
            13:54 < Ragnarok> you can start it by hand using "java -jar addresbook.jar <path to i2p/addressbook>"
            
-
            13:54 < Ragnarok> thank you :)
            
-
            13:55 < kaji> oh, and i dled version 2.0.0 is there an update someware?
            
-
            13:55 < Ragnarok> ok, I fixed the column, it was just a stupid mix of absolute and realitive sizes
            
-
            13:56 < Ragnarok> yep, there's 2.0.1 up now on ragnarok.i2p
            
-
            13:57 <+ugha2p> I'm getting "Failed to load Main-Class manifest attribute from" now, but never mind, I'll do a restart later.
            
-
            13:57 < Ragnarok> whoops
            
-
            13:58 < Ragnarok> that's my bad
            
-
            13:58 < Ragnarok> I'll try to fix that soon
            
-
            13:58 <+ugha2p> Ah, okay. :)
            
-
            13:58 < Ragnarok> there will also be an easy to install .war version soon
            
-
            13:59 < dm> jrandom: you are a machine
            
-
            14:00 <@jrandom> wikked, thanks Ragnarok 
            
-
            14:00 <@jrandom> susi23: ping?
            
-
            14:00 < susi23> 1200ms
            
-
            14:01 <@jrandom> !thwap
            
-
            14:01 <@jrandom> anyway, wanna give us a rundown on whats up w/ susidns?
            
-
            14:01 <@jrandom> or should that wait for later?
            
-
            14:01 < susi23> do we have time for a more general discussion about naming stuff?
            
-
            14:02 < susi23> what features we want in the future?
            
-
            14:03 <@jrandom> some of my thoughts are posted up on http://dev.i2p.net/pipermail/i2p/2004-February/000135.html
            
-
            14:03 <@jrandom> (for what general features)
            
-
            14:04 <@jrandom> i think the hardest thing will be weaning people off globally unique human readable names, but with some good interfaces it should be doable
            
-
            14:04 < Ragnarok> implementing the data structures you outlined in xml is one of my next goals
            
-
            14:04 < susi23> ok, there is a small writing about attributes at http://susi.i2p/removablekeys.html
            
-
            14:05 < ant> <Jnymo> wow.. pretty crowded in here tonight
            
-
            14:05 < bens> ragnarok: have you checked out YAML? Might be easier
            
-
            14:05 <+ugha2p> Jnymo: Yeah, we're trying to hold a meeting here.
            
-
            14:05 < Ragnarok> YAML's name is far too apt
            
-
            14:05 <@jrandom> cool susi23, though i think we'll definitely want to migrate away from the plain hosts.txt format
            
-
            14:05 < ant> <Quadn-werk> addition of a command line graceful restart?
            
-
            14:06 < ant> <Jnymo> ugha2p: ah
            
-
            14:06 < susi23> are there any ideas how to keep names unique in the long run?
            
-
            14:06 <@jrandom> one of the important parts of the data to be managed in the naming service is for an entry to be signed, requiring some hard structure (or careful xml)
            
-
            14:07 <@jrandom> i dont believe in globally unique human, human readable, and secure names.
            
-
            14:07 <@jrandom> (i bundle centralized & secure together)
            
-
            14:07 <@jrandom> susi23: have you seen http://zooko.com/distnames.html ?
            
-
            14:07 < Ragnarok> I think using an addressbook like system, the names will end up being mostly unique, since it's in the interest of the person claiming a name not to choose one that's already in use
            
-
            14:08 <@jrandom> Ragnarok: we'll see.  perhaps
            
-
            14:08 < susi23> i'll check this out
            
-
            14:08 < bens> I suspect trusted authorities will emerge
            
-
            14:08 < Ragnarok> well, there already is one
            
-
            14:08 < frosk> hosts.txt? :)
            
-
            14:09 < Ragnarok> jrandom's, yeah
            
-
            14:09 <@jrandom> or if not trusted authorities, names that include the path to uniquely identify it
            
-
            14:09 <@jrandom> (e.g. "the site orion.i2p calls 'frosk.i2p'")
            
-
            14:10 <@jrandom> Derek Eddington had some posts along those lines in september - http://dev.i2p.net/pipermail/i2p/2004-September/000432.html
            
-
            14:10 < bens> frosk.orion.i2p
            
-
            14:10 <@jrandom> smtp.frosk.ns.orion.i2p
            
-
            14:11  * jrandom starts building uucp bang paths
            
-
            14:11 < frosk> hah
            
-
            14:12 < susi23> ok, what now... how about a "naming roadmap"? :)
            
-
            14:12 < ant> <Jnymo> you guys have swayed me away from an absolute distributed dns for i2p.. somewhat.. but ducks ideas started me thinking that a trust system might work.. like, a lookup could bring back a list of sites/files, and each could be listed with the amount of trust that the network gives it
            
-
            14:12 < susi23> once we agreed what to do
            
-
            14:12 <@jrandom> thats a good idea susi23, wanna write one up?
            
-
            14:13 <@jrandom> trusting other people's trust has potential, but needs to be done very carefully
            
-
            14:13 < susi23> I could do this, but I still have no idea WHAT we want to do. There are some decisions to make.
            
-
            14:14 <@jrandom> (aka only according to the terms that you trust the peers along the chain to the trust author)
            
-
            14:14 < modulus> there is or there should not be a "network trust" of a site, trust has to be user-centric always
            
-
            14:14 <@jrandom> susi23: roadmap step 1: decide among $featureset
            
-
            14:14 < susi23> Or at least we have to develop all ideas into a more precise concept.
            
-
            14:14 < ant> <Jnymo> well, if it was explicitly simple.. like, if files i2p listed how many sites linked to siteinquestion.i2p
            
-
            14:15 < Ragnarok> ok, the I've updated the addressbook package with an executable jar.
            
-
            14:15 < ant> <Jnymo> er, files.i2p
            
-
            14:15 <@jrandom> jnymo: that turns into a centralized authority - files.i2p
            
-
            14:15 < modulus> not to say that you could poison the pool of links by establishing a shitload of sites.
            
-
            14:16 < modulus> googlebombing on i2p
            
-
            14:16 < ant> <Jnymo> true.. but files i2p could be decentralized
            
-
            14:16 < susi23> ok, how about collection ideas/information/concepts until, lets say january
            
-
            14:16 < orion> 'lo all. I see naming is on the table.. *again* :)
            
-
            14:16 < susi23> then comes the decision phase, ok?
            
-
            14:16 <@jrandom> sounds good - will you be the point of contact to gather that together?
            
-
            14:16 < Ragnarok> sure
            
-
            14:16 < modulus> doesn't matter if the trust aggregate is descentralized, trust has to emanate from the user. anything else can be poisoned imo.
            
-
            14:17 < susi23> can't we take the mailinglist for this?
            
-
            14:17 < bob> or perhaps ugha's wiki?
            
-
            14:17 < ant> <Jnymo> agreed.. but what how to do that? put a little trust meter bar at the top of the web browser?
            
-
            14:18 <@jrandom> the wiki would be good, we can gather links to all the previous discussions there
            
-
            14:18 < modulus> jnyo: probably the most feasible solution is to bind to the first name encountered or something.
            
-
            14:18 < dm> let's all give a hand of applause to jrandom for his wonderful project management
            
-
            14:18 < susi23> fine
            
-
            14:18 < modulus> but there are more ways than sausages.
            
-
            14:19 < susi23> url to the wiki? (for the records)
            
-
            14:19 < ant> * Jnymo claps
            
-
            14:19 <@jrandom> ugha.i2p
            
-
            14:19  * dm claps
            
-
            14:19 < susi23> ok
            
-
            14:19 < susi23> then I'm done and ping jrandom back ;)
            
-
            14:20 < ant> <Jnymo> modulus: so, if i refer a link to someone else, i'm refering them to the site i first binded to.. that might work.. 
            
-
            14:20 <+ugha2p> Looks like jrandom has ping timeouted.
            
-
            14:20 <@jrandom> ok cool, anything else on nami^W nm, no more on naming.  on to the wiki
            
-
            14:20 < modulus> anyway, if you're linking you'll probably want to put an absolute path in the link, not just a name
            
-
            14:21 <@jrandom> moving forward to 4) eepsite roundup
            
-
            14:21 < dm> dm.i2p is up and running
            
-
            14:21 <@jrandom> cool
            
-
            14:22 <@jrandom> ok, i dont really have much to add beyond whats mentioned in the mail
            
-
            14:22 < bob> nice to see an influx of sites!  all speedy to access as well!
            
-
            14:22 <@jrandom> aye, agreed bob
            
-
            14:22 < bob> orion, thanks for your work.. I use your site daily.
            
-
            14:22  * jrandom too, the 'last updated' is especially helpful
            
-
            14:23 < bob> dm: :-)
            
-
            14:24 <@jrandom> ok, if there's nothing more on that, we can jump to 5) ???
            
-
            14:24 <@jrandom> is there anything else people want to bring up for the meeting?
            
-
            14:24 < ant> <Jnymo> hows the net status?
            
-
            14:24 < ant> <Jnymo> wrt 4.2.5?
            
-
            14:25 <@jrandom> its looking good, but the release is only a few hours old, so too soon to tell
            
-
            14:25 < ant> <Jnymo> oh, heh
            
-
            14:25 < ant> <Jnymo> any fusenet news?
            
-
            14:26 <@jrandom> (http://piespy.i2p/i2p/i2p-current.png heh)
            
-
            14:26 < frosk> my work on i2pcontent has been largely put aside for some weeks, but the latest version of the document can be read at http://frosk.i2p/i2pcontent.html . if anyone is interested, do read, and do comment harshly if needs be (om irc when i'm not /away or mail to frosk@mail.i2p)
            
-
            14:26 < frosk> i2pcontent/fusenet/anything ;)
            
-
            14:26 < ant> <Jnymo> wordicus
            
-
            14:28 <@jrandom> ok, if there's nothing else...
            
-
            14:28 < mule2> tons of applause for all the excellent contributions
            
-
            14:29 <@jrandom> aye, y'all are doing some kickass shit
            
-
            14:29 < frosk> you too, jrandom :)
            
-
            14:29 < orion> word.
            
-
            14:29 < orion> yes, very much so, you too jrandom.
            
-
            14:29 < scintilla> hear hear!
            
-
            14:29 < ant> <Jnymo> yea, i noticed on the site, theres less info on how to help out
            
-
            14:29 <@jrandom> sometimes kickass, sometimes ass kicked ;)
            
-
            14:29 < orion> HIP HIP
            
-
            14:30 < ant> <Jnymo> HORRAY
            
-
            14:30  * orion smiles
            
-
            14:30 < Frooze> downloaded eclipse today, to learn java over holiday, because y'all are so impressive.
            
-
            14:30 <@jrandom> jnymo: many of the small easy-to-accomplish tasks have been done
            
-
            14:30 <@jrandom> ooh wikked Frooze 
            
-
            14:31 < Frooze> so, trouble on horizon.  heh
            
-
            14:31 <@jrandom> jnymo: i really should collect some more of them though and post 'em
            
-
            14:31 < ant> <Jnymo> jrandom: You still looking for someone to help out on alexandria.i2p?
            
-
            14:31 <@jrandom> (take cover arizona!)
            
-
            14:31  * jrandom is not involved in alexandria, but yes, i believe they are still looking for a librarian
            
-
            14:31 < ant> <Jnymo> learn to swim, folks ;)
            
-
            14:31  * orion loves pump up the volume references. Vague though they may be.
            
-
            14:31 <@duck> yes we do
            
-
            14:31 <@jrandom> :)
            
-
            14:31 < Ragnarok> jrandom: where is the war actually supposed to go?
            
-
            14:31 <@jrandom> (orion++)
            
-
            14:32 <@jrandom> Ragnarok: i2p/webapps/addressbook.war
            
-
            14:32 <@jrandom> (then restart the router)
            
-
            14:32 < ant> <Jnymo> duck, you talkint to me?
            
-
            14:32 < Ragnarok> cool.  I shall commence testing
            
-
            14:32 <@jrandom> r0x0r
            
-
            14:32 < ant> <Jnymo> duck: is alexandria on your site?
            
-
            14:33 <@duck> duck.i2p/alexandria/
            
-
            14:33 < ant> <Jnymo> word
            
-
            14:34 <@jrandom> ok, if thats all, we can slide out of here @ the 90m mark..
            
-
            14:34  * jrandom winds up
            
-
            14:34  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting122.html b/www.i2p2/pages/meeting122.html
deleted file mode 100644
index 1a8eaae3..00000000
--- a/www.i2p2/pages/meeting122.html
+++ /dev/null
@@ -1,201 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 122{% endblock %}
-{% block content %}
            I2P dev meeting, December 28, 2004
            
-
            
-
            13:06 <@jrandom> 0) hi
            
-
            13:06 <@jrandom> 1) 0.4.2.5
            
-
            13:06 <@jrandom> 2) 0.5
            
-
            13:06 <@jrandom> 3) ???
            
-
            13:06 <@jrandom> 0) hi
            
-
            13:06  * jrandom waves
            
-
            13:06 <+postman> *wave*
            
-
            13:06 < ant> <jnymo> hello
            
-
            13:06 <@jrandom> brief status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html
            
-
            13:07 <@jrandom> jumping in to 1) 0.4.2.5
            
-
            13:07 <@jrandom> as mentioned, things are pretty much working
            
-
            13:08 <+postman> yeah, quite impressive
            
-
            13:08 <+postman> no more lease timouts on my systems at all
            
-
            13:08 <@jrandom> a lot of people have seen what you've seen jnymo, with 0 participating tunnels, largely in part to the increased efficiency & peer selection (where we now know to leech off postman's machine ;)
            
-
            13:08 < ant> <jnymo> me too
            
-
            13:08 <@jrandom> nice
            
-
            13:08 < ant> <jnymo> and eepsites are snappy
            
-
            13:09 <+postman> :)
            
-
            13:09 < ant> <jnymo> thanks postman :)
            
-
            13:09 <+postman> totsl bw is 29kb / 30.1kb/s
            
-
            13:09 < frosk> everybody feels less loved, but in reality the love is just being put more efficiently to work
            
-
            13:10 < ant> <jnymo> wow
            
-
            13:10 <@jrandom> b1tchin postman 
            
-
            13:10 < mule2> i don't think that is the preferred ideal. we'd better have some traffic through all nodes
            
-
            13:10 < ant> <jnymo> i could handle that if people just loved me :(
            
-
            13:10 <+postman> yep
            
-
            13:10 < mule2> as kind of cover traffic
            
-
            13:10 <@jrandom> mule2: its a matter of our load being much less than our network capacity
            
-
            13:11 <@jrandom> i dont think we'll be able to keep the capacity greater than the load for long
            
-
            13:11 < ant> <jnymo> mule2, postman is also act as i mixer.. so its hard to tell where you packets are going after they go in
            
-
            13:11 <@jrandom> so i'm not too worried about not pushing any data through slower peers
            
-
            13:12 < mule2> probably less perfect optimization would be good for anonymity
            
-
            13:12 <@jrandom> otoh, it also gives incentive for more people to (implement &) use i2pcontent, so they can mirror as well as gain cover traffic ;)
            
-
            13:12 < jdot__> i it a security issue that one router handles all(ish) tunnels?
            
-
            13:13 <@jrandom> mule2: lets first get it as good as we can get it, then we can discuss proactively making it worse
            
-
            13:13 <@jrandom> jdot__: we don't have one router handling all of the traffic, but we are seeing the grouping of routers who are on very fast connections (colo, etc) handling more than dialup/dsl/cable users
            
-
            13:14 <@jrandom> plus the reduced tunnel failures means we're shifting & exploring less
            
-
            13:14 < mule2> perhaps some traffic distribution would be possible, as long as we are far from the routers limits
            
-
            13:14 <@jrandom> right, probabalistic tunnel rejection is in the router and can be enabled based on the router's bandwidth limits
            
-
            13:15 < ant> <jnymo> yea, but such high throughput on postman's node makes it harder to analyze his node.. so it might be safer to send through him than for all nodes to do one KBs..
            
-
            13:15 <@jrandom> (but if postman doesnt set any limits, we can't reject based on a % of that ;)
            
-
            13:15 < ant> <jnymo> groupings of faster nodes cause something of a mix cascade structure, no?
            
-
            13:15 <@jrandom> aye, that is one way to look at it
            
-
            13:15 < lektriK> can I close the Start I2P window?
            
-
            13:15  * postman is very sorry NOT to restrict his bandwidth
            
-
            13:16 <@jrandom> lektriK: unfortunately, not really, unless you start i2p as a service (See http://localhost:7657/configservice.jsp)
            
-
            13:16 <@jrandom> heh postman dont worry, we'll back off your router if/when we reach your router's capacity
            
-
            13:17 < lektriK> Ok, it sais service started
            
-
            13:17 < lektriK> can I close it now?
            
-
            13:17 <@jrandom> lektriK: no/yes - you can shut down your router then start it again via start->run->"net start i2p"
            
-
            13:18 < mule2> as it is, a few very big routers could handle all the tunnels, removing all cover traffic from all other routers. but lets continue with that after the meeting.
            
-
            13:18 < mule2> don't want to complain about the network behaving to good :)
            
-
            13:18 <@jrandom> hehe
            
-
            13:20 <@jrandom> some further exploration will occur with 0.5, though there are anonymity related issues with spreading too far.  there'll be further details to be worked through on that for 0.5 though (and in the doc which might be ready next week as a first draft)
            
-
            13:21 <@jrandom> anyway, anyone else have something to bring up for 0.4.2.5?  
            
-
            13:21 <@jrandom> or shall we move on briefly to 2) 0.5?
            
-
            13:21 <+postman> move
            
-
            13:21 < ant> <jnymo> very stable... move
            
-
            13:21 <@jrandom> consider us moved
            
-
            13:22 <@jrandom> 2) 0.5
            
-
            13:22 <@jrandom> yeah.  still work in progress.  more info when its ready.
            
-
            13:22 < ant> <Quadn-werk> Sir Arthur C. Clarke is alive :P
            
-
            13:22 < ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1
            
-
            13:22 < ant> <jnymo> .5 is exciting
            
-
            13:22 <@jrandom> ok, thats all i have to say on that - anyone have any questions / things to discuss about it?
            
-
            13:23 <@jrandom> aye, there are definitely some important revamping going on, based on what we've learned over the last 16 months
            
-
            13:23 <@jrandom> (or shit, 18)
            
-
            13:23 <+postman> jrandom: so 0.5 will emnploy a new tunnel management system mostly?
            
-
            13:23 < ant> <Quadn-werk> arg, i hope i didnt interrupt the meeting :/
            
-
            13:23 <+postman> wow
            
-
            13:23 < ant> <Quadn-werk> sorry heh
            
-
            13:23 < ant> <jnymo> heh. i had a suggestion
            
-
            13:24 <@jrandom> yeah postman, new management, pooling, and building
            
-
            13:24 <+postman> quadn: look what you've done - your paste caused a netsplit :)
            
-
            13:24 <@jrandom> you bastard!
            
-
            13:24 < ant> <Quadn-werk> !
            
-
            13:24 <@jrandom> sup jnymo?
            
-
            13:24 <+postman> jrandom: will every tunnel be a separate local destination still?
            
-
            13:25 <@jrandom> huzzawuzzah?
            
-
            13:25 <@jrandom> there won't be any change to i2ptunnel in 0.5
            
-
            13:25 <+postman> jrandom: ok
            
-
            13:25 <@jrandom> (at least, i dont plan on any)
            
-
            13:26 < mule> postman mounting an intersection attack?
            
-
            13:26 < ant> <jnymo> for those who aren't getting /any/ bandwidth usage..  how bout letting routers build tunnels with them in it.. like ABCABCA
            
-
            13:26 <+postman> mule: no, it was quadn's fault :)
            
-
            13:26 < ant> <jnymo> and that would be a dummy tunnel
            
-
            13:27 <@jrandom> jnymo: advertising a router as saying "hey i have excess bandwidth, use me" is a dangerous game
            
-
            13:27 <+postman> jrandom: what issues will then be addressed by the redesign  ( in a nutshell )
            
-
            13:27 < ant> <jnymo> not sure i meant that, jrandom
            
-
            13:27 <@jrandom> but what it looks like now is that we'll have two sets of tunnels - the normal ones, and then exploratory ones, where the later are built from randomly selected non-failing peers
            
-
            13:28 < ant> <jnymo> jrandom: i meant creating a dummy tunnel, and putting my self in the middle of that tunnel just to simulate some traffic
            
-
            13:29 <@jrandom> postman: making it much harder to correllate peers in a tunnel, allowing clients to effectively choose their outbound tunnel length, and providing the options necessary for addressing the predecessor attack (with various tradeoffs)
            
-
            13:29 <@jrandom> (oh, and improving performance by getting rid of a lot of modPow calls)
            
-
            13:29 <+postman> ok thanks
            
-
            13:29 < ant> <jnymo> postman: and per hop tunnel ids is a big one
            
-
            13:30 <+postman> modpow?
            
-
            13:30 <@jrandom> ah jnymo.  yeah, there's a lot of potential for various chaff traffic generation
            
-
            13:30 < ant> <jnymo> that way, no two non-neighboring nodes can know there on the same tunnel, postman
            
-
            13:30 <@jrandom> postman: modular exponentiation, heavy cpu usage & memory waste
            
-
            13:31 < ant> <jnymo> jrandom: k cool
            
-
            13:31 <+postman> k
            
-
            13:31 < scintilla> jrandom, wrt to letting clients choose tunnel length: will there be anything in place to keep ppl from cranking it up to 99 (or whatever)?
            
-
            13:31 < ant> <jnymo> cpu power
            
-
            13:32 <@jrandom> when necessary we can add hashcash, but excessively long tunnels will just end up failing anyway
            
-
            13:32 < scintilla> ah good point
            
-
            13:32 <@jrandom> we could even add in some trickery - requiring that a tunnel have a valid tunnel message pumped through it within 60s of creation for it to be 'valid'
            
-
            13:33 <@jrandom> (so if the tunnel was 20 hops long, it'd take them too long to build all those hops)
            
-
            13:33 < scintilla> that's a great idea - that'll keep any such ridiculousness from lingering for very long
            
-
            13:33 <@jrandom> but thats all vs the hackers.  normal users will just use the exposed interface
            
-
            13:34 < ant> <jnymo> right, which you'll cap off somewhere right?
            
-
            13:34 < ant> <jnymo> we'll get higher than the maximum 2 as it is now, right?
            
-
            13:34 <@jrandom> right, like the # hops drop down on /configclients.jsp or /i2ptunnel/edit.jsp
            
-
            13:35 <@jrandom> oh i thought the max was 3 now?  ok, but yeah, higher than 2 will be available
            
-
            13:35 < ant> <jnymo> 3 tunnels, 2 hops
            
-
            13:35 <@jrandom> ah 'k
            
-
            13:35 <@jrandom> yeah, 0.5 will add in some important new tweaks, such as whether to randomize those lengths, as well as how much to randomize, etc
            
-
            13:36 < frosk> the max is indeed 3
            
-
            13:36 < ant> <jnymo> hmm
            
-
            13:37 <@jrandom> ah its 3 on /configclients 2 on i2ptunnel
            
-
            13:37 < frosk> is 0.5 still on track for january?
            
-
            13:37 < ant> <jnymo> ah
            
-
            13:37 <@jrandom> yeah frosk
            
-
            13:37 < frosk> goodie
            
-
            13:37 <@jrandom> i wont dawdle too much longer on the streaming lib, i promise ;)
            
-
            13:37 < frosk> it just sounds like a lot of work :)
            
-
            13:38 <@jrandom> its actually not so bad, the hard part is getting the algorithms right
            
-
            13:38 <@jrandom> (details schmetails ;)
            
-
            13:39 <+postman> frosk: and it's all on paper already
            
-
            13:39 <+postman> :)
            
-
            13:39 < ant> <jnymo> heh
            
-
            13:39 < frosk> true :)
            
-
            13:39 <@jrandom> mostly yeah ;)
            
-
            13:39 <@jrandom> ok, anyone have anything else for 2) 0.5?
            
-
            13:39 < ant> <jnymo> nada
            
-
            13:39 < frosk> el zilcho
            
-
            13:40 <@jrandom> 'k, swingin on to good old fashioned 3) ???
            
-
            13:40 <@jrandom> hi
            
-
            13:40 <@jrandom> anyone have anything else they want to bring up?
            
-
            13:41 < ant> <jnymo> postman: there arent smtp/pop3 inproxies on i2pmail.org are there?
            
-
            13:41 < cat-a-puss> I am still seeing weird delays on the client end...
            
-
            13:41 <+postman> hrm no
            
-
            13:41 < frosk> this is where i'd hand over the congratulatory bottle of wine for a fine year of development ;)
            
-
            13:41 <+postman> jnymo: POP3 is only available for i2p users
            
-
            13:41 <@jrandom> cat-a-puss: ah i missed those messages when you were around earlier
            
-
            13:41 <+postman> jnymo: there IS a SMTP inproxy as MX for the domain i2pmail.org
            
-
            13:42 <@jrandom> frosk: cheers
            
-
            13:42 < ant> <jnymo> right right.. that's coo'..
            
-
            13:42 < cat-a-puss> Like I can have two local Destinations and when one trys to connect to another there is a delay and it is not CPU bound
            
-
            13:42 < mule> cat-a-puss: do you also hand over the bonus cheque ?
            
-
            13:42  * postman donates a good whiskey 
            
-
            13:42 <@jrandom> cat-a-puss: right, you saw a .5-1.0s delay right?
            
-
            13:42 < cat-a-puss> mule: what?
            
-
            13:42 < cat-a-puss> jrandom: yeah
            
-
            13:43 <@jrandom> cat-a-puss: perfectly normal, part of the deferred syn
            
-
            13:43 < mule> sorry, the comment was from frosk
            
-
            13:43 < ant> * jnymo pulles out that crappy box wine
            
-
            13:43 < mule> frosk: do you also hand over the bonus cheque ?
            
-
            13:43 <@jrandom> (it waits a bit to send the SYN and the related ACK in case there is more data to bundle)
            
-
            13:43 < scintilla> oh fyi, i should be receiving the book with the fortuna algorithm spec in it soon... in the meantime i've been experimenting with trying to gather entropy in java without destroying a machine
            
-
            13:44 <@jrandom> ah kickass
            
-
            13:44 < ant> <jnymo> mmm, someone was wanting to mount some attacks on i2p
            
-
            13:44 < ant> <jnymo> who was that?
            
-
            13:44 <@jrandom> connelly
            
-
            13:44 < cat-a-puss> Is there a way to prevent that, or do I just have to try to avoid short lived connections where I can?
            
-
            13:45 < ant> <jnymo> any word on that, jr?
            
-
            13:45 <@jrandom> cat-a-puss: yeah there are some options you can pass when creating the I2PSocketManager, lemmie pull 'em up
            
-
            13:46 <@jrandom> jnymo: its a long term intersection attack, so after a while he'll have data to help identify what routers particular eepsites are on.  i'm sure he's going to write up some summary data for us once he's got it
            
-
            13:46 < ant> <jnymo> scintalla: what's the fortuna algorithm?
            
-
            13:46 < ant> <jnymo> jrandom: aight
            
-
            13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100
            
-
            13:48 < scintilla> it's a cryptographically secure pseudo-random number generator... something which is absolutely essential for trustworthy encryption
            
-
            13:48 < jdot__> anyone volunteer for that attack yet?
            
-
            13:48 <@jrandom> cat-a-puss: then be sure to flush() after write()ing to the I2PSocket
            
-
            13:48 <@jrandom> jdot__: yeah, he has 7 volutneered sites
            
-
            13:48 < cat-a-puss> jrandom: ok
            
-
            13:49 < ant> <jnymo> wrt the great naming debate.. 
            
-
            13:49 < ant> * jnymo snickers
            
-
            13:49 <@jrandom> oh and i2p.streaming.initialAckDelay=1000
            
-
            13:49 <@jrandom> or even =100
            
-
            13:49  * jrandom flings mud at jnymo
            
-
            13:50 < ant> <jnymo> i actually do work with x500 and my job lets me have free winSevers
            
-
            13:50 < ant> <jnymo> so, perhaps i'll just set up a central DNS for testing purposes in a month or two
            
-
            13:51 <@jrandom> heh, having a centralized naming server hosted on a .mil would be bloody hilarious 
            
-
            13:51 < ant> <jnymo> though hacking i2p addresses into winserver may be non-trivial.. dunno
            
-
            13:51 < ant> <jnymo> heh.. dnsalias is the ticket
            
-
            13:52 <@jrandom> nano has done some really cool work, integrating dnsjava with i2p
            
-
            13:52 < ant> <jnymo> ooooh
            
-
            13:53 <@jrandom> check out nano.i2p for more details
            
-
            13:53 < ant> <jnymo> and no one was going to tell me.. ah, thanks
            
-
            13:53 <@jrandom> but, as mentioned last time, people should post up their thoughts and ideas about naming to the wiki
            
-
            13:54 <@jrandom> ok, anyone else have something to bring up for the meeting?
            
-
            13:55 < ant> <jnymo> nope
            
-
            13:57 <@jrandom> ok in that case
            
-
            13:57  * jrandom winds up
            
-
            13:57  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting123.html b/www.i2p2/pages/meeting123.html
deleted file mode 100644
index 58caea5e..00000000
--- a/www.i2p2/pages/meeting123.html
+++ /dev/null
@@ -1,160 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 123{% endblock %}
-{% block content %}
            I2P dev meeting, January 4, 2005
            
-
            
-
            13:09 <@jrandom> 0) hi
            
-
            13:09 <@jrandom> 1) Net status
            
-
            13:09 <@jrandom> 2) 0.4.2.6
            
-
            13:09 < ant> <DrVince> It says that it can't find tools.jar but doesn't stop
            
-
            13:10 <@jrandom> 3) 0.5
            
-
            13:10 <@jrandom> 4) jabber @ chat.i2p
            
-
            13:10 <@jrandom> 5) ???
            
-
            13:10 <@jrandom> 0) hi
            
-
            13:10  * jrandom waves
            
-
            13:10 < eco> hi
            
-
            13:10 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-January/000541.html
            
-
            13:10 <@jrandom> DrVince: if you can hang around, we can hack through that after the meeting
            
-
            13:10 < ant> <DrVince> Cool
            
-
            13:11 <@jrandom> jumping on into 1) Net status
            
-
            13:11 <@jrandom> (as i'm sure y'all have read the weekly status notes already *cough*)
            
-
            13:11 <@jrandom> basically, the net seems to be working well
            
-
            13:11 <@jrandom> we still do have more irc disconnects than usual though, but not a horrid amount
            
-
            13:12 <@jrandom> hopefully the next release (with the streaming lib improvements) will help out, as will further load balancing off duck's server
            
-
            13:12 <@jrandom> (since remember, every message we send to any irc channel is sent to the irc server and echoed out again several times)
            
-
            13:13 <+protokol> yeah
            
-
            13:13 <@jrandom> a fully distributed chat system would be neat, but i'm not holding my breath.  plus, irc works good enough
            
-
            13:14 <@jrandom> ok, thats all i have wrt 1) net status
            
-
            13:14 <@jrandom> does anyone have anything to add, comment, etc?
            
-
            13:14  * eco has been away for a while (what's new)
            
-
            13:15 < eco> and was happily surprised by the state of things. very good progress
            
-
            13:15 < Myo9> Wasn't the meeting at 10?
            
-
            13:15 < eco> both performance and usability wise
            
-
            13:15 < eco> Myo9 10GMT (general meeting time)
            
-
            13:16 <@jrandom> 9p GMT
            
-
            13:16 <@jrandom> the last year has definitely brought a lot of progress
            
-
            13:17  * eco hands out cookies to all devs and then shuts up
            
-
            13:17 <@jrandom> *munch*
            
-
            13:17 <@jrandom> ok, jumping on to 2) 0.4.2.6
            
-
            13:18 <@jrandom> new release coming with bugfixes, improvements, and the addressbook bundled in
            
-
            13:18 <@jrandom> i dont know exactly when it'll be out, maybe end of the week
            
-
            13:18 <@jrandom> it'll be announced on the list and in the channels, of course
            
-
            13:19 <@jrandom> thats all i have to say on that - anyone have any questions/comments/concerns wrt 0.4.2.6?
            
-
            13:19  * eco recalls someone mentioning Debian packages
            
-
            13:20 <@jrandom> os/distro-specific packaging is probably premature at the moment
            
-
            13:20 < eco> Burton is willing to give that a try, but that won't be this week i guess
            
-
            13:20 <@jrandom> ah cool, i hadn't heard that
            
-
            13:21 < eco> agree, though it would be handy
            
-
            13:21 <+protokol> hold on, im pretty high
            
-
            13:21 <+protokol> oops
            
-
            13:21 <+protokol> that was supposed to be a PM
            
-
            13:21 <@jrandom> distro-specific packaging will be nice, but we probably need to have the auto-updater in place for that to be viable
            
-
            13:21 <+protokol> i can look into making an ebuild
            
-
            13:21 <@jrandom> protokol: if you're nice, i'll cut that out of the logs ;)
            
-
            13:21 <+protokol> no guarentees
            
-
            13:21 <+protokol> lol
            
-
            13:22 <@jrandom> yeah, i wouldn't worry about packages until 0.5, if not 1.0
            
-
            13:22 <@jrandom> (i hope to have the auto-updater in 0.5)
            
-
            13:22 <+protokol> awesomecore
            
-
            13:23 <@jrandom> actually, if someone wants to work on the updater, that'd be a pretty kick-ass low-hanging-fruit.  just write a servlet to download and verify from dev.i2p/i2p/i2pupdate.zip, then call the router's restart method
            
-
            13:23 < Myo9> Auto-updater, sounds like a threat.
            
-
            13:23 <+protokol> modulus: welsome
            
-
            13:23 <+protokol> $200 bounty for it
            
-
            13:24 <@jrandom> heh true myo9, the update would want to allow both manual controls (one click update) and would want to verify a signature on the update
            
-
            13:24 < ant> * DrVince had a problem with i2pupdate.zip
            
-
            13:24 < ant> <cervantes> something that can be enabled or disabled would be nice ;)
            
-
            13:24  * protokol makes it offical
            
-
            13:24 < Myo9> So, all of a sudden, the router restarts and one notices Jr. has teamed with the IP ppl and DRM is enabled.
            
-
            13:24 <@jrandom> protokol: oh cool, send in the $200 and i'll add that to the bounty page 
            
-
            13:24 < Myo9> ;)
            
-
            13:24 < Myo9> I want auto-update turned off by default.
            
-
            13:24 <@jrandom> agreed myo9
            
-
            13:25 < ant> <cervantes> perhaps the routerconsole can be ammended to notify if a new version is available
            
-
            13:25 <@jrandom> right cervantes
            
-
            13:25 < Myo9> Great!
            
-
            13:25 <@jrandom> it would want to display whether there is a new release, and give the user a one click option to upgrade
            
-
            13:25 <@jrandom> (it'd be easy enough to add a web page @ www.i2p/ that contains the current version, so the router could check that periodically)
            
-
            13:26 <@jrandom> ((or on demand))
            
-
            13:26 < Hybrid> yes jrandom. that would be cool.   also on the button a link to 'whats new' html page
            
-
            13:26 <@jrandom> Hybrid: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD
            
-
            13:26 < ant> <cervantes> yeah...I've got a page on the forum that lets my firefox toolbar know of latest "events"/news
            
-
            13:27 <@jrandom> but yeah, a link there too would be nice
            
-
            13:27 <@jrandom> ah cool cervantes
            
-
            13:27 < Hybrid> don't forget to put the version the user is currently running and the new version number available.   (I like the way dvd decrypter does this)
            
-
            13:27 < ant> <cervantes> don't count on me releasing anything yet though....
            
-
            13:28 <@jrandom> right right Hybrid, the current version the user is running is visible on the top left corner of the router console, so it shouldnt be a problem
            
-
            13:28 < ant> <cervantes> wanted to spend the holidays working on it and have so far done absolutely nothing...
            
-
            13:28 <@jrandom> but this won't be bundled into the 0.4.2.6 release, because i havent written any of this code :)
            
-
            13:28 <@jrandom> heh cervantes, i hear you.  i do look forward to the xul though!
            
-
            13:29 <@jrandom> ok, anyone have anything else wrt 2) 0.4.2.6, or shall we move on to 3) 0.5?
            
-
            13:29 < Hybrid> is it a problem for i2p to shutdown, new version install, and restart... would other applications irc need restarting??.. any other complications in  a 'click n update' feature
            
-
            13:30 < Hybrid> (sorry interrupting dev meeting lol)
            
-
            13:30 <@jrandom> Hybrid: not a problem at all - thats what the "graceful restart" button on http://localhost:7657/configservice.jsp does
            
-
            13:30 < Hybrid> k
            
-
            13:31 < ant> <cervantes> jrandom: does the wrapper re-read the wrapper.config on a restart?
            
-
            13:31 <@jrandom> cervantes: no :(
            
-
            13:31 <@jrandom> i wish it did
            
-
            13:31 < ant> <cervantes> guess we need a wrapper service wrapper
            
-
            13:32 <@jrandom> perhaps someone could get a patch in to the java service wrapper folks
            
-
            13:32 <@jrandom> heh
            
-
            13:32 <@jrandom> ok, jumping to 3) 0.5
            
-
            13:32 <@jrandom> well, i dont really have much to say about this beyond whats in the email
            
-
            13:33 <@jrandom> lots of progress, many sheets of paper, and some code.  nothing committed or ready for show yet though
            
-
            13:33 <@jrandom> thats 'bout all i have to say on that front, unless someone has any questions
            
-
            13:34 <@jrandom> if not, we can mosey on over to 4) jabber @ chat.i2p
            
-
            13:35 <@jrandom> new jabber server (w00t!).  see the email & the forum for details
            
-
            13:35 <@jrandom> aparently it was dirt easy to set up the server too, so hopefully we can get some docs out there so that other people can run their own
            
-
            13:35 < frosk> i think it's the third i2p has had. i hope this one sticks around :)
            
-
            13:36 < jdot> docs are coming.  its easy a heck w/ Jive Messenger.  Just tunnel the ports properly.
            
-
            13:36 <@jrandom> personally, i'm fine with irc for one on one and group chat, but having the option for jabber is cool
            
-
            13:36 <@jrandom> ah word jdot
            
-
            13:36 <@jrandom> no rush, whenever is great
            
-
            13:37 <@jrandom> it'd just be great to be able to tell people that if they dont like how things are on one particular irc srever, they can go run their own :)
            
-
            13:37 < jdot> also will be looking to changate it with the irc channels .. in the future
            
-
            13:37 <@jrandom> nice
            
-
            13:38 <@jrandom> ok, thats all i have to say on that.  you have anything you want to add jdot?
            
-
            13:39 <+protokol> how does one get on chat.i2p
            
-
            13:39 <+protokol> tis not resolve for me
            
-
            13:39 <@jrandom> http://forum.i2p.net/viewtopic.php?t=229
            
-
            13:40 < jdot> nothing to add.  
            
-
            13:40  * eco has peeked at java service wrapper in the mean time
            
-
            13:40 < eco> re-reading the config file has been implemented for the upcoming 3.20 release
            
-
            13:40 < eco> see http://sourceforge.net/tracker/index.php?func=detail&aid=981060&group_id=39428&atid=425190
            
-
            13:41 <@jrandom> ah wikked
            
-
            13:41  * eco doesn't know when that's due though
            
-
            13:41 <@jrandom> perhaps with 0.5 we'll do a big external-app-upgrade, replacing our aging jetty and java service wrapper code
            
-
            13:42 <@jrandom> oh, before i go on, i suppose we should officially move to 5) ???
            
-
            13:42 <@jrandom> protokol: i think i remember you saying you got jetty working with CGI?  any docs / info on that?
            
-
            13:43 <@jrandom> someone else out there was able to get jetty to do symlinks too, though i dont know who
            
-
            13:43 <@jrandom> (you out there, whoever you are?  how'd you do it?  :)
            
-
            13:44 <@jrandom> or, i suppose, anyone else have anything they want to bring up?
            
-
            13:45  * eco has a public service announcement
            
-
            13:45 < eco> there's a bounty for succesfully pulling i2p through gcj
            
-
            13:45 < eco> according to jr this will be dead simple, so go get it! :-)
            
-
            13:45 <@jrandom> heh, not dead simple, that was just wishful thinking ;)
            
-
            13:46 <@jrandom> but it might be
            
-
            13:46 <@jrandom> (so go get it :)
            
-
            13:46 < cervantes> think I posted links concering jetty symlinks somewhere either in chat or on the forum...can't remember which
            
-
            13:46 < cervantes> was a while back now
            
-
            13:46 <+protokol> jrandom: it was for the more recent version, i just crashed my jetty
            
-
            13:46 < slart> any news on the azureus plugin?
            
-
            13:46 <+protokol> i think jetty should be borught up-to-date so the docs on their website are useful
            
-
            13:46 < Hybrid> gcj?
            
-
            13:46 <+protokol> makes java into a binary
            
-
            13:46 <@jrandom> ah cool cervantes, i'll dig around for it
            
-
            13:47 < cervantes> I've looked at jetty with php...but it's a very hit an miss affair... php comes with a servlet .jar executable for use with tomcat..., I've seen reports that it can be made to work with jetty...but I have no idea how
            
-
            13:47 <@jrandom> protokol: ah
            
-
            13:47 <+protokol> and it needs cgi and symling support as well
            
-
            13:47 <@jrandom> slart: the azureus devs are hacking away and making progress, but its not ready yet
            
-
            13:47 <+protokol> cervantes: DO IT!
            
-
            13:48 <+protokol> it would be like apache built into i2p
            
-
            13:48 < frosk> Hybrid: The GNU Compiler for Java, or sumthing
            
-
            13:48 <@jrandom> cervantes: yeah, .jar support would be neat, but if its flakey, not worth it.  having cgi support in jetty would be best, sicne we could then use normal php
            
-
            13:48 < slaw> excellent
            
-
            13:48 < frosk> mod_i2p :)
            
-
            13:49 <@jrandom> heh
            
-
            13:50 <@jrandom> ok, anyone else have anything they want to bring up for the meeting?
            
-
            13:51 <@jrandom> if not...
            
-
            13:51  * jrandom winds up
            
-
            13:51  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting124.html b/www.i2p2/pages/meeting124.html
deleted file mode 100644
index 8cb5791f..00000000
--- a/www.i2p2/pages/meeting124.html
+++ /dev/null
@@ -1,384 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 124{% endblock %}
-{% block content %}
            I2P dev meeting, January 11, 2005
            
-
            
-
            13:10 < jrandom> 0) hi
            
-
            13:10 < deer> <Ragnarok> you're fired
            
-
            13:10 < jrandom> 1) Net status
            
-
            13:10 < jrandom> 2) 0.5 progress
            
-
            13:10 < jrandom> 3) 0.6 status
            
-
            13:10 < deer> <polecat> bye!
            
-
            13:10 < jrandom> 4) azneti2p
            
-
            13:10 < jrandom> 5) fbsd
            
-
            13:10 < jrandom> 6) hosts.txt as WoT
            
-
            13:11 < jrandom> 7) ???
            
-
            13:11 < jrandom> 0) hi
            
-
            13:11  * jrandom waves
            
-
            13:11 < fdr> yo
            
-
            13:11 < deer> <Ragnarok> hola
            
-
            13:11 < toad_> you just starting? /me will just watch from time to time
            
-
            13:11 < deer> <detonate> hi
            
-
            13:11 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000551.html
            
-
            13:11 < jrandom> cool, all are welcome
            
-
            13:11 < deer> <polecat> Oh.  Not your employment.  My bad.  =3
            
-
            13:11 < jrandom> the logs of the dev meetings are posted up @ the website (after the meeting, of course)
            
-
            13:11 < fdr> I'm starving, so I'll be in and out..
            
-
            13:12 < jrandom> ok, swinging on int to 1) Net status
            
-
            13:12 < jrandom> things seem to be working fine.  duck is back (yay!)
            
-
            13:12 < jrandom> I dont really have much to add beyond whats in the email - anyone else have anything?
            
-
            13:13 < deer> <jrandom> nope
            
-
            13:13 < jrandom> ok, if not, moving on to 2) 0.5 status
            
-
            13:14 < jrandom> There's been some good progress here, finally got the matrix encryption working, but after chatting with polecat the other day, theres a little tweak we need to add on
            
-
            13:14 < toad_> talking to yourself?
            
-
            13:14 < jrandom> heh yeah, until anyone replies ;)
            
-
            13:14 < jrandom> (you should have seen these meetings before I posted the weekly status notes beforehand)
            
-
            13:14 < toad_> I meant across networks. I talk to myself all the time, but not usually across networks. ;)
            
-
            13:15 < deer> <jrandom_> across three networks even [iip here]
            
-
            13:15 < deer> <Ragnarok> stop that, it's creepy :)
            
-
            13:15 < deer> * postman waves
            
-
            13:16 < jrandom> I dont really have anything else to add wrt 0.5, beyond "more info coming soon"
            
-
            13:16 < deer> <polecat> Re net performance, my i2p router went down 24h ago, but before that I managed 8 days of uptime.
            
-
            13:16 < jrandom> ah ok cool
            
-
            13:16 < jrandom> OOMed?  were you running bt or just from activity?
            
-
            13:17 < deer> <polecat> Just a heuristic to brag about.  =3
            
-
            13:17 < deer> <frosk> i generally get as much uptime from my router as i want, although usually no more than 8-9 due to upgrades :)
            
-
            13:17 < deer> <frosk> 8-9 days, that is
            
-
            13:18  * jrandom wishes my kaffe box could do that (oh well)
            
-
            13:18 < deer> * orion can crash a router at will by running 40+ local destinations via btlaunchmanycurses.py. ;)
            
-
            13:18 < jrandom> heh yes, that would do it orion
            
-
            13:18 < deer> <polecat> Oh, the logs say that the JVM appears hung, so I suppose lucky must have used me in a tunnel to download gigabytes of over endowed men.
            
-
            13:18 < deer> <orion> but, I've had uptime of 15 days before BT storms.
            
-
            13:18 < jrandom> oh interesting polecat.  
            
-
            13:19 < jrandom> polecat: if you're feeling brave, it might be worth trying the latest java service wrapper
            
-
            13:19 < jrandom> (if it gets rid of that we should upgrade)
            
-
            13:19 < deer> * laberhorst had uptime 15days with 0.4.2.5 without bt
            
-
            13:19 < jrandom> i think cervantes is still the winner w/ 0.4.1.1 @ 41 days
            
-
            13:20 < deer> <polecat> Anyone want to PM me on how to get the latest java service wrapper?
            
-
            13:20 < jrandom> but anyway, anyone have any comments on 0.5 stuff?
            
-
            13:20 < protok0l> is i2p done yet?
            
-
            13:20 < jrandom> http://wrapper.tanukisoftware.org/doc/english/
            
-
            13:20 < deer> <eco> looking forward to the docs
            
-
            13:20 < jrandom> !thwap protok0l 
            
-
            13:21 < jrandom> ok, moving on to 3) 0.6 status
            
-
            13:21 < deer> <polecat> I still think that there ought to be a way to checksum without the gateway knowing all the checksums, or how many.
            
-
            13:21 < deer> <Ragnarok> where are the documents going up?
            
-
            13:21 < jrandom> polecat: I'd love it, but I doubt it can be done.  
            
-
            13:22 < jrandom> Ragnarok: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD is the current draft
            
-
            13:22 < jrandom> (not updated wrt the first hop issue)
            
-
            13:22 < deer> <Ragnarok> thanks
            
-
            13:22 < deer> <polecat> "They said it couldn't be done.... they called me mad... but they were fools, FOOLS!
            
-
            13:22 < jrandom> heh
            
-
            13:22 < jrandom> hey, if you can find a way, I'm all ears
            
-
            13:23 < jrandom> (and I have a feeling the mixmaster/mixminion folks will be too)
            
-
            13:23 < deer> <jrandom> zounds, 42 usres here
            
-
            13:23 < deer> <jrandom> mule: you 'round?
            
-
            13:24 < deer> <polecat> Heh.  Will keep my nose to the ground then, but no promises as I'm just a dumb ferret not geniushes like y'all.
            
-
            13:24  * jrandom flings a small furry animal at polecat
            
-
            13:25 -!- dm [mihi@dsl-80-42-80-26.access.uk.tiscali.com] has joined #i2p
            
-
            13:25 < jrandom> ok, anyway, 0.6 stuff looks interesting, and mule has started on some hacking, but its still early on in the game
            
-
            13:26 < jrandom> zab has been pretty helpful giving us some guidance from how limewire goes about things, but, well, their congestion control is kind of scary (fixed small windows, full ack)
            
-
            13:26 < jrandom> (but i'm sure they'll improve in time, of course)
            
-
            13:26 < jrandom> also was nice of him to give us a view into how they're having the rubber hit the road, what gotchas they've had with various jvms, etc
            
-
            13:27 < jrandom> (yay zab)
            
-
            13:27 < jrandom> in any case, if you're interested in helping out with the design and implementation or integration of some other provider for 0.6, get in touch with either mule or myself (or, of course, send patches ;)
            
-
            13:28 < jrandom> not much else to say on that, unless anyone has anything to bring up?
            
-
            13:28 < deer> <polecat> Isn't 0.6 supposed to have preliminary fusenet support?
            
-
            13:28 < deer> <frosk> by april, hopefully :)
            
-
            13:29 < toad_> fusenet?
            
-
            13:29 < deer> <frosk> but with all this work on the udp transport, maybe it'll be ready before fusenet will
            
-
            13:29 < jrandom> yeah, the general aim is just to get the ball rolling
            
-
            13:29 < deer> <frosk> fusenet is a content-distribution system more or less like usenet on speed
            
-
            13:29 < toad_> cool
            
-
            13:30 < deer> <frosk> it will initially support blogs, discussion forums and addressbooks for i2p name-destination mappings
            
-
            13:30 < jrandom> though of course, if we get the UDP transport implemented next month, we'll probably roll that out with 0.5
            
-
            13:31 < deer> <frosk> of course, that would be cool :)
            
-
            13:31 < jrandom> and if i had a pony, i'd play with him aaaaalll day
            
-
            13:31 < jrandom> ok, thats prolly 'bout it for 0.6 stuff, moving on to 4) azneti2p
            
-
            13:31 < deer> <frosk> i'm glad you have no pony, then ;)
            
-
            13:31 < jrandom> heh
            
-
            13:32 < jrandom> azneti2p == kickass.  
            
-
            13:32 < jrandom> parg & the rest of the azureus folks have done some great work, and the integration is really nice
            
-
            13:33 < jrandom> torrents work the same as before, show up with all the pretty graphs, lets you do all the queueing / etc you're used to in azureus, except anonymously
            
-
            13:33 < deer> <postman> w00t!
            
-
            13:33 < jrandom> there are still further optimizations and simplifications left to do, but all in all, i'm quite impressed
            
-
            13:33 < deer> <eco> hurray! enter the masses...
            
-
            13:33 < deer> <frosk> i understand you still have to do some manual labour in the router console before you can use it?
            
-
            13:33  * jrandom holds the gates closed for just a litttttle wile longer
            
-
            13:33 < deer> <eco> is java 1.5 indeed required?
            
-
            13:34 < deer> <polecat> Yup.. neat stuff except you can't leave it to daemon out.
            
-
            13:34 < deer> <postman> sounds like the invitated for the i2p network to get his ass kicked badly
            
-
            13:34 < jrandom> frosk: right - but we're working on patching it up to do the I2PTunnel calls within the plugin itself
            
-
            13:34 < deer> <frosk> cool
            
-
            13:34 < jrandom> eco: unsure, I only tried it with 1.5, but I believe them when they say it.  
            
-
            13:34 < deer> <polecat> eco: I should hope not.  o.O  1.5 is just Sun trying to strongarm the market.
            
-
            13:34 < jrandom> worth trying though, i'll do so later
            
-
            13:35 < deer> * postman does not care, i got gigabit ethernet interfaces and LOTS of traffic included :)
            
-
            13:35 < deer> <polecat> Oh dear... and azareus requires it.  I _really_ have to make my C++ torrent app.
            
-
            13:35 < jrandom> polecat: azureus does have a headless mode of operation, and a web console
            
-
            13:36 < deer> * polecat blinks.
            
-
            13:36 < jrandom> (but its... tough to the uninitiated [like myself])
            
-
            13:36 < deer> <polecat> Well okay then... I thought it didn't, like KazAa
            
-
            13:36 < jrandom> but i only glanced at it (and ran back to the GUI ;)
            
-
            13:36 < deer> <Ragnarok> is duck going to be bringing i2p-bt up to 3.9/4.0?
            
-
            13:37 < jrandom> ragnarok: unknown, but duck is currently doing leaps and bounds to keep all the existing stuff compatible with azneti2p
            
-
            13:37 < jrandom> (they had to do some... odd changes due to technical requirements)
            
-
            13:37 < deer> <polecat> One of the most powerful aspects of p2p is if the app can run quietly in the background whet you're not using it.
            
-
            13:38  * jrandom isnt arguing with that point
            
-
            13:38 < jrandom> ok, i think thats all i have to say wrt azneti2p (other than w00t, again).  more info in the email, and there'll be lots of activity in #i2p-bt i'm sure
            
-
            13:39 < jrandom> anyone else have anything to bring up wrt azneti2p?
            
-
            13:39 < cervantes> are you ready for it... ;-)
            
-
            13:40 < jrandom> heh, we're workin' on it
            
-
            13:40 < deer> <polecat> Might I note that the source of azareus is totally abysmal...
            
-
            13:40 < deer> <polecat> There are 28 main entry points, and it uses at least a namespace depth of 3.
            
-
            13:40 < deer> <Ragnarok> does any bt client have nice source?
            
-
            13:40 < jrandom> there are some oddities, but i suspect you'll find that in anyone else's source (NIH)
            
-
            13:40 < deer> <polecat> Mine will.
            
-
            13:40 < jrandom> oh c'mon, net.i2p.router.netdb.kademlia.* :)
            
-
            13:41 < deer> <Ragnarok> not if it's in C++ it won't :)
            
-
            13:41 < toad_> lol
            
-
            13:41 < deer> <polecat> I said at least!
            
-
            13:42 < jrandom> ok, anyway, moving us along to 5) fbsd
            
-
            13:42 < deer> <polecat> Ragnarok: You've never seen how I *cough*rape*cough* use C++.  n.n
            
-
            13:42  * duck looks in
            
-
            13:42 < deer> <polecat> Who cares about FreeBSD?  Show of hands?
            
-
            13:42 < jrandom> lioux has packaged up the 0.4.2.6 release into ports (w00t!)
            
-
            13:42 < deer> * detonate raises his
            
-
            13:42 < deer> <polecat> Paws, tentacles, wings, etc?
            
-
            13:43  * jrandom raises my hand
            
-
            13:43  * [dave] raises
            
-
            13:43 < deer> <Ragnarok> duck: 3.9/4.0? :)
            
-
            13:43 < deer> <polecat> Woah, i2p is integrated into a distribution?
            
-
            13:43 < duck> Ragnarok: the lack of comments / docs / etc on the latest bram-Bittorrent changes were a bit of a setback
            
-
            13:43 < fdr> FreeBSD is cool :(
            
-
            13:43 < deer> <Ragnarok> I'll bet
            
-
            13:43 < fdr> I may be biased though.
            
-
            13:44 < jrandom> aye, i was worried at first polecat, but his ports impl looked really really easy (so updates will be really really easy)
            
-
            13:44 < duck> It would require studying what they did, maybe it would be worth the effort
            
-
            13:44 < deer> <polecat> As far as I'm concerned, fbsd is a distro with an odd kernel and lots of data hiding.  It's all POSIX in the end so... ;)
            
-
            13:44 < jrandom> polecat: and very, very w0nky JVMs
            
-
            13:45 < duck> though secretly I have been hoping on azneti2p solving all problems
            
-
            13:45 < deer> <Ragnarok> duck: it did sound like there were some nice improvements, but you're the one who'd probably be doing the work, so... :)
            
-
            13:45 < deer> <polecat> Ugh... don't remind me.
            
-
            13:45 < jrandom> heh, azneti2p will probably fit the needs of many users, but simple CLI tools will still make sense for the ubergeeks out there
            
-
            13:46 < jrandom> anyway, so it seems he's tested i2p 0.4.2.6 on fbsd5.3 without problems (w00t)
            
-
            13:46 < deer> <Ragnarok> oy, I don't like azureus, I'd much rather use the normal client
            
-
            13:46  * jrandom has only done so on 4.8
            
-
            13:46 < duck> currently I'd like to do something with kenosis; being a hit-n-run coder
            
-
            13:47 < deer> <eco> jrandom: what jvm did he use?
            
-
            13:47 < jrandom> kenos2p
            
-
            13:47 < jrandom> eco: native compiled sun 1.4
            
-
            13:47 < jrandom> (booo hiss)
            
-
            13:47 < deer> <eco> ah, illegal!
            
-
            13:47 < deer> <polecat> Ragnarok: If you want to critique my bittorrent client design, my current code plan is here: http://polecat.i2p/bittorrent.plan.txt
            
-
            13:47 < jrandom> ((but kaffe works))
            
-
            13:48 < jrandom> eco: is it illegal?  I thought you could agree to the terms and get the source legit on fbsd
            
-
            13:48 < deer> <eco> sun withdrew the license afaik
            
-
            13:48 < jrandom> hmm, i think thats just the blackdown license
            
-
            13:48 < jrandom> (and, tbh, blackdown sucks)
            
-
            13:49 < jrandom> individuals can still license it under SCSL
            
-
            13:49 < deer> <polecat> ouch.
            
-
            13:49 < jrandom> (first born child, etc)
            
-
            13:49 < jrandom> heh, its interesting to hear such license gripes when so few have copyright gripes ;)
            
-
            13:50 < jrandom> but this discussion is best for the 7) ??
            
-
            13:50 < jrandom> and we're on 5) fbsd
            
-
            13:50 < deer> <eco> license stuff on http://www.freebsdfoundation.org/press/20041221-newsletter.shtml , but back to the main thread...
            
-
            13:50 < cervantes> first time we've crept above 5) in a long time
            
-
            13:51 < jrandom> cervantes: and we had to trim things ;)
            
-
            13:51 < jrandom> ok, i think thats it for fbsd stuff (beyond yay!)
            
-
            13:51 < jrandom> so jumping into a messy one... 6) hosts.txt as a WoT
            
-
            13:51 < deer> <polecat> licensing can get you at the node though, whereas copyright vio can only be tracked to the destination.
            
-
            13:51 < deer> <polecat> Which "can't" be found.
            
-
            13:52 < jrandom> right right polecat, but once They have physical control of your box, you're in deep shit anyway
            
-
            13:53 < jrandom> ok, anyway I'm not sure if there's much I have to add to what was posted in the email wrt hosts.txt
            
-
            13:53 < jrandom> anyone have any questions/comments/concerns?
            
-
            13:53 < jrandom> (was I vague enough?  :)
            
-
            13:53 < duck> yes
            
-
            13:53 < deer> * eco considers handing hosts.txt management over to the UN
            
-
            13:54 < jrandom> heh yeah, because we know nice centralized beurocratic authorities always Do The Right Thing
            
-
            13:54 < toad_> lol
            
-
            13:55 < jrandom> i suppose the real "big win" will be when the addressbook gets both a web interface and more metadata
            
-
            13:55 < jrandom> (and perhaps the fusenet syndication, etc)
            
-
            13:55 < deer> <Ragnarok> metadata will be the next thing I work on, using xml name records
            
-
            13:56 < jrandom> kickass ragnarok!
            
-
            13:56 < jrandom> whats your take on the WoT side ragnarok - do you see it as an issue with the addressbook, or how you forsee naming?
            
-
            13:57 < deer> <Ragnarok> Essentially I think the way addressbook works (and how passing around name references on fusenet will work) is the only really sensible way to handle naming on i2p
            
-
            13:58 < deer> <Ragnarok> so, the WoT is a feature :)
            
-
            13:58 < jrandom> Wo0T
            
-
            13:58 < lucky> whoa
            
-
            13:58 < deer> <eco> but surely you sell premium accounts?
            
-
            13:58 < lucky> is that a toad i see?
            
-
            13:58 < lucky> a real toad?
            
-
            13:58 < lucky> or just a frog.
            
-
            13:58 < deer> <frosk> the important point imho, is how to handle collisions
            
-
            13:59 < toad_> a toad
            
-
            13:59 < deer> <detonate> first come, first serve
            
-
            13:59 < jrandom> right frosk, it'd be nice to have an interface to manage those, rather than just "read the log"
            
-
            13:59 < deer> <Ragnarok> frosk: I think that's more an issue of interface than anything else.  Collisions will have to be resolved by the user.
            
-
            13:59 < toad_> call my name if it gets close to my area :)
            
-
            13:59 < deer> <frosk> Ragnarok: my thinking too
            
-
            13:59 < deer> <Ragnarok> anything else can be attacked
            
-
            13:59 < lucky> oh, not the freenet toad.
            
-
            13:59 < lucky> oh
            
-
            13:59 < lucky> it is.
            
-
            13:59 < deer> <eco> so the names are simply like aliases in IM?
            
-
            14:00 < deer> <frosk> collisions need to be stored so you can switch long after the fact
            
-
            14:00 < deer> <Ragnarok> and is probably not provably better in the general case
            
-
            14:00 < lucky> we're paying toad now?
            
-
            14:00 < jrandom> eco: right - the names are just private local nicknames
            
-
            14:00 < deer> <susi23> the addressbook should recognize collisions and notify the user so he can decide
            
-
            14:01 < deer> <Ragnarok> frosk: after the switch to name records, the intent is to never throw them away, but make it easy to change the address they correspond to
            
-
            14:01 < deer> <susi23> until the user made his decision any changes regarding the collision should somehow get "quarantined" :)
            
-
            14:01 < deer> <Ragnarok> susi23: that's essentially how it works now
            
-
            14:01 < deer> <Ragnarok> it just has a lousy interface
            
-
            14:01 < deer> <frosk> Ragnarok: sounds good :) do you have a web interface in the works? (or is there one already i'm not aware about?)
            
-
            14:02 < deer> <susi23> fine then
            
-
            14:02 < deer> <Ragnarok> nope.  I don't do web interfaces :)
            
-
            14:02 < deer> <Ragnarok> susi was working on something, I think, but I'm not sure what's happened with that
            
-
            14:02 < jrandom> (volunteers?  any chance of reviving susidns to manage the names?)
            
-
            14:03 < deer> <susi23> ok, give me a week, I put it on TODO
            
-
            14:03 < jrandom> (and after susidns, we need susitorrent and susiirc...)
            
-
            14:03 < jrandom> wikked!
            
-
            14:04 < jrandom> ok, anyone have anything else to bring up wrt that whole hosts.txt thing?
            
-
            14:05 < jrandom> if not, moving on to 7) ???
            
-
            14:05 < deer> <Ragnarok> one thing
            
-
            14:05 < jrandom> you've got the mic
            
-
            14:05 < deer> <Ragnarok> for the next release, can we agree that hosts.txt should be managed directly by addressbook, so we can stop mangiling userhosts.txt?
            
-
            14:06 < jrandom> sounds reasonable.  i'll stop shipping hosts.txt in the i2pupdate.zip (but will include it in i2pinstall.jar)
            
-
            14:06 < deer> <Ragnarok> cool.  That's all :).
            
-
            14:07 < jrandom> ok, now back to the opne floor
            
-
            14:07 < jrandom> anyone else have anything they want to bring up?
            
-
            14:07 < deer> <postman> yes
            
-
            14:07 < jrandom> hit it postman
            
-
            14:07 < deer> * postman raises his hand
            
-
            14:08 < deer> * postman is desperately looking for a volunteer providing the secondary MX server for i2pmail.org ( this being an inproxy to the internal mailsystem )
            
-
            14:09 < deer> <postman> if anyone got a stable, fast (dedicated) machine, i would be very happy to accept  help
            
-
            14:09 < deer> <postman> configuration / howto will be delivered by me
            
-
            14:09 < deer> <eco> how fast is fast?
            
-
            14:10 < deer> <postman> eco: static IP wuld be nice - everything else is negotiable
            
-
            14:10 < jrandom> how much traffic are you seeing through mail.i2p postman?
            
-
            14:10 < jrandom> (external, that is)
            
-
            14:10 < deer> <polecat> Stable, fast, dedicated... well 1/3 isn't bad.
            
-
            14:10 < deer> <postman> the mailtraffic is VERY low
            
-
            14:10 < deer> <postman> in/out is about 500 mails / month
            
-
            14:11 < jrandom> ah cool
            
-
            14:11 < deer> <Frooze> i have slow (500 MHz), stable, dedicated
            
-
            14:11 < deer> <postman> BUT since the inproxy will have a I2P running
            
-
            14:11 < jrandom> (that'll probably pick up as more people find out about it though ;)
            
-
            14:11 < deer> <eco> the machine would be for incoming mail only?
            
-
            14:11 < deer> <postman> most traffic would be I2p i guess
            
-
            14:12 < deer> <postman> eco: at least incoming ( it's needed for this ) 
            
-
            14:12 < deer> <postman> if the operator is ok with that i would like to rotate outgoing over both machines
            
-
            14:12 < deer> <postman> Frooze: it's ok, when it's able to run i2p
            
-
            14:13 < deer> <postman> just drop me a mail
            
-
            14:13  * toad_ wonders if his current issues are AOB business or if they are simply between him and jrandom
            
-
            14:13 < deer> <postman> if anyone is interested
            
-
            14:14 < deer> * postman hands back the mike
            
-
            14:14 < deer> <Frooze> will do.
            
-
            14:14 < deer> <postman> thanks jr :)
            
-
            14:14 < jrandom> cool, thanks postman
            
-
            14:14 < jrandom> toad_: i think there's much to be discussed, though largely a question for the freenet folks
            
-
            14:15 < toad_> jrandom: right
            
-
            14:15 < toad_> jrandom: talk after meet
            
-
            14:15 < jrandom> sounds good
            
-
            14:15 < duck> no public mudfight? :/
            
-
            14:15 < jrandom> ok, anyone else have anything to bring up for the meeting?
            
-
            14:15 < jrandom> heh duck
            
-
            14:15 < deer> * eco points at http://dodo.freenetproject.org/pipermail/tech/2005-January/001224.html
            
-
            14:15 < jrandom> (that was on tehc ;)
            
-
            14:15 < cervantes> postman: my box has too much shit running on it to be any help I'm afraid ;-)
            
-
            14:15 < deer> <polecat> Ragnarok: If we could sign the addressbook host data, that would allow for automatic updates.  Otherwise not much to be done.  Even if the user gets a popup, how are they to tell which key is accurate?
            
-
            14:15 < deer> <Ragnarok> what does accurate mean?
            
-
            14:16 < jrandom> polecat: signing entries would Kick Fucking Ass.
            
-
            14:16 < deer> <eco> fyi
            
-
            14:16 < deer> <eco> no mud involved.
            
-
            14:16 < deer> <Ragnarok> (and signing is planned for name records)
            
-
            14:16 < deer> <postman> cervantes: hi, thanks anyway :)
            
-
            14:16 < cervantes> you are indeed very welcome
            
-
            14:16 < cervantes> :P
            
-
            14:17 < jrandom> ok, anything else?
            
-
            14:17 < deer> <polecat> Ragnarok: accurate means centered around the correct result.
            
-
            14:17 < cervantes> polecat: I'm waiting for one of my clients to go bust before I sneak into one of their forgotten mailservers to install i2p
            
-
            14:18 < deer> <Ragnarok> polecat: yes, but what's the correct result?
            
-
            14:18 < jrandom> lol cervantes 
            
-
            14:18 < cervantes> %s/polecat/postman
            
-
            14:19 < deer> <polecat> The addressbook file that gets sent between eepsites could do the signing in its format, keeping the other hosts.txt the same.
            
-
            14:19  * duck wonders if updating dot.png is useful?
            
-
            14:19 < duck> it got kind of full
            
-
            14:19 < deer> <eco> give us a 3d applet
            
-
            14:20 < jrandom> duck: its a bit hard to read yeah ;)
            
-
            14:20 < jrandom> duck: perhaps only list the blue lines?
            
-
            14:20 < jrandom> to me, the value comes from seeing how spread out green is
            
-
            14:20 < jrandom> (or whether there are clusters of dark green, etc)
            
-
            14:20 < deer> <Ragnarok> polecat: signing will be supported in the xml name record format.
            
-
            14:21 < deer> <polecat> Ragnarok: The correct result is that the human readable name maps to the destination you expect to see, and only changes when the owner of that destination changes keys.
            
-
            14:21 < deer> <polecat> Right.  So... great.  No problem then.
            
-
            14:21 < deer> <Ragnarok> polecat: that's what we've got now
            
-
            14:22 < deer> <polecat> If the signature of an update matches the original record's public key then you can update automatically, no problem.
            
-
            14:24 < jrandom> ok, there's still room left to be hashed out on the Great Naming Debate, of course
            
-
            14:24 < jrandom> anyone have anything else for the meeting?
            
-
            14:24 < deer> * eco has a UI poll
            
-
            14:24  * jrandom has a GUI
            
-
            14:25 < deer> <Ragnarok> polecat: that will be supported once we've got signing :)
            
-
            14:25 < deer> <eco> the i2ptunnel option in the web ui results in a popup - am i the only one less enthusiastic about that?
            
-
            14:25 < jrandom> definitely not the only one eco.  
            
-
            14:25 < jrandom> i wrote the i2ptunnel web interface approximately as poorly as i could
            
-
            14:25 < jrandom> it really, really sucks
            
-
            14:25  * cervantes steals jrandom's "patches welcome" line
            
-
            14:26 < jrandom> (what cervantes said :)
            
-
            14:26 < jrandom> or even just plain HTML, i can integrate it with the jsp
            
-
            14:26 < jrandom> (but of course patches to the jsp would be nice)
            
-
            14:27 < cervantes> jrandom: btw I have a patch for what we discussed yesterday...just going to test it a little more first....
            
-
            14:27 < jrandom> ah wikked cervantes, thanks!
            
-
            14:27 < deer> <eco> why not list that in the main page, like the other pages?
            
-
            14:27 < deer> <eco> ok, so no big religious or technical reason behind it?
            
-
            14:28 < deer> * polecat has a FUI
            
-
            14:28 < jrandom> eco: from a UI perspective, it can be made to look like the other pages, but not technically
            
-
            14:28 < jrandom> technically, it needs to stay seperate as a client app deployed as a seperate .war file
            
-
            14:28 < deer> <polecat> Ragnarok: I thought you said that's what we've got now?
            
-
            14:29  * jrandom appreciates very much mihi's contribution of that code, but I can't let the i2p console depend upon GPL
            
-
            14:29 < deer> <Ragnarok> er, sorry, I meant everything but the signing, which obviously we don't do right now.
            
-
            14:29 < jrandom> (but we can make it look like the other pages
            
-
            14:30 < deer> <eco> ah, license issues. great
            
-
            14:30 < jrandom> heh isn't it grand eco?
            
-
            14:30 < deer> <Ragnarok> so currently addresses are never updated automatically, changing the destination an address points to always requires user intervention
            
-
            14:30 < cervantes> jrandom: iframe :P
            
-
            14:30  * jrandom wishes people just saw the IP farse for what it was and released into the public domain
            
-
            14:30 < deer> <eco> but in this case a socket connection for example should be okay GPL-wise i'd guess
            
-
            14:30 < jrandom> cervantes: not an impossible alternative
            
-
            14:30 < jrandom> right eco
            
-
            14:31 < jrandom> we've done our best to tap dance around the integration of the actual meat (using clients.config and i2ptunnel.config), but the web UI suffers a bit from it
            
-
            14:33 < deer> <susi23> any wishes, feature requests, and comments regarding the addressbook interface please add to http://susi.i2p/susidns.html
            
-
            14:33  * toad_ respects jrandom's extremist licensing views while disagreeing vehemently with them :)
            
-
            14:33 < jrandom> oh cool, shall do susi23
            
-
            14:34 < jrandom> heh toad_ :)
            
-
            14:34 < deer> * eco puts it on his when-i'm-64-to-do-list
            
-
            14:34 < toad_> bbiab
            
-
            14:34 < jrandom> l8r
            
-
            14:34 < toad_> when i get back we need to talk about various technical issues with i2p/freenet integration
            
-
            14:34 < jrandom> ok, anyone else have anything for the meeting?
            
-
            14:34  * cervantes wheels out the metal gong
            
-
            14:34 < toad_> will try to get back quickly
            
-
            14:34 < jrandom> cool toad_, i'll be around
            
-
            14:34 < jrandom> (it'll give me time to catch up on those threads ;)
            
-
            14:35  * jrandom winds up
            
-
            14:35  * jrandom *baf*s the gong, closing the meeting
            
-
            14:35 < deer> <DrWoo> jrandom: I have one issue if you're still open to 7)??? , I just want to go back to the azureus plug-in for a moment if I may, #1 - this will be *quite* appealing to the peeps, isn't this the perfect time to try to get easy tunnel length controls into the p2p side of I2P via this plug-in, to try to make the best use of bw resources on the net? #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not,
            
-
            14:35 < dm> i2p/freenet integration!?
            
-
            14:35  * jrandom de-gongs
            
-
            14:35  * cervantes puts the gong away
            
-
            14:35 < jrandom> #1: yes, absolutely - I've sent parg a patch to do that
            
-
            14:36 < jrandom> #2: [got trimmed @ 'want it or not,']
            
-
            14:38  * jrandom watches the irc streaming lib logs -
            
-
            14:38 < jrandom> 14:37:55.701: SEND bRC43g==QRnB~Q==: #2          DELAY 1000 MS ACK 1 data: 29 sent 2 times
            
-
            14:38 < jrandom> 14:38:20.072: SEND juVFdg==aAUIVw==: #3465       DELAY 1000 MS ACK 5723 data: 43 sent 2 times
            
-
            14:40 < deer> * eco grabs a beer
            
-
            14:40 < deer> <DrWoo> jrandom: #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not, are you prepared for a user influx, and if not when do you think you will be?
            
-
            14:40 < jrandom> it would not be good to have a large burst of users prior to the UDP transport
            
-
            14:41 < jrandom> there is still a lot of work to be done on azneti2p, so hopefully that'll buy us some time, but we'll do what we need to do
            
-
            14:41 < deer> <DrWoo> jrandom: cool to see your all over #1 ;)
            
-
            14:42 < jrandom> we also will need some docs for #1 too, explaining why 0 hops works for some threat models :)
            
-
            14:44 < jrandom> ok, we ready for a re-gong?
            
-
            14:45  * jrandom winds up
            
-
            14:45  * jrandom *baf*s the meeting closed^2
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting125.html b/www.i2p2/pages/meeting125.html
deleted file mode 100644
index bf7c36ab..00000000
--- a/www.i2p2/pages/meeting125.html
+++ /dev/null
@@ -1,284 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 125{% endblock %}
-{% block content %}
            I2P dev meeting, January 18, 2005
            
-
            
-
            13:04 < jrandom> 0) hi
            
-
            13:04 < jrandom> 1) Net status
            
-
            13:04 < jrandom> 2) 0.5
            
-
            13:04 < jrandom> 3) i2pmail.v2
            
-
            13:04 < jrandom> 4) azneti2p_0.2
            
-
            13:04 < jrandom> 5) ???
            
-
            13:04 < ant> <duck> (the sound of the crypto talk flying past my ears)
            
-
            13:04 < jrandom> :)
            
-
            13:04  * jrandom waves
            
-
            13:04 < cervantes> 'lo
            
-
            13:04 < jrandom> you too can listen to the sound of crypto talk flying past your ears!  weekly status note posted @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html
            
-
            13:05 < bla> hi
            
-
            13:05 < jrandom> jumping on in, since we're cutting into an interesting discussion anyway... 1) net status
            
-
            13:05 < jrandom> i dont really have anything to add beyond whats in the mail - anyone have anything they want to bring up wrt the net status?
            
-
            13:06 < bla> Other that we have, for the first time, seen nodes on *all* continents except Antarctica, no.
            
-
            13:06 < jrandom> w00t!
            
-
            13:07 < jrandom> ok, moving on to 2) 0.5 stuff
            
-
            13:07 < mule> hey, my father is just on his way to antarctica, should have given him a node
            
-
            13:07 < ant> <duck> bloody Antarticans
            
-
            13:07 < Xan> no antarcticans? :(
            
-
            13:07 < jrandom> hah nice
            
-
            13:07 < jrandom> though i dont think there's much of an anonymity set up there 
            
-
            13:07 < Frooze> blame antarctica
            
-
            13:08  * cervantes sets up an oil rig in antartica so he can finance a node there
            
-
            13:09 < jrandom> ok ok, there's a lot of 0.5 stuff, so we can take it in pieces
            
-
            13:09 < jrandom> first up, thanks to the folks who gathered a days worth of stats - lots of interesting data @ http://dev.i2p.net/~jrandom/messageSizes/
            
-
            13:09 < postman> it was a pleasure :)
            
-
            13:10 < cervantes> wrt net status...seen quite a few people having troubles getting I2P up and running lately (on the forums etc) - I don't know if that's just down to increase user volume or perhaps more i2p based apps for things to go wrong with
            
-
            13:10 <+protokol> jrandom: LIAR! you said the data was interesting!
            
-
            13:10  * jrandom flings mud at protokol 
            
-
            13:11 < ant> <duck> cervantes: I have also seen reports of ppl able to get it up and running within a couple of minutes
            
-
            13:11 < ant> <duck> I think that NAT is causing most problems
            
-
            13:11 < cervantes> duck: true...
            
-
            13:11 < ant> <dmdm> who is NAT?
            
-
            13:11 < jrandom> cervantes: there are some ugly issues still, certainly.  the NAT issue and osx has been a bit of a pain lately, but Jhor's help with the later should improve the later
            
-
            13:12 < cervantes> aye
            
-
            13:12 < cervantes> *cough* so... 0.5
            
-
            13:13 < Xan> dmdm: network address translation
            
-
            13:13 < jrandom> heh, ok.  basically the drive with those message size stats is to explore the padding issues 
            
-
            13:14 < jrandom> unfortunately, the strategy i built by cherry picking numbers sucked, giving a 25% overhead just with padding data
            
-
            13:14 < jrandom> if we go with one of the proposals for the 0.5 encryption (tunnels-alt.html), we won't have that issue
            
-
            13:15 < jrandom> (since it'll force small fixes sizes with fragmentation)
            
-
            13:15 < mule> what type of messages do you want to pad, those a router sees or those an external observer sees?
            
-
            13:15 < jrandom> mule: important question
            
-
            13:15 < jrandom> if we're just worried about the external observer, we can leave the messages unpadded, doing any chaff generation at the transport layer
            
-
            13:16 < Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3
            
-
            13:16 < jrandom> otoh, if we're worried about tunnel participants doing flow analysis, we need to worry about padding down the tunnel
            
-
            13:16 <@duck> with 5-6 hops, how big is the danger of a router doing traffic analysis?
            
-
            13:16 < cervantes> Teal`c: meeting atm... can you use #i2p-chat for mp3 announce ;-)
            
-
            13:17 < Teal`c> sorry
            
-
            13:17 < cervantes> :) for david hasselhoff?
            
-
            13:18 < jrandom> depends upon what level of analysis duck.  if they've somehow tracked down what tunnel they're in (e.g. they're the inbound tunnel gateway and have harvested the netDb, correlatign that with a destination), thats nontrivial data.  otoh its not a direct exposure, but does give some info
            
-
            13:18 < jrandom> even more than the tunnel padding though is end to end padding, hiding message flow data from gateways and endpoints.
            
-
            13:19 < jrandom> if we're crazy/stupid, we could go all the way to a pipenet, using constant bitrate everywhere
            
-
            13:19 <+polecat> I got it!
            
-
            13:19 < jrandom> (and end up with no users running i2p)
            
-
            13:19 <+polecat> What we need to do is tunnel i2p over email!
            
-
            13:19 < cervantes> what's the likelyhood of colluding routers ending up in the same tunnel on a sufficiently large network?
            
-
            13:19 <+polecat> No ISP would be dumb enough to stop email!
            
-
            13:20  * jrandom awaits the net.i2p.router.transport.gmail implementation
            
-
            13:20 < postman> polecat: gee , this is silly 
            
-
            13:20 < postman> :)
            
-
            13:20 < bla> cervantes: N^(-h) (N is # of fast nodes, h = # hops). It seems
            
-
            13:20 <+polecat> =3   I know.
            
-
            13:21 < cervantes> is that a lot? :)
            
-
            13:21 < jrandom> not the # of fast nodes, as external people won't know your profiles
            
-
            13:21 <+polecat> Seriously though, in shameless abuse of existing IP services, we could tunnel i2p in any number of ingenious ways.
            
-
            13:21 < jrandom> c^2/N^h to get two peers into the same tunnel
            
-
            13:21 < jrandom> agreed polecat.  thats one of the reasons why we don't have bidirectional tunnels
            
-
            13:22 < jrandom> some transports (e.g. email) suck for bidirectional comm
            
-
            13:22 < bla> jrandom: c = ?
            
-
            13:22 < jrandom> c==# colluding peers
            
-
            13:23 <+polecat> Hm, interesting point.
            
-
            13:23 < ant> <duck> roadmap wise, what is the impact of i2p going a wrong direction and picking a wrong crypto solution?
            
-
            13:23 <+polecat> Or carrier pigeon protocol, not bidi in the slightest.
            
-
            13:23 <+polecat> crypto is modular already, isn't it?
            
-
            13:23 < jrandom> duck: its just one bullet point out of 0.5, and one subsection of the tunnels*.html doc.  theres lots more to the tunnel routing than just how we wrap the data
            
-
            13:24 < bla> jrandom: Then again, this is the prob. for getting them in the tunnel *now*. However, over T tunnel refreshments (every so many minutes), this goes as P = 1 - (1 - c^2/N^h)^T
            
-
            13:24 < jrandom> otoh, the difference between "fixed 1KB blocks" and "0-40KB blocks" has substantial impact
            
-
            13:24 <+polecat> I'd hate to see this network go the way of Entropy, stuck in McEliece.
            
-
            13:24 < jrandom> polecat: read http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD
            
-
            13:24 < bla> jrandom: And thus tends to zero for large enough time. I.e.: for large enough time, the attackers will be in the same tunnel at last one time
            
-
            13:25 < jrandom> the plan is standard AES256/CBC
            
-
            13:25 <+protokol> i hear dns is good for tunneling stuff, most people dont block it
            
-
            13:25 < jrandom> certainly bla, though its not quite that direct (for exploratory tunnels it is, but not for client tunnels)
            
-
            13:26 <+polecat> And if somehow even AES gets cracked, some equivalent symmetric cipher.
            
-
            13:27 < jrandom> bla: i dont think its large enough of a practical worry for most cases in that degree, but when you mount it as part of a predecessor attack, the issue is largely moot
            
-
            13:28 < jrandom> (because of the way we do the rest of the tunnel routing)
            
-
            13:28 < bla> jrandom: k
            
-
            13:28 < jrandom> right polecat 
            
-
            13:29 < jrandom> duck: if we go w/ the second option, changing to another later will likely be easy.  
            
-
            13:29 < jrandom> otoh, the second option will require some hefty performance tuning to Not Suck
            
-
            13:29 < jrandom> but i'm sure we can pull it off
            
-
            13:31 < jrandom> anyway, I think the above covers where we are right now wrt 0.5 work
            
-
            13:31 < jrandom> does anyone have any more questions/comments/concerns?
            
-
            13:31 < bla> jrandom: One
            
-
            13:32 < bla> jrandom: I think we should values anon. slightly more than performance atm: so yes, the PRNG options sounds good
            
-
            13:33 < jrandom> agreed.  performance can be tuned later, "adding in" better anonymity however, is much harder
            
-
            13:33 < jrandom> (but, of course, performance /is/ a security parameter.  if it Sucks, no one uses it)
            
-
            13:33 < bla> Yes.
            
-
            13:33 < bla> jrandom: 
            
-
            13:33 < bla> sorry
            
-
            13:33 <@duck> right, /me flips the magical Freenet-performance bit
            
-
            13:33 < cervantes> perhaps it'll deter all those torrent waving leechers to stay away a while longer ;-)
            
-
            13:34 < jrandom> heh
            
-
            13:34 < cervantes> <-- connection reset
            
-
            13:34 < bla> cervantes: No, I'm not! :)
            
-
            13:34 < cervantes> :)
            
-
            13:35 < jrandom> i do think that we can pull off some really cool optimizations, and it seems a lot of our choke is not related to the peer selection, but merely (heh) bugs in the jobqueue
            
-
            13:36 < jrandom> but, anyway, anything else for 2) 0.5?
            
-
            13:36 < ant> <BS314159> could you post an explanation for this loop attack?
            
-
            13:37 < ant> <BS314159> it sounds more dangerous than your treatment implies it is
            
-
            13:37 < jrandom> loop: build a tunnel containing A-->B-->C-->D-->C, send in 10 messages.
            
-
            13:37 < jrandom> without the PRNGs, you can add as many messages to that C<-->D loop as you want
            
-
            13:38 < ant> <BS314159> ok
            
-
            13:38 < jrandom> effectively DoSing any routers with just a few messages
            
-
            13:38 < ant> <BS314159> but only A can do this
            
-
            13:38 < jrandom> with the PRNGs, it limits the number of messages that can go into the loop
            
-
            13:38 < ant> <BS314159> so there's no danger of an attacker shortening my tunnels by introducing loops
            
-
            13:38 < jrandom> no, no one can shorten your tunnels
            
-
            13:39 < jrandom> the only thing this is useful for is a DoS
            
-
            13:39 < jrandom> (a very cheap DoS)
            
-
            13:39 < jrandom> (but when you can selectively DoS peers without much cost, you can do naaaasty stuff)
            
-
            13:40 < ant> <BS314159> comprendo
            
-
            13:40 <+protokol> and hashcash certs will help this?
            
-
            13:40 < jrandom> protokol: hashcash addresses the issue of a peer building too many tunnels, and perhaps building too many hops
            
-
            13:41 < jrandom> protokol: it doesnt help with loops.  the two ways i could find that /did/ were the PRNGs (tunnel-alt.html) or verifying at each step (tunnel.html)
            
-
            13:42 < jrandom> verifying at each step has dangers, so the current leaning is towards the PRNGs
            
-
            13:42 <+Ragnarok> how effective will the prng method be?
            
-
            13:42 < Xan> A-->B-->C-->D-->C - shouldnt each hop get a different id or something, so that messages leave the tunnel the second time they reach C rather than looping?
            
-
            13:43 < jrandom> Xan: they do, but without verifying each step, you can't tell whether its bad or not
            
-
            13:44 < jrandom> Ragnarok: i think it'll be very effective at minimizing the damage done
            
-
            13:45 < jrandom> at least, from what I can see so far
            
-
            13:45 < jrandom> if anyone sees any problems/issues with it, or suggestions for improvement, please get in touch :)
            
-
            13:46 < Xan> or maybe Im missing the point
            
-
            13:46 < Xan> bbl
            
-
            13:46 < jrandom> 'k l8r, i'll update the doc to be more clear 
            
-
            13:47 < jrandom> ok, unless there's something else, shall we move on to 3) i2pmail.v2?
            
-
            13:47 < jrandom> postman: you 'round?
            
-
            13:48 < postman> yes
            
-
            13:49 < postman> :)
            
-
            13:49 < jrandom> anything to add from your post on the forum?  it sounds pretty cool
            
-
            13:49 < postman> well, a few of you might have read the draft for i2pmail.v2 already
            
-
            13:50 < bla> wtf is happening? Massive disconnects. I've got trouble reaching sites (say orion, library) here too
            
-
            13:50 < postman> it aims towards a fully decentralized mail infrastructure in the future
            
-
            13:50 < postman> but is in need of proxysoftware on the nodes as well as a bunch of dedicated relays
            
-
            13:51 < postman> all are invited to contribute ideas / concepts / rants
            
-
            13:51 < postman> development already has started - dont expect anything before late spring :)
            
-
            13:51 < jrandom> w00t
            
-
            13:51 < kaji> hmm, the cops just showed up at my door
            
-
            13:52 < bla> kaji: ?
            
-
            13:52 < jrandom> quick, blow your hard drive
            
-
            13:52 < postman> jrandom: well, this is all i have to say for now :) 
            
-
            13:52 < cervantes> hide the blackjack table!
            
-
            13:52 < jrandom> wikked, thanks postman 
            
-
            13:52 < kaji> they said i dialed 911, but im quite sure neither i nor my brother did
            
-
            13:53 <+protokol> kaji: they're just checking up on i2p
            
-
            13:53 < jrandom> ok, unless there's anytihng else on 3) i2pmail, lets move over to 4) azneti2p_0.2
            
-
            13:53 <+protokol> <creepy music>
            
-
            13:53 < jrandom> as mentioned in the email, there's been some important progress lately
            
-
            13:53 < kaji> then they said cordless phones can freak out when off the hook, but all my cordless phones are on their charger -> #i2p-chat
            
-
            13:55 < jrandom> the azureus folks have been very responsive in getting an update ready (yay!), but people should also be on the lookout for problems
            
-
            13:55 < jrandom> (if you don't read the i2p mailing list and use azneti2p, read the i2p mailing list)
            
-
            13:55 < jrandom> ((or even if yuo dont use azneti2p, read the list, as thats where we announce important things ;)
            
-
            13:56 < jrandom> duck and orion have also been making lots of updates to accomodate the new bt client and formatting
            
-
            13:56 < jrandom> (yay!)
            
-
            13:56  * orion smiles
            
-
            13:57 < orion> theres still a ways to go, but for now, it works.
            
-
            13:57 < jrandom> (inasmuch as i2p lets it ;)
            
-
            13:58 < orion> hehe, yes. ;)
            
-
            13:58 < jrandom> does anyone else have anything to bring up wrt azneti2p or i2p-bt?
            
-
            13:58 < jrandom> (or bytemonsoon2p ;)
            
-
            14:00 < jrandom> ok if not, moving right along to 5) ???
            
-
            14:00 < jrandom> open floor - anyone else have anything to bring up? 
            
-
            14:00 < postman> jrandom: why does the addressbook publich userhosts entries ?
            
-
            14:01 < jrandom> postman: bug.  
            
-
            14:01 < postman> so this was no planned behaviour and will be changed?
            
-
            14:01 < cervantes> just one thing...
            
-
            14:01 < jrandom> postman: correct, and will be changed
            
-
            14:02 < jrandom> (right Ragnarok?  :)
            
-
            14:02 <+Ragnarok> depends on exactly what postman means...
            
-
            14:03 < jrandom> Ragnarok: new entries added by the local user to their own private hosts shouldn't be propogated to the hosts published
            
-
            14:03 < jrandom> (e.g. userhosts.txt is private, hosts.txt is synchronized with other people and is public)
            
-
            14:03 < cervantes> As part of a semi regular slot on the forum, there will be recognition and awards for those that have contributed good things to I2P either recently or over the project's lifetime
            
-
            14:03 < postman> Ragnarok: after updating to 0.4.2.6 i found entries from my userhosts.txt in the published addressbook in my eepsite folder
            
-
            14:03 < ant> <BS314159> hmm
            
-
            14:04 < postman> Ragnarok: those have been manually added keys, which haven't been supposed to be published
            
-
            14:04 < cervantes> this week we recognise duck for general excellence as a service provider for the community and as an all round great idler: http://forum.i2p/viewtopic.php?t=275
            
-
            14:04 < jrandom> w00t!
            
-
            14:04 < jrandom> (go duck go, go duck go)
            
-
            14:05 < Teal`c> what about domain name hijacking ?
            
-
            14:05  * brachtus applauds
            
-
            14:05  * orion does a duck waddle as a sign of respect.
            
-
            14:05 < cervantes> one important point for the future...you don't have to be a cryptographic genius to get praise!
            
-
            14:06 <+Ragnarok> no, that's expected behaviour.  I can change it, but first I'll have to finish implementing file locking so you can change hosts.txt directly
            
-
            14:06 < orion> (but it helps)
            
-
            14:06 < cervantes> you might just have contributed a cracking eepsite or something...
            
-
            14:06 < cervantes> or been a helpful bod on the forum etc
            
-
            14:07 < ant> <BS314159> hmm
            
-
            14:07 < cervantes> (otherwise, lets face it, jrandom would win every week)
            
-
            14:07 < jrandom> hey, y'all are paying for my beer fund, this stuff aint free ;)
            
-
            14:07 < ant> <BS314159> could you just make a new file, "publichosts.txt"?
            
-
            14:07 < ant> <BS314159> then have addressbook ignore userhosts.txt, but allowed users to subscribe to their own publichosts.txt?
            
-
            14:08 < jrandom> Teal`c: there is no way to hijack a domain name, no entries are overwritten, and userhosts always overrides hosts
            
-
            14:09 < jrandom> Ragnarok: perhaps the web interface can address the locking issue, since users won't be adding to the files manually
            
-
            14:09 <+Ragnarok> once the locking is done, there's no real reason to pull in addresses from userhosts.txt anymore (it's currently the only way to dodge a race), so there's no real point in adding a third file
            
-
            14:10 <+Ragnarok> jrandom: well, I was planning on using the java file locking api
            
-
            14:10 < jrandom> if you think its necessary, you're the boss :)
            
-
            14:10 < ant> <BS314159> it would allow you to kill all the names gotten from other people while keeping the ones you made yourself
            
-
            14:10 < ant> <BS314159> simply by clearing hosts.txt and changing your subscriptiong
            
-
            14:11 < ant> <BS314159> but I guess that can wait for name-signing
            
-
            14:11 < orion> metadata will solve this problem.  Is a spec drafted yet?
            
-
            14:11 < jrandom> using just two files should be fine - one managed by the addressbook, one not
            
-
            14:12 < jrandom> (you could even have the addressbook ignore userhosts.txt entirely - userhosts.txt overrides hosts.txt anyway)
            
-
            14:12 <+Ragnarok> jrandom: that would be the plan, once locking is done (which really shouldn't be too much work, I just haven't gotten around to it :)
            
-
            14:13 <+Ragnarok> and I'm currently working on learning enough xml schema to write one for the namerecords
            
-
            14:13 < ant> <dr_kavra> is this the channel for kenosis? another channel told me to come here :D
            
-
            14:13 < jrandom> lol
            
-
            14:13 < jrandom> nah, sorry, this is i2p
            
-
            14:14 < jrandom> (unless you're looking for an anonymous comm layer)
            
-
            14:14 < jrandom> wikked Ragnarok 
            
-
            14:14 < ant> <BS314159> I still the XML is too verbose and non-human-readable for this, compared to YAML, but I'm not the one writing the code
            
-
            14:14 < jrandom> Ragnarok: the tough part will be doing the crypto w/ XML without reverting to ugly CDATA
            
-
            14:14 < orion> anybody write a working draft for the metadata spec yet?
            
-
            14:15 < jrandom> (i personally think xml sucks, but i'm just a naysayer)
            
-
            14:15 < jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html has a basic setup
            
-
            14:15 < orion> (name/key metadata)
            
-
            14:15 < dox> has the addressbook and its features been announced somewhere? I didn't know my hosts.txt is published
            
-
            14:15 < jrandom> (see NameReference and LocalEntry elements)
            
-
            14:16 < jrandom> dox: its written to the location specified in addressbook/config.txt
            
-
            14:16 < jrandom> (by default, ./eepsite/docroot/hosts.txt)
            
-
            14:17 < orion> is missing a public/private (i.e. distribute, don't) flag.
            
-
            14:17 < ant> <cervantes> the only good thing about XML (and this is a large + point) is that it's a widely accepted standard
            
-
            14:17 < jrandom> right orion, lots of good ideas have come up since that post
            
-
            14:17 <+Ragnarok> xml may suck, but frankly, it better than any of the alternatives for what I'm doing
            
-
            14:17 < jrandom> cervantes: so is EDI
            
-
            14:17 < orion> is there a place to condense them?  i.e. forum area?
            
-
            14:18 < orion> or maybe a wiki page?
            
-
            14:18 < jrandom> orion: susi's or ugha's wiki
            
-
            14:18 < orion> I'm going to set up wikis for bytemonsoon and orion.i2p to help get some community consensus as to the future development goals of each.
            
-
            14:18 < BrockSamson> xml + crypto w/o CDATA = mime, no?
            
-
            14:19 < jrandom> wikked orion 
            
-
            14:19 < jrandom> BrockSamson: smime, with different parsers ;)
            
-
            14:19 < orion> (also one for name metadata)
            
-
            14:21 < jrandom> there are lots of ways to do the metadata, the important thing is flexibility and 'correctness' so that it can grow or change over time
            
-
            14:21  * jrandom is sure Ragnarok et al will come up with some good stuff :)
            
-
            14:21 < orion> thats why I think a public draft is in order.
            
-
            14:22 < ant> <cervantes> i2p consortium :P
            
-
            14:22 < jrandom> well, people have been saying "someone should put up their ideas on the wiki" for the last few meetings, but the wiki pages aren't growing too much ;)  which is fine, we take the pace we take
            
-
            14:23  * orion promises to have three wikis up within a day and email everyone their locations
            
-
            14:23 < BrockSamson> call me lazy, but compare an ANSI 850 Purchase order EDI to nearly any other XML based purchase order, and i'd rather decode, code, and debug for the XML version. Even if it's 5x the EDI size
            
-
            14:23 < jrandom> w00t
            
-
            14:23 < jrandom> heh BrockSamson 
            
-
            14:24 < BrockSamson> Position 10 is ST? oh then position 310 should be name
            
-
            14:24 < BrockSamson> duh me
            
-
            14:24 < jrandom> BrockSamson: don't think the xml schemas for POs are much better ;)
            
-
            14:24 < jrandom> (but yeah, that stuff is just a totally bloody disaster)
            
-
            14:25 < BrockSamson> they are at 4:30 in the morning
            
-
            14:25 < BrockSamson> unless...
            
-
            14:25 < jrandom> heh
            
-
            14:25 < BrockSamson> it's written by an ex EDI programmer
            
-
            14:25 < BrockSamson> and the xml looks like this: <p1><po><q>1</q></po></p1>
            
-
            14:26 < BrockSamson> i bet though, if you add up the horuse OpenSource projects spend talking about to 'XML' or not 'XML' you could code linux 10x over.
            
-
            14:26 < BrockSamson> every project i've ever been part of has had massive debates on it
            
-
            14:27 < orion> debates are good for a project, depending on who's debating. ;)
            
-
            14:27 < jrandom> eh, it does what it does, but its not a panacea.  it may work well for the naming stuff
            
-
            14:28 < BrockSamson> many people are in projects just to debate though.
            
-
            14:28 < jrandom> not here.  i'm here for the free beer
            
-
            14:28 < ant> <cervantes> that's debatable
            
-
            14:28 < orion> the implementation details will be clearer when the draft spec is more tangable.
            
-
            14:28 < orion> hence the need for a wiki/peer review.
            
-
            14:29 < BrockSamson> I heard this project gave away free Garlic
            
-
            14:29 < jrandom> lots of it
            
-
            14:30 < jrandom> ok, anyone else have anything to bring up for the meeting?
            
-
            14:30 < ant> * cervantes wheels out the ceremonial call with bell
            
-
            14:30 < ant> <cervantes> call =cow
            
-
            14:30  * jrandom winds up
            
-
            14:31  * jrandom *baf*s the cowbell, closing the meeting
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting126.html b/www.i2p2/pages/meeting126.html
deleted file mode 100644
index 53c98475..00000000
--- a/www.i2p2/pages/meeting126.html
+++ /dev/null
@@ -1,178 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 126{% endblock %}
-{% block content %}
            I2P dev meeting, January 25, 2005
            
-
            
-
            13:50 < jrandom> 0) hi
            
-
            13:50 < jrandom> 1) 0.5 status
            
-
            13:50 < jrandom> 2) sam.net
            
-
            13:50 < jrandom> 3) gcj progress
            
-
            13:50 < jrandom> 4) udp
            
-
            13:50 < jrandom> 5) ???
            
-
            13:50 < jrandom> 0) hi
            
-
            13:50  * jrandom waves belatedly
            
-
            13:51 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000560.html
            
-
            13:51 <+postman> hi
            
-
            13:51  * brachtus waves back
            
-
            13:52  * cervantes waves a detention slip for tardiness
            
-
            13:52 < jrandom> yeah yeah, blame the code for sucking me in
            
-
            13:52 < jrandom> ok, jumping into 1) 0.5 status
            
-
            13:53 < jrandom> lots of progress since last week - all the messy problems we had with the new crypto are resolved without much trouble
            
-
            13:54 < jrandom> the latest http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD is very likely to be what we deploy in 0.5 and beyond, unless/until people find any problems with it
            
-
            13:55 < jrandom> not sure if i have anything else to add beyond whats in the email
            
-
            13:55 < jrandom> anyone have any questions/concerns?
            
-
            13:56 < Ragnarok> what's performance going to be like?
            
-
            13:56 < jrandom2p> (not me)
            
-
            13:56 < jrandom> Ragnarok: tunnel performance should be much better
            
-
            13:56 < frosk> any significant overhead compared to what we have today?
            
-
            13:57 < jrandom> frosk: sometimes
            
-
            13:57 < jrandom> frosk: when we can coallesce messages in a tunnel, the overhead will be minimal
            
-
            13:58 < jrandom> however, when we cannot coallesce or when its not effective, there can be nontrivial waste
            
-
            13:58 < frosk> i see
            
-
            13:59 < jrandom> otoh, we're trimming some of the absurdities of our current i2np (where we currently prepend a 32 byte SHA256 before each I2NP message, even ones within garlic messages, etc)
            
-
            13:59 < jrandom> the fragmentation and fixed size will be an issue we need to tune with, but there is lots of room to do so
            
-
            14:01 < jrandom> ok, anytihng else on 0.5?
            
-
            14:02 < jrandom> if not, moving on to 2) sam.net
            
-
            14:02 < jrandom> smeghead has ported the java sam client lib to .net (yay!)
            
-
            14:02 < jrandom> smeghead: wanna give us the rundown?
            
-
            14:03 < smeghead> sure
            
-
            14:03 < smeghead> i'm writing tests for it, should have those in cvs in the next couple of days
            
-
            14:04 < smeghead> should work with .net/mono/portable.net
            
-
            14:04 < smeghead> and c# and vb.net
            
-
            14:05 < frosk> (and all of the other languages that works with .net i suppose)
            
-
            14:05 < cervantes> (urgh)
            
-
            14:05 < smeghead> the interface is dirt simple
            
-
            14:05 < smeghead> just register listener methods with SamReader, or subclass SamBaseEventHandler and override methods as necessary
            
-
            14:05 < smeghead> yes, i aim to make it fully CLR compatible
            
-
            14:06 < jrandom> wikked
            
-
            14:06 < cervantes> cool... smeg.net ;-)
            
-
            14:06 < frosk> goodie
            
-
            14:06 < smeghead> really not much else to it
            
-
            14:06 <+protokol> CLR?
            
-
            14:06 < smeghead> common language runtime
            
-
            14:06 < smeghead> the .net equivalent of the JRE
            
-
            14:07 <+protokol> JRE?
            
-
            14:07 <+protokol> just kidding
            
-
            14:07 < jrandom> !thwap protokol 
            
-
            14:07 < Ragnarok> jrandom: how's the sam bridge holding up these days?  were all the bt related issues resolved?
            
-
            14:08 < Tracker> I doubt it, i2p-bt can even drive my amd64 3000 mad, cpu-wise...
            
-
            14:08 < jrandom> Ragnarok: i havent touched it lately.  there's still the outstanding choke issue that polecat came up with, but where the i2p-bt<-->sam bridge is getting off, i'm not sure
            
-
            14:09 < jrandom> hmm, failed connections will force full ElGamal instead of AES
            
-
            14:10 < Ragnarok> ok
            
-
            14:10 < jrandom> we should be able to reduce some of that after 0.5, but only partially
            
-
            14:12 < Tracker> Ok, the I2P will be good for anonymus trackers but not for anonymus clients. Just try to think what happens on a really popular torrent with some 1000 seeds and leechs.
            
-
            14:12 < jrandom> ok, the sam.net stuff sounds cool, thanks again smeghead.  i'm looking forward to the unit tests and perhaps a demo app :)
            
-
            14:12 < ant> <Evil-Brotten> hello everbody
            
-
            14:12 < smeghead> a demo app, yes i'll do that too
            
-
            14:13 < smeghead> i've ported yours in fact
            
-
            14:13 < jrandom> Tracker: i2p can handle anonymous clients just fine, we just need to figure out whats wrong with the i2p-bt<-->sam bridge to reduce the full ElG's
            
-
            14:13 < smeghead> they're just bug-ridden atm
            
-
            14:13 < ant> <Evil-Brotten> deer?
            
-
            14:13 < jrandom> hi Evil-Brotten
            
-
            14:13 < ant> <Evil-Brotten> hello
            
-
            14:14 < jrandom> weekly dev meeting going on, feel free to stick around.  deer is a gateway to i2p/iip
            
-
            14:14 < ant> <Evil-Brotten> are you an i2p expert?
            
-
            14:14 < ant> <Evil-Brotten> :P
            
-
            14:14 < ant> <Evil-Brotten> ow, ok
            
-
            14:14 < ant> <cervantes> Evil-Brotten: you can talk in #i2p-chat if you like while the meeting is ongoing
            
-
            14:14 < jrandom> Tracker: we've got a lot to do before handling 1k-wide torrents
            
-
            14:14 < ant> <Evil-Brotten> i was just trying to install your program, but i am having some problems
            
-
            14:14 < ant> <Evil-Brotten> cool, i will ask there
            
-
            14:15 < jrandom> wikked smeghead 
            
-
            14:15 < Tracker> jrandom: I hope so, non-anonymus bt won't survive much longer...
            
-
            14:15 < frosk> nonsense
            
-
            14:15 < jrandom> "but exeem is anonymous!@#" </snark>
            
-
            14:15 < Tracker> jrandom: But that's a different story
            
-
            14:15 < ant> <MikeW> what?
            
-
            14:15 < ant> <MikeW> who said exeem is anonymous?
            
-
            14:16 < jrandom> mikew: just the occational fanboy
            
-
            14:16 < jrandom> Tracker: after 0.5 we're going to have a lot of work to do getting performance where we need it to be
            
-
            14:16  * DrWoo notes that 'people' are fucking morons (sometimes)
            
-
            14:16 < Tracker> jrandom: Yeah, installing spy-/adware isn't really what I would do ;)
            
-
            14:16 < jrandom> heh
            
-
            14:17 < smeghead> i happen to like people
            
-
            14:17 < smeghead> they're good on toast
            
-
            14:17 < jrandom> *chomp*
            
-
            14:17 < smeghead> some need a little more butter than others
            
-
            14:18 < jrandom> ok, i think thats 'bout it for 2) sam.net (unless anyone has something else to add?)
            
-
            14:18 < jrandom> if not, moving on to 3) gcj progress
            
-
            14:19 < ant> <dm> sam.net??
            
-
            14:19 < ant> <dm> is it working?/
            
-
            14:19 < jrandom> i've read in my backlog that smeghead has been making some good headway - wanna give us an update on how its going?
            
-
            14:19 < smeghead> yes
            
-
            14:20 < ant> <dm> cooooooool
            
-
            14:20 < smeghead> i modified a few classes so the router compiles with gcj 3.4.3
            
-
            14:20 < smeghead> i will submit the patch after the meeting
            
-
            14:20 < smeghead> after that i and anyone who would like to help can get to work on making it run
            
-
            14:21 < jrandom> nice
            
-
            14:21  * frosk decorates smeghead with the Employee of the Week medal for sam.net _and_ gcj work
            
-
            14:21 < jrandom> aye, v.cool
            
-
            14:21 < smeghead> :)
            
-
            14:22 < Tracker> frosk: better forum user of the week ;)
            
-
            14:22 < frosk> i haven't read the forum this week, sorry :)
            
-
            14:22 < cervantes> duck's glory has not yet expired ;-)
            
-
            14:23  * jrandom is very much looking forward to seeing i2p gcj compatible
            
-
            14:24 < jrandom> (and there's still that bounty on it, so people should get in touch with smeghead and get involved ;)
            
-
            14:24 < smeghead> yes it would expand i2p's portability significantly
            
-
            14:24 < cervantes> maybe we'll be able to squeeze something that resembles performance from the router :P
            
-
            14:24 < ant> <dm> my 32-week run as hardest I2P worker ends at last...
            
-
            14:25 < jrandom> i dont expect gcj to actually improve performance or reduce the memory footprint, but it'll work on OSes that sun doesn't release JVMs for and kaffe is b0rked on
            
-
            14:25 < jrandom> (but if i'm wrong, cool!)
            
-
            14:25 < frosk> anything that can make i2p run better without proprietary software is Good
            
-
            14:26 < jrandom> agreed.  supporting both kaffe and gcj would be a Good Thing
            
-
            14:27 < jrandom> ok, anything else on 3) gcj progress, or shall we move on?
            
-
            14:27 < smeghead> installation would be easier too
            
-
            14:27 < Teal`c> has gcj worked for anything besides 'hello world' examples ?
            
-
            14:27 < Ragnarok> someone built eclipse with it
            
-
            14:27 < smeghead> Teal`c: yes, i've used it for .exe's under mingw before in fact
            
-
            14:27 < smeghead> yes, eclipse was running under gcj with red hat not to long ago
            
-
            14:28 < jrandom> having the option of distributing gcj'ed executables, plain .jar installers, and bundled .jar+jvm will definitely be Good
            
-
            14:29 < jrandom> ok, moving on to 4) udp
            
-
            14:30 < jrandom> there was a recent post to the forum that i just wanted to draw people's attention to, asking (and answering) why udp is important
            
-
            14:30 < Tracker> Yuck
            
-
            14:30 < jrandom> (see http://forum.i2p.net/viewtopic.php?t=280 and comment if you have any suggestions/questions/concenrs)
            
-
            14:31 < jrandom> yuck Tracker?
            
-
            14:32 < jrandom> anyway, both mule and detonate are making some headway on the udp side.  detonate/mule: y'all have any updates to share?
            
-
            14:32 < Tracker> UPD is evil here, while it works well within the country borders it really get's ugly when trying to use it on destinations outside our countrys.
            
-
            14:32 < jrandom> hmm
            
-
            14:32 < Tracker> Just my experience from 5 years online gaming...
            
-
            14:33 < jrandom> we'll certainly need to take into account the congestion and mtu issues as they go out on the net
            
-
            14:33 < Tracker> Somehow the two big backbones here don't like to router UPD very well and if only with very low priority.
            
-
            14:34 < Tracker> Meaning pings between 5 and 20 seconds.
            
-
            14:34 < jrandom> i'd be pretty suprised if there was an isp that didn't allow UDP at all (since we all use DNS)
            
-
            14:34 < Tracker> And high packet loss
            
-
            14:34 < jrandom> congestion control is certainly important
            
-
            14:35 < Tracker> Why do you think I'm running my own caching dns with a very big cache for years ;)
            
-
            14:35 < jrandom> heh
            
-
            14:35 < jrandom> well, we will have the fallback of tcp for people who cannot use udp for some reason
            
-
            14:36 < jrandom> but udp will be overwhelmingly preferred 
            
-
            14:36 < Tracker> That's nice.
            
-
            14:36 < jrandom> (meaning i hope there will only be perhaps 10 people using tcp out of 1m+ nodes ;)
            
-
            14:37 < jrandom> but, again, that forum link explains why we need to do what we're doing, though if anyone can find a better way, i'm all ears
            
-
            14:37 < Tracker> I guess I will be one of them.
            
-
            14:37 < jrandom> perhaps.  
            
-
            14:38 < jrandom> we'll see as 0.6 is deployed whether thats the case, or whether we'll be able to work around the issues your isp has
            
-
            14:38 < jrandom> ok, anything else on udp?  or shall we move on to 5) ???
            
-
            14:39 < jrandom> consider us moved
            
-
            14:39 < jrandom> 5) ??
            
-
            14:39 < jrandom> anyone have anything else to bring up?
            
-
            14:40 < Teal`c> is the pizza here yet ?
            
-
            14:40 < Jhor> anybody know where i should look to find/debug problems in bittorrent?
            
-
            14:41 < jrandom> Jhor: in i2p-bt, a good place to start would likely be adding in some logging to tell you what BT messages are sent/received, so we know where its blocking/timing out/etc
            
-
            14:41 < jrandom> (assuming you mean i2p-bt and not azneti2p?)
            
-
            14:42 < Jhor> yeah, i2p-bt.  what are the different spew levels?
            
-
            14:42 < jrandom> no idea, all i know is --spew 1
            
-
            14:42 < Jhor> Ok, I'll try that
            
-
            14:43  * Jhor prepares for a crash course in python
            
-
            14:43 < jrandom> :)
            
-
            14:44 < jrandom> ok, anybody else have something to discuss?
            
-
            14:44  * cervantes wheels out the Strand Gong
            
-
            14:44 < jrandom> we're around the 60m mark, so a pretty good rate
            
-
            14:44 < Teal`c> when is udp due for general consumption ?
            
-
            14:44 < jrandom> Teal`c: april
            
-
            14:44 < jrandom> thats 0.6, we're still working on 0.5
            
-
            14:45 < Teal`c> nice work.
            
-
            14:46 < jrandom> progress, ever onwards
            
-
            14:46  * jrandom winds up
            
-
            14:46  * jrandom *baf*s the gong, closing the meeting
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting127.html b/www.i2p2/pages/meeting127.html
deleted file mode 100644
index 3f6793fe..00000000
--- a/www.i2p2/pages/meeting127.html
+++ /dev/null
@@ -1,159 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 127{% endblock %}
-{% block content %}
            I2P dev meeting, February 1, 2005
            
-
            
-
            13:06 < jrandom> 0) hi
            
-
            13:06 < jrandom> 1) 0.5 status
            
-
            13:06 < jrandom> 2) nntp
            
-
            13:06 < jrandom> 3) tech proposals
            
-
            13:06 < jrandom> 4) ???
            
-
            13:06 < jrandom> 0) hi
            
-
            13:06  * jrandom waves
            
-
            13:06 <+postman> hi jr
            
-
            13:07  * postman waves
            
-
            13:07 < jrandom> w3wt there is life out there :)
            
-
            13:07 < jrandom> weekly status notes posted up @ http://i2p.net/pipermail/i2p/2005-February/000561.html
            
-
            13:07 < ant> * dm waves
            
-
            13:08 < jrandom> while y'all read that email, we can jump into 1) 0.5 status
            
-
            13:08 < MANCOM> hi
            
-
            13:09 < jrandom> lots of progress over the last week, all the new crypto is in and tested, and now all of the router's tunnel operation is done through the new tunnel pools
            
-
            13:10 < jrandom> there are still some parts of the router i chopped out while doing the update, such as the tie in to request leases from clients or periodically test the tunnels, but those shouldn't be too difficult
            
-
            13:11 < jrandom> the code is not compatible with the live net, and is on a separate branch in cvs, so people can still pull cvs HEAD and work with the latest 
            
-
            13:12 <+polecat> Dook I finally looked at that page, and I still don't understand how we can avoid mixmaster style redundancy to protect from tunnel detection attacks.
            
-
            13:12 <+protokol> yey
            
-
            13:12 <+polecat> I imagine it works very well though.  :)
            
-
            13:12 <+protokol> are you throwing in any other cool compatibility-breaking stuff?
            
-
            13:13 <+protokol> the tunnel pool has to do with treads, right?
            
-
            13:13 < jrandom> polecat: we don't verify at every hop, but we have a fixed message size to prevent useful tagging (and everything is encrypted at each hop)
            
-
            13:14 < jrandom> protokol: i'm considering http://www.i2p/todo#sessionTag
            
-
            13:14 <+polecat> So how to prevent multiple hops passing around bogus messages, and causing a DoS?
            
-
            13:15 < jrandom> but no, the pools aren't the threading issue, the pools just let us safely manage the tunnels so that we don't get those "Lease expired" messages and can configure the length on a per-client basis
            
-
            13:15 < jrandom> polecat: they'll fail at the endpoint, and the creator will detect the failure and move off it
            
-
            13:16 <+protokol> jrandom: aside from any difficulty, i think any anon-improving features should go in ASAP
            
-
            13:16 <+polecat> w00t!  Synchronized PRNG!  First application I've ever seen of that idea!
            
-
            13:17 < ant> <dm> what does PRNG stand for?
            
-
            13:17 < ant> <dm> if I may ask :)
            
-
            13:18 < jrandom> protokol: agreed, thats what 0.5 is for :)  there aren't any other i2p-layer low hanging fruit, but there's always improvements that can be made at the app and lib layers (e.g. i2ptunnel filtering, etc)
            
-
            13:18 < jrandom> dm: PseudoRandom Number Generator
            
-
            13:18 < ant> <dm> cool, thanks
            
-
            13:20 <+protokol> so youre saying that after this, its mostly speed and reliability tweaking?
            
-
            13:21 <+protokol> and why has IRC been sucking lately
            
-
            13:21 < jrandom> protokol: prior to 2.0 for the core and router, yes
            
-
            13:21 <+protokol> i cant seem to connect to ducks server
            
-
            13:21 <+protokol> yey
            
-
            13:21  * jrandom doesnt know, we've seen perhaps 5 bulk disconnects in the last day or so, perhaps something on the server side
            
-
            13:22 < jrandom> there's lots to be tweaked though, especially in the streaming lib after 0.5 is deployed
            
-
            13:23 <+polecat> That whole UDP thing.
            
-
            13:24 < jrandom> ah, the streaming lib shouldn't need changes for the 0.6 release, beyond the ones we do for the 0.5 rev
            
-
            13:25 < jrandom> ok, thats all i have to bring up wrt 0.5 status - anyone have anything else on it?
            
-
            13:27 < jrandom> if not, moving on to 2) nntp
            
-
            13:27 < jrandom> nntp.fr.i2p is up, check it out :)
            
-
            13:28 < jrandom> it doesnt seem like LonelyGuy is around, but he can be reached at http://fr.i2p/.  there are also configuration instructions for slrn on my blog, and jdot found that thunderbird can be fairly safe (though i dont know what config jdot used)
            
-
            13:30 < smeghead> LonelyGuy? :)
            
-
            13:30 < cervantes> did someone also test Pan?
            
-
            13:30 < jrandom> hes been on here occationally
            
-
            13:30 <+polecat> I wouldn't waste too much time on nntp, but as long as it has user managed access control it's fine.
            
-
            13:30 < jrandom> (lonelyguy, not pan ;)
            
-
            13:30 < smeghead> i thought his name was LazyGuy
            
-
            13:31 < jrandom> is it LazyGuy?
            
-
            13:31 < jrandom> i know we've had both...
            
-
            13:31 < jrandom> you're right, lazyguy
            
-
            13:31  * jrandom !stabs self
            
-
            13:31 < jrandom> cervantes: i think LazyGuy tried it out, i dont know the config or result though
            
-
            13:32 < cervantes> I thought it was LimeyGuy?
            
-
            13:33  * jrandom awaits SnarkeyGuy's comments
            
-
            13:33 < smeghead> he's French
            
-
            13:35 < jrandom> ok, i dont have anything more to add beyond that, so unless anyone has any questions, moving on to 3) tech proposals
            
-
            13:35 < cervantes> smeghead: you're thinking of ParesseuxGuy
            
-
            13:36 < jrandom> orion has put together some good descriptions and ideas for a few of the messier issues up at 1) 0.5 status
            
-
            13:36 < jrandom> 2) nntp
            
-
            13:36 < jrandom> 3) tech proposals
            
-
            13:36 < jrandom> erg
            
-
            13:36 < jrandom> damn ^C^V
            
-
            13:36 < jrandom> up at http://ugha.i2p/I2pRfc that is
            
-
            13:37 < jrandom> so next time you want to discuss how you've got a killer naming idea, go to http://ugha.i2p/I2pRfc/I2pRfc0001ResourceNameMetadata
            
-
            13:39 < jrandom> i dont really have much more to add beyond that. its a wiki, get wikiing :)
            
-
            13:39 <+polecat> Yay.
            
-
            13:39 <+postman> jrandom: ohh, cool i think i need to add a few ...
            
-
            13:40 < jrandom> cool postman, thought you would :)  there's a template up there for new ones
            
-
            13:41 <+postman> jrandom: gimme a lil time (first things first) but i will contribute :)
            
-
            13:41 < jrandom> w3rd
            
-
            13:41 <+polecat> ResourceNameMetadata, forming it is relatively trivial.  The trick is figuring out how to /get/ it from other people.
            
-
            13:42 < jrandom> polecat: as postman said, first things first.
            
-
            13:42 <+polecat> But if I had a solution, I'd be wikiing now wouldn't I.  :)
            
-
            13:42 < jrandom> heh
            
-
            13:42 < jrandom> discussion of the tradeoffs of /how/ to distribute prior to deciding /what/ to distribute is premature
            
-
            13:43 < jrandom> there's room for lots of 'em though, so anyone should feel free to post up ideas that aren't fully worked through yet even (though fully functional ones with implementations would be cool too ;)
            
-
            13:44 < jrandom> ok, unless there's something else on that, perhaps we can swing on to good ol' 4) ???
            
-
            13:44 < jrandom> anyone have anything else to bring up?
            
-
            13:45 < jrandom> smeghead: is there anything people can do to help out work through the gcj issues, or is it stalled on their prng?
            
-
            13:46 <+polecat> What to distribute is just a signed dict.  Simple as that.
            
-
            13:46 <+polecat> Yeah probably a good idea.
            
-
            13:46 <+polecat> I'm STILL working on the skeleton for my i2p bt client, though would very much appreciate advice at any stage.
            
-
            13:46 < smeghead> i think i've found a solution
            
-
            13:46 < smeghead> in gnu crypto, there's a fortuna impl. since last summer
            
-
            13:46 < jrandom> nice polecat 
            
-
            13:46 < jrandom> oh cool smeghead 
            
-
            13:46 <+polecat> smeghead: Hee, the $150 is as good as yours.
            
-
            13:47 < smeghead> i can whip up a gnu-crypto.jar that contains only the classes needed for Fortuna
            
-
            13:47 <+polecat> My working notes so far are at http://polecat.i2p/bittorrent.plan.doc
            
-
            13:47 < smeghead> if we shipped the whole gnu-crypto.jar it's about 500 KB, too big really
            
-
            13:47 <+polecat> Don't let the .doc scare you, it's in text/plain.
            
-
            13:48 <+polecat> Fortuna doesn't use SecureRandom to do random things?
            
-
            13:48 < jrandom> yowza, yeah 500KB is a bit excessive, but glancing at http://www.gnu.org/software/gnu-crypto/, it looks like something we could integrate safely (as we'd only be linking to it, not modifying)
            
-
            13:48 < smeghead> SecureRandom was never the problem
            
-
            13:48 < jrandom> polecat: fortuna /feeds/ secureRandom :)
            
-
            13:49 < smeghead> jrandom: it would be easy to make a custom .jar, probably around 50KB
            
-
            13:49 < smeghead> (rough estimate mind you)
            
-
            13:49 < smeghead> i could make an ant build to custom package it on demand even
            
-
            13:50 < jrandom> smeghead: wanna dig 'er into i2p/apps/fortuna/ ?
            
-
            13:50 < smeghead> will do
            
-
            13:50 < jrandom> kickass!
            
-
            13:51 < smeghead> after that, assuming gcj will finally be spitting out random numbers, there will probably be more testing of various i2p functionality
            
-
            13:51 <+polecat> What's the license?
            
-
            13:51 < jrandom> we can then work some voodo in net.i2p.util.RandomSource to either use SecureRandom or fortuna (if its found, etc)
            
-
            13:51 < smeghead> lgpl
            
-
            13:51 <+polecat> Cool.
            
-
            13:51 < smeghead> true, SecureRandom would be unnecessary
            
-
            13:52 < jrandom> yeah, there's still lots to do to get it gcjing, but its a great start
            
-
            13:52 < jrandom> in the profiles i've done on the live net, reseeding the PRNG takes a good portion of the cpu load
            
-
            13:52 < smeghead> if anyone is into writing tests
            
-
            13:52 < smeghead> but i probably don't have to finish that sentence
            
-
            13:52 < jrandom> hehe
            
-
            13:53 < smeghead> i will ask the gnu crypto maintainer about this impl., because i googled for info on it and searched their mailing list archives and there's not a peep on it
            
-
            13:54 < smeghead> and their cvs commit logs aren't too enlightening either
            
-
            13:54 < jrandom> 'k good idea
            
-
            13:54 < smeghead> i hope it works
            
-
            13:54 < smeghead> it's in kaffe cvs btw
            
-
            13:54 < smeghead> your version should have it even
            
-
            13:55 < jrandom> hmm, ah, yeah from the gnu-crypto import
            
-
            13:55 < smeghead> gnu.security.prng.Fortuna
            
-
            13:55 < jrandom> the 'kaffe' provider still uses their old sha1prng iirc
            
-
            13:55 < jrandom> cool
            
-
            13:56 < MANCOM> what is the status of the .net sam stuff? should one start getting into it or are major changes to be expected?
            
-
            13:56 < smeghead> MANCOM: it needs testing, i'll be writing some unit tests for it soon
            
-
            13:56 < smeghead> this gcj thing has kinda put that on hold
            
-
            13:57 < smeghead> MANCOM: i don't expect there'll be any changes to the API at all, so it should be safe to code against
            
-
            13:58 < smeghead> changes behind the API are likely, but you as a client don't need to know that :)
            
-
            13:59 < MANCOM> :)
            
-
            13:59 < jrandom> there may be some later updates that are relevent if you build apps that do large bulk transfer
            
-
            14:00 < jrandom> but if you're just transferring a 10s of KB at a time, it should be fine
            
-
            14:00 < smeghead> ok if the Java client's API changes, then the sam-sharp's will too :)
            
-
            14:01 < MANCOM> i can't argue against that
            
-
            14:02 < jrandom> ok, does anyone have anytihng else to bring up for the meeting?
            
-
            14:02  * cervantes lowers big ben into the channel
            
-
            14:03 <+DrWoo> note: nice work jrandom
            
-
            14:03 < smeghead> nice pun cervantes
            
-
            14:03  * jrandom groans
            
-
            14:04 < MANCOM> i read that you don't want to advertise i2p too much before v0.5, is that true?
            
-
            14:04 < jrandom> MANCOM: before 0.6.  yes
            
-
            14:04 < jrandom> MANCOM: 0.5 will improve anonymity and help users control their performance better.  0.6 will let thousands+ concurrent users operate safely
            
-
            14:04 < MANCOM> ah. 0.6. ok.
            
-
            14:05 < jrandom> gracias doc, lots of progress :)
            
-
            14:05 <+polecat> Whee, here's looking forward to 0.6...
            
-
            14:05 <+DrWoo> :)
            
-
            14:06 < jrandom> agreed polecat, agreed :)
            
-
            14:06  * jrandom winds up
            
-
            14:06  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting128.html b/www.i2p2/pages/meeting128.html
deleted file mode 100644
index 252b9e21..00000000
--- a/www.i2p2/pages/meeting128.html
+++ /dev/null
@@ -1,291 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 128{% endblock %}
-{% block content %}
            I2P dev meeting, February 8, 2005
            
-
            
-
            13:05 < jrandom> 0) hi
            
-
            13:05 < jrandom> 1) 0.4.2.6-*
            
-
            13:05 < jrandom> 2) 0.5
            
-
            13:05 < jrandom> 3) i2p-bt 0.1.6
            
-
            13:05 < jrandom> 4) fortuna
            
-
            13:05 < jrandom> 5) ???
            
-
            13:06 < jrandom> 0) hi
            
-
            13:06  * jrandom waves
            
-
            13:06 <@duck> y0
            
-
            13:06 < smeghead> hi
            
-
            13:06 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000564.html
            
-
            13:07 < cervantes> sorry I'm late...I was busy reading the status notes that were posted at the last minute...
            
-
            13:07 < jrandom> hey, this week they were /before/ the meeting at least (by 30s or so ;)
            
-
            13:08 < jrandom> anyway, while you dig through that oh so exciting email, lets jump on into 1) 0.4.2.6-*
            
-
            13:09 < jrandom> with the latest patches from anon et al, i'm torn between pushing out a new 0.4.2.7 so close to the 0.5 rev.  
            
-
            13:10 < jrandom> for the moment though, if you're feeling brave, feel free to give cvs a whirl - its stable (i'm breaking things off on another branch), and has some good stuff
            
-
            13:11 < jrandom> the deciding factor for not pushing a rev out was when i did a checklist for 0.5 and found that the only things left were really web interface updates
            
-
            13:11 <+Ragnarok> about the patches from sugadude, they do represent a policy change, as we discussed filtering out non .i2p addresses before, and you decided against it
            
-
            13:11 < jrandom> oh, hrm?  i disagree with my old self then - eepproxy doesn't accept non-.i2p address in any case, even if they were in hosts.txt
            
-
            13:12 < jrandom> did i have a convincing argument before?
            
-
            13:13 <+Ragnarok> ok, then can we revert the patch, and I can implement it the way it originally worked, which is a 0 line change?
            
-
            13:13 <+Ragnarok> not really, I just didn't care either way :)
            
-
            13:13 < jrandom> oh, cool you're the boss
            
-
            13:13 < cervantes> well you convinced me to drop all my work on a multi-tld management system and fire all my employees
            
-
            13:13 <+Ragnarok> filtering is already happening, so it's just adding a condition to an if statement
            
-
            13:14 < jrandom> cervantes: there's also this beautiful bridge i've got for sale...
            
-
            13:14 < cervantes> :)
            
-
            13:14 < jrandom> ok word Ragnarok, if you want to send me a .java/.tar/.diff/.whatever, that'd be great
            
-
            13:15 <+Ragnarok> I can do cvs now :)
            
-
            13:15 < jrandom> :) even better
            
-
            13:15  * cervantes backs up cvs head
            
-
            13:15 < jrandom> heh
            
-
            13:16 <+Ragnarok> *BOOM*
            
-
            13:16 <+Ragnarok> ... just kidding :)
            
-
            13:17 < jrandom> ok, other than that, anyone have anything else to bring up wrt 0.4.*?
            
-
            13:17 < ant> <dm>gt; 0.4.* sucks, give us 0.5
            
-
            13:17 < ant> <dm>gt; It's like a gazillion years old!!
            
-
            13:18 < ant> <fvw>gt; 0.4.* doesn't suck, give us 0.5 anyway.
            
-
            13:18 < jrandom> 2) 0.5 it is then :)
            
-
            13:19 < ant> <dm>gt; you guys owe me big time, I brought 0.5
            
-
            13:19 < jrandom> we couldn't'a done it without ya dm 
            
-
            13:19 < ant> <dm>gt; amen
            
-
            13:20 < jrandom> as mentioned in the notes, pretty much all the heavy lifting for 0.5 is done and tested, but there are still the odds and ends left to fix up
            
-
            13:21 < jrandom> (e.g. the next task on my list is a tunnel config page to manage the pools and settings)
            
-
            13:22 <@duck> I hope we will have a test-0.5 network before releasing?
            
-
            13:22 < jrandom> there have been updates to lots of different components though, so 0.5 might be a bit bumpy
            
-
            13:22 < ant> <dm>gt; jrandom HAS a test network already.. duh
            
-
            13:23 < jrandom> aye, i've been doing one locally here with a dozen routers, but in the next day or two i'll try to snag some people to help with some wide area tests
            
-
            13:24  * postman can offer a dedicated machine
            
-
            13:24 < jrandom> wikked.  perhaps we can try something out tomorrow, try to break some things.  
            
-
            13:26 < cervantes> as can I
            
-
            13:27 < jrandom> word
            
-
            13:27 < jrandom> thats about all i have to say about the upcoming 0.5 at the moment - the cvs commit logs have been pretty verbose, so if you want the nitty gritty, hit 'em up
            
-
            13:28 < jrandom> anyone else have any comments/questions/concerns/frisbees wrt 0.5?
            
-
            13:29 <+postman> no
            
-
            13:29  * postman is looking forward to get the new V8 running :)
            
-
            13:30 < jrandom2p> well, 0.5 is more of a new tank - designed to improve security and anonymity, not as a performance tweak ;)
            
-
            13:30 < jrandom2p> but i agree, its been too long
            
-
            13:30 <@duck> dont forget to add a 0.5 target to bugzilla
            
-
            13:30 <@duck> in case there are bugs
            
-
            13:30 < jrandom2p> (heh, did i even add a 0.4?)
            
-
            13:31 < jrandom2p> but good call
            
-
            13:31 <@duck> or would you like bugs elsewhere
            
-
            13:31 <@duck> err bugreports :)
            
-
            13:31 <@duck> I know that I have been lazy and abuse irc messages for them
            
-
            13:31 < jrandom2p> no, bugzilla is great, much better than my notebook
            
-
            13:32 < jrandom2p> i don't blame you, as bugzilla is a bit of a pain
            
-
            13:32 < jrandom2p> but as bugs pile up, its for the best
            
-
            13:32 <@duck> nah
            
-
            13:33  * jrandom just noticed i'm switching schitzophrenically between screens
            
-
            13:34 < jrandom> ok, anyway, moving on to 3) i2p-bt 0.1.6
            
-
            13:34 < jrandom> duck: you've got the mic 
            
-
            13:34 <@duck> ok
            
-
            13:34 <@duck> i2p-bt 0.1.5 had some issues, the two biggest ones:
            
-
            13:35 <@duck> - resource temporarily unavailable
            
-
            13:35 <@duck> - invalid argument error on windows
            
-
            13:35 <@duck> both have been fixed
            
-
            13:35 < jrandom> (yay!)
            
-
            13:35 <@duck> while I tried to blame the sam protocol, the sam bridge and winsock
            
-
            13:35 <@duck> the problem turned out to be related to non-blocking socket code
            
-
            13:36 <@duck> I yet have to see 0.1.6 crash
            
-
            13:36 <@duck> some other issues are not addressed:
            
-
            13:36 <@duck> the GUI users have been complaining about the popups
            
-
            13:36 <@duck> you can comment them out, but I didnt like that
            
-
            13:37 <@duck> still waiting for someone to implement a better solution
            
-
            13:37 <@duck> like showing a status line on the transfer window itself
            
-
            13:37  * smeghead hides
            
-
            13:37 < smeghead> i looked at that last night actually
            
-
            13:37 < smeghead> but it's not at the top of my priority list
            
-
            13:37 <@duck> or maybe one day I will look into how wxPython works and do it myself
            
-
            13:37 <@duck> but it's not at the top of my priority list
            
-
            13:38 <@duck> and I dont use the GUI, so I dont really care :P
            
-
            13:38 <+Ragnarok> there's always the new gui from 3.9 :)
            
-
            13:38 <@duck> is it any better?
            
-
            13:38 < smeghead> yes why did you base i2p bt on such a crusty version in the first place? :)
            
-
            13:38 <@duck> because it was the stable release at that moment
            
-
            13:39 <@duck> and not as mutilated as clients like bittornado
            
-
            13:40 <@duck> Ragnarok: ignoring licensing issues, I think that porting our i2p things to 3.9 might be good
            
-
            13:40 <+Ragnarok> the new gui is pretty awsome, imho, and it's written using pygtk, so I can actually hack on it
            
-
            13:40 < jrandom> what's 3.9's license?  i thought it was mit-esque?
            
-
            13:40 <+protokol> i would love a more recent jetty version
            
-
            13:40 < smeghead> protokol: that's coming sooner than you think
            
-
            13:41 <@duck> "BitTorrent Open Source License"
            
-
            13:41 < smeghead> flavor of the month license
            
-
            13:41 <+Ragnarok> I haven't read all of it.. it seems odd
            
-
            13:41 <+protokol> licencing does not exist on i2p
            
-
            13:41 <@duck> derived from the Jabber Open Source License 1.0
            
-
            13:41 <+protokol> if there is source, its PD
            
-
            13:41 <@duck> protokol: that is why I said 'ignoring'
            
-
            13:42 < smeghead> and the jabber license is based on?
            
-
            13:42 < jrandom> (out of date copyright laws?)
            
-
            13:42 < smeghead> besides that :)
            
-
            13:43 < modulus> Sun's wish to fuck about.
            
-
            13:43 <@duck> http://www.opensource.org/licenses/jabberpl.php
            
-
            13:43 < smeghead> i move we schedule the licensing issue for the next meeting of the I2P Public Domain Security Council
            
-
            13:43 < modulus> ah, that one
            
-
            13:43 < modulus> misheard.
            
-
            13:45 <@duck> 3.9.0 looks hot
            
-
            13:45 <@duck> it is still beta though
            
-
            13:47 <@duck> ok, those willing to help, please let me know
            
-
            13:47 <@duck> so we can look into using 3.9.x
            
-
            13:47 <@duck> .
            
-
            13:47 < jrandom> w3rd
            
-
            13:47 < smeghead> i'm willing to help out
            
-
            13:47 < jrandom> i'm willing to help test
            
-
            13:48 <+Ragnarok> I'm willing, but there are likely to be time constraints, as I am currently having the semester from hell.
            
-
            13:48 < jrandom> d'oh
            
-
            13:48 <@duck> drop out
            
-
            13:48 < jrandom> damn, duck beat me
            
-
            13:48 < smeghead> yes, everyone does it
            
-
            13:49 <+Ragnarok> boo
            
-
            13:49 < ant> <jnymo>gt; just join the military ;)
            
-
            13:50 < jrandom> yeah, as that'll give you lots of time to code, 'eh?  ;)
            
-
            13:50 <+Ragnarok> I've already given up on being a math major, that's as much as you're getting from me :)
            
-
            13:50 < jrandom> heh
            
-
            13:50 < jrandom> ok, anyone else have anything on 3) i2p-bt?  
            
-
            13:51 < ant> <jnymo>gt; just don't sign up for six years
            
-
            13:51 <@duck> quite a bit of forum posts on it
            
-
            13:51 <@duck> thanks to those who aid the newbies
            
-
            13:51 <@duck> s/thanks/my thanks/
            
-
            13:51 <@duck> if you have stuff for a FAQ, lemme kno
            
-
            13:52 < jrandom> (if we still had drupal, we could just add a new node...)
            
-
            13:53 < jrandom> ok, anyway, moving on to 4) fortuna
            
-
            13:54 < jrandom> smeghead: wanna give us an update on things?
            
-
            13:54 < smeghead> yes, i'm working on pants and fortuna in tandem
            
-
            13:55 < smeghead> since i needed to modify fortuna's build to turn it into a pbuild
            
-
            13:55 < smeghead> eta on a patch that will let you test fortuna is a day or two, maybe tonight depending on what drugs are involved
            
-
            13:56 < jrandom> heh
            
-
            13:56 <@duck> so you'll get your pants down?
            
-
            13:56 < jrandom> ok, cool, whenever is fine - if we get it in for 0.5 in the next week or so, thats great, if not, thats great too
            
-
            13:56 < smeghead> well even if i finish it tonight, i would take a conservative stance on deployment
            
-
            13:57 < jrandom> reasonable enough
            
-
            13:57 < smeghead> until we get some decent testing in
            
-
            13:57 < smeghead> since this will be at the heart of most of i2p's crypto
            
-
            13:57 < jrandom> aye
            
-
            13:57 < ant> <jnymo>gt; will jbigi stay?
            
-
            13:57 < smeghead> your new entropy class is cool
            
-
            13:58 < jrandom> yeah jnymo, this is just a random # generator
            
-
            13:58 < ant> <jnymo>gt; ah
            
-
            13:59 < jrandom> we'll still need to do some research into the quality of various entropy sources in the router, but I think we'll be able to feed it some data.
            
-
            14:00 < smeghead> btw if anyone wants to read what this pants thing is about: http://smeghead.i2p/README_pants
            
-
            14:00 < jrandom> oh wikked
            
-
            14:01 < smeghead> pants is almost done too
            
-
            14:01 < brachtus> i know jbigi is kinda hard to get working with OS X/Darwin... will this have the same build problems?
            
-
            14:01 < smeghead> what is the issue on osx?
            
-
            14:01 < modulus> it's just you have to build the lib
            
-
            14:02 < modulus> not a big deal imo, but somewhat troublesome.
            
-
            14:02 < jrandom> brachtus: fortuna is in pure java, doesnt use anything native
            
-
            14:02 < smeghead> i can put jbigi into pants and that should make building a cinch if we ship pants with i2p
            
-
            14:02 < brachtus> nothign terribly difficult, it's like building a shared lib on linux, but harder than just double-click-install
            
-
            14:02 < smeghead> you'd need ant of course
            
-
            14:02 < brachtus> ok jrandom, that's great :)
            
-
            14:03 < jrandom> smeghead: thats actually a good point - jbigi has a pants dependency upon GMP
            
-
            14:03 < ant> <jnymo>gt; what is pants?
            
-
            14:03 < smeghead> no manual mucking would be necessary
            
-
            14:03 < ant> * jnymo doesn't have a router up
            
-
            14:03 < smeghead> jnymo: read that link i just posted
            
-
            14:04 < jrandom> http://bolas.mine.nu:8080/cgi-bin/nph-proxy/000000A/http/smeghead.i2p/README_pants
            
-
            14:04 < smeghead> pants can build gmp too
            
-
            14:04 < jrandom> (public inproxy)
            
-
            14:04 < smeghead> ah nice
            
-
            14:04 < jrandom> yuck, that totally b0rked the text
            
-
            14:04 < ant> <jnymo>gt; thanks jr
            
-
            14:04 < ant> <fvw>gt; aren't you afraid of legal trouble?
            
-
            14:04 < smeghead> jrandom doesn't run the inproxy
            
-
            14:04 < jrandom> oh, the inproy is run by someone else, its been posted to the forum
            
-
            14:05 < jrandom> (see http://bolas.mine.nu:8080/)
            
-
            14:05 < cervantes> jrandom: it shouldn't be viewed as an html file...check the source
            
-
            14:05 < ant> <fvw>gt; still, I'm amazed anyone would. But as long as it's being run by someone not vital to the project, fine :)
            
-
            14:05 < jrandom> hehe
            
-
            14:05 < jrandom> we're /all/ vital to the project :)
            
-
            14:06 < smeghead> fvw: i don't see inproxies as legally precarious as outrpoxies
            
-
            14:06 < smeghead> outproxies even
            
-
            14:06 < ant> <fvw>gt; Perhaps not, but they can still serve up child porn and such
            
-
            14:06 < jrandom> only if there were such things on i2p, which, to my knowledge, there isnt 
            
-
            14:06 < legion> outproxies could route through tor, just to be a little safer, since they would just be used for webrowsing I don't see it as a problem.
            
-
            14:07 < jrandom> (but yeah)
            
-
            14:07 < modulus> yet
            
-
            14:07 < ant> <fvw>gt; yeah, but anyone can put it on at any point.
            
-
            14:07 < ant> <fvw>gt; yeah, I wouldn't run a tor outproxy either. Anyway, sorry for drifting offtopic like that
            
-
            14:07 < jrandom> legion: yeah, though i tossed up squid.i2p before tor was out
            
-
            14:07 < ant> <duck_>gt; to get back on topic; looking forward to pants
            
-
            14:08 < jrandom> aye, pants++
            
-
            14:08 < smeghead> i'll let you know before i drop pants on CVS
            
-
            14:08 < smeghead> it's kinda big
            
-
            14:08 < ant> <duck_>gt; folks outside of i2p might be interested in it too
            
-
            14:09 < cervantes> yes let us all know before you drop your pants
            
-
            14:09 < smeghead> yes, i intend to publicise it outside of i2p also
            
-
            14:09 < jrandom> agreed, perhaps we should put it in another module (or on the new fast/large server)?
            
-
            14:09 <+Ragnarok> especially if you're a big pants kind of guy
            
-
            14:10 < smeghead> yes the pants module really should be kept separate from the pants repo in the source tree, currently i have them located in the same apps/pants root
            
-
            14:10 < smeghead> :/
            
-
            14:10 < smeghead> which i don't have to tell you is total pants
            
-
            14:11 < smeghead> so what were we talking about originally?
            
-
            14:11 < jrandom> hmm, we can discuss deployment options offline
            
-
            14:11 < jrandom> fortuna ;)
            
-
            14:11 < smeghead> right
            
-
            14:12 < jrandom> smeghead: have you looked at the AES/SHA256 needs of the impl?
            
-
            14:12 < jrandom> (as i2p's SHA256 doesn't do partial digests)
            
-
            14:13 < smeghead> hm
            
-
            14:13 < jrandom> AES we've got perfectly suitable block impl though
            
-
            14:13 < smeghead> i guess i'll find out when it blows up
            
-
            14:13 < jrandom> anyway, we can work those through too
            
-
            14:13 < jrandom> heh
            
-
            14:15 < jrandom> ok, anyone have any questions/thoughts/concerns on fortuna?
            
-
            14:15 < jrandom> if not, hopping on over to 5) ???
            
-
            14:15 < jrandom> cervantes: p1ng
            
-
            14:16 < cervantes> http://forum.i2p/viewtopic.php?t=305
            
-
            14:16 < cervantes> we have a new forum member of the week
            
-
            14:16 < cervantes> I present [drumroll] Sugadude!
            
-
            14:16  * brachtus applauds Sugadude
            
-
            14:17 < jrandom> yay
            
-
            14:17 < cervantes> for generally being a helpful sod to all those i2p n00bs
            
-
            14:17 <@duck> nice avatar too
            
-
            14:17 < cervantes> avatar(s)
            
-
            14:18 < legion> avatars? didn't know that we could have avatars on the i2p forums?
            
-
            14:18 < smeghead> only users who are really really bad get them
            
-
            14:18 < cervantes> you can't...unless you're a forum person of the week ;-)
            
-
            14:18 <@duck> only for the elite
            
-
            14:18 < legion> oh, i see...
            
-
            14:19 < ant> <jnymo>gt; i know someone was interested in secure financial systems over i2p
            
-
            14:19 < legion> makes sense :)
            
-
            14:19 < ant> <jnymo>gt; don't know if they're here, but...
            
-
            14:19 <@duck> I am a smelly anarcho capitalist
            
-
            14:19 <@duck> so try me
            
-
            14:20 < ant> <jnymo>gt; i was reading more on threashold cryptography and theres talk about using it for that
            
-
            14:20 < ant> <jnymo>gt; as well as securing other functions
            
-
            14:21 < ant> <jnymo>gt; everyone familiar with threshold cryptography?
            
-
            14:21 < legion> IMO that cryptography and network security should be variable, how much should depend on the feature/task.
            
-
            14:21 < ant> <duck_>gt; jnymo: a bit
            
-
            14:22 < ant> <jnymo>gt; well, for trustable financial transactions in i2p, we want strong decentralized trust
            
-
            14:22 < modulus> is that about the shared keys and shit like that?
            
-
            14:23 < ant> <jnymo>gt; yea, keys are shared in pieces
            
-
            14:23 < ant> <duck_>gt; but in an anonymous environment, how do you know that the entities doing the sharing arent controlled by the same one?
            
-
            14:23 < ant> <jnymo>gt; and you need to circumvent more than half of all the servers in the system to obtain the priv key
            
-
            14:24 < modulus> afaik it's kind of complicated the issue of distributed key generations though.
            
-
            14:24 < legion> yeah but in a system of millions that would be hard (yeah i2p is small at the moment, but hopefully it will grow much larger soon).
            
-
            14:25 < ant> <jnymo>gt; atomic communications, or something.. but yea, theres issues with taking on new nodes on the system, which i thing are being worked out
            
-
            14:25 < ant> <jnymo>gt; think
            
-
            14:25 < ant> <jnymo>gt; so maybe its not developed enough, but i'd bet some usage of threshold crypto will end up over i2p at some point
            
-
            14:26 < jrandom> neat
            
-
            14:26 < legion> dunno, maybe
            
-
            14:26 < ant> <jnymo>gt; someone has already built a DNSSEC addon with threshold crypto
            
-
            14:27 < ant> <jnymo>gt; and a wrapper around bind
            
-
            14:27 < jrandom> thresholds work fine when identity is scarce
            
-
            14:27 < jrandom> in anonymous networks, however, identity is free
            
-
            14:27 < legion> I'd figure at the moment the highest priority is to get it more user friendly and debugged.
            
-
            14:27 < jrandom> (want a new destination?  want 100,000?)
            
-
            14:28 < legion> granted it's cool whenever a new service/feature is developed.
            
-
            14:28 < jrandom> aye, commerce and finance on top of i2p will be nice
            
-
            14:28 < ant> <jnymo>gt; yea, and i wouldn't know if atomic commo would work over a 10000 node threshold crypto sys
            
-
            14:29 < ant> <jnymo>gt; well, that's all i had to say :)
            
-
            14:30 < jrandom> heh cool, definitely feel free to post up neat stuff to the forum or whatnot whenever
            
-
            14:30 < jrandom> ok, anyone else have anything for the meeting?
            
-
            14:32 <+ugha2p> I suck.
            
-
            14:33 < jrandom> whats up ugha2p?
            
-
            14:33 < ant> <jnymo>gt; glad you got that off your' chest, ugha ;)
            
-
            14:33 <+ugha2p> I never remember the meetings. :)
            
-
            14:33 < jrandom> heh
            
-
            14:33 < jrandom> well, the logs will be posted soon, 90 minutes of action packed fun
            
-
            14:34 < jrandom> well, on that note
            
-
            14:34  * jrandom winds up
            
-
            14:34  * Curiosity waves to jrandom and stays thank-you! :D
            
-
            14:34 < ant> * jnymo pitches the meeting ball
            
-
            14:34  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting129.html b/www.i2p2/pages/meeting129.html
deleted file mode 100644
index 75798319..00000000
--- a/www.i2p2/pages/meeting129.html
+++ /dev/null
@@ -1,253 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 129{% endblock %}
-{% block content %}
            I2P dev meeting, February 15, 2005
            
-
            
-
            13:07 < jrandom> 0) hi
            
-
            13:07 < jrandom> 1) Net status
            
-
            13:07 < jrandom> 2) 0.5 status
            
-
            13:07 < jrandom> 3) i2p-bt 0.1.7
            
-
            13:07 < jrandom> 4) ???
            
-
            13:07 < jrandom> 0) hi
            
-
            13:07  * jrandom waves
            
-
            13:07 <+ugha2p> jrandom: Is irc.duck.i2p also available on the testnet and linked to this network?
            
-
            13:07 <+ugha2p> To this IRC network
            
-
            13:07 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2005-February/000575.html
            
-
            13:07 < ant> <Sonium_> Bonjour, sa cette fois de la semaine encore,
            
-
            13:07 < jrandom> no ugha2p 
            
-
            13:08 < ant> <Sonium_> are you speaking french jrandom ?
            
-
            13:08 < jrandom> heh, yeah, proof that babelfish has its limits ;)
            
-
            13:08 < jrandom> lol, yeah, people were saying babelfish was turning out ok french before, but aparently not this time ;)
            
-
            13:09 <+ugha2p> Hi fellow I2Pers.
            
-
            13:09 < ant> <fedo2p> hi 
            
-
            13:09 < jrandom> anyway, lets get this underway before we netsplit again 
            
-
            13:09 < jrandom> 1) net status
            
-
            13:09 < jrandom> see the email for an update
            
-
            13:10 < jrandom> it seems that while irc has been pretty bumpy, as has some outproxy activity, bt has been doing pretty well
            
-
            13:11 < jrandom> i don't really have much more to add beyond that though - anyone have any comments/questions/concerns?
            
-
            13:12 < ant> <Sonium_> will 0.5 be released this friday?
            
-
            13:12 < jrandom> heh good question, I suppose that can bring us on to 2) 0.5 status
            
-
            13:12 < jrandom> yes, 0.5 will be released this friday
            
-
            13:13 < jrandom> the test network is doing pretty well with the latest updates, but there's still some doc and minor cleanups left to do.  i'm also going to try to get the latest jetty in there, but we'll see
            
-
            13:14 < ant> <Sonium_> a question for a native english speaker: what is the semantical difference between "it will be released" and "it is going to be released" ?
            
-
            13:14 < bla_> Routing seems to be a little bit of a problem sometimes; in, say 5-10% of the cases, I have to reload a page, because the tunnel isn't working well
            
-
            13:14 < smeghead> i'd like to request that everyone involved in bittorrent activity voluntarily cease until 0.5 is released on friday since the surge in bt traffic is ruining the rest of the network traffic, especially irc
            
-
            13:15 < jrandom> Sonium: the later is more definitive, but same general idea
            
-
            13:15 < bla_> smeghead: I'd agree, but 0.5 will not solve the load problem, will it?
            
-
            13:15 < smeghead> eepsites are affected too, not just irc
            
-
            13:16 < ant> <Sonium_> ok, than it missunderstood the usage till now
            
-
            13:16 <+ugha2p> jrandom: Will it be doing a better job with interactive traffic?
            
-
            13:16 < jrandom> 0.5 will change a lot of dynamics, and should be able to more cleanly handle load balancing, as we can now differentiate between the different causes of tunnel rejection
            
-
            13:16 < ant> <Sonium_> I better would have listened up at school
            
-
            13:16 < jrandom> ugha2p: yes, substantially
            
-
            13:17 <+ugha2p> Ah, cool.
            
-
            13:17 < jrandom> otoh, there will be an overal increase in bandwidth usage for many situations, though we will improve upon that later as things progress
            
-
            13:18 < smeghead> and someone please let our new french speaking users know about this and ask them to hold off the bt stuff until friday
            
-
            13:18 < ant> <BS314159> smeghead: it's three days. I'm sure you can come up with something else to do for three days
            
-
            13:19  * jrandom could poke open an inproxy to spaetz's 0.5 ircd :)
            
-
            13:20 < jrandom> perhaps a simpler solution would be to suggest bt users take advantage of the capacity to reduce network load by reducing their tunnel length
            
-
            13:21 < jrandom> (both on the inbound tunnels, as configured with the bt command line, and on outbound tunnels, as configured on http://localhost:7657/configclients.jsp )
            
-
            13:21 < polecat> Yeah, they don't need so much anonymity as obscurity.  It's us illegal alien ferrets that need the 2 hop thingy.
            
-
            13:21 < bla_> jrandom: A possible solution, bt-0.1.8, wiith default tunnels length of 1, was mentioned before here on the channel. Duck, you here?
            
-
            13:22 < polecat> Does i2p-bt use SAM, or does it use an i2ptunnel session?
            
-
            13:23 < jrandom> hmm, otoh there are a whole set of new i2cp session options we'll want exposed in the i2p-bt, so i'll need to get in touch with duck about an updated release anyway 
            
-
            13:23 < jrandom> polecat: SAM
            
-
            13:23 < smeghead> BS314159: i'm a contributor to not only i2p codebase, but also i2p-bt, this bt traffic is preventing me from communicating with the other devs and impeding our efforts to improve everyone's experience, have some consideration please
            
-
            13:23 < smeghead> BS314159: is it more important for you to torrent than it is for us to develop
            
-
            13:23 < smeghead> ?
            
-
            13:23 < smeghead> polecat: sam
            
-
            13:23 < cervantes> make 0.1.8 shop all it's users to the mpaa and we'll all stick with 0.1.7
            
-
            13:23 < smeghead> bla_: there probably won't be a 0.1.8, we've got 0.2.0 in cvs now, a new codebase based on bt 3.9.1
            
-
            13:23 < jrandom> heh cervantes 
            
-
            13:23 < jrandom> ooOOo nice
            
-
            13:24 < jrandom> perhaps thats a good segue from 2) 0.5 status to 3) i2p-bt :)
            
-
            13:24 < jrandom> smeghead/duck, how goes?  
            
-
            13:25 < ant> <Sonium_> google knows 167 links to www.i2p.org
            
-
            13:25 < bla_> jrandom: Maybe the upgrade timeline should be reiterated: take yer eepsite offline on Thursday evening (UTC), upgrade on Friday, and fire up the eepsite when a sufficient number of users have upgraded
            
-
            13:26 < ant> <Sonium_> erm .net
            
-
            13:26 < smeghead> all the bt mods in 0.1.7 have been integrated into the new 0.2.0 codebase
            
-
            13:26 < smeghead> but we have to write a completely new sam interface, we can't use the one from 0.1.7
            
-
            13:27 < jrandom> ah ok
            
-
            13:27 < smeghead> if there's anyone with python socket experience that would like to help *cough*connelly
            
-
            13:28 < polecat> All that's happening in SAM is the addition of stream level choking, right?
            
-
            13:28 < jrandom> polecat: no protocol changes yet (to my knowledge), just porting
            
-
            13:28 < smeghead> please get in touch with duck
            
-
            13:28 < ant> <MANCOM> anything new on azneti2p?
            
-
            13:28 < smeghead> the 0.2.0 client will handle multiple torrents all in one instance, you won't have to open multiple sessions anymore
            
-
            13:29 < jrandom> (yay!)
            
-
            13:29 < polecat> Reeeally?
            
-
            13:29 < smeghead> and hopefully we can get it all working over a single sam session to further reduce network clutterage
            
-
            13:29 < bla_> smeghead: Nice! Will you also port the text-onlu bttrackmany?
            
-
            13:29 < polecat> Can it run in the background?
            
-
            13:29 < jrandom> MANCOM: I haven't heard any news, and unfortunately haven't had time to audit the updates
            
-
            13:29 < polecat> How much memory does it sit on?
            
-
            13:29 < smeghead> bla_: yes i believe so
            
-
            13:30 < smeghead> polecat: using btdownloadheadless.py it's a background process
            
-
            13:31 < polecat> A single SAM session is possible: the peerwire and tracker protocol can be divined by both the client and server.
            
-
            13:31 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?
            
-
            13:32 < smeghead> polecat: and it shouldn't use significantly more memory than the comparable number of 0.1.7 instances do
            
-
            13:34 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT.  someone could add new and better features, but lets start with a plain port first ;)
            
-
            13:36 < bla_> (Connection rollercoaster ride, again...)
            
-
            13:36 < jrandom> (this is why I lightly edit the meeting logs ;)
            
-
            13:37 < bla_> jrandom: :)
            
-
            13:37 < jrandom> wb
            
-
            13:37 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?
            
-
            13:38 <+ugha2p> jrandom: No, it must be because you're censoring the netsplits.
            
-
            13:38 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT.  someone could add new and better features, but lets start with a plain port first ;)
            
-
            13:38 < jrandom> hey, if i censor the netsplits, they dont happen!  
            
-
            13:38  * jrandom buries head in sand
            
-
            13:40 < smeghead> but i will use this opportunity to again ask bt users to hold off until friday please
            
-
            13:41 < bla_> Right, if there's anyone who speaks French here, you don't have to say anything now, but please add a message to the effect of what smeghead asks to the French sections of forum.i2p ...
            
-
            13:42 <+polecat> At any rate, I've missed the chance to say but, I was thinking of instead of a bt client in C++, I could just fix the mldonkey bittorrent plugin, and use that.
            
-
            13:42 < ant> <dm> I speak french.
            
-
            13:43 < ant> <dm> awww shit, I was supposed to not say anything.
            
-
            13:43  * jrandom flings mud at dm
            
-
            13:43 < bla_> dm: Could you add those messages?
            
-
            13:43 < smeghead> there's nothing wrong with torrenting, but then again such a sudden increase in the number of i2p users wasn't expected and clearly the 0.4.x network can't handle it well
            
-
            13:43 <+polecat> Unless someone else had an idea for something better I could waste my time on.  :/
            
-
            13:44 < ant> <dm> don't have i2p on here, I'm afraid. I can translate english->french if u msg me what needs to be said.
            
-
            13:44 < jrandom> polecat: perhaps help out getting the upcoming i2p-bt to work as you'd like?
            
-
            13:44 < jrandom> dm: forum.i2p.net/
            
-
            13:44 <+polecat> jrandom: I think the main bt isn't very useful myself, and is doomed to be a stopping block for multiple torrent system, unless they switch to a client/server UI.
            
-
            13:44 <+polecat> Which I might add, mldonkey/mlnet has already done.
            
-
            13:44 < smeghead> polecat: mldonkey is a horrid, horrid mess, please help on the i2p-bt project or the azureus-i2p project, they could use a hand
            
-
            13:44 < ant> <BS314159> polecat: I think it's a waste of time to reimplement i2p-bt in a faster language, given the overhead in I2P
            
-
            13:45 <+polecat> And I was planning to do with this stupid C++ client thingy o' mine.
            
-
            13:45 < jrandom> polecat: so put on a gui, giving you the benefit of the underlying i2p-bt code
            
-
            13:45 < ant> <BS314159> but having the use of the MLDonkey interface might be a very good thing
            
-
            13:46 <+polecat> Azareus doesn't separate UI from file transfer I dun' think.  :/
            
-
            13:46 < smeghead> polecat: you need to try bt 3.9.1, it's a multitorrent client now
            
-
            13:48 <+polecat> Does it allow you to quit the UI without quitting swarming your files?
            
-
            13:48 < jrandom> there are some features that it doesnt do well, that azureus does well, though there are also some environments where azureus isn't the right solution
            
-
            13:48 < ant> <jnymo> has azureus released a compatable binary for the plugin?
            
-
            13:48 < jrandom> polecat: no.  but adding that is trivial compared to writing a new bt client
            
-
            13:48 < jrandom> jnymo: yes, they have a beta azneti2p
            
-
            13:49 < smeghead> polecat: it could easily be modified to do so, very easily in fact
            
-
            13:49 < jrandom> polecat: just modify the existing bt daemon to allow other processes (aka your new GUI) to tell it to do things
            
-
            13:49 <+polecat> Well, perhaps...
            
-
            13:49 <+polecat> You think so?
            
-
            13:49 <+polecat> Maybe if I wrote a UI that was just an RPC socket protocol, and then... I'd have to write a whole client to grok that protocol...
            
-
            13:50 < smeghead> polecat: you don't have to write a new ui, mod the existing i2p-bt 0.2.0 ui to do it, it's simple
            
-
            13:50 <+polecat> Maybe we could separate the UI part of bt and the daemon part, and run those pieces as separate processes without having to rewrite too much code!
            
-
            13:50 <+polecat> Okay.
            
-
            13:50 <+polecat> I have one more question though...
            
-
            13:51 < smeghead> polecat: don't reinvent the wheel because something lacks trivial features
            
-
            13:51 < smeghead> polecat: you haven't looked at the i2p-bt codebase at all have you? the ui is completely separate
            
-
            13:51 <+polecat> If bittorrent 3.9.1 is out, why are we using version 0.2.0 in i2p?  o.o 
            
-
            13:51 < jrandom> heh
            
-
            13:51 < jrandom> i2p-bt 0.2.0 == bt 3.9.1 :)
            
-
            13:51 <+polecat> I looked at the codebase a while ago.  It was quite convoluted and obfuscated.
            
-
            13:51 < jrandom> (i2p-bt 0.1.* == bt 3.4.something i think)
            
-
            13:51 <+polecat> Oh, you have different versioning.
            
-
            13:52 <+polecat> Is i2p-bt on CVS?
            
-
            13:52 < smeghead> polecat: 0.2.0 is a new branch in cvs i created yesterday, it's i2p-bt, the official bt version it's based on is 3.9.1 which will be bittorrent 4.0 when it's out of beta
            
-
            13:52 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p-bt/
            
-
            13:52 < smeghead> i2p-bt 0.1.7 is bt 3.4.2 based
            
-
            13:52 <+polecat> Thanks.
            
-
            13:52 <+polecat> Wait.
            
-
            13:53 < cervantes> at which point we'll call it version 0.3.0 :P
            
-
            13:53 <+polecat> I meant CVS, not the "ooh lookit the pretty website CVS"
            
-
            13:53 < jrandom> cvs -d :pserver:anoncvs@cvs.i2p.net/cvsroot co i2p-bt
            
-
            13:53 <+polecat> CVSROOT= is noticeably absent on those cvs-cgi thingies I've noticed.
            
-
            13:53 < jrandom> or, if you have the CVS proxy locally, cvs -d :pserver:anoncvs@localhost/cvsroot co i2p-bt
            
-
            13:54 < smeghead> polecat: convoluted? btdownloadgui.py is all the gui code, how can you get more cleanly separated than that?
            
-
            13:54  * polecat whews, and doesn't feel a burning desire to bitch about CVS now.
            
-
            13:54 < ant> <dm> ugh, that was painful, haven't written anything in french for years! http://forum.i2p.net/viewtopic.php?p=1238#1238
            
-
            13:55 < jrandom> thanks dm
            
-
            13:56 < ant> <dm> np
            
-
            13:57 < smeghead> it probably says something obscene
            
-
            13:58 < ant> <dm> hehehhe
            
-
            13:58 <+polecat> Alright, so I have to write btdaemon.py, which is the gui - all gui stuff.  And also btdaemongui.py, which is the gui - all daemon stuff.
            
-
            13:58 < ant> <BS314159> if it's sufficiently obscene, it may serve our purposes just fine
            
-
            13:58 < ant> <fedo2p> good job dm ;)
            
-
            13:58 < jrandom> heh
            
-
            13:58 < jrandom> r0x0r polecat
            
-
            13:59 <+polecat> Sigh, I hate to emerge wxwindows though, it's a big library I don't normally use.  Oh well.
            
-
            13:59 < smeghead> polecat: 0.2.0 is gtk based, no more wxwidgets
            
-
            13:59 < jrandom> ok, lots of bt work to do, perhaps we can discuss further on the list/forum/wiki/#i2p-bt as necessary?
            
-
            13:59 <+polecat> If I'm gonna be hackin', I best get the toolz
            
-
            14:00 <+polecat> Oh I forgot about that channel.  :)
            
-
            14:00 < smeghead> polecat: get bittorrent 3.9.1 beta and read the docs
            
-
            14:01 < smeghead> #i2p-bt, right
            
-
            14:01 < smeghead> there's even people there
            
-
            14:02 < jrandom> heh ok, lots of exciting bt stuff.  anything else for 3) i2p-bt, or shall we move on to 4) ???
            
-
            14:03 < jrandom> ok, moving to 4) ???
            
-
            14:03 < jrandom> anyone else have anything else to bring up for the meeting?
            
-
            14:03 < ant> <jnymo> threshold crytography rules
            
-
            14:04 < cervantes> ??? = http://forum.i2p/viewtopic.php?p=1237
            
-
            14:04 < ant> <BS314159> proxies to the web are not cool. What about proxies to new versions of I2P, or other anonymnets?
            
-
            14:04 < ant> <BS314159> and by not cool I mean not safe to run
            
-
            14:04 < ant> <jnymo> they aren't run by everyone, BS
            
-
            14:05 < ant> <BS314159> I know that
            
-
            14:05 < cervantes> Forum member of the week is <tadaa!> jrandom
            
-
            14:05 < ant> <BS314159> I'm thinking about upgrades
            
-
            14:05 < jrandom> lol thanks cervantes 
            
-
            14:06 < ant> <BS314159> Not now, but eventually, would it be possible to have a large number of routers act as inter-version proxies?
            
-
            14:06 < ant> <BS314159> and would that remove the timing attack without downtime?
            
-
            14:06 < ant> <jnymo> forced upgrades are necessary
            
-
            14:07 < ant> <BS314159> I disagree
            
-
            14:07 < jrandom> BS314159: I2NP over i2ptunnel over I2P would be, painful.  though perhaps one of the "outproxies" could point at some inproxy 
            
-
            14:07 < jrandom> BS314159: while forced upgrades aren't generally necessary, they are here.  period.  we need it, because I didn't forsee all of the changes we need for 0.5
            
-
            14:08 < ant> <BS314159> I'm not saying new versions should be backwards-compatible
            
-
            14:08 < cervantes> jrandom: well lets be honest...you're the one that does 98% of the work ;-)
            
-
            14:09 < ant> <BS314159> I'm just trying to come up with a way to allow non-nimble I2P users to upgrade without timing attacks or downtime
            
-
            14:10 < jrandom> BS314159: can't be done for the 0.5 release.  later releases we can be careful.  but for this one, its a drop dead cutoff.  
            
-
            14:10 < ant> <jnymo> automatic update may be better in the future
            
-
            14:10 < ant> <BS314159> I'm speaking about the far future.
            
-
            14:10 < ant> <jnymo> is auto-update too insecure?
            
-
            14:10 < jrandom> cervantes: nah, only 95% of the infrastructure, but there's a lot more goin' on than just i2p/{core,router}/ :)
            
-
            14:11 < jrandom> jnymo: 0 click update == insecure.  1 click == safe.
            
-
            14:11 < cervantes> jrandom: yes it's begun to pickup over the last couple of months thankfully ;-)
            
-
            14:11 < ant> <jnymo> and a line that says "you need to update.. countdown in * days"
            
-
            14:12 < jrandom> aye, lots of people [http://www.i2p.net/team] have been doing kickass shit
            
-
            14:13 < jrandom> BS314159: definitely lots we can do for later updates, perhaps we can discuss concrete impls as they approach :)
            
-
            14:13 < jrandom> ok, anyone else have anything to bring up for the meeting?
            
-
            14:13 < ant> <MANCOM> could we have some kind of autospeed feature (like with the azureus plugin that measures ping times) in i2p that adjusts the maximum (upload-)bandwidth?
            
-
            14:14 < ant> <MANCOM> it would help keep bandwidth up and latency down
            
-
            14:14 < jrandom> oh, interesting
            
-
            14:14  * cervantes is working on a 1-2 click update feature for the i2p toolbar
            
-
            14:14 < cervantes> although I'm having problems with hashing atm....so it's probably a few weeks away.
            
-
            14:15 < ant> <jnymo> cervantes++
            
-
            14:15 < jrandom> MANCOM: if you could doc up how it'd work and look, and post that on the forum, that'd be great.  if its simple enough, might even make it into 0.5
            
-
            14:15 < cervantes> in which time a dozen people will come up with a glut of better solutions
            
-
            14:16 < jrandom> heh
            
-
            14:16 < cneal92_> :D
            
-
            14:17 < ant> <MANCOM> well, i'll try
            
-
            14:17 < ant> <cervantes> but it already detects when there's a new release out, and can point you at the relevant download link...
            
-
            14:17 < ant> <cervantes> which I may roll with initially
            
-
            14:18 < jrandom> cool cervantes
            
-
            14:18 < jrandom> thanks MANCOM
            
-
            14:18 < ant> <jnymo> you could just put the "graceful restart" button to upgrade, after the update is already in the directory
            
-
            14:19 < ant> <jnymo> or call it "upgrade"
            
-
            14:19 < ant> <jnymo> and put the restart function in there
            
-
            14:19 < ant> <jnymo> though i'm probably stating the obvious
            
-
            14:19 < jrandom> right, we need perhaps a dozen lines of code to fetch http://dev.i2p/i2p/i2pupdate.zip, verify it, then restart
            
-
            14:20 < jrandom> ok, anyone else have anything to bring up for the meeting?
            
-
            14:20 < ant> <cervantes> well I can already get the toolbar to download an update into the i2p folder AND trigger a graceful restart...but so far I haven't been able to get it verify the download's integrity
            
-
            14:21 < jrandom> cervantes: ah, that part should be easy - at a later date, we'll have the update itself be self-verifying
            
-
            14:21 < jrandom> (aka signed, verified by the router before installation)
            
-
            14:21 < ant> <cervantes> jrandom: that would be cool.
            
-
            14:21 < ant> <jnymo> ooh
            
-
            14:22 < ant> <cervantes> perhaps it will be enough then that I trigger the download and then pop a "do you wish to restart" yes/no requester
            
-
            14:22 < ant> <cervantes> so someone can verify manually if desired
            
-
            14:23 < ant> <cervantes> (it already displays what the sha1 _should_ be)
            
-
            14:23 < jrandom> hehe
            
-
            14:23 < ant> <jnymo> how bout, "click here to autodownload on availability"
            
-
            14:25 < cervantes> I'd rather avoid auto downloads
            
-
            14:25 < ant> <jnymo> hmf.. microsoft does it ;)
            
-
            14:26 < cervantes> but by all means alert the user that a download exists and offer a "download now" button
            
-
            14:26 < jrandom> right, 1 click at the least.  we can automatically /notify/ on update availability, but autoinstall is not ok
            
-
            14:26 < jrandom> (er, what cervantes said)
            
-
            14:27 < ant> <jnymo> now, how do 10000 people update? how bout integrating i2p-bt at one point?
            
-
            14:27 < jrandom> yes, and flying ponies
            
-
            14:28 < ant> <jnymo> good enough for me
            
-
            14:29 < jrandom> ok cool... if there's nothing else...
            
-
            14:29 <+postman> damn missed the meeting :/
            
-
            14:29  * cervantes gets back to coding his vapourware
            
-
            14:29 < jrandom> heh you're at the buzzer, in case there's something you want to bring up postman :)
            
-
            14:30 <+postman> no thanks
            
-
            14:30 <+polecat> Microsoft?  =)  I have gentoo doing it.
            
-
            14:30  * jrandom winds up
            
-
            14:30 <+postman> ooops
            
-
            14:30  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting130.html b/www.i2p2/pages/meeting130.html
deleted file mode 100644
index 927a3ed7..00000000
--- a/www.i2p2/pages/meeting130.html
+++ /dev/null
@@ -1,288 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 130{% endblock %}
-{% block content %}
            I2P dev meeting, February 22, 2005
            
-
            
-
            13:04 < jrandom> 0) hi
            
-
            13:04 < jrandom> 1) 0.5
            
-
            13:04 < jrandom> 2) Next steps
            
-
            13:04 < jrandom> 3) azneti2p
            
-
            13:04 < jrandom> 4) ???
            
-
            13:04 < jrandom> 0) hi
            
-
            13:04  * jrandom waves
            
-
            13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html
            
-
            13:05 < jrandom> (yeah, only a minute or two before the meeting, so lets test your speed reading)
            
-
            13:05 <+detonate> i think i'll wait until it's a bit less buggy before i put boondock saints up, in that case
            
-
            13:06 < jrandom> why... thats... thats... thats a copyright violation!
            
-
            13:06 <+detonate> weird new additions to the azureus beta
            
-
            13:06 <+detonate> categories
            
-
            13:06 <+detonate> haha
            
-
            13:06 <+detonate> a dht tracker
            
-
            13:06 <+detonate> sweet
            
-
            13:07 < jrandom> aye, it looks v.cool, but lets hit items 1 and 2 before 3, 'eh? ;)
            
-
            13:07 <+detonate> hi
            
-
            13:07 <+detonate> indeed
            
-
            13:07 < jrandom> jumpin into 1) 0.5
            
-
            13:07 < jrandom> its, like, out, and stuff
            
-
            13:08 < cervantes> yay!
            
-
            13:08 < jrandom> there'll be a new rev later this evening with a bunch of updates (current CVS head is 0.5-5, with a -6 in testing on some routers)
            
-
            13:09 < jrandom> its gone pretty well, but we've hit a few funky bugs along the way.  but c'est la vie
            
-
            13:09 < frosk> i can report that 0.5-5 behaves a _lot_ more friendly than -4 (which often gave me participating tunnel counts in the thousands)
            
-
            13:09 < bla> jrandom: Will the 0.5.0.1 version correct the problem of nor being able to find destinations?
            
-
            13:09 < jrandom> ah, well, thats really just a function of other people though, the -0 build actually does build hundreds of tunnels
            
-
            13:09 < bla> s/nor/not
            
-
            13:10 < jrandom> bla: yes, thats a bug in the netDb
            
-
            13:10 < bla> jrandom: Great!
            
-
            13:10 < jrandom> (in the leaseSet publishing, specifically)
            
-
            13:11 < jrandom> and yes, the 0.5.0.1 rev will get rid of that occational disapearing proxy bug 
            
-
            13:12 < jrandom> there is still a funky memory leak I haven't tracked down affecting some users
            
-
            13:12 < bla> Then, in all, it seems that part from these bugs, the 0.5 net is doing very well. Yay!
            
-
            13:12 < jrandom> to my knowledge, its only really hitting two or three I2PTunnel instances though
            
-
            13:12 < Meomia> is it a sign of progress when you have gone from 0 to 130 participating tunnels since 0.5 ?
            
-
            13:13 < jrandom> w3wt
            
-
            13:13 < jrandom> Meomia: bah, I've had over 5000 tunnels ;)
            
-
            13:13 < jrandom> but dm actually has helped find a bug in the exploratory pool code, so we will be building tunnels more often on 'random' peers
            
-
            13:14 < jrandom> (yay)
            
-
            13:14 < Meomia> ok
            
-
            13:14 < bla> jrandom: Does that also mean that now, in contrast to 0.4, every peers can at one time become your inbound gateway?
            
-
            13:14 < jrandom> yes, for exploratory tunnels
            
-
            13:15 < jrandom> client tunnels will only use peers in the 'fast' tier
            
-
            13:15 < bla> bla: Ok. The fact that client tunnels use only the fast peers is good: otherwise, we get the anon issue we discussed before
            
-
            13:16 < jrandom> and performance would suck otherwise ;)
            
-
            13:17 < jrandom> actually, that brings us in to 2) Next steps
            
-
            13:18 < jrandom> the big thing left for the 0.5 series is a bunch of strategies for ordering and/or filtering the peers used in tunnels
            
-
            13:18 < godmode0> jrandom can use nntp w i2p ?
            
-
            13:18 < jrandom> godmode0: there are two NNTP servers on i2p, yes.  see the forum
            
-
            13:19 < godmode0> jrandom ok i;m testing
            
-
            13:19 < godmode0> i can build my server too ?
            
-
            13:20 < jrandom> godmode0: we're in a meeting right now, but yes, you can run a server
            
-
            13:20 < godmode0> jrandom ok sorry
            
-
            13:20 < jrandom> np
            
-
            13:20 < jrandom> the posted strategies are basically aimed at improving anonymity, but there are a few other goals that we can balance in there
            
-
            13:21 < jrandom> perhaps we can find a way to integrate some of the AS paths into the selection, as bla suggested
            
-
            13:22 < jrandom> that can both improve (jurisdictional) anonymity, or if we try to stay within an AS (or two), that can improve performance
            
-
            13:22 < bla> jrandom: This basically is related to a paper by the Tor creators: http://theland.i2p/files/routing-zones.pdf
            
-
            13:22 < jrandom> aye
            
-
            13:23 < jrandom> there are a whole slew of different strategies people can use, and trying out new ones should be pretty easy
            
-
            13:24 < jrandom> we aren't going to spend months implementing everything we can think of, but merely provide the basics for what most people will need.  anyone who wants to add new ones are very much encouraged to help plug 'em in
            
-
            13:25 < jrandom> anyway, once the basics are in place, we'll be moving on to focus on the UDP transport for 0.6
            
-
            13:26 < jrandom> thats about all I have for 2) next steps, anyone have any comments/questions/concerns?
            
-
            13:26 < bla> Who where the ppl that started looking into I2P, again?
            
-
            13:26 < bla> It seems we haven't heard much from them, lately.
            
-
            13:27 < bla> s/into I2P/into UDP/
            
-
            13:27 < bla> sorry
            
-
            13:27 < jrandom> ah, mule has been sick, thogh I think detonate is making progress
            
-
            13:28 < jrandom> detonate: any news?
            
-
            13:29 < jrandom> or perhaps not ;)  
            
-
            13:30 < jrandom> ok, moving on to 3) azneti2p
            
-
            13:30 <+detonate> sorry
            
-
            13:30 <+detonate> i'm making progress
            
-
            13:30 <+detonate> i still need to finish the re-assembly side of things
            
-
            13:31 <+detonate> as far as splitting data into packets and sending it across in an orderly fashion, that works
            
-
            13:31 <+detonate> on to 3)
            
-
            13:31 < jrandom> wikked
            
-
            13:31 < godmode0> sorry step 2) i2p  has any problem with attacks ?
            
-
            13:31 < bla> detonate: Cool! Can you keep all of us posted on the forum?
            
-
            13:32 <+detonate> bla: sure
            
-
            13:32 < tracker> About azneti2p, look here: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 seems like downloading works, seeding not.
            
-
            13:32 < jrandom> godmode0: the different ordering strategies should let the user choose the impact of predecessor attacks
            
-
            13:33 < microsoft> whoever runs i2p.net should add more Enterprise Class Solutions buzzwords to the page.
            
-
            13:33 <+detonate> someone needs to make sure that new dht tracker isn't misbehaving as well, with respect to the azureus plugin
            
-
            13:33 < tracker> My local tests seem to prove this, I can download with azureus but not seed.
            
-
            13:34 < jrandom> hmm ok cool tracker, thanks - i know they updated a few things and pushed out b34 last night, but there may be more left to do, it seems
            
-
            13:34 < jrandom> detonate: good point
            
-
            13:35 < tracker> Good point detonate, I have DHT disabled as azureus dies after some hours whit 100% CPU usage when it's active.
            
-
            13:35  * jrandom would like to reiterate that the azneti2p plugin is still fairly early beta, and azureus' anonymity implications have not fully been audited
            
-
            13:36 < jrandom> while I'm sure they love having people test it out, those who need anonymity may want to be cautious 
            
-
            13:36 < tracker> On the other hand, i2p-bt works really well. Except that it doesn't close the tunnels, but that's not too bad IMHO.
            
-
            13:37 < jrandom> oh, thats still happening with you tracker?  i havent been able to reproduce that
            
-
            13:37 < jrandom> you're on the 0.1.7 rev, right?
            
-
            13:37 < tracker> Yes, I'm.
            
-
            13:38 < jrandom> ok cool, if it happens all the time for you I'd love to pick your brains after the meeting to help track down the cause
            
-
            13:39 < tracker> Maybe it's related to running it on XP instead of linux or unix. Closing the tunnel works with azureus, so I gues it is I2P-BT related.
            
-
            13:39 < jrandom> hmm right, i2p-bt uses SAM, while azureus uses the i2p SDK directly
            
-
            13:40 < tracker> Btw. I send you a bug-report on the forum. The timestamper is dies on the latest cvs-builds of I2P.
            
-
            13:40 < jrandom> ah cool, thanks, havent checked my PMs over there today
            
-
            13:41 < jrandom> on -5 or -4?  or earlier?
            
-
            13:42 < jrandom> ah, -4.  ok cool
            
-
            13:42 < jrandom> thanks, I'll get that fixed for 0.5.0.1
            
-
            13:42 < jrandom> ok, anyone have anything else for 3) azneti2p?
            
-
            13:43 < tracker> It's also happening on -5
            
-
            13:43 < jrandom> you have sntp server defined explicitly, right?
            
-
            13:44 < tracker> Yes. The 2 ones from our country.
            
-
            13:44 < jrandom> i just checked the source and the exception occurs if the # concurring servers (default = 3) is greater than the # of servers specified (new default has 3)
            
-
            13:44 < jrandom> ok cool, its a trivial fix to % # servers
            
-
            13:45 < jrandom> ok, if there's nothing else for azneti2p, moving on to good ol' fashioned 4) ???
            
-
            13:46 < jrandom> anyone else have something to bring up for the meeting?
            
-
            13:46 < tracker> Nice. I've just send you the log errors from the router when closing i2p-bt on the forum.
            
-
            13:47 < jrandom> 'k cool, thanks
            
-
            13:47 < cervantes> nothing to mention other than: nice work with the 0.5 rollout, looks like it'll kick ass once the bugs are ironed out
            
-
            13:48 < tracker> Yep, the latest CVS builds are really performin good over here.
            
-
            13:48 < jrandom> thanks, with your help as well as the rest of the 0.5-pre testers we were able to clean up a bunch of issues
            
-
            13:49 < jrandom> the performance has been better than i had expected, though still not as high throughput as before.  lots left to optimize though
            
-
            13:49 < cervantes> strangely the pre version were more stable...for me, but then, I was running them on a different machine ;-)
            
-
            13:49 < jrandom> (and these damn bugs to get reliability where it should be)
            
-
            13:50 < jrandom> heh well, yeah, but the -pre network was 5-7 routers, all insanely reliable on really really fast connections
            
-
            13:50 < cervantes> :)
            
-
            13:51 < cervantes> sign me up for the 0.6 pre test then :)
            
-
            13:51 < jrandom> heh
            
-
            13:51 < tracker> Maybe I should take part in the next pre network then. Providing a very unreliable and slow connection ;).
            
-
            13:51 < jrandom> the 0.6 migration will probably be even easier, I hope, as we'll just be able to add new router addresses to the routerInfo (UDP addresses)
            
-
            13:51 < jrandom> heh word
            
-
            13:51 < cervantes> I can put my 1TB file share online...
            
-
            13:52 < jrandom> we'll definitely need lots of help with the 0.6 testing, pulling in a whole variety of network setups
            
-
            13:52 < hobbs> ssh '~C' command is nifty
            
-
            13:52 < laberhorst> will this e another non comnpatible step?
            
-
            13:53 < Myo9> Anyone knows what nntp servers are up?
            
-
            13:53 < jrandom> laberhorst: no, 0.6 will be backwards compatible
            
-
            13:53 < jrandom> Myo9: dunno, they might be up and just be bitten by the 0.5-0 bugs
            
-
            13:54 < jrandom> the 0.5.0.1 rev should fix a lot of issues, and once its out, upgrading will be highly recommended
            
-
            13:54 < laberhorst> so just built a test 0.6 and put it to testers
            
-
            13:54 < cervantes> we can make BT traffic use only outdated routers...that will encourage people to upgrade ;-)
            
-
            13:54 < laberhorst> so big upgrade party tomorrow
            
-
            13:54 < jrandom> there'll be an announcement on the forum and the list when its ready
            
-
            13:54 < jrandom> right laberhorst 
            
-
            13:54 < jrandom> heh cervantes ;)
            
-
            13:55 < laberhorst> *being keen on testing for you*
            
-
            13:55 < jrandom> BT performance has been pretty good on 0.5, I've seen lots of successful large file transfers on the trackers
            
-
            13:55 < laberhorst> pload rate:    8.85 kB/s
            
-
            13:55 < jrandom> (and irc hasn't been affected as it was before, beyond the problems we've been having with duck's tunnel)
            
-
            13:55 < tracker> Depends on what you call large ;)
            
-
            13:56 < jrandom> tracker: i'm thinking of a particular 874MB file that has a bunch of successful downloads ;)
            
-
            13:56 < jrandom> but its true, thats small to some 
            
-
            13:56 < laberhorst> just good old porn
            
-
            13:56 < laberhorst> i assume ;-)
            
-
            13:57 < laberhorst> lets hope from tomorrow on, my router won't participate in >3000 tunnels
            
-
            13:57 < tracker> Ok, that's large.
            
-
            13:57 < laberhorst> or, if so, the network IS large
            
-
            13:57 < jrandom> heh laberhorst 
            
-
            13:58 < jrandom> ok, anyone have anything else for the meeting?
            
-
            13:58 < laberhorst> btw, if participate in >3000 a synonym for a good reliable router in i2p with fast connection?
            
-
            13:58 <+detonate> i'm putting boondock saints up after i grab house tonight :)
            
-
            13:59 <+detonate> that'll be a good 4.1gb :)
            
-
            13:59  * laberhorst just wants to thank the developers for fast bug squashing
            
-
            13:59 <+detonate> there seems to be lots of demand
            
-
            13:59 < laberhorst> oh, some DVD images are here, to
            
-
            13:59 < hobbs> detonate: ooh, right. House. :)
            
-
            13:59 < tracker> cervantes, did you already upgrade to phpBB 2.0.12
            
-
            13:59 < laberhorst> but wait till 0.5.0.1 is out
            
-
            13:59 <+detonate> should give 0.5.0.1 a good shakedown too
            
-
            14:00 <+detonate> yeah
            
-
            14:00 <+detonate> i intend to
            
-
            14:00 < jrandom> only people who already own legal copies of those files should download them, of course.  thats just for testing
            
-
            14:00 < jrandom> *cough*
            
-
            14:00 < tracker> rofl
            
-
            14:01  * jrandom notes mpaa.i2p
            
-
            14:01 <+detonate> heh
            
-
            14:01 < laberhorst> oh, i can built iso images from debian, fedora, suse, pictures I made,...
            
-
            14:01 < laberhorst> so a lot of legal material
            
-
            14:01 < laberhorst> if you just want to test, /dev/random is VERY large
            
-
            14:01 < Ragnarok> not always
            
-
            14:02 < laberhorst> btw, for lonely weekends: cat /dev/random | grep linux :-)
            
-
            14:02 < jrandom> heh
            
-
            14:02 < frosk> /dev/random runs empty all the time, i prefer /dev/urandom :)
            
-
            14:02 < frosk> or the new, improved /dev/jrandom
            
-
            14:02 < jrandom> nah, that dumps core all the time
            
-
            14:03 < jrandom> and needs its nightly rest
            
-
            14:03 < Ragnarok> what's the best way to generate entropy for /dev/random?
            
-
            14:03 < laberhorst> we should really built the "get jrandom a few beers" fund
            
-
            14:03 < frosk> call it rest or entropy gathering :)
            
-
            14:03 < hobbs> Ragnarok: Depends on what you really mean. Getting a hardware RNG would be more or less the "best" way :)
            
-
            14:03 < jrandom> Ragnarok: depends on your OS (and whether you have hardware ;)
            
-
            14:04 < tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Allways nice ;)
            
-
            14:04 < jrandom> we'll actually be bundling in a fortuna implementation one of these builds, and will need to dig around for various entropy sources
            
-
            14:04 < Ragnarok> without hardware :P
            
-
            14:04 < susi23> . o O ( I thought somebody using i2p knows why he should not use /dev/urandom )
            
-
            14:05 < cervantes> tracker: the security exploits covered in 2.0.12 my mod_rocinante inadvertantly fixes, so I haven't bothered to upgrade yet
            
-
            14:05 < hobbs> susi23: when it's just for mischief, I think it's alright ;)
            
-
            14:05 < ant> <Nolar> who here does the python BT port?
            
-
            14:05 < jrandom> Nolar: that'd be duck
            
-
            14:06  * duck whistles
            
-
            14:06 < ant> <Nolar> duck:  why did you guys change the request block size to 128k ?
            
-
            14:06 < susi23> . o O ( next one suggests: while true; do echo $RANDOM >> largefile; done )
            
-
            14:06 < ant> <Nolar> that's why az cant seed to you
            
-
            14:06 < tracker> cervantes: Ok
            
-
            14:06 < ant> <Nolar> we block requests > 64k
            
-
            14:06 < laberhorst> hell, i need more mp3
            
-
            14:06 < frosk> susi23: for grepping for linux on an idle evening, /dev/urandom is just fine :)
            
-
            14:07 < jrandom> ah, did you always?  iirc i2p-bt has used 128k for a while
            
-
            14:08 < ant> <Nolar> yup, been there since the beginning :)
            
-
            14:08 < ant> <Nolar> any reason 128 is used?
            
-
            14:08 < ant> * duck looks through cvs log
            
-
            14:08 < jrandom> keeps the pipeline filled, i2p has some lag ;)
            
-
            14:08 < jrandom> with 32KB, thats essentially a fixed window size of 1
            
-
            14:09 < jrandom> so each message blocks for an ACK, while 128KB allows 4 messages to fly in the rtt
            
-
            14:09 <@duck> right, maximum allowed slice size according to the BT specs
            
-
            14:09 < ant> <Nolar> well, there are two ways do deal with this:  1) we raise the limit to 128k on our side, or 2) you simply pipeline more requests
            
-
            14:09 < cervantes> i2pbt is a little snappier than it used to be...perhaps you can afford to reduce it...
            
-
            14:10 <@duck> schni, schna, schnappi
            
-
            14:10 < ant> <Nolar> so, instread of making a single 128k request, send out two 64k ones for example
            
-
            14:10 < hobbs> duck: haha... that thing has gotten around the world.
            
-
            14:10 <@duck> why do you block 128k?
            
-
            14:11 < cervantes> *shudder* europop
            
-
            14:11 < laberhorst> duck: pls. be quiet OR i shoot you down!
            
-
            14:11 < tracker> Sometimes I regret that I learned german some years ago...
            
-
            14:11 < laberhorst> no europop, really not POP
            
-
            14:11  * cervantes orders the UK to repel borders before a song like that enters the charts
            
-
            14:11 < laberhorst> tracker: don't care, its ok
            
-
            14:12 < ant> <duck> its now (2^17)-13
            
-
            14:12 < ant> <Nolar> duck: well, the limit has been there for a while, but one good reason is that 128K blocks take a while to upload.....16KB (our default) allows for finer request control
            
-
            14:12 < ant> <duck> 13 bytes being the bittorrent command length
            
-
            14:12 < ant> <duck> would have no problem to (2^16)-13
            
-
            14:12 < laberhorst> some music is really ridiculous, but real industrial music, boh, no
            
-
            14:13 < ant> <duck> or go back to the default?
            
-
            14:13 < jrandom> reducing it to 64KB seems the simplest (is that a cli param atm?)
            
-
            14:13 < ant> <duck> --download_slice_size
            
-
            14:14 < ant> <Nolar> well, my question is, do you have a compelling reason for sticking to 128K blocks, which seems a bit large to me, especially for i2p
            
-
            14:14 < ant> <Nolar> rather than just pipelining multiplpe smaller requests?
            
-
            14:14 < ant> <duck> I have no reason.
            
-
            14:14 < tracker> laberhorst: Sometimes I catch some of the german channels via satellite. Especially viva and that "Theater Kanal" are really gruesome...
            
-
            14:15 < ant> <Nolar> one problem with large blocks is that once i choke you, i still have to finish sending that 128k chunk
            
-
            14:15 < jrandom> I don't recall whether the vanilla bt knows how to pipeline, but it should be simple enough (especially since i'm not doing it ;)
            
-
            14:15 < ant> <Nolar> which can take a while
            
-
            14:15 < laberhorst> tracker: viva is only interesting while "hard rock" time, all other times "please ignore", and theater, i don't know
            
-
            14:15 < jrandom> with i2p, 128KB isn't really that large, since there's an inherent lag on the order of seconds
            
-
            14:15 < ant> <Nolar> which can mess with the chunk/unchoke 
            
-
            14:16 <@duck> jrandom: does it still make sense to subtract the bittorrent 13 byte overhead so it fits in a sam message?
            
-
            14:16 < jrandom> duck: nah, since the streaming lib already reduces it further into 16KB messages, so just have it be 64KB
            
-
            14:17 <@duck> ok, 2**16 it is
            
-
            14:17 < jrandom> (and then the tunnels break those 16KB messages into 996 byte fragments..)
            
-
            14:17 < ant> <Nolar> the problem with 128k, is that if i'm uploading at say 12 k/s, then it'll take me 10+ seconds to finish that block
            
-
            14:18 < cervantes> wow that's almost as long as the lag on irc...
            
-
            14:18 < jrandom> which is 1-10 RTTs (while on the normal net, 10-500)
            
-
            14:18 <+detonate> i was all set to use 512K blocks
            
-
            14:18 < ant> <Nolar> you might also experiment with pipelinng 16kb blocks
            
-
            14:18 < jrandom> heh
            
-
            14:18 <+detonate> so 64 is preferred?
            
-
            14:19 < ant> <Nolar> all bt clients afiak use 16KB blocks
            
-
            14:19 < ant> <duck> fixed in CVS;
            
-
            14:19 < jrandom> wikked, thanks duck!  (and Nolar!)
            
-
            14:19 < ant> <duck> expect it to appear in the 0.1.8 release together with some sam i2cp tuning
            
-
            14:19 < tracker> laberhorst: It's complete name is "ZDF Theater" or so. And well they say they send a high level cultural program. I really hope that what they send isn't the best the german culture can offer ;)
            
-
            14:19 < jrandom> ok, heh, I just remembered we're still in a meeting
            
-
            14:19 < jrandom> anyone else have anything for the meeting?
            
-
            14:20 < ant> <Nolar> so if we want a 128k chunk, we just make 8 simult requests
            
-
            14:20 < susi23> . o O ( and discard the 448 left bytes? )
            
-
            14:20 < jrandom> right right
            
-
            14:20 < laberhorst> tracker: oh, that is small side channel... arte or 3sat is really more interesting
            
-
            14:20 < laberhorst> and arte is german/french :-)
            
-
            14:20 < ant> <Nolar> if the uploader can fill such a request, all 128k should be pushed into the i2p pipe stream
            
-
            14:20 < jrandom> cool
            
-
            14:21 < cervantes> . o O ( wonders why he can hear everything susi is thinking )
            
-
            14:21 < ant> <Nolar> so, it might be worth experimenting with 16KB vs 32KB vs 64KB blocks sizes
            
-
            14:21 < jrandom> aye
            
-
            14:21 < jrandom> as long as its pipelined, i2p doesnt care
            
-
            14:21 < ant> <Nolar> great
            
-
            14:22 < jrandom> the speed at 16KB without pipelines is pretty bad though, or at least it used to be
            
-
            14:22 < tracker> laberhorst: Ok, I'll try if I can catch arte in the next days...
            
-
            14:22 < ant> <duck> I suggest leaving this tweaking for 0.2
            
-
            14:22 < ant> <duck> since it will include the bittorrent 3.9.1 improvements
            
-
            14:22 < jrandom> yeah, DTSTTCPW
            
-
            14:22 < susi23> . o O ( oh thats easy... people are so predictable... )
            
-
            14:23 < ant> <duck> which might completely restructure the network code
            
-
            14:23 < cervantes> http://www.gavelstore.com
            
-
            14:24 < jrandom> ok, I think thats it for the moment, people should check the list and the site in a few hours as the 0.5.0.1 rev will be coming out soon
            
-
            14:24 < ant> <Nolar> ya, i can see how single 16kb requests would be slow
            
-
            14:24  * jrandom downloads a gavel
            
-
            14:24  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting131.html b/www.i2p2/pages/meeting131.html
deleted file mode 100644
index 66238ef5..00000000
--- a/www.i2p2/pages/meeting131.html
+++ /dev/null
@@ -1,372 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 131{% endblock %}
-{% block content %}
            I2P dev meeting, March 1, 2005
            
-
            
-
            13:05 <@jrandom> 0) hi
            
-
            13:05 <@jrandom> 1) 0.5.0.1
            
-
            13:05 <@jrandom> 2) roadmap
            
-
            13:05 <@jrandom> 3) addressbook editor and config
            
-
            13:05 <@jrandom> 4) i2p-bt
            
-
            13:05 <@jrandom> 5) ???
            
-
            13:05 <@jrandom> 0) hi
            
-
            13:05  * jrandom waves
            
-
            13:05 <@duck> hi
            
-
            13:05 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000616.html
            
-
            13:05 < null> hi
            
-
            13:05 <@jrandom> (yeah, i'm late this week, off with my head)
            
-
            13:06 <@jrandom> while y'all speedreaders dig through that, perhaps we can jump into 1) 0.5.0.1
            
-
            13:07 <@jrandom> 0.5.0.1 is out, and gets rid of the most ovious bugs from 0.5, but as we've seen, there's still work to be done
            
-
            13:07 <@jrandom> (current cvs stands at 0.5.0.1-7, I expect at least -8 or -9 before we hit 0.5.0.2)
            
-
            13:07 <+ugha2p> Hi.
            
-
            13:08 <+ugha2p> Does CVS HEAD fix that 100% CPU issue?
            
-
            13:08 <@jrandom> yes, -7 should get the last remnants of it
            
-
            13:08 <@duck> Does CVS HEAD fix that OOM issue?
            
-
            13:08 <+detonate> hi
            
-
            13:08 <@jrandom> no, the OOM is still being tracked down
            
-
            13:09 <@jrandom> actually... is there a Connelly in the house?
            
-
            13:09 < ant> <jrandom> nope
            
-
            13:09 <@jrandom> bugger
            
-
            13:09 <+ugha2p> jrandom must be going crazy, he is having a dialogue with himself.
            
-
            13:09 <@jrandom> ok, well, we can see what will be done to get rid of the OOM.  its definitely a show stopper, so there won't be a release until its resolved one way or another
            
-
            13:10 <+detonate> just in time for the meeting
            
-
            13:11 <@jrandom> thats about all i have to say for the 0.5.0.1 stuff - anyone else have anything they want to mention/ask/discuss?
            
-
            13:12 <+ugha2p> jrandom: Err, I haven't actually seen the CPU issue with 0.5.0.1, but it happened twice when I tried 0.5.0.1-5. Am I missing something?
            
-
            13:12 <+ugha2p> I downgraded back to 0.5.0.1 as a result.
            
-
            13:13 <+detonate> i had a question, the shutdown seems to take a very long time, and the memory usage spikes by about 40mb during that time
            
-
            13:13 <+detonate> was wondering if you knew why
            
-
            13:14 <+detonate> the immediate one, obviously
            
-
            13:14 <@jrandom> it could happen with 0.5.0.1, you just hadn't run into it.  
            
-
            13:14 <@jrandom> (its not a common occurrence, and it only hits some people in odd situations)
            
-
            13:14 <@jrandom> detonate: very long, as in, more than the usual 11-12 minutes?
            
-
            13:14 <+ugha2p> Well, it hit me twice during a 8-hour period.
            
-
            13:15 <+detonate> once all the participating tunnels are gone
            
-
            13:15 <+ugha2p> jrandom: Is it supposed to use up all the CPU and lose all the leases until restarted when that bug occurs?
            
-
            13:16 <@jrandom> ugha2p: thats a typical result from the bug, yes
            
-
            13:16 <+detonate> hmm
            
-
            13:17 <@jrandom> (it happens when the # of tunnel build requests consume sufficient CPU to exceed the time to satisfy a request, causing an additional request to be queued up, etc)
            
-
            13:17 <+ugha2p> Must have been an extreme coincidence that it only happened to me while on 0.5.0.1-5.
            
-
            13:18 <@jrandom> ugha2p: its happened to some people repeatably on 0.5.0.1-0, but is fixed in -7.  you can stick with -0 if you prefer, of course
            
-
            13:18 < cervantes> it was a wonderous godsend
            
-
            13:18 <+ugha2p> jrandom: I'll try out -7.
            
-
            13:18 <@jrandom> cool
            
-
            13:19 <+ugha2p> Although I'm already feeling guilty for giving a bumpy ride to the wiki users so far. :)
            
-
            13:20 <+ugha2p> One more thing, have you documented the bulk/interactive tunnel types anywhere?
            
-
            13:20 <+ugha2p> (Except for the source ;)
            
-
            13:20 <@jrandom> in the changelog.  the only difference is a max window size of 1 message
            
-
            13:20 <+ugha2p> Oh, okay.
            
-
            13:21 <@jrandom> ok, anything else on 0.5.0.1, or shall we move on over to 2) roadmap?
            
-
            13:21 <@duck> move on!
            
-
            13:21 <@jrandom> consider us moved
            
-
            13:22 <@jrandom> roadmap updated.  'n stuff.  see the page for details
            
-
            13:22 < cervantes> eeh, duck ankle bites
            
-
            13:23 <@jrandom> i'm thinking of pushing some of the strategies from 0.5.1 to 0.6.1 (so we get UDP faster), but we'll see
            
-
            13:23 <@jrandom> anyone have any questions/comments/concerns/frisbees?
            
-
            13:23 <+detonate> have you heard from mule lately?
            
-
            13:23 <+detonate> speaking of udp
            
-
            13:24 <@jrandom> nope, he was fairly ill last i heard from 'im
            
-
            13:24 <+detonate> :/
            
-
            13:24 < jnymo> udp would kick ass
            
-
            13:25 <@jrandom> s/would/will/
            
-
            13:25 <@jrandom> hopefully he's off having fun instead though :)
            
-
            13:25 <+ugha2p> jrandom: What kind of changes would the bandwidth and performance tuning include?
            
-
            13:26 < jnymo> so, udp basically means connectionless.. which means.. bigger network, right
            
-
            13:26 <+detonate> udp introduces all sorts of difficulties along with that
            
-
            13:26 <@jrandom> ugha2p: batching the tunnel message fragments to fit better into the fixed 1024byte tunnel messages, adding per-pool bw throttles, etc
            
-
            13:27 <+detonate> but yeah
            
-
            13:27 <@jrandom> detonate: it won't be so bad, the token bucket scheme we have now can handle async requests without a problem
            
-
            13:27 <@jrandom> (we just obviously wouldn't use the BandwidthLimitedOutputStream, but would ask the FIFOBandwidthLimiter to allocate K bytes)
            
-
            13:27 <+ugha2p> Would the first one really make much difference? Per-pool throttling doesn't sound urgent.
            
-
            13:28 <+detonate> that's good then
            
-
            13:28 <@jrandom> ugha2p: likely, yes.  you can see the exact #s involved by going to /oldstats.jsp#tunnel.smallFragments
            
-
            13:29 < bla> detonate: How's progress on the reassembly?
            
-
            13:29 <+detonate> really stalled
            
-
            13:30 <@jrandom> ugha2p: though its largely dependent upon the type of activity, of course.  chatty comm has more to gain, but bulk comm already fills the fragments fully
            
-
            13:30 <+ugha2p> jrandom: Ok.
            
-
            13:30 <+ugha2p> Right.
            
-
            13:31 <+detonate> i stopped working on it completely and started working on the addressbook-editor
            
-
            13:31 <+detonate> there's probably a really efficient, well-researched way of doing that sort of thing, but i haven't come across it 
            
-
            13:31 < jnymo> will upd mean people behind nats can get through now?
            
-
            13:31 <@jrandom> some jnymo 
            
-
            13:31 < jnymo> and use i2p?
            
-
            13:32 <@jrandom> but first we need to get it to work with udp at all, then we start adding the firewall/nat punching, then the PMTU, etc
            
-
            13:32 < jnymo> that'll be a boon
            
-
            13:33 <+detonate> of course if anyone has suggestions on what to do, i'd appreciate them
            
-
            13:33 <+ugha2p> jrandom: How would UDP help people behind NATs?
            
-
            13:34 < bla> detonate: TCP (on the regular net) does reassembly. Can those concepts be carried over to the I2P UDP reassembly?
            
-
            13:34 <+detonate> i haven't looked into how tcp does it
            
-
            13:34 <@jrandom> ugha2p: there's a lot of trickery we can pull off with consistent port #s, etc.  lots of code & docs out there
            
-
            13:35 <@jrandom> bla: we'll certainly be using some level of UDP reassembly along tcp-SACK lines
            
-
            13:35 <+detonate> but if you're going to handle most of what tcp does, you might as well go the NIO route and actually use it
            
-
            13:35 <+detonate> saving the hassle
            
-
            13:35 <@jrandom> no, there's substantial reason for why we do want both some reassembly/retransmission and not tcp
            
-
            13:36 <+detonate> well, the threads thing
            
-
            13:36 <@jrandom> the transport layer will not need to be fully reliable or ordered, just semireliable and unordered
            
-
            13:37 <+ugha2p> Can we also expect a drop in memory usage because of fewer threads?
            
-
            13:37 <@jrandom> yes
            
-
            13:37 <+ugha2p> A significant drop
            
-
            13:38 <+ugha2p> ?
            
-
            13:38 <@jrandom> substantially.  (as well as a drop in memory usage, based off whatever the current OOM is coming from ;)
            
-
            13:38 <+ugha2p> Right.
            
-
            13:39 <@jrandom> ok, anything else on 2) roadmap?
            
-
            13:39 < bla> jrandom: Yeah.
            
-
            13:40 < bla> jrandom: Will detonate be doing the UDP stuff now? Or else, who will?
            
-
            13:40 <@jrandom> its a team effort for all who can contribute :)
            
-
            13:40 <+detonate> heh, i plan on working on udp stuff more, it's less boring than watching tv
            
-
            13:41 <@jrandom> heh w3wt
            
-
            13:41 < bla> jrandom: I understand. But for a moment it looked like detonate dropped the project ;)
            
-
            13:42 <@jrandom> its on the roadmap, it will be done
            
-
            13:42 <+detonate> sorry for the confusion
            
-
            13:43 <@jrandom> ok anyone else have anything on 2) roadmap, or shall we mosey on over to 3) addressbook stuff?
            
-
            13:44 <@jrandom> ok, detonate wanna give us an overview/status report on the editor?
            
-
            13:45 < bla> detonate: (np)
            
-
            13:45 <+detonate> ok
            
-
            13:45 <+detonate> the current state of the editor is here:
            
-
            13:45 <+detonate> http://detonate.i2p/addressbook-editor/current-state.html
            
-
            13:45 <+detonate> it still doesn't do any actual editing
            
-
            13:45 <+detonate> and currently i'm working on the table at the bottom
            
-
            13:46 <+detonate> i need to read a couple chapters of my jsp book, but after that, you should be able to use it to add/modify entries in the hosts.txt and subscriptions quite easily
            
-
            13:47 <+detonate> i took a break from it the last 24 hours or so, so that's why there hasn't been much progress
            
-
            13:47 <+detonate> that's pretty much all
            
-
            13:47 <@jrandom> w3wt
            
-
            13:48 < bla> detonate: Looks good
            
-
            13:49 <@jrandom> yeah, mos' def', I'm looking forward to a way to manage the entries /other/ than just hcaking the hosts file
            
-
            13:49 <+detonate> thanks
            
-
            13:49 <+detonate> that's the first time i've used jsp for anything
            
-
            13:50 <@jrandom> cool
            
-
            13:51 <@jrandom> oh, i hadn't realized there was the overlap here for subscription management - perhaps smeghead's work can fit in with this as well
            
-
            13:51 <@jrandom> smeghead: you 'round?  you seen this yet?
            
-
            13:51 < jnymo> detonate: will there be collision detection and what not?
            
-
            13:51 <@smeghead> actually i only hashed out some skeleton code on the addressbook console, nothing useful
            
-
            13:51 <+detonate> yeah, i got tired of that, thank duck for suggesting the idea :)
            
-
            13:51 <@smeghead> i got sidetracked on the TrustedUpdate thingy
            
-
            13:52 <@jrandom> ah cool :)
            
-
            13:53  * jrandom likes sidetracking to add new features 
            
-
            13:53 < bla> smeghead: You mean 1-click updates of I2P from _within_ I2P?
            
-
            13:53 <@smeghead> so luck, not laziness (at least this time :)
            
-
            13:53 < cervantes2p> bla: 2 click at least ;-)
            
-
            13:54 <@jrandom> bah, we can get it down to 1 (reject if bad sig/invalid/etc ;)
            
-
            13:54 <+detonate> yeah, there will be collision detection, that's currently what i'm working on
            
-
            13:54 <@jrandom> detonate: doesnt the addressbook itself take care of that?
            
-
            13:54 <@jrandom> detonate: i thought what you're doing just edited the files?  
            
-
            13:55 <@jrandom> (the files will be uniq'ed by the addressbook)
            
-
            13:55 <+detonate> i mean, showing you the collisions from the logs and handling that
            
-
            13:55 <@jrandom> ah
            
-
            13:55 <@jrandom> ok cool
            
-
            13:55 <+detonate> i assume that's what jnymo is talking about
            
-
            13:55 < Ragnarok> hm, is there anything I can do to make your life easier? :)
            
-
            13:55 <+detonate> so you can say "replace entry" with the colliding one of your choice
            
-
            13:55 <@jrandom> nice!
            
-
            13:58 <@jrandom> Ragnarok: iirc detonate was able to parse out the logfile pretty easily.  do you forsee that format changing?
            
-
            13:58 < jnymo> detonate: pretty much, yea
            
-
            13:58 < jnymo> now, is this tied into i2p tightly?  How easily can i put a link+key from my browser into my address book?
            
-
            13:59 <+detonate> yeah, don't change the format, that'll break everything
            
-
            13:59 < Ragnarok> the format is highly unlikely to change
            
-
            14:00 < Ragnarok> though more things may get logged in the future
            
-
            14:00 <@jrandom> jnymo: the eepproxy doesn't have any hooks into detonate's editor atm, but we could add something down the road
            
-
            14:00 <+detonate> although if you modified the Conflict lines, that would make them easier to parse
            
-
            14:00 < cervantes2p> possibly something my firefox plugin could do
            
-
            14:00 <+detonate> right now there are lots of human readable words that get in the way
            
-
            14:00 < Ragnarok> modify how?
            
-
            14:00 <@jrandom> (for instance, perhaps i2paddresshelper might redirect to an editor page)
            
-
            14:00 < cervantes2p> "click here to add this to your addressbook"
            
-
            14:00 < Ragnarok> ah...  I want to be nice to the humans, though
            
-
            14:00 <+detonate> <date>=<host>=<source>=<new destination> would be superior
            
-
            14:01 <@jrandom> cervantes2p: that going to work like google's page rewriter?  :)
            
-
            14:01 <+detonate> well, that's what the addressbook-editor is for :)
            
-
            14:01 <+detonate> it's really not an issue, i've got it covered
            
-
            14:01 < cervantes2p> jrandom: nah...just have it in the link context menu
            
-
            14:01 <@jrandom> ooOOoo
            
-
            14:01 <+detonate> as long as nothing changes radically, things should keep working smoothly
            
-
            14:02 < cervantes2p> of course I could add a rewriter...but that's just breaks people's page layouts ;-)
            
-
            14:02 <+detonate> oh, one thing you could do
            
-
            14:02 <+detonate> because it conflicts with what i do
            
-
            14:02 <+detonate> make sure all the entries for the hostnames are all-lowercase
            
-
            14:02 <+detonate> since Legion.i2p is in there
            
-
            14:02 < cervantes2p> I do want to add a "non i2p link highlighter"
            
-
            14:02 <+detonate> and i run them all through toLowercase()
            
-
            14:02 <@jrandom> ah that'd be neat cervantes2p 
            
-
            14:03 <@jrandom> (be sure to only toLowercase the names, base64 is case sensitive ;)
            
-
            14:03 <+detonate> yeah, only the names
            
-
            14:04 < jnymo> context menu would be ideal
            
-
            14:04 <@jrandom> (dont forget the flying ponies!)
            
-
            14:04 < Ragnarok> I've made address comparisons non-case sensitive in my local branch... I should commit that...
            
-
            14:04 <+detonate> /make all the hostnames lowercase
            
-
            14:04 <+detonate>                 pair[0] = pair[0].toLowerCase();
            
-
            14:05 <+detonate> there, in black and white
            
-
            14:05 <+detonate> it just does the hostnames
            
-
            14:05 <@jrandom> aye Ragnarok, give us the goods :)
            
-
            14:05 < jnymo> why do i always feel i'm the one riding the flying ponies :(
            
-
            14:06 <@jrandom> thats 'cause you're hoggin' 'em jnymo ;)
            
-
            14:06 < cervantes2p> jnymo: don't discuss your domestic "arrangements" in a meeting
            
-
            14:07 <@jrandom> ok, lots of cool stuff going on within the addressbook & editor.  any eta on when we can beta things detonate?  (this week, next week, etc)
            
-
            14:07 < jnymo> heh
            
-
            14:07 <+detonate> well, as soon as you can get it to work in jetty, you can put it in beta i think
            
-
            14:07  * jnymo pulls out his p32-space-modulator
            
-
            14:07 <@jrandom> it works in jetty
            
-
            14:07 <+detonate> i have no idea how to get netbeans to precompile them and put them in the war
            
-
            14:08 <+detonate> as long as people don't change the names of the files in config.txt, it should work hopefully without bugs
            
-
            14:08 <@jrandom> ok, we can work you through ant to take care of things
            
-
            14:08 <+detonate> ok
            
-
            14:08 <+detonate> cool
            
-
            14:08 < cervantes2p> detonate: do what I did, take jrandom's code....strip out everything you don't need, crowbar in your own code and run the ant build script ;-)
            
-
            14:08 <@jrandom> heh
            
-
            14:09 <@smeghead> detonate: i know a thing or two about ant, yell if ya get stuck
            
-
            14:09 <+detonate> feel free to add it to your release
            
-
            14:09 <+detonate> if you know how to do that
            
-
            14:09 < MichElle> s/you don't need//
            
-
            14:09 < Ragnarok> addressbook has a very simple build script, if you want to take a look at that
            
-
            14:10 <+detonate> i need the section that precompiles jsps
            
-
            14:10 <+detonate> that's missing from mine
            
-
            14:10 <+detonate> although it does compile them, it just doesn't merge them, and the entry to test compile them isn't in build.xml
            
-
            14:10 <@jrandom> detonate: check out the precompilejsp targets in routerconsole, that'll get you started
            
-
            14:10 <+detonate> and i need to figure out where to put -source 1.3 etc in
            
-
            14:10 <@jrandom> (and the <war> task)
            
-
            14:11 <+detonate> yeah, we can sort things out later this evening
            
-
            14:11 <@jrandom> aye
            
-
            14:11 < cervantes> yup that's how I managed it...and I don't know ANY java or jsp ;-)
            
-
            14:11 <@jrandom> ok, if there's nothing more on 3) addressbook stuff, moving on to 4) bt stuff
            
-
            14:12 <@jrandom> duck/smeghead: wanna give us an update?
            
-
            14:12 <@duck> k
            
-
            14:12 <@duck> last week we spoke with Nolar from Azureus about fixing some compatibility problems
            
-
            14:12 <@duck> with the release of 0.1.8 as result
            
-
            14:12 <@duck> this week has been mostly about communication
            
-
            14:12 <@duck> with fellow developers, with forum admins and with users
            
-
            14:13 <+detonate> does anyone know if the aznet plugin can host torrents again?
            
-
            14:13 <@duck> the FAQ has been updated based on input from the forum, thanks for those who contributed
            
-
            14:13 <@duck> also there has been some miscommunication and confusion
            
-
            14:13 <@jrandom> detonate: word on the street is yes
            
-
            14:13 <@duck> like legions spork
            
-
            14:13 <+detonate> excellent
            
-
            14:13 <@duck> I believe that changing the name of it will prevent further problems there
            
-
            14:13 <@duck> .
            
-
            14:14 <@jrandom> r0xor duck
            
-
            14:14  * MichElle applauds duck
            
-
            14:14 < MichElle> duck: you work very hard
            
-
            14:14 < jnymo> yea, why not i2p-bt_extractor or some shit?
            
-
            14:15 <@jrandom> any word on the later 0.2 stuff, or is that to be addressed after 0.5.0.2/etc?
            
-
            14:15 <@smeghead> don't applaud yet, you don't know what we're naming it >;-}
            
-
            14:15 <@jrandom> heh
            
-
            14:15  * jnymo claps
            
-
            14:15 <@duck> tell us!
            
-
            14:15 <@jrandom> i2p-flying-pony-torrent
            
-
            14:16 <+detonate> heh, are we hiding it now by changing the name?
            
-
            14:16 < MichElle> again with the ponies
            
-
            14:16 <@smeghead> it's top-secret for now, we don't want to get sued
            
-
            14:16 < jnymo> what a debocle
            
-
            14:17  * bla makes sign for MPAA: "Sue me, if you can..."
            
-
            14:17 <@smeghead> duck and i have agreed 0.2 will be the first version with the new name
            
-
            14:17 <+detonate> i2p-communism
            
-
            14:17 <@duck> released spring 2006
            
-
            14:17 <@jrandom> heh
            
-
            14:17 <@duck> .
            
-
            14:18 <@smeghead> based on my current workload and the fact that i'm moving this week, i don't expect to get any hacking done on 0.2 for a few days, i don't know what duck's near-term schedule is like
            
-
            14:18 <@duck> been doing 8 hours of C++ pointer fixing
            
-
            14:19 <@duck> so not much here either :)
            
-
            14:19 <@jrandom> 'k but something we can perhaps look forward to along side 0.6 (or 0.5.1 if we're lucky?)
            
-
            14:19 <@jrandom> yikes, fun fun fun
            
-
            14:19 <@duck> before 2.0 atleast
            
-
            14:19 <@smeghead> i'd estimate a month or so, just a wild guess, what do you think duck
            
-
            14:19 <@duck> yeah
            
-
            14:19 <@jrandom> cool
            
-
            14:19 <@duck> ballpark
            
-
            14:20 <@smeghead> the thing is we'd like to wait until the release of the official BT 4.0
            
-
            14:20 <@jrandom> its ok, we know how schedules go ;)
            
-
            14:20 <@smeghead> so we can sync 0.2 up-to-date with that
            
-
            14:20 < MichElle> duck has many things on his plate, indeed
            
-
            14:20 <@smeghead> 4.0 appears imminent
            
-
            14:20 <@jrandom> ah, really smeghead?  cool
            
-
            14:20 <@duck> smeghead: that is just the official excuse :)
            
-
            14:20 < MichElle> but he is a hard worker
            
-
            14:21 <@duck> I am for 5) ???
            
-
            14:21 <@jrandom> almost there... 
            
-
            14:21 <@jrandom> legion: any updates on your bt client?  progress, etc?
            
-
            14:21 <@smeghead> source code?
            
-
            14:22 <@smeghead> (in a zip, not an .exe)
            
-
            14:22 < cervantes> so the next wave of releases then
            
-
            14:22 <@jrandom> hmm, legion seems to be idle, ok perhaps we can get an update later
            
-
            14:22 < cervantes2p> damn huge lag
            
-
            14:23 <@jrandom> so, movin' on over to 5) ???
            
-
            14:23 < cervantes> *ahem* w00t
            
-
            14:23 <@jrandom> cervantes2p: nah, you're just slow ;)
            
-
            14:23 <@jrandom> ok, anyone else have anything to bring up?
            
-
            14:23 < cervantes2p> I said those things like 5 minutes ago
            
-
            14:23 <+ugha2p> jrandom: The mailing list footer still uses the i2p.dnsalias.net address. Perhaps you should update it to reflect dev.i2p.net? :)
            
-
            14:23  * cervantes2p feeds his router's hamster
            
-
            14:24 <@jrandom> ah, yeah, prolly ugha2p 
            
-
            14:24  * jrandom has some sysadmin work i've been avoiding for a while (like, oh, moving things to the new srever...)
            
-
            14:24 < MichElle> I have a concern
            
-
            14:24 < MichElle> regarding transparency
            
-
            14:24 <@jrandom> sup MichElle?
            
-
            14:25 < MichElle> for purposes of full transparency, I will declare here that identiguy has suggested jrandom could in fact be employed by the NSA
            
-
            14:25 <+detonate> oh, i've noticed 190 routers, how close are we to the thread limit right now?
            
-
            14:25  * jnymo wonders about other help people can do
            
-
            14:25 < jnymo> (still looking into the php thing, duck ;)
            
-
            14:25 <@jrandom> heh MichElle
            
-
            14:25 < MichElle> his 'convenient' ability to work 24/7 on i2p is quite suspicious, indeed
            
-
            14:25 < MichElle> anyway
            
-
            14:25 < MichElle> that's all I wanted to say
            
-
            14:25 < MichElle> keep your eyes on jrandom
            
-
            14:26 < MichElle> his gentle and warm facade may be just that.
            
-
            14:26 <+ugha2p> detonate: There are no theoretical thread limits, it will just consume all available resources until it crashes. :)
            
-
            14:26 < jnymo> facade
            
-
            14:26 <@jrandom> detonate: some OSes/ulimits may throttle @ 256, but win98 is already past the 100 TCP connections limit anyway
            
-
            14:26 < cervantes2p> I can give a quick update on the firefox plugin. The I2P Mail notifier is working now, as is the news reader and basic router controls. I'm busy with tediously building configuration screens now ( http://freshcoffee.i2p/fire2pe_i2pmail_prefs.jpg )
            
-
            14:27 < jnymo> MichElle, if the source code is sound, then who cares?
            
-
            14:27 <+detonate> oh, is the firefox plugin released?
            
-
            14:27 < MichElle> jnymo: it ruins the mood a little
            
-
            14:27 < cervantes2p> and I want to implement a downloader/install service that ties into smeghead's new updater verifier before I release
            
-
            14:27 < ddd> hi channel
            
-
            14:28 <+detonate> ok
            
-
            14:28 <@jrandom> w0ah! kickass cervantes2p 
            
-
            14:28 <@jrandom> it looks really nice
            
-
            14:28 <+detonate> hi ddd
            
-
            14:28 < cervantes2p> but getting close now...probably another couple of weeks...
            
-
            14:28 < MichElle> sort of like how running windows would still not be cool, even if microsoft open-sourced it
            
-
            14:28 <+detonate> that plugin looks cool
            
-
            14:28 < MichElle> back to the meeting, though ...
            
-
            14:28 <@smeghead> TrustedUpdate may be done this week hopefully, before i move
            
-
            14:28 <@jrandom> cool
            
-
            14:29 < ddd> ?
            
-
            14:29 < ddd> is i2p the only anonymous chat?
            
-
            14:29 <@jrandom> hi ddd .  weekly dev meeting going on
            
-
            14:30 < cervantes2p> 'lo ddd, we're just finishing a meeting...stick around we'll be done in a couple of minutes
            
-
            14:30 < ddd> are there other projects like i2p?
            
-
            14:30 <@smeghead> ddd: type /list then take your pick
            
-
            14:30 < ddd> ok
            
-
            14:30 < ddd> no i mean on other networks
            
-
            14:30 <@jrandom> ok, anyone else have anything to bring up for 5) ???
            
-
            14:30 <@smeghead> ddd: ask in #i2p-chat
            
-
            14:30 < ddd> ok i let you guys finish
            
-
            14:30 <+detonate> has anyone successfully run i2p in openbsd yet?
            
-
            14:31 <@jrandom> ddd: http://www.i2p.net/how_networkcomparisons
            
-
            14:31 < ddd> ok
            
-
            14:31 <+detonate> i was thinking of starting that fiasco up again
            
-
            14:31 <@jrandom> detonate: dunno
            
-
            14:31 < jnymo> oh yea.. who was doing the bsd i2p distro, and which bsd was it?
            
-
            14:31 <@jrandom> heh cool detonate, let us know how it goes
            
-
            14:31 <@jrandom> jnymo: lioux packaged 'er up for fbsd
            
-
            14:32 <@smeghead> i2p would never ship with openbsd :)
            
-
            14:32 <+detonate> sure
            
-
            14:32 < jnymo> woord..  wasn't someone going to do a i2p oriented distro?
            
-
            14:32 <+detonate> yeah, there's a port in freebsd now
            
-
            14:32 <+detonate> it's scary
            
-
            14:32 <+detonate> heh, someone wanted to have a knoppix cd that ran i2p
            
-
            14:32 <@jrandom> jnymo: after i2p is rock solid, it'd be worthwhile to explore packaging on distros/microdistros, yeah
            
-
            14:32 <+detonate> who knows why
            
-
            14:33 <@smeghead> jnymo: i remember that, i think it was going to be a knoppix/i2p, can't recall who was talking about it
            
-
            14:33 <@jrandom> detonate: netcafe
            
-
            14:33 <+detonate> ah
            
-
            14:34 <@jrandom> ok, anything else for the meeting?
            
-
            14:34 < MichElle> what the fuck is an i2p 'oriented' distro
            
-
            14:34 < MichElle> tor, i2p, and freenet ?
            
-
            14:34 < MichElle> there is no purpose
            
-
            14:34 < MichElle> the bandwidth requirements cancel the programmes out
            
-
            14:34 < MichElle> is jrandom theo de raadt ?
            
-
            14:34 < cervantes> a slightly camp distribution
            
-
            14:34 < jnymo> a completely anonymized distro
            
-
            14:35 < cervantes2p> jrandom: I guess not :)
            
-
            14:35 < MichElle> jrandom: nothing
            
-
            14:35  * jrandom winds up
            
-
            14:35  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting132.html b/www.i2p2/pages/meeting132.html
deleted file mode 100644
index 0f8576b2..00000000
--- a/www.i2p2/pages/meeting132.html
+++ /dev/null
@@ -1,365 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 132{% endblock %}
-{% block content %}
            I2P dev meeting, March 8, 2005
            
-
            
-
            13:06 <@jrandom> 0) hi
            
-
            13:06 <@jrandom> 1) 0.5.0.2
            
-
            13:06 <@jrandom> 2) mail.i2p updates
            
-
            13:06 <@jrandom> 3) i2p-bt updates
            
-
            13:06 < legion> so it's related to the irc servers?
            
-
            13:06 <@jrandom> 4) ???
            
-
            13:06 <@jrandom> 0) hi
            
-
            13:06 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html
            
-
            13:07 < fedo> hi
            
-
            13:07 <+postman> hi
            
-
            13:07 < frosk> goodday
            
-
            13:07 <@jrandom> legion: no, related to i2p bugs, being worked on
            
-
            13:07 < bla> hi
            
-
            13:07 < legion> ok
            
-
            13:07 <@jrandom> speaking bugs being worked on, lets jump on in to 1) 0.5.0.2 :)
            
-
            13:07 < cervantes> 'lo
            
-
            13:07 < cervantes> -- Disconnected
            
-
            13:08 <@jrandom> heh
            
-
            13:08 < ant> <mihi> hi all
            
-
            13:08 <@jrandom> 0.5.0.2 is out, and while your irc connection may lag at times, it'll recover ;)
            
-
            13:08 <@jrandom> woah heya mihi
            
-
            13:09 < cervantes> hey mihi
            
-
            13:09 <@jrandom> the status notes give a general overview of where things are and the most immediate priorities
            
-
            13:10 <@jrandom> the scary thing I'm trying to track down can be seen on http://localhost:7657/oldstats.jsp#router.invalidMessageTime
            
-
            13:10 < bla> As for me, I can say that 0.5.0.2 already improved realiability _vastly_ compared to 0.5.0.1: errors where destinations couldn't be contacted almost don't occur anymore 
            
-
            13:10 <@jrandom> those numbers should be very very small, but they're not, unfortunately
            
-
            13:10 <@jrandom> wikked bla 
            
-
            13:11 <@jrandom> yeah, the 0.5.0.2 is definitely an improvement, and everyone should upgrade ASAP 
            
-
            13:11 < bla> 375,932.22 in the last 10 minutes here....
            
-
            13:11 <@jrandom> well, the particular value isn't really the problem, its their frequency
            
-
            13:11 <@jrandom> (events per period)
            
-
            13:12 <@jrandom> those messages can likely be attributed to 0.5 routers, and some of it to 0.5.0.1 routers, which is why I want people to upgrade ASAP
            
-
            13:12 <@jrandom> it may be the case that its something else though, but I'd like to rule it out
            
-
            13:12 < bla> jrandom: I get about 200 per hour here
            
-
            13:13 <@jrandom> bla: i've currently got 93 this hour, but peak count much higher (thousands)
            
-
            13:13 <@jrandom> anyway, this particular stat is published in the netdb
            
-
            13:13 < bla> jrandom: How about excluding 0.5-0 from the net in software when releasing 0.5.0.3?
            
-
            13:14 <@jrandom> so we can all look around and see what values other people have ;)
            
-
            13:14 <@duck> 309,854.24 peak 5,473,314.59
            
-
            13:15 <@duck> pasting the wrong one,  huh
            
-
            13:15 <@jrandom> bla: definitely.  I added some code in the 0.5.0.2 rev to do soem forward compatability that 0.5.0.1 and 0.5 don't have
            
-
            13:16 <@jrandom> duck: hard to have a nonintegral # of events ;)
            
-
            13:16 < bla> jrandom: Good. At least that allows you to test your invalid-messages-are-due-to-0.5-0 hypothesis in a controlled manner
            
-
            13:16 <@jrandom> bla: aye, though it'd be great if people updated before then ;)
            
-
            13:17 <@jrandom> (so for those reading at home: http://www.i2p.net/download is your friend ;)
            
-
            13:17 < maestro^> jr: those numbers for router.invalidMessageTime deviations in ms?
            
-
            13:17 <@jrandom> maestro^: yes
            
-
            13:18 <@jrandom> (aka some really insanely skewed values)
            
-
            13:18 < legion> Here is a little network report [version|Number of nodes][0.5|6][0.5.0.1|39][0.5.0.2|107]
            
-
            13:18 <@jrandom> yeah, y'all have been great about updating
            
-
            13:18 < legion> So there is still a few people running 0.5 and many people running 0.5.0.1
            
-
            13:18 < maestro^> so any idea where they might be lagging?
            
-
            13:18 < bla> jrandom: Freenet has a flag in each release that specifies the minimum node version it will communicate with. Is the new forward-compat. code something like that?
            
-
            13:19 <@jrandom> maestro^: many, many ideas for why 0.5 and 0.5.0.1 users are lagging.
            
-
            13:19 <@jrandom> bla: similar
            
-
            13:19 < maestro^> or is it clock drift on nodes?
            
-
            13:20 <@jrandom> maestro^: clock skew, some serialization bugs, the 100% cpu bug
            
-
            13:20 <@jrandom> ok, thats generally my focus atm, trying to get the message reliability back up
            
-
            13:21 <@jrandom> anyone have any questions/comments/concerns on 0.5.0.2?
            
-
            13:21 < ant> * mihi has a 0.4.2.5 router here on hd not started since dec 22th... but he thinks he'd better delete it...
            
-
            13:21 <@jrandom> heh
            
-
            13:21 <@jrandom> yeah, that wont talk to too many routers ;)
            
-
            13:21  * postman got a backup copy of his last 0.4 installation :)
            
-
            13:21 < ant> <mihi> question for me 'd be upgrade or delete.
            
-
            13:22 <@jrandom> delete
            
-
            13:22 <@jrandom> (backing up any destination keys)
            
-
            13:22 <@jrandom> there is no upgrade procedure from pre-0.5 anymore
            
-
            13:22 < legion> Perhaps releasing another update say 0.5.0.2-1 that only allows connections from 0.5.0.2 or newer, would be good?
            
-
            13:22 <@jrandom> legion: that would segment the network
            
-
            13:22 <@jrandom> people should juts upgrade.
            
-
            13:23 <@jrandom> (and we should work around those that dont)
            
-
            13:24 < legion> yeah until the people running outdated nodes updated ;)
            
-
            13:24 <@jrandom> segmenting the network hurts us all, not just them
            
-
            13:25 < legion> Maybe if there was a update notification in the router console or something that let them know they are running outdated versions?
            
-
            13:25 <@jrandom> yeah, that'd certainly be pretty cool
            
-
            13:25 <@jrandom> hopefully that can get tied in with the updater as well
            
-
            13:26 < legion> yeah, I know, segmentation is bad...
            
-
            13:26 <@jrandom> smeghead is working on some of the key components of that, though not sure if that includes the notification / download
            
-
            13:26 <@jrandom> (so if anyone wants to help work on that, get in touch!)
            
-
            13:27 <@jrandom> ok, movin' on to 2) mail.i2p updates
            
-
            13:27 <@jrandom> postman: ping
            
-
            13:27 <+postman> yes
            
-
            13:27 < bla> jrandom: smeghead was doing some signing-related stuff IIRC (so that when you get an update notice, you at least know it's real, and not a phishing/spyware/crap thing)
            
-
            13:28  * postman takes over the mike
            
-
            13:28 < legion> hmm, maybe if there was a autoupdate feature built in, where updates would be downloaded through i2p and the nodes would simply download the update, then do a graceful restart.
            
-
            13:28 <@jrandom> right bla
            
-
            13:28 < ant> <Gatak> Oh, btw. Would I2P work behind nat even if you cannot open a port?
            
-
            13:28 <@jrandom> Gatak: not yet.  some people will be able to at 0.6, others at 2.0
            
-
            13:29 <@jrandom> legion: patches welcome
            
-
            13:29 < ant> <Gatak> 2.0 heck, that is far on the future =)
            
-
            13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;)
            
-
            13:29 <+postman> erm, shall i start now?
            
-
            13:29 < aum> morning all
            
-
            13:30 <@jrandom> mic is all yours postman (sorry ;)
            
-
            13:30 <@jrandom> 'lo aum, made it for the meeting
            
-
            13:30 <@jrandom> (d'oh!  /me shuts up again)
            
-
            13:30 < cervantes> Gatek: http://www.i2p.net/roadmap
            
-
            13:30 <+postman> first, i wanted to say, that we reached 300 accounts registered at postman.i2p already
            
-
            13:30 <@jrandom> w00t
            
-
            13:30 <+postman> the number of mails from/to internet is growing steadily and once more proves that we need to move further
            
-
            13:31 < cervantes> *squeeeel*
            
-
            13:31 <+postman> after talking to jr some weeks ago we agreed upon the the release of v2mail together with I2P 1.0
            
-
            13:31 <+postman> recent status is: the java based smtp proxy designed to run on every node is finished
            
-
            13:31 <@jrandom> nice!
            
-
            13:32 <+postman> the java based POP3 proxy is at 80% with just the maildir engine missing
            
-
            13:32 <+postman> there will be a webmanager that needs some heavy tweaking still (15% done)
            
-
            13:32 <+postman> the inter node communication is at 40% - we tested some datarecord exchanging with HTTP/XML
            
-
            13:33 <+postman> seems to work quite well and fast even
            
-
            13:33 <+postman> even if a relay node fails/was powered off for a few days, it'll be synced within a few minutes after going back onlione again
            
-
            13:33 <@jrandom> wikked
            
-
            13:33 <+postman> i think we're quite n track
            
-
            13:34 <+postman> one thing is noteable
            
-
            13:34 < bla> postman: Nice work man! One question: Many nodes cannot receive or send data on port 25 (not directly, anyway). Will node-owners be able to specify this (or will this be auto-detected)?
            
-
            13:34 < cervantes> cool
            
-
            13:34 <+postman> bla: later
            
-
            13:34 <+postman> in v2mail there will be a locally run webapp
            
-
            13:34 <+postman> with this you can manager your local proxies AND apply for an "relayaccount"
            
-
            13:35 <+postman> this relayaccount will then be used to associate your addess/domain to the relays
            
-
            13:35 <+postman> the relays will sync the information automatically
            
-
            13:35 <@jrandom> cool
            
-
            13:35 <+postman> even features like the addressbook / public keys and stuff will work with the LOCAL interface
            
-
            13:36 <+postman> so the idea is to have one centralized manager where you can do all your mailstuff
            
-
            13:36 <+postman> relevant data is transferred to ONE of the relays and then being synced between the relays
            
-
            13:36 <+postman> and this webbased manager will run on your very node
            
-
            13:37 <+postman> when your node is online, the relays will deliver mails queued for your destination/domain/address
            
-
            13:37 <+postman> it will be delivered to your local smtp proxy
            
-
            13:37 <+postman> you can even trigger the whole thing with ETRN :)
            
-
            13:37 < aum> hi again
            
-
            13:37 < aum> i'd like to raise a discussion point in this meeting, if it's ok
            
-
            13:37 <+postman> so much for the future folks :)
            
-
            13:37 <+postman> .
            
-
            13:38 <@jrandom> sound bitchin postman 
            
-
            13:38  * postman hands back the mike
            
-
            13:38 <@jrandom> aum: great, should be some time at 4) 
            
-
            13:38 <+postman> yeah, iam ecstatic :)
            
-
            13:38 <@jrandom> postman: so for the normal user, the smtp proxy will have the local maildir, and the pop3 proxy will read/etc, right?
            
-
            13:39 <+postman> yeah, the smtp proxy got a MDA
            
-
            13:39 <+postman> and will deliver the mail into local maildirs
            
-
            13:39 <+postman> even several accounts/users can be created locally
            
-
            13:39 < cervantes> postman: will the relays keep track of your quotas etc and propogate such info between each other?
            
-
            13:39 <+postman> and mapped to accounts of your domain
            
-
            13:39 <+postman> cervantes: yes, they will
            
-
            13:39 < septu_ssh> sorry, can I ask postman about payment/anti-spam mechanisms in the new model?
            
-
            13:40 <+postman> septu_ssh: have you read any of the documents on the webpage?
            
-
            13:40 <+postman> cervantes: it's not perfect real time
            
-
            13:40 <+postman> cervantes: but i am fine with a few minutes update of quota information exchange
            
-
            13:40 < septu_ssh> postman: in the queue for reading :/
            
-
            13:40 < septu_ssh> but if it's doc'd, then it's fine
            
-
            13:40 < cervantes> postman: yeah I figured
            
-
            13:41 <+postman> septu_ssh: www.postman.i2p/inout.html
            
-
            13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html
            
-
            13:41 <+postman> cervantes: this is no drama really - the quota is a sane limit
            
-
            13:41 < cervantes> postman: even someone being able to send  nrelays * quota recipients is no bad thing
            
-
            13:41  * septu_ssh is bungle
            
-
            13:41 <+postman> cervantes: yep
            
-
            13:42 <+postman> the goal is just to stop anybody from really abusing the service
            
-
            13:42 <+postman> in the tests i had 3 relays have been really fast 
            
-
            13:42 <@jrandom> postman: i forget, will this have support for the local smtp relay talking directly to someone else's smtp relay, rather than bouncing through your nodes?
            
-
            13:42 <+postman> cervantes: within 10 secs they have been synced :)
            
-
            13:43 <@jrandom> (or perhaps thats just for later)
            
-
            13:43 <+postman> jrandom: the i2p mail relays will be operated by several ppl and are the preferred dests for routing mail
            
-
            13:43 < cervantes> postman: you could introduce an exponential delay to the send queue
            
-
            13:43 < cervantes> if it becomes an issue
            
-
            13:43 <+postman> jrandom: so sending to other destinations could be handy under certain circumstances
            
-
            13:44 <@jrandom> aye, though dangerous under others
            
-
            13:44 < cervantes> so the more mail you send the greater the time the mail gets queued for...should give the relays time to catch up
            
-
            13:44 <+postman> jrandom: but if a node's owner discloses his IMIO destination he could be spammed w/o control :)
            
-
            13:44 <@jrandom> exactly
            
-
            13:44 <@jrandom> otoh, same goes if the i2p mail relays are hostile
            
-
            13:45 <+postman> jrandom: indeed, it's a WOT like construction
            
-
            13:45 <@jrandom> </tinFoil>
            
-
            13:45 <+postman> jrandom: i cannot stop a relay operator from distributing a quota of 0 for your address
            
-
            13:45 <@jrandom> 'k great.  yeah, no need to worry about it for now
            
-
            13:45 <+postman> :)
            
-
            13:46 <+postman> ok
            
-
            13:46 <+postman> .
            
-
            13:46 <@jrandom> ok cool, thanks for the update.  some really exciting stuff
            
-
            13:46 <@jrandom> ok, swinging on to 3) i2p-bt updates
            
-
            13:46 <@jrandom> duck: ping
            
-
            13:46 <@duck> hi
            
-
            13:47 <@duck> Yesterday BitTorren 4.0.0 was released
            
-
            13:47 < ant> <dm> sounds german
            
-
            13:47 <@duck> which we more or less waited for before starting on 0.2
            
-
            13:47 <@duck> wrote a tasklist / todo: http://pastebin.ca/raw/7037
            
-
            13:47 <@duck> (sorry my www is currently down)
            
-
            13:48 <@jrandom> cool
            
-
            13:48 < legion> what sort of timetable are we talking about for 0.2?
            
-
            13:48 <@duck> the goal was 4 weeks
            
-
            13:49 < legion> cool
            
-
            13:49 <@duck> as you can see RawServer (the part that communicates with i2p) is the biggest task
            
-
            13:50 <@duck> .
            
-
            13:50 <@duck> a quick poll:
            
-
            13:50 < legion> yeah, I'm well aware of that :)
            
-
            13:50 <@duck> who is planning to create an i2p-bt fork?
            
-
            13:50 <@jrandom> cool, is there anything people can do to help?
            
-
            13:50 <@jrandom> heh
            
-
            13:51 < ant> <dm> i
            
-
            13:51  * jrandom grabs a spoon
            
-
            13:51 < ant> <dm> m wiling to hepl
            
-
            13:51 < legion> i
            
-
            13:51 < ant> <dm> m gay
            
-
            13:51 < legion> I'm working on a fork
            
-
            13:52 <@duck> good, then I know who not to take serious.
            
-
            13:52 <@duck> really, I think it is silly; pooling resources might get you much further
            
-
            13:53 <@jrandom> or perhaps if there are better ways to go, you can convince duck to work that way?
            
-
            13:53 < named> I'm going to write a fork in qbasic, please take me seriously.
            
-
            13:53 <@duck> I'll try to have the process more open, so others can see what is planned etc
            
-
            13:53 < ant> <dm> your openness is not swaying us. FORK! FORK! FORK! FORK!
            
-
            13:53 <@duck> if you have any other suggestions
            
-
            13:54 < ant> * dm raises legion onto his shoulders.
            
-
            13:54 < legion> hmm, that may be true, though with what I'm doing I doubt you want me polluting the main i2p-bt development process ;)
            
-
            13:54 < ant> <dm> FORK! FORK! FORK! FORK!
            
-
            13:54 <@jrandom> legion: what are you doing that duck wouldn't want to support?
            
-
            13:55 <@duck> legion: congrats, if you google for 'i2p bittorrent', then an announcement of "Windows I2P Bittorrent Version 1.0" is #1
            
-
            13:55 <@jrandom> jesus
            
-
            13:56 < bla> jrandom: Yes?
            
-
            13:56 <+postman> jrandom: yeah, they will rip this network's ass open soon :)
            
-
            13:56 < bla> ;)
            
-
            13:56 < named> 1.0? Damn, I'm using 0.1.8!
            
-
            13:56 < Ragnarok> oy
            
-
            13:57 < legion> omfg, really?! I cannot believe it... that's insane.
            
-
            13:57 <@duck> anyway, I dont think that there is much new to say on this
            
-
            13:57 < legion> my 1.0 release is based on 0.1.8 if you're running 0.1.8 you're fine.
            
-
            13:58 <@jrandom> (and the 1.0 release is a .exe that no one has reviewed, ymmv)
            
-
            13:58 < legion> I poorly named and numbered it sorry, again about that.
            
-
            13:58 < ant> <dm> 1.0 >> 0.1.8
            
-
            13:58 < ant> <dm> any day of the week
            
-
            13:59 <@duck> slightly related:
            
-
            13:59 <@jrandom> ok, anything else on 3) i2p-bt, or shall we move on to 4) ???
            
-
            13:59 <+postman> legion: when there will be sourcecode downloadable?
            
-
            13:59 < frosk> "I2P-BT 0.1.8 works pretty fine and stable so far. I personally see no reason to update to I2P-BT 1.0" (seen on forum)
            
-
            13:59  * jrandom sighs
            
-
            13:59 <@duck> last month bram cohen held a talk about bittorrent on some university
            
-
            14:00 <@duck> quite interesting: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent
            
-
            14:00 <@duck> (learned lessons about big p2p programs, plus some bittorrent details explained)
            
-
            14:00 <@duck> .
            
-
            14:01 <@jrandom> word
            
-
            14:01 <@duck> postman: legion has released some sourcecode
            
-
            14:01 < ant> <dm> is he the inventor of BT?
            
-
            14:01 <@duck> but according to smeghead it isnt the same as the .exe
            
-
            14:01 <@jrandom> dm: yes
            
-
            14:01 < legion> There is a developer source you can download from http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2
            
-
            14:02 <+postman> k, will have a look
            
-
            14:02 < ant> <dm> is the exe a direct compile of that source?
            
-
            14:03 < legion> though really the 1.0 source is really just 0.1.8 with a patch from smeghead, compiled and nicely packaged.
            
-
            14:04  * cervantes walks over to 4)??? and waits for everyone to catch up
            
-
            14:04 < ant> <dm> the question remains unanswered
            
-
            14:04 < ant> <dm> Legion, did you or did you not, order a code red???
            
-
            14:04 <@jrandom> *cough*
            
-
            14:04 < legion> Perhaps we should get back on topic, my bt client discussion moved to #itorrent
            
-
            14:05 <@jrandom> ok, 4) ???
            
-
            14:05 <@jrandom> anything else people want to bring up?
            
-
            14:05 <@jrandom> aum: you had something?
            
-
            14:06 < ant> <dm> stasher is back?
            
-
            14:06 < legion> I'm just seeing some funky behavior with 0.5.0.2 periods of heavy traffic...
            
-
            14:06 < aum> yes
            
-
            14:06 < aum> i'd like to raise the question of automated tunnel creation/management
            
-
            14:07 < ant> <dm> go on
            
-
            14:07 <+detonate> there's a null pointer exception in the systray thing in windows, i just noticed
            
-
            14:07 < aum> it's 1337 that the web console now allows for humans to manually create/delete/manage tunnels
            
-
            14:07 <@jrandom> detonate: could you toss 'er on the bugzilla?
            
-
            14:07 < aum> but I also strongly believe that there should always be a reliable and convenient way for programs to manage tunels as well
            
-
            14:08 <@jrandom> aum: no one disagrees.  we need it, and we will have it.  just not yet.
            
-
            14:08 < ant> <dm> can't you do that through SAM?
            
-
            14:08 < aum> i noticed on my recent return to i2p that the pysam library is no longer working
            
-
            14:08 < septu_ssh> I have a quick question as well after aum
            
-
            14:08 < aum> which was a disappointment
            
-
            14:08 <@jrandom> the SAM protocol works, pysam doesnt
            
-
            14:08 < Ragnarok> did it ever work?
            
-
            14:09 < aum> correct
            
-
            14:09 < aum> pysam used to work brilliantly
            
-
            14:09 < legion> During such periods there are 1000+ tunnels my node is participating in and several seconds of lag and delay.
            
-
            14:09 <@jrandom> legion: aye, the # of tunnels is because of older builds
            
-
            14:09 < cervantes> ah mymodesty
            
-
            14:09 < cervantes> eerm pymodesty
            
-
            14:09 < aum> i'm presently writing a module 'i2ptunnel.py', which defines classes allowing easy tunnel management
            
-
            14:10 < legion> so if older builds were not being connected to, the networking would be much smoother?
            
-
            14:10 <@jrandom> 'k, i don't know if thats the right long term solution, but if it bridges the gap for you now, cool
            
-
            14:10 <@jrandom> legion: those tunnels aren't the problem
            
-
            14:11 < aum> well, the class interfaces can remain even though the underlying mechanism changes
            
-
            14:11 <@jrandom> 'k
            
-
            14:11 < legion> aren't they?
            
-
            14:12 < legion> When there a few tunnels, there is very little lag and delay...
            
-
            14:12 < cervantes> legion: sorry aum is just raising some questions, if you hang fire a minute
            
-
            14:12 < legion> it just seems odd to me.
            
-
            14:13 < legion> ok
            
-
            14:13 <@jrandom> i just worry that we need to take into consideration whats been successful in the past - the web config works and is maintained because everyone uses it.  perhaps it'd be best to get whatever app you're working on working with manual tunnel creation *first*, that'd be more efficient?
            
-
            14:13 <@jrandom> just so that there is always something that is using i2ptunnel.py, to stress it
            
-
            14:13 < aum> we seem to be deadlocking
            
-
            14:13 <+detonate> jrandom:sure
            
-
            14:14 < ant> <dm> let's move on then
            
-
            14:14 < aum> i don't want to invest time in developing my app till I've got a tunnel mgmt API I can rely on
            
-
            14:14 < septu_ssh> \o. - point to raise 
            
-
            14:14 < cervantes> realistically I can't imagine the tunnel interface will be revamped in the next couple of months though...
            
-
            14:14 <@jrandom> but surely you see that we can add one trivially
            
-
            14:14 < cervantes> so a stopgap solution is viable
            
-
            14:15 < named_> Couldn't the web config have some kind of api that aum's program manipulates?
            
-
            14:15 <@jrandom> named_: yes
            
-
            14:16 <@jrandom> its trivial to add something in to allow safe control via URLs, but only makes sense if there's something that needs it
            
-
            14:16 <@jrandom> otherwise it'll just rot
            
-
            14:16 < aum> named_: that would be nice, and could work if there were a hardcoded password in config that client progs need to POST in along with tunnel control fields
            
-
            14:16 < cervantes> personally I'd like to see the whole tunnel system completely revamped, if you include a tunnel management interface from the start then you won't have to worry about the extra effort needed to maintain a seperate interface
            
-
            14:17 <@jrandom> aye, the proxies do need a bunch of work, which i've been hiding from as much as possible :)
            
-
            14:17 < aum> SAM is good for some situations, bad for others
            
-
            14:17 < cervantes> but that's somewhat down the line...
            
-
            14:17 < fedo> (
            
-
            14:18 <@jrandom> aum: but as a stopgap, couldn't you just use one of the three available methods?
            
-
            14:18 < cervantes> ie if the webinterface itself uses the api then there's no maintenance overhead
            
-
            14:18 <@jrandom> right.  the web interface uses the TunnelControllerGroup
            
-
            14:19 < aum> SAM usage gets difficult when one wants to use existing libs that are extensively dependent on standard TCP sockets
            
-
            14:19 < aum> jrandom: the I2PTunnel CLI doesn't work for opening server tunnels, so i'm presently writing code for using TunnelControllerGroup
            
-
            14:19 <@jrandom> aum: exising libs need to be carefully audited.  for instance, the gzip utility itself exposes sensitive data
            
-
            14:19 < aum> coding as we speak
            
-
            14:21 <@jrandom> I'm certain that the CLI works for server tunnels, but using the TunnelControllerGroup is preferred, if you need it that way
            
-
            14:21 <@jrandom> ok, anyone else have anything to bring up?
            
-
            14:22 < septu_ssh> My question pertains to a distributed version of the hosts.txt, a DHT table is used currently for routerInfo, could this not be extended to a distributed version of DNS? The DNS DHT could contain mappings from www.bla.i2p to the eepsite SHA, and the entries would be signed by an 'I2P registrar'... comments? rebuttals?
            
-
            14:22 < mancom> a question concerning the roadmap: is 0.6 still scheduled for april?
            
-
            14:22 <@jrandom> septu_ssh: non-routing data goes in the netDb over my dead body ;)
            
-
            14:23 < septu_ssh> jrandom: not the same db
            
-
            14:23 < septu_ssh> a different distributed db
            
-
            14:23 < aum> jrandom: did you see my bug report? the CLI 'server' command /does not work/
            
-
            14:23 < maestro^> septu_ssh: there isnt any i2p registrar
            
-
            14:23 <@jrandom> septu_ssh: there are many dangerous aspects of naming, with a few key tradeoffs.  have you seen the naming discussion on ugha.i2p?
            
-
            14:24 <@jrandom> septu_ssh: ah, a DHT on top of I2P could certainly be used to distribute entries, though those names would not be secure, if they were treated as global entries
            
-
            14:26 <@jrandom> aum: i used it daily up through a few weeks ago, did you see my reply?
            
-
            14:26 <@jrandom> maestro^: thats the plan
            
-
            14:26 <@jrandom> er, mancom:
            
-
            14:26 < cervantes> aum: I have a reply to that i2plist mail from jr, has it not reached you yet, or does the issue remain?
            
-
            14:26 < septu_ssh> the only reason why I suggest a 'registrar' is because collisions can take place otherwise
            
-
            14:26 <@jrandom> septu_ssh: embrace collisions :)
            
-
            14:26 <@jrandom> globally unique, human readable, distributed, and secure naming doesnt exist
            
-
            14:27 < septu_ssh> it can also happen in host.txt if it is manually edited, but the problem remains the same
            
-
            14:27 <@jrandom> drop the first parameter, and you're golden
            
-
            14:27 < aum> jrandom: i did see your reply - and I /do/ have streaming.jar in my cp
            
-
            14:27 < septu_ssh> postman manages a central node for mail, so there is some element of trust within the network, surely someone would trust a registrar to manage namespace?
            
-
            14:27 <@jrandom> ok cool, and it still comes back with that stacktrace aum?
            
-
            14:28 < aum> yes
            
-
            14:28 <@jrandom> septu_ssh: postman only acts as a central element for postman's outproxies and inproxies
            
-
            14:28  * Ragnarok really need to get around to writing that addressbook doc...
            
-
            14:28 < aum> this is when i manually run the cli, do a genkeys, then do a 'server' using the privkeyfile generated by genkeys
            
-
            14:28 <@jrandom> septu_ssh: no one will trust anyone to manage a namespace.  censorship == exert presure on that registrar.
            
-
            14:28 < maestro^> everyone is really their own registrar
            
-
            14:29 < maestro^> you trust your friends and they trust you
            
-
            14:29 < aum> oh shit, i picked up an old classpath
            
-
            14:29  * aum tests again
            
-
            14:30 < ant> <dm> ok, I'll be the registrar.
            
-
            14:31 < ant> <dm> I'll be as unbiased as I can... cool?
            
-
            14:31 < septu_ssh> hmmm, ok, back to the proverbial drawing board then...
            
-
            14:31 <@jrandom> septu_ssh: a good place to review is http://zooko.com/distnames.html :)
            
-
            14:32 <@jrandom> everyone wants it, but what they want just isn't secure.  we have a solution that is, but we give up global uniqueness
            
-
            14:33 < septu_ssh> hmmm, ok
            
-
            14:33 <@jrandom> ok, anyone else have anything else to bring up for the meeting?
            
-
            14:33 < cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134
            
-
            14:33 < aum> jrandom - ok, cli 'server' now works, but i never got a 'job number' for the tunnel
            
-
            14:34 <@jrandom> hmm right, it runs forever
            
-
            14:34 < aum> oh, i gotta do 'list' to get the job num
            
-
            14:36 <@jrandom> ok cool, if there's nothing else...
            
-
            14:36  * jrandom winds up
            
-
            14:36  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting133.html b/www.i2p2/pages/meeting133.html
deleted file mode 100644
index ff4bfd93..00000000
--- a/www.i2p2/pages/meeting133.html
+++ /dev/null
@@ -1,323 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 133{% endblock %}
-{% block content %}
            I2P dev meeting, March 15, 2005
            
-
            
-
            13:07 < jrandom> 0) hi
            
-
            13:07 < jrandom> 1) Net status
            
-
            13:07 < jrandom> 2) Feedspace
            
-
            13:07 < jrandom> 3) ???
            
-
            13:07 < jrandom> 0) hi
            
-
            13:07  * jrandom waves
            
-
            13:07 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000649.html
            
-
            13:08 < Teal> hi
            
-
            13:08 < jrandom> (yeah, i was late this time, but close!)
            
-
            13:08 < frosk> hi
            
-
            13:08 < jrandom> might as well jump on in to 1) net status
            
-
            13:08 < jrandom> the net, its, like, up, 'n stuff
            
-
            13:09 < jrandom> overall throughput is still down where it was before, with a substantial number of dropped messages & fragments
            
-
            13:09 < bla> hi
            
-
            13:09 < ant> <dm> bad
            
-
            13:09 < Teal> any clues as to why ?
            
-
            13:10 < jrandom> Teal: sure, read the status notes?  :)
            
-
            13:10 <+detonate> hi
            
-
            13:11 < jrandom> there are still ~ 25 people on older builds, and likely, they'll be staying there until we drop them off the net
            
-
            13:11 < jrandom> in any case, we should be able to work around them, so having them here is actually helpful, i suppose
            
-
            13:11 < jrandom> (though it'd be nice if they upgraded... ;)
            
-
            13:11 < cervantes> (hi)
            
-
            13:11 < frosk> those are probably sheeple who installed i2p because they read about it somewhere and wanted to try "anonymous p2p"
            
-
            13:12 < ant> <BS314159> yeah, if network quality degradation can happen due to bugs, it's possible due to malice
            
-
            13:12 < newkid> This is the first meeting I am in, but I read the notes, and the problem seems related to what I explained before the meeting
            
-
            13:12 < Pseudonym> do we know what specific probblems the old nodes are causing and why?
            
-
            13:12 < jrandom> bs314159: never attribute to malice what can be attributed to jrandom writing bad code ;)
            
-
            13:13 < jrandom> Pseudonym: yeah, see the changelog
            
-
            13:13 < newkid> I run two nodes, milliseconds apart, and they don't regard eacxh other "fast" more of the time
            
-
            13:13 < jrandom> right newkid 
            
-
            13:13 < jrandom> the speed calculator as deployed is, well, pretty shitty
            
-
            13:13 < jrandom> it doesnt gather enough data to have any sort of confidence in the values
            
-
            13:13 < bla> Hmm.. That's bad at best ;)
            
-
            13:13 < jrandom> its about as meaningless as the "instantaneous rates" you can see on /oldconsole.jsp
            
-
            13:14 < jrandom> i'm trying out some new calculators, and there is an improvement, but there are problems in the algorithm
            
-
            13:14 < jrandom> namely, it won't let high capacity peers turn into fast peers without those fast peers dropping from the high capacity group
            
-
            13:15 < bla> jrandom: Does every node get "fastness" data for the other nodes directly ("P2P"), or via tunnels?
            
-
            13:15 < jrandom> (aka the first K peers placed in the fast group will stay in the fast group)
            
-
            13:15 < jrandom> bla: tunnels, we cannot trust direct measurement, as that'd allow trivial anonymity attacks
            
-
            13:15 < godmode0> "alfYl6RvHzw="  =   "21538-900"
            
-
            13:15 < godmode0> "alV9ye/y/Us="  =  "23565-200"
            
-
            13:15 < godmode0> its is sha1 ?
            
-
            13:15 < jrandom> (e.g. be really really slow to everyone except Alice)
            
-
            13:15 <+detonate> they'll stay there for the lifetime of the router?
            
-
            13:15 < jrandom> godmode0: we're in a meeting right now
            
-
            13:16 < godmode0> ops sorry
            
-
            13:16 < jrandom> detonate: until one of them failed or rejected a tunnel (aka their capacity rank drops them from the high capacity group)
            
-
            13:16 <+detonate> ok
            
-
            13:17 < bla> bla: Hmm.. This sounds like a problem that ---in order to get _really_ enough_ data--- has to be >>log(N) on the network. 
            
-
            13:17 < jrandom> i've been toying with some ideas to get more data, but haven't updated it yet
            
-
            13:17 < bla> In terms of load, that is.
            
-
            13:18 < jrandom> well, one of the critical points certainly is when the network load exceeds the network capacity
            
-
            13:18 < jrandom> i believe our capacity calculators can handle that though
            
-
            13:18 < cervantes> jrandom: is -3 actually employing this fast peer selection method?
            
-
            13:18 <+polecat> Hopefully since data transfer between peers has fairness controls, there won't be any way to increase load too much...
            
-
            13:19 < bla> jrandom: Well, I mean more specifically: we need to make sure that the "finding out who is fast" algo. stays O(log(N))
            
-
            13:19 < jrandom> cervantes: yeah, but as i said, it doesn't allow promoting peers between fast and high capacity
            
-
            13:19 < jrandom> polecat: fairness controls?
            
-
            13:19 < cervantes> since I've just realised I've had the proxy enabled, and have been browsing the live web without realising (I did think my connection was a little sluggish) ;-)
            
-
            13:20 < cervantes> s/live web/outerweb
            
-
            13:20 < jrandom> bla: i'm not sure we should be dependent upon N.  no need to find an optimal 'fastest on the net', merely 'fast enough to handle our data'
            
-
            13:20 <@smeghead> it would seem i2pProxy.pac is dangerous even for its creator :)
            
-
            13:20 < jrandom> heh nice cervantes :)
            
-
            13:20 < jrandom> lol
            
-
            13:20 < cervantes> so it certainly seems to have improved things on my home node which was really suffering before
            
-
            13:21 < ant> <BS314159> jrandom: can you randomize it?
            
-
            13:21 < cervantes> smeghead: hehe hell I don't use that! you think I'm mad!
            
-
            13:21 < ant> <BS314159> i.e. create a spontaneous transition rate?
            
-
            13:21 < jrandom> BS314159: we use the tiers, and randomize within the tiers
            
-
            13:22 < jrandom> BS314159: spontaneous rates are essentially what we have now, which fluctuate widely
            
-
            13:22 < jrandom> (we == 0.5.0.2-0)
            
-
            13:22 < ant> <BS314159> I think I don't understand the problem. nm.
            
-
            13:23 < jrandom> it is tough to do safely and accurately, but i think there's enough data around for us to harvest sufficient info.  we shall see
            
-
            13:23 < bla> jrandom: In any case, finding out a couple of good nodes looks an awful lot like an ant-colony optimization thing
            
-
            13:24 < bla> jrandom: Because once you've got fast peers, you're likely to use _those_ to find out who else is fast.
            
-
            13:24 < jrandom> would you propose further active probing along those lines?
            
-
            13:24 < jrandom> ah, actualy, thats not true
            
-
            13:25 < jrandom> thats the difference between client tunnels and exploratory tunnels
            
-
            13:25 < bla> jrandom: And thus, it seems you'd essentially be doing a greedy optimization scheme (much like ant-colony)
            
-
            13:25 < jrandom> client tunnels are built with fast peers, exploratory tunnels are built with any non-failing peer
            
-
            13:25 < jrandom> (chosen randomly)
            
-
            13:26 < bla> jrandom: Hmm.. For anonimity, that's good. However, for quickly finding good tunnel-partners to use, it would be better to use fast peers in the expl. tunnels... The trade-off again
            
-
            13:26 < jrandom> otoh, there may be something in that vein to help optimize the peer selection
            
-
            13:26 < jrandom> oh, right, certainly you'd get better performance by using the fast peers, but then you wouldn't be exploring :)
            
-
            13:27 < jrandom> the exploratory tunnels aren't used for end to end client messages, just for netDb messages, tunnel maintenance messages, and peer test messages
            
-
            13:27 < bla> jrandom: I see, so effectively, you use random expl. tunnels to prevent falling into local optima?
            
-
            13:27 < jrandom> so the actual throughput of the exploratory tunnels doesnt matter (as long as the data gets through, eventually)
            
-
            13:27 < jrandom> aye
            
-
            13:29 < bla> jrandom: Ok, I see. OTOH: When I use my client tunnels to transfer some data (like downloading from an eepsite), I seems to me (intuitively), that the timing/throughput data on that could also serve as some kind of "passive peers assessment", couldn't it?
            
-
            13:29 < jrandom> definitely bla, and at the moment, we don't yet harvest that data within the speed selection
            
-
            13:29 < bla> jrandom: i.e. as an aux. way to get more data on peers
            
-
            13:30 < jrandom> some of it we can, though some of it will be harder to grab (since the streaming lib is external)
            
-
            13:30 < jrandom> we should definitely grab what we can though to get more confidence
            
-
            13:30 < ant> <BS314159> won't that depend on the slowest link in any tunnel?
            
-
            13:31 < ant> <BS314159> making it very difficult to use for hops>0?
            
-
            13:31 < jrandom> BS314159: yeah, but it'll average out, as peers are selected randomly within the fast tier
            
-
            13:31 < jrandom> same goes for any remote measurement
            
-
            13:34 < jrandom> ok, so thats generally where things stand atm.  hopefully we'll have some new calculators & stats up for a -4 or -5 build in the next few days, trying to see how it handles the live net
            
-
            13:34 < jrandom> anyone have anything else to bring up for 1) Net status?
            
-
            13:34 < bla> jrandom: It may seem that I'm putting a truckload of emphasis on this, but it seems to me to be a problem that['s very fundamental for a big I2P net to work...
            
-
            13:35 < jrandom> bla: its certainly important, but remember, we don't need optimal peer selection.  merely sufficient
            
-
            13:35 < ant> <aum> morning folks
            
-
            13:36 < jrandom> all we care about is finding some peers who can handle a tunnel, and making sure those tunnels can handle our data
            
-
            13:36 < jrandom> 'mornin aum, in time for the meeting :)
            
-
            13:36 < bla> jrandom: I see. Thnx for the explaination!
            
-
            13:36 < jrandom> of course, you're right in that it'd be kickass if we /could/ find the optimal peer selection ;)
            
-
            13:37 < jrandom> and there is definitely lots of room for some students to work out some ideas and write up some papers
            
-
            13:37 < frosk> this would be a cool thesis project :)
            
-
            13:37 <+detonate> how workable do you think it would be to actively tweak the parameters of the peer selection until it hopefully settles on something that works, disregarding the impossibility of debugging such a system? :)
            
-
            13:38 < jrandom> detonate: manual peer selection is a PITA, since fast peers get congested occationally, asking you to back off, etc.  
            
-
            13:38 <+detonate> ah
            
-
            13:39 < jrandom> i know we could dig into this forever, which is why i've set a milestone of successfully transferring one specific large file through standard tunnels, without disconnect
            
-
            13:39 <+detonate> alright
            
-
            13:40 < Teal> Victory at any cost!
            
-
            13:40 < jrandom> (otoh, there are some undocumented features of the peer selection system to let people weight individual peers manually, but i'm not recommending 'em ;)
            
-
            13:40 < jrandom> ok, thats 'bout it for 1), now lets swing on to 2) Feedspace
            
-
            13:41  * jrandom hands the mic to frosk 
            
-
            13:41 < frosk> oh, ok, hi
            
-
            13:42 < Myo9> Hi Frosk.
            
-
            13:42  * jrandom gets out the high intensity spotlight
            
-
            13:42 < frosk> so, everyone should check out http://feedspace.i2p (keys at orion or jrandom's blog)
            
-
            13:42 < frosk> my devbuddy (which i will out now as ku) and i have started writing some code and have had many lively discussions
            
-
            13:42 < frosk> also, http://feedspace.i2p/wiki/CallForComments has a fresh rev of the feedspace document :)
            
-
            13:43 < frosk> hi Myo9
            
-
            13:43 < frosk> oh yeah, feedspace is our new (and final) name for what used to be known as i2pcontent or fusenet :)
            
-
            13:43 < jrandom> r0x0r
            
-
            13:43 < frosk> as the status notes notes, we are still very interested in feedback on the general design of everything
            
-
            13:44 < frosk> nobody should be shy about challenging it :)
            
-
            13:44 < frosk> and the web site also lists some "job openings", we could use some helping hands on many aspects of the system and project
            
-
            13:45 < frosk> we're on a pretty tight schedule and none of us are full-time developers on the project unfortunately
            
-
            13:45 < frosk> so that's pretty much it, i think. questions? :)
            
-
            13:45 < ant> * aum can't reach orion.i2p or jrandom's blog, so can't reach feedspace.i2p
            
-
            13:46 < frosk> hm yes, the web site also has a roadmap, but the dates there _will_ change :)
            
-
            13:46 < legion> feedspace.i2p=KuW5sR2iGCfnnuwdslHbFsNyNCsoZnoIwAmHeypOV-s8OQxokBpdNazksBrhoQum9nv81vprl6k15Mhcd~KWE4OajjmdU7v2fjqps7QK3KmLv4UTrX-ihSIUdhb5B9FLh2XEFEQ4-8guFTVxBRqQQE~c058AL6~uZpuFpLtEOg0HEZ6BydndOhx-FCDm8ip12pPwZ3a5O86l1UoATZBXxoctGafTjnUlx64jyQs6y0WB811l36wVrc~~dqEcanxab0yfg8dJ~1M4EUNrXcHT-PwYYrr3GgpimuF4oUtYjkeDKlq5WjfMAa8bE73HFgquxq99fuW5aI1JbLPxnTLHi00-2On0dSDwJxSP08HOhKFKMNzykI9Asg8CywzNO6kWpbX9yaML36ohCJF0iaLvvDyhS4a2B65crSJRJPVkbxIvsyyUyYMGi31EK593ijOLjOvug
            
-
            13:46 < legion> there you go aum
            
-
            13:46  * jrandom just added feedspace to http://dev.i2p.net/i2p/hosts.txt
            
-
            13:46 < jrandom> (and cvs)
            
-
            13:46  * frosk goes temporarily blind
            
-
            13:46 < jrandom> legion: never paste as a single line, its too large to fit
            
-
            13:47 < ant> <aum> thx
            
-
            13:47 < frosk> jrandom can probably commit the key into his hosts.txt maybe? :)
            
-
            13:47 < jrandom> aye, 'tis on there now, forgot to :)
            
-
            13:48 < frosk> anyway, the plan is to have something simple and functional (and 100% bug-free!) out by I2P 0.6.1, and we'll build more neat stuff in later
            
-
            13:49 < jrandom> heh wikked
            
-
            13:49 < frosk> s/out/ready for real-world testing/
            
-
            13:49 < frosk> i still can't say if that's realistic or not, but i hope it will be, or we'll continue to cut features ;)
            
-
            13:49 < ant> <BS314159> since I can't reach feedspace.i2p, I'll ask a basic question
            
-
            13:50 < ant> <aum> that key is not correct, only 441 chars
            
-
            13:50 < jrandom> right aum, irc trims it, snag http://dev.i2p.net/i2p/hosts.txt
            
-
            13:51 <+detonate> frosk: i have a suggestion for the meantime
            
-
            13:51 <+detonate> get something on the i2p router console that grabs a list of updates from the i2p webserver, so people know when to update their routers, etc :)
            
-
            13:51 < legion> ah sorry, about that. Anyways I've already commited it to my hosts.txt also.
            
-
            13:51 < ant> <aum> thx jrandom
            
-
            13:51 < ant> <BS314159> which of the following systems do you see feedspace supplanting: usenet, gnutella, google, livejournal, www
            
-
            13:52 < jrandom> , the church
            
-
            13:52 < jrandom> er..
            
-
            13:52 < cervantes> jrandom: ah you caught me mid commit of hosts
            
-
            13:52 < ant> <BS314159> i.e. is it a message forum, a filesharing system, a content indexing system, a dynamic page system, and/or a static serving system
            
-
            13:53 < ant> * aum turns off throttling within routerConsole, and sees if that helps
            
-
            13:54 < frosk> BS314159: we will support blogs, forums, and shared address books (for the first version, other applications are possible)
            
-
            13:54 < frosk> it doesn't replace web pages per se
            
-
            13:54 < frosk> but it certainly could be used for "file sharing"
            
-
            13:54 <+detonate> content syndication then?
            
-
            13:54 < jrandom> it'd probably supplant static web content though, allowing persistent web publication for people who cannot run eepsites
            
-
            13:54 < frosk> that's what it's about
            
-
            13:55 < jrandom> (two word summary: usenet+SSK)
            
-
            13:55 < frosk> yeah
            
-
            13:55 < ant> <BS314159> ok
            
-
            13:55 < Ragnarok> not that persistent
            
-
            13:56 < jrandom> Ragnarok: depends on syndicator policy, true
            
-
            13:56 <+detonate> is anything happening with stasher?
            
-
            13:56 < frosk> it can be as persistant as the most eager syndicator :)
            
-
            13:56 < jrandom> (see: dejanews ;)
            
-
            13:56 < ant> <aum> detonate: stasher is on hold, writing a whole new thing called quartermaster
            
-
            13:57 <+detonate> i see
            
-
            13:58 < jrandom> frosk: what can we do to help?
            
-
            13:59 < jrandom> should people register & hack on the wiki, email, post on the forum?
            
-
            13:59 < jrandom> oh, perhaps we can get cervantes to add a new forum category?
            
-
            13:59 < frosk> i think actually a forum would be very nice at this point
            
-
            14:00 < frosk> for more private discussion, you can email us both at ku@mail.i2p and frosk@mail.i2p
            
-
            14:01 < cervantes> hrrrm ... are you going to put game reviews in it?
            
-
            14:01 < jrandom> heh
            
-
            14:01 < jrandom> w3rd
            
-
            14:01 < cervantes> because if not...then you're welcome to have a new forum section
            
-
            14:01 < frosk> i was thinking top20 music reviews, cervantes
            
-
            14:02 < jrandom> (btw, mirror of the call for comments @ http://dev.i2p.net/~jrandom/feedspace.txt)
            
-
            14:02 < cervantes> :)
            
-
            14:04 < cervantes> frosk: feedspace or feed space or Feedspace or Feed Space or FeedSpace?
            
-
            14:04 < frosk> cervantes: Feedspace
            
-
            14:05 < frosk> looking forward to much discussion over at the forum then :) i don't have anything else for this point, anyone else?
            
-
            14:05 < jrandom> ok cool, thanks for the update frosk 
            
-
            14:06 <@smeghead> or FEeDspace?
            
-
            14:06 < ant> <cervantes> frosk: when you have a moment, just pm me a one liner description for the forum section
            
-
            14:06 < legion> hmm speaking of new forums, lol. I'm putting a new forum site together. Though I have much hacking left to do on the phpbb code, it should be finshed sometime this week. ;)
            
-
            14:06 < jrandom> cool legion 
            
-
            14:06 < jrandom> that actually brings us into 3) ??? nicely
            
-
            14:06 < jrandom> anyone have anything else to bring up? 
            
-
            14:06 < jrandom> aum: any updates on Q?
            
-
            14:07 < frosk> i, uhm, no
            
-
            14:07 < ant> <aum> Q devlt is moving along nicely, nothing to announce atm
            
-
            14:07 < jrandom> w3rd
            
-
            14:07 < ant> * aum is 90% complete with net.i2p.i2ptunnel.I2PTunnelXMLServer
            
-
            14:07 < ant> <BS314159> I have a simple question about netDb
            
-
            14:07 < ant> <aum> everything's working now except 'i2p.tunnel.close'
            
-
            14:07 < legion> my forums will allow for members to have decent sized avatars, discuss shared content, just about whatever.
            
-
            14:08 < jrandom> wikked
            
-
            14:08 < ant> <BS314159> it says on the page that entries are stores on the peers closest to SHA256(router identity + YYYYMMdd)
            
-
            14:08 < jrandom> right BSpi
            
-
            14:08 <@smeghead> legion: will it be as much a security hazard as your bt client?
            
-
            14:08 < ant> <BS314159> does this mean there's a burst of traffic every 00:00 GMT?
            
-
            14:08 < ant> * aum is actually gaining some fluency in java, having attained a 'cognitive critical mass'
            
-
            14:09 < jrandom> BS: data points expire more frequently than they migrate
            
-
            14:09 < jrandom> a LeaseSet is only good for 10 minutes, for example
            
-
            14:09 < bla> jrandom: Is there a command-line call  I can make, such that I can speed estimates of each of the peers in the net over the last, say, 60 seconds, or so?
            
-
            14:09 < legion> lol, forums a security hazard?
            
-
            14:10 <@smeghead> legion: yes, and if you don't know that much, i'm already convinced that your forums will be a security hazard
            
-
            14:10 < jrandom> bla: yeah, java -cp lib/i2p.jar:lib/router.jar -Djava.library.path=. net.i2p.router.peermanager.ProfileOrganizer peerProfiles/*
            
-
            14:10 < jrandom> (i think)
            
-
            14:10 < legion> oh and the next release of my bt client shouldn't cause such issues...
            
-
            14:10 < jrandom> you may need to add some log levels to logger.config, lemmie check
            
-
            14:10 <@smeghead> legion: Cervantes made a ton of modifications to phpBB to lock it down for i2p use
            
-
            14:10 < ant> <BS314159> It just seems like having it occur all-at-once at a specified time is awkward.  If it were happening continuously, that would seem...smoother.  It would also give an attacker less time to mount an attack, since bits of the data would be wrong in less than 24 hours
            
-
            14:11 < jrandom> nah, it dumps to stdout
            
-
            14:11 < frosk> jrandom: how do you feel about the i2p roadmap currently, if one may ask? do you think it's realistic?
            
-
            14:11 < legion> Hmm I wonder if I can get a copy of cervantes mods?
            
-
            14:11 < jrandom> frosk: i update it when i become uncomfortable with it
            
-
            14:12 < frosk> ok
            
-
            14:12 <+detonate> you know, there's a windows installer for python 2.4, one for wxpython, and there's the i2p-bt tarball, i don't really see why anyone would get/trust a third-party release
            
-
            14:12 < legion> Otherwise I'll just have to continue to hack on the phpbb source myself...
            
-
            14:12 < jrandom> BS: peers would only look in the wrong place for up to 30s, due to clock synchronization
            
-
            14:12 <@smeghead> legion: have fun
            
-
            14:12 < legion> well why would anyone get and use kazaa?
            
-
            14:13 < bla> jrandom: I'm asking, because...
            
-
            14:13 < legion> Or morpheus?
            
-
            14:13 < jrandom> (because they dont know better?)
            
-
            14:13 < legion> Both of those contain adware/etc...
            
-
            14:13 <+detonate> they are ignorant?
            
-
            14:14 < legion> yeah and there are millions of ignorant users out there. ;)
            
-
            14:14 < ant> <BS314159> legion: you sound like you want to bundle spyware with I2P.  Truly, a stroke of genius.
            
-
            14:14 < bla> jrandom: ...I browsed SpeedCalculator.java and CapacityCalculator.java, and I'd like to experiment with the estimators
            
-
            14:14 < cervantes> legion: stay uptodate with official patches, and put htaccess on the admin areas
            
-
            14:14 < jrandom> wikked bla
            
-
            14:14 < legion> What? Heck no... I hate malware...
            
-
            14:14 < cervantes> most of my mods involve spam prevention
            
-
            14:14 < ant> <aum> can i raise a more critical issue?
            
-
            14:14 < legion> That's it? cervantes?
            
-
            14:15 < jrandom> sup aum?
            
-
            14:15 <@smeghead> legion: what about your users that also hate malware? why do you do nothing to alleviate any concerns they might have?
            
-
            14:15 < ant> <dm> BS314159: are you a windows hotfix?
            
-
            14:15 < ant> <aum> is it just me, or is there still some flakiness going on with in i2p? i'm having heaps of trouble with even main eepsites, irc etc
            
-
            14:15 < bla> jrandom: In addition, the idea of "passive fingerprinting" is now in my head (a bit ;): If I receive data through a tunnel, this tells me something about the bandwidth/capacity of all the peers in that tunnel:...
            
-
            14:15 < jrandom> aum: see the weekly status notes
            
-
            14:16 < cervantes> legion: rename all registration, login , posting and profile editing pages to something non-standard 
            
-
            14:16 < bla> jrandom: It tells me some about the peer closest to me, somewhat less about the peers one step away, and so progressively less.
            
-
            14:16 < cervantes> will help keep worms at bay
            
-
            14:16 < jrandom> bla: aye, i read that timing paper, and yesterday's tor attack paper with much interest
            
-
            14:17 < Myo9> Cervantes, releasing ant of your mods?
            
-
            14:17 < Myo9> s/ant/any/
            
-
            14:17 < jrandom> there is worry along those lines in the capacity calculator with the different tiers of rejection
            
-
            14:18 < bla> jrandom: In a way, this gives me some degree of "belief" in a peers bandwidth/capacity (that degree of belief depends on the distance to each of the tunnel members, and on the amount of belief I have on the BW/cap. of the nodes closest to me)
            
-
            14:18 < legion> thanks for the advice cervantes :)
            
-
            14:18 < bla> jrandom: Now, I happen to know some ppl that know a lot about Bayesian Belief Networks... ;))
            
-
            14:18 <@smeghead> again, legion ignores the question
            
-
            14:18 <+thetower> I think we're all gonna have to call a truce with legion and let him write whatever he wants, its not like anyone is forced to use it.
            
-
            14:18 < jrandom> hmm, what do you mean by distance bla?
            
-
            14:18 < ant> <dm> what is legion up to?
            
-
            14:19 < bla> jrandom: I'll have a chat with them, regarding passive fingerprinting (note: I do not mean "fingerprinting" in the negative sense of the word)
            
-
            14:19 < jrandom> wikked
            
-
            14:19 < jrandom> suggestions as to how we can best select 'quality' peers are very much welcome
            
-
            14:19 < cervantes> Myo9: I certainly could do.
            
-
            14:19 < legion> Anyways there isn't many i2p windows users just yet and not that many running my i2p-bt binary distribution. Soon my next release will be done and released, it will not have such issues... As there will be a binary and source distribution.
            
-
            14:19 <@smeghead> why anyone would want to use software from someone who doesn't even take the most basic measures to address users' concerns about security and anonymity is beyond me
            
-
            14:20 < ant> <aum> frosk: what lang you writing feedspace in? (forgive me if i asked you before)
            
-
            14:20 < cervantes> it's not a clean "patch" or anything though
            
-
            14:20 < bla> jrandom: distance... Say I have an inbound tunnel X -> Y -> me, and I know a _lot_ about Y's properties, than stats on what I receive thru that tunnel tells me a good deal about X
            
-
            14:20 < frosk> aum: java (and i forgive you ;)
            
-
            14:20 < cervantes> I've just been fixing stuff andproblems as it arises
            
-
            14:20 < bla> jrandom: OTOH, if I have little data/belief on Y's properties, transfer stats don't tell me much about X yet; I first have more to learn about Y
            
-
            14:20 < cervantes> as they
            
-
            14:20 < jrandom> bla: its very hard to tell whether lag or congestion occurs @ X or Y (or earlier hops)
            
-
            14:20 < cervantes> http://forum.i2p/index.php?c=4
            
-
            14:21 < cervantes> new section: Feedspace
            
-
            14:21 < jrandom> w00t
            
-
            14:21 < frosk> yay
            
-
            14:22 < legion> anyways enough discussion about my release, any further discussion about it should be done in the #itorrent channel
            
-
            14:22 < bla> jrandom: That is true. However, given large amount of data (and hoping that the measurement time is not _much_ larger than the timescale on which node properties change), I'm convinced there _must_ be information in traffic/tunnel stats
            
-
            14:22 <@smeghead> legion: we can discuss in meeting point # 3) any business that affects i2p
            
-
            14:23 <@smeghead> legion: and i think your software is of serious concern and warrants a warning to users
            
-
            14:23 < legion> yeah, ok
            
-
            14:23 < jrandom> bla: certainly, we just need to rope in the RTT from the OutboundClientMessageOneShotJob
            
-
            14:23 < jrandom> (and then figure out how best to calculate & decay the data)
            
-
            14:24 < legion> So smeghead if you were to make such a release, what would you do differently?
            
-
            14:24 <@smeghead> legion: the way you continually dodge questions and try to defer discussion on the subject is very disconcerting
            
-
            14:25 <@smeghead> legion: first of all, release the source to your current binary, no matter if it's "just i2p-bt with smeghead's patch", and have a writeup on your site explaining about your fork
            
-
            14:25 < bla> jrandom: What does the RTT signify there?
            
-
            14:26 <@smeghead> legion: it would be helpful to do as i2p-bt does also, and make a changelog indicating all the modifications you've made
            
-
            14:27 < jrandom> bla: end to end client messages are often (by default, always) bundled in garlic wrapping, containing an additional DeliveryStatusMessage that returns to the sender (through tunnels, of course), allowing the use of AES+sessionTags instead of ElGamal
            
-
            14:28 < bla> jrandom: (yes)
            
-
            14:28 <+detonate> as i said, you could just provide a link to the download page for the three things you need for i2p-bt to work, it's straight-forward and gets you exactly the same thing, i can't actually see a use for it besides a trojan
            
-
            14:28 < jrandom> later on we'll update I2CP (and the SDK) to allow the streaming lib to deliver that same data without requiring the DeliveryStatusMessage
            
-
            14:29 <@smeghead> detonate: i agree, he should have just submitted a patch to the official i2p-bt in the first place, forking was completely unnecessary and fostered immediate suspicioun
            
-
            14:30 <+detonate> indeed
            
-
            14:30 <@smeghead> *suspicion
            
-
            14:31 < jrandom> ok, anyone else have anything to bring up for the meeting?
            
-
            14:31 < ant> <drakoh> hi people ! wanted to know, is there anything special with the network ?
            
-
            14:32 <@smeghead> because of the nature of i2p, applications developed for it require a greater measure of openness with end users and cooperation among developers
            
-
            14:32 < jrandom> drakoh: see the weekly status notes
            
-
            14:32 < bla> quit
            
-
            14:32 < ant> <drakoh> no I mean something strange ...
            
-
            14:32 <@smeghead> i2p users will always be naturally paranoid to some extent, and it's our duty to do what we can to dispel any concerns we possibly can
            
-
            14:32 < ant> <drakoh> like I lost all my peers
            
-
            14:33 < jrandom> aye, agreed smeghead.  for anonymity or security software, especially software dealing with a trojan-laden field such as filesharing, its critical to be open.
            
-
            14:33 < jrandom> drakoh: ok, hold on, we can debug that once the meeting is over
            
-
            14:33 < ant> <drakoh> woops sorry
            
-
            14:33 < jrandom> ok, speaking of the meeting being over...
            
-
            14:34  * jrandom winds up
            
-
            14:34  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting134.html b/www.i2p2/pages/meeting134.html
deleted file mode 100644
index c4485ea8..00000000
--- a/www.i2p2/pages/meeting134.html
+++ /dev/null
@@ -1,177 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 134{% endblock %}
-{% block content %}
            I2P dev meeting, March 22, 2005
            
-
            
-
            13:01 <@jrandom> 0) hi
            
-
            13:01 <@jrandom> 1) 0.5.0.3
            
-
            13:01 <@jrandom> 2) batching
            
-
            13:01 <@jrandom> 3) updating
            
-
            13:01 <@jrandom> 4) ???
            
-
            13:01 <@jrandom> 0) hi
            
-
            13:01  * jrandom waves
            
-
            13:01 <@jrandom> the just-now-posted weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html
            
-
            13:02 <+detonate> hi
            
-
            13:02 <+cervantes> 'lo
            
-
            13:02 <@jrandom> jumpin' right in to 1) 0.5.0.3
            
-
            13:02 <@jrandom> the release came out a few days ago, and reports have been positive
            
-
            13:02 <+cervantes> jrandom: let us know when the blue dancing dwarves climb onto your monitor and we'll stop the meeting early
            
-
            13:03 <@jrandom> heh cervantes 
            
-
            13:03 <@jrandom> (thank Bob for editable meeting logs ;)
            
-
            13:04 <@jrandom> i dont really have much to add wrt 0.5.0.3 than whats in that message
            
-
            13:04 <@jrandom> anyone have any comments/questions/concerns on it?
            
-
            13:04 < bla> jrandom: Any new measurements on the fast-peers-selection code?
            
-
            13:05 <@jrandom> ah, i knew there was something else in 0.5.0.3 that i had neglected ;)
            
-
            13:06 <@jrandom> i dont have any hard metrics yet, but anecdotally the fast peer selection has found the peers that i know explicitly to be 'fast' (e.g. routers on the same box, etc)
            
-
            13:07 < bla> jrandom: Sometimes, eepsites still require a number of retries to find a good tunnel to use
            
-
            13:07 <@jrandom> reports have come in for fairly reasonable throughput rates on occation as well (in the 10-20KBps range), but thats still not frequent (we still have the parameters tuned down)
            
-
            13:08 <+ant> <Connelly> oops there's a meeting
            
-
            13:09 <@jrandom> hmm, yes, i've found that reliability still isn't where it need to be.  retrying more than once really isn't a solution though - if a site doesnt load after 1 retry, give it 5-10m before retrying
            
-
            13:09 <@jrandom> what i've seen on the net though is some not-infrequent-enough transport layer delay spikes
            
-
            13:10 <@jrandom> e.g. taking 5-20+ seconds just to flush a 1-2KB message through a socket
            
-
            13:10 <@jrandom> tie that up with a 5 hop path (2 hop tunnels) and you can run into trouble
            
-
            13:11 <@jrandom> thats actually part of whats driving the batching code - reducing the # of messages to be sent
            
-
            13:13 <@jrandom> ok, anyone else have any questions/comments/concerns on 0.5.0.3?
            
-
            13:13 < bla> jrandom: Looks good. I will ask more about it in the next "section"
            
-
            13:14 <@jrandom> w3rd, ok, perhaps we can move on there then - 2) batching
            
-
            13:15 <@jrandom> the email and my blog (jrandom.dev.i2p</spam>) should describe the basics of whats planned
            
-
            13:15 <@jrandom> and, well, really its some pretty basic stuff
            
-
            13:15 <@jrandom> the current preprocessor we have was the simplest possible one to implement (class name: TrivialPreprocessor) ;)
            
-
            13:16 <@jrandom> this new one has some tunable parameters for batching frequency, as well as some outbound tunnel affinity within individual tunnel pools (where we try to select the same outbound tunnel for subsequent requests for up to e.g. 500ms, so that we can optimize the batching)
            
-
            13:17 <@jrandom> that's about all i have to add on that though - any questions/comments/concerns?  
            
-
            13:18 < bla> Does this require all participating nodes to run the new preprocessor, or can a mix of Trivial/NewOne coexist?
            
-
            13:18 <+Ragnarok> this will add .5 s to latency, right?
            
-
            13:19 <@jrandom> bla: nah, this preprocessor is only used on the tunnel gateway, and its up to that gateway to decide how or whether to batch
            
-
            13:20 <@jrandom> Ragnarok: not usually - message 1 may be delayed for up to .5s, but messages 2-15 get transferred much faster than they would have otherwise.  its also a simple threshold - as soon as a full tunnel message worth of data is available, its flushed
            
-
            13:20 <+Ragnarok> cool
            
-
            13:20 <+Ragnarok> how much overhead does it save?
            
-
            13:21 <@jrandom> substantial ;)
            
-
            13:21 <+Ragnarok> substantial is good, if vague :P
            
-
            13:21 <@jrandom> look on your http://localhost:7657/oldstats.jsp#tunnel.smallFragments
            
-
            13:21 <@jrandom> compare that to #tunnel.fullFragments
            
-
            13:22 < bla> jrandom: Does this concern endpoint->IB-gateway communication only? 
            
-
            13:22 <@jrandom> with batching, the ratio of full to small will go up, and the # of pad bytes in the small will go down
            
-
            13:23 <@jrandom> bla: hmm, it concerns all tunnel gateways, whether inbound or outbound
            
-
            13:24 < mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events
            
-
            13:24 < bla> jrandom: ok
            
-
            13:24 < mihi> can there be a frational number of fragments?
            
-
            13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events
            
-
            13:25 <@jrandom> heh mihi
            
-
            13:25 <@jrandom> (that small: 746 means that on those 692k messages, 746 out of 996 bytes were wasted pad bytes!)
            
-
            13:26 <@jrandom> well, not quite wasted - they served their purpose
            
-
            13:26 <+detonate> needless overhead anyway
            
-
            13:27 <@jrandom> yep, much of which we should be able to shed with the batching preprocessor
            
-
            13:28 <@jrandom> unfortunately, that won't be bundled in the next release
            
-
            13:28 <@jrandom> but it will be bundled in the 0.5.0.6 rev (or perhaps 0.5.1)
            
-
            13:28 <@jrandom> erm, 0.5.0.5, or 0.5.1
            
-
            13:28  * jrandom gets confused with #s
            
-
            13:29 < bla> jrandom: How come not?
            
-
            13:29 <+cervantes> hash and pills...damn
            
-
            13:30 <@jrandom> !thwap cervantes 
            
-
            13:30 <@jrandom> bla: there's a bug in 0.5.0.3 (and before) where the fragmented message handler will cause subsequent fragments within the same tunnel message to be discarded
            
-
            13:31 <@jrandom> if we deployed the batching preprocessor directly, we'd have a substantial number of lost messages
            
-
            13:31 <@jrandom> its not a worry, we've got other neat stuff up our sleeves though, so this coming 0.5.0.4 won't be totally boring ;)
            
-
            13:31 < bla> jrandom: Ah, so that
            
-
            13:32 < bla> jrandom: Ah, so that is why we have to do that after 0.5.0.4 is mainstream.. I see. Thnx.
            
-
            13:33 <@jrandom> yeah, it'd be nice if the fragment handler was able to deal with it, and it does, generally, it just releases the byte buffer too soon, zeroing out subsequent fragments (oops)
            
-
            13:33 <@jrandom> ok, anything else on 2), or shall we move on to 3) updating?
            
-
            13:35 <@jrandom> ok, as mentioned in the status notes (and discussed for a while in various venues), we're going to add some functionality for simple and safe updating that doesn't require the end user to go to the website, read the mailing list, or read the topic in the channel :)
            
-
            13:36 <+detonate> cool
            
-
            13:36 <@jrandom> smeghead has put together some code to help automate and secure the process, working with cervantes to tie in with fire2pe as well as the normal routerconsole
            
-
            13:37 <@jrandom> the email lists the general description of whats going to be available, and while most of it is functional, there are still a few pieces not yet fully hashed out
            
-
            13:37 <@jrandom> unlike the batching, this /will/ be available in the next rev, though people won't be able to make much use of it until 0.5.0.5 (when it comes time to update)
            
-
            13:39 <+Ragnarok> so... what's the cool stuff for 5.0.4, then?
            
-
            13:42 <@jrandom> with the update code comes the ability to pull announcement data, displaying e.g. a snippet of news on the top of the router console.  in addition to that, as part of the update code we've got a new reliable download component which works either directly or through the eepproxy, retrying and continuing along the way.  perhaps there'll be some relatd features built off that, but no promises
            
-
            13:42 <+Ragnarok> neat
            
-
            13:43 <@jrandom> ok, anyone else have any questions/comments/concerns on 3) updating?
            
-
            13:45 <@jrandom> if not, moving on to 4) ???
            
-
            13:45 <@jrandom> anything else anyone wants to bring up?  i'm sure i've missed soem things
            
-
            13:45 <+detonate> i2p's known to work with the sun jvm in OpenBSD 3.7 :)
            
-
            13:45 <@jrandom> nice!
            
-
            13:47 < bla> What is the status on the UDP transport?
            
-
            13:48 <+detonate> udp is going to be messy, i think it would be better to steal the pipelining code from bt and adapt it ;)
            
-
            13:48 <@jrandom> *cough*
            
-
            13:49 <@jrandom> i dont expect there to be much trouble, but there's certainly work to be done
            
-
            13:49 <@jrandom> how the queueing policy operates, as well as the bw throttling for admission to the queue will be interesting
            
-
            13:50 < bla> Who was doing that prelim work?
            
-
            13:50 <@jrandom> bla: detonate and mule
            
-
            13:50 <+detonate> yeah.. i've been slacking off the last month or so though
            
-
            13:50 < bla> detonate: I assume you jest, with your BT remark?
            
-
            13:51 <+detonate> i'm half-serious
            
-
            13:51 <+detonate> you could at least cut the thread count for the transport in half if you did that
            
-
            13:51  * jrandom flings a bucket of mud at detonate 
            
-
            13:51 < jdot> woohoo.  my router is now running on my dedicated server rather than my POS cable connection.
            
-
            13:51 <@jrandom> nice1 jdot 
            
-
            13:52 <@jrandom> we'll be able to get by with 3-5 threads in the transport layer for all comm with all peers
            
-
            13:52 < bla> detonate: But half is not going to cut it, when the net becomes large (> couple hundred nodes)
            
-
            13:52 < jdot> with 1000GB of b/w at its disposal
            
-
            13:53 < jdot> unforunately j.i2p and the chat.i2p will be down for a few more hours while i migrate things
            
-
            13:53 < duck> detonate: addressbook on halt too?
            
-
            13:53 <+detonate> yeah, it's on halt too
            
-
            13:54 <+detonate> the only thing that isn't on halt is the monolithic profile storage, i was meaning to get that working later today
            
-
            13:54 <@jrandom> w3rd
            
-
            13:54 <+detonate> then i2p won't fragment the drive massively
            
-
            13:54 < jdot> jrandom: as far as BW limits go, are they averages?
            
-
            13:54 <+frosk> modern filesystems don't fragment, silly
            
-
            13:55 <+detonate> ntfs does
            
-
            13:55 <@jrandom> jdot: the bandwidth limits are strict token buckets
            
-
            13:55 <@jrandom> jdot: if you set the burst duration out, thats how long of a period it averages out through
            
-
            13:56 <@jrandom> (well, 2x burst == period)
            
-
            13:56 <@jrandom> ((ish))
            
-
            13:56 < jdot> hmmm...  well i have 1000GB and want i2p to be able to take up to 800GB/mo....
            
-
            13:56 <+ant> <mihi> detonate: ntfs stores really small files in mft which means nealy no fragmentation
            
-
            13:57 < jdot> and i dont care what it bursts to
            
-
            13:57 <+detonate> well, when you run the defragmenter, it spends 10 minutes moving all 6000 profiles around.. so they must fragment
            
-
            13:58 <@jrandom> jdot: hmm, well, 800GB is probably more than it'll want to push anyway, so you can probably go without limits ;)  
            
-
            13:58 <@jrandom> otoh, if you could describe a policy that you'd like implemented, we might be able to handle it
            
-
            13:58 < jdot> jrandom: i'll do that for now and see how it works
            
-
            13:58 < bla> detonate: NTFS, IIRC, is a journalling FS. So even a monolotic file will get fragmented if you write small portions to it 
            
-
            13:58 <+detonate> everything gets written at once
            
-
            13:59 <+detonate> and read at once
            
-
            13:59 < bla> detonate: Ok. I see.
            
-
            13:59 < jdot> jrandom: well, lets wait until we figure out if it'll even be a problem.
            
-
            13:59 < bla> detonate: Good work in that case!
            
-
            13:59 <+detonate> i'd be interested in knowing how much usage there really is if you leave it uncapped
            
-
            14:00 <+detonate> on a good connection
            
-
            14:00 < jdot> i'm interested too!
            
-
            14:00 <@jrandom> my colo routers run uncapped, though cpu constrained
            
-
            14:00 <+Ragnarok> can you use a bitbucket to average over a month?
            
-
            14:00 < jdot> jrandom: cpu contrianed?  what kind of cpu?
            
-
            14:01 <@jrandom> 4d transfer 3.04GB/2.73GB
            
-
            14:01 <+detonate> hmm, was expecting less
            
-
            14:01 <@jrandom> jdot: cpu constrained because i run 3 routers on it, plus a few other jvms, sometimes profiling
            
-
            14:01 <+detonate> must be those bt people
            
-
            14:01 <+detonate> once the batching stuff is online, it would be interesting to see how that changes
            
-
            14:02 <@jrandom> detonate: some of that transfer is also me pushing 50MB files between itself ;)
            
-
            14:02 <+detonate> heh
            
-
            14:02 < jdot> ahh.  ok.  well, we'll see how this system does.  its an AMD XP 2400 w/ 512MB and a 10Mbit connection
            
-
            14:02 <@jrandom> Ragnarok: token buckets dont really work that way
            
-
            14:02 <@jrandom> jdot: word, yeah, this is a p4 1.6 iirc
            
-
            14:03 <@jrandom> Ragnarok: in a token bucket, every (e.g.) second you add in some tokens, according to the rate.  if the bucket is full (size = burst period), the tokens are discarded
            
-
            14:04 <@jrandom> whenever you want to transfer data, you need to get a sufficient amount of tokens
            
-
            14:04 <@jrandom> (1 token = 1 byte)
            
-
            14:04 <+Ragnarok> I know how they work... what happens if you just make the bucket really big?
            
-
            14:05 <+detonate> then you never stop sending data
            
-
            14:05 <+detonate> if it's infinite in size
            
-
            14:05 <+detonate> err, and it's filled with tokens
            
-
            14:05 <@jrandom> if its really big, it may go out and burst to unlimited rates after low usage
            
-
            14:06 <@jrandom> though perhaps thats desired in some cases
            
-
            14:07 <@jrandom> the thing is, you can't just set the token bucket to 800GB, as that wouldnt constrain the total amount transferred
            
-
            14:08 <+detonate> you need a field there where you can set the number of tokens per second, then you can just divide the bandwidth usage per month by the number of seconds
            
-
            14:08 <+detonate> :)
            
-
            14:10 <@jrandom> thats the same as just setting the rate averaged over the month, which would be unbalanced.  but, anyway, lots of scenarios available - if anyone has any that address their needs that can't be met with whats available, please, get in touch
            
-
            14:10 <+Ragnarok> but if you set the rate to the average you want... I think 308 kB/s here, and then set the bitbucket to something very larger... why doesn't that work?
            
-
            14:11 <+Ragnarok> s/larger/large/
            
-
            14:12 <+detonate> well, you could set it so that it never sends more than 800GB/44000 in a 60 second burst period
            
-
            14:12 <+detonate> 44000 being roughly the number of minutes in a month
            
-
            14:13 <@jrandom> the bucket size / burst duration describes how much we'll send without constraint, and most people /do/ want constraints, so the router doesnt gobble 10mbps for 5 minutes while draining the bucket (or whatever)
            
-
            14:14 <@jrandom> an additional throttle of tokens coming out of the bucket is also possible (and should that throttle have its own token bucket, and that bucket have its own throttle, etc)
            
-
            14:16 <+Ragnarok> I thought the bucket only got paid into when there was bandwidth not being used
            
-
            14:16 <@jrandom> tokens are added to the bucket at a constant rate (e.g. 64k tokens per second)
            
-
            14:17 <@jrandom> anything that wants bandwidth always asks the bucket
            
-
            14:18 <+Ragnarok> ah.. ok
            
-
            14:19 <@jrandom> ok cool, anyone else have anything they want to bring up for the meeting?
            
-
            14:21 <@jrandom> ok if not
            
-
            14:21  * jrandom winds up
            
-
            14:21  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting135.html b/www.i2p2/pages/meeting135.html
deleted file mode 100644
index ea9b0bea..00000000
--- a/www.i2p2/pages/meeting135.html
+++ /dev/null
@@ -1,125 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 135{% endblock %}
-{% block content %}
            I2P dev meeting, March 29, 2005
            
-
            
-
            13:13 < jrandom> 0) hi
            
-
            13:13 < jrandom> 1) 0.5.0.5
            
-
            13:13 < jrandom> 2) UDP (SSU)
            
-
            13:13 < jrandom> 3) Q
            
-
            13:13 < jrandom> 4) ???
            
-
            13:13 < jrandom> 0) hi
            
-
            13:13  * jrandom waves
            
-
            13:13  * smeghead particles
            
-
            13:13 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000661.html
            
-
            13:14 < jrandom> (an hour early *mumblemumble*)
            
-
            13:14 < jrandom> anyway, jumping in to 1) 0.5.0.5
            
-
            13:15 < jrandom> as mentioned in the status notes, there'll be a new release later this evening
            
-
            13:15 < jrandom> everyone who is not yet on 0.5.0.4 should upgrade ASAP, as you'll be unable to talk to 0.5.0.5 users
            
-
            13:15 < jrandom> all 0.5.0.4 users should upgrade as soon as 0.5.0.5 is out, as well
            
-
            13:16 <@smeghead> will the update work through the new trusted update facility in the router console?
            
-
            13:17 < jrandom> yes and no
            
-
            13:17 < jrandom> of course, 0.5.0.4 has a bug in the NewsFetcher, where it doesn't write to a temp file, but instead resumes /over/ the existing file 
            
-
            13:18 < jrandom> so, given the way that the NewsFetcher detects updates, it won't see the later "hey, 0.5.0.5!  get it!" info
            
-
            13:18 < zzz> yes if you want to wait 12 hours? there's no 'update now' button, is there?
            
-
            13:18 < jrandom> otoh, once 0.5.0.5 is out and the news.xml is updated, 0.5.0.4 users can delete the file and it'll fetch it, detect it, and let you update
            
-
            13:19 <@smeghead> what's the name of this file?
            
-
            13:19 <@smeghead> oh ic
            
-
            13:19 < jrandom> zzz: if news.xml doesn't exist or if it hasn't been modified in 12 hours, a new rev is fetched
            
-
            13:20 < jrandom> there'll be a new i2pupdate.zip made available, as well as i2pupdate.sud
            
-
            13:20 < jrandom> (though for later revs, the .zip may not be provided)
            
-
            13:20 <@smeghead> should news.xml be in the base install dir?
            
-
            13:20 < jrandom> smeghead: docs/news.xml
            
-
            13:21 <+Myo9> Would it not good to get updates anonymous by default?
            
-
            13:21 <+Myo9> s/not/"not be"/
            
-
            13:22 < jrandom> Myo9: last week bla offered a counterpoint to that - the fact that you're running i2p is not secret, and using your eepproxy to fetch it could let dev.i2p see what destination is used
            
-
            13:22 <+frosk> anyone can tell you're running a router anyway
            
-
            13:22 <+ant> <mae^> lalalala
            
-
            13:22 < jrandom> just as it isn't a good idea to say on irc "hey, i'm restarting my router now", you dont want to associate your nyms with your router's activity
            
-
            13:23 <+Myo9> Ok.
            
-
            13:23 <+ant> * mae^ covers his ears
            
-
            13:23 < jrandom> but, on the other hand, if dev.i2p were truely an anonymous host (aka we didn't know it was dev.i2p.net), we'd need support for it :)
            
-
            13:23 <+ant> <mae^> dont talle me your goddamn network passwword
            
-
            13:24 <+ant> <mae^> damnit
            
-
            13:25 < jrandom> ok, anyone else have anything for 1) 0.5.0.5?
            
-
            13:25 <+ant> <mae^> lets all take take a minute to thank jr ight now
            
-
            13:25 <+ant> <mae^> silently and to yourself...
            
-
            13:25 <@smeghead> mae^: how about after the meeting
            
-
            13:25 < jrandom> heh, and to the donations page ;)
            
-
            13:25 <+ant> <mae^> or to him and private is ifine too
            
-
            13:26 <+ant> <mae^> or donate!
            
-
            13:26 < jrandom> ok, moving on to 2) UDP (SSU)
            
-
            13:26 < jrandom> we've got some thoughts on the new UDP protocol up on the web, and some critical feedback would be great
            
-
            13:27 <+ant> * cervantes notes the royal "we"
            
-
            13:27 <@smeghead> what is SSU
            
-
            13:27 < jrandom> well, i may be the one who types it in, but we've all been discussing the issues ;)
            
-
            13:28 < jrandom> SSU == Secure Semireliable UDP
            
-
            13:28 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD
            
-
            13:28 <+ant> <Eol> ??? got i2p up and running but can't resolve the .i2p sites .... states point browser at 4444 proxy but privoxy + tor already there ... site.i2p:4444 also fails ... ideas (w/o disabling privoxy or tor)
            
-
            13:28 <@smeghead> Eol: --> #i2p-chat
            
-
            13:29 < jrandom> Eol: perhaps some people in #i2p-chat can help, we're in the weekly dev meeting right now
            
-
            13:30 < jrandom> the basic gist of things is that we'll be able to work around most NATs, but unfortunately not all of 'em.  stats show that it'll work for a substantial % though (75-95, depending upon who you ask)
            
-
            13:31 < jrandom> ok, thats that, really - if anyone has any questions/comments/concerns, feel free to bounce me or the list an email anytime
            
-
            13:31 <+ant> * Eol apologizes
            
-
            13:31 <@smeghead> the remaining should rebel against their tyrannical system admins
            
-
            13:31 < jrandom> np eol
            
-
            13:32 <@smeghead> (or splurge for a real net connection)
            
-
            13:32 < jrandom> or get a non-symmetric NAT
            
-
            13:32 <+frosk> (or wait for restricted routes)
            
-
            13:32 < jrandom> yeah, or wait for 2.0 :)
            
-
            13:32 <@smeghead> because really, if you're concerned about freedom of information and anonymity, you shouldn't subject yourself to such NAT restrictions beyond your power anyhow
            
-
            13:32 < jrandom> smeghead: not everyone has a choice in the matter
            
-
            13:33 < jrandom> for instance, we had a user here the other day from the UAE, where there is ONE isp, with their own NAT
            
-
            13:33 <@smeghead> very true, but there are also people who expect us to bend over backwards to support them when they should be getting their power back
            
-
            13:33 <@smeghead> right
            
-
            13:34 < jrandom> aye, we'll support what we can, and what we can't, well, we can't, yet
            
-
            13:34 <@smeghead> the more people bend over for their ISPs, the more ISPs will restrict their users, and the harder our task becomes
            
-
            13:37 < jrandom> ok, anyone else have anything for 2) UDP?  if not, moving on to 3) Q
            
-
            13:37 < jrandom> hmm, looks like aum isn't up yet :)
            
-
            13:37 < jrandom> but basically, lots of cool stuff up @ http://aum.i2p/q/
            
-
            13:38 <@smeghead> i think i speak for aum when i say, "zzzzzzzzzzzzzZZZz"
            
-
            13:39 < jrandom> ok, i dont know if i have anything to add beyond whats in the email, beyond "neat stuff, talk to aum" :)
            
-
            13:40 < jrandom> ok, moving on at a rapid rate to 4) ???
            
-
            13:40 < jrandom> anyone else have anything they want to bring up?
            
-
            13:41 < cervantes> whoa a sub half hour?
            
-
            13:41 < jrandom> first i get the meeting notes out an hour early, and now this!
            
-
            13:41 <@smeghead> time for a filibuster
            
-
            13:41 < jrandom> *cough*
            
-
            13:41 <+postman> :)
            
-
            13:41 < jrandom> ok, if there's nothing else, i can get back to packaging up 0.5.0.5 and y'all can download when its ready :)
            
-
            13:41 <+postman> ok, just wanted to announce v2mail.i2p
            
-
            13:42  * cervantes wheels out a ming dynasty china gong
            
-
            13:42 < jrandom> ooh word postman 
            
-
            13:42 <+postman> as official portal to the v2mail deleopment
            
-
            13:42 <+postman> the html layout eats babys
            
-
            13:42 <+postman> but still i hope you find the docs/whitepapers there interesting
            
-
            13:43 <+postman> the documentation will be updated over the next week
            
-
            13:43 <@smeghead> could you say a little about what v2mail is?
            
-
            13:43 <@smeghead> v2 like version 2, or like the rocket?
            
-
            13:43 <+postman> smeghead: the new decentralized mailservice for i2p 1.0
            
-
            13:43 <+postman> smeghead: v2 refers to the version
            
-
            13:44  * postman does not plan any mailbombs or rockets :)
            
-
            13:44 <@smeghead> does it have specific dependencies on 1.0, or is that just a target?
            
-
            13:45 <+postman> there's still a few months work ahead - updates will be announced there
            
-
            13:45 <+frosk> nice effort, postman
            
-
            13:45 <+postman> smeghead: no, there're no dependencies on 1.0 - you'll still continue using susimail or your own mua
            
-
            13:46 <+postman> frosk: thanks 
            
-
            13:46 <+postman> jrandom: k, /me hands back the microphone
            
-
            13:47 <+ant> <cervantes> *distant clapping*
            
-
            13:47 < jrandom> w3rd, it definitely looks cool
            
-
            13:47 <+postman> cervantes: hey, what about your firefox plugin?
            
-
            13:47 < jrandom> ok, anyone else have anything to add to the meeting?
            
-
            13:48 <+ant> <cervantes> postman: eerm still plugin away at it
            
-
            13:49 <+postman> cervantes: me want play with it :)
            
-
            13:50 <+ant> <cervantes> just getting through a tedious part of managing user preferences...then all should be ready for a test release
            
-
            13:50 < jrandom> wikked
            
-
            13:50 <+postman> c00l :)
            
-
            13:52 <+ant> <cervantes> on an aside...I seem to have persuaded a few mozilla developers to look into modifying the codebase so I can easily add URI filtering into the plugin (ie I will be able to guarantee no connections to non-i2p addresses are being made)
            
-
            13:52 < jrandom> oh, nice!
            
-
            13:52 <+ant> <cervantes> but that won't be in firefox for a couple of releases
            
-
            13:53 < jrandom> great, please keep us updated
            
-
            13:53 <+ant> <cervantes> will do
            
-
            13:54 < jrandom> ok, if there's nothing else...
            
-
            13:54  * jrandom winds up
            
-
            13:54  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting136.html b/www.i2p2/pages/meeting136.html
deleted file mode 100644
index 946ef440..00000000
--- a/www.i2p2/pages/meeting136.html
+++ /dev/null
@@ -1,103 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 136{% endblock %}
-{% block content %}
            I2P dev meeting, April 5, 2005
            
-
            
-
            14:34 <@jrandom> 0) hi
            
-
            14:34 <@jrandom> 1) 0.5.0.5
            
-
            14:34 <@jrandom> 2) Bayesian peer profiling
            
-
            14:34 <@jrandom> 3) Q
            
-
            14:34 <@jrandom> 4) ???
            
-
            14:35 <@jrandom> 0) hi
            
-
            14:35  * jrandom waves
            
-
            14:35  * smeghead outsources his todo list to a parallel universe
            
-
            14:35 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-April/000675.html
            
-
            14:36 <@jrandom> might as well jump on in to 1) 0.5.0.5
            
-
            14:36 <+ant> * Connelly waves
            
-
            14:37 <+protokol> high everyone
            
-
            14:37 <@jrandom> as mentioned in the status notes (and the current history.txt), we've tracked down some very long lasting netDb bugs
            
-
            14:37 <@jrandom> in the past, we've been able to fudge it, but 0.5.0.5 forced us to start doing things "right", which is why its been biting us now
            
-
            14:39 <@jrandom> i expect we'll have a new release sometime tomorrow, so keep an eye out for the update link on your router console :)
            
-
            14:39 <+protokol> yey
            
-
            14:39 <@jrandom> actually, thats about all i have on that at the moment - anyone else have anything to add wrt 0.5.0.5?
            
-
            14:40 <+protokol> nope
            
-
            14:41 <@jrandom> ok, moving on to 2) Bayesian peer profiling
            
-
            14:41 <@jrandom> ah, damn, bla dropped off the channel a few mins back
            
-
            14:42 <@jrandom> well, anyway, I just wanted to point people out at bla's work exploring some more robust profiling techniques
            
-
            14:42 <+protokol> postponing 2?
            
-
            14:43 <@jrandom> check out the forum post and the link to theland.i2p for more info, and bounce bla your thoughts :)
            
-
            14:44 <@jrandom> ok, movin' on to 3) Q
            
-
            14:44 <@jrandom> aum: you up?
            
-
            14:44 <@jrandom> hmm, doesnt look like it
            
-
            14:45 <@jrandom> ok, lots of progress on the Q front, more details for getting involved in alpha testing up @ http://aum.i2p/q/ 
            
-
            14:45 <@jrandom> i'm sure we'll hear more on the list when there's an update available
            
-
            14:46 <+ant> <Connelly> Q works for me for retrieving content
            
-
            14:46 <@jrandom> yeah, its been working great for me as well, a few bumps here and there, but quite promising
            
-
            14:47 <+ant> <Connelly> my Q server stored 2 small items, then got stuck at 100% cpu usage until i killed it
            
-
            14:47 < zzz> for those who haven't seen it check out my q front end http://flock.i2p/cgi-bin/q
            
-
            14:47 <@jrandom> zzz: that is quite kickass
            
-
            14:48  * jrandom forgot the url to that when writing up the status notes (d'oh)
            
-
            14:50 <@jrandom> ok, anything else on 3) Q?  or shall we move on to 4) ???
            
-
            14:50  * jrandom considers us moved
            
-
            14:51 <@jrandom> anyone have anything else they'd like to bring up for the meeting?
            
-
            14:51 <+ant> <Connelly> i've coding an http/html filter for i2p
            
-
            14:51 <+protokol> yes
            
-
            14:51 <+protokol> ian clarke is a troll on slashdot
            
-
            14:51 <+ant> <Connelly> been coding
            
-
            14:51 <+ant> <Connelly> should be more safe than freenet's html filterer
            
-
            14:51 <+ant> <Connelly> if i run out of time i'll just incorporate freenet's filterer
            
-
            14:51 <@jrandom> cool Connelly, how is it coming along?
            
-
            14:52 <@jrandom> protokol: and you're a troll in #i2p ;)
            
-
            14:52 <+ant> <Connelly> so in the end we should have an html filterer for i2p
            
-
            14:52 <+ant> <Connelly> got html filtering done, now working on css, still haven't looked at header filtering
            
-
            14:53 <+ant> <Connelly> it's very paranoid :)
            
-
            14:53 <@jrandom> bitchin
            
-
            14:53 <+protokol> whitelist?
            
-
            14:53 <@duck> does it let anything trough at all?
            
-
            14:53 <+ant> <Connelly> yeah
            
-
            14:53 <+protokol> if so, what is currently disallowed
            
-
            14:53 <+protokol> (of any importance)
            
-
            14:55 <+ant> <Connelly> disallowed of significance: frames and iframes, scripting, optgroup
            
-
            14:55 <+ant> <Connelly> meta
            
-
            14:55 <+ant> <Connelly> embedded objects
            
-
            14:56 <@jrandom> neat.  i'm looking forward to seeing how things progress - any eta on when we could try rigging it up with the eepproxy?
            
-
            14:56 <+ant> <Connelly> i'll probably have an alpha in 1-2 weeks
            
-
            14:57 <+ant> <Connelly> so we can test out how it works
            
-
            14:57 < jrandom2p> kickass
            
-
            14:58 <+ant> <Connelly> it allows forms, cookies, content caching but those can be turned off in 'paranoid' mode
            
-
            14:58 <+protokol> why frames and iframes? can you just not block connections to non-i2p sites from them?
            
-
            14:59 <+ant> <Connelly> it has a cgiproxy like url navigator bar at the top
            
-
            14:59 <+ant> <BS314159> I suspect the hard thing would be blocking frames between different eepsites
            
-
            14:59 <+ant> <Connelly> i don't want that hijacked
            
-
            14:59 <+protokol> i mean can you just block connections
            
-
            14:59 <+ant> <Connelly> could make it like freenet's proxy where you just enter a url at the beginning
            
-
            14:59 <+protokol> yeah, frames can rock
            
-
            14:59 <+ant> <Connelly> and can't enter urls once you start browsing
            
-
            14:59 < jrandom2p> frames kill kittens
            
-
            15:00 <+ant> <BS314159> this has to be the oldest framewar ever.  excuse me, flamewar
            
-
            15:00 < jrandom2p> heh
            
-
            15:00 <+protokol> i said "can" rock
            
-
            15:00 <+ant> <BS314159> what we need is our own browser
            
-
            15:00 <@jrandom> and flying ponies
            
-
            15:01 <@jrandom> *cough*
            
-
            15:01 <+ant> <Connelly> i'd prefer an F-16 to a pony
            
-
            15:01 < Teal`c__> can i have a girl ?
            
-
            15:01 <+ant> <Connelly> i'll make an option for enabling frames
            
-
            15:01 <+protokol> Teal`c__: no
            
-
            15:02 <+ant> <BS314159> Is there a functioning I2P inproxy? bolas.mine.nu appears to be dead.
            
-
            15:02 <+protokol> from other eepsites, right?
            
-
            15:02 <@jrandom> BS314159: http://i2p.mine.nu/
            
-
            15:02 <+protokol> i2p.mine.nu
            
-
            15:02 < frosk> i2p.mine.nu
            
-
            15:02 <+ant> <BS314159> thanks
            
-
            15:02 <+ant> <BS314159> frames are safe if they're inside one eepsite.  frames are safe if all content is static
            
-
            15:03 <+ant> <BS314159> the only danger is if there's a form in one of the frames, since you might submit information to the wrong party
            
-
            15:04 <@jrandom> eh, i'm of the opinion the filter should only support what we *need* (and know is safe), and let actual end user demands expand functionality, rather than preemptively assume people will want some things
            
-
            15:04 <+ant> <BS314159> wise
            
-
            15:06 <@jrandom> ok, anyone else have anything for the meeting?
            
-
            15:06 < Teal`c__> sorry didn't know a meeting was on
            
-
            15:07 <@jrandom> heh no worry, you'll be immortalized in the meeting logs ;)
            
-
            15:07 <@jrandom> speaking of which
            
-
            15:07  * jrandom winds up
            
-
            15:07  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting137.html b/www.i2p2/pages/meeting137.html
deleted file mode 100644
index 72e4c90b..00000000
--- a/www.i2p2/pages/meeting137.html
+++ /dev/null
@@ -1,286 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 137{% endblock %}
-{% block content %}
            I2P dev meeting, April 12, 2005
            
-
            
-
            14:05 < jrandom> 0) hi
            
-
            14:05 < jrandom> 1) Net status
            
-
            14:05 < jrandom> 2) SSU status
            
-
            14:05 < jrandom> 3) Bayesian peer profiling
            
-
            14:05 < jrandom> 4) Q status
            
-
            14:05 < jrandom> 5) ???
            
-
            14:05 < hummingbird> 7) Profit
            
-
            14:06 < jrandom> damn, i messed up y'all's agenda :)
            
-
            14:06 < jrandom> hi
            
-
            14:06 < jrandom> weekly status notes posted /before/ the meeting up @ http://dev.i2p.net/pipermail/i2p/2005-April/000683.html
            
-
            14:06 < gott> jrandom: try it again
            
-
            14:06 <+cervantes> never mind, this meeting gott off onto a bad footing anyway
            
-
            14:06 < jrandom> *cough*
            
-
            14:06 < jrandom> jumping in to 1) Net status
            
-
            14:07 < jrandom> the big problem we were seeing with the netDb has been fixed and confirmed dead in the wild
            
-
            14:07 < jrandom> there are still some other issues, but it seems on the whole to be fairly reasonable
            
-
            14:08 < frosk> any idea what's causing the weird dnfs sometimes?
            
-
            14:08 < gott> confirm; I can get my illegal porn at record speeds for i2p now.
            
-
            14:08 <+cervantes> seems like that might be a hard one to pin down
            
-
            14:08 < jrandom> sneaking suspicion that its some confusion related to the throttle on the tunnel building
            
-
            14:09 < jrandom> pulling out those throttles will probably address it, but could be painful for users with slow CPUs
            
-
            14:09 < jrandom> otoh, perhaps we could make them optional, or someone could write some smarter throttling code
            
-
            14:10 < frosk> i see
            
-
            14:10 <+cervantes> the throttle seems much more pro-active than previous versions on my system
            
-
            14:10 < jrandom> yeah, we delay tunnel building when there are too many outstanding - before we just said "ok, we need to build X tunnels.  build 'em"
            
-
            14:10 <+cervantes> can we not make the threshold tweakable?
            
-
            14:11 < jrandom> aye, that we can
            
-
            14:11 < gott> jrandom: optional
            
-
            14:11 < gott> so users with thin i2p servents can still be productive
            
-
            14:12 < jrandom> my attention is focused elsewhere at the moment, so if someone wants to dig into that, the key method is TunnelPoolManager.allocateBuilds
            
-
            14:12 < jrandom> (or if no one jumps at it, i can toss in some tweaks when the next build comes out)
            
-
            14:13 <+cervantes> ........@    <-- tumbleweed
            
-
            14:13 < jrandom> :)
            
-
            14:13 < jrandom> anyone have anything else for 1) net status, or shall we move on to 2) SSU?
            
-
            14:14  * gott mutters something about too much talk and too little action when it comes to the i2p community
            
-
            14:14 <+cervantes> perhaps in the future we can introduce performance profiles into the console
            
-
            14:14 < gott> jrandom does too much on the development side.
            
-
            14:14 <+cervantes> so people can choose a preset batch of config options for high/med/low spec systems
            
-
            14:15 < jrandom> ooh good idea cervantes, there's lots of room for variants.  while we want to automatically tune ourselves as best we can, it may be easier for humans to do it
            
-
            14:15 <+cervantes> since there are many that seem to be using low spec machines and modem connections atm
            
-
            14:15 < gott> cervantes: yeah, excellent idea.
            
-
            14:15 <+cervantes> I should publish my fire2pe todo list...it has lots of shit like that in it ;-)
            
-
            14:16 < gott> based on processor and network speed primarily ?
            
-
            14:16 < jrandom> a site with a pseudonymous todo list would be nice
            
-
            14:16 < gott> that is a good idea.
            
-
            14:16 <+cervantes> well the bandwidth limiter should ideally take care of net speed
            
-
            14:16 < gott> in typical google-fashion, have a bunch of 'thin i2p servents' in your LAN.
            
-
            14:17 <+cervantes> jrandom: ugha.i2p?
            
-
            14:17 < jrandom> perhaps
            
-
            14:19 < jrandom> ok, anything else for 1) net status?
            
-
            14:19  * jrandom moves us on to 2) SSU
            
-
            14:19 < jrandom> Lots of progress on the UDP front (SSU == Secure Semireliable UDP)
            
-
            14:19 < gott> someone should alias 'i2pwiki.i2p' to that
            
-
            14:20 <+cervantes> I guess that's up to ugha ;-)
            
-
            14:20 < jrandom> the general overview of whats up is in the email, and a lot more technical details (and a pretty picture ;) is up on my blog
            
-
            14:21 <+ant> <godmode0> udp is safe ?
            
-
            14:21 <+ant> <godmode0> how :)
            
-
            14:21 < jrandom> http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html <-- how
            
-
            14:22 <+ant> <godmode0> hehe
            
-
            14:22 <+ant> <godmode0> i2p not found  right ip my computer
            
-
            14:22 < jrandom> sorry, if you don't have i2p installed, change "dev.i2p" to "dev.i2p.net"
            
-
            14:22 <+ant> <godmode0> have installled
            
-
            14:23 <+ant> <godmode0> but not work
            
-
            14:23 < jrandom> ok, perhaps we can debug that after the meeting 
            
-
            14:23 <+ant> <godmode0> oops in meeting again sorry
            
-
            14:23 < jrandom> hehe np
            
-
            14:25 < jrandom> anyway, as i said, the general plan of how things are going is in the email
            
-
            14:25 < jrandom> anyone have any questions/comments/concerns wrt SSU?
            
-
            14:26 <+Ragnarok> will throughput/latency be much different than the tcp transport?
            
-
            14:27 < jrandom> my hope is that the cause of the lag spikes will be addressed, but i'm not making any particular predictions.
            
-
            14:28 < jrandom> if we can keep latency in the same ballpark as it is now and get rid of the spikes, we can jack back up the throughput
            
-
            14:29 <+Ragnarok> cool
            
-
            14:29 < gott> will there be documentation on the implementation provided on i2p.net ?
            
-
            14:30 < jrandom> much of my time when i go offline to move will be writing up docs to be put on the website, yes
            
-
            14:30 < gott> awesome \m/
            
-
            14:30 < jrandom> we do have some pretty good implementation docs at the code level for the core and router, but no great overall router architecture docs yet
            
-
            14:31 < jrandom> anyway, if there's nothing else on 2) SSU, lets shimmy on over to 3) Bayesian peer profiling
            
-
            14:32 < jrandom> we got a brief update from bla earlier this evening, as shown in the status notes
            
-
            14:32 <+bla> I'm still here though... ;)
            
-
            14:33 < jrandom> bla may atcually still be around to give us any further thoughts or answer questions -
            
-
            14:33 < jrandom> ah, there you are
            
-
            14:33 < defnax> jrandom : what do you think about anounce i2p bittorrent Tracker, for security i think is not good or?, 
            
-
            14:34 <+bla> The IRC discussion quoted by jrandom shows the general idea. Summarized: 
            
-
            14:34 < jrandom> defnax: perhaps we can discuss that further in 5) 
            
-
            14:34 < defnax> ok i can wait 
            
-
            14:34 <+bla> The eventual idea is to use both round-trip-time information obtained from explicit tunnels tests, and implicit information from client-tunnel tests, into one node-speed estimation framework
            
-
            14:35 <+bla> For now, I use information obtained from explicit tunnel tests only, as for those tests, all participating peers are known.
            
-
            14:36 <+bla> A naive Bayesian classifier framework will be used to estimate a peer's speed, given the tunnels in which it has participated (in any position), and how fast those tunnels were
            
-
            14:36 <+bla> In order to compare things to a "ground truth", I've obtained "actual" peer speeds as listed in the status notes
            
-
            14:37 <+bla> Results are very prelim. But http://theland.i2p/estspeed.png shows the correlation between actual speeds, and speeds inferred using the Bayesian framework
            
-
            14:37 <+bla> Well. Any questions or comments?
            
-
            14:38 < jrandom> comment: looks promising.  
            
-
            14:38 <+ant> <BS314159> it seems like the total tunnel speed provides a hard lower bound on the speed of every participating peer
            
-
            14:38 <+detonate> comment: seem to be a few outliers
            
-
            14:38 <+ant> <BS314159> is that incorporated?
            
-
            14:39 < jrandom> BS314159: total tunnel speed?  oh, do you mean the testing node's net connection?
            
-
            14:40 <+bla> BS314159: That does provide a lower bound, yes. This is not addressed yet, but will be: The naive Bayesian framework enables weighting different samples (RTT measurements) to different degrees. Very fast RTTs will be weighted by a larger factor in the future
            
-
            14:40 <+ant> <BS314159> I mean the total bandwidth of a given tunnel
            
-
            14:40 <+bla> BS: The results show _latency_ measurements, for now
            
-
            14:40 <+ant> <BS314159> right.
            
-
            14:41 <+ant> <BS314159> nevermind, then
            
-
            14:41 < jrandom> ah, right, certainly.  throughput measurements will require further modifications to test with different size messages
            
-
            14:41 < jrandom> otoh, the implicit tunnel tests are driven by larger messages (typically 4KB, since thats the streaming lib fragmentation size)
            
-
            14:42 <+bla> detonate: Yes, there are outliers. There will always be _some_ (that's inherent to estimation, and modeling in general). However, the separation between really slow and really fast clients (putting a threshold at around 400 ms), is ok-ish
            
-
            14:42 <+detonate> ok
            
-
            14:43 <+bla> jrandom: Indeed. Once I get that working (in not a Java buff...), I'll also test using the larger messages
            
-
            14:43 <+bla> detonate: Now, I'd like to make the separation between fast and really-fast peers in a better way.
            
-
            14:43 < jrandom> cool, i'll see if i can bounce you a modified TestJob for that
            
-
            14:44 <+bla> I'll report when I have new results.
            
-
            14:44 < jrandom> kickass
            
-
            14:45 < jrandom> ok cool, anyone else have anything for 3) Bayesian peer profiling?
            
-
            14:46 < jrandom> if not, moving on to 4) Q status
            
-
            14:46 < jrandom> As mentioned in the email, rumor has it Aum is making progress on a new web interface
            
-
            14:47 < jrandom> i don't know much about it, or the status details on the rest of the Q updates, but i'm sure we'll hear more soon
            
-
            14:48 < jrandom> anyone have anything on Q to bring up?  or shall we make this a rapid fire agenda item and move on to 5) ???
            
-
            14:49 < jrandom> [consider us moved]
            
-
            14:49 < jrandom> ok, anyone have anything else to bring up for the meeting?
            
-
            14:50 < jrandom> defnax: announcing an i2p tracker to people in the i2p community would be great.  to the outside world it might be a bit rough, since we aren't at 0.6 yet
            
-
            14:50 < gott> Yes.
            
-
            14:50 < jrandom> (or 1.0 ;)
            
-
            14:50 < gott> I have some information to bring up on userland documentation efforts.
            
-
            14:51 <+mancom> just for the record: on mancom.i2p there is a c# implementation of Q's client api (in its first incarnation)
            
-
            14:51 < jrandom> oh cool, sup gott
            
-
            14:51 < jrandom> ah nice1 mancom
            
-
            14:51 < gott> I have previously written userland documentation for 0.4 i2p.
            
-
            14:52 < jrandom> which i unforutnately obsoleted by changing a whole bunch of stuff :(
            
-
            14:52 < gott> But it is entirely out-of-date with current i2p.
            
-
            14:52 < gott> Accordingly, I am very interested in writing a defacto set of documentation that we can either (a) bundle with i2p or (b) have access via i2p.
            
-
            14:53 < jrandom> wikked.  docs to bundle with i2p (localized to the user's language, etc) would be great
            
-
            14:53 <+cervantes> cool
            
-
            14:53 < gott> I don't suggest bundling, but it is still a possible option, as a user can't access eepsites to read the manual if he doesn't know how to use or configure i2p ;-)
            
-
            14:53 < gott> Okay.
            
-
            14:53 < gott> But is it overkill ?
            
-
            14:53 <+ant> <BS314159> what respectable program comes without man pages?
            
-
            14:53 <+cervantes> and is it worth waiting til 1.0?
            
-
            14:54 < gott> That is another question.
            
-
            14:54 < jrandom> since development is fairly fluid, it might be worth focusing on context-specific help, rather than an overall user guide
            
-
            14:54 < gott> BS314159: these are not manpages, as it will be platform-independent. Probably HTML.
            
-
            14:54 <+cervantes> how much more structural changes are we due before then
            
-
            14:54 < jrandom> for instance, it'd be nice to have better docs describing what the different config options *mean*, what their implications are, etc.
            
-
            14:55 < gott> Okay, so I shall write an english and french localisation of a manual for i2p.
            
-
            14:55 <+jdot> actually, we could use the inproxy to access the documentation even w/o i2p being installed.
            
-
            14:55 < gott> Two major questions :
            
-
            14:55 < jrandom> those could be kept up to date by virtue of being *in* the interface itself
            
-
            14:55 <+cervantes> yeah context help would rock
            
-
            14:55 < gott> (1) Bundled or accessible via manual.i2p ?
            
-
            14:55 < gott> (2) For which version ?
            
-
            14:55 < gott> yes
            
-
            14:55 < jrandom> gott: i'm not sure it'd be wise to build a user guide yet
            
-
            14:55 < gott> that's a great idea
            
-
            14:56 < gott> do you mean to use the auto-update function to update the usermanual ?
            
-
            14:56 < gott> jrandom: okay
            
-
            14:56 < gott> but then how do you suggest context-specific help ?
            
-
            14:56 < jrandom> oh, we can certainly deploy updates to the docs with the update process
            
-
            14:56 <+cervantes> if/when it's time to do a manual then perhaps a manual.war can be dropped into a user's webapps folder if they want local access to the docs
            
-
            14:57 < gott> I am thinking of a user-manual.
            
-
            14:57 < gott> or a HOWTO.
            
-
            14:57 < gott> I have no idea what you mean by context-specific help.
            
-
            14:57 < gott> it's pretty straightforward.
            
-
            14:57 < jrandom> gott: for instance, a set of human (non-ubergeek) readable info explaining wtf things on /config.jsp mean.  that info would go *on* /config.jsp, or on an html page reachable from that config.jsp
            
-
            14:58 < jrandom> a user-manual or howto would be great, but not until 1.0
            
-
            14:59 < jrandom> there's already some work on that front in the forum @ http://forum.i2p.net/viewtopic.php?t=385
            
-
            14:59 < gott> jrandom: yes.
            
-
            14:59 < gott> well.
            
-
            14:59 < gott> the information on config.jsp is pretty straightfoward already 
            
-
            15:00 < jrandom> otoh, we see questions about what bandwidth limits actually do, how the burst rates work, etc here all the time.  it'd be great to have the answers on the page, rather than have people ask
            
-
            15:00 < gott> heh
            
-
            15:00 < jrandom> gott: its straightforward to you because you've been using i2p for almost two years
            
-
            15:00 < gott> nevermind, 'configtunnels.jsp' could use some work.
            
-
            15:00 < gott> okay.
            
-
            15:00 <+cervantes> straightforward to the initiated perhaps, a n00b would be lost
            
-
            15:01 < gott> this is, then, a more up-to-date selection of tasks :
            
-
            15:01 <+cervantes> not sure the best way to present the help from an interface perspective
            
-
            15:01 < gott> (1) Context-specific help on the webpages localised to user's language. A configuration variable can be set for the language interface, by default, loaded from $LANG path variable on linux
            
-
            15:02 < gott> I'm not sure how java figures out the default locale under windows.
            
-
            15:02 < gott> But this is a good start to localisation and documentation writing.
            
-
            15:03 < gott> (2) For version 1.0, a HOWTO _accessed_ via i2p
            
-
            15:03 < gott> I don't suggest bundling the HOWTO, as that is just overkill. Would be nice to keep i2p as small as possible, hmm ?
            
-
            15:03 < jrandom> dood, its html.  its tiny.  even if its huge, html compresses *really* well
            
-
            15:03 < jrandom> having a local manual would be very much preferred
            
-
            15:03 < jrandom> especially since we can push updates
            
-
            15:03  * gott shrugs
            
-
            15:04 < gott> I suppose.
            
-
            15:04 < gott> I just find it silly.
            
-
            15:04 < gott> when you can just download it via the web.
            
-
            15:04 < gott> but on the other hand, if the user can't figure out how to use i2p
            
-
            15:04 < gott> he can't.
            
-
            15:04 <+ant> <Synonymous2> Is aum around, i was looking at the specs for QuarterMaster
            
-
            15:04 <+ant> <Synonymous2> * In order to help client-side searching, all data items are accompanied
            
-
            15:04 <+ant> <Synonymous2>    by a simple metadata schema - so far, just consisting of:
            
-
            15:04 <+ant> <Synonymous2>     - key - text name of key
            
-
            15:04 <+jdot> put it on www.i2p.net so it is accessible via the intarweb and i2p.
            
-
            15:04 <+jdot> and always up to date
            
-
            15:05 < gott> yeah.
            
-
            15:05 < gott> well, just use the update mechanism.
            
-
            15:05 < gott> okay.
            
-
            15:05 < gott> so, finalising :
            
-
            15:05 < jrandom> sure, we can put it on the website too.  we can spam it all over the net if it helps ;)
            
-
            15:05 <+ant> <Synonymous2> I am wondering if Aum can implement the datastore so the metadata are seperated incase he wants to upgrade the storage system.  Remember when Freenet wanted to change the storage system but was stuck
            
-
            15:05 < gott> 1 : Localised interface and context-specific help.
            
-
            15:05 < gott> 2 : Localised HOWTO for version 1.0
            
-
            15:05 <+ant> <Synonymous2> oopse is this the meeting :)
            
-
            15:05 < gott> Any additions ?
            
-
            15:06 < gott> the HOWTO will cover a lot of extra i2p-network features.
            
-
            15:06 < gott> where to get the latest porn ( j/k )
            
-
            15:06 <+ant> <BS314159> manpage! :-)
            
-
            15:06 < gott> manpages aren't platform-independent
            
-
            15:06 < jrandom> cool, including things like Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto
            
-
            15:06 <+cervantes> the installer could be localised too I guess...
            
-
            15:06 < gott> the i2p network has a hilariously large amount of french users
            
-
            15:07 <+Ragnarok> you should clearly write the addressbook documentation I've never gotten around to :)
            
-
            15:07 < gott> I'm sure they would appreciate a localised interface so they don't have to look at the disgusting english language
            
-
            15:07 <+cervantes> hey it's mostly french already
            
-
            15:07 < gott> true.
            
-
            15:07 < gott> good ideas.
            
-
            15:08 < gott> well, that is all I had to say.
            
-
            15:08 < jrandom> ok cool, thanks gott, nice initiative
            
-
            15:08 < gott> for now, I shall start on the context-specific stuff
            
-
            15:08 < jrandom> Synonymous2: I'm not sure what Aum is doing on that front
            
-
            15:08 < jrandom> bitchin'
            
-
            15:08 < gott> and then, when a localisation option is added, the localised languages 
            
-
            15:08 <+bla> gott: Je _deteste_ Anglais! ;)
            
-
            15:09 < gott> moi aussi
            
-
            15:09 <+ant> <Synonymous2> Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto, i think the wiki article should be updated for i2p to add this, i'll do that
            
-
            15:09 <+cervantes> ewll you have william the conquerer to blame for that
            
-
            15:09 < jrandom> heh
            
-
            15:09 < gott> a wiki is good, but also non-official.
            
-
            15:09 < gott> the manual has the element of certification.
            
-
            15:09 < gott> it is more reassuring.
            
-
            15:10 <+ant> <Synonymous2> if ppl want to come and look that would be helpful too, the freenet wikipedia article is also good describing the tools for freenet.  As well, I see that the Freenet webpage is released under the GNU FDL, if i2p.net could do the same (or public domain) I could copy some stuff to wikipedia :)) if you want to do that
            
-
            15:10 <+cervantes> we'd still be speaking anglo-saxon otherwise
            
-
            15:10 < jrandom> everything i do which i 'have rights to' is released implicitly into the public domain
            
-
            15:11 <+ant> <Synonymous2> i thought it was, if you can put that as a blurb on the webpage that would be great at your convience, the ppl at wikipedia are anal bout copyright :>
            
-
            15:11 <+ant> <Synonymous2> :)))
            
-
            15:11 < gott> jrandom: all the localisation I write will be public domain
            
-
            15:11 < jrandom> otoh, outright copying the text is, er, not too helpful, as your copies will be out of date - just link to it, the web is there for a reason
            
-
            15:11 < gott> I don't give a damn about any licenses.
            
-
            15:12 < gott> also, last question :
            
-
            15:12 <+ant> <Synonymous2> i was going to copy a few things like the chart and some graphics hehe
            
-
            15:12 < gott> where are the .jsp for the router located ?
            
-
            15:12 < jrandom> gott: http://dev.i2p/cgi-bin/cvsweb.cgi/apps/routerconsole/jsp/
            
-
            15:13 < gott> ah
            
-
            15:13 < gott> so, locally, they are in a .jar ?
            
-
            15:13 < jrandom> gott: routerconsole.war
            
-
            15:13 < jrandom> but you can't really edit them there, as they're precompiled into java
            
-
            15:13  * gott nods
            
-
            15:13 < gott> Sure.
            
-
            15:14 < gott> Though, that's an inconvenience.
            
-
            15:14 < gott> when localisation comes out, that might be changed ?
            
-
            15:14 < jrandom> yep.  lots of options though.  if you work out the html that the jsps should render as, we can wire it in
            
-
            15:14 <+cervantes> Synonymous: http://www.i2p.net/licenses
            
-
            15:15 < gott> so you can have language packs
            
-
            15:15  * gott nods
            
-
            15:15 < gott> for now, it is just hardcoded
            
-
            15:15 < jrandom> localization in java works by loading up per-language properties files with resources
            
-
            15:15 < gott> but later on, it should be less restricted, I suggest
            
-
            15:15 < jrandom> right right
            
-
            15:16 < gott> awesome.
            
-
            15:16 < gott> well, I'll use anonymous CVS then ;-)
            
-
            15:16 < jrandom> bitchin'
            
-
            15:16 <+ant> <BS314159> bla: is your raw data available anywhere?
            
-
            15:16 < jrandom> bla has recently disconnected, but we'll see about getting some data available
            
-
            15:17 < gott> btw, do we have anyone running i2p on openbsd ?
            
-
            15:17 <+ant> <BS314159> it's be fun to let people try their own estimators
            
-
            15:17 <+ant> <BS314159> sister:...23?
            
-
            15:17 < jrandom> gott: yeah, i think detonate is
            
-
            15:18 <+ant> <BS314159> ack
            
-
            15:18 <+ant> <BS314159> cross-post
            
-
            15:18 <+ant> <BS314159> curses!
            
-
            15:18 < gott> is it even possible ? what are the java limitations regarding openbsd and i2p ?
            
-
            15:18 < gott> okay.
            
-
            15:18 < jrandom> BS314159: yeah, there's some good info about modifying your estimators up in the forum
            
-
            15:18 <+cervantes> long meeting
            
-
            15:18 < gott> if I ever have time, I might get it running and setup a port.
            
-
            15:18 < gott> but that is long off and someone will probably do it before me ;-)
            
-
            15:18 < jrandom> cervantes: check the logs, we've broken 2h before ;)
            
-
            15:19 < jrandom> ok, anyone else have anything for the meeting?
            
-
            15:20 < jrandom> if not
            
-
            15:20  * jrandom winds up
            
-
            15:20  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting138.html b/www.i2p2/pages/meeting138.html
deleted file mode 100644
index f7544722..00000000
--- a/www.i2p2/pages/meeting138.html
+++ /dev/null
@@ -1,106 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 138{% endblock %}
-{% block content %}
            I2P dev meeting, April 19, 2005
            
-
            
-
            14:05 <@jrandom> 0) hi
            
-
            14:05 <@jrandom> 1) Net status
            
-
            14:05 <@jrandom> 2) SSU status
            
-
            14:05 <@jrandom> 3) Roadmap update
            
-
            14:05 <@jrandom> 4) Q status
            
-
            14:05 <@jrandom> 5) ???
            
-
            14:05 <@jrandom> 0) hi
            
-
            14:05  * jrandom waves
            
-
            14:05 <@jrandom> weekly status notes (posted a sec ago) up @ http://dev.i2p.net/pipermail/i2p/2005-April/000708.html
            
-
            14:06  * maestro^ beatboxes
            
-
            14:06 <+cervantes> evening
            
-
            14:06 <+protokol> susi23: you there?
            
-
            14:06 <@jrandom> while y'all read those exciting notes, lets jump on in to 1) net status
            
-
            14:06 <+protokol> oops, meeting
            
-
            14:07 <@jrandom> i dont really have much to add beyond what it says though.  new release tomorrow, most likely, with the fixes incorporated so far, as well as some neat new contributions
            
-
            14:08 <@jrandom> anyone have any comments or concerns w/ the net status &&/|| the upcoming 0.5.0.7?
            
-
            14:10 <@jrandom> if not, moving on to 2) SSU status
            
-
            14:10 <+maestro^> i've been getting some of these errors: Wanted to build 2 tunnels, but throttled down to 0, due to concurrent requests (cpu overload?)
            
-
            14:10 <@jrandom> ah, yeah, thats the tunnel throttling issue
            
-
            14:10 <+protokol> will it support ftp?
            
-
            14:10 <@jrandom> its a bit... overzealous
            
-
            14:10 <+protokol> jk jk
            
-
            14:10 <@jrandom> !thwap protokol 
            
-
            14:10 <+maestro^> heh, ok
            
-
            14:12 <@jrandom> ok, as for SSU, there's been a bunch of updates in the last week, and still further changes locally not yet committed
            
-
            14:13 <@jrandom> i havent been making any history.txt entries for the updates though, since its not used by anyone yet, so only people on the i2p-cvs list get to read the exciting details ;)
            
-
            14:14 <@jrandom> otoh, in the last few days after things have been pretty much working, while streamlining its operation i've found some choke points in the SDK
            
-
            14:14 <@jrandom> (and in the jobQueue).  i've pulled those out now, locally, and testing continues.
            
-
            14:15 <@jrandom> we may have some alphas for the SSU transport this week, more likely this weekend though
            
-
            14:15 <@jrandom> not much more i have to say on that - anyone have any questions?
            
-
            14:16 <+Ragnarok> how much impact did the choke points have?
            
-
            14:17 <@jrandom> well, it varies - i'm measuring the impact upon the live net now, but on my local ssu network, two minor tweaks gave more than an order of magnitude improvement
            
-
            14:17 <@jrandom> but i don't expect that to occur on the live net
            
-
            14:17 <+Ragnarok> yikes
            
-
            14:18 <+Ragnarok> heh, ok
            
-
            14:18 <@jrandom> (at least, not until we move to 0.6 ;)
            
-
            14:20 <@jrandom> ok, following that lead, lets move to 3) Roadmap update
            
-
            14:21 <@jrandom> as mentioned in the notes, the dates and revs on the roadmap have been moved around.  0.5.1 dropped, with the further tunnel modifications pushed to 0.6.1
            
-
            14:21 <+cervantes> 3) Roadmap Skew
            
-
            14:21 <@jrandom> heh
            
-
            14:22 <@jrandom> yeah, when you run a fast CPU, it skews the clock more frequently.  similary... ;)
            
-
            14:22 <@jrandom> ^ry^rly
            
-
            14:23 <+cervantes> ooh is that a hint of an ego? I never would have thought! :)
            
-
            14:23 <@jrandom> but yeah, unfortunately, a 0.6 rev in april just isnt going to happen
            
-
            14:23 <@jrandom> hehe
            
-
            14:23 <@jrandom> cervantes: dont worry, its tempered by the fact that its taken 2 years to get this far ;)
            
-
            14:25 <@jrandom> we will probably have some -X builds for people to brea^Wtest SSU on the live net while i'm offline, but there won't be a 0.6 rev until i'm back
            
-
            14:25 <@jrandom> (and, like last year, i have no idea how long it'll take to get hooked up again, but hopefully less than a month)
            
-
            14:25 <+cervantes> heh, if anyone here is a little deserving of self-appreciation then I guess it would be you ;-)
            
-
            14:26 <+polecat> Where you going, jrandom ?
            
-
            14:27 <+cervantes> $somewhere
            
-
            14:27 <@jrandom> dunno
            
-
            14:27 <@jrandom> (thankfully, $somewhere is a runtime expression ;)
            
-
            14:27 <+cervantes> jrandom: do you envisage a months downtime?
            
-
            14:27 <+maestro^> jr: walk around the neighborhood and setup a wireless relay network from someone else's link ;]
            
-
            14:27 <@jrandom> depends on the internet situation where i end up cervantes.
            
-
            14:28 <@jrandom> i'm quite likely to hop online occationally of course, though
            
-
            14:28 <+protokol> polecat: lol
            
-
            14:28 <+cervantes> I would have though you would have got the relocation class method pretty slick by now
            
-
            14:28 < Teal`c> lets move to .6 now and work the bugs out as we go along
            
-
            14:28 <+cervantes> *thought
            
-
            14:28 <+cervantes> cool, Teal'c you can do Q&A
            
-
            14:29 <@jrandom> Teal`c: "work the bugs out" == fix the code == (have a coder who knows the code to fix it)
            
-
            14:29 < Teal`c> ya, I'd like that.
            
-
            14:29 < Teal`c> I know some perl
            
-
            14:29  * cervantes sets bugzilla > tealc@mail.i2p
            
-
            14:29 <@jrandom> word Teal`c, we can always use some help testing
            
-
            14:30 <@jrandom> especially in automation of tests
            
-
            14:31 <@jrandom> ok, anything else on 3) or shall we move to 4) Q status
            
-
            14:31 <+polecat> I see.  Good luck getting stable Internet back.
            
-
            14:31 <+ant> <jrandom> hrm, aum seems to be sleeping still
            
-
            14:31 <@jrandom> thanks. i'm sure i'll find a way ;)
            
-
            14:32 <@jrandom> ok, I don't really have much more to add beyond whats in the status notes
            
-
            14:32 <@jrandom> aum's code is in cvs now though, so the hardcore can grab it and start hacking
            
-
            14:32 <+maestro^> shweet
            
-
            14:33 <@jrandom> yeah, definitely.  currently things are all GPL (since one component links against I2PTunnel), but I hear aum is working on some refactoring so it'll end up LGPL
            
-
            14:34 <@jrandom> (but dont ask me what the implications of licensing is when it comes to xmlrpc ;)
            
-
            14:34 <@jrandom> ok, anyone have anything on 4) to bring up?
            
-
            14:36 <@jrandom> ok, if not, moving on to 5) ???
            
-
            14:36 <@jrandom> anyone have anything else to bring up for the meeting?
            
-
            14:36 <+polecat> I would like to say a few words for this occasion.
            
-
            14:37 <+polecat> Hinkle finkle dinkle doo.
            
-
            14:37 <@jrandom> mmmhmm.
            
-
            14:37 <@jrandom> ok, anyone have anything to bring up in a human language?  :)
            
-
            14:38 < defnax> what moving on 5?
            
-
            14:39 <+maestro^> long live spacerace! long live i2p!
            
-
            14:39 <@jrandom> hmm defnax?
            
-
            14:41 < defnax> on 5 o'clock in the morning?
            
-
            14:41 < defnax> in 5 hours?
            
-
            14:41 <+cervantes> wrt xmlrpc, copyright is retained on the specification, but no restrictions placed upon implementation
            
-
            14:42 <@jrandom> defnax: agenda item 5: "???", where we discuss other issues
            
-
            14:43 <+maestro^> jr: have you committed those optimization changes?
            
-
            14:43 <@jrandom> cervantes: my jab related to the question of whether using a GPL'ed app's xmlrpc API is viral (but merely a rhetorical question)
            
-
            14:43 <@jrandom> maestro^: nope
            
-
            14:43  * jrandom tests before committing
            
-
            14:43 <+maestro^> excellent! whats your eta on that?
            
-
            14:44 <@jrandom> later tonight, maybe, else tomorrow for the release
            
-
            14:45 <@jrandom> ok, if there's nothing else
            
-
            14:45  * jrandom winds up
            
-
            14:45  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting139.html b/www.i2p2/pages/meeting139.html
deleted file mode 100644
index 9e409d7a..00000000
--- a/www.i2p2/pages/meeting139.html
+++ /dev/null
@@ -1,64 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 139{% endblock %}
-{% block content %}
            I2P dev meeting, April 26, 2005
            
-
            
-
            14:10 <@jrandom> 0) hi
            
-
            14:10 <@jrandom> 1) Net status
            
-
            14:10 <@jrandom> 2) SSU status
            
-
            14:10 <@jrandom> 3) Unit test bounty
            
-
            14:10 <@jrandom> 4) ???
            
-
            14:10 <@jrandom> 0) hi
            
-
            14:10  * jrandom waves
            
-
            14:10 <@jrandom> (late) weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-April/000723.html
            
-
            14:10 < bla> hi
            
-
            14:11 <@jrandom> while y'all read that tome, lets jump on into 1) Net status
            
-
            14:12 <@jrandom> the previous set of problems we saw with some eepsites going offline in 0.5.0.6 seems to be resolved, though there are a few people who have been running into other problems with their sites
            
-
            14:13 <@jrandom> i've seen some increased torrent activity at some trackers as well, though it hasn't caused any problems on irc from what i can tell
            
-
            14:13 < laberhorst> net status: fairly well beside the not reachable prob :-)
            
-
            14:13 <@jrandom> heh
            
-
            14:13 <@jrandom> yeah, i'm stil not sure whats going on with your site. we can debug further after the meeting
            
-
            14:14 <@jrandom> other than that, anyone else have any questions/comments/concerns wrt the net status / 0.5.0.7?
            
-
            14:16 <@jrandom> ok, if not, moving on to 2) SSU status
            
-
            14:16 <@jrandom> [insert hand waving here]
            
-
            14:17 < Lorie> Good morning.
            
-
            14:17 <@jrandom> i know, i'm dragging my heels a bit by not pushing it out faster, and it does perform really well as is.  still, there are some issues i'm not comfortable with yet, so y'all will have to bear with me a bit during this testing
            
-
            14:18 <@smeghead> i commend you for not foisting crapware on us :)
            
-
            14:18 <@jrandom> i'm hoping this week we'll have some further live net tests though (fingers crossed)
            
-
            14:19 <@jrandom> well, i've foisted enough bugs on y'all so far
            
-
            14:19 < Lorie> you're dragging your heels, are you ?
            
-
            14:19  * Lorie eyes smeghead
            
-
            14:19 < bla> jrandom: Just to make things clear: We could even have an intermediate period in which clients can be both UDP and TCP?
            
-
            14:20 <@jrandom> bla: yes.  i've got a test network now with some TCP-only and some both TCP and UDP.  its kind of neat running the tunnels through both :)
            
-
            14:20 <@jrandom> the live net will actually handle that as well, ignoring any UDP addresses (for people who don't yet support it)
            
-
            14:20 <@smeghead> and that's given us lots of protein, but we don't want to over-indulge
            
-
            14:21 < bla> jrandom: Nice! That's good for the transition
            
-
            14:23 <@jrandom> aye, thats the hope.  still, there's lots of work to do[/obligatory]
            
-
            14:23 <@jrandom> while our transport is SSU - "SEMIreliable Secure UDP" - we still need to try to be kind of reliable
            
-
            14:24 <@jrandom> i've followed a bunch of research out there on the net, watching whats worked best, and while we could just be lazy and fire & forget, there's a lot to be gained by doing some simple tcp-esque reliability, which is what i'm hacking on now
            
-
            14:25 <@jrandom> otoh, since its just semireliable, if it doesn't get ACKed quickly we can just drop the message, rather than drop the connection
            
-
            14:26 < Lorie> yes
            
-
            14:26 < Lorie> do be reliable; time is a luxury one has
            
-
            14:27 <@jrandom> thats about all i have to bring up for 2) SSU status.  anyone have any questions/comments/concerns, or shall we move on to 3) Unit test bounty?
            
-
            14:28 < jrandom2p> consider us moved
            
-
            14:29 < jrandom2p> ok, duck posted up a good summary about whats up and the importance of the unit test bounty the other day, and there's a lot of detail referenced from the site.
            
-
            14:30 < jrandom2p> this is a good chance for someone to dig into i2p a bit and get a little cash back in the process ;)
            
-
            14:30 < jrandom2p> but anyway, y'all can read all that stuff.  does anyone have any questions on it?
            
-
            14:31 < jrandom2p> ok, if not, moving on to 4) ???
            
-
            14:32 <@smeghead> anyone tried that emma code coverage suite?
            
-
            14:32 < jrandom2p> there's been a lot of various things going on in the last week, though i'm not sure whats ready for discussion yet.  anyone have anything they want to bring up?
            
-
            14:33 < jrandom2p> not i
            
-
            14:33 <@duck> *hick*
            
-
            14:34 <@smeghead> either duck is inebriated, or he has spotted a redneck
            
-
            14:34 <@duck> !former
            
-
            14:35 < jrandom2p> (to evaluate as a shell command or c/java... ;)
            
-
            14:36 < jrandom2p> anyone else have anything to bring up for the meeting?
            
-
            14:36  * jrandom2p likes short meetings, leaves more time for coding
            
-
            14:36 <@smeghead> and drinking apparently :)
            
-
            14:36 <@duck> & drinking
            
-
            14:37 <@smeghead> bah lag
            
-
            14:37 < jrandom2p> heh
            
-
            14:38 < jrandom2p> ok, time to get back to dri^Wworking
            
-
            14:38  * jrandom2p winds up
            
-
            14:38  * jrandom2p *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting140.html b/www.i2p2/pages/meeting140.html
deleted file mode 100644
index b3d4bf58..00000000
--- a/www.i2p2/pages/meeting140.html
+++ /dev/null
@@ -1,199 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 140{% endblock %}
-{% block content %}
            I2P dev meeting, May 3, 2005
            
-
            
-
            14:08 < jrandom> 0) hi
            
-
            14:08 < jrandom> 1) Net status
            
-
            14:08 < jrandom> 2) SSU status
            
-
            14:08 < jrandom> 3) i2phex
            
-
            14:08 < jrandom> 4) awol
            
-
            14:08 < jrandom> 5) ???
            
-
            14:08 < jrandom> 0) hi
            
-
            14:08  * jrandom waves
            
-
            14:08 < jrandom> weekly status notes posted nearly an hour early @ http://dev.i2p.net/pipermail/i2p/2005-May/000738.html
            
-
            14:09  * Masterboy waves back:P
            
-
            14:10 < jrandom> ok, jumping into 1) Net status
            
-
            14:10 < jrandom> i don't really have too much more to add, though it does appear that we may be up for some turbulance from the azureus influx
            
-
            14:11 < jrandom> hopefully it'll hold up well enough though, we'll see
            
-
            14:11 < Masterboy> no big probs for me and i can't remember the little ones.
            
-
            14:11 < jrandom> heh cool
            
-
            14:11 < jrandom> anyone else have any questions/comments/concerns wrt the current net status?  
            
-
            14:11 < sirup> is azureus using out proxies?
            
-
            14:12 < jrandom> heh i hope not
            
-
            14:12 < jrandom> its probably just people trying it out after seeing the option listed
            
-
            14:12 <@smeghead> most will bugger off in a week or so
            
-
            14:13 < Masterboy> :D
            
-
            14:13 <+DrWoo> smeghead: that's not good
            
-
            14:13 < sirup> so they wrap two different networks under one hood
            
-
            14:13 <+cervantes> it's not mentioned in the az release notes
            
-
            14:13 <+cervantes> although it is listed in the plugins section
            
-
            14:14 < ant> <cat-a-puss> There is a link that mentions it on the left of their main page
            
-
            14:14 < jrandom> it'll be great once 0.6 is out and we can handle the increased user load
            
-
            14:14 <+DrWoo> jrandom: what is the current status of getting out a build to cope with more users?
            
-
            14:14 < jrandom> yeah, azureus is currently our largest referrer to the website, well more than even the /. references
            
-
            14:15 < jrandom> DrWoo: no chance.  
            
-
            14:15 < sirup> don't let that stress you and put out 0.6 too early
            
-
            14:15  * eAi sets unreasonable bandwidth limit to stop people haxoring my download speed
            
-
            14:15 < ant> <cat-a-puss> how big of a network will .6 support?
            
-
            14:15 < jrandom> DrWoo: 0.6 is the solution, and that'll be ready when its ready :)
            
-
            14:15 <+cervantes> there are 445 google hits for "i2p" and "azureus"
            
-
            14:15 < jrandom> heh eAi 
            
-
            14:16 <+cervantes> I must say I was impressed with the throughput of the test SSU net
            
-
            14:16 < Masterboy> w00t cervantes:)
            
-
            14:16 <+DrWoo> jrandom: you know I love ya but your shedule is slipping like a $5 hooker's panties ;)
            
-
            14:16 < jrandom> cat-a-puss: it removes our current bottleneck to the point that i don't see the next bottleneck clearly.  i hope it'll handle into the thousands.
            
-
            14:16 <+cervantes> managed to max out my DSL connection with a straight http file transfer
            
-
            14:17 < jrandom> damn straight DrWoo ;)  if it could be done faster, that'd be great, but i've got to move next week, so there really isn't any alternative
            
-
            14:17 < sirup> cervantes: 0 hops both ends ;)
            
-
            14:18 < jrandom> sirup: sure, but the point is the SSU transport was able to handle it
            
-
            14:18 <+DrWoo> jrandom: yikes that sux, good luck :)
            
-
            14:18 < Teal`c__> there is an alternative.  I'm calling toad, he'll finish it up while you're in tahiti
            
-
            14:18 <@smeghead> movin' on up, to the east side, to a deluxe apartment in the skyyyyy
            
-
            14:18 < shendaras> You have a place in mind, jrandom, or is it up in the air where you end up?
            
-
            14:19 <+cervantes> *mute*
            
-
            14:19 < jrandom> heh
            
-
            14:19 < jrandom> i think i know what country i'll end up in.  beyond that, not really
            
-
            14:19 < jrandom> ok, anyway, back onto the agenda
            
-
            14:19 < jrandom> anything else on 1) Net status, or shall we move on to 2) SSU status?
            
-
            14:20 < Masterboy> move
            
-
            14:20 < jrandom> consider us moved
            
-
            14:21 < jrandom> ok, as described in the status notes and as cervantes said a minute ago, things are looking promising
            
-
            14:22 < jrandom> this first round of live net tests caught a few bugs but also helped expose some of the tradeoffs in bandwidth, latency, and tcp-friendliness
            
-
            14:23 < Masterboy> how can one join a test net?:P
            
-
            14:23 < jrandom> thats the thing - the ssu testing is done on the live net
            
-
            14:24 < jrandom> if you look in the netDb, you'll see that some peers have both TCP and SSU addresses, while almost everyone else has just a TCP address.  
            
-
            14:24 < jrandom> peers who know how to talk via SSU try that first, but fall back on TCP if the SSU port isn't reachable.
            
-
            14:25 < jrandom> still, and i can't emphesize this enough, ssu is not production ready.  it will break, and it will cause problems, so people should not use it except as part of explicit tests
            
-
            14:25 < Masterboy> thanks:)
            
-
            14:26 < jrandom> for now, everyone should disable ssu, but in the next day or so there'll be more info made available on my blog for the second round of tests
            
-
            14:27 < jrandom> ok, i think that and the email covered pretty much what i have to bring up wrt ssu.  anyone have any questions/comments/concerns?
            
-
            14:27 < Teal`c__> jrandom: can we use ssu while your gone ?
            
-
            14:28 < jrandom> probably, but people may want to talk to other users to see if it acts up, and if it does, just disable it
            
-
            14:29 < shendaras> What's your new SACK technique? =)
            
-
            14:29 < jrandom> i've still got almost a week of hacking time left, so there's going to be more improvement
            
-
            14:30 <+bla> jrandom: I was just thinking... When there is a SSU connection between two nodes, do they drop the TCP connection between them (since that's not necessary then)?
            
-
            14:30 < jrandom> heh shendaras, its just exploiting the small message size and fixed fragmentation to let the receiver transmit explicit ACKs/NACKs for a full message in a bitfield, rather than ACKing or NACKing each fragment separately
            
-
            14:31 < jrandom> bla: correct, they never establish a TCP connection if SSU is available
            
-
            14:31 < jrandom> the two transports 'bid' on each message being sent, and the SSU transport is configured to bid 'lower' than the TCP transport
            
-
            14:31 <+bla> jrandom: That's good, but it means I'll have to update my theland.i2p scripts :(... ;)
            
-
            14:32 < jrandom> heh well, yeah too bad ;)
            
-
            14:32 < jrandom> (the new peers.jsp may be what you're after though)
            
-
            14:33 <+bla> jrandom: I'll have a look. But I don't plan on using SSU until it is ready, though
            
-
            14:33 <+cervantes> perhaps we should all stay on TCP so bla doesn't have to do any coding
            
-
            14:34 < jrandom> heh 
            
-
            14:34 < jrandom> cool bla, yeah, no rush
            
-
            14:34 <+cervantes> ;)
            
-
            14:34 <+bla> cervantes: ;) 
            
-
            14:35 <+cervantes> will there be any situations where an SSU connection is not appropriate and a TCP one would be preferred?
            
-
            14:36  * Masterboy pokes jr
            
-
            14:36 < jrandom> the current default setup prefers an established TCP connection to an unestablished SSU connection
            
-
            14:36 < jrandom> (you can override that with a config flag, i think its documented in the history.txt)
            
-
            14:37 <@smeghead> there are some people who've claimed their ISPs block UDP altogether
            
-
            14:37 < jrandom> but in general, no i can't think of why you'd want to go TCP when SSU is available
            
-
            14:37 <+cervantes> yup I know about the config option...but I mean are there circumstances where it would be better to use TCP instead of UDP packets
            
-
            14:37 < jrandom> smeghead: there are some people who've claimed elvis was a martian
            
-
            14:38 <+cervantes> so it's good just as a fallback
            
-
            14:38 < jrandom> cervantes: none i can think of, as long as ssu is available by both peers
            
-
            14:39 < jrandom> perhaps as a fallback, though it does raise issues of restricted routes, as all peers must be able to contact all peers.
            
-
            14:40 < jrandom> if we allow TCP only nodes, that means everyone must be reachable through TCP and UDP
            
-
            14:41 < Teal`c__> :~(
            
-
            14:41 < jrandom> for this summer, we'll probably support both, but i'm inclined to lean towards udp only
            
-
            14:41 < entroy> Hi, can any one tell me where I can go to ask a q about setting up 12p and Azureus?
            
-
            14:41 < jrandom> (until 2.0)
            
-
            14:42 < jrandom> hi entroy, #i2p-chat may be able to help, or forum.i2p.net.  we're in our weekly dev meeting at the moment, but can help you out afterwards if you're still having trouble
            
-
            14:42 <+cervantes> here they come, repel borders :)
            
-
            14:42 < jrandom> cervantes: anyone who can make it onto irc is one of us :)
            
-
            14:42 <@smeghead> better call the Minutemen
            
-
            14:43 < Teal`c__> liverpool or chelsea ?!
            
-
            14:43 < entroy> ok, thx
            
-
            14:43 < ant> <cat-a-puss> jrandom: WRT bitfields, if we assume most of the packets are going to be successfully received, then the bitfields would be almost all 1's. Wouldn't it be more efficent to list the number of NACKS and then encode them ECC style.
            
-
            14:43 <+cervantes> jrandom: are you sure about that...someone mentioned an mschat client earlier
            
-
            14:43 <+cervantes> ;-)
            
-
            14:45 < jrandom> cat-a-puss: there are a few options, but when you look at the actual message size, its pretty hard to beat- tunnel messages, which are 4x as common as every other message, will require at *most* two fragments - only two bits
            
-
            14:45 < Teal`c__> <steve> # Appears as TIKI
            
-
            14:45 < jrandom> streaming lib messages between the endpoint and gateway is only 4KB - up to 8 bits, or 2 bytes wiwth the bitfields
            
-
            14:45 < jrandom> that is, assuming the absolute smallest MTU
            
-
            14:46 < jrandom> with 1492 (or 1472, depending on who is counting), you can handle most anything in a single bitfield byte
            
-
            14:46 < ant> <cat-a-puss> jrandom: ah, so the bitfields are only for fragments, not for each packet then?
            
-
            14:47 < jrandom> right, if a message is partially received, you send back the bitfield for the received fragments of that message
            
-
            14:47 < ant> <cat-a-puss> ok
            
-
            14:47 < jrandom> message ids are unfortunately completely random and unordered, so we can't use tcp style sequence numbers
            
-
            14:48 < jrandom> (and, well, we dont want that overhead either)
            
-
            14:49 < jrandom> ok, if there's nothing else on 2) SSU, lets move on to 3) i2phex
            
-
            14:49 < jrandom> sirup: you 'round?
            
-
            14:49 < ant> <cat-a-puss> quickly:why random?
            
-
            14:50  * sirup is lurking
            
-
            14:50 < jrandom> cat-a-puss: message ids are exposed to peers - we don't want them to know that one message is related to another message (the one with an earlier sequence #)
            
-
            14:50 < ant> <cat-a-puss> ok
            
-
            14:51 < jrandom> heya sirup, i posted up some general info to the list, but if you could give us an update, that'd be great
            
-
            14:52 < sirup> well. first tests were successfull
            
-
            14:52 < jrandom> [w3wt]
            
-
            14:52 < sirup> but it also seems that we need tweaking with the time out settings. connections between peers don't hold up for some reason
            
-
            14:53 < sirup> so it's not run and gun right now :)
            
-
            14:53 < sirup> but i also expected that, cause i didn't change anything concerning timeouts and such
            
-
            14:54 < sirup> generally, i would be happy if some people would be ready to help me test it until a bearable state is reached
            
-
            14:55 < sirup> several instances on the same machine only get you so far...
            
-
            14:55 < sirup> oh. and any experience/input is welcome. best done wiht mail to sirup@mail.i2p
            
-
            14:56 < sirup> a forum would be great too (i can't have any at my destination, 'cause i'm not 24/7)
            
-
            14:56 < sirup> that's it :)
            
-
            14:56 < jrandom> wikked
            
-
            14:56 < jrandom> cervantes: any way we could get an i2phex section added in there?
            
-
            14:57 <+cervantes> sure could
            
-
            14:57  * sirup wonders who's downloading that crappy commons licensed music from me :)
            
-
            14:58 <@smeghead> hey, you can build more crap on top of that crap at least :)
            
-
            14:58 <+cervantes> sirup: I take it "sirup" is your moniker on the forum
            
-
            14:58 < sirup> that would be neat
            
-
            14:58 < sirup> yes
            
-
            14:59 < ant> <BS314159> status notes?
            
-
            15:00 < jrandom> ok great.  its looking really quite promising, sirup has done some great work, so people should swing over to sirup.i2p and read up on whats goin' on :)
            
-
            15:00 <@smeghead> mailing list?
            
-
            15:00 < RevDuck> or www.i2phex.tk
            
-
            15:01 < sirup> mailing list would also be nice, of course
            
-
            15:01 < sirup> lol. i2phex.tk is fake. get your dialers there :)
            
-
            15:01 <+cervantes> I2Phex forum added
            
-
            15:01 < jrandom> !stab duck
            
-
            15:02 <+cervantes> sirup is moderator
            
-
            15:02 < Masterboy> :D
            
-
            15:02 <+cervantes> sirup: let me know if you want to change the description text
            
-
            15:02 < jrandom> sirup: if you'd like an i2phex and i2phex-cvs list, lemmie know, they're easy enough to add
            
-
            15:02 < jrandom> (though at the moment, it may be simpler to just use the i2p list)
            
-
            15:02 < sirup> cervantes, thanks a bunch 
            
-
            15:03 < sirup> yeah. forum will do atm
            
-
            15:04 < jrandom> ok cool.  anyone have anything else on 3) i2phex?
            
-
            15:05 < jrandom> if not, moving on briefly to 4) awol
            
-
            15:05 < jrandom> i know y'all are chomping at the bit, looking for ways to contribute code to i2p, so the status notes have a few suggestions
            
-
            15:05 <+bla> jrandom: You're finally being canceled by Operations?
            
-
            15:06 < jrandom> nah, the CIA is just reassigning me^Ula la la
            
-
            15:06 <@smeghead> no the black budget was increased this quarter
            
-
            15:07 <+cervantes> *the elephant has flown the nest* repeat *the elephant has flown the nest* over
            
-
            15:07 < jrandom> i dont really have much more to add to 4) than what was in the mail, though i'm sure y'all have plenty of other neat ideas 
            
-
            15:07  * smeghead supresses elephantitis joke
            
-
            15:08 < jrandom> so your homework assignment while i'm gone is to pick something neat that you want to build, and build it ;)
            
-
            15:08  * cervantes staunches smeghead's bleeding temples
            
-
            15:08 < jrandom> (be it a webpage or a flying pony)
            
-
            15:09 < jrandom> ok, moving on to 5) ???
            
-
            15:09 < jrandom> anyone else have anything they want to bring up for the meeting?
            
-
            15:09 < shendaras> We'll miss you...
            
-
            15:09 <@smeghead> yeah who's chairing the meetings while you're gone?
            
-
            15:09 <+mancom> has aum shown up during the last week?
            
-
            15:09 <@smeghead> mancom: negative
            
-
            15:10 < Masterboy> brother duck?:P
            
-
            15:11 < jrandom> our beloved operations manager will hopefully fill in, or y'all can draw straws for who has to write up status notes at the last minute :)
            
-
            15:11 < jrandom> mancom: he was by #i2p-chat the other day briefly
            
-
            15:12 < RevDuck> maybe only hold meetings when there is actually something to report though
            
-
            15:12 <+cervantes> it's ok I'm writing a jrandom simulation script
            
-
            15:12 <+cervantes> * w3wt
            
-
            15:12 < jrandom> nothing wrong with 5 minute meeting ;)
            
-
            15:13 <+cervantes> * jrandom flings a mud at his flying pony
            
-
            15:13  * smeghead writes a cervantes simulation script that writes a jrandom simulation script
            
-
            15:13  * jrandom writes a smeghead simu[CRASH]
            
-
            15:13 <+cervantes> oop gotta work on that grammar
            
-
            15:14 <@smeghead> haha
            
-
            15:14 < jrandom> ok, anyone else have anything to bring up for the meeting?
            
-
            15:14  * cervantes writes an aum simula.........
            
-
            15:14 <@smeghead> java.util.RecursiveIdiocyException
            
-
            15:15 < jrandom> speaking of which.. ;)
            
-
            15:15  * jrandom winds up
            
-
            15:15  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting141.html b/www.i2p2/pages/meeting141.html
deleted file mode 100644
index 92e780de..00000000
--- a/www.i2p2/pages/meeting141.html
+++ /dev/null
@@ -1,135 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 141{% endblock %}
-{% block content %}
            I2P dev meeting, August 2, 2005
            
-
            
-
            13:53 < jrandom2p> ok, as i'm here, is there anyone interested in having a brief meeting wrt the notes (or something else)?
            
-
            13:54 < jrandom2p> anything in the notes people are concerned with, thoughts not related to 'em that people want to bring up, or other issues relevent and timely?
            
-
            13:54 <@smeghead> sure
            
-
            13:54 <+protokol> is icepick here?
            
-
            13:55 <+protokol> i am wondering if i2p-mnet is testable yet and/or an ETA on it
            
-
            13:55 < jrandom2p> idle for 9 hours atm..
            
-
            13:56 < jrandom2p> from the channel logs, it didnt sound workable, but he did get the basic SAM integration going
            
-
            13:56 < jrandom2p> i'm sure we'll hear more when there's more to hear
            
-
            13:56 <+protokol> cooool
            
-
            13:57 < jrandom2p> smeghead: has -1 fixed your port migration issue?
            
-
            13:57 <@smeghead> i haven't noticed any funny business
            
-
            13:58 <@smeghead> in 3 days or so
            
-
            13:58 <@cervantes> glad to say I haven't had a loss of service for a day or two
            
-
            13:58 <@smeghead> i think i can call it fixed
            
-
            13:58 < jrandom2p> wr0d
            
-
            13:58 < jrandom2p> (^2)
            
-
            13:59 <@cervantes> and thetower is only reconnecting every 4 minutes now...so the network health in general must be improving
            
-
            13:59 < jrandom2p> heh
            
-
            13:59 <+thetower> A fresh install seemed to fix the problem, but it was really quite disturbing and I never could find a good reason for it.
            
-
            14:00 < jrandom2p> hmm
            
-
            14:00 < jrandom2p> was it irc only, or were you losing many peers?
            
-
            14:00 <@cervantes> gremlins
            
-
            14:01 <+thetower> Is it possible that changing the router.config file without restarting i2p would have caused the crashes?
            
-
            14:01 < jrandom2p> hmm, no, i change router.config often
            
-
            14:01 < jrandom2p> or, is there a particular change you're concerned with?
            
-
            14:02 <@cervantes> I remember copying over my jbigi lib once while the router was still running.... THAT caused problems ;-)
            
-
            14:02 <+thetower> I set up some script to alter the bandwidth limits based on current network usage and I was wondering if that was causing the problem.
            
-
            14:02 < jrandom2p> heh yeah cervantes, that'll always kill the router
            
-
            14:03 < jrandom2p> ah ok, no, that shouldnt be a problem... though... if it altered the limits to be too small for messages to get through...
            
-
            14:04 <+thetower> Well, it had fairly reasonable lower limits so I guess that wasn't it.
            
-
            14:04 < jrandom2p> ok cool, just checkin~ :)
            
-
            14:05 < jrandom2p> i suppose we'll have 0.6.0.1 tomorrow then, as -1 seems to be a pretty good improvement
            
-
            14:05 < jrandom2p> it'll be backwards compat, etc, yadda yadda.
            
-
            14:06 < jrandom2p> anything else y'all know that needs to get pushed out there?
            
-
            14:06 < jrandom2p> whats the status with i2phex?
            
-
            14:06 <@smeghead> maybe push the cvs hosts.txt to dev.i2p.net... the current one is months old
            
-
            14:06 < jrandom2p> i did the other night iirc
            
-
            14:07 <@smeghead> sirup hasn't been around in a couple of weeks
            
-
            14:07 < jrandom2p> ooh, hmmm..
            
-
            14:07 <@smeghead> it's summer though
            
-
            14:07 <@smeghead> maybe on holiday or something
            
-
            14:08 <@cervantes> or he's been bum-raped by the riaa
            
-
            14:08 < jrandom2p> ah yeah, its up there (it was just cached on squid.i2p)
            
-
            14:08 <@smeghead> riaaped?
            
-
            14:09 < jrandom2p> ($Id: meeting141.html,v 1.2 2005-08-04 16:21:39 duck Exp $)
            
-
            14:09 < jrandom2p> *cough*
            
-
            14:09 <+bar> there are some things that need to be added to bugzilla, like i2p 0.6 and java 1.5
            
-
            14:09 <@smeghead> ok
            
-
            14:09 < jrandom2p> ah right, yeah i still havent gotten my laptop online yet (grr)
            
-
            14:10 < jrandom2p> ((the weekly status notes needed to be burnt to cd... a 1KB cd...))
            
-
            14:10 < jrandom2p> woah heya mihi
            
-
            14:10 <@duck> hi mihi!
            
-
            14:10 < mihi> hi all :)
            
-
            14:10 <@cervantes> could be dm :)
            
-
            14:10 < jrandom2p> heh
            
-
            14:10 <@smeghead> indeed
            
-
            14:10 <@cervantes> 'lo mihi
            
-
            14:10 < mihi> seemed to require a bit of tweaking in the config file till my router believed that *only* 8887/udp is open...
            
-
            14:11  * jrandom2p mentioned i2ptunnel in the status notes and mihi appears ;)
            
-
            14:11 < jrandom2p> ah, hmm, the i2np.udp.fixedPort=true thing?
            
-
            14:11 < mihi> hmm? was it there?
            
-
            14:11  * mihi read status notes only quickly
            
-
            14:11 < mihi> hmm... is that better solution?
            
-
            14:12  * mihi just reset the port to 8887 and restarted hard until it did not change the port...
            
-
            14:12 < jrandom2p> whats the tweak you did to your router.config to make it believe only 8886?
            
-
            14:12 < jrandom2p> er, 8887
            
-
            14:12 < jrandom2p> hah
            
-
            14:12 <@cervantes> can we perhaps rename I2PTunnel as you suggested to something like I2PProxy...?
            
-
            14:12 < jrandom2p> ok, yeah, use i2np.udp.fixedPort=true
            
-
            14:12 < jrandom2p> (deployed in 0.6-1 and to be released asap as 0.6.0.1)
            
-
            14:12 <@cervantes> it can get very confusing talking about "the tunnel config page"
            
-
            14:13 <+thetower> Oh I have a question, isn't i2p supposed to automatically detect which udp port to use? And if so, is it supposed to be hard coded in the default router.config?
            
-
            14:13 < mihi> hmmkay...
            
-
            14:14 < mihi> seems that i2p changed the port once again
            
-
            14:14 < mihi> expect me to be away soon :)
            
-
            14:14 < jrandom2p> thetower: yes, it should automatically detect, but there are some funky tap dances that we~re going through at the moment 
            
-
            14:14 <@cervantes> mihi: d'you have the latest cvs?
            
-
            14:14 < jrandom2p> thats what the whole PeerTest thing is about (making it so that we always automatically configure it properly)
            
-
            14:14 < mihi> nope.
            
-
            14:14 <@cervantes> mihi: that would be why then :)
            
-
            14:15 < mihi> only the version from i2pupdate.zip
            
-
            14:15 <@cervantes> mihi: 0.6 has RandomPort (tm) functionality
            
-
            14:15 < jrandom2p> heh
            
-
            14:16 <@cervantes> :)
            
-
            14:16 <+ant> * mihi 'd like FixedPorto functionality :)
            
-
            14:16 <+ant>  and disconnected...
            
-
            14:16 <@cervantes> then you'd need  0.6-1 FixedPort Pro
            
-
            14:16 < jrandom2p> heh
            
-
            14:16 < jrandom2p> ok, anyone else have something to bring up for the meeting?
            
-
            14:16 <@cervantes> or wait for 0.6.0.1
            
-
            14:17 < jrandom2p> how has the latency/throughput been, barring the intermittent reachability?
            
-
            14:17 <+ant>  hmm. here is a cvs checkout from 2004-10-06. should try to update it :)
            
-
            14:17 < jrandom2p> !thwap mihi
            
-
            14:18 <@cervantes> I got i2pinstall.jar at 110k/sec from dev.i2p yesterday on a single stream
            
-
            14:18 < jrandom2p> nice
            
-
            14:19 <@cervantes> and 320k/sec using multiple
            
-
            14:19 < jrandom2p> w0ah
            
-
            14:19 < jrandom2p> 0hop, i assume
            
-
            14:19 < jrandom2p> (dev.i2p is 0hop)
            
-
            14:19 <@cervantes> yup
            
-
            14:19 < jrandom2p> ((in case you couldn't tell ;)
            
-
            14:19 <@cervantes> ;-)
            
-
            14:19 <+thetower> download to:    GTA San Andreas
            
-
            14:19 <+thetower> download rate:  28.51 kB/s
            
-
            14:20 <@cervantes> that was from multiple sources though...
            
-
            14:20 < jrandom2p> ah cool thetower 
            
-
            14:20 <@cervantes> managed to push squid.i2p up to about 280
            
-
            14:21 < lucky> jrandom2p :)
            
-
            14:21 < lucky> would you push the new hosts.txt to the site
            
-
            14:21 <@cervantes> lucky: tis done
            
-
            14:21 < jrandom2p> yeah, once we can consistently pull that sort of rate cervantes, we'll need to add on some configurable delays to let people do 0hops safely
            
-
            14:22 < jrandom2p> (so it delays AVG(tunnelTestTime/2) but doesnt waste bw or lose messages)
            
-
            14:22 <@cervantes> to hide the fact that it's a 0 hop tunnel?
            
-
            14:22 < lucky> i wonder if I2P will ever have speeds decent enough tha ti could let people log into my virtu-vax
            
-
            14:23 < jrandom2p> yeah.  otherwise, if you say "hey i~m getting 300KBps from your site", you can pretty safely guess that its 2 0hop tunnels
            
-
            14:23 < jrandom2p> (otoh, 1 to 2 to 3 to 4hops don't have such a dramatic cut)
            
-
            14:23 <@cervantes> so will i2p effectively have a bandwidth cap
            
-
            14:23 < jrandom2p> ((as once you force true tunnel operation, each intermediate hop isn't much))
            
-
            14:24 < jrandom2p> nah cervantes, large windows + delays 
            
-
            14:24  * cervantes cancels his plans for HDTV streaming anonymous pr0n
            
-
            14:24 < jrandom2p> you can just have more messages in the air to get the same rate
            
-
            14:25 <@cervantes> ah right
            
-
            14:25 < jrandom2p> (but it'll take a few more rtts to get to the larger window, of course)
            
-
            14:25 < jrandom2p> ok, anyone have anything else to bring up?
            
-
            14:26 < mihi> bring up a *baf*er :)
            
-
            14:26 <@cervantes> it's gone rusty with missuse
            
-
            14:27 < jrandom2p> heh i suppose its time ;)
            
-
            14:27  * jrandom2p winds up
            
-
            14:27  * jrandom2p *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting142.html b/www.i2p2/pages/meeting142.html
deleted file mode 100644
index fa4196dc..00000000
--- a/www.i2p2/pages/meeting142.html
+++ /dev/null
@@ -1,94 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 142{% endblock %}
-{% block content %}
            I2P dev meeting, August 9, 2005
            
-
            
-
            13:11 < jrandom2p> 0) hi
            
-
            13:11 < jrandom2p> 1) 0.6.0.2
            
-
            13:11 < jrandom2p> 2) roadmap update
            
-
            13:11 < jrandom2p> 3) ???
            
-
            13:11 < jrandom2p> 0) hi
            
-
            13:11  * jrandom2p waves
            
-
            13:11 <+detonate> hi
            
-
            13:11 < jrandom2p> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000839.html
            
-
            13:12 < jrandom2p> ok, jumping in briefly to [1-2] before the freeforall..
            
-
            13:12 < jrandom2p> 1) 0.6.0.2
            
-
            13:12 < jrandom2p> its out.  and stuff
            
-
            13:12 < jrandom2p> anyone have any questions/comments/concerns w/ 0.6.0.2?
            
-
            13:13 < jrandom2p> if not, moving on to 2) roadmap update
            
-
            13:13 < jrandom2p> the, er, roadmap has been updated.  and stuff ;)
            
-
            13:14 < duck> you aussie
            
-
            13:14 <+bla> jrandom: There still are intermittent problems contacting a destination, even when it's normally up
            
-
            13:14  * postman can second this
            
-
            13:14  * detonate can third that
            
-
            13:14 <+bla> jrandom: E.g., forum.i2p works fine, then after a few minutes it doesn't, and requires a few reloads
            
-
            13:15  * bla firsted it ;)
            
-
            13:15 < jrandom2p> hmm, aye, i've heard reports of that.  with 0.6.0.2 as well, right?
            
-
            13:16 <+postman> indeed sir
            
-
            13:16 <+bla> Yes, 0.6.0.2
            
-
            13:16 <+bla> Could be netDb trouble, or poor selection of peers to put in tunnels (or something else)
            
-
            13:16 < jrandom2p> 'k
            
-
            13:17 < jrandom2p> the tunnel peer selection has been pretty bad lately, as has netDb store flooding
            
-
            13:17 < jrandom2p> (see your /oldstats.jsp for tunnel request failure counts)
            
-
            13:18 <+bla> Now that we use UDP/SSU, peer classification seems to be better than before: a number of peers I _know_ to be fast, usually show up under the "fast" section on the profile pafe
            
-
            13:19 < jrandom2p> nice
            
-
            13:19 < jrandom2p> 0.6.0.2 added some tunnel rejection code based on the netDb that it should have been doing before (refusing to join if we can't find the next hop), so the increase in rejections is expected
            
-
            13:19 <+bla> Though I really should get going at the classification algorithms again... ;)
            
-
            13:20 < jrandom2p> i've been doing profile/stat analysis, but no solid results yet
            
-
            13:21 < jrandom> that would be cool bla :)
            
-
            13:25 < jrandom2p> ok, anything else on 2) roadmpa update?  :)
            
-
            13:26 < jrandom2p> if not, moving on to 3) ???
            
-
            13:26 <+detonate> do you think it would be useful to shitlist peers with high failure/duprecv rates compared to the mode?
            
-
            13:27 < jrandom> hmm, i'm not sure about that - if the failure/dup rates are too high to be useful, we should just transfer slowly and carefully
            
-
            13:27 < jrandom> as long as messages are getting through, messages are getting through
            
-
            13:28 < jrandom> there's a reason why we haven't used stats on direct peer communication as part of our profiling - depending upon them would make us vulnerable to some easy and powerful attacks (acting differently to different peers and see who uses you, etc)
            
-
            13:29 <+detonate> hmm
            
-
            13:29 <+detonate> ok
            
-
            13:29 < jrandom> but perhaps we need to drop sessions for peers who are in such congested cons
            
-
            13:29 <+detonate> good point
            
-
            13:34 < jrandom> ok, anyone else have something to bring up for 3) ???
            
-
            13:34 < luckypunk> o,oh, maybe you should wait ti leveryone is back
            
-
            13:34 < luckypunk> before asking critical questions :P
            
-
            13:35 < jrandom2p> bah, they've got the mailing list ;)
            
-
            13:35 < luckypunk> well
            
-
            13:35 < luckypunk> i guess this is the right place to whine
            
-
            13:36 < luckypunk> I2P still uses a bit of CPU
            
-
            13:36 < luckypunk> but not as much as before
            
-
            13:36 < luckypunk> true, i haven't run it since the 5.0 days
            
-
            13:36 < luckypunk> but yeah
            
-
            13:36 < luckypunk> er
            
-
            13:36 < luckypunk> 0.5.0
            
-
            13:36 < jrandom2p> cool, which of your boxes works with it?
            
-
            13:36 < luckypunk> er
            
-
            13:36 < luckypunk> ffs
            
-
            13:36 < luckypunk> i haven't used it since 0.6.0.0
            
-
            13:36 < luckypunk> it works fine with the pentium 2
            
-
            13:37 < luckypunk> the default nice value mens it tends to crashif i do anything too CPU intensive for too long as I2P gets CPU starved
            
-
            13:38 <+detonate> hmm, i guess there could be a space in the router console network config to hardwire the introducers, once there are introducers, if the user prefers
            
-
            13:39 < jrandom2p> are you on 0.6.0.2 now luckypunk?
            
-
            13:39 <@smeghead> detonate: that's trusted route stuff... later on in the roadmap :)
            
-
            13:39 < luckypunk> no
            
-
            13:39 < luckypunk> i haven't run it since 0.6.0.0
            
-
            13:39 <@smeghead> *restricted route
            
-
            13:40 < luckypunk> but it's CPU use seemed much less.
            
-
            13:40 <+detonate> heh, it should be there as soon as there's introducers :)
            
-
            13:40 < jrandom2p> ah yeah detonate, the introducer selection could certainly be configurable, but it'll probably be a hidden advanced config option ;)
            
-
            13:41 < jrandom2p> luckypunk: 0.6.0.1 cut out a lot of crypto, and 0.6.0.2 should help further.  give it a try sometime, it may handle it better
            
-
            13:41 < luckypunk> ok
            
-
            13:41 <@smeghead> what if an introducer doesn't want you selecting them all the time?
            
-
            13:41 < luckypunk> i have the feeling I2P would on a dedicated mid range pentium now.
            
-
            13:41 < jrandom> smeghead: then they say "fuck off, i'm not going to serve as an introducer for you"
            
-
            13:42 < jrandom> and peers will have multiple introducers, so it'll be balanced
            
-
            13:42 < jrandom> (and its only 2 packets to wire up a new peer, not all packets communicated)
            
-
            13:44 <+detonate> if introducers worked differently you could do a majority vote between them to decide which ones are working, but as it stands that doesn't make sense
            
-
            13:45 < ant> <jme___> q. where can i find a description of this voting system ?
            
-
            13:45 < jrandom> majority doesnt make any sense
            
-
            13:45  * jrandom doesnt trust voting any further than i can throw it
            
-
            13:45 < jrandom> (especially in light of sybil)
            
-
            13:45 < jrandom> an introducer is working if a new peer can contact you through it
            
-
            13:47 <+detonate> what's the status of vanguard, that's sort of related
            
-
            13:47 <+detonate> while smeghead is around
            
-
            13:51 < jrandom> ok, if there isn't anything else...
            
-
            13:51  * jrandom winds up 
            
-
            13:51  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting143.html b/www.i2p2/pages/meeting143.html
deleted file mode 100644
index 1bafa6a4..00000000
--- a/www.i2p2/pages/meeting143.html
+++ /dev/null
@@ -1,56 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 143{% endblock %}
-{% block content %}
            I2P dev meeting, August 16, 2005
            
-
            
-
            13:09 <@jrandom> 0) hi
            
-
            13:09 <@jrandom> 1) PeerTest status
            
-
            13:09 <@jrandom> 2) Irc2P
            
-
            13:09 <@jrandom> 3) Feedspace
            
-
            13:09 <@jrandom> 4) meta
            
-
            13:09 <@jrandom> 5) ???
            
-
            13:09 <@jrandom> 0) hi
            
-
            13:09  * jrandom waves
            
-
            13:09 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000842.html
            
-
            13:10 <@jrandom> (which i'm sure you've all read studiously)
            
-
            13:10 <@postman> hi
            
-
            13:10 <+cervantes> hmm changate perl scripts...will give them a go...
            
-
            13:10 <+cervantes> hi
            
-
            13:10 <@jrandom> 1) peer test status
            
-
            13:11 <@jrandom> not too much to add on this beyond what i posted in the notes - anyone have any questions/comments/concerns with it?
            
-
            13:11 <@jrandom> i'm not sure whether to verify the remote reachability of everyone who connects to us, but i'm toying with that idea
            
-
            13:11 <@jrandom> (we do that now with tcp)
            
-
            13:13 <@jrandom> well, perhaps we can try it without that on a 0.6.0.3 before moving to 0.6.1.  ve zhall zee
            
-
            13:13 <@jrandom> ok, moving on to 2) irc2p
            
-
            13:13 <@jrandom> y'all are here, so you know whats up :)
            
-
            13:13 <@jrandom> nice work postman & smeghead
            
-
            13:16 <@jrandom> ok, smeghead & postman have been putting out plenty of info on that thaang, so if there's nothing else y'all want to bring up on that, we can swing over to 3) feedspace
            
-
            13:16 <@jrandom> frosk seems to have stepped out, and i don't really have anything to add beyond whats in the notes (and on his blog)
            
-
            13:17 <@postman> :)
            
-
            13:17  * Complication is reading frosk's blog
            
-
            13:18 <@jrandom> ok, perhaps frosk'll fill us in with a post there when there's more info to share
            
-
            13:19 <@jrandom> movin' on briefly to 4) meta
            
-
            13:19 <@jrandom> what are y'all's thoughts on 8p GMT meetings?  too early, too late, just right?
            
-
            13:21  * jrandom holds back the crowds
            
-
            13:21 <+Complication> I'd like to say something useful, but cannot seem to find my world clock...
            
-
            13:21 <@jrandom> google://what+time+is+it
            
-
            13:22 <+Complication> :)
            
-
            13:22 <@jrandom> ok, movin' on to 5) ???
            
-
            13:22 <@jrandom> anyone have anything else they want to bring up?
            
-
            13:23 <+susi23> well
            
-
            13:23 <+susi23> not officially ;)
            
-
            13:24 <+Complication> It's been an unusually stable time.
            
-
            13:24 <+Complication> Aside from occasional "message invalid" (or was it "packet invalid"), I can't find errors to report. :o
            
-
            13:24 <@postman> my errors are already reported :)
            
-
            13:24 <@jrandom> coo', though thats unfortunately a symptom of undetected errors Complication, since there's still some stuff not going as it Should
            
-
            13:25 <@jrandom> but, progress, ever onwards
            
-
            13:25 <@jrandom> perhaps we're seeing a lot of restricted routes out there due to the udp situation
            
-
            13:25 <+susi23> we started a new idlerpg on #idle and you are all invited to join :)
            
-
            13:25 <@jrandom> (and perhaps there's a bunch of other things...)
            
-
            13:25 <@jrandom> w00t susi23 
            
-
            13:26 <+susi23> :P
            
-
            13:30 <@jrandom> ok, anyone else have something to bring up for the meeting?
            
-
            13:32 <@jrandom> ok, if there's nothin' else
            
-
            13:32  * jrandom winds up
            
-
            13:32  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting144.html b/www.i2p2/pages/meeting144.html
deleted file mode 100644
index 0929a2f6..00000000
--- a/www.i2p2/pages/meeting144.html
+++ /dev/null
@@ -1,149 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 144{% endblock %}
-{% block content %}
            I2P dev meeting, August 23, 2005
            
-
            
-
            12:01 < jrandom> 0) hi
            
-
            12:01 < jrandom> 1) 0.6.0.3 status
            
-
            12:01 < jrandom> 2) IRC status
            
-
            12:01 < jrandom> 3) susibt
            
-
            12:01 < jrandom> 4) Syndie
            
-
            12:01 < jrandom> 5) ???
            
-
            12:01 < jrandom> 0) hi
            
-
            12:01  * jrandom waves
            
-
            12:01 < lucky> hi
            
-
            12:02 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000857.html
            
-
            12:02 < lucky> hihihihi
            
-
            12:02 < jrandom> hi lucky 
            
-
            12:02 < jrandom> ok, jumping into 1) 0.6.0.3 status
            
-
            12:02 < jrandom> i think the biggest things worth mentioning wrt 0.6.0.3 are in the status notes, but beyond that, anyone have anything to bring up?
            
-
            12:04 < gott> What's the deal with 'Unknown' ?
            
-
            12:04 < jrandom> i'm not sure whether the ssu cwin improvements will come in 0.6.0.4 or will wait until 0.6.1 when we have better peer / configuration
            
-
            12:04 < jrandom> gott: there are two paragraphs in the email related to that - do you have any specific questions beyond those?
            
-
            12:05 < jrandom> or is there some point i could clarify?
            
-
            12:05 < gott> No, I just haven't read the bloody email.
            
-
            12:05 < jrandom> heh
            
-
            12:05 < jrandom> well, scroll up five lines and read the bloody email ;)
            
-
            12:06 < jrandom> ok, anyone else have any questions on 0.6.0.3?
            
-
            12:07 < jrandom> if not, moving on to 2) IRC status
            
-
            12:07 < modulus> sorry guys, but need to leave. later all.
            
-
            12:08 < jrandom> beyond whats in the mail, postman/cervantes/arcturus: y'all have anything you want to bring up?
            
-
            12:08 < jrandom> l8r modulus
            
-
            12:08 <+arcturus> on 1)?
            
-
            12:08 <+arcturus> oh sorry
            
-
            12:08 < gott> Hmm.
            
-
            12:08 <+arcturus> 2) it is now
            
-
            12:09 < gott> How much upstream bandwidth does IRC over i2p usually take at the moment ?
            
-
            12:09 <+arcturus> netsplits are history
            
-
            12:09 <+arcturus> gott: i coudln't say that without compromising my router's anonymity
            
-
            12:09 < gott> No, no, no.
            
-
            12:10 < jrandom> not sure, my router with squid.i2p/dev.i2p/cvs.i2p/www.cvs/syndiemedia.i2p plus my irc and eepproxy uses on average 10-20KBps
            
-
            12:10 < gott> Does it require a commercial line ?
            
-
            12:10 < jrandom> nice1 arcturus
            
-
            12:10 < gott> jrandom: I mean to say, to host.
            
-
            12:10 < jrandom> gott: to operate a server or a client?
            
-
            12:10 < jrandom> ah
            
-
            12:10 <+arcturus> gott: i couldn't say that without compromising my router's anonymity
            
-
            12:10 < gott> server.
            
-
            12:10  * jrandom knows not.  probably less when you have just one ircd
            
-
            12:10 < gott> So are you running a modified unrealircd ?
            
-
            12:11 < jrandom> say, add a factor of 1.3 to the client usage for a single server
            
-
            12:11 <+arcturus> i'd like to also add that inter-server lag is steady and very very low
            
-
            12:11 < gott> I assume you are, since there doesn't seem to be a VERSION command
            
-
            12:11 <+arcturus> i disabled version
            
-
            12:12 < gott> Are your modifications open-source ?
            
-
            12:12 <+arcturus> maybe we're running unreal, maybe we aren't :)
            
-
            12:12 < gott> You should put them up so others can start their own private networks.
            
-
            12:12 <+arcturus> i can't tell you without compromising security
            
-
            12:12 < gott> security through obscurity, sweet.
            
-
            12:12 < jrandom> word arcturus.  i'm seeing something like 0-2s lag on average (at the moment, less than irssi's lag detector)
            
-
            12:12 <+arcturus> no, it's only one layer of security
            
-
            12:13 <+arcturus> and it only serves as a deterrent, no substitute for technical security measures
            
-
            12:15 < jrandom> arcturus: how goes with vanguard?
            
-
            12:15 <+arcturus> i haven't coded on it lately, other projects have been occupying me, but there's a constant, steady pressure i feel to get around to finishing it :)
            
-
            12:16 < jrandom> heh coo'
            
-
            12:16 <+arcturus> vanguard will be most effective against bots, the hashcash measure is a separate deal
            
-
            12:16 <+arcturus> i'm concerned about hashcash now though
            
-
            12:17 <+arcturus> with the latest attacks against sha-1
            
-
            12:17 <+arcturus> it won't be long before there are tools available to the masses
            
-
            12:17 <+arcturus> unfortunately the standard hashcash implementation is based entirely on sha-1
            
-
            12:17 < susi23_> Unable to find a javac compiler; // com.sun.tools.javac.Main is not on the classpath. // Perhaps JAVA_HOME does not point to the JDK
            
-
            12:18 <@cervantes> ah made it
            
-
            12:18 < susi23_> any ideas about this? JAVA_HOME points definitely to the right dir, javac is in PATH and callable
            
-
            12:18 <+arcturus> susi23_: we're in a meeting atm :)
            
-
            12:18 < jrandom> susi23_: OOM?
            
-
            12:18 < susi23_> meeting? though its 8pm?
            
-
            12:18 < jrandom> (precompile your jsps rather than letting jetty/tomcat do it, its faster ;)
            
-
            12:19 < jrandom> yeah we moved it susi23_ :)
            
-
            12:19 < susi23_> didn't know, sorry
            
-
            12:19 < jrandom> hehe np, glad you made it for the meeting, your agenda item is up next ;)
            
-
            12:20  * susi23_ sits down and listens
            
-
            12:20 <+arcturus> so while i don't expect immediate problems with hashcash, i think it's feasible sha-1 could be seriously compromised soon
            
-
            12:21 < jrandom> arcturus: hashcash with md5 would probably be fine
            
-
            12:21 < jrandom> its just a PoW
            
-
            12:21 <+arcturus> if anyone knows of any hashcash implementations based on sha256 or higher please met me know
            
-
            12:21 <+arcturus> well PoW is pointless if there's little P in it :)
            
-
            12:21 < jrandom> the size of the hash only matters when your hashcash reaches the size of the hash
            
-
            12:23 < jrandom> (but, yeah, running against a truncated sha256 or 512 or whirlpool or whatever would be neat)
            
-
            12:23 <+arcturus> i guess we could go ahead with the current implementation, perhaps we can design it so that we can swap it out easily later when we need to
            
-
            12:24 < jrandom> (DTSTTCPW)
            
-
            12:25 <+arcturus> because we will eventually need to drop sha-1, i'm sure of it :) and if we can't be reasonably certain a token was generated properly there's no reason to even be using hashcash
            
-
            12:25 < jrandom> (its only for a PoW to get a nym on irc, not to get access to fort knox ;)
            
-
            12:26 <@cervantes> there's some talk on the hashcash mailing list about implementing sha256
            
-
            12:26 <+arcturus> it's not for a nym, it's for entry to the server
            
-
            12:26 <+arcturus> cervantes: cool i'll check that
            
-
            12:27 <+arcturus> jrandom: and it's not just PoW, the hashcash is what gives us a method to uniquely identify clients on the network, akin to being able to identify by IP, so that we can ban with precision
            
-
            12:28 < jrandom> certainly those are renewed over time though, right?
            
-
            12:28 < jrandom> e.g. a new PoW cert every 6 months (or 6h, or whatever)
            
-
            12:28 <+arcturus> if a user doen't have to do any work to get their ID, that nullifies our ability to ban them
            
-
            12:29 <+arcturus> i don't know of any reason to expire them automatically, only expire them manually if they violate terms of service
            
-
            12:29 <+arcturus> no need to make people do unnecessary work for new IDs
            
-
            12:29 < jrandom> eh, its just a passive PoW, they can run one cycle every 6 hours to regenerate a new one
            
-
            12:29 < jrandom> but perhaps DTSTTCPW
            
-
            12:30 <+arcturus> any hashcash genereated must be used within 24 hours or it is invalid
            
-
            12:32 <@cervantes> just to reiterate the new server irc.freshcoffee.i2p needs to be added into your i2ptunnel console
            
-
            12:32 < jrandom> coo'.  ok, anything else for 2) irc2p?
            
-
            12:33 <@cervantes> (http://forum.i2p/viewtopic.php?t=911
            
-
            12:33 <@cervantes> )
            
-
            12:33 <@cervantes> <-- done
            
-
            12:34 <+arcturus> i don't have anything else to bore you all with :)
            
-
            12:34 < jrandom> hehe
            
-
            12:34 < jrandom> ok, 3) susibt
            
-
            12:34 < ardvark> um, when I add the new server to my tunnel, do I have to restart i2p?
            
-
            12:34 < jrandom> susi23_: p1ng
            
-
            12:35 <@cervantes> ardvark: just the tunnel
            
-
            12:35 <@cervantes> (ircproxy tunnel)
            
-
            12:35 < ardvark> oh ok, I just added and saved, so that is not enuff then
            
-
            12:36 < jrandom> right, unfortunately you need to stop and start that proxy
            
-
            12:36 < susi23_> well
            
-
            12:36 < ardvark> but i'll miss the meeting then ;)
            
-
            12:37 < susi23_> susibt is a webapp (like susimail) to drop into your routers VM
            
-
            12:37 < susi23_> it acts as a web frontend for i2p-bt
            
-
            12:38 < susi23_> so you can manage your seeds, up- and download files etc.
            
-
            12:38 < jrandom> w00t
            
-
            12:39 < susi23_> the prob is, you need to start a btdownloadheadless.py for each seed... so you get lot of python processes to your many java threads :)
            
-
            12:39 <+arcturus> that will be addressed in ducktorrent *cough*
            
-
            12:39 < jrandom> heh
            
-
            12:39  * jrandom holds breath
            
-
            12:40 < susi23_> it even supports restart of seeds after router restart
            
-
            12:40 <@cervantes> nice
            
-
            12:40 < jrandom> wikked
            
-
            12:40 < susi23_> future plans are automatic build of torrents and ui improvement
            
-
            12:41 < susi23_> if you want to try it out, I recommend a separate jetty instance
            
-
            12:41 < susi23_> so you don't have to fiddle with your router :)
            
-
            12:41 < susi23_> download and installation instructions on http://susi.i2p
            
-
            12:42 < susi23_> thats all *ping back to jr*
            
-
            12:42 < jrandom> w3wt, gracias susi
            
-
            12:42 < jrandom> ok, anyone have any questions & comments on that, or shall we jump on over to 4) syndie?
            
-
            12:44 < jrandom> ok regarding syndi, i've posted a bunch to the list about it over the last day or two, and there'll be lots more activity
            
-
            12:45 < jrandom> the main demo site for syndie is http://syndiemedia.i2p / http://66.111.51.110:8000/, but of course people are encouraged to download it and install it locally
            
-
            12:45 < jrandom> i dont have too much to add at the moment on that frnt. unless anyone has any questions?
            
-
            12:46 < gott> Why is it called syndie ?
            
-
            12:46 < gott> is it a reference to 'syndicate' ?
            
-
            12:47 < jrandom> yeah, its a generic syndication frontend (+ security, authentication, and anonymity awareness)
            
-
            12:48 < jrandom> ok, if there's nothing else on 4), lets jump on over to 5) ???
            
-
            12:48 < jrandom> anyone have anythin i2p related to bring up for the meeting?
            
-
            12:51 < jrandom> ok, if there's nothing else
            
-
            12:51  * jrandom winds up
            
-
            12:52  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting145.html b/www.i2p2/pages/meeting145.html
deleted file mode 100644
index dbd0fec6..00000000
--- a/www.i2p2/pages/meeting145.html
+++ /dev/null
@@ -1,134 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 145{% endblock %}
-{% block content %}
            I2P dev meeting, August 30, 2005
            
-
            
-
            13:03 <+bla> Is there a meeting today?
            
-
            13:04 < jrandom> 0) hi
            
-
            13:04 < jrandom> 1) Net status
            
-
            13:04 < jrandom> 2) floodfill netDb
            
-
            13:04 < jrandom> 3) Syndie
            
-
            13:04 < jrandom> 4) ???
            
-
            13:04 < jrandom> 0) hi
            
-
            13:04 <+bla> ;)
            
-
            13:04  * jrandom waves
            
-
            13:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-August/000871.html
            
-
            13:04 < jrandom> (yeah, i'm a few minutes late ;)
            
-
            13:05 < jrandom> anyway, jumping into 1) net status
            
-
            13:06 < jrandom> restricted routes suck, and we finally have some data as to how common they are (boo hiss)
            
-
            13:06 < jrandom> but stil, the net seems fairly healthy, if you ignore all the worried reports of "omg it says status: Unknown!" ;)
            
-
            13:07 < gloin> hmm.. where should be the document root for the i2p  included webserver?
            
-
            13:07 < jrandom> $i2pInstallDir/eepsite/docroot/
            
-
            13:07 < gloin> i2p/eepsite/docroot ?
            
-
            13:07 < jrandom> anyone have any questions/comments/concerns regarding the net status outside of whats posted in the status notes?
            
-
            13:08 < gloin> found it. it seems that the webserver won't deliver index.html automatically.
            
-
            13:08 <+bla> jrandom: I have been doing some tests to check which nodes are selected in tunnels.
            
-
            13:09 <+bla> jrandom: Mainly, as I've now implemented node-localization in the RouterInfo struct, I can see graphically (country flags) were tunnel participants are located.
            
-
            13:09 <+bla> I am in Europe (no secret), and most of my tunnel participants are in Europe
            
-
            13:09 < jrandom> gloin: it should serve up the index.html (thats what renders "Welcome to your Eepsite")
            
-
            13:10 < jrandom> ooh nice1 bla!
            
-
            13:10 < redzara> as some people have reported some low perf with UDP, maybe we could had a little perfmeter like iperf in I2P ?
            
-
            13:11 < redzara> s/had/add
            
-
            13:11 < jrandom> bla: so thats not just on the profiles.jsp page, but also on tunnels.jsp?  v.cool... screenshots, screenshots!  :)
            
-
            13:11 < gloin> jrandom: now it works. strange.
            
-
            13:11 <+bla> jrandom: I'll post some screenshots, but I first have to black out my own router-ID in the screenshots ;)
            
-
            13:11 < jrandom> redzara: hmm, a command line utility to let people check their link quality, or a monitor for SSU performance?
            
-
            13:11 < jrandom> heh bla
            
-
            13:12 < jrandom> odd gloin 
            
-
            13:13 < gloin> jrandom: btw, since I updated my pppoe i2p seems to be more stable.
            
-
            13:13 < jrandom> nice, what was the problem with your net connection?  firmware update?
            
-
            13:14 < gloin> jrandom: I lost all peers. But the internet connection was ok, but every peer failed. 
            
-
            13:16 < jrandom> right, but what did you update about your pppoe settings?
            
-
            13:17 < gloin> jrandom: I mean the linux ppppoe deamon.
            
-
            13:18 < jrandom> ah ok
            
-
            13:18 < jrandom> ok, anyone else have anything for 1) net status, or shall we move on to 2) floodfill netdb?
            
-
            13:18 <+bla> http://theland.i2p/parttunnels.jpg
            
-
            13:19 <+bla> http://theland.i2p/servertunnels.jpg
            
-
            13:21 <+bar> (umm.. inaccessible?)
            
-
            13:21 < jrandom> yeah, i'm having trouble reaching it too
            
-
            13:21 < fox> <godmode0> i use pppoe never be at problem i2p
            
-
            13:22  * jrandom will try later though
            
-
            13:22 <+bla> jrandom: Well.. There's new network problem just there ;)
            
-
            13:22 < jrandom> hehe
            
-
            13:22 < jrandom> bla: are you on -4 or an earlier build?
            
-
            13:23 <+bla> jrandom: I'm on -4
            
-
            13:23 < jrandom> hmm, ok cool
            
-
            13:23 < jrandom> ok, anyway, we can dig through that later
            
-
            13:24 < jrandom> (if you could send me the netDb stats from /oldstats.jsp, that'd be great :)
            
-
            13:25 < jrandom> ok, moving on to 2) floodfill netdb
            
-
            13:26 < jrandom> there's lots of info posted to my blog on this topic
            
-
            13:26 < jrandom> we've begun deploying a first pass, though there's still some work to be done
            
-
            13:26 < jrandom> does anyone have any questions/comments/concerns on the plan?
            
-
            13:27 <+bla> jrandom: Will the floodfill scale as log(N) (N=number of peers in the net), or linearly?
            
-
            13:27 < jrandom> linearly with M (M= number of peers participating in the floodfill netdb)
            
-
            13:28 < jrandom> well, M may be small enough that N is the dominant term
            
-
            13:29 < jrandom> (in which case it'll be linearly with N)
            
-
            13:29 < jrandom> which is not great, but until we have > 10K eepsites, it doesnt matter
            
-
            13:30 < jrandom> once we do, then we can go into more advanced algorithms for sharing the load between the floodfill participants
            
-
            13:31 < jrandom> (note thats 10k eepsites, not users, since we don't really need to publish client leaseSets in the netdb)
            
-
            13:32 <+bla> jrandom: Is there a reason why we still do publish the client destinations in the netDb?
            
-
            13:32 <+bla> jrandom: Or, for that matter, why we still show off who our fast peers are in the netDb?
            
-
            13:33 <+bla> jrandom: Removing both would slash the netDb data by a big factor
            
-
            13:33 < jrandom> bla: to the former, no.  to the later, for me to debug (though i havent looked at that particular field recently)
            
-
            13:33 < jrandom> aye, worth trying, perhaps in -5
            
-
            13:36 < jrandom> ok coo', well, we'll see and hopefully get -5 out in the next few days
            
-
            13:37 < jrandom> (maybe tomorrow)
            
-
            13:37 < jrandom> ok, if there's nothing else on 2) floodfill netdb, lets move on to 3) syndie
            
-
            13:38 < jrandom> i posted a bunch of info in the mail and on my blog, so rather than rehash them, does anyone have any questions / comments / concerns?
            
-
            13:40  * jrandom really digs the remote syndication functionality, though its far from what we're hoping for with feedspace integration
            
-
            13:41 < jrandom> (i havent been bothered to do freenet posting integration, though it would be quite easy to fire up a CLI and post all the entries in)
            
-
            13:42 < jrandom> ok, if there's nothing else on 3) syndie, lets open 'er up to 4) ???
            
-
            13:42 < jrandom> anyone have anything else i2p related to bring up?
            
-
            13:42 < redzara> sure, where is the doc ;)
            
-
            13:43 < laberhorst> just that my node under 0.6.x sonsumes up to 100% cpu load, but have to crosscheck it with linux on that line here
            
-
            13:43 <+nickless_head> I think the i2pProxy.pac script should be in the jetty web folder by default.
            
-
            13:43 < jrandom> nickless_head: i dont recommend i2pproxy.pac, as its a huge security risk
            
-
            13:44 < redzara> 2 - could be have the latest build of jetty included in I2P ?
            
-
            13:44 < jrandom> we've got 5.2.1 in i2p right now
            
-
            13:44 < jrandom> er, 5.1.2
            
-
            13:44 <+nickless_head> jrandom: it's the only thing available for separating between eepsites and websites in one browser without having to switch by hand afaik
            
-
            13:45 < jrandom> i use switchproxy
            
-
            13:45 < jrandom> (and i dont switch to non-anonymous browsing)
            
-
            13:45 < jrandom> ((squid.i2p is fast enough for me))
            
-
            13:45 <+nickless_head> Think of the slashdotters! :p
            
-
            13:46 < jrandom> as i've said before, i have reservations about the viability of eepsites.  the security risks are tremendous
            
-
            13:46 < jrandom> but, for those who don't care about those risks, perhaps an i2pproxy.pac makes sense.
            
-
            13:47 <+bla> I strongly think that something that isn't secure by _default_, shouldn't be in I2P, as to not give new users a false sense of secutiry
            
-
            13:48 < jrandom> agreed (though we do push i2pproxy.pac, we just dont tell people about it until we scare 'em enough ;)
            
-
            13:49 <+nickless_head> I somehow can't believe that within the configuration of Mozilla there isn't a way to make sites only access resources from the same domain .. 
            
-
            13:50 < redzara> sorry but IRC connection lost :( about jetty there is a fix about common logging and maybe this help me running my mvnforum in the same instance of I2P
            
-
            13:50 < redzara> Jetty-5.1.5rc1 - 23 August 2005
            
-
            13:52 < jrandom> ah cool, whats the problem exactly redzara?
            
-
            13:52 < jrandom> nickless_head: if you find a way, let us know
            
-
            13:52 < redzara> or maybe i could even only build my own I2P with the latest version of jetty
            
-
            13:52 < jrandom> redzara: that you certainly can do - just drop in the jetty jar files into your i2p lib directory
            
-
            13:53 < redzara> jrandom : everythime i try to start mvnforum in I2P, jetty failed to find apache common logging
            
-
            13:53 <+nickless_head> Oh! I just noticed that the default i2pproxy.pac uses a mode which allows sites to switch proxy'ing to i2p on and off at runtime, which is protected by the TOTALLY SECURE AND UNBREAKABLE </sarcasm> default password "passw0rd". Please, someone who knows about cvs change this.
            
-
            13:54 < jrandom> redzara: thats in commons-logging.jar and commons-el.jar iirc, which should be in your lib dir and in your wrapper.config's classpath
            
-
            13:54 < jrandom> nickless_head: yet another reason why i dont recommend anyone use it ;)
            
-
            13:55 < redzara> yes i know, i'm not so n00b :)) i've to dig into again with this new version of jetty
            
-
            13:56 < jrandom> cool, keep us updated
            
-
            13:56 < redzara> np
            
-
            13:57 < fox> * mihi guesses most i2p users will reveal their "real ip" to a java applet  anyway :)
            
-
            13:57 < fox> <mihi> try http://www.stilllistener.com/checkpoint1/Java/ (and scroll down)
            
-
            13:58  * jrandom sees lots of blank fields ;)
            
-
            13:59 <+bla> fox: All one exposes is the relation between an IP and a particular client destination, where the client destination will change at every router restart.
            
-
            13:59 < jrandom> bla: unless the user is on some site like e.g. http://i_have_illegal_stuff.i2p/
            
-
            14:00 < jrandom> (exposing the clients IP "just once" is fatal enough ;)
            
-
            14:00 <+bla> jrandom: Yes. 
            
-
            14:00 <+bla> But then again, if you're serious about anonymous browsing, you'll use temporary HTTP proxies, and disable all things java, and plugins, and cookies, entirely
            
-
            14:01 < jrandom> or use syndie :)
            
-
            14:02 < ZULU> sorry for interruption,is duck.ip down ?
            
-
            14:02 <+bla> jrandom: Is it time yet for general questions?
            
-
            14:02 < jrandom> aye, we're on 4) ???
            
-
            14:02 < jrandom> ZULU: yeah, duck is offline for the time being
            
-
            14:03 <+bla> jrandom: I've edited the java-files that help profiles.jsp and tunnels.jsp generate the country-flags
            
-
            14:04 <+bla> jrandom: However, where do I place images that I can actually LINK to, and that will work, on my local router (_not_ my eepsite)?
            
-
            14:06 < jrandom> we need a "get.jsp?name" that dumps the contents of ./docs/'name' to the browser
            
-
            14:06 < jrandom> (aka you need to have it in the .war right now, but with a tiny .jsp file, you could dump 'em in docs)
            
-
            14:06 <+bla> jrandom: Ah, ok, so it wasn't my fault ;)
            
-
            14:06 < jrandom> heh nope, blame me :)
            
-
            14:09 < jrandom> ok, if there's nothing else for the meeting
            
-
            14:09  * jrandom winds up
            
-
            14:10  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting146.html b/www.i2p2/pages/meeting146.html
deleted file mode 100644
index 37f47a4a..00000000
--- a/www.i2p2/pages/meeting146.html
+++ /dev/null
@@ -1,218 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 146{% endblock %}
-{% block content %}
            I2P dev meeting, September 06, 2005
            
-
            
-
            13:04 < jrandom> 0) hi
            
-
            13:04 < jrandom> 1) Net status
            
-
            13:04 < jrandom> 2) Syndie status
            
-
            13:04 < jrandom> 3) susidns
            
-
            13:04 < jrandom> 4) ???
            
-
            13:04 < jrandom> 0) hi
            
-
            13:04  * jrandom waves
            
-
            13:04 <+bar> salaam aleikum
            
-
            13:04 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2005-September/000888.html
            
-
            13:04 <+Ragnarok> hi
            
-
            13:04  * cervantes tips his hat
            
-
            13:04 <+fox> * adamta waves back across the Irc2p/Freenode bridge
            
-
            13:05 < jrandom> :)  ok, movin' in to 1) net status
            
-
            13:05 <@cervantes> *** Disconnected
            
-
            13:05 < jrandom> things seem to be going reasonably well from what i can see
            
-
            13:05 < jrandom> heh
            
-
            13:06  * cervantes concurs...only one netsplit in a few days
            
-
            13:06 < jrandom> i know we do still have some problems when one's net con is heavily congested (causing messages to back up and fail, resulting in more elGamal and higher CPU usage)
            
-
            13:06 <@cervantes> and my irc connection uptime is as long as my routers'
            
-
            13:06 <+Ragnarok> same as usual for me.  Slow, but usable, with intermittent unreliability
            
-
            13:07 < jrandom> nice, i have been seeing that too cervantes 
            
-
            13:07 < jrandom> Ragnarok: unreliability with eepsites, irc, i2pbt, i2phex, mail, all of the above?  with 0.6.0.5 or earlier?
            
-
            13:08 <+Ragnarok> mostly in the form of irc disconnects every few hours. 
            
-
            13:08 <+Ragnarok> don't use a whole lot else, so I don't have much more information
            
-
            13:08 < jrandom> hmm, do you have the bw limiter set?
            
-
            13:08 <+Ragnarok> yeah
            
-
            13:08 < jrandom> (as a reminder, -1 now means 16KBps)
            
-
            13:09 <+Ragnarok> it's set to more than the default
            
-
            13:09 < jrandom> ok cool, is it hitting that limit at all, and/or is that limit appropriate for your real net capacity?
            
-
            13:09 <+Ragnarok> the limit is well below my real capacity, since setting it high seems to kill my wireless router
            
-
            13:10 < jrandom> heh ok
            
-
            13:10 <+Ragnarok> but my router doesn't seem to hit the limit anyway
            
-
            13:11 <+Ragnarok> I can try to stress test it a bit, and keep better track
            
-
            13:11 < jrandom> does the peak bw usage hit it though (per oldstats.jsp)?  i2p is pretty bursty, and congestion on a burst might cause an irc discon
            
-
            13:11 < jrandom> cool, that'd be great.  i can only locally test so many situations, so any reports are appreciated
            
-
            13:11 <+Ragnarok> which number am I looking for.  oldstats is pretty dense...
            
-
            13:12 <+Ragnarok> s/./?/
            
-
            13:12 < jrandom> heh, sorry - oldstats.jsp#bw.sendBps the 60s peak (the second number on the line)
            
-
            13:14 <+Ragnarok> what are the units?  The number seems highly improbable
            
-
            13:14 < jrandom> KBps, sorry
            
-
            13:14 < jrandom> (its improperly named)
            
-
            13:15 < Pseudonym> bits or bytes?
            
-
            13:15 < jrandom> bytes
            
-
            13:15 <+Ragnarok> unfortuneately, it must be wrong then
            
-
            13:15 <+Ragnarok> the peak number is a small fraction of the limit, and of the current usage of the router
            
-
            13:15 < jrandom> hmm, its pretty specific, counting sizeof(messages received)
            
-
            13:16 < jrandom> (though the bw limiter itself works at a lower level, counting sizeof(packets received or sent)
            
-
            13:16 <+Ragnarok> how bad is it if I cut & paste the line? :)
            
-
            13:16 < jrandom> might be safer to msg it to me 
            
-
            13:17 <+Ragnarok> wait, I was looking at the 60 m rate.  It still looks low, but at least it's higher than the current usage.
            
-
            13:17 <+Ragnarok> sorry
            
-
            13:17 <+Ragnarok> I'll /msg you more info
            
-
            13:17 <@cervantes> Ragnarok: we'd instantly be able to determin your name, address and credit details from the netDB
            
-
            13:17 < jrandom> heh
            
-
            13:18 < jrandom> cervantes: thats why the netDb bw publishes only the *current* rate, not the peak ;)
            
-
            13:18 < jrandom> (but yeah, giving out one's bw usage can be dangerous to an adversary)
            
-
            13:19 < jrandom> ok, anyone else have anything to bring up wrt net status?
            
-
            13:21 < jrandom> if not, moving on to 2) syndie status
            
-
            13:22 < jrandom> lots of syndie progress, as outlined in the email and on my blog.  rather than repeating it here, anyone have anything to bring up on that front?
            
-
            13:22 <@cervantes> Officiali2pApps++
            
-
            13:23 <+fox> <adamta> I'm modifying the JSP files to use more structured/semantic markup so that it can be more flexibly styled with CSS.
            
-
            13:23 <+fox> <adamta> I don't have anything to show yet, but I'll post on the mailing list when I have something ready.
            
-
            13:23 <+Ragnarok> maybe a small description on what you think the common use case for syndie is might be nice.  I'm still a little unsure as to what it is, aside from a blog CMS
            
-
            13:23 < jrandom> cool adamta - be sure to work with the latest codebase, as I went through and css'ed everything last night
            
-
            13:24 < jrandom> (at a rought level, that is)
            
-
            13:24 <+fox> <adamta> jrandom: Oops... I'd been working on an earlier version.
            
-
            13:24 <+fox> <adamta> I'll `cvs update` and see what's changed, then.
            
-
            13:24  * Ragnarok , asking for user docs.  Oh the hypocrisy
            
-
            13:24 < jrandom> good call Ragnarok.  the use case is essentially '$myI2P.getUseCases()'
            
-
            13:25 < jrandom> safe syndication and publication of content, rather than using eepsites
            
-
            13:25 < jrandom> (as eepsites don't allow safe syndication, require more skill for publication, and require high availability of the operating node)
            
-
            13:25 <+Ragnarok> how is it syndicated, though?
            
-
            13:26 < jrandom> a good intro to syndie's aims is in the post http://syndiemedia.i2p/index.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=1124496000001&images=false&expand=true
            
-
            13:27 < jrandom> syndication, right now, is done through http with explicitly specified syndication peers (either apache archives, other syndie instances, or freesites with syndie archives)
            
-
            13:27  * cervantes just pulled apart the syndie css... it's sufficiently classes to do a varied amount of styling, but the markup itself isn't good for working in new themes
            
-
            13:27 <+Ragnarok> oh, nice.  I don't think I've seen that
            
-
            13:27 <@cervantes> *classes=classed
            
-
            13:27 <@cervantes> adamta: I'd be interested in seeing what you come up with
            
-
            13:28 < jrandom> cervantes: i'm no css wonk, so anyone inspired to improve upon it, restructure it, or revamp how the whole css/frontend works is very much appreciated :)
            
-
            13:28 <@cervantes> just get rid of those damn tables :)
            
-
            13:28 < jrandom> heh
            
-
            13:30 <+fox> <adamta> cervantes+jrandom: Indeed. There's enough there for basic styling, like changing the colour scheme, but I'm trying to modify it to get rid of the tables and to provide enough semantic markup (nested <div>s for sections, header tags, and so forth, all with classes and IDs when it would be useful) so that a stylesheet can completely change the appearance to the user's liking.
            
-
            13:30 <@cervantes> cool
            
-
            13:30 < jrandom> kickass adamta!
            
-
            13:31  * jrandom will not touch that side of things for a bit (i've got plenty to work on in the router :)
            
-
            13:31 <@cervantes> on a semi related note the new routerconsole themes have been somewhat delayed by arcturus' *ahem* disappearence
            
-
            13:31 < jrandom> heh d'oh
            
-
            13:31 <@cervantes> I'm trying to pick up where he left off with some of the workflow tweaks
            
-
            13:32 <@cervantes> but I don't have the JSP skills to do anything radical like fix the broken tunnel config screens
            
-
            13:33 < jrandom> ah cool, any progress is good, and if you need help with anything in particular, i'm 'round
            
-
            13:33 < jrandom> adamta: one thing to keep in mind is the multiple-style thing (using the author-selected but locally hosted style) ((check my recent blog posts for more info))
            
-
            13:33 <@cervantes> having said that the new alternative theme is looking ok
            
-
            13:33 < jrandom> nice
            
-
            13:34 <+fox> <adamta> The new color scheme is definitely nicer, if that's what you're referring to (?).
            
-
            13:35 <@cervantes> adamta: it would be cool if the author's can select a complete style from a set of templates for their particular blog
            
-
            13:35 < jrandom> cervantes: do you think we should deploy those jsp/css changes arcturus bounced me before, or would you prefer to hold off until you've finished some more pieces of it?
            
-
            13:36 <@cervantes> jrandom: I'm not sure what he gave you
            
-
            13:36 <@cervantes> if you can sling them over to me I can compare...I have made additional markup changes since I last discussed things with him
            
-
            13:37 < jrandom> cervantes: individual blog posts can now have per-blog style applied (causing e.g. class="s_detail_addressLink ss_minimal_detail_addressLink" to be used in the html, assuming the style specified is "minimal")
            
-
            13:37 < jrandom> cool, i'll bounce 'em your way cervantes 
            
-
            13:37 <@cervantes> ta
            
-
            13:38 < jrandom> cervantes: a per-blog theme is a bit tougher - the LJ folks had to deal with it too, and came up with the compromise saying the list containing multiple blogs uses the reader's style preferences, while the list containing just one blog's posts uses the author's style preferences
            
-
            13:38 < jrandom> we could publish a 'DefaultStyle: minimal' in the blog's metadata to allow the later
            
-
            13:39 <@cervantes> yeah that was what I was imagining
            
-
            13:39 <+susi23> (readers preferences should always override others)
            
-
            13:39 <+susi23> (but thats an opinion :)
            
-
            13:39 < jrandom> right, when the reader has explicit preferences
            
-
            13:39 <@cervantes>  /ignore susi23
            
-
            13:39 <@cervantes> sheet it didn't work
            
-
            13:41 <@cervantes> if we make filter by blog more distinct form of navigation
            
-
            13:42 <@cervantes> such as a side list
            
-
            13:42 < jrandom> at the moment, the user's preferences are kind of integrated into the workflow, rather than off in a separate prefs page (e.g. a link to bookmark a blog, or ignore them, or hide/show images).  perhaps when we have multiple local styles, it'd be good to have a 'view style' drop down at the top
            
-
            13:42 <@cervantes> then it will make style changes more pallatable
            
-
            13:42 < jrandom> hmm yeah ,interblog navigation is going to be interesting
            
-
            13:43 < jrandom> so you like how it was originally, with that list of blogs on the left hand side, rather than the drop down?
            
-
            13:43 < jrandom> http://syndiemedia.i2p/viewattachment.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=1124769600000&attachment=0
            
-
            13:44 <@cervantes> <bluesky>well that could be a template preference perhaps?</bluesky>
            
-
            13:44 < jrandom> hmm, i dont know if stylesheets can turn a list into a drop down, can it?
            
-
            13:44 <@cervantes> navigation type: dropdown|sidelist|hierarchy  
            
-
            13:44 <@cervantes> no
            
-
            13:45 < jrandom> ok, yeah, that can be done in jsp & user preference though, no problem
            
-
            13:45 < jrandom> (hierarchy?)
            
-
            13:45 <+susi23> (sure, you can give the select a rows parameter)
            
-
            13:45 <@cervantes> but if you abstract the markup into templates then you can have multiple user preference layouts
            
-
            13:45 < jrandom> ah, true, as a multivalued list
            
-
            13:45 < jrandom> (rather than an html list of links)
            
-
            13:46 <@cervantes> (I was blueskying though)
            
-
            13:46 < jrandom> right right cervantes (though it'd be nice if we can do as much templating as possible through css, since thats easier to deploy themes for)
            
-
            13:46 < jrandom> ((especially with the new docs/syndie_standard.css))
            
-
            13:46 <@cervantes> you might want to save that until version 2 and concentrate on more important aspects
            
-
            13:47 <+susi23> (you could put all three variants in the html source and the users decides which divs we want to hide)
            
-
            13:47 <@cervantes> right, if adamta sorts out the markup then you can probably do quite dramatic variations
            
-
            13:47 < jrandom> aye, but i'm open for ideas for the default.  if there's a better way to nav, it'd be better to deploy that
            
-
            13:47 < jrandom> good call susi23 
            
-
            13:47 <+susi23> (k, not very elegant way ;)
            
-
            13:47 <@cervantes> as in http://www.csszengarden.copm
            
-
            13:48 <@cervantes> * http://www.csszengarden.com
            
-
            13:48  * jrandom is glad i implemented ArchiveIndex as a separate object from Archive, so all this stuff is essentially just churning through the archive.txt textfile :)
            
-
            13:49 < jrandom> ok, anyone have any further questions/comments/concerns wrt syndie?
            
-
            13:50 < jrandom> (one thing to note is that the new petname stuff has a one-click export to the user's userhosts.txt file, dumping any i2p addresses there [but it doesn't import yet])
            
-
            13:50 <@cervantes> nice work
            
-
            13:50 < jrandom> gracias cervantes 
            
-
            13:50 <@cervantes> you going to ever do anything on i2p core again? :)
            
-
            13:50 < jrandom> heh
            
-
            13:51  * jrandom has a pair of killer changes to the router coming up, giving us lots of capabilities
            
-
            13:51 < jrandom> (but more on those when they're tested and ready for deployment)
            
-
            13:51 <@cervantes> i2pponies.ar
            
-
            13:51 <@cervantes> i2ponies.war
            
-
            13:52 <@cervantes> hmm vnc refresh is slow tonight
            
-
            13:52 <+susi23> (pony wars? poor ponies...)
            
-
            13:52 < jrandom> heh
            
-
            13:52 < jrandom> ok, moving on to 3) susidns
            
-
            13:52 < jrandom> susi23: wanna give us a rundown?
            
-
            13:52 <+susi23> well
            
-
            13:53 <+susi23> there is not much to say... susidns is a very simple webapp giving you access to addressbook configuration and subscriptions files
            
-
            13:53 <+susi23> and to your "addressbooks" namely hosts.txt, userhosts.txt and (if existing) your published addressbook
            
-
            13:54 <+susi23> I added an introduction page and some explanations how addressbook works
            
-
            13:54 <+susi23> (ok, how I think addressbok works ;)
            
-
            13:54 < jrandom> w00t :)
            
-
            13:54 <+bar> userhosts.txt?
            
-
            13:54 <+susi23> as there've been user questions about this in the last weeks
            
-
            13:54 <+Ragnarok> I'll send feedback, once I try it out :)
            
-
            13:54 <@cervantes> cool, how ready is it?
            
-
            13:54 <+susi23> sure
            
-
            13:54 <+susi23> usable
            
-
            13:55 < ardvark> i use addressbook, but have no userhosts.txt, or is userhosts.txt my personal/private eepsites?
            
-
            13:55 < jrandom> ardvark: userhosts is for user specified custom overrides (it doesnt exist by default)
            
-
            13:55 <+susi23> userhosts.txt is a 2nd hosts.txt file which is read by the NamingService
            
-
            13:55 < ardvark> ok
            
-
            13:55 <+Ragnarok> userhosts.txt is the one you can edit without fear of dataloss via race conditions :)
            
-
            13:55 <+susi23> and yes people used this for private keys
            
-
            13:56 <+susi23> (which is a bit dangerous now when you activate addressbook publication)
            
-
            13:57 <+susi23> well, no magic here... thats all
            
-
            13:57 <+Ragnarok> adding a privatehosts.txt or something, which is read by the NamingService but not addressbook would be trivial
            
-
            13:57 <+susi23> true
            
-
            13:57 <@cervantes> I would like to see that ;-)
            
-
            13:58  * cervantes clutches his private keys ;-)
            
-
            13:58 < jrandom> ooh, susidns intro page is nice :)
            
-
            13:58 < jrandom> (cervantes/susi/ragnarok/et al: see the syndie pet name web interface too [you need to log in to see it])
            
-
            13:58 <+susi23> as addressbooks publication is turned off by default there is no danger for normal people
            
-
            13:58 < jrandom> right right
            
-
            13:59 <+Ragnarok> I've asked this before, but is there anything I can do to make life easier for people writing addressbook frontends?
            
-
            13:59  * cervantes has forgotten his login
            
-
            13:59 < jrandom> cervantes: you can register again ;)
            
-
            13:59 <+Ragnarok> so have I, probably
            
-
            14:00 <@cervantes> wouldn't sushidns be a better name?
            
-
            14:00  * cervantes ducks
            
-
            14:00 <+susi23> ragnarok: how about a function to interupt the sleeping thread for immediate (user triggered) subscription update?
            
-
            14:01 < jrandom> ooh, or a manual "fetch now" capabiliy
            
-
            14:01  * susi23 slaps cervantes with a large trout.
            
-
            14:01 <+susi23> yes, calling it dns is ridiculous here...but thats a historic name :)
            
-
            14:01 <@cervantes> raw trout!
            
-
            14:01  * cervantes grabs the soya sauce
            
-
            14:01 <+susi23> (pervert!)
            
-
            14:02 <+susi23> k, back to topic please ;)
            
-
            14:02 <+Ragnarok> ok, I'll look into that
            
-
            14:02 <+susi23> (don't drink at meetings!)
            
-
            14:02  * jrandom hides my drink
            
-
            14:03  * susi23 pings jrandom
            
-
            14:03 < jrandom> ok cool, thanks susi, looks v.nice
            
-
            14:03 < jrandom> ok, moving on to 4) ???
            
-
            14:03 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            14:04 <@cervantes> if anyone has been experiencing any issues with irc2p please let the admins know
            
-
            14:06 <@cervantes> #irc2p is the support channel
            
-
            14:06 <@cervantes> or post to the forum
            
-
            14:06 <@cervantes> jrandom: do you want a syndie forum btw? (or is that redundant)
            
-
            14:07 <@cervantes> susi23: you're welcome to have one too, for you plethora of i2p apps ;-)
            
-
            14:07 < jrandom> atm, i think we're ok without one, thanks though
            
-
            14:07 < jrandom> the susiworld forum
            
-
            14:09 < jrandom> ok, if there's nothing else
            
-
            14:09  * jrandom winds up
            
-
            14:09  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting147.html b/www.i2p2/pages/meeting147.html
deleted file mode 100644
index 4e02d49b..00000000
--- a/www.i2p2/pages/meeting147.html
+++ /dev/null
@@ -1,47 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 147{% endblock %}
-{% block content %}
            I2P dev meeting, September 13, 2005
            
-
            
-
            13:01 < jrandom> 0) hi
            
-
            13:01 < jrandom> 1) Net status
            
-
            13:01 < jrandom> 2) SSU introductions / NAT hole punching
            
-
            13:01 < jrandom> 3) Bounties
            
-
            13:01 < jrandom> 4) Client app directions
            
-
            13:01 < jrandom> 5) ???
            
-
            13:01 < jrandom> 0) hi
            
-
            13:01  * jrandom waves
            
-
            13:01 < jrandom> weekly status notes posted up (before the meeting!) at http://dev.i2p.net/pipermail/i2p/2005-September/000892.html
            
-
            13:01 < jrandom> (drop the .net if you prefer, of course)
            
-
            13:03 < jrandom> jumping on in to 1) Net status
            
-
            13:03 < jrandom> there are a few users bouncing a bit on irc, but it seems pretty good for most
            
-
            13:04 < jrandom> does anyone have any reports regarding other protocols to bring up, or questions/concerns regarding the net status?
            
-
            13:05 <@cervantes> I've found this version to be the most stable since 0.4.x
            
-
            13:05 <@cervantes> so top work! ;-)
            
-
            13:05 < jrandom> w00t
            
-
            13:05 < jrandom> ok, if there's nothing else on 1) net status, lets move on to 2) SSU introductions
            
-
            13:06 < jrandom> I don't really have much to add beyond whats in the email - anyone have any questions/comments/concerns?
            
-
            13:07 < jrandom> if not, i suppose we'll be hearing more when 0.6.0.6 comes out ;)
            
-
            13:07 < jrandom> ok, moving on to 3) bounties
            
-
            13:07  * cervantes battens down the hatches
            
-
            13:08  * cervantes wonders if people have got the hang of the new meeting time yet
            
-
            13:08 < jrandom> hmm, it doesn't seem like Comwiz is around at the moment.  I suppose we can expect more info when its ready
            
-
            13:08 < jrandom> bah, bloody americans and their slow time zones
            
-
            13:09 <+Myo9> I though you were one, having your own bunker and all. ;)
            
-
            13:09  * susi23 listens to the dialog ;)
            
-
            13:10 < jrandom> ok, if there's nothing else on 3), we can race on through to 4) client apps directions
            
-
            13:11 < jrandom> lots of typing in the mail, so rather than repeat it here, anyone have any thoughts on it?  
            
-
            13:11 < jrandom> its not just an immediate question, if/when people want to chime in on that stuff, please feel free to post to the forum or list as well
            
-
            13:12 <@cervantes> there's a new Application Support section in the forum, which is a good place to post about such matters
            
-
            13:12 < jrandom> ah good call
            
-
            13:13 < jrandom> also the discussion section for non-support comments, e.g. prioritization stuff
            
-
            13:13 < jrandom> ok, working us towards the first under-15-minute meeting in a long time...
            
-
            13:14 < kbi> i guess the meetings go fast when everyone is happy
            
-
            13:15 < jrandom> could be, and hopefully we'll get some posts on the list and the forum
            
-
            13:15 < jrandom> ok, moving on to 5) ???
            
-
            13:15 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            13:15 <@cervantes> (except their lunch)
            
-
            13:17 <@cervantes> there goes 15 mins
            
-
            13:17  * jrandom winds up
            
-
            13:17  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting148.html b/www.i2p2/pages/meeting148.html
deleted file mode 100644
index a3430cb0..00000000
--- a/www.i2p2/pages/meeting148.html
+++ /dev/null
@@ -1,103 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 148{% endblock %}
-{% block content %}
            I2P dev meeting, September 20 @ 20:00 GMT
            
-
            
-
            16:18 < jrandom> 0) hi
            
-
            16:18 < jrandom> 1) 0.6.0.6
            
-
            16:18 < jrandom> 2) I2Phex 0.1.1.27
            
-
            16:18 < jrandom> 3) migration
            
-
            16:18 < jrandom> 4) ???
            
-
            16:18 < jrandom> 0) hi
            
-
            16:18  * jrandom waves
            
-
            16:18 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-September/000929.html
            
-
            16:18 <+postman> hello
            
-
            16:18 < forest> hi
            
-
            16:18 < jrandom> lets jump on in to 1) 0.6.0.6
            
-
            16:19 < jrandom> the status notes cover pretty much what i've got on my mind for 0.6.0.6.  anyone have any questions/concerns/comments to bring up?
            
-
            16:19 <+postman> jrandom: observation:
            
-
            16:19 <+postman> jrandom: much higher bandwidth consumption
            
-
            16:20 <+postman> jrandom: all within the limits and running fine - but my routers really getting warm now
            
-
            16:20  * nickless_head makes similar observation
            
-
            16:20 < jrandom> aye, me too, i think its likely due to an increase in bt and i2phex traffic
            
-
            16:20 <+postman> what increase, with just 80 active torrents on the tracker? :)
            
-
            16:20 < jrandom> heh
            
-
            16:21 <+postman> but its good to see, that the network does not crumble
            
-
            16:21 <+postman> irc is pretty stable altho the router does 50k/s atm
            
-
            16:21 < jrandom> mos' def'.  i'm not even logged into freenode anymore, as irc here is stable enough
            
-
            16:22  * postman hands the mike back
            
-
            16:22 < jrandom> cool, thanks.  i think there's definitely still room to go for bandwidth efficiency, but it seems reasonable atm
            
-
            16:22 < jrandom> (hopefully the thing i'm working on will help, but more on that when its ready)
            
-
            16:22 < fox> <mihi> you should definitely distinguish between OK (Nat) and Err (Nat)...
            
-
            16:23 < fox> <mihi> or is your hole punching almighty?
            
-
            16:23 < jrandom> heh
            
-
            16:23 < jrandom> well, ERR-SymmetricNAT is and will continue to be an ERR
            
-
            16:23 < fox> <mihi> or is it impossible to check whether it was successful?
            
-
            16:24 < fox> <mihi> ok
            
-
            16:24 < jrandom> but ERR-Reject is due to restricted cone, while full cone nats work fine
            
-
            16:24 < jrandom> (since i2p uses only one source port for everyone, as long as you're on i2p you'll have a hole punched for the full cone)
            
-
            16:25 < jrandom> still, it is better when people forward their ports so they don't need introducers, as that lets them also become introducers themselves
            
-
            16:25 < fox> <mihi> as long as there are no nasty iptables rules (like drop UDP to 8887 from IP addresses divisable by 7 :) )
            
-
            16:25 < jrandom> heh
            
-
            16:26 < jrandom> and unfortunately, some people do have b0rked configurations like that (*cough*peerguardian*cough*)
            
-
            16:26 < jrandom> someone the other day was wondering why i2p didn't work, even though they had their firewall dropping packets from all .edu peers
            
-
            16:27 <+Ragnarok> .edu?  That's pretty random
            
-
            16:27 < jrandom> yeah, made no sense to me, in so many ways
            
-
            16:27 < jrandom> but, c'est la vie
            
-
            16:27  * nickless_head sings: We don't need no education...
            
-
            16:28 < jrandom> heh
            
-
            16:28 < jrandom> ok, anyone else have anything on 1) 0.6.0.6?
            
-
            16:29 < jrandom> if not, moving on to 2) i2phex 0.1.1.27
            
-
            16:29 < jrandom> not much to say here beyond whats in the mail either...
            
-
            16:30 <+postman> jrandom: there was no positive response in the mentioned forums either :(
            
-
            16:31 <+postman> jrandom: i will forward your statusnotes and links - maybe the readers get the point
            
-
            16:31 < jrandom> postman: people are of course able to use whatever they want, but I don't recommend the binary release from legion as the source doesn't match the binary, and the launcher is entirely closed source
            
-
            16:32 < jrandom> now that we've got i2phex on a web accessible location, built from cvs, hopefully that will reduce people's reliance on that
            
-
            16:33 < jrandom> (perhaps if you want to post the irc log from #i2p-chat an hour or two ago between legion and i, that might help explain the situation to people more completely)
            
-
            16:34 < jrandom> ok, anyone else have anyhing on 2) i2phex, or shall we move on to 3) migration
            
-
            16:34  * postman has a look
            
-
            16:34 < jrandom> there's not much really to add for 3), its more of an fyi
            
-
            16:34 < jrandom> so, perhaps we can jump quickly to 4) ???
            
-
            16:34 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            16:35 <+Complication> Migration?
            
-
            16:36 < jrandom> if you didn't notice, great :)
            
-
            16:36 < jrandom> we moved from one colo to another
            
-
            16:36 < jrandom> (cvs.i2p.net, dev.i2p.net, www.i2p.net, mail.i2p.net)
            
-
            16:36 <+Complication> Oh, that migration. :)
            
-
            16:36  * Complication is simply a bit slow today
            
-
            16:39 <+Complication> By the way, 0.6.0.6 seems very nice... in the regard that my router didn't touch 0 participating tunnels in 54 hours.
            
-
            16:39 <+Complication> Not even once.
            
-
            16:39 < jrandom> nice
            
-
            16:40 < jrandom> ok, if there's nothing else people want to bring up for the meeting...
            
-
            16:40  * jrandom winds up
            
-
            16:40 <+postman> jrandom: one thing
            
-
            16:40  * jrandom stops winding
            
-
            16:40 <+postman> jrandom: you just incremented the i2phex version - what if sirup plans another release?
            
-
            16:40 < jrandom> postman: sirup uses the cvs
            
-
            16:41 <+postman> jrandom: how about giving it a an additional tag
            
-
            16:41 <+postman> ok, that's fine then
            
-
            16:41 <+postman> :)
            
-
            16:41  * postman is back in his cave
            
-
            16:41 < jrandom> (developing code outside a source control system == crazy)
            
-
            16:41  * Kefoo remembers how crazy it was developing inside a source control system, too
            
-
            16:41 <+postman> jrandom: (it did not need to be YOUR's)
            
-
            16:42 < jrandom> heh true enough Kefoo ;)
            
-
            16:42 < jrandom> heh well, yeah... his just happens to be though ;)
            
-
            16:43  * bar just set a new personal record of 156 concurrent udp connections (old record was 152)
            
-
            16:43 < jrandom> cool, yeah, i saw 173 earlier today
            
-
            16:44 <+bar> oh :) yeah the indtroducing is doing its thing fo' sure
            
-
            16:44 < Kefoo> Not to backtrack, but is i2phex supossed to try connecting on startup? I've heard both yes and no.
            
-
            16:44 <+bar> -d
            
-
            16:44 < jrandom> wikked bar
            
-
            16:44 < jrandom> Kefoo: afaik, no.
            
-
            16:44 < jrandom> but, i'm no phex dev
            
-
            16:45 < Kefoo> The only way I've found is to copy and paste the host keys into the program and connect to them manually
            
-
            16:45 < jrandom> thats what i've done Kefoo
            
-
            16:45 <+postman> wind ye up now, jrandom :)
            
-
            16:45 < Kefoo> Ok, so I'm not making it harder than it should be
            
-
            16:45 < Kefoo> I do that sometimes
            
-
            16:46 < jrandom> Kefoo: if there's something easier, i'd like to hear about it :)
            
-
            16:46 < jrandom> ok ok postman, you can go get your beer ;)
            
-
            16:46  * jrandom winds up
            
-
            16:46  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting149.html b/www.i2p2/pages/meeting149.html
deleted file mode 100644
index fdf31cc2..00000000
--- a/www.i2p2/pages/meeting149.html
+++ /dev/null
@@ -1,258 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 149{% endblock %}
-{% block content %}
            I2P dev meeting, September 27, 2005
            
-
            
-
            16:14 < jrandom> 0) hi
            
-
            16:14 < jrandom> 1) Net status
            
-
            16:14 < jrandom> 2) 0.6.1
            
-
            16:14 < jrandom> 3) ???
            
-
            16:14 < jrandom> 0) hi
            
-
            16:14  * jrandom waves
            
-
            16:14 <+Ragnarok> ok, I'll hold my further questions
            
-
            16:14 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-September/000933.html
            
-
            16:14 <+Ragnarok> hi :)
            
-
            16:15 < wiht> Hello.
            
-
            16:15 < jrandom> we can definitely dig into it further in 3?? if you'd prefer
            
-
            16:15 <+Ragnarok> cool
            
-
            16:15 < jrandom> ok, jumping into 1) Net status
            
-
            16:15 < jrandom> in general, things seem pretty solid
            
-
            16:16 < A123> Is the http outproxy run by just one router?
            
-
            16:16 < wiht> I see 307 known nodes on my router console.
            
-
            16:16 < A123> (I'm still a little hazy on how I2P works)
            
-
            16:16 < jrandom> there are two outproxies configured by default, and a few others available not configured by default
            
-
            16:16 < wiht> Has anyone's bandwidth been maxed out by the recent growth of the network?
            
-
            16:17 < jrandom> well, my bandwidth usage has grown, a steady 30-40KBps on my routers
            
-
            16:17 < jrandom> (to a steady 30-40, that is)
            
-
            16:18 < jrandom> (i'm also running a few high traffic services, like squid.i2p ;)
            
-
            16:19 < A123> Ever look at the logs?
            
-
            16:19 < jrandom> of squid?  no, i have it set to not do any request logging
            
-
            16:20 <+Ragnarok> remember, he could be lying :)
            
-
            16:20 <+Ragnarok> thus, it's a stupid question to ask
            
-
            16:20 < jrandom> (though that could be a lie, and may work for the FBI/etc, so don't abuse it ;)
            
-
            16:20 < A123> I was just curious as to whether there was anything interesting in there :)
            
-
            16:21 <+mihi> A123: run your own outproxy :)
            
-
            16:21 < gloin> A123: setup a tor node.
            
-
            16:21 < A123> Is it easy to set up?
            
-
            16:21 < jrandom> not really
            
-
            16:21 < A123> gloin, tor is explicitly not designed for file sharing, so I have little interest in it.
            
-
            16:22 < jrandom> (an outproxy, that is.  tor is easy to set up)
            
-
            16:22 < A123> Or at least, they've explicitly stated that they don't want people to use it for file sharing.
            
-
            16:22 < wiht> jrandom, do you still want to wait for version 1.0 before a full public announcement of the I2P project's maturity?
            
-
            16:23 <+mihi> A123: it is definitely harder than registering your nick with nickserv *hint* *hint*
            
-
            16:23 < A123> Oh yeah, I sure don't want A123 to be taken :)
            
-
            16:23 < wiht> If the network is doing well now, could it stand the addition of more users?
            
-
            16:23 < jrandom> we'll need to do some outreach before 1.0 so that we can have some testing in larger environments
            
-
            16:24 <+Ragnarok> maybe a preview release, or some such thing
            
-
            16:24 < wiht> A beta release? Sounds like a good idea.
            
-
            16:25 < jrandom> aye, that'll happen along side the website revamp, maybe before 0.6.2
            
-
            16:25 < jrandom> (or maybe @ 0.6.2)
            
-
            16:25 < jrandom> (website revamp being part of that critical path so we dont spend hours upon hours answering the same questions)
            
-
            16:25 <+Ragnarok> well, with a little more end-user polish than just another beta
            
-
            16:26 < A123> Is it possible for I2P-aware clients to configure tunnels themselves easily?
            
-
            16:26 < jrandom> yes
            
-
            16:26 < A123> I guess they could always do HTTP requests to the console...
            
-
            16:26 <+Ragnarok> the router console also need a serious revamp.  It would be nice for the initial page to be more like an i2p portal, and move all the technical stuff a little farther in
            
-
            16:26 < jrandom> its one of the properties they send when they connect to i2p
            
-
            16:26 < jrandom> agreed Ragnarok
            
-
            16:27 < A123> Hrm. The Azureus I2P plugin could have a bit of additional friendliness, then.
            
-
            16:27 < A123> Or any friendliness at all.
            
-
            16:27 < jrandom> agreed A123 ;)
            
-
            16:27 < jrandom> (though they've done a great job showing the proof of work)
            
-
            16:28 < jrandom> there have been a lot of great suggestions on the mailing list as of late regarding usability
            
-
            16:28 < jrandom> many/most of which should be done prior to asking new users to try i2p out
            
-
            16:28 < A123> From the console: "If you can't poke a hole in your NAT or firewall to allow unsolicited UDP packets to reach the router, as detected with the Status: ERR-Reject..."
            
-
            16:28 < A123> Where would I see "Status: ERR-Reject"?
            
-
            16:29 <+Ragnarok> it's nice that we're at the point where we can worry about usability :)
            
-
            16:29 < jrandom> A123: on the left hand side of your router console, it says Status: OK (or Status: unknown, or something else)
            
-
            16:29 <+Complication> In the Status field of the router console.
            
-
            16:29 < jrandom> true 'nuff Ragnarok 
            
-
            16:29 <+Complication> Hopefully you've got an OK or OK (NAT) there.
            
-
            16:30 < A123> Complication, ah, thanks. Is that the thing that gets updated if you click on "Check network reachability..."?
            
-
            16:30 < wiht> I hope that you will not have to break compatibility in future releases of I2P. Full network migration to a new version seems to have been painful in the past.
            
-
            16:30 <+Complication> A123: yes, it should test again when you click
            
-
            16:30 <+Complication> Doesn't happen instantly, though.
            
-
            16:30 < jrandom> eh, they're not as painful as they used to be, but yeah, it'd be good if we can avoid it wiht
            
-
            16:30 < A123> So I have to refresh the page?
            
-
            16:30 < A123> Well, no, that would do another http post...
            
-
            16:31 <+Complication> A123: it may take a minute to find a testing-suitable peer
            
-
            16:31 <+Complication> 'cause you cannot test with those whom you're already speaking to
            
-
            16:31 <+Complication> It could give false results.
            
-
            16:32 <+Complication> So, it should show up when you view the router console sometime later.
            
-
            16:32 <+Complication> Basically, in ideal circumstances, you shouldn not need to fire a peer test manually.
            
-
            16:33 <+Complication> =shouldn't need
            
-
            16:33 < jrandom> right, i2p now does a peer test automatically when certain events occur
            
-
            16:33 < jrandom> (such as when someone tells you that your IP is something other than what you think it is)
            
-
            16:33 < A123> I found that button completely unintuitive. I had no idea what it was updating and when, it never explicitly told me the results of the test...
            
-
            16:34 < A123> The page wasn't automatically refreshing (I think), I can't do a reload in the browser...
            
-
            16:34 < jrandom> reload should be safe
            
-
            16:34 < A123> Surely that fires another test?
            
-
            16:34 < jrandom> but yeah, the router console was designed more for technical reasons rather than usability
            
-
            16:34 < jrandom> A123: it has a nonce to prevent that
            
-
            16:34 <+Complication> That facet might benefit from a better explanation text in future
            
-
            16:35 < wiht> Have we skipped 2) and gone to 3) already?
            
-
            16:35 < jrandom> Complication: we'll probably drop it, since its unnecessary
            
-
            16:35 < jrandom> no, still on 1
            
-
            16:35 < jrandom> actually, anyone have anything else for 1) network status?
            
-
            16:35 < A123> Ah, indeed, after a few times it complains about the nonce.
            
-
            16:35 < jrandom> if not, moving on to 2) 0.6.1
            
-
            16:35 < A123> "nonce" to non-geeks is just going to seem like a nonsense word.
            
-
            16:36 < A123> :)
            
-
            16:36  * Complication looks at graphs
            
-
            16:36 <+Complication> No complaints about net status from here.
            
-
            16:36 < jrandom> w3wt
            
-
            16:37 < A123> Is there any reason that reseeding isn't automatic?
            
-
            16:37 < jrandom> ok, i don't really have too much to mention regarding 0.6.1 beyond whats in the mail
            
-
            16:37 < gloin> hmm.. shouldn't be the incoming and outoging traffic more or less symmetric?
            
-
            16:37 < A123> Mine seems more or less symmetric.
            
-
            16:37 < jrandom> A123: yes, though we may be able to do it safer
            
-
            16:37 <+Complication> gloin: not if one's leeching or seeding ;)
            
-
            16:37 <+Ragnarok> not if you're downloading stuff
            
-
            16:38 < A123> Total: 3.74/4.09KBps (that's in/out)
            
-
            16:39 < gloin> Complication: Is this a security problem? Shouldn't the 'foreign' traffic be reduced?
            
-
            16:39 <+Complication> gloin: depends on what the criteria are
            
-
            16:40 <+Complication> A person striving for utmost security clearly shouldn't be doing things which permit others to cause observable changes in their BW.
            
-
            16:40 < jrandom> gloin: as we move to 1.0, we will stop publishing those stats
            
-
            16:40 < A123> My ISP will still know them...
            
-
            16:40 < jrandom> but yes, defending against local traffic analysis does require you to participate in other people's tunnels
            
-
            16:41 <+Complication> (for a strict definition of "their BW", meaning "bandwidth use starting/ending at their node")
            
-
            16:41 < jrandom> (or do sufficient chaff activity.  tarzan for instance has "mimics" for wasting bandwidth^W^Wdefending anonymity)
            
-
            16:41 < A123> Hrm.
            
-
            16:41 < A123> I'm on ADSL, with far more download ability than upload.
            
-
            16:42 <+Complication> Many are.
            
-
            16:42 < A123> When my download exceeds my upload, doesn't that imply that I'm downloading stuff?
            
-
            16:43 < wiht> No, you could also be forwarding others' traffic.
            
-
            16:43 <+Complication> I guess it would imply you are downloading something.
            
-
            16:43 < A123> Does I2P cache data?
            
-
            16:43  * wiht would like to be corrected if that's wrong.
            
-
            16:43 <+Complication> Unless you are seeding as much as you're leeching.
            
-
            16:43 < jrandom> i2p itself does not cache
            
-
            16:43 <+Complication> A123: no caching occurs to my knowledge
            
-
            16:43 < jrandom> though syndie, on the other hand, does.  
            
-
            16:44 < A123> If there's no caching, then my download exceeding my upload must mean that I'm downloading something myself, right?
            
-
            16:44 < jrandom> if you have large amounts of inbound trafffic but no current outbound traffic, you could just be running a syndie node
            
-
            16:44 < jrandom> yes A123, given a small enough time frame
            
-
            16:45 < A123> Since I could only usefully be downloading at the speed of my upload, after network buffers fill.
            
-
            16:45 < jrandom> for a certain threat model, yes
            
-
            16:45 < A123> Hrm.
            
-
            16:45 < jrandom> (local passive attacker with sufficient resources, or a targetted local attacker, etc)
            
-
            16:46 <+Complication> You could download faster, but it would increase your risk. (For which reason I have allocated up/down similar limits.)
            
-
            16:46 < A123> Ah, good point, I can just limit my download speed.
            
-
            16:46 <@LevDavidovitch> btw, you should limit both your dl and ul speed
            
-
            16:47 <+Complication> But if someone targeted everyone who downloads more than uploads... they'd be targeting everyone and their granny.
            
-
            16:47 < wiht> We are still having disconnection issues with IRC, it seems.
            
-
            16:47 < jrandom> wiht: only a few people are
            
-
            16:47 < wiht> OK.
            
-
            16:47 <@LevDavidovitch> also reconnection is v FAST these days
            
-
            16:48 < jrandom> (and nothing as bad as it was)
            
-
            16:48 < wiht> I agree, reconnections are better.
            
-
            16:48 < jrandom> aye, its nice to have our irc servers hosted on routers with reasonable bw limits :)
            
-
            16:49 < jrandom> ((not that before was unreasonable, it was great, we just outgrew it))
            
-
            16:49 < A123> Is there any technical reason why DCC isn't supported? It can be implemented similar to the nat module, right?
            
-
            16:49 < jrandom> ok, anyone have anything for 2) 0.6.1?
            
-
            16:49 < jrandom> yes A123, there are technical reasons why dcc isnt supported
            
-
            16:50 <@LevDavidovitch> it'd have to be done client side, i think.
            
-
            16:50 < jrandom> someone could implement an irc proxy with dcc support, but no one has
            
-
            16:50 < A123> What are they? Or is that a long discussion?
            
-
            16:50 < jrandom> dcc support requires knowing and interpretting the irc protocol, and rewriting the irc messages sent as necessary
            
-
            16:50 <@LevDavidovitch> normal dcc uses arbitrary ports and all
            
-
            16:50 < jrandom> (in particular, ctcp messages for establishing dcc connections)
            
-
            16:50 < A123> Oh, that's what I meant to ask... Whether it was technically possible to do it as with a nat module (which does as you say).
            
-
            16:51 < jrandom> i dont know what a nat module is?
            
-
            16:51 <@LevDavidovitch> the nat uses some UDP weirdnesses.
            
-
            16:52 <@LevDavidovitch> the nat traversal thing i think he means
            
-
            16:52 < jrandom> ah, ok, yeah, its technically possible, but no one has volunteered to work on it (and i'm swamped)
            
-
            16:52 < A123> No... At least for Linux, there's a masq module for iptables which will rewrite IRC packets with DCC CTCP requests.
            
-
            16:53 <@LevDavidovitch> ah, i see
            
-
            16:53 <@LevDavidovitch> maybe some of that code would be usable
            
-
            16:53 <@LevDavidovitch> depends how intimate it is with the ipfilter thing
            
-
            16:54 < jrandom> probably simpler to just extend I2PTunnelClient to interpret irc perhaps
            
-
            16:54 < A123> http://www.koders.com/c/fidA6A89E1080590138EB211E694473DDDD098B6B75.aspx <- Might be interesting, courtesy of Google.
            
-
            16:54 < jrandom> (in the same way I2PTunnelHTTPClient extends it to interpret HTTP)
            
-
            16:55 <@LevDavidovitch> not in most countries. 
            
-
            16:55 <@LevDavidovitch> oops
            
-
            16:56 < jrandom> A123: an os level filter would be a bit tough to deploy, but if someone wants to work on it, that'd be a good place to start
            
-
            16:57 < jrandom> ok, anything else on 2) 0.6.1, or shall we move on to 3) ???
            
-
            16:57 < A123> jrandom, it wouldn't really need to be OS level, would it? It would be coming through the IRC tunnel anyway...
            
-
            16:58 < jrandom> actually, it wouldn't even work as an iptables filter.  it has to be done inside i2ptunnel or some other i2p-aware proxy
            
-
            16:58 < jrandom> in any case, its a lot of work, and unless someone volunteers to do it, it'll never get done ;)
            
-
            16:59 < jrandom> (it *woudl* be cool though)
            
-
            16:59 < A123> Right.
            
-
            16:59 < A123> I meant "like the iptables filter", not "using the iptables filter" :)
            
-
            16:59 < A123> -the+a
            
-
            16:59 < A123> +n
            
-
            17:00 < A123> Hrm hrm.
            
-
            17:00 <@LevDavidovitch> go forth I think
            
-
            17:01 < jrandom> ok, on to 3) ??? 
            
-
            17:01 < jrandom> (though one could probably say we've been on 3) all along ;)
            
-
            17:01 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            17:01 <+fox> <brutus> on 3) bugzilla would be nice to have in shape before 1.0
            
-
            17:01 < wiht> Speaking of the usability suggestions from the mailing list, have you incorporated any of them into I2P?
            
-
            17:02 < jrandom> brutus: we used to have bugzilla, but no one used it
            
-
            17:03 < wiht> I should say, are you still concentrating on the core I2P functionality and planning to focus on usability a little later?
            
-
            17:03 < A123> I don't want to try it here, but I think that sending someone a DCC request at the moment would reveal to them your IP.
            
-
            17:03 < A123> (Assuming your client knows your IP)
            
-
            17:03 < jrandom> wiht: the last week i've been doing a lot of improvements to the streaming lib which should substantially improve usability
            
-
            17:04 < jrandom> A123: the irc servers filter ctcp messages
            
-
            17:04 < jrandom> (they've been modified)
            
-
            17:04 < A123> Servers...
            
-
            17:04 < jrandom> but yes, that does send your ip to the server (which it may discard, or may file into some NSA database)
            
-
            17:04 < jrandom> so, dont send dcc requests
            
-
            17:04 < A123> I don't really want the server admins knowing who I am, either :)
            
-
            17:05 < A123> (In theory. I don't care now or with you guys)
            
-
            17:05 < A123> It might be worth warning users about that.
            
-
            17:05 < jrandom> there's a page on the wiki about a whole slew of issues iirc
            
-
            17:05 < jrandom> (swing by ugha.i2p)
            
-
            17:06 <+fox> <mihi> btw: are the irc2p servers connected via i2p or directly?
            
-
            17:06 <+Complication> I'd assume i2p
            
-
            17:06 <+Complication> Unless someone's gone mad meanwhile, and not notified me. :P
            
-
            17:06 < wiht> jrandom, that's good, but what about the UI suggestions by Isamoor?
            
-
            17:07 < jrandom> mihi: i believe they're done over i2p
            
-
            17:08 < jrandom> wiht: the list of what i've been doing is available on http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD
            
-
            17:09 < jrandom> there's a lot more to be done, and a lot more will be done, but i have only two hands
            
-
            17:09 < wiht> Thank you, I will look there.
            
-
            17:10 < jrandom> actually, i have something to bring up for the meeting...
            
-
            17:10 < A123> What's the server/channel that fox is changating? Or do I misunderstand fox's purpose?
            
-
            17:11 < jrandom> as mentioned on hq.postman.i2p, we've had over a full year of anonymous mail service through postman's servers!  
            
-
            17:11  * jrandom cheers
            
-
            17:11  * wiht does not want to seem ungrateful.
            
-
            17:12 < A123> jrandom, have the spammers caught on yet?
            
-
            17:12 < jrandom> A123: fox is a bridge to irc.freenode.net
            
-
            17:12 < A123> (OK, it's a slow way to go about spamming...)
            
-
            17:12 < jrandom> A123: doubt it, postman has antispam measures
            
-
            17:12 < jrandom> inbound spam is a bit of a problem though ;)
            
-
            17:13 < jrandom> (but my account there has been well filtered)
            
-
            17:13 < mule> is it really that long. time passes ...
            
-
            17:13 < A123> jrandom, ah, thanks.
            
-
            17:13  * Complication looks if someone has finally dropped him a bear via e-mail
            
-
            17:14 <+fox> <brutus> yeah, postman & cervantes deserve a medal, they're pulling some great weights around here
            
-
            17:15 <+fox> <brutus> excellent services indeed
            
-
            17:16 < jrandom> mos' def'.  as is mule with his outproxy and fproxy, orion with his site, and the rest of y'all with yer content :)
            
-
            17:16 < jrandom> ok, anyone have anything else to bring up for the meeting?
            
-
            17:16 < wiht> Speaking of content...
            
-
            17:16 < wiht> It seems that we know what sites are up or not, but no easily accessible directory of sites.
            
-
            17:17 < A123> My clock runs fast. Would it be possible for the "Updating clock offset to -316819ms from -304801ms" messages to be downgraded from "CRIT"? It's a little disconcerting.
            
-
            17:17 < wiht> I was thinking of creating one where site admins can post what their site is about.
            
-
            17:17 < jrandom> orion.i2p is pretty easily accessible...?
            
-
            17:17 < jrandom> A123: hmm, perhaps
            
-
            17:18 < wiht> It has a short description of sites' purposes?
            
-
            17:18 <+postman> A123: spam is only a problem for incoming mail ( mail FROM the internet )
            
-
            17:18 < jrandom> wiht: yeah, it does, though i dont know where they come from
            
-
            17:18 <+Complication> wiht: no, orion doesn't seem to have that feature
            
-
            17:18 < wiht> I will look again.
            
-
            17:18 < jrandom> iirc jnymo used to maintain them
            
-
            17:18 <+postman> A123: i2p mail  users can rarely spam themselves as well as they cannot spam internet targets
            
-
            17:19 <+Complication> Sorry, meant to say it doesn't seem user-accessible.
            
-
            17:19 < wiht> I was thinking of a directory that categorizes sites, something similar to dmoz.org.
            
-
            17:19 < A123> wiht, as a brand new user, that sounds great.
            
-
            17:19 <+fox> <Sugadude> wiht: Do we have enough sites to need to classify them?
            
-
            17:19 < A123> wiht, but check Freenet for an excellent example of how not to do it.
            
-
            17:20 < jrandom> a reliable categorized site would be neat.  or perhaps we can integrate it into syndie to let people tag and categorize their peer references (and share them)
            
-
            17:20 < jrandom> (syndie already has a set of category tags for each bookmark, laying it out visually dmoz style wouldnt be hard)
            
-
            17:20 < jrandom> and it'd be local <--- fast
            
-
            17:20 < A123> Or just get Google interested in i2p...
            
-
            17:20 < jrandom> heh
            
-
            17:24 < jrandom> ok, if there's nothing more for the meeting...
            
-
            17:25  * jrandom winds up
            
-
            17:25  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting15.html b/www.i2p2/pages/meeting15.html
deleted file mode 100644
index 3013049e..00000000
--- a/www.i2p2/pages/meeting15.html
+++ /dev/null
@@ -1,526 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 15{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 15
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Oct 15 23:31:29 2002
-
            23:31 < logger> test
-
            23:32 < mason> sorry, that test did not work
-
            23:32 < mason> :)
-
            23:32 -!- mode/#iip-dev [+o mids] by Trent
-
            23:32 <@mids> Tue Oct 15 21:32:19 UTC 2002
-
            23:32 <@mids> meeting starts in 1:30 hours
-
            --- Day changed Wed Oct 16 2002
-
            00:44 < geully> hi all
-
            00:50 <@mids> Public IIP meeting in 10 minutes here
-
            00:50 < Robert> Hello all.
-
            00:51 <@mids> shhh
-
            00:51 <@mids> not yet
-
            00:51 <@mids> 9 more minutes
-
            00:51 < Grishnav> lol
-
            00:51 < al-jabr> Tue Oct 15 22:51:23 UTC 2002
-
            00:51  * Robert zips his lip.
-
            00:51 < al-jabr> lalala
-
            00:53 -!- geully is now known as Geully
-
            01:00 <@mids> Tue Oct 15 23:00:02 UTC 2002
-
            01:00 <@mids> welcome to the n-th public IIP meeting
-
            01:00 <@mids> logfiles are on http://mids.student.utwente.nl/~mids/iip/
-
            01:00 < nop> hehe
-
            01:00 <@mids> oh, 15th
-
            01:00 < nop> 15th
-
            01:00 < nop> yes
-
            01:00 <@mids> agenda for today:
-
            01:01 <@mids> - new IIP developer
-
            01:01 <@mids> - IIP logo contest
-
            01:01 <@mids> - bug fixes
-
            01:01 <@mids> - question rounds
-
            01:01 <@mids> ,
-
            01:01 <@mids> .
-
            01:01 < nop> ok
-
            01:02 < nop> welcome back all
-
            01:02 < nop> to another round of meetings ;)
-
            01:02 < nop> for all that work in a corporate office
-
            01:02 < nop> you have permission to sleep
-
            01:02 < nop> ok
-
            01:02 < nop> new IIP developer
-
            01:02 -!- mode/#iip-dev [+o nop] by mids
-
            01:02 <@nop> and is a talented and quick learning C programmer
-
            01:02 -!- mode/#iip-dev [+o UserX] by mids
-
            01:02 <@nop> and has already added some patches and some grunt work that was needed to the code
-
            01:03 <@mids> hurray!
-
            01:03 <@nop> we are glad to have him
-
            01:03 <@nop> and we feel that he will be an essential part of the team
-
            01:03  * al-jabr claps
-
            01:03 <@nop> ok
-
            01:03 <@nop> next on list
-
            01:03 <@nop> IIP logo contest
-
            01:03 <@nop> any graphix designers etc
-
            01:03 <@mids> graphix? you mean graphics?
-
            01:04 < Grishnav> No, he means graphix :P
-
            01:04 < hobbs> nop: maybe. Me or my mom. She's good, and she got a tablet recently. :)
-
            01:04 <@nop> who would like to come up with a cool slogan and/or logo for invisiblenet, and IIP (yes I mean graphics) for t-shirts can submit their entries to iip@invisiblenet.net
-
            01:04 <@nop> the winner
-
            01:04 <@nop> will win a free t-shirt
-
            01:04 <@nop> black or white
-
            01:04 <@nop> of his choice
-
            01:04 <@nop> or her choice
-
            01:04 <@mids> woohoo!
-
            01:04 <@nop> and 10.00 DRAN
-
            01:04 < hobbs> nice.
-
            01:05 <@nop> this can definitely include slogans as well
-
            01:05 <@nop> so there could be two winners
-
            01:05 <@nop> if one comes up with logo
-
            01:05 -!- mode/#iip-dev [+o Chocolate] by mids
-
            01:05 <@nop> and one comes up with an awesome slogan
-
            01:05 -!- mode/#iip-dev [+o Chocolate] by Trent
-
            01:05 <@nop> but submit to iip@invisiblenet.net
-
            01:05 <@nop> and they will be reviewed
-
            01:05 <@nop> I hope that if you're not a graphics guy, that you can tell a friend
-
            01:05 <@nop> and maybe split the profits
-
            01:05 <@nop> ;)
-
            01:06 <@nop> because we would like to have cool shirts 
-
            01:06 <@nop> for the e-store
-
            01:06 <@nop> and in general
-
            01:06 <@nop> as well
-
            01:06 <@nop> for bumper stickers etc
-
            01:06 <@nop> maybe a mascot would be good too
-
            01:06 <@mids> :)
-
            01:06 <@nop> either way
-
            01:06 <@nop> do what you can
-
            01:06 <@nop> submit them
-
            01:06 <@nop> and we'll decide at the end of the month
-
            01:06 < philocs> our only mascot is satan
-
            01:06 <@nop> well
-
            01:06 <@nop> that's taken
-
            01:06 <@nop> BSD
-
            01:06 <@nop> ;)
-
            01:07 < philocs> we could make a scarier satan
-
            01:07 < hobbs> that's a DAEMON!
-
            01:07 <@nop> hehe
-
            01:07 <@Chocolate> black
-
            01:07 <@nop> ok
-
            01:07 <@nop> next
-
            01:07 <@nop> bugfixes
-
            01:07 <@Chocolate> tshirt must be black
-
            01:07 <@nop> ok
-
            01:07 <@nop> yeah
-
            01:07 <@nop> all artist must make inversed drawings
-
            01:07 <@nop> so that it caters to black or white backgrounds
-
            01:07 <@nop> and you can use color :)
-
            01:07 <@nop> oh
-
            01:07 <@nop> and the winner
-
            01:08 < nemesis> http://www.stk.com/products/50_beta/about50.cfm
-
            01:08 <@nop> will of course get full credit by having his logo on the t-shirt
-
            01:08 < nemesis> nice
-
            01:08  * al-jabr fears that this T-shirt may be hopelessly dorky
-
            01:08 <@mids> al-jabr: make a better one
-
            01:08 <@mids> okay...
-
            01:08 <@mids> next poing?
-
            01:09 <@mids> point :)
-
            01:09 <@mids> beeing: bugfixes
-
            01:09 <@mids> UserX fixed even more bugs then reported
-
            01:09 <@mids> there are still a few (possible) bugs out there..
-
            01:09 <@mids> if you found some that aren't mentioned
-
            01:09 <@mids> please tell us
-
            01:10 < al-jabr> I personally couldn't replicate the terminal bug, unless that was something in CVS
-
            01:10 <@mids> without bugreports we cant fix
-
            01:10 <@nop> neither could i
-
            01:10 <@mids> al-jabr: I have had it in the past; but couldn't repeat
-
            01:10 <@mids> I'll ask Jeekay for more details
-
            01:10 < philocs> where do I find list of outstanding bugs?
-
            01:11 <@nop> well everyone is encouraged to use the sourceforge bug tracker
-
            01:11 <@nop> but most people don't
-
            01:11 <@nop> ;)
-
            01:11 < philocs> bug tracker is good
-
            01:11 <@nop> we should probably link to that on our main site
-
            01:11 <@mids> http://www.sourceforge.net/projects/invisibleip/
-
            01:11 <@nop> for a bug submital
-
            01:11 < firegod> too bad it doesnt have an IRC frontend (:
-
            01:11 <@mids> most bugs are mailed to the iip-dev mailinglist though
-
            01:11 < philocs> ok I just subscribed yesterday
-
            01:11 <@mids> cool
-
            01:12 < nemesis> cause the logo, whate resolution? and dpi ?
-
            01:13 <@nop> any one knowing graphix have a suggestion for resolution and dpi?
-
            01:13 < firegod> start big
-
            01:13 < firegod> it can be resized
-
            01:13 <@nop> ok
-
            01:13 <@nop> kewl
-
            01:13 < firegod> down if needed
-
            01:13 < nemesis> -e
-
            01:13 < firegod> it is much more difficult going the other way (:
-
            01:13 < nemesis> hehe
-
            01:13 < nemesis> firegod
-
            01:13 < nemesis> something
-
            01:14 < hobbs> nop: would you be interested in having it in a vector graphics format, if that just happens to be how it's done?
-
            01:14 < firegod> always good to have high res masters
-
            01:14 < nemesis> 10 megapixels
-
            01:14 <@nop> svg?
-
            01:14 < nemesis> 72dpi
-
            01:14 < hobbs> (not that I even own a vector program, but somebody might care)
-
            01:14 < nemesis> or 1000 ?
-
            01:14 < nemesis> ;)
-
            01:14 < nemesis> very dificult
-
            01:14 < nemesis> +f
-
            01:15 < firegod> sure, if they are creative..
-
            01:15 < firegod> but svg isnt widly used just yet
-
            01:15 < al-jabr> Question:  I'm patching IIP to use /dev/random.  Would you be interested in incorporating this?  I'm doing it #ifdef linux for until I or someone configurifies the source.
-
            01:15 < firegod> so standard raster formats would be more usable atm
-
            01:15 < firegod> al-jabr: finish the patch and submit it to the mailing list
-
            01:15 <@nop> al-jar
-
            01:15 < al-jabr> okay
-
            01:15 < hobbs> al-jabr: I'd suggest making it #ifdef SOME_FLAG_THAT_CAN_GO_IN_MAKEFILE
-
            01:15 < al-jabr> yeah
-
            01:16 < al-jabr> will do
-
            01:16 < hobbs> (and have a well-commented DFLAGS line in Makefile)
-
            01:16 <@nop> yarrow is a very good prng
-
            01:16 <@nop> it's known to be secure
-
            01:16 <@nop> and we have done a test with our randomness via chi-square
-
            01:16 < al-jabr> nop: I believe yarrow would be redundard when we have /dev/urandom
-
            01:16 <@nop> and it got 25% which is good 
-
            01:16 <@nop> yes, but yarrow is portable
-
            01:16 <@nop> and known to be stronger
-
            01:16 <@mids> al-jabr: the problem is that not all operating systems have a good implementation for /dev/random
-
            01:16 < firegod> not at all
-
            01:17 <@nop> I would rather rely on what a cryptography expert developed
-
            01:17 <@nop> then the /dev/random on the machines
-
            01:17 < hobbs> true. A -DUSE_DEV_RANDOM might end up being useful, or it might just hurt a lot of people who don't know what they're doing.
-
            01:17 <@mids> otoh, giving the more modular future of IIP, maybe several alternatives could be an option
-
            01:17 < hobbs> and not the best odds on the first. :)
-
            01:17 <@nop> yes
-
            01:17 <@nop> and we do plan to add more entropy in the future
-
            01:18 < al-jabr> Well, linux /dev/random and /dev/urandom are some of the most scrutinized crypto out there... I'm mostly thinking of that because it's a very good entropy pool that's out there on very many machines running IIP
-
            01:18 <@nop> to increase this
-
            01:18 < firegod> general question: with iip2 are we going to have more feedback from the proxy?
-
            01:18 < al-jabr> you wouldn't have to go querying the user for entropy.
-
            01:18 <@nop> yes firegod
-
            01:18 <@nop> well you usually don't
-
            01:18 <@nop> but it's definitely added plus
-
            01:18 <@nop> if there isn't enough
-
            01:18 <@nop> it will query
-
            01:19 <@nop> and we will probably look into adding a form of /dev/random entropy very soon
-
            01:19 < hobbs> does linux /dev/random support O_NONBLOCK ?
-
            01:19 <@nop> because we intend on really strengthening the pool
-
            01:19 <@nop> I'm sure it does hobbs
-
            01:19 <@nop> /dev/random let's you select your pool size
-
            01:19 < hobbs> nop: yeah, but there's a softlimit, and a hardlimit in the kernel, and the hardlimit isn't that big.
-
            01:19 <@nop> al-jabr it would be best to hold off
-
            01:19 < al-jabr> nop: personally I'd trust linux more, which uses SHA1 and uses all kinds of hardware sources of entropy, than a newbie who might just go entering 'aaaaaaaaaa...'  but anyway it's only an option
-
            01:20 <@nop> al-jabr
-
            01:20 < al-jabr> ok
-
            01:20 <@nop> thats not all the entropy
-
            01:20 <@nop> there is more
-
            01:20 <@nop> there are network timings, and dh calculation timings as well
-
            01:20 < al-jabr> but it only has access to user-mode entropy
-
            01:20 <@nop> and we plan to add more
-
            01:20 < al-jabr> why reinvent the wheel.   i recommend using /dev/random and for those who don't have it, EGD.
-
            01:20 <@mids> nop: would it harm to give al-jabr a try, and maybe use it as plugin for entropy?
-
            01:20 < al-jabr> since the GPG and linux people are doing it
-
            01:21 <@mids> nop: alww
-
            01:21 < al-jabr> why don't we concentrate on doing what we do best?
-
            01:21 <@nop> that's fine
-
            01:21 <@mids> nop: always good to have alternatives around
-
            01:21 <@nop> if you want to submit a patch
-
            01:21 <@nop> please do
-
            01:21 <@nop> I'm not against it
-
            01:21 <@nop> and we definitely want to add more entropy
-
            01:21 < philocs> is the darwin /dev/random good? is it the same one in linux or openbsd?
-
            01:21 <@nop> so please submit it to iip-dev when you've added it
-
            01:21 < firegod> thats what mailing lists are for, people can digest it better
-
            01:22 < al-jabr> okay, will do.
-
            01:22 <@nop> thnx
-
            01:22 <@nop> is that all?
-
            01:22 <@nop> no more questions?
-
            01:22 <@mids> hehe
-
            01:22 <@nop> or suggestions
-
            01:22 <@nop> or complaints
-
            01:22 < nemesis> hm..
-
            01:22 < philocs> I have a dumb newbie question ...
-
            01:22 <@nop> sure
-
            01:22 < firegod> well. release dates?
-
            01:22 < nemesis> cache in the nodes
-
            01:22 <@mids> sjoet
-
            01:22 <@nop> oh oh on
-
            01:22 <@nop> that wasn't on the list
-
            01:22 <@nop> but
-
            01:23 <@nop> we are at this time working on a short term todo list
-
            01:23 <@nop> that will be publicized
-
            01:23 < philocs> if someone hacks a relay to log, does that mean they can see the trafic for private channels that go through it?
-
            01:23 <@nop> no
-
            01:23 <@mids> philocs: all traffic is encrypted node-node and end-end
-
            01:23 < philocs> ok, so you can only get the cleartext at the server, right?
-
            01:23 < firegod> but not contextually withing IRC
-
            01:23 <@nop> right
-
            01:24 < firegod> right
-
            01:24 < firegod> and the client
-
            01:24 <@mids> philocs: correct
-
            01:24 <@nop> yes
-
            01:24 < philocs> good
-
            01:24 < firegod> how far are you from encrypted channels?
-
            01:24 < hobbs> and the client -- well, can only see stuff that's actually sent to it.
-
            01:24 <@mids> firegod: nop is working on a roadmap and syncing it with the developers (if I understood well)
-
            01:24 < nemesis> add an multicast option for filetransfers, when one user, will send the same file to some multiple clients
-
            01:24 < hobbs> which means, if you don't even know that a channel exists, then you can't (intentionally or accidentally) snoop it.
-
            01:24 <@nop> firegod it will be done when we decentralize
-
            01:24 <@nop> which is our next goal
-
            01:25 <@nop> after 1.1 stable
-
            01:25 < nemesis> that the nodes between the nodes cache it
-
            01:25 < firegod> okay. roadmap.
-
            01:25 < hobbs> nemesis: actually.... that's worth thinking about -- talk to chocolate. :)
-
            01:25 < philocs> is there an advantage to having "channel key encryption" before decentralization?
-
            01:25 <@mids> nemesis: well, filetransfer isnt implemented in IIP itself anyway
-
            01:25 < nemesis> lol
-
            01:25 < firegod> hobbs: well, knowing about a channel is easy
-
            01:25 <@mids> nemesis: it CAN do multicast, just send it to a channel :)
-
            01:25 < hobbs> nemesis: it should be possible to add a hack to fileserv to have it use a channel, and then anyone who wants to receive just joins. :)
-
            01:25 < hobbs> firegod: oh, is it?
-
            01:25 < nemesis> what can you do with an anonymous network
-
            01:26 < nemesis> when you can share code?
-
            01:26 < nemesis> whats about some c code?
-
            01:26 < firegod> multicast is a problem due to not spectacular widespread support..
-
            01:26 <@mids> philocs: yes, I'd think so... less trust needed on the server
-
            01:26 < nemesis> when the complet internet are banned for open source?
-
            01:26 < hobbs> firegod: not multicast IP, just "multicast" :)
-
            01:26 < firegod> hobbs: re fileserv channel: that gives you encrypted channels btw (:
-
            01:26 < nemesis> how you can share this information?
-
            01:26 < hobbs> firegod: oh, how's that?
-
            01:27 < nemesis> <hobbs> nemesis: it should be possible to add a hack to fileserv to have it use a channel, and then anyone who wants to receive just joins. :)
-
            01:27 < firegod> hobbs: sure, if you join IIP at all it is simple to /list the channels
-
            01:27 < nemesis> not a hack
-
            01:27 < philocs> I might start thinking about some 'channel key encryption'. it doesn't seem like it would be terribly complicated thing to me, just keep private keys in some directory maybe
-
            01:27 < nemesis> built in
-
            01:27 < nemesis> and an "server node" option
-
            01:27 < nemesis> to allow that
-
            01:27 < nemesis> or not
-
            01:27 <@mids> philocs: you could implement it client side...
-
            01:27 < hobbs> nemesis: okay, I'm just behind the times. I haven't worked on fileserv for... months
-
            01:27 < nemesis> and an option for the cache size for it
-
            01:27 <@mids> philocs: look at the blowfish.pl scripts for irssi and xchat
-
            01:27 < firegod> philocs: and perl plugins on clients
-
            01:27 <@mids> s/blowfish/blowjob/
-
            01:28 < philocs> mids: would it make sense to implement it in the client side of isproxy?
-
            01:28 <@mids> nemesis: caching wouldnt make much sense when everything goes still through the central ircd
-
            01:28 < philocs> that way it would work with all clients
-
            01:28 < nemesis> <mids> nemesis: caching wouldnt make much sense when everything goes still through the central ircd
-
            01:28 <@mids> philocs: maybe; but that would require the 'vircd'
-
            01:28 < nemesis> i think there are planned to be an p2p network?
-
            01:28 < nemesis> and then theres no central hub
-
            01:28 <@mids> nemesis: for IIP 2
-
            01:29 < nemesis> only some nodes
-
            01:29 < nemesis> where cache the datas
-
            01:29 <@mids> nemesis: but that is long term; first IIP 1.2
-
            01:29 < philocs> nemesis: I think you want freenet maybe
-
            01:29 < nemesis> no
-
            01:29 < philocs> p2p file transfers with caching
-
            01:29 < nemesis> only an option to share some public files
-
            01:29 < nemesis> or larger text
-
            01:29 < philocs> thats what freenet does
-
            01:29 < firegod> any merging of namespace possible between freenet and iip?
-
            01:29 < nemesis> that you don'*t copy it line for line in the channel /query
-
            01:29 < hobbs> what sits on top of the IIPv2 network could be a lot of interesting things -- but that's a while off. :)
-
            01:29 <@mids> nemesis: first we would need decentralized routing...
-
            01:30 < nemesis> k
-
            01:30 < firegod> every isproxy was a freenet node?
-
            01:30 < nemesis> but don't forget it ;)
-
            01:30 < philocs> I don't think it makes sense to cannabalize freenet ...
-
            01:30 <@mids> nemesis: once we have that; ask again :)
-
            01:30 < firegod> philocs: does it do the job?
-
            01:30 < nemesis> lol
-
            01:30 <@mids> philocs: giving recent freenet-shit; I'd say no, indeed it doesn't
-
            01:30 < firegod> philocs: and I like 'incorporate' a bit better
-
            01:30 < hobbs> it should be possible to write a mini-freenet on top of IIP... but it would be better to leave freenet at what it does, and take advantage of the high speed and "pushiness" of IIP to write even better things.
-
            01:30 < nemesis> in how many years? *fg*
-
            01:31 < firegod> alright (:
-
            01:31 < firegod> people do want to exchange chunks of binary data thru their messaging clients, in this case IIP
-
            01:31 < firegod> how will that be addressed?
-
            01:31 < philocs> firegod: well, I think it does the job well, and it will only get better. yes I agree that it would be better to have iip implement the freenet protocol for freenet type things rather than make something incompatible
-
            01:31 < hobbs> for example, IIPv2 should be able to support the niftiest "anonymail" anyone's ever seen (without a bot), unless I'm hallucinating. :)
-
            01:31 < nemesis> hm..
-
            01:32 < nemesis> hacker ethic
-
            01:32 < nemesis> the slogon
-
            01:32 < nemesis> for..
-
            01:32 < nemesis> miiiids!!
-
            01:32 <@mids> hobbs: IIPv2 will be so smart that it could do your math homework
-
            01:32 < hobbs> that's good, 'cause I don't do mine often enough.
-
            01:32 < philocs> speaking of which
-
            01:33 <@UserX> firegod: the intention is to do a DCC emulation using Freenet as the transport for files
-
            01:33 < Grishnav> Sorry if this has already been suggested, I've missed much of the conversation being in and out of the room, but how about some sort of API for IIP to create modules? After IIP gets completely distributed (with v2) you could have all sorts of interesting modules pop up... a file transfer mod, perhaps a freenet node mod if you only wanted one service running...
-
            01:33 < firegod> UserX: that'll work (:
-
            01:33 < philocs> UserX: I think that is the best solution
-
            01:33 < hobbs> Grishnav: that's more or less the plan, as I understand it. And if it's not, we'll beat nop with halibut until it is.
-
            01:33 < Grishnav> lol
-
            01:34 < firegod> UserX: but if IIPv2 is decenteralized, would this dcc emulation need freenet? you already can do point multipoint point transfers, you just need a session handshake for that kind of transfer
-
            01:34 < firegod> albiet dcc
-
            01:34 < nemesis> waaaaaaaaaah
-
            01:34 < philocs> plus if every iip user was running some sort of freenet implementation, that would make freenet much better
-
            01:34 < nemesis> ardvark
-
            01:34 < nemesis> grrrrrr
-
            01:34 < nemesis> where is he?
-
            01:34 < nemesis> where can speak german?
-
            01:34 < hobbs> also, it should be (more) convenient to have multiple IIPv2 networks, but I think that's a given. :)
-
            01:34 < nemesis> or known only a little bit german
-
            01:34 < firegod> philocs: thats what I'm saying (:
-
            01:34 < nemesis> and have the english hacker ethic?
-
            01:34 < firegod> whos working on IIPv2?
-
            01:35 < philocs> I need to go study for my german test soon
-
            01:35 < philocs> firegod: are you left handed or in oz or something?
-
            01:35 <@mids> hm, ppl; I got to go; keep chatting here
-
            01:35 <@mids> bbl
-
            01:35 < nemesis> hrhr
-
            01:35 < nemesis> mids!!!
-
            01:35 < firegod> philocs: nope, just a freak
-
            01:35 < nemesis> don't drunk to much ;p
-
            01:35 < nemesis> *fg*
-
            01:36 < firegod> mids is working on IIPv2 I'm sure, anyone else? UserX?
-
            01:36 < nemesis> nop
-
            01:36 <@UserX> firegod: in theory yes. but currently we want to keep IIP low bandwidth. freenet would me suited transfering large volumes of data (and better because it doesn't have a constraint of realtime routing that IIP needs)
-
            01:36 < nemesis> i think
-
            01:36 <@nop> yes
-
            01:36 < nemesis> aaaaaah
-
            01:36 < nemesis> nop
-
            01:36 < philocs> I guess what is really needed is for someone to write a C implementation of freenet ...
-
            01:36 < firegod> UserX: this is true.
-
            01:37 < firegod> UserX: or at least an opt-in on that feature
-
            01:37 <@UserX> firegod: yes i am working v2
-
            01:37 < hobbs> philocs: I agreed with that pretty heavily a few months ago, but right now I'm happy to let java fred do its thing, and settle down, before anyone clones.
-
            01:37 < hobbs> (now that it _works_, that is)
-
            01:37 < firegod> UserX: how have you solved scaling issues for resource location? ie: how do you find nodes originating #channels?
-
            01:37 < philocs> UserX: yes well thats a good reason to not make it easy for people to do 'dcc' and to encourage them to use freenet
-
            01:38 < firegod> philocs: it should just be opt-in.. people wanting to abuse their bandwidth, can go right ahead.. those on modems dont get killed (:
-
            01:38 < hobbs> UserX: would be nice to keep in mind, though, that freenet is good at pulling things, and iip is good at pushing things. :)
-
            01:38 < philocs> hobbs: well I agree, I think the java version is fine but if we are going to basically package freenet with iip somehow then eventually (and probably when freenet hits 1.0?) we will want a c implementation
-
            01:38 < firegod> philocs: those wanting freenet backed features, change a setting and BLAM it just works
-
            01:38 <@UserX> firegod: haven't worked out highly scalable system yet
-
            01:39 < firegod> hobbs: IIP is a great way of grouping freenet keys (:
-
            01:39 < hobbs> philocs: that's some pretty long thinking. :)
-
            01:39 < firegod> UserX: ah. If you havnt peaked at Circle, I encourage you to (:
-
            01:39 < firegod> I know mids said he'd played with it
-
            01:39 < philocs> hobbs: well freenet is getting more stable all the time 
-
            01:40 < youkai> yeah, i would never run freenet as long as its only java
-
            01:40 < firegod> theres a slogan for ya d-:
-
            01:40 < firegod> "getting more stable every day"
-
            01:40 < youkai> too bulky
-
            01:41 < philocs> youkai: its not too bad
-
            01:41 < youkai> plus i think its shitty to have os software that only compiles on a corp owned language
-
            01:41 < Grishnav> I don't like Java anymore than the next guy, but I certainly am a freenet fan. I'll use the java one, but only until I hear about a C implementation. :)
-
            01:42 < youkai> i mean if you guys were using the os non sun java i wouldent mind as much
-
            01:42 < youkai> ah yes
-
            01:42 < youkai> blackdown
-
            01:42 < hobbs> youkai: freenet works fine on a few flavors of non-sun java.
-
            01:42 < hobbs> blackdown has sun behind it.
-
            01:42 < youkai> you just cant win with java then :/
-
            01:42 < firegod> so?
-
            01:42 < youkai> i dont trust sun any more then i do microsoft
-
            01:43 < firegod> java is not your friend (:
-
            01:43 < Grishnav> Does anyone have a link to the souce download for Blackdown? (Their site is less than helpful)
-
            01:43 < firegod> I encourage those who are disatisfied with java, to try phthon for their scripting needs (it is NOT java)
-
            01:43 < youkai> yeah python is cool
-
            01:44 < youkai> but i dident stop running m$ operating systems just so i could let another corp in the door (sun)
-
            01:44 < hobbs> Grishnav: er. It's in "non-free" for a reason, isn't it?
-
            01:44 < philocs> you are wanting me to write freenet in python? would a python module be distributed with iip?
-
            01:44 < Grishnav> Ahh... I was under the impression is was free. my mistake.
-
            01:45 < youkai> thats the only problem i have with freenet
-
            01:45 < philocs> java is not evil, sun treats java differently than MS treats windows
-
            01:45 < hobbs> Grishnav: no. If you ask sun, it's impossible to create a free java2 implementation, and they've done a good job of making it true.
-
            01:45 < youkai> i mean java is a lot easier to code in because you dont have to worry about memory leaks and stuff as much
-
            01:45 < Grishnav> rofl
-
            01:45 < youkai> the garbage collector lets you be lazy
-
            01:45 < philocs> hobbs: why is it impossible?
-
            01:45 < Grishnav> [16:45] <youkai> i mean java is a lot easier to code in because you dont have to worry about memory leaks and stuff as much -- yeah, it's no wonder that all java apps are so goddamn memory hoggy!!
-
            01:46 < youkai> yeah thats because they need the whole jre loaded in memory with the software
-
            01:46 < hobbs> philocs: because if you write anything that's java2, and claims to be "java", then sun will destroy you. :)
-
            01:46 < philocs> hobbs: yes but you can make java, just don't call it 'java'
-
            01:46 < hobbs> er... without obtaining the appropriate license and signing the appropriate agreements first, that is. :)
-
            01:46 < Grishnav> call it coffee
-
            01:46 < philocs> kaffe
-
            01:46 < Grishnav> hehe
-
            01:46 < Grishnav> yeah
-
            01:47 < Grishnav> I've played with Kaffe
-
            01:47 < hobbs> philocs: true. But nobody's done it.
-
            01:47 < Grishnav> not quite mature enough yet, but getting there
-
            01:47 < philocs> hobbs: uh yes, the FSF has done it
-
            01:47 < hobbs> philocs: oh?
-
            01:47 < philocs> yes
-
            01:47 < youkai> but seriously i think java is right up there with VB
-
            01:47 < philocs> Kaffe
-
            01:47 < hobbs> philocs: Kaffe is not java2.
-
            01:47 < youkai> its for lazy programmers
-
            01:47 < youkai> who dont mind being owned by a corp
-
            01:47 < philocs> hobbs: but there is no reason it could not implement java2
-
            01:47 < hobbs> philocs: except for the fact that it doesn't.
-
            01:47 < philocs> plus gccj or whatever its called
-
            01:48 < hobbs> er...
-
            01:48 < youkai> the other thing is java2 is huge, and they have a gigantic team of programmers working on it all the time
-
            01:48 < hobbs> yeah. gcj/gij are also nice.
-
            01:48 < firegod> not to interupt, but java wars work out better in apropriatly named channels (:
-
            01:48 < philocs> hobbs: but its not a legal issue, the java spec is an open standard, the java name is not
-
            01:48 < youkai> gcj?
-
            01:48 < philocs> youkai: gcc that compiles java code
-
            01:48 < youkai> huh
-
            01:49 < youkai> to binary or does it still need a jre
-
            01:49 < philocs> binary I believe
-
            01:49 < hobbs> philocs: that's a pretty heavy restriction, though.
-
            01:49 < hobbs> You can't say: this is java, this is compatible with java, or this smells like java.
-
            01:49 < philocs> hobbs: well I don't think so. You can make the claim that 'this software is not java, but you will probably find that it works the same'
-
            01:50 < philocs> which most people would understand
-
            01:50 < hobbs> probably.
-
            01:50 < youkai> anyway, why rewrite java when you could just use c++
-
            01:50 < youkai> its almost the same language
-
            01:51 < philocs> arg, I would rather use java over c++
-
            01:51 < philocs> but I'm not getting into that
-
            01:51 < philocs> anyway, I forgot where this horrible diatribe started
-
            01:51 < hobbs> youkai: not really. c++ doesn't force you to use OO crap when it's completely inappropriate, like java does. :)
-
            01:51 < firegod> round and round we go, where we stop nobody knows
-
            01:51 < firegod> philocs: exactly
-
            01:51 < philocs> ok, so in isproxy, is there like a client side and a node side?
-
            01:52 < firegod> philocs: you know how many times I've seen this exact same 'argument' ? (:
-
            01:52 < youkai> hobbs: hah
-
            01:52 < firegod> philocs: there are relays, and proxys and 'servers'
-
            01:52 < firegod> as I see it
-
            01:52 <@UserX> philocs: can you clarify your question?
-
            01:52 < philocs> I mean, would it make sense to put channel key encryption in isproxy, the part that actually talks to the irc client on 6667?
-
            01:52 < hobbs> philocs: sorta. there are nodes, and there are nodes. :)
-
            01:52 < firegod> philocs: dont forget you have multiple clients for each isproxy
-
            01:53 < hobbs> and nodes 1) talk to clients 2) talk to nodes 3) (one of them) talks to the server.
-
            01:53 < philocs> firegod: really? I've never been able to see this behavior, actually maybe its just my configuration
-
            01:53 < firegod> (:
-
            01:54 < philocs> but anyway, does my question make sense?
-
            01:54 < youkai> i just came here to beg you guys not to write the next ver of iip in java :D
-
            01:54 < firegod> which question d-:
-
            01:54 < firegod> youkai: i think thats a given
-
            01:54 <@UserX> philocs: currently IIP 1.x is essentially a tunnel. having the client implement channel encryption would require a lot of work to do. and would become redunant when v2 gets done
-
            01:54 < youkai> also if theres freenet people around, a c++ ver would be nice
-
            01:55 < firegod> UserX: how about isproxy functioning as an http tunnel?
-
            01:55 < firegod> UserX: IIPv2 as well?
-
            01:55 < nemesis> <youkai> i just came here to beg you guys not to write the next ver of iip in java :D
-
            01:55 < nemesis> noooooo
-
            01:56 < philocs> I'm thinking that you could have it so that there ways like a 'keys/' directory and then you could have in that 'channel.key' or something and then just run blowfish or whatever on what goes in and out of that channel, understand?
-
            01:56 < nemesis> native code are the best thing
-
            01:56 < philocs> and fuck c++, I'll take java over c++ anyday
-
            01:56 < philocs> but I also think that c is nice
-
            01:57 <@UserX> firegod: 1.x could be used to tunnel to a single fixed HTTP server
-
            01:57 < firegod> okay, enough language wars please?
-
            01:57 < nemesis> m$ sponsored his .net campain, and will place his IL on the front
-
            01:57 < youkai> k :D
-
            01:57 < firegod> User: hrmm
-
            01:57 < nemesis> you can controll the compiller
-
            01:57 < philocs> youkai keeps brining it up, if he likes c++ so much, he should marry it 
-
            01:57 < nemesis> thats the different
-
            01:57 < firegod> oh jebus
-
            01:57 < youkai> heh philocs: if you like java so much you should go work for sun
-
            01:57 < nemesis> can't
-
            01:58 < philocs> UserX: would that make sense or is it better to wait for next version to do that?
-
            02:00 < youkai> UserX: thats a good idea
-
            02:00 <@UserX> philocs: to do that with 1.x network would require giving nodes the intelligence to read and parse recompose IRC client messages/commands
-
            02:01 < philocs> oh I see
-
            02:01 < nemesis> <UserX> philocs: to do that with 1.x network would require giving nodes the intelligence to read and parse recompose IRC client messages/commands
-
            02:01 < nemesis> xml ;)
-
            02:01 <@UserX> it's possible but would take a fair amount of effort which i want to put into v2
-
            02:01 < nemesis> very flexible
-
            02:01 < philocs> I understand
-
            02:02 < philocs> later
-
            02:11 < logger> logging ended
-
            --- Log closed Wed Oct 16 02:11:14 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting150.html b/www.i2p2/pages/meeting150.html
deleted file mode 100644
index 71d1b10a..00000000
--- a/www.i2p2/pages/meeting150.html
+++ /dev/null
@@ -1,148 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 150{% endblock %}
-{% block content %}
            I2P dev meeting, October 4, 2005
            
-
            
-
            16:16 < jrandom> 0) hi
            
-
            16:16 < jrandom> 1) 0.6.1.1
            
-
            16:16 < jrandom> 2) i2phex
            
-
            16:16 <@protokol> speaking of, whats the news on legion and i2phex
            
-
            16:16 < jrandom> 3) syndie
            
-
            16:16 < jrandom> 4) ???
            
-
            16:16 < jrandom> 0) hi
            
-
            16:16  * jrandom waves
            
-
            16:16 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-October/000939.html
            
-
            16:17 <+postman> hi
            
-
            16:17 < jrandom> might as well jump into 1) 0.6.1.1
            
-
            16:18 <+postman> ya
            
-
            16:18 < jrandom> the network has been growing in number and in usage, but things have been doing pretty well
            
-
            16:18 <+postman> .. apart from the irc servers
            
-
            16:18 < jrandom> aye, thats an interesting one
            
-
            16:19 < jrandom> (the irc servers are currently running an older rev, and we're still working on some debugging to understand exactly why things are the way they are)
            
-
            16:19 <+Ragnarok> what happened?
            
-
            16:20 < jrandom> hopefully we'll get the irc servers upgraded sooner rather than later, as there has been some good stuff lately
            
-
            16:20 < cervantes> Ragnarok: server<->server link is shakey under 1.1
            
-
            16:20 <+Ragnarok> weird
            
-
            16:20 < jrandom> 0.6.1.1, that is ;)
            
-
            16:20 <+Complication> protokol: see forum, he finally opted for a sensible approach
            
-
            16:20 <+postman> cervantes: don't mention the time travel, idiot
            
-
            16:20 < cervantes> 0.6.1.x
            
-
            16:20 <+postman> :)
            
-
            16:21 < cervantes> oop
            
-
            16:21 <+postman> jrandom: i hope i'll be able to build a test ircd this week
            
-
            16:21 <+postman> jrandom: we could link to an instance run by you or cervantes 
            
-
            16:22 < jrandom> aye, that'd be great.  we could even split off the different tunnels into different jvms, using different streaming libs and router versions, to isolate the issue further
            
-
            16:23 < jrandom> it'd be cool if we could do that before 0.6.1.2, but if not, no big deal
            
-
            16:24 < jrandom> ok, anyone else have anything for 1) 0.6.1.1?
            
-
            16:24 <+postman> jrandom: apart from that: runs like hell
            
-
            16:24 < jrandom> would that be a good hell or a bad hell?  :)
            
-
            16:24 <+postman> a hell of a hell :)
            
-
            16:25 <+Complication> Eh, managed to cause a few more errors (but those were really, really borderline stuff, router restart under a running i2phex.) Will send privately.
            
-
            16:26 < jrandom> ah cool, thanks Complication 
            
-
            16:26 <+Complication> (e.g. they probably won't hurt anyone in real life)
            
-
            16:26 < jrandom> heh never underestimate people's ability to break things :)
            
-
            16:27 < cervantes> or the ingenuity of fools in testing fool proof systems
            
-
            16:27 <+postman> yea, make something fool proof and you'll be rewarded with a new kind of fool
            
-
            16:28 < jrandom> hallelujah
            
-
            16:29 < jrandom> ok, anything else for 1), or shall we move on to 2) i2phex
            
-
            16:30 < jrandom> there has been a lot of discussion as of late, and legion has agreed to merge back the changes made into sirup's i2phex codebase.  
            
-
            16:30 <+postman> move
            
-
            16:30 < jrandom> this is quite cool, as it'll be great for us all to benefit from legion's hard work while remaining entirely open and secure
            
-
            16:31 <+Ragnarok> what did he actually do?
            
-
            16:33 < jrandom> latest changes include the addition of systray4j, striker's timeout updates, increased tunnel length defaults, some nsis and jni stuff, and a few other changes
            
-
            16:33 <+Ragnarok> hm, ok
            
-
            16:33 <+postman> jrandom: so there're a bunch of improvements - those will be kept tho?
            
-
            16:34 < jrandom> certainly, all good stuff will be integrated into i2phex
            
-
            16:34 < jrandom> there are a few things i'm not so sure of, but that'll be discussed with legion outside of the meeting ;)
            
-
            16:35 <+postman> k
            
-
            16:36 < jrandom> ok, anyone else have anything for 2) i2phex?  or shall we move on to 3) syndie?
            
-
            16:37  * postman prepares his syndie500 franchising goods
            
-
            16:37 < jrandom> heh
            
-
            16:37 < jrandom> ok, Ragnarok, wanna give us the rundown on the latest?
            
-
            16:37 <+Ragnarok> hm, ok
            
-
            16:38 <+Ragnarok> Syndie will now get new posts from an archive automatically.  
            
-
            16:38 <+Ragnarok> you can set which archives you want to get updates from, and set how often you do it in the syndie config file
            
-
            16:39 <+Ragnarok> more details about that are in history.txt
            
-
            16:39 <+Ragnarok> it needs a ui, but otherwise it's essentially done
            
-
            16:39 <+Ragnarok> 'course, no one seems to be posting anything recently, so maybe it's not that useful :)
            
-
            16:40 < jrandom> [insert field of dreams quote here]
            
-
            16:40 < jrandom> thanks Ragnarok, this has been an oft requested feature
            
-
            16:41 <+Ragnarok> cool
            
-
            16:41 <+Ragnarok> happy to do it, wasn't really that much work
            
-
            16:42 <+Ragnarok> mostly just scratching my own itch :)
            
-
            16:42 < cervantes> oh wasn't it? or forget it then :P
            
-
            16:42 < cervantes> or=oh
            
-
            16:42 <+postman> (hush, the genius must not admit that it needs to work hard too)
            
-
            16:42 <+Ragnarok> hehe
            
-
            16:43 <+Ragnarok> anyway, if anyone's got bug reports/feature requests/boos/cheers/etc. let me know
            
-
            16:43 < jrandom> (cheers!)
            
-
            16:43 <+Ragnarok> next thing I'm thinking of is auto matically importing petnames seen in posts into the routers petname db, but that looks like it could be complicated...
            
-
            16:44 <+Ragnarok> but, it would essentially allow syndie to replace addressbook
            
-
            16:44 < jrandom> that would be Very Cool
            
-
            16:44 <+nickless_head> yeah :)
            
-
            16:45 <+Ragnarok> I just have to figure out how to get a list of petnames out of the archive
            
-
            16:45 <+Ragnarok> everything else is trivial
            
-
            16:45 <+nickless_head> ragnarok: are your  changes already in cvs? (too lazy to read the whole discussion) :)
            
-
            16:45 <+Ragnarok> yeah
            
-
            16:45 <+nickless_head> :happy:
            
-
            16:45  * nickless_head considers cvs update
            
-
            16:45 <+Ragnarok> have been since yesterday
            
-
            16:45 <+nickless_head> nah, probably better to wait for the next release
            
-
            16:45 < jrandom> perhaps get the petnames whenever they're rendered, exposed via the HTMLRenderer (in the addressReceived)
            
-
            16:46 <+Ragnarok> ok, I'll look into that
            
-
            16:46 < jrandom> cool, thanks Ragnarok 
            
-
            16:47 <+Ragnarok> well, that's it from me, unless there's questions
            
-
            16:49 < jrandom> wr0d.  ok, jumping on to 4) ??? 
            
-
            16:49 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            16:49 < cervantes> aye
            
-
            16:49  * nickless_head looks at cervantes interestedly
            
-
            16:50 <+fox> <mancom> is there anything new on Q or feedspace?
            
-
            16:50 <+postman> nickless_head: hey, he's mine - don't dare to stare at him like that :)
            
-
            16:50 <+nickless_head> I'm not staring at him .. I'm looking at him interestedly.
            
-
            16:51 < cervantes> After some deliberation I've revived the "Forum User of the Month" spot - and this month it deservedly has gone to Complication for outstanding forum contributions
            
-
            16:51 <+nickless_head> congratulations complication!
            
-
            16:51 <+postman> kudos :)
            
-
            16:51 < cervantes> so he gets an avatar (whether he likes it or not) :P
            
-
            16:51 <+Complication> Heh, I hope my blunders have been less outstanding. :O :D
            
-
            16:52 <@protokol> oh yeah
            
-
            16:52 < jrandom> w00t!  thanks Complication 
            
-
            16:52 < cervantes> (which is active now)
            
-
            16:52 <@protokol> hows that Yellow Submarine i2phex test going
            
-
            16:52 <@protokol> any notable speeds or lack thereof?
            
-
            16:52 <+Complication> It's going.
            
-
            16:52 < jrandom> mancom: nothing new regarding Q or feedspace
            
-
            16:53 <+Complication> No hyperfast speeds, but a guaranteed good-enough speed, I'd say.
            
-
            16:53 < jrandom> protokol: last i heard was 10-20KBps, but thats just stuff on the forum
            
-
            16:53 <@protokol> im downloading it right now
            
-
            16:53  * nickless_head understands what postman implied
            
-
            16:53  * nickless_head blushes
            
-
            16:53 <+Complication> (also: I re-read part of the tech intro, and couldn't find flaw with the network comparisons. I think they're good enough.)
            
-
            16:54 <+postman> nickless_head: LOL (sorry)
            
-
            16:54  * Complication looks at the avatar and grins :D
            
-
            16:54 <+nickless_head> postman: *GG* (no problem)
            
-
            16:54 < cat-a-puss> Has anything been done in an effort to get "Amazon honor system" as an alternate method of collecting donations?
            
-
            16:54 <+Complication> Spot on. :P
            
-
            16:55 <@protokol> cat-a-puss: what do you mean?
            
-
            16:55 < jrandom> not yet cat-a-puss, haven't seen wilde around
            
-
            16:55 < jrandom> woah, hey phedy
            
-
            16:55 < phedy> Hi jrandom.
            
-
            16:55 < cat-a-puss> protokol: it's like pay-pal, except you can use an account you have with amazon.com to make payment
            
-
            16:56 < jrandom> Complication: thanks re: the comparisons.  there are a few cleanups left, but its coming along
            
-
            16:56 <@protokol> weak
            
-
            16:56 <+Complication> (not that I know Tor or Freenet in decent degree, although I've used both)
            
-
            16:57  * cat-a-puss is thinking of creating a bounty for helping finish the distributed search engine. 
            
-
            16:57 < jrandom> (before putting the doc out on the normal website i'll run it by those folks for comment)
            
-
            16:58 < cervantes> Complication: it's an art installation on a roundabout in London that causes havoc with the traffic ;-)
            
-
            16:59 < jrandom> cat-a-puss: i've got to work out some other financial stuff soon anyway, so shall let you know asap
            
-
            16:59 < jrandom> ok, anyone else have anything to bring up for the meeting?
            
-
            16:59 < cat-a-puss> oh if we want documents translated to some other languages before 1.0, I may know people who could help with Spanish and Chinese.
            
-
            16:59 < cat-a-puss> ok
            
-
            16:59 < jrandom> kickass, that'd be great
            
-
            17:00 <+Complication> cervantes: thanks for telling, I wasn't aware where such an, umm... effect occurred :D
            
-
            17:00 < jrandom> there's a draft tech intro floating around in cvs, and we'll eventually want whatever our website redesign turns out to contain to be translated
            
-
            17:03  * nickless_head goes to sleep
            
-
            17:03 < jrandom> i suppose i should grab the baffer...
            
-
            17:03 < jrandom> if there's nothing else
            
-
            17:03  * jrandom winds up 
            
-
            17:03  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting151.html b/www.i2p2/pages/meeting151.html
deleted file mode 100644
index acec0ec4..00000000
--- a/www.i2p2/pages/meeting151.html
+++ /dev/null
@@ -1,240 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 151{% endblock %}
-{% block content %}
            I2P dev meeting, October 11, 2005
            
-
            
-
            16:29 < jrandom> 0) hi
            
-
            16:29 < jrandom> 1) 0.6.1.2
            
-
            16:29 < jrandom> 2) I2PTunnelIRCClient
            
-
            16:29 < jrandom> 3) Syndie
            
-
            16:29 < jrandom> 4) I2Phex
            
-
            16:29 < jrandom> 5) Stego and darknets (re: flamewar)
            
-
            16:29 < jrandom> 5) ???
            
-
            16:29 < jrandom> 0) hi
            
-
            16:29 <@cervantes> (6)
            
-
            16:29 <+postman> you mean 6)?
            
-
            16:29 < jrandom> yeah, i can't count ;)
            
-
            16:30  * postman high-fives cervantes 
            
-
            16:30 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/000990.html
            
-
            16:30 < wiht> Questions should be item 6.
            
-
            16:30 < jrandom> since i'm 30 minutes late, y'all have already read through those notes, I'm sure, so lets get this underway ;)
            
-
            16:31 < jrandom> 1) 0.6.1.2
            
-
            16:31 <@cervantes> 6) Discuss jrandom's roommate's poor judgement in timing
            
-
            16:31 < jrandom> *cough* ;)
            
-
            16:31 < jrandom> ok, as mentioned in the email, the 0.6.1.2 release seems to be doing pretty well
            
-
            16:32 < jrandom> we've found the bug that had kept the irc servers back on an older build, and they're now up to date too (w00t!)
            
-
            16:32 <+postman> :)
            
-
            16:32 < wiht> Speaking of that, in the netDB on the router console, would it be possible to list the table with routers and their versions at the top of the page?
            
-
            16:33 < jrandom> the number of routers per version, right?  sure, that could be done pretty easy, maybe integrate it into the peers.jsp table (showing per-peer version) and a new table at the bottom?
            
-
            16:34 < jrandom> its kind of nice seeing 9 versions playing well together, though of course newer ones work best
            
-
            16:35 < jrandom> ok, anyone else have something to bring up regarding 1) 0.6.1.2?
            
-
            16:35 <+postman> one of my routers shows 1080 known
            
-
            16:35 < jrandom> zounds
            
-
            16:35 <+postman> i think this is a bit off track?
            
-
            16:35 < jrandom> is that on 0.6.1.2?
            
-
            16:35 <+postman> yeah, think so
            
-
            16:36 < jrandom> hmm, yeah, thats a... bit high.  i'm seeing about half that many right now
            
-
            16:36 <+Complication> Sustainably 400-ish here
            
-
            16:37 <+bar> same here
            
-
            16:37 < wiht> I see 260 known routers.
            
-
            16:37 < jrandom> postman: perhaps we can dig into whats going on in that router after the meeting (could you tar.bz2 me netDb/routerInfo-*?)
            
-
            16:38 <+postman> jrandom: yeah thanks
            
-
            16:38 < jrandom> gracias
            
-
            16:38 < jrandom> yeah, not everyone will see every netDb reference, so thats normal for there to be fluctuation
            
-
            16:40 < jrandom> ok, if there's nothing else on 1) 0.6.1.2, lets swing on over to 2) I2PTunnelIRCClient
            
-
            16:40 <@cervantes> nice one dust
            
-
            16:40 < jrandom> as mentioned in the email, we've got a new IRC-protocol-specific filter available in CVS, and it should be rolled out as the default in the next rev
            
-
            16:41 <+postman> cool
            
-
            16:41 < jrandom> yeah, this is very cool, people have been asking for something like it for ages
            
-
            16:41 <+Myo9> Jrandom, you have become more open recently, we have learned about your ex, and now your room mate, etc. Do recall: http://www.navysecurity.navy.mil/st031204.jpg
            
-
            16:41 < jrandom> *cough*
            
-
            16:42 < dust> if you wish to see what your client send you can add net.i2p.i2ptunnel.I2PTunnelIRCClient=INFO and then look at the logs to see it all
            
-
            16:43 < dust> i've tested some clients but there are many..
            
-
            16:43 < jrandom> yeah, i've been watching it for a lil bit, but the filtering seems sound
            
-
            16:44 < jrandom> there are some neat things we may be able to do in the future too - e.g. PING/PONG locally, to cut down on network activity
            
-
            16:44 <+Complication> dust: thanks for the "info" :)
            
-
            16:44 <+bar> awsome dust, thanks a lot
            
-
            16:44 < wiht> Does this mean we don't need to set up an extra IRC tunnel?
            
-
            16:44 < jrandom> wiht: no, you'll need an irc tunnel, but it can replace the one you use already
            
-
            16:45 <+Complication> wiht: just worry less about our IRC client giving away our ass
            
-
            16:45 < jrandom> postman/cervantes: any thoughts on increasing or removing the server ping/pong timeouts?  
            
-
            16:45 < wiht> That explains it, thanks.
            
-
            16:46 <+postman> mmh, i would not remove them, my client completely freaked when i played around with it
            
-
            16:46 < jrandom> postman: well, i'm thinking if it responded to them locally, so the client would get a really, really fast PING/PONG
            
-
            16:46 <@cervantes> postman: the proxy could respond to pings
            
-
            16:46 < jrandom> (but the ping/pong wouldn't need to go over the network)
            
-
            16:47 < jrandom> i don't know the impact, but it may be worth looking into.
            
-
            16:47 <@cervantes> but I'm not sure how the servers would react, you might end up with a bunch of zombie clients
            
-
            16:47 <+postman> jrandom: well
            
-
            16:47 < jrandom> well, the streaming lib's keepalive should handle that
            
-
            16:47  * Complication has occasionally experienced zombification
            
-
            16:47 < jrandom> Complication: recently?
            
-
            16:47 <+postman> jrandom: if the proxy pings for the client, the proxy must ping/pong to the client as well
            
-
            16:48 <+Complication> A week ago, I think.
            
-
            16:48 < jrandom> postman: a PING from the client to the proxy would have the proxy respond directly to the client with a PONG without sending anything over i2p
            
-
            16:48 <+Complication> But my "copy" was dropped eventually.
            
-
            16:48 <@cervantes> jrandom: the connection would be held open...the servers would need to lower their threshold for deciding at what point a client is stale and need ejecting
            
-
            16:48 < jrandom> Complication: ah, the irc servers weren't up to date back then, shouldn't happen anymore
            
-
            16:49 <+Complication> Without me using "ghost". Recent uses of the ghost command have been due to operating with many nodes.
            
-
            16:49 <+postman> jrandom: and the lag measurement?
            
-
            16:49 < jrandom> cervantes: right.  and/or if necessary, the proxy could inject an extra PING message to the server if it /needs/ one. 
            
-
            16:49 <+postman> i find it quite useful to know if i am lagged or not
            
-
            16:49 < jrandom> postman: i do too, but you can always /msg yourself
            
-
            16:50 < dust> you could perhaps reduce the number of pings
            
-
            16:50 < jrandom> it would save a substantial amount of bandwidth, since tunnel messages are 1024byte blocks, sent over 2*k+1 hops
            
-
            16:50 < jrandom> that too
            
-
            16:50 < jrandom> i don't know, just an idea.  what we have now is kick ass regardless 
            
-
            16:51 <+postman> ok, i would try to patch a testserver
            
-
            16:51 <@cervantes> perhaps we could look into reducing the number...but I think we should still send some real pings do determine if the clients are still alive
            
-
            16:51 <+postman> maybe it works
            
-
            16:51 < jrandom> seems reasonable cervantes.  i don't think it'd need any patching on the server, i hope?
            
-
            16:52 <+postman> jrandom: to deactivate maybe - but lowering the interval is conf parameter
            
-
            16:53  * postman chews on the ircd documentation ( again )
            
-
            16:53 < jrandom> cool, no rush.  just something we can look into sometime
            
-
            16:53 <@cervantes> class servers
            
-
            16:53 <@cervantes> {
            
-
            16:53 <@cervantes>     pingfreq   120;
            
-
            16:54 <@cervantes> class clients { pingfreq 90 }
            
-
            16:54 <@cervantes> that's my current config
            
-
            16:54 <+postman> cervantes: yes, i know  - the question is if it can be deactivated at all
            
-
            16:54 <@cervantes> I wouldn't deactivate them...just look into reducing them
            
-
            16:55 <+postman> ok, let's start with that
            
-
            16:55 <+postman> cervantes: how about 180 secs?
            
-
            16:56 <@cervantes> in at the deep end with 240
            
-
            16:56 <@cervantes> but perhaps we should ge tthe ircproxy side of things ready first
            
-
            16:57 <@cervantes> *discuss after meeting*
            
-
            16:57 <+postman> agreed
            
-
            16:57 < jrandom> w3rd.  ok, anything else on 2) I2PTunnelIRCClient, or shall we move on to 3) Syndie?
            
-
            16:57 <@cervantes> anything to reduce my current 40kb/sec average router traffic ;-)
            
-
            16:58 < jrandom> heh, for some reason i doubt thats all irc ;)
            
-
            16:58 < jrandom> ok, movin' on
            
-
            16:59  * cervantes hides is pony video downloads he's been leeching from jrandom all week
            
-
            16:59 <@cervantes> is=the
            
-
            16:59 <+postman> LOL
            
-
            16:59 < jrandom> as mentioned in the mail, there's some pretty cool stuff going on with syndie
            
-
            16:59 < jrandom> the cli is trivial, but dust's new Sucker looks really promising
            
-
            16:59 < jrandom> dust: wanna give us a rundown?
            
-
            17:00 < dust> oh,
            
-
            17:01 < dust> well, it uses rome for parsing the feeds and then converts it to sml, like described in jrandoms blog
            
-
            17:02 < dust> it's not what you'd call robust yet, but it's only two days old :)
            
-
            17:02 < dust> i've got some dilbert in my syndie..
            
-
            17:02 < dust> :)
            
-
            17:02 < dust> .
            
-
            17:02 < jrandom> nice
            
-
            17:03 < jrandom> ok, what are your thoughts on where its going - should we toss it into the syndie source and expose it as a cli, or keep it separate and distribute it independently, or something else?
            
-
            17:04  * dust don't know, you decide
            
-
            17:04 < dust> the less separate tools the better
            
-
            17:04 < jrandom> yeah, probably easier to bundle it all together, that way everyone knows they can use it
            
-
            17:05 < jrandom> we'd then be able to do things like integrate it into the web interface, and maybe into Ragnarok's scheduler (syndicating with other nodes and pulling from rss/atom/etc)
            
-
            17:07 < jrandom> ok, anyone have any questions/comments/concerns on 3) Syndie?
            
-
            17:07 < wiht> If you keep integrating software into I2P, it may become a bloated software package.
            
-
            17:07 < wiht> Of course, I can turn off Syndie if I am not using it.
            
-
            17:08 < jrandom> the i2p sdk 13KLOC
            
-
            17:08 < jrandom> and the i2p router is only 22KLOC
            
-
            17:08 < jrandom> but yeah, there is an impact on download times of the install
            
-
            17:09 < jrandom> if someone wanted, they could build a stripped down router with no client apps, using just the router.jar, jbigi.jar, and i2p.jar
            
-
            17:09 < wiht> Yes, I was referring to the download.
            
-
            17:09 < jrandom> (but its much more useful when there's a web interface to control it, and i2ptunnel, and the streaming lib, etc ;)
            
-
            17:11 < jrandom> smeghead was working on a distribution system (like emerge, for java), and there's the jpackage folks too
            
-
            17:11 < jrandom> if someone wants to look into a seamless and reliable way to manage the apps without bundling, it'd be pretty cool
            
-
            17:12 < jrandom> ok, if there's nothing else on that, lets jump on over to 4) I2Phex
            
-
            17:13 < jrandom> I don't really have much to add beyond whats in the status notes
            
-
            17:13 < jrandom> redzara: you around?
            
-
            17:13 <+redzara> yes i'm
            
-
            17:13 <+redzara> I'm already working on the next version, while waiting for the meeting with Gregor.
            
-
            17:13 < jrandom> ah great
            
-
            17:13 <+redzara> Work, for the moment, primarily consists in identifying the differences and the needs related to the use of I2P such as for example tcp/udp vs i2p, management of the parameters specific to I2P (and management of the update of these same parameters at the time of the next versions, ...) port of GWebCache to I2P, use RSS or not, use push or not... 
            
-
            17:14 <+redzara> I have much documentation and code to read
            
-
            17:15 < jrandom> wow, yeah, sounds like a lot.  let me know if you've got any questions regarding i2p integration, or if you just want someone to bounce ideas off
            
-
            17:16 < jrandom> getting the I2Phex part into a plugin for the mainline Phex would be really kickass
            
-
            17:17 < jrandom> ok, anyone else have anything for 4) I2Phex?
            
-
            17:18 <+redzara> I would need certainly assistance for the petname part
            
-
            17:19 <+redzara> and maybe too for fine tunning tunnels's parameters
            
-
            17:19 < jrandom> cool, the naming is pretty easy - at a basic level, you could even get by without using names at all (this is how I2Phex does it now)
            
-
            17:20 < jrandom> tunnel config shouldn't be a problem either, though that brings up the idea that maybe Phex would need an "advanced configuration" section for plugins
            
-
            17:20 < jrandom> (we'd obviously want to have good defaults anyway)
            
-
            17:21 <+redzara> maybe something like ircclient, an filter to be sure
            
-
            17:22 <@cervantes> better to get the app in shape imho
            
-
            17:22 < jrandom> that might work, though dealing with arbitrary byte sequences may be tough
            
-
            17:23 < jrandom> though, a proxy like ircclient might be able to allow any gnutella client to use it.  but it'd be a bunch of work.
            
-
            17:23 <+redzara> humm, it's just an idea ;)
            
-
            17:23  * jrandom doesn't know the protocol well enough to say what the best approach is, so suggest going with the simplest thing that could possibly work :)
            
-
            17:25 < jrandom> ok, if there's isn't anything else, perhaps we can swing through 5) stego and darknets briefly
            
-
            17:26 < jrandom> i'm not sure if there's anything i have to add beyond whats being said on the list (and major discussion should probably continue there)
            
-
            17:27 < jrandom> that said, is there anything people want to bring up about the issues raised?
            
-
            17:27 < wiht> Freenet version 0.5 and 0.7 were mentioned in the discussion. Is there a version 0.6 for Freenet?
            
-
            17:27 < jrandom> 0.6 is their current "unstable" branch of the network
            
-
            17:27 < jrandom> afaik
            
-
            17:27 <+postman> ohh and i thought it has been stolen by alien forces
            
-
            17:28 < jrandom> while blaming the aliens is usually a safe bet, this is one of the few instances where they're not at fault
            
-
            17:28 <+postman> :)
            
-
            17:28 < wiht> Toad was talking about being able to harvest the IP addresses of I2P or FreeNet nodes, right?
            
-
            17:28 < jrandom> among other things
            
-
            17:29 < wiht> Just wanted to clarify that, thanks.
            
-
            17:29 < jrandom> np.  ok, anyone else have anything on 5), or shall we move on over to the good ol' fashioned 6) ???
            
-
            17:30 <+postman> ok, i got one for 6)
            
-
            17:30 < jrandom> consider us moved.
            
-
            17:30 < jrandom> whats up postman?
            
-
            17:30 <+postman> we all have seen that protocol specific filter capable proxies are good and needed
            
-
            17:31 <+postman> would it be feasable to invest thinking in a generic proxy
            
-
            17:31 <+postman> that can be fed with a protocol description
            
-
            17:31 <+redzara> I would like to have an application like cron using beanshell to run code java code dynamically
            
-
            17:31 <+postman> along with stuff to watch for/filter/disguise
            
-
            17:31 <+postman> like a filter/sanitize xml description 
            
-
            17:32 <+postman> so that we dont need new source but just a new filter file/profile
            
-
            17:32 <+postman> (just a question if its worth to think about it)
            
-
            17:32 < jrandom> very, very complicated postman.  it'd be possible to use a lexer like javacc to build input languages and an app to translate that language into the output format
            
-
            17:32 <@cervantes> it's catching the stuff that deviates from the protocol that's tricky
            
-
            17:33 <+postman> it was just an idea to trigger a process of brainstorming
            
-
            17:33 <+postman> imho something like a generic proxy with modeled filter/parser is very usable
            
-
            17:33 < wiht> Has anyone been able to connect to eepsites.i2p? I have tried several times over the past week, but was always unsuccessful.
            
-
            17:33 < jrandom> wiht: i loaded it once, its the same as eepsites.com
            
-
            17:34 < jrandom> (or is it .net?  or .org?  i forget)
            
-
            17:34  * wiht visits eepsites.com
            
-
            17:34 < jrandom> postman: if someone could come up with something that'd work, that'd kick ass
            
-
            17:34 <+postman> jrandom: ok, i'll do some thinking together with susi
            
-
            17:34 < jrandom> w3wt
            
-
            17:34 <+postman> jrandom: maybe we'll drop it next week 
            
-
            17:35 < wiht> It is eepsites.com, and it is a search engine for eepsites.
            
-
            17:35 <+postman> but i had a dream that it worked
            
-
            17:35 <+postman> :]
            
-
            17:35 < jrandom> :)
            
-
            17:36  * Complication suspects that descibing all the subtleties which occur in protocols... requires code, and nothing less than code
            
-
            17:36 <+Complication> (for most protocols, at least)
            
-
            17:36 <@cervantes> nah just some eeevul regex
            
-
            17:36 <+postman> Complication: maybe this suspicion is the reason that keeps us from further investigation
            
-
            17:37 <+postman> Complication: i am not yet sure, but suspicion alone will not put me to rest on that matter
            
-
            17:37 < jrandom> well, an important point here is something dust demonstrated for us -
            
-
            17:37  * Complication fears a regex capable of such things
            
-
            17:37 < jrandom> code isn't necessarily that scary.
            
-
            17:37 <+postman> see? :)
            
-
            17:37 <+postman> a good filter modelling language will do the same
            
-
            17:38 <+postman> :)
            
-
            17:38 <@cervantes> tcl? :)
            
-
            17:38 <+Complication> It would have to be good.
            
-
            17:38  * jrandom sees that you've got your own flying ponies too postman ;)
            
-
            17:38  * dust also felt bad about duplicating code here and there
            
-
            17:38 <+postman> jrandom: no cows :)
            
-
            17:38 < jrandom> working code >>> theoretical improvements in code 
            
-
            17:39 <+postman> mmh
            
-
            17:40 <+postman> one thing i learned from i2p
            
-
            17:40 < wiht> >>> means "much, much better?"
            
-
            17:40 <+postman> do not give up on first looks
            
-
            17:40 < jrandom> true enough postman 
            
-
            17:40 < jrandom> yes wiht 
            
-
            17:41 < jrandom> it would be really cool
            
-
            17:41 < jrandom> ok, anyone else have something to bring up for the meeting?
            
-
            17:41 <+bar> well, how's the IMAP working, postman? (i read about it in the forums but haven't tried it yet myself)
            
-
            17:41 <+postman> bar: try it yourself - i have no user reports yet
            
-
            17:41  * cervantes rolls in the pony shaped gong
            
-
            17:42 <+bar> ok, will do :)
            
-
            17:42 <+postman> bar: and for me it works FINE :)
            
-
            17:42 < jrandom> nice
            
-
            17:42 <+bar> cool
            
-
            17:42 <+postman> cervantes: you're fixated
            
-
            17:42 <@cervantes> me?!
            
-
            17:42 <@cervantes> :)
            
-
            17:43 < jrandom> ok, before we reach the 90 minute mark
            
-
            17:43  * jrandom winds up
            
-
            17:43  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting152.html b/www.i2p2/pages/meeting152.html
deleted file mode 100644
index 750a847c..00000000
--- a/www.i2p2/pages/meeting152.html
+++ /dev/null
@@ -1,276 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 152{% endblock %}
-{% block content %}
            I2P dev meeting, October 18, 2005
            
-
            
-
            16:10 < jrandom> 0) hi
            
-
            16:10 < jrandom> 1) 0.6.1.3
            
-
            16:10 < jrandom> 2) Freenet, I2P, and darknets (oh my)
            
-
            16:10 < jrandom> 3) Tunnel bootstrap attacks
            
-
            16:10 < jrandom> 4) I2Phex
            
-
            16:10 < jrandom> 5) Syndie/Sucker
            
-
            16:10 < jrandom> 6) ???
            
-
            16:10 < jrandom> 0) hi
            
-
            16:10  * jrandom waves
            
-
            16:10 < jrandom> weekly status notes are up at http://dev.i2p.net/pipermail/i2p/2005-October/001017.html
            
-
            16:10 < dust> yay, works now. thanks Gregor
            
-
            16:10 < cervantes> hullo
            
-
            16:11 <+fox> <blx> heloa
            
-
            16:11 < jrandom> ok, jumping into 1) 0.6.1.3
            
-
            16:11 < jrandom> y'all have updated at a pretty good clip, thanks!  
            
-
            16:12 < jrandom> things seem to be in reasonable condition, but I don't have much to add beyond whats in the status notes
            
-
            16:12 < jrandom> anyone have any questions/comments/concerns re: 0.6.1.3?
            
-
            16:13 < jrandom> ok if not, lets jump on in to 2) Freenet, I2P, and darknets (oh my)
            
-
            16:13 < cervantes> 609 known peers!
            
-
            16:14 < cervantes> (w00t)
            
-
            16:14 < jrandom> aye, network has been growin'
            
-
            16:14 <+fox> <blx> oh my!
            
-
            16:14  * cervantes is holding a sweepstake for how long until the big 1000
            
-
            16:14 < jrandom> heh
            
-
            16:14 < tethra> heheh
            
-
            16:15 < tethra> are we betting with digital cash? ;)
            
-
            16:15 < cervantes> but it show how solid i2p core has got lately that the user uptake has been accelerating
            
-
            16:16 < cervantes> nah...jrandom has already unknowningly donated all his beer money for this year
            
-
            16:16 < jrandom> hehe
            
-
            16:16 < jrandom> ok, on 2), i'm not sure if i've got anything else to add to the subject (i think we've flogged that horse).  anyone have any questions/comments/concerns on it?
            
-
            16:18 < cervantes> as you said, if nothing else it has stimulated some interesting semi-related security discussions ie 3)
            
-
            16:18 < jrandom> if not, we can jump forward at a quick pace to 3) Tunnel bootstrap attacks
            
-
            16:18 < jrandom> aye, that it has
            
-
            16:19 < jrandom> the issue Michael brought up quantifies a general view i've had, but its nice to make it explicit
            
-
            16:20 < jrandom> there's going to be some further discussion on the newer attack later this evening (once i can write up a reply), but the former doesn't seem to be much of a problem
            
-
            16:21 < jrandom> does it make sense to people, or do people have any questions or concerns about it?
            
-
            16:22 < cervantes> heh...that either means everyone is cool with it or they can't make head of tail of what the issues are
            
-
            16:23 < cervantes> I'll put myself in the ignorance is bliss category
            
-
            16:23 < jrandom> heh its basically an attack where the mean guys just happen to be the outbound endpoint of every tunnel you've ever built
            
-
            16:23 < jrandom> now, when you're just starting up, "every tunnel you've ever built" is a very small number (eg. 0, 1, 2)
            
-
            16:24 < jrandom> but after a few seconds, the number grows large enough to turn (c/n)^t into a really really small number
            
-
            16:25 < tethra> (c/n)^t is...
            
-
            16:25 < jrandom> (this is one of the reasons why we don't start up the i2cp listener - and hence, i2ptunnel/etc - until a little while after startup)
            
-
            16:25 < jrandom> c == # of colluding peers (bad guys), n == # of peers in the network, t == # of tunnels you've built.
            
-
            16:25 < cervantes> right...
            
-
            16:25 < tethra> ah
            
-
            16:26 < jrandom> so as t grows, the probability of successful attack gets really small
            
-
            16:26 < cervantes> so for it to be even viable you'd have to start using your router for sensitive tasks within a couple of minutes of it starting up?
            
-
            16:26 < jrandom> (or, in any case, smaller than the probability of taking over all hops in a tunnel)
            
-
            16:26 < tethra> ahh, i see
            
-
            16:27 < jrandom> cervantes: immediately, before the 3rd tunnel is built
            
-
            16:27 < jrandom> (assuming you use 3 hop tunnels)
            
-
            16:27 < cervantes> that's fairly improbable
            
-
            16:28 < cervantes> just from a use case perspective
            
-
            16:28 < jrandom> 'zactly.
            
-
            16:28 < jrandom> and since we build more than 3 tunnels on startup before letting any clients run, its not just a probability issue
            
-
            16:28 < jrandom> but its good to quanitify the attack anyway
            
-
            16:29 < cervantes> is it worth letting the router churn for a bit longer to guard against any likelyhood?
            
-
            16:30 < cervantes> or churn harder...
            
-
            16:30 < jrandom> perhaps.  if we ignore connection establishment time as well as nonrandom peer selection, it has no likelihood
            
-
            16:31 < tethra> that's cause for a "woot!" i take it?
            
-
            16:32 < jrandom> aye, though from an engineering perspective, we shouldn't ignore those characteristics ;)  
            
-
            16:32 < jrandom> so, for 0.6.2 we may want to look at it during the revamped tunnel peer selection / ordering implementation, to make sure its behaving Sanely
            
-
            16:34 < jrandom> ok, if there's nothing else on 3), lets move on to 4) I2Phex
            
-
            16:34 < jrandom> sirup isn't here, and i haven't seen striker on irc - redzara, you around?
            
-
            16:36 <+redzara> yes
            
-
            16:36 <+redzara> First pass is nearly completed : port Sirup's mod to lastest phex cvs.
            
-
            16:36 < jrandom> nice1!
            
-
            16:36 <+redzara> next : Second pass : diff from Sirup code to base phex code used in initial release, to be sure i don't forget anything :)
            
-
            16:37 <+redzara> maybe terminated for this W.E.
            
-
            16:37 < jrandom> wow that'd be great
            
-
            16:37 <+redzara> Pass three : refactoring comm layer with GregorK
            
-
            16:37 <+fox> <GregorK> hope you are aware that in latest Phex CVS the download code is not stable and the download file is not compatible with previous releases
            
-
            16:38 < jrandom> this is i2p, we're used to instability :)
            
-
            16:38 <+fox> <GregorK> :)
            
-
            16:38 <+redzara> For the last pass, as I've currently no contact with GregorK, this sould be pretty hard :(
            
-
            16:38 < jrandom> GregorK: what would you recommend for inegration?
            
-
            16:39 <+fox> <GregorK> well you now have contact with me ;)
            
-
            16:39 < jrandom> ah 'k redzara, the first two are big enough in any case :)
            
-
            16:39 <+redzara> GregorK : hi man
            
-
            16:40 <+redzara> GregorK : I've read carefully all codes
            
-
            16:40 <+fox> <GregorK> I have a idea on how to build a layer... I can try to prepare it as good as i can and then we can see how good it fits and what needs to be changed
            
-
            16:40 <+fox> <GregorK> all?? wow...
            
-
            16:40 <+redzara> Gregork : yes, all !!
            
-
            16:41 < cervantes> he even knows the size of your underwear
            
-
            16:41 < Rawn> :D
            
-
            16:41 <+fox> <GregorK> great... next time I'm shopping I just need to ask you... 
            
-
            16:43 <+fox> <GregorK> what would be nice if we could maybe have someone from the i2phex team on the phex team too..
            
-
            16:43 < jrandom> redzara: so, do you think we'll have a 0.1.2 I2Phex release with the results of your second pass before we get everything merged into a plugin layer in the mainline Phex?  or will that be all in one go?
            
-
            16:43 <+redzara> Sorry, but I don't understand / speak /read / write english good enough to  laugh with what you have writed
            
-
            16:43 <+fox> <GregorK> this would also help solve bugs that are on both sides
            
-
            16:44 < jrandom> GregorK: hopefully we'll find a way that the I2P side is just a thin plugin in Phex though, right?
            
-
            16:44 < jrandom> or do you think the two should stay separate?
            
-
            16:44 <+redzara> jrandom : I think we could have an Phex 2.6.4 over I2P, for me I2Phex is down
            
-
            16:45 < jrandom> down?
            
-
            16:45 <+fox> <GregorK> i'm not sure if we can make it this way right from the start, but I think the major part of it could be separated into a plugin.
            
-
            16:45 < jrandom> cool, yeah, its a lot of work, I'm sure
            
-
            16:46 < jrandom> especially when you look at things like java.net.URL (which leaks DNS requests on instantiation, etc)
            
-
            16:46 <+redzara> jrandom : down, endded
            
-
            16:46 <+Ragnarok> grr
            
-
            16:47 < jrandom> ok right redzara, one we can get everything working in Phex 2.6.4 over I2P, I agree, there wouldn't seem to be much of a need for an I2Phex
            
-
            16:47 <+fox> <GregorK> right... I think Phex uses the apache URI class in some places to work around this.. but only when necessary
            
-
            16:48 < jrandom> ah right, I remember playing around with that library, looks good
            
-
            16:49 < jrandom> we'll definitely be helping audit things a bit for anonymity/security before pushing it for end users over i2p
            
-
            16:49 < jrandom> (not to suggest there are any problems in Phex, just there are problems in every app, and hopefully we can help sort 'em out)
            
-
            16:50 <+fox> <GregorK> for some things like Socket use and these things I have an idea on how to integrate it smothly... but other places like different features UDP and such... I'm not sure yet how to solve them best
            
-
            16:50 <+fox> <GregorK> oh i'm sure there are many problems in phex. :)
            
-
            16:50 < jrandom> ah, yeah sockets will be easy, but we may need to disable other things.  what is udp used for - quick queries?
            
-
            16:51 <+fox> <GregorK> currently only bootstrapping
            
-
            16:51 <+fox> <GregorK> UDP Host Cache.. a replacement for GWebCache
            
-
            16:52 < jrandom> ahhh, ok.  
            
-
            16:52 <+redzara> So we don't need it if we have a descent GwebCache ?
            
-
            16:53 <+fox> <GregorK> yes... but the standard GWebCache have there security problems too...
            
-
            16:53 <+redzara> GregorK : not inside I2P I think
            
-
            16:54 < jrandom> oh, that part could be overcome - I2PSocket is authenticated - you know the 'destination' of the peer on the other end, so they couldn't say "I'm, er... whitehouse.gov.. yeah!"
            
-
            16:54 < jrandom> but you're right, its soemthing that needs to be verified 
            
-
            16:54 <+fox> <GregorK> also firewall to firewall transfers would be a UDP topic we like to implement once we find a volunteer :)
            
-
            16:54 < jrandom> ah, well, I2P doesn't need firewall to firewall transfers - I2P exposes an entirely open end to end address space :)
            
-
            16:55 < jrandom> but... ooh, thats something that might be useful
            
-
            16:55 < jrandom> if Phex users had "0 hop tunnels", they'd get free NAT traversal/firewall to firewall transfers with pretty decent speed
            
-
            16:55 <+fox> <GregorK> another one would be LAN broadcasts of queries and such... for easier sharing of contents in private networks
            
-
            16:56 < jrandom> (0 hop tunnels offers a level of plausible deniability without requiring any intermediary peers to carry the trafffic)
            
-
            16:57 < jrandom> hmm, lan broadcast is good, though i'm not sure if i2p would really need that (since its an anonymity risk to know where the other peer is :), so perhaps that feature could be disabled when using the I2P plugin?
            
-
            16:58 < cervantes> *disabled by default
            
-
            16:58 <+fox> <GregorK> well its not available yet.. but in this case user usually know each other anyway to build that private network..
            
-
            16:58 < jrandom> oh right cervantes 
            
-
            16:58 < jrandom> right right GregorK
            
-
            16:59 <+fox> <GregorK> are there any changes regarding the user interface??
            
-
            17:00 <+bar> well, we won't need flags :)
            
-
            17:00 < jrandom> at the least, the ability to have a few configuration options related to I2P would be useful.
            
-
            17:01 < jrandom> i think sirup was able to switch in some of the display to use I2P 'destinations' instead of showing IP + port numbers, so I think it was fine 
            
-
            17:01 <+redzara> And what about bitzyNot for the moment, but flags and countries are unused
            
-
            17:01 < jrandom> bitzy?
            
-
            17:01 <+redzara> sorry, wrong coupy/paste :(
            
-
            17:02 <+fox> <GregorK> can you provide a list of configuration options and optional features you need?
            
-
            17:03 < jrandom> I'm sure we can get those to you.  a host+port that I2P is running on and a few drop downs regarding performance/anonymity tweaks should do it
            
-
            17:03 < jrandom> we'll get you the details though
            
-
            17:02 <cervantes> [x] Super transfer speed mode
            
-
            17:02 <+fox> < GregorK> well bitzi is used to identify files.. is that an anonymity problem?
            
-
            17:03 < vulpine> <redzara> GregorK : I'm preparing it, but basicly, thre is no changes
            
-
            17:03 <+fox> < GregorK> :) ask your provider cervantes...
            
-
            17:03 <redzara> GregorK : maybe, I'm working on it
            
-
            17:04 <cervantes> GregorK: heh UK resident....no chance ;-)
            
-
            17:04 <+fox> < GregorK> if you transfer files between 2 Phex instances on the same PC.. transfers are lightning fast ;)
            
-
            17:05 <cervantes> cool...I have lots of cool movies I can share with myself :)
            
-
            17:05 <cervantes> * strike that from the meeting notes *
            
-
            17:06 <bar> jrandom touched the subject before, but, here's that crazy idea again:
            
-
            17:06 <+bar> how 'bout integrating i2p into Phex, so that ordinary users have 0-hop tunnels?
            
-
            17:07 <+fox> <GregorK> I think display of flags and IP+port comes from the HostAddress object.. which would be hidden from the new layer.. so you can display something else
            
-
            17:07 <+bar> (for plausible deniability and udp firewall hole punching)
            
-
            17:08 <+fox> <GregorK> not sure if I really understand what that means ;)
            
-
            17:08 <+bar> probably me neither ;)
            
-
            17:09 < jrandom> GregorK: essentially, it means that Phex users would talk to each other directly, but would get plausible deniability, as they could be talking indirectly
            
-
            17:09 <+bar> jrandom, i'm sure you're catching my drift here, could you elaborate?
            
-
            17:09 < jrandom> they'd also get I2P's NAT traversal thrown in for free, as well as data security and protection from sniffing by ISPs/etc
            
-
            17:09 <+redzara> GregorK : so you have to strip all code related to host+port + IsLocalIP + Is PrivateIP + ...
            
-
            17:10 < jrandom> on the other hand, (a BIG other hand), it wouldn't be able to talk to gnutella clients that don't run on top of I2P
            
-
            17:10 < jrandom> (though eventually, they all will ;)
            
-
            17:10 <+fox> <GregorK> Well I think the first step is - and that step is already big enough - to bring i2p and phex closer together.
            
-
            17:10 < jrandom> agreed
            
-
            17:10 <+bar> (damn, didn't think of that)
            
-
            17:11 <+bar> yeah, def.
            
-
            17:11 < jrandom> this is flying pony stuff.  lets get the practical things first
            
-
            17:11 <+fox> <GregorK> and after we see how good that worked we can decide how we go further.. 
            
-
            17:11 < jrandom> exactly
            
-
            17:12 <+fox> <GregorK> redzara: I like to have two implementations of HostAddress one for i2p and on like the current.
            
-
            17:14 <+redzara> Gregork : no pb, I've commented all code in my mod you could easyly build two implementations. Just let me finish the initial work please
            
-
            17:14 <+fox> <GregorK> sure.. no problem..
            
-
            17:14 < jrandom> :)  ok, so redzara, you think we may be able to get an alpha test of the new Phex-2.4.2 based version sometime next week?
            
-
            17:15 < jrandom> (for the phase 2 part.  your phase 3 will take more work integrating with the mainline)
            
-
            17:15 <+redzara> jrandom : next sems to be ok for me
            
-
            17:16 < jrandom> ok great
            
-
            17:16 <+redzara> s/next/next week/
            
-
            17:16 < jrandom> ok, this is pretty exciting stuff, it'll be wonderful to get it going smoothly 
            
-
            17:17 < jrandom> does anyone have anything else to bring up for 4) I2Phex, or shall we move on briefly to 5) Syndie/Sucker?
            
-
            17:17 < cervantes> I2P will surely benefit from such killer apps
            
-
            17:18 <+fox> <GregorK> btw there is a Phex CVS mailing list for all CVS changes in Phex... if that is of any help
            
-
            17:18 < jnymo> *ehem*.. hell yes
            
-
            17:18 < jrandom> ok great, thanks GregorK
            
-
            17:18 < jrandom> definitely cervantes 
            
-
            17:19 < jrandom> ok, on 5), I don't really have anything to add beyond whats there
            
-
            17:19 < jrandom> dust: are you around?
            
-
            17:19 <+redzara> GregorK : Thanks but handlingone version is far enough for me :)
            
-
            17:19 < jrandom> hehe redzara 
            
-
            17:19 < dust> I haven't had much spare time lately, but if I do I'm thinking I'll try to get a handle on this addresses.jsp thing, add 'RSS' in the protocol dropdown in there and then build a path through Updater, Sucker to BlogManager.
            
-
            17:20 < dust> unless anyone have a better idea
            
-
            17:20 < jrandom> kickass
            
-
            17:20 < jrandom> that sounds perfect.
            
-
            17:21 < jrandom> though, hmm, maybe it'd need an additional field (the "what blog to post it in" and "what tag prefix")...
            
-
            17:21 < jrandom> maybe a separate form/table would make sense, though maybe not
            
-
            17:22 < dust> oh, I thought addresses.jsp was for one blog only (since you have to login to get there?)
            
-
            17:22 < jrandom> ah, true, good point
            
-
            17:23 < jrandom> the updater part is kind of fuzzy, but you're right
            
-
            17:23 < dust> (we'll figure it out when we get there)
            
-
            17:23 < jrandom> aye
            
-
            17:24  * jnymo thinks www.i2p.net could start up a 'merchandise cafe' type thing
            
-
            17:24 < jnymo> with eyetoopie shirts that say "I am Jrandom" on them ;)
            
-
            17:24  * mrflibble  is still catching up on the "flamewar",  which seems to be spiraling into  a proper flamewar :)
            
-
            17:24 < jrandom> heh jnymo 
            
-
            17:25 < jrandom> yeah, there's a lot of content in that thread
            
-
            17:25 < jrandom> ok, maybe this gets us to 6) ???
            
-
            17:25 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            17:25 <+bar> aye, just a quick note on the symmetric nat issue (been doin a lil snoopin'):
            
-
            17:25 <+nickless_head> jrandom: I know the truth!
            
-
            17:25 <+fox> <blx> kaffe?
            
-
            17:25 < mrflibble> oops,  sorry jr
            
-
            17:26 < jnymo> but seriously.. every open source project of any size has their own merchandise section
            
-
            17:26 <+nickless_head> jrandom: I have definite proof you hacked the last.fm homepage!
            
-
            17:26 <+nickless_head> (the what you get when you sign up section listed 'a pony')
            
-
            17:26 < jrandom> jnymo: i think you're right, we will want to explore that avenue, might be a good method of fundraising too
            
-
            17:27 < jnymo> jrandom: exactly
            
-
            17:27  * mrflibble would buy the tshirt
            
-
            17:27 <+bar> right, regarding symmetric nats,
            
-
            17:27 <+bar> for what it's worth, i think that unlike for the already supported nats, there's no magic trick. the only way to do it properly, is to study and examine each and every symmetric nat's behaviour and use introducers for probing.
            
-
            17:28 < jrandom> blx: the latest kaffe CVS is completely b0rked.  the crypto packages aren't in the source, the prng fails to initialize, and the url handlers can't deal with file:// :(
            
-
            17:28 < jnymo> You probably wouldn't want to wear it in public until i2p has a few thousand users though ;)
            
-
            17:28 <+bar> (i believe this is how e.g. Hamachi and Skype do udp hole punching from behind symmetric nats)
            
-
            17:28 <+nickless_head> jnymo: cups would rule :)
            
-
            17:28 <+bar> based on what i have read on the 'net so far, symmetric nat prediction algos pretty much suck.
            
-
            17:28 < jrandom> hmm bar
            
-
            17:28 < mrflibble> hehe, i wouldn't put my nick on it. oh, and i'm still allive/unarrested even though  i've got an IIP ttshirt
            
-
            17:28 < jrandom> yeah, thats what i read too
            
-
            17:29 <+bar> i will try gathering some more good, relevant reading material on this.
            
-
            17:29 <+redzara> Small question : what was the common average percentage of bytes retransmitted in 0.6.1.3 ?
            
-
            17:29 < jrandom> thanks bar
            
-
            17:29 <+fox> <jme___> bar, the prediction they got are consistent ? 
            
-
            17:29 <+fox> <jme___> bar, let me rephrase :)
            
-
            17:29 <+fox> <blx> jrandom, i'm sad to hear
            
-
            17:30 < jrandom> redzara: I unfortunately forgot to put that into the netDb.  I do see 2.6 and 3.8 right now though
            
-
            17:30 < jrandom> blx: me too :(
            
-
            17:30 <+fox> <jme___> bar, when you analyze the nat box behaviour and find a formula to predict it. does this always work for this nat box ? or later once it worked, once it fails ?
            
-
            17:30 < jrandom> blx: i know they're doing some merging with classpath now though, so hopefully once thats sorted
            
-
            17:30 <+fox> <blx> probably means i wont be joining the party
            
-
            17:30 < jrandom> blx: are you kaffe-specific, or OSS/DFSG-specific?
            
-
            17:31 <+fox> <blx> free software
            
-
            17:31 <+fox> <blx> dfsg you could say
            
-
            17:31 < jnymo> encase an i2p user wants to use a hosted server for i2p, what would be a liberal, cheap hosted services company to go with?
            
-
            17:31 <+bar> jme___: hamachi is reportedly able to mediate 97% of all connection attempts. i guess there are some nats out there that show an almost random behaviour when it comes to assigning ports
            
-
            17:32 < jrandom> ok, I'm sure we'll get something going blx.  kaffe used to work, and we don't depend upon anything sun specific
            
-
            17:32 < jrandom> jnymo: i use sagonet.net, but they've cranked up their prices from 65/mo to 99/mo (but on a fast link w/ 1250GB/mo)
            
-
            17:32 < jrandom> i know there are some cheap ones in germany too
            
-
            17:33 <+fox> <jme___> bar, 97% would be terrific
            
-
            17:33 < jrandom> redzara: what are you seeing for retransmission rate?
            
-
            17:33 <+bar> jme___: yeah, so i guess most symmetric nats are predictable
            
-
            17:33 <+fox> <blx> jrandom, i sure hope so. i'm really interested in this shit :)
            
-
            17:33 <+fox> <jme___> bar, what would you do ? relay, udp hole punching, cnx reversal.. is there others thech ?
            
-
            17:33 < jnymo> is 99 expensive, on average?
            
-
            17:34 <+redzara> jrandom between 3;8 and 4.2
            
-
            17:34 < jrandom> jme___: we're udp, no need for connection reversal :)
            
-
            17:35 <+bar> jme___: i'm no expert, perhaps i'll have some more info for next week's meeting (but it sure smells like profiling + udp hole punching ;)
            
-
            17:35 < jrandom> jnymo: for 1250GB, not really.  i've seen 60-120USD/mo for 50-100GB/mo
            
-
            17:35 < jrandom> bar: perhaps UPnP would be a better way to go?
            
-
            17:35 <+fox> <jme___> jrandom, even with udp it is usefull :)
            
-
            17:35 <+redzara> jrandom : but only some node done major impact, maybe some olders
            
-
            17:35 <+fox> <jme___> vulpine: ok
            
-
            17:35 < jrandom> though that only helps the people who could control their NAT
            
-
            17:36 <+fox> <jme___> upnp must be supported but it isnt exclusive to other means
            
-
            17:36 < jrandom> well, we're doing everything we do now without any UPnP
            
-
            17:36 <+fox> <jme___> because upnp isnt supported by all nat, far from it
            
-
            17:36 < jrandom> right, e.g. an ISP's nat
            
-
            17:36 <+bar> jrandom: if there are no security issues with upnp, i guess it can't hurt. though, hamachi doesn't use upnp
            
-
            17:36 <+fox> <jme___> here by 'must' = to provide the max connectivity
            
-
            17:37 <+fox> <jme___> ok going back to my c++ :)
            
-
            17:38 < jrandom> right jme___, though if we can do symmetric hole punching in addition to cone/restrited hole punching, we're in great shape
            
-
            17:38 < jrandom> l8s jme___
            
-
            17:38 < jrandom> yeah, it'd be ideal if we didn't need it
            
-
            17:39 < jrandom> ok, anyone have anything else to bring up for the meeting?
            
-
            17:41 < jrandom> if not...
            
-
            17:41  * jrandom winds up
            
-
            17:41  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting153.html b/www.i2p2/pages/meeting153.html
deleted file mode 100644
index da9b839e..00000000
--- a/www.i2p2/pages/meeting153.html
+++ /dev/null
@@ -1,446 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 153{% endblock %}
-{% block content %}
            I2P dev meeting, October 25, 2005
            
-
            
-
            16:24 < jrandom> 0) hi
            
-
            16:24 < jrandom> 1) Net status
            
-
            16:24 < jrandom> 2) Fortuna integration
            
-
            16:24 < jrandom> 3) GCJ status
            
-
            16:24 < jrandom> 4) i2psnark returns
            
-
            16:24 < jrandom> 5) More on bootstrapping
            
-
            16:24 < jrandom> 6) Virus investigations
            
-
            16:24 < jrandom> 7) ???
            
-
            16:24 < jrandom> 0) hi
            
-
            16:24  * jrandom waves
            
-
            16:24 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/001079.html
            
-
            16:25  * susi23 waves back
            
-
            16:26 < jrandom> lets jump on in to 1) net status
            
-
            16:26 < jrandom> as I mentioned, things look pretty reasonable so far.  
            
-
            16:26 <+fox> <Romster> ah meeting sweet
            
-
            16:27 < jrandom> there is some good stuff coming down the line too, so we'll have a new release later this week
            
-
            16:27 < jrandom> anyone have anything they want to bring up regarding 1) net status?
            
-
            16:27 <@cervantes> omg 7 issues
            
-
            16:27 <+legion> yup looking good :-)
            
-
            16:27 < jrandom> busy week cervantes :)
            
-
            16:28 <@cervantes> can only be good
            
-
            16:28 <+Complication> Works relatively well, dev.i2p even - I can even pull CVS checkouts without EOF messages.
            
-
            16:28 < jrandom> nice :)
            
-
            16:28 <+Complication> Might have been release-related overloads, those last ones.
            
-
            16:28 <+Complication> But I can't tell.
            
-
            16:28 < jrandom> dev.i2p is on the latest build code too (-7), so it'll be hopefully performing substantially better than before
            
-
            16:29 < jrandom> s/dev.i2p/cvs.i2p (etc)/
            
-
            16:29 <+legion> forums.i2p also seems to be much better than before :)
            
-
            16:29 <@cervantes> *ahem*
            
-
            16:29 <+fox> <Romster> is i2p safe to let others join etc?
            
-
            16:29 <+Ragnarok> ok, now I've got to try this miraculous "cvs checkout that works the first time"
            
-
            16:30 <+fox> <Romster> since there is no known limits now
            
-
            16:30 <@cervantes> that's because everyone's hammering i2p-list instead of posting to the forum 
            
-
            16:30 <+legion> hmm you sure cervantes?
            
-
            16:30 < jrandom> Romster: well, we've been growing at a pretty good pace lately, but we should hold off on public beta until 0.6.2
            
-
            16:30 < jrandom> heh cervantes ;)
            
-
            16:30 < jrandom> hush Ragnarok, you'll jinx it!
            
-
            16:31 <+Ragnarok> wow... it's true.  I'm speechless
            
-
            16:31 <+fox> <Romster> k jrandom
            
-
            16:31 < jrandom> (man my eyes are watering from the curry my roomates are cooking downstairs)
            
-
            16:31 < jrandom> nice1 Ragnarok 
            
-
            16:32 <+fox> <Romster> lol now that's a strong curry
            
-
            16:32 < jrandom> ok, if there's nothing else on 1), we can jump quickly through 2) Fortuna integration
            
-
            16:32 < jrandom> (true that Romster)
            
-
            16:32 <+fox> <shardy> yay for fortuna integration!
            
-
            16:32 <+fox> <Romster> moving onto 2) :P
            
-
            16:32 <+fox> <Romster> what is fortuna?
            
-
            16:32 < jrandom> heh thought you'd like that shardy :)
            
-
            16:32 <+fox> <Romster> i've been a bit behind the last month
            
-
            16:32 <+Complication> PRNG algo, if I remember.
            
-
            16:33 <+Complication> Supposedly a good one, or so they write. :P
            
-
            16:34  * Complication knows nothing about its inner workings, though
            
-
            16:34 < jrandom> shardy: I'd love if you could give it a look sometime
            
-
            16:34 <+fox> <shardy> of course
            
-
            16:34 <+fox> <shardy> you're using the gnu implementation?
            
-
            16:34 < jrandom> Romster/Complication: there are some links in the email
            
-
            16:34 < jrandom> yeah shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java
            
-
            16:35 < jrandom> (integrated with http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java )
            
-
            16:36 < jrandom> we vary from the straight gnu-crypto implementation though, since we've already got AES256 and SHA256 code (Cryptix's and Bouncycastle's, respectively)
            
-
            16:36 < jrandom> ok, anyway, this looks cool, as we've been hacking through getting that support in there for probably a year now
            
-
            16:37 < jrandom> (fortuna integration was one of the main projects driving smeghead to build 'pants' ;)
            
-
            16:37 < jrandom> if anyone has any questions/comments/concerns about it, please bounce 'em to the list
            
-
            16:37 < jrandom> (or email, or forum, of course)
            
-
            16:38 <+fox> <Romster> yeah where is smeghead hes not been around for awhile now
            
-
            16:38 < jrandom> smeghead is [redacted] doing [redacted]
            
-
            16:39 < jrandom> ok, moving on to 3) GCJ status
            
-
            16:39 < jrandom> i2p works on GCJ!  [w00t!]
            
-
            16:39 <+susi23> nice job
            
-
            16:39 <+legion> sweet
            
-
            16:39 < jrandom> at least, it does on GCJ 4.0.2 on linux 2.6.12.  I haven't tried any other platforms
            
-
            16:40 < jrandom> yeah, the GCJ and GNU Classpath folks have worked wonders
            
-
            16:40 < jrandom> it was really easy to get it building, the old static reference classes I remember weren't necessary
            
-
            16:41 <+Complication> Which sounds quite positive, given Sun Java's less-than complete openness (with regard to distribution, if I remember correct).
            
-
            16:41 < jrandom> there's a makefile shipped with I2P now, though for simplicity, I think we'll probably stick with distributing pure java, at least primarily
            
-
            16:41 <+susi23> (next we try to run it on J2ME ;)
            
-
            16:42 <+fox> <Romster> GCJ to take over Suns JVM>
            
-
            16:42 < cat-a-puss> how is preformance with GCJ?
            
-
            16:42 < jrandom> aye, though sun is entirely open, and we /could/ distribute their JVM along side I2P, but their license prohibits distributing their JVM as a general purpose tool
            
-
            16:42 < jrandom> cat-a-puss: comparable
            
-
            16:42 < jrandom> most of the heavy work in i2p is already done by assembler code ;)
            
-
            16:43 <+fox> <Romster> how would i2p go with C#/mono again with that jave to C# adition (forgot it's name)
            
-
            16:43 <+fox> <Romster> i remember jrandom and i both tryed it out ages ago
            
-
            16:43 < jrandom> no idea.  but if it works with gcj, it might work with ikvm - the mono jvm thing
            
-
            16:44 <+Ragnarok> IKVM
            
-
            16:44 <+Ragnarok> nm
            
-
            16:44 <+fox> <Romster> ah tahts the one ikvm
            
-
            16:44 <+fox> <Romster> much difereances with GCJ and IKVM and Sun's?
            
-
            16:45 < jrandom> i've never used ikvm
            
-
            16:45 <+fox> <Romster> i'm sure you have once with mono or was that eclipse?
            
-
            16:45 <+fox> * Romster shrugs
            
-
            16:45 < jrandom> and i2p as shipped doesn't currently support the router console, though it does support the router operation, i2ptunnel, and sam
            
-
            16:46 <+Ragnarok> what's blocking the router console?
            
-
            16:47 <+susi23> xerces, when I remember correctly
            
-
            16:47 < jrandom> xerces stuff.  the xercesImpl shipped with i2p has sun.* dependencies, and when I naively tried to drop in the latest xerces, getting that and jdom and rome and the rest of jetty GCJed was b0rking
            
-
            16:47 < jrandom> there are some additional requirements of the latest xerces, it seems
            
-
            16:48 < jrandom> (for jar files we don't currently ship).  however, I'm sure we can track it down
            
-
            16:49 <+fox> <Romster> jrandom is good at tracking down problems :)
            
-
            16:49 < jrandom> even better at making problems
            
-
            16:49 <+fox> * Romster featches a coffee
            
-
            16:49 < jrandom> ok, anything else on 3) GCJ status?
            
-
            16:49 < jrandom> or shall we move on to 4) i2psnark
            
-
            16:50 < jrandom> consider us moved
            
-
            16:50 < jrandom> ok, i2psnark is back (yay)
            
-
            16:51 < jrandom> not much I have to add to whats in the mail... you have anything Ragnarok?
            
-
            16:51 <+Ragnarok> nope
            
-
            16:51 <+susi23> regarding web frontend
            
-
            16:51 <+Ragnarok> more testing would be nice though, so everyone should try it :)
            
-
            16:52 <+susi23> supporting it with susibt shouldn't be a problem
            
-
            16:52 < jrandom> ooh give us the scoop susi23 :)  
            
-
            16:52 < jrandom> nice
            
-
            16:52 <+fox> <jme___> naive question, why spending time supporting old bt client while other (azureus) support full blown client ?
            
-
            16:52 < jrandom> jme___: azureus *is* kickass
            
-
            16:52 <+susi23> major release of susibt is scheduled for november :)
            
-
            16:53 < jrandom> heh cool susi23 
            
-
            16:53 <+Complication> To me, Azureus seemed terribly complex.
            
-
            16:53 <+Ragnarok> azureus blows monkey chunks
            
-
            16:53 <+susi23> for me, I always need a headless solution
            
-
            16:53 <+Ragnarok> not to put too fine a point on it
            
-
            16:53 <+fox> <jme___> ok :)
            
-
            16:53 < jrandom> jme___: azureus is a bit heavyweight though, but is a great general purpose bt solution
            
-
            16:53 <+Complication> (I personally could see the day I'd misconfigure something in it, and dent my anonymity.)
            
-
            16:54 <+fox> <jme___> it make sense, just wanted to know
            
-
            16:54 <+fox> <Romster> to me azerious never workd well i've moved to bitlord which does work
            
-
            16:54 < jrandom> i do still plan on helping further improve the azneti2p plugin with the azureus folks, but i2psnark took literally less than 2 hours before I was swarming data
            
-
            16:54 <+legion> Yeah azureus is just too big and complicated for i2p
            
-
            16:54 <+Complication> If the goal is bundling a bt client along with i2p, a lightweight client sounds best.
            
-
            16:54 <+fox> <Romster> KISS principal
            
-
            16:54 <+Ragnarok> I like the official client best, but i2psnark has the major advantage of being simple enough for me to hack on
            
-
            16:55 <+legion> thing is i2p doesn't need a heavyweight bittorrent client
            
-
            16:55 < jrandom> yeah, its really clean code (with oddball gnu formatting ;)
            
-
            16:55 <+Ragnarok> damn gnu
            
-
            16:55 <+Ragnarok> worst brace style ever
            
-
            16:55 < jrandom> heh
            
-
            16:55 <+fox> <Romster> heh code reformatter :)
            
-
            16:55 <+Ragnarok> jrandom won't let me :)
            
-
            16:55 <+Ragnarok> well, for good reason
            
-
            16:55 <+fox> <jme___> independance and simplicity are criteria i definitly agree with
            
-
            16:56 <+fox> <Romster> will there be options to enable the bt-torrent program on each i2p node?
            
-
            16:56 < jrandom> aye, it'd be nice if we can backport multitorrent, piece selection, and web capacity to mjw's mainline snark
            
-
            16:56 <+Ragnarok> the simpler it is, the more likely it will be maintained
            
-
            16:56 < jrandom> exaaactly Ragnarok 
            
-
            16:57 <+legion> yeah backporting those would be killer
            
-
            16:57 <+fox> <Romster> as a OT point here take a look at emules KAD network i think it's rather neat.
            
-
            16:57 < jrandom> Romster: its now shipped with the build by default, but once we get it into susibt, it'll be on the top nav with the rest of the clients
            
-
            16:58 <+Ragnarok> we need to be able to ship a .torrent maker as well, though.  And a tracker would be nice.
            
-
            16:58 < jrandom> yeah, actually, snark has both of those, I just disabled them because i didn't want to maintain 'em :)
            
-
            16:58 <+legion> hmm good point ragnarok
            
-
            16:58 < jrandom> but getting them back in wouldn't be much trouble
            
-
            16:59 <+Ragnarok> well, the torrent maker at least shouldn't be that bad
            
-
            16:59 < jrandom> there's a Tracker.java too, and handling in the PeerAcceptor, but I threw out what wasn't necessary, so one would probably want to look back at http://klomp.org/snark/ for those
            
-
            17:00 < jrandom> (and review http://dev.i2p/~jrandom/snark_diff.txt for changes)
            
-
            17:00 <+fox> <Romster> since snarik is back it'll get worked on right :)
            
-
            17:00 <+legion> actually when it comes to a tracker, it'd be better to come up with a distributed solution
            
-
            17:00 <+fox> <Romster> snark*
            
-
            17:00 < jrandom> porting code is easier than building a new distributed tracker legion ;)
            
-
            17:00 <+fox> <Romster> legion, your your talking
            
-
            17:00 <+legion> true, that
            
-
            17:01 < jrandom> but I wouldn't be opposed to integrating a nice clean maintained anonymity-friendly distributed tracker solution :)
            
-
            17:01 <+fox> <Romster> could be tacked onto the eepsites?
            
-
            17:01  * jrandom spots a flying pony go past the window
            
-
            17:01 <+Ragnarok> the official bt client has a kademlia based distributed tracker, but obviously that's only good as a design reference
            
-
            17:01 <+legion> a place to start ;)
            
-
            17:02 <+fox> <Romster> actually kademlia = emules KAD netowrk? hmm, if that's the case KAD would be ideal for a tracker but bootstraping is an issue
            
-
            17:03 <+Ragnarok> they're based on the same algorithm, but they're not in any way compatable
            
-
            17:03 <+Ragnarok> compatible, even
            
-
            17:04 <+Ragnarok> doing something like emule's KAD for i2phex would be sort of interesting...
            
-
            17:04 <+Ragnarok> anyway, flying ponies
            
-
            17:04 < jrandom> :)
            
-
            17:04 < jrandom> (agreed on both counts)
            
-
            17:04 < jrandom> ok, anything else on 4) i2psnark?
            
-
            17:05 <+Ragnarok> as long as we have something to make .torrent files, the existing trackers are fine
            
-
            17:05 < jrandom> thats a good point - there's some commented out code in Snark's main I believe
            
-
            17:05 <+legion> no I think the existing trackers are not fine :(
            
-
            17:05 < jrandom> whats wrong with them legion?
            
-
            17:05 < cat-a-puss> don't just hand uesrs a torrent file ether
            
-
            17:05 <+legion> often have trouble accessing them
            
-
            17:06 < jrandom> hmm cat-a-puss?  oh, you mean, we need to get a web interface to transparently swarm?
            
-
            17:06 <+legion> sites get flooded with traffic
            
-
            17:06 < jrandom> ah, thats i2p's issue, hopefully 0.6.1.4 will improve that
            
-
            17:06 < jrandom> postman was telling me how he was getting tons of hits @ tracker.postman.i2p
            
-
            17:06 < jrandom> i forget the #s offhand
            
-
            17:06 < cat-a-puss> If we are handling both the swarming code and the code to get the torrent in the first place, might as well make it transparent for the user
            
-
            17:07 < jrandom> orion.i2p/bt/ isn't really used though
            
-
            17:07 < jrandom> (and tracker-fr seems lively)
            
-
            17:07 <+susi23> with susibt I hope to include trackers rss feed, so you don't need to go on the trackers webpage anymore but get the torrents downloaded automatically :)
            
-
            17:07 < cat-a-puss> also prevents confusing an i2p torrent with a non-anonymous one
            
-
            17:07 <+fox> <jme___> http tracker for bt doesnt scale due to poorely designed protocol
            
-
            17:07 <+fox> <Romster> router watchdog router hung hard restart wtf
            
-
            17:07 <+legion> right, which is my point some trackers are flooded while others are idle
            
-
            17:07 < jrandom> cat-a-puss: ah, yeah I'd love to integrate hooks from syndie into susibt :)
            
-
            17:07 <+fox> <jme___> it can be easily fixed but break the compatibility with official bt protocol
            
-
            17:08 <+fox> <jme___> it is the road followed by the dht tracker stuff
            
-
            17:08 < jrandom> (and the other way around, so people can easily syndicate .torrent files, etc)
            
-
            17:08 <+Complication> Romster: I get those, but the machine I get them on is borderline (300 MHz)
            
-
            17:08 <+fox> <Romster> the distributed tracker is the solution to hammered trackers
            
-
            17:08 < jrandom> legion: that can easily be remedied by people using different trackers :)
            
-
            17:08 <+fox> <Romster> azerius DHT
            
-
            17:08 < jrandom> code is expensive, using different URLs is cheap
            
-
            17:08 <+legion> yeah, but they don't seem to be doing that do they?
            
-
            17:09 < jrandom> but, yes, a distributed tracker would be great.  not on my roadmap though, but if someone gets it going, that would Rule.
            
-
            17:09 <+Complication> In due time... surely someone can go distributed too.
            
-
            17:09 <+legion> Instead of of posting torrents to tracker sites, they could post a bith and whatever details to their eepsite.
            
-
            17:10 < jrandom> bith == hash?
            
-
            17:10 <+legion> yeah, stands for bittorrent hash, not my term
            
-
            17:10 <+Complication> In the beginning, though... a simple and solid client, in Java, bundled with the router... can solve many problems. (Perhaps even pull signed updates without overloading dev.i2p.)
            
-
            17:11 <+legion> yeah, that would be great
            
-
            17:11 < jrandom> aye Complication 
            
-
            17:11 <+fox> <Romster> yeah torrent updates
            
-
            17:11 <+fox> <Romster> ok next item ont he list :)
            
-
            17:12 < jrandom> ok, 5) more on bootstrapping
            
-
            17:12 <+legion> yeah lets move on
            
-
            17:12 < jrandom> lots of interesting stuff on the list as of late, and no way am i going to summarize it all here :)
            
-
            17:12 <+fox> <Romster> bootstraping the i2p router database?
            
-
            17:12 < jrandom> anyone have any questions/comments/concerns they want to discuss about the thread?
            
-
            17:12 < jrandom> Romster: see the list and/or email
            
-
            17:12 <+fox> * Romster needs to read that list
            
-
            17:13 < jrandom> aye, there's good stuff on there :)
            
-
            17:13 <+fox> <Romster> i've been rather busy laterly
            
-
            17:13 <+Complication> 26 messages to read through, can't comment yet
            
-
            17:13 < jrandom> still no end result, but we're looking towards a new way of building tunnels for 0.6.2
            
-
            17:14 <+fox> <Romster> a new way, is there a flay in the current method?
            
-
            17:14 <+fox> <Romster> flaw*
            
-
            17:14 < jrandom> Michael's analysis shows the attack is not really a problem now, as there are easier attacks on the alternatives
            
-
            17:14 < jrandom> read the list ;)
            
-
            17:14 <+fox> <Romster> arg later
            
-
            17:14 <+fox> <Romster> this is now :)
            
-
            17:15 <+fox> <Romster> i'm noramlly asleep at this time.
            
-
            17:15 <+fox> <Romster> so i rearly get to be at a meeting
            
-
            17:16 < cat-a-puss> can you post your ideas for a new way / existing / rejected ways in an email to the list so we can compare
            
-
            17:16 <+fox> <Romster> so its todo with attack methods and tunnel creation i assume, without reading the list yet
            
-
            17:16 < cat-a-puss> (that's for Jrandom)
            
-
            17:16 < jrandom> cat-a-puss: i'm not sure if we've really hashed out an end result yet
            
-
            17:16 <+fox> <Romster> be an idea cat-a-puss
            
-
            17:17 <+Complication> Romster: yes, it was more-or-less about giving the endpoint of an exploratory tunnel less influence as a possible attacker
            
-
            17:17 < jrandom> but http://dev.i2p.net/pipermail/i2p/2005-October/001073.html is the latest for what I see coming out of your suggestion
            
-
            17:17 < jrandom> well, not influence - i2p is a free route mixnet - but less information
            
-
            17:18 <+Complication> Yes, that would likely be a more correct term
            
-
            17:18 < jrandom> (the above linked url is full of arm waving, no solid crypto figured out yet)
            
-
            17:18 <+fox> <Romster> lesss = better for more robustness agenst attacks, i get what your geting at
            
-
            17:18 < jrandom> ((but i think its all doable with existing techniques)
            
-
            17:19 < jrandom> Romster: here's a plot of Michael's attack against the existing algorithm, with the X axist saying what % of the network is compromised - http://dev.i2p.net/~jrandom/fraction-of-attackers.png
            
-
            17:20 < jrandom> (plain telescopic building would be off the chart before hitting x=200)
            
-
            17:20 < jrandom> ((so what we have now is literally orders of magnitude better))
            
-
            17:20 < jrandom> but we can improve upon that further
            
-
            17:21 < jrandom> though there's also the garlic routing alternative too
            
-
            17:21 < jrandom> anyway, yeah, more things to be hashed out, keep an eye on the list :)
            
-
            17:21 <+fox> <Romster> ok i'll have a good read of that list later
            
-
            17:22 <+fox> <Romster> and see if i can think of anything too add
            
-
            17:22 < jrandom> cool
            
-
            17:22 < cat-a-puss> would the "new" telescopic method be fast enough to do on demand construction?
            
-
            17:22 < jrandom> I'm not sure we want that
            
-
            17:22 < jrandom> its the O(1) vs O(N) issue
            
-
            17:23 < jrandom> the new technique would allow tunnel creation without using the exploratory tunnels, leavng the exploratory tunnels for netDb operation 
            
-
            17:23 < jrandom> (and for exploratory tunnel creation :)
            
-
            17:24 <+fox> <Romster> hrmm would it be worthwhile screwing with the hackers by givving them heaps of false positives thereby masking the real source
            
-
            17:24 <+legion> sounds good :)
            
-
            17:24 <+legion> I'd think some screwing like that would be good
            
-
            17:24 < cat-a-puss> jrandom: right, I was asking if doing do would speed things up enough, so that sometimes that last hops don't know they are the last hop, as disguesed on list.
            
-
            17:25 <+fox> <Romster> exploratory tunnels to collect netDB router refereances?
            
-
            17:25 < jrandom> romster: we are the hackers ;)  but yeah, if the false positives overwhelmed the true positives, it'd require substantially large number of attacks to get statistically significant data
            
-
            17:26 < jrandom> hmm right cat-a-puss, but I'm not sure how that'd speed things up though, it'd move us from an O(1) to O(N) tunnel topology
            
-
            17:26 < jrandom> or what do you mean by speed things up?
            
-
            17:26 <+fox> <Romster> and if it got to the point of being detected it could then drop off and go silent forawhile?
            
-
            17:26 < jrandom> using the new technique would reduce the failed tunnel creations, certainly
            
-
            17:26 <+fox> <Romster> or mistearly change it's key and continue or something heh
            
-
            17:26 < jrandom> romster: it'd probably be worth digging through the mails to review the attack ;)
            
-
            17:27 <+fox> <Romster> yeah after sleep
            
-
            17:27 <+Complication> Romster: afaik, it's a passive attack mostly, so the target can't detect it occurring
            
-
            17:27 <+fox> <Romster> and fixing a friends pc i got sitting here
            
-
            17:27 <+fox> <Romster> ah ic complication.
            
-
            17:27 < cat-a-puss> jrandom: I'm not talking about the O(n) thing. I mean just waiting to construct a client tunnel until we need one for some apps, rather than just having them sit there all the time. 
            
-
            17:28 <+Complication> (but I might be wrong, and those last 26 messages might have active components)
            
-
            17:28 <+fox> <Romster> would a long term passive attack evently find the target?
            
-
            17:28 <+fox> <Romster> i'll comment after i've read the list
            
-
            17:28 < jrandom> ah cat-a-puss, we'll certainly improve the tunnel pooling for 0.6.2.  we currently only build the tunnel when we need it (giving ourselves a little time in case the creation fails)
            
-
            17:28 <+Complication> Romster: well, persisting the attack beyond tunnel lifetime would require resources and patience
            
-
            17:28 <+fox> <Romster> and understand it better
            
-
            17:29 <+Complication> But time plays a part in every probability of success. You try long, you get more chances.
            
-
            17:29 <+fox> <Romster> ah that's the idea tunnel life tiem be too short to actually have a worthwhile attack work.
            
-
            17:29 < jrandom> each pool has a defined number of backup tunnels, and we by default build replacements between 60-120 seconds before an old one expires
            
-
            17:29 <+fox> <Romster> time*
            
-
            17:30 < jrandom> right Complication - each sample occurs only 'm' times every (c/n) tunnels
            
-
            17:30 <+fox> <Romster> there is no interaction between each tunnel to gather stastics?
            
-
            17:30 <+fox> <Romster> as one is about to die and another is being built
            
-
            17:31 < jrandom> romster: the new tunnels do not talk to each other, no, but thats not the attack Michael has been describing
            
-
            17:31 < jrandom> there are countless attacks out there, most of which we have dealt with, but whenever someone comes up with one that may have a bearing on I2P's operation, we want to analyze it further
            
-
            17:31 <+fox> <Romster> must read the list, ok i'll leave it at that for now, anyone else got anything to say?
            
-
            17:32 < jrandom> ok, if there's nothing else, lets move on to 6) virus investigations
            
-
            17:32 <+fox> <Romster> actually one stastic i can see could be gathered is no 0 hop would mean that the next hop is not the end point so it could be ruled otu but with millions of nodes that analying technique would be useless
            
-
            17:33 < jrandom> I don't have anything to add beyond whats been discussed on the forum
            
-
            17:33 < jrandom> right Romster, there are predecessor attacks on tunnel length, which is one of the main things we're addressing in 0.6.2
            
-
            17:33 <+fox> <Romster> virus, what virus, if it's linux it'll be nonexistant, but windows hmmm
            
-
            17:34 <+Complication> Well, although I couldn't build a matching binary (hell knows hy) the final difference was small enough... to hopefully be useful to anyone interested in reading assembly code.
            
-
            17:34 < jrandom> Romster: please, the weekly status notes should explain these agenda items, and the meeting is to discuss things /beyond/ whats in the notes ;)
            
-
            17:35 <+Complication> I sure couldn't find anything obvious in there, but nor could I explain away all the difference.
            
-
            17:35 <@cervantes> rtfml and rtff
            
-
            17:35 <+fox> <Romster> yeah i haven't been upto speed for quite awhile, sorry about taht jrandom
            
-
            17:35 <@cervantes> ;-)
            
-
            17:35 < jrandom> aye, the fact that both a known safe bat file and the old one triggered the same detection code is substantial
            
-
            17:35 <+Complication> Yes, that sort of eases doubts.
            
-
            17:36 <+Complication> I guess the QBFC might have undocumented differences within the same version number (different builds?)
            
-
            17:37  * jrandom has no idea, but its possibly just some OS interaction, or whatever.  I don't know, you've put up enough analysis for people to make their own informed decision
            
-
            17:37 <+Complication> I think it's better that way.
            
-
            17:37 <+Complication> Disassembly is really notably outside my usual playground.
            
-
            17:37 < jrandom> legion: is there anything you want to mention about this, or should people just go through the forum if they want more info?
            
-
            17:38 <@cervantes> can I just re-iterate what others have said on the forum, and thank Complication for the time and maticulous attempts he's put in to checking this issue out
            
-
            17:38 < jrandom> aye, its much appreciated
            
-
            17:38 <+legion> I've nothing to add, I feel that I've said way too much about it already
            
-
            17:39 < jrandom> 'k understood.  ok, anyone else have anything to bring up on this, or shall we move on to 7) ???
            
-
            17:39 < jrandom> [consider us moved]
            
-
            17:40 <+fox> * Romster seconds that :)
            
-
            17:40 <+legion> ok for 7)??? how about we take a moment to discuss i2phex
            
-
            17:40 < jrandom> cool, good idea
            
-
            17:40 <+fox> <Romster> since i'm using it right now even :)
            
-
            17:40 <@cervantes> no no group hug first
            
-
            17:40 < jrandom> redzara mentioned he was going to be at the meeting, but progress on the merge is going slow
            
-
            17:41 <+legion> susi23 inquired about a headless version
            
-
            17:41 < jrandom> ah cool, i saw your post on that
            
-
            17:41 <+fox> <Romster> might i add the favourites list needs to be wider to cope with the longer i2p keys
            
-
            17:42 <+susi23> (that's no must, I was just curious about it)
            
-
            17:42 < jrandom> well, no one can remember base64 keys, so I'm not sure if you're missing much Romster ;)
            
-
            17:42 < jrandom> (and the first few bytes should be enough to uniquely identify them)
            
-
            17:42 <+fox> <Romster> starting i2phex with a server is the major problem i see so far
            
-
            17:42 <+legion> Actually I'd like to see only like the first 12 characters of keys to displayed in the client
            
-
            17:42 <+fox> <Romster> heh guess
            
-
            17:42  * Complication is regrettably majorly busy, and can't do no xml-rpc
            
-
            17:43 < jrandom> seems reasonable legion 
            
-
            17:43 <+fox> <Romster> what about display as many characters to make the key unique
            
-
            17:43 < jnymo_> I'm having good results with i2phex
            
-
            17:44 < jrandom> cool jnymo_, i've been hearing good things too
            
-
            17:44 <+fox> <Romster> so if 2 keys start with abc it'll be abcx
            
-
            17:44 < jnymo_> 12 identical characters isn't likely, romster
            
-
            17:44 <+fox> <Romster> true
            
-
            17:44 <+Complication> Besides, simpler = quicker
            
-
            17:44 <+fox> <Romster> but wouldnt need 12 if the keys are that far randomised
            
-
            17:45 <+Complication> (not that there is much speed to gain from displaying things)
            
-
            17:45 <+legion> Well maybe there could be a new host properties window, stating the full key and certain information like how much it is sharing and whatever
            
-
            17:45 <+susi23> (netdb works great with 4 chars only for router ids)
            
-
            17:45 <+fox> <Romster> or the database and using the keyname=base64 and only displaying the keyname
            
-
            17:45 < jrandom> hmm, i thought there was already a peer info display legion?
            
-
            17:46 < jrandom> legion: some things like that would be good to add to the mainline phex, most likely?
            
-
            17:46 <+legion> hmm could be right...
            
-
            17:46 < jrandom> (that way Gregor can maintain it ;)
            
-
            17:46 <+Complication> Well, there's a "Browse host" function, but that may not be the exact same thing. (If it works.)
            
-
            17:46 < jrandom> Complication: it does
            
-
            17:46 < jrandom> (work, that is)
            
-
            17:47 <+Complication> Seems to basically drop the host destkey into the search box
            
-
            17:47 <+Complication> ...and runs a search.
            
-
            17:48 < jnymo_> this may be an i2phex mainline issue, but I didn't see an ETA on i2phex downloads
            
-
            17:48 <+Complication> Hmm... or actually, doesn't run a search.
            
-
            17:48 <+Complication> Mine seems to wait until I manually start it.
            
-
            17:48 <+fox> <Romster> whats the nearby i2phex running tickbox for?
            
-
            17:49 <+legion> I see where there is plenty of room for improvement. ;)
            
-
            17:49 < jrandom> yep :)
            
-
            17:50 < jrandom> lots to be done, and the forum is a good place to post up ideas/suggestions/questions(/patches :)
            
-
            17:50 <+fox> <Romster> despite it's ovous name
            
-
            17:50 < jrandom> ok, anyone have anything else for the meeting?
            
-
            17:50 <+fox> <Romster> hmm good point
            
-
            17:50 <+fox> <Romster> can't think of anything else
            
-
            17:51 <+fox> <Romster> but anyone working on a distributed data store?
            
-
            17:51  * cervantes checks his watch
            
-
            17:51 <+fox> <Romster> like activtely
            
-
            17:51 < jrandom> Romster: beyond syndie, no
            
-
            17:51 < jrandom> (not to my knowledge, at least)
            
-
            17:52 <+legion> well I was wondering about integrating a http download manager into i2p, would make downloading larger content from eepsites easier.
            
-
            17:52 <+fox> <Romster> q and iphex and one or 2 others but i've not seen anything mentained for awhile now
            
-
            17:52 <@cervantes> what's the status of feedspace...I haven't heard aught of it in a while
            
-
            17:52 < jrandom> legion: that would be cool - there's a post about that on the forum too i think
            
-
            17:53 <+fox> <Romster> ah feedspace another one
            
-
            17:53 < jnymo_> if this was mentioned in the meeting already, nm.. but, is there news on i2p freenet colab?
            
-
            17:53 < jrandom> cervantes: last i heard frosk was kind of busy, but if frosk is around, maybe he can tell us more :)
            
-
            17:53 <+legion> Personally I'd like to see a i2p entropy colab.
            
-
            17:54 <+fox> <Romster> i have ideas for a datastore, but it be a expansion to existing methods that are in use currently
            
-
            17:54 <+legion> Given that q, feedspace and such don't seem to be going anywhere fast right now
            
-
            17:54 < jrandom> jnymo_: I've bounced the freenet folks some code to run on our SSU transport,toad has been joining in on some of the discussions, but freenet won't be in a position for us to run it as a data store on top of i2p for a while (after their 0.7 release comes out, most likely)
            
-
            17:54 <+fox> <Romster> i want to start a project but not go over what others have done already
            
-
            17:54 <+legion> wonder if it'd be possible to port entropy to run over i2p...
            
-
            17:54 < jrandom> legion: entropy would be good, but integration is kind of hard.  of course, people could run things like fproxy.i2p for entropy
            
-
            17:55  * jrandom doesnt know entropy's transport code at all
            
-
            17:55 <+fox> <Romster> i've put my irc client on hold, there is alot of them in progress already all i2p needs now is a datastore and it'll beat freenet with ease :)
            
-
            17:55 < jrandom> (but perhaps that'd be a good way to get someone to hack on the GCJ SDK :)
            
-
            17:56 < jrandom> Romster: helping out on other efforts is a lot more rewarding that starting brand new projects, as you get a lot more done with less effort :)
            
-
            17:56 < jnymo_> ah.. congrats on the gcj port
            
-
            17:56 <+fox> <Romster> entropy's is in c or C++ iirc
            
-
            17:57 < jrandom> right Romster, which is why they'd be able to use I2P's SDK and streaming lib, built with GCJ into native libraries
            
-
            17:57 <+fox> <Romster> jrandom true, but who :)
            
-
            17:57 < jrandom> not I
            
-
            17:57 <+legion> oh and on another issue, just like to mention that today I released a new version of my readme.html update for the i2p router console.
            
-
            17:57 < jrandom> (the only way to get something you care about done is for *you* to do it :)
            
-
            17:57 < jrandom> cool
            
-
            17:57  * dust would like to see some kind of 'squid' syndication for offloading eepsites
            
-
            17:58 < jrandom> dust: yeah totally, if we can get sucker into that position, that'd be ideal
            
-
            17:58 < jrandom> e.g. I'd love to get the latest info from orion in syndie, local
            
-
            17:58 <+fox> <Romster> build a proxy for squid to use :)
            
-
            17:59 <+legion> I'd been putting it of in the hope that certain improvements to the python eepsitechecker would have been made by now.
            
-
            17:59 < dust> ah, syndie
            
-
            17:59 < jrandom> (thats actually what syndie is for - syndication to cut down on load)
            
-
            17:59 < dust> _the_ answer
            
-
            17:59 < jrandom> there's a python eepsite checker?
            
-
            17:59 <+fox> <Romster> first i've heard about it
            
-
            17:59 <+legion> yeah, it's what I use ;)
            
-
            18:00 < jrandom> cool legion 
            
-
            18:00 <+legion> really? It's been around for awhile
            
-
            18:00 <+fox> <Romster> nice i'd like to check that out :)
            
-
            18:00 <@cervantes> think someone ported baffled's script... can't remember who/when
            
-
            18:00 <+fox> <Romster> i'm learning python
            
-
            18:00 < jrandom> ah ok cervantes 
            
-
            18:00 <+fox> <Romster> the hard way by examples and the manual :)
            
-
            18:00 < jrandom> yeah, i'm lazy, i just use polecat.i2p/i2psurvey/ and orion.i2p/ :)
            
-
            18:01 < jrandom> (no need for me to spider)
            
-
            18:01 <+legion> if someone would care to work with me on it, I'd really like to get the code fixed and working with either python 2.3 or 2.4
            
-
            18:01 <+fox> <Romster> i have 2.4 installed here
            
-
            18:01 <+Ragnarok> I may have a look at it.  Got link?
            
-
            18:01 <+fox> <Romster> actually think it's 2.4.1
            
-
            18:02 <+legion> right now it has no py2exe compatibility and half of it works with each version, which means anyone running it needs to have both installed.
            
-
            18:02  * jnymo_ would love to see an orion.i2p/I2PDirectory hybrid.. info, catagories, stats.. butter
            
-
            18:02 <+legion> I'll archive it after the meeting and post a link to the forums
            
-
            18:03 <+Ragnarok> ok
            
-
            18:03 < jrandom> legion: hmm, do you see lots of people needing to run that though?  I mean, only a few people need to spider
            
-
            18:03 <+fox> <Romster> both eck, might be a bit much for me to translate to the newer dunno untill i look at the code
            
-
            18:03 < jrandom> (not that there's anything wrong with making it easy for those few people, that is :)
            
-
            18:04 <+fox> <Romster> cold be disected and used todo other things too?
            
-
            18:04 <+legion> Well thing is I can see where there could be some uses for everyone that runs i2p.
            
-
            18:04 <+fox> <Romster> could*
            
-
            18:04 < jrandom> hmm, I'm not so sure, could you explain how?
            
-
            18:04 < jrandom> I mean, I don't want everyone to essentially DDoS every eepsite
            
-
            18:05 <+legion> One of which would be a dynamic bookmarks page, that is auto generated every 12-24 hours or so.
            
-
            18:05 < jrandom> ah, that is trivial in syndie (actually one of the main features - 'new blogs')
            
-
            18:05 < jrandom> ((but of course, syndie doesn't have a great ui for that yet))
            
-
            18:06 <+fox> <Romster> actually would only need a few to spider and throw it into a torrent/dht like database and sync that between nodes
            
-
            18:06 < jrandom> right Romster (though that torrent/dht-like database to sync, or "syndi"cate, could be syndie ;)
            
-
            18:06 <+fox> <Romster> could even be a hidden way to learn more i2p nodes and services
            
-
            18:07 <+fox> <Romster> yeah or syndie
            
-
            18:07 < jrandom> ok, anyone else have anything for the meeting?  the curry is getting cold ;)
            
-
            18:08 <+fox> <Romster> if syndie is going tobe that great one could store static pages to cashe and the same with images
            
-
            18:08 <+fox> <reliver> bon appetit, jrandom :-)
            
-
            18:08 < jrandom> exactly romster, you can do that now 
            
-
            18:09 < jrandom> ok, if there's nothing else...
            
-
            18:09  * jrandom winds up
            
-
            18:09  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting154.html b/www.i2p2/pages/meeting154.html
deleted file mode 100644
index 7330195c..00000000
--- a/www.i2p2/pages/meeting154.html
+++ /dev/null
@@ -1,182 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 154{% endblock %}
-{% block content %}
            I2P dev meeting, November 1, 2005
            
-
            
-
            15:04 < jrandom> 0) hi
            
-
            15:04 < jrandom> 1) 0.6.1.4 and net status
            
-
            15:04 < jrandom> 2) boostraps, predecessors, global passive adversaries, and CBR
            
-
            15:05 < jrandom> 3) i2phex 0.1.1.34
            
-
            15:05 < jrandom> 4) voi2p app
            
-
            15:05 < jrandom> 5) syndie and sucker
            
-
            15:05 < jrandom> 6) ???
            
-
            15:05 < jrandom> 0) hi
            
-
            15:05  * jrandom waves
            
-
            15:05 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-November/001186.html
            
-
            15:05 < jrandom> (lets see if this cat will let me use both hands to type...)
            
-
            15:06 < jrandom> ooh, looks like we're a few minutes early (damn clock skew), but maybe this'll make up for being a few minutes late before ;)
            
-
            15:07 < jrandom> anyway, jumping into 1) 0.6.1.4 and net status
            
-
            15:08 < jrandom> I don't have much to add beyond whats in the status notes
            
-
            15:08  * cervantes is waiting till the correct time to say hi
            
-
            15:08 < jrandom> heh
            
-
            15:09 < jrandom> you've got 19 seconds, acording to timeanddate.com :)
            
-
            15:09 <@cervantes> hi
            
-
            15:09 < jrandom> ;)  ok, anyway, anyone have any comments/concerns on 0.6.1.4?  from what i can see, its gone prety well
            
-
            15:10 <+Complication> Counted 747.6 routers today :P
            
-
            15:10 < jrandom> yeah, we've had a higher churn than usual lately
            
-
            15:10 < jrandom> still getting a bunch of referrers in from that digg / gotroot article
            
-
            15:10 <+Complication> And one trick to "knowing" more peers is simply restarting less often :)
            
-
            15:10 < jrandom> heh true enough
            
-
            15:10 <@cervantes> *cough*sourceforge*cough*
            
-
            15:11 <+polecat> I've had some trouble with number of participating tunnels dropping abruptly now and again.  Might be that darn NAT thing.
            
-
            15:11  * jrandom cringes.  have you had many referrers from sf cervantes?
            
-
            15:11 <+Complication> cervantes: you mean *that* SourceForge page? :eek:
            
-
            15:11  * cervantes doesn't log referrers
            
-
            15:11 < jrandom> hmm polecat, could be a problem with your nat, but dropping the # of participating tunnels isn't really a bad thing - it /should/ do that 
            
-
            15:11 < jrandom> ah ok cervantes 
            
-
            15:12 <+polecat> Really?  I thought lots of participating tunnels was good.
            
-
            15:12 <+Complication> polecat: mine used to drop them rapidly when it exceeded practically usable bandwidth
            
-
            15:12 <@cervantes> I make a point of only logging the minimum required to debug forum issues ;-)
            
-
            15:12 <@cervantes> since folk seem touchy on the subject
            
-
            15:12 <@cervantes> I've noticed...
            
-
            15:13 < jrandom> polecat: sure, but the # should drop if your machine gets loaded or otherwise acts funky
            
-
            15:13 < jrandom> reasonable enough cervantes 
            
-
            15:13  * jrandom logs everyone's mother's maiden name, to remind people not to trust anyone ;)
            
-
            15:14 < jrandom> (or do I?  you'll never know ;)
            
-
            15:15 < jrandom> polecat: is your nat just randomly restarting, or losing its ip address, or something else?
            
-
            15:15 <@cervantes> yeah I might change my mind on that issue....it's way too much fun seeing where everyone follows links from :P
            
-
            15:16 < jrandom> its how i found the got-root and digg articles :)
            
-
            15:16 < dust> i've noticed better network throughput lately, or it it just me imagining things again?
            
-
            15:17 < jrandom> it should be better, especially for short lived connections (e.g. http responses)
            
-
            15:18 < jrandom> otoh, its not as much of an improvement as i had hoped, so there's still work to be done on that front
            
-
            15:18 < dust> e.g. i2phex pretty much takes any limit i give it if i give it enough parallel transfers
            
-
            15:18 < jrandom> nice
            
-
            15:20 < dust> per-tunnel seems limited <~10k/s
            
-
            15:20 < dust> or per-transfer
            
-
            15:20 <+polecat> Okay, my machine does get loaded now and again.
            
-
            15:21 <@cervantes> have any of the folk on bandwidth restricted connections noticed improvement?
            
-
            15:22 < jrandom> hmm right, 10KBps per stream seems ballpark to what i'm seeing as well
            
-
            15:22 < jrandom> cervantes: i think we scared 'em all away (but if anyone with a modem or Really Shitty Connection wants to give it a try and report back, it'd be appreciated :)
            
-
            15:23 < jrandom> ok, if there's nothing else on 1), lets move on to 2) boostraps, predecessors, global passive adversaries, and CBR
            
-
            15:23 < jrandom> there's been lots of discussion on this fron over the mailing list (october had more posts than any other month since i2p started!)
            
-
            15:24 < defnax> did anywere looked eepsites.i2p?
            
-
            15:24 < jrandom> beyond whats in the status notes, i'm not sure what i have to add at the moment.  anyone have any questions/comments/concerns?
            
-
            15:24 <@cervantes> I think you've successfully generated full tunnel CBR by maintaining a constant level of i2plist mails
            
-
            15:24 < jrandom> heh cervantes 
            
-
            15:24 < jrandom> defnax: yeah, it looks neat, a nice database growing there
            
-
            15:25 < jrandom> same with tino.i2p
            
-
            15:25 < defnax> but i dont like it
            
-
            15:25 <+polecat> Hey, I'm on a bandwidth restricted connection!  i2p gets 10K/s up and 32K/s down.  :)
            
-
            15:26 < defnax> www.eepsites.com then can all normal users on internet search for i2p sites
            
-
            15:26 < defnax> and mpaa or riaa can browse what sites avaible and 
            
-
            15:26 < jrandom> so?
            
-
            15:26 < jrandom> mpaa/riaa/etc can just run i2p if they want to see whats on i2p
            
-
            15:26 < jrandom> w3wt polecat 
            
-
            15:27 < jrandom> (jesus, some sick search queries @ eepsites.com...)
            
-
            15:27 < defnax> thats not good for anonnymity
            
-
            15:27 < defnax> then all users now where can find torrents on I2P eepsites
            
-
            15:27 < jrandom> defnax: same with tino.i2p
            
-
            15:27 <@cervantes> I like the faux google ads on eepsites.i2p.... but anyway, digression
            
-
            15:27 < jrandom> defnax: thats not good for /secrecy/.  thats different from anonymity.
            
-
            15:27 < jrandom> people hosting public eepsites should expect that anyone can view their eepsites
            
-
            15:28 < jrandom> if they want to restrict who can access it, they should do so
            
-
            15:28 < jrandom> yeah definitely cervantes :)
            
-
            15:28 <+polecat> Anyone who wants a private eepsite, just don't give it a name in hosts.txt.  Problem solved!
            
-
            15:28 < defnax> but normal internet users must dont know which eepsites is avaible!
            
-
            15:28 < jrandom> polecat: thats not entirely sufficient
            
-
            15:29 <+polecat> Really?
            
-
            15:29 < jrandom> i'm sorry, perhaps I misunderstand defnax.  why shouldn't people know what eepsites are available?
            
-
            15:29 < defnax> i know it then not listend in a search enigine when dont make eespite public
            
-
            15:29 <+polecat> I thought it was a brute force sweep through the base64 keyspace to find eepsites...
            
-
            15:29 < jrandom> polecat: right, someone can harvest the netDb
            
-
            15:29 < defnax> i think this person dont need I2P
            
-
            15:29 < jrandom> well, harvesting for leaseSets is substantially more work than harvesting for routers...
            
-
            15:30 < jrandom> defnax: I'm sorry, I don't understand
            
-
            15:30 < jrandom> eepsites.com is a public interface to a search engine across public eepsites.  nothing private is being revealed
            
-
            15:30 <@cervantes> lol @ last 5 searches
            
-
            15:30 <+Complication> Yep, the "last searches" box suggests someone (ironically someone who is probably non-anonymous) is a tiny bit sick.
            
-
            15:30 <+Complication> Ah, whatever.
            
-
            15:30 < defnax> i mean he dont need I2P ! he tells on public IP on which eespites are torrents or other things avaible!
            
-
            15:31 < defnax> on I2P is ok , but not on normal internet
            
-
            15:31 < jrandom> defnax: sure, that person running eepsites.com does not themselves require i2p.  you can find out their home address, phone number, etc.
            
-
            15:31 < jrandom> but, on the other hand, same goes for forum.i2p.  
            
-
            15:31 < jrandom> (and to some extent, www.i2p, though that doesn't give you /my/ info ;)
            
-
            15:32 < jrandom> some sites are public.  thats fine.  thats neat.  
            
-
            15:32 <+fox> <jme___> defnax, what attacks is possible thanks to this site, which isnt without this site ?
            
-
            15:32 <@cervantes> Complication: snigger
            
-
            15:32 < jrandom> they're offering a potentially useful service to people who may want to try out i2p before installing
            
-
            15:33 < defnax> ok any news from I2Psnark? 
            
-
            15:33 <+Complication> cervantes: yeah, nothing like good old irony :)
            
-
            15:33 < defnax> i will become before 0.6.2 a webinterface/gui?
            
-
            15:33 <@cervantes> defnax: there's been an i2p inproxy for several months
            
-
            15:33 < jrandom> defnax: nope, but I suppose we should jump forward in the agenda before we hit 6) ???
            
-
            15:33 < jrandom> ok, is there anything else on 2) boostraps, predecessors, global passive adversaries, and CBR?
            
-
            15:34 < jrandom> or shall we move on to 3) I2Phex 0.1.1.34
            
-
            15:34 < jrandom> [consider us moved]
            
-
            15:35 < jrandom> ok, those not yet on 0.1.1.34 should upgrade, as there's some important stuff in the release.  Those already on 0.1.1.34 who want to help test out some not-yet-released improvements, there's further work in CVS, so if you try that out and run into troubles, please post on the forum
            
-
            15:36 < jrandom> in other news, I've heard some good progress on the gwebcache front as well, but no word on its integration with i2phex yet
            
-
            15:36 < jrandom> redzara: any word on the merge?
            
-
            15:37 <+Complication> The post .34 cvs improvements seem to make the GUI *much* more responsive.
            
-
            15:38 < jrandom> cool, yeah, I couldn't handle the <= ..34 responsiveness, but i'm not sure if the fixes are entirely regression-free, since i don't really understand all the code.  but it /seems/ ok :)
            
-
            15:42 <+redzara> jrandom : sorry, but we have just change hour time in France to Winter Time and work is near finished for I2phex, I've just to track 2 or 3 bugs
            
-
            15:43 < jrandom> ah cool!
            
-
            15:43 < jrandom> no rush, just wondering
            
-
            15:44 <+redzara> and maybe I've to get lastest I??phex code to see if GregorK's mod apply to lastest phex code ?!?
            
-
            15:45 < jrandom> yeah, disabling the remote request functionality will be required, but it was a trivial two line fix (comment out MAGMA and URI requests).
            
-
            15:45 < jrandom> same for the latest synchronization issue (remove unnecessary locks on network operations)
            
-
            15:46 <+fox> <jme___> I??phex <- interesting how typo can reveal location too :)
            
-
            15:46 < jrandom> not as much as "in France" does ;)
            
-
            15:46 <+redzara> this is already done in my code
            
-
            15:46 <@cervantes> hehe
            
-
            15:46 < jrandom> (but thats another bug thats not yet fixed... the irc charset stuff)
            
-
            15:46 < jrandom> ok cool redzara 
            
-
            15:47 <+redzara> jme___ : I don't search to hide my location, you konw :-)
            
-
            15:47 <+redzara> so nothing more to say about i2phex for me
            
-
            15:47 <+fox> <jme___> redzara, ok :) 
            
-
            15:48 < jrandom> ok great, thanks for the update
            
-
            15:48 < jrandom> anyone else have anything on i2phex, or shall we move on to 4) voi2p app?
            
-
            15:49 <+redzara> consider we are moving :)
            
-
            15:49 < jrandom> for 4), I'm not sure if I've got anything to add beyond whats in the mail, and it seems aum has disconnected, so we'll probably have to wait for an update at a later time
            
-
            15:49 < jrandom> (unless someone else has something to discuss for 4)?)
            
-
            15:50 < jrandom> if not, consider us moved to 5) syndie and sucker
            
-
            15:50 < jrandom> dust: wanna give us the word?
            
-
            15:51 <@cervantes> so is syndie good at sucking now?
            
-
            15:51 < jrandom> yes *cough*
            
-
            15:51 < dust> heh
            
-
            15:52 < dust> well, the note says pretty much it
            
-
            15:52 < dust> there are still stuff to do
            
-
            15:53 < dust> word on the testing and reporting of bugs
            
-
            15:54 < jrandom> ok great, do you know offhand what the story with rome-0.8 is?  worth waiting for a pending release, or should we grab a cvs build and upgrade it later?
            
-
            15:55 <+fox> <brutus> oi, how about the auto ping-pongin' ircProxy, any progrssthat?
            
-
            15:55 < jrandom> no progress i know of
            
-
            15:55 <+fox> <brutus> (ups, sry)
            
-
            15:55 <+polecat> voi2p, make a mp3 of your voice and i2p bittorrent it.
            
-
            15:56 < dust> no, dunno the eta on next rome
            
-
            15:56 < dust> i couldn't get to the cvs
            
-
            15:57 < dust> (i don't remember why)
            
-
            15:57 < jrandom> ah 'k, well, we don't need it yet, it'd just be neat.  a later date then
            
-
            15:58 < jrandom> ok, anyone have anyhing else on 5)? or shall we move on to 6) ???
            
-
            15:59 < jrandom> [consider us moved]
            
-
            15:59 <@cervantes> brutus: I don't beleive anything has been done concerning that
            
-
            16:00 < dust> should it be done?
            
-
            16:01 <+fox> <brutus> oki, yeah, i guess it's pretty low priority as well
            
-
            16:01 <+polecat> I still want to know how we could make i2p, and anonymity techniques in general, more accessible in poor or dangerous places.
            
-
            16:01 < jrandom> polecat: by getting someone with a dialup connection to help test ;)
            
-
            16:01 <@cervantes> free rifle with every installation?
            
-
            16:02 < jrandom> polecat: we're definitely working on that, but we have so, so much more to do first.
            
-
            16:02 < jrandom> dust: the irc thing?  might be worthwhile, but sucker improvements are probably more important
            
-
            16:02 < jrandom> (imho)
            
-
            16:03 <@cervantes> (somewhat biases opinion ;-)
            
-
            16:03 <@cervantes> *biased
            
-
            16:03 < jrandom> true that, but i think my bias is Right :)
            
-
            16:04  * cervantes notes the capital lettering ;-)
            
-
            16:05  * Complication looks at the phone socket, and wonders if anything good can come of such <things> :D
            
-
            16:05 <+Complication> Then again, if DSL travels over it, it cannot be inherently evil. :D
            
-
            16:05 <+polecat> No... not Things!
            
-
            16:05 <@cervantes> Complication: you can also use it to call people....
            
-
            16:06 < jrandom> ok, anyone have anything else for 6) ???
            
-
            16:07  * cervantes wasn't sure we had anything for ??? in the first place
            
-
            16:07 < jrandom> in that case... 
            
-
            16:07  * jrandom winds up
            
-
            16:08  * jrandom *bafs* the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting155.html b/www.i2p2/pages/meeting155.html
deleted file mode 100644
index 67558f02..00000000
--- a/www.i2p2/pages/meeting155.html
+++ /dev/null
@@ -1,66 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 155{% endblock %}
-{% block content %}
            I2P dev meeting, November 8, 2005
            
-
            
-
            15:21 < jrandom> 0) hi
            
-
            15:21 < jrandom> 1) Net status / short term roadmap
            
-
            15:21 < jrandom> 2) I2Phex
            
-
            15:21 < jrandom> 3) I2P-Rufus
            
-
            15:21 < jrandom> 4) I2PSnarkGUI
            
-
            15:21 < jrandom> 5) Syndie
            
-
            15:22 < jrandom> 6) ???
            
-
            15:22 < jrandom> 0) hi
            
-
            15:22  * jrandom waves
            
-
            15:22 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2005-November/001206.html
            
-
            15:22  * bar mumbles greetings from behind his/her false(?) beard
            
-
            15:23 < jrandom> ok, jumping into 1) Net status / short term roadmap
            
-
            15:23 < jrandom> Not much to say beyond whats in the mail - hopefully a new release later this week, or this weekend
            
-
            15:24 < jrandom> there are some new optimizations in cvs which should help improve reliability, and its worked pretty well in the tests i've done, but it probably won't have much of an impact until it gets widespread deployment
            
-
            15:25 < jrandom> I also haven't picked an arbitrary throughput level I want to reach before continuing on to 0.6.2, though my gut instinct tells me that optimizations should continue until I can justify the choke points by per-router hop delays
            
-
            15:26 < jrandom> right now, however, that isn't our choke point, so there's still work to be done.
            
-
            15:26 < jrandom> I don't have much more to add on that front - anyone have any questions/comments/concerns?
            
-
            15:28 < jrandom> ok, if not, moving on to 2) I2Phex
            
-
            15:28 < jrandom> I don't have much more to add here beyond whats been said in the email.  There have been a bunch of discussions on the forum too, though, so swing by there for more news and ranting 
            
-
            15:31 < jrandom> ok, if not, jumping on over to 3) I2P-Rufus
            
-
            15:31 < jrandom> this bullet point was really just me repeating a rumor, but we'll see how things go
            
-
            15:32 < jrandom> Rawn / defnax: do you have anything to add?
            
-
            15:35 < tealc_> whats i2p-rufus ?
            
-
            15:35 < jrandom> a port of the rufus bittorrent client for I2P (http://rufus.sourceforge.net/)
            
-
            15:36 < jrandom> ok, if there's nothing else, we can jump to another quick rumor reportage - 4) I2PSnarkGUI
            
-
            15:37 < jrandom> I don't have much to add to this beyond saying "hey, cool" :)
            
-
            15:38 <+bar> yeah, looks nice
            
-
            15:38 <@frosk> snark is Y.A. BT client?
            
-
            15:38 < jrandom> yeah, but snark is a bittorrent client bundled with I2P :)
            
-
            15:38 <@frosk> oh yeah, right :)
            
-
            15:38 < jrandom> (currently a command line tool, but multitorrent and web interface is on the way, though not imminent)
            
-
            15:39 <+fox> <ZipTie> who was doing the work for the rarest-first fetching strategy for snark? did that ever get done?
            
-
            15:39 < jrandom> yeah, Ragnarok implemented that
            
-
            15:39 < jrandom> its in the current I2PSnark
            
-
            15:39 <+fox> <ZipTie> cool
            
-
            15:40 < jrandom> aye, quite
            
-
            15:41 <+fox> <ZipTie> is i2p-bt going to be decomissioned then in favor of either rufus or snark?
            
-
            15:41 < jrandom> thats for users to decide
            
-
            15:42 <+fox> <ZipTie> or maintainability :)
            
-
            15:42 < jrandom> personally, I think if snark gets a web interface, integrated with the router console, multitorrent capabilities, and offers equivilant performance as the others, it'll be in good shape
            
-
            15:43 < jrandom> but really, what you mention is the key - who does the maintenance and development is the driving force
            
-
            15:43  * jrandom does not maintain python apps
            
-
            15:44 < jrandom> ok, if there's nothing else on 4, lets move on to 5) Syndie
            
-
            15:45 < jrandom> I've been doing some usability research into how best to proceed, and I think we've got a pretty viable UI on the way, but if you've got an opinion, post it up on syndie or the forum and we can hopefully take it into consideration
            
-
            15:46 < tealc_> ahh, i thought i2phex was java.. the stuff on the forums offers .exe installers and .exe's in zips
            
-
            15:47 < jrandom> i2phex is java
            
-
            15:47 < jrandom> and the .exe works with any platform that java works on
            
-
            15:47 < jrandom> java -jar i2phex.exe
            
-
            15:47 < jrandom> (yes, really)
            
-
            15:49 < jrandom> (cough)
            
-
            15:49 < jrandom> dust: anything to add re: syndie stuff?
            
-
            15:50 < dust> nope
            
-
            15:50 < jrandom> ok cool.  unless anyone else has anything on it, lets jump to ol' faithful: 6) ???
            
-
            15:50 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            15:53 <+fox> <reliver> is the paella ready ? ;-)
            
-
            15:53  * jrandom grabs a spork
            
-
            15:54 < jrandom> (on that note...)
            
-
            15:54 <+fox> <reliver> and the cat still smells like cats ;?)
            
-
            15:54  * jrandom windos up
            
-
            15:54  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting156.html b/www.i2p2/pages/meeting156.html
deleted file mode 100644
index eb494335..00000000
--- a/www.i2p2/pages/meeting156.html
+++ /dev/null
@@ -1,351 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 156{% endblock %}
-{% block content %}
            I2P dev meeting, November 15, 2005
            
-
            
-
            15:15 < jrandom> 0) hi
            
-
            15:15 < jrandom> 1) Net status / 0.6.1.5
            
-
            15:15 < jrandom> 2) Syndie updates
            
-
            15:15 < jrandom> 3) I2Phex
            
-
            15:15 < jrandom> 4) I2P-Rufus
            
-
            15:15 < jrandom> 5) Issue tracker
            
-
            15:15 < jrandom> 6) Dynamic Keys
            
-
            15:15 < jrandom> 7) ???
            
-
            15:15 < jrandom> 0) hi
            
-
            15:15  * jrandom waves
            
-
            15:16 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-November/001210.html
            
-
            15:17 <+bar> yalla! *fires some rounds into the air*
            
-
            15:17  * jrandom ducks and covers, diving into 1) Net status / 0.6.1.5
            
-
            15:18 < jrandom> as mentioned in the mail, there's been a lot of progress, and there should be a new release later tonight
            
-
            15:18  * jrandom would have released it earlier, but I slept late and didn't want everyone upgrading /during/ the meeting :)
            
-
            15:20 < jrandom> anyone have any questions/comments/concerns re: 1) net status / 0.6.1.5?
            
-
            15:20 <+fox> <ailouros> is "please keep up the good work" an acceptable comment?
            
-
            15:20 < jrandom> :) thanks
            
-
            15:22 < jrandom> I've been pretty happy with the stability as of late.  hopefully the next release will improve throughput beyond 4-8KBps/stream.  I've done plenty of local testing, but we need to see it out in the wild
            
-
            15:22 < tethra> i second ailouros's comment, and furthermore, propose a toast:
            
-
            15:22 < jrandom> we've also had some more positive reports from users on dialup connections
            
-
            15:22 < tethra> to jrandom, and i2p! woot!
            
-
            15:22 < tethra> <3
            
-
            15:23 < jrandom> w3wt.  ok, if there's nothing else, lets jump on over to 2) Syndie updates
            
-
            15:24 < jrandom> lots of progress on this front, but perhaps it'll be best to discuss it after the release when people can try it for themselves
            
-
            15:25 < jrandom> hopefully the info up @ http://syndiemedia.i2p.net/about.html (the first link) can explain why you should bother trying it out :)
            
-
            15:25 <+fox> <ailouros> oh come on, first you don't release it, then you say "try it first"... this is just teasing! :D
            
-
            15:25 < jrandom> :)
            
-
            15:26 < jrandom> ok ok, so lets just jump ahead to 3) I2Phex then, so y'all can post up your thoughts about syndie to syndie itself after you upgrade ;)
            
-
            15:27 < jrandom> there's going to be an announcement for I2Phex 0.1.1.36 later tonight
            
-
            15:28 < jrandom> the only change is the fix for the annoying "Please insert a disk" popup
            
-
            15:28 < tethra> that means i can take the disk out the drive without it screaming at me, then? ;)
            
-
            15:28 < jrandom> heh yes
            
-
            15:28 < tethra> :D
            
-
            15:30 < jrandom> ok, if there's nothing more on 3) I2Phex, lets jump on over to 4) I2P-Rufus
            
-
            15:30 < tethra> what are the plans for i2phex, while we're on the subject?
            
-
            15:30 < jrandom> ah
            
-
            15:30 < jrandom> there's a set of feature requests posted to the forum
            
-
            15:31 < jrandom> I haven't heard anything from redzara about the code merge with Phex, but Gregor is still working on abstracting the networking stuff so we can more easily keep in sync
            
-
            15:32 < jrandom> generally, the app seems functional, though gwebcache support would be Really Good, so that I2Phex could work out of the box without needing to fetch any files or keys
            
-
            15:32 < jrandom> I don't know anyone working on getting gwebcache support (back) into I2Phex, but if someone knows java, that'd be Really Useful
            
-
            15:33 < tethra> cool.
            
-
            15:33 <+fox> <reliver> _007pig perhaps ?
            
-
            15:33 <+fox> <ailouros> sorry if I ask, but wasn't gnutella network the one that flooded itself to death some time ago?
            
-
            15:33 < tethra> the new guys do tend to be a bit confused about it at first
            
-
            15:33 <+fox> <reliver> you did not take him up on his offer for help, yesterday, jrandom
            
-
            15:33 < jrandom> _007pig was looking into translation work, but anyone would be great.  Phex itself has gwebcache support, but sirup disabled it
            
-
            15:34 < jrandom> ailouros: gnutella is still around, but yeah, its not ideal.
            
-
            15:34 < tethra> is anyone looking into perhaps changing the protocol i2phex uses to something else?
            
-
            15:35 < jrandom> I'm hesitant to demand people work on specific projects, so I instead suggest a few different areas that someone could explore
            
-
            15:35 < jrandom> tethra: no one that I know of
            
-
            15:35 <+fox> <ailouros> well, I think I'd rather see Localhost (azureus modification) on i2p then
            
-
            15:36 < tethra> surely bittorrent is more awkward than gnutella?
            
-
            15:36 < tethra> in terms of seeding and such
            
-
            15:36 < jrandom> ailouros: whatever people implement and maintain is good :)
            
-
            15:36 <+fox> <ailouros> I don't know, I didn't use gnutella since... 6 years I think
            
-
            15:37 < anti> surely it is more efficient and better test of true scalability?
            
-
            15:37 <+fox> <ailouros> jrandom yeah that's a good metric :D
            
-
            15:37 < jrandom> i2phex works pretty well, I've transferred lots of data through it, and found some neat content
            
-
            15:37 <@cervantes> (pony pr0n)
            
-
            15:37 <+fox> <ailouros> lol
            
-
            15:37 < tethra> hahah
            
-
            15:37 < jrandom> there may be better ways to do things, but something that works is better than something that doesn't exist
            
-
            15:37 < tethra> cervantes++
            
-
            15:37 < tethra> ;)
            
-
            15:38 < tethra> truer words have never been spoken.
            
-
            15:39 < anti> good point
            
-
            15:39 <@cervantes> uhoh... jr has taken offense and gone early to dinner
            
-
            15:39 <@cervantes> (sorry)
            
-
            15:39 < anti> no, he's probably searching for that (mythical) pony pr0n. ;)
            
-
            15:40 < jrandom> *cough* ;)
            
-
            15:40 < tethra> lol 
            
-
            15:40 < tethra> heheh ;)
            
-
            15:40 < jrandom> ok, if there's nothing else on 3), lets move on to 4) I2P-Rufus
            
-
            15:40 <+fox> <reliver> i want flying pony pr0n :-)
            
-
            15:40 < jrandom> Rawn / defnax: anything to add to what was posted on the forum?
            
-
            15:41 <@cervantes> looks like some good progress is being made
            
-
            15:41 < jrandom> aye
            
-
            15:45 < jrandom> ok, if there's nothing on that, lets jump on to 5) issue tracker
            
-
            15:45 < jrandom> the forum is a bit heavyweight for managing bugs and feature requests, and bugzilla is a bit of a beast... 
            
-
            15:46 <@frosk> isn't there a bugzilla already somewhere?
            
-
            15:46 < jrandom> i've posted up some general requirements, and cervantes has come up with one workable solution
            
-
            15:46 < jrandom> nah, the bugzilla was on the old host (@johnscompanies) before we migrated to sago
            
-
            15:46 <+fox> <ailouros> hot about NNTP? better than forums, usually threaded...
            
-
            15:46 <+fox> <reliver> strange that bugzilla is so lacking, considering the huge open source community using it ...
            
-
            15:46 <+fox> <ailouros> how*
            
-
            15:46 <@frosk> ah ok
            
-
            15:47 < jrandom> nntp has potential, but there are some benefits over that by using syndie (simple filtering by tag): http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&
            
-
            15:48 < jrandom> but nntp does have the benefits of having decades of battle testing
            
-
            15:48 <+fox> <ailouros> NNTP reader filter by keyword (the [] tags)? :D
            
-
            15:49 <@modulus> perhaps not so much testing of late?
            
-
            15:49 <+fox> <reliver> including spamming and flaming ...
            
-
            15:49 < jrandom> we'd want something web accessible though, since most people don't use nntp readers
            
-
            15:49 <+fox> <ailouros> I say Thunderbird is good in that sense, and you can share the enigmail between i2mail and i2nntp
            
-
            15:49 <@modulus> maybe a web accessible nntp reader?
            
-
            15:49 <+fox> <reliver> gateways are common
            
-
            15:49 < jrandom> hmm modulus?
            
-
            15:50 <@modulus> well, usenet is not so much used anymore i think
            
-
            15:50 < jrandom> right, so we'd have to have an nntp server and a gateway with filtering support
            
-
            15:50 <@frosk> i like cervantes' idea though
            
-
            15:50 <+fox> <ailouros> (and I also say the reason people don't use NNTP readers is because forums are so much prettier and so much heavier)
            
-
            15:50 <@modulus> hmm, gateway with filtering support? what are you guys talking about, maybe it helps knowing. :-)
            
-
            15:51 <@modulus> imo forums suck, i hate fucking forums, they're unusable ;-(
            
-
            15:51 <+fox> <ailouros> LOL I guess he wants the access from the InterNEt
            
-
            15:51 <+fox> * ailouros agrees with modulus
            
-
            15:51 <@frosk> modulus: so very true
            
-
            15:51 < jrandom> heh modulus ;)  we're discussing http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003&
            
-
            15:51 <+fox> <ailouros> aieee the megabyte long URI
            
-
            15:52 <@modulus> what I love about syndie URLs is how memorable and simple they are to type
            
-
            15:52 < jrandom> I do still like http://syndiemedia.i2p.net:8000/threads.jsp?post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&
            
-
            15:52 < jrandom> heh
            
-
            15:52 < jrandom> well, go to http://syndiemedia.i2p.net/threads.jsp then and click on the "Issue tracking software" link :)
            
-
            15:53 <@frosk> bug reporting right from your router console
            
-
            15:53 <@modulus> hmm, bug tracking.
            
-
            15:53 < jrandom> using syndie would give us 1) integration with every I2P user's environment 2) trivial filtering 3) threading 4) spam handling (via ignore/favorites) 5) syndie a workout :)
            
-
            15:54 <+fox> <reliver> sounds great :-)
            
-
            15:54 <+fox> <ailouros> it is
            
-
            15:54 < jrandom> aye that is a really good feature frosk... we could even have specialized html forms to post to /syndie/post.jsp
            
-
            15:54 <+fox> <ailouros> and by the way, wasn't there talk about basing syndie on NNTP? :D :D :D
            
-
            15:54 <@modulus> hmm, how about the Debian bug tools? they're nice i think, the mailbug
            
-
            15:54 < anti-> can't argue with what already works!
            
-
            15:55 <@cervantes> I think you should do it purely from a techdemo perspective
            
-
            15:55 < jrandom> ailouros: using NNTP to distribute syndie posts, yeah.  right now we just use ad-hoc syndication, but further enhancements would be great
            
-
            15:56 <@cervantes> no better way to demonstrate syndie than with some real world use cases
            
-
            15:56 < jrandom> true enough
            
-
            15:56 < jrandom> ok, perhaps we can plan on getting that out in the 0.6.1.6 release
            
-
            15:56 <+fox> <reliver> what i don't like about forum is they are low entry cost
            
-
            15:57 <+fox> <reliver> so lots of distractions filling them.
            
-
            15:57 <@modulus> i don't know, this syndie thing ... i much do not like yet, but maybe i'll get used to it.
            
-
            15:57 <+fox> <reliver> and you can only work with them online
            
-
            15:57 < jrandom> modulus: have you read the post linked to from http://syndiemedia.i2p.net/about.html ?
            
-
            15:57 <@modulus> reliver: high-entry is bad for bug reports though, people are making you a big favour by bothering to report in a sense.
            
-
            15:57 <+fox> <ailouros> they are not low entry cost: bandwidth comes to mind. They are high noise levels, so you can use [font=54]HELLO WORLD![/font] and annoy a huge number of people in no time
            
-
            15:57 < jrandom> agreed modulus
            
-
            15:58 <+fox> <ailouros> oh yeah and you have to be online indeed
            
-
            15:58 < jrandom> heh ailouros, thats something we need to deal with in Syndie anyway :)
            
-
            15:58 <@modulus> hmm, probably not, jr, let me check
            
-
            15:58 <+fox> <ailouros> well, with syndie you can blacklist the users and you're pretty much set
            
-
            15:58 < jrandom> well, with syndie you can create your bug reports offline, then syndicate them up to a remote archive later when you are :)
            
-
            15:58 < jrandom> exactly ailouros, with one click in the new release too
            
-
            15:59 <+fox> <ailouros> with forums either you hope for an admin to come and kill'em, or you keep them
            
-
            15:59 < anti-> it's more uucp than nntp :)
            
-
            15:59 <@modulus> hmm, which post in particular linked from there?
            
-
            15:59 < jrandom> lol *exactly* anti
            
-
            15:59 < jrandom> modulus: the first link "in syndie itself"
            
-
            15:59  * cervantes likes the killing option
            
-
            16:00 <@modulus> bah, uucp == nntp for all practical purposes :-)
            
-
            16:00 < jrandom> anti-: thats actually the point - as people build newer and better transport mechanisms (uucp, nntp, usenetdht, etc), the content can flow seamlessly
            
-
            16:00 <+fox> <ailouros> this all reminds me of plan9
            
-
            16:01 <+fox> <reliver> i2p may be special, but usually bug reporting systems used as firewalls against users ...
            
-
            16:01 < jrandom> used as firewalls against users?
            
-
            16:01 <+fox> <reliver> i2p may be special, but usually bug reporting systems are used as firewalls against users ...
            
-
            16:01 <+fox> <reliver> yes.
            
-
            16:01 < jrandom> I want it to be really, really easy for people to report bugs
            
-
            16:01 <+fox> <reliver> mozilla, thunderbird, ubuntu are just examples
            
-
            16:02 <+fox> <reliver> ok, great :-)
            
-
            16:02 < jrandom> mozilla/etc have that integrated "feedback agent" for submitting bug reports automatically
            
-
            16:02 <+fox> <reliver> they don't read those bug reports
            
-
            16:02 < jrandom> heh
            
-
            16:02 <@modulus> hmm, that intro is ok, only problem is i just don't like the interface at all, i prefer doing mailish things through the folder metaphor rather than the web-with-sithloads-of-links-on-it method
            
-
            16:02 <@modulus> but that's just me
            
-
            16:02 < jrandom> modulus: perhaps the rss export would best serve your needs then?
            
-
            16:02 <+fox> <ailouros> I agree with modulus (anyone guessed? :D )
            
-
            16:02 <@cervantes> having to use pastebin to show console errors is a bit of a put-off for some folks
            
-
            16:03 < jrandom> or we can get susimail integration, as cervantes suggested, to send out reports
            
-
            16:03 < jrandom> (or to post to syndie)
            
-
            16:03 <@modulus> it is possible, jrandom, i'll look into it. maybe i need an RSS-to-NNTP or RSS-to-POP?/IMAP converter, i'll think on it.
            
-
            16:05 <@cervantes> modulus: I'll be curious to find out what you think of the new i2ptunnel interface come the next i2p release
            
-
            16:05 <@cervantes> whether it's better or worse for you in terms of usability
            
-
            16:05 <@cervantes> (but I guess you just normally edit the config files?)
            
-
            16:07 < jrandom> ooh yeah shit, I forgot so much stuff in the status notes...
            
-
            16:08 <+fox> <ailouros> then let's hurry ahead and skip to the next point in line... that was point number C, right?
            
-
            16:08  * jrandom thinks it really kicks ass, but we'll get some more feedback as people try it out
            
-
            16:08 <@modulus> cervantes: is that curious as in "you're going to kill yourself with a small knife in your arse as a better alternative to using it" or on the contrary? :-)
            
-
            16:08 < jrandom> yeah, jumping to 6), anyone have any thoughts on the Dynamic Keys proposal?
            
-
            16:09 <@modulus> cervantes: usually use the interface actually, though now i know the config files are editable ... :-)
            
-
            16:09 <+fox> <ailouros> yeah, I'm pretty certain it will cause the skyrocket in the number of supposed known routers
            
-
            16:09 <@cervantes> *damn* :)
            
-
            16:10 <@modulus> this dynamic key is the idea that routers get a new key upon new IP, right?
            
-
            16:10 <@cervantes> modulus: well, just if it's even worth bothering with WAI bullshit
            
-
            16:10 < jrandom> heh thats true ailouros
            
-
            16:10 <@cervantes> anyway...I digress
            
-
            16:10 < jrandom> right modulus 
            
-
            16:11 <@modulus> well, perhaps it isn't bad that the known peers are actually guesswork, more so than now.
            
-
            16:11 <+Complication> Well, the only thing I can figure out about Dynamic Keys.. seems that one shouldn't change keys needlessly (or it screws reliability performance tracking).
            
-
            16:11 <+Complication> But when IP changes (rare enough?) it might not hurt.
            
-
            16:11 < jrandom> right Complication.  it isn't something we'd want by default.  most people will *not* want it
            
-
            16:12 < anti-> i'm not sure of the positive impact of the proposals.
            
-
            16:12 < jrandom> it won't offer much of an improvement for anonymity either, and no improvement at all against a powerful adversary, but it might help against weak adversaries
            
-
            16:12 <+fox> <ailouros> wouldn't it also give away which nodes are fixed ip and which aren't?
            
-
            16:13  * cervantes has had the same key for nearly 2 years :)
            
-
            16:13 <+polecat> Well at least I can get here.
            
-
            16:13 < jrandom> ailouros: it would not be used by most people.  only a very, very small minority would want to use it
            
-
            16:13 <+fox> <ailouros> so basically more churn for a bit of protection against weak adversaries?
            
-
            16:13 < jrandom> right ailouros
            
-
            16:13 <+fox> <ailouros> oh ok
            
-
            16:14 <+fox> <ailouros> is there a way to measure the performance hit of that feature once in the wild?
            
-
            16:14 <@modulus> it would, i think, help against a node-dest intersection attack?
            
-
            16:14 <+polecat> I still wonder why I keep switching between OK and OK(NAT), puzzling...
            
-
            16:14 < jrandom> modulus: only for a weak adversary
            
-
            16:14 <+fox> <ailouros> polecat don't worry, I keep switching between 15h uptime and 0h uptime :|
            
-
            16:14 < jrandom> ailouros: not sure, though stats.i2p suggests that we can handle the churn
            
-
            16:15 < jrandom> polecat: hmm, means there's likely some filtering going on
            
-
            16:15 <@modulus> imo the node-dest intersection attack is the most serious likely feasible attack atm? besides the fact we are too few, i mean.
            
-
            16:15 <@modulus> so, i think anything which helps on that line is probably a good idea
            
-
            16:16 <+polecat> I can send UDP packets right over my router at that port, no problem from remote shells.  No clue, perhaps i2p detects the NAT, and mistakenly thinks it isn't forwarded.
            
-
            16:16 <+fox> <ailouros> I agree with the "good idea" as long as the churn doesn't cause a severe performance hit
            
-
            16:16 < anti-> when the network is bigger, there will be plenty of churn anyway...
            
-
            16:17 < anti-> *points out the obvious DoS attack involving constantly changing keys every few minutes
            
-
            16:17 < anti-> what impact would that have?
            
-
            16:17 <+fox> <ailouros> dos against who? :D
            
-
            16:18 < jrandom> eh, new peers go in the "not failing" tier by default, and only go up to the "high capacity" or "fast" tiers after they are around for a while
            
-
            16:18 < jrandom> so it won't DoS peer selection
            
-
            16:18 < anti-> with a relatively strong opponent... would create an awful lot of apparently dead nodes/netdb churn?
            
-
            16:18 <+Complication> anti: nobody would consider that node reliable any more
            
-
            16:18 <+polecat> anti-: We have a shitlist for a reason.
            
-
            16:19 < anti-> *satisfied
            
-
            16:19 < jrandom> well, the netDb entries are dropped if the peer is unreachable
            
-
            16:20 < anti-> then the same performance issues that were just raised about dynamic keys would apply? if the performance wouldn't be too impacted by such an attack, the performance wouldn't be affected noticeably by dynamic keys either... would it?
            
-
            16:20 <+polecat> incremental trust really does help with handling late onset betrayers, I was thinking.
            
-
            16:20 <+fox> <ailouros> what's a "late onset betrayer"?
            
-
            16:20 <+polecat> Trust people more and more as they continue to benefit you, but never so much that they can take away more than they've given...
            
-
            16:20 < anti-> join for ages, then turn judas.
            
-
            16:21 < jrandom> right, peers get dropped out of the 'fast' tier quickly if they act poorly
            
-
            16:21 <+Complication> I'd think it would be someone behaving like "wait until 300 participating tunnels, crash"
            
-
            16:21 <+polecat> Oh, I make up phrases all the time.  Yeah, Judas type betrayal, where you genuinely help someone, then betray them with the idea of cashing in at the last minute.
            
-
            16:21 < anti-> oh no, the tunnels broken *rebuild*
            
-
            16:21 < jrandom> the peers promoted to the 'fast' tier during that time they're dropped should then suffice
            
-
            16:21 <+fox> * ailouros has fun with these incorrect bible refernces :D
            
-
            16:22 < jmg> speaking of high capacity, wow im getting between 400k and 600K constantly for the router today. (but maybe all those zero hops settings im using are helping)
            
-
            16:22 < jrandom> 600KBps?!
            
-
            16:22 <+polecat> Hopefully during the time it takes to get to 300 participating tunnels, you'll be required to help transfer enough data it wouldn't matter if you crashed.
            
-
            16:22 < jmg> yes
            
-
            16:22 <+fox> <ailouros> O_O what are you connected to?
            
-
            16:22 <+Complication> Such bandwidth is news to me :)
            
-
            16:22 < jrandom> damn, thats fast enough to start running into our bloom filters
            
-
            16:22 < anti-> ailouros: rude question to anony researchers ;)
            
-
            16:23 <+polecat> It's gotta be 600KBpm or ph.
            
-
            16:23 <+fox> <ailouros> sorry anti- :D but he was the first to speak
            
-
            16:23 <+polecat> puh!
            
-
            16:23 < jrandom> I'd love to get some stats from the oldstats.jsp page off you.  but glad to hear its handling things :)
            
-
            16:23 < anti-> one day i will try from i2...
            
-
            16:23 < jrandom> hehe
            
-
            16:24 <+fox> <ailouros> sounds cool, I2P on I2
            
-
            16:24 < jmg> jrandom: im keeping graphs, ill monitor more closely, but yes i can confirm 600kB/s sustained for 2 minutes, about 5 minutes ago
            
-
            16:24 <+polecat> Has anyone tried to traverse a d-link router's firewall?  I'm having no luck there whatsoever and my friend keeps forgetting to forward the port.
            
-
            16:24 < jrandom> nice jmg 
            
-
            16:24 < anti-> polecat: do we do udp holepunching yet? i lost track
            
-
            16:25 < jrandom> anti-: yes, we do, for all but symmetric NATs
            
-
            16:25 < jrandom> polecat: if your friend has their model #, there are a few sites online listing what type of NAT it is
            
-
            16:26 < anti-> regarding late onset betrayal... might be an issue with a powerful adversary?
            
-
            16:26 < jmg> jrandom: of course bittorrent has been known to rape this connection at 4MB/s sustained, but Iv eased up on that a little lately
            
-
            16:26 < anti-> 24000 nodes, so you get one crashing every 10 seconds or so?
            
-
            16:26 <+polecat> symmetric NAT, as opposed to full cone?
            
-
            16:26 < jrandom> nice jmg 
            
-
            16:26 < jrandom> hmm anti-?
            
-
            16:26 < jrandom> polecat: or restricted cone
            
-
            16:27 <+polecat> Wow, it can even do restricted cone that's impressive..
            
-
            16:27 < anti-> i don't think late onset betrayal would have any significant effect at all unless applied on an incredibly massive scale, at which other attacks would have more of an impact?
            
-
            16:28 < jrandom> yeah I'm not too worried about it anti-... it'd cost too much, and we can route around failures anyway, so the damage would be minimal
            
-
            16:28 <+Complication> Late betrayal kind of requires contributing a lot (as to get other machines relying on your machine).
            
-
            16:28 <+fox> <ailouros> incredibly massive scale = you are all the netries on almost everyone else's router?
            
-
            16:28 < anti-> that is exactly what anti-p2ps do now, but we do have anti-anti-p2ps now...
            
-
            16:29 <+fox> <ailouros> no wait anti-p2p send trash instead of good data
            
-
            16:29 <+fox> <ailouros> that's not the same
            
-
            16:29 < anti-> that's just a faster way of getting shitlisted, so you would never be listed well.
            
-
            16:29 < anti-> that wouldn't work against i2p at all, i think.
            
-
            16:29 <@cervantes> jmg: I've had 4-5mb/s off torrents before, but never anything like 600k over I2P...have you got beefy hardware too?
            
-
            16:29 <+polecat> I was more thinking independant of i2p persay.  My government does a lot of late onset betrayal, though they try to keep it classified.
            
-
            16:29 < anti-> but we would probably bleed them dry of bandwidth first!
            
-
            16:29 < jrandom> anti-: if they're reliable for days on end, they can only attack once for less than 10 minutes
            
-
            16:30 < jrandom> exactly anti- :)
            
-
            16:30 <+polecat> Or in the context of online banking.
            
-
            16:30 < jmg> does anyone have easy instructions on setting up the Native BigInteger library for amd64? if not ill just figure it out
            
-
            16:30 < jrandom> heh polecat 
            
-
            16:30 < jrandom> jmg: its built into jbigi.jar, but it should build on amd64 now
            
-
            16:30 < jrandom> though, I suppose this means we're now on 6.1) ??? 
            
-
            16:31 < jrandom> anyone have anything else to bring up?  :)
            
-
            16:31 < anti-> you'd need 20000 machines or something, with a rolling crash schedule, and i think the results would be disappointing; you would end up contributing far more to the network than you took away!
            
-
            16:31 < jrandom> that is the hope anti-
            
-
            16:31 <+fox> <ailouros> well, worst case scenario is that people must reseed
            
-
            16:31 < jmg> oh thanks
            
-
            16:31 <+polecat> 64 bit processor, 4mbit upload bandwidth, sounds like somebody's a lucky bastard.
            
-
            16:32 < anti-> or running a normal machine at a uni...
            
-
            16:32 <+fox> * ailouros looks at his uni's hardware list and frowns
            
-
            16:32 < anti-> a uni that doesn't buy dell ;)
            
-
            16:33 <+fox> <ailouros> I think we have a couple of dells... from 5 years ago IIRC
            
-
            16:33 <+fox> <Sonium> i think this is bad:
            
-
            16:33 <+fox> <Sonium> jvm 1    | java.lang.OutOfMemoryError
            
-
            16:33 <+fox> <Sonium> jvm 1    | java.lang.OutOfMemoryError
            
-
            16:33 <+fox> <Sonium> jvm 1    | java.lang.OutOfMemoryError
            
-
            16:33 <@cervantes> polecat: 4 megabyte ;-)
            
-
            16:33 < jrandom> Sonium: yeah, once it gets one OOM, it'll die fast
            
-
            16:34 <+fox> <Sonium> and this too:
            
-
            16:34 <+fox> <Sonium> jvm 1    | 21:21:44.484 CRIT  [ Establisher] sport.udp.EstablishmentManager: Err
            
-
            16:34 <+fox> <Sonium> or in the establisher
            
-
            16:34 < jrandom> (subsequent OOMs are safe to ignore)
            
-
            16:34 < jrandom> once it gets a single OOM, you can ignore all subsequent errors
            
-
            16:34 <+fox> <ailouros> yeah but you shouldn't have the first OOM :D
            
-
            16:34 < jmg> polecat: the latency out here on the russian space station in phenominal though..
            
-
            16:34 < jrandom> true ailouros
            
-
            16:35 <+fox> <ailouros> oh, by the way... my router gets watchdogged quite often
            
-
            16:35 < jrandom> hrm, high cpu usage?
            
-
            16:35 <+fox> <ailouros> I guess it's just my unlucky installation?
            
-
            16:35 <+fox> <ailouros> not that I know of, the machine is rather unloaded
            
-
            16:36 <+fox> <ailouros> but I guess this is what I should expect from a buggy JVM on a somewhat bugged linux emulation layer
            
-
            16:36 < jrandom> what jvm are you using, and what os?
            
-
            16:36 <+fox> <Sonium> me?
            
-
            16:36 <+fox> <ailouros> Sun's Java(tm) 2 Standard Edition, JRE 5.0 Update 5 on NetBSD/i386 2.0.2
            
-
            16:37 < jrandom> ahhh yeah, I have done no testing on nbsd.  fbsd is fine, but I don't have any experience w/ nbsd
            
-
            16:38 < jrandom> might be worth trying out gcj, perhaps we can dig into that after the meeting
            
-
            16:38 <+fox> <ailouros> it works rather well, but the real fun with this is that sometimes (depending on which bit he flipped when getting off the bed -- err restarting) the netbsd files get created with 540 permission :D
            
-
            16:38 <+fox> <Sonium> something really sucks here
            
-
            16:38 <+fox> <Sonium> jvm 1    | #  Internal Error (53414645504F494E540E4350500175), pid=3500, tid=345
            
-
            16:38 <+fox> <Sonium> 6
            
-
            16:39 <+fox> <ailouros> sorry the netDb files are created 540
            
-
            16:39 <+fox> <Sonium> I think I will reinstall this later
            
-
            16:39 < jrandom> Sonium: what OS are you on?  the jvm seems to be acting up
            
-
            16:39 <+fox> <Sonium> winxp
            
-
            16:39 < jrandom> yeah, if you're on 1.5.0_5, might be worth trying 1.4.2_09
            
-
            16:39 < anti-> i don't think that's i2p's problem...
            
-
            16:40 < jrandom> (1.4.2 has been more stable for me, requiring less resources)
            
-
            16:40 < jrandom> and i2p doesn't use any 1.5-isms, nor do we need the 1.5 GUI improvements
            
-
            16:40 <+fox> <Sonium> the curious thing is, that is never occured before
            
-
            16:40 <+polecat> Can't use azureus if you don't have 1.5 though, meh.
            
-
            16:40 <+fox> <ailouros> and of course I *DO* use azureus :|
            
-
            16:41 <+fox> <ailouros> but it isn't a real problem... not much, I think...
            
-
            16:41 <+fox> <ailouros> unless those messages about bob being fourth are relevant
            
-
            16:41 < jrandom> nah, those are safe to ignore
            
-
            16:41 < anti-> (am i the only one irked by utorrent and bitcomet not being open?)
            
-
            16:42 <+polecat> :o  Damn you bob!
            
-
            16:42 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:42 < anti-> muffins?
            
-
            16:42  * cervantes can recommend ibm java 1.4.2 if you're after better resource handling
            
-
            16:42 <+polecat> anti-: Try mlnet.  caml -> weirdest language in the world, but it works well.
            
-
            16:42 <+fox> <ailouros> caml is cool
            
-
            16:42 <+fox> <ailouros> (if you can read it :D )
            
-
            16:42 <@frosk> hey, don't diss caml
            
-
            16:43 < anti-> prolog deserves a mention there, as does brainf**k et al
            
-
            16:43 <+polecat> caml has horrible docs.  It took me half an hour to figure out that ! usually (sometimes) is a dereference operator.
            
-
            16:43 <@frosk> i'm paid to write ocaml :)
            
-
            16:43 <+polecat> jrandom: Didn't know I crashed a meeting, sorry.
            
-
            16:44 < jrandom> np, we're making up for our short meetings ;)
            
-
            16:44  * jrandom winds up
            
-
            16:44  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting157.html b/www.i2p2/pages/meeting157.html
deleted file mode 100644
index 6996448d..00000000
--- a/www.i2p2/pages/meeting157.html
+++ /dev/null
@@ -1,144 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 157{% endblock %}
-{% block content %}
            I2P dev meeting, November 22, 2005
            
-
            
-
            16:18 < jrandom> 0) hi
            
-
            16:18 < jrandom> 1) Net status
            
-
            16:18 < jrandom> 2) Fox hunt
            
-
            16:18 < jrandom> 3) ???
            
-
            16:18 < jrandom> 0) hi
            
-
            16:18  * jrandom waves belatedly from a house with its power restored
            
-
            16:18 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001227.html
            
-
            16:19 < jrandom> 1) Net status
            
-
            16:20 < jrandom> not much to add beyond whats in the mail.. anyone have anything they want to bring up re: net status?
            
-
            16:21 < jrandom> if not, movin' on to 2) Fox hunt
            
-
            16:21 < zzz> great idea
            
-
            16:22 < jrandom> here, too, I don't have much to add beyond whats in the mail and Raccoon23's proposals..
            
-
            16:22 <+fox> <ailouros> I have something against the name "Fox hunt". I'd rather call it "Man hunt". Foxes did nothing wrong.
            
-
            16:22 < Raccoon23> hah
            
-
            16:22 < jrandom> aye, I concur zzz, it'll be quite helpful to give people a real incentive without the serious dangers of actual use 
            
-
            16:23 < nickless_head> call it "<politically correct animal> hunt
            
-
            16:23 < Raccoon23> "Fox hunt" is the typical name for a ham radio contest where you try to find a rogue transmitter
            
-
            16:24 <+fox> <ailouros> I don't care for radio trasmitters called Fox, we're talking i2p here, no anonymous foxes allowed
            
-
            16:24 <+fox> <ailouros> :D
            
-
            16:24  * cervantes wonders if ailouros is aware of the name of changate
            
-
            16:24 < nickless_head> maybe "Dissident hunt"
            
-
            16:25 <@cervantes> <fox> <ailouros> :D
            
-
            16:25 <+fox> <ailouros> (err what's changate?)
            
-
            16:25 < jrandom> heh
            
-
            16:25 <@cervantes> ailouros: it's the bots that relay chat between different networks
            
-
            16:26 <+fox> <ailouros> you mean vulpine here?
            
-
            16:26 <@cervantes> chat over on i2p gets relayed to you as vulpine
            
-
            16:26 <@cervantes> and you chat is relayed to us via fox
            
-
            16:26 <@cervantes> ;-)
            
-
            16:26 <@cervantes> *your
            
-
            16:26 <+fox> <ailouros> so the hunt is for the poor slave-working bot? :D
            
-
            16:27 < Raccoon23> so yeah, I think there should be a bounty/info page set up. I think we should shoot for raising $1k
            
-
            16:27 <+fox> <ailouros> yeah sorry I don't usually go i2pchat  :)
            
-
            16:27 <+fox> <ailouros> now, that's a bounty!
            
-
            16:28 < jrandom> Raccoon23: I agree, but it may be a bit premature to do so now.  
            
-
            16:28 < jrandom> (we can always allocate funds out of the general fund to the bounty to kick start it when necessary)
            
-
            16:28 <+fox> <ailouros> start the hunt right now but without a bounty?
            
-
            16:28 <+fox> <ailouros> I mean, the sooner it starts, the more eyes get open
            
-
            16:28 < jrandom> for the fox hunt to make sense (aka help I2P), we need to do so carefully.
            
-
            16:28 < jrandom> no ailouros, I disagree.
            
-
            16:29 < jrandom> running the contest before I2P is ready would be very bad.
            
-
            16:29 < Raccoon23> yah
            
-
            16:29 < jrandom> both because it would waste people's time evaluating something that isn't done, and because it wouldn't tell anything useful
            
-
            16:30 <+fox> <ailouros> ....point taken
            
-
            16:30 < Raccoon23> and it would be bad press if vulns were "found" that were scheduled to be fixed in coming versions
            
-
            16:30 < jrandom> aye
            
-
            16:33 < jrandom> ok, anything else on 2), or shall we move on over to 3) ???
            
-
            16:34 < zzz> on the other part of the jrandom/raccoon23 thread, was it a conclusion to move to 2-hop-minimum? any other conclusions?
            
-
            16:35 < jrandom> hmm, its all a question of who one's adversary is, but it wouldn't really hurt to default to 2 +0-1 and would afford protection against a class of attacker
            
-
            16:35 < jrandom> other conclusions may be "hey, get rolling on 0.6.2" :)
            
-
            16:35 <+fox> <ailouros> how do I set the configuration so that the tunnels always have a set value (like 0+1 variance)? I keep getting default values every restart
            
-
            16:36 < jrandom> ailouros: you should be able to save the settings on /i2ptunnel/ 
            
-
            16:36 < jrandom> or are you changing them on /configtunnels.jsp ?
            
-
            16:37 < Raccoon23> I think 1 hop tunnels allow a pretty weak attacker to do a lot in 0.6.1 at least. I would argue that 0.6.1.6 should not have 1 hop tunnels by default
            
-
            16:37 <+fox> <ailouros> configtunnels it is
            
-
            16:37 < jrandom> aye, agreed Raccoon23 
            
-
            16:37 < jrandom> ailouros: use /i2ptunnel/ and save your settings
            
-
            16:37 <+fox> <ailouros> didn't notice the new interface :D
            
-
            16:38 <@cervantes> ailouros: just added in 0.6.1.5
            
-
            16:38 < jrandom> yeah cervantes did some great work there ailouros
            
-
            16:38 <+fox> <ailouros> well, kudos for that
            
-
            16:39 <@cervantes> while we're on that subject, if folk are having troubles saving settins on the new interface, they might want to use a non-IE browser for now until the next release
            
-
            16:39 <@cervantes> *grumble* microsoft *grumble*
            
-
            16:40 <+fox> <ailouros> on a different topic, would anyone be interested if I set up a nethack server on i2p? :D
            
-
            16:41 <@frosk> ailouros: been thinking about it (playing nethack irl), but the lag would be horrible i'm afraid (and lag sucks really hard when playing nethack)
            
-
            16:42 <+fox> <ailouros> guess so
            
-
            16:42 <+fox> <ailouros> okay, idea scrapped
            
-
            16:43  * frosk just had his first ascension a few months back, woot
            
-
            16:44 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:45 <+fox> <ailouros> yes, some indicator for syndie wen the thread has a new message
            
-
            16:46 < nickless_head> jrandom: and it would be cool if new messages (the titles) could be printed in bold/italics the first time they're displayed
            
-
            16:47 < nickless_head> jrandom: is there a _really simple_ way to get to the messages in the syndie database, over http?
            
-
            16:47 < jrandom> ah yeah ailouros/nickless_head, I'm thinking of color coding/flagging the first column by date (e.g. things posted today get a bright flag, yesterday a less bright, etc).  
            
-
            16:47 < nickless_head> jrandom: preferredly in something nice and importable like xml
            
-
            16:48 < jrandom> nickless_head: wget -R http://localhost:7657/syndie/archive/
            
-
            16:48 < nickless_head> if there is, I could write a syndie to nntp exporter
            
-
            16:48 < jrandom> oh, if you want to export to nntp, use rss to nntp
            
-
            16:48 < nickless_head> jrandom: ok I'll try that :)
            
-
            16:48 < nickless_head> jrandom: that already exists? ... damn. ;)
            
-
            16:49 < jrandom> i'm also thinking about adding per-user message histories to let you mark messages as read/unread, but that probably won't be in 0.6.1.6 (unless someone else implements it :)
            
-
            16:49 < jrandom> or perhaps a new filter on the thread tree - only show messages posted since [today |v]
            
-
            16:49 < jrandom> (or yesterday, or 2 days ago)
            
-
            16:50 < jrandom> nickless_head: http://www.methodize.org/nntprss/
            
-
            16:50 < nickless_head> jrandom: thanks
            
-
            16:54 < jrandom> np
            
-
            16:54 < Raccoon23> jrandom: so it'd be a while before I'd be able to implement it (I wanna get restricted routes done first), but what do you think about optional 1024bit garlic routing for outbound server tunnels?
            
-
            16:54 < jrandom> tremendous overhead - O(data) is >>> O(tunnels).  if we're running into trouble now with O(tunnels), there's no way we can hope for O(data)
            
-
            16:55 < Raccoon23> are we still having cpu issues? my router has been pretty low, but I don't exactly have a T1 over here..
            
-
            16:56 < jrandom> not everyone has p4s ;)
            
-
            16:56 < jrandom> i hear reports of 8-15% usage on slow machines, but that spikes bad under congestion
            
-
            16:56 < jrandom> (to 100+%)
            
-
            16:56 <+Complication> About CPU consumption: curiously enough, Java on Mandriva 10.1 consumes a lot less than Java on Mandriva 2006.
            
-
            16:56 < Raccoon23> yah, but those who don't probably don't have T1
            
-
            16:56 < Raccoon23> either :)
            
-
            16:57 <+Complication> Both tweaked, 2006 has jbigi compiled locally.
            
-
            16:57 < jrandom> weird Complication 
            
-
            16:57 < jrandom> same revs of i2p?
            
-
            16:57 <+Complication> On 2006 (Celeron 2.4) java can hit 20%.
            
-
            16:58 <+Complication> On 10.1 it wouldn't go higher than 5%.
            
-
            16:58 <+Complication> (Usually)
            
-
            16:58 <+Complication> (usually==not on startup)
            
-
            16:58 <+Complication> Same revisions.
            
-
            16:58 <+Complication> Almost the same Java too (_04 versus _05)
            
-
            16:59 <+Complication> Reminds me to tweak daemons a bit more. Perhaps some of them is obstructing java.
            
-
            16:59 <+Complication> In some wacky way I cannot figure out.
            
-
            17:00 <+Complication> But yes, the Cel 300 is feeling notably better. Could have been the adaptive MTU
            
-
            17:01 < jrandom> ah cool, yeah, we've got some neat stuff on the way :)
            
-
            17:03 <+Complication> I wonder if there'd be a way to get past the libc-related jbigi problems on certain Linux distros?
            
-
            17:03 < jrandom> yeah, definitely, just need to rebuild all the jbigis 
            
-
            17:03 < jrandom> (its not libc, its libg++)
            
-
            17:05  * Raccoon23 decides he doesn't give up his dreams of garlic routing, but will wait for performance to stabilize.. perhaps 2.0
            
-
            17:05 <+Complication> Oh, you think a proper rebuild will help it?
            
-
            17:05 < jrandom> Complication: yeah, the jcpuid link errors are unnecessary, as jcpuid is really just an ASM call (and shouldn't have been implemented in c++ anyway ;)
            
-
            17:06 < jrandom> Raccoon23: cool :)  its something we can do eventually over the live net too, just using a different I2NP message type, advertising the right capability, and filtering on that
            
-
            17:06 < jrandom> (eventually)
            
-
            17:07 < Raccoon23> like a caps=S for speedy CPU? ;) 
            
-
            17:08 < jrandom> and caps=I for insane ;)
            
-
            17:08 < jrandom> ok, anyone else have something for the meeting?
            
-
            17:08 < Raccoon23> haha
            
-
            17:09 < Raccoon23> what do you think about the stopgap of sharing keys across multiple tunnels? too little payoff for the work?
            
-
            17:09 < jrandom> why would that be better than just having multiple tunnels and sending the message through one of the multiple tunnels?
            
-
            17:10 < jrandom> (and, erm, wouldn't it be worse, from a security perspective, and anonymity perspective)
            
-
            17:10 < Raccoon23> well the idea is that nodes could not tell which traffic was part of one tunnel, so that if you were running i2phex and and eepsite, and choose the same hosts for your tunnels, the traffic from the two would be blended as far as the hops could see
            
-
            17:11 < Raccoon23> which should make timing attacks harder
            
-
            17:11 < jrandom> ah, yikes, yeah.  that adds Really Bad linkability
            
-
            17:11 < jrandom> its why we moved to per-client tunnel pools in 0.4
            
-
            17:11 < Raccoon23> explain?
            
-
            17:11 < jrandom> i2ptunnel does let people share pools, if they want, by sharing the same destination
            
-
            17:12 < jrandom> if messages for 2 clients go down a tunnel, you know both of those clients are controlled by the same person
            
-
            17:12 < jrandom> s/clients/destinations/
            
-
            17:13 < Raccoon23> well if keys were shared, the early hops could be blended, but the leasesets seperate..
            
-
            17:13 < Raccoon23> the early hops being the dangerous ones for timing attacks anyways
            
-
            17:13 < jrandom> it'd still allow a vector for linking the two unlinkable destinations
            
-
            17:14 < jrandom> one could do some munging to hopefully obfusticate the linkability, but they'd be inherently linked.  which isn't necessary, and is bad.
            
-
            17:18 < Raccoon23> back to dreaming of caps=SI I guess :)
            
-
            17:19 < jrandom> ah well.  ok, anyone have anything else?
            
-
            17:20  * jrandom winds up
            
-
            17:20  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting158.html b/www.i2p2/pages/meeting158.html
deleted file mode 100644
index 2ce40d1a..00000000
--- a/www.i2p2/pages/meeting158.html
+++ /dev/null
@@ -1,228 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 158{% endblock %}
-{% block content %}
            I2P dev meeting, November 29, 2005
            
-
            
-
            15:25 < jrandom> 0) hi
            
-
            15:25 < jrandom> 1) Net status and 0.6.1.6
            
-
            15:25 < jrandom> 2) Syndie
            
-
            15:25 < jrandom> 3) I2P Rufus 0.0.4
            
-
            15:25 < jrandom> 4) ???
            
-
            15:25 < jrandom> 0) hi
            
-
            15:25  * jrandom waves
            
-
            15:25 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html
            
-
            15:26  * bar hands jrandom a baf
            
-
            15:26 < c3rvantes> not yet!
            
-
            15:26  * jrandom winds up
            
-
            15:26 < jrandom> er...
            
-
            15:26 < jrandom> lets hit the first few agenda items first :)  1) Net status and 0.6.1.6
            
-
            15:27 < jrandom> lots of things have been updated in the last few releases, but the network still seems reasonably stable.  
            
-
            15:28 < jrandom> we've had some serious spikes in router participation on a few routers, though thats pretty harmless
            
-
            15:28 <+legion> cool, I agree net status is getting better. Also yeah why not drop tcp for 0.6.1.7
            
-
            15:28 < jrandom> (er, spikes in tunnel participation, that is)
            
-
            15:29 <@cervantes> you're not kidding
            
-
            15:29 < jrandom> not sure legion.  there may be some users out there limited to tcp only, but i seem to recall that there was only one or maybe two of those
            
-
            15:29 <+legion> well I've noticed with 0.6.1.5 the router would sometimes restart on its own.
            
-
            15:29 <+Complication> Mine's been swinging withint reasonable limits, 100 to 250 participating tunnels
            
-
            15:29 < jrandom> I can't think of any great reason to keep it, and I can think of a few to drop it
            
-
            15:30 < jrandom> cool Complication
            
-
            15:30 < jrandom> (those numbers are fairly average, according to stats.i2p/, but remember, numbers like that can damage anonymity, so shouldn't really be given out, especially not in logged meetings ;)
            
-
            15:30 <+Complication> My old Celeron is still auto-restarting every 10 hours or so
            
-
            15:30 <+Complication> Otherwise it's better connected than ever before
            
-
            15:30 < Pseudonym> what are the reasons to drop it?
            
-
            15:31 <+Complication> TCP is expensive
            
-
            15:31 <@cervantes> my router is shagged out
            
-
            15:31 <+Complication> In terms of threads per connections
            
-
            15:31 <@cervantes> Complication: multiply that by 10 and you get my router's current range ;-)
            
-
            15:31 <+legion> Mines been swinging within 200-400 participating tunnels, so it seems better than ever.
            
-
            15:32 <+Complication> cervantes: ouchie ouchie
            
-
            15:32 <+Complication> I've seen a freak accident which caused 2000 participating tunnels, but that was in Summer
            
-
            15:32 < jrandom> Pseudonym: performance (cpu/memory, better scheduling due to our semireliable requirements), maintainability, more effective shitlisting
            
-
            15:32 <+Complication> A single spike which never repeated again
            
-
            15:32 <+legion> yeah, with some past versions there were such spikes
            
-
            15:32 < jrandom> Complication: we've had > 2000 tunnel spikes with this last rev
            
-
            15:33 < jrandom> but hopefully 0.6.1.7 will take care of that
            
-
            15:33 <+legion> Well those are some good reasons to drop tcp :)
            
-
            15:33 < jrandom> but, again, the spikes in tunnel participation is fine, as most of them aren't used
            
-
            15:34 <@cervantes> Pseudonym: there only seems to be one or two routers still using tcp on the network
            
-
            15:34 < jrandom> it may also be a good idea to drop tcp in this rev too, since it doesn't have other major changes.  that way we can see how it affects things pretty clearly
            
-
            15:34 < jrandom> (and can reenable it if necessary)
            
-
            15:35 < Pseudonym> if there are only two routers using it, I can't imagine it would have much effect either way
            
-
            15:35 < Pseudonym> (except for there being two less routers on the network)
            
-
            15:35 <@cervantes> 2 disgruntled customers
            
-
            15:35 < jrandom> well, the transport does show up in some odd situations, which is one of the reasons i want to disable it :)
            
-
            15:35 <+Complication> I hope they won't take it very personally
            
-
            15:36 <+Complication> It's really nasty of certain ISP's to filter UDP.
            
-
            15:36 <+Complication> Nasty, and completely senseless.
            
-
            15:36 < jrandom> (e.g. when a router is hosed, people mark their SSU transport as failing, and as such, they fall back on the tcp transport)
            
-
            15:36  * Pseudonym loves his ISP.  no restrictions
            
-
            15:37 <+Complication> So without TCP, one would see how UDP handles it alone?
            
-
            15:37 <+Complication> "with no auxiliary wheels" :P
            
-
            15:37 <+legion> huh so how do we get around such nasty filtering without tcp?
            
-
            15:38 < jrandom> exactly Complication :)
            
-
            15:38 < jrandom> legion: we don't
            
-
            15:38 < jrandom> (restricted routes)
            
-
            15:38 <+Complication> Well, aren't there a number of useful apps besides file-sharing programs, which also use UDP packets sized above DNS packets?
            
-
            15:39 <+legion> :( doesn't sound good
            
-
            15:39 <+Complication> Sized similarly to the smallest packet size I2P uses?
            
-
            15:39 < jrandom> eh legion, its not a problem
            
-
            15:39 < jrandom> Complication: streaming protocols
            
-
            15:39 <+Complication> One cannot block UDP directly, ever, without crippling DNS.
            
-
            15:39 <+Complication> One can limit the packet size.
            
-
            15:40 <+legion> ok, it did sound like it could be
            
-
            15:40 <+Complication> VoIP?
            
-
            15:40 < jrandom> it'd be a problem if it were widespread - if the internet community in general banned udp
            
-
            15:40 <+Complication> Hmm, does VoIP use big or small packets?
            
-
            15:40 < jrandom> but if its just a few isps, we can treat them like restricted routes
            
-
            15:40 <+Complication> Or did you mean more like... video spreaming?
            
-
            15:40 <+legion> I'd think it'd use a mix of both
            
-
            15:41 < jrandom> both Complication, RTSP runs over UDP, and real runs over RTSP iirc
            
-
            15:41 <+Complication> s/p/s
            
-
            15:42 <+legion> So on to the next item?
            
-
            15:42 <+Complication> cat /etc/services | grep -c udp
            
-
            15:42 <+Complication> 227
            
-
            15:43 < jrandom> I'm still not sure if we'll drop tcp in 0.6.1.7, but probably.  
            
-
            15:43 < jrandom> aye, anyone have anything else on 1)?  if not, lets jump on to 2) Syndie
            
-
            15:43 <+Complication> Meaning, there are at least 227 apps (some possibly obsolete or LAN apps) which use UDP
            
-
            15:44 < jrandom> bah, this is the intarweb.  all you need is proxied HTTP access
            
-
            15:44 < jrandom> I don't have much to add to 2) beyond whats in the mail (and whats on Syndie)
            
-
            15:44 <+legion> I'm convinced, yeah drop it. :)
            
-
            15:44 < jrandom> anyone have anything re: syndie they want to bring up?
            
-
            15:45 <+legion> I've nothing to say about 2) either.
            
-
            15:45  * Complication is reading "how Syndie works"
            
-
            15:46 <+Complication> One little UI effect, keeps surprising me. :D
            
-
            15:46 <+Complication> When I expand a thread of messages, it always gets me by surprise that the active message moves to become the topmost in the list. :P
            
-
            15:47 <+Complication> But you can proabably safely ignore that. I'm just very picky, and a creature of habit. :P
            
-
            15:47 <@cervantes> the threading model is something that's being discussed at length
            
-
            15:47 <@cervantes> ;-)
            
-
            15:47 <+Complication> I'll get used to it. :)
            
-
            15:48 <+Complication> cervantes: in Syndie? I gotta find that thread. :)
            
-
            15:48 <@cervantes> I don't like that either - but it could well change
            
-
            15:48 < jrandom> yeah, thats kind of kooky I suppose
            
-
            15:48 <+legion> yeah
            
-
            15:48 <@cervantes> "subject: syndie threading"
            
-
            15:49 <+Complication> Besides, if the expanded message were the bottom-most, it *would* have to move anyway.
            
-
            15:49 <+Complication> 'Cause otherwise it'd be stuck there.
            
-
            15:50 < jrandom> well, the nav at the bottom shows 10 *threads* at a time, not 10 messages.  so it could expand the bottom thread
            
-
            15:50  * cervantes is testing some different threading UI style implementations atm
            
-
            15:51 < jrandom> wikked
            
-
            15:51 < jrandom> yeah, ideally we'll be able to switch them around in css, or if not, on the server side
            
-
            15:52 <@cervantes> or rather "threading navigation styles"
            
-
            15:53 <@cervantes> hmm my tests use pure html nested unnordered lists by default
            
-
            15:53 <@cervantes> you can layer on as much css and javascript as your need or want
            
-
            15:53 < jrandom> any eta on when we can see some mockups?
            
-
            15:53 <@cervantes> (however it's only a proof of concept, not an actual ui implementation)
            
-
            15:54 <@cervantes> I do most of my coding during I2P meetings ;-)
            
-
            15:54 < jrandom> heh
            
-
            15:54 <@cervantes> perhaps the first mockup will be ready this evening
            
-
            15:54  * jrandom schedules daily meetings
            
-
            15:54 < jrandom> wikked
            
-
            15:54 <@cervantes> curses :)
            
-
            15:55 < jrandom> ok, anyone have anything else for 2) syndie?
            
-
            15:55 < jrandom> if not, lets move on to 3) I2P Rufus 0.0.4
            
-
            15:56 < jrandom> I don't have much to add beyond whats in the mail - Rawn/defnax, y'all around?
            
-
            15:56 <+legion> so how good is 0.0.4? What problems remain if any?
            
-
            15:57  * jrandom hasn't a clue
            
-
            15:58 <+legion> Maybe one of its users can answer. Does it seem good and stable?
            
-
            15:58 < jrandom> ok, seems Rawn and defnax are away atm.  if anyone has any questions/comments/concerns regarding I2P Rufus, swing on by the forum and post 'em away
            
-
            15:58 <+legion> darn, guess we'll have to.
            
-
            15:59 <+legion> on to 4)?
            
-
            15:59 < jrandom> aye, so it seems.  ok, 4) ??? 
            
-
            15:59 <+Complication> I haven't tried I2P Rufus, unfortunately.
            
-
            16:00 < jrandom> anyone have anything else they want to bring up?
            
-
            16:00 < jrandom> (c'mon, we've got to drag this out so cervantes can do some more work!)
            
-
            16:00 <+legion> yeah, what sort of interesting stuff is coming down the pipe?
            
-
            16:00 <+bar> is there anywhere i could read more about "restricted routes"?
            
-
            16:00 <+bar> (i *have* searched)
            
-
            16:01 <+legion> Maybe we could even discuss i2phex?
            
-
            16:01 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD
            
-
            16:01  * cervantes poises his mouse over the close button
            
-
            16:01 < jrandom> er, #future.restricted
            
-
            16:02 < jrandom> plus the how_* pages & todo
            
-
            16:02 < jrandom> (on the web)
            
-
            16:02 <+Complication> Heh, I2P seems to have skipped a build :D
            
-
            16:02 <+Complication> :D
            
-
            16:02 <+bar> thanks
            
-
            16:02 <+Complication> -    public final static long BUILD = 1;
            
-
            16:02 <+Complication> +    public final static long BUILD = 3;
            
-
            16:03 < jrandom> legion: some hacking on the netDb, performance mods, restricted routes, streaming improvements, eepproxy improvements, tunnel improvements, etc.  lots of stuff, but nothing ready yet
            
-
            16:03 <+legion> huh, odd
            
-
            16:03 < jrandom> anything to bring up re: i2phex legion?
            
-
            16:03 < jrandom> Complication: yeah, intended.  I forgot to increase it for BUILD = 2
            
-
            16:03 <+Complication> (not that it matters for anything, just wondering if I've seen this rare occasion before :)
            
-
            16:04 <+legion> sweet, sounds great, thanks!
            
-
            16:04 < jrandom> oh, that reminds me... it'd be cool if someone wanted to dig into looking at revamping our webpage
            
-
            16:05  * jrandom doesnt want to think about it, but its got to be done sooner or later
            
-
            16:05 <+legion> yeah, there is
            
-
            16:05 <+legion> would it be worthwhile to update i2phex at this point to the latest phex cvs code?
            
-
            16:06 <+Complication> Not sure, I haven't heard from Redzara recently
            
-
            16:06 < jrandom> last I recall, redzara was waiting on gregorz's updates to phex
            
-
            16:06 < jrandom> (so we could have a fairly clean update/extension)
            
-
            16:08 <+legion> huh, then why have i2phex?
            
-
            16:08 <+Complication> Just in case?
            
-
            16:08 < jrandom> hmm?
            
-
            16:08 < jrandom> i2phex is an extension to phex
            
-
            16:08 <+legion> Seems like they wanted there to just be phex with a i2p extension
            
-
            16:09 < jrandom> extension, as in, modification to a very small number of bits
            
-
            16:09 < jrandom> er, s/bits/components/.  so we can easily update the code whenever the phex devs fix things
            
-
            16:10 <+legion> if so then it shouldn't take much work for me to update it to the latest cvs code, though I know it will.
            
-
            16:10 < jrandom> last I heard in the forum was that the plan is to have I2Phex and Phex be separate applications, but they'd share a majority of code
            
-
            16:10 < jrandom> aye legion, that'd be great, but last I heard, Gregor hadn't finished the modifications to Phex yet
            
-
            16:11 < jrandom> (which is what redzara was waiting on)
            
-
            16:11 <+legion> ah I see
            
-
            16:11 < jrandom> so, the alternative is to either help Gregor out or continue modifying the existing I2Phex codebase
            
-
            16:12 <+legion> well then if I don't wait and just update i2phex with new code, there would be no need for redzara continue
            
-
            16:12 < jrandom> well, not really. 
            
-
            16:12 < jrandom> updating I2Phex to the current Phex code would be great, yes
            
-
            16:13 < jrandom> but as soon as the Phex developers update their Phex code, we're out of sync again
            
-
            16:13 <+legion> ok, I'll probably get to it sometime tonight or within a couple days.
            
-
            16:13 < jrandom> wikked
            
-
            16:13 <+legion> That is fine.
            
-
            16:14 <+legion> Really I'm not looking to have i2phex remain in sync with phex code, it's just that it sounds like the cvs contains fixes which i2phex could certainly use.
            
-
            16:15 <+legion> Also I'm really looking to drop out any phex code and features which i2phex doesn't need.
            
-
            16:15 < jrandom> cool
            
-
            16:16 <+legion> As to any new features and fixing anything that is still not working like the upload queues... Well I've already looked into getting the webcaches working, but have much more to do.
            
-
            16:17 < jrandom> word.  yeah, phex used to have working gwebcache support, but sirup disabled it, as it wasn't necessary at first
            
-
            16:17 <+legion> I do plan on adding jeti to i2phex eventually.
            
-
            16:17 < jrandom> neat
            
-
            16:18  * jrandom has never used jeti, and I hope it stays an optional component, but supporting more things is cool
            
-
            16:18 <+legion> Yeah it can be optionally, users will be able to download a jeti2phex ;)
            
-
            16:19 < jrandom> word
            
-
            16:19 <+legion> There still is much we can do with i2phex, though it is working great as it is.
            
-
            16:20 <+legion> So far keeping a client connected, up and running for 24/7 is possible and easy.
            
-
            16:21 < jrandom> yeah, I've had some good success with it... "backing up my licensed recordings"
            
-
            16:21 <+legion> heh :)
            
-
            16:22 < jrandom> ok, anyone else have anything for the meeting?
            
-
            16:23  * cervantes wheels in the chinese gong
            
-
            16:23 <+legion> Seems like I'm forgetting something... hmm
            
-
            16:24 <+legion> Oh yeah, any ideas on how we can reduce the amount of memory i2p and i2phex consumes?
            
-
            16:25 <+Complication> Well, the TCP transport takes a bit
            
-
            16:25 < jrandom> one could run both in the same jvm
            
-
            16:25 <+Complication> If that is going, it will free a bit
            
-
            16:26 <@cervantes> take some ramsticks out of your machine
            
-
            16:26 < cat-a-puss> anyone with any experence with javolution know if it would help? http://javolution.org/
            
-
            16:26 < jrandom> (clients.config in the i2p install dir defines the main class and arguments to launch clients)
            
-
            16:26 <+legion> So if we ran both in the same jvm and when tcp goes, could we bring it down to under 50mb?
            
-
            16:27 < jrandom> no idea legion.  depends on what you mean by 50MB as well.  RSS/VSS/etc
            
-
            16:27 < jrandom> I really wouldn't recommend running both in one JVM though, unless you keep both running all the time, since shutting down one would kill the other
            
-
            16:27 <@cervantes> legion: limiting bandwith and capping participants might also help
            
-
            16:27 < jrandom> aye, what cervantes said
            
-
            16:28 < cat-a-puss> it would seem to me that if we know exactly how many of some type of object we are eventually likely to use, it would help prevent overzellous jvm allocation
            
-
            16:28 <+Complication> Right, it makes those different allocations, which I've never really managed to make sense of
            
-
            16:28 < jrandom> aye, we do some of that cat-a-puss (see net.i2p.util.ByteCache)
            
-
            16:29 <+Complication> (but as said, Java is a very new thing to me)
            
-
            16:29 < jrandom> I've glanced at javolution before, but it seems to have made a lot of progress.  i'll give 'er another look
            
-
            16:30 < cat-a-puss> jrandom:I know some people at my work use it and are happy with it, though they don't care about memory allocation
            
-
            16:31 < jrandom> well, it really wouldn't save any memory, but would help cut down on GC churn
            
-
            16:31 <+legion> Well I personally don't care much about memory allocation, however many people do.
            
-
            16:31 < jrandom> ooh, and its BSD licensed too
            
-
            16:31 < cat-a-puss> right
            
-
            16:31 < jrandom> legion: memory allocation means performance
            
-
            16:32 <+legion> er, oh, memory consumption then
            
-
            16:33 <+legion> Many people are so very happy with utorrent because of it's very small memory footprint.
            
-
            16:33 < jrandom> ah, oh, yeah.  we can tweak it down the line, but since i2p runs within the default jvm sizes, i'm not too worried (as we've got lots of room for tweaking)
            
-
            16:34 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:35 <+legion> nah I'm good...
            
-
            16:37  * jrandom winds up
            
-
            16:37  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting159.html b/www.i2p2/pages/meeting159.html
deleted file mode 100644
index 62e28f3e..00000000
--- a/www.i2p2/pages/meeting159.html
+++ /dev/null
@@ -1,266 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 159{% endblock %}
-{% block content %}
            I2P dev meeting, December 6, 2005
            
-
            
-
            15:26 < jrandom> 0) hi
            
-
            15:26 < jrandom> 1) 0.6.1.7 and net status
            
-
            15:26 < jrandom> 2) Experimental tunnel failures
            
-
            15:26 < jrandom> 3) SSU and NATs
            
-
            15:26 < jrandom> 4) Syndie
            
-
            15:26 < jrandom> 5) ???
            
-
            15:26 < jrandom> 0) hi
            
-
            15:26  * jrandom waves
            
-
            15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001237.html
            
-
            15:26  * ailouros read the notes
            
-
            15:27  * jrandom is late, so I'll give y'all a moment to read up :)
            
-
            15:29 < jrandom> ok, might as well jump on in to 1) 0.6.1.7 and net status
            
-
            15:29 <@cervantes> *cough*
            
-
            15:29 < jrandom> I don't have much more to add beyond whats in the mail on this point.  anyone have any further comments/questions/ideas?
            
-
            15:30 < Pseudonym> seems like doing performance optimization before changing the the tunnel creation algo might be backwards
            
-
            15:30 < gott> I am getting a lot of "No HTTP method found in the request.
            
-
            15:30 < gott> Software caused connection abort: socket write error
            
-
            15:30 < gott> "
            
-
            15:30 <@modulus> tunnel lag is much lower, i don't know if you made any changes or my ISP is better all of a suden.
            
-
            15:30 < gott> from the I2PTunnel Webmanager
            
-
            15:31 < jrandom> gott: those suggest bad http requests, or things that the eepproxy ouldn't understand
            
-
            15:31 < jrandom> modulus: cool, we've been doing lots to try and improve things
            
-
            15:31 < jrandom> Pseudonym: well, so far tunnel creation hasn't been our choke point - our choke point was much higher level stuff
            
-
            15:32 < jrandom> otoh, the improvements of the last few revs have exposed some issues down there
            
-
            15:32 < Pseudonym> oh, so the optimization has been related to other parts of the code?
            
-
            15:32 < Pseudonym> cool
            
-
            15:33 < jrandom> aye, at the SSU level, as well as the tunnel operation level.  tunnel creation is not a performance sensitive operation [except when it is ;]
            
-
            15:34 < jrandom> I'm doing some live net load testing though, gathering some non-anonymous load stats of different peers to try to narrow things down further
            
-
            15:34 < ailouros> I wonder why sometimes I see more tunnels than those configured for a destination (eg. eeProxy, inbound 7 tunnels 4 outbound)
            
-
            15:34 < jrandom> so, over the next few days when you see the router 7xgV transferring lots of data, well, dont mind it ;)
            
-
            15:35 < jrandom> ailouros: when tunnel creation takes a while, it builds extras, just in case.  
            
-
            15:35 < jrandom> zzz outlines a few of the odd issues on that front too, and there's a patch being worked on to improve things a bit
            
-
            15:35 < ailouros> I see.. but then why they all expire at the same time?
            
-
            15:35 <@cervantes> jrandom: out of curiosity, when did you begin those tests?
            
-
            15:35 < jrandom> cervantes: a few days ago
            
-
            15:36 <@cervantes> ah cool, it's _not_ that then ;-)
            
-
            15:36 < jrandom> dunno ailouros, depends on a few conditions.  but there are some... *cough* oddities in the tunnel creation code, which I've been holding off messing with since its getting rewritten for 0.6.2
            
-
            15:38 < ailouros> I see. I thought it was a policy matter... I'd rather see the tunnels die at different times unless there's a good reason not to
            
-
            15:38 < ailouros> as in, tunnel creations are skewed
            
-
            15:39 < jrandom> aye, there will be better randomization for 0.6.2, and zzz's patch adds some randomization for the current rev too
            
-
            15:40 <+Complication> I wonder why an otherwise sane instance of i2phex... would decide to rehash files every other time I start it?
            
-
            15:40 < jrandom> not a clue
            
-
            15:40 <+Complication> Damaged configuration sounds the likely cause so far, but I've not deleted my config yet.
            
-
            15:40 < jrandom> perhaps skewed timestamps?
            
-
            15:42 <+Complication> Nah, they seem correct too
            
-
            15:42  * jrandom knows not.  never looked at that part of phex's cod
            
-
            15:42 < jrandom> er, code
            
-
            15:42 <+Complication> I'll see if deleting old config files does it any good
            
-
            15:42 < jrandom> cool
            
-
            15:43 < jrandom> ok, anything else on 1) Net status / 0.6.1.7?
            
-
            15:43 < jrandom> if not, moving on to 2) Experimental tunnel failures
            
-
            15:44 < jrandom> we've touched on this a bit already, and there's more in the notes and on zzz.i2p
            
-
            15:44 < jrandom> zzz: do you have anything you want to add/bring up?
            
-
            15:46 < jrandom> if not, lets move on to 3) SSU and NATs
            
-
            15:46 < jrandom> bar: anything you want to add?
            
-
            15:46 <+bar> nope, i have nothing else to add but what's in the mail
            
-
            15:47 < jrandom> cool, yeah I've still got to reply to some of the details - i think our retransmission will already take care of some of the issues you bring up
            
-
            15:48 < jrandom> the trick is going to be detecting which situation is in play, so we can automate the right procedure (or inform the user that they're screwed)
            
-
            15:48 <+bar> all in due time, no hurry
            
-
            15:49 <+bar> aye, i suggested a manual user setting to circumvent that problem for the time being, perhaps it's not possible, but we can discuss it later
            
-
            15:50 < jrandom> yeah, manual overrides will help, but my experience with earlier i2p revs was that everyone (*everyone*) fucked it up ;)  so automation is preferred 
            
-
            15:50 < jrandom> (everyone meaning myself included ;)
            
-
            15:52 <+bar> agree
            
-
            15:52 < ailouros> lol if I did too then there were something wrong with the docs, as I followed them bit by bit :D
            
-
            15:53 <+bar> meanwhile, i will spend some time studying the peer testing
            
-
            15:53 < jrandom> cool, thanks bar!
            
-
            15:54 <+bar> (perhaps i could generate some useless spam regarding that as well :)
            
-
            15:54 < jrandom> :)
            
-
            15:55 < jrandom> ok, if there's nothing else on 3), lets move on to 4) Syndie
            
-
            15:56 < jrandom> there has been a lot of progress on this front lately, with pretty substantial UI revamps since 0.6.1.7 came out
            
-
            15:57 < jrandom> there's also a new standalone install/build, though since all of us have i2p installed, we don't need a separate one 
            
-
            15:57 < ailouros> I find that 6.1.7's layout is harder to use than 6.1.6's
            
-
            15:58 < jrandom> hmm, are you running syndie in single user mode?  and/or are you using the latest CVS build or the official 0.6.1.7 build?
            
-
            15:58 < ailouros> official 0.6.1.7, single user
            
-
            15:58 < jrandom> are you one of the proponents of the blog-like interface, as opposed to the threaded nav?
            
-
            15:58 < ailouros> I am not, though I don't really know which is the blog-like
            
-
            15:58 < ailouros> personally I'd rather have a threaded nav
            
-
            15:59 < ailouros> (and some color-coding of new messages as well in thread view)
            
-
            15:59 <+Complication> Relatively late CVS, single user
            
-
            15:59 <+Complication> I've found a minor oddity (which I think, could be non-intended)
            
-
            15:59 < jrandom> ah, there has been a lot of progress on that front in CVS ailouros 
            
-
            15:59 < ailouros> great :)
            
-
            16:00 < jrandom> we've got a new threaded display too, using cervantes' suggested full traversal of just one branch, as opposed to all branches
            
-
            16:00 <@cervantes> are those changes pushed to syndiemedia.i2p.net?
            
-
            16:00 <+bla> Would it be a good idea to show some default examples for the location in http://localhost:7657/syndie/syndicate.jsp ?
            
-
            16:00 < jrandom> syndiemedia.i2p.net is CVS head, yeah
            
-
            16:00 <+Complication> When you've opened up a thread, and are currently reading its posts... and then choose to apply a filter to which no posts match (e.g. open thread "Syndie threading", apply filter "i2p.i2phex")...
            
-
            16:00 < jrandom> aye, perhaps bla.  new installs will have the three defaults in there, but examples would be good
            
-
            16:01 <@cervantes> (the actual thread's tree needs to fully open too though)
            
-
            16:01 <+Complication> ...it appears to leave the current posts displayed, as if they were matching or something...
            
-
            16:01 <+Complication> Despite me definitely clicking the "Go" button.
            
-
            16:01 <@cervantes> Complication: yeah I found that confusing too
            
-
            16:02 < jrandom> hmm Complication, the general idea was to let you browse around while still looking at a post, but perhaps it'd be best to drop the posts being displayed
            
-
            16:02 < jrandom> cervantes: ah, yeah expanding it to the leaf would be good, and should be trivial to do
            
-
            16:02 <+Complication> Just noticed, and since it stuck out, thought I'd tell
            
-
            16:02 <@cervantes> (or make it more obvious that there aren't any matches)
            
-
            16:03 < jrandom> well, the thread nav says *no matches* :)
            
-
            16:03 < ailouros> perhaps he's looking for a lighter
            
-
            16:03 < jrandom> !thwap
            
-
            16:03 <@cervantes> (or make it even more obvious that there aren't any matches)
            
-
            16:03 < jrandom> <blink>No matches</blink>
            
-
            16:03 <+Complication> Oops :)
            
-
            16:04 < tethra> seems your !thwap got spaetz__ instead, jr!
            
-
            16:04 <+Complication> Right, sometimes the thread navigator *does* feel a long distance away :)
            
-
            16:04 < jrandom> yeah, we're experimenting with some css to float that down the side, as an option
            
-
            16:05 <@cervantes> with skinning support you could have the thread top buttom left right etc
            
-
            16:05 <@cervantes> ah as jr said
            
-
            16:05 <+Complication> The "Threads" link takes one there fairly quick, though
            
-
            16:05 <+Complication> ...if it's within the viewport currently.
            
-
            16:06 <+Complication> And those who are used to keyboard-navigating can naturally press "End"
            
-
            16:06 < jrandom> of course, this stuff is really simple to modify (as you can see from the rapid changes in CVS :), so if anyone has any suggestions (or mockups - html / png / etc), please, post 'em up whenever
            
-
            16:07 < jrandom> I expect we'll have a main blog overview page in the next few days in cvs
            
-
            16:08 < jrandom> ok, there's lots of other stuff going on w/ syndie, so swing on by http://localhost:7657/syndie/ for more info :)
            
-
            16:08 < jrandom> anyone have anything else to bring up on that, or shall we move on to 5) ???
            
-
            16:09 < zzz> hi just walked in. on 2), I'm looking for testers for my patch.  
            
-
            16:10 < zzz> My results are improvements in job lag and reliability, and reduction in router hangs. So hoping others will try.
            
-
            16:10 < ailouros> that sounds good enough. what do I have to do?
            
-
            16:11 < jrandom> heya zzz, ok cool, i'll be bashing it around a bit here too.  its got lots of different components to it, so might be worth splitting up into pieces, but it does look good and is on track for 0.6.1.8
            
-
            16:11 < ailouros> (average uptime is about 10h here :(
            
-
            16:11 < zzz> If  you have source code and ant just apply the patch - or I can put up an i2pupdate.zip if you want
            
-
            16:12 < zzz> jrandom I'll work on splitting it up
            
-
            16:12 < ailouros> I'll go for the update, thanks
            
-
            16:13 < zzz> ailouros will put it on zzz.i2p within an hour - thanks
            
-
            16:13 < jrandom> zzz: I wouldn't worry about it unless you've got spare time... I can read through the diff :)
            
-
            16:13 < ailouros> thank you
            
-
            16:14 < zzz> jrandom OK. There's some miscellaneous stuff that can easily be ripped out by either you or me.
            
-
            16:16 < ailouros> I guess we're at 5) ??? now?
            
-
            16:16 < zzz> jrandom other topic  was Router OOMs with i2phex and possible SAM  issues
            
-
            16:16 < jrandom> aye ailouros 
            
-
            16:16 < jrandom> ah yeah zzz, it'd be great to track down whats up with SAM
            
-
            16:17 < ailouros> j346, did you have the chance to check out my app?
            
-
            16:17 < jrandom> what would Rule is if someone could jump on and take over maintenance of the SAM bridge, as I havent done any substantial work on it, and human hasn't been around for a while.
            
-
            16:19 < jrandom> not yet ailouros, unfortunately.  was a bit unsure about how it worked, so I've got to read through the source first
            
-
            16:20 < ailouros> feel free to ask
            
-
            16:20 < ailouros> (and good luck on the journey through the source, it's a good definition for the word "mess")
            
-
            16:20 < jrandom> hehe
            
-
            16:21 < zzz> correction my experience has been OOMs when using i2p-bt, not i2phex. Happens after about 24 hours when running one i2p-bt and in a few hours when running two i2p-bt
            
-
            16:22 <+Complication> Mine happened after some late-night stress-testing.
            
-
            16:22 <+Complication> (during which, let it be noted, I saw 5-minute averages of 50 KB/s)
            
-
            16:22 < bar_> could you please remind me what your app is/does, ailouros? my memory is good but short...
            
-
            16:22 <+Complication> Incoming, that is.
            
-
            16:22 <+Complication> Outgoing was limited to 35 KB/s
            
-
            16:22 <@cervantes> Complication: I've never heard it called late-night stress testing before...
            
-
            16:22 < jrandom> nice Complication 
            
-
            16:23 <+Complication> cervantes: well, one *could* call it semi-daily megaleeching then :P
            
-
            16:23 < ailouros> bar_: it's a working proof-of-concept for a distributed filesharing app which shares common blocks among differnt files (as suggested by polecat)
            
-
            16:23 < bar_> ah, right, thanks ailouros
            
-
            16:24 < tethra> cervantes: heheheh ;)
            
-
            16:24 < ailouros> you're welcome (if anyone wants to get the source, it's in c/c++)
            
-
            16:25 <+polecat> ailouros: Be careful, the chance of two binary blocks being the same is sufficiently rare, I'm mostly talking about pure theory that would be unuseful in practice.
            
-
            16:25 < ailouros> polecat, I agree. My best guess is that it comes useful when you get different versions of the same files
            
-
            16:25 < ailouros> like, a movie which has a corrupted block
            
-
            16:25 <+polecat> You could transfer blocks of zeroes at lightning speeds!  ("The next block is zeroes" "oh I have that already" "the next block is zeroes" "oh I have that already")
            
-
            16:26 < ailouros> or an archive of other zip files
            
-
            16:26 < jrandom> or e.g. modified ID3 tags, etc
            
-
            16:26 < ailouros> exactly
            
-
            16:26 <+polecat> True.  But an easy way to "fix" a movie with a corrupted block is to tell bittorrent to download on top of it.  Most clients will preserve the blocks whose hashes are the same, and overwrite the ones that are different.
            
-
            16:26 < jrandom> archives of files probably won't work though, since they'd have to break on file boundaries
            
-
            16:27 < ailouros> j636, that's why I want to implement LBFS's idea of splitting on data marks and not fixed block sizes
            
-
            16:27 <@cervantes> the DC community used that method, by sharing file distributions in rarsets
            
-
            16:27 <+polecat> What might be useful is to make a general binary error correction algorithm, then implement it on a huge scale.  All blocks could be "corrected" into each other, and you'd only have to transmit the correction data, which might be smaller than transmitting the block itself.
            
-
            16:29 <@cervantes> and then searches are basedon tiger hashes of those rar parts
            
-
            16:29 <+Complication> Nice thought... sounds difficult though :)
            
-
            16:29 <+polecat> But just a hash-for-hash equivalent... you'd never find two blocks alike!
            
-
            16:29 < ailouros> cervantes, what's a "rarset"? :D (except a "RAR file", that is)
            
-
            16:29 <+polecat> Unless both sides already had the file, one of them corrupted.
            
-
            16:29 < ailouros> polecat, uh?
            
-
            16:29 <@cervantes> ailouros: a split rar archive, with parity files if necessary
            
-
            16:30 < ailouros> cervantes: I don't understand the advantage of doing that
            
-
            16:31 <@cervantes> it's main benefit was to add pseudo-multi-source downloading to DC
            
-
            16:32 < ailouros> well, that's part of the block sharing mechanism between files, isn't it?
            
-
            16:34 < ailouros> polecat: about the bittorrent overwriting of damaged files, what it doesn't buy you is when you're trying to get multiple versions at once
            
-
            16:35 <@cervantes> your client only matches/downloads valid parts, if you have parity files you can also recover damaged parts 
            
-
            16:35 < ailouros> with my system there are no damaged parts (files are assembled only when the composing blocks are downloaded and re-checked)
            
-
            16:36 <@cervantes> stuff bittorrent does by default, except that you can't search specifically for individual parts
            
-
            16:36 <+polecat> Multiple versions aren't likely to have a single bit in common though... which is why they're so stupid.  Some jerk decides to re-encode the movie in postage stamp format, and gives it the same name.
            
-
            16:37 <+polecat> Or another jerk takes random data and names it by the file you want to download.
            
-
            16:37 < ailouros> lol that's correct
            
-
            16:37 <@cervantes> exactly and rarset releases are immune to that...
            
-
            16:37 < ailouros> but keep in mind that files from other networks (emule, kazaa, whatever) often come corrupted
            
-
            16:38 <+polecat> rarset releases aren't immune...
            
-
            16:38 <+polecat> You still have to figure out which rarset is the right one.
            
-
            16:38 < ailouros> cervantes, how are rarsets immune to an idiot publishing random junk?
            
-
            16:38 <@cervantes> (provided you have a reliable source)
            
-
            16:39 <@cervantes> because a release group publishes hashes/distribution information
            
-
            16:39 < ailouros> hahaha that's easy :D
            
-
            16:39 <@cervantes> and stuff is marked as nuked if it's poor quality, folk remove it from shares
            
-
            16:40 < ailouros> cervantes, that much my toy already does
            
-
            16:40 <@cervantes> cool
            
-
            16:40 < ailouros> you get the file descriptor from a trusted source, you multiget the file pronto
            
-
            16:41 <@cervantes> sounds good ;-)
            
-
            16:41 < ailouros> you don't get to sarch for files, but you can browse through each user's shared dire, so you can use a web crawler and cache the results
            
-
            16:42 < ailouros> though I might add a search function sometime in the future if deemed necessary
            
-
            16:44 < ailouros> I believe my toy, proprely developed into an app, can offer the caching and resiliancy the freenet people try to offer
            
-
            16:44 < ailouros> as in static content distribution and caching
            
-
            16:45 < ailouros> you read my blog, you cache it and offer it to other people when they want. you don't do anything more than leave the content there
            
-
            16:45 < ailouros> don't like the content? delete it and we're all set
            
-
            16:45 < jrandom> hmm, so do you see it as a backing store that could be used for syndie?  
            
-
            16:46 < ailouros> it CAN be used as a backing store
            
-
            16:46 < ailouros> as it is now, you might even use it in place of jetty, in i2p default installations
            
-
            16:46 < jrandom> e.g. attachments / links to [clunk hash="$foo"]my file[/clunk]
            
-
            16:46 < ailouros> (well with a couple of minor changes :D )
            
-
            16:46 < jrandom> heh
            
-
            16:47 < jrandom> ok, yeah, I definitely don't understand how clunk works... wanna post about it in syndie, or put up an eepsite?  :)
            
-
            16:47 < ailouros> file hashes are downloaded on file request, and these hashes are automagically downloaded into the full file
            
-
            16:48 < jrandom> right, but "down"loaded is a question of from where to where, etc.  an overal network architecture description would be helpful
            
-
            16:48 < ailouros> I'll write a decent doc first, then publish it somewhere
            
-
            16:48 < jrandom> r0x0r, thanks
            
-
            16:48 < ailouros> downloaded from wherever you got the hash from
            
-
            16:48 < ailouros> plus everyone else sharing these blocks
            
-
            16:49 < ailouros> think go!zilla and download accellerator :)
            
-
            16:49 < jrandom> I think you misunderstand how much I am confused
            
-
            16:49 < ailouros> but transparent and within i2p
            
-
            16:49 < ailouros> lol guess so :D
            
-
            16:50 < jrandom> a very, very basic explanation of e.g. "you run a clunk client, download from a clunk server, get info about clunk peers", etc
            
-
            16:50 < jrandom> do I use a web browser to query a clunk client?  or server?  or peer?
            
-
            16:51 < jrandom> (thats how lost I am)
            
-
            16:51 < ailouros> redo from 0 :)
            
-
            16:51 < ailouros> you use your web browser
            
-
            16:51 < ailouros> you connect to your client
            
-
            16:51 < ailouros> you browse others' dir with your browser
            
-
            16:51 < ailouros> you select which files to download with your browser
            
-
            16:51 < ailouros> your client does the dirty work
            
-
            16:52 < ailouros> you get the downloaded file back
            
-
            16:52 < ailouros> is this better? :)
            
-
            16:52 < jrandom> ok great, thanks - so the "browse other's dir" is done by your client querying their client and responding back with an HTML representation of it
            
-
            16:52 < ailouros> exactly
            
-
            16:52 < jrandom> (or pulled from some server/superpeer/etc)
            
-
            16:53 < jrandom> coo'
            
-
            16:53 < ailouros> all the dirty work (finding duplicates, multidownloads and so on) is done by your (local) client transparently
            
-
            16:54 < ailouros> what you see is, basically, a directory tree and some fiels you can download
            
-
            16:54 < jrandom> cool
            
-
            16:55 < ailouros> to publish your data you give away your public (p2p) address
            
-
            16:55 < ailouros> and to share files you copy them (or symlink them) to the pub/ directory (or some subdir). It's that easy
            
-
            16:57  * jrandom will dig through the source further, and look forward to more info :)
            
-
            16:57 < jrandom> ok, anyone else have anything for the meeting?
            
-
            16:57 < bar_> umm.. what's the difference between publishing and sharing, if i may ask? does publishing push the data to some datastore?
            
-
            16:58 < ailouros> bar_: sharing is giving the blocks to download. publishing is letting the world know what you share
            
-
            16:58 < ailouros> publishing is a subset of sharing
            
-
            16:58 < bar_> aha, gotcha, thanks
            
-
            16:58 < ailouros> for example, if you have half of a file, you share it but don't publish it
            
-
            16:59 < jrandom> how would people know they ould get those blocks from you then?
            
-
            16:59 < ailouros> and you have full control over which files you publish (unlike emule where every downloaded file is published)
            
-
            16:59 < ailouros> because each client periodically sends information to the network about which blocks he has to offer
            
-
            17:00 < jrandom> coo'
            
-
            17:00 < ailouros> sends to the network as in server (as is now) or DHT (future)
            
-
            17:00 < jrandom> so its mnet-esque, with a block tracker
            
-
            17:00 < ailouros> err mnet-esque?
            
-
            17:01 < jrandom> similar to how mnet (mnetproject.org) works
            
-
            17:01  * ailouros is reading mnetproject.org
            
-
            17:02 < ailouros> well, you have just your personal spaces, no shared spaces
            
-
            17:02 < ailouros> and you don't PUSH blocks around
            
-
            17:02 < jrandom> yeah, its not exactly the same as mnet, but it similar structurally
            
-
            17:03 < jrandom> its like mnet where everyone is too broke to have anyone host their data ;)
            
-
            17:03 < ailouros> yep
            
-
            17:03 < ailouros> :D
            
-
            17:03 < jrandom> ok, anyone else have anything else to bring up?
            
-
            17:04 < jrandom> if not...
            
-
            17:04  * jrandom winds up
            
-
            17:04  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting160.html b/www.i2p2/pages/meeting160.html
deleted file mode 100644
index 7592392d..00000000
--- a/www.i2p2/pages/meeting160.html
+++ /dev/null
@@ -1,55 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 160{% endblock %}
-{% block content %}
            I2P dev meeting, December 13, 2005
            
-
            
-
            15:15 < jrandom> 0) hi
            
-
            15:15 < jrandom> 1) Net status and load testing
            
-
            15:15 < jrandom> 2) I2PSnark
            
-
            15:15 < jrandom> 3) Syndie
            
-
            15:15 < jrandom> 4) ???
            
-
            15:15 < jrandom> 0) hi
            
-
            15:15  * jrandom waves
            
-
            15:15 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-December/001239.html
            
-
            15:15 < jrandom> (*before* the meeting this week - who woulda thunk it?)
            
-
            15:16 < jrandom> not that it matters, since y'all wait until the meeting starts to read it anyway ;)
            
-
            15:16 < jrandom> so, movin' on in to 1) Net status and load testing
            
-
            15:16 <@cervantes> hey!
            
-
            15:17 < jrandom> thanks for doing your part cervantes ;)
            
-
            15:17 <@cervantes> read what?
            
-
            15:17 -!- DreamTheaterFan [anonymous@irc2p] has quit [Connection reset by peer]
            
-
            15:17 < jrandom> I don't have much to add beyond whats in the mail, anyone have any questions or comments on 1)?
            
-
            15:19 < spaetz> is load testing performed on *the* i2p net or do you have a private net for this?
            
-
            15:19 < jrandom> I'm doing it on the live net
            
-
            15:19 < spaetz> just curious
            
-
            15:19 < spaetz> k
            
-
            15:20 < jrandom> its being done carefully though, backing off hard from peers under load, and it of course honors tunnel rejections
            
-
            15:20 <@cervantes> recent irc2p instability was unrelated to the tests
            
-
            15:21 <@cervantes> (in case you were wondering)
            
-
            15:21 < jrandom> hows the new setup handling things cervantes?  
            
-
            15:21 <@cervantes> been rock solid so far
            
-
            15:22 < jrandom> cool
            
-
            15:22 <@cervantes> just took some tedium to track down the source of the gremlins
            
-
            15:24 < jrandom> ok, anyone else have any questions/omments, or shall we jump on over to 2) I2PSnark?
            
-
            15:25 < jrandom> consider us jumped
            
-
            15:26 < jrandom> ok, basically I2PSnark should work again... there were a few attributes not yet in the BT spec but used by azureus and rufus, causing incompatibility, but we're now compatible with the situations I was able to see
            
-
            15:26 < jrandom> i2psnark now works with all of the torrents i've tested, but if anyone runs into trouble, let me know
            
-
            15:27 < jrandom> part of the drive for me to fix that up was in relation to some SAM bugs, since I2PSnark doesn't use SAM
            
-
            15:28 < jrandom> not much more to add on that front... unless anyone has any questions, lets move on over to 3) Syndie
            
-
            15:29 -!- Xunk [Xunk@irc2p] has quit [Connection reset by peer]
            
-
            15:30 < jrandom> ok, I don't have much to add beyond the email on that front either
            
-
            15:31 -!- Xunk [Xunk@irc2p] has joined #i2p
            
-
            15:31 < jrandom> if there aren't any questions re: Syndie, lets continue on and open the floor with 4) ???
            
-
            15:31 -!- DreamTheaterFan [anonymous@irc2p] has joined #i2p
            
-
            15:32  * jrandom remembers that clunk wasn't in the agenda, among other things.  anyone have anything they want to bring up?
            
-
            15:32 <@cervantes> man speeding though
            
-
            15:32 <@cervantes> *through
            
-
            15:33 -!- bar [bar@irc2p] has quit [Connection reset by peer]
            
-
            15:33 < jrandom> aye, no need to talk just to see words on the meeting logs :)
            
-
            15:33 -!- bar [bar@irc2p] has joined #i2p
            
-
            15:33 -!- mode/#i2p [+v bar] by chanserv
            
-
            15:33 -!- mule [mule@irc2p] has joined #i2p
            
-
            15:35 < jrandom> ok, if there's nothing else...
            
-
            15:35  * jrandom winds up
            
-
            15:35  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting161.html b/www.i2p2/pages/meeting161.html
deleted file mode 100644
index e8eb51e6..00000000
--- a/www.i2p2/pages/meeting161.html
+++ /dev/null
@@ -1,122 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 161{% endblock %}
-{% block content %}
            I2P dev meeting, December 20, 2005
            
-
            
-
            15:20 < jrandom> 0) hi
            
-
            15:20 < jrandom> 1) Net status
            
-
            15:20 < jrandom> 2) I2PSnark updates
            
-
            15:20 < jrandom> 3) Syndie blog UI
            
-
            15:20 < jrandom> 4) ???
            
-
            15:20 < jrandom> 0) hi
            
-
            15:20  * jrandom waves
            
-
            15:20 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001240.html
            
-
            15:22 < jrandom> ok, jumping on in to 1) Net status
            
-
            15:22 < jrandom> I don't have much to add beyond whats in the status notes.
            
-
            15:22 <+Complication> If it weren't for the occasional OOM's, I'd dare call it good
            
-
            15:22 < jrandom> the load testing is looking quite promising, suggesting that we have a lot of room to improve performance
            
-
            15:23 <+Complication> And I guess the OOM
            
-
            15:23 < jrandom> heh, i2psnark related OOMs?  or from before that?
            
-
            15:23 <+Complication> 's contribute to flakyness, when either i2p-bt, i2psnark, or i2p-rufus  instances do... things.
            
-
            15:24 < zzz> my theory is that increased torrent traffic is somewhat hurting IRC reliability
            
-
            15:24 <+Complication> (perhaps I shouldn't be calling the SAM oddity an OOM, since I've not looked at it closely, but it's one of the factors definitely)
            
-
            15:24 < jrandom> hmm, I'm not sure, as the irc status was similar to before the latest snark updates
            
-
            15:25 <+Complication> Bandwidth has been solid, part. tunnels solid too... just crashing now and then
            
-
            15:26 < zzz> In any case I'm optimistic the tunnel build fixes coming in 0.6.1.8 will improve people's IRC experience
            
-
            15:26 <+Complication> For known reasons, which hopefully go away when their time comes :)
            
-
            15:26 < jrandom> aye, I think so too zzz, so we'll probably have a release in the next day or so
            
-
            15:26 <+legion> Well irc might just be too sensitive, maybe just using something like jabber would be better?
            
-
            15:26 < zzz> especially for people on slower machines and/or connections
            
-
            15:27 < jrandom> jabber would not change things
            
-
            15:27 <+Complication> Especially with tunnel redundancy at 2
            
-
            15:28 <+bar> i'd say irc is an excellent crap-o-meter for determining the network weather
            
-
            15:28 <+legion> Yeah, the wind just blows a little and irc craps out
            
-
            15:28 <+bar> exactly :)
            
-
            15:28 <+Complication> I notice that after the shitlisting fix, "Recent" tends to always exceed "Known"
            
-
            15:29 <+Complication> Would this be because "Known" doesn't include shitlisted peers, while "Recent" does?
            
-
            15:29 < jrandom> aye, irc is a good view on things, as its shown substantial variation on different users (e.g. dreamtheaterfan always has trouble, etc)
            
-
            15:30 < jrandom> hmm, that makes sense Complication 
            
-
            15:30 <+Complication> (I'm not sure if it does, just guessing)
            
-
            15:30 < jrandom> (as shitlisted peers are dropped from the netDb, but their profiles are not removed)
            
-
            15:32 <+Complication> Then the indicators seem OK (just wanted to ask in case they wouldn't)
            
-
            15:33 < jrandom> ok, anything else on 1) Net status?
            
-
            15:33 < jrandom> if not, lets move on over to 2) I2PSnark updates
            
-
            15:33 < tealc_>  what sort of updates are available?
            
-
            15:34 < jrandom> see http://dev.i2p.net/pipermail/i2p/2005-December/001240.html for a brief listing ;)
            
-
            15:34 < jrandom> basically I2PSnark can now handle multiple torrents at once over a single I2P destination, has a web interface, and is built into the router console
            
-
            15:35 < tealc_> i'm running of the latest cvs builds and i2psnark is causing a lot of memory heap errors or whatever
            
-
            15:35 <+Complication> ...and it also handles Azureus-created torrents with odd meta-tags.
            
-
            15:35 <+Complication> Which it previously got stuck on.
            
-
            15:35 < jrandom> ah, yeah, there are still some things I'm debugging in there tealc_ 
            
-
            15:35 < jrandom> (as mentioned in the weekly status notes ;)
            
-
            15:35 < jrandom> ah right Complication 
            
-
            15:36 < jrandom> oh, also, the Azureus folks have fixed a bug in their tracker that would keep I2PSnark from using it
            
-
            15:36 < jrandom> (so people running azureus trackers prior to B16 should upgrade at their earliest convenience)
            
-
            15:37 <+bar> i'd like to have the possibility to easily disable the i2psnark autostart (for low bw scenarios, etc.)
            
-
            15:38 < jrandom> that should be easy enough to add in
            
-
            15:38 <+bar> sounds great
            
-
            15:39 < jrandom> ok, anything else on 2) I2PSnark updates?  
            
-
            15:40 < jrandom> if not, lets move on to 3) Syndie blog UI
            
-
            15:40 < zzz> two thumbs up on the new i2psnark - good job
            
-
            15:41 < jrandom> gracias, mjw did the hard work, making snark so easy to extend
            
-
            15:41 < jrandom> ok, as mentioned in the status notes, syndie now has a new blog UI
            
-
            15:42 < jrandom> I think it'll offer a balance between whitelists and blacklists, dealing with the different spam issues available to people
            
-
            15:43 < jrandom> we'll have that rolled out in the next release, so y'all can dig in to it in a day or two
            
-
            15:43 <+legion> Is spam really going to become much of a problem anytime soon?
            
-
            15:44 <+Complication> legion: as someone was kindly willing to demonstrate, it could be
            
-
            15:44 < jrandom> nah, blacklists take care of authors who flood, and whitelists take care of spammers who create lots of authors
            
-
            15:44 < dust> (anonymity brings out the worst in a some people)
            
-
            15:44 < jrandom> (so spamming is not a problem)
            
-
            15:45 <+Complication> (Although I think the fellow was regenerating keys to avoid perma-blacklisting, which *is* somewhat of a slow-down.)
            
-
            15:45 <+Complication> Although not a big slow-down, and thus I whole-heartedly agree that whitelists are good too. :)
            
-
            15:46 <+bar> perhaps some hashcash solution could be feasible down the road, if necessary
            
-
            15:46 < jrandom> if necessary, but I don't see why it would be
            
-
            15:46 <+bar> agree, right now, i don't either
            
-
            15:46 <+Complication> bar: like "don't show unless they've bothered to crunch some numbers"?
            
-
            15:47 <+bar> yes, something along that line
            
-
            15:47 <+Complication> Sounds possible, even if probably needless.
            
-
            15:47 <+bar> probably so.
            
-
            15:47 < jrandom> if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog
            
-
            15:47 <+Complication> Or more like, hopefully needless.
            
-
            15:48 <+Complication> Might be good to consider if Syndie can accommodate such functionality, should need ever arise.
            
-
            15:49 < jrandom> aye, it can, with headers in the blog post or in the blog's own metainfo
            
-
            15:49 < jrandom> er, metadata (damn you bt!)
            
-
            15:51 < jrandom> ok, if there's nothing else on 3) Syndie, lets jump on to 4) ???
            
-
            15:51 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            15:51 <+legion> yes a couple things
            
-
            15:52 <+legion> first clunk
            
-
            15:52 < jrandom> cool, yeah clunk sounds interesting
            
-
            15:52 <+legion> As I mentioned earlier today in i2p-chat, I've been working on getting it to compile with cygwin and or mingw.
            
-
            15:53 <+legion> So far just the client is broken, the rest including the server compiles and seems to work
            
-
            15:53 < jrandom> neat
            
-
            15:54 < tealc_> i2p could prove to be a real hairball for George Bush's limitless surveillance program.   I'll see you guys in the death camps, bring the cards ya
            
-
            15:54 <+legion> Been trying to not only track down why the client is broken, but also resolve it. At the moment I'm stuck.
            
-
            15:56 <+legion> The other thing I was meaning to discuss, was could a default tunnel to my jabber server be included in the next update? Just to make things easier for anyone that wants to try out jabber.
            
-
            15:57 < tethra> 20:34:37 <jrandom> if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog <--- perhaps something to the effect of polecat's way of combining trust could play a role in this? (ie to both block spammers -and- promote popular authors.)
            
-
            15:57 < tethra> </$0.02>
            
-
            15:58 <+polecat> That would be a primitive example of my trust network idea, with a heuristic of 100% trust transfer, yes.
            
-
            15:58 < jrandom> legion: hmm, adding a disabled config is easy enough for new users, but the hesitancy I have is regarding protocol filtering (and what clients leak what info).  what is your experience with different clients?
            
-
            15:59 < jrandom> aye, there is a lot of room for integration of trust metrics into syndie
            
-
            16:01 <+legion> Well far as I know jeti doesn't leak, other than its filetransfer, which is disabled in my server settings anyways. Possibly the next jeti version will have it corrected. Other than that I don't know about the other clients.
            
-
            16:02 <+legion> I do know for sure the groupchat is solid, regardless of clients, it is just contact outside of the groupchat which some clients might leak, though I'm not sure.
            
-
            16:03 < jrandom> hmm, leaking isn't really a boolean, its a matter of /what information/ the clients leak, not whether they leak any information
            
-
            16:04 <+legion> Right, I was of course referring to any critical information like ip addresses, though good clients should if they do leak that information only report it as 127.0.0.1 or localhost
            
-
            16:06 <+legion> So I would recommend only using known clients which don't leak, such as jeti.
            
-
            16:07 < zzz> could you add a verified-doesn't-leak column to your client chart?
            
-
            16:07 < jrandom> it'd be useful if you could doc up what jeti does and does not leak (along the lines of what postman put together for the smtp and pop proxy)
            
-
            16:08 <+legion> According to jeti's developer it does not leak anything that would comprimise ones anonymity. That much is certain without a doubt. I've also looked through its source and have not found anything which would make me think otherwise.
            
-
            16:09 < jrandom> that the developer said it may be certain, but what the developer understands about anonymity is another question ;)
            
-
            16:09 <+legion> Yeah zzz I could add another such column
            
-
            16:09 < jrandom> I don't doubt the possibility that jeti behaves properly, but we need to know what that means
            
-
            16:10 < zzz> seems like non-leakage can only be verified by protocol tracing
            
-
            16:10 < zzz> not by looking at source or asking developer
            
-
            16:12 < jrandom> ok, does anyone have anything else for the meeting?
            
-
            16:12 <+bar> just a reminder not to forget amd64 jbigi
            
-
            16:13 <+bar> (but i bet it's on your todo list)
            
-
            16:13 < jrandom> aye :)
            
-
            16:13 < jrandom> (win amd64, that is, linux amd64 is already working)
            
-
            16:13 < jrandom> but, if there's nothing else...
            
-
            16:14  * jrandom winds up
            
-
            16:14 <+bar> yes, win amd64.
            
-
            16:14  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting162.html b/www.i2p2/pages/meeting162.html
deleted file mode 100644
index 385f327c..00000000
--- a/www.i2p2/pages/meeting162.html
+++ /dev/null
@@ -1,93 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 162{% endblock %}
-{% block content %}
            I2P dev meeting, January 4, 2006
            
-
            
-
            15:22 < jrandom> 0) hi
            
-
            15:22 < jrandom> 1) Net status and 0.6.1.8
            
-
            15:22 < jrandom> 2) Load testing results and peer profiling
            
-
            15:22 <@cervantes> jrandom: arguably the slowest most horrific punishment since they banned stoning
            
-
            15:22 < jrandom> 3) 2005 review / 2006 preview / ???
            
-
            15:22 < jrandom> 0) hi
            
-
            15:22 < gott>   falafel
            
-
            15:22 < gott>        n : small croquette of mashed chick peas or fava beans seasoned
            
-
            15:22 < gott>            with sesame seeds
            
-
            15:22 <@cervantes> hullo
            
-
            15:22  * jrandom waves after recovering from the falafel pelting
            
-
            15:22 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001246.html
            
-
            15:23 < jrandom> as I'm 10m late, I'm sure y'all have already read those notes and have comments ready
            
-
            15:23 < jrandom> *cough*
            
-
            15:23 < jrandom> ok, lets jump on in to 1) net status and 0.6.1.8
            
-
            15:24 <@cervantes> ie. it works well, except protocol is slowing it down
            
-
            15:24 < jrandom> I don't have much to add beyond whats in the mail - we had 0.6.1.8 cooking for a while before the release, and its gone pretty well from what I can tell
            
-
            15:25 < jrandom> heh yeah, I'm not sure if infoshop has posted anything since the last rss import
            
-
            15:25 < JosephLeBlanc> Hmm, well I have just a couple of comments.
            
-
            15:25 <+Complication> With regard to status, though I've mentioned before... after build -7 got into CVS, my Celeron 300 seems to behave like an actual computer. It like, transfers data with a resemblance of stability.
            
-
            15:26 <+Complication> Lets me extensively browse eepsites, and only rarely kicks me from IRC.
            
-
            15:26 < jrandom> word Complication 
            
-
            15:26 < jrandom> whats up JosephLeBlanc 
            
-
            15:26 <@cervantes>  /kick complication
            
-
            15:26 <@cervantes> doh
            
-
            15:26 < JosephLeBlanc> I am running the latest CVS and, afaics, most things are in order.
            
-
            15:27 < JosephLeBlanc> However, I was wondering if that jbigi athlon problem was fixed which I talked to you about some time ago.
            
-
            15:28 < jrandom> jbigi for amd64 on window isn't yet in jbigi.jar, though I hope to get it into 0.6.1.9
            
-
            15:29 <+Complication> I *think* (but can't confirm) that it's focusing more tightly on peers it has seen success with... and this approach *may* keeps those paths from collapsing more effectively (it's behind a somewhat too agressive NAT).
            
-
            15:29 < JosephLeBlanc> Well, the logs are returning: 'NOTICE: Resource name [jbigi] was not found' 
            
-
            15:30 < jrandom> JosephLeBlanc: there is a line after that regarding jbigi - what does it say?
            
-
            15:31 < JosephLeBlanc> It reads, "INFO: Optimized native BigInteger library 'libjbigi-linux-athlon.so' loaded from resource
            
-
            15:31 < jrandom> ok great
            
-
            15:32 < JosephLeBlanc> Just wanted to give you a heads up about that NOTICE line.
            
-
            15:32 < jrandom> that means it first tries to pull the resource "jbigi", but it doesn't exist (which is normal - the jbigi resource is for very rare situations)
            
-
            15:32 < jrandom> it then tries to pull the OS/architecture specific resource "libjbigi-linux-athlon.so" and succeeds
            
-
            15:33 < JosephLeBlanc> Ah, okay. Then, it seems that whatever bug I was experiencing earlier has been fixed in -7
            
-
            15:33 < jrandom> w3wt
            
-
            15:33 < JosephLeBlanc> Thanks a billion, bud.
            
-
            15:34 < jrandom> np
            
-
            15:34 < jrandom> Complication: aye, I think you're right, and some of the strategies for 0.6.2 will build on that concept further
            
-
            15:35 < jrandom> ok, anyone else have something for 1) net status / 0.6.1.8?
            
-
            15:37 < jrandom> if not, lets move on to 2) Load testing results and peer profiling
            
-
            15:39 < jrandom> ok, lots of stuff in the email, does anyone have any questions on it?
            
-
            15:40 <+bar> how big was the resonable improvement?
            
-
            15:41 <+Complication> Late remark about 0.6.1.8 (just tested with my laptop) - jbigi was loaded correctly there too.
            
-
            15:42 <+Complication> Previously, this machine (Mandriva 2005) was failing to load the correct one.
            
-
            15:42 <+Complication> Due to the jcpuid problem.
            
-
            15:42 < jrandom> I'd rather not quote a number in the meeting, as it'll affect people's expectations.  measureable improvement, but nowhere near wire speed.
            
-
            15:43 < jrandom> (and the load test is a bit contrived)
            
-
            15:43 <+bar> alrighty np :)
            
-
            15:44 < jrandom> cool complication.  Yeah, I finally bundled up scintilla's C jcpuid port :)
            
-
            15:45 < jrandom> ok, I don't have much to add on 2) beyond whats in the mail.  More info on the resulting speed profiling will come out once its shipped in 0.6.1.9.
            
-
            15:47 < jrandom> if there's nothing else on that, jumping on to 3) 2005 review / 2006 preview / ???
            
-
            15:49 <+bar> i agree with what's in the mail, 2005 was a fantastic year and i can't see 2006 becoming any worse, i2p wise
            
-
            15:49 < jrandom> we've come a long way in the last year, and y'all have done lots of great work pushing us forward.  this coming year looks to be the big one for us, moving out of the geeky backrooms and into the venues where it matters.  
            
-
            15:50  * tethra came in towards the wrong end of 2005, but it was still pretty damn cool. *thumbs up*
            
-
            15:51 <+Complication> Hoping for the best.
            
-
            15:51 < jrandom> I don't have much more to add, so if there's other stuff that people want to bring up for the meeting, the floor is open
            
-
            15:52 <+Complication> Speaking of which, if someone wanted to translate some docs into Spanish (see Discussion forum), whom would it be best for them to coordinate with?
            
-
            15:52 <+Complication> e.g. which parts are liable to change heavily, or such matters
            
-
            15:53 <+Complication> Also, in which format would it be best to have various docs?
            
-
            15:54 < jrandom> the tech intro doc @ dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD is fairly stable
            
-
            15:54 <+Complication> Included with the router... on the website... both?
            
-
            15:54 < jrandom> (there will be updates on 0.6.2 though)
            
-
            15:54 < jrandom> well, I'm hugely in favor of inline documentation
            
-
            15:54 < jrandom> but that should probably wait until the new router console is in place
            
-
            15:55 < jrandom> website intro docs would be good as well, but that should probably wait until the new website is in place
            
-
            15:55 <+Complication> Aha... so it would be best to not touch that yet...
            
-
            15:56 <+Complication> ...instead preferring docs like the above.
            
-
            15:58 < jrandom> probably.  ok, is there anything else people want to bring up for the meeting?
            
-
            15:59 < jrandom> if not...
            
-
            15:59 < tethra> did we discuss the eepget UI idea yet?
            
-
            15:59 < gott> If the meeting is still on, please fix the trouble with accents in IRCclient
            
-
            15:59 < tethra> ie, before i got here
            
-
            15:59 < jrandom> nope, wanna implement it tethra?  :)
            
-
            15:59 < jrandom> gott: patches welcome
            
-
            16:00 < gott> If not, please fix the trouble with accents in IRCclient.
            
-
            16:00 < gott> jrandom: By the time, I fix it, it will be fixed by somebody else ;-)
            
-
            16:01 < tethra> jrandom: i'm not entirely sure how to go about it, as i'm not much a coder. if you feel like pointing me at any tutorials in writing .war type apps and i'll be glad to have a shot, though.
            
-
            16:01 < gott> I reserve the right to be defeatist in deed and action.
            
-
            16:01 < tethra> haha
            
-
            16:01 <+Complication> :)
            
-
            16:02 < jrandom> tethra: the oreily servlets books are pretty good
            
-
            16:02 < jrandom> ok, if there's nothing else...
            
-
            16:02  * jrandom winds up
            
-
            16:02  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting163.html b/www.i2p2/pages/meeting163.html
deleted file mode 100644
index d2111a5e..00000000
--- a/www.i2p2/pages/meeting163.html
+++ /dev/null
@@ -1,176 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 163{% endblock %}
-{% block content %}
            I2P dev meeting, January 10, 2006
            
-
            
-
            15:26 < jrandom> 0) hi
            
-
            15:26 < jrandom> 1) Net status
            
-
            15:26 < jrandom> 2) Throughput profiling
            
-
            15:26 < jrandom> 3) Syndie blogs
            
-
            15:26 < jrandom> 4) HTTP persistent connections
            
-
            15:26 < jrandom> 5) I2Phex gwebcache
            
-
            15:26 < jrandom> 6) ???
            
-
            15:26  * jrandom waves
            
-
            15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001247.html
            
-
            15:27 < jrandom> (yeah, I know... we need a 7) One more thing...)
            
-
            15:28 < jrandom> jumping on in to 1) Net status 
            
-
            15:28 < jrandom> In general, seems the same ol' same ol', beyond whats in the mail.  
            
-
            15:28 < jrandom> Anyone have anything they want to bring up about 1)?
            
-
            15:30 < jrandom> ok, if not, moving on over to 2) Throughput profiling
            
-
            15:31 < tethra> it sounds cool, but may i ask what the objective is?
            
-
            15:31 < jrandom> find fast peers
            
-
            15:31 < tethra> (forgive my lack of wit and tact)
            
-
            15:31 < tethra> ah, cool.
            
-
            15:32 < jrandom> basically, our old speed profiling wasn't that great (see last week's status notes for a summary), and this seems to be pretty good at finding peers that I know are fast
            
-
            15:32 < jrandom> (I know they're fast because I've cheated and measured them with non-anonymous techniques)
            
-
            15:33 < tethra> shocking! ;)
            
-
            15:33 < jrandom> ((yes, someone could have been crazy and mounted attacks to confuse my measurements, but, well, I doubt it ;)
            
-
            15:33 < tethra> haha
            
-
            15:33 < tethra> sweet, so that should make client tunnels more likely to find a 'good' peer and presumably put the 'fast' peers under less pressure, then?
            
-
            15:35 < tethra> s/'good'/fast/
            
-
            15:35 < jrandom> yes to the former, but not really to the later - it won't reduce the pressure on them, but it will let people make more effective use of them
            
-
            15:35 <@cervantes> I guess the folks with fast peers will have to hope the peer throttling is good enough to take the extra participation
            
-
            15:36 < jrandom> e.g. rather than having $slow-->$fast-->$fast, it'll have $fast-->$fast-->$fast
            
-
            15:36 < tethra> ah, i see
            
-
            15:36 < jrandom> aye cervantes, I've been paying attention to the capacity profile as well, and its been doing the trick
            
-
            15:36 <@cervantes> grand
            
-
            15:37 < jrandom> the interplay between capacity and speed is important - peers are not considered fast if they are not high capacity, even if their speed is ranked higher than everyone else
            
-
            15:37 <@cervantes> be interesting to see how it effects througput
            
-
            15:37 < jrandom> (which is why 'fast' is just shorthand for 'fast and high capacity')
            
-
            15:37 <@cervantes> +h
            
-
            15:37 < jrandom> aye cervantes
            
-
            15:39 < jrandom> ok, if there's nothing else on 2, lets jump on over to 3) Syndie blogs
            
-
            15:40 < jrandom> I don't have much more to add beyond whats in the mail there
            
-
            15:41 <@cervantes> it's looking swell
            
-
            15:41 < tethra> i very much like where the blogs are going, personally. it seems to all be gravy, one might say.
            
-
            15:41 < tethra> :D
            
-
            15:41 <+Complication> Bit late, sorry.
            
-
            15:42 < jrandom> cool, its similar to how it was originally, but I think the blog view has some promise
            
-
            15:42 < jrandom> wb Complication, no worry, we've got logs :)
            
-
            15:43 <+Complication> Reading scrollback right now :)
            
-
            15:43 < jrandom> I do think there's a place for both views, I suppose it just depends on the user
            
-
            15:43 < jrandom> (and the content, and the author)
            
-
            15:45 < jrandom> one thing though is that the html aint that grand.  cervantes has been helping me revamp my very basic education to a more modern view, but there are lots of issues left
            
-
            15:46 < jrandom> there will be continuing improvements to syndie's web interface, and if some html volunteer wanted to help out with formatting, design, css, cross browser issues, etc, it would be much appreciated
            
-
            15:47 <@cervantes> other than having 2 opening <style> tags the code looks pretty clean ;-)
            
-
            15:47 < jrandom> heh oops
            
-
            15:48 <@cervantes> I think the emphasis will be on getting the styling clean and readable and perhaps designing some template alternatives
            
-
            15:48 < jrandom> hmm
            
-
            15:49 < jrandom> thats one thing I was thinking about for the blog view - it'd be easy to let people customize certain attributes (colors, fonts, sizes), but I'm not sure how much more
            
-
            15:50 < jrandom> otoh, the blog view, like the thread view, is all just a template over the syndie archive
            
-
            15:50 <@cervantes> well you certainly don't want to allow deployable templates
            
-
            15:50 < jrandom> so the question is, a template for whom?
            
-
            15:50 < jrandom> (what level of experience would those using the template require)
            
-
            15:51 <@cervantes> I was thinking just a popup config option someone can choose for their blog
            
-
            15:51 < jrandom> hmm?
            
-
            15:51 <@cervantes> I want "Pony Look"
            
-
            15:51 < jrandom> ah, ok
            
-
            15:51 <@cervantes> so we ship syndie with a variety of skins
            
-
            15:52 < jrandom> yeah, preset colors/font/etc
            
-
            15:52 < jrandom> (and icons, etc)
            
-
            15:52 < jrandom> thats one thing that hasn't really been implemented through the blog view yet
            
-
            15:54 < jrandom> good idea on the simple theme chooser though, rather than some complex set of options
            
-
            15:54 <@cervantes> an alternative would be someone can offer their own template presets as a download on their site - which could be saved into a theme folder
            
-
            15:55 <@cervantes> it's up to the individual if they want to trust the blog author's custom skin
            
-
            15:55 < jrandom> ... trust?
            
-
            15:55 < jrandom> nothing in syndie will let you do unsafe html or css
            
-
            15:55 < tethra> what of unsafe javascript/etc
            
-
            15:55 < jrandom> the skins would be text files/config files/images, rather than jsp
            
-
            15:55 < tethra> ?
            
-
            15:56 < tethra> (page forwards to non-anonymous addresses with js, for instance?)
            
-
            15:56 <@cervantes> it depends if a theme might also contain structural html changes 
            
-
            15:56 <@cervantes> right ok
            
-
            15:56 <@cervantes> well that would keep it nice an clean and simple
            
-
            15:57 < jrandom> tethra: I'm... incredibly hesitant about javascript.  seen that new blog post today from default?
            
-
            15:57 < jrandom> "I'm just curious: does it use AJAX? The page doesn't seem to update as a whole..."
            
-
            15:57 < tethra> nein, i did not.
            
-
            15:57 < tethra> i'd find a way to just shag any js that is used, personally.
            
-
            15:58 < jrandom> since syndie is *local*, its insanely fast, and we don't need do worry about the same latency issues
            
-
            15:58 < tethra> as i don't trust it as far as i can throw it.
            
-
            15:58 < tethra> hmm :/
            
-
            15:58 < jrandom> cervantes: aye, very simple - we could even do things like let people viewing a blog theme they like say "steal this theme"
            
-
            15:59 <@cervantes> in theory you could provide a library of "safe" functions fo blog user - but by the time you remove everything that is unsafe from the average browser's implementation you're left with the "alert();" function
            
-
            16:00 < jrandom> heh
            
-
            16:00 < jrandom> (and you've got all those accessibility issues of javascript)
            
-
            16:00 <+Complication> cervantes: mind you, alert() in an infinite loop can be bad :P
            
-
            16:00  * jrandom is quite proud of syndie's lynx-friendliness
            
-
            16:00 < tethra> lynx <3
            
-
            16:02 < jrandom> ok, if there's nothing else on 3), lets jump on over to 4) HTTP persistent connections
            
-
            16:02 < jrandom> I don't have anything to add beyond whats in the mail... zzz, you here?
            
-
            16:02 <@cervantes> there are other ways of implementing a *spit* AJAX ui, like a mozilla extension
            
-
            16:03 < jrandom> fire2pe++ :)
            
-
            16:03 < jrandom> zzz doesn't seem to be around, so we'll probably have to wait for later for more info on 4)
            
-
            16:03 <@cervantes> fire2pe is just a helper - syndilla is what you mean ;-)
            
-
            16:03 < jrandom> lol
            
-
            16:04 < jrandom> (and, the usb keychain version, syndog ;)
            
-
            16:04 < jrandom> ok, moving on to 5) I2Phex gwebcache
            
-
            16:05 < jrandom> Complication: p1ng
            
-
            16:05 <+Complication> Well, since it would make integrating with the net easier...
            
-
            16:06 <+Complication> ...I've recently worked on reviving the gwebcache code already in I2Phex
            
-
            16:06 <+Complication> It's already doing some very limited things (like crash neatly) at this stage :)
            
-
            16:06 <+Complication> Also pesters awup's webcache server with moderate success
            
-
            16:07 < jrandom> lol nice
            
-
            16:07 <+Complication> I have hope though, that eventually I'll get it reworked
            
-
            16:07 <+Complication> (lots of it is currently meant to deal with IP addresses)
            
-
            16:09 < jrandom> cool, good luck, and lemmie know if there's anything I can do to help
            
-
            16:09 <+Complication> Will do :)
            
-
            16:10 < jrandom> ok, anything else on 5) I2Phex gwebcache, or shall we mosey on over to 6) ???
            
-
            16:11 < jrandom> consider us moseyed
            
-
            16:11 < jrandom> anyone have anything else for the meeting?
            
-
            16:11 <@cervantes> another cup of tea would be nice
            
-
            16:12 < tethra> heheh
            
-
            16:12 < Pseudonym> how's the roadmap?
            
-
            16:12 < jrandom> no changes
            
-
            16:12 < Pseudonym> what's left for 0.6.2?
            
-
            16:13 < jrandom> all of the 0.6.2-related stuff
            
-
            16:13  * jrandom ducks
            
-
            16:14 < Pseudonym> :-P
            
-
            16:14 <@cervantes> some bling bling
            
-
            16:14 < Pseudonym> do we have a tentative date/timeline?
            
-
            16:14 < jrandom> specifically, the new tunnel creation crypto and algorithms, the new peer selection strategies
            
-
            16:14 < tethra> heheh
            
-
            16:14 < jrandom> no dates and timelines (at least, not announced in meetings ;)
            
-
            16:15 < Pseudonym> is there more to peer selection strategies than the throughput stuff you've been working on?
            
-
            16:16 < jrandom> yes, these peer profiling changes are performance issues, not the anonymity related peer selection and ordering strategies
            
-
            16:16 <+Complication> jrandom: do I remember correct... if I guess the tunnel creation crypto related to things discussed on the mailing list, during the talk about predecessor (and other) attacks?
            
-
            16:17 < jrandom> yeah Complication 
            
-
            16:17 <+Complication> s/related/relates
            
-
            16:19 <+Complication> You're going to try making that fancy lil' datastructure work?
            
-
            16:19 < jrandom> aye
            
-
            16:20 < jrandom> (hence, 0.6.2 is not on the 2 week horizon ;)
            
-
            16:20 <+Complication> Neat. Sounds interesting, I should probably read up about it
            
-
            16:21 <+Complication> I hope it goes smoothly
            
-
            16:21 < jrandom> it was only arm-waved around on the list, no spec digitized yet
            
-
            16:21 < tethra> which neat datastructure is this, sorry?
            
-
            16:21 <+Complication> Oh, and figured why the link (from the "moo" message) wouldn't work. :D It's freedomarchives.i2p (in the plural, with an "s" at end)
            
-
            16:21 < jrandom> it'll be backwards incompatible, so smooth won't be its catchphrase, but hopefully won't hurt too much :)
            
-
            16:21 < jrandom> ah bugger
            
-
            16:22 < jrandom> tethra: a datastructure that doesn't exist yet for creating tunnels
            
-
            16:22 < tethra> cool
            
-
            16:22 < jrandom> (see the predecessor threads from november or so)
            
-
            16:23 < tethra> what advantages/disadvantages will it have over the current one? (if there is a current one :o)
            
-
            16:23 < jrandom> (see the predecessor threads from november or so) ;)
            
-
            16:23 < tethra> ah, ok
            
-
            16:23 <+Complication> IIRC, to make tunnel creation less transparent to observers
            
-
            16:23 < tethra> ""
            
-
            16:23 < tethra> ;)
            
-
            16:23 < jrandom> but, its not a proposal, there is nothing on the table for 0.6.2 until all of the things prior to 0.6.2 are sorted.
            
-
            16:23 < jrandom> once the things that should be working are working in the manner that we need them to work, then we move on.
            
-
            16:24 < Pseudonym> other than fast peer selection, what's not working?
            
-
            16:25 < jrandom> fast peer selection is a part of "good performance"
            
-
            16:25 < jrandom> we /do/ have good performance, for an anonymous network, but not good enough to compete with non-anonymous networks
            
-
            16:25 < jrandom> to compete, we've got to get better performance *and* provide functionality they can't get elsewhere
            
-
            16:26 < jrandom> (anonymity does not sell)
            
-
            16:26 < Pseudonym> is there more to it than fast peer selection?
            
-
            16:27 < jrandom> through the last month or two, benchmarking different aspects of i2p, slow peer selection seems to be the smallest bottleneck.  what the next bottleneck will be is unknown.
            
-
            16:27 < jrandom> (there have also been countless improvements at different points to improve performance)
            
-
            16:27 < jrandom> (see http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD )
            
-
            16:28 < Pseudonym> so... release of new peer selection this week? ;-)
            
-
            16:28 < teal`c_> i2p feels good
            
-
            16:29 < jrandom> Pseudonym: aye, new peer profile algorithm is in cvs and will be deployed this week with 0.6.1.9
            
-
            16:30 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:30 < Pseudonym> cool
            
-
            16:31 < jrandom> if not...
            
-
            16:31  * jrandom winds up
            
-
            16:32  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting164.html b/www.i2p2/pages/meeting164.html
deleted file mode 100644
index 75f811b2..00000000
--- a/www.i2p2/pages/meeting164.html
+++ /dev/null
@@ -1,267 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 164{% endblock %}
-{% block content %}
            I2P dev meeting, January 17, 2006
            
-
            
-
            15:40 < jrandom> 0) hi
            
-
            15:40 < jrandom> 1) Net status and 0.6.1.9
            
-
            15:40 < jrandom> 2) Tunnel creation crypto
            
-
            15:40 < jrandom> 3) Syndie blogs
            
-
            15:40 < jrandom> 4) ???
            
-
            15:40 < jrandom> 0) hi
            
-
            15:40  * jrandom waves
            
-
            15:40 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html
            
-
            15:41 <@cervantes> pfff, good job i2p is more reliable than NASA
            
-
            15:41 < jrandom> heh 
            
-
            15:41 < tethra> haha
            
-
            15:41 < jrandom> (though I am 20 minutes late... ;)
            
-
            15:41 < jrandom> anyway, lets jump on in to 1) Net status and 0.6.1.9
            
-
            15:42 < wmpq> NSA or NASA, not that diffrent are they?
            
-
            15:42 <@cervantes> I said I2P not jrandom ;-)
            
-
            15:42 < jrandom> good point cervantes ;)
            
-
            15:42 < tethra> don't be silly, jrandom IS i2p! ;D
            
-
            15:42 <@cervantes> oh I thought it was a way of thinking
            
-
            15:42 < wmpq> [redact]
            
-
            15:43 < jrandom> heh well, anyway, 0.6.1.9 is out and about, with 70% of the net upgraded (thanks y'all)
            
-
            15:43 < Pseudonym> mmmm, tasty new release
            
-
            15:44 <+zzz> client tunnel build success remains < 30%
            
-
            15:44 < jrandom> I haven't heard many reports of substantially increased end to end throughput, though some routers are more than saturating T1 lines
            
-
            15:44 <+zzz> down from ~40%
            
-
            15:44 <+Complication> Bandwidth seems normal, a bit higher than on the last CVS before release. Peer counts look a big higher.
            
-
            15:45 < jrandom> hmm, yeah, I'm not really worried about that zzz, since its all getting completely reworked for 0.6.2
            
-
            15:45 <+zzz> avg BW up from ~12K to ~20K
            
-
            15:45 < jrandom> 0.6.1.9 shouldn't pick peers more liable to agree (meaning, high capacity), but should instead focus on those who have higher throughput
            
-
            15:46 <+Complication> Retransmission percentage (noted 7% on the night of release) has come down to 6 point something
            
-
            15:46 < jrandom> aye, with routers pushing 1-300KBps, there's going to be a skew
            
-
            15:46 < jrandom> hmm, thats a pretty crazy rate Complication, i've only seen 2-3%
            
-
            15:46 < jrandom> (but I don't doubt what you see)
            
-
            15:47 <+Complication> I'm maxing out my outbound, pretty much
            
-
            15:47 <+Complication> (and I mean maxing out the line capacity)
            
-
            15:47 < jrandom> ah, that'd do the trick
            
-
            15:47 <+zzz> still getting NULLs before gets which results in 405 bad method, rate may be declining, hard to say for sure
            
-
            15:48 < jrandom> yeah zzz, there are some things that need to be worked through in the streaming lib, but I probably won't get to that until after the 0.6.2 tunnel revamps
            
-
            15:48 < jrandom> (but if someone wants to dig in further before that, that would rule, of course)
            
-
            15:49 < jrandom> Complication: if you reduce your bw limiter to something like 70% of your line capacity, does the failure rate go back to a reasonable value?
            
-
            15:49 <+zzz> I still think it was something that went in the code just before new years, so better to look at before those recent changes are forgotten :)
            
-
            15:50 <+zzz> First seen Dec. 29
            
-
            15:50 < jrandom> yeah zzz, it certainly was.  likely related to how we now honor timeouts.
            
-
            15:51 <+Complication> jrandom: I'm actually trying that currently :)
            
-
            15:51 <+Complication> Adjusted a few seconds before you asked, but won't know very soon, I guess
            
-
            15:51 < jrandom> but there is substantial work that needs to be done in there to clean it up, and its more important to get the new tunnel creation code implemented (which will substantially improve tunnel build success rates, as well as add a whole set of anonymity improvements)
            
-
            15:51 < jrandom> cool Complication, yeah, give it 3-6 hours 
            
-
            15:51 < jrandom> (to clear out the old values / connections)
            
-
            15:52 <+zzz> ~ 1% - 3% of GETs are corrupted atm
            
-
            15:54 < jrandom> so do you suggest reverting the streaming lib changes (so that i2psnark will OOM all of its users in 12-48 hours) and put off further streaming lib rework until after the 0.6.2 tunnel work, or push out the 0.6.2 tunnel work for a week or two while revamping the streaming lib?
            
-
            15:55 <+zzz> certainly don't revert
            
-
            15:56 <+zzz> your call
            
-
            15:56 <+Complication> It's a fairly sly bug, I can only say
            
-
            15:58 < jrandom> there are other bugs in the streaming lib, so if I'm going to roll up my sleeves, I'd want to tackle them all together (since none of the remaining bugs are apparent).  
            
-
            15:59 < jrandom> on the other hand, we'll have substantial bandwidth usage reduction, increased build success percentage, better anonymity, and an improved ability to monitor load balancing on the live net by going with the tunnel work first
            
-
            15:59 < Pseudonym> if it's only a 1-3% failure rate on surfing, I'd say it can wait, but that's just my opinion.
            
-
            16:00 < jrandom> I'm leaning towards doing the tunnel work first, since after deploying it, we can passively monitor the network while actively revamping the streaming lib
            
-
            16:01 < jrandom> (I'd also like to build a GUI for editing/posting to Syndie, but that can wait until after both of those things are sorted ;)
            
-
            16:01 <+Complication> That's what the rate is like, here too
            
-
            16:02 <+Complication> (on my eepsite)
            
-
            16:04 < jrandom> Ok, I think it'd be great if y'all can keep an eye on things to see if those rates changes, but in the meantime, I'll continue on with the tunnel revamp, after which will come the streaming lib revamp (both of which will be in place before 0.6.2)
            
-
            16:05 < jrandom> (or, if somene wants to dig into the streaming lib [or see if there's some odd interaction with i2ptunnel], lemmie know!)
            
-
            16:06 <+Complication> jrandom: out of curiosity, could one exclude i2ptunnel with a test app?
            
-
            16:07 <+Complication> e.g. if something like jnymo's sample app would *also* receive nulls, that would clear i2ptunnel from the list of suspected causes?
            
-
            16:07 < jrandom> one could wire up a thin (in-VM) I2PSocket implementation to do that, certainly 
            
-
            16:07 <+Complication> Since, IIRC, that sample used the streaming lib directly...
            
-
            16:08 <+Complication> (or pretty directly)
            
-
            16:08 < jrandom> aye, of course if something using the streaming lib can duplicate it, it would exonerate i2ptunnel
            
-
            16:10 <+Complication> Hmm, unless someone else gets first (I'll try finishing with the webcache thingy first) I might try emulating HTTP with something like that...
            
-
            16:10 < jrandom> wikked, thanks Complication
            
-
            16:10 < jrandom> ok, anything else on 1) Net status and 0.6.1.9?  
            
-
            16:11 < jrandom> if not, lets mosey on over to 2) Tunnel creation crypto
            
-
            16:11 <+Complication> Nah, it may lead to nothing useful, or I may stumble on halfway... but it's a possibility which intrigues me
            
-
            16:11 < jrandom> aye, definitely worth exploring Complication
            
-
            16:12 < jrandom> (and explorations do not have to have positive results to be worthwhile :)
            
-
            16:12  * cervantes spots a "moo" exception in the source changes leading up to new year....perhaps that's the issue? :)
            
-
            16:13 < jrandom> ok, there's a new tunnel creation crypto spec referenced in the email, based on the discussion toad, Michael, and myself had on the mailing list last october
            
-
            16:14 < jrandom> give 'er a look and lemmie know your thoughts - it won't be deployed on the live net for a while, as there are other things that need to be implemented first, but its coming
            
-
            16:14 <+Complication> Is "moo" a reserved word for Java? ;P
            
-
            16:14 <+zzz> on 2) I'll help review references in status mail
            
-
            16:14 <+Complication> On the tunnel crypto subject, do you mind checking if the following rephrase is decent - I'd just like to ensure I've understood it right...
            
-
            16:14 < jrandom> thanks zzz
            
-
            16:15 <+Complication> "Each hop encrypts all records with their reply key, which they decrypted from their record, using their ElGamal private key, and by encrypting in such fashion, reverses one layer of decryption (or should I say, encryption) done by the tunnel owner, rendering the next participants' record readable with the next participant's ElGamal private key?"
            
-
            16:15 < jrandom> Complication: yes
            
-
            16:15 <+Complication> Or is my rephrase plain wrong?
            
-
            16:16 <+fox> <jme___> and way to complicated, if i may
            
-
            16:16 < jrandom> its correct I believe, but yeah, too many clauses :)
            
-
            16:16 <+Complication> I didn't think of a better way to visualize it. 'Twas hard enough that way. :P
            
-
            16:16 < jrandom> (or jme___ are you saying the algorithm is too complicated?)
            
-
            16:17 <+fox> <jme___> nope i tried rapidely to read the doc and give up as too many things require prior knowledge
            
-
            16:17 <+fox> <jme___> on the other hand i didnt try much :) other things to do
            
-
            16:17 < jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD
            
-
            16:18 <+fox> <jme___> is this peer review a formality, or you are really worried/unsure of it ?
            
-
            16:19 <+Complication> Well, it's always good to know what an underlying mechanism is doing...
            
-
            16:19 < jrandom> I'm confident that it does what I intend for it to do, but I am sincerely interested if someone can see a problem
            
-
            16:19 <+fox> <jme___> if the second i could spend the time, but my knowledge is old and not on top of my head
            
-
            16:20 <+fox> <jme___> if not i trust :)
            
-
            16:20 < jrandom> the notes section has some questions - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes 
            
-
            16:22 < jrandom> there's no rush, it'll probably be a week or two before this new crypto is actually used in the router 
            
-
            16:22 <@cervantes> jrandom: on those, would there be much of a performance hit on injecting a random delay between hops?
            
-
            16:22 <@cervantes> as that seems the most sensible option to prevent timing attacks
            
-
            16:23 < jrandom> its tunnel creation, so a delay wouldn't hurt, though could cause premature lease set expiration under catastrophic failures
            
-
            16:25 < jrandom> well, I'm not sure how effective those delays would be.  they may help substantially, but they may not.  live tunnels, however, can simply use blending to detect colluding peers on that tunnel anyway though, so I'm not sure it matters
            
-
            16:25 <+fox> <jme___> ok rereading it
            
-
            16:27 < jrandom> thanks.  ok, no rush, but if/when anyone has any thoughts, bounce 'em my way (or to the list, or to your blog, etc)
            
-
            16:27 < jrandom> ok, anything else on 2, or shall we move on to 3) Syndie blogs?
            
-
            16:29 < jrandom> (consider us moved)
            
-
            16:29 < jrandom> ok, new neat bloggy stuff in syndie, dig in ;)
            
-
            16:29 <@cervantes> v.cool
            
-
            16:30 < jrandom> the groups on the left can contain links to arbitrary urls, as well as links to blogs, posts within blogs, or attachments to posts within blogs
            
-
            16:30 < jrandom> there are a whole slew of enhancements possible, too, such as adding per-blog or per-tag styling for posts, icons, etc.  if someone wants to dig into that, it'd rule (and have a highly visible impact :)
            
-
            16:31 <@cervantes> btw external links defined in comments should also have a title attribute set to the target url (as you have done on the left panel)
            
-
            16:31 <@cervantes> comments/posts
            
-
            16:32 < jrandom> ah, good idea
            
-
            16:33 < jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer method renderLinks(...) :)
            
-
            16:34 <@cervantes> *scribble*
            
-
            16:35 < jrandom> what else do the syndie blogs need for them to offer a functional alternative to informational eepsites?  obviously, syndie is static content, so you can't do some things, but you can publish content and let people comment
            
-
            16:36 < jrandom> are there particular customizations you want to be able to do?  if so, lemmie know
            
-
            16:37 < DoubtfulSalmon> jrandom: updating existing content via script?
            
-
            16:37 <@cervantes> archive by date
            
-
            16:37 < jrandom> DoubtfulSalmon: via script?
            
-
            16:37 < jrandom> cervantes: ah, like a little calendar widget, rather than the "5 older entries" links?
            
-
            16:38 <@cervantes> yup
            
-
            16:38 < DoubtfulSalmon> jrandom: say I want this file/text to replace that file/text. How do I do that?
            
-
            16:38 < jrandom> ok cool, yeah, that should be really easy (if someone whips up the html :)
            
-
            16:38 <@cervantes> or more simply "view last month's posts"
            
-
            16:39 <@cervantes> jrandom: you just need a 7x6 table with some numbers in it ;-)
            
-
            16:40 < jrandom> DoubtfulSalmon: changing content that has been published is an interesting direction.  across the board, it wouldn't always work, since it'd have to operate like usenet control messages (cancelling an old post, etc)
            
-
            16:40 < jrandom> DoubtfulSalmon: on the other hand, you can simply post a new file/entry and change the links on the left hand side to point to the new file/entry
            
-
            16:40 < jrandom> (that way, the old content is still there, but people are directed to the new content)
            
-
            16:41 < DoubtfulSalmon> jrandom: yeah, it would be ok if the old content was still there, as long as everyone's links pointed to the new content, without them having to change their content.
            
-
            16:41 < jrandom> building a full blown wiki out of it, essentially posting diffs with syndie rendering them result, is possible, but may be overkill
            
-
            16:41 < jrandom> hmm, ok I see what you're saying
            
-
            16:42 < jrandom> so, you want the ability to have redirectable links, rather than the existing links to exact versions of content
            
-
            16:43 < jrandom> perhaps that could be done by linking to a blog's bookmark, and the exact version is found by loading that blog's current bookmarks and seeing where it points
            
-
            16:44 < jrandom> otoh, the new version could be marked as a reply to the old post, so when people follow a link, they can follow it to the reply which replaces the content
            
-
            16:44 < jrandom> (though thats probably not as seamless)
            
-
            16:44 < DoubtfulSalmon> yeah: say I want to have a link to say: a current radar image, or somthing like that that will be upadated every 10 min. It's ok if the contet doesn't fly all over the net, but if someone else links to my page, the user should see the current image.
            
-
            16:45 < jrandom> well, that depends on what they want to do - do they want to link to the image as it was when they referred to it, or do they want to link to the service that renders the image when the reader views it
            
-
            16:45 <+Complication> cervantes: oddity of the day :D Last post in: http://forum.i2p/viewtopic.php?t=1199&start=15
            
-
            16:46 <+Complication> Felt like it might be another of our robotic overlords :P
            
-
            16:46 < jrandom> but its a good idea to support both concepts, and I don't think it'd be much trouble
            
-
            16:46 <@cervantes> thnx
            
-
            16:46 < jrandom> though it'd need a small extension to sml (e.g. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.png"])
            
-
            16:47  * cervantes will upgrade forum defenses if we start to get a lot of them
            
-
            16:47 <@cervantes> (already know how to stop that one)
            
-
            16:47 < DoubtfulSalmon> jrandom: they should be able to link to both a static version of it, provided the syndicator has not deleted the content, as well as a generic url that points to whatever is the latest version
            
-
            16:47 < jrandom> (which would look at ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c='s current meta post for bookmarks, pulling the exact uri from the one named "radar.png")
            
-
            16:48 < DoubtfulSalmon> jrandom: could that be done now with something like: "View most recent one post in tag <weird string>"
            
-
            16:48 < jrandom> ah, good point - yes, it could
            
-
            16:49 < jrandom> that could even be restricted to "View most recent post by $author with tag $tag"
            
-
            16:49 < jrandom> (so other people couldn't spoof it)
            
-
            16:49 < DoubtfulSalmon> so maybe just put some sort of UI so the user does not have to see weird tags and what not
            
-
            16:50 < jrandom> there's an example of how that looks up there, though I don't have the uri offhand... but yeah, is a link around the linked text
            
-
            16:50 < DoubtfulSalmon> I assume all of that information can come in URL form.
            
-
            16:51 < jrandom> but this is definitely complicated to write the source SML, which is why a GUI to create SML would be useful
            
-
            16:51 < jrandom> they're attributes on the SML tags, not URLs
            
-
            16:52 <@cervantes> and SML gui will be tricky without javascript
            
-
            16:52 < DoubtfulSalmon> but you can bookmark a search result right?
            
-
            16:52 < jrandom> what is a search result?
            
-
            16:52 < jrandom> and what do you mean by bookmark?
            
-
            16:52 <@cervantes> (or a browser extension ;-)
            
-
            16:52 < jrandom> oh, browser side bookmarks,  yes
            
-
            16:52 <+Complication> A filter result?
            
-
            16:53 < jrandom> but those bookmarks are not generally shareable
            
-
            16:53 < DoubtfulSalmon> er: a "get most resent 1 post by X with tag Y" 
            
-
            16:53 < jrandom> (actually, most are, but its not universal, since they're URLs not URIs))
            
-
            16:53 < DoubtfulSalmon> yeah, it would be good if other bolgs could link to those too
            
-
            16:54 < jrandom> DoubtfulSalmon: they can, with sml
            
-
            16:54 < jrandom> [blog tag="Y" bloghash="X"]
            
-
            16:54 < DoubtfulSalmon> oh goodie
            
-
            16:55 < jrandom> cervantes: javascript, or xul, or java, or some other OS-specific client app
            
-
            16:57 <@cervantes> ah cool, so you don't mind a scripting or plugin dependancy
            
-
            16:57 < jrandom> (when our website gets revamped for 0.6.2, syndie will definitely get a website explaining wtf this whole syndie thing is, and how it can do everything short of wash the dishes ;)
            
-
            16:57 <@cervantes> (as long as it degrades gracefully)
            
-
            16:57 < jrandom> cervantes: syndie should be function with lynx, but there's lots of room for rich clients
            
-
            16:58 < jrandom> (s/function/functional/)
            
-
            16:58 <@cervantes> right..so lynx uses would get an SML reference chart, but nothing more
            
-
            16:58 < jrandom> aye, as we have now
            
-
            16:58 < jrandom> though perhaps a simplified sml, dunno.
            
-
            17:01 <+Complication> jrandom: do you think it might be even remotely plausible... that the null bug might be related to gzip encoding?
            
-
            17:01 <+Complication> I was thinking of how to disable gzipping for my eepsite tunnel...
            
-
            17:01 <+Complication> Or would that be entirely implausible?
            
-
            17:01 <@cervantes> there was some http compressor stuff added just before new year in i2ptunnel
            
-
            17:03 < jrandom> aye, it could - yo ucan disable it on the client side with i2ptunnel.gzip=false (on /configadvanced.jsp).  atm I don't think you can disable it in i2ptunnelhttpserver though
            
-
            17:03 <+zzz> it's on the request side where there isn't any compression
            
-
            17:03 <+zzz> server won't compess if client set to false
            
-
            17:03 <+Complication> zzz: oh, right, I forgot that
            
-
            17:04 < jrandom> (but without too much trouble you could add it to I2PTunnelHTTPServer [line 310, etc)
            
-
            17:04  * Complication is a fool, and apologizes for that
            
-
            17:04 <@cervantes> (or you could use a normal tunnel)
            
-
            17:04 <+Complication> Aha, thanks...
            
-
            17:05 < jrandom> hmm, though by the time the i2ptunnelhttpserver receives the GET, the null is already there
            
-
            17:05 <+zzz> yup I did get orion moved back to HTTP tunnel which greatly helps load times for his pages since now compressed again
            
-
            17:05 <+Complication> I somehow entirely forgot that gzipping starts when the client and server have *agreed* to do it
            
-
            17:05 < jrandom> so it may be on the client side, but definitely not the server side
            
-
            17:05 < jrandom> yeah zzz, its pretty insanely fast now :)
            
-
            17:05 <+zzz> its on the _request_ side not the _response_ side - could be on either client or server side
            
-
            17:06 < jrandom> true
            
-
            17:09 < jrandom> ok, anyone else have anything on 3) Syndie blogs?
            
-
            17:09 < jrandom> if not, lets jump on to 4) ???
            
-
            17:09 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            17:10 < cat-a-puss> Complication: Java's gzip stream + I2P tunnels. Does NOT work and it's sun's bug
            
-
            17:10 < jrandom> hmm cat-a-puss?  really?
            
-
            17:10 <+zzz> HTTP persistent connections update: client side mostly done, server side making good progress, lots of bulletproofing and testing to do, est. completion 2-4 wks
            
-
            17:10 < jrandom> nice1 zzz!
            
-
            17:11 < cat-a-puss> jrandom: yeah I talked to you about that a long time ago, I could probably find the long explination as to why, but it's probably best to just document that somewhere as there is no reason to do it.
            
-
            17:12 < jrandom> hmm I'm out of context, what exactly does not work?  what is sun's bug?  
            
-
            17:14 < dust> i get weird logs like this: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html>
            
-
            17:14 < jrandom> hmm, interesting
            
-
            17:15 < jrandom> what tracker?
            
-
            17:15 < cat-a-puss> jrandom: As I recall sun uses headerless zips and some magic number to tell that it's a zip stream. But the number just so happens to be negitive, so if you endup creating a zip stream within a zip stream for some reason, it reads the data out of the stream as a sequence of unsigned bytes and so the magic number gets converted to some other positive number. (I am probably missing some detail but that is the gist of it)
            
-
            17:16 < dust> for example the  OSDevWithCVS_3E.pdf.torrent
            
-
            17:17 < dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ...
            
-
            17:17 < jrandom> hmm, I don't know anything about that, and I'm not sure how it'd affect gzip stream over i2ptunnel (if it /did/, they'd all fail, because we gzip evertthing)
            
-
            17:19 < jrandom> ok cool dust, so postman's tracker.  hmm, are you on 0.6.1.9 dust?
            
-
            17:20 < cat-a-puss> jrandom: yeah it's been almost a year now sense I had that problem so I don't remember too well, and I don't know if it is fixed in 1.5 but I did have a reall devil of a time trying to figure out why every normal type of stream would work, but as soon as I wrapped them in a compressed stream they would all fail.
            
-
            17:20 < dust> yes
            
-
            17:20 < jrandom> cat-a-puss: we've changed things dramatically for compression over i2p in the last year ;)
            
-
            17:21 < jrandom> (and I don't personally use 1.5)
            
-
            17:21 < jrandom> but we do our own zip encoding explicitly, rather than use their packaged stream (but for anonymity / efficiency reasons, not compatability)
            
-
            17:22 <@cervantes> zzz: where exactly in the request does the null happen? right after GET?
            
-
            17:22 <+Complication> Before, if I remember
            
-
            17:23 <+fox> <lordalbert> hi
            
-
            17:23 <+Complication> Sidenote: Celeron 300 shows twice lower retran. percentage than Sempron
            
-
            17:23 < jrandom> 'lo lordalbert
            
-
            17:23 < jrandom> cool Complication, 2-3% is reasonable (though I'd prefer lower, of course)
            
-
            17:23 <@cervantes> would be interesting to fire off a load of HEAD requests or something...
            
-
            17:24 < jrandom> yeah, a set of local tests would be great, though iirc Complication tried that a while back with no errors
            
-
            17:24 <+fox> <lordalbert> can anyone make a anonymous tracker? I try it but i dont' understand how use the tunnel
            
-
            17:24 <+Complication> cervantes: I once tried provoking it, with a recursive wget between my 2 nodes
            
-
            17:24 <+Complication> Grew tired before it happened
            
-
            17:25 <@cervantes> heh
            
-
            17:26 <+fox> <lordalbert> 'lo b0unc3 ;)
            
-
            17:26 <+fox> <b0unc3> lordalbert, :D
            
-
            17:26 <+Complication> lordalbert: which part would you need advise about?
            
-
            17:27 <+Complication> About setting up trackers, I unfortunately don't know.
            
-
            17:27 <+Complication> About I2PTunnel, I could try explaining...
            
-
            17:27 <+fox> <lordalbert> I have installed BTtracker, and it work perfectly
            
-
            17:28 <+Complication> It should also be noted that, for the tracker to *remain* anonymous, it should likely run a pretty careful config
            
-
            17:28 <+fox> <lordalbert> now, i'd like anonimise it
            
-
            17:28 <+fox> <lordalbert> so
            
-
            17:28 < jrandom> I'm sure we can help work through it after the meeting.  you shouldn't use generic trackers, you need one built for anonymity
            
-
            17:28 <+fox> <lordalbert> i have just made a i2ptunnel
            
-
            17:29 < jrandom> (e.g. the bytemonsoon modification that you can find on any of the i2p trackers, or in the cvs)
            
-
            17:29 <+fox> <lordalbert> now, i'd like to know how use this tunnel. I have made a tunnel yet
            
-
            17:29 < jrandom> ok, anyone have anything else for the meeting?
            
-
            17:30 < jrandom> lordalbert: http://localhost:7657/i2ptunnel/ should let you create an 'http server tunnel' pointing at your webserver/tracker, but your tracker will not work unless it has been modified for anonymous use
            
-
            17:30 <+fox> <lordalbert> jrandom, what tracker i must use?
            
-
            17:31 <+Complication> postman uses a modified version of ByteMonsoon, I think
            
-
            17:32 < jrandom> i2p-bytemonsoon has been modified for anonymous use - there's a zip up @ http://i2p-bt.postman.i2p/, and there's the cvs in http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ but I really don't know much about it
            
-
            17:32 <+fox> <lordalbert> isn't bytemonsoon obsolete?
            
-
            17:32 < jrandom> if it works, its not obsolete.  it works
            
-
            17:33 <+fox> <lordalbert> ok XD
            
-
            17:33 < jrandom> there are many trackers out there, and if some developer wants to modify it to work safely and anonymously, that'd be great
            
-
            17:33 <+Complication> May well be oldish... but definitely works with destkeys instead of IP's...
            
-
            17:33 <+Complication> Can't tell about security and leakproofness
            
-
            17:34 < jrandom> (it was modified by duck et al for anonymity and security)
            
-
            17:34 <+Complication> But it's been up for a while, and seems to manage...
            
-
            17:35 < jrandom> ok, if there's nothing else for the meeting...
            
-
            17:36  * jrandom winds up
            
-
            17:36  * jrandom *baf*S the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting165.html b/www.i2p2/pages/meeting165.html
deleted file mode 100644
index 299f3be6..00000000
--- a/www.i2p2/pages/meeting165.html
+++ /dev/null
@@ -1,114 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 165{% endblock %}
-{% block content %}
            I2P dev meeting, January 24, 2006
            
-
            
-
            15:25 < jrandom> 0) hi
            
-
            15:25 < jrandom> 1) Net status
            
-
            15:25 < jrandom> 2) New build process
            
-
            15:26 < jrandom> 3) ???
            
-
            15:26 < jrandom> 0) hi
            
-
            15:26  * jrandom waves
            
-
            15:26 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2006-January/001254.html
            
-
            15:26 -!- Teal`c [tealc@irc2p] has joined #i2p
            
-
            15:26 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]
            
-
            15:26 < bar> hi
            
-
            15:26 < jrandom> lets jump on in to 1) Net status
            
-
            15:26 -!- gloin [gloin@irc2p] has joined #i2p
            
-
            15:27 < jrandom> I don't have much more to add beyond whats in the mail... anyone have any questions/comments/concerns?
            
-
            15:27 <+Complication> Moving to CVS build -6 has been... challenging
            
-
            15:28 < jrandom> aye, understandable
            
-
            15:28 <+Complication> Net is probably doing fine. It's just my node whcih isn't.
            
-
            15:28 <+Complication> =which
            
-
            15:28 < bar> it's a rough road, but it's the right road. i'm 100% supportive of this move
            
-
            15:29 < jrandom> tunnel building on 2+ hop tunnels is a pain, with nasty failure rates as has been reported
            
-
            15:29 < jrandom> much of this is likely to be addressed with 0.6.2's new creation crypto, but I'm not convinced that all of it will be.
            
-
            15:30 < jrandom> I do wonder whether we'll be able to get it reliable enough prior to that though.  But we'll try
            
-
            15:31 <+Complication> If there's any stats I can provide (though you probably have more than enough of them at your own disposal) just ask
            
-
            15:31 < jrandom> so, 1 hop tunnels are fairly reliable on the latest builds, but those who need 2+ hop tunnels should expect... bumps
            
-
            15:31 < jrandom> thanks Complication
            
-
            15:32 <+Complication> Most of my apps are 2+0..1
            
-
            15:32 <+Complication> And the router itself too, if I remember correct
            
-
            15:33 < jrandom> well, I could suggest staying at the release, but the release will be building short tunnels anyway if and when it encounters catastrophic failures
            
-
            15:34 < jrandom> (s/short/1hop/)
            
-
            15:34 <+Complication> Right, I could probably adjust it to 2+0
            
-
            15:34 <+Complication> And have less spectacular effects
            
-
            15:35 < jrandom> aye, though that'll still, in effect, turn to 2+/-1, but it'll try its best to stay at 2hops
            
-
            15:36 <+Complication> With build -6 too?
            
-
            15:36 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]
            
-
            15:36 < jrandom> no, the current release will fail hard rather than go to fallback tunnels
            
-
            15:37 <+Complication> Or is there probability involved, which never quite goes zero?
            
-
            15:37 < jrandom> the trouble there is that if it goes for 10 minutes without building the tunnels, it'll restart the router (due to the watchdog)
            
-
            15:37 <+Complication> Saw it once :)
            
-
            15:37 < jrandom> no, -5 or newer will use exactly the hop lengths allowed by the client (2+/-0 means only 2 hop tunnels.  never anything else)
            
-
            15:39 < jrandom> ok, anyone have anything else for 1) Net status?
            
-
            15:39 < jrandom> or, I suppose we're already discussing 2) New build process ;)
            
-
            15:40 < jrandom> does anyone have anything else to discuss on 2) New build process?
            
-
            15:40 <+Complication> Not much here, anymore :D
            
-
            15:41 < jrandom> hehe ok, if not, lets shimmy on over to 3) ???
            
-
            15:41 < jrandom> anyone have anything else they want to discuss?
            
-
            15:42 < bar> may i ask, how many backwards incompatible changes are lined up now, and if some (all?) can be put into one release?
            
-
            15:42 < bar> i mean, is there more than one backwards incompatible release planned, until 0.6.2?
            
-
            15:42 < jrandom> bar: the hope is to do them all at once
            
-
            15:42 < jrandom> (though there may be further ones down the line)
            
-
            15:43 -!- Complication [Complicati@irc2p] has quit [Connection reset by peer]
            
-
            15:43 -!- Complication2 [Complicati@irc2p] has joined #i2p
            
-
            15:43 < bar> hmac bug, new crypto and restricted routes at once?
            
-
            15:43 < bar> that's a tall order :)
            
-
            15:43 < jrandom> restricted routes?
            
-
            15:43 < jrandom> the hmac bug "fix" is changing one value ;)
            
-
            15:44 < bar> ah :)
            
-
            15:44 -!- Complication2 is now known as Complication
            
-
            15:44 < bar> umm.. perhaps restricted routes was 2.0..
            
-
            15:44 < jrandom> yeah, but restricted routes will be doable without losing backwards compatability
            
-
            15:45 < jrandom> (in fact, it can be done with 0.6.2, if done carefully, to a degree)
            
-
            15:45 < bar> ok, great
            
-
            15:45 < jrandom> I'm also thinking of when to drop tcp... maybe in the next release
            
-
            15:46 < jrandom> or maybe after, so we don't have /too much/ at once
            
-
            15:49 < jrandom> ok, anyone have anything else for the meeting?
            
-
            15:51 < jrandom> if not
            
-
            15:51  * jrandom winds
            
-
            15:51 < stealth> I have some question: I noticed that all eepsites are mapped  to the external internet e.g. http://tracker.postman.i2p.tin0.de/. Is that wanted ?
            
-
            15:51 < jrandom> [saved]
            
-
            15:51 < jrandom> sure, I think thats cool
            
-
            15:51 < jrandom> anyone who publishes information should expect that their information is public 
            
-
            15:52 -!- gloin [gloin@irc2p] has joined #i2p
            
-
            15:52 < jrandom> I think tino has a way for people to topopt out as well
            
-
            15:52 < tethra> that was short
            
-
            15:53 < stealth> They are also indexed by google...
            
-
            15:53 < jrandom> isnt that a good thing stealth?
            
-
            15:53 < Complication> Did it not involve some convention similar to "robots.txt"
            
-
            15:54 < jrandom> aye Complication 
            
-
            15:54 < Complication> (might be best to ask tin0)
            
-
            15:54 <@postman> damn, i am too late
            
-
            15:54 <@postman> (again)
            
-
            15:54 < jrandom> nah, hasn't ended yet postman :)
            
-
            15:54 < Complication> He wrote about it in the forum, at some point
            
-
            15:54 < Complication> Might be findable there
            
-
            15:54 <@postman> ahh cool ( hello then) :)
            
-
            15:55 < jrandom> yeah, its opt-out-able, but I don't understand the concept of opt-out for the i2p content (are people pushing some idea of 'copyright' - "don't copy my stuff or make it visible other places"?)
            
-
            15:55 < jrandom> but, whatever, tino is being nicer than I would be regarding inproxies ;)
            
-
            15:56 -!- Rawn [Rawn@irc2p] has quit [Connection reset by peer]
            
-
            15:56 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]
            
-
            15:57 -!- Karellen [Karellen@irc2p] has quit [Connection reset by peer]
            
-
            15:57 < Complication> Yes indeed, the assumption shouldn't follow that other providers of in-proxies will be equally nice
            
-
            15:58 -!- Karellen [Karellen@irc2p] has joined #i2p
            
-
            15:58 -!- Rawn [Rawn@irc2p] has joined #i2p
            
-
            15:58 -!- mode/#i2p [+v Rawn] by chanserv
            
-
            15:59 < Complication> Information intended to be secret... is best simply not published
            
-
            15:59 < tethra> indeed :/
            
-
            15:59 < stealth> Yes but it might turn too much publicity to i2p before evrything is really totally save. The problem seems to me that I2p has at the moment not enough nodes for a very good anonymity...
            
-
            16:00 -!- Complication [Complicati@irc2p] has quit [Connection reset by peer]
            
-
            16:00 < jrandom> our anonymity isn't dependent upon the size, and i2p has been googled plenty
            
-
            16:01 < jrandom> (or, the base level of anonymity isn't dependent upon the size)
            
-
            16:01 < jrandom> but, of course, no one who needs hard anonymity should use i2p now.
            
-
            16:01 -!- digger3 [digger3@irc2p] has quit [Connection reset by peer]
            
-
            16:01 -!- digger3 [digger3@irc2p] has joined #i2p
            
-
            16:02 < bar> i wouldn't worry, 99% would just ignore the seemingly dead link that turns up on google... the other 1% is likely somewhat geeky and would want to know more
            
-
            16:03 -!- gloin [gloin@irc2p] has joined #i2p
            
-
            16:03 < bar> (well.. dead, that depends on tino's inproxy being up or not, of course)
            
-
            16:05 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:06 < jrandom> if not
            
-
            16:06  * jrandom winds up
            
-
            16:07  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting166.html b/www.i2p2/pages/meeting166.html
deleted file mode 100644
index 7b3db02e..00000000
--- a/www.i2p2/pages/meeting166.html
+++ /dev/null
@@ -1,142 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 166{% endblock %}
-{% block content %}
            I2P dev meeting, January 31, 2006
            
-
            
-
            15:19 < jrandom>  0) hi
            
-
            15:19 < jrandom> 1) Net status
            
-
            15:19 < jrandom> 2) 0.6.1.10 status
            
-
            15:19 < jrandom> 3) ???
            
-
            15:19  * jrandom waves
            
-
            15:19 < jrandom> status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001257.html
            
-
            15:20 < jrandom> ok, jumping on in to 1) Net status
            
-
            15:21 < jrandom> as mentioned in the mail, those on 0.6.1.9-0 (the full release) should have the same-ol'-same-ol'
            
-
            15:21 < jrandom> though users on newer builds (those since 0.6.1.9-5 or newer) may have trouble
            
-
            15:21 < jrandom> ("trouble" is perhaps an understatement...)
            
-
            15:21 <+Complication> CVS -8 was a bit flaky, so running -2 instad (works nice enough)
            
-
            15:22 < gloin> :-)
            
-
            15:22 <+Complication> =instead
            
-
            15:22 < Pseudonym> things seem unstable lately (I'm on 0.6.1.9-0)
            
-
            15:22 < jrandom> cool, I was considering reverting the process changes but including dust's ircclient update and the i2ptunnel httpserver patch on head, but 0.6.1.10 probably isn't that far away
            
-
            15:23 < jrandom> hmm Pseudonym, accessing eepsites, irc, or other services, or hosting them?
            
-
            15:23 <+Complication> Unstable with -0? How does the problem exibit itself?
            
-
            15:23 < Pseudonym> I notice IRC primarily (playing idlerpg)
            
-
            15:24 < jrandom> ("playing" ;)
            
-
            15:24 < Pseudonym> also, somtimes the router goes wonky and has to be restarted (no active peers)
            
-
            15:24 < Pseudonym> heh
            
-
            15:24 < jrandom> hmm, internet connectivity issues?
            
-
            15:24 <@frosk> -0 is stable here, of course except for the twice-daily "router hung!" restarts
            
-
            15:24 < jrandom> hrm frosk, real "router hung", or "router hung" due to leaseSet expiration?
            
-
            15:25 < Pseudonym> internet connectivity is fine.  when I restart the i2p router it comes right back
            
-
            15:25 <+Complication> My Cel300 also hangs after a while, but the periods have been increasing, and I'm not up-to-date on its reason
            
-
            15:25 <@frosk> jrandom: lease expiration, i'm pretty sure
            
-
            15:25 < jrandom> hmm 'k
            
-
            15:26 < jrandom> pretty much all of that has been rewritten for the new creation and management code, so we'll see how it goes in 0.6.1.10
            
-
            15:27 <@frosk> cool
            
-
            15:27 <@frosk> i'll be glad to help test it
            
-
            15:28 < Pseudonym> I don't need you to troubleshoot the problem right now.  I just wanted to add a datapoint about stability
            
-
            15:28 < jrandom> wikked, once its stable locally I'll certainly need to recruit some help :)
            
-
            15:28 < jrandom> cool, thanks Pseudonym 
            
-
            15:28 < jrandom> ok, anyone else have something for 1) Net status?
            
-
            15:30 < jrandom> if not, lets jump on in to 2) 0.6.1.10 status
            
-
            15:30 < jrandom> as mentioned in the mail, rather than pile tweak upon tweak on the live net, we're going to go straight to the source
            
-
            15:31 < jrandom> it won't be backwards compatible, so it will have a... bump, and while we'll roll up a few other backwards incompatible changes with it, there is the possibility for another one afterwards
            
-
            15:32 < jrandom> more specifically, one idea I'm toying with is migrating to 1024bit ElGamal for the tunnel creation code, rather than 2048bit
            
-
            15:32 < jrandom> but that may not be necessary.  it depends on how hard it hits us on the live net
            
-
            15:34 < jrandom> if it does, it would just mean a network upgrade, but all destinations/etc would stay the same.
            
-
            15:34 < jrandom> but, anyway, thats something to explore after 0.6.1.10 comes out
            
-
            15:34 <+Complication> A loosely related question: is the key length in any way related to the tunnel-creation datastructure length?
            
-
            15:34 < jrandom> yes
            
-
            15:35 < jrandom> directly related: key length * 2 * max # hops == data structure size
            
-
            15:36 < jrandom> (so, 256*2*8 = 4KB, which also happens to be the size of full streaming lib messages)
            
-
            15:37 < jrandom> ((ElGamal has a 2x expansion factor))
            
-
            15:38 <+Complication> Aha, thanks. :)
            
-
            15:38 < jrandom> ah, one other thing re: the new spec.  during implementation I found one other data point I need (a 4 byte "reply message ID") which I've added to the spec locally, using some of the reserved bits
            
-
            15:40 < jrandom> I'm hoping to get everything working in the next few days though, so perhaps there'll be some early (non-anonymous) testing by the weekend
            
-
            15:40 < jrandom> but, of course, more info on that as it comes
            
-
            15:41 < jrandom> ok, anyone have any questions/comments/concerns on the 0.6.1.10 stuff?
            
-
            15:41 < bar> another loosely related question: during the rol out of .10, how about keeping i2p.net on .9 for a couple of days for all the auto updating folks?
            
-
            15:41 < bar> rollout*
            
-
            15:41 < jrandom> aye, definnitely
            
-
            15:42 < jrandom> I'll probably have two or three routers on that box during the migration
            
-
            15:42 < jrandom> and there will be loud warnings at least 5 days in advance of the release
            
-
            15:42 < bar> smooth
            
-
            15:42 <+Complication> This way it would be smoother indeed.
            
-
            15:43 <+Complication> Forum seems a good channel. News box on the Router Console too...
            
-
            15:43  * jrandom remembers the days when every release was backwards incompatible... we got a lot of practice then ;)
            
-
            15:43 < jrandom> aye, forum, news box, list, website
            
-
            15:43 <+Complication> So those who attend their machines would know.
            
-
            15:43 < tethra> heheh
            
-
            15:44 < jrandom> and those on 0.6.0.1 still, well, they're fscked anyway ;)
            
-
            15:44 <@frosk> off with their heads
            
-
            15:44 <+Sugadude> Totally un-related: Can we have more backwards incompatible changes more often to force these old routers out?
            
-
            15:44 <+Complication> I think they just forgot I2P running :)
            
-
            15:44 < jrandom> heh Sugadude
            
-
            15:45 < jrandom> well, if they're compatible, we can make use of their resources, but if there's some reason why we can't, we should mark them as incompatible
            
-
            15:47 < jrandom> ok, if there's nothing else on that, lets jump on over to our catch-all: 3) ???
            
-
            15:47 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            15:48 < tethra> it says somewhere on the router console that users behind symmetric NATs aren't currently supported, is that going to change at some point soon? 
            
-
            15:48 < tethra> or am i showing immense ignorance of something
            
-
            15:49 <+Complication> Regarding webcache code... it seems I'm pretty much ready.
            
-
            15:49 < jrandom> there are a few techniques to help users behind symetric nats, which bar has outlined on the list and the forum, though I don't know of any immediate progress on it
            
-
            15:49 < jrandom> oh, nice1 Complication, lemmie know when to push the release :)
            
-
            15:50 <+Complication> Got the watchdog aborting downloads reasonably, doing some testing and clean-up (it currently logs way more than decent)..
            
-
            15:50 <+Complication> I have one webcache server up, awup has another... for some realistic testing, we may want to turn limiting on...
            
-
            15:51 <+Complication> ...if I manage to encounter legion, I'll ask if he might be interested in running one too.
            
-
            15:52 < jrandom> cool, even a single webcache would be a great start
            
-
            15:52 <+Complication> And if anyone else wants to run the script (available from awup.i2p, Python script using SAM)... their references can be added, though currently adding refs to more "seed webcaches" does require a recompile of sources.
            
-
            15:53 <+Complication> (not in a file but the header of GWebCacheContainer.java)
            
-
            15:53  * gloin don't know what this webcache stuff is.
            
-
            15:53 < jrandom> gloin: it lets you connect to i2phex without having to download an i2phex.hosts file the first time
            
-
            15:54 <+Complication> gloin: for easier integration of I2PHex
            
-
            15:55  * cervantes arrives late
            
-
            15:55 <+Complication> And for later reconnecters (e.g. people who've run out of live peer refs) it can offer fresh refs
            
-
            15:55 < gloin> ok.
            
-
            15:57 <+Complication> Oh, offline again
            
-
            15:58 < stealth> what about an automatic startup of i2phex after i2p has started ?
            
-
            15:58 <+Complication> Seems like overkill
            
-
            15:58 <+Complication> At current phase, at least
            
-
            15:58 < jrandom> stealth: you can have the i2p router launch any java application you want by adding entries into your client.config file
            
-
            15:59 <+Complication> Besides, I think I2Phex can be started before I2P runs
            
-
            15:59 <@frosk> at any phase
            
-
            15:59 <+Complication> Theoretically, it should keep trying to connect until I2P gets up
            
-
            15:59 <+Complication> (haven't tested, though)
            
-
            15:59 < jrandom> though remember, if you tell it to launch i2phex, when i2phex closes, chances are the i2phex client will kill the JVM (restarting your router)
            
-
            16:00 <+Complication> Besides, one could script it fairly easily too...
            
-
            16:00 <+Complication> e.g. "cd /home/i2p; sh i2prouter start; cd /home/i2phex; sleep 100; sh run.sh;"
            
-
            16:00 <+Complication> (or however it was)
            
-
            16:01 <+Complication> Sorry, /home/user/i2p more likely :)
            
-
            16:01 < cervantes> don't forget to start /usr/games/tetris before the sleep 100
            
-
            16:02 < jrandom> damn straight
            
-
            16:02 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:03 < stealth> well I thought  about it just start the exe. the i2psnark solution with always on is better because people forget to share their files if they are not downloading...
            
-
            16:04 < jrandom> aye, though I've yet to hear of a gnutella client that is thin enough (that could be integrated)
            
-
            16:05 < cervantes> isn't the work being done on the current Phex to abstract the UI? perhaps the client eventually become skinny
            
-
            16:05 <+Complication> I haven't read that part of Phex CVS
            
-
            16:06 < jrandom> if phex could be run as a .war, that would indeed rule
            
-
            16:06 < cervantes> isn't the=isn't there
            
-
            16:06 < cervantes> I'm probably mistaken
            
-
            16:06 <+Complication> Sirup certainly was working on an XML-RPC interface, but I'm not sure if Gregor & co are too
            
-
            16:07 <+Complication> So I'm not sure if sirup ported it in, or started writing it from scratch
            
-
            16:09 < jrandom> iirc he was just importing apache's xmlrpc lib and exposing some of i2phex's internals, but there hasn't been any work on that in probably 6-8 months, and it was never functional afaik
            
-
            16:10 < fox_> <tethra> mutella is a web based gnutella client that is fairly lightweight, iirc. not sure if it will be any help, but heh, might be worth someone (more talented) checking it out.
            
-
            16:10 < fox_> <tethra> might not be what is being looked for, though.
            
-
            16:12 < jrandom> porting a new one is a chunk of work, especially a C/C++ one, unfortunately
            
-
            16:12 <+Complication> I'm personally unlikely to tinker with XML-RPC. Attempting to catch various bugs... is in my near-term plans, though.
            
-
            16:13  * Complication wants the rehash effect gone for good, since it's such a waste of time
            
-
            16:13 < jrandom> ooh, perhaps thats triggered by timezone shift?
            
-
            16:14 < jrandom> when the I2P SDK connects to the router, it gets the current I2P (NTP) time from it, and forces the SDK's JVM into UTC
            
-
            16:14 <+Complication> Sounds unlikely... but at this stage, I can't exclude much
            
-
            16:15 < jrandom> (and if the rehash depended upon ordering and file timestamps, perhaps the shift of a few hours would change that)
            
-
            16:15 < jrandom> yeah, you've dug into a lot of it, just mentioning a possibility
            
-
            16:15  * jrandom doesn't know anything about it beyond your bug reports :)
            
-
            16:16 <+Complication> It occurs occasionally, and *seems* related to something happening when the "sharedlibrary" config file is being loaded/rewritten
            
-
            16:16 <+Complication> Hmm, interesting possibility...
            
-
            16:16 <+Complication> I've not dug enough to exclude that
            
-
            16:18 < jrandom> ok, anyone else have something for the meeting?
            
-
            16:19 < jrandom> if not...
            
-
            16:19  * jrandom winds up
            
-
            16:19  * bar wishes jrandom good luck with .10 and hands him a shiny baf
            
-
            16:19 < jrandom> gracias :)
            
-
            16:19  * jrandom *baf*s the meeting closed 
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting167.html b/www.i2p2/pages/meeting167.html
deleted file mode 100644
index ee455052..00000000
--- a/www.i2p2/pages/meeting167.html
+++ /dev/null
@@ -1,151 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 167{% endblock %}
-{% block content %}
            I2P dev meeting, February 7, 2005
            
-
            
-
            15:36 < jrandom> 0) hi
            
-
            15:36 < jrandom> 1) Net status
            
-
            15:36 < jrandom> 2) _PRE net progress
            
-
            15:36 < jrandom> 3) I2Phex 0.1.1.37
            
-
            15:36 < jrandom> 4) ???
            
-
            15:36 < jrandom> 0) hi
            
-
            15:37  * jrandom waves
            
-
            15:37 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html
            
-
            15:37 < bar> hello
            
-
            15:38 < jrandom> while y'all dig through that oh-so-exciting material, lets jump on in to 1) Net status
            
-
            15:38 < jrandom> there hasn't been much changed on the live net in the last week, from an i2p perspective, so I don't really have much to add here
            
-
            15:39 < jrandom> anyone have anything they want to bring up regarding the current net status?
            
-
            15:39 < KBlup> I have seen terrible spikes of failing clients when running i2p for long... dunno if thats fits to 1)
            
-
            15:39 < jrandom> KBlup: does that correlate to high cpu load or bandwidth consumption?
            
-
            15:40 < KBlup> resuluts in msg-delay > 10000ms :-/
            
-
            15:40 < jrandom> ah, very likely one of the causes of the _PRE net being developed :)
            
-
            15:40 < KBlup> I think it then tries to establish new tunnels and fails constantly, which results in 300+ jobs some times...
            
-
            15:41 < KBlup> my maschine is quite strong but overloaded with that...
            
-
            15:41 < jrandom> aye, thats all been reworked along the way for 0.6.1.10, hang tight until thats ready
            
-
            15:43 < jrandom> ok, anything else on 1), or shall we mosey on over to 2) _PRE net progress
            
-
            15:43 <+Complication> 0.6.1.10 seems to contain substantial changed indeed
            
-
            15:45 < jrandom> yeah, there's a lot of meat under here.  The current state is that the new creation code is in place and seems to be working properly, but now I'm using this opportunity to debug some of the underlying issues further
            
-
            15:46 <+Complication> You mentioned having to cough up a lot of CPU time in advance
            
-
            15:47 <+Complication> Would this cost now be associated with building any sort of a tunnel?
            
-
            15:48 <+Complication> (meaning, before the construction, during a short while, you'd have to perform a batch of heavy crypto)
            
-
            15:48 < jrandom> yes, all tunnel build requests will need to do k heavy crypto operations (where k = number of hops in the tunnel being built)
            
-
            15:49 <+Complication> Whad I wanted to ask... is the interval just tighter than before, or the amount bigger too?
            
-
            15:50 < jrandom> the amount is both bigger, smaller, and tighter.  tighter, in that they're all done upfront.  bigger, in that we can't short circuit and not do the encryption for a hop if an earlier hop rejects it, and smaller in that earlier hops fail a lot less
            
-
            15:51 < jrandom> in addition, however, unlike earlier releases, we're no longer using ElGamal/AES+SessionTag for the tunnel requests - we use (fairly) straight ElGamal
            
-
            15:52 <+Complication> ...and it couldn't be pre-calculated, unless one knew the final set that's going to succeed?
            
-
            15:52 < jrandom> that means that while we used to be able to cheat without an asymmetric operation, we don't try to cheat anymore (as the cheating itself exposed a class of attacks)
            
-
            15:53 <+Complication> (set of peers)
            
-
            15:53 < jrandom> hmm, it could certainly be precalculated, assuming you know who the peers in the tunnel that are going to be asked
            
-
            15:54 < jrandom> the new tunnel creation process is done on a separate thread, so it doesn't bog down the main job queue under load, and so that it can throttle itself better
            
-
            15:54 <+Complication> Could one also assume that, barring change in available knowledge, one knows a few whom one is going to ask from, if attempts fail?
            
-
            15:54 < jrandom> hmm, not entirely sure I follow
            
-
            15:55 <+Complication> Or is knowing them already useless, since the struct must be redone from scratch?
            
-
            15:56 <+Complication> (meaning: the ElGamals redone from scratch, at least)
            
-
            15:56 < jrandom> ah, the structure is http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord
            
-
            15:56 < jrandom> so, yes, if the next hop changes, the ElGamal must be redone
            
-
            15:56 < jrandom> (if you precompute)
            
-
            15:56 <+Complication> Right, I wasn't sure enough about that instantly
            
-
            15:57 <+Complication> Now I realize it, though
            
-
            15:57 < jrandom> otoh, we're really trying to get our build success rate up, and the new build process should be able to adapt to minimize unnecessary creations
            
-
            15:58 <+Complication> How does it seem doing in reality?
            
-
            15:58 < jrandom> (oh, that structure has been slightly modified on the _PRE branch: http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord )
            
-
            15:59 <+Complication> I noticed the detail about ElGamal encrypts taking a leap towards quickness...
            
-
            15:59 < jrandom> well, the build success rate is much much higher than it is on the live net, but that may just be due to the small _PRE net size
            
-
            16:00 < jrandom> yeah, creating a 2 hop structure, for instance, takes an average of 44ms over 1120 runs, as compared to the live net's ElGamal encryption time of 542ms (over 1344 runs)
            
-
            16:02 < jrandom> (on the same box)
            
-
            16:02 <+Complication> Would this 542 include retries on failure too, or just the pure building?
            
-
            16:02 <+Complication> If it's pure building, I need to find my lower jaw... it's on the floor somewhere. :P
            
-
            16:02 < KBlup> about that change of the exponent : at what scale does that affect anonymity?
            
-
            16:02 < jrandom> no, thats the pure elGamal stat, since the live net doesn't build the new _PRE net structure
            
-
            16:04 < jrandom> KBlup: anonymity?  none.  security?  according to what I've read, 228 bits is more than enough to match 2048bit ElGamal
            
-
            16:04  * Complication doesn't know much about ElGamal's x and y
            
-
            16:04 <+Complication> Not enough to comment meaninfully
            
-
            16:06 <+Complication> If serious researchers consider the shorter x hard enough, and those crypto wonks didn't run away screaming...
            
-
            16:06 <@cervantes> well not only that, but the implications of dropping to 1024/160
            
-
            16:07 < KBlup> i guess i have to read the paper later ;)
            
-
            16:07 <+Complication> cervantes: yes, it's better than that, for sure
            
-
            16:08 <+Complication> Besides, what is the foremost attack this cipher must repel, and how long is the attack viable?
            
-
            16:09 <+Complication> Could it be something which benefits you only if you break it quick, or also benefits if you break it eventually?
            
-
            16:11 <+Complication> If I understand right, the immediate secret it guards is the next tunnel participant, right?
            
-
            16:11 <+Complication> (or more precisely, the next-to-next one)
            
-
            16:11 <@modulus> meeting ongoing?
            
-
            16:11 <+Complication> (which only the next one may know)
            
-
            16:11 <@cervantes> modulus: ayre
            
-
            16:11 <@cervantes> -r
            
-
            16:11 < jrandom> for a practical (yet insanely powerful) adversary, breaking it during the tunnel lifetime would be necessary.  breaking it after that tunnel lifetime would only help if you logged all network traffic and broke all tunnels (that is, after breaking the ephemeral transport layer crypto and working on the tunnel layer crypto)
            
-
            16:11 < jrandom> so, we're talking on the order of minutes here, not decades
            
-
            16:12 < jrandom> (so 1024bit is probably even overkill)
            
-
            16:12 <@cervantes> is there a way to measure the risk in a meaningful way?
            
-
            16:13 <+Complication> Besides, for a tunnel with more hops, the adversary would have to break several, right?
            
-
            16:13 <+Complication> (though the builder would have to build several too)
            
-
            16:13 <@cervantes> if we need no more than 1024 bits, then is it really necessary to use more? 
            
-
            16:14 <@cervantes> we can always use a stronger algo in 3 years time when we've got vastly more powerful quantum computers
            
-
            16:14 <@modulus> jrandom: if the adversary would know that at time hh:mm something important is going to be tunneled is it likely they could break it somehow by logging?
            
-
            16:14 < jrandom> Complication: right, they'd have to break several (and the DH keys protecting the transport layer)
            
-
            16:14 <@modulus> afaik 1024bit is break()able with a lot of power
            
-
            16:15 < jrandom> a lot of power and a decade
            
-
            16:15 < jrandom> (or three)
            
-
            16:15 <@cervantes> jrandom: is it difficult to try the weaker cipher?
            
-
            16:15 <@modulus> i was under the impression that 1024bit composits were factorizable these days in a few months.
            
-
            16:15 <@cervantes> could we roll out to the pre net 
            
-
            16:15 <@cervantes> and see whether it actually offers much benefit
            
-
            16:16 <@cervantes> modulus: yes but they'd need to break several
            
-
            16:16 <@modulus> if this is based on discrete log domain and all that stuff then i don't know anything
            
-
            16:16 <@modulus> cervantes: aha
            
-
            16:16 < jrandom> cervantes: it requires changes to a lot of structures, since we currently use 512byte slots.  though, perhaps we could just fill the first 256 bytes with 0x00 for testing
            
-
            16:17 < jrandom> modulus: ElGamal is based on discrete log
            
-
            16:17 <@cervantes> jrandom: worthy of testing?
            
-
            16:17 <@modulus> right right, i was imagining RSA
            
-
            16:17 <@cervantes> or better to focus on other things and return to it if necessary
            
-
            16:18 < jrandom> definitely worth testing, though for the moment I'm hacking away at some transport layer evaluations
            
-
            16:18 <+Complication> I guess it depends on how their calculation can be handled in real life.
            
-
            16:18 < jrandom> (and the 44ms encryption time is good enough for the moment, though a 4ms encryption time would be even better :)
            
-
            16:19 <+Complication> If it holds together with current computers, it will improve with newer machines.
            
-
            16:19 <@modulus> especially if there comes crypto hw, as it is starting to come in some
            
-
            16:19 < jrandom> but, of course, changing this parameter will not be done lightly or immediately.  but if someone has a good reason to avoid it, please get in touch
            
-
            16:21 < jrandom> modulus: I've heard of dedicated AES and RSA chips, but nothing on DH/ElGamal.  otoh, when one looks to the NSA/etc as an adversary, where they can build their own, its possible
            
-
            16:22 <@cervantes> they have crypto machines built on ring sprinkled donut technology
            
-
            16:23  * Complication is willing to upgrade the Celeron 300 to Athlon 600, if it holds the tide of ring-sprinkled donuts :D
            
-
            16:23 < tethra> heheh
            
-
            16:24 < jrandom> mmMMmm donuts
            
-
            16:25 < jrandom> ok, anyone have anything else on 2) _PRE net progress?
            
-
            16:25 < jrandom> if not, lets jump on over to 3) I2Phex 0.1.1.37
            
-
            16:26 < jrandom> Complication: wanna give us the skinny?
            
-
            16:26 <+Complication> Well, it seems to work. :)
            
-
            16:26 <+Complication> There is hope of getting more webcaches for extra redundancy soon.
            
-
            16:27 < jrandom> word
            
-
            16:27 < jrandom> hmm, do you think we need more webcaches?  don't we just need one to be up?  not that more hurts, of course
            
-
            16:27 <+Complication> (if legion manages to solve the mysteries which haunted his initial try)
            
-
            16:27 <+Complication> There's also a mystery bug in there, but it doesn't byte hard, and I'm trying to find it.
            
-
            16:28 <+Complication> One up is enough
            
-
            16:28 <+Complication> More just increases the chances that one is up
            
-
            16:28 < jrandom> cool
            
-
            16:28 <+Complication> Because at current stage, it will never drop webcaches as bad. Too few of them altogether.
            
-
            16:29 <+Complication> (that routine will activate if there exist more than 10)
            
-
            16:29 <+Complication> (if I remember correctly)
            
-
            16:29 <+Complication> As for the bug: after a long time operating, the webcache subsystem sometimes stalls
            
-
            16:30 <+Complication> Likely because a httpclient's GET request can't be aborted successfully
            
-
            16:31 <@modulus> so it needs to die from time to time?
            
-
            16:31 <+Complication> It's safe, and never seems to bite freshly joined machines
            
-
            16:31 < jrandom> hmm, what does that mean, functionally?  after a while, it will stop registering with the webcache, so new people won't be given references to them?
            
-
            16:31 <+Complication> If it bites a machine already well integrated, that machine can get enough peers from the peers it's already connected to
            
-
            16:31 <+Complication> So currently the impact seems close to 0
            
-
            16:31 <@modulus> cool
            
-
            16:32 <+Complication> It's curious, just
            
-
            16:32 <@modulus> no rule about when it will fail or anything?
            
-
            16:32 <+Complication> modulus: generally not before 20 hours
            
-
            16:33 <+Complication> And since I have no way of forcing it to occur, debugging is a bit slow
            
-
            16:33 <@modulus> :_)
            
-
            16:34 <+Complication> Either way, should I find it, I'll fix it, and should I not find it, I'll find other stuff to tinker with :)
            
-
            16:34 < jrandom> :)
            
-
            16:34 < jrandom> sounds like its just a symptom of some bugs we've seen in the streaming lib / eepproxy, so fixing those should fix this
            
-
            16:35 <+Complication> Could be
            
-
            16:38 < jrandom> ok great, nice work Complication
            
-
            16:38 < jrandom> anyone have anything else on 3) I2Phex 0.1.1.37, or shall we jump on over to the catch-all, 4) ???
            
-
            16:41 < jrandom> (consider us jumped)
            
-
            16:41 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:42 < tmp> Or forever hold your breath?
            
-
            16:43 < jrandom> and ever and ever
            
-
            16:43  * jrandom winds up
            
-
            16:43  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting168.html b/www.i2p2/pages/meeting168.html
deleted file mode 100644
index e6ebbcb0..00000000
--- a/www.i2p2/pages/meeting168.html
+++ /dev/null
@@ -1,74 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 168{% endblock %}
-{% block content %}
            I2P dev meeting, February 14, 2006
            
-
            
-
            15:39 < jrandom> 0) hi
            
-
            15:39 < jrandom> 1) Net status
            
-
            15:39 < jrandom> 2) 0.6.1.10
            
-
            15:39 < jrandom> 3) Syndie activity
            
-
            15:39 < jrandom> 4) ???
            
-
            15:39 < jrandom> 0) hi
            
-
            15:39  * jrandom waves
            
-
            15:39 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001260.html
            
-
            15:39 < jrandom> (I'm a lil late with that, so I'll give y'all a minute to skim through those brief notes)
            
-
            15:40 <+Complication> hello
            
-
            15:40 <@cervantes> 'lo
            
-
            15:41 < jrandom> well, its brief enough, so lets just jump on in to 1) Net status
            
-
            15:41 < jrandom> I don't have anything to add to this one, anyone have something on it to discuss?
            
-
            15:41 <@cervantes> <jrandom> (damn flakey net connection)
            
-
            15:41 <+Complication> A bit congested occasionally, but graphs suggest it's nothing new
            
-
            15:42 < jrandom> heh cervantes, well, thats due to one of my roommates using limewire, not i2p ;)
            
-
            15:43 <@cervantes> we've had various server problems too with irc and postman's tracker over the past couple of weeks - postman has done a lot of migrations, so things should be more stable for folk
            
-
            15:43 <+Complication> It must be hard letting them do that, but I guess... such is life :O
            
-
            15:43 <+Complication> do that=use limewire
            
-
            15:44 <+Complication> This morning, tracker.postman.i2p was refusing connections, though
            
-
            15:44 < jrandom> Complication: disk was full, fixed now
            
-
            15:44 < jrandom> (new machines have their new quirks)
            
-
            15:46 < jrandom> ok, anyone have anything else on 1) Net status?
            
-
            15:46 < jrandom> otherwise, lets shimmy on over to 2) 0.6.1.10
            
-
            15:47 < jrandom> As mentioned, we're going to have a new backwards incompatible release in a few days
            
-
            15:48 < jrandom> while it alone won't revolutionize our performance, it will improve a few key metrics to get us on our way
            
-
            15:48 < jrandom> there are also a whole bunch of bug fixes in there too
            
-
            15:49 <@cervantes> will zzz's server tunnel improvements make the fold?
            
-
            15:49 < jrandom> oh, and there's that whole improved anonymity thing... ya know, sine qua non
            
-
            15:50 < jrandom> cervantes: probably not, haven't heard much since that post to zzz.i2p last week.  i did do some minor bugfixes in cvs though (to should support lighttpd, etc), but we won't have zzz's persistent connections
            
-
            15:50 < jrandom> (yet)
            
-
            15:51 <@frosk> what DH key size/etc did you land on?
            
-
            15:51 <@cervantes> yeah, I saw those newline issues a few weeks ago, but I held off changing them because of zzz's impending improvements
            
-
            15:51 < jrandom> ah, for the moment we'll be sticking with 2048bit crypto with small exponents
            
-
            15:52 <@frosk> so some lower cpu consumption can be expected?
            
-
            15:52 < jrandom> aye
            
-
            15:53 <@frosk> excellente
            
-
            15:53 < jrandom> switching to 1024bit would cut another order of magnitude to the CPU load, but would require some reworking of the tunnel creation structures (1024bit asym isn't large enough to convey the data we need to convey).  
            
-
            15:54 < jrandom> we may explore that in the future though, but this next release should substantially cut down cpu overhead
            
-
            15:54 < jrandom> I've also disabled the TCP transport, because I'm a mean and vicious person
            
-
            15:55 <@frosk> do you expect any more incompatible upgrades before 1.0?
            
-
            15:55 < jrandom> hope not
            
-
            15:55  * cervantes must be a danish cartoonist
            
-
            15:55 <@frosk> i don't think we'll miss tcp :)
            
-
            15:55 <@cervantes> I mean jrandom must be
            
-
            15:55 <@cervantes> ;-)
            
-
            15:55  * jrandom watches the embassy burn
            
-
            15:56 < jrandom> ok, anyone have anything else on 2) 0.6.1.10?
            
-
            15:56 < void> why wouldn't it support lighttpd earlier?
            
-
            15:56 < jrandom> (ah, as an aside, there have also been some interesting improvements to the streaming lib for 0.6.1.10, such as tcp-style fast retransmit, etc, so we'll see how that helps)
            
-
            15:57 <@cervantes> void: malformed headers
            
-
            15:57 < jrandom> void: bug where we weren't standards compliant
            
-
            15:57 < void> ah, are these inconsistent newline bugs also fixed?
            
-
            15:58 < void> and what about the null character one? are you waiting for zzz's persistent connection patch?
            
-
            15:58 < jrandom> the newline bug is the malformed header, and is fixed
            
-
            15:58 < jrandom> no news on the null character one
            
-
            15:59 < void> ok
            
-
            16:00 < jrandom> ok, if there's nothing else on 2, lets swing on by 3) Syndie activity briefly
            
-
            16:00 < jrandom> well, I don't really have much to add...
            
-
            16:01 < jrandom> (I /did/ say briefly)
            
-
            16:01 < jrandom> so lets jump on to 4) ???
            
-
            16:01 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            16:01 <+fox> <duck> too busy reading Syndie to comment
            
-
            16:01 < jrandom> ;)
            
-
            16:02  * Complication is too busy issuing meaningless signatures to comment :D
            
-
            16:05 < jrandom> ok cool.  just another reminder for people to stay away from CVS for the next day or two until the release, as CVS HEAD is going to get the _PRE branch's changes, and the _PRE branch is going to be retired
            
-
            16:05  * jrandom winds up
            
-
            16:05  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting170.html b/www.i2p2/pages/meeting170.html
deleted file mode 100644
index 51d02b75..00000000
--- a/www.i2p2/pages/meeting170.html
+++ /dev/null
@@ -1,122 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 170{% endblock %}
-{% block content %}
            I2P dev meeting, February 28, 2006
            
-
            
-
            15:11 < jrandom> 0) hi
            
-
            15:11 < jrandom> 1) Net status and 0.6.1.12
            
-
            15:11 < jrandom> 2) Road to 0.6.2
            
-
            15:12 < jrandom> 3) Miniprojects
            
-
            15:12 < jrandom> 4) ???
            
-
            15:12 < jrandom> 0) hi
            
-
            15:12  * Complication quickly reads notes
            
-
            15:12  * jrandom waves
            
-
            15:12 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001266.html
            
-
            15:12 < jrandom> (and here I was posting the notes more than 15 minutes before the meeting!  ;)
            
-
            15:13 < jrandom> ok while y'all read those oh-so-exciting bits, lets jump on in to 1) Net status and 0.6.1.12
            
-
            15:14 < jrandom> as mentioned, the primary goals of the 0.6.1.10-0.6.1.12 releases seem to have been met, addressing the tunnel creation crypto change and improving creation reliability substantially
            
-
            15:16 < jrandom> the bumps we saw at 0.6.1.10 are gone, and irc stability seems quite good again
            
-
            15:16 < jrandom> anyone have anything else to bring up for 1) Net status and 0.6.1.12, or shall we mosey on over to 2) Road to 0.6.2?
            
-
            15:17 <+Complication> Net status over here: no more going back under 20 KB/s :)
            
-
            15:18 < jrandom> cool, yeah 0.6.1.12 fixed a pretty large bug in 0.6.1.11 where it wouldn't exploit the bandwidth available.  it should now make better use of available resources
            
-
            15:20 < jrandom> ok, lets jump on to 2)
            
-
            15:20 < jrandom> as mentioned, there are a few things that need to get sorted before the last functional change is put in place for 0.6.2, but we're making progress on that front
            
-
            15:20 < nymisis> net status is fine :)
            
-
            15:22 < jrandom> word.  there'll be more info available on the specifics of the new peer ordering strategies before they come out, but the gist of them should be clear from their brief mention in the notes
            
-
            15:23 < jrandom> anyone have any questions/comments/concerns regarding 2) road to 0.6.2?
            
-
            15:23 < postman> jrandom: any testnets this time?
            
-
            15:24 < postman> (need any routers, particpants to test stuff)
            
-
            15:24 < postman> ?
            
-
            15:24 <+Complication> The essence of the matter seemed quite straightforward - to limit opportunity for an adversary to harvest diverse statistical data
            
-
            15:25 <+Complication> Sounds like a fairly desirable feature
            
-
            15:25 < jrandom> postman: the new stuff should work transparently on the live net using local-only info, so shouldn't need a separate net to test
            
-
            15:25 < jrandom> aye, exactly Complication 
            
-
            15:26 < postman> ok
            
-
            15:26 < postman> jrandom: are you bold enough to disclose an ETA for 0.6.2 ? :)
            
-
            15:27 < blubb> 1 april
            
-
            15:27 < jrandom> well, seeing as today is the end of feb, i'd guess march or april
            
-
            15:27 < postman> hehe
            
-
            15:27 < jrandom> blubb: we've already got an mi6 backdoor scheduled for then ;)
            
-
            15:29 <@cervantes> more like an mi6 catflap
            
-
            15:29 <@cervantes> (budget cuts)
            
-
            15:29 < postman> in an elephant house
            
-
            15:30 < nymisis> That's SIS, not MI6, if you're going to be accurate. :)
            
-
            15:30 < jrandom> well, lets just call them Them ;)
            
-
            15:31 < jrandom> ok, anything else for 2)?
            
-
            15:31 < jrandom> if not, lets shimmy on over to 3) miniprojects
            
-
            15:31 <@cervantes> sorry "the firm"
            
-
            15:34 < jrandom> ok, I just wanted to point out a few neat things that would be 1) simple to do and 2) really useful
            
-
            15:34 <+Complication> On the miniprojects side, I'm not sure if my Syndie reply made it or not, but I'm wondering if I could snatch one.
            
-
            15:34 <+Complication> Not sure which one yet. Currently practising a little more Java (doing a micro-project :D) just to have added certainty that when I try, I'll be able to handle one
            
-
            15:35 < DeltaQ> hmm if i upp the bw on the console is the chanes immediate or reboot needed?
            
-
            15:35 <+Complication> When I get ready with the "micro-project" (assuming of course the table hasn't been cleared yet), I'll try picking one
            
-
            15:35 < jrandom> w3wt, great Complication 
            
-
            15:36 < jrandom> DeltaQ: immediately 
            
-
            15:36 <@cervantes> isn't 1) syndie scheduler a tie in with 4) Download Manager / eepget scheduler
            
-
            15:36 <+Complication> DeltaQ: takes effect almost instantly (within the periods that bandwidth gets averaged over)
            
-
            15:37 <@cervantes> seems to me that a more generally functional up and download manager would service both needs
            
-
            15:37 < jrandom> cervantes: hmm, not necessarily.  1) is pretty focused, and also includes pushes, while 4) is prety generic
            
-
            15:37 <+Complication> cervantes: sounds like it could
            
-
            15:37 < jrandom> but yeah, the engine behind both is EepGet
            
-
            15:37 < jrandom> (eepget does syndie's http transfers, programatically)
            
-
            15:38 < DeltaQ> avg doesnt seem yto go above 13kb/s
            
-
            15:38 < DeltaQ> i set 64kb/s with 192 burst down
            
-
            15:38 < DeltaQ> 32/64 up
            
-
            15:38 <@cervantes> so a generic pushing and pulling eepget with a scheduling and management api...
            
-
            15:39 <@cervantes> still, in probably ceases to become a mini-project at that point
            
-
            15:39 <+Complication> DeltaQ: the average also depends on how much load your client tunnels (and other peers' participating tunnels) generate
            
-
            15:39 <+Complication> sorry, s/average/actual bandwidth
            
-
            15:39 < jrandom> cervantes: yeah, there's substantial logic involved in the syndie stuff though.
            
-
            15:40 < DeltaQ> heh it finally went up
            
-
            15:40 < DeltaQ> 1s: 30.82/29.33KBps
            
-
            15:40 < DeltaQ> guess i needed up upp the ul bw
            
-
            15:40 < jrandom> DeltaQ: the average will also be affected by how other people view you, which depends upon your actions, not any advertized rate, so it'll take a bit
            
-
            15:40 <+Complication> DeltaQ: for pass-though traffic (participating tunnels), what comes in must also get out
            
-
            15:41 <+Complication> DeltaQ: so very different ul/dl rates would choke participating traffic to the lower of the two
            
-
            15:42 <+Complication> DeltaQ: also, participating traffic depends on how other nodes "perceive" your node's routing capacity
            
-
            15:42 < DeltaQ> oki
            
-
            15:43 <+Complication> If they think it can route well, they'll ask more often
            
-
            15:43 < jrandom> ok, if there's nothing else on 3) miniprojects, lets jump on over to 4) ???
            
-
            15:43 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            15:43 < DeltaQ> well i am behind a router but i did map port 8887 to this pc
            
-
            15:43 <+Complication> If it's new, or has only recently increased in capacity, they're a bit shy
            
-
            15:44 < DeltaQ> oh sorry i didnt mean to intervere a meeting ^^
            
-
            15:44 <+Complication> Someone asked the other day, about possible attacks based on clock skew. I think I saw your answer about the tunneling part (creation message holds only tunnel validity period, not time from its creator's perspective)...
            
-
            15:44 <@cervantes> (thanks for the mention in the status notes) ;-)_
            
-
            15:46 <+Complication> So I thought, actually, about asking... which points if any at all, in I2P messaging, could contain time from a sender's perspective?
            
-
            15:47 <+Complication> I've not managed to dig myself up-to-date on this, so I'm a bit clueless about it
            
-
            15:47 < jrandom> Complication: nothing explicitly says "I think it is now $time", but with sufficient traffic and timing analysis, one could likely narrow it down substantially
            
-
            15:48 < jrandom> we do quantize the times at a large period, though not as large as our max clock skew, so there is room there
            
-
            15:49 <+Complication> Do you think there would ultimately be any benefit to receive from a more "streamlined" NTP client?
            
-
            15:49 <+Complication> One which would / could easier keep skews smaller?
            
-
            15:50 < jrandom> well, since the sntp client was introduced into i2p, its been getting better and better so that now we don't see the variation we used to
            
-
            15:51 < jrandom> perhaps we could reduce the minimum-skew limit from 10s to perhaps 2 or 3s, or maybe less
            
-
            15:51 < jrandom> alternately, we could allow it to look at the ssu clock skews as well to avoid unecessary skews
            
-
            15:52 <+Complication> Or alternatively, could it be possible to limit further any opportunity to guess at another peer's possible clock value?
            
-
            15:53  * Complication doesn't know which way would be more practical, just suggesting random possibilities :D
            
-
            15:53 < jrandom> no, we know the clock skew of directly connected peers
            
-
            15:55 < Magii> is there anyway to tell if the update was done successfully?
            
-
            15:55 <+Complication> Aha, so session protocol really depends on that info..
            
-
            15:55 < tethra> look at your version number
            
-
            15:55 <+Complication> Magii: it should file a CRIT like "update verified, restarting to install" in logs
            
-
            15:55 < tethra> :/
            
-
            15:55 <+Complication> Then, it should count down minutes to a graceful restart
            
-
            15:56 <+Complication> And finally restart
            
-
            15:57 <+Complication> Oh, sidenote: does the internal NTP client know of a concept like "clock drift rate"?
            
-
            15:58 < jrandom> yeah, the version number on the top left corner of http://localhost:7657/index.jsp should be a giveaway :)
            
-
            15:58 < jrandom> Complication: no, it doesn't guarantee sequential clock ticks
            
-
            15:59 < jrandom> s/sequential/ordered/
            
-
            15:59 <+Complication> Nor develop knowledge like "our system clock is 0.00345 times faster than needed"?
            
-
            16:00 < jrandom> ah, no, though adding that to net.i2p.util.Clock wouldn't be that hard (wanna miniproject?  :)
            
-
            16:00 <+Complication> I was thinking of something along those lines
            
-
            16:01 <+Complication> I guess I'm now thinking a bit more about it :)
            
-
            16:01 <+Complication> Other miniprojects first, though :)
            
-
            16:02 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:03 < nymisis> Muffins?
            
-
            16:04 < jrandom> no, pancakes
            
-
            16:04 < jrandom> (mmMMmm pancakes)
            
-
            16:04 < jrandom> speaking of which
            
-
            16:04  * jrandom winds up
            
-
            16:04 < nymisis> Oh, darn, good point.
            
-
            16:04  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting171.html b/www.i2p2/pages/meeting171.html
deleted file mode 100644
index f855275d..00000000
--- a/www.i2p2/pages/meeting171.html
+++ /dev/null
@@ -1,78 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 171{% endblock %}
-{% block content %}
            I2P dev meeting, March 7, 2006
            
-
            
-
            15:08 < jrandom> 0) hi
            
-
            15:08 < jrandom> 1) Net status
            
-
            15:08 < jrandom> 2) ???
            
-
            15:08 < jrandom> 0) hi
            
-
            15:08  * jrandom waves
            
-
            15:08 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001267.html
            
-
            15:09  * jrandom gives y'all hours to read through that huge tome of notes
            
-
            15:10  * Complication pretends not having noticed yet ;)
            
-
            15:11 <+Complication> Hi :)
            
-
            15:11 <+susi23> hi :)
            
-
            15:12 < jrandom> well, might as well dig on in to 1) net status
            
-
            15:12 < jrandom> The mail gives my general view of whats going on.  how does that line up with what y'all are seeing?
            
-
            15:13 <+Complication> Throttling fixes seem to have increased reliability, but really suppressed bandwidth
            
-
            15:13 <+Complication> Just a second, digging for the graph
            
-
            15:14 <+Complication> http://complication.i2p/files/bw-week.png
            
-
            15:14 <+Complication> High stretches are on non-latest, low stretches on latest
            
-
            15:15 <+Complication> Same limiter settings, possibly more lax on stricter (latest) versions
            
-
            15:16 <+Complication> But it's not much of a problem, since it does transfer
            
-
            15:16 < jrandom> cool, reduced bandwidth usage is appropriate as you approach your actual bandwidth limit
            
-
            15:17 <+Complication> Most of time, it seems to bounce back before the "sustained bandwidth" limit
            
-
            15:17 <+Complication> Never touches the burst limit
            
-
            15:18 <+Complication> (which, in itself, is sensible - it's the bouncing back before the sustained limit which concerns me)
            
-
            15:19 < bar> i'm seeing pretty much what Complication is seeing. my total bw consumption is just 50% of my max settings. it used to be ~80% pre 0.6.1.11
            
-
            15:19 < jrandom> is 200kbps your limiter rate, w/ 300kbps burst?
            
-
            15:20 < jrandom> (just wondering how much time it used to spend in the burst)
            
-
            15:20 < jrandom> reduced bandwidth usage though is one of the aims of the recent changes
            
-
            15:21 <+Complication> ~225 sustained, ~325 burst
            
-
            15:21 <+Complication> Hey, I could have...
            
-
            15:22 <+Complication> Have I *interpreted* it wrong?
            
-
            15:23 <+Complication> Forget it, I'm a fool... did the math wrong, it's not nearly as bad :O
            
-
            15:23 < jrandom> insufficient data :)  it might be indicitive of a problem, but what you've described so far suggests things are behaving as desired
            
-
            15:23 <+Complication> It's a bit on the conservative side, but not nearly as bad as I thought
            
-
            15:24 <+Complication> According the Router Console (which measures in the same unit as the limiter) outbound total average is 2/3 of the sustained limit, and 1/2 of the burst limit
            
-
            15:25 <+Complication> But inbound total average, I have to say, is only slightly above 1/3 sustained limit, and 1/4 burst limit
            
-
            15:26 <+Complication> for example, assuming a sustained limit of 30, and a burst limit of 40, outbound would be 20 and inbound just above 10 (mostly due to lack of load)
            
-
            15:26 < jrandom> cool
            
-
            15:26 <+Complication> But the graph I misinterpreted, due to Kb/KB issues :O
            
-
            15:27  * Complication wipes the graph from history
            
-
            15:28 < jrandom> good eye though, definitely lemmie know when things sound funky
            
-
            15:28 < jrandom> ok, anything else on 1) Net status?
            
-
            15:28 < jrandom> if not, lets shimmy on over to 2) ???
            
-
            15:28 < jrandom> anyone have anything else to discuss?
            
-
            15:30 <+Complication> Well, there's been some jbigi testing, and apparently, someone got results which suggested the 64-bit version for Linux being slowish
            
-
            15:31 <+Complication> They had it slower than pure Java, not sure if a measurement glitch or not :O
            
-
            15:32 <+Complication> I couldn't repeat it
            
-
            15:32 < jrandom> yeah, i wasn't sure exactly what .so they were using for the platform
            
-
            15:32 <+Complication> Over here, it was about twice faster than pure Java
            
-
            15:32 <+dust> my experiments with html as an additional message format in syndie is starting to work. my local 'sucker' can now retrieve web pages (with images) and store them as syndie posts
            
-
            15:33 < jrandom> ah wikked dust 
            
-
            15:33 <+dust> no css tho
            
-
            15:33 <+Complication> But people on 32-bit spoke of it being *way* faster then pure Java (like 10x or similar)
            
-
            15:35 < bar> hmm.. Complication, could it be that the current amd64 .so is for 32-bit systems only, and he tested it on a 64-bit OS?
            
-
            15:36 <+Complication> bar: could be, since I tested it too on a 64-bit OS :O
            
-
            15:36 < jrandom> iirc the amd64 was built to work on pure64 debian
            
-
            15:37 <+Complication> Either way, some people suggested that importing a fresher gmp might help
            
-
            15:37 < bar> just a stab in the dark, i'm no wiz at these things
            
-
            15:37 < jrandom> eh, we use 4.1.4
            
-
            15:37 <+Complication> Especially after they've done their soon-to-come version jump
            
-
            15:38 <+Complication> Since I'm no gmp specialist, I couldn't tell much about it
            
-
            15:38 < jrandom> (and the upcoming optimizations in gmp aren't likely to have substantial improvement)
            
-
            15:38 <+Complication> Aside from "perhaps indeed"
            
-
            15:38 < jrandom> improvements come from per-arch builds
            
-
            15:40 <+Complication> In my test, provoked by their test, however the 64-bit athlon lib on a 64-bit Sempron, on a 64-bit Mandriva, however... does seem only marginally quicker than pure Java
            
-
            15:40 <+Complication> (oh, and a 64-bit VM)
            
-
            15:41 <+Complication> (marginally being twice)
            
-
            15:41 < jrandom> hmm 'k
            
-
            15:42 <+Complication> I'll try testing on more platform combinations, and tell if I find anything which seems worth relaying
            
-
            15:43 < jrandom> cool, thanks
            
-
            15:43 < jrandom> ok, anyone have anything else for the meeting?
            
-
            15:46 < jrandom> if not...
            
-
            15:46  * jrandom winds up
            
-
            15:47  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting172.html b/www.i2p2/pages/meeting172.html
deleted file mode 100644
index e3ba0fdf..00000000
--- a/www.i2p2/pages/meeting172.html
+++ /dev/null
@@ -1,65 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 172{% endblock %}
-{% block content %}
            I2P dev meeting, March 14, 2006
            
-
            
-
            15:09 <@jrandom> 0) hi
            
-
            15:09 <@jrandom> 1) Net status
            
-
            15:09 <@jrandom> 2) ???
            
-
            15:09 <@jrandom> 0) hi
            
-
            15:09  * jrandom waves
            
-
            15:09 <@jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001270.html
            
-
            15:10 <@jrandom> while y'all read that massive missive, lets jump into 1) Net status
            
-
            15:10 <@jrandom> the net seems to still work (woot)
            
-
            15:12 < bar> got me a new udp connection high score yesterday, 244
            
-
            15:12 <@jrandom> I don't have much more to add on that front - anyone have any comments/questions/concerns?
            
-
            15:12 <@jrandom> ah nice
            
-
            15:12 <@jrandom> yeah, I'm hitting peak values too, currently 338 SSU connections
            
-
            15:14  * jrandom has also done some substantial i2psnark transfers, though not always at great rates
            
-
            15:15 <@jrandom> I've seen some interesting cyclical variations on stats.i2p regarding tunnel selection though, but that'll be seeing some changes as .0.6.1.13 rolls out
            
-
            15:17 <@jrandom> I've also been doing some low(er) bandwidth testing and optimization, and thats really whats currently holding up ...13.  I think we'll have some good stuff down the pipe, but we'll see how it goes
            
-
            15:18 <@jrandom> ok, if there's nothing else on 1) Net status, lets move on over to the floor - 2) ???
            
-
            15:18 <@jrandom> anyone have anything they want to bring up?
            
-
            15:18 <+Complication> I have only record uptimes to report, and to add that build -6 is very conservative on accepting participating tunnels
            
-
            15:19 <+Complication> (but I mentioned that already earlier)
            
-
            15:19 <@jrandom> nice - its doing well with the lower peer counts still, too, right?
            
-
            15:19 <+Complication> Peer counts have recently risen a bit, actually
            
-
            15:20 <@jrandom> ah 'k
            
-
            15:20 <+Complication> They are now more like 50...100
            
-
            15:20 <+Complication> (generally more towards 50 than 100)
            
-
            15:20 <@jrandom> oh, so still fairly low compared to before
            
-
            15:20 <+Complication> The around-30 values seem to have been as low as it gets
            
-
            15:21 <+Complication> But generally, it's doing fine
            
-
            15:21 <@jrandom> great
            
-
            15:26  * jrandom would like to take this moment for a brief shout-out to some recent contributors supporting I2P - special thanks go out to bar, $anon, postman, and the rest of the folks up at http://www.i2p.net/halloffame!
            
-
            15:27 <@jrandom> contributions of code and content of course are critical, but financial support helps keep me out of the normal workforce and crunching on I2P fulltime, plus our varied infrastructure costs
            
-
            15:28 < bar> me blushes, but thanks :)
            
-
            15:28 <@cervantes> w00t
            
-
            15:29 <+Complication> nice :)
            
-
            15:31 < ripple> jrandom: pastebin.i2p...mission accomplished....
            
-
            15:32 <@jrandom> ripple: thanks - it looks like it behaves as desired - on OOM, it dies a fast and horrible death, which the service wrapper detects and restarts the router
            
-
            15:32 <@jrandom> ok, anyone have anything else for the meeting?
            
-
            15:34 < tmp> Yes, let's pray for the recovery of Betty.
            
-
            15:34  * tethra prays
            
-
            15:34 <@jrandom> your prayers have been answered - she's back :)
            
-
            15:34 < tmp> Faith based I2P.
            
-
            15:35 < tmp> Ok. ;)
            
-
            15:35 < tethra> awesome
            
-
            15:35 < tethra> XD
            
-
            15:35 < fc> tmp: is that a transport protocol or what?
            
-
            15:35 < tethra> anonymous prayer?
            
-
            15:35 <@jrandom> betty == my laptop
            
-
            15:35 < tethra> not even god knows who you are!
            
-
            15:36 <@frosk> how about the new machine that bar so awesomely donated?
            
-
            15:36 <+susi23> jr: you did not name it susi??? shame on you ;)
            
-
            15:37 <@jrandom> the new machine is currently being assembled, an x86_64 (x2) box for windows, gentoo, and perhaps fbsd
            
-
            15:37 <@frosk> cool
            
-
            15:37 <@jrandom> (once its ready, expect some photos on my blog ;)
            
-
            15:38 < fc> bsd! bsd! bsd! ;)
            
-
            15:38 <@jrandom> susi23: the new one will need a new name... ;)
            
-
            15:38 <@cervantes> susan!
            
-
            15:39 <@jrandom> ;)
            
-
            15:39 <@jrandom> ok, if there's nothing else for the meeting...
            
-
            15:39  * jrandom winds up
            
-
            15:39  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting173.html b/www.i2p2/pages/meeting173.html
deleted file mode 100644
index ea5dbbcf..00000000
--- a/www.i2p2/pages/meeting173.html
+++ /dev/null
@@ -1,122 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 173{% endblock %}
-{% block content %}
            I2P dev meeting, March 21, 2006
            
-
            
-
            15:09 <@jrandom> 0) hi
            
-
            15:09 <@jrandom> 1) Net status
            
-
            15:09 <@jrandom> 2) jrobin
            
-
            15:09 <@jrandom> 3) biff and toopie
            
-
            15:09 <@jrandom> 4) new key
            
-
            15:09 <@jrandom> 5) ???
            
-
            15:09 <@jrandom> 0) hi
            
-
            15:09  * jrandom waves
            
-
            15:09 <@jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001271.html
            
-
            15:11 <@jrandom> lets jump briefly on in to 1) Net status
            
-
            15:12 <@jrandom> we've been a while since a release, but things still seem fairly stable.  there are some improvements coming down the pipe though, and I hope to get us a new 0.6.1.13 this week
            
-
            15:13 <@jrandom> anyone have any questions/comments/concerns regarding the status of the network?
            
-
            15:13 <+Complication> About the periodism I noticed yesterday on a freshly started node: it desynchronized itself in a few hours
            
-
            15:14 <@jrandom> ah cool
            
-
            15:14 <+Complication> Meaning, the highs and lows became a lot more random
            
-
            15:14 <@jrandom> I think it still may be worthwhile to jumpstart that at the beginning though
            
-
            15:14 <@jrandom> (for those playing at home, we're talking about the implications of the 10m rebuild period)
            
-
            15:15 <+Complication> Probably helps prevent tunnel failures
            
-
            15:15 <+Complication> I'm still observing a healthy amount of those, but haven't counted
            
-
            15:15 <+tethra> (thanks for the translation :)
            
-
            15:15 <+Complication> Aside from that, working decently here
            
-
            15:16 <+Complication> I think I get "as there are no inbound/outbound tunnels available" about once per 2 hours
            
-
            15:17 <@jrandom> hmm, on an i2phex / i2psnark / eepproxy / ircproxy / eepsite destination?
            
-
            15:17 <@jrandom> (its possible for clients to overload their own tunnels, which is why I ask which)
            
-
            15:18 <+Complication> Checking if there's a trend
            
-
            15:19 <+Complication> Bit of shared clients and Pycache, more of I2Phex
            
-
            15:20 <@jrandom> hmm ok cool, thanks
            
-
            15:20 <+Complication> Significantly more of I2Phex
            
-
            15:20 <+Complication> Might have to limit its bandwidth
            
-
            15:21 <+Complication> (was at default 16K)
            
-
            15:23 <@jrandom> ok cool, anyone have anything else for 1) Net status?
            
-
            15:25 <@jrandom> if not, lets shimmy on over to 2) JRobin
            
-
            15:26 <@jrandom> jrobin is neat.  I like it.  it was dirt easy to integrate, fairly small (177KB), fast, has a low memory overhead, and provides visualizations that are easy to understand
            
-
            15:27 <+Complication> Quite agreed :)
            
-
            15:29 <+Complication> Convenient graphs, with high enough resolution, help find oddities and help ask about them :)
            
-
            15:29 <@jrandom> if there are any rrdtool gurus out there, if you want to give the latest cvs a glance and see what we're doing and/or see if there are easier ways to accomplish these tasks, I'd love some advice
            
-
            15:30 <@jrandom> (rrdtool <-->jrobin info @ http://www.jrobin.org/api/jrobinandrrdtoolcompared.html)
            
-
            15:31 <@jrandom> (and, if someone wants, they could write a fairly small app to read netDb/routerInfo-*.dat, feed them into jrobin databases, and essentially run your own stats.i2p)
            
-
            15:32 <@jrandom> the in-console jrobin integration is different from the stats.i2p functionality though, as it summarizes *your* router, not all routers.  both are useful
            
-
            15:34 <@jrandom> ok, if there's nothing else on 2) JRobin, lets swing on over to 3) biff and toopie
            
-
            15:34 <@jrandom> postman: wanna give us the rundown?
            
-
            15:34 < postman> aah yes
            
-
            15:35 < postman> years ago the mailservice had an irc bot called biff could notify you about new mails
            
-
            15:35 <+Complication> Postman's AI foundry ;P
            
-
            15:35 < postman> with the migration to a new platform biff became unusauble and i had no time to revamp it
            
-
            15:35 < postman> now it's back online again
            
-
            15:35 <@jrandom> (yay!)
            
-
            15:36 < postman> if you wish to monitor your mailbox over irc just /msg biff .help for a list of commands
            
-
            15:36 < postman> usage is straightforward
            
-
            15:36 < postman> question/errors/rants/flames -> postman@mail.i2p
            
-
            15:36 < postman> 2.
            
-
            15:37 < postman> in order to cope with the (hopefully) increasing stream of newbies jr, cervantes and me thougt of a Q&A bot that can be asked for helkp on the usual daily topics and problems
            
-
            15:38 < postman> first draft is named toopie and will soon reside on #i2p (i2p-chat maybe too)
            
-
            15:38 < postman> it will hold a list of topics, and Q&A sorted by topics and indexed by keywords
            
-
            15:38 < postman> toopie can speak to the channel as well as privmsg with a user
            
-
            15:38 <+Complication> Sounds neat, though I've never seen one before :)
            
-
            15:39 < postman> we hope to fill its brain asap
            
-
            15:39 < postman> Complication: you can play with it in #irc2p (in private if you wish :))
            
-
            15:39 <@jrandom> and one of the good parts about it is that we can fill it up with messages on irc :)
            
-
            15:39 < postman> yes
            
-
            15:40 < postman> admins can add some lines straight from irc and make it a new q&a
            
-
            15:40  * tethra suggests an entry purely for the sake of TheJudge/closedshop to the effect of "No, predecessor attacks don't work."
            
-
            15:40 <+tethra> ;)
            
-
            15:40 < postman> hee
            
-
            15:41 < postman> there is still room for the way of structuring the informationm
            
-
            15:41 <@jrandom> (but they do.  though they're not a particular program you "run" to attack someone)
            
-
            15:41 < postman> more to come soon
            
-
            15:41  * postman hand back the mike
            
-
            15:41 <@jrandom> word, thanks postman
            
-
            15:42 < ashter> postman; will toopie speak in other langages too ?
            
-
            15:42 < postman> ashter: not (yet)
            
-
            15:42 <+fox> <mihi> igpay atinlay? *g*
            
-
            15:42 < ashter> ok
            
-
            15:42 < postman> ashter: the infrastructure is there ( /me planned this )
            
-
            15:42 <@jrandom> word
            
-
            15:42 < postman> ashter: it will be a version 2 feature 
            
-
            15:42 < ashter> great, really nice thank you
            
-
            15:44 < postman> (thejudge makes alone 50% of alle irc disconnects today)
            
-
            15:45 < postman> jrandom: ok next topic
            
-
            15:46 <@jrandom> ok cool, anyone have anything else on 3) biff and toopie?
            
-
            15:46 <@jrandom> if not, lets swing on by to 4) new key
            
-
            15:47 <@jrandom> well, there's not really anything to add to what I posted.  new key, yadda yadda
            
-
            15:47 <@jrandom> ok, lets jump on over to 5) ???
            
-
            15:47 <+tethra> erm
            
-
            15:47 <@jrandom> anyone have anything else to bring up?
            
-
            15:48 <+tethra> how does biff know you are you? :/
            
-
            15:48 <+fox> <mihi> tethra: you have to register
            
-
            15:48 <+fox> <mihi> just read what is referenced in the weekly notes :)
            
-
            15:48 < postman> tethra: 1.) you know your mailboxes credentials, 2. you register with an identified nick@biff
            
-
            15:48 <+fox> <mihi> yes :)
            
-
            15:48 <+fox> <mihi> what is the point to have expiring keys when you could have expiring subkeys instead?
            
-
            15:48 <+tethra> postman: ah, ok. thanks.
            
-
            15:49 <@jrandom> mihi: to compartmentalize compromise.
            
-
            15:50 <+fox> <mihi> you can delete expired secret subkeys from your keyring if you wish
            
-
            15:51 <+fox> <mihi> but I guess it is much nicer to have ppl lsign your key every year :)
            
-
            15:51 <+fox> <mihi> nicer in some sadistic point of view :->
            
-
            15:51 < postman> jrandom: now, riddle mihi this :)
            
-
            15:52 <@jrandom> (assuming only the subkey could be compromised)
            
-
            15:54 <@jrandom> in any case, anyone have anything else to bring up for the meeting?
            
-
            15:54 <+fox> <mihi> assume someone compromised your key yesterday. now he can have played a mitm and replaced the new key.
            
-
            15:54 <+fox> <mihi> i.e. compromise one key -> compromise all future keys, isn't it
            
-
            15:55 <+Complication> Unless the owner uses a revocation certificate
            
-
            15:55 <+Complication> invalidate compromised key -> invalidate future ones
            
-
            15:55 <@jrandom> mihi: and I could revoke the compromised key and tell you not to trust new keys
            
-
            15:55 <@jrandom> you now have the choice whether to trust the key change or not
            
-
            15:56 <+fox> <mihi> whom to believe then? :)
            
-
            15:56 <@jrandom> good question.  if you hear a signed revocation in the next day or two, you should discard the new key
            
-
            15:57 <+fox> <mihi> and if it was a subkey, you'd revoked the amin key and the subkey is automatically discarded :)
            
-
            15:57 <+fox> <mihi> s/amin/main/
            
-
            15:58 <+fox> <mihi> agree to disagree?
            
-
            15:58 <@jrandom> aye, that we can agree to ;)
            
-
            15:58 <@jrandom> ok, if there's nothing else for the meeting...
            
-
            15:58 <+fox> * mihi hands jrandom the *baf*er (after years, just like in good old times...)
            
-
            16:00 <@jrandom> hehe
            
-
            16:00  * jrandom winds up
            
-
            16:00  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting174.html b/www.i2p2/pages/meeting174.html
deleted file mode 100644
index ec4b731b..00000000
--- a/www.i2p2/pages/meeting174.html
+++ /dev/null
@@ -1,78 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 174{% endblock %}
-{% block content %}
            I2P dev meeting, March 28, 2006
            
-
            
-
            15:08 < jrandom> 0) hi
            
-
            15:08 < jrandom> 1) Net status and 0.6.1.13
            
-
            15:08 < jrandom> 2) Use case survey
            
-
            15:09 < jrandom> 3) ???
            
-
            15:09 < jrandom> 0) hi
            
-
            15:09  * jrandom waves
            
-
            15:09 < Complication> Finally loaded, reading :)
            
-
            15:10 < jrandom> weekly status notes posted up at dev.i2p.net/pipermail/i2p/2006-March/001274.html
            
-
            15:10 <@cervantes> *** connection reset
            
-
            15:10 < jrandom> heh
            
-
            15:11 < jrandom> ok, while y'all dig into that, lets jump on in to 1) Net status
            
-
            15:12 < jrandom> about 2/3rds of the net has upgraded to 0.6.1.13 (thanks!), and results have been mixed
            
-
            15:12 < jrandom> anyone out there on low bandwidth links have any experiences they want to share?  better / worse / no difference?
            
-
            15:13 < jrandom> or, any results from folks on dsl-class links?
            
-
            15:13  * jrandom has heard (and felt) some results on faster links (largely negative, unfortunately)
            
-
            15:14 <+Complication> Well, I wanted to say that net status is a bit flaky. :) But the net said it first. :D
            
-
            15:15 <+Complication> On the scale of recent disconnects, this was a very rapid recovery, though.
            
-
            15:16 <+Complication> Haven't had any more massive message jams, but it still loses a lease now and then
            
-
            15:17 <+Complication> Also, I think the last router run ended when a lease couldn't be renewed, so it concluded "Router hung!"
            
-
            15:18 < jrandom> ah col
            
-
            15:18 <+Complication> Had been ticking for 15 hours or so
            
-
            15:18 < jrandom> perhaps we should adjust the watchdog to stop restarting the router under those situations
            
-
            15:19 <+Complication> Retransmission is also the same as before (uncomfortably high, but apparently possible to live with - which in itself is good news)
            
-
            15:19 < jrandom> the restart used to be necessary, but recurrant tunnel failure should be recoverable
            
-
            15:19 < jrandom> hmm, <10%, <20%, >20%?
            
-
            15:20 <+Complication> > 20%
            
-
            15:20 <+Complication> I don't know many protocols which work tolerably when every third message goes missing
            
-
            15:21 <+Complication> This one works :) But it used to be around 7%
            
-
            15:21 < jrandom> well, thats averaged across all of the peers, so its probably quite low for most peers, but quite high for highly congested peers
            
-
            15:21 < jrandom> (as shown on peers.jsp)
            
-
            15:22 <+Complication> True, and I haven't taken a look at that side of the distribution yet
            
-
            15:23 <+Complication> Might need to check, if for nothing else, then to verify how it's distributed
            
-
            15:24 < jrandom> cool, thanks Complication 
            
-
            15:24 < jrandom> ok, anyone have anything else on 1) Net status?
            
-
            15:25 < bar> Complication: may i ask what burst limit you are using? mine are set to 60% of my theoretical upload max, and i currently have a retransmission ratio of 11% 
            
-
            15:26 <+Complication> bar: it's around 80% of line speed
            
-
            15:26 < bar> ok
            
-
            15:26 <+Complication> On the same level as it was, when retransmission was around 7%
            
-
            15:26 <+Complication> Had it higher meanwhile, but brought back down
            
-
            15:28 < bar> i'll try to use 80% for a day or so to see if anything happens
            
-
            15:28 <+Complication> And sustained transfer limit is around 65%
            
-
            15:28 <+Complication> Actual transfer, if the total indicator is correct, averages near 60% of line speed
            
-
            15:29 <+Complication> (peaks are higher)
            
-
            15:30 < ashter_> for my part lot of 'no lease' thing for local destination (as i said today)
            
-
            15:30 < ashter_> and a node a bit more congested
            
-
            15:30 <+fox> <nextgens> hi
            
-
            15:30 < jrandom> heya nextgens
            
-
            15:30 < jrandom> ashter_: hmm, are you on dialup, dsl/cable, or faster?  or, better said (more anonymously), are you congested?
            
-
            15:31 <+fox> <nextgens> cool, jrandom is around :) you might help me :)
            
-
            15:31 < jrandom> (as in, network congestion, not the numbers i2p displays)
            
-
            15:31 < ashter_> dsl/cable
            
-
            15:32 < jrandom> ok thanks
            
-
            15:33 < jrandom> ok, if there's nothing else on 1) Net status, lets jump on over to 2) Use case survey
            
-
            15:34 < jrandom> I don't expect anwers immediately, but if y'all could put some thought into the questions from the mail and post up replies (either to the forum, syndie, the list, etc), it'd be much appreciated
            
-
            15:37 <@cervantes> *cough*
            
-
            15:38 <+tethra> oh dear :/
            
-
            15:39 < jrandom> (|grep -v -- -\!- ;)
            
-
            15:39 < jrandom> ok, as I said though, bounce word through whatever fashion you care to use at your convenience.  gracias
            
-
            15:39 < jrandom> movin' on to 3) ???
            
-
            15:39 < jrandom> anyone have anything they want to bring up for the meeting?
            
-
            15:40 <@cervantes> http://forum.i2p.net/viewtopic.php?p=7442  <-- sticky thread for use case discussion
            
-
            15:40 < jrandom> ah cool, thanks cerv
            
-
            15:42 < ashter> (erf that happened once again, and when this occurs participating tunnels grows insanly :( )
            
-
            15:43 < jrandom> hmm, to the thousands, or hundreds?
            
-
            15:43 < jrandom> (there are a few fixes for bursts of new tunnels pending, should be out later this week)
            
-
            15:43 < ashter> thousands
            
-
            15:44 < ashter> (ok thank you)
            
-
            15:44 < jrandom> ok cool.  you may want to conider lowering your bandwidth limit or share percentage in the meantime
            
-
            15:44 < jrandom> ok, anyone have anything else for the meeting?
            
-
            15:45 < jrandom> if not...
            
-
            15:45  * jrandom winds up
            
-
            15:46  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting175.html b/www.i2p2/pages/meeting175.html
deleted file mode 100644
index 4cfe80c5..00000000
--- a/www.i2p2/pages/meeting175.html
+++ /dev/null
@@ -1,132 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 175{% endblock %}
-{% block content %}
            I2P dev meeting, April 4, 2006
            
-
            
-
            16:21 < jrandom> 0) hi
            
-
            16:21 < jrandom> 1) Net status and 0.6.1.14
            
-
            16:21 < jrandom> 2) Syndie plotting
            
-
            16:21 < jrandom> 3) Local jbigi optimizations
            
-
            16:21 < jrandom> 4) ???
            
-
            16:21 < jrandom> 0) hi
            
-
            16:21  * jrandom waves
            
-
            16:21 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-April/001275.html
            
-
            16:21  * Complication reads
            
-
            16:22 < jrandom> while y'all read that (briefly put together) post, lets jump on in to 1) Net status
            
-
            16:23 <@cervantes> (forum back)
            
-
            16:23 < jrandom> there are a few problems out there affecting use on 0.6.1.13, and most of tem have been tracked down and solved
            
-
            16:24 < Complication> Over here, with the "fourth" CVS build, I noticed a change in my graphs
            
-
            16:24 < jrandom> here are still a few kinks getting tested and revamped though, but a release should be out in the next few days
            
-
            16:24 < Complication> In general, things moved towards more stability and less jumpyness
            
-
            16:24 < jrandom> oh bugger, I forgot to increment it to -4 didn't I?
            
-
            16:24 < jrandom> (ok, -5 will be out later this evening)
            
-
            16:24 < jrandom> cool Complication 
            
-
            16:25 < Complication> But my perceptions could be influenced by jbigi too, as I didn't take steps to exclude that
            
-
            16:25 < Complication> Now, after a while, retransmission has edged down to 15% too
            
-
            16:28 < jrandom> hmm, i'm also seeing my average ssu rto approach the 3s ceiling as well
            
-
            16:28 < jrandom> (though very low retransmission still, under 5%)
            
-
            16:29  * Complication takes a second look at it
            
-
            16:29 < Complication> Let's say the raw average is a little over 1500
            
-
            16:29 < Complication> (over here)
            
-
            16:30 <+fox> <BrianR___> jrandom: Is there a de-facto "MTU" for i2p packets?
            
-
            16:30 < jrandom> ah ok, perhapsas that inches up, the retransmission rate will go down
            
-
            16:30 < Complication> I noticed mine start out with smaller MTUs, now it's upped some to 1350
            
-
            16:30 < jrandom> BrianR___: yes, either 1350 or 608 (as shown on http://localhost:7657/peers.js)
            
-
            16:31 < jrandom> if the failure rate is too high at the larger MTU, it falls back to the smaller MTU (and if its too low at the smaller MTU, it jumps up to the higher MTU)
            
-
            16:31 <+fox> <BrianR___> jrandom: Now is that for the inside payload or the visible IP packets?
            
-
            16:31 <+fox> <BrianR___> Ie, if I were to send a block of data over an I2P stream, what would be the ideal size for the chunks to minimize overhead?
            
-
            16:31 < jrandom> that is for the UDP payload
            
-
            16:32 < jrandom> streams are two layers up
            
-
            16:32 < jrandom> (there's fragmentation for tunnels, and then fragmentation at the stream/i2cp level)
            
-
            16:32 <+fox> <BrianR___> Yes... Is there an ideal size to minimize fragmentation?
            
-
            16:32 < jrandom> the ideal block size of an app using the streaming lib is "large", so that the streaming lib can use the appropriate size.
            
-
            16:33 < jrandom> (aka ignore the man behind the curtain)
            
-
            16:33 <+fox> <BrianR___> Aah.. Maybe I should think about pipelining or something then..
            
-
            16:34 <+fox> <BrianR___> I'm planning an app with lots of request/response traffic...
            
-
            16:34 < jrandom> i'd recommend batching then to cut down on the chattyness
            
-
            16:34 < Complication> Perhaps keeping traffic focused would help to some extent
            
-
            16:37 < jrandom> ok, anyhing else on 1) Net status, or shall e shimmy on over to 2) Syndie plotting
            
-
            16:38  * jrandom shimmies
            
-
            16:39 < jrandom> this is largely a placeholder and cfp - there's going to be some substantial revamp to syndie, both in operaion and the ui, so if you've got some key features or use cases you think need to be addressed, get in touch
            
-
            16:40 < jrandom> (more info will be of course forthcoming as things get fleshed out further)
            
-
            16:42 < jrandom> thats all i've got to say on that for the moment, so, moving on over to 3) jbigi optimizations
            
-
            16:42 <@frosk> and i had assumed "plotting" referred to some jrobin stuff in syndie :)
            
-
            16:43 < jrandom> hehe
            
-
            16:43 < jrandom> it'd be interesting to plot posts/day, posts/author, new authors/day, etc ;)
            
-
            16:44 < Complication> Oh, on bit about Syndie (sorry, only now remembered)
            
-
            16:44 < Complication> =one bit
            
-
            16:44 <@frosk> which do you want, 0 or 1? :)
            
-
            16:44 < Complication> Do you think it could be practical, or easy/difficult to separate favourite authors and blacklisted (spam)authors into two different lists?
            
-
            16:45 < Complication> On addresses.jsp
            
-
            16:45 < jrandom> oh, yeah without much trouble
            
-
            16:46 < jrandom> thats a good idea for therevamp too, but perhaps we can get that into the 0.6.1.14 build
            
-
            16:47 < Complication> Nah, it's not byting me, I just remembered something I noticed back then
            
-
            16:47 < Complication> Anyway, jbigi gets faster on Linux/AMD64 when you compile locally and use GMP 4.2
            
-
            16:48 < jrandom> cool
            
-
            16:48 < jrandom> did you compare that w/ -O3 -m64 on GMP 4.1.2?
            
-
            16:48 < Complication> And I'm a damn fool for going after way wrong compile flags :O
            
-
            16:48 <@cervantes> the relevant link was http://forum.i2p/viewtopic.php?t=1523&start=30 btw
            
-
            16:48 < jrandom> ah thanks cervantes 
            
-
            16:48 < Complication> jrandom: I haven't compared yet, but will
            
-
            16:49 < Complication> During next scheduled reboot
            
-
            16:50 < jrandom> the jbigi build process is essentially "build GMP, then build jbigi.o, and link the two together", so any sort of optimizations people want to make on GMP can be made as the first step
            
-
            16:50 <@cervantes> I've not seen much difference between -O3 and -O2 in any previous tests I've done, whether that's different under x86_64 ... *shrug*
            
-
            16:50 < jrandom> aye, might be compiler rev dependent as well
            
-
            16:50 < jrandom> (especially with all these 3.3/3.4/4.0/4.1 issues)
            
-
            16:51 <@cervantes> just to re-iterate what I mentioned in that thread... we probably won't see windows64 optimised jbigi anytime soon
            
-
            16:51 <+fox> <BrianR___> Does the i2p stream lib do payload compression?
            
-
            16:52 < Complication> BrianR: yes
            
-
            16:52 <@cervantes> unless someone has M$ VC 2005 w/64-bit SDK and fancies some heavy toil to get it to compile gmp
            
-
            16:52 < Complication> At least to my knowledge
            
-
            16:53 <@cervantes> (there was a project to port gmp into a vc project somewhere though)
            
-
            16:53 < jrandom> cervantes: well, we've got one that /works/ for amd64/win, but it doesn't use the most out of the hardware ;)
            
-
            16:53 < jrandom> (when my new box gets here though i may be able to tweak that, as its an amd64)
            
-
            16:53 <+fox> <BrianR___> trying to figure if I should use a binary protocol to save bits or if zlib or something is going to smoosh up ascii protocol nice and small..
            
-
            16:54 <@cervantes> coolio - unfortunately Mingw64 or cygwin64 doesn't seem to be on the near horizon...
            
-
            16:54 < jrandom> BrianR___: premature optimization being the root of all evil, and all that jazz...
            
-
            16:55 < Complication> at least partly human readable protocols are generally easier to debug, but I guess it depends what one's doing
            
-
            16:56 < Complication> ('cause some things like encryption don't like being human-readable, no matter what :) )
            
-
            16:57 < Complication> But if I2P does the encryption, and also compresses, good chances are that many things which occur on top of it, can be done with human-readable protos
            
-
            16:58 < jrandom> aye
            
-
            16:58 < jrandom> ok, anything else on 3) jbigi stuff?
            
-
            16:58 < jrandom> if not, lets move to 4) ??? 
            
-
            16:59 < jrandom> anyone have anything else for the meeting?
            
-
            17:01 <+tethra> i recall hearing something about anonymous collaboration tools recently
            
-
            17:01 <+tethra> care to elaborate on what kind, and whether they'll be syndie-esque or not?
            
-
            17:02 <@cervantes> irc and syndie is an anonymous collaboration tool :)
            
-
            17:02 < jrandom> hmm, not sure of what you refer to - or maybe you mean the actual planned syndie revamps?  :)
            
-
            17:02 <+tethra> true.
            
-
            17:02  * tethra isn't sure either, which is why he asked
            
-
            17:02 <+tethra> there was talk of it on the forums - reasons for anonymity and stuff
            
-
            17:03 <+tethra> i'll find the thread so i can get the quote
            
-
            17:03 < jrandom> ah right
            
-
            17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618
            
-
            17:03 < jrandom> the use case thread
            
-
            17:03 <+tethra>  - anonymously hosted & publicly reachable forums/boards/wikis 
            
-
            17:03 <+tethra> yeah
            
-
            17:04 <+tethra> is there going to be an i2wiki type project that is based around something like syndie or is it up to users?
            
-
            17:04 < jrandom> there have been some good ideas in there, and some good feedback
            
-
            17:05 < jrandom> the ability to edit syndie posts is an oft-requested feature, and with that, you could pull off a wiki w/ a rich editor
            
-
            17:05 < jrandom> but, of course, nothing will exist in a vaccum - if someone believes that is necessary, someone should say "hey, a wiki is essential, and here's why"
            
-
            17:06 < jrandom> there are an infinite number of apps that /can/ be built, but as we're aiming for strong anonymity and strong security, care must be taken in what is built
            
-
            17:07 <+tethra> right
            
-
            17:07 <+tethra> that said, some of the more difficult things to keep anonymous and secure might be better off being done by someone who is good at keeping things anonymous and secure, right?
            
-
            17:08 < jrandom> likely so, though there is no cabal - anyone can learn
            
-
            17:08 <+tethra> (key things, basically. not that i'm naming any, but hey.)
            
-
            17:08 <+tethra> true
            
-
            17:09 <+tethra> but learning at the cost of your own and other people's anonymity isn't the greatest way of doing it
            
-
            17:10 < jrandom> everyone has to start somewhere, of course
            
-
            17:10 <+tethra> (perhaps if someone made a sandbox type thing that allowed people to run $software and have people attack it and stuff that'd be good for someone who is new/inexperienced?)
            
-
            17:10 <+tethra> yeah
            
-
            17:14 < jrandom> ok, anyone else have anything for the meeting?
            
-
            17:15 < jrandom> if not
            
-
            17:15  * jrandom winds up
            
-
            17:15 <@cervantes> *ahem*
            
-
            17:15  * jrandom pauses
            
-
            17:16 < jrandom> whats shakin' cerv? 
            
-
            17:16 < Complication> Neat, I found a baf ;P
            
-
            17:17 < jrandom> baf-blocked ;)
            
-
            17:17 <@cervantes> hups srry, continue baffing
            
-
            17:17  * jrandom resumes winding
            
-
            17:18  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting176.html b/www.i2p2/pages/meeting176.html
deleted file mode 100644
index 04441552..00000000
--- a/www.i2p2/pages/meeting176.html
+++ /dev/null
@@ -1,180 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 176{% endblock %}
-{% block content %}
            I2P dev meeting, April 18, 2005
            
-
            
-
            16:09 < jrandom> 0) hi
            
-
            16:09 < jrandom> 1) Net status and 0.6.1.16
            
-
            16:09 < jrandom> 2) Tunnel creation and congestion
            
-
            16:10 < jrandom> 3) Feedspace
            
-
            16:10 < jrandom> 4) ???
            
-
            16:10 < jrandom> 0) hi
            
-
            16:10  * jrandom waves
            
-
            16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-April/001281.html
            
-
            16:10  * frosk too
            
-
            16:10 < jrandom> (almost two hours *before* the meeting, too :)
            
-
            16:11 < jrandom> ok, since i'm sure y'all've already poured over the notes, lets jump into 1) Net status
            
-
            16:12 <+Complication> Hi :)
            
-
            16:12  * Complication quickly grabs the notes
            
-
            16:12 < jrandom> the 0.6.1.16 release fixed a very long standing but in our prng, which had caused a substantial number of arbitrary tunnel rejections
            
-
            16:13 < jrandom> (the root cause was injected last october, but is fixed now)
            
-
            16:13 <+Complication> Status over here: works tolerably with 1 + 0..1 hop tunnels, won't behave with 2 + 0..1 or 2 +/- 0..1
            
-
            16:14 < jrandom> aye, thats understandable too, especially under slower links
            
-
            16:14 < jrandom> (unfortunately, "slower" isn't all that slow, either)
            
-
            16:15 < jrandom> there is still much work to do, and 0.6.1.16 isn't where we need to be, but its progress
            
-
            16:17 <+Complication> Something I've been thinking of,  with regard to what you called "congestion collapse"
            
-
            16:18 <+Complication> One way to limit its impact might be to actually *require* a router to accept a certain quota of participation requests
            
-
            16:19 <+Complication> (something specified by the user either directly or indirectly?)
            
-
            16:19 < jrandom> specified by which user?
            
-
            16:19 <+Complication> (e.g. some part of share percentage or an additional parameter)
            
-
            16:19 < jrandom> the local user, or by us as remote users?
            
-
            16:19 <+Complication> Specified by everyone for themselves
            
-
            16:19 <@frosk> should we move over to 2) then? :)
            
-
            16:20 < jrandom> aye, might as well consider us on 2) :)
            
-
            16:20 <+Complication> So that I could, for example, tell my router "even if you're congested, keep routing a minimum of 4 KB/s"
            
-
            16:21 < jrandom> Complication: thats not really possible - if a router is too congested, other people will (hopefully ;) stop asking them to participate in tunnels.
            
-
            16:21 <+Complication> (this would, of course, mean that some local destination could be offline a while longer)
            
-
            16:21 < jrandom> and if they aren't asked, they /cant/ push other people's data
            
-
            16:22 <+Complication> Ah, perhaps I should have phrased it significantly clearer
            
-
            16:24 <+Complication> I imagined it could, under a certain quota of participating traffic, throttle its own tunnel creation messages instead of participating tunnels
            
-
            16:24 <+Complication> e.g. "I'll never throttle my participating tunnels to less than 4 KB/s. If that would be needed, I'll instead throttle my own traffic."
            
-
            16:26 < jrandom> hmm, there are anonymity risks in that (though still along the same lines of selective DoS, which we don't defend against anyway)
            
-
            16:27 < jrandom> but throttling our own local tunnel builds in face of congestion is something i've got in testing now - adding support tooptionally ignore the 4KBps floor should be simple enough
            
-
            16:28 < spinky> Currently, you get no cover traffic at all when transferring lots of data.
            
-
            16:29 < spinky> Having a floor for participation bw sounds good.
            
-
            16:30 < jrandom> well, we do have a floor (both as the share percentage and an internal 4KBps reserved after all bw is assigned)
            
-
            16:30 <+Complication> Bah, disconnects... I hope much wasn't lost of what I said, but any replies I'll have to read from the log :)
            
-
            16:32 <@frosk> is there anything significant about 4KBps?
            
-
            16:33 < jrandom> a few things - 4KB ~= sizeof(tunnel create message), and heuristically, i've never heard of a router running uccessfully on less
            
-
            16:33 < spinky> Maybe it's the bugs that keep the share percentage from working then?
            
-
            16:34 < jrandom> what makes you say the share percentage doesn't work?
            
-
            16:34 <@frosk> i see
            
-
            16:34 <+Complication> frosk: nah, it's just a number in the current code, and I referred to it while trying to explain what I imagined too
            
-
            16:35 <+Complication> (not because of meaningful reasons, just because what I imagined was, in a certain sense, its equal opposite)
            
-
            16:35 < spinky> It's set to 80% and participation goes to 0 when locally generating data. Perhaps I'm misunderstanding things.
            
-
            16:36 < jrandom> ah, yes, thats not what the share percentage does
            
-
            16:36 <+Complication> spinky: it's a maximum limit of what may be shared, subject to bandwidth actually available for sharing
            
-
            16:37 <+Complication> If local traffic takes up 70%, you've only got 10% left for sharing
            
-
            16:37 <+Complication> If local traffic is heavy, you'll have 0% left, and the top limit of 80% will never be touched
            
-
            16:37 < spinky> Ok. I see it says 'up to'...
            
-
            16:38 <+Complication> And also, there's the 4 KB/s reserve
            
-
            16:38 < jrandom> ah, its share percentage of what you have available
            
-
            16:38 < spinky> Maybe another setting for the floor participation bw, under which the router will accept more tunnels?
            
-
            16:38 < jrandom> if you are using 95% of your bw, it will share up to 80% of the remaining 5%
            
-
            16:39 <+Complication> Oh, then I've partly misunderstood it too
            
-
            16:40 < fox> <zorglu1> how i2p measure the amount of bw used by other local applications ?
            
-
            16:40 < spinky> (Just saying, if you consider cover traffic a good thing maybe having it configurable even under heavy local bw usage is a good thing)
            
-
            16:40 <+Complication> I thought it was applied against the sustained limit
            
-
            16:40 < jrandom> zorglu1: it measures i2p's bw usage, and knows i2p's bw limits
            
-
            16:41 < jrandom> oh, hmm, looking back at the code, int availBps = (int)(((maxKBps*1024)*share) - used);
            
-
            16:41 < jrandom> so you're right Complication 
            
-
            16:42 < jrandom> spinky: cover traffic is only so useful on a low latency mixnet
            
-
            16:42 < jrandom> it does add some incentive for higher bw routers, but those w/out bw to spare have little recourse
            
-
            16:49 < jrandom> anyway, the tunnel congestion issue has been around for a while, but only recently exacerbated by the insane tunnel rejection rates
            
-
            16:49 < jrandom> hopefully the next rev will clear it up for us
            
-
            16:49 < jrandom> ok, anyone have anything else on 2) tunnel creation and congestion?
            
-
            16:50 <@frosk> sounds like it would take some changes to the tunnel-building scheme
            
-
            16:50 <+Complication> I hope it will help improve things :)
            
-
            16:51 <+Complication> Oh, by the way...
            
-
            16:52 < jrandom> well, we've got some cheap fixes, such as reducing the max concurrency, throttling our build attempts when congested, reducing the drop frequency (as opposed to explicit rejection), and adjusting the profiling to incentivize explicit rejections as opposed to drops
            
-
            16:52 <+Complication> ...did you perchance find anything which could explain the big disparity between raw bandwidth indicators and tunnel payload indicators?
            
-
            16:52 <+Complication> (e.g. total banwidth 1 GB, tunnel payload summed up 300 MB)
            
-
            16:52 < jrandom> but its true, those only affect the magnitude
            
-
            16:52 <+Complication> (since I haven't been around IRC lately, I'm not sure if you've been looking at that one recently)
            
-
            16:54 < jrandom> havent dug into that much, but remember, tunnel build requests for outbound tunnels aren't tunnel messages (and there are lots of them if only .1% are successful.  and at 4KB each...)
            
-
            16:54  * Complication isn't certain if it's the indicators, or a real effect
            
-
            16:55 <+Complication> Oh... outbound build requests... indeed
            
-
            16:55 < jrandom> the upcoming -1 build adds a slew of stats for monitoring per-message-type packet monitoring
            
-
            16:55 <+Complication> That could be precisely it
            
-
            16:55 < jrandom> (also included in those outbound build requests are build participationg requests - forwarding a reply)
            
-
            16:56 < jrandom> ((so its not just local stuff))
            
-
            17:00 <+Complication> > Thanks, that explains it a whole lot :)
            
-
            17:00 <+Complication> > It ain't voodoo then, but quite real traffic, which I just forgot, since it wasn't specifically counted in the places I checked
            
-
            17:00 <+Complication> It would indeed have to occur, and would indeed cost a lot of bytes
            
-
            17:00 <+Complication> Especially with low success rates
            
-
            17:01 < jrandom> aye, though i shouldn't cost as much as it does, since we should have higher success rates than we do :)
            
-
            17:01 < jrandom> ok, anything else on 2)?
            
-
            17:02 < jrandom> if not, lets swing on over to 3) Feedspace
            
-
            17:02 < jrandom> frosk: wanna give us an update?
            
-
            17:03 < jrandom> (or tell us to fsck off and read the eepsite?  ;)
            
-
            17:04 <@frosk> well, for those who haven't paid attention to frosk.i2p or feedspace.i2p, feedspace is now basically working (for my own defintion of "basically)
            
-
            17:04 < jrandom> (w00t)
            
-
            17:05 <@frosk> there's been some nice additions lately, like infrastructural support for transports other than i2p (tor and non-anonymous tcp/ip comes to mind)
            
-
            17:06 <@frosk> so in time, we plan to allow syndie (in an upcoming and probably very nice rewrite) to use feedspace as one of its syndication methods
            
-
            17:06 <@frosk> for now, there aren't any client apps to actually *use* feedspace for anything :) i've been testing with an extremely crude servlet app
            
-
            17:07 < jrandom> (crude + functional)++
            
-
            17:07 <@frosk> so there is of course a job opening for a client hacker ;)
            
-
            17:08 <@frosk> there are still some necessary stuff that feedspace needs before any public testing, but it shouldn't be long now :)
            
-
            17:08 < jrandom> nice1
            
-
            17:08 < jrandom> anything we can do to help?
            
-
            17:08 <@frosk> also i've been working a bit on documentation, which has been lacking
            
-
            17:09 < spinky> Do you see feedspace being usable for large files?
            
-
            17:10 <@frosk> 1) client apps using the (still undocumented) xmlrpc api, 2) http://feedspace.i2p/wiki/Tasks, 3) participate in testing when that time comes
            
-
            17:10 <@frosk> large files support is not a priority for now, but perhaps later
            
-
            17:10 <@frosk> focus for "1.0" is smaller messages such as blog and discussion entries, and events of any sort
            
-
            17:11 < jrandom> though feeding .torrent files into an rss/feedspace-enabled bt client wouldn't be a problem
            
-
            17:11 <@frosk> large files may or may not work :)
            
-
            17:11 <@frosk> that would be a superneat thing
            
-
            17:12 < jrandom> feed2snark ;)
            
-
            17:12 <@frosk> i hope we'll see all sorts of such "adapter" apps :)
            
-
            17:12 <+Complication> Well, I'm sure people will find ways to move large files using bit... umm, side channels :)
            
-
            17:15 <@frosk> i feel a bit guilty about the feedspace code using all sorts of java1.5 features. it would probably be hard to compile/use on free java right now, but it will catch up i'm sure :)
            
-
            17:15 < jrandom> yikes
            
-
            17:16 < jrandom> well, there are rumors of gcj adopting ecj for 1.5-isms
            
-
            17:16 < spinky> Complication: Ponies with saddle bags full of hdds?
            
-
            17:16 <@frosk> yep
            
-
            17:17 <+Complication> spinky: drones, in my preferred case :P
            
-
            17:17  * jrandom is still barely moving up to 1.4-isms
            
-
            17:17 <+Complication> But I guess ponies work too :P
            
-
            17:17 < jrandom> though 1.6 sure is nice ;)
            
-
            17:17 <@frosk> to stay gcj-compatible?
            
-
            17:18 <@frosk> well 1.6 doesn't have a lot of "isms" for most things anyway i think :)
            
-
            17:18 <+Complication> (or flying hedgehogs airdropping memory cards)
            
-
            17:18 < jrandom> gcj/classpath/etc, but also for performance (i've found 1.5 a bit heftier than 1.4)
            
-
            17:19 < jrandom> true, 1.6's improvements are largely vm/bytecode specific
            
-
            17:19 <@frosk> hm ok
            
-
            17:20  * jrandom isn't trying to pursuade you not to use 1.5isms.  i'm sure you've got your reasons, and e.g. azureus already requires 1.5
            
-
            17:21 <@frosk> well there's no going back :) hopefully it won't be too bumpy
            
-
            17:24 < jrandom> aye, i'm ure it'll work out fine :)
            
-
            17:25 < jrandom> ok cool, anyone have anything else on 3) feedspace?
            
-
            17:25  * frosk hugs his generics and java.util.concurrent ;)
            
-
            17:25 < jrandom> heheh
            
-
            17:27 < jrandom> ok, if there's nothing else on 3, lets move on over to 4) ???
            
-
            17:27 < jrandom> anyone have anything else for the meeting?
            
-
            17:27 <+Complication> A little question which I should have asked under 2)
            
-
            17:28 <+Complication> Do you know, how do idle participating tunnels typically form?
            
-
            17:28 <+Complication> Are they mostly a sign of failed tunnel builds, where only the creator really knows it failed?
            
-
            17:28 <+Complication> Or do they have additional reasons?
            
-
            17:28 <+Complication> (besides, of course, the obvious - namely an app sitting idle)
            
-
            17:29 < jrandom> an idle app wouldn't have idle tunnels (they'd be tested)
            
-
            17:29 < jrandom> idle tunnels are failed for some reason or another
            
-
            17:29 < jrandom> (either failed to be creted fully, or failed during operation)
            
-
            17:30 <+Complication> Right, so all tunnels are tested anyway, and tunnel testing should cause traffic... indeed
            
-
            17:30 <+Complication> That actually brings me to the second part of my question: would it offer any benefit to notice that a tunnel is idle, and scrap it early?
            
-
            17:31 <+Complication> Are there any precious resources to be saved there?
            
-
            17:32 < jrandom> none - a tunnel that isn't pushing data isn't using up resources
            
-
            17:32 < jrandom> (ok, its using up some ram, perhaps 32 bytes)
            
-
            17:32 <+Complication> Or perhaps, could it help a router to keep a better picture of its load and similar parameters...
            
-
            17:33 < jrandom> predictions on bw usage bsed on the tunnel history is certainly an open question
            
-
            17:33 <+Complication> Or would it just be pointless work, and it's best to wait until it expires naturally?
            
-
            17:33 <+Complication> (like it does now)
            
-
            17:34 < jrandom> we used to do some predictions, but it didn't give us clear benefits, so we're using a simpler algorithm now
            
-
            17:34 <+Complication> Aha, so no gain...
            
-
            17:34 <+Complication> Thanks, that was basically all I wanted to ask about it :)
            
-
            17:34 < jrandom> np, understandable concern
            
-
            17:34 < jrandom> ok, anyone have anything else for the meeting?
            
-
            17:35 <+Complication> Yeah, if one did predictions, the percentage of idling tunnels might tilt estimates
            
-
            17:35 <+Complication> (if it varied significantly)
            
-
            17:36 < jrandom> aye, we'd want to keep idle % as part of the estimate
            
-
            17:36 < jrandom> (we used to - see the RouterThrottleImpl.allowTunnel method)
            
-
            17:37 <+Complication> Oh, didn't know that :)
            
-
            17:37 < jrandom> and note the new comment:
            
-
            17:38 < jrandom>  // ok, ignore any predictions of 'bytesAllocated', since that makes poorly
            
-
            17:38 < jrandom>  // grounded conclusions about future use (or even the bursty use).  Instead,
            
-
            17:38 < jrandom>  // simply say "do we have the bw to handle a new request"?
            
-
            17:39  * Complication is still browsing towards the file, but thanks :)
            
-
            17:39 < jrandom> w3rd
            
-
            17:40 < jrandom> ok, if there's nothing else for the meeting...
            
-
            17:40  * jrandom winds up
            
-
            17:41  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting177.html b/www.i2p2/pages/meeting177.html
deleted file mode 100644
index 4ffb95db..00000000
--- a/www.i2p2/pages/meeting177.html
+++ /dev/null
@@ -1,154 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 177{% endblock %}
-{% block content %}
            I2P dev meeting, April 25, 2005
            
-
            
-
            16:12 < jrandom> 0) hi
            
-
            16:12 < jrandom> 1) Net status and 0.6.1.17
            
-
            16:12 < jrandom> 2) I2Phex
            
-
            16:13 < jrandom>  3) ???
            
-
            16:13 < jrandom> 0) hi
            
-
            16:13  * jrandom waves
            
-
            16:13 <@cervantes> 'lo
            
-
            16:13 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html
            
-
            16:14 < jrandom> while y'all skim that, lets jump into 1) Net status 
            
-
            16:14 < jrandom> so, as most of y'all have seen, we've got a new release out, and so far, the results have been pretty positive
            
-
            16:15 <@cervantes> (yay!)
            
-
            16:15 < jrandom> still not where we need to be, but it pretty much sorts out the main issues we were seeing
            
-
            16:15 < jrandom> aye, 'tis nice to have halfway decent tunnel build rates again, at 2+ hop tunnels :)
            
-
            16:16  * jrandom has 50%+ success rates on another router w/ 1hop tunnels
            
-
            16:17 < jrandom> I think the last few changes in 0.6.1.17 should help avoid this sort of congestion collapse in the future as well
            
-
            16:17 < jrandom> the user-visible result though is that we'll occationally see lease expirations, but rather than compounding itself, it'll back off
            
-
            16:17  * cervantes sparks up azureus
            
-
            16:18 <+Complication> This morning, I recorded client tunnel (length 2 +/- 1) success rates near 35%
            
-
            16:18 <+Complication> Currently it's lower, since I tried making some modifications, and the latest of them wasn't so great :D
            
-
            16:18 <@cervantes> jrandom: well done tracking that down - we were beginning to look like freenet for a bit :)
            
-
            16:19 < jrandom> *cough* ;)
            
-
            16:20 <+fox> <inkeystring> jrandom: would you mind briefly describing the backoff mechanism? i'm working on something like that for freenet 0.7 at the moment
            
-
            16:21 < jrandom> inkeystring: we've had a transport layer backoff mechanism in place to cut down transmissions to a peer when the transport layer is overloaded, but that wasn't sufficient
            
-
            16:21 <@cervantes> *cough* did I say freenet, I meant tor
            
-
            16:21 <+fox> <inkeystring> :-)
            
-
            16:22 < jrandom> inkeystring: the new change was to propogate that up to a higher level so that we stopped trying to build tunnels when our comm layer was saturated
            
-
            16:22 < jrandom> (rather than sending more tunnel build attempts)
            
-
            16:22 <+fox> <inkeystring> thanks - does the transport layer only back off when packets are lost, or is there some way for the receiver to control the flow?
            
-
            16:23  * jrandom seems to recall discussing the impact of congestion *vs* routing w/ toad a few times (on irc and my old flog), though i don't recall any net-positive solution :/
            
-
            16:23 < jrandom> the receiver can NACK, and we've got hooks for ECN, but they haven't been necessary
            
-
            16:23 <+fox> <inkeystring> yeah the debate has resurfaced on freenet-dev :-) still no silver bullet
            
-
            16:24 <+fox> <inkeystring> cool, thanks for the information
            
-
            16:24 <+Complication> They're using UDP too these days, aren't they?
            
-
            16:24 < jrandom> currently, the highly congested peers have trouble not with per-peer throttling, but with the breadth of the peer comm
            
-
            16:24 <+Complication> (as the transport protocol)
            
-
            16:24 <+fox> <inkeystring> breadth = number of peers?
            
-
            16:24 < jrandom> yes
            
-
            16:25 < jrandom> with the increased tunnel success rates, peers no longer need to talk to hundreds of peers just to get a tunnel built
            
-
            16:25 < jrandom> so they can get by with just 20-30 peers
            
-
            16:25 < jrandom> (directly connected peers, that is)
            
-
            16:26 <+fox> <inkeystring> i guess that's good news for nat hole punching, keepalives etc?
            
-
            16:26 < jrandom> otoh, w/ 2-300 active SSU connections, a 6KBps link is going to have trouble
            
-
            16:26 < jrandom> aye
            
-
            16:26 <+fox> <inkeystring> Complication: yes
            
-
            16:27 <+fox> <inkeystring> (in the 0.7 alpha)
            
-
            16:27 <+Complication> Aha, then they're likely facing some similar stuff
            
-
            16:27 <+Complication> I hope someone finds the magic bullet :D
            
-
            16:27 < jrandom> in a different way though.  the transport layer is a relatively easy issue
            
-
            16:27 <+fox> <inkeystring> i think they might have reused some of the SSU code... or at least they talked about it
            
-
            16:27 < jrandom> (aka well studied for 30+ years)
            
-
            16:28 < jrandom> but i2p (and freenet) load balancing works at a higher level than point to point links, and has different requirements
            
-
            16:28 <+fox> <inkeystring> yeah it's the interaction with routing that's tricky
            
-
            16:29 < jrandom> aye, though i2p's got it easy (we don't need to find specific peers with the data in question, just anyone with capacity to participate in our tunnels)
            
-
            16:30 <+fox> <inkeystring> so there's no efficiency loss if you avoid an overloaded peer...
            
-
            16:30 <+fox> <inkeystring> whereas in freenet, routing around an overloaded peer could increase the path length
            
-
            16:30 <+fox> <inkeystring> anyway sorry this is OT
            
-
            16:31 < jrandom> np, though explaining why the changes in 0.6.1.17 affect our congestion collapse was relevent :)
            
-
            16:31 < jrandom> ok, anyone else have anything for 1) Net status?
            
-
            16:32 <+Complication> Well, as actually mentioned before, while running pure .17, I observed a noticable periodism in bandwidth and active peers
            
-
            16:32 <+Complication> And a few other people seem to experience it too, though I've got no clue about how common it is
            
-
            16:33 <+Complication> I've been wondering about its primary causes, mostly from the perspective of tunnel throttling, but no solution yet
            
-
            16:33 <+Complication> I managed to get my own graphs to look flatter, but only at the cost of some overall deterioration
            
-
            16:33 <+Complication> Tried modifications like:
            
-
            16:34 <+Complication> > _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1));
            
-
            16:34 <+Complication> (this was to avoid it totally refraining from build attempts for its own tunnels)
            
-
            16:35 < jrandom> ah right
            
-
            16:35 <+Complication> (oh, and naturally the loglevel is wacky, since I changed those for testing)
            
-
            16:35 < jrandom> we've got some code in there that tries to skew the periodicity a bit, but it isn't working quite right (obviously)
            
-
            16:36  * perv just shot his system :(
            
-
            16:36 <+Complication> But I tried some things like that, and tried reducing the growth factor for tunnel counts
            
-
            16:36 < perv> is there an undelete for reiser4?
            
-
            16:36 < jrandom> basically, if we just act as if tunnels expire (randomly) earlier than they actually do, it should help
            
-
            16:36 <+Complication> Currently reading the big "countHowManyToBuild" function in TunnelPool.java :D
            
-
            16:36 <+Complication> But I've not read it through yet
            
-
            16:37 < jrandom> (though it'd obviously increase the tunnel build frequency, which prior to 0.6.1.17, wouldn't have been reasonable)
            
-
            16:37 <+Complication> perv: there is something
            
-
            16:37 < jrandom> hmm, putting a randomization in there would be tough Complication, as we call that function quite frequently
            
-
            16:38  * perv considers salvaging and switching to gentoo
            
-
            16:38 < jrandom> what i'd recommend would be to look at randomizing the expiration time of successfully built tunnels
            
-
            16:38 <+Complication> perv: you're better off with reiser than ext3, certainly
            
-
            16:38 <+Complication> perv: but I don't know it by heart
            
-
            16:38 <+Complication> jrandom: true, sometimes it could overbuild this way
            
-
            16:38 < jrandom> (so that the existing countHowManyToBuild thinks it needs them before it actually does)
            
-
            16:38 <+Complication> (and sometimes it inevitably overbuilds, when tunnels break and it gets hasty)
            
-
            16:40 <+Complication> Hmm, a possibility I've not considered...
            
-
            16:41 <+Complication> Either way, playing with it too, but no useful observations yet
            
-
            16:42 < jrandom> cool, i've got some tweaks i've been playing with on that, perhaps we can get those together for the next build to see how it works on the reasonably-viable net ;)
            
-
            16:43 < spinky> Is there a stat where you can see the amount of overhead the i2p network adds to the application data?
            
-
            16:43 < jrandom> "overhead" is such a loaded term... ;)
            
-
            16:43 < jrandom> we call it the cost of anonymity ;)
            
-
            16:43 < spinky> hehe
            
-
            16:45 < jrandom> (aka not really.  application layer payload on a perfect net w/ 0 congestion & 1+1hops gets something like 70-80% efficiency for the endpoints)
            
-
            16:45 < jrandom> ((last i measured))
            
-
            16:45 < jrandom> but thats really lab conditions
            
-
            16:45 < jrandom> live net is much more complicated
            
-
            16:47 < spinky> Right, I meant just the amount of extra data used for setting up tunnels, keys, padding etc 
            
-
            16:47 < spinky> ...compared to the application data transferred
            
-
            16:47 < jrandom> depends on the message framing, congestion, tunnel build success rates, etc
            
-
            16:48 < jrandom> a 2 hop tunnel can be built by the network bearing 20KB
            
-
            16:48 <+Complication> I've wanted to test that sometimes, primarily with the goal of estimating the "wastefulness" of mass transfer applications like BitTorrent and I2Phex
            
-
            16:48 <+Complication> But I never got around to doing a clean measurement between my two nodes
            
-
            16:48 <+Complication> Some day, I'll get back to that, though
            
-
            16:49 < jrandom> Complication: its pretty tough with chatty apps, much simpler to measure wget :)
            
-
            16:49 <+Complication> How very true
            
-
            16:50 <+Complication> In what I managed to try, no resemblance of precision was involved
            
-
            16:54 < jrandom> ok, if there's nothing else on 1), lets slide on over to 2) I2Phex
            
-
            16:55 < jrandom> Complication: whatcha upta?  :)
            
-
            16:55 <+Complication> Well, yesterday's commit was a fix to certain problems which some people experienced with my silly first-run detector
            
-
            16:56 <+Complication> The first-run detector is now less silly, and bar reported that it seemed to start behaving normally
            
-
            16:56 <+Complication> However, since I2Phex seems runnable already in current network conditions,
            
-
            16:56 <+Complication> I'll try finding the rehash bug too.
            
-
            16:57 <+Complication> If I only can
            
-
            16:57 < jrandom> cool, i know that one has been haunting you for months now 
            
-
            16:57 <+Complication> What is interesting that mainline Phex may also have it, and locating + reading their observations is something I'll try doing too
            
-
            16:58 < jrandom> but nice to hear the startup fix is in there
            
-
            16:58 < jrandom> ah word
            
-
            16:58 <+Complication> =is that
            
-
            16:58 <+Complication> I can't confirm currently if mainline Phex has it or not, though - never seen it personally there
            
-
            16:59 < jrandom> (intermittent bugs)--
            
-
            16:59 <+Complication> It's difficult to cause in controlled fashion, and thus difficult to find
            
-
            17:00 <+Complication> And on my side, that's about all currently
            
-
            17:00 <+Complication> Later on, I was wondering if it would be worthwhile to limit the number of parallel peer contacting attempts I2Phex fires at a time
            
-
            17:01 < jrandom> aye, likely
            
-
            17:01 <+Complication> Since they'd create a whole bunch of NetDB lookups in a short time, and that could be potentially not-so-nice from an I2P router's perspective
            
-
            17:02 < jrandom> and new destination contacts require elG instead of aes
            
-
            17:02 <+Complication> But I've not read or written any actual code towards that goal yet
            
-
            17:04 < jrandom> k np.  perhaps the mythical i2phex/phex merge'll bundle a solution :)
            
-
            17:04 <+Complication> And on my part, that's about all the news from the I2Phex front...
            
-
            17:04 < jrandom> cool, thanks for the update and the effort looking into things!
            
-
            17:05 < jrandom> ok, lets jump on over to 3) ???
            
-
            17:05 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            17:05 < lsmith> hello! i just want to commend the devs on the fantastic improvements with the latest release, my total bw reads 0.9/1.4 KBps and i remain connected to irc... it's...insanely cool :)
            
-
            17:05 <+Complication> :D
            
-
            17:06 < jrandom> thanks for your patience along the way - supporting low bw users is critical
            
-
            17:06 <@cervantes> lsmith: that's really good to
            
-
            17:06 <@cervantes> * Connection Reset
            
-
            17:06 < jrandom> heh
            
-
            17:07 < lsmith> :)
            
-
            17:09 < jrandom> oh, one other thing of note is that zzz is back, and with 'im comes stats.i2p :)
            
-
            17:09 < jrandom> [wewt]
            
-
            17:11 <+Complication> A quite useful source of comparison data :)
            
-
            17:11 < jrandom> mos' def'
            
-
            17:11 < jrandom> ok, anyone have anything else for the meeting?
            
-
            17:13 < jrandom> if not...
            
-
            17:13 < jdot> i have a post-baf question or two
            
-
            17:13 < jrandom> heh ok, then lets get the baffer rollin' :)
            
-
            17:13  * jrandom winds up...
            
-
            17:13  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting178.html b/www.i2p2/pages/meeting178.html
deleted file mode 100644
index fa0b0db4..00000000
--- a/www.i2p2/pages/meeting178.html
+++ /dev/null
@@ -1,41 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 178{% endblock %}
-{% block content %}
            I2P dev meeting, May 2, 2006
            
-
            
-
            16:09 < jrandom> 0) hi
            
-
            16:09 < jrandom> 1) Net status
            
-
            16:09 < jrandom> 2) Syndie status
            
-
            16:09 < jrandom> 3) ???
            
-
            16:09 < jrandom> 0) hi
            
-
            16:09  * jrandom waves
            
-
            16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001285.html
            
-
            16:11 < jrandom> ok, while y'all read through that exciting mail, lets jump on in to 1) Net status
            
-
            16:13 < jrandom> so far, it seems the whole congestion collapse issue is fixed, yand tunnel creation rates are doing pretty well.  still, there are issues left to be sorted out
            
-
            16:14 < jrandom> the previously discussed cyclic behavior (often running on 10-12 minute intervals) is still in place,causing rejections inversely.  there's a new fix to the code as of -1 that should get rid of that though
            
-
            16:15 < jrandom> (namely, randomize the tunnel expirations /correctly/, unlike the broken randomization before)
            
-
            16:16 < jrandom> that, plus the improved ssu and tunnel test scheduling should help, but to what dgree, i'm not entirely sure yet
            
-
            16:17 < jrandom> ok, thats about all i have on that at the moment.  anyone have any questions/comments/concerns on 1) Net status?
            
-
            16:18 < green> humm, max bw limits are never reached and this is really far from previous
            
-
            16:18 < green> like in 1é-7
            
-
            16:18 < green> s/1é-7/.12-7
            
-
            16:18 < jrandom> how is your bw share percentage set?  thats now a very powerful control
            
-
            16:19 < green> 80%
            
-
            16:19 < green> but only about 40% of total bw is used
            
-
            16:20 < green> this is just a "do nothing router" :P
            
-
            16:20 < jrandom> hmm, how often does your bw spike up to 80%, and do you often reject tunnel requests (http://localhost:7657/oldstats.jsp#tunnel.reject.30 and tunnel.reject.*)
            
-
            16:21 < jrandom> the periodicity seen in tunnel requests often causes people to detect overload when it isn't really there
            
-
            16:21 < jrandom> (because routers have excess capacity at other times, just not when they're being spiked)
            
-
            16:22 < green> tunnel.reject.30 is very flat like 1,00 over 14 025,00 events
            
-
            16:22 < jrandom> oh, sorry, its the event count theselves for that stat thats key - you've rejected more than 14,000 tunnel requests due to bandwidth overload
            
-
            16:23 < jrandom> (the "value" for that stat is how many tunnels were rejected at the event, and thats always 1, since an event is caused by a message)
            
-
            16:27 < jrandom> ok, if there's nothing else on 1) Net status, lets slide on over to 2) Syndie status
            
-
            16:27 < jrandom> I don't have much more to add to whats in the email regarding syndie, just wanted to give an update
            
-
            16:28 < jrandom> ok, as such, unless there's something someone wants to bring up wrt syndie, lets jump on to ol' faithful, 3) ???
            
-
            16:28 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            16:31  * tethra would like to say "thanks" (again) for .17, as it has been muchos improvement
            
-
            16:33 < jrandom> glad to help, and there's more stuff on the way
            
-
            16:33 < jrandom> ok, but if there's nothing else for toay's meeting...
            
-
            16:33  * jrandom winds up
            
-
            16:33  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting179.html b/www.i2p2/pages/meeting179.html
deleted file mode 100644
index 7f06d45b..00000000
--- a/www.i2p2/pages/meeting179.html
+++ /dev/null
@@ -1,67 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 179{% endblock %}
-{% block content %}
            I2P dev meeting, May 9, 2006
            
-
            
-
            16:31 < jrandom> 0) hi
            
-
            16:31 < jrandom> 1) Net status and 0.6.1.18
            
-
            16:31 < jrandom> 2) baz
            
-
            16:31 < jrandom> 3) ???
            
-
            16:31 < jrandom> 0) hi
            
-
            16:31  * jrandom waves
            
-
            16:32 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001288.html
            
-
            16:32 < jrandom> while y'all read through that, lets jump on in to 1) Net status and 0.6.1.18
            
-
            16:33 < jrandom> the past week has been pretty bumpy on irc & the net in general
            
-
            16:33 <+Complication> Watching the graphs, but haven't noticed a perceivable change yet
            
-
            16:33 <+Complication> Only the beginning too, of course
            
-
            16:34 < jrandom> aye, its only been a few hours, with under 20% of the net upgraded
            
-
            16:35 < jrandom> there are still a few big guns left to deploy on the net, but I'd like things to stabilize first before pushing out major changes
            
-
            16:35 <+Complication> Indeed, it helps to see (as much as seeing is possible) what changes what, and in which direction
            
-
            16:36 <+Complication> If one deploys everything at once, figuring out what worked may be very tough
            
-
            16:38 < tmp> *sigh* 
            
-
            16:38  * tmp dreams of IRC stability.
            
-
            16:39 < jrandom> aye, on all fronts ;)
            
-
            16:39 <+fox> <roderick_spod1> Roderick dreams of big tits.
            
-
            16:39 < jrandom> (this is why we can filter the meeting logs... ;)
            
-
            16:40 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.18?
            
-
            16:41 < jrandom> if not, lets hop on over to 2) 
            
-
            16:42 < jrandom> not much more to add here, just giving a status update on some w32/w64 support
            
-
            16:43 < jrandom> as mentioned in the mail, gcj doesn't really seem viable on mingw atm, though we might be able to pull some tricks
            
-
            16:44 < jrandom> there is an older 3.4.4/3.4.5 gcj that works on mingw, but the classpath suport in there is pretty old.
            
-
            16:45 < jrandom> (and even after stripping a bunch out of hsqldb, there are still some dependencies that 3.4.5 doesn't meet.  but maybe we can hack those out too... if necessary)
            
-
            16:47 < jrandom> ok, if there's nothing else, lets move on over to 3) ???
            
-
            16:47 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            16:48 < cervantes> just to say "nice one bar" for his cool donation 
            
-
            16:48 <+Complication> Well, there was a question in the forum about uptimes presented in NetDB...
            
-
            16:48  * Complication seconds that
            
-
            16:49 <+Complication> 'bout the uptimes, if you recall, I fuzzified them slightly in March...
            
-
            16:49 < cervantes> must have missed that amongst the odci.gov rants
            
-
            16:50 < tmp> What on earth are you doing on that side roderick_spod?
            
-
            16:50 < jrandom> aye Complication 
            
-
            16:50 <+Complication> Well, since the question was raised, I wondered if they could be fuzzified further, or would it hurt ability to debug?
            
-
            16:52 < jrandom> i'm not sure of the point - with careful analysis, all of the stat data can reveal a bunch of information
            
-
            16:52 < arse> do you guys think the network periodicity is gonna subside
            
-
            16:52 < jrandom> when its time, we will just turn off the stat publhshing whatsoever
            
-
            16:52 <+Complication> We haven't recently had any router-restarting ones, but that's only recently...
            
-
            16:52 < jrandom> arse: yes
            
-
            16:52 <+Complication> (and partly because the watchdog lacks teeth)
            
-
            16:54 <+Complication> True, it's pretty inevitable that during this phase, some info must be out there
            
-
            16:55 < jrandom> also, the assumption they've made isn't correct, publishedTimeAgo is how long ago the router /received/ the netDb entry, not when it was signed
            
-
            16:55 < jrandom> erm, wait, no, thats not true
            
-
            16:56 < jrandom> never mind me.  yeah, it just adds a small variation
            
-
            16:56 <+Complication> Heh, I'm trying to post a reply, but get "no post mode specified" currently
            
-
            16:57 <+Complication> Yeah, there's delay involved, and besides, how often was this info published? Not very frequently, IIRC?
            
-
            16:57 <+Complication> Basically, if I offered to somewhat decrease the precision there, would you mind?
            
-
            16:58 < jrandom> a new signed entry is published eery 5-15 minutes, but that is only published to the netDb, not all peers
            
-
            16:58 < jrandom> peers only get the updated one when they either search for it or they reconnect
            
-
            16:59 < jrandom> but yeah, adding more variation is fine.  it'd affect stat.i2p's uptime plots, but as long as it keeps things reasonable, thats cool
            
-
            17:01 <+Complication> I'll try to keep it reasonable, then :)
            
-
            17:01 < jrandom> heh cool, thanks Complication 
            
-
            17:04 < jrandom> *cough* (and consistent ;) ok, anyone have anything else for the meeting?
            
-
            17:04 <+Complication> sidenote: neat, the "post mode" bug yielded to persistence, and I could post a reply too :)
            
-
            17:05 < jrandom> w3rd Complication 
            
-
            offtopic messages snipped
            
-
            17:08 < jrandom> ok, if there's nothing else...
            
-
            17:08  * jrandom winds up
            
-
            17:09  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting18.html b/www.i2p2/pages/meeting18.html
deleted file mode 100644
index cb818ad5..00000000
--- a/www.i2p2/pages/meeting18.html
+++ /dev/null
@@ -1,179 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 18{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 18
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Nov 05 23:14:03 2002
-
            23:14 < logger> test
-
            23:55 < nop> hineo
-
            23:55 < Neo> hinop
-
            23:57 < nop> hi hezekiah 
-
            --- Day changed Wed Nov 06 2002
-
            00:00 < Neo> 23:00:00.00 UTC
-
            00:00 < nop> ok
-
            00:00 < nop> welcome
-
            00:00 < nop> I kind of want to wait, looks like a relay died
-
            00:00 < nop> just another minute
-
            00:00 < nop> so that people can re-assimilate ;)
-
            00:01 < hezekiah> Yeah. I got bumped out about 30 seconds ago.
-
            00:01 < nop> right
-
            00:01 < nop> ok
-
            00:01 < nop> ok
-
            00:01 < nop> welcome to the n-th iip-dev meeting
-
            00:02 < hezekiah> 18th!
-
            00:02 < nop> I think it's like the 18th
-
            00:02 < nop> yes
-
            00:02 < nop> thnx
-
            00:02 < nop> on the agenda
-
            00:02 < nop> 1) welcome <-- we're doing this now
-
            00:02 < nop> 2) agenda list <-- we're doing this now
-
            00:02 < nop> 3) ;)
-
            00:03 < nop> 4) IIP logo
-
            00:03 < nop> 5) Dev report
-
            00:03 < nop> 6) RC3 (coming soon, we promise)
-
            00:03 < nop> 7) questions
-
            00:03 < nop> .
-
            00:03 < nop> ok we did the welcome and the agenda
-
            00:03 < nop> let's do the ;)
-
            00:03 < nop> ;)
-
            00:04 < nop> Ok IIP logo
-
            00:04 < nop> and slogan
-
            00:04 < co> Where can we see the logos that have been submitted?
-
            00:04 < nop> none have really been submitted
-
            00:04 < nop> except one
-
            00:04 < nop> and I submitted a slogan for InvisibleNet
-
            00:04 < nop> I'll tell you mine
-
            00:05 < nop> front part of shirt "You can't attack what you can't see..."
-
            00:05 < nop> then back would say
-
            00:05 < nop> InvisibleNet 
-
            00:05 < nop> then there's this other one, I'll mail to iip-dev 
-
            00:05 < nop> but no one else seems to care
-
            00:05 < nop> so... :(
-
            00:06 < nop> then again
-
            00:06 < nop> no one seems to want to buy shirts for IIP anyway
-
            00:06 < nop> so... what can ya do
-
            00:06 < nop> yes we're working on getting black shirts
-
            00:06 < nop> next on the agenda
-
            00:06 < nop> Dev report
-
            00:07 < nop> same ol' same ol' dev is working on the core control
-
            00:08 < nop> userx will give a brief summary
-
            00:08 < hezekiah> *applause*
-
            00:09 < UserX> core control will provide a system for being able to support multiple cores in iip. each core is esssentially network protocol
-
            00:10 < UserX> .
-
            00:10 < nop> ok
-
            00:10 < nop> thank you UserX
-
            00:10 < nop> man of many words
-
            00:10 < nop> ;)
-
            00:10 < nop> or woman
-
            00:10 < nop> never know
-
            00:10 < nop> anyway
-
            00:10 < nop> RC3 
-
            00:11 < nop> it's on it's way out the door, I believe there is an openbsd compatibility that was reported and from what I know, it's been patched and cvs'd
-
            00:11 < nop> (for some reason, I haven't got a listserv about it)
-
            00:11 < nop> but we're hoping that this weekend would be a good time to do an RC3 upgrade
-
            00:11 < nop> and it's not going to conflict with rc2 in any way 
-
            00:12 < nop> just mostly bug fixes
-
            00:12 < nop> Questions
-
            00:12 < nop> anyone?
-
            00:12 < codeshark> so everything is in cvs now?
-
            00:12 < dj28> yea
-
            00:12 < dj28> i have a stupid one
-
            00:12 < dj28> when will the IIP core server migrate away from the irc protocol?
-
            00:12 < nop> codeshark - I believe so, please check with UserX to make sure he's comfortable with it
-
            00:13 < nop> this is what the core control dev work puts us in a position to do
-
            00:13 < dj28> and when will it become completely distributed?
-
            00:13 < dj28> oh ok
-
            00:13 < nop> so then we'll be able to build upon that
-
            00:13 < UserX> codeshark: it will be once my server is talking to the internet again
-
            00:13 < nop> and we hope to have 1.2 a fully distributed version
-
            00:13 < dj28> ok. cool
-
            00:13 < nop> at least at communication level
-
            00:13 < nop> the routing might still be run through inform
-
            00:14 < nop> but the communication should be decentralized
-
            00:14 < nop> similar to how freenet 0.3 was
-
            00:14 < dj28> yea
-
            00:14 < nop> any other questions?
-
            00:15 < co> So a core is a package of encryption algorithms that allow network communication?
-
            00:15 < co> Explain that concept again, please.
-
            00:15 < Mak> wow ...i jumped here ...sorry ...
-
            00:16 < nop> well
-
            00:16 < nop> a core is a network protocol
-
            00:16 < nop> this puts us in a modular position
-
            00:16 < nop> to possibly support many routing architectures
-
            00:16 < Neo> oooh nice...
-
            00:17 < nop> this could position us to support many protocols
-
            00:18 < nop> the core control is similar to an API for cores
-
            00:19 < nop> any more questions?
-
            00:19 < co> Thank you.
-
            00:19 < nop> np
-
            00:21 < nop> oh
-
            00:21 < nop> one more thing
-
            00:22 < nop> Many thanks to Phiberoptika for her fine translation of the El Pais newspaper article done on IIP
-
            00:22 < nop> it appears in spanish and with english translation (done by Phiberoptika) on the iip site www.invisiblenet.net/iip
-
            00:22 < nop> it's a good article
-
            00:22 < hezekiah> Cool! I'll have to check that out! Thanks, Phiberoptika! :)
-
            00:22 < al-jabr> I have a question...
-
            00:22 < nop> yes sir
-
            00:22 < al-jabr> Two questions
-
            00:22 < nop> sure
-
            00:22 < al-jabr> I had one problem
-
            00:23 < al-jabr> running IIP in linux, don't know if it's actually an IIP problem
-
            00:23 < al-jabr> after I killed isproxy
-
            00:23 < al-jabr> and tried to run again, it couldn't bind to the port
-
            00:23 < al-jabr> had this problem a couple times, had to change the port number
-
            00:23 < al-jabr> but when i logged of and on again (a few days later) the port was available
-
            00:24 < al-jabr> so I'm not sure that's directly an issue with isproxy
-
            00:24 < hezekiah> Is this reproducable, or just a random happening?
-
            00:24 < nop> right, if you wait like 1 minute with RC2 you can rebind 
-
            00:24 < UserX> was something connected to it when you killed it?
-
            00:24 < al-jabr> i'll try to reproduce it
-
            00:24 < al-jabr> but
-
            00:24 < al-jabr> no, nothing was connected to 6667
-
            00:25 < nop> oh that port
-
            00:25 < nop> hmm
-
            00:25 < al-jabr> and it happened like three or four times and i had to keep changing ports
-
            00:25 < al-jabr> yeah
-
            00:25 < al-jabr> not the other one
-
            00:25 < Phiberoptika> re:article: ;)!!!, no problem chicos..
-
            00:25 < al-jabr> i haven't reproduced it since then, but i haven't been trying
-
            00:25 < nop> hehe
-
            00:25 < al-jabr> since i rarely go restarted isproxy
-
            00:26 < al-jabr> i should probably try to.  also, i was experiencing a lot of problems with the network for the last few days
-
            00:26 < Povert> I have a question....
-
            00:26 < al-jabr> and i don't know if it's something local
-
            00:26 < UserX> odd. the only reason i know for that to happen is that if the connection is closed properly it will be left hanging and you have to wait for the OS to time it out
-
            00:26 < Povert> is de openbsd thing realy solved?
-
            00:26 < al-jabr> or if it's not really any worse than it's usually been
-
            00:27 < al-jabr> because, before the last couple days, i got kicked off, maybe a couple times a day at MOST, then all of the sudden i was getting kicked off every few minutes, and sometimes not getting on at all, and sometimes lagging
-
            00:27 < UserX> al-jabr: did you try using netstat to see if there were any lingering connections to port 6667
-
            00:27 < al-jabr> and changing node.refs didn't seem to help
-
            00:27 < al-jabr> no, i should have investigated that
-
            00:27 < al-jabr> silly me
-
            00:27 < al-jabr> i'll try it a bit more and i'll do that
-
            00:28 < al-jabr> i didn't think that there could be connections on the other end after the server is killed
-
            00:28 < nop> would netstat give a TIME_WAIT?
-
            00:29 < hezekiah> Also, sometimes a process of isproxy hangs (but that only has happened to me when I'm debugging buggy code.) You should be able to check to see if there are still a hanging process of isproxy by doing: ps -e | grep isproxy
-
            00:29 < al-jabr> i did that
-
            00:29 < al-jabr> no isproxies were running
-
            00:29 < hezekiah> Good. :)
-
            00:30 < al-jabr> no, bad.
-
            00:30 < al-jabr> but anyway, i'll investigate that some more, probably not a big issue
-
            00:32 < Povert> nop
-
            00:32 < Povert> is openbsd kompilation ready solved?
-
            00:32 < Neo> diff -r1.2 sock.h
-
            00:32 < Neo> 45c45
-
            00:32 < Neo> < #elif defined(__FreeBSD__) || defined(__MACH__)
-
            00:32 < Neo> ---
-
            00:32 < Neo> > #elif defined(__FreeBSD__) || defined(__MACH__) || defined(__OpenBSD__)
-
            00:33 < Povert> in codetree I meen
-
            00:34 < nop> it's about to be committed
-
            00:34 < Povert> ok
-
            00:34 < Povert> dank
-
            00:34 < nop> yep
-
            00:37 < nop> any more questions?
-
            00:42 < nop> thanks for attending
-
            00:42 < nop> .
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting180.html b/www.i2p2/pages/meeting180.html
deleted file mode 100644
index 82f7842d..00000000
--- a/www.i2p2/pages/meeting180.html
+++ /dev/null
@@ -1,83 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 180{% endblock %}
-{% block content %}
            I2P dev meeting, May 16, 2006
            
-
            
-
            < cervantes>  moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html
-
            < cervantes>  0) hi
-
            < cervantes>  1) jrandom's not here
-
            < cervantes>  2) ???
-
            < cervantes>  0) hi
-
            < cervantes>  hi
-
            < cervantes>  moving on to 1)
-
            < cervantes>  jrandom isn't here today, but he'll give us a status update tomorrow
-
            < cervantes>  2) ???
-
            < cervantes>  does anyone have anything else to add to the meeting?
-
            < bar>  i have a question
-
            < cervantes>  in that case...
-
            * cervantes winds up
-
            * cervantes stops winding
-
            < Complication>  Aha, a question...
-
            < bar>  the PRNG fix in cvs, will that improve the general performace or is it related to something else?
-
            < cervantes>  it's uncertain what consequences it might have in general
-
            < Complication>  I'm personally not aware of its total impact, but it does involve at least two behaviours I'm aware of:
-
            < cervantes>  but it specifically fixes a symptom with i2ptunnel
-
            * cervantes lets complication decomplicate 
-
            < Complication>  tunnel length randomization and IRC server choice (more generically, random selection from a list of I2PTunnel destinations)
-
            < Complication>  Tunnel length randomization probably has a significant effect on overall network health, since it allows clients who are permitted to compromise on tunnel length to actually do that
-
            < Complication>  So they won't be holding breath and building 2-hop tunnels, but also try some 1-hop tunnels
-
            < Complication>  (which on hard times, are much easier to get)
-
            < cervantes>  also irc connectivity might improve once it's  rolled out. Basically freshcoffee was never getting any client connections because it was second in the list - so with the next release the load should be evenly distributed between both servers
-
            < bar>  so the bug made people always go for the longer tunnel lengths if available?
-
            < Complication>  If I understood right, every randomization with smallish integers (e.g. pick 0 or 1) was affected
-
            < Complication>  I *think* randomizations with bigger integers (e.g. pick an integer between 0 and 100) were less affected
-
            < Complication>  if you're interested, you should probably ask jranom for details when he's back
-
            < Complication>  I may get the details wrong.
-
            < bar>  i see, thanks. good catch
-
            < Complication>  well, cervantes came here and started complaining about not getting any overload ;P
-
            < cervantes>  that was my understanding of it too
-
            < cervantes>  see...you don't get anything in life if you don't grumble :)
-
            < cervantes>  do any folk have other questions or topics for the meeting?
-
            < fox>  < duck>  yes
-
            < Pi>  a question about general net health : i see more and more clients get left behind i2p-version wise (2 still using 0.6.1.11 and so on). won't these clients make monitoring effects of changes to the core more and more harder? (as "fewer" seem to want to update)
-
            < fox>  * duck repeats above
-
            * w423412323 suggests a topic change along that line. ;)
-
            < fox>  < duck>  I was wondering, I have seen some funky tuning commits on the cvs mailinglist. are those more experiments? are they based on observations? are they premature?
-
            < Complication>  Pi: as long as they aren't present in big numbers, they shouldn't make a big difference
-
            < Pi>  70 of 300 clients using non-0.6.1.18-version according to my netdb now 
-
            < Complication>  It's a game of numbers and capacity - if either most routers, or additionally the highest-capacity routers are reasonably updated, some people forgetting that they installed I2P shouldn't matter :)
-
            < cervantes>  Pi: if the older routers misbehave then the network _should_ adapt and reduce traffice being router via them
-
            < cervantes>  *being routed
-
            < cervantes>  Complication: did you see duck's question? 
-
            < Pi>  and a question about a stat on the i2p-console which appeared some time ago : what does handle backlog mean?
-
            < Complication>  duck: would you mean the tunnel throttle adjustments? They're tuning in the sense that they won't bring much inherently new, but they should be fairly well-tested now (e.g. they probably won't byte)
-
            < Complication>  But they might byte a little, if you run an exotic setup which is completely outside the parameters I could think of
-
            < fox>  < duck>  Complication: I was wondering if '2' instead of '3' thingies really mattered that much
-
            < fox>  < duck>  but it seemed that the random problem might have been a big baddy
-
            < fox>  < duck>  (though the relative impact of that towards network unhealth depends on when it was introduced)
-
            < cervantes>  Pi: handle backlog is the number of pending inbound tunnel join requests (quoted from the changelog)
-
            < Complication>  If you mean the random nextInteger() problem, and effect on tunnel length randomization, I feel it would have significant effect
-
            < Complication>  The cost difference of building a 1-hop and 2-hop tunnel is pretty significant
-
            < Pi>  thx, cervantes :)
-
            < fox>  < duck>  when was it introduced?
-
            < Complication>  duck: I think it was introduced with some switchovers to the Fortuna generator, or some modification therein
-
            < fox>  < duck>  ok; thanks a lot for your input
-
            < Complication>  Let me check the cvsweb for more detail...
-
            < cervantes>  Pi: I believe there's code in place now that drops inbound tunnel requests if the queue fills up (to help reduce cpu load)
-
            < Complication>  Pi: yes, that should be the visible indicator of another parameter used for deciding "do we have enough capacity to participate in another tunnel?"
-
            < cervantes>  duck: I certainly experience a large change in router behaviour since the fix was introduced. - not all good I have to say :)
-
            < Complication>  big handle backlog == congestion, no point in trying to join other people's tunnels
-
            < cervantes>  had a load average of 14 and 12000 participating tunnels the other day
-
            < Complication>  Handle backlog seems important particularly on high-capacity routers (referring to what cervantes saw)
-
            < Complication>  Low capacity routers generally throttle their tunnel acceptance for bandwidth reasons
-
            < Complication>  (or tunnel test time reasons, to be correct)
-
            < Complication>  (or at least, to try that)
-
            < cervantes>  wow we've managed half an hour....
-
            < Complication>  Indeed :D
-
            < cervantes>  anyone want to bring anything else to the table?
-
            < cervantes>  in that case...
-
            * cervantes winds up
-
            * cervantes *baffs* the meeting closed
-
            < fox>  < duck>  thx for taking care of the meeting
-
            < cervantes>  heh I was expecting to baf it closed before anything said anything....but bar ruined that plan :)
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting181.html b/www.i2p2/pages/meeting181.html
deleted file mode 100644
index 4686983e..00000000
--- a/www.i2p2/pages/meeting181.html
+++ /dev/null
@@ -1,58 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 181{% endblock %}
-{% block content %}
            I2P dev meeting, May 30, 2006
            
-
            
-
            16:00 < jrandom> 0) hi
            
-
            16:00 < jrandom> 1) Net status
            
-
            16:00 < jrandom> 2) Peer filtering
            
-
            16:00 < jrandom> 3) Syndie status
            
-
            16:00 < jrandom> 4) ???
            
-
            16:00 < jrandom> 0) hi
            
-
            16:00  * jrandom waves
            
-
            16:01 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html
            
-
            16:01 < jrandom> (up an hour early, even [or a few weeks late, if you want to pick on me ;])
            
-
            16:02 < jrandom> ok, lets jump on in to 1) Net status
            
-
            16:02 < jrandom> things arent in the shape they should be in.  they're better than they were during the congestion collapse, but it should be better than it is now
            
-
            16:03 < jrandom> i don't have much more to add on that though, unless anyone has any questions/concerns on 1)?
            
-
            16:03 <@frosk> i get days of irc connection with .19, so no complaints here
            
-
            16:04 < jrandom> nice
            
-
            16:04 < jrandom> yeah, its good for some, just not good enough or consistent enough.  stats in the db aren't looking that great either
            
-
            16:06 < jrandom> ok, anyone have anything else on 1) Net status, or shall we move on over to 2)Peer filtering?
            
-
            16:07 < jrandom> [insert moving sounds here]
            
-
            16:09 < jrandom> as mentioned in the mail, the gist of things is to give our peer selection a bit of a boost.  at first, it'll be a bit dangerous, allowing some active partitioning attacks, but if it works as I hope, we can avoid those
            
-
            16:10 < jrandom> (but avoiding it requires essentially killing all router identities, which would essentially serve as a network reset, so i'd like to avoid that unless its worthwhile)
            
-
            16:11 < bar> reset them once or repeatedly?
            
-
            16:11 < bar> s/reset/killing
            
-
            16:11 < jrandom> at least once, but also on all subsequent drastic config changes
            
-
            16:12 < jrandom> (aka putting some criteria into the router identity's certificate, which in turn means changing the ident hash, so they can't pretend to push one setting to some people and others to others)
            
-
            16:13 < bar> gotcha
            
-
            16:14 < jrandom> ok, i dont think i have anything else on that topic atm, unless anyone has any questions/comments/concerns?
            
-
            16:15 < jrandom> (hopefully there'll be a build out in the next day or two, release after it stabilizes)
            
-
            16:17 < jrandom> ok, hitting 3) briefly..
            
-
            16:18 < jrandom> syndie is coming along, and although the amd64/amd32/x86/swt/gcj battle hasn't always been pretty, we'll have a build ready in june
            
-
            16:19 < jrandom> (but still don't talk to me about mingw/gcj ;)
            
-
            16:19 < jrandom> i don't have much more to add on there at the moment though, unless anyone has any questions/concerns re: the syndie revamp?
            
-
            16:21 <@cervantes> how's mingw/gcj support coming along?
            
-
            16:21 <@cervantes> *duck*
            
-
            16:22 <@cervantes> do we get some screenies before the june release? :)
            
-
            16:23 < jrandom> i'm sure i'll try to rope some eager volunteers into pre-release testing ;)
            
-
            16:23 < tethrar> count me in ;)
            
-
            16:23 < jrandom> w3wt
            
-
            16:24 < jrandom> ok, lets swing over to the bullet point i know y'all have been waiting for: 4) ???
            
-
            16:24 < jrandom> wazaaaap?
            
-
            16:24 < green> Is there any plan to have to have a "real" working I2P router with Via C7 ? jbigi give only 30% better than full java
            
-
            16:25 < jrandom> is 30% still too cpu intensive?  what makes it not "real"?
            
-
            16:25 < jrandom> but no, i do not have the math or c7 asm skill to make a better libGMP for C7.
            
-
            16:25 < green> sure too cpu intensive with 100% cpu load :P
            
-
            16:26 < jrandom> 100% cpu load suggests that the problem isn't jbigi, but the fact that jbigi needs to be used too much
            
-
            16:26 < jrandom> and for that, yes, there is lots we've got on the way.
            
-
            16:26 < jrandom> (e.g. reducing the connection reestablishments, improving tunnel build success rates, etc)
            
-
            16:27 < jrandom> ((and not getting as many tunnel requests if the router is not capable of handling them))
            
-
            16:29 < green> humm, this is with a dedicated box with 100Mb/s so It should be capable
            
-
            16:30 < jrandom> no, bandwidth is not the only resource constrained here, cpu obviously is ;)
            
-
            16:33 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:36 < jrandom> *cough*
            
-
            16:37  * jrandom winds up
            
-
            16:37  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting182.html b/www.i2p2/pages/meeting182.html
deleted file mode 100644
index 40a2589e..00000000
--- a/www.i2p2/pages/meeting182.html
+++ /dev/null
@@ -1,63 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 182{% endblock %}
-{% block content %}
            I2P dev meeting, June 13, 2006
            
-
            
-
            16:05 < jrandom> 0) hi
            
-
            16:05 < jrandom> 1) Net status
            
-
            16:05 < jrandom> 2) 0.6.1.21
            
-
            16:05 < jrandom> 3) ???
            
-
            16:05 < jrandom> 0) hi
            
-
            16:05  * jrandom waves
            
-
            16:05 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-June/001293.html
            
-
            16:06 < jrandom> while y'all dig through that, lets jump on over to 1) Net status
            
-
            16:07 < jrandom> the network's behavior isn't that great at the moment - it works pretty well for some people, but for others, it doesn't work at all
            
-
            16:07 < modulus> .20 works pretty well for me, where .19 didn't work at all, but i guess that's just anecdote.
            
-
            16:08 < jrandom> you say anecdote, i say data point :)
            
-
            16:08 < jrandom> there'll be a new release tomorrow though which should improve things a bit
            
-
            16:09 < jrandom> oh, i suppose thats 2)... anyone have anything else on 1) net status they'd like to discuss first?
            
-
            16:10 < jrandom> if not, lets jump to 2) 0.6.1.21
            
-
            16:11 < jrandom> 0.6.1.20-7 is cvs head, and will become 0.6.1.21 sometime tomorrow
            
-
            16:12 < jrandom> it should improve the ability for fast peers to handle more tunnels, which in turn should improve everyone's success rates
            
-
            16:13  * jrandom currently gets ~30-60% success rates (excluding expirations) - hopefully the expirations will be cut further
            
-
            16:14 < jrandom> ok, I don't have much more to add on that front- the changes are listed in the history.txt, so keep an eye out tomorrow for the release
            
-
            16:14 < jrandom> (also, remember that it may take up to 12 hours to push the release out, so its probably best to either build -7 or wait until the actual announcement on the mailing list/website)
            
-
            16:15 < jrandom> ok, lets shimmy on over to 3) ???
            
-
            16:15 < jrandom> anyone have anything else they want to bring up?
            
-
            16:15 < user-land> are there recommendations for routers that can take the load from i2p ?
            
-
            16:15 < NickyB> yes
            
-
            16:15 < NickyB> about the ircproxy
            
-
            16:15 < user-land> and what holds up i2p 1.0 ? :-)
            
-
            16:16 < jrandom> user-land: to the first question, no (other than "patience")
            
-
            16:16 < jrandom> to the second question, see the first question
            
-
            16:16 < NickyB> first, sorry for my poor english. My ircProxy is set to be reachable on my lan, like all others proxy (eeproxy too) but my 6668 is reachable on the Net....
            
-
            16:17 < jrandom> NickyB: when you say on your lan, what is the *interface* it is bound to (on http://localhost:7657/i2ptunnel/index.jsp)
            
-
            16:18 < jrandom> NickyB: if the interface is "0.0.0.0", yes, it will accept connections from anywhere.  if its "127.0.0.1" it will only accept connections from the localhost.  if its "10.0.0.123" or "192.168.1.42", then it will accept connections from your LAN
            
-
            16:19 < NickyB> err, for my console, i did a change in client.config
            
-
            16:19 < NickyB> clientApp.0.args=7657 192.168.0.1 ./webapps/
            
-
            16:19 < NickyB> 192.168.0.1  is the adresse gived to all my proxy 
            
-
            16:19 < NickyB> Reachable by:
            
-
            16:20 < NickyB> LAN Hosts
            
-
            16:20 < NickyB> 192.168.0.1
            
-
            16:20 < NickyB> and my 4444 is not reachable on the net, but my 6668 yes
            
-
            16:20 < jrandom> NickyB: you need to stop and start that particular i2ptunnel proxy for the changes to take effect
            
-
            16:21 < jrandom> though, perhaps we can continue debugging after the meeting (as this is all logged ;)
            
-
            16:21 < NickyB> will try, thank you
            
-
            16:21 < jrandom> np, thanks for your patience
            
-
            16:21 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:21 < fedo> why the .21 will not be a *mandatory* release ? i ask that because we have a lot of .12 .13 etc. routeurs. This may not help for the network health ...
            
-
            16:23 < jrandom> the old routers don't hurt much, and there arent too many of them (something like 2-300 stay within 1 release of current)
            
-
            16:23 < user-land> my hardware router crashed under i2p load. that is why i asked for hardware recommendations.
            
-
            16:24 < jrandom> ah, sorry, misundertood your question user-land.  i've been able to get by with cheap linksys and belkins, though i dont know what switches they have at the current colo
            
-
            16:24 < user-land> thanks.
            
-
            16:25 < jrandom> fedo: the real key of ...21 is that 1) fast routers upgrade (and they're the most likely to anyway) and 2) that users be on ...19 or higher
            
-
            16:26 < fedo> ok Jr
            
-
            16:26 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:28 < user-land> thanks for your efforts :-)
            
-
            16:28  * ashter2 seconds user-land
            
-
            16:28 < user-land> and http://www.savetheinternet.com/
            
-
            16:29 < jrandom> (bah, never trust politics to defend us.  use technology)
            
-
            16:29 < jrandom> ok, if there's nothin' else...
            
-
            16:30  * jrandom winds up
            
-
            16:30  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting183.html b/www.i2p2/pages/meeting183.html
deleted file mode 100644
index 33288a3d..00000000
--- a/www.i2p2/pages/meeting183.html
+++ /dev/null
@@ -1,191 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 183{% endblock %}
-{% block content %}
            I2P dev meeting, August 1, 2006
            
-
            
-
            16:02 < jrandom> ok, might as well get this rolling
            
-
            16:03 < jrandom> hi, pre-meeting notes posted up at http://dev.i2p.net/pipermail/i2p/2006-August/001304.html
            
-
            16:03 < jrandom> rather than have me essentially reread that message to y'all here, lets just skip to our standard ??? section -
            
-
            16:04 < jrandom> anyone have anything they want to bring up and discuss?
            
-
            16:04 <@cervantes> eerm
            
-
            16:04  * cervantes scurries to read the post
            
-
            16:05 <+Complication> With regard to network status, all fine over here...
            
-
            16:05 <+Complication> But one question (actually relaying from forum) about the NTCP transport,
            
-
            16:06 <+Complication> namely, does it sound likely that activating it could cause someone CPU load issues (they were on XP)?
            
-
            16:06 <@cervantes> I have to say I've actually been seeing lower CPU usage since switching over :)
            
-
            16:07 < jrandom> well, you can't *deactivate* it (unless you've been reading the source code and know the magic incantation ;)
            
-
            16:07 <+Complication> The person who spoke of this problem (can't easily repeat it, and no big CPU use here) mentioned that their experience of high CPU usage seemed to correlate with NTCP
            
-
            16:07 < jrandom> so, i assume they mean not accepting inbound ntcp connections
            
-
            16:07 <+polecat> NTCP causes my router to instantly clock the CPU, and I repeated it twice before manually having to alter the config file to get a working router again.
            
-
            16:07 < jrandom> (while still using outbound ntcp connections)
            
-
            16:07 <+Complication> (over here it's only a tiny bit up from usual levels, and that's likely because of pumping *way* more data)
            
-
            16:08 <+Complication> ( http://forum.i2p/viewtopic.php?t=1815 )
            
-
            16:08 < jrandom> when you establish an ntcp connection, you do a heavyweight crypto calculation (or three)
            
-
            16:08 < jrandom> if you are accepting inbound ntcp connections, you may get lots of inbound attempts at once, since there are hundreds of i2p routers out there
            
-
            16:09 < jrandom> polecat: that wasn't ntcp's fault, it was the fault of a bad ntp server in the ntp pool
            
-
            16:09 <+polecat> Yes.  So I can't handle that myself, apparantly.
            
-
            16:09 < jrandom> (thanks to cervantes for tracking down that ntp server and getting the pool folks to !thwap 'em :)
            
-
            16:10 < jrandom> ((and Complication for making it so we avoid those crazy bastards in the future :))
            
-
            16:10 <@cervantes> heh I think their server watchdogs only work on weekdays ;-)
            
-
            16:10 <+Complication> Well, the current avoidance is pretty limited
            
-
            16:10 <@cervantes> http://www.pool.ntp.org/scores/216.52.237.153
            
-
            16:11 <+Complication> I hope to get something more paranoid coded eventually
            
-
            16:11 <+polecat> Oh, so enabling NTCP won't clock the CPU anymore?
            
-
            16:11 < jrandom> (it never did polecat, 'twas a coincidence ;)
            
-
            16:12 <+Complication> "clock" in which particular sense?
            
-
            16:12 < jrandom> (see cervantes' link)
            
-
            16:12  * polecat clocks Complication upside the head.
            
-
            16:12 <@cervantes> whatcha smoking polecat
            
-
            16:12 <+Complication> :P
            
-
            16:12 <+polecat> Er, I mean, stole all clock cycles.  :)
            
-
            16:13 <+Complication> If it jumped 30 seconds forward or backward, it could have lost many, many sessions, and resorted to all kinds of heavy, heavy crypto
            
-
            16:13 <+Complication> That could steal plenty of CPU cycles, I think
            
-
            16:13 <+Complication> Indeed, perhaps the person in the forum actually saw the same, and mis-correlated it? Have to ask...
            
-
            16:13 < jrandom> ah.. well, bursts of valid inbound ntcp connections will cause bursts of cpu, while outbound-only ntcp will only try to talk to so many new ntcp peers at a time
            
-
            16:14 < jrandom> there is nothing wrong with not enabling inbound ntcp.  
            
-
            16:15 <@cervantes> Complication: the server was corrected mid-monday, so it might be worth seeing if they've had issues since then
            
-
            16:15 < jrandom> ok, anyone else have something they want to discuss?
            
-
            16:16 <+Complication> cervantes: indeed, could be worth a try
            
-
            16:16 <@cervantes> I've had reports of some folk still losing leases periodically... is that a known problem?
            
-
            16:16 <+void> how much does the ntcp implementation differ from ssu?
            
-
            16:17 <+polecat> How do we tell if we lose leases?
            
-
            16:18 < jrandom> void: there's a slightly higher per-message andwidth overhead in ntcp (though perhaps offset by the OS's likely-more-efficient reliable transmission implementation)
            
-
            16:18 <+Complication> polecat: tunnels.jsp will show no tunnels for a particular tunnel pool (e.g. "shared clients")
            
-
            16:18 < jrandom> cervantes: aye, our tunnel build success rates still aren't where they need to be
            
-
            16:18 <+void> polecat: the router console says so
            
-
            16:18 <+Complication> And like void says, the left sidebar of the console will tell so
            
-
            16:19 <+polecat> I get those "No leases" messages a lot... that's what you mean, right?
            
-
            16:19 <@cervantes> yup
            
-
            16:20 <+polecat> That's usually what kills my IRC connection.  Thought it was normal!
            
-
            16:21  * jrandom cringes
            
-
            16:24 <+tethra> lol ;)
            
-
            16:25 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:25 <@cervantes> jrandom: have you made any progress on syndie lately or have you had your hands full with ntcp/bug fixing/ISP hunting/bicycling ?
            
-
            16:27 <+tethra> any news on feedspace, or should i just go to their eepsite?
            
-
            16:28 < jrandom> when the live net hit the shitter i pushed syndie to the side.  but with the net moving back on track again, syndie has been reclaiming my time, and I hope to have a small cli system out shortly (with focused guis coming after that, based on user feedback)
            
-
            16:28 < jrandom> (the implemented swt gui is in pretty good shape, but its probably best to start off with the cli to adjust expectations)
            
-
            16:29  * jrandom hasn't heard any news on feedspace
            
-
            16:29 <@cervantes> cool
            
-
            16:29 < jrandom> frosk: any word?  :)
            
-
            16:29 <+polecat> I'm glad you're working on syndie again.  The new one does sound pretty promising. Any thoughts on ACL for stuff such as deleting blogs from a node, or doing administrative account-independant tasks?
            
-
            16:30 <@cervantes> <jrandom> DELETE FROM messages WHERE postedOn < NOW()-14*24*60*60;
            
-
            16:31 < jrandom> local archives will likely remain essentially trusted (since if you can access the local archive db, you can change the file however you want)
            
-
            16:32 < jrandom> however, for shared blogs, yeah there's a whole set of crypto structures in place for authenticating and / or authorizing posts and changes
            
-
            16:33 < jrandom> (but there'll be a way for people to view 'unauthorized' posts as well, but they'll be very much off to the side)
            
-
            16:33 <+polecat> I'm sure once someone floods syndicates with thousands of giant blog posts, the technique to physically delete posts will be perfected.
            
-
            16:34 <+tethra> heheh
            
-
            16:35 < jrandom> physical deletion is trivial, its the question of what posts to accept in the first place ;)
            
-
            16:36 < jrandom> (i have no interest in making syndie into a movie distriution platform, etc)
            
-
            16:36 <+polecat> One cannot be sure of what one is accepting, until a sample has been accepted.  I envision something like allowing only a whitelist of blogs, and allowing new IDs on a trial basis before adding them, insta-deleting on spam betrayal.
            
-
            16:36 < jrandom> aye
            
-
            16:37 <+polecat> I'm more interested in its application for colluding streams of conversation together: we could make a BBS that had no central server, just a tag in common!
            
-
            16:37 < jrandom> (manually allowing new ids, manually kickbanning ids that flood, etc)
            
-
            16:37 < jrandom> there's even inherent support for that in the crypto polecat :)
            
-
            16:37 <+polecat> Possibly a moderator signing approved messages for the BBS, and people collecting those approval lists from the moderator's blog.
            
-
            16:38 <+polecat> Ooh excellent.
            
-
            16:38 <@frosk> jrandom: been working on gui stuff lately, but it's been hard to combine with starting a new job :(
            
-
            16:39  * cervantes contacts Human Resources to get frosk fired
            
-
            16:40 < jrandom> ah cool, hopefully once syndie is out there pushing kludged http syndication we'll tempt you on it again ;)
            
-
            16:40 <@frosk> at least my boss follows i2p development now :)
            
-
            16:40  * jrandom waves to frosk's boss
            
-
            16:40 <@frosk> oh yes, i'm still determined (damn it!) :)
            
-
            16:40 < jrandom> (gives frosk more time off, we need 'im!)
            
-
            16:41 <@cervantes> hopefully he won't read about how you've been posting classified company information onto your syndie blog
            
-
            16:41 < bar> gui is good, we like gui. you're forgiven.
            
-
            16:41 <+Complication> Hehe :)
            
-
            16:41 <@frosk> it's weird to walk into his office and catch him reading syndie :)
            
-
            16:41 < jrandom> hah awesome
            
-
            16:42 <+polecat> Congratulations frosk, even if you get fired in shame and infamy, at least you showed one more person how cool syndie can be.
            
-
            16:43 <@frosk> hehe yeah
            
-
            16:43 <+tethra> haha
            
-
            16:44 <@frosk> the gui (in swt) is/will be a testbed for all things feedspace, to kickstart it
            
-
            16:44 < jrandom> r0x0r
            
-
            16:45 <+void> jrandom: perhaps you should cross-post everything that goes onto the mailing lists to syndie as well?
            
-
            16:45 < jrandom> we should totally merge it in with the syndie swt gui (basic paradigm is a browser, though not displaying html pages in the tabs)
            
-
            16:46 <+polecat> That'd be nice.  I can't seem to get the mailing list anymore.
            
-
            16:46 < jrandom> void: it'd be pretty easy for someone to write up a small shell script to pipe procmail into the syndie CLI
            
-
            16:46 <@cervantes> are these fancy swt gui's tied into the applications? or are they tops for cli executables or use tcp etc etc 
            
-
            16:46 <@frosk> that makes sense
            
-
            16:46 < jrandom> (iirc there's a post in my blog a while back explaining how to use the syndie cli to insert posts)
            
-
            16:47 <+polecat> Currently one can make RSS feeds to feed into syndie, though it's kind of cludgy still.
            
-
            16:47 < jrandom> cervantes: jdbc in event handlers, inline with jni and msvc callouts, of course ;)
            
-
            16:47  * jrandom ducks
            
-
            16:48 <+polecat> Microsoft Visual Classes?
            
-
            16:49 <@cervantes> jrandom: so anything that can talk SQL can administer syndie then
            
-
            16:49 < jrandom> (from syndie's perspective, all of the functionality is basically implemented in lots of tiny cli apps which just update the jdbc database, and there's an swt ui to browse around the db)
            
-
            16:51 <+polecat> And since the database has two interfaces, JDBC, and SQL, a client communicating in either protocol can screw with syndie.
            
-
            16:51 < jrandom> cervantes: well, yes and no - there's a good portion of the database thats encrypted, so not all fields are readable
            
-
            16:51 <+void> will the current web interface still be there?
            
-
            16:51 < jrandom> (jdbc == sql)
            
-
            16:51 < jrandom> void: no
            
-
            16:51 <+polecat> I thought you said that JDBC wasn't a stupid human readable protocol?
            
-
            16:51 <+Complication> jdbc == java database interface, perhaps a bit similar to odbc
            
-
            16:51 < jrandom> ((jdbc ~= sql))
            
-
            16:51 <+Complication> Something you talk SQL over
            
-
            16:52 <+void> jrandom: what will happen to syndie.i2p/syndiemedia.i2p.net?
            
-
            16:52 <+polecat> Oh.  Well I never liked SQL anyway, for the record.
            
-
            16:52 <@cervantes> jrandom: so it's best to create a top for syndieTools (tm) than to try and leech the data yourself
            
-
            16:53 < jrandom> void: time will tell.  likely they'll 1) serve as syndie's website/eepsite, 2) serve as a public archive of posts to syndicate with, and eventually, when a web interface is written, 3) serve up a web interface
            
-
            16:53 <+polecat> Why not submit bytecode as database queries, instead of archaic COBOL statements?
            
-
            16:53 < jrandom> aye cervantes
            
-
            16:53 < jrandom> !lart polecat
            
-
            16:54 <+void> hehehe
            
-
            16:54 <+polecat> Ah, my secret weakness.
            
-
            16:54 <@cervantes> * you have 6 larts left in your inventory, there is a door to the north and an unconsious polecat on the floor
            
-
            16:54 < jrandom> cervantes: thats actually cli app #3 (extracting individual posts, which comes after app #2, listing individual posts (after #1, creating individual posts, and after #0, managing nyms)))
            
-
            16:54 < jrandom> lol
            
-
            16:54 <+tethra> haha
            
-
            16:55 <+Complication> feature proposal: instead of bytecode, why not submit live $agency agents as database queries? ;P
            
-
            16:56 <+Complication> Would be far easier to validate for safety :P
            
-
            16:56 <@cervantes> jrandom: gotcha
            
-
            16:56 <+tethra> do they act like carrier pigeons under the right climate, Complication? 
            
-
            16:56 <+Complication> tethra: only if you manage to push them through the TCP stack intact :P
            
-
            16:56 <+polecat> Yes, database queries over CPP!
            
-
            16:57 <+Complication> I imagine that getting wrinkled in TCP might corrupt them
            
-
            16:58 <+Complication> (sorry, should really keep jokes to #i2p-chat, but sometimes can't help)
            
-
            16:58  * cervantes senses a baff is soon approaching
            
-
            16:58 <+Complication> database queries as shellcode?
            
-
            16:59 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:59 <+polecat> http://www.blug.linux.no/rfc1149/ <- we could tunnel i2p over this, really.
            
-
            16:59  * Complication would rather stick with SQL
            
-
            17:00 <+void> jrandom: do other langauges than java have libraries for hsqldb databases?
            
-
            17:01 <+Complication> Oo would seem likely to, since they seem to use it
            
-
            17:01 <+void> looks like a "no" to me
            
-
            17:01 <+void> oh, hmm
            
-
            17:01 <@cervantes> openoffice uses it so I would guess so
            
-
            17:01 <+Complication> But I'm not sure what OpenOffice is written in
            
-
            17:01 < jrandom> not that i know of.  but someone could run syndie against another jdbc database (mysql, oracle, etc)
            
-
            17:01 < jrandom> oo uses java
            
-
            17:02 <+void> what exactly does openoffice use this database for?
            
-
            17:02 <+Complication> But seems to only partially use it
            
-
            17:02 < jrandom> void: for pdf generation and for their access-like database app
            
-
            17:02 < jrandom> (among other things)
            
-
            17:02 <+Complication> Given that it recommends an external JRE
            
-
            17:02 <+void> okay
            
-
            17:03 <+void> it's a pain in the ass to write portable sql though
            
-
            17:03 <+Complication> if one doesn't do triggers or stored procedures, shouldn't be a big pain, though
            
-
            17:04 < jrandom> eh, its not that bad, and easy to externalize
            
-
            17:04 <+void> especially when aiming oracle ;)
            
-
            17:05 < jrandom> actually, hsqldb supports pl/sql ;)
            
-
            17:06 < bar> are there any other plans for this database, such as for stats, peer profiles, netdb..?
            
-
            17:06 < jrandom> no, this is syndie only
            
-
            17:06 < bar> ok
            
-
            17:07 < jrandom> (though when we ship the hsqldb code, we can use it in i2p 'for free')
            
-
            17:07 <@cervantes> since syndie is not an I2P application, just an application that can run over I2P correct?
            
-
            17:07 < jrandom> aye cervantes, there is no dependency upon i2p
            
-
            17:07 <+Complication> Good to keep Syndie portable, since it might have other transports besides I2P
            
-
            17:07 < bar> right
            
-
            17:08 <+Complication> However, I take it wouldn't be difficult to run many hsqldb instances on the same machine
            
-
            17:08 <+Complication> So if other apps would need it, it seems they could just use it
            
-
            17:08 < jrandom> trivial, and 0-cost if you just use the in-jvm dataase
            
-
            17:08 <+Complication> (use their own instance, preferably)
            
-
            17:10 <+void> there's no jdbc driver for sqlite?
            
-
            17:11 < jrandom> dunno, never used it
            
-
            17:11 <+void> ah, looks like there is *something*
            
-
            17:13 < jrandom> ok, anything else for the meeting?
            
-
            17:13 < jrandom> if not...
            
-
            17:13  * jrandom dinws up
            
-
            17:13  * jrandom steps back
            
-
            17:13  * jrandom winds up
            
-
            17:13  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting184.html b/www.i2p2/pages/meeting184.html
deleted file mode 100644
index cbd363df..00000000
--- a/www.i2p2/pages/meeting184.html
+++ /dev/null
@@ -1,268 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 184{% endblock %}
-{% block content %}
            I2P dev meeting, September 12, 2006
            
-
            
-
            16:06 < jrandom> 0) hi
            
-
            16:06 < jrandom> 1) 0.6.1.25 and net status
            
-
            16:06 < jrandom> 2) I2PSnark
            
-
            16:06 < jrandom> 3) Syndie (what/why/when)
            
-
            16:06 < jrandom> 4) Syndie crypto questions
            
-
            16:06 < jrandom> 5) ???
            
-
            16:06 < jrandom> 0) hi
            
-
            16:06  * jrandom waves
            
-
            16:06 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-September/001307.html
            
-
            16:07 < jrandom> since those notes came up hours and hours ago, y'all should have already read them and have notes ready, right? ;)
            
-
            16:07 < jrandom> jumping forward to 1) 0.6.1.25 and net status
            
-
            16:08 < vulpine> <Complication> Regarding 0.6.1.25 seems to have worked fine over here, only one previously unseen error
            
-
            16:08 < jrandom> cool, whats the prob?
            
-
            16:08 < vulpine> * Complication searches logs
            
-
            16:09 < jrandom> the net size seems larger than before, though still same orer of magnitude
            
-
            16:09 < vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840"
            
-
            16:10 < vulpine> <Complication> Started with "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)"
            
-
            16:10 < jrandom> ah ok cool, that one has been around for a long time, safe to ignore
            
-
            16:11 < vulpine> <Complication> Single occurrence
            
-
            16:11 < vulpine> <frosk> i've gotten several of that last one
            
-
            16:11 < vulpine> * jrandom pokes fox
            
-
            16:12 < vulpine> <Complication> Oh, and one more: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ"
            
-
            16:12 < vulpine> <Complication> (seems non-significant too, maybe simple congestion)
            
-
            16:12 < jrandom> aye, likely 
            
-
            16:13 < jrandom> irc is, obviously, a bit rough at the moment still
            
-
            16:13 < jrandom> (but, for once, its not i2p's fault :)
            
-
            16:14 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.25?
            
-
            16:15 < kostya213> just want to add that .25 fixed all my problems i've been having the past few months
            
-
            16:15 < jrandom> wikked!
            
-
            16:16 < vulpine> <green> please, change status calcul when only using NTCP
            
-
            16:16 < jrandom> 'k, but its not recommended to disable udp (i believe i've explicitly said that i won't tell people how to disable udp too)
            
-
            16:17 < jrandom> but the status should be updated to take into consideration that udp is not the only transport
            
-
            16:17 < jrandom> i'll get that fixed in the next rev, thanks
            
-
            16:17 < vulpine> <green> jrandom : sure you don't tell, but i'm able to read code ;)
            
-
            16:18 < jrandom> right, though when i don't recommend something, and tell people not even to try, don't be suprised if a display message comes up confusing ;)
            
-
            16:19 < vulpine> <green> sure, i could also juste display "OK" in console :)
            
-
            16:19 < jrandom> true 'nuff
            
-
            16:21 < jrandom> ok, lets jump on over to 2) I2PSnark 
            
-
            16:21 < jrandom> zzz doesn't seem to be over there atm
            
-
            16:22 < jrandom> there are some changes zzz is working on to improve the scheduling in i2psnark
            
-
            16:23 < jrandom> (its a bit.. simplistic atm iirc, though i'm not entirely certain of the mods zzz is hacking on)
            
-
            16:23 < jrandom> ((but i look forward to the progress!))
            
-
            16:25 < jrandom> ok, if there's nothing else on 2) I2PSnark, lets move forward to 3.*) Syndie stuff
            
-
            16:26 < jrandom> lets jump in to 3.1) what is syndie first, since there's so much to cover
            
-
            16:27 < jrandom> i got a few questions before the meeting regarding the encryption for posts
            
-
            16:27 < jrandom> basically, posts are *symmetrically* encrypted - anyone with the symmetric key can read the post, as they're authorized
            
-
            16:28 < jrandom> channel replies are asymmetrically encrypted to the public key associated with the channel/forum
            
-
            16:28 < jrandom> some posts can use passphrase based encryption to generate the symmetric key for reading
            
-
            16:29 < jrandom> and some posts can include the symmetric key in the post's readable headers (so that anyone can read it)
            
-
            16:29 < modulus> what's the point of that last one?
            
-
            16:29 < jrandom> and some forums themselves can include the symmetric key in the forum metadata, so that anyone can read the post but only if they have the channel metadata
            
-
            16:29 < jrandom> modulus: so that everything is always encrypted, even publicly readable stuff
            
-
            16:29 < jrandom> (so that trivial wiretapping is useless)
            
-
            16:30 < modulus> right, i see.
            
-
            16:31 < jrandom> ok, i think that covers the encryption questions that were asked before the meeting
            
-
            16:31 < jrandom> does anyone have any questions on 3.1) what is syndie?
            
-
            16:31 < jrandom> (I mean, more will be clarified as it is pushed out there, of course)
            
-
            16:32 < vulpine> <void> hmm
            
-
            16:33 < jrandom> que tal void?
            
-
            16:33 < vulpine> <void> <void> i guess that the message (.zip) archive can also include other messages, possibly from other  people, such as the messages being quoted?
            
-
            16:34 < jrandom> well, yes, you can include .snd files as attachments, but there is an explicit namespace, so you can do standard References: style links to previous messages
            
-
            16:34 < jrandom> (aka you don't have to do frost-style "threading")
            
-
            16:35 < vulpine> <void> ok, right
            
-
            16:37 < vulpine> <Complication> About Syndie, I wondered how people would go about solving the problem of granting people access to some multiple-poster forum (like accounts on an ordinary message board) but not granting this irrevocably, and avoiding undesired mess when need to revoke access (for whatever reasons) occurs
            
-
            16:38 < vulpine> <Complication> One solution, of course, seemed for the author to specify a recommendation of whose replies clients should display
            
-
            16:38 < jrandom> Complication: create a new pub/private keypair, give the private key to (temporarily) authorized people, and include the public key as the list of "keys allowed to post"
            
-
            16:38 < vulpine> <Complication> ..and for clients, unless they desire to research history, to follow this recommendation (or more specifically its latest version)
            
-
            16:38 < jrandom> (and when they are no longer authorized, remove that key from the list of "keys allowed to post")
            
-
            16:39 < kostya213> jrandom: you might want to use a different extension than .snd since it's a widely used extension for audio applications, mime will confuse it
            
-
            16:39 < jrandom> ah, right - all forums have an "owner" (a signing private key) who can manage the list of who is allowed to post, etc
            
-
            16:39 < vulpine> <Complication> "keys allowed to post" would be metadata attached to the author's latest post, or some other message, right?
            
-
            16:39 < jrandom> good point kostya213, though we may be stuck with .dat then ;)
            
-
            16:40 < jrandom> Complication: ah sorry, no, its like the current/old syndie- separate signed metadata posts for the forum/channel itself
            
-
            16:40 < vulpine> * Complication believes that someone has even claimed .dat for something :)
            
-
            16:40 < jrandom> yes, the application called "octet-stream" ;)
            
-
            16:40 < vulpine> <void> it doesn't look like .syn is used for anything noteworthy
            
-
            16:41 < vulpine> <Complication> Aha, special metadata posts... right, that could do it
            
-
            16:41 < jrandom> oh neat, we get to syn!
            
-
            16:41 < jrandom> (good eye void, thanks kostya213)
            
-
            16:41 < vulpine> <void> hmm, "
            
-
            16:41 < vulpine> <void> hmm, "Word Synonym File", Company: Microsoft
            
-
            16:42 < jrandom> well, i'm sure we'll work 'er out
            
-
            16:42 < kostya213> yes it's used by word
            
-
            16:42 < vulpine> <void> but we might as well ignore that :)
            
-
            16:42 < kostya213> don't lose hope, i think it's possible to find something that won't cause problems with widely used mimetypes
            
-
            16:43 < jrandom> ok, anything else on 3.1) What is syndie?
            
-
            16:43 < vulpine> <void> err, then again, why would we stick with three-letter extensions? it's a relic from the DOS ages
            
-
            16:43 < kostya213> one thing that must be asked, why limit to a three-letter extension? nobody uses DOS anymore
            
-
            16:44 < jrandom> heh
            
-
            16:44 < kostya213> jinx on void
            
-
            16:44 < kostya213> .syndie seems good to me
            
-
            16:44 < vulpine> <void> .synd wouldn't conflict with any
            
-
            16:44 < kostya213> good as well
            
-
            16:45 < vulpine> <void> damn lag :(
            
-
            16:48 < jrandom> ok, lets jump on over to 3.2) Why does Syndie matter?
            
-
            16:48 < vulpine> <void> jrandom: wait
            
-
            16:48 < cervantes> (because you say it does)
            
-
            16:48  * jrandom waits
            
-
            16:48 < jrandom> !thwap cervantes ;)
            
-
            16:48 < vulpine> <void> the status notes post mentions that an avatar can be attached to a post, otherwise a default will be used
            
-
            16:49 < vulpine> <void> but what if a person wants to have several predefined avatars instead of a single "default" one?
            
-
            16:49 < jrandom> aye, the author can include a default avatar in their own channel's metadata
            
-
            16:49 < vulpine> <void> attaching the other one every time isn't going to be efficient
            
-
            16:49 < jrandom> good question void - lets jump to that script code in the notes
            
-
            16:50 < jrandom>     listauthkeys --authorizedOnly true
            
-
            16:50 < jrandom>     authenticate 0
            
-
            16:50 < vulpine> <void> (?)
            
-
            16:50 < jrandom> listauthkeys will display all of the identities you can sign the message saying that you are, while "authenticate 0" picks an identity to sign with
            
-
            16:51 < jrandom> so, that identity has its own channel, and that channel has its own metadata, which may include an avatar
            
-
            16:51 < vulpine> <void> hmm, a separate identity means a separate keypair?
            
-
            16:51 < jrandom> yes
            
-
            16:51 < vulpine> <void> what if a person wants to have several avatars on a single identity?
            
-
            16:52 < jrandom> they have a default avatar on their channel metadata, and they can override it on a per-message basis
            
-
            16:52 < kostya213> dubious value
            
-
            16:52 < vulpine> <void> several "default" avatars he can choose from
            
-
            16:52 < vulpine> <void> or am i splitting hair here? :)
            
-
            16:53 < jrandom> ah, i understand what you're saying.  nah, not supported at first
            
-
            16:53 < jrandom> maybe later
            
-
            16:53 < vulpine> <void> true kostya213, never mind then
            
-
            16:53 < vulpine> <void> :)
            
-
            16:53 < jrandom> (but the avatars will be very limited in size, so shouldn't be much trouble to include)
            
-
            16:53 < vulpine> * Complication thinks the adding of per-message ones could be coded to be easy enough
            
-
            16:53 < vulpine> <void> so, 3.1) What is syndie?
            
-
            16:53 < vulpine> <Complication> (eventually)
            
-
            16:54 < vulpine> * cervantes glues the irc servers together
            
-
            16:54 < vulpine> <void> Complication: jrandom just said he is going to do that already :)
            
-
            16:54 < jrandom> (per message ones will be in the baseline complication, its the idea of having many 'defaults' to choose from, picking it by saying "use avatar 1" in a message rather than including the avatar itself)
            
-
            16:54 < vulpine> <Complication> latency, latency...
            
-
            16:54 < jrandom> ok, anything else for 3.1?
            
-
            16:54 < jrandom> if not, lets jump to 3.2
            
-
            16:55 < vulpine> <void> i think that's all
            
-
            16:55 < jrandom> wr0d.
            
-
            16:56 < jrandom> other than cervantes' snark, anyone have any questions/comments/concernts re "why"?
            
-
            16:56 < jrandom> (er, "concerns")
            
-
            16:58 < vulpine> <Complication> cervantes: did you clean the surface with alcohol before applying glue on the ircd? ;)
            
-
            16:58 < kostya213> imo syndie doesn't need justification, its value should be self-evident to anyone who's already interested in anonymizing networks
            
-
            16:58 < kostya213> and aware of the dangers of centralization of information
            
-
            16:59 < vulpine> <Complication> (repost, please ignore if reached server)
            
-
            16:59 < vulpine> * Complication thinks that Syndie matters because Joe Sixpack running phpBB would suffer pwnage too quickly, and Joe Sixpack running $random_blogging_tool would suffer it too
            
-
            16:59 < vulpine> <Complication> (even if probability might vary)
            
-
            16:59 < vulpine> <void> indeed
            
-
            16:59 < jrandom> aye, plus anyone facing actual hostile adversaries (not even necessarily state level)
            
-
            17:00 < jrandom> ok, cool, just wanted to run things by y'all
            
-
            17:00 < jrandom> anything else on 3.2, or shall we move over to 3.3) when can we use syndie?
            
-
            17:01 < vulpine> <void> well, essentially it's a forum/blogging/e-mail/communication tool based on cryptographic primitives and independent from a transport layer
            
-
            17:01 < vulpine> <Complication> ...and in the far-out scenario that Joe Sixpack's adversary would mount intersection attacks, anyone running an eepsite of any kind would suffer pwnage eventually (except in an enormous network)
            
-
            17:01 < kostya213> it might be a harder sell to those who don't see immediate value in privacy/anonymity
            
-
            17:01 < jrandom> kostya213: aye, though we may be able to pull some tricks, like being able to safely browse offline
            
-
            17:02 < vulpine> <Complication> They might appreciate security regardless
            
-
            17:02 < jrandom> (e.g. an offline rss reader that also pulls in the full set of pages referenced, not just the rss summary)
            
-
            17:02 < vulpine> <void> so yeah, i can't see why it needs justification :)
            
-
            17:02 < vulpine> <void> kostya213: they needn't be anonymous to use syndie
            
-
            17:02 < cervantes> when can we use syndie or when will syndie be useable?
            
-
            17:02 < jrandom> word void :)
            
-
            17:03 < cervantes> for the text interface I imagine there needs to be a fairly hefty amount of usage documentation
            
-
            17:03 < jrandom> cervantes: right now, syndie is functional (you can create posts, manage channels, read posts, reply to posts, etc)
            
-
            17:03 < kostya213> jrandom: how does syndie handle redundancy? how resilient is it against content disappearing?
            
-
            17:03 < cervantes> (before it's useable)
            
-
            17:03 < jrandom> cervantes: there's inline menus with each command doc'ed (at least minimaly)
            
-
            17:04 < cervantes> cool, any plans on some use case examples?
            
-
            17:04 < jrandom> kostya213: syndie works at the content layer - redundancy is handled by something else.  if you post to usenet, its replicated across usenet (for instance)
            
-
            17:04 < cervantes> I think the trick will be learning how they all script together
            
-
            17:04 < vulpine> <void> kostya213: that's out of the scope of syndie, it's dependant on the transport mechanism
            
-
            17:04 < vulpine> <void> unfortunately
            
-
            17:04 < jrandom> good idea cervantes
            
-
            17:05 < jrandom> the first syndie release will include an http replication system like the old/existing syndie
            
-
            17:05 < jrandom> cervantes: perhaps some of the beta users can put together  their favorite scripts for us to distribute :)
            
-
            17:05 < modulus> mmm, is this a console app?
            
-
            17:05 < jrandom> modulus: yes, the first text based app
            
-
            17:06 < modulus> excellent!
            
-
            17:06 < cervantes> jrandom: provided the beta users can work out how to use it ;-)
            
-
            17:06 < jrandom> hehe
            
-
            17:06  * jrandom considered curses/etc, as well as cli-only, but an interactive scriptable text interface is probably the simplest and most useful
            
-
            17:07 < jrandom> (sans gui, that is)
            
-
            17:07 < cervantes> modulus: see, jrandom listened to your relentless feedback :)
            
-
            17:07 < vulpine> <Complication> If people want, they can probably build more interactive textual interfaces on top of it
            
-
            17:07 < jrandom> aye, certainly
            
-
            17:08 < jrandom> (the code is built to support easy integration with an irc client, like pircbot)
            
-
            17:08 < modulus> cervantes: hehe
            
-
            17:09 < modulus> i guess you could put a gui on top of it too for that matter, if it works roughly as i imagine
            
-
            17:09 < modulus> although that'd be lots more work.
            
-
            17:09  * kostya213 waits for the emacs plugin
            
-
            17:09 < modulus> hahaha
            
-
            17:09 < jrandom> heh
            
-
            17:09 < modulus> actually an emacs mode isn't such a bad idea, maybe would attract more crazies to it.
            
-
            17:10 < cervantes> press ctrl-alt-shift-break-uparrow-num7-b to choose your identity
            
-
            17:10  * jrandom will leave that to elipsers to hack through ;)
            
-
            17:10 < kostya213> no offense, but i'm not sure this project needs to attract more crazies
            
-
            17:10 < vulpine> <Complication> would those sort of crazies code, too?
            
-
            17:11 < jrandom> hopefuly complication
            
-
            17:11 < jrandom> ok, hopefully 3.3) explains a it of whats coming down the line
            
-
            17:11 < jrandom> as for *when*, well, we'll see, but i'm hoping "soon" ;)
            
-
            17:12 < jrandom> ok, anyone have anything else for 3.3)?
            
-
            17:12 < vulpine> * Complication would welcome a few hordes of those crazies then :D
            
-
            17:12 < cervantes> well there's coding and then there's writing obfuscated perl interpreted tcl
            
-
            17:12 < kostya213> a plugin for FUSE might be useful too
            
-
            17:13 < jrandom> aye
            
-
            17:13 < jrandom> ok, lets jump on over to 4) crypto for syndie
            
-
            17:13 < jrandom> anyone have any comments on those issues?
            
-
            17:14 < vulpine> <Complication> I wish I had, but I'm not competent to estimate the strength of those ciphers/hashes/key lengths
            
-
            17:15 < vulpine> <void> how long are elgamal/rsa signatures? 4kbit for a 2kbit key?
            
-
            17:15 < vulpine> * Complication leaves that talk entirely for others
            
-
            17:15 < jrandom> dunno offhand
            
-
            17:15 < vulpine> <void> vs dsa?
            
-
            17:16 < jrandom> (though ecc looks nice'n'tiny)
            
-
            17:16 < modulus> ElGamal signatures are hard and long. as gnupg's team found out.
            
-
            17:16 < jrandom> aye, though some of those tricks were related to key reuse
            
-
            17:16 < vulpine> <void> ah, ok
            
-
            17:16 < vulpine> <void> yeah, it does
            
-
            17:16 < tethra> modulus: if they're hard and long, there's a fetish site for it
            
-
            17:17 < jrandom> ok, that point was really just a heads up and call for comments whenever y'all have thoughts
            
-
            17:17 < cervantes> could it not be possible to implement some kind of pluggable ciphers - when a better method of creating keys is standardised we can add that to syndie and new posts will begin using them, but can still use obsolete methods for older posts
            
-
            17:17 < tethra> (sorry)
            
-
            17:17 < jrandom> cervantes: it includes a DSA: prefix, so an Elg: prefix would work
            
-
            17:17 < modulus> are you using 1024-limited dsa or not?
            
-
            17:18 < modulus> also what has? sha1 or higher order revs?
            
-
            17:18 < cervantes> so really you are just concerned with getting syndie off to a good start
            
-
            17:18 < jrandom> dsa is only 1024bit (there are dsa2 proposals for longer, but they aren't standardized yet)
            
-
            17:18 < jrandom> and yes, dsa requires sha1
            
-
            17:18 < modulus> hmm, my understanding is that they were quite strong pre-standards.
            
-
            17:18 < kostya213> cervantes has a good point, having syndie content in fixed ciphers offers poor forward-secrecy, you never know when an algo will go titsup
            
-
            17:18 < modulus> but i don't follow the process closely enough so you are probably right
            
-
            17:19 < jrandom> kostya213: but choice is bad for crypto, so we should have fixed values when we can
            
-
            17:19 < jrandom> (bad because of anonymity)
            
-
            17:19 < vulpine> <void> do you know why aren't more people/protocols using ecc, anyway? are they afraid of the lack of research, or just worried about compatibility?
            
-
            17:19 < modulus> patents.
            
-
            17:20 < jrandom> patents and fud, yet some concerns in implementation
            
-
            17:20 < vulpine> <void> ah, right modulus
            
-
            17:20 < modulus> btw, is there are a good reason to go dsa vs rsa-sha512 for instance?
            
-
            17:20 < tethra> patents and fud and the state (oh my)
            
-
            17:20 < modulus> not trying to be annoying, just considering that gpg for instance has gone this way, among others.
            
-
            17:20 < jrandom> haven't reviewed that option in years modulus
            
-
            17:21 < modulus> obviously dsa is a standard, which speaks for it, but the keys are small and the hashes are weak. not that i think it's likely to end up being the weakest link ;-)
            
-
            17:23 < cervantes> I wouldn't propose "choice" - but new versions of syndie would package increasingly secure (mandatory) ciphers
            
-
            17:23 < vulpine> <Complication> Leaving some leeway in the structures for future change, seems reasonable regardless of which current crypto proves best, I'd think
            
-
            17:23 < jrandom> aye, though that implies the fallback to weaker/older versions to interoperate
            
-
            17:23 < jrandom> but, ok, we'll work through it
            
-
            17:24 < jrandom> ok, lets jump on over to 5) ???
            
-
            17:24 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            17:25 < cervantes> no being able to read the latest posts from your favourite source is a good incentive to make sure everyone stays upgraded
            
-
            17:25 < jrandom> to a degree
            
-
            17:26 < cervantes> no=not
            
-
            17:26 < jrandom> (aye, its an incentive, but people are lazy/not interested in "upgrading software", etc)
            
-
            17:27 < jrandom> s/people/some people/
            
-
            17:27 < cervantes> I guess that's their issue though
            
-
            17:27 < jrandom> true that
            
-
            17:27 < kostya213> the i2p implementation at least can have painless upgrading
            
-
            17:28 < jrandom> certainly
            
-
            17:28 < cervantes> as for ??? - apologies for the irc connectivity - the ISP should be restoring one if it's major network carriers "as soon as possible"
            
-
            17:29 < jrandom> w3wt
            
-
            17:29 < vulpine> <Complication> To the ??? topic, I could perhaps add that the second (more extensive) part of NTP modifications is close to working, and I hope to have it committed for testing soonish
            
-
            17:29  * cervantes pinches salt
            
-
            17:29 < kostya213> what's the near-term plans for router development? is the roadmap accurate?
            
-
            17:29 < jrandom> wikked complication
            
-
            17:29 < vulpine> <Complication> It's goal is to second-guess NTP servers basing on peer clock skews
            
-
            17:29 < jrandom> kostya213: stabilization until syndie is out
            
-
            17:30 < jrandom> (from my perspective)
            
-
            17:30 < vulpine> <Complication> (and avoid taking potentially connectivity-damaging action)
            
-
            17:31 < cervantes> grand
            
-
            17:32 < jrandom> ok, anything else for the meeting?
            
-
            17:34  * jrandom winds up
            
-
            17:34  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting185.html b/www.i2p2/pages/meeting185.html
deleted file mode 100644
index 1db03a4a..00000000
--- a/www.i2p2/pages/meeting185.html
+++ /dev/null
@@ -1,85 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 185{% endblock %}
-{% block content %}
            I2P dev meeting, October 17, 2006
            
-
            
-
            16:01 < jrandom> 0) hi
            
-
            16:01 < jrandom> 1) Net status
            
-
            16:01 < jrandom> 2) Syndie dev status
            
-
            16:01 < jrandom> 3) ???
            
-
            16:01 < jrandom> 0) hi
            
-
            16:01  * jrandom waves
            
-
            16:01 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001314.html
            
-
            16:02 <+fox> * dm waves
            
-
            16:02 < jrandom> w3wt, ok, while y'all read that oh-so-fun missive, lets jump on to 1) net status
            
-
            16:03 < jrandom> the net seems to be maintaining the steady state right now, though with a slight growth trend
            
-
            16:04 < jrandom> there are some discussions on the big cpu-related issue on the forum, though no big win yet, afaics
            
-
            16:04 < jrandom> anyone have anything to bring up re: 1) net status?
            
-
            16:05 < jrandom> (the last full week w/ 0.6.1.26 seems to have gone well [yay])
            
-
            16:06 <+fox> <dm> well, I better say something
            
-
            16:06 <+fox> <dm> is there a consistent metric that is being used to monitor net status
            
-
            16:06 <+fox> <dm> or is it just ad-hoc experiences?
            
-
            16:07 <+fox> <dm> like is there an application out there that tries to connect to random places every day while measuring response times and failures.
            
-
            16:07 < jrandom> i'm going largely by irc behavior, as well as the stats and activity on the routers i run (stats.i2p is down for a week or two, but it usually is a solid enchmark to run against)
            
-
            16:08 <+fox> <dm> cool, I'll check that site out.
            
-
            16:08 < jrandom> there are several people running stat monitoring apps - orion.i2p, tino.i2p, eepsites.i2p, as well as stats.i2p
            
-
            16:09 <+fox> <dm> thank you!
            
-
            16:09 < jrandom> np :)
            
-
            16:09 < jrandom> ok, if there's nothing else on 1), lets jump on over to 2) syndie dev status
            
-
            16:10 < jrandom> lots going on, as mentioned in the status notes (and you can finally see a non-hideous-looking website at syndie.i2p.net :)
            
-
            16:11 <+fox> <dm> down at the moment?
            
-
            16:11 <+fox> <dm> scratch that
            
-
            16:11 <+fox> * dm shuts up
            
-
            16:11 < jrandom> :)
            
-
            16:12 < marlowe> jrandom, the diagram on the front page is very helpful
            
-
            16:12 < marlowe> i know understand the concept behind syndie
            
-
            16:12 <+fox> <dm> it's pretty as well
            
-
            16:13 <+fox> <dm> but how do you access syndie without download/installing it? I remember you could do this before?
            
-
            16:13 < jrandom> great, glad its clear marlowe - it can be a confusing concept in just text :)
            
-
            16:13 < jrandom> dm: the old syndie (syndiemedia.i2p.net/) was web based, but this new one is, well, brand new, completely redesigned
            
-
            16:14 <+fox> <dm> it's not web-based?
            
-
            16:14 < jrandom> (and thanks to cervantes for turning my ugly ms-paint-style image into the slick pic you see there :)
            
-
            16:14 < jrandom> no, its not web based - current release is actually text only, but work continues on a gui
            
-
            16:14 < jrandom> http://syndie.i2p.net/roadmap.html
            
-
            16:14 <+fox> <dm> text-only! wow. ok. downloading.
            
-
            16:14 < jrandom> w3wt
            
-
            16:15 < jrandom> one important thing you need to know to effectively use it is the location of a syndie archive that you can push posts to and pull posts from
            
-
            16:15 <+fox> <dm> wow.. this is hardcore stuff. (Next Command:) hehhehe
            
-
            16:15 < jrandom> there's currently one at http://syndie.i2p.net/archive - you can sync up with that via "menu syndicate" "getindex --archive http://syndie.i2p.net/archive" and "fetch" :)
            
-
            16:16 < jrandom> its a fairly simple system, though with very specific design features
            
-
            16:16 < jrandom> (and incredibly robust - it can run on anything :)
            
-
            16:17 <+fox> <dm> there's something cool about really complex apps running with a text frontend
            
-
            16:17 <+fox> <dm> anyway...
            
-
            16:17 <+fox> * dm shuts up again
            
-
            16:19  * jrandom hopes to bring us up to 1.0 sometime this month, so beta testing would be great
            
-
            16:20 < jrandom> (kick the tires, tell me whats broken, etc)
            
-
            16:20 < jrandom> 1.0 won't include the gui, of course, thats 2.0
            
-
            16:20 <+fox> <dm> of course
            
-
            16:21 < jrandom> ok, anyone have any comments/questions/suggestions/toenails on 2) Syndie dev status?
            
-
            16:22 < jrandom> oh, one thing i wanted to bring up - as i posted in my syndie blog, we need a logo!  so, see urn:syndie:channel:d7:channel44:bF2lursCrXhSECJAEILhtXYqQ6o-TwjlEUNJLA5Nu8o=9:messageIdi1160962964161ee :)
            
-
            16:23 <+fox> <dm> there's a good place to get free or semi-free very high quality logos
            
-
            16:24 < jrandom> flickr?  :)
            
-
            16:24 <+fox> <dm> http://www.worth1000.com/ <--- photoshop geeks around try to outdo each other for a little fame and/or money
            
-
            16:24 < jrandom> ah cool
            
-
            16:25 <+fox> <dm> example of a previous 'contest' http://www.worth1000.com/cache/contest/contestcache.asp?contest_id=12170&start=1&end=10&display=photoshop
            
-
            16:25 <+fox> * dm shuts up again
            
-
            16:26 < jrandom> wikked, thanks dm
            
-
            16:27 < jrandom> ok, if there's nothing on 2, lets jump to 3) ???
            
-
            16:28 < jrandom> anyone have anything else for the meeting?
            
-
            16:28 < bar> perhaps we should save that for the 1.99b version and have a little contest/bounty thing going to plug syndie 2.0?
            
-
            16:28 < jrandom> ah, thats a good idea, since 1.* is going to be text anyway
            
-
            16:30 < bar> think about it, i'm sure we can dig up some funding
            
-
            16:30 <+fox> <dm> how's funding going anyway? 
            
-
            16:31 <+fox> <dm> are you still doing this full-time jr?
            
-
            16:31 < jrandom> aye, still getting by, thanks to some insanely generous contributors (thanks!)
            
-
            16:31 < jrandom> http://www.i2p.net/halloffame
            
-
            16:32 <+fox> <dm> ah yes.. the shoestring budget. I remember now
            
-
            16:32 < jrandom> hehe
            
-
            16:34 < jrandom> ok, anyone have anything else to bring up?
            
-
            16:34 <+fox> <dm> just dropped you a c-bill. Make sure it's only used for alcohol or other frivolous uses.
            
-
            16:34 <+fox> <dm> oh and keep my real name secret!
            
-
            16:34 < jrandom> w00t!  thanks dm
            
-
            16:36 < jrandom> ok, if there's nothing else...
            
-
            16:36  * jrandom winds up
            
-
            16:36  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting186.html b/www.i2p2/pages/meeting186.html
deleted file mode 100644
index 50fe9dd5..00000000
--- a/www.i2p2/pages/meeting186.html
+++ /dev/null
@@ -1,103 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 186{% endblock %}
-{% block content %}
            I2P dev meeting, October 24, 2006
            
-
            
-
            16:03 < jrandom> 0) hi
            
-
            16:03 < jrandom> 1) Net status
            
-
            16:03 < jrandom> 2) Syndie dev status
            
-
            16:03 < jrandom> 3) ???
            
-
            16:03 < jrandom> 0) hi
            
-
            16:03  * jrandom waves
            
-
            16:03  * Complication stumbles to somewhere within reach of keyboard (week's beginning was hell, but it's over now)
            
-
            16:04 < jrandom> (hooray to hellish beginnings!)
            
-
            16:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001315.html
            
-
            16:04 <+Complication> Hello
            
-
            16:05 < jrandom> while y'all read the (short) notes, lets jump to 1) Net status
            
-
            16:05  * jrandom has been connected to freshcoffee for 3 days now w/out discon, and it looks like both of the irc servers have a good number of users on them
            
-
            16:06 < jrandom> stats.i2p is back too, and the tunnel success rate has been doing some odd jumps, but generally in good shape too
            
-
            16:06 < jrandom> (though still in the 20-30 range)
            
-
            16:06 < jrandom> ((which is much better than 5-10, but much worse than 60-80))
            
-
            16:07 < jrandom> ok, anyone have anything to bring up for 1) net status?
            
-
            16:08 <+Complication> Similar here, but no extra-persistent connections
            
-
            16:08 <+tethra> other than applause, nothing from me!
            
-
            16:08 <+Complication> I just wanted to drop a little line related to NTP issues
            
-
            16:09 <+Complication> Basically, on Sunday, Oct 29, some times zones will jump off dailight saving time
            
-
            16:09 < jrandom> (its going to suck)
            
-
            16:10 <+Complication> I personally hope it doesn't cause anyone any problems, but I'm not well versed enough in NTP to be sure
            
-
            16:10 <+Complication> So, just in case the recent NTP server sanity check (added with version .26) should inconvenience someone that night...
            
-
            16:11 <+Complication> ...I thought it'd be better if I mentioned the configuration key using which it can be disabled (if need should exist)
            
-
            16:11 <+Complication> (so folks who read status notes would know)
            
-
            16:12 <+Complication> Disabling it can be done by entering the line "router.clockOffsetSanityCheck=false" into http://localhost:7657/configadvanced.jsp
            
-
            16:12 <+Complication> But as mentioned, I do hope nobody needs that
            
-
            16:13 <+Complication> It will be interesting to watch and see how the network behaves that night, though, as different time zones start switching
            
-
            16:13 <+Complication> I'll certainly observe, in hope that if any anomaly is seen, perhaps it can be fixed by Spring :D
            
-
            16:14 < jrandom> the minute-of will probably be pretty jumpy, but should heal shortly
            
-
            16:14 <+Complication> ...and that's all I had. :)
            
-
            16:14 < jrandom> but, hopefully it'll work out, and if not, as you say, there's spring :)
            
-
            16:14 < bar> and should things indeed b0rk, there were two possible suggestions for future improvement that surfaced in the chat the other day:
            
-
            16:15 < bar> "prevent skewed routers from forming subnets by handing over control to NTP if peers < some number"
            
-
            16:15 < bar> ...and "do not delete floodfill peer router infos from netdb if there are too few of them"
            
-
            16:15 < jrandom> aye
            
-
            16:16 <+Complication> Indeed, adjusting the required number of data points (available peer clock skews) which are required to deem peer skew measurements reliable
            
-
            16:16 <+Complication> (oops, some redundancy in my last sentence)
            
-
            16:17 <+Complication> ...and yes, the floodfill check. I take that no similar check exists currently?
            
-
            16:18 < jrandom> right
            
-
            16:18 <+Complication> Seems like some people, sometimes, either with luck or magic, may be managing to lose track of floodfill peers
            
-
            16:19 < jrandom> that should certainly be remedied
            
-
            16:19 < jrandom> (it hit some folks the other day, when one of 'em was null routed)
            
-
            16:20 < jrandom> (if #floodfill == 0, perhaps randomly treat a few as floodfill)
            
-
            16:20 <+Complication> If that's doable, possible also
            
-
            16:21 <+Complication> Though, perhaps doing that in addition to keeping at least 2 (or something like that) floodfill peers would be a doubly safe bet
            
-
            16:22 < jrandom> aye
            
-
            16:25 < jrandom> ok, anyone have anything else for 1) net status?  or shall we move on over to 2) syndie dev status?
            
-
            16:25 < badger> re irc stability: seeing much much much fewer reconnects at the server end.
            
-
            16:25 < badger> you could almost call it a service :)
            
-
            16:26 < jrandom> :)
            
-
            16:28 < jrandom> ok, jumping on to 2) syndie dev status
            
-
            16:28 < jrandom> lots of progress here, as mentioned in the status notes
            
-
            16:28 < jrandom> there's also been a bunch of discussion on it here over the last few days
            
-
            16:28 < jrandom> anyone have anything they want to bring up on that front?
            
-
            16:30 <@cervantes> install something other than mspaint
            
-
            16:30 < jrandom> heh
            
-
            16:30 < jrandom> well, there's value in using *ugly* things to sketch - limits expectations
            
-
            16:31 <+fox> <HotTuna> the links in the forumpost seem to be down ... some are anyway..
            
-
            16:31 <@cervantes> I think that's mentioned in the posts
            
-
            16:31 <+fox> <HotTuna> oh. . sorry
            
-
            16:31 < jrandom> hottuna: they're mirrored @ dev.i2p.net/~jrandom/mockup/
            
-
            16:31 <@cervantes> some should be mirrored further down
            
-
            16:32 <+Complication> One question: so, do you think it's easier to (safely) implement limited HTML from ground up, without picking apart some web browser?
            
-
            16:33  * jrandom just uploaded two more pics: dev.i2p.net/~jrandom/mockup/forum.png and blog.png (showing the discussion of the last few days regarding different ways to view a forum)
            
-
            16:33 <@cervantes> most definitely easier to do that safely
            
-
            16:33 <+Complication> (just being curious as to what's going in on the GUI side, having been somewhat unaware of it)
            
-
            16:33 < jrandom> Complication: i've got nearly everything done for general formatting purposes already
            
-
            16:33 <@cervantes> especially given the limited subset of html that syndie will support
            
-
            16:34 <+Complication> Aha
            
-
            16:34 < jrandom> (fonts, alignment, sizes, colors, images, links, lists (including nested), headers, paragraphs, html entities)
            
-
            16:35 < jrandom> now, going in and doing divs for placement or tables requires substantially more work, but i'm not tackling that now
            
-
            16:35 <+Complication> Sounds nice enough
            
-
            16:36 <@cervantes> and of course the <blink> tag
            
-
            16:36  * jrandom pelts cervantes with †
            
-
            16:37 <@cervantes> ouch, skewered by an entity
            
-
            16:37 < jrandom> we'll see though.  as it gets deployed and used, perhaps it'll be necessary to switch to a full blown html rendering engine
            
-
            16:38  * jrandom wants the codebase to be as small as possible though, so there is less to debug and review for security and anonymity issues
            
-
            16:39 <+Complication> Indeed, there are doubtless benefits to handling text/plain
            
-
            16:40 <+Complication> (which hopefully only supports natural-language attacks ;P )
            
-
            16:41 <+Complication> What are your opinions about the possibility of hashcash antispam measures? Too early to tell? Do you think they'd be easy to tack on later?
            
-
            16:42 <@cervantes> well I guess using bbcode or wiki syntax would reduce the risk of markup injection in a full html engine
            
-
            16:42 <@cervantes> *rendering engine
            
-
            16:43 < jrandom> quite easy to tack on Complication - just a new public header (hashcalc'ed against the canonical syndie uri, verified on import, created on signing)
            
-
            16:44  * Complication thought about some a few days back, but only lightly
            
-
            16:44 < jrandom> the hashcash can be done at several levels too - per new channel (meta.syndie), per updated channel, or per post (perhaps even graduated against sizeof(post) or #msgs/day)
            
-
            16:44 <+Complication> If one wanted to implement hashcash as proof of work, I wonder what the poster of the message would be best required to caclulate collisions against?
            
-
            16:45 <+Complication> Aha, the uri... might be indeed
            
-
            16:45 <+Complication> Oh, indeed
            
-
            16:45 <+Complication> That's some things I didn't think about
            
-
            16:48 < jrandom> cervantes: true enough
            
-
            16:48 < jrandom> ok, anyone have anything else for 2) syndie dev status?
            
-
            16:51 < jrandom> ok, if not, lets jump to 3) ???
            
-
            16:51 < jrandom> anyone have anything else they want to bring up?
            
-
            16:54 < jrandom> ok, if not...
            
-
            16:54  * jrandom winds up
            
-
            16:54  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting187.html b/www.i2p2/pages/meeting187.html
deleted file mode 100644
index 40211a84..00000000
--- a/www.i2p2/pages/meeting187.html
+++ /dev/null
@@ -1,76 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 187{% endblock %}
-{% block content %}
            I2P dev meeting, October 31, 2006
            
-
            
-
            15:33 < jrandom> 0) hi
            
-
            15:33 < jrandom> 1) Net status
            
-
            15:33 < jrandom> 2) Syndie dev status
            
-
            15:33 < jrandom> 3) ???
            
-
            15:33 < jrandom> 0) hi
            
-
            15:33  * jrandom waves
            
-
            15:33 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2006-October/001316.html
            
-
            15:33  * tethra waves back!
            
-
            15:34 < jrandom> lets jump on in to 1) net status
            
-
            15:34 < jrandom> no news on this front afaik... things seem stable
            
-
            15:34 < jrandom> anyone have anything they want to bring up on it?
            
-
            15:35 <+tethra> nothing here
            
-
            15:36 < jrandom> ok lets jump on to 2) Syndie dev status then
            
-
            15:37 < jrandom> as mentioned in the notes, i've been exploring some wysiwyg editor components, but it seems a big pain in the ass (no suprise), and no great solution exists afaik
            
-
            15:38 < jrandom> so, right now my thoughts are to go with a basic editor with helpers like you see on forums like forum.i2p.net.  not wysiwyg, but helpful
            
-
            15:39 <+tethra> makes sense. might wysiwyg be a progression later on, then?
            
-
            15:39 < jrandom> of course, if someone tracks down a good small oss wysiwyg editor, i'd love to hear about it (though i've reviewed a dozen options)
            
-
            15:39 < jrandom> aye, thats a great way for later enhancement
            
-
            15:40 <+tethra> less of a jump between geek and non geek that way :)
            
-
            15:40 <+tethra> (have you looked at Nvu?)
            
-
            15:41 < jrandom> aye, huge, but promising
            
-
            15:41 <+tethra> which others had you looked at?
            
-
            15:42 <+tethra> out of interest
            
-
            15:42 < jrandom> everything i could google into.  no list at hand
            
-
            15:42 <+tethra> ah, right
            
-
            15:44 < koff> Would it be useful to have a split view with the html at the bottom and a realtime updating rendering of the page at the top?
            
-
            15:45 <+tethra> or maybe left/right (being able to choose would be lovely
            
-
            15:45 <+tethra> )
            
-
            15:45 < jrandom> aye, thats a good idea (not entirely realtime, but semi-realtime)
            
-
            15:46 <+tethra> yeah, refresh button etc
            
-
            15:46 < jrandom> perhaps on 5s idle or a button press
            
-
            15:46 < jrandom> right
            
-
            15:48 < koff> You could maybe even have two cursors, so you almost feel like you're navigating both at the same time?
            
-
            15:48 <+tethra> that'd be a bit confusing :/
            
-
            15:48 < koff> maybe :)
            
-
            15:50 < jrandom> ok, anyone have anything else on 2) syndie dev status?
            
-
            15:51 < jrandom> if not, lets move on to 3) ???
            
-
            15:51 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            15:54 <+fedo> yeah Jr , can hope to have a "joe 6 pack"'s  guide to use syndie 1.0 ? ie : what we can do with that text mode console ...
            
-
            15:55 <+fedo> i'll love to help to test syndie but i'm still unable to understand how to use syndie ! :)
            
-
            15:55 < jrandom> fedo: does http://syndie.i2p.net/manual.html and http://syndie.i2p.net/features.html and http://syndie.i2p.net/usecases.html help?
            
-
            15:55 < jrandom> is it a question of "what can you do with syndie", or "how can you do $x"?
            
-
            15:55 <+fedo> hm not really Jr :-/
            
-
            15:56 <+fedo> really, i try to do it ...
            
-
            15:56 <+fedo> how i can use syndie ...
            
-
            15:57 <+fedo> the text mode console is not a problem
            
-
            15:57 < jrandom> how you can use syndie /to do what/?  or is that the question itself - why would you install and use syndie?
            
-
            15:57 <+fedo> but what to do when i've installed Syndie is one :-s
            
-
            15:57 < jrandom> ah
            
-
            15:58 < jrandom> ok, think of syndie like a customized web browser - you install it so that you can participate in forums.  once you install it, you need to tell it what forums you want to participate in
            
-
            15:59 < jrandom> the current 0.919b install will out of the box tie in to the syndie archive at http://syndie.i2p.net/archive/ - you can just install it, log in, and sync up
            
-
            16:00 < jrandom> and once you've synced up, you can read posts to the various forums, post up replies, or post up to your own forum
            
-
            16:01 <+fedo> Jr : i'm thinking that you could made a breif note to explain how to use Syndie : ie how to sync, how to fecth a post ...
            
-
            16:02 <+tethra> (or even, an example repository (syndie.i2p.net ?) to sync to)
            
-
            16:02 <+tethra> oh, didn't read above :/
            
-
            16:02 <+tethra> nvm
            
-
            16:03 < jrandom> fedo: good idea, i'll write one up
            
-
            16:03  * fedo waves
            
-
            16:05 < jrandom> ok cool, anyone have anything else for the meeting?
            
-
            16:05 <+fedo> we know that you to enable the use of syndie on freenet : tell us how to do it ... (you know that i'm unable to find by reading the syndie's code :-/ )
            
-
            16:05 <+fedo> ((help me :))
            
-
            16:06 < jrandom> http://syndie.i2p.net/manual.html#syndicate_freenetpost
            
-
            16:06 < jrandom> and http://syndie.i2p.net/manual.html#syndicate_getindex
            
-
            16:07 <+fedo> many 'neurones' to burn but i'll  try :)
            
-
            16:07 < burl> fedo: Complication has written a brief and pretty handy startup guide on the forum here: http://forum.i2p/viewtopic.php?p=8860#8860
            
-
            16:08 < jrandom> ah right, thats a good one burl
            
-
            16:08 <+fedo> thanks burl : i'll have a look to that note ;)
            
-
            16:12 < jrandom> word, ok, if there's nothing else for the meeting...
            
-
            16:12  * jrandom winds up
            
-
            16:12  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting188.html b/www.i2p2/pages/meeting188.html
deleted file mode 100644
index dd09ed64..00000000
--- a/www.i2p2/pages/meeting188.html
+++ /dev/null
@@ -1,93 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 188{% endblock %}
-{% block content %}
            I2P dev meeting, November 7, 2006
            
-
            
-
            15:09 < jrandom> 0) hi
            
-
            15:09 < jrandom> 1) Net status
            
-
            15:09 < jrandom> 2) Syndie dev status
            
-
            15:09 < jrandom> 3) I2Phex mods
            
-
            15:09 < jrandom> 4) ???
            
-
            15:09 < jrandom> 0) hi
            
-
            15:09  * jrandom waves
            
-
            15:10 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2006-November/001317.html
            
-
            15:10  * spaetz waves back
            
-
            15:10 < mrflibble> cool,  i was the only one  in #i2p-dev a minute ago :)
            
-
            15:10 < jrandom> hehe
            
-
            15:10 < jrandom> yeah, the i2p-dev chan migration didn't last too long ;)
            
-
            15:10 < jrandom> ok, lets jump into 1) Net status
            
-
            15:11 < spaetz> ad 1) net seems stable
            
-
            15:11 < spaetz> however, as you noted, reseeding is needed every 7 days or so
            
-
            15:11 < jrandom> aye, 'tis unfortunate, and fixable
            
-
            15:12 < jrandom> though the kludge fix is kind of ugly, and the long term fix is pretty involved
            
-
            15:12 < spaetz> yep, that would be nice. My firewall is too tight for reseeding
            
-
            15:12 < jrandom> damn, doesn't allow outbound http to dev.i2p.net?
            
-
            15:12 < spaetz> I need to poke additional holes in it :-)
            
-
            15:13 < spaetz> jrandom: outbound yes, but all the reply data gets stopped by default :-)
            
-
            15:13 < spaetz> but that OT. go on.
            
-
            15:14 < jrandom> lol ok, interesting
            
-
            15:14 < jrandom> its something that needs to get addressed, though its not on my do-immediately pile
            
-
            15:15 < jrandom> i dont really have much more to add to 1).. anyone have anything else they want to bring up re: net status?
            
-
            15:15 < spaetz> I get disconnected on IRC every 1-2 hours
            
-
            15:15 < spaetz> but I would call that stable :-)
            
-
            15:16 < spaetz> ok, on to 2)
            
-
            15:16 < jrandom> heh cool, 2) it is
            
-
            15:17 < jrandom> lots of progress on this front
            
-
            15:17 < spaetz> Is the new Syndie going to be integrated into i2p when it goes gold?
            
-
            15:18 < jrandom> hmm, if you mean bundled with, i'm not sure.  if you mean capable of seamlessly using, yes, definitely
            
-
            15:19 < spaetz> I actually meant bundled. I2p seems to come "with batteries included"
            
-
            15:19 < jrandom> the reason i'm not sure is that syndie will weigh a good deal (swt native libs, translations, spellcheck dictionaries, etc)
            
-
            15:19 < jrandom> we will have an option to bundle them, certainly
            
-
            15:20 < jrandom> and maybe that'll be the most common download
            
-
            15:20 < spaetz> ok, I'm  for an optional install then. alright. 
            
-
            15:21 < jrandom> bundling the text UI is certainly doable without a doubt, thats quite lightweight
            
-
            15:22 < spaetz> that might be good enough to tease people
            
-
            15:22 < spaetz> SOme might want to run the gui on a different machine than their i2p peer anyway
            
-
            15:22 < spaetz> (I will)
            
-
            15:23 < jrandom> word
            
-
            15:23 < jrandom> ok, some teaser images for the gui dev status:
            
-
            15:23 < jrandom> html rendering: http://dev.i2p.net/~jrandom/mockup/render_snap.png
            
-
            15:23 < jrandom> forum tree: http://dev.i2p.net/~jrandom/mockup/syndie_refchooser.png
            
-
            15:23 < jrandom> message tree / filter: http://dev.i2p.net/~jrandom/mockup/syndie_msgchooser.png
            
-
            15:24 < jrandom> (the html rendering has been seen before, and the reference chooser may have been, and the message chooser was just implemented last night ;)
            
-
            15:25 < jrandom> there'll be lots of little add-ons, but i'm focusing on first getting gui message generation in place
            
-
            15:25 < jrandom> (which requires being able to browse forums and messages anyway, to pick links)
            
-
            15:26 < spaetz> cool
            
-
            15:26 < spaetz> although the beauty of syndie was its seamless integration through the web interface
            
-
            15:26 < spaetz> but I bet that would be possible to implement
            
-
            15:27 < jrandom> well, a web interface would technically be possible, but it would have all the security issues of the browser plus all the problems for interactive content that javascript/etc can cause
            
-
            15:28 < spaetz> mmh, I see the hell you'd get into. I remember the corresponding freenet discussions a few years back
            
-
            15:28 < jrandom> technically, we can pull in the mozilla engine to do html rendering with the SWT Browser widget, but doing so just isn't safe
            
-
            15:29 < jrandom> aye, exactly
            
-
            15:29 < jrandom> (and what, 5-8 years on, they still just found another security hole in their filter the other week)
            
-
            15:30 < jrandom> ((my point is not that their filter isn't great, its that doing the filter is insanely dangerous))
            
-
            15:30 < spaetz> ok, if there's a document "syndie for dummies" I'd give it a shot. (the text UI). IS the manual the right document for this?
            
-
            15:30 < spaetz> It seemed a bit specific already
            
-
            15:31 < jrandom> ah - check out Complication2's post: http://forum.i2p.net/viewtopic.php?t=1935
            
-
            15:31 < spaetz> ok, thanks.
            
-
            15:31 < jrandom> that's getting wrapped up into a page for the syndie site, but isn't up yet
            
-
            15:32 < spaetz> ok, that's great. all I needed
            
-
            15:34 < jrandom> cool.  ok, thats about it for gui stuff atm
            
-
            15:34 < jrandom> there's a little teaser for the p2p folks in the status notes regarding a swarming syndication system
            
-
            15:35 < jrandom> thats an area quite ripe for playing around in, for those who'd like to do some network hacking
            
-
            15:36 < jrandom> but, thats just a side note
            
-
            15:36 < jrandom> ok, if there's nothing else on 2) syndie dev status, lets jump over to 3) i2phex mods
            
-
            15:36 < jrandom> Complication2: wanna give us the rundown?
            
-
            15:38 < jrandom> or, if you're not here, those of y'all interested can check the status notes for my synopsis
            
-
            15:39 < spaetz> mmh, gone fishin'
            
-
            15:39 < jrandom> ok, lets jump on over to 4) ???
            
-
            15:39 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            15:39  * mrflibble sticks his hand up
            
-
            15:40 < spaetz> nahh, looking forward to see (the new) Syndie getting more useful
            
-
            15:40 < mrflibble> on http://dev.i2p.net/pipermail/i2p/2006-November/001317.html, what does "hi y'all, good luck with the subpoena power" mean exactly?
            
-
            15:40 < spaetz> will the first codename be "will the real Syndie please stand up?" :-)
            
-
            15:41 < jrandom> mrflibble: http://www.electoral-vote.com:2006/
            
-
            15:41 < jrandom> hehe spaetz 
            
-
            15:41 < mrflibble> oh!
            
-
            15:41  * bar impregnates a ballot
            
-
            15:43 < jrandom> (not that the democrats would be any better for the world, but the ability to subpoena the us president via congressional investigations would likely throw a few wrenches into the war machine for a bit)
            
-
            15:44 < jrandom> ok, anyone have anything else for the meeting?
            
-
            15:45 < jrandom> if not...
            
-
            15:46  * jrandom winds up
            
-
            15:46  * jrandom *baf*S the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting189.html b/www.i2p2/pages/meeting189.html
deleted file mode 100644
index 626963fd..00000000
--- a/www.i2p2/pages/meeting189.html
+++ /dev/null
@@ -1,96 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 189{% endblock %}
-{% block content %}
            I2P dev meeting, November 14, 2006
            
-
            
-
            15:07 < jrandom> 0) hi
            
-
            15:07 < jrandom> 1) Net status
            
-
            15:07 < jrandom> 2) Syndie dev status
            
-
            15:07 < jrandom> 3) I2Phex mods
            
-
            15:07 < jrandom> 4) ???
            
-
            15:07 < jrandom> 0) hi
            
-
            15:07  * jrandom waves
            
-
            15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001318.html
            
-
            15:07 < jrandom> (i'm late, so i'll let y'all catch up on those)
            
-
            15:09 < jrandom> ok, lets jump on in to 1) net status
            
-
            15:10 < jrandom> [eom] :)
            
-
            15:10  * jrandom has had a good irc connection now (4+ days), so things are in pretty good shape.
            
-
            15:11 < jrandom> we've also got those new peer capacity graphs on stats.i2p, detailing some interesting ratios 
            
-
            15:13 < jrandom> ok, anyone have anything else for 1) net status?
            
-
            15:14 < striker> just that it looks nice.
            
-
            15:14 < jrandom> w00t :)
            
-
            15:15 < jrandom> ok, lets hop on over to 2) syndie dev status then
            
-
            15:15 < green> I dunno U can have 4+ days conection on IRC,, I'm disconnected somewhat every 24h even with a router not so overloaded
            
-
            15:15 < jrandom> green: unfortunately, its pretty arbitrary.
            
-
            15:16 < jrandom> (or, more precicely, the cause is dependent upon many factors without a good control over them)
            
-
            15:17 < green> any chance to really know why ?
            
-
            15:17 < green> I've plenty of tunnels even where IRC goes down
            
-
            15:18 < green> s/when
            
-
            15:18 < jrandom> yes, there's lots we can do, but i'm focusing my time on getting syndie out first
            
-
            15:18 < green> I know, so I've just to way more ;)
            
-
            15:19 < green> s/wait
            
-
            15:20 < green> gr f..ing keyboard
            
-
            15:20 < green> ok, no more on 1 let's got to 2
            
-
            15:20 < jrandom> w3rd
            
-
            15:21 < jrandom> ok, not much more to add beyond whats in the notes (well, that can reasonably be brought up)
            
-
            15:21 < jrandom> the webcaching discussion thread is http://forum.i2p.net/viewtopic.php?t=1958
            
-
            15:22 < green> is there any plan on phpbb to syndie converter ?
            
-
            15:22 < jrandom> and the latest mockup image referred to is http://dev.i2p.net/~jrandom/mockup/forum.png
            
-
            15:23 < jrandom> green: hmm, i thought we discussed that in one of the meetings, but looking back at the logs, it occurred outside of a meeting
            
-
            15:24 < jrandom> short answer: doable, and maybe it'll get done, but its not on the immediate roadmap
            
-
            15:24 < jrandom> at least, not bidirectional phpbb<-->syndie operation
            
-
            15:24 < jrandom> phpbb-->syndie is easy (just suck in the posts, or use server side generation)
            
-
            15:25 < jrandom> syndie-->phpbb is easy too
            
-
            15:25 < jrandom> i'm not sure if the phpbb model of operation is what people will end up using syndie for though
            
-
            15:25 < jrandom> but we'll see
            
-
            15:28 < green> even just an phpbb -> syndie would be enough
            
-
            15:30 < jrandom> cool, that'll be trivial (pulling phpbb's rendered html into a page & posting it).  a bit more complex would be pulling from phpb's database itself, though that'd give more control (but then only the phpbb admin could do it - the former method can be done by anyone)
            
-
            15:31 < badger> phpbb's admin is fairly flat.... not a challenge to get a hook of
            
-
            15:32 < badger> and there are various rss plugins available for it
            
-
            15:33 < jrandom> ah cool.  actually, if someone wanted to start looking into that, it'd rule - just generate an HTML page (and if you need to reference other resources, do so with the syndie URIs [syndie.i2p.net/spec.html#uri] 
            
-
            15:34 < jrandom> (and if you need images/etc, just reference them as img src="attachment1" etc)
            
-
            15:34 < jrandom> (and then we can shove 'em into a syndie post with no problem)
            
-
            15:35 < jrandom> currently the message editor has "add text page" and "add html page" features... eventually we can toss in an "add page from the web..." that prompts you for a URL to fetch
            
-
            15:37 < badger> http://forum.i2p/rss_news.php
            
-
            15:38 < badger> translating that to syndie markup would probably be straightforward
            
-
            15:39 < jrandom> aye (though remember, syndie markup /is html/.  the uris are just... long and hard to read :)
            
-
            15:41 < jrandom> ok, anyone have anything else on 2) syndie dev?
            
-
            15:42 < jrandom> if not, lets jump to 3) i2phex mods
            
-
            15:43 < jrandom> strike1 / Complication: wanna give us an update?
            
-
            15:43 < strike1> I did a quick sanity check in regards to solving the connect to self problem
            
-
            15:43 < strike1> http://forum.i2p.net/viewtopic.php?t=1965
            
-
            15:44 < strike1> It seems to be working okay, but is merely preventing the local dest from being added to i2phex.hosts
            
-
            15:44 < strike1> I am also looking into the hashing problems, and the downloading issues
            
-
            15:45 < jrandom> kickass!
            
-
            15:45 < strike1> The new mods in cvs seem to make for a slightly better i2phex so far too, I must say.
            
-
            15:48 < strike1> Hopefully between Complication, I, and anyone else who wants to help we can solve them all soon. :)
            
-
            15:49 < jrandom> wikked, thanks strike1 (& complication et al!)
            
-
            15:50 < jrandom> ok, anyone have anything else for 3) i2phex mods?
            
-
            15:51 < jrandom> if not, lets jump to 4) ???
            
-
            15:51 < jrandom> anyone have anything else they'd like to bring up for the meeting?
            
-
            15:54 < green> any chance to have a dijjer port on I2P ?
            
-
            15:55 < green> wow, don't worry, just a simple question ;)
            
-
            15:55 < jrandom> probably not (dijjer port being a large number of public squid outproxies that cache)
            
-
            15:56 < jrandom> but the ability to have content hosted when you're not online will be there with syndie
            
-
            15:56 < jrandom> (and syndie can run over i2p)
            
-
            15:56 < green> sure but how syndie can handle large content ?
            
-
            15:57 < jrandom> technically, yes, but practically, no
            
-
            15:58 < green> so using cache is not a so bad idea ?
            
-
            15:58 < jrandom> otoh, we can have syndie distributed .torrent files for torrents that are encrypted with session keys that only those authorized on syndie know
            
-
            15:59 < jrandom> there's a use case for caching large files, though i'm not sure if the freenet/dijjer caching method is the best route
            
-
            15:59 < jrandom> (no pun intended)
            
-
            15:59 < green> humm .torrent files so we have to rely on a cetral server / tracker
            
-
            15:59 < green> s/central
            
-
            16:00 < jrandom> (for instance, see http://freehaven.net/anonbib/#redblue )
            
-
            16:01 < jrandom> green: torrents can be distributed, and you can put the same data on lots of swarms
            
-
            16:01 < jrandom> but functionally, we know that torrents work for transfering truckloads of data
            
-
            16:03 < green> There isn't so much goo tracker on I2P, so currently we rely on a central server even if it's doable to distribute torrent over a lot of tracker
            
-
            16:05 < jrandom> hmm, the trackers we have are good, there just isn't that much content :)
            
-
            16:06 < strike1> I agree though looking at postman's tracker I was impressed with what I found there as opposed to last year.
            
-
            16:07 < jrandom> aye, quite
            
-
            16:07 < strike1> Lots of nice stuff :)
            
-
            16:09 < jrandom> ok, anything else for the meeting?
            
-
            16:10 < green> (baf) :)
            
-
            16:10  * jrandom winds up
            
-
            16:10  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting190.html b/www.i2p2/pages/meeting190.html
deleted file mode 100644
index 01698c69..00000000
--- a/www.i2p2/pages/meeting190.html
+++ /dev/null
@@ -1,120 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 190{% endblock %}
-{% block content %}
            I2P dev meeting, November 21, 2006
            
-
            
-
            15:02 < jrandom> 0) hi
            
-
            15:02 < jrandom> 1) Net status
            
-
            15:02 < jrandom> 2) Syndie dev status
            
-
            15:02 < jrandom> 3) ???
            
-
            15:02 < jrandom> 0) hi
            
-
            15:02  * jrandom waves
            
-
            15:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001319.html
            
-
            15:03 < jrandom> since that one is pretty short, lets jump on in to 1) net status
            
-
            15:04 < jrandom> things are looking pretty good atm, network seems pretty steady
            
-
            15:04 <+zzz> I invented a "peer capacity index"
            
-
            15:04 <+zzz> on the dashboard...
            
-
            15:04 <+zzz> so far not sure it is helpful though
            
-
            15:04 < jrandom> ah yeah, sorry, metioned that one last week - looks quite useful, thanks!
            
-
            15:05 < jrandom> interesting to see the disparity out there so clarly
            
-
            15:05 <+zzz> the idea is the ratio of high-cap routers to low-cap routers, which is obviously important to tunnel build %
            
-
            15:06 <+zzz> I'm removing routers from stats that I don't get a netdb update for in 1.5 hours but that seems too quick, I think it is skewing the stats
            
-
            15:07 < jrandom> ah, ok, that would explain it.  are you still harvesting?
            
-
            15:07 < jrandom> (or wget'ing from dev.i2p.net?)
            
-
            15:08 <+zzz> yes
            
-
            15:08 < jrandom> cool
            
-
            15:08 <+zzz> netDb.harvestDirectly=false
            
-
            15:08 <+zzz>   netDb.shouldHarvest=true, right?
            
-
            15:09 < jrandom> so the stats we've had before were largely based on routers that were so bad the user shut them down & disapeared then?
            
-
            15:09 < jrandom> right
            
-
            15:10 <+zzz> it's always been 1.5 hours, but plotting the M/N/O routers, they seem to come and go when intuitively they should stay pretty constant
            
-
            15:10 < jrandom> ah ok
            
-
            15:10 <+zzz> you can see spikes/dips in all the data that last 1.5 hours :)
            
-
            15:11 < spaetz> net seems pretty stable. Yep
            
-
            15:12 <+zzz> thats all I have for that topic
            
-
            15:12 < spaetz> I'd like to know if jrandom completely focuses on syndie nowadays or if he still looks at i2p dev.
            
-
            15:12 < spaetz> or if this is just a bit on hte backburner temporarily
            
-
            15:13  * jrandom completely focuses on syndie nowadays, but will work on i2p both when there are problems and once syndie is established
            
-
            15:13  * spaetz thanks for the information
            
-
            15:14  * spaetz is fine with this
            
-
            15:15 < jrandom> w3wt.  yeah, steadystate means syndie dev can continue, but if there are problems, of course i reprioritize
            
-
            15:15 < jrandom> ok, anyone have anything else on 1) net status?
            
-
            15:15 < Walter> I have a random question.
            
-
            15:15 < jrandom> hit me Walter 
            
-
            15:17 < Walter> Assume you have 100Mb/s BW, what kind of server would you need to saturate it as an I2P node?
            
-
            15:17 < jrandom> doesnt matter
            
-
            15:17 < jrandom> i2p does not and will not saturate 100Mbps
            
-
            15:18 < Walter> Assume one wanted to make use of available BW.
            
-
            15:18 < jrandom> you would not.
            
-
            15:19 < spaetz> I've got 150kbs up and down and it uses like 25% of a vserver (Dell shared with a dozen others)
            
-
            15:19 < jrandom> that exceeds the capacity of the entire network
            
-
            15:19 < spaetz> 25%CPU that is
            
-
            15:19  * spaetz admits that's not really a precise answer and shuts up
            
-
            15:20 < jrandom> the routers themselves have a mem v. throughput tradeoff, making it less likely that a router can even push > 3-350KBps
            
-
            15:20 < jrandom> (of course, that tradeoff can be tweake to allow higher rates, but thats not an issue)
            
-
            15:21 < jrandom> using bandwidth is *BAD* unless that bandwidth is being used only when necessary
            
-
            15:22 <+zzz> the network is averaging about 1.5 MBps (=12 Mbps) total traffic over the last 3 months
            
-
            15:23 < Walter> I see.
            
-
            15:24 <+fox> <LeerokKitchen> Field trip!
            
-
            15:26 < jrandom> ok, if there's nothing else for 1) net status, lets jump on over to 2) syndie dev status
            
-
            15:26 < jrandom> progress here continues, and i've been doing testing both on windows and linux
            
-
            15:28 < jrandom> current battle is on the forum management interface, though since the text interface is already embedded, all functionality is already in place
            
-
            15:29 < jrandom> not much more news to discuss on that front though
            
-
            15:30 < jrandom> anyone have any questions/comments/concerns on 2) syndie dev status?
            
-
            15:33 < jrandom> ok, lets jump on to 3) ???
            
-
            15:33 < jrandom> y'all have anything else for the meeting?
            
-
            15:34 <+fox> <blx> when will gpl java be usable with i2p=
            
-
            15:34 <+fox> <blx> ?
            
-
            15:35 < Complication3> I guess it depends on when gpl java will be usable on various distros
            
-
            15:35 < Complication3> Or available for download from Sun
            
-
            15:36 < Complication3> But it feels like a moot point, since it's the same Java which is usable already now
            
-
            15:36 < Complication3> GPL would only let it be packaged more conveniently, and improved upon
            
-
            15:37 < jrandom> (and i2p already works with gcj/kaffe, though not all of the client apps)
            
-
            15:37  * Complication3 quickly reads backlog
            
-
            15:37 < jrandom> ((and syndie works with gcj/kaffe completely))
            
-
            15:38 <+fox> <blx> Compilation, thats what they want you to think ;)
            
-
            15:38 <+fox> <blx> but ok, i got my question answered.
            
-
            15:38 <+fox> <blx> Complication even. misread
            
-
            15:39 < Complication3> blx: well, the sources are available already now, it's just that few read and compile them
            
-
            15:39 < jrandom> (and you can even modify and use those modifications, you just can't distribute your mods)
            
-
            15:40 < koff> when will i2p have the logging functionality suggested by the proposed laws i heard about?
            
-
            15:41 < jrandom> never
            
-
            15:41 <+zzz> hahahaha
            
-
            15:41  * Complication3 suspects never :)
            
-
            15:41 <+fox> <blx> what laws?
            
-
            15:41  * jrandom assumes you refer to .de/.eu data retention issues
            
-
            15:41 < Complication3> Someone in the forum talked of a (proposed) law in Germany
            
-
            15:42 < jrandom> (and then the .us ones in a few years)
            
-
            15:42 < Complication3> They could have spelled it out better though
            
-
            15:42 < jrandom> aye, 'tis just proposed, but not a big suprise
            
-
            15:43 < Complication3> I personally think: it's not like data retention laws aren't being broken left and right already
            
-
            15:43 < Complication3> Breaking a dozen more of them? I personally wouldn't care much...
            
-
            15:44 < Complication3> In short, I want to see how they're going to enforce it
            
-
            15:44 < tea> like they did with napster : arrest everyone
            
-
            15:45 < Complication3> If they manage to make a good try, something will need to be found to thwart that ("not in my country" peering principle for countries where insanity prevails)
            
-
            15:45 <+fox> <LeerokLacerta> That reminds me of a song.
            
-
            15:45 <+fox> <LeerokLacerta> http://2ch.ru/mu/src/1163070550597.mp3
            
-
            15:46 < tea> turning all data traffic over to anonymous networks might help ...
            
-
            15:47 < Complication3> Just ignoring them en masse has worked for plain ordinary pirates...
            
-
            15:47 < Complication3> You can arrest one person ignoring you. Can't do that with several hundred thousand.
            
-
            15:47 < tea> that's no argument for a german :)
            
-
            15:47 <+fox> <modulus> you can
            
-
            15:47 <+fox> <modulus> hitler did
            
-
            15:48 < Complication3> That's only because nobody bothered removing him
            
-
            15:48 < jrandom> *cough*
            
-
            15:48 < Complication3> Had they taken up arms, it wouldn't have worked
            
-
            15:48 < Complication3> (sorry, far off topic, yes)
            
-
            15:48 < tea> still, one does feel important in being paranoid
            
-
            15:48 <+fox> <modulus> that said i think i2p could comply with data retention laws without damaging anonimity, but there's no reason to do that.
            
-
            15:48 < jrandom> ok, well, i think we've addressed the i2p-related issue there ;)
            
-
            15:48 < tea> sry
            
-
            15:49 < jrandom> aye modulus
            
-
            15:49 < jrandom> (we already assume individual users are logging everything anyway, as are the isps)
            
-
            15:49 <+fox> <modulus> right, so a DR-enabled i2p wouldn't be the end of the world
            
-
            15:51 < Complication3> Someone would have to bother forking that, though... :P
            
-
            15:52  * jrandom keeps my mouth shut ;)
            
-
            15:52 < jrandom> ok, anyone have anything else for the meeting?
            
-
            15:53 < jrandom> if not
            
-
            15:53  * jrandom winds up
            
-
            15:53  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting191.html b/www.i2p2/pages/meeting191.html
deleted file mode 100644
index 5eca6091..00000000
--- a/www.i2p2/pages/meeting191.html
+++ /dev/null
@@ -1,58 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 191{% endblock %}
-{% block content %}
            I2P dev meeting, November 28, 2006
            
-
            
-
            15:14 < jrandom> 0) hi
            
-
            15:14 < jrandom> 1) Net status
            
-
            15:14 < jrandom> 2) Syndie dev status
            
-
            15:14 < jrandom> 3) ???
            
-
            15:14 < jrandom> 0) hi
            
-
            15:14  * jrandom waves
            
-
            15:14 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001320.html
            
-
            15:14 < jrandom> (sorry for the delay, small kitchen emergency)
            
-
            15:14 < gott> Hello, jrandom.
            
-
            15:15 < jrandom> heya gott
            
-
            15:15 < jrandom> ok, lets jump in to 1) net status
            
-
            15:15  * jrandom has nothing more to add for 1) net status, beyond mentioning that i've been connected to irc for 13 days now w/out discon)
            
-
            15:16 < gott> I have been able to download my favourite modernist movie Metroland from the Frenchmen in #fr via i2psnark
            
-
            15:16 < gott> Going at download rate of 4400 kb/s; upload around the same.
            
-
            15:16 < gott> 6 peers.
            
-
            15:16 < gott> Very good for the propagation of European modernist fiction.
            
-
            15:16 < jrandom> !thwap
            
-
            15:17 < jrandom> (or, if you are actually getting 4Mbps, both sides are using 0hop tunnels)
            
-
            15:17 < gott> bytes a second.
            
-
            15:18 < jrandom> anyone have anything else to bring up for 1) net status?
            
-
            15:20 < jrandom> ok, lets jump on over to 2) syndie dev status
            
-
            15:20 < gott> Is it possible to make i2p better somehow in this regard?
            
-
            15:20 < jrandom> gott: oh, you mean 4400 Bps, not kbps?
            
-
            15:20 < jrandom> then i take back the 0hop tunnel thing
            
-
            15:21 < jrandom> 4KBps is typical atm, and can be improved with better peer selection and congestion management
            
-
            15:22 < jrandom> ok, for syndie dev status, lots of progress going on, as mentioned in the notes
            
-
            15:23 < jrandom> there's still a bunch of gaps to fill, but they're largely just filling gaps, not writing new components
            
-
            15:24 < jrandom> ok, anyone have anything else on 2) syndie dev status?
            
-
            15:25 < jrandom> ok, lets jump on over to 3) ??? then
            
-
            15:26 < jrandom> anyone have anything else to bring up in this short meeting?
            
-
            15:26 < JosephLeBlanc> Do you need any money?
            
-
            15:26 < JosephLeBlanc> oh for fuck sake
            
-
            15:26 < JosephLeBlanc> well, do you need any money?
            
-
            15:27 < JosephLeBlanc> Do you want a computer?
            
-
            15:27 < JosephLeBlanc> Do you want beer?
            
-
            15:27 < JosephLeBlanc> What?
            
-
            15:27 < jrandom> atm, finances are in pretty good shape, though contributions are always appreciated, of course
            
-
            15:27 < JosephLeBlanc> Out with it
            
-
            15:27 < JosephLeBlanc> Alright, then
            
-
            15:27 <+zzz> post a bounty for emule client :)
            
-
            15:28 < jrandom> (but if you've got money burning a hole in your poket, it'd be great to snag a mac mini for osx gui testing ;)
            
-
            15:28 < jrandom> lol zzz
            
-
            15:28 < JosephLeBlanc> Not everyone is a lesbian snob who has a 40 thousand dollar student loan that needs paying off
            
-
            15:28 <+zzz> keep up the good work jr
            
-
            15:28 < jrandom> just in case that wasn't closedshop: i appreciate the interest and support, but i won't have any time to work on a file sharing app in the future
            
-
            15:29 < JosephLeBlanc> Can you implement modulus' lovesoc
            
-
            15:29 < JosephLeBlanc> ?
            
-
            15:29 < jrandom> thanks zzz, you as well (your services and code definitely help tons!)
            
-
            15:29 <+zzz> get the baf lol
            
-
            15:30  * jrandom runs to the corner
            
-
            15:30  * jrandom winds up
            
-
            15:30  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting192.html b/www.i2p2/pages/meeting192.html
deleted file mode 100644
index 6e932273..00000000
--- a/www.i2p2/pages/meeting192.html
+++ /dev/null
@@ -1,58 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 192{% endblock %}
-{% block content %}
            I2P dev meeting, December 5, 2006
            
-
            
-
            15:00 < jrandom> 0) hi
            
-
            15:00 < jrandom> 1) Net status
            
-
            15:00 < jrandom> 2) Syndie dev status
            
-
            15:00 < jrandom> 3) iToopie
            
-
            15:00 < jrandom> 4) ???
            
-
            15:00 < jrandom> 0) hi
            
-
            15:00  * jrandom waves
            
-
            15:00 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-December/001321.html
            
-
            15:01 < jrandom> (almost two hours before the meeting, too! :)
            
-
            15:01 < jrandom> ok, lets jump on in to 1) net status
            
-
            15:01 < jrandom> things are going pretty well, no big change on this front
            
-
            15:02  * jrandom has been connected to irc here for 20 days now, too (a record, i believe)
            
-
            15:03 < jrandom> not much more to add on this front though atm
            
-
            15:03 < jrandom> so, if there's nothing else on it, lets jump forward to 2) syndie dev status
            
-
            15:04 < jrandom> progress continues here, with more bits and bobs becoming workable
            
-
            15:04 < jrandom> its still quite rough though... "utilitarian", but graphically utilitarian ;)
            
-
            15:05 < jrandom> the alpha isn't imminent though, but i hope to have it ready soon
            
-
            15:07 < jrandom> in any case, more info as it comes about :)
            
-
            15:08 < jrandom> ok, lets jump briefly on over to 3) iToopie
            
-
            15:08 < jrandom> as mentioned in the notes, Thanks y'all!  :)
            
-
            15:08 < jrandom> ok, continuing on in rapid fire to 4) ???
            
-
            15:08 < jrandom> anyone have anything they'd like to bring up for the meeting?
            
-
            15:10 < jrandom> (its probably been a year or two since our last 10 minute meeting, but perhaps that's for the best)
            
-
            15:10 <+fox> <Ch0Hag> Hey wow. Totally by accident I am actually present for an I2P meeting.
            
-
            15:11 <+fox> <Ch0Hag> Hi mum!
            
-
            15:11 <+fox> <Ch0Hag> This is going in the logs right? :)
            
-
            15:11 < jrandom> heh yeah ch0 ;)
            
-
            15:12 <+fox> <Ch0Hag> Because of course my mum reads I2P meeting logs...
            
-
            15:12 < burl> i was going to ask about the licensing but i just read the answer on www.i2p (why not gpl?)
            
-
            15:13 < jrandom> gpl kills babies
            
-
            15:13  * jrandom ducks
            
-
            15:13 < burl> i have to print them out for my mum. she's not very good with computers
            
-
            15:13 < jrandom> heheh
            
-
            15:14 < burl> i've been reading all about the free software movement recently. ethically it seems bang on
            
-
            15:14 < burl> closed source is evil :)
            
-
            15:14 < jrandom> good, evil, they're all the same.  what matters here is that closed source is /insecure/ ;)
            
-
            15:15 < jrandom> (syndie license summary @ http://syndie.i2p.net/faq.html#license less religious license info for i2p @ http://www.i2p.net/licenses )
            
-
            15:15 < burl> yeah, that did cross my mind too. if some evil company stole syndie and made a "better" closed version, who'd trust it?
            
-
            15:16 < jrandom> you can't steal whats free
            
-
            15:16 < burl> yeah, but i mean made changes to the source and didn't let you see them
            
-
            15:17 < jrandom> changes to /your copy/ of the source.  my copy of the source is still exactly as it was before, and still exactly as free ;)
            
-
            15:17 < jrandom> but, yeah, i understand.  disagree, but understand
            
-
            15:18 < jrandom> all things considered, open source>>closed source, and while gpl has some nasty limits, its sufficient for many things, and open enough for security
            
-
            15:18 < burl> because no-one would trust the closed version so it could never take over in popularity
            
-
            15:20 < jrandom> aye
            
-
            15:21 < jrandom> licence rants are always good ways to fill up 10m of meeting logs ;)
            
-
            15:21 < jrandom> ok, anyone have anything else for the meeting?
            
-
            15:23 <+fox> <Ch0Hag> Well if you need more meeting time - why Java?
            
-
            15:23 <+fox> <Ch0Hag> I mean ewww!
            
-
            15:23 < jrandom> !thwap
            
-
            15:24  * jrandom winds up
            
-
            15:24  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting193.html b/www.i2p2/pages/meeting193.html
deleted file mode 100644
index b0a601f7..00000000
--- a/www.i2p2/pages/meeting193.html
+++ /dev/null
@@ -1,26 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 193{% endblock %}
-{% block content %}
            I2P dev meeting, December 12, 2006
            
-
            
-
            15:03 < jrandom> 0) hi
            
-
            15:03 < jrandom> 1) Net status
            
-
            15:03 < jrandom> 2) Syndie dev status
            
-
            15:04 < jrandom> 3) ???
            
-
            15:04 < jrandom> 0) hi
            
-
            15:04  * jrandom waves
            
-
            15:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-December/001322.html
            
-
            15:04 < jrandom> lets jump on in to 1) net status
            
-
            15:05 < jrandom> no real changes here, though its good to note that stability seems quite sufficient on irc, even with long tunnels
            
-
            15:05 < jrandom> though, of course, thats not necessarily the case for eveyone, and can vary substantially
            
-
            15:05 < jrandom> but, 'tis nice to see anyway
            
-
            15:05 < jrandom> ok, anyone have anything to bring up for 1) net status?
            
-
            15:07 < jrandom> if not, lets swing over to 2) syndie dev status
            
-
            15:07 < jrandom> lots going on here, though summarized in the mailing list post
            
-
            15:08 < jrandom> the new http server isn't in use on the syndie.i2p.net/archive/ archive yet, so you cant push up new messages atm, though you can pull (or, of course, run your own 'httpserv' and let people post)
            
-
            15:11 < jrandom> ok, anyone have anything to discuss for 2) syndie dev status?
            
-
            15:11 < jrandom> if not, lets shimmy over to 3) ???
            
-
            15:12 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            15:16 < jrandom> if not
            
-
            15:16  * jrandom winds up
            
-
            15:16  * jrandom *baf*s the meeting closed
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting194.html b/www.i2p2/pages/meeting194.html
deleted file mode 100644
index 798c7bfe..00000000
--- a/www.i2p2/pages/meeting194.html
+++ /dev/null
@@ -1,160 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 194{% endblock %}
-{% block content %}
            I2P dev meeting, December 26, 2006
            
-
            
-
            15:02 < jrandom> 0) hi
            
-
            15:02 < jrandom> 1) Net status
            
-
            15:02 < jrandom> 2) Syndie 1.000a
            
-
            15:02 < jrandom> 3) ???
            
-
            15:02 < jrandom> 0) hi
            
-
            15:02  * jrandom waves
            
-
            15:02 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2006-December/001324.html
            
-
            15:03 < jrandom> lets jump on in to 1) net status
            
-
            15:03 < Complication2> Oh, I entirely forgot it's a Tuesday
            
-
            15:03 < jrandom> things are going pretty well, as mentioned, though my router finally had a restart after a 45 day uptime
            
-
            15:04 < jrandom> (but frankly, i'd be quite happy if we could consistently get 1+ month uptimes :)
            
-
            15:04 < Complication2> Net status is a bit flakier than before for me, but that's because one of my I2P routers is having a recurring (once about 10 days) problem
            
-
            15:04 < Complication2> Other router is capable of pulling one-month uptimes, but it's not a very high-traffic router
            
-
            15:05 < Complication2> Rather modest, in fact
            
-
            15:05 < jrandom> stats.i2p has been showing a slightly reduced build success rate in the past week, but that may just be seasonal
            
-
            15:07 <+fox> <hottuna> Ive been getting some weird wrapper log messages
            
-
            15:07 <+fox> <hottuna> INFO   | jvm 1    | 2006/12/26 01:00:00 | 2006-dec-26 00:00:00 org.mortbay.util.RolloverFileOutputStream removeOldFiles
            
-
            15:07 <+fox> <hottuna> INFO   | jvm 1    | 2006/12/26 01:00:00 | INFO: Log age 2006_09_26.request.log
            
-
            15:07 <+fox> <hottuna> INFO   | jvm 1    | 2006/12/26 01:00:00 | 2006-dec-26 00:00:00 org.mortbay.util.RolloverFileOutputStream removeOldFiles
            
-
            15:07 < jrandom> irc is still doing pretty well though, even with 3 hop tunnels
            
-
            15:07 < jrandom> oh interesting hottuna, sounds like some verbose commons-logging stuff
            
-
            15:08 < jrandom> (jetty uses their own logger, not ours)
            
-
            15:08 <+fox> <hottuna> nothing to worry about then .. 
            
-
            15:08 <+fox> <hottuna> but still ahven been running my router due to BW starvation
            
-
            15:09 < jrandom> starvation being "not enough bw for i2p", or "i2p using too much bw"?
            
-
            15:11 <+fox> <hottuna> Well, both but since Im running i2p to donate bw the first alternative fits me best
            
-
            15:11 < jrandom> ah heh, ok
            
-
            15:11 <+fox> <hottuna> I just started syndie for the first time and Im feling a bit overwhelmed, dont really know where to begin
            
-
            15:11 <+fox> <hottuna> nice touch with adding the standard archive though
            
-
            15:13 < jrandom> thanks :)  there's lots that we need to do to reduce the overwhelmed sensation, though lets do that in our jump to 2) Syndie 1.000a :)
            
-
            15:13 < jrandom> 1.000a is out, download and enjoy!
            
-
            15:14 < jrandom> out of box experience should basically be: install, start, "add the standard archive", tell Syndie to sync with the standard archive "now" (then hit save), and it'll start pulling messages
            
-
            15:15 < jrandom> it'll add a line to that table below the save button, one per message and one per forum - right clicking on messages & forums brings them up, or you can browse via the Forum->Read all menu
            
-
            15:15 < bar> congratulations on the syndie alpha release, you've been working long and hard on this. respect.
            
-
            15:16 < Complication2> Same here. Impressive database and quite promising interface. :)
            
-
            15:16 <+fox> <hottuna> Im using syndie right now and reading the epic syndie and i2p direction post
            
-
            15:16 < gloin> btw, build.xml contains a hardcoded value: build.xml:    <property name="swt.win32" value="../swt-I20061214-1445-win32-win32-x86/swt.jar" />
            
-
            15:16 < jrandom> thanks, there's lots to do to get syndie where it needs to be, but its a start
            
-
            15:17 <+fox> <hottuna> there is much work to be done on the usability front but still you have come a long way
            
-
            15:17 < jrandom> gloin: aye, 3 of 'em (swt.win32, swt.osx, and swt.linux32) - they're only used for "ant dist"
            
-
            15:18 < Complication2> does "ant" default to "ant clean jar", by the way?
            
-
            15:18  * Complication2 checks
            
-
            15:18 < jrandom> hottuna: thats where you (and y'all :) come in - my head is deep in the innards of syndie, so its often hard for me to get the right perspective for making syndie more usable
            
-
            15:19 < jrandom> i need your opinions, feedback, and suggestions to improve things
            
-
            15:19 < Complication2> Aha, dependency check and jar
            
-
            15:19 < Complication2> (without the cleanup part)
            
-
            15:19 < jrandom> right Complication2, no 'clean' by default
            
-
            15:21 < gloin> does "ant dist" build versions for linux, win32 and so on?
            
-
            15:21 < jrandom> gloin: yeah, building installers, .exe files, etc
            
-
            15:22 < jrandom> if you just want to build and run syndie for your own use, "ant jar" and copy the lib/syndie.jar to your syndie install, or "ant run" to launch it in place
            
-
            15:23 < Complication2> darn, I overlooked the "run" target then
            
-
            15:23 < jrandom> (specifying the necessary -Dswt.dir=/blah flags, or placing them in the (new) file nbproject/private/private.properties as swt.dir=/blah/)
            
-
            15:23 < Complication2> Cooked up a run.sh :D
            
-
            15:24 < Complication2> two-liner, though, so nothing time-consuming
            
-
            15:24 < jrandom> that works too :)
            
-
            15:24 < Complication2> Yep, "ant run" worked nicely
            
-
            15:24 < gloin> ant run seem to work, the install linux32.exe complains about missing swt.
            
-
            15:24 < Complication2> Just tested
            
-
            15:26 < jrandom> hmm gloin, and swt.jar exists in the installed syndie lib dir?
            
-
            15:27 < gloin> yes.
            
-
            15:28 < jrandom> and you're running "java -jar /some/path/to/that/syndie/bin/syndie.exe"?  or do you mean the linux installer?
            
-
            15:29 < gloin> the installer was fine. it created the syndie-1.000a directory.
            
-
            15:31 < gloin> Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3235 in java.library.path
            
-
            15:33 < Complication2> One little question (I'm testing out the Linux binary)
            
-
            15:33 < jrandom> hmm, did it create the libswt-pi-gtk-3235.so in /tmp/ gloin?
            
-
            15:33 < Complication2> Where to obtain the public key "393F2DF9"?
            
-
            15:33 < jrandom> thats a good question... 
            
-
            15:34 < gloin> who? when?
            
-
            15:34 < gloin> at the moment, theres no  libswt-pi-gtk-3235.so in /tmp/
            
-
            15:35 < jrandom> gloin: the new swt (3.3M4) shipped with syndie extracts the native libs to /tmp/ when it can't find them
            
-
            15:36 < jrandom> gloin: can you run (cd ~/syndie-1.000a/ ; java -cp lib/syndie.jar:lib/swt.jar:lib/hsqldb.jar syndie.gui.SWTUI ) and see if that finds them?
            
-
            15:36 < jrandom> Complication2: it'll be up on the various keyservers and the website after the meeting
            
-
            15:37 < Complication2> Thanks :)
            
-
            15:37 < jrandom> (its on my keyrings which aren't accessible from my windows box)
            
-
            15:37 < Complication2> Meanwhile, I found out using more conventional means that my download of the binary *did* abort early
            
-
            15:37  * Complication2 fetches the end again
            
-
            15:38 < gloin> no. Maybe I rebuild the the installer
            
-
            15:39 < jrandom> gloin: could you check the swt.jar to make sure it contains the libswt-pi-gtk-3235.so (jar tvf lib/swt.jar)?
            
-
            15:40 < jrandom> in any case, we'll keep on debugging as things come up
            
-
            15:41 < gloin> it's not in it.
            
-
            15:41 < jrandom> thats about it for syndie 1.000a - there will of course be updates over time, and they'll be announced in meetings or mails
            
-
            15:42 < jrandom> (there are much smaller downloads for upgrading syndie than the full 4-5+MB ones - see syndie.i2p.net/download.html)
            
-
            15:42 <+fox> <hottuna> whats is the i2p syndie archives url on the i2p network ?
            
-
            15:43 < jrandom> gloin: could you priv msg me the jar tvf output?
            
-
            15:43 < jrandom> hottuna: http://archive.syndie.i2p/
            
-
            15:43 <+fox> <hottuna> thank you
            
-
            15:45 < jrandom> (note that archive.syndie.i2p / syndie.i2p.net:8080 are just instances of syndie with the built-in HTTP server running)
            
-
            15:45 <+fox> <hottuna> oh :) wicked :)
            
-
            15:45 <+fox> <hottuna> oh btw the syndie clock doesnt match the clock on my system
            
-
            15:46 < jrandom> so, anyone can run their own syndie archive and let people sync off 'em - just give them a link to your archive (which you can do via irc/html/etc, or in syndie itself with an 'archive link'/reference)
            
-
            15:46 < jrandom> syndie clock?
            
-
            15:46 <+fox> <hottuna> or the time stamps on messages in syndie
            
-
            15:47 <+fox> <hottuna> wait a second. . now they seem to be right..
            
-
            15:47 <+fox> <hottuna> a restart later
            
-
            15:52 < gloin> how do I build a headless archive server? I assume that the import.cgi is not 'supported' anymore?
            
-
            15:53 < jrandom> right, import.cgi is incompatible with the latest - you can run a headless server with a normal syndie install by running syndie "--cli", causing it to run the text engine. 
            
-
            15:55 < jrandom> the integrated http server can be run from the text engine via the 'httpserv' command (http://syndie.i2p.net/manual.html#general_httpserv )
            
-
            15:55 < gloin> thanks a lot.
            
-
            15:56 < jrandom> if you're going to be firing up your archive again, i should be thanking you :)
            
-
            15:57 < gloin> puh.. even with a gui, it looks complicated :)
            
-
            15:58 < jrandom> aye, y'all've got your work cut out for you - help make it usable and useful :)
            
-
            15:59 < jrandom> we'll have lots more to cover as people start kicking the tires and issues start coming up, but for the time being, feel free to dig in, post away, and see whats going on
            
-
            15:59 < jrandom> shimmying on over to 3) ???, anyone have anything else to bring up for the meeting?
            
-
            16:00 < Complication2> Tested the Linux binary installer, runs nicely
            
-
            16:00 < Complication2> It's only curious that when it tried creating a shortcut in the KDE menu, the shortcut ended up in the group "Development"
            
-
            16:00 < Complication2> Along with NetBeans and stuff
            
-
            16:01 < Complication2> I might be mistaken, but I think I recall it writing that it was going to try creating a group called Syndie...
            
-
            16:01 < jrandom> ah, yeah.  izpack and the java packagers/installers are still working through the kde integration
            
-
            16:02 < Complication2> Anyway, small detail
            
-
            16:02 < Complication2> But wanted to mention just in case
            
-
            16:02 < jrandom> it /should/ create a Syndie group, but as you can see, the kde menu doesn't have per-app folders (it has categories of apps, and then per-app folders)
            
-
            16:02 < jrandom> hopefully to be fixed when izpack fixes it (its on their radar)
            
-
            16:03 < Complication2> Right
            
-
            16:03 < Complication2> Either way, the shortcut appeared, and the uninstaller shortcut appeared too
            
-
            16:03 < jrandom> wewt
            
-
            16:03 < Complication2> And the uninstalled worked nicely too (used it too since I typically compile from sources)
            
-
            16:03 < Complication2> =uninstaller
            
-
            16:04 < bar> i have two questions, slightly related to each other
            
-
            16:04 < bar> 1. any plans yet on when to nuke the old syndie?
            
-
            16:04 < bar> 2. could we have an i2p gateway, syndie.i2p, to syndie.i2p.net, or would that perhaps collide with the old syndie infrastructure?
            
-
            16:05 < Complication2> On 2, I think it currently would collide
            
-
            16:06 < jrandom> hmm, i actually haven't thought about that much.  i'm tempted to say "nuke it, move everyone to the new syndie now now now" :)
            
-
            16:07 < Complication2> ...going to "http://archive.syndie.i2p" through "localhost:4444"
            
-
            16:07 < bar> the reason i'm asking is, it's sometimes a bit of a pain having to use squid.i2p to access the syndie web pages
            
-
            16:07 < jrandom> ah, understood.  ok, i can redirect syndie.i2p to point to syndie.i2p.net, and old-syndie users can still use syndiemedia.i2p
            
-
            16:09 < bar> loverly :)
            
-
            16:09 < Complication2> oh, you meant the web pages
            
-
            16:10 < Complication2> I thought you meant the archive :)
            
-
            16:10 < bar> correct Complication2, sorry for not being clear on that
            
-
            16:10 < gloin> the own forum is the own identity?
            
-
            16:11 < Complication2> There's definitely a default identity / pseudonym created in a new Syndie instance
            
-
            16:11 < Complication2> I'm not sure if it auto-creates a forum
            
-
            16:11 < jrandom> gloin: every identity has a forum (and every forum is owned by an identity)
            
-
            16:12 < jrandom> a forum, in syndie, is just a public key
            
-
            16:12 < jrandom> (as is an author)
            
-
            16:12 < Complication2> I've forgotten how I went about doing it, and it was in October with the text interface anyway, I think :)
            
-
            16:12 < jrandom> ((in the database and code, they're both called 'channels', but the ui talks about forums and authors/nyms))
            
-
            16:13 < bar> on the topic of closing down the old syndie, may i suggest something along the lines of "keeping it online for another month but closing the archive for new posts, along with leaving an informative note"
            
-
            16:14 < gloin> the gui let me create forums only. Does that  means, when I a want that you can post in my forum I authorize the jrandom forum and not the jrandom person?
            
-
            16:15 < Complication2> Or perhaps even leaving it open for a short while after posting the note, so if someone desperately needs it at this stage (gasp!) they can exchange some data for a short while still
            
-
            16:15 < jrandom> gloin: forums and identities are the same thing - when you create a new forum, you craete a new ientity (and to authorize jrandom the person to post in your forum, authorize jrandom's forum)
            
-
            16:15 < jrandom> seems reasonable Complication2 & bar
            
-
            16:17 < jrandom> gloin: this stuff is definitely not-obvious, and we need to do a lot of work on making it easier
            
-
            16:21 < Complication2> Oops, I've not noticed multiple suggestions for I2Phex tuning by striker on the old Syndie
            
-
            16:21  * Complication2 makes local copies
            
-
            16:23 < jrandom> :)  the old syndie will still remain accessible at syndiemedia.i2p/ and syndie.i2p.net:8000/ 
            
-
            16:23 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:25 < gloin> In the forum configuration I can set the privay level (all/auth/passphrase). But with each post I can set it, too. Which counts?
            
-
            16:27 < jrandom> both count, though for the time being, i'd recommend keeping the forum privacy as 'public' (since i havent written up the gui for passphrase protected forums yet, only passphrase protected messages)
            
-
            16:27 < jrandom> the forum privacy covers the forum's metadata (links to other sites, bundled keys, etc), while individual messages have their own policy
            
-
            16:33 < jrandom> (syndie.i2p --> syndie.i2p.net as of now, syndiemedia.i2p still points to syndie.i2p.net:8000/)
            
-
            16:33 < jrandom> ok, if there isn't anything else for the meeting
            
-
            16:33  * jrandom winds up
            
-
            16:33  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting195.html b/www.i2p2/pages/meeting195.html
deleted file mode 100644
index 73d33ee5..00000000
--- a/www.i2p2/pages/meeting195.html
+++ /dev/null
@@ -1,78 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 195{% endblock %}
-{% block content %}
            I2P dev meeting, January 2, 2007
            
-
            
-
            15:02 < jrandom> 0) hi
            
-
            15:02 < jrandom> 1) Net status and plans
            
-
            15:02 < jrandom> 2) Syndie 1.001a
            
-
            15:02 < jrandom> 3) ???
            
-
            15:02 < jrandom> 0) hi
            
-
            15:02  * jrandom waves
            
-
            15:02 < jrandom> weekly status notes posted up on http://dev.i2p.net/pipermail/i2p/2007-January/001325.html
            
-
            15:03  * mrflibble waves to jrandom
            
-
            15:03  * jrandom expects most are still nursing their hangovers, so we'll do this quietly
            
-
            15:04 < jrandom> lets jump on in to 1) Net status and plans
            
-
            15:05 < jrandom> as mentioned in the notes, there's been a lot covered, but we've got our work cut out for us this year
            
-
            15:05 < jrandom> we'll want to discuss the various tradeoffs though and make sure the most appropriate ones are taken to support the specific functionality we're driving towards
            
-
            15:06 < jrandom> but, we'll see how it goes as things progress
            
-
            15:06 < jrandom> for the time being though, the net seems fairly steady-state, which is Good
            
-
            15:07 < jrandom> anyone have anything they'd like to bring up re: net status and plans?
            
-
            15:09 < jrandom> if not, lets hop on over to 2) Syndie 1.001a
            
-
            15:09 < z^z> anything I can work on on the net - netdb or tunnels?
            
-
            15:09  * jrandom hops back
            
-
            15:10 < z^z> I know we have questions on netdb propagation and on cpu usage but I would need a good pointer to get started
            
-
            15:11 < z^z> think about it anyway
            
-
            15:11 < jrandom> z^z: netDb search when the # of known/reachable floodfill peers reaches 0 needs to, most likely, do a random iterated walk across known peers
            
-
            15:12 < z^z> ok thx will poke around and ask questions later
            
-
            15:12 < jrandom> perhaps a new flag on the netDb lookup message asking for "give me some floodfill peers"
            
-
            15:12 < jrandom> kickass z^z!  that'd likely have a substantial impact for new users - let me know if you run into any trouble
            
-
            15:13 < z^z> ha that will take me into new territory sounds like fun for the new year
            
-
            15:13 < jrandom> :)
            
-
            15:14 < bar> "do not delete floodfill peer router infos from netdb if there are too few of them" <-- does anyone remember if this one got into cvs or not?
            
-
            15:15 < jrandom> nope
            
-
            15:15 < jrandom> or, not that i recall...
            
-
            15:16 < bar> okie
            
-
            15:17 < jrandom> (a great spot for that would be KademliaFloodfillNetworkFacade::dropAfterLookupFailed)
            
-
            15:18 < jrandom> er, KademliaNetworkDatabaseFacade, that is (floodfill extends it)
            
-
            15:20 < jrandom> (there's also a few bits in the DatabaseLookupMessage that could be used to flag 'send me floodfill peers' - the 'tunnelSpecified' is a boolean, but transferred in a full byte)
            
-
            15:21 < jrandom> ok, anything else on 1) Net status and plans?
            
-
            15:23  * jrandom resumes the hopping to 2) Syndie 1.001a 
            
-
            15:24 < jrandom> she's coming soon, maybe in a day or two.  lots of bugfixes and cleanup (thanks to everyone helping!), with more details in the announcement when its released
            
-
            15:25 < jrandom> thats about it to mention on that, though (but if you're using the new syndie, you can follow up on the latest discussions there ;)
            
-
            15:27 < jrandom> anyone have anything to bring up on syndie 1.001a, or shall we skip on over to 3) ???
            
-
            15:27 < jrandom> anyone have anything else they'd like to discuss in the meeting?
            
-
            15:28 <+fox> <covracer> are you still not in favor of an ebuild?
            
-
            15:29 < jrandom> for syndie, or i2p?  
            
-
            15:29 <+fox> <covracer> i2p
            
-
            15:29 < jrandom> correct, i am still not in favor of an ebuild
            
-
            15:29 < jrandom> (thank you for the offer/suggestion though!)
            
-
            15:30 < jrandom> i2p's problems are not related to the size of the network, so increasing the size will not address them
            
-
            15:30 < jrandom> instead, it will just force more people to deal with the problems and the upgrade path to address them
            
-
            15:30 <+fox> <covracer> yeah
            
-
            15:31 <+fox> <covracer> alex has done some good work though on an ebuild
            
-
            15:31 <+fox> <covracer> it's in the java-experimental-migration overlay iirc
            
-
            15:31 <+fox> * godmode0 is back (gone 01:57:51)
            
-
            15:32 <+fox> <covracer> well at any rate it depends on lots improvements in gentoo's handling of java and jetty
            
-
            15:32 <+fox> <covracer> and won't get into the main tree any time soon
            
-
            15:33 < jrandom> cool (that alex's work is going well), and hopefully we'll get i2p to the point where pushing it to main will be a great thing :)
            
-
            15:34 <+fox> <covracer> would a ebuild for syndie be welcomed or should it also be postponed?
            
-
            15:34  * jrandom wonders how much shakeup there is going to be in java handling once the sun jvm & libs go gpl
            
-
            15:35 < jrandom> syndie will hopefully be ready for full production use in a matter of months, with beta in maybe a month, so looking at an ebuild there would be great
            
-
            15:36 < jrandom> when syndie goes production i'd like to make it as easy as possible for people to use - apt-get, emerge, rpm, etc
            
-
            15:36 <+fox> <covracer> okay, I'll see if I can hack an ebuild together this week of vacation--I've got nothing better to do
            
-
            15:36 < jrandom> kickass, thanks covracer!
            
-
            15:37 <+fox> <covracer> easy installation is very important for wide adoption
            
-
            15:37 < jrandom> (and let me know if you run into any bits that could be simplified 'upstream' - i'd like to make packaging as transparent as possible)
            
-
            15:37 < jrandom> aye, definitely
            
-
            15:38 <+fox> <covracer> alright, although I'm only vaguely aware of the best practices of ebuild writing, not being a dev myself or really all that active on the coding front
            
-
            15:40 < jrandom> cool, you likely know more about ebuild writing than I though :)  good luck, and thanks
            
-
            15:40 < jrandom> ok, anyone have anything else they'd like to bring up for the meeting?
            
-
            15:40 < bar> well, i think an official post in cervantes' syndie forum and the old syndie wouldn't hurt, if/when you're looking for more testers for the new syndie
            
-
            15:40 < bar> except for the last meeting log, i don't think there has been much mentioning of the alpha release, many i2p users simply haven't heard the news, methinks
            
-
            15:41 < jrandom> good idea - i'll spam 'em when 1.001a is out
            
-
            15:42 < bar> alritey :)
            
-
            15:47 < jrandom> ok, if there isn't anything else for the meeting...
            
-
            15:47  * jrandom winds up
            
-
            15:47  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting196.html b/www.i2p2/pages/meeting196.html
deleted file mode 100644
index 11c57832..00000000
--- a/www.i2p2/pages/meeting196.html
+++ /dev/null
@@ -1,117 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 196{% endblock %}
-{% block content %}
            I2P dev meeting, January 9, 2007
            
-
            
-
            15:07 < jrandom> 0) hi
            
-
            15:07 < jrandom> 1) Net status
            
-
            15:07 < jrandom> 2) I2Phex 0.1.1.38
            
-
            15:07 < jrandom> 3) Syndie progress
            
-
            15:07 < jrandom> 4) Syndie bug harvesting contest
            
-
            15:07 < jrandom> 5) ???
            
-
            15:07 < jrandom> 0) hi
            
-
            15:07  * jrandom waves
            
-
            15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-January/001328.html
            
-
            15:09 < jrandom> while y'all continue drooling over the macworld stuff, lets jump on in to 1) net status
            
-
            15:09 < jrandom> i don't have anything to mention here this week, but felt bad not including the net status in the report, so here it is
            
-
            15:09 < jrandom> anyone have anything to add regarding the network status?
            
-
            15:09 <+zzz> I'm testing a couple of i2psnark tweaks, nothing major
            
-
            15:10 < jrandom> ah cool, regarding the recent bug reports, or other goodies we can look forward to?
            
-
            15:11 <+zzz> other - mostly better handling of torrents with > 4 peers
            
-
            15:11 < jrandom> wikked
            
-
            15:11 <+zzz> also catching a couple of common OOM spots rather than dumping the whole JVM
            
-
            15:12 < tea> sounds great, atm i2p-bt seems the best choice for "high"-speed torrents
            
-
            15:12 <+zzz> i.e where it grabs a whole 256KB - 1MB chunk to store a piece
            
-
            15:13 <+zzz> everybody pick a torrent and pile onto it to help me test :)
            
-
            15:14 < jrandom> kickass, let us know when we should try things out zzz
            
-
            15:14 < tea> shall someone redo 'casino royale' ? :)
            
-
            15:14  * jrandom mentions that this meeting is logged and posted on the web ;)
            
-
            15:15 <+void> oh, the meeting
            
-
            15:15 < tea> no volunteers, then
            
-
            15:16 < jrandom> ok cool, anyone have anything else for 1) Net status?
            
-
            15:17 < bar> while we're mentioning i2psnark...
            
-
            15:18 < bar> ...would it be possible to start, stop and restart i2psnark from the console?
            
-
            15:18 < bar> (rather than restarting the whole router to kill the tunnels)
            
-
            15:19 <+zzz> don't know - jrandom you have any thoughts?
            
-
            15:20 < jrandom> bar: when you say stop and start, what does that entail beyond stopping and starting the inividual torrents?
            
-
            15:21 < bar> killing the i2psnark tunnels that are draining my resources when not torrenting
            
-
            15:22 < bar> (the tunnels don't die when you remove the .torrents, iirc)
            
-
            15:22 < jrandom> ah, stopping the actual i2p destination for it.  doable without much trouble, the web interface has access to the SnarkManager
            
-
            15:23 < jrandom> (an interim workaround could be to set the tunnel lengths to 0 until you need to use them again)
            
-
            15:23 < jrandom> but you're right, that would be useful
            
-
            15:23 <+void> you could change the tunnels to have 0 depth, although that would be error prone
            
-
            15:23 <+zzz> good idea to provide a stop tunnel button on the web page, agreed
            
-
            15:23  * jrandom !hi5s void
            
-
            15:24 <+void> ack, i'm lagging *that* much?
            
-
            15:24 < jrandom> I2PSnarkUtil already has a static .disconnect() too
            
-
            15:25 < jrandom> (so calling that from the I2PSnarkServlet should be trivial)
            
-
            15:25 < jrandom> zzz: you wanna hit that, or you want me to toss that in there?
            
-
            15:27 <+zzz> I don't see a question there so take it
            
-
            15:27 < jrandom> ok cool, shall do
            
-
            15:27 < jrandom> ok, anyone have anything else on 1) Net status?
            
-
            15:29 < jrandom> if not, lets hop over to 2) I2Phex 0.1.1.38
            
-
            15:29 < jrandom> Complication: wanna pelt us with the low down?
            
-
            15:31 < jrandom> afaik, there's a good summary of changes in the CVS and announcement (http://forum.i2p.net/viewtopic.php?t=2005)
            
-
            15:33 < tea> is there a possibility of permantly changing the tunnel lengths ?
            
-
            15:34 < jrandom> sure, i recall there's a place where you can set them in the i2phex config file by specifying the custom i2p options (though i don't recall the i2phex config file option to use at the moment)
            
-
            15:35 < bar> tea: yes, in i2phex.cfg (i2pInboundLength, i2pInboundLengthVariance, i2pOutboundLength, i2pOutboundLengthVariance)
            
-
            15:36 < tea> i was thinking of the option tab i2p-rufus has
            
-
            15:37 < tea> could something like that be added ? 
            
-
            15:38 < jrandom> i think complication said that'd be a good idea, so its probably pretty doable
            
-
            15:38  * jrandom hasn't done any gui hacking in i2phex (though I'm sure if you sent in a patch, I'd make sure it went in :)
            
-
            15:38 < jrandom> oh, nm, seems complication said 'e's working on it
            
-
            15:39 < jrandom> http://forum.i2p.net/viewtopic.php?t=2005#9149
            
-
            15:39 < tea> as an amateur rufus user i was pleased to see the pop up question 'allow zero hop connections ?', and be able to click no ...
            
-
            15:42 < jrandom> aye.  ok, anyone have anything else on 2) I2Phex 0.1.1.38?
            
-
            15:42 < bar> well, while we're at it, i think congratulations to the original Phex team on their 3.0 release are in order, it came out just the other day :)
            
-
            15:43  * bar waves
            
-
            15:43 < jrandom> aye, congrats ArneBab et al!
            
-
            15:45 < tea> maybe they'll wave back one day ...
            
-
            15:46 < jrandom> ArneBab and GregorK have had some good feedback on i2phex over the years 
            
-
            15:46 <+void> the day that i2phex reaches version 3.0?
            
-
            15:46 < jrandom> here's hopin :)
            
-
            15:47 < bar> we'll be long gone by then, but yeah :)
            
-
            15:48 < jrandom> ok, lets jump on over to 3) Syndie progress
            
-
            15:48 < jrandom> lots of progress in the last week, including 1.001a hitting the street
            
-
            15:50 < jrandom> though most of the discussion on that front is going on within syndie itself
            
-
            15:50 < jrandom> so, if you're not on it yet, get on it and find out more :)
            
-
            15:51 < jrandom> anyone have anything they'd like to discuss regarding syndie?
            
-
            15:53 <+void> well, i just ran sync and it imported one unread message with a bunch of read ones
            
-
            15:53 <+void> but i guess we'll debug that after the meeting?
            
-
            15:54 < jrandom> hmm, aye, quite strange (i imported a few new messages recently, and they showed up as unread).  but yeah definitely need to dig some more into that
            
-
            15:54 < jrandom> ok, lets hop on over to 4) Syndie bug harvesting contest
            
-
            15:55 <+void> can you register anonymous egold accounts?
            
-
            15:55 < jrandom> aye, no ID necessary
            
-
            15:56 <+void> ah, cool
            
-
            15:56 < jrandom> though, of course, they can freeze fraudulent accounts, and they do track all the transfers, and share the transfer data with Them
            
-
            15:56 < jrandom> but it is more than sufficient to defend against most adversaries
            
-
            15:57 <+void> yeah, naturally
            
-
            15:58  * jrandom has found the bug reports and feature requests invaluable, and while I realize the $50USD doesn't come close to compensate the actual time involved, its hopefully a small token of thanks
            
-
            15:58 < jrandom> I'm hoping we'll continue this contest every month
            
-
            15:58 <+void> hehe
            
-
            15:59 <+void> heheat least it's fun time
            
-
            15:59 <+void> arg
            
-
            16:00 < jrandom> does anyone have any questions regarding the contest, or suggestions, or frisbees?
            
-
            16:01 <+tethra> contest?
            
-
            16:01 <+tethra> (i am late)
            
-
            16:01  * tethra reads up
            
-
            16:01 <+tethra> cool :o
            
-
            16:02 < jrandom> so get yer bug reports flowin' :)
            
-
            16:03 < jrandom> ok, lets swing on over to 5) ???
            
-
            16:03 <+void> they already are :)
            
-
            16:03 <+tethra> yessir! ;)
            
-
            16:03 < jrandom> aye, thanks!  (yes, I'm counting everything from jan1 to jan31 :)
            
-
            16:03 < jrandom> ok, anyone have anything else to bring up for the meeting?
            
-
            16:04 <+fox> <nony> does it run on java6?
            
-
            16:04 < tea> sure
            
-
            16:04 <+tethra> come to that, does it compile with gcj?
            
-
            16:04 < jrandom> nony: i run it on java6 here, yes
            
-
            16:04 < jrandom> tethra: aye, and runs ;)
            
-
            16:04 <+tethra> excellent
            
-
            16:04 <+tethra> ;)
            
-
            16:04 <+fox> <nony> sweet
            
-
            16:07 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:09 < jrandom> if not...
            
-
            16:09  * jrandom winds up
            
-
            16:09  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting197.html b/www.i2p2/pages/meeting197.html
deleted file mode 100644
index 87441dcb..00000000
--- a/www.i2p2/pages/meeting197.html
+++ /dev/null
@@ -1,39 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 197{% endblock %}
-{% block content %}
            I2P dev meeting, January 16, 2007
            
-
            
-
            15:03 < jrandom> 0) hi
            
-
            15:03 < jrandom> 1) Net status
            
-
            15:03 < jrandom> 2) I2PSnark updates
            
-
            15:03 < jrandom> 3) Syndie progress
            
-
            15:03 < jrandom> 4) ???
            
-
            15:03 < jrandom> 0) hi
            
-
            15:03  * jrandom waves
            
-
            15:03 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2007-January/001329.html
            
-
            15:05 < jrandom> as y'all dig through that, lets jump on in to 1) Net status
            
-
            15:05 < jrandom> not much change at the moment on this front
            
-
            15:06 < jrandom> interesting to note the updated domains chart on http://stats.i2p/cgi-bin/serv_domain.cgi listing a good spread of hosts even after pruning 2000 old entries
            
-
            15:07 < jrandom> zzz: what period is that chart based off?
            
-
            15:07 <+zzz> 1 month
            
-
            15:07 < jrandom> wow cool
            
-
            15:09 < jrandom> of course, the NICs aren't always up to date, but it gives a good view of things from a high level.  nice work zzz, thanks
            
-
            15:10 < jrandom> ok, anyone have anything else to bring up for 1) net status?
            
-
            15:12 < jrandom> if not, lets hop on over to 2) i2psnark updates
            
-
            15:12 < jrandom> zzz, wanna give us the low down?
            
-
            15:13 <+zzz> we have improvements in fairness when > 4 leechers, a fix for the longstanding restart-torrent bug, don't start a tunnel if autostart unchecked, and adding some more links on the webpage.
            
-
            15:13 <+zzz> added a stop-all button which usually doesn't work if there is traffic, it seems
            
-
            15:13 <+zzz> looking for testers and reports as usual, thanks
            
-
            15:14 < jrandom> kickass, thanks zzz
            
-
            15:14 < jrandom> when you feel its right, we can package 'er up and ship a new 0.6.1.27 w/ that bundled
            
-
            15:15 <+zzz> ok maybe a week or 2
            
-
            15:16 < jrandom> sounds good
            
-
            15:17 < jrandom> ok lets jump on over to 3) Syndie progress
            
-
            15:17 < jrandom> logs going on in this front as mentioned, and we'll hopefully be pushing out a new rev in the next day or two
            
-
            15:19 < jrandom> there'll be an announcement when thats out, in syndie, on the web pages, on the forum, and in the list
            
-
            15:19 < jrandom> ok, swinging over to 4) ???
            
-
            15:20 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            15:23 < jrandom> if not...
            
-
            15:23  * jrandom winds up
            
-
            15:23  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting198.html b/www.i2p2/pages/meeting198.html
deleted file mode 100644
index eccb1218..00000000
--- a/www.i2p2/pages/meeting198.html
+++ /dev/null
@@ -1,63 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 198{% endblock %}
-{% block content %}
            I2P dev meeting, January 30, 2007
            
-
            
-
            15:06 < jrandom> 0) hi
            
-
            15:06 < jrandom> 1) Net status
            
-
            15:06 < jrandom> 2) Syndie status
            
-
            15:06 <+zzz> )))
            
-
            15:06 < jrandom> 3) I2PSnark status
            
-
            15:06 < jrandom> 4) ???
            
-
            15:06 < jrandom> 0) hi
            
-
            15:07  * jrandom waves
            
-
            15:07 <+fox> <mk> I just made the post, so feel free to respond
            
-
            15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-January/001331.html
            
-
            15:07 < jrandom> w3wt, shall do mk, thanks
            
-
            15:07 < jrandom> (now lets get into our archived weekly development meeting :)
            
-
            15:08 < jrandom> short set of status notes this week, but lets jump through 'em
            
-
            15:08 < jrandom> 1) Net status
            
-
            15:08 < jrandom> no real changes here, though we've had a substantial decline in build success rates as charted on stats.i2p
            
-
            15:08 < jrandom> though not the catastrophic failures we saw last summer
            
-
            15:09 <+zzz> yes, contrary to your rather sunny assessment in the notes, we hit a 3-month low in tunnel build success late last week. There has been only a modest recovery in last few days
            
-
            15:09 < Complication2> On the net status side, I've seen some increased routing pressure, which has caused about 10% of bandwidth increase, but not much more
            
-
            15:11 < jrandom> aye, thats the odd part zzz - the failure rate has substantially incrased, but irc hasn't been substantially affected
            
-
            15:11 < Complication2> It "feels" like a bit of significant routing capacity either recently left the network, or experienced downtime
            
-
            15:11 < jrandom> Complication2: hmm, there were a few nodes with hardware and network trouble, which would correlate with that
            
-
            15:12 <+zzz> from over $here irc was quite affected
            
-
            15:12 < Complication2> but I found that my stat recorder has been recording 0B files since October... so I honestly don't know
            
-
            15:12 < Complication2> had a typo in my script :O
            
-
            15:12 < jrandom> d'oh
            
-
            15:13 < jrandom> zzz: hopefully that has passed though, right?
            
-
            15:13 <+zzz> I'd say things are improving although during evenings GMT things are worse than in mornings
            
-
            15:15 < jrandom> hmm interesting
            
-
            15:15 < Complication2> if most users are still from Europe, during evenings GMT, their count could be rising...
            
-
            15:15 <+zzz> just remember weather is always sunny inside a colo :)
            
-
            15:16 < Complication2> (but I haven't checked theland.i2p lately)
            
-
            15:16 < jrandom> hehe
            
-
            15:16 < jrandom> (we have had an increase in the last few days, with known: hitting 555 earlier this afternoon, and now sitting at 570)
            
-
            15:17 < jrandom> ((active: 266/367))
            
-
            15:17 < jrandom> at least, according to my router
            
-
            15:18 < jrandom> ok, anyone have anything else for 1) Net status?
            
-
            15:20 < jrandom> if not, lets hop on over to 2) Syndie status
            
-
            15:20 < jrandom> some hefty stuff going on here, with a new release coming in the next day or two
            
-
            15:21 < jrandom> i'm doing my best to clear as many of the bugs filed as possible, and there are two major functional improvements in the upcoming release - better handling for banning, and support for a whole slew of privacy, authentication, and authorization policies for various forums
            
-
            15:23 < jrandom> when the new release is out though, there'll be more to discuss on that front (though most of that discussion is going on within syndie, naturaly :)
            
-
            15:23 < jrandom> as for the contest - there's still one more day left to file your bugs!  the winners and supporters will be announced in next week's meeting
            
-
            15:24 < jrandom> ok, anyone have any questions/comments/concerns re: syndie status?
            
-
            15:25 < jrandom> if not, lets jump on to 3) I2PSnark status
            
-
            15:25 < jrandom> zzz, wanna give us an update on things?
            
-
            15:25 <+zzz> yes
            
-
            15:26 <+zzz> at the mtg 2 wks ago I was at a good stopping point, but then I found and fixed some real memory-eaters and made some other tweaks...
            
-
            15:26 <+zzz> I'm now at a good stopping point again so folks please test CVS and report results here or in syndie - thanks
            
-
            15:27 <+zzz> on the startup thrashing...
            
-
            15:27 <+zzz> there were some good suggestions in syndie...
            
-
            15:28 <+zzz> my first idea didn't really work, but I cleaned up a lock so that the web page doesn't hang at startup anymore, so it _looks_ faster
            
-
            15:28 <+zzz> may stab at the other suggestions later. <eot>
            
-
            15:29 < jrandom> heh cool, thanks zzz!
            
-
            15:30 < jrandom> ok, lets jump to our good ol' catch-all: 4) ???
            
-
            15:30 < jrandom> anyone have anything else tobring up for the meeting?
            
-
            15:33 < jrandom> ok, if not...
            
-
            15:33  * jrandom winds up
            
-
            15:34  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting199.html b/www.i2p2/pages/meeting199.html
deleted file mode 100644
index f76b3002..00000000
--- a/www.i2p2/pages/meeting199.html
+++ /dev/null
@@ -1,241 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 199{% endblock %}
-{% block content %}
            I2P dev meeting, February 6, 2007
            
-
            
-
            15:02 < jrandom> 0) hi
            
-
            15:02 < jrandom> 1) Net status
            
-
            15:02 < jrandom> 2) Syndie dev status
            
-
            15:02 < jrandom> 3) January bug harvesting contest winners!
            
-
            15:02 < jrandom> 4) ???
            
-
            15:02 < jrandom> 0) hi
            
-
            15:02  * jrandom waves
            
-
            15:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001333.html
            
-
            15:03 < jrandom> hopping on to 1) Net status
            
-
            15:03 < jrandom> I don't really have much to add here (as you can probably tell ;)
            
-
            15:03 < jrandom> anyone have anything to bring up regarding the network status?
            
-
            15:04 <+void> used to be better, somehow...
            
-
            15:04 <+void> but not bad
            
-
            15:05 < jrandom> its odd, the last wek or so our build rates have been going back up, per stats.i2p
            
-
            15:05 < tethrage> is there a long term pattern?
            
-
            15:06 < tethrage> (in build rate change)
            
-
            15:07 < jrandom> afaics the patterns have been associated with the capacity of high powered routers, but thats only given a very limited view of the network (since i only know whats publicly available, pretty much)
            
-
            15:07 < tethrage> i see
            
-
            15:08 < tethrage> is there any information that could be provided to help?
            
-
            15:08 < tethrage> from just normal routers that is
            
-
            15:08 < jrandom> not really, from my point of view
            
-
            15:09 < tethrage> i see
            
-
            15:09 < jrandom> (basically we just need to implement some code changes before moving forward)
            
-
            15:10 < tethrage> i see
            
-
            15:11 < jrandom> ok, anyone have anything else for 1) Net status?
            
-
            15:12 < jrandom> if not, lets skip on over to 2) Syndie dev status
            
-
            15:14 < jrandom> lots going on here, as you can read
            
-
            15:14 <+fox> <mk> minor: perhaps changed 'signed by' to 'authorization'? I'm a little edgy on the blurry lines between forums, identities, signatures, and so on
            
-
            15:14 <+fox> <mk> -d
            
-
            15:15 < jrandom> ah, thats a good idea
            
-
            15:16 <+void> mk: a forum is an identity :)
            
-
            15:16 <+void> and vice versa
            
-
            15:17 < jrandom> aye, though we don't want to confuse people too much by making this odd duality visible
            
-
            15:17 <+fox> <mk> I'm aware, but it's still blurry. I grasp it just fine now, but I worry that new users might be confused by the lack of differentiation
            
-
            15:18 <+void> ah
            
-
            15:18 < jrandom> right - people think of forums differently than they think of identities, so need to make sure we behave as expected
            
-
            15:18 <+fox> <mk> something else that might be worth implementing in the forum or identity management is explicit 'post to this forum only under author x authorization y', which would eliminate mixups. you wouldn't even need a dropdown on the new post messages
            
-
            15:19 <+fox> <mk> (a dropdown for keys)
            
-
            15:20 <+void> i'd prefer a global identity dropdown that was visible at all times
            
-
            15:20 <+fox> <mk> like, who you're posting under?
            
-
            15:20 < jrandom> hmm
            
-
            15:21 <+fox> <mk> perhaps, but there really isn't much of a difference, I think, between having it on top always and having it appear on posts only
            
-
            15:22 < jrandom> ok, before we dig too deep into this, there is a side channel not currently addressed in syndie that can link multiple identities
            
-
            15:22 <+void> though your identity is not used anywhere else other than posting
            
-
            15:22 <+fox> <mk> what do you mean?
            
-
            15:23 <+void> pushing new posts?
            
-
            15:23 < jrandom> if you need to have completely unlinkable identities, you need to run separate syndie instances - you can sync them off each other, and only use one to pull/push to the other archives, but the local archive contains information that only some of the identities have access to
            
-
            15:23 <+fox> <mk> (I agree that we should probably save big discussions for the dev forum, but it is nice to have a bunch of people talking about it at once)
            
-
            15:24 <+void> true
            
-
            15:24 < jrandom> however, all of the identities on the local archive can acces that information, and if they act on it (post with those keys, etc), they'd leak the linkabiity
            
-
            15:25 < jrandom> perhaps we can find a way to accomplish all of that transparently through the gui though
            
-
            15:26 < jrandom> (running with multiple archives locally without having to fire up syndie twice)
            
-
            15:26 <+fox> <mk> there are many other issues - like marking certain archives exclusive against each other - that could help with anonymity. we should try to define all these scenarios and figure out a way to deal with them in a very usable way
            
-
            15:27 < tethrage> syndie doesn't aim for anonymity, just security
            
-
            15:27 < tethrage> it is the transport layer it runs on that should deal with that, surely? :/
            
-
            15:27 < jrandom> syndie aims for anonymity
            
-
            15:27 < tethrage> (correct me if i'm wrong)
            
-
            15:28 < jrandom> the transport layer only deals with a small portion of the anonymity - we need to deal with the rest
            
-
            15:28 < jrandom> s/small//
            
-
            15:28 < tethrage> does it? :/
            
-
            15:28 <+fox> <mk> yes, that's right. syndie deals especially with information leaks
            
-
            15:29 < jadeSerpent> ip address anonymity vs. identity anonymity
            
-
            15:29 < tethrage> i see. i thought you said a while ago syndie was meant as a secure app that employed crypto but wasn't strictly anonymous?
            
-
            15:29 < tethrage> (not in the same way as i2p etc, anyway)
            
-
            15:29 <+fox> <mk> information security is handled by the redundancy of archives
            
-
            15:29 < jrandom> mk: i'm not sure what you mean by marking the archives, but i'd love a post on the syndie dev forum discussing it :)
            
-
            15:29 < jrandom> tethra: syndie can be used for things that don't require anonymity
            
-
            15:30 < jrandom> but syndie must be usable for things that do
            
-
            15:30 < jrandom> (otherwise, there is no point to implement it as part of the i2p project)
            
-
            15:31 < tethrage> yeah
            
-
            15:31 <+void> jrandom: well, to be fair, there still would be a point if syndie provided anonymity by utilizing i2p
            
-
            15:31 <+void> but never mind
            
-
            15:31 <+void> c
            
-
            15:31 < tethrage> what, other than security against information leaks and dodgy code, does syndie do to keep people anonymous? :/
            
-
            15:32 < tethrage> surely unless specified you access the archives directly etc?
            
-
            15:32 <+fox> <mk> tethrage, information leaks of all sorts. If you'd like we can go into more detail in a bit
            
-
            15:33 < jrandom> tethra: for instance, someone accessing an eepsite with javascript enabled
            
-
            15:33 < jadeSerpent> tethrage: there's no guarantee that the posts you push to an archive originated with you, someone might have pushed them to your archive
            
-
            15:34 < tethrage> jrandom: yeah, the js can give things away and such. but surely that's more a matter of security than anonymity if you're not using an anonymous network of some variety?
            
-
            15:34 < tethrage> then again, i suppose i'm just arguing semantics, so i'll stop
            
-
            15:34 < tethrage> :/
            
-
            15:34 < jadeSerpent> i would argue running your own publically accessible archive increases your anonymity in that respect
            
-
            15:34 <+fox> <mk> jrandom, I'll make that post. Also, I've been playing around with a design for a browser (I don't like opening new tabs for new sections), so I'll try to make a prototype for it, and perhaps post some scribbles to dev
            
-
            15:34 < jrandom> "security against information leaks" is the core of anonymity - controlling who knows facts about your identity
            
-
            15:35 < jrandom> ah kickass mk, thanks!
            
-
            15:35 < jrandom> jadeSerpent: certainly
            
-
            15:35 < tethrage> i see
            
-
            15:35 < tethrage> point taken
            
-
            15:36 < jrandom> mk: if there are better ways to present the syndie ui, i'm 100% for it (only a very small portion of code is bound to these tab-based components)
            
-
            15:36 < jrandom> and we are alpha after all
            
-
            15:38 <+void> jrandom: i don't suppose it's hard to turn the tabbed interface into a windowed interface?
            
-
            15:38 <+fox> <mk> yep. and if some people prefer the tabbed-for-all approach, then there's no problem with using that
            
-
            15:38 <+fox> <mk> (alongside of the browser tab)
            
-
            15:39 < jadeSerpent> please no mdi, i suggest something halfway between tabbed and mdi, eclipse's perspectives
            
-
            15:39 <+void> mdi is bad, i agree
            
-
            15:40 < jadeSerpent> netbeans has something like that too, forget what it's called
            
-
            15:40 < jadeSerpent> views or workbenches or something, been a while
            
-
            15:41 < jrandom> .png sketches appreciated :)
            
-
            15:41  * jrandom went with the tab-for-all style because everyone loves firefox (/etc)
            
-
            15:42 < jadeSerpent> when i finish the icons i might hack on some of that
            
-
            15:42 <+fox> <mk> the 2 week release cycle is a good thing. I like seeing those goals explicit, but I'd also like to see some 'softer' goals listed - dev and later on user documentation, diagrams, and so on
            
-
            15:42 < jrandom> wikked
            
-
            15:42 < jadeSerpent> tabs are fine for now imo, they're usable
            
-
            15:42 < jrandom> mk: http://syndie.i2p.net/roadmap.html ?
            
-
            15:42 < jrandom> (though there are no dates on the roadmap)
            
-
            15:43 <+fox> <hottuna> nice :=) ... just posted about it to pending tasks :P
            
-
            15:44 <+fox> <mk> yeah, though I'm referring to smaller goals. "document the general interactions between classes in syndie.gui", or "write up a doc regarding banning" etc.
            
-
            15:44 < jrandom> ah, good point
            
-
            15:45 < jrandom> i've been meaning to collate all the small/mid/high level todo items again
            
-
            15:45  * jrandom adds that to the todo list
            
-
            15:47 < jrandom> ok, anything have anything else to bring up for 2) Syndie dev status?
            
-
            15:48 < jrandom> (of course, we've always got the dev forums in syndie, but irc is useful for quick back & forth)
            
-
            15:49 < jrandom> if not, lets jump on over to to 3) January bug harvesting contest winners! 
            
-
            15:50 < jrandom> congrats Darn, voyde, mk, and Anonymous, and thanks to everyone who helped out
            
-
            15:51  * jrandom realizes the contest was originally for the top 3, but the count was so close 
            
-
            15:51 < jrandom> there's a new contest on for this month too, same rules as before
            
-
            15:51 < jadeSerpent> how do you know "Anonymous" was only one person? ;)
            
-
            15:51 <+fox> <mk> 225 (by my count) bugs in total - impressive
            
-
            15:51 <+void> :)
            
-
            15:52 <+fox> <mk> jade, the key, I would think :)
            
-
            15:52 < jrandom> jadeSerpent: urn:syndie:meta:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=e :)
            
-
            15:53 < jrandom> it could be five people sharing that key though
            
-
            15:53 < jrandom> but then they've got to share the $50USD ;)
            
-
            15:53 < jrandom> (first one with the private key who signs a message to me specifying what egold acct to send it to wins ;)
            
-
            15:53 < jadeSerpent> unless one kills the others
            
-
            15:54 < jadeSerpent> but that kind of thing would only happen in romania
            
-
            15:54 < tethrage> and russia
            
-
            15:54 < jrandom> (and britain, and australia, and...)
            
-
            15:55 <+fox> <mk> 50usd is a lotta money...
            
-
            15:55 < jadeSerpent> in russia they'd all be killed, and the landlord would take the money and pass it on to the mob as protection fee
            
-
            15:55 < tethrage> not in gbp ;p
            
-
            15:55 <+fox> <mk> I know *I'd* kill for it
            
-
            15:55 < tethrage> i suppose asking where you're from wouldn't get an answer, mk?
            
-
            15:55 < tethrage> :/
            
-
            15:56 <+fox> <dw_g> ok, I'll take it ;)
            
-
            15:56 <+fox> <mk> russia originally :D now canada
            
-
            15:56 < jadeSerpent> 225 bugs is impressive, how many of those have been closed?
            
-
            15:56 < tethrage> ice.
            
-
            15:56 < tethrage> +n
            
-
            15:57 < jrandom> jadeSerpent: i'd thumb it at maybe 75-80% addressed
            
-
            15:57 < jadeSerpent> nice
            
-
            15:58 < jrandom> (with maybe another 5-10% invalid/wontfix)
            
-
            15:58 < jrandom> but actually, thats one of the higher level todo items - get a real management ui on the bugtracking
            
-
            15:58  * jadeSerpent recommends trac
            
-
            15:58 < jrandom> (it took me a while to walk through all the posts and count them all up manually)
            
-
            15:58 <+fox> <mk> external to syndie?
            
-
            15:59 < jrandom> hmm, with a syndie-->track exporting system?
            
-
            15:59 < jrandom> s/ck//
            
-
            15:59 <+fox> <mk> a nice project would be to hook syndie up to a bug tracker
            
-
            15:59 < jadeSerpent> yeah
            
-
            15:59  * jrandom bets a few SQL queries & inserts would do the trick
            
-
            16:00 < jrandom> it would be quite worthwhile though, at least from a readonly-trac perspective
            
-
            16:00 <+void> but syncing updates made to trac back into syndie is bound to be tricky, i think
            
-
            16:00 < jrandom> full cycle integration isvery hard
            
-
            16:00 < jrandom> right
            
-
            16:00 <+fox> <mk> at some point it might be worth considering a 'revision'-type system
            
-
            16:00 < jrandom> but being able to query & drill down in trac, and generate reports, etc
            
-
            16:01 <+fox> <mk> where posts supercede older ones
            
-
            16:01 < jrandom> ah, yeah there are hooks for that, but the Overwrite* headers aren't currently honored
            
-
            16:02 < jrandom> wouldnt be too tough though, just a UI toggle to navigate to previous revs of the same post, plus a few lines of code to verify the post is authorized to override the old post
            
-
            16:03 < jadeSerpent> i understand the desire to use syndie itself for bug reporting, but its design doesn't involve issue tracking, and it will always be sub-optimal for that task, imo you should use a real issue tracker
            
-
            16:04 <+fox> <mk> seeing the number of bugs filed, I agree with jadeSerpent
            
-
            16:05 < jrandom> though on the flip sie, how many bugs were discovered by those using syndie to file the bugs?
            
-
            16:05  * jrandom is not entirely oposed to a trac or other bug tracking system
            
-
            16:05 < jadeSerpent> those kinds of bugs are going to be discovered anyhow
            
-
            16:05 <+void> well, severities, components, versions and closing/opening/reopening bugs can be done with syndie tags
            
-
            16:05 < jrandom> right
            
-
            16:06 <+void> (and most of those already are)
            
-
            16:06 < jadeSerpent> like the other day when it froze up on someone who was posting a bug report, it would have frozen on them if they were posting about any subject, didn't matter that it was a bug report
            
-
            16:06 < jrandom> it we can feed a real issue tracker via pseudonymously (and authentic) messages, that would be great
            
-
            16:06  * jrandom has received a few private bug reports as well, which include sensitive information, - these are protected by syndie's encryption
            
-
            16:07 <+fox> <mk> well, why not keep both?
            
-
            16:08 < jadeSerpent> i agree that there is however no issue tracker designed with anonymity or more-than-trivial confidentiality in mind
            
-
            16:09 <+fox> <mk> it would be nice to have syndie have that sort of bug tracker, but anonymity isn't too great a problem when filing most bug reports
            
-
            16:10 < jadeSerpent> maybe trac could be modded to utilize syndie's features there
            
-
            16:10 <+fox> <mk> jade, it'd be hard. browsers don't implement signing
            
-
            16:12 < jrandom> hmm.  what we have is originally based off: http://syndiemedia.i2p.net:8000/blog.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003
            
-
            16:12 < jrandom> plus http://dev.i2p.net/~jrandom/bugsp1.txt and http://dev.i2p.net/~jrandom/bugsp2.txt
            
-
            16:13 < jrandom> i agree that we need something better than what we have to track these issues, and i'm open to whatever best moves us forward
            
-
            16:13 < jrandom> but i'd like to keep whatever it is minimal if possible, because we're building syndie, not a bug tracker :)
            
-
            16:14 < jadeSerpent> yeah well you seem to be managing it for now without one ;)
            
-
            16:14 < jrandom> but i'm sure some will fallbetween the cracks, and others will have a harder time finding whats known/etc, and contributing fixes
            
-
            16:15 <+fox> <mk> we probably don't even need to implement it through syndie. it's useful there to some extent, but 200+ bugs really is a lot. we should decide on a tracker and make it available through the www and through i2p
            
-
            16:16 <+fox> <mk> provide a link to it atop the syndie file a bug screen, and that way we have both options. a bug tracker implementation in syndie isn't something to be using resources on now
            
-
            16:17  * jrandom does love having bug tracking integrated (so people don't need to create bug tracking accounts, use fake email addresses, etc), but i'm open to proposals for what solution we should use
            
-
            16:17 <+fox> <mk> I think we should keep that, but also have that bug tracker
            
-
            16:18 < jadeSerpent> read-only access for the short term would be nice
            
-
            16:18 < jadeSerpent> i prefer a more bug-oriented search interface
            
-
            16:18 < jrandom> wouldn't be so bad, could perhaps write a one-way syndie-->issue tracker export without much trouble too, of r those who can't dont want to use the web based one
            
-
            16:19 < jrandom> s/of r/for/
            
-
            16:19 <+fox> <mk> integrated bug submission is a great thing to have, but we shouldn't use the syndie archive to track 200+ bugs
            
-
            16:20 < jrandom> though its great for testing our search capabilities :)  [yeah, ok, i'm convinced]
            
-
            16:20 < jrandom> so, one vote for trac.  any other votes?  please post to the syndie dev forum, with rationale, of course
            
-
            16:21 < jadeSerpent> two votes for trac, unless you've already counted mine ;)
            
-
            16:21 < jrandom> aye, thats what i was counting ;)
            
-
            16:21 <+fox> <mk> what are the options? I know nothing about trackers
            
-
            16:21 < jadeSerpent> i was hoping that was your own vote, but ok
            
-
            16:22 < jadeSerpent> i've worked with trac, great third party support
            
-
            16:22 < jadeSerpent> bugzilla i would say blah to
            
-
            16:22 < jrandom> though, as an aside, if someone is quite familiar with an issue tracker, that'd be helpful for whipping out a syndie-->issue tracker export 
            
-
            16:22 < jrandom> yeah, bugzilla is a beast
            
-
            16:22 < jadeSerpent> jira is also good, like trac
            
-
            16:23 <+void> trac is probably familiar to lots of people, too
            
-
            16:23 < jrandom> aye, and good folks too (they gave i2p a license, though we havent used it yet)
            
-
            16:23 < jadeSerpent> you have a jira license?
            
-
            16:23 < jrandom> aye, jira and fisheye
            
-
            16:24 < jadeSerpent> cool, might as well give it a shot
            
-
            16:24 < jadeSerpent> btw eclipse's mylar plugin integrates fully into bugzilla, trac, and jira
            
-
            16:24 < jadeSerpent> high praises for its interface
            
-
            16:25 < jrandom> damn this netbeans/eclipse battle
            
-
            16:25 < bar> (bugs are reported automatically when created? ;)
            
-
            16:25 < tethrage> (haha)
            
-
            16:26 <+fox> <mk> hah, nice
            
-
            16:26 < jadeSerpent> jrandom: netbeans support is on the mylar roadmap iirc
            
-
            16:26 < jrandom> cool
            
-
            16:26 <+fox> <modulus> that's what comes to those who fanatically support sun :-)
            
-
            16:27  * jrandom pelts modulus with javabeans
            
-
            16:27 < jadeSerpent> even though mylar is offically under the aegis of eclipse foundation
            
-
            16:27 <+fox> * mk can't find a live site for trac
            
-
            16:27 <+fox> <modulus> http://trac.wordpress.org/
            
-
            16:27 < jrandom> mk: http://feedspace.i2p/ atm
            
-
            16:28 <+void> http://trac.edgewall.com/
            
-
            16:29  * jrandom doesn't want to spend a lot of time evaluating lots of different systems, so if someoe wants to champion a specific system, please do so in the syndie dev forum 
            
-
            16:29 < jadeSerpent> http://overlays.gentoo.org/proj/alt/wiki
            
-
            16:29 <+void> (^ official meta-trac)
            
-
            16:29 <+fox> <mk> yeah, it's all the same to me
            
-
            16:30  * jrandom will assume thats it for * 3) January bug harvesting contest winners! and move us on to 4) ???
            
-
            16:30 < jrandom> anyone have anything else for the meeting?
            
-
            16:30 <+fox> <mk> 'best' is overrated. whoever has the most experience with these things should probably flip a coin
            
-
            16:32  * jrandom isn't really looking for a project planning / release planning system, or a source code browser (a free wiki doesnt hurt, but we've got ugha.i2p too)
            
-
            16:32 < jrandom> tracking issues is the only feature i care about for that
            
-
            16:37 < jrandom> ok, if there isn't anything else for the meeting...
            
-
            16:37  * jrandom winds up
            
-
            16:37  * void hands jrandom the baffer
            
-
            16:37  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting2.html b/www.i2p2/pages/meeting2.html
deleted file mode 100644
index 55f668d8..00000000
--- a/www.i2p2/pages/meeting2.html
+++ /dev/null
@@ -1,1134 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 2{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 2
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue May 28 22:39:11 2002
-
            22:39 <+logger> logging started
-
            22:40 -!- mids changed the topic of #iip-dev to: IIP Development Channel (moderated) | Weekly development meetings happen here at 0000 UTC wed. (tue if you are in a minus tz) | (during meetings) live logfile http://mids.student.utwente.nl/~mids/meeting2/livelog.txt
-
            22:52 -!- mode/#iip-dev [-v logger] by mids
-
            23:42 -!- mids changed the topic of #iip-dev to: IIP Development Channel (moderated) | Weekly development meetings happen here at 0000 UTC wed. (tue if you are in a minus tz) | http://mids.student.utwente.nl/~mids/iip/
-
            --- Day changed Wed May 29 2002
-
            00:16 [Users #iip-dev]
-
            00:16 [@mids] [ athena] [ logger] [ MiB] [ SubLiminaL] 
-
            00:16 -!- Irssi: #iip-dev: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal]
-
            00:26 -!- mode/#iip-dev [+o UserX] by mids
-
            00:29 -!- mode/#iip-dev [+o codeshark] by mids
-
            00:32 <@codeshark> mids: i have an additional topic for today
-
            00:32 <@codeshark> we need more relays
-
            00:33 <@mids> where do you want it?
-
            00:34 <@codeshark> stability of networks
-
            00:34 <@mids> done
-
            00:56 <@UserX> mids: i'm going to have to leave about 30 minutes after the meeting starts
-
            00:56 <@mids> ok, if you have agenda items, please msg them to me, and they will be discussed
-
            00:56 <@mids> same if you want to shuffle the order
-
            00:57 <@mids> though I tried to move the most important ones to the top
-
            00:58 <@codeshark> add to agenda items: change meeting time
-
            00:59 <@mids> to when?
-
            00:59 <@codeshark> needs to be discussed
-
            01:00 <@mids> ok
-
            01:00 <@codeshark> for me it's a bit too late
-
            01:00 <@codeshark> 2 AM ...
-
            01:22 -!- mode/#iip-dev [+o nop] by mids
-
            01:51 -!- mode/#iip-dev [-m] by mids
-
            01:51  * mids unmoderates till it start
-
            01:51 <@codeshark> my notebook has power for 38 minutes
-
            01:52  * codeshark wonders if that's enough
-
            01:52 <@mids> brb
-
            01:53 <@mids> re
-
            01:54 < MiB> Side question: I noticed mids' page is .nl... how many of you are Dutch?  I'm a Belgian myself.
-
            01:54 <@mids> we have atleast 10 dutch(wo)men here
-
            01:54 < MiB> Wow, leuk om weten :)
-
            01:55 -!- mode/#iip-dev [+o nop] by mids
-
            01:55 < athena> codeshark: where are you at 2am that doesn't have a power outlet?? :)
-
            01:57 <@codeshark> i have, but i'm too lazy
-
            01:59 -!- mids changed the topic of #iip-dev to: Meeting info, agenda, livelog including live logs in case you are late): 
-
            01:59 -!- mids changed the topic of #iip-dev to: Meeting info, agenda, livelog (in case you are late): http://mids.student.utwente.nl/~mids/iip/
-
            02:00 <@nop> ok
-
            02:00 <@nop> welcome
-
            02:00 <@nop> to our 2nd meeting
-
            02:00 -!- mode/#iip-dev [+m] by mids
-
            02:00 <@nop> at IIP
-
            02:00 <@mids> This is the first public IIP meeting, we plan to have such a meeting each week at the same time and place.
-
            02:00 <@mids> Previous meeting ( http://mids.student.utwente.nl/~mids/iip/meeting1/ ) was non public, this one is.
-
            02:00 <@mids> We will moderate the meetings to prevent chaos. After the subject is stated, the channel will be unmoderated
-
            02:00 <@mids> so you can talk. If this becomes too chaotic, it will be kept moderated and then if you have a question or
-
            02:00 <@mids> want to contribute something, message someone with ops (@) or voice (+)
-
            02:00 <@mids> Meeting info, agenda, livelog (in case you are late): http://mids.student.utwente.nl/~mids/iip/
-
            02:00 <@mids> .
-
            02:00 <@nop> ok
-
            02:01 <@nop> let's get started, I've been so busy today
-
            02:01 <@nop> multitasking
-
            02:01 <@nop> so you'll have to excuse if I'm in and out
-
            02:01 <@mids> np
-
            02:01 <@nop> agenda list
-
            02:01 <@mids> Topics:
-
            02:01 <@mids> 1) Welcome
-
            02:01 <@mids> 2) Stability network
-
            02:01 <@mids> 3) Project management
-
            02:01 <@mids> 4) Instant Anonymous Messenger
-
            02:01 <@mids> 5) Website
-
            02:01 <@mids> 6) Documentation
-
            02:01 <@nop> ok
-
            02:01 <@mids> 7) Other
-
            02:01 <@nop> stability network
-
            02:01 <@mids> 8) Questions?
-
            02:01 <@mids> 9) Next meeting
-
            02:01 <@mids> .
-
            02:02 -!- mode/#iip-dev [-m] by mids
-
            02:02 <@nop> as you may have noticed
-
            02:02 <@mids> maybe initial questions?
-
            02:02 <@nop> sure
-
            02:02 <@mids> anybody....
-
            02:02 < Neo> hi.
-
            02:02 < Neo> do you know the causes of the network problems?
-
            02:02 <@mids> Neo: that will be answered in a minute
-
            02:02 <@nop> ok
-
            02:02 <@mids> first we look if there are initial questions
-
            02:02 <@nop> any initial questions
-
            02:02 <@mids> guess not, nop go on (+m)
-
            02:03 <@nop> ok
-
            02:03 <@nop> network stability
-
            02:03 <@nop> the reasons of this are many
-
            02:03 <@nop> for one
-
            02:03 <@nop> this network has been sitting in a laptop on a desk at my work for a long time
-
            02:03 <@nop> problem with this is
-
            02:03 <@nop> someone moved the laptop
-
            02:03 <@nop> not thinking it needed to be on
-
            02:03 <@nop> so... that was one problem
-
            02:04 <@nop> second
-
            02:04 <@nop> I decided to move it
-
            02:04 <@nop> to a beefier box
-
            02:04 <@nop> especially because of all the Diffie-Hellman calculations
-
            02:05 <@mids> can you explain the case with the DH?
-
            02:05 <@nop> it is now gone from a 300 mhz
-
            02:05 <@nop> actually
-
            02:05 <@nop> 366 mhz
-
            02:05 <@nop> to a 933 mhz
-
            02:05 <@nop> from 128 megs of ram to 512
-
            02:05 <@nop> big difference
-
            02:05 <@nop> :)
-
            02:05 <@nop> Pent II - Pent III
-
            02:05 <@nop> ok
-
            02:05 <@nop> from that point 
-
            02:05 <@nop> we found a memfree assertion error - actually athena also discovered it running rc2
-
            02:06 <@nop> and this problem needed to be addressed
-
            02:06 <@nop> which was
-
            02:06 <@nop> and just recently
-
            02:06 <@nop> upon fixing that problem
-
            02:06 <@nop> it has been since stable
-
            02:06 <@nop> now
-
            02:06 <@nop> we would really love to move away from centralization and that's our main goal
-
            02:06 <@nop> but it's a one step at a time type of deal, and this is a developer's network
-
            02:06 <@nop> so sometimes reliability is not it's best
-
            02:07 <@nop> but I am trying to keep everyone happy at this level
-
            02:07 <@nop> any questions
-
            02:07 <@nop> regarding this matter
-
            02:07 <@mids> can you explain the case with the DH?
-
            02:07 <@nop> Case with DH
-
            02:07 <@nop> Diffie-Hellman key exchange calculations take a lot of processes
-
            02:07 <@nop> so when it goes down for a sec
-
            02:07 <@nop> and everyone tries to connect
-
            02:07 <@nop> it spikes the cpu at 99%
-
            02:08 <@nop> because lots of calculations are taking place
-
            02:08 <@nop> our goal
-
            02:08 -!- mode/#iip-dev [-s] by mids
-
            02:08 <@nop> to fix this
-
            02:08 <@nop> we have done a few things
-
            02:08 <@nop> we put a poll/delay to handle calculations better
-
            02:08 <@nop> and 2
-
            02:08 <@nop> we are planning on implemented a better Multi-precision library in the future
-
            02:09 <@nop> any more questions regarding this matter
-
            02:09 <@mids> I have one thing to ad:
-
            02:09 <@nop> ok
-
            02:09 <@nop> please
-
            02:09 <@mids> network graph: http://mids.student.utwente.nl/~mids/iipstats/network.html
-
            02:09 <@mids> as you see (especially at weekly)
-
            02:09 <@mids> after a long network downtime
-
            02:09 <@mids> we loose a big time of users
-
            02:09 <@mids> and it takes a long time to gain them back
-
            02:09 <@mids> this is bad for our reputation
-
            02:09 <@nop> and for anonymity
-
            02:09 <@mids> maybe we should communicate better with the users
-
            02:09 <@nop> more users the better
-
            02:10 <@nop> agreed
-
            02:10 <@mids> when you know that the net will go down: do a global announcement
-
            02:10 <@nop> ok
-
            02:10 <@nop> sometimes
-
            02:10 <@nop> I don't know
-
            02:10 <@mids> if you observe that it is down: update status on site
-
            02:10 <@mids> .
-
            02:10 <@nop> ok
-
            02:10 <@nop> any questions or comments on this topic
-
            02:10 < athena> if i can make a suggestion: a brief update in the ircd motd would be great also
-
            02:10  * Neo things update status on site is really good idea
-
            02:11 <@nop> ok athena : you are noted, and I will make my efforts in doing so
-
            02:11 < athena> thanks'
-
            02:11 < Neo> (sometimes I don't know if it is the network or just me)
-
            02:11 <@nop> Neo and mids I agree on update status
-
            02:11 <@nop> great idea
-
            02:11 <@mids> codeshark had something on the node status
-
            02:11 <@nop> k
-
            02:11 <@codeshark> just thought it could be integrated in the nodechecker
-
            02:12 <@nop> please elaborate
-
            02:12 <@codeshark> if i see that all hosts are down (=network down), i could update the status page
-
            02:12 <@nop> cool
-
            02:12 <@nop> sounds great
-
            02:13 <@nop> this also could go well with nym's who's online, instead of that, just have a network status page
-
            02:13 <@mids> please use . when done
-
            02:13 <@codeshark> .
-
            02:13 <@nop> .
-
            02:13 < Neo> .
-
            02:13 <@mids> how many public relays do we have?
-
            02:13 <@mids> .
-
            02:13 <@codeshark> right now we 15 in the nodechecker list
-
            02:13 <@codeshark> 13 are online
-
            02:14 <@codeshark> .
-
            02:14 <@nop> agenda
-
            02:14 <@mids> do we need more?
-
            02:14 <@mids> .
-
            02:14 <@nop> we always need more
-
            02:14 <@nop> that's a given
-
            02:14 <@nop> :)
-
            02:14 <@nop> .
-
            02:14 <@codeshark> not for stability
-
            02:14 <@codeshark> but for anonymity
-
            02:14 <@codeshark> .
-
            02:14 <@nop> yes 
-
            02:14 <@nop> .
-
            02:14 <@mids> other questions/
-
            02:14 <@mids> .
-
            02:14 <@nop> this . thing is funny
-
            02:14 <@nop> .
-
            02:14  * mids does no . after a question anymore
-
            02:15 <@mids> okay, next
-
            02:15 <@mids> 3) Project management
-
            02:15 <@nop> mids - you might want to open up on that
-
            02:15 <@mids> maybe we should try to be more professional
-
            02:15 <@mids> while keeping it fun
-
            02:15 <@nop> well
-
            02:15 <@nop> maybe more organized
-
            02:15 <@mids> publish our milestones
-
            02:15 <@nop> professionaly is up for debate
-
            02:16 <@mids> delegate tasks
-
            02:16 <@nop> the challenge with professional is we can't be committed every single day to this, because of real life
-
            02:16 <@nop> but yes
-
            02:16 <@nop> we should definitely delegate tasks
-
            02:16 <@nop> which
-
            02:16 <@nop> I think we do
-
            02:16 <@nop> but not everyone has remained in contact about their task
-
            02:16 <@mids> maybe make delegation more open
-
            02:16 <@mids> so everybody knows who to inform about what
-
            02:16 <@nop> ok
-
            02:16 <@nop> yes
-
            02:16  * Neo has a suggestion re: project management helper that we are using in DC.
-
            02:16 <@mids> I remember several cases of double work
-
            02:16 <@mids> .
-
            02:16 <@mids> yes Neo ?
-
            02:17 < Neo> Mr Project.
-
            02:17 <@nop> an agent?
-
            02:17 < Neo> Here is our release schedule: http://citystateinc.com/dc/dc_project_5-28-2002.gif
-
            02:17 < Neo> Its a task sheduler thing, take a look at the gif it explains it pretty much.
-
            02:17 < Neo> Its just a helper tool.
-
            02:18 <@nop> sounds good
-
            02:18 <@nop> also
-
            02:18 <@nop> we need a whiteboard type communication device
-
            02:18 <@nop> something that can allow developer's to communicate visually
-
            02:18 <@nop> especially as we dive deeper into complications of anonymous network
-
            02:18 <@nop> s
-
            02:18 <@codeshark> mids and I tried some whiteboard stuff
-
            02:18 <@nop> networks
-
            02:18 <@codeshark> but it doesn't seem to be very useful
-
            02:18 <@codeshark> at least the tools we tried
-
            02:18 <@codeshark> .
-
            02:18 <@nop> hmm
-
            02:18 <@mids> those we tried were too slow and limited
-
            02:18 <@mids> .
-
            02:19 <@nop> hmm
-
            02:19 <@nop> what did you try
-
            02:19 <@mids> some freshmeat ones
-
            02:19 <@nop> k
-
            02:19 <@mids> does anybody have good experience with public whiteboards?
-
            02:19 <@nop> guess not
-
            02:19 <@mids> hm, nope
-
            02:19 <@mids> :)
-
            02:19 <@nop> well
-
            02:19 <@nop> maybe we should delegate a task
-
            02:19 <@mids> put it on the todo
-
            02:20 <@nop> todo/task delegateion
-
            02:20 <@nop> who wants to assist in finding a whiteboard that would suit developer's needs
-
            02:20 <@nop> it can always be more than one person as well
-
            02:20 <@mids> well, if I find one, I wont keep it a secrey
-
            02:20 <@nop> k
-
            02:20 <@nop> well it's on the todo
-
            02:20 <@mids> but it has to be multiplatform
-
            02:20 <@nop> yes
-
            02:21 <@mids> ok
-
            02:21 < Neo> nop, what do you see people finding the whiteboard useful for? (curious of your ideas)
-
            02:21 <@nop> well, I am visual with networks 
-
            02:22 <@nop> and I know there have been a few times
-
            02:22 <@nop> that visual drawings make sense
-
            02:22 <@nop> rather than chatting on irc
-
            02:22 < Neo> k, thanks :)
-
            02:22 <@nop> that can be limiting and hard to get your algorithm/network design across
-
            02:22 <@mids> especially the explination of the relays
-
            02:22 < Neo> some screen grabs could come in handy for docs also.
-
            02:22 <@nop> yes
-
            02:23 <@nop> so far
-
            02:23 <@nop> I've come to the point of drawing it out and faxing it last time
-
            02:23 <@nop> :)
-
            02:23 <@mids> lol
-
            02:23 <@nop> ok - anyway
-
            02:23 <@codeshark> nop: email :)
-
            02:23 <@nop> noted that whiteboard would be a plus
-
            02:23 <@nop> yeah yeah
-
            02:23 <@mids> other point:
-
            02:23 <@nop> email smemail
-
            02:23 <@nop> you guys think we're like geeks or somethin
-
            02:24 <@mids> banks suggested to follow the thought of the Cathedral Bazaar thing by Eric Raymond: release often
-
            02:24 <@nop> I'm still learning email ;)
-
            02:24 <@mids> I think that is under project management too
-
            02:24 <@nop> umm, link
-
            02:24 <@codeshark> (... release early)
-
            02:24 <@mids> http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
-
            02:25 <@codeshark> i think that's what we doing. or do you want to release more often?
-
            02:25 <@codeshark> .
-
            02:25 <@mids> Banks?
-
            02:25 < Banks> I'm not sure yet
-
            02:26  * mids guesses he is just anxious to see RC2
-
            02:26 < Banks> it helps people to see that the path to RC2 is advancing swiftly :)
-
            02:26 <@nop> RC2 is done - it's docs that are being the hold up
-
            02:26 <@mids> docs are point 6
-
            02:26 <@nop> k
-
            02:27 < Banks> Docs on RC2?
-
            02:27 <@mids> Banks: yes
-
            02:27 <@nop> well, docs for 1.1 official release
-
            02:27 <@nop> but yes
-
            02:27 <@nop> if we don't get progress done
-
            02:27 <@nop> on docs
-
            02:27 <@nop> then we'll be lagged period
-
            02:27 <@nop> for release of 1.1 Release
-
            02:27 < Banks> I've just done a ton on the docs but not for RC2. Haven't sent it yet. Don't know cvs
-
            02:28 <@nop> hehe
-
            02:28 <@nop> ok
-
            02:28 <@codeshark> banks: what did you do?
-
            02:28 < Aster> hola
-
            02:28 <@mids> hi Aster please check the notices
-
            02:28 < Aster> which notices?
-
            02:28 < Aster> im soo lost
-
            02:28 < Aster> whats going onn? aaahhhh
-
            02:28 <@mids> [notice(Aster)] welcome, the channel is moderated if you have something to say, message me or somebody else with ops or voice
-
            02:28 <@mids> [notice(Aster)] Information, agenda and logs: http://mids.student.utwente.nl/~mids/iip/
-
            02:29 < Banks> codeshark: A handful of things. Related quotes at the beginning of each chapter, a small FAQ ...
-
            02:29 < Banks> How to contribute
-
            02:29 < Banks> Why Anonymity?
-
            02:29 < ptsc> suggestion if i may be so bold:  default option, which can be disabled, of 'crippling' urls to be non-clickable, in the proxy.
-
            02:29 <@codeshark> ok. we have to talk about that in point 6
-
            02:29 <@mids> great
-
            02:29 < Banks> How to configure a WinXP firewall to allow IIP
-
            02:30 <@mids> ptsc: what do you mean?
-
            02:30 < ptsc> perhaps by chaning http to some other string such as wysiwyg or url or something unlikely to be anonymity compromising, like the anonymity tripwire in freenet
-
            02:30 <@mids> you mean, that if I say http://www.google.com/ that it will be censored?
-
            02:31 < ptsc> since the easiest means of compromising anonymity is to post a honeypot url to a crowded channel
-
            02:31 < SkyRat> no just not clickable
-
            02:31 <@mids> anybody want to respond on that one?
-
            02:31 < ptsc> this should be something that can be disabled.
-
            02:31 < Banks> That would have to be done at the IRC client level wouldn't it?
-
            02:31 < athena> or server
-
            02:32 <@mids> it can be done on the server level
-
            02:32 <@mids> but I think there is some responcibility for the user
-
            02:32 < ptsc> contaminating server traffic might be bad
-
            02:32 <@mids> should we also change telephone numbers?
-
            02:32 < Banks> Lot of overhead though isn't it?
-
            02:32  * Neo thinks manipulating content should not be done with the system. that is a pure client issue
-
            02:32 < athena> think this problem can't be solved
-
            02:33 < Banks> It's a good point though
-
            02:33 <@mids> maybe a specialmodified security client
-
            02:33 <@mids> see point 5!
-
            02:33 <@mids> err 4
-
            02:33  * Banks is trying not to jump to the docs part, "I mentioned it in the docs"
-
            02:33 <@mids> hehe
-
            02:33  * Neo thinks mids is correct, it has a place in a custom client maybe, or in "security" patches to existing clients
-
            02:33 < athena> there should be discussion of this in the manual... i.e. "ways of losing your anonymity"
-
            02:34 <@mids> I suggest going on , and see what point 4 brings us after MiBs comment
-
            02:34 < MiB> :)
-
            02:34 < MiB> You spoke about better communication with users a bit earlier, how do you feel about a public mailing list and/or BBS where developers and testers can conversate with each other?
-
            02:34 <@mids> afaik we have 1 mailinglist
-
            02:34  * athena points out #iip
-
            02:34 <@mids> iip-dev mainly for development
-
            02:35 < Banks> Maybe an IRC chan where people who can't connect to IIP can go?
-
            02:35 <@mids> although also other topics
-
            02:35 <@codeshark> we have the bug-list on sourceforge too
-
            02:35 < ptsc> i actually have written a sort of 'guide for the clueless' 
-
            02:35 < ptsc> including some of these
-
            02:36 < Banks> I saw that at deja, ptsc. Nice.
-
            02:36 < ptsc> http://groups.google.com/groups?selm=ss9rdugclv39cemnk4ue9t8jv6n8se8a3h%404ax.com&output=gplain
-
            02:36 < ptsc> it is written to a specialized audience concerning an iip channel that is as yet relatively uninhabited
-
            02:36 < ptsc> thx
-
            02:36 < Banks> It's a good idea for a chan
-
            02:37 < ptsc> i think it captures the "fool's mate" ways of trashing your own anonymity, but i do believe more sophisticated attacks could be made especially by an opponent who both has surveillance capability and is running a node.
-
            02:37 <@mids> cool for an howto I would say!
-
            02:38 <@mids> noe?j
-
            02:38 <@mids> err
-
            02:38 < Neo> Re: BBS - Distribued City is a ssl/web based community system located at xs4all. We welcome IIP forums in our forum section.
-
            02:38 <@mids> neo?
-
            02:38 < Banks> I tried to put some of it into the docs.
-
            02:38 < ptsc> i think it's beyond a mid-level opponent such as an unaided church of scientology but assisted by hackers and/or a corrupt node, and a manipulated federal agency (FBI), i think you could possibly bust it open
-
            02:39 < ptsc> it doesn't have the latency of the remailer network (and in fact couldn't, and still be reasonably 'instant')
-
            02:39 < Neo> The DC system also has GPG Web private messaging. Mids and I and others have kept in contact when IIP was down, and also relevant discussion of issues related to IIP.
-
            02:39 < Neo> We are in beta now, but opening to public soon.
-
            02:39 < Neo> .
-
            02:39 <@mids> So we can use DC for the non-irc part of IIP
-
            02:39 <@mids> forums, announcements
-
            02:39 < Neo> You bet.
-
            02:39 < Banks> A corrupt node would have to unscramble the end-to-end encryption too, wouldn't it?
-
            02:39 < Neo> We trashed our chat system, and are using IIP, so you guys jump right in.
-
            02:40 <@mids> Banks: err, thats offtopic atm
-
            02:40 < Banks> mids: You're right
-
            02:40 <@mids> I suggest discussing the IIP internals later
-
            02:40 < ptsc> i guess by 'corrupt' i meant the person rather than the node
-
            02:40 <@mids> lets hurry and move on before chocolate joins
-
            02:40 <@mids> any objections?
-
            02:40 < ptsc> and by that, i mean just that the person is going to run netstat periodically and log who is connecting to them,
-
            02:41 < ptsc> while also being logged in a channel as a nick, watching who shows up, and weeding people out by a process of elimination
-
            02:41 < Neo> We can give IIP their own custom forums. - Newbies - Tech - Dev... let us know.
-
            02:41 -!- mode/#iip-dev [+o Chocolate] by mids
-
            02:41 < ptsc> they could also get network internals of other nodes they connect to, and then obtain subpoenas/'carnivore' capability on those nodes
-
            02:41 <@mids> ptsc: its offtopic
-
            02:41 <@mids> please discuss it later
-
            02:41 <@mids> (getting chaotic)
-
            02:41 < ptsc> apologies
-
            02:41 <@mids> np
-
            02:42 <@mids> 4) Instant Anonymous Messenger (wilde wont be here)
-
            02:42 <@mids> wilde was too sleepy
-
            02:42 <@mids> so u
-
            02:42 <@nop> ok
-
            02:42 <@mids> so I 'll just paste what he said:
-
            02:42 <@nop> please do
-
            02:42 <@mids> Status and features:
-
            02:42 <@mids> wilde started to work on an IM, easy to use program to connect to IIP.
-
            02:42 <@mids> He got the IRC connection working. The plugin system works too.
-
            02:42 <@mids> Apart from IRC and IM support there will also be features for digital
-
            02:42 <@mids> currencies. He is looking into cryptography now.
-
            02:42 <@mids> For further information email wilde@invisiblenet.net or visit #iam-dev
-
            02:42 <@mids> .
-
            02:42 <@nop> ok
-
            02:42 <@nop> also
-
            02:42 <@nop> if freenet ever gets stable
-
            02:42 <@nop> it would be nice to add a dcc transport
-
            02:42 <@nop> that utilizes freenet
-
            02:42 <@nop> as a plugin
-
            02:43 <@mids> yup
-
            02:43 <@nop> ok
-
            02:43 <@nop> sounds good
-
            02:43 <@nop> any questions
-
            02:43 <@mids> and maybe, like ptsc suggested
-
            02:43 < Banks> True, but won't RC2 have DCC?
-
            02:43 <@mids> filter the IRC, to disable urls
-
            02:43 <@nop> IIP rc2 will not have dcc
-
            02:43 <@nop> it compromises anonymity
-
            02:43 <@nop> file sharing will have to be later within IIP
-
            02:44 <@nop> but it's in planning
-
            02:44 < Banks> ok, I thought there might be a way to do it without compromise
-
            02:44 <@nop> not till we decentralize
-
            02:44 <@nop> then there will be
-
            02:44 <@nop> utilizing broker agents
-
            02:44 <@nop> etc
-
            02:44 <@nop> we have a fileserv plugin for xchat
-
            02:44 <@nop> that does base64
-
            02:44 <@nop> anyway
-
            02:44 <@nop> that's the plan
-
            02:44 <@nop> ok
-
            02:44 <@nop> next topic
-
            02:45 <@mids> maybe questions
-
            02:45 <@mids> but we dont know all answers
-
            02:45 <@mids> cause wilde aint here
-
            02:45 <@mids> :)
-
            02:45 <@mids> so just ask, he can read them in the logs
-
            02:45 < Neo> wilde coding in perl?
-
            02:45 <@nop> java
-
            02:45 <@mids> java
-
            02:45 <@nop> I believe
-
            02:46 <@mids> he bases it on a full IM client that a friend of him wrote
-
            02:46 < Neo> ah
-
            02:46 <@mids> okay, lets hurry to topic 5
-
            02:46 <@mids> we have 9 in total
-
            02:47 <@nop> topic number 5 is ...
-
            02:47 <@nop> drum roll please
-
            02:47 <@mids> write your burning quesitons down
-
            02:47 <@mids> 5) Website
-
            02:47 <@nop> ahh
-
            02:47 <@nop> yes
-
            02:47 <@nop> the lag
-
            02:47 <@mids> I want to give the word to nym
-
            02:47 <@nop> yeah
-
            02:47 <@nop> umm
-
            02:47 <@mids> nym?
-
            02:47 <@mids> okay
-
            02:47 <@nop> ok
-
            02:47 <@nop> site looks ok
-
            02:47 <@mids> he was here last week
-
            02:47 <@nop> the fear I have
-
            02:47 <@mids> and appologied for the delay
-
            02:47 <@nop> is that it will take him forever to update any changes
-
            02:47 <@mids> he has made a new updayed design:
-
            02:47 <@mids> http://buttsnot.com/invisible2.html
-
            02:48 <@nop> or press releases
-
            02:48 <@mids> the first one was http://mids.student.utwente.nl/~mids/iip/meeting1/draft2.jpg
-
            02:48 <@nop> so dunno
-
            02:48 <@mids> any comments on the looks?
-
            02:48 <@nop> and we need a plan b
-
            02:48 <@nop> just in case he never shows a stable site
-
            02:48 < tikk> nice job.. and i'm a designer
-
            02:48 < tikk> there's a few table errors
-
            02:48 < Neo> ellison is available for plan b
-
            02:48 < Aster> its ok, could use some more work
-
            02:49 < tikk> cosmetic stuff
-
            02:49 <@nop> neo are you sure
-
            02:49 <@nop> that would be great
-
            02:49 <@nop> also Neo
-
            02:49 <@nop> thnx for the IIP stuff you wrote
-
            02:49 <@mids> I think it is not good enough for > 15 hours work
-
            02:49 <@nop> it's impressive
-
            02:49 < Neo> yes, he already offered
-
            02:49 <@nop> great
-
            02:49 < Neo> what IIP stuff?
-
            02:49 <@nop> dc 
-
            02:49 <@nop> on dc beta
-
            02:50 < Neo> OH. ellison did that :)
-
            02:50 <@nop> also
-
            02:50 <@nop> well thank him
-
            02:50 <@nop> also
-
            02:50 <@nop> does ellison do logo design?
-
            02:50 < Neo> will do, he will read this log
-
            02:50 <@mids> FYI, ellison is the gfx guy of Distributed City
-
            02:50 < Neo> you bet.
-
            02:50 <@nop> kewl
-
            02:50 < Neo> and alta/lese/liquid privacy
-
            02:50 <@nop> is he fast working
-
            02:50 <@nop> like we would be able to see something soon
-
            02:50 <@nop> type of deal
-
            02:50 <@nop> because I"m bout ready to put my foot down
-
            02:50 <@nop> and go with plan b
-
            02:51 < Neo> he will be on later, we can have a quick meeting then, I can't speak for him
-
            02:51 <@mids> update on nym
-
            02:51 <@nop> ok
-
            02:51 <@mids> he got $100 from us to do a design
-
            02:51 <@mids> payed out of the donations depot
-
            02:51 < Neo> now but I know that he was very interested in doing something for IIP if the opportunity arose.
-
            02:51 <@mids> all the donators agreed
-
            02:51 <@mids> but, what we have now is not usable
-
            02:51 <@mids> it is going too slow
-
            02:51 <@nop> and we know 100$ ain't much
-
            02:52 <@nop> but I don't feel that we even have that worth
-
            02:52 <@mids> but well, we dont have more
-
            02:52 <@mids> I am sure that nym means it all right
-
            02:52 <@nop> we gave it to him like more than a month ago
-
            02:52 <@mids> but lacks the time
-
            02:52 <@nop> yes
-
            02:52 <@nop> I understand
-
            02:52 <@nop> but we have to be practical
-
            02:52 < Aster> once he gets the design done, someone else (ide be willing to) get the rest together
-
            02:52 <@mids> we want a website asap
-
            02:52 <@mids> Aster: thanks
-
            02:52 <@nop> and good logo's
-
            02:52 <@nop> yes thanks
-
            02:53 <@mids> so what are the options:
-
            02:53 <@mids> - use what we have and craft it into a site
-
            02:53 <@mids> - put another gfx guy/girl on it
-
            02:53 <@mids> - keep the old site
-
            02:53 <@nop> old site has to go
-
            02:53 <@nop> I like it
-
            02:53 <@nop> but it's too villany
-
            02:53 <@mids> - wait for nym to finish it
-
            02:54 <@nop> and casper == copyright infringement
-
            02:54 < Banks> I think the old site is pretty good. Logo and Times New Roman aside.
-
            02:54 <@nop> hehe
-
            02:54 <@nop> you know
-
            02:54 <@nop> you'd be surprised
-
            02:54 <@nop> but that was done in 10 minutes
-
            02:54 < Banks> shame that Gamespy had to steal our logo before we had a chance to create it :)
-
            02:54 <@nop> haha
-
            02:55 <@nop> ok
-
            02:55 <@nop> so on topic of website
-
            02:55 <@nop> reverting back to old one is last option at most
-
            02:55 <@nop> I'm really wanting to go for a brighter look
-
            02:55 <@nop> something more professional
-
            02:55 <@nop> because
-
            02:55 <@nop> if we get attention by press
-
            02:55 <@nop> the darkness will give way to the "media hacker" term
-
            02:56 < Banks> true. I think we should think about who the target market is and cater it to that.
-
            02:56 <@nop> and IIP will not go down like that
-
            02:56 <@nop> Banks: agreed
-
            02:56 <@nop> the target market is how you market it though
-
            02:56 <@nop> the way I see this
-
            02:56 < Neo> ellison can *REALLY* help you with this.
-
            02:56 <@nop> yes
-
            02:56 <@nop> I see
-
            02:56 <@mids> I have seen ellisons work
-
            02:56 <@nop> I have as well, it's very good
-
            02:56 <@mids> and if he wants, lets give him a try
-
            02:56 <@nop> PR and website == one idea
-
            02:57 < Banks> True, but there's already an audience for it. Slashdot-types.
-
            02:57 < Aster> market to both groups: hackers and corp looking...have 2 sites
-
            02:57 < Aroonkoa> And kuro5hin. :)
-
            02:57 <@mids> about the $100, I see it as lost
-
            02:57 <@nop> yes
-
            02:57 <@mids> and we dont do such things again in the future
-
            02:57 <@Chocolate> 2 sites is way to much overhead
-
            02:57 <@mids> lets name it a learning phase
-
            02:57 <@nop> yes
-
            02:57 < Aster> chocolate: in what way?
-
            02:57 <@nop> we want the invisibleNet front page
-
            02:57 < Banks> The program itself is always significantly more important than the website.
-
            02:57 <@nop> then the Invisible Irc Project page
-
            02:58 < Banks> A good program markets itself.
-
            02:58 <@nop> InvisibleNet is the Dev team
-
            02:58 <@nop> all of us
-
            02:58 <@nop> everyone using IIP
-
            02:58 <@nop> is part of an invisibleNet
-
            02:58 <@nop> :)
-
            02:58 <@nop> a society so secret we don't even know ourselves
-
            02:58 <@nop> ;)
-
            02:58 <@nop> but seriously
-
            02:58 <@nop> and then we need the main IIP page
-
            02:58 <@mids> tikk offers his help too
-
            02:58 <@mids> maybe we can make a little web-board
-
            02:58 <@nop> tikk, much appreciated
-
            02:58 <@mids> for input etc
-
            02:59 < Neo> Banks: yes, but part of the marketing needs to cater to PR for political reasons ciphers only go so far
-
            02:59 <@mids> who wants to participate in the webboard? (just an idea)
-
            02:59  * mids  
-
            02:59 <@nop> Neo : please elaborate on that comment
-
            02:59 < Banks> Neo: I agree
-
            02:59  * nop doesn't quite understand yet
-
            03:00 <@nop> also - mids : anytime Website is topic have website/PR as one topic
-
            03:00 <@nop> because it is one in the same
-
            03:00 <@mids> nop: yup
-
            03:00 <@nop> ok
-
            03:00 <@nop> well, if ellison is willing
-
            03:00 <@nop> and tikk you are willing to offer advice
-
            03:00 <@nop> let's do this
-
            03:01 < Neo> re: PR. Like your comment above about the "media hacker" term. The dark "villianry" (sp?)
-
            03:01 <@nop> and anyone else willing to get the website to the optimal point then hop on and let's go for it
-
            03:01 <@nop> Neo: point seen - understood
-
            03:01 < Neo> image is not good for PR - Political PR and marketing for new users PR.
-
            03:01 < Neo> That is why people interested in saving money from people who try and take it away from
-
            03:01 < Aster> nop: you mean as in webmaster, or just finishing the job of the site (hop on comment)
-
            03:02 < tikk> i'm willing to help advise, sure.. i'm not sure if i'm +v here
-
            03:02 < Neo> them and use crypto, it is better for them to use crypto for freedom of speech uses. not to capitalize on
-
            03:02 <@mids> tikk: we hear you
-
            03:02 <@nop> aster that's debatable, lately, I've been the semi-webmaster
-
            03:02 <@mids> tikk: the chan isnt +m
-
            03:02 <@nop> aster
-
            03:02 < Aster> yup?
-
            03:02 <@nop> if you want to it's an open position once we get it up
-
            03:02 < Neo> how they are protecting assets. (nuff said, this is for another room/thread)
-
            03:02 < Aster> sure
-
            03:03 <@nop> I have a feeling this is going to be bigger than I can handle
-
            03:03 <@mids> ok
-
            03:03 <@nop> Neo : good point ;)
-
            03:03  * mids asks contact info from parties involved
-
            03:03 <@mids> and I'll notice you
-
            03:03 <@nop> and pubkeys
-
            03:03 <@nop> also
-
            03:03 <@nop> on a side note
-
            03:03 <@nop> everyone registered with trent
-
            03:03 <@nop> has anonymail access
-
            03:03 <@nop> user@iipmail.net
-
            03:04 <@nop> pgp compatible
-
            03:04 <@nop> somewhat
-
            03:04 <@nop> :)
-
            03:04 <@nop> it's like memoserv here
-
            03:04 <@nop> and is very useful
-
            03:04 <@nop> continue
-
            03:04 <@nop> off topic
-
            03:04 <@mids> ok
-
            03:04 <@nop> but needed to say
-
            03:04 <@mids> (just ask in #iip for more info)
-
            03:04 <@nop> yep
-
            03:05 <@mids> I'll contact the parties who offered their interest in the web/pr
-
            03:05 <@mids> lets move on
-
            03:05 <@mids> ) Documentation (codeshark, cohesion or mids)
-
            03:05 <@mids> cohesion isnt here
-
            03:05 <@Chocolate> can I stick something in real fast?
-
            03:05 <@nop> sure
-
            03:05 <@mids> ok
-
            03:05 <@Chocolate> going back to the whiteboard
-
            03:05  * mids scrolls up
-
            03:05 < Banks> That's what I'm always saying to my wife.
-
            03:05 <@Chocolate> I found one called "CSV" (if I remeber rigth)
-
            03:06 <@Chocolate> I'll find the url and send it to #iip
-
            03:06 <@Chocolate> .
-
            03:06 <@mids> nice
-
            03:06 <@mids> 6) Documentation
-
            03:06 <@mids> last week we had a lenghty talk
-
            03:06 <@mids> 3 ppl involved with documentation
-
            03:06 <@mids> all pretty busy
-
            03:07 <@mids> docu is really needed before release
-
            03:07 <@mids> there are 2 systems:
-
            03:07 <@mids> LaTeX or Docbook
-
            03:07 <@mids> we agreed on using LaTeX now
-
            03:07 <@mids> and moving to docbook in a later state
-
            03:08 <@mids> current latex is available on http://mids.student.utwente.nl/~mids/docdemo/
-
            03:08 < Banks> I was using HTML to PDF with HTMLDOC.
-
            03:08 <@mids> but it needs review
-
            03:08 <@mids> and also misses some items
-
            03:08 <@mids> (unix install)
-
            03:08 <@mids> probably anonymail can be added too it too as appendix
-
            03:08 <@mids> now, we heared that a few people have made additions to the manual
-
            03:09 <@mids> problem is that we dont know what version
-
            03:09 <@mids> so lets coordinate that
-
            03:09 <@mids> and put everything together
-
            03:09 <@mids> .
-
            03:09 <@mids> anybody something to add?
-
            03:10 <@mids> hm
-
            03:10 <@mids> we have 3 translations
-
            03:10 < Banks> Is codeshark still here?
-
            03:10 <@mids> spanish, french and dutch
-
            03:10 <@mids> so it becomes a bit heavy
-
            03:10 <@mids> we need documentation management.
-
            03:11 <@mids> any news about cohesion's status?
-
            03:11 <@mids> nop?
-
            03:11 <@nop> here
-
            03:11 <@nop> sorry
-
            03:11 <@nop> umm
-
            03:11 <@nop> he's around
-
            03:11 <@nop> on earlier today
-
            03:11 <@mids> but he is documentation manager not?
-
            03:11 <@nop> umm
-
            03:12 <@nop> yes
-
            03:12 <@nop> hold 
-
            03:12 <@nop> just a sec
-
            03:12 <@nop> someone at work talking in my ear
-
            03:12 <@mids> :)
-
            03:12 <@mids> --- advertizement ---
-
            03:12 < Banks> Codeshark: Are you still here? Check your pm
-
            03:13 <@mids> Banks: if you talk to him, tell him to respond here too :)
-
            03:13 < Banks> codeshark has been idle 27mins 38secs
-
            03:13 < Banks> :)
-
            03:13 <@mids> darn, out of battery power
-
            03:13 <@Chocolate> lol
-
            03:14 <@nop> back
-
            03:14 <@nop> ok
-
            03:14 <@mids> ellison: we are now at the part 6) Documentation
-
            03:14 <@nop> cohesion is document manager
-
            03:14 <@mids> ok
-
            03:14 <@nop> and main technical writer
-
            03:14 <@mids> but he seems to be busy
-
            03:14 <@nop> but people have real life
-
            03:14 < ellison> thanks, catching up in the logs
-
            03:14 <@nop> and I think that is what is going on
-
            03:14 <@nop> so...
-
            03:14 <@mids> true
-
            03:14 <@nop> we should have a assistant doc manager
-
            03:14 <@mids> suggestion: put as much as possible in CVS, so more can work on it
-
            03:14 <@nop> so that this can continue
-
            03:15 <@nop> mids = you seem like you have a lot on plate
-
            03:15 <@nop> do you
-
            03:15 <@nop> or does it seem that way
-
            03:15 <@nop> with IIP that is
-
            03:15 < Banks> I can help but I'm not familiar with CVS
-
            03:15 <@nop> hold
-
            03:15 <@mids> nop: yup
-
            03:15 <@nop> banks
-
            03:15 <@mids> need to delegate
-
            03:15 <@nop> I'll get you doc on cvs
-
            03:15 <@nop> well chocolate - how are you lately ol' buddy ol pal
-
            03:16 <@nop> ok
-
            03:16 <@mids> I can do the assistent doc management
-
            03:16 < Banks> Does anyone want a copy of a PDF I churned out? Codeshark is busy right now.
-
            03:16 <@mids> but I am not going to write
-
            03:16 <@mids> I can put input into LaTex
-
            03:16 <@mids> and keep it central
-
            03:17 <@mids> it wont be much time for me
-
            03:17 <@mids> Banks: url
-
            03:17 <@nop> sure Banks
-
            03:17 < Banks> Where do you want me to email it?
-
            03:17 <@nop> mids = if you waill approve and put in cvs as a contrib
-
            03:17 <@nop> waill =will
-
            03:17 <@nop> aster
-
            03:17 <@mids> nop: what? my latex of Banks pdf?
-
            03:17 <@nop> I believe so
-
            03:18 <@nop> also
-
            03:18 < Aster> nop: hum?
-
            03:18 <@nop> ellison wrote a good end users doc on dc beta
-
            03:18 <@nop> much appreciated
-
            03:18 <@nop> and could be very usable in future
-
            03:18 <@nop> for general IIP
-
            03:18 <@nop> on website
-
            03:18 <@nop> here
-
            03:18 <@nop> a getting started
-
            03:18 <@nop> type thing
-
            03:18 < Banks> mids: Do you want me to email it to mids@invisiblenet.net?
-
            03:18 <@mids> Banks: please
-
            03:19 < Banks> ok
-
            03:19 <@nop> aster - mind if I delegate you a webmaster once site goes up
-
            03:19 < Aster> nop: dont mind at all :)
-
            03:19 < Banks> mids: Sent.
-
            03:19 < ellison> nop: i can clean it up and re-purpose it for the site
-
            03:19 <@nop> great
-
            03:20 <@nop> ellison - at a later point in time
-
            03:20 <@nop> we would like to discuss web dev with you
-
            03:20 < ellison> ok
-
            03:20 < Banks> mids: Tell me what you think.
-
            03:20 <@mids> Banks: will do once I got it
-
            03:21 <@nop> docs - anymore comments on docs
-
            03:21 <@nop> or questions
-
            03:21 < Banks> mids: Ok, I can send the HTML with BMPs later too.
-
            03:21 < Banks> I've got a question.
-
            03:21 <@mids> Banks: I'll contact you and put it central
-
            03:21 <@nop> yes sir
-
            03:21 < Banks> The whitepaper says "here is a "steady" streaming protocol, for those who can afford the bandwidth, for constant traffic, (which protects you from traffic analysis of any form, but will cause a 500 millisecond lag)."
-
            03:22 < Banks> And then "[name of this parameter?]"
-
            03:22 < Banks> What is the name of the parameter? :)
-
            03:22 <@mids> euh
-
            03:22 <@mids> too detailed
-
            03:22 <@mids> this is a public meeting :)
-
            03:22 <@Chocolate> isnt that offtopic?
-
            03:22 < Banks> My bad.
-
            03:22 <@mids> I got the contact info from those with documentation
-
            03:23 <@mids> I will gather it
-
            03:23 <@mids> and put it central
-
            03:23 <@mids> then find editors to edit
-
            03:23 <@mids> dont fear LaTeX or CVS
-
            03:23 <@mids> you'll live
-
            03:23 <@mids> :)
-
            03:23 <@mids> .
-
            03:23 < Banks> Reading up on LaTeX was a nightmare :)
-
            03:23 <@Chocolate> ok so is Documentation finished?
-
            03:24 <@mids> Chocolate: lol
-
            03:24 <@mids> Chocolate: well, the subject here is
-
            03:24 <@mids> I think.
-
            03:24  * Chocolate kicks mids
-
            03:24 <@Chocolate> thats what I ment
-
            03:24 <@mids> oh :)
-
            03:24 <@mids> before we go to a free-for-all question round
-
            03:24 <@Chocolate> I ment "is agenda item 6 finished"
-
            03:25 <@mids> lets do 1 more public thing
-
            03:25 <@mids> about the meeting time
-
            03:25 <@mids> Quick jump to topic 9 Next meeting:
-
            03:25 -!- Chocolate changed the topic of #iip-dev to: Meeting info, agenda, livelog (in case you are late): http://mids.student.utwente.nl/~mids/iip/ | current topic: meeting time
-
            03:25 <@mids> statement: current time too late for Europeans, better time?
-
            03:25 <@mids> codeshark and me would prefer 2 hours earlier
-
            03:26 <@mids> (its 3:30 am here now)
-
            03:26 < Aster> ouch
-
            03:26 <@mids> Kronos-X: we are now almost finished
-
            03:27 <@mids> Kronos-X: trying to settle a better meeting time
-
            03:27 < Kronos-X> I'm unpredictable, so I'm flexible by default.
-
            03:27 < Kronos-X> :)
-
            03:27 < MiB> 3:38 over here, 3 to 4 hours earlier would be much more humane for me :)
-
            03:27 <@mids> nop: what about 2 hours earlier? choc? banks? neo?
-
            03:28 <@Chocolate> IIRC 0000 is the earlyst nop can make it
-
            03:28 < Neo> anytime is cool with me, its the others to ask. :)
-
            03:28 <@Chocolate> 2200 tuesday should be ok for me
-
            03:29 < Banks> Fine by me
-
            03:29 <@Chocolate> it's important that nop and/or userx can make the meetings though
-
            03:29 < Aster> uh, whats thaht eastern?
-
            03:29 <@Chocolate> no, UTC
-
            03:29 < Aster> what would be eastern then? ( i dont know how this time stuff works :)
-
            03:29 <@mids>  http://www.timeanddate.com/worldclock/
-
            03:29 <@Chocolate> EDT is -5
-
            03:29 < Aster> k
-
            03:29 < ellison> oooh, an ISO compliant meeting!
-
            03:29 < Kronos-X> Heh
-
            03:30 <@mids> nop seems to be busy
-
            03:30 <@mids> he has a veto on the time imho
-
            03:30 <@Chocolate> same
-
            03:30 <@mids> those who showed up didnt complain
-
            03:30 <@mids> so proposal is 2 hours earlier
-
            03:30 <@mids> end of meeting time?
-
            03:30 <@mids> .
-
            03:31 <@mids> topic 7/8 Free 4 all Question round!!!
-
            03:31 <@mids> sorry for cutting you all off earlier
-
            03:31 <@mids> take revenge now
-
            03:31 <@Chocolate> lol
-
            03:31 <@nop> sorry
-
            03:31 <@nop> back
-
            03:31 <@mids> nop: 2 hours earlier meeting okay?
-
            03:31 <@nop> ooh
-
            03:31 <@nop> well, I'm in prime of working time
-
            03:31 <@mids> be honest
-
            03:32 <@nop> hmm
-
            03:32 <@nop> can we shoot for an hour earlier
-
            03:33 <@nop> I can get in trouble for chatting at work at that time in the day
-
            03:33 <@mids> yup
-
            03:33 <@mids> then we will try that
-
            03:34 <@nop> ok
-
            03:34 <@mids> okay... questions!
-
            03:34 -!- mids changed the topic of #iip-dev to: Meeting info, agenda, livelog (in case you are late): http://mids.student.utwente.nl/~mids/iip/ | current topic: Questions
-
            03:34 < Kronos-X> mids: Where are the .debs?
-
            03:34 < Kronos-X> ;)
-
            03:34 <@nop> teach us old wise one
-
            03:34 <@nop> and we will make .debs
-
            03:34 <@nop> :)
-
            03:34 <@mids> Kronos-X: you would make them!
-
            03:34 < Kronos-X> Heh.
-
            03:35 < Kronos-X> Sorry, I'm just here to bump the noise-to-signal ratio.,
-
            03:35 < Kronos-X> Let me pass the mic on to someone with a real question.
-
            03:35 <@nop> hehe
-
            03:35 <@mids> ptsc: any Q about the protocol?
-
            03:35 < Banks> ptsc has been idle 53mins 56secs :)
-
            03:36 <@mids> okay, banks' PDF is online on http://mids.student.utwente.nl/~mids/iip/meeting2/
-
            03:36 <@nop> did we discuss roadmaps
-
            03:36 <@nop> etdd
-
            03:36 <@mids> it looks cool already
-
            03:36 <@nop> etc
-
            03:37 <@mids> nop: only that rc2 depends heavily on docs
-
            03:38 <@nop> ok
-
            03:39 <@nop> this pdf kicks ass
-
            03:39 <@nop> just need the invisible irc logo in there
-
            03:40 <@nop> and you're done eh:)
-
            03:40 <@mids> I love the quotes and the screenshots
-
            03:40 < Banks> Casper?
-
            03:40 <@mids> even a FAQ!
-
            03:40 <@mids> Banks: why didn't you tell us before?
-
            03:40 < Banks> I spoke to codeshark but he didn't really say anything.
-
            03:42 <@nop> no
-
            03:42 <@nop> take the one off the site
-
            03:42 <@nop> for now
-
            03:42 < Banks> ok
-
            03:43 <@mids> I am going to sleep
-
            03:43 <@mids> logger will keep running for a while
-
            03:43 <@mids> thanks everybody for listening
-
            03:43 < Neo> l8r mids
-
            03:43 <@mids> night
-
            03:44 <@Chocolate> night
-
            03:44 < Banks> night mids
-
            03:44 < Kronos-X> Night, mids.
-
            03:44 < Aster> nite
-
            03:45 < ellison> l8r mids
-
            03:46 < Banks> Is there a logo in the works?
-
            03:48 <@nop> umm yeah
-
            03:48 <@nop> also
-
            03:48 <@nop> we want to have
-
            03:48 <@nop> pwered by InvisibleNet
-
            03:48 <@nop> and IIP now logo's
-
            03:49 < Banks> That's a good idea.
-
            03:49 <@nop> banks
-
            03:49 < Banks> It's hard to think of a logo that conveys IRC invisibility :)
-
            03:49 <@nop> excellent pdf
-
            03:49 < Aster> how long till these logos exist
-
            03:49 <@nop> we will definitely use it for distro with IIP
-
            03:49 < Banks> Cheers
-
            03:49 <@nop> well
-
            03:49 <@nop> I have some drafts of powered by invisiblenet
-
            03:49 <@nop> but you know
-
            03:49 <@nop> the goal of IRC is one thing
-
            03:49 <@nop> but in the future
-
            03:49 <@nop> Invisible Internet
-
            03:49 <@nop> so...
-
            03:50 < Banks> True
-
            03:50 <@nop> IRC Is main project
-
            03:50 <@nop> but it's so modular
-
            03:50 <@nop> that rumors might start
-
            03:50 < Banks> Logos with heads or faces seem to do pretty well. Redhat, Napster, etc.
-
            03:50 < Banks> Rumors?
-
            03:51 < Aster> banks: but do we want to copy the other guys, or come up with something unique, while still remeberable
-
            03:51 <@nop> it's a joke, basically it will be so modular anything can be put in as a protocol to anonymize
-
            03:51 < Banks> nop: I see :)
-
            03:52 < Banks> Aster: A head or face can still be unique. I think they're better than geometric patterns, etc.
-
            03:52 < Aster> yeah
-
            03:53 <@Chocolate> anyone with a camelion as a maskot?
-
            03:54 <@nop> geiko
-
            03:54 <@nop> insurance
-
            03:54 <@nop> :)
-
            03:54 <@Chocolate> damn
-
            03:54 <@Chocolate> the fuckers
-
            03:54 <@Chocolate> they're a terible companie
-
            03:55 < Banks> GameSpy has taken the Invisible Man thing
-
            03:55 <@nop> yes
-
            03:55 <@nop> they don't even do good at getting cheap insurance
-
            03:55 <@Chocolate> maby a klingon bird of prey?
-
            03:55 < Banks> :)
-
            03:55 <@Chocolate> cloaked you know ;)
-
            03:56 < Banks> Maybe footprints that disappear across the text.
-
            03:57 <@nop> hehe
-
            03:57 <@nop> ok, meeting is officially over
-
            03:57 <@nop> just to let you know
-
            03:58 <@nop> it's free for all
-
            03:58 <@nop> anyone have a good slogan for IIP
-
            03:58 <@mids> IIP - it keeps you awake
-
            03:58 <@nop> hehe
-
            03:58 < Neo> IIP - "Fuck the State"
-
            03:59 <@nop> umm
-
            03:59 < Neo> oh... sorry...
-
            03:59 <@nop> no
-
            03:59 < Neo> :) lol
-
            03:59 < Banks> I love that one Neo :)
-
            03:59 < Banks> IIP - "Stuttering Urinators."
-
            03:59 <@nop> hah
-
            03:59 <@nop> haha
-
            04:00 <@Chocolate> IIP - where animals talk
-
            04:00 < Banks> Heh heh
-
            04:01 < Banks> Maybe a Dog logo, you know, on the internet no one knows that you're a dog.
-
            04:01 < Banks> An invisible dog! :)
-
            04:01 < ellison> "and doubly-so with IIP"
-
            04:02 < Banks> IIP - "Where AOLers can be free from prejudice"
-
            04:03 <@nop> haha
-
            04:05 <@Chocolate> IIP - Talk to yourself without people laughing at you
-
            04:05 < Banks> Heh heh
-
            04:10 -!- CwZ|away is now known as Somedude
-
            04:11 <@Chocolate> hey Somedude
-
            04:11 < Somedude> hey Chocolate
-
            04:11 < Somedude> how goes?
-
            04:11 <@Chocolate> I'm ok, you?
-
            04:11 < Somedude> fine fine
-
            04:12 < Banks> Heh heh
-
            04:13  * Banks pm's Somedude, "We all hate Chocolate".
-
            04:13 < Somedude> yea I do too
-
            04:13 <@nop> hey guyes
-
            04:14 <@nop> email me sites you like
-
            04:14 <@nop> for examples of styles for IIP
-
            04:14 < Banks> Hmmm.
-
            04:14 <@nop> 0x90@invisiblenet.net
-
            04:17 < Mole> Ok, heres the deal: I am a p2p researcher and has al ot of nice algorithms that I have invented and tested for distributed systems.
-
            04:17 < Mole> I am currently looking for some project with which I should share my knowledge.
-
            04:18 < Banks> You've come to the right place :)
-
            04:18 < Banks> nop is your man.
-
            04:18 < Mole> I just found iip some minutes ago.
-
            04:18 < Mole> I guy in #freenet on openprojects.net recommend you.
-
            04:18 < Mole> Well, heres what i got so far:
-
            04:19 <@nop> k
-
            04:19 < Mole> * All my algorithms are completely distributed and is not dependant on any central server.
-
            04:20 < Mole> * An algorithm to keep together a network with anything from 2 to 20000000000 nodes. :))
-
            04:20 < Mole> * That network never gets netsplits and cant be crashed as far as I know. 
-
            04:20 <@nop> mole
-
            04:20 <@nop> please email iip@invisiblenet.net
-
            04:20 <@nop> with it
-
            04:20 <@nop> along with your pubkey
-
            04:21 < Mole> * Algorithm to announce subnets/services on the main network. (Aad subnets on the subnets.)
-
            04:21 <@nop> can it remain anonymous
-
            04:21 <@nop> and help not give too much info
-
            04:21 < Mole> * Algorithms to collect statistics like number of nodes, average and median values et.c.
-
            04:22 < Mole> * Algorithms to keep secret hwhat different nodes does on the network and what services they are suppliyng.
-
            04:22 <@nop> why Mole for a nick
-
            04:22 < Mole> And I am curently I am working to solve the distributed secure efficient database. :)
-
            04:22 <@nop> kewl
-
            04:22 < Mole> Well, Mole has been my Internet nick since 1991.
-
            04:23 < Mole> I myself is not a very secret person. :)
-
            04:23 < ellison> Mole: you familiar with quorum based distributed data systems?
-
            04:23 < Mole> But I like to supply secresy to people. :)
-
            04:23 <@nop> had a feeling those algo's are secret
-
            04:23 <@nop> :)
-
            04:23 < Mole> nope, not quorum.
-
            04:23 <@nop> quorum or quantum
-
            04:23 < ellison> lotsa cool work being done there
-
            04:24 < ellison> quorum
-
            04:24 < Mole> Kind of been into my research and simulations to much so I am currently taking a long break to check what other projects there are out there.
-
            04:24 < ellison> it's basically a distributed databases structure where many entities can have read/write access, but the system is protected from attempts at corruption by any of those entities
-
            04:24 < ellison> really useful for certain types of data structures/purposes
-
            04:25 < ellison> http://citeseer.nj.nec.com/malkhi97byzantine.html
-
            04:25 <@Chocolate> Mole: I recomened you here :)
-
            04:25 <@Chocolate> got a spybot going in #freenet here
-
            04:26 < Mole> Ok, Ill check quorum out to.
-
            04:26 < Mole> Well, now I have lots of questions about IIP to see what good my algorithms and knowledge might do for you. :)
-
            04:27 < Mole> First of all, is there any documentation of how IIP works anywhere?
-
            04:28 <@nop> yes
-
            04:28 <@nop> banks
-
            04:28 <@nop> where's that link
-
            04:28 < Banks> Wait one
-
            04:28 < Banks> http://mids.student.utwente.nl/~mids/iip/meeting2/iipdoc.pdf
-
            04:29 < Banks> Mole: You'll probably want to read mainly chapter 1 and chapter 9.
-
            04:29 < Mole> Ok, downloading it.
-
            04:32 <@nop> I have to run
-
            04:32 <@nop> see ya guys later
-
            04:33 < Banks> Seeya nop
-
            04:33 < Mole> Hey you gues are really friendly. Lots of chats in all windows and private cahts too.
-
            04:33 < Banks> :)
-
            04:36 < Mole> I'll read all the stuff you all recommended and talk to you some other day when I know more. :)
-
            04:37 < Banks> That'd be great :)
-
            06:07 < Mole> Ahh, I just browsed through iipdoc.pdf and now I think I understand how IIP works.
-
            06:08 < Mole> If I got it right there are allmost normal IRC-servers in the "backbone" ?
-
            06:12 < Mole> And you are planning on making verions 2.0 fully decentralised.
-
            06:12 < Mole> Have any design work or algorithm research been done on the decentrailsed structure for verison 2.0 ?
-
            06:20 <@Chocolate> some
-
            06:20 <@Chocolate> still r&d
-
            06:21 < Mole> Ok, I think I can be of use to you then. :)
-
            06:36 < Aster> k
-
            06:37 < Mole> Ok, well here are my thoughts on anonymous DCC chat and file send:
-
            06:38 < Mole> Add a socks-proxy to the "IIP-client".
-
            06:38 < Mole> Tell the users to configure their IRC client to run through the IIP-socks-proxy.
-
            06:39 < Mole> That means all the DCC connections will go to the IIP-socks-proxy.
-
            06:40 < Mole> The when the IRC-client (like mIRC) wants to connect to mole.anon.iip the proxy sends that connection through some of the other
-
            06:40 < Mole> nodes in the network until it finally reaches the node you want to DCC.
-
            06:41 < Mole> Thus you got an anonoymous DCC!
-
            06:41 < Mole> Waht do you think?
-
            06:41 < Aster> dcc involves files right (im not a big irc kid)
-
            06:42 < Mole> Yep.
-
            06:43 < Mole> So it will create much network load for the nodes that the connection "bounces" through.
-
            06:43 < Aster> yeah...the only problem i see is that now, when you start sending your file, its gotta go through all the other servers, causing lots of traffic
-
            06:43 < Aster> yeah
-
            06:44 < Mole> But since allmost all nodes should be assisting the distributed net that network load could be spread pretty equally.
-
            06:44 < Mole> But it will of course be slower "downloads" than over unsafe DCC.
-
            06:45 < Mole> Ahh, network split?
-
            06:46 < Aster> sorry, i missed your last few messages 
-
            06:46 < Mole> Repating: But since allmost all nodes should be assisting the distributed net that network load could be spread pretty equally.
-
            06:46 < Mole> Repeating: But it will of course be slower "downloads" than over unsafe DCC.
-
            06:46 < Aster> yeah
-
            06:47 < Mole> So it has to be discussed if it should be implented.
-
            06:47 < Aster> not really though about the spread out network load...each node still has to relay, lets say, 10mB no matter how many other nodes are there
-
            06:47 < Mole> But atleast it is very simple to implement if you decide to use it.
-
            06:47 < Aster> yeah
-
            06:48 < Mole> Not with my algorithms. :) Then each node only has to relay about 500 byte / second.
-
            06:48 < Mole> Excpet for the DCC data ofcourse....
-
            06:49 < Mole> Lets go to my next simple algorithm:
-
            06:49 < Mole> To create network efficient channel communications you do like this:
-
            06:50 < Mole> Provided that each user has his own local IIP-node:
-
            06:51 < Mole> That is, all the data we are creating while chatting only travles among the nodes taking part in the chat.
-
            06:51 < Mole> Thus not loading the rest of the network.
-
            06:51 < Mole> We have to ad one thing though for anonymity:
-
            06:51 < Mole> The nodes actually taking part in the mini network for the channel
-
            06:52 < Mole> is only front ends for the real chatters.
-
            06:52 < Mole> That is each node connects to a front end (perhaps in two or more levels) and it is the front end that joins the channel-network.
-
            06:53 < Mole> That save a lot of communication bandwidth!
-
            06:53 < Mole> and also makes the network much more robust.
-
            06:53 < Aster> hum
-
            06:54 < Aster> interesting
-
            06:55 < Aster> brb....i need to lay down for a bit..back hurting
-
            06:55 < Mole> chatter node <-> intermediate <-> frontend <- channelnet -
-
            06:55 < Mole> > frontend <-> intermediate <-> chatter node
-
            06:56 < Mole> Any other of you guys have any comments?
-
            07:18 -!- Zwollywood is now known as Zwolly
-
            07:21 < Mole> Hi Zwolly
-
            07:22 < Zwolly> hello
-
            07:22 < Zwolly> one moment
-
            07:23 < Mole> Are you working with IIP-development?
-
            07:24 < Zwolly> no i am just an user
-
            07:24 < Zwolly> i think i am to late for the meetibg
-
            07:25 < Mole> Ahh, me to.
-
            07:25 < Mole> Yep, the meeting was hours ago.
-
            07:25 < Mole> I am thinking on joining the development team.
-
            07:25 < Zwolly> http://mids.student.utwente.nl/~mids/iip     there is some info there
-
            07:25 < Zwolly> great 
-
            07:25 < Zwolly> if you got the skills and they can use some one
-
            07:26 < Mole> Yep, I got the skills. Researched decentralised p2p systmes since 1997...
-
            07:27 < Mole> Thanks for the reminder of the URL.
-
            07:28 < Mole> I checked it again and there were more stuff there then I noticed when I took a first look some hours ago.
-
            07:28 < Zwolly> only thing i know of making programs is how to make them crash hehe
-
            07:28 < Mole> Well, sounds like you could bee a good beta-tester  then?
-
            07:29 < Zwolly> yeh maybe
-
            07:29 < Zwolly> i am busy on an dutch translation of the manual so maybe i can help a little with that
-
            07:29 < Mole> I find it funny that they have a command to add your website to your ncik.
-
            07:30 < Mole> Just read about the extra commands IIP has.
-
            07:30 < Zwolly> yeh that is a nice option
-
            07:32 < Mole> Oops, I looked in the "livelog.txt" on the site IIP site.
-
            07:34 < Mole> Whoops, got disconnected.
-
            07:35 < Zwolly> yeh i see
-
            07:35 < Zwolly> also an point on agenda 
-
            07:35 < Zwolly> more stable connections
-
            07:36 < Mole> hehe, yep.
-
            07:37 < Mole> It is possble to build networks that use multiple tcp-connections to make things very robust.
-
            07:38 < Zwolly> yeh i am reading about that but need to see it first before i believe it
-
            07:38 < nop> dang
-
            07:38 < nop> meeting still going?
-
            07:38 < Zwolly> now reading log file
-
            07:38 < Zwolly> no
-
            07:39 < Zwolly> just some people talking and reading what they have missed
-
            07:39  * mids kicks everybody out
-
            07:40 <@mids> MEETING IS OVER
-
            --- Log closed Wed May 29 07:40:24 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting20.html b/www.i2p2/pages/meeting20.html
deleted file mode 100644
index 42f68eeb..00000000
--- a/www.i2p2/pages/meeting20.html
+++ /dev/null
@@ -1,413 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 20{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 20
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Nov 19 23:51:34 2002
-
            23:52 < logger> test
-
            23:52 -!- mode/#iip-dev [+o mids] by Trent
-
            23:52 -!- mode/#iip-dev [+v logger] by mids
-
            23:53 -!- mode/#iip-dev [+oo nop UserX] by mids
-
            23:57 <@mids> public IIP meeting in channel #iip-dev starting in 2.5 minutes
-
            23:57 < nemesis> lol
-
            23:57 < zic> anybody from Ukrain? message me! hehehe
-
            23:58 -!- mode/#iip-dev [+o hezekiah] by mids
-
            23:58 <@hezekiah> Hello again, mids!
-
            23:58 < Robert> Hey Nemesis, have you seen http://www.bash.org/?top
-
            23:58  * athena sees hezekiah in a whole new light :p
-
            23:58 < nemesis> bash?
-
            23:58 <@mids> Robert: they are down
-
            23:58 <@mids> what!
-
            23:58 <@mids> they are back!
-
            --- Day changed Wed Nov 20 2002
-
            00:00 <@mids> Tue Nov 19 23:00:00 UTC 2002
-
            00:00 <@nop> welcome
-
            00:00 <@nop> welcome
-
            00:00 <@nop> to the 20th?
-
            00:00 <@nop> IIP meeting
-
            00:00 <@hezekiah> 20th!
-
            00:00 <@mids> yes
-
            00:00 <@nop> yes on the agenda today...
-
            00:01 <@nop> mids...
-
            00:01 <@mids> 1) welcome
-
            00:02 <@mids> 2) getting rc3 out
-
            00:02 <@mids> 3) sneak preview on rc3
-
            00:02 <@mids> 4) snacks and drinks
-
            00:02 <@mids> 5) questions
-
            00:02 <@mids> .
-
            00:02 <@nop> thnx
-
            00:02 <@nop> ok
-
            00:02 <@nop> so we are having rc3 officially released thursday
-
            00:02 <@nop> please mark that in your calendars
-
            00:02 <@mids> we hope :)
-
            00:02 <@mids> (unless sourceforge is down again)
-
            00:03 <@nop> right, did they fix the ro on nfs?
-
            00:03 <@mids> yes
-
            00:03 <@nop> was it their mistake?
-
            00:03 < tarpY> i am here for the food
-
            00:03 <@mids> it was announced on their status page btw
-
            00:03 <@nop> ok
-
            00:03 <@mids> maintenance
-
            00:03 <@nop> gotcha
-
            00:03 <@nop> probably doing backups
-
            00:03 < tarpY> i wanted to order pizza off of the freenet and i found out they wont
-
            00:03 <@nop> :)
-
            00:03 < tarpY> where can i get food here
-
            00:03 <@mids> tarpY: #muchnies-to-take-away
-
            00:04 <@nop> ok
-
            00:04 <@mids> what will be new in rc3:
-
            00:04 <@nop> so Thursday we will get that out
-
            00:04 <@nop> oh
-
            00:04 <@nop> Mids, I believe you have the changelog handy
-
            00:04 <@nop> if not
-
            00:04 <@mids> me too
-
            00:04 <@nop> I'll display
-
            00:04 <@nop> ok
-
            00:04 < sinster> will rc3 have a decent install script for *nix?
-
            00:04 <@mids> - Display of version number for windows (menu option) and unix (command line).
-
            00:04 <@mids> - Random number generation fix.
-
            00:04 <@mids> - IIP network connections are no longer paused while in the setup screen.
-
            00:04 <@mids> - Now exits if it can't bind to a socket at startup.
-
            00:04 <@mids>   Windows now displays a message box informing that it can't bind to port.
-
            00:04 <@mids> - Several bugfixes and one memory leak fixed.
-
            00:04 <@mids> .
-
            00:04 <@mids> sinster: no, that is what hezekiah is working on
-
            00:05 <@mids> that will be 1.2
-
            00:05 <@hezekiah> Not quite ...
-
            00:05 <@nop> ok
-
            00:05 < zic> are there plans for translating the (nice) faq @ help.invisiblenet.net ?
-
            00:05 <@nop> anyone who wants to translate
-
            00:05 <@nop> please do
-
            00:05 < sinster> mids/hezekiah: will it add iip to /etc/rc.d/ so that it starts automatically?  just a suggestion
-
            00:05 <@nop> we would very much appreciate it
-
            00:05 <@nop> and have it on the site
-
            00:05 < zic> will rc3 demand any mod in the FAQ?
-
            00:06 <@mids> sinster: I got a script here... but that needs more testing
-
            00:06 <@mids> sinster: maybe we'll add that with 1.1 final
-
            00:06 <@hezekiah> sinster: that would not be distribution compatible, since different distros put startup stuff in different places.
-
            00:06 <@mids> zic: no
-
            00:06 < sinster> mids: yeah, make sure you test it on the major linux flavors, redhat, debian etc
-
            00:06 <@nop> well, can we wait on quesitons
-
            00:06 <@nop> please
-
            00:06 < zic> my isproxy is scripted in /etc/init.d (debian), works perfectly
-
            00:06 <@mids> oops
-
            00:06 <@nop> till the questions and answers
-
            00:06 < zic> sorry!
-
            00:06 < zic> sorry!
-
            00:06 <@hezekiah> Sorry.
-
            00:06 <@nop> it gets confusing
-
            00:06 <@nop> ;)
-
            00:06 <@nop> sorry
-
            00:06 < sinster> nop: ok
-
            00:06 < tarpY> no translating everyone should speak english.
-
            00:07 < sinster> nop: my bad
-
            00:07 <@nop> no prob
-
            00:07 <@mids> any questions on the changelog?
-
            00:07 <@mids> no?
-
            00:07 <@mids> nop: sneak preview?
-
            00:07 <@nop> hold my relay just bit the dust
-
            00:08 <@nop> wait till everyone comes back 
-
            00:08 <@mids> auch
-
            00:08 <@nop> delay can be annoying in a meeting
-
            00:08 <@nop> ;)
-
            00:08 <@nop> everyone still here?
-
            00:08 <@mids> seems like it
-
            00:09 <@hezekiah> I didn't see anyone leave.
-
            00:09 <@nop> ok
-
            00:09 < zic> i am (does i matter? hehe)
-
            00:09 <@nop> well there is a delay feature we have
-
            00:09 <@nop> ;)
-
            00:09 <@nop> ok
-
            00:09 < al-jabr> I didn't either.
-
            00:09 <@nop> guess my relay got kicked off the list for unreliability
-
            00:09 <@nop> haha
-
            00:09 <@mids> hehe
-
            00:09  * Robert joins #muchnies-to-take-away while he waits...
-
            00:09 <@mids> there we go
-
            00:09 <@nop> yep
-
            00:10 <@nop> there's another
-
            00:10 <@nop> ;)
-
            00:10 < al-jabr> there goes five.
-
            00:10 <@hezekiah> We really need to do something about that. :(
-
            00:10 < nemesis> erm
-
            00:10 < nemesis> mids
-
            00:10 <@nop> hezekiah: spread spectrum routing
-
            00:11 < tc> is this glitches in the relay system?
-
            00:11 <@nop> ;)
-
            00:11 <@nop> my windows relay box crashed
-
            00:11 <@nop> typical
-
            00:11 < nemesis> for win2k / xp, thers in the future a build without gui
-
            00:11 <@hezekiah> lol
-
            00:11 < nemesis> or only gui to setup
-
            00:11 < nemesis> and the rest as an daemon?
-
            00:11 <@nop> it would be nice to have it as a service
-
            00:11 <@nop> ;)
-
            00:12 < nemesis> yes 
-
            00:12 < nemesis> ;)
-
            00:12 <@nop> there is a program out there called service installer
-
            00:13 <@nop> ok
-
            00:13 <@nop> well
-
            00:13 < nemesis> iip.exe --install
-
            00:13 <@nop> no more delays
-
            00:13 < nemesis> like apache for win
-
            00:13 <@mids> is everybody already back?
-
            00:14 <@nop> ok
-
            00:15 <@nop> welcome baci
-
            00:15 <@nop> back
-
            00:15 < nemesis> matrix's neo? ;)
-
            00:15 <@nop> ok
-
            00:15 <@nop> I think they are back
-
            00:16 <@mids> yes
-
            00:16 <@nop> ok
-
            00:16 <@nop> sneak preview
-
            00:16 <@mids> I made a FLT-iip.1.1-rc3-pre1-mids-sneak-preview-screaner.tgz
-
            00:16 <@mids> everybody with unix can test it
-
            00:16 <@mids> no windows version yet
-
            00:16 <@nop> I can make one right now
-
            00:16 <@nop> if you want
-
            00:16 < zic> lol
-
            00:16 <@mids> http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz
-
            00:16 < nemesis> thats ok
-
            00:16 < nemesis> i wait
-
            00:16 < zic> OGG or LAME audio?
-
            00:17 <@mids> I am especially looking forward to reports on obscure unix versions
-
            00:17 <@mids> like netbsd etc
-
            00:17 < nemesis> i think, its not so important when a unix machine crash with 30 days uptime
-
            00:17 <@mids> and macosx
-
            00:17 < nemesis> as an windows machine with 3 days uptime ;)
-
            00:17 < tc> mids:  is this change just in the isproxy or in any other relay stuff also?
-
            00:17 <@nop> no
-
            00:17 <@nop> you keep your settings
-
            00:17 <@nop> did we test that it can install over the previous one
-
            00:17 <@nop> hmm
-
            00:18 <@nop> make a note
-
            00:18 < zic> nemesis: but it would be cool if it never crashed. but let's kill the talking here. we are in a formal meeting
-
            00:18 < nemesis> hehe
-
            00:18 <@nop> ok
-
            00:18 <@nop> if anyone wants to test if the upgrade process is trivial
-
            00:18 < nemesis> don't test it on meeting days ;)
-
            00:18 <@nop> then please go ahead
-
            00:18 <@nop> and email or notify one of the devs of the results
-
            00:18 <@mids> please test it next to your current relay
-
            00:18 <@mids> and yes, please give feedback
-
            00:19 <@mids> on what went wrong
-
            00:19 <@mids> etc
-
            00:19 <@nop> wb tarpY 
-
            00:19 <@nop> let's put that screener in the topic
-
            00:19 < goc> is it possible to run isproxy-rc2 and isproxy-almost-rc3 simultaneously?
-
            00:19 <@nop> yes
-
            00:20 <@nop> different port settings
-
            00:20 <@nop> and it's not hard at all
-
            00:20 < goc> where's the conf file stored?
-
            00:20 <@nop> but rc3 should be able to go over rc2
-
            00:20 <@nop> you might have to do a -f /dir 
-
            00:20 <@nop> or you may have it go over the rc2 install
-
            00:21 < tarpY> are you going to eventually remove the proxy and integrate it into a client?
-
            00:21 <@nop> probably not
-
            00:21 <@nop> the idea is transparent applications
-
            00:21 <@nop> it's a transport medium
-
            00:21 <@nop> and we'll remove the server
-
            00:21 <@nop> and integrate it into the proxy yes
-
            00:22 <@nop> mids, can we have your link on the topic
-
            00:22 <@nop> for the preview
-
            00:22 -!- mids changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback
-
            00:23 <@nop> ok
-
            00:23 < zic> compiling
-
            00:23 <@nop> so that's the rc3 unix preview
-
            00:23 <@nop> next on agenda
-
            00:23 <@nop> I think it's food and drinks
-
            00:23 <@mids> snacks and drinks
-
            00:23 < zic> i want pizza
-
            00:24  * mids gives a Quattro-Strationi to zic 
-
            00:24 < zic> it's stinking :-/
-
            00:24 < zic> what did you put on that?
-
            00:24 <@mids> ok
-
            00:24 <@mids> questions?
-
            00:24 < zic> i have
-
            00:24 < tc> zic: dead fish
-
            00:24 < zic> tc ehhe
-
            00:25 < tc> does this just change the proxy?
-
            00:25 < zic> i propose a translation project... 
-
            00:25 <@nop> also
-
            00:25 <@nop> we need a doc writer
-
            00:25 <@nop> for technical documentation
-
            00:25 <@nop> updates
-
            00:25 <@mids> volunteers?
-
            00:26 < zic> i would be, but my english is bad hehe
-
            00:26 < zic> i prefer translating things
-
            00:26 <@nop> translation: any volunteer
-
            00:26  * zic !
-
            00:26 <@nop> what languages?
-
            00:26  * zic -=> portuguese only
-
            00:27 <@nop> ok
-
            00:27 <@nop> any other volunteers for specific languages
-
            00:27 < Fairwitness> English :)
-
            00:27 < nemesis> english and german ;)
-
            00:28 <@nop> English, is done, unfortunately it's the primary language
-
            00:28 <@nop> FW are you planning to assist with tech docs then
-
            00:28 <@nop> ?
-
            00:28 < Fairwitness> sure, if you want help. I like to write...
-
            00:28 < zic> i would like to help with something else, but i dont know what i need, and i am a mediocre coder
-
            00:28 < zic> s/i/you
-
            00:29 < Fairwitness> ...and I can't code for shit...
-
            00:29 <@nop> zic translation is great
-
            00:29 < zic> i can make debian packages
-
            00:29 <@nop> that's definitely a plus
-
            00:29 < zic> but this is not good for RC
-
            00:29 <@nop> correct
-
            00:29 < zic> but i can test it
-
            00:29 <@nop> but debian wants to include IIP as a package when stable
-
            00:30 < zic> is there anybody doing this?
-
            00:30 <@mids> I got to sleep now
-
            00:30 <@mids> ...
-
            00:30 <@mids> bye all
-
            00:30 <@nop> ok
-
            00:30 <@hezekiah> Bye!
-
            00:30 < Fairwitness> bye mids
-
            00:30 < zic> bye mids
-
            00:30 <@nop> ok so FW
-
            00:30 <@nop> can you assist with docs
-
            00:30 < tc> bye
-
            00:30 < Neo> nightz
-
            00:30 < Fairwitness> sure, what do you need done?
-
            00:30 <@nop> I have to upgrade the docs on encryption
-
            00:30 <@nop> and we're going to need docs for 1.2
-
            00:31 <@nop> soon
-
            00:31 <@nop> and full regular docs for 1.1 stable that have been reviewed
-
            00:31 <@nop> and are considered good for general audience
-
            00:31 < Fairwitness> define "general".
-
            00:31 < nemesis> ;)
-
            00:32 <@nop> well, when stable is released
-
            00:32 <@nop> we'd like a good docs to accompany
-
            00:32 < nemesis> that i understand this ;)
-
            00:32 < Fairwitness> general public or general crypto techno fetish geek 
-
            00:32 < Fairwitness> :)
-
            00:32 <@nop> a little in between
-
            00:32 < nemesis> hrhr
-
            00:32 < nemesis> make some nice pictures
-
            00:32 <@nop> enough to be in the middle and answers questions for all users
-
            00:32 < nemesis> and say this is the securest irc network
-
            00:32 < nemesis> like m$
-
            00:32 < nemesis> this winxp is the stablest windows
-
            00:33 < nemesis> ;)
-
            00:33 < zic> "anoymousest"
-
            00:33 <@nop> haha
-
            00:33 < Fairwitness> Well if you give me the docs you have I can go through them and review and edit them for a general release.
-
            00:33 < zic> what about wiki documentation?
-
            00:33 <@nop> do you know how to make .chm file in windows
-
            00:34 < Fairwitness> In my RL I have got quite good an writing software docs that are understandable by "generl" folks as well as non english speakers.
-
            00:34 < nemesis> xml to chm?
-
            00:34 < nemesis> ;)
-
            00:34 < nemesis> or latex to chm
-
            00:34 <@nop> .chm is like the help doc in win32
-
            00:35 <@nop> we can discuss that later
-
            00:35 <@nop> ok
-
            00:35 <@nop> http://www.invisiblenet.net/iip/docsMain.php
-
            00:35 < nemesis> i know.. k later..
-
            00:36 <@nop> ok
-
            00:36 <@nop> any other questions?
-
            00:36 < zic> what is the future of mankind?
-
            00:37 < Fairwitness> are there any caffinated beverages here?
-
            00:37 < Fairwitness> if not, why not!
-
            00:37 <@nop> haha
-
            00:37 < tc> zic:  wonderous .. if we can survive assholes
-
            00:37 < Fairwitness> I demand intra venus V as my price for editing docs !!
-
            00:37 < Fairwitness> :)
-
            00:38 < Fairwitness> Hi Neo
-
            00:38 <@nop> ok
-
            00:38 <@nop> meeting officially ended
-
            00:38 < Fairwitness> but, my V!!
-
            00:38 < zic> hahaha
-
            00:39  * Fairwitness slumps in the chair.
-
            00:40 -!- mode/#iip-dev [+o Chocolate] by Trent
-
            00:40 -!- mode/#iip-dev [+n] by Chocolate
-
            00:40 <@Chocolate> damn I alwasy miss them :(
-
            00:40 < nemesis> hrhr
-
            00:40 < nemesis> Chocolate: ;)
-
            00:44 < zic> nictuku:/home/yves/freenet# [2002/11/19-23:41:02]:Socket(5), Error (98):Failed to bind listening socket.
-
            00:44 < zic> [2002/11/19-23:41:02]:sockListen: bind failed: host(127.0.0.1), port(6667)Failed to bind listening socket.
-
            00:45 < zic> it should say it exited
-
            00:45 <@hezekiah> If you do a "ps -e | grep isproxy" you shouldn't see it on the list.
-
            00:45 < zic> i know
-
            00:45 <@hezekiah> However, that is a good idea.
-
            00:45 < zic> but it should printf that
-
            00:47 < sanity> are you talking about how to kill isproxy?
-
            00:47 <@hezekiah> No. What isproxy should do when it doesn't load.
-
            00:52 < zic> is iip already meant to be popular?
-
            00:52 < nemesis> i don't know
-
            00:52 < nemesis> it's like
-
            00:53 < nemesis> cryptomail
-
            00:53 < zic> i bet it isnt in freshmeat and tucows, for example.. is it? it could
-
            00:53 < nemesis> when there are no way to share files with more than under 1kbyte/sec then i don't have a good look at the future
-
            00:54 < zic> but iip is not about sharing files.. 
-
            00:55 < nemesis> thats true
-
            00:55 < nemesis> but what can i do with an chating plattform
-
            00:55 < nemesis> when i can't send the other people the newest own mp3 mix?
-
            00:56 < zic> chat!
-
            00:56 < nemesis> theres to many options what you can do with files
-
            00:56 < nemesis> when it's only a chatlog
-
            00:56 < zic> i bet in OPN ppl dont care about sending things
-
            00:56 <@Chocolate> zic: iip is on freshmeat I beleave
-
            00:56 < nemesis> what you will send the other one
-
            00:56 < nemesis> or a new perlscript for xchat
-
            00:56 < nemesis> and so on
-
            00:57 < nemesis> desktop pics
-
            00:57 <@Chocolate> nemesis: use fileserv.pl, it's under the GPL so you can make any modifications you want
-
            00:57 < zic> i think he knows that chocolate
-
            00:57 < nemesis> erm
-
            00:57 <@Chocolate> zic: well I forgot to include the licence header in the file so :)
-
            00:57 < nemesis> test it on windows with xchat and active perl please
-
            00:58 < nemesis> and say me how i can use it
-
            00:58 < nemesis> or make a faq
-
            00:58 < zic> Chocolate: oh yes, you made it. thank you, btw
-
            00:58 < nemesis> ;)
-
            00:59 < zic> Chocolate: is it possible to make a perl-version compatible MIRC script ?
-
            00:59 < nemesis> ;)
-
            01:00 < nemesis> where need a shareware?
-
            01:00 < nemesis> xchat under win is more stable and open than mirc
-
            01:00 < nemesis> i only miss the drag and drop option bye filesend
-
            01:00 < zic> but mirc is far more popular
-
            01:00 < nemesis> and?
-
            01:01 < zic> and many IIP users use mirc
-
            01:01 < nemesis> i had mirc 6.00 for 1 to 2 month
-
            01:01 < nemesis> it crashes always after some hours
-
            01:01 < zic> i used mirc all my life
-
            01:01 < zic> i like mirc a lot
-
            01:01 < nemesis> and it takes 3 month or so for the next version
-
            01:01 < nemesis> then
-
            01:01 < nemesis> the multiserv
-
            01:01 < nemesis> in the performlist
-
            01:01 < nemesis> it deleted and reorganized the list
-
            01:02 < nemesis> in xchat i can use the (very slow) transparent windowbackground
-
            01:02 < nemesis> have good ssl support for other irc networks that support this
-
            01:02 < zic> nemesis: ok, but ppl use it, so fileserver.pl must have a compatible clone for mirc...
-
            01:03 < nemesis> for every server a own perform list and so on
-
            01:03 < nemesis> mirc
-
            01:03 < nemesis> thats an programing language the mirc script?
-
            01:04 < zic> hmm it's mirc's own scripting language
-
            01:04 < zic> which is btw very known, my first interpreted language was mirc's
-
            01:05 < nemesis> lol
-
            01:05 < nemesis> *sorry*
-
            01:05 < nemesis> make a good if then constallation
-
            01:05 < nemesis> i stopped it
-
            01:06 < nemesis> cause i can't finde the way to make it possible in mirc
-
            01:06 < zic> why not?
-
            01:07 < zic> well, nevermind
-
            01:07 < nemesis> it's to hard to explain it in english sorry guy
-
            01:08 < zic> ok, dont worry, sorry for pushing
-
            01:08 < zic> what i meant is just that fileserver.pl needs compatibility.. hehe
-
            01:08 < nemesis> kk
-
            01:09 < nemesis> find a way in your mirc scripting language ;)
-
            01:09 < zic> :-/
-
            01:09 < zic> i dont even use windows anymore
-
            01:09 < nemesis> i only liked the easy way to make windows with mirc
-
            01:29 < sanity> .
-
            01:29 < zic> '
-
            01:31 < zic> going to opn, see you
-
            02:44 < dd0c> is this rc3 preview useable?
-
            02:44 < dd0c> heh dumb question
-
            --- Log closed Wed Nov 20 10:43:44 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting200.html b/www.i2p2/pages/meeting200.html
deleted file mode 100644
index a762ef36..00000000
--- a/www.i2p2/pages/meeting200.html
+++ /dev/null
@@ -1,79 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 200{% endblock %}
-{% block content %}
            I2P dev meeting, February 13, 2007
            
-
            
-
            15:04 < jrandom> 0) hi
            
-
            15:04 < jrandom> 1) Net status and 0.6.1.27
            
-
            15:04 < jrandom> 2) Syndie dev status
            
-
            15:04 < jrandom> 3) trac.i2p.net
            
-
            15:04 < jrandom> 4) ???
            
-
            15:04 < jrandom> 0) hi
            
-
            15:04  * jrandom waves
            
-
            15:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001334.html 
            
-
            15:05 < jrandom> lets jump on in to 1) Net status and 0.6.1.27
            
-
            15:06 < jrandom> zzz: wanna give us the rundown of the main bugfixes/improvements we'll find in i2psnark?
            
-
            15:07 <+zzz> um, it's all over the map, see history.txt :)
            
-
            15:07 < green> We can't say anything about that since you don't have work on it for a long time, humm !
            
-
            15:08 < green> So there isn't new to discuss
            
-
            15:08 < jrandom> heh ok zzz, fair 'nuff :)
            
-
            15:08 <+zzz> should be more robust for torrents with large number of seeders, some UI improvements, some bug fixes, support for multi-file torrent creation, etc etc
            
-
            15:08 <+zzz> BTW w00t mtg 200
            
-
            15:09 < jrandom> zounds
            
-
            15:09 < jrandom> ok word
            
-
            15:09 < jrandom> my plans right now are just to add in the simple whispering for the floodfill peers (so people don't lose track of them as easily)
            
-
            15:09 < jrandom> are there any other low hanging fruit i should address before tagging & pushing?
            
-
            15:10 <+zzz> that sounds smarter than waiting for me to do it
            
-
            15:10 < jrandom> oh, i should disable the old syndie too
            
-
            15:11 < jrandom> (or at least its fetching)
            
-
            15:11 < jrandom> i've heard some suggestions to disable theepsite tunnel by default as well - any thoughts?  yea nea?
            
-
            15:11  * bar beats his not-yet-quite-dead "not have eepsite server tunnels autostart by default" horse
            
-
            15:12 <+zzz> I checked in a note on localhost/syndie/ warning people it's obsolete if you want to let it go one more release, up to you
            
-
            15:13 < jrandom> it might be worth keeping the content around for a while but killing the syndication
            
-
            15:13 < jrandom> ok, if anyone comes up with omething else, lemmie know
            
-
            15:14 <+zzz> if you do check to see if the note I added needs updating
            
-
            15:14 < jadeSerpent> i agree it shouldn't start serving pages out of box, no other app does that, potential security risk
            
-
            15:14 < green> Disabling default eepsite is a good idea as most people using I2P don't use it and others use user defined tunnels, you have just to look at orion stat with only ~30 sites online
            
-
            15:14 < jrandom> aye
            
-
            15:14 <+zzz> and ditto if you disable eepsite tunnel the instructions & default eepsite homepage need to be updated
            
-
            15:15 < jrandom> it won't disable already configured tunnels, it'll just affect new users
            
-
            15:15 < jrandom> true zzz
            
-
            15:15 <+zzz> prob. a good idea
            
-
            15:17 < green> but this is just a minor tweak not a improvemnt
            
-
            15:17 < jrandom> ok, anyone have anything else for 1) net status and 0.6.1.27?
            
-
            15:17 <+zzz> resources/eepsite_index.html "your eepsite is up and running but..."
            
-
            15:17 < jrandom> aye
            
-
            15:19 < green> jr : Courage, let us flee!
            
-
            15:19 < jrandom> ok jumping to 2) Syndie dev status
            
-
            15:20 < jrandom> lots going on here, of course
            
-
            15:20 < jrandom> beyond whats mentioned in the notes, once we get i2p 0.6.1.27 out i'm going to clear a bunch of the open bugs for next week's 1.004a release
            
-
            15:21 <+fox> * thecrypto waves as he returns after a very very long hiatus from this project
            
-
            15:21 < jrandom> anyone want to bring up anything for 2) Syndie dev status?
            
-
            15:21 < jrandom> woah!
            
-
            15:21 < jrandom> wb thecrypto
            
-
            15:22 <+fox> <thecrypto> Thank you
            
-
            15:22 < jrandom> still hacking on an i2p 0.1 sdk? :)
            
-
            15:22 <+zzz> back for the 200th anniversary?
            
-
            15:23 <+fox> <thecrypto> I guess so :) But I'm hoping to get back up to speed on this stuff as I've been looking around at what else is out there and it all sucks :)
            
-
            15:24 < jrandom> heh cool
            
-
            15:24 <+fox> * thecrypto takes a seat off to the side to let the rest of the meeting proceed
            
-
            15:25 < jrandom> ok, if there's nothing else for 2) Syndie dev status, lets jump to 3) trac.i2p.net
            
-
            15:25 < jrandom> by popular (and reasonable) demand, we've migrated from the in-syndie bugtracker to a real bugtracker
            
-
            15:26 < jrandom> please use it if you can to file bug reports (though bug reports filed with syndie will be automatically imported into it after a delay)
            
-
            15:26  * jadeSerpent claps
            
-
            15:27 <+fox> <thecrypto> Trac works very well, use it at my day job. Have you integrated CVS into it?
            
-
            15:27 < jrandom> monotone (our dvcs), yes
            
-
            15:27 < jrandom> https://trac.i2p.net/browser
            
-
            15:28 <+fox> <thecrypto> Neat, migrated to DVCS :) Good time for me to rejoin :)
            
-
            15:28 < jrandom> mos' def'
            
-
            15:29 < jrandom> at the moment, the wiki is basically disabled, but might get some use at times for working through some issues
            
-
            15:29 < jrandom> i'm not sure if/when it'll get used though, but we'll see
            
-
            15:30 < jrandom> ok, anyone have anything else for 3) trac.i2p.net ?
            
-
            15:31 < jrandom> if not, lets jump to good ol' fashioned 4) ???
            
-
            15:31 < jrandom> anyone have something else to bring up for the meeting?
            
-
            15:33 <+fox> <thecrypto> Glad to be bck
            
-
            15:33 < jadeSerpent> does it always get really laggy around meeting time?
            
-
            15:35 < jrandom> jadeSerpent: more than usual, yeah, though not that bad (i'm @ 1.46s lag)
            
-
            15:35  * jrandom winds up
            
-
            15:35  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting201.html b/www.i2p2/pages/meeting201.html
deleted file mode 100644
index add47182..00000000
--- a/www.i2p2/pages/meeting201.html
+++ /dev/null
@@ -1,40 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 201{% endblock %}
-{% block content %}
            I2P dev meeting, February 20, 2007
            
-
            
-
            14:59 < jrandom> 0) hi
            
-
            14:59 < jrandom> 1) Net status
            
-
            14:59 < jrandom> 2) Syndie dev status
            
-
            15:00 <+void> jrandom: fyi, bookmark management is not working as of 8e18877de3908c52daae6d8a85fc8c671cdfb5d5
            
-
            15:00 < jrandom> 3) ???
            
-
            15:00 < jrandom> 0) hi
            
-
            15:00  * jrandom waves
            
-
            15:00 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001336.html
            
-
            15:01 < jrandom> void: drag and drop onto the bookmarks currently doesn't refresh the display (the bookmarks are added but not shown) - working on that in the other dwindow atm :)
            
-
            15:01 <+void> ah :)
            
-
            15:01 < jrandom> if thats not what you're referring to, please file a bug report
            
-
            15:01 <+void> (well, i already filed a bug report for that
            
-
            15:01 <+void> )
            
-
            15:02 < jrandom> w3wt
            
-
            15:02 < jrandom> ok, lets jump into 1) Net status
            
-
            15:02 < jrandom> i don't really have much to add beyond whats in the status notes
            
-
            15:04 < jrandom> anyone have anything they'd like to add re: 1) Net status?
            
-
            15:06 < jrandom> if not, lets shimmy on over to 2) Syndie dev status
            
-
            15:06 < bar> jrandom: yeap, Traditional Chinese language support fixed the "china.i2p" issue and Simplified Chinese fixed your "peace" post
            
-
            15:06 < jrandom> ah great bar
            
-
            15:06 < bar> (oops, sry!)
            
-
            15:08 < jrandom> in theory we could bundle actual fonts and distribute them with syndie (which might make sense in some situations, like the preinstalled CDs/images that anonymous recently discussed)
            
-
            15:10 < jrandom>  (specifically, in the bug report @ urn:syndie:channel:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=9:messageIdi1171666081846ee )
            
-
            15:10 < jrandom> anyway, regarding syndie dev status, lots going on there
            
-
            15:10 < jrandom> i expect we'll have a new release out later this week with the latest goodies
            
-
            15:12 < jrandom> as always, keep those bug reports and feature requests flowin, and we'll get 'em addressed as soon as possible
            
-
            15:12 < jrandom> anyone have anything to add re: 2) Syndie dev status?
            
-
            15:15 < jrandom> ok if not, lets slide to 3) ???
            
-
            15:15 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            15:16 <+Complication> not anything I'd recall in a hurry :)
            
-
            15:18 <+Complication> (not yet, at least)
            
-
            15:18 < jrandom> heh in that case...
            
-
            15:18  * jrandom winds up
            
-
            15:18  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting202.html b/www.i2p2/pages/meeting202.html
deleted file mode 100644
index f3386871..00000000
--- a/www.i2p2/pages/meeting202.html
+++ /dev/null
@@ -1,87 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 202{% endblock %}
-{% block content %}
            I2P dev meeting, March 13, 2007
            
-
            
-
            16:01 < jrandom> 0) hi
            
-
            16:01 < jrandom> 1) Net status and 0.6.1.28
            
-
            16:01 < jrandom> 2) Syndie dev status and 1.005a
            
-
            16:02 < jrandom> 3) Syndie GUI directions
            
-
            16:02 < jrandom> 4) Feb bug harvesting contest results
            
-
            16:02 < jrandom> 5) ???
            
-
            16:02 < jrandom> 0) hi
            
-
            16:02  * jrandom waves
            
-
            16:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001338.html
            
-
            16:02 < jrandom> y'all've had a few hours to read those (and of course to read the related syndie posts ;) so lets just jump in to 1) net status and 0.6.1.28
            
-
            16:04 < jrandom> there's been a bunch going on in this front lately - zzz wanna gives us a rundown of whats coming in 0.6.1.28?
            
-
            16:05 <+zzz> ok
            
-
            16:06 <+zzz> lots of improvements in tunnel building and upstream performance, mainly benefitting those who have a lot of outbound traffic or are upstream-bandwidth-constrained...
            
-
            16:06 <+zzz> like i2psnark users...
            
-
            16:06 <+zzz> I'm getting good results in testing so looking forward to getting it out there to all...
            
-
            16:07 < jrandom> [w3wt]
            
-
            16:07 <+zzz> I have one tweak to make a parameter configurable, as requested by Amiga4000, should get that in soon.
            
-
            16:08 <+zzz> And thx for the $$ offer, however please keep it in the bank.
            
-
            16:08 <+zzz> EOT :)
            
-
            16:08 < jrandom> r0x0r - added to halloffame.html :)
            
-
            16:09 <+zzz> haha I'm famous now
            
-
            16:10 < jrandom> the changes look pretty promising, and they do seem that they'll have their largest impact once its widely deployed
            
-
            16:11 < jrandom> just bounce me a msg when you want me to pull the trigger and i'll get it packaged and pushed w/in a day or so
            
-
            16:11 < jrandom> ok, anyone have anything they'd like to bring up re: net status?
            
-
            16:13 < jrandom> if not, lets hop on over to 2) syndie dev status
            
-
            16:14 < jrandom> lots going on here (as you can see if you're using syndie or following https://trac.i2p.net/timeline )
            
-
            16:14 < jrandom> i expect we'll have a new 1.005a release in the next day or two (obviously not including the things we're discussing in (3) below)
            
-
            16:15 < TrevorReznik> jrandom: do you have time for a short query?
            
-
            16:17 < jrandom> if its for the meeting, certainly (if its on 2), now is good, if it doesnt fit the agenda, we've got 5) ??? for everything else :)
            
-
            16:17 < jrandom> (if its not something for the meeting, hit me as a priv msg)
            
-
            16:17 < TrevorReznik> ok ;) ill wait
            
-
            16:18 < jrandom> ok, anyone have anything for 2) syndie dev status?
            
-
            16:20 < jrandom> if not, lets switch to 3) Syndie GUI directions
            
-
            16:20 < jrandom> as mentioned in the mail, lots going on in this direction - mk has put together some really interesting ideas and we'll likely see it in syndie sooner rather than later
            
-
            16:20 <+zzz> call me a traditionalist, but I think the current multipane thunderbird-like i/f is pretty good
            
-
            16:24 < jrandom> hmm, with the multipane view, would that fit more with mk's mods than our current multitab interface though?
            
-
            16:24 < jrandom> do you use the preview tab on the thread view now, for instance?
            
-
            16:26 <+zzz> right now there's no choice but to go to the preview tab to see attachments, which I don't like - would rather just see the whole thing in the lower pane
            
-
            16:26 <+zzz> sorry not conversant in the details of mk's mods so can't answer your other question
            
-
            16:27 < jrandom> ah, so it would work better w/ mk's view (once we get it using the MessageView instead of MessagePreview down there)
            
-
            16:27 < jrandom> oh, there's a screencap of mk's proposal up at http://dev.i2p.net/~jrandom/mk_max.png
            
-
            16:27 < jrandom> mk: perhaps we could find a way to make the tree above vs. left configurable?
            
-
            16:29 <+zzz> thunderbird used to give you a choice of 2 or 3 layouts for the 3 panes, but can't find it in the options atm
            
-
            16:30 < jrandom> i remember reviewing their diagram for that, yeah
            
-
            16:31 < jrandom> perhaps if we can find a way to get mk's "explorer" parentable cleanly in an arbitrary SWT Composite we could use it both via the current tabbed GUI as a tab and in the fullscreen mode as a screen
            
-
            16:33 <+zzz> I like the tabs for the less-common stuff like options, syndication configuration, etc; I think that tabs combined with the multipane for the common stuff is good. imho anyway.
            
-
            16:34 < jrandom> do you run syndie fullscreen or only in part of the screen
            
-
            16:35 <+zzz> usually full
            
-
            16:35 < jrandom> hmm cool
            
-
            16:36 <+zzz> but because I'm using a 1024x768 laptop these days... on my 1600x1200 desktop I wouldn't take up the whole screen
            
-
            16:37 < jrandom> ok, for all y-all watching in the background, please post up your thoughts and ideas whenever its convient for you
            
-
            16:37 < jrandom> heh aye, makes sense
            
-
            16:38  * jrandom is on an 800x600 net cafe box atm
            
-
            16:38 <@detonate> hmm, i'm having trouble getting i2p working again
            
-
            16:39 <@detonate> it's doing something, using lots of cpu, but the web console doesn't seem to ever start
            
-
            16:39 <@detonate> i guess i could try running it in windows
            
-
            16:39 < jrandom> anything in the logs?
            
-
            16:39 <@detonate> not really, it just says that i need to reseed
            
-
            16:39 <@detonate> are the logs quieter than before?
            
-
            16:39 <+zzz> wrapper.log NPE's?
            
-
            16:41 < jrandom> ok, if there isn't anything else for 3, lets jump on to 4) Feb bug harvesting contest results
            
-
            16:42 < jrandom> congrats & thanks to void, Darn, and Anonymous!  
            
-
            16:42 < jrandom> (and to everyone else who has helped out, of course)
            
-
            16:42 < jrandom> bug reports help us track down these issues and make sure they get taken care of, so please keep 'em coming
            
-
            16:43 < jrandom> ok, if there isn't anything on 4), lets jump to 5) ???
            
-
            16:43 < jrandom> anyone have anything they want to bring up for the meeting?
            
-
            16:45 < bar> there was someone asking in the forums why the graphs displaying bw seem a bit off
            
-
            16:45 < bar> thought you might have an idea or two
            
-
            16:46 < bar> (basically, they peak at 1.5 x max bw setting)
            
-
            16:47 < jrandom> aye, wasn't sure *which* bw graphs they were referring to (each of the graphs accurrately render the stat which they represent, from what i've seen)
            
-
            16:47 <@detonate> nm, it's working again :)
            
-
            16:48 <+zzz> it's the first 3 graphs on graphs.jsp, which seem much higher than the bw displayed on the left side of the router console, and for me are much higher than my configured upstream limit
            
-
            16:49  * jrandom loads
            
-
            16:51 < jrandom> hmm, and that includes the upstream avg w/ burst in mind?
            
-
            16:52 <+zzz> yes
            
-
            16:52 < jrandom> hmm, ill look into it
            
-
            16:53 <+zzz> I'll investigate further, guess it doesn't ring a bell for you
            
-
            16:53 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:57 < jrandom> if not...
            
-
            16:57  * jrandom winds up
            
-
            16:58  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting203.html b/www.i2p2/pages/meeting203.html
deleted file mode 100644
index c129b5d5..00000000
--- a/www.i2p2/pages/meeting203.html
+++ /dev/null
@@ -1,111 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 203{% endblock %}
-{% block content %}
            I2P dev meeting, March 20, 2007
            
-
            
-
            16:05 < jrandom> 0) hi
            
-
            16:05 < jrandom> 1) Net status and 0.6.1.28
            
-
            16:05 < jrandom> 2) Syndie dev status
            
-
            16:05 < jrandom> 3) ???
            
-
            16:05 < jrandom> 0) hi
            
-
            16:05  * jrandom waves
            
-
            16:05 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001341.html
            
-
            16:05  * jrandom only recently posted that, so i'll give y'all a minute to read that exiting note ;)
            
-
            16:08 < jrandom> ok, lets jump on into 1) net status and 0.6.1.28
            
-
            16:09 < jrandom> things are looking pretty good so far with about half of the net upgraded
            
-
            16:09 < jrandom> an interesting data point is that the net has grown a bit too, added perhaps another 40-50 active ntcp connections to my router and i see around 700 known router idents
            
-
            16:10 < jrandom> we'll see how that progresses over the next week or so though
            
-
            16:11 < jrandom> ok, anyone have anything to bring up re: net status or 0.6.1.28?
            
-
            16:13 < jrandom> ok, if not, lets swing on over to 2) syndie dev status
            
-
            16:13 < jrandom> lots going on in that front, as mentioned in the notes
            
-
            16:13 < Amiga4000> hi
            
-
            16:13 < jrandom> heya Amiga4000 
            
-
            16:13 < Amiga4000> which point now?
            
-
            16:13 < jrandom> we just hopped over to 2, but if you have something to bring up for 1, hit me ;?
            
-
            16:14 < Amiga4000> yeah, posted in syndie right now, I assume my pool isn't working as aspected
            
-
            16:14 < jrandom> pool?
            
-
            16:14 < Amiga4000> 2 pout tunnels 2 hops, one 70sec and 1300kb, one 250sec and 1000 kb
            
-
            16:15 < Amiga4000> ( I refer to the msg in zzz forum on syndie about I2Psnark and pooling inside router)
            
-
            16:15 < jrandom> i assume those times are expiration times, right, and data is total transferred so far
            
-
            16:15 < Amiga4000> damned, right
            
-
            16:15 < jrandom> ok, i replied to that post in syndie - what you see is good
            
-
            16:15 < Amiga4000> *fine*
            
-
            16:16 < Amiga4000> sry, wqas to fast in read and not understanding
            
-
            16:16 < jrandom> if all tunnels expired at the same time, there'd be a rush and a good chance of total failures
            
-
            16:16 < Amiga4000> correct, any chance to see the lifteime of a tunnel?
            
-
            16:16 < jrandom> 1300KB and 1000KB is pretty good balancing too
            
-
            16:16 < jrandom> lifetime is always 10 minutes
            
-
            16:17 < Amiga4000> ok, I track some more data :_)
            
-
            16:18 < jrandom> w3wt, thanks for asking about it though, its a good question
            
-
            16:18 < Amiga4000> ok, and net status: 0.1.28 is fine, although upload of i2psnakr data is slow
            
-
            16:19 < jrandom> hmm, you were describing 10-15KBps though, right?
            
-
            16:19 < Amiga4000> right, it was 30-40 before the last 2 or 3 changes by zzz
            
-
            16:20 < jrandom> hmm, lets see how it progresses as the new-release churn reduces
            
-
            16:20 < Amiga4000> yes, lets wait 1-2 weeks more :-)
            
-
            16:20 < jrandom> though in my view, 10-15KBps is good enough
            
-
            16:21 < Amiga4000> :-)
            
-
            16:21 < jrandom> (i was actually using the 10-20 range as my target for reasonable usage, rather than 1-5KBps)
            
-
            16:21 < jrandom> of course, more is better, but a solid 10-15 is great news
            
-
            16:21 < Amiga4000> I just know it has done the 2-4x of that
            
-
            16:21 < _bob> Hmm, i2p is using 120% CPU. ;)
            
-
            16:22 < Amiga4000> and I still can grab data from "internet" via the outproxy< in 20-40 kb rate
            
-
            16:22 < jadeSerpent> _bob: hope your heatsink/fan is working
            
-
            16:22 < jrandom> you're referring to kilobytes per second, right Amiga4000?
            
-
            16:22 < Amiga4000> right
            
-
            16:23 < jrandom> cool
            
-
            16:23 < Amiga4000> and even syndie.i2p is in the 40 range
            
-
            16:23 < jrandom> bob: or you've got a dual or quad proc pc ;)
            
-
            16:24 < _bob> Didn't know top reported values over 100%.
            
-
            16:24 < jrandom> i2p is just magic
            
-
            16:24 < jadeSerpent> i guess it's over the top
            
-
            16:25 < _bob> Wish I did. Can only route around 150KB/s in each direction as it is now.
            
-
            16:25  * jadeSerpent dodges rotten fruit
            
-
            16:27 < jadeSerpent> i have a core 2 duo and i sometimes see various processes using >100%
            
-
            16:29 < jrandom> ok, anyone have anything else for 1? 
            
-
            16:30 < jrandom> if not, really moving on to 2 ;)
            
-
            16:30 < jrandom> not much more to add to that here beyond whats in the mail and the forum
            
-
            16:30 < jrandom> anyone have anything they want to bring up re: 2) syndie dev status?
            
-
            16:30 < jadeSerpent> i can't wait to try the new editor widget
            
-
            16:30 < jadeSerpent> the current one is driving me nuts
            
-
            16:30 < jrandom> heh
            
-
            16:31 < jadeSerpent> how were you able to pull in native editors on the various platforms?
            
-
            16:31 < Eric> Just a quick question...why does Susimail take so long to check mail or load? Other .i2p pages load quickly.
            
-
            16:32 < jadeSerpent> Eric: pop3 is a very verbose protocol, moreseo than http (more packets exchanged per operation)
            
-
            16:32 < Eric> Ah, alright.
            
-
            16:33 < jrandom> jadeSerpent: import org.eclipse.swt.widget.Text instead of ...swt.custom.StyledText ;)
            
-
            16:33 < _bob> Eric = Protocol?
            
-
            16:33 < jrandom> Eric: aye, the app runs locally but talks a full pop3 subset to the pop3 server
            
-
            16:34 < jadeSerpent> jrandom: ah so swt does interface to com frameworks
            
-
            16:34 < Eric> Why not use webmail over HTTP as opposed to a local client fetching and sending via POP/SMTP?
            
-
            16:34 < jadeSerpent> nm i'll just read the code
            
-
            16:35 < jrandom> jadeSerpent: well, its a native /text/ widget, not the com html editor widget
            
-
            16:35 < jadeSerpent> Eric: ask postman that question, and preferably in #i2p-chat ;)
            
-
            16:35 < Eric> Okay.
            
-
            16:35 < jadeSerpent> jrandom: oh
            
-
            16:35  * jadeSerpent was thinking gedit/console/riched32
            
-
            16:36 < jadeSerpent> s/console/kate/
            
-
            16:36 < jrandom> jadeSerpent: the com html editor widget is easy enough to integrate too, but itd require a lot of issues
            
-
            16:36 < jadeSerpent> yeah best do your own parsing for security
            
-
            16:36 < jrandom> (eg auditing it for security, especially when quoting content)
            
-
            16:39 < jrandom> ok, if there's nothing else on 2), lets jump to 3) ???
            
-
            16:39 < jrandom> anyone have anything they want to bring up for the meeting?
            
-
            16:40 < jadeSerpent> how's the situation with registerfly
            
-
            16:40 < jadeSerpent> is i2p.net saved? ;)
            
-
            16:41 < jrandom> eh not yet sorted, hope to get it dealt with soon
            
-
            16:41 < jrandom> but y'all have 66.111.51.110 memorized anyway, right?  ;)
            
-
            16:41 < _bob> i2p.net will soon serve you ads and ads. ;)
            
-
            16:42 < jadeSerpent> yes, it's the same number i use for the combination on my briefcase
            
-
            16:42 < jadeSerpent> _bob: that's one of my fears :(
            
-
            16:43 < jadeSerpent> or redirect to SiteFinder
            
-
            16:43 < jadeSerpent> what a mess registerfly created heh
            
-
            16:43 < jrandom> it'll get sorted in the next day or two
            
-
            16:44 < Eric> Heh, now I remember where I've seen that IP. It's the outproxy IP address.
            
-
            16:44 < snoopy> jr: check this page, re i2p.net: http://www.dyndns.com/news/releases/registerfly_safe_harbor.html
            
-
            16:44 < jrandom> aye eric :)
            
-
            16:46 < jrandom> snoopy: most of the registrars out there are offering discounts to scoop up ex-registerfly users (though luckily we're technically an enom registrant)
            
-
            16:46  * jrandom just needs to get onto a secure term (tried to earlier today, but the place was closed)
            
-
            16:47 < jrandom> ok, anyone have anything else to bring up for the meeting?
            
-
            16:49 < jrandom> if not...
            
-
            16:49  * jrandom winds up
            
-
            16:50  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting204.html b/www.i2p2/pages/meeting204.html
deleted file mode 100644
index bffdd6a3..00000000
--- a/www.i2p2/pages/meeting204.html
+++ /dev/null
@@ -1,81 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 204{% endblock %}
-{% block content %}
            I2P dev meeting, March 27, 2007
            
-
            
-
            16:02 < jrandom> 0) hi
            
-
            16:02 < jrandom> 1) Net status
            
-
            16:02 < jrandom> 2) zzz's NTCP/SSU proposals
            
-
            16:03 < jrandom> 3) Syndie dev status
            
-
            16:03 < jrandom> 4) DNS/registrar status
            
-
            16:03 < jrandom> 5) ???
            
-
            16:03 < jrandom> 0) hi
            
-
            16:03  * jrandom waves
            
-
            16:03 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001342.html
            
-
            16:04 < jrandom> jumping into 1) net status
            
-
            16:04 < jrandom> things seem pretty good, and as mentioned there's more research to do regarding the latest changes
            
-
            16:05 <+Complication> I wanted to complain a bit about IRC connectivity (everything else seems decent enough), but this last day, I've only had about 6 disconnects, which ain't so bad
            
-
            16:05 < cervantes>  /mute Complication
            
-
            16:05 < jrandom> heh
            
-
            16:05 <+Complication> :D
            
-
            16:06 <+Complication> Tunnel build success is very nice, though
            
-
            16:06  * Complication checks again, just in case
            
-
            16:06 < jrandom> yeah i've seen some discon churn (though tbh, i read my backlog with a grep -v -\!- so never see the discons ;)
            
-
            16:06 < cervantes> there have been various ISP cockups recently on the irc front - postman is looking into alternative hosting arrangements
            
-
            16:06 < jrandom> tunnel build rates on the stats have made an upturn, though seem generally in line with the cycles up on stats.i2p
            
-
            16:06 < cervantes> hopefully we can get some better network redundancy
            
-
            16:06 < jrandom> ah ok cervantes 
            
-
            16:07  * jrandom would offer to help w/ dev.i2p.net, but i dont remember the last time the load was under 4 on it
            
-
            16:08 < jrandom> ok, anyone have anything else to bring up re: net status?
            
-
            16:10 < jrandom> if not, hopping over to 2) zzz's NTCP/SSU proposals
            
-
            16:10 < jrandom> zzz doesn't seem to be around atm, and i left my syndie posts responding to the thread at home (d'oh)
            
-
            16:11 < jrandom> in any case, post up your thoughts in zzz's blog (or read there for more info)
            
-
            16:11 < jrandom> anyone have anything to discuss regarding that here now though?
            
-
            16:12 <+Complication> Well, I personally wrote a reply there, expressing concern about too great reliance on UDP (since for me personally, UDP had rather high retransmission rates)
            
-
            16:12 < jrandom> aye
            
-
            16:12 <+Complication> I thougt, however, about one approach...
            
-
            16:12 <+Complication> Currently the bids are fully deterministic (as opposed to probabilistic with a random component) right?
            
-
            16:13 < jrandom> aye, fully deterministic
            
-
            16:13 <+Complication> I was wondering if there would be any benefit (in the sense of avoiding extremes) in making them have a probability component
            
-
            16:14 <+Complication> As in "60% chance of getting NTCP, 40% chance of getting SSU"
            
-
            16:14 <+Complication> (assuming no prior data - if prior failure / success data would be present, that would probably need to skew the probability in favour of the better-performing transport for that link)
            
-
            16:15 < jrandom> well, it depends on what one is hoping to achieve - from my understanding of zzz's proposal, the aim is to use ssu whenever possible
            
-
            16:15 <+Complication> (assuming of course that both transports are usable for a given link - sometimes they certainly aren't)
            
-
            16:15 < jrandom> randomizing it would't help with that, though would offer more room to get data on both transports in the wild
            
-
            16:16 <+Complication> Just a thought on one possible way of trying to strike a balance between them ('cause if one always bids higher, routers likely won't "experiment" much)
            
-
            16:19 < jrandom> 'tis a method we could use to gather more data, worth keeping in mind
            
-
            16:19 < jrandom> ok, as mentioned, post on up to that thread for more stuff :)
            
-
            16:20 < jrandom> jumping on over to 3) Syndie dev status
            
-
            16:20 < jrandom> i dont have much to add beyond whats in the mail
            
-
            16:20 < jrandom> anyone have any questions/comments/concerns?
            
-
            16:21 <+Complication> Not yet. :)
            
-
            16:22 < jrandom> hehe
            
-
            16:22  * Complication entertains a hope of helping out more, either on the I2P or Syndie front, but I really need to get that webcache thingy out of the door first
            
-
            16:22 < jrandom> w3rd, looking forward to both :)
            
-
            16:24 < jrandom> ok lets skip past 4 and jump to 5) ???
            
-
            16:25 < jrandom> anyone have anything else they want to bring up for the meeting?
            
-
            16:26 < TrevorReznik> is there any interest in a hashcash generator for i2p?
            
-
            16:26 < TrevorReznik> as in through the browserinterface.
            
-
            16:26 < TrevorReznik> i thought about that as kind of way to eliminate possible DoS scenarios inside i2p.
            
-
            16:27 < jrandom> hmm, in javascript or c/java?
            
-
            16:27 < jrandom> i think there are a few hashcash generators out there
            
-
            16:27 < TrevorReznik> in java.
            
-
            16:28 <+Complication> well, some research into hashcash schemes is likely to be needed at some point
            
-
            16:28 < TrevorReznik> www.hashcash.org has some i think.
            
-
            16:28 < TrevorReznik> they are an initiative to establish it for email clients as antispam thing.
            
-
            16:28 <+Complication> perhaps not research in a proper sense, but in an implementation and best practise sese
            
-
            16:28 <+Complication> =sense
            
-
            16:28 < TrevorReznik> they have a collection of implementations in a multitude of languages.
            
-
            16:28 < TrevorReznik> there are 2 java classes and at least one applet there, though i dont know the exact license parameters as of now.
            
-
            16:30 <+Complication> places which could use it: 1) nym registration in Syndie 2) name registration in I2P
            
-
            16:30 <+Complication> 3) email, obviously
            
-
            16:30  * TrevorReznik agrees.
            
-
            16:30 <+Complication> 4) in less optimistic scenarios, ordinary messages in Syndie
            
-
            16:31 <+Complication> on the I2P network level itself...
            
-
            16:31 <+Complication> hmm
            
-
            16:31 < jrandom> its possible to embed them into tunnel creation mesages, but we're already hosed on that cpu front as it is ;)
            
-
            16:39 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:41 < jrandom> if not
            
-
            16:41  * jrandom winds up
            
-
            16:41  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting205.html b/www.i2p2/pages/meeting205.html
deleted file mode 100644
index ac9a7ab0..00000000
--- a/www.i2p2/pages/meeting205.html
+++ /dev/null
@@ -1,88 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 205{% endblock %}
-{% block content %}
            I2P dev meeting, April 3, 2007
            
-
            
-
            16:01 < jrandom> 0) hi
            
-
            16:01 < jrandom> 1) net status
            
-
            16:01 < jrandom> 2) syndie dev status
            
-
            16:01 < jrandom> 3) ???
            
-
            16:01 < jrandom> 0) hi
            
-
            16:01  * jrandom waves
            
-
            16:01 < jrandom> weekly status notes are not up yet, but there wasn't much in 'em so we can cover it inline here
            
-
            16:01 < jrandom> jumping into 1) net status
            
-
            16:01 < jrandom> things seem to be doing pretty well, no major problems atm.  there were some troubles on the irc servers earlier, but the hardware issues have been resolved (thanks cervantes and postman!)
            
-
            16:01 < jrandom> there's been some more discussion on zzz's blog regarding the ssu/ntcp ideas - check that out for more info
            
-
            16:01 < jrandom> i don't have much to add on that... anyone have anything to bring up on 1) net status?
            
-
            16:04 < jrandom> if not, lets move on to 2) syndie dev status
            
-
            16:04 < jrandom> some good progress on the desktop gui lately, with a few components propagated back into the tabbed gui as well
            
-
            16:04 < jrandom> we've still got some work to do, but i use the desktop gui for most everything atm. 
            
-
            16:04 < jrandom> mk has brought up some more ideas and concerns regarding the desktop gui as well, and as always, read the Syndie dev forum to follow the planning and implementation
            
-
            16:04 <+Complication> indeed, I can also confirm higher IRC sessions persistence
            
-
            16:04 < jrandom> w3wt
            
-
            16:06 <+Complication> Seems like testing it again might be scheduled then (during my last test, I found it a bit... intimidating)
            
-
            16:07 < jrandom> ah yeah, i added labels to most of the buttons now ;)
            
-
            16:07 < jrandom> though if you're on windows it still does the vertical button labels wrong (need to write a custom layout for that)
            
-
            16:07 <+Complication> (especially the lack of labels on the many components)
            
-
            16:08 < jrandom> but its still not ready for alpha... i can use it because i know what everything does/is suposed to do
            
-
            16:08 <+Complication> over here it's Linux, but good to know, I guess
            
-
            16:08 < jrandom> but hopefully in the next week or so
            
-
            16:09 <+Complication> on the Syndie side, I've been wondering about one issue: could the new syncing code is being overzealous, like attempting too many transfers concurrently?
            
-
            16:09 <+Complication> s/is being/be
            
-
            16:09 < jrandom> it'll try 5 concurrent fetches per archive
            
-
            16:10 < jrandom> (and one async import thread)
            
-
            16:10 <+Complication> Over here, its failure rate against most archives has seen a dramatic rise from earlier times
            
-
            16:10 < jrandom> hmm
            
-
            16:10 <+Complication> It could be that more people are syncing too,  but I'd still hope it possible to hit a spare moment when the archive ain't busy
            
-
            16:10 <+Complication> "hitting a spare moment" and getting a quality sync done, seems to generally not happen, though
            
-
            16:10 < jrandom> so various fetches fail saying "connection reset" or other tcp-like error message?
            
-
            16:11 <+Complication> "socket closed" and whatnot
            
-
            16:11 < jrandom> ah ok
            
-
            16:11 <+Complication> I haven't really counted them
            
-
            16:11 <+Complication> This is of course entirely via I2P
            
-
            16:11 < jrandom> the servers arent currently that hefty (i think they have very limited handling capacity), and that should get imporved
            
-
            16:12 < jrandom> also, as you and $nymFormerlyKnownAsAnonymous said, we should retry those kinds of failures
            
-
            16:12 <+Complication> right, that might help too
            
-
            16:12 < tapeworm> What are the servers based on?
            
-
            16:12 < jrandom> but we definitely need that to be rock solid and transparent, of course
            
-
            16:13 < jrandom> tapeworm: homebrew
            
-
            16:13 <+Complication> though when I mesured "eepget" performance a while back, comparatively to Syndie, eepget got great performance and reliability
            
-
            16:13 < jrandom> (about a dozen lines of code)
            
-
            16:13 <+Complication> it pulled 2 x 9 MB from dev.i2p.net while archive.syndie.i2p kept failing on tiny little messages
            
-
            16:13 < jrandom> oh, thats not really a fair test though
            
-
            16:14 <+Complication> different boxes?
            
-
            16:14 < jrandom> and syndie actually /uses/ eepget to fetch
            
-
            16:14 < jrandom> fetching from apache is pretty different from fetching lots of small files from a homebrew webserver ;)
            
-
            16:14 <+Complication> hmm... I should probably log overzealously while syncing then
            
-
            16:15 <+Complication> indeed, and the difference between servers too
            
-
            16:17 <+Complication> heh, it seems I managed to initiate a sync in the desktop UI
            
-
            16:17 <+Complication> a task which proved too hard last time :)
            
-
            16:17 < jrandom> w3wt :)
            
-
            16:18 < jrandom> ok, anyone have anything else for 2?  if not, lets jump on over to 3) ???
            
-
            16:18 <+Complication> I do have the habits of a heavy taskbar user, though, so it will likely take some getting used to
            
-
            16:18 <+Complication> (I usually have the taskbar on auto-hide)
            
-
            16:19 < jrandom> well, there's a compile time option to put the desktop gui in a shell rather than fullscreen - we can make that a command line switch instead 
            
-
            16:19 <+Complication> is the desktop gui, in principle, capable of having a "minimize" button?
            
-
            16:19 < jrandom> its trouble to make it a runtime change though, as swt doesn't allow gui component reparenting (reliably), and you cant change a shell's trim
            
-
            16:20 < jrandom> oh, yes, definitely possible - good idea
            
-
            16:20 <+Complication> which would send it to background without affecting the order in which other windows below it are arranged?
            
-
            16:20 < jrandom> we can toss that into the control menu (top left) or the task menu (top right)
            
-
            16:20 <+Complication> Because using alt+tab tends to change that
            
-
            16:21 <+Complication> (something... like the "show desktop" button I typically like to have on the taskbar near the KDE / Start button)
            
-
            16:21 <+Complication> (another location may prove better, but something of this effect)
            
-
            16:22 < jrandom> yeah, we can hide it the same wayt the tabbed gui's minimize works (or we can iconize it like the normal windowing minimize button)
            
-
            16:22 <+Complication> Even if admittedly, minimize and show desktop are different things - now that I consider more, minimize seems a bit more logical.
            
-
            16:24 <+Complication> As for syncing errors, I currently have 1 instance of HTTP 504, and 4 instances of "socket closed"
            
-
            16:24 <+Complication> 2 successes
            
-
            16:24  * TrevorReznik encounters like 70% socket closed
            
-
            16:24 < jrandom> zounds
            
-
            16:24 < jrandom> ok, ill look into that and get an update in there asap
            
-
            16:27 < jrandom> ok, in 3) ??? - anyone have anything else for the meeting?
            
-
            16:27 <+Complication> I wish I had, but not yet - webcache app still incomplete, since real life ran me over a little
            
-
            16:28 < jrandom> damn that reality!
            
-
            16:28  * Complication will try to get the 15 annoying things sorted out of the way
            
-
            16:32 < jrandom> wr0d
            
-
            16:32 < jrandom> ok, if there isn't anything else for the meeting...
            
-
            16:32  * jrandom winds up
            
-
            16:33  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting206.html b/www.i2p2/pages/meeting206.html
deleted file mode 100644
index e6e33c2e..00000000
--- a/www.i2p2/pages/meeting206.html
+++ /dev/null
@@ -1,45 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 206{% endblock %}
-{% block content %}
            I2P dev meeting, April 10, 2007
            
-
            
-
            16:01 < jrandom> 0) hi
            
-
            16:01 < jrandom> 1) Net status
            
-
            16:01 < jrandom> 2) Syndie dev status
            
-
            16:01 < jrandom> 3) ???
            
-
            16:01 < jrandom> 0) hi
            
-
            16:01  * jrandom waves
            
-
            16:01 < jrandom> the brief weekly status notes are posted up at http://dev.i2p.net/pipermail/i2p/2007-April/001343.html
            
-
            16:01  * mrflibble waves back
            
-
            16:03 < jrandom> as those notes are short enough, lets jump on in to 1) Net status
            
-
            16:03 < jrandom> things seem to be going along fairly well lately
            
-
            16:03 < jrandom> atm there aren't any major changes underway for the net (that i know of), so that will likely remain the case
            
-
            16:03 < jadeSerpent> irc seems to have calmed down finally too
            
-
            16:03 < jrandom> cool
            
-
            16:05 < jrandom> i don't have much to add re: 1) net status, so unless anyone has anything for it, lets jump on over to 2) Syndie dev status
            
-
            16:07 < jrandom> the next rev is taking longer than expected, but i'm hoping to get a new release out in the next 2-3 days
            
-
            16:07 < jrandom> it won't be the desktop gui, but will include a number of improvements
            
-
            16:08 < Complication> anything which helps syndication reliability would be wonderful
            
-
            16:08 < Complication> it's been comparatively poor lately
            
-
            16:08 < jrandom> aye, that trouble should be easy enough to sort out (to an extent)
            
-
            16:09 < jadeSerpent> you know what's causing the failed fetches via i2p?
            
-
            16:09 < jrandom> aye, low timeouts
            
-
            16:10 < jrandom> (and low handler threads on the servers)
            
-
            16:13 < jrandom> ok, if there isn't anything else on 2) Syndie dev status, lets jump over to 3) ???
            
-
            16:13 < jrandom> anyone have anything else to bring up for the meeting?
            
-
            16:14  * mrflibble waves
            
-
            16:14 < mrflibble> sorry, going back  to  point 1 again
            
-
            16:15 < mrflibble> <jadeSerpent> irc seems to have calmed down finally too - is this for any particular reason do you think?
            
-
            16:16 < jrandom> there were some network and hardware trouble on the irc servers, and most people have upgraded to the latest release now (giving us the benefit of zzz's improvements)
            
-
            16:17 < jrandom> the #s for tunnel creation success rates look much better
            
-
            16:17 < mrflibble> oh ok, was the servers themselves
            
-
            16:17 < mrflibble> what were zzz's imporvements?
            
-
            16:19 < Complication> message priorities, to allow tunnel build messages to take priority over tunnel traffic
            
-
            16:19 < Complication> and streaming lib adjustments, and the usual array of I2PSnark fixes
            
-
            16:19 < mrflibble> ah,  thanks
            
-
            16:19 < jrandom> (what Complication said :)
            
-
            16:22 < jrandom> ok, anyone have anything else for the meeting?
            
-
            16:26 < jrandom> if not
            
-
            16:26  * jrandom winds up
            
-
            16:26  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting21.html b/www.i2p2/pages/meeting21.html
deleted file mode 100644
index 30b00ad2..00000000
--- a/www.i2p2/pages/meeting21.html
+++ /dev/null
@@ -1,691 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 21{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 21
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Nov 26 22:43:56 2002
-
            22:44 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback
-
            22:44 [Users #iip-dev]
-
            22:44 [ CwZ|away] [ Disposable] [ icepick] [ logger] [ pox] [ UserX] 
-
            22:44 -!- Irssi: #iip-dev: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal]
-
            22:44 -!- Irssi: Join to #iip-dev was synced in 2 secs
-
            22:44 < logger> test
-
            23:35 < nop> IIP dev meeting in 25 minutes, Special appearance by Capn' crunch aka John Draper
-
            23:36 < Disposable> cool
-
            23:36 < Disposable> the famous capncrunch
-
            23:36 < Disposable> :P
-
            23:36 < nop> yes
-
            23:37 < nop> friend of mine
-
            23:37 < nop> ;)
-
            23:37 < Disposable> yeah?
-
            23:37 < nop> he's working on porting iip to mac os 9
-
            23:37 < Disposable>  cool
-
            23:37 < ptsc> unfortunately i'm off to do laundry but will lurk
-
            23:37 < nop> ok
-
            23:37 < ptsc> nop, why not an os x.2 clean version?
-
            23:37  * Disposable is listening to The Beets - Killer Tofu
-
            23:37 < nop> what?
-
            23:37 < nop> ptsc, we have os x versions
-
            23:37 < Disposable> hmmm
-
            23:37 < nop> we need os 9
-
            23:38 < nop> because there are still a lot of people on it
-
            23:38 < ptsc> ah, okay.  i was considering getting a mac that could run os x
-
            23:38 < nop> yes
-
            23:38 < nop> but only 20% of mac users have switched to X
-
            23:38 < ptsc> in my case, i'd be switching to mac specifically *because* of x
-
            23:39 < Disposable> lol
-
            23:39 < Disposable> yeah
-
            23:39 < Disposable> it looks so sweet
-
            23:39 < Disposable> :)
-
            23:39 < Disposable> i wunna try it
-
            23:39 < Rain> "unix for users done right" some feel
-
            23:39 < ptsc> i saw it at a friend's house who has been a mac freak for ages
-
            23:39 < ptsc> and it just looks awesome
-
            23:39 < ptsc> plus they brought back the NeXT-style file browser
-
            23:39 < ptsc> which has always ruled
-
            23:40 < ptsc> ok bbl
-
            23:40 < Rain> "the first lickable interface", according to mr jobs.
-
            23:41 < Disposable> :/
-
            23:48 < Disposable> wb
-
            --- Day changed Wed Nov 27 2002
-
            00:00 < nemesis> blubb
-
            00:00 < nemesis> 23 UTC
-
            00:00 < nop> ok
-
            00:00 < nop> welcome to the 21st iip meeting
-
            00:01 < nop> on the agenda
-
            00:01 < nop> 1) welcome
-
            00:01 < nop> 2) why rc3 isn't released yet
-
            00:01 < nop> 3) when will it be released
-
            00:01 < nop> 4) OS 9 port by Cap'n Crunch
-
            00:01 < nop> 5) Questions and comments
-
            00:02 < nop> ok
-
            00:02 < nop> welcome
-
            00:02 < nop> :)
-
            00:02 < nop> codeshark is out of the country on business, and will be back later this week
-
            00:02 < nop> he's our release coordinator
-
            00:02 < nop> and if he's not back shortly, mids and I will arrange the release candidate
-
            00:02 < nop> and do it that way by friday
-
            00:02 < Aprogas> one should only accept the function of release coordinator, if one knows to have time for that function
-
            00:02 < nop> when will it be released, friday at latest
-
            00:03 < nop> comments are saved for last 
-
            00:03 < nop> thnx though aprogas
-
            00:03 < Aprogas> ok
-
            00:03 < nop> ok, os 9 port, Cap'n Crunch has been working (along with his friend) on porting IIP to mac os 9 users
-
            00:04 < nop> hopefully, he will be on here shortly to give us some detail
-
            00:04 < nop> if not I'll send out an email
-
            00:04 < nop> to iip-dev with the latest from him
-
            00:04 < nop> oh speak of the devil
-
            00:04 < crunchman> Ok,   I'm on 
-
            00:04 < nop> Hi crunch
-
            00:04 < Aprogas> nop: that must be bpb in disguise
-
            00:04 < nop> can you give us a quick detail of what's going on with os 9
-
            00:04 < crunchman> Of course I didn't get the chance to read over the source so I can bring up my issues.
-
            00:05 < nop> k
-
            00:05 < crunchman> yes - I can.
-
            00:05 < nop> the floor is yours, take it away
-
            00:05 < crunchman> basically - the way IIP was written,  it's a CAAN OF WORMS if I have to use the structures you are already using.
-
            00:06 < crunchman> There is NO discrete seperation between the GUI and the guts.
-
            00:06 < crunchman> Let me explain.
-
            00:06 < crunchman> It is VERY baised towards WinBlows.
-
            00:06 < crunchman> As you know,  the Mac uses resources for the GUI components.
-
            00:07 < crunchman> I need to examine the code now,   and would like to take a few mins to go over my notes,  so I can be more specific.
-
            00:07 < nop> ok
-
            00:07 < nop> either way, we can cover that later, but Crunch is working on the os 9, and we will aid him with what we can so that it may be not so tedious a task
-
            00:08 < nop> reasons for the port, is only 20% of mac users have made the switch to os x
-
            00:08 < nop> they still rely on os 9
-
            00:08 < nop> so a lot of mac os users donated money towards this goal
-
            00:08 < nop> and any other donations are welcome to assist crunch for his time on this project
-
            00:09 < nop> questions and comments from iip users etc
-
            00:09 < nop> ?
-
            00:09  * Disposable is listening to Creedence Clearwater Revival - Fortunate Son
-
            00:09 < Aprogas> comment: one should only accept the function of release coordinator, if one knows to have time for that function
-
            00:09 < Rain> question: what will be new in rc3
-
            00:09 < Rain> ?
-
            00:09 < nop> mainly bug fixes, hold, I'll get the changelog
-
            00:09 < Aprogas> /exec -o cat ChangeLog | head -200
-
            00:10 < bpb> question: since when does IIP get donations?
-
            00:10 < crunchman> bob cant get on
-
            00:10 < nop> + iip1.1-rc3:
-
            00:10 < nop> + - Display of version number for windows (menu option) and unix (command line).
-
            00:10 < nop> + - Random number generation fix.
-
            00:10 < nop> + - IIP network connections are no longer paused while in the setup screen.
-
            00:10 < nop> + - Now exits if it can't bind to a socket at startup.
-
            00:10 < nop> +   Windows now displays a message box informing that it can't bind to port.
-
            00:10 < nop> + - Several bugfixes and one memory leak fixed.
-
            00:10 < crunchman> i
-
            00:10 < nop> + 
-
            00:10 < crunchman> im on phone - helping him
-
            00:10 < crunchman> hold on
-
            00:10 < nop> k
-
            00:10 < nop> that is the changelog
-
            00:11 < Aprogas> comment: women are always late
-
            00:11 < crunchman> hold on - still on phone w/ bob
-
            00:11 < Rain> ok, thanks.
-
            00:11 < nop> haha
-
            00:11 < nop> ok meeting is officially over
-
            00:11 < bpb> if he can't get iip to work, he could connect to my node
-
            00:11 < Aprogas> huh ?
-
            00:12 < nop> I will resume talks with crunch in here
-
            00:12 < athena> okay, so i can slap aprogas now?
-
            00:12 < Aprogas> but maybe i still had questions or commens
-
            00:12 < bpb> :)
-
            00:12 < nop> aprogas
-
            00:12 < nop> do you have any more questions
-
            00:12 < Aprogas> am i being ignored?
-
            00:12 < nop> or comments
-
            00:12 < nop> that pertains to IIP
-
            00:12 < Rain> is the "sneak release" the same as the final one, and will i dare running it on a public proxy at this stage?
-
            00:12 < crunchman> meeting is over?  - but we havent even gotten on yet!
-
            00:12 < Aprogas> where is mids?
-
            00:12 < bpb> crunchman: that's nop for you...
-
            00:12 < nop> crunch we can still talk in here
-
            00:12 < Aprogas> no mids no meeting
-
            00:12 < crunchman> Bob is trying to get on - and yet the meeting is now over?
-
            00:12 < nop> rain sneak is the same yes
-
            00:12 < nemesis> hm... nop, i use blackbox under windows xp, why theres no cmd line version of IIP out?
-
            00:13 < nemesis> that i can use as an service..
-
            00:13 < crunchman> bpb - I have no clue what you mean by "crunchman: that's nop for you"
-
            00:13 < Aprogas> bpb means nothing with it
-
            00:13 < Aprogas> he loves to confuse people
-
            00:13 < nop> well, nemesis iip -d might be able to do that for you
-
            00:13 < crunchman> still trying to get bob logged in.
-
            00:13 < bpb> crunchman: he's cutting off the meeting after it hasn't begun
-
            00:14 < nop> the "official" meeting is over
-
            00:14 < Disposable> hehe
-
            00:14 < nop> other than comments
-
            00:14 < crunchman> sorry I couldn't get on sooner.
-
            00:14 < Rain> ok, so i might as well de-install the rc2 proxy i recently installed today, and replace it with rc3, no risk?
-
            00:14 < Aprogas> nop: will there be an rc4 or even rc5, and when are they expected, and when is iip 1.1 expected?
-
            00:14 < nop> rc3 should be final before 1.1
-
            00:15 < nop> unless
-
            00:15 < Aprogas> of course the release candidate comes before the release
-
            00:15 < crunchman> Could someone call bob on phone and help him
-
            00:15 < nop> unless major bugs were found
-
            00:15 < nemesis> hm....
-
            00:15 < Aprogas> nop: why do i get the idea you forget what a rc is all the time ?
-
            00:15 < nemesis> nop, must i shutdown my current iip for -d?
-
            00:16 < Aprogas> nop: so when are 1.1 and 1.1-rc3 expected?
-
            00:16  * bpb remembers when decentralized 2.0 was expected ;)
-
            00:16 < nemesis> crunchman: help with what?
-
            00:17 < crunchman> bob cant get on this IRC server.
-
            00:17 < crunchman> I tried to help him - I gave up.
-
            00:17  * Aprogas remembers saying that iip 1.1 would be released the day after freenet 0.5
-
            00:17 < crunchman> I asked Lance to help him get on.
-
            00:17 < Aprogas> crunchman: what kind of error does he get ?
-
            00:17 < crunchman> When he's on...  he can give you guys an update in HIS progress.
-
            00:18  * Disposable is listening to Creedence Clearwater Revival - Susie Q
-
            00:18 < crunchman> I don't know - I didnt get chance to ask him - sorry.
-
            00:18 < nemesis> waaaaaaaaaaaaaaaaaaaaaaah *crying*
-
            00:18 < nemesis> mids
-
            00:18 < nemesis> i have 5 iip process running...
-
            00:18 < crunchman> I REALLY would like to go off and re-examine the IIP work I did - so I can answer intellegent questions on the issues I want to bring up.
-
            00:18 < nemesis> fuck it *grrr*
-
            00:18 < crunchman> but I want BOB up here first.
-
            00:19 < crunchman> because he also has to explain HIS part in the project
-
            00:19 < Aprogas> it would be useful if we would know what kind of problem he has with connecting to here
-
            00:19 < crunchman> I think he will address the group on his "socket" problems.
-
            00:19 < Aprogas> is he using his own isproxy or yours?
-
            00:19 < crunchman> Nop is talking to him on the phone right now - i hope.;
-
            00:20 < crunchman> Bob has a Mac...   I think he's using ircle
-
            00:20 < crunchman> this is what I'm using right now.
-
            00:20 < nop> I am
-
            00:20 < nop> athena
-
            00:20  * Kyfhon remembers trying that vile thing in an emulator
-
            00:20 < Disposable> question: primary mac developeman will before os 9 ? 
-
            00:20 < nop> he's using athena
-
            00:20 < crunchman> ok,  i'll be right back.
-
            00:20 < nemesis> re....
-
            00:20 < nemesis> are no pid implented in iip yet?
-
            00:21 < nemesis> or cmd line output...
-
            00:21 < nop> crunch, his inet connection is acting up
-
            00:21 < nemesis> i always started a new instance with iip -d  or -h or -? and ?
-
            00:23 < Aprogas> maybe he could come tomorrow, or at next week's meeting then
-
            00:24 < bpb> well, captn crunch made a atleast celebrity appearance today.
-
            00:24 < bpb> err
-
            00:24 < Aprogas> never heard of him, im from the pentium generation
-
            00:25 < bpb> minus the atleast
-
            00:25 < bpb> Aprogas: you never heard of captain crunch?
-
            00:25 < Aprogas> no
-
            00:25 < bpb> he is THE LEGEND
-
            00:25 < Aprogas> nop: IIP should become a tiny bit more formal
-
            00:25 < xenode> im from the pentium generation and i still've heard of him
-
            00:25 < nop> formal?
-
            00:25 < Aprogas> of course its an opensores project, so it will always be informal
-
            00:25 < bpb> Aprogas: you mean without your rudeness?
-
            00:26 < Aprogas> but right now it seems like a chaotic bunch of people doing some things in a basement and something coming out of nowhere once in a while
-
            00:26 < bpb> Captain Crunch is the man who started telephone fraud :)
-
            00:26 < Aprogas> it seems completely unorganised to me
-
            00:26 < Aprogas> bpb: as i said, im from the pentium generator
-
            00:26 < xenode> Aprogas: thats no excuse
-
            00:26 < bpb> well, maybe not started it, but he did it using a captain crunch whistle
-
            00:26 < nemesis> hm....
-
            00:27 < Aprogas> its not meant as an excuse, its a reason
-
            00:27 < rda> i am here
-
            00:27 < xenode> its not a reason either
-
            00:27 < Kyfhon> Aprogas: What do you expect? Snappy logos and a pr gremlin?
-
            00:27 < nemesis> irc are at the most time idle
-
            00:27 < Aprogas> kyfhon: no, but that is all i see now
-
            00:27 < bpb> ...and used it to call the pope long distance for free
-
            00:27 < nemesis> whats about VoIP (IIP) ;)
-
            00:27 < Aprogas> i'd like releases, and code, and bugfixes and stuff
-
            00:27 < nemesis> 8kbit datastream
-
            00:27 < bpb> the legendary phone call
-
            00:27 < Aprogas> and less t-shirts, mugs, and interviews
-
            00:27  * Kyfhon didn't know there were tshirts. Hmm
-
            00:27 < crunchman> Ok,  back on again.
-
            00:28 < crunchman> ok
-
            00:28 < bpb> Aprogas: I can't believe you hadn't heard of Captn Crunch
-
            00:28 < nemesis> lol
-
            00:28 < hezekiah> crunchman: Good! :)
-
            00:28 < bpb> geez Aprogas, you're a disgrace
-
            00:29 < Aprogas> bpb: i know
-
            00:29 < bpb> next thing I know you'll be saying you don't know who Steve Wozniac is
-
            00:29 < Aprogas> nop: i also feel like my suggestions are being ignored
-
            00:29 < Aprogas> dont know him either
-
            00:29 < nop> well, you expect quite a bit
-
            00:29 < Aprogas> im a hermit, i dont know many people
-
            00:29 < Aprogas> maybe
-
            00:29 < xenode> he must be fooling with us.. i mean.. jeez
-
            00:29 < Aprogas> or maybe IIP isnt what i thought it was
-
            00:29 < bpb> Aprogas: what about Steve Jobs?
-
            00:29 < bpb> Aprogas: Bill Gates?
-
            00:30 < Aprogas> bpb: sounds familiar, isnt he the Apple CEO
-
            00:30 < bpb> Aprogas: 0x90
-
            00:30 < bpb> yep
-
            00:30 < Aprogas> and the second one the Microsoft Fuehrer
-
            00:30 < Aprogas> i know 0x90
-
            00:30 < Aprogas> but he isnt legendary
-
            00:30 < bpb> true
-
            00:30 < Aprogas> nop: what is IIP actually?
-
            00:30 < bpb> but I wanted to make sure you knew who he was :)
-
            00:31 < Aprogas> i know his address, get a copy of his phone bill, listen to his phonecalls sometimes, and have camera's behind his mirrors
-
            00:31 < Aprogas> so i know him
-
            00:31 < bpb> but captain crunch is one of the few true legends we have in the world of geekdom
-
            00:31 < xenode> heh
-
            00:31 < Aprogas> im not a geek, im a hermit
-
            00:31 < bpb> Aprogas: that's too bad
-
            00:31 < Aprogas> but i need IRC for some dynamics
-
            00:31 < Aprogas> my shack is only statis
-
            00:32 < Aprogas> and statis does not bring much inspiration
-
            00:32 < bpb> nop: you know the world of geekdom well, correct? :)
-
            00:32 < nop> yes
-
            00:32 < nop> aprogas IIP is what it is
-
            00:32 < Aprogas> nop: which is ?
-
            00:32 < Aprogas> im not sure if i know what IIP is actually
-
            00:32 < Aprogas> or what it is meant to be
-
            00:32 < Aprogas> can you tell me ?
-
            00:33 < nop> it would take too long
-
            00:33 < nop> read the site
-
            00:33 < Aprogas> bla
-
            00:33 < nop> rda join #dev
-
            00:33 < bpb> haha
-
            00:33 < Aprogas> i read it
-
            00:33 < Aprogas> #dev, #iip-dev, #iip, #anonymous
-
            00:33 < Aprogas> *g*
-
            00:33 < Aprogas> you want to DoS my client by letting me join more channels than it can handle?
-
            00:33 < bpb> they're all conspiring against us in #dev
-
            00:34 < nop> well aprogas it doesn't matter to you
-
            00:34 < nop> you're not a developer
-
            00:34 < Aprogas> ok
-
            00:34 < Aprogas> indeed i am not
-
            00:34 < nop> so your expectations must remain as a critic
-
            00:34 < nop> critics don't get what they want
-
            00:34 < nop> developers do
-
            00:34 < Aprogas> im not a critic
-
            00:34 < bpb> hahaha
-
            00:34 < Aprogas> im a disappointed enthusiast
-
            00:35 < nop> yes
-
            00:35 < bpb> nop: you never answered my question from the meeting btw...
-
            00:35 < nop> and I appreciate your dissapointment
-
            00:35 < nop> which one bpb
-
            00:35 < bpb> nop: since when does IIP get donations?
-
            00:35 < Aprogas> someone who thought it would be possible to resist opression without needing dark basements and information exchanges in the park
-
            00:35 < nop> well they have bpb
-
            00:36 < bpb> nop: since when, how much, etc.? :)
-
            00:36 < bpb> nop: the critics must know ;)
-
            00:36 < Aprogas> nop: i think you still did not tell me when iip 1.1 will be done
-
            00:37 < nop> I can't give that answer until rc3 is released
-
            00:37 < Aprogas> can you give a rough estimate ?
-
            00:37 < Aprogas> or at least tell me when you expect rc3
-
            00:38 < nop> rc3 by friday
-
            00:38 < nop> at worse case
-
            00:38 < Aprogas> so by friday you can give a rough estimate about when iip 1.1 will be done ?
-
            00:38 < nop> yes
-
            00:38 < Aprogas> ok, ill stay until friday then
-
            00:39 < nop> fine with me
-
            00:39 < nop> what do you expect from IIP aprogas
-
            00:39 < nop> and why
-
            00:39 < Aprogas> i dont know what to expect from IIP
-
            00:39 < Aprogas> but i can try to analyse what i expect from it
-
            00:40 < Aprogas> i think i expect IIP to be a certain `medium' which i can use to say anything i would like without having feelings of fear along with saying those things
-
            00:40 < Aprogas> but i think i also expect IIP to have a somewhat professional, or at least organised, character
-
            00:41 < Aprogas> probably because i would have more trust in the application if that would be the case
-
            00:41 < nop> I can't demand professionals unless I can pay them
-
            00:41 < Aprogas> you can act like a professional
-
            00:41 < nop> since people like you choose not to donate substantial amounts of money, and only your criticism it will be hard
-
            00:41 < Aprogas> i dont enjoy criticism
-
            00:42 < Aprogas> and i would love the develop if i didnt think the development team was an unorganised bunch of people
-
            00:42 < nop> it's not unorganized
-
            00:42 < nop> it's quite organized
-
            00:42 < Aprogas> it seems to be
-
            00:42 < nop> it's just not the way you want it
-
            00:42  * Debolaz whispers to the developers next to him: "Don't take it personally.. someday, you'll be a real live boy"
-
            00:42 < Aprogas> maybe
-
            00:43 < nop> aprogas, if you want to be the leader
-
            00:43 < nop> than that is up to you
-
            00:43 < Aprogas> i dont want to be the leader at all
-
            00:43 < nemesis> hrhr
-
            00:43 < Aprogas> i want to be unknown, because being unknown is safer
-
            00:43 < nop> correct
-
            00:43 < Kyfhon> Dear gods. Aprogas get your head out of your ass. These people are doing this on their own time and letting everyone use it, and you're demanding behavior modification
-
            00:44 < Aprogas> i am just giving these people some advice
-
            00:44 < nemesis> achja, fehlt nur noch ardvark ;)
-
            00:44 < Aprogas> if you make a tool, but if you seem like an unorganised bunch, that will probably repell serious users
-
            00:44 < nop> well, we have serious software that works
-
            00:44 < Aprogas> sure, you'll attract some geeks who can say `look mommy, im now anonymous'
-
            00:44 < nop> and a serious website
-
            00:44 < nop> and we have decent organization
-
            00:44 < Kyfhon> Well your advice was given quite awhile ago. You keep giving the advice repeatedly and thus it looks like demands from my end
-
            00:44 < Aprogas> then why do you hide that ?
-
            00:44 < nop> I think that we have gone farther than a lot of open source projects
-
            00:44 < Aprogas> if you have serious softwar that works, why dont you release it ?
-
            00:45 < nop> you're using it right now
-
            00:45 < Aprogas> it doesnt seem to work well
-
            00:45 < nop> and if you want rc3
-
            00:45 < nop> it's in cvs
-
            00:45 < nop> ready for you
-
            00:45 < nop> and when rc3 is ready for the General audience
-
            00:45 < nop> it will be released
-
            00:45 < Aprogas> my isproxy often complains it cannot reach certain things, and sometimes just vanishes without a trace
-
            00:45 < nemesis> hm.... irgendwie hat er ja recht...
-
            00:45 < nop> probably because someone hated your noc
-
            00:45 < bpb> nop: well, what's the goal of IIP anyway?  And how close is it to reaching that goal?
-
            00:45 < Aprogas> no
-
            00:45 < nemesis> lol
-
            00:45 < Aprogas> it did that before that
-
            00:46 < Aprogas> bpb: the goal of IIP is to be what it is
-
            00:46 < nop> bpb, the goal is obvious
-
            00:46 < nop> if you haven't read the site
-
            00:46 < nop> then I can't help you
-
            00:46 < nop> I'm not going to be long winded
-
            00:46 < nemesis> hm...
-
            00:46 < nop> I am programmed to have a array of 200 characters max per line
-
            00:46 < nop> and I prefer it to be shorter
-
            00:46 < nop> obviously
-
            00:46 < bpb> nop: I've read the sites ever since casper the friendly ghost...
-
            00:46 < nemesis> 200?
-
            00:47 < nop> then you're asking a rhetorical question
-
            00:47 < Aprogas> nop: is the central IIP server reliable ?
-
            00:47 < nop> it hasn't gone down for a very long time
-
            00:47 < nop> it's hosted in a secured facility
-
            00:47 < nemesis> 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
-
            00:47 < bpb> nop: no, I don't believe I am...  maybe I should rephrase...
-
            00:47 < nemesis> thats 200 ^^
-
            00:47 < Aprogas> even before our NOC was destroyed, i got disconnected from IIP at least once a day i think
-
            00:47 < Aprogas> so i wouldnt really call that `software that works'
-
            00:47 < nop> well, you're talking on it now
-
            00:47 < nop> so
-
            00:48 < Aprogas> sure
-
            00:48 < Aprogas> but i want it to be reliable
-
            00:48 < Aprogas> you never know when you are going to need it
-
            00:48 < bpb> nop: why did you start IIP exactly?
-
            00:48 < Aprogas> bpb: to mock his wife
-
            00:48 < nop> because it was cool
-
            00:48 < nop> and i wanted to be cool
-
            00:48 < nop> don't you know
-
            00:48 < nop> I'm in california
-
            00:48 < nop> it's all about cool
-
            00:48 < nemesis> ;)
-
            00:49 < nemesis> and whate are you think about your project at this time? ;)
-
            00:49 < bpb> ...
-
            00:49 < bpb> heh
-
            00:49 < nop> next I'll get breast implants
-
            00:49 < nop> I think it's cool
-
            00:49 < nop> ;)
-
            00:49 < nemesis> hehe ;)
-
            00:49 < bpb> nop: hey, if you're a city employee in SF, free sex change ;)
-
            00:49 < nop> look aprogas, you've made your comments
-
            00:49 < Aprogas> maybe
-
            00:50 < nop> and they are heard
-
            00:50 < nop> and we do our best
-
            00:50 < bpb> nop: butt sex is also cool in california ;)
-
            00:50 < Aprogas> they havent been really said
-
            00:50 < nemesis> why you wan't to limit the max characters to max 200 each per line?
-
            00:50 < Aprogas> its hard to express what exactly i mean
-
            00:50 < Aprogas> its just that everytime i try to do something with anonimity and stuff, it fails
-
            00:50 < Aprogas> its a big disappointment
-
            00:51 < nemesis> thats true..
-
            00:51 < Aprogas> every few months i cvs checkout freenet again, see if it works already
-
            00:51 < Aprogas> then it seems to work, and at the moment i am to share my excitement with others, it breaks into a horrible pit of frustration and agony
-
            00:51 < Aprogas> im afraid IIP is going to be affected by the same curse
-
            00:52 < nop> well aprogas, more comments say IIP works better than freenet
-
            00:52 < nop> but it's a work in progress
-
            00:52 < bpb> If you want to be cool, you just need to let everybody know you're friends with captn crunch... oh wait, you've done that too ;)
-
            00:52 < Aprogas> thats why i still use IIP right now and ditched freenet
-
            00:52 < Kyfhon> Heh ever since freenet 0.5 it takes like 5 minutes to retr something.
-
            00:52 < Aprogas> kyfhon: thats not that bad
-
            00:52 < Aprogas> i can wait 5 minutes
-
            00:52 < Kyfhon> ...With a50% failure rate
-
            00:53 < nemesis> hrhr
-
            00:53 < Aprogas> mm.. maybe i should try freenet again
-
            00:53 < bpb> yeah
-
            00:53 < bpb> 0.4 during a certain era was great
-
            00:53 < Aprogas> is that with the 5xx or 6xx build?
-
            00:53 < Aprogas> most of the time 0.4 was broken
-
            00:53 < Aprogas> and trying to insert something in freenet 0.3 traumatised me
-
            00:53 < bpb> Aprogas: 0.5 is 5xx and 6xx
-
            00:54 < Kyfhon> 0.5.0.6 tarball
-
            00:54 < Aprogas> bpb: thats why im asking where kyfhon gets those decent results
-
            00:54 < Aprogas> but i shouldnt be naive
-
            00:54 < Aprogas> i know its going to faiil
-
            00:54 < Aprogas> because i use kaffe
-
            00:54 < Aprogas> so ill try again later
-
            00:54 < bpb> haha
-
            00:55 < bpb> kaffe works fine with freenet
-
            00:55 < bpb> evil GPL ware
-
            00:55 < Aprogas> nop: i think the problem with the IIP developers team is that they are a bunch of geeks who are coding a program for a bunch of other geeks
-
            00:55 < bpb> anyway...  shouldn't we be talking in #anonymous
-
            00:55 < Aprogas> but it would be nice if IIP would also target different users
-
            00:56 < bpb> Aprogas: umm, what do you think the first computers were, and look at them now ;)
-
            00:56 < Aprogas> users who dont just want to explore the technology of being anonymous, but users who actually need being anonymous
-
            00:56 < Aprogas> the first computers were used in the textile industry i think
-
            00:59 < Rain> they were not really computers, though. more like automats. they could not actually process information, only act on a given program. progammed looms.
-
            01:00 < Aprogas> are there any users on here who arent here just for the kick of being `anonymous' ?
-
            01:00  * Debolaz isn't being anonymous here.
-
            01:00 < Aprogas> debolaz: why are you here ?
-
            01:00 < nemesis> me?
-
            01:01 < Rain> i like the people, and i want to see how it turns out.
-
            01:01 < Aprogas> bla
-
            01:02 < Aprogas> you would whine too if you were in my position
-
            01:02 < Aprogas> you fucking rats
-
            01:02 < Kyfhon> Wah =[
-
            01:02 < nemesis> hrhr
-
            01:02 < mateofree> what was that?!?
-
            01:02 < nemesis> "<Aprogas> you would whine too if you were in my position"
-
            01:02 < nemesis> what he mean with this?
-
            01:03 < Kyfhon> He prolly needs anonymity. Or something.
-
            01:03 < mateofree> I might have an idea for logo
-
            01:03 < mateofree> mind if I throw it out here?
-
            01:04 < Rain> go ahead man..
-
            01:04 < mateofree> ok
-
            01:05 < mateofree> well I thought maybe a head either in profile or from front..
-
            01:05 < mateofree> with one side dissolving into ones and zeros
-
            01:06 < Rain> might look nice, but what is the "iip specific" thing of it?
-
            01:06 < mateofree> hehe don´t know
-
            01:06 < mateofree> hello fw
-
            01:06 < mateofree> the eye is closed btw
-
            01:07 < Fairwitness> the eye?
-
            01:07 < mateofree> so there is some allusion to "invisible" "not seen"
-
            01:07 < mateofree> hehe
-
            01:07 < Rain> hmm, that might work.
-
            01:07 < Kyfhon> Submarine dissolving into (1|0)'s
-
            01:07 < Fairwitness> your talking about a logo?
-
            01:07 < Rain> pehaps a question mark somewhere..
-
            01:07 < mateofree> don´t go anywhere, I will upload it
-
            01:07 < mateofree> I have a scetch
-
            01:08 < mateofree> have to log first
-
            01:08 < mateofree> brb
-
            01:08 < Gilles2Rais> hey about dcc on iip irc, perhaps freenet could be used
-
            01:09 < Kyfhon> It would take years to send a file :>
-
            01:09 < Gilles2Rais> hum not really !!
-
            01:09 < Kyfhon> Well, not _that_ long
-
            01:09 < Gilles2Rais> a irc command could be used for trading the key
-
            01:09 < Kyfhon> Might as well just give out refs
-
            01:10 < Gilles2Rais> simulating a dcc
-
            01:10 < Rain> does anyone know if there is any project 
-
            01:10 < Rain> to make a native freenet node implementation?
-
            01:10 < Kyfhon> That would be nice
-
            01:11 < Rain> the last one died, but now that 0.5 is actually released
-
            01:11 < Kyfhon> Isn't there a java compiler that outputs native bins?
-
            01:11 < Rain> yeah, but i belive i read that there was some misc trouble with it
-
            01:11 < Rain> ie, the process is not perfect
-
            01:11 < Kyfhon> Hm
-
            01:15  * Kyfhon has to scram
-
            01:17 < mateofree> check here: http://briefcase.yahoo.com/mateo_freeman
-
            01:18 < mateofree> in IIP sketch folder
-
            01:20 < Fairwitness> What's this image proposed for Mateo?
-
            01:20 < mateofree> IIP logo
-
            01:20 < mateofree> just an idea I got
-
            01:20 < mateofree> just now
-
            01:21 < Fairwitness> can you explain the image?
-
            01:21 < mateofree> well, it is a head either in profile or from front, with closed eye
-
            01:21 < mateofree> and one side dissolves into ones and zeros
-
            01:22 < Fairwitness> ahhh.. I could see that it was disolving but not what into
-
            01:22 < mateofree> oh, well I did it fast so...
-
            01:22 < mateofree> just to get the idea out, hehe
-
            01:23 < mateofree> don´t know if it is proper though
-
            01:23 < mateofree> might be too ambigous
-
            01:24 < mateofree> might work though as a t shirt logo though
-
            01:24 < mateofree> a little one on chest or somethign
-
            01:24 < Fairwitness> might be a bit detailed for a tshiort
-
            01:24 < Fairwitness> I think it is a great idea and woudl love to see you develop it. 
-
            01:24 < mateofree> well, I was thinking of simplyfying it
-
            01:25 < mateofree> with more clean lines
-
            01:25 < Fairwitness> Kool. 
-
            01:25 < mateofree> I kind of like the profle one
-
            01:25 < mateofree> profile
-
            01:25 < Fairwitness> that's much better for screen printing...
-
            01:26 < mateofree> yes
-
            01:26 < mateofree> maybe something with lines, as in that picture is better than ones and zeros
-
            01:26 < mateofree> might be too small to see
-
            01:26 < mateofree> ones and zeros that is
-
            01:27 < Fairwitness> I lik ethe fading to 1's and 0's idea...
-
            01:28 < mateofree> yes.. but would maybe be to small for something like t shirt?
-
            01:28 < mateofree> the "point" is though the shut eye
-
            01:28 < mateofree> that is what ties to invisible
-
            01:30 < Rain> i actually like the sound of that. simple enought. together with the "iip" text, it will be pretty obvious, even to a non techie. they might not now what a "proxy" is, but "invisible" and "net" should be prettey obvious.
-
            01:31 < Rain> heh, a "closed eye" is kinda the opposite of the "lidless eye" from LOTR...
-
            01:31 < mateofree> hehe
-
            01:32 < mateofree> hmm, maybe an open eye over a pyramid might be better..... ;)
-
            01:33 < Rain> hmm, that seems kinda familiar....
-
            01:33 < Gilles2Rais> hu my job is graphism and 3d so if u need ...
-
            01:33 < mateofree> cool
-
            01:33 < Rain> (note to self: learn to spell)
-
            01:33 < Gilles2Rais> u could find my gallery at :
-
            01:33 < Gilles2Rais> (just wait :)
-
            01:33 < mateofree> what programs du you use?
-
            01:33 < mateofree> for 3d
-
            01:34 < Rain> can you accentuate the closed eye, make the face look "calm"?
-
            01:34 < Gilles2Rais> http://www.renderosity.com/gallery.ez?ByArtist=Y&Artist=delly
-
            01:34 < Gilles2Rais> im using rhino for modelling
-
            01:34 < Rain> in the the current scetch he looks to be somewhat in pain ;)
-
            01:34 < mateofree> wow cool
-
            01:34 < Gilles2Rais> render with pov bmrt or lightwave
-
            01:34 < mateofree> I owbn rhino too
-
            01:34 < Gilles2Rais> or flamingo 
-
            01:34 < Gilles2Rais> rhino is soooooo cool
-
            01:34 < Gilles2Rais> the best for me
-
            01:35 < mateofree> yeah
-
            01:35 < Gilles2Rais> and im using only one
-
            01:35 < Gilles2Rais> rhino
-
            01:35 < mateofree> I used to do 3d some years ago
-
            01:35 < Gilles2Rais> have u and url where I could see the actual logo
-
            01:35 < mateofree> also used truespace
-
            01:35 < Gilles2Rais> yes ive tried it
-
            01:35 < Gilles2Rais> ive luv the cinema 4d rendering too
-
            01:36 < Gilles2Rais> actually for fast done animation I prefer moray 303
-
            01:36 < Gilles2Rais> and lightwave for not fast done :)
-
            01:36 < mateofree> oh btw did you see my post on dc?
-
            01:36 < mateofree> about 3d plugin to 3dmax
-
            01:37 < mateofree> http://www.eyematic.com/products_facestation.html
-
            01:37 < mateofree> now that is cool
-
            01:37 < Gilles2Rais> have u  try brazil ?
-
            01:37 < mateofree> nope, what is that?
-
            01:37 < Gilles2Rais> woo I luv it too but all tried beta was so bugged
-
            01:37 < Gilles2Rais> the better render engine
-
            01:38 < Gilles2Rais> (for me :)
-
            01:38 < mateofree> cool
-
            01:38 < mateofree> hehe
-
            01:38 < Gilles2Rais> splutterfish.com
-
            01:38 < Gilles2Rais> I guess
-
            01:38 < Gilles2Rais> Video In. Facial Animation Out. It's That Simple.
-
            01:38 < Gilles2Rais> its ur artcile
-
            01:38 < mateofree> snow desert was very cool
-
            01:38 < Gilles2Rais> article
-
            01:38 < mateofree> what program did you use for it?
-
            01:38 < mateofree> cool
-
            01:39 < Gilles2Rais> dont know this
-
            01:39 < Gilles2Rais> http://www.neilblevins.com/artgallery/gallery_brazil.htm
-
            01:40 < Gilles2Rais> see and cry :)
-
            01:40 < Gilles2Rais> http://splutterfish.com/sf/Images/img_c02_glassc.jpg
-
            01:40 < mateofree> your gallery was very cool
-
            01:40 < Gilles2Rais> thx
-
            01:40 < Gilles2Rais> but it seems lots pictures are 404 :(
-
            01:41 < Gilles2Rais> I luv this http://splutterfish.com/sf/Images/img_c06_delphipaw_marbles_on_rails_DOF3-3.jpg
-
            01:41 < mateofree> wow!
-
            01:41 < mateofree> that was very cool
-
            01:42 < mateofree> brb
-
            01:43 < mateofree> back
-
            01:44 < mateofree> what I really like about rhino and truespace is price
-
            01:44 < mateofree> very good price/value
-
            01:44 < Gilles2Rais> yep true
-
            01:44 < Gilles2Rais> so much features
-
            01:45 < mateofree> yeah
-
            01:45 < Gilles2Rais> have u try flamingo too ?
-
            01:45 < mateofree> truespace is amazing
-
            01:45 < mateofree> nope
-
            01:45 < Gilles2Rais> its great and too easy to use materials
-
            01:45 < mateofree> only have rhino 1. something and truespace 4. something 
-
            01:45 < Gilles2Rais> but slow
-
            01:45 < mateofree> haven´t used them in years
-
            01:45 < Gilles2Rais> truespace have nice render and seems fast
-
            01:46 < Fairwitness> Sorry to split in the middle of a conv Mateo but I had to get the phone..
-
            01:46 < Gilles2Rais> rhino 3 beta is available
-
            01:46 < mateofree> I like that truespace is a complete package
-
            01:46 < Fairwitness> I agree with the previous commment that the face looks quite unhappy.
-
            01:46 < mateofree> hehe np fw
-
            01:46 < mateofree> ofcourse it is unhappy, having to hide away from the statists, hehe
-
            01:46 < Gilles2Rais> have u and url I could see the actuall iip logo
-
            01:46 < Fairwitness> Do either of you have PalmS?
-
            01:47 < Fairwitness> PDA's that is?
-
            01:47 < mateofree> nope
-
            01:47 < mateofree> gilles du you mean:  http://www.invisiblenet.net/iip/
-
            01:47 < mateofree> or my example?
-
            01:48 < Fairwitness> bummer :) 
-
            01:48 < Fairwitness> I have a palm addiction... I found an excellent drawing program for Plam OS
-
            01:48 < Fairwitness> I LOVE your gallery Gilles2Rais!!
-
            01:48 < mateofree> cool
-
            01:48 < mateofree> the palms are really cool
-
            01:49 < Fairwitness> I use it a lot as it is great t be able to have coloured drawing tools wherever I go 
-
            01:49 < Fairwitness> and it can print the images at ANY size with no loss of quality as it is vector based
-
            01:49 < mateofree> yeah I bet
-
            01:50 < mateofree> I have a wacom drawing tablet, very cool
-
            01:50 < Gilles2Rais> I need it
-
            01:50 < Gilles2Rais> but my mouse is terrible :)
-
            01:50 < mateofree> I guess palm is kind of like it
-
            01:50 < mateofree> hehe
-
            01:50 < Fairwitness> I nearly bought one of them...
-
            01:50 < mateofree> yeah drawing witgh mouse is ipossible for me
-
            01:50 < Fairwitness> but I bought a film scanner instead
-
            01:51 < Fairwitness> I don't do a lot of drawing.. mostly photos.
-
            01:51 < Fairwitness> and retouching is ok with a mouse... but a tblet woud be better
-
            01:51 < mateofree> yeah
-
            01:51 < mateofree> it is pretty amazing really
-
            01:52 < mateofree> you think it might be weird but it is very intuitive
-
            01:52 < Fairwitness> I will console myself with the fact that I LOVE my film scanner :0
-
            01:52 < Fairwitness> though now i have got a digital camera...
-
            01:53 < mateofree> hehe what model is it?
-
            01:53 < mateofree> oh yeah an ixus right?
-
            01:53 < mateofree> those are cool
-
            01:53 < Fairwitness> I know this probably sounds silly but I didn;t get a tablet because i just have no more desk space
-
            01:53 < Fairwitness> yeah
-
            01:53 < Fairwitness> it is ok for stuff to go on the web
-
            01:53 < mateofree> lol
-
            01:53 < Fairwitness> but big prints are a bit suboptimal
-
            01:54 < mateofree> yeah
-
            01:54 < Fairwitness> nothing like film for resolution..
-
            01:54 < Fairwitness> but I am OVER the chemicals.
-
            01:54 < mateofree> well.....
-
            01:54 < Fairwitness> I will soon be putting up the kipbetbot page whic has some nice shots on it...
-
            01:54 < mateofree> price is a bit to high right now but there are very good alternatives
-
            01:55 < mateofree> for digital cams
-
            01:55 < Fairwitness> true, but I am waiting... I think there will be a big jump in quality soon.
-
            01:55 < mateofree> for about 2000 dollars you can get a digital cam as good as 35mm film
-
            01:55 < mateofree> yeah
-
            01:55 < Fairwitness> and I want one of the decents lens makers to come up with an really goood digital camera...
-
            01:56 < Fairwitness> ...but lenses...?
-
            01:56 < mateofree> oh the proffesional ones are compatible with standard lenses
-
            01:56 < Fairwitness> resolution on the screen is nice... but oyu need the lenses ot get good images to utilise the high res
-
            01:56 < Fairwitness> still too expensive though..
-
            01:57 < mateofree> yeah
-
            01:57 < mateofree> but if trends are going as lately it will be cheap soon
-
            01:57 < Fairwitness> anyway I am supposed ot be working... gotta go...
-
            01:57 < mateofree> ok bye
-
            01:58 < Fairwitness> I hope so.. I'm counting on prices falling ...
-
            01:58 < Fairwitness> see you later
-
            01:58 < mateofree> http://www.luminous-landscape.com/reviews/cameras/d60/d60.shtml
-
            01:58 < mateofree> save that for later
-
            01:58 < mateofree> good review of canon d60
-
            02:30 < Gilles2Rais> cya all
-
            07:14 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback
-
            07:14 [Users #iip-dev]
-
            07:14 [ CwZ|away] [ epoch        ] [ jeremiah] [ nemesis] [ ptm ] [ UserX] 
-
            07:14 [ Debolaz2] [ icepick-work_] [ logger  ] [ pox    ] [ ptsc] 
-
            07:14 -!- Irssi: #iip-dev: Total of 11 nicks [0 ops, 0 halfops, 0 voices, 11 normal]
-
            07:14 -!- Irssi: Join to #iip-dev was synced in 2 secs
-
            08:45  * nemesis is away: sleeps
-
            --- Log closed Wed Nov 27 10:49:36 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting22.html b/www.i2p2/pages/meeting22.html
deleted file mode 100644
index bd0fd3a1..00000000
--- a/www.i2p2/pages/meeting22.html
+++ /dev/null
@@ -1,153 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 22{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 22
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Dec 03 23:52:14 2002
-
            23:52 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback
-
            23:52 [Users #iip-dev]
-
            23:52 [ codeshark2] [ Disposable] [ logger] [ nemesis] [ nop] [ root_] 
-
            23:52 [ Debolaz   ] [ icepick   ] [ mids  ] [ Neo    ] [ pox] [ UserX] 
-
            23:52 -!- Irssi: #iip-dev: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal]
-
            23:52 -!- Irssi: Join to #iip-dev was synced in 3 secs
-
            --- Day changed Wed Dec 04 2002
-
            00:01 < mids> Tue Dec  3 23:01:00 UTC 2002
-
            00:01 < mids> Welcome everybody
-
            00:02 < mids> today we are going to talk about nice websites
-
            00:02 < mids> atleast, until nop comes back in 8 minutes
-
            00:02 < mids> now here comes my nice website:
-
            00:02 < hezekiah> lol
-
            00:02 < mids> http://www.longbets.org/
-
            00:02 < mids> "The purpose of the Long Bet Foundation is to improve long-term thinking"
-
            00:03 < mids> consult the website for more information
-
            00:03 < mids> .
-
            00:03 < hezekiah> mids ... you need to take a course at an MC camp about "filling dead air."
-
            00:03 < hezekiah> How's RC3? Do you know?
-
            00:03 < mids> 1) you take a bottle of air
-
            00:03 < mids> 2) you fill it with water
-
            00:03 < mids> 3) the dead air is filled.
-
            00:03 < mids> .
-
            00:03 < hezekiah> Any feedback on the "pre" RC3?
-
            00:04 < mids> someone asked how the upgrade could be done
-
            00:04 < mids> otherwise no comments that I can remember
-
            00:05 < mids> codeshark made some commits for the windows version of rc3 to CVS
-
            00:05 < mids> like said last weeks: rc3 is near
-
            00:05 < mids> only we lack developertime to release it :)
-
            00:06 < hezekiah> The configure script should now support Linux, FreeBSD, and Mac OS X. If you want to try it, check out the "development" branch of CVS and give it a whirl!
-
            00:06 < mids> I tried it
-
            00:06 < mids> but I got all kind of errors
-
            00:06 < hezekiah> When did you try it?
-
            00:06 < mids> 3 days ago
-
            00:06 < hezekiah> Hmmm ... what operating system?
-
            00:06 < mids> linux
-
            00:07 < hezekiah> Odd. Send me the errors.
-
            00:07 < hezekiah> I'll look into it.
-
            00:08 < mids> ./configure works fine... but takes quite long actually
-
            00:08 < mids> compared with other opensource projects
-
            00:08 < hezekiah> Hmm ... it should take only a minute or so.
-
            00:08 < mids> yeah
-
            00:08 < mids> but longer as other projects with the same size
-
            00:09 < hezekiah> Do they have to do crypto?
-
            00:09 < hezekiah> That can make a big difference. (A fair section of the time is spent finding OpenSSL, and finding integer types and making macros for them.)
-
            00:09 < mids> hm nope
-
            00:09 < mids> it compiles now
-
            00:09 < hezekiah> Good! :)
-
            00:09 < mids> but it refuses to bind to port 6667
-
            00:10 < mids> is the configuration file format changed?
-
            00:10 < hezekiah> It should.
-
            00:10 < mids> oh wait
-
            00:10 < hezekiah> You already have isproxy running on port 6667 since your talking to me. (Unless you customized the isproxy you ran before.)
-
            00:10 < mids> it is this NASTY timeout
-
            00:10 < mids> that should really be fixed...
-
            00:11 < mids> it works
-
            00:11 < hezekiah> The timeout that occures when a copy of isproxy bombs out with the port still bound?
-
            00:11 < mids> hip hip
-
            00:11 < hezekiah> hurra!
-
            00:11 < mids> yeah that timeout
-
            00:11 < hezekiah> Ugh. You're right.
-
            00:11 < mids> .
-
            00:11 < mids> Other question that I got through some user:
-
            00:12 < hezekiah> Well, that's the current state in developerland from my view folks! More at 11:00!
-
            00:12 < hezekiah> What?
-
            00:12 < mids> why does the entropy generation feed directly from the keypresses?
-
            00:12 < mids> and not from /dev/random like GnuPG etc do?
-
            00:12 < hezekiah> I don't know. UserX?
-
            00:12 < mids> /dev/random uses mouse, network and other randomness too
-
            00:13 < hezekiah> (Well, /dev/random doesn't use network if you say not to in the kernel; ... which I do.)
-
            00:13 < mids> depens on the os I think
-
            00:14 < mids> .
-
            00:14 < UserX> reason for that is not all /dev/randoms produce secure random data
-
            00:15 < hezekiah> Ah ...
-
            00:15 < mids> UserX: then how does GnuPG handle it? I am sure they do it right :)
-
            00:15 < hezekiah> Maybe we should make it check to see if the system does ... and use it if so.
-
            00:16 < UserX> mids: i'm not sure. i'll look into that
-
            00:16 < hezekiah> If it's in their configure script, then I might be able to find it.
-
            00:16 < mids> great
-
            00:16 < mids> I _really_ need to sleep now
-
            00:17 < hezekiah> Bye, mids! :
-
            00:17 < hezekiah> :)
-
            00:17 < mids> night
-
            00:17 < hezekiah> 'night.
-
            00:17 < mids> (logfiles on http://mids.student.utwente.nl/~mids/iip/)
-
            00:18 < hezekiah> (Meanwhile, our reports are still investigating the mysterious dissapearence of "nop"! We'll give you the breaking news "as it happens (r)!")
-
            00:18 < hezekiah> [If no one has noticed yet, I'll be the first to admit: I don't do well at filling dead air.]
-
            00:19 < hezekiah> I would like to officially thank the person who submitted a logo to the iip-dev mailing list.
-
            00:19 < hezekiah> It's the best one I've seen yet. (Note: It's also the only one I've seen yet ...)
-
            00:20 < hezekiah> Well, while we wait for nop ...
-
            00:20 < hezekiah> ... Does anyone have question!?
-
            00:21 < hezekiah> Anyone?
-
            00:21 < hezekiah> Anyone at all?
-
            00:21 < pox> bpb was writing a license.  did it materialize?
-
            00:22 < hezekiah> I wasn't aware of any license in the works. Currently, I beleive is IIP licensed under the GPL.
-
            00:23 < hezekiah> Yup. IIP is licensed under the GPL
-
            00:23 < nop> hi
-
            00:23 < nop> ok
-
            00:23 < nop> sorry
-
            00:23 < hezekiah> The man is HERE!
-
            00:24 < nop> alright
-
            00:24 < nop> rc3 should be coming out today
-
            00:24 < nop> it's getting tested as we speak
-
            00:24 < hezekiah> Yay!
-
            00:25 < nop> other than that
-
            00:25 < nop> I don't think there's much to say this week
-
            00:25 < nop> rather slow week
-
            00:25 < nop> busy for most people
-
            00:25 < nop> side note
-
            00:25 < nop> life is good
-
            00:25 < nop> :)
-
            00:25 < nop> any questions
-
            00:25 < nop> comments
-
            00:26 < nop> .
-
            00:26 < hezekiah> When can we expect IIP 1.1 final to be out?
-
            00:27 < nop> hezekiah you tell me ;)
-
            00:27 < nop> j/k
-
            00:27 < nop> probably a few weeks after rc3 is released today
-
            00:27 < hezekiah> I'm working on 1.2 development!
-
            00:27 < nop> haha
-
            00:27 < hezekiah> OK. :)
-
            00:27 < nop> I know
-
            00:27 < nop> I'm kidding
-
            00:27 < hezekiah> You would!
-
            00:27 < hezekiah> lo
-
            00:27 < nop> pending bugs etc
-
            00:27 < hezekiah> lol
-
            00:30 < hezekiah> Does any else have a question?
-
            00:30 < nemesis> hm...
-
            00:31 < nemesis> plan codeshark a tut for fileserv?
-
            00:40 < hezekiah> Well ... I'm off. Have fun everyone. ;-)
-
            03:09 < nemesis> http://forum.pcwelt.de/fastCGI/pcwforum/topic_show.fpl?tid=82168&pg=5 loooooooooooooooooooooooooooooooooooooooooooooooooooooool
-
            03:10 < nemesis> ups, sorry, an url ;)
-
            03:10 < nemesis> *gg*
-
            04:07 < nemesis> cu@all
-
            04:11  * Disposable is listening to System of a Down - Spiders
-
            13:17 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | sneak rc3 preview for unix http://mids.student.utwente.nl/~mids/iip/iip-1.1-rc3-mids1.tgz | please give feedback
-
            13:17 [Users #iip-dev]
-
            13:17 [ Debolaz   ] [ icepick] [ pox   ] [ UserX] 
-
            13:17 [ Disposable] [ logger ] [ root__] 
-
            13:17 -!- Irssi: #iip-dev: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
-
            13:17 -!- Irssi: Join to #iip-dev was synced in 8 secs
-
            --- Log closed Wed Dec 04 19:49:58 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting23.html b/www.i2p2/pages/meeting23.html
deleted file mode 100644
index 65efbb3d..00000000
--- a/www.i2p2/pages/meeting23.html
+++ /dev/null
@@ -1,340 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 23{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 23
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Dec 10 23:32:22 2002
-
            23:32 -!- Topic for #iip-dev: http://www.patrick.fm/boobies/boobies.php?text=IIP <-- mmm, boobies, aka our new mascot!
-
            23:32 [Users #iip-dev]
-
            23:32 [@codeshark] [ icepick] [ Neo] [ pox   ] [ UserX ] 
-
            23:32 [ Debolaz  ] [ logger ] [ nop] [ sferic] [ xcasex] 
-
            23:32 -!- Irssi: #iip-dev: Total of 10 nicks [1 ops, 0 halfops, 0 voices, 9 normal]
-
            23:32 -!- Irssi: Join to #iip-dev was synced in 2 secs
-
            23:34 -!- mode/#iip-dev [+o mids] by Trent
-
            23:34 -!- mode/#iip-dev [+v logger] by mids
-
            23:53 < |EN3RGY|> wee
-
            23:55 < mrflibble> lol, like the pic, is it ne1 we know?
-
            23:55  * jeremiah_  wonders if this is working... using the metropipe JS interface...
-
            23:55 < hobbs> jeremiah_ : you're sending, at least. :)
-
            23:56 < jeremiah_> hobbs: looks like it works, meeting about to start? I'm at the public library
-
            23:56 < hobbs> jeremiah_ : just a few minutes, yeah.
-
            23:56 < Zwolly> i want to order an IIP mascot where can i buy them???
-
            23:57 < nop> hehe
-
            23:57 < jeremiah_> hey nop
-
            23:57 < nop> hi
-
            23:57 < nop> I like the metropipe thing
-
            23:57 < nop> rather neat
-
            23:57 < jeremiah_> yeah it's cool
-
            23:57 < hobbs> yeah, and amazing that it works. >:)
-
            23:58 < nop> works real well
-
            --- Day changed Wed Dec 11 2002
-
            00:00 <@mids> Tue Dec 10 23:00:04 UTC 2002
-
            00:00 <@mids> Welcome to the 23th IIP meeting
-
            00:00 < dangermouse> 22:48 by my clock :p
-
            00:00 < xcasex> thankyou
-
            00:00 <@mids> Agenda:
-
            00:00 <@mids> 1) Welcome
-
            00:00 <@mids> 2) RC3 finally
-
            00:00 <@mids> 3) Security Advisory
-
            00:00 <@mids> 4) Network inconsistancies
-
            00:00 <@mids> 5) Questions?
-
            00:00 <@mids> .
-
            00:00 <@mids> Logs are available on
-
            00:00 <@mids> http://mids.student.utwente.nl/~mids/iip/
-
            00:01 <@mids> If you got questions related to the current agenda item, please ask
-
            00:01 <@mids> otherwise safe them for the question round
-
            00:01 <@mids> .
-
            00:01 < nop> I'm gonna wait for a sec
-
            00:01 <@mids> yeah, till they come back
-
            00:02 < nop> k
-
            00:02 <@mids> did you all see nop's IIP mascot submission?
-
            00:02 <@mids> http://www.patrick.fm/boobies/boobies.php?text=IIP
-
            00:02 < hobbs> nop : btw, whatever happened to those beeps in the MOTD? I actually liked them.
-
            00:02 < jeremiah_> is it profane? I can't really look at profane stuff
-
            00:02 < {Due}> hi all
-
            00:02 < nop> oh, I think I fixed the problems
-
            00:02 < hobbs> jeremiah_ : not suitable for a library.
-
            00:02 -!- mids changed the topic of #iip-dev to: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            00:03 < nop> oh, got rid of our mascot
-
            00:03 < nop> :(
-
            00:03 < {Due}> here ppl only write in english?
-
            00:03 -!- mids changed the topic of #iip-dev to: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ - IIP Mascot: http://www.patrick.fm/boobies/boobies.php?text=IIP
-
            00:03 <@mids> {Due}: yeah
-
            00:04 < |EN3RGY|> la mayoria si, {Due}
-
            00:04 < {Due}> i really dont understand what is the meaning of this
-
            00:04 < {Due}> :\
-
            00:04 <@mids> ok, me hands the microphone to nop
-
            00:04 < nop> alright
-
            00:04 < nop> Welcome
-
            00:04 < nop> to the nth
-
            00:04 < nop> hezekiah: you should know
-
            00:04 < hezekiah> 23rd
-
            00:04 < nop> meeting
-
            00:04 < nop> of IIP
-
            00:04 < nop> clockwork
-
            00:05 < nop> mids, agenda please
-
            00:05 <@mids> 1) Welcome
-
            00:05 <@mids> 2) RC3 finally
-
            00:05 <@mids> 3) Security Advisory
-
            00:05 <@mids> 4) Network inconsistancies
-
            00:05 <@mids> 5) Questions?
-
            00:05 < |EN3RGY|> {Due} entiendes algo ?
-
            00:05 < nop> ok
-
            00:05 < {Due}> si |EN3RGY|
-
            00:05 < nop> please try and save comments for the questions part
-
            00:05 -!- mode/#iip-dev [+oo nop hezekiah] by mids
-
            00:05 < {Due}> ahora hay "chala", wait
-
            00:05 < |EN3RGY|> XD
-
            00:05 <@nop> so we can get throught his
-
            00:05 < |EN3RGY|> ok
-
            00:05 < {Due}> ;)
-
            00:05 <@nop> 2) RC3 finally!!!
-
            00:05 <@nop> yeah
-
            00:05 <@hezekiah> Yeah!
-
            00:05 < |EN3RGY|> q paranoia !
-
            00:06 <@nop> RC3 is here and arrived in 50% less time than RC2
-
            00:06 < {Due}> |EN3RGY| /say yeah!
-
            00:06 < {Due}> ke todo hay ke decirtelo :\
-
            00:06 <@mids> ok, be quiet people, I can barely hear nop
-
            00:06 <@nop> hmm
-
            00:06 < |EN3RGY|> yeah!
-
            00:06 < |EN3RGY|> XDDD
-
            00:06 <@nop> cayete
-
            00:06 <@nop> or how ever you say it
-
            00:06 <@nop> silencio
-
            00:06 < |EN3RGY|> solo me entero
-
            00:06 < |EN3RGY|> de algo sobre el RC3
-
            00:06 < jeremiah_> nosotros hablamos espanol tambien
-
            00:06 < {Due}> |EN3RGY| silencio ;)
-
            00:06 <@nop> they are translating ;)
-
            00:06 <@nop> haha
-
            00:06 < |EN3RGY|> ok
-
            00:07 <@nop> ok
-
            00:07 <@nop> anyway
-
            00:07 < |EN3RGY|> ok jeremiah_
-
            00:07 <@nop> RC3 is here, and it includes what was requested as well as bugfixes
-
            00:07 <@nop> version is definitely there this time :)
-
            00:07 <@nop> so we're all happy
-
            00:07 < {Due}> nop, before of that, waht is RC3 ?
-
            00:07 <@nop> oh
-
            00:07 <@nop> Release Candidate 3 of 1.1
-
            00:07 < {Due}> ajam
-
            00:08 <@nop> the neat thing about it, is the next version will be ...
-
            00:08 <@nop> 1.1 STABLE!!!
-
            00:08 <@nop> 1.1.0 STABLE
-
            00:08 <@nop> so we have room for error ;)
-
            00:08 < Rav-> haha
-
            00:08 <@nop> we'll take the freent approach
-
            00:08 < {Due}> nop i know about this soft just 5 minuts ago, plz tell me what this does
-
            00:08 <@nop> build 500392938103967
-
            00:08 <@nop> Due - http://help.invisiblenet.net
-
            00:08 <@mids> {Due}: we will help you later
-
            00:08 < {Due}> oka
-
            00:09 <@nop> ok
-
            00:09 <@nop> 3) Security Advisory
-
            00:09 <@nop> accidentally came upon some weaknesses in Adelphia's PowerLink Network that is crucial to privacy
-
            00:09 <@nop> so I felt the need to send them an advisory
-
            00:09 <@nop> and post it to iip-dev list
-
            00:09 < Debrys> Due: http://www.invisiblenet.net/iip/aboutMain.php take a look at this page....... and also the interview and docs....... most of the things you're asking yourself get answered there :) they're really no nonsense page..... pure info and straight to the point
-
            00:10 <@nop> anyway
-
            00:10 <@nop> if any users use adelphia
-
            00:10  * {Due} reading ;)
-
            00:10 <@nop> that is the reason I posted it
-
            00:10 <@nop> for the benefit of our users
-
            00:10 <@nop> as they host 5.5 million customers
-
            00:10 <@nop> so we might have a few
-
            00:11 <@nop> hopefully they will adhere to the advisory and fix it
-
            00:11 <@nop> if not
-
            00:11 <@nop> it will be publicized 30 days from the date
-
            00:11 <@nop> which will apply a bit of pressure to fix the problem
-
            00:11 <@nop> moving on
-
            00:11 <@nop> Connection issue
-
            00:11 <@nop> with the upgrade
-
            00:11 <@nop> a lot of people probably have been shutting off their previous rc2 relay
-
            00:11 <@nop> and turning on rc3
-
            00:12 <@nop> this probably will happen over a span of a couple weeks
-
            00:12 <@nop> most people aren't consistant with keeping track of upgrade day
-
            00:12 <@nop> also
-
            00:12 <@nop> there were a few times this past week that the colocation facility of the ircd server had some network maintenance
-
            00:12 <@nop> this caused a few hiccups
-
            00:12 <@nop> and it may have beend difficult to get on
-
            00:12 <@nop> this is over
-
            00:13 <@nop> and it should be pretty clean (other than relays dropping from time to time)
-
            00:13 < jeremiah_> will a relay notify the admin when it should be updated?
-
            00:13 <@nop> as in the IIP software notify?
-
            00:13 <@mids> currently, no
-
            00:13 <@nop> the relay admin?
-
            00:13 <@nop> that should be optional
-
            00:13 <@nop> for debatable anonymity reasons
-
            00:13 < jeremiah_> yeah, but it isn't an option right now, correct?
-
            00:13 <@codeshark> nop: maybe a simple version check would help
-
            00:13 <@nop> correct it is not
-
            00:14 <@nop> definitely an option that could appear in 1.1
-
            00:14 <@nop> stable
-
            00:14 <@nop> but I can't promise that
-
            00:14 <@nop> as we want to keep changes to a minimum
-
            00:14 < jeremiah_> ok
-
            00:14 <@mids> I suggest we dont put it in
-
            00:14 <@mids> only fix bugs
-
            00:14 <@nop> as well do I for this version
-
            00:14 <@codeshark> yes, no new features
-
            00:15 <@hezekiah> I agree.
-
            00:15 <@nop> ok
-
            00:15 <@mids> are there any bug reports yet?
-
            00:15 <@nop> I know that codeshark had one
-
            00:15 <@codeshark> yeah, couldn't send mail, damn invisiblenet ;)
-
            00:16 <@nop> haha
-
            00:16 <@nop> send it when you can
-
            00:16 <@nop> there's a couple of firewall questions
-
            00:16 <@codeshark> iip.log, isproxy.ini, mynode.ref, seed.rnd are stored in current directory instead of ~iip/.iip  dir
-
            00:16 <@nop> I think we might have to be more clear that 6667 isn't the only connection that should be open
-
            00:17 <@nop> can you officially send it as an email
-
            00:17 <@nop> it helps for tracking
-
            00:17 <@codeshark> doesn't work ;)
-
            00:17 <@nop> mail shoudl work
-
            00:17 <@mids> nop: do you mean firewall rules for outgoing connections?
-
            00:18 <@nop> yes
-
            00:18 <@mids> ok
-
            00:18 <@nop> I don't think all users realize how it works
-
            00:18 <@mids> yeah we can add that to the firewall chapter of the FAQ
-
            00:18 <@nop> ok
-
            00:18 <@mids> or create that one if it doesnt exist
-
            00:18 <@nop> anyway, cs can you submit it to our sourceforge bug report page
-
            00:18 < {Due}> ok, one second
-
            00:19 < {Due}> may i ask something?
-
            00:19 <@nop> hold
-
            00:19 <@nop> what's next on agenda
-
            00:19 <@mids> question round!
-
            00:19 <@nop> ok
-
            00:19 <@nop> due
-
            00:19 < {Due}> ;)
-
            00:19 <@nop> you can ask
-
            00:19 < {Due}> oka
-
            00:19 <@codeshark> nop: ok
-
            00:20 < {Due}> 1) mids says tha this servers is anonymoues
-
            00:20 < {Due}> anonymous
-
            00:20 < {Due}> <mids> we dont know where the server is
-
            00:20 < {Due}> newsserver1.ussc.com
-
            00:20 <@nop> that's a relay
-
            00:20 <@nop> 1 of many
-
            00:20 <@nop> your peers protect you
-
            00:20  * Neo stands in question queue
-
            00:21 < {Due}> but what is the meaning of all that?
-
            00:21 < {Due}> i mean, all the ircu servers
-
            00:21 <@mids> I'll try to help {Due} in private
-
            00:21 < {Due}> has vhost
-
            00:21 < {Due}> oka mind
-
            00:21 <@nop> neo yes
-
            00:21 <@mids> pop queue, neo
-
            00:21 < Neo> Ok.
-
            00:22 < Neo> nop: can you please give us:
-
            00:22 < Neo> diff 'invisible internet' 'tarzan'
-
            00:22 < Neo> thoughts please.
-
            00:22 <@nop> I need to finish my read on tarzan before I can answer that
-
            00:22 <@nop> but they are similar
-
            00:22 <@nop> but I find some problems with tarzan
-
            00:22  * jeremiah_  would like a url that describes tarzan
-
            00:23 <@nop> neo do you have the url handy
-
            00:23 < Neo> http://www.pdos.lcs.mit.edu/tarzan/index.html
-
            00:23 < jeremiah_> thank you
-
            00:23 <@nop> I'll tell you what neo
-
            00:23 <@nop> when I finish my read
-
            00:23 <@nop> I will send you an email
-
            00:23 <@nop> on my thoughts
-
            00:24 <@hezekiah> What if you just submit the email to iip-dev?
-
            00:24 <@nop> ok
-
            00:24 < Rav-> can i make a suggestion
-
            00:24 < Rav-> for the node.ref etc files
-
            00:24 <@nop> there are aspects that can be fully utilized from tarzan
-
            00:24 < Neo> nop: thanks
-
            00:24 < Rav-> store them in user home directories
-
            00:24 <@hezekiah> That would be nice.
-
            00:25 < Rav-> so its easier to secure a proxy
-
            00:25 < Rav-> and have it update noninteractively
-
            00:27 < Debrys> ahem:....... it would be nice if i could use IIP withouth installation and copied file....... i.e. copy the files on a disk......... go to someone with a pc and irc-client........ run IIP from disk withouth any files copied to the hard-disk....... so i would be thankfull if this user-home-dirs thingie would be an option
-
            00:29 <@mids> currently it _should_ look in several places
-
            00:29 <@mids> current directory, homedir
-
            00:29 <@mids> and system wide directory
-
            00:29 <@mids> I dont remember in what order that happens
-
            00:29 < jeremiah_> it would also good to be able to run the system from memory w/o config files so someoen could use it and then delete it easily (not sure how possible this is right now)
-
            00:29 < Debrys> okay, thanks for the info mids
-
            00:30 <@nop> knoppix
-
            00:30 <@nop> www.knoppix.net
-
            00:30 <@mids> Debrys: but codeshark just reported a bug on that, so it might not work :)
-
            00:30 <@codeshark> Debrys: yes, there's a problem with this feature
-
            00:30 <@codeshark> some files are stored in local directory
-
            00:30 < xcasex> jeremiah_: just mount a portion of ram to the filesystem D:
-
            00:30 < xcasex> :D
-
            00:30 < Debrys> well, i'm okay if i know it will work in the future :)
-
            00:31 < Debrys> its just a possibility i would miss if it would be discarded in future development
-
            00:31 < Rav-> from memory only the node.ref file needs to be local.. is that right?
-
            00:32 <@nop> 7and listen.ref
-
            00:32 <@nop> and
-
            00:32 < Debrys> cs: local dir is okay....... because the local dir would be the diskette?
-
            00:32 <@nop> and isproxy.ini
-
            00:32 < Rav-> yeah thats right
-
            00:32 < Rav-> 3 files
-
            00:32 <@nop> although
-
            00:32 < Debrys> the only problem would be if its run from a cd........ but thats okay to me
-
            00:32 <@mids> you can specify the file location if you run isproxy
-
            00:32 <@mids> try: isproxy -h
-
            00:32 <@mids> if will give an overview of options
-
            00:33 < Debrys> °nods°
-
            00:33 < Rav-> atm i have those 3 files rw for users since iip starts as a user daemon not a system daemon
-
            00:34 <@nop> ok
-
            00:34 <@nop> I'll bb in a bit
-
            00:35 <@mids> other questions?
-
            00:35 < Debrys> not for now or 1.1
-
            00:35 < Rav-> mmm... update notification?
-
            00:35 < Rav-> wouldnt be anonymous i guess
-
            00:36 <@mids> Rav-: the server could send a control message 
-
            00:36 < Rav-> okay
-
            00:36 <@mids> atually it already sends the version I think
-
            00:36 <@mids> but then again
-
            00:36 <@mids> if I run a public relay
-
            00:37 <@mids> what should the relay do if it sees that it is too old?
-
            00:37 < Rav-> you could include it in node.ref
-
            00:37 < Rav-> dunno
-
            00:37 < jeremiah_> it could be given the option of emailing the admin
-
            00:37 < jeremiah_> or anonymail
-
            00:37 <@mids> yeah maybe
-
            00:37 < Debrys> what if clients get to know about a new version from other clients..... not the server? this could also work in a decentralized network........ since if update notification is server dependant it wouldn't work when IIP goes decentralized?
-
            00:38 < Rav-> yeah thats why i was thinking node.ref
-
            00:38 <@mids> I dont think it is possible to do it in a decentralized environment
-
            00:38 <@mids> unless you sign those messages by the IIP development team
-
            00:38 <@mids> since otherwise it would be too easy to send fake messages
-
            00:38 < hezekiah> Right
-
            00:39 < Debrys> thats true
-
            00:39 < Rav-> hmm
-
            00:39 <@mids> actually
-
            00:39 <@mids> once it is fully distributed
-
            00:39 <@mids> it could well be that there are multiple version
-
            00:39 < Debrys> but would it be THAT evil if a fake "new version" message is received? except of being annoying?
-
            00:39 <@mids> +s
-
            00:39 <@mids> and clones etc
-
            00:40 <@mids> Debrys: it would be easy to do, and make it not useful anymore
-
            00:40 < Rav-> that should be a good case for update notification
-
            00:40 < Debrys> okay
-
            00:40 <@mids> what would be better is the admins subscribing to the IIP development mailinglist
-
            00:40 < Rav-> dont know how you would dist the message
-
            00:40 <@mids> :)
-
            00:40 <@mids> maybe we should make other mailinglists in the future
-
            00:40 <@mids> like iip-announce
-
            00:41 < xcasex> dont forget the-iip-133+3
-
            00:41  * jeremiah_  has to go
-
            00:41 < jeremiah_> bye
-
            00:41 < jeremiah_> will login later
-
            00:41 < Rav-> when you say distributed, do you mean as part of a decentralised iip network or do you mean you are releasing the server daemon for use on other networks
-
            00:41 < hezekiah> bye
-
            00:44 <@mids> Rav-: decentralized
-
            00:46 < hezekiah> Well, I'm off. Bye everyone.
-
            00:47 <@mids> ok
-
            00:47 <@mids> hereby I declare the meeting beeing over
-
            00:47 <@mids> see you next week, same time, same place
-
            00:48 <@mids> feel free to hang around a bit
-
            00:48 <@mids> and if there are more questions / comments, ask em in #iip or #anonymous
-
            --- Log closed Wed Dec 11 00:48:34 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting25.html b/www.i2p2/pages/meeting25.html
deleted file mode 100644
index 995da1b3..00000000
--- a/www.i2p2/pages/meeting25.html
+++ /dev/null
@@ -1,150 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 25{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 25
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Topic for #iip-dev is IIP Meeting - logfiles:
-
            http://mids.student.utwente.nl/~mids/iip/
-
            <nemesis> nop, no meeting today?
-
            <nop> yes
-
            <nop> sorry
-
            <nop> ok
-
            <nop> welcome
-
            <nemesis> hi nop ;)
-
            <nop> hi
-
            <nop> agenda
-
            <nop> 1) welcome
-
            <nemesis> whats going on? everybody sleeps?
-
            <nop> 2) Happy New Year
-
            <nop> 3) Happy Holidays
-
            <chscrtr> hi, happy new year
-
            <nop> 4) IIP
-
            <nemesis> hehe, happy new year too
-
            <mrflibble> happy new year! :)
-
            <nop> 5) IIP logo contest
-
            <nop> 6) CryptoCon
-
            <nop> 4) IIP
-
            <nop> ok IIP
-
            <nop> it's kind of stagnant because of the holidays
-
            <nop> but I believe we're picking it back up
-
            <nop> any bug reports please send to iip@invisiblenet.net
-
            <nop> ok
-
            <nop> 5) IIP logo contest
-
            <nop> we'll being putting up something on our site about the rules etc
-
            <nop> and display the drawings we have so far
-
            <nop> please help out if you can
-
            <nop> get a free t-shirt and your logo on it
-
            <nop> 6) CryptoCon
-
            <mrflibble> cool
-
            <nop> we're trying to get a program committee and some organizational
-
            planning for Jan 2004 to have cryptocon happen
-
            <nop> join #cryptocon for any assistance etc
-
            <nop> anyway, that's about it
-
            <nop> questions?
-
            <nop> questions?
-
            <nop> ;)
-
            <mrflibble> nope
-
            <nop> ok
-
            <nop> meeting ajourned
-
            <Neo> nope
-
            <Neo> thanks. :)
-
            <mrflibble> np
-
            <mrflibble> oo, 1 thing
-
            <mrflibble> about cryptocon
-
            <mrflibble> is there a particular reason for organising your/your own?
-
            <mrflibble> there are general crypto confs out there that cyou could submit
-
            stuff 2
-
            <nop> well
-
            <nop> we want to attract businesses to meet cipherpunks
-
            <nop> and push cryptography more than it is
-
            <nop> this will be different
-
            <mids> fsck
-
            <mrflibble> gotcha
-
            <nop> missed it
-
            <nop> ;)
-
            <mids> sorry folks :)
-
            <mrflibble> it will just be a lot of work 4 u all
-
            <mids> is there still a point in bringing the logger here?
-
            <mrflibble> lol
-
            <nemesis> hehe
-
            <nop> well mrflibble I don't think it will be
-
            --- Log opened Wed Jan 08 00:14:47 2003
-
            00:14 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            00:14 [Users #iip-dev]
-
            00:14 [ chscrtr] [ logger] [ mrflibble] [ Neo] [ Nostradumbass] [ w    ] 
-
            00:14 [ co     ] [ mids  ] [ nemesis  ] [ nop] [ UserX        ] [ wilde] 
-
            00:14 -!- Irssi: #iip-dev: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal]
-
            00:15 < nop> we have a year to plan
-
            00:15 < mrflibble> true
-
            00:15 -!- Irssi: Join to #iip-dev was synced in 43 secs
-
            00:16 < nop> plus we need to raise money
-
            00:16 < nop> and this might help
-
            00:16 < nop> since no one likes to donate
-
            00:16 < nop> ;)
-
            00:16 < chscrtr> error - less than a year
-
            00:16 < nemesis> hm... nop, you are using knoppix right now, or?
-
            00:17 < mrflibble> ic
-
            00:17 < nop> suse right now
-
            00:17 < mrflibble> u might need to advertise a lot to get the sponsers
-
            00:17 < mrflibble> which will cost
-
            00:18 < nemesis> are you think that iip is important/stable enough to show it the world?
-
            00:18 < chscrtr> not that much, PR can be cheap
-
            00:18 < nop> nemesis I don't think I'm showing it to the world
-
            00:19 < mrflibble> hmm, i hope so
-
            00:19 < nop> It's a conference, separate concept
-
            00:19 < mids> ok, lizzy__ raised the point that the idleing time might give away too much information
-
            00:19 < nemesis> hehe
-
            00:19 < nop> yes it does
-
            00:19 < mids> so (s)he suggested to disable it server side
-
            00:19 < nop> we can take that out
-
            00:19 < nop> I've been wanting to do that
-
            00:19 < nop> ok
-
            00:19 < nemesis> cause, it would be nice when future releases are packed for trustix ;)
-
            00:19 < nop> will work on it
-
            00:19 < mids> also that registering your nickname pinpoints you and makes you more traceble
-
            00:19 < mids> so there should be a warning against that
-
            00:19 < mids> .
-
            00:20 < mids> I suggest that we metion the possible risks and issues more clear in the documentation
-
            00:20 < mids> mention
-
            00:20 < mrflibble> why is registering mae u more traceable?
-
            00:20 < mrflibble> make
-
            00:20 < mids> mrflibble: because once you identify, then you are guaranteed the same person as before
-
            00:21 < mids> while if you just use the same nick, you might not be the same person
-
            00:21 < mids> registering and identifying makes you pseudonymous
-
            00:21 < mids> instead of anonymous
-
            00:21 < mrflibble> oh
-
            00:21 < mrflibble> but that's good tho
-
            00:21 < mrflibble> trust is important
-
            00:24 < mids> yes, but you build a public record of information
-
            00:24 < mids> each time that you connect and say something, you add more info 
-
            00:24 < mids> there are tools which can identify the identity of people based on language patterns.
-
            00:25 < mids> the ones that I tried are not that good, but it is often quite easy to spot errors and make conclusions.
-
            00:25 < mids> I believe that it wouldn't harm to add a chapter about the risks even in an 'anonymous' environment to our manual
-
            00:25 < mids> and I invite lizzy__ to start with that chapter.
-
            00:25 < mids> .
-
            00:25 < Nostradumbass> That's why passing your text through multiple language translators can be useful
-
            00:27  * mids passes the microphone back to the audience
-
            00:28 < mids> oh, excuse for joining that late, if someone can send me the logs of the first 15 minutes then I would much appreciate it.
-
            00:28 < mids> .
-
            00:29 < mrflibble> ooh
-
            00:29 < mrflibble> gotcha
-
            00:29 < mrflibble> mids, make that about 5 minutes :)
-
            00:29 < mids> heh.
-
            00:30 < mids> did nop already say something about 1.1-final?
-
            00:30 < mids> like when we claim that it will be released ;)
-
            00:31 < mrflibble> nope
-
            00:31 < mrflibble> ill send u a capture
-
            00:31 < mids> gracias
-
            00:31 < mrflibble> shit, i cant
-
            00:31  * mrflibble slaps mrflibble around a bit with a large trout
-
            00:31 < mrflibble> ill cut and paste
-
            00:32 < mrflibble> hope i dont flood myself off
-
            00:32 < mids> in private please
-
            00:32 < mids> okay, now this unofficial meeting is officially closed
-
            00:32 < mids> :)
-
            00:32 < nemesis> looool
-
            --- Log closed Wed Jan 08 00:33:43 2003
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting26.html b/www.i2p2/pages/meeting26.html
deleted file mode 100644
index 99f95dc5..00000000
--- a/www.i2p2/pages/meeting26.html
+++ /dev/null
@@ -1,269 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 26{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 26
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Jan 14 22:44:57 2003
-
            22:45 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            22:45 [Users #iip-dev]
-
            22:45 [ logger] [ pox] 
-
            22:45 -!- Irssi: #iip-dev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
-
            22:45 -!- Irssi: Join to #iip-dev was synced in 3 secs
-
            23:48 -!- StoVoKor|away is now known as StoVoKor
-
            23:58 < mids> Tue Jan 14 22:58:16 UTC 2003
-
            23:59 < mids> 1 minute
-
            --- Day changed Wed Jan 15 2003
-
            00:00 < mids> Tue Jan 14 23:00:00 UTC 2003
-
            00:00 < mids> Welcome to the 26th IIP meeting
-
            00:00 < mids> I didn't get any agenda items from anybody, so I'll just propose my own:
-
            00:00 < mids> - Release of 1.1-final
-
            00:00 < mids> do you guys have anything else to add?
-
            00:00 < hezekiah> (I propose an agenda item: What's the current major feature being worked on in IIP 1.2 dev?)
-
            00:01 < mids> great
-
            00:01 < FillaMent> I have a couple suggestions for additions to anonymail
-
            00:01 < mids> ok
-
            00:01 < mids> Agenda:
-
            00:02 < mids> - What's the current major feature being worked on in IIP 1.2 dev
-
            00:02 < mids> - Anonymail suggestions
-
            00:02 < mids> - Release of 1.1-final
-
            00:02 < mids> .
-
            00:02  * mids hands the microphone to hezekiah 
-
            00:02 < FillaMent> Also like to note a project that I'm working on that uses IIP
-
            00:02 < hezekiah> I have no clue. It was actually a question. :) Nop?
-
            00:02  * hezekiah hands the microphone to nop.
-
            00:02 < nop> hi
-
            00:02 < nop> ok
-
            00:02 < nop> welcome
-
            00:03 < nop> ok on the agenda
-
            00:03 < nop> mids take it away
-
            00:04 < mids> no, you tell what the status of 1.2 is
-
            00:04 < nop> ok
-
            00:04 < nop> well
-
            00:04 < nop> lots of grindy stuff
-
            00:04 < nop> mainly taking care of the grunt stuff
-
            00:04 < hezekiah> (Ahmen!)
-
            00:04 < nop> getting the core ready for hardcore decentralization and crypto, we're in the midst of deciding crypto libraries, we think cryptlib and GnuMP 
-
            00:05 < nop> and are looking at a few possibilities for routing, either the listener route concept, or possibly chord type routing
-
            00:05 < nop> and that's mainly it for right now
-
            00:05 < nop> for 1.2
-
            00:05 < mids> cool
-
            00:05 < nop> 1.1 status, is if no one has any bugs in a weeks time
-
            00:06 < nop> then we will probably move to defcon 1.1
-
            00:06 < nop> ;)
-
            00:06 < nop> meaning 1.1 Release
-
            00:06 < mids> stick to the agenda nop
-
            00:06 < mids> anonymail features are first
-
            00:06 < nop> I didn't see an agenda
-
            00:06 < mids> :p
-
            00:06 < hezekiah> Mids, behave! :)
-
            00:06 < hezekiah> ;-)
-
            00:06 < nop> ok
-
            00:06 < nop> I guess anonymail suggestions
-
            00:06 < mids> - Anonymail suggestions
-
            00:06 < nop> take it away whoever that was
-
            00:06 < mids> FillaMent?
-
            00:06 < FillaMent> Okay, I just have two quick ones...
-
            00:07 < FillaMent> 1) Some sort of escape character to do \n's.
-
            00:07 < hezekiah> Yeah!
-
            00:07 < FillaMent> Discuss or move on to #2?
-
            00:07 < hezekiah> Perhaps, "\n" for a newline, and "\\n" for a literal, "\n".
-
            00:08 < mids> what character do you suggest?
-
            00:08 < mids> ok
-
            00:08 < hezekiah> (Like how you would do in C with printf.)
-
            00:08 < FillaMent> C, Perl, Java....
-
            00:08 < hezekiah> C++ ... :)
-
            00:08 < FillaMent> Nah, make it vbCRLF
-
            00:08 < mids> and \\\\n for literal \\n :)
-
            00:08 < hezekiah> Yup1
-
            00:08 < mids> vbCRLF?
-
            00:09 < FillaMent> visualbasicCarriageReturnLineFeed
-
            00:09 < mids> are you serious?
-
            00:09 < hezekiah> (I hope not.)
-
            00:09 < FillaMent> I used to hack vbScript (no, I'm not serious. \n is what everyone will be familiar with)
-
            00:09 < hezekiah> So, what was suggestion number 2?
-
            00:10 < thecrypto> damn wireless network
-
            00:10 < FillaMent> 2) Stripping non-plain text MIME garbage from mails that come from the internet and replacing it with something to the effect of <One part MIME binary/word-doc stripped>
-
            00:11 < FillaMent> Forgive me if I'm incorrectly implying MIME
-
            00:11 < mids> I dont really agree
-
            00:11 < mids> you should be able to receive RFC2015 compatible PGP signatures
-
            00:11 < mids> and stuff
-
            00:11 < hezekiah> Yeah.
-
            00:12 < hezekiah> But changing Quoted-Printable to plain ASCII might not be a bad idea if it isn't already implemented.
-
            00:12 < FillaMent> And that's a specific mime type?
-
            00:12 < FillaMent> PGP sig I mean.
-
            00:12 < mids> it is
-
            00:12 < hezekiah> There are OpenPGP sigs that have a mime type.
-
            00:12 < mids> I can understand that it will be a lot of work to do MIME right
-
            00:13 < mids> since there are a lot of MIME types
-
            00:13 < mids> and browsers who violate it
-
            00:14 < hezekiah> "2) Stripping non-plain text MIME ..." (Wouldn't they be in base64 if they aren't plain ASCII anyway? And if not, then couldn't they just be converted?)
-
            00:14 < mids> maybe we should just forward the suggestions to codeshark
-
            00:15 < mids> since he knows how the app looks
-
            00:15 < hezekiah> Or even, if it has to be stripped, you could offer an option to retrieve it (in base64 or 7-bit.) That way you can save it via copy-paste, and decode/read it on your hard drive.
-
            00:15 < mids> (he made it)
-
            00:15 < mids> and what he can implement
-
            00:15 < hezekiah> Good idea!
-
            00:15 < FillaMent> The other day I got a mail that was written with MS Outaluck/W3rd and it came in as multipart MIME. The first part was a plain txt version of the message, the second was an RTF will all the formatting Markup
-
            00:15 < nop> this is something
-
            00:15 < nop> that needs to be sent to anonymail
-
            00:15 < nop> oops
-
            00:15 < nop> codeshark
-
            00:15 < mids> yeah
-
            00:15  * FillaMent digresses.
-
            00:15 < mids> lets just pass it on
-
            00:15 < mids> and see what his imput is
-
            00:16 < mids> - Release of IIP 1.1-final
-
            00:16 < mids> my comments: got to check the sourceforge bugtracker
-
            00:16 < mids> but I dont think that there are any code bugs open
-
            00:17 < hezekiah> Not the last time I saw ... (checking now.)
-
            00:17 < mids> http://sourceforge.net/tracker/index.php?func=detail&aid=651711&group_id=50945&atid=461514
-
            00:17 < mids> (files stored in wrong dir)
-
            00:17 < mids> http://sourceforge.net/tracker/index.php?func=detail&aid=655568&group_id=50945&atid=461514
-
            00:17 < mids> (-h doesnt work)
-
            00:17 < mids> that option DOES work for me
-
            00:17 < mids> please check it
-
            00:18 < mids> and if it works for everybody, we got to mark that report as invalid
-
            00:18 < mids> http://sourceforge.net/tracker/index.php?func=detail&aid=654147&group_id=50945&atid=461514
-
            00:18 < mids> (FreeBSD socket call)
-
            00:18 < mids> I dont have FreeBSD, someone with FreeBSD should check
-
            00:19 < mids> .
-
            00:19 < mids> Also we should really really supply some script that people can put in their /etc/init.d/
-
            00:20 < mids> ping?
-
            00:20 < hezekiah> It looks like the guy who did the FreeBSD bug ...
-
            00:21 < hezekiah> ... already found and pointed out the problem.
-
            00:21 < hezekiah> http://sourceforge.net/tracker/download.php?group_id=50945&atid=461514&file_id=37660&aid=654147
-
            00:22 < hezekiah> That's the link to the patch file. AF_INET apparently needs to be PF_INET on FreeBSD.
-
            00:22 < hezekiah> The patch was simple:
-
            00:23 < hezekiah> 484,489c484
-
            00:23 < hezekiah> < 	// If statement added by wiht, since FreeBSD uses PF_INET.
-
            00:23 < hezekiah> < 	#ifdef __FreeBSD__
-
            00:23 < hezekiah> < 		sh->Socket = socket(PF_INET, SOCK_STREAM, 0);
-
            00:23 < hezekiah> < 	#else
-
            00:23 < hezekiah> < 		sh->Socket = socket(AF_INET, SOCK_STREAM, 0);
-
            00:23 < hezekiah> < 	#endif
-
            00:23 < hezekiah> ---
-
            00:23 < hezekiah> > 	sh->Socket = socket(AF_INET, SOCK_STREAM, 0);//PF_INET);
-
            00:23 < mids> I see, but then I dont know why the original ifdef was there at first?
-
            00:23 < hezekiah> What do you think, nop?
-
            00:23 < hezekiah> The top section should be the new code. The bottom section should be the old.
-
            00:23 < nop> that should work
-
            00:24 < hezekiah> Yeah. The bottom is the old.
-
            00:24 < nop> you should commit looks fine
-
            00:24 < hezekiah> Do you want me to write it up, commit, and label the bug as fixed, nop?
-
            00:24 < nop> but why is it different
-
            00:24 < hezekiah> Apparently, FreeBSD requires PF_INET instead of AF_INET as the first arguement for socket.
-
            00:25 < hezekiah> I don't know why.
-
            00:25 < hezekiah> But, the writter said this fixed the problem. Commit?
-
            00:25 < nop> yes
-
            00:25 < hezekiah> OK.
-
            00:25 < mids> ok
-
            00:26 < mids> who can look into the filepath problem?
-
            00:27 < FillaMent> I don't get that problem. If I try and start IIP as a different user or not in ~iip it says it can't write the log
-
            00:28 < mids> ok, we got to check the reported bugs and report on that on the mailinglist
-
            00:28 < mids> lets try to do that this week
-
            00:28 < mids> .
-
            00:28 < mids> The biggest problem is the scalability of IIP
-
            00:28 < mids> RC2 was kinda stable
-
            00:28 < mids> RC3 isnt
-
            00:29 < mids> why?
-
            00:29 < mids> Imho it is because the node.ref is so big
-
            00:29 < mids> so a lot of potential bad node
-
            00:29 < mids> nodes
-
            00:29 < mids> it is really, anonymity vs stability
-
            00:29 < mids> .
-
            00:29 < hezekiah> I noticed that. But some of them are just slow, not necisarily bad.
-
            00:29 < mids> the problem is the lot of people Pinging Out
-
            00:30 < mids> the solution that I suggest is releasing RC3 with a minimal node.ref
-
            00:30 < mids> only 4 nodes or something
-
            00:30 < mids> .
-
            00:31 < nop> I agree
-
            00:31 < FillaMent> Pardon my lack of design knowledge... IIRC uses relays like freenet and IRC, right?
-
            00:32 < FillaMent> node == relay
-
            00:32 < mids> they are more static
-
            00:32 < mids> once you connect
-
            00:32 < nop> well
-
            00:32 < nop> at least in 1.1
-
            00:32 < mids> you stay connected through them for the same session
-
            00:32 < nop> they won't be forever
-
            00:32 < FillaMent> But, it's still one node passes to other nodes
-
            00:32 < nop> yes
-
            00:33 < mids> if you keep a big list of nodes, then the path is very long
-
            00:33 < mids> hence a lot of potential problems
-
            00:33 < FillaMent> Why not just make it so that it goes through the node.ref and picks a few at random, and keeps doing that. The user could maybe set the number. This would maybe distribute the load a little more?
-
            00:34 < mids> the current protocol doesnt support selecting the amount of hops
-
            00:34 < nop> and we're not changing it in this version
-
            00:34 < nop> ;)
-
            00:34 < FillaMent> Okay, then it's outside my technical knowledge... what about the starting point?
-
            00:34 < FillaMent> or is the TTL the number or nodes in node.ref
-
            00:35 < FillaMent> s/or/of/
-
            00:35 < mids> each node connects to a node in its node.ref at random
-
            00:35 < mids> until it 'accidently' hits the server
-
            00:35 < mids> so if you have a lot of nodes
-
            00:35 < FillaMent> got it.
-
            00:35 < mids> it will have huge paths
-
            00:36 < mids> that is why I would suggest a manually crafter first layer of public nodes
-
            00:36 < FillaMent> Could another solution be to make 'the' server 'a' server?
-
            00:36 < mids> so you decrease the amount of hops
-
            00:36 < LeeroklaLacerta> Is there any sort of reliability-index-type thing?
-
            00:36 < mids> you only have 1 end-node
-
            00:36 < mids> there isnt, since you dont know what nodes a node connects through
-
            00:37 < mids> if your connection goes down, you dont know what node caused it
-
            00:37 < mids> it can be anyone on your path
-
            00:37 < LeeroklaLacerta> K.
-
            00:37 < mids> and you dont know your path
-
            00:37 < FillaMent> Is there anyway for the end user it increase the reliability of IIP?
-
            00:37 < mids> yes, manually edit your node.ref
-
            00:38 < mids> and put only some stable nodes on it
-
            00:38 < mids> and dont let it update the node.ref automatically
-
            00:38 < FillaMent> mids: I mean setting up a relay or something.
-
            00:38 < mids> ofcourse you dont know what are stable nodes, unless you have some inside knowledge about the IIP topography
-
            00:39 < mids> Trent for example directly connects to a node which connects to the IIP server node
-
            00:39 < mids> otherwise it would go down all the time
-
            00:39 < mids> resulting in a really bad network
-
            00:41 < FillaMent> To save me some time, where does iip store the nodes.ref on a linux box?
-
            00:41 < mids> ~/.iip/
-
            00:41 < mids> or the local directory
-
            00:42 < mids> ok, I want to quit this item
-
            00:42 < mids> homework for next week:
-
            00:42 < mids> think about the issues
-
            00:42 < mids> and propose suggestions to the mailinglist
-
            00:42 < FillaMent> Give me 10 min and I'll have a kludge for the massive node list problem
-
            00:42 < mids> or to a developper (if you arent subscribed)
-
            00:43 < mids> .
-
            00:43 < mids> questions?
-
            00:51 < hezekiah> You almost have your "kludge" (I don't know what that word means) for the node list problem yet, FillaMent?
-
            00:52 < FillaMent> kludge is coding duct tape, and yes.
-
            00:52 < hezekiah> Ah.
-
            00:53 < thecrypto> the full definition is http://www.tuxedo.org/~esr/jargon/html/entry/kluge.html
-
            00:54 < mids> hezekiah: thanks for putting your hands on those 2 bugtracker items
-
            00:55 < hezekiah> No problem. I still don't know how to assign a bug to myself. Otherwise, I would have "officially" picked up the PF_INET one.
-
            00:55 < hezekiah> I couldn't find the button/link/whatever that lets you assign a bug to yourself.
-
            00:57 < mids> only project admins seem to be able to assign bugs for our project
-
            00:57 < hezekiah> Ah
-
            00:57 < hezekiah> That would explain it! :)
-
            00:59 < hezekiah> OK. Well, I'm going to leave now. Bye everyone! :)
-
            00:59 < LeeroklaLacerta> Good bye.
-
            01:04 < mids> ok
-
            01:04 < mids> I am gone too
-
            01:04 < mids> bye
-
            01:08 < LeeroklaLacerta> Everyone's leavin'?
-
            01:08 < LeeroklaLacerta> Is the meeting over?
-
            01:09 < FillaMent> I'm still here. Perhaps my time estimate was a bit off. I love/hate perl.
-
            01:10 < LeeroklaLacerta> What's perl got to do with it?
-
            01:10 < FillaMent> My node.ref kluge
-
            01:10 < LeeroklaLacerta> Ah.
-
            01:11 < FillaMent> I should just describe it to someone competant and let them do it in like 5min
-
            01:11 < LeeroklaLacerta> I'm just here for the heck of it.
-
            01:16 < LeeroklaLacerta> I'm going back to #anonymous.
-
            01:17 < FillaMent> Ha ha!
-
            01:39 < FillaMent> Anyone care to enlighten me as to why in perl, when I push an item into an array, /every/ item ends up being that item?
-
            02:59 < sdgg> hi
-
            03:05 < FillaMent> Know how long an md5 signature is supposed to be?
-
            03:10 < sdgg> 128 bits I believe
-
            03:14 < sdgg> Does anyone know of a good tutorial on c/c++ for *nix programming?
-
            03:14 < sdgg> Or somewhere I can look?
-
            05:10  * FillaMent is away: Destinking myself
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting28.html b/www.i2p2/pages/meeting28.html
deleted file mode 100644
index bd7d1636..00000000
--- a/www.i2p2/pages/meeting28.html
+++ /dev/null
@@ -1,149 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 28{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 28
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Jan 28 22:35:17 2003
-
            22:35 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            22:35 [Users #iip-dev]
-
            22:35 [ co] [ logger] [ pox] [ ptm] [ UserX] 
-
            22:35 -!- Irssi: #iip-dev: Total of 5 nicks [0 ops, 0 halfops, 0 voices, 5 normal]
-
            22:35 -!- Irssi: Join to #iip-dev was synced in 2 secs
-
            22:41 -!- mode/#iip-dev [+o mids] by Trent
-
            22:41 -!- mode/#iip-dev [+v logger] by mids
-
            22:41 -!- mode/#iip-dev [+o UserX] by mids
-
            23:56 -!- mode/#iip-dev [+o nop] by mids
-
            --- Day changed Wed Jan 29 2003
-
            00:00 <@mids> Tue Jan 28 23:00:00 UTC 2003
-
            00:00 <@nop> hi
-
            00:00 < Debrys> greetings
-
            00:00 < case> hallo
-
            00:00 <@nop> hi
-
            00:00 < Bouris> Hi.
-
            00:00 < MrEcho> hey case
-
            00:00 <@nop> meeting started
-
            00:00 < case> sup echo
-
            00:01 <@mids> nop: agenda please
-
            00:01 <@nop> ok
-
            00:01 <@nop> I thought you had it
-
            00:01 <@nop> ;)
-
            00:01 <@nop> 1) welcome
-
            00:01 <@mids> 1) Welcome
-
            00:01 <@mids> 2) Normal stuff
-
            00:01 <@mids> 3) Questions
-
            00:01 <@mids> .
-
            00:01 <@nop> sure that works
-
            00:01 <@nop> welcome to the nth IIP-dev meeting
-
            00:01 <@nop> 2) Normal stuff, i.e. IIP update
-
            00:01 <@nop> ok
-
            00:02 <@nop> we're working on getting rc3 changed to 1.1 final
-
            00:02 <@nop> I think all that's left is some path fix bugs
-
            00:02 <@mids> hezekiah made the patch for -h, nop is reviewing it
-
            00:02 <@nop> yes
-
            00:02 <@nop> actually he can commit, I'll let him know, forgot to email him
-
            00:02 <@mids> ok
-
            00:02 <@nop> also
-
            00:02 <@mids> then we just got to check how the other reported bug is
-
            00:03 <@nop> Hezekiah has successfully compiled a version of IIP with the GNU Multi Precision library
-
            00:03 <@nop> and it was a success
-
            00:03 < MrEcho> cool
-
            00:03 <@nop> the crypto speed was improved
-
            00:03 <@nop> so that will be something we do for 1.2
-
            00:03 <@nop> 1.2 is focusing on standards as well, standardized crypto engine and big number routines
-
            00:03 <@nop> etc
-
            00:03 <@mids> there is our hero!
-
            00:04 -!- mode/#iip-dev [+o hezekiah] by mids
-
            00:04 <@hezekiah> Who?
-
            00:04 <@nop> you
-
            00:04 <@mids> you!
-
            00:04 <@hezekiah> Sorry I'm late. :)
-
            00:04 <@hezekiah> (And thanks for the compliment.)
-
            00:06 <@hezekiah> Did I miss the meeting? ... or is it still going?
-
            00:06 <@mids> nop was just telling about the update works
-
            00:06 <@mids> and that you can commit the -h patch
-
            00:06 <@hezekiah> OK.
-
            00:06 <@mids> then we got to see how severe the problems with the file paths are
-
            00:06 <@hezekiah> I just got through reading the logs.
-
            00:06 <@mids> test in multiple locations etc
-
            00:06 < MrEcho> anything new for windows users?
-
            00:06 <@mids> platofrms I mean
-
            00:08 <@hezekiah> Well, the -h bugfix might affect the windows users. I'm not sure if it was a problem over there.
-
            00:09 <@hezekiah> As for the GnuMP implementation of BigNum, that should be part of the 1.2 release for windows (though it might take some work to get it to run on windows.)
-
            00:09 < Debrys> may i ask what this BigNum-stuff is all about?
-
            00:10 < case> what version of libgmp was it dones with?
-
            00:10 < case> er 
-
            00:10 < case> dones/done
-
            00:10 <@hezekiah> Well, since mids and nop seem to have dissapeared for the moment, I'll explain it while we wait for them to get back.
-
            00:10 <@hezekiah> OK.
-
            00:10 <@mids> I am listening
-
            00:10 <@mids> please entertain
-
            00:10 <@hezekiah> First I'll answer case's question because it is simple. I used version 4.1 of GnuMP.
-
            00:10 <@hezekiah> (Gentoo doesn't have 4.1.2 yet.)
-
            00:11 <@hezekiah> Next is Debrys question:
-
            00:11 <@hezekiah> BigNum structure with a is a bunch of functions used in the isproxy source code.
-
            00:11 <@hezekiah> It is basically just a way to make integers that are REALLY REALLY big.
-
            00:11 <@hezekiah> Obviously modern CPU's don't offer really really big integer types, so C doesn't have them.
-
            00:12 <@hezekiah> ... and crypto needs to use really big numbers.
-
            00:12 <@hezekiah> Thus, an implementation of a "BigNum" is needed.
-
            00:12 < Debrys> i think i got it :) thank you
-
            00:12 <@hezekiah> Currently, we have 2 implentations of BigNum: one in SSL and one in GnuMP.
-
            00:12 <@hezekiah> You're welcome. :)
-
            00:12 <@hezekiah> Back to you, mids. :)
-
            00:12 <@mids> ok
-
            00:12  * hezekiah hands the microphone back.
-
            00:13 <@mids> I am done on point 2
-
            00:13 <@mids> lets go to the question round
-
            00:13 <@mids> questions?
-
            00:13 <@hezekiah> (oh, the irony.) ;-)
-
            00:13 <@hezekiah> Yeah. Are we almost to 1.1 release yet?
-
            00:14 <@hezekiah> What still needs to be done? (Besides get codeshark to make a tarball.)
-
            00:14 <@mids> testing if files are stored in the right directories
-
            00:14 <@mids> in every case
-
            00:15 <@mids> hezekiah: please tell  me if you did commit the -h thing, then I'll put the bug item closed
-
            00:15 <@nop> oh hezekiah you can commit
-
            00:15 <@nop> the -h thing
-
            00:15 <@nop> ;)
-
            00:15 <@hezekiah> I haven't commited the -h thing yet.
-
            00:15 <@hezekiah> I don't know what branch to commit to. :)
-
            00:15 <@nop> he does now ;)
-
            00:16 <@hezekiah> Give me a minute and I
-
            00:16 <@hezekiah> I'll update the bugfix.
-
            00:16 < Debrys> hmm, what will be new or changed in 1.1? not too much into detail - just in general
-
            00:16 <@hezekiah> 1. Bugfixes! :)
-
            00:17 <@mids> 2. more bugfixe
-
            00:17 < Debrys> lol
-
            00:17 <@nop> debrys no major changes
-
            00:17 < Debrys> anything which makes the connections more stable?
-
            00:17 <@nop> just bug fixes
-
            00:18 <@mids> Debrys: we will try that with a more minimum node.ref in the initial distribution
-
            00:18 < Debrys> i did a.......... rather unelegant hack to the node.ref..........
-
            00:19 < Debrys> only the invisiblenet relays.......... no update of node.ref
-
            00:19 < Debrys> i havent ping-timeout'ed for days........
-
            00:19 < Debrys> before of that i god disconnected in 30min intervals on average
-
            00:20 < Debrys> but its not a very good solution :)
-
            00:21 < Debrys> also.......... on the floppy-disk thing........
-
            00:21 < Debrys> i asked someone if he would do a hack for me on the boxedIRC-Source......
-
            00:22 < Debrys> if he accepts, this means i would have an 120kb IRC-Client which doesn't need any installation and saves all its settings in a ini-file on the disk
-
            00:23 <@mids> nice
-
            00:23 <@mids> keep us informed please
-
            00:23 < Debrys> if this works, there will not only be IIP and a IRC-Client on the disk, but also an email-client...... and i'm trying to get a PGP-App on it too........... maybe also a messenger client :)
-
            00:23 < Debrys> I'll do :)
-
            00:23 < lonelynerd> sound nice.
-
            00:23 < lonelynerd> [ sounds even. ]
-
            00:24 <@mids> ok
-
            00:24 <@mids> more things?
-
            00:24 < Debrys> nope
-
            00:25  * mids searches for his meeting-hammer
-
            00:25 <@hezekiah> Almost got the patch up, mids.
-
            00:25 <@mids> hurray
-
            00:25 <@mids> *baff*
-
            00:25 <@mids> meeting closed
-
            00:25 <@hezekiah> lol.
-
            00:25 < Debrys> :)
-
            00:26 < Bouris> Hooray!
-
            00:27 <+logger> cya next week
-
            --- Log closed Wed Jan 29 00:27:06 2003
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting29.html b/www.i2p2/pages/meeting29.html
deleted file mode 100644
index bd87eb2c..00000000
--- a/www.i2p2/pages/meeting29.html
+++ /dev/null
@@ -1,205 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 29{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 29
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Feb 04 23:38:39 2003
-
            23:38 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            23:38 [Users #iip-dev]
-
            23:38 [ co    ] [ mids  ] [ Neo] [ ptm  ] 
-
            23:38 [ logger] [ MrEcho] [ pox] [ UserX] 
-
            23:38 -!- Irssi: #iip-dev: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal]
-
            23:38 -!- Irssi: Join to #iip-dev was synced in 12 secs
-
            23:51 < mids> nop wont be on
-
            23:51 -!- mode/#iip-dev [+o mids] by Trent
-
            23:51 -!- mode/#iip-dev [+o UserX] by mids
-
            23:59 -!- mode/#iip-dev [+o hezekiah] by mids
-
            23:59 -!- mode/#iip-dev [+o hezekiah] by Trent
-
            23:59 <@hezekiah> Oops!
-
            23:59 <@hezekiah> I was just about to try that, mids! :)
-
            23:59 <@hezekiah> I think I figured it out!
-
            23:59 <@mids> you did
-
            23:59  * hezekiah feals very happy with himself for learning more about IRC. :)
-
            --- Day changed Wed Feb 05 2003
-
            00:00 < MrEcho> lol
-
            00:00 <@mids> Tue Feb  4 23:00:10 UTC 2003
-
            00:00 <@mids> Welcome to the 29th iip meeting
-
            00:00 <@mids> nop emailed me that he wont be there
-
            00:00 <@mids> so you got to do it without him
-
            00:00 <@mids> I dont have a specific agenda
-
            00:00 <@mids> except for this
-
            00:01 <@mids> 1) welcome :)
-
            00:01 <@mids> 2) highlights of the week
-
            00:01 <@mids> 3) questions
-
            00:01 <@mids> .
-
            00:01 <@mids> any highlights to report?
-
            00:02 <@hezekiah> Uh, not on my side. I'm still waiting for UserX or nop to look at the GnuMP BigNum impl. to see if it's OK.
-
            00:02 <@mids> userx added some code to the isproxy so that an empty node.ref file wont do harm if you upload
-
            00:02 <@hezekiah> The configure options for it got uploaded though.
-
            00:02 <@hezekiah> Is IIP 1.1 out yet?
-
            00:03 <@mids> havent seen it
-
            00:03 <@hezekiah> I guess not.
-
            00:03 <@mids> only thing is that we need to look at the location where the files are saved
-
            00:04 <@hezekiah> Hmmm ...
-
            00:04 <@mids> and if that gives bugs on different operating systems
-
            00:04 <@hezekiah> What exactly is the problem?
-
            00:05  * mids loads the sourceforge bugtracker
-
            00:05 <@mids> http://sourceforge.net/tracker/index.php?func=detail&aid=651711&group_id=50945&atid=461514
-
            00:05  * hezekiah is doing the same.
-
            00:05 <@hezekiah> Thanks. :)
-
            00:06 <@hezekiah> I remeber looking at that briefly once.
-
            00:07 <@hezekiah> The tricky part is what you are supposed to do in Windows.
-
            00:07 <@hezekiah> The *nix/*BSD part shouldn't be that difficult. (I hope.)
-
            00:07 <@mids> in windows it does just look at the current working directory
-
            00:08 <@hezekiah> I'll leave the Windows part to UserX. :)
-
            00:08 <@mids> the windows behavious shouldnt change imho
-
            00:09 <@hezekiah> Whatever. I run linux, and avoid Windows whenever I can. ;-)
-
            00:09 <@mids> same
-
            00:09 <@mids> but what behaviour do we want for unix?
-
            00:09 <@hezekiah> The behavior is defined in the code using #ifdef's based on platform.
-
            00:09 <@mids> you need to have access to the root/iip account to be able to access ~iip/.iip
-
            00:10 <@mids> so it should also look in other dirs
-
            00:10 <@mids> like ~/.iip
-
            00:10 <@mids> or the current dir
-
            00:10 <@hezekiah> Well, if isproxy is installed the default thing for a program to do would be look in /home/<user's homedir name>/.iip
-
            00:10 <@hezekiah> So in my case: /home/hezekiah/.iip
-
            00:10 <@hezekiah> node.ref would be /home/hezekiah/.iip/node.ref
-
            00:11 <@hezekiah> Then each user can have their own settings, etc.
-
            00:11 < MrEcho> you can kind of do the same thing in NT
-
            00:11 < MrEcho> my doc's folder is protected
-
            00:11 <@hezekiah> But under Win9[58] there really aren
-
            00:11 < MrEcho> ya
-
            00:11 <@hezekiah> aren't user specific home dirs.
-
            00:12 < MrEcho> anyone using 9x needs help anyways ....
-
            00:12  * hezekiah laughs
-
            00:12 <@hezekiah> Well, I'll email nop and ask him how he wants it done for *nix. Then, I'll see what I can do.
-
            00:12 <@mids> mail the list please
-
            00:13 <@mids> the we can all discuss
-
            00:13 < MrEcho> for the 9x ppl just put the files in ./.iip/
-
            00:13 <@hezekiah> OK.
-
            00:13 <@hezekiah> Or when IIP is installed it could be installed in Program Files/IIP.
-
            00:14 < MrEcho> for 9x ppl
-
            00:14 <@hezekiah> node.ref, isproxy.ini, seed.rnd, etc. could be placed there.
-
            00:14 <@mids> if you start IIP with a windows start thingie, then you can set the workingdirectory
-
            00:15 <@hezekiah> Well, anyway, I don't intend to touch the Windows implementation with a ten-foot poll. UserX can figure this one out. ;-)
-
            00:15 < MrEcho> :P
-
            00:15 <@mids> ok
-
            00:15 < FillaMent> You could look into a nasty WSH script. Then you can store in info in the registry
-
            00:15 <@hezekiah> (My compiler might not even _compile_ IIP under Windows!)
-
            00:15 <@mids> :)
-
            00:15 < MrEcho> fuck the registry
-
            00:15 <@hezekiah> FillaMent: if we used the registry in a program that needs to work under *nix, it would be an #ifdef NIGHTMARE!!
-
            00:16 < FillaMent> Not what I"m saying
-
            00:16 <@hezekiah> (But I will admit I tought of it to for a few seconds ... only a few, mind you.)
-
            00:16 <@hezekiah> Oh?
-
            00:16 <@hezekiah> Explain? :)
-
            00:17 < FillaMent> Have the location of the data file stored in the registry, then launch IIP with a WSH script that pulls the path out of the registry and pass it to the program as a cmnd line option
-
            00:17 < MrEcho> http://bofh.st/bofh/images/traffic.gif
-
            00:18 <@hezekiah> That might be doable.
-
            00:19 <@mids> I only had someone asking for windows NOT to change the current system there
-
            00:19 <@mids> maybe it would be nice to let it work without registry
-
            00:19 < FillaMent> A while back I wrote a script that would replace the name of the last logged in user with an arbitrary string. NT Ninja Vanish =) Had to do it because Generals and Colonels would freak because there was another login nam
-
            00:19 <@mids> from a security / anonymity pov
-
            00:20 <@hezekiah> I have to admit that I hate the Windoze registry with a pasion, just my personal opinion, though. :)
-
            00:20 < MrEcho> same here hezekiah
-
            00:20 < MrEcho> but ive learned to work with it
-
            00:20 <@hezekiah> So have I, ... but I still hate it. :)
-
            00:20 <@mids> so
-
            00:20 <@mids> lets investigate this week how the system currently works
-
            00:21 <@mids> and discuss on the list about how it should
-
            00:21 <@hezekiah> Right.
-
            00:21 <@mids> after that, make it work like it should :)
-
            00:21 <@hezekiah> I'll post an email to start up the conversation.
-
            00:21 <@mids> yay
-
            00:21 <@mids>  so
-
            00:21 <@mids> next item?
-
            00:22 <@hezekiah> 3.) questions
-
            00:22 < MrEcho> where the hell is 1.1  
-
            00:22 <@mids> *nod*
-
            00:22 < MrEcho> hehe
-
            00:22 <@hezekiah> I don't know.
-
            00:22 <@hezekiah> But I think the reason it's not out is because of the aforementioned bug.
-
            00:22 <@hezekiah> (The one we are going to talk about on the mailing list.)
-
            00:23 < MrEcho> i just hope it connects faster and more stable connections
-
            00:24 <@hezekiah> (I have to admit I haven't had a problem with unstable connections, and I usually connect to the 1st or 2nd node I try.)
-
            00:24 <@mids> but that is just because you have a clean node.ref, I assume?
-
            00:24 <@hezekiah> No.
-
            00:24 <@hezekiah> I have a normal node.ref
-
            00:24 <@mids> oh
-
            00:25 <@mids> but you never stay online for 24 h
-
            00:25 <@hezekiah> It's the one the server gives me each time I conect.
-
            00:25 < FillaMent> I can stay connected for a couple days, usually.
-
            00:25 <@hezekiah> No. I have a life. ;-)
-
            00:25 <@mids> one can stay online without irc-ing ofcourse
-
            00:25 <@mids> *geeh*
-
            00:25 <@hezekiah> And my family's phone line is the same on the internet connection is on. :)
-
            00:25 < jrandom> eww
-
            00:26 <@mids> then get offline now!
-
            00:26 <@mids> :)
-
            00:26 <@hezekiah> Other questions?
-
            00:26 <@mids> I dont have those
-
            00:28 < FillaMent> HaZaa...
-
            00:28 <@hezekiah> HaZaa?
-
            00:28 <@mids> gesundheit
-
            00:28 <@hezekiah> *lol*
-
            00:28 <@hezekiah> Was that a question, FillaMent?
-
            00:28 < FillaMent> My FServe
-
            00:29 <@hezekiah> OK. I'm lost. :)
-
            00:29 <@mids> tell us about it hezekiah 
-
            00:29 <@mids> s/hezekiah/FillaMent/
-
            00:30 < FillaMent> I was just wondering if there'd be any expected problems using IIP as a comm backbone for a lot of file browsing.
-
            00:30 < FillaMent> And eventually a text-based protocol like HTTP
-
            00:30 <@mids> you will be bound to the slowness of IIP
-
            00:30 <@mids> the 50B/s limit 
-
            00:31 <@hezekiah> IIP might not always be slow, mids. ;-)
-
            00:31 <@hezekiah> We shall optimize and improve. :)
-
            00:31 <@mids> hurray
-
            00:31 < FillaMent> That's not a big deal since we're not doing actual file transfer of IIP. Just comm. I'm concerned with whether or not it would be a strain.
-
            00:32 < lonelynerd> 50B/s might be ok for telnet
-
            00:32 <@hezekiah> (Mids? You want to answer all this? I'm reeaaallllyyy lost.)
-
            00:32 <@mids> ok
-
            00:32 <@mids> FillaMent is working on something caled HaZaa
-
            00:32 <@mids> it is some fserve on IIP
-
            00:33 <@mids> which uses Freenet for the actual file sharing
-
            00:33 <@mids> right?
-
            00:33 < FillaMent> Yeah... IIP for the browsing.
-
            00:33 <@mids> so you have some telnet/ftp like interface locally
-
            00:33 < FillaMent> firing it up now.
-
            00:34 < FillaMent> haz: /msg hazaaclone shell
-
            00:36 < FillaMent> haz: /msg hazaaclone cd /stuff/mp3s
-
            00:38 <@hezekiah> Not bad!!
-
            00:38 <@hezekiah> Uh ... how do you leave the shell?
-
            00:38 < FillaMent> It just times out.
-
            00:38 <@hezekiah> Oh ...
-
            00:39 < FillaMent> Think traffic like that would be a problem... I expect /lots/ of people will run them. Especially since DALnet just put a ban on FServes
-
            00:40 < HazaaClone> I might clog your chat network =) 
-
            00:40 <@hezekiah> Hmmm ...
-
            00:40 <@hezekiah> That would be a problem. :)
-
            00:41 < FillaMent> Dunno how much traffic it would be or what effect it will have on IIP.
-
            00:41 <@mids> during the slashdot attack we did do pretty well
-
            00:41 < FillaMent> Sounds solid then.
-
            00:41 <@mids> the total amount of people wasnt too high
-
            00:41 <@mids> but it was constant joining and parting
-
            00:42 < FillaMent> I /think/ I got the flooding issue fixed.
-
            00:43 <@hezekiah> Well, if you threw in an "exit/quit" command, maybe the connections would be lower. Just a suggestion. :)
-
            00:44 <@hezekiah> Well, I had better go. See you all around. :)
-
            00:44 < FillaMent> THe eventual version will use IIP to pass search queries and query results.
-
            00:45 <@hezekiah> mids: I'm looking into the code on the file placement bug. I should have an email up on the mailing list shortly. :)
-
            00:45 <@hezekiah> Bye, all! :)
-
            00:45 <@mids> bye
-
            00:46 < MrEcho> hey mids .. have you checked out iip-im latly
-
            00:46 <@mids> nope
-
            00:46 <@mids> but I didnt get many CVS updates
-
            00:46 < MrEcho> got a bunch of stuff done
-
            00:46 <@mids> lets end the official part of the meeting
-
            00:46 < MrEcho> im working on xml themes right  now
-
            00:46 <@mids> and move over to friendly chit chat
-
            00:46 < MrEcho> ...
-
            00:47 < FillaMent> ooooo! That just gave me an idea.
-
            00:48 < FillaMent> Oooo.... this is going to ROCK!
-
            00:48 <@mids> ?
-
            --- Log closed Wed Feb 05 00:48:36 2003
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting3.html b/www.i2p2/pages/meeting3.html
deleted file mode 100644
index 601b638e..00000000
--- a/www.i2p2/pages/meeting3.html
+++ /dev/null
@@ -1,618 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 3{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 3
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Wed Jun 05 00:38:00 2002
-
            00:38 <+logger> logging started
-
            00:38 <@codeshark> already?
-
            00:38 <+logger> yes, warming up
-
            00:49  * Annemiek is nu afwezig [Slapen/sleeping] [p-uit l-uit]
-
            00:49 -!- Annemiek is now known as keimennA
-
            00:59 <@nop> time
-
            00:59 <@nop> what time is it
-
            00:59 <@codeshark> 22:59 UTC
-
            01:00 < ellison> drumroll.....
-
            01:00 <@codeshark> 23:00 UTC
-
            01:00 < Zwollywood> 1:00
-
            01:00 <@mids> Tue Jun  4 23:00:50 UTC 2002
-
            01:01 <@mids> lets start
-
            01:01 <@nop> ok
-
            01:01 <@nop> Welcome all
-
            01:01 <@nop> to the 3rd meeting
-
            01:01 <@nop> of IIP
-
            01:02 <@nop> Today is probably a shorter meeting
-
            01:02 <@nop> but that's not exactly a bad thing
-
            01:02 <@nop> so anyway
-
            01:02 <@mids> on request of some europeans the meeting is held 1 hour earlier, nop is busy working, so he might be away
-
            01:02 <@nop> let's get started shall we
-
            01:02 <@mids> Previous meeting has logs on http://mids.student.utwente.nl/~mids/iip/meeting2/
-
            01:03 <@mids> if it will get crowded, this channel will be moderated, in that case direct your question to those with ops
-
            01:03 <@nop> ok
-
            01:03 <@nop> agenda
-
            01:03 <@mids> 1) Welcome
-
            01:03 <@mids> 2) Documentation status
-
            01:03 <@mids> 3) RC2 compatibility
-
            01:03 <@mids> 4) IPv6 support for IIP 1.2
-
            01:03 <@mids> A) Questions?
-
            01:03 <@mids> B) Next meeting
-
            01:03 <@nop> welcome
-
            01:03 <@nop> on to 2
-
            01:04 <@mids> Thanks to Banks a lot of holes in the docs are filled
-
            01:04 <@mids> he added screenshots for windows
-
            01:04 <@mids> and found nice quotes that are used in each chapter
-
            01:04 < Banks> np
-
            01:04 <@codeshark> yeah, doc looks cool
-
            01:04 <@mids> cohesion reviewed his work on chapter 1 and 2
-
            01:04 <@mids> it is in CVS now
-
            01:05 <@mids> demo: http://mids.student.utwente.nl/~mids/iip/htmldoc/en/index.html
-
            01:05 <@mids> nop still has to review everything, so it is in no way final
-
            01:05 <@mids> .
-
            01:05 <@mids> pardon the logo, that ASCII art is a placeholder :)
-
            01:05 <@mids> .
-
            01:06 <@mids> Sina: now everybody is looking at the nice docs: demo: http://mids.student.utwente.nl/~mids/iip/htmldoc/en/index.html
-
            01:07 < Neo> nice job banks. stuff looks great.
-
            01:07 < Banks> cheers :)
-
            01:07 <@nop> one comment
-
            01:08 <@nop> looks great
-
            01:08 <@nop> but
-
            01:08 <@nop> oh
-
            01:08 <@nop> never mind
-
            01:08 <@nop> ok
-
            01:08 < Banks> If we can get an advance release on RC2 we can package the latest docs with it
-
            01:08 <@mids> hehe
-
            01:08 <@nop> it's all good
-
            01:08 <@nop> we will, we'll get to rc2 next
-
            01:08 <@mids> any other comments on the docs?
-
            01:08 < Banks> You sure there isn't a but? :)
-
            01:08 < cohesion> anyone here have debian?
-
            01:09  * mids 
-
            01:09 <@mids> there is no /etc/boot.local
-
            01:09 <@mids> everything is script based
-
            01:09 < cohesion> sys V
-
            01:09 < cohesion> you mean?
-
            01:09 <@mids> so you need to create a startup script and put it in /etc/rcS.d/
-
            01:09 < cohesion> ya
-
            01:09 < cohesion> hum
-
            01:09 < cohesion> *shrugs*
-
            01:10 <@nop> oh guys
-
            01:10 <@nop> we need to include the random data for windows snapshot
-
            01:10 <@nop> might throw them off
-
            01:10 <@nop> but we generate a seed there as well
-
            01:10 <@mids> is that GUI based?
-
            01:10 <@nop> yes
-
            01:10 <@nop> mouse and keyboard strokes
-
            01:10 <@nop> both or either
-
            01:11 <@mids> so it is already in cvs?
-
            01:11 <@nop> yes sir
-
            01:11 <@mids> ok
-
            01:11 <@nop> but you have to do a clean install on that
-
            01:11 <@mids> Banks: can you snap that?
-
            01:11 <@nop> cohesion
-
            01:11 <@nop> chapter 4
-
            01:11 <@nop> installation on Unix systems
-
            01:11 <@nop> is that completed the isproxy -C
-
            01:12 < Banks> mids: I'll try
-
            01:12 <@nop> because it starts up at beginning if you are not upgrading
-
            01:12 <@mids> Banks: you require a windows compilation then, maybe ask codeshark 
-
            01:12 <@mids> AndreGoldman: we are at 2) Documentation status
-
            01:12 <@nop> I can compile it for you
-
            01:12 < Banks> nop: Cheers
-
            01:13 <@nop> and send it your ways
-
            01:13 <@mids> AndreGoldman: everybody is looking at the documentation demo: http://mids.student.utwente.nl/~mids/iip/htmldoc/en/
-
            01:13 < AndreGoldman> Thank, I'll jut follo along. 
-
            01:13 <@nop> I'll send it in a bit
-
            01:13 <@mids> more comments on docs?
-
            01:13 <@nop> cohesion
-
            01:13 <@nop> need to finish isproxy configuration for unix
-
            01:13 <@nop> on chapt 4
-
            01:14 <@nop> I'll look over it later for other stuff
-
            01:14 <@nop> but that's a biggy
-
            01:14 < cohesion> hum
-
            01:14 < Zwolly> just let me know where to find original and i will make an dutch translation
-
            01:14 <@nop> ahh yes
-
            01:14 <@nop> translations
-
            01:14 <@mids> Zwolly: will do once reviewed by nop
-
            01:14 <@nop> we need to include those 
-
            01:14 <@nop> in source
-
            01:14 <@nop> this will help people tremendously
-
            01:15 <@mids> any germans here?
-
            01:15 <@nop> Skyrat is
-
            01:15 <@nop> but he's not on right now
-
            01:15 <@mids> or other languages except for english, dutch and french
-
            01:15 <@nop> also
-
            01:15 < Phiberoptika> do you need spanish?
-
            01:15 <@nop> cohesion include the network diagram
-
            01:15 <@mids> UnDeRToW told me that he didn't have time for up to date spanish
-
            01:15 <@nop> I think we have spanish
-
            01:15 <@nop> oh
-
            01:15 <@nop> ok
-
            01:15 <@nop> then yes
-
            01:15 <@nop> spanish is good
-
            01:15 < cohesion> what diagram?
-
            01:15 <@nop> the one I sent a while back
-
            01:16 <@nop> ascii art of the network architecture
-
            01:16 < cohesion> ok
-
            01:16 < cohesion> i'll find it
-
            01:16 <@nop> k
-
            01:16 <@mids> Phiberoptika: cool, we'll find you when needed :)
-
            01:16 <@nop> because what's demonstrated is part of the communication protocol
-
            01:16 <@nop> not the netwrk arch
-
            01:16 <@nop> and we'll label that communication protocol as such
-
            01:16 < Phiberoptika> ok : )
-
            01:16 <@nop> and then include net arch
-
            01:16 <@nop> anyway
-
            01:17 <@nop> I've spoken my mind, the rest of that can be worried about offline
-
            01:17 <@mids> .
-
            01:17 <@nop> oh
-
            01:17 <@nop> and pertaining to rc2 with docs
-
            01:17 <@nop> I will rewrite the encryption when done, but we'll know why in next part
-
            01:18 <@mids> next item?
-
            01:18 <@nop> yes
-
            01:18 <@mids> 3) RC2 compatibility
-
            01:18 <@nop> ok
-
            01:18 <@nop> decided yesterday
-
            01:18 <@nop> we have some more work on rc2
-
            01:18 <@nop> so please 
-
            01:19 <@nop> use 1.1 rc1 until otherwise notified
-
            01:19 <@nop> because they won't work together
-
            01:19 <@mids> wasn't there a function freeze?
-
            01:19 <@nop> and the entire infrastructure has to be upgraded
-
            01:19 <@nop> but it must be when release of rc2 is out
-
            01:19 <@nop> or at least 1 week for pre-testing
-
            01:19 <@nop> reason:
-
            01:19 <@codeshark> nop: we need a parallel rc-2 network
-
            01:19 <@nop> we will have one cs
-
            01:19 <@codeshark> ok
-
            01:19 <@nop> but inform will look the same
-
            01:19 <@nop> and you'll have to restart inform
-
            01:20 <@nop> because we're not changing the communication to inform
-
            01:20 <@nop> so when we parallel
-
            01:20 <@nop> we'll slowly delete out as wel upgrade
-
            01:20 <@codeshark> you mean: flush the relays
-
            01:20 <@nop> we upgrade
-
            01:20 <@nop> yes
-
            01:20 <@nop> except for a couple
-
            01:20 <@nop> which we can discuss later
-
            01:20 <@codeshark> sure
-
            01:20 <@nop> ok
-
            01:20 <@mids> what is changed?
-
            01:20 <@nop> reason:
-
            01:20 <@nop> mandatory security upgrade
-
            01:21 <@nop> IIP 1.1 as is, is very secure under normal circumstances
-
            01:21 <@nop> hackers, etc
-
            01:21 <@nop> but
-
            01:21 <@nop> against a gov't attack, and ultimate paranoia
-
            01:21 <@nop> there can be a few certain types of physical attacks that can be used to obtain the secret server key through coersion
-
            01:21 <@nop> because of this risk
-
            01:21 <@nop> well
-
            01:22 <@nop> let me explain it in more detail
-
            01:22 <@nop> for instance
-
            01:22 <@nop> we're all enjoying ourselves on IIP
-
            01:22 <@nop> right?
-
            01:22 <@nop> right
-
            01:22 <@mids> k: we are now on 3) RC2 compatibility
-
            01:22 <@mids> right
-
            01:22 < Neo> I am.
-
            01:22 <@nop> someone does something stupid and happens to live in a corrupt gov't space
-
            01:22 <@mids> (if the network is up)
-
            01:22 <@nop> this gov't is now wiretapping and monitoring their internet connection
-
            01:22 < k> listening.
-
            01:23 <@nop> and starts putting up spy nodes around this user
-
            01:23 <@nop> then
-
            01:23 <@nop> they log this stuff for the amount of time they feel needed to get this guy
-
            01:23 <@nop> and suddenly they seek me out
-
            01:23 <@nop> and say we're raidnng the server
-
            01:23 <@nop> you have no choice but to give us the key
-
            01:23 <@nop> legally I'm obligated to do so
-
            01:23 <@nop> which is another issue of whether I do or not
-
            01:23 <@nop> say worst situation
-
            01:24 <@nop> they shoot me in the head
-
            01:24 <@nop> and take the key
-
            01:24 <@nop> ok
-
            01:24 <@nop> now with proper analysis
-
            01:24 <@nop> they will be able to decrypt the messages involved
-
            01:24  * Neo thinks we would all miss you.
-
            01:24 < AndreGoldman> it is called 'rubber hose cryptography'
-
            01:24 <@nop> well
-
            01:24 <@nop> still
-
            01:25 < Aroonkoa> Can the key be kept completely in memory?
-
            01:25 <@nop> this is involving IIP as a protocol and rubber hose doesn't work on 2.4 kernels
-
            01:25 <@nop> we have provided a solution
-
            01:25 <@nop> and are currently in the process of implementing it
-
            01:25 < Banks> can you tell us what it is?
-
            01:25 <@nop> this solution is to have a double encrypted protocol for end to end
-
            01:25 <@nop> of course, we're open source
-
            01:25 <@nop> ;)
-
            01:25 <@nop> what happens
-
            01:26 <@nop> user A connects through ---> to end node, connects to networkid, authenticates, and then will be doing a separate random key exchange that will disappear after communication is finished
-
            01:26 <@nop> this key will not be used again
-
            01:26 <@nop> and is after networkid authentication
-
            01:26 <@nop> plus enhanced with the Rolling Key Algorithm we use
-
            01:26 <@nop> and the way we Xor every 8 bytes of data
-
            01:27 <@codeshark> well, you could still do a mitm
-
            01:27 <@nop> no
-
            01:27 <@codeshark> why not?
-
            01:27 <@nop> because
-
            01:27 <@codeshark> if you have the network key
-
            01:27 <@nop> it's done after the networkid
-
            01:27 <@nop> this is a situation against the log and raid server attack
-
            01:27 <@nop> not a live attack
-
            01:27 <@codeshark> ok
-
            01:27 <@mids> will this cause more load on the serverside IIP relay?
-
            01:27 <@nop> most likely not after they are connected
-
            01:27 <@nop> you might note a spike on exchange
-
            01:27 <@nop> but that happens anyway
-
            01:27 <@nop> and a little more time connecting
-
            01:27 <@nop> also
-
            01:28 < Banks> the one-time key will be securely wiped after use?
-
            01:28 <@nop> networkid will be changed for safety reasons
-
            01:28 <@nop> and become 2048 bit
-
            01:28 <@nop> and made optionally in the software to support a 4096 bit networkid key
-
            01:28 <@mids> how well does it scale?
-
            01:28 <@nop> yes Banks it will
-
            01:28 <@mids> we had big trouble on the old server, when everybody connected at once
-
            01:28 < Neo> (log and raid server attack == log all cipher traffic, then raid for the key, then replay the traffic and decrypt the data)
-
            01:28 <@nop> correct
-
            01:28 <@mids> thanks nop 
-
            01:29 <@mids> s/nop/Neo/
-
            01:29 <@nop> the already used ciphers assist quite well for most attacks, the windows are small because of RKA and fake traffic forcing the rolling of keys
-
            01:29 <@nop> but if a user is being monitored
-
            01:29 <@nop> they are at risk until we decentralize completely
-
            01:29 <@nop> so for this reason
-
            01:30 <@nop> we are implementing rc2 as a mandatory security upgrade
-
            01:30 < Banks> cool
-
            01:30 <@nop> and will not be compatible with the previous version
-
            01:30 <@nop> and
-
            01:30 <@nop> one more comment on security
-
            01:30 <@nop> we need to make an ettiquette doc on how to think securely and anonymously
-
            01:30 <@nop> especially in public channels
-
            01:30 <@nop> as well
-
            01:30 <@mids> offtopic :)
-
            01:30 <@nop> as just putting iip links to lots of websites
-
            01:31 <@nop> it's part of the security of IIP
-
            01:31 <@nop> which I believe is rc2
-
            01:31 <@nop> ;)
-
            01:31 < Banks> heh
-
            01:31 <@nop> just linking IIP could lead to bad compromised software
-
            01:31 <@nop> even with md5's
-
            01:31 <@nop> we need to make sure that the servers that mirror it
-
            01:31 <@nop> are secure
-
            01:31 <@nop> etc
-
            01:31 <@nop> anyway
-
            01:32 <@nop> off topic
-
            01:32 <@nop> so we'll discuss that next meeting
-
            01:32 <@nop> anywa
-
            01:32 <@nop> scalability
-
            01:32 <@nop> IIP doesn't scale at all really because of it's centralized (temporary) design
-
            01:32 <@nop> but DH key exchange will not affect the scaling
-
            01:32 <@nop> we are planning for the future
-
            01:32 <@nop> and bigger prime numbers are essential as we go against faster and faster computers out there
-
            01:33 <@mids> well I remember terrible loads when everybody connects at once, right?
-
            01:33 <@nop> not anymore
-
            01:33 <@nop> this was fixed recently
-
            01:33 <@nop> on the back end
-
            01:33 <@nop> I get a spike of 32% now with that issue
-
            01:33 <@nop> not 99%
-
            01:33 <@mids> nice
-
            01:33 <@mids> why put this mandatory thing in RC2 (which was feature frozen imho) and not in 1.2 ?
-
            01:34 <@nop> because it will be waiting too long
-
            01:34 <@nop> no offense to the US gov't
-
            01:34 <@nop> but they have been issuing laws faster than we code
-
            01:34 <@nop> particularly to wiretapping
-
            01:34 <@nop> deniability is a key issue here
-
            01:34 < Banks> indeed
-
            01:34 <@mids> k
-
            01:34 <@nop> especially for the server
-
            01:34 <@mids> good point then
-
            01:35 <@mids> do we need version numbering in the node.ref? (like freenet has)
-
            01:35 <@nop> hence the need to fix some issues and advance in our need for privacy and security
-
            01:35 <@nop> it's an ongoing battle
-
            01:35 <@nop> but it's worth it
-
            01:35 <@nop> well
-
            01:35 <@nop> versioning might be an optional feature
-
            01:35 <@nop> sounds like it will turn out important soon
-
            01:36 <@nop> so it's in consideration
-
            01:36 <@nop> will let you know next week
-
            01:36 <@nop> ok
-
            01:36 <@nop> I'm done
-
            01:36 <@mids> k
-
            01:36 <@nop> .
-
            01:36 <@nop> any questions
-
            01:36 <@mids> .
-
            01:36 < Neo> Yeah.
-
            01:37 < Neo> The fake traffic option.
-
            01:37 < Neo> Wouldn't it be a good idea to have this turned on by default?
-
            01:37 <@nop> it is
-
            01:37 < Neo> good.
-
            01:37 < Neo> thanks.
-
            01:37 <@nop> it's been on since encryption came out to IIP
-
            01:37 <@mids> fake traffic, what is the length again?
-
            01:37 <@nop> it varies
-
            01:38 <@nop> it's max is 50 bytes
-
            01:38 <@mids> between fixed values isnt it?
-
            01:38 <@nop> about the size of simulated chat messages
-
            01:38 <@mids> cant you let it vary based on normal chat?
-
            01:38 <@nop> it is as close as we can get at this time
-
            01:38 <@nop> AI comes later
-
            01:38 <@nop> ;)
-
            01:38 <@mids> heh
-
            01:39 < Banks> what do you mean mids?
-
            01:39 <@nop> we plan to do that with iip 2
-
            01:39 <@nop> that will have more available techniques
-
            01:39 <@mids> Banks: well, maybe 50 maximum is too short
-
            01:39 <@mids> Banks: topic are much longer for example
-
            01:39 < Banks> I see. Is it random text?
-
            01:39 <@mids> Banks: and that might give away something
-
            01:39 <@nop> yes
-
            01:39 <@nop> I believe the values can be altered fairly easy
-
            01:39 <@nop> ;)
-
            01:40 < Banks> :)
-
            01:40 <@mids> k
-
            01:40 <@nop> any more questions
-
            01:40 <@mids> feature request for 1.2:
-
            01:40 <@nop> oh
-
            01:40 <@nop> feature requests need to be posted on sourceforge
-
            01:40 <@mids> keep record of average and SD of the lenght of lines
-
            01:40 <@mids> yes, I know
-
            01:41 <@nop> SD?
-
            01:41 <@mids> standard diviation
-
            01:41 <@nop> why?
-
            01:41 <@mids> to be able to fake messages within the used scale
-
            01:41 < Banks> mids: you mean per user or for all users?
-
            01:42 <@mids> Banks: all users is safest
-
            01:42 <@mids> hm, but harder
-
            01:42 <@nop> well
-
            01:42 <@mids> hm
-
            01:42 <@nop> a nice goal
-
            01:42 <@nop> would be this
-
            01:42 <@nop> iip node takes data traffic
-
            01:42 <@nop> analyzes it
-
            01:42 <@nop> and scrambles it
-
            01:42 <@nop> and uses it for it's seed of random spurting data
-
            01:43 <@nop> that would give a bit of form of ai
-
            01:43 <@mids> k
-
            01:43 < Banks> might be better to get the random data from somewhere else. I mean, that's the data we're trying to keep secret :)
-
            01:43 <@nop> what I mean
-
            01:43 <@nop> not direct data
-
            01:43 <@nop> but size of data info
-
            01:44 <@nop> and
-
            01:44 <@nop> spurt ratio of normal data
-
            01:44 <@nop> so that it mimics
-
            01:44 <@nop> actual data
-
            01:44 < Banks> I see
-
            01:44 <@nop> is randomized using yarrow
-
            01:44 < Banks> Do you guys get notified of bugs added at sourceforge?
-
            01:44 <@nop> I check daily
-
            01:45 <@mids> and subscribers are emailed
-
            01:45 < Banks> ok, just wanted to point out that node/relay settings bug if you hadn't seen it
-
            01:45 <@nop> which one
-
            01:45 < Banks> cool
-
            01:45 <@mids> the one that you didnt see :)
-
            01:45 < Banks> [ 563246 ] node/relay type settings cancellation
-
            01:46 <@nop> ahh
-
            01:46 <@nop> yes
-
            01:47 <@mids> Banks: thanks for pointing out
-
            01:47 <@mids> who does the windows code?
-
            01:47 <@nop> that's not really a bug
-
            01:47 < Banks> yeah, but it's not really a feature either :)
-
            01:47 <@nop> right
-
            01:47 <@nop> it warns you about your settings
-
            01:48 <@nop> but
-
            01:48 <@nop> we'll look into it
-
            01:48 <@nop> thnx
-
            01:48 < k> what's the time?
-
            01:48 < Banks> np
-
            01:48 <@mids> Tue Jun  4 23:48:37 UTC 2002
-
            01:48 <@mids> more item 2 questions?
-
            01:48 <@nop> next on agenda
-
            01:49 < k> what's that in central america?
-
            01:49 <@mids> 4) IPv6 Support for IIP 1.2
-
            01:49 <@mids> http://www.timeanddate.com/worldclock
-
            01:49 < k> thnx
-
            01:50 <@mids> IPv6 is something that is going to be used more wide spread
-
            01:50 <@mids> making IIP IPv6 compatible seems usefull
-
            01:51 <@mids> does anybody have experience with making daemons IPv6 compatible?
-
            01:51 <@nop> well
-
            01:51 <@nop> I think it's fairly simple to make it ipv6 compatible
-
            01:51 <@nop> it's really size and input, if your machine is compatible
-
            01:51 <@nop> then it will just do it correctly
-
            01:52 <@codeshark> node.ref parser?
-
            01:53 <@mids> how does it know if it should use the IPv6 or IPv4 address when doing a DNS query?
-
            01:54 <@codeshark> dns returns it
-
            01:54 <@codeshark> either an A record
-
            01:54 <@codeshark> or AAA
-
            01:54 <@mids> dns returs both
-
            01:54 <@mids> (if both exist)
-
            01:54 <@codeshark> hmm, if it has both
-
            01:54 <@mids> s/AAA/AAAA/
-
            01:54 <@UserX> ipv6 nodes would probably be indicated by adding a "transport" field to noderef with a value "tcp6" or similar
-
            01:54 <@codeshark> right :)
-
            01:55 < Aroonkoa>  Nodes could be both ipv4 and ipv6, correct?
-
            01:55 <@UserX> .
-
            01:55 <@UserX> yes
-
            01:56 <@mids> would be nice, that way you can make them gateways
-
            01:56 <@codeshark> if nodes can be on ipv6, i need to connect to the ipv6 network with the nodechecker
-
            01:56 <@codeshark> .
-
            01:56 <@nop> right
-
            01:57 <@nop> remember this is iip 1.2
-
            01:57 <@nop> so hopefully we'll be prepared for then
-
            01:57 <@nop> .
-
            01:57 <@mids> k
-
            01:58 < k> me?
-
            01:58 < k> j/k
-
            01:58 <@mids> more IPv6?
-
            01:58 <@nop> mids
-
            01:58 <@nop> it won't be too hard
-
            01:58 <@nop> I think that's it for ipv6
-
            01:59 <@mids> UserX's idea is great, that should solve all problems
-
            01:59 <@mids> .
-
            01:59 <@nop> yes
-
            01:59 <@nop> .
-
            01:59 <@nop> he always has great ideas
-
            01:59 <@nop> .
-
            01:59 <@mids> A) Questions
-
            01:59 <@mids> -------------
-
            01:59 <@mids> Ask a question
-
            01:59 <@nop> How does everyone like IIP so far
-
            01:59 <@nop> ?
-
            01:59 <@nop> ;)
-
            02:00 < Banks> It's elite
-
            02:00 < Zwolly> great and impressed
-
            02:00 <@mids> I like it pure
-
            02:00 <@nop> hehe
-
            02:00 < Neo> Schweeet.
-
            02:00 < Aroonkoa> Love it.
-
            02:00 <@nop> awesome
-
            02:00 < Zwolly> just looking fot this my whole internet irc life
-
            02:00 < Zwolly> for
-
            02:00 < Neo> We love it for what it is, and even more so for what it plans to be.
-
            02:01 <@nop> neato
-
            02:01 < Phiberoptika> bravo!: ))))
-
            02:01 < Banks> It's not just a pipe dream. It's here, now. With promise for the future.
-
            02:01  * Banks reaches for tissues.
-
            02:01 <@nop> umm
-
            02:01 <@nop> that was the idea
-
            02:02  * Banks offers the box around.
-
            02:02 <@nop> haha
-
            02:02 <@nop> oh
-
            02:02 <@nop> banks
-
            02:02 <@nop> great job on iip logo design
-
            02:02 <@nop> one comment
-
            02:02 <@mids> what logo?
-
            02:02 < Banks> shoot
-
            02:02 <@nop> use it for docs if we can
-
            02:02 <@nop> t-shirts
-
            02:02 <@nop> and bumper stickers
-
            02:02 <@nop> but website probably will be more light
-
            02:03 <@nop> it's very cynical ;)
-
            02:03 <@nop> and as a group
-
            02:03 <@nop> we like it
-
            02:03 <@mids> ah, banks did the logo, forgot
-
            02:03 < Zwolly> t-shirts...  there goes your anonimous life
-
            02:03 < Neo> bumper stickers... lol
-
            02:03 <@nop> just saying
-
            02:03 <@mids> did everybody see it? I will put it on my site
-
            02:03 < Banks> :)
-
            02:03 <@nop> defintely on the docs though
-
            02:03 <@nop> THat is the epitome of the docs
-
            02:03 <@nop> and the software
-
            02:04 <@mids> http://mids.student.utwente.nl/~mids/iip/meeting3/IIPlogo_bigger.png
-
            02:04 <@mids> somebody who isnt here at the moment had a comment on the logo
-
            02:05 <@mids> (s)he didn't quite like how the P worked out
-
            02:05 < Banks> We can change IIP to stand for Invisible Internet Project if you like, which represents your long-term goals as I understand it.
-
            02:05 <@mids> (but liked the whole concept)
-
            02:05 < Banks> if we can think of a way to improve the P, we should.
-
            02:06 <@mids> maybe a normal P?
-
            02:06 <@nop> maybe make both
-
            02:06 <@nop> irc and internet
-
            02:06 <@nop> internet is a ways off
-
            02:06 < k> just don't p on the floor, k?
-
            02:06 <@nop> we have a joker in here
-
            02:06 <@nop> hehe
-
            02:06 <@nop> ;)
-
            02:06 < Banks> :)
-
            02:06 <@mids> well, there is an idea
-
            02:07 <@mids> if you put the P a bit higher, it looks maybe better
-
            02:07 <@mids> though I like the concept!
-
            02:07 < Banks> mids: you can make those changes and send them around for comment if you want, or I can do it.
-
            02:07 <@mids> I am not a gfx guy
-
            02:08 < Banks> neither am I really :)
-
            02:08 <@mids> :)
-
            02:08 < Banks> I'll do a normal P and move it up and send it around
-
            02:08 < k> what's the time in costa rica??
-
            02:11 <@mids> okay, I have a little idea
-
            02:11 <@mids> everybody may promote his channel here now, with a oneliner
-
            02:11 <@mids> include channelname + description
-
            02:12 <@mids> #anonymous - general network channel, meet celibrities & crackheads
-
            02:12 < Zwolly> channel Annemiek just for the fun and in dutch (or english)
-
            02:12  * keimennA is afwezig [Slapen/sleeping] [1h22m52s]
-
            02:13 < k> glad I got to know that..
-
            02:13 < Banks> #scientology is a classic example of the kind of channels which IIP is ideally suited to
-
            02:13 < Banks> (it's not mine though :) )
-
            02:13 < k> lol
-
            02:14 < Neo>  #distributedcity - Sovereign Individuals
-
            02:14 <@mids> #test - for all your testing
-
            02:15 <@nop> #vegetarian for vegetarian (joke)
-
            02:15 < Banks> #hacktivismo isn't up today
-
            02:15 < Banks> Heh
-
            02:16 <@mids> okay, any questions? (IIP related)
-
            02:18 < Banks> Any way to improve fserve speed in the short-term? We could get a bigger user-base then.
-
            02:18 <@nop> umm
-
            02:18 <@nop> not without having flooding problems
-
            02:18 <@codeshark> filesharing in iip is not a very good idea
-
            02:19 <@codeshark> it's very inefficient
-
            02:19 <@nop> wait till decentralized
-
            02:19 <@codeshark> because of base64 encoding and additional irc headers
-
            02:19 <@codeshark> ...
-
            02:19 <@nop> then we'll make sure it's possible
-
            02:19 < Banks> I think it's a priority for a lot of people though. I was just wondering if there was any way to improve it somewhat before decentralization. Ok.
-
            02:20 <@nop> freenet gets it's act together
-
            02:20 <@nop> and you can write an irc plugin
-
            02:20 <@nop> :)
-
            02:20 <@codeshark> yeah, integration with freenet or somthing like it would be great
-
            02:20 <@mids> help freenet testing by running a watchme node
-
            02:20 <@codeshark> watchme node?
-
            02:20 <@mids> if they get that thing working again, freenet will be very usefull
-
            02:21 <@mids> http://freenetproject.org/cgi-bin/twiki/view/Main/SpyWare
-
            02:21 <@codeshark> statistics node?
-
            02:21 < Banks> true
-
            02:21 <@mids> it is a 'spyware' node, intended for debugging
-
            02:24 < k> woo
-
            02:25 <@mids> yes k? do you have a question?
-
            02:25 <@mids> (no sorry, dont know the costa rica timezone)
-
            02:26 < k> sorry - just celebrating out loud.
-
            02:27 <@mids> question: how does the 'new' time suit you?
-
            02:27 < k> huh?
-
            02:28 <@codeshark> it's a bit better, but we need to make the meetings shorter
-
            02:28 <@codeshark> .
-
            02:28 < Banks> I won't be able to make it to the next meeting. I have unavoidable business all day.
-
            02:28 <@nop> ok
-
            02:28 <@nop> it's all good
-
            02:28 <@mids> codeshark: any idea how to make it shorter?
-
            02:29 <@codeshark> make it more efficient
-
            02:29 <@codeshark> someone has to lead each topic
-
            02:30 <@codeshark> .
-
            02:30 <@mids> k
-
            02:30 <@mids> I am going to sleep
-
            02:30 <@mids> thanks all
-
            02:30 <@codeshark> me too
-
            02:31 <@mids> nop: can you moderate the channel again when the discussion is over?
-
            02:31 <@nop> sure
-
            02:31 <@mids> logger will be kept running for a while
-
            02:31 <@codeshark> nop: anything left for discussion>
-
            02:31 <@codeshark> ?
-
            02:32 <@nop> not really
-
            02:32 <@nop> no
-
            02:32 <@nop> everyone go home
-
            02:32 <@nop> haha
-
            02:32 < Zwolly> thanx dad
-
            02:32 <@nop> your welcome son
-
            02:32 < Zwolly> hehe
-
            02:33 -!- mode/#iip-dev [+m] by nop
-
            02:33 <@nop> everybody out
-
            02:33 <@nop> I need my time alone
-
            02:33 <@nop> leave me be
-
            02:33  * codeshark kicks out everyone
-
            02:34 -!- Phiberoptika was kicked from #iip-dev by nop [nop]
-
            02:34 -!- Neo was kicked from #iip-dev by nop [nop]
-
            02:34 -!- keimennA was kicked from #iip-dev by nop [nop]
-
            02:34 -!- keimennA was kicked from #iip-dev by nop [nop]
-
            02:34 -!- mode/#iip-dev [+i] by codeshark
-
            02:34 -!- keimennA was kicked from #iip-dev by nop [nop]
-
            02:34 -!- k was kicked from #iip-dev by nop [nop]
-
            02:34 -!- jakob[oFF] was kicked from #iip-dev by nop [nop]
-
            02:34 -!- AndreGoldman was kicked from #iip-dev by codeshark [codeshark]
-
            02:34 -!- Banks was kicked from #iip-dev by codeshark [codeshark]
-
            02:34 -!- ion was kicked from #iip-dev by nop [nop]
-
            02:35 -!- ellison was kicked from #iip-dev by nop [nop]
-
            02:35 -!- Aroonkoa was kicked from #iip-dev by codeshark [codeshark]
-
            02:35 -!- cohesion was kicked from #iip-dev by nop [nop]
-
            02:35 <@codeshark> hehe
-
            02:35 <+logger> abusive
-
            02:35 <+logger> logging ended
-
            --- Log closed Wed Jun 05 02:35:32 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting30.html b/www.i2p2/pages/meeting30.html
deleted file mode 100644
index 17c2ea6d..00000000
--- a/www.i2p2/pages/meeting30.html
+++ /dev/null
@@ -1,457 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 30{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 30
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Feb 11 23:36:59 2003
-
            23:37 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            23:37 [Users #iip-dev]
-
            23:37 [ ArdVark ] [ logger    ] [ mids] [ ptm      ] [ UserX] 
-
            23:37 [ jeremiah] [ lonelynerd] [ pox ] [ thecrypto] 
-
            23:37 -!- Irssi: #iip-dev: Total of 9 nicks [0 ops, 0 halfops, 0 voices, 9 normal]
-
            23:37 -!- Irssi: Join to #iip-dev was synced in 2 secs
-
            23:57 < nop> hi hezekiah 
-
            23:58 < hezekiah> Hi. :)
-
            23:58 -!- mode/#iip-dev [+o mids] by Trent
-
            23:58 -!- mode/#iip-dev [+o nop] by Trent
-
            23:58 <@mids> gimme an h. e. z. e. k. i. a. h
-
            23:58 <@mids> hezekiah!
-
            23:58 < hezekiah> lol
-
            23:58 < lonelynerd> :D
-
            23:58 < hezekiah> (Hmmm ....)
-
            23:59  * hezekiah gets an idea wondering if I can do something in IRC.
-
            23:59 <@nop> uh oh
-
            23:59 -!- mode/#iip-dev [+o hezekiah] by Trent
-
            23:59 -!- mode/#iip-dev [+o UserX] by hezekiah
-
            23:59 < _42> what?
-
            23:59 <@hezekiah> It works!
-
            23:59 <@mids> kick me out?
-
            23:59 <@hezekiah> Cool!
-
            23:59 <@hezekiah> No.
-
            23:59 -!- mode/#iip-dev [-o UserX] by mids
-
            23:59 <@hezekiah> See if I could op UserX
-
            23:59 <@nop> it worked yes
-
            23:59 <@hezekiah> Oops.
-
            23:59 <@mids> userx didnt identify
-
            23:59 < _42> op everyone :)
-
            23:59 <@hezekiah> Oh.
-
            23:59 <@hezekiah> Sorry.
-
            23:59 <@mids> he might be evil
-
            23:59 <@mids> :)
-
            23:59 <@hezekiah> My mistake. :(
-
            23:59 <@mids> *grin&
-
            23:59 <@hezekiah> I was just wondering if I could do it. (Good at C. Newborn at IRC.)
-
            --- Day changed Wed Feb 12 2003
-
            00:00 <@nop> anonymity and authentication take practice hezekiah 
-
            00:00 <@mids> Tue Feb 11 23:00:05 UTC 2003
-
            00:00 < _42> Yeah, but we all know that nop is sa fe.
-
            00:00 <@nop> you will learn grasshoper
-
            00:00 <@nop> ok
-
            00:00 <@nop> welcome
-
            00:00 <@mids> Welcome to the 30th meeting
-
            00:00 <@nop> _42 let's take this outside
-
            00:00 <@nop> ;)
-
            00:00 < thecrypto> yah!
-
            00:00 < thecrypto> 30!
-
            00:00 <@nop> sweet
-
            00:00 <@nop> ok
-
            00:01 <@nop> anyway
-
            00:01 <@nop> welcome, do we have anything specific on the agenda
-
            00:01 <@hezekiah> IIP 1.1 yet?
-
            00:01 <@mids> nope!
-
            00:01 < hobbs> 30 is the product of the first three primes. :)
-
            00:02 <@nop> hehe
-
            00:02 < thecrypto> yah!
-
            00:02 < thecrypto> primes!
-
            00:02 <@nop> simmer down everyone
-
            00:02 <@mids> showstoppers for IIP 1.1:
-
            00:02 <@mids> - file paths
-
            00:02 < _42> what about them?
-
            00:03 <@nop> 42 we have questions later
-
            00:03 <@nop> after all this
-
            00:03 <@nop> continue mids please
-
            00:03 <@mids> 42 asked what is one with the file paths I guess
-
            00:03 <@mids> I dont have other showstoppers
-
            00:04 <@nop> oh
-
            00:04 <@nop> well than do a .
-
            00:04 <@nop> so we know
-
            00:04 <@nop> sorry 42
-
            00:04 < _42> it's ok
-
            00:04 <@nop> ok umm, I believe UserX is working on the file path issue
-
            00:04 <@nop> I don't think he's at his keyboard at this moment
-
            00:04 <@mids> he didnt yet
-
            00:04 <@mids> I checked today
-
            00:04 <@nop> but I'll see if I can get that done stat
-
            00:05 <@hezekiah> I also proposed a solution.
-
            00:05 <@nop> oh ok
-
            00:05 <@hezekiah> I'm willing to code it if someone tells me what to do.
-
            00:05 <@mids> read http://sourceforge.net/tracker/index.php?func=detail&aid=651711&group_id=50945&atid=461514
-
            00:05 <@mids> and fix it :)
-
            00:05 <@nop> ok, mids I think you know the details of what we wanted done, but did we decide on the proper paths?
-
            00:05 <@hezekiah> If that
-
            00:06 <@hezekiah> mids: ... that's the bugtracker ID, then I've already read it. :)
-
            00:06 <@mids> yeah
-
            00:06 <@mids> first ~/.iip/
-
            00:06 <@mids> if not, current dir
-
            00:06 <@hezekiah> Were we going to make an "install-local"?
-
            00:07 <@mids> yes
-
            00:07 <@hezekiah> BTW, accourding to my testing, the code already does that.
-
            00:07 <@mids> I already made that I think...
-
            00:07 <@hezekiah> It just requires that ~/.iip exists.
-
            00:07 <@mids> hezekiah: it never ever puts iip.log in there
-
            00:07 <@hezekiah> Ah.
-
            00:07 <@hezekiah> That can be corrected. :)
-
            00:07 <@mids> and maybe also not mynode.ref
-
            00:07 <@hezekiah> Any other files that need to be there?
-
            00:07 <@hezekiah> (I think it does put node.ref there.)
-
            00:08 <@mids> userx' problem was that the logger code is very low level
-
            00:08 <@hezekiah> How's that affect the file paths?
-
            00:08 <@mids> and it doesnt have the extended features like '@' extends to path
-
            00:09 <@hezekiah> (I wish people would tell me they want these things.) I can probably write that up for him.
-
            00:09 <@hezekiah> In the development tree that is. I'm not sure what the logging code in head looks like.
-
            00:10 <@hezekiah> I should be able to write that up for him in head as well.
-
            00:10 <@hezekiah> I'll have to ask him exactly what he wants. :)
-
            00:11 <@mids> do that
-
            00:11 <@hezekiah> OK. :)
-
            00:11 <@hezekiah> So exactly what files _aren't_ getting placed in ~/.iip?
-
            00:12 <@hezekiah> You mentioned iip.log.
-
            00:12 <@mids> according to codeshark:  iip.log, isproxy.ini, mynode.ref, seed.rnd
-
            00:12 <@hezekiah> Hmmm.
-
            00:12 <@hezekiah> I can't remember which CVS tree I tested, but isproxy.ini, node.ref, and seed.rnd were are placed in ~/.iip.
-
            00:13 <@hezekiah> The key was that ~/.iip needs to exist _and_ isproxy.ini needs to be in ~/.iip or not exist.
-
            00:13 <@hezekiah> When those conditions are met, the 3 files I listed are placed in ~/.iip.
-
            00:13 <@mids> if not, current directory
-
            00:14 <@hezekiah> Right.
-
            00:14 <@hezekiah> isproxy.ini  listen.ref  node.ref  seed.rnd
-
            00:14 <@hezekiah> Those are the files that the development branch places in ~/.iip.
-
            00:14 <@mids> what about mynode.ref ?
-
            00:15 <@hezekiah> mids, I've never met a file called mynode.ref.
-
            00:15 <@hezekiah> What is it?
-
            00:15 <@mids> it is created if you make a public/private relay
-
            00:15 <@mids> contains the info that is also sent to inform
-
            00:15 <@nop> yes
-
            00:16 <@nop> it's designed for if you want to do neighbor noding
-
            00:16 <@hezekiah> It is only mentioned in active sourcecode at: iip/iip-ui.c:650
-
            00:16 <@nop> they specifically piggy back off you
-
            00:16 <@nop> so they can bootstrap
-
            00:16 <@nop> into the network
-
            00:18 <@mids> ok
-
            00:18 <@mids> keep in mind that the filepath can be changed
-
            00:18 <@mids> it has to work if the filepath is changed too
-
            00:18 <@hezekiah> (I'm looking into where mynode.ref gets placed.)
-
            00:18 <@mids> or if the location for the individual files are specified too
-
            00:18 <@hezekiah> mids: right now the filepath is hardcoded into the code.
-
            00:19 <@mids> -f lets you change the path
-
            00:19 <@hezekiah> If features are added in the future to do those things, then the code can be adapted to work with them.
-
            00:19 <@mids> see my manpage :)
-
            00:19 <@hezekiah> Hmmm ... odd.
-
            00:20 <@hezekiah> Oh, duh! Right, the part that's hardcoded is used as a default parameter.
-
            00:21 <@mids> thats fine
-
            00:21 <@hezekiah> Anyway, I'll talk to UserX and see what he has done/wants done. :)
-
            00:21 <@nop> coo
-
            00:21 <@mids> huya
-
            00:21 <@hezekiah> huya?
-
            00:21 <@mids> lets try to get this done BEFORE the next meeting
-
            00:22 <@hezekiah> If I can catch UserX before the next meeting (which I should), and I can get rid of this cold (which I should), and I don't make any more braindead mistakes (which I hope I won't), then hopefully, it will be.
-
            00:22 <@hezekiah> (Note I garuntee nothing: Coding is far to volatile [no pun intended] to do that.)
-
            00:23 <@mids> would be awesome
-
            00:23 <@mids> okay
-
            00:23 <@mids> other release issues?
-
            00:23 <@mids> did everybody look at the new manpage?
-
            00:23 <@mids> can the old one be removed?
-
            00:23 <@hezekiah> Yeah.
-
            00:23 <@hezekiah> Do you want it removed?
-
            00:24 <@mids> I'll do that right away
-
            00:24 <@mids> I wont put the .1 manpage in CVS
-
            00:24 <@mids> if we release, it has to be created
-
            00:25 <@mids> I'll send my Makefile with install-local to the mailinglist
-
            00:25 <@hezekiah> Should the makefiles create the manpage?
-
            00:25 <@mids> not right now
-
            00:26 <@mids> end-users dont need to have perl
-
            00:26 <@hezekiah> OK. Should they be installed by the Makefile?
-
            00:26 <@mids> (which ships perldoc)
-
            00:26 <@mids> future versions can have a make distribute or something
-
            00:27 <@hezekiah> I'm asking these questions because right now the automake Makefiles for the development tree install the isproxy.1 manpage.
-
            00:27 <@mids> making a directive that makes an isproxy.1 out of isproxy.pod should be simple
-
            00:28 < lonelynerd> [
-
            00:28 <@hezekiah> Right. But that makes the end user require perl. :)
-
            00:28 < lonelynerd> whoops
-
            00:28 <@mids> pod2man  -s 1 -c isproxy -r $VERSION ./$NAME/doc/isproxy.pod >./$NAME/doc/isproxy.1
-
            00:28 <@hezekiah> Remember, you said you don't want them to need perl.
-
            00:28 <@mids> then put that in the make distribute code
-
            00:28 <@mids> I am more talking about requirements for 1.1
-
            00:28 <@mids> 1.2 is different
-
            00:29 <@mids> k
-
            00:30 <@mids> TODO: mids mail install-local makefile
-
            00:30 <@mids> hezekiah contact userx
-
            00:30 <@hezekiah> Right.
-
            00:30 <@mids> nop: look at podfile
-
            00:30 <@mids> okay, for install-local
-
            00:30 <@mids> where should the binary and manpage be installed?
-
            00:30 <@mids> ~/bin and ~/man or something?
-
            00:31 <@mids> or not install manpage..
-
            00:31 <@hezekiah> What did UserX say in our email conversation?
-
            00:31 <@nop> ok
-
            00:31 <@hezekiah> Oops.
-
            00:32 <@hezekiah> nop?
-
            00:32 <@nop> yes
-
            00:32 <@nop> which email conversation
-
            00:32 <@hezekiah> You were saying something. :)
-
            00:32 <@nop> no
-
            00:33 <@nop> just saying I'd look at podfile
-
            00:33 <@hezekiah> Oh, mids, UserX, and I were going back and forth about what to do with the file path problem.
-
            00:33 <@hezekiah> Part of that involved making an install-local makefile target.
-
            00:33 <@hezekiah> I think I sent CC's of all my messages to you.
-
            00:33 <@mids> did get some
-
            00:33 <@hezekiah> Except for one that your email box wouldn't accept because it was full.
-
            00:33 <@hezekiah> (I anonymailed you the summary of that one.)
-
            00:34 <@hezekiah> I quote from UserX: "A possible solution to this is to add a "install-local" target to the Makefile. This would put the executable in ~/bin/ and other files in ~/.iip/."
-
            00:35 <@mids> mail sent
-
            00:37 <@hezekiah> So for now, install-local only copies node.ref and isproxy.
-
            00:37 <@hezekiah> I still see a small problem.
-
            00:37 <@hezekiah> When the user just runs "make install".
-
            00:38 <@hezekiah> ... then ~/.iip doesn't get created.
-
            00:38 <@hezekiah> Thus, isproxy will still leave its files in the current directory.
-
            00:38 <@mids> can you check userid with make?
-
            00:38 <@hezekiah> Huh?
-
            00:38 <@mids> so if you arent root, make install will give an error
-
            00:39 <@hezekiah> You can run a command like whoami.
-
            00:39 <@mids> would that be an option?
-
            00:39 <@hezekiah> id -u
-
            00:39 <@hezekiah> That should spit out the numeric ID of the user.
-
            00:40 <@mids> "Error: make install requires you to be root, use make install-local instead"
-
            00:40 <@hezekiah> Well, they should get that anyway if they are trying to copy files to /usr/local/bin
-
            00:41 <@hezekiah> It still doesn't fix the problem: isproxy will not place files in ~/.iip unless it exists, and "make install" doesn't create it.
-
            00:41 < nemesis> can i speak?
-
            00:41 <@hezekiah> (I don't see why not. Nop or mids can he speak?
-
            00:41 <@hezekiah> )
-
            00:41 < nemesis> ;)
-
            00:41 <@mids> please speak
-
            00:42 < nemesis> anyone know the linux distri SoL (server optimized linux) ? there are a root /server for all servers, unreal are added too
-
            00:42 <@mids> (hezekiah: make install makes /home/iip/.iip/ and installs there)
-
            00:42 < nemesis> it would be nice when iip goes someday in that distri
-
            00:43 < _42> What about configure --prefix=~ ?
-
            00:43 < nemesis> any suggestions?
-
            00:43 <@mids> _42: 1.1 doesnt have configure yet, 1.2 does
-
            00:43 < _42> oh.
-
            00:43 <@hezekiah> _42: the main branch of CVS doesn't have a configure script.
-
            00:43 <@mids> _42: good point though
-
            00:43 <@hezekiah> _42: but I already suggested that for 1.2. :)
-
            00:44 <@mids> nemesis: once 1.1 is out, we'll ask distributetions to make packages
-
            00:44 <@mids> which leads us to the following, we need an init.d script
-
            00:44 <@mids> we should really supply that
-
            00:44 < nemesis> SoL usese XML for that
-
            00:44 < nemesis> very nice configs...
-
            00:44 < _42> mids: they're distro-defined. I might be able to write a gentoo one.
-
            00:45 <@hezekiah> And Gentoo uses a different format than most.
-
            00:45 <@mids> iip.1.1.showstoppers.add(init.d-script)
-
            00:45 <@mids> maybe we can supply a general one?
-
            00:45 <@hezekiah> I wouldn't bet on it working.
-
            00:45 <@mids> ah
-
            00:45 <@mids> so, we dont have to?
-
            00:45 <@hezekiah> I'd save leave it to the distros, or make distro-specific ones.
-
            00:45 < _42> mids: gentoo uses a dependency system with its init.d scripts. It's simple, but incompatible.
-
            00:45 <@mids> k
-
            00:45 <@mids> then lets leave it
-
            00:46 <@mids> I still have some contact info of a debian packages
-
            00:46 <@hezekiah> _Especially_ when not all distros even USE init.d! (Gentoo uses a totally different format.)
-
            00:46 <@hezekiah> OK. :)
-
            00:46 <@mids> he offered to package iip in the past
-
            00:46 <@hezekiah> Cool! :) So where were we?
-
            00:46 <@mids> show stoppers
-
            00:46 <@mids> any more?
-
            00:46 <@hezekiah> Oh, yeah.
-
            00:46 <@hezekiah> I don't know of any
-
            00:46 < nemesis> when will 1.1 be released? ;)
-
            00:46 <@mids> nemesis: once all the show stoppers are tackled
-
            00:47 <@hezekiah> When we fix all the showstoppers! ;-)
-
            00:47 <@mids> what about the windows helpfile thing
-
            00:47 <@mids> how does that work atm?
-
            00:47 < nemesis> *g* k thx
-
            00:47 <@mids> what does it say
-
            00:47 < _42> mids: If I knew the proper start/stop commands I could write a gentoo runscript.
-
            00:47 <@hezekiah> I have no clue. I don't use Windoze unless I need to.
-
            00:47 <@mids> I believe that codeshark made a 'no help right now, see http://help.invisiblenet.net/' or something
-
            00:47 <@hezekiah> (If it comes to that, I could write one, _42. I use Gentoo.)
-
            00:47 <@mids> thx
-
            00:48 < _42> hezekiah: how about one of us does the ebuild, and the other the init.d? :)
-
            00:48 <@hezekiah> Fine. I don't really care. :)
-
            00:48 < _42> yes, but who does what?
-
            00:48 <@mids> ok
-
            00:48 <@mids> any windows user?
-
            00:48 <@hezekiah> You can do both if mids lets you. :)
-
            00:49 <@mids> it wont be bundled in the 1.1 release itself
-
            00:49  * hezekiah listens to the thunderous silence resounding through the room.
-
            00:49 <@mids> oh yeah
-
            00:49 <@hezekiah> What?
-
            00:49 <@mids> nop had to read through the docs
-
            00:49 <@mids> some crypto things changed
-
            00:50 < _42> what, the ebuild? of course not. That's distributed from Gentoo HQ. in a mysteriopus complex in (DELETED FOR DISTRO SECURITY REASONS) via rsync
-
            00:50 <@hezekiah> So what's the list of stuff we need to do until 1.1 look like now?
-
            00:50 <@hezekiah> _42: I know. But you can write one and submit it to the bugzilla list.
-
            00:50 <@mids> - filepath
-
            00:50 <@mids> - install-local
-
            00:50 <@mids> - readme, install, authors update
-
            00:51 <@mids> - windows documentation check
-
            00:51 <@mids> .
-
            00:51 <@hezekiah> - and nop needed to look at those docs you mentioned?
-
            00:51 <@nop> ok
-
            00:51 <@hezekiah> Or was that the windoze doc check?
-
            00:52 <@mids> well
-
            00:52 <@mids> the docs on http:L
-
            00:52 <@hezekiah> Ah! :)
-
            00:52 <@mids> http://help.invisiblenet.net/ can be changed also after release
-
            00:52 <@hezekiah> So my work is talking to UserX about the filepath stuff and seeing how I can help all this.
-
            00:52 <@mids> yes
-
            00:52 <@mids> and pushing us to do our stuff
-
            00:52 <@hezekiah> lol.
-
            00:53 <@hezekiah> I wouldn't do good at that. You're better at pushing. ;-)
-
            00:53 <@mids> I k
-
            00:53 <@mids> I'll request daily updates
-
            00:53 <@mids> at 8.00 am
-
            00:53 <@mids> :)
-
            00:53 <@hezekiah> Do I change the development automake Makefile templates to mimic your install-local, or does it need to be reviewed first?
-
            00:54 <@mids> it is a request for comments
-
            00:54 <@hezekiah> Ah.
-
            00:54 <@mids> lets first put it in 1.1, if everybody agrees
-
            00:54 <@mids> cvs dev can be done later
-
            00:54 <@hezekiah> I have a comment: let's make a PREFIX var.
-
            00:54 <@hezekiah> Right now /usr/local is hardcoded into several variables.
-
            00:55 <@mids> in Makefile?
-
            00:55 <@hezekiah> This is a pain for anyone that needs to install on a system that doesn't use /usr/local.
-
            00:55 <@hezekiah> Yeah.
-
            00:55 <@mids> ok
-
            00:55 <@hezekiah> i.e. INSTALLEXEPATH would look like this
-
            00:55 <@hezekiah> > PREFIX=/usr/local
-
            00:55 < _42> what's the syntax for checking out the 1.1 branch?
-
            00:55 < _42> from cvs
-
            00:55 <@mids> 1.1 is HEAD
-
            00:55 <@hezekiah> > INSTALLEXEPATH=$(INSTALLEXEPATH)/bin
-
            00:55 <@hezekiah> .
-
            00:55 < _42> ok
-
            00:56 <@hezekiah> 1.2 is development. :)
-
            00:56 <@hezekiah> ;-)
-
            00:56 < _42> oh, how zen
-
            00:56 < _42> You must be one with the development...
-
            00:56 <@hezekiah> Anyway, a PREFIX var would let someone go "make PREFIX=/usr install" instead of setting 3-4 other variables.
-
            00:57 <@hezekiah> _42: yeah. :)
-
            00:57 <@hezekiah> _42: but I do bugfix stuff for 1.1 too ... it's just that most my code goes in development.
-
            00:57 <@mids> how do you let make PREFIX= override the PREFIX in the Makefile?
-
            00:57 <@hezekiah> "make PREFIX=/usr install"
-
            00:57 < _42> 'k. But if dev is in CVS, wouldn't a co without a -r get it as well?
-
            00:57 <@mids> I mean, in the makefile itself
-
            00:58 <@hezekiah> It would override whatever PREFIX was set to in the makefile.
-
            00:58 <@mids> automagically?
-
            00:58 <@hezekiah> If PREFIX=/usr/local in the makefile "make PREFIX=/usr install" makes PREFIX=/usr instead.
-
            00:58 <@mids> great
-
            00:58 <@hezekiah> That's one way how Gentoo ebuild get around anoying makefiles. :)
-
            00:58 <@mids> ok
-
            00:59 <@mids> nother thing
-
            00:59 <@hezekiah> Cool.
-
            00:59 <@mids> in iip/doc/help/imaghes
-
            00:59 <@mids> iomages
-
            00:59 <@mids> images even :)
-
            00:59 <@mids> there are some bmp files
-
            00:59 <@mids> I believe that they can be removed
-
            00:59 <@mids> iip.pdf in doc/help too
-
            00:59 <@hezekiah> You sure the files in doc/help don't use them?
-
            00:59 <@mids> no idea
-
            00:59 <@mids> I am not a windows guy
-
            00:59 <@hezekiah> (Ouch.)
-
            01:00 <@mids> should ask codeshark
-
            01:00 <@mids> he made em
-
            01:00 <@hezekiah> Neither here, but I try to be careful.
-
            01:00 <@hezekiah> I'll leave the removing of files from the HEAD branch to you. :)
-
            01:00 <@hezekiah> (... and keep my neck safely on my shoulders.) ;-)
-
            01:00 <@mids> ok, I removed isproxy.1 from both branches
-
            01:00 <@hezekiah> Ah.
-
            01:00 <@mids> super todo: mail todo list to mailinglist
-
            01:00 <@mids> :)
-
            01:00 <@hezekiah> lol
-
            01:01 <@hezekiah> First we should update it.
-
            01:01 <@hezekiah> There are a bunch of things I've done that never got checked off.
-
            01:01 <@hezekiah> Also, the development branch makefiles depended on isproxy.1.
-
            01:01 <@mids> oh
-
            01:01 <@mids> I already removed isproxy.1 from dev
-
            01:02 < _42> The Makefile should support copying files to one dir but configuring the executable for another
-
            01:02 <@hezekiah> So what do I do _exactly_ with isproxy.pod?
-
            01:02 <@mids> here it comes:
-
            01:02 < hobbs> mmm. pod.
-
            01:02 <@hezekiah> Well, we can put it back if we need to, but I think there are better things to do. :)
-
            01:02 <@mids> hezekiah: pod2man  -s 1 -c isproxy -r $VERSION ./$NAME/doc/isproxy.pod >./$NAME/doc/isproxy.1
-
            01:02 <@hezekiah> _42: it does. The executable and makefiles go in different places. They were both targets for "make install" though.
-
            01:03 <@mids> I hope that the makefile knows the version somehow
-
            01:03 <@hezekiah> I can handle that.
-
            01:03 <@hezekiah> But this makes the user require perl.
-
            01:03 <@nop> sorry guys I'm in and out
-
            01:03 <@nop> at work so
-
            01:03 <@hezekiah> (We were over this before.)
-
            01:03 < _42> No, I mean copy the files to one directory specified by overriding a makefile var and configure them for another
-
            01:03 <@hezekiah> No problem. :)
-
            01:03 <@mids> you can replace "./$NAME/doc/isproxy.pod >./$NAME/doc/isproxy.1" with "$? > $@"
-
            01:03 < _42> k
-
            01:04 <@hezekiah> OK.
-
            01:04 <@hezekiah> But this still leaves the user of the development branch dependant on perl.
-
            01:04 <@hezekiah> Is that OK?
-
            01:04 <@mids> depend on pod2man
-
            01:04 <@hezekiah> OK.
-
            01:04 <@hezekiah> So I make the configure script look for it.
-
            01:04 <@mids> yes
-
            01:05 <@mids> _42: doesnt gentoo patch makefiles etc?
-
            01:05 <@mids> (like freenet does)
-
            01:05 <@hezekiah> nop: any objections to me having the configure script look for pod2man and having the makefile (in the development tree) build the manpage?
-
            01:05 <@hezekiah> mids: Gentoo uses patches, sed, or just sets makefile VAR's.
-
            01:06 <@hezekiah> mids: whichever least drastic measure is required. :)
-
            01:06  * mids guesses that nop doesnt object
-
            01:06 < _42> mids: it can, but it's easier to add a PREFIX=${D}/
-
            01:06 <@mids> _42: yop
-
            01:06 < _42> freenet patches akefiles?
-
            01:06 <@mids> freebsd
-
            01:06 < _42> ah
-
            01:07 <@mids> or maybe it doesnt
-
            01:07 <@mids> anyway
-
            01:08 <@mids> - filepath (A hezekiah, userx)
-
            01:08 <@mids> - Makefile install-local,PREFIX
-
            01:08 <@mids> - README, INSTALL, AUTHORS (mids)
-
            01:08 <@mids> - windows documentation (codeshark)
-
            01:08 <@mids> - docs (nop)
-
            01:08 <@mids> any additions?
-
            01:09 <@mids> otherwise I'll mail that
-
            01:09 <@hezekiah> Not that I can think of. :)
-
            01:10 <@mids> who will do the makefile?
-
            01:10 <@mids> me?
-
            01:10 <@hezekiah> You do the HEAD one.
-
            01:10 <@mids> I am talking about HEAD
-
            01:11 <@hezekiah> I usually take care of the makefiles/configure script in development. :)
-
            01:11 <@hezekiah> You do it. :)
-
            01:12 < lonelynerd> what about debian packages? ;)
-
            01:12 <@mids> lonelynerd: that can be done after the code is frozen / release is made
-
            01:12 < lonelynerd> sure
-
            01:13 <@mids> TODO mailed
-
            01:13 <@mids> ok
-
            01:13 <@mids> question round?
-
            01:14 <@mids> question round.
-
            01:14 < hezekiah> Sorry about that.
-
            01:14 < hezekiah> I got disconnected.
-
            01:14 <@mids> you did? :)
-
            01:14 < hezekiah> Yeah. :)
-
            01:16 <@mids> okay, meeting participants without questions are not allowed to ask any for a week if they could ask them now :)
-
            01:16 < hezekiah> lol.
-
            01:16 < hezekiah> mids: do people actually come up to you with questions during the week?
-
            01:17 <@mids> shiploads
-
            01:17 < hezekiah> Wow!
-
            01:17 < lonelynerd> ;)
-
            01:17 <@mids> mostly in #iip and #help
-
            01:17 < hezekiah> Oh. "Mommy, Mommy! What's an isproxy!?"
-
            01:17 < hezekiah> ;-)
-
            01:17 <@mids> RTFM
-
            01:18 < hezekiah> lol
-
            01:18 <@mids> ok
-
            01:18 <@mids> end?
-
            01:18  * hezekiah hands mids his gaffle to "baf"
-
            01:18 <@mids> baf it will be
-
            --- Log closed Wed Feb 12 01:19:02 2003
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting31.html b/www.i2p2/pages/meeting31.html
deleted file mode 100644
index 93e5aca8..00000000
--- a/www.i2p2/pages/meeting31.html
+++ /dev/null
@@ -1,446 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 31{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 31
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Feb 18 23:54:43 2003
-
            23:54 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            23:54 [Users #iip-dev]
-
            23:54 [ aum   ] [ bpb      ] [ jeremiah       ] [ logger] 
-
            23:54 [ Barney] [ codeshark] [ LeerokOnKnoppix] [ mids  ] 
-
            23:54 -!- Irssi: #iip-dev: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal]
-
            23:54 -!- Irssi: Join to #iip-dev was synced in 2 secs
-
            23:55  * bpb points at the logging bot then jumps up and down like a japanese animated school girl
-
            23:55 -!- mode/#iip-dev [+o mids] by Trent
-
            23:55 -!- mode/#iip-dev [+v logger] by mids
-
            23:57 -!- LeerokOnKnoppix is now known as Trent
-
            23:57 -!- Trent is now known as nickthief76011
-
            23:57 <@mids> :p
-
            23:57 -!- nickthief76011 is now known as LeerokOnKnoppix
-
            23:57 < lonelynerd> wwwhat?
-
            23:58 <@mids> Trent protects the nick
-
            23:58 < lonelynerd> oh, nothing
-
            23:58 < LeerokOnKnoppix> How does it do that?
-
            23:58 -!- LeerokOnKnoppix is now known as _Trent
-
            23:58 < _Trent> I am Trent, hear me roar!
-
            23:58 < hezekiah> LOL
-
            23:58 < _Trent> Get out, all unverified users!
-
            23:59 -!- mode/#iip-dev [+o hezekiah] by Trent
-
            23:59 < _Trent> What about me?
-
            23:59 <@mids> hey hezekiah :)
-
            23:59 -!- _Trent is now known as LeerokOnKnoppix
-
            23:59 <@hezekiah> Hi, mids. :)
-
            23:59 <@hezekiah> I think I'm getting the hang of some of this IRC thing! :)
-
            23:59 <@mids> kool
-
            --- Day changed Wed Feb 19 2003
-
            00:00 <@hezekiah> So have any bugs defied the great IIP dev team and risen their ugly heads since your last mail to the iip-dev mailinglist?
-
            00:01 < LeerokOnKnoppix> It disconnects every now and then.
-
            00:01 <@hezekiah> I don't seem to experiance that bug. :(
-
            00:01 < lonelynerd> LeerokOnKnoppix, it's probably your connection. i haven't had any problems
-
            00:01 < LeerokOnKnoppix> Hmm.
-
            00:01 <@hezekiah> mids: Where are nop and UserX?
-
            00:01 <@mids> Tue Feb 18 23:01:51 UTC 2003
-
            00:01 <@mids> user was here but he pinged out
-
            00:01 < LeerokOnKnoppix> _Trent kicked them out.
-
            00:02 <@mids> userx
-
            00:02 <@mids> just icq-ed nop
-
            00:02 < LeerokOnKnoppix> Is he coming?
-
            00:02 <@mids> dunno
-
            00:02 < bpb> lonelynerd: it's always happened though...  and it's not just him
-
            00:03 < lonelynerd> bpb, still, it's not a problem with iip but unreliable connections
-
            00:04 <@mids> nop is comming
-
            00:04 < nop> hi
-
            00:04 < lonelynerd> hi
-
            00:04 < nop> ok
-
            00:04 < nop> welcome
-
            00:04 < LeerokOnKnoppix> Hello nop.
-
            00:04 <@hezekiah> Hi, nop! :)
-
            00:04 < nop> Leerok likes Knoppix?
-
            00:04 < LeerokOnKnoppix> So far.
-
            00:04 < nop> kewl
-
            00:04 < nop> ok
-
            00:04 < bpb> lonelynerd: it's a problem with the actual network then
-
            00:04 < LeerokOnKnoppix> But I want to install it to the hard drive.
-
            00:04 < LeerokOnKnoppix> But it didn't work when I tried it.
-
            00:04 < nop> well, welcome to the 31st meeting
-
            00:04 < nop> of IIP-dev
-
            00:04 < LeerokOnKnoppix> Cool.
-
            00:04 < lonelynerd> bpb, well, it could handle unrealiable links, but it doesn't at the moment
-
            00:04 < LeerokOnKnoppix> I'm just hanging around to let knowledge osmose into my head.
-
            00:05 < nop> ok
-
            00:05 < nop> shh
-
            00:05 < nop> meeting started
-
            00:05 < nop> on the agenda
-
            00:05 -!- mode/#iip-dev [+o nop] by mids
-
            00:05 <@nop> IIP 1.1 and pleasantries with that
-
            00:05 <@nop> hezekiah: 
-
            00:06 <@hezekiah> Yeah?
-
            00:06 <@nop> hezekiah: all entropy stuff have we resolved? For instance the hhhhhh issue
-
            00:06 <@hezekiah> I just told you about the hhhhhhhh isue.
-
            00:06 <@hezekiah> We haven't done anything about it yet.
-
            00:06 <@nop> ok
-
            00:06 <@hezekiah> The seed.rnd issue is resolved by porting the --randomdialog option from development ..
-
            00:06 <@nop> ok
-
            00:07 <@nop> and can you explain what they do
-
            00:07 <@nop> just for the record
-
            00:07 <@hezekiah> ... and having IIP abort when seed.rnd doesn't exist.
-
            00:07 <@hezekiah> Explain what --randomdialog and --ignoreemptyrandom do?
-
            00:07 <@nop> yes
-
            00:07 <@hezekiah> OK. :)
-
            00:07 <@nop> for official purposes
-
            00:07 <@nop> aka the meeting
-
            00:07 <@hezekiah> Right. :)
-
            00:08 <@hezekiah> When isproxy is run with --randomdialog, the user is asked for entropy (even is seed.rnd already exists).
-
            00:09 <@hezekiah> When isproxy is run with --ignoreemptyrandom, and there isn't enough entropy (a condition that would cause isproxy to _normally_ abort), the program just keeps going. This is a security risk, so a suitablely scary warning label is added in the help description.
-
            00:09 <@hezekiah> (Speaking of all these options, unless mids as already added them, they aren't in the isproxy.pod file yet.)
-
            00:09 <@hezekiah> .
-
            00:09 <@mids> I didnt
-
            00:09 <@hezekiah> We should do that before release. :)
-
            00:10 < lonelynerd> (shouldn't it be --random-dialog and --ignore-empty-random ? ;P)
-
            00:10 <@hezekiah> lonelynerd: I code what UserX orders. :)
-
            00:10 < lonelynerd> ok
-
            00:10 <@hezekiah> nop: So, the seed.rnd problem is solved, but the hhhhhhhh problem isn't.
-
            00:10 <@nop> right
-
            00:11 <@nop> hmm, well, we could have a counter that won't allow the same keystroke more than three times in a row
-
            00:11 <@hezekiah> (I don't even know if hhhhhhhh is a problem. I just mentioned it to you and UserX. You tell me!) :)
-
            00:11 <@nop> real simple
-
            00:11 <@nop> it's a slight problem
-
            00:11 <@hezekiah> PGP some how knows how much entropy text is worth.
-
            00:11 <@nop> well, we calculate the keyboard timings as well
-
            00:12 <@nop> we could just force a wait till something beyond 3 same char in a row are pressed
-
            00:12 <@hezekiah> Does GPG evaluate the entropy of a string of text? If they do, we could look at their code. :)
-
            00:12 <@nop> I am not sure
-
            00:12 <@nop> I advise looking at it
-
            00:12 < lonelynerd> hezekiah, i think it just uses /dev/random, or?
-
            00:12 <@nop> lonelynerd no
-
            00:12 <@nop> it doesn't
-
            00:13 < lonelynerd> ah
-
            00:13 <@nop> we're talking about creation of entropy
-
            00:13 <@nop> aside /dev/random
-
            00:13 <@nop> like an Initialization
-
            00:13 <@hezekiah> GPG does make the user pound on the keyboard. :)
-
            00:13 <@mids> well no
-
            00:13 <@mids> it reads from the entropy pool
-
            00:13 <@mids> and suggests that you move the mouse + press keys
-
            00:14 <@mids> but entropy pool can be filled with interrupts etc too
-
            00:14 <@nop> yes
-
            00:14 < lonelynerd> yep
-
            00:14 <@hezekiah> Ah. I just remembered when GPG made me pound on the keyboard once. ;)
-
            00:14 < lonelynerd> it was pgp perhaps?
-
            00:14 <@hezekiah> Nope. It was GPG running under Mandrake Linux.
-
            00:14 < Barney> yep
-
            00:15 <@hezekiah> (It was a few years ago, before AES was released I remember.) Anyway, back on topic. :)
-
            00:15 <@nop> I think we should look at the code
-
            00:15 <@hezekiah> OK. :)
-
            00:15 < lonelynerd> :)
-
            00:15 <@nop> if it's not clear, I suggest limiting the characters in a row
-
            00:15 <@nop> and waiting
-
            00:15 <@nop> for new characters to be pressed
-
            00:15 <@hezekiah> Are there any methods outline (maybe in whitepapers from acedemia) on evalutating the entropy worth of a string of text?
-
            00:16 <@nop> yes there are, I will dig them up in a bit
-
            00:16 <@hezekiah> Cool! :)
-
            00:16 < lonelynerd> "ent - A pseudorandom number sequence test program"
-
            00:16 <@nop> yes, chi squaring 
-
            00:16 <@hezekiah> We could just implement one of those. (Believe it or not, it might be faster than digging through GPG code!) :)
-
            00:16 <@nop> http://www.gnu.org/software/gnu-crypto/api/gnu/crypto/tool/Ent.html
-
            00:17 <@nop> that's java
-
            00:17 <@nop> but still
-
            00:17 <@hezekiah> I can read Java. :)
-
            00:17 <@hezekiah> I can translate too. :)
-
            00:17 < lonelynerd> ent is in C, too
-
            00:17 <@nop> yep
-
            00:17 <@hezekiah> lonelynerd: Where can I find the C version?
-
            00:18 < lonelynerd> apt-get inst.. whoops, ;P http://www.fourmilab.ch/random
-
            00:18 < lonelynerd> Upstream Author(s): John Walker
-
            00:21 <@nop> ok
-
            00:21 <@nop> anyway
-
            00:21 <@nop> I'm sure that needs to be taken care of b4 1.1
-
            00:21 <@nop> this will give mids time to update isproxy.pod
-
            00:21 <@hezekiah> lol
-
            00:21 <@mids> pff
-
            00:22 <@mids> say nop, did you work on the docs? :)
-
            00:22 <@nop> ;)
-
            00:22 <@nop> I am working on them
-
            00:22 <@nop> and I have an editor too ;)
-
            00:22 <@mids> well
-
            00:22 <@mids> dont edit the html
-
            00:22 <@nop> I know
-
            00:22 <@nop> I'm just writing it in notepad
-
            00:22 <@nop> ;)
-
            00:22 <@mids> just send me the text changes, yeah thats fine
-
            00:22 <@hezekiah> Yay! Real HTML coder! Uses a plain text editor! ;-)
-
            00:23 <@nop> haha
-
            00:23 <@nop> I ain't coding it
-
            00:23 <@nop> just typing the doc
-
            00:23 <@nop> ;)
-
            00:23 <@mids> so
-
            00:24 <@mids> will any more features slip in for 1.1?
-
            00:24  * mids hopes not
-
            00:24 <@mids> I tried to contact codeshark
-
            00:24 <@nop> no
-
            00:24 <@mids> but didnt get a reply yet
-
            00:24 <@nop> it's not a feature
-
            00:24 <@nop> it's a bug fix
-
            00:24 <@nop> ;)
-
            00:25 <@nop> anyway
-
            00:25 <@nop> moving forward
-
            00:25 <@mids> ok, I got other things to do
-
            00:25 <@mids> if you need me shout loud
-
            00:25 < lonelynerd> (gpg seems to use get_entropy_count(fd) to check how many bytes /dev/random has to offer)
-
            00:26 <@nop> right
-
            00:26 <@nop> aka checking the entropy pool size
-
            00:26 < lonelynerd> which is some ioctl
-
            00:26 < lonelynerd> dunno how that would work under windows
-
            00:26 <@hezekiah> lonelynerd: It probably _doesn't_ work under windows. This a GNU project, remember? :)
-
            00:27 < lonelynerd> great :)
-
            00:27 <@hezekiah> What we really want (at least I think we do) is something that can evaluate how much entropy is in a buffer of text.
-
            00:27 < lonelynerd> but gpg supports also other means to get entropy
-
            00:27 <@nop> yes
-
            00:27 <@hezekiah> That way we can have the user keep pounding until we get that much _REAL_ entropy. :)
-
            00:27 < lonelynerd> hezekiah, ok
-
            00:27 <@nop> yes
-
            00:27 <@nop> we should have 1 bits per 3 characters
-
            00:28 <@nop> technically that's considered secure entropy
-
            00:28 < lonelynerd> ok, but under linux it could just read /dev/random
-
            00:28 < lonelynerd> let the windows users type ;)
-
            00:28 <@hezekiah> Well, isn't "randomentropyneeded" the number of bytes of entropy still needed?
-
            00:28 <@nop> yes
-
            00:29 < LeerokOnKnoppix> MD5sum of the registry.
-
            00:29 <@hezekiah> lonelynerd: UserX, nop, and I have talked about ways to get IIP to use /dev/urandom under controlled circumstances.
-
            00:29 < lonelynerd> hezekiah, hmm
-
            00:29 < lonelynerd> hezekiah, urandom is just like random, but it doesn't block when there isn't enough entropy?
-
            00:31 <@hezekiah> I think so. Is that right, nop?
-
            00:31 <@nop> yes, with urandom you can assign the amount of entropy in advanced
-
            00:31 < lonelynerd> so urandom might or might not be secure
-
            00:32 <@nop> urandom just uses random
-
            00:32 < lonelynerd> yep
-
            00:33 <@hezekiah> lonelynerd: That's the issue. :) We considering compiling a list of OS's (and their versions) with secure instances of /dev/urandom, and having IIP use it when it's secure; when it's not secure, IIP would stick with the current methods. It's a thought. :)
-
            00:33 <@nop> right, but not for 1.1
-
            00:33 <@nop> ;)
-
            00:33 <@hezekiah> Of course!
-
            00:33 < lonelynerd> hezekiah, wouldn't that be "secure versions of random" and not urandom?
-
            00:33 <@hezekiah> This is all 1.2 stuff I'm talking about. (I am usually always talking 1.2 unless otherwise stated!)
-
            00:33 < lonelynerd> ok
-
            00:33 < lonelynerd> sounds great
-
            00:34 <@nop> lonelynerd nothing wrong with urandom if random is considered secure
-
            00:34 < lonelynerd> well if you check that there is enough entropy
-
            00:36 <@hezekiah> So, nop? How exactly do we handle this hhhhhhhh problem?
-
            00:36 <@nop> well
-
            00:36 <@nop> for 1.1.0 I would limit the amount of repeated characters
-
            00:36 <@nop> in a row that is
-
            00:36 <@nop> and then leave it for in depth discussion in 1.2
-
            00:37 <@hezekiah> OK. But what happens when someone does pattern like "hHhHhHhHhHhHhH"?
-
            00:37 < lonelynerd> :)
-
            00:37 <@nop> we need to create a counter that spaces it out
-
            00:37 <@hezekiah> (Let's assume the user is an idiot. The software is only as secure as the user!) :)
-
            00:37 <@nop> so so many bytes can not contain this letter
-
            00:37 <@nop> since last used
-
            00:37 < jeremiah> hello
-
            00:37 <@nop> hi
-
            00:37 <@hezekiah> jeremiah: hi. :)
-
            00:37 < jeremiah> hey hezekiah
-
            00:38 <@nop> for instance [h][H][xonH[xonH[ etc
-
            00:38 <@hezekiah> So, 'h' can't be repeated more than _m_ times in _x_ bytes?
-
            00:38 <@nop> yes
-
            00:38 < jeremiah> are we talking about buffer overflows?
-
            00:38 <@nop> it will be considered rejected entropy
-
            00:38 <@hezekiah> jeremiah: Nope! We're talking about entropy! :)
-
            00:38 <@nop> but still log the keyboard timings
-
            00:38 <@nop> just ignore it as a string
-
            00:39 < jeremiah> random number generators are supposed to make sure there isn't a correlation with the numbers anyways
-
            00:39 < jeremiah> you can do that with chi-square
-
            00:39 < jeremiah> right?
-
            00:40 <@nop> well yarrow helps mix
-
            00:41 <@hezekiah> You said we "log the keyboard timings". What's that mean?
-
            00:42 < jeremiah> hezekiah: times between when you hit keys
-
            00:42 < lonelynerd> that's difficult if input is buffered
-
            00:42 <@nop> just do the character thing, it will be fine
-
            00:42 <@nop> yarrow does the rest
-
            00:42 <@hezekiah> nop: Are we getting the entropy from the keys being hit or the timing between when the keys get hit?
-
            00:42 <@nop> both
-
            00:42 <@hezekiah> Oh. OK. :)
-
            00:42 <@hezekiah> I'll just write up some code that prohibits 'char' repeating more than 'm' times in 'x' bytes. :)
-
            00:43 <@nop> yes
-
            00:43 <@nop> thnx
-
            00:43 <@hezekiah> Then for development, we brainstorm. ;-)
-
            00:43 <@nop> yes
-
            00:44 < LeerokOnKnoppix> How 'bout you get entropy from all possible inputs like the microphone, internet, processor speed, temperature, memory usage and speed, and other things?
-
            00:44 < lonelynerd> LeerokOnKnoppix, calm down :P
-
            00:44 <@hezekiah> I refuse to collect entropy from my internet connection; if someone can sniff it, then the quality of my entropy is lowwered.
-
            00:45 <@nop> haha
-
            00:45 < lonelynerd> yeah, and the kernel already does a nice job in gathering entropy. applications shouldn't do it
-
            00:46 <@hezekiah> lonelynerd: That works fine as long as IIP is run on an OS with good kernel random number support. There are OS's that exist that _don't_ have good support!
-
            00:46 < PsionX> like windows
-
            00:46 <@hezekiah> lol
-
            00:46 < lonelynerd> hezekiah, yep
-
            00:46 -!- PsionX is now known as WindowsHater
-
            00:46 < WindowsHater> lol
-
            00:46 < lonelynerd> hezekiah, just use some #ifdef there
-
            00:47 -!- WindowsHater is now known as PsionX
-
            00:47 <@nop> this was discussed earlier
-
            00:47 <@nop> and we will look at it on 1.2
-
            00:47 <@nop> moving on
-
            00:47 < lonelynerd> ok ok
-
            00:47 <@nop> we'll end up repeating ourselves
-
            00:47 <@nop> a dozen times
-
            00:47 <@nop> before this meeting is over
-
            00:47 <@hezekiah> Yeah. :)
-
            00:47 <@hezekiah> Next item! :)
-
            00:49 <@hezekiah> Uh, nop? Do we have a next item?
-
            00:49 <@hezekiah> Perhaps: "What's on the list until we can release IIP 1.1"
-
            00:50 <@hezekiah> Currently, I have:
-
            00:50 <@hezekiah> 1.) mids adds docs for --randomdialog and --ignoreemptyrandom to isproxy.pod
-
            00:50 <@hezekiah> 2.) nop finishes working on his HTML docs
-
            00:50 <@nop> yeah
-
            00:50 <@hezekiah> 3.) We correct the 'hhhhhhhh' entropy problem by prohibiting a certain number of repeated characters.
-
            00:51 <@hezekiah> Anything else?
-
            00:51 <@nop> right
-
            00:51 <@nop> nope
-
            00:51 <@nop> not that i know of
-
            00:51 <@hezekiah> Well, hopefully all that will be done by next week! :)
-
            00:51 <@hezekiah> (Or earlier!)
-
            00:51 <@nop> yes
-
            00:54 <@hezekiah> So what's next on the agenda?
-
            00:55 <@nop> umm
-
            00:55 <@nop> questions,
-
            00:55 <@hezekiah> lol!
-
            00:55 < LeerokOnKnoppix> Not much, it appears.
-
            00:55 < LeerokOnKnoppix> Will there be socks?
-
            00:55  * PsionX looks at his feet
-
            00:55 < LeerokOnKnoppix> No, I mean the proxy thing.
-
            00:55 <@nop> not in 1.1.0
-
            00:56 < LeerokOnKnoppix> Hmm.
-
            00:57 < LeerokOnKnoppix> Will there be IP spoofing?
-
            00:57 < lonelynerd> w-what?
-
            00:57 <@nop> umm, not in this lifetime
-
            00:57 < LeerokOnKnoppix> Never mind.
-
            00:57 < LeerokOnKnoppix> I'm just thinking up random questions.
-
            00:58 < lonelynerd> :)
-
            00:58 < LeerokOnKnoppix> Will there be any sort of file-transer?
-
            00:58 < LeerokOnKnoppix> *transfer
-
            00:58 <@nop> not in 1.1
-
            00:58 < LeerokOnKnoppix> Will there be buddy icons?
-
            00:58 <@hezekiah> LOL
-
            00:59 < PsionX> will someone please shut him up?
-
            00:59 < lonelynerd> LeerokOnKnoppix, you can already transfer files over iip but it's a bit slow
-
            00:59 < LeerokOnKnoppix> I know.
-
            01:01 < LeerokOnKnoppix> Will there be Reversi?
-
            01:01 < PsionX> this guy wants everything and a bag of chips too
-
            01:02 < LeerokOnKnoppix> Indeed.
-
            01:02 <@nop> the best question
-
            01:02 <@nop> will the human race be freed 
-
            01:02 <@nop> from oppression
-
            01:02 < LeerokOnKnoppix> With IIP? Certainly!
-
            01:02 <@hezekiah> lol!
-
            01:02 < PsionX> i got a question
-
            01:02 < PsionX> ... can i kick hezy in the butt for no good reson?
-
            01:02 <@nop> sure
-
            01:02 < PsionX> lol
-
            01:03 <@hezekiah> nop: So my work for now is to write up the repeating-character-entropy fix.
-
            01:03 <@nop> yes
-
            01:03 <@nop> oh and change the world in one sitting
-
            01:04 <@hezekiah> lol
-
            01:04  * aum pulls his face out of the other windows
-
            01:04 < LeerokOnKnoppix> Peace in Iraq.
-
            01:04 < aum> hi all
-
            01:04 < LeerokOnKnoppix> Hello.
-
            01:04 <@hezekiah> Oh, boy! I spent TOO LONG going over THAT one!
-
            01:04 <@nop> hi aum
-
            01:04 < PsionX> ...
-
            01:04 < PsionX> ... i got spikeys
-
            01:05 <@hezekiah> Question!
-
            01:05 < PsionX> Answer
-
            01:06 <@hezekiah> After IIP 1.1 is released, are we going to sit down and draw up a nice linear list of what needs to be done to decentralize the ircd server? (For example: does the "core" code need to be completed first?)
-
            01:09 <@nop> yes we will do that
-
            01:09 <@mids> s/1.1/1.1.0/
-
            01:09 <@hezekiah> lol. OK, mids. :)
-
            01:10 <@hezekiah> mids: Though it should probably be s/1\.1/1.1.0/ just for clarity's sake. ;-)
-
            01:10 <@mids> oops, sorry
-
            01:10 <@hezekiah> lol. :)
-
            01:11 <@hezekiah> Also:
-
            01:11 <@mids> maybe before decentralizing there should be another step
-
            01:11 <@hezekiah> I've seen that there is the capability to make varios crypto cores.
-
            01:11 <@mids> keeping a central irc, but letting the proxy be IRC aware
-
            01:11 <@mids> so it can already handle private conversations
-
            01:11 <@mids> etc
-
            01:14 <@hezekiah> mids: i.e. it interprets /msg and does direct user-to-user encryption?
-
            01:14 <@mids> yes
-
            01:14 <@hezekiah> Well, I don't know how abstract things have to say, but I think it's a good idea until we can get the server decentralized! :)
-
            01:16 <@hezekiah> About the crypto cores: if IIP has several crypto cores (SOCKS, SSL, and custom for example), then what happens when you have a connection between a user and several relays that has different encryption between each link?
-
            01:16 <@mids> you can do what GPG does
-
            01:16 <@mids> require a minimum
-
            01:16 <@mids> and if both parties have better, use that
-
            01:16 <@mids> also look hope SILC does it
-
            01:17 <@mids> bye hezekiah
-
            01:17 < PsionX> LOL dial up
-
            01:17 < PsionX> lol on hezy
-
            01:17 <@mids> ;)
-
            01:17 <@mids> wb
-
            01:17 < hezekiah> Let's say that SOCKS is weaker than SSL (I have no idea if it is.)
-
            01:18 < namless> what about own privat/publick keys that the user can add to (client or to IIP proxy) so he can crypt what he talks to chertain chanels or private querys? (meaning users who downt have the right key on these special chanels or private queries down  understant other users and IIP proxy filters this crypted text away)
-
            01:18 < hezekiah> (Sorry about being nocked off the internet folks; my brother probably tried to get on.)
-
            01:18 < namless> down -> dont (dam bad english and typos :(
-
            01:19 <@mids> namless: like the existing blowfish etc encryption for irc clients, but then server side
-
            01:19 <@mids> (psybnc has it too)
-
            01:19 < namless> jep
-
            01:20 < namless> the system vould be build into the IIP proxy so it could be transparent to the client...
-
            01:20 <@mids> another thing that I'd like to see is support for multiple layers on the same 'mixnet'
-
            01:20 < namless> vould-> could
-
            01:20 <@mids> so you can do multiple protocols with the same relays
-
            01:22 < hezekiah> (OK. This is getting annoying.)
-
            01:22 <@mids> probably it is bedtime for you :)
-
            01:23 < hezekiah> Nah. That's not for hours.
-
            01:23 <@mids> so no divine intervention?
-
            01:23 < hezekiah> lol
-
            01:23 < hezekiah> So, mids. From what the logs said (Thank God for logs), you mentioned that we could do as GPG does: require a minimum and use better if we have it.
-
            01:24 <@mids> yeah
-
            01:24 <@mids> probably different systems can be compatible too
-
            01:24 <@mids> like homebrew DH and SSL one
-
            01:24 <@mids> with SSL just beeing faster
-
            01:24 < hezekiah> But all the advantage of one connection type being securer than the other are lost when someone along the long uses something less secure.
-
            01:24 -!- LeerokOnKnoppix is now known as LeerokShovelSno
-
            01:26 < hezekiah> Oops. s/along the long/along the line/
-
            01:26 < hezekiah> Well, we can worry about that another day.
-
            01:26 <@mids> k
-
            01:26 <@mids> btw, any idea how to do something like <br> in POD format?
-
            01:26 < hezekiah> nop: Sometime we should also work on implementing RKA. :)
-
            01:27 < hezekiah> mids: You know more about POD than I do because I know nothing about POD! :)
-
            01:29 <@nop> well we have RKA working but not as good as we'd like
-
            01:29 <@nop> the GMP stuff will change that
-
            01:29 < hezekiah> mids: "E<escape>" -- a character escape
-
            01:29 < hezekiah> nop: We do? When did that happen?
-
            01:29 <@nop> it's been in
-
            01:30 <@nop> every 52 blocks it changes keys
-
            01:30 < hezekiah> Ah
-
            01:30 < hezekiah> Do you think we might make the key changing a little more random?
-
            01:30 < namless> "everyting should be random"...
-
            01:31 < hezekiah> Like having a random number checked every 10 blocks and a 1 out of 3 chance of the key changing?
-
            01:31 < hezekiah> ... or having an SHA sum of the last 3 plaintext messages checked and a 1 out of 3 chance of the key changing based on that?
-
            01:35 < lonelynerd> hmm
-
            01:35 <@mids> ok, info about --randomdialog and --ignoreemptyrandom added to POD
-
            01:35 < namless> by the way how "similar" is the traffic IIP is making? is there any plans to make this traffic to look as much random it can be?    if the "transfer macanism" makes a static mark in the traffic then it can be detected as IIP traffic and can be started to be monitored and well there only the sky is the limit...
-
            01:35 < hezekiah> And committed to HEAD and development?
-
            01:36 <@mids> oops
-
            01:36  * mids does to dev too
-
            01:37 < hezekiah> nop? Are you there?
-
            01:37 <@nop> sorry
-
            01:37 <@nop> what
-
            01:37 <@nop> dude, my brain is gone
-
            01:37 <@nop> can we discuss all this later
-
            01:37 < hezekiah> OK. :)
-
            01:37 < hezekiah> Sorry. :)
-
            01:38 <@mids> ok, lets close
-
            01:38 < hezekiah> (If it makes you feel any better, my brain is going to be gone too after a Physics review and some calcus!) :)
-
            01:38 <@mids> commited to development too
-
            01:38  * hezekiah hands mids the "baff"er
-
            01:38 < hezekiah> OK. Good! :0
-
            01:38 <@mids> *baff*
-
            01:38 < hezekiah> s/0$/)/
-
            01:38 < hezekiah> Bye all! :)
-
            01:38 <@mids> cya next week
-
            01:40 < lonelynerd> bye
-
            --- Log closed Wed Feb 19 01:40:48 2003
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting32.html b/www.i2p2/pages/meeting32.html
deleted file mode 100644
index b868b83c..00000000
--- a/www.i2p2/pages/meeting32.html
+++ /dev/null
@@ -1,307 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 32{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 32
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Mar 04 23:47:24 2003
-
            23:47 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            23:47 [Users #iip-dev]
-
            23:47 [ eep] [ jeremiah] [ logger] [ mids] [ nop] [ UserX_] 
-
            23:47 -!- Irssi: #iip-dev: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal]
-
            23:47 -!- Irssi: Join to #iip-dev was synced in 2 secs
-
            23:48 < LeerokLacerta> Making history.
-
            23:48 < mrflibble> helooo
-
            23:48 < LeerokLacerta> Hello.
-
            23:52 < nop> hi
-
            23:52 < jeremiah> hi
-
            23:53 < nop> hi
-
            23:53 -!- mode/#iip-dev [+o mids] by Trent
-
            23:53 < LeerokLacerta> Konnichiwa.
-
            23:54 < bpb> konnichiwa
-
            23:58 < nop> hi
-
            23:58 <@mids> Hi hezekiah!
-
            23:58 < hezekiah> Hi. :)
-
            23:58 <@mids> *hedgehog sound*
-
            23:58 < hezekiah> lol
-
            23:58 < hezekiah> *orgle*
-
            23:58 < LeerokLacerta> Hedgehog?
-
            23:58 < hezekiah> (orgle: That's one of the sounds a llama makes.)
-
            23:58 <@mids> LeerokLacerta: relatively large rodents with sharp erectile bristles mingled with the fur
-
            23:59 < hezekiah> Mids got turned into a hedgehog by the entropy bug.
-
            23:59 < hezekiah> I got turned into a llama.
-
            23:59 <@mids> no
-
            23:59 < LeerokLacerta> I know what it is, but why're you making hedgehog noises?
-
            23:59 <@mids> because I reported the logging bug that didnt exist
-
            23:59 < hezekiah> Ah.
-
            23:59 < hezekiah> Well, you had mentioned you were going to turn into a hedgehog when refering to the previous entropy bug.
-
            --- Day changed Wed Mar 05 2003
-
            00:00 <@mids> that was back then
-
            00:00 <@mids> Tue Mar  4 23:00:03 UTC 2003
-
            00:00 <@mids> meeting NOW in here
-
            00:00 <@mids> Welcome everybody
-
            00:00 <@mids> this is the 32th IIP meeting
-
            00:00  * LeerokLacerta feels welcomed.
-
            00:00 <@mids> previous one was canceled, because nobody was there
-
            00:00 <@mids> logs are available on http://mids.student.utwente.nl/~mids/iip/
-
            00:01 <@mids> We got a little agenda:
-
            00:01 <@mids> 1) Welcome
-
            00:01 <@mids> 2) IIP 1.1.0 Release status update
-
            00:01 <@mids> 3) Trent accesslevel for 'voice'
-
            00:01 <@mids> 4) Question round
-
            00:01 <@mids> if you have any questions on the current topic, please ask
-
            00:01 <@mids> otherwise save them for the question round.
-
            00:01 <@mids> .
-
            00:02  * mids moves the agenda pointer to #2 "IIP 1.1.0 Release status update"
-
            00:02 <@mids> well hezekiah, what happened? :)
-
            00:02 < hezekiah> Oh. OK. :)
-
            00:02 < hezekiah> Well, the first entropy bug got fixed.
-
            00:02 < hezekiah> After much banging of heads and exchanging of emails ...
-
            00:03 < hezekiah> ... UserX, nop, and myself managed to work out a fix for it.
-
            00:03 < hezekiah> Now, mids is noticing a NEW problem with the entropy gathering (namely seed.rnd isn't getting saved.)
-
            00:03 < hezekiah> Anyway, I've hunted in the code and posted my discoveries to the iip-dev mailing list.
-
            00:04 <@mids> this thing is another release delayer
-
            00:04 <@mids> hopefully the last one
-
            00:04 < hezekiah> I am now waiting on UserX or nop to tell me what all this means and if I'm missing something (because I think I am. None of it makes any sense.)
-
            00:04 < hezekiah> Hopefully. *orgle*
-
            00:04 <@mids> .
-
            00:04 < hezekiah> .
-
            00:04 <@mids> Any IIP 1.1.0 specific questions?
-
            00:05 < LeerokLacerta> No socks?
-
            00:05 <@mids> no socks
-
            00:05 < hezekiah> No SOCKS.
-
            00:05 < LeerokLacerta> K.
-
            00:05 <@mids> ok
-
            00:05 <@mids> lets move on to #3 "Trent accesslevel for 'voice'"
-
            00:06 <@mids> this is related with the hidden agenda point #2.9 "The #freenet-opn channel"
-
            00:06 <@mids> the official Freenet project channel is on irc.freenode.net
-
            00:06 <@mids> but that is not anonymous
-
            00:06 <@mids> we have a mirror with that channel here
-
            00:06 <@mids> in #freenet-opn
-
            00:07 <@mids> the bot 'eyeKon' tells you everything that happens on the other side
-
            00:07 <@mids> normally this is a one way mirror, but you can say something back with the "!say :text" command
-
            00:07 <@mids> to use this you got to have operator or voice status
-
            00:07 <@mids> if you want to say something, ask an operator to give you voice
-
            00:07 <@mids> ,
-
            00:08 < dm> How about if you are identified by Trent you get voice automatically and your name gets prefixed to your messages. If people on the other side have a problem they can send a command to the bot to "ban" a certain anonyname. In which case EyeKon on this side removes voice permanently from that name.
-
            00:08 < LeerokLacerta> Permanently?
-
            00:08 < LeerokLacerta> How 'bout timed ban?
-
            00:08 <@mids> it will get pretty complicated
-
            00:09 <@mids> they have to know how to bot works
-
            00:09 <@mids> while it is intended more as a one-way transparant thing
-
            00:09 -!- hezekiah is now known as nickthief88099
-
            00:09 <@mids> I have contacted the channelowners of #freenet
-
            00:09 <@mids> and they didnt have a problem with it
-
            00:09 < dm> sure, until mids or someone restores it. Must make sure not to spam/bother people on the other side.
-
            00:09 <@mids> that is why not everybody will get voice 
-
            00:09 <@mids> it is VERY easy to create lot of accounts here
-
            00:10 <@mids> so it will be impossible to ban them all
-
            00:10 < dm> ok, so selective voice, through trent?
-
            00:10 <@mids> what I DO want to do is selective voice through Trent
-
            00:10 < jake> this sure is an interesting conversation but I need to eat buh bye
-
            00:10 <@mids> which is agenda item #3
-
            00:10 <@mids> bye jake, thanks for joining
-
            00:10 <@mids> be sure to read the logfile afterwards
-
            00:10 < jake> thank you
-
            00:10 < jake> k
-
            00:10 <@mids> Right now the channel access system has 3 levels:
-
            00:11 <@mids> level 1: operator
-
            00:11  * mids checks the site how he called it
-
            00:12 <@mids> Level 1: Normal operator, can give him/herself ops 
-
            00:12 <@mids> Level 2: Super operator, can add other users to the channel (with lower level)
-
            00:12 <@mids> Level 3: Founder, most powerfull, required to drop a channel for example
-
            00:12 <@mids> I want to add a voice level
-
            00:12 <@mids> so people can get voice on the channel if they are on the access list
-
            00:12 <@mids> but the problem is... what number should the voice level be?
-
            00:12 < hezekiah> lol
-
            00:13 < hezekiah> Tell me you didn't use magic numbers, mids.
-
            00:13 < hezekiah> Please.
-
            00:13 <@mids> I am thinking about changing level 1 into 10
-
            00:13 <@mids> and 2 into 20 
-
            00:13 <@mids> and 3 into 30
-
            00:13 <@mids> and adding level 5 as voice
-
            00:13 < hezekiah> Sounds good. It leaves room for further improvements.
-
            00:13 <@mids> exactly
-
            00:14 <@mids> note that I dont plan to make Trent a big & bloaty service
-
            00:14 <@mids> comments? objections?
-
            00:14 <@mids> .
-
            00:14 < hezekiah> Umm .. so what's the problem?
-
            00:15 <@mids> there is no problem
-
            00:15 < dm> voice = voice on all channels?
-
            00:15 < hezekiah> OK.
-
            00:15 < hezekiah> It sorta looked like that. :)
-
            00:15 <@mids> dm: no, it is channel specific
-
            00:15 <@mids> hezekiah: I am always dramatic
-
            00:15 < dm> ok
-
            00:15 <@mids> dm: try this:
-
            00:15 <@mids>  /squery trent chanlist #iip-dev
-
            00:15 <@mids> you'll get a list of the users on the access list
-
            00:15 <@mids> with the level 
-
            00:15 < dm> ah, nice
-
            00:16 <@mids> ok
-
            00:17 <@mids> then it is now time for the last item #4: "Question Round"
-
            00:17 < dm> is there a roadmap documented anywhere, for IIP?
-
            00:18 <@mids> only internally I think
-
            00:18 <@mids> I dont have it...
-
            00:18 <@mids> hezekiah?
-
            00:18 < hezekiah> And why does "/squery Trent :chanlist #anonymous" return a blank list.
-
            00:18 < hezekiah> Oh.
-
            00:18 < hezekiah> Well we have a small todo list of stuff we need to do in the development tree.
-
            00:18 <@mids> hezekiah: too late (because nobody is on the access list for #anonymous, it is oper-less)
-
            00:18 < hezekiah> I'm not aware of any roadmap though.
-
            00:19 <@mids> maybe it would be good to make one
-
            00:19 < dm> ok, you're not even thinking about decentralizing any time soon, correct?
-
            00:19 < hezekiah> Well, that would be nop's department.
-
            00:19 < hezekiah> (Actually, I've already asked for something like that.)
-
            00:20 < hezekiah> (He said we were going to sit down and map out [or whatever he said] IIP 1.2 after 1.1 is released.)
-
            00:20 < hezekiah> .
-
            00:21 <@mids> well
-
            00:21 < dm> 1.1 is there a changelog somewhere?
-
            00:21 <@mids> nop is very busy
-
            00:21 <@mids> maybe someone else should do it
-
            00:21 <@mids> dm: yes, hang on
-
            00:21 < hezekiah> mids: No one else has the authority to do it.
-
            00:21 <@mids> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/invisibleip/iip/CHANGELOG
-
            00:21 < hezekiah> We are talking about setting the future course of development for IIP.
-
            00:21 < dm> thanks, bookmarked
-
            00:22 <@mids> hezekiah: understood
-
            00:25  * mids just heared that they got plenty of things to do for 1.2
-
            00:25 < hezekiah> As for nop not having time, ...
-
            00:25 < hezekiah> We still have plenty of known coding to do on 1.2.
-
            00:26 < hezekiah> 1.2 will not die for lack of vision. And even if we finish the stuff currently on the list, a short discussion will come up with more.
-
            00:26 < hezekiah> Eventually nop will have time to sit down with us and describe a plan for development of 1.2.
-
            00:26 < dm> any general notes on what 1.2 is striving for?
-
            00:26 < hezekiah> The big one: decentralize the ircd server!
-
            00:26 < dm> ah, ok, you don't know.
-
            00:27 < dm> ah, that's in 1.2? sweet.
-
            00:27 <@mids> is it already?
-
            00:27 <@mids> omg
-
            00:27 < hezekiah> Is the decentralization ready? No!
-
            00:27 < dm> planned for I mean :p
-
            00:27  * mids objects!
-
            00:27 <@mids> when do you want to release 1.2?
-
            00:27 <@mids> 2010?
-
            00:27  * LeerokLacerta is an object.
-
            00:27 < hezekiah> lol
-
            00:28 < hezekiah> Let's just say sometime after 1.1 is released. :)
-
            00:28 < hezekiah> Right now 1.1 is the priority.
-
            00:28 < hezekiah> (At least that's the feeling I've gotten.)
-
            00:28 < dm> so you is it going to be distributed ircd servers or completely decentralized?
-
            00:28 < hezekiah> dm: I don't know the details.
-
            00:28 < dm> ok
-
            00:28 < hezekiah> I'm not really very good at P2P stuff. :)
-
            00:28 < hezekiah> I just code
-
            00:28 <@mids> let me paste an email from 2002-03-19
-
            00:28 <@mids> From: 0x90 (0x90@invisiblenet.net)
-
            00:28 <@mids> Date: Tue Mar 19 2002 - 00:22:26 CET
-
            00:28 <@mids> Subject: [iip-dev] 1.1.0 almost complete
-
            00:28 <@mids> Ok, we're nearing the completion of 1.1.0. As soon as the TODO/Fixes and cui
-
            00:28 <@mids> for linux are complete, we should run a beta test of the network for this
-
            00:28 <@mids> week, this is done by the developers/testers. Stay posted.
-
            00:29 <@mids> --0x90-- 
-
            00:29 <@mids> .
-
            00:29 < hezekiah> Ouch.
-
            00:29 < hezekiah> That hurt, mids. ;-)
-
            00:29 <@mids> yes it did
-
            00:29 < hezekiah> What date was the last release of IIP made?
-
            00:30 <@mids> RC3 was 2002-12-04
-
            00:30 <@mids> but ofcourse the whole 'RC' stuff was wrong
-
            00:31 <@mids> ofcourse it is just a name
-
            00:31 <@mids> RC2 could have been 1.1.0
-
            00:31 <@mids> then RC3 1.1.1
-
            00:31 <@mids> and what we will have now 1.1.2
-
            00:32 < nop> well
-
            00:32 < nop> in the crypto community
-
            00:32 < nop> we should continue with RC4, 5 and 6, and see if they crack it
-
            00:32 < nop> ;)
-
            00:32 < nop> bad joke
-
            00:33 < Nostradumbass> Excuse me for butting in...
-
            00:33 < jake> butts!
-
            00:33 < Nostradumbass> but it seems that iip developers have forgotten the prime mazimum of open source, "Release early, release often".
-
            00:34 < LeerokLacerta> IIP is open source?
-
            00:34 < nop> sure
-
            00:34 < nop> right
-
            00:34 < nop> but
-
            00:34 < hezekiah> LeerokLacerta: yes
-
            00:34 < LeerokLacerta> I'm dumb.
-
            00:34 < nop> we also value security
-
            00:34 < Nostradumbass> i haven't been around on iip too long but i can't recall ever hearing about it being /.'d
-
            00:35 < nop> and we like to bend the rules
-
            00:35 < nop> it's been slashdotted
-
            00:35 < Nostradumbass> apologies
-
            00:35 <@mids> RC2 was /.-ed
-
            00:35 < Nostradumbass> k
-
            00:35 <@mids> and it gave us... hezekiah !
-
            00:35 < nop> yes
-
            00:35 < nop> ;)
-
            00:35 < Nostradumbass> still that's quite a while back.
-
            00:35 < hezekiah> mids: actually no.
-
            00:36 < hezekiah> mids: I was watching this project for more than a year before the /.ing.
-
            00:36 < jake> um guys? about the web based IIP are there any plans for improvement? like a nicer interface?
-
            00:36 < nop> that's a distributedcity question
-
            00:36 < nop> they make the interface
-
            00:36 < jake> oooo k
-
            00:37 < nop> it was something that they did, not really direct involvement with us
-
            00:37 <@mids> doing releases gives publication
-
            00:37 <@mids> you can do announcements, press releases
-
            00:37 <@mids> we have multiple places that really like to hear about updates
-
            00:38 <@mids> it increases the interest and amount of users in the project
-
            00:38 <@mids> and also potential contributors / developers
-
            00:38 <@mids> IF you have some super-duper mixnet
-
            00:38 <@mids> you do need lots of users
-
            00:38 <@mids> because with 2 users it isnt anonymous
-
            00:39 <@mids> there have been more stable periods in the development code
-
            00:39 <@mids> at which point we could have made a release
-
            00:39 <@mids> IMHO
-
            00:39 <@mids> problem is maybe the dependencies...
-
            00:40 <@mids> PGP signing the release, compiling for windows, etc
-
            00:40 <@mids> anyway, I have said it before ;)
-
            00:42 < hezekiah> Well, between my being sporadically bumped from the network, I've tried to say something that didn't get said. ;-)
-
            00:42 < hezekiah> <hezekiah> nop: mids has raised some good points.
-
            00:42 < hezekiah> <hezekiah> nop: After we get 1.1 out the door (which should be _really_ soon), are we going to come up with a nice coherent plan for 1.2 so that we can get it out in a reasonable amount of time?
-
            00:42 < hezekiah> <hezekiah> I think with good planning, and goals to get certain parts done by certain times, we could still write great code, but get it done in a reasonable timeframe. :)
-
            00:42 < hezekiah> There! :)
-
            00:42 <@mids> thanks
-
            00:43 < Nostradumbass> in addition to the proposed feature list, perhaps a list of prohibited features (to limit feature creep) might be a good idea.
-
            00:43 < dm> 1.2! 1.2! 1.2! 1.2!
-
            00:44 <@mids> good suggestion Nostradumbass 
-
            00:44 < hezekiah> Well, I wasn't really refering to a feature list. I was refering to what we are going to code, in what order, and by what suggested time.
-
            00:45 < hezekiah> nop? What do you think?
-
            00:46 < nop> good idea
-
            00:46 < nop> organization is always good
-
            00:46 < nop> but not always perfect
-
            00:46 < hezekiah> Perhaps after we release 1.1, all the developers could sit down and we could make up a list of stuff we plan on doing in the next 1-2 months, then a list of stuff planned for the next 5 months, then with a full list of what will make IIP 1.2 to be version 1.2. :)
-
            00:46 < hezekiah> I know. It will be _very_ flexable.
-
            00:47 < hezekiah> (For starters I wouldn't say feature A is one at date 1 and feature B is done at date 2. I'd say feature A is hopefully done in X weeks, and feature B is hopefully done Y weeks after feature A.)
-
            00:47 < hezekiah> I think that something as a general guide to what we're doing is a good idea.
-
            00:48 < hezekiah> Not a stiff-as-iron list. :)
-
            00:48 <@mids> yeah, get it
-
            00:48 < hezekiah> OK ...
-
            00:48 < hezekiah> Anything to add mids?
-
            00:49 <@mids> nope
-
            00:49 < hezekiah> OK. ;)
-
            00:49 < hezekiah> So for now ...
-
            00:49 < hezekiah> I am waiting for nop or UserX to enlighten me concerning the stuff I dug up on mids' new entropy bug.
-
            00:49 <@mids> I hope that I wont find other issues
-
            00:49 < hezekiah> (It just doesn't seem like randomWriteSeed() is never called.)
-
            00:49 < hezekiah> Let's hope. :)
-
            00:50 < nop> double negative
-
            00:50 < nop> hmm
-
            00:50 < nop> ;)
-
            00:50 <@mids> .
-
            00:50 <@mids> I am done :)
-
            00:50 < hezekiah> You're right! :)
-
            00:50 < hezekiah> It seems like randomWriteSeed() should be called.
-
            00:50 < hezekiah> But it doesn't look like it is.
-
            00:51 <@mids> not in randomSlowPoolReseed?
-
            00:52 < hezekiah> Well, lets hope we have this bug fixed by next week.
-
            00:52 <@mids> you better do that!
-
            00:52  * mids tries to put up an angry face
-
            00:53 <@mids> ok, been a pleasure again. till next meeting, mailinglist, chat or otherwise!
-
            00:53 <@mids> *boink*
-
            00:53 < hezekiah> randomSlowPoolReseed() calls randomWriteSeed(), but (as I said in my email to iip-dev), randomSlowPoolReseed() is never called by anyone!
-
            00:53 < hezekiah> lol
-
            -- Log closed Wed Mar 05 23:42:43 2003
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting33.html b/www.i2p2/pages/meeting33.html
deleted file mode 100644
index 53a0b6a5..00000000
--- a/www.i2p2/pages/meeting33.html
+++ /dev/null
@@ -1,426 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 33{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 33
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Wed Mar 12 00:01:53 2003
-
            00:01 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            00:01 [Users #iip-dev]
-
            00:01 [@mids    ] [ jeremiah] [ mihi] [ pox  ] 
-
            00:01 [ hezekiah] [ logger  ] [ nop ] [ UserX] 
-
            00:01 -!- Irssi: #iip-dev: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal]
-
            00:02 -!- Irssi: Join to #iip-dev was synced in 7 secs
-
            00:02 <@mids> Welcome to the 33th meeting
-
            00:02 < hezekiah> Hi
-
            00:03 <@mids> IIP 1.1.0 is released yesterday
-
            00:03 < toni> is it okay, to simply idle here and eve's drop?
-
            00:03 <@mids> toni: yes
-
            00:03 <@mids> Agenda for this meeting:
-
            00:03 <@mids> 1) IIP 1.1.0 
-
            00:03 <@mids> 2) Future of IIP
-
            00:03 <@mids> 3) Questions
-
            00:04 <@mids> if you have questions about the current subject, please ask
-
            00:04 <@mids> otherwise save it for round 3
-
            00:04 <@mids> .
-
            00:04 < nop> hi
-
            00:04 <@mids> logs are available on http://mids.student.utwente.nl/~mids/iip/
-
            00:04 < hezekiah> hi! :)
-
            00:04 < luckypunk> Hi.
-
            00:04 <@mids> .
-
            00:04 < jrand0m> ev'nin
-
            00:05 <@mids> 1) IIP 1.1.0 (stable) Released!!!
-
            00:05 < hezekiah> YAY!
-
            00:05 <@mids> Finally
-
            00:05 < luckypunk> :)
-
            00:05 <@mids> almost a year after nop's post that it would be out soon :)
-
            00:05 < FillaMent> w3rd i$ b0nd
-
            00:05 <@mids> In this version the installation for Unix is enhanced, entropy generation is improved and a few bugs are fixed. 
-
            00:05 <@mids> We call it a stable release
-
            00:05 < hezekiah> mids: Is that list of changes as compared to 1.1.0 RC3 or compared to 1.0.0?
-
            00:05 <@mids> and it looks stable so far
-
            00:06 <@mids> hezekiah: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/invisibleip/iip/CHANGELOG
-
            00:06 <@mids> thats all I know
-
            00:06 < hezekiah> OK. :)
-
            00:06 < hezekiah> (It sorta sounds like it is a comparison to 1.1.0 RC3 or RC2.)
-
            00:07 <@mids> hezekiah: it does, because nobody wrote what was updated before
-
            00:07 < dm> Should I download the Service Pack 2 for IIP if I'm using a cracked version of IIP?
-
            00:07 < hezekiah> mids: Ah ... Therein lies the tale! ;-)
-
            00:07 < dm> sorry, carry on.
-
            00:07 < hezekiah> dm: I'm not aware of any service packs.
-
            00:07 <@mids> the release is announced on our website, freshmeat, infoanarchy and frost
-
            00:08 <@mids> I did email a few other sites that had it listed
-
            00:08 <@mids> if you guys/girls know other places to tell...
-
            00:08 <@mids> please do so
-
            00:08 < jrand0m> nsa?
-
            00:08 < toni> i know, but im a total stranger to iip *g*
-
            00:08 < FillaMent> kuro5hin?
-
            00:08 < hezekiah> mids: Did you email that program archive that hosts it that was recently mentioned on iip-dev?
-
            00:08 < toni> heise.de german security/internet related site
-
            00:08 < FillaMent> jinx.biz
-
            00:09 <@mids> hezekiah: I did mail vipul's munitions
-
            00:09 < hezekiah> mids: OK! :)
-
            00:09 <@mids> kuro5hin requires a decent article
-
            00:09 <@mids> and they are very picky
-
            00:09 <@mids> but if you want to write something...
-
            00:09 <@mids> please do so
-
            00:09 < hezekiah> slashdot again?
-
            00:09 <@mids> toni: could you inform them?
-
            00:09 < hezekiah> They don't require anything super decent, and they mentioned us before. ;-)
-
            00:10 < toni> they also require articles, and i dont know how picky they are
-
            00:10 < toni> if somebody writes an article, i could translate it to german and email them
-
            00:10 <@mids> you could use the press release on http://www.infoanarchy.org/story/2003/3/10/23466/2065
-
            00:11 <@mids> and link the CHANGELOG to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/invisibleip/iip/CHANGELOG
-
            00:11 <@mids> be sure to include a general description of IIP
-
            00:11 <@mids> I think we should try to do /.
-
            00:12 <@mids> we survived it before
-
            00:12 < hezekiah> mids: Note: You mention to view the changelog in the infoanarchy article, but you don't appear to provide people with a link to it!
-
            00:12 < toni> since im not really familiar with iip, i guess i can't give a decent description, but if you /. it, i could give heise a hint, they often take news from there and translate them
-
            00:12 <@mids> hezekiah: yes, I forgot.
-
            00:12 <@mids> I'll mail their editor
-
            00:15 < hezekiah> OK ... anything else on agenda item 1 (IIP 1.1 release) ?
-
            00:17 <@mids> did you all already submit a newsstory to /.?
-
            00:17 < hezekiah> No.
-
            00:18 < hezekiah> I haven't been with the project quite long enough to have a firm grasp of what has happened since 1.0.
-
            00:18 < hezekiah> Who wrote the last /. post?
-
            00:18 <@mids> we dont know
-
            00:18 < hezekiah> LOL!
-
            00:18 < jrand0m> hahah
-
            00:18 < dm> I think it might have been no_nick
-
            00:18 < mihi> is iip too anonymous? ;-)
-
            00:19 <@mids> yes :)
-
            00:19 < hezekiah> Well, I'll go hunt up the previous post, and see if I can come up with something. :)
-
            00:19 <@mids> ok...
-
            00:19 <@mids> previous one was a copy of the kuro5hin article
-
            00:19 <@mids> which was about nop's interview
-
            00:19 <@mids> ok
-
            00:19 <@mids> Item 2??
-
            00:19 < hezekiah> Yay! :)
-
            00:20 <@mids> 2) Future of IIP
-
            00:20 <@mids> we want:
-
            00:20 <@mids> DECENTRALIZATION
-
            00:20 <@mids> but who is going to do it
-
            00:20 <@mids> and how
-
            00:21 < dm> and is it possible.
-
            00:21 < jrand0m> and what will be lost.
-
            00:21 < hezekiah> If I may interupt: I just want to make sure nop and UserX and present and accounted for. This conversation will be pretty futile without them. :)
-
            00:21 < jrand0m> (aka centralized authentication - trent)
-
            00:21 < hezekiah> nop?
-
            00:21 < hezekiah> UserX?
-
            00:21 <@mids> hezekiah?
-
            00:21 < hezekiah> Are you present?
-
            00:21 < hezekiah> mids: Here!
-
            00:21 < nop> I'm somewhat present
-
            00:22 < hezekiah> OK. :)
-
            00:22 < nop> userx and I have had discussions
-
            00:22 < nop> on how we would like to do it
-
            00:23 < hezekiah> Did those get discussions written up in papers and stuck in the research directory of the IIP website?
-
            00:23 < nop> ues
-
            00:23 < nop> most are there
-
            00:23 < nop> userx has more
-
            00:23 < nop> that I would like pu t there
-
            00:23 < nop> http://www.invisiblenet.net/research/IIP-WP-Notes.txt
-
            00:23 < hezekiah> OK. Could you please give the filenames of the most relavent ones so I can give them a look? :)
-
            00:23 < nop> that one contains quite a bit
-
            00:24 < nop> there is also some other's contributed
-
            00:24 < nop> IIP_netproto.html
-
            00:24 < nop> and architecture.pdf
-
            00:24 < hezekiah> OK. :)
-
            00:24 < nop> 
-
            00:25 < nop> http://www.invisiblenet.net/research/IIP-Identity.txt
-
            00:25 < nop> as well
-
            00:25 < nop> http://www.invisiblenet.net/research/IIP-Messages.txt
-
            00:27 < hezekiah> OK. Are any of them completely (or primarily) devoted to just the decentralization aspect?
-
            00:27 < nop> yes
-
            00:27 < nop> all of them
-
            00:27 < hezekiah> OK. :)
-
            00:27 < hezekiah> Thanks for all the links! I'm checking them out now. :)
-
            00:31 <@mids> ok
-
            00:31 <@mids> other IIP Future events?
-
            00:31 < dm> is FillaMent here?
-
            00:31 < hezekiah> Well, in the near future, IIP-dev still doesn't have the "entropy problem" fixed.
-
            00:31 < dm> he had the idea of making trent allow PGP key exchanges
-
            00:31 < dm> which makes sense.
-
            00:31  * FillaMent is present
-
            00:32 <@mids> yes FillaMent and me did talk about that
-
            00:32  * mids hands the microphone to FillaMent 
-
            00:32  * FillaMent taps it a couple times, "this thing on?" (sorry)
-
            00:33  * hezekiah turns up the volume
-
            00:33 < lonelynerd> :)
-
            00:33 < FillaMent> Here's the deal: I think it'd be handy to have a PGP key storage and exchange mechanism on IIP. I have a few proposals as to how such a thing should work.
-
            00:34 < dm> Should be fairly easy? Just add a field for PGP to trent, and add GET/STORE commands?
-
            00:34 < FillaMent> 1) Capability is built into trent. This presents a problem with most IRC clients sending strings that long
-
            00:35 < dm> ah, ok.
-
            00:35 < FillaMent> 2) Make trent able to pull a CHK from freenet and store the contents of that file as the Key
-
            00:35 < FillaMent> 3) Build a separate bot to preform 1 or 2
-
            00:35 < nop> hmm
-
            00:35 <@mids> good points
-
            00:35 < nop> the only issue
-
            00:35 < nop> I have
-
            00:35 < nop> with this concept
-
            00:35 < nop> is how do we trust trent or any bot for that matter to handle pub keys
-
            00:35 < nop> without verification
-
            00:36 <@mids> well
-
            00:36 < FillaMent> Well, it could check and make sure the nick was reg'd and ident'd
-
            00:36 <@mids> it could be just as a keyserver
-
            00:36 < nop> the idea I'm thinking
-
            00:36 < nop> is it can do a verify to all major key servers
-
            00:36 < nop> as well
-
            00:36 < nop> so that it gets congruent info
-
            00:36 < FillaMent> nop: read my flog entry about psuedoidentity?
-
            00:36 < nop> link
-
            00:37 < FillaMent> SSK@WxBcPJd1ppZSZ~C8IJI-DHx94oIPAgM/fillament//
-
            00:37 <@mids> keyservers dont verify anything
-
            00:37 <@mids> they just store stuff
-
            00:37 <@mids> what you can do now with Trent
-
            00:37 < FillaMent> here's the short of it... what if your identity only exists in anonymous space? What can you verify?
-
            00:37 <@mids>  /squery trent nickinfo mids
-
            00:38 <@mids> see the comment line
-
            00:38 <@mids> it can contain anything
-
            00:38 <@mids> also urls etc
-
            00:38 < FillaMent> but short
-
            00:38 <@mids> so you could link to your PGP key
-
            00:39 < FillaMent> I'm just thinking of something to remove all the middle steps.
-
            00:39 < hezekiah> Looking at mids' ID comment, I see it lists a key fingerprint
-
            00:39 < hezekiah> It also lists the key ID. Why can't someone just get the key from a keyserver, and check the fingerprint.
-
            00:39 < FillaMent> hezekiah: What key server?
-
            00:39 < FillaMent> one on the internet?
-
            00:39 < nop> that's what I'm saying
-
            00:40 < mihi> how get a key up to a key server? anonymously?
-
            00:40 < lonelynerd> we just need a bot to fetch those
-
            00:40 < FillaMent> if your identity only exists in anonymous space, like mine... I don't want to leave a trail on the internet
-
            00:40 < hezekiah> Ah ...
-
            00:40 < hezekiah> OK. I get it. :)
-
            00:40 <@mids> so a keyserver bot for IIP would be it
-
            00:40 <@mids> combined with freenet
-
            00:40 < FillaMent> that'd be sweet... just feed trent the fingerprint and it'll try to fetch the key...
-
            00:41 <@mids> currently freenet is too heavy to run on the Trent server
-
            00:41 < lonelynerd> mids, well, you could ascii armor the public keys
-
            00:41 < FillaMent> mids: Such a thing need not be built into trent, as my point 3
-
            00:41 < nop> well
-
            00:41 < nop> you could use a gateway mids
-
            00:41 < nop> like groovy
-
            00:41 <@mids> too unreliable
-
            00:42 < someone> why do you need freenet, again?
-
            00:42 < FillaMent> mids: If you wanted to make trent capable, just have it access one of the public freenet servers
-
            00:42 <@mids> why not let a user upload the key to freenet and give the url to the bot?
-
            00:42 <@mids> someone: for file storage
-
            00:42 < FillaMent> mids: Because it a few days it's gone if no one accesses it.
-
            00:42 < lonelynerd> mids, wouldn't it be more efficient to have a one huge digest of public keys used by people?
-
            00:43 < hezekiah> lonelynerd, mids: You could just add a the capability to assign PGP key ID's to a nick just like you can assign a comment.
-
            00:43 < FillaMent> I think the best solution is to have it not integrated into IIP. Someone writes it as a piece of software (hell, I could do it but am busy) then distribute the software. Anyone who wants to run an IIP keyserver, can.
-
            00:44 < lonelynerd> hezekiah, true, but you still need to fetch the pgp key
-
            00:44 < nop> ok here's the funny thing
-
            00:44 < lonelynerd> FillaMent, sounds reasonable
-
            00:44 < nop> things we can see
-
            00:44 < nop> we trust
-
            00:44 < nop> like the internet
-
            00:44 < nop> yet it's insecure
-
            00:44 < someone> why not just have a bot upload nad download keys from internet key servers and store a fingerprint with trent
-
            00:44 < nop> yet we have a cryptographic network
-
            00:44 < nop> and we don't trust a soul to run a pgp keyserver
-
            00:44 < lonelynerd> someone, that's what i suggested
-
            00:44 < hezekiah> nop: lol! :)
-
            00:45 < lonelynerd> nop :)
-
            00:45 <@mids> nop
-
            00:45 <@mids> you dont get it
-
            00:45 < nop> I do get it
-
            00:45 <@mids> you DONT need trust for a keyserver
-
            00:45 < nop> I'm joking
-
            00:45 < FillaMent> nop: Sure you do... one just has to put their pseudoidentity on line.
-
            00:45 < FillaMent> on the line
-
            00:45 < FillaMent> mids: Sure you do
-
            00:45 <@mids> it is just for storage
-
            00:45 < nop> I know mids
-
            00:45 < nop> I was just being funny
-
            00:45 < nop> ;)
-
            00:45 <@mids> users should ALWAYS verify fingerprint
-
            00:45 < someone> lonelynerd: so we don't need freenet, right?
-
            00:45 <@mids> and check web of trust
-
            00:45 < FillaMent> mids: I could just stick my key there and say it's nop's.
-
            00:46 <@mids> nop: good if you are funny :) but others might not understand it
-
            00:46 < lonelynerd> FillaMent, actually, what you wrote about pseudoidentity got me thinking. i'm wasting time and resources by having two identities on iip, one for people who know me irl and then this.
-
            00:46 <@mids> FillaMent: thats why you can stick the fingerprint on Trent
-
            00:46 < lonelynerd> someone, exactly, freenet is cool, but not needed this time
-
            00:46 <@mids> (you'll have to trust trent though
-
            00:46 < FillaMent> mids: Yes... and /how/ many people know about key fingerprints?
-
            00:47 < lonelynerd> someone, but somebody could still post compressed digests contain many keys
-
            00:47 <@mids> if they dont know, they shouldnt use PGP
-
            00:47 < FillaMent> mids: yeah.. let's alienate the userbase
-
            00:47 < lonelynerd> true
-
            00:47 < lonelynerd> :)
-
            00:47 <@mids> no seriously
-
            00:47 < FillaMent> I've already had this discussion 20x with zab
-
            00:47 < hezekiah> FillaMent: if they don't know enough about key fingerprints, then they probably don't know enough about crypto for me to trust that they haven't given away their key!
-
            00:47 <@mids> using PGP without checking fingerprints gives a false sense of security
-
            00:48 < FillaMent> hezekiah: And how do you sort those people out?
-
            00:49 < lonelynerd> FillaMent, that's tricky. far too many users use pgp insecurely
-
            00:49 < hezekiah> FillaMent: Tis the billion dollar question! That is very hard. :) 
-
            00:49 < FillaMent> If you tell people that they're too stupid to use crypto, they won't want to. They'll say, 'fuck it... I don't have time to care about privacy'... they may be sheep, but there are more of them voting than us. We have to make it easy for the sheep.
-
            00:50 <@mids> you can try to educate them
-
            00:50 < FillaMent> You have to get them in the classroom, and IIP/Fnet is the best classroom I know of
-
            00:50 < hezekiah> Correct, mids. Security is only as strong as the intelligence of the person behind it.
-
            00:50 <@mids> I totally agree FillaMent 
-
            00:51 < FillaMent> such a key storage bot would have a motd explaining that they should be checking fingerprints
-
            00:51 <@mids> I just think that you should seperate keyserver from trust
-
            00:51 < hezekiah> So what are we going to do with this bot and IIP? What do we want it to do, and how?
-
            00:51 < FillaMent> I think it should be a 3rd party thing
-
            00:52 < hezekiah> Like anonymail?
-
            00:52 < FillaMent> no... like something that anyone can run
-
            00:52 <@mids> anybody can run anonymail
-
            00:52 <@mids> IF you would have the source
-
            00:52 <@mids> :)
-
            00:52 < FillaMent> mids: You know what I mean though
-
            00:53 <@mids> yes
-
            00:53 <@mids> sorry
-
            00:53 < hezekiah> So is this something, the IIP developers need to write, or can someone who knows nothing about IIP but basic IRC can write?
-
            00:53  * FillaMent already has a framework going
-
            00:53 < hezekiah> OK! :)
-
            00:54 < FillaMent> well... I'd have to hack it to change it's direction
-
            00:54 < FillaMent> GAH!!!!!! More projects!!!! Nooooooo!
-
            00:54 < jrand0m> give in FillaMent, just give in
-
            00:54 < FillaMent> jrand0m: I know... I know.
-
            00:54 < hezekiah> Basically what I'm asking is, is this something that needs to get built into IIP, or can it be independant?
-
            00:55 < FillaMent> independent
-
            00:55 < hezekiah> If it's independant, then I'd say, "GO FOR IT!" :)
-
            00:55 <@mids> hezekiah: IndependEnt
-
            00:55  * mids ducks
-
            00:55 < hezekiah> mids: really?
-
            00:55 <@mids> yes
-
            00:55  * FillaMent thinks he's missing a joke.
-
            00:56 < hezekiah> My spell checker says independant is OK.
-
            00:56 <@mids> hezekiah: made a typo
-
            00:56 < FillaMent> oh... yeah...
-
            00:56 < FillaMent> dent
-
            00:56 < FillaMent> independEnce
-
            00:56 < hezekiah> Hmmm ... it says independent is OK too, odd.
-
            00:56 <@mids> hezekiah:  grep "^independ.nt$" /usr/share/dict/words 
-
            00:56 < FillaMent> probably a new english/old english thing
-
            00:56 <@mids> anyway
-
            00:56 < hezekiah> Anyway ... :)
-
            00:57 <@mids> say we have this keybot
-
            00:57 < hezekiah> And it will be independent of IIP. :)
-
            00:57 <@mids> how will it get the key from a user?
-
            00:57 < FillaMent> /msg
-
            00:57 <@mids> the full key?
-
            00:57 < FillaMent> no
-
            00:57 < FillaMent> freenet
-
            00:57 <@mids> ah
-
            00:58 <@mids> so you msg the freenet url
-
            00:58 <@mids> and it tries to download in the background
-
            00:58 < lonelynerd> what's the problem? you can easily paste full key to iip.
-
            00:58 < FillaMent> /msg Keybot STORE CHK@lakdjfa;lsdfjasd;lkfj
-
            00:58 <@mids> lonelynerd: my key is 8 KB big
-
            00:58 < FillaMent> lonelynerd: Not will all clients
-
            00:58 < mihi> FillaMent: you can if you do it in blocks of 10 lines.
-
            00:59 <@mids> the keyboard _could_ look if you are identified with trent
-
            00:59 <@mids> keybot
-
            00:59 <@mids> :)
-
            00:59 < FillaMent> mids: It would have to
-
            00:59 <@mids> and just add that as an additional flag
-
            01:00 < FillaMent> /msg keybot MSGSTORE ad;flkjsflkjsdf;lasdrkfj
-
            01:00 < FillaMent> /msg keybot MSGSTORE ad;flkjsflkjsdf;lasdrkfj
-
            01:00 < FillaMent> /msg keybot MSGSTORE ad;flkjsflkjsdf;lasdrkfj
-
            01:00 <@mids> well
-
            01:00 < FillaMent> such a thing would best be scripted
-
            01:00 <@mids> yes
-
            01:00 <@mids> exactly
-
            01:00 < jrand0m> is a centralized identity manager like trent really desireable?
-
            01:00 < FillaMent> so either chopped and sent via msg or via freenet
-
            01:00 <@mids> jrand0m: with a centralized ircd, yes
-
            01:00 <@mids> maybe we should form a keybot commitee
-
            01:01 <@mids> and let them discuss the details
-
            01:01 < jrand0m> ah, right.  yeah, I was assuming a decentralized net.
-
            01:01  * mids opens #keybot
-
            01:01 < FillaMent> mids: I don't see a need
-
            01:01 <@mids> well
-
            01:01 <@mids> we got more on the agenda
-
            01:01 < lonelynerd> mids, uhm.
-
            01:01 <@mids> and we are already busy for 1 hour
-
            01:01 < FillaMent> 20 people start keybots... 1 will eventually prove the most reliable and become the defacto standard
-
            01:02 <@mids> I mean more.. any other Future IIP things?
-
            01:02 < hezekiah> nop?
-
            01:02 < hezekiah> What are the major features/changes you plan for 1.2?
-
            01:02 < nop> what
-
            01:02 < nop> decentralization
-
            01:02 < nop> and channel encryption
-
            01:02 < nop> as well as client to client encryption
-
            01:02 < nop> channel trust
-
            01:02 < nop> using RSA keyring
-
            01:02 < Debolaz> I have a question. What is the thing needed most from IIP now, that an ISP would be able to provide?
-
            01:03 <@mids> money!
-
            01:03 <@mids> millions
-
            01:03 <@mids> so we can hire thousands of developers
-
            01:03 < Debolaz> I was thinking more in terms of services.
-
            01:04 < jrand0m> OC12?
-
            01:04 <@mids> hosting is fine at sf so far
-
            01:04 <@mids> maybe a stable node somewhere
-
            01:05 <@mids> ...
-
            01:05 < Debolaz> Well, I was thinking of a node sort of thing. And perhaps a file mirror.
-
            01:05 <@mids> project release files are already mirrored on 8 servers so far
-
            01:06 <@mids> plus on vipul's munitions
-
            01:07  * mids slowly pushes the topic to item 3, questions
-
            01:07 < hezekiah> Ack!
-
            01:07 <@mids> 3) Questions?
-
            01:08 < jrand0m> eta for decentralization (1 mo, 3 mo, 6 mo)?
-
            01:08 < jrand0m> aka, without dependence on a central server
-
            01:08 <@mids> no comment!
-
            01:08 < hezekiah> mids: LOL!
-
            01:08 < hezekiah> I really have no idea. UserX would probably have the best bet
-
            01:09 < hezekiah> nop, UserX: are we done decentralizing "core" in isproxy yet?
-
            01:09 < nop> um no
-
            01:11 < hezekiah> I'm assuming that "core" comes before ircd decent., right?
-
            01:12 < nop> first
-
            01:12 < nop> we have to make a virc 
-
            01:12 < nop> which is a virtual irc transport
-
            01:12 < nop> so that the irc clients can still talk to the core
-
            01:12 < nop> without ircd
-
            01:13 <@mids> roadmap anybody?
-
            01:13 < hezekiah> lol. I'm clueless. :)
-
            01:16 <@mids> *silence*
-
            01:16 <@mids> I heared that some wanted next meeting to be earlier
-
            01:16 < nop> yes
-
            01:16  * FillaMent rubs his legs together furiously but fails to produce the proper chirp.
-
            01:16 < nop> UserX can't make it at the time we have now
-
            01:16 < nop> because of work 
-
            01:16 < hezekiah> Ah.
-
            01:16 < nop> if we had it a couple hours earlier
-
            01:16 <@mids> what time would be better?
-
            01:16 < nop> this would be easier
-
            01:16 <@mids> 21:00 UTC?
-
            01:16 < hezekiah> If UserX would talk more we could really get some stuff done! :)
-
            01:16 < nop> that should work
-
            01:17 < hezekiah> Let's see ...
-
            01:17 < hezekiah> It's normally 23:00 UTC, right?
-
            01:17 <@mids> yes
-
            01:17 < hezekiah> Yeah.
-
            01:17 < hezekiah> That should work for me. :)
-
            01:17 <@mids> 21:00 UTC it is
-
            01:18 <@mids> ok
-
            01:18 <@mids> I am out
-
            01:18 <@mids> thanks for listening to me :)
-
            01:18  * mids bows
-
            01:18 <@mids> oh
-
            01:18 <@mids> before I forget
-
            01:18 <@mids> UserX, nop, hezekiah, thanks for your work on IIP so far!
-
            01:18 < hezekiah> mids: I enjoy listening to you.
-
            01:19 < hezekiah> mids: A pleasure! :)
-
            01:19 < hezekiah> All you guys make it worthwhile! :)
-
            01:19 < jrand0m> yeah, thanks for the updates.  I appreciate using y'alls software
-
            01:19 < hezekiah> (Note: I am a Yankee. No offense is meant if there are girls in the channel.)
-
            01:19  * FillaMent curses them for this network that consumes his free time.
-
            01:19 < hezekiah> FillaMent: lol! :)
-
            01:19 < jrand0m> heh
-
            01:20  * hezekiah picks up the "baf"er
-
            01:20 < hezekiah> *BAF!*
-
            01:20 < hezekiah> Meeting adjurned! :)
-
            01:22 < mihi> adjourned, you mean?
-
            01:23 < hezekiah> Over.
-
            01:23 < hezekiah> Done.
-
            01:23 < hezekiah> End.
-
            01:23 < hezekiah> Dead.
-
            01:23 < hezekiah> The meeting is dead. Long live the next meeting.
-
            01:23 < mihi> ;-) logger is still living
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting34.html b/www.i2p2/pages/meeting34.html
deleted file mode 100644
index d43c27e9..00000000
--- a/www.i2p2/pages/meeting34.html
+++ /dev/null
@@ -1,136 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 34{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 34
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Mar 18 20:14:29 2003
-
            20:15 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            20:15 [Users #iip-dev]
-
            20:15 [ jeremiah] [ logger] [ mids] [ UserX] 
-
            20:15 -!- Irssi: #iip-dev: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal]
-
            20:15 -!- Irssi: Join to #iip-dev was synced in 5 secs
-
            20:17 -!- mode/#iip-dev [+o mids] by Trent
-
            22:00 < nop> hi
-
            22:00 <@mids> Tue Mar 18 21:00:10 UTC 2003
-
            22:00 < hezekiah> Hi. :)
-
            22:00 <@mids> HEllo
-
            22:00 <@mids> so 
-
            22:01 <@mids> whats on the agenda?
-
            22:01 < hezekiah> I have no clue.
-
            22:01 < armpit> howdy
-
            22:01 < hezekiah> Hi
-
            22:01 <@mids> ok
-
            22:01 < armpit> mind if i lurk around? :)
-
            22:01 <@mids> then lets just keep a question round
-
            22:01 <@mids> btw, Freenet 0.5.1 is out
-
            22:01 < hezekiah> Cool. :)
-
            22:02 < hezekiah> Maybe one of these days I'll try using it. :)
-
            22:02 <@mids> so, any IIP questions?
-
            22:02 < Hitman> quick run down of current status would be nice nop
-
            22:02 < Hitman> so we can get up to speed on what's happening with it all
-
            22:03 <@mids> good point
-
            22:03 < nop> hold
-
            22:03  * hezekiah turns on beautiful classical music those tech-support hotlines play while we wait for them ...
-
            22:04  * Hitman shudders as teh memories flood back
-
            22:05  * mids runs out of breath
-
            22:06  * mids dies
-
            22:06 < hezekiah> Well, meanwhile I think it should be noted that some people don't appear to have remembered the meeting starts 2 hours earlier now.
-
            22:06 <@mids> or they just dont care :)
-
            22:07 < nop> ok
-
            22:07 < nop> back
-
            22:07 < hezekiah> Yay! :)
-
            22:07 < nop> 1.1.0 is out, 1.2 meeting needs to be set
-
            22:07 < nop> so that hez, Userx and I can discuss furthur major development
-
            22:08 <@mids> maybe the development cycle should be more open?
-
            22:08 <@mids> so others can hear what the plans are too?
-
            22:08 < nop> we will log and place in research directory
-
            22:08 < nop> on invisiblenet
-
            22:08 <@mids> ok
-
            22:08 < Aprogas> that would counter allegations that IIP is vapourware
-
            22:09 < hezekiah> mids: I think openess is great, but it can get pretty annoying when you are trying to discuss coding and the listeners are continueally getting off the subject into theory. :(
-
            22:09 < nop> that's why we log
-
            22:09 < nop> ;)
-
            22:09 < hezekiah> I think the logging is a good idra.
-
            22:09 < nop> and publish
-
            22:09 <@mids> hezekiah: channels can be moderated
-
            22:09 < hezekiah> Maybe we could post the log to the iip-dev mailing list too? That would give people a good idea of what's going on behind the scenes.
-
            22:09 < Hitman> open discussion of ideas and brainstorming would rock, but end product changes will have to be discussed seperately by the actual coding team otherwise thing's won't get implemented correctly
-
            22:09 <@mids> k
-
            22:09 < hezekiah> They could pipe up with all kinds of suggestions then. :)
-
            22:10 < hezekiah> UserX? Are you currently present?
-
            22:10 < UserX> i'm present
-
            22:10 < hezekiah> OK. :)
-
            22:10 < hezekiah> (To both UserX and nop): Do either of you have any times for that meeting that would be good for you?
-
            22:11 < hezekiah> I mentioned the times that won't work for me, in my email. I hope it's a small enough subset not to be a problem. :)
-
            22:12 <@mids> anyway, you can settle that in private
-
            22:12 < Hitman> in my personal opinion I think that decentralisation of the network is the number one priority.  To make IIP completely p2p would take away any ability whatsoever the goverment and other nasty forces have to shut it down.  While a central server exists tehy can still end it....ie napster
-
            22:12 < hezekiah> OK.
-
            22:12 <@mids> we can read the logs afterwards.
-
            22:13 < hezekiah> Hitman: decentralization is the main theme of 1.2
-
            22:13 < Hitman> sweet
-
            22:14 < hezekiah> So where were we?
-
            22:15 < hezekiah> Oh, yeah. Nop was listing the current status of 1.2.
-
            22:15 < nop> yeah
-
            22:15 < hezekiah> Did you have anything else to add, nop?
-
            22:15 < nop> so 1.2 we need a dev meeting to start
-
            22:15 < nop> and from that point is our start
-
            22:16 < Aprogas> did you create a branch in CVS so bugs in 1.1 can be fixed without requiring users to update to a alpha or beta state 1.2 ?
-
            22:17 < UserX> The development is already in a seperate branch from 1.1
-
            22:18 < hezekiah> And the 1.1 release was tagged v1-1-0.
-
            22:18 < Aprogas> so there is a tag on the release, but not a branch tag ?
-
            22:18 < Aprogas> i assume the development is on the `MAIN' branch ?
-
            22:19 < hezekiah> Uh, I currently don't know what CVS commands I should be running to tell the difference. :)
-
            22:19 < UserX> 1.1 is on the MAIN branch
-
            22:19 < Aprogas> something like cvsweb gives more overview of such things than cvs commands anyway; branchs in cvs are quite confusing
-
            22:20 < Aprogas> anyway, having a release on the main branch and the development in a seperate branch is quite an uncommon setup; and that might have reasons
-
            22:20 < Aprogas> maybe it is worth investigating if it would not be more useful to do it the other way around ?
-
            22:25 < hezekiah> Well, I don't know much about CVS so my input wouldn't be much worth here. :)
-
            22:26 < Aprogas> CVS is a scary beast
-
            22:27 < hezekiah> Yeah. I wonder if it ate the other people in the room. It seems deathly quiet in here.
-
            22:27 < Aprogas> i ended up re-importing sources numerous times because i messed up after trying to put my branches right
-
            22:27 < hezekiah> ;-)
-
            22:28 < Aprogas> so be careful with it
-
            22:28 < hezekiah> *lol*
-
            22:29 < hezekiah> Mids? Do we have another item on the agenda? It seems like we're done with this one (or else someone got eaten by the CVS beast.)
-
            22:31 < Aprogas> well.. i didnt really see anyone reacting to my `suggestions'
-
            22:31 < Aprogas> im wondering why the IIP development team uses this different way of using branches
-
            22:31 < hezekiah> I have no clue.
-
            22:31 < Aprogas> i guess 99% of the CVS-using project develop on the MAIN branch and keep releases on seperate branches
-
            22:32 < hezekiah> I do know that it works fine.
-
            22:32 < Aprogas> that will become obvious when you get 1.2
-
            22:32 < Aprogas> what will happen with 1.1 which s currently on the main branch ?
-
            22:32 < hezekiah> So I say that "If it isn't broken, then don't fix it."
-
            22:32 < hezekiah> It's sources are tagged.
-
            22:33 < Aprogas> a bug in it might be found
-
            22:33 < Aprogas> and you might want to create 1.1.1
-
            22:33 < hezekiah> I guess that if we need to do a bug fix, then someone checks out v1-1-0, fixes the bug, and commits under the tag v1-1-1.
-
            22:33 <@mids> hezekiah: no, none
-
            22:33 < Aprogas> hezekiah: that is possible too
-
            22:33 < hezekiah> mids: As I said, I don't know much about CVS. :)
-
            22:33 < Aprogas> but using release branches is more common
-
            22:33 < UserX> the developement will probably be merged back on to the main branch. and if we need to do bug fixes/upgrades to 1.1 we just create a branch from it
-
            22:33 < Aprogas> userx: ok
-
            22:33 < hezekiah> Oh, well. I'll leave the CVS playing to the developers that understand it. :)
-
            22:34 < Aprogas> noone understands CVS
-
            22:34 < hezekiah> lol
-
            22:34 < Aprogas> thats the problem
-
            22:34 < Aprogas> its a beast that cannot really be tamed
-
            22:34 < hezekiah> So, mids. What's next on the agenda? Question round?
-
            22:34 <@mids> ok, I am out. cya
-
            22:35 -!- mode/#iip-dev [+o hezekiah] by Trent
-
            22:35 <@hezekiah> OK. The question round has officially begun, I guess. :)
-
            22:35 < Aprogas> oh
-
            22:35 <@hezekiah> Questions?
-
            22:35 <@hezekiah> (Not that I can promise an answer, but you can ask.)
-
            22:37 <@hezekiah> Going once ...
-
            22:37 <@hezekiah> Going twice ..
-
            22:37 <@hezekiah> Gone!
-
            22:38 <@hezekiah> Sold to the eternal silence of the ever questioning public (until the next iip-dev meeting that is.) ;-)
-
            22:38 <@hezekiah> Well, it was nice talking to you all (and nice to be able to have UserX around and talking in an iip-dev meeting. I'm glad the time change has improved things for him.)
-
            22:38 <@hezekiah> Bye, all! :)
-
            22:38 < nop> bye
-
            --- Log closed Tue Mar 18 22:43:48 2003
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting35.html b/www.i2p2/pages/meeting35.html
deleted file mode 100644
index 226035ff..00000000
--- a/www.i2p2/pages/meeting35.html
+++ /dev/null
@@ -1,208 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 35{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 35
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Mar 25 22:07:19 2003
-
            22:07 -!- Topic for #iip-dev: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/
-
            22:07 [Users #iip-dev]
-
            22:07 [@hezekiah] [ Aprogas] [ logger] [ mids] [ poX] [ UserX] 
-
            22:07 -!- Irssi: #iip-dev: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal]
-
            22:07 -!- Irssi: Join to #iip-dev was synced in 3 secs
-
            22:07 < UserX> yes
-
            22:07 <@hezekiah> OK. :)
-
            22:07 < mids> log is up http://mids.student.utwente.nl/~mids/iip/meeting35/livelog.txt
-
            22:07 < Aprogas> /exec -o tail -f http://mids.student.utwente.nl/~mids/iip/meeting35/livelog.txt
-
            22:08 < Aprogas> loops are fun
-
            22:08 < mids> unless anybody has any agenda;
-
            22:08 < mids> I'd like to hear what the official proposals are for the decentralized routing protocol
-
            22:09 < Aprogas> then at least have  1. decentral routing protocl 2. question  as agenda
-
            22:09 < mids> 1) welcome
-
            22:09 < mids> 2) decentralized protocol
-
            22:09 < mids> 3) WVTTK
-
            22:09 < mids> 4) questions
-
            22:09 < Aprogas> thats dutch
-
            22:10 < mids> whats the english word for it?
-
            22:10 < Aprogas> 3) WCTTA
-
            22:10 < Aprogas> maybe
-
            22:10 < Aprogas> but latin would be more elite
-
            22:10 < Aprogas> where is the director to tell me to shut up and get back to the point ?
-
            22:10 <@hezekiah> Aprogas: be quite and get back to the point. ;-)
-
            22:10 < mids> quod etcetera mensa venit
-
            22:11 < Aprogas> hezekiah: thanks
-
            22:11 < mids> -1-
-
            22:11 < mids> Welcome everybody!
-
            22:11 <@hezekiah> Hiya! :)
-
            22:11 < mids> as you see, the regular meetings are earlier as the other 33 ones from now on
-
            22:11 < mihi> hi mids
-
            22:11 < mids> .
-
            22:11 < mids> -2-
-
            22:11 < Aprogas> to better fit the mainly US/EU users of IIP ?
-
            22:12 < nop> yo
-
            22:12 < Aprogas> hello nop
-
            22:12 -!- mode/#iip-dev [+o nop] by Trent
-
            22:12 <@nop> got the page
-
            22:12 <@hezekiah> Hiya, nop! :)
-
            22:12 < mids> Aprogas: it would fit better for UserX / nop
-
            22:12 <@nop> is userx alive?
-
            22:12 < Aprogas> dont forget to change your nick to noP
-
            22:12 -!- nop is now known as noP
-
            22:12 < mids> 2) I'd like to hear what the official proposals are for the decentralized routing protocol
-
            22:12 <@noP> thnx aprogas
-
            22:12 <@noP> we have no official proposal till Friday 21:00 
-
            22:12 < UserX> noP: i'm here
-
            22:13 <@noP> that is to be discussed
-
            22:13 <@noP> there are semi-official proposals in www.invisiblenet.net/research
-
            22:13 < Aprogas> can i join that discussion to give totally useless suggestions ?
-
            22:13 <@noP> which are many different proposals
-
            22:13 <@hezekiah> Uh, oh. Looks like I have a lot of reading to do before Friday. ;-)
-
            22:13 <@noP> we will log it
-
            22:13 <@noP> and you can suggest
-
            22:13 <@noP> during iip-dev meeting
-
            22:14 <@noP> yeah hezekiah we added more stuff ;)
-
            22:14 -!- mids changed the topic of #iip-dev to: IIP Meeting - logfiles: http://mids.student.utwente.nl/~mids/iip/ - http://www.invisiblenet.net/research/
-
            22:14 < mids> ok
-
            22:14 < mids> .
-
            22:14 < mids> quod etcetera mensa venit?
-
            22:14 <@noP> brb
-
            22:14 <@hezekiah> mids: What language is that?
-
            22:15 < mids> latin
-
            22:15 <@hezekiah> Ah.
-
            22:15 < Aprogas> mensam sounds more correct
-
            22:15 < mids> it should mean something like: what else comes to the table
-
            22:15 < Aprogas> and `etcetera' isnt
-
            22:15 < mids> et cetera
-
            22:15 < Aprogas> but that still doesnt make sense
-
            22:16 < mihi> quod ceterum ad mensam venit?
-
            22:16 < Aprogas> maybe
-
            22:16 < Aprogas> when will the IIP sourcecode be translated to latin using latin.h ?
-
            22:16 < mihi> igpay atinlay? ;-)
-
            22:16 < Aprogas> in other words, when will IIP development freeze to transfer those manhours to my latin.h project and complete it, only to then implement it in IIP ?
-
            22:17 <@hezekiah> Never.
-
            22:17 < mids> quod autem ad mensam venit
-
            22:17 < mids> powered by http://www.latijnnederlands.nl/
-
            22:17 < mids> .
-
            22:17 < Aprogas> thats W Echter TTK
-
            22:17 < mids> any IIP questions?
-
            22:17 < mids> Aprogas: 2. verder, voorts, en dan (ter voortzetting of uitwerking v. iets voorafgaands).
-
            22:17 < mihi> "*but* what comes to the table"?
-
            22:17 < Aprogas> `what' does
-
            22:18 < mids> mihi: questions, proposals, comments
-
            22:18 < mihi> mids, you missed the ""
-
            22:18 < Aprogas> anything that was talked about during the meeting but didnt fit in the point that was currently active
-
            22:18 <@hezekiah> Is this item 3 on the agenda?
-
            22:18 < Aprogas> hezekiah: i think we are at questions yet
-
            22:18 < mids> hezekiah: yes
-
            22:18 < Aprogas> the meeting seems chaotic and without any real content, except that the decision on the routing protocol will be made later
-
            22:19 <@hezekiah> ... because I have no idea what "WVTTK" means and this conversation is definately obscure enough to be a possible candidate. ;-)
-
            22:19 < mids> ok, /me formalizes
-
            22:19 <@hezekiah> Right
-
            22:19 < Aprogas> its probably because i am here
-
            22:19 < mids> and because I had a lot of beer
-
            22:19 < Aprogas> WVTTK in reality is anything that does not make sense
-
            22:19  * mids moves on to point 4
-
            22:20 < mids> any IIP related questions?
-
            22:20 < Aprogas> how does the IIP team expect the userbase to grow, and when will massive PR start to stimulate more growth ?
-
            22:20 < Aprogas> also, what kind of people does the IIP team expect to attract in the beginning, and with the PR campaign
-
            22:21 < mids> past experience has tought that it is very easy to get on slashdot
-
            22:21 < mids> which results in a quick increase of users
-
            22:21 < mids> but you need Cool Features
-
            22:21 < mids> to excuse an announcement
-
            22:21 < Aprogas> well, most slashdot users dont stay long i think
-
            22:21 < Aprogas> a few of them stay, but most just want to `check it out'
-
            22:21 <@hezekiah> Right.
-
            22:21 <@hezekiah> So once we decentralize we will have something to brag about on /.
-
            22:22 < mids> then we can address some online magazines
-
            22:22 < mids> like theregister
-
            22:22 < mids> and/or wired
-
            22:22 < Aprogas> you need cool features to excuse an announcement, and you need a cool application to keep them
-
            22:22 <@hezekiah> Right.
-
            22:22 < Aprogas> but slashdot is a pretty `limited' target group
-
            22:22 < Aprogas> it only attracts a certain type of people
-
            22:22 < mids> it is a part
-
            22:22 < Aprogas> perhaps some more diversity would be good
-
            22:22 < mids> you could also address some target audiences
-
            22:22 <@hezekiah> I personally don't really care about attracting people. I just want a good program.
-
            22:23 < mids> like writing to the dutch organisation Martijn :)
-
            22:24 < mids> maybe some press release to AA groups, amnesty, EFF, scientology/cult critics
-
            22:24 < mids> hezekiah: even with a good program you require a certain userbase to be able to offer decent traffic
-
            22:25 < mids> you cant have only 2 users on your ultra-anonymous network
-
            22:25 <@hezekiah> The way I look at it, if it's easy enough to find on freashmeat/sourceforge and it offers what people want (good anonymized chat), then people will use it.
-
            22:26 <@hezekiah> Yes. That is a very primitive outlook on userbase growth.
-
            22:26 < Aprogas> the average internet user does not search at sourceforge
-
            22:26 < Aprogas> its hard to search for something if you dont know that it exists
-
            22:26 < mids> hezekiah: freshmeat / sourceforge is only for the geeks
-
            22:26 < mids> they think that anonymity is 'cool' 
-
            22:26 < mids> but dont really need it that much
-
            22:26 <@hezekiah> Or they have people they don't want to be looking over their shoulder. :)
-
            22:26 < mids> cause they have nothing to hide :)
-
            22:27 <@hezekiah> But their paranoia helps them set up secure nodes.
-
            22:27 <@hezekiah> I'm not sure I would want my message traffic running through Great Aunt Edna's Windows Me machine.
-
            22:27 < mids> what is the target audience in your oppinion?
-
            22:27 < mids> 16-23 year old linux kiddies?
-
            22:27 <@hezekiah> Well, I really don't care who uses it.
-
            22:28 < mids> or joe sixpack
-
            22:28 <@hezekiah> I would just want the people who make the nodes to make them securely.
-
            22:28 < Aprogas> maybe some lawyers to defend us
-
            22:28 <@hezekiah> Beyond that, I just want to make the program better by good coding.
-
            22:28 < Aprogas> if IIP is a proper program, it would take into account that not all nodes can be secure
-
            22:28 <@hezekiah> Nop does some userbase kind of stuff. He seems to understand it pretty well.
-
            22:29 < mids> what do you mean?
-
            22:29 < Aprogas> hezekiah is the true programmer, he is afraid of users
-
            22:29 <@hezekiah> Aprogas: IIP will do its best to be idiot proof, but the security of a system always comes down to the people who run it.
-
            22:29 <@hezekiah> Aprogas: I'm not affraid of users. I just don't really care too much _who_ they are.
-
            22:29 < mids> http://www.joelonsoftware.com/articles/StrategyLetterV.html
-
            22:30 <@hezekiah> mids: He does corporate stuff. Buisness kind of things. I still don't know how he got funding to hire Cap'n Crunch.
-
            22:30 < mids> no comment
-
            22:30 <@hezekiah> lol
-
            22:33 < mids> I got nothing to say anymore
-
            22:33 < mids> other questions?
-
            22:33 < Aprogas> how many developers does IIP have right now, and how many hours per week do those developers spend (estimated)
-
            22:33 <@hezekiah> Uh ..
-
            22:34 <@hezekiah> That's a trick question actually. :)
-
            22:34 < Aprogas> is it ?
-
            22:34 <@hezekiah> Which _kind_ of developers are you looking for?
-
            22:34 < Aprogas> i am not looking for developers
-
            22:34 < Aprogas> i just want to know how the IIP development is doing
-
            22:34 <@hezekiah> So you want to know about the developers who right isproxy?
-
            22:35 < Aprogas> IIP is more than just isproxy i guess
-
            22:35 <@hezekiah> Yeah.
-
            22:35 < Aprogas> i just want to know how many people are currently spending time on IIP
-
            22:35 <@hezekiah> That's why it's a trick question. :)
-
            22:35 <@hezekiah> Then I have no idea! :) Not all of them are probably public!
-
            22:35 < mids> how much time do you spend on IIP then?
-
            22:35 < Aprogas> never mind, ill just go watch the sf's actitivity meter i guess
-
            22:36 < Aprogas> if it has such information
-
            22:36 <@hezekiah> I can tell you that right now (to the best of my knowledge) there are really only two people actively writting code for the isproxy source.
-
            22:36 <@hezekiah> UserX and myself.
-
            22:36 < mids> *nod*
-
            22:36 < Aprogas> im not only talking about writing code
-
            22:36 <@hezekiah> Nop is doing stuff in the background when he can that deals with neat protocols and theory.
-
            22:36 < Aprogas> also about plannig stuff, for example that routing protocol
-
            22:36 < Aprogas> just the project as a whole
-
            22:36 <@hezekiah> OK ... this is an opensource project. The "developers" are anyone who pitches in an idea.
-
            22:37 <@hezekiah> lol
-
            22:37 < Aprogas> actually i want to know how many manhours are spent (wasted?) on IIP, so i can calculate how much money that represents
-
            22:37 <@hezekiah> A lot trickier to answer than you thought, eh?
-
            22:37 <@hezekiah> Well, I pretty much only know about work on isproxy.
-
            22:37 < Aprogas> ok
-
            22:37 <@hezekiah> That fluxuates based on how busy UserX and myself are.
-
            22:37 <@noP> aprogas you're being nit picky
-
            22:38 < Aprogas> its just that i want to know that if i were to donate money to this project, that i donate the right amount, not too much, not too little
-
            22:38 <@noP> if you're not on the dev team
-
            22:38 <@noP> then just don't waste your time
-
            22:38 <@hezekiah> For example, right now I am very busy in real life, so I haven't been able to touch the isproxy code for over a week! (Ack!)
-
            22:38 < Aprogas> so i want to know how much this project would `cost' in manhours
-
            22:39 <@hezekiah> On an average week where I can write code, I might get in 4-5 hours. That's a wild stab in the dark! UserX seems to code in spurts (no offense) having periouds where he doesn't have much time and then one week where there is a flurry of commits. (He might be coding the whole time and just committing when he has completed code. I really don't know.)
-
            22:39 <@hezekiah> Anyway, it's way to volatile for me to really get a handle on it.
-
            22:40 < Aprogas> ok
-
            22:41 < Aprogas> i have no more questions
-
            22:43  * mids ends the suffering
-
            22:43  * hezekiah hands mids the *baf*er
-
            22:44 -!- mode/#iip-dev [+o mids] by Trent
-
            22:44 -!- logger was kicked from #iip-dev by mids [*baf*]
-
            --- Log closed Tue Mar 25 22:45:02 2003
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting4.html b/www.i2p2/pages/meeting4.html
deleted file mode 100644
index 56c4c32c..00000000
--- a/www.i2p2/pages/meeting4.html
+++ /dev/null
@@ -1,428 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 4{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 4
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Jun 11 22:52:16 2002
-
            22:55 < logger> logging started
-
            22:55 <@mids> already?
-
            22:55 < logger> yes :)
-
            22:55 -!- mode/#iip-dev [+v logger] by mids
-
            23:23 < I> 23:23 @933.23
-
            23:23 < I> heh, evil time
-
            --- Day changed Wed Jun 12 2002
-
            00:09 -!- mode/#iip-dev [+oo UserX nop] by mids
-
            00:39 -!- mode/#iip-dev [+o codeshark] by nop
-
            00:39 <@mids> hey codeshark 
-
            00:39 <@codeshark> hey
-
            00:41 < UnDeRToW> hi, good night everybody
-
            00:41 <@nop> night
-
            00:49 <+BluePaperBoy> hi
-
            00:49 <+BluePaperBoy> did I miss the meeting yet?
-
            00:50 <@mids> Tue Jun 11 22:50:18 UTC 2002
-
            00:50 <@mids> almost
-
            00:50 <+BluePaperBoy> just in time :)
-
            00:55 <+BluePaperBoy> 4 minutes 20 seconds ;)
-
            00:56 <@nop> ok
-
            00:57 <+BluePaperBoy> sorry, just getting antsy :)
-
            00:58 <@nop> hehe
-
            00:59 <@mids> lets get started
-
            00:59 <@mids> first of all I want to congratulate UnDeRToW, he passed his exams
-
            01:00 <+BluePaperBoy> 0
-
            01:00 < UnDeRToW> :)
-
            01:00 <+BluePaperBoy> :)
-
            01:00 <@nop> awesome
-
            01:00 <+BluePaperBoy> it has begun :P
-
            01:00 <@mids> all the important docs are on http://mids.student.utwente.nl/~mids/iip/
-
            01:00 <+BluePaperBoy> err, my count down ended :P
-
            01:00 <@mids> this is the 4th meeting
-
            01:00 <@mids> it is public, and unmoderated as long as it isnt chaotic
-
            01:01 <@mids> if it become moderated, message an operator or somebody with voice, the line that you want to say
-
            01:01 <@mids> welcome :)
-
            01:01 <@nop> welcome all
-
            01:01 <@mids> a logfile is recorded
-
            01:01 <@mids> and available for everybody
-
            01:01 <@mids> including for those who are too late
-
            01:01 <@mids> .
-
            01:02 <@mids> got something to add nop ?
-
            01:02 <@nop> thnx you for all coming
-
            01:03 <@nop> and contributing to IIP as a user/tester, developer, or otherwise
-
            01:03 <@codeshark> i'm here
-
            01:03 <@nop> let's see what's on the agenda for today
-
            01:03 <@mids> 1) Welcome
-
            01:03 <@mids> 2) Network / Channel policies
-
            01:03 <@mids> 3) Website
-
            01:03 <@mids> 4) Documentation status
-
            01:03 <@mids> A) Questions?
-
            01:03 <@mids> B) Next meeting
-
            01:03 <@mids> attition: something about iip 1.1
-
            01:03 <@mids> (forgot to add that)
-
            01:03 <@mids> .
-
            01:04 <@nop> ok
-
            01:04 <@nop> 2 network / channel policies
-
            01:04 <@nop> mids if you would please
-
            01:04 <@mids> sure
-
            01:04 <@mids> we had something happening in #anonymous
-
            01:04 <@mids> I kind of missed it
-
            01:05 <@mids> but thanks to my big brother logging, I got to see it later
-
            01:05 <@mids> there was a little incident that showed us the need for some policies
-
            01:05 <@mids> since this network is going to become more serious
-
            01:05 <@mids> with more people attending
-
            01:05 <@nop> may I add something
-
            01:05 <@mids> the risk of possible conflicts is always there
-
            01:05 <@nop> ?
-
            01:05 <@mids> sure
-
            01:06 <@nop> The definitive goal of IIP
-
            01:06 <@nop> is to allow freedom of speech
-
            01:06 <@nop> and to fight censorship and oppression
-
            01:06 <@nop> now we all share this common goal
-
            01:06 <@nop> assuming
-
            01:06 <@nop> so there are moderators
-
            01:06 <@nop> for channels
-
            01:07 <@nop> which gives us a sense of power, but really, is very minimal control, banning anonymity is not exactly easy
-
            01:07 <@nop> but the purpose is to make sure everyone is not inhibited by their speech
-
            01:07 <@nop> and can say what they would like to say
-
            01:07 <@mids> as you maybe all know
-
            01:07 <@nop> so keeping this in mind
-
            01:08 <@nop> continue
-
            01:08 <@mids> 'we' dont often know what is going on on the network
-
            01:08 <@mids> exept for the public channels
-
            01:08 <@mids> inclusing #anonymous, but also #iip and #help
-
            01:08 <@mids> maybe I forgot more official channels, if so
-
            01:08 <@mids> inform me
-
            01:08 <@mids> because those channels kindof determine the public look of IIP, we need to get some rules done
-
            01:09 <@mids> why?
-
            01:09 <@mids> 2 reasons
-
            01:09 <@mids> tell the users what the operators can do
-
            01:09 <@mids> and visa versa
-
            01:09 <@mids> normally, on IIP, every channel
-
            01:09 <@mids> should be seen as a sovereign country
-
            01:09 <@mids> since there is almost none network wide power
-
            01:09 <@mids> every channel got to have its own rules
-
            01:10 <@mids> which can differ from channel to channel
-
            01:10 <@mids> if you have a channel names #sailing
-
            01:10 <@mids> we cant do nothing there
-
            01:10 <@mids> even if we hate the boat that you like to sail with :)
-
            01:10 <@mids> anyway
-
            01:10 <@mids> I want to propose some rules
-
            01:11 <@mids> 3 categories
-
            01:11 <@mids> 1) network wide
-
            01:11 <@mids> 2) #anonymous
-
            01:11 <@mids> 3) other official channels
-
            01:11 <@mids> for all other channels, we have no power as IIP team
-
            01:11 <@mids> except for the network rules
-
            01:11 <@mids> any questions so far?
-
            01:12 <@mids> nope?
-
            01:12 <@mids> great
-
            01:12 <@mids> I have thought of these 3 rules for the whole network:
-
            01:12 < ellison> seems to me that #iip should be protected as well
-
            01:12 <@mids> - no flooding
-
            01:12 <@mids> - no spamming
-
            01:13 < ellison> oh, 3)  other protected channels
-
            01:13 <@mids> - no acts that endanger the existance of IIP
-
            01:13 <@mids> .
-
            01:13 <@mids> ellison: yes?
-
            01:13 < ellison> nevermind, 'scuse me
-
            01:13 <@mids> np
-
            01:13 <+BluePaperBoy> acts that endanger the existance of IIP?  please clarify
-
            01:14 <@mids> sure
-
            01:14 <@mids> that is a pretty broad subject
-
            01:14 <@mids> but whatever happens here.. we shouldnt risk the continuity of IIP
-
            01:14 <@mids> some posibilities:
-
            01:14 <@mids> ddos attacks
-
            01:14 <@mids> child porn
-
            01:15 <@mids> terrorist cells etc
-
            01:15 <@mids> if we know about those things
-
            01:15 <@mids> we have to forbid them
-
            01:15 <@mids> because countries will attack us if we support such things
-
            01:15 < UnDeRToW> but how we control that?
-
            01:15 <@mids> good question
-
            01:16 < UnDeRToW> we cant spy other users
-
            01:16 <@mids> sure
-
            01:16 <+BluePaperBoy> we shouldn't atleast
-
            01:16 < ellison> ddos is a separate matter from the rest
-
            01:16 <@mids> but if such happens, without us knowing?
-
            01:16 <@mids> ellison: yes, correct.. ddos is more flooding
-
            01:16 < ellison> for child porn, terrorist cells, money laundering and other statust bugaboos, we should insist on proof from the entity complaining or threatening to shut down IIP
-
            01:18 <@mids> so if an entity comes with evidence about activity x
-
            01:18 <@nop> evidence that they have to prove that it is the specific user
-
            01:18 < ellison> yup
-
            01:19 <@mids> then we can nuke his trent accounts, jupe his nick etc
-
            01:19 < ellison> if the entity complaining has no power to harm IIP, we ignore them
-
            01:19 <@mids> but such claims should always be verified
-
            01:19 <+BluePaperBoy> if IIP is truly anonymous, how could that be proven and what steps could be taken to stop the person is question
-
            01:19 <@mids> ellison: exactly
-
            01:20 < ellison> if they can harm IIP, we insist on proof
-
            01:20 <@mids> BluePaperBoy: we can deal with nyms, not with real persons
-
            01:20 <+BluePaperBoy> mids: but then they can merely change their IIP identity and continue
-
            01:20 < ellison> if they meet the proof requirements, we delete their Trent accounts as you said, and then send a report to the entity which complained
-
            01:21 < ellison> BPB: yeah, that's the beauty of a pseudoanonymous system...
-
            01:21 <@mids> for the sake of the common IIP wealth, such complaints should be globally announced I think
-
            01:22 <@nop> agreed
-
            01:22 < ellison> BPB: say some soldiers in afghanistan discovered a computer with IIP logs which proved that terrorists were using IIP to communicate ebtween their cells
-
            01:22 <@mids> nop: what is the official email address for such things?
-
            01:22 <+BluePaperBoy> put on the website?
-
            01:22 < ellison> that would consistute proof, I think
-
            01:22 <@nop> iip@invisiblenet.net
-
            01:23 <+BluePaperBoy> ellison: be we would no not who it was or how to stop them
-
            01:23 < ellison> we'd have their nym names
-
            01:23 < ellison> and we could just delete their records from Trent (assuming they used Trent)
-
            01:23 <@mids> okay, governments and other entities should email their proof of misusage (pgp signed & encrypted ofcourse) to iip@invisiblenet.net
-
            01:23 < ellison> heh
-
            01:24 <@nop> we still have very little power
-
            01:24 <@nop> to stop them
-
            01:24 <@nop> and the most we can do
-
            01:24 <@nop> is prohibit them from using trent
-
            01:24 <@nop> etc
-
            01:24 <@nop> at least under that nym
-
            01:24 <@mids> ofcourse we will do that
-
            01:24 <@mids> whatever is in our power
-
            01:24 < ellison> (this inability to exert controlling censorship is part of the good design of IIP, IMHO)
-
            01:25 <@nop> it only gets better with age
-
            01:25 <@UserX> what do we do if entities try and demand logging?
-
            01:25 <@mids> UserX: they may join channels
-
            01:25 < ellison> remove IIP servers from their jurisdiction
-
            01:25 <@mids> and log all traffic
-
            01:25 <+BluePaperBoy> so IIP'll do like most governments and "officially condemn"
-
            01:26 <@nop> try being key operative word
-
            01:26 <@nop> the most logging that is taking place
-
            01:26 <@nop> is the irc clients
-
            01:27 <@nop> but the big concern is coercing or forcing a user to log
-
            01:27 <@mids> everybody should understand that he/she acts here as a nym
-
            01:28 <@mids> and every relationshop between his/her real identify and the nym is a possible danger on his anon/pseudo nymity
-
            01:29 <+BluePaperBoy> What about bad mouthing IIP and convincing people to leave/stop supporting...would that be considered "acts that endanger the existance of IIP" (just to clarify)
-
            01:29 <@nop> no
-
            01:29 <+BluePaperBoy> thank you
-
            01:29 <@nop> but 
-
            01:29 <@nop> it's not nice
-
            01:29 <@nop> ;)
-
            01:30 <+BluePaperBoy> I was just wondering how liberally mids' statement would be taken :)
-
            01:30 <@mids> ok
-
            01:30 <@mids> now we have another thing
-
            01:30 <@mids> maybe it is channel, maybe network wide
-
            01:30 <@mids> 'dont reveal the identify of others without permission'
-
            01:31 <+BluePaperBoy> I don't think that should be regulated
-
            01:31 <@nop> it's more of a request
-
            01:31 <@nop> not a regulation
-
            01:31 <@mids> maybe on a personal / per channel base?
-
            01:32 <@mids> ok, got network covered... lets move to #anonymous
-
            01:32 <@mids> what is the main purpose of this channel
-
            01:32 <@mids> and what is its name :)
-
            01:32 <@mids> personally I think that it is about freedom of speech
-
            01:32 <+BluePaperBoy> bash liberals?
-
            01:32 <@mids> & that is what IIP is about
-
            01:33 <@mids> so, I don't think that any additional rules are needed except for the network ones
-
            01:33 < Robert> .
-
            01:33 <@mids> with the suggestion to move offtopic stuff to the appropriate channels
-
            01:34 <@mids> freenet stuff may be discussed there
-
            01:34 <@mids> but should be not taken too seriouyd
-
            01:34 <@mids> serioud
-
            01:34 <@mids> err
-
            01:34 <@mids> whatever :)
-
            01:35 <@mids> if someone is doing / saying things that you dont like
-
            01:35 <@mids> consider using /ignore
-
            01:35 <@mids> (see your IRC client manual for more information)
-
            01:35 <@mids> other additions to #anonymous?
-
            01:35 < Neo>  /ignore #anonymous works pretty good for me :)
-
            01:36 <@mids> Neo: I think you mean /part #anonymous :)
-
            01:36 < Neo> :)
-
            01:36 <@mids> now the other official channels...
-
            01:36 <@mids> which do we have?
-
            01:36 <@mids> I think : #iip 
-
            01:36 <@mids> #iip-dev and #help
-
            01:37 <+BluePaperBoy> what about #freenet?
-
            01:37 <@mids> hm, since there is no real relationship between freenet and IIP, I think that that isnt an official matter
-
            01:38 < ellison> #terrorist-plots
-
            01:38 < ellison> ;-)
-
            01:38 <@mids> #freenet channel policies should be discussed with the #freenet founder and operators
-
            01:38 <@mids> -Trent(anon.iip)- The channel #terrorist-plots is NOT registered
-
            01:38 <@mids> ok
-
            01:38 <@mids> #iip is the main serious IIP channel
-
            01:38 <@mids> (imho)
-
            01:39 <@mids> so, stuff there should be related to IIP
-
            01:39 <@mids> and should be correct.. don't give incorrect info there
-
            01:39 <@mids> maybe same for #help
-
            01:39 <@mids> anyway
-
            01:39 <@mids> I got the hint that we are getting bored
-
            01:39 <@mids> :)
-
            01:40 <@mids> ,
-
            01:40 <@nop> ok
-
            01:40 <@nop> basically
-
            01:40 <@nop> no inhibiting people's speech
-
            01:40 <@nop> only time to regulate
-
            01:40 <@nop> is if others are inhibiting free speech
-
            01:40 <@nop> aka spamming
-
            01:40 <@nop> or flooding
-
            01:41 <@nop> and do not abuse operator powers to inhibit speech
-
            01:41 <@nop> got it
-
            01:41 <@nop> good
-
            01:41 <@nop> move on
-
            01:41 <@mids> yup
-
            01:41 <@mids> official thingL
-
            01:41 <@mids> reinstate cohesion
-
            01:41 <@nop> we will once we talk to him and review the rules
-
            01:41 <@nop> he should be re-instated
-
            01:41 <@mids> done
-
            01:42 <@mids> with level 2
-
            01:42 <@mids> over & out :)
-
            01:42 <@mids> 3) Website
-
            01:43 <@mids> --------
-
            01:43 <@mids> how is the design going?
-
            01:43 <+BluePaperBoy> ?
-
            01:43  * mids looks at the agenda
-
            01:43 <@mids> ellison: got something to say? :)
-
            01:44 < ellison> ah
-
            01:44 < ellison> working on it right now
-
            01:44 < ellison> looks cool, trust me.
-
            01:44 < ellison> ;-)
-
            01:44 <+BluePaperBoy> which "sample" is his
-
            01:44 <+BluePaperBoy> ?
-
            01:44 < ellison> I might have something to show by the end of the meeting - if not then, later tonight
-
            01:45 <@mids> another design (from tikk) is on http://www.nokhockey.com/scott/IIP/home2.htm
-
            01:45 <@mids> hm, nop, can you say something about "wear IIP? 
-
            01:47 <@nop> oh
-
            01:48 <@nop> hold please
-
            01:48 <@nop> on phone
-
            01:48 <@mids> ah
-
            01:48 <@mids> "if you cant wait till the IIP site is done and already want to show your passion with IIP : http://www.cafepress.com/invisiblenet
-
            01:48 <@mids> nop got some nice stuff there
-
            01:48  * mids bought some IIP tshirts :)
-
            01:49 <@nop> all funding goes to fund the project
-
            01:49 <@mids> but most goes to the cafepress guys :(
-
            01:49 <@mids> I want to have a black tshirt with a white IIP logo
-
            01:50 <@mids> if you know a way to get it... tell us :)
-
            01:50 < ellison> i want a black t-shirt with a black logo...
-
            01:51 <@mids> ellison: noted.. we will have them too :)
-
            01:51 < ellison> :-)
-
            01:51 <@mids> other comments?
-
            01:51 <+BluePaperBoy> I want something blue :)
-
            01:51 <@mids> BluePaperBoy: cool
-
            01:51 <@mids> I think that the logo's that Banks made are available
-
            01:51 <+BluePaperBoy> ...can't find anything though ;(
-
            02:07 -!- Topic for #iip-dev: Info, agenda, log : http://mids.student.utwente.nl/~mids/iip/ | Tuesday 23:00 UTC - http://e-store.invisiblenet.net
-
            02:07 [Users #iip-dev]
-
            02:07 [@codeshark   ] [ ellison] [ logger] [ Robert   ] [ UserX] 
-
            02:07 [@nop         ] [ epoch  ] [ mids  ] [ Rooster77] 
-
            02:07 [+BluePaperBoy] [ I      ] [ Neo   ] [ UnDeRToW ] 
-
            02:07 -!- Irssi: #iip-dev: Total of 13 nicks [2 ops, 0 halfops, 1 voices, 10 normal]
-
            02:07 -!- Irssi: Join to #iip-dev was synced in 1 secs
-
            02:07 < Neo> <UserX> A new protocol has now been implemented for IIP 1.1 details of it are at: http://mids.student.utwente.nl/~mids/iip/meeting4/iip11proto.txt
-
            02:07 < Neo> <UserX> this adds error detection and fixes problems introduced by the server having a static key
-
            02:07 < Neo> (4 the logger)
-
            02:08 < logger> gracia
-
            02:10 <@nop> ok
-
            02:10 <@nop> next
-
            02:10 < logger> 3,4]                                                                                      
-
            02:11 -!- mode/#iip-dev [+o mids] by Trent
-
            02:13 < UnDeRToW> ...
-
            02:14 <@mids> hmpf
-
            02:14 <@mids> sorry ppl
-
            02:14 <@mids> blaim the civ :)
-
            02:14 <@mids> did you all see the new network diagrams?
-
            02:14 <@nop> yes
-
            02:14 <@nop> links etc
-
            02:15 <@mids> question:
-
            02:15 <@mids> bigendian == network order?
-
            02:15 <@nop> big endian == byte order
-
            02:15 <@mids> byte order != network order?
-
            02:16 <@nop> ok
-
            02:16 <@nop> any questions
-
            02:16 <@nop> before we close the meeting
-
            02:16 < UserX> as i understand bigendian byte order is the network byte order
-
            02:16 <@mids> thanks UserX 
-
            02:17 -!- mode/#iip-dev [+o UserX] by mids
-
            02:17 < UnDeRToW> can we translate the isproxy too?
-
            02:18 <@mids> can you explain? windows, unix, docs?
-
            02:19 < UnDeRToW> the program to join here
-
            02:20 <@mids> how do such programs work? do they detect the language automatically?
-
            02:20 <@nop> locale I guess
-
            02:21 < UnDeRToW> or have different versions
-
            02:21 < UnDeRToW> spannish, french .....
-
            02:22 <@UserX> there are some hooks for adding translations (gettext style) to isproxy but no support for doing actual translations yet
-
            02:22 <@mids> I think that is a good thing.. certainly not for 1.1.. but to keep in mind, maybe 1.2 ?
-
            02:22 < UnDeRToW> great
-
            02:23 < UnDeRToW> and also a we have to start a FAQ
-
            02:23 <@mids> but, I think the work involved shouldnt underestimated... chinese characters sound complex to me
-
            02:24 <@mids> UserX: any idea how the windows i18n is?
-
            02:24 <@codeshark> you can use resource files on windows
-
            02:24 <@nop> chinese require double byte
-
            02:24 <@nop> unicode
-
            02:24 <@codeshark> yes
-
            02:24 <@UserX> mids: do you mean how hard it would be to do translation?
-
            02:24 <@mids> Rooster77 knows something about htat
-
            02:25 <@mids> UserX: no, more the unicode / utf8 support
-
            02:26 < Rooster77> Rooster77 is not fluent yet, but is working on it..
-
            02:27 <+BluePaperBoy> just give it to a chinese programmer ;)
-
            02:27 < Rooster77> good idea...!
-
            02:27 <@UserX> not that familar with it but as i understand you can select codepages for interpreting 8 bit characters
-
            02:28 <@mids> okay... more questions?
-
            02:30 < UnDeRToW> i need the new docs to update the translation
-
            02:30 <@mids> okay, while they are still under review, you can get them from the CVS
-
            02:30 < UnDeRToW> ok
-
            02:30 <@mids> do you know how to use CVS?
-
            02:30 <+BluePaperBoy> mids: are we stuck with that crappy iip logo?  What ever happend to the copyrighted casper pics?
-
            02:30 < UnDeRToW> yes
-
            02:30 <@mids> UnDeRToW: contrib/htmldoc/
-
            02:31 <@nop> which logo
-
            02:31 <@mids> UnDeRToW: thats where everything is
-
            02:31 <+BluePaperBoy> the two trenchcoat guys then the p
-
            02:31 < UnDeRToW> ok
-
            02:31 <+BluePaperBoy> ...on the clothing ;)
-
            02:31 <@mids> I like the new design
-
            02:32 < UnDeRToW> and the FAQ
-
            02:32 < UnDeRToW> we have to do one
-
            02:32 <@mids> UnDeRToW: banks started some faq items in the manual too
-
            02:32 < UnDeRToW> i see almost always the same quesitons
-
            02:32 < UnDeRToW> ok
-
            02:32 < UnDeRToW> i will take a look
-
            02:33 < UnDeRToW> last thing
-
            02:33 <@nop> k
-
            02:33 <@nop> I think we're done
-
            02:33 < UnDeRToW> i think
-
            02:34 < UnDeRToW> would be usefull to being able to change your trent password
-
            02:35 <@mids> ok
-
            02:35 < UnDeRToW> if you want to change you pass you have to drop the nick
-
            02:35 <@mids> would it be needed to enter it twice?
-
            02:35 < UnDeRToW> but if you drop you loose the channels
-
            02:35 <+BluePaperBoy> mids: that would be nice
-
            02:36 <@mids> I'll think about it :)
-
            02:37 <@mids> (no reason not to do it, just someone has to code it)
-
            02:37 <@nop> should be like 5 lines of code
-
            02:37 <@mids> well, 6
-
            02:37 <@mids> :)
-
            02:38 <+BluePaperBoy> so it'll be done within a year I guess :)
-
            02:38 <@mids> very likely
-
            02:39 <@nop> ok
-
            02:39 <@mids> remember me everydat
-
            02:39 <@mids> day
-
            02:39 <@nop> one thing
-
            02:39 <@nop> http://e-store.invisiblenet.net
-
            02:39 <@nop> support the project
-
            02:39 <@nop> will work on getting black on white
-
            02:39 <@nop> ellison
-
            02:39 <@nop> anything on website yet
-
            02:39 < ellison> hey,
-
            02:39 < ellison> about 1 hour away from something I'd be comfortable showing
-
            02:40 <@nop> ok
-
            02:40 <@nop> is it like just started
-
            02:40 <@nop> or is it fully functional 
-
            02:40 <@nop> the one you're showing
-
            02:40 <@nop> ?
-
            02:40 < ellison> this is a photoshop draft
-
            02:40 <+BluePaperBoy> are you hardcoding or cheating?
-
            02:40 < ellison> ?
-
            02:41 < ellison> it's quite a few steps away from a finished site, but I can break out the HTML for templates in a day or so once the design is finalized
-
            02:42 <@nop> ok
-
            02:42 <@nop> kewl
-
            02:45 <@mids> okay folks, I am going to sleep.. thanks for the patience  :)
-
            02:46 < UnDeRToW> me too
-
            02:46 < UnDeRToW> i have to wake up in 4 hours
-
            02:46 < UnDeRToW> :(
-
            02:46 < UnDeRToW> bye
-
            02:46 <+BluePaperBoy> bye
-
            03:08 < logger> logging ended
-
            --- Log closed Wed Jun 12 03:08:35 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting47.html b/www.i2p2/pages/meeting47.html
deleted file mode 100644
index 801a77d4..00000000
--- a/www.i2p2/pages/meeting47.html
+++ /dev/null
@@ -1,912 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Meeting 47{% endblock %}
-{% block content %}
            
-
            -->	You are now talking on #iip-dev
            
-
            ---	Topic for #iip-dev is IIP Meeting - logfiles:
            
-
            	  http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/
            
-
            <al-jebr>	it's 21:13
            
-
            <--	wilde has quit (Ping timeout)
            
-
            ---	Trent@anon.iip gives channel operator status to UserX
            
-
            <nop>	ok
            
-
            <qriff> !time
            
-
            <Ambience>	al-jebr: 00:21 here
            
-
            <nop>	I believe everyone has settled
            
-
            <hezekiah>	Let's go. :)
            
-
            <jrand0m>	11:06 here
            
-
            <nop>	let's start
            
-
            <nop>	anyone get my agenda
            
-
            <nop>	so they can play it back
            
-
            <nop>	I forgot the order
            
-
            <--	leenookx has quit (Ping timeout)
            
-
            <Ambience>	my clock is 15 minutes ahead :)
            
-
            -->	hifi (~MetroPipe@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	<nop> on the agenda
            
-
            <hezekiah>	<nop> 1) Welcome
            
-
            <hezekiah>	<nop> 2)Our Goodbyes
            
-
            <hezekiah>	<nop> 3)IIP development now
            
-
            <hezekiah>	<nop> 4) IIP development restructuring proposal
            
-
            <qriff> actually its xx:13 everywhere...
            
-
            <hezekiah>	<nop> 5) Recruiting for services to aid with IIP
            
-
            <hezekiah>	<-- Delly has quit (Ping timeout)
            
-
            <hezekiah>	<nop> 6) comments suggestions and people who want to help
            
-
            <mids>	23:05:28 <@nop> 1) Welcome
            
-
            <mids>	23:05:38 <@nop> 2)Our Goodbyes
            
-
            <mids>	23:05:43 <@nop> 3)IIP development now
            
-
            <mids>	23:05:56 <@nop> 4) IIP development restructuring proposal
            
-
            <mids>	23:06:16 <@nop> 5) Recruiting for services to aid with IIP
            
-
            <mids>	23:06:53 <@nop> 6) comments suggestions and people who want to help
            
-
            <nop>	wow, flood in here ;)
            
-
            <nop>	pl
            
-
            <LeerokLacerta> Out goodbyes?
            
-
            <hezekiah>	lol
            
-
            <hifi>	TROLLS !!!
            
-
            <nop>	Ok, welcome all
            
-
            <nop>	let's settle down now :)
            
-
            <hifi>	.
            
-
            <Ambience>	settled
            
-
            -->	wilde (~anon@anon.iip) has joined #iip-dev
            
-
            <hifi>	settled
            
-
            <al-jebr>	anyone logging?
            
-
            -->	thecrypto (~thecrypto@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	I am (sort of).
            
-
            <luckypunk>	mids should be.
            
-
            *	jrand0m logs at all times
            
-
            <al-jebr>	let's go!
            
-
            <nop>	ok
            
-
            <hezekiah>	nop: Agenda item number 2?
            
-
            <nop>	Our goodbyes
            
-
            <LeerokLacerta> Bye!
            
-
            <thecrypto>	where is the livelog?
            
-
            <nop>	Ok, mids has come to a point where he is moving to other projects
            
-
            -->	Phiberoptika (~none@anon.iip) has joined #iip-dev
            
-
            <mids>	After having worked for IIP for more than I year now, I have decided to
            
-
            	  resign as IIP developer.
            
-
            <LeerokLacerta> Awww.
            
-
            <mids>	It has been fun and an educative experience
            
-
            <mids>	but it is time to move on, refresh the spirit and shuffle the cards.
            
-
            <Rain>	Will you still be online/around?
            
-
            <mids>	I'll keep running Trent as long as needed and possible.
            
-
            <mids>	Yes, I do plan to stay around as user
            
-
            -->	ntk (~blob@anon.iip) has joined #iip-dev
            
-
            *	nop is in the corner sobbing
            
-
            <nop>	oh, ah hem
            
-
            <jrand0m>	many thanks mids, iip w/out trent would be a pita
            
-
            <LeerokLacerta> It's so sad.
            
-
            <nop>	yes
            
-
            <nop>	thank you mids for all your workup
            
-
            <nop>	work
            
-
            <mids>	Although I'll be off on vacation soon :)
            
-
            <mids>	.
            
-
            ---	mids removes channel operator status from mids
            
-
            <luckypunk>	:D
            
-
            <luckypunk>	Seem's like you've done a great job.  :)
            
-
            <Rain>	..how symbolic..
            
-
            <nop>	we love you mids!!!
            
-
            <nop>	you hear that
            
-
            <nop>	that was my window opening
            
-
            <thecrypto>	we all do!
            
-
            <nop>	fan base out there
            
-
            -->	w (~w@anon.iip) has joined #iip-dev
            
-
            ---	nop is now known as we
            
-
            <luckypunk>	lol, yep.
            
-
            <luckypunk>	:D
            
-
            *	we love you mids
            
-
            <Rain>	Go mids go!
            
-
            <jrand0m>	rofl
            
-
            -->	leenookx (~leenookx@anon.iip) has joined #iip-dev
            
-
            ---	LeerokLacerta has changed the topic to: IIP Meeting - logfiles:
            
-
            	  http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/
            
-
            	  | We love you mids!
            
-
            <Rain>	weeeeee are the chaaaampins, my frieeeennnndd...
            
-
            <Neo>	yes mids, thanks for all your input, collaboration and hard work in code
            
-
            	  and doing general developer things for IIP.
            
-
            ---	we is now known as nop
            
-
            *	mids bows
            
-
            *	Ehud stands up and gives a standing ovation to the commitment, perseverence,
            
-
            	  effort, and good hard code that mids has given the project.
            
-
            <hifi>	yeah mids take your toys and go to tigertown lol
            
-
            <nop>	and don't forget the PR and web management
            
-
            <nop>	he's been a vital aspect to IIP
            
-
            <nop>	getting it this far would have been hard without his work
            
-
            -->	ChZEROHag (hag@anon.iip) has joined #iip-dev
            
-
            <hifi>	hifi bitches with mids over trolling issue
            
-
            <--	hezekiah has quit (Ping timeout)
            
-
            <mids>	heh hifi
            
-
            -->	hezekiah (~hezekiah@anon.iip) has joined #iip-dev
            
-
            ---	Trent@anon.iip gives channel operator status to hezekiah
            
-
            <hezekiah>	Back. :)
            
-
            <luckypunk>	Yay.
            
-
            <hezekiah>	(And in case anyone doubted, Hezekiah == Ehud.)
            
-
            <hifi>	i never used frucking trent and don't know what mids did . i only troll .
            
-
            <nop>	obviously your hezekiah@anon.iip gave it away
            
-
            <--	Ehud has quit (Ping timeout)
            
-
            <hezekiah>	Ugh
            
-
            <hezekiah>	Item number 3?
            
-
            <hezekiah>	(If we're all done sobbing yet ...)
            
-
            <hifi>	and i never was pingouted in my life . I am the most disciplined user of
            
-
            	  IIP .
            
-
            <mids>	3)IIP development now
            
-
            <luckypunk>	heh
            
-
            <luckypunk>	Ok everyone!  Shhh.  Back on track!
            
-
            <hifi>	BUT I CRY that MIDS GO !!!
            
-
            <hifi>	ok
            
-
            <hifi>	.
            
-
            <luckypunk>	IIP development.  Whats the current status of that code snapshot
            
-
            	  release?
            
-
            <luckypunk>	That was supposed to happen today?
            
-
            <hezekiah>	Well, unless UserX has an objection to the tarball I made,
            
-
            	  it's done.
            
-
            <luckypunk>	Ok.  Post it on the wiki?
            
-
            <hezekiah>	UserX? Were there any problems with the tarball?
            
-
            <UserX> no problems with the tarball
            
-
            <luckypunk>	Yes, but are there any windows compilations?
            
-
            <hezekiah>	OK1
            
-
            <hezekiah>	http://invisiblenet.net/hezekiah
            
-
            <hezekiah>	Get your tarballs there!
            
-
            <UserX> there hasn't been a windows compilation on the windows version yet
            
-
            <luckypunk>	hm
            
-
            <LeerokLacerta> "tarballs" sound like some sort of food...
            
-
            *	luckypunk will try and make one.
            
-
            ---	hezekiah has changed the topic to: IIP Meeting - logfiles:
            
-
            	  http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/
            
-
            - tarballs of the 'unstable' development release are at
            
-
            	  http://invisiblenet.net/hezekiah | We love you mids!
            
-
            <luckypunk>	They are.  For GCC.
            
-
            <luckypunk>	lol
            
-
            <Rain>	Sticky food.
            
-
            <hezekiah>	There is one 'documented bug'.
            
-
            <nop>	I can compile a win32 version if you'd like
            
-
            <Rain>	So, could you give a quick describtion of what is new in this release?
            
-
            <hezekiah>	If you run isproxy, and it fails to bind the port, then it will
            
-
            	  /not/ abort. It will just sit there wasting memory.
            
-
            <hezekiah>	Rain: That's too much for me to handle (not to mention I don't
            
-
            	  even _know_ all the differences).
            
-
            <Ambience>	this one I assume: iip-1.2-dev1.tar.bz2    01-Jul-2003 01:45
            
-
            	  292k  tar archive ?
            
-
            <hezekiah>	UserX could give a much better description
            
-
            <hezekiah>	UserX?
            
-
            <nop>	hezekiah/UserX can we get a changelog of the differences by chance
            
-
            <nop>	that may be a day before that gets done
            
-
            <hezekiah>	Ambience: Yup! Or the Gziped one. There the same tarball.
            
-
            <nop>	because there are a log of changes
            
-
            <Rain>	Oh, and has the expired IIP signing-key been replaced?
            
-
            <Ambience>	hezekiah: ok
            
-
            <hezekiah>	nop: I joined IIP after the development branch was already in
            
-
            	  progress.
            
-
            -->	Ehud (~hezekiah@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	Rain: No. I had to use my GPG key.
            
-
            <nop>	no one has tested the compile of this dev branch in win32 have they?
            
-
            <luckypunk>	Hey, is this src is CVS?
            
-
            <hezekiah>	Rain: I couldn't contact anyone who had the IIP release key.
            
-
            <hezekiah>	luckypunk: Yes.
            
-
            *	luckypunk has, but his system didn't work for it.
            
-
            <Rain>	hezekiah: Ok, roger.
            
-
            <UserX> changes: multi-threading,  bignum support via openSSL or GMP, numerous
            
-
            	  inmprovements to the memory management system
            
-
            <hezekiah>	luckypunk: Right now that tarball is a copy of what you get when
            
-
            	  you check out the hezekiah-dev branch from CVS and run 'make dist-bzip2'.
            
-
            <luckypunk>	Gah!  I hate windows.
            
-
            <Rain>	UserX: niceties ;)
            
-
            <hezekiah>	And of course there are other internal changes that only the
            
-
            	  developers see. :)
            
-
            <qriff> just as a question for the qurious... what defines the holder for "Trent"...
            
-
            <hezekiah>	One simple thing is that now that BigNum is implemented using
            
-
            	  either GMP or SSL, login is a LOT faster.
            
-
            <Rain>	May i mention a IIP quirk i noticed earlier today?
            
-
            *	luckypunk guesses its a yes.
            
-
            <hifi>	at wiki search button is absent . only window to type in but nowhere to
            
-
            	  click lol .
            
-
            <luckypunk>	hit enter.
            
-
            <qriff> and what about channel/nick expiration...
            
-
            ---	Ehud is now known as logger
            
-
            <qriff> registration that is...
            
-
            <Rain>	Ok, it seems to me like you cannot start isproxy from a /path/to/isproxy
            
-
            	  command, but intead have to do a cd /path/to and then do a ./isproxy
            
-
            <hezekiah>	Rain: Let me guess ... you get a configuration screen or a request
            
-
            	  for entropy, right?
            
-
            *	jrand0m has a feeling this will be a very.long.meeting
            
-
            <Rain>	Is that intentional, or just some quirk of my local system?
            
-
            <Rain>	hezekiah: yes.
            
-
            <hezekiah>	Rain: You need to make a .iip subdirectory in your home directory.
            
-
            <Rain>	It claims that the conf-file is not found.
            
-
            <Rain>	with my .conf file?
            
-
            <hezekiah>	Rain: If no such directory exists, isproxy will always look for
            
-
            	  the config files in the current directory
            
-
            -->	AmishOne (amishone@anon.iip) has joined #iip-dev
            
-
            <Rain>	Ahh. Of course.
            
-
            <hezekiah>	OK ...
            
-
            <hezekiah>	nop? Was there anything else for item 3?
            
-
            <nop>	have we tested it for win32
            
-
            <nop>	compile wise
            
-
            <hezekiah>	I haven't.
            
-
            <nop>	UserX: ?
            
-
            <UserX> no
            
-
            <nop>	I will test it this week then
            
-
            <hezekiah>	luckypunk, tried doing hezekiah-dev recently and complained for
            
-
            	  compile errors.
            
-
            <nop>	that's key to maintain portability
            
-
            <hezekiah>	I suspect there might be problems.
            
-
            *	luckypunk tried, it balked.
            
-
            <hezekiah>	Yup. There are problems.
            
-
            <Ambience>	I'll have to leave for the more dominant one is ordering me to
            
-
            	  and I have no choice here. So I'll be off to bed, but will be logging #iip-dev
            
-
            	  for future reference.
            
-
            <Ambience>	see ya guys!
            
-
            <lonelynerd>	later
            
-
            <qriff> bye
            
-
            <hezekiah>	Bye, Ambience. :)
            
-
            <luckypunk>	i'll be back.
            
-
            <Ambience>	<--gone (log on)
            
-
            <nop>	ok
            
-
            <nop>	this topic is done
            
-
            <nop>	next on agenda
            
-
            <nop>	what's 4?
            
-
            <hezekiah>	4) IIP development restructuring proposal
            
-
            <nop>	ok
            
-
            <nop>	we had a meeting about a discussion and proposal brought to us by jrand0m
            
-
            	  for the future development
            
-
            <nop>	and as well
            
-
            <nop>	I have had a lot of privmessages directed at me
            
-
            <nop>	for requests to focus on an arbitrary framework, instead of IRC specific
            
-
            <nop>	aka a framework that supports IRC + a whole lot more
            
-
            <nop>	so the want is obviously there
            
-
            <nop>	and the developers definitely want to go there as well
            
-
            <hezekiah>	Amen!
            
-
            <nop>	the question of how to go about doing it
            
-
            <nop>	and how to make the most productive use of our developers
            
-
            <nop>	is up in the air
            
-
            <ChZEROHag>	XML
            
-
            <mids>	is his framework site available to everybody?
            
-
            <nop>	this isn't specifically about language
            
-
            <ChZEROHag>	create a communications protocol
            
-
            <nop>	ok, please let me finish
            
-
            <ChZEROHag>	I've started on that somewhere...
            
-
            <nop>	then we can comment
            
-
            <ChZEROHag>	My apologies
            
-
            <ChZEROHag>	I'm a bit in and out at the moment
            
-
            <nop>	ok,
            
-
            <nop>	no prob
            
-
            <nop>	We are at a stage where there is discussion of an arbitrary communications
            
-
            	  protocol
            
-
            <nop>	specifically for anonymous and secure communication
            
-
            <nop>	at this point jrand0m, any chance we can post the logs of #iip-future
            
-
            	  meeting
            
-
            <jrand0m>	sure
            
-
            <jrand0m>	perhaps those zips I sent you so people don't have to struggle
            
-
            	  through freenet for the other pages too
            
-
            <nop>	ok
            
-
            <nop>	hold
            
-
            <nop>	please
            
-
            <jrand0m>	(btw, the logs were unedited, so expect the usual occational banter)
            
-
            <hezekiah>	lol. Yup! You'll get to see exactly how much I DON'T know about
            
-
            	  p2p networks! lol
            
-
            <jrand0m>	heh
            
-
            <hezekiah>	(And they'll probably have my conspiracy theories about nop
            
-
            	  too! So be sure to read the logs! ;-) )
            
-
            <--	logger has quit (Ping timeout)
            
-
            <hezekiah>	Ugh
            
-
            <nop>	ok
            
-
            <Neo>	the logs will be a lot to read. can someone summarizze for the meeting
            
-
            	  what was covered and some key points of all this?
            
-
            <nop>	http://office.invisiblenet.net/iip_future.zip
            
-
            <nop>	and
            
-
            <hezekiah>	At this point, the 'stable' release is being more unstable than
            
-
            	  the 'unstable' one!! Urg.
            
-
            <nop>	http://office.invisiblenet.net/meetingPrepnotes.zip
            
-
            <nop>	http://office.invisiblenet.net/jrand0mnetwork_protocol.txt
            
-
            <jrand0m>	meetingPrepnotes.zip is a small doc that summarizes the meeting,
            
-
            	  and the meeting was basically "ok, any thoughts?".
            
-
            <--	Delly has quit (EOF From client)
            
-
            <jrand0m>	essentially, the proposal is to get going on a generic secure
            
-
            	  anonymous message based system, and run iip on top of that
            
-
            <mids>	is there a zip with anonCommFramework too?
            
-
            <nop>	I didn't see that
            
-
            <nop>	jrand0m can you zip and send I'll post to site
            
-
            <jrand0m>	sure, h/o
            
-
            <--	Phiberoptika has quit (* ciaito mua mua *)
            
-
            <Neo>	what is anonCommFramework?
            
-
            <jrand0m>	uber-quick summary of the meeting in iip_future.zip is "ok,
            
-
            	  here's the proposal, any comments?" and comments were basically "ok, can IIP work
            
-
            	  as planned on this?
            
-
            <jrand0m>	if you're on freenet, anonCommFramework is at
            
-
            	  SSK@MQNd5lT-X5wHA4vONvtVadi6q1IPAgM/anonCommFramework/2//
            
-
            *	jrand0m is sending nop a zip of that momentarily
            
-
            <Rain>	Did you discuss support for PGP-based nyms?
            
-
            <nop>	ah hem, this is early discussions
            
-
            <--	ChZEROHag has quit (Ping timeout)
            
-
            <jrand0m>	no, endpoints in the framework are not nym based, they're idents
            
-
            <Rain>	Right. So nyms an higher level.
            
-
            <Rain>	are
            
-
            <jrand0m>	(and for lots of reasons, they shouldn't be long term idents
            
-
            	  like nyms)
            
-
            <jrand0m>	yes
            
-
            <Rain>	I was just thinking of something like trent with PGP signarute auth.
            
-
            <mids>	trent is central
            
-
            <mids>	central=bad
            
-
            -->	logger (~hezekiah@anon.iip) has joined #iip-dev
            
-
            <jrand0m>	briefly, anonCommFramework is a meta-network.  a generic set
            
-
            	  of protocols & structures that an anonymous communication network could use to
            
-
            	  interoperate to provide militant grade anonymity
            
-
            <wilde> what's the one sentence explanation of your ideas on network topology?
            
-
            -->	ChZEROHag (~hag@anon.iip) has joined #iip-dev
            
-
            <ChZEROHag>	that was fun
            
-
            -->	Delly (dedede@anon.iip) has joined #iip-dev
            
-
            <Rain>	mids: Yea. I meant similar services.
            
-
            <lonelynerd>	what about having to pay with hashcash to send data? couldn't
            
-
            	  that help against flooding?
            
-
            <jrand0m>	wilde> heterogeneous.  no one answer solves all problems.
            
-
            	  interoperate, balancing latency, bandwidth, anonymity, and reliability to provide
            
-
            	  the user's needs
            
-
            <Delly> still in 4) ?
            
-
            <hezekiah>	Delly: Yup
            
-
            <Delly> thx
            
-
            <ChZEROHag>	I think when the ircd is removed from the equation, we'll have
            
-
            	  far better options than (hash|think|real)cash
            
-
            <nop>	jrand0m: any luck sending
            
-
            <nop>	;)
            
-
            <jrand0m>	uploading to hush now.
            
-
            <jrand0m>	ChZEROHag> anonCommFramework has built in support for providing
            
-
            	  network use authorization credentials
            
-
            <Rain>	There has been a lot of talk of IIP-Freenet interoparability. Will that
            
-
            	  fit into the framework, or are we talking application-level again?
            
-
            <ChZEROHag>	come again?
            
-
            <jrand0m>	app level
            
-
            <jrand0m>	what we're discussing is splitting iip into two parts - the irc
            
-
            	  part, and the message based secure anonymous network
            
-
            <wilde> one solution could be:
            
-
            <Rain>	jrand0m: k.
            
-
            <wilde> Application <-> SOCKS5 Proxy Interface <-> Onion Wrapper <-> Onion Router
            
-
            	  1 <-> ... <-> Onion Router N <-> Exit Relay <-> Public Server
            
-
            <jrand0m>	building a DHT on top of the message layer should be fairly easy
            
-
            <hezekiah>	DHT?
            
-
            <jrand0m>	distributed hash table
            
-
            <jrand0m>	(ala freenet)
            
-
            <nop>	ok, jrand0m let me clarify
            
-
            <ChZEROHag>	wilde: I think the plan is to design it such that the 'public
            
-
            	  server' could be removed from the equation at some point
            
-
            <nop>	are we talking about splitting irc, or merging to focus on anonymity
            
-
            	  framework
            
-
            <jrand0m>	well, given unlimited # of developers, splitting and doing both
            
-
            	  (well, 3 things ;) in parallel.
            
-
            <nop>	what I mean is that the irc part is application layer
            
-
            <jrand0m>	given reality, there's prolly only enough dev time to get the
            
-
            	  comm system running first, then iip on top
            
-
            <jrand0m>	right exactly
            
-
            <nop>	and since we have a somewhat viable network working with IIP
            
-
            <jrand0m>	irc is just another app running on it
            
-
            <nop>	then the idea should be
            
-
            <nop>	is to have developers start focusing on framework aspects
            
-
            <wilde> ChZEROHag: ok, what I suggested is an anonymizing layer for regular
            
-
            	  internet traffic, not a seperate network
            
-
            <hezekiah>	(This could get fun.)
            
-
            <nop>	wilde there are weaknesses to that
            
-
            <nop>	just to let you know
            
-
            <nop>	aka the clear text on the outer ends
            
-
            <--	AmishOne has quit (EOF From client)
            
-
            <wilde> nop: yes, so all connections should be encrypted to the ends
            
-
            <nop>	we have an effort as well to have anonymous web browsing possible with
            
-
            	  this network
            
-
            <jrand0m>	yes.  it must be able to operate without ever leaving the mixnet
            
-
            <nop>	but it is not as real time direct as your proposal wilde
            
-
            <nop>	it uses some time delay tactics
            
-
            <nop>	with caching etc
            
-
            <nop>	timing attacks are a serious threat to anonymity
            
-
            <hifi>	I WANT ANONYMISER BASED on IIP !! I DON"t TRUST OTHER ANONYSERS THEY ARE
            
-
            	  FBI TRAPs !!
            
-
            <mids>	http://mids.student.utwente.nl/~mids/anonCommFramework/
            
-
            <nop>	hifi, this isn't changing IIP, this is moving us forward
            
-
            <nop>	thanks mids
            
-
            <jrand0m>	heh word mids, my moz is hanging
            
-
            <nop>	ok
            
-
            <wilde> although independant mixnets are cool, the real killer apps will probably
            
-
            	  be general ip traffic anonymizers
            
-
            <nop>	wilde, they are myths
            
-
            <wilde> killer apps?
            
-
            <nop>	no
            
-
            <--	thetower has quit (EOF From client)
            
-
            <jrand0m>	wilde> that could be a service built on top of the comm layer
            
-
            <nop>	general ip traffic anonymizers
            
-
            <wilde> or ip traffic anonymizers?
            
-
            <nop>	so far they don't exist
            
-
            <nop>	they exist in papers only
            
-
            -->	thetower (none@anon.iip) has joined #iip-dev
            
-
            <jrand0m>	if you build an anonymizing service on top of the comm layer,
            
-
            	  however, your outbound routers will get shut down quickly
            
-
            <thetower>	Haha, I just noticed I wasn't port forwarding.
            
-
            <thetower>	Oop, sorry, wrong chan
            
-
            <wilde> nop: what about the ZKS system?
            
-
            <nop>	is it still around?
            
-
            <nop>	and working
            
-
            <wilde> nope, bad business
            
-
            <wilde> few people paid
            
-
            <wilde> but the framework seemed to work, but all nodes were ZKS:s paid relays
            
-
            <nop>	wilde but they were internal and it wasn't complete
            
-
            <nop>	it still had certain vulnerabilities
            
-
            <nop>	it was a start
            
-
            <nop>	I met Ian Goldberg at CodeCon 2k2, and he himself admitted it was incomplete
            
-
            	  to what he desired
            
-
            <wilde> yes, everything has vulnerabilities, we just raise the cost of tracing
            
-
            	  dramatically
            
-
            <jrand0m>	right, after the mixnet is up and running, i'd like to see wilde
            
-
            	  offer generic outbound proxy services.	that'd be cool
            
-
            <jrand0m>	(sincerely)
            
-
            <nop>	jrand0m: but again the ultimate would be using that magic mirror concept
            
-
            	  for optimum protection
            
-
            <ChZEROHag>	Probably the hardest option, but wouldn't freenet be a good
            
-
            	  framework to build from?
            
-
            <nop>	wilde, maybe you and I can discuss this in another forum at some point
            
-
            <jrand0m>	but in any case, the network must be built first
            
-
            <ChZEROHag>	Or is that not what we're discussing?
            
-
            <jrand0m>	ChZEROHag> no.
            
-
            <jrand0m>	freenet doesn't provide hard anonymity
            
-
            <ChZEROHag>	aah
            
-
            <ChZEROHag>	I should try paying attention
            
-
            <nop>	ok, moving forward
            
-
            <nop>	UserX you still here
            
-
            <wilde> nop: yes, if you have decided on topology there is no need to discuss
            
-
            	  this in public
            
-
            <UserX> I'm still here
            
-
            <nop>	well it's application layer, so that comes after net design etc
            
-
            <nop>	ok
            
-
            <nop>	where did we leave off at #iip-future meeting
            
-
            <--	hezekiah has quit (Ping timeout)
            
-
            <nop>	let's start there
            
-
            ---	logger is now known as Ehud
            
-
            *	nop is catching up on the meeting logs
            
-
            <jrand0m>	[04:31] <jrand0m> I think we're back to your question.	can /
            
-
            	  should the irc functionality move forward as its going or move towards this mixnet.
            
-
            	  there are significant benefits to move towards the mixnet, but some aspects of
            
-
            	  the irc side seem to require some redesign to operate on it.
            
-
            <jrand0m>	[04:31] <jrand0m> the right way for the irc development to go is
            
-
            	  not for me to say
            
-
            <Ehud>	Basically, UserX had some thinking to do about wether IIP could run
            
-
            	  satisfactorily on the mixnet.
            
-
            <mids>	nite all
            
-
            <--	mids (mids@anon.iip) has left #iip-dev (mids)
            
-
            <ChZEROHag>	Would it not be an idea to create a replacement irc in parallel
            
-
            	  with a mixnet?
            
-
            <ChZEROHag>	After all it's going to be damn hard to use a normal ircd
            
-
            <jrand0m>	ChZEROHag> given infinite # devs, yes
            
-
            <nop>	ok ChZEROHag silence please :)
            
-
            <ChZEROHag>	Assume infinite devs
            
-
            <ChZEROHag>	Oh is this not a question bit?
            
-
            -->	hezekiah (hezekiah@anon.iip) has joined #iip-dev
            
-
            <nop>	not yet
            
-
            <UserX> Unfortuantlely I haven't had time to seriously sit down and think about
            
-
            	  how your proposal would fit in with IIP
            
-
            <ChZEROHag>	oh
            
-
            <ChZEROHag>	oops
            
-
            <nop>	just want to get into the discussion
            
-
            <nop>	well
            
-
            <jrand0m>	UserX> think of the mixnet as a socket
            
-
            <nop>	let me suggest something
            
-
            <nop>	do we agree that our goal is not just IRC ?
            
-
            <lonelynerd>	well
            
-
            <Delly> it's a great idea sure
            
-
            <hezekiah>	nop: Beyond all doubts, I agree that the goal is an anonymous
            
-
            	  network.
            
-
            <lonelynerd>	doing something traffic-intensive would have the potential to
            
-
            	  ruin the whole project
            
-
            <hezekiah>	nop: IRC is just a starting point.
            
-
            <nop>	ok, well what we should look at is this
            
-
            <jrand0m>	NOT doing something traffic intensive has the potential to get
            
-
            	  us to overlook problems :)
            
-
            <nop>	instead of saying IIP doesn't fit
            
-
            <nop>	or it does fit
            
-
            <nop>	let's look at what modifications need to be made for irc to fit with this
            
-
            	  mixnet, whether it's a mod to the mixnet itself
            
-
            <lonelynerd>	jrand0m: hmm
            
-
            <nop>	for instance
            
-
            <nop>	UserX has a vision of using channels as endpoints
            
-
            <nop>	Jrand0m calls them idents
            
-
            <nop>	are they having subtle differences
            
-
            <nop>	or are they largely different
            
-
            <jrand0m>	there's substance to those differences.
            
-
            <nop>	can we review that
            
-
            <nop>	on both sides
            
-
            <nop>	from jrand0m and UserX
            
-
            <--	hezekiah has quit (EOF From client)
            
-
            <nop>	actually
            
-
            <nop>	read the log
            
-
            <nop>	nevermind
            
-
            <jrand0m>	;)
            
-
            -->	hezekiah (hezekiah@anon.iip) has joined #iip-dev
            
-
            <jrand0m>	the hesitancy I have w/ sending messages to a channel ident and
            
-
            	  having that channel redistribute it to members is that the channel gets plaintext
            
-
            <nop>	how does it get plaintext?
            
-
            <jrand0m>	instead, I'd suggest having a channel contain just the channel info
            
-
            	  (modes, users, topic, etc)
            
-
            <jrand0m>	the channel is just an application running on one (well, 3+)
            
-
            	  routers listening to one (well, 3+) identities.  when you /msg a channel, you
            
-
            	  send a message to that identity (application).	it then resends it out to the N
            
-
            	  users in the channel, encrypted to each
            
-
            <nop>	well
            
-
            <nop>	I had a proposal for that
            
-
            <nop>	that would have the channel not contain plaintext
            
-
            <nop>	directly
            
-
            <jrand0m>	at least, without adding a channel key (which would be managed
            
-
            	  by the channel application itself, which defeats the point)
            
-
            <nop>	well
            
-
            <nop>	we were having channel keys
            
-
            <nop>	for private channels
            
-
            <nop>	and pub channels are public anyway
            
-
            <jrand0m>	right.	there may be ways around it.  y'all know more about irc
            
-
            	  than I do.  there are other ways that don't require going this route though
            
-
            <nop>	see the neat thing with message channels is this
            
-
            <nop>	you scale slightly better than trying to find all idents to send to directly
            
-
            <--	luckypunk has quit (Ping timeout)
            
-
            -->	dd0c (dd0c@anon.iip) has joined #iip-dev
            
-
            <jrand0m>	I'm not sure you scale better, but you do redistribute the load
            
-
            <jrand0m>	(we can find idents via O(log(n)))
            
-
            -->	sahara (~sahara@anon.iip) has joined #iip-dev
            
-
            <jrand0m>	but thats neither here nor there, this is application layer
            
-
            	  design ;)
            
-
            <nop>	right
            
-
            <jrand0m>	all we need to do, imho, is find some workable ways that *could*
            
-
            	  operate on the comm layer and then leave it to the wayside until we get there
            
-
            <UserX> jrand0m: messages sent to channels are encrypted with a channel key that
            
-
            	  is different to the channel's identity. a channel server can't decrypt a message
            
-
            	  unless it has come across the key by othermeans
            
-
            <sahara>	did I miss the meeting?
            
-
            <jrand0m>	you've got some ways that could work, it sounds like, right?
            
-
            <jrand0m>	UserX> how does a user joining a channel get the key?
            
-
            <hezekiah>	sahara: Nope. You're right in the middle of it! :)
            
-
            <nop>	it's a key exchange
            
-
            <jrand0m>	with whom nop?
            
-
            <jrand0m>	brand new user joining #anonymous, and the app containing the
            
-
            	  list of users on #anonymous doesn't have the key (As userx said)
            
-
            <jrand0m>	(all I'm saying is there's a way to get all the functionality
            
-
            	  and still avoid having a channel key)
            
-
            <UserX> jrand0m: with public channels it is derived from the channel name. with
            
-
            	  private channels the user either creates one or a someone gives them the keys to
            
-
            	  the channel
            
-
            <jrand0m>	'k, cool
            
-
            <jrand0m>	so apps managing public channels can read the plaintext (by
            
-
            	  deriving from the channel name)
            
-
            <jrand0m>	(which is prolly fine)
            
-
            <nop>	right
            
-
            <wilde> jrand0m: if the apps encrypt the plaintext to each recepient, will it
            
-
            	  scale well?
            
-
            <jrand0m>	yes wilde, perhaps better (depending on the algorithm used to
            
-
            	  nominate channel managers)
            
-
            <jrand0m>	(though it will potentially have a nonserialized delivery)
            
-
            <jrand0m>	((though i think thats the case with normal irc anyway))
            
-
            <--	thecrypto has quit (Ping timeout)
            
-
            <jrand0m>	but, getting back on to the question -
            
-
            <jrand0m>	nop, what do we hope to have decided by the end of the discussion
            
-
            	  of #4?
            
-
            <--	Neo has quit (Ping timeout)
            
-
            -->	d (~sahara@anon.iip) has joined #iip-dev
            
-
            <nop>	well
            
-
            <--	sahara has quit (EOF From client)
            
-
            <hifi>	simple site , problem is i am tech blond but want good things lol
            
-
            <nop>	I was hoping that we could re-organize, but this is gonna be a discussion
            
-
            	  for later
            
-
            <hifi>	sorry OOPS
            
-
            <nop>	UserX
            
-
            <--	d has quit (Client exiting)
            
-
            <nop>	how long will you need to think about certain aspects, and maybe doc them
            
-
            	  up as a concern list
            
-
            <UserX> hard to say. maybe a week
            
-
            <nop>	what I'm thinking jrand0m is that a lot of this needs sorting out, rather
            
-
            	  than just plowing into it, or we'll end up at the beginning with nothing to show
            
-
            <nop>	so let's push a week into this
            
-
            <nop>	and see what concerns are coming into play
            
-
            <nop>	because again
            
-
            <nop>	we want an adaptable mixnet
            
-
            <nop>	any application should be able to survive
            
-
            <jrand0m>	absolutely
            
-
            <jrand0m>	thats the point of the anon comm framework
            
-
            <--	wilde has quit ()
            
-
            <nop>	ok, so let's put this off a week, and focus on some realistic proposals
            
-
            	  that can fit all of our needs
            
-
            <jrand0m>	you say "send message M to location L" and it magically, securely,
            
-
            	  anonymously gets delivered
            
-
            <nop>	but magic is one thing
            
-
            <nop>	science is another
            
-
            <nop>	of course you know that :)
            
-
            <jrand0m>	the magic is from the app level's perspective ;)
            
-
            <nop>	yes
            
-
            <nop>	understood
            
-
            <jrand0m>	the science is in that 15 page anonCommFramework/2// ;)
            
-
            <nop>	ok
            
-
            <hezekiah>	lol
            
-
            <nop>	UserX, if you can get that in a week that would be helpful
            
-
            <nop>	?
            
-
            <jrand0m>	I'll aim at revamping the docs & getting comm layer network design
            
-
            	  ready for then so we can hit the ground running
            
-
            <nop>	well
            
-
            <nop>	we haven't agreed on certain aspects
            
-
            <nop>	I think that still should be hashed out
            
-
            <jrand0m>	what, in the network layer, haven't we agreed on?
            
-
            <nop>	personally I agree that maybe you post your anonCommFramework on iip-dev
            
-
            <nop>	and have it reviewed and commented
            
-
            *	jrand0m isn't on iip-dev
            
-
            <Rain>	So, meeting again next tuesday, same bat-time, same bat-channel?
            
-
            <nop>	what haven't we agreed on is whether it can support all applications
            
-
            <hezekiah>	jrand0m: Just post to iip-dev@invisiblenet.net .
            
-
            <hezekiah>	Rain: We are on item #4. There are still other items to go. :)
            
-
            <jrand0m>	its ~800k.  if someone could post the URL to mids' mirror that'd
            
-
            	  be cool
            
-
            <Delly> argh
            
-
            <Delly> re
            
-
            <Delly> about services, i think if IIP become more easier and friendly, we will see
            
-
            	  more users and more nodes. it's why i'm making script for mIRC user, one is a Trent
            
-
            	  script, allowing to use Trent and Anonymail with the mouse, the other is a script
            
-
            	  allowing to transfer file over iip, staying anonymous (using uuencoding). The
            
-
            	  "protocol" used is easy and could be done for lot's irc clients with scripting
            
-
            	  support. And so everybody could transfer little files, even between di
            
-
            <jrand0m>	nop> I'm 100% certain it can support all applications.
            
-
            <Rain>	hezekiah: Right. My missunderstanding.
            
-
            <jrand0m>	this layer has been used for over a decade in hundreds of industries
            
-
            <Delly> was my thought of the day
            
-
            <nop>	well then where do we not agree
            
-
            <nop>	if Irc is an issue, then how is it adaptable?
            
-
            <jrand0m>	it isn't an issue
            
-
            <jrand0m>	y'all just don't understand the layer's abstraction ;)
            
-
            <lonelynerd>	Delly: i have a perl script that allows one to use ssh/telnet/etc
            
-
            	  over irc
            
-
            <jrand0m>	(really, think of it as a socket)
            
-
            <Delly> lonelynerd, the goal was just to enhance mirc
            
-
            <Delly> for iip network
            
-
            <lonelynerd>	Delly: yeah, but if you use base64, i think it's compatible with
            
-
            	  this one
            
-
            <Delly> could be possible tu use it
            
-
            <jrand0m>	ok, we ready for #5 yet?
            
-
            <hezekiah>	nop?
            
-
            <--	hezekiah has quit (Client exiting)
            
-
            <Delly> oups i thought it was 5)  !
            
-
            <ChZEROHag>	There's a 5?
            
-
            -->	hezekiah (hezekiah@anon.iip) has joined #iip-dev
            
-
            <--	hezekiah has quit (Client exiting)
            
-
            -->	hezekiah (hezekiah@anon.iip) has joined #iip-dev
            
-
            <nop>	sorry
            
-
            <nop>	delly
            
-
            <nop>	you guys
            
-
            <nop>	this is off topic
            
-
            <nop>	please reserve your conversation outside this channel
            
-
            -->	hezekiah_ (~hezekiah@anon.iip) has joined #iip-dev
            
-
            <--	hezekiah has quit (EOF From client)
            
-
            <nop>	well
            
-
            <nop>	jrand0m
            
-
            ---	hezekiah_ is now known as hezekiah
            
-
            <nop>	before I agree to go to 5
            
-
            <nop>	the problem I'm seeing is
            
-
            <nop>	UserX has a voice
            
-
            <nop>	as well
            
-
            ---	Trent@anon.iip gives channel operator status to hezekiah
            
-
            <jrand0m>	of course
            
-
            <nop>	and if he sees logistical problems
            
-
            <nop>	I believe they should be heard
            
-
            <nop>	so you can't just say, hey it's gonna work
            
-
            <nop>	it has to be "solidly" agreed on both ends
            
-
            <nop>	aka he needs convincing
            
-
            <jrand0m>	right, but I'm not going to sit on my thumbs waiting for him
            
-
            	  to doc them up.  if he does come up with some problems in a week, fantastic,
            
-
            	  and we'll revise accordingly
            
-
            <nop>	or he needs to convine you
            
-
            <nop>	but the idea is this
            
-
            <nop>	what I'm trying to propose with this
            
-
            <nop>	is to reorganize our dev team to get on your bandwagon
            
-
            <nop>	with that
            
-
            <nop>	it would put our energy in working on the network design
            
-
            <nop>	that's the idea
            
-
            <nop>	thus helping all of us get somewhere specific
            
-
            <nop>	I'm not trying to slow down
            
-
            <jrand0m>	right, i don't expect to have a V1.0 final protocol spec next week.
            
-
            	  last night I downloaded about 50 new articles off citeseer to do some more research
            
-
            <nop>	ok
            
-
            <nop>	so can we post your proposal to iip-dev
            
-
            <nop>	and get some review
            
-
            <jrand0m>	coo'
            
-
            <nop>	also I advise on your own to propose it on cryptography@metzdowd.com
            
-
            <nop>	which will get some serious review
            
-
            <jrand0m>	sounds good
            
-
            <nop>	ok
            
-
            <nop>	UserX, you there
            
-
            <UserX> i'm here
            
-
            <nop>	ok, so jrand0m will work on protocol spec, and can I assume you'll come
            
-
            	  up with a concerns list or some additives to the protocol?
            
-
            <UserX> yes
            
-
            <nop>	ok, let's resume this in a week
            
-
            <nop>	what was 5?
            
-
            <nop>	sorry If I'm being a pain
            
-
            <nop>	just want to organize it
            
-
            <nop>	to make sure we're all on same page
            
-
            <jrand0m>	recruiting for services...?
            
-
            <hezekiah>	5) Recruiting for services to aid with IIP
            
-
            <nop>	ok
            
-
            <nop>	yes
            
-
            <nop>	since mids departure
            
-
            <nop>	and cohesions return
            
-
            <nop>	we are possibly looking for others to contribute to IIP in some aspect
            
-
            <nop>	this does not mean you have to be a hardcore core developer
            
-
            <nop>	but additives like maybe a web maintainer would be good,
            
-
            <nop>	some PR would be good
            
-
            <hezekiah>	luckypunk volunteered to manage the website.
            
-
            <hezekiah>	<luckypunk> I wanna help/take over the IIP website.
            
-
            <hezekiah>	<luckypunk> :D
            
-
            <nop>	and if more people would like to hop on with the upcoming project that
            
-
            	  jrand0m is proposing
            
-
            <jrand0m>	wikked
            
-
            <nop>	even if you just want to review the protocol
            
-
            <nop>	that is more than enough help
            
-
            <nop>	the reality is this
            
-
            <nop>	we have a lot of developers with real time jobs
            
-
            <nop>	and it is consuming them at the moment
            
-
            <nop>	and any additional help is wanted
            
-
            <nop>	since this is a huge endeavor
            
-
            <nop>	to take IIP to where it needs to be
            
-
            <nop>	aka InvisibleNet at some point
            
-
            <nop>	real life jobs ;)
            
-
            <nop>	anyway
            
-
            <nop>	the idea is
            
-
            <nop>	it would be cool if people would love to add to this project in some ways
            
-
            <nop>	using their skills, and I know their are some programmers out there
            
-
            <nop>	and a few that have some spare tiem
            
-
            <nop>	time
            
-
            <nop>	luckypunk's reliability will have to be reviewed, no offense, I've had
            
-
            	  him offer before with help maintaining a freesite, and no luck there
            
-
            <hezekiah>	nop: I can understand that one. ;-)
            
-
            <hezekiah>	nop: He just asked me to forward the offer along because he
            
-
            	  wouldn't be here.
            
-
            <nop>	ok
            
-
            <hezekiah>	nop: I did. My part's done. :)
            
-
            <nop>	well, either way, anyone who wants to join in
            
-
            <nop>	contact one of us
            
-
            <nop>	either at iip@invisiblenet.net
            
-
            <hezekiah>	One of whom?
            
-
            <nop>	or just by nick,
            
-
            <nop>	hezekiah, userx, nop,
            
-
            <jrand0m>	I hear anyone who volutneers to help iip gets free hookers and blow
            
-
            <hezekiah>	What are 'hookers and blow'?
            
-
            <hezekiah>	... or do I not want to know?
            
-
            <jrand0m>	heh
            
-
            <nop>	hezekiah: don't ask
            
-
            <hezekiah>	OK.
            
-
            <hezekiah>	I don't want to know. :)
            
-
            <nop>	hezekiah: enjoy your sheltered life ;)
            
-
            <nop>	while you can
            
-
            <nop>	cuz college is gonna be fun :)
            
-
            <hezekiah>	I'm enjoying it! I'm enjoying it!
            
-
            *	jrand0m enjoys the hookers and blow ;)
            
-
            <nop>	jrand0m: quick question
            
-
            *	w hugs luckypunk and nop
            
-
            <jrand0m>	si sr?
            
-
            <nop>	jrand0m: are you considering yourself a dev of IIP at some time soon?
            
-
            <nop>	since you are offering a merge ;)
            
-
            <hifi>
            
-
            	  http://www.guerrillanews.com/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=gnn&Number=182767&page=0&view=collapsed&sb=5&o=0&part=
            
-
            <hifi>	sorry , opps again
            
-
            <jrand0m>	nop> a dev of invisiblenet, but I can't contribute to iip
            
-
            <nop>	understood
            
-
            <nop>	IIP == invisiblenet future projects
            
-
            <hezekiah>	jrand0m: Good working!
            
-
            <hezekiah>	jrand0m: Wording.
            
-
            <nop>	devs wanted for either
            
-
            <nop>	to make that clear
            
-
            <nop>	specifically cuz jrand0m could use a good team set
            
-
            <Addic> I could take a look of the Windows code...
            
-
            <jrand0m>	si sr.	once we get rolling into software design, there's going
            
-
            	  to be more truckloads of work than one can imagine
            
-
            <jrand0m>	word Addic
            
-
            <nop>	awesome
            
-
            <nop>	ok
            
-
            <nop>	I will send this request on iip-dev line as well
            
-
            <nop>	anyone interested please don't hesitate to contact
            
-
            <nop>	was there a 6?
            
-
            <nop>	I believe so
            
-
            <jrand0m>	6) comments suggestions and people who want to help
            
-
            <jrand0m>	suggestion: < 1.8 hours next time :)
            
-
            <jrand0m>	(not that any of the topics could have been condensed any more
            
-
            	  than they were)
            
-
            <nop>	no comments?
            
-
            *	nop thinks everyone's asleep
            
-
            <nop>	hehe
            
-
            <nop>	we bored them
            
-
            <jrand0m>	w3wt
            
-
            <Addic> heh, who has been working on the Windows' code this far?
            
-
            <nop>	ok
            
-
            <hifi>	zzzzzz...
            
-
            <nop>	UserX has made it so far portable
            
-
            <Rain>	What kind of talents are we looking for?
            
-
            <Addic> ok
            
-
            <nop>	ok, let me re-iterate
            
-
            <nop>	Coders, Graphics dudes, Web devs, PR people, Web maintainers
            
-
            <Rain>	Ok, missed that. Sry.
            
-
            <nop>	and if you can write biz plans, that helps me too :)
            
-
            <nop>	you didn't miss
            
-
            <nop>	I didn't go in enough detail
            
-
            <jrand0m>	heh
            
-
            <--	Ehud has quit (EOF From client)
            
-
            <hifi>	I am Born PR people
            
-
            <Rain>	Step one: Collect Underpants.
            
-
            <Addic> translating to other languages at wiki?
            
-
            <nop>	yes
            
-
            <nop>	that would be great
            
-
            <nop>	translations
            
-
            <Addic> ok, i could do that too
            
-
            <nop>	documentation
            
-
            <nop>	etc
            
-
            <--	hezekiah has quit (Ping timeout)
            
-
            <nop>	even organization
            
-
            <nop>	anyone who wants to be actively involved in helping InvisibelNet/IIP
            
-
            <hifi>	I invite ppl to use IIP alll the time
            
-
            <nop>	thnx hifi
            
-
            -->	hezekiah (hezekiah@anon.iip) has joined #iip-dev
            
-
            <Rain>	What kind of org skills?
            
-
            <nop>	well, maybe help run the meetings, or maybe forcing us dev guys to get
            
-
            	  more docs on the protocol
            
-
            <nop>	etc
            
-
            <nop>	possibly organize interviews and some type of press releases
            
-
            <nop>	some ideas for the future of promoting the use of IIP
            
-
            <nop>	etc
            
-
            <nop>	ok, please contact one of us if you want to help out
            
-
            <Rain>	Ok, org question, that I have mentioned before: IIP Signing key? (nag, nag)
            
-
            -->	Ehud (~hezekiah@anon.iip) has joined #iip-dev
            
-
            <hifi>	IIP notification service :) for ppl to knoe I /him is online LOL
            
-
            <qriff> just as a question for the qurious... what defines the holder for "Trent"...
            
-
            <qriff> and what about channel/nick expiration...
            
-
            <qriff> registration that is...
            
-
            <--	ChZEROHag has quit (Ping timeout)
            
-
            <jrand0m>	trent is a service, not a nick, so trent must have access to the
            
-
            	  ircd (i think)
            
-
            <nop>	these questions are mids questions for trent, he's an abstract piece
            
-
            <nop>	yes jrand0m
            
-
            <jrand0m>	iip notification would be cool.  how does anonymail do it?
            
-
            <jrand0m>	can clients send a /notify nick to the server and get a msg when
            
-
            	  the nick joins?
            
-
            <hifi>	IIP SMS notification LOL
            
-
            <nop>	actually
            
-
            <nop>	we did have IIP SMS as the first version of anonymail
            
-
            <nop>	but it tended to flood
            
-
            <hifi>	oh
            
-
            <nop>	so now we do it as anonymail database delivery
            
-
            <hifi>	IIP invitation msg as signature to ordinary e-mails ...
            
-
            <hifi>	Kinda " Do yo Yahoo ? Get MSN free " stuff
            
-
            <jrand0m>	ooOOoo textAds
            
-
            <jrand0m>	but does iip need more users?
            
-
            <hifi>	oh
            
-
            <jrand0m>	or is getting more users just a "oh cool, lets service more people"?
            
-
            <hifi>	no
            
-
            <hifi>	dunno
            
-
            <hifi>	i just brainstorm
            
-
            <--	Mira has quit (Ping timeout)
            
-
            <hezekiah>	More people ... more ideas ... more volunteers
            
-
            <hifi>	IIP as world standart will be cool
            
-
            <hezekiah>	More people ... more problems ... more strain on the network ...
            
-
            <hezekiah>	... more floods of #anonymous ...
            
-
            <hezekiah>	It's a two sided question.
            
-
            <hifi>	more channels lol
            
-
            -->	Mira (~Mira@anon.iip) has joined #iip-dev
            
-
            <hifi>	IIP Eugenics Program LOL Less Population Less Problems
            
-
            -->	ChZEROHag (~hag@anon.iip) has joined #iip-dev
            
-
            <Addic> hmm... going back to the notification question... is it so the /notify
            
-
            	  nick does not work here? Or am I not understanding the question...
            
-
            <lonelynerd>	Addic: sure it works
            
-
            <Addic> well what's the problem then?
            
-
            <hifi>	?
            
-
            <--	Delly has quit (EOF From client)
            
-
            <lonelynerd>	wasn't much following the conversation, but they talked about
            
-
            	  having a /notify that wouldn't require the client to poll
            
-
            <Addic> ok
            
-
            <--	ChZEROHag has quit (Ping timeout)
            
-
            <--	w has quit (Ping timeout)
            
-
            <--	Rain has quit (I Quit)
            
-
            -->	w (~w@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	Hmmm ...
            
-
            <hezekiah>	I think it's about time we adjurne this meeting.
            
-
            <hezekiah>	What do you say, nop?
            
-
            *	jrand0m thinks he fell asleep too
            
-
            <nop>	yeah
            
-
            <nop>	ok
            
-
            <nop>	later
            
-
            <--	jrand0m (jrandom@anon.iip) has left #iip-dev (jrand0m)
            
-
            <hezekiah>	Meeting adjurned! :)
            
-
            <hezekiah>	*BAF*!
            
-
            <--	Addic (anon@anon.iip) has left #iip-dev (Addic)
            
-
            <--	LeerokLacerta (~leerok@anon.iip) has left #iip-dev (Client Exiting)
            
-
            <--	hezekiah has quit (Client exiting)
            
-
            <--	Ehud has quit (Client exiting)
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting49.html b/www.i2p2/pages/meeting49.html
deleted file mode 100644
index ab93d5d8..00000000
--- a/www.i2p2/pages/meeting49.html
+++ /dev/null
@@ -1,746 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 49{% endblock %}
-{% block content %}
            
-
            --- Log opened Tue Jul 15 17:46:47 2003
            
-
            17:46 < gott> yo.
            
-
            17:46 <@nop> just a heads up on my silence
            
-
            17:46 <@hezekiah> Tue Jul 15 21:46:49 UTC 2003
            
-
            17:47 <@hezekiah> OK. The iip-dev meeting has started.
            
-
            17:47 <@hezekiah> Is it the 48th or 49th?
            
-
            17:47 < jrand0m> nop> this is why its critical that we get the router
            
-
            	 architecture pounded out asap.  I understand that different people have
            
-
            	 different rates of speed, and we must segment so different components can
            
-
            	 proceed accordingly
            
-
            17:47 < mihi> 49th
            
-
            17:47 <@hezekiah> OK! Welcome to the 49th iip-dev meeting!
            
-
            17:47 < jrand0m> I have three more days at my job, after which 90+ hours /
            
-
            	 week will be dedicated to getting this going
            
-
            17:48 < jrand0m> I know and don't expect everyone to be able to do that,
            
-
            	 which is why we need to segment
            
-
            17:48 < jrand0m> hi hezekiah :)
            
-
            17:48 <@hezekiah> lol
            
-
            17:48 <@nop> to rebutt on that
            
-
            17:48 <@hezekiah> I'll wait a minute. Then we can do the agenda. :)
            
-
            17:48 <@nop> the security of the router architecture is dependant that you
            
-
            	 do not rush as well
            
-
            17:49 <@nop> if we do
            
-
            17:49 <@nop> we overlook
            
-
            17:49 <@nop> which could leave us cleaning up a big mess later
            
-
            17:49 -!- Rain [Rain@anon.iip] has quit [I Quit]
            
-
            17:49 < jrand0m> nop> disagree.  we can still build app layer and APIs
            
-
            	 without implementing the router (or even knowing how the network will operate)
            
-
            17:49 <@nop> I agree with that
            
-
            17:50 <@nop> I'm specifically talking about the underlying network
            
-
            17:50 < jrand0m> if we can agree to the API I sent out, then thats the
            
-
            	 segmentation we need
            
-
            17:50 < jrand0m> right, router impl and network design still isn't done
            
-
            17:50 <@nop> ok
            
-
            17:50 <@nop> oh, I can definitely agree with your api so far
            
-
            17:51 <@hezekiah> jrand0m: One problem.
            
-
            17:51 < jrand0m> shoot hezekiah
            
-
            17:51 <@hezekiah> It will look different if you implement it in C.
            
-
            17:51 < jrand0m> not too different
            
-
            17:51 < gott> oh dear
            
-
            17:51 < jrand0m> less capital letters, and replace the objects with structs
            
-
            17:51 < gott> what languages are people considering implementing it in?
            
-
            17:51 < jrand0m> (for the api)
            
-
            17:51 <@hezekiah> Uh, jrand0m? There is no 'byte[]' in C.
            
-
            17:51 < jrand0m> gott> read the mail archives for some example answers to that
            
-
            17:52 <@hezekiah> You will be using void*'s with an integer to specifiy the
            
-
            	 length most likely.
            
-
            17:52 < jrand0m> hezekiah> then unsigned int[]
            
-
            17:52 < gott> jrand0m: for once, a religious war that I'm not a part of
            
-
            17:52 <@hezekiah> If I remember correctly (help me out here nop), you can't
            
-
            	 just return an unsigned int[] from a function.
            
-
            17:53 <@hezekiah> gott: It's not a religious war. I'm just saying that the
            
-
            	 API as a concept might be fine, but in C it would look seriously different.
            
-
            17:53 < gott> hezekiah: as opposed to what? pseudocode?
            
-
            17:53 < jrand0m> right, syntactic changes.  but yes, if there are real
            
-
            	 differences, we need to get them worked out ASAP.  (like, today)  Perhaps
            
-
            	 now would be a good tiem to look at the email I sent entitled "high level
            
-
            	 router architecture and API" and review?
            
-
            17:54 <@hezekiah> nop? UserX? Are you game for that?
            
-
            17:54 < jrand0m> not too different, but different none the less, yes.
            
-
            	 which is why I said Java API on todays email :)
            
-
            17:54 -!- WinBear [WinBear@anon.iip] has joined #iip-dev
            
-
            17:55 <@nop> wait
            
-
            17:55 <@nop> reading above
            
-
            17:55 -!- mihi_2 [~none@anon.iip] has joined #iip-dev
            
-
            17:55 -!- mihi is now known as nickthief60234
            
-
            17:55 -!- mihi_2 is now known as mihi
            
-
            17:55 < jrand0m> wb mihi
            
-
            17:55 < gott> btw, is this being live logged?
            
-
            17:55 -!- nickthief60234 [~none@anon.iip] has quit [EOF From client]
            
-
            17:55 <@hezekiah> gott: Yes.
            
-
            17:55 < mihi> redundancy rules ;)
            
-
            17:55 < gott> I'll just read it later on then.
            
-
            17:55 -!- gott [~gott@anon.iip] has left #iip-dev [gott]
            
-
            17:56 <@nop> ok
            
-
            17:56 <@nop> yes
            
-
            17:56 < WinBear> jrand0m: hi
            
-
            17:56 <@nop> definitely differences
            
-
            17:56 <@nop> what we need
            
-
            17:56 < jrand0m> heya WinBear
            
-
            17:56 <@nop> is a team of certain developers to write the main api level
            
-
            	 controls for these languages
            
-
            17:56 <@nop> we know that jrand0m can handle java
            
-
            17:56 <@nop> and probably could team up with thecrypto as well
            
-
            17:56 <@nop> and hezekiah and the gang can do C
            
-
            17:56 <@nop> and jeremiah if he's willing
            
-
            17:56 <@nop> can do python
            
-
            17:56 <@hezekiah> I can do C++ too! ;-)
            
-
            17:56 <@nop> ok
            
-
            17:56 <@nop> C++ as well
            
-
            17:57 <@hezekiah> lol
            
-
            17:57 <@nop> C++ will probably work
            
-
            17:57 <@nop> with C
            
-
            17:57 <@nop> if you don't template the crap out of it
            
-
            17:57 < jrand0m> heh
            
-
            17:57 <@hezekiah> lol
            
-
            17:57 <@hezekiah> Actually, while MSVC can link C and C++ object files,
            
-
            	 gcc doesn't seem to like that.
            
-
            17:57 <@nop> aka, stick to structs that are compatible with C, or is that
            
-
            	 not viable
            
-
            17:57 < jrand0m> first question, prior to that, is what applications will use
            
-
            	 these APIs?  I know of apps that will want to use java, will iproxy be in C?
            
-
            17:58 <@hezekiah> nop: I don't think C and C++ are object compatible.
            
-
            17:58 <@nop> ok
            
-
            17:58 <@hezekiah> nop: C++ won't get along with C much better than Java.
            
-
            17:58 <@nop> well maybe USerX could do C
            
-
            17:58 <@nop> and you could pull C++
            
-
            17:58 <@hezekiah> We don
            
-
            17:58 <@nop> ?
            
-
            17:58 <@hezekiah> don't even need to _do_ C++ if you don't want to. It's
            
-
            	 just that I prefer it.
            
-
            17:59 <@nop> well, the thing is
            
-
            17:59 <@nop> there are a lot of C++ developers
            
-
            17:59 <@nop> especially in the microsoft world
            
-
            17:59 <@hezekiah> Even in the Linux world. (see: KDE and Qt.)
            
-
            17:59 < jrand0m> C and C++ are binary compatible if you just make .so or .a
            
-
            17:59 < jrand0m> (btw)
            
-
            18:00 <@nop> can C be a good placement for C++, aka C++ developers would be
            
-
            	 able to handle a c api easier than a C++ api with a c developer?
            
-
            18:00 <@hezekiah> jrand0m: Yeah. You can probably have libraries ... but if
            
-
            	 you can
            
-
            18:00 <@hezekiah> jrand0m: can't even use classes, it sorta defeats the
            
-
            	 purpose.
            
-
            18:00 <@nop> right
            
-
            18:00 <@nop> let's stick with C
            
-
            18:01 <@nop> because C++ coders can still call a C library rather easily
            
-
            18:01 <@hezekiah> If one module needs to call anothers functions, then they
            
-
            	 had best both be the same language.
            
-
            18:01 <@hezekiah> nop: C++ coders will know C well enough ... though it
            
-
            	 might take some work if they never /learned/ C.
            
-
            18:02 <@hezekiah> However, C coders wouldn't know C++ since C is just a
            
-
            	 subset of C++.
            
-
            18:02 -!- logger_ [~logger@anon.iip] has joined #iip-dev
            
-
            18:02 -!- Topic for #iip-dev: logfiles will be online after the meeting:
            
-
            	 http://wiki.invisiblenet.net/?Meetings
            
-
            18:02 [Users #iip-dev]
            
-
            18:02 [@hezekiah] [+Ehud    ] [ leenookx] [ moltar] [ tek    ]
            
-
            18:02 [@nop     ] [ jeremiah] [ logger_ ] [ Neo   ] [ WinBear]
            
-
            18:02 [@UserX   ] [ jrand0m ] [ mihi    ] [ ptsc  ]
            
-
            18:02 -!- Irssi: #iip-dev: Total of 14 nicks [3 ops, 0 halfops, 1 voices,
            
-
            10 normal]
            
-
            18:02 < jrand0m> right
            
-
            18:02 -!- Irssi: Join to #iip-dev was synced in 9 secs
            
-
            18:02 < jrand0m> (with JMS :)
            
-
            18:02 <@nop> yep
            
-
            18:03 -!- You're now known as logger
            
-
            18:03 < jrand0m> ok, can we review the overall architecture to see whether
            
-
            	 the APIs are even relevent first?
            
-
            18:03 <@nop> fine  18:04 < jrand0m> :)
            
-
            18:04 < jrand0m> ok, see the email I sent w/ the routerArchitecture.png.
            
-
            	 any thoughts on that seperation?
            
-
            18:04 -!- tek [~tek@anon.iip] has quit []
            
-
            18:05 < WinBear> jrand0m: is that on the wiki?
            
-
            18:05 < jrand0m> WinBear> no, on the mailing list, though the archives
            
-
            	 are down.  lemmie add it to the wikki
            
-
            18:06 <@hezekiah> Correct me if I'm wrong ...
            
-
            18:07 <@hezekiah> ... but it looks like we're going to have 3 seperate API's
            
-
            	 that are as similar as possible.
            
-
            18:07 <@hezekiah> Right?
            
-
            18:07 < jrand0m> yes hezekiah
            
-
            18:07 <@hezekiah> So since each API is in a different language, are they
            
-
            	 going all each have seperate implementations?
            
-
            18:07 < jrand0m> yes
            
-
            18:07 <@hezekiah> Or is there a way for Java or Python to access a C library?
            
-
            18:08 < jrand0m> yes, but we don't want to go that route
            
-
            18:08 < mihi> for java: JNI
            
-
            18:08 <@hezekiah> So this talk about Java, C, C++, Python, etc. working
            
-
            	 together is mute since they never will?
            
-
            18:08 < jrand0m> how do I attach an image to the wiki?
            
-
            18:08 <@hezekiah> Each API has its own backend written in that language.
            
-
            18:08 < jrand0m> no hezekiah, look at the diagram
            
-
            18:09 <@hezekiah> Oh, duh!
            
-
            18:09 <@hezekiah> The API's don't link to a backend.
            
-
            18:10 <@hezekiah> They talk via sockets.
            
-
            18:10 < jrand0m> si sr
            
-
            18:10 <@hezekiah> This is still a little confusing though.
            
-
            18:10 <@hezekiah> Give me a sec here. :)
            
-
            18:11 <@hezekiah> OK. What is the thing labeled 'transport'?
            
-
            18:11 < jrand0m> for example, bidirectional HTTP transport, SMTP transport,
            
-
            	 plain socket transport, polling HTTP socket, etc
            
-
            18:11 < jrand0m> the thing that moves bytes between routers
            
-
            18:12 <@hezekiah> OK.
            
-
            18:12 <@hezekiah> So the diagram I'm looking at shows one person's computer.
            
-
            18:12 <@hezekiah> He has a router that talks to other people's computers
            
-
            	 via the transports.
            
-
            18:12 < jrand0m> correct
            
-
            18:12 <@hezekiah> Person 1 (Alice) has 2 applications running.
            
-
            18:12 <@hezekiah> One is in C, the other in Java.
            
-
            18:13 <@hezekiah> Both are linked to a library (that's the API).
            
-
            18:13 < jrand0m> both are "linked" to seperate libraries (the APIs)
            
-
            18:13 <@nop> simple concept
            
-
            18:13 <@nop> yes
            
-
            18:13 <@hezekiah> Those libraries, take input from the program encrypt it,
            
-
            	 and send it via sockets (unix or TCP) to the router ... which is another
            
-
            	 program Alice is running.
            
-
            18:13 < jrand0m> correct
            
-
            18:14 <@hezekiah> OK. So it's kinda like isproxy being split in two.
            
-
            18:14 < jrand0m> bingo :)
            
-
            18:14 <@hezekiah> One part is low end and written in C, and the other is
            
-
            	 high end and written in whatever.
            
-
            18:14 < jrand0m> exactly
            
-
            18:14 <@hezekiah> OK. I get it. :)
            
-
            18:14 < jrand0m> w00t
            
-
            18:14 <@hezekiah> So no language needs to play nice with any other language.
            
-
            18:14 < jrand0m> WinBear> sorry, I can't toss it on the wiki as it only
            
-
            	 takes text :/
            
-
            18:15 <@hezekiah> Since they all comunicate with the router via sockets,
            
-
            	 you could write an API in PASCAL for all the design cares.
            
-
            18:15 <@nop> yes
            
-
            18:15 <@nop> arbitrary
            
-
            18:15 < jrand0m> right
            
-
            18:15 <@nop> it handles arbitrary sockets
            
-
            18:15 < jrand0m> though some things need to be standardized (like the data
            
-
            	 structures for Destination, Lease, etc)
            
-
            18:15 < WinBear> jrand0m: i get a vague idea based on what hezekiah is saying
            
-
            18:15 < jrand0m> word
            
-
            18:16 <@hezekiah> jrand0m: Right. The structure and order of the bytes that
            
-
            	 go across that socket is set in a design somewhre
            
-
            18:16 <@hezekiah> somewhere.
            
-
            18:17 <@hezekiah> But you can still implement how those bytes are send and
            
-
            	 received any joly way you please.
            
-
            18:17 <@nop> WinBear: it's the same exact way that the irc client works
            
-
            	 with isproxy
            
-
            18:17 < jrand0m> exactly
            
-
            18:17 <@hezekiah> Good.
            
-
            18:17 <@hezekiah> I understand now. :)
            
-
            18:17 -!- moltar [~me@anon.iip] has left #iip-dev [moltar]
            
-
            18:17 <@nop> well
            
-
            18:17 <@nop> not exactly
            
-
            18:17 <@hezekiah> Uh oh.
            
-
            18:17 <@nop> but imagine how that works
            
-
            18:17 <@nop> and you can understand arbitrary sockets
            
-
            18:17 <@nop> isproxy just routes
            
-
            18:17 <@nop> and delivers
            
-
            18:18 <@nop> now jrand0m
            
-
            18:18 <@nop> quick question
            
-
            18:18 < jrand0m> si sr?
            
-
            18:18 <@nop> is this api designed for only new applications that are designed
            
-
            	 to work on this network
            
-
            18:18 -!- mode/#iip-dev [+v logger] by hezekiah
            
-
            18:18 < WinBear> nop: with the highlevel replacing the irc client?
            
-
            18:18 < jrand0m> nop> yes.  though a SOCKS5 proxy could use this API as well
            
-
            18:18 <@nop> or can it be able to have a middle man that can allow already
            
-
            	 standard clients
            
-
            18:18 <@nop> for instance
            
-
            18:19 <@nop> so all we would have to do is write the middleman -> api
            
-
            18:19 < jrand0m> (but note that there's no 'lookup' service available -
            
-
            	 no DNS for this network)
            
-
            18:19 < jrand0m> correct
            
-
            18:19 <@nop> so that we can support say Mozilla etc
            
-
            18:19 <@nop> so they can just code plugins
            
-
            18:19 < jrand0m> nop> yes
            
-
            18:19 <@nop> ok
            
-
            18:19 <@nop> or transports :)
            
-
            18:20 < jrand0m> (e.g. the SOCKS5 has the HTTP outproxies hardcoded to
            
-
            	 destination1, destination2, and destination3)
            
-
            18:20 <@nop> ok
            
-
            18:20 < WinBear> i think i get it
            
-
            18:21 < jrand0m> w00t
            
-
            18:21 < jrand0m> ok, one of the things I had to think about in this design
            
-
            	 was keeping the private keys in the app's memory space - the router never
            
-
            	 gets a hold of destination private keys.
            
-
            18:21 <@hezekiah> So the application can send raw data over the I2P network
            
-
            	 by sending it to the API, and it doesn't need to worry about the rest.
            
-
            18:22 <@hezekiah> Right?
            
-
            18:22 < jrand0m> that means the APIs need to implement the end to end part
            
-
            	 of the crypto
            
-
            18:22 < jrand0m> exactly hezekiah
            
-
            18:22 <@hezekiah> OK.
            
-
            18:22 <@nop> yes
            
-
            18:22 <@nop> that's the idea
            
-
            18:22 <@nop> it does it for you
            
-
            18:22 <@nop> you just call the hook
            
-
            18:23 <@hezekiah> One quick question:
            
-
            18:23 <@hezekiah> This 'router' obviously needs to speak a certain protocol
            
-
            	 over it's transports.
            
-
            18:23 < jrand0m> correct
            
-
            18:23 <@hezekiah> So it is possible to provide multiple implementations of
            
-
            	 the router ...
            
-
            18:23 < jrand0m> yes
            
-
            18:24 <@hezekiah> ... as long as they both speak the same protocol.
            
-
            18:24 < jrand0m> (which is why the spec has placeholders for bitbuckets)
            
-
            18:24 < jrand0m> right
            
-
            18:24 <@hezekiah> So you have a router in Java, and one in C, and one
            
-
            	 in PASCAL.
            
-
            18:24  * jrand0m cringes
            
-
            18:24 < jrand0m> but yeah
            
-
            18:24 <@hezekiah> And they all can talk together since they're talking over
            
-
            	 TCP/IP using the same protocol.
            
-
            18:24  * WinBear jumps
            
-
            18:24 <@hezekiah> jrand0m: And yes. I don't remember my PASCAL days overly
            
-
            	 fondly either.
            
-
            18:25 < jrand0m> well, Pascal can talk to the C one through the TCP transport,
            
-
            	 and the C one can talk to the Java one over the HTTP transport, for example
            
-
            18:25 <@hezekiah> Right.
            
-
            18:25 < jrand0m> (transports talk to other like transports, routers manage
            
-
            	 the messages delivered between them but don't deal with how they're delivered)
            
-
            18:26 <@hezekiah> The point I was looking to make was that the protocol is the
            
-
            	 same, so it doesn't matter what language someone's router is implemented in.
            
-
            18:26 < jrand0m> right
            
-
            18:26 <@hezekiah> Cool.
            
-
            18:26 < jrand0m> now you understand why I said "who cares" to all the C vs
            
-
            	 Java vs etc debates?  :)
            
-
            18:26 <@hezekiah> Yup.
            
-
            18:26 <@hezekiah> lol
            
-
            18:27 <@hezekiah> I've got to hand it to you jrand0m. This will make it very
            
-
            	 kind for develoeprs to write programs for this network.
            
-
            18:27 < jrand0m> heh, well, the API ain't quite original.  this is how
            
-
            	 Message Oriented Middleware (MOM) works
            
-
            18:27 <@hezekiah> And you could even make routers that specialize in certain
            
-
            	 platform specific features (like 64-bit CPU's).
            
-
            18:28 < jrand0m> absolutely
            
-
            18:28 <@hezekiah> jrand0m: Humble too! ;-)
            
-
            18:28 <@hezekiah> Well, it looks good to me.
            
-
            18:28 < jrand0m> ok, UserX, nop, does this seperation make sense?
            
-
            18:28 <@nop> of course
            
-
            18:28 <@nop> is userx still here
            
-
            18:29 <@hezekiah> He's been idle for 1:26.
            
-
            18:29 < jrand0m> 'k.  so then we have two tasks: design the network, and
            
-
            	 design how the API works.
            
-
            18:29 <@nop> right
            
-
            18:29 <@hezekiah> Quick simple question: The API's do end to end crypto. Do
            
-
            	 the routers to node to node crypto ?
            
-
            18:29 <@nop> yes
            
-
            18:30 < jrand0m> yes
            
-
            18:30 < jrand0m> (transport level)
            
-
            18:30 <@hezekiah> Good. :)
            
-
            18:30 <@nop> hezekiah: it's very similar to what we have so far
            
-
            18:30 <@nop> in that aspect
            
-
            18:31 < jrand0m> ok.. er, shit, thecrypto aint around for comments on the
            
-
            	 performance model.
            
-
            18:31 < Neo> and for the paranoid, the apps can do the pgp encryption before
            
-
            	 it hits the API ;)
            
-
            18:31 < jrand0m> absolutely neo
            
-
            18:31 < jrand0m> I was even tempted to leave the end to end crypto out of
            
-
            	 the API and leave it up to the apps...
            
-
            18:31 <@hezekiah> jrand0m: That would be cruel.
            
-
            18:31 < jrand0m> heheh
            
-
            18:32 <@hezekiah> BTW, the API's and the router communicate via sockets.
            
-
            18:32 <@hezekiah> On UNIX will they be using UNIX sockets or local TCP/IP
            
-
            	 sockets?
            
-
            18:32 < jrand0m> prolly just local tcp/ip for simplicity
            
-
            18:32 <@nop> hold
            
-
            18:32 <@hezekiah> (I suppose you could make a router that accepts both.)
            
-
            18:33  * hezekiah is really liking this interchangable parts setup
            
-
            18:33 <@nop> if you hold on a sec
            
-
            18:34 <@hezekiah> Holding ... :)
            
-
            18:34 <@nop> I'll call thecrypto at his house
            
-
            18:34 <@nop> see if he can get on
            
-
            18:34 < jrand0m> hehe word
            
-
            18:34 <@hezekiah> lol
            
-
            18:34  * hezekiah dons a thick Itallian accent
            
-
            18:34 <@hezekiah> Nop ha' got ... CONNECTIONS!
            
-
            18:34 < jeremiah> lo
            
-
            18:34 <@nop> hey jeremiah
            
-
            18:35 < jrand0m> heya jeremiah
            
-
            18:35 <@nop> would you be willing at the api level to assist with a python api
            
-
            18:35 < jeremiah> sure
            
-
            18:35  * jeremiah reads backlog
            
-
            18:35 < jrand0m> heh word
            
-
            18:35  * nop is calling
            
-
            18:36 <@nop> he's not home
            
-
            18:36 <@nop> he'll be back in an hour
            
-
            18:36 < jrand0m> 'k, has anyone else read the .xls and/or have comments on
            
-
            	 the model?
            
-
            18:37 <@hezekiah> I read the .xls ... but I don't know much about p2p so
            
-
            	 most of it was over my head.
            
-
            18:37 <@hezekiah> UserX is good at that stuff.
            
-
            18:37 <@nop> I have to read it still
            
-
            18:37 < jrand0m> (btw, morphmix had some insane numbers... they were saying
            
-
            	 they could expect random hosts on the net to have average 20-150ms ping times,
            
-
            	 rather than the 3-500 I was expecting)
            
-
            18:37 < jrand0m> coo'
            
-
            18:37 <@nop> it's staroffice or openoffice?
            
-
            18:37 < jrand0m> openoffice, but I exported it to .xls
            
-
            18:37 <@nop> which is excell?
            
-
            18:37 < jrand0m> correct
            
-
            18:38 <@hezekiah> BTW, concerning the API ...
            
-
            18:38 < jrand0m> si sr?
            
-
            18:38 <@hezekiah> ... in C the boolean would be int.
            
-
            18:38 <@nop> which email
            
-
            18:38 <@nop> hezekiah: yes
            
-
            18:38 <@hezekiah> The classes would be sent as structure pointers.
            
-
            18:38 <@nop> unless you typedef boolean
            
-
            18:39 <@hezekiah> And the functions that use byte[] would use a void* with
            
-
            	 an additional parameter that specefies the length of the buffer.
            
-
            18:39 <@nop> hezekiah: you're being picky :)
            
-
            18:39 < jrand0m> nop> I cant access the archives so I'm not sure what the
            
-
            	 subject line was, but it was last week...
            
-
            18:39 <@nop> save it for a later time
            
-
            18:39 <@hezekiah> nop: Picky?
            
-
            18:39 < jrand0m> heh, yeah, y'all working on the C api can work that detail out
            
-
            18:39  * jeremiah is done reading backlog
            
-
            18:39 <@nop> what's the file called
            
-
            18:39 <@hezekiah> nop: I'm just trying to find all the stuff that is different,
            
-
            	 so we can hammer it out like jrand0m asked.
            
-
            18:40 <@hezekiah> I'm trying to be helpful. :)
            
-
            18:40 <@nop> hezekiah: yes, probably off meeting time
            
-
            18:40 < jrand0m> nop> simple_latency.xls
            
-
            18:40 <@hezekiah> boolean sendMessage(Destination dest, byte[] payload);
            
-
            18:40 <@hezekiah>  would be
            
-
            18:40 <@hezekiah> int sendMessage(Destination dest, void* payload, int length);
            
-
            18:40 <@hezekiah> .
            
-
            18:40 <@hezekiah> byte[]  recieveMessage(int msgId);
            
-
            18:40 <@hezekiah>  that could either be:
            
-
            18:41 <@hezekiah> void*  recieveMessage(int msgId, int* length);
            
-
            18:41 <@hezekiah>  or
            
-
            18:41 <@nop> jrand0m: got it
            
-
            18:41 <@hezekiah> void recieveMessage(int msgId, void* buf, int* length);
            
-
            18:41 <@hezekiah>  or
            
-
            18:41 < jrand0m> hezekia: why not typedef struct { int length; void* data;
            
-
            	 } Payload;
            
-
            18:41 <@hezekiah> DataBlock* recieveMessage(int msgId)l
            
-
            18:41 <@hezekiah> DataBlock* recieveMessage(int msgId);
            
-
            18:41 < jeremiah> where's this xls?
            
-
            18:41 <@nop> oh iip-dev
            
-
            18:41 <@hezekiah> jrand0m: The struct you just mentioned is basically what
            
-
            	 DataBlock is.
            
-
            18:42 < jrand0m> word hezekiah
            
-
            18:42 <@nop> subject more models
            
-
            18:42 <@hezekiah> Chances are the C version would have DataBlocks.
            
-
            18:43 <@hezekiah> Beyond that the only other thing to note is that each
            
-
            	 'interface' would just be a set of functions.
            
-
            18:43 <@hezekiah> nop: Did I find all the differences that would exist in
            
-
            	 a C API?
            
-
            18:43 < jrand0m> right.  perhaps #include "i2psession.h" or something
            
-
            18:43 < jeremiah> is there a mockup python api?
            
-
            18:44 < jrand0m> no jeremiah, I don't really know python :/
            
-
            18:44 <@nop> I would have to re-review the java api, but I would say that
            
-
            	 you're right on target
            
-
            18:44 < jrand0m> but it would probably be similar to the java, as python is OO
            
-
            18:44 < jeremiah> cool, i can derive one from the C one
            
-
            18:44  * nop is not a java head
            
-
            18:44 < jrand0m> cool jeremiah
            
-
            18:44 < jeremiah> is the c api in the thing you sent out a few days ago?
            
-
            18:44 <@hezekiah> Yeah. Python should be able to handle the Java api.
            
-
            18:44 < jrand0m> jeremiah> that was the Java one
            
-
            18:45 < jrand0m> oh, the Java one was today
            
-
            18:45 < jrand0m> the older one was language independent
            
-
            18:45 <@hezekiah> Hmm
            
-
            18:45 <@nop> UserX says he should be able to assist with C api
            
-
            18:45 < jrand0m> word
            
-
            18:45 <@nop> he's busy at work at the moment
            
-
            18:46 < jrand0m> coo'
            
-
            18:46 <@hezekiah> One last note: With the C api, each function would probably
            
-
            	 take a structure* to the structure that it is an 'interface' of in Java.
            
-
            18:46 <@nop> hezekiah: loos good
            
-
            18:46 <@nop> looks good
            
-
            18:46 <@hezekiah> I2PSession       createSession(String keyFileToLoadFrom,
            
-
            	 Properties options);
            
-
            18:46 <@hezekiah>  would be:
            
-
            18:46 <@nop> java and their non-native data types
            
-
            18:46 <@hezekiah> I2PSession* createSession(I2PClient* client, char*
            
-
            	 keyFileToLoadFrom, Properties* options);
            
-
            18:46 <@nop> ;)
            
-
            18:46 < jrand0m> hehe
            
-
            18:46 < jrand0m> right hezekiah
            
-
            18:47 < jeremiah> are we addressing unicode?
            
-
            18:47 <@hezekiah> Anyway, if you can live with those differences, the C and
            
-
            	 Java API's should be identical beyond that.
            
-
            18:47 <@hezekiah> nop? Unicode? :)
            
-
            18:47 < jrand0m> UTF8 if not UTF16
            
-
            18:48 <@hezekiah> Perhaps Unicode should be dealt with on the application
            
-
            	 level.
            
-
            18:48 < jrand0m> right, charset is all the content of the message
            
-
            18:48 <@hezekiah> Oh.
            
-
            18:48 < jeremiah> ok
            
-
            18:48 <@hezekiah> Java String's are done in Unicode, aren't they jrand0m?
            
-
            18:48 < jrand0m> the bitbuckets'll all be bit defined
            
-
            18:48 < jrand0m> yes hezekiah
            
-
            18:48 < jrand0m> (unless you explicitly instruct them to change charsets)
            
-
            18:49 <@hezekiah> So the string sent to the Java API would be different than
            
-
            	 the one sent to the C API unless the C API implements strings using Unicode.
            
-
            18:49 < jrand0m> not relevent
            
-
            18:49 <@hezekiah> OK.
            
-
            18:49 < jrand0m> (app->API != API->router.  we only define API->router)
            
-
            18:49 <@hezekiah> What I'm saying is this, jrand0m:
            
-
            18:50 <@hezekiah> If I set my password with the Java API, it goes to the
            
-
            	 router out someplace else.
            
-
            18:50 < jrand0m> password?  you mean you create a Destination?
            
-
            18:50 <@hezekiah> Then it find another router, which sends it to another API
            
-
            	 (?) which is implemented in C.
            
-
            18:50 <@hezekiah>   void            setPassphrase(String old, String new);
            
-
            18:50 <@hezekiah> That function.
            
-
            18:51 < jrand0m> hezekiah> thats the administrative password to access the
            
-
            	 administrative methods of the router
            
-
            18:51 <@hezekiah> Ah
            
-
            18:51 <@hezekiah> Do any functions in the API which use Java String's end
            
-
            	 up with that String being sent to another API?
            
-
            18:51 < jrand0m> 99.9% of apps will only use I2PSession, not I2PAdminSession
            
-
            18:51 <@nop> also, anything carried with the router gets converted for
            
-
            	 network travel correct?
            
-
            18:51 <@hezekiah> If so, we should probably use Unicode.
            
-
            18:51 <@nop> unicode wouldn't be releavant
            
-
            18:52 < jrand0m> hezekiah> no.  all inter-router info will be defined by
            
-
            	 bit buckets
            
-
            18:52 <@hezekiah> OK.
            
-
            18:52 < jrand0m> correct nop, at the transport level
            
-
            18:52 <@hezekiah> (I'm assuming a bit bucket is just a binary buffer, right?)
            
-
            18:53 < jrand0m> a bit bucket is a statement that the first bit means X,
            
-
            	 the second bit means Y, bits 3-42 mean Z, etc
            
-
            18:53 < jrand0m> (e.g. we may want to use X.509 for the certificates bitbucket)
            
-
-
            18:53 <@hezekiah> I've never dealt with that before.
            
-
            18:54 <@hezekiah> I'll worry about it when I get there. :)
            
-
            18:54 < jrand0m> heh word
            
-
            18:55 < jrand0m> ok, the four things I wanted us to hit today: *router
            
-
            	 architecture, *performance model, *attack analysis, *psyc.  We've done
            
-
            	 the first, thecrypto is offline so perhaps we delay this (unless you have
            
-
            	 thoughts on the model nop?)
            
-
            18:57 <@hezekiah> Um ... jrand0m. I have yet another question.
            
-
            18:57 < jeremiah> jrand0m: where's the latest version of the network spec? is
            
-
            	 it what you sent out on the 13th?
            
-
            18:57 < jrand0m> si sr?
            
-
            18:57 <@hezekiah> Well the router architecture has the API's handle keys
            
-
            	 /sent to them by the Application/.
            
-
            18:57 < jrand0m> jeremiah> yes
            
-
            18:57 <@nop> I don't at this time
            
-
            18:58 <@hezekiah> Now ... the only way I see that the API gets the key is
            
-
            	 from createSession.
            
-
            18:58 < jrand0m> hezekiah> the router  gets public keys and signatures,
            
-
            	 not private keys
            
-
            18:58 < jrand0m> right
            
-
            18:58 <@hezekiah> But that requires a file.
            
-
            18:58 < jrand0m> the keys are stored in a file or in the API's memory
            
-
            18:58 < jrand0m> yes
            
-
            18:58 <@hezekiah> Now if the application generates a key, why can't it just
            
-
            	 send it to the API via a buffer?
            
-
            18:59 <@hezekiah> Must it really store it in a file, and then provide the
            
-
            	 file name?
            
-
            18:59 < jrand0m> no, it can be in memory if you'd like
            
-
            18:59 <@hezekiah> There is not function to all that in the API though.
            
-
            18:59 <@hezekiah> It's just a thought.
            
-
            19:00 <@hezekiah> If the key is supposed to be generated only once and used
            
-
            	 many, many times (like GPG keys), then a file makes sense.
            
-
            19:00 -!- mihi [none@anon.iip] has quit [bye all, it's getting late...]
            
-
            19:00 <@hezekiah> But if it will be generated more often, then perhaps some
            
-
            	 way to directly send it to the API via a structure or buffer of some sort
            
-
            	 might be nice
            
-
            19:00 <@hezekiah> .
            
-
            19:01 < jrand0m> yes, its generated once and only once (unless you're wearing
            
-
            	 a tinfoil hat)
            
-
            19:02 < jrand0m> though the createDestination(keyFileToSaveTo) lets you
            
-
            	 create that key
            
-
            19:02 <@hezekiah> OK.
            
-
            19:02 <@hezekiah> So there's really no need for transfer directly from the
            
-
            	 App to the API. A file will suffice.
            
-
            19:03 <@hezekiah> So where were we before I so rudely interupted? :)
            
-
            19:06 < jeremiah> so right now we're just working on the router API, not
            
-
            	 the client one, right?
            
-
            19:06 < jrand0m> well, we're skipping on performance analysis for now
            
-
            	 (hopefully we can get some chatter re: it on the mailing list before next
            
-
            	 week?).  and probably the same wrt attack analysis (unless anyone read the
            
-
            	 new spec and has comments)
            
-
            19:07 <@hezekiah> So we're since we're skipping that, what are we supposed
            
-
            	 to be talking about now?
            
-
            19:07 <@hezekiah> Psyc?
            
-
            19:07 < jrand0m> unless anyone else has other comments to bring up...?
            
-
            19:08 <@hezekiah> Well, for once, my comment hole (also notoriously known
            
-
            	 as my mouth) is empty.
            
-
            19:08 < jrand0m> hehe
            
-
            19:09 < jrand0m> ok, anyone have any thoughts on how the IRC side of things
            
-
            	 will work, and whether psyc may be relevent or useful?
            
-
            19:09 < jeremiah> sidenote (that pissed me off): wired's "Wired, Tired,
            
-
            	 Expired" list had Waste as 'wired'
            
-
            19:09 < jrand0m> heh
            
-
            19:09 < jrand0m> do you realize how much we're going to blow everyone away?
            
-
            19:09 < jeremiah> yep
            
-
            19:09 <@hezekiah> jrand0m: That assumes we get this to work.
            
-
            19:10 < jrand0m> I guarantee it will work.
            
-
            19:10 <@hezekiah> There are a lot of other failed efforts out there.
            
-
            19:10 < jrand0m> I quit my job to work on this.
            
-
            19:10 <@hezekiah> Then we're going to blow everyone away. :)
            
-
            19:10 <@hezekiah> Yeah. How is bread getting on the table when you do that?
            
-
            19:10 <@hezekiah> GPL code doesn't pay well. ;-)
            
-
            19:10 < jrand0m> heh
            
-
            19:11 <@hezekiah> As for psyc ... let me put it this way:
            
-
            19:11 <@hezekiah> The first time I heard of it was when you emailed us
            
-
            	 about it.
            
-
            19:11 < jrand0m> shit, I wasn't the one who found it :)
            
-
            19:11 <@hezekiah> However, IRC is probably one of the most (if not /the/
            
-
            	 most) prolific chat protocols around.
            
-
            19:11 <@hezekiah> People will want IRC apps LONG before they even /know/
            
-
            	 what psyc is.
            
-
            19:11 <@hezekiah> jrand0m: Oops. Sorry. I forgot that detail. :)
            
-
            19:12 < jrand0m> not according to psyc.  their history goes back to 86 I think
            
-
            19:12 <@hezekiah> The point is that the supperiority of the protocol, isn't
            
-
            	 really as relevant as to who uses it.
            
-
            19:12 <@hezekiah> Their _history_ may go back that far.
            
-
            19:12 <@hezekiah> But how many people _use_ Psyc?
            
-
            19:12 < jeremiah> yeah if they've been around since a year after I was born
            
-
            	 (ahem) and they aren't that big yet
            
-
            19:12 <@hezekiah> My point is that even if it's a better protocol, most
            
-
            	 people _use_ IRC.
            
-
            19:13 <@hezekiah> We can make the best I2P network on the planet ...
            
-
            19:13 -!- Ehud [logger@anon.iip] has quit [Ping timeout]
            
-
            19:14 < jeremiah> can someone explain briefly why we care? I thought IRC
            
-
            	 would only be one possible application but that the network is flexible to
            
-
            	 support psyc as well if it wanted to
            
-
            19:14 <@hezekiah> Right.
            
-
            19:14 <@hezekiah> Psyc can be made ...
            
-
            19:14 <@hezekiah> ... but I'm saying we should do IRC first because more
            
-
            	 people use it.
            
-
-
            19:14 <@hezekiah> jrand0m, we can make a great I2P network, but people won't
            
-
            	 use it unless it has something they want.
            
-
            19:14 < jrand0m> jeremiah> the reason psyc is interesting is that we may
            
-
            	 want to implement IRC in the same vein that psyc works
            
-
            19:15 <@hezekiah> Hence we should provide them with a 'killer-app'.
            
-
            19:15 < jeremiah> ok
            
-
            19:15 < jrand0m> right, IIP is invisible IRC project, and will allow people
            
-
            	 to run IRC
            
-
            19:16 < jrand0m> with no central server (or any server at all, actually),
            
-
            	 theres a lot of thinking to be done to figure out how IRC will work.
            
-
            	 psyc has a possible answer to that
            
-
            19:16 < jrand0m> though there are others
            
-
            19:17 <@hezekiah> As I said, psyc might do better, but people want to use IRC,
            
-
            	 not psyc.
            
-
            19:17 < jrand0m> and they will
            
-
            19:17 < jrand0m> they'll use irc
            
-
            19:17 <@hezekiah> It's all about marketing, baby! ;-)
            
-
            19:17 < jeremiah> I'll try to read the spec and some stuff on psyc tonight
            
-
            19:17 < jrand0m> word
            
-
            19:17 <@hezekiah> lol
            
-
            19:17 < jeremiah> planning to meet at 5:00 UTC tommorow?
            
-
            19:17 <@hezekiah> No?
            
-
            19:18 < jeremiah> or whenever
            
-
            19:18 < jrand0m> I'm on iip 24x7 :)
            
-
            19:18 < jeremiah> yeah but i eat
            
-
            19:18 <@hezekiah> jrand0m: I noticed.
            
-
            19:18 < jrand0m> 05:00 utc or 17:00 utc?
            
-
            19:18 <@hezekiah> jeremiah: LOL!
            
-
            19:18 <@hezekiah> Well the iip-dev meeting officially starts at 21:00 UTC.
            
-
            19:18 -!- Ehud [~logger@anon.iip] has joined #iip-dev
            
-
            19:19 < jeremiah> ok, i just said 05:00 UTC because I was talking out of my ass
            
-
            19:19 < jeremiah> where's mids?
            
-
            19:19 <@hezekiah> mids, left the project for a while.
            
-
            19:19 <@hezekiah> Weren't you there a few meetings back?
            
-
            19:19 < jeremiah> ok
            
-
            19:19 < jeremiah> guess not
            
-
            19:19 <@hezekiah> We had a goodbye party of sorts as part of the agenda.
            
-
            19:19 < jeremiah> oh
            
-
            19:20 <@hezekiah> OK ...
            
-
            19:20 <@hezekiah> Is there anything still on the agenda?
            
-
            19:20  * jrand0m doesn't have any left on mine
            
-
            19:20 < jeremiah> about psyc:
            
-
            19:20 < jeremiah> if this is a psyc feature, I know you mentioned it a
            
-
            	 while ago
            
-
            19:20  * hezekiah never had an agenda in the first placve
            
-
            19:21 <@hezekiah> pace
            
-
            19:21 <@hezekiah> place
            
-
            19:21 < jeremiah> I don't think having each user send a message to every
            
-
            	 other use in the room is s smart idea
            
-
            19:21 <@hezekiah> There!
            
-
            19:21 < jrand0m> jeremiah> so you'd have redundant nominated pseudoservers
            
-
            	 redistribute the messages?
            
-
            19:21 < jrand0m> (pseudoservers = peers in the channel who have the list
            
-
            	 of users)
            
-
            19:21 < jeremiah> I don't think 'broadcasting' is that smart either, but it
            
-
-
            	 seems like it'll require a _lot_ of bandwith for a given user who may be on
            
-
            	 a modem, and with the lag from sending say... 20 messages separately would
            
-
            	 screw up conversation
            
-
            19:21 < jeremiah> I don't know the best solution, maybe that would be one
            
-
            19:22 < jeremiah> I think direct messaging would be good if you wanted it,
            
-
            	 but there are cases where it's probalby not that important
            
-
            19:22 <@hezekiah> The message would need to be signed by the authors private
            
-
            	 key to garuntee authenticity.
            
-
            19:22 <@hezekiah> Though this issue won't matter for a long time still,
            
-
            	 I think jeremiah has a point
            
-
            19:22 < jrand0m> hezekiah> that requires users wanting provable comm :)
            
-
            19:23 < jrand0m> definitely.
            
-
            19:23 <@hezekiah> If I had to send a message to 100 users in a channel ...
            
-
            19:23 < jeremiah> although my average message is only a few hundred bytes,
            
-
            	 so sending it to hundreds of users might not be so hard
            
-
            19:23 <@hezekiah> ... well, my conversation would be /very/ slow.
            
-
            19:23 < jeremiah> especially if you didn't wait for a response
            
-
            19:23 <@hezekiah> 20K to send one message.
            
-
            19:23 <@hezekiah> I don't think so. :)
            
-
            19:23 < jrand0m> well, if there are 100 users in a channel, *someone* has
            
-
            	 to send out 100 messages
            
-
            19:23 < jeremiah> it's 20k?
            
-
            19:23 < jeremiah> oh, right
            
-
            19:23 <@hezekiah> 200 users
            
-
            19:24 < jeremiah> hmm
            
-
            19:24 < jeremiah> wouldn't the routers be good at that?
            
-
            19:24 < jeremiah> we can somewhat safely assume they have decent bandwith,
            
-
            	 right?
            
-
            19:24 <@hezekiah> I thought each person had a 'router implementation'
            
-
            19:24 < jrand0m> not really.  if there are relays, the nomination mechanism
            
-
            	 needs to take that into consideration
            
-
            19:24 < jrand0m> yes hezekiah
            
-
            19:24 < jeremiah> i haven't read the spec
            
-
            19:25 < jrand0m> a router is your local router
            
-
            19:25 <@hezekiah> Ugh!
            
-
            19:25 <@hezekiah> I'm still mixing your nicks up!
            
-
            19:25 <@hezekiah> lol
            
-
            19:25 < jrand0m> hehe
            
-
            19:25 <@hezekiah> Um ... where'd nop go?
            
-
            19:25 <@hezekiah> Oh.
            
-
            19:26 <@hezekiah> He's still here.
            
-
            19:26 <@hezekiah> I thought he was gone for a moment,
            
-
            19:26 < jrand0m> but jeremiah is right, psyc has some ideas we may want to
            
-
            	 consider, though we may want to reject them
            
-
            19:26 <@hezekiah> Let's just get the network running first.
            
-
            19:26  * jrand0m drinks to that
            
-
            19:26 <@hezekiah> If you strech your vision to the finish line, you'll trip
            
-
            	 over the rock 3 inches in front of you.
            
-
            19:27  * jeremiah feels inspired
            
-
            19:27 <@hezekiah> lol
            
-
            19:27 < jrand0m> I think what would be really great if we could aim to review
            
-
            	 the network spec by next week, sending out emails to iip-dev whenever anyone
            
-
            	 has thoughts or comments.  am I out of my mind?
            
-
            19:27 <@hezekiah> nop? Do you have anything else to add to the agenda,
            
-
            	 or do we adjurn?
            
-
            19:27 <@hezekiah> jrand0m: Well, I don't know if I could read all that by
            
-
            	 next week, but I can try. :)
            
-
            19:27 < jrand0m> heh
            
-
            19:28 < jrand0m> its a grueling 15 pages ;)
            
-
            19:28 <@hezekiah> 15 pages?
            
-
            19:28 <@hezekiah> It looked more like 120!
            
-
            19:29 < jrand0m> heh, well, depends on your resolution I suppose ;)
            
-
            19:29 < jeremiah> he has a lot of anchors in there, makes it look like
            
-
            	 it's huge
            
-
            19:29 < jrand0m> hehe
            
-
            19:29 <@hezekiah> The left side has a LOT more than 15 links, budy!
            
-
            19:29 <@hezekiah> 'Fess up!
            
-
            19:29 <@hezekiah> It's more than 15. :)
            
-
            19:29 <@hezekiah> Oh!
            
-
            19:29 <@hezekiah> Those aren't pages! They're just anchors!
            
-
            19:29 <@hezekiah> I'm saved!
            
-
            19:30  * hezekiah feels like a seaman just rescued from drowning
            
-
            19:30 < jeremiah> class turn to volume 4 chapter 2 Message Byte Structure
            
-
            19:30 < jrand0m> lol
            
-
            19:30 <@hezekiah> lol
            
-
            19:30 <@nop> adjourn
            
-
            19:30 <@hezekiah> *baf*!
            
-
            19:30 <@hezekiah> Next week, 21:00 UTC, same place.
            
-
            19:30 <@hezekiah> See y'all there. :)
            
-
            19:30 < jeremiah> seeya
            
-
            --- Log closed Tue Jul 15 19:30:51 2003
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting50.html b/www.i2p2/pages/meeting50.html
deleted file mode 100644
index 27ca0910..00000000
--- a/www.i2p2/pages/meeting50.html
+++ /dev/null
@@ -1,597 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 50{% endblock %}
-{% block content %}
            --- Log opened Tue Jul 22 15:56:06 2003
            
-
            15:56 <@hezekiah> jrand0m: Righto!
            
-
            15:56 -!- mode/#iip-dev [+o jrand0m] by hezekiah
            
-
            15:56 <@cohesion> log enabled
            
-
            15:56 <@jrand0m> w00t
            
-
            15:56 <@nop> we need to add cohesion and remove mids on dev list
            
-
            15:56 <@hezekiah> Excelent. :)
            
-
            15:56 <@hezekiah> What dev list?
            
-
            15:56 <@cohesion> nop: i tried CVS and it wouldn't accept my user/pass
            
-
            15:56 <@nop> ok, I'll add you
            
-
            15:56 <@nop> hold
            
-
            15:56 <@nop> what is your sf id
            
-
            15:56 <@cohesion> cohesion
            
-
            15:56 <@nop> pmsg me if you need
            
-
            15:56 <@nop> ok
            
-
            15:57 <@cohesion> i think
            
-
            15:57 -!- thecrypto [thecrypto@anon.iip] has joined #iip-dev
            
-
            15:57 <@hezekiah> BTW, everyone I will be leaving around 22:15.
            
-
            15:57 <@hezekiah> UTC
            
-
            15:57 <@cohesion> yea
            
-
            15:57 <@cohesion> hezekiah: okay
            
-
            15:58 <@nop> cohesion: you're in
            
-
            15:58 <@nop> we need to update website
            
-
            15:58 <@cohesion> nop: okay
            
-
            15:58 <@cohesion> nop: i'll try it now
            
-
            15:58 <@nop> and we need to start modelling the IIP with an I2P
            
-
            15:58 < thecrypto> hey
            
-
            15:58 < thecrypto> i made it
            
-
            15:58 <@nop> ok
            
-
            15:58 <@nop> werd
            
-
            15:58 <@nop> ;)
            
-
            16:00 <@hezekiah> jrand0m? I just looked at your revision to the
            
-
            development schedual.
            
-
            16:00 <@jrand0m> si sr?
            
-
            16:00 <@hezekiah> The graph with the bars and lines gets chopped off at
            
-
            the right hand side; I can't see the rest of it.
            
-
            16:01 <@jrand0m> yeah, ganttproject isn't quite perfect, but its better
            
-
            than doing it by hand.
            
-
            16:01 <@jrand0m> the things at the far right are the last tasks -
            
-
            nothing is after them
            
-
            16:01 <@hezekiah> But I can
            
-
            16:01 <@jrand0m> the tasks there are listed, in order, on the
            
-
            index-tasks.html
            
-
            16:01 <@hezekiah> can't even see what the tasks are.
            
-
            16:02 <@hezekiah> OK. :) I'll just have to settle for text.
            
-
            16:02 <@hezekiah> nop: Are we going to start soon? I'm going to have to
            
-
            leave at 22:15 UTC, but I'd like to catch as much of the meeting as
            
-
            possible.
            
-
            16:02 <@jrand0m> let me see if I can make a big task to fix that...
            
-
            16:02 <@hezekiah> jrand0m: Thanks. :)
            
-
            16:03 <@nop> yes
            
-
            16:03 <@nop> alright
            
-
            16:03 <@nop> agenda
            
-
            16:03 <@nop> 1)
            
-
            16:03 <@nop> welcome
            
-
            16:03 <@nop> 2)
            
-
            16:03 <@nop> Website future
            
-
            16:03 <@nop> 3)
            
-
            16:03 <@nop> bug fixes with 1.1
            
-
            16:03 <@nop> 4)
            
-
            16:03 <@nop> I2P
            
-
            16:03 <@nop> 5)
            
-
            16:03 <@nop> Suggestions and comments
            
-
            16:03 <@nop> welcome all
            
-
            16:04 <@nop> moving to 2
            
-
            16:04 <@nop> website
            
-
            16:04 <@nop> cohesion, are your maintanance website skills up to par?
            
-
            16:04 <@cohesion> aye
            
-
            16:04 <@cohesion> XHTML and CSS are my specialties
            
-
            16:04 <@nop> ok, we are assuming you can do website stuff, changes etc
            
-
            16:04 <@nop> ok
            
-
            16:04 <@cohesion> yep
            
-
            16:05 <@cohesion> granted that i can get CVS to cooperate :)
            
-
            16:05 <@nop> easy
            
-
            16:05 <@nop> export CVS_RSH=ssh
            
-
            16:05 <@nop> and don't use pserver
            
-
            16:05 <@nop> use d:ext
            
-
            16:05 <@cohesion> i'm using gruntspud to CVS interfacing
            
-
            16:05 <@nop> ok
            
-
            16:05 <@cohesion> it's part of my text editor
            
-
            16:05 <@cohesion> it should work
            
-
            16:05 <@cohesion> we can talk about that later though
            
-
            16:05 <@cohesion> i'm trying it now
            
-
            16:05 -!- thecrypto [thecrypto@anon.iip] has quit [Ping timeout]
            
-
            16:05 <@nop> if you have issues let me know right away if you can, so I
            
-
            can assist this because I have a bunch of tasks
            
-
            16:06 <@nop> also
            
-
            16:06 <@nop> we need to look at making an I2P section
            
-
            16:06 <@nop> since it's going to be the next big project
            
-
            16:06 <@nop> I'll talk to ellison to see if he's contribute a bit of his
            
-
            web design skills to add to that for a template
            
-
            16:06 <@hezekiah> Should I2P be a section of invisiblenet.net or
            
-
            invisiblenet.net/iip? (I vote for the former.)
            
-
            16:06 <@nop> and we can get that hashed out
            
-
            16:06 <@cohesion> ok
            
-
            16:06 <@nop> former as well
            
-
            16:06 <@jrand0m> former
            
-
            16:06 <@nop> it would be under projects
            
-
            16:07 -!- thecrypto [~thecrypto@anon.iip] has joined #iip-dev
            
-
            16:07 <@nop> iip is one project
            
-
            16:07 <@nop> i2p is another
            
-
            16:07 <@hezekiah> So, invisiblenet.net/i2p
            
-
            16:07 <@nop> yes
            
-
            16:07 <@hezekiah> Right. That's the way I see it too. :)
            
-
            16:07 <@nop> anyone here good at making a logo?
            
-
            16:07 <@nop> volunteers are welcome
            
-
            16:07 <@nop> just submit to iip-dev list
            
-
            16:07 <@nop> ok moving on
            
-
            16:07 <@nop> bug fixes in 1.1
            
-
            16:07 <@jrand0m> h/o
            
-
            16:07 * hezekiah would like to point out that his skills at the GIMP are
            
-
            to be avoided like WMD.
            
-
            16:08 <@jrand0m> would it be possible to keep the i2p stuff off the web
            
-
            until we're ready for beta?
            
-
            16:08 <@cohesion> i suggest we use the wiki for collaborating on the i2p
            
-
            documents
            
-
            16:08 <@nop> yes
            
-
            16:08 <@cohesion> i can set up a restricted area
            
-
            16:08 <@nop> that's possible
            
-
            16:08 <@hezekiah> jrand0m: Are you thinking of a big smash announcement
            
-
            on /. or something once we have it in good order?
            
-
            16:08 <@nop> cohesion: I concur
            
-
            16:08 <@jrand0m> yes hezekiah
            
-
            16:08 <@jrand0m> word cohesion
            
-
            16:09 <@nop> ok
            
-
            16:09 <@nop> let's look at 1.1 for a sec
            
-
            16:09 <@nop> hezekiah you made a discovery, that has not to do with
            
-
            focus?
            
-
            16:09 <@nop> or what?
            
-
            16:10 <@hezekiah> The code is fine.
            
-
            16:10 <@hezekiah> The problem is communication, not code.
            
-
            16:10 <@hezekiah> The user has to move the mouse aroung _inside_ the
            
-
            dialog box.
            
-
            16:10 < mihi> the dialog lacks a progress bar to give feedback if the
            
-
            user does it correctly
            
-
            16:10 <@nop> yes that's true
            
-
            16:10 <@hezekiah> He can move the mouse around _outside_ the dialog box
            
-
            until he's blue in the face, but it won't gather entropy. (Which is what
            
-
            these users are doing.)
            
-
            16:10 <@nop> it does lack a dialog box
            
-
            16:11 <@hezekiah> A progress bar would be a plus.
            
-
            16:11 <@hezekiah> And should be somewhat easy to implement ... if I
            
-
            could understand the tangle that UI code in IIP is.
            
-
            16:11 <@cohesion> or even some feedback
            
-
            16:11 <@hezekiah> Anyway, I posted my suggestions to the mailing list.
            
-
            16:12 <@nop> it's in win32 api
            
-
            16:12 <@nop> ;)
            
-
            16:12 <@hezekiah> Either capture the mouse (I couldn't get M$ to
            
-
            cooperate to do that), or make the dialog box message explain to the
            
-
            user he needs to move the mouse around _inside_ the dialog box.
            
-
            16:12 <@hezekiah> nop: I know.
            
-
            16:12 <@nop> fine hezekiah be that way :)
            
-
            16:12 <@hezekiah> What?
            
-
            16:12 <@hezekiah> What did I do?
            
-
            16:12 * hezekiah is confused
            
-
            16:12 < thecrypto> how about just maximize the dialog box?
            
-
            16:12 <@nop> hezekiah: I'm just messin' with ya
            
-
            16:13 <@hezekiah> nop: OK. :)
            
-
            16:13 <@hezekiah> Where's UserX? He knows more about the IIP UI code
            
-
            than I do.
            
-
            16:14 <@hezekiah> thecrypto: As for maximizing, well, the user might not
            
-
            like a rabid dialog box consuming his entire screen.
            
-
            16:14 <@hezekiah> Mouse capture is ideal, but as I said, I couldn't get
            
-
            M$ to do it.
            
-
            16:14 <@jrand0m> many other apps don't capture the mouse
            
-
            16:14 <@jrand0m> a status bar plus explaination seems typical
            
-
            16:15 <@hezekiah> Anyway, that's the 'bug'.
            
-
            16:15 <@hezekiah> How do you want it fixed nop?
            
-
            16:15 <@nop> well
            
-
            16:15 <@nop> I would think if possible we could have a meter that shows
            
-
            the entropy gathering for sure
            
-
            16:16 <@hezekiah> OK.
            
-
            16:16 <@nop> and definitely fixes the language. Have you exhausted the
            
-
            research on capturing the mouse movements?
            
-
            16:16 <@hezekiah> To the point of my patience.
            
-
            16:16 <@hezekiah> Seriously, what I did _should_ work.
            
-
            16:16 <@nop> I assume that's a lot?
            
-
            16:16 <@hezekiah> Well, I didn't get much sleep last night.
            
-
            16:17 <@nop> hmm
            
-
            16:17 <@nop> let's try to get a meter bar and the language fixed
            
-
            16:17 <@nop> that will give us an idea
            
-
            16:17 <@hezekiah> Because it isn't working, I'm assuming the M$ docs are
            
-
            lieing to me (very possible) or something 'unknown' is happening in the
            
-
            IIP UI code.
            
-
            16:17 <@nop> right
            
-
            16:17 <@hezekiah> Righto. :)
            
-
            16:17 * hezekiah now gets down on his knees and prays that UserX wrote
            
-
            UI code for a progress bar.
            
-
            16:19 <@nop> haha
            
-
            16:19 <@nop> if not go to planet-source-code.com
            
-
            16:19 <@nop> there's a lot of samples there
            
-
            16:19 <@hezekiah> The win32 API I can manage (though I detest it.)
            
-
            16:19 <@nop> I hate it as well
            
-
            16:19 <@hezekiah> But UserX/whoever-originally-wrote-this made a wrapper
            
-
            around it.
            
-
            16:19 <@hezekiah> It's the wrapper I'm worried about.
            
-
            16:19 * nop is coding in it right now for work
            
-
            16:19 <@hezekiah> I'm looking into it now.
            
-
            16:20 <@hezekiah> Let's move on to the next agenda item.
            
-
            16:20 -!- jeremiah-gym is now known as jeremiah
            
-
            16:20 <@nop> ok
            
-
            16:20 <@nop> next item is i2p
            
-
            16:20 < jeremiah> hi
            
-
            16:20 <@nop> hi
            
-
            16:20 <@nop> jrand0m you start
            
-
            16:20 <@hezekiah> jeremiah: Just in time!
            
-
            16:20 < jeremiah> hezekiah: nop and I are oddly time synced, as you'll
            
-
            learn
            
-
            16:20 <@jrand0m> 'k, has everyone had a chance to check out the roadmap?
            
-
            16:21 <@hezekiah> Yeah.
            
-
            16:21 <@jrand0m> its obviously draft, and things after the 1.0 milestone
            
-
            are largely up in the air, but its something to start from
            
-
            16:21 <@jrand0m> I've updated it beyond whats on the list to include
            
-
            hezekiah jumping on the C api (w00t!)
            
-
            16:22 -!- jeet [~miteymous@anon.iip] has joined #iip-dev
            
-
            16:22 <@jrand0m> basically, after this coming friday, we'll have the API
            
-
            protocol spec'ed out, which will mean we can parallelize a lot
            
-
            16:22 < jeet> hello ;)
            
-
            16:22 <@jrand0m> 'lo jeet
            
-
            16:23 < jeet> hey if i make a server is it possible to change anon.iip
            
-
            to whatever i want
            
-
            16:23 <@jrand0m> rough gut question: how insane does the r2 roadmap
            
-
            sound? are schedules insane, are there things missing, are things in the
            
-
            wrong order or dependencies not represented?
            
-
            16:23 <@nop> yes
            
-
            16:23 < jeet> kewl
            
-
            16:24 <@hezekiah> jrand0m: I would concur the entire thing is insane.
            
-
            However, I think (until I get to college) it should be doable.
            
-
            16:24 <@jrand0m> heh
            
-
            16:24 < jeet> this is a very cool thing you guys have done ;X
            
-
            16:24 <@hezekiah> Though I'm not sure nop and UserX can design that IRC
            
-
            protocol even in 21 days.
            
-
            16:24 <@hezekiah> nop: ;-)
            
-
            16:24 <@nop> no
            
-
            16:24 <@jrand0m> ok, you're off to uni in late august? mid august? when
            
-
            should we pencil you in for less activity?
            
-
            16:24 <@hezekiah> Around August 20th I'm of.
            
-
            16:24 <@hezekiah> off.
            
-
            16:25 <@jrand0m> 'k
            
-
            16:25 <@hezekiah> Until then I'm a rabid nermal! :)
            
-
            16:25 < jeremiah> I'm off about the same time
            
-
            16:25 < jeremiah> (to univ)
            
-
            16:26 <@nop> ok
            
-
            16:26 <@jrand0m> so we'll have to get more resources on the 'implement
            
-
            IRC' task or just drop the task from the 1.0 release
            
-
            16:26 <@hezekiah> I wouldn
            
-
            16:26 <@hezekiah> wouldn't make the 1.0 release dependant on IRC.
            
-
            16:26 <@nop> I believe that we will need to delay the task
            
-
            16:26 < jeet> [17:23] -anon.iip- CTCP (except ACTION) and DCC are
            
-
            disabled <- how can i stop this from poppiing up every 3 minutes?
            
-
            16:26 <@hezekiah> Do the IRC, but let i2p 1.0 come out when it's ready.
            
-
            16:27 < thecrypto> wow, i'm half way through college as two others just
            
-
            start :)
            
-
            16:27 <@jrand0m> lol
            
-
            16:28 <@jrand0m> I concur hezekiah
            
-
            16:28 <@hezekiah> Cool. I still think i2p will be it's own killer app.
            
-
            :)
            
-
            16:28 <@jrand0m> so that basically means all I2P 1.0 requires after
            
-
            august is a month of debugging and documentation to go from alpha to
            
-
            beta to 1.0
            
-
            16:29 <@jrand0m> hezekiah> definitely. we need to get a demo app out on
            
-
            it first - does the instant messenger app + file transfer sound good to
            
-
            people for that?
            
-
            16:29 -!- jeet [~miteymous@anon.iip] has quit [ircN 7.27 + 7.0 for mIRC
            
-
            (2002/01/10 00.00)]
            
-
            16:29 <@hezekiah> Well, you said it best: 'demo'. From my view, it
            
-
            doesn't need to be special. It just needs to prove the network is worth
            
-
            developing on.
            
-
            16:30 <@hezekiah> So the IM client would be a good demo, in my opinion.
            
-
            16:30 < Zwolly> file transfer is one thing i really would like to see so
            
-
            gimme a demo
            
-
            16:30 <@hezekiah> Zwolly: lol
            
-
            16:30 <@nop> yes
            
-
            16:30 < Zwolly> and see me as an "normal" user
            
-
            16:31 <@hezekiah> Zwolly: You can be our guniea pig! ;-)
            
-
            16:31 * hezekiah starts mixing poisinous code in his lab. ;-)
            
-
            16:31 < Zwolly> hmmm yummie
            
-
            16:32 <@jrand0m> ok, one last thing on i2p
            
-
            16:32 <@nop> sure
            
-
            16:33 <@jrand0m> nop> any chance we can get a non sourceforge trusted
            
-
            cvs server?
            
-
            16:34 <@jrand0m> sourceforge has more problems than these college
            
-
            student's exams
            
-
            16:34 <@nop> yes
            
-
            16:34 <@nop> I will arrange that and have it up by next week
            
-
            16:34 <@jrand0m> awesome. thanks
            
-
            16:34 <@nop> also
            
-
            16:34 <@nop> I may be able to get a compile farm
            
-
            16:34 <@nop> that is not sf
            
-
            16:34 <@nop> with vpn access to it
            
-
            16:35 <@hezekiah> Compile farm!?
            
-
            16:35 <@jrand0m> compile farm? bah, we can just run ant :)
            
-
            16:35 <@hezekiah> jrand0m: All code is not Java.
            
-
            16:35 <@hezekiah> I personally love compile farms.
            
-
            16:35 <@hezekiah> :)
            
-
            16:35 <@jrand0m> ant == make. it can run gcc / etc
            
-
            16:35 <@nop> hezekiah: send me a list of viable platforms we'll need to
            
-
            test on
            
-
            16:35 <@jrand0m> 'k, if we really need the cpu power of a compile farm,
            
-
            thats great
            
-
            16:36 < wilde> what license are you planning to use?
            
-
            16:36 <@nop> GPL
            
-
            16:36 <@jrand0m> GPL cool with everyone for this?
            
-
            16:36 < wilde> k nice
            
-
            16:36 <@hezekiah> I'm very pro GPL.
            
-
            16:36 <@hezekiah> But one warning
            
-
            16:36 <@hezekiah> For the API's we will probably need LGPL. Otherwise
            
-
            all programs made for this network MUST be GPL
            
-
            16:36 <@jrand0m> we may want to go LGPL down the line
            
-
            16:37 <@jrand0m> yeah
            
-
            16:37 <@jrand0m> we MUST not require all apps using I2P to be GPL'ed
            
-
            16:37 <@hezekiah> So the router should be GPL, but the API's will
            
-
            probably need to be LGPL at some time.
            
-
            16:37 <@hezekiah> jrand0m: Then we'll need an LGPL API.
            
-
            16:37 <@hezekiah> The only problem that poses is getting a good crypto
            
-
            kit for C that is compatible with LGPL.
            
-
            16:38 <@hezekiah> I don't think Cryptlib's Sleepycat license is.
            
-
            16:38 <@hezekiah> I could email the author and ask for an exception or
            
-
            something if I need to when the time comes.
            
-
            16:38 <@jrand0m> hezekiah> not need, want. the API comm layer will be an
            
-
            open spec, so anyone can write their own and not link to any of our
            
-
            libraries
            
-
            16:38 <@hezekiah> Right.
            
-
            16:38 <@nop> right
            
-
            16:38 <@hezekiah> So for now we can even make GPL API's if we need to.
            
-
            16:39 <@hezekiah> OK, one question for jrand0m:
            
-
            16:39 < jeremiah> but we should try to have non-viral ones asap
            
-
            16:39 <@hezekiah> I agree.
            
-
            16:39 < wilde> http://www.virtualunlimited.com/products/beecrypt/
            
-
            16:40 < wilde> Bee Crypt is LGPL, i've used once
            
-
            16:40 <@hezekiah> wilde: Beecrypt is far beneath what is required
            
-
            unfortunately.
            
-
            16:40 <@nop> yes
            
-
            16:40 <@nop> I don't think we should use a crypto lib like Beecrypt
            
-
            16:40 <@jrand0m> word wilde
            
-
            16:40 <@cohesion> hezekiah: there's tons of crypto code in
            
-
            GnuPrivacyGuard that's all GPL'd
            
-
            16:40 <@cohesion> you might check and see where it came from
            
-
            16:40 <@hezekiah> cohesion: The problem is we'll need an LGPL C API that
            
-
            uses Crypto.
            
-
            16:41 <@hezekiah> I'll work it out when I get to it.
            
-
            16:41 <@hezekiah> For now, I have two questions for jrand0m: (It's gone
            
-
            up one!) :)
            
-
            16:41 <@jrand0m> we have lots of options. we'll figure it out
            
-
            16:41 <@jrand0m> heh fire away
            
-
            16:42 <@hezekiah> 1.) When the client API spec is done on the 25th will
            
-
            it detail the byte-by-byte structure of the messages sent over the
            
-
            network, and will it detail the specifics on how the crypto is
            
-
            implemented?
            
-
            16:42 -!- ion [ion@anon.iip] has joined #iip-dev
            
-
            16:42 <@jrand0m> yes
            
-
            16:42 <@hezekiah> 2.) Will be we using Twofish? ;-)
            
-
            16:43 <@jrand0m> no, prolly aes, unless someone has a really good reason
            
-
            16:43 <@hezekiah> jrand0m: Was that yes to both questions, or just
            
-
            question 1?
            
-
            16:43 -!- nemesis [nemesis@anon.iip] has joined #iip-dev
            
-
            16:43 <@hezekiah> OK.
            
-
            16:43 <@jrand0m> hezekiah> yes to both
            
-
            16:43 <@nop> well
            
-
            16:43 < nemesis> uuuh, since when there are here ops? :)
            
-
            16:43 <@hezekiah> I really like twofish, but unfortunately AES is easier
            
-
            to find a good lib for.
            
-
            16:44 <@nop> hold
            
-
            16:44 <@hezekiah> nemesis: The English structure of that sentence was
            
-
            too garbled for me to decipher? Whould you like to restate your
            
-
            question?
            
-
            16:44 <@jrand0m> whats special about twofish? why not go with the
            
-
            advanced encryption Standard?
            
-
            16:44 <@hezekiah> nop: Holding ... :)
            
-
            16:44 * jrand0m holds
            
-
            16:44 <@nop> I prefer that we have a suite of encryption options
            
-
            16:44 <@nop> not just aes
            
-
            16:44 <@nop> there are opinions about AES that some people do not feel
            
-
            comfortable using
            
-
            16:44 <@nop> and would rather go with Twofish etc
            
-
            16:44 <@nop> so maybe we can have it be a selection
            
-
            16:44 < wilde> do both :)
            
-
            16:44 <@nop> yes
            
-
            16:44 <@nop> wilde: exactly
            
-
            16:45 <@jrand0m> nop> suites would mean not everyone can send messages
            
-
            to everyone
            
-
            16:45 < jeremiah> but then wouldn't each router have to support both?
            
-
            that seems painful
            
-
            16:45 <@jrand0m> doing both is definitely the case for transport layer,
            
-
            where things can be negotiated
            
-
            16:45 <@nop> not really
            
-
            16:45 <@nop> I would not agree with AES then
            
-
            16:45 <@nop> as if you are paranoid
            
-
            16:45 <@hezekiah> Right. But let's try to too enclude things that are
            
-
            weakening like 3DES.
            
-
            16:45 <@hezekiah> A chain is only as strong as its weakest link.
            
-
            16:45 <@nop> then you'll realize why
            
-
            16:45 <@nop> with the US gov't approvals
            
-
            16:46 <@jrand0m> I don't support AES because it has govt approval, I
            
-
            support AES because it has cryptographers, scientists, and
            
-
            mathematicians approvals.
            
-
            16:46 <@jrand0m> if there is a better one, we can go with that.
            
-
            16:46 <@jrand0m> but I don't want to go with something because its
            
-
            different
            
-
            16:46 <@nop> but the approval of twofish is strong as well amongst
            
-
            cryptographers
            
-
            16:46 <@hezekiah> Well, the last three AES candidates were Rijndael,
            
-
            Twofish, and Serpent.
            
-
            16:46 <@nop> exactly
            
-
            16:47 <@hezekiah> Rijndael was the fastest.
            
-
            16:47 <@hezekiah> Personally, I have more faith in Twofish than
            
-
            Rijndael.
            
-
            16:47 <@jrand0m> nop I think I heard you say there were problems with
            
-
            serpent?
            
-
            16:47 < wilde> use multiple layers of encryption if you have CPU for it
            
-
            16:48 <@jrand0m> wilde> there will be, but thats on a different aspect
            
-
            of things.
            
-
            16:48 <@nop> all I'm saying is that we could have both supported
            
-
            16:48 <@nop> doesn't hurt
            
-
            16:48 <@jrand0m> actually it does hurt
            
-
            16:48 <@jrand0m> segmentation attack
            
-
            16:48 < wilde> ok twofish wrapped in AES could be overkill
            
-
            16:48 <@nop> haha
            
-
            16:48 <@nop> not twofish wrapped in AES
            
-
            16:49 < jeremiah> should we standardize each transport as having one
            
-
            specific set of characteristics (network setup, encryption)?
            
-
            16:49 <@nop> alright for the sake of argument
            
-
            16:49 <@nop> let's do rijndael for this part
            
-
            16:49 < jeremiah> and then we could have one TCP transport supporting
            
-
            AES, one with Twofish, but not one that has to juggle both?
            
-
            16:49 <@jrand0m> jeremiah> yes, particular transports will have
            
-
            particular characteristics, but we're covering the end to end message
            
-
            crypto done in the api atm
            
-
            16:49 <@nop> let's do end to end AES
            
-
            16:49 < jeremiah> jrand0m: ah
            
-
            16:49 <@nop> then node to node twofish option
            
-
            16:50 <@nop> and if you can, do AES-counter mode
            
-
            16:50 <@jrand0m> 'k, sounds good. we can always change later on before
            
-
            release (during peer review, etc)
            
-
            16:50 < wilde> but all crypto algorithms have failed in the past, using
            
-
            double encryption would at least buy time in case of a crypto
            
-
            breakthrough
            
-
            16:50 < jeremiah> not really
            
-
            16:50 <@jrand0m> wilde> the truly paranoid can encrypt with their own
            
-
            system prior to sending messages over the I2P network
            
-
            16:50 <@hezekiah> wilde: If one algorithm is found to be weak, we'll
            
-
            replace it.
            
-
            16:51 <@jrand0m> I2P will just transparently encrypt
            
-
            16:51 < wilde> jrand0m: yes, you're right, there should be a limit to
            
-
            paranoia
            
-
            16:52 <@nop> yes
            
-
            16:52 <@nop> we could go on all day
            
-
            16:52 <@nop> arguing about it
            
-
            16:52 <@nop> AES end to end
            
-
            16:52 <@jrand0m> ok, I don't have anything else on I2P stuff
            
-
            16:52 <@nop> Twofish and others node to node
            
-
            16:52 <@jrand0m> coo'
            
-
            16:53 <@jrand0m> any other I2P stuff, or are we on the next agenda item?
            
-
            16:54 <@hezekiah> I'm done. :)
            
-
            16:54 < wilde> what about A2A, anonymous 2 anonymous?
            
-
            16:54 <@hezekiah> I
            
-
            16:55 <@hezekiah> I've never heard of that. What are you talking about,
            
-
            wilde?
            
-
            16:55 <@jrand0m> I2P is anonymous to anonymous communication
            
-
            16:55 <@jrand0m> I2P = "Invisible Internet Project"
            
-
            16:55 < nemesis> jrand0m: can you send the roadmap as an attechment, and
            
-
            not as inline?
            
-
            16:55 <@jrand0m> (dont make us say I^2P)
            
-
            16:55 <@nop> hushmail has an encrypted messenger
            
-
            16:55 <@nop> neat
            
-
            16:56 <@jrand0m> nemesis> hmm, I tried to - hushmail said it was
            
-
            attached :/
            
-
            16:56 <@hezekiah> nemesis: I got it as attached.
            
-
            16:56 <@jrand0m> nemesis> you can d/l from
            
-
            http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/290
            
-
            16:56 < nemesis> i'm sorry, i can't copy&paste it
            
-
            16:56 <@hezekiah> nemesis: Perhaps your mail reader is the problem? (He
            
-
            sent it as a zip file.)
            
-
            16:56 < nemesis> its inline
            
-
            16:56 < nemesis> theres a zip file...
            
-
            16:56 -!- UserX [~User@anon.iip] has joined #iip-dev
            
-
            16:57 <@jrand0m> 'lo userx
            
-
            16:57 < nemesis> -Hush_boundarfy-31fda3d62329b
            
-
            16:57 <@nop> did anyone log this
            
-
            16:57 < nemesis> Content-Transfer-Encoding: base64
            
-
            16:57 <@hezekiah> cohesion was supposed to.
            
-
            16:57 <@jrand0m> I log all IRC
            
-
            16:57 <@cohesion> i have it all
            
-
            16:57 < thecrypto> yes
            
-
            16:57 <@jrand0m> word
            
-
            16:58 < Zwolly> my ISP also logs all the IRC chatting so what is new
            
-
            16:58 <@jrand0m> lol Zwolly
            
-
            16:58 < Zwolly> hehe
            
-
            16:59 <@hezekiah> Zwolly: Your ISP won't have logs of this. :)
            
-
            16:59 < Zwolly> i hope not if so you guys do a louzy job
            
-
            16:59 <@hezekiah> lol
            
-
            17:00 <@hezekiah> So, I'm assuming we move on to the next agenda item
            
-
            now since we've stopped talking about i2p for a while.
            
-
            17:00 <@nop> yes
            
-
            17:00 <@nop> comments
            
-
            17:00 <@nop> suggestions
            
-
            17:01 <@jrand0m> we, should, like, do some drugs, man
            
-
            17:01 <@hezekiah> jrand0m: Sorry. I refuse to ruin a good mind with such
            
-
            substances.
            
-
            17:01 < wilde> question: isn't the release plan a bit optimistic=
            
-
            17:01 < wilde> ?
            
-
            17:02 <@hezekiah> wilde: lol. Well, my term would be 'insane'. But I
            
-
            think it might be feasible.
            
-
            17:02 <@jrand0m> wilde> good question. it should be plausible, and if
            
-
            any devs on there want to adjust tasks they are working on, we will.
            
-
            17:03 < thecrypto> we can do it!
            
-
            17:04 <@jrand0m> go TEAM!
            
-
            17:04 < wilde> aim high that's good, but it should be realistic
            
-
            17:04 < wilde> do you guys have time enough for the actual programming?
            
-
            17:04 * jrand0m quit his job to work on this, and a few people have
            
-
            summer break coming up
            
-
            17:05 < wilde> i mean september-october that's like 60-90 days
            
-
            17:05 < wilde> ok that's sounds good
            
-
            17:05 <@jrand0m> but don't believe us. we'll release when its ready.
            
-
            17:05 <@hezekiah> jrand0m: BTW, since you quit your job, how are you
            
-
            going to eat while you code this?
            
-
            17:05 < jeremiah> wilde: we're going to be implementing lots of it in
            
-
            high-level languages and then re-coding in C later
            
-
            17:05 <@jrand0m> hezekiah> I eat code
            
-
            17:05 <@hezekiah> I was afraid you'd say something like that.
            
-
            17:06 <@jrand0m> ;)
            
-
            17:06 <@hezekiah> I just hope you've got a good nest egg to live on.
            
-
            17:06 < jeremiah> jrand0m: my code eats random numbers
            
-
            17:06 < jeremiah> that might make a bad loop
            
-
            17:06 <@hezekiah> ROTFL!
            
-
            17:07 < wilde> drinking java, eating python, roasted ant, could go
            
-
            17:07 <@jrand0m> but bugs have lots of protien
            
-
            17:07 * jrand0m !thwaps self
            
-
            17:07 <@jrand0m> ok, do we have other questions / comments /
            
-
            suggestions?
            
-
            17:07 <@hezekiah> Well, I've got to go now.
            
-
            17:07 <@hezekiah> Bye everyone. :)
            
-
            17:07 <@jrand0m> or are we actually finishing up in under an hour?
            
-
            17:07 -!- hezekiah [hezekiah@anon.iip] has quit [Client exiting]
            
-
            17:07 <@jrand0m> lol wilde
            
-
            17:08 <@jrand0m> nop> got anything or we done?
            
-
            17:10 -!- UserX [~User@anon.iip] has quit [Ping timeout]
            
-
            17:10 -!- wilde [anon@anon.iip] has quit []
            
-
            17:10 <@cohesion> ok, i'm ending the meeting
            
-
            17:11 < nemesis> STOP!
            
-
            17:11 <@cohesion> nop: i'll get with you about CVS tomarrow
            
-
            17:11 * jrand0m stops
            
-
            17:11 < nemesis> ganttproject-1.9.7.jar
            
-
            17:11 <@cohesion> GO!
            
-
            17:11 < nemesis> how it works?
            
-
            17:11 <@nop> ok
            
-
            17:11 <@nop> also
            
-
            17:11 <@nop> aes
            
-
            17:11 <@jrand0m> nemesis> just double click on it with java 1.4.2
            
-
            installed
            
-
            17:11 <@nop> we should use 256 bit as a norm
            
-
            17:11 < nemesis> i have java 1.4.2...
            
-
            17:11 <@jrand0m> nemesis> I'll email out the xml with the project info
            
-
            17:12 <@jrand0m> word nop, definitely
            
-
            17:13 < nemesis> Could not find the main class. Program will exit!
            
-
            17:13 < nemesis> hm.. i think my java are broken.... Title of the
            
-
            Window: Java Virtual Machine Launcher...
            
-
            17:14 <@jrand0m> weird nemesis, works for me... make sure its loading it
            
-
            with the 1.4.2 jvm and not the windows jvm
            
-
            17:14 <@jrand0m> ah, try running from the cmd.exe command line
            
-
            17:14 < nemesis> eh?
            
-
            17:14 < nemesis> k
            
-
            17:14 < nemesis> then i write a .bat for it, like for columba :)
            
-
            17:14 <@cohesion> ok, i'm closing the logs
            
-
            17:14 <@jrand0m> (and type java -version first to make sure it uses the
            
-
            right one)
            
-
            17:14 <@jrand0m> heh word
            
-
            17:14 <@cohesion> everyone say "cheese"
            
-
            17:14 <@jrand0m> queso
            
-
            17:14 < thecrypto> cheese
            
-
            17:15 < Zwolly> chesse
            
-
            17:15 < Zwolly> cheese
            
-
            17:15 < nemesis> E:\Sytemprogramme\server\Projektverwaltung>java
            
-
            ganttproject-1.9.7.jar
            
-
            17:15 < nemesis> Exception in thread "main"
            
-
            java.lang.NoClassDefFoundError: ganttproject-1/9/7/ja
            
-
            17:15 < nemesis> r
            
-
            17:16 <@jrand0m> java -jar ganttproject-1.9.7.jar
            
-
            17:16 < nemesis> java version "1.4.2-beta"
            
-
            17:16 < nemesis> Java(TM) 2 Runtime Environment, Standard Edition (build
            
-
            1.4.2-beta-b19)
            
-
            17:16 < nemesis> Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed
            
-
            mode)
            
-
            17:16 < nemesis> hm... why with -jar?
            
-
            17:16 < nemesis> now it works...
            
-
            17:17 -!- ion [ion@anon.iip] has quit [Ping timeout]
            
-
            17:17 < nemesis> thx jrand0m
            
-
            17:17 <@jrand0m> without -jar asks it to load the class
            
-
            ganttproject-1/9/7/jar
            
-
            17:17 <@jrand0m> np
            
-
            17:17 < jeremiah> is cvs working?
            
-
            17:17 < jeremiah> i checked out earlier today, but it's weird now
            
-
            17:17 <@jrand0m> sourceforge is being a pain atm
            
-
            --- Log closed Tue Jul 22 17:18:14 2003
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting51.html b/www.i2p2/pages/meeting51.html
deleted file mode 100644
index 30ba4fc9..00000000
--- a/www.i2p2/pages/meeting51.html
+++ /dev/null
@@ -1,886 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 51{% endblock %}
-{% block content %}
            
-
            --- Log opened Tue Jul 29 16:54:31 2003
            
-
            17:11 <@hezekiah> Tue Jul 29 21:11:18 UTC 2003
            
-
            17:11 <@hezekiah> The 51th (I think) iip-dev meeting.
            
-
            17:11 <@hezekiah> Agenda:
            
-
            17:11 <@hezekiah> 1.) Welcome
            
-
            17:11 <@hezekiah> 2.) jrand0m's stuff
            
-
            17:11 <@hezekiah> 3.) Any of the other developer's stuff
            
-
            17:11 <@hezekiah> 4.) Anything nop adds when/if he gets here
            
-
            17:12 <@hezekiah> 5.) Questions and Comments from the ever eager unwashed
            
-
            	 masses. ;-)
            
-
            17:12 <@hezekiah> OK!
            
-
            17:12 <@hezekiah> Welcome everyone to the 51th (I think) iip-dev meeting
            
-
            17:12 <@hezekiah> Item number 2!
            
-
            17:12 <@hezekiah> jrand0m's stuff
            
-
            17:12 -!- thetower [none@anon.iip] has joined #iip-dev
            
-
            17:12  * hezekiah hands the mike to jrand0m
            
-
            17:12 <@jrand0m> sub-agenda:
            
-
            17:12 <@jrand0m> 2.1) I2CP spec & dev status
            
-
            17:12 < co> Where are the logs for meeting 50?
            
-
            17:12 <@jrand0m> 2.2) SDK plans
            
-
            17:12 <@jrand0m> 2.3) crypto
            
-
            17:12 <@jrand0m> 2.4) roadmap / network proto status
            
-
            17:13 <@hezekiah> co: cohesion is working on getting them up
            
-
            17:13 <@jrand0m> (btw, its "mic", for microphone)
            
-
            17:13 <@hezekiah> jrand0m: Sorry. :)
            
-
            17:13 <@hezekiah> jrand0m: (And this mistake from a sound tech guy!)
            
-
            17:13 -!- luckypunk [~yetalohe@anon.iip] has joined #iip-dev
            
-
            17:13 -!- odargur [odargur@anon.iip] has joined #iip-dev
            
-
            17:13 <@jrand0m> 2.1) I2CP: the spec is committed to CVS with a slight mod
            
-
            	 to one of the messages (MessageStatusMessage)
            
-
            17:14 <@jrand0m> Comments are always welcome on I2CP, but the sooner the
            
-
            	 better.
            
-
            17:14 <@hezekiah> jrand0m: Where's the spec in CVS? ... and is it on the SF
            
-
            	 CVS too?
            
-
            17:14 <@jrand0m> The reason for sooner the better is that we'll have a
            
-
            	 working Java client implementation by friday.
            
-
            17:14 -!- some_random_guy [~dan@anon.iip] has joined #iip-dev
            
-
            17:14  * thecrypto crosses fingers on that one
            
-
            17:14 <@jrand0m> Plus a local only router by the end of the weekend, I'm hoping
            
-
            17:15 <@jrand0m> no hez, only on the cathedral
            
-
            17:15 <@jrand0m> good point thecrypto.
            
-
            17:15 <@jrand0m> Caveat:
            
-
            17:15 <@hezekiah> Ugh. I still can't get CVS to work with cathedral.
            
-
            17:15 <@jrand0m> some crypto isn't 100%, but its all stub'ed to let us plug
            
-
            	 in more complete or other implementations later
            
-
            17:15 <@jrand0m> hezekiah> we'll get you up after the meeting.
            
-
            17:15 <@hezekiah> jrand0m: Thanks. :)
            
-
            17:16 <@jrand0m> the spec is in the
            
-
            	 i2p/doc/specs/data_structure_spec/datastructures.html
            
-
            17:16 <@jrand0m> thecrypto> do you have anything to add re: java impl?
            
-
            17:16 -!- ArdVark [simple1@anon.iip] has joined #iip-dev
            
-
            17:16 <@jeremiah> the local-only router you mentioned was the python one,
            
-
            	 right? or is there a java one too?
            
-
            17:17 <@jrand0m> that all depends :)
            
-
            17:17 <@jrand0m> jeremiah/hezekiah> how goes the python client and local-only
            
-
            	 router?
            
-
            17:17 <@thecrypto> not really, except for the crypto issue i think we'll
            
-
            	 talk about in a bit
            
-
            17:17 <@jrand0m> word thecrypto.
            
-
            17:17 <@hezekiah> jrand0m: It's coming. I finally got the TCP transport
            
-
            	 stuff working yesterday.
            
-
            17:17 <@jeremiah> it seems ok, i think most of it will be dependent on
            
-
            	 hezekiah's dev speed more than mine
            
-
            17:17 <@hezekiah> jrand0m: Jeremiah has some nice stuff going with the
            
-
            	 message strcutures.
            
-
            17:18 <@hezekiah> hezekiah: I'm hoping that we can make the deadline.
            
-
            17:18 <@jrand0m> cool.
            
-
            17:18 <@jeremiah> also... friday is my birthday, so I plan on not being
            
-
            	 around the computer then
            
-
            17:18 <@hezekiah> jeremiah: Understandable. :)
            
-
            17:18 <@hezekiah> jeremiah: And happy birthday in advance. :)
            
-
            17:18 <@jeremiah> thanks
            
-
            17:18 <@jrand0m> jumping slightly to agenda 2.4> when would we expect to be
            
-
            	 able to have the python local only router?  realistically?
            
-
            17:19 <@jrand0m> word, if you code on friday I'll kick your ass
            
-
            17:19 <@jrand0m> virtually, at least
            
-
            17:19 <@hezekiah> jrand0m: I thought that's what I'm coding. The Python
            
-
            	 local only router.
            
-
            17:19 <@jrand0m> si, that you are
            
-
            17:19 <@hezekiah> Well the deadline is August 1st.
            
-
            17:19 <@jeremiah> right now we're working on message to-from binary format
            
-
            	 stuff
            
-
            17:19 <@hezekiah> That's not that hard.
            
-
            17:19 <@jeremiah> right
            
-
            17:19 <@hezekiah> I'm hoping to have that done in a day or two.
            
-
            17:20 <@jrand0m> thats friday :)
            
-
            17:20 <@jrand0m> awesome
            
-
            17:20 <@hezekiah> I hope it will be done by August 1st. Realistically it
            
-
            	 might be a few days late, but I hope not.
            
-
            17:20 <@jrand0m> 'k, I'll hold off on touching any java local only stuff
            
-
            	 then and work on the network spec after the java client api is set.
            
-
            17:20 <@hezekiah> Yes. Specs are good.
            
-
            17:21 <@hezekiah> They make my job a LOT easier! :)
            
-
            17:21 <@jrand0m> word.
            
-
            17:21 <@jrand0m> I'll write up a quick 2 paragraph run through of the java
            
-
            	 I2CP test harness too
            
-
            17:21 <@jrand0m> I'll get that out tonight
            
-
            17:22 <@hezekiah> jrand0m: I love how you get these specs written so fast.
            
-
            17:22 <@hezekiah> This is fun. :)
            
-
            17:22 <@jrand0m> Ok, hez/jeremiah/thecrypto> anything else on I2CP?
            
-
            17:22 <@jrand0m> lol
            
-
            17:22 -!- dm [~hifi@anon.iip] has joined #iip-dev
            
-
            17:22 <@hezekiah> Um ...
            
-
            17:22 <@hezekiah> I want the crypto spec!
            
-
            17:22 < dm> welcome
            
-
            17:22  * hezekiah pouts like a baby
            
-
            17:22 <@hezekiah> ;-)
            
-
            17:23 <@hezekiah> Seriously, ... I can't think of anything.
            
-
            17:23 <@jrand0m> thats agenda item 2.3
            
-
            17:23 <@thecrypto> still waiting for 2.3 to come up
            
-
            17:23 <@hezekiah> If I do, I'll just come online and pester you with questions,
            
-
            	 jrand0m. :)
            
-
            17:23 <@jrand0m> word.
            
-
            17:23 <@jrand0m> ok.  2.2) SDK plans
            
-
            17:23 <@hezekiah> What agenda point did we just finish?
            
-
            17:23 <@hezekiah> 2.4?
            
-
            17:23 <@hezekiah> And have we finished 2.1 yet?
            
-
            17:23 <@jrand0m> 2.1
            
-
            17:24 <@jrand0m> now 2.2> the SDK
            
-
            17:24 <@hezekiah> OK.
            
-
            17:24 < dm> agenda has decimal point in it now? I see progress already.
            
-
            17:24 <@hezekiah> I'm found now (as opposed to lost).
            
-
            17:24 <@thecrypto> we might have 2 decimal points :)
            
-
            17:25 <@jeremiah> what makes up the SDK apart from the various APIs?
            
-
            17:25 <@jrand0m> the SDK is: the client API (as many as we have available), the
            
-
            	 local only router, a trivial sample app, and some docs on how to use the APIs.
            
-
            17:25 <@hezekiah> jrand0m: Would I be correct in assuming that you're writing
            
-
            	 the docs? :)
            
-
            17:26 <@jrand0m> I'd like to have the SDK released asap, so that 3rd (or
            
-
            	 even 2nd or 1st) party developers can write and test applications that will
            
-
            	 run over I2P, so once the network is operational, we'll hit the ground running.
            
-
            17:26 <@jrand0m> hezekiah> I'd actually prefer not to.
            
-
            17:26 <@jrand0m> hezekiah> and I say that not because I don't want to document,
            
-
            	 but because I'm too close to it.
            
-
            17:26 <@hezekiah> jrand0m: OK.
            
-
            17:26 <@jrand0m> we should have somone who *doesn't* actually implement the
            
-
            	 code write that doc, so it can be understandable to people who didn't write
            
-
            	 the I2CP spec
            
-
            17:26 <@hezekiah> jrand0m: We'll cross that bridge when we get there.
            
-
            17:26 <@jrand0m> but if need be, I'll jump on it.
            
-
            17:26 <@jrand0m> word.
            
-
            17:27 < dm> what incentive do people have to write apps without an operational
            
-
            	 network, and how would they even test their app.
            
-
            17:27 <@hezekiah> jrand0m: Or why don't someone who designed the protocol
            
-
            	 write it, and then have someone who never worked with it go over it until
            
-
            	 it makes sense?
            
-
            17:27 <@jrand0m> Ok, there has been some discussion of a simple 'talk'
            
-
            	 style app.
            
-
            17:27 <@jrand0m> dm> people will be able to test with the SDK.
            
-
            17:27 <@thecrypto> actully, i was wondering what would be the use of that
            
-
            	 if it's local only
            
-
            17:28 <@jeremiah> dm: the idea is to implement a simple network that isn't
            
-
            	 fully functional but can pass messages
            
-
            17:28 <@thecrypto> you'd only be able to talk to yourself
            
-
            17:28 <@jeremiah> it's not actually local-only, but it only includes
            
-
            	 client-router, not router-router code
            
-
            17:28 <@jrand0m> thecrypto> you can talk to other Destinations. I2P is
            
-
            	 location independent - local is the same as remote.
            
-
            17:29 <@thecrypto> okay
            
-
            17:29 < dm> nice and all, I just don't see anyone (besides you 3-4) writing
            
-
            	 anything if you can only test locally. But anyway, doesn't matter.
            
-
            17:29 <@jrand0m> so a talk app can open up two instances of the application
            
-
            	 and talk to oneself, etc
            
-
            17:30 <@thecrypto> but when we add the remote stuff, the app should just work
            
-
            17:30 <@jrand0m> dm> right, this is just a prereq for having other people
            
-
            	 write apps.
            
-
            17:30 <@jrand0m> exactly.
            
-
            17:30 <@jrand0m> the app will work with absolutely NO changes
            
-
            17:30 < co> dm: This is a test application. Once the router-router code is
            
-
            	 written, you will be able to talk to others.
            
-
            17:30 <@jeremiah> having local-only just lets us develop in parallel
            
-
            17:30 < dm> yes, but if the app assumes 10 ms latency, and it ends being 12
            
-
            	 seconds, it won't work too well :)
            
-
            17:31 <@jrand0m> agreed dm
            
-
            17:31 < dm> any estimates on latency btw? :)
            
-
            17:31 <@jrand0m> if we have 12 second latency, we have work to do.
            
-
            17:31 <@jrand0m> we won't have that though.
            
-
            17:31 <@jrand0m> estimates are .6-2.7sec
            
-
            17:31 <@jrand0m> for a 5,000,000 router network.
            
-
            17:31 <@hezekiah> BTW, that reminds me. We need to talk about ElGamal.
            
-
            17:31 <@thecrypto> the longest time is setup
            
-
            17:31 <@jrand0m> (see iip-dev archives for the rudimentary models)
            
-
            17:31 < dm> lower or higher for smaller networks?
            
-
            17:32 <@jrand0m> hezekiah> 2.3: crypto.
            
-
            17:32 <@thecrypto> after that the time the drops dramatically
            
-
            17:32 <@jrand0m> dm> lower.
            
-
            17:32 <@thecrypto> hezekiah: you prolly have the same question as i
            
-
            17:32 <@jrand0m> thecrypto> exactly, setup time is offline for message
            
-
            	 delivery though [aka set up tunnels prior to sending messages]
            
-
            17:32 < dm> ok, just checking you ;)
            
-
            17:32 <@jrand0m> heh
            
-
            17:33 <@jrand0m> ok.  last part of the SDK - the app
            
-
            17:33 <@jrand0m> co/thecrypto: thoughts on a java talk impl?  workable?
            
-
            	 time?  plans?  interest?
            
-
            17:34 <@thecrypto> once the API is up, we can prolly have a talk done in
            
-
            	 about a week or so, 2 tops, co agrre?
            
-
            17:34 <@jeremiah> chat could be built in as a jabber router, right?
            
-
            17:34 < co> That should be fairly easy to do.
            
-
            17:34 < co> thecrypto: I agree.
            
-
            17:34 <@jrand0m> jeremiah> I don't know jabber, but if jabber can run over
            
-
            	 the api, cool
            
-
            17:35 <@jrand0m> word co & thecrypto
            
-
            17:35 <@jrand0m> jeremiah> note that this is just a trivial app to do proof
            
-
            	 of concept with, not a Kickass Anonymous IM System :)
            
-
            17:35 <@jeremiah> not yet ;)
            
-
            17:35 <@thecrypto> we can add that functionallity later
            
-
            17:35 <@jeremiah> k
            
-
            17:36 <@jrand0m> heh
            
-
            17:36 <@thecrypto> let's start small
            
-
            17:36  * jrand0m puts in the schedule "add feature: be kickass"
            
-
            17:36 < some_random_guy> heh
            
-
            17:36 < some_random_guy> nice feature :)
            
-
            17:36 -!- dm2 [~hifi@anon.iip] has joined #iip-dev
            
-
            17:37 <@jeremiah> jrand0m: I think I missed this in 2.1, but any thoughts
            
-
            	 on kademlia as a DHT? it requires less upkeep than Chord
            
-
            17:37 -!- nop [nop@anon.iip] has joined #iip-dev
            
-
            17:37 < nop> sorry
            
-
            17:37 <@jrand0m> plus one of these days we need to get someone on the IIP
            
-
            	 redesign to run over this.
            
-
            17:37 -!- dm [~hifi@anon.iip] has quit [Ping timeout]
            
-
            17:37 < nop> what?
            
-
            17:37 < nop> who
            
-
            17:37 < nop> where
            
-
            17:37 < nop> when
            
-
            17:37 < nop> ?
            
-
            17:37 -!- dm2 is now known as dm
            
-
            17:37 <@jrand0m> hey, speakin of the devil
            
-
            17:37 < WinBear> why?
            
-
            17:37 < WinBear> nm
            
-
            17:37 < nop> I'm an angel actually
            
-
            17:37 <@hezekiah> lol
            
-
            17:38 <@thecrypto> someone hand nop a log
            
-
            17:38 < WinBear> azrel
            
-
            17:38 <@jrand0m> jeremiah> kademila is a good DHT, and we will definitely
            
-
            	 review that plus the chord/tapestry crew, along with sloppy dhts in the
            
-
            	 network spec.
            
-
            17:38 <@jeremiah> jrand0m: cool
            
-
            17:38 <@hezekiah> thecrypto: I'm working on it. :)
            
-
            17:38 < nop> I was hearing of one that kicks but
            
-
            17:38 < nop> called chord/middle
            
-
            17:38 -!- hif [~hifi@anon.iip] has joined #iip-dev
            
-
            17:39 < nop> but you know who is good to talk to his brandon wiley
            
-
            17:39  * jrand0m !thwaps nop
            
-
            17:39 < nop> I knew that would hurt
            
-
            17:39 <@hezekiah> lol
            
-
            17:39 <@hezekiah> Who's Brandon Wiley?
            
-
            17:39 < nop> someone I'm sure jrand0m has been in numerous discussions with
            
-
            17:39 < nop> :)
            
-
            17:39 < nop> someone email me a log
            
-
            17:39 < dm> Brandon is jrandom's real name, busted!
            
-
            17:39 <@hezekiah> I'm working on it.
            
-
            17:40 <@hezekiah> Hold you horses, nop. :)
            
-
            17:40 < nop> haha
            
-
            17:40 < dm> Brandon Wiley is the first Freenet programmer, having
            
-
            17:40 < dm> co-founded the development effort with the system's inventor,
            
-
            	 Ian Clarke
            
-
            17:40 < nop> is userx here or there
            
-
            17:40 < WinBear> you can talk to my brandon wiley
            
-
            17:40 <@hezekiah> OK. It's on the way ... if my mail client will cooperate
            
-
            	 and send a 15K attachement.
            
-
            17:41 <@thecrypto> we've talked alot :)
            
-
            17:41 <@hezekiah> nop: UserX is niether hither or thither.
            
-
            17:41 <@hezekiah> OK!
            
-
            17:41 <@hezekiah> The log is sent nop! Go read. :)
            
-
            17:41 <@thecrypto> and now we wait
            
-
            17:41 <@jrand0m> ok, anyone have any SDK thoughts while we give nop a min
            
-
            	 to catch up? ;)
            
-
            17:41 <@hezekiah> jrand0m: Now that I've gotten that log business done
            
-
            	 ... what's kademlia?
            
-
            17:42 <@jrand0m> Yet Another Academic DHT :)
            
-
            17:42 <@hezekiah> And where I can get a link to kademlia's webpage?
            
-
            17:42 -!- Erazerhead [JohnDoe@anon.iip] has joined #iip-dev
            
-
            17:42 <@jeremiah> http://kademlia.scs.cs.nyu.edu/
            
-
            17:42 <@hezekiah> Thanks. :)
            
-
            17:42 <@thecrypto> YAADHT?
            
-
            17:42 <@hezekiah> lol
            
-
            17:42 <@hezekiah> Names these days ... I tell ya'!
            
-
            17:43 <@jrand0m> and if there's ever any CS stuff mentioned that you don't
            
-
            	 understand, go to citeseer.nj.nec.com/cs
            
-
            17:43 < WinBear> klamidia?
            
-
            17:43 <@hezekiah> OK.
            
-
            17:43 < nop> jrand0m: I was just about to say citeseer
            
-
            17:43 < dm> what's the ETA on the SDK?
            
-
            17:44  * jrand0m avoids injecting the clap into I2P
            
-
            17:44  * jrand0m hopes the SDK will be out next week.  perhaps next friday?
            
-
            17:44  * thecrypto crosses another pair of fingers
            
-
            17:45 <@jrand0m> ok.  moving on to 2.3) Crypto.
            
-
            17:45  * hezekiah imagines thecrypto with about 13 sets of fingers crossed
            
-
            	 ... and then realized that he must have run out by now.
            
-
            17:45 <@hezekiah> Yay!
            
-
            17:45  * jrand0m pokes nop to make sure he's here
            
-
            17:45 <@hezekiah> Crypto!
            
-
            17:45 <@hezekiah> I have something to start us off with. :)
            
-
            17:46 <@thecrypto> i have something too
            
-
            17:46 <@thecrypto> Dibs! :)
            
-
            17:46  * jrand0m doesn.t so you two fight it out
            
-
            17:46 <@hezekiah> thecrypto can go first. :)
            
-
            17:46 <@jrand0m> thecrypto> speak
            
-
            17:46 <@jrand0m> :)
            
-
            17:46 <@thecrypto> Ok, on Elgamal
            
-
            17:47 <@thecrypto> We have to figure out whether or not we have common p
            
-
            	 and alpha
            
-
            17:47 -!- some_random_guy [~dan@anon.iip] has quit [BitchX: the original
            
-
            	 point-and-click interface.]
            
-
            17:47 <@thecrypto> the problem with a common p and alpha is that we'd have
            
-
            	 to find someway to change everyone's keys at the same time
            
-
            17:48 <@jrand0m> aka: really bad.
            
-
            17:48 < co> thecrypto: Sorry, what are p and alpha?
            
-
            17:48 <@thecrypto> the advantage is that we can pick specially optimized
            
-
            	 ones and the amount of data transmitted for a public key is very small
            
-
            17:48  * jrand0m sees no good reason to use common p and alpha, beyond saving
            
-
            	 a few bits
            
-
            17:48 <@thecrypto> co: for all intensive purposes, special big numbers
            
-
            17:49 <@jrand0m> thecrypto> we can still optimize for commonly encrypted to
            
-
            	 destination's p and alpha
            
-
            17:49 <@thecrypto> or should i go into an explaination of how elgamal workds
            
-
            17:49 <@thecrypto> jrand0m: yes
            
-
            17:49 < co> thecrypto: OK.
            
-
            17:49 <@thecrypto> we can also have everyone have a different p and alpha
            
-
            17:50 <@jeremiah> for those who are interested:
            
-
            	 http://www.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem
            
-
            17:50 <@thecrypto> this means that the amount of data transmitted is much
            
-
            	 larger and we have to figure out how to pack it in
            
-
            17:50 <@jrand0m> word, thanks jeremiah
            
-
            17:50 <@jrand0m> much larger?
            
-
            17:50 <@jrand0m> I thought with varying p and alpha we can use smaller p
            
-
            	 and alpha?
            
-
            17:51 <@thecrypto> instead of 160 bit numbers we are now talking 2 1024 bit
            
-
            	 and 1 160
            
-
            17:51 <@thecrypto> or overall 2308
            
-
            17:51 <@hezekiah> 288 bytes
            
-
            17:51 <@hezekiah> Big deal.
            
-
            17:52 <@jrand0m> ok, thats not too bad.  we've planned on 256bytes
            
-
            17:52 <@hezekiah> These keys aren't transfered all that often, are they?
            
-
            17:52 <@jrand0m> another 32 doesn't hurt
            
-
            17:52 <@jrand0m> hezekiah> they're inserted into the DHT
            
-
            17:52 <@hezekiah> Ah!
            
-
            17:52 <@hezekiah> That's why we wanted it small.
            
-
            17:53 <@thecrypto> also, another problem about elgamal we might also have
            
-
            	 to worry about
            
-
            17:53 <@jrand0m> well, it doesn't really hurt if the RouterInfo structure
            
-
            	 is about 10K or so
            
-
            17:53 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev
            
-
            17:53 <@jrand0m> 'k, s'up thecrypto?
            
-
            17:53 <@thecrypto> message expansion is 2, the size of an encryption or a
            
-
            	 signature is twice the size of the message
            
-
            17:54 <@jrand0m> ElG encryption is only of the AES key
            
-
            17:54 <@jrand0m> ElG signature is only of the SHA256 hashes
            
-
            17:55 <@thecrypto> okay, it's just something to bring up as well
            
-
            17:55 <@hezekiah> jrand0m: Which makes me _really_ puzzled.
            
-
            17:55 <@thecrypto> now back to the original issue, do we want to have a
            
-
            	 shared p and alpha or do we want everyone to have different p and alphas?
            
-
            17:55 <@jrand0m> hezekiah> hmm?  you read the data structure spec for
            
-
            	 #Payload ?
            
-
            17:55 <@jrand0m> any thoughts/questions on that hezekiah?
            
-
            17:55  * dm now understands how DHTs work.
            
-
            17:55 <@jrand0m> nop> thoughts?
            
-
            17:55 <@jrand0m> awesome dm
            
-
            17:55 <@hezekiah> If a signature is twice the size of the data signed,
            
-
            	 then why does the IC2P spec say a signature is 128 bytes?
            
-
            17:56 < nop> no
            
-
            17:56 < nop> shared p
            
-
            17:56 <@hezekiah> Shouldn't it bee 512?
            
-
            17:56 <@thecrypto> the hash of the bytes
            
-
            17:56 < nop> and alphas
            
-
            17:56 < dm> seems like a lot of work is required when joining a DHT, but I
            
-
            	 guess it works.
            
-
            17:56 < nop> shared base, shared p
            
-
            17:56 <@jrand0m> hezekiah> bits / bytes.
            
-
            17:56 < nop> this will eliminate a lot of risk
            
-
            17:56 <@thecrypto> then how big do we want it?
            
-
            17:56 <@hezekiah> Hmm
            
-
            17:56 <@jrand0m> nop> in 3 years, will we want to have everyone change their
            
-
            	 p and alpha at the same time?
            
-
            17:56 < nop> and hold our protocol to standards
            
-
            17:57 <@thecrypto> since it does open up that p and alpha huge attacks
            
-
            17:57 < nop> jrand0m: there is such a thing called cooked primes, at this
            
-
            	 time, and this is the time I'm looking at
            
-
            17:57 <@thecrypto> which if completed bring the entire network down
            
-
            17:57 < nop> I believe we can modify with the times
            
-
            17:57 < nop> but a static oakley approved prime is advised
            
-
            17:57 < nop> as they have been reviewed thoroughly as secure
            
-
            17:58 < nop> and that is a better basis than any of our assumptions about
            
-
            	 primes being generated (probable at that)
            
-
            17:58 <@thecrypto> if it's not prime, encryption or signatures won't work
            
-
            	 so we just throw it our
            
-
            17:59 <@jrand0m> agreed, they have better primes.  so when one of those
            
-
            	 primes are factored, everyone using them is exposed, correct?
            
-
            17:59 < dm> hmmm, I gotta go. This is logged right?
            
-
            17:59 < nop> jrand0m: yes
            
-
            17:59 <@thecrypto> yup
            
-
            17:59 < nop> jrand0m: when that happens we'll all know
            
-
            17:59 < nop> I don't want to risk prime generation
            
-
            17:59 -!- dm [~hifi@anon.iip] has quit [it better be]
            
-
            17:59 <@thecrypto> how will we know?
            
-
            17:59 < nop> plus it adds to our calculation time
            
-
            17:59 -!- hif [~hifi@anon.iip] has quit []
            
-
            17:59 < nop> thecrypto: if you use a standard defined Oakley prime set,
            
-
            	 you will know when it's been cracked
            
-
            18:00 <@thecrypto> how?
            
-
            18:00 < nop> as it will be very public news
            
-
            18:00 <@jrand0m> nop> we'll know unless the NSA cracks it.
            
-
            18:00 < co> nop: How many of those primes are there? If not many, using them
            
-
            	 is a risk.
            
-
            18:00 <@thecrypto> yeah, passive evesdropping is still a threat
            
-
            18:00 <@thecrypto> and i can make a program to generate ps and alphas and
            
-
            	 test them in about an hour
            
-
            18:00 <@jrand0m> nop> it would be very public news unless it was a threat
            
-
            	 to national security.
            
-
            18:00 < co> Wait... no, that's a stupid question. Never mind.
            
-
            18:01 < nop> this is true, but I believe from numerous contacts in the
            
-
            	 cryptography community that if it's solved it will be solved before the NSA
            
-
            	 does it
            
-
            18:01 < nop> our prime generation will not secure that either way
            
-
            18:01 < nop> if they solve those primes
            
-
            18:01 < nop> you may as well figure out a new algo to use
            
-
            18:01 <@jrand0m> 'k.
            
-
            18:02 < nop> please use static, it will relieve problems with cryptanalysis,
            
-
            	 and reduce the risks of mistake in our crypto
            
-
            18:02 <@jrand0m> I was on the fence, and I'm fine with going with shared
            
-
            	 known good primes.
            
-
            18:02 <@thecrypto> okay, then let's pick a prime then
            
-
            18:02 <@jrand0m> nop> we've still got you penciled in the ganttchart for
            
-
            	 crypto spec
            
-
            18:02 <@thecrypto> and do they have generators for these primes?
            
-
            18:02 < nop> yes
            
-
            18:02 < nop> yes I do
            
-
            18:03 < nop> 2
            
-
            18:03 < nop> that is a primitive root of the primes I will have
            
-
            18:03 < nop> what size primes do you guys want?
            
-
            18:03 <@thecrypto> i'm thinking somewhere between 2048-4096
            
-
            18:03 <@hezekiah> We're using a 2048 key, right?
            
-
            18:03 < nop> yes, so use a 4096 or higher prime
            
-
            18:04 <@thecrypto> because the sharedness means we're out in the open
            
-
            18:04 <@thecrypto> and if this takes off, it would be a very valuble prime
            
-
            	 to break
            
-
            18:04  * cohesion missed the meeting
            
-
            18:04 < co> You are using this prime within ElGamal, though, right?
            
-
            18:04 <@hezekiah> So the keys will be 4096 bits?
            
-
            18:04 <@cohesion> did someone log?
            
-
            18:04 < nop> co yes
            
-
            18:04 < nop> no hezekiah
            
-
            18:04 < nop> the keys will be 2048
            
-
            18:04 <@cohesion> ok
            
-
            18:04 < nop> the prime will be higher than 4096
            
-
            18:04  * cohesion goes back to his work
            
-
            18:04 <@hezekiah> OK. Please forgive my horribe understanding here. :)
            
-
            18:04 < nop> brb
            
-
            18:05 <@thecrypto> p and alpha can be fixed, alpha will be 2 and p will be
            
-
            	 the prime we pick
            
-
            18:05 < nop> ok, let me email the prime candidates
            
-
            18:05 < nop> give me a couple of hours I have some work to do
            
-
            18:05  * jeremiah wanders to dinner, will read logs later
            
-
            18:05 <@thecrypto> the serect key is a, a number between 0 and p - 2
            
-
            18:05 <@thecrypto> the public key is 2^a mod p
            
-
            18:06 < nop> can we move to next topic and come back so I can be here for
            
-
            	 that, I'll be right back, at work and have to do a task real quick
            
-
            18:06 <@hezekiah> OK, so you call my 'x' as 'a'
            
-
            18:06 <@hezekiah> ... and my 'g' as 'alpha'.
            
-
            18:06 < nop> please move the algo talk explanations to a private message
            
-
            18:06 <@hezekiah> thecrypto: Right?
            
-
            18:06 <@thecrypto> yes
            
-
            18:06 <@jrand0m> ok.  so thecrypto, nop, and hezekiah will work out the
            
-
            	 details of the algo later.
            
-
            18:06 < nop> ok
            
-
            18:06 < nop> for sure
            
-
            18:06 <@hezekiah> OK ... so thecrypto, are you done with your question?
            
-
            18:06 <@thecrypto> so let's move on
            
-
            18:06 < nop> I'll email our primes
            
-
            18:06 <@thecrypto> ye
            
-
            18:06 <@thecrypto> s
            
-
            18:06 <@hezekiah> OK. My turn! :)
            
-
            18:07 <@hezekiah> Why on earth are we using ElGamal for signing?
            
-
            18:07 <@jrand0m> ok.  2.4) roadmap / network proto status
            
-
            18:07 <@jrand0m> not yet hez :)
            
-
            18:07 <@jrand0m> oh hez
            
-
            18:07 <@hezekiah> When do I get to ask it?
            
-
            18:07 -!- dm [~hifi@anon.iip] has joined #iip-dev
            
-
            18:07 <@jrand0m> what would you recommend, when we have ElG public keys?
            
-
            18:07 <@thecrypto> when nop gets back
            
-
            18:07 <@jrand0m> no, you're right, I'm wrong.  now is the right time.
            
-
            18:07 < co> Next topic, please.
            
-
            18:07 <@hezekiah> jrand0m: Well, the problem is this:
            
-
            18:07 <@hezekiah> speed
            
-
            18:08 <@hezekiah> I was playing around with the crypto stuff today, and got
            
-
            	 a nasty shock.
            
-
            18:08 <@hezekiah> ElGamal was _astronomically_ slower at verifying a signature
            
-
            	 than DSA or RSA.
            
-
            18:08 <@jrand0m> hezekiah> is that a library implementation problem or
            
-
            	 the algorithm?
            
-
            18:08 <@hezekiah> I don't know.
            
-
            18:09 <@hezekiah> But I checked Applied Crypto and saw that at least _part_
            
-
            	 of the problem is with ElGamal.
            
-
            18:09 <@hezekiah> AC has tables of the amount of time it takes for signing
            
-
            	 and verification for DSA, RSA, and ElGamal.
            
-
            18:09 <@jrand0m> so are you suggesting we go to RSA for encryption, decryption,
            
-
            	 and signing?
            
-
            18:09 <@hezekiah> I
            
-
            18:09 <@hezekiah> I'm not really suggesting much that's definate.
            
-
            18:09 <@jrand0m> ...though we *could* add a second signing public key to
            
-
            	 the RouterInfo structure
            
-
            18:10 <@hezekiah> I'm just saying, that AC lists ElGamal verification at
            
-
            9.30 seconds.
            
-
            18:10 <@hezekiah> RSA is 0.08 seconds
            
-
            18:10 <@thecrypto> for 1024 bits
            
-
            18:10 <@jrand0m> damn.
            
-
            18:10 <@hezekiah> DSA is 1.27 seconds
            
-
            18:10 <@hezekiah> Now you see my problem.
            
-
            18:10 <@hezekiah> ElGamal is dirt slow ...
            
-
            18:10 <@jrand0m> we need sub <100ms verification.
            
-
            18:10 <@jrand0m> if not sub <10ms
            
-
            18:10 <@hezekiah> ... and my CPU is 333MHz.
            
-
            18:11 <@hezekiah> BTW, these calculations were done on a SPARC II
            
-
            18:11 <@hezekiah> I've got an AMD K6-2 333MHz.
            
-
            18:11 <@jrand0m> a sparc 2 is a 40Mhz machine.
            
-
            18:11 <@hezekiah> Verifying an ElGamal sig with my Python module (which uses
            
-
            	 a C backend but smells a little fishy).
            
-
            18:11 < luckypunk> god
            
-
            18:11 < luckypunk> well
            
-
            18:11 <@hezekiah> jrand0m: OK. I have no clue about SPARC's.
            
-
            18:11 <@hezekiah> Anyway, it took about 20 seconds.
            
-
            18:12 <@hezekiah> If not a little more.
            
-
            18:12 < luckypunk> anyone with a 1 ghz -2 ghz proc doesn't need to worry.
            
-
            18:12 < co> hezekiah: On modern computers, then, the verification should be
            
-
            	 acceptably fast.
            
-
            18:12 <@hezekiah> DSA and RSA were nearly instantainious.
            
-
            18:12 <@jrand0m> hezekiah> I do.  sparc 2 was fast in '92
            
-
            18:12 <@hezekiah> Anyway, that's why I bring all this up.
            
-
            18:12 <@hezekiah> We could add a DSA key, but that would meen 2 keys
            
-
            18:12 <@thecrypto> we should still wonder about people who don't have the
            
-
            	 uber fast machines
            
-
            18:12 <@hezekiah> Or we could go with RSA.
            
-
            18:12 <@jrand0m> my memory of our rationale for ElG as opposed to RSA was
            
-
            	 the preference was not very strong.
            
-
            18:13 <@hezekiah> Or we can live with the long verification time and use ElG.
            
-
            18:13 <@jrand0m> thecrypto> absolutely.
            
-
            18:13 <@thecrypto> nop was the one to say, let's use elgamal
            
-
            18:13 <@hezekiah> thecrypto: Precisely. Mom and Pop will eventually be
            
-
            	 transparently using I2P.
            
-
            18:13 <@jrand0m> we're going to want bootable distros for 386s, as well as
            
-
            	 in-applet implementations.
            
-
            18:13 <@hezekiah> Mom and Pop won't have state of the art hardware.
            
-
            18:13 < luckypunk> oh god
            
-
            18:14 < luckypunk> everyone who would want this has at least a p100 or so.
            
-
            18:14 < co> Let's not compromise security by choosing a weaker algorithm
            
-
            	 that is faster.
            
-
            18:14 <@hezekiah> co: I'm not suggesting we do.
            
-
            18:14 <@thecrypto> elgamal and DSA are equivilent
            
-
            18:14 <@jrand0m> ok.  so we're going to revisit the RSA/ElG choice.  the code
            
-
            	 changes shouldn't be a problem.
            
-
            18:14 < luckypunk> they can suffer.
            
-
            18:14 <@hezekiah> co: RSA and DSA are just as reputable as ElGamal.
            
-
            18:14 < luckypunk> lol
            
-
            18:14 < luckypunk> if you're concerned about anonyminity
            
-
            18:14 <@hezekiah> thecrypto: And nothing could be farther from the truth.
            
-
            18:14 < luckypunk> you won't care about speed too much.
            
-
            18:14 <@thecrypto> hezekiah: they are both implementations of the same
            
-
            	 general algorithim
            
-
            18:14 < dm> the obvious step here is for someone to figure out for certain
            
-
            	 what the CPU usages for the two are :)
            
-
            18:14 <@jrand0m> luckypunk> you listen to the complaints wrt freenet much?
            
-
            18:15 <@hezekiah> thecrypto: DSA can't encrypt. It's only a sig algo, and
            
-
            	 it's a lot faster than ElG.
            
-
            18:15 <@thecrypto> hezekiah: it just happens that the signing and verification
            
-
            	 equations for DSA are faster
            
-
            18:15 <@jrand0m> dm> if Applied Crypto benchmarked RSA verification at
            
-
            1/100th ElG, thats enough for me.
            
-
            18:15 <@thecrypto> we can use ElG for encryption/decryption and DSA for
            
-
            	 signing/verification
            
-
            18:15 <@jrand0m> the options are go to RSA or add a DSA key (~256bytes more)
            
-
            	 to the RouterInfo structure
            
-
            18:15 <@hezekiah> Right. But now the DHT has 2 public keys in it.
            
-
            18:16 <@jrand0m> so?
            
-
            18:16 < co> Let's have one public key. That will be less confusing.
            
-
            18:16 <@hezekiah> co: It would only be 'confusing' for developers ... and
            
-
            	 we need to know what we're doing. :)
            
-
            18:16 <@thecrypto> i think it's time to wait for nop on this one too
            
-
            18:16 <@hezekiah> Right.
            
-
            18:16 <@jrand0m> but if its 100times a slow...
            
-
            18:16 <@jrand0m> anyway, we'll continue the crypto design discussion offline.
            
-
            18:17 <@hezekiah> jrand0m: Email the mailing list, will ya'?
            
-
            18:17 < luckypunk> jrand0m: god, i don't mind, if you cant wait 40 sseconds
            
-
            	 for your page to load, fuck off.
            
-
            18:17 <@thecrypto> or after the main part of the meeting
            
-
            18:17 <@jrand0m> shit, I email the list daily :)
            
-
            18:17 <@jrand0m> heh lucky
            
-
            18:17 -!- hif [~hifi@anon.iip] has joined #iip-dev
            
-
            18:17 <@jrand0m> right.
            
-
            18:17 <@jrand0m> ok> 2.4) roadmap / network proto status
            
-
            18:17 -!- hif is now known as dm2
            
-
            18:18 <@jrand0m> I have done very little wrt the network proto beyond
            
-
            	 responding to co's messages, as I've been working on the java and I2CP.
            
-
            18:18 <@jrand0m> roadmap still seems on target.
            
-
            18:18 <@jrand0m> any changes to the roadmap?
            
-
            18:19 <@jrand0m> ok.  if there are, whenever there are, just mail the list.
            
-
            18:19 <@hezekiah> Right.
            
-
            18:19 -!- dm [~hifi@anon.iip] has quit [Ping timeout]
            
-
            18:19 <@jrand0m> the roadmap.xml is now in the i2p cvs module
            
-
            	 i2p/doc/projectPlan
            
-
            18:19 -!- dm2 is now known as dm
            
-
            18:20 <@hezekiah> jrand0m: Let me guess ... that's on cathedral too?
            
-
            18:20 < nop> back
            
-
            18:20 < nop> sorry bout that
            
-
            18:20 <@jrand0m> ok, thats it for that (though we can come back to network
            
-
            	 protocol questions in the questions section).
            
-
            18:20 <@jrand0m> I have no more subitems
            
-
            18:20 <@jrand0m> hezekiah> I don't use sf
            
-
            18:20 <@thecrypto> well, now that nop is back we can go back to the speed
            
-
            	 issue quickly
            
-
            18:20 <@hezekiah> Right.
            
-
            18:21 < nop> which speed issue
            
-
            18:21 <@thecrypto> Elgamal is slow to verify
            
-
            18:21 < nop> that's true
            
-
            18:21 < nop> but so is rsa
            
-
            18:21 <@jrand0m> nop> Applied Crypto benchmarked RSA verification at 1/100th
            
-
            	 ElG for signing.
            
-
            18:21 < nop> hmm
            
-
            18:22 <@hezekiah> RSA and DSA are instantanious for me.
            
-
            18:22 <@hezekiah> ElG takes 20 seconds.
            
-
            18:22 < nop> DSA is el gamal
            
-
            18:22 <@jrand0m> So we can either jump to RSA or add a DSA key to the
            
-
            	 RouterInfo structure
            
-
            18:22 < nop> DSA
            
-
            18:22 < nop> I have anything with R's in it
            
-
            18:22 < nop> ;)
            
-
            18:22  * jrand0m doesn't remember a really strong reason for ElG as opposed
            
-
            	 to RSA
            
-
            18:22  * jrand0m resents that
            
-
            18:22 <@hezekiah> nop: Will you enlighten us? Why don't we use RSA?
            
-
            18:23 <@hezekiah> In all the gory detials. :)
            
-
            18:23 < nop> for the reasons of this, and it's debatable, but
            
-
            18:23 < dm> someone msg me the URL to the iip-dev again when you get a chance.
            
-
            18:23 < nop> factoring primes is how to solve RSA
            
-
            18:23 < dm> iip-dev list that is.
            
-
            18:23 < luckypunk> RSA has been cracked.
            
-
            18:23 < luckypunk> practically.
            
-
            18:23 < nop> yes, 512 bit RSA has been cracked
            
-
            18:23 < luckypunk> or was it DES?
            
-
            18:23 < luckypunk> bah.
            
-
            18:23 <@hezekiah> DES has been cracked.
            
-
            18:23 < nop> it was DES I think you're talking about
            
-
            18:23 < co> luckypunk: Keys of certain size have been cracked.
            
-
            18:23 <@hezekiah> RSA is not quite there yet.
            
-
            18:24 < nop> anyway
            
-
            18:24 < luckypunk> but it might.
            
-
            18:24 < nop> back to my point
            
-
            18:24 <@hezekiah> But the question is: is a 2048 or 4096 RSA key secure today?
            
-
            18:24 <@thecrypto> hold one second
            
-
            18:24 < nop> 512 bit RSA keys have been cracked with office computers
            
-
            18:24 <@jrand0m> we're looking at 2048bit RSA or ElG
            
-
            18:24 < nop> hezekiah: it would be, but here's the fun part
            
-
            18:24 < nop> if you can factor primes
            
-
            18:24 < nop> you can crack RSA
            
-
            18:24 < nop> if you can compute discrete logarithms you can solve RSA and
            
-
            	 EL gamal
            
-
            18:24 < nop> we're closer to factoring
            
-
            18:24 < nop> than we are with computing discrete logs
            
-
            18:24 < nop> at this time
            
-
            18:24 < luckypunk> isn't discrete logs a bit harder?
            
-
            18:25 <@hezekiah> If you can factor primes _quickly_ you can crack RSA.
            
-
            18:25 <@hezekiah> luckypunk: That's what nop's saying.
            
-
            18:25 < luckypunk> quantum computers.
            
-
            18:25 < luckypunk> are damned near to functional.
            
-
            18:25 <@hezekiah> lol
            
-
            18:25 < nop> and the ratio of bit sizes for pub keys for discrete logs is
            
-
            	 stronger than RSA's keys
            
-
            18:25 < nop> for instance 768 bit key is not advised by diffie-hellman
            
-
            	 variants, but it has not been provably cracked
            
-
            18:25 <@hezekiah> So, the end of it is that we add a DSA key.
            
-
            18:25 <@thecrypto> nop, don't do a bill gates, it's factor large n where n = pq
            
-
            18:25 < nop> as 512 bit RSA keys have
            
-
            18:25 <@thecrypto> since factoring prime numbers is easy
            
-
            18:25 < nop> thnx
            
-
            18:25 < nop> sorry
            
-
            18:25 <@jrand0m> hezekiah> thats what its looking like.
            
-
            18:26 < nop> I was trying to let everyone understand
            
-
            18:26 < nop> sorry
            
-
            18:26 <@thecrypto> just a bit of a clarification
            
-
            18:26 <@jrand0m> word nop, thats cool, gracias
            
-
            18:26 <@hezekiah> OK.
            
-
            18:26 < nop> so DSA
            
-
            18:26 < nop> then
            
-
            18:26 <@hezekiah> So we're adding a DSA key?
            
-
            18:26 < nop> which is a diffie-hellman variant as well
            
-
            18:26 <@jrand0m> ok, given that, we'll continue crypto details offline.
            
-
            18:26 < nop> I'm in favor of logs over factors
            
-
            18:27 < nop> ;)
            
-
            18:27 <@hezekiah> BTW, what do we still need to continue?
            
-
            18:27 < co> dm: That URL is
            
-
            	 http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel
            
-
            18:27 <@thecrypto> hezekiah: picking the magic prime
            
-
            18:27 <@hezekiah> Oh, right!
            
-
            18:27 < dm> thanks co, I found jrand0m's specs. Now all I need is a printer
            
-
            	 with lots of toner.
            
-
            18:27 < nop> I'll send that out
            
-
            18:27 <@jrand0m> hezekiah> update the data structure spec, add info wrt the
            
-
            	 DSA, specify key size for dsa, etc.
            
-
            18:27 < nop> let's do that offline
            
-
            18:27 <@jrand0m> lol dm.
            
-
            18:28 <@hezekiah> OK, so do you have anything left, jrand0m?
            
-
            18:28 <@jrand0m> ok, I'm done with my stuff.  hezekiah> you had # 3?
            
-
            18:28 <@hezekiah> Yeah.
            
-
            18:28 < dm> hmmm. pictures are not showing up.
            
-
            18:28 <@hezekiah> 3.) Whatever nop wants to add to the agenda.
            
-
-
            18:28 < dm> jrand0m: is there a place to get the 'I2P Network Spec Draft
            
-
            2003.07.23' with pictures included?
            
-
            18:29 < co> dm: Yes, I have had that problem, too.
            
-
            18:29 <@jrand0m> dm/co> get the first rev of the network spec (two weeks
            
-
            	 prior in the zip), which includes the png.
            
-
            18:30 <@jrand0m> (its in cvs too, but thats not anon/public yet)
            
-
            18:30 < arj> when will it be? :)
            
-
            18:30 <@hezekiah> Wow!
            
-
            18:30 <@hezekiah> CVS is fast now!
            
-
            18:31 <@jrand0m> arj> we're doing our best to avoid hype, so once its ready
            
-
            	 we're going to put things public, but keep it largely quiet until.
            
-
            18:31 < nop> hezekiah: what the cathedral one?
            
-
            18:31 <@jrand0m> arj> however, everything we're doing is GPL, at least so far.
            
-
            18:31 <@hezekiah> nop: Yeah
            
-
            18:31 <@hezekiah> !
            
-
            18:31 < dm> two weeks prior in which zip?
            
-
            18:31 <@jrand0m> oh word, you got it working hezekiah?
            
-
            18:31 < arj> jrand0m: just wanted to read the latest specs
            
-
            18:31 <@jrand0m> dm> network_spec_*.zip iirc
            
-
            18:31 <@hezekiah> jrand0m: Yup! :)
            
-
            18:31 < dm> same here, with pictures!
            
-
            18:31 <@thecrypto> iip-dev has most of it
            
-
            18:32 <@jrand0m> arj>
            
-
            	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/292 has
            
-
            	 all but one tiny change.
            
-
            18:32 <@jrand0m> (well, except for the Client Access Layer, which is in a
            
-
            	 different spec now)
            
-
            18:33 < arj> ok thanx
            
-
            18:33 <@jrand0m> the client access layer spec is
            
-
            	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/298
            
-
            18:33 < dm> ok, and the link to the zip with the pictures?
            
-
            18:33 <@jrand0m> ok.  nop you have anything, or we "5) opening up to
            
-
            	 questions/thoughts from the masses"?
            
-
            18:34 -!- mihi [none@anon.iip] has quit [Ping timeout]
            
-
            18:34  * jeremiah is back and has read the backlog
            
-
            18:34 <@jrand0m> dm> h/o, pulling it up
            
-
            18:34 <@jrand0m>
            
-
            	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/269
            
-
            18:35 < dm> ty
            
-
            18:35 <@jrand0m> ok, any questions / thoughts?
            
-
            18:35 -!- arj [anders@anon.iip] has quit [EOF From client]
            
-
            18:35 < co> yes.
            
-
            18:35 <@jrand0m> np
            
-
            18:35 < co> Are we on item 5 now?
            
-
            18:35  * jrand0m knew you'd have some co :)
            
-
            18:35 < co> Currently, communication between client and router (outgoing)
            
-
            	 is not encrypted.
            
-
            18:35 <@jrand0m> yes, since nop is slow :)
            
-
            18:35 <@jrand0m> (damn people with jobs and stuff)
            
-
            18:36 <@hezekiah> lol
            
-
            18:36 < co> Suppose I have a trusted friend and want to use his router for
            
-
            	 outgoing messages.
            
-
            18:36 <@hezekiah> jrand0m: Well, you know. Not everyone can aford not having
            
-
            	 a life.
            
-
            18:36 <@jrand0m> co> largely correct.  message payloads are encrypted,
            
-
            	 but the rest of I2CP isn't
            
-
            18:36 < co> Wouldn't that put me at risk of having my messages captured.
            
-
            18:37 <@hezekiah> Yeah. They would be transfered in the clear over the wire.
            
-
            18:37 <@hezekiah> Unless you ssh tunnel to his router or something.
            
-
            18:37 <@jrand0m> if you have a trusted friend and connect to their router,
            
-
            	 they can know that you sent or recieved a message, but they can't know what
            
-
            	 you sent.
            
-
            18:37 <@jeremiah> wouldn't the messages still go under public key encryption?
            
-
            18:37 <@hezekiah> Oops.
            
-
            18:37 <@hezekiah> My bad.
            
-
            18:37 < dm> I'm gonna use I2P as a way to learn new stuff to prevent 9to5
            
-
            	 (windows admin, VB tools) job from turning me into a zombie.
            
-
            18:37 <@jrand0m> I'm fine with adding SSL listener support, as opposed to
            
-
            	 just TCP listener.
            
-
            18:37 <@hezekiah> I forgot that clients to end to end encryption.
            
-
            18:37 < co> Your assumption is that I run a local trusted router, but as
            
-
            	 stated above, I might not want to do that so that messages would not be
            
-
            	 connected to me.
            
-
            18:37 <@jrand0m> yes jeremiah, but thats only for the payload
            
-
            18:37 <@jrand0m> heh word dm
            
-
            18:37 -!- mihi [none@anon.iip] has joined #iip-dev
            
-
            18:38 <@jrand0m> hmm.
            
-
            18:38 <@hezekiah> jrand0m: Why not add support later on for client-to-router
            
-
            	 comm to be encrypted?
            
-
            18:38 <@jrand0m> you really always should have a local trusted router.
            
-
            	 you can have it connect to another known non-local trusted router too.
            
-
            18:39 < co> True, but I would like to second hezekiah's suggestion.
            
-
            18:39 <@jrand0m> hezekiah> I'm fine with adding it later (where later:
            
-
            	 t=0...releaseDate ;)
            
-
            18:40 <@jrand0m> I have absolutely no qualms with even adding support for
            
-
            	 DH+AES for I2CP
            
-
            18:40 < nop> good
            
-
            18:40 <@jrand0m> actually, those features can be added on per-router basis
            
-
            	 as well
            
-
            18:41 < nop> jrand0m: also I believe the polymorphic key rotation will be
            
-
            	 needed as well as chaffe traffic
            
-
            18:41 < nop> I'm sure we're looking at that at a later meeting
            
-
            18:41 < nop> just my side comment
            
-
            18:41 < nop> using key sets
            
-
            18:41 <@jrand0m> yes, when we touch the router-router comm.
            
-
            18:41 <@jrand0m> (1-2 weeks off)
            
-
            18:41 < co> nop: Currently, I don't see chaffe traffic in the spec, but it
            
-
            	 would be good to add.
            
-
            18:42 <@jrand0m> there is chaffe, in the sense that routers and tunnel
            
-
            	 participants test themselves and their peers.
            
-
            18:42 -!- arj [~anders@anon.iip] has joined #iip-dev
            
-
            18:42 <@jrand0m> plus DHT requests are chaffe wrt payload messages
            
-
            18:42 < nop> jrand0m: well I'll dive into some research on evading some
            
-
            	 traffic analysis and giving away any known plaintext
            
-
            18:42 <@jrand0m> *and* individual transports will have hteir own chaffe styles
            
-
            	 (e.g. http transport will query google for "cute puppy dogs" periodically,
            
-
            	 or whatever)
            
-
            18:43 < nop> well, that chaffe is nice, but I also mean encrypted chaffe
            
-
            18:43 < nop> this helps rotate the session keys
            
-
            18:43 < nop> and keep your node busy even when inactive
            
-
            18:43 < dm> maybe change that to hard child porn for more realistic chaffe
            
-
            18:43 <@jrand0m> word.
            
-
            18:43 < dm> just kidding!
            
-
            18:43 <@hezekiah> dm: Good. Otherwise I'd have to !thwack you.
            
-
            18:43 <@hezekiah> :)
            
-
            18:44 <@jrand0m> DHT (link encrypted) and test messages (free route mix,
            
-
            	 ala onion/garlic) won't have known plaintext problems
            
-
            18:44 < nop> since newer nodes will have less traffic when starting out
            
-
            18:44 <@jrand0m> plus we'll have support for constant bitrate transports
            
-
            18:44 < nop> garlic rocks
            
-
            18:44 < nop> :)
            
-
            18:44 < nop> jrand0m: DC net style :)
            
-
            18:44  * jrand0m is making some pasta w/ lots of garlic after this meeting
            
-
            	 is over
            
-
            18:45 < nop> jrand0m: I meant garlic routing
            
-
            18:45 <@hezekiah> lol!
            
-
            18:45 <@jrand0m> i know ;)
            
-
            18:45 < nop> jrand0m: anyway, constant bitrate could be forced with the
            
-
            	 block encryption since AES generates 128 bit blocks
            
-
            18:45 < nop> ;)
            
-
            18:45 < nop> so we could just pad all data to be 16 bytes per message
            
-
            18:45 <@jrand0m> co> did my answers to your email make sense?
            
-
            18:47 <@jrand0m> *ping*
            
-
            18:47 <@hezekiah> *pong*
            
-
            18:47 <@thecrypto> *pong
            
-
            18:47 <@thecrypto> *
            
-
            18:47 <@jrand0m> any other questions from anyone, or has my iproxy
            
-
            	 disconnected?
            
-
            18:47 <@jrand0m> heh word
            
-
            18:47 <@hezekiah> thecrypto: Fragmented packet!
            
-
            18:47 <@hezekiah> lol
            
-
            18:48 <@thecrypto> lost that tail end there
            
-
            18:48 <@thecrypto> smaller MTU here :)
            
-
            18:48 <@hezekiah> jrand0m: Well, I have no questions.
            
-
            18:48 < co> jrand0m: Yes, the answers made sense.
            
-
            18:48 < co> I have no more questions.
            
-
            18:48 < dm> I shall create questions when I read the specs tomorrow.
            
-
            18:49 <@jrand0m> well, I hope you have more later :)
            
-
            18:49 <@jrand0m> awesome dm
            
-
            18:49 < dm> awesome initially maybe.
            
-
            18:49 < dm> well, i'm off. good luck people!
            
-
            18:49 -!- dm [~hifi@anon.iip] has quit []
            
-
            18:50 <@jrand0m> we *do* still have the big 2 week peer review period in
            
-
            	 the schedule, but review before then is appreciated (even though all the
            
-
            	 details haven't yet been put in)
            
-
            18:51 <@jrand0m> ok.  any other questions, or are we going to wrap up #52
            
-
            	 as a 102 minute meeting?
            
-
            18:52 <@thecrypto> #51
            
-
            18:52 <@hezekiah> Uh, I read 1:57 minutes.
            
-
            18:52 <@hezekiah> Duh.
            
-
            18:52 <@hezekiah> I'm stupid
            
-
            18:52 <@hezekiah> Never mind me.
            
-
            18:52 <@hezekiah> I have no questions ...
            
-
            18:52 <@hezekiah> Questions!
            
-
            18:52  * jrand0m could never add...
            
-
            18:52 <@hezekiah> Speak now or hold you peace until next Tuesday!
            
-
            18:52 <@hezekiah> Going once!
            
-
            18:53 <@hezekiah> ... Going twice!
            
-
            18:53 <@thecrypto> Sold to the guy in a button down shirt
            
-
            18:53 <@hezekiah> Gone!
            
-
            18:53  * jrand0m goes to the kitchen to make some long overdue dinner
            
-
            18:53 <@jrand0m> gracias srs y srtas
            
-
            18:53 <@hezekiah> Goodbye everyone!
            
-
            18:53 <@jeremiah> I should checkout the source before I wander off
            
-
            18:53 <@hezekiah> See you next Tuesday!
            
-
            --- Log closed Tue Jul 29 18:53:55 2003
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting52.html b/www.i2p2/pages/meeting52.html
deleted file mode 100644
index 6c58b017..00000000
--- a/www.i2p2/pages/meeting52.html
+++ /dev/null
@@ -1,381 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 52{% endblock %}
-{% block content %}
            
-
            <nop>	ok, meeting started
            
-
            <nop>	what's on the agenda
            
-
            -->	logger (logger@anon.iip) has joined #iip-dev
            
-
            -->	Anon02 (~anon@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	Tue Aug  5 21:03:10 UTC 2003
            
-
            <hezekiah>	Welcome to the Nth iip-dev meeting.
            
-
            <hezekiah>	What's on the agenda?
            
-
            <thecrypto>	Tue Aug  5 21:02:44 UTC 2003
            
-
            <thecrypto>	synced to a NTP stratum 2 :)
            
-
            <hezekiah>	Tue Aug  5 21:03:13 UTC 2003
            
-
            -->	ptm (~ptm@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	Just synced to NIST. :)
            
-
            <mihi>	this sync does not help w/ iip delays ;)
            
-
            <jrand0m>	nop: things I want to see covered: java dev status, java crypto
            
-
            	  status, python dev status, sdk status, naming service
            
-
            <hezekiah>	(We're going into the naming service _already_?)
            
-
            <jrand0m>	not design you wanker, thats co's schpeel.  just talk about stuff
            
-
            	  if there's stuff to talk about.
            
-
            <hezekiah>	Ah
            
-
            *	jrand0m puts LART away
            
-
            <jrand0m>	anything else on the agenda?
            
-
            <jrand0m>	or shall we dig in?
            
-
            <hezekiah>	Well, I can't think of anything else to add.
            
-
            <hezekiah>	Ah!
            
-
            <hezekiah>	Oh!
            
-
            <jrand0m>	ok.  java dev status:
            
-
            <hezekiah>	Good.
            
-
            <--	mrflibble has quit (Ping timeout)
            
-
            <nop>	ok
            
-
            <nop>	agenda
            
-
            <nop>	1) Welcome
            
-
            <jrand0m>	as of today, there is a java client API with a stub java router
            
-
            	  that can talk to each other.  in addition, there is an application called ATalk
            
-
            	  allowing anonymous IM + file transfer.
            
-
            <nop>	2) IIP 1.1 blackouts
            
-
            <nop>	3) I2P
            
-
            <nop>	4) The End with comments and stuff
            
-
            *	jrand0m goes back to corner
            
-
            <nop>	sorry
            
-
            	  joeyo jrand0m Aug 05 17:08:24 * hezekiah gives jrand0m a dunce hat to wear in
            
-
            	  the corner. ;-)
            
-
            <nop>	sorry about that
            
-
            <nop>	didn't see you started there
            
-
            <nop>	maybe I should go in corner
            
-
            <hezekiah>	lol
            
-
            <jrand0m>	no worry.  item 1)
            
-
            *	hezekiah hands nop a dunce hat too. :)
            
-
            <nop>	ok welcome everybuddy
            
-
            <nop>	blah blah
            
-
            <nop>	2) IIP 1.1 blackouts
            
-
            -->	mrflibble (mrflibble@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	52nd iip-dev meeting and all that good rot!
            
-
            <nop>	the server recently had some issues with the hard drive sectors and has
            
-
            	  been replaced
            
-
            <nop>	I plan to be moving the darn server into a more stable environment with
            
-
            	  redundancy
            
-
            <nop>	and possibly lend out control of multiple ircd servers
            
-
            <nop>	dunno
            
-
            <nop>	that's something to be discussed
            
-
            <--	Anon02 has quit (EOF From client)
            
-
            <nop>	hopefully our servers should stay up now since the harddrive was replaced
            
-
            <nop>	sorry about the inconvenience folks
            
-
            <nop>	3) I2P - Jrand0m take it away
            
-
            <nop>	come out of the corner jrand0m
            
-
            *	hezekiah goes over to the corner, pulls jrand0m off his chair, drags him
            
-
            	  to the podium, takes away his dunce hat, and hands him the mic.
            
-
            *	nop goes into that corner to fill his place
            
-
            <hezekiah>	lol!
            
-
            <jrand0m>	sorry, back
            
-
            *	nop grabs dunce hat from hezekiah
            
-
            *	nop puts it on his head
            
-
            *	nop applauds for jrand0m
            
-
            *	jrand0m just watches the show
            
-
            <jrand0m>	er... um ok
            
-
            <hezekiah>	jrand0m: i2p, java status, etc. Talk man!
            
-
            <jrand0m>	so, as of today, there is a java client API with a stub java
            
-
            	  router that can talk to each other.  in addition, there is an application called
            
-
            	  ATalk allowing anonymous IM + file transfer.
            
-
            <hezekiah>	File transfer already!?
            
-
            <jrand0m>	si sr
            
-
            <hezekiah>	Wow.
            
-
            <hezekiah>	I'm sure behind the times.
            
-
            <jrand0m>	but not the most graceful
            
-
            <hezekiah>	lol
            
-
            <jrand0m>	it takes a file and tosses it in a message
            
-
            <hezekiah>	Ouch.
            
-
            <nop>	how long did 1.8 mb local transfer take?
            
-
            <jrand0m>	I've tested with a 4K file and a 1.8Mb file
            
-
            <jrand0m>	a few seconds
            
-
            <nop>	nice
            
-
            <nop>	:)
            
-
            <hezekiah>	Does the java stuff do real encryption yet, or does it still
            
-
            	  fake that?
            
-
            <nop>	fake
            
-
            <nop>	even I know that
            
-
            <nop>	:)
            
-
            <jrand0m>	I warmed it up by talking to myself first [e.g. one window to
            
-
            	  another, saying hi] so it didn't deal with the overhead of the first elg
            
-
            <jrand0m>	right, its faked largely
            
-
            <thecrypto>	most of the encryption is fake
            
-
            <thecrypto>	that's being worked on though
            
-
            <hezekiah>	Of course. :)
            
-
            <jrand0m>	definitely.
            
-
            <jrand0m>	on that front, wanna give us an update thecrypto?
            
-
            <thecrypto>	well, right now i'm done with ElGamal and SHA256
            
-
            <thecrypto>	right now I'm working on generating primes for DSA
            
-
            <thecrypto>	I'll send out 5 and then we can just pick one
            
-
            <hezekiah>	nop: Didn't you have prime(s) coming for use with DSA?
            
-
            <thecrypto>	We also have some benchmarks on ElGamal and SHA256
            
-
            <thecrypto>	And they are all fast
            
-
            <jrand0m>	latest benchmarks w/ elg:
            
-
            <jrand0m>	Key Generation Time Average: 4437	total: 443759	min:
            
-
            	  872	   max: 21110	   Keygen/second: 0
            
-
            <jrand0m>	Encryption Time Average    : 356	total: 35657	min:
            
-
            	  431	   max: 611	   Encryption Bps: 179
            
-
            <jrand0m>	Decryption Time Average    : 983	total: 98347	min:
            
-
            	  881	   max: 2143	   Decryption Bps: 65
            
-
-
            <hezekiah>	min and max: are they in seconds?
            
-
            <jrand0m>	note that the Bps isn't really useful, as we only encrypt/decrypt
            
-
            	  64 bytes
            
-
            <thecrypto>	ms
            
-
            <jrand0m>	no, sorry, those are all milliseconds
            
-
            <hezekiah>	Cool. :)
            
-
            <hezekiah>	And this is done in java?
            
-
            <thecrypto>	yes
            
-
            <thecrypto>	pure java
            
-
            <hezekiah>	OK. I am officiall impressed. :)
            
-
            <jrand0m>	100%.  P4 1.8
            
-
            <thecrypto>	they are about the same on my 800 Mhz
            
-
            <hezekiah>	How can I do the same tests?
            
-
            <jrand0m>	sha256 benchmark:
            
-
            <jrand0m>	Short Message Time Average  : 0 total: 0	min: 0	max:
            
-
            	  0  Bps: NaN
            
-
            <jrand0m>	Medium Message Time Average : 1 total: 130	min: 0	max:
            
-
            	  10 Bps: 7876923
            
-
            <jrand0m>	Long Message Time Average   : 146	total: 14641	min:
            
-
            	  130	   max: 270	   Bps: 83037
            
-
            <thecrypto>	run the ElGamalBench program
            
-
            <hezekiah>	OK.
            
-
            <hezekiah>	I'll go find it.
            
-
            <jrand0m>	(short size: ~10 bytes, medium ~10KB, long ~ 1MB)
            
-
            <jrand0m>	java -cp i2p.jar ElGamalBench
            
-
            <jrand0m>	(after running "ant all")
            
-
            <hezekiah>	jrand0m: Thanks. :)
            
-
            <jrand0m>	np
            
-
            <thecrypto>	The NaN thing means it's so fast that we end up dividing by 0
            
-
            	  it's so fast :)
            
-
            <hezekiah>	What's the sha bench?
            
-
            <jrand0m>	java -cp i2p.jar SHA256Bench
            
-
            -->	Neo (anon@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	OK.
            
-
            <jrand0m>	we'll probably want to move those to be main() methods of the
            
-
            	  associated engines, but they're good where they are atm
            
-
            <hezekiah>	Let's see how fast all this is on an AMD K6-2 333MHz (which is
            
-
            	  a chip not well know for its integer math.)
            
-
            <jrand0m>	heh
            
-
            <jrand0m>	ok so we have DSA and AES left, right?
            
-
            <jrand0m>	this is all wikked thecrypto.  nice work.
            
-
            <thecrypto>	yup
            
-
            <jrand0m>	can I nag you for an ETA on the other two?  ;)
            
-
            <hezekiah>	If this is anywhere near as fast on my box as it is on yours,
            
-
            	  you have to show me how you do that. ;-)
            
-
            <thecrypto>	DSA should be done almost as soon as i have primes ready
            
-
            <nop>	hezekiah have you tried the sslcrypto for python
            
-
            <thecrypto>	copying some code around from the prime generator and things like
            
-
            	  that and it's done
            
-
            <nop>	the one off that link
            
-
            <hezekiah>	nop: sslcrypto won't do us any good.
            
-
            <hezekiah>	nop: It doesn't implment ElGamal _or_ AES _or_ sha256.
            
-
            <thecrypto>	AES is mostly done except that there is some error somewhere that
            
-
            	  i'm still trying to pick out and destroy, once i have that, it'll be done
            
-
            <jrand0m>	thecrypto> so by friday, DSA keygen, sign, verify, and AES encrypt,
            
-
            	  decrypt for arbitrary size inputs?
            
-
            <nop>	the one on McNab's site does not?
            
-
            <thecrypto>	yeah
            
-
            <nop>	darn
            
-
            <thecrypto>	should be friday
            
-
            <thecrypto>	most likey thursday
            
-
            <jrand0m>	thecrypto> does that include the UnsignedBigInteger stuff?
            
-
            <thecrypto>	i'll be missing next weeks meeting because of summer camp, and
            
-
            	  i'll be back after that
            
-
            <thecrypto>	jrand0m: prolly not
            
-
            <jrand0m>	ok.
            
-
            <jrand0m>	so for the time being, interoperability between java and python
            
-
            	  is b0rked.
            
-
            <jrand0m>	for crypto, that is.
            
-
            ---	Notify: jeremiah is online (anon.iip).
            
-
            -->	jeremiah (~chatzilla@anon.iip) has joined #iip-dev
            
-
            <jrand0m>	(aka for signatures, keys, encryption, and decryption)
            
-
-
            <nop>	hmm maybe we should focus more on C/C++
            
-
            <thecrypto>	well, once we get it working completely we can then make sure
            
-
            	  both java and python can speak to each other
            
-
            <jrand0m>	while you're out I'll look into the unsigned stuff.
            
-
            <jeremiah>	can someone email me a backlog? jeremiah@kingprimate.com
            
-
            <hezekiah>	jeremiah: Give me a minute. :)
            
-
            <jrand0m>	nop> do we have devs for C/C++?
            
-
            <nop>	I have one guy yes
            
-
            <nop>	and Hezekiah we know could do it
            
-
            <jrand0m>	or perhaps we can get a python dev status update from hezekiah +
            
-
            	  jeremiah to see when we'll have more people for the c/c++ dev
            
-
            <jrand0m>	right, of course.  but hez+jeremiah are working on python atm
            
-
            	  (right?)
            
-
            <hezekiah>	Yeah.
            
-
            <--	mrflibble has quit (Ping timeout)
            
-
            <hezekiah>	I'm sort of giving poor jeremiah lots of trouble.
            
-
            <nop>	I was just saying if python won't be fast speeds
            
-
            <hezekiah>	Python is mainly for me to understand this network.
            
-
            <nop>	ahh
            
-
            <hezekiah>	Once, I get it to basically follow the complete spec, I intend
            
-
            	  to hand it off to jeremiah to do with as he sees fit.
            
-
            <hezekiah>	It's not meant to be a killer implementation of the spec.
            
-
            <hezekiah>	(If I wanted that, I'd use C++.)
            
-
            <jeremiah>	well there aren't any really processor intensive parts of the app,
            
-
            	  iirc, aside from crypto, and ideally that will be handled in C anyways, right?
            
-
            <jrand0m>	sure jeremiah.	all depends on the app
            
-
            -->	mrflibble (mrflibble@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	jeremiah: In theory.
            
-
            <jrand0m>	so where are we on the python side?  client api, local only
            
-
            	  router, etc?
            
-
            <jeremiah>	the python implementation will also let us know what optimizations
            
-
            	  we could make from the start... I'd like to keep it up to date or, possibly,
            
-
            	  ahead of the C implementation as I can
            
-
            <hezekiah>	jrand0m: OK. Here's what I've got.
            
-
            <hezekiah>	In _theory_ the router should be able to handle all non-admin
            
-
            	  messages from a client.
            
-
            <hezekiah>	However, I don't have client yet, so I haven't been able to debug
            
-
            	  it (i.e. there are still bugs.)
            
-
            <hezekiah>	I'm working on the client right now.
            
-
            <jrand0m>	'k.  if you can disable signature verification, we should be able
            
-
            	  to run the java client against it now
            
-
            <hezekiah>	I'm hoping to have that done except for admin messages in a day
            
-
            	  or two.
            
-
            <jrand0m>	we can test that out after the meeting
            
-
            <hezekiah>	jrand0m: OK.
            
-
            <jeremiah>	I've been dealing with real-world stuff mostly since the last
            
-
            	  meeting, I can work on the client API, just been trying to sync my thinking
            
-
            	  with hezekiah's
            
-
            <jrand0m>	cool
            
-
            <hezekiah>	jeremiah: You know what, just wait.
            
-
            <hezekiah>	jeremiah: I'm probably throwing in too much new stuff for you to
            
-
            	  deal with right now.
            
-
            <jeremiah>	hezekiah: right, what I was going to say is that you should
            
-
            	  probably just go ahead and implement the base stuff
            
-
            <hezekiah>	jeremiah: In a little while, it will be stabalized and you can
            
-
            	  start refining it. (There are lots of TODO comments that need help.)
            
-
            <jeremiah>	and then I can extend it later once I get the picture
            
-
            <hezekiah>	Exactly.
            
-
            <hezekiah>	You get to maintain all this code. :)
            
-
            <jrand0m>	cool.  so eta 1-2 weeks for a working python router + client api?
            
-
            <hezekiah>	I'm going on vacation next week so probably.
            
-
            <hezekiah>	Are we going to have more details on router to router soon?
            
-
            <jrand0m>	no.
            
-
            <jrand0m>	well, yes.
            
-
            <jrand0m>	but no.
            
-
            <hezekiah>	lol
            
-
            <jeremiah>	hezekiah: how long is the vacation?
            
-
            <hezekiah>	1 week.
            
-
            <jeremiah>	ok
            
-
            <jrand0m>	(aka as soon as the SDK goes out, 100% of my time goes into I2NP)
            
-
            <hezekiah>	I'm hoping to have all non-admin functionality written before I
            
-
            	  go on vacation
            
-
            <hezekiah>	.
            
-
            <jrand0m>	but then soon after you get back you're off to college, right?
            
-
            <hezekiah>	I2NP?
            
-
            <hezekiah>	Right.
            
-
            <jrand0m>	network proto
            
-
            <hezekiah>	I have about 1 week after vacation.
            
-
            <hezekiah>	Then I'm gone.
            
-
            <hezekiah>	And my free time drops like a stone.
            
-
            <jrand0m>	so that 1 week should only be debugging
            
-
            <jeremiah>	I can work on the code while hez is gone though
            
-
            <jrand0m>	word
            
-
            <jrand0m>	whats your summer look like jeremiah?
            
-
            <hezekiah>	jeremiah: Perhaps you can get those admin functions working?
            
-
-
            <thecrypto>	i'll still have a month after i come back from my vaction to work
            
-
            	  on things
            
-
            <jrand0m>	having a life, or being like the rest of us l00sers?  :)
            
-
            <jeremiah>	maybe
            
-
            <hezekiah>	100sers?
            
-
            <hezekiah>	What's a 100ser?
            
-
            <jeremiah>	i leave for college on the 22nd, other than that I can dev
            
-
            <mihi>	hezekiah: a loser
            
-
            <jeremiah>	and the last week before I leave all my friends will be gone... so
            
-
            	  I can go into hyperdev mode
            
-
            <hezekiah>	mihi: Ah!
            
-
            <jrand0m>	hehe
            
-
            <hezekiah>	OK. So where were we on the agenda?
            
-
            <hezekiah>	i.e. What's next?
            
-
            <jrand0m>	sdk status
            
-
            <jrand0m>	sdk == one client impl, a local only router impl, an app, and docs.
            
-
            <jrand0m>	I'd like to have that out by next tuesday.
            
-
            <hezekiah>	jeremiah: That backlog is on the way. Sorry I forgot you there. :)
            
-
            <jeremiah>	thanks
            
-
            <jrand0m>	ok, co isn't around, so the naming service stuff is prolly a bit
            
-
            	  off base
            
-
            <jrand0m>	we can discuss the naming service after he puts out specs or
            
-
            	  he's around
            
-
            <jrand0m>	ok, thats it for I2P stuff
            
-
            <jrand0m>	anyone else have I2P stuff, or we on to: <nop> 4) The End with
            
-
            	  comments and stuff
            
-
            <hezekiah>	I can't think of anything.
            
-
            <jrand0m>	I assume everyone's seen
            
-
            	  http://www.cnn.com/2003/TECH/internet/08/05/anarchist.prison.ap/index.html ?
            
-
            <thecrypto>	not here
            
-
            <jrand0m>	(nop posted it here earlier)
            
-
            <hezekiah>	The thing about the guy who got arrested for linking to a bomb
            
-
            	  building site?
            
-
            <jrand0m>	yes
            
-
            <jrand0m>	relevence to the need to get I2P up ASAP should be aparent ;)
            
-
            <hezekiah>	OK! jeremiah, those logs are now sent.
            
-
            <jeremiah>	thanks
            
-
            <jrand0m>	anyone have any questions / comments / thoughts / frisbees,
            
-
            	  or are we having a record breaking short meeting?
            
-
            *	thecrypto tosses a frisbee
            
-
            <--	logger has quit (Ping timeout)
            
-
            <jrand0m>	damn y'all are quiet today ;)
            
-
            <mihi>	question:
            
-
            <mihi>	where can non devs get yout java code?
            
-
            <jrand0m>	si sr?
            
-
            <thecrypto>	not yet
            
-
            <mihi>	404
            
-
            <jrand0m>	that'll be made available once we're release ready.  aka the
            
-
            	  source will go out with the SDK
            
-
            <jrand0m>	heh
            
-
            <jrand0m>	yeah, we don't use SF
            
-
            <hezekiah>	nop: Is it possible that we can get anonymous cvs working some tiem?
            
-
            <hezekiah>	time?
            
-
            <--	mrflibble has quit (Ping timeout)
            
-
            <nop>	well, I would open up a non-standard port
            
-
            <jrand0m>	hezekiah> we'll have that once the code has the GPL license on there
            
-
            <nop>	but I am working on viewcvs
            
-
            <jrand0m>	aka not now since the gpl doc hasn't been added to the code yet
            
-
            <hezekiah>	jrand0m: It's in all the python code directories and all python
            
-
            	  source files speceify licensing under GPL-2.
            
-
            <jrand0m>	hezekiah> is that on the cathedral?
            
-
            <hezekiah>	Yes.
            
-
            <jrand0m>	ah word.  i2p/core/code/python ?  or a different module?
            
-
            *	jrand0m hasn't seen it in there
            
-
            <hezekiah>	Each python code directory has a COPYING file in it with the
            
-
            	  GPL-2 and each source file has the license set a GPL-2
            
-
            <hezekiah>	It's i2p/router/python and i2p/api/python
            
-
            <jrand0m>	'k
            
-
            <jrand0m>	so, yeah, by next tuesday we'll have the SDK + public source access.
            
-
            <hezekiah>	Cool.
            
-
            <hezekiah>	Or as you like to say, wikked. ;-)
            
-
            <jrand0m>	heh
            
-
            <jrand0m>	nada mas?
            
-
            <hezekiah>	nada mas? What's that mean!?
            
-
            <jeremiah>	nothing more
            
-
            *	jrand0m suggests you learn a lil espanol en universidad
            
-
            -->	mrflibble (mrflibble@anon.iip) has joined #iip-dev
            
-
            <hezekiah>	Questions anyone?
            
-
            <hezekiah>	Going once!
            
-
            <--	ptm (~ptm@anon.iip) has left #iip-dev (ptm)
            
-
            <hezekiah>	Going twice!
            
-
            <--	mrflibble has quit (mr. flibble says "game over boys")
            
-
            <hezekiah>	Speak now .. or wait until you feel like speaking later!
            
-
            <thecrypto>	okay, i'm going to be optimizing the elgamal even more, so expect
            
-
            	  even faster elgamal benches in the future
            
-
            <jrand0m>	please focus on DSA and AES before tuning... puhleeeease :)
            
-
            <thecrypto>	i will
            
-
            <hezekiah>	The reason he's doing that is 'cause I'm causing trouble for
            
-
            	  people again. ;-)
            
-
            <thecrypto>	i'm making DSA primes
            
-
            -->	mrflibble (mrflibble@anon.iip) has joined #iip-dev
            
-
            <thecrypto>	well, at least making the program to make DSA primes right now
            
-
            <hezekiah>	ElGamal in Java doesn't like an AMD K-6 II 333MHz.
            
-
            <hezekiah>	OK.
            
-
            <hezekiah>	Question round is over!
            
-
            <jrand0m>	ok hez, we're done.  you wanna powow on getting the java client
            
-
            	  and the python router work?
            
-
            <hezekiah>	See you all next week citizens!
            
-
            *	hezekiah smashes down the *baf*er
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting53.html b/www.i2p2/pages/meeting53.html
deleted file mode 100644
index 184708a9..00000000
--- a/www.i2p2/pages/meeting53.html
+++ /dev/null
@@ -1,113 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 53{% endblock %}
-{% block content %}
            
-
            [21:09] <jrand0m> ok.  21:00 UTC esta ahora
            
-
            [21:09] <jrand0m> welcome to the um meeting
            
-
            [21:09] <jrand0m> we have a lot of people out today (nop, hezekiah, thecrypto, and userx), so we'll keep it brief
            
-
            [21:10] <jrand0m> agenda: 1) hi 2) sdk 3) status 4) questions
            
-
            [21:10] <jrand0m> 1) hi
            
-
            [21:10] <jrand0m> hello.
            
-
            [21:10] <jrand0m> 2) sdk
            
-
            [21:11] <jrand0m> the I2P SDK 0.1 is ready for quiet release.  
            
-
            [21:11] <mihi> quiet release?
            
-
            [21:11] <jrand0m> basically we're not publicizing it except for people in the know, and those trusted by people in the know
            
-
            [21:12] <jrand0m> it is however fully ready to do application design, development, and testing with
            
-
            [21:12] <jrand0m> If you're on #iip-dev, you're in the know
            
-
            [21:13] <jrand0m> so anyone who wants to check it out can either pull it from CVS or retrieve source, docs, and build from CHK@GZ-A-C~SH03AwBuKf~AE3E347IcKAwI,4K38eh3m06zAygRzUnw4tQ/i2p_sdk.zip
            
-
            [21:13] * UserX has joined #iip-dev
            
-
            [21:13] <jrand0m> hey, its UserX
            
-
            [21:14] <jrand0m> The 0.1 of the SDK contains the working java client API, as well as both a python and java router implementation and a simple command line chat application
            
-
            [21:15] <jrand0m> The point of having the SDK is so that people can get a head start on development so their applications will be up and running once the network goes operational and public in september.
            
-
            [21:16] <mihi> september that never ended? ;)
            
-
            [21:16] <jrand0m> (rather than having the network up and running with no applications)
            
-
            [21:16] <jrand0m> heh
            
-
            [21:16] <jrand0m> no, we're actually beating the schedule I posted to iip-dev a few weeks back in the ganttproject document
            
-
            [21:16] <jrand0m> not by much (5 days), but beating it none the less.
            
-
            [21:17] <jrand0m> I'm quite confident that we'll be 1.0alpha in september.
            
-
            [21:17] <jrand0m> Also, for status, I suspect that there will be a new I2NP (network proto) draft out by the end of the week.
            
-
            [21:18] <jrand0m> Then, hopefully next week we can have some internal review and revisions, after which we can go into peer review.
            
-
            [21:18] * shardy_ is now known as shardy
            
-
            [21:18] <jrand0m> 'lo shardy
            
-
            [21:18] <shardy> hiya.
            
-
            [21:18] <shardy> how goes?
            
-
            [21:19] <jrand0m> wikked.  
            
-
            [21:19] <jrand0m> I hear rumors we might be able to get some of your time for some .net client lib stuff?
            
-
            [21:19] * jrand0m may be misinformed
            
-
            [21:20] * ion has quit IRC (Ping timeout)
            
-
            [21:21] <shardy> .net? nope, that's not me...
            
-
            [21:21] <jrand0m> ah 'k, my bad
            
-
            [21:21] <jrand0m> soy muy tonto
            
-
            [21:21] <jrand0m> well, hi anyway :)
            
-
            [21:21] <jrand0m> I also got some feedback from co wrt the naming service application
            
-
            [21:22] * ion has joined #iip-dev
            
-
            [21:22] <jrand0m> "On August 8th the first version of the specification for the naming service was posted.  It was discovered that the specification has flaws, and I am revising it. It should be done within a week or so. After that, I will be start implementing the system.  In the end, there will be four components of this software: 
            
-
            [21:22] <jrand0m> 1. Client program to interact with naming service.
            
-
            [21:22] <jrand0m> 2. Program for the naming service itself.
            
-
            [21:22] <jrand0m> 3. Administrative utilities for the naming service.
            
-
            [21:22] <jrand0m> 4. A Certificate Authority (CA) component."
            
-
            [21:23] <jrand0m> That's co's status report
            
-
            [21:23] <jrand0m> I think that may be it for status, unless someone has something to add.
            
-
            [21:24] <shardy> neat.
            
-
            [21:24] <jrand0m> definitely neat
            
-
            [21:24] <shardy> as soon as I get time I'm going to start looking over the specs and get familiar with the way you guys do things.
            
-
            [21:25] <jrand0m> cool.  the I2CP spec in the SDK is pretty much operational, but the I2P network spec posted yesterday is a few weeks behind the times.
            
-
            [21:25] <jrand0m> I'll be posting a new version probably on friday.
            
-
            [21:25] <jrand0m> (and as this project only began in earnest maybe a month ago, we're open for variations in how we work)
            
-
            [21:26] <jrand0m> oh wait, now I remember, you're the ecc guy :)
            
-
            [21:26] <shardy> yep, that's me. although I haven't really done much with ecc in a while... I'm now the prng guy.
            
-
            [21:27] <jrand0m> oh nice.  we're currently using generic prngs, and will want a better way to deal with random data
            
-
            [21:27] <jrand0m> ok
            
-
            [21:27] <shardy> generic ones? nop mentioned using yarrow, which seems pretty good.
            
-
            [21:28] <shardy> I'm doing implementation work on a new prng now. trying to reduce the theory and practice gap somewhat. :)
            
-
            [21:28] <jrand0m> right.  we have a GPL'ed version of yarrow we can pull from freenet into the java implementations, but for the time being we're using java's built in one (java.security.SecureRandom)
            
-
            [21:28] <jrand0m> heh
            
-
            [21:29] <mihi> be careful w/ yarrow from freenet, it does heisenbugs ;)
            
-
            [21:29] <jrand0m> lol
            
-
            [21:29] <jrand0m> well, thats fixed now that its synchronized
            
-
            [21:29] * jrand0m opens the floor to any questions
            
-
            [21:30] * mihi gets DNF for the key mentioned above :(
            
-
            [21:30] <jrand0m> shite.  I inserted it a dozen times at htl 25
            
-
            [21:30] <jrand0m> I'll reinsert it yet again
            
-
            [21:32] <jrand0m> anyone have any questions, other than "why won't freenet find the SDK's key?"
            
-
            [21:33] * mihi did not ask that ;) and does not have any other questions until he looks @ it ;)
            
-
            [21:33] <jrand0m> heh
            
-
            [21:33] <mihi> who puts the log onto the wiki this time? /me has it completely this time.
            
-
            [21:33] <jrand0m> awesome, go for it
            
-
            [21:34] <jrand0m> I believe we're out of questions for the meeting, though please everyone feel free to post up further thoughts ot the mailing list.
            
-
            [21:34] * jrand0m really likes active discussion on iip-dev, even if its everyone saying how my docs suck
            
-
            [21:34] <mihi> your java sux, jrandom ;) (HHOK)
            
-
            [21:35] <jrand0m> thats more like it
            
-
            [21:35] <jrand0m> I'm reinserting the .zip from freenet's CLI, so it'll probably have a different CHK
            
-
            [21:36] <jrand0m> I'll msg people with it after I reinsert it a few times
            
-
            [21:36] <jrand0m> mihi wants it.  anyone else I should msg?
            
-
            [21:36] <jrand0m> (or anyone can ask at another time, as well)
            
-
            [21:36] <mihi> you could mail it to me...
            
-
            [21:36] <jrand0m> 1.1Mb
            
-
            [21:37] <mihi> if it is not *too* large.
            
-
            [21:37] <mihi> erm, okay then not.
            
-
            [21:37] * mihi is not kind on fetching splitfiles anyway
            
-
            [21:37] <mihi> s/kind/keen/
            
-
            [21:37] <jrand0m> heh, are you going to suggest I insert it without FEC?
            
-
            [21:38] <mihi> i guess it won't have any chance in current freenet.
            
-
            [21:38] <jrand0m> ok, I'll see about getting it web accessible with a private URL
            
-
            [21:39] * jrand0m feels kind of weird with this quiet release thing, but I think its for the best
            
-
            [21:40] <mihi> just put it on some webspace and put some gpg conventional encryption around it - and tell the passphrase here.
            
-
            [21:40] <mihi> or use the key mentioned above as passphrase
            
-
            [21:40] <mihi> btw - shall i strip that one from the log?
            
-
            [21:41] <jrand0m> no need to.  I'm paranoid enough to believe if its said here, its available to those who want to see it ;)
            
-
            [21:41] <jrand0m> I'll have nop toss it up on some webspace when he gets back later this evening and anonymail people with the appropriate info (url & password / technology / etc)
            
-
            [21:43] <mihi> thx. "this evening" regarding which time zone? (me will go to bea in about 1 hour)
            
-
            [21:43] <mihi> s/bea/bed
            
-
            [21:46] <jrand0m> heh, evening for nop, which is california
            
-
            [21:46] <jrand0m> ok, I've got to jet.  
            
-
            [21:46] * jrand0m !thwaps meeting to an end
            
-
            [21:46] <jrand0m> gracias srs y srtas
            
-
            [21:46] * mihi hands jrandom the *baf*er
            
-
            [21:47] * jrand0m *baf*s  mihi on the head
            
-
            [21:47] * shardy has quit IRC (EOF From client)
            
-
            [21:48] <ion> 2 blocks downloading above url
            
-
            [21:48] <jrand0m> nice
            
-
            [21:48] * shardy has joined #iip-dev
            
-
            [21:48] * mihi drops dead.
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting54.html b/www.i2p2/pages/meeting54.html
deleted file mode 100644
index 63822ffb..00000000
--- a/www.i2p2/pages/meeting54.html
+++ /dev/null
@@ -1,441 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 54{% endblock %}
-{% block content %}
            
-
            --- Log opened Tue Aug 19 16:56:12 2003
            
-
            17:00 -!- logger [logger@anon.iip] has joined #iip-dev
            
-
            17:00 -!- Topic for #iip-dev: Weekly IIP development meetings, and other
            
-
            	 conversations among developers are held here.
            
-
            17:00 [Users #iip-dev]
            
-
            17:00 [ cohesion] [ leenookx  ] [ mihi] [ shardy_  ] [ UserXClone]
            
-
            17:00 [ Ehud    ] [ logger    ] [ nop ] [ thecrypto] [ velour    ]
            
-
            17:00 [ hezekiah] [ lonelynerd] [ Rain] [ UserX    ] [ WinBear   ]
            
-
            17:00 -!- Irssi: #iip-dev: Total of 15 nicks [0 ops, 0 halfops, 0 voices,
            
-
            15 normal]
            
-
            17:00 -!- Irssi: Join to #iip-dev was synced in 7 secs
            
-
            17:00 < hezekiah> Alright! :)
            
-
            17:00 < hezekiah> Both loggers are in place. :)
            
-
            17:01 < thecrypto> yah!
            
-
            17:03 < hezekiah> Hmmm ...
            
-
            17:03 < hezekiah> This meeting was supposed to start 3 minutes ago.
            
-
            17:03 < hezekiah> I wonder what's up.
            
-
            17:04 < thecrypto> well, whose idle
            
-
            17:04 < hezekiah> jrand0m's not even online.
            
-
            17:04 < hezekiah> nop's been idle 15 minutes.
            
-
            17:05 < nop> hi
            
-
            17:05 < nop> sorry
            
-
            17:05 < nop> I'm super busy at work
            
-
            17:05 < mihi> [22:36] * jrand0m is off to dinner but i'll be back within
            
-
            	 the half hour for the meeting
            
-
            17:05 -!- jrand0m [~jrandom@anon.iip] has joined #iip-dev
            
-
            17:05 < hezekiah> Hi, jrand0m.
            
-
            17:05 < nop> hi
            
-
            17:05 < nop> ok, here's the thing
            
-
            17:05 < nop> I can't be seen on IIP at work right now
            
-
            17:05 < nop> so I'll check in with yall later
            
-
            17:05 < nop> got slack about it yesterday
            
-
            17:05 < nop> so
            
-
            17:05 < hezekiah> Bye, nop.
            
-
            17:05 < thecrypto> bye
            
-
            17:06 < nop> I'll hang in the channel
            
-
            17:06 < nop> just won't be obvious :)
            
-
            17:06 < hezekiah> jrand0m? Since you do the most talking these days, is
            
-
            	 there anything you want on the agenda for this meeting?
            
-
            17:07 < jrand0m> back
            
-
            17:08 < jrand0m> ok, the pesto pasta was good.
            
-
            17:08 < jrand0m> lemmie pull up the agenda-ish stuff
            
-
            17:09 -!- Lookaround [~chatzilla@anon.iip] has joined #iip-dev
            
-
            17:09 < jrand0m> x.1) i2cp sdk mods x.2) i2np review x.3) polling http
            
-
            	 transport x.4) dev status x.5) todo x.6) plan for next two weeks
            
-
            17:09 < jrand0m> (place x at whatever # in the agenda it fits)
            
-
            17:10 < thecrypto> you are the agencda
            
-
            17:10 < hezekiah> jrand0m: I don't have anything to say, and nop can
            
-
            17:10 < hezekiah> can't talk.
            
-
            17:10 < jrand0m> lol
            
-
            17:10 < hezekiah> UserX most likely won't be adding anything (he usually
            
-
            	 doesn't), so as far as I'm concerned it's all yours. :0
            
-
            17:10 < hezekiah> :)
            
-
            17:10 < jrand0m> 'k.  we logging?
            
-
            17:10 < jrand0m> heh
            
-
            17:10 < hezekiah> I'm logging everything.
            
-
            17:10 < jrand0m> cool.  ok.  0.1) welcome.
            
-
            17:10 < jrand0m> hi.
            
-
            17:11 < jrand0m> 0.2) mailing list
            
-
            17:11 < jrand0m> the list is down atm, back asap.  you'll know when it is :)
            
-
            17:11 < jrand0m> for the meantime, wiki or use iip to convo.
            
-
            17:11 < jrand0m> 1.1) i2cp sdk mods
            
-
            17:12 < jrand0m> the SDK has been updated with some bugfixes, plus some new
            
-
            	 things in the spec have been introduced.
            
-
            17:12 < jrand0m> I posted to the list yesterday with the info.
            
-
            17:13 < jrand0m> hezekiah/thecrypto/jeremiah> any questions on what I posted,
            
-
            	 or thoughts on a plan to implement the changes?  (or other alternatives I
            
-
            	 haven't considered?)
            
-
            17:13 < hezekiah> I've been running around like the chicken with my head
            
-
            	 cut off getting ready for college.
            
-
            17:13 < jrand0m> word, understood.
            
-
            17:13 < hezekiah> I had a cursory look at what you wrote, but haven't actually
            
-
            	 looked at the changes to the spec.
            
-
            17:13 < jrand0m> we barely have any more of your time left, do we...
            
-
            17:13 < hezekiah> Not until I get to college.
            
-
            17:14 < hezekiah> Once I do, then I will probably be unheard from for at
            
-
            	 least a week while I adjust.
            
-
            17:14 < jrand0m> and once you get there you'll have a lot of settling in to do
            
-
            	 (iirc from when i went to school ;)
            
-
            17:14 < jrand0m> heh word.
            
-
            17:14 < hezekiah> Then by then, I should be a bit more efficient and have
            
-
            	 more time so I can code.
            
-
            17:14 < jrand0m> cool
            
-
            17:14 < thecrypto> i'm just doing crypto, so the data structures are my real
            
-
            	 worry, once i have the CTS mode done, i'll go work on that prolly
            
-
            17:14 < hezekiah> Anyway, that's my guess.
            
-
            17:14 < jrand0m> awesome thecrypto
            
-
            17:15 < jrand0m> ok, the good thing is the SDK works perfectly fine (with
            
-
            	 the bugs mihi found being fixed [yay mihi!]) without the update to the spec.
            
-
            17:15 -!- arsenic [~none@anon.iip] has joined #iip-dev
            
-
            17:16 < jrand0m> ok, on to 1.2) i2np review
            
-
            17:16 < jrand0m> anyone read the doc?
            
-
            17:16 < jrand0m> ;)
            
-
            17:16 < hezekiah> Not I, yet.
            
-
            17:16 < hezekiah> As I said, I'm currently a chicken with its head cut off.
            
-
            17:17 < hezekiah> BTW jrand0m, it appears you like sending PDF's.
            
-
            17:17 < jrand0m> can everyone read openoffice .swx?
            
-
            17:17 < hezekiah> I can.
            
-
            17:17 < jrand0m> [if so, I'll send swx]
            
-
            17:17 -!- abesimpson [~k@anon.iip] has joined #iip-dev
            
-
            17:17 < thecrypto> i can
            
-
            17:17 < hezekiah> I can't search for text in a PDF with KGhostView.
            
-
            17:17 < hezekiah> So that really hurts.
            
-
            17:17 < jrand0m> that sucks hezekiah
            
-
            17:17 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev
            
-
            17:17 < hezekiah> The linux version of Adobe Acrobat isn't very friendly eiter.
            
-
            17:18 < jrand0m> ok, openoffice format it is instead of pdf.
            
-
            17:18 < hezekiah> Cool.
            
-
            17:18 < jrand0m> um, ok.  i2np has a few minor changes to the LeaseSet
            
-
            	 structure (reflecting the i2cp change posted earlier), but other than that,
            
-
            	 largely in place.
            
-
            17:19 < hezekiah> jrand0m: Are all these docs in cathedral's CVS?
            
-
            17:19 < nop> oh
            
-
            17:19 < nop> can I interject
            
-
            17:19 < hezekiah> i.e. copies of the PDF files you've been sending to the
            
-
            	 list, etc.
            
-
            17:19 < hezekiah> nop: Go ahead.
            
-
            17:19 < nop> this is offtopic but important
            
-
            17:19 -!- ChZEROHag [hag@anon.iip] has joined #iip-dev
            
-
            17:19 < nop> IIP-dev and the mail are kind of screwy right now
            
-
            17:19 < hezekiah> I noticed.
            
-
            17:19 < nop> so bear with us for a bit
            
-
            17:20 < nop> we're trying to get it up and going
            
-
            17:20 < nop> but it has spam assassin built in
            
-
            17:20 < nop> which is the good news
            
-
            17:20 < nop> :)
            
-
            17:20 < nop> and a lot of other features
            
-
            17:20 < jrand0m> any eta nop for the list?
            
-
            17:20  * ChZEROHag pokes his nose in
            
-
            17:20 < jrand0m> (i know you're busy, not nagging, just wondering)
            
-
            17:20 < nop> hopefully by tomorrow
            
-
            17:20 < jrand0m> cool
            
-
            17:20 < nop> the mail admin is working on it
            
-
            17:21  * hezekiah notes that jrand0m _really_ likes the iip-dev list. ;-)
            
-
            17:21 < nop> haha
            
-
            17:21 < hezekiah> Go delta407!
            
-
            17:21 < nop> anyway
            
-
            17:21 < jrand0m> its best to document decisions publicly hezekiah ;)
            
-
            17:21 < nop> back to our regularly scheduled meeting
            
-
            17:21 < jrand0m> heh
            
-
            17:21 -!- nop is now known as nop_afk
            
-
            17:21 < hezekiah> jrand0m: So where were we?
            
-
            17:21 < jrand0m> ok, to your equestion hezekiah> some are, but the latest
            
-
            	 aren't.  I'll switch to placing in the openoffice format.
            
-
            17:21 < jrand0m> rather than the pdfs
            
-
            17:22 < hezekiah> OK.
            
-
            17:22 < hezekiah> It'd be really cool if all the docs were in CVS.
            
-
            17:22 < jrand0m> definitely, and they will be
            
-
            17:22 < hezekiah> Then I can just update, and I know I have the latest edition.
            
-
            17:22 < jrand0m> (there are the three drafts that aren't so far)
            
-
            17:22 < hezekiah> (BTW, a little off topic, but is anonymous access to
            
-
            	 cathedral up yet?)
            
-
            17:23 < jrand0m> not yet.
            
-
            17:23 < jrand0m> ok, by friday, I hope to have another draft of I2NP in
            
-
            	 full form [aka no more ... for the kademlia explanation sections, and sample
            
-
            	 implementation details]
            
-
            17:24 < jrand0m> there are no significant changes.  just more filling
            
-
            	 clarifying things.
            
-
            17:24 < hezekiah> Sweet.
            
-
            17:24 < hezekiah> Will there be byte layout for data structures avalible in it?
            
-
            17:24 < jrand0m> 1.3) I2P Polling HTTP Transport spec.
            
-
            17:24 < jrand0m> no, byte layouts go in the data structures spec, which
            
-
            	 should be converted to the standard format instead of html
            
-
            17:25 < jrand0m> (though I2NP already has all the necessary byte layouts)
            
-
            17:25 < jrand0m> ((if you read it *cough* ;)
            
-
            17:25 < hezekiah> Good.
            
-
            17:25 < hezekiah> lol
            
-
            17:25 < hezekiah> Sorry about that.
            
-
            17:25 < hezekiah> As I said, I've been really busy.
            
-
            17:25 < jrand0m> heh no worry, you're heading off to college shortly, you're
            
-
            	 supposed to be partying :)
            
-
            17:25 < hezekiah> Partying?
            
-
            17:25 < jrand0m> ok, 1.3) I2NP Polling HTTP Transport spec
            
-
            17:25 < hezekiah> Hmmm ... I guess I'm just odd.
            
-
            17:25 < jrand0m> heh
            
-
            17:26 < jrand0m> ok, I tried sending this out earlier, but I'll commit
            
-
            	 it shortly.  its a quick and dirty transport protocol fitting in with I2NP
            
-
            	 to allow routers to send data back and forth without direct connections
            
-
            	 (e.g. firewalls, proxies, etc)
            
-
            17:27 < jrand0m> I'm *hoping* someone can see how this works and build
            
-
            	 similar transports (e.g. bidirectional TCP, UDP, direct HTTP, etc)
            
-
            17:27 -!- mihi [none@anon.iip] has quit [Ping timeout]
            
-
            17:27 < hezekiah> Hmmm, well I don
            
-
            17:27 < jrand0m> before putting I2NP out for review, we need to include
            
-
            	 sample transports so people can see the full picture
            
-
            17:27 < hezekiah> don't think _I'll_ be building any transports soon. ;-)
            
-
            17:27 -!- WinBear_ [~WinBear@anon.iip] has joined #iip-dev
            
-
            17:27 < hezekiah> TCP is working for Java and Python.
            
-
            17:27 < hezekiah> (At least client-to-router is.)
            
-
            17:27 < jrand0m> no worry, I'm just putting it out there as a todo for people
            
-
            	 who want to contribute
            
-
            17:28 < hezekiah> Right.
            
-
            17:28 < jrand0m> right, client-router has different requirements than the
            
-
            	 router-router.
            
-
            17:28 < jrand0m> ok, anyway, 1.4) dev status
            
-
            17:28 < jrand0m> how we doing with CBC thecrypto?
            
-
            17:28 < thecrypto> CBC is committed
            
-
            17:28 < jrand0m> w00000t
            
-
            17:28 < thecrypto> CTS is almost done
            
-
            17:28 < hezekiah> thecrypto: What's CTS?
            
-
            17:29 < thecrypto> i just have to figure out how to implement i nicely
            
-
            17:29 < jrand0m> cts being cyphertext stealing :)
            
-
            17:29 < hezekiah> Ah!
            
-
            17:29 < thecrypto> CipherText Stealing
            
-
            17:29 -!- WinBear [WinBear@anon.iip] has quit [EOF From client]
            
-
            17:29 < jrand0m> did you pull nop's reference on that?
            
-
            17:29 < hezekiah> OK. We're using CBC with CTS instead of padding.
            
-
            17:29 < hezekiah> Hmm.
            
-
            17:29 < thecrypto> basically, it makes the message exaclty right length
            
-
            17:29 < jrand0m> is that workable for the python side hezekiah?
            
-
            17:29 < hezekiah> I might need to slap the Python crypto lib I'm using upside
            
-
            	 the head to make it us CTS properly.
            
-
            17:30 < hezekiah> I've always prefered CTS over padding, but I don't know
            
-
            	 what PyCrypt does.
            
-
            17:30 < jrand0m> what can python do out of the box to allow exact message
            
-
            	 size recovery?
            
-
            17:30 < thecrypto> all you need to do is change how you process the last
            
-
            	 two blocks
            
-
            17:30 < hezekiah> I have a feeling that library is going to get some serious
            
-
            	 rewritting.
            
-
            17:30 < hezekiah> jrand0m: The CBC stuff in python is transparent. You just
            
-
            	 send the buffer to the AES objects encrypt function.
            
-
            17:31 < hezekiah> It spits out cipher text.
            
-
-
            17:31 < hezekiah> End of story.
            
-
            17:31 < jrand0m> does D(E(data,key),key) == data, byte for byte, exact
            
-
            	 same size?
            
-
            17:31 < hezekiah> So if it has the wacky idea of using padding instead of CTS,
            
-
            	 then I might need to get in its guts and fix it.
            
-
            17:31 < jrand0m> (regardless of input size?)
            
-
            17:31 -!- mihi [~none@anon.iip] has joined #iip-dev
            
-
            17:31 < hezekiah> jrand0m: Yes. It should.
            
-
            17:31 < jrand0m> hezekiah> if you could look into exactly what algorithm it
            
-
            	 uses to do the padding, that'd be great
            
-
            17:32 < hezekiah> Right.
            
-
            17:32  * jrand0m is hesitant at requiring a mod to a python crypto lib if
            
-
            	 the lib already uses a standard and useful mechanism
            
-
            17:32 < hezekiah> One way or another, CBC with CTS sounds good.
            
-
            17:32 < hezekiah> jrand0m: This python crypto lib stinks.
            
-
            17:32 < jrand0m> heh 'k
            
-
            17:33 < thecrypto> i just have to calculate how to mess with the two blocks
            
-
            17:33 < hezekiah> jrand0m: ElGamal will need to be completely rewritten in
            
-
            	 C just to make it fast enough to use.
            
-
            17:33 < jrand0m> hezekiah> whats the benchmark for python elg of 256bytes?
            
-
            	 its only done once per dest-dest comm...
            
-
            17:34 < jrand0m> (if you know offhand, that is)
            
-
            17:34 < hezekiah> I'd have to test it.
            
-
            17:34 < hezekiah> Encryption is only a second or two I think
            
-
            17:34 < jrand0m> < 5 sec, < 2 sec, > 10 sec, > 30 sec?
            
-
            17:34 < thecrypto> i'll prolly do some work with it
            
-
            17:34 < hezekiah> Decrypton might be some place between 5 or 10 seconds.
            
-
            17:34 < jrand0m> cool.
            
-
            17:35 < jrand0m> hezekiah> have you spoken with jeremiah or do you have any
            
-
            	 news about the status of the python client api?
            
-
            17:35 < hezekiah> thecrypto: All you should need to do is write a C module
            
-
            	 that works with Python.
            
-
            17:35 < hezekiah> I have no clue what he's been up to.
            
-
            17:35 < hezekiah> I haven't spoken to him since I got back.
            
-
            17:35 < jrand0m> 'k
            
-
            17:35 < jrand0m> any other dev status thoughts?
            
-
            17:36 < hezekiah> Um, not really from me.
            
-
            17:36 < hezekiah> I've already explained my current free time status.
            
-
            17:36 < jrand0m> word.  understood
            
-
            17:36 < hezekiah> My only plans are to get the C API up and the python router
            
-
            	 back up to spec.
            
-
            17:37 < jrand0m> 'k
            
-
            17:37 < hezekiah> Oh my goodness!
            
-
            17:37 < jrand0m> 1.4) todo
            
-
            17:37 < jrand0m> si sr?
            
-
            17:37 < hezekiah> The Python crypto lib doesn't implement CTS or padding!
            
-
            17:37 < hezekiah> I'll have to do that manually.
            
-
            17:37 < jrand0m> hmm?  it requires data to be mod 16 bytes?
            
-
            17:37 < hezekiah> Yup.
            
-
            17:38 < jrand0m> heh
            
-
            17:38 < jrand0m> oh well.
            
-
            17:38 < hezekiah> Currently the Python router uses padding.
            
-
            17:38 < jrand0m> ok.  here are some oustanding items that need to get done.
            
-
            17:38 < hezekiah> I remember that now.
            
-
            17:38 < hezekiah> Well, let
            
-
            17:38 < hezekiah> let's be frank about one thing.
            
-
            17:38 < hezekiah> The Python router is never really meant to be used.
            
-
            17:39 < hezekiah> It's primarily meant for me to be very familiar with the
            
-
            	 spec and it also accomplishes something else:
            
-
            17:39 < hezekiah> It forces the Java router to comply _exactly_ with the spec.
            
-
            17:39 < jrand0m> both very important goals.
            
-
            17:39 < hezekiah> Sometimes the Java router doesn't quite comply, and then
            
-
            	 the Python router screams bloody murder.
            
-
            17:39 < hezekiah> So it doesn't really need to be fast or stable.
            
-
            17:39 < jrand0m> plus I'm not sure it won't ever be used in the sdk
            
-
            17:39 < jrand0m> right.  exactly.
            
-
            17:39 < jrand0m> the python client api is a different thing though
            
-
            17:39 < hezekiah> The Python client API on the other hand needs to be decent.
            
-
            17:40 < jrand0m> exactly.
            
-
            17:40 < hezekiah> But that's jeremiah's problem. :)
            
-
            17:40 < hezekiah> I've left that to him.
            
-
            17:40 < jrand0m> the SDK local only routers are client dev use only
            
-
            17:40 < jrand0m> lol
            
-
            17:40 < jrand0m> ok, as I was saying... ;)
            
-
            17:40 < hezekiah> ;-)
            
-
            17:41 < jrand0m> - we need someone to start working on a small web page
            
-
            	 for i2p that will be used for putting out the various I2P related specs for
            
-
            	 peer review.
            
-
            17:41 < jrand0m> I'd like this to be ready before 9/1.
            
-
            17:41 < hezekiah> OK. I am stating right now that you don't want me to do that.
            
-
            17:41 < hezekiah> I'm not a good webpage designer. :)
            
-
            17:41 < jrand0m> nor I, if anyone here has seen my flog ;)
            
-
            17:41 < jrand0m> cohesion?  ;)
            
-
            17:41 < hezekiah> lol
            
-
            17:42 < hezekiah> Poor cohesion, always stuck with the dirty work. :-)
            
-
            17:42  * cohesion reads the back log
            
-
            17:42 < hezekiah> ;)
            
-
            17:42 < jrand0m> heh
            
-
            17:42 < cohesion> jrand0m: I will do it
            
-
            17:42 < cohesion> me@jasonclinton.com
            
-
            17:42 < cohesion> send me the specs
            
-
            17:42 < jrand0m> 'k, gracias.
            
-
            17:42 < jrand0m> the specs aren't all done yet.
            
-
            17:43 < jrand0m> but the contents that will need to be there are:
            
-
            17:43 < cohesion> well, what you have an what you would like to have put up
            
-
            17:43 < jrand0m> -I2CP spec, I2NP spec, Polling HTTP Transport spec, TCP
            
-
            	 Transport spec, Security analysis, Performance analysis, Data structure spec,
            
-
            	 and a readme/intro
            
-
            17:44 < jrand0m> (those 7 documents will be in pdf and/or text format)
            
-
            17:44 < cohesion> k
            
-
            17:44 < jrand0m> barring the readme/intro
            
-
            17:45 < jrand0m> I'm hoping that all of those docs will be ready by next week
            
-
            	 (8/26).  will that give you enough time to get together a small page for a
            
-
            9/1 release?
            
-
            17:46 < jrand0m> ok.  another thing that will need to come down the pipe is
            
-
            	 an I2P network simulator.
            
-
            17:46 < jrand0m> do we have anyone looking for a CS project?  ;)
            
-
            17:46 < hezekiah> lol
            
-
            17:46 < cohesion> jrand0m: yea, that's doable
            
-
            17:47 < hezekiah> I'm not for another few years. ;-)
            
-
            17:47 < jrand0m> cool cohesion
            
-
            17:47 < thecrypto> not for a year
            
-
            17:47  * cohesion goes back to work
            
-
            17:47 < jrand0m> tnx cohesion
            
-
            17:48 < jrand0m> ok, 1.6) next two weeks.  on my plate is getting these specs,
            
-
            	 docs, and analysis up.  I'll post & commit as soon as I can.
            
-
            17:48 < jrand0m> PLEASE READ THE SPECS AND COMMENT
            
-
            17:48 < jrand0m> :)
            
-
            17:48 < hezekiah> jrand0m: Right. Once I get time, I will start reading. :)
            
-
            17:48 < jrand0m> I'd prefer people to post comments to the list, but if
            
-
            	 people want to be anon, send me comments privately and I'll post replies to
            
-
            	 the list anonymously.
            
-
            17:49 < hezekiah> (What do you think the eta for OpenOffice files for the
            
-
            	 docs being on CVS is?)
            
-
            17:49 < jrand0m> I can commit the latest revs within 10 minutes of this
            
-
            	 meeting being over.
            
-
            17:49 < hezekiah> Awesome. :)
            
-
            17:50 < jrand0m> ok, thats it for 1.*.
            
-
            17:50 < jrand0m> 2.x) comments/questions/concerns/rants?
            
-
            17:50 < jrand0m> how's the sdk mod working out mihi?
            
-
            17:51 < jrand0m> or anyone else?  :)
            
-
            17:51 < hezekiah> jrand0m: What is this sdk mod you're talking about?
            
-
            17:52 < jrand0m> hezekiah> two bugfixes to the sdk, commited (& posted)
            
-
            	 the other day
            
-
            17:52 < hezekiah> Ah
            
-
            17:52 < hezekiah> Neato.
            
-
            17:52 < jrand0m> (rotate the message IDs, synchronize writes)
            
-
            17:52 < hezekiah> Just the java side, or the python side too?
            
-
            17:52 < jrand0m> yo no hablo python.
            
-
            17:53 < hezekiah> lol
            
-
            17:53 < jrand0m> not sure if the bugs exist there.  do you rotate message
            
-
            	 ids every 255 messages, and synchronize your writes?
            
-
            17:54 < hezekiah> I think the Python router does both
            
-
            17:54 < jrand0m> cool.
            
-
            17:54 < jrand0m> we'll let you know if it doesn't ;)
            
-
            17:54 < hezekiah> What exactly do you mean by "synchronize your writes"?
            
-
            17:55 < jrand0m> aka make sure multiple messages aren't written to a client
            
-
            	 at the same time if there are multiple clients trying to send messages to
            
-
            	 it at the same time.
            
-
            17:55 < hezekiah> All the data sent over the TCP connection gets sent in
            
-
            	 the order it originated.
            
-
            17:56 < hezekiah> So you won't be 1/2 of message A and then 1/3 of message B.
            
-
            17:56 < jrand0m> 'k
            
-
            17:56 < hezekiah> You'll get message A and then message B.
            
-
            17:56 < hezekiah> OK ... if no one else is going to talk, I suggest we
            
-
            	 adjurne the meeting.
            
-
            17:56 < mihi> my simple TCP/IP over I2p seems to work...
            
-
            17:56 < jrand0m> niiiiice!!
            
-
            17:56  * mihi was idling a bit sorry
            
-
            17:57 < hezekiah> Anyone else have anything to say?
            
-
            17:57 < jrand0m> mihi> so we'll be able to run pserver over that?
            
-
            17:57 < mihi> as long as you do not try to create lotas connections at once.
            
-
            17:57 < mihi> jrand0m: i guess so - i could ge tgoogle through it
            
-
            17:57 < jrand0m> niiiice
            
-
            17:57 < jrand0m> mihi++
            
-
            17:57 < mihi> jrand0m-ava
            
-
            17:57 < jrand0m> so you have an outproxy and an inproxy?
            
-
            17:58 < mihi> exactly.
            
-
            17:58 < jrand0m> cool
            
-
            17:58 < mihi> the destination needs keys, the source generates them on demand
            
-
            17:58  * hezekiah hands jrand0m the *baf*er. Smash the thing when you're
            
-
            	 done, man.
            
-
            17:58 < jrand0m> right.  hopefully co's naming service could help with that
            
-
            	 once its ready.
            
-
            17:59 < jrand0m> ok cool.  mihi, let me or anyone else know if there's
            
-
            	 anything we can do to help :)
            
-
            17:59 < mihi> fix that thing with the 128 msgids or build a better GUARANTEED
            
-
            	 support
            
-
            17:59  * jrand0m *baf*s nop_afk over the head for having a real job
            
-
            18:00 < mihi> jrand0m: baf abuse costs 20 yodels
            
-
            18:00 < jrand0m> lol
            
-
            18:00 < jrand0m> better guaranteed support?
            
-
            18:00 < jrand0m> (aka better performance than the one described?  we'll fix
            
-
            	 that in impl)
            
-
            18:00 < mihi> did you test my test case with start_thread=end_thread=300?
            
-
            18:01 < mihi> it generates lots of messages in one direction, and that causes
            
-
            	 all msgids to be eaten...
            
-
            18:01 < jrand0m> hmm, no, hadn't seen that message
            
-
            18:01 < hezekiah> jrand0m: Would it be reasonable to make msgid 2 bytes?
            
-
            18:01  * jrand0m tried the 200 / 201, but thats fixed with the latest
            
-
            18:01 -!- cohesion [cohesion@anon.iip] has quit [off to the lug meeting]
            
-
            18:01 < mihi> which latest?
            
-
            18:01 < hezekiah> Then they would have 65535 msgids (if you don't could
            
-
            	 msgid 0)
            
-
            18:01 < hezekiah> .
            
-
            18:02 < jrand0m> 2 byte message ids wouldn't hurt.  I'm comfortable with
            
-
            	 that change.
            
-
            18:02 < jrand0m> mihi> the one I mailed you
            
-
            18:02 < mihi> if you have a more latest than the one you sent me, send it
            
-
            	 (or give me cvs access)
            
-
            18:03 < mihi> hmm, that one fails for me with 200/201 (as well as with 300)
            
-
            18:03 < jrand0m> hmm.  I'll do some more testing and debugging and mail you
            
-
            	 what I come up with.
            
-
            18:03 < mihi> thx.
            
-
            18:04 < jrand0m> ok.
            
-
            18:04  * jrand0m declares the meeting
            
-
            18:04 < jrand0m> *baf*'ed
            
-
            18:04  * hezekiah hangs the *baf*er reverantly on its special rack.
            
-
            18:05  * hezekiah then spins around walks out the door, slamming it behind
            
-
            	 him. The baffer falls off the rack.
            
-
            18:05 < hezekiah> ;-)
            
-
            --- Log closed Tue Aug 19 18:05:36 2003
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting55.html b/www.i2p2/pages/meeting55.html
deleted file mode 100644
index 35b0edbb..00000000
--- a/www.i2p2/pages/meeting55.html
+++ /dev/null
@@ -1,214 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 55{% endblock %}
-{% block content %}
            
-
            [23:00] <jrand0m> ok, topics> x.0: welcome x.1: spec questions x.2: elg issues x.3: sdk status x.4: release plan x.5: apps 
            
-
            [23:00] <jrand0m> is x == 0 or 1 or 2? 
            
-
            [23:00] <jeremiah> 22/7
            
-
            [23:01] <thecrypto> i think it's 0
            
-
            [23:01] * jrand0m always logs, so wtf, why not.
            
-
            [23:01] <jrand0m> 0.0: welcome. 
            
-
            [23:01] <jrand0m> hi. 
            
-
            [23:01] <jrand0m> 0.1: spec questions 
            
-
            [23:01] <jrand0m> anyone read the specs?  :) 
            
-
            [23:02] * mihi did. at least tried to
            
-
            [23:02] <jrand0m> w0ah word 
            
-
            [23:02] <jeremiah> nope
            
-
            [23:02] <jeremiah> what are the new ones?
            
-
            [23:02] <thecrypto> occasionally
            
-
            [23:02] <jrand0m> mihi> tried to, hard to read, bad language, incomprehensible organization, or just boring as fuck? 
            
-
            [23:03] <mihi> i'm just not familiar enough with crypto. the first part was very interesting.
            
-
            [23:03] <jrand0m> jeremiah> specs are in cvs, and I post to iip-dev when they come out.  current ones are: i2cp, i2np, i2p data structures, polling http transport proto 
            
-
            [23:03] <mihi> but when it got into detaily, you could have described how to brew an irish stew and i would not hav noticed ;)
            
-
            [23:04] <jeremiah> sweet
            
-
            [23:04] <jrand0m> lol mihi 
            
-
            [23:05] <mihi> although the format had its problems as well -don't have open office here, just ol' staroffice 5.2
            
-
            [23:05] <jrand0m> does star office 5.2 not read it?  would you prefer .pdf or kludged html? 
            
-
            [23:05] <jrand0m> (or .txt?  though txt wouldn't have pics or real formatting) 
            
-
            [23:05] <mihi> i'd prefer "old" .sdw format.
            
-
            [23:05] <jeremiah> pdf if at all possible
            
-
            [23:05] <mihi> or pdf
            
-
            [23:06] <jrand0m> pdf is a one click solution. 
            
-
            [23:06] * jrand0m edits in open office, reads in pdf
            
-
            [23:06] <jeremiah> or appleworks
            
-
            [23:06] <jeremiah> ;)
            
-
            [23:06] <mihi> sxw is supported only in staroffice 6.0 and above
            
-
            [23:06] <jrand0m> ah ok mihi 
            
-
            [23:06] * jrand0m put out .sxw because last time people complained and wanted .sxw.  when we publish we'll put out .sxw, .sdw, and .pdf
            
-
            [23:07] <jrand0m> (or maybe .doc if i'm feeling dirty) 
            
-
            [23:07] <mihi> i would not mind .sdw.zip or .sdw.gz or .sdw.bzw either...
            
-
            [23:07] <mihi> s/bzw/bz2/
            
-
            [23:07] <jrand0m> heh, zipped up, for sure. 
            
-
            [23:08] <jrand0m> the data structures spec may require a mod, and the network proto requires some fixed urls before release. 
            
-
            [23:08] <jrand0m> anyone have any questions on any of the four specs? 
            
-
            [23:09] <thecrypto> not at the momemet
            
-
            [23:10] <jrand0m> ok.  0.2: elg issues 
            
-
            [23:10] <jrand0m> we're having some probs w/ elgamal encryption as specified on p13 of the data structures spec. 
            
-
            [23:11] <jrand0m> it may be key related, algorithm related, or implementation related.  probably not implementation related, as this has been tested against two implementations. 
            
-
            [23:11] <jrand0m> if its algorithm related, we're going to want to update the spec prior to spec release to reflect whatever we need to change to make it work. 
            
-
            [23:12] <jrand0m> if its implementation or key generation related, we can publish the spec and fix the sdk when resolved. 
            
-
            [23:13] <jrand0m> thecrypto> any thoughts on whats up, or we waiting for nop to reply to the list (or here, if he's around and available to talk) 
            
-
            [23:14] <thecrypto> i'm trying to figure it out at the moment
            
-
            [23:15] *** Signoff: mihi (Ping timeout)
            
-
            [23:15] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
            
-
            [23:15] <jrand0m> 'k 
            
-
            [23:15] *** mihi_ is now known as mihi
            
-
            [23:15] <thecrypto> i have to run some math and through some other implementation and figure it out
            
-
            [23:15] <thecrypto> i never had a problem with elgamal
            
-
            [23:15] <thecrypto> last time i tested
            
-
            [23:16] *** Signoff: mihi ((null))
            
-
            [23:17] <thecrypto> with that benchmark
            
-
            [23:17] <jrand0m> right, but the benchmark only tried one key 
            
-
            [23:17] <thecrypto> ahh
            
-
            [23:17] <jrand0m> i can quite repeatedly get the error without any mods to the elg impl 
            
-
            [23:17] <thecrypto> didn't we have a wrong key message that came up?
            
-
            [23:18] <jrand0m> yes, those still come up 
            
-
            [23:18] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
            
-
            [23:18] <jrand0m> periodically (usually 2-4 times per keygen) 
            
-
            [23:18] *** mihi (~none@anon.iip) has joined channel #iip-dev
            
-
            [23:18] *** mihi is now known as mihi_backup
            
-
            [23:18] *** mihi_ is now known as mihi
            
-
            [23:18] <thecrypto> and we still get bad keys?
            
-
            [23:19] <jrand0m> or something. 
            
-
            [23:19] <jrand0m> all that wrong size tests is "if ( (k0.length == PublicKey.KEYSIZE_BYTES) && (k1.length == PrivateKey.KEYSIZE_BYTES) ) {" 
            
-
            [23:19] <jrand0m> no value evaluation, etc. 
            
-
            [23:20] <thecrypto> one second
            
-
            [23:23] <thecrypto> can you check if x the private key is < p
            
-
            [23:23] <jrand0m> if (m.compareTo(CryptoConstants.elgp) >= 0) 
            
-
            [23:23] <jrand0m> already done. 
            
-
            [23:23] <jrand0m> (throw new IllegalArgumentException("ARGH.  Data cannot be larger than the ElGamal prime.  FIXME");)  that exception is never thrown. 
            
-
            [23:23] <jrand0m> er x?  hmm.   
            
-
            [23:24] <jrand0m> 'k.  perhaps we may want to steal bouncycastle's or another impl's elg key gen algo 
            
-
            [23:25] <jrand0m> ok.  0.3> sdk issues 
            
-
            [23:26] <jrand0m> elg is pending, but other than that the sdk is very close to 0.8 (aka release matching specs) 
            
-
            [23:26] <jrand0m> (only the elg issue plus the LeaseSet modification is left) 
            
-
            [23:26] <jrand0m> I'd like to have the SDK 0.8 ready to go with the spec release, but I don't think we should commit to that. 
            
-
            [23:27] <jrand0m> or even whether we need to include SDK 0.1 with the spec release. 
            
-
            [23:27] <thecrypto> gah! annoying
            
-
            [23:28] <thecrypto> miracl which nop pointed me too does the exact same thing we do
            
-
            [23:28] <thecrypto> and they have no checks
            
-
            [23:28] <jrand0m> unsigned though. 
            
-
            [23:28] <jrand0m> (since miracl is in c) 
            
-
            [23:28] * jrand0m assumes
            
-
            [23:28] <thecrypto> yes
            
-
            [23:29] <thecrypto> but still, i make sure we never have a signed biginteger
            
-
            [23:30] <jrand0m> biginteger.toByteArray() returns a signed byte array 
            
-
            [23:30] <thecrypto> sorry, continue
            
-
            [23:30] <jrand0m> 'k 
            
-
            [23:30] <jrand0m> any movement on the python front jeremiah? 
            
-
            [23:31] <jeremiah> hey
            
-
            [23:31] <jeremiah> sorry I was reading the backlog
            
-
            [23:31] <jrand0m> heh hi 
            
-
            [23:31] <jeremiah> nope, I'm still getting used to classes
            
-
            [23:31] <jrand0m> coo' 
            
-
            [23:31] <jrand0m> no prob 
            
-
            [23:31] <jeremiah> I think I'm gonna sleep for a bit actually
            
-
            [23:31] <jrand0m> 'k 
            
-
            [23:32] <jrand0m> 0.4: release plan 
            
-
            [23:32] <jrand0m> we need the sdk issues resolved in the next day or so, one way or another. 
            
-
            [23:32] <jrand0m> we need to get working on wiki-fiying the security model 
            
-
            [23:32] <jrand0m> (wiki, where art thou) 
            
-
            [23:33] <jrand0m> we need to get the performance model up (not a prob, ill have it in a day or so) 
            
-
            [23:33] <jrand0m> we need to update the specs to include any elg mods, plus real URLs to other specs. 
            
-
            [23:33] <nop> miracl
            
-
            [23:33] <nop> has a port
            
-
            [23:33] <nop> to java
            
-
            [23:33] <jrand0m> perhaps we need to host the specs && / || sdk outside the US for export regulations [not that i care] 
            
-
            [23:34] <jrand0m> right, but miracl's java port doesnt have elg encryption last i checked. 
            
-
            [23:34] <jrand0m> i'll check again. 
            
-
            [23:34] <nop> jrand0m, we don't care, but we'll worry about that later
            
-
            [23:34] <nop> jrand0m if it has bigdig() and modexp()
            
-
            [23:34] <nop> you're fine
            
-
            [23:34] *** yodel (~yodel@anon.iip) has joined channel #iip-dev
            
-
            [23:34] <thecrypto> one second
            
-
            [23:34] <thecrypto> i think i found our problem
            
-
            [23:35] <jrand0m> word, whats up thecrypto? 
            
-
            [23:35] <nop> can you check jrand0m
            
-
            [23:35] <thecrypto> our k isn't being checked for relitive prime
            
-
            [23:36] <jrand0m> will that cause the problems described thecrypto?  i thought that would just render the encryption insecure (a problem, nonetheless) 
            
-
            [23:36] <thecrypto> but that would mean only some messages with the key would fail
            
-
            [23:36] <thecrypto> it's something in keygen
            
-
            [23:36] <jrand0m> nop> we'll find something to solve it.  but i outlined some specific questions in my email that are implementation independent 
            
-
            [23:36] <jrand0m> ok thecrypto, we'll work through that after the meeting 
            
-
            [23:37] <nop> the double ciphertext question?
            
-
            [23:37] <thecrypto> okay
            
-
            [23:37] <jrand0m> nop> thats one of the questions 
            
-
            [23:37] * nop goes to read
            
-
            [23:39] <jrand0m> nop> any ideas on when the wiki will be up?  if its just dns, whats the IP so I can mod my hosts file so I can start editing? 
            
-
            [23:40] <thecrypto> quick q jrand0m: where does it fail, the benchmark runs perfectly and it makes a new keypair every time?
            
-
            [23:41] <nop> let me get it up, hold
            
-
            [23:41] <mihi> wiki.invisiblenet.net == jasonclinton.com [64.91.236.103]
            
-
            [23:41] <jrand0m> gracias mihi 
            
-
            [23:42] <jrand0m> thecrypto> it makes a new keypair each time.  it fails on a two line test case that I built when debugging the ElGamalAESEngine 
            
-
            [23:42] <thecrypto> can i see this ElGamalAESEngine?
            
-
            [23:42] <thecrypto> just commit it to CVS and i'll see what the problem is
            
-
            [23:43] <nop> ok wiki is cname'd
            
-
            [23:43] <nop> should propagate in a bit
            
-
            [23:43] * jrand0m doesnt commit things that don't work, but I'll email you
            
-
            [23:43] <jrand0m> thanks nop 
            
-
            [23:43] <nop> it's up
            
-
            [23:43] <nop> ;)
            
-
            [23:43] <nop> (Link: http://wiki.invisiblenet.net)http://wiki.invisiblenet.net
            
-
            [23:43] <jrand0m> not on my box it aint 
            
-
            [23:43] <jrand0m> ;) 
            
-
            [23:44] <nop> what are we wiki'ing
            
-
            [23:44] <nop> ?
            
-
            [23:44] <jrand0m> the security doc, plus a place to distro the specs. 
            
-
            [23:44] <jrand0m> perhaps even the i2p website prior to 1.0 release, but at least the security doc. 
            
-
            [23:45] *** Signoff: sirk ((null))
            
-
            [23:45] *** Signoff: shardy_ (Ping timeout)
            
-
            [23:46] <jrand0m> ok.  given the above 5 points on the release plan, I'd like to have the specs out friday, saturday, or sunday, at the latest. 
            
-
            [23:46] *** shardy_ (~shardy@anon.iip) has joined channel #iip-dev
            
-
            [23:46] <nop> I have a grphx guy working on the website
            
-
            [23:47] <nop> for i2p
            
-
            [23:47] <jrand0m> any problems with that for a deadline?  [friday deadline, fallback only if Bad Things Happen] 
            
-
            [23:47] <nop> sure
            
-
            [23:47] <thecrypto> jrand0m: sent?
            
-
            [23:47] <jrand0m> 'k, so just the security docs and the i2p spec distro location 
            
-
            [23:47] <jrand0m> no thecrypto, there are half a dozen files.  i'll send after the meeting. 
            
-
            [23:47] <thecrypto> okay
            
-
            [23:48] <thecrypto> i'd like them sooner because we're moving tables around today so i need to move computers soon
            
-
            [23:48] <nop> jrand0m, I'll need to look at your email and I'll respond shortly
            
-
            [23:48] <nop> multi-tasking
            
-
            [23:49] <jrand0m> 'k. 
            
-
            [23:49] <jrand0m> 0.5> apps 
            
-
            [23:49] <jrand0m> the name service is awol, as co aint around ;)  [but i think he just went off to school too, so thats to be expected for the short term] 
            
-
            [23:49] <jrand0m> mihi has an awesome awesome i2ptunnel app 
            
-
            [23:50] *** Signoff: WinBear_ (EOF From client)
            
-
            [23:50] <mihi> strip one or two `awesome's ;)
            
-
            [23:50] <jrand0m> heh 
            
-
            [23:51] <jrand0m> well, its very impressive.  there's still stuff to add, but as is its a working port forwarder with reasonable performance.  a really good proof of concept 
            
-
            [23:51] <mihi> it relies on too many things i cannot see from the spec (e.g. that GUARANTEED packets are delivered in order)
            
-
            [23:52] <jrand0m> guaranteed packets are not delivered in order, but the java impl blocks on send of guaranteed, so if you use the java impl w/ guaranteed and don't have multiple sending threads, its guaranteed in order. 
            
-
            [23:52] <jrand0m> ideally, it'd be cool if it FEC'ed or had built in ordering & reconstruction or something 
            
-
            [23:52] <jrand0m> (so that it didn't block on send and didn't require GUARANTEED) 
            
-
            [23:53] <mihi> that's a bot too many ifs i think...
            
-
            [23:53] <mihi> s/bot/bit/
            
-
            [23:55] <mihi> but perhaps i'll have some time to add reordering/resending to it...
            
-
            [23:55] <jrand0m> well, thats how the java client impl is implemented ;)  guaranteed is not recommended for low latency synchronous use, as it requires an ack (which in turn is a full message delivery, though without the client side end to end crypto, just i2np crypto) 
            
-
            [23:55] <jrand0m> word 
            
-
            [23:56] <jrand0m> any other apps on the horizon?  should we have a page on the wiki w/ apps & app ideas for devs to get involved with? 
            
-
            [23:57] * jrand0m thinks we probably aren't too far off until yodel's xml rpc can operate via the i2p sdk (either through mihis tunnel or natively)
            
-
            [23:57] <nop> hmm
            
-
            [23:57] <thecrypto> test
            
-
            [23:57] <jrand0m> tset 
            
-
            [23:57] <thecrypto> still connected?
            
-
            [23:57] <jrand0m> si sr 
            
-
            [23:58] <thecrypto> we're unplugging phonelines right now
            
-
            [23:58] <nop> IIP, it defies phone lines
            
-
            [23:58] <jrand0m> heh 
            
-
            [23:58] <nop> :)
            
-
            [23:58] <thecrypto> i can get back on the IM front and file transfer
            
-
            [23:58] <jrand0m> wikked 
            
-
            [00:00] <jrand0m> ok.  thats all i have for agenda items. 
            
-
            [00:00] <jrand0m> any comments/questions/concerns/frisbees? 
            
-
            [00:00] * thecrypto throws a frisbee
            
-
            [00:00] * jrand0m gets a frisbee in the face
            
-
            [00:01] <thecrypto> i just want to get this crypto stuff done so i can go back and optimize elg
            
-
            [00:01] <thecrypto> and do the same for python hopefully
            
-
            [00:01] <jrand0m> word.  I'll get you the code in the next 5 
            
-
            [00:02] <thecrypto> that would be good
            
-
            [00:03] * jrand0m readies the *baf*er
            
-
            [00:03] * jrand0m winds up
            
-
            [00:03] * jrand0m *baf*s the meeting to a close.
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting56.html b/www.i2p2/pages/meeting56.html
deleted file mode 100644
index de7a01df..00000000
--- a/www.i2p2/pages/meeting56.html
+++ /dev/null
@@ -1,215 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 56{% endblock %}
-{% block content %}
            
-
            [22:53] <jrand0m> ok, wtf, why not.  agenda: 
            
-
            [22:53] <jrand0m> 0) welcome 
            
-
            [22:53] <jrand0m> 1) spec & sdk release  
            
-
            [22:53] <jrand0m> 2) spec & sdk questions  
            
-
            [22:53] <jrand0m> 3) dev status 3.1) co's NS 3.2) SDK 1.0 criteria 3.3) network simulator 3.4) other apps [IM, tunnel, etc] 3.5) more transports 3.6) java router implementation   
            
-
            [22:53] <jrand0m> 4) meeting time change?   
            
-
            [22:53] <jrand0m> 5) cvs administravia 
            
-
            [22:54] <jrand0m> 6) shardy's stuff 
            
-
            [22:54] <jrand0m> 7) peanut gallery 
            
-
            [22:54] <jrand0m> thazzit. 
            
-
            [22:54] <jrand0m> 0) welcome 
            
-
            [22:54] <w0rmus> hihi
            
-
            [22:54] <thecrypto> so welcome everyone to meeting number 55
            
-
            [22:54] <thecrypto> 56
            
-
            [22:55] <thecrypto> 56 is correct
            
-
            [22:55] *** Signoff: mihi (EOF From client)
            
-
            [22:55] <jrand0m> hi.  welcome to meeting 56 
            
-
            [22:55] <jrand0m> yea 
            
-
            [22:55] <jrand0m> 1) spec & sdk release 
            
-
            [22:55] <w0rmus> haha
            
-
            [22:55] *** mihi (~none@anon.iip) has joined channel #iip-dev
            
-
            [22:55] <jrand0m> the specs are out and the sdk 0.2 is out as well. 
            
-
            [22:56] <jrand0m> currently, they're only available on freenet [http://localhost:8888/CHK@p1VU1U67UgXYJ7v7cS4Xqn~p4ssLAwI,RvdwV4jZyZYcJgYabpVPOQ/I2P_SDK.zip] 
            
-
            [22:56] <jrand0m> but nop told me he'd have them on the normal web today, as well as an email to a few of the traditional lists to round up some reviewers 
            
-
            [22:57] <jrand0m> 2) any new questions on the specs or the sdk? 
            
-
            [22:58] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev
            
-
            [22:58] *** terrific (terrific@anon.iip) has joined channel #iip-dev
            
-
            [22:58] <jrand0m> well, first question in there is, how goes the progress /reading/ the specs?  :) 
            
-
            [22:58] <w0rmus> needa do that :)
            
-
            [22:58] <thecrypto> slowlyu
            
-
            [22:58] <w0rmus> therefore I have no questions
            
-
            [22:58] <jrand0m> heh word 
            
-
            [22:59] <w0rmus> I'll start now then
            
-
            [22:59] <jrand0m> suggested order of reading the PDFs is> I2POverview.pdf, then I2NP, then datastructures, then I2CP, then polling HTTP transport 
            
-
            [22:59] <w0rmus> ok I'll do it in that order then
            
-
            [23:00] <jrand0m> ok.  on to # 3 then, unless there are any q's on the specs 
            
-
            [23:00] <jrand0m> 3.1) co's naming service proposal 
            
-
            [23:00] <jrand0m> he posted rev 1.1 of his spec up to the mailing list this morning and it seems to deal with a lot of the issues brought up before 
            
-
            [23:01] <jrand0m> does anyone have any comments/questions on the spec that they want to say here?  or should we just do that part on the list, since co isn't here atm? 
            
-
            [23:01] <mihi> how can one get the address of a name server? ;)
            
-
            [23:02] <jrand0m> OOB, but good point.  he should toss in a "bootstrapping" section 
            
-
            [23:03] <thecrypto> OOB?
            
-
            [23:03] <jrand0m> out of band.  e.g. from a web site or built into the software 
            
-
            [23:03] <thecrypto> ahh
            
-
            [23:03] *** naphtala (asdf@anon.iip) has joined channel #iip-dev
            
-
            [23:04] <jrand0m> (co may actually have different ideas, I'm just assuming thats what he meant.  definitely something to mention on the list) 
            
-
            [23:04] <mihi> is there any general way to make a text representation of Destinations (e.g. ascii armor)?
            
-
            [23:05] <jrand0m> no, we haven't needed to spec that yet, though offhand I'd probably suggest alt-base64 the Destination object per that rfc that was just released 
            
-
            [23:06] <jrand0m> perhaps that should be added to the I2P data structures spec.  good idea.   
            
-
            [23:06] <jrand0m> does anyone have any qualms with base64? 
            
-
            [23:07] <jrand0m> ok.  at least for now that'll get added in. 
            
-
            [23:08] <jrand0m> 3.2) SDK 1.0 criteria 
            
-
            [23:08] <jrand0m> SDK 0.2 does full end to end crypto for java, but there's still a lot to be done before the SDK is 1.0 ready. 
            
-
            [23:09] <jrand0m> the criteria I have jotted down for the sdk 1.0: all APIs and local only routers up to spec [there are two small mods left].  full Java, C, and Python client API implementations.   
            
-
            [23:09] <jrand0m> optionally, we may want to include a streaming API as well 
            
-
            [23:10] <jrand0m> does anyone else have any 1.0 criteria they'd like to see in the SDK? 
            
-
            [23:11] *** jnk (jnk@anon.iip) has joined channel #iip-dev
            
-
            [23:11] <jrand0m> ok.  post to the list if you think of anything 
            
-
            [23:11] <jrand0m> 3.3) network simulator 
            
-
            [23:12] <jrand0m> sometime when someone has spare time, there should be efforts made on simulating the i2p net per i2np.  the performance models used so far are limited in that they do not take into consideration resource contention among different users 
            
-
            [23:13] <jrand0m> there are good tools out there, and i've got some sketches down already of how to run this, but I'm just mentioning this now in case anyone is looking for a project ;) 
            
-
            [23:14] * jrand0m utterly fails to keep a straight face wrt the likelyhood of someone jumping up and writing a simulator
            
-
            [23:14] <jrand0m> ok.  3.4) other apps 
            
-
            [23:14] <w0rmus> haha
            
-
            [23:14] *** Signoff: mihi_backup (Ping timeout)
            
-
            [23:14] * thecrypto jumps up...and writes something else
            
-
            [23:14] <jrand0m> heh 
            
-
            [23:15] <jrand0m> mihi> any mods/updates/plans for the i2ptunnel?   
            
-
            [23:17] <mihi> nope.
            
-
            [23:17] <jrand0m> cool, just checkin' in :) 
            
-
            [23:17] <mihi> if someone writes a TCP layer for I2P, i might use it, but I wont write it.
            
-
            [23:18] <jrand0m> ah word.  yeah, thats the streaming api thing.  no worry, using GUARANTEED works and is a perfect use for local only routers 
            
-
            [23:18] *** Trifixion (~lame-o@anon.iip) has joined channel #iip-dev
            
-
            [23:19] <jrand0m> and in a production environ waiting for an ACK before sending the next message is only a ~.4s delay 
            
-
            [23:19] <jrand0m> <insert caveat on latency models here> 
            
-
            [23:19] <jrand0m> ok.  next "other apps" 
            
-
            [23:20] <jrand0m> thecrypto> IM? 
            
-
            [23:20] <thecrypto> well, i'm working on a UI prototype right now
            
-
            [23:20] <thecrypto> as soon as we have some way of communicating with other people, i can just put in the networking stuff
            
-
            [23:20] <jrand0m> we /have/ some way of communicating with other people 
            
-
            [23:21] <jrand0m> (not that I'm against doing it in pieces anyway) 
            
-
            [23:21] <thecrypto> i'm going to start with just UI
            
-
            [23:21] <jrand0m> wikked. 
            
-
            [23:21] <w0rmus> I do wish to help thecrypto with the IM but I've some reading to do
            
-
            [23:21] <thecrypto> once all the UI is done, whoever is working on this will just have to plug in the networking stuff and we'll be done'
            
-
            [23:22] <jrand0m> nice 
            
-
            [23:22] <thecrypto> and i thought we only had local only unless you want to tunnel?
            
-
            [23:22] <jrand0m> will the UI have an address book feature for storing destinations of friends? 
            
-
            [23:22] <thecrypto> buddy list
            
-
            [23:23] <thecrypto> we'll have to poll the name server somehow to check when people are online
            
-
            [23:23] <jrand0m> right, local only, but you can still run multiple instances and talk to itself through the SDK.  same way normal network dev goes against localhost 
            
-
            [23:23] <jrand0m> hmm, the IM app will depend on the name server? 
            
-
            [23:23] <jrand0m> or will the IM have a central "presence" server? 
            
-
            [23:23] <thecrypto> it'll need someway to keep track of everyone
            
-
            [23:23] <thecrypto> i'm trying to avoid central anything
            
-
            [23:24] <thecrypto> but some sort of distributed presense would have to be thought up and it looks like the NS will do that
            
-
            [23:24] <jrand0m> I don't think the NS has presence.  it only says what the Destinations are 
            
-
            [23:24] <jrand0m> (for each service for each nym) 
            
-
            [23:25] <thecrypto> but doesn't it have an online offline state?
            
-
            [23:25] <jrand0m> no, the NS is just like DNS.  it doesn't tell you if the host is reachable. 
            
-
            [23:25] <thecrypto> at least i thought it do
            
-
            [23:25] *** mihi_backup (~none@anon.iip) has joined channel #iip-dev
            
-
            [23:25] <thecrypto> so you have to try it to find out
            
-
            [23:26] <thecrypto> then i'll have to come up with my own spec to work out that part
            
-
            [23:26] <jrand0m> coo'.  perhaps start without one, and maybe add a rudimentary periodic ping, and then a fully distributed whatever ;) 
            
-
            [23:27] <thecrypto> well step 1 is UI
            
-
            [23:27] <jrand0m> anyway, you know best, whatever works for ya.  if there's anything anyone can do to help, just say the word 
            
-
            [23:27] <jrand0m> right 
            
-
            [23:27] <jrand0m> ok.  I don't have any other apps to discuss in the "other apps" section.  anyone else have app related ideas / discussion? 
            
-
            [23:28] <thecrypto> well what apps do we have planned already other than IM and NS and Tunnel?
            
-
            [23:29] <w0rmus> will file transfer be implemented along with IM or separately?
            
-
            [23:29] <w0rmus> separately I imagine
            
-
            [23:29] <thecrypto> you will be allowed to file transfer IM, but other people can come up with file transfer only protocols like FTP
            
-
            [23:29] <w0rmus> ok so what you're working on will have file transfer as well
            
-
            [23:29] <jrand0m> thecrypto> I'd like to see an http proxy (perhaps ripping the code from JAP), as well as a plugin for a web server to allow I2P web publishing and browsing 
            
-
            [23:30] <thecrypto> IE replace freenet :)
            
-
            [23:30] <jrand0m> a multiplexing "outdial" tcp tunnel would be cool too 
            
-
            [23:30] <jrand0m> naw, freenet is a CDN, this would require having a server to store space on 
            
-
            [23:31] <thecrypto> okay
            
-
            [23:31] <jrand0m> (the outdial would probably require SOCKS integration though) 
            
-
            [23:32] <jrand0m> that it for the top of my head though.  with mihi's tunnel we can already ssh and cvs over i2p 
            
-
            [23:32] <jrand0m> ok.  3.5) more transports 
            
-
            [23:33] <jrand0m> we need more transports (TCP, UDP, Email).  realistically, this will probably be spec'ed and implemented in line with the router reference implementation. 
            
-
            [23:33] <jrand0m> but if someone wants to look at the polling HTTP transport and define some other transport, that'd be fantastic 
            
-
            [23:33] <thecrypto> transports kinda like the jabber transports
            
-
            [23:33] <thecrypto> translating one to another?
            
-
            [23:34] <jrand0m> hmm?  transports are the actual means of sending bytes from one router to another. 
            
-
            [23:34] <thecrypto> ahh okay
            
-
            [23:34] *** jnk has left #iip-dev
            
-
            [23:34] <thecrypto> so instead of just one method of getting the bits from one router to another there are many?
            
-
            [23:34] <jrand0m> exactly. 
            
-
            [23:34] <jrand0m> I2NP does /not/ specify a particular transport 
            
-
            [23:35] <thecrypto> so if one is firewalled/blocked/slow/... you use another
            
-
            [23:35] <jrand0m> exactly 
            
-
            [23:35] <thecrypto> sweee
            
-
            [23:35] <w0rmus> yah that sweet :)
            
-
            [23:35] <jrand0m> ok, 3.6) java router reference implementation 
            
-
            [23:36] <jrand0m> I'll probably have an architecture doc and some rapid prototypes ready this week.  nothing whatsoever will work, but it'll show how things will fit together. 
            
-
            [23:36] <jrand0m> then individual subsystems can be stub'ed and implemented in turn (or in parallel).   
            
-
            [23:37] *** Signoff: mihi (EOF From client)
            
-
            [23:37] <jrand0m> so probably by end of week or perhaps next weeks meeting I'll be making a call out for java devs to jump in and get coding :) 
            
-
            [23:37] <thecrypto> can do
            
-
            [23:38] <jrand0m> w3wt 
            
-
            [23:38] <w0rmus> hopefully can do :)
            
-
            [23:38] <jrand0m> word 
            
-
            [23:38] <jrand0m> ok.  any other dev status questions / thoughts / comments? 
            
-
            [23:39] <w0rmus> thecrypto: is anyone else working on the IM with you as of now?
            
-
            [23:39] <thecrypto> co should be
            
-
            [23:39] <w0rmus> is co cohesion?
            
-
            [23:39] <thecrypto> but right now i'm just getting the UI started
            
-
            [23:39] * jrand0m thinks co will havea /LOT/ of work with the naming service
            
-
            [23:39] <thecrypto> no co == whit
            
-
            [23:39] <jrand0m> no, co is wiht, cohesion is a different person :) 
            
-
            [23:39] <w0rmus> ok thanks
            
-
            [23:40] *** mihi (~none@anon.iip) has joined channel #iip-dev
            
-
            [23:40] <thecrypto> if it was cohesion then we would use tab compleletion
            
-
            [23:40] <jrand0m> heh 
            
-
            [23:40] <w0rmus> some people are too lazy for even that 
            
-
            [23:41] <jrand0m> ok.  agenda item 4) meeting time change 
            
-
            [23:41] <jrand0m> is anyone here further east than GMT+2? 
            
-
            [23:41] <jrand0m> you don't need to answer that... 
            
-
            [23:41] <jrand0m> er, is anyone here already pushed to their limit of lateness with 9PM GMT meeting time? 
            
-
            [23:41] * mihi_backup is gmt+2
            
-
            [23:42] <jrand0m> ah cool.  would later work for you mihi, or is 9p best? 
            
-
            [23:42] * jrand0m doesn't go to bed until after the sun rises in gmt+2
            
-
            [23:42] <mihi_backup> not much later. 8p or 7p would be better
            
-
            [23:42] <jrand0m> ah 'k 
            
-
            [23:42] <mihi_backup> but if i can't come; i'll read the log.
            
-
            [23:43] *** Signoff: cohesion (class)
            
-
            [23:43] <jrand0m> well, we have no hard reason to make it later and its good to have you here ;) 
            
-
            [23:43] <thecrypto> i say it's perfect where it is
            
-
            [23:44] <jrand0m> cool.  I just wanted to bring it up to possibly help out the left coast 'mericans who have jobs :) 
            
-
            [23:44] <jrand0m> but 9P GMT it is and 9P GMT it stays 
            
-
            [23:44] <jrand0m> ok.  item 5) cvs administravia 
            
-
            [23:45] <jrand0m> well, none of the python people are here, and thecrypto and I have already spoken re: cvs module conventions :) 
            
-
            [23:45] <jrand0m> we still are working on getting anon cvs 
            
-
            [23:45] <jrand0m> or at the very least nightly snapshots of the cvs on the web. 
            
-
            [23:45] <jrand0m> that'll be announced once its ready. 
            
-
            [23:46] <thecrypto> most of the reason for limiting access to to make sure not too many people start getting at it
            
-
            [23:46] <thecrypto> before it's ready
            
-
            [23:46] <jrand0m> right, but the SDK has the full source of everything in the tree atm anyway ;) 
            
-
            [23:47] <jrand0m> but thats a good point.  perhaps we can change perms on the dirs for the router ref impl as it progresses until its ready 
            
-
            [23:47] <jrand0m> dunno though.  we'll cross that bridge when it comes  
            
-
            [23:47] *** Trifixion has left #iip-dev
            
-
            [23:48] <jrand0m> item 6) shardy's stuff 
            
-
            [23:48] * jrand0m waves to shardy
            
-
            [23:48] <shardy> hiya
            
-
            [23:48] <shardy> um, I don't really have much of anything to say
            
-
            [23:48] <shardy> just thought I'd say hi and all
            
-
            [23:48] <shardy> seeing as how I've got myself involved in the project latey :)
            
-
            [23:48] <shardy> lately.
            
-
            [23:48] <w0rmus> hihi
            
-
            [23:49] <shardy> I don't have a ton of time until thesis/toorcon are both done, but I'll help out with what I can do until then
            
-
            [23:49] <shardy> like if you need random code debugged, or crypto implemented, or optimized
            
-
            [23:49] <shardy> the next thing I'm probably going to look at is optimizing the hell out of the crypto engine... I have a lot of experience doing that kind of stuff
            
-
            [23:49] <jrand0m> cool.  we'll probably want to pick your brain as the crypto gets implemented for the routers and we pull in yarrow or another prng 
            
-
            [23:49] <jrand0m> nice 
            
-
            [23:50] <shardy> I'll be hanging around, so grab me for whatever if you need anything.
            
-
            [23:50] <thecrypto> yah
            
-
            [23:50] <jrand0m> wikked. 
            
-
            [23:50] <jrand0m> ok.  7) peanut gallery 
            
-
            [23:50] <jrand0m> any i2p thoughts / comments / questions / concerns? 
            
-
            [23:52] <jrand0m> ok then :) 
            
-
            [23:52] *** naphtala has left #iip-dev
            
-
            [23:52] <w0rmus> i2p is neat
            
-
            [23:52] <jrand0m> heh 
            
-
            [23:52] <w0rmus> ;0
            
-
            [23:52] * jrand0m pulls the *baf* off the wall...
            
-
            [23:53] <jrand0m> ... the wind-up 
            
-
            [23:53] <jrand0m> and the *baf* 
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting57.html b/www.i2p2/pages/meeting57.html
deleted file mode 100644
index b852a774..00000000
--- a/www.i2p2/pages/meeting57.html
+++ /dev/null
@@ -1,170 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 57{% endblock %}
-{% block content %}
            
-
            [22:57] <jrand0m> ok, buenos noches srs y srtas 
            
-
            [22:57] <jrand0m> agenda: 
            
-
            [22:57] <jrand0m> 0) welcome 
            
-
            [22:57] <jrand0m> 1) cvs 
            
-
            [22:57] <jrand0m> 4) naming service 
            
-
            [22:58] <co> You forgot 5) questions.
            
-
            [22:58] <jrand0m> 3) dev status 
            
-
            [22:58] <jrand0m> 2) spec questions? 
            
-
            [22:58] <jrand0m> 5) other questions? 
            
-
            [22:58] <jrand0m> oh, shit, I forgot to reorder those.  ok.  they're numbered incorrectly :)  0 == 0, 1 == 1, 4 ==2, 3 == 3, 2 == 4, 5 == 5 
            
-
            [22:59] <jrand0m> lets see if I can keep that straight as we go... 
            
-
            [22:59] <jrand0m> ok, 0) welcome 
            
-
            [22:59] <shardy> yay for permutation groups!
            
-
            [22:59] <jrand0m> welcome to meeting 57 
            
-
            [22:59] <jrand0m> yeah, they're all just symbols anyway 
            
-
            [22:59] <w0rmus> sweet whatup ;0
            
-
            [23:00] <w0rmus> I'll help comprise peanut gallery
            
-
            [23:00] <jrand0m> 1) cvs is still down, after 10+ days.  we're finding a new host. 
            
-
            [23:00] <jrand0m> sf.net sucks, and I have no reason to believe gnu's nongnu is better. 
            
-
            [23:00] <co> jrand0m: Why not make that host have the alias "cvs.invisiblenet.net"?
            
-
            [23:00] <jrand0m> nop is leading the charge on finding the new host. 
            
-
            [23:01] <jrand0m> sure co, once we get the server 
            
-
            [23:01] <shardy> what do you need for a host?
            
-
            [23:01] <jrand0m> shardy> reliable net connection, ssh/cvs access.  and some disk space 
            
-
            [23:01] <shardy> do you have something lined up?
            
-
            [23:01] <shardy> because if not. I may be able to assist.
            
-
            [23:02] <jrand0m> awesome!  I don't know what nop has lined up, but I'll have him check in with you (unless he's here now?) 
            
-
            [23:02] * w0rmus taps nop
            
-
            [23:03] <shardy> I've got 1.1 business sdsl. I'd need to find a machine. but as long as you're not using uber amounts of bandwidth I could probably host the server.
            
-
            [23:03] <shardy> how much disk space would you need?
            
-
            [23:03] <jrand0m> the repository currently comprises ~ 6Mb.  so probably 50M would handle growth for a good while 
            
-
            [23:04] <shardy> oh. pfft. that's nothing.
            
-
            [23:04] <shardy> and the machine wouldn't need to be super fast?
            
-
            [23:04] <shardy> you wouldn't be doing big compile jobs on it?
            
-
            [23:04] <jrand0m> naw, a 286 would probably do it. 
            
-
            [23:04] <jrand0m> no, strictly cvs checking / checkout  
            
-
            [23:04] <jrand0m> (well, and diff, and log, etc ;) 
            
-
            [23:05] <jrand0m> "we're java, we don't need compile farms" </fark> 
            
-
            [23:05] *** Signoff: cohesion (class)
            
-
            [23:05] <w0rmus> do people concerned with anonymity access CVS using something like JAP?  I've never used CVS
            
-
            [23:05] <jrand0m> w0rmus> I use cvs through a private series of ssh proxies 
            
-
            [23:05] <co> jrand0m: Keep in mind that a C or C++ implementation may be likely in the future.
            
-
            [23:06] <mihi> jap does not allow cvs access AFAIK :(
            
-
            [23:06] <w0rmus> ssh tunnelling
            
-
            [23:06] <shardy> let me see what I can do. someone said they were going to give me another drive... if I can get a disk I have a machine I can toss up.
            
-
            [23:06] <jrand0m> oh, of course co.  I just don't expect we can require a cvs repository to necessarily be a compile farm as well. 
            
-
            [23:07] <jrand0m> awesome shardy.  there's anything we can do, just say the word. 
            
-
            [23:07] <co> jrand0m: You are right. They should be separate.
            
-
            [23:07] <shardy> will do. let me scrounge for a drive, I should be able to get one, and if I do I'd be happy to host the cvs for everyone.
            
-
            [23:07] <jrand0m> shardy++ 
            
-
            [23:07] <w0rmus> yay ;0
            
-
            [23:07] <jrand0m> ok, 4) naming service 
            
-
            [23:08] <jrand0m> co, how goes?   
            
-
            [23:08] <co> I am still writing, but would like to say a few words about it.
            
-
            [23:08] <co> First, to address a question from thecrypto during the last meeting, the NS does not provide notification of someone's being online.
            
-
            [23:09] <co> It merely says that a person can be contacted via certain methods, such as AIM.
            
-
            [23:09] <co> Second, the client side.
            
-
            [23:09] <co> There will be an API which programs can use to make queries to naming servers.
            
-
            [23:10] <co> The underlying mechanism will read a configuration file of which servers to query, will use the I2P network to obtain the results, and will pass the results back to the caller.
            
-
            [23:11] <co> The underlying mechanism will also read the destination mechanism for the local router to contact from a file.
            
-
            [23:11] <jrand0m> the destination mechanism? 
            
-
            [23:11] <co> I'm sorry, the destination address.
            
-
            [23:11] <jrand0m> ah 'k 
            
-
            [23:12] <co> That is all at this time.
            
-
            [23:12] <jrand0m> cool 
            
-
            [23:12] <w0rmus> I agree
            
-
            [23:12] <w0rmus> ;)
            
-
            [23:12] <jrand0m> any ballpark ideas on timelines for various milestones?   
            
-
            [23:13] <jrand0m> obviously nothing anyone could hold you to, of course, just wondering 
            
-
            [23:13] <co> Let's say end of the week for finishing the specification and publishing it and the API.
            
-
            [23:14] * mariesofie arrives late
            
-
            [23:14] <jrand0m> ah nice co 
            
-
            [23:14] <co> Then, I will start implementing it. I am not certain how long that will take, though.
            
-
            [23:14] <jrand0m> understandable 
            
-
            [23:15] <jrand0m> anyone else have any naming service questions/thoughts? 
            
-
            [23:15] <jrand0m> ok, 3) dev status 
            
-
            [23:16] <jrand0m> dev goes well. 
            
-
            [23:16] <jrand0m> the java side is up to spec and implements all I2CP and I2NP messages and structures 
            
-
            [23:17] <jrand0m> the java architecture itself is functional and I'm going to continue stubbing out the various subsystems 
            
-
            [23:17] <co> Have you tested it?
            
-
            [23:17] <jrand0m> the messages & structures?  yes via the TestData harness in net.invisiblenet.i2p.data.test 
            
-
            [23:17] <co> I mean connecting two different computers with I2P.
            
-
            [23:18] <jrand0m> oh, no, thats requires the full implementation of the communication subsystem 
            
-
            [23:18] <co> I see.
            
-
            [23:18] <jrand0m> first I'm building the various subsystems to operate in test mode, then implementing the various subsystems so they can operate in isolation 
            
-
            [23:19] <jrand0m> we're probably 2 weeks off from a client sending a message to a client on a different router 
            
-
            [23:19] * mariesofie cheers
            
-
            [23:20] <jrand0m> there's still a lot of work to be done after that before the alpha, but thats progress  
            
-
            [23:21] <jrand0m> the datastrucutres and i2np specs need about a dozen small modifications that I've been accumulating during the implementation to address things overlooked.  e.g. "datastructures p11, TunnelSigningPublic/PrivateKey should contain SIGNING Public/Private keys" and "i2np p15, TunnelCreateStatus - add hash of the replying RouterIdentity" 
            
-
            [23:21] <shardy> man. i really need to read up on the specs.
            
-
            [23:22] <jrand0m> well, they'll soon be hosted on your machine so it'll be easy :) 
            
-
            [23:22] <w0rmus> haha
            
-
            [23:22] <w0rmus> I have not finished specs either
            
-
            [23:23] <mariesofie> i printed the specs, read them so many times it got worn out and i had to print out another copy
            
-
            [23:23] <jrand0m> from discussions I've had with various people, I've found the specs aren't that great at conveying how the thing actually works.  they cover the fuzzy stuff and the nitty gritty, but not why the nitty gritty meets the why 
            
-
            [23:23] <w0rmus> heh
            
-
            [23:23] <jrand0m> rofl mariesofie 
            
-
            [23:23] <jrand0m> ok, thats it for 3) dev status 
            
-
            [23:24] <jrand0m> now for 2) spec questions 
            
-
            [23:24] <w0rmus> I suppose I'll read them instead of stupid calculus
            
-
            [23:24] <co> I am thinking a little bit into the future.
            
-
            [23:24] <co> The python and C or C++ implementations will need to have message data readable by the Java implementation.
            
-
            [23:24] *** Signoff: mihi (EOF From client)
            
-
            [23:25] <jrand0m> correct co 
            
-
            [23:25] <co> How will you accomplish that?
            
-
            [23:25] <jrand0m> the datastructures spec specifically defines the byte layouts 
            
-
            [23:25] <jrand0m> and everything is big endian and all numbers are unsigned 
            
-
            [23:25] <mariesofie> what level of technical knowledge are you targetting the specs for? anyone with decent comp. knowledge? college level CS engineer students?
            
-
            [23:25] <co> Oh, all right.
            
-
            [23:25] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
            
-
            [23:26] <mariesofie> i.e. who is the target audience?
            
-
            [23:26] *** mihi_ is now known as mihi
            
-
            [23:26] <jrand0m> mariesofie> well, those specs were really targeted haphazardly.  i2p_philosophy was the "ok, wtf is this all about", but the rest of the specs were targeted towards people interested in actually implementing the system 
            
-
            [23:26] <jrand0m> we really really need some docs that go in the middle 
            
-
            [23:27] <mariesofie> i see
            
-
            [23:27] <mariesofie> I found the API docs are very easy to understand and useful, but ironically I still get mixed up when reading the I2NP specs trying to understand the core architecture
            
-
            [23:28] <mariesofie> maybe thats reflective on me more than the documentation :)
            
-
            [23:28] <jrand0m> heh geek :) 
            
-
            [23:29] <jrand0m> ok, any other questions on the specs?  lets move on to 5) other questions  
            
-
            [23:29] <jrand0m> anyone have any other questions?  this is our last bullet point on the meeting agenda 
            
-
            [23:30] <w0rmus> I wonder where thecrypto is with achat
            
-
            [23:30] <jrand0m> ah, thecrypto is offline for the next three weeks or so 
            
-
            [23:30] <mihi> what happens with peer review?
            
-
            [23:30] <w0rmus> or atalk
            
-
            [23:30] <w0rmus> wow
            
-
            [23:30] <mihi> is anyone reviewing it?
            
-
            [23:30] <mariesofie> i thought thecrypto has 2hrs per day
            
-
            [23:31] <w0rmus> and I can't even see the codes he has :(
            
-
            [23:31] <jrand0m> mihi> reviews have been sent to various people for review and as feedback comes it will be addressed. 
            
-
            [23:31] <jrand0m> w0rmus> do you have any questions on ATalk? 
            
-
            [23:32] <shardy> I will be reviewing it as soon as I have time :)
            
-
            [23:32] <mihi> i meant, did any feedback come till nowß
            
-
            [23:32] <w0rmus> I suppose not
            
-
            [23:32] <mihi> s/nowß/now?/
            
-
            [23:32] <jrand0m> mihi> largely in the form of discussions and clarifications 
            
-
            [23:32] <jrand0m> awesome shardy :) 
            
-
            [23:33] <Brownspider> hapy birthday google
            
-
            [23:33] <jrand0m> mariesofie> right, but thats not even enough time for him to d/l the java lang docs to continue dev :/ 
            
-
            [23:33] <w0rmus> ahaha wtf
            
-
            [23:35] <jrand0m> ok, any other questions / thoughts? 
            
-
            [23:35] <w0rmus> I guess I should mention that I've never coded outside of school
            
-
            [23:35] <w0rmus> but I gotta start somewhere anyways
            
-
            [23:35] <jrand0m> now's a good time to start :) 
            
-
            [23:35] <jrand0m> word 
            
-
            [23:35] <w0rmus> ;0
            
-
            [23:35] <mariesofie> i have questions on the api, but not yet, in a day or two when i can try it out some more
            
-
            [23:35] <w0rmus> I've taken 2 years of java or so
            
-
            [23:36] <jrand0m> ok cool mariesofie, just bounce a msg to the list or bounce me a message here whenever 
            
-
            [23:37] <co> mariesofie: Have you read the discussion on the iip-dev mailing list?
            
-
            [23:37] <w0rmus> where is it archived?
            
-
            [23:37] <jrand0m> http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel 
            
-
            [23:37] <jrand0m> (fairly low traffic atm) 
            
-
            [23:38] <Brownspider> jrand0m wants you code something that can not logicly exist, to tear the world usunder, to end the reign of god.
            
-
            [23:38] <shardy> my services are still offered if you need any crypto cores or such written or debugged. 
            
-
            [23:39] *** M123456789 (~no@anon.iip) has joined channel #iip-dev
            
-
            [23:39] <co> Brownspider: huh?
            
-
            [23:39] <Brownspider> co, it was on his freesite, nevermind
            
-
            [23:40] <jrand0m> great shardy, I have a feeling we're going to need some once the routers get up and running, and especially when we get the C/Python APIs back up to spec 
            
-
            [23:40] <mariesofie> co> i've only read back to about issue #52 or so
            
-
            [23:42] <jrand0m> ok.  any last words (as I eye the *baf*er...) 
            
-
            [23:43] *** mihi_backup_ (~none@anon.iip) has joined channel #iip-dev
            
-
            [23:43] *** Signoff: mihi_backup (EOF From client)
            
-
            [23:43] *** mihi_backup_ is now known as mihi_backup
            
-
            [23:43] <jrand0m> ok great.  next week, same bat time, same bat place. 
            
-
            [23:44] * jrand0m *baf*s the meeting to an end
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting58.html b/www.i2p2/pages/meeting58.html
deleted file mode 100644
index 9d37ae8b..00000000
--- a/www.i2p2/pages/meeting58.html
+++ /dev/null
@@ -1,314 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 58{% endblock %}
-{% block content %}
            
-
            [22:53] <jrand0m> 0) welcome 
            
-
            [22:54] <jrand0m> 1) apps: 
            
-
            [22:54] <jrand0m> 1.1) IM 
            
-
            [22:54] <jrand0m> 1.2) NS  
            
-
            [22:54] <jrand0m> 2) dev status: 
            
-
            [22:54] <jrand0m> 2.1) subsystems 
            
-
            [22:54] <jrand0m> 2.2) encryption key persistence 
            
-
            [22:54] <jrand0m> 2.3) todo 
            
-
            [22:54] <jrand0m> 3) spec stuff 
            
-
            [22:54] <jrand0m> 3.1) mods 
            
-
            [22:54] <jrand0m> 4) administravia: 
            
-
            [22:54] <jrand0m> 4.1) anon cvs 
            
-
            [22:54] <jrand0m> 5) ? 
            
-
            [22:55] <jrand0m> ok, 0) welcome  
            
-
            [22:55] <jrand0m> welcome to meeting 58 
            
-
            [22:55] <thecrypto> that all
            
-
            [22:55] <jrand0m> si sr, unless anyone else has things to add? 
            
-
            [22:55] * nop notices jrand0m is object oriented with his numbering :)
            
-
            [22:56] <nop> 3.1.2.2.4.5.8() ;)
            
-
            [22:56] <jrand0m> hey, they could be structs ;) 
            
-
            [22:56] <nop> haha
            
-
            [22:56] <nop> that is definitely true
            
-
            [22:56] <jrand0m> ok, 1.1) IM.  thecrypto? 
            
-
            [22:56] <nop> although
            
-
            [22:56] <nop> 2 has inheritance
            
-
            [22:57] <nop> ;)
            
-
            [22:57] <jrand0m> heh 
            
-
            [22:57] <nop> nevermind me
            
-
            [22:57] <nop> ok
            
-
            [22:57] <nop> sorry
            
-
            [22:57] <nop> continue
            
-
            [22:57] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
            
-
            [22:57] <thecrypto> okay, right now i'm uploading some basic specs for IM
            
-
            [22:58] <thecrypto> (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw for oowriter
            
-
            [22:58] <thecrypto> and i'm working on uploading the pdf
            
-
            [22:58] <nop> if you want I can put on i2p site
            
-
            [22:59] <thecrypto> give me a second
            
-
            [22:59] <thecrypto> sure
            
-
            [22:59] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev
            
-
            [22:59] <jrand0m> do you want to put that into i2p/apps/IM/doc/ ? 
            
-
            [22:59] *** mihi_ is now known as mihi_backup
            
-
            [23:00] <nop> I can
            
-
            [23:00] <nop> yes
            
-
            [23:00] <jrand0m> I meant in cvs :) 
            
-
            [23:00] <thecrypto> i can do that too
            
-
            [23:00] <jrand0m> (but on the web is good too) 
            
-
            [23:00] <nop> oh
            
-
            [23:00] <nop> haha
            
-
            [23:00] <thecrypto> (Link: http://www.thecrypto.org/i2pim.pdf)http://www.thecrypto.org/i2pim.pdf
            
-
            [23:01] <MrEcho> "the file is damaged and could not be repaired"  AR error
            
-
            [23:01] <thecrypto> try again
            
-
            [23:01] * jrand0m loaded it fine
            
-
            [23:01] <co> MrEcho: The PDF file?
            
-
            [23:01] <jrand0m> (the sxw) 
            
-
            [23:01] <thecrypto> only partially uploaded at that time
            
-
            [23:01] <MrEcho> now it works
            
-
            [23:01] <MrEcho> hehe
            
-
            [23:02] <thecrypto> basicall i just put in the presence stuff, online offline messages, and a message message
            
-
            [23:02] <thecrypto> i shameless ripped some sections from the I2NP documenty
            
-
            [23:02] <thecrypto> :)
            
-
            [23:02] <jrand0m> heh I thought some of it looked familiar :) 
            
-
            [23:02] <thecrypto> i'm also working on uploading the UI i
            
-
            [23:02] <thecrypto> i've been working on
            
-
            [23:03] <thecrypto> jrand0m: do i need to create the dirs apps/IM/doc
            
-
            [23:03] <jrand0m> yes, and cvs add them individually 
            
-
            [23:03] <thecrypto> -kb?
            
-
            [23:03] <jrand0m> yes 
            
-
            [23:03] <co> thecrypto: I believe apps/ is there now.
            
-
            [23:04] <jrand0m> whats a presence? 
            
-
            [23:05] <thecrypto> let me run update
            
-
            [23:05] <thecrypto> but it's getting in there
            
-
            [23:05] *** Signoff: shardy (Ping timeout)
            
-
            [23:05] <thecrypto> i'm just saying rip apart the specs
            
-
            [23:05] <thecrypto> and the UI will be in there soon as well
            
-
            [23:05] <thecrypto> and if you have anything that needs to be clarified then anonymail, e-mail, anything me and i'll fix it
            
-
            [23:05] <mrflibble> did i miss the meeting?
            
-
            [23:05] *** shardy (~shardy@anon.iip) has joined channel #iip-dev
            
-
            [23:05] <co> thecrypto: You might want to announce it on the e-mail list, as well, with a link to the documents.
            
-
            [23:05] <thecrypto> i thought i put that in there?
            
-
            [23:05] <jrand0m> nope still on the first item point mrflibble 
            
-
            [23:05] <co> mrflibble: Meeting is in progress.
            
-
            [23:05] <mrflibble> oh sorry, just couldnt see "logger"
            
-
            [23:06] <jrand0m> thecrypto> you state that its a destination, but is that the destination at which to send messages?  how do offline messages work? 
            
-
            [23:06] <mihi> no mids here, so no logger ;)
            
-
            [23:06] <mrflibble> k
            
-
            [23:06] * mrflibble goes back to lurking
            
-
            [23:06] <jrand0m> oh wait, these are just presence notifications, sorry 
            
-
            [23:06] <mihi> how can one subscribe to a presence?
            
-
            [23:06] <thecrypto> jrand0m: no offline messages
            
-
            [23:07] <thecrypto> basically
            
-
            [23:07] <thecrypto> the presence just wraps a destination and a name together
            
-
            [23:07] <thecrypto> to make things easy
            
-
            [23:08] <thecrypto> so if we want to move onto NS we can do that, and we can come back to this later?
            
-
            [23:09] <jrand0m> 'k cool 
            
-
            [23:09] <thecrypto> and you can still message me questions
            
-
            [23:09] <jrand0m> actually, one quick question 
            
-
            [23:09] <thecrypto> shoot
            
-
            [23:09] <jrand0m> so the IM is strictly text only? 
            
-
            [23:10] <thecrypto> with this basic one yes, but i will be adding file support in
            
-
            [23:10] <jrand0m> coo' 
            
-
            [23:10] <thecrypto> i just want the beginnings of the system taken care of and build on it
            
-
            [23:10] <jrand0m> (iterative and incremental)++ 
            
-
            [23:11] <jrand0m> ok great.  I'll go through this further and other people should too... for now, moving on to 1.2) NS.  co? 
            
-
            [23:11] <co> Version 1.1 (final) of the naming service specification was released earlier today.
            
-
            [23:12] <jrand0m> (and there was much rejoicing) 
            
-
            [23:12] <co> Basically, I finished the sections on the data structures and network messages that the program needs.
            
-
            [23:12] <co> I will be releasing the client API on Thursday.
            
-
            [23:12] <co> And will begin implementing the NS application.
            
-
            [23:12] <jrand0m> great 
            
-
            [23:13] <co> One idea that has changed is what the CA does when entities register with it.
            
-
            [23:13] <thecrypto> co: how will you be implementing it?
            
-
            [23:13] <thecrypto> co: the name server or the client?
            
-
            [23:14] <co> thecrypto: Well, first I will implement the data structures necessary.
            
-
            [23:14] <co> Then, the client, then the server and CA components.
            
-
            [23:14] <thecrypto> okay
            
-
            [23:15] <co> As I was saying, I now would like the CA to issue a certificate to newly registered entities.
            
-
            [23:15] <co> They will present this certificate to naming servers when modifying their records.
            
-
            [23:15] <co> I have not specified what the certificate contains in this version; that will go into the next version of the specification.
            
-
            [23:16] <co> Does this strike anyone as a bad idea?
            
-
            [23:16] <jrand0m> hmm.  wouldn't it be simpler / safer to just have the client use a public key / private key? 
            
-
            [23:16] <jrand0m> aka during register, provide a public key for updates and sign the registration, and whenever you want to update again, sign an update 
            
-
            [23:16] <jrand0m> (so that hte CA never gets the private key) 
            
-
            [23:17] <thecrypto> Sidenote: all the I2PIM stuff is now committed to the cvs respository
            
-
            [23:17] <jrand0m> great 
            
-
            [23:17] <co> It may be simpler to do just that. I will re-think this issue. Thank you for the comment.
            
-
            [23:17] <co> That is all I have to discuss for the naming service at this time, if you have no other questions.
            
-
            [23:18] <jrand0m> its lookin good, I haven't gone through the 1.1 yet but I'll email if I come across something 
            
-
            [23:19] <co> OK. Next topic?
            
-
            [23:19] <jrand0m> ok, 2.1) dev status for subsystems. 
            
-
            [23:19] *** w0rmus (o0o@anon.iip) has joined channel #iip-dev
            
-
            [23:20] <jrand0m> transport subsystem is good 'nuff to move forward.  peer management subsystem is stubbed with stupid algorithms but functional.  network db, tunnel management, and stats management subsystems are still pending.  client subsystem will be trivial (just reusing the SDK local only router) 
            
-
            [23:21] <co> What do you mean by stupid algorithms?
            
-
            [23:21] <w0rmus> not fast?
            
-
            [23:21] <jrand0m> eh, the peer management subsystem isn't keeping track of peer performance, its just returning random peers. 
            
-
            [23:22] <jrand0m> the algorithm will be updated and tuned as things progress to more adequately provide peer selection 
            
-
            [23:22] <jrand0m> current task on my plate is building and handling garlic messages, which is a PITA. 
            
-
            [23:23] <jrand0m> but workable, just annoying  
            
-
            [23:23] <jrand0m> that actually leads into 2.2) encryption key persistence. 
            
-
            [23:24] <jrand0m> garlic messages use ElG+AES encryption to wrap the layers of the cloves 
            
-
            [23:24] <jrand0m> and private keys are used in other places (transport, client management) 
            
-
            [23:25] *** Signoff: thecrypto (Ping timeout)
            
-
            [23:25] <jrand0m> keeping private and session keys always in memory and never on disk is ideal, but sucks for times when the router goes down (either intentionally or by fault) 
            
-
            [23:26] <jrand0m> does anyone have any thoughts for whether we should 1) never write the keys to disk and risk excessive unnecessary message loss (since they won't be decryptable) 2) encrypt them before writing to disk or 3) just write them to disk plain? 
            
-
            [23:26] <co> Option 2.
            
-
            [23:27] <nop> jrand0m option 2, or do what we said before
            
-
            [23:27] <nop> we must trust localhost 
            
-
            [23:27] *** Signoff: cohesion (class)
            
-
            [23:27] <nop> we assume localhost is not compromised
            
-
            [23:27] <jrand0m> the kooky thing about option 2 is that it either the user will have to enter a pass phrase to start the router, or the session key will be knowable 
            
-
            [23:27] <jrand0m> good point nop. 
            
-
            [23:28] <nop> again we are a transport, we can't worry about that as much, that can be modified on client end, or we could give them options
            
-
            [23:28] <nop> depending on paranoia level
            
-
            [23:28] <nop> security vs convenience measure
            
-
            [23:29] <co> Then I propose having 3 by default, and giving the user the option to use 2.
            
-
            [23:29] <nop> exactly
            
-
            [23:29] <jrand0m> right.  ok, the good thing is that people can (and should!) take the router code and modify it for that tradeoff - a "tinfoil I2P router" and a "jane sixpack I2P router" 
            
-
            [23:29] <jrand0m> ok, cool, I'll just go with the simple 3) for now then 
            
-
            [23:30] <jrand0m> ok 2.3) todo 
            
-
            [23:30] * co would like to revisit the NS topic at the end of the meeting.
            
-
            [23:30] * nop needs to finish reading the NS email
            
-
            [23:30] <jrand0m> 'k, you're item #5 now 
            
-
            [23:30] <co> I can wait until the end.
            
-
            [23:31] <jrand0m> mihi put together some tests to point out some bugs in the SDK impl.  some fixed already, some not.  fixing them is on the todo :) 
            
-
            [23:32] <jrand0m> also, there have been about a dozen changes to various specs.  once I get time I'll update the docs and push 'em out, though I may just put up an errata page on the wiki in the meantime 
            
-
            [23:33] <nop> word
            
-
            [23:34] <jrand0m> other todo's... um, I fixed the "Wrong Size generating key" thing this morning plus a few random bugs 
            
-
            [23:34] <jrand0m> ok, thats it for dev status.  3) spec stuff 
            
-
            [23:35] <jrand0m> 3.1) see todo re: mods.  there have been mostly typographical changes, I came across a slightly larger one today when implementing the garlics.  still no prob, just requires moving around some data structures and doing some fancy footwork with the encryption.  I'll get that in the errata. 
            
-
            [23:35] <jrand0m> 3.2) [I know, this one wasn't on the agenda, but here it is anyway] spec questions 
            
-
            [23:35] <shardy> (brb, I'm still lurking if you need me)
            
-
            [23:35] <jrand0m> anyone have any questions on any of the specs? 
            
-
            [23:35] <jrand0m> cool shardy 
            
-
            [23:36] <co> jrand0m: Please tell us again which spec is in which document.
            
-
            [23:37] <jrand0m> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs has 'em mapped out 
            
-
            [23:37] <co> I will look at it.
            
-
            [23:38] <jrand0m> (looking at that it reminds me I need to document the secure reliable UDP transport.  yet another todo...) 
            
-
            [23:39] <jrand0m> there have been some questions from various people wrt what specs to look at - basically, unless you want to know how the routers work (or you want to help implement them), you won't need to read the I2NP spec.  I2CP and the I2CP section of the data structures is good enough 
            
-
            [23:40] <nop> jrand0m
            
-
            [23:40] <jrand0m> si sr? 
            
-
            [23:41] <nop> do you mean actual UDP as in UDP packets 
            
-
            [23:41] <nop> or UDP as in a general UDP protocol
            
-
            [23:41] <jrand0m> yes, UDP as in UDP packets 
            
-
            [23:41] <nop> for I2P
            
-
            [23:41] *** thecrypt1 (~thecrypto@anon.iip) has joined channel #iip-dev
            
-
            [23:41] *** thecrypt1 is now known as thecrypto
            
-
            [23:41] <jrand0m> i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp for the implementation 
            
-
            [23:42] <thecrypto> back
            
-
            [23:42] <jrand0m> wb 
            
-
            [23:42] <thecrypto> anyone want to send me what happened while i was gone?
            
-
            [23:43] <jrand0m> the UDP impl is a pretty simple one - it does a DH exchange and messages are split into 1K packets and AES256 encrypted with the generated key 
            
-
            [23:43] <jrand0m> rekeying is supported though not automatic atm 
            
-
            [23:43] <jrand0m> ACKs are sent back in bundles (aka "I received all packets for message 42 up through packet 18 but not 3 or 7") 
            
-
            [23:44] <jrand0m> (and the practical reason why I went with the UDP impl before the TCP impl is UDP gives 'free' asynchronous IO with nearly 0 overhead) 
            
-
            [23:45] <nop> of course
            
-
            [23:45] <jrand0m> there are two things left to do in that udp impl - station to station it for MITMs and add a packet for "oh shit, I forgot the session key" 
            
-
            [23:45] <nop> good
            
-
            [23:46] <jrand0m> after the UDP transport the next one I want to implement is the polling HTTP - so we will have support for both the common user (UDP) and the firewalled / nat'ed / proxied user (polling http) 
            
-
            [23:47] <jrand0m> ok, so, yeah, that needs to get doc'ed up into a spec :) 
            
-
            [23:48] * jrand0m !thwaps self for coding before specing
            
-
            [23:48] <thecrypto> coding before specing helps me
            
-
            [23:48] <jrand0m> yeah, it works best iteratively 
            
-
            [23:48] <jrand0m> (as we're finding problems with the specs by implementing them, etc) 
            
-
            [23:49] <jrand0m> ok, thats 3) specs.  4) administravia 
            
-
            [23:49] <jrand0m> 4.1) anon cvs.  thecrypto?  :) 
            
-
            [23:49] <thecrypto> just in the nick of time
            
-
            [23:49] <thecrypto> well, i'm looking into it, i think 2401 is currently blocked
            
-
            [23:49] <jrand0m> can you cvs -d :pserver: locally? 
            
-
            [23:49] <thecrypto> and there might be some inetd stuff to do as well thanks jrandom
            
-
            [23:50] <jrand0m> ah coo' 
            
-
            [23:50] <thecrypto> let me test that i forgot you cood do that :)
            
-
            [23:51] <thecrypto> would it just be cvs -d :pserver: ?
            
-
            [23:51] <jrand0m> cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p 
            
-
            [23:52] <jrand0m> also, it'd be great if we could get a bugzilla on there too 
            
-
            [23:52] <thecrypto> acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused
            
-
            [23:52] <jrand0m> 'k, after adding the inetd.conf line and kill -HUP identd? 
            
-
            [23:52] <thecrypto> let me try that inet line and i'll get back to you
            
-
            [23:52] <jrand0m> er, inetd :) 
            
-
            [23:52] <jrand0m> 'k cool 
            
-
            [23:53] <thecrypto> does the pserver go on the same line?
            
-
            [23:53] <jrand0m> yes, thats all on one line 
            
-
            [23:55] <jrand0m> ok, thats it for administravia, at least that I can think of 
            
-
            [23:55] <jrand0m> 5a) co, you're up 
            
-
            [23:56] <co> When two people want to register the same entity name, the second is refused.
            
-
            [23:56] <co> But if we use a signature-based approach,
            
-
            [23:56] <co> the person who was refused could send a message to the naming server
            
-
            [23:56] <co> anyway, telling it to modify the record.
            
-
            [23:56] <co> There are two possibilities:
            
-
            [23:57] <co> 1) CA sends the naming server a copy of the public key for the entity that was approved.
            
-
            [23:57] <co> 2) CA sends the person who is registering a name a certificate, signed by its private key. The naming server will have the CA's public key to verify it.
            
-
            [23:58] <co> If a malicious user tells the naming server to modify a certain record, the lack of a certificate would prevent the modification.
            
-
            [23:58] <co> That is what I was thinking.
            
-
            [23:59] <jrand0m> but in that case the CA knows the key - asym crypto would mean the CA only ever knows the public key, plus the CA would never want to or need to give that public key out to anyone - its just for the authentic updater to sign against when requesting an update 
            
-
            [00:00] <jrand0m> what you're describing sounds more like symmetric crypto - just using a passphrase, eseentially 
            
-
            [00:00] <thecrypto> cvs is screwing with me!
            
-
            [00:00] <jrand0m> (where the certificate is the shared secret between CAs and the authentic owner of the nym) 
            
-
            [00:00] *** mrsc (~efgsdf@anon.iip) has joined channel #iip-dev
            
-
            [00:01] <jrand0m> whats up thecrypto? 
            
-
            [00:01] <thecrypto> i added the user anonymous with blank password added them to readers and into the cvsgroup and i get cvs login: authorization failed: server localhost rejected access to /home/cvsgroup/cvsroot for user anonymous
            
-
            [00:01] <co> jrand0m: Good point. Let's say that this part of the specification is not finalized, and I will think about it some more.
            
-
            [00:01] <jrand0m> coo' 
            
-
            [00:01] *** LeerokLacerta (~leerok@anon.iip) has joined channel #iip-dev
            
-
            [00:02] <LeerokLacerta> Konnichiwa.
            
-
            [00:02] <jrand0m> hmm thecrypto, I don't think you want an anonymous OS user 
            
-
            [00:02] <jrand0m> heya LeerokLacerta 
            
-
            [00:02] <LeerokLacerta> Hello, jrand0m.
            
-
            [00:02] <thecrypto> well i stuck on a password and it works now
            
-
            [00:03] <co> jrand0m: And if you have any more suggestions after reading the spec, send them to me.
            
-
            [00:03] <jrand0m> shall do co 
            
-
            [00:03] <jrand0m> cool thecrypto.. is /bin/false their shell? 
            
-
            [00:03] <thecrypto> now i just have to find that section in the cvs manual about how to make a user
            
-
            -> *thecrypto* whats the pw?
            
-
            [00:04] <thecrypto> now it is
            
-
            [00:05] <jrand0m> ok, we can work through this after the meeting. 
            
-
            [00:05] <jrand0m> ok, last point on the agenda: 5b) ? 
            
-
            [00:05] <jrand0m> any questions / thoughts / concerns? 
            
-
            [00:05] <thecrypto> just check out the IM app
            
-
            [00:06] <thecrypto> right now all it does is make a tree but it shows you what it's starting to look like
            
-
            [00:06] <LeerokLacerta> No SOCKS?
            
-
            [00:06] <thecrypto> ohh yeah that's what i forgot
            
-
            [00:06] <jrand0m> ah cool thecrypto 
            
-
            [00:06] <jrand0m> SOCKS?  as in, the proxy protocol? 
            
-
            [00:06] <thecrypto> anyone here good at making icons?
            
-
            [00:06] <LeerokLacerta> Yup.
            
-
            [00:06] <LeerokLacerta> The answer for all the times I've asked as been "No".
            
-
            [00:07] <jrand0m> ah.  yes, we're definitely going to want a socks proxy, but no one is working on it atm. 
            
-
            [00:07] <LeerokLacerta> Hmm.
            
-
            [00:07] <jrand0m> thats going to be one of the apps we'll want by 1.0 public, so that people can browse i2p based sites, as well as so that people can browse the normal web anonymously 
            
-
            [00:07] <mihi> there are enough socks proxies available for free, i'd say ;)
            
-
            [00:08] <jrand0m> exactly, we just need to integrate 'em 
            
-
            [00:08] <mihi> but i don't know any in java.
            
-
            [00:08] <jrand0m> the JAP client app might work well, I don't know if its GPL though 
            
-
            [00:08] <mihi> the jap client does not contain a proxy.
            
-
            [00:08] <thecrypto> well I need some icons for the I2PIM project
            
-
            [00:09] <thecrypto> Something to represent online offline and a group of people
            
-
            [00:09] <mihi> the only proxy is a http/ftp proxy and that is in the last mix.
            
-
            [00:10] <mihi> like with iip - isproxy does not know any IRC protocol.
            
-
            [00:10] <jrand0m> well, thats the outbounds side - for i2p based web sites, we'll need something to accept proxy requests from local browsers, do the lookup of the dest, and send the messages to the appropriate dest 
            
-
            [00:10] <thecrypto> anyone interested?
            
-
            [00:11] <co> thecrypto: Could you take the icons from the GPL'd gaim project?
            
-
            [00:11] * jrand0m makes horrificly boring graphics in ms paint
            
-
            [00:11] <co> Since it's under GPL, and so is this, unless I am mistaken.
            
-
            [00:11] <thecrypto> yeah, i could
            
-
            [00:11] <jrand0m> if I2PIM uses the sdk's client libs, I2PIM is definitely GPL :) 
            
-
            [00:12] <thecrypto> ahh the wonderful GPL
            
-
            [00:12] <jrand0m> LeerokLacerta> any particular reason you ask, or just wanting to prod us to do it? ;) 
            
-
            [00:13] <thecrypto> the problem with the gaim ones is they are from the IM apps they are using
            
-
            [00:14] <thecrypto> so if someone could make the I2PIM icon that would just be great
            
-
            [00:15] * jrand0m thinks we'll have lots of scribbled paint-based images for the time being...
            
-
            [00:16] <jrand0m> ok, anyone have any other thoughts / questions / commnets? 
            
-
            [00:16] <nop> I have commnets
            
-
            [00:16] <jrand0m> (other than "wtf is a commnet") 
            
-
            [00:16] <jrand0m> is that contagious? 
            
-
            [00:16] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev
            
-
            [00:16] <mrflibble> lol
            
-
            [00:17] <jrand0m> 'k, well, if not, that about wraps up the meetin', no more agenda items left 
            
-
            [00:17] <nixonite> did i miss the meeting?
            
-
            [00:17] <jrand0m> yup, 9p GMT 
            
-
            [00:17] <jrand0m> well, technically you made it for the end :) 
            
-
            [00:17] <nixonite> oh
            
-
            [00:18] <co> nop: Let's hear them.
            
-
            [00:18] <thecrypto> so what are the comments
            
-
            [00:18] * jrand0m thought nop was just making fun of my typo, but if he has comments, let 'er rip bro
            
-
            [00:20] <thecrypto> anon cvs is still not liking me, more work tommorow
            
-
            [00:20] <jrand0m> gimmie root and I'll get 'er up 
            
-
            [00:21] <thecrypto> talk to nop about that one
            
-
            [00:21] <jrand0m> heh 'k 
            
-
            [00:22] <jrand0m> ok, as nop seems to have been dragged back into work... 
            
-
            [00:22] <jrand0m> nop, and anyone else, really> if you have any comments /questions / concerns, either let us know or post on the mailing list (or even into the wiki) 
            
-
            [00:23] * jrand0m loads up and *baf*s the meeting to an end.
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting59.html b/www.i2p2/pages/meeting59.html
deleted file mode 100644
index 275c9e21..00000000
--- a/www.i2p2/pages/meeting59.html
+++ /dev/null
@@ -1,734 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Meeting 59{% endblock %}
-{% block content %}
            
-
            [22:56] <jrand0m> ok ok 
            
-
            [22:56] <jrand0m> agenda 
            
-
            [22:56] <jrand0m> 0.0) welcome 
            
-
            [22:56] <jrand0m> 1.0) dev status 
            
-
            [22:56] <jrand0m> 1.1) router 
            
-
            [22:56] *** Myself248 (~ident@anon.iip) has joined channel #iip-dev
            
-
            [22:56] <jrand0m> 1.2) DH precalc 
            
-
            [22:56] <jrand0m> 2.0) microroadmap 
            
-
            [22:56] <jrand0m> 3.0) apps / usage 
            
-
            [22:56] <jrand0m> 4.0) ns 
            
-
            [22:56] <jrand0m> 5.0) IM 
            
-
            [22:56] <jrand0m> 6.0) administravia (cvs, bugzilla, cvs list, cvs web) 
            
-
            [22:56] <jrand0m> 7.0) questions 
            
-
            [22:57] <jrand0m> (yes, 7 points today.  w00t) 
            
-
            [22:57] <jrand0m> 0.0) welcome 
            
-
            [22:57] <jrand0m> hi. 
            
-
            [22:57] <dm> hey
            
-
            [22:57] <jrand0m> 17 users today.  neat 
            
-
            [22:57] *** Ryan_Singer (chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [22:57] <jrand0m> and counting 
            
-
            [22:57] <jrand0m> ok 
            
-
            [22:57] <thecrypto> 1~hi
            
-
            [22:57] <jrand0m> 1.1) dev status for router 
            
-
            [22:58] <jrand0m> the java reference impl router is doing very well 
            
-
            [22:58] *** ChZEROHag (hag@anon.iip) has joined channel #iip-dev
            
-
            [22:58] <jrand0m> we can now run applications on different routers and send messages ot each other 
            
-
            [22:59] <ChZEROHag> Sorry to interrupt, but hopefully it'll just be once
            
-
            [22:59] <jrand0m> taking an iterative and incremental approach, the current state is secure, not anonymous, not scalable, and harvestable 
            
-
            [22:59] <ChZEROHag> Is anyone else working on a C api?
            
-
            [22:59] <jrand0m> 'lo ChZEROHag, whats shakin? 
            
-
            [22:59] <ChZEROHag> Because I am, but very slowly
            
-
            [22:59] *** dcat (dirtycat@anon.iip) has joined channel #iip-dev
            
-
            [22:59] <jrand0m> oh cool 
            
-
            [22:59] <jrand0m> shardy will be working on one after toorcon is finished 
            
-
            [22:59] <jrand0m> perhaps you two could work together on that? 
            
-
            [23:00] <co> jrand0m: Can you input a destination to send messages to by hand?
            
-
            [23:00] <co> Better said, is there an ASCII representation of a destination?
            
-
            [23:00] <jrand0m> yes co, to both 
            
-
            [23:00] <co> Excellent.
            
-
            [23:00] <jrand0m> destinations, and all I2P structures, are loadable and serializable in (an alternate alphabet) base 64 
            
-
            [23:01] <thecrypto> so it won't be easy to remember, but it will be ascii?
            
-
            [23:01] <jrand0m> (e.g. in the netDb for one of my routers, I have leaseSet-enD4jtE-orMwFD0QGog9GAyC5MvLvnPzhVD8cDYvSI8.dat which contains the lease set for destination enD4jtE-orMwFD0QGog9GAyC5MvLvnPzhVD8cDYvSI8) 
            
-
            [23:02] <jrand0m> [though that is H(destination).toBase64() 
            
-
            [23:03] <jrand0m> ChZEROHag> if there's anything we can do to help you with that, just say the word 
            
-
            [23:03] <jrand0m> ok thats 1.1.  1.2) DH precalc 
            
-
            [23:03] <ChZEROHag> You could do it for me? :-)
            
-
            [23:04] <jrand0m> last night I wrote up a precalc optimization for DH exchanges to save ~1s off 1.5s session negotiations.  I'd love if someone who knows crypto could make sure I'm not nuts ;) 
            
-
            [23:04] <jrand0m> lol ChZEROHag 
            
-
            [23:04] <ChZEROHag> aah I know what I needed
            
-
            [23:04] <ChZEROHag> A netdb implementation
            
-
            [23:04] <thecrypto> is it in cvs?
            
-
            [23:04] <thecrypto> the dh
            
-
            [23:04] <jrand0m> yes thecrypto 
            
-
            [23:05] <jrand0m> C:\dev\i2p\code\core\java\src\net\invisiblenet\i2p\crypto\DHSessionKeyBuilder.java 
            
-
            [23:05] <ChZEROHag> Well I'm going to be up for a good 3/4 hours yet, maybe it'll give me something to do
            
-
            [23:05] <jrand0m> er, s/C:\\dev/g; s/\\/\//g 
            
-
            [23:05] *** wax_off (~nomail@anon.iip) has joined channel #iip-dev
            
-
            [23:06] <jrand0m> word.  what do you need a netdb impl for? 
            
-
            [23:06] <ChZEROHag> I don't remember
            
-
            [23:06] <jrand0m> we currently have a non-scalable netdb in cvs 
            
-
            [23:06] <jrand0m> heh 
            
-
            [23:06] <ChZEROHag> Haven't touched it in at least a week
            
-
            [23:06] <jrand0m> you're working on a C I2CP api, right?  not I2NP? 
            
-
            [23:07] <ChZEROHag> I was just going to do everything
            
-
            [23:07] *** wax_off has left #iip-dev
            
-
            [23:07] <jrand0m> I2NP is really, really, really significantly more work than I2CP 
            
-
            [23:07] <ChZEROHag> Once I actually get properly started, it'll just roll out
            
-
            [23:07] <jrand0m> but if you impl an I2NP in C that'd rule 
            
-
            [23:07] <dm> is there a I2NP in anything right now?
            
-
            [23:07] <jrand0m> (I2CP:I2NP::FCP:FNP) 
            
-
            [23:07] <jrand0m> yes dm 
            
-
            [23:08] * ChZEROHag deminimizes emacs
            
-
            [23:08] <jrand0m> the java impl i'm working on has I2NP functioning 
            
-
            [23:08] <dm> alrighty...
            
-
            [23:08] <ChZEROHag> jrand0m: url? I could do with a reference, even if it's in a horrible language.
            
-
            [23:08] <jrand0m> heh 
            
-
            [23:08] <jrand0m> erm, actually thats 6.0 administravia: aka where the fuck is our anon cvs access ;) 
            
-
            [23:09] <thecrypto> i'm getting the DH stuff
            
-
            [23:09] <jrand0m> coo' 
            
-
            [23:09] <ChZEROHag> Oh right
            
-
            [23:09] <Ryan_Singer> jrand0m,  back to schedule, the microroadmap?
            
-
            [23:09] * thecrypto hides his face
            
-
            [23:09] <ChZEROHag> well I'll wait :)
            
-
            [23:09] <jrand0m> heh 'k 
            
-
            [23:09] <jrand0m> microroadmap 
            
-
            [23:09] <jrand0m> I have 0.1 through 0.5 mapped out 
            
-
            [23:09] <dm> followed freenet's roadmap then?
            
-
            [23:10] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev
            
-
            [23:10] <jrand0m> 0.1) functional, secure, not anonymous, not scalable, harvestable 
            
-
            [23:10] <dm> development slows down and freezes during 0.5...
            
-
            [23:10] <jrand0m> we are now at 0.1.   
            
-
            [23:10] <jrand0m> heh I noticed that dm, flinks hosed off at 0.5.2 as well ;) 
            
-
            [23:10] <co> What are you calling the whole package?
            
-
            [23:10] <jrand0m> (strange coincidence) 
            
-
            [23:10] <co> i.e. version 0.1 of?
            
-
            [23:10] <jrand0m> the whole package?  i2p router reference implementation 
            
-
            [23:10] <ChZEROHag> co: Wonga
            
-
            [23:10] * beefbroth joins the meeting
            
-
            [23:11] <jrand0m> buenos noches beefbroth 
            
-
            [23:11] <co> All right. That explains it.
            
-
            [23:11] <ChZEROHag> Actually maybe I will call it that. Certainly sounds more interesting than 'i2pd'
            
-
            [23:11] <jrand0m> 0.1 has bugs.  thats a given.  and it has no optimizations of note (though the DH precalc helps).   
            
-
            [23:11] <jrand0m> heh 
            
-
            [23:11] <Ryan_Singer> jrand0m,  what's 0.2) then?
            
-
            [23:11] <jrand0m> invisible internet police department 
            
-
            [23:11] <jrand0m> ok, 0.2 
            
-
            [23:12] <jrand0m> 0.2 is functional, secure, anonymous, not scalable, harvestable 
            
-
            [23:12] <jrand0m> 0.2 adds support for non-zero-length tunnels 
            
-
            [23:12] <jrand0m> I actually implemented most of that last night, but not thoroughly tested 
            
-
            [23:12] <jrand0m> I think 0.2 will be ready by end of week 
            
-
            [23:12] <Ryan_Singer> how far away are we from that from a dev perspective?
            
-
            [23:13] <Ryan_Singer> great
            
-
            [23:13] <jrand0m> 0.3) is functional, secure, anonymous, scalable, harvestable 
            
-
            [23:13] * thecrypto gets bochs so he can simulate a network to help with this
            
-
            [23:13] <jrand0m> 0.3 adds a kademliaDatabaseManager 
            
-
            [23:13] <jrand0m> right now we use a BroadcastDatabaseManager 
            
-
            [23:13] <jrand0m> (aka gnunet ;) 
            
-
            [23:14] <jrand0m> trivial to implement and functional for small networks, but we need the kademlia to scale 
            
-
            [23:14] <jrand0m> 0.4) is functional, secure, anonymous, scalable, non-harvestable 
            
-
            [23:14] <jrand0m> that adds trusted links 
            
-
            [23:14] <Ryan_Singer> jrand0m,  and how much of a dev challenge is it to implement kademlia?
            
-
            [23:14] <jrand0m> I have two ideas for trusted links.. one is more easily implementable and usable 
            
-
            [23:15] <jrand0m> kademlia will probably take a full week 
            
-
            [23:15] <jrand0m> (to get right) 
            
-
            [23:15] <jrand0m> note that all of this has lots of room for refactoring and tuning.  I'm aiming functional first, then we tune. 
            
-
            [23:16] <co> Are you certain you will be able to develop and test that quickly?
            
-
            [23:16] <jrand0m> I am certain of nothing 
            
-
            [23:16] <jrand0m> thats just my estimate 
            
-
            [23:16] <Ryan_Singer> co, hegets functional, we test
            
-
            [23:16] <ChZEROHag> Are you sure?
            
-
            [23:16] <ChZEROHag> (sorry)
            
-
            [23:16] <co> Ryan_Singer: I see.
            
-
            [23:17] * jrand0m <3 people who test :)
            
-
            [23:17] <Myself248> When you say "we" test. Is there any place for non-coders to help with the testing?
            
-
            [23:17] <jrand0m> Myself248> probably not until 0.4 
            
-
            [23:17] <dm> lets just hope it never gets to the point where it's functional, but nobody knows what the fuck is going on inside the network to make it work well (i.e. freenet)
            
-
            [23:18] <jrand0m> once 0.4 is ready, thats pre-alpha.  once its 0.4 I'll tune and refactor and fill in the blanks to get ready for 0.5 (alpha) 
            
-
            [23:18] <Myself248> Document, document, document.
            
-
            [23:18] <dm> is there any though being put into active monitoring of network internals, or is it straightforward?
            
-
            [23:18] <jrand0m> yes dm, absolutely 
            
-
            [23:18] <jrand0m> one of the key pieces of i2np is the inclusion of stats in the routerInfo strutures published 
            
-
            [23:18] <mihi> jrand0m: do a s/0./0.0./ ;)
            
-
            [23:18] <jrand0m> the initial revs will publish real stats so we can tune 
            
-
            [23:19] <jrand0m> later revs will either not publish any stats or publish fake ones 
            
-
            [23:19] * jrand0m does not do 0.0
            
-
            [23:19] <shardy> ok, I'm here
            
-
            [23:19] <jrand0m> wb shardy 
            
-
            [23:19] <shardy> sorry for being late, forgot about this window being open, heh
            
-
            [23:19] <dm> cool.
            
-
            [23:19] <Ryan_Singer> is there a higher level document describing the archetecture for the network under .4?
            
-
            [23:19] <jrand0m> off with your head 
            
-
            [23:20] <jrand0m> Ryan_Singer> hmm, I had some overview docs a few months back that mids and nop mirrored, and there's the i2p overview doc 
            
-
            [23:20] <jrand0m> 0.4 is full i2np as described in the spec, just not optimally implemented 
            
-
            [23:20] <shardy> oh and jrand0m, I'll check out the DH optimization for you
            
-
            [23:20] <jrand0m> word, gracias  
            
-
            [23:20] <Ryan_Singer> can I get those docs?
            
-
            [23:21] <jrand0m> the overview is at (Link: http://www.invisiblenet.net/i2p/i2p_philosophy.pdf)http://www.invisiblenet.net/i2p/i2p_philosophy.pdf 
            
-
            [23:21] <beefbroth> they're on the wiki I think?
            
-
            [23:21] <jrand0m> hte old overview docs... hmm 
            
-
            [23:21] <jrand0m> (i2p specs are at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs) 
            
-
            [23:21] <co> They are on (Link: www.invisiblenet.net/i2p/.)www.invisiblenet.net/i2p/.
            
-
            [23:21] <jrand0m> right beefbroth 
            
-
            [23:22] <jrand0m> though there are old docs in html format w/ ugly ms paint pictures from before showing how tunnels work... 
            
-
            [23:22] <beefbroth> I should know, I've read them enough
            
-
            [23:22] <jrand0m> hehe 
            
-
            [23:22] <co> Unless those are older versions or mirrors.
            
-
            [23:22] <jrand0m> those files on the wiki are 0.9 (0.9.1 is out for I2NP and datastructures, but they only include minor changes) 
            
-
            [23:23] <thecrypto> jrand0m: the precalc looks good
            
-
            [23:23] <jrand0m> cool 
            
-
            [23:24] *** pitu (~pitu@anon.iip) has joined channel #iip-dev
            
-
            [23:24] * jrand0m runs the router w/ java -Dcrypto.dh.precalc.min=3 -Dcrypto.dh.precalc.max=10 -Dcrypto.dh.precalc.delay=5000 -jar C:\dev\i2p\code\router\java\src\router.jar 
            
-
            [23:25] <jrand0m> ok, thats the microroadmap 
            
-
            [23:25] <jrand0m> as you can see, I'm accepting that alpha won't be ready for end of month.  0.4 will probably be first week of october 
            
-
            [23:26] <dm> that's okay, even that would be the fastest ever implementation of a network of this type ;)
            
-
            [23:26] <Ryan_Singer> lol
            
-
            [23:26] <beefbroth> when reading jrand0m's time estimates here, please remember that he has been drinking whiskey for the last 4 hours :-P
            
-
            [23:26] <jrand0m> heh 
            
-
            [23:26] <Ryan_Singer> ok...apps/usage?
            
-
            [23:26] <jrand0m> good whiskey at that ;) 
            
-
            [23:26] <jrand0m> ok, apps/usage 
            
-
            [23:27] <dm> 0.7 in 4 seconds....3...2...1..!!
            
-
            [23:27] <jrand0m> I'm aiming for low hanging fruit here - these are things that we can do with 0 or minimal new code. 
            
-
            [23:27] <ChZEROHag> How are you supposed to code properly if you're stone sober?
            
-
            [23:27] <jrand0m> all of these make significant use of mihi's kickass i2ptunnel 
            
-
            [23:27] <co> ChZEROHag: Easily.
            
-
            [23:27] *** mihi has changed the topic on channel #iip-dev to <dm> 0.7 in 4 seconds....3...2...1..!!
            
-
            [23:28] <jrand0m> using the i2ptunnel, we can do the following without writing any new code: 
            
-
            [23:28] <jrand0m> public ww proxy (using i2ptunnel + squid) 
            
-
            [23:28] * dm tips his hat to mihi.
            
-
            [23:28] <jrand0m> JAP (using i2ptunnel + JAP) 
            
-
            [23:28] <mihi> you cannot kick asses though i2p (not through a tunnel either...)
            
-
            [23:28] <jrand0m> browse www anon (i2ptunnel + web browser) 
            
-
            [23:28] <jrand0m> run an i2p web server (i2ptunnel + httpd) 
            
-
            [23:29] <co> Very nice. Bravo, mihi.
            
-
            [23:29] <jrand0m> cvs outproxy (i2ptunnel) [e.g. cvs outproxy to sourceforge for anon freenet dev] 
            
-
            [23:29] <jrand0m> cvs client, cvs server 
            
-
            [23:29] <jrand0m> IM app, pop3 server, imap server, opennap 
            
-
            [23:29] <jrand0m> those are all really low hanging fruit 
            
-
            [23:29] <dm> okay, now all we need is i2p :)
            
-
            [23:30] <jrand0m> right ;) 
            
-
            [23:30] <Myself248> wouldn't i2p webserver kinda supplant freenet? :)
            
-
            [23:30] * jrand0m thinks that qualifies as a faq I should answer
            
-
            [23:30] <Ryan_Singer> jrand0m,  but they are also very valuable
            
-
            [23:30] <ChZEROHag> From that list, I'd consider cvs more important/useful
            
-
            [23:30] <ChZEROHag> Partly because I wish to remain anonymous, but also because if anonymous www is provided you'll get lusers
            
-
            [23:30] <jrand0m> i2p + web doesn't supplant freenet - freenet adds significant value on top of an anon comm framework - content distribution 
            
-
            [23:31] <ChZEROHag> And at the moment the idea of anonymous email is scary :)
            
-
            [23:31] * dm writes down: "no lusers"
            
-
            [23:31] <jrand0m> cvs definitely is in the top 3 
            
-
            [23:31] <beefbroth> i think if i2p webserving works well, you have to consider merging the DHT/storage parts of freenet on top of i2p and then you have the best of both worlds.
            
-
            [23:31] <Ryan_Singer> ChZEROHag,  if it's scalable thats a goodthing
            
-
            [23:31] <ChZEROHag> dm: lusers are only a problem during the early stages, but they tend not to use cvs
            
-
            [23:31] <Myself248> okay, add lots of hashcash to any anon email thing.
            
-
            [23:31] <ChZEROHag> Or, for that matter, even know what (or that) it is
            
-
            [23:31] <co> I think one of the tests that needs to be done is a test attack on the network.
            
-
            [23:31] <jrand0m> yes beefbroth, once i2p does what we aim at, freenet will most likely adjust to make use of it 
            
-
            [23:32] <co> Sorry if that is offtopic.
            
-
            [23:32] <mihi> Myself248: just add a redirector to an anon remailer.
            
-
            [23:32] <jrand0m> no, thats definitely on topic co - attacking this network is key 
            
-
            [23:32] <ChZEROHag> Myself248: hashcash is primarily to stop flooding while we're forced to use the ancient protocol that is 'irc'
            
-
            [23:32] <ChZEROHag> Not to stop what could be termed 'abuse'
            
-
            [23:32] <jrand0m> right mihi.  though perhaps mixminion run over i2p would be useful 
            
-
            [23:33] <jrand0m> right, hashcash is even built into i2p itself to keep messages from being delivered a single hop unless they "pay up" 
            
-
            [23:33] <Ryan_Singer> jrand0m,  we could run imap over this easily?
            
-
            [23:33] <jrand0m> absolutely 
            
-
            [23:33] <Ryan_Singer> impressive
            
-
            [23:33] <jrand0m> imapd with an i2ptunnel pointing at it, with i2ptunnel on the client pointing at that tunnel's destination 
            
-
            [23:34] <Myself248> and freenet search engines :)
            
-
            [23:34] <mihi> ftp or several non-jabber instant messengers will make problems...
            
-
            [23:34] <jrand0m> right, things that require two connections are more complex 
            
-
            [23:34] <ChZEROHag> jrand0m: hashcash in i2p?
            
-
            [23:34] <ChZEROHag> I shall bug you about that when this is over.
            
-
            [23:34] <shardy> hashcash in i2p? nice. 
            
-
            [23:34] <dm> we're getting ahead of ourselves! oh alright, who cares.. QUAKE + IIP!!!!!!
            
-
            [23:34] <dm> sorry, I2p :)
            
-
            [23:34] <jrand0m> lol dm 
            
-
            [23:35] <Myself248> Those of us with little CPUs get nervous when someone says hashcash, but as an anti-spamming measure I understand it.
            
-
            [23:35] <co> dm: That is *reallY* getting ahead of ourselves.
            
-
            [23:35] * mihi is jabber:schierlm@a-message.de ;)
            
-
            [23:35] <jrand0m> yes ChZEROHag - Destination == public signing key (DSA) + public encryption key (ElGamal) + certificate (either null or hashcash(keys)) 
            
-
            [23:35] <beefbroth> is the i2p tunnel static or dynamic on the client end?
            
-
            [23:35] <mihi> beefbroth: atm it is all static. but you could use a socks proxy as dest. ;)
            
-
            [23:35] <jrand0m> Myself248> I'm getting a bitching sun ultra1 in the mail in a few weeks.  if a 160Mhz box can do it, everyone can 
            
-
            [23:35] <shardy> well. hashcash shouldn't be something that is terrible even to small cpus. only if you want to do something eleventy billion times, should you notice it.
            
-
            [23:36] <co> beefbroth: It can be dynamic.
            
-
            [23:36] <Ryan_Singer> the potential applications of the "low-hanging fruit"  here are very impressive
            
-
            [23:36] <jrand0m> right mihi 
            
-
            [23:36] <jrand0m> "eleventy".  heh 
            
-
            [23:36] <ChZEROHag> the low hanging fruit is essentially 'normal' internet apps, but anonymously
            
-
            [23:36] <ChZEROHag> right?
            
-
            [23:36] <jrand0m> right 
            
-
            [23:36] <Ryan_Singer> yes
            
-
            [23:36] <dm> (quake)
            
-
            [23:37] <jrand0m> 0.1 runs them securely, 0.2 runs them anonymously, 0.3 runs them scalably, 0.4 runs them non-harvestably 
            
-
            [23:37] <jrand0m> (we're @ 0.1 now) 
            
-
            [23:37] <shardy> what do you mean by non-harvestably?
            
-
            [23:37] <co> Sorry, what is harvestable again?
            
-
            [23:37] <ChZEROHag> dm: Unfortunately we've ben held back enough that realtime is after more than 30 years still not 'normal'
            
-
            [23:37] <Myself248> Phew. I was hoping someone would ask that. ;)
            
-
            [23:37] <Ryan_Singer> loggable
            
-
            [23:37] <jrand0m> harvesting means an active attacker can run a router, find out about lots of other routers ("harvest" them), and send the goons to kick in their doors 
            
-
            [23:38] <Myself248> oh, like you can do with gnutella. :)
            
-
            [23:38] <Ryan_Singer> secret-servicy like goons
            
-
            [23:38] <jrand0m> right 
            
-
            [23:39] <shardy> ah, gotcha.
            
-
            [23:39] <jrand0m> ok, but yeah, thats the microroadmap. 
            
-
            [23:40] <jrand0m> now, am I being stupid calling these 0.x instead of 0.0.x?  should 1.0 be "perfect" or should 1.0 be functional and safe? 
            
-
            [23:40] <Ryan_Singer> jrand0m,  and we will see .4 when?
            
-
            [23:40] <jrand0m> 0.4 is probably 2 weeks out 
            
-
            [23:40] * jrand0m is taking a week off (ish) in mid october as I have people coming to visit
            
-
            [23:40] *** Signoff: dm (EOF From client)
            
-
            [23:40] <mihi> 1.0 should be stable.
            
-
            [23:40] <co> Let 1.0 be functional and safe.
            
-
            [23:40] <thecrypto> dittos co
            
-
            [23:41] <Ryan_Singer> 1.0 should be functional, stable and safe
            
-
            [23:41] <ChZEROHag> jrand0m: My philosophy, regarding version numbers, is if in doubt, copy Linux
            
-
            [23:41] <Myself248> 5.0 can be "perfect". Free software people are overly afraid of version number bloat.
            
-
            [23:41] <jrand0m> word 
            
-
            [23:41] <mrflibble> jrand0m, v1 of things are never perfect :)
            
-
            [23:41] *** dm (~gj@anon.iip) has joined channel #iip-dev
            
-
            [23:41] <mrflibble> people dont expect them to be perfect either
            
-
            [23:41] <dm> did I miss 1.0?
            
-
            [23:41] <ChZEROHag> mrflibble: People don't expect any software to be perfect. People use windows.
            
-
            [23:41] <Ryan_Singer> this software will beGPL orLGPL?
            
-
            [23:41] <jrand0m> cool, I've already gotten flack for 1.0 being not-perfect yet 
            
-
            [23:41] <ChZEROHag> That doesn't mean it shouldn't be.
            
-
            [23:41] <mrflibble> good point ChZEROHag
            
-
            [23:42] <dm> ah shit, I did didn't i..
            
-
            [23:42] <mihi> dm: stop kidding
            
-
            [23:42] <mrflibble> yup, u did
            
-
            [23:42] <jrand0m> the router is GPL.  the java client library is currently GPL, but I'm open.  thecrypto and I are full owners of all but one section (the Cryptix AES impl, which is MIT) 
            
-
            [23:42] <dm> alright alright I'm sorry :(
            
-
            [23:42] <jrand0m> actually, I take that back 
            
-
            [23:42] <jrand0m> I used the Base64.java from freenet too 
            
-
            [23:43] <beefbroth> are we still on agenda item 0.3 Apps ?
            
-
            [23:43] <jrand0m> so base64 is GPL :) 
            
-
            [23:43] <thecrypto> and the IM client will be GPL
            
-
            [23:43] <jrand0m> oh yeah, we're on 0.3 aren't we 
            
-
            [23:43] <thecrypto> as soon as i get around to putting comments in the code
            
-
            [23:43] *** UserX_ (~User@anon.iip) has joined channel #iip-dev
            
-
            [23:43] <jrand0m> heh thecrypto 
            
-
            [23:43] <ChZEROHag> GPL sounds good to me
            
-
            [23:43] <jrand0m> w0ah, 23 users 
            
-
            [23:43] <Myself248> we're on agenda item 6.02E23, random crap. :)
            
-
            [23:43] <Ryan_Singer> jrand0m,  if you get time, I want to talk to you about liscencing and potential consulting gigs
            
-
            [23:43] <jrand0m> cool Ryan_Singer 
            
-
            [23:43] <ChZEROHag> Though as someone (Fillament?) pointed out - if someone breaks the license how is an anonymous person going to do anything about it?
            
-
            [23:43] <mihi> jrand0m: 22 ;)
            
-
            [23:43] <jrand0m> ChZEROHag> read my license on flinks ;) 
            
-
            [23:43] <Myself248> we need an anonymous court system.
            
-
            [23:44] * mihi is here twice
            
-
            [23:44] <jrand0m> Myself248> its called yodel ;) 
            
-
            [23:44] <Myself248> "The court now hears docket number 34534, J. Doe v. J. Doe"
            
-
            [23:44] <Ryan_Singer> ChZEROHag,  the reason I ask is for corporations to make use of this software for security against industrialespionage
            
-
            [23:44] <co> Naming server will be licensed under GPL as well.
            
-
            [23:44] <CCD> lol
            
-
            [23:44] <Myself248> "Baliff, aren't those the same parties as the last 34533 cases we've heard?"
            
-
            [23:44] <shardy> well
            
-
            [23:45] <shardy> there's always the idea that if you want people to *really* use your protocol, and you're not worried about money, just make it completely open. not even restricted by gpl.
            
-
            [23:45] <co> shardy: You mean public domain?
            
-
            [23:45] <beefbroth> i think that was co's lead in to 0.4 agenda item :-P
            
-
            [23:45] <jrand0m> shardy> the specs are public and open.  I have not asserted copyright on the specs. 
            
-
            [23:45] <Ryan_Singer> shardy,  no, we would like work on the protocol to stay available
            
-
            [23:45] <shardy> public domain, bsd license, "do whatever you want just give us credit please" license, etc
            
-
            [23:45] <jrand0m> the code is GPL for the router.  one client api implementation in java is GPL 
            
-
            [23:46] <Ryan_Singer> check out the liberty protocol.... (Link: http://projectliberty.org)http://projectliberty.org
            
-
            [23:46] <shardy> jrand0m: ok cool. gotcha.
            
-
            [23:46] * jrand0m has thought about "no government use" licenses ;)
            
-
            [23:46] <jrand0m> ok, the reason I tossed 3.0) apps into the list of issues is this 
            
-
            [23:46] <jrand0m> we need help. 
            
-
            [23:46] <Ryan_Singer> help with what?
            
-
            [23:46] <jrand0m> i2ptunnel is good code.  i2p's router will be good code. 
            
-
            [23:47] <jrand0m> what we need is for people to start figuring out the nuts and bolts of release engineering 
            
-
            [23:47] <dm> why do you need apps if you can just use i2ptunner?
            
-
            [23:47] <ChZEROHag> jrand0m: come again?
            
-
            [23:47] <jrand0m> aka, how to actually package something up that joe sixpack can download and browse the web 
            
-
            [23:47] <ChZEROHag> dm: Why do you need apps if you can just use telnet?
            
-
            [23:47] <dm> what?
            
-
            [23:47] * dm scratches his head.
            
-
            [23:47] <CCD> err, there is something besides telnet?
            
-
            [23:48] * jrand0m thinks thats ChZEROHag's point dm ;)
            
-
            [23:48] *** Myself248 is now known as myself248
            
-
            [23:48] *** Signoff: thecrypto (Ping timeout)
            
-
            [23:48] <ChZEROHag> dm: To use i2ptunnel would be like having a working car and then dragging it around on a handcart
            
-
            [23:48] <jrand0m> ok, thats just that.  I just wanted to mention in case people had spare time :) 
            
-
            [23:48] <jrand0m> ok, 4.0) 
            
-
            [23:48] <jrand0m> naming service 
            
-
            [23:48] <dm> I can see he's trying to make a point.
            
-
            [23:48] <jrand0m> hi co, hows it going?  :) 
            
-
            [23:48] <co> The naming server must be GPL, since at least the Java implementation uses code from the client library to contact routers.
            
-
            [23:49] <dm> but we just spent 20 minutes going: I2Ptunnel + web server!, I2Ptunnel + quake! ;)
            
-
            [23:49] <ChZEROHag> Or, in computing terms, like doing all your internet stuff with telnet instead if directly on the ip stack
            
-
            [23:49] <co> I did not do much last week. I released the client API, which also needs work.
            
-
            [23:49] <ChZEROHag> i2ptunnel is an interrim solution
            
-
            [23:49] <co> I will have time this week, though, to begin implementing the naming server.
            
-
            [23:49] <jrand0m> cool 
            
-
            [23:49] <jrand0m> where is the client api again? 
            
-
            [23:50] <mihi> on the mailing list ;)
            
-
            [23:50] <co> One of its assumptions is that destinations can be encoded in base64, which is why I asked the question about that earlier.
            
-
            [23:50] <jrand0m> ChZEROHag> in some ways its interim 
            
-
            [23:50] * jrand0m !thwaps self
            
-
            [23:50] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev
            
-
            [23:50] <dm> so is TCP!
            
-
            [23:50] *** yodel (yodel@anon.iip) has joined channel #iip-dev
            
-
            [23:50] <jrand0m> 'lo yodel 
            
-
            [23:50] <beefbroth> what are the naming conventions going to look like? is it something that joe average will be able to relate to (i.e. (Link: www.somthing.com)www.somthing.com  or (Link: www.something.i2p)www.something.i2p for http/web stuff)?
            
-
            [23:50] <co> I will put the naming service specification and client API into CVS.
            
-
            [23:50] <jrand0m> wb thecrypto 
            
-
            [23:50] <ChZEROHag> These have probably been covered before, but how will the ns provide unique names fairly?
            
-
            [23:50] * mihi wants to have *.mihi.iip ;)
            
-
            [23:50] <jrand0m> beefbroth> with the naming service or without? 
            
-
            [23:50] <jrand0m> heh mihi 
            
-
            [23:50] <ChZEROHag> avoiding the squatting, etc. that has plagued DNS
            
-
            [23:50] <thecrypto> can someone send me what happened?
            
-
            [23:51] <beefbroth> jrand0m: with. i think without would be a long string of numbers.
            
-
            [23:51] <co> ChZEROHag: You will register with a group of naming servers, then will use the name of that group to identify yourself.
            
-
            [23:51] <co> As in IM.beefbroth.mygroup if you provide IM service.
            
-
            [23:51] <mihi> oops, s/iip/i2p
            
-
            [23:51] *** godmode0_ (~mode@anon.iip) has joined channel #iip-dev
            
-
            [23:51] *** Signoff: godmode0 (EOF From client)
            
-
            [23:51] <jrand0m> ChZEROHag> co's naming service has trusted groups, where each group manages a group name (tld).  you select chose which groups run each tld 
            
-
            [23:51] <co> Yes, it will be possible for someone to register the username beefbroth with group2.
            
-
            [23:51] <thecrypto> in the 4 minutes i was gone
            
-
            [23:52] <ChZEROHag> co: So the only issue is the .mygroup uniqueness?
            
-
            [23:52] <ChZEROHag> And who gets the group 'com'? :-)
            
-
            [23:52] <jrand0m> and that is selected by the client 
            
-
            [23:52] <mihi> ChZEROHag: i2p is not COMmerical
            
-
            [23:52] <jrand0m> (e.g. you tell your ns client lib "group '.com' is group 0123ff33aefcbb34fe 
            
-
            [23:52] <beefbroth> I hate to suggest it, but I almost think the groups should default to 3 letters to preserve the illusion that it is similar to the regular web
            
-
            [23:52] <co> ChZEROHag: I am not sure who gets the "com" group.
            
-
            [23:52] <co> Good question.
            
-
            [23:53] <shardy> beefbroth: except the "regular web" is no longer only 3 letter lds
            
-
            [23:53] <mihi> beefbroth: or add a .i2p to all addresses.
            
-
            [23:53] <ChZEROHag> beefbroth: That illusion is only present in america
            
-
            [23:53] <shardy> tlds.
            
-
            [23:53] <jrand0m> to start with, we may just want to initially have one group of naming servers, ".i2p" 
            
-
            [23:53] <co> beefbroth: The naming server software permits you to have up to 32 letters.
            
-
            [23:53] <ChZEROHag> Elsewhere we use the 2-letter country codes given us
            
-
            [23:53] <shardy> .us is also in use in america.
            
-
            [23:53] <co> Actually, I wanted the first group to be "test".
            
-
            [23:53] <shardy> as are things like .info and .name
            
-
            [23:53] <jrand0m> heh 'k 
            
-
            [23:54] <ChZEROHag> shardy: yeah, by about 5 people.
            
-
            [23:54] <ChZEROHag> But this is perhaps a rant for another time :)
            
-
            [23:54] <jrand0m> actually... 
            
-
            [23:54] <shardy> there's even a .museum
            
-
            [23:54] <Ryan_Singer> jrand0m,  using .12p sounds good
            
-
            [23:54] <jrand0m> I ran into a distributed DNS based of JXTA the other day 
            
-
            [23:54] <co> ChZEROHag: But the point is that if you do not like the people running the "com" group, you can establish the "com2" group and run its servers (and register with it).
            
-
            [23:55] <ChZEROHag> YEs that bit makes perfect sense
            
-
            [23:55] <mihi> ChZEROHag: (Link: http://www.nic.us/press/audio/dotus-mayEM.wav)http://www.nic.us/press/audio/dotus-mayEM.wav ;)
            
-
            [23:55] <jrand0m> co> can't you just say "well, they 'think' they're .com, but I say .com is run by group2"? 
            
-
            [23:55] <ChZEROHag> What I'm getting at, I suppose, is does it rely on first-come-first-served?
            
-
            [23:55] <co> You may configure your client to do anything.
            
-
            [23:56] <Ryan_Singer> how does the JXTA name system work?
            
-
            [23:56] <jrand0m> co> (Link: http://wiki.java.net/bin/view/Jxta/DisDNS)http://wiki.java.net/bin/view/Jxta/DisDNS is a distributed DNS wiki, though its very rough and doesn't address any real hard issues 
            
-
            [23:56] <co> ChZEROHag: In registering your username with a group, yes.
            
-
            [23:56] <co> jrand0m: I will look at that after the meeting.
            
-
            [23:56] <jrand0m> jxta runs naming servers off rendevous points 
            
-
            [23:56] <ChZEROHag> mihi: wassat?
            
-
            [23:56] <beefbroth> so it is possible someone tries to attack the NS system by mimicing the already existing i2p group of naming servers
            
-
            [23:57] *** Signoff: jeremiah (Ping timeout)
            
-
            [23:57] <co> beefbroth: I think not.
            
-
            [23:57] <mihi> ChZEROHag: listen to it. why xxx million americans prefer .us over .com
            
-
            [23:57] <mihi> 68 million
            
-
            [23:57] <co> As I envision it, people setting up groups will announce those groups.
            
-
            [23:57] <jrand0m> mimicing?  they can't mimic as the servers in the group are authenticated by public key systems 
            
-
            [23:58] <jrand0m> however, if groups allow non-trusted members to join the group, they can be taken over trivially. 
            
-
            [23:58] <shardy> but how is the key exchange done?
            
-
            [23:58] <co> The later people will face the problem that the group is already established, and the client software configuration files contain the former group's destinations.
            
-
            [23:58] <ChZEROHag> mihi: Well I've always said it makes sense to prefer it, patriotism and whatnot, I've just never really seen it.
            
-
            [23:58] <beefbroth> what happens if two groups of naming servers both claim to resolve the .i2p group?
            
-
            [23:58] <co> Good question, though, and I will think over it again, carefully.
            
-
            [23:58] <ChZEROHag> Anyway, I shall have a listen
            
-
            [23:58] <jrand0m> shardy> no key exchange - key publishing 
            
-
            [23:58] <beefbroth> i see, good point
            
-
            [23:58] <ChZEROHag> co: Yeah that's another thing I was trying to get at
            
-
            [23:58] <shardy> but keys can still be intercepted if they're published online
            
-
            [23:58] <jrand0m> beefbroth> no one claims anything.  your client says "i2p == [dest1, dest2, dest]" 
            
-
            [23:59] <shardy> what we need is a trust-based dns system :)
            
-
            [23:59] <shardy> so you can submit a query for the name and get back a list of responses... and then go with the trusted one
            
-
            [23:59] <co> Thank you for bringing this up.
            
-
            [23:59] <jrand0m> shardy> ah, I think I understand the confusion.  I think the naming service will want to come with a set of destinations out of band (aka packaged with install) 
            
-
            [23:59] <ChZEROHag> Yeah we have one - everyone trusts IANA (or whatever they call themselves) or else.
            
-
            [23:59] * shardy ducks
            
-
            [23:59] <ChZEROHag> :-D
            
-
            [23:59] <mrflibble> they're trying that with dnssec, but of course that's not anonymous
            
-
            [00:00] <jrand0m> what this naming service does is get away from root servers 
            
-
            [00:00] <beefbroth> you could always have an i2p homepage that listed active naming groups and authorites?
            
-
            [00:00] <shardy> jrand0m: ok. just pointing out that it can still be intercepted no matter what you do, unless there's a physically secure channel to initially transmit those keys over...
            
-
            [00:00] <co> shardy: I think I covered key exchange in the spec. If not, tell me.
            
-
            [00:00] <shardy> but packaging it oob makes it better
            
-
            [00:00] <shardy> co: I'll check it out. 
            
-
            [00:00] <jrand0m> shardy> oh, right.  yes, people need to be able to trust the code they download 
            
-
            [00:00] <co> beefbroth: Certainly.
            
-
            [00:01] <ChZEROHag> aah that reminds me
            
-
            [00:01] <jrand0m> beefbroth> yes, thats most certainly one of the first apps that will be implemented - an i2p webserver w/ bbs & wiki that people can access through i2p 
            
-
            [00:01] <ChZEROHag> I should create a gpg key for my iipmail
            
-
            [00:01] *** yodel has left #iip-dev
            
-
            [00:01] * ChZEROHag does so while unexciting stuff happens
            
-
            [00:01] <jrand0m> heh ok 
            
-
            [00:01] <co> Please understand that the naming server specification is still open to suggestions for improvement.
            
-
            [00:02] <shardy> I think I'm going to bring all the specs with me on the flight to toorcon... that'll give me a time to read them
            
-
            [00:02] <co> I do not claim it is perfect or finalized at this time.
            
-
            [00:02] <jrand0m> heh I hope its a long flight 
            
-
            [00:02] <shardy> and it's more productive than playing fft advance the entire time, heh
            
-
            [00:02] * jrand0m has found that criticism will more freely come once there is code implementing specs
            
-
            [00:02] *** godmode0_ is now known as godmode0
            
-
            [00:02] <co> And I have to write the code.
            
-
            [00:02] <co> I think we can move on to the next topic now.
            
-
            [00:02] <jrand0m> 'k 
            
-
            [00:02] <jrand0m> 5.0) IM 
            
-
            [00:03] <jrand0m> hi thecrypto 
            
-
            [00:03] <mihi> names should not be able to clash with base64 representations.
            
-
            [00:03] <thecrypto> hi
            
-
            [00:03] <thecrypto> okay
            
-
            [00:03] <mihi> and the namin server should transparently return bas64 addressas as is.
            
-
            [00:03] <co> mihi: Very well, I will try to avoid that problem.
            
-
            [00:03] <thecrypto> first since my e-mail isn't working again (damn spammers)
            
-
            [00:03] <jrand0m> (all classes that extend DataStructure have String .toBase64() and .fromBase64(InputStream) ) 
            
-
            [00:03] <thecrypto> i'll answer whit's questions about me system here
            
-
            [00:04] * jrand0m loads up co's email
            
-
            [00:04] <mihi> jrandom? why Inputstream and not Reader?
            
-
            [00:04] <thecrypto> network is the first thing that came to mind, you are making connections over the i2p network, it's very p2p so i called it a networkr
            
-
            [00:04] <jrand0m> if you want a Reader, just run an InputStreamReader, you brat 
            
-
            [00:04] <mihi> base64 is characters, not bytes in my opinion.
            
-
            [00:04] <ChZEROHag> jrand0m: IM == Instant Messaging?
            
-
            [00:04] <jrand0m> yes ChZEROHag 
            
-
            [00:04] <thecrypto> if people have a problem with that, give me a suggestion for what to call it about
            
-
            [00:05] <ChZEROHag> jabber?
            
-
            [00:05] <thecrypto> IM == my own distributed IM network
            
-
            [00:05] <shardy> you should call it "bob"
            
-
            [00:05] <jrand0m> i2p im is a network in the same way aim is a network, or kazaa is a network, all running over tcp/ip or udp/ip 
            
-
            [00:05] <co> How about IM application?
            
-
            [00:05] <ChZEROHag> (anonabber)
            
-
            [00:05] <co> jrand0m: I see.
            
-
            [00:05] <thecrypto> jabber requires a centerized server
            
-
            [00:05] <jrand0m> terminology doesn't matter to me.  I like shardy's idea 
            
-
            [00:05] <ChZEROHag> thecrypto: Nothing *requires* a centralised server
            
-
            [00:05] <thecrypto> and i cannot spell today so bear with me
            
-
            [00:06] <ChZEROHag> That's just the way things are written
            
-
            [00:06] <jrand0m> (though I prefer Betty) 
            
-
            [00:06] <thecrypto> so you want me to call it I2PIM bob?
            
-
            [00:06] <thecrypto> :)
            
-
            [00:06] <jrand0m> how about wilma? 
            
-
            [00:06] <jrand0m> fred is taken thoug 
            
-
            [00:06] <co> How about distributed IM?
            
-
            [00:06] <jrand0m> DIM, heh 
            
-
            [00:06] <co> But then, distributed IM *application*?
            
-
            [00:06] <dm> AIM, anonymous Instant messaging!
            
-
            [00:06] <thecrypto> bad acronym :)
            
-
            [00:07] <dm> then we can take over AOL.
            
-
            [00:07] <thecrypto> ohh i can just wait for AOL to get wind of that
            
-
            [00:07] <ChZEROHag> dm: That would realy piss certain wankers off. I like it.
            
-
            [00:07] <jrand0m> heh do it 
            
-
            [00:07] <Ryan_Singer> thecrypto,  will webe able to implement IM in a decentralised way, or will it have to be centrallized?
            
-
            [00:07] <co> dm: Good idea. I would back that acronym.
            
-
            [00:07] <jrand0m> the way I've read thecrypto's docs, the IM is fully decentralized 
            
-
            [00:07] <thecrypto> i am implementing a distributed IM, it's in the CVS
            
-
            [00:07] <beefbroth> I would vote against anything that is going to confuse people
            
-
            [00:08] <Ryan_Singer> AOL TimeWarner changed it's name to Time Warner
            
-
            [00:08] <ChZEROHag> beefbroth: I would too, but the vote to piss AOL off outweighs that.
            
-
            [00:08] <beefbroth> You want the system to be familiar enough that people won't be afraid to install it, but different enough to differentiate
            
-
            [00:08] <jrand0m> actually, thats a good point 
            
-
            [00:08] <thecrypto> I2PIM is the name of the application
            
-
            [00:08] <jrand0m> being transparently anonymous isn't useful if people don't understand what anonymous is. 
            
-
            [00:09] <ChZEROHag> Oh wait, I have something like this down on paper
            
-
            [00:09] <beefbroth> I like the crypto's idea
            
-
            [00:09] <thecrypto> what "network" I2PIM runs on is what I'm looking for
            
-
            [00:09] <jrand0m> teaching people how to protect themselves is a really important thing 
            
-
            [00:09] <thecrypto> i was thinking Presence System?
            
-
            [00:09] <Ryan_Singer> hypethe security aspect of anon
            
-
            [00:09] <dm> I2M (instant 2 messaging)
            
-
            [00:09] <ChZEROHag> Although I only called it XIrc
            
-
            [00:10] <jrand0m> you're the man thecrypto, whatever works for ya ;) 
            
-
            [00:10] <dm> and in the I2M logo, the 2 will be really small :)
            
-
            [00:10] <thecrypto> well I2P expands to Invisible ... jrand0m ?
            
-
            [00:10] <ChZEROHag> The main thing I liked about it was that everyone was called a Borg and they chatted in Collectives
            
-
            [00:10] <jrand0m> i2p = i^2p (invisible internet project) 
            
-
            [00:10] <co> I thought the P stands for protocol.
            
-
            [00:10] <jrand0m> that too 
            
-
            [00:10] <jrand0m> well, actually, no 
            
-
            [00:11] <thecrypto> so it's Invisible Internet Project Instant Messaging
            
-
            [00:11] <jrand0m> i2np is the protocol 
            
-
            [00:11] <jrand0m> i2p is the project 
            
-
            [00:11] <beefbroth> I thought it stood for "poop"
            
-
            [00:11] <jrand0m> i2cp is the client proto 
            
-
            [00:11] <co> thecrypto: You are right, the name does not matter too much.
            
-
            [00:11] <dm> i2m = i^2m = instant invisible messaging
            
-
            [00:11] <thecrypto> so next topic then
            
-
            [00:11] <Ryan_Singer> ok....so, we're drifting off agenda...are we done with IM?
            
-
            [00:11] <shardy> if "bob" isn't good enough, we can call it "jimbob"
            
-
            [00:11] <jrand0m> 0k, 6.0) administravia 
            
-
            [00:11] <thecrypto> no, still more here
            
-
            [00:12] <thecrypto> sorry
            
-
            [00:12] <co> It's administrivia.
            
-
            [00:12] <thecrypto> no it's IM
            
-
            [00:12] <jrand0m> nop> give me root.  I need to get anon cvs, bugzilla, and cvsweb installed. 
            
-
            [00:12] <thecrypto> i wasn't finished
            
-
            [00:12] <thecrypto> :)
            
-
            [00:12] <thecrypto> rewind!
            
-
            [00:12] * jrand0m backs up
            
-
            [00:12] <jrand0m> 5.1) thecrypto v2 
            
-
            [00:12] <Ryan_Singer> what else is there in IM, thecrypto?
            
-
            [00:13] <mihi> thecrypto: just talk on; /me idi it the same way as i missed the naming services
            
-
            [00:13] <thecrypto> okay, the thing about presences communicating is different
            
-
            [00:13] <thecrypto> not everyone knows everyone else
            
-
            [00:13] <thecrypto> there is practically no way to "stalk" someone
            
-
            [00:13] <thecrypto> you have to ask to be shown
            
-
            [00:14] <mihi> in anonymous networks, usually no one knows anyone else ;)
            
-
            [00:14] <jrand0m> (as long as people's Destination is random) 
            
-
            [00:14] *** Signoff: pitu (Lost terminal)
            
-
            [00:14] <dm> what do you mean?
            
-
            [00:14] <thecrypto> Alice wants to talk to Bob
            
-
            [00:14] <jrand0m> mihi> though the naming service allows search by service 
            
-
            [00:14] <jrand0m> (service being IM, www, etc) 
            
-
            [00:14] <thecrypto> Alice finds Bobs IM destination some how, prolly by the naming service
            
-
            [00:15] <thecrypto> So Alice sends a message to Bobs IM destination
            
-
            [00:15] <dm> yes?
            
-
            [00:15] <thecrypto> he gets a little message saying "Alice tried to contact you" if he wants to talk to her, he can, or he can ignore it
            
-
            [00:16] <thecrypto> but there is no central presence server, Alice can also just see her message disappear and not get a response
            
-
            [00:16] <dm> ok, like MSN then?
            
-
            [00:16] <jrand0m> (though Alice can know that Bob ignored her) 
            
-
            [00:16] <thecrypto> and Alice can't just put Bob on her buddy list and wait for him
            
-
            [00:16] <Ryan_Singer> thecrypto,  ok...how is this different then properly configured Y!, MSN or AIM..apart from the nocentral server bit
            
-
            [00:16] <thecrypto> because Bob has to send a message to Alice to see her sign on
            
-
            [00:16] <Ryan_Singer> oh
            
-
            [00:16] <dm> ok, it doesn't change anything as far as the user is concerned, but I see what you mean.
            
-
            [00:17] <jrand0m> thecrypto> not quite true 
            
-
            [00:17] <Ryan_Singer> got it..no buddylist functionality...
            
-
            [00:17] <jrand0m> oh, well, hmm, technically... 
            
-
            [00:17] <thecrypto> Ryan_Singer: no there is still a buddy list
            
-
            [00:17] <dm> how does alice send bob a message if she can't see him?
            
-
            [00:17] <dm> you just have to try random contacts in case they are there?
            
-
            [00:17] <jrand0m> bob has to send a message to alice's router, which can happen without alice knowing it 
            
-
            [00:17] <thecrypto> Alice can just randomly try
            
-
            [00:18] <dm> that's not very convenient? you go online and have to send everyone a message saying (you there?, you there?)
            
-
            [00:18] <beefbroth> thecrypto: can't a user "notify" all their buddies when they sign on by sending them a message? or is that what you were just saying
            
-
            [00:18] * co notes that there can be two Bobs registered with two different naming server groups.
            
-
            [00:18] <thecrypto> beefbroth: that was just want i'm saying
            
-
            [00:18] <dm> ok, so similar to current scheme but you are invisible by default.
            
-
            [00:18] <dm> gotcha.
            
-
            [00:19] <thecrypto> dm: no it's the other way around, when you sign on, you send a message to everyone saying "I'm on, I'm on" if you recieve a message saying "I'm on" you return it
            
-
            [00:19] <thecrypto> if you want to
            
-
            [00:19] <co> So the user controls who can see him/her/it.
            
-
            [00:19] <thecrypto> so Alice can put you on her buddy list and you'll get a message when she signs on saying "Alice has put you on her buddy list, would you like to notify her of your presece"
            
-
            [00:20] <Ryan_Singer> when you get off do you first send a msg that says "I'm getting off"?
            
-
            [00:20] <dm> ok, that's just a way to get around having a server, but the question is will the apps be setup by default to send a "I'm on" when someone logs on.
            
-
            [00:20] <Ryan_Singer> hopefully
            
-
            [00:20] <jrand0m> Ryan_Singer> or just have a periodic "I'm still on" ping 
            
-
            [00:20] <jrand0m> (and missing ping == off) 
            
-
            [00:21] <Ryan_Singer> keep-alive type deal?
            
-
            [00:21] <beefbroth> It might need to "ping" the other IM user every so often to make sure there wasn't an unintentional disconnect
            
-
            [00:21] <thecrypto> if Bob has Alice on his buddy list and Bob recives and Online message from Alice the return message is automatic
            
-
            [00:21] <beefbroth> heh
            
-
            [00:21] <thecrypto> If Bob doesn't have Alice on his buddy list and bob recives an online message from alice, the user is propmted
            
-
            [00:21] <dm> ok, so the IM experience is the same as it is now. Just wanted to confirm that.
            
-
            [00:22] <thecrypto> just you now have a confirm on buddy adds
            
-
            [00:22] <thecrypto> which i think only ICQ has
            
-
            [00:22] <jrand0m> will the IM app be a stand alone or will I be able to use trillian? 
            
-
            [00:22] <dm> yeah, that's how MSN works.
            
-
            [00:22] <jrand0m> [etc] 
            
-
            [00:22] <ChZEROHag> thecrypto: ICQ only pretends to require confirmation
            
-
            [00:22] <beefbroth> dm: wrong. you won't have to deal with MSN, Y! and AIM changing their protocols and locking people out every few months :)
            
-
            [00:23] <thecrypto> jrand0m: i'll make a spec, trillian can either give me a plugin interface or they can write thier own
            
-
            [00:23] <thecrypto> i will be writing a plugin for gaim at leasty
            
-
            [00:23] <thecrypto> along with a standalong client
            
-
            [00:23] <jrand0m> cool 
            
-
            [00:23] <thecrypto> which is built to be used with the network
            
-
            [00:23] <jrand0m> does gaim support file xfer or will that be the benefit of the i2pim client? 
            
-
            [00:23] <beefbroth> thecrypto: you might want to give a shout to the kopete developers just to let them know
            
-
            [00:23] * jrand0m shows his cluelessnesss
            
-
            [00:24] <thecrypto> i'll try to make the gaim plugin work as well as the standalong, but i don't know
            
-
            [00:24] <co> thecrypto: Let's have the standalone application first.
            
-
            [00:24] <thecrypto> gaim file transfer i think only works on AIM
            
-
            [00:24] <thecrypto> so it might take some wrangling to get it into a plugin
            
-
            [00:24] <Ryan_Singer> ok..I think we all understand this now...any more IM issues?
            
-
            [00:25] <thecrypto> and co's final thing
            
-
            [00:25] <beefbroth> gaim suffers problems with it's IM xfers for people using NAT
            
-
            [00:25] <thecrypto> more than one person can have the same name
            
-
            [00:25] <thecrypto> they will have unique destinations
            
-
            [00:25] *** Signoff: mihi (Ping timeout)
            
-
            [00:25] <co> All right.
            
-
            [00:25] * mihi_backup is still here...
            
-
            [00:25] <thecrypto> but someone can't masquerde
            
-
            [00:26] <jrand0m> heh nice1 mihi_backup 
            
-
            [00:26] <co> If you use the naming server, it will be "Bob from group1" and "Bob from group2".
            
-
            [00:26] <co> With unique destinations.
            
-
            [00:26] <jrand0m> right thecrypto.  names are arbitrary.  kind of like dns ;) 
            
-
            [00:26] *** mihi (~none@anon.iip) has joined channel #iip-dev
            
-
            [00:26] <thecrypto> also the IM client itself can optionally check "Hey, this IM you got was from someone called Bob, the destination of the Bob in your list is different, accept message?"
            
-
            [00:27] <dm> mihi: your backup talked while you were gone.
            
-
            [00:27] <thecrypto> if they person is trying to masquerde Bob, you'll know, otherwise, you can alias them out
            
-
            [00:27] <mihi> i know...
            
-
            [00:27] <jrand0m> "someone called bob"?  says who?  they call themself bob?  or some group calls them bob?  or you call their dest bob? 
            
-
            [00:27] <thecrypto> there is a feild in the presence called name
            
-
            [00:27] <thecrypto> i'm looking at that
            
-
            [00:28] * jrand0m likes the way ICQ works with that problem - everyone is a number and you just alias numbers locally to names
            
-
            [00:28] <co> As an aside, should I make the NS entity names case insensitive?
            
-
            [00:28] <jrand0m> probably co 
            
-
            [00:28] <mihi> base64 things must be case sensitive still ;)
            
-
            [00:28] * jrand0m doesn't want people spoofing Jrand0m
            
-
            [00:28] <co> mihi: Entity names, not destinations.
            
-
            [00:28] <jrand0m> right right mihi 
            
-
            [00:29] <jrand0m> (well, people can spoof jrand0m all they want.  I just want jrandom back) 
            
-
            [00:29] <co> Go on, thecrypto.
            
-
            [00:29] *** Signoff: UserX_ (Ping timeout)
            
-
            [00:29] <thecrypto> that's all i have
            
-
            [00:29] <thecrypto> finally :)
            
-
            [00:29] <mihi> co: you should be able to place a destination wherever you can place an entity name.
            
-
            [00:29] <mihi> like it is with dns names and IPs
            
-
            [00:29] <co> mihi: Good point. I will add that to the specification.
            
-
            [00:29] <thecrypto> jrand0m: actully it's kinda like ICQ except you tell people what you'd like your alias to be
            
-
            [00:30] <thecrypto> which i think they do now
            
-
            [00:30] <co> The idea, though, is that it will be much shorter to type names than destinations.
            
-
            [00:30] <jrand0m> mihi> the naming service only turns names to destinations - if you ask the naming service for the destination of a destination, it should return really really quickly 
            
-
            [00:30] <Ryan_Singer> ok guys...I have a meeting... jrand0m, anonymail me
            
-
            [00:30] <jrand0m> 'k adios 
            
-
            [00:30] <mihi> jrand0m: yes, and it should return that dest itself, and not "not found"
            
-
            [00:31] <jrand0m> right 
            
-
            [00:31] *** Signoff: Ryan_Singer ((null))
            
-
            [00:31] <jrand0m> ok.  we're at 7.0)  
            
-
            [00:31] <jrand0m> questions 
            
-
            [00:31] <jrand0m> hi 
            
-
            [00:31] <co> What about 6.0) Administrivia?
            
-
            [00:32] <co> Or were you done with that?
            
-
            [00:32] <jrand0m> 6.0 administravia was just me nagging nop to give me root to get y'all: anon cvs access, bugzilla, and a cvsweb interface :) 
            
-
            [00:32] <beefbroth> are there going to be owners to work on packaging the alpha, beta and releases for Win/Mac/SuSE/RehHat/Debian to speed up adoption?
            
-
            [00:33] <jrand0m> you volunteering? 
            
-
            [00:33] <jrand0m> (aka yeah, that'd be great) 
            
-
            [00:33] <beefbroth> If I learn how to make a package for my distribution :)
            
-
            [00:33] <jrand0m> what distro do you use? 
            
-
            [00:34] <co> As I recall, the IIP developers wanted to reimplement IIP over I2P. If I2P delivers on its promises of anonymity, will it not be simpler to just have IRC over I2P?
            
-
            [00:34] <beefbroth> But my point is, alot of people rely on those. It would make it easier for people to adopt. Freenet suffers from a lack of active maintainers.
            
-
            [00:34] <dm> jr makes for a good manager :)
            
-
            [00:34] <jrand0m> yes co, simpler, but not as scalable 
            
-
            [00:34] *** UserX_ (~User@anon.iip) has joined channel #iip-dev
            
-
            [00:34] <thecrypto> yes, but some people don't want IRC
            
-
            [00:35] <jrand0m> beefbroth> you're absolutely right, there's a lot of work to do, and I need to sleep at least 4 hours a night 
            
-
            [00:35] <co> thecrypto: Good point, though I2P will anonymize people's IP addresses.
            
-
            [00:35] <beefbroth> jrand0m: i can help package when things are ready. I think that's a great way some non-developers with a bit of technical expertise can contribute.
            
-
            [00:35] <jrand0m> awesome beefbroth 
            
-
            [00:35] <thecrypto> if we have IM and IRC, more adoption
            
-
            [00:36] <mihi> co: the problem is that with irc there is something to shut down (servers).
            
-
            [00:36] *** jeremiah (~jeremiah@anon.iip) has joined channel #iip-dev
            
-
            [00:36] <jrand0m> thecrypto> instant adoption: opennap 
            
-
            [00:36] <beefbroth> it's easier to learn to make packages than to learn i2p datastructures. it's an easy way for a few people to get involved
            
-
            [00:36] <dm> IRC is quite tough though isn't it?
            
-
            [00:36] <dm> distributed IRC that is...
            
-
            [00:36] <co> mihi: Of course. I forgot that. Thank you for reminding me. Objection withdrawn.
            
-
            [00:37] <jrand0m> dm> irc can have multiple irc servers (ala efnet, etc) that talk to each other through i2p 
            
-
            [00:37] <shardy> do you mean an "irc lookalike" chat protocol?
            
-
            [00:37] <shardy> or adapting irc?
            
-
            [00:37] <jrand0m> with people talking to each other by tunneling to one of the irc servers via i2p 
            
-
            [00:37] <dm> irc with servers behind i2p is fine, I'm saying without servers. Doesn't matter I guess.
            
-
            [00:38] <jrand0m> dm> right, it can be done much better without servers, and some thought has been put into it, but nothing really solid (to my knowledge) 
            
-
            [00:39] <dm> anyway, it's off-topic.
            
-
            [00:39] <dm> carry on!
            
-
            [00:39] <jrand0m> any other questions?   
            
-
            [00:39] <jrand0m> anyone read the specs yet?  ;) 
            
-
            [00:39] <jrand0m> (other than beefbroth, who has them memorized) 
            
-
            [00:39] * dm looks at the ceiling.
            
-
            [00:40] <jrand0m> ok, 100 minute meeting it is then 
            
-
            [00:40] <thecrypto> i'm reading the, when i need something :)
            
-
            [00:40] <ChZEROHag> specs!
            
-
            [00:40] <ChZEROHag> That's what I forgot!
            
-
            [00:40] <jrand0m> heh 
            
-
            [00:41] *** dm has changed the topic on channel #iip-dev to topic1
            
-
            [00:41] * jrand0m loads up and...
            
-
            [00:41] * jrand0m *baf*s the meeting to an end
            
-
            {% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting60.html b/www.i2p2/pages/meeting60.html
deleted file mode 100644
index f67aec94..00000000
--- a/www.i2p2/pages/meeting60.html
+++ /dev/null
@@ -1,279 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 60{% endblock %}
-{% block content %}
            
-
            [22:53] <jrand0m> 0.x) welcome 
            
-
            [22:53] <jrand0m> 1.x) todo before i2p 0.2: 
            
-
            [22:53] <jrand0m> 1.1) bw limiting 
            
-
            [22:54] <jrand0m> 1.2) AES the tcp transport 
            
-
            [22:54] <jrand0m> 1.3) package up [distro, building, seeding, running] 
            
-
            [22:54] <jrand0m> 1.4) ElG session ack discussion 
            
-
            [22:54] * hezekiah is away: Is off eating to keep up is strength for his upcoming tests
            
-
            [22:54] <jrand0m> 2.x) apps 
            
-
            [22:54] <jrand0m> 2.1) ns 
            
-
            [22:54] <jrand0m> 2.2) i2pim 
            
-
            [22:54] <jrand0m> 2.3) i2ptunnel 
            
-
            [22:54] <jrand0m> 3.x) ??? 
            
-
            [22:54] <jrand0m> 0.x) welcome 
            
-
            [22:54] <jrand0m> welcome to meeting 60 
            
-
            [22:54] <dm> thanks
            
-
            [22:55] <mihi> oh. 60. whe have something to celebrate ;)
            
-
            [22:55] * jrand0m hands out some beers
            
-
            [22:55] *** wiht (anon@anon.iip) has joined channel #iip-dev
            
-
            [22:55] * mihi does not like alcohol
            
-
            [22:55] <thecrypto> hi
            
-
            [22:55] * jrand0m takes back the german beer
            
-
            [22:55] <thecrypto> i'm not awake
            
-
            [22:55] <mihi> but not asleep either ;)
            
-
            [22:55] <jrand0m> heh interesting 
            
-
            [22:56] <jrand0m> ok, 1.{x,1}) todo before 0.2 
            
-
            [22:56] <thecrypto> i just remembered the meeting it today
            
-
            [22:56] <thecrypto> i was just discussing wireless cards
            
-
            [22:56] <jrand0m> the router is in pretty good shape, and I think 0.2 will be ready for internal dist and testing 
            
-
            [22:57] *** Signoff: mihi (EOF From client)
            
-
            [22:57] <jrand0m> there are three things that need to get implemented first though.  bandwidth limiting, AES on the TCP, and ElG session ack 
            
-
            [22:57] <jrand0m> the bandwidth limiting will be classless for the moment - just one big honking input limit and output limit. 
            
-
            [22:58] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [22:58] <jrand0m> the code is committed to tie it in, but the limit is set at infinity atm 
            
-
            [22:58] <jrand0m> for point 1.2, the TCP transport has key exchange and authentication, but needs encryption 
            
-
            [22:59] <jrand0m> nop/semi-awake-thecrypto> thoughts on AES for streaming?   
            
-
            [22:59] <thecrypto> carefully
            
-
            [22:59] <jrand0m> !thwap 
            
-
            [22:59] <thecrypto> sorry
            
-
            [23:00] * CounterRev eats popcorn in the grand stands
            
-
            [23:00] <jrand0m> CBC using first 16 bytes of H(sessionKey) work, or should we do something else? 
            
-
            [23:00] <dm> I can't remember where that originated, exclamation mark before an action.
            
-
            [23:00] <thecrypto> i realized when the agenda started being pasted today was tuesday
            
-
            [23:00] <jrand0m> dm> some eggdrops use them as command identifiers 
            
-
            [23:01] <thecrypto> why not use more bits from the DH for that?
            
-
            [23:01] <jrand0m> hmm? 
            
-
            [23:01] <thecrypto> i don't see any problem for that
            
-
            [23:01] <thecrypto> for the IV
            
-
            [23:01] <jrand0m> more bits of what?  X, Y, x, y? 
            
-
            [23:02] *** mihi (mihi@anon.iip) has joined channel #iip-dev
            
-
            [23:02] <thecrypto> K
            
-
            [23:02] <dm> !thwap thecrypto
            
-
            [23:02] <thecrypto> what?
            
-
            [23:02] <dm> he said X,Y,x or y
            
-
            [23:02] <jrand0m> AES 256 only has a 16 byte K 
            
-
            [23:02] <jrand0m> er, IV 
            
-
            [23:03] <jrand0m> the session key is 32 bytes 
            
-
            [23:03] <thecrypto> but you generate many more
            
-
            [23:03] <jrand0m> (originally I was stupid and made the IV the first 16 bytes of the key ;) 
            
-
            [23:03] <thecrypto> so use 48 bytes from the DH
            
-
            [23:04] <dm> we all make mistakes.
            
-
            [23:04] <jrand0m> hmm ok, pulling more bytes off the modPow will work.  cool.  but why 48?   
            
-
            [23:04] <jrand0m> (why not just another 16?) 
            
-
            [23:05] <thecrypto> i meant 32+16
            
-
            [23:05] <jrand0m> ah 'k 
            
-
            [23:06] <jrand0m> ok cool, CBC with that.  if you or nop or someone else has time (userx?), we can get rekeying / rotating keys in there.  but for the moment I'll get it CBC'ed w/ that IV 
            
-
            [23:06] <jrand0m> (rekey would be just drop the connection and re-DH) 
            
-
            [23:06] <jrand0m> ok, 1.3) packaging up for 0.2 
            
-
            [23:07] <jrand0m> that just means a make / ant script, install / build doc, plus a method for distributing seed routerInfo references  
            
-
            [23:07] <jrand0m> (plus, most likely, a set of a few routers for people to connect to) 
            
-
            [23:08] <jrand0m> I hope to have 0.2 out and ready for people to d/l and install by this time next week, if not sooner 
            
-
            [23:09] <jrand0m> the one last point holding up 0.2 is the ElG session ack 
            
-
            [23:09] <dm> can we use 0.2 to talk to each other?
            
-
            [23:09] <jrand0m> yes dm 
            
-
            [23:09] <dm> ok, that's useful.
            
-
            [23:10] <mihi> dm: is talking with you really useful? *veg*
            
-
            [23:10] <dm> (Killer App: Cyber Sex)
            
-
            [23:10] <jrand0m> 0.2 is definitely not even alpha, so it won't be for the faint of heart 
            
-
            [23:10] <jrand0m> heh 
            
-
            [23:10] <jrand0m> (but we need to get some testing and experience on some platforms and usage patterns other than my xp box here) 
            
-
            [23:11] <dm> I'll take care of the marketing for I2P, I have a knack for it.
            
-
            [23:11] <jrand0m> lol 
            
-
            [23:11] <dm> 0.2 code name: CyberSex, features, anonymous CyberSex through text.
            
-
            [23:11] <jrand0m> ok, the ElG session ack stuff.   
            
-
            [23:11] <wiht> I can test on FreeBSD and Gentoo Linux.
            
-
            [23:11] <jrand0m> awesome wiht! 
            
-
            [23:11] * popopopo can test Debian
            
-
            [23:11] <jrand0m> nice 
            
-
            [23:12] <thecrypto> i can test on mandrake
            
-
            [23:12] * dm can test windows XP
            
-
            [23:12] <jrand0m> damn we're going to have pretty good coverage :) 
            
-
            [23:12] * dm stands out from the crowd.
            
-
            [23:12] <popopopo> I can test win2k as well I think, although that should be about the same as XP I think
            
-
            [23:12] <jrand0m> hopefully 
            
-
            [23:12] <dm> stick to unix popopopo
            
-
            [23:13] * thecrypto plays the trump: I can test win 98 :)
            
-
            [23:13] <jrand0m> uuuugh 
            
-
            [23:13] * dm welcomes his little brother to the crowd.
            
-
            [23:13] <popopopo> I have an old DOS disk around here. Will java run on that? :)
            
-
            [23:13] <wiht> popopopo: Probably not.
            
-
            [23:13] <jrand0m> actually, probably. 
            
-
            [23:14] <jrand0m> since gcc supports java 
            
-
            [23:14] <jrand0m> and djgpp runs on dos 
            
-
            [23:14] <popopopo> I2P on DOS, now that would be an accomplishment
            
-
            [23:14] <mihi_backup> popopopo: there is a commercial java version for DOS ;)
            
-
            [23:14] * jrand0m is currently hacking around with gjc to see if we can compile to native
            
-
            [23:14] <dm> Getting PPP working on DOS would be accomplishment enough.
            
-
            [23:14] <mihi> dm: use arachne.
            
-
            [23:15] <popopopo> gcj
            
-
            [23:15] <mihi> should work via parallel modem.
            
-
            [23:15] <nop> oh shit
            
-
            [23:15] <nop> it's tuesday
            
-
            [23:15] <nop> haha
            
-
            [23:15] <jrand0m> ah right popopopo... I always type it wrong 
            
-
            [23:15] <mihi> oops, serial modem ;)
            
-
            [23:15] <jrand0m> wb nop ;) 
            
-
            [23:15] <thecrypto> nop: you and me both
            
-
            [23:15] <nop> haha
            
-
            [23:16] <nop> sorry
            
-
            [23:16] <nop> my brain is fried this week
            
-
            [23:16] <nop> re-cooping
            
-
            [23:16] <nop> from this weekend
            
-
            [23:16] <thecrypto> nop: you and me both
            
-
            [23:16] <jrand0m> ok, the ElG ack stuff. 
            
-
            [23:16] <jrand0m> (take 4) 
            
-
            [23:16] * CounterRev could test xp as well "its running.. its running... its stopped"
            
-
            [23:17] <jrand0m> right now the ElG+AES works by using session tags - 32 byte tags prepended to AES streams to identify what session key to decrypt with 
            
-
            [23:17] <mihi> and "it's bluescreened, it's autorebooting"
            
-
            [23:17] <jrand0m> (these tags are distributed in the streams, and the session keys are distributed in the ElG) 
            
-
            [23:18] <jrand0m> the problem comes up if we lose the first ElG+AES, we've lost the session key as well as the initial set of session tags 
            
-
            [23:18] <thecrypto> brb, playing magic
            
-
            [23:18] <jrand0m> so we need to make sure messages use ElG instead of AES with a session tag unless we know for sure the session key has been received 
            
-
            [23:19] <jrand0m> there are lots of optimizations and tradeoffs here - one could always ElG and just forget about acks 
            
-
            [23:19] <jrand0m> (trading cpu for bandwidth) 
            
-
            [23:19] <jrand0m> or one could always require an ack for the first block, and then AES 
            
-
            [23:20] <jrand0m> but that breaks if the recipient crashes and loses the session key 
            
-
            [23:20] * nop is backlogging
            
-
            [23:20] <jrand0m> there are a few different patterns that can be used to implement these sessions 
            
-
            [23:21] <jrand0m> what I'm probably going to go with is requiring an ack for the ElG message, using AES from then on, but every {$timeperiod, numMessages, bytes} send another ElG 
            
-
            [23:22] <dm> like P frames in MPEG!
            
-
            [23:22] <jrand0m> 'k, I dont know the MPEG standard really 
            
-
            [23:22] <dm> sorry, I frames.
            
-
            [23:23] <jrand0m> the thing is, these ElG messages are expensive.  ~0.5-1.0 seconds 
            
-
            [23:23] <jrand0m> (cpu time) 
            
-
            [23:23] <jrand0m> though, hmm, we could precalculate them 
            
-
            [23:23] <jrand0m> (if we don't rotate session keys) 
            
-
            [23:23] <mihi> which cpu? ;)
            
-
            [23:23] <dm> sender or reciever cpu time?
            
-
            [23:24] <jrand0m> exactly mihi - mine.  p4 1.7g.  so we need some perf tuning on the algorithm 
            
-
            [23:24] <jrand0m> both dm 
            
-
            [23:24] <jrand0m> (.5 encrypt, .5 decrypt) 
            
-
            [23:24] <jrand0m> (hand wavey approx) 
            
-
            [23:24] * mihi has celeron 700
            
-
            [23:24] * dm has PIII 850
            
-
            [23:24] <jrand0m> cool.  I'm also getting a sun ultra1 (150Mhz) in a few weeks 
            
-
            [23:25] <dm> Why you getting a SUN?
            
-
            [23:25] <jrand0m> I'm leaving the option open for reevaluating our ElG keysize if we need to 
            
-
            [23:26] <jrand0m> dm> its free (you can buy a u1 for ~50-100 USD).  I also have a few sparc for various purposes 
            
-
            [23:26] <dm> sweet.
            
-
            [23:27] <jrand0m> ok, unless anyone has any comments on the ElG stuff, on to agenda item 2.x... 
            
-
            [23:27] <jrand0m> ok, 2.x) apps 
            
-
            [23:27] <jrand0m> 2.1) ns 
            
-
            [23:27] <jrand0m> wiht, how goes? 
            
-
            [23:28] *** Signoff: mihi_backup (Ping timeout)
            
-
            [23:30] <wiht> I have not done any coding on the naming server this past week.
            
-
            [23:30] <wiht> I should say "of" the naming server.
            
-
            [23:31] <jrand0m> 'k, understandable.. what do you think your schedule looks like for the next few weeks for implementation?  no committment or anything, just wondering 
            
-
            [23:31] <wiht> But I will be working on it this week, and should have something more to report during the next meeting.
            
-
            [23:31] <jrand0m> cool, great 
            
-
            [23:31] <CounterRev> what is i2p like sans ns?
            
-
            [23:32] <jrand0m> icq, I suppose 
            
-
            [23:32] <wiht> I should be less busy during the next few weeks, and will have time for this. I cannot say when the naming server will be completed at this time.
            
-
            [23:32] <jrand0m> you need the secret number for contacting someone, but once you have it, you're ok 
            
-
            [23:33] <mihi> CounterRev: lots of very long destination keys...
            
-
            [23:33] <jrand0m> CounterRev> I suspect someone will install a squid and an i2ptunnel on their router, allowing people to point at the destination and browse the web anonymously 
            
-
            [23:33] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [23:33] <jrand0m> ok, 2.2) i2pim... 
            
-
            [23:33] <jrand0m> thecrypto> you still playing magic?   
            
-
            [23:34] <dm> i2pim, is that the name of the IM app?
            
-
            [23:34] <jrand0m> yup 
            
-
            [23:34] <wiht> dm: Yes.
            
-
            [23:34] <dm> crap! i2m, Invisible Instant messaging.
            
-
            [23:34] <dm> i^2m, just like i^2p!
            
-
            [23:34] <jrand0m> sounds like there's a market 
            
-
            [23:35] <mihi> dm: we had that discussion last meeting...
            
-
            [23:35] <dm> fine fine... I'll have to live with it.
            
-
            [23:36] <jrand0m> ok, thecrypto is probably still off.  he'll post to the list if there's any news on the i2pim 
            
-
            [23:36] <jrand0m> (i hope) 
            
-
            [23:36] <jrand0m> ok, 2.3) i2ptunnel 
            
-
            [23:36] * jrand0m waves to mihi
            
-
            [23:37] <wiht> jrand0m: I see that we have three applications being developed at this time. Have others been proposed?
            
-
            [23:37] <mihi> oops...
            
-
            [23:37] <mihi> but i have nothing to tell anyway ;)
            
-
            [23:37] <mihi> i2p is in cvs; look @ it ;)
            
-
            [23:37] <dm> mihi speaks in code.
            
-
            [23:38] <jrand0m> heh word.  any updates since you added that config> command? 
            
-
            [23:38] <dm> or rather, his code speaks for itself.
            
-
            [23:38] <mihi> i2ptunnel is in cvs i mean...
            
-
            [23:38] * nop proposes ex-lax for i2p
            
-
            [23:38] <mihi> jrand0m: nope.
            
-
            [23:38] <jrand0m> coo' 
            
-
            [23:38] <jrand0m> would that be like a LaTeX clone nop? 
            
-
            [23:39] <jrand0m> wiht> some various discussions, but those three have been the main ones discussed 
            
-
            [23:39] <jrand0m> (the i2ptunnel enables a shitload of normal apps to operate over it) 
            
-
            [23:40] <dm> has it been tested with anything?
            
-
            [23:40] <mihi> i2ptunnel has been tested extensively with the local router.
            
-
            [23:40] <dm> (not locally)
            
-
            [23:40] <jrand0m> I've done some web browsing with it, as well as ssh 
            
-
            [23:40] <jrand0m> (browsing a single site, that is) 
            
-
            [23:41] * wiht wonders if that website can still track people through cookies.
            
-
            [23:41] <dm> great.
            
-
            [23:41] <jrand0m> sure wiht, cookies are still sent  
            
-
            [23:43] <jrand0m> ok, thats it for apps atm, and on to 3.x) ??? 
            
-
            [23:43] <jrand0m> any questions, thoughts, concerns, toenail clippers, hedgehogs? 
            
-
            [23:43] <mihi> a pony? ;)
            
-
            [23:43] <jrand0m> yeah, I want a pony! 
            
-
            [23:43] * dm raises his glass.
            
-
            [23:43] <mihi> nop will give you onw...
            
-
            [23:43] <dm> TO 0.2!!!
            
-
            [23:44] <jrand0m> oh yeah, mihi pointed out that in 17 minutes we miss the deadline I set in my flog a month ago 
            
-
            [23:44] <jrand0m> to 1.0! 
            
-
            [23:45] <mihi> 7 minutes ;)
            
-
            [23:45] <dm> so 2 weeks from now, we'll have 20 people on the network who'll be able to send texts to each other?
            
-
            [23:45] <jrand0m> I said we'd have an alpha out by end of september.  well, it looks like we'll be a little late on that, but I think we're still making a good pace 
            
-
            [23:45] <jrand0m> yes dm (and files, etc) 
            
-
            [23:45] <nop> sickening
            
-
            [23:45] <jrand0m> there will still be room for performance improvements, of course.  there hasn't been much tuning at all 
            
-
            [23:45] <nop> sorry, I already spent my budget the next month
            
-
            [23:45] <dm> Alrighty, well if that happens, I will applaud.
            
-
            [23:45] <nop> pony has to wait
            
-
            [23:46] <jrand0m> damnit! 
            
-
            [23:46] <nop> bought a grand piano instead
            
-
            [23:46] <nop> ;)
            
-
            [23:46] <jrand0m> heh nice 
            
-
            [23:47] <mihi> jrand0m: here are some virtual ponies for you: (Link: http://tinyurl.com/p8kx)http://tinyurl.com/p8kx
            
-
            [23:47] <dm> estimated latency?
            
-
            [23:47] <dm> with network < 30 nodes?
            
-
            [23:48] <jrand0m> dm> depends on the sender and receiver's tunnel length 
            
-
            [23:48] <dm> order of magnitude.
            
-
            [23:48] <jrand0m> (e.g. if they have 0 length tunnels, it'll be approx 400ms) 
            
-
            [23:49] <dm> 0 length tunnels, don't know how I2P works, but 0 length doesn't sound good ;)
            
-
            [23:49] <mihi> or (Link: http://tinyurl.com/p8l7)http://tinyurl.com/p8l7
            
-
            [23:49] <jrand0m> if they have 2 hop tunnels, the latency should be ~ 1s 
            
-
            [23:49] <dm> alrighty.
            
-
            [23:49] <dm> throughput?
            
-
            [23:50] <dm> harder to estimate?
            
-
            [23:50] <jrand0m> depends on bandwidth 
            
-
            [23:51] <dm> Say X is the non I2P bandwidth between 2 nodes, through all the hops I2P uses.
            
-
            [23:51] <dm> what is the equation for Y(X) where Y is the throughput of I2P from one node to the other.
            
-
            [23:51] <jrand0m> I2P doesn't add a significant overhead to the size of the data 
            
-
            [23:52] <dm> alrighty.
            
-
            [23:52] <dm> wait and see I guess.
            
-
            [23:53] <jrand0m> once she's up and running, we'll definitely get some modeling going on 
            
-
            [23:53] <dm> aye..
            
-
            [23:54] * dm raises his glass.
            
-
            [23:54] <dm> To women!
            
-
            [23:54] <mihi> dm: you forgot to lower it first ;)
            
-
            [23:55] <dm> You germans...
            
-
            [23:55] <dm> You wacky germans.
            
-
            [23:55] <jrand0m> ok, I think thazzabout it 
            
-
            [23:55] <dm> It's no suprise an american is leading us into the 21st century of anonymous networking.
            
-
            [23:55] * mihi /igs dm
            
-
            [23:55] <jrand0m> american? 
            
-
            [23:56] <mihi> jrand0m is spanish i guess.
            
-
            [23:56] <dm> I was referring to you!
            
-
            [23:56] <mihi> or italian or sth in CET timezone.
            
-
            [23:56] <dm> jrand0m, the quiet american.
            
-
            [23:56] <wiht> dm: jrand0m seems to be a European.
            
-
            [23:56] <dm> !thwap mihi
            
-
            [23:57] <dm> !thwap wiht
            
-
            [23:57] <dm> jrand0m: your team members don't know you well.
            
-
            [23:58] * jrand0m thinks dm has been drinkin a lil too much, but its time for me to do the same. 
            
-
            [23:58] * jrand0m raises the *baf*...
            
-
            [23:58] <dm> nice try jr!
            
-
            [23:58] * jrand0m *baf*s the meeting away
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting61.html b/www.i2p2/pages/meeting61.html
deleted file mode 100644
index 2cb27e1b..00000000
--- a/www.i2p2/pages/meeting61.html
+++ /dev/null
@@ -1,82 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 61{% endblock %}
-{% block content %}
            
-
            [23:04] <jrand0m> 0.0) welcome 
            
-
            [23:04] <jrand0m> 1.0) dev status 
            
-
            [23:04] <jrand0m> 2.0) new server 
            
-
            [23:04] <jrand0m> 3.0) questions? 
            
-
            [23:04] <jrand0m> 0.0) welcome to the 61st iip meeting 
            
-
            [23:04] <jrand0m> hi. 
            
-
            [23:04] <mihi> hi all
            
-
            [23:04] <dm> hi you two ;)
            
-
            [23:04] <jrand0m> ok, 1.0) dev status 
            
-
            [23:05] <jrand0m> we're pretty much ready for 0.2 - which is where people would be able to run i2p.   
            
-
            [23:06] <dm> great!
            
-
            [23:06] <dm> ETA?
            
-
            [23:06] <jrand0m> it won't scale, and it is currently implemented with the insanely secure style of the ElG+AES (rather than the optimized w/ session tags) 
            
-
            [23:06] <jrand0m> eta: a few days (related point: agenda item 2.0) 
            
-
            [23:07] <jrand0m> but it will be functional.  I'm able to send messages of 10 bytes as well as 100K in ~10s 
            
-
            [23:07] <jrand0m> (both on the same CPU, so its cpu contention) 
            
-
            [23:07] <jrand0m> still some tunnel failback I'm working through, then its time to build the ant scripts, etc 
            
-
            [23:07] <jrand0m> actually 
            
-
            [23:08] <jrand0m> a few seconds ago I built everything using Kaffe 1.1.1 on freebsd with not even a warning. 
            
-
            [23:08] * jrand0m <3 not having to make changes to code
            
-
            [23:08] <mihi> but it wasn't working either, was it? ;)
            
-
            [23:08] <jrand0m> heh 
            
-
            [23:09] <jrand0m> no, it works 
            
-
            [23:09] <jrand0m> the prob I'm working through is a failover (aka if one is shut down and starts back up, comm recovers cleanly) 
            
-
            [23:10] <mihi> have you tried to send a complete ASCII table (bytes 0x00 to 0xFF)? And does it appear as it should on the other end?
            
-
            [23:10] <jrand0m> not yet, havent tried i2ptunnel yet either.  but shall tonight 
            
-
            [23:10] <mihi> try i2ptunnel with a binary connection (like ssh), no text based one.
            
-
            [23:11] <jrand0m> 'k 
            
-
            [23:11] <mihi> what if a node shuts down and does not come up again?
            
-
            [23:11] <jrand0m> then communication with it will fail ;) 
            
-
            [23:12] <jrand0m> (guaranteed delivery now fails correctly and the SDK has been patched to act on that) 
            
-
            [23:13] <jrand0m> ok, thats it for status atm.  I've been pulled in other directions for the last two days, but that should be quieting down shortly. 
            
-
            [23:13] <jrand0m> 2.0) new server 
            
-
            [23:13] <jrand0m> we have a new server on a triple homed T3.   
            
-
            [23:14] <jrand0m> its going to host webcvs, a default i2p router, a webserver with seed router references, and a few default services (e.g. an i2p tunnel pointing at a squid instance, an i2ptunnel pointing at cvs, an i2ptunnel pointing at a webserver) 
            
-
            [23:15] *** Signoff: mihi (EOF From client)
            
-
            [23:15] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [23:15] <jrand0m> i'll also be tossing on a public isproxy later 
            
-
            [23:15] <dm> damn, how much is that costing you?
            
-
            [23:15] <jrand0m> 65/mo 
            
-
            [23:15] <jrand0m> 40Gb transfer, 2Gb data 
            
-
            [23:15] <dm> bandwidth limit?
            
-
            [23:15] <dm> cool.
            
-
            [23:16] *** mihi_ is now known as mihi
            
-
            [23:16] <jrand0m> perhaps that server will become our cvs, but no need to switch right now.   
            
-
            [23:16] <jrand0m> ok, 3.0) questions 
            
-
            [23:17] <jrand0m> [yes, this has been the fastest meeting I've ever seen ;)] 
            
-
            [23:17] <mihi_backup> do you know anything about naming service progress?
            
-
            [23:17] <jrand0m> I hear wiht has committed a few files, but I haven't checked them out yet 
            
-
            [23:17] <dm> I'd like to offer my (mental) support to all the developers. Stay humble yet determined.
            
-
            [23:18] <mihi_backup> they are only dummies afaik.
            
-
            [23:18] <jrand0m> clueless wankers, for sure. 
            
-
            [23:18] <mihi_backup> interfaces to implement against.
            
-
            [23:18] <dm> dummies?
            
-
            [23:18] <jrand0m> lol 
            
-
            [23:19] <dm> ah
            
-
            [23:19] * jrand0m extends MyParents
            
-
            [23:19] <mihi_backup> java does not allow multiple inheritance ;)
            
-
            [23:19] <dm> no bastards...
            
-
            [23:20] * jrand0m implements MyDad, MyMom // just seems wrong
            
-
            [23:20] <mihi_backup> although you do not extend either your mother nor your father (see the liskov (sp?) substitution principle)
            
-
            [23:20] * dm implements jrandom'sMom
            
-
            [23:20] <dm> ;)
            
-
            [23:20] <jrand0m> oh, good point mihi 
            
-
            [23:20] * dm now implements mihi'smother
            
-
            [23:20] <jrand0m> heh 
            
-
            [23:21] *** Signoff: mihi (Ping timeout)
            
-
            [23:21] <mihi_backup> you just need a constructor public Human(Human father, Human mother) throws SameSexException
            
-
            [23:22] <dm> nice one
            
-
            [23:22] <jrand0m> I think modern science requires a few more constructors 
            
-
            [23:22] <dm> although it's not public
            
-
            [23:22] <dm> it's pubic
            
-
            [23:22] *** mihi (mihi@anon.iip) has joined channel #iip-dev
            
-
            [23:22] <dm> I crack myself up.
            
-
            [23:23] <jrand0m> ok, on that note 
            
-
            [23:23] <jrand0m> I think we've just gotten away with a 23 minute meeting :) 
            
-
            [23:23] * jrand0m slips the *baf*er out of my back pocket and *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting62.html b/www.i2p2/pages/meeting62.html
deleted file mode 100644
index edf7ec73..00000000
--- a/www.i2p2/pages/meeting62.html
+++ /dev/null
@@ -1,288 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 62{% endblock %}
-{% block content %}
            
-
            [23:01] <jrand0m> agenda 
            
-
            [23:01] <jrand0m> 0) welcome 
            
-
            [23:01] <jrand0m> 1) 0.2 status 
            
-
            [23:01] <jrand0m> 2) www proxy 
            
-
            [23:01] * dm ponders.
            
-
            [23:02] <dm> oh, meeting?
            
-
            [23:02] <jrand0m> 3) phttprelay 
            
-
            [23:02] <jrand0m> 4) i2ptunnel 
            
-
            [23:02] <jrand0m> 5) installation 
            
-
            [23:02] <dm> sorry.
            
-
            [23:02] <jrand0m> 6) iip feature request 
            
-
            [23:02] <jrand0m> 7) ??? 
            
-
            [23:02] <jrand0m> 0) welcome  
            
-
            [23:02] <jrand0m> hi. 
            
-
            [23:02] <jrand0m> meeting 62? is it? 
            
-
            [23:02] <Dellammo> hi
            
-
            [23:02] <jrand0m> (no worry dm, we can forgive you) 
            
-
            [23:02] <mihi> hi jrand0m
            
-
            [23:02] <dm> hi mihi
            
-
            [23:02] * mihi thinks so
            
-
            [23:03] <jrand0m> 1) 0.2 status 
            
-
            [23:03] * jrand0m has had a severe case of feature-creep-itis as of late, so the 0.2 release still has about 30 minutes left of code left to do.
            
-
            [23:04] <jrand0m> but then we'll be able to run and communicate reliably regardless of NAT, firewall, or HTTP proxy. 
            
-
            [23:04] * dm has just created I2PSecureRemoteShell 1.0
            
-
            [23:04] <dm> cool jr!
            
-
            [23:05] <jrand0m> everything is functional, the only thing left to do is to expire unused database entries after N minutes (probably 5 for a default) 
            
-
            [23:05] <jrand0m> the comm across NAT/firewall/HTTP proxy is the PHTTP transport.  its slow, but reliable. 
            
-
            [23:05] <dm> how does it work? what ports does it use?
            
-
            [23:06] <jrand0m> it sends the message to a reachable PHTTP relay, which stores the message, and then the receiver polls for messages ever N seconds 
            
-
            [23:06] <jrand0m> there is a LOT that can be tuned and improved on that side of things, which is agenda point 3 :) 
            
-
            [23:06] <dm> P stands for?
            
-
            [23:06] <jrand0m> Polling HTTP 
            
-
            [23:06] <dm> ok thanks.
            
-
            [23:07] <jrand0m> I'm going to update the "kludges" page on the wiki after the meeting too, to note the things that are funky 
            
-
            [23:07] <jrand0m> (such as not yet handling a lease change during communication) 
            
-
            [23:08] <jrand0m> the other point to discuss is agenda item 5 - installation.  aka how we should handle installation of the router/sdk/tunnel/etc 
            
-
            [23:08] <jrand0m> ok, thats it for 0.2 status 
            
-
            [23:08] <jrand0m> 2) www proxy. 
            
-
            [23:09] <jrand0m> moi had a really cool idea for browsing in-i2p www sites. 
            
-
            [23:09] <jrand0m> wanna explain whats up moi? 
            
-
            [23:09] * jrand0m puts the spotlight on ya
            
-
            *** moi is ~someone@anon.iip (someone) 
            
-
            *** on channels: #freenet #anonymous #iip #iip-dev 
            
-
            *** on irc via server anon.iip (Official IIP )
            
-
            *** moi has been idle 9 minutes, signed on at Thu Jan 01 01:00:00 1970 
            
-
            [23:10] <moi> well
            
-
            [23:10] <moi> i am just modifying an HTTP proxy and using mihi's tunnel
            
-
            [23:10] <moi> so that you can go to (Link: http://i2p/BASE64KEYHERE)http://i2p/BASE64KEYHERE
            
-
            [23:10] <moi> eventually the naming server would be there--
            
-
            [23:11] <dm> sweet
            
-
            [23:11] *** Signoff: mihi (Ping timeout)
            
-
            [23:11] <moi> you have to paste in the first long key, but after that you should technically be able to follow links I think
            
-
            [23:11] <Dellammo> so an internal web page or a page outside of i2p?
            
-
            [23:11] <dm> i2p resolves to localhost?
            
-
            [23:11] <moi> so someone could put up an i2p Google, and go from there.... mabye
            
-
            [23:12] <mihi-backup> !thwap dm.
            
-
            [23:12] <mihi-backup> a proxy...
            
-
            [23:12] <jrand0m> for security, the proxy should 404 all hosts other than (Link: http://i2p/)http://i2p/ 
            
-
            [23:12] <dm> oops!
            
-
            [23:12] <moi> good point
            
-
            [23:12] <dm> missed that part
            
-
            [23:12] <mihi-backup> although a simple servlet would be nice too
            
-
            [23:12] <jrand0m> hmm? 
            
-
            [23:13] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [23:13] <jrand0m> hmm, there may be a problem. 
            
-
            [23:13] <jrand0m> this would use HTTP 1.0 or 1.1? 
            
-
            [23:14] <mihi> if the server requests a Host: header?
            
-
            [23:14] <jrand0m> [aka, would it have a Host: header?] 
            
-
            [23:14] <jrand0m> exactly 
            
-
            [23:14] * mihi wishes for something
            
-
            [23:14] <moi> I wonder if we can have the proxy blank that out
            
-
            [23:14] <jrand0m> if the server's outbound tunnel is always on the same host, thats fine 
            
-
            [23:14] <jrand0m> you can set the proxy Host: to 127.0.0.1 
            
-
            [23:15] *** dm_backup (~as@anon.iip) has joined channel #iip-dev
            
-
            [23:15] <jrand0m> but then you must run the tunnel on the same host as the server.  not a bad problem, as its not for general normal-web browsing 
            
-
            [23:15] <jrand0m> right? 
            
-
            [23:15] *** Signoff: dm (Ping timeout)
            
-
            [23:16] * moi hadn't thought that deeply into it yet
            
-
            [23:16] <mihi> if you run the server on your own box you can also alias i2p to localhost or sth like that.
            
-
            [23:16] <dm_backup> so do people have to run web servers now?
            
-
            [23:16] <jrand0m> dm_backup> this is only for people who want to. 
            
-
            [23:16] *** dm_backup is now known as dm
            
-
            [23:16] <Dellammo> like me
            
-
            [23:16] <dm> yeah, I mean for this (Link: http://i2p)http://i2p thingie
            
-
            [23:17] <mihi> if you want to provide content, yes.
            
-
            [23:17] <mihi> but you have to run one to provide content in good ol' www as well.
            
-
            [23:18] <Dellammo> why?
            
-
            [23:18] <dm> Hmmm, maybe I should build a P2P app for I2P.
            
-
            [23:18] <jrand0m> a filesharing app over i2p would rule. 
            
-
            [23:18] <dm> yes sorry, filesharing.
            
-
            [23:19] <moi> I think it would be possible for someone to run an OpenNap server in conjunction with i2ptunnel
            
-
            [23:19] <jrand0m> yes. 
            
-
            [23:19] <jrand0m> (though a native i2p p2p would have better performance) 
            
-
            [23:19] <mihi> but the downloads will be hard. 
            
-
            [23:20] <mihi> no way to get to the correct host as all are localhost ;)
            
-
            [23:20] <dm> Let's wait till we see PING running over i2ptunnel first.
            
-
            [23:20] * Dellammo is confused are we talking about a proxy thats not i2ptunnel that lets you access webservers that are internal to the i2p network by typing '(Link: http://i2p/')http://i2p/' ?
            
-
            [23:20] <jrand0m> perhaps just a simple FTP client designed to run over i2p? 
            
-
            [23:20] <dm> (not ping literally)
            
-
            [23:20] <mihi> jrand0m: ftp needs 2 ports...
            
-
            [23:20] <jrand0m> designed to run over i2p. 
            
-
            [23:21] <jrand0m> a general file transfer app, not the FTP protocol, specifically 
            
-
            [23:21] <mihi> then it's not ftp.
            
-
            [23:21] <mihi> ATalk ;)
            
-
            [23:21] <jrand0m> (taking advantage of larger message sizes) 
            
-
            [23:21] <dm> battle of the wise men!
            
-
            [23:21] <jrand0m> heh 
            
-
            [23:21] <moi> Dellammo: right now you have to create an i2ptunnel for each website/Destination you want to browse. We are thinking of using a proxy server that would dynamically build an i2ptunnel for each site.
            
-
            [23:22] <jrand0m> (kind of) 
            
-
            [23:22] <jrand0m> you won't want to use an i2ptunnel, specifically.  
            
-
            [23:22] <jrand0m> you'll want to use the i2ptunnel protocol, and send messages directly, not via TCP/IP sockets. 
            
-
            [23:23] <jrand0m> mihi> any idea what kind of time it would take to factor the protocol functionality out of i2ptunnel so other apps could send data to an i2p tunnel? 
            
-
            *** mihi is mihi@anon.iip (mihi) 
            
-
            *** on channels: #iip-dev #iip #headlines #german #freenet-opn #freenet #fredisdead #frazaa @#fiw #anonymous 
            
-
            *** on irc via server anon.iip (Official IIP )
            
-
            *** mihi has been idle 3 minutes, signed on at Thu Jan 01 01:00:00 1970 
            
-
            *** mihi-backup is ~mihi@anon.iip (mihi) 
            
-
            *** on channels: #iip-dev 
            
-
            *** on irc via server anon.iip (Official IIP )
            
-
            *** mihi-backup has been idle 12 minutes, signed on at Thu Jan 01 01:00:00 1970 
            
-
            [23:25] <mihi> is there any large protocol functionality? I2PTunnelRunner can be used as is.
            
-
            [23:25] <mihi> You just have to adjust the client class for your needs.
            
-
            [23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket 
            
-
            [23:26] <jrand0m> this is a plain java app that wants to generate a message ("HTTP GET /\n\n") and send it to an outbound I2PTunnel 
            
-
            [23:27] <jrand0m> we don't want to redirect the client contacting the proxy to a new port to connect to the newly instantiated I2PTunnel (as there'd be no way to switch back for links off that site) 
            
-
            [23:28] <jrand0m> but perhaps switching I2PTunnelRunner to use an InputStream (all it uses is socket.getInputStream) would be easy... 
            
-
            [23:28] <jrand0m> but then we still need the listen side 
            
-
            [23:28] *** Signoff: mihi (Ping timeout)
            
-
            [23:28] <jrand0m> d'oh 
            
-
            [23:28] * jrand0m hopes the backup isn't about to ping out...
            
-
            [23:28] <dm> backup's gonna die as well ,watch it!
            
-
            [23:29] <mihi-backup> ;)
            
-
            [23:29] <jrand0m> w00t 
            
-
            [23:29] <mihi-backup> [23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket
            
-
            [23:29] <mihi-backup> [23:25] <mihi> oops, right. and you want to do it completely without sockets?
            
-
            [23:29] <mihi-backup> [23:26] <mihi> then there is not much code left from i2ptunnel. most is for handling the sockets.
            
-
            [23:29] <mihi-backup> [23:26] <mihi> best stick to the protocol and implement it yourself (build the messages w/ the static method in i2ptunnel.java)
            
-
            [23:29] <mihi-backup> [23:28] <mihi> http would not need that many threads. Just run a reader over the incoming message until a double return and then send your thing out.
            
-
            [23:30] <jrand0m> ah 'k.  thanks 
            
-
            [23:30] <jrand0m> moi> tu sabes? 
            
-
            [23:30] <mihi-backup> re switching I2PTunnel for an input stream. what for? you won't get anythin on it any more after you parsed the request.
            
-
            [23:31] * moi thinks
            
-
            [23:31] <dm> toi thinks
            
-
            [23:31] <mihi-backup> just forget the tunnelrunner. ;)
            
-
            [23:31] <jrand0m> right, I was just thinking to keep the I2PTunnel and the http proxy to use the same code - I2PTunnel would use socket.getInputStream(), the http proxy would use new ByteArrayInputStream("GET / \n\n".getBytes()) 
            
-
            [23:31] *** mihi (mihi@anon.iip) has joined channel #iip-dev
            
-
            [23:32] * moi will need to go over this later in detail
            
-
            [23:32] <mihi-backup> but that will cause the runner to send a "Connection closed" when the string is sent.
            
-
            [23:32] <mihi-backup> as the stream ends.
            
-
            [23:32] <jrand0m> right, which is normal HTTP 
            
-
            [23:33] <mihi-backup> just forget the runner, i said ;)
            
-
            [23:33] <jrand0m> 'k 
            
-
            [23:33] <mihi-backup> jrand0m: nope. the connection is closed when the answer is here, not when the question is out.
            
-
            [23:33] <jrand0m> oh yeah 
            
-
            [23:33] <jrand0m> ;) 
            
-
            [23:36] <jrand0m> cool moi, we can work through this stuff later on. 
            
-
            [23:36] <jrand0m> ok, thats agenda item 2).  now for 3) 
            
-
            [23:36] <moi> ok
            
-
            [23:37] <jrand0m> 3) phttprelay 
            
-
            [23:37] <jrand0m> phttp relay is a set of servlets wrapped in a .war file 
            
-
            [23:38] <jrand0m> it works out of the box on windows / sun JVM, but I had to hack jetty to run w/ kaffe 
            
-
            [23:38] <mihi> make .peace not .war
            
-
            [23:39] * jrand0m groans
            
-
            [23:39] <dm> you can run .war files without a J2ee server?
            
-
            [23:39] <dm> good to know.
            
-
            [23:39] <jrand0m> .war files run in any servlet container - tomcat, apache w/ mod_jk, jetty, etc 
            
-
            [23:40] <jrand0m> we're going to want some people to run these on machines w/ publicly reachable IP addresses, but they're only necessary for people who don't have publicly reachable addresses (like me) 
            
-
            [23:41] <mihi> which ports do you need to redirect if you want to go through a nat without that?
            
-
            [23:41] <jrand0m> its implementation is very rudimentary as well - it needs some limits as to how many routers it relays for, how many messages it queues up, how long before it times out, etc 
            
-
            [23:41] <jrand0m> just the I2NP TCP port 
            
-
            [23:41] <jrand0m> (or the I2NP UDP port) 
            
-
            [23:41] * mihi does not know if his nat allows udp forwarding
            
-
            [23:42] * jrand0m doesn't know if mihi's nat does either
            
-
            [23:43] <jrand0m> right now, for example, my laptop is reachable via PHTTP only, and my server's router is reachable via PHTTP, TCP, and UDP.  if my laptop establishes a connection to the server's router via TCP, it can send messages via TCP.  but if my laptop doesn't first do that, the server must send messages via PHTTP 
            
-
            [23:44] <jrand0m> the code is in i2p/code/apps/phttprelay/ for anyone with servlets experience who wants to hack on a small app 
            
-
            [23:45] <jrand0m> (it should also work transparently with https as well as plain http) 
            
-
            [23:45] <jrand0m> I'll doc up the PHTTP protocol Real Soon Now.  :) 
            
-
            [23:45] *** Signoff: mihi (Ping timeout)
            
-
            [23:45] <jrand0m> ok, thats it for item 3) phttprelay 
            
-
            [23:45] <jrand0m> 4) i2ptunnel 
            
-
            [23:46] <jrand0m> we've already discussed a bunch of stuff.  unless mihi (or anyone else) has anything else on it, we can move to 5) 
            
-
            [23:46] *** wilde (~anon@anon.iip) has joined channel #iip-dev
            
-
            [23:46] <jrand0m> hola wilde 
            
-
            [23:47] <jrand0m> ok.  that said, item 5 :) 
            
-
            [23:47] <jrand0m> 5) installation 
            
-
            [23:48] <jrand0m> to get 0.2 out the door, and beyond, I'm thinking of some ant scripts. 
            
-
            [23:48] <jrand0m> or should we use another open source installation system? 
            
-
            [23:48] <jrand0m> anyone have any experiences / thoughts on this? 
            
-
            [23:49] <Dellammo> hmm
            
-
            [23:50] <jrand0m> ant has the benefit of being unified with the build system, platform independent, and has headless operation. 
            
-
            [23:50] <wilde> hey
            
-
            [23:50] <jrand0m> but it requires ant (which requires java).  and it doesn't have a GUI 
            
-
            [23:51] <Dellammo> i can think of many install programs for windows... i dont know how many are gpl though
            
-
            [23:51] <jrand0m> yeah, I have a licensed InstallAnywhere Enterprise installation, but its bad for open source 
            
-
            [23:51] <jrand0m> NSIS is open source, but has its nuances. 
            
-
            [23:51] <dm> stupid question: is ant included in java?
            
-
            [23:52] <jrand0m> nope. 
            
-
            [23:52] <jrand0m> oh, though we COULD distribute a GCJ'ed ant 
            
-
            [23:52] <dm> alright, must have come with eclipse then.
            
-
            [23:52] <jrand0m> (compiled to native code) 
            
-
            [23:52] <jrand0m> definitely dm. 
            
-
            [23:52] <jrand0m> apache makes ant (ant.apache.org) and its apache licensed. 
            
-
            [23:52] <jrand0m> oh, yuck. 
            
-
            [23:52] * jrand0m just read the sentence I typed)
            
-
            [23:53] <jrand0m> gpl is not apl friendly, according to the FSF 
            
-
            [23:53] <jrand0m> we probably can't distribute ant. 
            
-
            [23:53] <dm> can't we just a script? what needs to be done for it to be installed?
            
-
            [23:53] <jrand0m> but we can use it. 
            
-
            [23:53] <jrand0m> not much at all.  a script is fine. 
            
-
            [23:53] <jrand0m> but do we want a .bat and a .sh, etc. 
            
-
            [23:54] *** shardy (~shardy@anon.iip) has joined channel #iip-dev
            
-
            [23:54] <dm> what does an installation entail, a couple of questions?
            
-
            [23:54] <jrand0m> writing a java installer to do the install platform independent is overkill, so we should ideally use an existing install framework 
            
-
            [23:54] <jrand0m> yeah, a few questions 
            
-
            [23:54] <jrand0m> the installation targets I forsee: 
            
-
            [23:54] <Dellammo> do we get a flashy new logo? whos working on that?
            
-
            [23:54] <jrand0m> install-router 
            
-
            [23:55] <jrand0m> install-www-tunnel, install-www-proxy, install-sdk, install-cvs-tunnel, update-seednodes 
            
-
            [23:55] <moi> why not use InstallAnywhere? if the code is open that is what matters
            
-
            [23:55] * jrand0m thinks YOU are Dellammo :)
            
-
            [23:55] <jrand0m> InstallAnywhere isn't open source. 
            
-
            [23:55] * Dellammo gets to work
            
-
            [23:56] <dm> script would probably be enough at this point, but I guess might as well think ahead.
            
-
            [23:56] <jrand0m> (its about 4k euro / seat) 
            
-
            [23:56] <jrand0m> right.  so for tomorrow, I'll probably just write ant scripts, but we need to look into a system 
            
-
            [23:56] *** Signoff: wilde (Ping timeout)
            
-
            [23:56] <jrand0m> so if anyone can help out with that, it'd be appreciated :) 
            
-
            [23:57] <dm> ah okay, I was thinking shell scripts.
            
-
            [23:57] <moi> Some of the package managers could do that on the Linux installs
            
-
            [23:57] *** wilde (~anon@anon.iip) has joined channel #iip-dev
            
-
            [23:57] <jrand0m> managing different installers for different platforms is a PITA 
            
-
            [23:59] <dm> java installer? Why is it a PITA?
            
-
            [23:59] <jrand0m> a java installer would be great 
            
-
            [23:59] <mihi-backup> pain in the a**e
            
-
            [23:59] <mihi-backup> oops, sorry...
            
-
            [23:59] <dm> system.out.println("Please enter where you would like to install I2P") ;)
            
-
            [23:59] <mihi-backup> s/tln/t; s/P"/P: "/
            
-
            [23:59] <mihi-backup> s/sys/Sys/
            
-
            [00:00] <jrand0m> writing a custom installer in java is possible, but its preferred to use an existing framework.  but if you're volunteering to write a custom installer, I'm behind ya! 
            
-
            [00:00] <dm> mihi's having an epileptic seizure.
            
-
            [00:00] * mihi-backup slaps dm around a bit with a large trout
            
-
            [00:00] <dm> Tell you what...
            
-
            [00:01] <dm> If you have time at any point to write out the exact steps needed in an install, I'll write a java installer.
            
-
            [00:01] <mihi-backup> dm: read the ant script ;)
            
-
            [00:01] <jrand0m> word dm.  once I get the ant thing working I'll doc 'er up for you 
            
-
            [00:01] <dm> fair enough, we'll see if I can figure out the ant script once it's out.
            
-
            [00:02] *** Signoff: wilde (Ping timeout)
            
-
            [00:02] <Dellammo> jrand0m, i2p I2P i^2p or I^2P ?
            
-
            [00:02] * jrand0m has some scribbles with a capital I, 2 and a capital P all superimposed on each other...
            
-
            [00:03] <Dellammo> hmm
            
-
            [00:03] *** wilde (~anon@anon.iip) has joined channel #iip-dev
            
-
            [00:03] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [00:03] <jrand0m> ok, thats 5) installation 
            
-
            [00:03] <jrand0m> 6) iip feature request 
            
-
            [00:04] <jrand0m> someone came on here with a request for auto-nicktheifing 
            
-
            [00:04] <jrand0m> basically, if someone has registered a nick, no one can stay as that nick unless they're identified 
            
-
            [00:04] <jrand0m> nop or anyone who has done iip dev - thoughts? 
            
-
            [00:04] * jrand0m thinks it'd be a great feature to have
            
-
            [00:05] * Dellammo draws an illuminati eye with a no 'as in no smoking sign' over it
            
-
            [00:05] <jrand0m> heh 
            
-
            [00:05] <dm> Maybe I'll make an I2P logo as well... for the gui part of my installer ;)
            
-
            [00:05] *** Signoff: wilde ((null))
            
-
            [00:05] <Dellammo> lets all make them, so we dont get stuck with a sucky logo
            
-
            [00:05] <mihi> jrand0m: ask mids - he maintains trent.
            
-
            [00:06] <mihi> the trent source is in cvs btw
            
-
            [00:06] <Dellammo> the logo is the most important part of any activity
            
-
            [00:06] <jrand0m> definitely Dellammo. 
            
-
            [00:06] * dm dusts off Corel Draw...
            
-
            [00:06] <dm> man I love Corel Draw.
            
-
            [00:07] <jrand0m> ok, thats it for 6) 
            
-
            [00:07] <jrand0m> 7) ??? 
            
-
            [00:07] <jrand0m> any questions / thoughts / frisbees/ toenails? 
            
-
            [00:07] <dm> Thought: hope it works.
            
-
            [00:08] <jrand0m> heh 
            
-
            [00:08] * jrand0m too.
            
-
            [00:09] <mihi> jrand0m: keep the good work!
            
-
            [00:09] <dm> yes, keep it up.
            
-
            [00:09] <jrand0m> good work?  you obviously haven't seen the code ;) 
            
-
            [00:09] <dm> Love your code, except for the bliding underscores.
            
-
            [00:09] <dm> blinding...bleeding..etc..
            
-
            [00:09] <jrand0m> heh, instance variables have _, so we don't ever need to do this.var = var; 
            
-
            [00:10] <jrand0m> ok... 68 minutes... if I can drag this out for one more minute... 
            
-
            [00:10] <jrand0m> w00t 
            
-
            [00:10] * jrand0m *baf*s the meeting closed.
            
-
            {% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting63.html b/www.i2p2/pages/meeting63.html
deleted file mode 100644
index f6af8f8c..00000000
--- a/www.i2p2/pages/meeting63.html
+++ /dev/null
@@ -1,183 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 63{% endblock %}
-{% block content %}
            Tuesday, October 28, 2003 21:02:50 UTC
            
-
            
-
            [22:59] <dm> so when IS this meeting?
            
-
            [23:00] <jrand0m> now. 
            
-
            [23:00] <jrand0m> 0) welcome [63] 
            
-
            [23:00] <jrand0m> 1) roadmap: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap 
            
-
            [23:00] <jrand0m> 2) 0.2 todo: 
            
-
            [23:00] <jrand0m> - long lasting comm testing 
            
-
            [23:00] <jrand0m> - lease rebuilding bugs 
            
-
            [23:00] <jrand0m> 3) prng (yay) 
            
-
            [23:00] <jrand0m> 4) apps / questions / etc 
            
-
            [23:00] <jrand0m> 0) hi 
            
-
            [23:00] <jrand0m> sorry for being stupid and forgetting about daylight savings time 
            
-
            [23:00] <jrand0m> welcome to meeting #63 
            
-
            [23:01] *** darl_mcbride has left #iip-dev
            
-
            [23:01] <jrand0m> 1) roadmap 
            
-
            [23:01] <jrand0m> the roadmap is at the above url and will be updated whenever necessary. 
            
-
            [23:02] <jrand0m> yes, the dates are further out than they've been in the past, and thats largely a reflection of 1) me not wanting to release shitty software 2) me overlooking details in previous estimates 
            
-
            [23:02] <jrand0m> but, of course, as it says on the roadmap, "If you get involved and help out with some of the coding, things will go faster" :) 
            
-
            [23:03] <jrand0m> 0.2 itself will allow actual useful functionality 
            
-
            [23:03] *** Signoff: thecrypto (Ping timeout)
            
-
            [23:03] <dm> that's good news.
            
-
            [23:03] <jrand0m> ok, item 2) 0.2 todo 
            
-
            [23:04] <jrand0m> i've been doing qa on the 0.2 release for the last week or so and have been tracking down some bugs that have been hard to spot 
            
-
            [23:04] <jrand0m> but i think I found their source a few minutes ago, and I'm running a test against it right now in the background. 
            
-
            [23:05] <jrand0m> (the problem has been that after a few hours of use, communication with a router or a destination fails) 
            
-
            [23:05] <dm> what kind of testing rig are you using? Is it all local at this point?
            
-
            [23:05] <jrand0m> three routers local, three routers remote 
            
-
            [23:05] <sisr> Does 0.2 include the feature that when a router is not able to be contacted after a certain number of times it stops trying?
            
-
            [23:05] <jrand0m> yes 
            
-
            [23:06] <jrand0m> every router publishes its contact info every N (currently 2) minutes to everyone it knows.  if a router doesn't get new contact info every 2.5*N minutes, it drops its reference. 
            
-
            [23:06] <jrand0m> however, if it /wants/ to find a new router (aka it gets a reference to it via a Lease), it can do a search at any time and find it 
            
-
            [23:07] <jrand0m> however, running three routers plus two active destinations locally is, well, a CPU beast. 
            
-
            [23:08] <jrand0m> I've added a nasty feature which I feel dirty about, but it lets you add an environmental variable to basically turn off ElG and AES encryption.  thats only useful for communication with other nodes with the encryption turned off (as otherwise you wouldn't be able to talk) 
            
-
            [23:09] <jrand0m> ok, thats it for 0.2 todo 
            
-
            [23:09] <dm> for your testing purposes?
            
-
            [23:09] <jrand0m> yeah basically 
            
-
            [23:09] <jrand0m> (and/or for anyone else who is doing their own testing to add new features / etc ;) 
            
-
            [23:10] <jrand0m> in theory however, two destinations (like atalk) could set the -Di2p.encryption=off flag and still work (though there wouldn't be any end to end encryption) 
            
-
            [23:10] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev
            
-
            [23:10] <jrand0m> but i think thats a Bad Idea. 
            
-
            [23:11] <jrand0m> this feature will most certainly get pulled once the AES+SessionTag stuff gets worked out 
            
-
            [23:11] <jrand0m> ok, 3) prng 
            
-
            [23:11] <sisr> Are there any suggested minimum CPU and RAM requirements?
            
-
            [23:12] <sisr> sorry
            
-
            [23:12] <jrand0m> hmm, RAM is minimal (sun's JVM takes 7-10Mb, kaffe 16-22Mb) 
            
-
            [23:13] <jrand0m> CPU is definitely the limiting factor at the moment,but I don't have a wide array of boxes to test on ;) 
            
-
            [23:14] <jrand0m> let me just say that running three routers and two i2ptunnels pointing offsite to a squid on the same box pretty much hoses my P4 1.7Ghz box 
            
-
            [23:14] <thecrypto> i might be a little more active if you want me to say somethingh
            
-
            [23:14] <dm> alright, say something.
            
-
            [23:15] <jrand0m> hiya thecrypto :) 
            
-
            [23:15] <sisr> Why would anyone run more than one router on the same computer?
            
-
            [23:15] <jrand0m> sisr> only a developer would. 
            
-
            [23:16] <sisr> Ok, so the CPU should not be too bad and we can run some tests over the weeks
            
-
            [23:16] <jrand0m> word 
            
-
            [23:17] <jrand0m> ok, the prng stuff turned out to be a bug in kaffe, which is now fixed.   
            
-
            [23:17] <jrand0m> with that, we don't have any hard need to get a yarrow impl, as they use sha1prng 
            
-
            [23:18] <jrand0m> (but it'd be nice, whenever we get it) 
            
-
            [23:18] <jrand0m> ok, 4) apps / questions / etc 
            
-
            [23:18] <jrand0m> I don't have anything else, so... hi :) 
            
-
            [23:19] <jrand0m> any questions / thoughts / comments on anything else? 
            
-
            [23:19] <sisr> How is the naming server? I have not seen co for a long time
            
-
            [23:19] *** co (anon@anon.iip) has joined channel #iip-dev
            
-
            [23:19] <jrand0m> speaking of the devil 
            
-
            [23:19] <jrand0m> hi co 
            
-
            [23:19] <sisr> haha
            
-
            [23:19] <co> Hello.
            
-
            [23:20] <jrand0m> we're at that point where there's not really anything left on the agenda 'cept for questions 
            
-
            [23:20] <jrand0m> [23:19] <sisr> How is the naming server? I have not seen co for a long time 
            
-
            [23:20] <jrand0m> [23:19] *** co (anon@anon.iip) has joined channel #iip-dev 
            
-
            [23:20] <jrand0m> and that happened :) 
            
-
            [23:20] *** Signoff: godmode0 (EOF From client)
            
-
            [23:21] <co> There has been no progress on it. I wrote just a small part of the client, and none of the server.
            
-
            [23:22] <jrand0m> coo' 
            
-
            [23:22] * dm points the shame-stick at co.
            
-
            [23:22] <sisr> I believe the HTTP i2p tunnel is working good now
            
-
            [23:22] <sisr> i have adapt mihis excellent httpclient so that you type it into your proxy setting
            
-
            [23:23] <jrand0m> aweseme! 
            
-
            [23:23] <sisr> it also does some simple filter of non i2p site
            
-
            [23:23] <sisr> i think jrand0m has commit this already, yes?
            
-
            [23:23] <jrand0m> do we know what browsers it works with?  I know moz... 
            
-
            [23:23] <jrand0m> yeah, I think I committed that stuff.. lemmie check 
            
-
            [23:23] * co is appropriately ashamed.
            
-
            [23:23] <sisr> It working with Mozilla and the Konqueror
            
-
            [23:24] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev
            
-
            [23:24] <jrand0m> dont worry co, I'm already 2 months behind schedule 
            
-
            [23:24] <sisr> I will try to get the mihi I2P tunnel to work with E-mail server this week
            
-
            [23:24] <sisr> Also many wiki pages have updated
            
-
            [23:24] <jrand0m> oh yeah!  thanks for that 
            
-
            [23:25] * jrand0m actually added a caveat to one of the FAQs this afternoon :)
            
-
            [23:25] * dm decides to concentrate his awesome analytical brainpower towards determining where sisr is from.
            
-
            [23:25] <dm> "Also many wiki pages have updated"
            
-
            [23:25] <sisr> Ok go ahead
            
-
            [23:25] <dm> mmmm.....MMmmmm.....mmmmmm...
            
-
            [23:26] <dm> ah, another clue?
            
-
            [23:26] <sisr> But I can not tell you if you are correct
            
-
            [23:26] <dm> "..... has commit this already, yes?"
            
-
            [23:26] <co> jrand0m: If this has not been asked already, do you want to release the I2P framework and applications as a package at the same time?
            
-
            [23:27] <jrand0m> I've found that what I want and what happens isn't always the same thing 
            
-
            [23:27] <co> I mean release them together.
            
-
            [23:27] <sisr> I have a question after co
            
-
            [23:27] <jrand0m> the current plan is up at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap 
            
-
            [23:28] <jrand0m> i2p itself will be the router and the sdk, but with it will be bundled any applications that are ready, whenever they're ready. 
            
-
            [23:28] <jrand0m> (the installer right now bundles the router, sdk, phttprelay, atalk, and i2ptunnel) 
            
-
            [23:29] *** Signoff: dm (Ping timeout)
            
-
            [23:29] <jrand0m> 'sup sisr? 
            
-
            [23:29] <co> That page is quite helpful. Thank you.
            
-
            [23:30] <sisr> The I2P is very big and it can be used to browse the WWW, to browse I2P Tunnel connect programs and web pages and If someone write a direct I2P webserver and client, can go without the tunnel
            
-
            [23:30] <jrand0m> absolutely. 
            
-
            [23:30] <sisr> My question is how is the I2P developer target towards? Make everything working with I2P Tunnels so that users can have the programs They are already familiar with like IE or
            
-
            [23:31] <sisr> Is it better to try and make I2P web server program, I2P web browser    everything special for the I2P ?
            
-
            [23:31] *** dm (~as@anon.iip) has joined channel #iip-dev
            
-
            [23:32] <jrand0m> personally, I'd love if the former could happen.  however, there will be performance gains by designing apps native to i2p 
            
-
            [23:32] <mihi> unix principle: one job, one tool. so don't write new browsers.
            
-
            [23:32] <jrand0m> right 
            
-
            [23:32] <sisr> How much is the overhead of the I2P Tunnel?    So we should focus on use the I2p Tunnel to get existing program to work
            
-
            [23:32] <dm> one job, one tool? silly principle.
            
-
            [23:33] <sisr> I believe we will need tutorial for people to set up Squid and E-mail proxy to the regular WWW. This is valuable and more than one or two is needed so this means Easy instructions for others to set up their own
            
-
            [23:33] <jrand0m> sisr> the only significant overhead of i2ptunnel is its reliance on i2p's guaranteed delivery mode, which requires waiting for an ack message after each message sent (a full round trip through the pair of tunnels, using all appropriate encryption) 
            
-
            [23:34] <sisr> Haha, ok sisr has a very old computer
            
-
            [23:34] <sisr> It seem real slow to me because of this
            
-
            [23:34] <dm> what was latency like on the first few real tests? Just out of curiosity.
            
-
            [23:35] <jrand0m> I can pull news.google.com with all images in ~ 30-60 seconds 
            
-
            [23:35] <dm> k
            
-
            [23:36] <sisr> How difficult will it be to set up a Freenet like content distribution system on top of I2P? Is that major effort or minor effort?
            
-
            [23:36] <co> And how much time does it take without the tunnel?
            
-
            [23:36] <jrand0m> sisr> if I worked on it fulltime, I'd suspect ~ 1 month to get a DHT on top of i2p 
            
-
            [23:37] <jrand0m> co> ~ 10-15 seconds 
            
-
            [23:38] <co> So i2ptunnel is 3 times as slow.
            
-
            [23:39] <jrand0m> well, i2ptunnel + the routers.  but that is not a linear time - sending 10 bytes over i2p takes about as long as sending 100k 
            
-
            [23:39] *** Signoff: thecrypto (Ping timeout)
            
-
            [23:39] <co> For you, at least.
            
-
            [23:39] <jrand0m> the overhead is in the message wrapping 
            
-
            [23:39] <sisr> If the I2P tunnel is to be the core of most application for I2P then we should concentrate on the User interface and make easy to click option to set up tunnel
            
-
            [23:40] <sisr> Like checkbox to set up I2P Tunnel web server with port, and Checkbox for E-mail server, so it real simple
            
-
            [23:40] <jrand0m> sisr> I personally really really like its interface atm :)   
            
-
            [23:40] <jrand0m> oh, definnitely.  actually 
            
-
            [23:40] * sisr has never seen the interface but imagines it like the textbox
            
-
            [23:40] <sisr> Maybe someone can screencap the I2P tunnel for tutorial
            
-
            [23:41] <jrand0m> what I was planning on is having the installer create a set of .bat and .sh scripts to do so automatically (e.g. java .... I2PTunnel -e 'config basdfawer' -e 'server ...' ) 
            
-
            [23:42] <sisr> What should we be working on for I2P now
            
-
            [23:42] <jrand0m> thats a big question.  short answer is "whatever you can" 
            
-
            [23:43] <jrand0m> if someone were to go ahead and update the installer to build those .sh and .bat scripts, that would rule 
            
-
            [23:43] <jrand0m> if anyone has time to work on some of the things on the i2proadmap, that would also rule :) 
            
-
            [23:44] <jrand0m> I think there's going to be a large demand for doc and qa once 0.2 is out (aka Real Soon Now) 
            
-
            [23:44] <sisr> How will the Installer be? Install shield or Java?
            
-
            [23:44] <jrand0m> the current installer is a single "install.jar" which prompts the user through a few questions 
            
-
            [23:45] <jrand0m> its a really crappy installer 
            
-
            [23:45] <jrand0m> but its as platform independent as it gets 
            
-
            [23:48] <jrand0m> ok cool, the routers are still working, I think this bugfix may have done it. 
            
-
            [23:48] <jrand0m> oh yeah.  
            
-
            [23:48] <jrand0m> the mailing list will be back sometime 
            
-
            [23:48] <jrand0m> if it isn't back by the time 0.2 is ready, I'll create a new mailing list 
            
-
            [23:49] <co> I have one other question.
            
-
            [23:49] <jrand0m> fire away 
            
-
            [23:50] <co> Is there a list available of I2P nodes running right now?
            
-
            [23:50] <jrand0m> nope. 
            
-
            [23:50] <jrand0m> no public i2p nodes are open 
            
-
            [23:50] <co> I see.
            
-
            [23:50] <jrand0m> however, one of them will make its list of peers available via http once 0.2 is released 
            
-
            [23:50] <jrand0m> (and the URL to that list will be in the installer) 
            
-
            [23:50] <jrand0m> s/will be/is/ 
            
-
            [23:52] <mihi> it's in my bookmarks as well...
            
-
            [23:52] <jrand0m> heh bastard 
            
-
            [23:52] <mihi> btw: size=777 is 111 bytes too large ;)
            
-
            [23:53] <jrand0m> rofl 
            
-
            [23:53] <jrand0m> I totally didn't notice that. 
            
-
            [23:53] <jrand0m> they used to be 384 
            
-
            [23:53] <jrand0m> but then I added some router sw version info to the routerInfo 
            
-
            [23:53] <sisr> I think nop can use the I2P tunnel to set up a test IRC server with the 0.2 router?
            
-
            [23:54] <jrand0m> that'd be really cool 
            
-
            [23:54] <sisr> I wonder how the latency comparing to this IIP if nop does that
            
-
            [23:54] <jrand0m> though we wouldn't be able to dcc 
            
-
            [23:54] <jrand0m> i2p would be a lot higher latency 
            
-
            [23:54] <jrand0m> (as each send would be a few seconds, since we don't have AES+SessionTag yet) 
            
-
            [23:57] <jrand0m> ok, if anyone has anything to say before the list is back, either talk here or toss stuff up on the wiki 
            
-
            [23:57] <dm> k, night
            
-
            [23:57] *** dm has left #iip-dev
            
-
            [23:57] * jrand0m *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting64.html b/www.i2p2/pages/meeting64.html
deleted file mode 100644
index 5e81d597..00000000
--- a/www.i2p2/pages/meeting64.html
+++ /dev/null
@@ -1,196 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 64{% endblock %}
-{% block content %}
            (meeting log edited to cover up the fact that iip crashed midway through the meeting and there were lots of ping timeouts, so don't try to read this as a plain narrative)
            
-
            Tuesday, November 11, 2003 21:02:50 UTC
            
-
            
-
            [22:02] <jrand0m> agenda 
            
-
            [22:02] <jrand0m> 0) welcome 
            
-
            [22:02] <jrand0m> 1) i2p router  
            
-
            [22:02] <jrand0m> 1.1) status 
            
-
            [22:02] <jrand0m> 1.2) roadmap changes 
            
-
            [22:02] <jrand0m> 1.3) open subprojects 
            
-
            [22:02] <jrand0m> 2) native modPow 
            
-
            [22:03] <jrand0m> 2) gui installer 
            
-
            [22:03] <jrand0m> 3) IM 
            
-
            [22:03] <jrand0m> 4) naming service 
            
-
            [22:03] <MrEcho> i saw that .c code
            
-
            [22:03] <jrand0m> 5) licensing 
            
-
            [22:03] <jrand0m> 6) other? 
            
-
            [22:03] <jrand0m> 0) welcome 
            
-
            [22:03] <jrand0m> hi. 
            
-
            [22:03] <nop> hi
            
-
            [22:03] <jrand0m> meeting 2^6 
            
-
            [22:04] <jrand0m> got any agenda items to add to there nop? 
            
-
            [22:04] <jrand0m> ok, 1.1) router status 
            
-
            [22:04] <jrand0m> we're 0.2.0.3 and last I heard, its functional 
            
-
            [22:04] <MrEcho> > 0.2.0.3
            
-
            [22:04] <MrEcho> right?
            
-
            [22:05] <MrEcho> im running it .. seems fine
            
-
            [22:05] <nop> no
            
-
            [22:05] <jrand0m> there have been minor commits after the 0.2.0.3 release, nothing release worthy 
            
-
            [22:05] <nop> I am jus trying to catch up
            
-
            [22:05] <jrand0m> coo' 
            
-
            [22:06] <jrand0m> given the experiences and feedback of 0.2.0.x, the roadmap has been updated to get things less resource intensive to run 
            
-
            [22:06] <jrand0m> (aka so people can run webservers / etc and it won't eat up their CPU) 
            
-
            [22:06] <jrand0m> specifically (moving to agenda 1.2): http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap 
            
-
            [22:06] <MrEcho> what ive noticed is that most routers use: TransportStyle: PHTTP   
            
-
            [22:07] <MrEcho> does it auto go to phttp or does it even try tcp first
            
-
            [22:07] <jrand0m> hmm, most routers should support PHTTP, and if they can accept incomming connections, should support TCP as well 
            
-
            [22:07] <jrand0m> if at all possible it uses TCP 
            
-
            [22:07] <jrand0m> PHTTP is weighted about 1000 times more expensive than TCP 
            
-
            [22:08] <jrand0m> (see GetBidsJob, which asks each transport how much it thinks it'd cost to send a message to a peer) 
            
-
            [22:08] <jrand0m> (and see TCPTransport.getBid and PHTTPTransport.getBid for the values used) 
            
-
            [22:08] <MrEcho> ok
            
-
            [22:08] <jrand0m> are you using PHTTP often to send and receive messages? 
            
-
            [22:09] <jrand0m> (that might be a sign that your TCP listener isn't reachable) 
            
-
            [22:09] <MrEcho> i didnt put in the urls on my side
            
-
            [22:09] <jrand0m> ah 'k.  
            
-
            [22:09] <MrEcho> ohh it is
            
-
            [22:10] <jrand0m> ok, yeah, my routers have open TCP connections to you 
            
-
            [22:10] <dm> how hospitable of them.
            
-
            [22:10] * jrand0m is glad y'all made me implement routerConsole.html so we don't have to dig through the logs for this crap
            
-
            [22:11] <MrEcho> is there a timeout thing if it doesnt connect to the tcp it goes phttp? and whatz the timing on it
            
-
            [22:11] <jrand0m> but anyway, the big change to the roadmap is that 0.2.1 will implement the AES+SessionTag stuff 
            
-
            [22:11] <MrEcho> or could we have that in a setting?
            
-
            [22:11] <jrand0m> if it gets a TCP connection refused / host not found /etc, it fails that attempt immediately, and tries the next available bid 
            
-
            [22:12] <MrEcho> so no retrys
            
-
            [22:12] <jrand0m> phttp has a 30 sec timeout iirc 
            
-
            [22:12] <jrand0m> no need to retry.  you either have an open TCP connection and can send the data or you don't :) 
            
-
            [22:12] <MrEcho> lol ok
            
-
            [22:13] <MrEcho> will it try tcp everytime after that or skip that and just go phttp for the next connection?
            
-
            [22:13] <jrand0m> it'll try tcp each time at the moment. 
            
-
            [22:13] <jrand0m> the transports don't keep histories yet 
            
-
            [22:13] <MrEcho> ok cool
            
-
            [22:14] <jrand0m> (but if a peer fails 4 times they get shitlisted for 8 minutes) 
            
-
            [22:14] <MrEcho> well once the otherside gets the phttp msg it should connect to the router that sent the msg via tcp right?
            
-
            [22:14] <jrand0m> correct.  once any tcp connection is established, it can use it. 
            
-
            [22:14] <jrand0m> (but if both peers only have phttp, they'll obviously only use phttp) 
            
-
            [22:15] <MrEcho> that would mean that it couldnt est. a tcp connection to anything
            
-
            [22:15] <MrEcho> .. but ya
            
-
            [22:16] <MrEcho> i wish there was a way around that
            
-
            [22:16] <jrand0m> no, one of my routers doesn't have a TCP address - only PHTTP.  but I establish TCP connections with peers who have TCP addresses. 
            
-
            [22:16] <jrand0m> (and then they can send back messages along that TCP connection instead of sending me slower PHTTP messages) 
            
-
            [22:17] <jrand0m> or is that not what you mean? 
            
-
            [22:17] <MrEcho> ya i got mixed up
            
-
            [22:17] <jrand0m> word, np 
            
-
            [22:18] <jrand0m> so, see the updated roadmap for updated schedule information ((Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap) 
            
-
            [22:18] <jrand0m> ok, 1.3) open subprojects 
            
-
            [22:19] <jrand0m> I finally put a bunch of my palmpilot's todo list into the wiki at (Link: http://wiki.invisiblenet.net/iip-wiki?OpenSubprojects)http://wiki.invisiblenet.net/iip-wiki?OpenSubprojects 
            
-
            [22:19] <jrand0m> so if you're bored and looking for code projects... :) 
            
-
            [22:19] <MrEcho> gezz
            
-
            [22:20] <MrEcho> already got 2
            
-
            [22:20] <dish> You have a palmpilot this is elite
            
-
            [22:20] <MrEcho> mine died
            
-
            [22:20] <jrand0m> mihi> there's a line item in there wrt the I2PTunnel describing a thought I had a lil while ago 
            
-
            [22:20] <MrEcho> dont know whatz up wit hit
            
-
            [22:21] <jrand0m> yeah, I used to have palms but just recently had this one donated to the cause ;) 
            
-
            [22:21] <dish> Could there be an agenda item at the meeting to discuss when the last time userX typed something was
            
-
            [22:21] <MrEcho> damm thing doesnt even turn on anymore
            
-
            [22:21] <MrEcho> lol
            
-
            [22:22] <jrand0m> I don't think UserX has said anything in 4 or 5 months ;) 
            
-
            [22:22] <MrEcho> is that a bot or something?
            
-
            [22:22] <dish> What did they say 5 months ago?
            
-
            [22:22] <MrEcho> i bet its a bitchx running on some box he use to have access to .. and forgot about it
            
-
            [22:22] <jrand0m> that they'd get back with comments about the anonCommFramework (i2p's old name) next week ;) 
            
-
            [22:23] <dish> haha
            
-
            [22:23] <jrand0m> but I suppose he's busy.  so is life 
            
-
            [22:23] <jrand0m> ok, 2) native modPow 
            
-
            [22:23] <MrEcho> i saw that c code
            
-
            [22:24] <jrand0m> i put together a stub .c and java class to show how something like GMP or another MPI library could be integrated, but it obviously doesn't work 
            
-
            [22:25] <jrand0m> what would be good would be if we had a small package of C classes and that trivial associated Java wrapper class that we could build for windows, osx, *bsd, linux, and package up under GPL  
            
-
-
            (insert major iip breakage here)
            
-
-
            [22:38] <MrEcho> last thing i saw was: [13:25] <jrand0m> ok, 2) native modPow
            
-
            [22:38] <jrand0m> hi MrEcho 
            
-
            [22:38] <jrand0m> yeah, looks like a main proxy crashed 
            
-
            [22:39] <jrand0m> I'm giving it another 2 mins before restarting 
            
-
            [22:39] <MrEcho> k
            
-
            [22:39] <MrEcho> for $25 1 time i can get full on java on thenidus.net ... one of my sites
            
-
            [22:40] <jrand0m> $25?  they charge you to install software? 
            
-
            [22:40] <MrEcho> no idea really .. its a package
            
-
            [22:40] <MrEcho> talking to my friend right now
            
-
            [22:40] <jrand0m> I'm not sure the code is quite stable enough to go out and rent a bunch of colo spots to put up routers though.  yet :) 
            
-
            [22:41] <dm> package of what?
            
-
            [22:41] <MrEcho> java - jsp
            
-
            [22:41] <jrand0m> ok, resending what I sent before: 
            
-
            [22:41] <jrand0m> i put together a stub .c and java class to show how something like GMP or another MPI library could be integrated, but it obviously doesn't work  
            
-
            [22:41] <jrand0m> what would be good would be if we had a small package of C classes and that trivial associated Java wrapper class that we could build for windows, osx, *bsd, linux, and package up under GPL (or less restrictive license) 
            
-
            [22:41] <jrand0m> however with the new roadmap placing AES+SessionTag as my current action item, this isn't quite as critical as it was. 
            
-
            [22:42] <jrand0m> if anyone wants to run with this though, that'd be great (and I'm sure another project we're all familiar with would be interested in such a packaging) 
            
-
            [22:43] <dm> frazaa?
            
-
            [22:43] <jrand0m> heh, in a way ;) 
            
-
            [22:44] <jrand0m> ok, 3) gui installer 
            
-
            [22:44] <jrand0m> MrEcho> hi 
            
-
            [22:44] <MrEcho> :)
            
-
            [22:44] <MrEcho> hehe
            
-
            [22:44] <MrEcho> its comming alog
            
-
            [22:44] <jrand0m> cool 
            
-
            [22:44] <MrEcho> nothing fancy
            
-
            [22:45] <MrEcho> ive got some really cool ideas to make it really fancy .. but thatz a way off
            
-
            [22:45] <jrand0m> I was wondering if the installer should add 1) an option to auto-get the seeds from http://.../i2pdb/ 2) auto-get the http://.../i2p/squid.dest and create a runSquid.bat/runSquid.sh too? 
            
-
            [22:45] <jrand0m> word 
            
-
            [22:46] <jrand0m> yeah, we want the installer to be as simple as possible - what fancy stuff were you thinking of? 
            
-
            [22:46] <MrEcho> question is .. when you do java -jar installer   it goes to the non gui by default because of the way u have things
            
-
            [22:46] <MrEcho> how are we going to make it to were you dbl click the jar file and it loads the gui
            
-
            [22:47] <jrand0m> install.jar <-- nongui,  installgui.jar <-- gui 
            
-
            [22:47] <jrand0m> seperate code, seperate packages 
            
-
            [22:47] <MrEcho> fancy as in things you might not notice .. but its goingto be nice and clean
            
-
            [22:47] <jrand0m> cool 
            
-
            [22:47] <MrEcho> aww ok
            
-
            [22:48] <jrand0m> (or install <-- gui installcli <-- cli.  we'll see how things progress) 
            
-
            [22:49] <jrand0m> anything else on the gui, or do we jump off to item 4)? 
            
-
            [22:49] <jrand0m> (any time frame you're thinking?  no pressure, just wondering) 
            
-
            [22:51] <MrEcho> no idea right now
            
-
            [22:51] <jrand0m> coo' 
            
-
            [22:51] <jrand0m> ok, 4) IM 
            
-
            [22:51] <jrand0m> thecrypto aint here, so..... 
            
-
            [22:51] <jrand0m> 5) naming service 
            
-
            [22:51] <jrand0m> wiht isn't here either... 
            
-
            [22:51] <jrand0m> ping 
            
-
            [22:52] <dish> you're off on the number agenda count
            
-
            [22:52] <dish> 3) IM
            
-
            [22:52] <jrand0m> yeah, I used to have 2 agenda item 2's 
            
-
            [22:52] <dish> 4) Naming
            
-
            [22:52] <dish> ;)
            
-
            [22:52] <jrand0m> (native modPow and gui installer) 
            
-
            [22:52] <jrand0m> see, we're dynamic and stuff 
            
-
            [22:59] <jrand0m> ok, for the logs I suppose I'll continue 
            
-
            [22:59] <jrand0m> 6) licensing 
            
-
            [23:00] <jrand0m> I'm thinking about going less restrictive than GPL.  we are using some MIT code, plus one other file is GPL (but thats just the base64 encoding and can be replaced trivially).  other than that, all of the code is either copyright by either myself or thecrypto. 
            
-
            [23:00] * dish look at mihi i2p tunnel part of code
            
-
            [23:01] <jrand0m> oh right, mihi has released that as gpl but he may want to release it as something else if he wants, as well 
            
-
            [23:01] <jrand0m> (but i2ptunnel is essentially a third party app and can license how it wants) 
            
-
            [23:02] <jrand0m> (though since the i2p sdk is gpl, he's been forced to be gpl) 
            
-
            [23:02] <MrEcho> damm about time
            
-
            [23:02] <jrand0m> I don't know.  licensing is not my forte, but I'm inclined at least to move to lgpl 
            
-
            [23:02] * dish release the 10-20 line of change to I2P HTTP Client mihi code as whatever mihi license is
            
-
            [23:03] <jrand0m> hehe :) 
            
-
            [23:06] <jrand0m> anyway, 7) other?   
            
-
            [23:07] <jrand0m> anyone have any questions / concerns / ideas wrt i2p? 
            
-
            [23:07] <dish> Let me ask
            
-
            [23:07] <dish> Does the I2P have any group name feature?
            
-
            [23:07] <jrand0m> group name feature? 
            
-
            [23:07] <dm> team discovery channel!
            
-
            [23:07] <MrEcho> lol
            
-
            [23:08] <dish> So that if you want to have private or seperate network, but some router get intermixed somehow without group name the two network would merge
            
-
            [23:08] <MrEcho> hes thinking of waste
            
-
            [23:08] <jrand0m> ah 
            
-
            [23:08] <dish> I don't know why you would want that, but I am just ask in case
            
-
            [23:08] <jrand0m> yes, early on in the network design I was playing with that 
            
-
            [23:09] <jrand0m> its more advanced than we need for now (or for the relatively near future [6-12 months]) but may be integrated later  
            
-
            [23:09] <dish> Or is that a bad idea because it is better to keep it one large network
            
-
            [23:09] <dm> i2pisdead
            
-
            [23:09] <jrand0m> heh dm 
            
-
            [23:10] <nop> shad up
            
-
            [23:10] <jrand0m> no dish, its a good idea 
            
-
            [23:10] <dm> nop: tough guy?
            
-
            [23:10] <jrand0m> its essentially what release 0.2.3 is -- restricted routes 
            
-
            [23:10] <jrand0m> (aka you've got a small private (trusted) set of peers and you don't want everyone to know who they are, but you still want to be able to communicate with them) 
            
-
            [23:15] <jrand0m> ok, anything else? 
            
-
            [23:15] <nop> nah, I'm just being funny
            
-
            [23:18] <dm> funny guy?
            
-
            [23:20] <jrand0m> ok, well, /interesting/ meeting, with a few iip crashes in the middle ;) 
            
-
            [23:21] * jrand0m *baf*s the meeting to a close
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting65.html b/www.i2p2/pages/meeting65.html
deleted file mode 100644
index 77cff95d..00000000
--- a/www.i2p2/pages/meeting65.html
+++ /dev/null
@@ -1,623 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 65{% endblock %}
-{% block content %}
            Tuesday, November 18, 2003 21:02:50 UTC
            
-
            
-
            [22:02] <jrand0m> agenda: 
            
-
            [22:02] <jrand0m> 0) welcome 
            
-
            [22:02] <jrand0m> 1) i2p dev status 
            
-
            [22:02] <jrand0m>  - 0.2.1.1 is out (peer and tunnel updating and testing, tuning enhancements, tunnel throttling, a DoS defense)  
            
-
            [22:02] <jrand0m>  - don't use bw limiting (still some debugging) 
            
-
            [22:02] <jrand0m>  - keep your clocks generally correct (30 minute fudge factor) [used for lease expirations and garlics] 
            
-
            [22:02] <jrand0m> 2) kademlia, 0.3, and idn 
            
-
            [22:02] <jrand0m> 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? 
            
-
            [22:02] <jrand0m> 4) app status [ppp2p, i2ptunnel, im, ns, squid] 
            
-
            [22:02] <duck> 5) why does jrand0m drink cheap local beer?
            
-
            [22:02] <jrand0m> 5) comments / questions / etc 
            
-
            [22:02] <jrand0m> heh 
            
-
            [22:02] <jrand0m> so yeah, basically that fits under 5 :) 
            
-
            [22:02] <mihi_> double 5 ;)
            
-
            [22:03] <mihi_> oops...
            
-
            [22:03] <jrand0m> 0) welcome 
            
-
            [22:03] * mihi_ did not look 2 the left column
            
-
            [22:03] <jrand0m> hi.  65th meeting I suppose. 
            
-
            [22:03] <jrand0m> hehe 
            
-
            [22:03] <jrand0m> 1) that code stuff 
            
-
            [22:04] <jrand0m> 0.2.1.1 came out last night 
            
-
            [22:04] <jrand0m> lots of goodness in there. 
            
-
            [22:04] * mihi tests it atm.
            
-
            [22:04] <jrand0m> tunnels are tested and fail fast, penalizing all participants so they won't likely get into the rebuild 
            
-
            [22:05] <jrand0m> messages in i2ptunnel are also throttled to max 64k size (larger messages caused badness) 
            
-
            [22:05] <jrand0m> there are some bugs being worked out with the bw limiting code, so make sure your bw limits in router.config are negative values 
            
-
            [22:06] <jrand0m> (i2p doesn't have enough traffic on it to cause real load atm anyway) 
            
-
            [22:06] <jrand0m> (but bw limiting will be unit tested and fixed for 0.2.1.2) 
            
-
            [22:07] <jrand0m> also, please try to keep your clocks close to correct.  it sucks that we have to need that, but right now we do. 
            
-
            [22:07] <jrand0m> we may be able to work out a way to not require semi-sync'ed clocks, but its delicate. 
            
-
            [22:07] <jrand0m> 2) fun stuff 
            
-
            [22:08] <jrand0m> a lot of the bugs being worked out in the last few releases are related to the crappy kludge of a BroadcastNetworkDB. 
            
-
            [22:08] <jrand0m> since its planned for replacement in 0.3, might as well at least mention what its being replaced with 
            
-
            [22:09] <jrand0m> kademlia is a structured distributed hash table (DHT) that lets us insert and fetch in under O(log(N)) time, guaranteed 
            
-
            [22:09] <jrand0m> [with one small caveat thats still being worked out] 
            
-
            [22:10] <jrand0m> that kademlia code needs to get written for 0.3 so we can do insert and fetch of RouterInfo and LeaseSet structures. 
            
-
            [22:10] <jrand0m> however, things would be simpler if it were implemented seperately - and hence testable seperately. 
            
-
            [22:10] <jrand0m> (unit testing == good) 
            
-
            [22:11] <jrand0m> so, whats a simple way to unit test a dht?  to write a simple file store/lookup service on it. 
            
-
            [22:11] <dm> insert fetch? are we talking about content?
            
-
            [22:11] <jrand0m> enter idn: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN 
            
-
            [22:11] <Ophite1> dm: No, only routerinfo and leaseset structures.
            
-
            [22:12] <jrand0m> dm> i2p's networkDatabase currently contains only two specialized structures, as ophite said 
            
-
            [22:12] <dm> okay, thanks.
            
-
            [22:12] <Ophite1> may or may not be useful to use it for bootstrapping other protocols too, but it's not anonymous itself. (?)
            
-
            [22:12] *** grimps (~grimp@anon.iip) has joined channel #iip-dev
            
-
            [22:12] <tusko> one question: which protocol is used now for networkDatabase?
            
-
            [22:13] <jrand0m> sorry, phone. 
            
-
            [22:13] *** Signoff: godmode0 (Ping timeout)
            
-
            [22:13] <jrand0m> correct, kademlia is not anonymous, but not non-anonymous either 
            
-
            [22:13] <Ophite1> modified kademlia will scale. random will not.
            
-
            [22:13] <jrand0m> tusko> currently we do a flooded broadcast 
            
-
            [22:13] <duck> what about kademlia getting splitted?
            
-
            [22:13] <dm> no cell phones allowed into meeting.
            
-
            [22:13] <duck> <insert zooko comments>
            
-
            [22:13] <Ophite1> flooded broadcast aka gnutella method definitely won't ;)
            
-
            [22:13] <jrand0m> Ophite1> right, kademlia doesn't use random ones :) 
            
-
            [22:13] <duck> Ophite1: works better as freenet routing :)
            
-
            [22:14] <jrand0m> duck> exactly (<jrand0m> [with one small caveat thats still being worked out] ) 
            
-
            [22:14] <Ophite1> duck: i rest my case... ;)
            
-
            [22:14] *** Signoff: mihi (Ping timeout)
            
-
            [22:14] <tusko> is kademlia some sort of hypercube?
            
-
            [22:14] <Ophite1> no, a circle.
            
-
            [22:14] *** Signoff: mihi_ (Ping timeout)
            
-
            [22:14] <jrand0m> and/or a xor tree :) 
            
-
            [22:15] <Ophite1> splits/joins... reshuffle tree? can we take a peek at emule's overnetalike for this? :)
            
-
            [22:15] <jrand0m> its a fairly easy protocol, but we can definnitely look around. 
            
-
            [22:16] <jrand0m> icepick has implemented kademlia in python too, for ent (as kashmir) 
            
-
            [22:16] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [22:16] <Ophite1> consider also malicious nodes deliberately fragmenting the tree.
            
-
            [22:16] <jrand0m> absolutely.  but its fairly attack resistant 
            
-
            [22:16] <Ophite1> 256 bit keyspace is more resistant to that though.
            
-
            [22:17] <Ophite1> plus would have to make a lot of routeridentity structures = hard.
            
-
            [22:17] <tusko> i found interesting the papers of gravepine: (Link: http://grapevine.sourceforge.net/)http://grapevine.sourceforge.net/
            
-
            [22:17] <jrand0m> this is also why I want to implement it first as an application, rather than rip out the core of i2p - so we can work out all the messy details first 
            
-
            [22:17] <Ophite1> so I'm pleased with sec 3 of 0.9 draft.
            
-
            [22:17] *** Signoff: nickthief54450 (Excess Flood)
            
-
            [22:18] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [22:18] <tusko> look to (Link: http://grapevine.sourceforge.net/tech-overview.php)http://grapevine.sourceforge.net/tech-overview.php
            
-
            [22:18] <Ophite1> though I might point out that if message 0, DatabasePing, is inplemented, you might want to include a hashcash in it.
            
-
            [22:18] <jrand0m> interesting tusko, I think their economic model might require some revision, as with their sybyl defenses 
            
-
            [22:19] <Ophite1> (you may already; haven't ready that part)
            
-
            [22:19] <jrand0m> absolutely Ophite1.  I was actually thinking about putting hashcash certs into all of the messages (DatabaseLookup included) 
            
-
            [22:20] <Ophite1> good idea. though, be careful of performance and tuning vs. dos defense there, and you might want to run hashcash calc in a separate, lower-priority thread?
            
-
            [22:21] <jrand0m> well, hashcash verification should be near instantaneous 
            
-
            [22:21] <jrand0m> and hashcash generation shouldn't be able to be precompiled 
            
-
            [22:21] <jrand0m> er, precomputed 
            
-
            [22:21] <dm> Ophite1 must be an avatar created by jrand0m so that he can finally talk about I2P with someone who understands wtf he's saying.
            
-
            [22:22] <jrand0m> lol 
            
-
            [22:22] * dm is not fooled.
            
-
            [22:22] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev
            
-
            [22:22] <Ophite1> one way of preventing that is to use derivatives of session keys as part of the hashcash..
            
-
            [22:22] <jrand0m> right.  and/or put in a nonce and the date 
            
-
            [22:22] <Ophite1> date leads to those troublesome timing problems though. that could be a real issue.
            
-
            [22:22] <Ophite1> unless you feel like rewriting ntp as well ;-)
            
-
            [22:22] *** Signoff: mihi (Ping timeout)
            
-
            [22:23] <jrand0m> heh 
            
-
            [22:23] <jrand0m> well, we've already run into that a little bit 
            
-
            [22:23] <jrand0m> (hence the 30 minute fudge factor) 
            
-
            [22:23] <jrand0m> a session hash may be workable though.  good idea. 
            
-
            [22:24] <Ophite1> and no, i'm not jrand0m's clone ;)
            
-
            [22:24] <jrand0m> ok, so for idn, I'm probably only going to implement the stuff on that I2PIDN wiki page  
            
-
            [22:25] *** Signoff: dm (Ping timeout)
            
-
            [22:25] <jrand0m> what would probably rule would be if someone would take that and run with it - make a real user interface, better get/store apps, fec/ecc/etc. 
            
-
            [22:25] <jrand0m> also, I had some ideas about a search network built in parallel as well 
            
-
            [22:26] <jrand0m> but, well, its probably more useful to i2p that I focus my time on the router 
            
-
            [22:26] <Ophite1> it runs on top of i2p?
            
-
            [22:26] <jrand0m> (making it functional, scalable, and secure) 
            
-
            [22:26] <jrand0m> yes 
            
-
            [22:26] <jrand0m> i2p lets idn be anonymous 
            
-
            [22:27] <Ophite1> what were your search network ideas?
            
-
            [22:27] <jrand0m> note: its not written yet, but its looking like its #2 on my task list 
            
-
            [22:27] <Ophite1> can another dht be built through tunnels?
            
-
            [22:27] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [22:27] <jrand0m> basically a distributed replicated db, with hashcash inserts and syncs, where people store idn keys along side metadata / etc 
            
-
            [22:27] *** dm (~as@anon.iip) has joined channel #iip-dev
            
-
            [22:28] <jrand0m> hmm, yes, certainly.  but i2p isn't inherently tunnel based - its message based (i2p is IP, i2ptunnel is TCP) 
            
-
            [22:28] <Ophite1> if ~all node participate = very useful for "discovering" other protocols.
            
-
            [22:28] <jrand0m> definitely 
            
-
            [22:28] <Ophite1> so, should be standard.
            
-
            [22:28] <Ophite1> dhcp/zeroconf for the i2p? :)
            
-
            [22:28] <jrand0m> idn would be a very good app to bundle with i2p to let people have an 'out of box experience' 
            
-
            [22:29] <Ophite1> If it's meant to be a fully featured communication/file transfer/storage application, I'd like to propose the name "Darknet".
            
-
            [22:29] <jrand0m> :) 
            
-
            [22:29] <Ophite1> You, of course, probably already know where that comes from. :)
            
-
            [22:30] <dm> Where does it come from?
            
-
            [22:30] <Ophite1> MS Research's paper: The Darknet and the Future of Content Distribution.
            
-
            [22:30] *** Signoff: godmode0 (Ping timeout)
            
-
            [22:30] <TC> link?
            
-
            [22:30] *** tonious (~Flag@anon.iip) has joined channel #iip-dev
            
-
            [22:30] <jrand0m> well, tim may says he invented the term ~11 years ago ;) 
            
-
            [22:30] <tusko> where is the I2PIDN wiki page?
            
-
            [22:30] <dm> (Link: http://crypto.stanford.edu/DRM2002/darknet5.doc)http://crypto.stanford.edu/DRM2002/darknet5.doc
            
-
            [22:30] <jrand0m> tusko> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN 
            
-
            [22:30] <Ophite1> also implies that the network works "in the dark" - noone knows who anyone is ;)
            
-
            [22:30] <jrand0m> exactly. 
            
-
            [22:31] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [22:31] <jrand0m> well, i2p itself is a darknet in that sense, but its generic messaging - it is the IP layer for such a darknet. 
            
-
            [22:31] <jrand0m> i2ptunnel is the TCP layer, and idn is NFS :) 
            
-
            [22:31] <Ophite1> i2p is the protocol that allows such a network to be created from something broadly like overnet.
            
-
            [22:31] <Ophite1> speaking of which... is there a way to specify priority in messages?
            
-
            [22:32] *** mihi is now known as nickthief76430
            
-
            [22:32] *** mihi_ is now known as mihi
            
-
            [22:32] <jrand0m> funny that you mention that :) 
            
-
            [22:32] *** nickthief76430 is now known as mihi_backup
            
-
            [22:32] <mihi> oops...
            
-
            [22:32] <jrand0m> I was just reading some of the upcoming HotNets2 papers ((Link: http://nms.lcs.mit.edu/HotNets-II/program.html)http://nms.lcs.mit.edu/HotNets-II/program.html) and got inspired for some QoS over i2p mechanisms 
            
-
            [22:33] <Ophite1> would a bulk/low-latency bit compromise anonymity slightly (intersection attack?) by allowing traffic linkage? well, even if it were sometimes flips?
            
-
            [22:33] <Ophite1> ah, well that might work better of course =)
            
-
            [22:33] <Ophite1> Don't worry about local plausible denability.
            
-
            [22:33] <jrand0m> right, i2p assumes the local machine is trusted 
            
-
            [22:33] *** Signoff: dm (Ping timeout)
            
-
            [22:33] <Ophite1> That is a problem to be solved by Rubberhose/Marutukku and Thermite, not I2P.
            
-
            [22:34] <jrand0m> exactly.  (otherwise, the software is compromised and it doesn't matter what we do) 
            
-
            [22:34] * TC hopes his local machine is trusted
            
-
            [22:34] <jrand0m> heh 
            
-
            [22:34] <Ophite1> TC: easy way to find out; make death threats against bush and see if SS agents turn up at your door ;-)
            
-
            [22:34] <jrand0m> lol 
            
-
            [22:34] <TC> done and done
            
-
            [22:34] *** Signoff: tonious (Ping timeout)
            
-
            [22:34] <jrand0m> hah! 
            
-
            [22:35] * jrand0m watches my squid proxy get taken down by the fbi
            
-
            [22:35] <TC> its a trap!
            
-
            [22:35] <jrand0m> get an axe! 
            
-
            [22:35] <jrand0m> :) 
            
-
            [22:35] <TC> anybody play uplink?
            
-
            [22:35] <Ophite1> completed it. cracked it. released it.
            
-
            [22:35] <Ophite1> trained it too ;)
            
-
            [22:36] * jrand0m takes that as a "yes"
            
-
            [22:36] *** dm (~as@anon.iip) has joined channel #iip-dev
            
-
            [22:37] <Ophite1> there may be some dos possibilities in caching, in memory stuff...
            
-
            [22:37] <jrand0m> ok, so thats what I'm thinking with idn/kademlia.  get idn implemented and working over the 0.2. code, smash it in a bit, then implement 0.3 with that kademlia implementation 
            
-
            [22:37] <jrand0m> oh certainly.  the todo list has 'sync pending and large messages to disk' :) 
            
-
            [22:37] <dm> shouldn't IDN be implemented after I2P is tested and mature?
            
-
            [22:38] <jrand0m> thats one of the problems we ran into testing a large file of TC's eepsite 
            
-
            [22:38] <Ophite1> dm: not given as it's a testbed for the fancy db.
            
-
            [22:38] <jrand0m> dm> I was thinking that too, but I need to implement the kademlia code to get 0.3 ready.  basically the kademlia code IS 0.3 
            
-
            [22:38] <Ophite1> I do like the hybrid dht nature such a network would provide though.
            
-
            [22:39] <dm> aha... 
            
-
            [22:39] <jrand0m> but if no one wants to toss a normal UI onto it until i2p 1.0, that might be a good idea as well 
            
-
            [22:39] <Ophite1> dht node discovery + ngr-like routing = scalability capable of handling critical mass
            
-
            [22:39] <dm> what happened to that original milestone list. secure-->anonymous-->not harvestable, etc...
            
-
            [22:39] <Ophite1> jrand0m: I will refrain from advertising it to pirates until it's ready. that enough?
            
-
            [22:39] <jrand0m> well, minus the ngr-like routing :) we tunnel :) 
            
-
            [22:39] <TC> as long as we keep the cli
            
-
            [22:39] <dm> ah scalable was one of the items in that chain.
            
-
            [22:39] <jrand0m> dm> 0.3 is necessary for scalable.  which is before not harvestable 
            
-
            [22:39] <jrand0m> thanks Ophite1 :) 
            
-
            [22:40] <jrand0m> definitely TC.  I'll need the cli to test it 
            
-
            [22:40] <Ophite1> scalability of the actual anonymous stuff is directly related to choices made in the routing for the tunnels, and that's a router implementation thing?
            
-
            [22:40] <jrand0m> (and, c'mon, we'll probably do software distribution / releases with idn) 
            
-
            [22:40] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev
            
-
            [22:40] <dm> alrighty... sounds okay then.
            
-
            [22:40] <jrand0m> absolutely ophite. 
            
-
            [22:40] <Ophite1> suggestion: maximum message size?
            
-
            [22:40] <jrand0m> thats the Hard problem 
            
-
            [22:41] <jrand0m> max message size is currently insanely large (4g) but I'm thinking of trimming it to 64k or 128k 
            
-
            [22:41] <jrand0m> but I don't want to resort to that yet 
            
-
            [22:41] * Ophite1 goes digging in notes
            
-
            [22:41] <Ophite1> BitTorrent/Scone scalability notes indicate 512K.
            
-
            [22:42] <jrand0m> heh ok cool.  (any refs I can dig into?) 
            
-
            [22:42] <Ophite1> but, think of it like tcp window size.
            
-
            [22:42] <jrand0m> right 
            
-
            [22:42] <Ophite1> not for scone, sorry - friend's research project.
            
-
            [22:42] <jrand0m> coo', no worry 
            
-
            [22:42] *** Signoff: mihi_backup (Ping timeout)
            
-
            [22:42] <Ophite1> fwiw, your kademlia is about as good as his though :)
            
-
            [22:42] <jrand0m> hehe 
            
-
            [22:42] <jrand0m> (well, I haven't implemented it yet ;) 
            
-
            [22:42] <Ophite1> uh, hers I mean :/
            
-
            [22:42] <jrand0m> oh wikked 
            
-
            [22:43] <dm> boner..
            
-
            [22:43] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev
            
-
            [22:43] <jrand0m> heh 
            
-
            [22:43] <jrand0m> so, thats 2) kademlia, 0.3, and idn 
            
-
            [22:43] <Ophite1> she named her toys after puddings. custard, crumble (Waste-like), strudel.. her bittorrent-a-like was the fastest pudding in the world - 'scone ;)
            
-
            [22:43] <jrand0m> haha 
            
-
            [22:45] <Ophite1> she's a math.
            
-
            [22:45] <jrand0m> even better 
            
-
            [22:45] <jrand0m> there's a lot of stats gathering / analysis that will be coming up for advanced peer selection 
            
-
            [22:45] <Ophite1> but I'll see if I can bounce stuff past her. scalability from i2np 0.9 was from her - she likes it.
            
-
            [22:45] <jrand0m> (unfortunately we can't cheat like mnet, mixminion, and tor) 
            
-
            [22:46] <jrand0m> great to hear 
            
-
            [22:46] <Ophite1> one comment - dsa?
            
-
            [22:46] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [22:46] <Ophite1> dsa 1024 bit, as in SHA-1?
            
-
            [22:46] <jrand0m> yea 
            
-
            [22:47] <Ophite1> 'spose it is tried and tested.
            
-
            [22:47] <Ophite1> also small.
            
-
            [22:47] <jrand0m> right.  but I'm not 100% tied to our particular crypto impls 
            
-
            [22:47] <Ophite1> anyway. to roadmap.
            
-
            [22:47] <TC> haha, lets name a windows version 'Microsoft Darknet (r)'
            
-
            [22:47] <jrand0m> heh tc 
            
-
            [22:48] <jrand0m> ok, 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? 
            
-
            [22:48] <jrand0m> because of all the bugs I've been running into wrt the broadcast db, I want to escalate the 0.3 (kademlia db) release 
            
-
            [22:48] <TC> its nice not being limmited by trademarks like a normal open source project
            
-
            [22:49] *** tonious (~Flag@anon.iip) has joined channel #iip-dev
            
-
            [22:49] <jrand0m> 0.2.3 is restricted routes / trusted peers, and probably not a hard feature requirement that anyone here has.  it can be shuffled out to 0.4 without problem, I think 
            
-
            [22:50] <jrand0m> 0.2.2 is tunnel mods, but I think a lot of the pressure to get that implemented will be eased with the 0.2.1.1 release (which tests and rebuilds tunnels as necessary, rather than waiting 10 minutes) 
            
-
            [22:50] <Ophite1> trusted peers is an area that needs some revision imho.
            
-
            [22:50] <jrand0m> agreed. 
            
-
            [22:50] *** dm_backup (~as@anon.iip) has joined channel #iip-dev
            
-
            [22:50] <Ophite1> only area that doesn't give me warm fuzzies.
            
-
            [22:50] <Ophite1> though that may just be the word "trusted". :)
            
-
            [22:50] <jrand0m> basically my current thoughts are to publish tunnels to routers 
            
-
            [22:50] <jrand0m> heh 
            
-
            [22:51] <jrand0m> (if we publish tunnels to routers, we can get away with untrusted gateways, which drops the 'trusted' from trusted peers) 
            
-
            [22:51] *** Signoff: dm (Ping timeout)
            
-
            [22:51] *** dm_backup is now known as dm
            
-
            [22:51] <Ophite1> need to analyse anonymity implications of that.
            
-
            [22:51] <jrand0m> but trusted peers is inherently necessary in a militant grade anon system, where /all/ nodes you can contact are considered attackers. 
            
-
            [22:52] <Ophite1> don't think that is truly possible...
            
-
            [22:52] <jrand0m> certainly.  yet another reason it should get 0.4 
            
-
            [22:52] <jrand0m> Ophite1> trusted nodes with timed / triggered self destruct. 
            
-
            [22:52] <jrand0m> set up a patsy, route through it, kill it 
            
-
            [22:52] <jrand0m> exactly, if patsies delete their logs after N hours / N bytes / N messages 
            
-
            [22:52] <Ophite1> I mean if you want me to release a worm that sets up a couple of million...
            
-
            [22:53] <Ophite1> logs? what logs?
            
-
            [22:53] <jrand0m> :) 
            
-
            [22:53] <jrand0m> ok, format the disks ;) 
            
-
            [22:53] * Ophite1 wrote kernel-level stealth trojan
            
-
            [22:53] <jrand0m> nice 
            
-
            [22:53] * dm wrote kernel level outlook calendar plugin.
            
-
            [22:53] <Ophite1> ...when I was 19 :)
            
-
            [22:53] <Ophite1> still works. :)
            
-
            [22:54] <Ophite1> not going to include it in this though, don't worry, or, uh, check my code, which would probably be a Good Thing To Do anyway ;)
            
-
            [22:54] <dm> when I was 12.
            
-
            [22:54] <jrand0m> I don't think i2p will want /that/ large distribution until after 1.0 is stable and heavily peer reviewed 
            
-
            [22:54] <jrand0m> heh Ophite1 
            
-
            [22:54] <jrand0m> heh dm 
            
-
            [22:54] <Ophite1> frankly, think that is a fluff feature.
            
-
            [22:54] <jrand0m> perhaps. 
            
-
            [22:55] <jrand0m> restricted routes is a necessity though 
            
-
            [22:55] <jrand0m> its basic functionality for people behind firewalls 
            
-
            [22:55] <jrand0m> (very restrictive firewalls) 
            
-
            [22:55] <Ophite1> hello, transports.
            
-
            [22:55] <Ophite1> we'll get to that.
            
-
            [22:55] <Ophite1> or is now the appropriate time to discuss them?
            
-
            [22:55] <jrand0m> sure, lets dig in :) 
            
-
            [22:56] <jrand0m> we've already run into a problem with an unreachable peer that could be solved with restricted routes 
            
-
            [22:56] *** tusko has left #iip-dev
            
-
            [22:56] <jrand0m> even though it was due to misconfiguration, it could be more common 
            
-
            [22:57] <Ophite1> Also: given two cooperating peers behind inbound-filtering firewalls that drop bad packets, and one cooperating peer which is not behind a firewall and can send packets with forged IP source addresses to both of the other peers...
            
-
            [22:57] <Ophite1> You can establish a TCP connection between the two firewalled peers that both firewalls think is outbound.
            
-
            [22:57] <jrand0m> definitely 
            
-
            [22:57] <dm> forged IP addresses?!?
            
-
            [22:58] <Ophite1> believe me, firewalls are a VERY common problem.
            
-
            [22:58] <Ophite1> sometimes they are user-controlled but the user is a doofus. that can be handled with the installer handling the firewall :)
            
-
            [22:58] <dm> I2P is gonna use IP spoofing? :)
            
-
            [22:58] <jrand0m> definitely.  if i2p can't operate behind firewalls / NATs / proxies, there's no reason to continue. 
            
-
            [22:59] <Ophite1> sometimes they are actively hostile, corporate or educational gateways seeking to deliberately mess up everything. It's got to traverse those, and traverse them cleanly.
            
-
            [22:59] <jrand0m> dm> transport options 
            
-
            [22:59] <jrand0m> absolutely Ophite1 
            
-
            [22:59] <Ophite1> dm: I have a working implementation - in the Direct Connect protocol.
            
-
            [22:59] <jrand0m> i2p wants to be the battleground for that code. 
            
-
            [22:59] <Ophite1> dm: If *that* can handle it, i2p can.
            
-
            [22:59] *** Signoff: tonious (Ping timeout)
            
-
            [23:00] <Ophite1> I suggest leaving it turned off by default though. Only a very few want it turned on, and it would be nice if they can advertise which they are so requests can be routed to them.
            
-
            [23:00] <dm> you can't spoof IPs without native code can you?
            
-
            [23:00] <Ophite1> the advantage is that they don't have to route *through*, just help the setup.
            
-
            [23:00] <Ophite1> = massive speed boost.
            
-
            [23:01] <jrand0m> definitely Ophite1, thats what the RouterInfo.routerAddress[] structure is for 
            
-
            [23:01] <Ophite1> dm: yeah, like this isn't going to be rewritten?
            
-
            [23:01] *** tonious (~Flag@anon.iip) has joined channel #iip-dev
            
-
            [23:01] <dm> okay, just checking...
            
-
            [23:01] <jrand0m> right dm, I have no qualms whatsoever with including native code in i2p 
            
-
            [23:01] <Ophite1> I would like to state that I don't think java is a permanent solution.
            
-
            [23:01] <Ophite1> And that I regard java router as testbed/prototype.
            
-
            [23:01] <jrand0m> thats fine.  if it gets us to 1.0, works out the protocol, etc, good enough. 
            
-
            [23:02] <Ophite1> ...and hope it doesn't get stuck there as freenet has ;)
            
-
            [23:02] <dm> IPAddress.Spoof(192.168.32.1);
            
-
            [23:02] *** alient (alient@anon.iip) has joined channel #iip-dev
            
-
            [23:02] <jrand0m> lol dm 
            
-
            [23:02] <dm> import IPSpoofing;
            
-
            [23:02] <Ophite1> mmm... raw sockets in java ;)
            
-
            [23:02] <jrand0m> fcntl / ioctl in java... mmMMmm 
            
-
            [23:02] <mihi> hmm, raw sockets require root on unix, don't they?
            
-
            [23:02] <dm> women with large breasts lickig my penis.. mmMMmmm
            
-
            [23:02] <jrand0m> so we include a rootkit 
            
-
            [23:03] <jrand0m> ;) 
            
-
            [23:03] <Ophite1> jrand0m: got it covered =)
            
-
            [23:03] <jrand0m> heh 
            
-
            [23:03] <Ophite1> besides as I said; only a few need it.
            
-
            [23:03] <jrand0m> right 
            
-
            [23:04] <jrand0m> and only for legitimate reasons, of course. 
            
-
            [23:04] <Ophite1> on my dc hub, only one (bot) had the capability, and the hub told it when passives wanted to connect to passives.
            
-
            [23:04] <Ophite1> caused a bit of amazement that did.
            
-
            [23:04] <jrand0m> hehe 
            
-
            [23:04] <Ophite1> also got the bot's host shut down, hence my suggestion to perhaps turn it off by default :)
            
-
            [23:04] <jrand0m> thats definitely a good feature to have avail 
            
-
            [23:04] <jrand0m> lol 
            
-
            [23:05] *** Signoff: nickthief54450 (Excess Flood)
            
-
            [23:05] <jrand0m> ok, so with restricted routes pushed to 0.4, we have a month or so to continue the debate as to whether the functionality is necessary 
            
-
            [23:06] <jrand0m> any other thoughts / things that should be in the roadmap that aren't, things that are in the wrong place, etc? 
            
-
            [23:06] <Ophite1> I say push it to 0.4 definitely. It will cause firewall issues at the moment but we are still in testing...
            
-
            [23:06] <Ophite1> ...someone that can't open a firewall port probably shouldn't be trying it yet.
            
-
            [23:06] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [23:06] <jrand0m> right.  and even with firewalls, PHTTP lets them through. 
            
-
            [23:07] <Ophite1> though need to test phttp against hostile proxies.
            
-
            [23:07] * jrand0m is behind a firewall I don't control and I participate fully in i2p
            
-
            [23:07] <dm> hax0r
            
-
            [23:07] <jrand0m> well, yes, hostile proxies can fake confirm, but its all signed, so the message can't go to the wrong place / etc 
            
-
            [23:08] <jrand0m> but the phttp relay and transport does have a lot of features needed 
            
-
            [23:08] <Ophite1> in particular, to examine the future possibilities application level routers might have at detecting/fucking up the protocol.
            
-
            [23:08] <jrand0m> hm? 
            
-
            [23:08] <Ophite1> have some experience with firewall tunnelling though.
            
-
            [23:08] <Ophite1> might want to include a GET fallback.
            
-
            [23:09] <jrand0m> hmm.  GET goes into logs.  but perhaps as a fallback 
            
-
            [23:09] <jrand0m> (POST can be to /index.html) 
            
-
            [23:09] <Ophite1> jrand0m: but it's all signed/encrypted if noderefs are cool...?
            
-
            [23:10] <Ophite1> unless the proxy becomes an active attacker too, that's going to be quite hard for it.
            
-
            [23:10] <jrand0m> all messages are encrypted to the destination router, and the designation as to what phttp relay to go through is signed in the routerInfo 
            
-
            [23:10] <jrand0m> right.  phttp proxy as is certainly isn't strong enough to go against an active attacker 
            
-
            [23:11] *** Signoff: grimps (Leaving)
            
-
            [23:12] <jrand0m> I think it'd be great if people posted some alternate transport ideas to the wiki :) 
            
-
            [23:12] <jrand0m> ok, 4) app status [ppp2p, i2ptunnel, im, ns, squid] 
            
-
            [23:12] <jrand0m> damn, tusko left 
            
-
            [23:12] <jrand0m> tusko wrote a python script (ppp2p) to let people run ppp over i2p via i2ptunnel 
            
-
            [23:13] <Ophite1> Told you someone would do that :)
            
-
            [23:13] <dm> ppp over i2p?
            
-
            [23:13] <jrand0m> I haven't looked at it, but last I heard he was running a vpn over i2p with 5s ping times 
            
-
            [23:13] <jrand0m> heh yeah 
            
-
            [23:13] <Ophite1> dm: of course.
            
-
            [23:13] <dm> when could you use that?
            
-
            [23:13] <dm> could/would
            
-
            [23:13] <jrand0m> dm> anonymous outproxy 
            
-
            [23:13] <Ophite1> dm: anonymous ANYTHING.
            
-
            [23:13] <jrand0m> to, say, run a kazaa node anonymously, or whatever 
            
-
            [23:13] * Ophite1 points out that anyone running an outbound i2p->ppp link is insane and will probably be blacklisted/hunted down
            
-
            [23:13] <dm> ah, I understand.
            
-
            [23:13] <jrand0m> definitely Ophite1 
            
-
            [23:14] <jrand0m> so right now, its only for trusted peers.   
            
-
            [23:14] <Ophite1> see also: the dresden JAP cascade... :)
            
-
            [23:14] <jrand0m> which, well, doesnt really make sense for anonymity... 
            
-
            [23:14] <jrand0m> heh 
            
-
            [23:14] <Ophite1> also most of the stuff going out of their node will be unencrypted...
            
-
            [23:14] * jrand0m thinks about ike over ppp over i2p
            
-
            [23:15] * jrand0m watches my head explode
            
-
            [23:15] *** fiaga (~po@anon.iip) has joined channel #iip-dev
            
-
            [23:15] <Ophite1> jrand0m: why not i2p over ppp over i2p?
            
-
            [23:15] <jrand0m> definitely doable.  aint recursion fun? 
            
-
            [23:15] <soros> i2p over i2p  :-o
            
-
            [23:15] <jrand0m> or i2p over ppp over i2p over i2p over freenet over kazaa 
            
-
            [23:15] <Ophite1> now that's just silly. Freenet wouldn't possibly work ;)
            
-
            [23:16] <godmode0> over slow connect :)
            
-
            [23:16] <jrand0m> heh it'd have latency issues, certainly :) 
            
-
            [23:16] <mihi> ... over an icmp tunnel over ...
            
-
            [23:16] <Ophite1> ooh yes, loki :)
            
-
            [23:16] <Ophite1> 0ldsk00l :)
            
-
            [23:17] <Ophite1> I2P addresses, being the public keys, are ... rather long.
            
-
            [23:17] <jrand0m> yes. 
            
-
            [23:17] <jrand0m> actually, since we're on agenda item 4: ns 
            
-
            [23:17] <Ophite1> As in an I2P www url being actually too long to paste into any sane place (>512 chars?!!)
            
-
            [23:17] <mihi> co promised to write a naming service...
            
-
            [23:17] <jrand0m> yeah. 
            
-
            [23:17] <jrand0m> I think with idn implemented, it would be very easy for someone to adapt the kademlia code into a distributed dns  
            
-
            [23:17] <mihi> Ophite1: post them to the eepsite forum.
            
-
            [23:18] <Ophite1> trouble with namespace as I can figure it out is that there has to be either some degree of central control OR you have to allow collisions.
            
-
            [23:18] *** Signoff: fiaga (Ping timeout)
            
-
            [23:18] <jrand0m> (just toss on a CA or WoT CAs, and voila.  (Link: www.mihi.i2p)www.mihi.i2p) 
            
-
            [23:18] <jrand0m> not necessarily. 
            
-
            [23:18] <Ophite1> please enlighten me with your better ideas then.
            
-
            [23:18] <jrand0m> Ophite1> check out co/wiht's specs on the iip-dev list.   
            
-
            [23:19] <Ophite1> best I could come up with is root key creates signed namespaces. dnssec stylee.
            
-
            [23:19] <jrand0m> he doesn't go the full route with a dht, but he manages groups 
            
-
            [23:19] <jrand0m> just like how we do now - we /all/ can choose who our root dns servers are. 
            
-
            [23:19] <jrand0m> in the same vein, we /all/ should be able to choose who our CA (or CA WoT) is 
            
-
            [23:20] <jrand0m> so I guess technically there /could/ be collisions, but only once there are multiple CA groups that don't interact 
            
-
            [23:20] * Ophite1 notes that is unlikely
            
-
            [23:20] <jrand0m> agreed 
            
-
            [23:20] <Ophite1> you either trust the root CA or you don't.
            
-
            [23:20] <jrand0m> and if you don't trust the root, you create your own 
            
-
            [23:21] <jrand0m> (or find another) 
            
-
            [23:21] <Ophite1> and if you don't trust the root CA it's for a reason, a reason that will rapidly get around.
            
-
            [23:21] <jrand0m> exactly 
            
-
            [23:21] <jrand0m> especially when there's anonymous publishing :) 
            
-
            [23:21] <Ophite1> being as CA's only real purpose is to insure anti-collision - like Trent...
            
-
            [23:21] <jrand0m> right 
            
-
            [23:22] <Ophite1> about the only thing that would cause lack of trust in CA is (1) key leakage or (2) refusal to register something that isn't already registered.
            
-
            [23:22] * jrand0m notes verisign's "trustworthiness"
            
-
            [23:23] * Ophite1 notes that Verisign purports to verify the identity of the certificate holder - one of the properties that an I2P namespace is in fact guaranteed NOT to do
            
-
            [23:23] <jrand0m> self signed certs+++ 
            
-
            [23:24] <Ophite1> also I'd point out that distributed systems - like Darknet, as I will call it from here on in until it sticks :) - built on top of i2p probably wouldn't use the namespace.
            
-
            [23:24] <Ophite1> It's for servers, really.
            
-
            [23:24] <jrand0m> heh 
            
-
            [23:24] <jrand0m> right 
            
-
            [23:24] <Ophite1> Servers don't scale. That problem will be in i2p as much as in IP.
            
-
            [23:24] <Ophite1> so, I think that the usage in practice will actually be surprisingly limited.
            
-
            [23:24] <jrand0m> the idn ("darknet") would keep references to destinations - the full 387 bits of their keys, not some pretty name 
            
-
            [23:24] <jrand0m> agreed. 
            
-
            [23:25] <jrand0m> except / until someone writes a distributed outproxy system 
            
-
            [23:25] <jrand0m> aka o-r / freedom  over i2p 
            
-
            [23:25] <TC> how many diffrent keys can we have?
            
-
            [23:25] * jrand0m looks forward to that day
            
-
            [23:25] <jrand0m> tc> 2^2048 
            
-
            [23:25] <Ophite1> jrand0m: at which point the root key signs them a namespace: .proxy.i2p
            
-
            [23:26] <dm> This must be the most hypothetical/megalomaniac open source development meeting ever :)
            
-
            [23:26] <jrand0m> aint subspaces grand :) 
            
-
            [23:26] <jrand0m> lol dm 
            
-
            [23:26] <jrand0m> hey, we're alowed to aim high, aint we? 
            
-
            [23:26] <dm> I'm sure most devl meetings are like: "So, do we put 3 bits for the mpeg-5 header or 4?"
            
-
            [23:26] <Ophite1> jrand0m: oddly as it may seem, not every number works for elgamal ;-)
            
-
            [23:26] <TC> dm, youve seen debian meetings right?
            
-
            [23:26] <jrand0m> awww c'mon, 000000000000000000000000000 is a secure key 
            
-
            [23:26] * Ophite1 hands out Chocolate Digestives
            
-
            [23:26] <dm> TC: no, what are the like?
            
-
            [23:26] <Ophite1> jrand0m: ooh, identity.
            
-
            [23:26] <TC> dm, i dont know, i was asking
            
-
            [23:27] <jrand0m> ok.  thecrypto isn't here either... anyone have im thoughts? 
            
-
            [23:27] <Ophite1> damn, I was about to ask about that.
            
-
            [23:27] <Ophite1> quite an important app.
            
-
            [23:27] <dm> Anyway, this type of meeting is more lurker-friendly, so I'm all for it.
            
-
            [23:27] * dm is entertained.
            
-
            [23:27] <jrand0m> heh 
            
-
            [23:27] <TC> where is co?
            
-
            [23:27] <Ophite1> as many people will expect i2p to be iip's successor.
            
-
            [23:28] <jrand0m> iip over i2p is fairly easy, if we don't want dcc 
            
-
            [23:28] <Ophite1> (I guess it could be, if we just run an iip irc server over i2p...)
            
-
            [23:28] <jrand0m> iip over i2p with dcc requires a new app 
            
-
            [23:28] <jrand0m> exactly Ophite1 
            
-
            [23:28] <jrand0m> 0 coding 
            
-
            [23:28] <TC> cant we just run irc over i2p?
            
-
            [23:28] <Ophite1> I don't like that idea 'cause ... well, it doesn't give us anything we don't already have :)
            
-
            [23:28] <jrand0m> but last I heard, thecrypto was doing some work on an IM app 
            
-
            [23:28] <jrand0m> certainly tc 
            
-
            [23:29] <jrand0m> right Ophite1, and it doesn't scale 
            
-
            [23:29] <jrand0m> (all the traffic gets funneled to the ircd) 
            
-
            [23:29] <Ophite1> Also the IRCd can spy on traffic.
            
-
            [23:29] <TC> ah, goodpoint
            
-
            [23:29] <jrand0m> (this would be when UserX should show up and discuss his ideas for iip2.0) 
            
-
            [23:29] <jrand0m> right Ophite1 
            
-
            [23:29] <jrand0m> all the problems of the current iip 
            
-
            [23:29] <Ophite1> jrand0m: And absolutely nothing different.
            
-
            [23:29] <jrand0m> more lag. 
            
-
            [23:30] <Ophite1> except it's in java. lovely. :)
            
-
            [23:30] <jrand0m> heh 
            
-
            [23:30] <Ophite1> Now, shitloads of people have cut their undergraduate teeth trying and failing to build distributed chat applications.
            
-
            [23:30] <jrand0m> ok, so someone should either help thecrypto out or push him along some more :) 
            
-
            [23:30] * Ophite1 points out IRC3
            
-
            [23:30] <jrand0m> yeah, its a perfect school project 
            
-
            [23:30] <Ophite1> ..and SILC...
            
-
            [23:30] <Ophite1> ...and...
            
-
            [23:31] <Ophite1> well about a gazillion others.
            
-
            [23:31] <jrand0m> 'zactly 
            
-
            [23:31] <Ophite1> Literally all of these, I might add, are pre-DHT as far as I can tell.
            
-
            [23:31] <jrand0m> yup 
            
-
            [23:31] <Ophite1> That's disappointing 'cause that's a freakishly useful structure.
            
-
            [23:31] <jrand0m> a DHT for lookup / P3P, and then direct con for IM 
            
-
            [23:31] <jrand0m> group chat is harder though, but not too hard 
            
-
            [23:31] <Ophite1> well, direct in the i2p sense :)
            
-
            [23:31] <jrand0m> heh right 
            
-
            [23:32] <Ophite1> what about darkmail/i2pmail?
            
-
            [23:32] <soros> group sex too
            
-
            [23:32] <dm> soros: agreed.
            
-
            [23:32] <jrand0m> group sex isn't that hard soros ;) 
            
-
            [23:32] <jrand0m> lol 
            
-
            [23:32] <jrand0m> email over i2p is easy.  someone just needs to run a pop server 
            
-
            [23:32] <jrand0m> or webmail 
            
-
            [23:32] <jrand0m> hahah 
            
-
            [23:33] <Ophite1> jrand0m: sure, as long as literally everyone is okay with bloody pgp :)
            
-
            [23:33] * Ophite1 gets CKT nightmares again
            
-
            [23:33] <jrand0m> oh, true.  that'd expose the contents to hte server ;) 
            
-
            [23:33] <Ophite1> Also... spam.
            
-
            [23:33] <jrand0m> yup 
            
-
            [23:33] <Ophite1> We have this thing called hashcash.
            
-
            [23:33] <Ophite1> They sort of fit together, no?
            
-
            [23:34] <jrand0m> ok, so yeah, someone should get working on an i2p specific email app :) 
            
-
            [23:34] <Ophite1> obviously that would work best as part of the im.
            
-
            [23:34] <Ophite1> What, after all, is the distinction between irc and email?
            
-
            [23:34] <jrand0m> true, like an IM VMB 
            
-
            [23:34] <Ophite1> Whether or not you can page up and see what you missed after you rejoin...
            
-
            [23:34] <jrand0m> placed into the dht 
            
-
            [23:34] <jrand0m> good point 
            
-
            [23:35] * jrand0m wishes we had a team of a dozen coders
            
-
            [23:35] <Ophite1> note, however, that mail requires storage, as it is offline communication. irc requires no storage, as it is online communication.
            
-
            [23:35] <dm> also email has a lot more penis enlargement adverts.
            
-
            [23:35] <Ophite1> jrand0m: ask around for funding.
            
-
            [23:35] <Ophite1> dm: see above re: hashcash.
            
-
            [23:35] <jrand0m> right, the P3P could contain pending messages 
            
-
            [23:36] <Ophite1> dm: A primitive that was not available to the bloke who hacked up email in a night.
            
-
            [23:36] <Ophite1> (At least we won't have to use ! paths to specify the tunnel manually. heh. heh. heh.)
            
-
            [23:36] * dm is gonna miss clear-text dead simple protocols.
            
-
            [23:36] <jrand0m> jrandom%ophite!dm!mihi 
            
-
            [23:37] <Ophite1> no, this is i2p. Insert ~520 garbage characters between the bangs then you're closer ;)
            
-
            [23:37] <jrand0m> haha 
            
-
            [23:37] <Ophite1> several of these things *are* sort of related.
            
-
            [23:37] <jrand0m> true, 387 bytes base64 encoded... 
            
-
            [23:38] <Ophite1> or to put it another way, ELONGURL :)
            
-
            [23:38] <jrand0m> heh 
            
-
            [23:38] <Ophite1> [does IE chop at 512?]
            
-
            [23:38] <jrand0m> naw, works fine 
            
-
            [23:38] <Ophite1> you admit to using IE?
            
-
            [23:38] <Ophite1> To browse anonymously?!
            
-
            [23:38] <jrand0m> ;) 
            
-
            [23:38] * Ophite1 pulls out six of Liu De Yiu's best and waits =)
            
-
            [23:38] * jrand0m uses ie for eppsites, moz for squiding
            
-
            [23:39] <duck> what item are we now?
            
-
            [23:39] <duck> 4?
            
-
            [23:39] <jrand0m> yeah, ok ok 
            
-
            [23:39] <Ophite1> still 4 I think.
            
-
            [23:39] <jrand0m> i2ptunnel.  still kicks ass. 
            
-
            [23:39] <jrand0m> any thoughts?  any comments mihi? 
            
-
            [23:40] <jrand0m> one thing I want to note wrt the squid outproxy is that I've updated the header filtering to ALLOW COOKIES and replace the user agent with something silly  
            
-
            [23:40] * mihi just waits for naming service...
            
-
            [23:40] <jrand0m> mihi (or someone else)> it'd be really easy to bootstrap such a naming service with an /etc/hosts style i2p ns 
            
-
            [23:41] <mihi> btw: are there any other public dests except your squid and tc's eepsite?
            
-
            [23:41] <jrand0m> i2pcvs.dest 
            
-
            [23:41] <jrand0m> (points at the i2p cvs pserver) 
            
-
            [23:41] <jrand0m> (but isn't always up) 
            
-
            [23:41] *** yodel (yodel@anon.iip) has joined channel #iip-dev
            
-
            [23:41] <jrand0m> hola yodel 
            
-
            [23:41] <yodel> hela
            
-
            [23:42] <jrand0m> ok, I think thats it for 4) apps 
            
-
            [23:42] <jrand0m> 5) comments / questions / etc 
            
-
            [23:42] <mihi> gui installer?
            
-
            [23:42] <TC> hi yodel
            
-
            [23:43] <yodel> I have to start experimenting putting the xml-rpc over i2p
            
-
            [23:43] <yodel> should work with httptunnel
            
-
            [23:43] <jrand0m> good question mihi.  last I heard MrEcho had some of it working 
            
-
            [23:43] <jrand0m> awesome yodel 
            
-
            [23:43] <jrand0m> definitely. 
            
-
            [23:43] <jrand0m> how large are the streams? 
            
-
            [23:43] <jrand0m> (aka how chatty is the protocol?) 
            
-
            [23:44] * Ophite1 plans to try BitTorrent over I2P as a stress test
            
-
            [23:44] <yodel> xml over http
            
-
            [23:44] <yodel> the ssl layer wont be needed with i2p
            
-
            [23:44] <Ophite1> so, uh, very chatty? :)
            
-
            [23:44] <jrand0m> ah cool, large POST or large replies? 
            
-
            [23:44] <jrand0m> (or just small and small?) 
            
-
            [23:45] <jrand0m> damn you Ophite1 :) 
            
-
            [23:45] <yodel> equal sizes
            
-
            [23:45] <yodel> does httptunnel support gzipped http?
            
-
            [23:45] <jrand0m> but doesn't bt use IP addresses? 
            
-
            [23:45] <jrand0m> hmm, httptunnel doesn't have any inherent compression, its just a bitstream 
            
-
            [23:45] <TC> hmm, package i2p+ppp\vpn+gui as a security solution for wireless windows shares
            
-
            [23:45] <yodel> so should work...
            
-
            [23:45] <godmode0> jrand0m> you test i2p in nntp news server ?
            
-
            [23:45] <jrand0m> yup yodel 
            
-
            [23:45] <yodel> 500-1000 byte send, same for reply
            
-
            [23:46] <jrand0m> hmm I haven't tested that yet godmode0 
            
-
            [23:46] <yodel> much less when zipped
            
-
            [23:46] <jrand0m> oh cool yodel, that'll work without any problem 
            
-
            [23:46] <yodel> what is the latency for a single msg/package/whatever?
            
-
            [23:46] <jrand0m> 2-5s, sometimes up to 10s 
            
-
            [23:46] <jrand0m> (currently) 
            
-
            [23:46] <Ophite1> not bad for a pre-dht :)
            
-
            [23:46] <yodel> so 20s roundtime?
            
-
            [23:47] <jrand0m> I usually pull up a web page in 5-10s 
            
-
            [23:47] <yodel> ah
            
-
            [23:47] <yodel> goo
            
-
            [23:47] <yodel> +d
            
-
            [23:48] <jrand0m> damn, we're coming up to the 2 hour mark.  anyone have any other questions / thoughts? 
            
-
            [23:48] <Ophite1> Pie is good.
            
-
            [23:48] <duck> jrand0m: why do you drink cheap local beer?
            
-
            [23:48] <Ophite1> Orgy and pie is better.
            
-
            [23:48] <jrand0m> rofl duck 
            
-
            [23:49] <Ophite1> duck: It's better than Tesco Value Lager?
            
-
            [23:49] * Ophite1 spits from reflex
            
-
            [23:49] <jrand0m> heh 
            
-
            [23:49] * duck is concerned about jrand0m's health
            
-
            [23:49] <jrand0m> you're concerned about my cheap beer habits but not my good whiskey habits? 
            
-
            [23:50] * Ophite1 reminds about the single malt on Cary Sherman's head
            
-
            [23:50] <duck> do you eat well?
            
-
            [23:50] <godmode0> corona
            
-
            [23:50] <duck> do you do your daily exercises?
            
-
            [23:50] <jrand0m> well, i'm one of those veggies 
            
-
            [23:50] <Ophite1> Isn't that a personal question, duck?
            
-
            [23:50] <jrand0m> does typing count? 
            
-
            [23:50] <duck> you did drink that much already?
            
-
            [23:50] <duck> that you became a veggie
            
-
            [23:50] <jrand0m> heh 
            
-
            [23:50] <Ophite1> cheap beer will do that.
            
-
            [23:51] <duck> Ophite1: jrand0m's health should concern us all, since it is essential for I2P
            
-
            [23:51] *** Signoff: mihi_backup (mihi hands jrand0m the *BAF*er)
            
-
            [23:51] <jrand0m> heh ok ok mihi 
            
-
            [23:51] * jrand0m winds up
            
-
            [23:51] * jrand0m *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting66.html b/www.i2p2/pages/meeting66.html
deleted file mode 100644
index 7758f3f2..00000000
--- a/www.i2p2/pages/meeting66.html
+++ /dev/null
@@ -1,477 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 66{% endblock %}
-{% block content %}
            Tuesday, November 26, 2003 22:00:00 CET
            
-
            
-
            [22:04] <jrand0m> agenda: 
            
-
            [22:04] <jrand0m> 0) welcome 
            
-
            [22:04] <jrand0m> 1) status 
            
-
            [22:04] <jrand0m> 2) transport futures 
            
-
            [22:05] <jrand0m> 3) peer stats for selection 
            
-
            [22:05] <jrand0m> 4) apps 
            
-
            [22:05] <jrand0m> 5) ...? 
            
-
            [22:05] <jrand0m> 0) 
            
-
            [22:05] <jrand0m> hi. 
            
-
            [22:05] <jrand0m> 66 is it? 
            
-
            [22:05] <duck> 7) what brand of whiskey does jrand0m drink?
            
-
            [22:06] <jrand0m> bushmills, glenlivit 
            
-
            [22:06] <jrand0m> (for whiskey and whisky, respectively) 
            
-
            [22:06] <TC> yey, i made the meating
            
-
            [22:06] <jrand0m> woot 
            
-
            [22:06] <jrand0m> ok, 1) status 
            
-
            [22:06] <jrand0m> the kademlia stuff is coming along very well. 
            
-
            [22:07] <jrand0m> I've build a little simulator that runs a network of five nodes and puts them through the basic tests 
            
-
            [22:07] <jrand0m> also the idn stuff is implemented with some tests as well 
            
-
            [22:08] <jrand0m> the last two days or so have been focused on making sure the kademlia code works for both idn and for the i2p netdb, which has caused a bunch of changes 
            
-
            [22:09] <jrand0m> actually, the big change is that I'm forcing myself to be practical and make the kademlia code work first with the netDb and /then/ think about the idn stuff. 
            
-
            [22:10] <jrand0m> idn right now is kind of functional, except for inter-node comm (which will be replaced with comm over i2p, of course ;) 
            
-
            [22:10] <TC> idn is the stuff for the distributed storage?
            
-
            [22:10] <jrand0m> roadmap has been updated as well - http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap 
            
-
            [22:10] <jrand0m> yes 
            
-
            [22:10] <jrand0m> idn = Invisible Distribution Network 
            
-
            [22:10] <jrand0m> (free open source anonymous akamai, basically) 
            
-
            [22:11] <TC> is there a non anonymous public akamai implemintation i could play with?
            
-
            [22:11] *** leenookx (~leenookx@anon.iip) has joined channel #iip-dev
            
-
            [22:12] <jrand0m> mnet is probably up that alley 
            
-
            [22:12] *** Signoff: nickthief60934 (Excess Flood)
            
-
            [22:12] <jrand0m> before I jump back into the router completely, I'm planning on leaving the idn code in a state that /hopefully/ someone would be able to jump in and make that into a usable app. 
            
-
            [22:13] *** dm (~sd@anon.iip) has joined channel #iip-dev
            
-
            [22:14] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [22:14] <jrand0m> if you see the roadmap, kademlia has been pushed into the 0.2.2 release.  in addition, there are also two big outstanding things that I hope to have in there, fixing a pair of bugs that do annoying things 
            
-
            [22:14] <TC> would it be posible do image grabs do idn from an i2ptunnel eepsite?
            
-
            [22:15] <jrand0m> hmm? 
            
-
            [22:15] <jrand0m> oh, like <img src="idn:blah">? 
            
-
            [22:15] <TC> i was just thinking of bandwidth saving, yes
            
-
            [22:15] <Ophite1> protocol would be the obvious way to go, yes.
            
-
            [22:16] <jrand0m> hmm Ophite1? 
            
-
            [22:17] <jrand0m> (sorry, I'm sick again so might not be quite on top of my game today) 
            
-
            [22:17] <dm> how many LOC have you written jr?
            
-
            [22:17] <TC> Ophite1, could i2p tunnel be modified to redirect?
            
-
            [22:18] <TC> or could the browser do it on its own somehow?
            
-
            [22:18] <jrand0m> dm> "find . -exec grep \\\; {} \; | wc -l" currently puts the sdk ~8kloc, the router ~11kloc 
            
-
            [22:18] <dm> okay thanks.
            
-
            [22:19] <jrand0m> idn would want to support receiving requests from browsers. 
            
-
            [22:19] <Ophite1> would mean integrating idn into i2ptunnel. very ugly.
            
-
            [22:19] <jrand0m> currently idn has a so-god-damn-easy api. 
            
-
            [22:19] <jrand0m> the api is the file system. 
            
-
            [22:19] <jrand0m> aka:  
            
-
            [22:19] <jrand0m> command=get 
            
-
            [22:19] <jrand0m> key=zGb1tPM6ARNRTWZLCWK4XXco2Ngk8ccx-ciDUCom~9U 
            
-
            [22:19] <jrand0m> saveAs=testGetOutput.txt 
            
-
            [22:20] <jrand0m> place that in a file in a directory, and voila. 
            
-
            [22:20] <jrand0m> (that was the easiest possible for me to implement and test with.  certainly better ones can be found and made) 
            
-
            [22:21] <jrand0m> ok, so, yeah.  thats the status.  I'm hoping for a 0.2.2 release by this time next week, at least. 
            
-
            [22:22] <jrand0m> that'll include the first integration of the kademlia stuff, tunnel fixes, and i2cp updates. 
            
-
            [22:23] <jrand0m> ok, 2) transport futures 
            
-
            [22:23] <jrand0m> I don't like our tcp transport.  and our udp transport is disabled.  and our phttp transport is tweaky. 
            
-
            [22:23] * jrand0m would like to see the tcp transport replaced with tls / ssl / some-other-standard
            
-
            [22:24] <Ophite1> link-level encryption is a requirement?
            
-
            [22:24] <jrand0m> absolutely. 
            
-
            [22:25] <Ophite1> tls is _hell_ though. ask openssl.
            
-
            [22:25] <tonious> ssh?
            
-
            [22:25] <Ophite1> that, too.
            
-
            [22:25] <jrand0m> yeah, I followed the nasty discussions on the cryptography list last month, with interest. 
            
-
            [22:25] <jrand0m> ssh is definitely a possibility. 
            
-
            [22:26] <jrand0m> safe, too, since we already essentially have the certificates (in the RouterInfo.publicKey) 
            
-
            [22:26] <Ophite1> but we're in java. we'd have to code it ourselves? :/
            
-
            [22:26] <jrand0m> naw, there are ssl, tls, and ssh java libs 
            
-
            [22:26] *** Signoff: nickthief60934 (Ping timeout)
            
-
            [22:26] <tonious> There's already at least one java ssh client.  Dunno about servers.
            
-
            [22:26] <Ophite1> re: security of such libs, given numerous high profile holes in openssl, openssh, et al?
            
-
            [22:27] <jrand0m> Ophite1> most likely better than custom built code. 
            
-
            [22:27] <jrand0m> not that I have any reason to think there are exploits in the tcp transport as written. 
            
-
            [22:27] <jrand0m> but it has not been reviewed. 
            
-
            [22:28] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [22:28] <jrand0m> in any case, updating the transports isn't really on deck until january (after the 0.3 release goes out) 
            
-
            [22:28] <jrand0m> but if anyone wants to look into it and do some research, that'd be great 
            
-
            [22:29] <TC> how many devs do we have activly coding?
            
-
            [22:29] <dm> 1! :)
            
-
            [22:29] <jrand0m> you can see who commits via (Link: http://i2p.dnsalias.net/pipermail/i2p-cvs/2003-November/thread.html)http://i2p.dnsalias.net/pipermail/i2p-cvs/2003-November/thread.html 
            
-
            [22:29] <tonious> But he's got the strength of ten men....
            
-
            [22:30] <jrand0m> mihi has been cleaning up some of my messes, thankfully :) 
            
-
            [22:30] <dm> haha, it's all jrandom :)
            
-
            [22:30] <dm> nice way of saying "just me"
            
-
            [22:31] <dm> I noticed that about mihi, when he got involved in frazaa, he just showed up one day and started cleaning up my (horrid) java. It was quite entertaining.
            
-
            [22:31] <jrand0m> heh 
            
-
            [22:31] <Ophite1> people like that are very, very useful :)
            
-
            [22:32] <jrand0m> quite 
            
-
            [22:32] <dm> "who's writing all these catch statements who do nothing ;)" -mihi
            
-
            [22:32] <jrand0m> d'oooh 
            
-
            [22:33] <Ophite1> it's cause of reminders like that the code won't get as bad as freenet (we hope?) :)
            
-
            [22:33] <jrand0m> if in 5 years any of the current i2p code is still in use, I'll be shocked. 
            
-
            [22:34] <jrand0m> (it had better be ported into finely tuned ASM code by then!) 
            
-
            [22:34] * Ophite1 makes his "java implementation is just a prototype" speech
            
-
            [22:34] <dm> well, if you're still working on it 4 years from now, I'll guarantee that It'll be in use 5 years from now :)
            
-
            [22:34] <TC> heh, comment it out and leave it in place
            
-
            [22:35] <dm> is there a link to see the source on the web? not just the changes.
            
-
            [22:35] <jrand0m> yes dm, http://i2p.dnsalias.net/ 
            
-
            [22:35] <dm> nm, found it.
            
-
            [22:35] <jrand0m> :) 
            
-
            [22:35] <jrand0m> ok, 4) peer stats for selection 
            
-
            [22:36] <jrand0m> calling this a nebulus topic is one hell of an understatement. 
            
-
            [22:36] <jrand0m> doctoral theses could be written (and some have been) on how to choose what peers to use in an untrusted environment. 
            
-
            [22:36] <dm> public interface Job
            
-
            [22:36] <dm> oops, meeting. Sorry didn't realize.
            
-
            [22:37] <jrand0m> the good part is that half of our peer selection is already taken care of - the selection of peers to find other peers. 
            
-
            [22:37] <jrand0m> (thats the kademlia stuff) 
            
-
            [22:38] <jrand0m> the part thats left is the selection of peers to participate in tunnels, to route garlics, and to bounce replies through 
            
-
            [22:38] *** Signoff: dm (EOF From client)
            
-
            [22:38] *** Signoff: TC (EOF From client)
            
-
            [22:38] *** Signoff: leenookx (EOF From client)
            
-
            [22:38] <jrand0m> what I'm thinking for 0.3 is just going to be a simple history of each peer, tested periodically 
            
-
            [22:39] *** TC (~TC@anon.iip) has joined channel #iip-dev
            
-
            [22:39] *** leenookx (~leenookx@anon.iip) has joined channel #iip-dev
            
-
            [22:39] <jrand0m> stats revolving around  latency and uptime 
            
-
            [22:39] *** Signoff: soros (Client exiting)
            
-
            [22:39] <Ophite1> suggest you be wary of including accurate information about bandwidth usage and latency in that stats.
            
-
            [22:40] <Ophite1> as per my drunken questions.
            
-
            [22:40] <Ophite1> perhaps a more indirect route, but it's an area that needs very careful, well considered attention.
            
-
            [22:40] <jrand0m> hmm, with the intent of keeping the accurate info unknown, or to defeat predictabilities? 
            
-
            [22:40] <jrand0m> right 
            
-
            [22:41] <jrand0m> this discussion is for a release that won't go out until at least jan 1 
            
-
            [22:42] * jrand0m understands and agrees that we want to avoid the predictabilities
            
-
            [22:42] <jrand0m> but I think we want to gather and use as accurate info as we can, /then/ adjust for entropy 
            
-
            [22:42] <Ophite1> mere entropy alone may not be enough.
            
-
            [22:43] <Ophite1> but, I need more research on this :/
            
-
            [22:43] <jrand0m> true - randomly deciding to garlic route a message rather than tunnel route it, or to use a sequence of tunnels instead of one directly, etc 
            
-
            [22:44] <jrand0m> no rush, just wanted to plant the subject in the minds of those out there :) 
            
-
            [22:44] <jrand0m> ok, 4) apps 
            
-
            [22:45] <Ophite1> been troubling me for a week or more; though, I'm happy to announce I've run into a brick wall so far :)
            
-
            [22:45] <jrand0m> w00t :) 
            
-
            [22:45] <Ophite1> inclusion of accurate or accurate+some%entropy statistics may make some attacks work though.
            
-
            [22:46] <TC> oh, before apps i have a question
            
-
            [22:46] <jrand0m> well, its always easy enough to simply discard accurate info as necessary 
            
-
            [22:46] *** Signoff: nickthief60934 (Excess Flood)
            
-
            [22:46] <jrand0m> sure tc, whats up? 
            
-
            [22:46] <jrand0m> (stats will also (hopefully) make it easier to debug the network's operation while in development) 
            
-
            [22:46] <TC> when are manditory minium hop counts (or something like it) going to start?>
            
-
            [22:47] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [22:47] <jrand0m> right now the default minimum tunnel length is one non-local hop 
            
-
            [22:47] *** dm (~sd@anon.iip) has joined channel #iip-dev
            
-
            [22:47] * TC didnt know that
            
-
            [22:48] <Ophite1> which is okay as long as the non-local hop doesn't KNOW it's the only non-local hop.
            
-
            [22:48] <jrand0m> that will be up'ed to 2-4 once things are more reliable 
            
-
            [22:48] <jrand0m> right Ophite1 
            
-
            [22:48] <Ophite1> still one better than a gnunet shortcut, so it's cool :)
            
-
            [22:48] <TC> oh, and how do speed improvements look?
            
-
            [22:48] * jrand0m is basing that 2-4 # on o-r comments
            
-
            [22:49] <Ophite1> temporary stats for network testing are okay by me, and very useful, but please bear in mind they may be a dangerous feature for production anonymity.
            
-
            [22:49] <jrand0m> hmm, speed improvements will come through more reliable and faster peer selections, which is the 0.3 release 
            
-
            [22:49] <dm> jeez, I forgot how jr's code looks like it was written by a robot.
            
-
            [22:49] <dm> Hmmm, that would explain a lot.
            
-
            [22:50] <Ophite1> and through more scalable routing, which is next weeks' :)
            
-
            [22:50] <jrand0m> heh sorry dm, I'll try to be more inconsistent ;) 
            
-
            [22:50] <Ophite1> (did I just mean discovery?)
            
-
            [22:50] <jrand0m> right, its discovery, not routing, really. 
            
-
            [22:51] <jrand0m> i2p is scale free for normal comm. 
            
-
            [22:51] <jrand0m> (and o(log(n)) for discovery) 
            
-
            [22:51] <TC> i think your average ai who lives on the net would be pro i2p, what do you think dm?
            
-
            [22:52] <dm> I think the average method size in this code is the smallest I've ever seen is what I think.
            
-
            [22:53] <Ophite1> dm: clean. very good for a proto :)
            
-
            [22:53] <dm> Do you comment as you go or do you go back and put those descriptions?
            
-
            [22:53] <jrand0m> I comment when I get confused 
            
-
            [22:54] <jrand0m> (I really can't wait until collections are typesafe) 
            
-
            [22:54] <jrand0m> but, yeah, 4) apps :) 
            
-
            [22:54] <jrand0m> (unless anyone else has router / network questions?) 
            
-
            [22:55] <TC> pnope
            
-
            [22:55] <jrand0m> ok, wiht isn't here, anyone else have any naming service thoughts / comments (mrecho?) 
            
-
            [22:55] <TC> a distributed naming server?
            
-
            [22:56] <dm> is wiht ever here?
            
-
            [22:56] <tonious> It could probably just sit on top of IDN.
            
-
            [22:56] <jrand0m> yeah, I'd really love to see the naming service be a dht (perhaps reusing the idn / kademlia code) containing CA signed entries 
            
-
            [22:56] <TC> did co die?
            
-
            [22:56] <jrand0m> exactly tonious 
            
-
            [22:57] <jrand0m> perhaps you're right, it could be an app that /uses/ idn, not just uses the code.  hmmm... 
            
-
            [22:57] <jrand0m> that'd be Good. 
            
-
            [22:57] <tonious> Mebbe have a key fingerprint associated in case of collisions.
            
-
            [22:57] <jrand0m> naw, co/wiht is around every few days 
            
-
            [22:57] <tonious> Wouldn't even necessarily need a centralized CA?
            
-
            [22:57] <jrand0m> we'd need a CA if nyms are unique. 
            
-
            [22:58] <Ophite1> The CA signing chain should elminiate collisions.
            
-
            [22:58] <jrand0m> (and we need nyms to be unique to do naming, really) 
            
-
            [22:58] <Ophite1> of course this makes CA key very important.
            
-
            [22:58] <TC> how about dys dns? can i make my host file redirect to a eepsite?
            
-
            [22:59] <tonious> TC: Not really.  The OS doesn't even see i2p.
            
-
            [22:59] <jrand0m> though we could have $nym.$ca be the thing looked up for 
            
-
            [22:59] <Ophite1> perhaps so important we want to distribute trust by it signing some second level .*.i2p domains, and have virtually all stuff under that, *.*.i2p - i.e., jrand0m.nym.i2p
            
-
            [22:59] <jrand0m> right, though with tusko's ppp2p we can get i2p to IP mappings 
            
-
            [23:00] <tonious> I dunno.  The idea of a CA in an essentially distributed system disagrees with me.
            
-
            [23:00] <tonious> Not bein' a developer though I'm not gonna make a fuss :)
            
-
            [23:01] <TC> dns really isnt that importent
            
-
            [23:01] <jrand0m> tonious> we can do a web of trust, essentially.  with, say, 8 seperate known CAs, everyone's local name server knows about those 8, and each of them manages a subdomain (e.g. tc.ca1 or Nightblade.ca2, or we add a .i2p at the end) 
            
-
            [23:01] <Ophite1> if you can think of a better way?
            
-
            [23:02] <Nostradumbass> i have another question - its sort of spans the network-application area.
            
-
            [23:02] <jrand0m> (thats really the degenerate case of a WoT) 
            
-
            [23:02] <Ophite1> what I said, sort of - get a root key to sign domains...
            
-
            [23:02] <jrand0m> agreed tc 
            
-
            [23:02] <jrand0m> fire away Nostradumbass 
            
-
            [23:02] <Ophite1> someone gets com.i2p or nym.i2p...
            
-
            [23:02] <Nostradumbass> has any thought been goven to guaranteed latency?
            
-
            [23:02] <Ophite1> allow them to sign jrand0m.nym.i2p, or whatever.
            
-
            [23:02] <Nostradumbass> i'm thinking of VoIP.
            
-
            [23:03] <jrand0m> Ophite1> we wouldn't even need a .i2p key with that 
            
-
            [23:03] <tonious> Ophite1: What if the com ca gets taken out by an RIAA hitsquad or something?
            
-
            [23:03] <jrand0m> Nostradumbass> you mean VoI2P?  :) 
            
-
            [23:03] <Ophite1> then once you're done, destroy the master CA.
            
-
            [23:03] <Nostradumbass> yes
            
-
            [23:03] <Ophite1> tonious: then there's still the others.
            
-
            [23:04] <Ophite1> or some system that requires conspiring groups to get the nym signing key?
            
-
            [23:04] <jrand0m> Nostradumbass> we have already had people run shoutcast streams over i2p with some buffering at 96khz and no buffering problems at less speed.  but there's latency. 
            
-
            [23:04] <Nostradumbass> with the upcoming release of cryptophone's (Link: http://www.cryptophone.de/)http://www.cryptophone.de/ source it could make an interesting app for i2p.
            
-
            [23:04] <Ophite1> and a really freakin' big hashcash?
            
-
            [23:04] <jrand0m> definitely Nostradumbass 
            
-
            [23:04] <tonious> Ophite1: Mebbe a majority signing protocol?
            
-
            [23:04] *** Signoff: dm (Ping timeout)
            
-
            [23:04] <jrand0m> tonious> majority is dangerous with sybil 
            
-
            [23:05] <Ophite1> tonious: otoh, it HAS to be non-repudiatory, and has to be able to guarantee non-collision.
            
-
            [23:05] <Ophite1> and majority couldn't do that.
            
-
            [23:05] <Ophite1> a majority of well known users maybe.
            
-
            [23:05] <Ophite1> if it's a consolation, the internet has problems with this too (think Verisign).
            
-
            [23:05] <jrand0m> right, WoT :) 
            
-
            [23:06] <Ophite1> but then WoT means that different people might have different ideas of who to trust, which violates non-collision maybe?
            
-
            [23:06] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev
            
-
            [23:06] <jrand0m> Nostradumbass> now if we could get some coders to work on a high performance RTSP over i2p tunnel... ;) 
            
-
            [23:06] <Ophite1> it's important, given the length of an "I2P address", but also hard.
            
-
            [23:06] *** Drak0h (~Dr4k0h@anon.iip) has joined channel #iip-dev
            
-
            [23:07] <Ophite1> Nostradumbass: not guaranteed.
            
-
            [23:07] <TC> so how do we secure alias identification (important for commerce and seting up multiple eepsites)?
            
-
            [23:07] <Nostradumbass> over-provisioning of bandwidth is often the only simple way to try and guarantee latency.  is there going to ba any way for a node to determine the available bandwidht at another node, so as to ease routing for VoIP apps? 
            
-
            [23:07] <jrand0m> yes Nostradumbass, QoS can be done transparently within i2p, but unfortunately thats (I hate saying this) > 1.0 
            
-
            [23:07] <tonious> Say we take root CAs out of it.  You generate your key and sign your aliases.
            
-
            [23:08] *** Signoff: thecrypto (EOF From client)
            
-
            [23:08] <Ophite1> Nostradumbass: also, troublesome re some potential attacks?
            
-
            [23:08] <tonious> You also specify who's keys you trust, ala PGP.  I think redundancy is more important than collision.
            
-
            [23:08] <Ophite1> tonious: so which jrand0m.nym.i2p did you want again?
            
-
            [23:08] * jrand0m attacks the ns dht to get my nym back
            
-
            [23:08] <Ophite1> if everyone doesn't trust the same, we might not be referring to the same thing when we use the same name.
            
-
            [23:09] <Ophite1> and it would probably allow freenet-KSK-style collision wars.
            
-
            [23:09] <jrand0m> right.  either the naming service has CA signed nyms, or it just distributes H(destination) --> destination mappings 
            
-
            [23:09] <tonious> Just pop up a menu or something.  Or if you're designing an application that talks to a specific server, give it the public key of the signing agent?
            
-
            [23:10] <jrand0m> (and H(destination) == 42 chars as opposed to ~500 chars for a destination) 
            
-
            [23:10] <Ophite1> tonious: if you're going to give it public keys, you might as well just sling around I2P addresses.
            
-
            [23:10] <Ophite1> now that's an interesting ideal
            
-
            [23:10] <Ophite1> assuming sha-256 can't be reversed that yields 256-bit I2P addresses that could be "looked up" to reveal the structure.
            
-
            [23:10] *** dm (~sd@anon.iip) has joined channel #iip-dev
            
-
            [23:11] <Ophite1> I smell kademlia again.
            
-
            [23:11] <jrand0m> :) 
            
-
            [23:11] <Ophite1> It can also be simply checked.
            
-
            [23:11] <jrand0m> and there's existing code to reuse. 
            
-
            [23:11] <Ophite1> somehow, that makes sense. why weren't we doing this already? :)
            
-
            [23:11] <jrand0m> because we want nyms 
            
-
            [23:12] <Ophite1> nyms for hosts?
            
-
            [23:12] <jrand0m> but, I suppose, 42 chars is a good enough starting point 
            
-
            [23:12] <Ophite1> need a root CA for that :/
            
-
            [23:12] <jrand0m> right 
            
-
            [23:12] <Ophite1> in the case where you don't want to trust a root ca?
            
-
            [23:12] <Ophite1> 42 chars is short enough to paste.
            
-
            [23:12] <jrand0m> you don't need a root CA, you can have a forest instead of a tree 
            
-
            [23:12] <Ophite1> 520 chars isn't :)
            
-
            [23:12] <jrand0m> heh 
            
-
            [23:13] <Ophite1> but if you have a forest, how does anyone know which tree you're talking about?
            
-
            [23:13] <Ophite1> you could slap a key in there, but then, ooh, we've got huge strings of random garbage again.
            
-
            [23:13] <jrand0m> common suffix.  $nym.$ca 
            
-
            [23:13] <Ophite1> well, I'd like $nym.$ca.i2p :)
            
-
            [23:13] <Ophite1> avoid confusion :)
            
-
            [23:13] <jrand0m> right.  I mean, there are possible attacks.  I dunno.  I'm with TC though  
            
-
            [23:13] <jrand0m> good 'nuff for me  
            
-
            [23:14] <jrand0m> ok, /other/ apps :) 
            
-
            [23:14] <Ophite1> how do you know which ca is which?
            
-
            [23:14] <Ophite1> you have a list? what signs the list?
            
-
            [23:14] <jrand0m> i2pns.config 
            
-
            [23:14] *** Signoff: Drak0h (Ping timeout)
            
-
            [23:14] <Ophite1> how're you going to get that?
            
-
            [23:14] <TC> if i could make my own dns list, hostfile style i would be happy
            
-
            [23:14] <jrand0m> on install 
            
-
            [23:15] <Ophite1> how are you going to verify those are the "right" keys?
            
-
            [23:15] <Ophite1> ca substitution?
            
-
            [23:15] <jrand0m> right tc, we can even do that without any distributed naming service 
            
-
            [23:15] <TC> because i say they are Ophite1
            
-
            [23:15] <jrand0m> Ophite1> you aren't, any more than you're verifying that the source code is running the "real" i2p 
            
-
            [23:15] <TC> and if you trust me, you can download them off my eepsite
            
-
            [23:16] <Ophite1> I suppose at the end of the day you can only reduce that to trust in one key being right, so :)
            
-
            [23:16] <Ophite1> works for me, yeah.
            
-
            [23:16] <Ophite1> as long as I get o1.i2p ;)
            
-
            [23:16] <jrand0m> heh 
            
-
            [23:17] <tonious> Hmm.  Revised threshold scheme:  Each CA works the entire namespace, but a majority of CAs must agree before handing out subspace?
            
-
            [23:17] <jrand0m> ok, last I heard tusko had found a way to get the ppp2p to run off windows machines as well as *nix 
            
-
            [23:17] <TC> it would make the i2p\internet doman system much more community based if we all passed around a huge hostfile\cheat sheet
            
-
            [23:17] <Ophite1> tonious: back to majority again...
            
-
            [23:17] <jrand0m> scary for attacks tonious 
            
-
            [23:17] <jrand0m> thats true TC 
            
-
            [23:17] <jrand0m> (and the value of such a community should not be underestimated) 
            
-
            [23:18] <Ophite1> tc: arpanet stylee?
            
-
            [23:18] <tonious> Sigh. :)
            
-
            [23:18] <Ophite1> I guess seeds have gotta come from somewhere, so yeah ;)
            
-
            [23:18] <TC> to get a domain name, you would say this is me, and if people agreed they would change the file, and if they where trusted, others would download updates
            
-
            [23:19] <jrand0m> sounds like that'd be a heavily retrieved key from idn :) 
            
-
            [23:19] <Ophite1> smells vaguely ca-like too :)
            
-
            [23:19] <TC> you could even have a fight, with more then one file
            
-
            [23:19] <Ophite1> the fidonet nodelist!
            
-
            [23:19] <tonious> And in case of a netsplit there'd be multiple patchfiles.
            
-
            [23:19] <Ophite1> ...doesn't scale.
            
-
            [23:19] <jrand0m> with under a few hundred domains, its maintainable manually 
            
-
            [23:20] <TC> after a few hundred you go trusted
            
-
            [23:20] <jrand0m> right Ophite1.  this would just be until we argue out the Right Way. 
            
-
            [23:20] <tonious> It might be enough to jumpstart a WoT.
            
-
            [23:20] <jrand0m> (or we convince people that CAs aren't that bad ;) 
            
-
            [23:20] <jrand0m> true tonious 
            
-
            [23:20] <Ophite1> if you're trusting someone to agree that someone is someone else, that's a CA, not just a nodelist :)
            
-
            [23:21] <tonious> Heh.  Sorry for bein' the skeptic.
            
-
            [23:21] <TC> jrand0m, in the end i dont whant to be dependent on CA's
            
-
            [23:21] <Ophite1> just allow people to give space below theirs...
            
-
            [23:21] <Ophite1> castyle -- and those on the nodelist to be the cas.
            
-
            [23:21] <Ophite1> course then it's all "which ca is jrand0m on?"
            
-
            [23:21] <jrand0m> CA's aren't necessarily choke points.  if they're unsatisfactory, we replace them.   
            
-
            [23:22] <tonious> Ophite1: I like that.
            
-
            [23:22] <Ophite1> point. CA being crapped out would be Big Enough News for someone to simply replace them.
            
-
            [23:22] <Ophite1> tonious: so is it slashdot.org or slashdot.com? goatse.cx? :)
            
-
            [23:22] <dm> what does CA stand for? :)
            
-
            [23:22] <Ophite1> certification authority.
            
-
            [23:23] <dm> k, thanks.
            
-
            [23:23] <tonious> Heh.  That's where your own WoT comes in, Ophite1.
            
-
            [23:23] <Ophite1> tonious: yes, but I still have to see goatse once before I realise it's the wrong bloody one. :)
            
-
            [23:23] <tonious> 'I trust Ophite1 not to show that horrible asshole, and he signed slashdot.org'
            
-
            [23:23] <jrand0m> lol 
            
-
            [23:24] <Ophite1> so essentially you're trusting a limited subset of people, not to be horrible assholes.
            
-
            [23:24] * jrand0m reserves the right to be an asshole at times
            
-
            [23:24] <Ophite1> and to hand out domains to the rest.
            
-
            [23:24] <Ophite1> at least one of which ought, really, to be a trent-style first-comes-first-served bot.
            
-
            [23:24] <Ophite1> (with.. yes... hashcash.)
            
-
            [23:24] <tonious> Yeah.  And there may be namespace collisions by people who are outside my WoT...
            
-
            [23:25] <jrand0m> yup, and another should be something like thetower's tfee/subpage redirects 
            
-
            [23:25] <Ophite1> tonious: something that you can actually USE might be appreciated. it's just a naming system. :)
            
-
            [23:25] <tonious> Heh.
            
-
            [23:25] <Ophite1> the good thing about multiple cas is that they can do their own thing re: that kind of thing - different policies.
            
-
            [23:26] *** Signoff: nickthief60934 (Ping timeout)
            
-
            [23:26] <jrand0m> ok, other apps... 
            
-
            [23:26] <jrand0m> IM? 
            
-
            [23:26] <Ophite1> finally :)
            
-
            [23:26] <Ophite1> signed nyms! :)
            
-
            [23:26] <tonious> Sorry Ophite1 :)
            
-
            [23:26] <jrand0m> !thwap Ophite1 
            
-
            [23:27] <Ophite1> what, what are you all looking at? :)
            
-
            [23:27] <Ophite1> yes, WoT would be appropriate for _that_ :)
            
-
            [23:27] <dm> I think I remember who was doing IM... thecrypto?
            
-
            [23:27] <Ophite1> in fact... elgamal 2048-bit... dsa 1024-bit... sha-256... sounds kind of familiar. openpgp?
            
-
            [23:27] <jrand0m> yodel was in here the other day, mentioned that they had tried out running yodel's xml-rpc interface over with their own  local router, and it worked.  so, yay 
            
-
            [23:27] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [23:28] <tonious> I've managed to get SOAP going on mine, too.
            
-
            [23:28] <jrand0m> yup dm 
            
-
            [23:28] <tonious> No useful apps, beyond 'Yep, it works' so far.
            
-
            [23:28] <jrand0m> hehe 
            
-
            [23:29] *** Signoff: nickthief60934 (Excess Flood)
            
-
            [23:29] <Nostradumbass> tonious: so SOAP over i2p = Black SOAP?
            
-
            [23:29] * jrand0m really wants to get idn up and running so we can use i2p as an IP layer, not a TCP layer
            
-
            [23:29] <jrand0m> lol Nostradumbass 
            
-
            [23:29] <Ophite1> nicename :)
            
-
            [23:29] <tonious> Nostradumbass: Yep, you got it.
            
-
            [23:30] <tonious> Now I can set up my own I2P casino. w00t!
            
-
            [23:30] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [23:30] <jrand0m> w33wt 
            
-
            [23:30] <jrand0m> ok, I think thats 'bout it for the apps 
            
-
            [23:30] <jrand0m> 5) ...? 
            
-
            [23:31] <jrand0m> hi 
            
-
            [23:31] <Ophite1> tonious: cool. we could use a few of those. donate a percentage to the i2p project? :)
            
-
            [23:31] <TC> merchandising
            
-
            [23:31] <tonious> Has anybody thought of a C implementation of I2P?
            
-
            [23:31] <jrand0m> yeah, rent out colo boxes and run routers :) 
            
-
            [23:32] <jrand0m> tonious> lets wait until we get the router protocol implemented and thoroughly reviewed before porting ;) 
            
-
            [23:32] <tonious> Or anonymous colo: Behind an I2P router and no internet routing :)
            
-
            [23:32] <Ophite1> merchandising = logo.
            
-
            [23:32] <TC> stickers, t-shirts, hats, we need the logo
            
-
            [23:32] <Ophite1> tonious: after it's working and anonymous and stuff? of course.
            
-
            [23:32] <tonious> Yeah, but I'm still running my P2 and I'm a poor guy.
            
-
            [23:32] <tonious> :(
            
-
            [23:32] <Ophite1> i2p needs a good logo.
            
-
            [23:32] <Nostradumbass> yes
            
-
            [23:32] <Ophite1> I mean, the internet doesn't have a logo, but that's just bad marketing. :)
            
-
            [23:32] <dm> I like the one on the WIKI.
            
-
            [23:32] <TC> also, each made-for-i2p program needs its own tweeked version, or take off of the logo
            
-
            [23:32] <jrand0m> how about a transparent logo... it'd, be, like, everywhere, dood 
            
-
            [23:33] <Ophite1> an invisible logo. heh.
            
-
            [23:33] <tonious> A 1 pixel by 1 pixel blank gif?
            
-
            [23:33] <jrand0m> definnitely 
            
-
            [23:33] <Ophite1> tonious: we'd be sued for copyright infringment? :)
            
-
            [23:33] <tonious> Ha!
            
-
            [23:33] <Ophite1> ("Hey, that's OUR blank gif!")
            
-
            [23:33] <jrand0m> lol 
            
-
            [23:33] <Ophite1> Hey, if John Cage can do it...
            
-
            [23:33] <tonious> So we leave our names in the comments field :)
            
-
            [23:33] <Nostradumbass> Ophite1: how about a stream roller paving over the Internet?
            
-
            [23:33] <jrand0m> heh we're just rendering his audio 
            
-
            [23:34] <Ophite1> that one on the bottom looks the best imho.
            
-
            [23:34] <tonious> I like the one on the top.  It's simple.  Like me.
            
-
            [23:34] <Ophite1> with the arc design.
            
-
            [23:35] <Ophite1> something that is small, very simple, and above all would work well as an icon, or in the system tray :)
            
-
            [23:35] <Ophite1> and yes, which can be customised and used as a basis for logos of apps.
            
-
            [23:35] <jrand0m> right 
            
-
            [23:35] <dm> How about a black circle with white fill.
            
-
            [23:35] <Ophite1> that arc would be a good start (colour changes?)
            
-
            [23:35] <dm> or a triangle, maybe a square!
            
-
            [23:35] <dm> a parallelogram!
            
-
            [23:37] <tonious> Heh.  Open up a cafepress store...
            
-
            [23:37] <Ophite1> god no, not cafepress.
            
-
            [23:37] <dm> a white cloud!
            
-
            [23:37] <Ophite1> we demand class.   ... thinkgeek. ;-)
            
-
            [23:37] <dm> little fluffy cloud.
            
-
            [23:38] <TC> it would look toomuch like a cumpuddle in minature
            
-
            [23:38] * jrand0m associates clouds with the sky, thankyouverymuch
            
-
            [23:38] <tonious> Ophite1: First we've gotta convince 'em that we're whitehat.
            
-
            [23:39] <TC> no, lets be black hat
            
-
            [23:39] <jrand0m> tonious> can militant anarchists be whitehats too? 
            
-
            [23:39] * TC doesnt like ppl in hats
            
-
            [23:39] <tonious> Dunno.
            
-
            [23:39] * tonious wears a grey fedora FWIW.
            
-
            [23:39] <Nostradumbass> how about a white and a black hat?
            
-
            [23:39] <TC> and modulus would say somthing about class distinction or something
            
-
            [23:40] <dm> a small picture of uncle sam's face?
            
-
            [23:40] <TC> checkered hat?
            
-
            [23:40] <jrand0m> heh tc 
            
-
            [23:40] <Nostradumbass> or white and a black wizzard hats
            
-
            [23:40] <Ophite1> I am NOT a white hat. How dare you insinuate that. I want an apology.
            
-
            [23:41] <TC> or a black dunce hat
            
-
            [23:41] <jrand0m> well, anyway... 
            
-
            [23:42] <tonious> "i2p inside"?
            
-
            [23:42] <jrand0m> heh 
            
-
            [23:42] <dm> I, too, pee...
            
-
            [23:42] <jrand0m> dm> on a calvin sticker! 
            
-
            [23:42] <Ophite1> "i2p ... somewhere"
            
-
            [23:42] <TC> so, logo ppl, come on!  so can nop set us up a i2p cafepress site?
            
-
            [23:43] * jrand0m repeats the mantra No PR until its ready.
            
-
            [23:43] <Nostradumbass> dm: yeah, make it a "Concentration" style chrade logo-gram.
            
-
            [23:43] <Nostradumbass> <eye> 2 and a pee-ing penis.
            
-
            [23:44] <dm> Let's set a date.
            
-
            [23:44] <jrand0m> heh, yeah, and you'll have your mother click on that icon? 
            
-
            [23:44] <dm> March 1st.
            
-
            [23:44] <Nostradumbass> grab it, in fact :)
            
-
            [23:44] <tonious> My mother disapproves of encryption :)
            
-
            [23:44] *** UserX (~User@anon.iip) has joined channel #iip-dev
            
-
            [23:44] <dm> Slashdot article! No matter how far (or not) jrand0m has gotten!
            
-
            [23:44] <dm> Let's pile on the pressure.
            
-
            [23:44] <Ophite1> nooooooo.
            
-
            [23:44] <Ophite1> not yet!
            
-
            [23:45] <jrand0m> damn dm, if you pulled that date out of thin air, you're good.  in my palm I have 1.0 slotted as ~ march 1 
            
-
            [23:45] * dm slaps Ophite1
            
-
            [23:45] <dm> i said march 1st.
            
-
            [23:45] <Ophite1> the appropriate time to promote is when we have a cool shiny thing to wave at them.
            
-
            [23:45] <Nostradumbass> please, no slashdot till the network is ready for the onslaught.
            
-
            [23:45] <jrand0m> right 
            
-
            [23:45] <dm> I'm good, what can I say.
            
-
            [23:45] <Ophite1> I call launch date April 4th.
            
-
            [23:45] <Ophite1> 04/04/04 ;)
            
-
            [23:45] <jrand0m> no PR until AFTER 1.0 comes out. 
            
-
            [23:45] <Nostradumbass> Mojo was almost destroyed by /.
            
-
            [23:46] <dm> no, none of this rational thinking. March 1st, end of story.
            
-
            [23:46] <jrand0m> ooOOo Ophite1 
            
-
            [23:46] * jrand0m senses that I'm going to have to submit to /. to get them to NOT post dm^H^Han anonymous person's article
            
-
            [23:46] <Ophite1> no, don't do that. malda doesn't give a shit, and he'll post THAT :)
            
-
            [23:46] <jrand0m> heh 
            
-
            [23:47] <dm> Yes, you will be ridiculed by my post: "Em, like, there's this like anonymous cool program that's better than kazaa, I2P it's awesome, it's fast, DSA124. yeah"
            
-
            [23:47] <jrand0m> anyway, as things progress, http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap will be updated 
            
-
            [23:48] <dm> time to pack.
            
-
            [23:49] <jrand0m> (and some day I'm going to take a week off and go snowboarding) 
            
-
            [23:49] *** soros (~soros@anon.iip) has joined channel #iip-dev
            
-
            [23:49] <jrand0m> yeah, we're about the 2hour mark. 
            
-
            [23:49] <jrand0m> time to... 
            
-
            [23:49] * jrand0m *baf*'s the meeting closed.
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting68.html b/www.i2p2/pages/meeting68.html
deleted file mode 100644
index 1fb3e12f..00000000
--- a/www.i2p2/pages/meeting68.html
+++ /dev/null
@@ -1,281 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 68{% endblock %}
-{% block content %}
            Tuesday, December 9, 2003 22:00:00 CET
            
-
            
-
            [22:02] <jrand0m> 0) welcome to $num 
            
-
            [22:02] <jrand0m> 1) iip status 
            
-
            [22:02] <jrand0m> 2) kademlia stuff + idn 
            
-
            [22:02] <jrand0m> 3) peer profiling stuff 
            
-
            [22:02] <jrand0m> 4) i2p services  
            
-
            [22:02] <jrand0m> 5) stuff 
            
-
            [22:02] <jrand0m> 0) welcome  
            
-
            [22:02] <jrand0m> hi 
            
-
            [22:03] <jrand0m> this is meeting 67 or 68...  
            
-
            [22:03] <jrand0m> 1) iip status 
            
-
            [22:03] <jrand0m> I dunno.  anyone know what the situation has been as of late? 
            
-
            [22:04] <jrand0m> the iip devs aren't here, so... dunno. 
            
-
            [22:04] <jrand0m> [ping] 
            
-
            [22:04] <jrand0m> (last week I typed for probably 10 minutes before my client pinged me out...) 
            
-
            [22:05] <jrand0m> (i'm not going to type anything else until I get a p0ng, damnit ;) 
            
-
            [22:05] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev
            
-
            [22:05] <jrand0m> 'lo Nostradumbass 
            
-
            [22:06] <Nostradumbass> hi :)
            
-
            [22:06] <jrand0m> ok cool, so I haven't pinged out, people are just lurking.  cool :) 
            
-
            [22:06] * jrand0m hops on to the next agenda item
            
-
            [22:06] <Nostradumbass> how's i2p coming?
            
-
            [22:06] <Nostradumbass> sorry?
            
-
            [22:06] <jrand0m> good lead in ;) 
            
-
            [22:07] <jrand0m> agenda item 3) i2p 0.2.3 status :) 
            
-
            [22:07] *** nerox (~nerox@anon.iip) has joined channel #iip-dev
            
-
            [22:07] <jrand0m> there's been a lot of progress, even though I'm offline.  commited a truckload of code a few hours ago 
            
-
            [22:07] <jrand0m> that includes an implementation of the kademlia netDb 
            
-
            [22:08] <jrand0m> so I'm pretty confident we'll hit the release for 0.2.3 next week (which is basically kademlia netDb + a shell script) 
            
-
            [22:08] <jrand0m> there have been a few more variations on the kademlia proto though to make things more relevent for i2p 
            
-
            [22:09] <jrand0m> we will always have a very, very, /very/ sparse kademlia tree. 
            
-
            [22:09] <jrand0m> 2^256 possible slots, and 1-10 values per peer in the network. 
            
-
            [22:09] <jrand0m> so, thinking insanely overzealous, we still wont be using jack shit, and everything will be in the furthest out kbucket 
            
-
            [22:10] <jrand0m> so some parts of kademlia are going to be quietly ignored ;)  but the basic gist stays the same, including the search algo & distance metric 
            
-
            [22:10] <jrand0m> idn, however, is dead in the water. 
            
-
            [22:11] <jrand0m> the idea that i2p's netDb code could run off the same code as a publishing DHT was a silly little idea 
            
-
            [22:11] <jrand0m> and has been promptly abandonded. 
            
-
            [22:11] <jrand0m> idn is still generally a good idea, but I'm not going to spend my i2p dev time working on it 
            
-
            [22:12] *** tusko (~tusko@anon.iip) has joined channel #iip-dev
            
-
            [22:12] <jrand0m> but part of the 0.2.3 changes include a dramatic revamp of how we choose peers and organize router stats 
            
-
            [22:12] <jrand0m> heya tusko 
            
-
            [22:12] <jrand0m> that brings us to agenda item 3) peer profiling 
            
-
            [22:12] <jrand0m> I've been pretty silly...and finally did some of the math 
            
-
            [22:13] <jrand0m> the stats being gathered now are immense. 
            
-
            [22:13] <jrand0m> about 6000 data points /per peer/ 
            
-
            [22:13] <duck> what is peer profiling?
            
-
            [22:13] <jrand0m> peer profiling is where the router keeps track of the performance of each peer so that it can decide who to use in the future 
            
-
            [22:13] <duck> ah
            
-
            [22:13] <jrand0m> (aka fast routers, reliable routers, etc) 
            
-
            [22:13] <duck> the process that eats up my memory :)
            
-
            [22:14] <jrand0m> heh actually that part isn't toooo bad 
            
-
            [22:14] <jrand0m> though 6000 data points won't scale. 
            
-
            [22:14] <jrand0m> 1000 routers @ 6000 data points each @ 4 bytes / data point = 24Mb 
            
-
            [22:15] <jrand0m> though keeping detailed stats on a few hundred peers is probably fine, even as the net grows beyond that 
            
-
            [22:15] <jrand0m> we /don't/ need to keep stats on everyone.  just routers we want to 'use' for our tunnels, garlic routing, and source routing. 
            
-
            [22:16] <jrand0m> we could probably get away in the long term with just keeping track of a hundred or so peers. 
            
-
            [22:16] <jrand0m> but, for now, I'm going to say fuckit. 
            
-
            [22:16] <jrand0m> keep stats on all peers 
            
-
            [22:16] <duck> ping
            
-
            [22:16] <jrand0m> p0ng 
            
-
            [22:17] <duck> will it try to learn about all peers?
            
-
            [22:17] <jrand0m> right now, yes 
            
-
            [22:17] <duck> oh wait, your last lines covered that
            
-
            [22:17] <jrand0m> we also have some code for coallescing and running calculations on the peer profiles 
            
-
            [22:18] <jrand0m> so one of those calculators will determine what peers to drop 
            
-
            [22:18] <jrand0m> an example of the data set being collected: (Link: http://i2p.dnsalias.net/~jrandom/profile.txt)http://i2p.dnsalias.net/~jrandom/profile.txt 
            
-
            [22:19] <jrand0m> (you'll notice lots of 0s :) 
            
-
            [22:19] <jrand0m> I've written up a rough manifesto for peer selection and profiling, but need to get that onto the wiki 
            
-
            [22:20] <jrand0m> but thats all 0.3 stuff, really.  0.2.3 just uses a little of it 
            
-
            [22:21] <jrand0m> ok, thats it for the peer profiling.  lots more later, just giving a lil view into whats up 
            
-
            [22:21] <jrand0m> (of course, as always, anyone who wants to get down and dirty and figure out what other stats / calculations / attacks / etc should be used would be *very* much appreciated) 
            
-
            [22:22] <jrand0m> ok, 4) i2p services 
            
-
            [22:23] <jrand0m> tc's site is awesome & really reliable!  I finally got to nightblade's page as well, and its a cool blog ('plog' ;).. I just wish I could leave comments :) 
            
-
            [22:23] <jrand0m> there's also duck's jabber server, which works fairly easily with the instructions posted to tc's board 
            
-
            [22:24] <jrand0m> things sometimes act up a bit, but thats related to some bugs in the router <= 0.2.2, and have been fixed (and will roll out in 0.2.3) 
            
-
            [22:24] <jrand0m> the squid proxy is generally offline, since I'm offline too much to babysit my kaffe routers :/ 
            
-
            [22:25] <jrand0m> so for the moment, the eepsites and the jabber chat is probably the most reliable things on i2p, all running on top of i2ptunnel 
            
-
            [22:25] <jrand0m> what services would be cool to show up next? 
            
-
            [22:25] <duck> I did try to run an ircd over i2ptunnel
            
-
            [22:25] <duck> but before it got the full MOTD after logging in, I got ping timeouted already
            
-
            [22:26] <jrand0m> d'oh 
            
-
            [22:26] <duck> and that was on the same router
            
-
            [22:26] <duck> so in the wild performance will be even worse
            
-
            [22:26] <jrand0m> on the local router it pinged out?! 
            
-
            [22:26] <jrand0m> local router should never ping anything out 
            
-
            [22:26] <jrand0m> oh, except for that race bug 
            
-
            [22:26] <jrand0m> (which is probably what it was, since it was local and the race is faster there) 
            
-
            [22:26] <duck> irc client pinged out for not responding in time
            
-
            [22:27] <duck> I'll retry with 0.2.3
            
-
            [22:27] <jrand0m> word 
            
-
            [22:27] <duck> though jabber is nice for now
            
-
            [22:27] <jrand0m> totally 
            
-
            [22:27] <jrand0m> and long term, irc is not the way to go 
            
-
            [22:27] <duck> tc, jrandom and me are there to chat with!
            
-
            [22:27] <jrand0m> hehe :) 
            
-
            [22:28] <jrand0m> we need an IM and group chat solution that doesn't give cleartext to anyone unauthorized, and doesn't require centralized choke points 
            
-
            [22:28] <jrand0m> (aka iip 2.0) 
            
-
            [22:28] <jrand0m> now would be a nice time for userx to come back into the fold ;) 
            
-
            [22:29] * jrand0m stops holding breath
            
-
            [22:29] <jrand0m> an nntp server would /also/ really really rule. 
            
-
            [22:29] <duck> I'll try that tomorrow
            
-
            [22:29] <jrand0m> r0x0r 
            
-
            [22:30] <duck> jabber is really nice to run other things over
            
-
            [22:30] <duck> check out the jabber rpc specs
            
-
            [22:30] <duck> (Link: http://www.pipetree.com/jabber/jrpc/)http://www.pipetree.com/jabber/jrpc/
            
-
            [22:30] <duck> other services?
            
-
            [22:30] <jrand0m> thats interesting - doing jabber as a naming service, essentially 
            
-
            [22:31] <duck> you mean:
            
-
            [22:31] <jrand0m> there will always be more services to add - with mail (usenet), chat (jabber) and publishing/browsing (eepsites), there's good coverage 
            
-
            [22:31] <duck> name server has a jabber client through which you can register names (provided token)
            
-
            [22:31] <duck> also use it to query?
            
-
            [22:31] <jrand0m> naw 
            
-
            [22:32] <jrand0m> jabber's registry being the naming service 
            
-
            [22:32] <duck> ok
            
-
            [22:32] <jrand0m> its centralized but it works 
            
-
            [22:32] <jrand0m> just like hosts.txt :) 
            
-
            [22:33] <duck> are there mail solutions that are better suited for there environments than smtp and pop/imap ?
            
-
            [22:33] <jrand0m> thats a really good question 
            
-
            [22:33] <duck> cause I dont think that it will just work when you hook up mail servers
            
-
            [22:34] <jrand0m> yeah, it'd probably need either a gateway (ala freemail) or the naming service doing some interesting tap dancing 
            
-
            [22:34] <jrand0m> or it reverts back to centralized single POP3/IMAP server with everyone on the same server 
            
-
            [22:35] <duck> I spoke with aum (author of freemail) yesterday
            
-
            [22:35] <duck> he was talking about reimplementing fred in python
            
-
            [22:35] <jrand0m> lol nice 
            
-
            [22:35] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev
            
-
            [22:35] <duck> so I did suggest him to work on the python routers for i2p instead
            
-
            [22:35] <jrand0m> ooh that would TOTALLY rule! 
            
-
            [22:35] <duck> then he got totally upset about the pdf documents
            
-
            [22:36] <jrand0m> hey, if he wants the openOffice originals, or even a txt export I'll export 
            
-
            [22:36] <duck> and I lost my patience and told him that you would also have the m$word docs if he did ask nicely
            
-
            [22:36] <duck> well, you were a fuckhead for not doing a html export or something
            
-
            [22:36] <jrand0m> naw, I tried that ;) 
            
-
            [22:36] <duck> I lost my patience and told him to talk to you
            
-
            [22:36] <jrand0m> the openOffice html export SUCKS 
            
-
            [22:37] <duck> hm
            
-
            [22:37] <mrflibble> true jr
            
-
            [22:37] <jrand0m> when the specs turn 1.0 (aka when the router turns 1.0 and they're updated to match the code), they'll be on the wiki. 
            
-
            [22:37] <duck> wiki has most info though
            
-
            [22:37] <jrand0m> exactly 
            
-
            [22:37] <mrflibble> i tried using that for that kevin mitnick book. it was worse than ms office
            
-
            [22:37] <duck> oh well
            
-
            [22:37] <jrand0m> zactly. 
            
-
            [22:37] <duck> he might appear here once
            
-
            [22:37] <jrand0m> that'd be awesome 
            
-
            [22:38] <duck> but maybe it is better with his attitude to join the freenet gang
            
-
            [22:38] <duck> ...
            
-
            [22:38] <jrand0m> well, effort on freenet is always a good thing 
            
-
            [22:38] * duck goes back to beeing friendly
            
-
            [22:38] <jrand0m> :) 
            
-
            [22:38] <duck> aums work rocks
            
-
            [22:38] <duck> hopefully he'll rock on i2p
            
-
            [22:39] <jrand0m> yeah whenever someone talked about searching on freenet, I always just said "well just do a McNabb" 
            
-
            [22:39] <jrand0m> we need the help, certainly 
            
-
            [22:39] <duck> which brings me to the following question:
            
-
            [22:39] <duck> are the changes to I2P that you do specced?
            
-
            [22:39] <duck> or is the java source the documentation for the latest info
            
-
            [22:40] <jrand0m> there are notes taken in my palmpilot, filesystem, and notebook, but unfortunately I haven't updated the openoffice docs in a while 
            
-
            [22:40] <jrand0m> feb is doc-month for jrandom. 
            
-
            [22:40] <jrand0m> (and qa, and bugfixing) 
            
-
            [22:41] <jrand0m> ((and benders ;)) 
            
-
            [22:41] <jrand0m> the specs are still pretty much correct, there are just more details. 
            
-
            [22:41] <duck> awesome
            
-
            [22:41] <jrand0m> but the datastructures have had more changes 
            
-
            [22:42] <jrand0m> ok, anything else for services?   
            
-
            [22:43] <jrand0m> ok, 5) stuff 
            
-
            [22:43] <jrand0m> hi 
            
-
            [22:43] <duck> hi!
            
-
            [22:43] <jrand0m> how's tricks? 
            
-
            [22:43] <jrand0m> [any questions / thoughts / issues / etc go here] 
            
-
            [22:43] <duck> the base64 tricks should be added to the i2ptricks pages
            
-
            [22:44] <jrand0m> ooh good point 
            
-
            [22:44] <duck> might be some other tricks too that I dont know yet
            
-
            [22:44] <duck> will grep the sources for 'main'
            
-
            [22:44] <jrand0m> I feel guilty for not having the installer let someoene automatically fetch hosts.txt and reseed 
            
-
            [22:44] <jrand0m> lol 
            
-
            [22:44] <jrand0m> there are lots and lots of main() methods, but they're mostly test functions 
            
-
            [22:45] <jrand0m> oh! 
            
-
            [22:45] <jrand0m> one thing.  DONT run the current code from cvs and expect it to work with normal routers. 
            
-
            [22:45] *** joda (--@anon.iip) has joined channel #iip-dev
            
-
            [22:45] <joda> hi
            
-
            [22:45] <jrand0m> the db messages changed :) 
            
-
            [22:45] <jrand0m> hi joda 
            
-
            [22:45] <joda> sorry, if I interrupt something
            
-
            [22:45] <duck> I got a bit upset that I couldnt get cvs to work
            
-
            [22:45] <duck> but then I did remember that this isnt freenet
            
-
            [22:45] <joda> I was just wondering what happend to "anonymail" ?
            
-
            [22:46] <duck> so you dont need latest cvs to be able to use it
            
-
            [22:46] <jrand0m> joda> the user who runs it doesn't seem to be online at the moment.  should be back soon 
            
-
            [22:46] <jrand0m> hehe duck - did it fail for you today after I committed, or do you mean from before today? 
            
-
            [22:46] <duck> last week somewhere
            
-
            [22:46] <joda> jrand> thx :)
            
-
            [22:46] <joda> cu :)
            
-
            [22:46] <jrand0m> ah 'k duck 
            
-
            [22:46] <jrand0m> l8r joda 
            
-
            [22:47] <jrand0m> yeah, I only endorse running the released code 
            
-
            [22:47] <duck> will 0.2.3 put the version files in a directory? :)
            
-
            [22:47] <jrand0m> 0.2.3 gets rid of the version files :) 
            
-
            [22:47] <jrand0m> (lots and lots and lots of changes) 
            
-
            [22:47] <jrand0m> but that means 0.2.3 (and beyond) will require g enerally correct clocks 
            
-
            [22:48] <jrand0m> (current Router.CLOCK_FUDGE_FACTOR = 30 minutes) 
            
-
            [22:48] <duck> what will the fudge facter be for 0.2.3?
            
-
            [22:48] <jrand0m> probably the same 
            
-
            [22:49] *** joda has left #iip-dev
            
-
            [22:49] <duck> oh, current = your code
            
-
            [22:49] <jrand0m> that time will be used to expire db entries 
            
-
            [22:49] <duck> k
            
-
            [22:49] <jrand0m> ah, right, yeah :) 
            
-
            [22:49] <jrand0m> (in 0.2.2 that clock_fudge_factor is spread out throughout half a dozen files) 
            
-
            [22:49] <duck> maybe the installer could be a bit more userfriendly
            
-
            [22:49] <duck> as in less questions
            
-
            [22:49] *** Signoff: nickthief66282 (Excess Flood)
            
-
            [22:50] <duck> default phttp urls included, no bandwidth limiting etc
            
-
            [22:50] <jrand0m> I guess we could autoguess random ports too 
            
-
            [22:50] <jrand0m> you're right 
            
-
            [22:50] <jrand0m> want commit privs?  :) 
            
-
            [22:50] *** Signoff: nerox (EOF From client)
            
-
            [22:50] <jrand0m> (if not I can update it for 0.2.3) 
            
-
            [22:51] <duck> an argument against it can be that users will take settings too easily for granted
            
-
            [22:51] <duck> and everybody uses the same phttp relay
            
-
            [22:51] *** nickthief24373 (~chatzilla@anon.iip) has joined channel #iip-dev
            
-
            [22:51] <jrand0m> true.  though 0.3.1 plans include an update to the phttp relay code to let relays talk to each other, and redirect users to a less loaded relay 
            
-
            [22:52] <jrand0m> i'm generally happy with the install process atm though - i built a new 0.2.2 install and was browsing tc's page in under a minute 
            
-
            [22:52] <jrand0m> (though thats because i know what all the text says and didn't read it...) 
            
-
            [22:52] <duck> I dont like the long keys
            
-
            [22:53] <duck> especially not if you have to copy&paste them
            
-
            [22:53] <duck> better use them as file
            
-
            [22:53] <jrand0m> hmm? 
            
-
            [22:53] <duck> but distributing the binary files are a pain
            
-
            [22:53] <duck> so you have to do the base64 trick..
            
-
            [22:53] <duck> could the i2ptunnel read base64 destination keys too?
            
-
            [22:53] <duck> from a file that is
            
-
            [22:53] <jrand0m> I was just typing that ;) 
            
-
            [22:53] <jrand0m> yeah, that wouldnt be much work 
            
-
            [22:54] <jrand0m> perhaps even 1 line 
            
-
            [22:54] <duck> also, what about armouring?
            
-
            [22:54] <duck> with a header&footer
            
-
            [22:54] <duck> like pgp etc
            
-
            [22:55] <jrand0m> true, it would be useful to have that sort of validation 
            
-
            [22:55] <duck> ofcourse that is a gadget
            
-
            [22:55] <duck> but it could be helpful for those who want to use the tunnel
            
-
            [22:55] <jrand0m> though the Destination structure itself is pretty picky 
            
-
            [22:55] <jrand0m> but you're right, a raw base64 isn't the most intuitive or safe thing to pass around 
            
-
            [22:56] <jrand0m> we need a bugzilla 
            
-
            [22:56] <jrand0m> so things like this can get posted as todo 
            
-
            [22:56] <jrand0m> i'd move off my palm's todo list for that 
            
-
            [22:56] <duck> bugzilla has nazi registration requirements
            
-
            [22:56] <duck> with emails etc..
            
-
            [22:56] <jrand0m> true 
            
-
            [22:57] <duck> but better as nothing
            
-
            [22:57] <duck> other bugtrackers all have their shortcomings
            
-
            [22:57] <jrand0m> yeah, every company i've worked at has pretty much ended building their own 
            
-
            [22:58] <jrand0m> we'll see.  we need a bugtracker by the time we start doing full on qa (once 0.3 comes out) 
            
-
            [22:58] <jrand0m> so we've got a few weeks ;) 
            
-
            [22:58] <jrand0m> but if someone did some research and found a really nice one, that'd be great 
            
-
            [22:59] <jrand0m> [not you specifically duck, anyone who's reading these meeting logs at home ;)] 
            
-
            [22:59] <duck> so far phpBugTrackers has been okay for me
            
-
            [22:59] <jrand0m> hmm haven't used that 
            
-
            [22:59] <duck> yes, I am not talking to jrandom either
            
-
            [22:59] <jrand0m> lol 
            
-
            [22:59] <duck> but to the group of I2P code developers :)
            
-
            [22:59] * jrand0m is actually 12 people acting under a single nym
            
-
            [23:00] <jrand0m> ok, 1 hour, on the dot 
            
-
            [23:00] <jrand0m> anyone else have anything before I get the *baf*er out? 
            
-
            [23:01] * duck demands 1 more minute
            
-
            [23:01] <duck> since we did start on 21:02
            
-
            [23:01] <jrand0m> yeah yeah 
            
-
            [23:01] <jrand0m> la la la 
            
-
            [23:01] <jrand0m> what should i have for dinner? 
            
-
            [23:01] <jrand0m> there's a nice falafel place next door... 
            
-
            [23:01] <jrand0m> had gnocci for lunch too 
            
-
            [23:01] <jrand0m> hmm... 
            
-
            [23:01] <jrand0m> maybe a liquid dinner 
            
-
            [23:02] <duck> soup?
            
-
            [23:02] <jrand0m> ooOooo whiskey soup! 
            
-
            [23:02] * jrand0m *baf*'s the meeting closed on that note
            
-
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting69.html b/www.i2p2/pages/meeting69.html
deleted file mode 100644
index 144ce11a..00000000
--- a/www.i2p2/pages/meeting69.html
+++ /dev/null
@@ -1,250 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 69{% endblock %}
-{% block content %}
            Tuesday, December 16, 2003 22:00:00 CET
            
-
            
-
            [22:04] <jrand0m> 0) hi 
            
-
            [22:04] <jrand0m> 1) iip 
            
-
            [22:04] <jrand0m> 2) 0.2.3 & 0.2.3.1 
            
-
            [22:04] <jrand0m> 3) hi 
            
-
            [22:04] <jrand0m> 0) hi 
            
-
            [22:04] <jrand0m> welcome to the ... something'th meeting 
            
-
            [22:05] <jrand0m> (68?  69?) 
            
-
            [22:05] <MrEcho> damm its 1pm here
            
-
            [22:05] <jrand0m> GMT-8? 
            
-
            [22:05] <duck> 69
            
-
            [22:05] <jrand0m> h0t. 
            
-
            [22:06] <jrand0m> ok, 1) iip 
            
-
            [22:06] *** Signoff: tusko (EOF From client)
            
-
            [22:06] * MrEcho compiles a kernel for the meeting
            
-
            [22:06] <jrand0m> iip is acting crazy.  all i know is nop is "moving servers", whatever that means.  i don't know when it'll be done, etc. 
            
-
            [22:06] <jrand0m> anyone have any more info they want to share with the class? 
            
-
            [22:06] *** mids (mids@anon.iip) has joined channel #iip-dev
            
-
            [22:06] <MrEcho> no info from nop
            
-
            [22:07] <mids> this morning I was told that I could start Trent again
            
-
            [22:07] <mids> (I did do so already last night)
            
-
            [22:07] <jrand0m> wikked 
            
-
            [22:07] <jrand0m> gracias 
            
-
            [22:07] <mids> so that indicates that nop believes that IIP is more stable again
            
-
            [22:07] <mids> if that is worth anything...
            
-
            [22:07] <mids> *cough*
            
-
            [22:07] <jrand0m> ok cool 
            
-
            [22:08] <jrand0m> [woot roommate just handed me a glass of wine for the meeting] 
            
-
            [22:08] <MrEcho> lol
            
-
            [22:08] <jrand0m> ok, since nop is online and won't come to hte meeting, we'll have to save the lynch mob for later 
            
-
            [22:09] <jrand0m> 2) 0.2.3 & 0.2.3.1 
            
-
            [22:09] <mids> what specific question do you want to ask him?
            
-
            [22:09] <protocol> when is the meeting
            
-
            [22:09] <jrand0m> specific question> when will he make an official announcement describing the past problems and how the future ones will be addressed? 
            
-
            [22:09] <jrand0m> the meeting is now 
            
-
            [22:10] <jrand0m> (aka, at what point should we explore non-iip means of communication) 
            
-
            [22:10] <mids> if I get an answer I'll let you know.
            
-
            [22:10] <jrand0m> thanks 
            
-
            [22:11] <jrand0m> ok, i2p stuff.  0.2.3 came out yesterday, and while most of hte kademlia code is working fine, there are some 0.2.2 bugs showing up as well as some other bugs being explored. 
            
-
            [22:11] <jrand0m> i've committed a change to use tunneled messages for dbStore instead of garlics, which should reduce the load tc (et al) have been seeing on servers 
            
-
            [22:12] <jrand0m> there is also a new persistent sessionKeyManager that will make it so restarts won't totally b0rk a router for 15 minutes 
            
-
            [22:12] <MrEcho> what about client connect times to routers?
            
-
            [22:12] <duck> so far it feels as good/bad as 0.2.2; unless my router/tunnels go down again this night, in which case it is worse as 0.2.2
            
-
            [22:13] <jrand0m> MrEcho> that seems to be in the interaction of two bugs from 0.2.2 thats acting up more than before.  those two are my top priority. 
            
-
            [22:13] <MrEcho> ok cool
            
-
            [22:13] <jrand0m> duck> my feeling is that its worse than 0.2.2, from an end user perspective.  i'm working on fixing that without sacrificing anonymity or security. 
            
-
            [22:13] <MrEcho> its hard to work on the dns with that damm bug .. i have to restrt the dns server alot
            
-
            [22:14] <jrand0m> MrEcho> with local only routers i have not been able to reproduce the bugs - does it work for you w/ local only? 
            
-
            [22:15] <MrEcho> no
            
-
            [22:15] <jrand0m> could you send me debug logs for that? 
            
-
            [22:15] <MrEcho> already deleted
            
-
            [22:16] <jrand0m> ok, if you try again and it doesn't work, if you could send me debug logs from both the router and client I'd appreciate it. 
            
-
            [22:16] <MrEcho> its doing the samething as before .. client gets msg that its sent .. but never makes it to the client
            
-
            [22:16] <MrEcho> to the other client
            
-
            [22:17] <MrEcho> ya .. ill see what i can do
            
-
            [22:17] <jrand0m> ok, sounds like the i2psessionImpl2 bug.  i haven't been able to reproduce that locally, but once its fixed for remote hopefully it will work for your situation 
            
-
            [22:17] <jrand0m> gracias 
            
-
            [22:17] <jrand0m> in any case, thanks for y'all's patience with the update.  we're making progress, even if it doesn't feel like it on the surface 
            
-
            [22:18] <protocol> shine on you crazy diamond
            
-
            [22:18] <duck> in the future, say once i2p is actually used, how will the development / release process change to prevent broken releases from mess up the net?
            
-
            [22:19] <jrand0m> once 1.0 is out, i'll do dev & roll out to an insane group of volunteers to play with for a week, then if things wokr great, it'll get rolled out to general release. 
            
-
            [22:20] * FireRabbit will be an insane vollunteer
            
-
            [22:20] <jrand0m> right now i've got to battle with kaffe & jetty for updates on i2p.dnsalias.net 
            
-
            [22:20] <duck> what species?
            
-
            [22:20] * MrEcho already is
            
-
            [22:20] *** tusko (~tusko@anon.iip) has joined channel #iip-dev
            
-
            [22:20] <jrand0m> y'all already are insane (and very helpful) volunteers :) 
            
-
            [22:20] <FireRabbit> thank you!
            
-
            [22:20] <FireRabbit> :)
            
-
            [22:21] *** TC (~TC@anon.iip) has joined channel #iip-dev
            
-
            [22:21] <jrand0m> hey if it aint tc 
            
-
            [22:21] * MrEcho wips TC .. your late
            
-
            [22:21] <TC> hey
            
-
            [22:21] <TC> we back up and running?
            
-
            [22:21] <MrEcho> ya i can type todya...
            
-
            [22:22] <jrand0m> iip seems up... 
            
-
            [22:22] <TC> yay
            
-
            [22:22] <jrand0m> in any case, i'm hoping to have 0.2.3.1 out in the next few days, once the two critical bugs get fixed (the cpu overload tc has seen has already been updated) 
            
-
            [22:23] *** wiht (anon@anon.iip) has joined channel #iip-dev
            
-
            [22:23] <TC> what was the cause?
            
-
            [22:23] <FireRabbit> i seem to have noticed increased disk activtiy since updating to 0.2.3 but i havent spent any time to see if thats actually i2p or just the comp being stupid
            
-
            [22:23] *** Signoff: wiht ((null))
            
-
            [22:23] <TC> FireRabbit, how much memmory do you have?
            
-
            [22:24] <FireRabbit> that computer has 128 i believe
            
-
            [22:24] <FireRabbit> you think it could be the paging file?
            
-
            [22:24] <jrand0m> the cause was that 0.2.3 sends all dbStore messages via garlic routed messages instead of directly, which uses either ElGamal or AES+SessionTag (depending on whether tags are known).  the persistentSessionKeyMAnager will make tags last longer, and 0.2.3.1 will send dbStore messages through tunnels instead 
            
-
            [22:24] <TC> because i have 512 and i2p gave me an 'out of memmory' error last night
            
-
            [22:24] <jrand0m> really?  shite 
            
-
            [22:24] <FireRabbit> oh, intresting
            
-
            [22:25] <MrEcho> wow
            
-
            [22:25] <jrand0m> yeah, thats #3 on the list of bugs left to crack (though thats not a 0.2.3.1 showstopper) 
            
-
            [22:25] <jrand0m> OOMs don't use all 512 
            
-
            [22:25] <TC> but it seems to be running fine now
            
-
            [22:25] <jrand0m> they only use what java's given (e.g. 64M) 
            
-
            [22:26] <TC> yes
            
-
            [22:26] <duck> Memory: In use: 8187KB
            
-
            [22:26] <jrand0m> word 
            
-
            [22:26] <duck> that is not much!
            
-
            [22:26] <duck> yet
            
-
            [22:26] <MrEcho> Memory: In use: 8908KB Free: 4088KB 
            
-
            [22:27] <jrand0m> right, there is something growing in there, i hope to have it tracked down by 0.3  
            
-
            [22:27] <jrand0m> cool, free means it used to use 12.9M, now it only uses 8.9 
            
-
            [22:27] <TC> its running at 30megs of memory at the moment but last night it jumped up to (what windows told me) '70' about then is where it crashed
            
-
            [22:27] <jrand0m> yeah, kaffe does that for me tc 
            
-
            [22:28] <jrand0m> ok, in any case, people should subscribe to the i2p mailing list 
            
-
            [22:28] * FireRabbit is thinking when he gets home today hes going to rewrite the meshwork lib since it has some problems
            
-
            [22:28] <FireRabbit> sigh
            
-
            [22:28] <jrand0m> ((Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/) 
            
-
            [22:28] <jrand0m> d'oh FireRabbit 
            
-
            [22:28] <FireRabbit> this thing is never going to gte done
            
-
            [22:28] <TC> yah, and memory is no biggy for the most part
            
-
            [22:28] <jrand0m> heh, no project goes as easily as one hopes 
            
-
            [22:28] <FireRabbit> nope
            
-
            [22:28] <protocol> jrand0m: the maillist triggers Yahoo! spam protection
            
-
            [22:28] <protocol> just a heads up
            
-
            [22:28] <jrand0m> really protocol? 
            
-
            [22:29] <protocol> yeah
            
-
            [22:29] <jrand0m> perhaps thats what triggered the spam guard when i cc'ed iip-dev 
            
-
            [22:29] * jrand0m will write my isp
            
-
            [22:29] <jrand0m> (or perhaps its the .dnsalias.net thing) 
            
-
            [22:30] <protocol> i didn't get any mailings so far, and i emptied my bulk mail b4 i could check
            
-
            [22:30] <duck> or the jrandom nicknam
            
-
            [22:30] <jrand0m> lol duck 
            
-
            [22:30] <FireRabbit> :)
            
-
            [22:30] <jrand0m> that'd be awesome if my nick was filtered :) 
            
-
            [22:30] <FireRabbit> hehe
            
-
            [22:30] *** wiht (anon@anon.iip) has joined channel #iip-dev
            
-
            [22:30] <jrand0m> wb wiht 
            
-
            [22:30] <jrand0m> speaking of which, I suppose I should inject 3.1) apps :) 
            
-
            [22:31] <jrand0m> hey MrEcho, how goes the battle? 
            
-
            [22:31] <wiht> jrand0m: Hello.
            
-
            [22:31] <MrEcho> the day somone writes a autodetect program for the linux compile config
            
-
            [22:31] <MrEcho> well its on its way
            
-
            [22:31] <duck> knoppix uses some autodetect thing, isnt it?
            
-
            [22:31] <jrand0m> ./configure ; make ; make check ; make install ; reboot 
            
-
            [22:31] <duck> </offtopic>
            
-
            [22:31] <MrEcho> ive pritty much maped out how i want to do everything
            
-
            [22:31] <jrand0m> word 
            
-
            [22:32] <jrand0m> do you have a clear view on how i2ptunnel could be updated to make use of what you're doing MrEcho? 
            
-
            [22:32] <FireRabbit> i think knoppix uses hotplug
            
-
            [22:32] <MrEcho> 0.1 wont be/might be locked down .. dont know yet
            
-
            [22:32] <jrand0m> coo' 
            
-
            [22:33] <TC> oh jrand0m, i have a question about the cvs
            
-
            [22:33] <jrand0m> que tal? 
            
-
            [22:33] <MrEcho> for dns querys im going to have a server port on the Client and RS side for Names querys
            
-
            [22:33] <FireRabbit> ok jrand0m so enlighten me on this, if you have two arrays, one thats storing data just recieved and one thats acting as a buffer what would you name them
            
-
            [22:33] <MrEcho> and im going to build a lib for any app to use
            
-
            [22:33] <jrand0m> FireRabbit> src, dest 
            
-
            [22:34] <FireRabbit> humm
            
-
            [22:34] <TC> i thought it would be a good idea if i updated the host file directly to the i2p based cvs so it could be included with future versions
            
-
            [22:34] <jrand0m> definitely tc 
            
-
            [22:34] <FireRabbit> this is a pretty big class, i think id want to go a little more specific than that
            
-
            [22:34] * jrand0m should get you a cvs account
            
-
            [22:34] <TC> im just wondering how to connect to it
            
-
            [22:34] <duck> TC: you want (Link: http://www.tortoisecvs.org/)http://www.tortoisecvs.org/
            
-
            [22:34] <duck> easiest CVS client for windows that I know
            
-
            [22:35] * MrEcho uses the dos ver :)
            
-
            [22:35] <mihi> duck: for windows != win9x ;)
            
-
            [22:35] * FireRabbit uses the cvs command line port
            
-
            [22:35] <duck> mihi: I did test it with win9x
            
-
            [22:35] <jrand0m> tc> have you used cvs before?  or are you concerned w/ anonymity?  (you should be able to cvs through i2p at the moment) 
            
-
            [22:35] * mihi uses either WinCVS or the cygwin cvs
            
-
            [22:35] * jrand0m uses cvs.exe
            
-
            [22:35] <TC> ok, so i use that client and set up the proxy?
            
-
            [22:35] <TC> no, ive never used cvs before
            
-
            [22:35] <jrand0m> ok, i'll walk you through the setup after the meeting 
            
-
            [22:36] <TC> sure, thanks
            
-
            [22:36] <duck> about cvs-ing through the tunnel:
            
-
            [22:36] <duck> wouldnt the double messages be a big problem?
            
-
            [22:36] *** Signoff: wiht (Ping timeout)
            
-
            [22:37] <duck> especially for commits
            
-
            [22:37] <jrand0m> yes duck, but I haven't run into that problem (cvs messages are typically small) 
            
-
            [22:37] <jrand0m> >64k messages (e.g. the specs .pdf or .sxw) should for now be done through the normal internet 
            
-
            [22:38] <duck> jabber msges get also duplicated quite often
            
-
            [22:38] <jrand0m> you're right though, in that its not a rock solid solution for cvs yet 
            
-
            [22:38] <duck> even though they are XML, they are not that big
            
-
            [22:40] <jrand0m> right, lost acks are one of the bitches of the current lost i2psessionimpl2 bugs :/ 
            
-
            [22:40] <duck> k
            
-
            [22:41] <duck> (that was a partly lost ack)
            
-
            [22:41] <jrand0m> (with the network this size, there should be no resends ever, unless that the peer is offline) 
            
-
            [22:42] <jrand0m> hmm ok, any other i2p stuff? 
            
-
            [22:42] <mihi> jrand0m: how about adding some kinda sequence number into the i2p packets?
            
-
            [22:43] <jrand0m> i2ptunnel packets? 
            
-
            [22:43] <mihi> this would help with the doubling things.
            
-
            [22:43] <mihi> no, i2pnp packets
            
-
            [22:43] <mihi> okay, one could do it on i2ptunnel level as well.
            
-
            [22:43] <TC> so jrand0m did you get your conncetion back or are you still at a cafe?
            
-
            [22:43] <mihi> just if you get twice the same number, disregard the second one.
            
-
            [22:44] <jrand0m> those already handle dup ids for most things, though you're right in that there's going to be an update on 0.3 for the remaining messages 
            
-
            [22:44] <jrand0m> right, currently we keep a history of the last 1000 msgIds to drop dups 
            
-
            [22:44] <mihi> okay, if anyone volunteers to write a good tcp impl for i2p, that would be better ;)
            
-
            [22:44] <jrand0m> yes! :) 
            
-
            [22:44] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev
            
-
            [22:45] * jrand0m thinks there's going to be a bounty for some [yet to be determined killer app/feature] once 1.0 gets near
            
-
            [22:45] <duck> win a 1 hour private chat session with UserX!
            
-
            [22:45] <jrand0m> lol 
            
-
            [22:45] <MrEcho> lol
            
-
            [22:46] <jrand0m> ok, any other i2p things, or iip things, or anything else for this, the 69th iip-dev meeting? 
            
-
            [22:46] <jrand0m> (other than userx pinup girl comments) 
            
-
            [22:47] <duck> any other apps that duck inc. should run?
            
-
            [22:47] <jrand0m> bluebeep! 
            
-
            [22:47] <TC> 1. jrand0m did you fix your connection issues? 2. what do you think of my new eepsite?
            
-
            [22:47] <TC> bluebeep?
            
-
            [22:47] <jrand0m> oh sorry tc.  yes, i finally have net access :)  haven't seen your new eepsite beyond the board (which kicks ass), but i'll check later :) 
            
-
            [22:48] <duck> TC: I like the new design
            
-
            [22:48] <TC> hmm, i should change the board as well to cut down on the load time
            
-
            [22:48] <duck> only think you should try to disable the email function in the phpboard, now you get an error each time
            
-
            [22:48] <TC> thanks duck
            
-
            [22:48] <jrand0m> dropping images would be a plus 
            
-
            [22:49] <TC> good idea
            
-
            [22:49] <jrand0m> (bluebeep is an old wardialer) 
            
-
            [22:49] <MrEcho> ya
            
-
            [22:49] <jrand0m> (and all around fun toy) 
            
-
            [22:49] <duck> please keep in mind that the average age is 16 here
            
-
            [22:50] * MrEcho is 24
            
-
            [22:50] * duck ducks
            
-
            [22:50] * jrand0m doubts there are too many 3 year olds to balance out the geriatrics among us ;)
            
-
            [22:50] *** wiht (anon@anon.iip) has joined channel #iip-dev
            
-
            [22:50] <MrEcho> lol
            
-
            [22:50] * TC built a blackbox once
            
-
            [22:50] <jrand0m> w3wt 
            
-
            [22:50] <lonelynerd> is the meeting already over?
            
-
            [22:50] <duck> last Q:
            
-
            [22:50] *** protocol is now known as proto_afk
            
-
            [22:51] <duck> how can we read the kademlia stats?
            
-
            [22:51] * jrand0m hasn't !baf'ed yet lonelynerd, so ask away :)
            
-
            [22:51] * MrEcho kills pcmcia support in the kernel
            
-
            [22:51] <duck> just so that we understand what routerConsole.html dumps
            
-
            [22:51] <MrEcho> im getting pissed
            
-
            [22:51] <jrand0m> ok, the JobQueue stats I assume you mean? 
            
-
            [22:52] * duck guesses that it is all obvious probably
            
-
            [22:52] <jrand0m> basically when I look at JobQueue stats, I check to see that the avg execution time for the Build garlic message, buld tunnel, and handle * message jobs are small 
            
-
            [22:52] <jrand0m> (those are the jobs that usually take the longest, and when the pending side of things gets large, everything suffers) 
            
-
            [22:53] <lonelynerd> (actually, i better read the logs first)
            
-
            [22:53] <duck> gotcha
            
-
            [22:53] <jrand0m> the .1-.6s avg pending time i've been seeing is shit poor and one of the big things i'm going to aim for once its time to tune 'em 
            
-
            [22:54] <jrand0m> the netDb contents liveliness and reliability are largely random numbers, as long as they're > 100.  last sent successfully means when was the last time it was sent to 2 or more peers  
            
-
            [22:54] <jrand0m> (we resend randomly if it isn't local) 
            
-
            [22:54] <jrand0m> (no more than once every 5 minutes though) 
            
-
            [22:55] <jrand0m> is there a stat that would be helpful for people, or some other visualization that might help?  (if its nontrivial i might not throw it in, but if its easy, i probably would) 
            
-
            [22:56] <duck> thanks
            
-
            [22:57] <jrand0m> any other comments / questions / concerns / frisbees? 
            
-
            [22:59] <jrand0m> in that case 
            
-
            [22:59] * jrand0m winds up
            
-
            [22:59] * jrand0m *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting7.html b/www.i2p2/pages/meeting7.html
deleted file mode 100644
index 88007d70..00000000
--- a/www.i2p2/pages/meeting7.html
+++ /dev/null
@@ -1,458 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 7{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 7
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Wed Jul 03 00:33:19 2002
-
            00:33 <+logger> logging started
-
            00:47 -!- mode/#iip-dev [+o nop] by mids
-
            00:54 < UnDeRToW> hi
-
            00:54 <@mids> hi
-
            01:01 <@nop> ok
-
            01:01 <@nop> hi
-
            01:01 <@nop> welcome
-
            01:01 <@nop> to the 5th meeting I believe
-
            01:01 <@mids> 7th
-
            01:02 <@nop> really
-
            01:02 <@nop> ok
-
            01:02 <@mids> http://mids.student.utwente.nl/~mids/iip/
-
            01:02 <@nop> wilde you have anonymail
-
            01:02 <@nop> ok
-
            01:03 <@nop> iip 1.1 rc2 will be released pending a few doc changes and me submitting a couple of technical docs for merging with docs
-
            01:03 <@nop> umm, cs and I will work on transforming inform to work with latest version
-
            01:04 <@nop> and we have had a few people try out some security checks on IIP
-
            01:04 <@nop> unfortunately with no success
-
            01:04 <@nop> but
-
            01:04 <@nop> that's the spirit
-
            01:04 <@nop> ;)
-
            01:04 <@nop> anyway
-
            01:05 <@nop> this is not much of a meeting today, but if anyone has anything to add please feel free at the questions part
-
            01:05 <@nop> so... mids, do you have anything
-
            01:05 <@mids> yes
-
            01:05 <@mids> I would like to have a public discussion about the pro's and con's of bots in the public channels
-
            01:06 <@mids> with ArdVark and some others I have had an argument about that
-
            01:06 <@mids> everybody has its personal ideas
-
            01:06 <@mids> and they aren't all compatible
-
            01:06 <@mids> but since we are not here to censor everything
-
            01:06 <@mids> lets discuss
-
            01:06 <@mids> allow me to state the current issue
-
            01:07 <@mids> unless someone already wants to add something
-
            01:07 <@mids> 3 2 1 0
-
            01:07 <@mids> ok
-
            01:07 <@mids> in #anonymous (and #iip and #help) we have had a few infobots
-
            01:07 <@mids> Herod, camabot and now visix
-
            01:08 <@mids> personally I dont see any good in those things.. since they seem to be only 'abused' for channel flooding
-
            01:08 <@mids> but I understand that my vision on that is biased
-
            01:08 <@mids> based on years of IRC trauma's :)
-
            01:09 < Kyl3> yes but there are some bots that are useful
-
            01:09 <@mids> Where are those bots good for?
-
            01:09 <@mids> .
-
            01:09 < ArdVark> what is defined as channel flooding?
-
            01:09 < UnDeRToW> for what?
-
            01:10 < Kyl3> there are some bots that are used for channel protection
-
            01:11 <@mids> like?
-
            01:11 <@mids> ArdVark: good one... anybody?
-
            01:11 < Kyl3> like my eggdrop on DALnet
-
            01:11 < UnDeRToW> but here is not necesary channel protection
-
            01:11 <@mids> I would say: filling the communication channel with data
-
            01:11 < Kyl3> all custom flood protection
-
            01:11 < UnDeRToW> at least now
-
            01:12 <@mids> Kyl3: true, but with Trent, I don't think that is a real issue here
-
            01:12 < ArdVark> excuse me but please define filling the communication channel with data
-
            01:12 <@mids> re flooding: but I agree that it is very personal what is seen as flood
-
            01:12 <@mids> Kyl3: what is flood in your wording?
-
            01:12 <@mids> communcation channel is irc channel / query window / message window
-
            01:13 <@mids> data = ascii characters on itc
-
            01:13 < Kyl3> so Trent has channel protections built into it?
-
            01:13 <@mids> and filling is putting too much into it
-
            01:13 <@mids> Kyl3: no, not like you mean...
-
            01:13 < ArdVark> no I have seen users place huge paragraphs of words in a channel without any negative response; perhaps a friend of an OP
-
            01:14 < UnDeRToW> I think the best way to control that is some @ on public channels that only go up when a problem appear
-
            01:14 <@mids> ArdVark: big pastes (what is big) is flood to imho
-
            01:14 <@mids> and jesus stating all the bible chapters is too... imho again
-
            01:15 < ArdVark> however mids you have offered no negative responses to some individuals; friends of your perhaps?
-
            01:15 < ArdVark> who paste large paragraphs
-
            01:15 <@mids> maybe friends
-
            01:15 <@mids> maybe I was away
-
            01:15 <@nop> tell you what
-
            01:15 <@nop> the best way
-
            01:15 <@nop> to determine this
-
            01:15 <@nop> is to let ircd determine it
-
            01:15 <@nop> ircd has a flood limit
-
            01:15 <@nop> and if they exceed that
-
            01:15 <@nop> it will kick them
-
            01:16 <@nop> other than that, if you're not intentionally doing it
-
            01:16 <@nop> then what's the problem
-
            01:16 <@mids> still, you can flood very easilly
-
            01:16 <@nop> yes
-
            01:16 <@nop> but intentional is obvious
-
            01:16 <@nop> so if it's intentional
-
            01:16 <@nop> we handle it
-
            01:16 <@nop> if it's not
-
            01:16 <@nop> then go on about our business
-
            01:16 < ArdVark> no too easy to decide someone is intentionally flooding nop
-
            01:16 <@nop> no need for unnecessary drama
-
            01:16 <@nop> but
-
            01:16 <@nop> it's easy to ask people to talk to the bot in a private channel
-
            01:17 <@nop> and if they are belligerent
-
            01:17 <@nop> then most likely you have probable cause of their intentions
-
            01:17 < ArdVark> I disagree
-
            01:17 <@nop> ok
-
            01:17 <@nop> ardvark
-
            01:17 <@nop> please define then
-
            01:17 <@nop> because if we can set boundaries
-
            01:18 <@nop> this argument will be quickly over
-
            01:18 < ArdVark> I have no problem with your ircd flood control notion; I have a big problem with an OP doing the "protecting"
-
            01:19 < ArdVark> OP's may have friends that they permit to "flood"; while  others are dealt with differently
-
            01:19 <@nop> yes
-
            01:19 <@mids> I think that your problem is having OPs... 
-
            01:19 <@nop> the biased issue
-
            01:19 < CyberLOK1> sorry just saw msg I have been at work
-
            01:19 < CyberLOK1> did I miss meeting?
-
            01:19 < ArdVark> yes my ultimate concern is  OP's because of the  potential to limit  speech mids
-
            01:19 <@mids> CyberLOK1: talking about flooding right now
-
            01:19 <@mids> CyberLOK1: logs: http://mids.student.utwente.nl/~mids/iip/
-
            01:19 < CyberLOK1> mids thanks
-
            01:20 <@mids> ArdVark: I totally agree on the theoretical side of that
-
            01:20 <@nop> well what about an agent
-
            01:20 < ArdVark> I will continually express my dissent about that issue
-
            01:20 <@mids> but on the practical side... without ops, how to deal with problem users that deny others to speak? (by flooding)
-
            01:22 < ArdVark> OP's are a threat to free speech, end of statement; deciding on flooding  by OP's is not objective
-
            01:22 <@mids> then please tell me how you see #anonymous without OPs.. using current available technology
-
            01:23 <@mids> everything is fine...
-
            01:23 <@nop> agent to set a standard
-
            01:23 <@mids> then 10 trouble guys enter
-
            01:23 <@nop> for flooding
-
            01:23 <@mids> and start spamming crap
-
            01:23 <@mids> what is your solution ArdVark ?
-
            01:24 < ArdVark> spam is an emotionally laden term used to point out speech other's, perhaps  most others do  not like; free speech is not just about speech I like
-
            01:24 <@mids> so these 10 guys paste #####'s with the maximum rate that the ircd allows
-
            01:25 <@mids> resulting in nobdy beeing able to see any text
-
            01:25 < UnDeRToW> but an oper can go up when a problem occur
-
            01:25 < UnDeRToW> and the rest of the time down
-
            01:25 < ArdVark> and the point is  that these guys  are  going to remain forever?
-
            01:25 <@mids> UnDeRToW: that is how it is now
-
            01:26 < UnDeRToW> i know
-
            01:26 < UnDeRToW> and if someone do a bad thing
-
            01:26 < UnDeRToW> or an oper do bad thing
-
            01:26 <@mids> ArdVark: why not.. they have a botnet with 100 t3 connections
-
            01:26 < UnDeRToW> talk and he/she know his error
-
            01:26 < UnDeRToW> and if persist
-
            01:26 < UnDeRToW> no more @
-
            01:27 < ArdVark> well I sense a real threat to free speech concern surrounding this  issue
-
            01:27 < UnDeRToW> but at least now any problem related with that, isnt it?
-
            01:28 <@mids> okay, I have a proposal
-
            01:28 <@mids> maybe we should try a period without any operators in #anonymous
-
            01:29 <@mids> few weeks
-
            01:29 <@mids> and see how it goes
-
            01:29 <@mids> fix topic to something static
-
            01:29 <@mids> channel mode +tn
-
            01:29 <@mids> and everybody removed from the trent access list
-
            01:29 <@nop> you know
-
            01:29 <@nop> this is really not fair
-
            01:29 <@nop> people are missing the point
-
            01:30 <@nop> IRC has a ruleset, and channel control and all this other shit
-
            01:30 <@nop> I understand the nature of freedom of speech
-
            01:30 <@nop> but we also have to have some sort of defense 
-
            01:30 <@nop> flooding can cause problems on networks
-
            01:30 <@nop> etc
-
            01:30 < wilde> but what's the problem really? anyone is free to open a new channel and get ops? So why is ops a bad thing in #anonymous? Open a new channel and speak freely
-
            01:30 <@nop> you can't say that's speech, really, it's 1's and 0's being abused
-
            01:30 < ArdVark> I disagree nop
-
            01:30 <@nop> the founders of specific channels, they have a choice to control the channel
-
            01:31 <@nop> if they want the #freespeech channel
-
            01:31 <@nop> then so be it
-
            01:31 <@nop> because then
-
            01:31 <@nop> you can flood it
-
            01:31 <@nop> all you want
-
            01:31 <@nop> and call it #freespeech
-
            01:31 <@nop> the technology provides the freedom
-
            01:31 <@nop> but the channel holders might not
-
            01:31 <@nop> and this is the design
-
            01:31 <@nop> you have choices
-
            01:31 < ArdVark> I must express my complete dissent officially 
-
            01:31 <@nop> and all the choices range
-
            01:31 <@nop> and that's the freedom of choice
-
            01:32 <@nop> is that if you say I disagree, I can't say, no you must agree
-
            01:32 <@nop> but in a founder's channel
-
            01:32 <@nop> I can say
-
            01:32 <@nop> we take this as flooding
-
            01:32 <@nop> we're not an op on every channel
-
            01:32 <@nop> and if there is concern
-
            01:32 <@nop> then there is concern
-
            01:32 <@nop> but #anonymous is public
-
            01:32 <@nop> which requires some governing of very basic rules
-
            01:32 <@nop> because everyone must have a chance to speak
-
            01:32 <@nop> but flooding, interpreted or not
-
            01:33 <@nop> is not going to be tolerated
-
            01:33 < ArdVark> well again I dissent
-
            01:33 <@nop> that just wouldn't make sense
-
            01:33 <@nop> it's like saying
-
            01:33 <@nop> I have the freedom to kill 10 people
-
            01:33 < UnDeRToW> but nop, and all people without op and if someone start flooding just go up and fix the prob
-
            01:33 < UnDeRToW> and then go down
-
            01:33 <@nop> yes
-
            01:33 <@nop> that's fair
-
            01:33 <@nop> but
-
            01:33 <@nop> the interpretation
-
            01:33 <@nop> is the challenge
-
            01:33 <@mids> UnDeRToW: thats what we all minus ardvark are saying...
-
            01:33 < ArdVark> because I was accused of causing flooding when someone else pasted large paragraphs into channel previously was not admonished
-
            01:34 < CyberLOK1> are we tring to justify flooding?
-
            01:34 <@nop> I agree with Ardvark's view in the sense that he may be executing his free speach
-
            01:34 <@nop> speech
-
            01:34 <@nop> but the interpretation seems to be biased
-
            01:34 <@nop> and to solve that
-
            01:34 <@nop> we need to have a standard
-
            01:34 < UnDeRToW> mids i know
-
            01:34 <@nop> but we can't just allow flooding
-
            01:34 < ArdVark> OP's are inconsistent in their  approach; let friends do stuff and  others  not
-
            01:35 < CyberLOK1> how about a control on the number of people and a throttle of max sends per second
-
            01:35 < CyberLOK1> this way it would be impossible to flood people for to long and it would really do nothing
-
            01:35 <@nop> hmm
-
            01:36 <@nop> it's not really an issue that much
-
            01:36 <@nop> and we might be a little sensitve
-
            01:36 < CyberLOK1> ArdVark remove the human part then
-
            01:36 <@nop> because we're used to public irc
-
            01:36 <@nop> and the biased ness is an issue
-
            01:37 <@nop> I say 
-
            01:37 <@nop> that unless it's seriously obvious script kiddie flooding
-
            01:37 <@nop> then we just leave it be
-
            01:37 <@nop> and at the most
-
            01:37 <@nop> we can ask questions or ask politely if they will talk to the bot in a private channel
-
            01:37 < ArdVark> problem with flooding is what if no one  is talking in channel?  suddenly I just type a lot; since no one else is talking I am not  infringing  on anyone else's speech
-
            01:37 <@nop> no you're not
-
            01:37 <@nop> and you should be allowed
-
            01:37 < ArdVark> well that was the issue the other day
-
            01:38 <@mids> aprogas asked you to stop
-
            01:38 <@mids> but you didnt see it
-
            01:38 <@mids> because of the bot output I think...
-
            01:38 <@nop> well
-
            01:38 <@nop> I think if aprogas asks to stop
-
            01:38 <@nop> he should do it privately
-
            01:38 <@nop> then he should see it
-
            01:38 <@nop> unless he's running certain irc clients
-
            01:38 <@mids> depends
-
            01:38 <@nop> but that's another issue
-
            01:38 <@mids> lot of people dont check private messages
-
            01:38 < ArdVark> he cann do it privately, but I sense  I need not stop because  of his/her request
-
            01:39 < ArdVark> if no one  else is talking
-
            01:39 <@mids> he was talking
-
            01:39 < CyberLOK1> mids ignorance is not an excuss
-
            01:39 < CyberLOK1> sorry spelling
-
            01:39 <@mids> now you dont want to stop
-
            01:39 <@mids> how much talking is needed for you to stop?
-
            01:39 < ArdVark> once again we have  Aprogas a friend of  an OP being  supported by that OP
-
            01:39 < ArdVark> therein lies the  problem
-
            01:40 <@mids> I understand your point
-
            01:40 < ArdVark> a threat to me who is no friend to the OP's and my speech
-
            01:40 <@mids> but I dont see a solution, except that you create your own channel with your rules
-
            01:41 < ArdVark> well why tell me to create one, why not tell your frend instead?
-
            01:41 <@mids> we created #anonymous
-
            01:41 < CyberLOK1> um how about 1 bot in each created channel that is oped.. then when a script kiddie flood is detected it protects the channel
-
            01:41 < ArdVark> see how it goes back to problem with OP's and their friends
-
            01:41 < CyberLOK1> then there is no more issue... no one is opped only 1 person and its not even a person so no one can claim biad
-
            01:41 < CyberLOK1> bias
-
            01:42 <@nop> but the programmer writes the biasedness
-
            01:42 < ArdVark> right
-
            01:42 < CyberLOK1> nop basic rules
-
            01:42 < CyberLOK1> if channel == lines per sec
-
            01:42 < CyberLOK1> if this many people are comming and going
-
            01:42 <@nop> hmm, mids can trent do this
-
            01:42 < CyberLOK1> then
-
            01:42 < CyberLOK1> lock channel kick out people flooding above this much
-
            01:42 < CyberLOK1> timeout at predefined
-
            01:43 <@mids> nop: technically yes, but I dont want trent to snoop on all channels
-
            01:43 <@nop> good point
-
            01:43 <@nop> what about just for #anonymous
-
            01:43 < CyberLOK1> well it would eliminate this "bias" 
-
            01:43 <@nop> which is "THE" pub channel
-
            01:43 < CyberLOK1> I mean
-
            01:43 < CyberLOK1> lets face a fact here
-
            01:44 < CyberLOK1> you take risk running to the street shouting your words
-
            01:44 < CyberLOK1> here you risk maybe we all are out to get you and record what you say
-
            01:45 < CyberLOK1> risk is all of life and if they can not deal with "snooping" (which its not but hey) then tell um to get out thier banners and head to the street
-
            01:45 <@nop> no
-
            01:45 <@nop> no snooping
-
            01:45 <@nop> we don't want snooping
-
            01:45 <@nop> the argument is not of this
-
            01:45 < CyberLOK1> nop anyone and anything can snoop
-
            01:45 <@nop> it's that #anonymous is a pub channel
-
            01:46 <@nop> what I'm saying is
-
            01:46 <@nop> we're not going to abuse the power of trent
-
            01:46 <@nop> and become the gov't
-
            01:46 < CyberLOK1> ahhh
-
            01:46 < CyberLOK1> kk well
-
            01:46 <@nop> that's hardly called for
-
            01:46 < CyberLOK1> we can form "public" channel groups
-
            01:46 < CyberLOK1> this consists of channels formed by people
-
            01:46 < CyberLOK1> who dont want ops anymore but want thier channel protected
-
            01:47 < CyberLOK1> and there for it would be a self election
-
            01:47 < CyberLOK1> an "option" 
-
            01:47 < CyberLOK1> this way no one choice is taken away
-
            01:47 < CyberLOK1> and you could use trent to protect the anonymous channel as an example
-
            01:47 <@nop> just trent for #anonymous because #anonymous is founded as the Public channel on IIP
-
            01:47 < CyberLOK1> others can leave it to op wars and other such nonsense
-
            01:47 <@nop> the rest is not trent's duty
-
            01:48 <@nop> look
-
            01:48 < CyberLOK1> nop I was thinking
-
            01:48 < CyberLOK1> I want to form a channel 
-
            01:48 < CyberLOK1> but I myself dont want to deal with ops and yada
-
            01:48 < CyberLOK1> I want just like you guys freedom of speech
-
            01:48 <@nop> ardvark I understand your concern, it makes complete sense, but without a solution or idea from you, I need to know what can be done
-
            01:48 < CyberLOK1> unless I would be allowed to run a bot in my channel
-
            01:48 <@nop> do you have a proposal
-
            01:48 <@nop> and/or can you offer one by the next meeting
-
            01:49 < ArdVark> well if you are using trent to "control" #anonymous, can you please always place in the topic or have an intro for each user?
-
            01:49 < ArdVark> to let them know of this
-
            01:49 <@nop> I don't think we will do this
-
            01:49 <@nop> but if we could have a proposal from you
-
            01:49 <@nop> by next meeting
-
            01:49 <@nop> on what ideas you think would be acceptable
-
            01:50 <@nop> then that can be accepted and we can work it out so that it make everyone happy
-
            01:50 <@nop> we are just trying to protect the network as well
-
            01:50 <@nop> and that's the stance I'm coming from
-
            01:50 <@nop> so that everyone can use it efficiently
-
            01:50 < CyberLOK1> foofd time 
-
            01:50 <@nop> and I want to respect the freedom of speech as well
-
            01:50 < ArdVark> nop I believe that must be worked out  over time, I cannot promise in some business-like  fashion a solution for next time
-
            01:50 < CyberLOK1> here here nop 
-
            01:50 <@mids> okay, thanks for dropping by CyberLOK1 
-
            01:50 <@nop> ok
-
            01:51 <@nop> that's fair
-
            01:51 < CyberLOK1> np mids
-
            01:51 <@nop> but let's just work it out
-
            01:51 <@nop> then
-
            01:51 <@nop> the hard fact is
-
            01:51 <@nop> we're humans
-
            01:51 <@nop> and a community
-
            01:51 <@nop> so it' s a challenge to not want to control
-
            01:52 <@nop> but I need a pseudo-utopia idea, but someone has to defend the utopia as well
-
            01:52 < ArdVark> no too many people are used to irc OP's where if you dissent with them you are kicked
-
            01:52 <@nop> ok
-
            01:52 < ArdVark> so if I dissent with an OP kicking someone
-
            01:52 <@nop> I understand the complain
-
            01:52 <@nop> complaint
-
            01:52 <@nop> and I believe that this can be a problem
-
            01:52 <@nop> and that no one is perfect
-
            01:52 <@nop> so what we can do is set up a standard
-
            01:52 <@nop> I think that mids idea
-
            01:52 <@nop> of no ops
-
            01:52 <@nop> in #anonymous
-
            01:52 <@nop> for a while
-
            01:52 <@nop> might be a workable solution
-
            01:52 < ArdVark> actually nop most people  will  not  complain, they will just  leave and not  return
-
            01:53 <@nop> ok
-
            01:53 <@nop> well
-
            01:53 <@nop> no ops for 2 weeks
-
            01:53 <@nop> in #anonymous
-
            01:53 <@mids> I still propose no ops for 2 weeks
-
            01:53 <@nop> and the only, and strictly only time
-
            01:53 <@nop> is if there is without a doubt a malicious attack on #anonymous
-
            01:53 <@nop> by a script kiddie
-
            01:53 <@mids> no
-
            01:53 <@mids> no ops is no ops
-
            01:53 <@nop> ok
-
            01:53 <@mids> then you have to do it right
-
            01:53 <@nop> fair enough
-
            01:54 <@nop> no ops
-
            01:54 <@nop> two weeks
-
            01:54 <@nop> in #anonymous
-
            01:54 <@nop> agreed?
-
            01:54 < UnDeRToW> not agree with no ops
-
            01:54 <@nop> all say I
-
            01:54 <@nop> we can vote can't we
-
            01:54 < UnDeRToW> one op only for big problems
-
            01:54 <@nop> that can't be done
-
            01:54 <@nop> it would still have biased
-
            01:54 <@nop> it's just 2 weeks
-
            01:54 <@nop> worse case scenario we deal with it
-
            01:54 <@nop> and measure it out
-
            01:55 <@nop> and say
-
            01:55 <@nop> is it worth it
-
            01:55 <@nop> in 2 weeks
-
            01:55 <@nop> ardvark
-
            01:55 <@mids> it would be an experiment, maybe with very interesting results
-
            01:55 <@nop> will that satisfy you for this temporarily till we can look at better options
-
            01:55 < ArdVark> OK
-
            01:55 <@nop> ok
-
            01:55 <@nop> done
-
            01:55 < ArdVark> thanks 
-
            01:55 <@mids> great
-
            01:56 <@mids> now what topic do we use?
-
            01:56 <@nop> the one that's up there
-
            01:56 <@nop> ;)
-
            01:56 <@mids> ok, do you remove everyone from the access list?
-
            01:58 <@nop> can you please mids
-
            01:58 <@nop> for two weeks
-
            02:00 < ArdVark> however I really do not think we have resolved the issue  of what is flooding; and the implications therein
-
            02:00 < ArdVark> if you want to talk about what  the network can handle
-
            02:00 < ArdVark> cause I understand programs have  limitations
-
            02:01 <@mids> (#anonymous accesslist is clear)
-
            02:01 < ArdVark> but have you ever  been in #anonymous when the conversation is  fast a furious
-
            02:01 < ArdVark> some people words pass by without being readable for me
-
            02:01 <@mids> yes, then I think that the normal typing exceeds the ircd floodrate :)
-
            02:02 < ArdVark> how is that different from so called spam or flooding?
-
            02:02 < AgentDelta> a hypothetical question, i hope i'm not out of line... if there was some kind of strong authentication system to authenticate to a known anonymous user with a micropayment account attached so users pay for breaking specified behavior, would that address flooding concerns? how difficult would it be to integrate such an api into the system?
-
            02:02 <@mids> AgentDelta: like hashcash for instance?
-
            02:02 <@mids> AgentDelta: not.. spam is also personal judged
-
            02:03 < wilde> Freedom of speech isn't equal to forcing people to listen, #anonymous is general place for chat, but if you want more freedom you should start your channel and discuss what you want and with as many sentences as you like per second
-
            02:03 <@mids> s/agentdelta/ardvark/
-
            02:03 < ArdVark> I agree mids, spam is personal
-
            02:04 <@mids> AgentDelta: and so it flood... even the flood that the ircd denies... some human picked the values for it
-
            02:04 < Neo> wilde: yeah, then you OP your own rules in your own channel.
-
            02:04 < ArdVark> look, I have no problem with people  having their  own channels with their own rules; so be it
-
            02:04 < ArdVark> #anonymous was started as I remember for anonymous free speech
-
            02:05 < AgentDelta> if the channels aren't owned, i guess you have the tragedy of the commons 
-
            02:05 < ArdVark> commons is not a tragedy
-
            02:06 < AgentDelta> no, commons isn't a tragedy, but it doesn't have a specific owner who looks out for it 
-
            02:06 < AgentDelta> and litter and other artifacts of this absence of an owner is called the tragedy
-
            02:07 < Neo> the commons can become a tragedy, and that is why we are talking about how to deal with people who flood the system and could turn #anonymous into nothing but a flood zone.
-
            02:07 < AgentDelta> ok
-
            02:07 < ArdVark> you mean like someone to be "accountable" AgentDelta?  Using the economic view of life
-
            02:08 < AgentDelta> no, "accountable" implies accountability to some outside power. if i own this piece of land, i'm going to keep it in good shape for my own selfish reasons
-
            02:08 < Neo> AgentDelta: no, accountable could mean accountable to internal users of the system.
-
            02:09 < Neo> We were thinking about forum mentors for DC forums.
-
            02:09 < Neo> They are not all powerfull channel dictators,
-
            02:09 < Neo> but if they censor people, they will be held accountable to the users of the system.
-
            02:09 < AgentDelta> explain
-
            02:09 < Neo> So if mids is the op of #anonymous and he abuses op power, then he can get removed of his status,
-
            02:10 < Neo> and he also suffers reputation damage.
-
            02:10 < Neo> So someone that is impartial controls true FLOODING and real abuse of the system by users.
-
            02:10 < AgentDelta> ok, so you have some stated standard of under what strict circumstances someone could be silenced, and if someone uses op powers demonstrably outside of the listed guidelines, he loses op status?
-
            02:10 < wilde> Actually I think this discussion is really not a big thing, everyone is free to start their own moderated/unmoderated channels, if this is a battle of the #anonymous channel I think most users agree that this general chat channel is best without flooding or promotion of child porn for example, so some minimal control is needed
-
            02:11 < ArdVark> I disagree wilde
-
            02:12 <@mids> AgentDelta: yes, but now the channel founders are free to choose their standards
-
            02:12 < AgentDelta> absent some mechanism to establish order, the most powerful takes control over any place, physical or virtual, and i submit in an irc channel, flooders and spammers are the most powerful.
-
            02:13 < AgentDelta> the sheer volume of noise can overwhelm any logical argument
-
            02:13 < AgentDelta> hehe
-
            02:13 <@mids> AgentDelta: but what is noise? :)
-
            02:13 < ArdVark> noise has it's value too
-
            02:13 < AgentDelta> that's true,
-
            02:14 < AgentDelta> you could have a channel with so much noise in it that you can insert stenographic data that is'nt obvious
-
            02:14 < wilde> ArdVark: You say you disagree, but on what?
-
            02:15 < ArdVark> wilde I will just stand on that statement for now, sorry
-
            02:15 < AgentDelta> an anonymous channel with a constant stream of noise seems to serve an entirely different purpose from an anonymous channel with expectation of real-time communication to/from other minds
-
            02:15 < Neo> The issue right now is not about noise.
-
            02:15 < AgentDelta> maybe it needs a separate channel for anonymous communication for a general purpose, and anonymous communication for conversation
-
            02:15 < Neo> It is about abuse of the #anonymous channel from users flooding the system.
-
            02:15 < wilde> ArdVark: you're arguments are brilliant
-
            02:16 < wilde> s/you're/your
-
            02:16 <@mids> Neo: and (potential) abuse of operator power
-
            02:16 <@mids> anyway, I am going to sleep.. thanks for dropping by. The channel logs are and will be available on  http://mids.student.utwente.nl/~mids/iip/
-
            02:20 < ArdVark> is the meeting  over?  guess so
-
            02:21 < Neo> yeah, got quiet in here.
-
            02:21 < ArdVark> nice discussion all, see you in #anonymous
-
            02:22 < UnDeRToW> time to sleep
-
            02:22 < UnDeRToW> bye everybody
-
            02:22 < Neo> l8r
-
            02:22 < UnDeRToW> nop
-
            02:22 < UnDeRToW> i will start with the translation of new docs soon
-
            02:22 < UnDeRToW> see you
-
            02:22 < UnDeRToW> bye
-
            10:12 -!- UserX_ is now known as UserX
-
            --- Log closed Wed Jul 03 10:29:14 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting70.html b/www.i2p2/pages/meeting70.html
deleted file mode 100644
index 6c203387..00000000
--- a/www.i2p2/pages/meeting70.html
+++ /dev/null
@@ -1,164 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 70{% endblock %}
-{% block content %}
            Tuesday, December 23, 2003 22:00:00 CET
            
-
            
-
            [22:01] <jrand0m> 0) hi 
            
-
            [22:01] <jrand0m> 1) administravia 
            
-
            [22:01] <jrand0m> 2) dev status 
            
-
            [22:02] <jrand0m> 3) services on i2p 
            
-
            [22:02] <jrand0m> 4) app status [ns, im, i2ptunnel, ...] 
            
-
            [22:02] <jrand0m> 5) ??? 
            
-
            [22:02] <thecrypto> wow, i picked a good time
            
-
            [22:02] <jrand0m> 0) hi 
            
-
            [22:02] <jrand0m> yes you did thecrypto :) 
            
-
            [22:02] <jrand0m> hi 
            
-
            [22:02] <jrand0m> welcome to meeting 70 
            
-
            [22:02] <TC> woot
            
-
            [22:03] <jrand0m> 1) administravia 
            
-
            [22:03] <thecrypto> w00t!
            
-
            [22:03] <jrand0m> mailing list, get on it for announcements / discussion / etc: (Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/ 
            
-
            [22:04] <jrand0m> bugzilla: tell me where shit is broken (and perhaps look for ways you can help! :) (Link: http://i2p.dnsalias.net/bugzilla/index.cgi)http://i2p.dnsalias.net/bugzilla/index.cgi 
            
-
            [22:04] <jrand0m> i think thats it for administravia 
            
-
            [22:05] <jrand0m> (note that i'm just talking i2p stuff here, i don't see any iip things on the agenda) 
            
-
            [22:05] <jrand0m> 2) dev status 
            
-
            [22:05] <jrand0m> 0.2.3 as originally released had a chunk of bugs, so there have been perhaps a dozen subsequent builds, but none quite stable enough to be called 0.2.3.1 yet 
            
-
            [22:06] <jrand0m> i'm rebuilding the tunnel management subsystem now, since that is the source of the bugs and 0.3 (scheduled for jan 1) needs the new pooling tunnel manager anyway. 
            
-
            [22:07] <jrand0m> making good progress on that, I'm hoping it'll be ready for use in the next day or two (i'm testing it now) 
            
-
            [22:07] <jrand0m> a description of whats up with that is on (Link: http://wiki.invisiblenet.net/iip-wiki?TunnelManagement)http://wiki.invisiblenet.net/iip-wiki?TunnelManagement 
            
-
            [22:08] <jrand0m> duck among others have been incredibly helpful in submitting bugs, logs, and helping track down a ton of problems and memory / cpu issues. 
            
-
            [22:08] <jrand0m> y'all rule, I really appreciate the help 
            
-
            [22:09] * thecrypto pulls out the "APPLAUSE" sign
            
-
            [22:09] <jrand0m> ;) 
            
-
            [22:09] <jrand0m> the # of routers have also been increasing... on avg we're at around 9-12 
            
-
            [22:09] <jrand0m> (up from 3-5 a week ago, and 6-8 in 0.2.2 times) 
            
-
            [22:10] <jrand0m> the next release will improve the reliability dramatically 
            
-
            [22:10] <jrand0m> (aka it won't get out the door until it does) 
            
-
            [22:10] <jrand0m> ok, 3) services on i2p 
            
-
            [22:11] <jrand0m> fillament started hosting his flog on i2p :) 
            
-
            [22:12] <FillaMent> and I've got another trick up my sleeve =)
            
-
            [22:12] <jrand0m> ooOOoo :) 
            
-
            [22:12] <luckypunk> tw
            
-
            [22:12] <luckypunk> hm
            
-
            [22:12] <luckypunk> hello.
            
-
            [22:12] <luckypunk> Does it work yet?
            
-
            [22:12] <jrand0m> duck started a new irc server on i2p with dcc disabled (for security reasons) plus some ident-ish features 
            
-
            [22:13] <luckypunk> lol
            
-
            [22:13] <jrand0m> luckypunk> people with 350Mhz machines will need to wait until 0.3 is out before being able to use it effectively ;) 
            
-
            [22:13] <luckypunk> yes, but is i2p reliable enough for that?
            
-
            [22:13] <jrand0m> (but subscribe to the i2p mailing list so you can get announcements) 
            
-
            [22:13] <luckypunk> i overclocked to 377
            
-
            [22:13] <luckypunk> does that help?
            
-
            [22:13] <luckypunk> lol
            
-
            [22:13] <jrand0m> i was chatting on that irc server the other day, until my irc client b0rked 
            
-
            [22:14] <jrand0m> but yes, things are a bit unreliable at the moment while the tunnel management subsystem is rebuilt 
            
-
            [22:14] <luckypunk> well, im happy my computer didn't molassify overnight again.
            
-
            [22:15] <jrand0m> any other new services i've missed?   
            
-
            [22:15] <luckypunk> well, when .3 comes out...t here'll be a yahooish service.
            
-
            [22:15] <luckypunk> ;)
            
-
            [22:15] <jrand0m> cool 
            
-
            [22:15] <TC> i should run somthing else
            
-
            [22:16] <TC> whats a service we need that doesnt require messing with apache?
            
-
            [22:16] <jrand0m> your bbs is kick ass tc, i just can't wait until i2p is reliable enough for me to get to it consistently 
            
-
            [22:16] <jrand0m> you could run a telnet based games server (e.g. adventure, etc) 
            
-
            [22:16] <luckypunk> lol
            
-
            [22:16] <TC> hah
            
-
            [22:16] <FillaMent> MUSH
            
-
            [22:17] <luckypunk> i'll do that... it's low demand.
            
-
            [22:17] <luckypunk> and i already had about 300k of tinymush code.
            
-
            [22:17] <jrand0m> yeah, the whole mush/mud/moo/ style thaang 
            
-
            [22:17] <luckypunk> heh
            
-
            [22:17] <TC> what about ultima online?
            
-
            [22:18] <thecrypto> ooh that's be fun
            
-
            [22:18] <luckypunk> "Slay FreeNet Databugs!"
            
-
            [22:18] <luckypunk> TC: =|
            
-
            [22:18] <thecrypto> we need to get a telnet client then
            
-
            [22:18] <luckypunk> maybe if we all obtained 6 ghz computers with oc-128 lines. :D
            
-
            [22:18] <jrand0m> thecrypto> /bin/telnet + i2ptunnel 
            
-
            [22:18] <thecrypto> ...yeah
            
-
            [22:18] <thecrypto> i'm sloew
            
-
            [22:19] <thecrypto> :)
            
-
            [22:19] <jrand0m> any other low hanging fruit for services?  a mail server (pop3/imap without internet mail) would rule 
            
-
            [22:19] <jrand0m> (and if it could /receive/ internet email that'd rule too) 
            
-
            [22:21] <jrand0m> ok, 4) app status 
            
-
            [22:21] <jrand0m> naming service 
            
-
            [22:21] <jrand0m> wiht / co was here earlier, but not now 
            
-
            [22:21] <jrand0m> MrEcho> how goes? 
            
-
            *** MrEcho is echo@anon.iip (Digital_Light) 
            
-
            *** on channels: #iip-dev #anonymous 
            
-
            *** on irc via server anon.iip (Official IIP )
            
-
            *** MrEcho has been idle 3 minutes, signed on at Thu Jan 01 01:00:00 1970 
            
-
            [22:23] <jrand0m> ok, perhaps we'll get back to that 
            
-
            [22:23] <jrand0m> hosts.txt has been growing as destinations have come online 
            
-
            [22:23] <jrand0m> there's a bot on the jabber server that will let you register / fetch entries 
            
-
            [22:24] <jrand0m> (plus the hosts.txt distributed with new installs is managed in cvs and mirrored at (Link: http://i2p.dnsalias.net/i2p/hosts.txt)http://i2p.dnsalias.net/i2p/hosts.txt) 
            
-
            [22:24] <jrand0m> next up, IM 
            
-
            [22:24] <jrand0m> hi thecrypto :) 
            
-
            [22:24] <jrand0m> welcome back 
            
-
            [22:25] <thecrypto> hi
            
-
            [22:25] <thecrypto> i2pim is being started from scratch
            
-
            [22:25] <thecrypto> i need to figure out how this network works but tearing apart ATalk and slowly putting it back together
            
-
            [22:25] <thecrypto> so it's slowly coming along
            
-
            [22:25] <jrand0m> word 
            
-
            [22:25] <thecrypto> i don't know if i can get group chat working
            
-
            [22:25] <thecrypto> but it's an idea
            
-
            [22:26] <jrand0m> you had mentioned the idea of 'tossing around the baton' style of group chat - not centralized, but still workable... I think that might be a way to go 
            
-
            [22:26] <thecrypto> it might involve some difficult baton passing to get it, but if anyone has an idea for how to do group chat under my model, e-mail the list i just signed onto
            
-
            [22:26] <jrand0m> hehe 
            
-
            [22:26] <jrand0m> cool 
            
-
            [22:27] <jrand0m> yeah, starting off with one on one (perhaps with send/receive file) would probably be prudent 
            
-
            [22:27] <thecrypto> yeah, the only problem would be syncronizing the baton will be difficult
            
-
            [22:27] <thecrypto> because you don't want 2 people grabbing the baton at the same time, or have the person who has the baton to drop of then et
            
-
            [22:27] <thecrypto> nety
            
-
            [22:27] <TC> token-ring-chat?
            
-
            [22:27] <jrand0m> yup, voting systems are a pain.   
            
-
            [22:28] <jrand0m> right, good ol' 2phaseCommit 
            
-
            [22:28] <thecrypto> TC: no, basically the IM network has no central presence server
            
-
            [22:28] <thecrypto> so what i'm thinking about doing is have a virtual server baton
            
-
            [22:29] <duck> ok, using a bootdisk from now on...
            
-
            [22:29] <jrand0m> the other option is to do group chat fully distributed: "group" just being "send these messages to peer X, Y, Z" 
            
-
            [22:29] <jrand0m> d'oh duck 
            
-
            [22:29] <thecrypto> yeah, but that's network by broadcast
            
-
            [22:29] <jrand0m> not really 
            
-
            [22:29] <thecrypto> which is usually the stupidest idea
            
-
            [22:29] <jrand0m> the messages have to get sent to peer X, Y, Z from someone sometime 
            
-
            [22:30] <jrand0m> its actually 1 less message than the (temporary) server based model 
            
-
            [22:30] <thecrypto> yes, but then each person has to keep track of the group
            
-
            [22:30] <jrand0m> (and the UI can make the group 'pretty') 
            
-
            [22:30] <thecrypto> and now there has to be messages passed around about what the group is current
            
-
            [22:30] <jrand0m> right, perhaps a control message stating "I think group A is X, Y, Z" 
            
-
            [22:31] <jrand0m> instead of the voting protocol 
            
-
            [22:31] <jrand0m> right, I'm not sure what way is best 
            
-
            [22:31] <jrand0m> just saying there's an option 
            
-
            [22:31] <jrand0m> no lo se  
            
-
            [22:31] <thecrypto> yeah
            
-
            [22:32] <jrand0m> anyway, if you want a 'product' on bugzilla for i2pim, lemmie know, as well as if theres anything i can do to help 
            
-
            [22:32] <thecrypto>  well, i need code for there to be bugs in first
            
-
            [22:32] <jrand0m> ;) 
            
-
            [22:33] <thecrypto> so wait a bit and i'll have something to put on bugzilla
            
-
            [22:34] <jrand0m> cool, whenever, its trivial to add 
            
-
            [22:35] <jrand0m> ok, i2ptunnel 
            
-
            [22:35] <jrand0m> i've tossed in two bug-ish things into bugzilla: (Link: http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=1)http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=1 and (Link: http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=2)http://i2p.dnsalias.net/bugzilla/show_bug.cgi?id=2 
            
-
            [22:36] <jrand0m> plus there's a thing wrt some browsers b0rking on missing trailing / 
            
-
            [22:37] <jrand0m> getting sequence numbers into i2ptunnel would be really good, as large transfers sometimes are getting corrupted (missing message thats dropped, but sequence numbers would notice that immediately and fail fast) 
            
-
            [22:37] <jrand0m> other than that, the things are minor, i2ptunnel is behaving a lot better than the router :) 
            
-
            [22:38] <jrand0m> ok, any other apps? 
            
-
            [22:39] <jrand0m> there was some discussion about NAT/SOCKS the last few days on the channel 
            
-
            [22:39] <jrand0m> a socks enabled proxy that would let people ftp, bittorrent, etc would be really great 
            
-
            [22:39] <jrand0m> plus there's the discussion aum started on the i2p list wrt file sharing / cdn 
            
-
            [22:40] <jrand0m> (i swear i didn't tell him to make that post ;) 
            
-
            [22:41] <jrand0m> i probably won't be doing anything on the app side beyond help out integrating with i2p, as there's a truckload of stuff to do in the router, so if you're interested in seeing them show up, get hackin' 
            
-
            [22:44] <jrand0m> ok, thats it for apps 
            
-
            [22:44] <jrand0m> 5) ??? 
            
-
            [22:44] <jrand0m> hi 
            
-
            [22:44] <jrand0m> any comments / questions / concerns / etc? 
            
-
            [22:45] <ardvark> I think everyone fell asleep ;)
            
-
            [22:46] <jrand0m> someone posted a question to the wiki's FAQ and it got answered after about a day, so if anyone has concerns, either post them there, to the i2p@i2p.dnsalias.net mailing list, ask it in this channel, or spraypaint it on the wall 
            
-
            [22:46] <duck> oh, meeting
            
-
            [22:46] <jrand0m> yeah, exciting, aint it ;) 
            
-
            [22:46] * jrand0m slings mud at duck
            
-
            [22:46] * mihi did not follow, sorry. he will stand in the corner for the next 5 minutes...
            
-
            [22:46] <jrand0m> hehe 
            
-
            [22:47] <jrand0m> ok, thats about it. 
            
-
            [22:48] * jrand0m *baf*s the meeting to a close
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting71.html b/www.i2p2/pages/meeting71.html
deleted file mode 100644
index fce1d5f4..00000000
--- a/www.i2p2/pages/meeting71.html
+++ /dev/null
@@ -1,336 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 71{% endblock %}
-{% block content %}
            Tuesday, December 30, 2003 22:00:00 CET
            
-
            
-
            <jrandom> 0) hi
            
-
            <jrandom> 1) router status
            
-
            <jrandom> 2) i2ptunnel
            
-
            <jrandom> 3) im
            
-
            <jrandom> 4) 0.3 plans
            
-
            <jrandom> 5) time synchronization
            
-
            <jrandom> 6) ???
            
-
            <jrandom> hello mihi, polo
            
-
            <polo> hello !
            
-
            <mihi> hi jrandom
            
-
            <jrandom> 0) hi
            
-
            <jrandom> :)
            
-
            <rsk> hi
            
-
            <i2p> <duck> hi
            
-
            <jrandom> 1) router status
            
-
            <jrandom> 0.2.3.3 is out, and it seems to be working
            
-
            <jrandom> still lots to do, of course
            
-
            <jrandom> but this should be the last 0.2 release
            
-
            <jrandom> 0.3 is going to add the peer profiling to allow routers to avoid bad routers
            
-
            <jrandom> (and 0.3.1 is a revamp of the transports)
            
-
            <jrandom> hola Ophite1
            
-
            <Ophite1> Heya.
            
-
            <rsk> so more overhead for 0.3?
            
-
            <jrandom> yes and no
            
-
            <jrandom> it will have peer testing, but its going to be more focused
            
-
            <rsk> will we see a speed up with path selection?
            
-
            <jrandom> yes
            
-
            <jrandom> there are those 'liveliness' calculators, and there will be new latency and throughput calculators added
            
-
            <jrandom> plus people will be able to tweak their own preferences for particular peers
            
-
            <jrandom> e.g. if you know you want to prefer peer X over peer Y, you will be able to give them a weighting bonus of
            
-
                      some random points
            
-
            <mihi> will there be a clean shutdown? *g*
            
-
            <jrandom> thats actually a good question mihi
            
-
            <jrandom> i2p is getting to the point where it needs an admin interface.
            
-
            <jrandom> the longest Job thats holding up its operation is the GenerateStatusConsoleJob
            
-
            <jrandom> which can now take up to 4-6 seconds
            
-
            <jrandom> (holding everything else up)
            
-
            <jrandom> that needs to go async and on demand.
            
-
            <jrandom> but i dont want to write a web listener / etc.
            
-
            <jrandom> perhaps the reverse - a servlet that starts the router and communicates with it
            
-
            <mihi> you don't need a full web server. just when you see GET, return your data.
            
-
            <jrandom> right
            
-
            <jrandom> you're right, that stuff should be in 0.3 as well.
            
-
            <mihi> and when you see something else (like SHUTDOWN), do as you please. of course only from localhost ;)
            
-
            <jrandom> aww c'mon
            
-
            <mihi> then someone can make a nice admin program
            
-
            <jrandom> right
            
-
            <mihi> you had some triggers by files, didn't you? are they documented somewhere?
            
-
            >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom
            
-
            <jrandom> those were in IDN, not the router itself
            
-
            <jrandom> but that might be a good way to go
            
-
            <jrandom> its a trivially easy system
            
-
            <jrandom> good idea, lets go that way
            
-
            <jrandom> (and i can just reuse that code :)
            
-
            <i2p> <duck> this magical filestuff starts to look like plan9
            
-
            <jrandom> lol
            
-
            <mihi> but file triggers require polling
            
-
            <jrandom> right mihi, reading a directory every 30s aint that bad
            
-
            <mihi> but a ServerSocket#accept is cheaper.
            
-
            <mihi> as it won't eat any time. (provided a good OS)
            
-
            <mihi> okay, file triggers are better than nothing, sure.
            
-
            <jrandom> server socket would allow remote admin
            
-
            <jrandom> (when appropriate)
            
-
            <jrandom> dunno.
            
-
            <jrandom> something to be worked out.
            
-
            <jrandom> (or if someone wants to jump on it and code... :)
            
-
            <mihi> and server socket could deliver the routerConsole as well.
            
-
            <jrandom> right
            
-
            <jrandom> ok, 2) i2ptunnel
            
-
            <jrandom> :)
            
-
            <jrandom> i2ptunnel still rules, and its looking like we want to add a socket based API to control it
            
-
            <i2p> <anon> aum's ic2cp2pc plans are off for now?
            
-
            <jrandom> yes, ci2cp is dead in the water, replaced with the socket based API to control I2PTunnel
            
-
            <jrandom> I think I may be able to throw on that API in the next few days, so he can get churning on the impl
            
-
            <mihi> just use a socket, make in.readLine() and feed that line to runCommand() ;)
            
-
            <rsk> what does the api give i2p?
            
-
            <jrandom> pretty much mihi (except it formats the results and send them back in a standard way)
            
-
            <mihi> with an appropriate "logger" to send the commands back.
            
-
            <mihi> s/commands/results/
            
-
            <jrandom> rsk> it lets application developers build client and server sockets over i2p without dealing with I2CP's
            
-
                      encryption needs
            
-
            <jrandom> right right
            
-
            <jrandom> i2ptunnel /does/ have an overhead for situations where there are lots of i2ptunnels
            
-
            <jrandom> regardless of the JVM
            
-
            <jrandom> i2ptunnel clients create a new destination per client contacted, and the router will perform much worse as
            
-
                      the number of local destinations grows.
            
-
            <rsk> ah
            
-
            <jrandom> this is due to the anonymity needs of the network tied to how our encryption works
            
-
            <jrandom> for applications who just want to open a tunnel or two to a peer, this new api will RULE
            
-
            <jrandom> but for applications that need to talk to lots of other peers, I2CP is the way to go.
            
-
            <jrandom> (since that is a single destination, multiplexed by i2cp)
            
-
            <jrandom> I suppose its the old TCP vs UDP balance, in a way
            
-
            <jrandom> mihi> do you have any thoughts, or some ideas for the future of i2ptunnel?
            
-
            <rsk> hows the work on the ip over i2p, or the vpn stuff going?
            
-
            <mihi> jrandom: someone write a good streaming api, and then lets i2ptunnel use it.
            
-
            <mihi> same for naming server.
            
-
            <mihi> perhaps add some sequence numbers if no one does the things above.
            
-
            <mihi> which will mean an incompatible change.
            
-
            <jrandom> incompatible changes aren't bad, we're early in dev
            
-
            <jrandom> (if we could increase the size of of the IDs too to two or four bytes per side as well?)
            
-
            <mihi> the streaming api will be an incompatible change nevertheless. and if i2p worked, we don't need sequence
            
-
                      numbers.
            
-
            <jrandom> rsk> on hold, until someone has time to run with it?
            
-
            ≡ rsk/#i2p thinks incompatible chages are the best kind
            
-
            <jrandom> right mihi
            
-
            <mihi> ID should be 3 byte atm, so why *increase* to 2 bytes?
            
-
            <jrandom> mihi> actually, I'd like to slowly deprecate mode=GUARANTEED and implement that in the streaming api
            
-
            ≡ mihi/#i2p too
            
-
            <jrandom> leaving i2p = IP, not TCP or UDP
            
-
            <jrandom> damnit I wish I had another 14 hours in the day.
            
-
            <mihi> only 14? ;)
            
-
            <jrandom> ;)
            
-
            <jrandom> aren't the 3 byte ids derived by both sides of the con?  or maybe i'm just confused
            
-
            <mihi> each side has an ID of 3 bytes, hovever, only one must be sent at a time.
            
-
            <jrandom> perhaps I'll implement the streaming API, rip out GUARANTEED, and add that socket controller next.
            
-
            <jrandom> ah ok
            
-
            <mihi> see /apps/i2p/i2ptunnel/java/src/protocol.txt
            
-
            <jrandom> right right
            
-
            <mihi> btw, who misplaced that file *there*?
            
-
            ≡ jrandom blames eco ;)
            
-
            <jrandom> wait, naw, you put 'em there
            
-
            <jrandom> didnt you?
            
-
            <jrandom> oh wait, no I imported them
            
-
            ≡ jrandom blames self for being stupid.
            
-
            <jrandom> (la la la)
            
-
            <jrandom> damn.  ok, yeah, working on the streaming API and the socket controller will allow me to mull over the peer
            
-
                      testing / profiling / selection manifesto
            
-
            <jrandom> I'll post that in a few days for comment
            
-
            <jrandom> (and it'll get my head out of the router.  variety++)
            
-
            <jrandom> mihi> anything else on i2ptunnel?
            
-
            <mihi> not that i know
            
-
            <jrandom> coo'
            
-
            <jrandom> (thanks again for taking the time to chime in on this stuff, I know you're busy with fiw and the rest)
            
-
            <jrandom> ok, thecrypto isn't here, but he's making progress on the IM app.
            
-
            <jrandom> (thats agenda item 3)
            
-
            <jrandom> 4) 0.3 plans
            
-
            <jrandom> 0.3.0 ~= peer profiling stuff, and now it'll also include the streaming api and that socket controller for
            
-
                      i2ptunnel
            
-
            <jrandom> but, if you couldn't guess, its not going to be released on jan 1
            
-
            <jrandom> jan 15 is an outside possibility.  we'll see how things go.
            
-
            <jrandom> 0.3.1 isn't a full month of work, so it may not need to get bumped.
            
-
            <jrandom> other than that, the roadmap is still pretty much on track and representative of where we're moving
            
-
            <jrandom> 5) time synchronization
            
-
            <jrandom> a new faq is posted at http://wiki.invisiblenet.net/iip-wiki?I2PTiming
            
-
            <jrandom> mihi, you had a suggestion about the fourth option there (building our own in-i2p timing)?
            
-
            <jrandom> hi brawl
            
-
            <mihi> yep.
            
-
            ∙φ∙ brawl is now known as eco_
            
-
            <eco_> hi guys
            
-
            <jrandom> oh heya eco
            
-
            <mihi> you should connect 3 random nodes and remember the diff between the avg time and local time.
            
-
            <jrandom> we just discussed the streaming API / tunnel api
            
-
            <mihi> and then hack up your own getTimeMillis that corrects that.
            
-
            <Ophite1> mihi: No, you shouldn't.
            
-
            <jrandom> mihi> so if an attacker creates 1000 nodes with the wrong time, everyone gets screwed
            
-
            <jrandom> (since avg would skew randomly in between)
            
-
            <mihi> if an attacker creates 1000 nodes, everyone gets screwed anyway...?
            
-
            <rsk> wouldnt that be self corecting?
            
-
            <Ophite1> mihi: OK, 3.
            
-
            <jrandom> no, we should be able to handle that mihi.
            
-
            <mihi> okay, then only use avg, if standard deviation is lower than 1sec or so.
            
-
            <rsk> if everyone has the same time your ok, even if that time is wrong, right?
            
-
            <jrandom> rsk> if all 1000 nodes were in sync, but what if they're all random
            
-
            <mihi> only use times that are close enough together. if not, take 3 new nodes.
            
-
            <jrandom> mihi> right, we could implement NTP (which basically does what you say, using a series of candidate averages
            
-
                      to iteratively close in on the correct time
            
-
            <mihi> but we need not care of everything (like ping latencies), as ntp does.
            
-
            <Ophite1> if we did not, mihi, time would slowly creep backwards.
            
-
            ≡ mihi/#i2p thinks that is better than let users set their time individually.
            
-
            <jrandom> so anyone who randomly picks 3 of those skewed nodes gets sent onto their own private network?
            
-
            <jrandom> what about that third option -
            
-
            <jrandom> i2p has a component that checks with a real NTP server via NTP or SNTP
            
-
            <mihi> if you have only skewed notes in your netDB, you are on that private net as well...
            
-
            <jrandom> rather than reimplementing the wheel
            
-
            <Ophite1> while I partially like that one...
            
-
            <Ophite1> NTP isn't signed, it's subject to an MITM attack.
            
-
            <Ophite1> or dns cache poisoning for, say, time.nist.gov
            
-
            <jrandom> right Ophite1, though with 200,000+ SNTP or NTP hosts, thats a large set to attack.
            
-
            <jrandom> we would definitely not sync of time.nist.gov.
            
-
            <Ophite1> connections from i2p to the NSA's time server might raise a few eyebrows, ne? :)
            
-
            <jrandom> and if an attacker goes after time.nist.gov, everyone everywhere is affected
            
-
            <jrandom> heh
            
-
            <mihi> then we combine both. ask a "real" ntp server and your neighbor. if both say the same, it's okay.
            
-
            <jrandom> so even /more/ code ;)
            
-
            <jrandom> but yeah, thats reasonable.
            
-
            <Ophite1> That's interesting. And if they don't?
            
-
            <Ophite1> pick another ntp server?
            
-
            <jrandom> refuse the peer.
            
-
            <mihi> try other ntp server and another peer.
            
-
            <mihi> until you have a match. then refuse all prev peers.
            
-
            ≡ mihi/#i2p types slower than jrandom :(
            
-
            <Ophite1> match within a certain threshold, say 1sec?
            
-
            <jrandom> 1s would be good.
            
-
            <jrandom> accepting peers up to 30s or so (to deal with lag)
            
-
            <Ophite1> is 1 sec okay on HEAVILY LADEN connections?
            
-
            <jrandom> 1s for syncing, 30s for comm.
            
-
            <Ophite1> I've seen latency on DSL get to 5 seconds when doing evil things to it.
            
-
            <jrandom> with tcp or udp?
            
-
            <Ophite1> but then, in that case, that host might not be the one you want to sync time to anyway ;)
            
-
            <jrandom> right
            
-
            <Ophite1> udp.
            
-
            <jrandom> hmm 'k
            
-
            <Ophite1> you'd have thought it'd get dropped :)
            
-
            <i2p> <duck> I think that the problem is more letting the user know that there is a problem
            
-
            <jrandom> duck> that is true.
            
-
            <i2p> <duck> only after walking through big logs they see that their clock is off (if they find it)
            
-
            <Ophite1> Maybe. Sort of.
            
-
            <i2p> <duck> or that the port is already bound
            
-
            <jrandom> an admin interface would be nice.
            
-
            <i2p> <duck> the world is better with everybody using NTP connected to their local stantrum (sp) 2 server
            
-
            CTCP Cloaking is now [On]
            
-
            <jrandom> perhaps we'll have a 0.4 release with a bunch of cleanups and end user things, prior to going 1.0?
            
-
            <jrandom> right (stratum)
            
-
            <i2p> <duck> only windows clients are not likely to have that
            
-
            <i2p> <duck> but they are also not likely to be stable
            
-
            <jrandom> windows has NTP
            
-
            <i2p> <duck> so who cares
            
-
            <Ophite1> duck: Windows XP and Windows Server 2003 include NTP.
            
-
            <jrandom> a shitload easier than with unix too
            
-
            <Ophite1> sync'ed by default to time.windows.com iirc.
            
-
            <jrandom> with drop down options for others
            
-
            <Ophite1> It's an essential part of Windows Product Activation.
            
-
            <Ophite1> can't expire if you don't know the time :)
            
-
            <jrandom> heh
            
-
            <mihi> no option at my university... all clocks are 1 hour to 5 hours off. but i might not be allowed to run i2p there
            
-
                      anyway...
            
-
            <Ophite1> mihi: i2p should try especially hard to work in such a situation...
            
-
            <jrandom> mihi> awesome!  you can help test out the hidden operation :)
            
-
            <jrandom> as an aside, I'm going to be doing some traveling this summer
            
-
            <jrandom> i'll likely be offline, without my laptop.
            
-
            <i2p> <duck> sidethought: ntp.duck.i2p :)
            
-
            <Ophite1> Look at it like this: Brianna Kazaa downloads cool new anonymous filesharing client which her best friend
            
-
                      told her was really cool and lets you chat to people secretly and stuff. Do we want to tell her that she
            
-
                      needs to set her clock within 30 seconds (how will she get some?)? Or do we want it to just work?
            
-
            <jrandom> but I'm going to make sure I can still be on I2P with just public terminals.
            
-
            CTCP Cloaking is now [Off]
            
-
            <jrandom> no brainer Ophite1.  just work (with docs for geeks)
            
-
            <jrandom> duck> bootstrap ;)
            
-
            <jrandom> and i2p will /not/ require root.
            
-
            <Ophite1> That's my point.
            
-
            <Ophite1> jrandom: would you run a router on a box you didn't have root to?
            
-
            <jrandom> so yeah, a mix between option 3 and 4
            
-
            <Ophite1> option 3.5 sounds cool to me ;)
            
-
            <jrandom> Ophite1> i'd run a hundred of them :)
            
-
            <mihi> option 3.1415926...
            
-
            <jrandom> (and move on to the next lab, run a hundred more)
            
-
            <Ophite1> Ooh. Pie. Tasty.;)
            
-
            <Ophite1> jrandom: I said you didn't have root on. Amateur. :)
            
-
            <jrandom> lol
            
-
            <jrandom> so thats basically where we're looking.
            
-
            <jrandom> until the time stuff is implemented, everyone should use option 1 or 2.
            
-
            <jrandom> for option 2, if someone could write up some docs, I'd appreciate it
            
-
            <Ophite1> that's acceptable for now as we are Not Yet Ready for Brianna Kazaa et al ;)
            
-
            <mihi> jftr: i won't test "hidden operation". my univ account has already been disabled once and i don't want it
            
-
                      another time blocked...
            
-
            <Ophite1> mihi: You are the best test we could possibly have.
            
-
            <jrandom> Ophite1 > not for test.
            
-
            <jrandom> 'k mihi, we'll find a way, and once its ready you'll be able to use it.
            
-
            <Ophite1> OK, maybe not test. Some unis get shirty enough to chuck you out rather than just block you.
            
-
            <Ophite1> I know someone at the most anti-filesharing pro-RIAA university in the USA. He runs a 2gbit dumpsite.
            
-
            <jrandom> lol nice
            
-
            <Ophite1> I appreciate that very, very few people are this ballsy.
            
-
            <jrandom> ok, thats it for time synchronization.
            
-
            <jrandom> eco_> hi.  any bt stuff you want to talk about?  {or save till next week}
            
-
            <Ophite1> but bear in mind the majority of the internet is in future probably going to become university/corporate.
            
-
                      i2p might be banned. i2p might WELL be considered abuse by major ISPs. i2p will have to work anyway.
            
-
            <Ophite1> I have a few interesting ideas along that angle I will present at a future date.
            
-
            <jrandom> word
            
-
            <Ophite1> (transport)
            
-
            <rsk> i2p is considered abuse by major ISPs, read your contract
            
-
            <Ophite1> rsk: running a distributed proxy cache?
            
-
            <rsk> running any 'server'
            
-
            <Ophite1> rsk: Not unless it relays to SMTP or WWW.
            
-
            <jrandom> running services of any time
            
-
            <jrandom> right
            
-
            <Ophite1> rsk: Hehe, I have a solution to that ;)
            
-
            <eco_> jrandom: can give a brief update
            
-
            <jrandom> floor is yours :)
            
-
            <eco_> i'm porting the java-based bittorrent client snark (www.klomp.org/snark) to get aquainted with i2p
            
-
            <eco_> first port runs on top of i2ptunnel, directly calling the java classes
            
-
            <eco_> current state: does work with 2 peers, things get messed up with > 2, tunnels aren't cleaned up, so restarting
            
-
                      is painful
            
-
            <eco_> eta: this weekend
            
-
            ≡ eco_/#i2p realises that this might be considered > 2003
            
-
            <jrandom> w00t!
            
-
            ≡ jrandom hacks time.nist.gov
            
-
            <eco_> a "real" port would probably cut the overhead of the tunnels, but that's a next step
            
-
            <jrandom> cool
            
-
            ≡ eco_/#i2p gives floor back to mc jrandom
            
-
            <jrandom> 'k, I think that was it
            
-
            <jrandom> 6) ???
            
-
            <jrandom> anyone have anything else?
            
-
            ≡ eco_/#i2p would like to express his thanks for the job well done by jrandom cs up to now
            
-
            <eco_> and that sleep has some use for home sapiens, though jrandom seems to prove this false
            
-
            <jrandom> ;)
            
-
            <jrandom> what are y'all's thoughts on meeting here as opposed to iip, until i2p is reliable enough?
            
-
            <jrandom> personally, I'm tired of meetings being cut to shreds every week.
            
-
            <i2p> <anon> lilo sucks!
            
-
            <eco_> we might be shutting people out by going here
            
-
            <jrandom> we are, I know.
            
-
            <jrandom> if we can get an iip<-->here bridge
            
-
            <i2p> <duck> IIP is shutting ppl out each day
            
-
            <jrandom> that'd be good.
            
-
            <jrandom> right.
            
-
            <jrandom> iip is, unfortunately, unusable for a reliable development community.
            
-
            <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html
            
-
            <i2p> <duck> that is the code where eyeKon etc is based on
            
-
            <jrandom> and while I like to go off coding on my own, y'all come up with really good ideas and do good stuff that is
            
-
                      essential
            
-
            ≡ rsk/#i2p is writing a windows update script
            
-
            <i2p> <duck> theoretically it could connect to 3 servers and mirror each of them
            
-
            <jrandom> word duck, perhaps I'll try to get one running on i2p.dnsalias.net
            
-
            <jrandom> ping flood from hell ;)
            
-
            <eco_> irc at duck.i2p was pretty good today, beat iip
            
-
            <jrandom> agreed
            
-
            <jrandom> dropped me a few times though.
            
-
            <jrandom> perhaps it'll be more reliable next week
            
-
            <eco_> it's in your hands :-)
            
-
            <jrandom> reliability probably won't improve until 0.3, which is ~2 weeks out
            
-
            <jrandom> (1 week to do the tunnel/streaming stuff, 1 week for peer profiling / testing)
            
-
            <jrandom> then there'll be whatever bugs that introduces :)
            
-
            <jrandom> though I should say I was really excited to stream audio from aum last night
            
-
            <jrandom> and ardvark was able to stream for 42 minutes without buffering!
            
-
            <jrandom> so perhaps we can be reliable enough
            
-
            <jrandom> (my local router is phttp only, which is probably a slight cause)
            
-
            <jrandom> ok, anyone have anything else?
            
-
            <i2p> <duck> cant thing of anything
            
-
            ≡ eco_/#i2p can't either
            
-
            ≡ jrandom winds up...
            
-
            ≡ jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting72.html b/www.i2p2/pages/meeting72.html
deleted file mode 100644
index dcf00388..00000000
--- a/www.i2p2/pages/meeting72.html
+++ /dev/null
@@ -1,659 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 72{% endblock %}
-{% block content %}
            Tuesday, Jan 6, 2004 22:00:00 CET
            
-
            
-
            [22:02] <jrand0m> agenda:
            
-
            [22:02] <jrand0m> 0) hi
            
-
            [22:02] <jrand0m> 1) http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html
            
-
            [22:02] <jrand0m> 2) [discussion]
            
-
            [22:02] <wiht> Can I add installer to agenda?
            
-
            [22:02] <jrand0m> 0) hi
            
-
            [22:02] <jrand0m> oh yes, certainly!
            
-
            [22:02] <jrand0m> we're trying something new this week
            
-
            [22:03] <wiht> You can put it at the end of the agenda.
            
-
            [22:03] <jrand0m> rather than the old talktalktalkreplytalktalktalk, the http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html post describes most of the things I had planned on saying
            
-
            [22:03] * mihi_ has joined #i2p
            
-
            [22:04] <jrand0m> instead, we're trying this week to make the meeting more discussion oriented - things people want to talk about from that post, any follow up posts, and/or anything else people want to discuss
            
-
            [22:04] <jrand0m> such as a new installer
            
-
            [22:05] <jrand0m> so, that said, people should start by checking out that email/post and we'll go from there :)
            
-
            [22:05] * mihi_away is now known as mihi
            
-
            [22:05] * kaji reads the post
            
-
            [22:05] * mihi_ is now known as mihi_backup
            
-
            [22:06] <jrand0m> 27 users with only one dup!  w0w
            
-
            [22:07] * dm is now known as dup
            
-
            [22:07] <jrand0m> ok, when people have read that, perhaps we can start by going over the index and seeing if there's anything someone wants to add / comment on / discuss?
            
-
            [22:07] <mihi> jrand0m: where do you know from that there are no more dupes?
            
-
            [22:07] <jrand0m> heh thanks dm
            
-
            [22:07] <jrand0m> mihi> I installed keyloggers on everyone's computers (bwhahahaha)
            
-
            [22:07] <wiht> I would like to add installer as topic 10, and possibly naming service as topic 11.
            
-
            [22:07] * mihi sent the followup to the wrong address :(, resending...
            
-
            [22:08] <jrand0m> good call wiht
            
-
            [22:09] <MrEcho> mrecho's new dns is in the works
            
-
            [22:09] <jrand0m> cool mihi, yeah I was wondering ;)
            
-
            [22:09] <kaji> how is dns coming along? - ah
            
-
            [22:09] <jrand0m> MrEcho> your post, right?
            
-
            [22:09] <MrEcho> working on the post
            
-
            [22:10] <jrand0m> ok, in the meantime, anyone have anything on 1) streaming? or should we jump to 2) I2PTunnel, TunnelManager, and i2pmgr?
            
-
            [22:10] <lucky> good lord... i could spend the rest of my life attempting to figure out these dependecnies.
            
-
            [22:10] <wiht> So let's say DNS/NS as topic 11.
            
-
            [22:10] <jrand0m> sounds good wiht
            
-
            [22:10] * duck walks in
            
-
            [22:11] <jrand0m> ev'nin duck
            
-
            [22:11] <mihi> ad 1, i committed code for i2ptunnel using the streaming api
            
-
            [22:11] <jrand0m> ah right, awesome mihi :) 
            
-
            [22:11] <lucky> hi duck
            
-
            [22:11] * twosandals has quit IRC (Leaving)
            
-
            [22:11] <kaji> jrand0m can several sevices use the same key if they are on diffrent ports?
            
-
            [22:11] <jrand0m> no kaji
            
-
            [22:11] <mihi> btw: why do your ant files always delete the jar before rebuilding it?
            
-
            [22:11] <jrand0m> mihi> paranoia
            
-
            [22:12] <mihi> stealing me time with debugging, i'd say ;)
            
-
            [22:12] <jrand0m> kaji> in i2p, a key /is/ a port, essentially
            
-
            [22:12] <jrand0m> heh
            
-
            [22:12] <kaji> ah
            
-
            [22:13] <jrand0m> mihi> if you want to update that, as long as it'll build the jar if the class files change thats fine
            
-
            [22:13] <mihi> if the file is newer than all files in it, and could skip it otherwise.
            
-
            [22:13] <jrand0m> right
            
-
            [22:13] <mihi> and for paranoia it is better to add a <depends> task
            
-
            [22:13] <jrand0m> agreed
            
-
            [22:13] <FillaMent> yo yo
            
-
            [22:13] <jrand0m> 'lo FillaMent
            
-
            [22:14] <jrand0m> ok, 2) i2ptunnel / tunnelmanager / i2pmgr
            
-
            [22:14] * TC has joined #i2p
            
-
            [22:15] <human> i did a little hacking to make the TunnelManager return the job ids when "openclient" or "openserver" commands are called
            
-
            [22:16] <jrand0m> kickass :)
            
-
            [22:16] <human> this way, apps using the TunnelManager know which job to close later, without parsing the "list" output
            
-
            [22:16] <jrand0m> yeah, I've not been too comfortable with using tunnelmanager's list and close, since multiple clients can b0rk each other that way
            
-
            [22:17] <jrand0m> we'll get that patch in there right after the meeting.  gracias human :)
            
-
            [22:17] <human> it involved making I2PTunnel.runCommand return some stuff (currently a Property)
            
-
            [22:17] <human> s/Property/Properties/
            
-
            [22:17] <jrand0m> oh right, there's some things to modify in that before getting it into the code
            
-
            [22:18] <human> but mihi would prefer to add some asynchronous callbacks to the Logging clas, as far as i understand...
            
-
            [22:19] <jrand0m> right - so that things can get information from the tasks immediately, without waiting for it to finish
            
-
            [22:20] * mihi has quit IRC (EOF From client)
            
-
            [22:20] <human> jrand0m: the idea is: let's I2PTunnel.runCommand() return immediately, and eventually use callbacks to get more info, right?
            
-
            [22:21] <jrand0m> right
            
-
            [22:21] <jrand0m> so the tasks fire callbacks whenever there is data to distribute
            
-
            [22:21] * mihi has joined #i2p
            
-
            [22:21] <human> well, IMHO there is another question: «how many java apps (will) use I2PTunnel.runCommand() asynchronously?»  *All* the apps currently using I2PTunnel (even via the TunnelManager) are perfectly fine with synchronous (even if long) .runCommand() calls, and making all the stuff asynchronous would only make things more complicated (IMHO)
            
-
            [22:22] * mihi uses it via the gui
            
-
            [22:22] <human> (well, "all" means the TunnelManager and apps parsing the Tunnel manager output)
            
-
            [22:22] <jrand0m> right, the gui will hang while the command is executed
            
-
            [22:22] <mihi> and entering the next 3 tunnel open commands is blocked while the first is running
            
-
            [22:23] <human> mihi: ok, i didn't know about your app... then we need some solution :-)
            
-
            [22:24] <human> mihi: asynchronous .runCommand() behaviour would require to revise the TunnelManager
            
-
            [22:24] <mihi> human: when (iyo) should runCommand terminate? when the tunnel is built, when the connection got through?
            
-
            [22:25] <mihi> "destination unreachable" will be known *after* the first connection attempt was made.
            
-
            [22:25] <jrand0m> the command pattern would have the execute() return only after it was complete.
            
-
            [22:26] <mihi> what does *complete* mean?
            
-
            [22:26] <jrand0m> (so if we're following the command pattern, runCommand would block until everything required to do that command was complete)
            
-
            [22:26] <human> mihi:  eheh, that's the question :-)
            
-
            [22:26] <jrand0m> complete for "server 1234 privkeys" would be when the server can accept connections on port 1234
            
-
            [22:26] <human> mihi: well, for TunnelServer's IMHO it should return after tunnel creation
            
-
            [22:27] <jrand0m> complete for "client 234 peer" would be complete when a connection to port 234 would successfully reach peer
            
-
            [22:27] <jrand0m> at least, thats my take
            
-
            [22:27] <mihi> how can you determint the latter?
            
-
            [22:27] <jrand0m> I really don't feel strongly either way
            
-
            [22:27] <jrand0m> perhaps a ping?
            
-
            [22:27] * Sciatica has joined #i2p
            
-
            [22:28] <mihi> and if the peer goes down just after the ping?
            
-
            [22:28] <mihi> imo it is impossible to do network apps without callbacks
            
-
            [22:28] <jrand0m> right
            
-
            [22:28] <mihi> or lotsa threads, and i prefer callback on threads synchronized to death
            
-
            [22:29] <jrand0m> perhaps it should only return after its able to /attempt/ to connect?  
            
-
            [22:29] <jrand0m> or maybe the command pattern isn't the desired pattern
            
-
            [22:29] <mihi> that's what it's doing now. and what result should it return then?
            
-
            [22:30] <mihi> the point is that you want to have a result (different from an int for the connection id)
            
-
            [22:30] <jrand0m> right, for the client command, one wants the job (so it can be closed later), but for the genkey command, one wants the public key and private key
            
-
            [22:30] * mihi cannot think of any other info that is known at that point.
            
-
            [22:30] <jrand0m> agreed, me neither.
            
-
            [22:31] <dup> 0!
            
-
            [22:31] <mihi> and genkey should wait? okay, if you think so.
            
-
            [22:31] <human> mihi: well, something like a status ("ok" or "error") and error messages...
            
-
            [22:31] <mihi> human: error messages will be "too late" imo
            
-
            [22:31] <mihi> but do what you want...
            
-
            [22:32] <mihi> as long as you make it work with the streaming api afterwards as well...
            
-
            [22:32] <jrand0m> the pain points human is addressing are the kludges in the TunnelManager that parses the logging messages.  but I agree, as long as we can expose that information via the logging interface, thats fine
            
-
            [22:32] <dup> mihi is wise.
            
-
            [22:32] <human> human: some can be communicated immediately (e. g. when the tunnel port is still in use)
            
-
            [22:32] <mihi> human is talking to himself ;)
            
-
            [22:32] <human> oops! :-)
            
-
            [22:35] <human> maybe we should see what kind of applications are being built upon I2PTunnel
            
-
            [22:35] <human> the asynchronous interface is the Right Thing(TM), but it's more complicated to use
            
-
            [22:35] <jrand0m> I think it would be best if we could keep the same functionality for the current software - including the gui.
            
-
            [22:35] <FillaMent> maybe I'm jumping in ignorantly, but perhaps a method like one might find many that deal with HTTP: getHeader(String headerName)
            
-
            [22:35] <FillaMent> smake me as needed
            
-
            [22:35] <FillaMent> smack
            
-
            [22:36] * jrand0m smake's FillaMent
            
-
            [22:36] <human> and the TunnelManager doesn't need it (since it will *never* be able to properly support asynchronous events, due to its nature)
            
-
            [22:36] * kaji has a completely off-topic idea
            
-
            [22:36] * FillaMent resigns himself to advocacy =)
            
-
            [22:37] <human> but if mihi application needs to monitor the tunnels state, then the asynchronous interface is a Must(TM)
            
-
            [22:37] <jrand0m> human> java -jar lib/I2PTunnel.jar\n.  We need to support async.
            
-
            [22:37] <kaji> i2p as a java applet so you can run it from strange computers quickly by going to a website
            
-
            [22:37] * Sciatica has quit IRC (EOF From client)
            
-
            [22:37] <human> jrand0m: yes, then we must rework the TunnelManager :-)
            
-
            [22:37] <jrand0m> kaji> i2p 3.0 :)
            
-
            [22:38] <jrand0m> agreed human, the tunnelmanager implementation was a quick and dirty impl
            
-
            [22:38] <jrand0m> do you think you could look into how that'd need to proceed?
            
-
            [22:38] * human can volunteer to adapti the TunnelManager to the asynchronous interface, when ready
            
-
            [22:38] <jrand0m> w00t :)
            
-
            [22:40] <jrand0m> ok, are we ready for agenda item 3) I2COCP
            
-
            [22:40] <human> otherwise, it would be possible to create sync and async methods for I2PTunnel
            
-
            [22:40] <jrand0m> true
            
-
            [22:40] <jrand0m> but duplication might be overkill when a little refactoring would serve the purpose
            
-
            [22:41] * baffled has quit IRC (Leaving)
            
-
            [22:41] <duck> personal concern about the tunnels: apps not closing them, so your whole tunnelmanager becomes flooded
            
-
            [22:41] <human> jrand0m: yes, we should choose the easiest solution between reworking the TunnelManager or adding new APIs to I2PTunnel :-)
            
-
            [22:42] <jrand0m> thats a good point duck.  currently there are no timeouts / expirations, and it assumes the apps using the tunnelManager are well behaving (and that the tunnelManager has no bugs [hah!])
            
-
            [22:43] <mihi> apropos new apis: should the Streaming api classes "replace" the old ones or should it be possible to use both (w/ different commands?)
            
-
            [22:43] <jrand0m> mihi> I think the streaming ones will want to replace, since once the streaming api is solid mode=GUARANTEED will go away
            
-
            [22:43] <jrand0m> (and hence the old ones wont work)
            
-
            [22:44] * MrEcho 's email sent
            
-
            [22:46] <jrand0m> anything else for the tunnel discussion?  (this obviously isn't the end of tunnel discussions overall ;)
            
-
            [22:47] * dup is now known as dm
            
-
            [22:47] <jrand0m> ok, I2COCP
            
-
            [22:47] <jrand0m> this was just something human suggested the other day and it seems to fill a gap thats not currently met.  but I think we want to hold off on implementing until we have something that wants to use it :)
            
-
            [22:48] <wiht> That is a somewhat long name, even abbreviated.
            
-
            [22:48] * jrand0m now calls I2COCP "Wilma"
            
-
            [22:48] <human> jrand0m: well, i was going to write the same words :-)
            
-
            [22:48] <jrand0m> heh cool
            
-
            [22:49] <jrand0m> ok, jumping on to 4) roadmap
            
-
            [22:49] <human> jrand0m: IMHO, in general, there should be a way for non-java apps to have a somewhat full access to the I2P network
            
-
            [22:49] <jrand0m> agreed
            
-
            [22:49] <jrand0m> the intent is that they'd use I2CP
            
-
            [22:50] <jrand0m> (as all java apps, i2ptunnel and the streaming library included, use that)
            
-
            [22:50] <human> jrand0m: yes
            
-
            [22:50] <MrEcho> I2PDNS "Janessa"
            
-
            [22:50] <jrand0m> but you're right, they'd want streaming too, so either tunnelmanager->i2ptunnel or i2cocp->streaming lib
            
-
            [22:50] * jrand0m has never met a Janessa
            
-
            [22:51] * Sciatica has joined #i2p
            
-
            [22:51] <jrand0m> ok, so, yeah, the roadmap has been updated.  no real big changes beyond pushing back 0.3 and 0.3.1 by 2 weeks, adding 2.0 info, and some more 1.0 criteria
            
-
            [22:51] <human> jrand0m: yeah, there should be "TCP" and "UDP"-like protocols for I2P, with complete protocol event reporting, accessible from non-java apps
            
-
            [22:52] <MrEcho> human, sounds good
            
-
            [22:52] <jrand0m> I want there to be every possible interface, but I don't want to overcommit with too many interfaces to be supported
            
-
            [22:52] * human wanted I2COCP (or whatever) for his I2P twisted transport (see http://www.twistedmatrix.com/), but for now he will happily kludge around the TunnelManager :-)
            
-
            [22:53] * w0rmus has quit IRC (Lost terminal)
            
-
            [22:53] <jrand0m> word.  that'd be best for now
            
-
            [22:54] <jrand0m> ok, any comments on the roadmap?  
            
-
            [22:55] <jrand0m> [nothing to see here, la la]
            
-
            [22:55] <jrand0m> ok, 5) i2pIM
            
-
            [22:55] <jrand0m> thecrypto isn't here, so we can just wait for a post to i2p@ with updates :)
            
-
            [22:55] <wiht> We have Jabber now, if I am not mistaken. Do we still need i2pIM?
            
-
            [22:55] <jrand0m> yes
            
-
            [22:55] <jrand0m> jabber has a server that gets cleartext.
            
-
            [22:56] <wiht> Oh. Very well, then; I was not aware of this.
            
-
            [22:56] <jrand0m> thats two strikes (a server, and cleartext)
            
-
            [22:56] <jrand0m> its a good solution for some things though, certainly
            
-
            [22:56] <jrand0m> actually, once thing I was thinking about this morning was if we could get i2pIM and i2psnark merged together, that would be Good.
            
-
            [22:57] <jrand0m> (but once thing at a time)
            
-
            [22:57] <jrand0m> actually, speaking of the devil, 6) i2psnark :)
            
-
            [22:57] <human> jrand0m: i sometimes used jabber with gnupg...
            
-
            [22:57] <jrand0m> for >2 person chats?
            
-
            [22:58] <jrand0m> for one on one, I totally agree there are existing solutions
            
-
            [23:01] <jrand0m> ok, on to a fun one, 7) introducing I.Toopie :)
            
-
            [23:01] <human> how would you implement encrypted >2 people chats? a shared private key?
            
-
            [23:01] <jrand0m> yes human
            
-
            [23:01] <jrand0m> or through n! shared keys in the group
            
-
            [23:02] <human> well, maybe it could be done above the existing jabber protocol...
            
-
            [23:02] <mihi> human: a shared symmetric key sent to all participants
            
-
            [23:02] <jrand0m> the hard part is dealing with joins & leaves - key rotation /etc
            
-
            [23:03] * Sciatica has quit IRC (Ping timeout)
            
-
            [23:03] <jrand0m> its in no way a trivial issue.  its really really really hard.
            
-
            [23:03] * mihi acks
            
-
            [23:03] * human agrees
            
-
            [23:04] <jrand0m> (which is why having an app designed for it rather than trying to kludge it on top of another protocol may be worthwhile)
            
-
            [23:04] <jrand0m> but thecrypto can best describe his plans
            
-
            [23:04] <jrand0m> (though its my understanding he's still open to ideas for how to deal with groups)
            
-
            [23:05] * Sciatica has joined #i2p
            
-
            [23:06] <jrand0m> ok, moving on :)  [further discussion on i2p@, etc]
            
-
            [23:06] <wiht> What is I.Toopee, though?
            
-
            [23:06] <lucky> the mascot...
            
-
            [23:06] <jrand0m> I.Toopie is a guy holding a yellow mask in front of his face
            
-
            [23:06] * lucky shudders.
            
-
            [23:07] <lucky> uh huh.
            
-
            [23:07] <lucky> can i see it?
            
-
            [23:07] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?I2PLogo
            
-
            [23:07] * mihi_backup has quit IRC (EOF From client)
            
-
            [23:07] <lucky> i have added java to my compile queue...
            
-
            [23:07] <lucky> but.. lol
            
-
            [23:07] <lucky> i already have 7 things running
            
-
            [23:07] <lucky> it'll be a while.
            
-
            [23:08] <lucky> aw, cute :P
            
-
            [23:08] <MrEcho> lol
            
-
            [23:08] <jrand0m> there have been lots of cool logos (I can't believe we've had the logo contest going on for 3 months!), and it looks like we've got some strong potential with I.Toopie.  in its simplicity, its conception, and its versatility.
            
-
            [23:08] <jrand0m> and, yeah, its cute ;)
            
-
            [23:08] <mihi> are some imgs broken or is my browser buggy?
            
-
            [23:08] <jrand0m> yeah, some are broken
            
-
            [23:09] <jrand0m> (they were put on temporary hosting sites 3 months ago)
            
-
            [23:09] <MrEcho> I.Toopie's stick is now all yellow ... 
            
-
            [23:09] <MrEcho> changed lastnight
            
-
            [23:09] <jrand0m> it is?
            
-
            [23:09] <jrand0m> people should UPDATE THE WIKI then 
            
-
            [23:09] <jrand0m> ;)
            
-
            [23:09] <MrEcho> hehe
            
-
            [23:09] <MrEcho> i dont have the pic anymore .. sorry
            
-
            [23:10] <wiht> I see the pictures with Opera, but not with Mozilla somewhy.
            
-
            [23:10] <jrand0m> you can see http://img.villagephotos.com/p/2003-10/437060/badass.jpg ?
            
-
            [23:10] <jrand0m> (thats one of the images on that page)
            
-
            [23:11] <duck> Access Denied (User Account Disabled)
            
-
            [23:11] <jrand0m> yeah, same here.
            
-
            [23:11] <MrEcho> i can see it
            
-
            [23:11] <jrand0m> but yes, DrWoo has done some kickass stuff with I.Toopie
            
-
            [23:11] <MrEcho> moz 1.5
            
-
            [23:11] * soros has quit IRC (EOF From client)
            
-
            [23:11] * mihi_away has joined #i2p
            
-
            [23:11] * lucky has quit IRC (EOF From client)
            
-
            [23:12] <jrand0m> same here MrEcho.   strange.
            
-
            [23:12] <wiht> MrEcho: I am using Mozilla 1.4.
            
-
            [23:12] <jrand0m> (same as in I'm on moz 1.5 and I'm getting access denied)
            
-
            [23:13] * jrand0m looks forward to a tray icon w/ i.toopie :)
            
-
            [23:13] <jrand0m> ok, moving on to 8) chess server
            
-
            [23:14] * Sciatica has quit IRC (Ping timeout)
            
-
            [23:14] * ion has quit IRC (Ping timeout)
            
-
            [23:14] <jrand0m> the latest hosts.txt (http://i2p.dnsalias.net/i2p/hosts.txt) contains the reference for chess.fillament.i2p
            
-
            [23:14] <jrand0m> you can use any old FICS client or just telnet to that and play away :)
            
-
            [23:14] <jrand0m> (yay)
            
-
            [23:15] <kaji> is there a goog fics client for windows?
            
-
            [23:15] <jrand0m> dunno, I ended up using telnet
            
-
            [23:15] <wiht> Does eboard work?
            
-
            [23:15] <jrand0m> (which had some fairly tough rampup to learn the commands)
            
-
            [23:15] * ion has joined #i2p
            
-
            [23:16] <jrand0m> dunno
            
-
            [23:16] * BpX has joined #i2p
            
-
            [23:16] <wiht> I will try it later.
            
-
            [23:16] <jrand0m> cool, if you could post up what you find, that'd be great
            
-
            [23:17] <jrand0m> ok, 9) DHT
            
-
            [23:17] * wilde has quit IRC (Ping timeout)
            
-
            [23:17] <jrand0m> we still don't have a dht, but perhaps this is a lead for something we can start to port
            
-
            [23:18] <jrand0m> (it uses UDP so getting it to use I2CP wouldn't be hard)
            
-
            [23:18] <MrEcho> dht???
            
-
            [23:18] <MrEcho> im blanking on that one
            
-
            [23:18] <jrand0m> MrEcho> see [10] in the email ;)
            
-
            [23:18] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?DHT
            
-
            [23:18] <Nightblade> entropy is a good enough temporary solution
            
-
            [23:18] <jrand0m> agreed
            
-
            [23:19] <jrand0m> though I think we need to look at a long term solution as well
            
-
            [23:19] * soros has joined #i2p
            
-
            [23:19] * lucky has joined #i2p
            
-
            [23:20] * human is worried about gcj/kaffe compatibility with DHTs like Bamboo (http://bamboo-dht.org/)
            
-
            [23:20] <jrand0m> yeah, bamboo is 1.4
            
-
            [23:20] <MrEcho> afk
            
-
            [23:20] <jrand0m> thats the glory of i2cp though - the router & tunnels can be gcj'ed, while things that access them can be whatever
            
-
            [23:21] <jrand0m> it /is/ purely for an app though - not as part of the core
            
-
            [23:21] <jrand0m> I'm just trying to think of things that would help the end users who end up downloading i2p do something useful right off the bat
            
-
            [23:22] <jrand0m> (being able to post uncensorable content anonymously would be a good useful thing)
            
-
            [23:22] <jrand0m> s/uncensorable/very censorship resistant/
            
-
            [23:23] <human> jrand0m: ah, ok - i thought that bamboo was going to replace Kademlia for the NetworkDB :-)
            
-
            [23:23] <Nightblade> the squid proxy is something they can do... for users for example in china that would be a very nice thing to have
            
-
            [23:23] <jrand0m> Nightblade> right, but the squid isn't scalable
            
-
            [23:24] <Nightblade> yeah i think it would be interesting to have a kind of distributed JAP
            
-
            [23:24] <jrand0m> agreed
            
-
            [23:24] <jrand0m> so that's also another thing that would be great if people could check into :)
            
-
            [23:24] <mihi> Nightblade: the prob is abuse handling - i won't open my box for any outgoing http
            
-
            [23:24] <jrand0m> I'm sure some people will though
            
-
            [23:25] <Nightblade> with an additional part where an individual node could choose what sites they want to proxy for people...  a client could send a requst for "whitehouse.com" and then one of the nodes that will do the proxying and will permit that url can answer
            
-
            [23:25] <Nightblade> yeah i think it would have to have some kind of access controls
            
-
            [23:25] <Nightblade> blacklist or whitelist
            
-
            [23:25] <jrand0m> right
            
-
            [23:25] <Nightblade> of domain names
            
-
            [23:26] <jrand0m> its the "exit policy" system.  though this is a whole project in and of itself
            
-
            [23:27] <MrEcho> it could ride on the DNS system... i guess
            
-
            [23:27] <jrand0m> certainly
            
-
            [23:27] <wiht> mihi: What if you limit the bandwidth used? Or is it the websites accessed that could get you in trouble?
            
-
            [23:27] <MrEcho> at a very later date lol
            
-
            [23:27] <jrand0m> wiht> many providers explicitly disallow running servers of any kind
            
-
            [23:28] <MrEcho> verizon fucks with port 21 for sure...
            
-
            [23:28] <wiht> jrand0m: Oh. Yes, that is a problem.
            
-
            [23:28] <Nightblade> there would have to be some way for clients to request the sites they want downloaded for them..  Broadcast requests are not a very good solution, especially on i2p
            
-
            [23:29] <mihi> wiht: the problem is the websites that can be accessed. compare the lawsuit of JAP some time ago. /me lives in the same country
            
-
            [23:29] <jrand0m> agreed.  though broadcast isn't possible without brute forcing a ~2^2300 keyspace ;)
            
-
            [23:30] <jrand0m> right mihi, people in oppresive regimes would not be able to safely run outproxies
            
-
            [23:30] <wiht> mihi: What was the lawsuit? I do not remember.
            
-
            [23:30] * dm has quit IRC (Ping timeout)
            
-
            [23:30] <Nightblade> i mean, even if you had a list of destinations that provide web proxying, you would not want to have to broadcast to them all
            
-
            [23:30] <jrand0m> right Nightblade
            
-
            [23:30] <Nightblade> request broadcast i mean
            
-
            [23:31] <mihi> the prob was that someone had accessed a child porn site and it went over a JAP proxy and they could not tell where the request came from. this was interpreted as thowing stones into police's work
            
-
            [23:31] <jrand0m> people may want to check out crowds or rewebber to see other projects that worked on this same task
            
-
            [23:31] <wiht> mihi: Ah. Thank you for the explanation. I see understand you are concerned now.
            
-
            [23:31] * mihi_away has quit IRC (Ping timeout)
            
-
            [23:31] <mihi> and made that change to the jap software that makes it possible to catch people. which was removed later
            
-
            [23:32] <wiht> Er, I understand why you are concerned.
            
-
            [23:32] <mihi> at the end it came out that the JAP would not have to disclose the data, but i don't want to know what the lawyers cost...
            
-
            [23:32] <Nightblade> yeah but didn't the police seize the information anyway?
            
-
            [23:32] <jrand0m> yes
            
-
            [23:33] <mihi> they did...
            
-
            [23:33] <jrand0m> but anyway, yes, both a scalable DHT and a scalable web proxy would be Really Good Things to have by 1.0
            
-
            [23:34] <mihi> and they cannot give it backk, can they?
            
-
            [23:34] * BpX has quit IRC (Ping timeout)
            
-
            [23:36] * Sciatica has joined #i2p
            
-
            [23:36] <jrand0m> ok, anything else for point 9? or are we on to 10/11) NS/DNS?
            
-
            [23:36] <wiht> I would like to make a brief comment about the installer after topic 10.
            
-
            [23:37] <jrand0m> 'k perhaps lets hit that now, since NS/DNS might not be uber-brief? ;)
            
-
            [23:37] <wiht> All right. The router has a start script and a stop script.
            
-
            [23:37] <jrand0m> right
            
-
            [23:37] <wiht> I would like all of the services to be done that way--to have both a start and a stop script.
            
-
            [23:37] <jrand0m> most of them do
            
-
            [23:37] <jrand0m> don't they?
            
-
            [23:38] <jrand0m> oh, not stop scripts
            
-
            [23:38] <wiht> No, just the router.
            
-
            [23:38] <wiht> That way, desired services could be started on computer bootup, just like the router. I made a post to that effect to the mailing list.
            
-
            [23:38] <jrand0m> aum is working on the i2pmgr, which is going to be both a console based and gui based control center for the services and the router itself
            
-
            [23:38] <wiht> Let's say I want to start the eep and nntp on bootup. Currently, I can't do that.
            
-
            [23:39] <jrand0m> right, you'd need to nohup startEepProxy.sh &
            
-
            [23:39] <wiht> All right. By the way, where are these scripts in CVS?
            
-
            [23:39] <MrEcho> k im back
            
-
            [23:39] * mihi_away has joined #i2p
            
-
            [23:39] <jrand0m> wiht> the scripts are in the Install.java (aka hacked)
            
-
            [23:39] <wiht> jrand0m: Thanks./
            
-
            [23:40] <jrand0m> but good point, we want it to be as simple as possible to start on boot, as well as start on demand
            
-
            [23:41] <jrand0m> ok, on to 10/11) ns/dns
            
-
            [23:41] <MrEcho> well check my email
            
-
            [23:41] <MrEcho> theres a few things i forgot about putting in there
            
-
            [23:41] <jrand0m> unfortunately your email didn't really go through to the web interface well :/
            
-
            [23:41] <MrEcho> like "temp" names
            
-
            [23:41] <MrEcho> ??
            
-
            [23:42] * Sciatica has quit IRC (Ping timeout)
            
-
            [23:42] * ion has quit IRC (Ping timeout)
            
-
            [23:42] <jrand0m> MrEcho> http://i2p.dnsalias.net/pipermail/i2p/2004-January/000072.html
            
-
            [23:42] <MrEcho> because of the gif or something
            
-
            [23:42] <MrEcho> shit .. i singed it
            
-
            [23:43] <MrEcho> sorry
            
-
            [23:43] <jrand0m> the mailing list is really intended to be text only.  pgp sigs are fine (others have posted signed things)
            
-
            [23:43] <kaji> whats a good free small antivirus?
            
-
            [23:43] * ion has joined #i2p
            
-
            [23:43] <jrand0m> kaji> linux
            
-
            [23:43] * Sciatica has joined #i2p
            
-
            [23:43] <wiht> LOL.
            
-
            [23:43] <kaji> that runs with my hardware
            
-
            [23:43] <wiht> kaji: Try AVG Antivirus for Windows.
            
-
            [23:44] * MrEcho_ has joined #i2p
            
-
            [23:44] * MrEcho has quit IRC (EOF From client)
            
-
            [23:44] <MrEcho_> fuckign iip
            
-
            [23:44] <jrand0m> MrEcho / (and anyone else interested in the NS/DNS issue)> have you read http://zooko.com/distnames.html ?
            
-
            [23:44] <MrEcho_> j, should i resend the email?
            
-
            [23:44] <jrand0m> it went through to the list fine, it just didn't get web archived correctly
            
-
            [23:44] <MrEcho_> ya
            
-
            [23:45] <wiht> jrand0m: I did not read it yet.
            
-
            [23:45] <MrEcho_> ill take a look at it later
            
-
            [23:45] * mrflibble has joined #i2p
            
-
            [23:45] <jrand0m> for those who aren't on the list, I've saved MrEcho_'s email at http://i2p.dnsalias.net/~jrandom/mrecho_dns.txt
            
-
            [23:46] <MrEcho_> thanks J
            
-
            [23:46] <kaji> its gay, it wants an email adress
            
-
            [23:46] <jrand0m> my concern is with the security and scalability of the naming service.  once we find a solution that meets those needs, fantastic, but until we do, we should be careful of interim solutions.
            
-
            [23:47] <jrand0m> kaji> email lists usually want an email address, yeah ;)
            
-
            [23:47] <kaji> i mean AVG Antivirus
            
-
            [23:47] <jrand0m> oh ;)
            
-
            [23:48] <wiht> MrEcho has several good ideas that I did not have in my specification, such as a ban list for bad clients.
            
-
            [23:49] <MrEcho_> not really a ban list
            
-
            [23:49] <jrand0m> once there are 1000 clients, does that mean that it would take 125 lookups to find a value?
            
-
            [23:49] <MrEcho_> no
            
-
            [23:49] <wiht> Not a list, but banning bad clients is something I did not have.
            
-
            [23:50] <MrEcho_> 2-4 clients for checking
            
-
            [23:50] <jrand0m> so every client will have 250 entries?
            
-
            [23:50] * mihi_away is now known as mihi_backup
            
-
            [23:50] <MrEcho_> no
            
-
            [23:50] <wiht> With what I have, it would be one lookup, possibly forwarded a couple of times to reach an authoritative server.
            
-
            [23:50] <MrEcho_> clients will only have what they need
            
-
            [23:51] <MrEcho_> it will keep querying other Clients untill they get data that matches for the check
            
-
            [23:51] <jrand0m> so with 4 peers, it'd do a random search and on average it'd take 125 lookups
            
-
            [23:51] <jrand0m> (1000/4/2)
            
-
            [23:51] <jrand0m> or are the peers a DHT?
            
-
            [23:52] <jrand0m> (with some maintenance protocol?)
            
-
            [23:52] <jrand0m> or a search tree?
            
-
            [23:52] <MrEcho_> in a way yes
            
-
            [23:52] <MrEcho_> ill have a cut off on client searches, it will just query the MS
            
-
            [23:53] <jrand0m> secure distributed naming is a fairly well studied problem - what would make your proposal easier to analyze the security and scalability would be if you could draw comparisons and validate variations on other approaches, perhaps?
            
-
            [23:54] <MrEcho_> if it doesnt find / or get enough data from Clients within a set range it will then just query the MS.
            
-
            [23:54] <jrand0m> as is, there isn't enough detail for me to have confidence in the scalability or security of the architecture.  not to say it couldn't work out well, I just can't see that it would yet.
            
-
            [23:54] <MrEcho_> cany u stop typing for a sec
            
-
            [23:54] * jrand0m stops typing.
            
-
            [23:55] <MrEcho_> its going to work .. it will have scalability, it will have security
            
-
            [23:56] <MrEcho_> the more users the better it will get
            
-
            [23:56] <jrand0m> so "trust me", 'eh?
            
-
            [23:56] <MrEcho_> do you trust the Internet DNS system?
            
-
            [23:56] <jrand0m> for some tasks.
            
-
            [23:57] <jrand0m> for many, no.
            
-
            [23:57] <jrand0m> (its quite easy for govts / etc to get records changed - court cases order registrars to update all the time)
            
-
            [23:58] <MrEcho_> only other way of doing it is having big ass lists of Names and lots of crypto on every client
            
-
            [23:58] <MrEcho_> and being dynamic .. forget about it
            
-
            [23:59] * mrflibble has quit IRC (EOF From client)
            
-
            [23:59] <jrand0m> I suggest reviewing zooko's paper before proceeding further, and answering his final point 5 ("why I'm wrong")
            
-
            Session Time: Wed Jan 07 00:00:00 2004
            
-
            [00:01] <jrand0m> ok, thats probably about it for point 10/11 (lots of future discussion still left on that, of course)
            
-
            [00:02] <jrand0m> anyone have any other thoughts, etc?
            
-
            [00:02] <wiht> Yes.
            
-
            [00:03] <jrand0m> care to share with the class?  :)
            
-
            [00:03] <wiht> I will be rewriting the specification I wrote. I would like to use a local SQL server to store data, not files.
            
-
            [00:03] <jrand0m> ah cool
            
-
            [00:03] <jrand0m> (same concerns go for the spec you wrote too - if you could answer zooko's last question, that'd be key :)
            
-
            [00:03] * mrflibble has joined #i2p
            
-
            [00:03] <wiht> Let MySQL or a similar server manage data storage, and let Java query that server.
            
-
            [00:04] <duck> huh ? zooko specs?
            
-
            [00:04] <wiht> I think that will be easier to implement.
            
-
            [00:04] <jrand0m> duck> naw, I'm just pointing people at his old article "Names: Decentralized, Secure, Human-Meaningful: Choose Two"
            
-
            [00:04] <duck> ah that
            
-
            [00:04] <Nightblade> wiht: what specification is that (i missed a lot of the meeting)?
            
-
            [00:04] * MrEcho has joined #i2p
            
-
            [00:04] <jrand0m> (a lot easier than rehashing why supernode/centralized servers are scary security issues ;)
            
-
            [00:05] * MrEcho_ has quit IRC (EOF From client)
            
-
            [00:05] * mihi 'd have something for the log as well ;)
            
-
            [00:05] <mihi> something longer ;)
            
-
            [00:05] <mihi> *** I2Ping results:
            
-
            [00:05] <mihi> + + +   eco.i2p
            
-
            [00:05] <mihi> + - -   jabber.duck.i2p
            
-
            [00:05] <mihi> - + +   i2pcvs.i2p
            
-
            [00:05] <mihi> - + +   duck.i2p
            
-
            [00:05] <mihi> - + -   jap.eco.i2p
            
-
            [00:05] <jrand0m> Nightblade> it was posted to iip-dev back in... august?
            
-
            [00:05] <mihi> - + +   irc.duck.i2p
            
-
            [00:05] <mihi> - + +   human.i2p
            
-
            [00:06] <mihi> - - +   nntp.duck.i2p
            
-
            [00:06] <mihi> - - -   tc.i2p
            
-
            [00:06] <mihi> - - -   dyad.i2p
            
-
            [00:06] <mihi> - - -   bozo.i2p
            
-
            [00:06] <mihi> - - -   ogg.aum.i2p
            
-
            [00:06] <mihi> - - -   fcp.entropy.i2p
            
-
            [00:06] <mihi> - - -   http.entropy.i2p
            
-
            [00:06] <Nightblade> jrandom: oh, before my time.. :)
            
-
            [00:06] <mihi> - - -   www.mail.i2p
            
-
            [00:06] <mihi> - - -   mp3.aum.i2p
            
-
            [00:06] <mihi> - - -   smtp.mail.i2p
            
-
            [00:06] <wiht> Nightblade: I posted it on September 15th.
            
-
            [00:06] <mihi> - - -   pop.mail.i2p
            
-
            [00:06] <mihi> - - -   mp3.tc.i2p
            
-
            [00:06] <mihi> - - -   lp.i2p
            
-
            [00:06] <mihi> - - -   kaji.i2p
            
-
            [00:06] <mihi> - - -   nm.i2p
            
-
            [00:06] <mihi> - - -   squid.i2p
            
-
            [00:06] <mihi> - - -   chess.fillament.i2p
            
-
            [00:06] <mihi> - - -   mesh.firerabbit.i2p
            
-
            [00:06] <mihi> - - -   nightblade.i2p
            
-
            [00:06] <mihi> - - -   aum.i2p
            
-
            [00:06] <MrEcho> gezz is anyone up and running?
            
-
            [00:06] <mihi> - - -   fillament.i2p
            
-
            [00:06] <mihi> *** Finished.
            
-
            [00:06] <mihi> why are so many hosts down...?
            
-
            [00:06] * jrand0m isn't running my servers atm
            
-
            [00:07] <FillaMent> I can connect to myself on both eep and chess
            
-
            [00:07] * mrflibble has quit IRC (Ping timeout)
            
-
            [00:07] <jrand0m> oh wait, i2pcvs is up, neat
            
-
            [00:07] <Nightblade> mihi: mine isn't up because the i2ptunnel crashes for me after a few hours
            
-
            [00:07] <mihi> so my router is broken (or it's usual I2P problems...)
            
-
            [00:08] <jrand0m> really Nightblade?  please report i2ptunnel crashes (bugzilla would be nice)
            
-
            [00:08] <Nightblade> it is in the bugzilla
            
-
            [00:08] <lucky> hi
            
-
            [00:08] <Nightblade> hold..
            
-
            [00:08] <FillaMent> Nightblade: what JVM?
            
-
            [00:08] <Nightblade> #39
            
-
            [00:08] <wiht> My router has been running for more than 12 hours now, although it had a problem in registering itself.
            
-
            [00:09] <Nightblade> java version "1.4.2-p5"
            
-
            [00:09] <Nightblade> on freebsd...  it could be a jvm problem, i don't know. java support isn't too good on freebsd
            
-
            [00:09] <jrand0m> you're right Nightblade, my bad
            
-
            [00:09] <jrand0m> thats the fairly infrequent i2cp bug 
            
-
            [00:09] <jrand0m> is that consistent for you?
            
-
            [00:09] <Nightblade> the router is very stable for me, just the i2ptunnel server tunnel gives me problems
            
-
            [00:09] <Nightblade> yeas it happened several times
            
-
            [00:10] <Nightblade> i haven't tried it recently though
            
-
            [00:10] * jrand0m just pulled fillament's eepsite
            
-
            [00:10] <jrand0m> (first try, just noticed the window was complete)
            
-
            [00:10] <FillaMent> Yeah,, I just jabbered with duck, wiht's trying to hit chess
            
-
            [00:10] <jrand0m> ah cool
            
-
            [00:10] <jrand0m> but yes, there are still reliability issues to be dealt with in the network.
            
-
            [00:10] * FillaMent nudges people with the included winking, "He'll probably be wanting to play."
            
-
            [00:10] * human 's eepsite is still up - it means that 'killall java' really helped... :-)
            
-
            [00:10] <wiht> I just successfully connected to chess server.
            
-
            [00:10] <duck> yeah?
            
-
            [00:11] <jrand0m> lol FillaMent
            
-
            [00:11] * mrflibble has joined #i2p
            
-
            [00:12] <Nightblade> is it safe to run the cvs version of i2p
            
-
            [00:12] <jrand0m> /me succesfully fetches human's 1984-2004: twenty years of GNU! :-) 
            
-
            [00:12] <jrand0m> yes Nightblade
            
-
            [00:12] <FillaMent> could not get eco...
            
-
            [00:12] <Nightblade> ok maybe i'll give that a try
            
-
            [00:12] <duck> with freenet you should always run the latest cvs version!
            
-
            [00:13] <duck> only then it is bugfree
            
-
            [00:13] <duck> s/freenet/i2p/
            
-
            [00:13] * jrand0m pulled eco.i2p
            
-
            [00:13] <FillaMent> just got duck
            
-
            [00:13] <jrand0m> "Jan 4: First field test of I2PSnark. Pretty catastrophic: no transfer at all. Guess my single router test environment wasn't very representative :-) Back to the drawing board... "
            
-
            [00:13] <jrand0m> d'oh
            
-
            [00:13] <duck> well, it worked actually
            
-
            [00:13] <duck> ardvark could snark something from me
            
-
            [00:14] <jrand0m> bt precreates the files - were the files actually valid?
            
-
            [00:14] <duck> but ze did find out the next day
            
-
            [00:14] <duck> because it was obscured in the logs
            
-
            [00:14] <jrand0m> what, you mean the logs i2p generates are fairly insane?  nawwwwww
            
-
            [00:14] <duck> no
            
-
            [00:14] <duck> the i2psnark output
            
-
            [00:14] <jrand0m> ah
            
-
            [00:15] <duck> additionally, I suspect that snark does too much churning (sp?)
            
-
            [00:15] <duck> the normal bittorrent client seems to be more easy
            
-
            [00:15] <duck> also the high delays on i2p might cause premature blocks
            
-
            [00:16] * mrflibble has quit IRC (Ping timeout)
            
-
            [00:16] <duck> last thing is that we had to restart i2ptunnel a few times :/
            
-
            [00:16] <jrand0m> agreed
            
-
            [00:16] <human> final question about I2PTunnel / I2PTunnelManager (yes, i know, i'm boring): what about my patch to make "openclient" and "openserver" return a meaningful jobId?
            
-
            [00:16] <jrand0m> so, yeah, lots of work to do
            
-
            [00:16] <human> 1. let's accept it to make the TunnelManager work until the new asynchronous architecture will be roxoring
            
-
            [00:17] <human> 2. your patch plain sucks, fuck off, and fuck the TunnelManager
            
-
            [00:17] <human> 3. ...
            
-
            [00:17] * MrEcho_ has joined #i2p
            
-
            [00:17] * mihi is for 3 ;)
            
-
            [00:17] * MrEcho has quit IRC (EOF From client)
            
-
            [00:17] <jrand0m> 4. lets see how we can update the tunnel manager to go async?  shouldn't be too hard
            
-
            [00:17] <jrand0m> the patch is good, but mihi has a point
            
-
            [00:18] <human> jrand0m: yes, i agree
            
-
            [00:18] <jrand0m> we still have 1+ weeks until 0.3, so we've got time until the next full release
            
-
            [00:18] <human> jrand0m: but my doubt is: how long will it take to have the async interface to be implemented in the TunnelManager?
            
-
            [00:18] <jrand0m> tunnelmanager itself was 2 hours, I could add async tonight
            
-
            [00:19] <jrand0m> (all that needs to happen is an update to the BufferedLogging to accept .set calls)
            
-
            [00:19] <human> jrand0m: (with "to have" i also mean "to have it implemented even in I2PTunnel)
            
-
            [00:19] <jrand0m> (or .nofity/etc)
            
-
            [00:19] <jrand0m> right
            
-
            [00:19] * mrflibble has joined #i2p
            
-
            [00:20] <jrand0m> if you'd prefer, I could start with your patch (which adds the job id) and merge it with the updates for async
            
-
            [00:21] <human> jrand0m: i could add the async interface to TunnelManager myself, but the interface still doesn't exist :-)
            
-
            [00:22] <jrand0m> right, just add public void notifyEvent(String eventName, Object value); to Logging.java
            
-
            [00:22] <human> jrand0m: i'd suggest "let's merge the dirty hack to make the job ids in the 0.3 release somewhat work, and then work on the async interface"
            
-
            [00:23] <jrand0m> 0.3 is still a ways off
            
-
            [00:23] <mihi> 0.3 should have the streaming api anyway, shouldn't it?
            
-
            [00:23] <human> jrand0m: i'm talking about the worst case
            
-
            [00:23] <wiht> jrand0m: Maybe there should be another version before 3.0 to settle these issues?
            
-
            [00:23] <jrand0m> yes mihi
            
-
            [00:23] <mihi> human: the worst case is "cvs rollback && patch -p0 your.patch"
            
-
            [00:24] <jrand0m> ok, how about this.  I'll get the async implemented and committed tonight, if you could look at it tomorrow human and see what needs to be done to get your update in there?
            
-
            [00:26] <FillaMent> jrand0m: do you have a job?
            
-
            [00:27] <jrand0m> i2p
            
-
            [00:27] <duck> get 1.0 done!
            
-
            [00:27] <FillaMent> I mean a source of income
            
-
            [00:27] <jrand0m> :)
            
-
            [00:27] <FillaMent> that you have to work for
            
-
            [00:27] <jrand0m> income is overrated.
            
-
            [00:27] * jrand0m fired my boss
            
-
            [00:27] <Nightblade> "will code for food"  - that's my motto
            
-
            [00:27] <Nightblade> lol
            
-
            [00:27] <human> mihi: well, but i and aum (who is working on a python app for the TunnelManager) would like to have jobIds ASAP...
            
-
            [00:28] <human> jrand0m: ok, i'll work on your changes later/tomorrow
            
-
            [00:28] <FillaMent> Job/Money, sleep/hygiene, food, side projects, social life: Choose any 3
            
-
            [00:29] * jrand0m only choses one.
            
-
            [00:29] <jrand0m> word human
            
-
            [00:30] <FillaMent> Anyone have any other ideas for "just tunnel to" services that would be nice to have on the network?
            
-
            [00:30] * jrand0m still wants a telnet based Adventure :)
            
-
            [00:30] <jrand0m> or a waffle bbs
            
-
            [00:30] * duck is now known as enduser
            
-
            [00:30] * jrand0m kicks enduser
            
-
            [00:31] <jrand0m> (damn, no ops)
            
-
            [00:31] <FillaMent> For OS/2 there was a comm driver that could map a comm port to a TCP port =)
            
-
            [00:31] <enduser> what difference will I see as enduser when I2PTunnel uses the SteamingAPI?
            
-
            [00:31] * enduser is now known as duck
            
-
            [00:31] <jrand0m> none
            
-
            [00:31] <human> lol
            
-
            [00:31] <FillaMent> FillaMent: friend of mine ran a BBS that way for a while
            
-
            [00:31] <jrand0m> performance, and perhaps anonymity
            
-
            [00:31] * human would like a I2P tunnel to a rootshell
            
-
            [00:32] <human> any volunteer? :-)
            
-
            [00:32] <duck> rootshell on a UML
            
-
            [00:32] <jrand0m> chroot'ed rootshells would be good
            
-
            [00:32] <jrand0m> or UML'ed :)
            
-
            [00:32] <FillaMent> human: had I a spare boxen, I'd do it
            
-
            [00:32] <jrand0m> hehe FillaMent
            
-
            [00:32] <duck> vnc connection to my vmware win98?
            
-
            [00:32] <FillaMent> seriously though guys...
            
-
            [00:32] <wiht> E-mail server would be a good one as well. Or do we have that already?
            
-
            [00:32] <FillaMent> wiht: think TC has pop and SMTP
            
-
            [00:33] <jrand0m> thats aum, but they're offline, as his box is offline
            
-
            [00:33] * human could offer telnet accounts on his GNU/Hurd system...
            
-
            [00:33] <jrand0m> ooOOoo
            
-
            [00:33] <FillaMent> well, I'm not too keen on setting up open SMTP access yet
            
-
            [00:33] <jrand0m> understandable
            
-
            [00:34] <FillaMent> maybe when the network is more stable and I've got money to up my bandwidth
            
-
            [00:34] <wiht> How about a PGP keyserver?
            
-
            [00:34] <mihi> FillaMent: you could set up a tunnel pointing to a cleartext remailer
            
-
            [00:34] <FillaMent> wiht: now THAT's a great idea =)
            
-
            [00:35] <FillaMent> mihi heh... I could just point the tunnel to my ISP SMTP box =)
            
-
            [00:35] <mihi> FillaMent: this would make *you* be resposible for abuse...
            
-
            [00:35] <mihi> s/be//
            
-
            [00:35] <duck> http://www.mit.edu/people/marc/pks/pks.html
            
-
            [00:36] <duck> seriously, should duck enterprises consider running a pgp keyserver?
            
-
            [00:37] <FillaMent> duck: I was poking into that myself... you want to handle it?
            
-
            [00:37] <duck> we have been one of the most stable service providers according to mihi's independent ping logs
            
-
            [00:37] <jrand0m> hehe
            
-
            [00:37] <wiht> duck: Yes, please consider it.
            
-
            [00:37] <jrand0m> btw duck, how do you do that?  do you restart periodically or just run on a reliable OS and JVM?
            
-
            [00:38] <FillaMent> question: does the JVM cache DNS resolves?
            
-
            [00:38] <duck> restarting is for kernel updates
            
-
            [00:38] <jrand0m> yes, but you can do some nasty trickery to avoid it FillaMent
            
-
            [00:38] * wiht notes that the meeting has gone on for 2h40m now.
            
-
            [00:38] <jrand0m> oh yeah,
            
-
            [00:39] * mrflibble sticks his hand up
            
-
            [00:39] <jrand0m> um, this meeting's log is going to be huge.  and here I was thinking posthing things up front would /shorten/ the meeting
            
-
            [00:39] <jrand0m> sup mrflibble?
            
-
            [00:39] <FillaMent> jrand0m: okay... because I am without downage but my IP changes periodically... my dyndns update script runs every hour so max 60+~10min of my named addy not pointing to my IP...
            
-
            [00:39] <FillaMent> how would that affect my router's presence on the network?
            
-
            [00:40] <mrflibble> my box could be availalbe for some kind of demony thing
            
-
            [00:40] <jrand0m> cool FillaMent, shouldn't be much of a problem, as long as you point to your dyndns
            
-
            [00:40] <wiht> mrflibble: demony?
            
-
            [00:40] <mrflibble> i guess it depends how much bandwidth the thing would use
            
-
            [00:40] <mrflibble> daemony
            
-
            [00:40] <jrand0m> w3rd mrflibble - has the router been working reliably for you, or are you just being a good sameritan?  :)
            
-
            [00:41] <mrflibble> not really, but that's because my local bw is saturated atm
            
-
            [00:41] <mrflibble> im not running it on my colo yet
            
-
            [00:41] <mrflibble> want to play around with it locally first
            
-
            [00:41] <jrand0m> ah cool.  yeah, i2p isn't really ready for wide deployment, still for testing mainly
            
-
            [00:42] <FillaMent> Heh.. I'll point a tunnel to my CUPS server and you can have anonymous printing =)
            
-
            [00:42] <jrand0m> rofl
            
-
            [00:42] <mrflibble> if there's something that u want me to run that would use <40gb bw a month, lmk
            
-
            [00:42] <FillaMent> just include a banner page so I know where to mail the hardcopy =)
            
-
            [00:42] <mrflibble> hehe
            
-
            [00:43] <jrand0m> wikked mrflibble, I'm sure we'll take you up on that :)
            
-
            [00:43] <mihi> banner | lpr ? ;)
            
-
            [00:43] <FillaMent> mihi you cah set up CUPS with a banner page
            
-
            [00:43] <mrflibble> oky doky!
            
-
            [00:43] <mihi> banner will most likely create lots of pages ;)
            
-
            [00:43] <jrand0m> ok, before we get to the mixminion->printer->post office gateway discussion, lets close this meeting ;)
            
-
            [00:44] * jrand0m readies the *baf*'er
            
-
            [00:44] * jrand0m *baf*'s the meeting closed.
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting73.html b/www.i2p2/pages/meeting73.html
deleted file mode 100644
index 34baa894..00000000
--- a/www.i2p2/pages/meeting73.html
+++ /dev/null
@@ -1,143 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 73{% endblock %}
-{% block content %}
            Tuesday, Jan 13, 2004 22:00:00 CET
            
-
            
-
            [22:01] <jrand0m> 0) hi
            
-
            [22:01] <jrand0m> 1) 0.2.3.4
            
-
            [22:01] <jrand0m> 2) 0.3
            
-
            [22:01] <jrand0m> 3) streaming library, I2COCP, CI2CP
            
-
            [22:01] <jrand0m> 4) apps
            
-
            [22:01] <jrand0m> 5) ???
            
-
            [22:01] <jrand0m> 0) hi
            
-
            [22:01] <jrand0m> hi everyone
            
-
            [22:01] <jrand0m> y'all seen http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html?
            
-
            [22:01] <jrand0m> if not, now's your chance :)
            
-
            [22:02] <jrand0m> iip has been acting up a bit, so if someone could say something every once in a while, that'd be swell 
            
-
            [22:02] <MrEcho> .
            
-
            [22:02] <jrand0m> w3rd
            
-
            [22:02] <jrand0m> ok, moving on, 1) 0.2.3.4
            
-
            [22:03] <jrand0m> there'll be a new release in the next day or so with the current state of the code, which includes a lot of bugfixes and more features
            
-
            [22:03] <jrand0m> e.g. tunnelmanager isn't in 0.2.3.3 yet
            
-
            [22:03] <MrEcho> col
            
-
            [22:03] <jrand0m> it'll be backwards incompatible, because i'm mean
            
-
            [22:04] <jrand0m> jumping onto 2) 0.3
            
-
            [22:04] <MrEcho> :P
            
-
            [22:04] <jrand0m> that'll be out fairly soon, but obviously not on thursday
            
-
            [22:04] <jrand0m> it won't be out until 0.2.3.4 is performing reliably so that everyone can reach all sites they should be able to
            
-
            [22:05] <MrEcho> cool
            
-
            [22:05] <jrand0m> well, moving right along to 3) streaming lib / etc
            
-
            [22:05] <jrand0m> well, thats all spelled out in the email :)
            
-
            [22:05] * eco has joined #i2p
            
-
            [22:05] * mihi_away is now known as mihi
            
-
            [22:05] <jrand0m> if anyone wants to get involved in it, please let me know
            
-
            [22:06] * ion has joined #i2p
            
-
            [22:06] <jrand0m> 'lo eco, mihi, ion
            
-
            [22:06] <jrand0m> ok, moving on to 4) apps 
            
-
            [22:06] <jrand0m> anyone working on an app that will run over i2p that has anything to add?
            
-
            [22:07] * wiht has joined #i2p
            
-
            [22:07] <MrEcho> re ask the quest j
            
-
            [22:07] <jrand0m> well, we're at the last agenda item, so might as well :)
            
-
            [22:08] <MrEcho> wiht .. get my email?
            
-
            [22:08] <jrand0m> anyone have anything to bring up outside the http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html post?
            
-
            [22:08] <wiht> Yes, let me read it.
            
-
            [22:08] <jrand0m> MrEcho> have you read zooko's naming page yet?
            
-
            [22:08] * jar has joined #i2p
            
-
            [22:08] <MrEcho> no .. lost the link
            
-
            [22:09] <jrand0m> (from the logs last week, http://zooko.com/distnames.html)
            
-
            [22:10] <jrand0m> anyone have anything to add, or are we at a record breaking 10 minute meeting?
            
-
            [22:10] <MrEcho> still working on my dns idea
            
-
            [22:10] <jrand0m> coo'
            
-
            [22:10] <wiht> MrEcho: Yes, I would like to work together on naming service.
            
-
            [22:10] <MrEcho> sweet
            
-
            [22:11] <wiht> But I will not have time until next Wednesday.
            
-
            [22:11] <MrEcho> ok
            
-
            [22:11] <MrEcho> will give me some time to finish up on a few things
            
-
            [22:11] <mrflibble> how long till the meet?
            
-
            [22:11] <jrand0m> -11 minutes
            
-
            [22:11] <mrflibble> oops
            
-
            [22:11] * mrflibble is v late
            
-
            [22:11] <mrflibble> :)
            
-
            [22:12] <jrand0m> (we've gone through the 5 agenda items very very quicky :)
            
-
            [22:12] * mrflibble goes back to lurking and the backscroll
            
-
            [22:12] <jrand0m> heh
            
-
            [22:12] <wiht> jrand0m: Have you measured how much CPU is used per tunnel by the server?
            
-
            [22:14] <wiht> Let me restate that: if you have five connections to other routers, and they are using 20% of CPU, how much will be used after 6th connection? Have you measured this?
            
-
            [22:15] <jrand0m> they shouldn't consume 20% of the cpu, or even 1%
            
-
            [22:15] <jrand0m> (for client tunnels - server tunnels may consume more)
            
-
            [22:15] <wiht> Server tunnels.
            
-
            [22:16] * eco has quit IRC (Ping timeout)
            
-
            [22:16] <wiht> But that will probably be dependent on your CPU speed, so that was a badly stated question.
            
-
            [22:16] <jrand0m> server tunnels before the streaming lib will require cpu load whenever a new peer connects 
            
-
            [22:18] <wiht> All right.
            
-
            [22:19] <duck> are we at #5 already?
            
-
            [22:19] * ion has quit IRC (Ping timeout)
            
-
            [22:19] <jrand0m> yup
            
-
            [22:20] * duck mentions the hosting options that home.duck.i2p provides
            
-
            [22:20] <jrand0m> ooOOoo
            
-
            [22:20] <duck> it hasnt been tested by anybody besides me though
            
-
            [22:20] <duck> waiting for betatester Ardvark to show up
            
-
            [22:20] <jrand0m> so the hosting lets someone run apache / etc?
            
-
            [22:21] <jrand0m> (or do they have to run the i2p router?
            
-
            [22:21] <duck> neither
            
-
            [22:21] <duck> they can put their html files on /home/username/public_html/
            
-
            [22:21] <duck> and it will show up on http://home.duck.i2p/~username/
            
-
            [22:21] <jrand0m> ah nice
            
-
            [22:21] <jrand0m> php support?  cgi / .pl / etc?  or just html?
            
-
            [22:22] <jrand0m> (thats kick fucking ass, in any case)
            
-
            [22:22] <duck> php and html
            
-
            [22:22] <jrand0m> wwwwwwwwwicked
            
-
            [22:22] <mihi> duck: won't that compromize your anonymity?
            
-
            [22:22] <duck> how?
            
-
            [22:22] <mihi> phpshell?
            
-
            [22:22] <mihi> or is the full apache in a vmware/UML box?
            
-
            [22:22] <duck> system, exec, etc are disabled
            
-
            [22:23] <duck> plus the host cant connect to the outsite
            
-
            [22:23] * wilde has joined #i2p
            
-
            [22:23] <duck> (it is inside an UML box)
            
-
            [22:23] <duck> (pl and other cgis are too difficult to debug without shell access, plus they often break)
            
-
            [22:23] * mihi_backup has joined #i2p
            
-
            [22:23] <jrand0m> jsp access?  :)
            
-
            [22:23] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))
            
-
            [22:23] <duck> ofcourse not
            
-
            [22:24] <mihi> and why not ssh access as well, when it's an UML box?
            
-
            [22:24] <duck> because the average IIP user will start running forkbombs
            
-
            [22:24] <jrand0m> with ssh access, they could traceroute i2p.dnsalias.net
            
-
            [22:24] <mihi> man ulimit
            
-
            [22:24] <jrand0m> ah true
            
-
            [22:24] <mihi> man limiting cpu time on uml boxes.
            
-
            [22:25] <mihi> (okay, it will crash apache, shit...)
            
-
            [22:25] <duck> man run your own host :)
            
-
            [22:25] <jrand0m> hehe
            
-
            [22:25] <lucky> hi
            
-
            [22:25] <duck> I'll add it on the todo
            
-
            [22:25] <jrand0m> a reliable hosting service provider will RULE
            
-
            [22:25] <kaji> now all we need is a wiki
            
-
            [22:25] * wiht has left #i2p (wiht)
            
-
            [22:26] * lucky has a reliable net connection...
            
-
            [22:26] <duck> you already have a wiki
            
-
            [22:26] <jrand0m> kaji> duck.i2p has one
            
-
            [22:26] <duck> wiki.invisiblenet.net
            
-
            [22:26] <jrand0m> that too
            
-
            [22:26] <kaji> oh sweet then
            
-
            [22:26] <jrand0m> (yeah, the main i2p wiki is http://wiki.invisiblenet.net/iip-wiki?I2P )
            
-
            [22:26] * dm has quit IRC (Ping timeout)
            
-
            [22:28] * mihi is now known as mihi_away
            
-
            [22:28] * mihi_backup has quit IRC (Ping timeout)
            
-
            [22:29] <jrand0m> 'k, anything else before we close out the meeting?
            
-
            [22:29] <kaji> doh, i missed the meeting?
            
-
            [22:29] <jrand0m> we're not quite done yet, but about it
            
-
            [22:29] <lucky> meeting?
            
-
            [22:29] <lucky> Oh, thats so not fair
            
-
            [22:29] <lucky> i just got home.
            
-
            [22:29] <wilde> are there logs anywhere?
            
-
            [22:29] <wilde> meeting log
            
-
            [22:30] * lucky has a log...
            
-
            [22:30] <kaji> can some one write a howto for using wget over i2p in windows?
            
-
            [22:30] <jrand0m> meeting logs at http://wiki.invisiblenet.net/iip-wiki?Meetings
            
-
            [22:30] <jrand0m> kaji you'll probably need to add the http_proxy to the environment
            
-
            [22:32] <jrand0m> ok, lets wrap this one up, and I'll post up the logs momentarily.  anyone who has anything else can post to the mailing list or just chat on here :)
            
-
            [22:32] <kaji> also im now sharing /books/ and /audio/ at kaji.i2p and i think i will make a short howto about the bugs in apache alias for windows
            
-
            [22:32] <jrand0m> word kaji!
            
-
            [22:32] * jrand0m *baf*s the meeting closed on that note
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting74.html b/www.i2p2/pages/meeting74.html
deleted file mode 100644
index 47a9dde0..00000000
--- a/www.i2p2/pages/meeting74.html
+++ /dev/null
@@ -1,190 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 74{% endblock %}
-{% block content %}
            Tuesday, Jan 20, 2004 22:00:00 CET
            
-
            
-
            [22:07] <jrand0m> agenda:
            
-
            [22:07] <jrand0m> 0) hi (read http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html)
            
-
            [22:07] <jrand0m> 1) router dev status
            
-
            [22:07] <jrand0m> 2) twisted-i2p
            
-
            [22:07] <jrand0m> 3) unit tests
            
-
            [22:07] <jrand0m> 4) network testing / monitoring
            
-
            [22:07] <jrand0m> 5) ???
            
-
            [22:07] <jrand0m> 0) hi
            
-
            [22:07] <jrand0m> hi
            
-
            [22:07] * jrand0m waves
            
-
            [22:07] <dm> ohhhh meeting!
            
-
            [22:07] * dm waves back.
            
-
            [22:07] <jrand0m> 9p gmt every tuesday :)
            
-
            [22:08] <jrand0m> people should read that url (http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html) since there's stuff in it that I need feedback on during agenda item 4
            
-
            [22:08] <jrand0m> 1) router dev status
            
-
            [22:09] <jrand0m> making progress, code currently in cvs is looking good.  i've had a script testing a series of routers for the last day or so and none of them have popped out a single ERROR message
            
-
            [22:09] <duck> reading...
            
-
            [22:10] <jrand0m> but of course thats just baseline testing (keeping the routers building tunnels correctly, tunneling data through one to another via i2ptunnel, etc)
            
-
            [22:11] * jnk has joined #i2p
            
-
            [22:11] <jrand0m> theres certainly other things that need to be fixed up in the wild, which is why there's going to be a 0.2.3.5 release in the next day or so to confirm functionality or to find new bugs
            
-
            [22:11] <jrand0m> ok, moving on
            
-
            [22:12] <jrand0m> 2) twisted+i2p
            
-
            [22:12] <duck> I do have errors
            
-
            [22:12] <duck> but probably due to others
            
-
            [22:12] <jrand0m> dropped messages and unknown tunnels, right?
            
-
            [22:12] <duck> checking
            
-
            [22:13] <jrand0m> (those are the errors I see with one of my 'live' routers but not on the test network)
            
-
            [22:13] <duck> 22:13:15.371 ERROR [ Sender 1148] er.transport.phttp.PHTTPSender: Error sending the message
            
-
            [22:13] <jrand0m> ah ok, yeah, i've been smacking around the phttp relay too
            
-
            [22:13] <duck> 21:01:01.509 ERROR [JobQueue28  ] eDatabaseSearchReplyMessageJob: Invalid router info returned from [Rout
            
-
            [22:14] <jrand0m> hmm that one is funky - could you bounce me the stacktrace?
            
-
            [22:14] <duck> I'll put it up.
            
-
            [22:14] <duck> .
            
-
            [22:14] <jrand0m> gracias
            
-
            [22:15] <jrand0m> actually, thats going to be a general rule with the future releases - WARN or INFO or DEBUG messages are fine, and ERROR or CRIT messages are things I'd like to hear about
            
-
            [22:16] <jrand0m> ok, back to 2)
            
-
            [22:16] <jrand0m> human has put together a way to use i2p via python and the twisted framework (yay!)
            
-
            [22:17] <jrand0m> see his email for more info (http://i2p.dnsalias.net/pipermail/i2p/2004-January/000100.html) 
            
-
            [22:17] <jrand0m> anything to add human?  (if you're here)
            
-
            [22:17] <duck> it is _so_ cool
            
-
            [22:17] <jrand0m> yeah, the sample code for the echo server and client look kick-ass
            
-
            [22:18] <jrand0m> ok, moving on to 3) unit tests
            
-
            [22:19] <jrand0m> yeah, there are some unit tests for most of the data structures, but they aren't "one click testable" so I don't run them on every build.  
            
-
            [22:20] <jrand0m> current thoughts are to migrate them to jUnit, as well as to merge as many of the other unit tests currently implemented in the main(..) method of various components (specifically the crypto ones) 
            
-
            [22:21] <duck> probably it is difficult to test more complex things
            
-
            [22:21] <jrand0m> thats going to come up to be on the critical path sooner rather than later, depending on where the debugging leads us
            
-
            [22:21] <jrand0m> right, the unit tests as is just test the basics
            
-
            [22:21] <duck> like routing, tcp stuff etc
            
-
            [22:21] <jrand0m> right
            
-
            [22:21] * dm sees a debate on value of unit testing coming.
            
-
            [22:21] <jrand0m> but things like the AESInputStream can be tested in collaboration with AESOutputStream
            
-
            [22:22] <duck> unit test = kickass
            
-
            [22:22] <jrand0m> (and for those watching their logs closely, there's been some funky "pushed back" behavior during decrypt streaming)
            
-
            [22:22] <jrand0m> definitely.
            
-
            [22:23] <jrand0m> unit tests are just for the, er, units.  not for the larger components (which is what agenda item 4 is about ;)
            
-
            [22:24] <jrand0m> but in any case, if someone is interested in helping out convert the existing data structure unit tests to the jUnit framework, lemmie know - it'd be much appreciated (and would give you a good foundation of the i2p codebase)
            
-
            [22:24] * mihi_away is now known as mihi
            
-
            [22:25] <dm> If it's not done by the weekend I can take a look. I know nothing about unit testing so I could learn through it.
            
-
            [22:25] <jrand0m> wikked!
            
-
            [22:25] <dm> No promises though.
            
-
            [22:25] <jrand0m> right right
            
-
            [22:25] <jrand0m> ok, moving on to 4) network testing / monitoring
            
-
            [22:26] <jrand0m> has everyone read http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html?  I don't want to just copy and paste that
            
-
            [22:26] * Frontier has joined #i2p
            
-
            [22:27] * jrand0m gives people time to digest
            
-
            [22:27] * dm says...
            
-
            [22:28] <Frontier> digest wat?
            
-
            [22:28] <dm> C) but not with automatic sending.
            
-
            [22:28] <dm> i.e. you type emaillogstojrandom.sh (.bat)
            
-
            [22:28] <dm> email or post, or whatever.
            
-
            [22:29] <dm> and when it does that it clears you log, or moves it somewhere, so you don't submit the same data twice.
            
-
            [22:29] <jrand0m> so basically B
            
-
            [22:29] <jrand0m> (or A)
            
-
            [22:29] <dm> Yeah, user-friendly B) :)
            
-
            [22:29] <jrand0m> thats one of the tricks wrt the data... that log grows to tens of megs per night
            
-
            [22:29] <jrand0m> right 
            
-
            [22:30] <dm> sorry, didn't see history=false for C.
            
-
            [22:30] <jrand0m> Frontier) we're discussing section 4 of http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html?
            
-
            [22:30] <mihi> jrand0m: man bzip2
            
-
            [22:30] <dm> So history=false with a script to post on command.
            
-
            [22:30] <dm> sorry, history=true :)
            
-
            [22:30] <dm> god, I've made a mess of it.
            
-
            [22:31] <jrand0m> right mihi, but bzip2 isn't on windows (unless we require it and install it).  or do you mean bzip2 has a flag to submit a file to a url?
            
-
            [22:32] <dm> I wouldn't worry about the size, 10s of megs for the small group of people you have here is fine.
            
-
            [22:32] <Ophite1> I vote C.
            
-
            [22:32] <dm> As long as it gets archived when you run the script to submit.
            
-
            [22:32] <Ophite1> This is a debug client.
            
-
            [22:32] <Ophite1> A in a production client of course :)
            
-
            [22:32] <mihi> jrand0m: then use GZipOutputStream
            
-
            [22:32] <jrand0m> right right Ophite1 ;)
            
-
            [22:33] <jrand0m> mihi> people might like to read these files ;)
            
-
            [22:33] <duck> yeah, opt-in for debugging participation, but once you join, make it as easy as possible for the user (so C)
            
-
            [22:33] <mihi> man zcat ;)
            
-
            [22:33] <Ophite1> jrandom: gzcat | less ;-)
            
-
            [22:33] <mihi> Ophite1: zless ;)
            
-
            [22:33] <jrand0m> C:\Documents and Settings\dev>man
            
-
            [22:33] <jrand0m> 'man' is not recognized as an internal or external command,
            
-
            [22:33] <jrand0m> operable program or batch file.
            
-
            [22:33] <jrand0m> ;)
            
-
            [22:34] <mihi> cd \cygwin <Ctrl+T> call cygwin.bat
            
-
            [22:34] * dm twiddles his thumbs.
            
-
            [22:34] <Ophite1> double-click -> winrar -> view
            
-
            [22:34] <jrand0m> ok, so we have one B, two C, whats your take mihi?
            
-
            [22:34] <jrand0m> (and anyone else?)
            
-
            [22:34] <dm> twiddle thumbs, pick nose, click click.
            
-
            [22:34] <mihi> double-click - 7zop - view. I'd say C.
            
-
            [22:35] <mihi> s/7zop/7zip/
            
-
            [22:35] <jrand0m> 3 c one b.  i kind of prefer c too, and of course if someone /doesnt/ want to submit this data, they can always say so and it won't do shit
            
-
            [22:36] <jrand0m> i'll see if i can implement both c and b
            
-
            [22:36] <dm> Looks like C it is.
            
-
            [22:36] <dm> Don't waste your time, the B person is on dialup and would offer very little data anyway ;)
            
-
            [22:36] <jrand0m> hehe
            
-
            [22:36] <jrand0m> well, c is probably going to be implemented on top of b, so it won't take any more work
            
-
            [22:37] <jar> for me : just like Ophite1 said ! A for prod client, C for debug ...
            
-
            [22:37] <jrand0m> word jar
            
-
            [22:37] <jar> just like Ophite1 said ! A for prod client, C for debug ...
            
-
            [22:37] <Ophite1> obviously not anything other than A for prod client...
            
-
            [22:37] <jar> just like Ophite1 said ! A for prod client, C for debug ...
            
-
            [22:37] <Ophite1> that's a no-brainer :)
            
-
            [22:37] <jar> sorry ... :(
            
-
            [22:37] <jrand0m> s'all good jar, we won't kickban you (... this time ;)
            
-
            [22:38] <jrand0m> ok, so i'll get cracking on that, and pretty much once thats tested we'll have a new 0.2.3.5 release (sometime tomorrow)
            
-
            [22:39] <jrand0m> ok, moving on to 5) ???
            
-
            [22:39] <jrand0m> anyone have anything else?  questions, thoughts, concerns?
            
-
            [22:39] * duck offers free hosting
            
-
            [22:39] * dm accepts free hosting
            
-
            [22:39] <jrand0m> oh word.  yeah, people should host sites on host.duck.i2p, its nice having reachable pages 
            
-
            [22:39] <jrand0m> (of course people should also feel free to host for themselves too ;)
            
-
            [22:40] <duck> sure, just for those who can't stay online 24/7
            
-
            [22:40] <jrand0m> right
            
-
            [22:40] <mihi> what happened (will happen?) to the streaming api?
            
-
            [22:40] <jrand0m> mihi> its in the task list, but getting the network functioning reliably is higher priority at the moment :/
            
-
            [22:41] <mihi> but it is not dropped completely? (that's what i wanna know...)
            
-
            [22:41] <jrand0m> i'll get back to the streaming api for the 0.3.1 release (perhaps sooner, but not sure)
            
-
            [22:41] <jrand0m> its definitely NOT dropped completely.
            
-
            [22:41] <jrand0m> it will be done.
            
-
            [22:41] <dm> What's this streaming API? A different way of exposing the network to clients?
            
-
            [22:42] <jrand0m> dm> http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary
            
-
            [22:43] <jrand0m> I made what is arguably a mistake of including mode=guaranteed in the router from the beginning instead of putting it in a seperate lib (and now i'm trying to move it out of the router :)
            
-
            [22:43] <jrand0m> (the insanely awesome benefit of that mistake was mihi coming along and writing i2ptunnel :)
            
-
            [22:44] * wn-user has joined #i2p
            
-
            [22:44] <jrand0m> anyone else have anything?
            
-
            [22:44] * dm gets it.
            
-
            [22:45] <jrand0m> w3rd
            
-
            [22:45] <dm> Hmmm, too early to end meeting, ain't it?
            
-
            [22:45] <duck> what about the hosts.txt
            
-
            [22:45] <duck> it is growing and growing
            
-
            [22:45] <jrand0m> well, 45 mins.  two weeks ago we had 20 mins
            
-
            [22:45] <jrand0m> ah, true that
            
-
            [22:45] <duck> but 75% is offline
            
-
            [22:45] <duck> and it looks like 50% is permanently offline
            
-
            [22:45] <jrand0m> prolly
            
-
            [22:46] <jrand0m> I dunno
            
-
            [22:46] <duck> just keep it growing, to raise the incentive for a DNS solution :)
            
-
            [22:46] <jrand0m> heh exactly
            
-
            [22:46] <Ophite1> I'm all for a little delay, I'm having a lot of fun with all kinds of Windows problems...
            
-
            [22:46] <dm> Ophite1: windows is the devil!
            
-
            [22:46] <Ophite1> You never really understand just how awful Windows is, until you write software for it.
            
-
            [22:47] <jrand0m> reason #941 to use java 
            
-
            [22:47] <dm> Unless you're using .NET.
            
-
            [22:47] <dm> also known as java++
            
-
            [22:47] <Ophite1> dm/jrand0m: it's still running *on* Windows, and there are still some things you just keep running into.
            
-
            [22:47] <duck> jrand0m: those last patches, would they solve disconnects? or more connection problems
            
-
            [22:47] <Ophite1> Path lengths for example. Bloody unicode.
            
-
            [22:48] <mihi> Or not to use \n in file names ;)
            
-
            [22:48] <mihi> which will crash cvs anyway (on *nix, BTDT)
            
-
            [22:48] <jrand0m> duck> no patches today are critical
            
-
            [22:48] <duck> from yesterday I mean
            
-
            [22:49] <dm> What happens if you use \n in a filenamE? :)
            
-
            [22:49] <mihi> dm: try it ;) on *nix, nothing happens, as long as you don't try to run cvs update afterwards.
            
-
            [22:49] <jrand0m> oh, yesterday there were Good patches that would solve some (most? all?) i2ptunnel Peer unreachable messages.  not i2cp disconnects though
            
-
            [22:50] <dm> I think it would throw an exception.
            
-
            [22:50] <jrand0m> (which is one of the reasons 0.2.3.5 is coming out)
            
-
            [22:51] <mihi> dm: it works w/ local repository, but not w/ pserver or ssh.
            
-
            [22:51] <mihi> something like 'protocol error'.
            
-
            [22:51] <mihi> (the protocol terminates file names by \n ;) )
            
-
            [22:51] <Ophite1> sort of like what happens with direct connect if you have filenames with $ and | in them. I hate DC.
            
-
            [22:51] <duck> .
            
-
            [22:52] <Ophite1> No matter what I code, ever, it could never be that bad :)
            
-
            [22:52] <jrand0m> naw, you c devs just treat \0 as special instead of $ ;)
            
-
            [22:52] <jrand0m> ok, anything else on i2p or we good to go?
            
-
            [22:53] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))
            
-
            [22:54] <jrand0m> 'k thazzit
            
-
            [22:54] * jrand0m *baf*s the meeting to a close
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting75.html b/www.i2p2/pages/meeting75.html
deleted file mode 100644
index f62713e3..00000000
--- a/www.i2p2/pages/meeting75.html
+++ /dev/null
@@ -1,104 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 75{% endblock %}
-{% block content %}
            Tuesday, Jan 27, 2004 22:00:00 CET
            
-
            
-
            [22:03] <jrand0m> 0) hi
            
-
            [22:03] <jrand0m> 1) router dev status (0.2.4)
            
-
            [22:03] <jrand0m> 2) RTCP
            
-
            [22:03] <jrand0m> 3) i2p.net
            
-
            [22:03] <jrand0m> 4) ???
            
-
            [22:03] <jrand0m> 0) hi
            
-
            [22:03] * jrand0m waves
            
-
            [22:03] <jrand0m> this is meeting $num
            
-
            [22:03] <duck> .
            
-
            [22:03] * mihi_backup has joined #i2p
            
-
            [22:03] <jrand0m> logs will go up onto the wiki once we're through
            
-
            [22:03] * Robert has quit IRC (Ping timeout)
            
-
            [22:04] * baffled has quit IRC (Ping timeout)
            
-
            [22:04] <jrand0m> ok, moving on (hopefully battling ping timeouts)... 1) router dev status
            
-
            [22:04] * baffled has joined #i2p
            
-
            [22:05] <jrand0m> some more bugfixes this week, and a large part of the delay and associated message loss has been narrowed down the PHTTP transport
            
-
            [22:06] <jrand0m> to avoid repeating myself from the email [http://i2p.dnsalias.net/pipermail/i2p/2004-January/000113.html], so, does anyone have any questions / comments on the dev status?
            
-
            [22:06] <duck> yes
            
-
            [22:06] <jrand0m> sup?
            
-
            [22:06] <duck> seems that still after a while the whole tunnel thing locks up
            
-
            [22:07] <duck> then madman2003 and human have to shout at me
            
-
            [22:07] <duck> and restart everything
            
-
            [22:08] <jrand0m> hmm, yeah, I think thats due in large part to the fucked up nature of the 0.2.3.5 PHTTP code.  There are some routers out there that are only reachable via PHTTP, and if they are still running plain 0.2.3.5, they won't be able to talk to each other (but will be able to talk to you)
            
-
            [22:08] * jar has joined #i2p
            
-
            [22:08] <madman2003> i'd like to say one thing(a bit offtopic): a 404 page in 0.3 would be nice, because a lot of browsers get confused if they don't get an expected response
            
-
            [22:08] <jrand0m> that means that whenever you build a tunnel through them, your tunnel is unreachable
            
-
            [22:09] * DrWoo has quit IRC (Ping timeout)
            
-
            [22:09] <jrand0m> duck> thats one of the reasons on the 'pro' camp for releasing a 0.2.3.6 asap, with 0.2.4 coming out with RTCP in few days
            
-
            [22:09] * DrWoo has joined #i2p
            
-
            [22:09] <duck> ok, so that is phttp part?
            
-
            [22:09] <jrand0m> (the 'con' camp being led by "upgrading sucks")
            
-
            [22:10] <jrand0m> hmm?  the phttp code has been patched in cvs
            
-
            [22:10] <duck> what con camp?
            
-
            [22:10] <jrand0m> madman2003> I think baffled might be looking at that :)
            
-
            [22:10] <madman2003> upgrading is easy :)
            
-
            [22:10] <kaji> upgrading rox
            
-
            [22:10] <madman2003> with i2pmgr it's even easier
            
-
            [22:11] <madman2003> just a touch of a button :)
            
-
            [22:11] * Robert has joined #i2p
            
-
            [22:11] <baffled2> I'm looking at it madman might be a while!
            
-
            [22:11] <jrand0m> well, the con side is that if there's a release (in, say, a few hours), people will have to do another upgrade in, say, 2-3 days
            
-
            [22:11] <jrand0m> if thats fine, i can wrap up a 0.2.3.6 quite easily
            
-
            [22:11] <duck> updating makes me happy
            
-
            [22:12] <kaji> what does .6 fix?
            
-
            [22:12] <baffled2> I'd say go for it most of us don't have any problem with upgrading regularly.
            
-
            [22:12] <madman2003> i'd upgrade every 24 hours if that does it
            
-
            [22:12] <jrand0m> 0.2.3.6 fixes PHTTP to be, er, functional
            
-
            [22:12] <jrand0m> ok cool
            
-
            [22:13] <jrand0m> i'll get a 0.2.3.6 wrapped up after the meeting then (perhaps 1-2 hours to clean up) and post on the list when its ready
            
-
            [22:13] <jrand0m> (as well as here)
            
-
            [22:13] * Masterboy has quit IRC (Ping timeout)
            
-
            [22:14] <jrand0m> ok, anything else for the dev status, or shall we jump to 2) RTCP
            
-
            [22:15] * jrand0m jmp 2
            
-
            [22:15] <madman2003> you can always get back to it
            
-
            [22:15] <jrand0m> right right
            
-
            [22:15] <jrand0m> ok, rtcp is coming along, and I'm hoping to have the client side libs working after a few more hours of coding
            
-
            [22:16] <jrand0m> Kirk brought up a good point on the list for chaining - in theory, all of these relays could have an inter-relay connection to build a virtual relay network
            
-
            [22:16] <jrand0m> but, well, that essentially grows into IRC, or another full on anon network
            
-
            [22:17] <madman2003> you mean totally eliminating PHTTP?
            
-
            [22:17] <jrand0m> while thats possible (and quite interesting), I think for now we'll just have the stand alone RTCP relay (and/or integrated relay in the router)
            
-
            [22:18] <jrand0m> madman2003> no, PHTTP will stay (if only for time sync and people behind HTTP only firewalls), but RTCP provides a faster, low latency alternative
            
-
            [22:18] <madman2003> (i'd intergrate in the router, because that would spread the load of the relaying)
            
-
            [22:18] <jrand0m> agreed
            
-
            [22:19] <jrand0m> basically the topology I forsee with the RTCP is everyone who can have a reachable address will run their own RTCP relay (with their own targetId on that), plus anyone who doesn't have a reachable address can just pick any of those that do and create a target on them
            
-
            [22:20] <jrand0m> these relays essentially become switchboards for peer comm, but in a fully distributed fashion (since none of them depend in any way on any of the other ones)
            
-
            [22:20] <madman2003> or use multiple relays if the there are more relays then people who need relays
            
-
            [22:20] <baffled2> How would folks find the various rtcp relays?
            
-
            [22:20] <madman2003> phttp :)
            
-
            [22:20] <jrand0m> right, thats a good point - routers can create targets on multiple relays
            
-
            [22:20] <jrand0m> baffled> rtcp relays will be listed in a router's RouterInfo (published in the networkDb)
            
-
            [22:21] <jrand0m> basically a router will see "oh, router XYZ has an rtcp address at 127.0.0.1:8999 targetId 3123" and then connect to 127.0.0.1:8999 and request its own target
            
-
            [22:23] <madman2003> something i just thought off: auto restart of tunnels every 12 or 24 hours
            
-
            [22:23] <madman2003> and an auto restart of router + the rest every few days
            
-
            [22:24] * jrand0m is working on making it so that wouldn't be necessary
            
-
            [22:24] <jrand0m> one of my routers on a linux box has been up without interruption for several days
            
-
            [22:24] <mihi> madman2003: you can add your own threads to the jvm to quit it after 12 hours
            
-
            [22:24] <jrand0m> (and it only went offline when I upgraded it)
            
-
            [22:24] * madman2003 has to go
            
-
            [22:25] <jrand0m> l8r madman2003
            
-
            [22:25] <madman2003> have a nice meeting
            
-
            [22:25] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))
            
-
            [22:25] <jrand0m> ok, anything else on rtcp?
            
-
            [22:26] <duck> no, sounds good
            
-
            [22:26] <jrand0m> ok, moving on to a brief one
            
-
            [22:26] <jrand0m> 3) i2p.net.  
            
-
            [22:26] <jrand0m> nuff said
            
-
            [22:26] <jrand0m> 4) ???
            
-
            [22:26] <jrand0m> anyone have anything else?
            
-
            [22:28] <duck> .
            
-
            [22:28] * jrand0m senses a record breaking 26 minute meeting
            
-
            [22:29] <Reskill> lol
            
-
            [22:29] * Reskill ambles in
            
-
            [22:29] <jrand0m> 'mornin Reskill
            
-
            [22:29] <jrand0m> ok, I'm going to get working on pushing out a 0.2.3.6, then crunch away on the rtcp code for a 0.2.4
            
-
            [22:30] <jrand0m> if there is nothing further...
            
-
            [22:30] <Reskill> Oo...
            
-
            [22:30] <baffled2> Okay, I'll see you all when I get home.
            
-
            [22:30] * jrand0m *baf*'s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting76.html b/www.i2p2/pages/meeting76.html
deleted file mode 100644
index e8264854..00000000
--- a/www.i2p2/pages/meeting76.html
+++ /dev/null
@@ -1,520 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 76{% endblock %}
-{% block content %}
            Tuesday, Feb 3, 2004 22:00:00 CET
            
-
            
-
            [22:01] <jrand0m> 0) hi
            
-
            [22:01] <jrand0m> 1) testnet
            
-
            [22:01] <jrand0m> 2) updated roadmap
            
-
            [22:01] <jrand0m> 3) updated application list
            
-
            [22:01] <jrand0m> 4) volunteers needed
            
-
            [22:01] <jrand0m> 5) ???
            
-
            [22:01] <jrand0m> 0) hi
            
-
            [22:01] * jrand0m waves
            
-
            [22:01] * mihi waves back
            
-
            [22:02] * jrand0m has to warn that i've been up for too long, so may be a little out of it
            
-
            [22:02] <jrand0m> but anyway, as we proceed, everyone should read (or have read) http://i2p.dnsalias.net/pipermail/i2p/2004-February/000132.html
            
-
            [22:02] <jrand0m> lets jump right into 1) testnet
            
-
            [22:03] <mihi> you should change the subject for each mail... they all get sorted into one thread here
            
-
            [22:03] <jrand0m> hah nice
            
-
            [22:03] * jrand0m tried for consistency (for ease of filtering)
            
-
            [22:03] <jrand0m> would you like me to add the date to it?
            
-
            [22:03] <madman2003> how is the testent really doing?(pessimistic opnion please)
            
-
            [22:03] <jrand0m> madman2003> poorly, but better than before
            
-
            [22:04] <mihi> jrand0m: date (or meeting number) would be great
            
-
            [22:04] <jrand0m> 'k mihi, consider it done
            
-
            [22:04] <jrand0m> (anyone other than me want to give some feedback to madman2003's question?)
            
-
            [22:04] <duck> madman2004: baffled and me have been connected for 4h now
            
-
            [22:04] <baffled> Really that long?
            
-
            [22:04] <duck> before test3 the maximum time was 10 min
            
-
            [22:05] <jrand0m> w00t
            
-
            [22:05] <duck> baffled: since 18:15:07 CET
            
-
            [22:05] <jrand0m> yeah i had a 90m session the other day too
            
-
            [22:05] <duck> but maybe we are directly hopped
            
-
            [22:05] <madman2003> and you're sure the link is intact?
            
-
            [22:05] <jrand0m> duck> all tunnels are 2 hop (unless your router is failing, in which case your tunnels will break at least once)
            
-
            [22:06] <jrand0m> madman2003> when the tunnels fail, they fail hard
            
-
            [22:06] <madman2003> how's general latency on the testnet?
            
-
            [22:06] * Ophite1 has joined #i2p
            
-
            [22:06] * jrand0m usually gets 2-10s latency through the squid
            
-
            [22:06] * lucky has joined #i2p
            
-
            [22:06] <jrand0m> 5-20s latency through irc
            
-
            [22:07] <madman2003> is the 30 secs delay on local sites fixed yet?
            
-
            [22:07] <jrand0m> duck> can you /ping duck on your ircd?  how long does it take to reply with a CTCP refused error?
            
-
            [22:07] <jrand0m> (or baffled>)
            
-
            [22:08] <jrand0m> madman2003> there have been significant bugfixes that would account for 30s+ delays locally
            
-
            [22:08] <jrand0m> (jobs got locked up causing insane delays)
            
-
            [22:08] <duck> response to admin request to baffleds ircd is ~8s
            
-
            [22:08] <jrand0m> duck> to local?
            
-
            [22:09] <duck> fido ping/pong is 3 seconds, which is local
            
-
            [22:09] <jrand0m> coo'
            
-
            [22:09] <duck> for local eepsites it also seems to be ~3s
            
-
            [22:09] <jrand0m> (still much higher than i'd like, but <<30s)
            
-
            [22:09] <duck> initial request longer, might be ~30s
            
-
            [22:10] <jrand0m> interesting
            
-
            [22:10] <duck> ,
            
-
            [22:10] <jrand0m> ok, so there's definitely still work to be done on the testnet, but there's been progress
            
-
            [22:10] <madman2003> is the testnet going to run until poor performance becomes perfect, what is the exact requirement of succes?
            
-
            [22:11] <madman2003> (i know about 3 days of working good)
            
-
            [22:11] <jrand0m> success == 3 consecutive days of things that should succeed succeeding.
            
-
            [22:11] <jrand0m> human has volunteered to help out and implement something along the lines of what I posted in the email
            
-
            [22:11] * mihi floods the testnet with pings ;)
            
-
            [22:11] * leenookx has quit IRC (Ping timeout)
            
-
            [22:11] <jrand0m> basically a way we can just leave a pair of bots connected to the two ircds and measure our progress and failures
            
-
            [22:12] <jrand0m> (yay human!)
            
-
            [22:12] <mihi> hmm, if there is no netsplit, i2p is working, but you cannot make the other way conclusion...
            
-
            [22:13] <jrand0m> the i2p roadmap [http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap] has the 0.2.4 release (~= testnet completion) in a week and a half
            
-
            [22:13] <madman2003> why don't you focus on making local delay <1s?
            
-
            [22:13] <jrand0m> that i will.
            
-
            [22:13] <madman2003> good chance that will solve some other problems too
            
-
            [22:13] <jrand0m> the cause of >1s delay is likely the load
            
-
            [22:14] <jrand0m> for routers with no peers, local only requests are near instantaneous
            
-
            [22:14] <jrand0m> (but as the testnet is actually showing some load, we're stressing different things)
            
-
            [22:15] <duck> baffled and me also had a little chat about making statsbots, but if human wants to do it; cool for me
            
-
            [22:15] <madman2003> maybe delays have to do with requests being send to other routers
            
-
            [22:15] <madman2003> before it see that it's local
            
-
            [22:15] <jrand0m> oh word duck
            
-
            [22:15] <jrand0m> naw, doesn't work that way madman2003
            
-
            [22:16] <jrand0m> (it gets pumped to the client manager first, which checks if its local, and only if it isn't does it get placed in the router's net pool)
            
-
            [22:16] * madman2003 wonders where all that load is coming from
            
-
            [22:16] <jrand0m> france.
            
-
            [22:16] <jrand0m> er, germany.
            
-
            [22:16] <jrand0m> (since *someone* is pinging everyone ;)
            
-
            [22:17] <duck> kuala lumpur
            
-
            [22:17] * duck hopes nobody gets that joke
            
-
            [22:17] * jrand0m is pleased to meet duck's hopes
            
-
            [22:17] <mihi> all that pings made my local box thrashing as well... (with no router!)
            
-
            [22:18] <jrand0m> mihi> the i2cp lib does the crypto ;)
            
-
            [22:18] * wiht has joined #i2p
            
-
            [22:18] <madman2003> doesn't i2p protect from ping floods?
            
-
            [22:19] <jrand0m> madman2003> the load isn't that significant, its just the code currently has very course grain synchronization (and during the testnet thats being adjusted to more fine grained sync)
            
-
            [22:19] <madman2003> grain sync?
            
-
            [22:19] <mihi> jrand0m: congrats: seems that ping -ns does not only produce - - - now
            
-
            [22:20] <jrand0m> lol mihi :)
            
-
            [22:20] <mihi> why lol? ping -ns never worked for me. (only the synchronized one)
            
-
            [22:20] <duck> synchronized one never worked for me...
            
-
            [22:20] <jrand0m> oh really?  word, -ns has been working well for me
            
-
            [22:21] <jrand0m> madman2003> its a tradeoff of memory and CPU vs concurrency
            
-
            [22:22] <jrand0m> (course grained synchronization minimizes CPU and memory usage, while fine grained synchronization uses more CPU and memory in exchange for higher concurrency)
            
-
            [22:22] * TrueSeeker has quit IRC (Leaving)
            
-
            [22:22] * mihi will post ping stats in #flood in a few secs
            
-
            [22:22] * ion has quit IRC (Ping timeout)
            
-
            [22:23] <lucky> bah.
            
-
            [22:23] <jrand0m> but yeah, the plan is to have the testnet wrap up once it passes the 3 day test.  my current estimate is the 14th, but we'll see.
            
-
            [22:23] <lucky> miserably day.
            
-
            [22:23] <lucky> stupid capitalist pigs
            
-
            [22:23] <lucky> taking all my money..
            
-
            [22:24] <baffled> looks like there a are new goodies in cvs, how long before test4?
            
-
            [22:24] <jrand0m> not today, hopefully tomorrow
            
-
            [22:24] * jrand0m is going to bed after the meeting :)
            
-
            [22:25] <baffled> cool.
            
-
            [22:26] <madman2003> bye everyone
            
-
            [22:26] <jrand0m> later madman2003
            
-
            [22:26] <madman2003> don't forget the other points of the meeting :)
            
-
            [22:26] <jrand0m> ok, so thats testnet.  anything else on that, or shall we move to 2) updated roadmap?
            
-
            [22:26] <jrand0m> hehe
            
-
            [22:26] <baffled> Are there other stressers we need on the test net?
            
-
            [22:26] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))
            
-
            [22:26] <duck> what date is it?
            
-
            [22:27] <jrand0m> Feb 3
            
-
            [22:27] <baffled> 3rd here.
            
-
            [22:27] <mihi> 2004-02-03
            
-
            [22:27] * leenookx has joined #i2p
            
-
            [22:27] <duck> ah, thanks
            
-
            [22:27] <jrand0m> baffled> actually, has anyone tried out i2psnark on testnet?
            
-
            [22:27] <wiht> baffled: What do you mean by stressers?
            
-
            [22:28] <mihi> wiht: i guess people stressing the testnet
            
-
            [22:28] <baffled> Well, the other day you asked aum and I to siess and desist on nntp I was kinda thinking about setting up a 128kbps ogg stream.
            
-
            [22:28] * mihi 'd like a public echo service set up by anyone - would allow good latency checks
            
-
            [22:28] <baffled> so those two items I guess.
            
-
            [22:28] <jrand0m> we've had a good crew hitting the squid
            
-
            [22:28] <jrand0m> oh, nntp would rule, as would an ogg stream!
            
-
            [22:29] * jrand0m doesn't recall asking y'all to stop (except maybe temporarily during an update?)
            
-
            [22:29] <jrand0m> agreed mihi
            
-
            [22:29] * jrand0m checks what port 'echo' is
            
-
            [22:29] <jrand0m> 7
            
-
            [22:29] <mihi> afaik 9
            
-
            [22:29] <mihi> oops ;)
            
-
            [22:29] <baffled> You may been frazelled about something else at the time.
            
-
            [22:30] <wiht> Port 7.
            
-
            [22:30] <duck> 4
            
-
            [22:30] * ion has joined #i2p
            
-
            [22:30] <jrand0m> prolly baffled ;)
            
-
            [22:30] <duck> echo            4/ddp                           # AppleTalk Echo Protocol
            
-
            [22:30] <jrand0m> echo            7/tcp
            
-
            [22:30] <jrand0m> echo            7/udp
            
-
            [22:30] <jrand0m> echo            4/ddp                           # AppleTalk Echo Protocol
            
-
            [22:30] <wiht> Port 7 for TCP and UDP.
            
-
            [22:30] <mihi> duck: we want [0-9]*/tcp
            
-
            [22:30] * duck ducks
            
-
            [22:31] * Synonymous has joined #i2p
            
-
            [22:31] <jrand0m> so, anyone want to wrap up human's test app (the echo server and client)?
            
-
            [22:32] <jrand0m> (though running twisted does seem a bit much for that ;)
            
-
            [22:32] <duck> the non-twisted one would work
            
-
            [22:33] <duck> .
            
-
            [22:33] * jrand0m didn't realize his i2p code could work w/out twisted
            
-
            [22:33] <jrand0m> but anyway, anyone wnat to volunteer to run point on getting an echo service up?
            
-
            [22:33] * duck sits on his hands
            
-
            [22:33] <wiht> Reachable through I2P, or reachable through regular Internet?
            
-
            [22:34] <jrand0m> through i2p
            
-
            [22:34] <baffled> I can look into it with some specific specs.
            
-
            [22:34] <mihi> duck: do ducks have hands? i thougt wings ;)
            
-
            [22:34] <jrand0m> spec: receive a line of text and echo it back :)
            
-
            [22:34] <baffled> oh, okay no prob.
            
-
            [22:34] <lucky> bah... i have to start filing taxes next year!
            
-
            [22:34] <mihi> jrand0m: s/line/byte chunk/
            
-
            [22:34] <lucky> Stupid, damn government...
            
-
            [22:35] <jrand0m> mihi> line is so much easier to parse ;)
            
-
            [22:35] <duck> lucky: hush
            
-
            [22:35] <jrand0m> baffled++
            
-
            [22:35] <jrand0m> ok, moving on to 2) updated roadmap
            
-
            [22:35] * jrand0m directs people's attention to http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap
            
-
            [22:36] <mihi> jrand0m: why? while (len=in.read(b) != -1) {o.write(b,0,len);}
            
-
            [22:36] <jrand0m> (which, of course, y'all have already read)
            
-
            [22:36] * MrEcho has joined #i2p
            
-
            [22:36] <jrand0m> mihi> single byte messages vs nagle, etc
            
-
            [22:37] <jrand0m> but anyway, whatever baffled implements to do echoing to support testing is Good 
            
-
            [22:37] <jrand0m> (or you and he can work out what works best for you)
            
-
            [22:37] * wiht has quit IRC (Ping timeout)
            
-
            [22:37] <baffled> If you have requirements write them down and let me know later mihi and I'll try.
            
-
            [22:38] * ion has quit IRC (Ping timeout)
            
-
            [22:38] <mihi_backup> baffled: not really. if needed adding a newline after a timestamp is no problem at all.
            
-
            [22:38] * jar_ has quit IRC (Ping timeout)
            
-
            [22:38] <duck> (netsplit after 4:20)
            
-
            [22:38] <jrand0m> heh
            
-
            [22:39] <jrand0m> not good :/
            
-
            [22:39] <jrand0m> well, iterative and incremental.
            
-
            [22:39] <mihi> 22:38:09.430 ERROR [WrC1->Pz83  ] .i2p.i2ptunnel.I2PTunnelRunner: Error sending
            
-
            [22:39] <mihi> message to peer.  Killing tunnel runner
            
-
            [22:39] <jrand0m> are all 9/10 routers up atm?
            
-
            [22:39] <jrand0m> (or did one go down?)
            
-
            [22:40] <jrand0m> i only see 8
            
-
            [22:40] <jrand0m> 22:41:02.758 ERROR [TCP Read [9]] er.transport.tcp.TCPConnection: Error reading from stream to [RouterIdentity:
            
-
            [22:40] <jrand0m>         Hash: 4Sb3aJoFusrhpHgYA2xCZCkn0P5jBo822qu9C0wsE1w=
            
-
            [22:40] * duck did just update
            
-
            [22:40] <duck> where goes the i2cp admin stuff fit in the roadmap?
            
-
            [22:41] <duck> afaik that isnt implemented, but 0.2.5 talks about finalizing the spec
            
-
            [22:41] <jrand0m> current plan is to make I2CP the plain client protocol, leaving admin functionality seperate
            
-
            [22:41] <jrand0m> (e.g. through the :7655 admin web port)
            
-
            [22:41] <duck> ok
            
-
            [22:42] <jrand0m> (and rip out all that other crap)
            
-
            [22:42] * jar_ has joined #i2p
            
-
            [22:42] * ion has joined #i2p
            
-
            [22:42] <jrand0m> ((shrinkingCodebase)++)
            
-
            [22:43] <jrand0m> does anyone have any thoughts on the two Big Issues?
            
-
            [22:43] <jrand0m> = aborting the current PHTTP transport (until 2.0)
            
-
            [22:43] <jrand0m> = keeping support for a restricted route topology at 2.0
            
-
            [22:43] <baffled> Well gang, gotta boogie so I'll have to read the logs later.
            
-
            [22:43] <jrand0m> cool, glad you could make it, l8r
            
-
            [22:43] * baffled has quit IRC (Leaving)
            
-
            [22:44] <duck> secure i2cp would lower the direct need for restricted route topology a bit
            
-
            [22:44] <duck> so thats fine
            
-
            [22:45] <jrand0m> agreed, though the 'secured' in this sense won't be ideal (all i2cp payloads will of course be encrypted, but sniffers can detect that $client is sending a $n byte message to $destination)
            
-
            [22:46] <jrand0m> the only difference from the current i2cp is a little update to the authentication protocol / structure
            
-
            [22:46] <jrand0m> ((well, the $client can't detect $n, since messages are padded randomly.  nm)
            
-
            [22:46] <jrand0m> er, $sniffer, not $client
            
-
            [22:47] * wiht has joined #i2p
            
-
            [22:47] <jrand0m> (of course that doesn't defeat a global passive adversary)
            
-
            [22:48] <jrand0m> anyone have any other concerns / suggestions / ideas / comments?
            
-
            [22:48] <jrand0m> (on the roadmap)
            
-
            [22:49] <duck> no
            
-
            [22:49] <jrand0m> nor do i
            
-
            [22:49] * jrand0m hops on to 3) updated application list
            
-
            [22:49] <jrand0m> [insert "mihi rules" rant here]
            
-
            [22:50] <duck> help jrand0m to say no!
            
-
            [22:50] <jrand0m> mihi> any thoughts on the muffin thing?  http://wiki.invisiblenet.net/iip-wiki?I2PApplications
            
-
            [22:50] <jrand0m> heh
            
-
            [22:51] <mihi> jrand0m: you know what i think about that...
            
-
            [22:51] <jrand0m> (i'm not specifically asking you to integrate it, i'm just seeing what your thoughts are as to whether it would be good)
            
-
            [22:52] <mihi> httpclient has to get out of i2ptunnel, since i2ptunnel is for stream forwarding and httpclient does content forwarding
            
-
            [22:52] <mihi> hacking that into i2ptunnel would be just more hackish.
            
-
            [22:52] <jrand0m> word, so the app down below [Scalable web proxies]
            
-
            [22:52] <jrand0m> that makes sense
            
-
            [22:53] <jrand0m> (apps that do One Thing and One Thing Well)++
            
-
            [22:53] <mihi> jrand0m: you misunderstood me...
            
-
            [22:53] <jrand0m> whaddimiss?
            
-
            [22:54] <mihi> i don't have anything against an app that reads a http request, parses it, sends it over i2p, reads the answer, parses it, sends it back (maybe with filtering) - just not do it as httptunnel does.
            
-
            [22:54] <mihi> httptunnel forwards everything except the first few lines.
            
-
            [22:54] <jrand0m> ah you're right
            
-
            [22:55] * jrand0m doesn't quite have head screwed on correctly
            
-
            [22:55] <mihi> it would be hard to build effective filtering into it (if it should filter html and not text or sth like that)
            
-
            [22:55] <jrand0m> right - perhaps just have MUFFIN as a standalone 
            
-
            [22:55] <jrand0m> (filtering whatever comes out of the httpclient)
            
-
            [22:55] <mihi> so i'd say, an extra app for that. but that would require streaming lib... (or sth like that)
            
-
            [22:56] * duck likes how you can do proxies xmlrpc/soap with httpclient though
            
-
            [22:56] <wiht> jrand0m: I did not see an entry for "muffin" on the list of applications.
            
-
            [22:56] <jrand0m> wiht> http://muffin.doit.org/
            
-
            [22:56] <mihi> muffin is a http content filter
            
-
            [22:57] <mihi> if we have a content filter, we could drop that shitty "proxy" thingy.
            
-
            [22:57] <jrand0m> duck> hopefully the muffin filter would be set to pass through xmlrpc/soap, only filtering things like VBScript / etc
            
-
            [22:57] <wiht> I see.
            
-
            [22:57] <jrand0m> hm, mihi?
            
-
            [22:57] <duck> ah wait, xmlrpc/soap would be content type xml
            
-
            [22:57] <jrand0m> mihi> wouldn't it still need to do the name translation, at the least?
            
-
            [22:58] <mihi> sure, but not as a proxy. http://localhost:12345/duck.i2p/ would work much better.
            
-
            [22:58] <Synonymous> muffin is gpl, u have to be careful in a public domain project to use gpl code, its still copyrighted ;)
            
-
            [22:58] <mihi> since you can link to that from the regular web
            
-
            [22:58] <jrand0m> hrm mihi.
            
-
            [22:58] <mihi> Synonymous: i2ptunnel is gpl anyway
            
-
            [22:58] <jrand0m> Synonymous> I2PTunnel is GPL
            
-
            [22:58] <Synonymous> ya
            
-
            [22:59] * jrand0m is well aware of the fact that some people consider copyrights valid, and tries to accomodate them.
            
-
            [22:59] <Synonymous> make sure to put that up where it is visible (if you use muffin) it already says that iptunnel is gpl
            
-
            [22:59] <jrand0m> of course, if we use muffin it'd get attributed and marked as gpl.
            
-
            [22:59] <Synonymous> ya thats what i said, becareful about it
            
-
            [23:00] <jrand0m> (we're not going to get into the copyright discussion here)
            
-
            [23:00] <jrand0m> ok, any other thoughts on the apps listed?
            
-
            [23:00] <Synonymous> then don't, and my comment was not intended to start one
            
-
            [23:00] * duck laughts at http://muffin.doit.org/demo/evil/
            
-
            [23:01] <jrand0m> what do y'all think will be necessary app functionality for 1.0?
            
-
            [23:01] <jrand0m> heh duck
            
-
            [23:01] <jrand0m> (or are we already there, and 1.0 app functionality == things proxied through i2ptunnel :)
            
-
            [23:02] <Synonymous> ppl would want functional chat, and maybe a freenet like ap for 1.0 if thats what you are asking, maybe a set of tools so ppl can easily set up their own services on it
            
-
            [23:02] <mihi> an IM and a naming service are still missing
            
-
            [23:02] <jrand0m> mihi> irc over i2p?
            
-
            [23:02] <wiht> Yes, naming service should be in place by 1.0 version of I2P.
            
-
            [23:03] <duck> eep
            
-
            [23:03] <mihi> jrand0m: irc over i2p would be okay as well, but a naming service ;)
            
-
            [23:03] <jrand0m> wiht> do you have any thoughts on whether a naming service will be implemented and ready to go live by April?
            
-
            [23:03] * jrand0m really doesn't think a naming service is necessary. useful, yes
            
-
            [23:04] <jrand0m> (all we *need* is a way to easily update a hosts.txt file)
            
-
            [23:04] <kaji> or a distributed vpn layer
            
-
            [23:04] <jrand0m> heh
            
-
            [23:04] <mihi> jrand0m: for me even that (if automated) is a naming service
            
-
            [23:04] <wiht> jrand0m: Probably by the middle of April.
            
-
            [23:05] <jrand0m> kaji> a distributed vpn layer is a solid month of 1-2 devs ;)
            
-
            [23:05] <wiht> I want to make it scalable for accomodating many more entries than we have in hosts.txt now.
            
-
            [23:05] <jrand0m> 1.0-->3.0 wont have millions of entries
            
-
            [23:05] <wiht> MrEcho: Do you have any thoughts on this?
            
-
            [23:05] <jrand0m> thousands, yeah
            
-
            [23:06] <jrand0m> Synonymous> freenet like app would be cool, but then we need to recruit someone to implement :)
            
-
            [23:07] <jrand0m> Synonymous> tools to set up services - definitely.  hopefully i2pmanager or i2pmole will do
            
-
            [23:07] <Synonymous> that might be hard, esp since freenet doesnt work hehe
            
-
            [23:07] <wiht> Speaking of which, what is the progress of I2PManager?
            
-
            [23:07] <jrand0m> aparently its coming along, the console / cli mode is making progress (aum now uses it to manage his services via init scripts)
            
-
            [23:08] <jrand0m> i've used the gui, and aum's logged a few bugs on the tunnelmanager that are still outstanding
            
-
            [23:08] <jrand0m> (due to large #s of tunnels being created, not due to a small #)
            
-
            [23:08] <wiht> I think I2PManager should be an application for 1.0.
            
-
            [23:09] <jrand0m> i hope so too
            
-
            [23:09] <jrand0m> (especially since that would mean we can throw out the kludged installer, since i2pmanager has that built in)
            
-
            [23:09] <jrand0m> so, people with python experience should get in touch with aum to see how they can help :)
            
-
            [23:09] <human> re
            
-
            [23:09] <jrand0m> wb human
            
-
            [23:10] * human read about the muffin proxy
            
-
            [23:10] <human> i know about another privacy-oriented personal proxy called privoxy
            
-
            [23:11] <jrand0m> yeah, privoxy was another one i had been looking at.  good potential as well
            
-
            [23:11] <jrand0m> (reason i leaned towards muffin was the ease of integration, since its java)
            
-
            [23:12] * jrand0m won't be the one who implements / integrates it, so my view is only a suggestion
            
-
            [23:12] <@Nightblade> i think a group chat (or irc) would be a good program because if you can get chat to work reliably then you know i2p's latency and stability are good
            
-
            [23:13] <jrand0m> agreed
            
-
            [23:13] <Synonymous> how would trent work on such a system though, is it possible to do it with a system of public and private keys (like frost)
            
-
            [23:13] <Synonymous> the channel would be the 'board' ?
            
-
            [23:13] <jrand0m> Synonymous> duck has actually done some neat stuff
            
-
            [23:13] <Synonymous> kool
            
-
            [23:14] <duck> which is: users login with a secret password to the ircd, the ircd publishes the sha1 of the password
            
-
            [23:14] <jrand0m> Synonymous> in his modified ircd, you can provide a password that has its hash shown in the ident 
            
-
            [23:14] <Synonymous> it would also be like waste i guess, even though I didnt usei t
            
-
            [23:14] <jrand0m> duck> though if anyone else creates their own ircd, they can spoof that :/
            
-
            [23:14] <duck> so others can check the sha1 against a local list, without requiring a centralized database
            
-
            [23:15] <duck> sure
            
-
            [23:15] <jrand0m> but people could just remember what ircd someone usually connects from, i suppose
            
-
            [23:15] <jrand0m> would it be possible to have a nickserv?
            
-
            [23:15] * jrand0m doesn't know much about how irc nets work
            
-
            [23:16] <duck> yes, but I didnt want that
            
-
            [23:16] <duck> because Trent was made as a temporary hack
            
-
            [23:16] <jrand0m> right, it'd be Good if we could do without
            
-
            [23:16] <jrand0m> hehe
            
-
            [23:16] <jrand0m> until iip 2.0, right?  ;)
            
-
            [23:16] <duck> now it is the longest running joke in the world
            
-
            [23:17] <duck> .
            
-
            [23:18] <jrand0m> ok, so if we go 1.0 with: irc, eepsites (and a way to set up your own), squid, and cvs, thats reasonable?
            
-
            [23:18] <@Nightblade> yeah
            
-
            [23:18] <jrand0m> (obviously it'd be fantastic if we could include i2psnark, naming, I2PIM, and the other apps)
            
-
            [23:19] <duck> with irc you mean native i2pirc?
            
-
            [23:19] <duck> or if not, why not nntp etc too
            
-
            [23:19] <jrand0m> oh, right
            
-
            [23:19] <jrand0m> of course
            
-
            [23:20] * jrand0m !thwaps self.
            
-
            [23:20] <duck> not too much ofcourse
            
-
            [23:20] * duck thinks that the pgp keyserver is silly
            
-
            [23:20] <jrand0m> i just meant that its easy to overwhelm people with options
            
-
            [23:20] <duck> ah, sure
            
-
            [23:20] <duck> as in officially bundeled stuff
            
-
            [23:20] <jrand0m> "why should I use I2P" "well you can [.............]"
            
-
            [23:20] <jrand0m> right
            
-
            [23:20] * duck agrees
            
-
            [23:21] <jrand0m> with i2ptunnel, we can support all that we've seen (and more :)
            
-
            [23:21] <jrand0m> ok, in that case, I don't think we need to worry too much about the i2papps
            
-
            [23:21] <mihi> btw: we should deprecate the -nogui option of I2PTunnel...
            
-
            [23:22] <jrand0m> to default to -nogui?
            
-
            [23:22] <jrand0m> (or you trying to get us all to use awt?  ;)
            
-
            [23:22] <mihi> no. not to use -nogui at all. -cli and -nocli are more "transparent"
            
-
            [23:22] <Synonymous> you should also package all these options in 1 distro if you can
            
-
            [23:22] <jrand0m> ah ok mihi
            
-
            [23:22] <Synonymous> unlike freenet, which mentions no otehr utilities and its up to you to go find them out
            
-
            [23:22] <jrand0m> Synonymous> definitely
            
-
            [23:22] <jrand0m> Synonymous> have you used i2pmgr yet?
            
-
            [23:23] <mihi> -nogui acts differently whether you use -e "run configfile" or use "configfile"
            
-
            [23:23] <Synonymous> no, i couldnt get it working :)
            
-
            [23:23] <jrand0m> (its still pre-alpha, but functional)
            
-
            [23:23] <jrand0m> ah ok
            
-
            [23:23] <Synonymous> from before but it didnt try the gui
            
-
            [23:23] <Synonymous> i might try now that it has one
            
-
            [23:23] <Synonymous> :)
            
-
            [23:23] <jrand0m> word, its been makin progress
            
-
            [23:23] * duck suppresses a yawn
            
-
            [23:24] <jrand0m> yeah yeah yeah duck, ok ;)
            
-
            [23:24] <jrand0m> i think thats it for apps - unless someone else has something?
            
-
            [23:24] <jrand0m> moving on to 4) Volunteers needed
            
-
            [23:25] <jrand0m> we're making good progress, and the pace is fine and imho sustainable
            
-
            [23:25] <jrand0m> but we've all been talking about some really neat things that we'd like added on
            
-
            [23:25] <jrand0m> if there were another N hours in the day, yadda yadda yadda
            
-
            [23:26] <duck> what do you mean with 'development bandwidth'?
            
-
            [23:26] <jrand0m> more hours of developer activity
            
-
            [23:26] <duck> aye
            
-
            [23:27] <jrand0m> (e.g. 2 developers == 16/20 hours/day)
            
-
            [23:27] <jrand0m> my gut feeling is of the 'if you build it, they will come' variety
            
-
            [23:28] <jrand0m> (but i've also worked at companies that thought they had a kickass product, made it more kickass, released it, and didn't see much market activity)
            
-
            [23:28] * duck doesnt think that hiring cheap indians will work
            
-
            [23:28] <jrand0m> heh
            
-
            [23:29] <duck> product marketing != developer marketing
            
-
            [23:29] <jrand0m> right, i agree
            
-
            [23:29] <jrand0m> i just meant as an analogy
            
-
            [23:30] <jrand0m> we'll see how things progress.  i just wanted to throw that stuff out there
            
-
            [23:30] <@Nightblade> it is a complex program which makes it harder to find people who can figure it out
            
-
            [23:31] <jrand0m> agreed Nightblade
            
-
            [23:31] * greasyaxelsex__ has joined #I2P
            
-
            [23:31] <jrand0m> Nightblade> thats what 1.0 release criteria #3 on the roadmap is for: " Javadoc and code walkthrough / guidebook updated"
            
-
            [23:32] * dm has joined #i2p
            
-
            [23:32] * wiht has quit IRC (EOF From client)
            
-
            [23:32] <jrand0m> we currently have a generally up to date wiki providing an overview of the java impl
            
-
            [23:32] <mihi> hi dm
            
-
            [23:32] <jrand0m> but i will definintely need help with the documentation
            
-
            [23:32] <dm> hello mihi.
            
-
            [23:33] <jrand0m> (since what makes sense to me != what makes sense to people learning the code)
            
-
            [23:33] * dm accuses jrand0m of using terms he's invented when explaining things.
            
-
            [23:34] <jrand0m> occationally ;)
            
-
            [23:34] <Synonymous> i will help wtih the webpage if u want
            
-
            [23:34] <jrand0m> (though the only thing i knowingly have coined wrt i2p is 'militant grade anonymity' ;)
            
-
            [23:34] <Synonymous> i already have a template
            
-
            [23:34] <dm> How far are we from a bugless 0.2.x? I get my broadband in less than a week's time.
            
-
            [23:34] * wiht has joined #i2p
            
-
            [23:34] <Synonymous> the website needs major owkr
            
-
            [23:34] <Synonymous> im working on my own anonymous p2p website, but you can borrow mine :)
            
-
            [23:35] <jrand0m> hehe
            
-
            [23:35] <Synonymous> its modeled after freenet's
            
-
            [23:35] <Synonymous> but better
            
-
            [23:35] <Synonymous> :P
            
-
            [23:35] <jrand0m> actually, yeah, perhaps we can start a thread on the i2p list describing goals of the website and seeing how it fits together?
            
-
            [23:35] <dm> Synonymous: are you building a p2p app, or just the website?
            
-
            [23:35] <Synonymous> just the website
            
-
            [23:35] <jrand0m> (and if that traffic grows, we'll move to something like i2p-www@)
            
-
            [23:36] <duck> ROFL at anonymous p2p website boilerplates
            
-
            [23:36] <jrand0m> dm> roadmap updated at http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap with 0.2.4 slated for February 14
            
-
            [23:36] <Synonymous> explaing anonymous p2p, the different topologies of networks, the philosophy of it, cypherpunkdom, digital imprimature, links to projects, a mailing list for ppl to discuss it
            
-
            [23:36] <mihi> dm> bugless sw does not exist
            
-
            [23:36] <jrand0m> duck> gotta keep the anonymity set large ;)
            
-
            [23:36] <Synonymous> also links to the other website that does that
            
-
            [23:37] <dm> mihi: does too!
            
-
            [23:37] <jrand0m> mihi> i worked on one project a few years ago that actually shipped with 0 bugs.  no p1 or even p5s
            
-
            [23:37] <dm> func addints(int a, int b) { return a + b; }
            
-
            [23:37] <mihi> jrand0m: they just did not find them...
            
-
            [23:37] <mihi> dm: which language?
            
-
            [23:37] <jrand0m> mihi> then its not a bug ;)
            
-
            [23:37] * greasyaxelsex__ has left #I2P (greasyaxelsex__)
            
-
            [23:37] <dm> pseudo-language
            
-
            [23:38] <mihi> and how does this pseudo-language react on an overflow?
            
-
            [23:38] <wiht> dm: In a project with thousands of lines of code, having no bugs is much less likely.
            
-
            [23:38] <duck> .
            
-
            [23:38] <Synonymous> so April is the deadline for something for public release?  Why not try to recruit some devls, or would it take to long for you to explain to them how it works etc.
            
-
            [23:39] <dm> input is never over max_value /2
            
-
            [23:39] <jrand0m> (we're currently ~20KLOC, using the "grep \; | wc -l" algorithm)
            
-
            [23:39] <jrand0m> Synonymous> I don't think we want to just go around posting on lists "hey, we're doing a kickass thing, come code on it" (thats essentially a 1.0 announcement)
            
-
            [23:40] <dm> that's a lotta lines.
            
-
            [23:40] <dm> Java bloat!
            
-
            [23:40] <jrand0m> but if there are people who are interested in helping out, i'll most definitely go out of my way to find out how i can get them involved
            
-
            [23:40] * jrand0m kicks dm
            
-
            [23:40] <jrand0m> java bloat is when the jvm uses ram.  you're suggesting OO bloat
            
-
            [23:40] <dm> What a project leader jrand0m is.
            
-
            [23:40] <Synonymous> well, how will u know if ppl are interested if there is no knowledge of it, thats a contradiction
            
-
            [23:41] <Synonymous> and by 'recruit' i mean email them, not pubically anounce on say, zeropaid, about i2p
            
-
            [23:41] <Synonymous> like someone did ;)
            
-
            [23:41] <jrand0m> Synonymous> what are your thoughts on the explanation of that issue from the email?
            
-
            [23:41] <dm> Right OO bloat.
            
-
            [23:41] <jrand0m> yeah, I was pissed when someone told me about that zp article
            
-
            [23:41] <Synonymous> ya your the one that did the interview
            
-
            [23:41] <jrand0m> (you can read the august iip-dev messages)
            
-
            [23:41] <Synonymous> they just quoted you?
            
-
            [23:41] <jrand0m> "interview"?  more like some random person on iip asking me questions
            
-
            [23:42] <dm> mihi: are you working on the streaming lib?
            
-
            [23:42] <Synonymous> ah :)
            
-
            [23:42] <mihi> dm:no
            
-
            [23:42] <mihi> Standard@laptop /cygdrive/c/eigenes/notback/cvsprojects/i2p/i2p/code
            
-
            [23:42] <mihi> $ grep \; `find . -name "*.java"` | wc -l
            
-
            [23:42] <mihi>   30593
            
-
            [23:42] <jrand0m> ah.
            
-
            [23:42] <Synonymous> well, make get a list of project leaders for anonymous p2p and say "here is a project you might be interested in looking at, if you have any ideas on code or projects that might help it please let me know"
            
-
            [23:42] <mihi> 30kLOC ;)
            
-
            [23:42] <jrand0m> grep -v \^import
            
-
            [23:43] <jrand0m> Synonymous> stealing project leads == bad form ;)
            
-
            [23:43] <jrand0m> (there are many good projects, and while I obviously think i2p is important, others are too)
            
-
            [23:44] <Synonymous> not stealing, and i dont think the 'leader' can be stolen, he would just desolve the project
            
-
            [23:44] * jrand0m cant believe we're at 30kloc
            
-
            [23:44] <jrand0m> heh
            
-
            [23:46] <jrand0m> ok, moving on to 5) ???
            
-
            [23:46] <duck> 2 eepsite proposals, for those who dont know what to do: 1) meshmx FE tunnel (with stunnel) 2) pastebin.de site
            
-
            [23:46] <jrand0m> anyone have anything else to discuss / bring up?
            
-
            [23:46] <jrand0m> oh word duck
            
-
            [23:46] <jrand0m> whats pastebin.de?
            
-
            [23:46] <jrand0m> (similar?)
            
-
            [23:47] <duck> site where you can paste code/logs/stuff publically
            
-
            [23:47] <duck> for irc debugging
            
-
            [23:47] <duck> http://pastebin.de/
            
-
            [23:47] <jrand0m> interesting
            
-
            [23:47] * @Nightblade just prefers flooding channels with code
            
-
            [23:48] <jrand0m> wow that is one hell of an innovative idea
            
-
            [23:48] <jrand0m> insanely simple.
            
-
            [23:48] <jrand0m> focused.
            
-
            [23:48] <jrand0m> practical.
            
-
            [23:48] <dm> Only python though?
            
-
            [23:48] <jrand0m> oh reall?
            
-
            [23:48] <jrand0m> :/
            
-
            [23:48] <duck> I think this one has python highlighting
            
-
            [23:48] * jrand0m takes back 'practical' ;)
            
-
            [23:48] <duck> but I have also seen php ones etc
            
-
            [23:48] <duck> and you might have a general approach
            
-
            [23:48] <dm> I think I've seen one which accepts any language.
            
-
            [23:49] <dm> Good idea, mind you.
            
-
            [23:49] <duck> anyway, just something simple
            
-
            [23:49] <duck> you dont need highlighting at all
            
-
            [23:49] <duck> online linenrs would be useful
            
-
            [23:49] * dm looks at python code.
            
-
            [23:49] <dm> What's so special about this again?
            
-
            [23:50] <jrand0m> its got a y
            
-
            [23:50] * Nightblade sets mode: +o jrand0m
            
-
            [23:50] <@jrand0m> w00t
            
-
            [23:50] * Trent@anon.iip sets mode: +o mihi
            
-
            [23:50] <duck> there is nothing special about it,
            
-
            [23:51] <dm> A lot of people really like it, I think.
            
-
            [23:51] <duck> oh, you mean about python
            
-
            [23:51] <dm> yes, sorry.
            
-
            [23:52] * duck moves that to 6) offtopic
            
-
            [23:52] <duck> :)
            
-
            [23:52] <@jrand0m> heh
            
-
            [23:52] <@jrand0m> [beuler, beuler]
            
-
            [23:52] <dm> Sorry, didn't realize you guys were having a meeting.
            
-
            [23:52] <@jrand0m> every tuesday 9p gmt :)
            
-
            [23:53] <duck> ok, php stuff: http://pastebin.com/pastebin.php?showsource=php
            
-
            [23:53] <@jrand0m> anyone have anything else they want to bring up wrt i2p, etc?
            
-
            [23:54] <@mihi> i2p rocks!
            
-
            [23:54] <@jrand0m> (if only it were more reliable..)
            
-
            [23:55] <@mihi> it is more reliable than freenet for me ;)
            
-
            [23:55] <@jrand0m> heh :)
            
-
            [23:55] <@jrand0m> if i just hadn't fucked with your i2ptunnel to set the retry count to 0 we'd be fine ;)
            
-
            [23:56] <@jrand0m> (corrupt a lil data here and there, but that never hurt no one...er......)
            
-
            [23:56] <@jrand0m> ok
            
-
            [23:56] <dm> don't baf
            
-
            [23:56] * @jrand0m isn't going to try to drag it out 4 more minutes to reach 2 hours
            
-
            [23:57] <dm> do not baf
            
-
            [23:57] * @jrand0m denies dm and *baf*'s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting77.html b/www.i2p2/pages/meeting77.html
deleted file mode 100644
index 0197a94e..00000000
--- a/www.i2p2/pages/meeting77.html
+++ /dev/null
@@ -1,502 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 77{% endblock %}
-{% block content %}
            Tuesday, Feb 10, 2004 22:00:00 CET
            
-
            
-
            [22:00] <jrand0m> <incoming>
            
-
            [22:00] <jrand0m> 0) hi
            
-
            [22:00] <jrand0m> 1) testnet status
            
-
            [22:00] <jrand0m> 2) naming in i2p
            
-
            [22:00] <jrand0m> 3) minwww and i2cp
            
-
            [22:00] <jrand0m> 4) i2p.net website
            
-
            [22:00] <jrand0m> 5) ???
            
-
            [22:00] <dm> I was thinking the other day, that we could make a .NET interface to I2P. Anyway.. 
            
-
            [22:00] <FireRabbit> well there will be one
            
-
            [22:00] <madman-away> hello
            
-
            [22:00] <jrand0m> -1) .net interface would be cool
            
-
            [22:00] <jrand0m> 0) hi
            
-
            [22:00] * madman-away is now known as madman2003
            
-
            [22:00] <jrand0m> hey y'all
            
-
            [22:00] <wilde> hi
            
-
            [22:00] <FireRabbit> <-- will write a .net interface
            
-
            [22:00] <FireRabbit> anyway hi
            
-
            [22:00] <jrand0m> r0x0r.
            
-
            [22:00] <dm> awesome
            
-
            [22:01] <jrand0m> welcome to the 70somethingth meeting
            
-
            [22:01] <FireRabbit> <-- needs that URL with the client protocol
            
-
            [22:01] * ion has joined #i2p
            
-
            [22:01] <jrand0m> i2p.net/ has links to the wiki, you'll probably want to use the tunnelManager
            
-
            [22:01] <FireRabbit> ok
            
-
            [22:01] <jrand0m> (people should review http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html for this weeks status update)
            
-
            [22:01] <FireRabbit> and that works good in the latest release?
            
-
            [22:02] <jrand0m> yup, aum uses it (and i just fixed a bug he was running into a few hours ago)
            
-
            [22:02] <jrand0m> (specs @ http://wiki.invisiblenet.net/iip-wiki?I2PTunnelManager)
            
-
            [22:02] <jrand0m> ok, movin' on
            
-
            [22:02] <jrand0m> 1) testnet status
            
-
            [22:02] <FireRabbit> okc ool yes,
            
-
            [22:03] <jrand0m> i hate sounding like a broken record here, but... testnet is making progress.  
            
-
            [22:04] <jrand0m> we're still not there, but we have multihour sessions without hiccup on the latest build
            
-
            [22:04] <jrand0m> some setups aren't giving that level of reliability, but some are.  so, we're working on making them all up to speed
            
-
            [22:04] <FireRabbit> excellent
            
-
            [22:04] <baffled> We're at least populating the net with animals
            
-
            [22:05] <jrand0m> hehe
            
-
            [22:05] <jrand0m> dog, cat, mouse, duck...
            
-
            [22:05] * wiht has joined #i2p
            
-
            [22:05] <FireRabbit> rabbit!
            
-
            [22:05] <baffled> maybe I should become a bafflo
            
-
            [22:05] <human> human!
            
-
            [22:05] <jrand0m> !!
            
-
            [22:05] <jrand0m> #animalfarm
            
-
            [22:06] <dm> dm
            
-
            [22:06] <jrand0m> but, yeah, thats basically what i've got to say about the testnet status (beyond whats in that status email)
            
-
            [22:06] <wilde> people will read the logs offline so stay on topic please
            
-
            [22:06] <jrand0m> heh sorry dad ;)
            
-
            [22:07] <jrand0m> i think we're still on track for the roadmap
            
-
            [22:07] <wiht> How many more testnet releases do you plan to distribute?
            
-
            [22:07] <jrand0m> (plus i've been getting some future things done while running tests, such as the >2 hop tunnels)
            
-
            [22:07] <jrand0m> wiht> as many as it takes
            
-
            [22:08] <jrand0m> we're quite close to being done with this round of the testnet though, in my opinion
            
-
            [22:08] <dm> isn't >2 hop tunnels just a setting?
            
-
            [22:08] <jrand0m> yes
            
-
            [22:08] <jrand0m> but in the past it wasn't well tested
            
-
            [22:08] <dm> cool
            
-
            [22:09] <jrand0m> while the testnet has been going on, i've had my own seperate testnet on my laptop doing other things
            
-
            [22:09] * human is open to suggestions to make the ircmonitor more useful
            
-
            [22:09] <jrand0m> <dreaming>an http listener to render .png on demand?</dreaming>
            
-
            [22:09] <jrand0m> (or just a /msg cat renderPNG)
            
-
            [22:10] <human> jrand0m: ok, it should be feasible
            
-
            [22:10] <baffled> I'd still like to see text summaries.
            
-
            [22:10] <jrand0m> human++
            
-
            [22:10] <baffled> on the ircmonitor.
            
-
            [22:10] <jrand0m> yes, (text summaries)++ too
            
-
            [22:10] <human> jrand0m: i was still thinking to make it use gnuplot to generate graphs (instead of gnu plotutils)
            
-
            [22:11] <jrand0m> potato, potato
            
-
            [22:11] <jrand0m> (ah, the glory of accents on irc)
            
-
            [22:11] <FireRabbit> lol
            
-
            [22:11] <human> jrand0m, baffled: could you give me an example of a text summary?
            
-
            [22:11] <baffled> If you leave it with me a bit.
            
-
            [22:11] * dm read that as "potato, potato"
            
-
            [22:12] <jrand0m> period: 4 hours avg latency: 5.3s missed messages: 95 missed message frequency: 1 every 49 seconds
            
-
            [22:12] <jrand0m> (perhaps max & min latency)
            
-
            [22:12] <human> jrand0m: oh, ok
            
-
            [22:12] <jrand0m> if thats possible / not too much trouble
            
-
            [22:13] <jrand0m> (at least thats what i think of when i hear text summary)
            
-
            [22:13] <wilde> max latency, min latency
            
-
            [22:13] <mihi> human: look @ the summary i give for the ping tester
            
-
            [22:13] <mihi> hmm, anyone running an echo server this week?
            
-
            [22:13] <jrand0m> not to my knowledge
            
-
            [22:14] <human> jrand0m: it should be feasible - i'll basically make the ircmonitor log more raw data, and then i'll create some utility scripts to generate graphs and/or text summaries
            
-
            [22:14] <jrand0m> kickass
            
-
            [22:14] <baffled> Sorry mihi, I've been meaning to set yours up but keep forgetting.
            
-
            [22:14] <jrand0m> i think this will be a good part of the overall functional testing that will grow with us
            
-
            [22:15] <jrand0m> ok, do we have anything else for the testnet discussion?
            
-
            [22:16] * jrand0m moves on to 2) naming in i2p
            
-
            [22:16] <wilde> what's the biggest issue with testnet right now?
            
-
            [22:16] <jrand0m> biggest issue in testnet is two fold -
            
-
            [22:16] <jrand0m> 1) finding and fixing the cause of router disconnect
            
-
            [22:17] <jrand0m> 2) determining the cause of the frequent inter-ircd disconnects
            
-
            [22:17] <mihi> 1b) coping w/ the fact that routers may disconnect sometimes
            
-
            [22:17] <jrand0m> right
            
-
            [22:17] <jrand0m> well, thats not really part of this testnet.
            
-
            [22:17] <jrand0m> 0.3.x is a series of updates to deal with unreliable routers
            
-
            [22:18] <jrand0m> thats really why i've been limiting the # of routers that run on the testnet - I know it acts poorly when routers aren't up most of the time
            
-
            [22:18] <wiht> So you are assuming reliable routers for now, right?
            
-
            [22:18] <jrand0m> in the 0.2.3.6 testnet, yes
            
-
            [22:18] <jrand0m> (it recovers from failure, but not quickly enough)
            
-
            [22:19] <jrand0m> (more graceful recovery will be with multiple leases per destination, increased peer profiling, replay prevention, and retries on alternate lease targets)
            
-
            [22:20] <jrand0m> ok, moving towards 2) naming in i2p
            
-
            [22:21] <jrand0m> wiht brings up the core of the issue - global names are really useful, and people like them
            
-
            [22:21] <jrand0m> (people who arent familiar with this discussion should review http://i2p.dnsalias.net/pipermail/i2p/2004-February/000135.html and the subsequent replies)
            
-
            [22:22] <wiht> People are used to them, perhaps more than to local names (such as your ICQ analogy).
            
-
            [22:22] <jrand0m> i'm not sure.
            
-
            [22:22] <jrand0m> lets say for instance that my name is John.
            
-
            [22:22] <jrand0m> John isn't global.
            
-
            [22:22] <jrand0m> not even John Q. Random is global.
            
-
            [22:22] <jrand0m> nor is John Q. Random born in 1942 in Argentina.
            
-
            [22:23] <human> well, it has been said that the naming system could have more than one flavor
            
-
            [22:23] <jrand0m> thats true 
            
-
            [22:23] <human> people could choose a trusted "registration authority" to pick unique names from
            
-
            [22:23] <jrand0m> absolutely.
            
-
            [22:24] <jrand0m> though there is the danger there
            
-
            [22:24] <wiht> The scheme I originally proposed allows for multiple certification authorities, as I recall.
            
-
            [22:24] <human> jrand0m: of course, it's the tradeoff between comfort and security
            
-
            [22:24] <FireRabbit> i think someone should write up a quick "centrlized" dns system for the time being then worry about security
            
-
            [22:24] <human> jrand0m: :-)
            
-
            [22:24] <FireRabbit> just to make testing easyer
            
-
            [22:25] <jrand0m> multiple CAs works more easily without the global naming
            
-
            [22:25] <wiht> jrand0m: Going back to your example, if you are the first to register jrandom.i2p, another John Random would have to register as jrandom2.i2p, for example.
            
-
            [22:25] <baffled> There isn't really any problem until a conflict occures right?
            
-
            [22:25] <jrand0m> FireRabbit> I have a strong feeling that what we start with will stay in place for 12+ months.
            
-
            [22:25] <jrand0m> correct baffled, in any of the plans
            
-
            [22:25] <wiht> baffled: That is the problem, yes.
            
-
            [22:25] <jrand0m> wiht> not if there are multiple CAs
            
-
            [22:25] <FireRabbit> suppose
            
-
            [22:25] <wilde> eepsites will be a mess if there is local naming, links will not work
            
-
            [22:25] <baffled> so you only need an authority in the case of conflict resolution.
            
-
            [22:26] <jrand0m> yes they will wilde
            
-
            [22:26] <jrand0m> names to be shared and used by others should be fully qualified - self certified - names
            
-
            [22:26] <wiht> jrand0m: Could you give an example of a self-certified name?
            
-
            [22:27] <jrand0m> from my email -   http://i2pref/[base64 of the NameReference]
            
-
            [22:27] <wilde> so when I link to your site, and there are three jrandoms out there...which one will be used?
            
-
            [22:28] * human thinks that a decentralized NS without global naming is Good(TM), because it makes people understand the risks of delegating hostname verification and certification
            
-
            [22:28] <jrand0m> you link with the fully qualified name - which includes the actual Destination *in it*.
            
-
            [22:28] <jrand0m> (the NameReference structure from my email)
            
-
            [22:28] <wilde> so it's like base64 linking
            
-
            [22:28] <jrand0m> right human - it gets rid of that attack point
            
-
            [22:28] <wiht> So people will have to type many characters again? That seems self-defeating.
            
-
            [22:28] * madman2003 has quit IRC (EOF From client)
            
-
            [22:29] <jrand0m> no one types base64 names
            
-
            [22:29] <jrand0m> (well, maybe mihi does)
            
-
            [22:29] <jrand0m> <a href="http://i2pref/[base64 of the NameReference]">jrandom's page</a>
            
-
            [22:29] <wiht> Oh. That makes sense.
            
-
            [22:30] * mihi does not *type* anything he can copy&paste
            
-
            [22:30] <jrand0m> :)
            
-
            [22:30] <wilde> ok but basically it's long URLS
            
-
            [22:30] <jrand0m> within eepsites, yes
            
-
            [22:30] * dm has quit IRC (Ping timeout)
            
-
            [22:30] <wilde> k that was the question
            
-
            [22:30] <jrand0m> there are several other scenarios worth looking at though
            
-
            [22:31] <jrand0m> such as when people want to browse or search for new sites
            
-
            [22:31] <jrand0m> those are situations where having servers that contain a lot of name references is useful
            
-
            [22:31] <baffled> Could I propose the idea of a history server rather than an authority.
            
-
            [22:31] <jrand0m> history server?
            
-
            [22:32] <jrand0m> ah, so whoever was first "gets it"?
            
-
            [22:32] <baffled> If someone adopts a new domain which is used the history server sends a note to that person outlining the original holder and how to contact them.
            
-
            [22:32] <human> maybe an archive to see how a domain name changed during time?
            
-
            [22:32] <baffled> The conflict can then be resolved by the two parties providing they are both available.
            
-
            [22:33] <wiht> baffled: What if the new domain's operator is sleazy and continues to hold that already-taken domain name?
            
-
            [22:33] <baffled> If one party is not available the the conflict goes o the available party in some amount of time.
            
-
            [22:33] <human> of course it implies to give some trust to the server operator
            
-
            [22:33] <wilde> that's just authority but in another way
            
-
            [22:33] <jrand0m> right
            
-
            [22:34] <baffled> Any arbitrator is either going to act as an authority.
            
-
            [22:34] <human> well, using non-global names will make people understand that everything built on top of them will ease their life, but possibly make it less secure
            
-
            [22:34] <jrand0m> right, right
            
-
            [22:34] <baffled> I don't expect it will become a major problem.
            
-
            [22:34] <jrand0m> (but why do we need an arbitrator?  can't there be two johns in the world?)
            
-
            [22:35] <jrand0m> if i2p is used for commerce or other such activities, I expect the names to be heavily attacked
            
-
            [22:35] <baffled> If I want jrandom.i2p and jr won't give it up I can always chose jrandom.i3p or put out a contract.
            
-
            [22:35] <wilde> I vote for the cryptic nameref solution´
            
-
            [22:35] <wiht> Again, that would be fine, as long as _new_ users would understand the implications and which John they want to contact.
            
-
            [22:35] <jrand0m> (since someone would be able to hijack and get money, etc)
            
-
            [22:36] <jrand0m> right - its likely we're always going to bundle some name references with the software
            
-
            [22:36] <jrand0m> (ala the current hosts.txt)
            
-
            [22:36] <wiht> One idea we should keep, though, is MrEcho's idea of attaching a timed lease to a reference. That way, domain names can expire.
            
-
            [22:37] <jrand0m> why would domain names want to expire again?
            
-
            [22:37] <baffled> They're tired of life?
            
-
            [22:37] <jrand0m> oh, to replace the Destination included?
            
-
            [22:37] <jrand0m> heh
            
-
            [22:38] <wiht> Some because the operators want their domain names for just a day or a month. Others, if domain ownership is transferred to a different destination.
            
-
            [22:38] <jrand0m> hmm, but without uniqueness, there really isnt such a thing as ownership
            
-
            [22:38] <jrand0m> its not scarce
            
-
            [22:38] <jrand0m> and if someone wants to change the dest they listen at, they sign a note with their dest saying "hey, I'm moving over here"
            
-
            [22:39] <wilde> so the nameref is protected by one key, the destination is another
            
-
            [22:39] <jrand0m> the nameref is signed by the destination's signing key
            
-
            [22:40] <wilde> you may want another key just for namerefs if possible
            
-
            [22:40] <jrand0m> hm, i understand and agree, but that'd mean Destination gets yet another 1024bit segment
            
-
            [22:40] <wilde> so even if a machine gets compromised you can keep the nameref key on a paper
            
-
            [22:41] * wiht has quit IRC (Ping timeout)
            
-
            [22:41] <jrand0m> (and Destination is used all over the place)
            
-
            [22:41] <jrand0m> hmm not sure I follow the compromised part?
            
-
            [22:42] <wilde> the destination privkey is on the machine all the time
            
-
            [22:42] <jrand0m> ah right right
            
-
            [22:42] <wilde> the nameref private key doesn't to be, they can be kept on paper in the wallet
            
-
            [22:43] <jrand0m> thats a good point.  perhaps the comment block could be used for that (containing a PGP signature surrounding the Destination's hash)?
            
-
            [22:43] <wilde> but that maybe overkill
            
-
            [22:43] <wilde> i just don't like keeping the most valuable keys on the machine if isn't necessary
            
-
            [22:44] <jrand0m> right - we need the Destination signing key and the destination decryption key, but nothing else, functionally.
            
-
            [22:44] <jrand0m> hmm
            
-
            [22:45] <jrand0m> perhaps the name reference could have a 1024bit public key on it as well
            
-
            [22:45] <jrand0m> and we'd use that to verify via DSA
            
-
            [22:45] <jrand0m> rather than the destination's public key
            
-
            [22:45] <jrand0m> yeah, that'd fly
            
-
            [22:45] <jrand0m> additional 32bytes, but only for nameReference, not for Destination
            
-
            [22:46] * jrand0m doesnt know why I thought that'd imply it goes in the Destination
            
-
            [22:46] <wilde> lots of keys :) but extra security and flexibility
            
-
            [22:46] <jrand0m> right
            
-
            [22:46] <jrand0m> (though, c'mon, we know everyone is going to keep their key in the same dir)
            
-
            [22:46] <jrand0m> ((but maybe commerce shops wont))
            
-
            [22:47] <wilde> you can hand over a "domain" but not the destination, or change to someone elses destination
            
-
            [22:47] <jrand0m> well, ok.  i wish MrEcho and wiht were here
            
-
            [22:47] <jrand0m> right
            
-
            [22:48] <jrand0m> well, this is all fine and good, and I think it'll fly
            
-
            [22:48] <jrand0m> but it needs to get coded :)
            
-
            [22:49] <jrand0m> so, well, perhaps we'll have additional discussions about it later, but until that time, hosts.txt it is
            
-
            [22:49] <wilde> hire some indians
            
-
            [22:50] * jrand0m /dcc gets a grant to hire a team of 80 to work on i2p
            
-
            [22:51] <wilde> :)
            
-
            [22:51] <jrand0m> ok, do we have anything else for naming, or for the time being are we covered?
            
-
            [22:51] <baffled> Skip on brother.
            
-
            [22:52] * wiht has joined #i2p
            
-
            [22:52] * jrand0m does a hop, skip, and a jump to 3) minwww and i2cp
            
-
            [22:52] <jrand0m> d'oh, wb wiht
            
-
            [22:52] <baffled> 1, 2, 5 uh 3 sitr.
            
-
            [22:52] <wiht> I had trouble getting back on IIP network. I will read logs later.
            
-
            [22:53] <jrand0m> cool wiht, and we can continue later on the list, etc
            
-
            [22:54] <jrand0m> ok the other day I finally wrote up why I think i2cp is worth looking into using directly, and sketched up a minimal web system for use in i2p (and for proxying outside web pages through i2p)
            
-
            [22:54] <jrand0m> (reference the wiki at http://wiki.invisiblenet.net/iip-wiki?MinWWW )
            
-
            [22:56] <jrand0m> for HTTP, the cost of establishing and tearing down TCP/IP connections is small, but over I2P, the difference is between 10 destination to destination messages vs 2
            
-
            [22:56] * sheer has joined #i2p
            
-
            [22:56] <duck> did the meeting already start?
            
-
            [22:57] <jrand0m> yeah, 56 mins ago
            
-
            [22:57] * jrand0m sends duck to the corner
            
-
            [22:57] <duck> so I am right on time
            
-
            [22:57] * wilde has quit IRC (Ping timeout)
            
-
            [22:57] <jrand0m> heh
            
-
            [22:57] <baffled> No doubt about it, he's gotta get a new clock.
            
-
            [22:58] <jrand0m> one part of minwww that I wasn't sure about was whether minwww proxies should automatically also be external gateways as well?
            
-
            [22:58] * wiht has quit IRC (Ping timeout)
            
-
            [22:59] <jrand0m> that'd increase the number of outproxies available, decreasing the load
            
-
            [22:59] <jrand0m> plus with a round robin algorithm tied to the 64/128KB limit, there isn't much likelihood people would use it for large file sharing
            
-
            [22:59] * wiht has joined #i2p
            
-
            [23:00] <jrand0m> or should we just have something like a small set list of outproxies (thats periodically updated)?
            
-
            [23:01] <jrand0m> (or is the idea not worth looking too much into?)
            
-
            [23:01] * wilde has joined #i2p
            
-
            [23:02] <jrand0m> (or i've timed out and no one can read anything i've said)
            
-
            [23:02] <wilde> jrand0m: can see
            
-
            [23:02] <jrand0m> 'k coo'
            
-
            [23:02] <baffled> I'll need to understand it better but for now I have another appointment in ten minutes so I'll bbl.
            
-
            [23:02] <jrand0m> word, l8r
            
-
            [23:03] <jrand0m> yeah, there's still the absolutely key functionality of i2ptunnel to handle 8bit clean streams
            
-
            [23:03] <jrand0m> thats necessary for e.g. irc over i2p and such
            
-
            [23:03] <mihi> jrand0m: don't forget ss[lh]
            
-
            [23:04] <jrand0m> but for message oriented protocols, such as http, smtp, bittorrent, etc, i2cp may be more appropriate
            
-
            [23:04] <jrand0m> right, absolutely
            
-
            [23:04] <jrand0m> (well, more like 'telnet', since ssh over i2p is a bit of an overkill)
            
-
            [23:04] <wilde> ssh -X
            
-
            [23:05] <jrand0m> true
            
-
            [23:05] <jrand0m> (plus certs, etc)
            
-
            [23:05] <wilde> there is never too much crypto
            
-
            [23:05] <jrand0m> but if we're pulling web pages through squid in 5-10s, using i2cp would drop that to .5-2s
            
-
            [23:06] <jrand0m> (without any subsequent tuning of the network, and would reduce overal network load)
            
-
            [23:06] <wilde> how many man hours does it take to make i2cp?
            
-
            [23:07] <jrand0m> imho, i2cp has a fairly simple API, bundled into the java i2p SDK
            
-
            [23:07] <jrand0m> mihi can more fairly say how much effort it is to use / learn it
            
-
            [23:08] * wiht has quit IRC (Ping timeout)
            
-
            [23:08] <mihi> it's a bit confusing sometimes (when you have to put a value to the constructor and when to a method after calling default constructor, but w/ i2ptunnel and atalk as examples it should be not too hard.
            
-
            [23:09] * ion has quit IRC (Ping timeout)
            
-
            [23:09] <jrand0m> we can obviously improve upon the sdk, i just based it off the JMS api
            
-
            [23:10] <jrand0m> (and i'd be more than willing to help out anyone who wanted to hack around with it to get familiar)
            
-
            [23:11] <jrand0m> ok, do we have anything else on the minwww/i2cp?
            
-
            [23:11] <jrand0m> if not, moving on to 4) i2p.net website
            
-
            [23:11] <jrand0m> (and there was much rejoicing)
            
-
            [23:11] <jrand0m> ok
            
-
            [23:12] <duck> about search functionality
            
-
            [23:12] <duck> wikipedia uses google for search functionality
            
-
            [23:12] <jrand0m> thats true. and we're already the #1 result for i2p :)
            
-
            [23:13] <duck> so a nifty thing might not be needed for searching.
            
-
            [23:13] <mihi> duck: atm yes ;)
            
-
            [23:13] <duck> I mean for internal searching
            
-
            [23:13] <mihi> #1 is www.crestron.com/company_info/i2p/ 
            
-
            [23:13] <jrand0m> ah yeah, i forgot to bribe the pigeons this week
            
-
            [23:14] <duck> LeaseSet site:wiki.invisiblenet.net
            
-
            [23:14] <jrand0m> nice
            
-
            [23:14] <jrand0m> yeah, absolutely.
            
-
            [23:14] <wilde> drupal has internal search, and you can filter on content types
            
-
            [23:15] <wilde> it's also VERY google friendly with the clean urls, no index.php?Zillions of arguments
            
-
            [23:15] <wilde> everything looks like directories
            
-
            [23:16] * ion has joined #i2p
            
-
            [23:16] <wilde> ok I've played around with different CMS:s so far and Drupal is my current favourite
            
-
            [23:16] <duck> I prefer Ian's home-baked solution
            
-
            [23:16] <duck> :)
            
-
            [23:16] <jrand0m> what does it use for a backend?  mysql/bdb/txt/?
            
-
            [23:16] <wilde> it's used by http://kerneltrap.org/ http://www.debianplanet.org/ http://www.linuxgazette.com/
            
-
            [23:16] <wilde> for example
            
-
            [23:17] <wilde> it can take heavy loads
            
-
            [23:17] <wilde> their designs sucks though
            
-
            [23:17] <wilde> but a nice CSS stylesheet fixes that
            
-
            [23:17] <wilde> here some other somewhat better looking ones:
            
-
            [23:17] <duck> The Drupal core platform, additional plug-in modules, and many theme templates are freely available for download under the GNU GPL. Drupal, written in PHP and using either MySQL, PostgreSQL or mSQL as the database backend, can run on many platforms, including Apache or Microsoft IIS web servers.
            
-
            [23:17] <wilde> http://www.sudden-thoughts.com/
            
-
            [23:17] <jrand0m> thats an important point - we need to make sure the underlying software can support the design (and the design can be workable on the underlying software)
            
-
            [23:18] <wilde> http://www.codemonkeyx.net/
            
-
            [23:18] <wilde> http://www.disguast.org/index.php
            
-
            [23:18] <wilde> http://trip.ee/
            
-
            [23:18] <wilde> http://www.blainepeterson.com/image
            
-
            [23:18] <wilde> .
            
-
            [23:19] * jrand0m gets the feeling wilde is a raving drupal fan :)
            
-
            [23:19] <wilde> I'm starting to become that yes, as I like the information management ideas behind it
            
-
            [23:19] <wilde> everything is a node
            
-
            [23:20] <wilde> great taxonomy system
            
-
            [23:20] <wilde> you can create vocabularies for Geographic location, content type, language, etc
            
-
            [23:20] <wilde> and create custom urls that filters on content those
            
-
            [23:21] <jrand0m> could it essentially include two blog sections on the homepage?  e.g. one small blog area containing titles of the most recent dev blogs, and the main large seperate blog area containing the most recent i2p announcements?
            
-
            [23:21] <wilde> and it's updated often and the changes are good
            
-
            [23:21] <duck> in other words we are stupid that we dont have drupal already
            
-
            [23:21] <wilde> we have duck
            
-
            [23:21] <wilde> drupal.i2p.net
            
-
            [23:21] <jrand0m> :)
            
-
            [23:21] <wilde> you're so in the 90:s duck
            
-
            [23:22] <duck> that is good
            
-
            [23:22] <wilde> the design sucks of course
            
-
            [23:22] <duck> cause that design is so in the 80:s
            
-
            [23:22] <jrand0m> lol
            
-
            [23:22] * wilde mud wrestles with duck
            
-
            [23:22] <jrand0m> right, there are 3 different things that need to get worked out - the tech, the IA, and the graphic design
            
-
            [23:23] <wilde> you could try the user interface
            
-
            [23:23] <wilde> login: test pw: test
            
-
            [23:23] <duck> warning: Bad arguments to implode() in /var/www/html/i2p/modules/project/issue.inc on line 360.
            
-
            [23:23] <duck> user error: You have an error in your SQL syntax near ') AND (p.state = 1 OR p.state = 2) ' at line 1
            
-
            [23:23] <duck> query: SELECT COUNT(*) FROM project_issues p LEFT JOIN node n USING (nid) WHERE n.status = 1 AND () AND (p.state = 1 OR p.state = 2)  in /var/www/html/i2p/includes/database.mysql.inc on line 90.
            
-
            [23:23] <jrand0m> search still doesn't work wilde, right?
            
-
            [23:24] <duck> user error: You have an error in your SQL syntax near ') AND (p.state = 1 OR p.state = 2) ORDER BY n.changed DESC LIMIT 0, 20' at line 1
            
-
            [23:24] <jrand0m> oh nice1 duck
            
-
            [23:24] <duck> query: SELECT n.nid FROM project_issues p LEFT JOIN node n USING (nid) WHERE n.status = 1 AND () AND (p.state = 1 OR p.state = 2) ORDER BY n.changed DESC LIMIT 0, 20 in /var/www/htm
            
-
            [23:24] <duck> sucky
            
-
            [23:24] <jrand0m>  AND () AND
            
-
            [23:24] <wilde> whoops, i had some problems with search i must admint
            
-
            [23:25] <duck> .
            
-
            [23:25] <wilde> there is some full text indexing cron script not yet configured
            
-
            [23:25] <wilde> 2 minutes and duck crashed my life work
            
-
            [23:25] <jrand0m> (!hi5 duck)
            
-
            [23:26] <jrand0m> but i do think its worth looking at
            
-
            [23:26] <wilde> what did you do duck?
            
-
            [23:26] <jrand0m> i don't know if we're at the point where we want to commit to some CMS yet
            
-
            [23:26] <wilde> no
            
-
            [23:26] <jrand0m> (s/some/some specific/)
            
-
            [23:27] <duck> jrand0m did already make an overview of the requires features didnt he
            
-
            [23:27] <jrand0m> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html
            
-
            [23:27] <duck> so now all parties should come with proposals and the price
            
-
            [23:28] <duck> ofcourse the winning solution will be paid in i2p stocks
            
-
            [23:28] <jrand0m> which, let me tell you, is quite valuable
            
-
            [23:28] <jrand0m> *cough*
            
-
            [23:29] <jrand0m> you'll get your own @i2p.net email
            
-
            [23:29] <jrand0m> and chicks will love you
            
-
            [23:29] <jrand0m> (or guys, whatever)
            
-
            [23:30] <wilde> we had some CMS options
            
-
            [23:30] <wilde> we should go for some CMS
            
-
            [23:30] <wilde> and wiki isn't really a long term solution
            
-
            [23:30] <jrand0m> yeah some listed in point 4 @ http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html
            
-
            [23:30] <jrand0m> agreed, for the website itself
            
-
            [23:31] <jrand0m> a wiki based section of the site might be good though, perhaps for the user guide / hackers guides
            
-
            [23:31] <jrand0m> (but not for everything)
            
-
            [23:32] <wilde> what about the hosting?
            
-
            [23:32] <jrand0m> there's always the 53 entries at http://dmoz.org/Computers/Software/Internet/Site_Management/Content_Management/Open_Source/
            
-
            [23:32] <wilde> it should survive a slashdot
            
-
            [23:32] <jrand0m> hosting?  
            
-
            [23:32] <jrand0m> ah, right.
            
-
            [23:33] <jrand0m> thats actually a really huge draw of plain HTML in and of itself
            
-
            [23:33] <jrand0m> (dirt easy to mirror)
            
-
            [23:33] <wilde> and on
            
-
            [23:33] <wilde> http://www.oscom.org/
            
-
            [23:33] <jrand0m> i2p.net is at a colo that is used by several large sites
            
-
            [23:34] <jrand0m> ah right
            
-
            [23:34] * jrand0m would love if people would keep at it and find the Right solution
            
-
            [23:35] <wilde> http://www.opencms.org/ is interesting
            
-
            [23:35] <wilde> but's maybe too corporate
            
-
            [23:35] <wilde> with workflows, projects, etc
            
-
            [23:35] <wilde> I really liked, used it for one project
            
-
            [23:36] <jrand0m> interesting
            
-
            [23:36] <wilde> but its java ;)
            
-
            [23:36] <jrand0m> hmm, and xml
            
-
            [23:36] <wilde> jsp templates etc
            
-
            [23:36] <wilde> tomcat
            
-
            [23:36] <jrand0m> (or jetty)
            
-
            [23:36] <jrand0m> ((or resin))
            
-
            [23:37] <duck> (((lisp)))
            
-
            [23:37] <wilde> I would never use if for this project, it's really too heavy
            
-
            [23:37] <jrand0m> wilde> would you be willing to look over the main CMSes and map out pros and cons?
            
-
            [23:38] <wilde> i have :), and chose Drupal ;)
            
-
            [23:38] * jrand0m should have known
            
-
            [23:38] <wilde> I've tried about ten of the major ones
            
-
            [23:38] <wilde> for some earlier projects
            
-
            [23:38] <wilde> different CMS works for different projects
            
-
            [23:39] <duck> so say drupal is used
            
-
            [23:39] <wilde> Zope and friends are nice too
            
-
            [23:39] <duck> is the structure clear?
            
-
            [23:39] <duck> is the next step doing the gui?
            
-
            [23:40] <wilde> it's really just a CSS template that's needed for the gui, some changes to the xtemplate to prettify things
            
-
            [23:41] <wilde> www.csszengarden.com could be an inspiration
            
-
            [23:41] <jrand0m> wilde>  could it essentially include two blog sections on the homepage?  e.g. one small blog area containing titles of the most recent dev blogs, and the main large seperate blog area containing the most recent i2p announcements?
            
-
            [23:41] <jrand0m> basically I want to avoid dev blog entries pushing news & announcements off the main stage
            
-
            [23:42] <wilde> jrand0m: don't know, gonna check, blogs doesn't have to go front page, i configured it that way
            
-
            [23:42] <jrand0m> ah cool
            
-
            [23:42] <wilde> we can change to just stories go front page
            
-
            [23:42] <wilde> everything that is a node could be frontpage, polls, stories, book pages, articles etc,
            
-
            [23:43] <jrand0m> would it be possible to have stories at the top, with latest N blog entries below?
            
-
            [23:43] * jrand0m stops micromanaging
            
-
            [23:43] <wilde> blogs are linked to the bottom left right now,
            
-
            [23:44] * godmode0 has joined #i2p
            
-
            [23:44] <wilde> there are nice galleries as plugin, good for screenshots
            
-
            [23:44] <jrand0m> word
            
-
            [23:44] <wilde> the filestore plugin would be nice too
            
-
            [23:45] <wilde> and more cvs, developer plugins too
            
-
            [23:45] <wilde> and mailinglist
            
-
            [23:45] <jrand0m> I'm no CMS expert, and it sounds like you've done your homework and are enthusiastic about it
            
-
            [23:45] <jrand0m> w0ah nice
            
-
            [23:45] <wilde> jrand0m: i need people pulling the brake for me sometimes :)
            
-
            [23:46] <wilde> but the design really must be fixed, who are the design gurus here?
            
-
            [23:46] * wilde can't stand poor design, wikis and current drupal kills him
            
-
            [23:46] * jrand0m points at DrWoo and frontier
            
-
            [23:46] <wilde> anyone here now?
            
-
            [23:47] <duck> no, I left
            
-
            [23:47] * jrand0m stares at the lurkers
            
-
            [23:47] <wilde> so what should the site communicate?
            
-
            [23:47] <duck> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html
            
-
            [23:47] <wilde> this is a bit broader, we have marketing and donations to think of
            
-
            [23:48] <jrand0m> (what duck said)
            
-
            [23:48] <wilde> yeah i've read that, but we are more people here :)
            
-
            [23:48] <jrand0m> :)
            
-
            [23:48] <duck> but the puny humans dont matter!
            
-
            [23:48] * wilde attaches to the borg collective
            
-
            [23:49] <jrand0m> obviously one of the things I'd like the web site to communicate is "hey, this is a kickass project, you devs should join us and work for the revolution"
            
-
            [23:49] <duck> ok; I am falling asleep
            
-
            [23:49] <duck> enjoy
            
-
            [23:49] <jrand0m> heh cool duck, g'night
            
-
            [23:49] <duck> wilde: cool work on the CMS stuff
            
-
            [23:49] * wilde remembers the thing about 80:s design, 5 months of work!
            
-
            [23:50] <jrand0m> well, good thing we have 2 months then ;)
            
-
            [23:50] <wilde> night duck
            
-
            [23:50] <duck> oh yes, the design should BEG for peer reviews and useful comment
            
-
            [23:50] * ion has quit IRC (Ping timeout)
            
-
            [23:50] <jrand0m> agreed
            
-
            [23:50] <wilde> about the toopie
            
-
            [23:51] <jrand0m> i like 'im, he's humorous, simple, and topical
            
-
            [23:51] <wilde> doesn't toopie look a bit ... hmm... stupid 
            
-
            [23:51] <jrand0m> (and he can serve as an icon with nearly any purpose)
            
-
            [23:51] * ion has joined #i2p
            
-
            [23:51] <wilde> he squints
            
-
            [23:52] <jrand0m> heh i think we can wrestle up a top-left-logo-quality toopie
            
-
            [23:52] <jrand0m> there've been a lot of revs going around for different purposes
            
-
            [23:53] <wilde> i like him, but he must meet a personality consultant
            
-
            [23:53] * jrand0m suggests bouncing some ideas off DrWoo, both for the design and toopie stuff
            
-
            [23:54] <wilde> agreed
            
-
            [23:54] <wilde> ok maybe we should leave it there
            
-
            [23:54] <jrand0m> there's no rush, lots to digest and churn through
            
-
            [23:54] <wilde> but please it you find this new kickass CMS, scream out
            
-
            [23:54] <duck> can we have this as background: http://www.artchive.com/artchive/B/bruegel/death.jpg
            
-
            [23:55] <jrand0m> but I agree with duck, nice work setting up a drupal to work off
            
-
            [23:55] <jrand0m> that is so going straight to my desktop
            
-
            [23:55] <jrand0m> wow I wonder what text over that would look like
            
-
            [23:55] <wilde> cool picture
            
-
            [23:55] <jrand0m> actually, on that note, 5) ???
            
-
            [23:56] <jrand0m> anyone have anything else to add?
            
-
            [23:56] * jrand0m prods the peanut gallery
            
-
            [23:56] <wilde> it's been very quiet in here today
            
-
            [23:56] <wilde> everyone comes here to listen to messiah Jrandom
            
-
            [23:57] <duck> 2h is a bit longish
            
-
            [23:57] <mihi> *ggg*
            
-
            [23:57] * jrand0m is just here for the beer
            
-
            [23:57] <duck> maybe you could try 2 weekly meetings of 30 min each
            
-
            [23:57] <wilde> nah
            
-
            [23:57] <duck> and then the layoffs at friday afternoon
            
-
            [23:57] <wilde> that's too often
            
-
            [23:58] <jrand0m> i do think 2h meetings are very excessive
            
-
            [23:58] <jrand0m> (unless they're specifically topical.  e.g. a meeting discussing the web page design, or some router functionality, etc)
            
-
            [23:58] <jrand0m> (hey look, we're meta)
            
-
            [23:59] <jrand0m> perhaps I should shut up more and limit it to 1h?
            
-
            [23:59] <jrand0m> or perhaps the bulk of the 'meeting' should go to the mailing list, with #i2p for discussion?
            
-
            [23:59] * godmode0 has quit IRC (Ping timeout)
            
-
            [23:59] <wilde> the mailinglist could be used more for discussions
            
-
            Session Time: Wed Feb 11 00:00:00 2004
            
-
            [00:00] <duck> I think that the heavy email pre-logs are already good
            
-
            [00:01] <jrand0m> so maybe the weekly meetings turn more into "ok guys, whats up?  anyone have anything to discuss?"
            
-
            [00:01] <jrand0m> (but open ended meetings like that are a danger in and of themselves)
            
-
            [00:01] * godmode0 has joined #i2p
            
-
            [00:02] <jrand0m> ok, maybe we can move this meta to the list or to later
            
-
            [00:02] <jrand0m> we've already broken the 2h mark
            
-
            [00:02] <jrand0m> so...
            
-
            [00:02] * jrand0m winds up...
            
-
            [00:02] <fidd> :)
            
-
            [00:02] * jrand0m *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting78.html b/www.i2p2/pages/meeting78.html
deleted file mode 100644
index 92827c51..00000000
--- a/www.i2p2/pages/meeting78.html
+++ /dev/null
@@ -1,290 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 78{% endblock %}
-{% block content %}
            
-
            Considering we did not have a very official meeting do to Jrand0m not
            
-
            feeling very well, here are my logs of the meeting from slightly
            
-
            before it started to sometime after it ended.  I have edited out the
            
-
            kick offs and start screens from iip restarting at least twice during
            
-
            that period.  If someone else has better logs feel free to replace
            
-
            these. (baffled)
            
-
            
-
            <human> baffled: we're experimenting a psychic communication towards jrand0m, to ask him to be here for the meeting
            
-
            <human> baffled: just focus your mind on him, and help us
            
-
            > Don't we have to hold hands or something like that?
            
-
            <human> baffled: if it helps you focusing your mind... well, yes
            
-
            > Cool, gimme your hand I'm commensing to focus!
            
-
              
-
            •  human gives his hand to baffled 
              
-
            
-
            human has changed the topic on channel #i2p to I2P meeting: hold the hand of your neighbour, focus your mind on jrand0m, and ask him to come here
            
-
            thecrypto (~thecrypto@anon.iip) has joined channel #i2p
            
-
              
-
            •  baffled whipes the sacred potato-chip oil off his fingers and takes humans hand.
              
-
            
-
            <DrWoo?> human: doesn't he make up a pre meeting agenda, you can grab that and direct the meeting
            
-
            <human> DrWoo?: er... why me?
            
-
            Rain (Rain@anon.iip) has joined channel #i2p
            
-
            <human> DrWoo?: (i didn't see any meeting agenda, though)
            
-
            <DrWoo?> human: why not, you're sober
            
-
            <wilde> let's make an agenda ourselves
            
-
            <DrWoo?> yeah you guys know the general issues
            
-
            <wilde> there are many topics to discuss
            
-
              
-
            •  human will direct the meeting in exchange of the sacrifice of the first daughter of every participant
              
-
            
-
            <wilde> funding, strategy, marketing, website, recruiting more developers and powerusers, etc
            
-
            <human> wilde: i agree, we could informally talk about the recent history of I2P
            
-
            <DrWoo?> wilde: open a text window and quickly make a numbered agenda
            
-
              
-
            •  human agrees with wilde 
              
-
            
-
            > As the first item don't we need to add massive responsibilites to jrandom in absentia?
            
-
            Signoff: wilde (Ping timeout)
            
-
            Signoff: ion (Ping timeout)
            
-
              
-
            •  human agrees with baffled, too
              
-
            
-
            wilde (~anon@anon.iip) has joined channel #i2p
            
-
            <wilde> back
            
-
            > you're the first to say anything your in charge.
            
-
            <wilde> who? me?
            
-
            jar (jar@anon.iip) has joined channel #i2p
            
-
            > quit looking surprised.
            
-
            <DrWoo?> you guys are funny :)
            
-
            > hey jar.
            
-
            <jar> 'lo baffled :)
            
-
            <jar> 'lo i2p !
            
-
            ion (ion@anon.iip) has joined channel #i2p
            
-
              
-
            •  human started logging the meeting (or whatever it will be)
              
-
            
-
            > We elected wild to run the meeting because he was the first to say anything after meeting time.
            
-
            <wilde> ok
            
-
            jrand0m (jrand0m@anon.iip) has joined channel #i2p
            
-
            <wilde> 1. Hello
            
-
            <wilde> 2. Status I2P
            
-
            <wilde> 3. How to help I2P Project
            
-
            <wilde> 4. Recruiting more developers
            
-
            <wilde> 5. Raising money (donations, selling t-shirts)
            
-
            <wilde> 6. General discussion
            
-
            <human> jrand0m: has appeared!!!
            
-
            <wilde> hey jrand0m!
            
-
            > I'll take a t-shirt.
            
-
            <human> our experiment succeeded!!!
            
-
            <jrand0m> shit thought I missed it :)
            
-
              
-
            •  jrand0m leaves the floor to wilde ;)
              
-
            
-
            > You better look back through the log jrandom.
            
-
            <wilde> ok boss you could modify the agenda as you like
            
-
            <jrand0m> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000144.html
            
-
              
-
            •  jrand0m just posted
              
-
            
-
            > Are the t-shirts good?
            
-
            <jrand0m> they had better be
            
-
              
-
            •  jrand0m apologizes for being late, been avoiding looking at the monitor today (killer headache)
              
-
            
-
            > No apology necessary or expected.
            
-
            <wilde> np, we prepared an emergency plan
            
-
            <wilde> everyone taking a job at McDonalds? and hiring indian programmers for the money
            
-
            Signoff: ion (Ping timeout)
            
-
            <jrand0m> hah nice
            
-
            <jrand0m> perhaps we can jump into that agenda, or are we on 1, 2, 3, 6?
            
-
            <wilde> 0.
            
-
            <wilde> 1. Hello
            
-
            <wilde> Hello I2P
            
-
            <fidd> hi
            
-
            <jrand0m> hi
            
-
            <jar> hi
            
-
            <kaji> ah, i made it
            
-
            <wilde> last hellos? going once, going twice...
            
-
            <kaji> hi
            
-
            > Which agenda the one you posted or the oone wild posted?
            
-
            <jrand0m> perhaps I can help out with agenda 2) status
            
-
            <wilde> 2. Status I2P
            
-
            <jrand0m> the router, as is, is nonfunctional
            
-
            <wilde> so how are we post-testnet?
            
-
            > can we cote on that?
            
-
            <jrand0m> post testnet, yes, but I introduced two bugs in the process
            
-
            > vote.
            
-
            <jrand0m> vote on whether its nonfunctional?
            
-
            > Right.
            
-
              
-
            •  jrand0m wonders if we vote hard enough it'll be functional again
              
-
            
-
            <kaji> its dead for me
            
-
            > oh, nevermind.
            
-
            > well, we held hands and you appeared.
            
-
            <jrand0m> hey, worth a shot ;)
            
-
              
-
            •  jrand0m starts a bug-excorcism seance
              
-
            
-
            > does that make them bogobugs?
            
-
              
-
            •  DrWoo? sprinkles dried blood on the floor
              
-
            •  jrand0m senses that this chant will cause the bugs to dissapear in the next day or two, with an email going out to i2p@ once its ready
              
-
            
-
            > oh wooooow!
            
-
            <kaji> i switched to j2sdk1.4.2_03 to get ant to work on XP, i wonder how much of and effect it has on the router not working
            
-
            <wilde> so there's a short i2p vacation
            
-
            <jrand0m> none, I use that build on xp
            
-
            <jrand0m> the bug is programmer error, probably a trivial one too
            
-
            <jrand0m> (but quite fatal)
            
-
            <jrand0m> right wilde
            
-
            <jrand0m> but after that, I've been making a bunch of progress on the docs for 0.2.5 and 0.3
            
-
            <jrand0m> so I don't think they'll be a full two weeks out
            
-
            <jrand0m> but we'll cross that bridge when we come to it.
            
-
            <wilde> nice, any application improvments anyone?
            
-
            <jrand0m> one idea - on the testnet, we focused a lot on irc and echo, more than eepsites
            
-
              
-
            •  wilde notes in the black book who hasn't done todays homework, a cool I2P application
              
-
            
-
            > Do you think they suffered for that? I certainly do.
            
-
            <jrand0m> having lots of clients (aka destinations) on a single router increases the load, and we may want to think about trimming down our test scope, perhaps
            
-
            <jrand0m> there's also a discussion wrt perhaps revisiting the keysize of the crypto to reduce the load (for another day after we have more metrics, etc) 
            
-
            Signoff: Robert (Ping timeout)
            
-
            > What do you consider a lot of clients on one router?
            
-
            <jrand0m> I dont know, I would like once 0.2.4.x is out and usable that we can use both IRC and eepsites
            
-
            <jrand0m> that depends on the computer
            
-
            <wilde> so what's best for now? eepsites or irc?
            
-
              
-
            •  jrand0m wants both, and we will have both functional in the mid and long run
              
-
            
-
            <jrand0m> anyway, we can see as 0.2.4.x comes out.  perhaps both will be fine again.
            
-
            <wilde> yeah but what's most useful for debugging? continous connections or sporadic ones?
            
-
            <jrand0m> both ;)
            
-
            <wilde> lighweight irc, or eep graphics?
            
-
            <jrand0m> i2p needs to support long term streaming connections and short term bursty ones
            
-
            <kaji> what about heavy long downloads?
            
-
            <jrand0m> right, long term streaming connections
            
-
            <jrand0m> (though I do think filesharing over i2p would best be served with i2psnark via messages, ala udp)
            
-
            <wilde> the question really is: you suggested narrowing the test scope, was that to IRC or EEP?
            
-
            <wilde> (or something else)
            
-
            <jrand0m> two or three clients will be fine, I just know that running 4+ services may be a bit of an overload for the time being (depending on people's computer)
            
-
            lucky (~lucky@anon.iip) has joined channel #i2p
            
-
            <wilde> ok, that's probably wise
            
-
            <jrand0m> anyone have any dev status for client apps?
            
-
            <wilde> so the focus should be on services that can us some statistics, like the irc scripts
            
-
            <jrand0m> that is definitely key.
            
-
            Newsbyte (~fredisdea@anon.iip) has joined channel #i2p
            
-
            <jrand0m> woah
            
-
            <jrand0m> hi Newsbyte
            
-
            <Newsbyte> ah, jran
            
-
              
-
            •  wilde looks at the clock and at Newsbyte, late arrival, that will cost you an apple
              
-
            
-
            <Newsbyte> huh?
            
-
            <Newsbyte> I never come here
            
-
            <jrand0m> also, the echo server and client app is great at gathering stats, and doesn't have any irc-specific dependencies. 
            
-
            <wilde> nothing
            
-
            <Newsbyte> besides, what's an I2P meeting without nop? ;-)
            
-
            <DrWoo?> wilde: heh somehow I dont think hes here for the meeting :)
            
-
            <human> would an eepsite monitoring tool be useful?
            
-
            <Newsbyte> no nop, no meeting
            
-
              
-
            •  Newsbyte can summarise
              
-
            
-
            <wilde> jrand0m: is there something else you'd like to have statistics in the network?
            
-
            <jrand0m> human> certainly - perhaps some way to do periodic pings of eepsites, maybe keeping track of changes even?
            
-
            <human> jrand0m: keeping track of what changes?
            
-
            <jrand0m> I think with the irc scripts giving us long term disconnect / reliability stats, plus the echo app giving us latency, the only thing left is really throughput
            
-
            <jrand0m> content on the page changing 
            
-
            <Newsbyte> yes, and use more then one server
            
-
            <wilde> a kb/s meter, I2P Pirate Radio someone?
            
-
            <jrand0m> hmm?  right, when the net is up we usually have between 4-10 servers
            
-
            <human> jrand0m: it's doable but... how would you use the content change information?
            
-
            <kaji> i ran a shoutcast stream for a while
            
-
            <jrand0m> human> that particular aspect wouldn't help me, but would let users use the test (which would tell them whats changed, as well as get them to run the test more [generate more traffic])
            
-
            <jrand0m> nice kaji
            
-
            <jrand0m> yeah, aum's streams were up periodically as well
            
-
            <human> jrand0m: oh, ok, now i understand
            
-
            <mihi> jrand0m: a chargen service? ;)
            
-
            <madman2003> bye everyone, good luck with i2p
            
-
            <wilde> so throuhput is one stat that would be interesting/useful
            
-
            <jrand0m> later madman2003
            
-
            <wilde> cya madman2003
            
-
            Signoff: madman2003 (..12(. www...nnscript...de .12.::. .N.o.N.ame.S.cript 3...8 .12.::. www...XLhost...de. .12.).)
            
-
            > Well, I have another meeting at five as usual so I'll bbl.  Remember to put me down for a t-shirt.
            
-
            <jrand0m> yes mihi, that'd work (but streaming .ogg sounds cooler)
            
-
            baffled (~kirk@anon.iip) has joined channel #i2p
            
-
            mrflibble (mrflibble@anon.iip) has joined channel #i2p
            
-
            -Trent@anon.iip- The nickname baffled is not registered
            
-
            Ocelot (~Ocelot@anon.iip) has joined channel #i2p
            
-
            Rain (~Rain@anon.iip) has joined channel #i2p
            
-
            nickthief61599 (~chatzilla@anon.iip) has joined channel #i2p
            
-
            lucky (~lucky@anon.iip) has joined channel #i2p
            
-
            backup (~ypo@anon.iip) has joined channel #i2p
            
-
            Sonax (~Sonax@anon.iip) has joined channel #i2p
            
-
            jar (jar@anon.iip) has joined channel #i2p
            
-
            wilde (~anon@anon.iip) has joined channel #i2p
            
-
            Signoff: backup (Ping timeout)
            
-
            <wilde> hey
            
-
            <wilde> is the network unstable?
            
-
            <wilde> I just couldn't get back on
            
-
            Signoff: thecrypto (Leaving)
            
-
            <lucky> yea
            
-
            <lucky> its a bit... ugh.
            
-
            <lucky> recently.
            
-
            <wilde> what happened to the meeting?
            
-
            <lucky> probably got decimated
            
-
            <wilde> ok lucky what was the last thing you saw from the meeting? (msg me)
            
-
            <lucky> <wilde> cya madman2003
            
-
            <lucky> <-- madman2003 has quit (( www.nnscript.de :: NoNameScript? 3.8 :: www.XLhost.de ))
            
-
            <lucky> <jrand0m> yes mihi, that'd work (but streaming .ogg sounds cooler)
            
-
            Galaxy (yogi@anon.iip) has joined channel #i2p
            
-
            <wilde> ok that's where it ended for me too
            
-
            <fidd> me2
            
-
            Signoff: Sonax (EOF From client)
            
-
            Sonax (~Sonax@anon.iip) has joined channel #i2p
            
-
            <kaji> the meeting got nuked
            
-
            kaji has changed the topic on channel #i2p to nuked
            
-
            <kaji> ping?
            
-
            <jar> pong!
            
-
            <kaji> ok
            
-
            <kaji> ithough it crashed again
            
-
            <jar> yep :(
            
-
            Signoff: wilde ()
            
-
            <kaji> so... meeting?
            
-
            <jar> ending brutaly ...
            
-
            <jar> more signs of jrandom, it seems it's all for the moment
            
-
            <jar> next move on 0.2.4.2 in few days ....
            
-
            <jar> (one or two as said jr)
            
-
            mihi_backup (~mihi@anon.iip) has joined channel #i2p
            
-
            jar is now known as jar_
            
-
            sheer (sheer@anon.iip) has joined channel #i2p
            
-
            <kaji> wilde said something about funding, but last time i asked jran he said i2p wasnt in a position to need money atm
            
-
            Signoff: Ranma ()
            
-
            Robert (~chatzilla@anon.iip) has joined channel #i2p
            
-
            Sonax is now known as JaSiger?
            
-
            JaSiger? is now known as Sonax
            
-
            Signoff: Rain (I Quit)
            
-
            zathras (~zathras@anon.iip) has joined channel #i2p
            
-
            Ranma (ranma@anon.iip) has joined channel #i2p
            
-
            mihi (mihi@anon.iip) has joined channel #i2p
            
-
            <mihi> hmm, what happened to the meeting?
            
-
              
-
            •  mihi has an idea
              
-
            
-
            <mihi> ;)
            
-
            Mode change "+o mihi" on channel #i2p by Trent@anon.iip
            
-
            Mode change "-o duck" on channel #i2p by mihi
            
-
            <mihi> no one knowing anything about the meeting?
            
-
              
-
            •  mihi notices that no one fears ops any longer ;)
              
-
            
-
            Signoff: zathras (Ping timeout)
            
-
            mihi_backup has been kicked off channel #i2p by mihi (mihi)
            
-
            zathras (~zathras@anon.iip) has joined channel #i2p
            
-
            Signoff: Sonax (Client exiting)
            
-
            <lucky> mihi, we lall got kicked for the meoeting
            
-
            hacktic4ever (~hacktic4e@anon.iip) has joined channel #i2p
            
-
            Signoff: hacktic4ever ()
            
-
            <mihi> ok, nite
            
-
            <duck> hello
            
-
            Signoff: sheer (EOF From client)
            
-
            Signoff: mihi (let's have more luck next week...)
            
-
            <duck> did I miss anything?
            
-
            Signoff: jnk (Ping timeout)
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting79.html b/www.i2p2/pages/meeting79.html
deleted file mode 100644
index efa09add..00000000
--- a/www.i2p2/pages/meeting79.html
+++ /dev/null
@@ -1,187 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 79{% endblock %}
-{% block content %}
            Tuesday, Feb 24, 2004 22:00:00 CET
            
-
            
-
            [22:00] <jrand0m> 0) hi
            
-
            [22:00] <jrand0m> 1) 0.2.4.2/0.2.5
            
-
            [22:00] <jrand0m> 2) docs
            
-
            [22:00] <jrand0m> 3) ???
            
-
            [22:00] <jrand0m> 0) hi
            
-
            [22:00] <human> hi
            
-
            [22:00] * jrand0m waves to the newly-restarted iip-ircd :)
            
-
            [22:01] <jrand0m> (and, uh, to you :)
            
-
            [22:01] <jrand0m> weekly status notes (that we're running off) located at http://i2p.dnsalias.net/pipermail/i2p/2004-February/000148.html
            
-
            [22:01] <jrand0m> (and posted to the mailing list, obviously)
            
-
            [22:01] <jrand0m> 1) 0.2.4.2/0.2.5
            
-
            [22:02] <jrand0m> Dev has been making some good headway on the 0.2.5 release, which will allow and exploit both 2+ hop tunnels and clients with multiple inbound tunnels
            
-
            [22:03] <jrand0m> the key functionality that will provide will be increased reliability and functional anonymity
            
-
            [22:04] <jrand0m> the 1-hop tunnels we have now exposes you to statistical attack by an active opponent, but with 0.2.5 you'll be able to determine the length of your own hops (and increasing the default to 2) making the statistical attack much more complex
            
-
            [22:06] <jrand0m> i also found a pair of bugs in the client send process and the network db which could account for some of the latest instability
            
-
            [22:06] <jrand0m> (bugfixes underway)
            
-
            [22:07] <jrand0m> as an aside, I think the roadmap [http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap] is still an accurate reflection of the dev schedule
            
-
            [22:07] * mihi has joined #i2p
            
-
            [22:07] <jrand0m> heya mihi
            
-
            [22:07] * protocol has quit IRC (Ping timeout)
            
-
            [22:07] <jrand0m> ok, thats it for the router dev status, moving on to 2) docs
            
-
            [22:07] * human would like to say that he finds I2P unusable since 0.2.4 (it seems to behave *far* worse than the 0.2.3 age, at least on my PC)
            
-
            [22:07] <jrand0m> hm
            
-
            [22:08] <human> maybe we could talk about it after the meeting...
            
-
            [22:08] <jrand0m> in reliability terms, latency, CPU, bandwidth?
            
-
            [22:08] * protocol has joined #i2p
            
-
            [22:08] <mihi> hi jrand0m, hi all
            
-
            [22:08] <human> jrand0m: i can't reach any eepsite or I2P service (with few temporary exceptions)
            
-
            [22:08] * mihi seconds human
            
-
            [22:09] <jrand0m> most eepsites are down - duck, baffled, madman2003 are the most consistently up lately
            
-
            [22:09] <human> jrand0m: i can't reach them, nor irc.*.i2p
            
-
            [22:09] <jrand0m> squid I use constantly for all my web browsing - are you unable to use that?
            
-
            [22:09] <human> jrand0m: nope
            
-
            [22:09] <jrand0m> hm
            
-
            [22:10] <madman-away> well an uptime of about 8 hours daily for my i2p site
            
-
            [22:10] <human> jrand0m: we could talk about it after the meeting, i don't want to monopolize the discussion :-)
            
-
            [22:10] * madman-away is now known as madman2003
            
-
            [22:10] <mihi> it might be my provider's problem as well, http://babelfish.altavista.com/babelfish/urltrurl?tt=url&url=http%3A%2F%2Fwww.expressnet.de%2Fnews%2Fnews.php&lp=de_en :(
            
-
            [22:10] <Janonymous> me too
            
-
            [22:10] <human> jrand0m: just to point out that some problems seems to exist (that weren't shown before)
            
-
            [22:10] <Janonymous> mine should be up now
            
-
            [22:11] <madman2003> what destination?
            
-
            [22:11] <jrand0m> well, 'k, if things are going backwards in reliability we need to address that before moving on to 0.2.5
            
-
            [22:11] * mihi hates babelfish's english :(
            
-
            [22:11] <jrand0m> heh
            
-
            [22:12] <jrand0m> (well, it got the Thank you for your understanding. sentence correct at least...)
            
-
            [22:12] <human> jrand0m: it should be investigated... i thought about an ISP issue, too, but the problem seems to be constant since 0.2.4 (and doesn't seem to happen with other network services)
            
-
            [22:12] <jrand0m> 0.2.4.0 was shit, as was 0.2.4.1
            
-
            [22:12] * wilde has joined #i2p
            
-
            [22:13] <human> jrand0m: i know, and it worries me...
            
-
            [22:13] <wilde> hey i2p
            
-
            [22:13] <jrand0m> heya wilde
            
-
            [22:13] <madman2003> one thing i noticed is that tunnels tend to get unstable more often
            
-
            [22:13] <human> jrand0m: i didn't change too much with 0.2.4.2 (at least for me)
            
-
            [22:13] <human> jrand0m: s/ i / it /
            
-
            [22:14] <jrand0m> madman2003> thats easily due to routers going on and offline (which will be a big problem until 0.3)
            
-
            [22:14] <jrand0m> hmm ok
            
-
            [22:14] <wilde> jrand0m: does that mean we should avoid running transients for now?
            
-
            [22:15] * mihi has quit IRC (Ping timeout)
            
-
            [22:15] <jrand0m> hm, I think there are going to be significant fixes in 0.2.5, but we can hold off on moving from 0.2.5 to 0.3 until after the reliability issues are cleared.
            
-
            [22:16] <jrand0m> wilde> i don't like the term transients, it makes me think of another project that treats unreliable routers differently than reliable ones.  we treat all routers equally (and need to, for anonymity)
            
-
            [22:16] <jrand0m> but as long as routers generally stay up or generally down, they're fine
            
-
            [22:17] <jrand0m> (just not up 10 minutes, down 10 minutes, up 30, down 30, etc)
            
-
            [22:17] <madman2003> i do have one request: an option for the router(and tunnels) to be reastablished
            
-
            [22:17] <baffled> i2p is an equal router opertunity organization?
            
-
            [22:17] <jrand0m> heh baffled
            
-
            [22:18] <jrand0m> madman2003> router to be reestablished?  your router is shutting down still?
            
-
            [22:18] <madman2003> i mean reconnecting everything
            
-
            [22:18] <madman2003> sort of a warm restart of the router
            
-
            [22:18] <madman2003> without pissing of the other routers
            
-
            [22:18] <madman2003> (i have to restart router and tunnels a lot)
            
-
            [22:18] <jrand0m> you can safely restart your client apps (e.g. i2ptunnel eepproxy, etc) without touching the rotuer
            
-
            [22:19] <jrand0m> you should /never/ need to restart your router.
            
-
            [22:19] <jrand0m> (almost all config settings are updated dynamically)
            
-
            [22:19] * Trix has joined #i2p
            
-
            [22:19] <jrand0m> hi Trix
            
-
            [22:19] <Trix> hi
            
-
            [22:19] <madman2003> usually restarting the tunnels does the trick
            
-
            [22:21] <jrand0m> there's only one situation where that's technically necessary (old lease expirations in a client's leaseSet, which occurred on startup randomly), and thats been fixed in CVS, so you shouldn't need to do that.
            
-
            [22:22] <jrand0m> (in fact, restarting tunnels can cause temporary problems, depending on the type of tunnel)
            
-
            [22:22] <madman2003> sometimes i just don't know if i'm causing problems or if someone else is
            
-
            [22:22] <jrand0m> if your router console doesn't have any of the red warnings, its the network (or someone else)
            
-
            [22:22] * jnk has joined #i2p
            
-
            [22:23] <jrand0m> patience fixes more of the current i2p bugs than restarts do ;)
            
-
            [22:24] <jrand0m> but we'll have another series of bugfix releases after 0.2.5
            
-
            [22:24] <jrand0m> (like testnet, except without the restrictions on the userbase)
            
-
            [22:25] <jrand0m> (and, as always, whenever things break, logs are appreciated :)
            
-
            [22:25] <jrand0m> anyway, moving on to 2) docs
            
-
            [22:26] <jrand0m> as posted in http://i2p.net/pipermail/i2p/2004-February/000147.html there've been some new overview docs
            
-
            [22:27] <jrand0m> I'd appreciate some critiques to improve them, as they referred to pages are essentially going to turn into the main starting point for learning about I2P
            
-
            [22:28] <madman2003> i read them and i hope you were right about the possibilty to safely reduce the amount of crypto
            
-
            [22:29] <wilde> layers of crypto or # of bits?
            
-
            [22:29] <jrand0m> I'm not convinced that the crypto is the bottleneck, but its a possibility
            
-
            [22:30] <jrand0m> we couldnt safely reduce the layers, but we could use different levels of crypto at different layers, rather than reusing the same code for everything
            
-
            [22:30] <madman2003> the problem is finding your way
            
-
            [22:30] <jrand0m> hmm?
            
-
            [22:31] <madman2003> a static path is usually well found
            
-
            [22:31] <madman2003> a more dynamic one is more difficult to establish
            
-
            [22:32] <madman2003> (i'm talking about the inability to properly handle routers going offline)
            
-
            [22:32] <jrand0m> ah, thought you were talking about crypto
            
-
            [22:32] <jrand0m> its going to be fairly easy to handle unreliable routers, its just the 0.3 code
            
-
            [22:33] * jrand0m has ~30 pages of notes on different techniques, its all workable, just lots to do
            
-
            [22:33] * protocol has quit IRC
            
-
            [22:34] <madman2003> maybe an idea to have backup routes ready
            
-
            [22:34] <madman2003> tunnel redundancy
            
-
            [22:34] <jrand0m> right, thats 0.2.5 - multiple leases
            
-
            [22:35] <jrand0m> (lease == declaration that a destination can be reached through a specific tunnel)
            
-
            [22:35] <madman2003> i'll be awaiting that :)
            
-
            [22:36] <jrand0m> w3rd
            
-
            [22:37] <jrand0m> well, if anyone has any suggestions for improving the docs, feel free to hit the wiki, post to the list, or send me an email
            
-
            [22:38] <jrand0m> ok, moving on at a rapid pace to 3) ???
            
-
            [22:38] <jrand0m> anything people want to bring up and discuss?
            
-
            [22:39] <DrWoo> potatoes are fucking cheap yet potatoe chips are expensive, what's up with that?
            
-
            [22:39] <DrWoo> :)
            
-
            [22:39] <jrand0m> its a conspiracy!
            
-
            [22:40] * DrWoo thinks jrand0m has the answer for most anything :)
            
-
            [22:40] <jrand0m> of course, you can blame anything on conspiracies.
            
-
            [22:40] <jrand0m> ok
            
-
            [22:40] <wilde> Stego ?
            
-
            [22:40] * human accepts suggestions about how to expose I2CP-like message-oriented functionality to non-java apps
            
-
            [22:41] <wilde> how I2P will implement Stego so an ordinary portscan will reveal nothing 
            
-
            [22:41] <wilde> not even random bytes
            
-
            [22:41] * human may (does?) sound repetitive... he's thinking about VPNs over I2P with http://openvpn.sf.net/
            
-
            [22:41] <jrand0m> well, for one, PHTTP.
            
-
            [22:42] <jrand0m> openvpn does look very interesting - I hadn't realized tun/tap had windows ports
            
-
            [22:42] <jrand0m> a simple message oriented socket bridge for I2CP should be very easy
            
-
            [22:43] <wilde> Isn't freenet calling it Silent Bob, when the node shuts up it you don't give the secret knock (know the router ID)
            
-
            [22:43] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))
            
-
            [22:43] <baffled> okay as usual I have another appointment in 15m so I'll catch up later.
            
-
            [22:43] <jrand0m> right, if we wanted to integrate with a webserver/etc to silent bob, we could
            
-
            [22:43] <jrand0m> cool, later baffled
            
-
            [22:44] <jrand0m> (but silent bob doesnt prevent portscan detection, it just makes it look like another service)
            
-
            [22:44] <wilde> I rather not have random people or ISP:s portscan me and find ports open
            
-
            [22:44] <wilde> ok
            
-
            [22:44] <human> jrand0m: ok, i'll work on it when I2P will work again on my PC :-)
            
-
            [22:44] <jrand0m> UDP would work as well
            
-
            [22:44] <jrand0m> :) human
            
-
            [22:45] * kaji has joined #i2p
            
-
            [22:46] <jrand0m> I hadn't realized reliability had gone down that bad, we'll go through sufficient iterations after 0.2.5 to get it back for you human
            
-
            [22:46] <wilde> is there a way of hiding an open port from java program, without messing with the OS or firewall
            
-
            [22:46] <human> w00t!
            
-
            [22:47] <jrand0m> you mean to have a listening TCP socket that can't be portscanned?  no, not directly from Java.
            
-
            [22:47] <wilde> ok
            
-
            [22:48] <jrand0m> (i dont even know how to do that in other langs)
            
-
            [22:48] <jrand0m> udp would probably be the best way to go for that
            
-
            [22:48] * human invites people to try to telnet human.i2p (tunneled TCP echo server) and type something in
            
-
            [22:48] <wilde> that would be a little C program filtering and forwarding to another port maybe
            
-
            [22:49] * kaji_ has joined #i2p
            
-
            [22:49] <jrand0m> if it accepts TCP connections, its already too late, if I understand your concern correctly.
            
-
            [22:49] <Janonymous> how do you telnet?
            
-
            [22:49] <kaji_> finaly
            
-
            [22:50] <kaji_> that took forever, iip usability sucks dick atm
            
-
            [22:50] * kaji has quit IRC (Ping timeout)
            
-
            [22:51] <duck> if you are concerned about open ports, you could use rTCP / PHTTP / whatever couldnt you?
            
-
            [22:51] <Janonymous> damn...  hey, jr, are those new docs accessable from the main i2p page?
            
-
            [22:51] <human> Janonymous: java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 12221 human.i2p"
            
-
            [22:51] <jrand0m> no Janonymous, just from the links on that email
            
-
            [22:51] <human> Janonymous: then telnet localhost 12221
            
-
            [22:51] <jrand0m> duck> right
            
-
            [22:52] <Janonymous> k
            
-
            [22:52] <duck> (ofcourse whatever can be a silentbob/stealth/stego transport)
            
-
            [22:52] <jrand0m> human> Message send failed after 61226ms with 391 bytes
            
-
            [22:53] <human> jrand0m: and it means that...?
            
-
            [22:53] <jrand0m> that means I cant reach your echo
            
-
            [22:53] <duck> -nogui is depricated :)
            
-
            [22:53] <jrand0m> can you reach duck.i2p?
            
-
            [22:54] <wilde> scary, i googled for rtcp: http://dret.net/glossary/rtcp
            
-
            [22:54] <jrand0m> right, rtcp is taken :/
            
-
            [22:54] <human> jrand0m: i'm trying, but i can't reach duck.i2p since a looong time ago...
            
-
            [22:54] <jrand0m> wilde> http://wiki.invisiblenet.net/iip-wiki?RelayingTCP
            
-
            [22:54] <wilde> "Wilde's WWW Online Glossary"
            
-
            [22:55] <jrand0m> hehe oh yeah :)
            
-
            [22:55] <jrand0m> human> thats a definite Bad Thing, as its up almost always - could you bounce me your log-*.txt?
            
-
            [22:56] <human> Started on:  Tue Feb 24 10:21:22 GMT 2004
            
-
            [22:56] <human> Version: Router: 0.2.4.2 / SDK: 0.2.4.2
            
-
            [22:56] <human> Bandwidth used: 56096295 bytes sent, 34308394 bytes received (avg 1.44KBps sent 0.88KBps received)
            
-
            [22:56] <human> jrand0m: ok, logs coming on meshmx
            
-
            [22:56] <jrand0m> gracias
            
-
            [22:56] <jrand0m> ok, anyone have anything else to bring up?
            
-
            [22:58] * jrand0m winds up
            
-
            [22:58] * jrand0m *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting8.html b/www.i2p2/pages/meeting8.html
deleted file mode 100644
index d1c93332..00000000
--- a/www.i2p2/pages/meeting8.html
+++ /dev/null
@@ -1,149 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 8{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 8
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Tue Aug 13 23:58:45 2002
-
            23:58 [Users #iip-dev]
-
            23:58 [@logger] 
-
            23:58 -!- Irssi: #iip-dev: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
-
            23:58 -!- Irssi: Join to #iip-dev was synced in 1 secs
-
            23:58 -!- mode/#iip-dev [-o logger] by Trent
-
            23:58 -!- mode/#iip-dev [+nt] by Trent
-
            23:58 -!- Trent changed the topic of #iip-dev to: Info, agenda, log : http://mids.student.utwente.nl/~mids/iip/ | Tuesday 23:00 UTC - http://e-store.invisiblenet.net | topic: no meeting in progress
-
            --- Day changed Wed Aug 14 2002
-
            00:00 -!- mode/#iip-dev [+o mids] by Trent
-
            00:05 -!- mode/#iip-dev [+v logger] by mids
-
            00:31 -!- mode/#iip-dev [+o mids] by Trent
-
            00:52 <@mids> Info, agenda, log : http://mids.student.utwente.nl/~mids/iip/ | Tuesday 23:00 UTC - http://e-store.invisiblenet.net | topic: Welcome
-
            01:00 <@mids> Tue Aug 13 23:00:00 UTC 2002
-
            01:00 <@mids> Meeting nr 8!
-
            01:00 <@mids> everybody ready?
-
            01:00 < Neo> yes
-
            01:00 < nop> welcome
-
            01:00 <@mids> thanks
-
            01:01 <@mids> as a sidenote, I feel that my connection is unreliable.. I can die every second
-
            01:01 <@mids> logs are available on http://mids.student.utwente.nl/~mids/iip/
-
            01:01 <@mids> Agenda for today:
-
            01:01 <@mids> 1) Welcome
-
            01:01 <@mids> 2) RC2
-
            01:01 <@mids> 3) Mac OS 9
-
            01:01 <@mids> 4) Website preview
-
            01:01 <@mids> A) Questions?
-
            01:01 <@mids> if you have anything to ask or add.. do so
-
            01:02 <@mids> otherwise I suggest we go to item nr2
-
            01:02 <@mids> .
-
            01:02 <@mids> great
-
            01:02 <@mids> 2) RC2
-
            01:03 <@mids> it should be out months ago :)
-
            01:03 <@mids> but it isnt due to various reasons
-
            01:03 <@mids> the biggest one is the summer/vacation period
-
            01:03 <@mids> as far as I know we are waiting on the relay checker that has to be modified for RC2
-
            01:04 <@mids> last month UserX has squished some more bugs
-
            01:04 <@mids> but nothing serious
-
            01:04 <@mids> once codeshark is back in business.. there is hope
-
            01:05 <@mids> waiting for nop to add optional info
-
            01:05 <@mids> so just have patience
-
            01:05 <@mids> we are doing our best.. working with the resources available
-
            01:05 <@mids> .
-
            01:06 <@mids> according to nop there is an issue with the PRNG
-
            01:06 < nop> for the inner key
-
            01:06 <@mids> Pseudo Random Number Generator
-
            01:06 < nop> technology
-
            01:06 < nop> for rc2
-
            01:06 < nop> it has an initialization problem
-
            01:06 < nop> that is being worked on
-
            01:07 < nop> but it is slow
-
            01:07 < nop> and userx is moving at this time, so it makes it double slow
-
            01:07 < nop> .
-
            01:07 <@mids> .
-
            01:07 <@mids> so keep up the hope  and lets move to the next item
-
            01:07 <@mids> which is... 3) Mac OS 9
-
            01:07 < nop> ok
-
            01:07 < nop> crunch has given me info on that
-
            01:08 < nop> someone just donated another 300 dollars
-
            01:08 < nop> to the project
-
            01:08 < nop> which is awesome
-
            01:08 < nop> crunch and bob are working on the gui and bob is fixing up the socket stuff
-
            01:08 < nop> it's more of a time issue as they are working on another project
-
            01:08 <@mids> how much $ are collected for the port now?
-
            01:08 < nop> but
-
            01:09 < nop> physically 1100
-
            01:09 < nop> is all the money that has been collected
-
            01:09 < nop> we would like to get up to 3500 total
-
            01:09 < nop> if possible
-
            01:09 < nop> so anyone wanting to even donate a dollar
-
            01:09 < nop> would help
-
            01:09 <@mids> so... if you want to have the mac os 9 port for IIP done... contact nop
-
            01:09 < nop> to pay for the development time of Cap'n Crunch and his partner bob
-
            01:09 < Robert> Excellent news. Let Neo or I know if you want another request to be put in on the DC front page.
-
            01:09 < nop> plse
-
            01:10 < nop> another request would be great Robert
-
            01:10 <@mids> I suggest we start doing p
-
            01:10 < nop> we've delivered 700 to Crunch
-
            01:10 <@mids> ublic announces every hour on IIP
-
            01:10 < nop> and 300 will be delivered next week 
-
            01:10 <@mids> just like OPN used to do :)
-
            01:10  * Neo thinks we should put in a 30 minute NAG screen on the os9 app until we get over $3500 :)
-
            01:10 < nop> haha
-
            01:10 < nop> I believe it's a bad idea
-
            01:10 < nop> let's just request
-
            01:11 < nop> not nag
-
            01:11 <@mids> kay :/
-
            01:11 <@mids> .
-
            01:11  * Neo thinks maybe a "I use os9 and have not donated" message broadcast from os9 users also. :)
-
            01:12 < Neo> just kidding
-
            01:12 < nop> hehe
-
            01:12 < ellison> there are a few Mac software companies that put funny requests in pop-ups when you first load the program
-
            01:12 <@mids> maybe an article on macworld?
-
            01:12 < ellison> I've found that approach to the the most effective with me personally
-
            01:13 <@mids> .
-
            01:14 <@mids> lets move on.. cause we have some exciting news!
-
            01:14 < nop> .
-
            01:14 <@mids> which is...
-
            01:14 <@mids> the
-
            01:14 <@mids> Website!
-
            01:14 <@mids> 4) Website preview
-
            01:14 <@mids> specially for you a sneak preview
-
            01:14 <@mids> http://www.citystateinc.com/ellison/invisiblenet/index.html
-
            01:15 <@mids> dont forget to click through to the "Invisible IRC Project" in the upper right corner
-
            01:15 <@mids> ellison just released this preview, he is working on the templates now
-
            01:15 <@mids> after that, copy has to be made to fill the blanks
-
            01:16 <@mids> I think we can have the website live pretty soon
-
            01:16 <@mids> .
-
            01:16 < ellison> we're almost there
-
            01:17 <@mids> comments?
-
            01:17  * mids thinks that everybody is still gasping at the site
-
            01:17 < ellison> i think everyone has passed out from joy and hasn't made it back up on their chairs yet
-
            01:17 < nop> haha
-
            01:18 <@mids> next topic? or are we going too fast?
-
            01:19 <@mids> topic nr 5.. requested by Neo
-
            01:19 <@mids> the ! channels with channel mode +a
-
            01:20 <@mids> on this irc server there can 
-
            01:20 <@mids> err
-
            01:20 <@mids> you can create special ! channels
-
            01:20 <@mids> to create them, type /join !!channelname
-
            01:20 <@mids> then you get a channel like: !A4CEQchannelname
-
            01:21 <@mids> this strange prefix is there to prevent channel collisions after netsplits, some obscure test by the ircnet programmers
-
            01:21 <@mids> but, these channels have something special
-
            01:21 <@mids> you can set the +a mode
-
            01:21 <@mids> with /mode !A4CEQchannelname +a
-
            01:21 <@mids> then the channel becomes truely anonymous
-
            01:22 <@mids> everybody his/her nick becomes 'anonymous'
-
            01:22 <@mids> so you dont know who is talking
-
            01:22 <@mids> try it out.. join !anonymous for a demo
-
            01:23 <@mids> so remember.. to create ! channels: /join !!channel
-
            01:24 <@mids> to join an existing channel: /join !channel
-
            01:24 <@mids> then set +a mode (if you are operator) /mode !prefixchannelname +a
-
            01:24 <@mids> this mode cant be unset
-
            01:24 <@mids> .
-
            01:25 <@mids> that was my topic list for today
-
            01:25 <@mids> any questions?
-
            01:26 <@mids> nope?
-
            01:26 < Robert> No sir.
-
            01:27 <@mids> then I'll end my monologue :)
-
            --- Log closed Wed Aug 14 01:28:33 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting80.html b/www.i2p2/pages/meeting80.html
deleted file mode 100644
index 4422593f..00000000
--- a/www.i2p2/pages/meeting80.html
+++ /dev/null
@@ -1,358 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 80{% endblock %}
-{% block content %}
            Tuesday, Mar 2, 2004 13:00:00 PST
            
-
            
-
            13:07 < jrandom> 0) hi
            
-
            13:07 < jrandom> 1) Dev status
            
-
            13:07 < jrandom> 2) Cascades
            
-
            13:07 < duck> I'll stop
            
-
            13:07 < jrandom> 3) Roadmap
            
-
            13:07 < jrandom> 4) Website
            
-
            13:07 < jrandom> 5) ???
            
-
            13:07 < jrandom> 0) hi
            
-
            13:07  * jrandom waves to the first over-i2p i2p dev meeting :)
            
-
            13:07 < ughabugha> nick is Janonymous.
            
-
            13:08 < ughabugha> Ok.
            
-
            13:08 < duck> hi
            
-
            13:08 < jrandom> weekly status notes are posted to the mailing list (online at http://i2p.net/pipermail/i2p/2004-March/000155.html)
            
-
            13:08 < ughabugha> hi.
            
-
            13:08 < jrandom> as usual, we'll be following that as a guide
            
-
            13:08 < nick> hello
            
-
            13:09 < jrandom> jumping into 1) Dev status
            
-
            13:09  * jrandom repeats mantra of "Progress is being made"
            
-
            13:10 < jrandom> 0.2.5 has some Good Stuff, and we're finding long hidden bugs
            
-
            13:10 < jrandom> latest one is db related, but thats not fixed up yet, so no need to track CVS HEAD
            
-
            13:11 < jrandom> echo tests show pretty good results, but there's still issues to be worked out wrt irc and snark
            
-
            13:12 < jrandom> how has eepsite retrieval been for people?
            
-
            13:12 < jrandom> (and/or squid?)
            
-
            13:12 < nick> here and there
            
-
            13:12 < duck> generally okay with janonymous or ugha
            
-
            13:13 < duck> sometimes janonymous goes down etc
            
-
            13:13 < ughabugha> Yeah.
            
-
            13:13 < duck> <mihi_backup> jrandom: you *really* know how to make me angry...
            
-
            13:13 < jrandom> d'oh
            
-
            13:13 < nick> I've been putting new content
            
-
            13:13 < jrandom> whats up mihi?
            
-
            13:13 < jrandom> nice nick
            
-
            13:14 < jrandom> er janonymous
            
-
            13:15 < nick> eh?
            
-
            13:15 < nick> :)
            
-
            13:15 < ughabugha> IIP <ughabugha> I started a two-way relay now.
            
-
            13:15 < jrandom> ah cool
            
-
            13:15 -!- nick [~Janonym@localhost] has quit [Client closed connection]
            
-
            13:15 < jrandom> whats up mihi?
            
-
            13:15 < ughabugha> IIP <ughabugha> Automatic.
            
-
            13:16 < ughabugha> IIP <ughabugha> :)
            
-
            13:16 < ughabugha> :)
            
-
            13:16 < ughabugha> IIP <ughabugha> Oops, a bug.
            
-
            13:16 < ughabugha> Oops, a bug.
            
-
            13:16 < jrandom> heh is he still there or is there anything else wrt dev status?
            
-
            13:17 < duck> lets go on
            
-
            13:17 < jrandom> 'k
            
-
            13:17 < jrandom> jumping to 2) Cascades
            
-
            13:17 < ughabugha> IIP <ughabugha> * mihi_backup is now known as mihi_away
            
-
            13:17 < ughabugha> * mihi_backup is now known as mihi_away
            
-
            13:17 < ughabugha> IIP <ughabugha> Argh, relaying for my own text doesn't work.
            
-
            13:17 < ughabugha> Argh, relaying for my own text doesn't work.
            
-
            13:17 < jrandom> ;)
            
-
            13:18 < ughabugha> IIP <ughabugha> No, wait.
            
-
            13:18 < ughabugha> No, wait.
            
-
            13:18 < madman> then don't speak :)
            
-
            13:18 < jrandom> mix cascades are one of the two big styles of low latency mix nets, and while we don't use them in i2p, if some people think they're useful, they can tweak their router to get the same effect
            
-
            13:19 < ughabugha> IIP <ughabugha> Test
            
-
            13:19 < ughabugha> Test
            
-
            13:19 < ughabugha> IIP <jrandom> mix cascades are one of the two big styles of low latency mix nets, and while we don't use them in i2p, if some people think they're useful, they can tweak their router to get the same effect
            
-
            13:19  * jrandom senses an incoming recursive echo...
            
-
            13:19 < ughabugha> IIP <ughabugha> Damn!
            
-
            13:19 < ughabugha> Damn!
            
-
            13:20 < jrandom> anyway, I think its always good to ask fundamental design questions, to poke at i2p and see why we do things the way we do
            
-
            13:21 < jrandom> i've got the feeling we'll be hearing more about cascade-like systems in the future, so hopefully the description in the email will help explain i2p's relation to cascades
            
-
            13:21 < ughabugha> Ok, it should work _now_.
            
-
            13:21 < ughabugha> IIP <ughabugha> Say something.
            
-
            13:21 < ughabugha> IIP <Janonymous> I move to not go after a mix net implementation within the current roadmap, and leave that for later
            
-
            13:21 < ughabugha> Yeah, it works now.
            
-
            13:21 -!- wilde [~anon@localhost] has joined #i2p
            
-
            13:22 < jrandom> janymous> well, i2p /is/ a mixnet, just not a mix cascade
            
-
            13:22 < madman> i'm going offline
            
-
            13:22 < jrandom> 'k, ttyl madman
            
-
            13:22 < jrandom> heya wilde
            
-
            13:22 < madman> so bye
            
-
            13:22 < ughabugha> IIP <wilde> finally
            
-
            13:22 < ughabugha> IIP <wilde> hello meeting
            
-
            13:22 < jrandom> but I concur, I don't think mix cascade functionality needs to be on the roadmap
            
-
            13:23 < ughabugha> IIP <madman2003> bye everyone
            
-
            13:24 < jrandom> ok, anything else on cascades, or should we move to 3) Roadmap?
            
-
            13:26 < ughabugha> Hi, wilde@IIP
            
-
            13:26 < ughabugha> Bye, madman@IIP
            
-
            13:26 -!- madman [~a@localhost] has quit [( www.nnscript.de :: NoNameScript 3.8 :: www.XLhost.de )]
            
-
            13:26 < ughabugha> IIP <Janonymous> Just seems like it could be implemented later, like a DHT might be. High Wilde
            
-
            13:26 < ughabugha> IIP <Janonymous> bye Madman
            
-
            --- Log closed Tue Mar 02 13:27:07 2004
            
-
            --- Log opened Tue Mar 02 13:27:52 2004
            
-
            13:27 -!- jrandom [~jrandom@localhost] has joined #i2p
            
-
            13:27 -!- Irssi: #i2p: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
            
-
            13:27 -!- wilde [~anon@localhost] has joined #i2p
            
-
            13:27 < jrandom> back
            
-
            13:28 < ughabugha> Uhoh, jrandom quitted.
            
-
            13:28 < ughabugha> IIP <Janonymous> bah
            
-
            13:28 < jrandom> ok last I saw was 13:26:08 < ughabugha> IIP <Janonymous> bye Madman
            
-
            13:28 -!- Irssi: Join to #i2p was synced in 36 secs
            
-
            13:28 < jrandom> (irssi missed a ping so it dropped it)
            
-
            13:29 < ughabugha> You missed IIP <Janonymous> Roadmap
            
-
            13:29 < ughabugha> IIP <Janonymous> ah.. We all agreed to go onto the roadmap ;)
            
-
            13:29 < jrandom> w3rd
            
-
            13:29 < jrandom> ok, the roadmap change is likely why mihi hates me now
            
-
            13:30 < ughabugha> Uh, then you missed alot more than that.
            
-
            13:30 < ughabugha> Just a second.
            
-
            13:30 < ughabugha> [23:23 39] <ughabugha> IIP <wilde> oh we have to camps now, the iip gang and the I2P hood
            
-
            13:30 < ughabugha> [23:23 47] <ughabugha> IIP <wilde> two
            
-
            13:30 < ughabugha> [23:23 50] <ughabugha> Hehe.
            
-
            13:30 < ughabugha> [23:23 54] <ughabugha> IIP <Janonymous> :) got a relay going
            
-
            13:30 < ughabugha> [23:24 22] <ughabugha> This is a temporary script I hacked together quickly. For future meetings we should think of something better.
            
-
            13:30 < ughabugha> [23:24 44] <ughabugha> IIP <Janonymous> It works
            
-
            13:30 < ughabugha> [23:25 18] <ughabugha> Ok, concentrate on I2P now, not the relay.
            
-
            13:30 < ughabugha> [23:25 39] <ughabugha> IIP <Janonymous> So, mix cascades could feasably implemented quite well over i2p
            
-
            13:30 < ughabugha> Sorry for the flood.
            
-
            13:30 < duck> this is chaos
            
-
            13:31 < ughabugha> IIP <Janonymous> but i think we can emphasize /over/
            
-
            13:31 < ughabugha> Ok, 3) Roadmap
            
-
            13:31 < ughabugha> duck: Pretty much.
            
-
            13:31 < jrandom> this aint nothing compared to meeting 67 ;)
            
-
            13:31 < jrandom> ok, on to 3
            
-
            13:31 < jrandom> anyone have any thoughts wrt the roadmap?
            
-
            13:32 < jrandom> the changes / views / concerns?
            
-
            13:32 < ughabugha> IIP <Janonymous> Multi-tunneling
            
-
            13:32 < jrandom> janonymous> we've already got that
            
-
            13:32 < jrandom> (as of 0.2.5)
            
-
            13:32 < jrandom> if I understand you correctly
            
-
            13:33 < ughabugha> IIP <Janonymous> but, as in, sending one file over two tunnels to accelerate transmission?
            
-
            13:33 < ughabugha> IIP <Janonymous> at the same time
            
-
            13:34 < jrandom> i2p doesn't deal with files, but yes, each individual i2p message can now go down multiple tunnels
            
-
            13:34 < ughabugha> IIP <Janonymous> I think that would be a great addition for the 2.0 area
            
-
            13:34 < jrandom> e.g. first 32kb sent down tunnel X, next 32kb sent down tunnel Y
            
-
            13:35 < ughabugha> IIP <Janonymous> right.. thats what I'm getting at.. that seems very necessary to me
            
-
            13:35 < jrandom> but i2psnark with i2cp support would be able to maximize things
            
-
            13:35 < jrandom> janonymous> we do that now
            
-
            13:36 < ughabugha> IIP <Janonymous> oh. I2PSnark will utilize multiple tunnels for point to point communication?
            
-
            13:36 < jrandom> all messages can go down multiple tunnels.
            
-
            13:36 < duck> theoretically
            
-
            13:37 < jrandom> not just theoretically - if a message takes > 15s, its sent down the other available lease
            
-
            13:37 < jrandom> and if it takes > 30s, the leaseSet is dropped and refetched, with subsequent messages going down found leases
            
-
            13:37 < jrandom> BUT
            
-
            13:38 < jrandom> i2ptunnel (any anything else that uses i2p's mode=guaranteed) waits until each message is delivered before sending the next one
            
-
            13:38 < jrandom> native i2cp apps don't need to do that
            
-
            13:38 < jrandom> (nor will any apps that use the socket library, once the socket library is both implemented and supports SACK)
            
-
            13:38 < ughabugha> IIP <Janonymous> ok.. I just think that will be a great method for these tunnels in the future.. for speed and anomymity
            
-
            13:38 < ughabugha> IIP <Janonymous> and keeping strain off individual tunnels
            
-
            13:39 < jrandom> agreed
            
-
            13:39 < jrandom> ok, anything else on the roadmap?
            
-
            13:40 < jrandom> (anyone going to bitch me out for dropping the socket lib?  mihi?  :)
            
-
            13:41 < ughabugha> IIP <Janonymous> I used an analogy earlier today to describe multi-tunneling to someone.. and I said it was like adding lanes to a road
            
-
            13:42 < jrandom> pretty much
            
-
            13:42 < jrandom> (though one's on-ramp is always the same number of lanes ;)
            
-
            13:42 < duck> if mihi is angry he can do the socket api cant he?
            
-
            13:43 < jrandom> sure, and/or anyone else.  the socket lib is Good
            
-
            13:43 < jrandom> (but hard, and imho not functionally essential to the operation / security of the network)
            
-
            13:44 < jrandom> i just wish i had the time to do it and keep moving on the core i2p code
            
-
            13:44 < jrandom> but, c'est la vie
            
-
            13:45 < ughabugha> IIP <Janonymous> looks like mihis not here
            
-
            13:45 < ughabugha> Ok, i'm back now.
            
-
            13:45 < jrandom> coo'
            
-
            13:45 < jrandom> ok, moving on to 4) website
            
-
            13:46 < ughabugha> IIP <Janonymous> big on ramp == cable / small on ramp == dialup ??
            
-
            13:46 < ughabugha> Hmm
            
-
            13:46 < ughabugha> What was the socket library going to do?
            
-
            13:46 -!- nick [~Janonym@localhost] has joined #i2p
            
-
            13:46 < jrandom> right nanonymous
            
-
            13:46 < jrandom> er, janonymous
            
-
            13:46 < jrandom> (no matter what, i2p cant make your local net connection faster)
            
-
            13:46 < jrandom> ughabugha: http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary
            
-
            13:47 < ughabugha> I mean a socket library for Java? Don't you already have one?
            
-
            13:47 < jrandom> the socket lib factors out the TCP-esque code out of i2p, letting i2p specialize in IP-like messages
            
-
            13:47 < nick> yup
            
-
            13:47 -!- nick [~Janonym@localhost] has quit [Client closed connection]
            
-
            13:48 < jrandom> ah, right, yes, but this would let applications stream data over i2p much more efficiently (if/when the socket library supports selective ACK, rather than requiring an ACK after each message like it does now)
            
-
            13:49 < jrandom> i'm not comfortable with implementing SACK within the router, since it can safely go outside of it (into the socket lib)
            
-
            13:49 < ughabugha> But why drop it? Does it really take that much work?
            
-
            13:49 < jrandom> yes, to get right
            
-
            13:49 < jrandom> there's some code thats part way implemented, but i dont have time to maintain and test it
            
-
            13:49 < ughabugha> Ok. You're the man.
            
-
            13:50 < jrandom> well, $devWhoImplements it is the man ;)
            
-
            13:50 < jrandom> anyway, moving on to 4) website
            
-
            13:50 < ughabugha> :)
            
-
            13:51 < ughabugha> Any volunteers?
            
-
            13:51 < ughabugha> IIP <Janonymous> research on implementations of anonymous p2p
            
-
            13:51  * jrandom echoes ughabugha's question :)
            
-
            13:51 < jrandom> hmm janonymous?
            
-
            13:51 < ughabugha> Janonymous: This will be covered under 5) ???
            
-
            13:51 < jrandom> :)
            
-
            13:52 < ughabugha> IIP <Janonymous> wll its content that goes on the site
            
-
            13:52 < jrandom> ah, yeah, I agree
            
-
            13:52 < jrandom> (see item 7 on http://i2p.net/pipermail/i2p/2004-February/000133.html)
            
-
            13:53 < jrandom> and item 8
            
-
            13:53 < jrandom> or is that not what you mean?
            
-
            13:53 < jrandom> I'll probably post up the truckload of papers i dug through last summer when researching and designing i2p
            
-
            13:53 < jrandom> (or at least pointers to their citeseer entries)
            
-
            13:54 < ughabugha> IIP <Janonymous> Ok. Were we going to discuss the next CMS for I2P?
            
-
            13:54 < ughabugha> jrandom allready chose the CMS.
            
-
            13:55 < jrandom> yes/no - rather than researching the pros and cons of CMSes for another month or two, we'll just go with drupal for now
            
-
            13:55 < ughabugha> IIP <ughabugha> /topic #i2p
            
-
            13:55 < ughabugha> IIP <Janonymous> Ok.. well, as far as what to put there.. We need a presentation
            
-
            13:55 < jrandom> if we need to migrate to another one, wilde assures me its simple enough to export content
            
-
            13:55 < jrandom> a presentation?
            
-
            13:56 < ughabugha> IIP <Janonymous> with lots of illustrations and a step by step introduction to I2P
            
-
            13:56 < jrandom> we do need the graphic design implemented
            
-
            13:56 < jrandom> ah right
            
-
            13:56 < jrandom> a user's intro
            
-
            13:56 < jrandom> the wiki intro is generally a technie intro
            
-
            13:56 < ughabugha> IIP <Janonymous> Almost like a multimedia presentation
            
-
            13:56 < ughabugha> IIP <jrand0m> w0ah
            
-
            13:56 < ughabugha> IIP <Janonymous> right
            
-
            13:57 < ughabugha> IIP <ughabugha> Yay!
            
-
            13:57 < jrandom> ok, i think we can get that together, but we'll probably want to wait on producing that content until we have both a Real installer, and a GUI control system
            
-
            13:57 < ughabugha> IIP <Janonymous> In it, there should be more pictures, than words. :)
            
-
            13:57 < jrandom> right
            
-
            13:58 < ughabugha> IIP <Janonymous> righto
            
-
            13:58 < jrandom> but we don't have a real installer yet, and (as much as i2pmgr and i2pmole are great) i think there's still work to be done on a control panel
            
-
            13:58 < ughabugha> This is not the top priority right now.
            
-
            13:58 < ughabugha> IIP <Janonymous> certainly not. but for those of us not programming...
            
-
            13:59 < jrandom> right.  so we need volunteers to work on 1) designing what content needs to be on the i2p website 2) designing the graphics / css / layout for the i2p website 3) people to work on creating content for the i2p website
            
-
            14:00 < ughabugha> IIP <Janonymous> I've got a month to spare. Think it would be time well spent.
            
-
            14:00 < jrandom> w00t :)
            
-
            14:00  * jrandom marks Janonymous down as a volunteer... for content design & content creation?
            
-
            14:00 < wilde> back
            
-
            14:00 < ughabugha> Well, I could do HTML, CSS and the technical stuff, but I'm not much of a writer, nor a designer.
            
-
            14:01 < jrandom> r0x0r
            
-
            14:01 < ughabugha> IIP <Janonymous> right.. I'm not so good at the designing part yet
            
-
            14:01 < ughabugha> IIP <Janonymous> I could try to write, but not without some good critique.. I've never writen editorial type things
            
-
            14:01 < ughabugha> I can also use Photoshop and other tools as long as I'm given specific instructions on what to do. ;)
            
-
            14:01 < wilde> I'll take care of drupal and features
            
-
            14:02 < ughabugha> IIP <Janonymous> I've got some good ideas for you ughabugha
            
-
            14:02 < jrandom> right, by content design i don't mean layout, but more "ok, we need a user intro page, a tech intro page, a faq" etc
            
-
            14:02 < ughabugha> Heh, ok. :)
            
-
            14:02 < jrandom> r0x0r0r
            
-
            14:02  * jrandom marks down wilde and ughabugha as volunteers :)
            
-
            14:02 < ughabugha> Looking forward to them.
            
-
            14:02 < ughabugha> IIP <Janonymous> there's a shaby picture I made that can be found linked to the new I2POverview doc on I2p
            
-
            14:03 < jrandom> word, yeah janonymous, that pic is pretty good, some minor tech issues with it, but quite useful
            
-
            14:03 < ughabugha> IIP <Janonymous> It would look alot nicer in photoshop I'm sure
            
-
            14:04 < ughabugha> Heh.
            
-
            14:04 < ughabugha> Janonymous: Let's discuss that privately tomorrow.
            
-
            14:04 < ughabugha> IIP <Janonymous> eh, actually I may have accidentally deleted it :/
            
-
            14:04 < jrandom> ok, anything else for the website, or can we move on to 5) ???
            
-
            14:04 < ughabugha> IIP <Janonymous> ok
            
-
            14:07 < wilde> ok one thing:
            
-
            14:07 < ughabugha> Anything else on website?
            
-
            14:07 < wilde> what is the first feeling you should get on the site?
            
-
            14:07 < wilde> keywords please
            
-
            14:07 < jrandom> wilde> see http://i2p.net/pipermail/i2p/2004-February/000133.html (the "rom a branding perspective" paragraph :)
            
-
            14:08 < jrandom> i do like the anonymous bit by bit thing
            
-
            14:08 < ughabugha> I suppose not. Should we go on to 5) ??? ?
            
-
            14:08 < ughabugha> IIP <Janonymous> should we make a more detailed user roadmap?
            
-
            14:08 < ughabugha> IIP <Janonymous> one describing the long term goals in more detail
            
-
            14:08 < ughabugha> wilde: Only positive emotions.
            
-
            14:09 < jrandom> janonymous> agreed, the current roadmap is really just tech notes for tech tasks ;)
            
-
            14:09 < jrandom> ok, 5) ??
            
-
            14:09 < jrandom> anything y'all want to bring up?
            
-
            14:10 < wilde> itoopie isn't really in line with simple and secure
            
-
            14:10 < wilde> it's more of a cartoon feeling
            
-
            14:10 < wilde> that's why i asked
            
-
            14:10 < ughabugha> IIP <Janonymous> yea, might want to build some more anticipation
            
-
            14:10 < ughabugha> IIP <Janonymous> for the users to get involved
            
-
            14:10 -!- kaji [~booky5@localhost] has joined #i2p
            
-
            --- Log closed Tue Mar 02 14:11:08 2004
            
-
            --- Log opened Tue Mar 02 14:12:12 2004
            
-
            14:12 -!- jrandom_ [~jrandom@localhost] has joined #i2p
            
-
            14:12 -!- Irssi: #i2p: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal]
            
-
            14:12 < jrandom_> back
            
-
            14:12 < ughabugha> IIP <Janonymous> like, it should work for them without them even knowing its there
            
-
            14:12 < jrandom_> wilde> I'm open to suggestions
            
-
            14:12 < ughabugha> * jrandom_ (~jrandom@localhost) has joined #i2p
            
-
            14:12 < jrandom_>  <Janonymous> yea, might want to build some more anticipation
            
-
            14:12 < jrandom_> hmm?
            
-
            14:14 < ughabugha> You missed these:
            
-
            14:14 < ughabugha> [00:11 43] <ughabugha> IIP <Janonymous> I'd just like to reemphasize.. I just think all multi-tunneling methods should be transparent and available to all client apps
            
-
            14:14 < ughabugha> [00:12 07] <ughabugha> IIP <Janonymous> like, it should work for them without them even knowing its there
            
-
            14:14 < jrandom_> janonymous> already implemented.
            
-
            14:14 < jrandom_> i2p already transparently balances end to end communication over multiple tunnels
            
-
            14:15  * jrandom_ kicks jrandom
            
-
            14:15 -!- jrandom [~jrandom@localhost] has quit [Ping timeout]
            
-
            14:15 -!- Irssi: Join to #i2p was synced in 231 secs
            
-
            14:15 < wilde> participation?
            
-
            14:15 < ughabugha> IIP <Janonymous> even if we profile the fastest most stable tunnels.. we can still use the other slow tunnels for extra throughput if we need it
            
-
            14:15 < kaji> is iip up?
            
-
            14:15 -!- kaji [~booky5@localhost] has quit [Client closed connection]
            
-
            14:15 < ughabugha> IIP <Janonymous> And we may want to distribute the load anyway.. and that should all be transparent to the client apps
            
-
            14:15 -!- You're now known as jrandom
            
-
            14:16 -!- protocol [~iip@localhost] has joined #i2p
            
-
            14:16 < ughabugha> IIP <Janonymous> ok
            
-
            14:16 < ughabugha> IIP <Janonymous> cool
            
-
            14:16 < jrandom> :)
            
-
            14:17 < ughabugha> jrandom: Don't use ACTION, it's not relayed ;)
            
-
            14:17 < jrandom> hah ok sorry
            
-
            14:17  * jrandom says something they cant see
            
-
            14:17 < jrandom> ;)
            
-
            14:17 < jrandom> ok, anyone else have anything else?
            
-
            14:18 < jrandom> i think after the current netDb bugs are fixed we may want to try the i2psnark tests again
            
-
            14:20 -!- kaji [~booky5@localhost] has joined #i2p
            
-
            14:20 -!- wilde [~anon@localhost] has quit [Ping timeout]
            
-
            14:20 < ughabugha> But does the 15-second wait really distribute the load?
            
-
            14:20 < ughabugha> That's not how I see it.
            
-
            14:20  * protocol says iip is for lusers
            
-
            14:20 < ughabugha> The way I see it, it should be 100% simultaneous, the node should put packets through the tunnel as fast as the destination can handle them.
            
-
            14:20 < ughabugha> Through all the tunnels, I mean.
            
-
            14:20 -!- nick [~Janonym@localhost] has joined #i2p
            
-
            14:20 -!- kaji [~booky5@localhost] has quit [Client closed connection]
            
-
            14:21 < jrandom> ughabugha: each message is ideally only sent over one tunnel, but each individual message is balanced over all of them
            
-
            14:21 < ughabugha> IIP <Janonymous> me and duck ran a test over I2PSnark
            
-
            14:21 < ughabugha> IIP <Janonymous> earlier today.
            
-
            14:21 < jrandom> ughabugha: if we sent it over all tunnels always, that'd be a significant amount of wasted traffic
            
-
            14:21 -!- nick [~Janonym@localhost] has quit [Client closed connection]
            
-
            14:21 < ughabugha> IIP <Janonymous> Is everyone happy with the "I2P" name?
            
-
            14:21 -!- kaji [~booky5@localhost] has joined #i2p
            
-
            14:21 -!- wilde [~anon@localhost] has joined #i2p
            
-
            14:22 < jrandom> janonymous> i2p is the name.
            
-
            14:22 < jrandom> you can call it betty, but i2p is the name ;)
            
-
            14:22 < ughabugha> kaji: Why are you blinking like this?
            
-
            14:22 < jrandom> ughabugha: kaji likes messing with us
            
-
            14:22 < ughabugha> jrandom: Yeah, I understand that. I guess it works just as I imagine it.
            
-
            14:23 < kaji> i dont know
            
-
            14:23 < kaji> is iip up?
            
-
            14:23 < ughabugha> IIP <Janonymous> cool
            
-
            14:23 < ughabugha> IIP <Janonymous> is for me
            
-
            14:23 < ughabugha> It is for some people, and it's not for others.
            
-
            14:23 < ughabugha> So I'm running a relay.
            
-
            14:24 < jrandom> ughabugha++
            
-
            14:24 < ughabugha> To connect the networks.
            
-
            14:24 < kaji> cool
            
-
            14:24 < jrandom> the details of the parallel/serial sending is in net.invisiblenet.i2p.router.message.OutboundClientMessageJob
            
-
            14:24 < ughabugha> :)
            
-
            14:24 < jrandom> (for anyone who wants to know more details of how it works)
            
-
            14:25 < jrandom> ok, anything else people want to bring up?
            
-
            14:25 < kaji> so how is i2p dev? :) (Mirc sez 'lag=30 seconds')
            
-
            14:25 < jrandom> kaji> we're making progress ;)
            
-
            14:26 < jrandom> irssi here has bounced between 80s and 1s lag
            
-
            14:26 < jrandom> (two disconnects in the last 90 minutes)
            
-
            14:26 < ughabugha> IIP <Janonymous> is there any more ideas on content for the new site?
            
-
            14:27 < ughabugha> IIP <kaji> sweet
            
-
            14:27 < jrandom> beyond http://i2p.net/pipermail/i2p/2004-February/000133.html I think we'll want to go with one of drupal's forum modules
            
-
            14:27 < ughabugha> No disconnects for me for 80 minutes.
            
-
            14:27 < jrandom> nice ughabugha 
            
-
            14:27 < kaji> hmm now the lag is down to a few seconds
            
-
            14:27 < jrandom> yeah, it varies kaji
            
-
            14:28 < ughabugha> IIP <Janonymous> oh, me and ugha talked on my chat room over eep today :)
            
-
            14:28 < jrandom> nice1!
            
-
            14:28 < ughabugha> Janonymous: I wouldn't call that talking. ;)
            
-
            14:28 < ughabugha> It was more like shouting over a distance of a few kilometers.
            
-
            14:28 < jrandom> wait, y'all did voice?
            
-
            14:29 < ughabugha> IIP <Janonymous> :) it was one message
            
-
            14:29 < ughabugha> :)
            
-
            14:29 < ughabugha> Well, I caused all the lag.
            
-
            14:30 < ughabugha> Anyway, if somebody has a proposition for discussion, do it now, because I have to go.
            
-
            14:30 < jrandom> word, 90m is a good meeting length to end at too...
            
-
            14:30 < jrandom> anything else can be taken up on the mailing list
            
-
            14:30 < jrandom> (and/or iip/i2p later)
            
-
            14:31  * jrandom winds up the *baf*er...
            
-
            14:31  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting81.html b/www.i2p2/pages/meeting81.html
deleted file mode 100644
index a76997b4..00000000
--- a/www.i2p2/pages/meeting81.html
+++ /dev/null
@@ -1,405 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 81{% endblock %}
-{% block content %}
            Tuesday, Mar 16, 2004 13:00:00 PST
            
-
            
-
            13:12 < jrandom> agenda:
            
-
            13:12 < jrandom> 0) hi
            
-
            13:12 < jrandom> 1) administravia
            
-
            13:13 < jrandom> 2) 0.3 status
            
-
            13:13 < jrandom> 3) peer profiling / selection
            
-
            13:13 < jrandom> 4) web architecture
            
-
            13:13 < jrandom> 5) ???
            
-
            13:13 < jrandom> 0) hi
            
-
            13:13  * jrandom waves to the gang
            
-
            13:14 < deer> * jrandom_ waves from i2p
            
-
            13:14 < deer> * wilde hi5s
            
-
            13:15 < deer> <ughabugha> Hi!
            
-
            13:15 < deer> * duck is reading
            
-
            13:15 < deer> <human> yo!
            
-
            13:16 < jrandom> w0rd, sorry for the delay getting those status notes up at (http://i2p.net/pipermail/i2p/2004-March/000165.html)
            
-
            13:18 < jrandom> 1) administravia
            
-
            13:19 < jrandom> for simplicity, and to avoid the trouble we had last week w/ the various networks being bitchy, some magic has been worked out and this meeting is being run off three irc networks
            
-
            13:19 < deer> <duck> (amazing!)
            
-
            13:19 < jrandom> iip's #i2p, the duck/baffled i2p irc network's  #i2p, and freenode's #i2p
            
-
            13:19 < jrandom> :)
            
-
            13:19 < deer> <baffled> who's paranoid?
            
-
            13:20 < deer> <ughabugha> Ok, done reading the status notes.
            
-
            13:20 < deer> <ughabugha> jrandom: What about it?
            
-
            13:20 < deer> <ughabugha> Or them?
            
-
            13:21 < jrandom> just mentioning it, so people who have trouble with one can use another
            
-
            13:21 < deer> <mihi> fine. done with status notes as well
            
-
            13:21 < jrandom> also, the drupal box should be back online this weekend (crossing fingers)
            
-
            13:22 < deer> <ughabugha> Oh, ok. Is there anything to discuss on 1)?
            
-
            13:22 < deer> <ughabugha> Or are we waiting for people to finish reading?
            
-
            13:22 < deer> <ughabugha> jrandom: Good. :)
            
-
            13:22 < jrandom> nope, unless anyone has any administravia they'd like to bring up?
            
-
            13:23 < deer> * mihi wants to set a flag at point 3
            
-
            13:23 < jrandom> flag set ;)
            
-
            13:23 < deer> * duck at point 2
            
-
            13:23 < deer> <duck> err, what index do we use?
            
-
            13:24  * jrandom supposes we can move on to agenda item 2) 0.3 status
            
-
            13:25 < jrandom> i ended up typing a lot more than usual for the 0.3 status notes, so rather than repeat them here, does anyone have any questions / concerns they'd like to bring up?
            
-
            13:25 < deer> <ughabugha> Go on.
            
-
            13:26 < deer> <duck> why do the ElGamal/AES+SessionTag decryptions fail too often?
            
-
            13:26 < jrandom> duck> due to overload and lag.  if a garlic routed message is delayed beyond that sessionTag's lifetime, the decryption will fail
            
-
            13:27 < deer> <duck> k
            
-
            13:27 < jrandom> in addition, if the garlic routed message is decrypted fine, but the content was delayed so much that the cloves expire, its a wasted decryption, as well
            
-
            13:28 < deer> <duck> somehow that sentence made me believe that there was a cause besided the overload/lag
            
-
            13:28 < deer> <tro|l> ce zi e azi?
            
-
            13:28 < jrandom> well, there have been some troubles with source routed reply blocks failing decryption, though since they're going away in 0.3.1, its not really worth debugging them too much
            
-
            13:29 < deer> <kaji> wow it works!
            
-
            13:29 < jrandom> (and a failed ElG is probably the most CPU intensive thing i2p does)
            
-
            13:30 < deer> <jrandom_> heh welcome to i2p #i2p :)
            
-
            13:30 < deer> * kaji praises 0.2.5.1
            
-
            13:30 < deer> <jrandom_> 0.2.5.1?  sheeit, get thee 0.2.5.4 :)
            
-
            13:30 < jrandom> ok, anything else for 0.3 status?
            
-
            13:31 < deer> <kaji> ..
            
-
            13:31 < deer> <duck> .
            
-
            13:31 < deer> <kaji> ping?
            
-
            13:31 < jrandom> p0ng
            
-
            13:31 < mihi> pung
            
-
            13:31 < deer> <mihi_backup> pung2
            
-
            13:32 < deer> <Pellinore> prawn
            
-
            13:32 < jrandom> ok, moving on to 3) peer profiling / selection
            
-
            13:32  * mihi moves the flag to the other number 3 ;)
            
-
            13:32 < jrandom> (man, its kind of funny that there isn't any vegetarian seafood substitutes...)
            
-
            13:32 < deer> * kaji praises 0.2.5.4.1
            
-
            13:32 < deer> <duck> the whole peer profiling thing looks at magic, how do you plan to debug that?
            
-
            13:32 < deer> <Pellinore> There is vegetarian crabmeat.
            
-
            13:32 < jrandom> ah, true pellinore.
            
-
            13:32 < deer> <wilde> jrandom: and veg sushi
            
-
            13:33 < jrandom> duck> what part of it looks like magic?
            
-
            13:33 < deer> <duck> the whole classification etc
            
-
            13:33 < deer> <Pellinore> And I could have sworn that I had seen some chik-type fish fillet substitute, but I could be wrong.
            
-
            13:33 < deer> <duck> I mean, how do you know that you are doing optimal things?
            
-
            13:33 < jrandom> the peer organizer (which moves profiles into the different groups) is a very simple and seperable component
            
-
            13:33 < jrandom> oh, thats a good point.
            
-
            13:34 < jrandom> i was doing some benchmarking the other day, running the organizer with 10,000 profiles, and it was organizing them all un ~50ms
            
-
            13:34 < jrandom> (organizing == runningthe calculators and moving them between groups)
            
-
            13:34 < jrandom> profiles also consume only ~3-4KB for a full profile, and a minimal profile takes ~200 bytes
            
-
            13:35 < deer> <duck> yeah, but how do you know that you are right with '0.597s reply' for group 1
            
-
            13:35 < deer> <duck> and that it shouldnt be 0.603s
            
-
            13:35 < jrandom> (so we'll keep a full profile of the best 1000 peers, and minimal of the next 10,000)
            
-
            13:35 < jrandom> ah, ok, good question.
            
-
            13:36 < jrandom> thats the Rate component
            
-
            13:36 < jrandom> there will obviously be some flutter, and we won't be very exact.  the goal ois to get ballpark and organize them accordingly
            
-
            13:37 < deer> <duck> I did see it using averages
            
-
            13:37 < jrandom> e.g. find the routers on T3s with quad procs, and keep them seperate from routers on 386s with 2400 bps modems
            
-
            13:37 < deer> <duck> so if you throw in 100 shitty nodes, you heavily influence the average
            
-
            13:37 < jrandom> agreed - there are two different aspects of that that we can tune
            
-
            13:38 < jrandom> first, we can make the threshold use the top 10% to determine the "fast" vs "not fast"
            
-
            13:38 < jrandom> (or top 90%, whichever)
            
-
            13:38 < jrandom> second, we can adjust the Rate component to keep various statistics - rather than a simple average, it can ignore skew, find stddev, etc
            
-
            13:39 < jrandom> the rate component currently is quite remedial, and I'd love if someone good with stats could take a look at it and fix it up
            
-
            13:39 < jrandom> (one of the key goals of it however is to keep it scale free - so if we get 100,000 events, it doesnt have to keep all those data points in memory, etc)
            
-
            13:40 < deer> <duck> ok, so what prevents another NGRouting disaster from happening?
            
-
            13:40 < jrandom> but you're absolutely right - the calculators and the peer selection algorithms are going to be a major focus of future network improvements
            
-
            13:40 < jrandom> ngrouting tried to do two different things - find particular data, and find available peers.
            
-
            13:40 < jrandom> we only need to find available peers
            
-
            13:41 < deer> <duck> good
            
-
            13:41 < jrandom> (and place our tunnels there)
            
-
            13:41 < deer> * duck removes breakpoint
            
-
            13:41 < jrandom> :)
            
-
            13:41 < mihi> but we have to find tunnels as well.
            
-
            13:41 < jrandom> right mihi - the netDb is an important point
            
-
            13:42 < deer> <Pellinore> I'm good with the math of statistics, but terrible with the tech aspects of translating the data into computer-useful data.
            
-
            13:42 < deer> <Pellinore> But I would happily partner up with someone and contribute if I can.
            
-
            13:42 < jrandom> awesome pellinore!
            
-
            13:43 < jrandom> the main rate class is up at http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/core/java/src/net/invisiblenet/i2p/stat/Rate.java?rev=1.3&content-type=text/x-cvsweb-markup and we can talk later to discuss it :)
            
-
            13:43 < deer> <Pellinore> k
            
-
            13:43 < jrandom> (i know, i don't expect you to read the code, just mentioning it)
            
-
            13:44 < deer> <Pellinore> I'll read it, but it will be about like my dog reading Kierkegaard.
            
-
            13:44 < jrandom> hehe
            
-
            13:45 < deer> <Pellinore> But I am learning.
            
-
            13:45 < deer> <Pellinore> Anyway, please proceed -- I don't mean to bog things down.
            
-
            13:45 < jrandom> (volunteering to help isn't bogging things down ;)
            
-
            13:46 < jrandom> one point i forgot to mention about the peer profiling / selection code is that the 'integration' rank is only used in the network database for 'exploration', not for search/store
            
-
            13:46 < jrandom> we still do (fairly) traditional kademlia search/store with all non-failing peers
            
-
            13:46 < jrandom> also, within each peer group, we always choose *randomly*
            
-
            13:46 < jrandom> (aka we don't always choose the fastest of the fast group, etc)
            
-
            13:47 < jrandom> thats for both security and load balancing reasons
            
-
            13:48 < jrandom> (security, so that an attacker can't just create a really fast router and watch everyone make use of them - they have to create a large number of really fast routers, skew the entire distribution in their favor, etc)
            
-
            13:49 < jrandom> ok, do we have anything else for 3) peer profiling / selection?
            
-
            13:49 < deer> <duck> .
            
-
            13:50 < deer> <ughabugha> Doesn't look like it.
            
-
            13:50 < jrandom> ok, moving on to 4) web architecture
            
-
            13:52 < jrandom> mihi's new streaming lib gives us a lot of flexibility, plus he's mentioned a few times the desire to factor out the httpclient code into something more robust.  in addition, human has started updating things to allow transparent squid(or tor-www) proxying and eepsite proxying within the same client
            
-
            13:52 < jrandom> given all of these different factors, and the likelyhood that web like functionality will be important for i2p's user base, i think we should take a step back and try to envision how it should all fit together
            
-
            13:53  * mihi has some code flying around on my hd for that httptunnel code. but it's far from being finished
            
-
            13:53 < mihi> for me httptunnel == httpclient + some filters
            
-
            13:53 < mihi> of course using my naming and streaming api.
            
-
            13:54 < mihi> the code atm only allows different "anonymity profiles".
            
-
            13:54 < jrandom> any thoughts on human's style of failing over to outproxies like squid/etc?
            
-
            13:54 < mihi> i.e. send all requests over one destination, mux them up to 10, mux them up to one dest per hostname, etc.
            
-
            13:54 < jrandom> ah, interesting
            
-
            13:55 < mihi> but these dests are not used yet ;)
            
-
            13:55 < jrandom> w3rd.  yeah, there *is* the big caveat that having lots of destinations on one router does increase CPU load nontrivially
            
-
            13:55 < jrandom> (since any garlic fail will need to fail once per dest before failing completely)
            
-
            13:56 < jrandom> there is some magic left that can be used to minimize that though, i think
            
-
            13:56 < deer> <ughabugha> Are you sure the transparent squid proxying is a good idea in the performance point of view? I mean, people might get too lazy and not take their eepproxy off after browsing I2P sites or using I2P squid, therefore wasting I2P bandwidth for things that don't require anonymity.
            
-
            13:56 < jrandom> ughabugha> all things require anonymity :)
            
-
            13:57 < jrandom> (and if they can't tell the difference, well, sheeit...)
            
-
            13:57 < mihi> my intention for httptunnel is that http links will be rewritten (similarly to fproxy) so that you don't need a proxy but only a servlet.
            
-
            13:57 < deer> <ughabugha> jrandom: Heh. That way, I2P was born dead. There isn't going to be enough available bandwidth on the network, that all the endnodes would likely consume.
            
-
            13:58 < mihi> on that info page one might add a feature to browse the site throufh e.g. squid.
            
-
            13:58 < jrandom> not quite sure i follow.  i do understand and agree with the DNS issues involved (though i think we can get around them a few ways)
            
-
            13:58 < jrandom> ah, ok mihi
            
-
            13:58 < deer> <aum> morning all
            
-
            13:58 < jrandom> mihi> so like a much much more advanced "Unable to reach peer" page?
            
-
            13:59 < mihi> more like a "anonymity warning" page like in freenet ;)
            
-
            13:59 < jrandom> ughabugha> if we cant handle web browsing, how are we going to handle BT/filesharing?
            
-
            13:59 < jrandom> hmm mihi, but do we want that, for people who want to browse the web anonymously?  or would httpclient not be the app they'd use?
            
-
            14:00 < jrandom> 'mornin aum, just in time for the dev meeting :)
            
-
            14:00 < mihi> jrandom: if someone just wants to browse the web anonymously, he
            
-
            14:00 < deer> <ughabugha> jrandom: Hmm... Good point. Are we going to at all? ;)
            
-
            14:00 < deer> <aum> jrandom: you're not on iip, you're not on irc.duck.i2p ?!?
            
-
            14:00 < jrandom> ughabugha> we must.
            
-
            14:01 < mihi> might configure httptunnel to so so (httptunnel will still work as a proxy, so it's quite trivial to add that)
            
-
            14:01 < mihi> and most likely someone browsing the web "anonymously" will like some content filters, i guess ;)
            
-
            14:01 < jrandom> mihi> i think human already did :)
            
-
            14:01 < jrandom> agreed mihih
            
-
            14:01 < jrandom> /hih/hi/
            
-
            14:02 < mihi> when i say httptunnel, i don't mean httpclient ;)
            
-
            14:02 < jrandom> ah ok
            
-
            14:02 < deer> <jrandom_> i'm here aum ;)
            
-
            14:02 < mihi> but we *really* should move i2ptunnel to use the streaming api ASAP, which will reduce the number of files we must maintain
            
-
            14:03 < jrandom> agreed
            
-
            14:03 < mihi> human only patched the old version, i patched the new version myself
            
-
            14:03 < jrandom> we ran into some bugs this afternoon, not sure if human bounced you logs yet
            
-
            14:03 < deer> <wilde> another thing for the list: outproxy was taken, but more like i2p2i
            
-
            14:04 < mihi> i did not get logs yet from anyone...
            
-
            14:04 < jrandom> mihi> we'll get on to the streaming code asap, we can talk about it after the meeting if you've got a moment, or over email?
            
-
            14:04 < deer> * aum spent part of yesterday looking at p2p apps with a view to running them on i2p
            
-
            14:04 < jrandom> wilde> hmm?
            
-
            14:04 < jrandom> wikked aum, anything promising?
            
-
            14:04 < deer> * aum is presently inclined to favour 'push'-type filesharing, eg konspire2b
            
-
            14:05 < jrandom> i2psnark could be modified to use the new i2ptunnel streaming api fairly easily too
            
-
            14:05 < deer> <human> mihi: sending the logs (mihi@i2p.net, right?)
            
-
            14:06 < mihi> dunno if mihi made a redirect for me
            
-
            14:06 < deer> <mihi> s/mihi/jrandom
            
-
            14:06 < jrandom> hmm aum, do you think that freenet/insert model really would work most effectively?
            
-
            14:06 < deer> <wilde> jrandom: i was thinking of using a i2p webserver -> proxy -> internet, so people can browse a i2p site, but maybe an ordinary tunnel can manage the traffic
            
-
            14:06 < jrandom> mihi> want me to set that to for ward to you?
            
-
            14:06 < mihi> jrandom: nothing against it ;)
            
-
            14:07 < deer> <ughabugha> aum: 'Push'-type? What's that?
            
-
            14:07 < deer> <aum> what i like about konspire2b is it takes away the expectation for instant/prompt delivery, and reduces bandwidth requirement, by only broadcasting content announcements, then letting people 'subscribe' to 'content feeds'
            
-
            14:07 < jrandom> mihi> done.
            
-
            14:08 < deer> <aum> so instead of requesting a file, sitting and twiddling your thumbs, getting pissed off waiting for it to come in, you just 'subscribe' to the source's 'channel', then get on with other stuff
            
-
            14:08 < deer> <aum> konspire2b.sf.net
            
-
            14:08 < jrandom> aum> but isn't that incredibly innefficient, since you've got to manage an overlay network (broadcast) for list of things available, then you've got to relay them?
            
-
            14:09 < jrandom> wouldn't a direct swarming system be much more useful / efficient?
            
-
            14:09 < deer> <ughabugha> Heh. That sounds promising for I2P.
            
-
            14:09 < deer> <aum> jrandom: any examples of direct swarming?
            
-
            14:09 < jrandom> wilde> oh, so like the cgiproxy on duck and janonymous's site?
            
-
            14:09 < jrandom> aum> bittorrent
            
-
            14:10 < deer> <ughabugha> aum: Did you mean http://konspire.sourceforge.net/?
            
-
            14:10 < jrandom> where you get the torrent somewhere, and get content blocks directly from peers who have it
            
-
            14:10 < deer> <aum> ughabugha: guess so :)
            
-
            14:10 < mihi> argl... $me->brother removed the port forward for i2p...
            
-
            14:10 < jrandom> d'oh
            
-
            14:10 < deer> <aum> jrandom: is anyone currently trying bt/i2p?
            
-
            14:11 < deer> <baffled> aum, have you had a close look at mnet?
            
-
            14:11 < jrandom> aum> eco made some headway with i2psnark
            
-
            14:11 < deer> <aum> i've had a look, but not a close look
            
-
            14:11 < jrandom> (though he's mia at the moment)
            
-
            14:12 < jrandom> hmm, mnet with eepsite metatrackers and human's i2p/twisted transport might work
            
-
            14:12 < deer> <duck> heavy testing by janonymous and me seem to show that the current i2psnark problems are 50% caused by i2p and 50% by snark
            
-
            14:12 < jrandom> duck> how recently were those tests?
            
-
            14:12 < deer> <duck> last week
            
-
            14:12 < jrandom> though i've got no qualms with potentially exploring other bt implementations
            
-
            14:12 < jrandom> ah ok
            
-
            14:13 < deer> <duck> about mnet, I _think_ that you'd first to fix mnet itself before you could make that working
            
-
            14:13 < deer> <duck> so you might as wel fix freenet and use that
            
-
            14:13 < jrandom> heh
            
-
            14:13 < deer> <aum> fix freenet, ok! right after we bring in world peace ;p
            
-
            14:13 < deer> <duck> but ask in #mnet @ freenode
            
-
            14:13 < deer> <Pellinore> mnet=?
            
-
            14:13 < deer> <Pellinore> Mute?
            
-
            14:14 < jrandom> in that sense, perhaps an azureus mod for i2p might work?
            
-
            14:14 < deer> <wilde> no, a market based p2p approach
            
-
            14:14 < jrandom> pellinore - mnet.sf.net, a distributed data store without anonymity
            
-
            14:14 < deer> <baffled> Actually, I'm using mnet quite reliably on about five machines.
            
-
            14:14 < jrandom> right, the mojonation followon
            
-
            14:14 < deer> <baffled> I can't use freenet reliably on one machine.
            
-
            14:14 < deer> <duck> baffled: 0.6 or 0.7?
            
-
            14:14 < deer> <duck> (0.7 is with twisted iirc)
            
-
            14:16 < deer> <Pellinore> jrandom -- thanks.
            
-
            14:16 < deer> <Pellinore> You can't use Freenet reliably on any machine.
            
-
            14:17 < deer> <baffled> 0.6.[23].
            
-
            14:17 < deer> <Pellinore> That is, among other reasons, why we are here. :)
            
-
            14:17 < deer> <aum> i find that entropy works well... eventually!
            
-
            14:17 < jrandom> i don't know, i still think freenet might be a good base to work from for the i2p DHT (when we can cut out most of the code and keep the data store / SSK/CHK stuff)
            
-
            14:18 < jrandom> for file sharing, we should learn from the filesharing crowd what works best
            
-
            14:18 < deer> <aum> but since my linuxworld article on entropy, there's gazillions of entropy nodes now, and the net has taken on some freenet performance characteristics
            
-
            14:18 < deer> <Pellinore> I like the basic layout and features of Freenet, it's just that the fucker doesn't work, especially if one is using a dialup connection.
            
-
            14:18 < jrandom> e.g. DC clones, BT, [or what else do those crazy filesharing people use?]
            
-
            14:19 < jrandom> heh aum, damn you ;)
            
-
            14:19 < deer> <duck> plus there are the things that Newsbyte did identify about entropy...
            
-
            14:19 < deer> <aum> it's weaker anonymity, for example?
            
-
            14:19 < deer> <baffled> Right but there are instability issues with 0.7.
            
-
            14:19 < deer> <baffled> I think this connection has gotten flakey again.
            
-
            14:19 < jrandom> and security issues.  i think we can unfortunately pass on using entropy
            
-
            14:21 < jrandom> but, erm, we're on discussion point 4, *web* architecture so for the moment lets jump back to that ;)
            
-
            14:21 < deer> <aum> another mad-assed file-sharing idea - what about using nntp, with n people running linked nntpds, and just use one of those libs that breaks down files into b64 chunks and posts them, and libs to retrieve them?
            
-
            14:22 < jrandom> NNTP would be really interesting - its reliable as fuck and time tested
            
-
            14:22 < deer> <duck> linking the servers?
            
-
            14:22  * jrandom would love to have an innd running with i2p ;)
            
-
            14:23 < deer> <aum> and since i2p does the anonymity, there's no need for nntp to have it
            
-
            14:23 < jrandom> right, the innd feed line could point at a local i2ptunnel proxy
            
-
            14:23 < deer> <aum> and people with different servers can config the servers to cache their own choice of groups
            
-
            14:23 < mihi> depending on how often they peer it would be possible to censor articles by creating message id collisions
            
-
            14:23 < deer> <duck> (ever tried configuring innd?)
            
-
            14:24 < jrandom> many times duck, but a loooong time ago
            
-
            14:24 < deer> <aum> is innd hard to setup?
            
-
            14:24 < deer> <duck> oh well, you are god
            
-
            14:24 < jrandom> mihi> agreed - thats not a censorship proof distribution medium
            
-
            14:24 < jrandom> aum> its a bitch
            
-
            14:25 < jrandom> just like squid - its good at what it does, but we likely need something dirt simple (one click, hopefully) to bundle
            
-
            14:25  * jrandom drags us back on topic
            
-
            14:26 < deer> <aum> and yet another p2p/filesharing approach - i seem to recall seeing a p2p app that works via http, chaining http servers
            
-
            14:26  * mihi guesses most users don't know how to set up a proxy in their brwoser...
            
-
            14:26 < deer> <aum> sorry, what's the topic?
            
-
            14:26 < jrandom> agenda item 4) web architecture ;)
            
-
            14:26 < aum> as in, web servers within i2p?
            
-
            14:26 < mihi> aum: yep
            
-
            14:26 < jrandom> thats a good point mihi - a web system will want the basics (.bat, .sh scripts) for startup/shutdown
            
-
            14:27 < jrandom> hmm, doesn't mozilla include a javascript url you can do to set the proxy?
            
-
            14:27 < jrandom> e.g. could we have a config page on httptunnel to click "on"/"off"?
            
-
            14:28 < jrandom> i realize we're not going to come to any decisions today about how the web functionality should work, but we should get some directions down
            
-
            14:28 < aum> what's the problem with the current eepproxy setup?
            
-
            14:29 < jrandom> e.g. filtering, inbound proxies (eeproxies), outbound servers (normal i2ptunnel server), outbound proxies (outproxies ala squid or tor-www)
            
-
            14:29 < mihi> aum: it requires quite some skill both to provide and to request eepsites
            
-
            14:29 < jrandom> also, the existing outproxy system sucks.
            
-
            14:29 < jrandom> its wholely unscalable
            
-
            14:29 < jrandom> we need something to allow/force distributing the outbound web request load across multiple outproxies
            
-
            14:30 < mihi> how can users get these outproxies. config file (like in hosts.txt?)
            
-
            14:30 < jrandom> and one reason why normal people would want to run outproxies is for plausible deniability - even if THEY are requesting "bad stuff", they can say "i2p did it"
            
-
            14:31 < jrandom> thats one option mihhi
            
-
            14:31 < mihi> jrandom: hehe
            
-
            14:31 < jrandom> s/hh/h/
            
-
            14:31 < aum> but doesn't eepproxy make 'direct' http connection to the requested server, ie as 'direct' as i2p connections are?
            
-
            14:31 < deer> <wilde> . /castvote DHT ala Freenet
            
-
            14:31 < mihi> aum: the problem are "normal" web urls.
            
-
            14:31 < jrandom> ./castvote 3 developers x 1 month x 12h / day
            
-
            14:32 < deer> * human added httptunnel support to the TunnelManager, btw
            
-
            14:32 < deer> <human> s/httptunnel/httpclient/
            
-
            14:32 < deer> <aum> what's that?
            
-
            14:32 < deer> <aum> oh, http client support?
            
-
            14:32 < deer> <human> aum: yes
            
-
            14:32 < jrandom> right, we need to find a way to let people browse slashdot.org via i2p
            
-
            14:32 < deer> <aum> so tunnelmgr now talks http?
            
-
            14:32 < jrandom> nice1 human!
            
-
            14:32 < jrandom> aum> remember the squid proxy?
            
-
            14:33 < deer> <aum> yep
            
-
            14:33 < deer> <wilde> jrandom: so 4 man-months roughly for a DHT?
            
-
            14:33 < deer> <human> aum: yup: openhttpclient <port> [<outbound WWW proxy>]
            
-
            14:33 < jrandom> wilde> i think thats reasonable, yes.
            
-
            14:34 < deer> <aum> human: have you written it up anywhere?
            
-
            14:35 < jrandom> aum> all it does is say "if !eepsite { send through $outboundWWWproxy } else {send to eepsite}"
            
-
            14:35 < deer> <human> aum: i was going to commit, then i got stuck with a StreamingI2PTunnelServer bug...
            
-
            14:36 < jrandom> a good short term solution would be a "outproxies.txt", ala hosts.txt
            
-
            14:36 < deer> <aum> human: and what exactly does 'openhttpclient <port> [<outbound WWW proxy>]' do?
            
-
            14:36 < jrandom> though we should start thinking about medium and long term solutions
            
-
            14:37 < deer> <human> human: will open a proxy listening for connections, that will redirect to WWW-proxy all the stuff that goes to URLS not ending with .i2p
            
-
            14:38 < deer> <Pellinore> Now that's interesting.
            
-
            14:38 < deer> <aum> human: ahh, nice, so you split off a thread within tunnelmgr?
            
-
            14:38 < deer> <human> human: i.e. you can use it to browse both eepsite and the normal web
            
-
            14:38 < deer> <human> human: yes
            
-
            14:38 < deer> <human> s/human/aum/ :-)
            
-
            14:39 < deer> <aum> slightly outside the 'brief' of tunnelmgr, but hey, there's no other place more appropriate in the i2p code - good job d00d
            
-
            14:39 < deer> <aum> human: so you talk python *and* java? is that damaging your brain?
            
-
            14:39 < deer> <human> aum: i did it to avoid launching yet another JVM for the EepProxy
            
-
            14:40 < jrandom> (well, the code is implement in i2ptunnel's httpclient, human just recently exposed it through tunnelmanager as well)
            
-
            14:40 < deer> <aum> yes, always good to keep the jvm instances down to a minimum
            
-
            14:40 < jrandom> ((and imho httpclient is exactly where it should go ;)
            
-
            14:40 < jrandom> (((until mihi's NextGen httpclient [httptunnel] is out)))
            
-
            14:41 < deer> <aum> is httpclient in cvs, such that it'll build for me as part of i2p update/build?
            
-
            14:41 < jrandom> yes, eepProxy uses httpclient
            
-
            14:42 < deer> <aum> *man this is so schizophrenic - i've got 3 xchat sessions open (irc.duck.i2p,iip,freenode)) 
            
-
            14:42 < jrandom> :)
            
-
            14:42 < deer> <aum> wicked latency on irc.duck.i2p
            
-
            14:42 < jrandom> ok, so no closure on the web architecture today, obviously, but worthwhile discussion
            
-
            14:43 < jrandom> yeah aum, 15s or so for me
            
-
            14:43 < jrandom> anything else on the web architecture for now, or should we move on to the 5) ??? open discussion section?
            
-
            14:43 < deer> * human is thinking about an I2PSocksTunnel
            
-
            14:44 < jrandom> yikes, now that'd be cool
            
-
            14:44 < deer> <human> (well, maybe it belongs to 5)
            
-
            14:44 < deer> <aum> socks? is there a way to 'shim' non-socks-enabled clients through to a socks interface?
            
-
            14:44 < deer> <human> aum: apt-get install tsocks :-)
            
-
            14:45 < aum> web discussion - one last thing - what about possibly forking /patching an existing web client
            
-
            14:45 < mihi> aum: sockscap for windwos
            
-
            14:45 < jrandom> aum> scary.  very powerful, but scary.
            
-
            14:45 < jrandom> [i'd hate to have to maintain that]
            
-
            14:45 < aum> even for now, a brain-dead browser like dillo
            
-
            14:46 < jrandom> [[though it could be made 'uber secure', etc.  but still, very, very scary]]
            
-
            14:46 < aum> or better, the browser control in wxwindows, it's multiplatform
            
-
            14:46  * jrandom reminices about the orignial flinks, when it had a built in freesite browser
            
-
            14:47 < aum> but then again, n00bs will whinge if they can't surf their usual m$-specific-javascript-infested sites
            
-
            14:47 < jrandom> right aum, and so will hackers if it doesnt support the latest standards compliant code
            
-
            14:47 < aum> hey, we should ask Microsoft for the source to IE6, then patch it ;p
            
-
            14:47 < jrandom> building a browser == good way to waste thousands of man-hours
            
-
            14:47 < jrandom> heh
            
-
            14:47 < deer> * human is quite happy using privoxy
            
-
            14:48 < aum> maybe they might toos in ie6 source as part of the European punitive settlement
            
-
            14:48 < deer> <human> (http://www.privoxy.org/)
            
-
            14:48 < aum> s/toos/toss/
            
-
            14:48 < jrandom> human> how would that fly for both sides of the proxy?
            
-
            14:48 < jrandom> e.g. we'll want the content filtered locally, not at the outbound endpoint
            
-
            14:49 < deer> <human> jrandom: users could be encouraged to install it
            
-
            14:49 < jrandom> (but the outbound endpoint will want to filter some content to avoid abuse, etc)
            
-
            14:49 < deer> <human> jrandom: or it may be part of the default I2P installation
            
-
            14:49 < aum> what if a DWP (distrib web proxy) was using a DHT for its cache?
            
-
            14:49 < jrandom> encourage == only geeks.  bundle :)
            
-
            14:49 < jrandom> that'd be Good aum
            
-
            14:49 < deer> <human> jrandom: eheheh, agreed :-)
            
-
            14:49 < deer> <human> jrandom: privoxy also runs on windogs, btw
            
-
            14:50 < jrandom> word.  yeah, we need some sort of content filtering - privoxy, muffin, whatever.
            
-
            14:50 < deer> <wilde> long meeting...
            
-
            14:50  * jrandom takes the hint..
            
-
            14:51 < deer> <Pellinore> wilde: Much to be said.
            
-
            14:51 < jrandom> anyone else have anything they want to bring up?  we always have the mailing list for further things
            
-
            14:51 < deer> <Pellinore> And much to be done of course.
            
-
            14:51 < deer> <Pellinore> I have a couple of small questions.
            
-
            14:51 < aum> could we fork privoxy and 1) make it work over i2p, 2) make it use DHT for caching?
            
-
            14:51 < deer> <Pellinore> But they are as easily taken up privately.
            
-
            14:51 < jrandom> pellinore> whats up?
            
-
            14:51 < deer> <Pellinore> Nada, sorry I said anything.
            
-
            14:51 < jrandom> aum> most likely we wouldnt need to fork
            
-
            14:52 < deer> <Pellinore> I'll talk to you about it privately, or duck, at another time.
            
-
            14:52 < deer> <Pellinore> Not really dev-specific stuff.
            
-
            14:52 < deer> <duck> 10+16+7=33 manhours wasted on this one-hour overtime :)
            
-
            14:52 < jrandom> but building a DHT is a lot of effort.  wholely incredibly worthwhile
            
-
            14:52 -!- Irssi: #i2p: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal]
            
-
            14:52  * aum goes again to visit infoanarchy.org wiki pages on DHTs
            
-
            14:52 < jrandom> there are 16 people on iip?
            
-
            14:53 < deer> <human> aum: no need to fork, just: web browser <-> privoxy <-> httpclient <-> i2p <-> outbound proxy <-> www.pr0n.com
            
-
            14:53 < deer> <wilde> a generic DHT that would work outside I2P too, and that allows other binding than http
            
-
            14:53 < jrandom> aum> check out the link duck added to the i2p wiki, listing various ones
            
-
            14:54 < deer> <human> aum: you can configure privoxy to make it connect to another HTTP/socks proxy (that's how my I2P-to-tor privoxy works)
            
-
            14:54 < deer> <duck> (http://www.bamboo-dht.org/)
            
-
            14:54 < aum> not sure i like the idea of a dht working outside i2p - the best dht is one without anonymity (and the anonymity overhead) that can work most optimally within i2p
            
-
            14:54 < jrandom> hrm duck, what happened to that list of 'em?
            
-
            14:54 < deer> <duck> aum: easier to test
            
-
            14:55 < deer> <duck> jrandom: some commie did remove it I guess
            
-
            14:55 < jrandom> heh
            
-
            14:56 < jrandom> google++ : http://www.etse.urv.es/~cpairot/dhts.html
            
-
            14:56 < jrandom> (not the same page, but interesting)
            
-
            14:56 < jrandom> oh, here's the page - http://himalia.it.jyu.fi/ffdoc/storm/pegboard/available_overlays--hemppah/peg.gen.html
            
-
            14:57 < jrandom> but yes, a DHT that doesnt try to implement anonymity, plus a DHT that supports both CHK-style and SSK style content would be best
            
-
            14:58 < jrandom> (SSK style not being strictly necessary, but damn it would be really useful)
            
-
            14:58 < jrandom> but, anyway
            
-
            14:58 < jrandom> anyone got anything else they want to bring up?
            
-
            14:59 < deer> <duck> tomorrow is St. Patrick's Day
            
-
            14:59 < deer> <wilde> topic 5) ?
            
-
            14:59 < deer> <duck> so all drink irish beer
            
-
            14:59 < jrandom> good point
            
-
            14:59 < deer> <Pellinore> TOmorrow is both the anniversary of my current relationship, and of my second marriage.
            
-
            14:59  * jrandom takes note to avoid irish pubs tomorrow
            
-
            15:00 < jrandom> oh, congrats pellinore :)
            
-
            15:00 < jrandom> wilde> we're on 5) ???
            
-
            15:01 < jrandom> (and about to be on 6) [baf])
            
-
            15:01  * jrandom will be coming to iip momentarily [if i can]
            
-
            15:01  * jrandom winds up
            
-
            15:01  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting82.html b/www.i2p2/pages/meeting82.html
deleted file mode 100644
index 408daf5f..00000000
--- a/www.i2p2/pages/meeting82.html
+++ /dev/null
@@ -1,470 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 82{% endblock %}
-{% block content %}
            Tuesday, Mar 23, 2004 13:00:00 PST
            
-
            
-
            [22:01:22] <jrand0m> agenda:
            
-
            [22:01:22] <jrand0m> 0) Hi
            
-
            [22:01:22] <jrand0m> 1) Network status
            
-
            [22:01:28] <jrand0m> 2) 0.3.1 plan
            
-
            [22:01:28] <jrand0m> 3) Web architecture
            
-
            [22:01:28] <jrand0m> 4) Administravia
            
-
            [22:01:34] <jrand0m> 5) ???
            
-
            [22:01:38] <jrand0m> 0) hi
            
-
            [22:01:39] <no_dammagE> of yourse
            
-
            [22:01:43] <ughabugha> Oh, cool, the meeting. :)
            
-
            [22:01:51] <jrand0m> hi, welcome to the weekly dev meeting, number $something
            
-
            [22:01:56] <ughabugha> Hi.
            
-
            [22:02:02] <jrand0m> weekly status notes up at http://i2p.net/pipermail/i2p/2004-March/000180.html
            
-
            [22:02:09] * mihi has joined #i2p
            
-
            [22:02:13] <fidd> howdy
            
-
            [22:02:32] <jrand0m> we'll see if we can avoid a 2 hour session today ;)
            
-
            [22:02:39] <jrand0m> ok, jumping to 1) network status
            
-
            [22:02:43] <Masterboy> :P
            
-
            [22:02:56] <jrand0m> we got 0.3.0 out on sunday, and its generally functional
            
-
            [22:03:12] <Masterboy> yes it is:)
            
-
            [22:03:23] <ox> * jrandom waves from i2p#i2p to prove it ;)
            
-
            [22:03:43] <jrand0m> there are still some bugs to fix, and a new set of things to be addressed, but ever onwards we go
            
-
            [22:04:21] * ion has joined #i2p
            
-
            [22:04:22] * ughabugha is reading the status notes.
            
-
            [22:04:27] * mrflibble has quit IRC (r eboot time)
            
-
            [22:04:35] <jrand0m> in the email i mention a new network monitoring tool duck put together - http://duck.i2p/dot/dot.png (or a snapshot at http://i2p.net/~jrandom/profiles.png)
            
-
            [22:05:05] <jrand0m> it basically gives us a view into how the network is doing - how many people are out there, and how well they're finding out about reliable and fast resources
            
-
            [22:05:22] <jrand0m> (basically it visualizes the result of the 0.3 peer profiling and selection process)
            
-
            [22:05:50] <ox> <duck> nice!
            
-
            [22:06:22] <jrand0m> yeah, its nice to see the visual feedback on the algorithms, rather than manually going through the networkDb
            
-
            [22:06:37] <ox> <Masterboy> there's a need of cpu usage decreasing..
            
-
            [22:06:38] <fidd> :)
            
-
            [22:06:48] * jrand0m gives the eepSiteAppOfTheWeek award to duck for dot.png
            
-
            [22:06:54] <ughabugha> Yeah, I wonder what would we be doing without duck?
            
-
            [22:07:08] <ox> <duck> maybe we can make an audio version too
            
-
            [22:07:17] <fidd> haha
            
-
            [22:07:20] <jrand0m> :)
            
-
            [22:07:22] <human> heheh
            
-
            [22:07:34] <fidd> or a smell-one
            
-
            [22:07:47] <ughabugha> Yeah, and stream it over jnon's icecast every hour.
            
-
            [22:07:51] <no_dammagE> how do I understand the speed column in #transport?
            
-
            [22:08:00] <no_dammagE> I mean peer profiles
            
-
            [22:08:25] <jrand0m> no_dammagE> good question.  if you read the bottom text below, it explains that the numbers have no correlation with anything - they're strictly relative values.
            
-
            [22:08:50] <no_dammagE> ok :)
            
-
            [22:09:15] <jrand0m> if you want the *real* answer, see http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/router/java/src/net/invisiblenet/i2p/router/peermanager/SpeedCalculator.java?rev=1.3&content-type=text/x-cvsweb-markup
            
-
            [22:10:07] <jrand0m> the network has also grown to a steady 18-22 routers, which is a good size for the moment
            
-
            [22:10:31] <jrand0m> we'll want to grow a bit more once some of the existing bugs are dealt with, and the 0.3.1 phttp code is in place
            
-
            [22:10:36] <KyroxX> re
            
-
            [22:10:45] <jrand0m> wb KyroxX
            
-
            [22:11:03] <jrand0m> ok, that leads us into 2) 0.3.1 plan
            
-
            [22:11:16] <no_dammagE> mine will go off in 30 minutes and will go on in ~ 20 hours (or ill make it on the autostart so that it will be started with the PC)
            
-
            [22:11:29] <jrand0m> cool no_dammagE, thats fine
            
-
            [22:11:33] * fR has quit IRC (Ping timeout)
            
-
            [22:12:01] <jrand0m> rather than get the phttp code, the bandwidth limiter, and the new collusion deterrent all in one 0.3.1 release, i'm pushing the collusion deterrent into 0.3.2
            
-
            [22:12:19] <jrand0m> roadmap hasn't yet been updated, but things are pretty much the same
            
-
            [22:12:45] * fR has joined #i2p
            
-
            [22:13:17] <ughabugha> Are you going to release 0.3.0.1?
            
-
            [22:13:18] <jrand0m> there's going to be some complex stuff in the phttp revamp, dealing with throttling the connections, but we'll see how it goes
            
-
            [22:13:36] * KyroxX has quit IRC (Verlassend)
            
-
            [22:13:47] <jrand0m> perhaps, though currently the roadmap lists 0.3.1 as next week
            
-
            [22:13:54] <jrand0m> sunday, even.
            
-
            [22:14:01] <ox> <baffled> I knew you was in collusion with somebody.
            
-
            [22:14:02] <jrand0m> so i'm not sure
            
-
            [22:14:03] * Rom|Away|3h has quit IRC (Ping timeout)
            
-
            [22:14:04] <Masterboy> how can i limit the cpu usageof my router? why not make : "low" - "normal" - "high" - so you could choose?
            
-
            [22:14:10] <jrand0m> heh baff
            
-
            [22:14:11] <no_dammagE> why is that critical?:
            
-
            [22:14:11] <no_dammagE> 21:55:36.249 CRIT  [I2CP Reader ] et.invisiblenet.i2p.util.Clock: Updating clock
            
-
            [22:14:12] <no_dammagE>  offset to 105791ms from 0ms
            
-
            [22:14:16] * Romster has joined #i2p
            
-
            [22:14:24] * jar has quit IRC (Ping timeout)
            
-
            [22:14:38] <jrand0m> Masterboy> the code to work along those lines is planned for the 1.0rc1 release
            
-
            [22:14:43] <jrand0m> (router throttling)
            
-
            [22:14:48] * KyroxX has joined #i2p
            
-
            [22:14:50] <jrand0m> we've got some basics, but its not ready yet.
            
-
            [22:15:08] <KyroxX> re
            
-
            [22:15:13] <jrand0m> no_dammagE> because it should only occur at most once - if you see it happening a lot, its an issue
            
-
            [22:15:14] <Masterboy> oki
            
-
            [22:15:21] <jrand0m> (a critical issue)
            
-
            [22:15:48] <jrand0m> any other questions / concerns on the 0.3.1 release?
            
-
            [22:15:55] <mihi> then it should be debug the first time and then crit...
            
-
            [22:16:06] <jrand0m> you're right
            
-
            [22:16:09] <KyroxX> whats the topic?
            
-
            [22:16:17] <ughabugha> jrand0m: Err.. How can this occur on I2P? Closing Link: [unknown@192.168.0.2] (Ping timeout)
            
-
            [22:16:31] <jrand0m> KyroxX> the weekly dev meeting, item 2) 2) 0.3.1 plan
            
-
            [22:16:35] <ughabugha> Ah, never mind.
            
-
            [22:16:40] <jrand0m> ughabugha> ircd patch
            
-
            [22:16:49] <KyroxX> ah
            
-
            [22:17:02] <ox> <duck> my ircd is running on nsa.localdomain
            
-
            [22:17:06] <jrand0m> hmm
            
-
            [22:17:08] <ox> <duck> which has 192.168.0.2 as IP
            
-
            [22:17:12] <jrand0m> ah
            
-
            [22:17:30] * Romster has quit IRC (Ping timeout)
            
-
            [22:17:32] <jrand0m> ok, moving on to 3) Web architecture
            
-
            [22:17:49] * ion has quit IRC (Ping timeout)
            
-
            [22:17:58] <jrand0m> i know we discussed this last week a bit, and there's been some discussion on the mailing list about it too
            
-
            [22:18:02] <mihi> how can i make an account on drupal.i2p.net?
            
-
            [22:18:15] * mihi is too stupid for that...
            
-
            [22:18:16] <jrand0m> wilde> can you add one for mihi?
            
-
            [22:18:31] <jrand0m> (there's no way to register normally)
            
-
            [22:18:35] <mihi> jrand0m: you could simply say no, then i know i can stop trying ;)
            
-
            [22:18:42] <jrand0m> if wilde isn't around, i'll add one for you momentarily :)
            
-
            [22:18:51] * Romster has joined #i2p
            
-
            [22:19:04] * Romster is now known as Rom|Away|3h
            
-
            [22:19:18] <fidd> i'd like one too if its ok :)
            
-
            [22:21:05] <ox> <jmand> /ping jmand
            
-
            [22:21:12] <jrand0m> ok, back to the web arch stuff
            
-
            [22:22:06] <jrand0m> there are several different aspects of "how we use the web" in i2p, and we can either treat them all as OneBigWebThingy, or we can talk about specializing the components, making things that do their OneThingWell
            
-
            [22:22:34] * ion has joined #i2p
            
-
            [22:22:44] <jrand0m> mihi brought up some good points that I hadn't been looking at, some valuable features that we'll certainly want
            
-
            [22:23:03] <ughabugha> jrand0m: Are you talking about the separation of Squid and I2P web?
            
-
            [22:23:11] <ughabugha> Or something deeper?
            
-
            [22:23:24] <duck> the 'HTTPTunnel vs. {privoxy,muffin} + HTTPClient' thread
            
-
            [22:23:30] <duck> (http://i2p.dnsalias.net/pipermail/i2p/2004-March/)
            
-
            [22:23:48] <jrand0m> the seperation of squid and eepsites, as well as the seperation of browser proxies vs. (essentially) cgis
            
-
            [22:23:49] <ughabugha> Right.
            
-
            [22:24:00] <jrand0m> and, of course, the filters
            
-
            [22:24:48] <jrand0m> since we all work in the open source world here, there's no real need to have OneBigThing that deals with all of the different use cases - we can build one to address a need, then reuse its code for another to address another need
            
-
            [22:24:56] * jar has joined #i2p
            
-
            [22:25:04] <duck> I tend to agree with human's latest post
            
-
            [22:25:13] <jrand0m> plus, with mihi's new streaming I2PTunnel api, its fairly easy to build off
            
-
            [22:26:42] <jrand0m> as do i, though i don't have the time to work on httptunnel, so its really up to mihi as to what use case he's most interested in addressing first
            
-
            [22:26:48] * lucky has joined #i2p
            
-
            [22:27:45] * jar has quit IRC (EOF From client)
            
-
            [22:27:52] <jrand0m> mihi> any thoughts?
            
-
            [22:28:26] <jrand0m> ok or anyone else?  :)
            
-
            [22:28:47] <duck> http://i2p.i2p/ looks ugly to me
            
-
            [22:28:55] <duck> but even that could be survived
            
-
            [22:28:59] <jrand0m> i2p.i2p?
            
-
            [22:29:05] <human> ?
            
-
            [22:29:27] * ion has quit IRC (Ping timeout)
            
-
            [22:29:28] <jrand0m> i could add in a dns entry for eep.i2p.net pointing to 127.0.0.1 for machines that do bad dns things
            
-
            [22:30:01] * fR has quit IRC (EOF From client)
            
-
            [22:30:20] * human didn't get the latest proposal :-)
            
-
            [22:30:27] <duck> I think I did see i2p.i2p mentioned somewhere as replacement for the current http://i2p/keybla
            
-
            [22:30:35] <jrand0m> yours was the latest human
            
-
            [22:30:54] <jrand0m> oh, right, yeah on irc last night i think jnano was discussing it
            
-
            [22:30:55] <human> jrand0m: i mean: "i could add in a dns entry for eep.i2p.net pointing to 127.0.0.1 for machines that do bad dns things"
            
-
            [22:31:03] <mihi> duck: you have good eyes. i did this to prevent netbios lookups in Opera.
            
-
            [22:31:21] <duck> ah yeah "code/apps/i2ptunnel/java/src/net/invisiblenet/i2p/httptunnel/handler/RootHandler.java"
            
-
            [22:31:21] <jrand0m> ah sorry human, i meant that with regards to what mihi just said :)
            
-
            [22:31:23] * lucky has quit IRC (Ping timeout)
            
-
            [22:31:49] <duck> it is a shame that some browsers need such workarounds
            
-
            [22:31:55] <human> wew
            
-
            [22:32:15] <jrand0m> human mentioned something about socks4 not requiring that?
            
-
            [22:32:15] * KyroxX is now known as wbk
            
-
            [22:32:23] <duck> socks4a
            
-
            [22:32:29] <jrand0m> ah ok
            
-
            [22:32:39] <duck> (socks4 does DNS)
            
-
            [22:32:49] <jrand0m> do all browsers support socks4a?
            
-
            [22:32:59] <human> jrand0m: socks4 is Evil(TM), but socks4a and socks5 delegate name resolution to the server
            
-
            [22:33:00] <duck> s/socks4 does DNS/with socks4 the client does DNS/
            
-
            [22:33:06] <mihi> some browsers don't even support socks proxies...
            
-
            [22:33:08] <human> jrand0m: yes, AFAIK
            
-
            [22:33:27] <jrand0m> right, plus the kiosk issue mihi, certainly
            
-
            [22:33:52] <duck> it could be an alternative
            
-
            [22:34:04] <duck> httpclient + socksclient + etc
            
-
            [22:34:29] <human> jrand0m, mihi: programs that don's support socks could be tsocks'ed
            
-
            [22:34:53] <jrand0m> human> unless its a kiosk, where people can't run apps
            
-
            [22:35:00] <jrand0m> (or change settings, etc)
            
-
            [22:35:19] <human> jrand0m: yes, of course socks tunnels aren't suited for these tasks
            
-
            [22:35:31] <duck> (human: though then they'd still call gethostbyname)
            
-
            [22:35:39] <jrand0m> would they duck?
            
-
            [22:35:55] <human> duck: no, tsocks even inhibits them and forwards them to the proxy server
            
-
            [22:36:16] <human> duck: (dunno what happens in the windows world, though)
            
-
            [22:36:30] <jrand0m> they BSOD
            
-
            [22:36:32] <jrand0m> er..
            
-
            [22:36:57] <duck> (not according to /usr/share/doc/tor-0.0.2_pre27/CLIENTS.gz)
            
-
            [22:36:57] <human> heheheh
            
-
            [22:37:07] <jrand0m> heh duck
            
-
            [22:37:18] <human> socks tunnels, however, will not replace www proxies :-)
            
-
            [22:37:24] <duck> (( </tortechnotalk> ))
            
-
            [22:38:25] <jrand0m> mihi> whats your take on the highest priority use case for httptunnel?  if there's something we can help with?
            
-
            [22:38:31] <mihi> http://home.arcor.de/mschierlm/test/nosocks.png (which browser is that?)
            
-
            [22:38:31] <human> it's just an add-on to do some neat stuff with tunnelling, chaining etc.
            
-
            [22:38:31] <wbk> I2P is the ircd of iip right?
            
-
            [22:38:31] <duck> anyway, all solutions need a clientside filter
            
-
            [22:38:47] <human> duck: yes, according to man 8 tsocks :-)
            
-
            [22:39:14] <jrand0m> dunno mihi, opera?
            
-
            [22:39:19] * fR has joined #i2p
            
-
            [22:39:19] <duck> wbk: no private msg
            
-
            [22:39:19] <jrand0m> wbk> no
            
-
            [22:39:30] <mihi_backup> jrand0m: make it work perfectly with post requests && make it do everything httpclient does
            
-
            [22:39:45] <jrand0m> word
            
-
            [22:40:08] <ughabugha> mihi: That's Opera.
            
-
            [22:40:14] <human> mihi: dunno, but as i wrote above: socks tunnels, however, will not replace www proxies :-)
            
-
            [22:40:18] <ughabugha> If you ment that as a question. :)
            
-
            [22:41:13] <jrand0m> ok, cool, anyone have anything else to bring up for web stuff, or are we ready for 4) Administravia?
            
-
            [22:42:23] <jrand0m> ok, just some notes -
            
-
            [22:42:24] * Rom|Away|3h is now known as Rom|Away|4h
            
-
            [22:42:51] <jrand0m> the drupal site is back online, so anyone who wants to help out with that, or see the latest progress, please hit drupal.i2p.net :)
            
-
            [22:44:02] <jrand0m> on it, you'll find the other two administravia points - the team roster [http://drupal.i2p.net/team] and the draft of a new license policy [http://drupal.i2p.net/node/view/85]
            
-
            [22:44:26] <duck> I was looking at the license policy...
            
-
            [22:44:35] <duck> AFAIK Cryptix == BSD
            
-
            [22:44:43] <jrand0m> right
            
-
            [22:44:52] <duck> (but with Cryptix team as copyrightor instead of regents of massachusets or something)
            
-
            [22:44:52] <jrand0m> but, strictly, its the Cryptix license ;)
            
-
            [22:45:05] <duck> what is MIT?
            
-
            [22:45:13] <jrand0m> mit is == bsd 2 clause
            
-
            [22:45:16] <jrand0m> == x
            
-
            [22:45:19] <duck> what code is MIT I mean
            
-
            [22:45:25] <jrand0m> nothing
            
-
            [22:45:29] <human> == x < 4.4.0
            
-
            [22:45:36] <jrand0m> i just list it as "if you want to use MIT, great"
            
-
            [22:45:42] <jrand0m> right human :/
            
-
            [22:45:49] <duck> the amount of licenses is already quite a few
            
-
            [22:45:56] <duck> I was wondering if that could be restricted
            
-
            [22:46:07] <duck> for example changing the GPL code into BSD or even pubdomain
            
-
            [22:46:31] <duck> was wondering what the author(s) of that part(s) did think about that
            
-
            [22:46:32] <ox> <no_dammagE> so, chatroom, ill go sleep now. Good code @ Devteam, good time of day to all others. Till tomorrow.
            
-
            [22:46:40] <duck> bye no_dammagE 
            
-
            [22:46:41] <jrand0m> i would love if the i2ptunnel streaming lib / naming lib or even the full i2ptunnel were licensed under a bsd-like license
            
-
            [22:46:51] <jrand0m> later no_dammagE
            
-
            [22:46:55] <no_dammagE> cu
            
-
            [22:46:58] * no_dammagE has quit IRC
            
-
            [22:47:19] * jar_backup has joined #i2p
            
-
            [22:47:50] <jrand0m> but, of course, GPL is fine, t'is mihi's right :)
            
-
            [22:48:06] <mihi> for streaming/naming lib that would be okay for me (or BSD or LGPL). but I'd like to keep GPL for the core I2PTunnel
            
-
            [22:48:07] <ughabugha> Well, whatever the license is, it should be GPL-compatible.
            
-
            [22:48:36] <ughabugha> (Ie, it shouldn't be more restrictive than GPL)
            
-
            [22:48:42] <human> i'm a GNU GPL advocate, but i think that the best license to disseminate new protocols and formats is something BSD-style (e.g. see how the OGG Vorbis guys relicensed everything from LGPL do MIT-X11)
            
-
            [22:49:05] <jrand0m> mihi> the streaming and naming lib are funcional without dependency upon i2ptunnel itself, right?
            
-
            [22:49:14] <ughabugha> Yeah, reference implementation shouldn't be GPL.
            
-
            [22:49:25] <mihi> they should be. if not, it's a bug.
            
-
            [22:49:30] <jrand0m> BSD 2 clause on those would be fantastic
            
-
            [22:49:40] <human> yup!
            
-
            [22:49:45] <mihi> you can have naming lib public domain if you include it into core ;)
            
-
            [22:50:02] * ion has joined #i2p
            
-
            [22:50:03] <jrand0m> absolutely, I'd love to include them in the core sdk
            
-
            [22:50:42] <mihi> them? ;) (including streaming lib into core would be a bad idea imho, since it is too less open for other impls)
            
-
            [22:51:09] <jrand0m> well, the sdk impl itself makes some nontrivial design assumptions - its just a ref impl
            
-
            [22:51:22] <jrand0m> i'd love if people could take i2p.jar and write a streaming app
            
-
            [22:51:28] <human> mihi: regarding I2PTunnels & GPL: i'd suggest to add an explicit GNU GPL exception that allows people to link your app with proprietary JVMs (see my comment on http://drupal.i2p.net/node/view/85)
            
-
            [22:51:28] * Masterboy has quit IRC (Ping timeout)
            
-
            [22:51:59] <duck> human: that brings up the "have to hire a lawyer before I can use it"-problem
            
-
            [22:52:01] <jrand0m> (perhaps we can split the current i2ptunnel into i2ptunnel and i2pstreaming, if you'd prefer?)
            
-
            [22:52:32] <mihi> jrand0m: that would be okay for me. just change the ant task to build 2 jars ;)
            
-
            [22:52:35] <human> duck: i suggest to add the exception just to avoid it
            
-
            [22:52:39] <jrand0m> duck> if mihi is willing to BSD the streaming and naming libs, i don't think that'd be too much trouble
            
-
            [22:53:30] <mihi> and better make i2pministreaming instead of i2pstreaming
            
-
            [22:53:41] <duck> mihistreaming :)
            
-
            [22:53:48] <mihi> (note the n in mi4ni)
            
-
            [22:54:02] <mihi> duck: that was exactly what i thought ;)
            
-
            [22:54:03] <jrand0m> word mihi, so perhaps we can revise the table on http://drupal.i2p.net/node/view/85 to list the I2PTunnel core as GPL (perhaps with the exception human mentions?), plus a seperate I2PMiniStreaming line as BSD?
            
-
            [22:54:04] <jrand0m> hehe
            
-
            [22:54:10] <jrand0m> i2pmihistreaming is good too :)
            
-
            [22:55:25] <duck> ok
            
-
            [22:55:40] <duck> next week I'll try to convince you all to move totally to publicdomain
            
-
            [22:55:45] <duck> but this is enough for now :)
            
-
            [22:55:48] <jrand0m> :)
            
-
            [22:55:50] <human> hehe
            
-
            [22:56:06] <jrand0m> mihi*=5
            
-
            [22:56:14] <mihi> jrandom**=5;
            
-
            [22:56:21] <duck> wbk did just offer to help with the webdesign
            
-
            [22:56:36] <jrand0m> oh awesome duck
            
-
            [22:56:45] <jrand0m> well, briefly before we jump to 5)
            
-
            [22:56:58] <jrand0m> do any devs have any qualms with the /policy/ in http://drupal.i2p.net/node/view/85?
            
-
            [22:57:05] <duck> so I did do a bureaucratic team-table lookup and delegate him to wilde
            
-
            [22:57:25] <human> before jumping... what about the GPL + exception suggestion?
            
-
            [22:57:29] <jrand0m> aka "implicitly under $primaryLicense" or "explicitly under $alternate"?
            
-
            [22:57:47] <jrand0m> duck++ :)
            
-
            [22:58:02] <mihi> human: I'm adding it atm
            
-
            [22:58:07] * human agrees with jrand0m's policy
            
-
            [22:58:25] <duck> what about copyright owner
            
-
            [22:58:28] <human> mihi: ok, thanks
            
-
            [22:58:30] * duck did see human adding some new files as GPL
            
-
            [22:58:36] <duck> and putting mihi's name on that
            
-
            [22:58:45] <ughabugha> Err... I don't think drupal likes passwords which are 32 characters long.
            
-
            [22:58:51] <human> duck: i just cut'n'pasted existing files
            
-
            [22:59:18] <duck> ok, but what if we have 50 ppl working on it and each putting their own name on the copyrights
            
-
            [22:59:20] <jrand0m> for people that add public domain code, there's no copyright, but for people who use copyright, people should copyright it themselves
            
-
            [22:59:22] <human> duck: (well, even if i'm forgetting to put copyrights into files...)
            
-
            [22:59:25] <duck> then you cant switch license at a later point
            
-
            [22:59:29] <jrand0m> thats fine duck, in my opinion
            
-
            [22:59:53] <jrand0m> e.g. thecrypto should be the copyright owner of his encryption and SHA routines
            
-
            [23:00:03] <human> (i was still observing jrand0m's policy to stick with module licenses, btw)
            
-
            [23:00:05] <jrand0m> though since he's released it under BSD 2 clause, we will use it
            
-
            [23:00:38] <jrand0m> oh, maybe i'm missing the point - you want to make sure everyone puts their own name on it?
            
-
            [23:00:44] <duck> no
            
-
            [23:00:49] * jrand0m assigns copyright to richard nixon
            
-
            [23:00:56] <human> heheh
            
-
            [23:01:34] <human> btw: in my country, "public domain" is just another kind of copyright
            
-
            [23:01:46] <jrand0m> hmm.  i2p doesn't have any legal entity to receive copyright (and *never* will)
            
-
            [23:02:02] <human> i.e. you (the author) distribute your works without any restrictions
            
-
            [23:02:18] <jrand0m> right, a lot of countries have fucked up IP laws
            
-
            [23:02:59] <human> jrand0m: just to say that maybe it's better to put something like "i've created this file, and you can use it without any restriction" in each file
            
-
            [23:03:13] <jrand0m> that i think is a good idea
            
-
            [23:03:47] <human> jrand0m: (it's still happening, of course, but i think it should be a requirement :-)
            
-
            [23:03:55] <jrand0m> thats why i included the "jrandom wrote this in $year and releases it into the public domain" ;)
            
-
            [23:04:08] <human> jrand0m: yeah :-)
            
-
            [23:04:27] <jrand0m> so i'm missing ducks point
            
-
            [23:04:37] <fidd> and that thing abouth eating children
            
-
            [23:04:37] <duck> I lost it too
            
-
            [23:04:43] <jrand0m> :)
            
-
            [23:04:44] <human> heheh
            
-
            [23:04:47] <duck> lets forget it
            
-
            [23:04:58] * lucky has joined #i2p
            
-
            [23:05:13] <jrand0m> ok, so I'll add to the commit priv section the suggestion that people make note of their authorship of what they write
            
-
            [23:05:22] <jrand0m> (even if they dont copyright it?)
            
-
            [23:05:24] <lucky> hi
            
-
            [23:05:25] <lucky> :D
            
-
            [23:05:39] <jrand0m> s/suggestion/<i>suggestion</i>/
            
-
            [23:05:42] <jrand0m> hi lucky
            
-
            [23:05:50] <jrand0m> [damn i borked my regexp]
            
-
            [23:05:57] <duck> want me to PGP sign a statement?
            
-
            [23:06:09] <jrand0m> i'm going to, yes
            
-
            [23:06:30] <jrand0m> once the policy is ready and revised, i'll be contacting all prior committers for PGP/GPG auth 
            
-
            [23:06:33] <human> jrand0m: yes (in my country it's impossible to refuse copyright, it's seen as an inalienable author's right)
            
-
            [23:06:52] <duck> yes, your country is fucked
            
-
            [23:06:53] <duck> NEXT
            
-
            [23:06:56] <duck> (oops)
            
-
            [23:06:58] <jrand0m> :)
            
-
            [23:07:19] <fidd> human, what country?
            
-
            [23:07:39] <human> jrand0m: so, "this file is not copyrighted" just doesn't make sense - you should *always* explicitly say that you're the author, and that you put no restrictions on your work
            
-
            [23:07:47] <human> fidd: somewhere near Europe :-)
            
-
            [23:07:54] <fidd> heh, ok
            
-
            [23:07:59] <lucky> human: you can later say you don't want the copyright
            
-
            [23:08:03] <lucky> and put it in the public domain.
            
-
            [23:08:19] <jrand0m> human> with the "implicit release under $primaryLicense", that should address the issue though, right?
            
-
            [23:08:24] <duck> human means that that doesnt mean anything in $fuckedcountry
            
-
            [23:08:42] <jrand0m> human> since that implicitly means commit == release as $primaryLicense
            
-
            [23:08:50] <human> duck: yup, exactly
            
-
            [23:09:07] <jrand0m> (so no comment == implicit license by $author, per `cvs log`)
            
-
            [23:09:28] <jrand0m> (ah, legalese in code ;)
            
-
            [23:09:36] <human> jrand0m: well, i'm not a lawyer... but i think it should work
            
-
            [23:09:43] * kaji has joined #i2p
            
-
            [23:09:48] <ox> * wilde agrees with the last proposal
            
-
            [23:09:57] <jrand0m> w3rd.
            
-
            [23:10:05] <jrand0m> ok, i'll see if i can get the eff to review
            
-
            [23:10:19] <jrand0m> moving on to 5) ???
            
-
            [23:10:21] <human> jrand0m: maybe it's better to have some sort of agreement when ppl are given CVS access
            
-
            [23:10:46] <ox> <wilde> when will we see, net.i2p.legal.LicenseManager?
            
-
            [23:10:47] <jrand0m> agreed human> explicit agreement with $policy will be a prerequisit for getting commit privs
            
-
            [23:10:50] <jrand0m> heh
            
-
            [23:10:52] <human> jrand0m: (for example, GPG signing the your policy, and hosting it on the I2P site?)
            
-
            [23:11:00] <human> heheh
            
-
            [23:11:04] <jrand0m> reasonable enough human.
            
-
            [23:11:13] <mihi> jrand0m prefers PGP8 ;)
            
-
            [23:11:23] <jrand0m> damn straight.  pgpdisk++
            
-
            [23:12:06] * wilde has joined #i2p
            
-
            [23:12:14] <duck> hi wilde
            
-
            [23:12:36] <jrand0m> ok, does anyone have anything they want to bring up for 5) ??? 
            
-
            [23:13:27] <wilde> just an invitation one more time for people to visit drupal and comment, modify, etc
            
-
            [23:13:37] <jrand0m> word, yes, thats a good point
            
-
            [23:13:41] <duck> http://drupal.i2p.net/
            
-
            [23:13:41] <wilde> so we can have good docs for 1.0
            
-
            [23:13:41] <mihi> human, jrand0m: is the license in CVS okay now? ;)
            
-
            [23:13:55] <jrand0m> on http://drupal.i2p.net/team there are a lot of [vacant] roles.  volunteer!
            
-
            [23:14:02] <fidd> i cant get drupal thru squuid :/
            
-
            [23:14:17] * mihi volunteers for QS guy cuz of echo server ;)
            
-
            [23:14:29] <mihi> s/QS/QA/
            
-
            [23:14:33] <jrand0m> woot!
            
-
            [23:15:01] <wilde> unit tests for echo server
            
-
            [23:15:12] <mihi> wilde rofl no
            
-
            [23:15:17] <human> mihi: maybe you should s/XXXX/mihi/ in the GPL exception :-)
            
-
            [23:15:20] <ughabugha> jrand0m: Heh, what do you mean by stress testing? :)
            
-
            [23:15:34] <mihi> echo server is system test for i2p ;)
            
-
            [23:15:38] <mihi> human: oops ;)
            
-
            [23:15:56] * Rom|Away|4h has quit IRC (Ping timeout)
            
-
            [23:16:08] <jrand0m> ughabugha> it means you smash (aka use) the router and have patience with me to debug it, submitting reports and logs
            
-
            [23:16:35] <ox> <wilde> thus stress testing poor jrandom...
            
-
            [23:16:40] <ughabugha> jrand0m: Oh, okay. :)
            
-
            [23:16:44] <duck> wow, mihi is fast
            
-
            [23:16:47] <ughabugha> Hehe.
            
-
            [23:17:30] * Romster has joined #i2p
            
-
            [23:17:40] <mihi> duck: editor still open and the CVS comment was fast to type as well ;)
            
-
            [23:17:40] <jrand0m> mihi> licenses look great - just to be explicit, you're idented here, and you intend to release under the bsd 2 clause [per http://opensource.org/licenses/bsd-license.php], correct?
            
-
            [23:17:41] * Romster is now known as Rom|Away|4h
            
-
            [23:18:02] <jrand0m> (or you can just add that copyright text into the source)
            
-
            [23:19:24] <mihi> hmm, what does idented mean? (yes to your second subclause)
            
-
            [23:19:42] <jrand0m> means you've proven to trent that you're mihi :)
            
-
            [23:19:50] <duck> authenticated
            
-
            [23:19:54] <mihi> ok, identified ;)
            
-
            [23:20:01] <jrand0m> w3rd
            
-
            [23:20:06] <human> let's try identicated
            
-
            [23:20:14] <mihi> it looked to me like "indented" and i thought that my white space was incorrect ;)
            
-
            [23:20:20] <jrand0m> hehe
            
-
            [23:20:43] <ox> * wilde thinks launches word for find yet another synonym
            
-
            [23:21:07] <human> authentified?
            
-
            [23:21:22] <duck> anyway...
            
-
            [23:21:28] <jrand0m> ok, r0x0r, anyone have anything else to bring up?
            
-
            [23:21:44] <ox> <wilde> yeah
            
-
            [23:21:50] <ox> <wilde> eep naming 
            
-
            [23:22:00] <jrand0m> heh you don't like my pronounciation?
            
-
            [23:22:12] * kaji has quit IRC (Ping timeout)
            
-
            [23:22:14] <ox> <wilde> of i2p -> eep
            
-
            [23:22:14] * Rom|Away|4h has quit IRC (Ping timeout)
            
-
            [23:22:21] <jrand0m> oh
            
-
            [23:22:30] <jrand0m> you want to rename the whole project "eep" ?
            
-
            [23:22:39] <human> lol
            
-
            [23:22:48] <ox> * wilde mutters
            
-
            [23:22:48] <mihi> envisible enternet project ;)
            
-
            [23:23:08] <lucky> envisible
            
-
            [23:23:09] <jrand0m> extrordinarily excellent people
            
-
            [23:23:15] <lucky> connotates something for me.
            
-
            [23:23:46] <mihi> even easier publishing ;)
            
-
            [23:23:51] <jrand0m> ooOOoo
            
-
            [23:23:51] <lucky> As in its going to be visable, therefore possible. envision maybe?
            
-
            [23:23:53] <ughabugha> Come on, stop picking on wilde. :)
            
-
            [23:23:54] <ox> <wilde> seriously, do you like the name then it's fun?
            
-
            [23:24:06] <ox> <wilde> fine i mean, getting tired
            
-
            [23:24:44] <ox> <wilde> new users will not have it easy
            
-
            [23:25:03] <jrand0m> oh, i'm not a marketeer.  we went under "eep" because its all i could think of
            
-
            [23:25:23] <human> i think it should be forbidden to explain that eep ~= i2p, or users will *really* screw up
            
-
            [23:25:25] * ion has quit IRC (Ping timeout)
            
-
            [23:25:26] <jrand0m> what should we call websites that people both host and access through i2p?
            
-
            [23:25:38] <jrand0m> hehe
            
-
            [23:25:42] <duck> i2psites?
            
-
            [23:25:44] <ox> <wilde> i2p site?
            
-
            [23:25:57] * human likes eepsites without explanations :-)
            
-
            [23:26:09] * kaji has joined #i2p
            
-
            [23:26:25] * jrand0m asks the http://drupal.i2p.net/team user advocate for their opinion
            
-
            [23:26:35] <duck> we got one?
            
-
            [23:26:38] <jrand0m> no
            
-
            [23:26:43] <jrand0m> ;)
            
-
            [23:26:52] <duck> heh
            
-
            [23:26:55] <human> anyway... you can change all the naming, as long as the "Shitlist" keeps its current name
            
-
            [23:26:56] <ox> * wilde rushes to the browser
            
-
            [23:27:01] <jrand0m> heh
            
-
            [23:27:06] <mihi> lol human
            
-
            [23:27:07] <jrand0m> oh, shitlist is going to stay, for sure ;)
            
-
            [23:27:21] <ox> <wilde> i take the role, it should be i2p sites, i resign
            
-
            [23:27:21] <duck> I bet that shitlist is a proper english word
            
-
            [23:27:24] <jrand0m> i mean, "blacklist" just isn't as fun
            
-
            [23:27:26] <jrand0m> hah wilde
            
-
            [23:27:29] <human> jrand0m: cool!
            
-
            [23:27:56] <ughabugha> But why not stick to the current names?
            
-
            [23:28:05] * human was worried that the shitlist was going to be the first victim when I2P goes corporate
            
-
            [23:28:06] <jrand0m> ok, i don't really care either way, i2psite is fine, eepsite is fine
            
-
            [23:28:09] <ughabugha> I mean we have enough time to consider it on the mailing list until 1.0.
            
-
            [23:28:09] <mihi> jrand0m: and the elephants on the moon have to stay too ;)
            
-
            [23:28:22] <kaji> so is kaji.i2p up for anyone. i kinda just started it up without testing anything and left it running
            
-
            [23:28:31] <jrand0m> human> i think we don't have to worry about that one ;)
            
-
            [23:28:35] <ughabugha> kaji: It worked for me.
            
-
            [23:28:48] <jrand0m> we have to keep moving the easter eggs mihi :)
            
-
            [23:28:48] <ox> <wilde> i don't really care, eepsite is just as boring as i2psite
            
-
            [23:29:05] <jrand0m> we can consider them synonyms
            
-
            [23:29:23] <ox> <wilde> that the worst decision ;)
            
-
            [23:29:44] <duck> wbk: ok, I have to leave for a bit. The meeting is almost over so people can help you in #i2p
            
-
            [23:29:44] * jrand0m supposes that now that i've taken on the title of PM i've got to make a decision
            
-
            [23:29:48] * ion has joined #i2p
            
-
            [23:29:55] * jrand0m kicks self
            
-
            [23:30:09] <human> heheh
            
-
            [23:30:12] * mihi guesses jrand0m needs some support for that
            
-
            [23:30:19] * Trent@anon.iip sets mode: +o mihi
            
-
            [23:30:27] * mihi sets mode: +o jrand0m
            
-
            [23:30:30] <@jrand0m> ooOOoo
            
-
            [23:30:32] * mihi sets mode: -o mihi
            
-
            [23:30:49] <ox> <wilde> ok no more questions from me
            
-
            [23:30:55] * human sacrifices his pet to the PM
            
-
            [23:31:38] * mihi still waits for jrand0m kicking himself...
            
-
            [23:31:44] <@jrand0m> i think there's benefit to discussion, as well as some quirkiness.  i also lean in human's direction - there's no need to confuse people by explaining "eep != i2p"
            
-
            [23:31:59] * @jrand0m Offically Decides "eepsite"
            
-
            [23:32:23] * You were kicked by jrand0m (bastard!)
            
-
            Session Close: Tue Mar 23 23:32:23 2004
            
-
            Session Start: Tue Mar 23 23:32:30 2004
            
-
            [23:32:32] <human> lol
            
-
            [23:32:37] <duck> lets quickly baff the meeting closed
            
-
            [23:32:40] <duck> oh, too late
            
-
            [23:32:42] <jrand0m> heh
            
-
            [23:32:48] <human> heheh
            
-
            [23:32:56] <jrand0m> ok anything else?  we're at the 92 minute mark
            
-
            [23:33:05] * jrand0m winds up...
            
-
            [23:33:20] * jrand0m *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting9.html b/www.i2p2/pages/meeting9.html
deleted file mode 100644
index fc574bf9..00000000
--- a/www.i2p2/pages/meeting9.html
+++ /dev/null
@@ -1,98 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 9{% endblock %}
-{% block content %}
-
            I2P (invisiblenet) Development Meeting 9
            
-
            
-Courtesy of the wayback machine.
-
            
-
            --- Log opened Wed Aug 21 00:58:22 2002
-
            00:58 <@mids> test
-
            01:00 <@mids> Hi folk(s)
-
            01:00 <@mids> nop & userx wont be here, and I dont have much to say
-
            01:00 <@mids> so lets just have an informal chit chat
-
            01:00 <@mids> with lots of questions and user feedback (yeah)
-
            01:01 -!- mids changed the topic of #iip-dev to: No formal meeting, but be welcome and chat. logs: http://mids.student.utwente.nl/~mids/iip/
-
            01:02 <@mids> on the freenet-devl mailinglist there has been a discussion about leaving OPN (irc.openprojects.net) and some suggested that IIP could be an alternative
-
            01:03 <@mids> Ian Clarke countered that IIP isn't subjected to any peer review by experts
-
            01:03 <@mids> and that it might be dangerous to think that this network is anonymous
-
            01:04 <@mids> he has a good point there, currently we are beeing reviewed by some guys, only info that I have is this url:
-
            01:04 <@mids> http://www.cypherpunks.to/ip/
-
            01:04 <@mids> .
-
            01:05 <@mids> I hope that everybody realizes that IIP isn't bugfree, and that the anonimity factor can be quite relative
-
            01:06 <@mids> but this shouldn't stop us from using it, catching bugs and making improvements
-
            01:06 <@mids> .
-
            01:06 < thecrypto> true anomimity is possible, it's just really hard
-
            01:07 < hobbs> no, actually, I'm pretty sure it's the other way around. true anonymity is impossible, but you can make it "really hard" for whoever wants to find out.
-
            01:08 < hobbs> off to eat. be back asap. :)
-
            01:08 <@mids> appart from the cryptography algorithms, IIP does depend on the amount of public relays to 'hide' the users. with only a few it can be relativly easy for big organisations with lots of power to systimatically track every user down
-
            01:08 <@mids> thanks for dropping by hobbs 
-
            01:08 < thecrypto> chaum proved it in his paper on dining cryptographer's, however setting up a DC-net for this would be a huge feat
-
            01:09 <@mids> but what if all philosophers but 1 are working together?
-
            01:10 < thecrypto> yes, that is a weakness there
-
            01:10 <@mids> so, we need more public relays and more peer reviews :)
-
            01:11 <@mids> if you happen to be a security / cryptography expert, dont hesitate to examine IIP
-
            01:11 <@mids> .
-
            01:12 <@mids> I have taken a look at SILC (http://www.silcnet.org)
-
            01:12 <@mids> it is a chat client and server system with embedded cryptography
-
            01:12 <@mids> you can put keys on channels and private conversations
-
            01:13 < thecrypto> i'm not an expert, just a student who reads alot about this topic :)
-
            01:13 <@mids> it cant be compared with IIP, since it doesn't offer (an attempt) to anonymity
-
            01:13 <@mids> but it is quite interesting, maybe you (readers of the logfile) should take a look at it
-
            01:14 <@mids> I have been trying to run it over IIP, so you will get both channel crypto and anonymity
-
            01:14 <@mids> but I had little problems setting up the network for IIP version 1.1
-
            01:14 <@mids> once nop / userx respond with some hints how to do it, I'll put a test server behind IIP... as a proof of concept
-
            01:15 <@mids> .
-
            01:15  * mids throws the mike in the audience
-
            01:18 < thecrypto> doesn't IIP already have end-to-end encryption?
-
            01:18 <@mids> server-end 
-
            01:18 <@mids> the server is a patched ircd, and gets all the text plaintext from the server-side IIP node
-
            01:18 <@mids> so an Evil Serveradmin could log all the private and channel conversations
-
            01:19 <@mids> (after patching the source ofcourse)
-
            01:20 <@mids> but he (or she) wont get are the IP addresses of users
-
            01:20 <@mids> .
-
            01:20 < thecrypto> ahh, the evil admin problem. why can't we put in encryption to the server?
-
            01:21 <@mids> because then you either have to put irc protocol level code in the local IIP nodes or use special irc clients
-
            01:21 <@mids> the aim for IIP has been (so far) to work with normal irc clients, and I expect that it will be that way in the (near) future
-
            01:22 <@mids> an aim is making a VIRCD (virtual irc daemon) in each IIP client relay which handles the channel / user crypto
-
            01:22 < thecrypto> so it's on the TODO list but not there yet
-
            01:22 <@mids> exactly
-
            01:23 <@mids> ellison informed me that he has a demo of the new IIP and InvisibleNet website available
-
            01:24 <@mids> it will cooked into HTML in a couple of minutes
-
            01:24 < agril> Why doesn't /lusers work anymore?
-
            01:25 <@mids> all /stats commands (I don't know if /lusers uses that, or if it is a native ircd command) have been disabled in the ircd
-
            01:25 <@mids> so we dont know how many clients or hidden channels there are
-
            01:26 <@mids> that is probably better... for evildoers it would be harder to measure the outcome of their flood/ddos attempts
-
            01:27 <@mids> but I have to admit that I miss the nice network graphs that could be created using those stats :(
-
            01:30 <@mids> (ellison is uploading the site right now)
-
            01:31 <@mids> http://www.citystateinc.com/ellison/invisiblenet/
-
            01:31 <@mids> hurray!
-
            01:31 < thecrypto> is there an offical TODO list anywhere?
-
            01:32 <@mids> I know that some subprojects have TODO lists... but the main project, I dont know
-
            01:32 <@mids> but I am sure that userx/nop have their own list
-
            01:33 <@mids> http://help.invisiblenet.net/ chapter 1 - future plans
-
            01:33 <@mids> that contains a few far away aims
-
            01:33 <@mids> Neo: http://www.citystateinc.com/ellison/invisiblenet/
-
            01:33 < Neo> tanks
-
            01:35 <@mids> any comments about the website?
-
            01:36 < Neo> Oh, nope.
-
            01:36 < Neo> Its looking great.
-
            01:36 < Neo> iip section is just so much better than what was before.
-
            01:37 <@mids> I totally agree
-
            01:37 < Neo> Download, Screenshots, Documentation, Development, Contact. Good flow.
-
            01:39 <@mids> it looks very consistent and easily adaptable
-
            01:39 < thecrypto> good site
-
            01:39 <@mids> any important section missing? (in the menu)
-
            01:42 <@mids> I think we have it all covered
-
            01:43 < pox> looks good
-
            01:43 <@mids> under Contact there will also be a list of all the PGP keys of developers and contributors
-
            01:45 <@mids> last point about the site: ellison will be done soon, then he'll ship it to me and nop and we will fill in the pieces
-
            01:45 <@mids> I guess that I will make some includes using php so that information can be updated easily
-
            01:46  * mids thinks we will have this cool website Real Soon!!!
-
            01:46 <@mids> .
-
            01:47 < thecrypto> a good website is the sign of a good project :)
-
            01:47 < Neo> Great stuff.
-
            01:48 <@mids> That was iip-dev radio with your host mids, feel free to hang around with your questions & comments
-
            01:49 < hobbs> wow. that's pretty.
-
            --- Log closed Wed Aug 21 01:55:36 2002
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/meeting90.html b/www.i2p2/pages/meeting90.html
deleted file mode 100644
index c504480f..00000000
--- a/www.i2p2/pages/meeting90.html
+++ /dev/null
@@ -1,203 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 90{% endblock %}
-{% block content %}
             Tuesday, May 18, 2004 14:00:00 PDT
            
-
            
-
            14:07 < jrandom> 0) hi
            
-
            14:07 < jrandom> 1) testnet status
            
-
            14:07 < jrandom> 2) SAM
            
-
            14:07 < jrandom> 3) roadmap updates
            
-
            14:07 < jrandom> 4) MyI2P
            
-
            14:07 < jrandom> 5) ???
            
-
            14:07 < jrandom> 0) hi
            
-
            14:07  * jrandom waves 
            
-
            14:08 < Nightblade> hi
            
-
            14:08  * jteitel waves back
            
-
            14:08 < jar> hi
            
-
            14:08 < duck> lo
            
-
            14:08 < Masterboy> :P
            
-
            14:08 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-May/000239.html
            
-
            14:09 < jrandom> sorry if I'm a bit out of it today, sleep schedule is more out of wack than usual
            
-
            14:09 < jrandom> anyway, moving on to 1) testnet status
            
-
            14:10 < duck> the diversification would automatically happen with a bigger network wouldnt it?
            
-
            14:10 < jrandom> yes, and/or less skewed peer selection thresholds
            
-
            14:11 < jrandom> for instance, if the speed threshold were the median as opposed to the average, we'd get half as many fast peers as reliable peers
            
-
            14:11 < jrandom> as opposed to the situation we have today where the speeds are heavily skewed
            
-
            14:12 < Masterboy> well the network healed that's not so bad
            
-
            14:12 < jrandom> yeah, it took longer than it should though, and exposed ways that it can be improved
            
-
            14:13 < jteitel> did the network heal?  I still cannot connect to i2p irc reliably
            
-
            14:13 < jrandom> the peer profiles didn't decay fast enough, or promote new candidates efficiently
            
-
            14:14 < jrandom> it did fire off a chain of secondary events as well - overloading routers that weren't capable of holding the load (due to insufficient profiling), causing some overloaded routers to run out of memory and shut down
            
-
            14:15 < human> ayeee ayeee ayeee!
            
-
            14:15 < jrandom> its been a progression jteitel - some of the issues we've been seeing are related to the netDb failures 
            
-
            14:15 < jrandom> heya human
            
-
            14:15 < jteitel> Oh, OK
            
-
            14:16 < _cervantes_> could not an troubled router offload tunnels to another peer?
            
-
            14:16 < ugha_node> Wow, Lifetime rate: 8.87KBps sent 8.35KBps received.
            
-
            14:16 < Nightblade> jteitel: I connected just now after several tries...still waiting for my /join to go through
            
-
            14:16  * BrianR looks around.
            
-
            14:16 < jrandom> no - a router can simply drop a tunnel though (if it shouldn't have accepted it in the first place)
            
-
            14:16 < ugha_node> (And I restarted my router half an hour ago)
            
-
            14:16 < BrianR> damn it. I'm late.
            
-
            14:17 < BrianR> jrandom: (Thanks for arranging myi2p towards the end of the agenda)
            
-
            14:17 < jrandom> ugha> yeah, y'all had to pick up the slack for those three fast ones
            
-
            14:17 < jrandom> hehe :)
            
-
            14:18 < duck> a nice attack it was
            
-
            14:18 < ugha_node> jrandom: Obciously.
            
-
            14:18 < _cervantes_> so would it not be better to be more ruthless and reject tunnels at lower threshold
            
-
            14:19 < jrandom> yes cervantes - the routers right now never reject a tunnel unless they cant reach the next hop
            
-
            14:19 < jrandom> we'll want to include some sort of throttling in there, perhaps based on the size of the jobQueue / avg lag, etc
            
-
            14:20 < jrandom> in addition, we'll want to make sure we dont try to build too many tunnels at once, as happened when a large portion of them failed
            
-
            14:20 < _cervantes_> or simply allow the user to set a threshold based on the hardware/bandwith he/she knows he has availabled
            
-
            14:20 < jrandom> (due to the fast+reliable peers going offline)
            
-
            14:20 < _cervantes_> at least at this stage
            
-
            14:20 < jrandom> oh thats a good point - allowing people to explicitly set a max # participating tunnels.
            
-
            14:21 < jrandom> we'll get that into the next rev.  good call.
            
-
            14:21 < ugha_node> This sounds just like fuzzy logic.
            
-
            14:21 < jrandom> we've got to deal with overload, and simply queueing up messages in memory certainly doesnt work
            
-
            14:21 < duck> (hi fvw)
            
-
            14:21 < _cervantes_> it would be good to have some kind of coalleted stats on tunnel performance... the kind of load the might inflict on a benchmark processor(s)
            
-
            14:22 < _cervantes_> btw I took my server offline....it was getting a shed load of tunnels and I haven't yet compiled jbigi ;-)
            
-
            14:22 < jrandom> see http://localhost:7655/routerStats.html#Tunnels
            
-
            14:23 < jrandom> ah!  yeah, jbigi is something we want to encourage everyone to use 
            
-
            14:23 < BrianR> Any thoughts on doing bandwidth budgeting for tunnels? 
            
-
            14:24 < jrandom> currently slated for 3.0 (with overall bandwidth limiting for the router as a whole @ 0.4.1)
            
-
            14:24 < jrandom> but having per-tunnel bandwidth limits earlier wouldnt hurt
            
-
            14:25 < fvw> Is it wise to spend effort on this so early when it's much easier and more precisely done in the kernel of the OSes most of the current users/testers are running?
            
-
            14:25 < _cervantes_> something I would like to see is per-tunnel depth settings (perhaps this is already possible)
            
-
            14:25 < _cervantes_> for instance I already know I can trust my server....so I don't want to have to go through _x_ hops to get to it
            
-
            14:25 < jrandom> fvw> thats a good point, especially since we currently don't devour too much bandwidth
            
-
            14:26 < jrandom> hmm cervantes - yes, each client can specify the length of their tunnels, but i'm not sure thats exactly what you want
            
-
            14:26 < _cervantes_> nope
            
-
            14:26 < jrandom> cervantes - i think what you're looking for is a QoS where you can shorten the conn for one particular peer
            
-
            14:26 < _cervantes_> for instance...
            
-
            14:26 < _cervantes_> yep
            
-
            14:27 < jrandom> (which was slated for i2p 4.0, but thats more than a year away == infinity)
            
-
            14:27 < _cervantes_> in this case also select the depth per i2p host
            
-
            14:27 < BrianR> fvw: Yes, but an i2p needs to know roughly how much bandwidth potential tunnel members have available in order to make wise tunnelbuilding decisions... 
            
-
            14:27 < _cervantes_> ah ok
            
-
            14:27 < _cervantes_> :)
            
-
            14:27 < jrandom> but its a good idea, and technically feasible, but patches accepted :)
            
-
            14:28 < _cervantes_> the patch is already in the mail....along with that cheque for 5000 bars of e-gold 
            
-
            14:28 < _cervantes_> ;-)
            
-
            14:28 < jrandom> BrianR: perhaps it can go halfway - keep track of how many tunnels it is participating in, as well as how much bandwidth those tunnels are using, and use that as part of the decision as to whether to accept or reject a tunnel create request?
            
-
            14:28 < jrandom> heh
            
-
            14:30 < jrandom> ok, anyone have anything else for the testnet status?
            
-
            14:30 < Masterboy> what about my paradox?
            
-
            14:30 < Masterboy> :)
            
-
            14:30 < jrandom> my plan is to get a 0.3.1.3 with the updates out by thursday or friday
            
-
            14:31 < jrandom> Masterboy: i havent had time to go through your logs, but we'll have it resolved
            
-
            14:31 < _cervantes_> friday 2005?
            
-
            14:31 < _cervantes_> cool
            
-
            14:31 < Masterboy> k
            
-
            14:31 < jrandom> ok, moving on to 2) SAM
            
-
            14:31 < Masterboy> now we know who is running the out of date router..
            
-
            14:32  * jrandom hands the mic to our intrepid SAM.pm dev
            
-
            14:33 < jrandom> (thats you BrianR :)
            
-
            14:33 < BrianR> Hold a second.. :)
            
-
            14:33  * duck cheers
            
-
            14:33 < jrandom> in the meantime, dm or firerabbit around?
            
-
            14:33 -!- Irssi: #i2p: Total of 26 nicks [0 ops, 0 halfops, 0 voices, 26 normal]
            
-
            14:33  * jrandom checks the /names, nope.  oh well
            
-
            14:33 < jrandom> (no .net/C# sam lib updates then)
            
-
            14:34 < duck> is the .py stuff still current?
            
-
            14:34 < duck> or depricated by SAM improvements
            
-
            14:34 < jrandom> not sure
            
-
            14:34 < BrianR> Ok. I'm back. 
            
-
            14:34 < Nightblade> My C library appears to be working... I have not written an application to use it yet though
            
-
            14:34 < jrandom> awesome nightblade!
            
-
            14:35 < Nightblade> Has anyone here done GTK+/C programming under Windows?
            
-
            14:35 < human> duck: the client lib needs a small change for versioning support
            
-
            14:35 < _cervantes_> "hello world"?
            
-
            14:35 < human> duck: the rest should work without problems
            
-
            14:35  * jrandom suggests a datagram like tftp as the ideal sam test :)
            
-
            14:35 < Nightblade> well, anything really... does GTK work well under windows.....?
            
-
            14:35 < jrandom> (or even SAM streaming instead of datagram or raw)
            
-
            14:36 < jrandom> cool BrianR - how goes the .pm and the samcat?
            
-
            14:36 < BrianR> Net::SAM is in the CVS in mostly non-working form.
            
-
            14:36 < BrianR> I hope to have all of the bugs ironed and datagram and raw working before week end.
            
-
            14:37 < BrianR> A bit more work will be required to put a nice OO finish on streams.
            
-
            14:37 < Nightblade> oh yeah, i didn't bother with datagram or raw... just stream
            
-
            14:37 < Nightblade> but that is all i would use anyway
            
-
            14:37 < fvw> human: Have you considered wxWindows? It's quite useful for that kind of stuff (don't think there's a windows GTK target though)
            
-
            14:37 < jrandom> awesome BrianR 
            
-
            14:38 < BrianR> Wife is bugging me to join her for dinner. I may or may not be back in time for myi2p discussion. I've posted the threat model and stuff dumb fileserver stuff on node 208 
            
-
            14:38 < human> fvw: the GTK windows client does exist (The GIMP runs on windows, too)
            
-
            14:38 < jrandom> cool nightblade, its best to implement whats needed first
            
-
            14:38 < human> fvw: s/client/port/
            
-
            14:38 < jrandom> heh 'k BrianR, thanks
            
-
            14:38 < fvw> human: I mean gtk windows target for wxWindows (which I was suggesting you use)
            
-
            14:38  * fvw waves to BrianR. Bon Appetite.
            
-
            14:38 < human> fvw: ah... well, i don't know about vxWidgets (vxWindows' new name :-)
            
-
            14:39 < human> fvw: but it was Nightblade speaking about GTK+, not me :-)
            
-
            14:40 < fvw> Oops, my eyes are crooked, ignore me.
            
-
            14:40 < Nightblade> I'm not as familiar with C++ as I am C
            
-
            14:40 < Nightblade> afaik GTK is the only cross-platform C GUI library
            
-
            14:40 < Nightblade> not that i am particularly fond of GTK
            
-
            14:40 < fvw> doesn't really matter, wxWindows is easily approachable from C.
            
-
            14:40 < Nightblade> hmm
            
-
            14:40 < Nightblade> well maybe i'll take a look at it too
            
-
            14:40 < Nightblade> i know C++ but I haven't written any major programs in it
            
-
            14:41  * fvw isn't a C++ coder either, but I set up a fairly large transaction viewer for a transport company in it a while back without troubles.
            
-
            14:42 < Nightblade> i am sure wxwindows has a more mature windows port
            
-
            14:42 < Nightblade> than gtk
            
-
            14:42 < fvw> quite probably yeah.
            
-
            14:43 < Nightblade> (ok continue meeting) heh
            
-
            14:43 < jrandom> :)
            
-
            14:43 < jrandom> ok, jumping to 3) roadmap updates
            
-
            14:44  * jrandom has been negligent updating http://www.i2p.net/roadmap over the last month
            
-
            14:44 < jrandom> but now its back up to current
            
-
            14:44 < jrandom> unfortunately we're obviously not getting 0.4 in next week
            
-
            14:44 < duck> (are 1.1, 2.0, 3.0 also up2date?)
            
-
            14:45 < jrandom> yessir
            
-
            14:45  * Masterboy read it liked it - no rush we are not on fire..
            
-
            14:46 < duck> someone should update wikipedia/infoanarchy too :)
            
-
            14:46 < jrandom> oh, i should probably remove the "SAM bridge and client libraries implemented and tested" from 0.4
            
-
            14:46 < jrandom> heh yeah, thats why i !thwapped iA a while back when they just copied the wiki page
            
-
            14:46 < jrandom> (they should just point to the /roadmap, not duplicate the content)
            
-
            14:47 < Masterboy> SAM is finished?
            
-
            14:47 < jrandom> its functional yes, though work on additional client libraries are ongoing
            
-
            14:47 < jrandom> s/are/is/
            
-
            14:48 < jrandom> ok, unless there are any more roadmap questions/concerns, moving on to 4) MyI2P
            
-
            14:50 < jrandom> while i've stopped working on myi2p myself, we've opened up the effort to a bounty - http://www.i2p.net/node/view/216
            
-
            14:50 < jrandom> part of that means we need to get the requirements right, and there has been some debate about what those should be
            
-
            14:51 < Masterboy> tried to get in it my friend he said too mutch work too little money;P well he is a capitalist;)
            
-
            14:51 < Masterboy> well i offered to code it..
            
-
            14:52 < jrandom> coding on it is always wanted :)  
            
-
            14:53 < jrandom> the current outstanding architectural question though is how to deal with people who cannot run their i2p router / myi2p node all the time
            
-
            14:53 < Nightblade> just have to have some trusted i2p isp
            
-
            14:53 < jrandom> the two proposals are either to use hosted service providers, or to split off the system to use a distributed backing store
            
-
            14:54 < _cervantes_> the later being the long term ideal solution
            
-
            14:54 < _cervantes_> *latter
            
-
            14:54 < duck> (and being another bounty)
            
-
            14:55 < _cervantes_> or a webcache proxy service...
            
-
            14:55 < jrandom> right - if we went the hosted service provider (or locally run node), when a DHT/etc were available we could push more and more of the content into the DHT
            
-
            14:55 < jrandom> _cervantes_: thats essentially the distributed backing store - untrusted data caches
            
-
            14:57 < deer> * Masterboy wonders where is bogobot
            
-
            14:57 < jrandom> the hard part is to get the access control functionality needed - with untrusted data caches / distributed backing store, ACLs are essentially encryption
            
-
            14:57 < jrandom> but a "side channel" to this discussion comes from the three points raised by an anonymous person @ http://www.i2p.net/node/view/215#comment-105
            
-
            14:57 < _cervantes_> and signed content
            
-
            14:58 < jrandom> right, both ways will need to have signed content
            
-
            15:00 < _cervantes_> this is where hypercubus' model has merit...but it's by no means "quick" solution
            
-
            15:00 < jrandom> from the discussions on irc last night, we focused on the "livejournal threat model" - what attacks LJ users care about, and what they dont
            
-
            15:01 < wilde> first things first, getting a basic MyI2P in first place
            
-
            15:02 < jrandom> right, and to get the basic myi2p implemented, we've got to know the deployment architecture
            
-
            15:03 < jrandom> with the lj threat model for users who cannot run their own nodes, i dont think we need to go the untrusted data cache route
            
-
            15:03 < jrandom> and why would someone use myi2p if they merely need lj's threat model?  because its anonymous
            
-
            15:04 < jrandom> we could go on for some idealized system, but there is the law of diminishing returns
            
-
            15:04 -!- Irssi: #i2p: Total of 24 nicks [0 ops, 0 halfops, 0 voices, 24 normal]
            
-
            15:05 < jrandom> which is why i'm leaning towards keeping the bounty along the current lines - we can add on alternatives later, after the basic system is out
            
-
            15:05 -!- duck_ is now known as duck
            
-
            15:06 < jrandom> anyway, i think thats all i've got for 4) MyI2P, unless someone has anything else they'd like to bring up
            
-
            15:06 < jrandom> if not, moving on to 5) ???
            
-
            15:07 < _cervantes_> hmm you need a large gavel :)
            
-
            15:07 < jrandom> i forgot to mention morph.i2p's new eepsite in the meeting notes, and nickster.i2p now has a public fproxy available!
            
-
            15:08 < jrandom> (and sungo.i2p has his webcam up and running :)
            
-
            15:08 < _cervantes_> heh...
            
-
            15:08 < _cervantes_> i2pr0n
            
-
            15:08 < jrandom> anyone else have anything they want to bring up?
            
-
            15:10 < jrandom> if not, that'll put us at the 70 minute mark
            
-
            15:10 < deer> <Masterboy> no
            
-
            15:10  * jrandom winds up
            
-
            15:10  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting92.html b/www.i2p2/pages/meeting92.html
deleted file mode 100644
index 1cf35d5d..00000000
--- a/www.i2p2/pages/meeting92.html
+++ /dev/null
@@ -1,341 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 92{% endblock %}
-{% block content %}
            
-
            [22:59] <duck> Tue Jun  1 21:00:00 UTC 2004
            
-
            [23:00] <duck> hi folks!
            
-
            [23:00] <mihi> hi duck
            
-
            [23:00] <duck> http://dev.i2p.net/pipermail/i2p/2004-June/000250.html
            
-
            [23:00] <duck> my proposal:
            
-
            [23:00] * Masterboy has joined #i2p
            
-
-
            [23:00] <duck> 1) code progress
            
-
            [23:00] <duck> 2) featured content
            
-
            [23:00] <duck> 3) testnet status
            
-
            [23:00] <duck> 4) bounties
            
-
            [23:00] <duck> 5) ???
            
-
            [23:00] <Masterboy> hi:)
            
-
            [23:00] <duck> .
            
-
            [23:01] <duck> since jrandom is off we'll have to do it ourself
            
-
            [23:01] <duck> (I know that he is logging and verifying our independency)
            
-
            [23:01] <Masterboy> no problem:P
            
-
            [23:02] <duck> unless there are problems with the agenda I propose that we stick to it
            
-
            [23:02] <duck> though there aint much that I can do if you dont :)
            
-
            [23:02] <duck> .
            
-
            [23:02] <mihi> ;)
            
-
            [23:02] <duck> 1) code progress
            
-
            [23:02] <duck> not much code submitted to cvs
            
-
            [23:02] <duck> I did win the trophy this week: http://duck.i2p/duck_trophy.jpg
            
-
            [23:03] * hypercubus has no cvs account yet
            
-
            [23:03] <Masterboy> and who did submit something?
            
-
            [23:03] <duck> anybody doing any secret coding?
            
-
            [23:03] * Nightblade has joined #I2P
            
-
-
            [23:03] <hypercubus> BrianR was working on some stuff
            
-
            [23:04] <hypercubus> i've got maybe 20% of the 0.4 installer hacked out
            
-
            [23:04] <duck> hypercubus: if you have stuff then provide diffs and $dev will commit for you
            
-
            [23:04] <duck> ofcourse the strict license agreements apply
            
-
            [23:05] <duck> hypercubus: cool, any issues / things worth mentioning?
            
-
            [23:06] <hypercubus> not yet, but i'll probably need a couple of BSD people to test the preinstaller shell scripts
            
-
            [23:06] * duck turns some stones
            
-
            [23:06] <Nightblade> is it text-only
            
-
            [23:07] <mihi> duck: which one is you on duck_trophy.jpg?
            
-
            [23:07] <mihi> ;)
            
-
            [23:07] <Nightblade> luckypunk has freebsd, also my isp has freebsd but their config is kind of screwed up
            
-
            [23:07] <Nightblade> my web host isp that is, not comcast
            
-
            [23:08] <duck> mihi: left one with the glasses. wilde is the right guy handing me the trophy
            
-
            [23:08] * wilde waves
            
-
            [23:08] <hypercubus> you have a choice... if you have java installed, you can skip the preinstaller altogether... 
            
-
              if you don't have java installed you can run the linux binary or win32 binary preinstaller (console mode), or a 
            
-
              generic *nix script preinstaller (console mode)
            
-
            [23:08] <hypercubus> the main installer gives you the choice of using console mode or spiffy GUI mode
            
-
            [23:08] <Masterboy> i will install freebsd soon so in the future i will give a try to the installer too
            
-
            [23:09] <hypercubus> ok good... didn't know if anyone else besides jrandom was using it
            
-
            [23:09] <Nightblade> freebsd java is invoked as "javavm" rather than "java"
            
-
            [23:09] <hypercubus> as built from sun sources?
            
-
            [23:09] <mihi> freebsd supports symlinks ;)
            
-
            [23:10] <hypercubus> anyhow the binary preinstaller is 100% complete
            
-
            [23:10] <hypercubus> compiles with gcj to native
            
-
            [23:11] <hypercubus> it just asks you for the install dir, and it grabs a JRE for you
            
-
            [23:11] <duck> w00t
            
-
            [23:11] <Nightblade> cool
            
-
            [23:11] <hypercubus> jrandom's packaging a custom JRE for i2p
            
-
-
            [23:12] <deer> <j> .
            
-
            [23:12] <Nightblade> if you install java from the freebsd ports collection you use some wrapper script called 
            
-
              javavm
            
-
            [23:12] <deer> <r> .
            
-
            [23:12] <hypercubus> anyhow this puppy will be almost completely automated
            
-
            [23:12] <deer> <r> .
            
-
            [23:12] <deer> <r> .
            
-
            [23:12] <deer> <r> .
            
-
            [23:12] <deer> <duck> r: cut it
            
-
            [23:12] <deer> <r> .
            
-
            [23:12] <deer> <m> .
            
-
            [23:13] <deer> <m> stoopid irc server, does not support pipelining :(
            
-
            [23:13] <duck> hypercubus: got any ETA for us?
            
-
            [23:14] <deer> <m> oops, the problem is "Nick change too fast" :(
            
-
            [23:14] <hypercubus> i still expect to be finished in under a month, before 0.4 is ripe for release
            
-
            [23:14] <hypercubus> though at present i'm compiling a new OS for my dev system, so it'll be a couple of days 
            
-
              before i get back to the installer ;-)
            
-
            [23:14] <hypercubus> no worries though
            
-
            [23:15] <duck> ok. so more news next week :)
            
-
            [23:15] <duck> any other coding done?
            
-
            [23:15] <hypercubus> hopefully... unless the power company screws me again
            
-
            [23:16] * duck moves to #2
            
-
            [23:16] <duck> * 2) featured content
            
-
            [23:16] <duck> lots of streaming audio (ogg/vorbis) done this week
            
-
            [23:16] <duck> baffled is running his egoplay stream and I am running a stream too
            
-
            [23:16] <Masterboy> and it works quite good
            
-
            [23:17] <duck> on our site you can get info how to use it
            
-
            [23:17] <hypercubus> got any rough stats for us?
            
-
            [23:17] <duck> if you use a player not listed there and figure out how to use it, please send them to me and I'll 
            
-
              add
            
-
            [23:17] <Masterboy> duck where is the link to baffleds stream on your site?
            
-
            [23:17] <Masterboy> :P
            
-
            [23:17] <duck> hypercubus: 4kB/s goes pretty well
            
-
            [23:18] <duck> and with ogg it aint tooooo bad
            
-
            [23:18] <hypercubus> but that still seems to be the avg. speed?
            
-
            [23:18] <duck> my observation is that is the max
            
-
            [23:18] <duck> but it is all config tweaking
            
-
            [23:19] <hypercubus> any idea why that seems to be the max?
            
-
            [23:19] <hypercubus> and i'm not just talking streaming here
            
-
            [23:19] <hypercubus> but downloads too
            
-
            [23:20] <Nightblade> i was downloading some big files yesterday (a couple megabytes) off of duck's hosting 
            
-
              service and i was getting about 4kb-5kb as well
            
-
            [23:20] <duck> I think that it is the rtt
            
-
            [23:20] <Nightblade> those Chips movies
            
-
            [23:20] <hypercubus> 4-5 seems an improvement over the ~3 that i've gotten consistently since i started using i2p
            
-
-
            [23:20] <Masterboy> 4-5kb is not bad..
            
-
            [23:20] <duck> with a windowsize of 1 you dont get much faster..
            
-
            [23:20] <duck> windowsize >1 bounty: http://www.i2p.net/node/view/224
            
-
            [23:21] <duck> mihi: maybe you can comment?
            
-
            [23:21] <hypercubus> but it is a remarkably consistent 3 kbps
            
-
            [23:21] <mihi> on what? windowsize>1 with ministreaming: you are a wizard if you manage that ;)
            
-
            [23:21] <hypercubus> no hiccups on the bandwidth meter... a fairly smooth line
            
-
            [23:21] <duck> mihi: on why it is so stable at 4kb/s
            
-
            [23:21] <mihi> no idea. i don't hear any sound :(
            
-
            [23:22] <duck> mihi: for all i2ptunnel transfers
            
-
            [23:22] <Masterboy> mihi you need to config the ogg streaming plugin..
            
-
            [23:22] <mihi> Masterboy:?
            
-
            [23:23] <mihi> no, there is no limit inside i2ptunnel regarding speed. it must be in the router...
            
-
            [23:23] <duck> my thinking: max packet size: 32kB, 5 second rtt: 32kB/5s =~ 6.5kb/s
            
-
            [23:24] <hypercubus> sounds plausible
            
-
            [23:25] <duck> ok..
            
-
            [23:25] <duck> other content:
            
-
            [23:25] * hirvox has joined #i2p
            
-
-
            [23:25] <duck> there is a new eepsite from Naughtious
            
-
            [23:25] <duck> anonynanny.i2p
            
-
            [23:25] <duck> key is commited to cvs and he did put it on ugha's wiki
            
-
            [23:25] * mihi is hearing "sitting in the ..." - duck++
            
-
            [23:25] <Nightblade> see if you can open two or three streams at a 4kb speed then you will be able to tell if it 
            
-
              is in the router or the streaming lib
            
-
            [23:26] <duck> Naughtious: you there? tell something about your plan :)
            
-
            [23:26] <Masterboy> i have read that he provides hosting
            
-
            [23:26] <duck> Nightblade: I did try 3 parallel downloads from baffled and I got 3-4kB each
            
-
            [23:26] <Nightblade> i c
            
-
            [23:27] <mihi> Nightblade: how can you tell that then?
            
-
            [23:27] * mihi likes listening in "stop&go" mode ;)
            
-
            [23:27] <Nightblade> well if there is some kind of limitation in the router that only lets it handle 4kb at once
            
-
            [23:27] <Nightblade> or if it is something else
            
-
            [23:28] <hypercubus> can someone explain this anonynanny site? i don't have a running i2p router atm
            
-
            [23:28] <mihi> hypercubus: just a wiki or some sort of it
            
-
            [23:28] <duck> plone CMS setup, open account creation
            
-
            [23:28] <duck> allows file upload and website stuff
            
-
            [23:28] <duck> through web interface
            
-
            [23:28] <Nightblade> another thing to do would be to test the throughput of the "repliable datagram" which afaik 
            
-
              is the same as the streams but without acks
            
-
            [23:28] <duck> likely a lot like drupal
            
-
            [23:28] <hypercubus> yeah i've run plone before
            
-
            [23:29] <duck> Nightblade: I have been thinking about using airhook to manage those
            
-
            [23:29] <duck> but so far only some basic thought
            
-
            [23:29] <hypercubus> anything goes for the wiki content, or does it center on something in particular?
            
-
            [23:29] <Nightblade> i think airhook is GPLed
            
-
            [23:29] <duck> the protocol
            
-
            [23:29] <duck> not the code
            
-
            [23:29] <Nightblade> ah :)
            
-
            [23:30] <duck> hypercubus: he wants quality content, and lets you provide that :)
            
-
            [23:30] <Masterboy> upload the best pr0n of yourself you have got hyper;P
            
-
            [23:30] <duck> ok
            
-
            [23:30] * Masterboy will try to do that too
            
-
            [23:30] <hypercubus> yeah, anyone running an open wiki is just asking for quality content ;-)
            
-
            [23:31] <duck> ok
            
-
            [23:31] * duck moves to #3
            
-
            [23:31] <duck> * 3) testnet status
            
-
            [23:31] <Nightblade> Airhook gracefully handles intermittent, unreliable, or delayed networks  <-- hehe not an 
            
-
              optimistic description of I2P!
            
-
            [23:31] <duck> how has it been going?
            
-
            [23:32] <duck> lets put the datagram over i2p discussion to the end
            
-
            [23:32] <tessier> I love to run around to open wiki's and link to this: http://www.fissure.org/humour/pics/squirre
            
-
              l.jpg
            
-
            [23:32] <tessier> airhook rocks
            
-
            [23:32] <tessier> I've been looking at it for building a p2p network also.
            
-
            [23:32] <Nightblade> it seems to be reliable to me (#3)
            
-
            [23:32] <Nightblade> best i've seen so far
            
-
            [23:33] <duck> yeah
            
-
            [23:33] <mihi> works well - at least for stop&go audio streaming
            
-
            [23:33] <duck> I see quite impressive uptimes on irc
            
-
            [23:33] <hypercubus> agreed... seeing lots more blue guys in my router console
            
-
            [23:33] <Nightblade> mihi: are you listening to techno ? :)
            
-
            [23:33] <duck> but hard to tell since bogobot doesnt seem to handle connections that go over 00:00
            
-
            [23:33] <tessier> audio streaming works great for me but loading websites often takes a number of tries
            
-
            [23:33] <Masterboy> i have an opinion that i2p runs very good after 6 hours of use in the 6th hour i used the irc 
            
-
              for 7 hours and so my router was running for 13hours
            
-
            [23:33] <duck> (*hint*)
            
-
            [23:34] <hypercubus> duck: er... heheh
            
-
            [23:34] <hypercubus> i could fix that i guess
            
-
            [23:34] <hypercubus> do you have the logging set for daily?
            
-
            [23:34] <duck> hypercubus++
            
-
            [23:34] <hypercubus> log rotation that is
            
-
            [23:34] <duck> oh yes
            
-
            [23:34] <duck> duck--
            
-
            [23:34] <hypercubus> that's why
            
-
            [23:34] <Nightblade> I was at work all day and turned on my computer and started i2p and was on duck's irc server 
            
-
              in just a few minutes
            
-
            [23:35] <duck> I have been seeing some weird DNFs
            
-
            [23:35] <duck> even when connecting to my own eepsites
            
-
            [23:35] <duck> (http://dev.i2p.net/bugzilla/show_bug.cgi?id=74)
            
-
            [23:35] <duck> I think that is what causes most problems now
            
-
            [23:35] <hypercubus> bogoparser will only analyze uptimes that occur wholly within a single logfile... so if the 
            
-
              logfile encompasses only 24 hours, nobody will show up as connected longer than 24 hours
            
-
            [23:35] <duck> Masterboy and ughabugha did also have it I think...
            
-
            [23:36] <Masterboy> yup
            
-
            [23:36] <duck> (fix it and you will win next weeks trophy for sure!)
            
-
            [23:37] <deer> <mihi> bogobot is excited? ;)
            
-
            [23:37] <Masterboy> i tried my web site and sometimes when i hit refresh it takes the other route? and i have to 
            
-
              wait for it to load but i never wait;P i hit it again and it shows instantly
            
-
            [23:37] <deer> <mihi> oops, sry. forgot that this is gated...
            
-
            [23:38] <duck> Masterboy: do the timeouts take 61 seconds?
            
-
            [23:39] <duck> mihi: bogobot set to weekly rotations now
            
-
            [23:39] * mihi has quit IRC ("bye, and have a nice meeting")
            
-
            [23:40] <Masterboy> sorry i didn't check it on my web site when i can't reatch it instantly i just hit refresh 
            
-
              and it loads instantly..
            
-
            [23:40] <duck> hm
            
-
            [23:40] <duck> well, it needs to be fixed
            
-
            [23:41] <duck> .... #4
            
-
            [23:41] <Masterboy> i think the route is given not the same eatch time
            
-
            [23:41] <duck> * 4) bounties
            
-
            [23:41] <duck> Masterboy: local connections should be cutted short
            
-
            [23:42] <duck> wilde had some bounty thoughts... you there?
            
-
            [23:42] <Masterboy> maybe it is a peer selection bug
            
-
            [23:42] <wilde> I'm not sure that was for the agenda really
            
-
            [23:42] <duck> oh
            
-
            [23:42] <wilde> ok but the thoughts were something like:
            
-
            [23:42] <Masterboy> i think then we go public the bounty system will work better
            
-
            [23:43] <Nightblade> masterboy: yes there are two tunnels for each connection, or that is how i understand it 
            
-
              from reading the router.config
            
-
            [23:43] <wilde> we could use this month to do some small advertising of i2p and increase the bounty pool a bit
            
-
            [23:43] <Masterboy> i can see that the Mute project is going good - they got 600$ and they didn't code a lot yet;P
            
-
            [23:44] <wilde> target against freedom communities, crypto people, etc
            
-
            [23:44] <Nightblade> I don't think jrandom wants advertising
            
-
            [23:44] <wilde> not public slashdot attention, no
            
-
            [23:44] <hypercubus> that's what i've observed as well
            
-
            [23:44] <Masterboy> i want to push it again - when we go public the system will work a lot better;P
            
-
            [23:45] <wilde> Masterboy: bounties could speed up myi2p development for example
            
-
            [23:45] <Masterboy> and as jr said no public till 1.0 and only some attention after 0.4
            
-
            [23:45] <Masterboy> *wrote
            
-
            [23:45] <wilde> when we have like $500+ for a bounty people could actually survive for some weeks
            
-
            [23:46] <hypercubus> the tricky part is, even if we target a small dev community, like *cough* Mute devs, those 
            
-
              guys might spread the word about i2p further than we'd like
            
-
            [23:46] <Nightblade> someone could make a career out of fixing i2p bugs
            
-
            [23:46] <hypercubus> and too soon
            
-
            [23:46] <wilde> i2p links are already in many public places
            
-
            [23:46] <Masterboy> you google and you can find i2p
            
-
-
            [23:47] <hypercubus> obscure public places ;-) (i saw the i2p link on a freesite... i'm lucky the damn freesite 
            
-
              even loaded!)
            
-
            [23:47] <wilde> http://en.wikipedia.org/wiki/I2p
            
-
            [23:47] <Masterboy> but i agree that no advertising till 0.4 is done
            
-
            [23:47] <Masterboy> wha???????
            
-
            [23:47] <wilde> http://www.ovmj.org/GNUnet/links.php3?xlang=English
            
-
            [23:48] <Masterboy> protol0l does a great job;P
            
-
            [23:48] <Masterboy> ;))))))
            
-
            [23:48] <hypercubus> nice typo ;-)
            
-
            [23:48] <wilde> ok anyway, I agree we should still keep I2P private (jr read this log ;)
            
-
            [23:49] <Masterboy> who did that?
            
-
            [23:49] <Masterboy> i think the Freenet crew discussion gave more attention..
            
-
            [23:50] <Masterboy> and jr discussing with toad give a lot info to the big public..
            
-
            [23:50] <Masterboy> so as in ughas wiki - we can all blame jr for that;P
            
-
            [23:50] <wilde> ok anyway, we'll see if we can bring in some $ without bringing in /.
            
-
            [23:50] <Masterboy> agreed
            
-
            [23:50] <hypercubus> the freenet dev list is hardly what i call the "big public" ;-)
            
-
            [23:50] <wilde> .
            
-
            [23:51] <hypercubus> wilde: you'll have a lot of $ sooner than you think ;-)
            
-
            [23:51] <wilde> oh come on, even my mum subscribe to freenet-devl
            
-
            [23:51] <duck> my mum reads through gmame
            
-
            [23:51] <deer> <clayboy> freenet-devl is being taught in schools here
            
-
            [23:52] <wilde> .
            
-
            [23:52] <Masterboy> so we will see more bounties after we go 0.4 stable..
            
-
            [23:53] <Masterboy> that is after 2 months;P
            
-
            [23:53] <wilde> where did that duck go?
            
-
            [23:53] <duck> thanks wilde 
            
-
            [23:53] <hypercubus> though as the only bounty claimant thus far, i have to say that the bounty money had no 
            
-
              bearing on my decision to take up the challenge
            
-
            [23:54] <wilde> hehe, it would if it been 100x
            
-
            [23:54] <duck> wyou are too good for the world
            
-
            [23:54] <Nightblade> haha
            
-
            [23:54] * duck moves to #5
            
-
            [23:54] <hypercubus> wilde, $100 doesn't mean shit to me ;-)
            
-
            [23:54] <duck> 100 * 10 = 1000
            
-
            [23:55] * duck pops("5 airhook")
            
-
            [23:55] <duck> tessier: got any real-world experience with it
            
-
            [23:55] <duck> (http://www.airhook.org/)
            
-
            [23:55] * Masterboy will try dis out:P
            
-
            [23:56] <duck> java implementation (dunno if it even works) http://cvs.ofb.net/airhook-j/
            
-
            [23:56] <duck> python implementation (a mess, did work in the past) http://cvs.sourceforge.net/viewcvs.py/khashmir
            
-
              /khashmir/airhook.py
            
-
            [23:58] * duck opens the rant-valve
            
-
            [23:58] <Nightblade> j one is also gpl
            
-
            [23:58] <duck> port it to pubdomain
            
-
            [23:58] <hypercubus> amen
            
-
            [23:58] <Nightblade> the entire protocol doc is only about 3 pages - it can't be that hard
            
-
            [23:59] <Masterboy> nothing is hard
            
-
            [23:59] <Masterboy> it's just not easy
            
-
            [23:59] <duck> I dont think that it is fully specced though
            
-
            [23:59] * hypercubus takes away masterboy's fortune cookies
            
-
            [23:59] <duck> you might need to dive into the C code for a reference implementation
            
-
            [00:00] <Nightblade> I would do it myself but I am busy with other i2p stuff right now
            
-
            [00:00] <Nightblade> (and also my full-time job)
            
-
            [00:00] <hypercubus> duck: maybe a bounty for it?
            
-
            [00:00] <Nightblade> there already is
            
-
            [00:00] <Masterboy> ?
            
-
            [00:00] <Masterboy> ahh Pseudonyms
            
-
            [00:00] <duck> it could be used at 2 levels
            
-
            [00:00] <duck> 1) as a transport besides TCP
            
-
            [00:01] <duck> 2) as a protocol to handle datagrams inside i2cp/sam
            
-
            [00:01] <hypercubus> that's worth serious consideration then
            
-
            [00:01] <hypercubus> </obvious>
            
-
-
            [00:02] <Nightblade> duck: i noticed that the repliable datagram in SAM has a maximum size of 31kb, whereas the 
            
-
              stream has a maximum size of 32kb - making me think that the sender's destination is sent with each packet in 
            
-
              repliable datagram mode, and only at the beginning for a stream mode -
            
-
            [00:02] <Masterboy> well airhook cvs is not very updated..
            
-
            [00:03] <Nightblade> making me think that it would be inefficient to make a protocol on top of the repliable 
            
-
              datagrams through sam
            
-
            [00:03] <duck> airhooks message size is 256 bytes, i2cp's is 32kb, so you need to atleast change a bit
            
-
            [00:04] <Nightblade> actually if you wanted to do the protocol in SAM you could just use the anoymous datagram 
            
-
              and have the first packet contain the sender's destination.... blah blah blah - i have lots of ideas but not 
            
-
              enough time to code them
            
-
            [00:06] <duck> then again you have to problems to verify signatures
            
-
            [00:06] <duck> so someone could send fake packages to you
            
-
            [00:06] <Masterboy> topic:::: SAM
            
-
            [00:06] <Masterboy> ;P
            
-
            [00:07] <Nightblade> true
            
-
            [00:08] <Nightblade> but if you sent back to that destination and there was no acknowledgement you'd know it was 
            
-
              a faker
            
-
            [00:08] <Nightblade> there woudl have to be a handshake
            
-
            [00:08] <duck> but you'll need aapplication level handshakes for that
            
-
            [00:08] <Nightblade> no not really
            
-
            [00:09] <Nightblade> just put it in a library for accessing SAM
            
-
            [00:09] <Nightblade> that is a bad way of doing though
            
-
            [00:09] <Nightblade> doing it though
            
-
            [00:09] <duck> you could also use seperated tunnels
            
-
            [00:09] <Nightblade> it shuold be in the streaming lib
            
-
            [00:11] <duck> yup. makes sense
            
-
            [00:12] <duck> ok
            
-
            [00:12] <duck> I am feeling *baff*-y
            
-
            [00:13] <Nightblade> ja
            
-
            [00:13] * duck *baffs*
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting93.html b/www.i2p2/pages/meeting93.html
deleted file mode 100644
index b93de222..00000000
--- a/www.i2p2/pages/meeting93.html
+++ /dev/null
@@ -1,280 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 93{% endblock %}
-{% block content %}
            
-
            21:02:08 <duck> Tue Jun  8 21:02:08 UTC 2004
            
-
            21:02:21 <duck> meeting time
            
-
            21:02:33 <duck> writeup is at http://dev.i2p.net/pipermail/i2p/2004-June/000268.html
            
-
            21:02:39 <duck> but I did make a mistake in the numbering
            
-
            21:02:45 <duck> so the first item 5 will be skipped
            
-
            21:02:53 <hypercubus> yay!
            
-
            21:03:03  * duck puts some ice in his beer
            
-
            21:03:14  * mihi 'd rename first #5 to #4 ;)
            
-
            21:03:27 <hypercubus> nah, let's just have two item 4's next week ;-)
            
-
            21:03:37  * duck renames 'hypercubus' to 'mihi'
            
-
            21:03:48 <hypercubus> yay!
            
-
            21:03:49 <duck> ok
            
-
            21:03:53 <duck> * 1) libsam
            
-
            21:04:02 <duck> is there a Nightblade in the channel?
            
-
            21:04:39 <duck> (idle     : 0 days 0 hours 0 mins 58 secs)
            
-
            21:05:03 <hypercubus> ;-)
            
-
            21:05:53  * duck reclaims the microphone
            
-
            21:06:15 <duck> Nightblade wrote a SAM lib for C / C++
            
-
            21:06:23 <duck> it compiles for me.. but that is all I can say :)
            
-
            21:06:37 <mihi> no test cases? ;)
            
-
            21:07:06 <duck> if there are any rFfreebsd users Nightblade might be interested in you
            
-
            21:07:08 <ugha_node> The strstr calls really annoyed me in the code. ;)
            
-
            21:07:27 <ugha_node> duck: What's a rFfreebsd?
            
-
            21:07:42 <duck> how I did type freebsd
            
-
            21:08:00 <mihi> rm -rF freebsd?
            
-
            21:08:29 <ugha_node> Too bad -F doesn't work with rm.
            
-
            21:08:30 <duck> ugha_node: its bsd licensed; so fix it
            
-
            21:08:41 <fvw> sounds sane to me :). Alas I uninstalled my last freebsd box a while back. I 
            
-
                            have accounts on other peoples' boxes though, and am willing to run testcases.
            
-
            21:08:43 <ugha_node> duck: I might. :)
            
-
            21:08:50 <duck> (damn BSD hippies)
            
-
            21:09:09 <duck> oh, nice and short frank
            
-
            21:09:17 <duck> mo libsam comments?
            
-
            21:09:49 <duck> fvw: I guess Nightblade will contact you if he has a need
            
-
            21:09:50  * fvw grumbles at perfectly sane unix behaviour for killing his irc client.
            
-
            21:10:02 <duck> but since his email was a week old be might have found something
            
-
            21:10:17 <mihi> fvw: ?
            
-
            21:10:24 <fvw> yeah, if someone wanted to take me up on my offer I sort of missed that. Feel 
            
-
                            free to send email or something.
            
-
            21:10:42  * duck hops to #2
            
-
            21:10:46 <hypercubus> uhm, to where? ;-)
            
-
            21:10:54 <duck> 2) browse i2p and normal web with one browser
            
-
            21:10:57 <fvw> fresh install, haven't yet told my zsh not to hup stuff in the bacgrkground. 
            
-
                            </offtopic>
            
-
-
            21:11:09 <fvw> hypercubus: I'm on the public mailinglist user list I think. fvw.i2p@var.cx
            
-
            21:12:11 <duck> there was some stuff about adding all TLDs to your brower proxy ignore list
            
-
            21:12:23 <fvw> does that require discussion? I think it was pretty much handled on the 
            
-
                            mailinglist.
            
-
            21:12:24 <duck> I think it is a dirty hack
            
-
            21:12:36 <fvw> yes, that was mentioned. Welcome back.
            
-
            21:12:47 <duck> fvw: I didnt read the thread :)
            
-
            21:13:12 <duck> okay, if you dont want to discuss it, move to #3
            
-
            21:13:19 <duck> * 3) chat channel
            
-
            21:13:23 <hypercubus> cervantes' script works perfectly on Konqueror 3.2.2, Firefox 0.8, and 
            
-
                                   Opera 7.51, all for Gentoo w/KDE 3.2.2
            
-
            21:13:39  * mihi places a flag on #4
            
-
            21:13:55 <duck> #i2p-chat is an alternative channel here for offtopic chat and light support
            
-
            21:14:08 <duck> I dont know who did regg it
            
-
            21:14:12 <hypercubus> i did
            
-
            21:14:17 <duck> so better be careful :)
            
-
            21:14:22 <fvw> ehm, there is no #4, just two #5's :)
            
-
            21:14:33 <hypercubus> i'll be lucky if i can remember the password when i need it ;-)
            
-
            21:14:33 <mihi> [22:27] -ChanServ-      Channel: #i2p-chat
            
-
            21:14:33 <mihi> [22:27] -ChanServ-      Contact: hypercubus <<ONLINE >>
            
-
-
            21:14:33 <mihi> [22:27] -ChanServ-    Alternate: cervantes <<ONLINE >>
            
-
            21:14:37 <mihi> [22:27] -ChanServ-   Registered: 4 days (0h 2m 41s) ago
            
-
            21:15:12 <hypercubus> i gave a few trusted peeps op powers for whenver i'm not around and 
            
-
                                   there's trouble
            
-
            21:15:24 <duck> sounds good
            
-
            21:15:39 <duck> it might be a bit overkill
            
-
            21:15:51 <hypercubus> you never know on IRC ;-)
            
-
            21:15:55 <duck> but after this protogirl did join here I thought it would be good to clean up 
            
-
                             this chan
            
-
            21:16:03 <hypercubus> heh
            
-
            21:16:27 <hypercubus> we'll need it for sure sometime in the next few months anyhow
            
-
            21:16:34 <duck> jups
            
-
            21:16:48 <duck> and then the freenode ppl will kick us out 
            
-
            21:16:55 <hypercubus> ;-)
            
-
            21:17:13 <duck> they dont like anything that isnt written in their kampf
            
-
            21:17:16 <duck> err
            
-
            21:17:44  * duck moves to $nextitem and triggers mihi's breakpoint
            
-
            21:17:47 <hypercubus> i figured tying the new channel in with support would legitimize it for 
            
-
                                   freenode
            
-
            21:18:47 <duck> hypercubus: you might be surprised
            
-
            21:19:04 <hypercubus> *cough* i admittedly didn't read all the policies...
            
-
            21:19:24 <duck> it is russian roullete
            
-
            21:19:39 <hypercubus> hmm, didn't think it would be quite that dire
            
-
            21:19:52  * duck is being negative
            
-
            21:19:54 <hypercubus> well i'll look into what we can do
            
-
            21:20:09 <fvw> sorry, I must have missed something. Why would freenode kick us off?
            
-
            21:20:21  * duck looks at the timeout counter for mihi's breakpoint
            
-
            21:20:32 <duck> fvw: they focus on development channels
            
-
            21:20:35 <mihi> ?
            
-
            21:20:53 <mihi> duck: the breakpoint triggers on /^4).*/
            
-
            21:21:01 <duck> mihi: but there is no #4
            
-
            21:21:06 <fvw> so? i2p is soo alpha that right now even support is development.
            
-
            21:21:11 <fvw> (and no, you may not quote me on that)
            
-
            21:21:36 <duck> fvw: you might not be familiar with the types of discussion that did happen 
            
-
                             on IIP
            
-
            21:21:38 <hypercubus> yeah but we have *2* channels for it
            
-
            21:21:45 <duck> and which will likely happen in #i2p channels
            
-
            21:22:04 <duck> I am pretty sure that freenode does not appreciate it.
            
-
            21:22:10 <Nightblade> i'm here now
            
-
            21:22:49 <hypercubus> we'll donate a margarita machine to them or something
            
-
            21:22:49 <mihi> duck: what do you refer to? the floods? or #cl? or what?
            
-
            21:23:08 <fvw> discussions on IIP or discussions on #iip? I've never seen anything apart from 
            
-
                            devel and support on #iip. And discussions on IIP would move to I2P, not 
            
-
                            #i2p@freenode.
            
-
            21:23:09 <duck> all kinds of non political correct talk
            
-
            21:23:36 <fvw> there's margarita machines? Ooh, me want.
            
-
            21:23:54 <duck> oh well
            
-
            21:24:38 <hypercubus> shall we revisit 2)?
            
-
            21:24:58 <duck> hypercubus: what do you have to add about the browser proxy?
            
-
            21:25:18 <hypercubus> oops, number 1... since nightblade just graced us with his presence ;-)
            
-
            21:25:33 <duck> Nightblade: we took the freedom to 'discuss' libsam
            
-
            21:25:42 <Nightblade> Ok, i'll say a few lines
            
-
            21:25:48 <hypercubus> but yeah i had something that wasn't brought up on the list about the 
            
-
                                   browser thing too now that i think about it
            
-
            21:25:56 <duck> Nightblade: fvw told us that he might be able to help with some freebsd 
            
-
                             testing
            
-
            21:26:20 <fvw> I don't have a freebsd machine anymore but I have accounts on freebsd 
            
-
                            machines, give me test cases and I'd be happy to run them.
            
-
            21:27:02 <Nightblade> I have started working on a C++ dht, which uses Libsam (C).  At this 
            
-
                                   point I have not gotten especially far although I've been working a lot 
            
-
                                   on it.  right now nodes in the dht can "ping" each other through a sam 
            
-
                                   data message
            
-
            21:27:09 <Nightblade> in the process i found a couple minor bugs in libsam
            
-
            21:27:18 <Nightblade> which i will post a new version of sometime in the future
            
-
            21:27:51 <ugha_node> Nightblade: Could you please remove those 'strstr' calls from libsam? :)
            
-
            21:27:52 <Nightblade> the test case is: try to compile it and report the errors to me
            
-
            21:28:01 <Nightblade> what is wrong with strstr
            
-
            21:28:21 <ugha_node> It's not meant to be used instead of strcmp.
            
-
            21:28:38 <Nightblade> oh yeah, also I am going to port libsam to windows, but that is not in 
            
-
                                   any near future
            
-
            21:29:07 <Nightblade> is there anything wrong with the way i am using it, besides aesthetics?
            
-
            21:29:15 <Nightblade> you can send me changes or tell me what you'd rather do
            
-
            21:29:19 <Nightblade> that just seemed the easiest way
            
-
            21:29:21 <ugha_node> Nightblade: I didn't notice any.
            
-
            21:29:32 <fvw> strcmp is more efficient than strstr ofcourse.
            
-
            21:29:36 <ugha_node> But I just skimmed through it.
            
-
            21:30:20 <ugha_node> fvw: You can occasionally exploit stuff which uses strstr instead of 
            
-
                                  strcmp, but that's not the case.
            
-
            21:31:22 <Nightblade> yeah now i see some places where i can change it
            
-
            21:31:28 <fvw> that too, but I'm assuming you'd have noted that. Well, actually, you'd have 
            
-
                            to use strncmp to prevent those exploits. But that's besides the point.
            
-
            21:31:31 <Nightblade> i don't remember why i did it that way
            
-
            21:31:57 <ugha_node> fvw: I agree.
            
-
            21:32:27 <Nightblade> oh now i remember why
            
-
            21:32:40 <Nightblade> it is a lazy way of not having to figure the length for strncmp
            
-
            21:32:49 <duck> heh
            
-
            21:32:52 <ugha_node> Nightblade: Heheh.
            
-
            21:33:01 <fvw> use min(strlen(foo), sizeof(*foo))
            
-
            21:33:04 <hypercubus> shall the spanking commence?
            
-
            21:33:15 <fvw> I thought the oral sex came first? *ducks*
            
-
            21:33:32 <fvw> right, next point I think. Hypercube had a comment about proxying?
            
-
            21:33:38 <hypercubus> heh
            
-
            21:33:54 <duck> bring it on!
            
-
            21:34:03 <Nightblade> i will make the changes for the next version - change some of them at 
            
-
                                   least
            
-
            21:34:25 <hypercubus> ok, well this had been discussed briefly in channel a few weeks back, 
            
-
                                   but i think it bears revisiting
            
-
            21:34:48 <deer> * Sugadude volunteers to perform the oral sex.
            
-
            21:34:59 <hypercubus> rather than adding TLD's to your browser's block list, or using the 
            
-
                                   proxy script, there's a third way
            
-
            21:35:29 <hypercubus> which shouldn't have the same drawbacks as the other two approaches 
            
-
                                   anonymity-wise
            
-
            21:36:17 <fvw> which I'll tell you for the cheap cheap price of $29.99? Spill it already!
            
-
            21:36:27 <hypercubus> and that would be to have the eeproxy re-write incoming html pages to 
            
-
                                   embed the page in a frameset... 
            
-
            21:36:58 <hypercubus> the main frame would contain the requested HTTP content, the other 
            
-
                                   frame would serve as a control bar
            
-
            21:37:13 <hypercubus> and would allow you to turn on/off proxying at will
            
-
            21:37:40 <hypercubus> and will also alert you, perhaps via colored borders or some other kind 
            
-
                                   of alert, that you're browsing non-anonymously
            
-
            21:37:54 <fvw> how are you going to prevent an i2p site (with javascript etc) from turning 
            
-
                            off anonimity?
            
-
            21:37:59  * duck tries to apply jrandom-skill-level-of tolerance
            
-
            21:37:59 <hypercubus> or that a link in an eepsite page leads to the RealWeb(tm)
            
-
            21:38:04 <duck> cool! make it!
            
-
            21:38:16 <fvw> you'll still have to do something fproxy-like, or make something 
            
-
                            non-browser-controlled for switching.
            
-
            21:38:29 <ugha_node> fvw: Right.
            
-
            21:39:10 <hypercubus> that's why i'm throwing this out here again, perhaps someone might have
            
-
                                    some ideas about how to secure this
            
-
            21:39:31 <hypercubus> but imo this is something that will be sorely needed for most i2p end 
            
-
                                   usrers
            
-
            21:39:33 <hypercubus> *users
            
-
            21:40:04 <hypercubus> because the TLD/proxy script/dedicated browser approaches are too much 
            
-
                                   to ask of your general net user
            
-
            21:40:29 <fvw> In the long run, I think an fproxy workalike is the best idea. But that's 
            
-
                            definately not a priority imho, and I don't actually think browsing sites will 
            
-
                            be the i2p killer app.
            
-
            21:40:42 <Sonium> What is the netDb anyway?
            
-
            21:40:59 <duck> Sonium: database of known routers
            
-
            21:41:10 <hypercubus> fproxy is too cumbersome for most users
            
-
            21:41:32 <Sonium> doesn't such a database compromise annonymity?
            
-
            21:41:39 <hypercubus> imo it's part of the reason freenet never caught on in the non-dev 
            
-
                                   community
            
-
            21:41:41 <fvw> hypercube: not necessarily. proxy autoconfiguragion ("pac") can make it as 
            
-
                            simple as filling in a single value in your browser config. I think we 
            
-
                            shouldn't underestimate the fact that in the foreseeable future, all the i2p 
            
-
                            users will be at least slightly clueful computer-wise. (all evidence on 
            
-
                            freenet-support notwithstanding)
            
-
            21:42:00 <ugha_node> Sonium: No, 'bad guys' could collect that information manually anyway.
            
-
            21:42:21 <Sonium> but if NetDb is down i2p is down, right?
            
-
            21:42:29 <fvw> hypercubus: Not really, I think the fact that it hasn't worked at all since 
            
-
                            early 0.5 is more to blame for that. </offtopic time="once again">
            
-
-
            21:42:44 <fvw> Sonium: you can have more than one netdb (anyone can run one)
            
-
            21:42:58 <hypercubus> we already have pac, and even though it works spectacularly from a tech 
            
-
                                   standpoint, realistically it's not going to protect the anonymity of 
            
-
                                   the avg. jog
            
-
            21:43:03 <hypercubus> *avg. joe
            
-
            21:43:22 <ugha_node> fvw: Err.. Every router has its own netDb.
            
-
            21:43:42 <duck> ok. I am about to pass out. be sure to *baff* the meeting closed after you 
            
-
                             are done
            
-
            21:43:52 <ugha_node> I2P has no central dependencies anymore.
            
-
            21:44:07 <hypercubus> ok, well i just wanted to get this idea formally in the logs ;-)
            
-
            21:44:30 <fvw> ugha_node: ok, a published netdb then. I don't actually run a node (yet), I'm 
            
-
                            not entirely up with the terminology.
            
-
            21:44:34 <ugha_node> Hmm. Didn't mihi want to say something?
            
-
            21:45:05  * fvw feeds duck coffee-flavoured chocolate to keep him up and running a little bit 
            
-
                      longer.
            
-
            21:45:07 <mihi> no :)
            
-
            21:45:21 <mihi> is duck a network device? ;)
            
-
            21:45:25 <ugha_node> mihi: Btw, are you going to take the window size increase bounty?
            
-
            21:45:28  * fvw feeds duck alcohol-flavoured chocolate to shut him down indefinately.
            
-
            21:45:30 <hypercubus> in swedish
            
-
            21:45:52 <mihi> ugha_node: what bounty?
            
-
            21:46:00 <hypercubus> okay, then on to 5), rant-a-rama? ;-)
            
-
            21:46:13 <ugha_node> mihi: http://www.i2p.net/node/view/224
            
-
            21:46:27  * duck eats some of fvw's chocolate
            
-
            21:47:16 <mihi> ugha_node: definitely no; sorry
            
-
            21:47:36 <ugha_node> mihi: Uh, okay. :(
            
-
            21:48:33  * mihi tried to hack up the "old" streaming api some time ago, but that one was too 
            
-
                      buggy...
            
-
            21:48:53 <mihi> but it would imho be easier to fix that one instead of fixing mine...
            
-
            21:49:21 <ugha_node> Heh.
            
-
            21:49:42 <hypercubus> so modest
            
-
            21:49:46 <mihi> since it already has some (broken) "reordering" support in it
            
-
            21:50:49 <Sonium> is there a way to ask deer how many people are on the i2p-#i2p channel?
            
-
            21:51:01 <duck> no
            
-
            21:51:08 <hypercubus> nope, but i can add that to bogobot
            
-
            21:51:08 <Sonium> :/
            
-
            21:51:11 <Nightblade> !list
            
-
            21:51:13 <deer> <duck> 10 ppl
            
-
            21:51:13 <hypercubus> after i finish the installer ;-)
            
-
            21:51:24 <Sonium> !list
            
-
            21:51:32 <Sonium> o_O
            
-
            21:51:35 <mihi> Sonium ;)
            
-
            21:51:38 <ugha_node> This is not an fserv channel!
            
-
            21:51:39 <Sonium> that was a trick!
            
-
            21:51:40 <ugha_node> :)
            
-
            21:51:41 <hypercubus> should be !who
            
-
            21:51:44 <deer> <duck> ant duck identiguy Pseudonym ugha2p bogobot hirvox jrandom Sugadude 
            
-
                             unknown
            
-
            21:51:48 <cervantes> oop missed the meeting
            
-
            21:51:57 <ugha_node> !list
            
-
            21:52:01 <Nightblade> !who
            
-
            21:52:11 <deer> <duck> !who-your-mom
            
-
            21:52:17 <mihi> !who !has !the !list ?
            
-
            21:52:21 <fvw> !yesletsallspamthechannelwithinoperativecommands
            
-
            21:52:33 <Nightblade> !ban fvw!*@*
            
-
            21:52:42 <mihi> !ban *!*@*
            
-
            21:52:50 <hypercubus> i sense a gavel coming down
            
-
            21:52:51 <duck> sounds like a good time to close it down
            
-
            21:52:55 <Sonium> btw, you should also implement an !8 command like chanserv has
            
-
            21:52:59 <fvw> right, now we have that settled, let's clo.. yes. that.
            
-
            21:53:00  * hypercubus is psychic
            
-
            21:53:05 <duck> *BAFF*
            
-
            21:53:11 <Nightblade> !baff
            
-
            21:53:12 <hypercubus> my hair, my hair
            
-
            21:53:24  * fvw points at hypercube and laughs. Your hair! Your hair!
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting95.html b/www.i2p2/pages/meeting95.html
deleted file mode 100644
index 8145fa03..00000000
--- a/www.i2p2/pages/meeting95.html
+++ /dev/null
@@ -1,287 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 95{% endblock %}
-{% block content %}
            
-
            14:00 < jrandom> 0) hi
            
-
            14:00 < jrandom> 1) status update
            
-
            14:00 < jrandom> 2) cvs HEAD
            
-
            14:00 < jrandom> 3) 0.4
            
-
            14:00 < jrandom> 4) 1.0
            
-
            14:00 < jrandom> 5) other activities
            
-
            14:00 < jrandom> 6) ???
            
-
            14:00 < jrandom> 0) hi
            
-
            14:00 < dm> 7) Profit!!
            
-
            14:00 < mihi> hi
            
-
            14:00 < cervantes> hello
            
-
            14:00 < dm> hi
            
-
            14:00 < fvw> hi dr nick
            
-
            14:01 < jrandom> for all those playing at home, we've got the status notes up @ http://dev.i2p.net/pipermail/i2p/2004-June/000286.html
            
-
            14:01 < jrandom> as we've done in the past, that contains the actual content - we get all meta here and discuss stuff
            
-
            14:01  * dm is playing at home. WINK WINK WINK.
            
-
            14:01 < jrandom> BrianR: this is where the LART comes in handy
            
-
            14:02 < jrandom> anyway, jumping into 1) status update
            
-
            14:02 < thecrypto> let's see if i can connect to an eepsite
            
-
            14:03 < jrandom> the other day we had a larger than usual # of routers jumping off the network, which i'm hoping is because a lot of the services on the network were b0rked due to my stupid bugs
            
-
            14:03  * mihi fires up his router
            
-
            14:03 < thecrypto> yah!
            
-
            14:03 < jrandom> if people are taking down their router for another reason (bugs, cpu/memory usage, etc) i'd really love to hear about it
            
-
            14:04 < dm> ok
            
-
            14:05 < BrianR> I must say, i2p is currently more well behaved than freenet on my machine... Both in bandwidth hogging and cpu/ram hogging.
            
-
            14:05 < jrandom> there's a really bad bug in cvs at the moment, but fixed locally - i'll have that committed later tonight (not sure if i'll do so before or after getting my new machine together)
            
-
            14:05 < jrandom> ah wikked
            
-
            14:06 < jrandom> well, to be fair, i2p does a lot less than freenet - once we have thousands of routers we'll see how it goes
            
-
            14:06 < dm> Why don't operating system's have per-application bandwidth limiting built-in? Is it a hard task?
            
-
            14:06 < BrianR> I'd like to do some stress testing with i2p's built in bandwidth limiting stuff though. How far along is that?
            
-
            14:06 < dm> All these projects wasting time implementing their own bandwidth limiting, seems silly.
            
-
            14:06 < fvw> dm: Linux does it, as does freebsd no doubt.
            
-
            14:07 < dm> Do they?
            
-
            14:07 < cervantes> netlimiter on windoze does it
            
-
            14:07 < BrianR> dm: It's not a hard task. There's lots of system level bandwidth limiting stuff available, for 'doze, linux, *bsd...
            
-
            14:07 < dm> Makes sense to put it in the OS if you ask me.
            
-
            14:07 < fvw> dm iptables marking + tc under linux; Using it right now, works like a charm.
            
-
            14:07 < jrandom> BrianR: its in pretty good shape - it'll be in the next 0.3.1.5 release (which i'm hoping to have out this week)
            
-
            14:07 < dm> But anyway...
            
-
            14:07 < BrianR> thing is, it often makes more sense to do limiting at the application level so you can make intelligent decisions about where to spend bandwidth first
            
-
            14:08 < jrandom> exactly
            
-
            14:08 < dm> That's a different problem.
            
-
            14:08 < jrandom> with bandwidth limiting within i2p, we know when we're saturating our limit and can refuse to participate in tunnels (etc)
            
-
            14:08 < BrianR> At the application level you have no idea which one of your TCP connections is going to lose a packet when you're above the system imposed TX limit.
            
-
            14:08 < fvw> actually, best would be to have the OS give proper feedback; But that's not relevant for i2p right now.
            
-
            14:09 < jrandom> true fvw, once we integrate i2p with tun/tap ;)
            
-
            14:09 < BrianR> fvw: You do get some feedback in terms of backpressure.. But it's hard to tell if backpressure is due to the remote side's link being slow or the local side..
            
-
            14:09 < dm> Put a bounty on patching windows to have per-application bandwidth limiting. Thanks.
            
-
            14:09 < jrandom> heh
            
-
            14:09 < fvw> "my stuff isn't arriving" and "this connection is being throttled now" are two entirely different things.
            
-
            14:09 < fvw> they sometimes overlap ofcourse.
            
-
            14:10 < dm> (extra $20 for having a small graph with bandwidth usage of each window in the window title bar... Next to the minimize buttons, etc)
            
-
            14:11 < jrandom> ok does anyone else have any network status related things to bring up?
            
-
            14:12 < BrianR> Oh.. That IRC connection monitoring thing..
            
-
            14:12 < duckie> I appologize for updating to cvs
            
-
            14:12 < jrandom> hehe
            
-
            14:12 < BrianR> Is there a MRTG graph of that or logs or something somewhere?
            
-
            14:12 < jrandom> bogobot right?  duck.i2p/bogo/ iirc?
            
-
            14:13 < duckie> something like that
            
-
            14:13 < jrandom> (its linked to off duck.i2p, my routers are down atm so i cant check)
            
-
            14:13 < duckie> linked to on http://duck.i2p/ uder the stats section
            
-
            14:13 < duckie> http://duck.i2p/bogobotlogs/
            
-
            14:14 < BrianR> it might be useful to extend that thing to act as a general reachability survey tool..
            
-
            14:15 < dm> You guys type reaaaaaaaaaaaaaaaally slowly.
            
-
            14:15 < deer> <cervantes> hypercubus has some enhancements on the backburner, but he's pretty busy with installer stuff atm
            
-
            14:16 < jrandom> BrianR: bogobot is just for passive irc tracking, but someone could modify i2ptunnel's ping command to support periodic checking?
            
-
            14:16 < jrandom> or someone could whip up a perl/SAM script ;)
            
-
            14:16 < BrianR> maybe some sort of script that produces a MRTG graph of endpoint reachability....
            
-
            14:16 < BrianR> jrandom: speaking of perl/sam, bring that up again when we get to the appropriate number in the agenda
            
-
            14:16 < duckie> doesnt the heartbeat thing do that?
            
-
            14:17 < BrianR> If it does, I couldn't make it work :(
            
-
            14:17 < jrandom> kind of - heartbeat tests heartbeat servers, not generic apps
            
-
            14:18 < BrianR> Yes... Like I want to see if I can successfully do a "GET /" on duck.i2p, and how long it took.
            
-
            14:18 < jrandom> but yes, once the net is in good shape, lots of people can run a heartbeat server and people can ping each other to measure network performance
            
-
            14:18 < Nightblade> pingflood too
            
-
            14:18 < dm> Is there a limit on GET strings?
            
-
            14:18 < dm> like if you have a really long URL, because of cgi parameters?
            
-
            14:19 < cervantes> 2047 characters iirc
            
-
            14:19 < jrandom> that wouldnt be too hard to put together
            
-
            14:19 < BrianR> dm: Depends on the web server... I think the RFC also specifies a minimum which must be suported.
            
-
            14:19 < jrandom> (er, an http tester)
            
-
            14:19 < dm> cervantes: thanks
            
-
            14:19 < dm> (just realized it might affect something I've been working on)
            
-
            14:20 < cervantes> you run into 2 problems, webserver support and client support
            
-
            14:20 < BrianR> have we stumbled off topic?
            
-
            14:20 < cervantes> both IE and Mozilla are 2047
            
-
            14:20 < cervantes> eer yep :)
            
-
            14:21 < dm> I got my answer, we can move on :)
            
-
            14:21 < jrandom> ok, i think that covers 1), now briefly to 2) cvs HEAD
            
-
            14:21 < jrandom> there's a nasty bug in there currently, and i apologize for not fixing it sooner
            
-
            14:22 < jrandom> in general, if you try out cvs HEAD and it doesnt work well, just roll back (download jars / pull from the tag)
            
-
            14:22 < jrandom> anyway, 'nuff 'bout that
            
-
            14:23 < jrandom> jumping forward to 3) 0.4
            
-
            14:23 < jrandom> the email has my viewpoint / rational for the release - anyone have any concerns / questions / ideas / suggestions?
            
-
            14:24 < Nightblade> looks good to me
            
-
            14:24 < duckie> how does it change the time estimates?
            
-
            14:24  * fvw nods. Sane and everything.
            
-
            14:25 < jrandom> it actually moves 0.4 closer, as we're pushing the scary parts of 0.3.3 into 0.4.1 and 0.4.2
            
-
            14:25 < jrandom> i dont think it'll change the 1.0 dates, just moving things around before it
            
-
            14:26 < jrandom> the sim has shown our main problem with tunnel diversification can be easily remedied by active peer testing
            
-
            14:26 < jrandom> we had some of this in the pre 0.2.3 revs, but stopped that since it seemed to add too much overhead
            
-
            14:27 < jrandom> (when in fact lots of shit was just plain broken, causing the overhead)
            
-
            14:27 < deer> <cervantes> what does active peer testing involve?
            
-
            14:29 < jrandom> it just means we'll build some secondary tunnels through peers we wouldnt normally use - specifically, i'm going to have it pull random peers from the 'reliable' set who arent in the 'fast+reliable' set
            
-
            14:29 < jrandom> (and if that intersection is too small, extend it to the 'not failing' set)
            
-
            14:29 < jrandom> i dont know how many tunnels or peers to test yet, we'll probably keep that as a tunable parameter
            
-
            14:30 < jrandom> the issue manifests itself in the peer profiles - you'll see lots of values for your favorite peers, but lots of 0s or other low numbers for other peers
            
-
            14:30 < jrandom> (which may be due to them being shitty, or more likely due to them not being tested)
            
-
            14:31 < jrandom> ok, anything else on 0.4?  or should we move on to 4) 1.0?
            
-
            14:32 < duckie> yes
            
-
            14:33 < jrandom> 4) 1.0
            
-
            14:33 < jrandom> i dont see 1.0 as a big scary asymptotically approached release.  its just a release where things work and people can use it
            
-
            14:34 < jrandom> that said, anyone have any concerns / ideas / suggestions/ questions wrt whats in the mail?
            
-
            14:35 < dm> The rate at which the versioning is increasing would indeed indicate that it is an asymptotically approached 1.0
            
-
            14:36 < dm> We're gonna need some big jumps!
            
-
            14:36 < jrandom> 0.4--> 1.0
            
-
            14:36 < dm> Sweeeeeeeet....
            
-
            14:36 < jrandom> and we're only a few weeks from 0.4
            
-
            14:37 < jrandom> but, of course, we could use some help to get things moving faster :)
            
-
            14:37 < dm> Are we happy with stability then?
            
-
            14:37 < jrandom> no, stability right now sucks
            
-
            14:37 < cervantes> myi2p could be a fairly hefty bit of development to get implemented properly, since it ideally relies on other projects coming to fruition
            
-
            14:37 < dm> Okay, haven't been following closely.
            
-
            14:38 < cervantes> such as DHT and datagrams etc
            
-
            14:38 < jrandom> agreed cervantes, but if we just have it with the address book and distributed blogging, that'll be good enough for me.
            
-
            14:38 < cervantes> right
            
-
            14:38 < jrandom> nightblade is working on a dht that we can plug in whenever its ready, or we could add hooks for referencing freenet:CHK@ or SSK@
            
-
            14:39 < cervantes> private messaging is just a small hop from the syndicated address book too
            
-
            14:39 < jrandom> right, its all doable
            
-
            14:40 < cervantes> live streaming cam girl desktop might take longer...
            
-
            14:40 -!- Irssi: #i2p: Total of 21 nicks [0 ops, 0 halfops, 0 voices, 21 normal]
            
-
            14:40 < jrandom> heh
            
-
            14:40 < jrandom> actually, as I mentioned to Sonium before the meeting, one of the things people can help out with is the documentation front -
            
-
            14:41 < jrandom> defining what docs we will need, starting to do some outlines of how those docs will fit together, and perhaps even tossing open an editor and writing 'em
            
-
            14:42 < cervantes> ah I meant to enquire earlier about enhancing the console GUI too
            
-
            14:42 < jrandom> docs are an essential part of the releases, both for tech docs (since without good tech docs, no devs will get involved) and for user docs (since without good user docs, users will leave)
            
-
            14:42 < jrandom> that we'll want for the 0.4 release, and will be jsp/servlet driven
            
-
            14:43 < jrandom> i havent done any mockups or workflows for that even, so if someone wants to jump on that, we could use the help
            
-
            14:43 < Nightblade> console GUI?  what is that - SVGALIB? :)
            
-
            14:43 < jrandom> heh
            
-
            14:43 < mihi> Nightblade: TWIN / curses
            
-
            14:43 < cervantes> is the data set the same or are there new and improved stats for 0.4
            
-
            14:44 < dm> I want a console gui in WIN32/MFC
            
-
            14:44 < Nightblade> the http console on 7655 right
            
-
            14:44 < cervantes> ie the duration that elephants stay on the moon, and whether they return freuqently
            
-
            14:44 < cervantes> yup
            
-
            14:44 < jrandom> all of the things on the console now reflect data that can be made available to a 0.4 console, but we should totally throw out its existing design
            
-
            14:45 < jrandom> (e.g. no one cares what the base64 of a routerIdentity's public key is)
            
-
            14:45 < cervantes> although I suggest that info should still be available
            
-
            14:46 < jrandom> yeah, i think we may keep the existing console as an option - no need to throw it away
            
-
            14:46 < jrandom> (but it'd be something like http://localhost:7655/uglyConsole/)
            
-
            14:46 < cervantes> ./forlynxusers/
            
-
            14:47 < jrandom> the new admin console should work for lynx users too
            
-
            14:47 < dm> Does anyone really use lynx?
            
-
            14:47 < cervantes> eeew cross browser compatibility
            
-
            14:47 < jrandom> i do
            
-
            14:47 < jrandom> (at times)
            
-
            14:47 < dm> but.... why?
            
-
            14:47 < fvw> for things like brief config edits, definately.
            
-
            14:47 < cervantes> dm: if you're stuck at a command prompt you don't have much choice
            
-
            14:47 < fvw> it's quick and you don't need X
            
-
            14:48 < Nightblade> i use it for web browsing on headless servers
            
-
            14:48 < deer> <Pseudonym> I use links browser
            
-
            14:48 < jrandom> well, yeah, links is preferable to lynx
            
-
            14:48 < mihi> anyone using w3m?
            
-
            14:48 < dm> I use INTERNET EXPLORER FROM MICROSOFT
            
-
            14:48 < dm> It's quite cool.
            
-
            14:48 < jrandom> good point - anything else wrt i2p 1.0?
            
-
            14:49 < dm> Won the browser war of 1992-1998
            
-
            14:49 < jrandom> or moving on to 5) other activites?
            
-
            14:49 < dm> 3 medals of honor.
            
-
            14:49 < Nightblade> yes
            
-
            14:49 < Nightblade> I am hoping to release a new version of libsam tomorrow but my home computer is broke so I don't know
            
-
            14:49 < Nightblade> I am going to also upload Nickster's threading library
            
-
            14:49 < jrandom> awesome!/doh!
            
-
            14:50 < jrandom> nice!
            
-
            14:50 < Nightblade> which he said was public domain - i am just going to upload it exactly as he sent it - i haven't had time to do much with it
            
-
            14:50 < jrandom> once 0.3.1.5 is out, i'll start running the cvs server on i2p as well
            
-
            14:50 < jrandom> cool
            
-
            14:51 < jrandom> (so nickster will be able to make edits/updates to his code in cvs without exposing his ip)
            
-
            14:51 < jrandom> whats new in the next rev of libsam?
            
-
            14:51 < Nightblade> some fixes to datagram send/receive which were broken
            
-
            14:51 < Nightblade> and some other stuff i don't remember
            
-
            14:51 < Nightblade> it iwll be in the changelog
            
-
            14:51 < jrandom> cool, sounds good
            
-
            14:52 < jrandom> btw, if you want a mailing list for libsam (-announce,-dev,-users,etc) lemmie know
            
-
            14:52 < jrandom> (but posting on i2p@i2p is fine too)
            
-
            14:52 < Nightblade> overkill
            
-
            14:52 < jrandom> hehe
            
-
            14:53 < jrandom> yeah prolly
            
-
            14:53 < cervantes> he can have a section in i2pforum
            
-
            14:53  * cervantes moves smoothly onto his agenda
            
-
            14:53 < Nightblade> maybe once I get that DHT working - but that is a long way off, and today and yesterday I hvane't had time to do much with it
            
-
            14:53 < Nightblade> cervantes: there is already an application development forum or somethihng like that iirc
            
-
            14:53 < Nightblade> also Connelly needs an account on i2p.net if someone has gotten him one yet
            
-
            14:53 < cervantes> specifically in relation to i2p?
            
-
            14:54 < Nightblade> http://www.i2p.net/forum/3
            
-
            14:54 < jrandom> oh, i havent added an account for connelly, i'll chat with 'im next time i see him
            
-
            14:54 < fvw> dang, got to run. See you all next week, keep up the good work.
            
-
            14:54 < jrandom> ugh, yeah, i dont know about the www.i2p.net/forum/s
            
-
            14:54 < cervantes> ah...drupal...
            
-
            14:55 < jrandom> cool fvw, glad you could make it
            
-
            14:56 < cervantes> the i2pforum is pretty much set up
            
-
            14:56 < cervantes> it basically just needs content/users to fill it :)
            
-
            14:56 < jrandom> i'm not sure about the drupal forums, or whether they really fit with what i see the website being.  i kind of like the idea of a seperate site thats dedicated to being a user/dev forum
            
-
            14:57 < jrandom> cool cervantes - is that as an eepsite, website, or both?
            
-
            14:57 < cervantes> I've picked arbitrary forum topics/sections so if people have any ideas or want to write stuff for FAQs etc them that would be appreciated
            
-
            14:57 < cervantes> it's both
            
-
            14:58 < cervantes> currently I have the i2p tunnel offline while my router is so unstable
            
-
            14:58 < jrandom> cant say i blame you :)
            
-
            14:58 < Nightblade> what is the url
            
-
            14:58 < cervantes> but people can start playing on outweb
            
-
            14:59 < cervantes> currenlty you'll have to add an entry to /etc/hosts c:/windows/system32/drivers/etc/hosts
            
-
            14:59 < cervantes> 212.113.22.104 i2pforum.cervantes.not2p
            
-
            14:59 < jrandom> heh
            
-
            15:00 < cervantes> I'll configure it with a proper hostname soon
            
-
            15:00 < cervantes> or if someone wants to add a subdomain pointer to the php.net domain record...that would be better
            
-
            15:00 < jrandom> lemmie know if you want something under the i2p.net domain or if you're going with another domain thats cool
            
-
            15:00 < cervantes> blah
            
-
            15:00 < cervantes> i2p.net
            
-
            15:00 < cervantes> <-- php on the brain
            
-
            15:01 < jrandom> do you want that to be e.g. forum.i2p.net?
            
-
            15:01 < cervantes> that would be cool ;-)
            
-
            15:01 < jrandom> w3rd, i'll update the records tonight
            
-
            15:01 < cervantes> I've tweaked standard phpbb2 code so it doesn't require a valid email to become a member
            
-
            15:01 < dm> "The site you requested is no longer hosted here"
            
-
            15:02 < cervantes> if you forget your pass then you have to contact an admin
            
-
            15:02 < cervantes> dm: did you enter that into your hosts file or are you just browsing to the IP
            
-
            15:03 < dm>                                   Invalid URI in request GET i2pforum.cervantes.
            
-
            15:03 < dm> not2p/<P>
            
-
-
            15:03 < dm> I don't use browsers, I'm using telnet.
            
-
            15:04 < jrandom> i did it through telnet just now.  works fine.
            
-
            15:04 < dm> hmm forgot the HTTP 1.1 I think.
            
-
            15:04 < jrandom> GET / HTTP/1.1\nHost: i2pforum.cervantes.not2p\n\n
            
-
            15:04 < jrandom> anyway
            
-
            15:04 < jrandom> BrianR: ping
            
-
            15:05 < dm> That worked. Your telnetting skills are sharp, young one.
            
-
            15:07 -!- Irssi: #i2p: Total of 19 nicks [0 ops, 0 halfops, 0 voices, 19 normal]
            
-
            15:07 < jrandom> ok, anyone else working on i2p related projects they want to discuss?
            
-
            15:07 < jrandom> if not, 6) ???
            
-
            15:07 < dm> cum!
            
-
            15:07  * wern put a hand in the air
            
-
            15:07 < jrandom> hi^2, que tal?
            
-
            15:08  * jrandom calls on wilde
            
-
            15:08 -!- wern is now known as wilde
            
-
            15:08 < wilde> I just want to thank our new sponsors, cervantes and hypercubus
            
-
            15:08 < wilde> :)
            
-
            15:09 < wilde> we got two generous donations to the general fund
            
-
            15:09 < cervantes> wilde: did they convert ok?
            
-
            15:09 < dm> how much?
            
-
            15:09 < wilde> cervantes: will exchange them tomorrow
            
-
            15:09 < cervantes> ah
            
-
            15:09 < wilde> (hopefully)
            
-
            15:10 < cervantes> so there still might be a runner-up prize ;-)
            
-
            15:10 < jrandom> awesome, thanks cervantes & hypercubus :)
            
-
            15:10 < cervantes> heh...well save praise until the money is in the bank I think ;-)
            
-
            15:11 < dm> twas a good meeting. I'm off to bed.
            
-
            15:11 < dm> Nite!
            
-
            15:11 < jrandom> 'night dm
            
-
            15:11 < wilde> yeah, I'll do the full praising next time
            
-
            15:11 < jrandom> ok, anything else to add wilde, or someone else?
            
-
            15:11 < wilde> yeah
            
-
            15:12 < wilde> I'll take the i2p.net site down tomorrow for a while (intentionally this time ;)
            
-
            15:12 < wilde> to switch servers
            
-
            15:12 < jrandom> heh ok cool
            
-
            15:12 < wilde> hold on to your posts, they may disappear
            
-
            15:12 < jrandom> will we have the same IP, or should I update the records?
            
-
            15:12 < dm> can you make it seamless?
            
-
            15:12 < wilde> if you post tomorrow that is
            
-
            15:13 < wilde> dm: no way ;)
            
-
            15:13 < wilde> not me
            
-
            15:13 < dm> okay.
            
-
            15:13 < wilde> jrandom: same IP
            
-
            15:13 < jrandom> ok cool
            
-
            15:13 < jrandom> wilde++
            
-
            15:13 < wilde> over and out
            
-
            15:14 < jrandom> ok, anyone else have something they'd like to discuss?
            
-
            15:14  * cervantes puts on his metal "ming the merciless" skullcap
            
-
            15:14 < jrandom> in that case
            
-
            15:15  * jrandom winds up
            
-
            15:15  * jrandom *baf*s cervantes on the head, closing the meeting
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meeting99.html b/www.i2p2/pages/meeting99.html
deleted file mode 100644
index 85abb28b..00000000
--- a/www.i2p2/pages/meeting99.html
+++ /dev/null
@@ -1,203 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 99{% endblock %}
-{% block content %}
            I2P dev meeting, July 20 @ 21:00 GMT
            
-
            
-
            14:05 < jrandom> 0) hi
            
-
            14:05 < jrandom> 1) 0.3.2.3, 0.3.3, and the roadmap
            
-
            14:05 < jrandom> 2) s/reliability/capacity/g
            
-
            14:05 < jrandom> 3) website updates
            
-
            14:05 < jrandom> 4) attacks and defenses
            
-
            14:05 < jrandom> 5) ???
            
-
            14:05 < jrandom> 0) hi
            
-
            14:05  * jrandom waves 
            
-
            14:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html
            
-
            14:06 < jrandom> swingin right into 1) 0.3.2.3, 0.3.3, and the roadmap
            
-
            14:07 < jrandom> (while y'all read ahead, i assume ;)
            
-
            14:07 < jrandom> the 0.3.2.3 release is out there and seems to be doing well
            
-
            14:07 < jrandom> what are the main pain points people are seeing?
            
-
            14:08 < deer> <Nightblade> no trouble at all
            
-
            14:08 < deer> <duck> 4d uptime with no problems
            
-
            14:08 < jrandom> hmm, word
            
-
            14:08 < deer> <duck> for some irc doesnt seem too stable
            
-
            14:08 < deer> <duck> like kaji getting kicked ever minute
            
-
            14:08 < deer> <duck> but thats nothing new
            
-
            14:09 < jrandom> yeah that happens to him on the freenode network too, so i'm not sure what to blame there
            
-
            14:09 < deer> <duck> yeah
            
-
            14:09 < deer> <duck> connelly had some bad downloads afaik
            
-
            14:10 < deer> <duck> but you dont hear me complainin'
            
-
            14:10 < jrandom> ah really?  hmm, i think we found some of those were related to his lib, but i've experienced the occational failure on larger file transfers
            
-
            14:10 < jrandom> especially while leeching books from alexandria
            
-
            14:10 < jrandom> (well, not especially, but thats the only site i leech from)
            
-
            14:11 < deer> <duck> :)
            
-
            14:11 < jrandom> ok, well, my plan is that once the 0.3.3 release is out, my time will be focused on getting us to 0.4, along side any bugfixes people bring up
            
-
            14:12 < jrandom> the 0.4 work that is left is largely simple web stuff (new router console w/ servlets, jetty integration, servlet to control the router, and a servlet to config the i2ptunnel instances)
            
-
            14:13 < jrandom> perhaps some jsp/servlet folks can help out with some of that to get their feet wet with the code, though i've done plenty of that stuff before so impl won't be too tough
            
-
            14:13 < jrandom> afaik hypercubus' installer is pretty much good to go
            
-
            14:13 < jrandom> (though i threw some new work on him today ;)
            
-
            14:13 < deer> <duck> featurecreep++
            
-
            14:14 < jrandom> keeps people on their toes :)
            
-
            14:14 < jrandom> (but c'mon, everyone hates downloading all the jars seperately for upgrades)
            
-
            14:14 < deer> <duck> yes, that is my biggest problem with upgrading
            
-
            14:14 < deer> <duck> (though I use cvs)
            
-
            14:14 < deer> <duck> but it would be if I didn't
            
-
            14:15 < jrandom> heh
            
-
            14:15 < mihi> jrandom: just tar all of them -> 1 download ;)
            
-
            14:15 < jrandom> that'd be simple enough, and leave updgrade.sh/upgrade.bat == jar xf upgrade.jar
            
-
            14:16 < jrandom> (after a wget-esque call)
            
-
            14:16 < jrandom> well, i think hypercubus has the code to do all that stuff under control, so we can leave it up to him to do the Right Thing
            
-
            14:17 < jrandom> anyway, yeah, as y'all may have noticed, our schedule isn't quite what it was before 
            
-
            14:17 < jrandom> the roadmap has been updated and eeeellloooonnnggaattteedd
            
-
            14:18 < mihi> jjrraannddoomm::  cchheecckk yyoouurr dduupplleexx sswwiittcchh
            
-
            14:18 < deer> <Nightblade> hah
            
-
            14:18 < jrandom> heh
            
-
            14:18  * mihi made a mistake... who spots it first?
            
-
            14:19 < jrandom> (\n\n)
            
-
            14:19 < jrandom> but anyway
            
-
            14:19 < mihi> okay, another one ;)
            
-
            14:19 < duck> (no double spaces)
            
-
            14:19 < mihi> duck++
            
-
            14:20 < jrandom> i do think the roadmap is pretty realistic at least through the 1.0 release now, though depending upon the user adoption and feedback we may reorder or drop one of 0.4.2 or 0.4.3
            
-
            14:20 < jrandom> (and, of course, as always the roadmap is subject to change if more people get involved :)
            
-
            14:21 < modulus> maybe one day I will, after I learn java, but i2p doesn't sound like a project for a novice.
            
-
            14:21 < deer> <Sandworm> yeah, it'll take longer :)
            
-
            14:21 < deer> * duck expects some more slips along the road
            
-
            14:21 < modulus> :-)
            
-
            14:22 < deer> * duck can barely call it slips, look at the impressive table on http://www.i2p.net/redesign/announcements
            
-
            14:22 < jrandom> slips may happen of course, but i think the milestones left are all pretty doable
            
-
            14:22 < jrandom> yeah, thanks for showing that i have no life duck ;)
            
-
            14:22 < deer> <duck> this is your life
            
-
            14:22 < modulus> so, when's 1.0 out? :-)
            
-
            14:22 < deer> <duck> be proud of it
            
-
            14:23 < jrandom> modulus: while some parts of i2p are a bitch, there are a lot of pieces that can be tackled by a new developer pretty easily
            
-
            14:23 < modulus> probably rather boring parts though, no?
            
-
            14:24 < jrandom> naw, not at all.  for example, whipping up a neat anonymous file transfer or chat app, a mini webserver, a mud, a chess app, whatever
            
-
            14:24 < duck> (website updates)
            
-
            14:24 < modulus> hmm, sounds cool.
            
-
            14:24 < jrandom> (aka simple client apps that can be anonymous)
            
-
            14:24 < jrandom> and of course web updates ;)
            
-
            14:25 < modulus> what's this web updates deal?
            
-
            14:25 < jrandom> our website needs work (see http://dev.i2p.net/pipermail/i2p/2004-July/000358.html or wait a few minutes for agenda item 3)
            
-
            14:25 < cat-a-puss> Where does myi2p fit into all that?
            
-
            14:25 < modulus> ah ah
            
-
            14:26 < jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :)
            
-
            14:26 < modulus> methinks myi2p isn't a priority right now...
            
-
            14:26 < jrandom> (i just wrote a brief page about it a few hours back)
            
-
            14:27 < jrandom> as an aside, website updates are all posted to the i2pwww mailing list (http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html)
            
-
            14:28 < modulus> hmm, i could write a global naming ap :-)
            
-
            14:28 < jrandom> but i do still see the myi2p implementation (at least the base address book and blogging) being implemented for the 1.0 release
            
-
            14:28 < jrandom> (per the roadmap, slated for november)
            
-
            14:28 < jrandom> yes, you certainly could
            
-
            14:28 < modulus> something simpler than DNS, with authentication and delegation of TLD's
            
-
            14:28 < jrandom> it wouldnt be a bad thing to have either - a simple app that you could query a central name server would be nice
            
-
            14:29 < modulus> yep
            
-
            14:29 < jrandom> so, get coding :)
            
-
            14:29 < modulus> I'll start tomorrow. beat me up if i'm on other things ;-)
            
-
            14:29 < jrandom> hehe cool, shall do
            
-
            14:29 < jrandom> ok, moving on to 2) s/reliability/capacity/g
            
-
            14:29 < duck> small questio on the site:
            
-
            14:29 < duck> oh wait
            
-
            14:29 < duck> thats 3
            
-
            14:29 < duck> sorry
            
-
            14:29 < jrandom> sure, sup?
            
-
            14:30 < jrandom> ah, 'k
            
-
            14:30 < jrandom> there is going to be a fairly fundamental change to the peer profiling and selection code in the 0.3.3 release, as described in the email and http://www.i2p.net/redesign/how_peerselection
            
-
            14:31 < jrandom> i've got it running on a pair of routers atm and it seems fairly well behaved (Speed: 25.18 (5 fast peers)  Capacity: 17.50 (8 high capacity peers)  Integration: 37.00 (2 well integrated peers))
            
-
            14:31 < jrandom> and no more negative values :)
            
-
            14:31 < modulus> :)
            
-
            14:32 < jrandom> i'm going to kick the tires a bit more, perhaps for another day or two, and then push 'er out as 0.3.3
            
-
            14:32 < cat-a-puss> d
            
-
            14:32 < cat-a-puss> <modulus>
            
-
            14:32 < cat-a-puss> oops
            
-
            14:33 < duck> suggesting against updating cvs?
            
-
            14:33 < cat-a-puss> to do dns look at a cache of http://www.levien.com/thesis/compact.pdf
            
-
            14:33 < jrandom> nope, cvs is fairly stable atm
            
-
            14:33 < jrandom> (but as always, be prepared to fall back if some nastiness hits)
            
-
            14:35 < jrandom> looks cool cat-a-puss, thanks
            
-
            14:35 < cat-a-puss> (I have a copy of the origional if anyone wants it)
            
-
            14:36 < jrandom> the google cache kind of garbles the images a bit, so if you have the raw pdf that'd be great
            
-
            14:36 < jrandom> anyway, we're sliding a bit off topic for the moment (but we can get back to this)
            
-
            14:37 < jrandom> that's about it for the reliability/capacity switch, so moving on to 3) website updates
            
-
            14:37 < jrandom> duck: you had something you wanted to bring up?
            
-
            14:38 < jrandom> while duck prepares his notes, perhaps anyone has any ideas/suggestions/concerns wrt the items posted in the email?
            
-
            14:39 < deer> <Nightblade> the website looks  good
            
-
            14:39 < jrandom> yeah, i like the new nav and the site layout is quite clean
            
-
            14:40 < deer> <Nightblade> easier to find stuff
            
-
            14:40 < cervantes> _much_ easier to find stuff
            
-
            14:40 < duck> first of all I want to thank our user advocate protocol for becoming useful :)
            
-
            14:40 < jrandom> heh
            
-
            14:40 < duck> he had some good suggestions and he did just start
            
-
            14:40 < cervantes> hip hip horray!
            
-
            14:40 < jrandom> (hear hear!)
            
-
            14:41 < duck> next I think that there is barely a reason not to put the redesign up for real
            
-
            14:42 < jrandom> agreed - perhaps we can just mark the news/development/documentation as non page nav elements, drop the jvm and config tweaks for the moment, and get some basic content for the I2PTunnel page, i think we can deploy it 
            
-
            14:42 < jrandom> i just want it to go live with all links working (and all pages that arent working)
            
-
            14:43 < jrandom> there will of course be further updates after it goes life ;)
            
-
            14:43 < jrandom> er, live
            
-
            14:44 < jrandom> as an aside, wilde has hooked up our 34sp account too, so we'll be able to migrate the site over there when necessary
            
-
            14:44 < cervantes> coolio
            
-
            14:44 < jrandom> thoughts duck?  can the menu.php thingy handle non-page nav entries?  
            
-
            14:44  * cervantes checks his inbox for referal points
            
-
            14:45 < jrandom> (or would it be too much effort to mod that in?)
            
-
            14:45 < jrandom> hehe cervantes, that should be on the way
            
-
            14:45 < cervantes> ;-)
            
-
            14:45 < cervantes> ah the old "cheque's in the post" gambit
            
-
            14:47 < duck> sorry; doing some other work in the meanwhile.
            
-
            14:47 < duck> ok; yes possible to make it nav section title only
            
-
            14:47 < jrandom> np, we can move on and come back to it later if you'd prefer
            
-
            14:47 < jrandom> ok cool
            
-
            14:47 < jrandom> (duck++)
            
-
            14:48 < jrandom> ok, any other website related stuff?  
            
-
            14:48 < duck> with your suggestion it sounds ready for up.
            
-
            14:48 < jrandom> if not, we can move on to 4) attacks and defenses
            
-
            14:48 < duck> .
            
-
            14:48 < jrandom> word
            
-
            14:49 < jrandom> ok, i'm assuming y'all read the mailing list and have seen connelly's posts and the various replies
            
-
            14:50 < cervantes> he's been busy :)
            
-
            14:50 < cervantes> (almost as much as proto)
            
-
            14:50 < Connelly> imo, the network looks sound to all except traffic analysis (sites with lots of traffic), and government connection-severing attacks, and for attackers taking over a large majority of the net
            
-
            14:50 < jrandom> while i think we're in pretty good shape, i'm certain that there must be something (or things) we've missed, so please don't assume i2p does or will do what it says - challenge the assumptions and say why it sucks
            
-
            14:50 < Connelly> the encryption pretty much screws over any non-aggressive attacks
            
-
            14:51 < jrandom> that is the hope
            
-
            14:51 < jrandom> plus with i2p 2.0 and 3.0 capabilities, defenses for attacks by govt scale adversaries will be possible
            
-
            14:51 < Connelly> course in practice there will be security holes to patch
            
-
            14:52  * jrandom still needs to write up some docs as to how the 3.0 delays will prevent segmentation attacks
            
-
            14:52 < jrandom> certainly connelly
            
-
            14:54 < jrandom> ok, if there's nothing more along those lines, i think thats all i've got
            
-
            14:54 < jrandom> so 5) ???
            
-
            14:55 < jrandom> oh, as an aside, i plotted the bandwidth usage vs. # tunnels participated in graph for one of the simulations over a 4 day period
            
-
            14:55 < jrandom> thats posted up @ http://dev.i2p.net/~jrandom/4daybandwidth.png
            
-
            14:56 < jrandom> the sim had 32KB messages sent back and forth every 30s, with two routers choked at 6KBps, and things behaved exactly as they 'should'
            
-
            14:56 < duck> (nolink property implemented for the site)
            
-
            14:56 < jrandom> (e.g. load distributed over the fast reliable peers, slow peers avoided, etc)
            
-
            14:56 < jrandom> w00t
            
-
            14:56 < Connelly> a log plot of bandwidth/user vs network size would be nice
            
-
            14:57 < Connelly> so you can say 'yeah, it really scales'
            
-
            14:58 < jrandom> that wouldnt even need a log plot - the scalability of client comm is strictly O(1) [requiring 2k*msgSize, where k = # hops in the tunnel]
            
-
            14:58 < jrandom> but yeah, I agree, we need some docs describing how i2p scales
            
-
            14:58 < Connelly> well for kademlia ... is that in your sim?
            
-
            14:58 < jrandom> yeah, the sim is actually the full blown router code, all run in a single JVM
            
-
            14:58 < jrandom> i'm running it even with the full TCP connections instead of the VM comm system too
            
-
            14:59 < jrandom> the kademlia code is used for the first time Alice wants to contact Bob - as long as they continue talking, their communication is O(1) as they bundle their LeaseSet along with the payload
            
-
            14:59 < jrandom> (so there are no needs for subsequent netDb lookups)
            
-
            15:00 < cervantes> vl07 and onb0 are the choked routers?
            
-
            15:00 < jrandom> but yeah, we need a simulation to demonstrate how the netDb itself scales
            
-
            15:01 < jrandom> cevantes: 0jvf and onb0
            
-
            15:01 < cervantes> what accounts for vl07's dive after a days uptime?
            
-
            15:02 < cervantes> seems to cross over with 00u0
            
-
            15:02 < jrandom> all of the non-choked routers are essentially equal - they're all on the same CPU, all have the same (0ms) lag, so the allocation of one as 'fast' vs 'reliable' is just arbitrary
            
-
            15:04 < Connelly> do your designations of 'fast and reliable', 'slow' etc recover from large values?
            
-
            15:04 < jrandom> why did it reduce its ranking/usage after a day?  i'm not sure, perhaps a transient cpu or io overhead while it was being tested caused its speed to reduce a bit
            
-
            15:04 < jrandom> yes, the rankings use the median now, not the mean, plus there is a fiarly fast decay on the data
            
-
            15:05 < jrandom> s/fiarly/fairly/
            
-
            15:05 < Connelly> so if i make you think my reliability is 1000000000, you can recover when i start dropping messages
            
-
            15:06 < jrandom> certainly - if you 'fail' i immediately stop asking you to do things and decrease your ranking
            
-
            15:06 < jrandom> the new "capacity" calculation in turn is quite sensitive to those types of changes
            
-
            15:06 < jrandom> (speed is kind of hard to fake too, as all speed ranks are actual measured values)
            
-
            15:07 < jrandom> ((as was the reliability, and as is the capacity calc))
            
-
            15:09 < jrandom> ok, anyone else have anything they want to bring up?
            
-
            15:10 < deer> * jrandomi2p suggests the *baf*er
            
-
            15:11  * jrandom concurs
            
-
            15:11  * jrandom winds up
            
-
            15:11  * jrandom *baf*s the meeting closed
            
-
            
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/meetings.html b/www.i2p2/pages/meetings.html
deleted file mode 100644
index 40fc2c5a..00000000
--- a/www.i2p2/pages/meetings.html
+++ /dev/null
@@ -1,192 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Meetings{% endblock %}
-{% block content %}
-
            Logs of past I2P meetings
            
-
            If you have something to discuss, please find the developers on IRC in #i2p-dev.
-Status updates from developers are also available.
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/newdevelopers.html b/www.i2p2/pages/newdevelopers.html
deleted file mode 100644
index 5b107257..00000000
--- a/www.i2p2/pages/newdevelopers.html
+++ /dev/null
@@ -1,186 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}New Developer's Guide{% endblock %}
-{% block content %}
-
            
-  So you want to start work on I2P? Great!
-  Here's a quick guide to getting started
-  on contributing to the website or the software, doing development or creating translations.
-
            
-
            
-  Not quite ready for coding?
-  Try getting involved first.
-
            
-
-
-
-
            Basic 'study'
            
-
-
            
-  Basic development on the I2P router or the embedded applications uses Java as the main development language.
-  If you don't have experience with Java, you can always have a look at Thinking in Java.
-
            
-
            
-  Study the how intro,
-  the other "how" documents,
-  the tech intro,
-  and associated documents.
-  These will give you a good overview of how I2P is structured and what different things it does.
-
            
-
-
            Getting the I2P code
            
-
-
            
-  For development on the i2p router or the embedded applications,
-  get the monotone source repository installed - short instructions:
-
            
-
              
-  
            • 
-    Install monotone.
-    Monotone is a version control system.
-    We use it because it allows us to keep track of who does what changes to the source code (and for a lot of complicated things, but 'keeping track of changes' is the basic idea).
-  
              • 
-  
            • Skim over the monotone tutorial, to make sure you understand the concepts.
              • 
-  
            • 
-    
              
-      If you want to remain anonymous, you need to do an additional step, to set up a connection to a monotone server over I2P:
-    
              
-    
              
-      Enable the i2ptunnel client tunnel on port 8998 pointing to mtn.i2p2.i2p.
-    
              
-  
              • 
-  
            • 
-  Pick a directory where you want to put all your I2P files, and create a monotone database: mtn -d i2p.mtn db init
-  
              • 
-  
            • Define the trust list by creating ~/.monotone/monotonerc (or _MTN/monotonerc in the i2p.i2p workspace) with the following contents:
-{% include "_monotonerc.html" %}
-
              • 
-  
            • Copy and paste the developer's commit keys into a new file (e.g. keys.txt) in the same directory
-  that i2p.mtn is in. Import the keys into your database with 
                    mtn -d i2p.mtn read < keys.txt
              
-  
            • 
-    Pull the I2P sources to your machine. This may take a long time, especially if you are doing this over I2P!
-    
                
-      
              • Anonymously: mtn -d i2p.mtn pull 127.0.0.1:8998 i2p.i2p -k""
                • 
-      
              • 
-        
                
-           Non-anonymously: mtn -d i2p.mtn pull mtn.i2p2.de i2p.i2p -k"" 
-        
                
-        
                
-          Alternatively, instead of 'mtn.i2p2.de', you can also download from mtn.i2p-projekt.de.
-        
                
-    
              
-  
              • 
-  
            • 
-    
              
-    All the sources are now present on your machine, in the database file. To make them available in a directory, you need to check them out: mtn -d i2p.mtn co --branch=i2p.i2p
-    
              
-    
              
-      The above command creates a directory i2p.i2p, which contains all of the I2P sources.
-    
              
-  
              • 
-
            
-
-
            Remarks
            
-
            
-  To download the website files instead of the I2P source files, use 'i2p.www' instead of 'i2p.i2p'.
-
            
-
            
-  The initial pull may take several hours using the tunnel.
-  If it fails after a partial pull, simply rerun it, it will start where it left off.
-  If you are in a hurry, use the non-anonymous access.
-
            
-
            
-  A full list of branches, including i2p.i2p and i2p.www can be found on viewmtn.
-
            
-
            
-  A long explanation about using monotone is available on the monotone page.
-
            
-
-
            Building I2P
            
-
-
            
-  To compile the code, you need the Sun Java Development Kit 6 or higher, or equivalent JDK
-  (Sun JDK 6 strongly recommended) and
-  Apache ant
-  version 1.7.0 or higher.
-  If you go are working on the main I2P code, you can go into the i2p.i2p directory and run 'ant' to see the build options.
-
            
-
-
            
-  To build or work on console translations, you need
-  the xgettext, msgfmt, and msgmerge tools from the
-  GNU gettext package.
-
            
-
-
            
-  For development on new applications,
-  see the application development guide.
-
            
-
-
            Development ideas
            
-
            
-  See zzz's TODO lists,
-  this website's TODO list or
-  Trac
-  for ideas.
-
            
-
-
            Making the results available
            
-
-
            
-  See the bottom of licenses.html for
-  commit privilege requirements. You need these to put code into i2p.i2p (not required for the website!).
-
            
-
-
            
-  Short version of how to generate and use keys if you plan to commit:
-  
              
-    
            • mtn genkey yourname-transport@mail.i2p (use an empty passphrase)
-    
            • mtn genkey yourname@mail.i2p (enter a passphrase)
-    
            • mtn pubkey yourname-transport@mail.i2p (send this to a mtn repo operator to get push privileges)
-    
            • mtn pubkey yourname@mail.i2p (send this to a release manager to get commit privileges - not required for website)
-    
            • mtn ci -k yourname@mail.i2p (check in with this key)
-    
            • mtn sync -k yourname-transport@mail.i2p (push with this key)
-  
            
-  Long version: see the monotone page.
-
            
-
-
            Get to know us!
            
-
            
-  The developers hang around on IRC. They can be reached on the Freenode network, OFTC, and on the I2P internal networks. The usual place to look is #i2p-dev. Join the channel and say hi!
-  We also have additional guidelines for regular developers.
-
            
-
-
            Translations
            
-
            
-  Website and router console translators: See the New Translators Page
-  for next steps.
-
            
-
-
            Tools
            
-
            
-I2P is open source software that is mostly developed using open sourced
-toolkits. The I2P project recently acquired a license for the YourKit Java
-Profiler. Open source projects are eligible to receive a free license provided
-that YourKit is referenced on the project web site. Please get in touch if you
-are interested in profiling the I2P codebase.
-
            
-
-
            
-YourKit is kindly supporting open source projects with its full-featured Java Profiler.
-YourKit, LLC is the creator of innovative and intelligent tools for profiling
-Java and .NET applications. Take a look at YourKit's leading software products:
-YourKit Java Profiler and
-YourKit .NET Profiler.
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/newtranslators.html b/www.i2p2/pages/newtranslators.html
deleted file mode 100644
index 064f3d77..00000000
--- a/www.i2p2/pages/newtranslators.html
+++ /dev/null
@@ -1,178 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}New Translator's Guide{% endblock %}
-{% block content %}
-Here's a very quick guide to getting started.
-
-
            How to Translate the Website
            
-
-
              
-
            1. 
-Preparation
-  
                
-  
              1. 
-   Come to #i2p-dev on irc and talk to people.
-   Claim the language -
-   To make sure other coworkers don't bump onto the files you are working on,
-   please update the translation status on this wiki page.
                2. 
-  
              2. 
-   Follow the new developer's guide,
-   Including the installation of monotone,
-   checking out i2p.www branch, and generate your own monotone keys.
-   It is not required that you sign a dev agreement.
                3. 
-  
              
-
-
            2. 
-Create files:
-   If the file for your language does not exist yet, copy another language file to a new file foo_xx.bar for your language.
-   Then 'mtn add' the file.
-   Also add a _layout_xx.html for your language xx.
-   Add a flag image file for the menu (copy from the router).
              3. 
-
-
            3. 
-Edit files:
-   Edit _layout_xx.html, _menu.html, and other files with any text editor.
-   Be sure not to use an editor in HTML mode that reformats everything.
              4. 
-
-
            4. 
-Check in:
-   mtn pull, mtn update. Then check in by "mtn ci -k yourname@mail.i2p file1 file2 ..."
-   This collects the diff info of your changed file into your local repo. Then "mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p i2p.i2p".
-   This synchronizes your local repo with the repo on the target machine.
              5. 
-
-
            5. 
-Repeat. Check in often. Don't wait until it is perfect.
              6. 
-
-
-
-
            
-
-
            How to Translate the Router Console
            
-
-
            The easiest way by far to translate the router console is to sign up for an account at 
-Transifex and request to join a translation team. 
-Alternatively it can be done "the old way" as outlined below.
            
-
-
              
-
            1. 
-Preparation
-  
                
-  
              1. 
-   Come to #i2p-dev on irc and talk to people.
-   Claim the language -
-   To make sure other coworkers don't bump onto the files you are working on,
-   please update the translation status on this wiki page.
                2. 
-  
              2. 
-   Follow the new developer's guide,
-   Including the installation of monotone and the gettext tools,
-   checking out i2p.i2p branch, and generate your own monotone keys.
                3. 
-  
              3. 
-   Generate your own gpg key and sign the dev agreement.
                4. 
-  
              2. 
-
-
            2. 
-Before starting a console translation, better help translate some i2p webpages first.
-At least an i2p homepage in your language would be great. This will also help you learn monotone.
              3. 
-
-
            3. 
-What to translate:
-   There are about 15 files in the i2p.i2p branch that needs translation:
-
-  
                
-  
              • 
-    installer/resources/readme/readme_xx.html
                • 
-  
              • 
-    installer/resources/initialNews/initialNews_xx.xml
                • 
-  
              • 
-    apps/routerconsole/locale/messages_xx.po
                • 
-  
              • 
-    installer/resources/proxy/*_xx.ht (about 9 files)
                • 
-  
              • 
-    apps/routerconsole/jsp/help_xx.jsp
                • 
-  
              • 
-    installer/resources/eepsite.help/help/index_xx.html
                • 
-  
              • 
-    apps/i2ptunnel/locale/messages_xx.po
                • 
-  
              • 
-    apps/i2psnark/locale/messages_xx.po
                • 
-  
              • 
-    apps/susidns/locale/messages_xx.po
                • 
-  
              
-
-   Where xx is your language code like fr/de/ch/zh/...
-
-   There may be or may not be files with your lang code. If not, you can create your own. by copying and renaming other language files you know with your own lang code.
-
              4. 
-
-
            4. 
-Create files:
-   If the file for your language does not exist yet, copy another language file to a new file foo_xx.bar for your language.
-   Then 'mtn add' the file.
-   After creating a .po file, edit the headers. Then run 'ant distclean poupdate'.
-
              5. 
-
            5. 
-Start to work:
-   Edit the HTML files with any text editor.
-   Be sure not to use an editor in HTML mode that reformats everything.
-   To work with .po files efficiently, you may wish to use POEdit
-
              6. 
-
            6. 
-Check in:
-   mtn pull, mtn update. Then check in by "mtn ci -k yourname@mail.i2p file1 file2 ..."
-   This collects the diff info of your changed file into your local repo. Then "mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p i2p.i2p".
-   This synchronizes your local repo with the repo on the target machine.
-
              7. 
-
            7. 
-Repeat. Check in often. Don't wait until it is perfect.
-
-
              8. 
-
            
-
-
            As you can see, it's not that difficult.
-If you have questions about the meaning of the terms in the console, ask in #i2p-dev on IRC.
-
            
-
-
-
            FAQ
            
-
-Q: Why do I have to install monotone, Java, jsp, learn about .po files and html, etc.? Why can't I just do a translation and email it to you?
-
-Answer: Several reasons:
-
-
              
-
            • You might be interested in translating via Transifex. Request to join a translation team here
              • 
-
            • 
- We don't have anybody who has time to accept manual contributions and submit them to our source control system on your behalf. Even if we did, it doesn't scale.
              • 
-
-
            • 
- Maybe you are thinking translation is a one-step process. It isn't. You can't do it all at once. You will make mistakes. You need to test it and tweak it to make it look right before you submit it. Developers will update or add to the English text, thus requiring a translation update.
-
              • 
-
            • 
- Having translators use a source control system directly provides authentication and accountablility - we know who is doing what, and we can track changes, and revert them if necessary.
-
-
              • 
-
            • 
- .po files are not difficult. If you don't want to work directly with them, we recommend 'poedit'.
-
              • 
-
            • 
- HTML files are not difficult. Just ignore the html stuff and translate the text.
-
              • 
-
            • 
- Installing and using monotone is not that difficult. Several of the translators and other contributors to I2P are non-programmers, and they use monotone regularly. Monotone is simply a source control system, it is not about "coding".
-
              • 
-
            • 
- Our items to translate are not "documents". They are html files and po files, with a specific format and character encoding (UTF-8) that must be maintained, and not corrupted by email programs or other methods of transfer.
-
              • 
-
            • 
- We looked at 'pootle' as a front-end for translators. It didn't work well, needed an administrator, and a pootle-based process would suffer from a number of the above flaws.
              • 
-
            
-
-In summary:
-
-Yes, we know it is somewhat of a hurdle to get started. It's really the only possible way we can do it. Give it a try, it really isn't that hard.
-
-
            More Information
            
-The #i2p-dev channel on IRC, or the translation forum on zzz.i2p.
-
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/not_found.html b/www.i2p2/pages/not_found.html
deleted file mode 100644
index a6c2a3fd..00000000
--- a/www.i2p2/pages/not_found.html
+++ /dev/null
@@ -1,5 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Not found{% endblock %}
-{% block content %}
-Yep... the resource, you were searching for, is named differently, doesn't exist or was removed.
-{% endblock %}
diff --git a/www.i2p2/pages/not_found_de.html b/www.i2p2/pages/not_found_de.html
deleted file mode 100644
index 42fa6929..00000000
--- a/www.i2p2/pages/not_found_de.html
+++ /dev/null
@@ -1,5 +0,0 @@
-{% extends "_layout_de.html" %}
-{% block title %}Nicht gefunden{% endblock %}
-{% block content %}
-Yep... die Information nach der du suchst, nennt sich anders, existiert nicht oder wurde entfernt.
-{% endblock %}
diff --git a/www.i2p2/pages/not_found_zh.html b/www.i2p2/pages/not_found_zh.html
deleted file mode 100644
index 95b66982..00000000
--- a/www.i2p2/pages/not_found_zh.html
+++ /dev/null
@@ -1,7 +0,0 @@
-{% extends "_layout_zh.html" %}
-{% block title %}
-未找到
-{% endblock %}
-{% block content %}
-您搜索的页面或资源的名称不正确或不存在或已被删除。
-{% endblock %}
\ No newline at end of file
diff --git a/www.i2p2/pages/_config b/www.i2p2/pages/old/_config
similarity index 100%
rename from www.i2p2/pages/_config
rename to www.i2p2/pages/old/_config
diff --git a/www.i2p2/pages/announcements.html b/www.i2p2/pages/old/announcements.html
similarity index 100%
rename from www.i2p2/pages/announcements.html
rename to www.i2p2/pages/old/announcements.html
diff --git a/www.i2p2/pages/feed.atom b/www.i2p2/pages/old/feed.atom
similarity index 100%
rename from www.i2p2/pages/feed.atom
rename to www.i2p2/pages/old/feed.atom
diff --git a/www.i2p2/pages/installation.html b/www.i2p2/pages/old/installation.html
similarity index 100%
rename from www.i2p2/pages/installation.html
rename to www.i2p2/pages/old/installation.html
diff --git a/www.i2p2/pages/statusnotes.html b/www.i2p2/pages/old/statusnotes.html
similarity index 100%
rename from www.i2p2/pages/statusnotes.html
rename to www.i2p2/pages/old/statusnotes.html
diff --git a/www.i2p2/pages/papers.html b/www.i2p2/pages/papers.html
deleted file mode 100644
index b68a42d1..00000000
--- a/www.i2p2/pages/papers.html
+++ /dev/null
@@ -1,301 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Papers and Presentations on I2P{% endblock %}
-{% block content %}
-
            Papers and Presentations on I2P
            
-
            
-Following are links to papers, presentations, videos, and tutorials about I2P.
-
            
-To request an addition to this page, please send to press ~~~at~~~ i2p2.de.
-
            
-Newest links are at the bottom of each section.
-
            
-
            
-
-
            Papers and Research
            
-
-
-
            Presentations
            
-
-
-
            Tutorials
            
-
-
-
            Articles and Interviews
            
-
            
-{% endblock %}
diff --git a/www.i2p2/pages/plugins.html b/www.i2p2/pages/plugins.html
deleted file mode 100644
index d0fb900c..00000000
--- a/www.i2p2/pages/plugins.html
+++ /dev/null
@@ -1,109 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Plugins{% endblock %}
-{% block content %}
-
            I2P Plugins
            
-
-Page last updated June 2012, current as of router version 0.9.
-
-
            General Information
            
-
            
-I2P includes a plugin architecture
-to support easy development and installation of additional software.
-
            
-
-
            
-There are now plugins available that support distributed email, blogs, IRC
-clients, distributed file storage, wikis, and more.
-
            
-
-
            
-Benefits to i2p users and app developers:
-
            
-
-
              
-
            • Easy distribution of applications
              • 
-
            • Allows innovation and use of additional libraries without worrying about
-increasing the size of i2pupdate.sud
              • 
-
            • Support large or special-purpose applications that would never be bundled
-with the I2P installation
              • 
-
            • Cryptographically signed and verified applications
              • 
-
            • Automatic updates of applications, just like for the router
              • 
-
            • Separate initial install and update packages, if desired, for smaller update downloads
              • 
-
            • One-click installation of applications. No more asking users to modify
-wrapper.config or clients.config
              • 
-
            • Isolate applications from the base $I2P installation
              • 
-
            • Automatic compatibility checking for I2P version, Java version, Jetty
-version, and previous installed application version
              • 
-
            • Automatic link addition in console
              • 
-
            • Automatic startup of application, including modifying classpath, without requiring a restart
              • 
-
            • Automatic integration and startup of webapps into console Jetty instance
              • 
-
            • Facilitate creation of 'app stores' like the one at plugins.i2p
              • 
-
            •  One-click uninstall
              • 
-
            •  Language and theme packs for the console 
              • 
-
            •  Bring detailed application information to the router console 
              • 
-
            •  Non-java applications also supported 
              • 
-
            
-
-
-
            Required I2P version
            
-
             0.7.12 or newer.  
            
-
-
            Installation
            
-
             To install and start a plugin, copy the .xpi2p install link to
-the form at the bottom of configclients.jsp in
-    your router console and click the "install plugin" button.  After a
-plugin is installed and started, a link to the plugin will usually appear at
-the top of your summary bar.  
            
-
-
             To update a plugin to the latest version, just click the update button on
-configclients.jsp.
-There is also a button to check if the plugin has a more recent version, as
-well as a button to check for updates for all plugins.  Plugins will be checked
-for updates automatically when updating to a new I2P release (not including dev
-builds).
            
-
-
-
            Development
            
-
             See the latest plugin specification and the plugin forum on zzz.i2p.  
             
             See
-also the sources for plugins developed by various people.  Some plugins, such
-as snowman, were developed
-specifically as examples.  
            
-
-
             Developers wanted! Plugins are a great way to learn more about I2P
-or easily add some feature.  
            
-
-
            Getting Started
            
-
             To create a plugin from an existing binary package you will need to get
-makeplugin.sh from the
-    i2p.scripts branch in monotone.  
            
-
-
-
            Known Issues
            
-
             Note that the router's plugin architecture does NOT currently
-provide any additional security isolation or sandboxing of plugins.
            
-
-
              
-
            • Updates of a plugin with included jars (not wars) won't be recognized if
-the plugin was already run, as it requires class loader trickery to flush the
-class cache; a full router restart is required.
              • 
-
            •  The stop button may be displayed even if there is nothing to stop.
              • 
-
            •  Plugins running in a separate JVM create a logs/ directory in
-$CWD.
              • 
-
            • No initial keys are present, except for those of jrandom and zzz (using the
-same keys as for router update), so the first key seen for a signer is
-automatically accepted—there is no signing key authority.  
              • 
-
            •  When deleting a plugin, the directory is not always deleted, especially on
-Windows.  
              • 
-
            •  Installing a plugin requiring Java 1.6 on a Java 1.5 machine will result
-in a "plugin is corrupt" message if pack200 compression of the plugin file is
-used.  
              • 
-
            •  Theme and translation plugins are untested.  
              • 
-
            •  Disabling autostart doesn't always work.  
              • 
-
            
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/protocols.html b/www.i2p2/pages/protocols.html
deleted file mode 100644
index 7c382c89..00000000
--- a/www.i2p2/pages/protocols.html
+++ /dev/null
@@ -1,105 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Protocol Stack{% endblock %}
-{% block content %}
-
-
            
-Here is the protocol stack for I2P.
-See also the Index to Technical Documentation.
-Updated August 2010, current for router version 0.8.
-
            
-
-
            
-Each of the layers in the stack provides extra capabilities.
-The capabilities are listed below, starting at the bottom of the protocol stack.
-  
              
-    
            • 
-        Internet Layer:
-        
              
-        IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery.
-    
              • 
-    
            • 
-        Transport Layer:
-        
              
-        TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet.
-        
              
-        UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet.
-    
              • 
-    
            • 
-        I2P Transport Layer: provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection.
-            Two protocols are implemented to provide these capabilities. NTCP builds on top of TCP, while SSU uses UDP.
-        
              
-        NTCP: NIO-based TCP
-        
              
-        SSU: Secure Semi-reliable UDP
-    
              • 
-    
            • 
-        I2P Tunnel Layer: provide full encrypted tunnel connections.
-        
              
-        Tunnel messages: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery.
-            The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key),
-            so it will be forwarded.
-        
              
-        I2NP messages: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages.
-    
              • 
-    
            • 
-        I2P Garlic Layer: provide encrypted and anonymous end-to-end I2P message delivery.
-        
              
-        I2NP messages: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous.
-    
              • 
-
            
-
            
-
-
            
-The following layers are strictly speaking no longer part of the I2P Protocol stack, they are not part of the core 'I2P router' functionality.
-However, each of these layers adds additional functionality, to allow applications simple and convenient I2P usage.
-
              
-    
            • 
-        I2P Client Layer: allow any client to use I2P functionality, without requiring the direct use of the router API.
-        
              
-        I2CP: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket.
-    
              • 
-    
            • 
-        I2P End-to-end Transport Layer: allow TCP- or UDP-like functionality on top of I2P.
-        
              
-        Streaming Library: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P.
-        
              
-        Datagram Library: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P.
-    
              • 
-    
            • 
-        I2P Application Interface Layer: additional (optional) libraries allowing easier implementations on top of I2P.
-        
              
-        I2PTunnel
-        
              
-        SAM/SAMv2/SAMv3(*),
-        BOB        
-    
              • 
-    
            • 
-        I2P Application Proxy Layer: proxy systems.
-        
              
-        HTTP Client/Server, IRC Client, SOCKS, Streamr 
-    
              • 
-  
            
-
            
-
            
-Finally, what could be considered the 'I2P application layer', is a large number of applications on top of I2P.
-We can order this based on the I2P stack layer they use.
-
              
-    
            • Streaming/datagram applications: i2psnark, Syndie, i2phex...
              • 
-    
            • SAM/BOB applications: IMule, i2p-bt, i2prufus, Robert...
              • 
-    
            • Other I2P applications: Syndie, EepGet, plugins...
              • 
-    
            • Regular applications: Jetty, Apache, Monotone, CVS, browsers, e-mail...
              • 
-
            
-
            
-
-    
            
-        I2P Network stack
-        

            
-        Figure 1: The layers in the I2P Network stack.
-    
            
-
            
-
-
            
-* Note: SAM/SAMv2 can use both the streaming lib and datagrams.
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.8.10.html b/www.i2p2/pages/release-0.8.10.html
deleted file mode 100644
index 82373a0e..00000000
--- a/www.i2p2/pages/release-0.8.10.html
+++ /dev/null
@@ -1,48 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.10 Release{% endblock %}
-{% block content %}
-
-
            
-
-Release 0.8.10 includes two changes intended to reduce the number of router-to-router connections,
-and therefore improve tunnel build success rates and general reliability.
-Of course, there's also a few bug fixes and translation updates.
            
-
-
            
-
-
            Files are available on the download page.
            
-
-
-
            Release Details
            
-
-
-
            - Disable tunnel testing as it forces too many router connections
-
            - Select outbound endpoint - inbound gateway paths that are closer, using an XOR metric, to reduce router connections.
            
-
-
            Bug Fixes
            
-
-
            - Fix exceptions at shutdown
-
            - Fix concurrency errors in SSU
-
            - Fix timeout message on POST
            
-
-
            Other
            
-
-
            - Increase max tunnels, reduce router info expiration
-
            - Add gunzip support to eepget to reduce reseed bandwidth
-
            - Finnish, Italian, Russian, and Swedish translation updates
            
-
-
-SHA256 Checksums:
-
-
            -
-     8494640d29b1b7969118169a7ae1c56bc5a07f354ec883734687bf09eef0e35c  i2pinstall_0.8.10.exe
-     e5832bb49f46b0b6620e8492e6fc6454de4107b84bca5a4b35461c6b7ac0575e  i2psource_0.8.10.tar.bz2
-     64bcd1fdd478cfda987c1d4906d94b3f20a0555bd4037aefa7a09af4f39a0e99  i2pupdate_0.8.10.zip
-     5620113f4e19768e15af0a9c8bc670ca443e9983a0d4868997800ee215790c51  i2pupdate.su2
-     39bfbfebbf77d660081fe1ce282f642fb15ed9cd170901f54a954bc986eadaf5  i2pupdate.sud
-
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.8.11.html b/www.i2p2/pages/release-0.8.11.html
deleted file mode 100644
index 7aa5a25c..00000000
--- a/www.i2p2/pages/release-0.8.11.html
+++ /dev/null
@@ -1,65 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.11 Release{% endblock %}
-{% block content %}
-
-
            
-As you all have noticed, the unprecedented network growth starting October 5th
-has dramatically increased network congestion, especially on evenings (UTC)
-and weekends. The last two releases contained a few changes that we hoped
-would relieve the pressure, but unfortunately these measures have been only
-modest successes. The primary issue is to limit the number of direct router
-to-router connections in the network. This isn't a new problem; we've been
-working on it for several years, with good results. However, the recent
-growth pushed us over the edge once again.
-
            
-Release 0.8.11 includes several more changes to reduce the number of router-to-router
-connections and increase connection and tunnel build capacity. The goal, of course,
-is to improve tunnel build success rates and general reliability. As always, there's
-a few bug fixes and translation updates.
-
            
-We welcome all our new users. Please be patient as we work to improve network
-performance. Debugging congestion problems in a distributed anonymous network
-is a continuing challenge. Please help improve the network
-by restarting your router once the upgrade is downloaded.
-
            
-
-
            Files are available on the download page.
            
-
-
-
            Release Details
            
-
-
            Major changes
            
-
-
            - Improve peer profile capacity metric to include factors for connection, reachability, country, and router hash, to reduce connection churn
-
            - Adjust connection limits and timeouts to increase capacity
-
            - Adjust router info and peer profile expirations to reduce memory usage
-
            - Rebuild existing tunnels some of the time to reduce connection churn and improve build success
-
            - Build Executor / Handler thread separation to increase build handling capacity for high-speed routers
-
            - Bloom Filter optimizations to reduce lock contention for high-speed routers
-
            - SSU introducer changes
            
-
-
            Bug Fixes
            
-
-
            - Fix expiration of peer profiles
            
-
-
            Other
            
-
-
            - Ukrainian translation updates
            
-
-
-
-
-SHA256 Checksums:
-
-
            -
-     fa3d566874f196e32e1d5987d3dedb956cfa0b2a93a0735e53d6dd9fa2b1769a  i2pinstall_0.8.11.exe
-     f7113da64bacea9a560e0f3c31c9fb663fc646d16bb621a9b8f1e97477d0a2d1  i2psource_0.8.11.tar.bz2
-     835fe7dadd4b8155a83774ea025dc76332660fed2c20799fa21f54b5627bff3d  i2pupdate_0.8.11.zip
-     d932c54d275eef0a31418970e0ecae8ea46d25e1110db4b9eab4ba685830e445  i2pupdate.su2
-     ca3e17c3cd29159e8a2a91ccc51bdfbf794ad9ca481f620b29bdd51251c3ab97  i2pupdate.sud
-
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.8.12.html b/www.i2p2/pages/release-0.8.12.html
deleted file mode 100644
index f97f2cbe..00000000
--- a/www.i2p2/pages/release-0.8.12.html
+++ /dev/null
@@ -1,97 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.12 Release{% endblock %}
-{% block content %}
-
-
            
-The 0.8.12 release fixes several message corruption bugs, some present since 2005.
-It also contains a redesign of the router's congestion control, and continued optimization
-of CPU and memory usage. We are hopeful that these changes will improve network performance.
-Upgrading is recommended.
-
            
-
-
            Files are available on the download page.
            
-
-
-
            Release Details
            
-
-
            This release contains several big changes that should help network reliability and performance.
            
-
-
            The first two changes are fixes for major UDP packet transmission bugs, described below. The third change
- is fixes to the decompressor. Fixing these should eliminate a big source of message delivery failures.
            
-
-
            Also, the release contains a rewrite of the router's participating traffic congestion control. It should
- now more accurately measure current participating bandwidth, handle bursts better, drop messages less, and
- drop the right messages if dropping is required.
            
-
-
            Also, the release reduces the amount of processing that routers do for messages they pass down the tunnel.
- These messages do not need to be completely parsed and validated since the gateway is simply passing them through.
- This will help performance of all routers but the improvement will probably not be noticeable except on high-traffic routers.
            
-
-
            We're optimistic that these changes will help, and of course eliminating sources of message corruption is sure to help.
- However the extend of the improvement won't be apparent until the majority of the network upgrades.
            
-
-
            The release also contains some updates to the router console light theme. You may need to do a shift-reload
- or control-reload in your browser to force a reload of the CSS.
            
-
-
            Major changes
            
-
-
            - Instead of fully parsing and validating messages received at the inbound gateway, simply pass them down the tunnel
-
            - Don't verify I2NP checksums in most cases, as message corruption is caught at other layers
-
            - Don't recalculate I2NP checksums on messages passed through unchanged
-
            - Several NTCP pumper optimizations, to hopefully fix NTCP pumper high CPU usage on fast routers
-
-
            - Rewrite participating tunnel congestion control, to drop less, more accurately measure traffic, and handle bursts better
            
-
-
            Wrapper Update
            
-
-
            New installs include wrapper version 3.5.13 which fixes a heap corruption with very long log lines.
- See http://wrapper.tanukisoftware.com/doc/english/release-notes.html
- for additional information. I2P PPA package users should have received this update in the last week of December.
- If you do not use our PPA package and would like to update your wrapper manually, follow the instructions at
- http://www.i2p2.de/manualwrapper .
            
-
-
            Bug Fixes
            
-
-
            - Fix major SSU MTU bug introduced in 0.8.9.The router sometimes sent UDP packets that exceeded the maximum
-size that routers would accept on the receive side. This resulted in a lot of dropped packets, tunnel build problems,
- and connection problems. One thing that contributed to us missing the problem was that 0.8.9 was released in the
- middle of the huge network expansion in early October, when network performance was already deteriorating rapidly.
-
            - Fix major SSU fragmentation bug present since 2005. UDP corrupted transmit messages when the message size
- was an exact multiple of the fragmentation size.
-
            - Fix major decompression bugs present since 2005 that caused message corruption and data loss at multiple protocol layers.
-
            - Snark doesn't always delete directories
-
            - Fix all character case conversion (Turkish four i problem)
-
            - Whitelist more IRC commands
-
            - Remove expired reseed cert
            
-
-
            Other
            
-
-
            - Speed up the inefficient GeoIP lookup
-
            - Optimize several heavily-used utility functions
-
            - Don't drop the transport connection when receiving an invalid message, it isn't necessary and could be an attack vector
-
            - Console light theme update
-
-
            - Move the complex network configuration stuff to a new console page
-
            - Add a link to hide the news in the console
-
            - Allow numerous additional IRC commands through the IRC filter
-
            - Several other cleanups, optimizations, and object caches added
-
            - New Estonian translation (thanks ajutine)
-
            - Spanish, Swedish, Ukrainian translation updates
-
            
-
-
-
-
-SHA256 Checksums:
-
-
            -
-    7a05b96c535f565b06aeec3b83fca6245b1159003d4e2da2149374ba0f476847  i2pinstall_0.8.12.exe
-    019d6018e7093650cf67fd883b0cf0f12aa2f4f0cddc5ef6a08e6147af07f142  i2psource_0.8.12.tar.bz2
-    a9556998b136d47b124749f426d86514e7128094308f03085b889f34bbdf8dc0  i2pupdate_0.8.12.zip
-    bb7be1dc9bdcc9b2db2587988325b4ea7c81e9eeb542ebcb17e0d6de29fc98d3  i2pupdate.su2
-    491722ef1a641512fc3bbaf825d5d1671b701e32b1298572f2820ab7fbf9851d  i2pupdate.sud
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.8.13.html b/www.i2p2/pages/release-0.8.13.html
deleted file mode 100644
index 2c6f4ad6..00000000
--- a/www.i2p2/pages/release-0.8.13.html
+++ /dev/null
@@ -1,83 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.13 Release{% endblock %}
-{% block content %}
-
-
            
-The 0.8.13 release contains several bug fixes and a couple of new features.
-We are pleased that the last release significantly improved performance,
-and the network is running well despite continued rapid growth.
-Upgrading is recommended.
-
            
-
-
            Files are available on the download page.
            
-
-
-
            Release Details
            
-
            
-This is likely to be the last release before 0.9, in which we will migrate to Jetty 6,
-and introduce a simplified router console home page. Monitor the news section of
-your the router console in the coming weeks for more information on the next release.
-
            
-Starting with this release, the router will
-check for and install plugin updates shortly upon restarting after a router update.
-To prevent this, add the advanced configuration
-plugins.autoUpdate=false before restarting.
-There is also a new update-all button on the client configuration page.
-
            
-Routers in certain countries will now automatically enable hidden mode for increased protection.
-However, hidden mode may have lower performance or reliability, and is still a work in progress.
-To disable hidden mode before restarting, add the advanced configuration
-router.isHidden=false.
-To disable hidden mode later, select use all auto-detect methods under IP Configuration on the
-network configuration page.
-For the list of countries see the thread on zzz.i2p.
-The only country on the list that has more than one or two I2P users is China.
-
            
-
-
-
            Major changes
            
-
            - Check for and download plugin updates upon restarting after a router update.
-
            - Routers in certain countries will now automatically enable hidden mode for increased protection.
-
            - New Tunnel Wizard for creating tunnels
            
-
            - A SIGHUP to the wrapper will now initiate a graceful shutdown
-
-
            Bug Fixes
            
-
-
            - Increase read timeout in HTTP Proxy
-
            - Shutdown hooks will now run when router is shutdown externally (i2prouter stop), broken in 0.8.8
-
            - If an external IP address is specified, bind only to that interface
-
            - Fail tunnels we created when we can't contact the adjacent hop
-
            - Prevent races when saving configuration
-
            - For plugins, check min and max Jetty versions; check all version requirements at startup, not just at install
-
            - Fix plugin startup when console is not on port 7657
-
            - Only stop plugins if they are running
-
            - Fix NPE when no network interfaces are present
-
            - Fix eepget exit code on failure
-
            - Improve inbound tunnel building when in hidden mode
-
            - Publish our router info sooner after startup to facilitate inbound tunnel building
-
            - Fix Streamr tunnel registration
            
-
-
            Other
            
-
-
            - Add icons to buttons in SusMail and SusiDNS
-
            - Move wrapper PID, status, and log files from /tmp to ~/.i2p (Debian packages and new installs only)
-
            - i2prouter graceful (Debian packages and new installs only)
-
            - Increase number of floodfills
-
            - Repack jars in installer to save a little space
-
            - New translation infrastructure for i2prouter script (not enabled yet)
-
            - New Czech translation (thanks Waseihou)
-
            - German, Italian, Polish, Spanish, Swedish, Ukrainian translation updates
            
-
-
-
-SHA256 Checksums:
-
-
            -    648a552ee009e9648aba0666c05e2f71e442a714716659a0ca4f60aca87bda50  i2pinstall_0.8.13.exe
-    bdd510cc47b2cd78aa8d994e27694185c1f2deb48b049d61a93a795932ce5712  i2psource_0.8.13.tar.bz2
-    36683d906ac121fd28ac5600218aec943da154cb0230f274f0e2a7c6cc6fb8a5  i2pupdate_0.8.13.zip
-    81fa5256250fde2790153b83d2b01b6bc3b5ee7ea1b4d12232ce46f06ae736ef  i2pupdate.su2
-    2eb25974ebfeeeec59d8138e42d5663d97cc24b94f2c6cf77cfe6dc991acf0bb  i2pupdate.sud
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.8.9.html b/www.i2p2/pages/release-0.8.9.html
deleted file mode 100644
index be14fac5..00000000
--- a/www.i2p2/pages/release-0.8.9.html
+++ /dev/null
@@ -1,88 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.9 Release{% endblock %}
-{% block content %}
-
-
            
-The 0.8.9 release has several performance improvements, and many changes to handle
-the continued rapid growth of the network. It uses a new iterative method for
-Kademlia network database lookups that should be more reliable and efficient.
-There are also several improvements to our SSU (UDP) transport protocol that
-should help reliability and efficiency. We have made several changes to
-improve tunnel build success rates. And, of course, there are lots of bug
-fixes and translation updates.
-
            
-The network has grown quite rapidly in recent weeks, and that's great news,
-but it has caused some instability. We welcome all our new users and we
-ask you to be patient as we make improvements to the software.
-
            
-Please help grow the network.
-Get involved,
-spread the word,
-and donate!
-If you find a bug, please enter a report on trac.
-We are still looking for help on new and existing translations.
-Please volunteer on IRC #i2p-dev.
-
            
-
-
            Files are available on the download page.
            
-
-
-
            Release Details
            
-
-
            * Iterative netdb lookup, this had to be fixed as the network growth was making the old method less reliable. Also increase lookup timeouts to improve success rates.
-
            * Implement a SSU disconnect message so that the other side of a connection finds out when the peer disconnects. This should considerably speed up subsequent reconnection.
-
            * Major rewrite of the SSU send queue code, for efficiency in high-speed routers
-
            * Major rewrite of the participating tunnels expiration code, for efficiency in high=speed routers
-
            * Increase the maximum SSU MTU so messages take less packets
-
            * New reverse lookup table in the hosts.txt database so that names are displayed again on the neteb leases page.
-
            * Preliminary support for IRC DCC - not enabled by default
-
            * (New installs only) Switch to the Maxmind GeoIP database which is up-to-date and has better coverage of some countries.
-
            * (New installs only) Update to wrapper 3.5.12 to fix file permission problems.
            
-
-
            Bug Fixes
            
-
-
            * Fix restoration of original tunnel quantity after idle
-
            * Reduce CPU usage when network is disconnected
-
-
            * Fix i2psnark "eject" button in certain browsers
-
            * Fix changing i2psnark tunnel parameters
-
            * Fix installation issues on some non-English Windows versions
-
            * Catch some uncaught exceptions from GNU NIO
-
            * Fix connectivity issues after long suspend times
            
-
-
            Other
            
-
-
            * Improvements to the data structure caching, and increase some cache sizes, to increase hit rates. Add a country code string cache.
-
            * Continue work on removing global locks for performance improvements
-
            * Rewrite of the job queue for efficiency
-
            * Switch to https reseed by default for security; update the reseed host lists
-
-
            * Don't bother to gzip small http responses and images
-
            * Use bigger buffers and gunzipper cache in the http proxy
-
            * Several changes to improve tunnel build success rates
-
            * Increase the number of floodfills again
-
            * Faster router info expiration
-
            * Remove ancient deprecated ministreaming socket manager
-
            * Add option for i2psnark files readable by everyone
-
            * Add option for i2psnark page refresh time
-
            * Add streaming API for getting and setting I2CP port
-
            * More aggressive netdb exploration by hidden routers
-
            * Remove confusing "firewalled and fast" message
-
            * Translation updates for German, Spanish, Portuguese, Russian, and Swedish
            
-
-
-
-SHA256 Checksums:
-
-
            -
-      554d0abe82ca034e1b7479410bab330bba5644ca1ae4117982af670d0f44ee66  i2pinstall_0.8.9.exe
-      c40d503c0ee2e90c75f3d635649490a8e49b60e1da8100db118e2097a133429e  i2psource_0.8.9.tar.bz2
-      dba9258b67b3021c40456aae8e6986dc954ec55ab4ea527fd1ef02cfba88d803  i2pupdate_0.8.9.zip
-      8f04438cd3d17240bebe8afc172ed54a65c3265db8ea4675a8c508d8ba088326  i2pupdate.su2
-      e8754a0490bd3e47bc5017ea66d2bfda6386e9c9c6d50a6d77d2c15c0cab098b  i2pupdate.sud
-
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.9.1.html b/www.i2p2/pages/release-0.9.1.html
deleted file mode 100644
index aac6d445..00000000
--- a/www.i2p2/pages/release-0.9.1.html
+++ /dev/null
@@ -1,85 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.9.1 Release{% endblock %}
-{% block content %}
-
-
            
-0.9.1 includes a large number of bug fixes in i2psnark, some streaming lib improvements,
-home page changes, new themes, and translation updates.
-Upgrading is recommended.
-
            
-
-
            Files are available on the download page.
            
-
-
            RELEASE DETAILS
            
-
-
            I2PSnark
            
-
-
            - Fix several bugs in downloading torrents with skipped files
-
            - Fix places where rarest-first was not honored
-
            - Fix handling of encoded magnet links
-
            - Additional inbound connection limits
-
            - Immediate closing of connections with handshake errors
-
            - Blocklist peers with multiple handshake errors
-
            - Delay "ballooning" files on disk until required, to speed torrent adds
-
            - Store partial pieces in temp files to greatly reduce memory usage when leeching
-
            - Remove peers restriction when leeching torrents with large pieces
-
            - Improve configuration of open and private trackers
-
            - Prevent configuratino of default trackers as private
-
            - Improved display and control of torrent file downloads
-
            - Reduced number of threads
-
            - Faster startup and shutdown of torrents
-
            - Allow clearing of message box
-
            - New light theme
-
            - Torrent info page updates and cleanups
-
            - Fix problems with restarted torrents
-
            - Delay tunnel close at shutdown to ensure trackers are notified
-
            - Better UI behavior during tunnel startup and shutdown
            
-
-
            Bug Fixes
            
-
-
            - Prevent shutdown hangs caused by buggy plugins
-
            - Fix for Raspberry Pi crashing
-
            - Fix rare job queue hang
-
            - Fix routing key modifier rarely not updating at midnight
-
            - Fix excessive padding in some AES-encrypted messages
-
            - Fix occasional gunzip failures
-
            - Several fixes to streaming lib to speed recovery after dropped packets and improve retransmit behavior
-
            - Fix bug that reduced reuse of tunnels
            
-
-
            Other
            
-
-
            - Ports are now passed through the SOCKS and HTTP proxies to support eepsite virtual hosts. See http://zzz.i2p/topics/1182 for setup instructions.
-
            - I2PTunnel configuration changes now take effect immediately. No tunnel restart required.
-
            - Summary bar iframe removed, refresh is now via Javascript only
-
            - Reduce netDB flood redundancy
-
            - Reduce stats publishing frequency
-
            - Minor router console changes
-
            - New Hungarian and Greek translations
-
            - Completed Italian translation
-
            - Updates to Dutch, Finnish, French, German, Spanish, and Swedish translations
-
            - Update geoip to Maxmind 2012-07-04
-
            - Theme updates
-
            - Theme support for SusiMail and SudiDNS; new dark themes
-
            - I2PTunnel and SusiDNS now iframed with summary bar
-
            - Console home page now shows news summary in summary bar
-
            - Console home page icon updates
-
            - Console summary bar now configurable
-
            - Change the HTTP proxy error code from 404 to 500
-
            - Cleanups for efficiency in netdb and I2CP
-
            - Increase timeout for internal uses of eepget to improve reliability
            
-
-
-SHA256 Checksums:
-
-
            -
-    0727af83988e82f32e0972a9e12c72ac14c3c0da0815c5902193d6b13d356371  i2pinstall_0.9.1_windows.exe
-    39c19c0df042ad231a14fdf1c20e4927651a2af0f0cf734b46eba0d2b8419314  i2pinstall_0.9.1.jar
-    8603c928a210ced77b6498bf8ee07cb000be9641adc389b34c3c8a10ac4f0677  i2psource_0.9.1.tar.bz2
-    136b74435b93aededef5884d39cfbc513f57184b74c8481580bcd5324aa23b1a  i2pupdate_0.9.1.zip
-    4f07fee850d56fada06f0aeabb5bb46c6172bad72411e07bf4f6a8e0d76d8acd  i2pupdate.su2
-    c039b423983789d914a1d02d3703b3c1aa36c87165e132419ff39b5d184ef480  i2pupdate.sud
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.9.2.html b/www.i2p2/pages/release-0.9.2.html
deleted file mode 100644
index cbf695e7..00000000
--- a/www.i2p2/pages/release-0.9.2.html
+++ /dev/null
@@ -1,62 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.9.2 Release{% endblock %}
-{% block content %}
-
-
            
-
-0.9.2 includes extensive low-level changes to improve the performance and efficiency of the router.
-We have updated our UPnP library, to hopefully make UPnP work for more people.
-I2PSnark now has DHT support, but it is not yet enabled by default, as we plan to do more
-testing during the upcoming 0.9.3 development cycle.
-As usual, there's also lots of bug fixes in this release, so updating is recommended. 
-
            
-
-
            Files are available on the download page.
            
-
-
            RELEASE DETAILS
            
-
-
-
            Major Changes
            
-
-
            - SSU: Fix several problems in our UDP transport, to improve efficiency and reliability for connection setup. Also improve defenses against various types of bad input.
-
            - UPnP: Updated our library to fix several issues, should work for more routers now
-
            - Transport: Improve performance in both our TCP and UDP transports, to benefit high-bandwidth routers
-
            - Crypto: The thresholds and number of ElGamal/AES Session Tags delivered are now much more flexible, which should lessen protocol overhead and reduce stalls caused by dropped tags.
-
            - I2PSnark: Add DHT support, not yet enabled by default, will do further testing and plan to enable by default in 0.9.3.
            
-
-
            Bug Fixes
            
-
-
            - Fix various issues affecting memory usage and performance on high-bandwidth routers
-
            - Fix problems in UDP for routers using a reduced-MTU connection, e.g. a VPN
-
            - Fix i2psnark bug that prevented a completion announcement to the tracker
-
            - Fix a lock contention problem in i2ptunnel
-
            - Fix some OSX installation issues
-
            - Remove uses of direct byte buffers that may have been leaking
            
-
-
            Other
            
-
-
            - Reduce overhead in network messages
-
            - Add "universal" theme support
-
            - Theme updates
-
            - Add a jbigi library for Raspberry Pi
-
            - New Scala unit test framework
-
            - Translation updates for Czech, Dutch, German, and Greek
-
            - Update wrapper to 3.5.15 (new installs and PPA only)
-
            - Update GeoIP data (new installs and PPA only)
            
-
-
-
-SHA256 Checksums:
-
-
            -
-    4cc506d74bea772d304a8fc1d4adee900e5d7d38cbf896bd8aa9de31002b4f43  i2pinstall_0.9.2_windows.exe
-    7eb1b62bdb955691dfd645acc2172fe7947266e35f201273f702272d57b80a70  i2pinstall_0.9.2.jar
-    ac0262120868a01d11b27ce56a7fea5ea243e261d0d7ff6e6dd59e18987a1be5  i2psource_0.9.2.tar.bz2
-    c547b81822ff642e52a9196e847466b5613219fc695bc26485930c7a855e0cee  i2pupdate_0.9.2.zip
-    f8b34fe7764d828fbdbcc13efd4f8f4ae20697f84c1c3772213241fa2ce0786a  i2pupdate.su2
-    8ee355a27713f43a2a37dcfb70a4ea1d9f6c1fbad2d33a35083c0a33afaedeec  i2pupdate.sud
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.9.3.html b/www.i2p2/pages/release-0.9.3.html
deleted file mode 100644
index fc2e1fb2..00000000
--- a/www.i2p2/pages/release-0.9.3.html
+++ /dev/null
@@ -1,65 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.9.3 Release{% endblock %}
-{% block content %}
-
-
            
-0.9.3 includes extensive low-level changes to the queueing of messages in the router.
-We implement the CoDel Active Queue Management (AQM) algoorithm.
-We also unify the queueing and priority mechanisms in the transports to aid diagnosis and reduce network latency.
-Work continues on fixing UDP transport bugs and making UDP more resistant to attacks.
-There are more changes to improve the performance of the router and reduce its memory usage.
-Also, we enable i2psnark's DHT support, introduced last release, by default.
-As usual, there's also lots of bug fixes in this release, so updating is recommended.
-
            
-
-
            Files are available on the download page.
            
-
-
            RELEASE DETAILS
            
-
-
            Major Changes
            
-
-
            - Active Queue Management
-
            - Priority queues
            
-
            - I2PSnark DHT: Several bug fixes, enable by default.
-
-
            Bug Fixes
            
-
-
            - Several SSU fixes including memory leak, and better handling of routers behind firewalls that change UDP ports; additional defenses for malicious packets.
-
            - Fix piece selection (rarest-first) bugs in i2psnark
-
            - Fix bug causing multiple browsers to open at startup
            
-
-
            Other
            
-
-
            - Improvements in caching
-
            - Several synchronization fixes and lock contention reduction
-
            - Major reduction in SSU buffers memory use
-
            - Fix streaming connection timeout back to 1 minute, was inadvertently changed to 5 minutes; set i2ptunnel server read timeout to 5 minutes, was unlimited
-
            - Improved defenses in i2ptunnel for "darkloris"
-
            - More validation at torrent creation in i2psnark
-
            - Several parameter changes in SSU to improve throughput
-
            - New event log for major events including restarts; show multiple restart lines on graphs
-
            - Remove duplicate messages from logs
-
            - Don't respond to blocked streaming connections with a reset, just drop
-
            - Remove all uses of inefficient SimpleTimer
-
            - More checks for valid IPs and ports entered in console
-
            - Fix bug that wasted a lot of entropy
-
            - Translation updates: Italian, Portuguese, Spanish, Swedish
-
            - Add non-NIO configuration in jetty.xml, recommended for Java 5
-
            - Update GeoIP data (new installs and PPA only)
            
-
-
-
-SHA256 Checksums:
-
-
            -
-    762964ab582801be1c9d45843c682f791c284d4fa7b1e1ee733ea4ef033d4907  i2pinstall_0.9.3_windows.exe
-    4ebea74b30064c9853c40cf24764d283dc6fff47ed2449b247f3c9991cccb494  i2pinstall_0.9.3.jar
-    39a7d6859bf4bd9ac56fd83a5e32d47d1b24ba06f912a027804492ca941936dd  i2psource_0.9.3.tar.bz2
-    2381e4a845c6cc0c0d9f27f99571984bcbf448ef041bc1f7a2ba8715228d6377  i2pupdate_0.9.3.zip
-    d8bb6aef09c967b30c7374fb49da246a7c237c4942fa92999e39c5ce2ca68893  i2pupdate.su2
-    600e806e72441e946027fcac84702f2daabd2783dbc1ee6df3427e6eda7db351  i2pupdate.sud
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.9.4.html b/www.i2p2/pages/release-0.9.4.html
deleted file mode 100644
index 7945a92a..00000000
--- a/www.i2p2/pages/release-0.9.4.html
+++ /dev/null
@@ -1,71 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.9.4 Release{% endblock %}
-{% block content %}
-
-
            0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2,
- that was reducing network performance and reliability. It also includes
- major changes in the in-network update system, and adds the capability
- to update via in-network torrents. 
            
-
-
            We fixed several bugs in the i2psnark DHT implementation that was introduced
- last release. For those of you using console or http proxy passwords,
- we converted to the more-secure digest method and improved the security for console forms.
            
-
-
            For those of you already running development builds, your router should automatically
-update to 0.9.4-0 using the new in-network torrent facility.
-For those running 0.9.3-0, you will update normally using in-network HTTP, and
-we will have more information for you when we release 0.9.5.
            
-
-
            Files are available on the download page.
            
-
-
            RELEASE DETAILS
            
-
-
            Major Changes
            
-
-
            - Big rework of the update system; Preliminary support for updates via i2psnark
-
            - Add per-destination outbound priorities
            
-
-
            Bug Fixes
            
-
-
            - Fix major bug that reduced SSU connection limits which reduced tunnel build success rates
-
            - Fix bug with external I2CP that prevented some external apps from working
-
            - Fixed several bugs in i2psnark DHT
-
            - Fixed bug in i2psnark PEX that inflated peer counts
-
            - Handle dropped I2CP messages better
-
            - Reduce overhead of I2CP messages
-
            - Enforce max size in transport outbound message queues
-
            - Fixes for Windows eepget.bat (new installs and PPA only)
-
            - Fix a bug that would drop messages of exactly 512 bytes in SSU
            
-
-
            Other
            
-
-
            - More performance improvements, memory reduction, and object churn reduction
-
            - Better detection of network disconnections
-
            - Further improvements in the SSU transport
-
            - Add console password form
-
            - Convert http proxy and console from basic to digest authentication for added security
-
            - Improved verification of console form submissions, using jsp sessions. Cookies may now be required on forms, except when the console password is enabled
-
            - Initial work on new interfaces to manage applications started via clients.config
-
            - Increase minimum peer port to 1024
-
            - Increase granularity of bandwidth limiter for smoother transmissions
-
            - Translation updates: Chinese, French, German, Italian, Polish, Portuguese, Swedish, and Ukrainian
-
            - Update GeoIP data (new installs and PPA only)
-
            - Update wrapper to 3.5.16 (new installs and PPA only)
-
            - New ARMv6 wrapper for Raspberry Pi
            
-
-
-SHA256 Checksums:
-
-
            -
-   c76bea15a6b7d98227466cc8025b1eb9069997e40e9d71ff49e55b2c8ac0b995  i2pinstall_0.9.4_windows.exe
-   8e670ba26c04176ace9246d91a09951975e2965b89628f620f5a3dff917298e4  i2pinstall_0.9.4.jar
-   1b7d9695555ed42142b04ad6bcda083cd1a064f6354b639ad2aef4d9cd474e06  i2psource_0.9.4.tar.bz2
-   0f369d9b85793f157ec67c4d59723a2ad0c1de2a0902d35e11c26a2c74add824  i2pupdate_0.9.4.zip
-   6e55d3c44d79b0727f5cd4075df4248e4d78f1736911e3504f6a8af45d973cfc  i2pupdate.su2
-   561e521a707fab457c9dfe166d41b446affbff5bc58ddf770d192235f51f4e90  i2pupdate.sud
-
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/release-0.9.html b/www.i2p2/pages/release-0.9.html
deleted file mode 100644
index 20f3aeb3..00000000
--- a/www.i2p2/pages/release-0.9.html
+++ /dev/null
@@ -1,113 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}0.9 Release{% endblock %}
-{% block content %}
-
-
            
-The 0.9 release concludes over a year and a half of work on the 0.8.x series,
-in which we greatly improved the performance and security of the router, and the
-scalability of the network.
-
            
-
            
-In the 0.9 release we migrate to Jetty 6 for the console and eepsite web server,
-and introduce a simplified router console home page.
-This release is network-compatible with prior releases, however see below for important
-information on compatibility with existing eepsites, plugins, and webapps.
-Upgrading is recommended.
-
            
-
-
            Files are available on the download page.
            
-
-
            Update info
            
-
-
              In-network updates and new installs will include Jetty 6, Tomcat, and JSTL.
- PPA (Ubuntu/Debian) updates will have new dependencies for these packages.
            
-
-
             If you have not enabled or modified your eepsite settings, the update should automatically migrate you to Jetty 6.
-If you do not use Jetty for your eepsite, the update will not affect it.
-
            
-
-
             If you have more than one Jetty eepsite or you have changed the local port (7658 by default) or otherwise edited jetty.xml,
- you must manually edit the new jetty configuration files after updating, and then restart. 
            
-
-
            For those with Jetty-based eepsites, we recommend that you verify that the upgrade
-was successful and the eepsites are operational after the router restarts.
-
-
               Plugin information:
-
                 Plugins not listed below should continue to work under Jetty 6.
-
                 The following plugins require updates for Jetty 6. The router will download and install them a few minutes
-      after upgrading: i2pcontrol, pebble, zzzot
-
                 The following plugins have been renamed and for Jetty 6. Users must manually remove them and download the new versions
-      after upgrading: neodatis, seedless
-
                 The following plugin does not work well with Jetty 6, you may wish to remove it and install the unofficial replacement
-      from plugins.i2p after upgrading: i2pbote
-
            
-
-
               Other non-standard console and eepsite webapps not packaged by the I2P development team may or may not
-      require modifications.
-
            
-
-
            Major changes
            
-
-
            - Jetty 6.1.26, Tomcat 6.0.35, JSTL 1.2, supporting Servlet 2.5 and JSP 2.1 standards
-
            - New simplified console home page.
-        Note that it may be modified or disabled on the new page /confighome .
-
            - The old .exe installer has been split into Windows (.exe) and non-Windows (.jar) installers
-
            - Update to wrapper 3.5.14 (Debian packages and new installs only)
            
-
-
            Bug Fixes
            
-
-
            - Fix use of unacked ElGamal/AES Session Tags, causing permanently "stuck" connections
-
            - Re-enable verifies of RouterInfo netdb stores
-
            - Fix removal of context properties
-
            - Fix handling of plugin installs requiring router restart
-
            - Fix update key names being forgotten after a save on the config update page
-
            - Fix i2psnark duplicate torrent messages
-
            - Fix occasional NPE in the UDP transport
            
-
-
            Other
            
-
-
            - More refactoring to get rid of static references which will help testing, shutdown, and embedded applications
-
            - Reseed cleanups and checks
-
            - Streamlining of tunnel endpoint message processing
-
            - i2psnark bug fixes
-
            - i2psnark private tracker support
-
            - i2psnark tracker configuration form
-
            - i2psnark message box cleanup
-
            - i2psnark Javascript refresh
-
            - i2psnark better error reporting
-
            - Remove support for i2psnark "run standalone"
-
            - Remove deprecated i2ptunnel Bean classes from the jar
-
            - Increase max leaseset size from 6 to 16 for future growth
-
            - Plugin tweaks
-
            - Jetty logging moved from wrapper log to I2P log
-
            - New page for viewing individual graphs for easy resizing and viewing of previous intervals
-
            - Remove bandwidth from netdb stats
-
            - Add negative lookup cache to naming service
-
            - Reduce size of netdb structures
-
            - HTTP Proxy refactoring to improve parsing of URLs and support IPv6 addresses, improve handling of malformed URLs, improved address helper handling
-
            - Use per-destination streaming timers
-
            - Better handling of leaseset/routerinfo overwrite attempts
-
            - GeoIP update to April 2012 version (Debian packages and new installs only)
-
            - German, Russian, Spanish, Swedish translation updates
-
            - Non-default theme updates
-
            - General code cleanups
            
-
-
-
-
-
-SHA256 Checksums:
-
-
            -
-     006a306a2c5a449cce6a19378da5e74b8aa216ba5a9383a4c2cb66dfead2e736  i2pinstall_0.9_windows.exe
-     6175c50a306cbd6ebe6eba40965408bd3f87f3ecd0f6199d7a927099c21d73c0  i2pinstall_0.9.jar
-     8a3654a13781a9aacf9db94081e057be73322f88db2931eba4f2cfa467ead429  i2psource_0.9.tar.bz2
-     234d4c0ad1736b389349c702bfcf70511e72770a414b0afe7e9f5e1f5ebca97d  i2pupdate_0.9.zip
-     78fc1af81b71b5797bf9900b5a98f4513af840b76e801c40b9e4abb5e7e37807  i2pupdate.su2
-     63ec749a1da0c7913c09cc7bcf552497bebb873024ac42030c8a507c92aec9de  i2pupdate.sud
-
-
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/roadmap.html b/www.i2p2/pages/roadmap.html
deleted file mode 100644
index 1b4decfc..00000000
--- a/www.i2p2/pages/roadmap.html
+++ /dev/null
@@ -1,34 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Roadmap{% endblock %}
-{% block content %}
-
-
            0.9
            
-
              
-
            • Include some seed data in the distribution so a central reseed location isn't required?
              • 
-
            • Reachability Mapping / handle peers partially reachable / enhanced restricted routes
              • 
-
            • Improve help pages and website
              • 
-
            • More translations
              • 
-
            • SSU disconnect message
              • 
-
            • Iterative floodfill lookups
              • 
-
            
-
-
            1.0
            
-
              
-
            • Full review of anonymity issues and other vulnerabilities
              • 
-
            • Reduce memory usage, remove debugging overhead, make it run better on slow and embedded machines
              • 
-
            • Docs
              • 
-
            
-
-
            2.0
            
-
              
-
            • Full restricted routes
              • 
-
            
-
-
            3.0
            
-
              
-
            • Tunnel mixing and padding
              • 
-
            • User defined message delays
              • 
-
            
-
-
            Please see the TODO list for more detailed info about some of these tasks.
            
-{% endblock %}
diff --git a/www.i2p2/pages/robots.txt b/www.i2p2/pages/robots.txt
deleted file mode 100644
index 264a66ac..00000000
--- a/www.i2p2/pages/robots.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-
-# allow everything for everyone... at least for now
-User-agent: *
-Disallow: 
diff --git a/www.i2p2/pages/socks.html b/www.i2p2/pages/socks.html
deleted file mode 100644
index 97dd80a5..00000000
--- a/www.i2p2/pages/socks.html
+++ /dev/null
@@ -1,70 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}SOCKS{% endblock %}
-{% block content %}
-
            SOCKS and SOCKS proxies
            
-
            
-    The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are supported.
-    Enable SOCKS by creating a SOCKS client tunnel in i2ptunnel.
-    Both shared-clients and non-shared are supported.
-    There is no SOCKS outproxy so it is of limited use.
-
            
-
            
-As it says on the
-FAQ:
-
            
-    Many applications leak sensitive
-    information that could identify you on the Internet. I2P only filters
-    connection data, but if the program you intend to run sends this
-    information as content, I2P has no way to protect your anonymity.  For
-    example, some mail applications will send the IP address of the machine
-    they are running on to a mail server. There is no way for I2P to filter
-    this, thus using I2P to 'socksify' existing applications is possible, but
-    extremely dangerous.
-
            
-And quoting from a 2005 email:
-
            
-... there is a reason why human and
-others have both built and abandoned the SOCKS proxies.  Forwarding
-arbitrary traffic is just plain unsafe, and it behooves us as
-developers of anonymity and security software to have the safety of
-our end users foremost in our minds.
-
-Hoping that we can simply strap an arbitrary client on top of I2P
-without auditing both its behavior and its exposed protocols for
-security and anonymity is naive.  Pretty much *every* application
-and protocol violates anonymity, unless it was designed for it
-specifically, and even then, most of those do too.  That's the
-reality.  End users are better served with systems designed for
-anonymity and security.  Modifying existing systems to work in
-anonymous environments is no small feat, orders of magnitude more
-work that simply using the existing I2P APIs.
-
            
-
-
            
-The SOCKS proxy
-supports standard addressbook names, but not Base64 destinations.
-Base32 hashes should work as of release 0.7.
-It supports outgoing connections only, i.e. an I2PTunnel Client.
-UDP support is stubbed out but not working yet.
-Outproxy selection by port number is stubbed out.
-
            
-
-
            See Also
            
-
-
-
            If You Do Get Something Working
            
-Please let us know. And please provide substantial warnings about the
-risks of socks proxies.
-
-{% endblock %}
diff --git a/www.i2p2/pages/streaming.html b/www.i2p2/pages/streaming.html
deleted file mode 100644
index 078230b0..00000000
--- a/www.i2p2/pages/streaming.html
+++ /dev/null
@@ -1,501 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Streaming Library{% endblock %}
-{% block content %}
-Updated November 2012, current as of router version 0.9.3
-
            Overview
            
-
-
            
-The streaming library is technically part of the "application" layer,
-as it is not a core router function.
-In practice, however, it provides a vital function for almost all
-existing I2P applications, by providing a TCP-like
-streams over I2P, and allowing existing apps to be easily ported to I2P.
-The other end-to-end transport library for client communication is the
-datagram library.
-
            
-
-
            The streaming library is a layer on top of the core 
-I2CP API that allows reliable, in-order, and authenticated streams
-of messages to operate across an unreliable, unordered, and unauthenticated 
-message layer.  Just like the TCP to IP relationship, this streaming 
-functionality has a whole series of tradeoffs and optimizations available, but
-rather than embed that functionality into the base I2P code, it has been factored
-off into its own library both to keep the TCP-esque complexities separate and to
-allow alternative optimized implementations.
            
-
-
            
-In consideration of the relatively high cost of messages, 
-the streaming library's protocol for scheduling and delivering those messages has been optimized to
-allow individual messages passed to contain as much information as is available.
-For instance, a small HTTP transaction proxied through the streaming library can
-be completed in a single round trip - the first messages bundle a SYN, FIN, and
-the small HTTP request payload, and the reply bundles the SYN,
-FIN, ACK, and the HTTP response payload.  While an additional
-ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has been
-received, the local HTTP proxy can often deliver the full response to the browser 
-immediately.  
-
            
-
-
            
-The streaming library bears much resemblance to an 
-abstraction of TCP, with its sliding windows, congestion control algorithms
-(both slow start and congestion avoidance), and general packet behavior (ACK,
-SYN, FIN, RST, rto calculation, etc).  
-
            
-
-
            
-The streaming library is
-a robust library
-which is optimized for operation over I2P.
-It has a one-phase setup, and
-it contains a full windowing implementation.
-
            
-
-
-
-
-
            API
            
-
-
            
-The streaming library API provides a standard socket paradigm to Java applications.
-The lower-level
-I2CP
-API is completely hidden, except that applications may pass
-I2CP parameters through the streaming library,
-to be interpreted by I2CP.
-
            
-
-
            
-The standard interface to the streaming lib is for the application to use the
-I2PSocketManagerFactory
-to create an
-I2PSocketManager.
-The application then asks the socket manager for an
-I2PSession,
-which will cause a connection to the router via
-I2CP.
-The application can then setup connections with an
-I2PSocket
-or receive connections with an
-I2PServerSocket.
-
            
-
            
-Here are the
-full streaming library Javadocs.
-
            
-
-
            
-For a good example of usage, see the i2psnark code.
-
            
-
-
-
            Options and Defaults
            
-
            
-The options and current default values are listed below.
-Options are case-sensitive and may be set for the whole router, for a particular client, or for an individual socket on a
-per-connection basis.
-Many values are tuned for HTTP performance over typical I2P conditions. Other applications such
-as peer-to-peer services are strongly encouraged to
-modify as necessary, by setting the options and passing them via the call to
-I2PSocketManagerFactory.createManager(_i2cpHost, _i2cpPort, opts).
-Time values are in ms.
-
            
-
            
-Note that higher-layer APIs, such as
-SAM,
-BOB, and
-I2PTunnel,
-may override these defaults with their own defaults.
-Also note that many options only apply to servers listening for incoming connections.
-
            
-As of release 0.9.1, most, but not all, options may be changed on an active socket manager or session.
-See the javadocs for details.
-
            
-
-
-
-
-
-
-
            OptionDefaultNotes
            i2cp.accessListnullComma- or space-separated list of Base64 peer Hashes used for either access list or blacklist
-      As of release 0.7.13.
-
            i2cp.enableAccessListfalse
-Use the access list as a whitelist for incoming connections
-      As of release 0.7.13.
-
            i2cp.enableBlackListfalse
-Use the access list as a blacklist for incoming connections
-      As of release 0.7.13.
-
            i2p.streaming.answerPingstrueWhether to respond to incoming pings
-
            i2p.streaming.blacklistnullComma- or space-separated list of Base64 peer Hashes to be
-      blacklisted for incoming connections to ALL destinations in the context.
-      This option must be set in the context properties, NOT in the createManager() options argument.
-      Note that setting this in the router context will not affect clients outside the
-      router in a separate JVM and context.
-      As of release 0.9.3.
-
            i2p.streaming.bufferSize64K
-      How much transmit data (in bytes) will be accepted that hasn't been written out yet.
-
            i2p.streaming.congestionAvoidanceGrowthRateFactor1
-
-      When we're in congestion avoidance, we grow the window size at the rate
-      of 1/(windowSize*factor).  In standard TCP, window sizes are in bytes,
-      while in I2P, window sizes are in messages.
-      A higher number means slower growth.
-
            i2p.streaming.connectDelay-1
-
-      How long to wait after instantiating a new con 
-      before actually attempting to connect.  If this is
-      <= 0, connect immediately with no initial data.  If greater than 0, wait
-      until the output stream is flushed, the buffer fills, 
-      or that many milliseconds pass, and include any initial data with the SYN.
-
            i2p.streaming.connectTimeout5*60*1000
-      How long to block on connect, in milliseconds. Negative means indefinitely. Default is 5 minutes.
-
            i2p.streaming.disableRejectLoggingfalse
-      Whether to disable warnings in the logs when an incoming connection is rejected due to connection limits.
-      As of release 0.9.4.
-
            i2p.streaming.enforceProtocolfalseWhether to listen only for the streaming protocol.
-      Setting to true will prohibit communication with Destinations earlier than release 0.7.1
-      (released March 2009). Set to true if running multiple protocols on this Destination.
-      As of release 0.9.1.
-
            i2p.streaming.inactivityAction2 (send) (0=noop, 1=disconnect)
-    What to do on an inactivity timeout - do nothing, disconnect, or send a duplicate ack.
-
            i2p.streaming.inactivityTimeout90*1000
-
            i2p.streaming.initialAckDelay2000
-
            i2p.streaming.initialResendDelay1000
-
-   The initial value of the resend delay field in the packet header, times 1000.
-   Not fully implemented; see below.
-
            i2p.streaming.initialRTT8000 (if no sharing data available)
-
            i2p.streaming.initialWindowSize6(if no sharing data available)
-   In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages.
-
            i2p.streaming.maxConcurrentStreams-1 (0 or negative value means unlimited)
-   This is a total limit for incoming and outgoing combined.
-
            i2p.streaming.maxConnsPerMinute0 Incoming connection limit (per peer; 0 means disabled)
-      As of release 0.7.14.
-
            i2p.streaming.maxConnsPerHour0 (per peer; 0 means disabled)
-      As of release 0.7.14.
-
            i2p.streaming.maxConnsPerDay0 (per peer; 0 means disabled)
-      As of release 0.7.14.
-
            i2p.streaming.maxMessageSize1730The MTU in bytes.
-
            i2p.streaming.maxResends8
-
-   Maximum number of retransmissions before failure.
-
            i2p.streaming.maxTotalConnsPerMinute0 Incoming connection limit (all peers; 0 means disabled)
-      As of release 0.7.14.
-
            i2p.streaming.maxTotalConnsPerHour0 (all peers; 0 means disabled)
-   Use with caution as exceeding this will disable a server for a long time.
-      As of release 0.7.14.
-
            i2p.streaming.maxTotalConnsPerDay0 (all peers; 0 means disabled)
-   Use with caution as exceeding this will disable a server for a long time.
-      As of release 0.7.14.
-
            i2p.streaming.maxWindowSize128
-
            i2p.streaming.profile1 (bulk)(2=interactive not supported)
-      This doesn't currently do anything, but setting it to a value other than 1 will cause an error.
-
            i2p.streaming.readTimeout-1
-
-      How long to block on read, in milliseconds. Negative means indefinitely.
-
            i2p.streaming.slowStartGrowthRateFactor1
-
-      When we're in slow start, we grow the window size at the rate
-      of 1/(factor).  In standard TCP, window sizes are in bytes,
-      while in I2P, window sizes are in messages.
-      A higher number means slower growth.
-
            i2p.streaming.writeTimeout-1
-
-      How long to block on write/flush, in milliseconds. Negative means indefinitely.
-
            
-
-
-
-
-
            Protocol Specification
            
-
            Packet Format
            
-
            
-The format of a single packet in the streaming protocol is:
-
            -
-+----+----+----+----+----+----+----+----+
-| send Stream ID    | rcv Stream ID     |
-+----+----+----+----+----+----+----+----+
-| sequence  Num     | ack Through       |
-+----+----+----+----+----+----+----+----+
-| nc |   NACKs ...
-+----+----+----+----+----+----+----+----+
-     | rd |  flags  | opt size| opt data
-+----+----+----+----+----+----+----+----+
-   ...                                  |
-+----+----+----+----+----+----+----+----+
-|   payload ...
-+----+----+----+----//
-
-
-
            
-
-
-
            FieldLengthContents
-
            sendStreamId 4 byte IntegerRandom number selected by the connection recipient
-and constant for the life of the connection.
-0 in the SYN message sent by the originator, and in subsequent messages, until a SYN reply is received,
-containing the peer's stream ID.
-
-
            receiveStreamId 4 byte IntegerRandom number selected by the connection originator
-and constant for the life of the connection. May be 0 if unknown, for example in a RESET packet.
-
-
            sequenceNum 4 byte Integer
-The sequence for this message, starting at 0 in the SYN message,
-and incremented by 1 in each message except for plain ACKs and retransmissions.
-If the sequenceNum is 0 and the SYN flag is not set, this is a plain ACK 
-packet that should not be ACKed.
-
-
            ackThrough 4 byte Integer
-The highest packet sequence number that was received
-on the receiveStreamId.  This field is ignored on the initial
-connection packet (where receiveStreamId is the unknown id) or
-if the NO_ACK flag set.
-All packets up to and including this sequence number are ACKed,
-EXCEPT for those listed in NACKs below.
-
-
            NACK count1 byte Integer
-The number of 4-byte NACKs in the next field
-
-
            NACKs n * 4 byte Integers
-Sequence numbers less than ackThrough that are not yet received.
-Two NACKs of a packet is a request for a 'fast retransmit' of that packet.
-
-
            resendDelay1 byte Integer
-How long is the creator of this packet going to wait before
-resending this packet (if it hasn't yet been ACKed).  The 
-value is seconds since the packet was created.
-Currently ignored on receive.
-
-
            flags 2 byte value
-See below.
-
-
            option size2 byte Integer
-The number of bytes in the next field
-
-
            option data0 or more bytes
-As specified by the flags. See below.
-
-
            payload remaining packet size
-
            
-
-
            Flags and Option Data Fields
            
-
            The flags field above specifies some metadata about the packet, and in
-turn may require certain additional data to be included.  The flags are
-as follows. Any data structures specified must be added to the options area
-in the given order.
            
-
            
-Bit order: 15....0 (15 is MSB)
-
            
-
-
            BitFlagOption DataFunction
-
            0SYNCHRONIZE--
-Similar to TCP SYN. Set in the initial packet and in the first response.
-FROM_INCLUDED and SIGNATURE_INCLUDED must be set also.
-
            1CLOSE--
-Similar to TCP FIN. If the response to a SYNCHRONIZE fits in a single message, the response
-will contain both SYNCHRONIZE and CLOSE.
-SIGNATURE_INCLUDED must be set also.
-
            2RESET--
-Abnormal close.
-SIGNATURE_INCLUDED must be set also.
-
            3SIGNATURE_INCLUDED40 byte DSA Signature
-
-Currently sent only with SYNCHRONIZE, CLOSE, and RESET, where it is required.
-The signature uses the Destination's DSA signing keys 
-to sign the entire header and payload with the 40-byte space in the option data field 
-for the signature being set to all zeroes.
-
            4SIGNATURE_REQUESTED--
-Unused. Requests every packet in the other direction to have SIGNATURE_INCLUDED
-
            5FROM_INCLUDED387+ byte Destination
-
-Currently sent only with SYNCHRONIZE, where it is required.
-
            6DELAY_REQUESTED2 byte Integer
-Optional delay.
-How many milliseconds the sender of this packet wants the recipient
-to wait before sending any more data.
-A value greater than 60000 indicates choking.
-
            7MAX_PACKET_SIZE_INCLUDED2 byte Integer
-Currently sent with SYNCHRONIZE only.
-Was also sent in retransmitted packets until release 0.9.1.
-
            8PROFILE_INTERACTIVE--
-Unused or ignored; the interactive profile is unimplemented.
-
            9ECHO--
-Unused except by ping programs
-
            10NO_ACK--
-This flag simply tells the recipient to ignore the ackThrough field in the header.
-Currently unused, the ackThrough field is always valid.
-
            11-15unused
-
            
-
-
            Implementation Details
            
-
-
            Setup
            
-
            
-The initiator sends a packet with the SYNCHRONIZE flag set. This packet may contain the initial data as well.
-The peer replies with a packet with the SYNCHRONIZE flag set. This packet may contain the initial response data as well.
-
            
-
            
-The initiator may send additional data packets, up to the initial window size, before receiving the SYNCHRONIZE response.
-These packets will also have the send Stream ID field set to 0.
-Recipients must buffer packets received on unknown streams for a short period of time, as they may
-arrive out of order, in advance of the SYNCHRONIZE packet.
-
            
-
-
            MTU Selection and Negotiation
            
-
            
-The maximum message size (also called the MTU / MRU) is negotiated to the lower value supported by
-the two peers. As tunnel messages are padded to 1KB, a poor MTU selection will lead to
-a large amount of overhead.
-The MTU is specified by the option i2p.streaming.maxMessageSize.
-The current default MTU of 1730 was chosen to fit precisely into two 1K I2NP tunnel messages,
-including overhead for the typical case.
-
            
-
            
-The first message in a connection includes a 387 byte (typical) Destination added by the streaming layer,
-and usually a 898 byte (typical) LeaseSet, and Session keys, bundled in the Garlic message by the router.
-(The LeaseSet and Session Keys will not be bundled if an ElGamal Session was previously established).
-Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not always attainable.
-However, the selection of the MTU, together with careful implementation of fragmentation
-and batching strategies in the tunnel gateway processor, are important factors in network bandwidth,
-latency, reliability, and efficiency, especially for long-lived connections.
-
            
-
-
            Data Integrity
            
-Data integrity is assured by the gzip CRC-32 checksum implemented in
-the I2CP layer.
-There is no checksum field in the streaming protocol.
-
-
-
            Packet Encapsulation
            
-Each packet is sent through I2P as a single message (or as an individual clove in a
-Garlic Message).
-Message encapsulation is implemented in the underlying
-I2CP,
-I2NP, and
-tunnel message layers.
-There is no packet delimiter mechanism or payload length field in the streaming protocol.
-
-
-
            Windowing
            
-
            
-The streaming lib uses standard slow-start (exponential window growth) and congestion avoidance (linear window growth)
-phases, with exponential backoff.
-Windowing and acknowledgments use packet count, not byte count.
-
            
-
-
-
            Close
            
-
            
-Any packet, including one with the SYNCHRONIZE flag set, may have the CLOSE flag sent as well.
-The connection is not closed until the peer responds with the CLOSE flag.
-CLOSE packets may contain data as well.
-
            
-
-
-
            Control Block Sharing
            
-
            
-The streaming lib supports "TCP" Control Block sharing.
-This shares two important streaming lib parameters
-(window size and round trip time)
-across connections to the same remote peer.
-This is used for "temporal" sharing at connection open/close time,
-not "ensemble" sharing during a connection (See
-RFC 2140).
-There is a separate share per ConnectionManager (i.e. per local Destination)
-so that there is no information leakage to other Destinations on the
-same router.
-The share data for a given peer expires after a few minutes.
-
            
-
-
            Other Parameters
            
-The following parameters are hardcoded, but may be of interest for analysis:
-
              
-
            • MIN_RESEND_DELAY = 2*1000 (minimum RTO)
-
            • MAX_RESEND_DELAY = 45*1000 (maximum RTO)
-
            • MIN_WINDOW_SIZE = 1
-
            • TREND_COUNT = 3
-
            • RTT_DAMPENING = 0.875
-
            • MIN_MESSAGE_SIZE = 512 (minimum MTU)
-
            • INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
-
            • INITIAL_TIMEOUT = 1.5 * initialRTT
-
            • PASSIVE_FLUSH_DELAY = 250
-
            • Maximum RTT estimate: 60*1000
-
            
-
            
-
-
            History
            
-
            
-The streaming library has grown organically for I2P - first mihi implemented the
-"mini streaming library" as part of I2PTunnel, which was limited to a window
-size of 1 message (requiring an ACK before sending the next one), and then it was
-refactored out into a generic streaming interface (mirroring TCP sockets) and the
-full streaming implementation was deployed with a sliding window protocol and 
-optimizations to take into account the high bandwidth x delay product.  Individual
-streams may adjust the maximum packet size and other options. The default
-message size is selected to fit precisely in two 1K I2NP tunnel messages,
-and is a reasonable tradeoff between the bandwidth costs of 
-retransmitting lost messages, and the latency and overhead of multiple messages.
-
            
-
-
-
-
-
-
            Future Work
            
-The behavior of the streaming library has a profound impact on
-application-level performance, and as such, is an important
-area for further analysis.
-
              
-
            • 
-Additional tuning of the streaming lib parameters may be necessary.
-
              • 
-
            • 
-Another area for research is the interaction of the streaming lib with the
-NTCP and SSU transport layers.
-See the NTCP discussion page for details.
-
              • 
-
            • 
-The interaction of the routing algorithms with the streaming lib strongly affects performance.
-In particular, random distribution of messages to multiple tunnels in a pool
-leads to a high degree of out-of-order delivery which results in smaller window
-sizes than would otherwise be the case. The router currently routes 
-messages for a single from/to destination pair through a consistent set 
-of tunnels, until tunnel expiration or delivery failure. The router's 
-failure and tunnel selection algorithms should be reviewed for possible 
-improvements.
-
              • 
-
            • 
-The data in the first SYN packet may exceed the receiver's MTU.
-
              • 
-
            • 
-The DELAY_REQUESTED field could be used more.
-
              • 
-
            • 
-Duplicate initial SYNCHRONIZE packets on short-lived streams may not be recognized and removed.
-
              • 
-
            • 
-Don't send the MTU in a retransmission.
-
              • 
-
            • 
-      Data is sent along unless the outbound window is full.
-      (i.e. no-Nagle or TCP_NODELAY)
-      Probably should have a configuration option for this.
-
              • 
-
            • 
-zzz has added debug code to the streaming library to log packets in a wireshark-compatible
-(pcap) format; Use this to further analyze performance.
-The format may require enhancement to map more streaming lib parameters to TCP fields.
-
              • 
-
            • 
-There are proposals to replace the streaming lib with standard TCP
-(or perhaps a null layer together with raw sockets).
-This would unfortunately be incompatible with the streaming lib
-but it would be good to compare the performance of the two.
-
              • 
-
            
-
-
-
-
-{% endblock %}
diff --git a/www.i2p2/pages/summerofcode-2011-end.html b/www.i2p2/pages/summerofcode-2011-end.html
deleted file mode 100644
index 0dc9696c..00000000
--- a/www.i2p2/pages/summerofcode-2011-end.html
+++ /dev/null
@@ -1,24 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Ipredator Summer of Code{% endblock %}
-{% block content %}
-
-
-
            itoopie and I2PControl are launching!
            
-
-
            I'm happy to announce that itoopie and I2PControl are available publicly.
            
-
-
            itoopie is a graphical interface intended as a compliment to the I2P Router Console.
-The aim of itoopie is to provide an interface that is simpler and has a lower lurning curve than the I2P Router Console.
            
-
-
            I2PControl is an I2P plugin providing a JSONRPC interface for the I2P router. The interface supports setting basic settings (bandwidth, ports etc.), reading many stats and is provided over an SSL encrypted HTTP connection.
            
-
-
            More information and instructions can be found at itoopie.net, itoopie.i2p.to (via proxy)and itoopie.i2p (anonymously).
-
-This project has been funded by the VPN services Relakks & Ipredator and was initiated by Jan-Erik Fiske and Peter Sunde.
-
-
            Thank you Jan-Erik and Peter,
-
            // hottuna
            
-{% endblock %}
-
-
-
diff --git a/www.i2p2/pages/summerofcode-2011.html b/www.i2p2/pages/summerofcode-2011.html
deleted file mode 100644
index 9f39a577..00000000
--- a/www.i2p2/pages/summerofcode-2011.html
+++ /dev/null
@@ -1,19 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}ViaEuropa Summer of Code{% endblock %}
-{% block content %}
-
-
-
            Ipredator Summer of Code
            
-
-
            
-I have been commissioned to contribute code to I2P during the summer of 2011, implementing a control protocol and a client for this protocol (similar to Vidalia for Tor).
-This work was the idea of Jan-Erik Fiske of ViaEuropa and Peter Sunde of flattr and The Pirate Bay fame and its funding will be generously provided by Relakks and Ipredator.
-
            
-
-
            
-Current information can be found on zzz's forum and #i2p-dev on chat.freenode.net
-
            
-
-
            Cheers
-
            // hottuna (or Robert)
            
-{% endblock %}
diff --git a/www.i2p2/pages/supported_applications.html b/www.i2p2/pages/supported_applications.html
deleted file mode 100644
index 5839354d..00000000
--- a/www.i2p2/pages/supported_applications.html
+++ /dev/null
@@ -1,621 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Supported Applications{% endblock %}
-{% block content %}
-
-
            Supported Applications
            
-
-
-
-
            This is intended to be a comprehensive listing of applications used with
-I2P. If you know of something that's missing please submit a ticket on
-Trac, and be sure to select the
-“www” component in the submission form.
            
-
-
            Supported applications are tagged with one or more of the following:
            
-
-
            
-  
            bundled
            
-
-  
            
-    
            Bundled application — I2P ships with a few officially
-    supported applications that let new users take immediate advantage of
-    some of I2P's more useful capabilities.
            
-  
            
-
-  
            plugin
            
-
-  
            
-    
            Third-party plugin — I2P's plugin system provides convenient
-    deployment of I2P-enabled applications and allows tighter integration
-    with the router. Plugins are [reviewed by the community](http://plugins.i2p) to identify security and
-    anonymity issues.
            
-  
            
-
            
-
-
            
-  
            standalone, standalone/mod
            
-
-  
            
-    
            Third-party standalone application — Many standard network
-    applications only require careful setup and configuration to communicate
-    anonymously over I2P. These are tagged with standalone. Some
-    applications, tagged with standalone/mod, require patching to
-    function properly over I2P or to prevent inadvertent disclosure of
-    identifying information such as the user's hostname or external IP
-    address.
            
-  
            
-
-  
            service
            
-
-  
            
-    
            Third-party essential network service — Services which on
-    the I2P network are analogous to those provided on the public Internet
-    by hosting providers, ISPs, and Google: eepsite indexes and jump
-    services, search engines, email, DNS-style name services, hosting,
-    proxies, etc. These services focus on boosting the usefulness of the
-    network as a whole, and making network content more discoverable.
            
-  
            
-
-  
            unmaintained
            
-
-  
            
-    
            Unmaintained — This is used to tag plugins, applications,
-    and services which appear to be unmaintained and may be removed from
-    this listing in the future.
            
-  
            
-
            
-
-
            Warning: Using an application, plugin, or service with I2P
-doesn't automatically protect your anonymity. I2P is merely a set of tools
-which can help you mitigate certain identified
-threats to anonymity. We do not and cannot make any guarantees about the
-safety of the applications, plugins, and services listed below. Most
-applications and plugins must be properly configured, and some will need to
-be patched — and even then your anonymity might not be assured. Similarly,
-services could put your anonymity at risk, either by design or through
-carelessness on their part or your own.
            
-
-
            If you have doubts about the suitability of an application,
-plugin, or service for use with I2P, you are urged to inquire about privacy
-issues with its maintainers, to search its mailing lists and bug tracker if
-one exists, and consult trusted, knowledgeable members of the I2P
-community.
            
-
-
            Take responsibility for your own anonymity and safety — always
-seek expert advice, educate yourself, practice good judgment, be mindful of
-disclosing personally identifying information, and don't take
-shortcuts.
            
-
-
            Blogging, Forums, and Wikis
            
-
-
              
-    
-
-  
            • 
-    
              El
-    Dorado — Lightweight forum software.
-    [standalone/mod]
              
-  
              • 
-
-  
            • 
-    
              Pebble
-    — Another lightweight blogging platform.
-    [plugin, standalone/mod]
              
-  
              • 
-
-  
            • 
-    
              phpBB — Most
-    popular open source forum software.
-    [standalone/mod]
              
-  
              • 
-
-  
            • 
-    
              Syndie —
-    Distributed forums software, originally developed by jrandom.
-    [plugin, standalone, unmaintained]
              
-  
              • 
-  
            • 
-     
              JAMWiki —
-     A Java-based MediaWiki clone. No external database needed.
-     Plugin available here.
-     [standalone, plugin]
              
-  
              • 
-
            
-
-
            Decentralized File
-Storage
            
-
-
              
-  
            • Tahoe-LAFS-I2P — Port
-  of the Tahoe-LAFS
-  distributed file system to the I2P network. Controller plugin here.
-  [plugin, standalone]
              • 
-
            
-
-
            Development Tools
            
-
-
            Version control
            
-
-
              
-  
            • 
-    
              Git — Most popular
-    distributed version control system. [standalone]
              
-  
              • 
-
-  
            • 
-    
              Monotone — Another
-    distributed version control system. Currently used in I2P development.
-    [standalone]
              
-  
              • 
-
            
-
-
            Domain Naming
            
-
-
              
-  
            • susidns
-  — Provides management of addressbooks, which are part of a simple,
-  user-controlled I2P naming system somewhat
-  analogous to the Internet's Domain Name System (DNS). Addressbooks map
-  Base64 destinations to short, usually human-readable “domain” names ending
-  with a .i2p suffix which the I2P router's HTTP client can resolve back to
-  Base64 addresses. (Note: While Base64 destinations are globally
-  unique, addressbook “domain” names only resolve to unique destinations
-  locally.) [bundled]
              • 
-
            
-
-
            Email
            
-
-
              
-  
            • 
-    
              I2P-Bote —
-    Serverless peer-to-peer email application using a distributed hash table
-    (DHT) for secure mail storage. [plugin]
              
-  
              • 
-
-  
            • 
-    
              Postman's anonymous email
-    service — Provides email service within the I2P network via
-    @mail.i2p addresses, and email gateway service between the I2P network
-    and the public Internet via @i2pmail.org addresses. One of the oldest
-    continuous services on I2P. [service]
              
-  
              • 
-
-  
            • 
-    
              susimail
-    — Simple web browser-based email interface. Configured to use Postman's
-    email service by default. [bundled]
              
-  
              • 
-
            
-
-
            File Sharing
            
-
-
            BitTorrent clients
            
-
-
              
-  
            • 
-    
              I2PSnark — I2P's
-    integrated BitTorrent client. [bundled]
              
-  
              • 
-
-  
            • 
-    
              I2PSnarkXL
-    — Modified version of I2PSnark. [standalone]
              
-  
              • 
-
-  
            • 
-    
              Robert — a
-    fork of rufus that uses the Basic Open Bridge (BOB) and has many
-    improvements, including using the latest wxwidgets and python. It also
-    supports use of seedless if installed for trackerless torrents and
-    magnet-link like fetching of torrents within i2p.
-    [standalone]
              
-  
              • 
-
-  
            • 
-    
              Transmission —
-    Clean, full-featured cross-platform BitTorrent client with official
-    ports for several GUI toolkits. [standalone/mod]
              
-  
              • 
-
-  
            • 
-    
              Azureus/Vuze —
-    Had a built-in I2P transport for a while.
-    [standalone, unmaintained]
              
-  
              • 
-
            
-
-
            BitTorrent trackers
-and indexers
            
-
-
            For a detailed feature comparison of I2P-enabled trackers/indexers, see
-here.
            
-
-
              
-  
            • 
-    
              Bytemonsoon — The
-    code that powered one of the first major tracker/indexer sites on the
-    Internet. Patched for I2P. [standalone/mod]
              
-  
              • 
-
-  
            • 
-    
              opentracker
-    — Lightweight tracker/indexer. I2P mod available in the i2p.opentracker
-    branch of the I2P Monotone repository.
-    [standalone/mod]
              
-  
              • 
-
-  
            • 
-    
              zzzot —
-    zzz's Java-based open tracker. More info
-    here.
-    [plugin]
              
-  
              • 
-
            
-
-
            ED2K
            
-
-
              
-  
            • iMule — I2P
-  port of the aMule ED2K client. [standalone]
              • 
-
            
-
-
            Gnutella
            
-
-
              
-  
            • 
-    
              I2Phex — Port
-    of the Phex Gnutella client. Website
-    for plugin version here.
-    [plugin, standalone]
              
-  
              • 
-
-  
            • 
-    
              jwebcache
-    — Cache for Gnutella peers on I2P. Website for plugin version here.
-    [plugin, standalone]
              
-  
              • 
-
            
-
-
            Network
-Administration
            
-
-
            General-purpose
-socket utilities
            
-
-
              
-  
            • 
-    
              netcat —
-    Unix standard tool for socket relaying. Several clones, ports, and forks
-    have appeared over the years. [standalone]
              
-  
              • 
-
-  
            • 
-    
              socat — Like
-    netcat but more powerful. [standalone]
              
-  
              • 
-
-  
            • 
-    
              tsocks
-    — Proxy providing simple, transparent SOCKS-ification of network
-    applications. [standalone]
              
-  
              • 
-
            
-
-
            SSH/SCP/SFTP
            
-
-
              
-  
            • 
-    
              OpenSSH — Most
-    popular implementation of the Secure Shell (SSH) protocol and related
-    tools. [standalone]
              
-  
              • 
-
-  
            • 
-    
              PuTTY
-    — Open source Secure Shell (SSH) client for Windows.
-    [standalone]
              
-  
              • 
-
            
-
-
            Real-time Chat
            
-
-
            Instant messaging
-clients
            
-
-
              
-  
            • I2P
-  Messenger — IM client with multiple incarnations.
-  [standalone]
              • 
-
            
-
-
            IRC clients
            
-
-
            Many IRC clients leak identifying information to servers or other
-clients, so I2P's IRC and SOCKS IRC client tunnels filter certain inbound
-and outbound messages to scrub data such as LAN IP addresses, external IP
-addresses, local hostnames, and the name and version of the IRC client. Two
-message types in particular, DCC and CTCP, can't be sufficiently anonymized
-without changes to the protocols or to IRC client/server code, so they are
-completely blocked, except for CTCP ACTION (the message emitted by the
-/me command) which isn't inherently dangerous.
            
-
-
            I2P's IRC filtering may not cover every possible leak — users should also
-check if their client is sending their real name or local username. Packet
-sniffers such as Wireshark are
-useful here. Eliminating remaining leaks may be as simple as changing the
-client's default configuration. If that doesn't help, inform the I2P
-developers; they may be able to solve it via additional filtering.
            
-
-
              
-  
            • 
-    
              jIRCii —
-    Small Java-based IRC client. Plugin available here.
-    [plugin, standalone]
              
-  
              • 
-
-  
            • 
-    
              XChat —
-    Cross-platform graphical IRC client.
-    [standalone]
              
-  
              • 
-
-  
            • 
-    
              irssi — Unixy
-    terminal-based IRC client. [standalone]
              
-  
              • 
-
-  
            • 
-    
              WeeChat —
-    Another Unixy terminal-based IRC client.
-    [standalone]
              
-  
              • 
-
            
-
-
            IRC servers
            
-
-
              
-  
            • 
-    
              ngIRCd — IRC
-    server developed from scratch. [standalone/mod]
              
-  
              • 
-
-  
            • 
-    
              UnrealIRCd
-    — Most popular IRC server. [standalone/mod]
              
-  
              • 
-
            
-
-
            Web Browsing
            
-
-
            Anonymous websites
            
-
-
              
-  
            • 
-    
              Eepsites — Any website hosted anonymously on I2P,
-    reachable through the I2P router's HTTP proxy.
-    [service]
              
-  
              • 
-
-  
            • 
-    
              Deepsites — Distributed anonymous websites hosted
-    using Tahoe-LAFS-I2P, currently only reachable with Tahoe-LAFS-I2P
-    clients or through the Tahoe-LAFS-I2P HTTP proxy.
-    [service]
              
-  
              • 
-
-  
            • 
-    
              i2host.i2p —
-    Website for sponge's jump service.
-    Source code available. [service]
              
-  
              • 
-
-  
            • 
-    
              i2jump.i2p —
-    Another jump service. [service]
              
-  
              • 
-
-  
            • 
-    
              perv.i2p —
-    Dynamically updated eepsite index. [service]
              
-  
              • 
-
-  
            • 
-    
              stats.i2p — Website
-    for zzz's jump service.
-    [service]
              
-  
              • 
-
            
-
-
            Proxy software
            
-
-
              
-  
            • 
-    
              Polipo
-    — SOCKS-enabled caching web proxy with basic filtering capabilities.
-    [standalone]
              
-  
              • 
-
-  
            • 
-    
              Privoxy —
-    Privacy-focused non-caching web proxy with advanced filtering
-    capabilities. Excels at removing ads and other junk.
-    [standalone]
              
-  
              • 
-
-  
            • 
-    
              Squid —
-    Venerable caching web proxy. [standalone]
              
-  
              • 
-
            
-
-
            Inproxies
            
-
-
            Gateways allowing users on the public Internet to access eepsites.
            
-
-
              
-  
            • i2p.to — tino's inproxy on the public Internet.
-  [service]
              • 
-
            
-
-
            Outproxies
            
-
-
            Gateways allowing I2P users to access content hosted on the public
-Internet.
            
-
-
              
-  
            • false.i2p — Publicly
-  advertised outproxy running Squid, located in Germany.
-  [service]
              • 
-
            
-
-
            Website Hosting
            
-
-
              
-  
            • Jetty
-  — Lightweight web server and Java servlet container. I2P is tightly
-  integrated with a bundled copy of Jetty which by default is configured to
-  host the user's eepsite. The bundled
-  Jetty also serves the I2P router console and web applications bundled with
-  I2P. [bundled, standalone]
              • 
-
            
-
-
            Web servers
            
-
-
            In addition to Jetty, any web server should function over I2P without
-modification so long as it's HTTP-compliant. Some web servers known to
-currently serve content on the I2P network are:
            
-
-
              
-  
            • 
-    
              Apache HTTP
-    Server — Most popular web server on the public WWW.
-    [standalone]
              
-  
              • 
-
-  
            • 
-    
              Apache
-    Tomcat — Web server and Java servlet container. More
-    features than Jetty. [standalone]
              
-  
              • 
-
-  
            • 
-    
              lighttpd —
-    Fast lightweight web server. [standalone]
              
-  
              • 
-
-  
            • 
-    
              nginx —
-    High-performance lightweight web server.
-    [standalone]
              
-  
              • 
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/team.html b/www.i2p2/pages/team.html
deleted file mode 100644
index decb3702..00000000
--- a/www.i2p2/pages/team.html
+++ /dev/null
@@ -1,351 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Team{% endblock %}
-{% block content %}
-
            I2P Project Members
            
-
            We are a small group of people spread around several continents, working to
-advance different aspects of the project and discussing the design of the
-network.
-Get involved!
-
            
-
-
-
-	
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-    
-	
-	
-
-
-	
-	
-	
-
-
-        
-        
-        
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-	
-	
-	
-
-
-
-	
-	
-	
-	
-
-
-        
-	
-	
-
-
-        
-	
-	
-
-
-        
-	
-	
-
-
-        
-	
-	
-
-
-        
-	
-	
-
-
-        
-	
-	
-
-
-        
-	
-	
-
-
-        
-	
-	
-
-
-        
-	
-        
-
-
-        
-	
-        
-
-
-        
-	
-        
-
-
-        
-	
-        
-
-
-        
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-    
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-
-	
-	
-
-
-
-	
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-        
-        
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-	
-
-
-	
-
-
            AdminProject Managerzzzpoint of contact of last resort
            Treasurereche|onmanage donations / accounts / bounties
            PR managerorionpress contact, manages public relations and affairs
            Forum admincervantesmanage the public user forum
            Mirrors adminwelterdemanage the project mirrors
            Monotone guruwelterde, eche|onmanage the public monotone repositories
            Packager; LinuxKillYourTVLinux (Debian/Ubuntu) distribution packager
            Packager; WindowsKillYourTVWindows installer packager
            Release ManagerzzzBuilds and signs the releases
            Update adminKillYourTVMonitors and recruits in-network update hosts
            Reseed adminMeehMonitors, advises and recruits reseed hosts
            Security expert[vacant]threat model / crypto expert
            User Advocate[vacant]gather, prioritize, advocate for user needs
            Web Designer[vacant]manage the public project website content design
            Webserver adminwelterdemanage the public project webservers
            Website admin[vacant]manage the public project website content
            News Admineche|onmanage router console news feed
            Director of passion[vacant]community motivator
            DevCore Leadzzzlead dev for the SDK and router
            I2P mail leadpostmanorganize and develop the i2p mail system
            I2Host leadspongeI2Host addressbook application
            BOB leadspongeBasic Open Bridge
            I2P-Bote leadHungryHoboI2PBote plugin
            Robert leadspongeRobert BitTorrent client
            I2Phex lead[vacant]I2Phex Gnutella client
            I2PSnark leadzzzMaintains the integrated Bittorrent client
            iMule lead[vacant]eMule client over I2P
            Syndie lead[vacant]Syndie development
            Susimail lead[vacant]Susimail development
            Console[vacant]Router console HTML/CSS design
            SAM[vacant]SAM maintainer
            Console TranslationswalkingChinese
            monkeybrainsDutch
            magmaFrench
            eche|on, mixxyGerman
            rus, 4get, slowRussian
            userSpanish
            thelastcode, hamadaArabic
            [vacant]Other languages
            Contributorscervantesfire2pe dev, console enhancements
            Mathiasdmdesktopgui, dijjer port
            KillYourTVDebian/Ubuntu Packager and PPA maintainer
            [vacant]Help needed on many fronts!
            Past contributorsmihiI2PTunnel development, ministreaming library
            jrandomProject lead, Syndie lead
            ComplicationProject lead, Syndie lead, I2Phex, support guru
            mkvoreiMule lead
            redzaraI2Phex work
            strikerI2Phex work
            legionI2Phex work
            ConnelyPython SAM library, attack simulations
            mastiejaneri2pmail development
            dustSyndie help
            susi23i2p mail,susimail and susidns apps
            sirupI2Phex (port of Phex to I2P)
            Ragnarokaddressbook,i2p-bt,syndie client
            duckorganize and develop the i2p-bt BitTorrent port
            Ragnarokaddressbook, i2p-bt, syndie client development
            thecryptoencryption and signature routines, I2PIM
            aumSAM jython code, work on stasher (DHT) and v2v (VoI2P)
            hypercubusinstaller, systray, bogobot
            ughajbigi development, wiki migration, doc cleanup
            oOojava debugging and client development on I2PTunnel and the router console
            BrianRSAM perl module
            ecoi2psnark work
            shendarasjava cleanup
            JAnonymousdocs. wiki migration
            jartranslations into French
            scintillaC port of jcpuid
            smegheadC# SAM library, pants, fortuna integration
            NightbladelibSAM
            dinomani2p-bt tracker development
            DrWooi2p-bt tracker development
            dr|z3dConsole and website themes
            …and many others
            
-{% endblock %}
diff --git a/www.i2p2/pages/techintro.html b/www.i2p2/pages/techintro.html
deleted file mode 100644
index 3e4645f2..00000000
--- a/www.i2p2/pages/techintro.html
+++ /dev/null
@@ -1,888 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Introducing I2P{% endblock %}
-{% block content %}
-
-
            I2P: A scalable framework for anonymous communication
            
-   
-
-  
            
-  
            Introduction
            
-  
            
-    I2P is a scalable, self organizing, resilient packet switched anonymous 
-    network layer, upon which any number of different anonymity or security conscious 
-    applications can operate. Each of these applications may make their own anonymity, 
-    latency, and throughput tradeoffs without worrying about the proper implementation 
-    of a free route mixnet, allowing them to blend their activity with the larger 
-    anonymity set of users already running on top of I2P.
-  
            
-  
            
-    Applications available already provide the full range of typical Internet activities -
-    anonymous web browsing, web hosting, chat, file sharing, e-mail,
-    blogging and content syndication, newsgroups, as well as several other applications under development.
-    
              
-      
            • Web browsing: using any existing browser that supports using a proxy.
              • 
-      
            • Chat: IRC, Jabber, I2P-Messenger.
              • 
-      
            • File sharing: I2PSnark, Robert, iMule, 
-        I2Phex, PyBit, I2P-bt
-        and others.
-      
              • 
-      
            • E-mail: susimail and I2P-Bote.
              • 
-      
            • Blog: using e.g. the pebble plugin or the distributed blogging software Syndie.
              • 
-      
            • Distributed Data Store: Save your data redundantly in the Tahoe-LAFS cloud over I2P.
              • 
-      
            • Newsgroups: using any newsgroup reader that supports using a proxy.
              • 
-    
            
-  
            
-    Unlike web sites hosted within content distribution networks like Freenet 
-    or GNUnet, the services hosted on 
-    I2P are fully interactive - there are traditional web-style search engines, 
-    bulletin boards, blogs you can comment on, database driven sites, and bridges 
-    to query static systems like Freenet without needing to install it locally. 
-  
            
-  
            
-    With all of these anonymity enabled applications, I2P takes on the role 
-    of the message oriented middleware - applications say that they want to send 
-    some data to a cryptographic identifier (a "destination") and I2P takes care 
-    of making sure it gets there securely and anonymously. I2P also bundles a 
-    simple streaming library to allow I2P's anonymous 
-    best-effort messages to transfer as reliable, in-order streams, transparently 
-    offering a TCP based congestion control algorithm tuned for the high bandwidth 
-    delay product of the network. While there have been several simple SOCKS proxies 
-    available to tie existing applications into the network, their value has been 
-    limited as nearly every application routinely exposes what, in an anonymous 
-    context, is sensitive information. The only safe way to go is to fully audit 
-    an application to ensure proper operation and to assist in that we provide 
-    a series of APIs in various languages which can be used to make the most out 
-    of the network.
-  
            
-  
            
-    I2P is not a research project - academic, commercial, or governmental, but 
-    is instead an engineering effort aimed at doing whatever is necessary to provide 
-    a sufficient level of anonymity to those who need it. It has been in active 
-    development since early 2003 with one full time developer and a dedicated 
-    group of part time contributors from all over the world. All of the work done 
-    on I2P is open source and freely available on the website, 
-    with the majority of the code released outright into the public domain, though 
-    making use of a few cryptographic routines under BSD-style licenses. The people 
-    working on I2P do not control what people release client applications under, 
-    and there are several GPL'ed applications available (I2PTunnel, 
-    susimail, I2PSnark, I2P-Bote, 
-    I2Phex and others.).
-    Funding for I2P comes entirely from donations,
-    and does not receive any tax breaks in any jurisdiction at this time,
-    as many of the developers are themselves anonymous.
-  
            
-  
            Operation
            
-  
            Overview
            
-  
            
-    To understand I2P's operation, it is essential to understand a few key concepts. 
-    First, I2P makes a strict separation between the software participating in 
-    the network (a "router") and the anonymous endpoints ("destinations") associated 
-    with individual applications. The fact that someone is running I2P is not 
-    usually a secret. What is hidden is information on what the user is doing, 
-    if anything at all, as well as what router a particular destination is connected 
-    to. End users will typically have several local destinations on their router 
-    - for instance, one proxying in to IRC servers, another supporting the user's 
-    anonymous webserver ("eepsite"), another for an I2Phex instance, another for 
-    torrents, etc.
-  
            
-  
            
-    Another critical concept to understand is the "tunnel".
-    A tunnel is a directed path through an explicitly selected list of routers.
-    Layered encryption is used, so each of the routers can only decrypt a single layer.
-    The decrypted information contains the IP of the next router, along with
-    the encrypted information to be forwarded.
-    Each tunnel has a starting point (the first router, also known as "gateway")
-    and an end point. Messages can be sent only in one way. To send messages back,
-    another tunnel is required.
-  
            
-    
            
-      Inbound and outbound tunnel schematic
-      

            
-      Figure 1: Two types of tunnels exist: inbound and outbound.
-    
            
-  
            
-  
            
-    Two types of tunnels exist:
-    "outbound" tunnels send messages away from the tunnel creator,
-    while "inbound" tunnels bring messages to the tunnel creator.
-    Combining these two tunnels allows users to send messages to each other.
-    The sender ("Alice" in the above image) sets up an outbound tunnel,
-    while the receiver ("Bob" in the above image) creates an inbound tunnel.
-    The gateway of an inbound tunnel can receive messages from any other user
-    and will send them on until the endpoint ("Bob").
-    The endpoint of the outbound tunnel will need to send the message
-    on to the gateway of the inbound tunnel.
-    To do this, the sender ("Alice") adds instructions to her encrypted message.
-    Once the endpoint of the outbound tunnel decrypts the message,
-    it will have instructions to forward the message to the correct
-    inbound gateway (the gateway to "Bob").
-  
            
-  
            
-    A third critical concept to understand is I2P's "network database" (or "netDb") 
-    - a pair of algorithms used to share network metadata. The two types of metadata 
-    carried are "routerInfo" and "leaseSets" - the routerInfo gives routers the 
-    data necessary for contacting a particular router (their public keys, transport 
-    addresses, etc), while the leaseSet gives routers the information necessary 
-    for contacting a particular destination. A leaseSet contains a number of "leases".
-    Each of this leases specifies a tunnel gateway, which allows reaching a specific destination.
-    The full information contained in a lease:
-    
              
-      
            • Inbound gateway for a tunnel that allows reaching a specific destination.
              • 
-      
            • Time when a tunnel expires.
              • 
-      
            • Pair of public keys to be able to encrypt messages (to send through the tunnel and reach the destination).
              • 
-    
            
-    Routers themselves send their routerInfo to the netDb directly, while leaseSets are sent through outbound tunnels
-    (leaseSets need to be sent anonymously, to avoid correlating a router with his leaseSets).
-  
            
-  
            
-    We can combine the above concepts to build successful connections in the network.
-  
            
-  
            
-    To build up her own inbound and outbound tunnels, Alice does a lookup in the netDb to collect routerInfo.
-    This way, she gathers lists of peers she can use as hops in her tunnels.
-    She can then send a build message to the first hop, requesting the construction of a tunnel and asking
-    that router to send the construction message onward, until the tunnel has been constructed.
-  
            
-    
            
-      Request information on other routers
-                         
-      Build tunnel using router information
-      

            
-      Figure 2: Router information is used to build tunnels.
-    
            
-  
            
-  
            
-    When Alice wants to send a message to Bob, she first does a lookup in the 
-    netDb to find Bob's leaseSet, giving her his current inbound tunnel gateways. 
-    She then picks one of her outbound tunnels and sends the message down it with 
-    instructions for the outbound tunnel's endpoint to forward the message on 
-    to one of Bob's inbound tunnel gateways. When the outbound tunnel endpoint 
-    receives those instructions, it forwards the message as requested, and when 
-    Bob's inbound tunnel gateway receives it, it is forwarded down the tunnel 
-    to Bob's router. If Alice wants Bob to be able to reply to the message, she 
-    needs to transmit her own destination explicitly as part of the message itself.
-    This can be done by introducing a higher-level layer, which is done in the
-    streaming library.
-    Alice may also cut down on the response time by bundling her most 
-    recent leaseSet with the message so that Bob doesn't need to do a netDb lookup 
-    for it when he wants to reply, but this is optional.
-  
            
-    
            
-      Connect tunnels using leaseSets
-      

            
-      Figure 3: Leasesets are used to connect outbound and inbound tunnels.
-    
            
-  
            
-  
            
-    While the tunnels themselves have layered encryption to prevent unauthorized 
-    disclosure to peers inside the network (as the transport layer itself does 
-    to prevent unauthorized disclosure to peers outside the network), it is necessary 
-    to add an additional end to end layer of encryption to hide the message from 
-    the outbound tunnel endpoint and the inbound tunnel gateway. This "garlic 
-    encryption" lets Alice's router wrap up multiple messages into a single 
-    "garlic message", encrypted to a particular public key so that intermediary 
-    peers cannot determine either how many messages are within the garlic, what 
-    those messages say, or where those individual cloves are destined. For typical 
-    end to end communication between Alice and Bob, the garlic will be encrypted 
-    to the public key published in Bob's leaseSet, allowing the message to be 
-    encrypted without giving out the public key to Bob's own router.
-  
            
-  
            
-    Another important fact to keep in mind is that I2P is entirely message based 
-    and that some messages may be lost along the way. Applications using I2P can 
-    use the message oriented interfaces and take care of their own congestion 
-    control and reliability needs, but most would be best served by reusing the 
-    provided streaming library to view I2P as a streams 
-    based network.
-  
            
-  
            Tunnels
            
-  
            
-    Both inbound and outbound tunnels work along similar principles.
-    The tunnel gateway accumulates a number of tunnel messages, eventually preprocessing 
-    them into something for tunnel delivery. Next, the gateway encrypts that preprocessed 
-    data and forwards it to the first hop. That peer and subsequent tunnel participants 
-    add on a layer of encryption after verifying that it isn't a duplicate before 
-    forward it on to the next peer. Eventually, the message arrives at the endpoint 
-    where the messages are split out again and forwarded on as requested. The 
-    difference arises in what the tunnel's creator does - for inbound tunnels, 
-    the creator is the endpoint and they simply decrypt all of the layers added, 
-    while for outbound tunnels, the creator is the gateway and they pre-decrypt 
-    all of the layers so that after all of the layers of per-hop encryption are 
-    added, the message arrives in the clear at the tunnel endpoint.
-  
            
-  
            
-    The choice of specific peers to pass on messages as well as their particular 
-    ordering is important to understanding both I2P's anonymity and performance 
-    characteristics. While the network database (below) has its own criteria for 
-    picking what peers to query and store entries on, tunnel creators may use any peers 
-    in the network in any order (and even any number of times) in a single tunnel. 
-    If perfect latency and capacity data were globally known, selection and ordering 
-    would be driven by the particular needs of the client in tandem with their 
-    threat model. Unfortunately, latency and capacity data is not trivial to gather 
-    anonymously, and depending upon untrusted peers to provide this information 
-    has its own serious anonymity implications.
-  
            
-  
            
-    From an anonymity perspective, the simplest technique would be to pick peers 
-    randomly from the entire network, order them randomly and use those peers 
-    in that order for all eternity. From a performance perspective, the simplest 
-    technique would be to pick the fastest peers with the necessary spare capacity, 
-    spreading the load across different peers to handle transparent failover, 
-    and to rebuild the tunnel whenever capacity information changes. While the 
-    former is both brittle and inefficient, the later requires inaccessible information 
-    and offers insufficient anonymity. I2P is instead working on offering a range 
-    of peer selection strategies, coupled with anonymity aware measurement code 
-    to organize the peers by their profiles.
-  
            
-  
            
-    As a base, I2P is constantly profiling the peers with which it interacts 
-    with by measuring their indirect behavior - for instance, when a peer responds 
-    to a netDb lookup in 1.3 seconds, that round trip latency is recorded in the 
-    profiles for all of the routers involved in the two tunnels (inbound and outbound) 
-    through which the request and response passed, as well as the queried peer's 
-    profile. Direct measurement, such as transport layer latency or congestion, 
-    is not used as part of the profile, as it can be manipulated and associated 
-    with the measuring router, exposing them to trivial attacks. While gathering 
-    these profiles, a series of calculations are run on each to summarize its 
-    performance - its latency, capacity to handle lots of activity, whether they 
-    are currently overloaded, and how well integrated into the network they seem 
-    to be. These calculations are then compared for active peers to organize the 
-    routers into four tiers - fast and high capacity, high capacity, not failing, 
-    and failing. The thresholds for those tiers are determined dynamically, and 
-    while they currently use fairly simple algorithms, alternatives exist.
-  
            
-  
             Using this profile data, the simplest reasonable peer selection strategy 
-    is to pick peers randomly from the top tier (fast and high capacity), and 
-    this is currently deployed for client tunnels. Exploratory tunnels (used for 
-    netDb and tunnel management) pick peers randomly from the "not failing" tier 
-    (which includes routers in 'better' tiers as well), allowing the peer to sample 
-    routers more widely, in effect optimizing the peer selection through randomized 
-    hill climbing. These strategies alone do however leak information regarding 
-    the peers in the router's top tier through predecessor and netDb harvesting 
-    attacks. In turn, several alternatives exist which, while not balancing the 
-    load as evenly, will address the attacks mounted by particular classes of 
-    adversaries.
-  
            
-  
            
-    By picking a random key and ordering the peers according to their XOR distance 
-    from it, the information leaked is reduced in predecessor and harvesting attacks 
-    according to the peers' failure rate and the tier's churn. Another simple 
-    strategy for dealing with netDb harvesting attacks is to simply fix the inbound 
-    tunnel gateway(s) yet randomize the peers further on in the tunnels. To deal 
-    with predecessor attacks for adversaries which the client contacts, the outbound 
-    tunnel endpoints would also remain fixed. The selection of which peer to fix 
-    on the most exposed point would of course need to have a limit to the duration, 
-    as all peers fail eventually, so it could either be reactively adjusted or 
-    proactively avoided to mimic a measured mean time between failures of other 
-    routers. These two strategies can in turn be combined, using a fixed exposed 
-    peer and an XOR based ordering within the tunnels themselves. A more rigid 
-    strategy would fix the exact peers and ordering of a potential tunnel, only 
-    using individual peers if all of them agree to participate in the same way 
-    each time. This varies from the XOR based ordering in that the predecessor 
-    and successor of each peer is always the same, while the XOR only makes sure 
-    their order doesn't change.
-  
            
-  
            
-    As mentioned before, I2P currently (release 0.8) includes the tiered 
-    random strategy above, with XOR-based ordering. A 
-    more detailed discussion of the mechanics involved in tunnel operation, management, 
-    and peer selection can be found in the tunnel spec. 
-  
            
-  
            Network Database
            
-  
            
-    As mentioned earlier, I2P's netDb works to share the network's metadata.
-    This is detailed in the networkdatabase page,
-    but a basic explanation is available below.
-  
            
-  
            
-    A percentage of I2P users are appointed as 'floodfill peers'.
-    Currently, I2P installations that have a lot of bandwidth and are fast enough,
-    will appoint themselves as floodfill as soon as the number of existing floodfill routers
-    drops too low.
-  
            
-  
            
-    Other I2P routers will store their data and lookup data by sending simple 'store' and 'lookup' queries to the floodfills.
-    If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers
-    using the Kademlia algorithm.
-    The 'lookup' queries currently function differently, to avoid an important
-    security issue.
-    When a lookup is done, the floodfill router will not forward the lookup to other peers,
-    but will always answer by itself (if it has the requested data).
-  
            
-  
            
-    Two types of information are stored in the network database.
-    
              
-        
            • A routerInfo stores information on a specific I2P router and how to contact it
              • 
-        
            • A leaseSet stores information on a specific destination (e.g. I2P website, e-mail server...)
              • 
-    
            
-    All of this information is signed by the publishing party and verified by any I2P router using or storing the information.
-    In addition, the data contains timing information, to avoid storage of old entries and possible attacks.
-    This is also why I2P bundles the necessary code for maintaining the correct time, occasionally querying some SNTP servers 
-    (the pool.ntp.org round robin by default)
-    and detecting skew between routers at the transport layer.
-  
            
-  
            
-    Some additional remarks are also important.
-    
              
-      
            • 
-        Unpublished and encrypted leasesets:
-        
              
-          One could only want specific people to be able to reach a destination.
-          This is possible by not publishing the destination in the netDb. You will however have to transmit the destination by other means.
-          An alternative are the 'encrypted leaseSets'. These leaseSets can only be decoded by people with access to the decryption key.
-        
              
-      
              • 
-      
            • 
-        Bootstrapping:
-        
              
-          Bootstrapping the netDb is quite simple. Once a router manages to receive a single routerInfo of a reachable peer,
-          it can query that router for references to other routers in the network.
-          Currently, a number of users post their routerInfo files to a website to make this information available.
-          I2P automatically connects to one of these websites to gather routerInfo files and bootstrap.
-        
              
-      
              • 
-      
            • 
-        Lookup scalability:
-        
              
-            Lookups in the I2P network are not forwarded to other netDb routers.
-            Currently, this is not a major problem, since the network is not very large.
-            However, as the network grows, not all routerInfo and leaseSet files will be present
-            on each netDb router. This will cause a deterioration of the percentage of successful lookups.
-            Because of this, refinements to the netDb will be done in the next releases.
-        
              
-      
              • 
-    
            
-  
            
-  
            Transport protocols
            
-  
             Communication between routers needs to provide confidentiality and integrity 
-    against external adversaries while authenticating that the router contacted 
-    is the one who should receive a given message. The particulars of how routers 
-    communicate with other routers aren't critical - three separate protocols 
-    have been used at different points to provide those bare necessities. 
            
-  
             I2P started with a TCP-based protocol which 
-    has since been disabled. Then, to accommodate the need for high degree communication 
-    (as a number of routers will end up speaking with many others), I2P moved 
-    from a TCP based transport to a UDP-based one - "Secure 
-    Semireliable UDP", or "SSU". 
            
-  
             As described in the SSU spec:
            
-  
             The goal of this protocol is to provide secure, authenticated, 
-    semireliable and unordered message delivery, exposing only a minimal amount 
-    of data easily discernible to third parties. It should support high degree 
-    communication as well as TCP-friendly congestion control and may include 
-    PMTU detection. It should be capable of efficiently moving bulk data at rates 
-    sufficient for home users. In addition, it should support techniques for addressing 
-    network obstacles, like most NATs or firewalls. 
            
-  
             Following the introduction of SSU, after issues with congestion collapse 
-    appeared, a new NIO-based TCP transport called NTCP 
-    was implemented. It is enabled by default for outbound connections only. Those 
-    who configure their NAT/firewall to allow inbound connections and specify 
-    the external host and port (dyndns/etc is ok) on /config.jsp can receive inbound 
-    connections. As NTCP is NIO based, so it doesn't suffer from the 1 thread 
-    per connection issues of the old TCP transport. 
            
-  
             I2P supports multiple transports simultaneously. A particular transport 
-    for an outbound connection is selected with "bids". Each transport bids for 
-    the connection and the relative value of these bids assigns the priority. 
-    Transports may reply with different bids, depending on whether there is already 
-    an established connection to the peer. 
            
-  
             The current implementation ranks NTCP as the highest-priority transport 
-    for outbound connections in most situations. SSU is enabled for both outbound 
-    and inbound connections. Your firewall and your I2P router must be configured 
-    to allow inbound NTCP connections. For further information see the NTCP 
-    page. 
            
-  
            Cryptography
            
-  
             A bare minimum set of cryptographic primitives are combined together to 
-    provide I2P's layered defenses against a variety of adversaries. At the lowest 
-    level, inter router communication is protected by the transport layer security 
-    - SSU encrypts each packet with AES256/CBC with both an explicit IV and MAC 
-    (HMAC-MD5-128) after agreeing upon an ephemeral session key through a 2048bit 
-    Diffie-Hellman exchange, station-to-station authentication with the other 
-    router's DSA key, plus each network message has their own hash for local integrity 
-    checking. Tunnel messages passed over the transports 
-    have their own layered AES256/CBC encryption with an explicit IV and verified 
-    at the tunnel endpoint with an additional SHA256 hash. Various other messages 
-    are passed along inside "garlic messages", which are encrypted with ElGamal/AES+SessionTags 
-    (explained below). 
            
-  
            Garlic messages
            
-  
             Garlic messages are an extension of "onion" layered encryption, allowing 
-    the contents of a single message to contain multiple "cloves" - fully formed 
-    messages alongside their own instructions for delivery. Messages are wrapped 
-    into a garlic message whenever the message would otherwise be passing in cleartext 
-    through a peer who should not have access to the information - for instance, 
-    when a router wants to ask another router to participate in a tunnel, they 
-    wrap the request inside a garlic, encrypt that garlic to the receiving router's 
-    2048bit ElGamal public key, and forward it through a tunnel. Another example 
-    is when a client wants to send a message to a destination - the sender's router 
-    will wrap up that data message (alongside some other messages) into a garlic, 
-    encrypt that garlic to the 2048bit ElGamal public key published in the recipient's 
-    leaseSet, and forward it through the appropriate tunnels. 
            
-  
             The "instructions" attached to each clove inside the encryption layer includes 
-    the ability to request that the clove be forwarded locally, to a remote router, 
-    or to a remote tunnel on a remote router. There are fields in those instructions 
-    allowing a peer to request that the delivery be delayed until a certain time 
-    or condition has been met, though they won't be honored until the nontrivial 
-    delays are deployed. It is possible to explicitly route garlic messages 
-    any number of hops without building tunnels, or even to reroute tunnel messages 
-    by wrapping them in garlic messages and forwarding them a number of hops prior 
-    to delivering them to the next hop in the tunnel, but those techniques are 
-    not currently used in the existing implementation. 
            
-  
            Session tags
            
-  
             As an unreliable, unordered, message based system, I2P uses a simple combination 
-    of asymmetric and symmetric encryption algorithms to provide data confidentiality 
-    and integrity to garlic messages. As a whole, the combination is referred 
-    to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe 
-    the simple use of 2048bit ElGamal, AES256, SHA256 and 32 byte nonces. 
            
-  
             The first time a router wants to encrypt a garlic message to another router, 
-    they encrypt the keying material for an AES256 session key with ElGamal and 
-    append the AES256/CBC encrypted payload after that encrypted ElGamal block. 
-    In addition to the encrypted payload, the AES encrypted section contains the 
-    payload length, the SHA256 hash of the unencrypted payload, as well as a number 
-    of "session tags" - random 32 byte nonces. The next time the sender wants 
-    to encrypt a garlic message to another router, rather than ElGamal encrypt 
-    a new session key they simply pick one of the previously delivered session 
-    tags and AES encrypt the payload like before, using the session key used with 
-    that session tag, prepended with the session tag itself. When a router receives 
-    a garlic encrypted message, they check the first 32 bytes to see if it matches 
-    an available session tag - if it does, they simply AES decrypt the message, 
-    but if it does not, they ElGamal decrypt the first block. 
            
-  
             Each session tag can be used only once so as to prevent internal adversaries 
-    from unnecessarily correlating different messages as being between the same 
-    routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses 
-    when and how many tags to deliver, prestocking the recipient with enough tags 
-    to cover a volley of messages. Garlic messages may detect the successful tag 
-    delivery by bundling a small additional message as a clove (a "delivery status 
-    message") - when the garlic message arrives at the intended recipient and 
-    is decrypted successfully, this small delivery status message is one of the 
-    cloves exposed and has instructions for the recipient to send the clove back 
-    to the original sender (through an inbound tunnel, of course). When the original 
-    sender receives this delivery status message, they know that the session tags 
-    bundled in the garlic message were successfully delivered. 
            
-  
             Session tags themselves have a very short lifetime, after which they are 
-    discarded if not used. In addition, the quantity stored for each key is limited, 
-    as are the number of keys themselves - if too many arrive, either new or old 
-    messages may be dropped. The sender keeps track whether messages using session 
-    tags are getting through, and if there isn't sufficient communication it may 
-    drop the ones previously assumed to be properly delivered, reverting back 
-    to the full expensive ElGamal encryption. 
            
-  
             One alternative is to transmit only a single session tag, and from that, 
-    seed a deterministic PRNG for determining what tags to use or expect. By keeping 
-    this PRNG roughly synchronized between the sender and recipient (the recipient 
-    precomputes a window of the next e.g. 50 tags), the overhead of periodically 
-    bundling a large number of tags is removed, allowing more options in the space/time 
-    tradeoff, and perhaps reducing the number of ElGamal encryptions necessary. 
-    However, it would depend upon the strength of the PRNG to provide the necessary 
-    cover against internal adversaries, though perhaps by limiting the amount 
-    of times each PRNG is used, any weaknesses can be minimized. At the moment, 
-    there are no immediate plans to move towards these synchronized PRNGs. 
            
-  
            Future
            
-  
             While I2P is currently functional and sufficient for many scenarios, there 
-    are several areas which require further improvement to meet the needs of those 
-    facing more powerful adversaries as well as substantial user experience optimization. 
-  
            
-  
            Restricted route operation
            
-  
             I2P is an overlay network designed to be run on top of a functional packet 
-    switched network, exploiting the end to end principle to offer anonymity and 
-    security. While the Internet no longer fully embraces the end to end principle
-    (due to the usage of NAT), 
-    I2P does require a substantial portion of the network to be reachable - there 
-    may be a number of peers along the edges running using restricted routes, 
-    but I2P does not include an appropriate routing algorithm for the degenerate 
-    case where most peers are unreachable. It would, however work on top of a 
-    network employing such an algorithm. 
            
-  
             Restricted route operation, where there are limits to what peers are reachable 
-    directly, has several different functional and anonymity implications, dependent 
-    upon how the restricted routes are handled. At the most basic level, restricted 
-    routes exist when a peer is behind a NAT or firewall which does not allow 
-    inbound connections. This was largely addressed in I2P 0.6.0.6 by integrating 
-    distributed hole punching into the transport layer, allowing people behind 
-    most NATs and firewalls to receive unsolicited connections without any configuration. 
-    However, this does not limit the exposure of the peer's IP address to routers 
-    inside the network, as they can simply get introduced to the peer through 
-    the published introducer. 
            
-  
             Beyond the functional handling of restricted routes, there are two levels 
-    of restricted operation that can be used to limit the exposure of one's IP 
-    address - using router-specific tunnels for communication, and offering 'client 
-    routers'. For the former, routers can either build a new pool of tunnels or 
-    reuse their exploratory pool, publishing the inbound gateways to some of them 
-    as part of their routerInfo in place of their transport addresses. When a 
-    peer wants to get in touch with them, they see those tunnel gateways in the 
-    netDb and simply send the relevant message to them through one of the published 
-    tunnels. If the peer behind the restricted route wants to reply, it may do 
-    so either directly (if they are willing to expose their IP to the peer) or 
-    indirectly through their outbound tunnels. When the routers that the peer 
-    has direct connections to want to reach it (to forward tunnel messages, for 
-    instance), they simply prioritize their direct connection over the published 
-    tunnel gateway. The concept of 'client routers' simply extends the restricted 
-    route by not publishing any router addresses. Such a router would not even 
-    need to publish their routerInfo in the netDb, merely providing their self 
-    signed routerInfo to the peers that it contacts (necessary to pass the router's 
-    public keys). Both levels of restricted route operation are planned for I2P 
-    2.0. 
            
-  
             There are tradeoffs for those behind restricted routes, as they would likely 
-    participate in other people's tunnels less frequently, and the routers which 
-    they are connected to would be able to infer traffic patterns that would not 
-    otherwise be exposed. On the other hand, if the cost of that exposure is less 
-    than the cost of an IP being made available, it may be worthwhile. This, of 
-    course, assumes that the peers that the router behind a restricted route contacts 
-    are not hostile - either the network is large enough that the probability 
-    of using a hostile peer to get connected is small enough, or trusted (and 
-    perhaps temporary) peers are used instead. 
            
-  
            Variable latency
            
-  
             Even though the bulk of I2P's initial efforts have been on low latency communication, 
-    it was designed with variable latency services in mind from the beginning. 
-    At the most basic level, applications running on top of I2P can offer the 
-    anonymity of medium and high latency communication while still blending their 
-    traffic patterns in with low latency traffic. Internally though, I2P can offer 
-    its own medium and high latency communication through the garlic encryption 
-    - specifying that the message should be sent after a certain delay, at a certain 
-    time, after a certain number of messages have passed, or another mix strategy. 
-    With the layered encryption, only the router that the clove exposed the delay 
-    request would know that the message requires high latency, allowing the traffic 
-    to blend in further with the low latency traffic. Once the transmission precondition 
-    is met, the router holding on to the clove (which itself would likely be a 
-    garlic message) simply forwards it as requested - to a router, to a tunnel, 
-    or, most likely, to a remote client destination. 
            
-  
             There are a substantial number of ways to exploit this capacity for high 
-    latency comm in I2P, but for the moment, doing so has been scheduled for the 
-    I2P 3.0 release. In the meantime, those requiring the anonymity that high 
-    latency comm can offer should look towards the application layer to provide 
-    it. 
            
-  
            Open questions
            
-  
            -How to get rid of the timing constraint?
-Can we deal with the sessionTags more efficiently?
-What, if any, batching/mixing strategies should be made available on the tunnels?
-What other tunnel peer selection and ordering strategies should be available?
-
            
-  
            Similar systems
            
-  
             I2P's architecture builds on the concepts of message oriented middleware, 
-    the topology of DHTs, the anonymity and cryptography of free route mixnets, 
-    and the adaptability of packet switched networking. The value comes not from 
-    novel concepts of algorithms though, but from careful engineering combining 
-    the research results of existing systems and papers. While there are a few 
-    similar efforts worth reviewing, both for technical and functional comparisons, 
-    two in particular are pulled out here - Tor and Freenet. 
            
-  
             See also the Network Comparisons Page. 
-  
            
-
-  
            Tor
            
-  
            website
            
-  
             At first glance, Tor and I2P have many functional and anonymity related 
-    similarities. While I2P's development began before we were aware of the early 
-    stage efforts on Tor, many of the lessons of the original onion routing and 
-    ZKS efforts were integrated into I2P's design. Rather than building an essentially 
-    trusted, centralized system with directory servers, I2P has a self organizing 
-    network database with each peer taking on the responsibility of profiling 
-    other routers to determine how best to exploit available resources. Another 
-    key difference is that while both I2P and Tor use layered and ordered paths 
-    (tunnels and circuits/streams), I2P is fundamentally a packet switched network, 
-    while Tor is fundamentally a circuit switched one, allowing I2P to transparently 
-    route around congestion or other network failures, operate redundant pathways, 
-    and load balance the data across available resources. While Tor offers the 
-    useful outproxy functionality by offering integrated outproxy discovery and 
-    selection, I2P leaves such application layer decisions up to applications 
-    running on top of I2P - in fact, I2P has even externalized the TCP-like streaming 
-    library itself to the application layer, allowing developers to experiment 
-    with different strategies, exploiting their domain specific knowledge to offer 
-    better performance. 
            
-  
             From an anonymity perspective, there is much similarity when the core networks 
-    are compared. However, there are a few key differences. When dealing with 
-    an internal adversary or most external adversaries, I2P's simplex tunnels 
-    expose half as much traffic data than would be exposed with Tor's duplex circuits 
-    by simply looking at the flows themselves - an HTTP request and response would 
-    follow the same path in Tor, while in I2P the packets making up the request 
-    would go out through one or more outbound tunnels and the packets making up 
-    the response would come back through one or more different inbound tunnels. 
-    While I2P's peer selection and ordering strategies should sufficiently address 
-    predecessor attacks, should a switch to bidirectional tunnels be necessary,
-    we could simply build an inbound and outbound tunnel along the same routers.
            
-  
             Another anonymity issue comes up in Tor's use of telescopic tunnel creation, 
-    as simple packet counting and timing measurements as the cells in a circuit 
-    pass through an adversary's node exposes statistical information regarding 
-    where the adversary is within the circuit. I2P's unidirectional tunnel creation 
-    with a single message so that this data is not exposed. Protecting the position 
-    in a tunnel is important, as an adversary would otherwise be able to mount 
-    a series of powerful predecessor, intersection, and traffic confirmation attacks. 
-  
            
-  
             Tor's support for a second tier of "onion proxies" does offer a non-trivial 
-    degree of anonymity while requiring a low cost of entry, while I2P will not 
-    offer this topology until 2.0. 
            
-  
             On the whole, Tor and I2P complement each other in their focus - Tor works 
-    towards offering high speed anonymous Internet outproxying, while I2P works 
-    towards offering a decentralized resilient network in itself. In theory, both 
-    can be used to achieve both purposes, but given limited development resources, 
-    they both have their strengths and weaknesses. The I2P developers have considered 
-    the steps necessary to modify Tor to take advantage of I2P's design, but concerns 
-    of Tor's viability under resource scarcity suggest that I2P's packet switching 
-    architecture will be able to exploit scarce resources more effectively. 
            
-
-  
            Freenet
            
-  
            website
            
-  
             Freenet played a large part in the initial stages of I2P's design - giving 
-    proof to the viability of a vibrant pseudonymous community completely contained 
-    within the network, demonstrating that the dangers inherent in outproxies 
-    could be avoided. The first seed of I2P began as a replacement communication 
-    layer for Freenet, attempting to factor out the complexities of a scalable, 
-    anonymous and secure point to point communication from the complexities of 
-    a censorship resistant distributed data store. Over time however, some of 
-    the anonymity and scalability issues inherent in Freenet's algorithms made 
-    it clear that I2P's focus should stay strictly on providing a generic anonymous 
-    communication layer, rather than as a component of Freenet. Over the years, 
-    the Freenet developers have come to see the weaknesses in the older design, 
-    prompting them to suggest that they will require a "premix" layer to offer 
-    substantial anonymity. In other words, Freenet needs to run on top of a mixnet 
-    such as I2P or Tor, with "client nodes" requesting and publishing data through 
-    the mixnet to the "server nodes" which then fetch and store the data according 
-    to Freenet's heuristic distributed data storage algorithms. 
            
-  
             Freenet's functionality is very complementary to I2P's, as Freenet natively 
-    provides many of the tools for operating medium and high latency systems, 
-    while I2P natively provides the low latency mix network suitable for offering 
-    adequate anonymity. The logic of separating the mixnet from the censorship-
-    resistant distributed data store still seems self-evident from an engineering, 
-    anonymity, security, and resource allocation perspective, so hopefully the 
-    Freenet team will pursue efforts in that direction, if not simply reusing 
-    (or helping to improve, as necessary) existing mixnets like I2P or Tor. 
            
-  
             It is worth mentioning that there has recently been discussion and work 
-    by the Freenet developers on a "globally scalable darknet" using restricted 
-    routes between peers of various trust. While insufficient information has 
-    been made publicly available regarding how such a system would operate for 
-    a full review, from what has been said the anonymity and scalability claims 
-    seem highly dubious. In particular, the appropriateness for use in hostile 
-    regimes against state level adversaries has been tremendously overstated, 
-    and any analysis on the implications of resource scarcity upon the scalability 
-    of the network has seemingly been avoided. Further questions regarding susceptibility 
-    to traffic analysis, trust and other topics do exist, but a more in-depth 
-    review of this "globally scalable darknet" will have to wait until the Freenet 
-    team makes more information available. 
            
-
-  
            Appendix A: Application layer
            
-
-  
            
-    I2P itself doesn't really do much - it simply sends messages to remote destinations 
-    and receives messages targeting local destinations - most of the interesting 
-    work goes on at the layers above it. By itself, I2P could be seen as an anonymous 
-    and secure IP layer, and the bundled streaming library 
-    as an implementation of an anonymous and secure TCP layer on top of it. Beyond 
-    that, I2PTunnel exposes a generic TCP proxying 
-    system for either getting into or out of the I2P network, plus a variety of 
-    network applications provide further functionality for end users.
-  
            
-
-  
            Streaming library
            
-  
            
-    The I2P streaming library can be viewed as a generic streaming interface (mirroring TCP sockets),
-    and the implementation supports a sliding window protocol
-    with several optimizations, to take into account the high delay over I2P.
-    Individual streams may adjust the maximum packet size and 
-    other options, though the default of 4KB compressed seems a reasonable tradeoff 
-    between the bandwidth costs of retransmitting lost messages and the latency 
-    of multiple messages.
-  
            
-  
            
-    In addition, in consideration of the relatively high cost of subsequent 
-    messages, the streaming library's protocol for scheduling and delivering messages 
-    has been optimized to allow individual messages passed to contain as much 
-    information as is available. For instance, a small HTTP transaction proxied 
-    through the streaming library can be completed in a single round trip - the 
-    first message bundles a SYN, FIN and the small payload (an HTTP request typically 
-    fits) and the reply bundles the SYN, FIN, ACK and the small payload (many 
-    HTTP responses fit). While an additional ACK must be transmitted to tell the 
-    HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy can 
-    deliver the full response to the browser immediately.
-  
            
-  
            
-    On the whole, however, the streaming library bears much resemblance to an 
-    abstraction of TCP, with its sliding windows, congestion control algorithms 
-    (both slow start and congestion avoidance), and general packet behavior (ACK, 
-    SYN, FIN, RST, etc).
-  
            
-
-  
            Naming library and addressbook
            
-  
             For more information see the Naming and Addressbook 
-    page.
            
-  
            Developed by: mihi, Ragnarok
            
-  
             Naming within I2P has been an oft-debated topic since the very beginning 
-    with advocates across the spectrum of possibilities. However, given I2P's 
-    inherent demand for secure communication and decentralized operation, the 
-    traditional DNS-style naming system is clearly out, as are "majority rules" 
-    voting systems. Instead, I2P ships with a generic naming library and a base 
-    implementation designed to work off a local name to destination mapping, as 
-    well as an optional add-on application called the "addressbook". The addressbook 
-    is a web-of-trust-driven secure, distributed, and human readable naming system, 
-    sacrificing only the call for all human readable names to be globally unique 
-    by mandating only local uniqueness. While all messages in I2P are cryptographically 
-    addressed by their destination, different people can have local addressbook 
-    entries for "Alice" which refer to different destinations. People can still 
-    discover new names by importing published addressbooks of peers specified 
-    in their web of trust, by adding in the entries provided through a third party, 
-    or (if some people organize a series of published addressbooks using a first 
-    come first serve registration system) people can choose to treat these addressbooks 
-    as name servers, emulating traditional DNS. 
            
-  
             I2P does not promote the use of DNS-like services though, as the damage 
-    done by hijacking a site can be tremendous - and insecure destinations have 
-    no value. DNSsec itself still falls back on registrars and certificate authorities, 
-    while with I2P, requests sent to a destination cannot be intercepted or the 
-    reply spoofed, as they are encrypted to the destination's public keys, and 
-    a destination itself is just a pair of public keys and a certificate. DNS-style 
-    systems on the other hand allow any of the name servers on the lookup path 
-    to mount simple denial of service and spoofing attacks. Adding on a certificate 
-    authenticating the responses as signed by some centralized certificate authority 
-    would address many of the hostile nameserver issues but would leave open replay 
-    attacks as well as hostile certificate authority attacks. 
            
-  
             Voting style naming is dangerous as well, especially given the effectiveness 
-    of Sybil attacks in anonymous systems - the attacker can simply create an 
-    arbitrarily high number of peers and "vote" with each to take over a given 
-    name. Proof-of-work methods can be used to make identity non-free, but as 
-    the network grows the load required to contact everyone to conduct online 
-    voting is implausible, or if the full network is not queried, different sets 
-    of answers may be reachable. 
            
-  
             As with the Internet however, I2P is keeping the design and operation of 
-    a naming system out of the (IP-like) communication layer. The bundled naming 
-    library includes a simple service provider interface which alternate naming 
-    systems can plug into, allowing end users to drive what sort of naming tradeoffs 
-    they prefer. 
            
-
-  
            Syndie
            
-  
             The old Syndie bundled with I2P has been replaced by the new Syndie which 
-    is distributed separately. For more information see the Syndie 
-    pages.
            
-  
             Syndie is a safe, anonymous blogging / content publication / content aggregation 
-    system. It lets you create information, share it with others, and read posts 
-    from those you're interested in, all while taking into consideration your 
-    needs for security and anonymity. Rather than building its own content distribution 
-    network, Syndie is designed to run on top of existing networks, syndicating 
-    content through eepsites, Tor hidden services, Freenet freesites, normal websites, 
-    usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie 
-    is done so as to offer pseudonymous authentication to anyone reading or archiving 
-    it. 
            
-
-  
            I2PTunnel
            
-  
            Developed by: mihi
            
-  
             I2PTunnel is probably I2P's most popular and versatile client application, 
-    allowing generic proxying both into and out of the I2P network. I2PTunnel 
-    can be viewed as four separate proxying applications - a "client" which receives 
-    inbound TCP connections and forwards them to a given I2P destination, an "httpclient" 
-    (aka "eepproxy") which acts like an HTTP proxy and forwards the requests to 
-    the appropriate I2P destination (after querying the naming service if necessary), 
-    a "server" which receives inbound I2P streaming connections on a destination 
-    and forwards them to a given TCP host+port, and an "httpserver" which extends 
-    the "server" by parsing the HTTP request and responses to allow safer operation. 
-    There is an additional "socksclient" application, but its use is not encouraged 
-    for reasons previously mentioned. 
            
-  
             I2P itself is not an outproxy network - the anonymity and security concerns 
-    inherent in a mix net which forwards data into and out of the mix have kept 
-    I2P's design focused on providing an anonymous network which capable of meeting 
-    the user's needs without requiring external resources. However, the I2PTunnel 
-    "httpclient" application offers a hook for outproxying - if the hostname requested 
-    doesn't end in ".i2p", it picks a random destination from a user-provided 
-    set of outproxies and forwards the request to them. These destinations are 
-    simply I2PTunnel "server" instances run by volunteers who have explicitly 
-    chosen to run outproxies - no one is an outproxy by default, and running an 
-    outproxy doesn't automatically tell other people to proxy through you. While 
-    outproxies do have inherent weaknesses, they offer a simple proof of concept 
-    for using I2P and provide some functionality under a threat model which may 
-    be sufficient for some users. 
            
-  
             I2PTunnel enables most of the applications in use. An "httpserver" pointing 
-    at a webserver lets anyone run their own anonymous website (or "eepsite") 
-    - a webserver is bundled with I2P for this purpose, but any webserver can 
-    be used. Anyone may run a "client" pointing at one of the anonymously hosted 
-    IRC servers, each of which are running a "server" pointing at their local 
-    IRCd and communicating between IRCds over their own "client" tunnels. End 
-    users also have "client" tunnels pointing at I2Pmail's 
-    POP3 and SMTP destinations (which in turn are simply "server" instances pointing 
-    at POP3 and SMTP servers), as well as "client" tunnels pointing at I2P's CVS 
-    server, allowing anonymous development. At times people have even run "client" 
-    proxies to access the "server" instances pointing at an NNTP server. 
            
-
-  
            i2p-bt
            
-  
            Developed by: duck, et al
            
-  
             i2p-bt is a port of the mainline python BitTorrent client to run both the 
-    tracker and peer communication over I2P. Tracker requests are forwarded through 
-    the eepproxy to eepsites specified in the torrent file while tracker responses 
-    refer to peers by their destination explicitly, allowing i2p-bt to open up 
-    a streaming lib connection to query them for 
-    blocks. 
            
-  
             In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making 
-    a few modifications as necessary to strip any anonymity-compromising information 
-    from the application and to take into consideration the fact that IPs cannot 
-    be used for identifying peers. 
            
-
-  
            I2PSnark
            
-  
            I2PSnark developed: jrandom, et al, ported from mjw's Snark client
            
-  
             Bundled with the I2P install, I2PSnark offers a simple anonymous BitTorrent 
-    client with multitorrent capabilities, exposing all of the functionality through 
-    a plain HTML web interface. 
            
-
-  
            Robert
            
-  
            Developed by: sponge
            
-  
            Robert is a Bittorrent client written in Python.
-    It is hosted on http://bob.i2p/Robert.html
             
-
-  
            PyBit
            
-  
            Developed by: Blub
            
-  
            PyBit is a Bittorrent client written in Python.
-    It is hosted on http://pebcache.i2p/
             
-
-  
            I2Phex
            
-  
            Developed by: sirup
            
-  
             I2Phex is a fairly direct port of the Phex Gnutella filesharing client to 
-    run entirely on top of I2P. While it has disabled some of Phex's functionality, 
-    such as integration with Gnutella webcaches, the basic file sharing and chatting 
-    system is fully functional. 
            
-
            iMule
            
-  
            Developed by: mkvore
            
-  
             iMule is a fairly direct port of the aMule filesharing client 
-    running entirely inside I2P.
            
-  
            I2Pmail/susimail
            
-  
            Developed by: postman, susi23, mastiejaner
            
-  
             I2Pmail is more a service than an application - postman offers both internal 
-    and external email with POP3 and SMTP service through I2PTunnel instances 
-    accessing a series of components developed with mastiejaner, allowing people 
-    to use their preferred mail clients to send and receive mail pseudonymously. 
-    However, as most mail clients expose substantial identifying information, 
-    I2P bundles susi23's web based susimail client which has been built specifically 
-    with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers transparent 
-    virus filtering as well as denial of service prevention with hashcash augmented 
-    quotas. In addition, each user has control of their batching strategy prior 
-    to delivery through the mail.i2p outproxies, which are separate from the mail.i2p 
-    SMTP and POP3 servers - both the outproxies and inproxies communicate with 
-    the mail.i2p SMTP and POP3 servers through I2P itself, so compromising those 
-    non-anonymous locations does not give access to the mail accounts or activity 
-    patterns of the user. At the moment the developers work on a decentralized 
-    mailsystem, called "v2mail". More information can be found on the eepsite 
-    hq.postman.i2p.
            
-
-  
            I2P-Bote
            
-  
            Developed by: HungryHobo
            
-  
            
-    I2P-Bote is a distributed e-mail application. It does not use the traditional
-    e-mail concept of sending an e-mail to a server and retrieving it from a server.
-    Instead, it uses a Kademlia Distributed Hash Table to store mails.
-    One user can push a mail into the DHT, while another can request the e-mail from the DHT.
-    And all the mails sent within the I2P-Bote network are automatically encrypted end-to-end. 
            
-    Furthermore, I2P-Bote offers a remailer function on top of I2P, for increased high-latency anonymity.
-  
            
-
-  
            I2P-Messenger
            
-  
            
-    I2P-Messenger is an end-to-end encrypted serverless communication application.
-    For communication between two users, they need to give each other their destination keys, to allow the other to connect.
-    It supports file transfer and has a search for other users, based on Seedless.
-  
            
-{% endblock %}
diff --git a/www.i2p2/pages/todo.html b/www.i2p2/pages/todo.html
deleted file mode 100644
index a702dfeb..00000000
--- a/www.i2p2/pages/todo.html
+++ /dev/null
@@ -1,349 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}To Do List{% endblock %}
-{% block content %}
-  
            I2P Project Targets
            
-  
            Below is a more detailed (yet still incomplete) discussion of the major areas 
-    of future development on the core I2P network, spanning the plausibly planned 
-    releases. This does not include stego transports, porting to wireless devices, 
-    or tools to secure the local machine, nor does it include client applications 
-    that will be essential in I2P's success. There are probably other things that 
-    will come up, especially as I2P gets more peer review, but these are the main 
-    'big things'. See also the roadmap. Want to help? 
-    Get involved! 
            
-  
            
-  
            Core functionality [link]
            
-  
-  
            Security / anonymity [link]
            
-  
-  
            Performance [link]
            
-  
            Core functionality
            
-  
              
-    
            •  
-      
              NAT/Firewall bridging via 1-hop restricted routes
              
-    
              • 
-    
-    Implemented in I2P 0.6.0.6 
-    
              The functionality of allowing routers to fully participate within the network 
-      while behind firewalls and NATs that they do not control requires some basic 
-      restricted route operation (since those peers will not be able to receive 
-      inbound connections). To do this successfully, you consider peers one of 
-      two ways:
              
-      
-  
            
-  
              
-    
            • Peers who have reachable interfaces - these peers do not need to 
-      do anything special
              • 
-    
            • Peers who do not have reachable interfaces - these peers must build 
-      a tunnel pointing at them where the gateway is one of the peers they have 
-      established a connection with who has both a publicly reachable interface 
-      and who has agreed to serve as their 'introducer'.
              • 
-  
            
-  
            
-    
            To do this, peers who have no IP address simply connect to a few peers, 
-      build a tunnel through them, and publish a reference to those tunnels within 
-      their RouterInfo structure in the network database.
            
-    
            When someone wants to contact any particular router, they first must get 
-      its RouterInfo from the network database, which will tell them whether they 
-      can connect directly (e.g. the peer has a publicly reachable interface) 
-      or whether they need to contact them indirectly. Direct connections occur 
-      as normal, while indirect connections are done through one of the published 
-      tunnels.
            
-    
            When a router just wants to get a message or two to a specific hidden peer, 
-      they can just use the indirect tunnel for sending the payload. However, 
-      if the router wants to talk to the hidden peer often (for instance, as part 
-      of a tunnel), they will send a garlic routed message through the indirect 
-      tunnel to that hidden peer which unwraps to contain a message which should 
-      be sent to the originating router. That hidden peer then establishes an 
-      outbound connection to the originating router and from then on, those two 
-      routers can talk to each other directly over that newly established direct 
-      connection.
            
-    
            Of course, that only works if the originating peer can receive connections 
-      (they aren't also hidden). However, if the originating peer is hidden, they 
-      can simply direct the garlic routed message to come back to the originating 
-      peer's inbound tunnel.
            
-    
            This is not meant to provide a way for a peer's IP address to be concealed, 
-      merely as a way to let people behind firewalls and NATs fully operate within 
-      the network. Concealing the peer's IP address adds a little more work, as 
-      described below.
            
-    
            With this technique, any router can participate as any part of a tunnel. 
-      For efficiency purposes, a hidden peer would be a bad choice for an inbound 
-      gateway, and within any given tunnel, two neighboring peers wouldn't want 
-      to be hidden. But that is not technically necessary.
            
-  
            
-  
              
-    
            •  
-      
              High degree transport layer with UDP, NBIO, or NIO
              
-      Both UDP and NIO have been Implemented in I2P 
-      
              Standard TCP communication in Java generally requires blocking socket 
-        calls, and to keep a blocked socket from hanging the entire system, those 
-        blocking calls are done on their own threads. Our current TCP transport 
-        is implemented in a naive fashion - for each peer we are talking to, we 
-        have one thread reading and one thread writing. The reader thread simply 
-        loops a bunch of read() calls, building I2NP messages and adding them 
-        to our internal inbound message queue, and the writer thread pulls messages 
-        off a per-connection outbound message queue and shoves the data through 
-        write() calls.
              
-      
              We do this fairly efficiently, from a CPU perspective - at any time, 
-        almost all of these threads are sitting idle, blocked waiting for something 
-        to do. However, each thread consumes real resources (on older Linux kernels, 
-        for instance, each thread would often be implemented as a fork()'ed process). 
-        As the network grows, the number of peers each router will want to talk 
-        with will increase (remember, I2P is fully connected, meaning that any 
-        given peer should know how to get a message to any other peer, and restricted 
-        route support will probably not significantly reduce the number of connections 
-        necessary). This means that with a 100,000 router network, each router 
-        will have up to 199,998 threads just to deal with the TCP connections!
              
-      
              Obviously, that just won't work. We need to use a transport layer that 
-        can scale. In Java, we have two main camps:
              
-      
              UDP
              
-      Implemented in I2P 0.6 ("SSU") as documented elsewhere 
-      
              Sending and receiving UDP datagrams is a connectionless operation - if 
-        we are communicating with 100,000 peers, we simply stick the UDP packets 
-        in a queue and have a single thread pulling them off the queue and shoving 
-        them out the pipe (and to receive, have a single thread pulling in any 
-        UDP packets received and adding them to an inbound queue).
              
-      
              However, moving to UDP means losing the benefits of TCP's ordering, congestion 
-        control, MTU discovery, etc. Implementing that code will take significant 
-        work, however I2P doesn't need it to be as strong as TCP. Specifically, 
-        a while ago I was taking some measurements in the simulator and on the 
-        live net, and the vast majority of messages transferred would fit easily 
-        within a single unfragmented UDP packet, and the largest of the messages 
-        would fit within 20-30 packets. As mule pointed out, TCP adds a significant 
-        overhead when dealing with so many small packets, as the ACKs are within 
-        an order of magnitude in size. With UDP, we can optimize the transport 
-        for both efficiency and resilience by taking into account I2P's particular 
-        needs.
              
-      
              It will be a lot of work though.
              
-      
              NIO or NBIO
              
-      NIO Implemented in I2P 0.6.1.22 ("NTCP") 
-      
              In Java 1.4, a set of "New I/O" packages was introduced, allowing Java 
-        developers to take advantage of the operating system's nonblocking IO 
-        capabilities - allowing you to maintain a large number of concurrent IO 
-        operations without requiring a separate thread for each. There is much 
-        promise with this approach, as we can scalable handle a large number of 
-        concurrent connections and we don't have to write a mini-TCP stack with 
-        UDP. However, the NIO packages have not proven themselves to be battle-ready, 
-        as the Freenet developer's found. In addition, requiring NIO support would 
-        mean we can't run on any of the open source JVMs like Kaffe, 
-        as GNU/Classpath has only limited 
-        support for NIO. (note: this may not be the case anymore, as there 
-        has been some progress on Classpath's NIO, but it is an unknown quantity)
              
-      
              Another alternative along the same lines is the Non 
-        Blocking I/O package - essentially a cleanroom NIO implementation 
-        (written before NIO was around). It works by using some native OS code 
-        to do the nonblocking IO, passing off events through Java. It seems to 
-        be working with Kaffe, though there doesn't seem to be much development 
-        activity on it lately (likely due to 1.4's NIO deployment).
              
-    
              • 
-  
            
-  
              
-    
            •  
-      
              NetworkDB and profile tuning and ejection policy for large 
-        nets
              
-      
              Within the current network database and profile management implementation, 
-        we have taken the liberty of some practical shortcuts. For instance, we 
-        don't have the code to drop peer references from the K-buckets, as we 
-        don't have enough peers to even plausibly fill any of them, so instead, 
-        we just keep the peers in whatever bucket is appropriate. Another example 
-        deals with the peer profiles - the memory required to maintain each peer's 
-        profile is small enough that we can keep thousands of full blown profiles 
-        in memory without problems. While we have the capacity to use trimmed 
-        down profiles (which we can maintain 100s of thousands in memory), we 
-        don't have any code to deal with moving a profile from a "minimal profile" 
-        to a "full profile", a "full profile" to a "minimal profile", or to simply 
-        eject a profile altogether. It just wouldn't be practical to write that 
-        code yet, since we aren't going to need it for a while.
              
-      
              That said, as the network grows we are going to want to keep these considerations 
-        in mind. We will have some work to do, but we can put it off for later.
              
-    
              • 
-  
            
-  
            Security / anonymity
            
-  
              
-    
            •  
-      
              Per-hop tunnel id & new permuted TunnelVerificationStructure 
-        encryption
              
-      Addressed in I2P 0.5 as documented elsewhere 
-      
              Right now, if Alice builds a four hop inbound tunnel starting at Elvis, 
-        going to Dave, then to Charlie, then Bob, and finally Alice (A<--B<--C<--D<--E), 
-        all five of them will know they are participating in tunnel "123", as 
-        the messages are tagged as such. What we want to do is give each hop their 
-        own unique tunnel hop ID - Charlie will receive messages on tunnel 234 
-        and forward them to tunnel 876 on Bob. The intent is to prevent Bob or 
-        Charlie from knowing that they are in Alice's tunnel, as if each hop in 
-        the tunnel had the same tunnel ID, collusion attacks aren't much work. 
-      
              
-      
              Adding a unique tunnel ID per hop isn't hard, but by itself, insufficient. 
-        If Dave and Bob are under the control of the same attacker, they wouldn't 
-        be able to tell they are in the same tunnel due to the tunnel ID, but 
-        would be able to tell by the message bodies and verification structures 
-        by simply comparing them. To prevent that, the tunnel must use layered 
-        encryption along the path, both on the payload of the tunneled message 
-        and on the verification structure (used to prevent simple tagging attacks). 
-        This requires some simple modifications to the TunnelMessage, as well 
-        as the inclusion of per-hop secret keys delivered during tunnel creation 
-        and given to the tunnel's gateway. We must fix a maximum tunnel length 
-        (e.g. 16 hops) and instruct the gateway to encrypt the message to each 
-        of the 16 delivered secret keys, in reverse order, and to encrypt the 
-        signature of the hash of the (encrypted) payload at each step. The gateway 
-        then sends that 16-step encrypted message, along with a 16-step and 16-wide 
-        encrypted mapping to the first hop, which then decrypts the mapping and 
-        the payload with their secret key, looking in the 16-wide mapping for 
-        the entry associated with their own hop (keyed by the per-hop tunnel ID) 
-        and verifying the payload by checking it against the associated signed 
-        hash.
              
-      
              The tunnel gateway does still have more information than the other peers 
-        in the tunnel, and compromising both the gateway and a tunnel participant 
-        would allow those peers to collude, exposing the fact that they are both 
-        in the same tunnel. In addition, neighboring peers know that they are 
-        in the same tunnel anyway, as they know who they send the message to (and 
-        with IP-based transports without restricted routes, they know who they 
-        got it from). However, the above two techniques significantly increase 
-        the cost of gaining meaningful samples when dealing with longer tunnels.
              
-    
            
-    
              
-      
            •  
-        
              Strict ordering of participants within tunnels
              
-        Implemented in release 0.6.2
              • 
-    
            
-    
            
-      
            As Connelly proposed 
-        to deal with the predecessor 
-        attack (2008 
-        update), keeping the order of peers within our tunnels consistent 
-        (aka whenever Alice creates a tunnel with both Bob and Charlie in it, 
-        Bob's next hop is always Charlie), we address the issue as Bob doesn't 
-        get to substantially sample Alice's peer selection group. We may even 
-        want to explicitly allow Bob to participate in Alice's tunnels in only 
-        one way - receiving a message from Dave and sending it to Charlie - and 
-        if any of those peers are not available to participate in the tunnel (due 
-        to overload, network disconnection, etc), avoid asking Bob to participate 
-        in any tunnels until they are back online.
            
-      
            More analysis is necessary for revising the tunnel creation - at the 
-        moment, we simply select and order randomly within the peer's top tier 
-        of peers (ones with fast + high capacity).
            
-      
            Adding a strict ordering to peers in a tunnel also improves the anonymity 
-        of peers with 0-hop tunnels, as otherwise the fact that a peer's gateway 
-        is always the same would be particularly damning. However, peers with 
-        0-hop tunnels may want to periodically use a 1-hop tunnel to simulate 
-        the failure of a normally reliable gateway peer (so every MTBF*(tunnel 
-        duration) minutes, use a 1-hop tunnel).
            
-    
            
-    
            •  
-      
              Randomly permuted tunnel lengths
              
-      Addressed in I2P 0.5 as documented elsewhere
              • 
-  
            
-  
              
-    
-    
              Without tunnel length permutation, if someone were to somehow detect that 
-      a destination had a particular number of hops, it might be able to use that 
-      information to identify the router the destination is located on, per the 
-      predecessor attack. For instance, if everyone has 2-hop tunnels, if Bob 
-      receives a tunnel message from Charlie and forwards it to Alice, Bob knows 
-      Alice is the final router in the tunnel. If Bob were to identify what destination 
-      that tunnel served (by means of colluding with the gateway and harvesting 
-      the network database for all of the LeaseSets), he would know the router 
-      on which that destination is located (and without restricted routes, that 
-      would mean what IP address the destination is on).
              
-    
              It is to counter user behavior that tunnel lengths should be permuted, 
-      using algorithms based on the length requested (for example, the 1/MTBF 
-      length change for 0-hop tunnels outlined above).
              
-      
-    
            •  
-      
              Full blown n-hop restricted routes with optional 
-        trusted links
              
-      
              The restricted route functionality described before was simply a functional 
-        issue - how to let peers who would not otherwise be able to communicate 
-        do so. However, the concept of allowing restricted routes includes additional 
-        capabilities. For instance, if a router absolutely cannot risk communicating 
-        directly with any untrusted peers, they can set up trusted links through 
-        those peers, using them to both send and receive all of its messages. 
-        Those hidden peers who want to be completely isolated would also refuse 
-        to connect to peers who attempt to get them to (as demonstrated by the 
-        garlic routing technique outlined before) - they can simply take the garlic 
-        clove that has a request for delivery to a particular peer and tunnel 
-        route that message out one of the hidden peer's trusted links with instructions 
-        to forward it as requested.
              
-    
              • 
-    
            •  
-      
              Hashcash for routerIdentity, destination, and tunnel request
              
-      
              Within the network, we will want some way to deter people from consuming 
-        too many resources or from creating so many peers to mount a Sybil 
-        attack. Traditional techniques such as having a peer see who is requesting 
-        a resource or running a peer aren't appropriate for use within I2P, as 
-        doing so would compromise the anonymity of the system. Instead, we want 
-        to make certain requests "expensive".
              
-      
              Hashcash is one technique that 
-        we can use to anonymously increase the "cost" of doing certain activities, 
-        such as creating a new router identity (done only once on installation), 
-        creating a new destination (done only once when creating a service), or 
-        requesting that a peer participate in a tunnel (done often, perhaps 2-300 
-        times per hour). We don't know the "correct" cost of each type of certificate 
-        yet, but with some research and experimentation, we could set a base level 
-        that is sufficiently expensive while not an excessive burden for people 
-        with few resources.
              
-      
              There are a few other algorithms that we can explore for making those 
-        requests for resources "nonfree", and further research on that front is 
-        appropriate.
              
-    
              • 
-    
            •  
-      
              Advanced tunnel operation (batching/mixing/throttling/padding)
              
-      
              To powerful passive external observers as well as large colluding internal 
-        observers, standard tunnel routing is vulnerable to traffic analysis attacks 
-        - simply watching the size and frequency of messages being passed between 
-        routers. To defend against these, we will want to essentially turn some 
-        of the tunnels into its own mix cascade - delaying messages received at 
-        the gateway and passing them in batches, reordering them as necessary, 
-        and injecting dummy messages (indistinguishable from other "real" tunnel 
-        messages by peers in the path). There has been a significant amount of 
-        research 
-        on these algorithms that we can lean on prior to implementing the various 
-        tunnel mixing strategies.
              
-      
              In addition to the anonymity aspects of more varied tunnel operation, 
-        there is a functional dimension as well. Each peer only has a certain 
-        amount of data they can route for the network, and to keep any particular 
-        tunnel from consuming an unreasonable portion of that bandwidth, they 
-        will want to include some throttles on the tunnel. For instance, a tunnel 
-        may be configured to throttle itself after passing 600 messages (1 per 
-        second), 2.4MB (4KBps), or exceeding some moving average (8KBps for the 
-        last minute). Excess messages may be delayed or summarily dropped. With 
-        this sort of throttling, peers can provide ATM-like QoS support for their 
-        tunnels, refusing to agree to allocate more bandwidth than the peer has 
-        available.
              
-      
              In addition, we may want to implement code to dynamically reroute tunnels 
-        to avoid failed peers or to inject additional hops into the path. This 
-        can be done by garlic routing a message to any particular peer in a tunnel 
-        with instructions to redefine the next-hop in the tunnel.
              
-    
              • 
-    
            •  
-      
              Stop & go mix w/ garlics & tunnels
              
-      
              Beyond the per-tunnel batching and mixing strategy, there are further 
-        capabilities for protecting against powerful attackers, such as allowing 
-        each step in a garlic routed path to define a delay or window in which 
-        it should be forwarded on. This would enable protections against the long 
-        term intersection attack, as a peer could send a message that looks perfectly 
-        standard to most peers that pass it along, except at any peers where the 
-        clove exposed includes delay instructions.
              
-    
              • 
-  
            
-  
            Performance
            
-  
            
-  Performance related improvements are listed on the
-  Performance page.
-  
            
-{% endblock %}
diff --git a/www.i2p2/pages/transition-guide.html b/www.i2p2/pages/transition-guide.html
deleted file mode 100644
index 0f10d1c8..00000000
--- a/www.i2p2/pages/transition-guide.html
+++ /dev/null
@@ -1,27 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Monotone{% endblock %}
-{% block content %}
            The I2P sourcecode is kept in several distributed monotone repositories.
-See the
-Monotone website for information
-on monotone.
-See
-this forum post on i2p monotone
-for more information on how to get started and check out the source anonymously.
-There is also a quick-start guide on the
-new developer's page.
-
            
-
-
            
-If you want to get the source non-anonymously, pull from the public server mtn.welterde.de.
-The i2p source code branch is "i2p.i2p".
-
            
-
-
            Guide
            
-
            
-The following is a detailed guide by Complication.
-
            
-
            -  {% include "transition-guide.txt" %}
-
            
-
-{% endblock %}
diff --git a/www.i2p2/pages/_layout_ar.html b/www.i2p2/pages/translations/_layout_ar.html
similarity index 100%
rename from www.i2p2/pages/_layout_ar.html
rename to www.i2p2/pages/translations/_layout_ar.html
diff --git a/www.i2p2/pages/_layout_cs.html b/www.i2p2/pages/translations/_layout_cs.html
similarity index 100%
rename from www.i2p2/pages/_layout_cs.html
rename to www.i2p2/pages/translations/_layout_cs.html
diff --git a/www.i2p2/pages/_layout_de.html b/www.i2p2/pages/translations/_layout_de.html
similarity index 100%
rename from www.i2p2/pages/_layout_de.html
rename to www.i2p2/pages/translations/_layout_de.html
diff --git a/www.i2p2/pages/_layout_el.html b/www.i2p2/pages/translations/_layout_el.html
similarity index 100%
rename from www.i2p2/pages/_layout_el.html
rename to www.i2p2/pages/translations/_layout_el.html
diff --git a/www.i2p2/pages/_layout_es.html b/www.i2p2/pages/translations/_layout_es.html
similarity index 100%
rename from www.i2p2/pages/_layout_es.html
rename to www.i2p2/pages/translations/_layout_es.html
diff --git a/www.i2p2/pages/_layout_fr.html b/www.i2p2/pages/translations/_layout_fr.html
similarity index 100%
rename from www.i2p2/pages/_layout_fr.html
rename to www.i2p2/pages/translations/_layout_fr.html
diff --git a/www.i2p2/pages/_layout_it.html b/www.i2p2/pages/translations/_layout_it.html
similarity index 100%
rename from www.i2p2/pages/_layout_it.html
rename to www.i2p2/pages/translations/_layout_it.html
diff --git a/www.i2p2/pages/_layout_nl.html b/www.i2p2/pages/translations/_layout_nl.html
similarity index 100%
rename from www.i2p2/pages/_layout_nl.html
rename to www.i2p2/pages/translations/_layout_nl.html
diff --git a/www.i2p2/pages/_layout_ru.html b/www.i2p2/pages/translations/_layout_ru.html
similarity index 100%
rename from www.i2p2/pages/_layout_ru.html
rename to www.i2p2/pages/translations/_layout_ru.html
diff --git a/www.i2p2/pages/_layout_zh.html b/www.i2p2/pages/translations/_layout_zh.html
similarity index 100%
rename from www.i2p2/pages/_layout_zh.html
rename to www.i2p2/pages/translations/_layout_zh.html
diff --git a/www.i2p2/pages/announcements_ar.html b/www.i2p2/pages/translations/announcements_ar.html
similarity index 100%
rename from www.i2p2/pages/announcements_ar.html
rename to www.i2p2/pages/translations/announcements_ar.html
diff --git a/www.i2p2/pages/announcements_de.html b/www.i2p2/pages/translations/announcements_de.html
similarity index 100%
rename from www.i2p2/pages/announcements_de.html
rename to www.i2p2/pages/translations/announcements_de.html
diff --git a/www.i2p2/pages/announcements_el.html b/www.i2p2/pages/translations/announcements_el.html
similarity index 100%
rename from www.i2p2/pages/announcements_el.html
rename to www.i2p2/pages/translations/announcements_el.html
diff --git a/www.i2p2/pages/announcements_fr.html b/www.i2p2/pages/translations/announcements_fr.html
similarity index 100%
rename from www.i2p2/pages/announcements_fr.html
rename to www.i2p2/pages/translations/announcements_fr.html
diff --git a/www.i2p2/pages/announcements_it.html b/www.i2p2/pages/translations/announcements_it.html
similarity index 100%
rename from www.i2p2/pages/announcements_it.html
rename to www.i2p2/pages/translations/announcements_it.html
diff --git a/www.i2p2/pages/api_de.html b/www.i2p2/pages/translations/api_de.html
similarity index 100%
rename from www.i2p2/pages/api_de.html
rename to www.i2p2/pages/translations/api_de.html
diff --git a/www.i2p2/pages/api_it.html b/www.i2p2/pages/translations/api_it.html
similarity index 100%
rename from www.i2p2/pages/api_it.html
rename to www.i2p2/pages/translations/api_it.html
diff --git a/www.i2p2/pages/bittorrent_fr.html b/www.i2p2/pages/translations/bittorrent_fr.html
similarity index 100%
rename from www.i2p2/pages/bittorrent_fr.html
rename to www.i2p2/pages/translations/bittorrent_fr.html
diff --git a/www.i2p2/pages/bounties_ar.html b/www.i2p2/pages/translations/bounties_ar.html
similarity index 100%
rename from www.i2p2/pages/bounties_ar.html
rename to www.i2p2/pages/translations/bounties_ar.html
diff --git a/www.i2p2/pages/bounties_de.html b/www.i2p2/pages/translations/bounties_de.html
similarity index 100%
rename from www.i2p2/pages/bounties_de.html
rename to www.i2p2/pages/translations/bounties_de.html
diff --git a/www.i2p2/pages/bounties_it.html b/www.i2p2/pages/translations/bounties_it.html
similarity index 100%
rename from www.i2p2/pages/bounties_it.html
rename to www.i2p2/pages/translations/bounties_it.html
diff --git a/www.i2p2/pages/bounties_ru.html b/www.i2p2/pages/translations/bounties_ru.html
similarity index 100%
rename from www.i2p2/pages/bounties_ru.html
rename to www.i2p2/pages/translations/bounties_ru.html
diff --git a/www.i2p2/pages/bounty_arabic_de.html b/www.i2p2/pages/translations/bounty_arabic_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_arabic_de.html
rename to www.i2p2/pages/translations/bounty_arabic_de.html
diff --git a/www.i2p2/pages/bounty_datastore_de.html b/www.i2p2/pages/translations/bounty_datastore_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_datastore_de.html
rename to www.i2p2/pages/translations/bounty_datastore_de.html
diff --git a/www.i2p2/pages/bounty_datastore_ru.html b/www.i2p2/pages/translations/bounty_datastore_ru.html
similarity index 100%
rename from www.i2p2/pages/bounty_datastore_ru.html
rename to www.i2p2/pages/translations/bounty_datastore_ru.html
diff --git a/www.i2p2/pages/bounty_debpack_de.html b/www.i2p2/pages/translations/bounty_debpack_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_debpack_de.html
rename to www.i2p2/pages/translations/bounty_debpack_de.html
diff --git a/www.i2p2/pages/bounty_i2phex_de.html b/www.i2p2/pages/translations/bounty_i2phex_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_i2phex_de.html
rename to www.i2p2/pages/translations/bounty_i2phex_de.html
diff --git a/www.i2p2/pages/bounty_i2phex_ru.html b/www.i2p2/pages/translations/bounty_i2phex_ru.html
similarity index 100%
rename from www.i2p2/pages/bounty_i2phex_ru.html
rename to www.i2p2/pages/translations/bounty_i2phex_ru.html
diff --git a/www.i2p2/pages/bounty_ipv6_de.html b/www.i2p2/pages/translations/bounty_ipv6_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_ipv6_de.html
rename to www.i2p2/pages/translations/bounty_ipv6_de.html
diff --git a/www.i2p2/pages/bounty_ipv6_ru.html b/www.i2p2/pages/translations/bounty_ipv6_ru.html
similarity index 100%
rename from www.i2p2/pages/bounty_ipv6_ru.html
rename to www.i2p2/pages/translations/bounty_ipv6_ru.html
diff --git a/www.i2p2/pages/bounty_rutrans_de.html b/www.i2p2/pages/translations/bounty_rutrans_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_rutrans_de.html
rename to www.i2p2/pages/translations/bounty_rutrans_de.html
diff --git a/www.i2p2/pages/bounty_rutrans_ru.html b/www.i2p2/pages/translations/bounty_rutrans_ru.html
similarity index 100%
rename from www.i2p2/pages/bounty_rutrans_ru.html
rename to www.i2p2/pages/translations/bounty_rutrans_ru.html
diff --git a/www.i2p2/pages/bounty_syndie2012_de.html b/www.i2p2/pages/translations/bounty_syndie2012_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_syndie2012_de.html
rename to www.i2p2/pages/translations/bounty_syndie2012_de.html
diff --git a/www.i2p2/pages/bounty_unittests_de.html b/www.i2p2/pages/translations/bounty_unittests_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_unittests_de.html
rename to www.i2p2/pages/translations/bounty_unittests_de.html
diff --git a/www.i2p2/pages/bounty_vuzeplugin_de.html b/www.i2p2/pages/translations/bounty_vuzeplugin_de.html
similarity index 100%
rename from www.i2p2/pages/bounty_vuzeplugin_de.html
rename to www.i2p2/pages/translations/bounty_vuzeplugin_de.html
diff --git a/www.i2p2/pages/bounty_vuzeplugin_ru.html b/www.i2p2/pages/translations/bounty_vuzeplugin_ru.html
similarity index 100%
rename from www.i2p2/pages/bounty_vuzeplugin_ru.html
rename to www.i2p2/pages/translations/bounty_vuzeplugin_ru.html
diff --git a/www.i2p2/pages/clt_de.html b/www.i2p2/pages/translations/clt_de.html
similarity index 100%
rename from www.i2p2/pages/clt_de.html
rename to www.i2p2/pages/translations/clt_de.html
diff --git a/www.i2p2/pages/cvs_de.html b/www.i2p2/pages/translations/cvs_de.html
similarity index 100%
rename from www.i2p2/pages/cvs_de.html
rename to www.i2p2/pages/translations/cvs_de.html
diff --git a/www.i2p2/pages/datagrams_de.html b/www.i2p2/pages/translations/datagrams_de.html
similarity index 100%
rename from www.i2p2/pages/datagrams_de.html
rename to www.i2p2/pages/translations/datagrams_de.html
diff --git a/www.i2p2/pages/debian_fr.html b/www.i2p2/pages/translations/debian_fr.html
similarity index 100%
rename from www.i2p2/pages/debian_fr.html
rename to www.i2p2/pages/translations/debian_fr.html
diff --git a/www.i2p2/pages/donate_ar.html b/www.i2p2/pages/translations/donate_ar.html
similarity index 100%
rename from www.i2p2/pages/donate_ar.html
rename to www.i2p2/pages/translations/donate_ar.html
diff --git a/www.i2p2/pages/donate_de.html b/www.i2p2/pages/translations/donate_de.html
similarity index 100%
rename from www.i2p2/pages/donate_de.html
rename to www.i2p2/pages/translations/donate_de.html
diff --git a/www.i2p2/pages/donate_fr.html b/www.i2p2/pages/translations/donate_fr.html
similarity index 100%
rename from www.i2p2/pages/donate_fr.html
rename to www.i2p2/pages/translations/donate_fr.html
diff --git a/www.i2p2/pages/donate_ru.html b/www.i2p2/pages/translations/donate_ru.html
similarity index 100%
rename from www.i2p2/pages/donate_ru.html
rename to www.i2p2/pages/translations/donate_ru.html
diff --git a/www.i2p2/pages/download_ar.html b/www.i2p2/pages/translations/download_ar.html
similarity index 100%
rename from www.i2p2/pages/download_ar.html
rename to www.i2p2/pages/translations/download_ar.html
diff --git a/www.i2p2/pages/download_cs.html b/www.i2p2/pages/translations/download_cs.html
similarity index 100%
rename from www.i2p2/pages/download_cs.html
rename to www.i2p2/pages/translations/download_cs.html
diff --git a/www.i2p2/pages/download_de.html b/www.i2p2/pages/translations/download_de.html
similarity index 100%
rename from www.i2p2/pages/download_de.html
rename to www.i2p2/pages/translations/download_de.html
diff --git a/www.i2p2/pages/download_el.html b/www.i2p2/pages/translations/download_el.html
similarity index 100%
rename from www.i2p2/pages/download_el.html
rename to www.i2p2/pages/translations/download_el.html
diff --git a/www.i2p2/pages/download_es.html b/www.i2p2/pages/translations/download_es.html
similarity index 100%
rename from www.i2p2/pages/download_es.html
rename to www.i2p2/pages/translations/download_es.html
diff --git a/www.i2p2/pages/download_fr.html b/www.i2p2/pages/translations/download_fr.html
similarity index 100%
rename from www.i2p2/pages/download_fr.html
rename to www.i2p2/pages/translations/download_fr.html
diff --git a/www.i2p2/pages/download_ru.html b/www.i2p2/pages/translations/download_ru.html
similarity index 100%
rename from www.i2p2/pages/download_ru.html
rename to www.i2p2/pages/translations/download_ru.html
diff --git a/www.i2p2/pages/download_zh.html b/www.i2p2/pages/translations/download_zh.html
similarity index 100%
rename from www.i2p2/pages/download_zh.html
rename to www.i2p2/pages/translations/download_zh.html
diff --git a/www.i2p2/pages/faq_ar.html b/www.i2p2/pages/translations/faq_ar.html
similarity index 100%
rename from www.i2p2/pages/faq_ar.html
rename to www.i2p2/pages/translations/faq_ar.html
diff --git a/www.i2p2/pages/faq_de.html b/www.i2p2/pages/translations/faq_de.html
similarity index 100%
rename from www.i2p2/pages/faq_de.html
rename to www.i2p2/pages/translations/faq_de.html
diff --git a/www.i2p2/pages/faq_el.html b/www.i2p2/pages/translations/faq_el.html
similarity index 100%
rename from www.i2p2/pages/faq_el.html
rename to www.i2p2/pages/translations/faq_el.html
diff --git a/www.i2p2/pages/faq_fr.html b/www.i2p2/pages/translations/faq_fr.html
similarity index 100%
rename from www.i2p2/pages/faq_fr.html
rename to www.i2p2/pages/translations/faq_fr.html
diff --git a/www.i2p2/pages/faq_zh.html b/www.i2p2/pages/translations/faq_zh.html
similarity index 100%
rename from www.i2p2/pages/faq_zh.html
rename to www.i2p2/pages/translations/faq_zh.html
diff --git a/www.i2p2/pages/getinvolved_ar.html b/www.i2p2/pages/translations/getinvolved_ar.html
similarity index 100%
rename from www.i2p2/pages/getinvolved_ar.html
rename to www.i2p2/pages/translations/getinvolved_ar.html
diff --git a/www.i2p2/pages/getinvolved_de.html b/www.i2p2/pages/translations/getinvolved_de.html
similarity index 100%
rename from www.i2p2/pages/getinvolved_de.html
rename to www.i2p2/pages/translations/getinvolved_de.html
diff --git a/www.i2p2/pages/getinvolved_el.html b/www.i2p2/pages/translations/getinvolved_el.html
similarity index 100%
rename from www.i2p2/pages/getinvolved_el.html
rename to www.i2p2/pages/translations/getinvolved_el.html
diff --git a/www.i2p2/pages/getinvolved_fr.html b/www.i2p2/pages/translations/getinvolved_fr.html
similarity index 100%
rename from www.i2p2/pages/getinvolved_fr.html
rename to www.i2p2/pages/translations/getinvolved_fr.html
diff --git a/www.i2p2/pages/getinvolved_ru.html b/www.i2p2/pages/translations/getinvolved_ru.html
similarity index 100%
rename from www.i2p2/pages/getinvolved_ru.html
rename to www.i2p2/pages/translations/getinvolved_ru.html
diff --git a/www.i2p2/pages/halloffame_de.html b/www.i2p2/pages/translations/halloffame_de.html
similarity index 100%
rename from www.i2p2/pages/halloffame_de.html
rename to www.i2p2/pages/translations/halloffame_de.html
diff --git a/www.i2p2/pages/how_cryptography_de.html b/www.i2p2/pages/translations/how_cryptography_de.html
similarity index 100%
rename from www.i2p2/pages/how_cryptography_de.html
rename to www.i2p2/pages/translations/how_cryptography_de.html
diff --git a/www.i2p2/pages/how_de.html b/www.i2p2/pages/translations/how_de.html
similarity index 100%
rename from www.i2p2/pages/how_de.html
rename to www.i2p2/pages/translations/how_de.html
diff --git a/www.i2p2/pages/how_el.html b/www.i2p2/pages/translations/how_el.html
similarity index 100%
rename from www.i2p2/pages/how_el.html
rename to www.i2p2/pages/translations/how_el.html
diff --git a/www.i2p2/pages/how_elgamalaes_de.html b/www.i2p2/pages/translations/how_elgamalaes_de.html
similarity index 100%
rename from www.i2p2/pages/how_elgamalaes_de.html
rename to www.i2p2/pages/translations/how_elgamalaes_de.html
diff --git a/www.i2p2/pages/how_fr.html b/www.i2p2/pages/translations/how_fr.html
similarity index 100%
rename from www.i2p2/pages/how_fr.html
rename to www.i2p2/pages/translations/how_fr.html
diff --git a/www.i2p2/pages/how_garlicrouting_de.html b/www.i2p2/pages/translations/how_garlicrouting_de.html
similarity index 100%
rename from www.i2p2/pages/how_garlicrouting_de.html
rename to www.i2p2/pages/translations/how_garlicrouting_de.html
diff --git a/www.i2p2/pages/how_intro_el.html b/www.i2p2/pages/translations/how_intro_el.html
similarity index 100%
rename from www.i2p2/pages/how_intro_el.html
rename to www.i2p2/pages/translations/how_intro_el.html
diff --git a/www.i2p2/pages/how_networkcomparisons_fr.html b/www.i2p2/pages/translations/how_networkcomparisons_fr.html
similarity index 100%
rename from www.i2p2/pages/how_networkcomparisons_fr.html
rename to www.i2p2/pages/translations/how_networkcomparisons_fr.html
diff --git a/www.i2p2/pages/how_peerselection_de.html b/www.i2p2/pages/translations/how_peerselection_de.html
similarity index 100%
rename from www.i2p2/pages/how_peerselection_de.html
rename to www.i2p2/pages/translations/how_peerselection_de.html
diff --git a/www.i2p2/pages/how_threatmodel_fr.html b/www.i2p2/pages/translations/how_threatmodel_fr.html
similarity index 100%
rename from www.i2p2/pages/how_threatmodel_fr.html
rename to www.i2p2/pages/translations/how_threatmodel_fr.html
diff --git a/www.i2p2/pages/htproxyports_fr.html b/www.i2p2/pages/translations/htproxyports_fr.html
similarity index 100%
rename from www.i2p2/pages/htproxyports_fr.html
rename to www.i2p2/pages/translations/htproxyports_fr.html
diff --git a/www.i2p2/pages/i2np_de.html b/www.i2p2/pages/translations/i2np_de.html
similarity index 100%
rename from www.i2p2/pages/i2np_de.html
rename to www.i2p2/pages/translations/i2np_de.html
diff --git a/www.i2p2/pages/impressum_de.html b/www.i2p2/pages/translations/impressum_de.html
similarity index 100%
rename from www.i2p2/pages/impressum_de.html
rename to www.i2p2/pages/translations/impressum_de.html
diff --git a/www.i2p2/pages/index_ar.html b/www.i2p2/pages/translations/index_ar.html
similarity index 100%
rename from www.i2p2/pages/index_ar.html
rename to www.i2p2/pages/translations/index_ar.html
diff --git a/www.i2p2/pages/index_cs.html b/www.i2p2/pages/translations/index_cs.html
similarity index 100%
rename from www.i2p2/pages/index_cs.html
rename to www.i2p2/pages/translations/index_cs.html
diff --git a/www.i2p2/pages/index_de.html b/www.i2p2/pages/translations/index_de.html
similarity index 100%
rename from www.i2p2/pages/index_de.html
rename to www.i2p2/pages/translations/index_de.html
diff --git a/www.i2p2/pages/index_el.html b/www.i2p2/pages/translations/index_el.html
similarity index 100%
rename from www.i2p2/pages/index_el.html
rename to www.i2p2/pages/translations/index_el.html
diff --git a/www.i2p2/pages/index_es.html b/www.i2p2/pages/translations/index_es.html
similarity index 100%
rename from www.i2p2/pages/index_es.html
rename to www.i2p2/pages/translations/index_es.html
diff --git a/www.i2p2/pages/index_fr.html b/www.i2p2/pages/translations/index_fr.html
similarity index 100%
rename from www.i2p2/pages/index_fr.html
rename to www.i2p2/pages/translations/index_fr.html
diff --git a/www.i2p2/pages/index_it.html b/www.i2p2/pages/translations/index_it.html
similarity index 100%
rename from www.i2p2/pages/index_it.html
rename to www.i2p2/pages/translations/index_it.html
diff --git a/www.i2p2/pages/index_nl.html b/www.i2p2/pages/translations/index_nl.html
similarity index 100%
rename from www.i2p2/pages/index_nl.html
rename to www.i2p2/pages/translations/index_nl.html
diff --git a/www.i2p2/pages/index_ru.html b/www.i2p2/pages/translations/index_ru.html
similarity index 100%
rename from www.i2p2/pages/index_ru.html
rename to www.i2p2/pages/translations/index_ru.html
diff --git a/www.i2p2/pages/index_zh.html b/www.i2p2/pages/translations/index_zh.html
similarity index 100%
rename from www.i2p2/pages/index_zh.html
rename to www.i2p2/pages/translations/index_zh.html
diff --git a/www.i2p2/pages/installation_de.html b/www.i2p2/pages/translations/installation_de.html
similarity index 100%
rename from www.i2p2/pages/installation_de.html
rename to www.i2p2/pages/translations/installation_de.html
diff --git a/www.i2p2/pages/installation_zh.html b/www.i2p2/pages/translations/installation_zh.html
similarity index 100%
rename from www.i2p2/pages/installation_zh.html
rename to www.i2p2/pages/translations/installation_zh.html
diff --git a/www.i2p2/pages/intro_ar.html b/www.i2p2/pages/translations/intro_ar.html
similarity index 100%
rename from www.i2p2/pages/intro_ar.html
rename to www.i2p2/pages/translations/intro_ar.html
diff --git a/www.i2p2/pages/intro_el.html b/www.i2p2/pages/translations/intro_el.html
similarity index 100%
rename from www.i2p2/pages/intro_el.html
rename to www.i2p2/pages/translations/intro_el.html
diff --git a/www.i2p2/pages/intro_fr.html b/www.i2p2/pages/translations/intro_fr.html
similarity index 100%
rename from www.i2p2/pages/intro_fr.html
rename to www.i2p2/pages/translations/intro_fr.html
diff --git a/www.i2p2/pages/intro_ru.html b/www.i2p2/pages/translations/intro_ru.html
similarity index 100%
rename from www.i2p2/pages/intro_ru.html
rename to www.i2p2/pages/translations/intro_ru.html
diff --git a/www.i2p2/pages/invisiblenet_de.html b/www.i2p2/pages/translations/invisiblenet_de.html
similarity index 100%
rename from www.i2p2/pages/invisiblenet_de.html
rename to www.i2p2/pages/translations/invisiblenet_de.html
diff --git a/www.i2p2/pages/jbigi_de.html b/www.i2p2/pages/translations/jbigi_de.html
similarity index 100%
rename from www.i2p2/pages/jbigi_de.html
rename to www.i2p2/pages/translations/jbigi_de.html
diff --git a/www.i2p2/pages/jrandom-awol_de.html b/www.i2p2/pages/translations/jrandom-awol_de.html
similarity index 100%
rename from www.i2p2/pages/jrandom-awol_de.html
rename to www.i2p2/pages/translations/jrandom-awol_de.html
diff --git a/www.i2p2/pages/license-agreements_de.html b/www.i2p2/pages/translations/license-agreements_de.html
similarity index 100%
rename from www.i2p2/pages/license-agreements_de.html
rename to www.i2p2/pages/translations/license-agreements_de.html
diff --git a/www.i2p2/pages/licenses_de.html b/www.i2p2/pages/translations/licenses_de.html
similarity index 100%
rename from www.i2p2/pages/licenses_de.html
rename to www.i2p2/pages/translations/licenses_de.html
diff --git a/www.i2p2/pages/links_de.html b/www.i2p2/pages/translations/links_de.html
similarity index 100%
rename from www.i2p2/pages/links_de.html
rename to www.i2p2/pages/translations/links_de.html
diff --git a/www.i2p2/pages/links_fr.html b/www.i2p2/pages/translations/links_fr.html
similarity index 100%
rename from www.i2p2/pages/links_fr.html
rename to www.i2p2/pages/translations/links_fr.html
diff --git a/www.i2p2/pages/links_zh.html b/www.i2p2/pages/translations/links_zh.html
similarity index 100%
rename from www.i2p2/pages/links_zh.html
rename to www.i2p2/pages/translations/links_zh.html
diff --git a/www.i2p2/pages/meetings_de.html b/www.i2p2/pages/translations/meetings_de.html
similarity index 100%
rename from www.i2p2/pages/meetings_de.html
rename to www.i2p2/pages/translations/meetings_de.html
diff --git a/www.i2p2/pages/meetings_fr.html b/www.i2p2/pages/translations/meetings_fr.html
similarity index 100%
rename from www.i2p2/pages/meetings_fr.html
rename to www.i2p2/pages/translations/meetings_fr.html
diff --git a/www.i2p2/pages/naming_fr.html b/www.i2p2/pages/translations/naming_fr.html
similarity index 100%
rename from www.i2p2/pages/naming_fr.html
rename to www.i2p2/pages/translations/naming_fr.html
diff --git a/www.i2p2/pages/newdevelopers_de.html b/www.i2p2/pages/translations/newdevelopers_de.html
similarity index 100%
rename from www.i2p2/pages/newdevelopers_de.html
rename to www.i2p2/pages/translations/newdevelopers_de.html
diff --git a/www.i2p2/pages/newdevelopers_fr.html b/www.i2p2/pages/translations/newdevelopers_fr.html
similarity index 100%
rename from www.i2p2/pages/newdevelopers_fr.html
rename to www.i2p2/pages/translations/newdevelopers_fr.html
diff --git a/www.i2p2/pages/newdevelopers_it.html b/www.i2p2/pages/translations/newdevelopers_it.html
similarity index 100%
rename from www.i2p2/pages/newdevelopers_it.html
rename to www.i2p2/pages/translations/newdevelopers_it.html
diff --git a/www.i2p2/pages/newtranslators_fr.html b/www.i2p2/pages/translations/newtranslators_fr.html
similarity index 100%
rename from www.i2p2/pages/newtranslators_fr.html
rename to www.i2p2/pages/translations/newtranslators_fr.html
diff --git a/www.i2p2/pages/papers_fr.html b/www.i2p2/pages/translations/papers_fr.html
similarity index 100%
rename from www.i2p2/pages/papers_fr.html
rename to www.i2p2/pages/translations/papers_fr.html
diff --git a/www.i2p2/pages/plugin_spec_de.html b/www.i2p2/pages/translations/plugin_spec_de.html
similarity index 100%
rename from www.i2p2/pages/plugin_spec_de.html
rename to www.i2p2/pages/translations/plugin_spec_de.html
diff --git a/www.i2p2/pages/plugin_spec_fr.html b/www.i2p2/pages/translations/plugin_spec_fr.html
similarity index 100%
rename from www.i2p2/pages/plugin_spec_fr.html
rename to www.i2p2/pages/translations/plugin_spec_fr.html
diff --git a/www.i2p2/pages/plugins_de.html b/www.i2p2/pages/translations/plugins_de.html
similarity index 100%
rename from www.i2p2/pages/plugins_de.html
rename to www.i2p2/pages/translations/plugins_de.html
diff --git a/www.i2p2/pages/plugins_fr.html b/www.i2p2/pages/translations/plugins_fr.html
similarity index 100%
rename from www.i2p2/pages/plugins_fr.html
rename to www.i2p2/pages/translations/plugins_fr.html
diff --git a/www.i2p2/pages/pressetext-0.7.html b/www.i2p2/pages/translations/pressetext-0.7.html
similarity index 100%
rename from www.i2p2/pages/pressetext-0.7.html
rename to www.i2p2/pages/translations/pressetext-0.7.html
diff --git a/www.i2p2/pages/protocols_de.html b/www.i2p2/pages/translations/protocols_de.html
similarity index 100%
rename from www.i2p2/pages/protocols_de.html
rename to www.i2p2/pages/translations/protocols_de.html
diff --git a/www.i2p2/pages/protocols_fr.html b/www.i2p2/pages/translations/protocols_fr.html
similarity index 100%
rename from www.i2p2/pages/protocols_fr.html
rename to www.i2p2/pages/translations/protocols_fr.html
diff --git a/www.i2p2/pages/release-0.7.8_zh.html b/www.i2p2/pages/translations/release-0.7.8_zh.html
similarity index 100%
rename from www.i2p2/pages/release-0.7.8_zh.html
rename to www.i2p2/pages/translations/release-0.7.8_zh.html
diff --git a/www.i2p2/pages/release-0.8.4_fr.html b/www.i2p2/pages/translations/release-0.8.4_fr.html
similarity index 100%
rename from www.i2p2/pages/release-0.8.4_fr.html
rename to www.i2p2/pages/translations/release-0.8.4_fr.html
diff --git a/www.i2p2/pages/release-0.8.5_fr.html b/www.i2p2/pages/translations/release-0.8.5_fr.html
similarity index 100%
rename from www.i2p2/pages/release-0.8.5_fr.html
rename to www.i2p2/pages/translations/release-0.8.5_fr.html
diff --git a/www.i2p2/pages/release-0.8.6_fr.html b/www.i2p2/pages/translations/release-0.8.6_fr.html
similarity index 100%
rename from www.i2p2/pages/release-0.8.6_fr.html
rename to www.i2p2/pages/translations/release-0.8.6_fr.html
diff --git a/www.i2p2/pages/release-0.8.7_fr.html b/www.i2p2/pages/translations/release-0.8.7_fr.html
similarity index 100%
rename from www.i2p2/pages/release-0.8.7_fr.html
rename to www.i2p2/pages/translations/release-0.8.7_fr.html
diff --git a/www.i2p2/pages/roadmap_de.html b/www.i2p2/pages/translations/roadmap_de.html
similarity index 100%
rename from www.i2p2/pages/roadmap_de.html
rename to www.i2p2/pages/translations/roadmap_de.html
diff --git a/www.i2p2/pages/roadmap_fr.html b/www.i2p2/pages/translations/roadmap_fr.html
similarity index 100%
rename from www.i2p2/pages/roadmap_fr.html
rename to www.i2p2/pages/translations/roadmap_fr.html
diff --git a/www.i2p2/pages/summerofcode-2011_fr.html b/www.i2p2/pages/translations/summerofcode-2011_fr.html
similarity index 100%
rename from www.i2p2/pages/summerofcode-2011_fr.html
rename to www.i2p2/pages/translations/summerofcode-2011_fr.html
diff --git a/www.i2p2/pages/team_de.html b/www.i2p2/pages/translations/team_de.html
similarity index 100%
rename from www.i2p2/pages/team_de.html
rename to www.i2p2/pages/translations/team_de.html
diff --git a/www.i2p2/pages/team_fr.html b/www.i2p2/pages/translations/team_fr.html
similarity index 100%
rename from www.i2p2/pages/team_fr.html
rename to www.i2p2/pages/translations/team_fr.html
diff --git a/www.i2p2/pages/techintro_fr.html b/www.i2p2/pages/translations/techintro_fr.html
similarity index 100%
rename from www.i2p2/pages/techintro_fr.html
rename to www.i2p2/pages/translations/techintro_fr.html
diff --git a/www.i2p2/pages/todo_de.html b/www.i2p2/pages/translations/todo_de.html
similarity index 100%
rename from www.i2p2/pages/todo_de.html
rename to www.i2p2/pages/translations/todo_de.html
diff --git a/www.i2p2/pages/todo_fr.html b/www.i2p2/pages/translations/todo_fr.html
similarity index 100%
rename from www.i2p2/pages/todo_fr.html
rename to www.i2p2/pages/translations/todo_fr.html
diff --git a/www.i2p2/pages/updates_de.html b/www.i2p2/pages/translations/updates_de.html
similarity index 100%
rename from www.i2p2/pages/updates_de.html
rename to www.i2p2/pages/translations/updates_de.html
diff --git a/www.i2p2/pages/transport.html b/www.i2p2/pages/transport.html
deleted file mode 100644
index 4dba232a..00000000
--- a/www.i2p2/pages/transport.html
+++ /dev/null
@@ -1,127 +0,0 @@
-{% extends "_layout.html" %}
-{% block title %}Transport Overview{% endblock %}
-{% block content %}
-
-Updated July 2010, current as of router version 0.8
-
-
            Transports in I2P
            
-
-A "transport" in I2P is a method for direct, point-to-point communication
-between two routers.
-Transports must provide confidentiality and integrity 
-against external adversaries while authenticating that the router contacted 
-is the one who should receive a given message.
-
-
             I2P supports multiple transports simultaneously.
-There are two transports currently implemented:
-
              
-
            1.  NTCP, a Java New I/O (NIO) TCP transport
-
            2.  SSU, or Secure Semireliable UDP
-
            
-
-Each provides a "connection" paradigm, with authentication,
-flow control, acknowledgments and retransmission.
-
-
-
            Transport Services
            
-
-The transport subsystem in I2P provides the following services:
-
              
-
            • Maintain a set of router addresses, one or more for each transport,
-    that the router publishes as its global contact information (the RouterInfo)
-
            • Selection of the best transport for each outgoing message
-
            • Queueing of outbound messages by priority
-
            • Bandwidth limiting, both outbound and inbound, according to router configuration
-
            • Setup and teardown of transport connections
-
            • Encryption of point-to-point communications
-
            • Maintenance of connection limits for each transport, implementation of various thresholds for these limits,
-    and communication of threshold status to the router so it may make operational changes based on the status
-
            • Firewall port opening using UPnP (Universal Plug and Play)
-
            • Cooperative NAT/Firewall traversal
-
            • Local IP detection by various methods, including UPnP, inspection of incoming connections, and enumeration of network devices
-
            • Coordination of firewall status and local IP, and changes to either, among the transports
-
            • Communication of firewall status and local IP, and changes to either, to the router and the user interface
-
            • Determination of a consensus clock, which is used to periodically update the router's clock, as a backup for NTP
-
            • Maintenance of status for each peer, including whether it is connected, whether it was recently connected,
-    and whether it was reachable in the last attempt
-
            • Qualification of valid IP addresses according to a local rule set
-
            • Honoring the automated and manual lists of banned peers maintained by the router,
-    and refusing outbound and inbound connections to those peers
-
            
-
-
-
            Transport Addresses
            
-
-The transport subsystem maintains a set of router addresses, each of which lists a transport method, IP, and port.
-These addresses constitute the advertised contact points, and are published by the router to the network database.
-
            
-Typical scenarios are:
-
              
-
            • A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections
-
            • A router is firewalled, and therefore publishes an SSU address which contains a list of cooperating
-    peers or "introducers" who will assist in NAT traversal (see the SSU spec for details)
-
            • A router is not firewalled or its NAT ports  are open; it publishes both NTCP and SSU addresses containing
-    directly-accessible IP and ports.
-
            
-
-
            Transport Selection
            
-
-The transport system delivers I2NP messages. The transport selected for any message is
-independent of the application-layer protocol (TCP or UDP).
-
            
-
-For each outgoing message, the transport system solicits "bids" from each transport.
-The transport bidding the lowest (best) value wins the bid and receives the message for delivery.
-A transport may refuse to bid.
-
            
-Whether a transport bids, and with what value, depend on numerous factors:
-
              
-
            • Configuration of transport preferences
-
            • Whether the transport is already connected to the peer
-
            • The number of current connections compared to various connection limit thresholds
-
            • Whether recent connection attempts to the peer have failed
-
            • The size of the message, as different transports have different size limits
-
            • Whether the peer can accept incoming connections for that transport, as advertised in its RouterInfo
-
            • Whether the connection would be indirect (requiring introducers) or direct
-
            • The peer's transport preference, as advertised in its RouterInfo
-
            
-
-
            
-In general, the bid values are selected so that two routers are only connected by a single transport
-at any one time. However, this is not a requirement.
-
-
-
-
            New Transports and Future Work
            
-
-Additional transports may be developed, including:
-
-
              
-
            • A TLS/SSH look-alike transport
-
            • An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes")
-
            
-
-
            
-Also, the existing transports will be enhanced to support multiple addresses within a single transport,
-including IPV6 addresses. Currently, a transport may only advertise a single IPV4 address.
-
-
            
-Work continues on adjusting default connection limits for each transport.
-I2P is designed as a "mesh network", where it is assumed that any router can connect to any other router.
-This assumption may be broken by routers that have exceeded their connection limits, and by
-routers that are behind restrictive state firewalls (restricted routes).
-
-
            
-The current connection limits are higher for SSU than for NTCP, based on the assumption that
-the memory requirements for an NTCP connection are higher than that for SSU.
-However, as NTCP buffers are partially in the kernel and SSU buffers are on the Java heap,
-that assumption is difficult to verify.
-
-
            
-Analyze
-Breaking and Improving Protocol Obfuscation
-and see how transport-layer padding may improve things.
-
            
-
-
-{% endblock %}
diff --git a/www.i2p2/static/images/i2plogo.png b/www.i2p2/static/images/i2plogo.png
deleted file mode 100644
index f7beff26..00000000
Binary files a/www.i2p2/static/images/i2plogo.png and /dev/null differ